image/wrapper script questions

[Grant Likely]

(Adding cc:devicetree-discuss)

On Mon, Jul 27, 2009 at 2:15 PM, Eddie Dawydiuk <eddie at embeddedarm.com> wrote:
> Thanks for the link. Although, I'm not looking for info on optimizing
> boot time. Rather I'm looking for information on what the path of least
> resistance is to boot a kernel with an initrd being loaded from it's
> own partition. To clarify currently I am using a simpleImage.initrd which
> is a single image with the flattened device tree, kernel, and initial
> ramdisk in a single file. One can simply load this image in RAM(assuming
> 1 to 1 MMU mapping) and jump into it. Now what I would like to do is to
> load a kernel, device tree, and initial ramdisk into RAM at different
> locations.

Quick word of warning, if you do split the kernel and .dtb images (which
is a good thing to do for several reasons, and I strongly recommend it),
make sure you do *not* hard code the .dtb image into firmware.  If the
end user isn't able to update the .dtb image as easily as updating the
kernel image, then you are asking for a world of hurt for yourself and
your users.

> I'm in the process of coming back up to speed on the low-level boot
> details of the powerpc kernel/architecture. It looks like one can
> accomplish this by loading R3 with the phys address of the device
> tree block, R4 with the phys address of the kernel, and R5 with Null.
> It also looks like the kernel, already has several routines which know
> about these details(prom_init() and __start()) and I was hoping I could
> reuse this code to accomplish this rather than rewriting the bootrom to
> handle this. That is I was hoping there is a boot wrapper image that
> would allow me to accomplish my goal of creating a single image
> containing a kernel and device tree block, and an interface to specify
> where the bootrom loads the initial ramdisk in RAM. I'll continue
> reading through the docs and code, but if anyone could provide any
> pointers on how to do this I would really appreciate it.

It really sounds like you're asking for a new board-specific dtbImage
(which is what dtbImages are designed for).  simpleImage is really just
a dtbImage with the assumption that firmware provides no boot information.

*HOWEVER* dtbImages were really designed for older firmware that cannot
handle the kernel and .dtb images separately.  If you've got control of
the firmware then I strongly recommend *not* relying on the dtbImage
approach of binding the device tree into the kernel image.  You ignore
a lot of the advantages of the device tree model if you do.  In particular
you take on maintenance of a new dtbImage variant in the kernel tree and
loose the ability to build and boot a more or less 'standard' 440 kernel
image.

Honestly, I think you'd be better off adapting your firmware to parse and
boot either a raw vmlinux elf image or a u-boot uImage wrapped image and
pass in the .dtb and initrd pointers.  I predict it will result in far
less confusion for your users (they don't need to know about a particular
'dtbImage.<board>', less maintenance pain for you, and less cursing from
the rest of the powerpc community about an oddball firmware that behaves
differently from everything else (from a boot perspective).

In other words, don't try to adapt the kernel boot to your firmware;
adapt the firmware to an established boot mechanism.

g.

--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.