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

[Graeme Russ]

Thanks again for you rapip response Jerry

On Mon, Sep 22, 2008 at 3:29 AM, Jerry Van Baren <gvb.uboot at gmail.com> wrote:
> Graeme Russ wrote:
>>
>> 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.

One of these ports is not like the other :) - Your response got me
looking a bit deeper and, as far as I can tell, i386 does not relocate.

I can find no references to relocate_code () in the i386 port (or any
other variation of 'relocate')

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

Hmmm - If it doesn't (and I am sure it doesn't) my next layer is why
does the linker map the command table to 0x540 and how is the command
table supposed to get there? Is 0x540 relative to a segment (Stack,
Data, BSS)? or is an absolute memory address?

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

I think this is starting to get well beyond my current abilities. It
appears to me that the standard relocation methodology for U-Boot is
to block copy the flash image and then process some form of 'fixup'
table to adjust absolute address references (command table for
example?)

If this is the case, how is this fixup table created and maintained?

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

The real to protected mode jump is already there and yes, it is a total
PITA.

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

Regards,

Graeme