[U-Boot] ARM: omap: Looking to dynamically setup ECC and nand settings during boot

[U-Boot] ARM: omap: Looking to dynamically setup ECC and nand settings during boot

[Jon Cormier]

We have a product based on the 335x that has several different models where
the only difference is the nand part.  We would like to have a unified
u-boot that can dynamically configure the nand's ECC, page size, block
size, etc using a spi eeprom containing a model number.  Both the UBL and
u-boot image are stored in nand. We already do this in the kernel.
Currently in the UBL all the nand information is setup in #defines during
compile time which makes it hard to change at runtime.  I am unsure how to
go about changing this.  Has anyone tried doing this dynamic setup?

We are currently based off of the 2013.10 tag but will move forward if
needed.

-- 
Jonathan Cormier
CriticalLink

[U-Boot] omap: Looking to dynamically setup ECC and nand settings during boot

[Gupta, Pekon]

Hi Jon,


>From: Jon Cormier [mailto:jcormier at criticallink.com] 

> We have a product based on the 335x that has several different models where the only difference is the nand part.? We would like to have a unified u-boot that can dynamically configure the nand's ECC, page size, block size, etc using a spi eeprom containing a model number.? Both the UBL and u-boot image are stored in nand. We already do this in the kernel.? Currently in the UBL all the nand information is setup in #defines during compile time which makes it hard to change at runtime.? I am unsure how to go about changing this.? Has anyone tried doing this dynamic setup?

(1) For NAND device parameters (like Block-size, Page-size, data-width)
These parameter are anyways dynamically determined by reading on chip
ONFI page during omap_board_init(). But that's only for u-boot (second-stage).
- For SPL these are still #defined based to keep the code-footprint small.


(2) For dynamically selection of ecc-scheme, you need to re-add
'nandecc' command which is kind of deprecated now. Though its
driver side support is still present in omap_gpmc.c.
- But again, this is not supported for SPL.
If everyone agrees, we should add this to main NAND framework
instead of cluttering individual board-files.
------------------------------------------------------------------
File: arch/arm/cpu/armv7/omap3/board.c

#if defined(CONFIG_NAND_OMAP_GPMC) & !defined(CONFIG_SPL_BUILD)
/******************************************************************************
 * OMAP3 specific command to switch between NAND HW and SW ecc
 *****************************************************************************/
static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[])
{
	if (argc < 2 || argc > 3)
		goto usage;

	if (strncmp(argv[1], "hw", 2) == 0) {
		if (argc == 2) {
			omap_nand_switch_ecc(1, 1);
		} else {
			if (strncmp(argv[2], "hamming", 7) == 0)
				omap_nand_switch_ecc(1, 1);
			else if (strncmp(argv[2], "bch8", 4) == 0)
				omap_nand_switch_ecc(1, 8);
			else
				goto usage;
		}
	} else if (strncmp(argv[1], "sw", 2) == 0) {
		omap_nand_switch_ecc(0, 0);
	} else {
		goto usage;
	}

	return 0;

usage:
	printf ("Usage: nandecc %s\n", cmdtp->usage);
	return 1;
}

U_BOOT_CMD(
	nandecc, 3, 1,	do_switch_ecc,
	"switch OMAP3 NAND ECC calculation algorithm",
	"hw [hamming|bch8] - Switch between NAND hardware 1-bit hamming and"
	" 8-bit BCH\n"
	"                           ecc calculation (second parameter may"
	" be omitted).\n"
	"nandecc sw               - Switch to NAND software ecc algorithm."
);

#endif /* CONFIG_NAND_OMAP_GPMC & !CONFIG_SPL_BUILD */
------------------------------------------------------------------


(3) If you need to have generic SPL too, then you might need to try
NANDI2C boot-mode of AM335x. (please refer AM335x TRM).


> We are currently based off of the 2013.10 tag but will move forward if needed.
Yes, I would suggest to move to latest u-boot which has support
for BCH16 ecc-scheme, as higher ecc-scheme work better with newer
technology NAND and MLC NAND devices which are more prone
to bit-flips.


with regards, pekon

> -- 
> Jonathan Cormier
> CriticalLink

[U-Boot] omap: Looking to dynamically setup ECC and nand settings during boot

[Jon Cormier]

Pekon,

Thanks for the response.


On Tue, Jul 15, 2014 at 12:23 AM, Gupta, Pekon <pekon@ti.com> wrote:

