A follow up question. With this method, the total image size (uncompressed) is limited to the 4MB (the link address of
the boot
wrapper)?
No.
Yes, unless you change the link address, or provide a vmlinux_alloc callback (which currently only happens on true OF, not cuImage).
Unless you're talking about the "(uncompressed)"? The limit applies to the uncompressed boot image -- anything that the bootwrapper itself is decompressing. It does not apply to any further uncompression of the ramdisk itself.
He should point the latter, "the total image size", including ramdisk. But the link address should be limited for the boot Image, not for the attached ramdisk.
Thanks for the clarification. Scott, so what are the things that the bootwrapper is decompressing? The kernel for sure. And anything else? I understand that the ramdisk image will be decompressed later when trying to boot it.
I have a large ramdisk image. The size of the image itself (i.e. the *.gz) is about 4MB. When the ramdisk was being decompressed in the later stage. It had the following errors. It seems to me that the ramdisk image somehow was corrupted. Did the script wrapper mess up the image? Is there any known bug in the wrapper? My kernel is 2.6.33. BTW the ramdisk image can be mounted properly if it's separated from the kernel image.
RAMDISK: gzip image found at block 0 uncompression error VFS: Mounted root (ext2 filesystem) readonly on device 1:0. Freeing unused kernel memory: 104k init EXT2-fs (ram0): error: ext2_check_page: bad entry in directory #336: : rec_len is smaller than minimal - offset=0, inode=0, rec_len=0, name_len=0 EXT2-fs (ram0): error: remounting filesystem read-only Kernel panic - not syncing: No init found. Try passing init= option to kernel. Call Trace: [c7821f30] [c0006cd8] show_stack+0x40/0x168 (unreliable) [c7821f70] [c001cefc] panic+0x8c/0x178 [c7821fc0] [c00026d4] init_post+0xe4/0xf4 [c7821fd0] [c01ee224] kernel_init+0x108/0x130 [c7821ff0] [c000dcc0] kernel_thread+0x4c/0x68 Rebooting in 180 seconds..
Thanks, -Shawn.