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

[Nicolas Pitre]

On Mon, 7 Nov 2011, Wolfgang Denk wrote:

> Dear Marek Vasut,
> 
> In message <201111072204.41980.marek.vasut at gmail.com> you wrote:
> >
> > You have that runtime patching stuff in linux-arm-kernel now, there should be no 
> > problem with that anymore actually. So basically I understood there was an 
> > agreement to make special uImage/fitImage which ... oh doh, here is where I'm 
> > getting lost. Is it that the kernel will still be copied to address, but a 
> > relative one to where uImage is loaded -- and the entrypoint will be relative to 
> > that same address?
> 
> Relative to the start of the system RAM.
> 
> See
> http://thread.gmane.org/gmane.linux.ports.arm.kernel/117512/focus=119281
> 
> There are to interesting pieces of information nicely summarized:
> 
> 1) zImages are are relocatable. They should be loaded and started at
>    offsets between 32 KiB and 128 MiB in system RAM.
> 
> 2) Raw images (without the preloader) have to be started at a fixed
>    address, virt_to_phys(PAGE_OFFSET + TEXT_OFFSET), which usually is
>    at an offset of 32 KiB in system RAM (with very few exzceptions).
> 
> Both sitations can be handled perfectly find with offset addresses in
> the images.

No.  Please, we're trying to remove _all_ hardcoded addresses from the 
kernel boot process, absolute or relative.  This is why zImage can be 
loaded at practically any address.  If uImage insists on having a 
relative offset encoded into it, this is slightly better than the 
absolute address but not by much.  Having the ability to use the _same_ 
uImage file and load it at _different_ addresses as specified by an 
argument to the load command is highly desirable.  Pure zImage can do it 
already, so only u-Boot is imposing restrictions here.

> When building the images from the kernel Makefiles, we can also make
> sure that such architecture specific addresses are correctly set.

We don't want any hardcoded architecture specific address anymore.  
This is being removed from the kernel as we speak.  If I cannot use a 
totally generic way to not specify a load address (using -1 for example) 
with mkimage soon, I'll be forced to remove the uImage makefile target 
from Linux as it will simply be broken otherwise.

> This allows to boot such images without additional configuration or
> adjustment of load and start addresses in the boot loader.

This allows to boot such image on only one specific architecture if 
uImage must contain architecture specific addresses, be that absolute or 
relative.  Granted, a relative offset is less problematic than an 
absolute address, but it is a problem nevertheless.  Such architecture 
specific information must live with the boot loader (ideally as a 
script) and not embodied into an image that could otherwise be totally 
generic.

> With Stephen's new approach, we could only use the zImage approach,
> and we have to add additional configuration information to the boot
> loader.

Absolutely!  That is where that configuration information must be.  The 
bootloader is not generic since it must initialize a very specific piece 
of hardware.  It therefore makes sense to associate the per architecture 
details such as the best kernel load address with the bootloader, not in 
the image itself.

OTOH, the kernel must become as generic as possible.  Using DT plays a 
big role in this.  But not having a load address/offset encoded in the 
image is also part of this. Think of what mess a Linux distribution for 
ARM would otherwise have to carry when it must know that configuration 
information for each device it intends to support.  Having a single 
kernel binary for as many ARM devices as possible is what we're aiming 
for, and currently u-Boot is one of the obstacles.


Nicolas