[U-Boot] [Question] Driver-Model UART on NOR-boot ? Work?

[Simon Glass]

Hi Masahiro,

On 1 October 2014 10:27, Masahiro YAMADA <yamada.m at jp.panasonic.com> wrote:
>
> Hi Simon,
>
> 2014-10-02 0:31 GMT+09:00 Simon Glass <sjg at chromium.org>:
> > Hi Masahiro,
> >
> > On 1 October 2014 05:23, Masahiro Yamada <yamada.m at jp.panasonic.com> wrote:
> >> Hi Simon,
> >>
> >>
> >>
> >> I am looking at the driver-model serial code.
> >>
> >>
> >> I notice driver-model serial code uses ".data" section
> >> for storing the current device even before relocation.
> >>
> >>
> >> This code in drivers/serial/serial-uclass.c:
> >>
> >>   /* The currently-selected console serial device */
> >>   struct udevice *cur_dev __attribute__ ((section(".data")));
> >>
> >>
> >>
> >> In my understanding, we should not write any data to
> >> .data section before relocation.
> >>
> >>
> >> Let's say we are booting U-Boot from NOR flash.
> >>
> >> Before relocation, everything (including .data section)
> >> is placed on NOR flash which is read-only.
> >> (Please point out if I am wrong.)
> >>
> >> We are only allowed to write data to the stack, gd_t, bd_t
> >> and malloc area (if CONFIG_SYS_MALLOC_F_LEN is defined)
> >> before relocation, I think.
> >>
> >>
> >>
> >> I think that is why pre-driver-model serial uses a hard-coded
> >> default serial port before relocation.
> >>
> >>
> >>   This code in driver/serial/serial.c:
> >>
> >>      if (!(gd->flags & GD_FLG_RELOC))
> >>                 dev = default_serial_console();
> >>      else if (!serial_current)
> >>                 dev = default_serial_console();
> >>      else
> >>                 dev = serial_current;
> >>
> >>
> >>
> >>
> >> My question is,  does printf() work
> >> with driver-model UART and XIP device such NOR flash?
> >
> > The global_data structure needs to go somewhere, even before
> > relocation. On ARM this is general SRAM I suppose. In your case I
> > think you have some cache RAM to use. Do you use SPL?
>
> UniPhier SoCs support various boot-modes.
>
> I use SPL for NAND and MMC card boot, but I don't for NOR boot.
>
> For NAND boot or MMC card boot, yes,
> .data section is on some cache RAM, i.e. it is writable.
>
> For NOR boot, the program is running eXecutable-In-Place; therefore
> before relocation, .data section is remaining on NOR flash and it is read-only.
>
>

OK I see.

>
> > The pre-reloc malloc() area goes below global_data so uses the same mechanism.
> >
> > Yes it is true that strictly speaking we should not use data before
> > relocation. I suppose we could move cur_dev to global_data instead for
> > this particular case. It doesn't really scale to other drivers, but
> > then I expect that only serial needs to keep a 'current' pointer
> > before relocation, and even that will eventually go away once the
> > serial stuff is cleaned up.
> >
> > So let me know if that solution works.
>
> I think it will work.
>
> Moving cur_dev to struct global_data is easy.
> My concern is only that struct global_data is already too cluttered.
>

Oh well, at least there is only one now.

>
> Some other options I have come up with are:
>
> [1]
> Before relocation, cur_dev is set to a fixed-device by a board file.
> This is the same solution as pre-driver-model UART does.
>
> This would be unfortunate.  We are using Device-Tree more and more these days.
> Run-time choosing would be more flexible.

Agreed.

>
>
> [2]
> Make .data section writable even before relocation.
>
> The boot sequence would be:
>
>    1.   Copy .data to the temporary SRAM and clear .bss section
>    2.   board_init_f()
>    3.   Relocate all sections to SDRAM
>    4.   board_init_r()
>

There might be a lot of .data, and this feels like a
double-relocation. When moving .data we would need to fix up all the
relocations that refer to it, then fix the rest after the 'real'
relocation.

I prefer option [0] :-)

Regards,
Simon