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
