Re: Linux MTD: Per Partition ECC

["Andreas Bießmann" <andreas.biessmann@corscience.de>]

[-- Attachment #1: Type: text/plain, Size: 3192 bytes --]

Dear star@gmx.li,

cc linux-mtd, one may have more information on that topic there.

On 02/11/2014 12:58 PM, star@gmx.li wrote:
> Dear Peter, dear Andreas,
> 
> I just found this during my research:
> 
> http://lists.infradead.org/pipermail/linux-mtd/2012-September/044120.html 
>
> I  have simular Problem, to update a device which runs on 1 bit SW-ECC out of linux to 'on-die-ECC'
> 
> I duplicated the board partition table (Linux 2.6.33) in a first step. Now each partition can be access  with 2 names
> /dev/mtd4 or /dev/mtd8 as example.

D'oh why the hell should one do that? I dunno if this is sane with
synchronisation between different access layers (e.g. two different
instances of filesystem).

> But how can I addict a ECC scheme to a certain partition? Do you think this is a possible way?
> So access /dev/mtd4 with software ECC and /dev/mtd8 with on-die-ecc?

AFAIK there is no way to do per partition ecc currently. So there is no
way to support this without changing the whole mtd framework.
But maybe there was some movement since my last check. Maybe one of the
mtd developers could comment on that.

Nevertheless the ECC scheme of Linux 1Bit hamming SW ECC is likely to be
different than the Micron (or whatever manufacturer you use)
'on-die-ECC', therefore there is no chance to support 'partition A' and
'partition B' working on the very same hardware with these different ECC
schemes. You can only support scheme A _or_ scheme B at a time. I mean
for the whole process of storing the data and reading it out of the
device. Is the data physically written with scheme A it would fail to
read with scheme B and vice versa.

> Andreas can you provide the complete patch for you version? 

You just found the complete patch [2] if you red the link mentioned above.

> Problem for me is, I am always running on a mtd partition.

Well, my patch provides a solution for a very special case. Doing system
update of embedded devices in the field and switching the ECC scheme of
one partition (the first one, which boot ROM is reading) to OMAP3 1 bit
hamming HW ECC scheme while the rest of the device is 8 bit BCH SW ECC
scheme (it is 'HW-assisted', cause of missing ELM in OMAP3; I know there
were some patches cleaning this up, dunno the current state).
I can do that cause we kexec the update firmware which brings the
omap-nand mtd driver as a module. That module then can be configured to
switch the ECC scheme when probing. The trick is to load it twice,
sequential with different setup.
As discussed in [1] this solution is only useful when doing such very
special update strategies. So sorry, I think it won't help you.

> As a workaround I do have 2 root partitions which can be boot alternatively.

Sorry, I fail to understand how that would help here. The point is you
need to patch your SPL, bootlaoder and kernel to support the newer ECC
scheme and update all of them at once. If the procedure fail then your
device is likely to be bricked ...

Best regards

Andreas Bießmann

[1] http://thread.gmane.org/gmane.linux.drivers.mtd/50364
[2] http://article.gmane.org/gmane.linux.drivers.mtd/43804


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]