On Friday 11 February 2011 06:16 PM, Albert ARIBAUD wrote: [snip...] >>> >>> Note also that there was a recent patch to ARM926's start.S (replacing >>> 'adr r1, _start' with 'ldr r1, _TEXT_BASE' at line 284). The same should >>> be done on arm1136. >> >> Is this going to happen for armv7 too? What is the real reason behind >> this proposal. What is the case when _start is not same as _TEXT_BASE(I >> looked at the archives but couldn't filter out the original discussion >> on this) > > The difference is that _TEXT_BASE always contains the link-time address > of _start, whereas references to _start may contain a different value if > the code is executed somewhere else than at the link-time address. > > /Normally/, u-boot should always execute first at the link-time address > -- that's a base constraint. > > /But/ this change makes it more resilient to out-of-link-time-address > execution, and I want, at some time in the future, to find a way for > u-boot to be able to start anywhere -- within reasonable limits: > anywhere in NOR for a NOR-based U-boot, anywhere in RAM for a RAM-based > U-boot, but I am not talking about a generic, > run-in-RAM-or-NOR-or-anywhere, binary. > > Yet. :) > >> I see a problem with that. _TEXT_BASE is based on >> CONFIG_SYS_TEXT_BASE. In our SPL's case CONFIG_SYS_TEXT_BASE indicates >> the TEXT_BASE for u-boot and *CONFIG_SYS_SPL_TEXT_BASE* indicates the >> TEXT_BASE for SPL. Both are defined and useful in SPL because one is >> used for linking SPL while the other is used while loading u-boot from >> MMC. So, CONFIG_SYS_TEXT_BASE used in the start.S of SPL will not be >> correct. > > The change I indicate is under the #else of a #ifdef CONFIG_NAND_SPL, so > it will not apply to SPL. Does that still cause an issue with armv7?
No. It doesn't. I am fine with this change if it applies only to u-boot. br, Aneesh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
