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 [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
