Hi Masahiro,
On 1 October 2014 05:23, Masahiro Yamada yamada.m@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?
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.
Regards, Simon