[U-Boot] u-boot stack overwrites end ramdisk

Norbert van Bolhuis nvbolhuis at aimvalley.nl
Wed Mar 17 16:52:10 CET 2010


before I send a patch or whatsoever I'll explain what's wrong first,
maybe I overlook something.

I'm using u-boot v2008.10, customized for our PPC MPC8313 based board.
When booting a kernel (including ramdisk and dtb) space for cmdline
and board info is reserved (by arch_lmb_reserve->lmb_reserve) in unused
memory, unused as in "far enough below the current stack ptr".
far enough is implemented here as stack-ptr minus 1k.
Btw. arch_lmb_reserve is called from do_bootm->bootm_start.

In my case the 1k hard-coded in arch_lmb_reserve isn't enough. This
is because a little later that same do_bootm calls bootm_load_os->gunzip->inflate
to decompress the linux kernel. In my case inflate alone already uses
1328 bytes of stack space, this is more than the stack-usage of
bootm_start and arch_lmb_reserve together (40 + 32 bytes) + 1k.

Again a little later do_bootm calls do_bootm_linux->boot_body_linux->boot_ramdisk_high.
The ramdisk address in memory (aligned on 0x1000 boundary) is determined here,
boot_ramdisk_high calls lmb_alloc_base and it places the ramdisk as close to and below
the arch_lmb_reserve stack-ptr minus 1k.


This is what happens:

bootargs=mem=252M
initrd_high=0x0fc00000
autoload=no
ethact=TSEC0
.
.
.
 >
## Booting kernel from Legacy Image at 20200000 ...
    Image Name:   Linux-2.6.28
    Created:      2010-03-12   9:06:20 UTC
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    1459866 Bytes =  1.4 MB
    Load Address: 00000000
    Entry Point:  00000000
    Version:      0x01003120 (16789792)
    Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 20500000 ...
    Image Name:   uboot initramfs
    Created:      2010-03-12  10:17:54 UTC
    Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
    Data Size:    2411044 Bytes =  2.3 MB
    Load Address: 00000000
    Entry Point:  00000000
    Version:      0x01003120 (16789792)
    Verifying Checksum ... OK
## Flattened Device Tree blob at 204e0000
    Booting using the fdt blob at 0x204e0000
    Uncompressing Kernel Image ... OK
    Loading Ramdisk to 0f8c0000, end 0fb0ca24 ... OK
    Loading Device Tree to 00ffa000, end 00fff593 ... OK
.
.
.
checking if image is initramfs...it isn't (invalid compressed format (err=1)); looks like an initrd
.
.
.
RAMDISK: Compressed image found at block 0
RAMDISK: ran out of compressed data
invalid compressed format (err=1)
List of all partitions:
1f00            1792 mtdblock0 (driver?)
1f01             128 mtdblock1 (driver?)
1f02             128 mtdblock2 (driver?)
1f03            2944 mtdblock3 (driver?)
1f04             128 mtdblock4 (driver?)
1f05            4096 mtdblock5 (driver?)
1f06            2944 mtdblock6 (driver?)
1f07             128 mtdblock7 (driver?)
1f08            4096 mtdblock8 (driver?)
1f09            4096 mtdblock9 (driver?)
1f0a            2048 mtdblock10 (driver?)
1f0b            4096 mtdblock11 (driver?)
1f0c            2048 mtdblock12 (driver?)
1f0d            8192 mtdblock13 (driver?)
1f0e           65536 mtdblock14 (driver?)
1f0f          159744 mtdblock15 (driver?)
No filesystem could mount root, tried:  iso9660
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Rebooting in 180 seconds..



The lowest used stack address by u-boot was 0x0fb0c370. This overwrites
the end of the ramdisk (which ends at 0fb0ca24)

Depending of the rate of compression of the ramdisk and the env setting
initrd_high and how aligning to 0x1000 turns out this problem does
or does not occur.

So, how about raising the 1k space to 8k, that seems safe enough ?

---
N. van Bolhuis.



More information about the U-Boot mailing list