[U-Boot] ARM relocation, question to Heiko

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <4CA6E8E5.2090605 at emk-elektronik.de> you wrote:
>
> > And yes, this means the content arrays of pointers such as init_sequence
> > is not relocated. Been there, done that, can give you one of the
> > tee-shirts I got :)

It should work.

Eventually we need to find out which sort of tweaking of compiler
and/or linker options is needed on ARM.

> > ATM I have not found a way to fix this, except making the code which
> > uses the pointers aware that the are location-sensitive and fix them
> > when using them.
> 
> That means that things like this cannot work (with relocation),
> unless adding the relocation offset before using the pointer:
> 
> const struct {
> 	const u8 shift;
> 	const u8 idcode;
> 	struct spi_flash *(*probe) (struct spi_slave *spi, u8 *idcode);
> } flashes[] = {
> #ifdef CONFIG_SPI_FLASH_SPANSION
> 	{ 0, 0x01, spi_flash_probe_spansion, },
> #endif
> #ifdef CONFIG_SPI_FLASH_ATMEL
> 	{ 0, 0x1F, spi_flash_probe_atmel, },
> #endif
> #ifdef CONFIG_SPI_FLASH_MACRONIX
> 	{ 0, 0xc2, spi_flash_probe_macronix, },
> #endif
> #ifdef CONFIG_SPI_FLASH_WINBOND
> 	{ 0, 0xef, spi_flash_probe_winbond, },
> #endif
> #ifdef CONFIG_SPI_FLASH_STMICRO
> 	{ 0, 0x20, spi_flash_probe_stmicro, },
> 	{ 0, 0xff, spi_flash_probe_stmicro, },
> #endif
> #ifdef CONFIG_SPI_FLASH_SST
> 	{ 0, 0xBF, spi_flash_probe_sst, },
> #endif
> #ifdef CONFIG_SPI_FRAM_RAMTRON
> 	{ 6, 0xc2, spi_fram_probe_ramtron, },
> # ifdef CONFIG_SPI_FRAM_RAMTRON_NON_JEDEC
> 	{ 0, 0xff, spi_fram_probe_ramtron, },
> # endif
> # undef IDBUF_LEN
> # define IDBUF_LEN 9 /* we need to read 6+3 bytes */
> #endif
> };

Well, please keep in mind that all this code is working find on
PowerPC, which has been using relocation right from the beginning.

It is my understanding that we don't suffer from this issue any more
on PPC - Peter Tyser posted relocation fixup patches for PPC about a
year ago or so.

I have to admit that I cannot remeber the final result of this
discussion (there were tool chain dependencies?), but IIRC this has
been solved for PPC.

We should do the same for AMR now.


Peter, could you please fill in the details of that old story?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
There is nothing in this world constant but inconstancy.      - Swift