Hi Graeme,
On Fri, Dec 14, 2012 at 2:15 PM, Graeme Russ <graeme.r...@gmail.com> wrote:
> Hi Simon,
>
> On 15/12/12 08:13, Simon Glass wrote:
>> It is useful to be able to access the timer before U-Boot has relocated
>> so that we can fully support bootstage.
>>
>> Move the relevant variables to the data region to support this.
>>
>> Signed-off-by: Simon Glass <s...@chromium.org>
>> ---
>> arch/x86/cpu/coreboot/coreboot.c | 4 ++--
>> arch/x86/cpu/interrupts.c | 2 +-
>> arch/x86/lib/timer.c | 2 +-
>> 3 files changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/cpu/coreboot/coreboot.c
>> b/arch/x86/cpu/coreboot/coreboot.c
>> index 9c9431e..22474f5 100644
>> --- a/arch/x86/cpu/coreboot/coreboot.c
>> +++ b/arch/x86/cpu/coreboot/coreboot.c
>> @@ -68,8 +68,8 @@ int board_early_init_r(void)
>> void show_boot_progress(int val)
>> {
>> #if MIN_PORT80_KCLOCKS_DELAY
>> - static uint32_t prev_stamp;
>> - static uint32_t base;
>> + static uint32_t prev_stamp __attribute__((section(".data")));
>> + static uint32_t base __attribute__((section(".data")));
>
> NAK
>
> This may work for coreboot where SDRAM is already initialised and you've
> loaded U-Boot into RAM, but it will not work when U-Boot is in Flash as all
> sections (including .data) are read-only until after relocation.
>
> The stack and Global Data are the only guaranteed read/write locations
> prior to relocation
Ah yes, I was thinking of your comment that all boards would move to
use coreboot. If that is not the case, then I will need to add
something to global data for the timer. And I don't want to do that
while generic board is in progress since it creates conflicts.
Regards,
Simon
>
> Regards,
>
> Graeme
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
