[U-Boot] [PATCH 03/10] x86: Permit bootstage and timer data to be used prior to relocation

[Simon Glass]

Hi Graeme,

On Wed, Dec 19, 2012 at 1:39 PM, Graeme Russ <graeme.russ at gmail.com> wrote:
> Hi Simon,
>
> On Wed, Dec 19, 2012 at 12:32 PM, Simon Glass <sjg at chromium.org> wrote:
>> Hi Graeme,
>>
>> On Fri, Dec 14, 2012 at 2:35 PM, Simon Glass <sjg at chromium.org> wrote:
>>>
>>> Hi Graeme,
>>>
>>>
>>> On Fri, Dec 14, 2012 at 2:15 PM, Graeme Russ <graeme.russ at 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 <sjg at 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.
>
> I'm trying to remember the context of my comment regarding only having
> coreboot boards. But anyway, not having any writeable data prior to
> relocation (other than the stack and gd) is a fundamental principle
> that we cannot simply avoid (although I must admit I don't know what
> the go is with SPL and U-Boot relocation).
>
>> Any thoughts on this point, please? I presume at least I can use RAM once
>> dram_init() is called. But when running from coreboot the RAM is already set
>> up...
>
> You will need to use global data to store the static variables. That's
> what the other arches do

That line is blurred a bit now, but OK I will do that. I will put this
series on hold until we see what happens with the arch-specific
global_data series.

Regards,
Simon

>
> Regards,
>
> Graeme