On 28/05/12 22:43, Luka Perkov wrote: > 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? Still working on it as my current implementation breaks the regular squashfs+jffs2 approach... It's not that complex and I will send the first patches/rfc either today or tomorrow.
>> 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. Yes, this works and no changes to preinit/firstboot are needed, as the rootfs is R/W from the beginning on and no overlay needs to be mounted and such. However, I want to have a restore-factory-defaults feature so people will have an easy way to un-brick wrongly configured or "suicidal" devices (i.e. reset button). For that, mimicking the JFFS2-overlay-approach makes a lot of sense (even if both volumes are UBIFS, one being static and another initially empty dynamic volume). Besides that, I currently do not implement the "keep settings" feature of sysupgrade, as that would obviously need some more tinkering (and is not mission-critical for what I want to do). Probably the most easy way to do that is to ubiattach, mount the newly created empty overlay volume and put the files back there after sysupgrade did ubidetach and ubiformat (ubiformat happends to be more useful than ubiupdatevol, as I'd like to have a single image file containing everything). >> 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? The U-Boot binary itself also contains a copy of the factory-default environment and obviously, U-Boot itself and the U-Boot environment already live in separate erase blocks. See: http://lists.denx.de/pipermail/u-boot/2006-April/014610.html OT: However, the uboot-env tools allows adding several *synced* environments, though it would be way more useful to have them separate (i.e. one for the loader which comes with the board which the user might use to load another version of U-Boot with features the user likes to have without risking to brick the board; in that case, the two loaders obviously need to have different separate environments, as otherwise it would try to infinitely load itself) Probably this is due to a misunderstanding of the redundant environment feature. If it comes to U-Boot itself being redundant, I'm not sure about how the in-chip loader of kirkwood reacts to the CRC of the eraseblock holding U-Boot itself being wrong or the eraseblock being marked as broken (is that available open-source somewhere in Marvell's elaborate specs about the kirkwood btw?). Skipping and searching for something which looks like U-Boot in 0x40000 steps would be sane approach, but I never had a board with the first NAND block broken, so I can't tell. >> 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). That's what I'm currently implementing. I'll add a configuration option which allows inclusion of the kernel uImage to the rootfs. In way, similar things need to happen so sysupgrade (and factory-restore) on x86 or other platforms not featuring the typical NOR flash MTD setup found in small embedded devices, so that it would be more satisfactory for the users. >> 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... As it is a very crucial thing we should probably have a couple of people testing and reviewing it independently... Particularly, the OpenWrt-added boards (iConnect and Dockstar) should be tested, though they are not very different from the sheevaplug support included in U-Boot. _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
