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

[Wolfgang Denk]

Dear Nicolas Pitre,

In message <alpine.LFD.2.02.1111071736280.3307 at xanadu.home> you wrote:
>
> > 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.  ...

I understand you are referring here to zImages only. Correct?

Or will raw images (without the preloader) be fully relocatable, too?

>                                        ...  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...

Why is it so important to load it at specific (different) addresses
when it can be started from any address?

Maybe this is a key point.  I simply fail to understand this.


> 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 

Also for raw images?

> 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.

Interesting argument.  Because you are fully flexible and can use any
address you cannot accept a make target that wraps your fully
relocatable image to load it on a specific address.  Now that makes
sense to me.

Or do I smell attempted extortion?


> 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 

Please explain _why_ you consider it a problem.  Describe use cases
where it doesn't work.

> specific information must live with the boot loader (ideally as a 
> script) and not embodied into an image that could otherwise be totally 
> generic.

Must it?  I don't see the need.  I don't even see the benefit.

> > 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.

Hm... if that is true, then it means we will have fully relocatable
raw images?

> 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.

Please explain which exact problems you see if Linux on ARM would by
default wrap the zImage into a relative uImage with load address =
entry point address at 32 KiB offset from start of system RAM?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Mistakes are often the stepping stones to utter failure.