[U-Boot-Users] do_bootm_linux OF_FLAT_TREE

David Updegraff dave at cray.com
Fri Jan 5 23:27:12 CET 2007


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 at 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
> 





More information about the U-Boot mailing list