[U-Boot] [PATCH v2 3/3] image: Allow images to indicate they're loadable at any address

[Stephen Warren]

(resending due to MIME encoding last time; sorry)

On 11/08/2011 04:50 AM, Wolfgang Denk wrote:
> Dear Marek Vasut,
> 
> In message <201111081235.05464.marek.vasut at gmail.com> you wrote:
>>
>> Ok, so guys ... let me ask a stupid question:
> 
> Not a stupid question at all.
> 
>> Will it be a problem to extend bootm (if not already done) to load zImages 
>> directly, with -z option for example ? Won't that satisty both parties -- 

I originally thought about a bootz command or extending bootm to support
zImages. It looked like coding that up would be significantly more
complex and invasive than extending uImages to support relative or
unspecified load addresses, and hence I naively imagined that such
patches were far more likely to be accepted. It's evident that I was
very wrong in that assessment.

> bootm is for uImage format.  I see no sense in "extending" it.

bootm already supports two completely different formats; legacy uImage
and FIT images. To me, it seems logical to simply add support for a
third image format for the kernel at least. Do you completely disagree
with this? Well, bootm would need to recognize raw (non-uImage-wrapped)
initrd and FDT blobs too, since currently bootm expects everything to be
uImage-wrapped.

> I already suggested to add a new command ("bootz" ?) that could be
> used to boot zImage files.

One potential advantage of extending bootz to recognize zImage directly
would be the re-use of the overall bootm flow and arch functions such as
arch/arm/lib/bootm.c:do_bootm_linux(). I /think/ that creating a new
separate bootz command would require duplicating a lot of code and might
make re-using do_bootm_linux() more complex, although again I'd need to
look at the code in more detail to say for sure.

Are you willing to entertain extending bootm to recognize a third image
format if this makes the patches less invasive, and/or leads to more
maintainable code?

-- 
nvpublic