Le 16/09/2010 07:09, Heiko Schocher a écrit :
Hello Albert,
Albert ARIBAUD wrote:
Le 11/08/2010 20:16, Heiko Schocher a écrit :
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 54519b0..88c6427 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c
+init_fnc_t *init_sequence[] = {
Tested this code tonight, and I noticed that if the image is run from another location than the one it was linked for, then access to init_sequence is not made at the right location. To get correct access regardless of the image location, init_sequence has to be defined const.
Hmm.. at this place code is not relocated! So it should be executed on the right address. Don;t know, if this would be the only problem, if you run this code from another address ...
Well, the main goal of -fPIC is that the code should be able to run from anywhere, so it should be able to run from anywhere in FLASH. Besides, that can be useful for designs where two (possibly differently built) images of u-boot are located in FLASH and some mechanism allows booting from either.
(I personally have another motive for having at least the _f part of u-boot able to run fully PIC, as I want to implement direct-to-u-boot resetting on targets that have a reset vector rather far away from the end of the addressable space but too near to fit u-boot in, e.g. the orion5x which resets as 0xffff0000: 64 KB is too small for u-boot. I have submitted a patch for this then withdrawn it because of the relocation patches; however for this conversation, we can keep this point aside)
As for what would or would not work, ATM it boils down to 'access to const variables will be position-independent, access to others will not'. Non-initialized as well as initialized-but-not-const globals are always accessed at their link location before and after relocation, and thus will work only if you're running the image at its linked location.
This means that non-const data obviously can't work when the image is linked to FLASH; and they can even wreak havoc if the image linked for RAM and relocated near, but not exactly at, its linked location. The fact that it did not break so far in u-boot without reloc (and yes, several drivers do access globals during in-FLASH board init) is due to the fact that DRAM is already initialized when drivers access these globals at their linked location; this breaks when the image is linked for a location in FLASH.
Of course solving the init data issue (by making them const) will not solve the issue of rw data. For this one I see two solutions:
1) forbid using such data in drivers during _f phase if that is possible. For instance, in the timer.c driver of orion5x, the timer_init code accesses two writable variables because it wants to have a first reference for rollover detection; this can obviously be postponed to the _r init phase.
2) in case where the _f phase *has* to store data in globals, then this data should go to the globals space allocated below the stack, where gd also resides, and be later copied to usual globals if reqired.
BTW, the comments in board.c say that the _f init functions receive a pointer to gd; actually they dont, they're int (*) (void). Were the comments always out-of-sync with the code, or was there a removal of the gd argument for some reason?
Amicalement,