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
