[U-Boot-Users] 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.
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
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
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
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
participants (3)
-
David Updegraff -
Kumar Gala -
Wolfgang Denk