do_bootm_linux OF_FLAT_TREE
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.
Quoted 12 lines · 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. andflat_tree. Since
"bootmulti_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.
Quoted 7 lines
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
Quoted 20 lines · Kumar Gala
Quoted 10 lines · 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
"bootmulti_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.Quoted 6 lines
An obvious solution does not pop out at me.
Maybe special-case check for MULTI within that special-case of
FLAT_TREEand argv=='-' ?Please suggest better way. Thnx.
Quoted 8 lines
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
Dear David,
Quoted 2 lines · in message <[email protected]> you wrote:
Kumar Gala wrote:
...
Quoted 3 lines
Quoted 3 lines
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.
Quoted 2 lines
Right... but the _assumption_ everywhere in
*_bootmseems 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.
Quoted 2 lines
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.
Quoted 5 lines
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
Signature · 3 lines
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?
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...
Quoted 40 lines
Dear David,
Quoted 1 line · in message <[email protected]> you wrote:
Kumar Gala wrote:
...
Quoted 3 lines
Quoted 3 lines
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.
Quoted 2 lines
Right... but the _assumption_ everywhere in
*_bootmseems to be that
MULTI = kernel + initrdUmmm... 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.
Quoted 2 lines
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.
Quoted 5 lines
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