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

[Masahiro YAMADA]

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.



> 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.


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.


[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()





-- 
Best Regards
Masahiro Yamada