[U-Boot] 'Relocation' for sc520 (i386) based boards

[Jerry Van Baren]

Graeme Russ wrote:
> Hi All,
> 
> I've been thinking about where U-Boot runs in memory on my sc520
> based board and it appears that it is always executing from ROM and
> I started pondering if I should attempt to relocate U-Boot into RAM.

Yes.  All u-boot ports that I am aware of relocate themselves and run 
out of RAM.

> Note: Please correct me if I am mistaken and U-Boot does indeed run
> from RAM on i386 / sc520

It should.  This may be the next layer of your onion.

> This, of course, would give me the benefit of having unfettered access
> to the flash that U-Boot is located on for things like environment
> storage, upgrade in place etc.
> 
> My thought is to not actually 'Relocate' U-Boot but to use a very
> handy feature of the sc520 - The ability to map the BOOTCS (Boot ROM
> Chip Select) to anywhere in memory using a PAR (Programmable Address
> Region).

I'm not competent to help/advise you on your sc520 BOOTCS feature, but 
would suggest that staying in the mainstream will be much easier in the 
long term.  The mainstream is to use the existing code to block copy 
u-boot to RAM, do some relocation fixups, and then run out of RAM.

[snip]

> One problem I can think of is that the linker will point all the jump
> labels into RAM - not an issue for the 16-bit code which uses relative
> jumps, but I think I may run into issues during the real to protected
> mode transition (far jump) which, by definition, has to happen before
> I get access to the full memory space. How do I tell the linker that
> these jumps should target 0x38040000+ and not 0x08040000+ ?

I'm not sure how this works for u-boot on an x86 target.  Fully 
relocatable is the preferable link policy.  IIRC, usually x86 programs 
can be linked to be fully relocatable - the code can exceed +/-32K and 
still work, as long as each call is within +/-32K of the target label.

There is a small piece of u-boot that runs in ROM that copies it to RAM 
and then does a jump to it.  This will have to be a far jump in x86.  I 
also recall that the transition from reset mode to full 32 bit mode is a 
real PITA (was there once, don't care to return ;-), but I would expect 
that already exists in the u-boot x86 port.  Actually, I would expect 
the transition to "protected" mode and the jump to RAM are one and the same.

Otherwise your execution location has to be fixed (in RAM) - it seems 
like some targets (arm?) have this limitation.

> Does all this sound logical? viable? sensible? practical?
> 
> Regards,
> 
> Graeme

Good luck,
gvb