* [U-Boot] environment in NAND @ 2011-09-06 14:16 Arno Steffen 2011-09-06 14:22 ` Wolfgang Wegner 2011-09-06 14:23 ` Marek Vasut 0 siblings, 2 replies; 10+ messages in thread From: Arno Steffen @ 2011-09-06 14:16 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-06 14:16 [U-Boot] environment in NAND Arno Steffen @ 2011-09-06 14:22 ` Wolfgang Wegner 2011-09-06 14:23 ` Marek Vasut 1 sibling, 0 replies; 10+ messages in thread From: Wolfgang Wegner @ 2011-09-06 14:22 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-06 14:16 [U-Boot] environment in NAND Arno Steffen 2011-09-06 14:22 ` Wolfgang Wegner @ 2011-09-06 14:23 ` Marek Vasut 2011-09-07 6:20 ` Arno Steffen 1 sibling, 1 reply; 10+ messages in thread From: Marek Vasut @ 2011-09-06 14:23 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-06 14:23 ` Marek Vasut @ 2011-09-07 6:20 ` Arno Steffen 2011-09-07 7:02 ` Wolfgang Wegner 0 siblings, 1 reply; 10+ messages in thread From: Arno Steffen @ 2011-09-07 6:20 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-07 6:20 ` Arno Steffen @ 2011-09-07 7:02 ` Wolfgang Wegner 2011-09-07 9:34 ` Arno Steffen 0 siblings, 1 reply; 10+ messages in thread From: Wolfgang Wegner @ 2011-09-07 7:02 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-07 7:02 ` Wolfgang Wegner @ 2011-09-07 9:34 ` Arno Steffen 2011-09-07 9:35 ` Wolfgang Wegner 2011-09-15 22:34 ` Scott Wood 0 siblings, 2 replies; 10+ messages in thread From: Arno Steffen @ 2011-09-07 9:34 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-07 9:34 ` Arno Steffen @ 2011-09-07 9:35 ` Wolfgang Wegner 2011-09-07 10:20 ` Arno Steffen 2011-09-15 22:34 ` Scott Wood 1 sibling, 1 reply; 10+ messages in thread From: Wolfgang Wegner @ 2011-09-07 9:35 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-07 9:35 ` Wolfgang Wegner @ 2011-09-07 10:20 ` Arno Steffen 2011-09-07 11:07 ` Wolfgang Wegner 0 siblings, 1 reply; 10+ messages in thread From: Arno Steffen @ 2011-09-07 10:20 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-07 10:20 ` Arno Steffen @ 2011-09-07 11:07 ` Wolfgang Wegner 0 siblings, 0 replies; 10+ messages in thread From: Wolfgang Wegner @ 2011-09-07 11:07 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] environment in NAND 2011-09-07 9:34 ` Arno Steffen 2011-09-07 9:35 ` Wolfgang Wegner @ 2011-09-15 22:34 ` Scott Wood 1 sibling, 0 replies; 10+ messages in thread From: Scott Wood @ 2011-09-15 22:34 UTC (permalink / raw) To: u-boot 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-09-15 22:34 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-06 14:16 [U-Boot] environment in NAND Arno Steffen 2011-09-06 14:22 ` Wolfgang Wegner 2011-09-06 14:23 ` Marek Vasut 2011-09-07 6:20 ` Arno Steffen 2011-09-07 7:02 ` Wolfgang Wegner 2011-09-07 9:34 ` Arno Steffen 2011-09-07 9:35 ` Wolfgang Wegner 2011-09-07 10:20 ` Arno Steffen 2011-09-07 11:07 ` Wolfgang Wegner 2011-09-15 22:34 ` Scott Wood
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.