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

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

[Graeme Russ]

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.

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

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

Currently, BOOTCS is mapped from 0x38000000. My board has 512k Boot
Flash, so the BOOTCS PAR is 0x38000000 - 0x3807ffff. With U-Boot in
the upper 256k (puts the reset vector at fff0 for cpu startup), this
puts u-boot code at 0x38040000 (TEXT_BASE in config.mk).

The SDRAM for my board is 128MB starting at 0x00000000 (ending at
0x08000000)

My thought is to change TEXT_BASE to 0x08040000, keep BOOTCS at
0x38000000, copy 0x38040000 - 0x3807ffff to 0x08040000 - 0x0807ffff
as soon as I enter protected mode (and have access to all memory) and
have set up the SDRAM controller etc, then jump directly to the copy
in RAM. I would then have two copies of u-boot in memory - One in RAM
at 0x08040000 and one in ROM at 0x38040000.

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

Does all this sound logical? viable? sensible? practical?

Regards,

Graeme

[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

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

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

[Graeme Russ]

I seem to be getting into a habit of (partially) answering my own
questions, but I figure these self answered questions may help
someone in the future...

Firstly, the i386 port definitely does not relocate - Two sources of
proof -1) /cpu/i386/start.S is where bss and data get initialised in
RAM with no copy of .text and 2) the startup banner gives it all away

U-Boot code: 38040000 -> 3805158F  data: 00400000 -> 00400A57
            ^^^^^^^^^^^^^^^^^^^^

       BSS: 00400A58 -> 00404463 stack: 00404464 -> 0040C463


start.S sets up the stack, copies .data & .got to 0x400000, and
clears .bss

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

[Graeme Russ]

I seem to be getting into a habit of (partially) answering my own
questions, but I figure these self answered questions may help
someone in the future...

Firstly, the i386 port definitely does not relocate - Two sources of
proof -1) /cpu/i386/start.S is where bss and data get initialised in
RAM with no copy of .text and 2) the startup banner gives it all away

U-Boot code: 38040000 -> 3805158F  data: 00400000 -> 00400A57
             ^^^^^^^^^^^^^^^^^^^^

        BSS: 00400A58 -> 00404463 stack: 00404464 -> 0040C463


start.S sets up the stack, copies .data & .got to 0x400000, and
clears .bss

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

[Graeme Russ]

Sorry, but the mailing list seems to keep cutting off half my
message at one of the blank lines - deleting them

I seem to be getting into a habit of (partially) answering my own
questions, but I figure these self answered questions may help
someone in the future...

Firstly, the i386 port definitely does not relocate - Two sources of
proof -1) /cpu/i386/start.S is where bss and data get initialised in
RAM with no copy of .text and 2) the startup banner gives it all away

U-Boot code: 38040000 -> 3805158F  data: 00400000 -> 00400A57
             ^^^^^^^^^^^^^^^^^^^^

        BSS: 00400A58 -> 00404463 stack: 00404464 -> 0040C463


start.S sets up the stack, copies .data & .got to 0x400000, and
clears .bss

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

[yusuf khan]

Hi Graeme

you can have a look at cpu/pxa/start.S, in this it relocates the complete
code including .text to ram.
I dont think you need to do anything in the compiler or linker.
Ya man it works,   i have already ported u-boot on two boards

-- 
Thanks & Regards

Yusuf A Khan
Multitech Software Systems
Koramangala,Bangalore