[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