simpleImage.XX and large kernels
John Williams
john.williams at petalogix.com
Tue Feb 9 10:12:58 EST 2010
Hi Wolfgang,
On Tue, Feb 9, 2010 at 8:48 AM, Wolfgang Denk <wd at denx.de> wrote:
>> I'm looking at the simpleImage.XXX make target (PPC 405/440), and it
>> seems that by default the arch/powerpc/boot/wrapper script places the
>> bootwrapper at 0x400000, effectively setting a limit on the maximum
>> bootable kernel size.
>>
>> For various reasons we'd like to be able to put a fairly complete
>> rootfs as an initramfs, which obviously blows past a 4Mbyte limit very
>> quickly. Short of adding a new 'platform' option and associated
>> hackery through the powerpc/boot Makefiles and wrapper, is there a
>> quick and clean way I can tell the boot wrapper to link at a higher
>> address?
>
> Is there any specific reason why you want to use simpleImage, instead
> of using a normal uImage either bundled with your ramdisk image as a
> classic multifile image, or (recommended) as a FIT image?
Yes, there are a few reasons, though not necessarily very strong ones!
Although we'll normally be using u-boot, I don't want to make it a
hard requirement. simpleImage's ability to boot directly with a DTB
already bundled is attractive in this regard.
Another reason is that for compatibility with our MicroBlaze flow
(which also uses a simpleImage target, although a MicroBlaze
simpleImage is actually vmlinux with the DTB stuffed into its own
section).
Also sometimes it's nice to have a single ELF or binary blob we can
just push over JTAG straight to the target. Having the DTB embedded
simplifies this process, no need to download vmlinux and DTB
separately, setup boot params etc.
I like FIT and think it's an elegant solution, I'm just a bit
reluctant to force its use. For deeply embedded and flash constrained
systems we sometimes have a requirement to bypass uboot and boot
directly.
I may have to rethink the boot strategy eventually but in the short
term, getting some control over simpleImage as per my original post
would be a good first step.
Regards,
John
More information about the Linuxppc-dev
mailing list