[U-Boot] [RFC][PATCH 00/21] [x86] 'Comming of Age'

Joakim Tjernlund joakim.tjernlund at transmode.se
Sun Mar 28 12:06:15 CEST 2010


Graeme Russ <graeme.russ at gmail.com> wrote on 2010/03/28 09:38:47:
>
> Joakim Tjernlund wrote:
> >
> > Graeme Russ <graeme.russ at gmail.com> wrote on 2010/03/27 12:54:03:
> >> Joakim Tjernlund wrote:
> >>> I did a few months ago for MPC83xx and sent it to the list. There was some
> >>> discussion but in the end it wasn't applied because it was too invasive.
> >>> PPC is especially bad as it needs to relocate string literals too.
> >>>
> >> To implement full relocation, I simply need to add an additional parameter
> >> to this function which provides the 'link versus load' offset which will
> >> get applied to the 'load versus run' offset calculation
> >
> > Are we talking about the same thing? when you say "does not
> > need to be loaded at TEXT_BASE" you need something like my LINK_OFF patch,
> > otherwise I don't see how you can boot out of flash otherwise.
> >
>
> I realise now that we are not talking about the same thing. The x86 port
> always relocates into (and runs from) RAM. Only a very small stub is run
> from flash (SDRAM setup and sizing, copy to RAM, process relocation entries
> etc). This stub can be made fully relocatable while running from Flash
> (with a few tricks)

Have you tried that yet? This is exactly what LINK_OFF is for. Turns out that
there is more code than you think that is executed before relocation into RAM.
Perhaps your stub is very small and doesn't need the serial port or access to
EEPROM via I2C. That won't work in the long run though.

>
> By adjusting all position dependent code after copying into RAM, LINK_OFF
> is no longer needed
You don't need LINK_OFF for this, PPC already have this feature since it can
relocate into any RAM address.



More information about the U-Boot mailing list