[Gta04-owner] NAND with 3.7 kernel?

[Dr. H. Nikolaus Schaller]

Am 19.03.2013 um 16:49 schrieb Dr. H. Nikolaus Schaller:

> 
> Am 19.03.2013 um 16:37 schrieb Rico Rommel:
> 
>> Am Dienstag, 19. März 2013, 15:41:49 schrieb Dr. H. Nikolaus Schaller:
>>> Anyone tried to enable jffs2 and to read/write the NAND flash written by the
>>> 2.6.32 kernel?
>>> 
>>> I only get strange error messages like:
>> 
>> I tried it multiple times and got the same errors. Another effect is, that now 
>> approximately 10% of flash memory are marked as bad. As I remember, it was the 
>> same with 3.4 and 3.5 kernels. 
> 
> Ah, good to know! Maybe it did never work with mainline kernels.
> 
>> Btw, is it safe or possible to scrub nand in u-boot to clean bad blocks?
> 
> Well, as long as you don't use NAND, you can leave it as it is.
> 
> The bad block management is done in some extra bits per sector and I suspect
> that there is some bug in the NAND driver which unnecessarily marks these
> sectors as bad. But if we manage to fix the drivers, we can do some
> 
> flash_eraseall -j /dev/mtd4
> 
> and it should set up a new and empty jffs2. If it finds bad blocks again, it will
> mark and ignore them again.
> 
> So the most important step is to find the right patches for the MTD and JFFS2 subsystems.
> 
> Since jffs2 is used on many different systems, I think it is more likely a problem in the
> DM3730 MTD driver (which has already been fixed in the non-mailine OMAP3 trees
> long ago).

I just did a quick diff between both versions of drivers/mtd/nand/omap2.c (which I assume
is the direct driver) and although the basic structure is the same, there are 142 differences
hiding almost anything what and why they were changed. And this is not the only file
which may have missing changes (e.g.plat_nand.c, nand_base.c, nand_ecc.c, ...).

A solution may be as simple as having a wrong/different config in the board file (haven't
checked yet) or some very subtle omission in the driver :(

-- hns