Hello Reinhard, Reinhard Meyer wrote: > Dear Albert ARIBAUD, >>> I try to understand how the relocation process could handle pointers (to >>> functions or other data) in const or data sections. >>> Your code cannot know what is data and what is a pointer that needs >>> adjustment? >>> >>> Best Regards, >>> Reinhard >> Hi Reinhart, >> >> Short answer - the relocation process does not handle pointers inside >> data structures. >> >> 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
The init_sequence should not called anymore after relocation, as it is the init_sequence ... or? >> tee-shirts I got :) >> >> 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: Yep, you have to fix these pointers after relocation ... > 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_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 > }; > > And I think there are more places of this type in u-boot... Yes, maybe. But relocation as I did for arm, also works on m68k, sparc, mips, avr32 and they must do also this fixups, so for common functions (except the new env handling, which I think got never tested on this architectures?) should work ... As I just searching in code: there is a env_relocate() function (which get called from arch/arm/lib/board.c board_init_r()), but it did not the necessary work for subcommandtable fixup... I think this should be the right place to do this ... or? bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot