On Mon, 2014-04-21 at 09:29 +0200, John Crispin wrote: > > 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 > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Thanks for the quick reply. You seem to have a solution for everything in the pipeline already! I'll investigate ubi-format, and submit a patch to the BTHH2 profile to support just the overlayfs for the moment, along the lines of the current FRITZ3370 profile. Then I'll look again once your planned changes are in trunk to see what else needs to be done. I'm still slightly confused about the status of the previous patch, but never mind. I'll just wait and see what the sources look like in a few weeks. In any case, if everything on top of ubi is the best approach, then I won't be making use of that patch at all. I imagine the jffs2_nand stuff I added to the lantiq/image/Makefile earlier can probably be removed as well. Ben _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
