Re: [U-Boot] [PATCH 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width
From: Scott Wood [mailto:scottwood@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 pekon@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
(re-sending by dropping cc-list, as u-boot maillist moderated earlier mail saying "Too many recipients to the message" :-) )
From: Scott Wood [mailto:scottwood@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 pekon@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
participants (1)
-
Gupta, Pekon