> Hi Jon,
>
>
> >From: Jon Cormier [mailto:jcormier at criticallink.com]
>
> > We have a product based on the 335x that has several different models
> where the only difference is the nand part.  We would like to have a
> unified u-boot that can dynamically configure the nand's ECC, page size,
> block size, etc using a spi eeprom containing a model number.  Both the UBL
> and u-boot image are stored in nand. We already do this in the kernel.
> Currently in the UBL all the nand information is setup in #defines during
> compile time which makes it hard to change at runtime.  I am unsure how to
> go about changing this.  Has anyone tried doing this dynamic setup?
>
> (1) For NAND device parameters (like Block-size, Page-size, data-width)
> These parameter are anyways dynamically determined by reading on chip
> ONFI page during omap_board_init(). But that's only for u-boot
> (second-stage).
> - For SPL these are still #defined based to keep the code-footprint small.
>
> Sure makes sense.  Could this be an area where I could experiment to see
if adding ONFI support makes the SPL too large? Alternatively without ONFI
support could I fallback to using a nand flash table like in the kernel for
older nand parts.  This could allow me to switch between a few parts after
either reading the eeprom or reading the nand part number.

>
> (2) For dynamically selection of ecc-scheme, you need to re-add
> 'nandecc' command which is kind of deprecated now. Though its
> driver side support is still present in omap_gpmc.c.
> - But again, this is not supported for SPL.
> If everyone agrees, we should add this to main NAND framework
> instead of cluttering individual board-files.
> ------------------------------------------------------------------
> File: arch/arm/cpu/armv7/omap3/board.c
>
> #if defined(CONFIG_NAND_OMAP_GPMC) & !defined(CONFIG_SPL_BUILD)
>
> /******************************************************************************
>  * OMAP3 specific command to switch between NAND HW and SW ecc
>
>  *****************************************************************************/
> static int do_switch_ecc(cmd_tbl_t * cmdtp, int flag, int argc, char *
> const argv[])
> {
>         if (argc < 2 || argc > 3)
>                 goto usage;
>
>         if (strncmp(argv[1], "hw", 2) == 0) {
>                 if (argc == 2) {
>                         omap_nand_switch_ecc(1, 1);
>                 } else {
>                         if (strncmp(argv[2], "hamming", 7) == 0)
>                                 omap_nand_switch_ecc(1, 1);
>                         else if (strncmp(argv[2], "bch8", 4) == 0)
>                                 omap_nand_switch_ecc(1, 8);
>                         else
>                                 goto usage;
>                 }
>         } else if (strncmp(argv[1], "sw", 2) == 0) {
>                 omap_nand_switch_ecc(0, 0);
>         } else {
>                 goto usage;
>         }
>
>         return 0;
>
> usage:
>         printf ("Usage: nandecc %s\n", cmdtp->usage);
>         return 1;
> }
>
> U_BOOT_CMD(
>         nandecc, 3, 1,  do_switch_ecc,
>         "switch OMAP3 NAND ECC calculation algorithm",
>         "hw [hamming|bch8] - Switch between NAND hardware 1-bit hamming
> and"
>         " 8-bit BCH\n"
>         "                           ecc calculation (second parameter may"
>         " be omitted).\n"
>         "nandecc sw               - Switch to NAND software ecc algorithm."
> );
>
> #endif /* CONFIG_NAND_OMAP_GPMC & !CONFIG_SPL_BUILD */
> ------------------------------------------------------------------
>
> Ok I would probably just call the omap_nand_switch_ecc function directly
after determining which part was in use.

>
> (3) If you need to have generic SPL too, then you might need to try
> NANDI2C boot-mode of AM335x. (please refer AM335x TRM).
>
> According to the TRM this is to setup the ROM when it can't autodetect the
nands setup.  Currently the ROM auto discovers each of the nands without
problems.  Since the ROM is already setting up the gpmc and ecc for the
nand, would it be possible to setup the SPL to use the already setup
hardware as is?

>
> > We are currently based off of the 2013.10 tag but will move forward if
> needed.
> Yes, I would suggest to move to latest u-boot which has support
> for BCH16 ecc-scheme, as higher ecc-scheme work better with newer
> technology NAND and MLC NAND devices which are more prone
> to bit-flips.
>
> Thanks.  We've already got BCH16 support in our u-boot.  It was needed to
program the 4k page size nands so the ROM would boot them.

>
> with regards, pekon
>
> > --
> > Jonathan Cormier
> > CriticalLink
>

I noticed this commit when looking for nand changes in the latest u-boot
but I'm not sure how this actually affects the SPL nand support. And
whether it helps me move towards my goal.
(6dd3b566893a99629771e076dca1ce8db7b77dc1) mtd: Add a
CONFIG_SPL_MTD_SUPPORT for a more full NAND subsystem in SPL


-- 
Jonathan Cormier
CriticalLink

[U-Boot] omap: Looking to dynamically setup ECC and nand settings during boot

[Gupta, Pekon]

Hi Jon,


