[U-Boot] environment in NAND

[U-Boot] environment in NAND

[Arno Steffen]

NAND is sufferered from Bad blocks and bit errors. Thats why usually
exists a bad block handling and an ECC. Am I wrong, that I miss both
on uboot  for it's environment?
Or is my uboot just to old (2010.06) and newer versions handle this?
Is there a special setting necessary to handle this?
I see that environment is CRC protected but this make things even
worse, if not an important bit is toogled.
Best regards
Arno

[U-Boot] environment in NAND

[Wolfgang Wegner]

Hi Arno,

On Tue, Sep 06, 2011 at 04:16:59PM +0200, Arno Steffen wrote:
> NAND is sufferered from Bad blocks and bit errors. Thats why usually
> exists a bad block handling and an ECC. Am I wrong, that I miss both
> on uboot  for it's environment?

U-Boot 2010.06 already has bad block handling in the way that it
skips bad blocks during read and write. At least this is how I understand
the code in common/env_nand.c (writeenv(), readenv()).

However, it seems to me that some boards might run into problems
in case there really are bad blocks because there is no extra
space reserved to compensate for them in case of bad blocks.
But this is just a configuration issue.

(Just stumbled over this for openrd, my image needs 3 blocks of
0x20000 size each, env starts at 0x60000 and has size 0x20000 -
this looks fatal to me in case of a bad block within the first
4 blocks, or am I overlooking something here?)

Regards,
Wolfgang

[U-Boot] environment in NAND

[Marek Vasut]

On Tuesday, September 06, 2011 04:16:59 PM Arno Steffen wrote:
> NAND is sufferered from Bad blocks and bit errors. Thats why usually
> exists a bad block handling and an ECC. Am I wrong, that I miss both
> on uboot  for it's environment?
> Or is my uboot just to old (2010.06) and newer versions handle this?
> Is there a special setting necessary to handle this?
> I see that environment is CRC protected but this make things even
> worse, if not an important bit is toogled.
> Best regards
> Arno

Hi,

the mtd subsystem in uboot is based on the one from linux. The ECC handling is 
there, no problem. The problem you might experience is in case you have a 
wrongly implemented NAND driver, which ignores ECC.

What board/cpu do you use? Also, why so old uboot, use mainline?

Cheers

> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] environment in NAND

[Arno Steffen]

2011/9/6 Marek Vasut <marek.vasut@gmail.com>:
> On Tuesday, September 06, 2011 04:16:59 PM Arno Steffen wrote:
>> NAND is sufferered from Bad blocks and bit errors. Thats why usually
>> exists a bad block handling and an ECC. Am I wrong, that I miss both
>> on uboot ?for it's environment?
>> Or is my uboot just to old (2010.06) and newer versions handle this?
>> Is there a special setting necessary to handle this?
>> I see that environment is CRC protected but this make things even
>> worse, if not an important bit is toogled.
>> Best regards
>> Arno
>
> Hi,
>
> the mtd subsystem in uboot is based on the one from linux. The ECC handling is
> there, no problem. The problem you might experience is in case you have a
> wrongly implemented NAND driver, which ignores ECC.
>
> What board/cpu do you use? Also, why so old uboot, use mainline?
>
> Cheers
>
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>

Hi Marek and Wolfgang, Thanks for your answers.
I kept already one sector space for bad blocks, so 1st environment is
at c.0000, 2nd at 10.0000. Blocksize is 2.0000 (so 1 block left).
Maybe I have to announce uboot, that there is one block more
available. But how, in wich defininition? I can declare size (which is
just 8k) and blocksize (128k), but not block number ?!?
I found that this below more or less relates to environment: Maybe I
miss something here? Some look redundant to me. I adopted this from
another board included in uboot, just changed size,location and
redundancy.

#define CONFIG_ENV_SIZE			(8 << 10)	/* 8 KiB */
#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (128 << 10))
#define CONFIG_SYS_GBL_DATA_SIZE	128	/* bytes reserved for */

#define SMNAND_ENV_OFFSET		0x0C0000 /* environment starts here */

#define CONFIG_SYS_ENV_SECT_SIZE	boot_flash_sec
#define CONFIG_ENV_OFFSET		boot_flash_off
#define CONFIG_ENV_ADDR			boot_flash_env_addr

#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
#define CONFIG_ENV_OFFSET_REDUND	0x100000
#define CONFIG_ENV_SIZE_REDUND		(CONFIG_ENV_SIZE)

