image/wrapper script questions

image/wrapper script questions

[Eddie Dawydiuk]

Hello,

I'm working on a custom board using an AMCC 440EP that is using a proprietary 
bootloader(optimized for fast boot time). Currently our bootloader loads a 
simpleImage.initrd into RAM and jumps into it. I originally chose to use a 
simpleImage with an initial ramdisk embedded because it was the simplest 
solution to debug the hardware and get a kernel and initial ramdisk running for 
development. For production I would prefer to put the initial ramdisk on it's 
own partition to allow customers to easily modify the initrd without having to 
concern themselves with the details of how to recompile a kernel. Would you 
recommend using one of the existing images(e.g. boot wrapper) or modify the 
bootrom to load the PPC registers with the details of where to find the dts, 
kernel, and initrd?

Thanks for any suggestions :)

-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive              | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: image/wrapper script questions

[Wolfgang Denk]

Dear Eddie Dawydiuk,

In message <4A6DDF80.209@embeddedarm.com> you wrote:
> 
> I'm working on a custom board using an AMCC 440EP that is using a proprietary 
> bootloader(optimized for fast boot time). Currently our bootloader loads a 
> simpleImage.initrd into RAM and jumps into it. I originally chose to use a 
> simpleImage with an initial ramdisk embedded because it was the simplest 
> solution to debug the hardware and get a kernel and initial ramdisk running for 
> development. For production I would prefer to put the initial ramdisk on it's 

Hm... isn't that an oxymoron? Trying to optimize  for  speed  on  one
hand, and using an initrd which is one of the slowest ways to boot on
the other hand?

> Thanks for any suggestions :)

Use another file system (and another fstype) and separate it from the
kernel image.

See also http://www.denx.de/wiki/view/DULG/RootFileSystemSelection

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Computers are not intelligent.  They only think they are.

Re: image/wrapper script questions

[Eddie Dawydiuk]

Wolfgang,

> In message <4A6DDF80.209@embeddedarm.com> you wrote:
>> I'm working on a custom board using an AMCC 440EP that is using a proprietary 
>> bootloader(optimized for fast boot time). Currently our bootloader loads a 
>> simpleImage.initrd into RAM and jumps into it. I originally chose to use a 
>> simpleImage with an initial ramdisk embedded because it was the simplest 
>> solution to debug the hardware and get a kernel and initial ramdisk running for 
>> development. For production I would prefer to put the initial ramdisk on it's 
> 
> Hm... isn't that an oxymoron? Trying to optimize  for  speed  on  one
> hand, and using an initrd which is one of the slowest ways to boot on
> the other hand?

We advertise the amount of time from a cold boot until one is sitting at a 
command prompt(< 2 s). A Debian filesystem(from Nand or SD card) is then mounted 
in the background. This gives one the power of Debian in a very short amount of 
time. From a technical stand point we have to use an initial ramdisk as we are a 
member of the SD association so we signed an NDA agreeing not to release any 
details of the SD spec. As a result we have code we can't release under the GPL 
so we have to load a proprietary SD card driver as a module.

I guess it depends upon how you define boot, that is we define it as how long it 
takes to get to a Linux shell prompt :) Even without the licensing issue I'm not 
sure we could boot faster(by the definition above) via some other method. All of 
the products I've seen that advertise a fast Linux boot time, boot to an initial 
ramdisk.

http://www.mvista.com/press_release_detail.php?fid=news/2009/Ultra-fast-boot.html

>> Thanks for any suggestions :)
> 
> Use another file system (and another fstype) and separate it from the
> kernel image.
> 
> See also http://www.denx.de/wiki/view/DULG/RootFileSystemSelection

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.

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.

-- 
Best Regards,
________________________________________________________________
  Eddie Dawydiuk, Technologic Systems | voice:  (480) 837-5200
  16525 East Laser Drive              | fax:    (480) 837-5300
  Fountain Hills, AZ 85268            | web: www.embeddedARM.com

Re: image/wrapper script questions

[Grant Likely]

(Adding cc:devicetree-discuss)

On Mon, Jul 27, 2009 at 2:15 PM, Eddie Dawydiuk <eddie@embeddedarm.com> wro=
te:
> 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.=A0 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.