Passing an initrd to a Linux kernel with Device Tree

[Grant Likely]

On Wed, Sep 21, 2011 at 8:25 AM, Nicolas Pitre <nico at fluxnic.net> wrote:
> On Wed, 21 Sep 2011, Dave P Martin wrote:
>
>>
>>
>> > -----Original Message-----
>> > From:
>> > devicetree-discuss-bounces+dave.martin=arm.com at lists.ozlabs.or
>> g [mailto:devicetree-discuss-> bounces+dave.martin=arm.com at lists.ozlabs.org] On Behalf Of
>> > Grant Likely
>> > Sent: 20 September 2011 21:11
>> > To: Olivier Martin
>> > Cc: devicetree-discuss at lists.ozlabs.org
>> > Subject: Re: Passing an initrd to a Linux kernel with Device Tree
>> >
>> > On Tue, Sep 20, 2011 at 06:46:22PM +0100, Olivier Martin wrote:
>> > > Hello,
>> > >
>> > > I tried recently to add support in UEFI to pass an initrd
>> > with FDT to
>> > > a Linux kernel. I have searched the Internet but I did not find any
>> > > information to do that.
>> > >
>> > > FYI, this is the way it is done in ATAG:
>> > > typedef struct {
>> > >   UINT32  start;
>> > >   UINT32  size;
>> > > } LINUX_ATAG_INITRD2;
>> > >
>> > > The boot loader loads the initrd in system memory and passes the
>> > > memory region information through ATAG.
>> > >
>> > >
>> > > Sorry, if it is the wrong mailing-list. In this case, can someone
>> > > point me on the right forum for any Linux FDT oriented questions.
>> >
>> > Hmmm, it may not be documented (the binding was implemented a
>> > long time ago before we got strict about documenting
>> > bindings).  The magic is two properties in the /chosen node;
>> > "linux,initrd-start" and "linux,initrd-end".  Each contains
>> > the physical start and end addresses of the initrd.
>>
>> What does "end address" mean here?
>>
>> It could be read as meaning either:
>>
>> a) address of the the final byte of the image
>> b) address of the first byte following the image (0 if the image ends at 4G)
>
> Looking at the code (remember this is always the ultimate
> documentation), end_address = start_address + size.  So (b) would be the
> right answer.

Yes, (b) is correct.  I lost 2 days of my life tracking down a bug
last year that turned out to be that I incorrectly assumed (a).

g.