* [U-Boot] Question regarding NAND environment @ 2012-01-26 17:05 Peter Barada 2012-01-26 17:27 ` Scott Wood 0 siblings, 1 reply; 6+ messages in thread From: Peter Barada @ 2012-01-26 17:05 UTC (permalink / raw) To: u-boot I'm trying to have a robust environment stored in NAND, and three blocks of space available to store it in. Looking at the REDUND code, I see it only keeps two copies of the environment regardless of the amount of space available. Instead I'm looking to use CONFIG_ENV_RANGE to handle the extra blocks. Can/does the code save multiple copies of the environment across the three blocks, and can readenv read copies of the environment (skipping bad blocks) until it finds one good environment? I'm trying to prevent any corruption from happening if (unlikely but possible) power fails while saving the environment. In my case the environment is 32K and each block is 128K, so I should be able to write six copies into NAND (if all three blocks are good), and if one block then goes bad I can still erase one of the other blocks (while the other remaining good block holds at least one valid copy of the environment). If u-boot doesn't do this currently is there any interest in a patch for such? -- Peter Barada peter.barada at logicpd.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] Question regarding NAND environment 2012-01-26 17:05 [U-Boot] Question regarding NAND environment Peter Barada @ 2012-01-26 17:27 ` Scott Wood 2012-01-26 17:34 ` Peter Barada 0 siblings, 1 reply; 6+ messages in thread From: Scott Wood @ 2012-01-26 17:27 UTC (permalink / raw) To: u-boot On 01/26/2012 11:05 AM, Peter Barada wrote: > I'm trying to have a robust environment stored in NAND, and three blocks > of space available to store it in. > > Looking at the REDUND code, I see it only keeps two copies of the > environment regardless of the amount of space available. Instead I'm > looking to use CONFIG_ENV_RANGE to handle the extra blocks. CONFIG_ENV_RANGE and CONFIG_ENV_*_REDUND are orthogonal, not alternatives. > Can/does the code save multiple copies of the environment across the > three blocks, No. Its purpose is to provide room to skip blocks that are formally marked as bad. If you want REDUND with more than two copies, you'll have to modify the REDUND code to support that. > and can readenv read copies of the environment (skipping > bad blocks) until it finds one good environment? I'm trying to prevent > any corruption from happening if (unlikely but possible) power fails > while saving the environment. Why are two copies insufficient for that? -Scott ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] Question regarding NAND environment 2012-01-26 17:27 ` Scott Wood @ 2012-01-26 17:34 ` Peter Barada 2012-01-27 21:46 ` Scott Wood 0 siblings, 1 reply; 6+ messages in thread From: Peter Barada @ 2012-01-26 17:34 UTC (permalink / raw) To: u-boot On 01/26/2012 12:27 PM, Scott Wood wrote: > On 01/26/2012 11:05 AM, Peter Barada wrote: >> I'm trying to have a robust environment stored in NAND, and three blocks >> of space available to store it in. >> >> Looking at the REDUND code, I see it only keeps two copies of the >> environment regardless of the amount of space available. Instead I'm >> looking to use CONFIG_ENV_RANGE to handle the extra blocks. > CONFIG_ENV_RANGE and CONFIG_ENV_*_REDUND are orthogonal, not alternatives. > >> Can/does the code save multiple copies of the environment across the >> three blocks, > No. Its purpose is to provide room to skip blocks that are formally > marked as bad. > > If you want REDUND with more than two copies, you'll have to modify the > REDUND code to support that. > >> and can readenv read copies of the environment (skipping >> bad blocks) until it finds one good environment? I'm trying to prevent >> any corruption from happening if (unlikely but possible) power fails >> while saving the environment. > Why are two copies insufficient for that? Two copies are sufficient, if none of the blocks ever go bad. To simplify things, suppose the environment is the same size as a block and you have only two blocks (and two copies) to hold the environment. If one block goes bad then there is a window between when the one remaining block is erased and written with the environment that if power fails then there is no environment in NAND. To solve this I can crank up the number of blocks to three which allows one block to go bad and still at all times have one good copy of the environment in NAND. But looking at writeenv(), it stops as soon as either nand_write fails, or one copy of the environment is written. So it could make sense to modify writeenv to write as many copies of the environment that fit into CONFIG_ENV_RANGE, and have readenv read out copies and verify them until it finds one good one. To prevent a "buried update", the order of reads/writes (by either u-boot or u-boot-tools in Linux) would have to be in the same order. Then if power fails while writing, either no valid data was written (while still having a copy of the previous good environment in a following block of NAND), or at least one new copy is written and on the next reboot u-boot will find it. I guess what I'm proposing to is much like REDUND, but I think more flexible... -- Peter Barada peter.barada at logicpd.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] Question regarding NAND environment 2012-01-26 17:34 ` Peter Barada @ 2012-01-27 21:46 ` Scott Wood 2012-01-27 22:08 ` Peter Barada 0 siblings, 1 reply; 6+ messages in thread From: Scott Wood @ 2012-01-27 21:46 UTC (permalink / raw) To: u-boot On 01/26/2012 11:34 AM, Peter Barada wrote: > On 01/26/2012 12:27 PM, Scott Wood wrote: >> Why are two copies insufficient for that? > Two copies are sufficient, if none of the blocks ever go bad. > > To simplify things, suppose the environment is the same size as a block > and you have only two blocks (and two copies) to hold the environment. > If one block goes bad then there is a window between when the one > remaining block is erased and written with the environment that if power > fails then there is no environment in NAND. It seems unlikely, but possible I guess. Currently I don't think we dynamically mark blocks bad at all in U-Boot, except in things like ubi and yaffs. > To solve this I can crank up the number of blocks to three which allows > one block to go bad and still at all times have one good copy of the > environment in NAND. But looking at writeenv(), it stops as soon as > either nand_write fails, or one copy of the environment is written. So > it could make sense to modify writeenv to write as many copies of the > environment that fit into CONFIG_ENV_RANGE, and have readenv read out > copies and verify them until it finds one good one. This isn't what CONFIG_ENV_RANGE is about. I think it would make more sense to change REDUND to support more than two copies (each with their own range). Probably better to never update the environment in the field -- source a script in an ubi partition instead. -Scott ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] Question regarding NAND environment 2012-01-27 21:46 ` Scott Wood @ 2012-01-27 22:08 ` Peter Barada 2012-01-27 22:25 ` Tom Rini 0 siblings, 1 reply; 6+ messages in thread From: Peter Barada @ 2012-01-27 22:08 UTC (permalink / raw) To: u-boot On 01/27/2012 04:46 PM, Scott Wood wrote: > On 01/26/2012 11:34 AM, Peter Barada wrote: >> On 01/26/2012 12:27 PM, Scott Wood wrote: >>> Why are two copies insufficient for that? >> Two copies are sufficient, if none of the blocks ever go bad. >> >> To simplify things, suppose the environment is the same size as a block >> and you have only two blocks (and two copies) to hold the environment. >> If one block goes bad then there is a window between when the one >> remaining block is erased and written with the environment that if power >> fails then there is no environment in NAND. > It seems unlikely, but possible I guess. Currently I don't think we > dynamically mark blocks bad at all in U-Boot, except in things like ubi > and yaffs. I'm probalby being paranoid, but from what I've seen, if it can fail, odds are it will. I can add code to mark the blocks bad if the erase/write fails. >> To solve this I can crank up the number of blocks to three which allows >> one block to go bad and still at all times have one good copy of the >> environment in NAND. But looking at writeenv(), it stops as soon as >> either nand_write fails, or one copy of the environment is written. So >> it could make sense to modify writeenv to write as many copies of the >> environment that fit into CONFIG_ENV_RANGE, and have readenv read out >> copies and verify them until it finds one good one. > This isn't what CONFIG_ENV_RANGE is about. I think it would make more > sense to change REDUND to support more than two copies (each with their > own range). Its somewhere in the middle. REDUND give you two copies. ENV_RANGE gives you one copy but allows it to live in the first good block. Modifying either way is going to affect units in the field. But I'll give it a whirl. > Probably better to never update the environment in the field -- source a > script in an ubi partition instead. Proper planning will save one from having to update the environment in the field, but I'm sure it happens. I just figured I'd try to make sure that nothing bad happens when people do... -- Peter Barada peter.barada at logicpd.com ^ permalink raw reply [flat|nested] 6+ messages in thread
* [U-Boot] Question regarding NAND environment 2012-01-27 22:08 ` Peter Barada @ 2012-01-27 22:25 ` Tom Rini 0 siblings, 0 replies; 6+ messages in thread From: Tom Rini @ 2012-01-27 22:25 UTC (permalink / raw) To: u-boot On Fri, Jan 27, 2012 at 3:08 PM, Peter Barada <peter.barada@logicpd.com> wrote: > On 01/27/2012 04:46 PM, Scott Wood wrote: >> On 01/26/2012 11:34 AM, Peter Barada wrote: >>> On 01/26/2012 12:27 PM, Scott Wood wrote: >>>> Why are two copies insufficient for that? >>> Two copies are sufficient, if none of the blocks ever go bad. >>> >>> To simplify things, suppose the environment is the same size as a block >>> and you have only two blocks (and two copies) to hold the environment. >>> If one block goes bad then there is a window between when the one >>> remaining block is erased and written with the environment that if power >>> fails then there is no environment in NAND. >> It seems unlikely, but possible I guess. ?Currently I don't think we >> dynamically mark blocks bad at all in U-Boot, except in things like ubi >> and yaffs. > I'm probalby being paranoid, but from what I've seen, if it can fail, > odds are it will. > > I can add code to mark the blocks bad if the erase/write fails. > >>> To solve this I can crank up the number of blocks to three which allows >>> one block to go bad and still at all times have one good copy of the >>> environment in NAND. ?But looking at writeenv(), it stops as soon as >>> either nand_write fails, or one copy of the environment is written. So >>> it could make sense to modify writeenv to write as many copies of the >>> environment that fit into CONFIG_ENV_RANGE, and have readenv read out >>> copies and verify them until it finds one good one. >> This isn't what CONFIG_ENV_RANGE is about. ?I think it would make more >> sense to change REDUND to support more than two copies (each with their >> own range). > Its somewhere in the middle. ?REDUND give you two copies. ?ENV_RANGE > gives you one copy but allows it to > live in the first good block. ?Modifying either way is going to affect > units in the field. ?But I'll give it a whirl. >> Probably better to never update the environment in the field -- source a >> script in an ubi partition instead. > Proper planning will save one from having to update the environment in > the field, but I'm sure it happens. ?I just figured I'd try to make sure > that nothing bad happens when people do... Right, but with uEnv.txt (or rather, the underlying tech) you could move away from a U-Boot controlled env at all. Have say /boot/uEnv.txt in your UBIFS-in-UBI image (so all the goodness of UBI managing blocks) and the default env will start out bootcmd with loading and updating the env with uEnv.txt and then running uenvcmd or what have you. This does mean the env is only changeable from Linux however. -- Tom ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-01-27 22:25 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-01-26 17:05 [U-Boot] Question regarding NAND environment Peter Barada 2012-01-26 17:27 ` Scott Wood 2012-01-26 17:34 ` Peter Barada 2012-01-27 21:46 ` Scott Wood 2012-01-27 22:08 ` Peter Barada 2012-01-27 22:25 ` Tom Rini
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox