On 06/09/2019 09.12, Sascha Hauer wrote:
> Hi,
> 
> On Thu, Sep 05, 2019 at 10:26:06PM +0200, Sean Nyekjaer wrote:
>> Hi,
>>
>> I have been troubleshooting some CAN problems on our imx6ull with a raw nand
>> flash.
>> I normally run with a 4.19 series kernel, but to verify those CAN problems
>> have been resolved in newer kernels i have been trying ~5.3-rc6.
>>
>> But with that kernel i have run into trouble with ubifs, it throws a lot of
>> errors:
>> [  188.384572] Not a node, first 24 bytes:
>> [  188.384588] 00000000: ff ff ff 00 00 00 00 e4 03 00 00 a0 81 00 00 01 00
>> 00 00 00 00 00 00 00                          ........................
>> [  188.402976] UBIFS error (ubi0:8 pid 117): ubifs_read_node: bad node type
>> (0 but expected 3)
>> [  188.411605] UBIFS error (ubi0:8 pid 117): ubifs_read_node: bad node at
>> LEB 46:49888, LEB mapping status 1
>>
>> I started a bisect from Linux 5.3-rc7 (bad) to 5.2 (good).
>> And i'm ending up here:
>>
>> commit ef347c0cfd619a9251e5a2f9ff72e33650a9bccb (HEAD)
>> Author: Sascha Hauer <s.hauer@pengutronix.de>
>> Date:   Tue May 21 09:06:43 2019 +0200
> 
> Damn it
> 
>>
>>      mtd: rawnand: gpmi: Implement exec_op
>>
>> dmesg on boot:
>> [    1.229431] nand: device found, Manufacturer ID: 0x98, Chip ID: 0xdc
>> [    1.229472] nand: Toshiba NAND 512MiB 3,3V 8-bit
>> [    1.229510] nand: 512 MiB, SLC, erase size: 256 KiB, page size: 4096, OOB
> 
> 4k page size NAND, I didn't have such a device for testing, so indeed it
> could be that my patch is broken for 4k NANDs.
> 
>> size: 128
>> [    1.229547] ------------[ cut here ]------------
>> [    1.229604] WARNING: CPU: 0 PID: 1 at
>> drivers/mtd/nand/raw/internals.h:114 nand_reset_op+0x198/0x1c0
>> [    1.229633] Modules linked in:
> 
> This is unrelated. Please cherry-pick:
> 
> commit b2b5921fe4b363ff29fea9183aca089231a6bafc
> Author: Sascha Hauer <s.hauer@pengutronix.de>
> Date:   Tue May 21 10:43:35 2019 +0200
> 
>      mtd: rawnand: initialize ntargets with maxchips

Okay will do :-)

> 
>> [    1.231060] ---[ end trace 12b9d19a5aac4c9f ]---
>> [    1.234710] Bad block table not found for chip 0
>> [    1.236076] Bad block table not found for chip 0
>> [    1.236113] Scanning device for bad blocks
>> [    1.244907] random: fast init done
>> [    1.701764] Bad eraseblock 798 at 0x00000c780000
>> [    2.132734] Bad eraseblock 1536 at 0x000018000000
>> [    2.133094] Bad eraseblock 1537 at 0x000018040000
>> [    2.434057] Bad block table written to 0x00001ffc0000, version 0x01
>> [    2.437254] Bad block table written to 0x00001ff80000, version 0x01
> 
> I assume your device had a bbt before, right? In that case we won't have
> to go down to UBI, even a plain read seems to be broken.

Yes my devicetree looks like this:
&gpmi {
         pinctrl-names = "default";
         pinctrl-0 = <&pinctrl_gpmi_nand1>; 
 
 
 

         nand-on-flash-bbt;
         status = "okay";
};
> 
> Could you dump some NAND page with and without ef347c0cfd619a and see if
> and how they are different? Something like "nanddump -c -l 4096 /dev/mtdx"
> should do it. Maybe you have to adjust the starting address with the -s
> option to get some page with data.

nanddump -c -l 4096 -s 0x0040000 /dev/mtd0 > before
nanddump -c -l 4096 -s 0x0040000 /dev/mtd0 > after
files are attached... They don't differ

Is is better to dump them to gist?

/Sean

> 
> Also you could try the mtd test modules to see if tests fail.
> 
> Sascha
>