On Fri, Sep 06, 2019 at 11:59:20AM +0200, Sean Nyekjaer wrote: > > > 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@xxxxxxxxxxxxxx> > > > 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@xxxxxxxxxxxxxx> > > 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? With mtd0 you took the blocks containing the bootloader. Try the one on which the UBI volume is. Also please pick a page that is almost full. You could generate a page with this (on the working kernel preferably): flash_erase /dev/mtd2 0 0 seq 2000 | dd bs=4096 count=1 | nandwrite /dev/mtd2 - Note this will erase /dev/mtd2 Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/