Angstrom Demo boot issue with BB C4


I'm new to the BB. I went through the BB validation procedure fine.
However I'm now attempting to boot the latest Angstrom demo on a C4
board. I've setup a dual boot SDHD card that appears to be working /
mounting, etc. From there I was able to flash to nand, u-boot and MLO.
On boot, it loads the Angstrom uImage and eventually produces a kernel
panic shortly after loading the root fs from mmcblk0p2. Apparently
something with freeing init memory? The sequence is shown below.

[ 24.185089] Waiting for root device /dev/mmcblk0p2...
[ 24.477874] mmc0: new high speed SDHC card at address aaaa
[ 24.483947] mmcblk0: mmc0:aaaa SD04G 3.69 GiB
[ 24.488922] mmcblk0: p1 p2
[ 24.522277] kjournald starting. Commit interval 5 seconds
[ 24.529907] EXT3-fs (mmcblk0p2): using internal journal
[ 24.535247] EXT3-fs (mmcblk0p2): recovery complete
[ 24.540100] EXT3-fs (mmcblk0p2): mounted filesystem with writeback
data mode
[ 24.547302] VFS: Mounted root (ext3 filesystem) on device 179:2.
[ 24.555816] devtmpfs: mounted
[ 24.558898] Freeing init memory: 208K
[ 24.562622] Unable to handle kernel NULL pointer dereference at
virtual address 00000014
[ 24.570770] pgd = c0004000
[ 24.573486] [00000014] *pgd=00000000
[ 24.577087] Internal error: Oops: 5 [#1] PREEMPT
[ 24.581726] last sysfs file:
[ 24.584716] Modules linked in:
[ 24.587799] CPU: 0 Not tainted (2.6.32 #1)
[ 24.592285] PC is at musb_interrupt+0x9f8/0xbb8
[ 24.596862] LR is at musb_interrupt+0x9e4/0xbb8
[ 24.601409] pc : [<c0340df8>] lr : [<c0340de4>] psr: 60000193
[ 24.601409] sp : cf823e58 ip : cf823e90 fp : 000000f0
[ 24.612976] r10: 00000000 r9 : 00000099 r8 : 00000009
[ 24.618225] r7 : 00000000 r6 : cf82f108 r5 : 00000001 r4 :
[ 24.624786] r3 : 00000000 r2 : 00000000 r1 : fa0ab000 r0 :
[ 24.631347] Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM
Segment kernel
[ 24.638793] Control: 10c5387d Table: 80004019 DAC: 00000017
[ 24.644561] Process swapper (pid: 1, stack limit = 0xcf8222f0)
[ 24.650451] Stack: (0xcf823e58 to 0xcf824000)
[ 24.654846]
3e40: 35353532
[ 24.663055] 3e60: cf823ef0 00000000 00008000 cf82f108 60000113
cf8a0a00 cf822000 0000005c
[ 24.671295] 3e80: 00000000 00000000 c066cfc0 c034101c a0000013
cf8a0a00 c063a5d8 c00a4e90
[ 24.679534] 3ea0: c06c0fd0 cf8a0a00 c063a5d8 0000005c 00000003
00000002 cf822000 cf823f55
[ 24.687774] 3ec0: cf823f46 c00a7058 0000005c 00000000 cf823f55
c003c074 00003f84 ffffffff
[ 24.696014] 3ee0: fa200000 c003cb44 00000001 80000013 c063643c
c063643c 00000001 00000005
[ 24.704254] 3f00: cf823f55 c0682f23 0000001a 0000002f cf823f55
cf823f46 cf823f08 cf823f30
[ 24.712493] 3f20: c006e5e4 c006ecac 60000013 ffffffff cf823fd0
00000036 00000000 80000013
[ 24.720703] 3f40: 60000013 205b8c80 34322020 3835352e 5d383938
ffff0020 cf823fd0 c00f97f8
[ 24.728942] 3f60: cf80b140 cf4d9598 00000000 cf823f78 c009027c
c00631fc c0638320 00000780
[ 24.737182] 3f80: 00000034 00080008 000000d0 0000e900 00000001
0008003c c06b8228 c04875d0
[ 24.745422] 3fa0: 00000033 c0043028 c056d184 c05d533a 000000d0
0008003c 00000000 c0670d58
[ 24.753631] 3fc0: c00301ec 00000000 00000000 00000000 00000000
00000000 00000000 c003c4f0
[ 24.761871] 3fe0: c0670d58 c000845c 00000000 00000000 00000000
c003d9fc 00ffee00 04f6ff00
[ 24.770141] [<c0340df8>] (musb_interrupt+0x9f8/0xbb8) from
[<c034101c>] (generic_interrupt+0x64/0xa8)
[ 24.779418] [<c034101c>] (generic_interrupt+0x64/0xa8) from
[<c00a4e90>] (handle_IRQ_event+0xac/0x1ec)
[ 24.788787] [<c00a4e90>] (handle_IRQ_event+0xac/0x1ec) from
[<c00a7058>] (handle_level_irq+0xbc/0x148)
[ 24.798187] [<c00a7058>] (handle_level_irq+0xbc/0x148) from
[<c003c074>] (asm_do_IRQ+0x74/0x98)
[ 24.806945] [<c003c074>] (asm_do_IRQ+0x74/0x98) from [<c003cb44>]
[ 24.815002] Exception stack(0xcf823ee8 to 0xcf823f30)
[ 24.820068] 3ee0: 00000001 80000013 c063643c
c063643c 00000001 00000005
[ 24.828308] 3f00: cf823f55 c0682f23 0000001a 0000002f cf823f55
cf823f46 cf823f08 cf823f30
[ 24.836547] 3f20: c006e5e4 c006ecac 60000013 ffffffff
[ 24.841644] [<c003cb44>] (__irq_svc+0x44/0xa8) from [<c006ecac>]
[ 24.849639] [<c006ecac>] (vprintk+0x394/0x428) from [<c04875d0>]
[ 24.857360] [<c04875d0>] (printk+0x18/0x28) from [<c0043028>]
[ 24.865325] [<c0043028>] (free_initmem+0x98/0xc4) from [<c003c4f0>]
[ 24.873565] [<c003c4f0>] (init_post+0xc/0x188) from [<c000845c>]
[ 24.881805] [<c000845c>] (kernel_init+0xec/0x128) from [<c003d9fc>]
[ 24.890655] Code: e3530003 13a02000 05963078 05933018 (05d33014)
[ 24.896850] ---[ end trace c43eeeec88ece3aa ]---
[ 24.901519] Kernel panic - not syncing: Fatal exception in

Any ideas on what I'm doing wrong?


Try powering it from +5V instead of usb till we fix the power buglet.



Thanks. I'll give that a try. I need to track down a 5V with the right
male connector.


Try 5V supply, but I have had panics caused by a mismatch between
filesystem and kernel. The kernel uImage.bin you put in the boot
partition should be the one from /boot in the Angstrom filesystem.
Strange things can happen otherwise.

Hi all
i have a similar problem.

@wriba where you able to solve this problem ?

i am using the latest uImage and rootfs from

kindly help :frowning:


Does the validation kernel + ramdisk work OK?

If you boot with USB OTG not connected, is it more reliable? I had
trouble with the gadget composite driver which gets loaded by default
on that image. Seems it was causing a hang - but not this addres 0x14
issue. I have not seen that one. I also have a rev C4 board.

Unfortunately it is unlikely you will find much extra support for the
Angstrom image. The developers appear to have moved on and users are
encouraged to get into OpenEmbedded and built their own filesystem.

My best suggestion is to try power from 5V supply with USB OTG
disconnected from the host.

Really? I know nothing of such a directive and I am the lead developer for angstrom... We tell users to use narcissus to generate filesystems.


Did I mention a directive? I'm not sure of the point of contention here.

I'm going by what I see on this list. Admittedly I don't know the
Angstrom developers from a bar of soap so I'll admit to inaccuracy on
the point which I assume you're arguing about (Narcissus v
OpenEmbedded). However when I said "developers" I was not thinking
Angstrom developers, but those who I have visibility of on this list.
I cannot know their affiliation.

On this list I have not seen anyone take ownership of the angstrom
demo image. Who did build it? Who maintains it? AFAICT no-one has put
their name to it.
I have not seen anyone update its README to warn people of the common
mistake (I assume) of booting the beagleboard validation kernel
against the angstrom image despite a reasonable number of people
having that problem (me included).
In response to booting issues, several responses I have seen pushed
users toward later versions. Looked to me like no-one was supporting
2010.3. I think I can stick by my claim that developers have move on.

Watching the list traffic I worry that there is a schizm between the
experienced developers and beagleboard beginners. Please don't forget
what it is like to be starting out on a new platform. The beagleboard
angstrom demo is an excellent resource but it should not fall into
disrepair. It helped get me started quite quickly.

Personnally I have no clue about Narcissus. I've never used it and I
have no idea why I should and I'm not aware of any developer
preference towards Narcissus (which I promise I will investigate).
Most of the interesting information my research turned up has pointed
to OpenEmbedded. Has it been superseded?

For beginners Google turns up the beagleboard demo image and it looks
perfect when you know nothing about the platform and just want a place
to start. If there's something wrong with the demo image then I think
it should be fixed as a community service.

I look at it the other way, where does it say other kernels are supported? All the announcements specify mlo,uboot,uimage and filesystem for a reason.

Maybe I'm thinking to simple....

You're thinking like someone who knows what they're doing.

This is how it happened for me - roughly. I assume similar for other
beginners because I still don't see any logic error in what I did.

1. I have a board. How do I make it work? Beagleboard manual (SRM)
points to validation page [1, 1a] with kernel plus ramdisk.gz. OK
kernel boots, looks normal, great!
2. Now what? I need to find a more complete filesystem that is known
to work. Validation page [1] mentions beagleboard angstrom demo [2].
Sounds perfect!
3. It's a tarball to unpack into the rootfs partition. OK done. Let's
boot.... kernel panic. WTF?! I followed the instructions!
4. Email beagleboard list.

Beginners need a progression that leads them with confidence to the
point of building their own generic filesystems without requiring
list/group consultation and also establishes the project relationships
and requisite knowledge. I hope you will agree that this is an outcome
we want to promote.

IMO some work needs to be done to provide a guided learning curve.
I'll put my hand up to contribute some of that material. After all, if
you want to make a difference you have to put in the work; right?

So here's my proposal: the page pointed to by the beagleboard SRM for
board validation [1] points users to the angstrom demo page [2]. How
about I write a hundred words or so for beginners, then you (Koen
Kooi) review for correctness and utility and when it's ready it
replaces the existing ftp-style page. AFAICT the existing page text
come from the accident that a README exists. I assume that providing a
index.html would allow the HTML to be served instead.

I hope this will serve as a public service for beginners as well as an
education for me.

sounds like a good plan, go for it

... snip ...

  since i helped with some of the content at the latest validation
page, give me a day or so and i'll see if i can't tidy things up so
that it just *works*. i'll go back through this thread but, just to
be clear, what the validation page was meant to do was lead one
through the process by which one could get their freshly-unpacked
beagleboard up and running. is that the goal we're after here?

  in any event, feel free to post what you think is wrong or missing
on the validation page(s).


The main validation page appears to have been superseded. There are now

The one for rev C4 is actually RevCValidationv3. Confused yet?

Some appropriate cross-linking and prominent directions to appropriate
pages are required. That will take care of the mess at

On the angstrom side of things, there aren't sufficient instructions
on the /demo/beagleboard page to safely guide a beginner through the
steps of unpacking the demo image, booting and verifying operation. It
is this latter element I was going to work on.

OK. Should I mail you some text off-list or do the iterations here? Or, other?

i contributed specifically to the ...v3 page. are you saying that
those instructions somehow don't work? if not, i'll make sure the
instructions are fixed -- if i have time today, i'll hook up my C4
board and run through it.

  but go ahead and post what seems to work for you and i'll add
to that page whatever's missing.


No not at all. The v3 page is accurate and the files worked for me.

What I'm saying is that there is a confusing mess of older pages. If
you have a rev C4 board it is hard to find the right page because the
others exist and they do not all have cross-references to the v3 page
for rev C4 boards. I'd like to see all the other pages prominently
point to the correct page for rev C4.

ping jason on this as well, we had some internal discussion on killing all the code.Google pages and putting it next to the sources on gitorious

I also have this problem. The thing missing in the thread is what
solves the problem? Is it power or is it the image? Could someone
just post which image and kernel play nice with each other? Thanks!

You should be fine if you copy the uImage from the /boot directory in
the root filesystem into the boot partition, instead of using the
uImage from the online demo directory.


Correct. The validation kernel does not work with the Angstrom demo
filesystem. You must copy the uImage.bin out of the tarball (from
/boot) and put it in the boot partition, replacing the existing

You also need to rename ramdisk.gz to something else.