On 21/04/2014 07:06, Ben Mulvihill wrote: > Hi John, > > May I take up your offer of a hand with overlayfs on top of ubi? I > have in fact managed to get a working overlay + ubi image, and also > a ubifs image. But I still have a few questions: > > - Am I right in thinking that there is no way to concatenate the > kernel and ubi image and have them split automatically like with > the squashfs image without ubi?
i added a ubi-flash tool to trunk that can be used to flash ubi volumes (and implicitly resize them) i plan to add a wrapper script this week. this script will be fed a tar file with the kernel and rootfs image. this allows us to "split" the files when flashing. i am using fixed size kernel part sizes for nand, there is enough space anyhow. > - Is there any point bothering with a jffs2 image as well, either > on top of ubi or not? i think the best option is flat ubifs or squashfs with jffs2/ubifs as overlay. > - the two images require different kernel parameters in the > 'chosen' line of the device tree: ubi.mtd=rootfs_ubi,256 > root=/dev/mtdblock8 // for overlayfs ubi.mtd=rootfs_ubi,256 > root=ubi0:rootfs // for ubifs Is there any way of combining them > so that a single device tree can be used with both images? Passing > the parameters from uboot ought to be one way of dealing with the > problem but I believe that with recent kernels parameters passed in > that way just get clobbered. i have a patch in my queue that will make the kernel auto-attach the rootfs_ubi mtd making the volumes inside it mountable. i will do my best to finsih the patch before the week is over. this will spare us the cmdline clobbering and not depend on any uboot environemnt variables. > - What is the best way to get the get the image onto the target? > nand write from uboot works fine, but you lose the wear levelling > information each time. I have also use tried booting a ramdisk > image first, copying root-overlay.ubi to /tmp, and flashing it with > ubiformat -f. That works too, but is there another option? on first flash you need to run ubi-format once. my plan is to push a special initramfs that has the ubi tools inside and carries the target rootfs as a payload. you flash/boot that image and it will do the rest of the firstboot/ubi-format for you. this will be part of the wrapper script mentioned above > Also, I am a little confused about the status of this patch: > http://patchwork.openwrt.org/patch/5110/ You told me it was a > "really bad idea" so I was expecting it to be rejected! But it is > appears in patchwork as accepted. Is that a mistake? the "split ubi volume" patch was a bad idea not this one :) sorry if i was not clear on that one hope that clears up some of the questions. John _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
