From mboxrd@z Thu Jan 1 00:00:00 1970 From: Masahiro YAMADA Date: Thu, 2 Oct 2014 01:27:55 +0900 Subject: [U-Boot] [Question] Driver-Model UART on NOR-boot ? Work? In-Reply-To: References: <20141001202307.90B5.AA925319@jp.panasonic.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Simon, 2014-10-02 0:31 GMT+09:00 Simon Glass : > Hi Masahiro, > > On 1 October 2014 05:23, Masahiro Yamada 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