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 to force the users to replace the booltloader on their boards. It is quite risky, expecially on NAND based devices. -Gabor 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 _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
