Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
On Thu, 30 Jan 2020 21:40:43 +0100 "Roger Pueyo Centelles | Guifi.net" wrote: > Hi Michal, > > El 29/1/20 a les 20:07, Michal Cieslakiewicz ha escrit: > > Please try adding 'qca,nand-swap-dma;' to '' section in > > router dts file. This in theory should fix endianness problem. > Yes, that worked! I also had to set nand-ecc-mode = "soft";, as > two-byte blocks were still swapped. > > By looking at C file, I have also found that this router uses > > model-specific ath79_nfc_set_scan_fixup() routine - a functionality > > that is not implemented in ath79, because there was no need for such > > quirks, at least not until now. > > Could this be related to the fact that the detected chip has 128 MiB, > but it is only usable up to 64 MiB? > > [ 0.774760] nand: Samsung NAND 128MiB 3,3V 8-bit > [ 0.779480] nand: 128 MiB, SLC, erase size: 128 KiB, page size: > 2048, OOB size: 64 > [ 0.787178] Scanning device for bad blocks > [ 0.797061] random: fast init done > [ 0.927117] 3 fixed-partitions partitions found on MTD device > ar934x-nand [ 0.934024] Creating 3 MTD partitions on "ar934x-nand": > [ 0.939338] 0x-0x0004 : "booter" > [ 0.945095] 0x0004-0x0040 : "kernel" > [ 0.950898] 0x0400-0x0bc0 : "ubi" > [ 0.955673] mtd: partition "ubi" extends beyond the end of device > "ar934x-nand" -- size truncated to 0x400 > > Kind regards, > > Roger > > Hello Roger, Glad to see progress in your struggle! 'qca,nand-swap-dma', looking at the driver code, works for 32-bit words so 16-bit swaps are kinda weird... ECC mode in ath79 defaults to HW while for ar71xx indeed it may be software-controlled. IMHO, there is still some work to be done on ar934x-nand driver side. I was porting it to ath79 for WNDR4300, that router does not require any special programming, and I'm no expert in NAND controllers. Anyway, code that has been left back in ar71xx may have to be included here for your Routerboard. As I've written before, mach-rb*.c files in ar71xx tree set some OOB ECC regions, apparently that functionality should be introduced as another qca-specific dts property. With this code in place, hopefully you will be able to use all 128 MiB flash space. Best regards Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Michal, El 29/1/20 a les 20:07, Michal Cieslakiewicz ha escrit: > Please try adding 'qca,nand-swap-dma;' to '' section in > router dts file. This in theory should fix endianness problem. Yes, that worked! I also had to set nand-ecc-mode = "soft";, as two-byte blocks were still swapped. > By looking at C file, I have also found that this router uses > model-specific ath79_nfc_set_scan_fixup() routine - a functionality > that is not implemented in ath79, because there was no need for such > quirks, at least not until now. Could this be related to the fact that the detected chip has 128 MiB, but it is only usable up to 64 MiB? [ 0.774760] nand: Samsung NAND 128MiB 3,3V 8-bit [ 0.779480] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [ 0.787178] Scanning device for bad blocks [ 0.797061] random: fast init done [ 0.927117] 3 fixed-partitions partitions found on MTD device ar934x-nand [ 0.934024] Creating 3 MTD partitions on "ar934x-nand": [ 0.939338] 0x-0x0004 : "booter" [ 0.945095] 0x0004-0x0040 : "kernel" [ 0.950898] 0x0400-0x0bc0 : "ubi" [ 0.955673] mtd: partition "ubi" extends beyond the end of device "ar934x-nand" -- size truncated to 0x400 Kind regards, Roger --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
On Wed, 29 Jan 2020 17:40:43 +0100 "Roger Pueyo Centelles | Guifi.net via openwrt-devel" wrote: > Hi all, > > It seems like the NAND flash is read with different endiannesses: > > [...] > > I wonder, though, which is the "correct" one --or how to change > ath79's, so that it is coherent with the previous target--. > > Roger > Hello Roger, Please try adding 'qca,nand-swap-dma;' to '' section in router dts file. This in theory should fix endianness problem. Explanation: In ar71xx target this router is initialized by file target/linux/ar71xx/files/arch/mips/ath79/mach-rb922.c. NAND controller setup is located in function rb922gs_nand_init(), there 'ath79_nfc_set_swap_dma(true)' is invoked. In ath79 device tree such byte-swapping is enabled by setting 'qca,nand-swap-dma'. By looking at C file, I have also found that this router uses model-specific ath79_nfc_set_scan_fixup() routine - a functionality that is not implemented in ath79, because there was no need for such quirks, at least not until now. Best regards Michal ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi all, It seems like the NAND flash is read with different endiannesses: root@ar71xx# hexdump /dev/mtd4 | head -n 2 000 3530 3935 f451 53ce 64a6 2e36 3234 010 312e 0032 root@ath79# hexdump /dev/mtd4 | head -n 2 000 3539 3035 ce53 51f4 a664 3432 362e 010 3200 2e31 I wonder, though, which is the "correct" one --or how to change ath79's, so that it is coherent with the previous target--. Roger El 27/1/20 a les 18:17, Roger Pueyo Centelles | Guifi.net ha escrit: > Hi Koen, > > Please find the bootlogs at: > > https://pastebin.com/PD5Lfx3p (ath79) > > https://pastebin.com/j1jBauQE (ar71xx) > > Cheers! > > El 27/1/20 a les 17:31, Koen Vandeputte ha escrit: >> Hi Roger, >> >> Can you send me full bootlogs please from both? >> >> I have RB922-5HPnD, not the AC version over here, but I guess the >> issue will also be present over there. >> >> Thanks again, >> >> Koen >> >> On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel >> wrote: >>> The sender domain has a DMARC Reject/Quarantine policy which disallows >>> sending mailing list messages using the original "From" header. >>> >>> To mitigate this problem, the original message has been wrapped >>> automatically by the mailing list software. >>> >>> ___ >>> openwrt-devel mailing list >>> openwrt-devel@lists.openwrt.org >>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > 0x5AF48A37E35766B1.asc Description: application/pgp-keys --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi Koen, Please find the bootlogs at: https://pastebin.com/PD5Lfx3p (ath79) https://pastebin.com/j1jBauQE (ar71xx) Cheers! El 27/1/20 a les 17:31, Koen Vandeputte ha escrit: > Hi Roger, > > Can you send me full bootlogs please from both? > > I have RB922-5HPnD, not the AC version over here, but I guess the > issue will also be present over there. > > Thanks again, > > Koen > > On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel > wrote: >> The sender domain has a DMARC Reject/Quarantine policy which disallows >> sending mailing list messages using the original "From" header. >> >> To mitigate this problem, the original message has been wrapped >> automatically by the mailing list software. >> >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
Hi Roger, Can you send me full bootlogs please from both? I have RB922-5HPnD, not the AC version over here, but I guess the issue will also be present over there. Thanks again, Koen On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel wrote: The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Hi, I'm working on porting a second MikroTik device, the RouterBOARD 922UAGS-5HPacD, from ar71xx to ath79 and I'm having trouble with the NAND storage. The chip is detected, but bad eraseblocks are reported when booting an initramfs image via TFTP (haven't tried sysupgrade yet): [ 0.791848] Creating 4 MTD partitions on "spi0.0": [ 0.796717] 0x-0xc000 : "routerboot" [ 0.802857] 0xc000-0xd000 : "art" [ 0.808379] 0xd000-0xe000 : "bios" [ 0.813924] 0xe000-0xf000 : "soft_config" [ 0.823549] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1 [ 0.830034] nand: Samsung NAND 128MiB 3,3V 8-bit [ 0.834717] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [ 0.842435] Scanning device for bad blocks [ 0.846909] Bad eraseblock 2 at 0x0004 [ 0.851500] Bad eraseblock 3 at 0x0006 [...] eraseblocks continue on all blocks, from 4 to 15 [ 0.911492] Bad eraseblock 16 at 0x0020 [ 1.036624] 3 fixed-partitions partitions found on MTD device ar934x-nand [ 1.043531] Creating 3 MTD partitions on "ar934x-nand": [ 1.048844] 0x-0x0004 : "booter" [ 1.054605] 0x0004-0x0040 : "kernel" [ 1.060369] 0x0040-0x0080 : "ubi" [ 1.477206] UBI error: unable to read from mtd6 The current 19.07.0 or snapshot ar71xx initramfs images do not complain about any bad eraseblocks, and can properly managa the UBI fs at mtd6: [ 3.402365] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xf1 [ 3.408818] nand: Samsung NAND 128MiB 3,3V 8-bit [ 3.413534] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64 [ 3.421239] Scanning device for bad blocks [ 3.579454] Creating 3 MTD partitions on "ar934x-nfc": [ 3.584716] 0x-0x0004 : "booter" [ 3.607604] 0x0004-0x0040 : "kernel" [ 3.630593] 0x0040-0x0800 : "ubi" It looks like the NAND chip is correctly detected, but I don't know what I'm missing that causes the [wrong] bad eraseblocks to appear. Any suggestions? The tree with the commit adding support is at https://github.com/rogerpueyo/openwrt/tree/ath79-mikrotik-rb-922uags-5hpacd_badblocks Thanks! Roger --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel