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

Nicolas Pitre
2011-11-07T22:57:32Z

On Mon, 7 Nov 2011, Wolfgang Denk wrote:

> Dear Marek Vasut,
>
> In message <201111072204.41980.marek.vasut@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