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?
could you please give some pointers to observe an overall status of
oprofile support on ARM A9 cores? IIUC, now it doesn't work
without oprofile.timer=1 kernel option, at least for Linus' tree;
searching gives a lot of discussion/patches fragments and similar
stuff, but I was unable to find a complete patch/git tree/whatever
else to try.
Thanks in advance,
During ELC a few people asked me if Linaro had something bigger than
nano and smaller than Ubuntu that they could use to build stuff. Of
course I said Android, but a lot of people actually want a regular
Linux platform where they can easily recompile what they need to hack
on, add their own libs and scripts and generally work in an "embedded,
cross build way." I know there's OpenEmbedded and I've heard of
something called "livebuild." Does anyone have anymore info? This
class of users is arguably the largest class of people using these
boards so creating something targeted at them would allow them to get
all the benefits of Linaro in a easy to use fashion.
Android Platform Team Lead, Linaro Platform Teams
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
v3 is rebased on top of the latest serial runtime
patches and boot tested with/without DT on OMAP4
SDP and OMAP4 Panda boards.
Patches can be found here..
I also had to pull in a fix for DT testing (already in linux-omap
master) which was missing as the serial runtime branch
was based on an older master commit.
Changes in v3:
-1- Rebased on latest serial runtime patches
-2- Minor typr fixes
Changes in v2:
-1- Got rid of binding to define which uart is console
-2- Added checks to default clock speed to 48Mhz
-3- Added compatible for each OMAP family
-4- Used of_alias_get_id to populate port.line
 git://gitorious.org/runtime_3-0/runtime_3-0.git for_3_3/lo_rc4_uartruntime
Rajendra Nayak (4):
omap-serial: Get rid of all pdev->id usage
omap-serial: Use default clock speed (48Mhz) if not specified
omap-serial: Add minimal device tree support
ARM: omap: pass minimal SoC/board data for UART from dt
.../devicetree/bindings/serial/omap_serial.txt | 10 +++
arch/arm/boot/dts/omap3.dtsi | 31 ++++++++
arch/arm/boot/dts/omap4.dtsi | 28 +++++++
arch/arm/mach-omap2/board-generic.c | 1 -
drivers/tty/serial/omap-serial.c | 80 +++++++++++++++----
5 files changed, 132 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/omap_serial.txt
I am forwarding the message to a couple mailing lists which might have
people interested on the Mono porting for ARM hard-float ABI.
2012/2/2 Jo Shields <directhex(a)apebox.org>:
> Right now, Mono is available in Debian armhf. This is a hack - what
> we're actually doing is building Mono as an armhf binary, but built to
> emit soft VFP instructions and using calling conventions and ABI for
> armel. This hack works well enough for pure cross-platform code (like
> the C# compiler) to run, but dies in a heap for anything complex.
> This situation is a bit on the crappy side of crap.
> In order for Mono on armhf not to be a waste of time, a "true" port
> needs to be completed. If I were to make a not-remotely-educated guess,
> I'd say it needs about 550 lines of changes, primarily the addition of
> code to emit the correct instructions feeling the correct registers in
> mono/mini/mini-arm.c plus a couple of tweaks to related headers.
> Upstream have also indicated that they're happy to provide guidance and
> pointers on how to implement this port, although they're unable to
> provide the requisite code themselves.
> Sadly, unless someone in the community is able to step forward and
> contribute here, it's only a matter of time before the armhf packages
> are rightfully marked RC-buggy, and 100+ packages need to be axed from
> armhf. This would make me sad.
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.
Changes since RFC:
*Changed the cpu cooling registration/unregistration API's to instance based
*Changed the STATE_ACTIVE trip type to pass correct instance id
*Adding support to restore back the policy->max_freq after doing frequency
*Moved the trip cooling stats from sysfs node to debugfs node as suggested
by Greg KH greg(a)kroah.com
*Incorporated several review comments from eduardo.valentin(a)ti.com
*Report time spent in each trip point along with the cooling statistics
*Add opp library support in cpufreq cooling api's
1) The generic cooling devices code is placed inside driver/thermal/* as
placing inside acpi folder will need un-necessary enabling of acpi code.
2) This patchset adds a new trip type THERMAL_TRIP_STATE_ACTIVE which passes
cooling device instance number and may be helpful for cpufreq cooling devices
to take the correct cooling action.
3) This patchset adds generic cpu cooling low level implementation through
frequency clipping and cpu hotplug. In future, other cpu related cooling
devices may be added here. An ACPI version of this already exists
(drivers/acpi/processor_thermal.c). But this will be useful for platforms
like ARM using the generic thermal interface along with the generic cpu
cooling devices. The cooling device registration API's return cooling device
pointers which can be easily binded with the thermal zone trip points.
4)This patchset provides a simple way of reporting cooling achieved in a
trip type. This will help in fine cooling the cooling devices attached.
Amit Daniel Kachhap (4):
thermal: Add a new trip type to use cooling device instance number
thermal: Add generic cpufreq cooling implementation
thermal: Add generic cpuhotplug cooling implementation
thermal: Add support to report cooling statistics achieved by cooling
Documentation/thermal/cpu-cooling-api.txt | 57 ++++
Documentation/thermal/sysfs-api.txt | 4 +-
drivers/thermal/Kconfig | 11 +
drivers/thermal/Makefile | 1 +
drivers/thermal/cpu_cooling.c | 484 +++++++++++++++++++++++++++++
drivers/thermal/thermal_sys.c | 165 ++++++++++-
include/linux/cpu_cooling.h | 71 +++++
include/linux/thermal.h | 14 +
8 files changed, 802 insertions(+), 5 deletions(-)
create mode 100644 Documentation/thermal/cpu-cooling-api.txt
create mode 100644 drivers/thermal/cpu_cooling.c
create mode 100644 include/linux/cpu_cooling.h