Which MLO & uboot & kernel combination works and which has which symptoms

GoogleGroups
1

Sorting out the various issues we actually observe with various MLO & uboot & kernel combinations on Beagle, yesterday at IRC there was the idea to track the various combinations and their symptoms [1]. With something like a table/matrix with working/not working MLO & uboot & kernel combinations, we hopefully will get a better overview. And then a better idea about the root causes of some issues :wink: This table/matrix should contain pointers to the working/not working MLO & uboot & kernel versions, too. To not loose the overview, the number of combinations have to be limited, though.

Currently I'm aware of the following (main*) MLO & uboot & kernel versions (MLO & uboot have to fit together):

a) "Default" MLO & uboot (381 MHz, L2 cache at kernel jump disabled)

http://beagleboard.googlecode.com/files/MLO
md5sum: 6a9f907d630de81f0b8ee8398cf94cf6

http://beagleboard.googlecode.com/files/u-boot.bin
md5sum: 249bb0e452b60dce6560fbb54c4de844

b) "500MHz" MLO & uboot (L2 cache at kernel jump disabled)

http://www.beagleboard.org/uploads/20080428/MLO
md5sum: fd4bd040dd000158952b67b743a5eb9c

http://www.beagleboard.org/uploads/20080428/u-boot.bin
md5sum: 11c59086892cf617ae4f6399672699e0

c) "2.6.22 WTBU" kernel

http://www.beagleboard.org/uploads/2.6_kernel-beagle-rev2.tar.gz

d) "OMAP git" kernel

http://source.mvista.com/git/?p=linux-omap-2.6.git;a=summary

Note: http://marc.info/?l=linux-omap&m=121044717627466&w=2

Runtime version checking: As clock and L2 cache seem to have big influence, we should always check/identify them at runtime. For clock I propose to use BogoMIPS (379.19 == 381 MHz, 499.92 == 500MHz). The WTBU kernel doesn't seem to have this nice "Clocking rate (Crystal/DPLL/ARM core): 26.0/332/500 MHz" output from git kernel.

For L2 cache I propose to apply my kernel patch [2] and observe the output.

Additionally, we should ensure that our boards have no known HW issues and HW errata 2 & 4 [3] are fixed on the board used for testing. Revision A5 boards should have both fixed, but re-checking can't be wrong :wink:

Best regards

Dirk

*Note: "main" versions: Not using binaries, but self compiled versions, there may be differences (toolchain, additional patches)

[1] http://www.beagleboard.org/irclogs/index.php?date=2008-05-10#T12:50:54

[2] http://marc.info/?l=linux-omap&m=121048635730217&w=2

[3] http://elinux.org/BeagleBoard#Hardware_2

2

Jason,

yesterday [1], you mentioned that your combination WTBU .22 with 500 MHz MLO, uboot and L2 on works fine.

If you have some time, maybe you kindly can check two things?

- Does "cat /proc/cpuinfo" work for your above combination?

- Do you like to apply my patch [2] to your WTBU .22 kernel and verify that L2 is really on?

Many thanks!

Dirk

[1] http://www.beagleboard.org/irclogs/index.php?date=2008-05-10#T12:46:09

[2] http://marc.info/?l=linux-omap&m=121048635730217&w=2

Dirk Behme wrote:

3

Jason,

yesterday [1], you mentioned that your combination WTBU .22 with 500
MHz MLO, uboot and L2 on works fine.

If you have some time, maybe you kindly can check two things?

- Does "cat /proc/cpuinfo" work for your above combination?

- Do you like to apply my patch [2] to your WTBU .22 kernel and verify
that L2 is really on?

I made some progress in getting the boot process more stable for this
combination:

500 Mhz MLO:
fd4bd040dd000158952b67b743a5eb9c mlo
U-boot 1.3.2:
11c59086892cf617ae4f6399672699e0 u-boot.bin
Kernel 2.6.26rc1 (git revision cb170dcdce58d..) with dvi, rtc and l2-
cache-{enable,check} patches:

root@beagleboard:~# dmesg | grep "L2 cache" ; uname -
a
OMAP3 L2 cache enabled
Linux beagleboard 2.6.26-rc1-omap1 #2 Sun May 11 10:35:01 CEST 2008
armv7l unknown unknown GNU/Linux

If I remove power, insert SD card and insert power (mini-usb plug) I
get a good boot nearly every time, with musb, ehci, sd, rtc and DVI
working (ehci still crashes on high cpu loads like md5summing files on
SD). Reboot using sysrq-b or the reset button are more troublesome.
This all makes me suspect that both linux and the maskrom make (wrong)
assumptions in what state the TWL is.

regards,

Koen