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 },
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
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. Then those blocks can be safely erased.
--Vladimir
On 12 January 2015 at 17:24, Michal Suchanek <hramr...@gmail.com> wrote:
> Hello,
>
> On 12 January 2015 at 17:59, Vladimir Komendantskiy
> <komendant...@gmail.com> wrote:
> > Hi Michal,
> >
> > Thanks for your patch. I tested it, arriving at the same result as before
> > (with mainline 3.19) except for your version is set to ignore real bad
> > blocks, which I hope was a temporary solution. I'm attaching the
> beginning
>
> Since Allwinner code overwrites the bad block marks when formatting
> the nand and there is no way to recover them there is no point looking
> at them unless you have a custom made device on which the Chinese
> never used the livesuit.
>
> > of the kernel panic dump. The NULL pointer happens during parsing the
> > partition table in the DT as a result of adding a NAND partition.
> >
> > I noticed that the driver calls nand_add_partition even if there are no
> > partitions in the DT. Is this driver behaviour consistent?
>
> I am not sure this is intended. However, bootable nand needs to have
> partitions so it is possibly untested to boot with unpartitioned nand.
>
> >
> > dump:
> >
> > [ 27.696237] Ignoring bad block marker at at 0x0001f23fc000.
> > [ 27.982825] Bad block table written to 0x0001ffc00000, version 0x01
> > [ 28.000800] Bad block table written to 0x0001ff800000, version 0x01
> > [ 28.008443] Unable to handle kernel NULL pointer dereference at
> virtual
> > address 00000713
> > [ 28.016602] pgd = c0004000
> > [ 28.019309] [00000713] *pgd=00000000
> > [ 28.022921] Internal error: Oops: 17 [#1] SMP ARM
> > [ 28.027621] Modules linked in: sunxi_nand(+) ofnandpart nand nand_ids
> > nand_hynix mtd nand_ecc
> > [ 28.036242] CPU: 0 PID: 70 Comm: kworker/u2:0 Not tainted
> > 3.19.0-rc3-00472-ge238956-dirty #16
> > [ 28.044753] Hardware name: Allwinner A1X (Device Tree)
> > [ 28.049886] task: df66ed00 ti: dec5c000 task.ti: dec5c000
> > [ 28.055290] PC is at kmem_cache_alloc+0x48/0x16c
> > [ 28.059911] LR is at getname_kernel+0x40/0x80
>
> I have this flash type:
> 4096 MiB, MLC, erase size: 1024 KiB, page size: 8192, OOB size: 640
>
> Since the partitions have to be in whole eraseblocks they should be at
> least 4M in size which seems to be the case. If so they should also
> have same number of data blocks so the bootloader should be happy.
>
> However, your partition specification is different from what I have in the
> DT:
>
> nand@0 {
> #address-cells = <2>;
> #size-cells = <2>;
> reg = <0>;
> allwinner,rb = <0>;
>
> nand-ecc-mode = "hw";
> nand-rnd-mode = "hw";
> nand-on-flash-bbt;
>
> boot0@0 {
> label = "boot0";
> reg = /bits/ 64 <0x0 0x200000>;
> nand-ecc-mode = "hw_syndrome";
> nand-rnd-mode = "hw";
> nand-randomizer-seeds = /bits/
> 16 <0x4a80>;
> };
>
> boot0-rescue@200000 {
> label = "boot0-rescue";
> reg = /bits/ 64 <0x200000
> 0x200000>;
> nand-ecc-mode = "hw_syndrome";
> nand-rnd-mode = "hw";
> nand-randomizer-seeds = /bits/
> 16 <0x4a80>;
> };
>
> main@200000 {
> label = "main";
> reg = /bits/ 64 <0x400000
> 0xffc00000>;
> nand-ecc-mode = "hw";
> nand-rnd-mode = "hw";
> nand-randomizer-seeds = /bits/ 16 <
> 0x2b75 0x0bd0 0x5ca3
> 0x62d1 0x1c93 0x07e9 0x2162 0x3a72
> 0x0d67 0x67f9 0x1be7
> 0x077d 0x032f 0x0dac 0x2716 0x2436
> 0x7922 0x1510 0x3860
> 0x5287 0x480f 0x4252 0x1789 0x5a2d
> 0x2a49 0x5e10 0x437f
> 0x4b4e 0x2f45 0x216e 0x5cb7 0x7130
> 0x2a3f 0x60e4 0x4dc9
> 0x0ef0 0x0f52 0x1bb9 0x6211 0x7a56
> 0x226d 0x4ea7 0x6f36
> 0x3692 0x38bf 0x0c62 0x05eb 0x4c55
> 0x60f4 0x728c 0x3b6f
> 0x2037 0x7f69 0x0936 0x651a 0x4ceb
> 0x6218 0x79f3 0x383f
> 0x18d9 0x4f05 0x5c82 0x2912 0x6f17
> 0x6856 0x5938 0x1007
> 0x61ab 0x3e7f 0x57c2 0x542f 0x4f62
> 0x7454 0x2eac 0x7739
> 0x42d4 0x2f90 0x435a 0x2e52 0x2064
> 0x637c 0x66ad 0x2c90
> 0x0bad 0x759c 0x0029 0x0986 0x7126
> 0x1ca7 0x1605 0x386a
> 0x27f5 0x1380 0x6d75 0x24c3 0x0f8e
> 0x2b7a 0x1418 0x1fd1
> 0x7dc1 0x2d8e 0x43af 0x2267 0x7da3
> 0x4e3d 0x1338 0x50db
> 0x454d 0x764d 0x40a3 0x42e6 0x262b
> 0x2d2e 0x1aea 0x2e17
> 0x173d 0x3a6e 0x71bf 0x25f9 0x0a5d
> 0x7c57 0x0fbe 0x46ce
> 0x4939 0x6b17 0x37bb 0x3e91 0x76db>;
> };
> };
> };
>
> I did not read the format of this table and just copied it but it
> looks like you are specifying partition size of 0 which would
> obviously cause the code to fail one way or another.
>
> 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.