Regarding the version:
I use an ARM Cortex-A8 / OMAP3, and this uboot is the SDK of TI.
(source is http://arago-project.org/git/projects/?p=u-boot-omap3.git;a=summary)

about ECC: The envrionment  is written with ECC, but my impression is
- it is not working or CRC check is done BEFORE correction is done. So
from time to time I've got a flash from supplier which gives me a CRC
error, and if I check the content, there is just one bit wrong.

@ Wolfgang: I would recommend to downsize the environment size to what
you need. It happens here that a bit is toggling, and than I get CRC
error - although this toggled bit is somewhere in 128k. If the size is
smaller, chances are better that the toggling bit in sector doesn't
hurt you, as it is outside the size.

Best regards
Arno

[U-Boot] environment in NAND

[Wolfgang Wegner]

Hi Arno,

On Wed, Sep 07, 2011 at 08:20:22AM +0200, Arno Steffen wrote:
> Hi Marek and Wolfgang, Thanks for your answers.
> I kept already one sector space for bad blocks, so 1st environment is
> at c.0000, 2nd at 10.0000. Blocksize is 2.0000 (so 1 block left).
> Maybe I have to announce uboot, that there is one block more
> available. But how, in wich defininition? I can declare size (which is
> just 8k) and blocksize (128k), but not block number ?!?
> I found that this below more or less relates to environment: Maybe I
> miss something here? Some look redundant to me. I adopted this from
> another board included in uboot, just changed size,location and
> redundancy.
> 
> #define CONFIG_ENV_SIZE			(8 << 10)	/* 8 KiB */
> #define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (128 << 10))
> #define CONFIG_SYS_GBL_DATA_SIZE	128	/* bytes reserved for */
> 
> #define SMNAND_ENV_OFFSET		0x0C0000 /* environment starts here */
> 
> #define CONFIG_SYS_ENV_SECT_SIZE	boot_flash_sec
> #define CONFIG_ENV_OFFSET		boot_flash_off
> #define CONFIG_ENV_ADDR			boot_flash_env_addr
> 
> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> #define CONFIG_ENV_OFFSET_REDUND	0x100000
> #define CONFIG_ENV_SIZE_REDUND		(CONFIG_ENV_SIZE)

this is my adapted openrd configuration:
#define CONFIG_ENV_IS_IN_NAND           1
#define CONFIG_ENV_SECT_SIZE            0x20000 /* 128K */

#define CONFIG_ENV_SIZE                 0x20000 /* 128k */
#define CONFIG_ENV_ADDR                 0x60000
#define CONFIG_ENV_OFFSET               0x60000 /* env starts here */
#define CONFIG_ENV_RANGE                (6 * CONFIG_ENV_SIZE)
#define CONFIG_ENV_OFFSET_REDUND        (CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE)

It is too long ago I made this modification, so I am not sure (but of
course hope so) that CONFIG_ENV_SIZE_REDUND does not have to be
explicitly specified.

Concerning your hint about making CONFIG_ENV_SIZE smaller: there
is a comment in the original openrd_base.h config file
/*
 * max 4k env size is enough, but in case of nand
 * it has to be rounded to sector size
 */
and I simply adhered to it. It is not clear to me if this is really
a requirement or just made for convenience (having overview over the
flash usage layout).

Up to now, I did not have any problems with this setup on something
like 100+ boards.

Best regards,
Wolfgang

[U-Boot] environment in NAND

[Arno Steffen]

2011/9/7 Wolfgang Wegner <wolfgang@leila.ping.de>:
> Hi Arno,
>
> On Wed, Sep 07, 2011 at 08:20:22AM +0200, Arno Steffen wrote:
>> Hi Marek and Wolfgang, Thanks for your answers.
>> I kept already one sector space for bad blocks, so 1st environment is
>> at c.0000, 2nd at 10.0000. Blocksize is 2.0000 (so 1 block left).
>> Maybe I have to announce uboot, that there is one block more
>> available. But how, in wich defininition? I can declare size (which is
>> just 8k) and blocksize (128k), but not block number ?!?
>> I found that this below more or less relates to environment: Maybe I
>> miss something here? Some look redundant to me. I adopted this from
>> another board included in uboot, just changed size,location and
>> redundancy.
>>
>> #define CONFIG_ENV_SIZE ? ? ? ? ? ? ? ? ? ? ? (8 << 10) ? ? ? /* 8 KiB */
>> #define CONFIG_SYS_MALLOC_LEN ? ? ? ? (CONFIG_ENV_SIZE + (128 << 10))
>> #define CONFIG_SYS_GBL_DATA_SIZE ? ? ?128 ? ? /* bytes reserved for */
>>
>> #define SMNAND_ENV_OFFSET ? ? ? ? ? ? 0x0C0000 /* environment starts here */
>>
>> #define CONFIG_SYS_ENV_SECT_SIZE ? ? ?boot_flash_sec
>> #define CONFIG_ENV_OFFSET ? ? ? ? ? ? boot_flash_off
>> #define CONFIG_ENV_ADDR ? ? ? ? ? ? ? ? ? ? ? boot_flash_env_addr
>>
>> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
>> #define CONFIG_ENV_OFFSET_REDUND ? ? ?0x100000
>> #define CONFIG_ENV_SIZE_REDUND ? ? ? ? ? ? ? ?(CONFIG_ENV_SIZE)
>
> this is my adapted openrd configuration:
> #define CONFIG_ENV_IS_IN_NAND ? ? ? ? ? 1
> #define CONFIG_ENV_SECT_SIZE ? ? ? ? ? ?0x20000 /* 128K */
>
> #define CONFIG_ENV_SIZE ? ? ? ? ? ? ? ? 0x20000 /* 128k */
> #define CONFIG_ENV_ADDR ? ? ? ? ? ? ? ? 0x60000
> #define CONFIG_ENV_OFFSET ? ? ? ? ? ? ? 0x60000 /* env starts here */
> #define CONFIG_ENV_RANGE ? ? ? ? ? ? ? ?(6 * CONFIG_ENV_SIZE)
> #define CONFIG_ENV_OFFSET_REDUND ? ? ? ?(CONFIG_ENV_OFFSET + CONFIG_ENV_RANGE)
>
> It is too long ago I made this modification, so I am not sure (but of
> course hope so) that CONFIG_ENV_SIZE_REDUND does not have to be
> explicitly specified.
>
> Concerning your hint about making CONFIG_ENV_SIZE smaller: there
> is a comment in the original openrd_base.h config file
> /*
> ?* max 4k env size is enough, but in case of nand
> ?* it has to be rounded to sector size
> ?*/
> and I simply adhered to it. It is not clear to me if this is really
> a requirement or just made for convenience (having overview over the
> flash usage layout).
>
> Up to now, I did not have any problems with this setup on something
> like 100+ boards.
>
> Best regards,
> Wolfgang
>
>

You are right:
./include/environment.h:# if defined(CONFIG_ENV_ADDR_REDUND) &&
!defined(CONFIG_ENV_SIZE_REDUND)
./include/environment.h:#  define CONFIG_ENV_SIZE_REDUND	CONFIG_ENV_SIZE
If it is not defined it assumes the size is same.

It is not necessary to round up. I see a message from uboot, that env
size is smaller than a sector and a the complete sector will be
erased.
See log below. (From my understanding every change is a complete erase
and rewrite, as it all happens in just one sector).

But again, how did you managed this with bad blocks?

"# save
Saving Environment to NAND...
Erasing Nand...
Warning: Erase size 0x00002000 smaller than one erase block 0x00020000
         Erasing 0x00020000 instead
Skipping bad block at  0x000c0000

Writing to Nand... FAILED!"

So from what I observe is, that neither e0000 (next block) is erased
nor written.

Best regards
Arno

[U-Boot] environment in NAND

[Wolfgang Wegner]

Hi,

sorry, not sure about it right now, but could it be you simply need
to define CONFIG_ENV_RANGE to some multiple of the sector size?

At least is what I seem to remember...

Wolfgang

[U-Boot] environment in NAND

[Arno Steffen]

2011/9/7 Wolfgang Wegner <wolfgang@leila.ping.de>:
> Hi,
>
> sorry, not sure about it right now, but could it be you simply need
> to define CONFIG_ENV_RANGE to some multiple of the sector size?
>
> At least is what I seem to remember...
>
> Wolfgang
>
>

You are my hero - thats what I'm looking for ! Out of all boards
included in uboot only 2 use this setting. That's why I didn't found
this setting.
So - bad block handling works !!!

There is a question left for redundancy, which is imho a bug (or maybe
I don't get the design concept of redundancy):
 If I have an empty environment (both standard and redund - env1 and
env2 ) and boot, it recognizes CRC error (which is ok).
A "save" write it to redundand environment (0x10.0000). This is
probably as it recognice an CRCerror in env1 and doesn't check this
for env2

If I add some settings ("set test true") and do "save" a second time -
it writes ONLY to default env (0xc.0000) ?!?
What happens, that it will change location? Or shouldn't it write to
both locations ?

Best regards
Arno

[U-Boot] environment in NAND

[Wolfgang Wegner]

On Wed, Sep 07, 2011 at 12:20:51PM +0200, Arno Steffen wrote:
> 
> There is a question left for redundancy, which is imho a bug (or maybe
> I don't get the design concept of redundancy):
>  If I have an empty environment (both standard and redund - env1 and
> env2 ) and boot, it recognizes CRC error (which is ok).
> A "save" write it to redundand environment (0x10.0000). This is
> probably as it recognice an CRCerror in env1 and doesn't check this
> for env2
> 
> If I add some settings ("set test true") and do "save" a second time -
> it writes ONLY to default env (0xc.0000) ?!?
> What happens, that it will change location? Or shouldn't it write to
> both locations ?

there is only one location written.
I don't remember exactly how it works, but there is an algorithm in
place to check which block is newer upon initial read.
Have a look at common/env_nand.c, env_init() to see how it works exactly.

Best regards,

Wolfgang

[U-Boot] environment in NAND

[Scott Wood]

On 09/07/2011 04:34 AM, Arno Steffen wrote:
> "# save
> Saving Environment to NAND...
> Erasing Nand...
> Warning: Erase size 0x00002000 smaller than one erase block 0x00020000
>          Erasing 0x00020000 instead
> Skipping bad block at  0x000c0000
> 
> Writing to Nand... FAILED!"

In newer versions of U-Boot this is a hard failure, not a warning.

CONFIG_ENV_RANGE should probably be defaulting to CONFIG_ENV_SECT_SIZE,
not CONFIG_ENV_SIZE -- that would eliminate this problem.

-Scott