Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.25. 11:26 keltezéssel, Gabor Juhos írta: Now I tried to create a UBI volume using the initramfs-Kernel. I get this kernel crash dump: # ubiattach -m 8 /dev/ubi_ctrl [ 3712.32] UBI: attaching mtd8 to ubi0 [ 3712.51] UBI: scanning is finished [ 3712.52] UBI: empty MTD device detected [ 3712.52] CPU 0 Unable to handle kernel paging request at virtual address , epc == , ra == 802094fc [ 3712.53] Oops[#1]: [ 3712.53] CPU: 0 PID: 1216 Comm: ubiattach Not tainted 3.10.12 #10 [ 3712.53] task: 878b5d50 ti: 8654c000 task.ti: 8654c000 [ 3712.53] $ 0 : 0001 8037c810 [ 3712.53] $ 4 : 87826010 0001 01ff 0200 [ 3712.53] $ 8 : 0005 80064830 [ 3712.53] $12 : d8197822 [ 3712.53] $16 : 878261b8 87826010 86e34000 [ 3712.53] $20 : 0200 86e34500 86e34d00 0007 [ 3712.53] $24 : [ 3712.53] $28 : 8654c000 8654dae8 802094fc [ 3712.53] Hi: [ 3712.53] Lo: 0010 [ 3712.53] epc : (null) [ 3712.53] Not tainted [ 3712.53] ra: 802094fc nand_write_subpage_hwecc+0xa0/0x1c4 Hm, this is a NULL pointer dereference. It seems that the nand_write_subpage_hwecc function tries to run a callback which is not initialized by the ar934x-nfc driver. I will look into that later. FYI, I have disabled writing of subpages in the driver. It is not supported by the controller if hardware ECC is used. At least I was not able to make it work. In the past, I have tested the ar934x-nfc driver (w/o hw ECC) with the modules provided by the mtdtests package and it passed all tests. Ideally, it should be tested again with hw ECC support but that is quite dangerous on devices which are using a NAND flash only. It passes all MTD tests now. Tested on the first MB of the reserved area on a on the WNDR4300: root@OpenWrt:/# cat /proc/mtd dev:size erasesize name mtd0: 0004 0002 u-boot mtd1: 0004 0002 u-boot-env mtd2: 0004 0002 caldata mtd3: 0008 0002 pot mtd4: 0020 0002 language mtd5: 0008 0002 config mtd6: 0030 0002 traffic_meter mtd7: 0012 0002 kernel mtd8: 017e 0002 rootfs mtd9: 0190 0002 firmware mtd10: 0004 0002 caldata_backup mtd11: 0010 0002 test mtd12: 05f0 0002 reserved root@OpenWrt:/# insmod /lib/modules/3.10.12/mtd_readtest.ko dev=11 [ 53.39] [ 53.39] = [ 53.40] mtd_readtest: MTD device: 11 [ 53.40] mtd_readtest: MTD device size 1048576, eraseblock size 131072, page size 2048, count of eraseblocks 8, pages per eraseblock 64, OOB size 64 [ 53.42] mtd_readtest: scanning for bad eraseblocks [ 53.42] mtd_readtest: scanned 8 eraseblocks, 0 are bad [ 53.43] mtd_readtest: testing page read [ 53.76] mtd_readtest: finished [ 53.77] = root@OpenWrt:/# insmod /lib/modules/3.10.12/mtd_speedtest.ko dev=11 [ 115.18] [ 115.18] = [ 115.19] mtd_speedtest: MTD device: 11 [ 115.19] mtd_speedtest: MTD device size 1048576, eraseblock size 131072, page size 2048, count of eraseblocks 8, pages per eraseblock 64, OOB size 64 [ 115.21] mtd_speedtest: scanning for bad eraseblocks [ 115.22] mtd_speedtest: scanned 8 eraseblocks, 0 are bad [ 115.23] mtd_speedtest: testing eraseblock write speed [ 115.48] mtd_speedtest: eraseblock write speed is 4162 KiB/s [ 115.49] mtd_speedtest: testing eraseblock read speed [ 115.80] mtd_speedtest: eraseblock read speed is 3313 KiB/s [ 115.81] mtd_speedtest: testing page write speed [ 116.07] mtd_speedtest: page write speed is 4129 KiB/s [ 116.07] mtd_speedtest: testing page read speed [ 116.39] mtd_speedtest: page read speed is 3303 KiB/s [ 116.40] mtd_speedtest: testing 2 page write speed [ 116.65] mtd_speedtest: 2 page write speed is 4162 KiB/s [ 116.66] mtd_speedtest: testing 2 page read speed [ 116.97] mtd_speedtest: 2 page read speed is 3303 KiB/s [ 116.98] mtd_speedtest: Testing erase speed [ 116.99] mtd_speedtest: erase speed is 170666 KiB/s [ 116.99] mtd_speedtest: Testing 2x multi-block erase speed [ 117.00] mtd_speedtest: 2x multi-block erase speed is 341333 KiB/s [ 117.01] mtd_speedtest: Testing 4x multi-block erase speed [ 117.02] mtd_speedtest: 4x multi-block erase speed is 341333 KiB/s [ 117.02] mtd_speedtest: Testing 8x multi-block erase speed [ 117.03] mtd_speedtest: 8x multi-block erase speed is 341333 KiB/s [ 117.04] mtd_speedtest: Testing 16x multi-block erase speed [ 117.05] mtd_speedtest: 16x multi-block erase
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Am 2013-09-27 13:25, schrieb Gabor Juhos: 2013.09.25. 11:26 keltezéssel, Gabor Juhos írta: Hm, this is a NULL pointer dereference. It seems that the nand_write_subpage_hwecc function tries to run a callback which is not initialized by the ar934x-nfc driver. I will look into that later. FYI, I have disabled writing of subpages in the driver. It is not supported by the controller if hardware ECC is used. At least I was not able to make it work. In the past, I have tested the ar934x-nfc driver (w/o hw ECC) with the modules provided by the mtdtests package and it passed all tests. Ideally, it should be tested again with hw ECC support but that is quite dangerous on devices which are using a NAND flash only. It passes all MTD tests now. Tested on the first MB of the reserved area on a on the WNDR4300: Great thanks! Using this patch I could successfully boot a kernel with a UBI-image flashed by U-Boot! However, I try now to understand the boot process/flashing process of Netgears U-Boot and OpenWRT itself. I try to understand the image/Makefile. On WNDR4300 I do understand the normal process: Netgear checks the kernel header and the rootfs header (which are altered versions of the default U-Boot (special magic)). Then the kernel starts booting. I could use the same tool which is used for WNDR3700(v2) routers to replace the header (the wndr3700 utility). Now I try to understand how the upgrade mechanism works. This is what I see when reading WNDR4300 U-Boot code (mainly the magic happens in StartTftpServerToRecoveFirmware): When in Factory Reset Mode, a TFTP server is running. After the user downloaded a file, the system checks the DNI header. Next data after the DNI header is flashed to a fixed address (length to be written is taken from file size according to TFTP): #define CFG_IMAGE_BASE_ADDR0x6c #define CFG_IMAGE_LEN 0x194 Bad blocks are simply ignored (data is written to next block). U-Boot doesnt clean the whole device, only the length of the image will be cleaned! If data fits not in available space, or too many blocks had to be skipped, U-Boot stops flashing and prints an error. But theres no other handling, than that, so system would try to start despite that fact... printf(** FAIL !! too many bad blocks, no enough space for data.\n); (This could be useful: UBI needs all blocks cleaned! We can create a image which is filled with 0xff. U-Boot would clean the whole NAND, and it would work even on devices with bad blocks) I try now to understand how image/Makefile works. So when the kernel is backed, put in a LZMA packed uImage. Then wndr3700 changes the magic. Now things are a bit confusing to me: It gets packet using mksquashfs-lzma, again mkimaged and then the headers are replaced again.. Why? And this whole image is used for the sysupgrade and factory reset image... Who is unpacking/flashing this? The original Netgear WNDR4300 image contains only DNI = uImage... Are things working differently for WNDR3700? How? -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.24. 23:07 keltezéssel, Stefan Agner írta: Am 2013-09-24 19:09, schrieb Gabor Juhos: A dd command with conv=noerror leads to a image witch is 16KiB smaller than it should be. Don't use dd on NAND flashes. Use the nanddump utility from the mtd-utils package instead. Ok I understand that /dev/mtdblock[x] is not the way to handle NAND, but reading should work anyway. Yes, it should work. However the mtdblock layer can't handle bad blocks/ecc errors so that throws error messages. By using nanddump I could successfully dump the images, although the ECC check corrected bitflips. I guess that when using this NAND through mtdblock, this leads to an I/O error (since its the exactly same place, 2880*512 = 0x00168000). root@OpenWrt:/tmp# dd if=/dev/mtdblock10 of=/tmp/gaga [ 1350.92] end_request: I/O error, dev mtdblock10, sector 2880 [ 1350.92] Buffer I/O error on device mtdblock10, logical block 360 [ 1351.00] end_request: I/O error, dev mtdblock10, sector 2880 [ 1351.00] Buffer I/O error on device mtdblock10, logical block 360 dd: /dev/mtdblock10: Input/output error root@OpenWrt:/tmp# nanddump /dev/mtd10 /tmp/wndr4300-mtd10-nanddump.img --omito ob --bb=skipbad ECC failed: 0 ECC corrected: 48 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 64 Dumping data starting at 0x and ending at 0x0190... ECC: 16 corrected bitflip(s) at offset 0x00168000 But this is not a showstopper than, since the driver seems to work correctly using the mtd interface. Did you write/erase the any of the partitions by any chance? Hm, I think I played around mounting the jffs2 partition once.. this should be after the CRC checked squashfs, but maybe I used the wrong mtd. This would explain the error. I reflashed the image, since then it boots fine even after using nanddump etc. from initram Ok. Even if you have used the correct mtd device, writing something into that can cause bit-flips in other erase blocks due to the common 'Write Disturb' problem. Now I tried to create a UBI volume using the initramfs-Kernel. I get this kernel crash dump: # ubiattach -m 8 /dev/ubi_ctrl [ 3712.32] UBI: attaching mtd8 to ubi0 [ 3712.51] UBI: scanning is finished [ 3712.52] UBI: empty MTD device detected [ 3712.52] CPU 0 Unable to handle kernel paging request at virtual address , epc == , ra == 802094fc [ 3712.53] Oops[#1]: [ 3712.53] CPU: 0 PID: 1216 Comm: ubiattach Not tainted 3.10.12 #10 [ 3712.53] task: 878b5d50 ti: 8654c000 task.ti: 8654c000 [ 3712.53] $ 0 : 0001 8037c810 [ 3712.53] $ 4 : 87826010 0001 01ff 0200 [ 3712.53] $ 8 : 0005 80064830 [ 3712.53] $12 : d8197822 [ 3712.53] $16 : 878261b8 87826010 86e34000 [ 3712.53] $20 : 0200 86e34500 86e34d00 0007 [ 3712.53] $24 : [ 3712.53] $28 : 8654c000 8654dae8 802094fc [ 3712.53] Hi: [ 3712.53] Lo: 0010 [ 3712.53] epc : (null) [ 3712.53] Not tainted [ 3712.53] ra: 802094fc nand_write_subpage_hwecc+0xa0/0x1c4 Hm, this is a NULL pointer dereference. It seems that the nand_write_subpage_hwecc function tries to run a callback which is not initialized by the ar934x-nfc driver. I will look into that later. In the past, I have tested the ar934x-nfc driver (w/o hw ECC) with the modules provided by the mtdtests package and it passed all tests. Ideally, it should be tested again with hw ECC support but that is quite dangerous on devices which are using a NAND flash only. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.23. 22:07 keltezéssel, Stefan Agner írta: Am 2013-09-23 21:08, schrieb Gabor Juhos: It should be possible to fix the board via JTAG. At least it seems that the PCB has an unpopulated JTAG header. Yes I thought about this too, but since I didn't found an openocd configuration which should work with this SoC, I didn't even tried it. I guess I would download U-Boot to RAM and try to reflash U-Boot from there, right? Yes, that would be the simplest method. Do you have a working JTAG toolchain for this SoC? Nope, I did not have to use JTAG on any AR934x based boards yet. Today I tested the driver. After adding the relevant Kernel configuration (CONFIG_MTD_NAND_AR934X_HW_ECC) I could successfully read from the device, data look good. However, when I tried to dd the whole kernel I get some errors: # dd if=/dev/mtdblock7 of=/tmp/wndr4300-mtd7-kernel.img [ 325.31] end_request: I/O error, dev mtdblock7, sector 424 [ 325.31] Buffer I/O error on device mtdblock7, logical block 53 [ 325.34] end_request: I/O error, dev mtdblock7, sector 536 [ 325.34] Buffer I/O error on device mtdblock7, logical block 67 [ 325.38] end_request: I/O error, dev mtdblock7, sector 424 [ 325.38] Buffer I/O error on device mtdblock7, logical block 53 dd: /dev/mtdblock7: Input/output error My first guess was this is/are bad blocks. But U-Boot seems not to support this idea: ar7240 nand bad Device 0 bad blocks: ar7240 Maybe U-Boot's bad block management doesn't work with those information... Despite what U-Boot says, those still can be bad blocks. The ar934x-ncf driver has no special bad block handling yet. A dd command with conv=noerror leads to a image witch is 16KiB smaller than it should be. Don't use dd on NAND flashes. Use the nanddump utility from the mtd-utils package instead. After working only with initramfs, the default Firmware doesn't boot anymore: ** check rootfs image ** Verifying Checksum ...Bad Data CRC This CRC checks the rootfs. Netgear put another uImage header just before the rootfs partition (but still in the kernel partition). It looks like the Kernel already changed something on NAND, which causes this Bad Data CRC... I then flashed the latest Netgear Firmware again. Guess what, I could successfully dd the whole kernel... But dd the rootfs still has Buffer I/O errors. Any idea what could go wrong here? I think it would be a good idea to figure out whats wrong before doing further steps... Well, the hardware ECC support in ar934x-nfc driver might contain some bugs. However, I don't think that the kernel writes anything into the flash by itself. Did you write/erase the any of the partitions by any chance? -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Am 2013-09-24 19:09, schrieb Gabor Juhos: A dd command with conv=noerror leads to a image witch is 16KiB smaller than it should be. Don't use dd on NAND flashes. Use the nanddump utility from the mtd-utils package instead. Ok I understand that /dev/mtdblock[x] is not the way to handle NAND, but reading should work anyway. By using nanddump I could successfully dump the images, although the ECC check corrected bitflips. I guess that when using this NAND through mtdblock, this leads to an I/O error (since its the exactly same place, 2880*512 = 0x00168000). root@OpenWrt:/tmp# dd if=/dev/mtdblock10 of=/tmp/gaga [ 1350.92] end_request: I/O error, dev mtdblock10, sector 2880 [ 1350.92] Buffer I/O error on device mtdblock10, logical block 360 [ 1351.00] end_request: I/O error, dev mtdblock10, sector 2880 [ 1351.00] Buffer I/O error on device mtdblock10, logical block 360 dd: /dev/mtdblock10: Input/output error root@OpenWrt:/tmp# nanddump /dev/mtd10 /tmp/wndr4300-mtd10-nanddump.img --omito ob --bb=skipbad ECC failed: 0 ECC corrected: 48 Number of bad blocks: 0 Number of bbt blocks: 0 Block size 131072, page size 2048, OOB size 64 Dumping data starting at 0x and ending at 0x0190... ECC: 16 corrected bitflip(s) at offset 0x00168000 But this is not a showstopper than, since the driver seems to work correctly using the mtd interface. Did you write/erase the any of the partitions by any chance? Hm, I think I played around mounting the jffs2 partition once.. this should be after the CRC checked squashfs, but maybe I used the wrong mtd. This would explain the error. I reflashed the image, since then it boots fine even after using nanddump etc. from initram Now I tried to create a UBI volume using the initramfs-Kernel. I get this kernel crash dump: # ubiattach -m 8 /dev/ubi_ctrl [ 3712.32] UBI: attaching mtd8 to ubi0 [ 3712.51] UBI: scanning is finished [ 3712.52] UBI: empty MTD device detected [ 3712.52] CPU 0 Unable to handle kernel paging request at virtual address , epc == , ra == 802094fc [ 3712.53] Oops[#1]: [ 3712.53] CPU: 0 PID: 1216 Comm: ubiattach Not tainted 3.10.12 #10 [ 3712.53] task: 878b5d50 ti: 8654c000 task.ti: 8654c000 [ 3712.53] $ 0 : 0001 8037c810 [ 3712.53] $ 4 : 87826010 0001 01ff 0200 [ 3712.53] $ 8 : 0005 80064830 [ 3712.53] $12 : d8197822 [ 3712.53] $16 : 878261b8 87826010 86e34000 [ 3712.53] $20 : 0200 86e34500 86e34d00 0007 [ 3712.53] $24 : [ 3712.53] $28 : 8654c000 8654dae8 802094fc [ 3712.53] Hi: [ 3712.53] Lo: 0010 [ 3712.53] epc : (null) [ 3712.53] Not tainted [ 3712.53] ra: 802094fc nand_write_subpage_hwecc+0xa0/0x1c4 [ 3712.53] Status: 1100dc03 KERNEL EXL IE [ 3712.53] Cause : 0088 [ 3712.53] BadVA : [ 3712.53] PrId : 0001974c (MIPS 74Kc) [ 3712.53] Modules linked in: ath9k ath9k_common pppoe ppp_async iptable_nat ath9k_hw ath pppox ppp_generic nf_nat_ipv4 nf_conntrack_ipv4 mac80211 ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_CT slhc nf_nat_irc nf_nat_ftp nf_nat nf_defrag_ipv4 nf_conntrack_irc nf_conntrack_ftp iptable_raw iptable_mangle iptable_filter ipt_REJECT ip_tables crc_ccitt compat ledtrig_usbdev ledtrig_netdev ip6t_REJECT ip6t_rt ip6t_hbh ip6t_mh ip6t_ipv6header ip6t_frag ip6t_eui64 ip6t_ah ip6table_raw ip6table_mangle ip6table_filter ip6_tables x_tables nf_conntrack_ipv6 nf_conntrack nf_defrag_ipv6 ipv6 arc4 crypto_blkcipher usb_storage leds_gpio ohci_hcd ledtrig_timer ledtrig_default_on ehci_platform ehci_hcd sd_mod scsi_mod gpio_button_hotplug ext4 jbd2 mbcache usbcore nls_base usb_common crc32c crypto_hash [ 3712.53] Process ubiattach (pid: 1216, threadinfo=8654c000, task=878b5d50, tls=77b24440) [ 3712.53] Stack : 1040 80099d00 0004 0010 8037c810 878261b8 87826010 0200 86e34500 0001 0fc0 0fc0 802093ac 878261b8 80208f98 878261b8 86e34500 878261b8 878261b8 8654dc00 87826010 0200 0200 0fc0 80209d18 8794e600 8654dc08 86e34500 ... [ 3712.53] Call Trace: [ 3712.53] [80099d00] __wake_up+0x24/0x44 [ 3712.53] [802093ac] nand_write_page+0xc0/0x170 [ 3712.53] [80208f98] nand_release_device+0x30/0x3c [ 3712.53] [80209d18] nand_do_write_ops+0x308/0x3c4 [ 3712.53] [801fb0d0] part_erase+0x22c/0x2c8 [ 3712.53] [80209f28] nand_write+0x5c/0x94 [ 3712.53] [8021ae34] ubi_io_write+0x350/0x618 [ 3712.53] [8020048c] erase_callback+0x0/0x14 [ 3712.53] [8021b2ec] ubi_io_write_ec_hdr+0xf0/0x108 [
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.22. 22:43 keltezéssel, Stefan Agner írta: Am 2013-09-17 08:18, schrieb Gabor Juhos: 2013.09.16. 1:06 keltezéssel, Stefan Agner írta: It is done in software in the ar934x-nfc driver. The NAND controller of the AR934x SoCs also supports hardware based ECC calculation but that is not yet implemented in the driver. The hardware based ECC might use a different OOB layout and that would cause similar problems if thas is enabled in the bootloader. I checked that in the original firmware, they definitly use hardware NAND, in both, the Kernel and Bootloader (actually its the same driver). Yes, I have found that in the meantime. I guess that it would be easy to figure out if the bootloader uses a different OOB layout or not. I saw your commits 38069-38071, did you test them on a actual device? I have used a WNDR4300 for testing. I erased my U-Boot when I used nand erase clean, somehow my command line got parsed wrong :-( Sad, but that happens sometimes. I also did that on a few boxes already. I'll try to get a new device and test your changes. It should be possible to fix the board via JTAG. At least it seems that the PCB has an unpopulated JTAG header. The kernel automatically sets the rootfs partition to be the root filesystem if the 'CONFIG_MTD_ROOTFS_ROOT_DEV' option is set. Thanks, this was a missing piece in my mind :-) ;-) I split those targets, will send a patch as soon as I've got something useful. Ok. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Am 2013-09-17 08:18, schrieb Gabor Juhos: 2013.09.16. 1:06 keltezéssel, Stefan Agner írta: It is done in software in the ar934x-nfc driver. The NAND controller of the AR934x SoCs also supports hardware based ECC calculation but that is not yet implemented in the driver. The hardware based ECC might use a different OOB layout and that would cause similar problems if thas is enabled in the bootloader. I checked that in the original firmware, they definitly use hardware NAND, in both, the Kernel and Bootloader (actually its the same driver). I guess that it would be easy to figure out if the bootloader uses a different OOB layout or not. I saw your commits 38069-38071, did you test them on a actual device? I erased my U-Boot when I used nand erase clean, somehow my command line got parsed wrong :-( I'll try to get a new device and test your changes. The kernel automatically sets the rootfs partition to be the root filesystem if the 'CONFIG_MTD_ROOTFS_ROOT_DEV' option is set. Thanks, this was a missing piece in my mind :-) I split those targets, will send a patch as soon as I've got something useful. - Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.14. 13:00 keltezéssel, Joris írta: Hello list, I posted an initial, quite horrible, patch to the forums to try and get the WNDR4300 working. I am not that experienced in either posting to lists or embedded development, so please do inform me of any mistakes I may have made. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. That is good to know and probably quite quick to test (which is easy for me to say as I have not found the courage yet to solder a serial connection). IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. It would indeed be a cleaner solution, however I gather from [2] that performance differences are minimal. Furthermore, direct support for UBI-SquashFS is not in mainline, according to [5], and the latest proposed patch I could find went AWOL after someone gave comments [6]. The referred solution also uses an intermediate layer. Under direct support I mean that the the squashfs code should be extended, in order to able to use an UBI volume directly without any intermediate layer. Looking at the current layout [7], I think an initial solution would be to use mtd8 'rootfs' as single UBI volume and layering SquashFS on top via gluebi and mtdblock_ro. Of course, if the amount of work is comparable for direct versus gluebi, the direct scenario makes more sense. For the gluebi based solution, every component is available in the mainline kernel so this would be the simplest way. However, I still don't like the complexity of it. For 'ubi-ubiblk-squashfs' patches are also available on various mailing lists but those must be actualized for the current kernel probably. It seems that this is the last version of the patch: http://lists.infradead.org/pipermail/linux-mtd/2012-December/045274.html For the direct solution, there are no public patches available. For the overlay, we could use the existing mtd12 'reserved' (for what, I wonder) as JFFS2 since that already includes bad block management. Using mtd12 would have the added advantage of providing a _huge_ amount of storage, while keeping the original layout of the flash, so it should be easy to revert to stock that way. One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. So _if_ one UBI volume was used this would be true, but since your proposal includes two UBI volumes, it works around the CRC check, right? Yes, in theory. Although I don't exactly know which part of the rootfs partition is covered by the CRC value. -Gabor Joris 1. https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c#L235 2. http://elinux.org/Flash_Filesystem_Benchmarks 3. http://lists.infradead.org/pipermail/linux-mtd/2013-February/045794.html 4. https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/image/Makefile#L63 5. http://elinux.org/Flash_Filesystem_Benchmarks_Protocol#Tested_filesystems 6. https://lkml.org/lkml/2011/10/1/51 7. http://wiki.openwrt.org/toh/netgear/wndr4300#visual.representation ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
2013.09.16. 1:06 keltezéssel, Stefan Agner írta: Hi Gabor, [resend, forgot mailing list in to list] In the early reference driver of the NAND controller, the data from the DMA has been swapped. On later reference drivers, this swapping has been removed. To match with the reference driver, the current ar934x-nfc driver does not swaps the data by default. If U-Boot on the WNDR4300 swaps the data then that can cause ECC errors in all NAND pages. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. I enabled this swapping, but without luck. Still can't mount filesystems flashed using U-boot. I guess that Netgears driver somehow uses the EC header differently (is this done in software?)Currently, I need to boot initramfs to flash/create root filesystems. But this has alsoadvantages, since I can use all those UBI utilities... It is done in software in the ar934x-nfc driver. The NAND controller of the AR934x SoCs also supports hardware based ECC calculation but that is not yet implemented in the driver. The hardware based ECC might use a different OOB layout and that would cause similar problems if thas is enabled in the bootloader. I guess that it would be easy to figure out if the bootloader uses a different OOB layout or not. 1. Flash an image from U-Boot. 2. Boot an initramfs based image, and read the image back via the 'nanddump' utility including the OOB data. 3. Write the same image to the same partition from the initramfs based kernel. 4. Dump it again and check what is the difference in the OOB data between the two. UBI/squahsfs should be working, at least it has been tested by Free Electrons [2] on older kernels. In my opinion, it makes no sense to use JFFS2 on an UBI volume. That would complicate things with no good reason. For JFFS2, two immediate layers are needed in order to make it work on UBI volumes whereas UBIFS can work directly on that. Agree IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. I'm going to try squashfs on UBI. I see that Free Electrons refers with squashfs-ubiblk to that combination. As far as I can see, it should be easy as referring to the UBI volume as root device (e.g. /dev/ubiblk0_0). One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. Hm, but this would still change CRC, wouldn't it? IIRC, wear leveling is not used on static (read-only ) UBI volumes, but I'm unsure about that. The kernel command line is fixed in U-Boot, so we would have to generate an image with fixed (e.g. CONFIG_CMDLINE_OVERRIDE=y) cmdline. Any other idea? Is this the first Netgear target which encounters this problem? We are using the patch-cmdline tool to inject a board specific command line into the kernel for almost all boards [4]. Ok ic. As far as I see theres no root= configuration injected. Does the kernel has some hard coded defaults? The kernel automatically sets the rootfs partition to be the root filesystem if the 'CONFIG_MTD_ROOTFS_ROOT_DEV' option is set. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Hi all, I guess that Netgears driver somehow uses the EC header differently (is this done in software?) Currently, I need to boot initramfs to flash/create root filesystems. But this has also advantages, since I can use all those UBI utilities... It should be possible to find this out from Netgear's GPL sources then, right? No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. Hm, but this would still change CRC, wouldn't it? Not of the SquashFS UBI volume, I presume, because those sectors 'never' change. And I think that _if_ a sector goes bad on a read action, we have a genuine problem and failing CRC actually is a correct action to take. As I mentioned on the forums, I'm having some trouble locating a USB-serial adaptor, so my input remains untested for now, unfortunately. Barring that, can someone (Gabor, maybe?) comment on the usual way in which cooperation on a new platform by people without commit access usually is done? Create a private branch, grant commit access to all contributors, when done rebase all commits onto latest commit of trunk, email diff? Thanks! Joris ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Hi Gabor, [resend, forgot mailing list in to list] In the early reference driver of the NAND controller, the data from the DMA has been swapped. On later reference drivers, this swapping has been removed. To match with the reference driver, the current ar934x-nfc driver does not swaps the data by default. If U-Boot on the WNDR4300 swaps the data then that can cause ECC errors in all NAND pages. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. I enabled this swapping, but without luck. Still can't mount filesystems flashed using U-boot. I guess that Netgears driver somehow uses the EC header differently (is this done in software?) Currently, I need to boot initramfs to flash/create root filesystems. But this has also advantages, since I can use all those UBI utilities... UBI/squahsfs should be working, at least it has been tested by Free Electrons [2] on older kernels. In my opinion, it makes no sense to use JFFS2 on an UBI volume. That would complicate things with no good reason. For JFFS2, two immediate layers are needed in order to make it work on UBI volumes whereas UBIFS can work directly on that. Agree IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. I'm going to try squashfs on UBI. I see that Free Electrons refers with squashfs-ubiblk to that combination. As far as I can see, it should be easy as referring to the UBI volume as root device (e.g. /dev/ubiblk0_0). One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. Hm, but this would still change CRC, wouldn't it? The kernel command line is fixed in U-Boot, so we would have to generate an image with fixed (e.g. CONFIG_CMDLINE_OVERRIDE=y) cmdline. Any other idea? Is this the first Netgear target which encounters this problem? We are using the patch-cmdline tool to inject a board specific command line into the kernel for almost all boards [4]. Ok ic. As far as I see theres no root= configuration injected. Does the kernel has some hard coded defaults? -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Hello list, I posted an initial, quite horrible, patch to the forums to try and get the WNDR4300 working. I am not that experienced in either posting to lists or embedded development, so please do inform me of any mistakes I may have made. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. That is good to know and probably quite quick to test (which is easy for me to say as I have not found the courage yet to solder a serial connection). IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. It would indeed be a cleaner solution, however I gather from [2] that performance differences are minimal. Furthermore, direct support for UBI-SquashFS is not in mainline, according to [5], and the latest proposed patch I could find went AWOL after someone gave comments [6]. Looking at the current layout [7], I think an initial solution would be to use mtd8 'rootfs' as single UBI volume and layering SquashFS on top via gluebi and mtdblock_ro. Of course, if the amount of work is comparable for direct versus gluebi, the direct scenario makes more sense. For the overlay, we could use the existing mtd12 'reserved' (for what, I wonder) as JFFS2 since that already includes bad block management. Using mtd12 would have the added advantage of providing a _huge_ amount of storage, while keeping the original layout of the flash, so it should be easy to revert to stock that way. One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. So _if_ one UBI volume was used this would be true, but since your proposal includes two UBI volumes, it works around the CRC check, right? Joris 1. https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/files/arch/mips/ath79/mach-rb2011.c#L235 2. http://elinux.org/Flash_Filesystem_Benchmarks 3. http://lists.infradead.org/pipermail/linux-mtd/2013-February/045794.html 4. https://dev.openwrt.org/browser/trunk/target/linux/ar71xx/image/Makefile#L63 5. http://elinux.org/Flash_Filesystem_Benchmarks_Protocol#Tested_filesystems 6. https://lkml.org/lkml/2011/10/1/51 7. http://wiki.openwrt.org/toh/netgear/wndr4300#visual.representation ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
Hi Stefan, In between I found out that the driver works fine if I erase/write the NAND first using the driver itself. But when I try to flash something using the stock U-Boot bootloader, the driver still complains as outlined in my first message. Right now I have a running kernel and root filesystem generated using git master. I generated these files by altering the ar71xx generic subtarget (included UBIFS, NAND driver etc.) I then flashed the kernel using stock U-Boot. To flash the root fs I used the already working initramfs and generated the UBI volume by hand, then used ubiupdatevol to write the generated *.ubifs image. Due to manual flashing, the default boot commands don't work since magics and CRCs are wrong. Beside that, there is no overlay right now, I have a read/writeable root fs. My goal is to generate a easily flashable (TFTP recovery or whatever) image for this router. Since I'm new to OpenWRT development I might be wrong with all this, so please help me/correct me... When the image is written by U-Boot, the rootfs won't be readable by the ar934x kernel driver (my initial problem). Any idea how to work around this? In the early reference driver of the NAND controller, the data from the DMA has been swapped. On later reference drivers, this swapping has been removed. To match with the reference driver, the current ar934x-nfc driver does not swaps the data by default. If U-Boot on the WNDR4300 swaps the data then that can cause ECC errors in all NAND pages. If that is the problem, swapping must be enabled in the ar934x-nfc driver as well by an 'ath79_nfc_set_swap_dma(true)' call before ath79_register_nfc(). See the mach-rb2011.c file [1] for example. If this does not help, then I have no idea what causes the read failures. As far as I can see, there is only xburst which _use_ UBIFS right now. The ar71xx/nand target use YAFFS2 (at least this is what the kernel has included). The question is, should I include UBIFS to the NAND subtarget and transfer this device to this subtarget? Or should I create a new target (so there would be three generic = squashfs/jffs2, nand = YAFFS2, ubi = ubi/ubifs). The nand subtarget is mainly for Mikrotik devices. Those needs yaffs2 support in order to keep it compatible with RouterBOOT. The yaffs2 fs will not be used for other boards so a separate subtarget would be better. Which is the NAND fs combination for OpenWRT in future anyway? I see following combinations (rootfs/rootfs_data): - UBI/squashfs, UBI/JFFS2 (using gluebi, stacking of FS, are these tested and working combinations? Too complicated?) UBI/squahsfs should be working, at least it has been tested by Free Electrons [2] on older kernels. In my opinion, it makes no sense to use JFFS2 on an UBI volume. That would complicate things with no good reason. For JFFS2, two immediate layers are needed in order to make it work on UBI volumes whereas UBIFS can work directly on that. - UBI/UBIFS(ro), UBI/UBIFS (I read that UBIFS doesnt allow to be a overlayfs since it lacks whiteout feature.. Is this true?) It is true for ubifs in mainline linux kernels. Overlayfs relies on symlink xattr support which is not present in mailine yet. We have a experimental patch for that in OpenWrt (see 550-ubifs-symlink-xattr-support.patch in target/linux/generic/patches-*). A more complete patchset has been posted to the linux-mtd list a few months ago [3], but i don't know the actual status of those patches. Additionally, there is a minor problem using UBIFS for the read only part. The resulting ubifs image is much larger than a corresponding squashfs image even if xz compression is used in ubifs. It is not a big problem because NAND flashes are usually larger than the generally used 4/8/16MB NOR flashes but it simply wastes space. IMHO, the optimal solution would be the following: Add direct support to squashfs in order to be able to use that on top of plain UBI volumes. Create two UBI volumes and use squashfs on the first and UBIFS on the second volume. This would be much cleaner solution than the 'ubi-gluebi-mtdblock-squashfs' combination. One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) No AFAIK. The UBI layer only uses the erase sectors of a given UBI volume for wear leveling. The kernel command line is fixed in U-Boot, so we would have to generate an image with fixed (e.g. CONFIG_CMDLINE_OVERRIDE=y) cmdline. Any other idea? Is this the first Netgear target which encounters this problem? We are using the patch-cmdline tool to inject a board specific command line into the kernel for almost all boards [4]. Or maybe go straight forward and just wipe the whole device, flash a U-Boot without integrity checks, use the whole NAND... (would be a one way thing... is there a solution where user can do this without opening the device..) I don't want
Re: [OpenWrt-Devel] SoC NAND driver ar934x/OpenWRT support on WNDR4300
In between I found out that the driver works fine if I erase/write the NAND first using the driver itself. But when I try to flash something using the stock U-Boot bootloader, the driver still complains as outlined in my first message. Right now I have a running kernel and root filesystem generated using git master. I generated these files by altering the ar71xx generic subtarget (included UBIFS, NAND driver etc.) I then flashed the kernel using stock U-Boot. To flash the root fs I used the already working initramfs and generated the UBI volume by hand, then used ubiupdatevol to write the generated *.ubifs image. Due to manual flashing, the default boot commands don't work since magics and CRCs are wrong. Beside that, there is no overlay right now, I have a read/writeable root fs. My goal is to generate a easily flashable (TFTP recovery or whatever) image for this router. Since I'm new to OpenWRT development I might be wrong with all this, so please help me/correct me... When the image is written by U-Boot, the rootfs won't be readable by the ar934x kernel driver (my initial problem). Any idea how to work around this? As far as I can see, there is only xburst which _use_ UBIFS right now. The ar71xx/nand target use YAFFS2 (at least this is what the kernel has included). The question is, should I include UBIFS to the NAND subtarget and transfer this device to this subtarget? Or should I create a new target (so there would be three generic = squashfs/jffs2, nand = YAFFS2, ubi = ubi/ubifs). Which is the NAND fs combination for OpenWRT in future anyway? I see following combinations (rootfs/rootfs_data): - UBI/squashfs, UBI/JFFS2 (using gluebi, stacking of FS, are these tested and working combinations? Too complicated?) - UBI/UBIFS(ro), UBI/UBIFS (I read that UBIFS doesnt allow to be a overlayfs since it lacks whiteout feature.. Is this true?) One other thing which bothers me: U-Boot checks the rootfs CRC. If these FS are on the same UBI volume, doesn't get NAND pages of the whole MTD changed (wear leveling?) The kernel command line is fixed in U-Boot, so we would have to generate an image with fixed (e.g. CONFIG_CMDLINE_OVERRIDE=y) cmdline. Any other idea? Is this the first Netgear target which encounters this problem? Or maybe go straight forward and just wipe the whole device, flash a U-Boot without integrity checks, use the whole NAND... (would be a one way thing... is there a solution where user can do this without opening the device..) Any thoughts? Thanks -- Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
