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
