[U-Boot] [PATCH] nand read.jffs2 (nand_legacy) in common/cmd_nand.c
Hi!
Error with CONFIG_NAND_LEGACY in common/cmd_nand.c:
With current code "nand read.jffs2s" (read and skip bad blocks) is always
interpreted as
"nand read.jffs2" (read and fill bad blocks with 0xff). This is because
".jffs2" is
tested before ".jffs2s" and only the first two characters are compared.
Correction:
Test for ".jffs2s" first and compare the first 7 characters.
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 0a366d3..ba1b27f 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -854,13 +854,12 @@ int do_nand (cmd_tbl_t * cmdtp, int flag, int argc, char
*argv[])
(u_char *) addr);
}
return ret;
- } else if (cmdtail && !strncmp (cmdtail, ".jffs2", 2))
- cmd |= NANDRW_JFFS2;/* skip bad blocks */
- else if (cmdtail && !strncmp (cmdtail, ".jffs2s", 2)) {
+ } else if (cmdtail && !strncmp (cmdtail, ".jffs2s", 7))
{
cmd |= NANDRW_JFFS2;/* skip bad blocks (on
read too) */
if (cmd & NANDRW_READ)
cmd |= NANDRW_JFFS2_SKIP; /* skip
bad blocks (on read too) */
- }
+ } else if (cmdtail && !strncmp (cmdtail, ".jffs2", 2))
+ cmd |= NANDRW_JFFS2;/* skip bad blocks */
#ifdef SXNI855T
/* need ".e" same as ".j" for compatibility with older
units */
else if (cmdtail && !strcmp (cmdtail, ".e"))
Signed-off-by: Manfred Schlaegl jun.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Am Sonntag, den 11.01.2009, 14:28 +0100 schrieb Wolfgang Denk: > Dear Manfred, > > In message <1231672254.3130.29.ca...@mobil.alm.archives.at> you wrote: > > > > 1. For our systems we assume, that the env-block never gets bad in > > productive use, because the env-block is never written again. So we > > reduced the problem to number of initial/factory bad blocks. > > That's a pretty risky setup because it is based on an incorrect > assumption - on NAND, block become not only bad when being erased or > written to, but also after a certain number of read operations is > exceeded. Yes, there is a maximum number of reads per block on NAND! > People like to ignore that... See for example the Micron Technical > Note "Design and Use Considerations for NAND Flash Memory", > http://download.micron.com/pdf/technotes/nand/tn2917.pdf Yes I know. I think my description was a little bit misunderstanding: Our solution is only a solution for positioning env-block(s) and handling initial/factory bad blocks. This solution can(should) combined with redundant env-blocks too, if write/erase-wearout is an issue. The problem you discribe is a general nand-flash-problem. To keep the system aware of this you theoretically have to implement a redundant uboot partition too. It makes no sense to have two env-blocks(except for erase/write-wearout-issues), but only one u-boot binary in nand-flash. > > Time to look into UBI, me thinks. Yes I think too. It would make things much easier .. :-) Perhaps: Uboot + Environment (ev. Kernel) on NOR-Flash and filesystem-partitions on NAND/UBI. Best regards, Manfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Hi! Am Sonntag, den 11.01.2009, 05:26 -0800 schrieb Frans Meulenbroeks: > Manfred, > > Thanks for your suggestions. > Did you modify u-boot to search from the last block of the device backwards? > I feel putting the env at the end is quite a good idea. > Yes. First I wanted to implement the openmoku-solution: putting the address of env-block in first block oob. But then I thought it would be much simpler to put the env at the second distinctive position on a nand device - the end. Yes, I had to do some modification on uboot. But I had to do this on uboot-1.1.3(delivered by our hardware-supplier) which is quite old. I'm currenty on work to port our architecture to 2009q1. > > Unfortunately in our system we need to modify the env at runtime. The solution to put the environment at end of device may also be combined with redundant environment. > For software upgrade we aim to go for a ping pong strategy (so having two > kernels and two rfs-es in flash, and upgrade the non active kernel, then > modify u-boot env so the next time we boot from the upgraded kernel). > Unless of course there is a better strategy for this. Yes. Its a very common strategie. We also use two kernel-partitions. - Manfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND bad environment block handling
Hi! Am Donnerstag, den 08.01.2009, 07:19 -0800 schrieb Frans Meulenbroeks: > > Has someone experience in this area? Ideas? Suggestions? 1. For our systems we assume, that the env-block never gets bad in productive use, because the env-block is never written again. So we reduced the problem to number of initial/factory bad blocks. 2. the partitioning and environment-saving is done at production-time. 3. we put the environment in the last good block of the device. The search starts at the end of device and ends at the last block of the last data-partition with an error. Example-Partition-Table on an 32MB-NAND, with blocksize 16kb and max. 45 factory bad-blocks: * the part-size means the possible data size (without bad-blocks). * the real partition-size on device depends on the bad-blocks in this the partition and is calculated automatically at production-time (partition generation). part-size partition 200kb: uboot 1000kb:kernel 15000kb: rootfs 15832kb: datafs rest of device: rest (maximal 45*16kb (max bad blocks) + 16bk (envblock) = 736kb with an increasing number of initial/factory bad-blocks the rest-partition shrinks. So the env-block can be written on any nand-device without less than 45 (initial/factory) bad-blocks. > > Thanks alot! > Frans Meulenbroeks > - Manfred ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
