I tried booting linux-linaro-2.6.37 kernel on my beagle board C4. I executed
1. Installed linaro on a 4 GB SD card using linaro-image-tools 0.4.1 with
hwpack daily snapshot hwpack_linaro-omap3_20110125-0_armel_supported.tar.gz
and linaro-natty-headless-tar-20101202-1.tar.gz. It was booting properly on
2. Cloned linux-linaro-2.6.37. Changed to source directory
3. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- omap2plus_defconfig
4. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig (enabled
5. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage
6. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules
7. make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules_install
8. cp arch/arm/boot/uImage /media/boot; sync
Everything went on smoothly. Then I put the SD card on BB and powered it on.
I got a kernel panic: http://paste.ubuntu.com/560562
Please help me figuring out the problem. Is it because I didn't create
uInitrd? If so, then how to create it for ARM?
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
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?
We currently use a feature branch / merge request / merge / test /
push approach in gcc-linaro. This works fine for a reasonable cost
but can mean that patches sit unreviewed and unmerged for up to a
month. Ramana, Andrew, and I had a talk about this earlier in the
week and I've written up the ideas here:
We're a bit unique as gcc-linaro started from a mature base, running
the testsuite takes days, and the product is so big that bzr takes a
long time to work on it.
If you have experience in running a master branch or ideas on
continious integration please have a read.
Here are what the patch set does.
* Remove .probe and .remove hooks from sdhci-pltfm.c and make it be
a pure common helper function providers.
* Add .probe and .remove hooks for sdhci pltfm drivers sdhci-cns3xxx,
sdhci-dove, sdhci-tegra, and sdhci-esdhc-imx to make them self
registered with calling helper functions created above.
* Migrate the use of sdhci_of_host and sdhci_of_data to
sdhci_pltfm_host and sdhci_pltfm_data, so that OF version host and
data structure works can be saved, and pltfm version works for both
* Add OF common helper stuff into sdhci-pltfm.c, and make OF version
sdhci drivers sdhci-of-esdhc and sdhci-of-hlwd become self
registered as well, so that sdhci-of-core.c and sdhci-of.h can be
* Consolidate the OF and pltfm esdhc drivers into one with sharing
the same pair of .probe and .remove hooks. As a result,
sdhci-esdhc-imx.c and sdhci-of-esdhc.c go away, while
sdhci-esdhc.c comes in and works for both MPCxxx and i.MX.
* Eliminate include/linux/mmc/sdhci-pltfm.h with moving stuff into
And the benefits we gain from the changes are:
* Get the sdhci device driver follow the Linux trend that driver
makes the registration by its own.
* sdhci-pltfm.c becomes simple and clean as it only has common helper
stuff there now.
* All sdhci device specific things are going back its own driver.
* The dt and non-dt drivers are consolidated to use the same pair of
.probe and .remove hooks.
* SDHCI driver for Freescale eSDHC controller found on both MPCxxx
and i.MX platforms is consolidated to use the same one .probe
The patch set works against the tree below, and was only tested on
i.mx51 babbage board, all other targets were build tested.
Comments are welcomed and appreciated.
PS: The first patch is a squashing of the patch set below, which was
posted for review a few days back.
[PATCH 0/5] make sdhci device drivers self registered
Some patches in this series are relatively large, involving more
changes than expected, I chose to not split considering they are
logically integral, and doing so can reduce the patch quantity much,
and make bisect much easier. But sorry for that it makes reviewers'
Shawn Guo (5):
mmc: sdhci: make sdhci-pltfm device drivers self registered
mmc: sdhci: eliminate sdhci_of_host and sdhci_of_data
mmc: sdhci: make sdhci-of device drivers self registered
mmc: sdhci: consolidate sdhci-of-esdhc and sdhci-esdhc-imx
mmc: sdhci: merge two sdhci-pltfm.h into one
drivers/mmc/host/Kconfig | 71 ++++---
drivers/mmc/host/Makefile | 17 +-
drivers/mmc/host/sdhci-cns3xxx.c | 68 ++++++-
drivers/mmc/host/sdhci-dove.c | 69 ++++++-
drivers/mmc/host/sdhci-esdhc-imx.c | 149 -------------
drivers/mmc/host/sdhci-esdhc.c | 412 ++++++++++++++++++++++++++++++++++++
drivers/mmc/host/sdhci-of-core.c | 247 ---------------------
drivers/mmc/host/sdhci-of-esdhc.c | 89 --------
drivers/mmc/host/sdhci-of-hlwd.c | 89 +++++++-
drivers/mmc/host/sdhci-of.h | 42 ----
drivers/mmc/host/sdhci-pltfm.c | 251 +++++++++-------------
drivers/mmc/host/sdhci-pltfm.h | 36 +++-
drivers/mmc/host/sdhci-tegra.c | 187 ++++++++++-------
include/linux/mmc/sdhci-pltfm.h | 35 ---
14 files changed, 912 insertions(+), 850 deletions(-)
In the scope of my work on systemtap, I would like to have a look to
its user-space instrumentation capabilities. Systemtap relies on
uprobes+utrace for that purpose so has anyone some feedback/global
view on these with regards to ARM ?
utrace did not make it into the mainline and would need more to
convince Linux. I have also seen that a utraceless uprobe is emerging.
There is also a PPA with a utrace enabled kernel but this is not covering ARM.
I am in parallel seeking info on utrace-devel mailing list.
thanks for any help
Hi there. I'm looking for areas where the toolchain could generate
faster code, and a good way of doing that is seeing how compiled code
does against the best hand-written code. I know of skia, ffmpeg,
pixman, Orc, and efl - what others are out there?
Thanks for any input,
Attached patch set has support for MPU DVFS (cpufreq) on OMAP4 and
these are rebased against latest .38 linaro kernel.
omap cpufreq driver changes are already posted to lo
(https://patchwork.kernel.org/patch/589081/) and OMAP4 DVFS layer
changes will be upstreamed once Basic DVFS framework is accepted.
Kindly let me know if you can merge these patches for .38 linaro kernel.
GCC 4.5 and up supports graphite optimization, and cloog and ppl
are required. This change attempts to support some combinations
of ppl and cloog/cloog-ppl libraries. Since cloog and ppl are
written in C++, it implies we might suffer from C++ ABI breakage
problems when host environment changes, that is a well-known issue
in GNU/Linux distributions. Thus, we have to drop runtime libstdc++
dependency by statically linking libstdc++.
PS: The attachment contains the patch against HEAD in Linaro's
android/toolchain/build.git, but please make yours comments via gerrit
since this change is generic in upstream.