* [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work?
@ 2014-10-01 11:23 Masahiro Yamada
2014-10-01 15:31 ` Simon Glass
0 siblings, 1 reply; 6+ messages in thread
From: Masahiro Yamada @ 2014-10-01 11:23 UTC (permalink / raw)
To: u-boot
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?
Best Regards
Masahiro Yamada
^ permalink raw reply [flat|nested] 6+ messages in thread* [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? 2014-10-01 11:23 [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? Masahiro Yamada @ 2014-10-01 15:31 ` Simon Glass 2014-10-01 16:27 ` Masahiro YAMADA 0 siblings, 1 reply; 6+ messages in thread From: Simon Glass @ 2014-10-01 15:31 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? 2014-10-01 15:31 ` Simon Glass @ 2014-10-01 16:27 ` Masahiro YAMADA 2014-10-01 23:43 ` Simon Glass 0 siblings, 1 reply; 6+ messages in thread From: Masahiro YAMADA @ 2014-10-01 16:27 UTC (permalink / raw) To: u-boot Hi Simon, 2014-10-02 0:31 GMT+09:00 Simon Glass <sjg@chromium.org>: > 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? 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? 2014-10-01 16:27 ` Masahiro YAMADA @ 2014-10-01 23:43 ` Simon Glass 2014-10-02 5:18 ` Masahiro Yamada 0 siblings, 1 reply; 6+ messages in thread From: Simon Glass @ 2014-10-01 23:43 UTC (permalink / raw) To: u-boot Hi Masahiro, On 1 October 2014 10:27, Masahiro YAMADA <yamada.m@jp.panasonic.com> wrote: > > Hi Simon, > > 2014-10-02 0:31 GMT+09:00 Simon Glass <sjg@chromium.org>: > > 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? > > 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? 2014-10-01 23:43 ` Simon Glass @ 2014-10-02 5:18 ` Masahiro Yamada 2014-10-04 2:19 ` Simon Glass 0 siblings, 1 reply; 6+ messages in thread From: Masahiro Yamada @ 2014-10-02 5:18 UTC (permalink / raw) To: u-boot Hi Simon, On Wed, 1 Oct 2014 17:43:19 -0600 Simon Glass <sjg@chromium.org> wrote: > > > > > > 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. Do you expect any other drivers that must be bound before relocation? (except DEMO driver of sandbox) Only UART? Best Regards Masahiro Yamada ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? 2014-10-02 5:18 ` Masahiro Yamada @ 2014-10-04 2:19 ` Simon Glass 0 siblings, 0 replies; 6+ messages in thread From: Simon Glass @ 2014-10-04 2:19 UTC (permalink / raw) To: u-boot Hi Masahiro, On 1 October 2014 23:18, Masahiro Yamada <yamada.m@jp.panasonic.com> wrote: > Hi Simon, > > > > On Wed, 1 Oct 2014 17:43:19 -0600 > Simon Glass <sjg@chromium.org> wrote: > >> >> > >> > > 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. > > > > Do you expect any other drivers that must be bound before relocation? > (except DEMO driver of sandbox) > > Only UART? Mostly UART, but as more boards are added there may be others. For example, SPI and I2C, But none will need the 'current device' concept I think. And remember that serial likely only needs it for legacy reasons. Regards, Simon ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-10-04 2:19 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-10-01 11:23 [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? Masahiro Yamada 2014-10-01 15:31 ` Simon Glass 2014-10-01 16:27 ` Masahiro YAMADA 2014-10-01 23:43 ` Simon Glass 2014-10-02 5:18 ` Masahiro Yamada 2014-10-04 2:19 ` Simon Glass
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.