Hi Michal,
On my hardware, when the NAND driver loads OK, there are still anomalies:
the "used by" count is -2 in lsmod output for all MTD modules.
# lsmod
Module Size Used by
ofpart 2048 -2
sunxi_nand 18325 -2
ofnandpart 1476 -2
nand 67314 -2
nand_ecc 3350 -2
nand_ids 5853 -2
nand_hynix 3255 -2
mtd 40998 -2
There are too many core devices created. Consequently, unloading sunxi_nand
is impossible because this count is non-zero. I wonder if you noticed
something similar.
--Vladimir
On 13 January 2015 at 12:06, Michal Suchanek <hramr...@gmail.com> wrote:
> On 13 January 2015 at 12:34, Vladimir Komendantskiy
> <komendant...@gmail.com> wrote:
> > I tested the driver with a different Hynix chip, and it worked. Same
> driver,
> > same DTB but with my original Hynix chip causes the same this NULL
> pointer
> > error. Here are the extended IDs for the reference:
> >
> > Works fine:
> > {"H27UBG8T2BTR 4GiB 3.3V 8-bit",
> > { .id = {0xad, 0xd7, 0x94, 0xda, 0x74, 0xc3} },
> > SZ_8K, SZ_4K, SZ_2M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),
> > 4 },
> >
> > Fails:
> > {"H27UCG8T2ETR 8GiB 3.3V 8-bit",
> > { .id = {0xad, 0xde, 0x14, 0xa7, 0x42, 0x4a} },
> > SZ_16K, SZ_8K, SZ_4M, 0, 6, 1664, NAND_ECC_INFO(40, SZ_1K),
> > 4 },
>
> hmm, the block sizes are different so maybe some calculation fails.
>
> Try to add more debug prints in the function that causes the NULL
> pointer dereference to figure out what is null where, exactly.
>
> >
> > There are different procedures to set up read retry, so I have to
> > double-check if my implementation of the RR procedure for the second chip
> > might be faulty. Strangely, it works OK in my attempt to backport the
> Sunxi
> > MTD development to sunxi-3.4. But it's rather reduced, for example,
> there I
> > have no DTB but a FEX file.
> >
> > I agree that Allwinner bad blocks should be ignored, and possibly the MTD
> > driver is good enough to spot them dynamically again. However, those
> blocks
>
> It isn't good enough to spot them. I had 5 and 6 blocks that failed to
> erase on two nand chips and neither was marked after the fact by the
> MTD code to be recognized as bad when looking at it again.
>
> > would typically carry non-zero values in the positions where the
> > manufacturer would write zeros to indicate a bad block. To get rid of
> > allwinner-marked blocks while keeping manufacturer-marked ones, it might
> be
> > useful to skip over blocks with non-zero markers during creation of the
> BBT.
>
> The bad block marker is determined by matching a pattern. Almost all
> blocks on my Allwinner-formatted nand flash match this pattern to the
> point there is no room for storing the bbt. So Allwinner is using the
> bbm area for other data and the marks are totally worthless once
> livesuit was used on the nand chip.
>
> > Then those blocks can be safely erased.
>
> More or less.
>
> Thanks
>
> Michal
>
> --
> You received this message because you are subscribed to the Google Groups
> "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to linux-sunxi+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
