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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
