On 28/05/12 20:38, Luka Perkov wrote: > I got feedback from Kaloz regarding ubifs - we should boot from > squashfs, and create ubifs after that. I'm using a single UBI mtd partition and having two volumes: One "static" (r/o in UBI terminology) for rom (i.e. what used to be the content of squashfs, but including the kernel-uImage) and one "dynamic" (overlay, what used to be JFFS2) for the user to change. Apparently UBI is by far not as efficient as squashfs... However, it got the advantage that U-Boot can read from it and we won't need an extra volume (or even worse: mtd partition) for the kernel-uImage, but it can be just a regular file, which is most transparent for the user. Besides space-efficiency (which is not so much an issue on most platforms using NAND anyway), what speaks against a static UBIFS for the factory FS?
Alternatively, the uImage could be a seperate UBI volume and we could use squashfs using gluebi (or make squashfs work on UBI volumes instead of MTD partitions). In the end of the day, what matters most is just having everything inside UBI volumes and having U-Boot as well as U-Boot environment redundant. In that way, no single NAND bad-block can ever brick the device (but you can still loose data, obviously or have your factory/rootfs destroyed). How and what we use *inside* UBI (uImage-volume+squashfs-volume+ubifs-overlay-volume vs. ubifs-rom-volume-including-uImage+ubifs-overlay-volume) is a matter of taste. Both ways have advantages and disadvantages: Increased efficiency comes together with increased complexity -- personally I'd be more happy to waste a couple of megs of nand (usually we got plenty) for having a simple solution using just one type of filesystem and storage subsystem. >> I recently also updated Das U-Boot to the most recent stable version which >> now >> got very well working support for UBIFS, in that way, the bootloader can >> (similarly to GRUB on x86) read the kernel-uImage from the filesystem which >> makes things much more transparent for the user. > This is true. I'm using this setup on my kirkwood unit. I use upstream > uboot. Having it built automatically using the OpenWrt toolchain would be nice. See https://lists.openwrt.org/pipermail/openwrt-devel/2012-May/015291.html https://lists.openwrt.org/pipermail/openwrt-devel/2012-May/015292.html https://lists.openwrt.org/pipermail/openwrt-devel/2012-May/015293.html Is there any reason why this cannot be included/updated? >> As I got no reaction on that at all, I seems like the kirkwood target is >> abandoned, which is a petty for that very developer-friendly platform which >> is >> the first embedded platform for many new-commers in the field. >> What's the situation? > I'm planning to resend the patches. Also, I would like to rework scripts > so we have something like: target/linux/lantiq/base-files/lib/ Great to see things are moving forward. I got the resources to be working on that matter most of the time in the next two days. I'll be happy to cross-review and discuss things with you. (I'll be on #openwrt-devel most of the day tomorrow and Tuesday as well, I'm in GMT+2, but I don't get up too early :) Cheers Daniel _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
