Aw: Re: Linux MTD: Per Partition ECC

[Andreas Bießmann]

Hi Steffen,

On 02/11/2014 04:43 PM, star at gmx.li wrote:
> It is clear to me, that I can't mix ECC at same time.
> I would like to switch at a certain point of time.
> 
> In uboot there is a command (nandecc) which does this for me.

Ok, understand. This command however is only available in omap3 devices
and exactly for that purpose. It was refused to implement a generic way
to switch ECC scheme for other SoC. The way to go seems to use the very
same ECC scheme as the ROM code uses (that is the case for at least Ti
devices like AM3xx family). Unfortunately this won't scale with changes
in NAND technology. So, yes, there might be the need for more
flexibility in NAND partitioning and ECC schemes.

> But howto do this in linux?

There is no builtin mechanism, you need to build one for your needs.

> The idea is to boot in a normal way (1 bit SW ECC).
> I need to copy all needed tools from flash to RAM (flash_eraseall, nandwrite, busybox)
> After that all partitions (uboot, kernel, root)  will be erased, written with new ECC scheme and rebooted.

That is the right way out.

> Thinking about this - once I read that it is possible to boot a new kernel out of linux.
> Not remember the preconditions, but this is probably the more complex way.

In my opinion this is the clean way. The 'copying required files to
ramfs' approach described above is widespread (at least in my feelings,
we used this approach in former devices too). The problem with this
approach is that you can't adopt the tools you need. The kexec approach
is more flexible here. Just my 2¢ and of course it is off topic here.

> Did I get it right: You managed it to boot your system (using flash content ?) and than unload the mtd module,
> reload it with a differen parameter and you are able to flash xloader?

Right, with a freshly booted linux out of the running linux. We switched
our update procedure to the kexec approach exactly for that reason. We
have a clean, controllable environment and can do just everything from
that running update system, including change of ecc scheme or even
change of mtd partitioning.

> Of course you cannot access all other partitions of flash during that.
> 
> In general that seems simular to my challenge - with the difference that I have to flash complete chain ...
> (at least uboot, environment, kernel, root).

We do exactly that, we do it sequentially and switch ecc scheme where
needed.

> You mentioned it is not possible to stick a /dev/mtdx to a certain ECC scheme. 

Well, it seems there is some work done regarding 'Per Partition ECC',
Boris Brezillon sent an RFC [1].

> My kernel is also rather old, (2.6.33) - so no hope that there is included this already.

That would be your job to get it working then. I can't say anything
about architectural changes in mtd framework since then.

> In kernel source it seems that each partition uses the copy of a so called master. Is more than one master possible?
> I didn't understand the precedure until now-
>
> If your are right, it is useless to double my partition scheme. Idea was to boot uboot from /dev/mtd1 but rewrite it with other ECC scheme at /dev/mtd6 as every partition is available with 2 names.

Regardless the meaningfulness of your approach, you need to flash a
kernel which is capable to do so and boot it again. So this would be a
two step approach to update your device. Why not just boot another linux
out of the running one which is capable to access your NAND with
different ECC schemes (however it is implemented) and do your update
procedure.

Best regards

Andreas Bießmann

[1] http://article.gmane.org/gmane.linux.drivers.mtd/51605


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20140212/c639971d/attachment.sig>