> From: Jon Cormier [mailto:jcormier at criticallink.com] 
>> On Tue, Jul 15, 2014 at 12:23 AM, Gupta, Pekon <pekon@ti.com> wrote:
>>>From: Jon Cormier [mailto:jcormier at criticallink.com]

>>> We have a product based on the 335x that has several different models where the only difference is the nand part.? We would like to have a unified u-boot that can dynamically configure the nand's ECC, page size, block size, etc using a spi eeprom containing a model number.? Both the UBL and u-boot image are stored in nand. We already do this in the kernel.? Currently in the UBL all the nand information is setup in #defines during compile time which makes it hard to change at runtime.? I am unsure how to go about changing this.? Has anyone tried doing this dynamic setup?

>>(1) For NAND device parameters (like Block-size, Page-size, data-width)
>>These parameter are anyways dynamically determined by reading on chip
>>ONFI page during omap_board_init(). But that's only for u-boot (second-stage).
>>- For SPL these are still #defined based to keep the code-footprint small.
>Sure makes sense.? Could this be an area where I could experiment to see if adding ONFI support makes the SPL too large? 

Yes, And this should be fairly easy. You have to just replicate the
code under  #ifdef CONFIG_SYS_NAND_ONFI_DETECTION ... #endif
from nand_base.c. And make appropriate call to it in
$U-BOOT/drivers/mtd/nand/am335x_spl_bch.c @@ nand_init(...)
after board_nand_init() call.

> Alternatively without ONFI support could I fallback to using a nand flash table like in the kernel >for older nand parts.? This could allow me to switch between a few parts after either reading the eeprom or reading the nand part number.
Yes, Look-up table approach is also possible, but ONFI is more flexible
and scalable.


>>(2) For dynamically selection of ecc-scheme, you need to re-add
>>'nandecc' command which is kind of deprecated now. Though its
>>driver side support is still present in omap_gpmc.c.
>>- But again, this is not supported for SPL.
>>If everyone agrees, we should add this to main NAND framework
>>instead of cluttering individual board-files.
[...]
> Ok I would probably just call the omap_nand_switch_ecc function directly after determining which part was in use.? 
You choice, but still suggest you to do it cleanly and contribute it back
to community for everyone's benefit.


>> (3) If you need to have generic SPL too, then you might need to try
>>NANDI2C boot-mode of AM335x. (please refer AM335x TRM).
>According to the TRM this is to setup the ROM when it can't autodetect the nands setup.? Currently the ROM auto discovers each of the nands without problems.? Since the ROM is already setting up the gpmc and ecc for the nand, would it be possible to setup the SPL to use the already setup hardware as is? 
AFAIK, NANDI2C is a separate independent boot mode, in addition to NAND boot mode
in which you can custom specify NAND parameters (even if its detectable NAND).
And you can select NANDI2C boot mode directly via SYSBOOT pins.

>>> We are currently based off of the 2013.10 tag but will move forward if needed.
>>Yes, I would suggest to move to latest u-boot which has support
>>for BCH16 ecc-scheme, as higher ecc-scheme work better with newer
>>technology NAND and MLC NAND devices which are more prone
>>to bit-flips.
> Thanks.? We've already got BCH16 support in our u-boot.? It was needed to program the 4k page size nands so the ROM would boot them. 
> --
> Jonathan Cormier
> CriticalLink

>I noticed this commit when looking for nand changes in the latest u-boot but I'm not sure how this actually affects the SPL nand support. And whether it helps me move towards my goal.
>(6dd3b566893a99629771e076dca1ce8db7b77dc1) mtd: Add a CONFIG_SPL_MTD_SUPPORT for a more full NAND subsystem in SPL

This may help you.
But I don't have much knowledge on use of MTD framework in SPL.
+ Tom Rini

with regards, pekon

[U-Boot] omap: Looking to dynamically setup ECC and nand settings during boot

[Jon Cormier]

On Wed, Jul 16, 2014 at 3:03 PM, Gupta, Pekon <pekon@ti.com> wrote:

> Hi Jon,
>
>
> > From: Jon Cormier [mailto:jcormier at criticallink.com]
> >> On Tue, Jul 15, 2014 at 12:23 AM, Gupta, Pekon <pekon@ti.com> wrote:
> >>>From: Jon Cormier [mailto:jcormier at criticallink.com]
>
> >>> We have a product based on the 335x that has several different models
> where the only difference is the nand part.  We would like to have a
> unified u-boot that can dynamically configure the nand's ECC, page size,
> block size, etc using a spi eeprom containing a model number.  Both the UBL
> and u-boot image are stored in nand. We already do this in the kernel.
> Currently in the UBL all the nand information is setup in #defines during
> compile time which makes it hard to change at runtime.  I am unsure how to
> go about changing this.  Has anyone tried doing this dynamic setup?
>
> >>(1) For NAND device parameters (like Block-size, Page-size, data-width)
> >>These parameter are anyways dynamically determined by reading on chip
> >>ONFI page during omap_board_init(). But that's only for u-boot
> (second-stage).
> >>- For SPL these are still #defined based to keep the code-footprint
> small.
> >Sure makes sense.  Could this be an area where I could experiment to see
> if adding ONFI support makes the SPL too large?
>
> Yes, And this should be fairly easy. You have to just replicate the
> code under  #ifdef CONFIG_SYS_NAND_ONFI_DETECTION ... #endif
> from nand_base.c. And make appropriate call to it in
> $U-BOOT/drivers/mtd/nand/am335x_spl_bch.c @@ nand_init(...)
> after board_nand_init() call.
>

