Hi Benoît,
On Tue, 15 Oct 2013 13:07:53 +0200 (CEST), Benoît Thébaudeau benoit.thebaudeau@advansee.com wrote:
Hi Albert,
On Sunday, October 13, 2013 7:16:33 PM, Albert ARIBAUD wrote:
Hi Benoît,
On Sun, 13 Oct 2013 17:00:25 +0200 (CEST), Benoît Thébaudeau benoit.thebaudeau@advansee.com wrote:
Hi Albert,
On Sunday, October 13, 2013 9:10:28 AM, Albert ARIBAUD wrote: [...]
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 34f50b0..f8ac573 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -105,8 +105,8 @@ static int display_banner(void) { printf("\n\n%s\n\n", version_string); debug("U-Boot code: %08lX -> %08lX BSS: -> %08lX\n",
_TEXT_BASE,_bss_start_ofs + _TEXT_BASE, _bss_end_ofs + _TEXT_BASE);
(ulong)&_start,(ulong)&__bss_start, (ulong)&__bss_end);#ifdef CONFIG_MODEM_SUPPORT debug("Modem Support enabled\n"); #endif
This hunk and all the other hunks using _TEXT_BASE in the same way will introduce different resulting values than the original code for targets having different build-time and run-time addresses.
This is not too much of an issue for the debug() call here, but this may be more damaging for things like gd->reloc_off below.
Indeed build-time and run-time values might be different. Normally, U-Boot starts by being loaded at its build-time address and run from there (or directly run there if from NOR). At that point, its build- and run-time addresses coincide. then we reach relocation. Then U-Boot runs from top of RAM, with a run-time address different from its build-time one, bu with all base-address-dependent locations fixed by relocation, so again, run-time and (relocated) build-time values are equal.
That's not true for all values following relocation. E.g., in start.S, _TEXT_BASE is initialized to either CONFIG_SPL_TEXT_BASE or CONFIG_SYS_TEXT_BASE. Those are #defined, so _TEXT_BASE has the same value before and after relocation, and this value differs from &_start after relocation.
Indeed; however, I believe that in all cases where _TEXT_BASE contained CONFIG_{SYS,SPL}_TEXT_BASE, I replaced references to _TEXT_BASE with references to CONFIG_{SYS,SPL}_TEXT_BASE, which is a constant and thus will not be relocated. Unless I missed one, of course.
Similarly, in places where relocation-sensitive symbols are actually used to compute size, which is relocation-insensitive, we should not have any problems either.
IOW, this debug() line would use true build-time values if invoked before relocation, and actual run-time values after relocation, because the &symbol constructs would have relocation entries and thus be fixed during relocation.
This does not preclude corner-case situations where some in-relocation code requires knowing both the pre- and post-relocation addresses of a symbol; usually it's a matter of looking at the "in-RAM" U-Boot image vs the "in-FLASH" U-Boot image, e.g. when relocating, we copy U-Bootfrom "source" to "destination" and then fix relocation using the "source" relocation table, because there is no "destination" relocation table. Normally these corner-case situations only arise near the relocation code itself.
However, if e.g. some fields of this debug() call should be the "initial" addresses while the debug() is executed at "final" location, just point them to me.
board_init_f() is called before relocation, so as long as there is no target having different build- and run-time addresses at this point (which AFAIK is the case), the changes made to this function are safe.
And display_banner() is called from board_init_f(), so everything should be fine here.
Hence, we basically just have to make sure that there is no exception board here.
Agreed, although the only possible 'exception' would be some board code expecting relocation-sensitive symbols to keep their pre-relocation values after relocation, and I don't see why that would happen.
Thanks for your input.
Best regards, Benoît
Amicalement,