Re: OMAP3 NAND ECC selection
Le Mon, 9 Dec 2013 04:33:51 +, Gupta, Pekon pe...@ti.com a écrit : Hi, From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: [...] Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Just to highlight few more points: (1) ROM code on newer OMAP platforms like AM33xx do have the ability to select ECC scheme by reading a specific location from EEPROM connected to I2C0. AFAIK on omap3, the rom code first try to read data with bch and if it doesn't work it fallback on haming 1 bit ecc. (2) And going forward, ECC based NAND devices may be phased out, and BE-NAND (Built-in) NAND devices are becoming popular. As both cost and density wise they are same to SLC NANDs today. Thus issue of un-compatibility of ecc-scheme with ROM code, will not hold true. We already have some BE-NAND support in our generic driver. http://patchwork.ozlabs.org/patch/222186/ Yes but these flash are not always compatible with the ROM. If the rom is expecting some ECC and the internal controller expect other ecc you are stuck. Matthieu -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 NAND ECC selection
From: Matthieu CASTET [mailto:matthieu.cas...@parrot.com] From: Pekon Gupta [mailto: pe...@ti.com] From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: [...] Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Just to highlight few more points: (1) ROM code on newer OMAP platforms like AM33xx do have the ability to select ECC scheme by reading a specific location from EEPROM connected to I2C0. AFAIK on omap3, the rom code first try to read data with bch and if it doesn't work it fallback on haming 1 bit ecc. I'm afraid, the OMAP35xx TRM does give much information about BCH ecc-scheme being used by ROM code. Though it says that BCH4 ecc-scheme would be selected for booting in cases when NAND_ID2 matches a particular value. But nothing much is clear (Reference [1]). Can you please point me to any other document or link which gives more info about the same ? (2) And going forward, ECC based NAND devices may be phased out, and BE-NAND (Built-in) NAND devices are becoming popular. As both cost and density wise they are same to SLC NANDs today. Thus issue of un-compatibility of ecc-scheme with ROM code, will not hold true. We already have some BE-NAND support in our generic driver. http://patchwork.ozlabs.org/patch/222186/ Yes but these flash are not always compatible with the ROM. If the rom is expecting some ECC and the internal controller expect other ecc you are stuck. For AM33xx and newer DRA7xx platforms, allows user to explicitly select between no ECC, BCH8 or BCH16. Thus ROM code of newer OMAP devices supports BE-NAND. (refer [2]). [1] http://www.ti.com/product/omap3530 http://www.ti.com/litv/pdf/spruf98x Chapter 25: Initialization Section 25.4.7.4 NAND Table 25-34. ID2 Byte Description [2] http://www.ti.com/product/am3359 http://www.ti.com/litv/pdf/spruh73i Chapter 26: Initialization Section: 26.1.7.4 Memory Booting NAND Table 26-17. NAND Geometry Information on I2C EEPROM with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
On 12/05/2013 11:38 AM, Tony Lindgren wrote: * Thomas Petazzoni thomas.petazz...@free-electrons.com [131205 11:33]: Dear Brian Norris, On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Yeah and it seems that for the bootloader partition we need to be able to specify the ECC scheme in the .dts file to avoid having people trash their system unless they really want to do it. /me at least has rebooted and reflashed way too many times unnecessarily while trying to update MLO or u-boot from the kernel. The M-Sys/Sandisk docg4 flash chip has a similiar issue, but is even more esoteric than merely a different ecc scheme for the SPL/u-boot partition. Not only is a different ecc scheme used for the SPL (actually it uses no ecc at all), but the flash controller must be placed into a special (proprietary) mode (reliable mode) before the SPL is written. Like the omap2 solution, the docg4 driver can be loaded with a special module parameter that enables writing the SPL partition in this mode. The docg4 is kind of a special case, though, because it is a nand flash wrapped inside a proprietary non-standard flash controller. Mike -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 NAND ECC selection
Hi, From: Thomas Petazzoni [mailto:thomas.petazz...@free-electrons.com] On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: [...] Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Just to highlight few more points: (1) ROM code on newer OMAP platforms like AM33xx do have the ability to select ECC scheme by reading a specific location from EEPROM connected to I2C0. Reference: http://www.ti.com/product/am3359 http://www.ti.com/litv/pdf/spruh73i Chapter 26: Initialization Section: 26.1.7.4 Memory Booting NAND Table 26-17. NAND Geometry Information on I2C EEPROM (2) And going forward, ECC based NAND devices may be phased out, and BE-NAND (Built-in) NAND devices are becoming popular. As both cost and density wise they are same to SLC NANDs today. Thus issue of un-compatibility of ecc-scheme with ROM code, will not hold true. We already have some BE-NAND support in our generic driver. http://patchwork.ozlabs.org/patch/222186/ However, I also support user space tool approach rather than having this included in NAND driver. with regards, pekon -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Hello,
Meanwhile, to do this we use a small userspace program created by
Javier Martinez in order to flash the MLO in our OMAP3 boards. See
http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary
I tried this with a 3.7 kernel and the following NAND; it does not work
for me
# ./writeloader -i /boot/u-boot.img -o /dev/mtd1
Error writing ECC in OOB area: Invalid argument
nand_do_write_oob() in nand_base.c fails with
if ((ops-ooboffs + ops-ooblen) len) {
pr_debug(%s: attempt to write past end of page\n,
__func__);
return -EINVAL;
}
ops-ooboffs, ops-ooblen, len is 1536, 64, 64, resp.
write_ecc() in writeloader.c does
oob.start = (sector_cnt - 1) * SECTOR_SIZE;
oob.ptr = oobbuf;
oob.length = 64;
return ioctl(ofd, MEMWRITEOOB, oob) != 0;
where sector_cnt is 4
this looks weird to me -- any ideas?
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xbc (Micron NAND 512MiB 1,8V
16-bit), page size: 2048, OOB size: 64
# ./mtdinfo -a
Count of MTD devices: 6
Present MTD devices:mtd0, mtd1, mtd2, mtd3, mtd4, mtd5
Sysfs interface supported: yes
mtd0
Name: MLO
Type: nand
Eraseblock size:131072 bytes, 128.0 KiB
Amount of eraseblocks: 4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 512 bytes
OOB size: 64 bytes
Character device major/minor: 90:0
Bad blocks are allowed: true
Device is writable: true
mtd1
Name: u-Boot
Type: nand
Eraseblock size:131072 bytes, 128.0 KiB
Amount of eraseblocks: 4 (524288 bytes, 512.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size: 512 bytes
OOB size: 64 bytes
Character device major/minor: 90:2
Bad blocks are allowed: true
Device is writable: true
thanks, regards, p.
--
Peter Meerwald
+43-664-218 (mobile)
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
On 12/05/2013 06:13 PM, Tony Lindgren wrote: * Peter Meerwald pme...@pmeerw.net [131205 08:13]: I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 pretty much what I have been looking for, thanks! Hmm well both methods should work, but is there anything stopping us merging the module param patch to the mainline tree? We could do so, should I provide a proper patch? On the other hand I think this approach is a workaround to circumvent the MTD architecture flaws mostly needed in embedded systems where we control the whole environment. Should we really introduce this switch to the whole bunch of users working with mainline distros on their beagle style HW? I think the user space tool approach is more useful there. regards Andreas Bießmann signature.asc Description: OpenPGP digital signature
OMAP3 NAND ECC selection
Hello, on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme (hw) than the rootfs (sw) is there a way to tell the kernel which ECC scheme to use on a per-partition basis? I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Hi Peter, 2013/12/5 Peter Meerwald pme...@pmeerw.net: Hello, on OMAP3, the NAND area holding MLO and u-boot need a different ECC scheme (hw) than the rootfs (sw) There is some discussion around this, please take a look at this thread, http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html is there a way to tell the kernel which ECC scheme to use on a per-partition basis? At this moment this is not possible. I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary Hope it helps you. Regards, Enric thanks, regards, p. -- Peter Meerwald +43-664-218 (mobile) __ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Hi Peter, On 12/05/2013 10:47 AM, Enric Balletbo Serra wrote: 2013/12/5 Peter Meerwald pme...@pmeerw.net: snip I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 Best regards Andreas Bießmann signature.asc Description: OpenPGP digital signature
Re: OMAP3 NAND ECC selection
I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 pretty much what I have been looking for, thanks! p. -- Peter Meerwald +43-664-218 (mobile) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
* Peter Meerwald pme...@pmeerw.net [131205 08:13]: I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 pretty much what I have been looking for, thanks! Hmm well both methods should work, but is there anything stopping us merging the module param patch to the mainline tree? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
[adding Pekon and Thomas as cc] On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren t...@atomide.com wrote: * Peter Meerwald pme...@pmeerw.net [131205 08:13]: I'd like to be able to update MLO and u-boot from within a booted Linux system on the device (I have to resort to u-boot for that where I can control the ECC scheme used) Meanwhile, to do this we use a small userspace program created by Javier Martinez in order to flash the MLO in our OMAP3 boards. See http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary we used another aproach here. See http://article.gmane.org/gmane.linux.drivers.mtd/43804 pretty much what I have been looking for, thanks! Hmm well both methods should work, but is there anything stopping us merging the module param patch to the mainline tree? Hi Tony, In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. In fact the data-sheet for the NAND device used on the IGEPv2 board says: Minimum required ECC 4-bit ECC per 528 bytes || Minimum required ECC for block 0 1-bit ECC per 528 byte so I don't think we should impose a software limitation by having a global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the ti,nand-ecc-opt. I'll see if I can get some free time to try to implement that. Pekon does not agree with this solution though [2] Thanks a lot and best regards, Javier [0]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg98969.html [1]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99008.html [2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Hi Javier, (CCing Brian: What do you think about this?) On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote: On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren t...@atomide.com wrote: In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. [..] global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the ti,nand-ecc-opt. I'll see if I can get some free time to try to implement that. AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. While there are some per MTD device (which model each partition), the ECC mode is present in the, nand_chip structure. My understanding is that the NAND core hasn't been designed for this use case, and thus some major re-work is needed to accomplish it. Therefore, it's a much short-term solution to implement the OMAP module parameter to fix the issue. Of course, feel free to prove me wrong :-) -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Hi Ezequiel, On Thu, Dec 5, 2013 at 7:26 PM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: Hi Javier, (CCing Brian: What do you think about this?) On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote: On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren t...@atomide.com wrote: In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. [..] global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the ti,nand-ecc-opt. I'll see if I can get some free time to try to implement that. AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. Agreed, in fact if you look at what I shared from the Micron NAND datasheet used on IGEPv2 it says that different ECC schemes could be used for block 0 and the rest of the NAND so definitely this is a software limitation. While there are some per MTD device (which model each partition), the ECC mode is present in the, nand_chip structure. My understanding is that the NAND core hasn't been designed for this use case, and thus some major re-work is needed to accomplish it. I see thanks for the clarification. I'm not familiar with the MTD subsystem to be honest so I somehow misunderstood that other nand drivers did this already and thought that it was just a matter of adding support to the OMAP NAND driver. Therefore, it's a much short-term solution to implement the OMAP module parameter to fix the issue. Of course, feel free to prove me wrong :-) Agreed. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com Thanks a lot and best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: OMAP3 NAND ECC selection
Hi Ezequiel, From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] [...] AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. I had some reservations in doing so.. (as mentioned in previous email also [2]) I would rather like to understand long term benefits of such implementation. Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. [2]: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108136 [a]: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg99025.html [b]: http://git.isee.biz/?p=pub/scm/writeloader.git;a=summary with regards, pekon
Re: OMAP3 NAND ECC selection
Dear Gupta, Pekon, On Thu, 5 Dec 2013 19:02:22 +, Gupta, Pekon wrote: From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] [...] AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. I had some reservations in doing so.. (as mentioned in previous email also [2]) I would rather like to understand long term benefits of such implementation. The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Isn't handling hardware constraints properly not a sufficient motivation for doing something? Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. And you're not realizing that these solutions are ugly and impractical? Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
On Thu, Dec 5, 2013 at 10:26 AM, Ezequiel Garcia ezequiel.gar...@free-electrons.com wrote: (CCing Brian: What do you think about this?) On Thu, Dec 05, 2013 at 06:39:10PM +0100, Javier Martinez Canillas wrote: On Thu, Dec 5, 2013 at 6:13 PM, Tony Lindgren t...@atomide.com wrote: In the another thread [0] pointed out by Enric we were discussing the same issue. Thomas suggested [1] that ideally we should be able to set a per MTD partition ECC scheme. That way we can set 1 bit hamming for the first MTD partition that has the SPL that the boot ROM needs to read and the other partitions can use a more secure ECC scheme. I completely agree with him. [..] global ECC scheme and we should expand the GPMC NAND DT binding so partitions support the ti,nand-ecc-opt. I'll see if I can get some free time to try to implement that. AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. While there are some per MTD device (which model each partition), the ECC mode is present in the, nand_chip structure. My understanding is that the NAND core hasn't been designed for this use case, and thus some major re-work is needed to accomplish it. Yes, it looks like a lot of work for little benefit. IMO, the *right* thing to do is have the bootloader use a sufficiently strong ECC for the flash part, so you don't have to configure different strengths for different partitions. But I'll concede that it may be *nice* to have flexibility in some cases. Part of the difficulty is in making this generic for all types of NAND drivers. On some, you can simply change some high-level software parameters to use a different ECC mode, while others may require hooks for controlling hardware parameters. And switching this at runtime can end up being a lot of work, since a sequence of reads/writes alternating between two differently-configured partitions would rapid reconfiguration of the ECC controller, which previously only needed configured at module initialization time. It may be doable, but to commit to this approach, you must do a lot of work. Also, this requires major changes to the MTD framework. Right now, I believe MTD partitions are a very small shim layer, where the bulk of the MTD transactions are filtered through to the parent master MTD. Therefore, it's a much short-term solution to implement the OMAP module parameter to fix the issue. That's possible, but even there, I don't see what the real benefit is. If you only need special-case solutions (which it seems like this use case is) for updating bootloader data, can't a simple 1-bit ECC user-space tool (like the one you linked earlier) suffice? It seems like it's only a small convenience to place this flexibility in a module parameter, but it is much *less* generic; what if someone builds omap2 into the kernel (not as a module)? So the user-space tool seems superior in many cases. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
On Thu, Dec 5, 2013 at 11:06 AM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: On Thu, 5 Dec 2013 19:02:22 +, Gupta, Pekon wrote: From: Ezequiel Garcia [mailto:ezequiel.gar...@free-electrons.com] [...] AFAIK, there's no hardware limitation that would prevent us from setting a per-partition ECC, keep in mind this effort is not reduced to make devicetree accept ECC on the partitions. I had some reservations in doing so.. (as mentioned in previous email also [2]) I would rather like to understand long term benefits of such implementation. The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. Isn't handling hardware constraints properly not a sufficient motivation for doing something? I'm not convinced your hardware constraints are reasonable or generally useful. But I could be convinced otherwise. Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. And you're not realizing that these solutions are ugly and impractical? Solution [a] is both ugly and impractical. Solution [b] is only a little ugly but quite practical (you could flesh out a better user-space ECC library, then combine it with nanddump/nandwrite --noecc). Rewriting both the MTD and NAND layers is not exactly practical and may still yield something ugly. Brian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
Dear Brian Norris, On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Isn't handling hardware constraints properly not a sufficient motivation for doing something? I'm not convinced your hardware constraints are reasonable or generally useful. But I could be convinced otherwise. They may not be reasonable, but they exist :) Also, any constrain due to ROM code, or upgrading from remote can be handled using various alternative approaches like [a] and [b]. And you're not realizing that these solutions are ugly and impractical? Solution [a] is both ugly and impractical. Solution [b] is only a little ugly but quite practical (you could flesh out a better user-space ECC library, then combine it with nanddump/nandwrite --noecc). Rewriting both the MTD and NAND layers is not exactly practical and may still yield something ugly. It's not practical because it wasn't thought like this originally, but technically speaking, being able to use a different ECC scheme for different areas of the NAND makes a lot of sense. That being said, it is true that having a good and reusable userspace tool to write data with arbitrary ECC schemes would be useful to workaround this situation. Best regards, Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3 NAND ECC selection
* Thomas Petazzoni thomas.petazz...@free-electrons.com [131205 11:33]: Dear Brian Norris, On Thu, 5 Dec 2013 11:24:18 -0800, Brian Norris wrote: The long term benefits is simply to properly handle the hardware constraints. We have hardware platforms were parts of the NAND *MUST* use 1-bit ECC to be compatible with the ROM code, and other parts of the NAND *MUST* use stronger 4-bits or 8-bits ECC to comply with the NAND requirements. Using 1-bit ECC on NAND is not a long-term solution. Given that fact, I think your ROM code is what may need to change, not the entire MTD subsystem. As someone (Tom Rini maybe?) pointed out, today the shift is 1-bit ECC supported by ROM code vs. 4 or 8 bits required by NAND. But we can very well imagine that tomorrow ROM code will support BCH4 (and the NAND will ensure block 0 is OK for use with BCH4) but the rest of the NAND will require BCH16 or something like that. I'm not designing ROM code, and the fact that they today have this limitation, should be an indication that Linux should be capable of handling different ECC schemes to handle those hardware constraints. Yeah and it seems that for the bootloader partition we need to be able to specify the ECC scheme in the .dts file to avoid having people trash their system unless they really want to do it. /me at least has rebooted and reflashed way too many times unnecessarily while trying to update MLO or u-boot from the kernel. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
