[U-Boot] [PATCH 12/26] ARM: add relocation support

[Graeme Russ]

On 16/09/10 18:23, Wolfgang Denk wrote:
> Dear Graeme Russ,
> 
> In message <AANLkTimDxzWm9-sekLv60-zNDFmBKE3dc=kxiO+ZqZZn at mail.gmail.com> you wrote:
>>
>>> I agree that it would be nice to have U-Boot completely position-
>>> independent and completelky restartable, but this would be a new
>>> feature, which newer existed before.
>>>
>>
>> x86 has a nice feature whereby I can build two images that differ only by
>> TEXT_BASE. I can build using TEXT_BASE somewhere in low memory, tftp the
>> image and the 'go' directly to the base address of the image
> 
> You can build such images for any architecture, but usually they will
> not work.
> 
> The code assumes to be started at the reset vector, and to find a CPU
> with all peripherals and registers in virgine state which is only
> present after a reset.
> 
> On many processors there are certain steps that are irreversiable by
> software - there are write-once registers, there are memory controller
> registers which change the behaviour of the memory controller when the
> are written for the first time, etc.

I have the same constraints. For example, I cannot reconfigure the DRAM
controller or perform memory sizing after tftp'ing the new image as they
are likely to destroy it.

> 
>> This works because the x86 reset vector is at top of memory (0xfffffff0),
>> not bottom (0x00000000) so the very first bytes of u-boot.bin are not the
>> reset vector, but rather where the reset vector jumps to after performing
>> some very low-level hardware init
> 
> The actual position of the reset vector in the address space has
> nothing to do with that isse. It's other things like register states

True, but it does make life easier to know the 'go' address is the same as
the load address

> or mode of operation of certain units (memory controller, MMU etc.)
> that are different when coming frash out of reset versus when coming
> from a running U-Boot systems.

I have a 'cold-boot' parameter which is set by the reset vector code. I can
use this to selectively skip 'once-only' initialisation

> 
>> As long as I do not mess with the low-level init code, I can be confident
>> that an image that 'boots' using the 'go' command will boot from Flash
> 
> This _may_ work on certain boards and processors, but it does not
> (and I think it cannot) work in general.

I don't doubt that you are entirely correct. But there are many ways to
skin a cat. My problem was to reduce the build->burn->boot development time
where the burn phase was the longest. The low level boot and device
initialisation all works and hasn't changed in quite a while, so I can rely
on what is on my (nearly a year) old image.

I don't see what I am doing as very far removed from the 'ipl' framework. I
have on my 'TODO' list to split the low-level init which always runs from
flash from the higher level code which runs relocated. From there, I can
create a fully position independent image which could be located anywhere
(on the boot flash, on other on-board flash, NAND device etc)

A common framework (within the bounds of cross-architecture limitations)
would be nice

Regards,

Graeme