> From: Scott Wood [mailto:scottw...@freescale.com] > > > On Wed, 2013-09-25 at 22:08 +0000, Woodruff, Richard wrote: > > Short comment. Apologies for top posting: > > > > The first incarnations of SPL and loader mainly cared about the boot flash > device. > > Is there an SPL that cares about something other than the boot device > now? > AFAIK about SPL driver in drivers/mtd/nand/am335x_spl_bch.c This driver depends on CONFIG_SYS_NAND_xx for deriving all device parameter - CONFIG_SYS_NAND_BLOCK_SIZE - CONFIG_SYS_NAND_PAGE_SIZE - CONFIG_SYS_NAND_ECCSIZE - CONFIG_SYS_NAND_ECCBYTES
Thus, IMO SPL drivers are written for following two uses: (1) load secondary boot-loader, which can further do dynamic device probing And based on that enables some device specific features. (2) load linux kernel image directly (in falcon-mode SPL_OS_BOOT), which will reduce the boot-time as all configurations are static. So, in either usage SPL drivers need to be statically configured to keep their foot-print small and boot them fast. > > OMAPs require a resistor strap to specify the width of the boot device. The > values is latched for SW to read. > > > > As such always a run time check of width was sufficient for boot device. > > > > On dev board we would have many devices and use DIP switch to select > which one was in use. A run time not compile time was way to support this. > > > > If information is dynamically available it is better to use this if focus > > is boot > device management. > > Agree, This was done on TI814x EVM boards which are development boards. but if you refer actual production board (custom boards of end-user), having even a single extra resistor means adding BOM cost. Also in production boards everything is known, (like NAND bus-width, page-size, etc), so dynamic detection becomes redundant because linux would anyways re-do the device probing when it boots. And if anyone really wants to do dynamic device probing in u-boot. Then go till u-boot second stage which has most of device probing capabilities same as linux kernel. (atleast in case of NAND driver). > > Other tricks writing patterns and reading results is also possible but > simplicity of compile vs. that is debatable. > > > > Regards, > > Richard W. > > I agree. Outside of SPL (where hardcoding can be useful due to size > constraints, and you only care about the boot device), it's best to let > drivers determine the best way to learn about such configuration. > > > From: Gupta, Pekon <pe...@ti.com> > > > > NAND driver needs to know bus-width of the connected NAND device, in > order to perform proper I/O and initialize itself. Currently there is no > CONFIG > option to provide this information to NAND driver. > > - SPL NAND driver does not have framework to parse ONFI parameter > page. > > Is this about SPL? It looks like a more general change. > Yes, actually I would have loved to see a generic SPL driver for all platforms, because SPL is mostly statically configured, and it just does plain NAND read (it doesn’t even support NAND write, etc). But I do not know the hardware configurations tweaks of other SoC, So at-least have common CONFIG_SYS_NAND_xx which all SPL drivers can use. > > - NAND drivers which cannot self initialize > !defined(CONFIG_SYS_NAND_SELF_INIT) > > do not have any information about device bus-width during > board_nand_init(), > > So, any device-width specific configurations are not possible there. > > Convert to self-init. That's what it's for. > I read it in doc/README.nand: CONFIG_SYS_NAND_SELF_INIT And this path is applicable only for second-stage u-boot loader. But today not many drivers are using this model. So just mentioned it here. With regards, pekon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot