[U-Boot] [PATCH 1/1] am33xx: add CONFIG_SYS_NAND_DEVICE_WIDTH to determine NAND device bus-width

[Gupta, 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 at 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 at 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