From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Sat, 02 Oct 2010 11:08:23 +0200 Subject: [U-Boot] ARM relocation, question to Heiko In-Reply-To: <4CA6E8E5.2090605@emk-elektronik.de> References: <4CA49746.2050301@emk-elektronik.de> <4CA4AEFF.3050101@denx.de> <20100930174308.070ECD2B48C@gemini.denx.de> <4CA570D3.9040406@denx.de> <4CA57468.6090702@free.fr> <4CA57762.3000201@denx.de> <4CA5821E.3070108@emk-elektronik.de> <4CA5873B.6040907@free.fr> <4CA590E6.6070701@emk-elektronik.de> <4CA59B89.6090207@denx.de> <4CA5BB7A.8050304@emk-elektronik.de> <20101001105506.A64D41539A0@gemini.denx.de> <4CA5BFEF.3090208@emk-elektronik.de> <20101001112125.4076E153A7E@gemini.denx.de> <4CA5C7DE.6010300@emk-elektronik.de> <20101001115908.A34411539A0@gemini.denx.de> <4CA5D26D.2090505@emk-elektronik.de> <4CA5D857.5010009@emk-elektronik.de> <20101001125502.D0B4E1539A0@gemini.denx.de> <4CA6DC16.5040409@emk-elektronik.de> <4CA6E517.9040701@free.fr> <4CA6E8E5.2090605@emk-elektronik.de> Message-ID: <4CA6F687.1080600@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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