[U-Boot-Users] do_bootm_linux OF_FLAT_TREE

[U-Boot-Users] do_bootm_linux OF_FLAT_TREE

[David Updegraff]

Hi.

in common/cmd_boot, around line 624:

Looks like there is a small hole in the logic here if you happen to want
to boot with a MULTI image with a ptr. and  flat_tree.  Since
	"boot multi_img_addr - of_tree_addr"
ends up falling into the 'Skipping initrd category'.  Which is annoying,
as it looses the initrd that is inside the MULTI img.

An obvious solution does not pop out at me.

Maybe special-case check for MULTI within that special-case of FLAT_TREE
and argv=='-' ?

Please suggest better way.  Thnx.

-dbu.

[U-Boot-Users] do_bootm_linux OF_FLAT_TREE

[Kumar Gala]

On Jan 3, 2007, at 1:18 PM, David Updegraff wrote:

> Hi.
>
> in common/cmd_boot, around line 624:
>
> Looks like there is a small hole in the logic here if you happen to  
> want
> to boot with a MULTI image with a ptr. and  flat_tree.  Since
> 	"boot multi_img_addr - of_tree_addr"
> ends up falling into the 'Skipping initrd category'.  Which is  
> annoying,
> as it looses the initrd that is inside the MULTI img.
>
> An obvious solution does not pop out at me.
>
> Maybe special-case check for MULTI within that special-case of  
> FLAT_TREE
> and argv=='-' ?
>
> Please suggest better way.  Thnx.

When I implemented this I felt that it was an all or nothing  
situation.  Either you specified the memory locations of the kernel,  
initrd, and dtb or you used a single MULTI image.

One problem was that the MULTI image doesn't include any header  
information to know what the "sections" of the image are.

- k

[U-Boot-Users] do_bootm_linux OF_FLAT_TREE

[David Updegraff]

Kumar Gala wrote:
> 
> On Jan 3, 2007, at 1:18 PM, David Updegraff wrote:
> 
>> Hi.
>>
>> in common/cmd_boot, around line 624:
>>
>> Looks like there is a small hole in the logic here if you happen to want
>> to boot with a MULTI image with a ptr. and  flat_tree.  Since
>>     "boot multi_img_addr - of_tree_addr"
>> ends up falling into the 'Skipping initrd category'.  Which is annoying,
>> as it looses the initrd that is inside the MULTI img.
>>
>> An obvious solution does not pop out at me.
>>
>> Maybe special-case check for MULTI within that special-case of FLAT_TREE
>> and argv=='-' ?
>>
>> Please suggest better way.  Thnx.
> 
> When I implemented this I felt that it was an all or nothing situation. 
> Either you specified the memory locations of the kernel, initrd, and dtb
> or you used a single MULTI image.
> 
> One problem was that the MULTI image doesn't include any header
> information to know what the "sections" of the image are.
> 
> - k

Right...  but the _assumption_ everywhere in *_bootm seems to be that
	MULTI = kernel + initrd
so my view would be to not introduce another [unfounded?] assumption
that .. eg. MULTI = kernel + initrd + dtb.  So; yes; it'd be maybe nice
to have the picking apart of MULTI off in its own func so its done
consistently..   or, at a cost of more duct-tape, but less overall
impact-full might be enclosed patch.

I dunno; still hoping & searching for a less-duct-tape solution.

-dbu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multi-dtd.patch
Type: text/x-patch
Size: 1101 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070105/9bc5b1d6/attachment.bin 

[U-Boot-Users] do_bootm_linux OF_FLAT_TREE

[Wolfgang Denk]

Dear David,

in message <459E6DC3.9040900@cray.com> you wrote:
> 
> Kumar Gala wrote:
...
> > When I implemented this I felt that it was an all or nothing situation. 
> > Either you specified the memory locations of the kernel, initrd, and dtb
> > or you used a single MULTI image.

That was what I had in mind, too, when we discussed this.

I have to admit that I missed this special case, too.

> Right...  but the _assumption_ everywhere in *_bootm seems to be that
> 	MULTI = kernel + initrd

Ummm... this may look like an assumption, but it ain't so. It's  just
that this was the only useful application of multifile images so far.
My intention however has always been to extend this if it should ever
be needed - like now.

> so my view would be to not introduce another [unfounded?] assumption
> that .. eg. MULTI = kernel + initrd + dtb.  So; yes; it'd be maybe nice

That's what was discussed, and agreed on, before.

> to have the picking apart of MULTI off in its own func so its done
> consistently..   or, at a cost of more duct-tape, but less overall
> impact-full might be enclosed patch.
> 
> I dunno; still hoping & searching for a less-duct-tape solution.

Maybe we should make this duplicated code a separate function so we
can use something like "len = find_initrd (hdr, &data);" or so?


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
How can you tell when sour cream goes bad?

[U-Boot-Users] do_bootm_linux OF_FLAT_TREE

[David Updegraff]

W.

hmm.. I kind was off on the tangent that I thought Mr. Gala had
suggested of having some way to "know" what kind of images were in that
MULTI  (how? mini-headers? magic-bytes?) and cope..  But maybe an
agreed-upon order is ok too.  But is friday.. brain shutting down...

> Dear David,
> 
> in message <459E6DC3.9040900@cray.com> you wrote:
>> Kumar Gala wrote:
> ...
>>> When I implemented this I felt that it was an all or nothing situation. 
>>> Either you specified the memory locations of the kernel, initrd, and dtb
>>> or you used a single MULTI image.
> 
> That was what I had in mind, too, when we discussed this.
> 
> I have to admit that I missed this special case, too.
> 
>> Right...  but the _assumption_ everywhere in *_bootm seems to be that
>> 	MULTI = kernel + initrd
> 
> Ummm... this may look like an assumption, but it ain't so. It's  just
> that this was the only useful application of multifile images so far.
> My intention however has always been to extend this if it should ever
> be needed - like now.
> 
>> so my view would be to not introduce another [unfounded?] assumption
>> that .. eg. MULTI = kernel + initrd + dtb.  So; yes; it'd be maybe nice
> 
> That's what was discussed, and agreed on, before.
> 
>> to have the picking apart of MULTI off in its own func so its done
>> consistently..   or, at a cost of more duct-tape, but less overall
>> impact-full might be enclosed patch.
>>
>> I dunno; still hoping & searching for a less-duct-tape solution.
> 
> Maybe we should make this duplicated code a separate function so we
> can use something like "len = find_initrd (hdr, &data);" or so?
> 
> 
> Best regards,
> 
> Wolfgang Denk
>