Changing the ECC method for a running system (UBI seems to use OOB?)
Hello everyone,
the problem which I have to solve is to change the type of the used ECC procedure for a linux system with UBIFS >>after<< the installation. For this purpose I have modified the first-stage bootloader so, that it reads all blocks with the old ECC method (software ECC 1-bit) and re-writes these with the new one (on-die hardware ECC, Micron flash).
The reason for that effort is, that the old method has to be proven as to bad (to much bit errors). Unfortunately it is not possible to install the system new with activated on-die ECC, because the hardware is scattered over the world.
The update procedure works in principle fine, that means, it is possible to update the blocks for kernel, u-boot, first-stage bootloader and environment variables. But the rootfs makes problems. Can it be, that UBIFS uses some bytes of the OOB structures, perhaps indirect?
Have someone any hints for me?
Best regards,
Steffen
Steffen,
We had exactly the same issue with our embedded systems (I'm really mad at Micron that they released the 4-bit ECC chips without as much as putting a warning message in the Linux kernel, but that's a separate topic...).
Anyhow, we modified the AT91bootstrap loader to convert the entire NAND from 1-bit sw-ecc to on-die 4-bit ECC. I'd be happy to send a patch to this mailing list if you think this would be useful.
UBI fortunately does not use OOB at all, so there should be no issue from there.
The subpage size has to match though. In our case, UBI was built for 512B subpage, but when turning on the on-die ECC support, it'd by default only support 2048B pages. The patch I sent earlier to this mailing list enables 512B subpage writes with on-die ECC.
--david
Quoted 33 lines · Steffen Kühn
Hello everyone,
the problem which I have to solve is to change the type of the used ECC procedure for a linux system with UBIFS >>after<< the installation. For this purpose I have modified the first-stage bootloader so, that it reads all blocks with the old ECC method (software ECC 1-bit) and re-writes these with the new one (on-die hardware ECC, Micron flash).
The reason for that effort is, that the old method has to be proven as to bad (to much bit errors). Unfortunately it is not possible to install the system new with activated on-die ECC, because the hardware is scattered over the world.
The update procedure works in principle fine, that means, it is possible to update the blocks for kernel, u-boot, first-stage bootloader and environment variables. But the rootfs makes problems. Can it be, that UBIFS uses some bytes of the OOB structures, perhaps indirect?
Have someone any hints for me?
Best regards,
Steffen______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Hello David,
Quoted 7 lines
We had exactly the same issue with our embedded systems (I'm really mad at Micron that they released the 4-bit ECC chips without as much as putting a warning message in the Linux kernel, but that's a separate topic...).
Anyhow, we modified the AT91bootstrap loader to convert the entire NAND from 1-bit sw-ecc to on-die 4-bit ECC. I'd be happy to send a patch to this mailing list if you think this would be useful.
Yes, this would be great! The patch is certainly also helpful for the next with the same problem ...
Quoted 3 lines
UBI fortunately does not use OOB at all, so there should be no issue from there.
I have read this too. I'm happy that I have not to deal with YAFFS2.
Quoted 5 lines
The subpage size has to match though. In our case, UBI was built for 512B subpage, but when turning on the on-die ECC support, it'd by default only support 2048B pages. The patch I sent earlier to this mailing list enables 512B subpage writes with on-die ECC.
That could be my problem. I have not considered this point. Thanks!
Best regards,
Steffen
Just to add one other point, you may need to skip programming "empty" pages when transcoding the data to the new ECC format. This will ensure the "empty" pages can be programmed correctly, when UBIFS attempts to use them.
Cheers,
Angus
Quoted 33 lines · Steffen Kühn
Hello David,
Quoted 7 lines
We had exactly the same issue with our embedded systems (I'm really mad at Micron that they released the 4-bit ECC chips without as much as putting a warning message in the Linux kernel, but that's a separate topic...).
Anyhow, we modified the AT91bootstrap loader to convert the entire NAND from 1-bit sw-ecc to on-die 4-bit ECC. I'd be happy to send a patch to this mailing list if you think this would be useful.
Yes, this would be great! The patch is certainly also helpful for the next with the same problem ...
Quoted 3 lines
UBI fortunately does not use OOB at all, so there should be no issue from there.
I have read this too. I'm happy that I have not to deal with YAFFS2.
Quoted 5 lines
The subpage size has to match though. In our case, UBI was built for 512B subpage, but when turning on the on-die ECC support, it'd by default only support 2048B pages. The patch I sent earlier to this mailing list enables 512B subpage writes with on-die ECC.
That could be my problem. I have not considered this point. Thanks!
Best regards,
Steffen______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
Signature · 8 lines
------------------------------------- Angus Clark ST Microelectronics (R&D) Ltd. 1000 Aztec West, Bristol, BS32 4SQ email: [email protected] tel: +44 (0) 1454 462389 st-tina: 065 2389 -------------------------------------