Hi Pekon On Mon, Dec 2, 2013 at 6:05 PM, Gupta, Pekon <pekon@xxxxxx> wrote: >>From: Thomas Petazzoni [mailto:thomas.petazzoni@xxxxxxxxxxxxxxxxxx] >>Dear Gupta, Pekon, >> >>On Mon, 2 Dec 2013 16:13:56 +0000, Gupta, Pekon wrote: >> >>> Yes, at-least OMAP3 arch u-boot should still supports 'nandecc'. >>> The infrastructure is still in place, however the command 'nandecc' is >>> deprecated in newer versions. >>> References in mainline u-boot: >>> arch/arm/cpu/armv7/omap3/board.c @@do_switch_ecc() >>> driver/mtd/nand/omap_gpmc.c @@omap_nand_switch_ecc() >>> >>> So with minor hacks, you should be able to bring-back 'nandecc'. >> >>So in short, what it means is that indeed the fact of switching to BCH8 >>on the kernel side is really breaking things, because U-Boot users now >>have the choice between: >> >> * Configuring U-Boot to use Hamming ECC, and be able to reflash their >> SPL, but not their filesystem images. >> >> * Configuring U-Boot to use BCH8, and be able to reflash their >> filesystem images, but not their SPL. >> >>Seems a little bit annoying for users, no? >> > Yes, agree .. > But this is only because we have mis-match in ecc-scheme between > ROM-code (while reading SPL) v/s rest of system. > However, if you continue using 'HAM1' for *both* u-boot and kernel > you should not face any issue. And with latest patch on u-boot > your board file should also remain unchanged. > > [...] > >>> But for all these, images need to be flashed from u-boot. As kernel >>> cannot switch ecc-schemes on-the-fly. >> >>Which as I was saying, is a bit of shame. There is technically nothing >>that makes the ECC scheme something that needs to be applied globally >>on the entire flash. > > No, I don't think that kernel needs to ever dynamically switch ecc-schemes. > This feature should be limited only to u-boot (or bootloaders) because: > I don't think so. There are cpu that can be boot only using some ecc scheme but for a lot of reason you should require to have for the filesystem a different ecc scheme > (1) Adding support for dynamic switching of ecc-schemes will require all > code to be compiled in driver which increases the kernel driver footprint. > (example adding BCH8_SW means you need to compile in lib/bch.c) > It depends on the system that you are using and sometime increase the kernel size is less important that guarantee system consistency > (2) Also selection of ecc-scheme mainly depends on NAND device parameter > (like density, page-size, oobsize) which remain constant for a device > (all NAND partitions). Thus all partitions should use *same* ecc-scheme > preferable highest possible available with NAND device & kernel. > same as above. It can be a limitation on the bootrom > (3) Kernel uses same driver instance to handle all MTD partitions, so if one > partition uses HAM1 while other uses BCH8, and both are simultaneously > mounted, then it would be difficult for driver to switch ecc-schemes while > doing interleaved Read/Write between the partitions. > (though it can be added in framework, but then it's too much over-head). > agree Michael > In my opinion, kernel driver should be free from all over-heads, And should > be *as lite as possible, while continuing to be strong in catching bit-flips.* > Because there are lot of file-system layers over it, to handle more severe > failures. > Example: even if you use HAM1 and report un-correctable errors, still > UBIFS has too much redundancy of critical metadata, that it can still > recover your volume. > Therefore, I preferred having ecc-scheme selectable via DT (static) for > kernel. However these are purely my opinions based on my assessments. > > >> And we see real practical cases where being able >>to specify a different ECC scheme per partition would make sense: when >>the ROM code uses a weaker ECC scheme than the one used for most other >>partitions. >> > This constrain of changing ecc-scheme has come because ROM code > ecc-scheme is hardened to select HAM1. And so u-boot (bootloaders) > is used to between bridge gaps between ROM code and kernel. > - This could have been avoided, if u-boot still supported 'nandecc' OR > - ROM code had mechanism to change its ecc-scheme based on some > Boot-mode setting (sysboot pins on board). > > > So coming back to the specific problem here. > I think we need 'nandecc' back in u-boot till atleast all systems have > migrated to BCH16 or whatever highest ecc-scheme which can be > supported on OMAP devices. > > > with regards, pekon > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
