(Adding cc:devicetree-discuss) On Mon, Jul 27, 2009 at 2:15 PM, Eddie Dawydiuk <ed...@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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
