Hi,
Started to work again on this. I essentially manually rebased the changes on trunk. My old commits moved the nand subtarget first, but since the subtarget nand is nowadays called mikrotik, this is not necessary anymore. But this doesn't allowed a straight forward rebasing..
@Zsub, I saw all your changes but when I was at the point looking at them (and pulling them) I already rebased or developed in another direction. But your work and findings are definitely helpful!
pivot_root is used by OpenWRT by default. But currently, ubox (the utility which does the magic) and some scripts are coded to create a JFFS2 partition on the device with the name rootfs_data, and uses that as overlay on the ROM (the device which is mounted initially, usually rootfs).
Things are working again on trunk, and I make use of the profile specific UBI settings introduced by Luka.
In my new branch called "wndr4300-nand-squashfs" the root MTD partition is now called ubiroot in order to solve autodetection issues (the kernel tried to split the MTD partition called rootfs). The UBI image consists now of two UBI volumes, the first wih a squashfs on it (called rootfs, which can be mounted using GLUEBI, it ends up as /dev/mtdblock12) and the data volume (rootfs_data, UBI, which ends up as /dev/mtdblock13). The layout looks like this now:
dev: size erasesize name
mtd0: 00040000 00020000 "u-boot"
mtd1: 00040000 00020000 "u-boot-env"
mtd2: 00040000 00020000 "caldata"
mtd3: 00080000 00020000 "pot"
mtd4: 00200000 00020000 "language"
mtd5: 00080000 00020000 "config"
mtd6: 00300000 00020000 "traffic_meter"
mtd7: 00120000 00020000 "kernel"
mtd8: 017e0000 00020000 "ubiroot"
mtd9: 01900000 00020000 "firmware"
mtd10: 00040000 00020000 "caldata_backup"
mtd11: 06000000 00020000 "reserved"
mtd12: 0024d000 0001f000 "rootfs"
mtd13: 011ec000 0001f000 "rootfs_data"
The kernel should mount the MTD called rootfs directly, but this doesn't work, so I pass root=/dev/mtdblock12 to the kernel.
When starting this image, userspace tools try to format the rootfs_data using jffs2.
At first, I haven't compiled this filesystem, so this didn't succeed:
Thu Jan 1 00:00:18 1970 user.err syslog: No jffs2 marker was found
Thu Jan 1 00:00:18 1970 kern.emerg switch2jffs: No jffs2 marker was found
Thu Jan 1 00:00:18 1970 user.err syslog: no jffs2 marker found
Thu Jan 1 00:00:18 1970 kern.emerg switch2jffs: no jffs2 marker found
Thu Jan 1 00:00:18 1970 user.err syslog: failed - mount -t jffs2 /dev/mtdblock13 /rom/overlay: No such device
Thu Jan 1 00:00:18 1970 kern.emerg switch2jffs: failed - mount -t jffs2 /dev/mtdblock13 /rom/overlay: No such device
Thu Jan 1 00:00:18 1970 kern.emerg setting up led WAN (green)
Thu Jan 1 00:00:18 1970 kern.emerg setting up led USB
Thu Jan 1 00:00:18 1970 kern.emerg - init complete -
The code then falls back to a RAM based rootfs_data, which gets mounted and overlayed. So overlaying works.
When adding JFFS2 to the kernel configuration, everything works fine, the partition gets formatted and I have persistent storage!
Well, this should enable all our wishes feature wise, but technically its not a clean solution since we run JFFS2 on UBI, and using the GLUEBI layer which makes the whole a bit unclean.
Also from the image generation standpoint things are still dirty: Its now required to enable Squashfs and UBIFS as root filesytem since the UBI target is only called when UBIFS is enabled... This certainly needs cleanup.
In order to have UBIFS as rootfs_data, we would need to extend the ubox utilites (which provide switch2jffs) and some scripts and bring them to format the partition using UBIFS.
Code: https://github.com/falstaff84/openwrt/t … d-squashfs
@neophyte: I can send you an image if you're ready to take the risk. Flashing only works using factory reset (at least, I tried only that way so far). This worked already several times on my device, but I can not guarantee for anything... (in other words, it might break your device!)