Worth a shot.

>
> > Alternatively without ONFI support could I fallback to using a nand
> flash table like in the kernel >for older nand parts.  This could allow me
> to switch between a few parts after either reading the eeprom or reading
> the nand part number.
> Yes, Look-up table approach is also possible, but ONFI is more flexible
> and scalable.
>
Understood.

>
> >>(2) For dynamically selection of ecc-scheme, you need to re-add
> >>'nandecc' command which is kind of deprecated now. Though its
> >>driver side support is still present in omap_gpmc.c.
> >>- But again, this is not supported for SPL.
> >>If everyone agrees, we should add this to main NAND framework
> >>instead of cluttering individual board-files.
> [...]
> > Ok I would probably just call the omap_nand_switch_ecc function directly
> after determining which part was in use.
> You choice, but still suggest you to do it cleanly and contribute it back
> to community for everyone's benefit.
>
> Yeah, I think the community contributable part would be adding this
functionality to the SPL though I fear it may become a bit of a hack.

>
> >> (3) If you need to have generic SPL too, then you might need to try
> >>NANDI2C boot-mode of AM335x. (please refer AM335x TRM).
> >According to the TRM this is to setup the ROM when it can't autodetect
> the nands setup.  Currently the ROM auto discovers each of the nands
> without problems.  Since the ROM is already setting up the gpmc and ecc for
> the nand, would it be possible to setup the SPL to use the already setup
> hardware as is?
> AFAIK, NANDI2C is a separate independent boot mode, in addition to NAND
> boot mode
> in which you can custom specify NAND parameters (even if its detectable
> NAND).
> And you can select NANDI2C boot mode directly via SYSBOOT pins.
>
> >>> We are currently based off of the 2013.10 tag but will move forward if
> needed.
> >>Yes, I would suggest to move to latest u-boot which has support
> >>for BCH16 ecc-scheme, as higher ecc-scheme work better with newer
> >>technology NAND and MLC NAND devices which are more prone
> >>to bit-flips.
> > Thanks.  We've already got BCH16 support in our u-boot.  It was needed
> to program the 4k page size nands so the ROM would boot them.
> > --
> > Jonathan Cormier
> > CriticalLink
>
> >I noticed this commit when looking for nand changes in the latest u-boot
> but I'm not sure how this actually affects the SPL nand support. And
> whether it helps me move towards my goal.
> >(6dd3b566893a99629771e076dca1ce8db7b77dc1) mtd: Add a
> CONFIG_SPL_MTD_SUPPORT for a more full NAND subsystem in SPL
>
> This may help you.
> But I don't have much knowledge on use of MTD framework in SPL.
> + Tom Rini
>

Good call.

Tom, What was the reason for this patch?  Can it help by allowing SPL
access to ONFI or omap_nand_switch_ecc?


> with regards, pekon
>



-- 
Jonathan Cormier
CriticalLink

[U-Boot] omap: Looking to dynamically setup ECC and nand settings during boot

[Tom Rini]

On Wed, Jul 16, 2014 at 04:47:30PM -0400, Jon Cormier wrote:
> On Wed, Jul 16, 2014 at 3:03 PM, Gupta, Pekon <pekon@ti.com> wrote:
[snip]
> > >I noticed this commit when looking for nand changes in the latest u-boot
> > but I'm not sure how this actually affects the SPL nand support. And
> > whether it helps me move towards my goal.
> > >(6dd3b566893a99629771e076dca1ce8db7b77dc1) mtd: Add a
> > CONFIG_SPL_MTD_SUPPORT for a more full NAND subsystem in SPL
> >
> > This may help you.
> > But I don't have much knowledge on use of MTD framework in SPL.
> > + Tom Rini
> 
> Good call.
> 
> Tom, What was the reason for this patch?  Can it help by allowing SPL
> access to ONFI or omap_nand_switch_ecc?

This was part of, but not enough, to make the full MTD/NAND subsystems
available within SPL, to for example re-use the environment code.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140716/85c8cfd4/attachment.pgp>