On 10/2/2010 3:17 AM, Joakim Tjernlund wrote:
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 ...
This pointer problem is solved with the fixup relocs on ppc and
should work without manual relocation. I think this is a ppc
only extension but I might be wrong.
Hi All,
You are correct that this is a ppc only extension. As such, it is
not a good candidate for "general" use.
I believe that the other alternative is to do it as x86 does
which I think is the general way which should work on any arch.
Graem Russ would know better.
Almost exactly a year ago, this was all pretty much presented by Graeme
in the threads
Relocation size penalty calculation (October 14, 2009)
i386 Relocation (November 24, 2009)
Using the full relocation scheme eliminates the need for all these
"fixups" in u-boot C code. I think this is a very desirable result.
It is also not clear to me that hard coding in the relocation as several
C routines will produce a u-boot that is "smaller" than the one
produced by using normal ELF relocation. However, using full relocation
creates an environment that is true "C" and does not rely on people
remembering that they may have to fix up some parts of their code. It is
hard to see much downside in using the full relocation capability
provided by Graeme's code.
FWIW, the relocation code and data does not have to be moved into ram if
space is at a premium.
Best Regards,
Bill Campbell
Jocke
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
