On Mon, May 28, 2012 at 09:27:32PM +0300, Daniel Golle wrote: > 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.
Ok. Do you have any patches for this? > 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? I dont know, I use only one UBI volume and it works fine. > 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. How can U-Boot environment be redundant? Is that uboot patch? > 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. I would go with second one (ubifs-rom-volume-including-uImage+ubifs-overlay-volume). > 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 agree. > >> 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 That looks ok to me... > 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 :) You can find me also there (luka12345). Luka _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
