Hi; I'm hoping somebody will be willing to run a test kernel
for me on some omap boards and send me the dmesg output.
(I'm trying to sort out QEMU's modelling of the OMAP ID
registers and the TRMs are rather unhelpful; in particular
the OMAP35x TRM claims that there are two overlapping registers
at addresses 0x218-0x21c!)
I've done a Beagle xM which is an OMAP3630, but I'm looking for
the results for OMAP34xx/35xx (I think classic Beagle is this)
and also if possible an OMAP2 board.
The kernel is http://people.linaro.org/~pmaydell/uImage.test
(it's the linaro 3.0 kernel with a stock omap2_defconfig and
some extra printks so it shouldn't do anything too alarming
to your board :-)). It needs the command line arguments
'earlyprintk debug console=ttyO2,115200'
(possibly for omap2 the console tty device is different)
and I'm interested in the bit of dmesg output near the start:
[ 0.000000] PMM: ID register dump:
[ 0.000000] register offset 0x204 value 0x0b89102f
[ 0.000000] register offset 0x208 value 0x00000000
[ 0.000000] register offset 0x20c value 0x00000000
[ 0.000000] register offset 0x210 value 0x000000f0
[ 0.000000] register offset 0x214 value 0xcafeb891
[ 0.000000] register offset 0x218 value 0x0703201f
[ 0.000000] register offset 0x21c value 0x015739ea
[ 0.000000] register offset 0x220 value 0x1bf00000
[ 0.000000] register offset 0x224 value 0x5dd40000
[ 0.000000] OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )
(so you don't need the initrd/modules/etc, it's ok if it
doesn't boot fully.)
Thanks in advance!
-- PMM
Hello,
One of the issues with https://android-build.linaro.org/ is that, if
build fails, it's not easy to tell if it happened because of
compilation error ("real" failure) or due to non-deterministic error
with setting up infrastructure for build (e.g. during source checkout).
The latter not so uncommon due to vast source size of Android and
complexity of cloud infrastructure.
This became especially problematic with start of automated CI loop,
where it leads to false negatives when doing pre-merge testing.
Improving this situation was subject of few blueprints in which
Infrastructure team worked, and recently, a solution was deployed. With
it, if a build fails due to non-deterministic infrastructure error, it
will get status of "NOT BUILT", meaning that a build never actually got
to compilation phase. Suggested action in such case is to retry.
Please note that Jenkins there is some inconsistency within the Jenkins
itself regarding NOT BUILT status - "Pending" is used as a display name
in places, and the same gray icon used as for ABORTED builds. So,
please keep that in mind, or yet better use Build Frontend.
Unfortunately, even short weekend testing showed that error separation
achieved is not ideal (folks who participated in Connect Q4.11
session dedicated to this, may remember that I said that it would
take adding AI to do that properly ;-) ).
In particular, if there was an issue with manifest file (essentially,
an error in Android source code), it will be reported as NOT BUILT
instead of FAILED. Here's example of such build:
https://android-build.linaro.org/jenkins/job/linaro-android_panda-ics-gcc44…
Opposite miscategorization may also happen: very early infra error may
be reported as FAILED instead of NOT BUILT. Example:
https://android-build.linaro.org/jenkins/job/linaro-android_panda-ics-gcc46…
So, Infrastructure team will continue to work on improving reliability
of builds, but in the meantime please keep looking in the build logs for
actual cause of the failure (feel free to report unexpected build
status to https://bugs.launchpad.net/linaro-android-infrastructure)
--
Best Regards,
Paul
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
The following patch checks if there are pending interrupts on the gic.
This function is needed for example for the ux500 cpuidle driver.
When the A9 cores and the gic are decoupled from the PRCMU, the idle
routine has to check if an interrupt is pending on the gic before entering
in retention mode.
Signed-off-by: Daniel Lezcano <daniel.lezcano(a)linaro.org>
---
arch/arm/common/gic.c | 37 +++++++++++++++++++++++++++++++++++
arch/arm/include/asm/hardware/gic.h | 2 +-
2 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index aa52699..2528094 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -750,6 +750,43 @@ void gic_raise_softirq(const struct cpumask *mask, unsigned int irq)
}
#endif
+/*
+ * gic_pending_irq - checks if there are pending interrupts on the gic
+ *
+ * Disabling an interrupt only disables the forwarding of the
+ * interrupt to any CPU interface. It does not prevent the interrupt
+ * from changing state, for example becoming pending, or active and
+ * pending if it is already active. For this reason, we have to check
+ * the interrupt is pending *and* is enabled.
+ *
+ * Returns true if there are pending and enabled interrupts, false
+ * otherwise.
+ */
+bool gic_pending_irq(unsigned int gic_nr)
+{
+ u32 pr; /* Pending register */
+ u32 er; /* Enable register */
+ void __iomem *dist_base;
+ int gic_irqs;
+ int i;
+
+ BUG_ON(gic_nr >= MAX_GIC_NR);
+
+ gic_irqs = gic_data[gic_nr].gic_irqs;
+ dist_base = gic_data_dist_base(&gic_data[gic_nr]);
+
+ for (i = 0; i < DIV_ROUND_UP(gic_irqs, 32); i++) {
+
+ pr = readl_relaxed(dist_base + GIC_DIST_PENDING_SET + i * 4);
+ er = readl_relaxed(dist_base + GIC_DIST_ENABLE_SET + i * 4);
+
+ if (pr & er)
+ return true;
+ }
+
+ return false;
+}
+
#ifdef CONFIG_OF
static int gic_cnt __initdata = 0;
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index 4b1ce6c..d198ac0 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -45,7 +45,7 @@ void gic_secondary_init(unsigned int);
void gic_handle_irq(struct pt_regs *regs);
void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
void gic_raise_softirq(const struct cpumask *mask, unsigned int irq);
-
+bool gic_pending_irq(unsigned int gic_nr);
static inline void gic_init(unsigned int nr, int start,
void __iomem *dist , void __iomem *cpu)
{
--
1.7.5.4
Hi,
I have an interesting observation that I thought might be interesting
to the tool-chain team.
I was trying to build u-boot in Thumb2 for OMAP4. Everything was fine
until I added some patches recently. One of these patches introduced an
API (let's say foo()) that has a weakly linked alias(let's say
__foo()) and a strongly linked implementation(the real foo()) in an
assembly file.
Although I give -mthumb and -mthumb-interwork for all the files,
apparently GCC generates ARM code for assembly files. In the final
image foobar() calls foo() using a BL. Since foobar() is in Thumb and
foo() in ARM, it ends up crashing. Looks like foobar() assumed foo()
to be Thumb because __foo() is Thumb.
Also I see that 'objdump -S' aborts when it tries to parse foo().
I could workaround this problem by having foo() also in a C file that
in turn calls into the assembly file.
I tried Linaro GCC 4.5.2 and Codesourcery Lite GCC 4.4.1. Both seem to
have the issue.
Isn't this an issue with GCC or am I missing something?
-Aneesh
Re-sending as these patches did not make it to the lists due to
issues with my 'git send-email'
v3 has mainly 2 differences from v2
-1- TWL driver now uses just one table for both dt and
non-dt based lookup for driver data.
-2- All common regulator nodes for twl4030 and twl6030 are
now defined in the twl4030.dtsi and twl6030.dtsi instead of
repeating the nodes in all board files, which also means
the patch ('arm/dts: twl: Pass regulator data from dt')
has a dependency with the series from Benoit which adds the
twl4030.dtsi and twl6030.dtsi files[1].
I have tested the patches on omap4panda and omap3beagle boards.
[1] git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.4/dt_i2c_twl
Rajendra Nayak (2):
regulator: twl: adapt twl-regulator driver to dt
arm/dts: twl: Pass regulator data from dt
.../bindings/regulator/twl-regulator.txt | 63 ++++++
arch/arm/boot/dts/omap3-beagle.dts | 6 +
arch/arm/boot/dts/twl4030.dtsi | 18 ++
arch/arm/boot/dts/twl6030.dtsi | 60 +++++
drivers/regulator/twl-regulator.c | 227 +++++++++++++-------
5 files changed, 301 insertions(+), 73 deletions(-)
create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt
Hey,
As usual, here it goes the announcement of the 12.02 RC images. This
time it's later than usual because we had an issue with our builder
(offspring), but seems to be all solved now (thanks to Fathi).
This release includes a newer version of Unity (2d and 3d), XBMC and
for Pandaboard's OpenGL ES drivers. Other than that we also had minor
fixes for other boards, with improvements at the audio support as
well.
You can find our current test cases at
https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu, and the 12.02 RC
builds (for all boards and image flavors) at
http://snapshots.linaro.org/oneiric/, with build id
20120221-1 for hwpacks and 20120221-0 for the rootfs (nano, developer,
alip, ubuntu-desktop and linaro-tv-xbmc).
For our four main boards we also have a testing spreadsheet, were we
publish the official release testing, done by the dev platform
engineers.
You can find the links at
https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you
can find the bug reports from the test cases by looking at the QA page
tag links).
Fathi will be coordinating all respin requests in the next following
days at linaro-release m-l, and the final image will be published this
thursday, at releases.linaro.org.
Please also be sure to publish any bug report with the RC images
against https://launchpad.net/linaro-ubuntu, or just contact us at
#linaro @ freenode
(https://wiki.linaro.org/MeetTheTeam#Developer_Platform).
Thanks,
--
Ricardo Salveti de Araujo
Hello
here is the status of the Graphics group. Latest meeting minutes can be
found in
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/Notes/2012-02-22
= Highlights =
- related to the 12.02 release the group managed to release the intended
components: libmatrix, glcompbench, glmark2, glproxy. Details are in the
12.02 release highlights -
https://wiki.linaro.org/Cycles/1202/Release/Highlights
- On the Unity/Nux/Compiz front: we are discussing the way forward
related to compiz-core with Ubuntu DX. There is a patch from our side,
based on earlier work done while Travis was still working for GFX - in
discussions this is the 'distro' or 'ifdef' patch, which is rather large
and work has been going on to split it into parts.
One part introduces an API which does not affect Compiz or Unity per se.
The objective is to have Unity using the new API. In doing so, Unity
will be loosing its fixed function OpenGL code and it will start to use
a more recent part of the OpenGL API that is more compatible with OpenGL
ES (it would turn the compiz package into a compiz-gles2). This will
reduce the difference in code between Unity on the desktop and Unity on ARM.
The point is this API patch won't be used right away when it is
proposed. So there aren't any existing automated DX tests to exercise it
in Unity immediately. This is an issue since the DX team are trying to
achieve working unity-3d for 12.04 before anything else, and they are
past feature freeze.
It has now been agreed to work on getting the 'distro' patch landed as
soon as possible. The API patch will be worked on at a later stage.
- dmabuf plans: the points from the discussions at Connect are being
collected at
https://wiki.linaro.org/WorkingGroups/Middleware/Graphics/UMM/Status,
and a number of blueprints are being created and discussed to reflect
the work under https://blueprints.launchpad.net/linaro-mm-sig/
- 12.03 plans: apart from the compiz and dmabuf work which was mentioned
above, the group will focus on working towards glmark2 backlog items,
glcompbench + glproxy.
- GFX LAVA dashboard: Alexandros has given a private demo of the
dashboard to a number of people. It is clear that the tests employed are
really useful in discovering regressions and issues with performance,
comparing daily test-run results. The development strategy is to focus
on the glmark2 benchmark first. After the glmark2 visualization is in a
good state, the team will start looking into visualizing additional
benchmarks. Due to the Linaro data policy there is also some polishing
needed - perhaps there will be 2 versions of the dashboard with the
externally available being completely compliant with the data policy.
Please note that the requirement to make a private version available
under permission is proving challenging, seems we would be spending much
time protecting the private dashboard view
- Finally related to prototyping around perf events (Mali): currently
this is bit stuck in not getting much data across the GPUs (information
is different between GPUs as well as the way to get the information is
different for different GPUs), trying to solve this in a good way.
Requires some driver specific modifications to generate the data
correctly, we will continue piloting this.
Questions, issues please let me know.
Best regards
--
Ilias Biris ilias.biris(a)linaro.org
Project Manager, Linaro
M: +358504839608, IRC: ibiris Skype: ilias_biris
Linaro.org│ Open source software for ARM SoCs