On 10/07/2014 08:27, Ben Mulvihill wrote:
> On Wed, 2014-07-09 at 16:27 +0200, Daniel Golle wrote:
>> On Wed, Jul 09, 2014 at 04:10:52PM +0200, Ben Mulvihill wrote:
>>>> JFFS2 works on bare MTD devices (originally NOR only, hackish
>>>> NAND support exists in the wild though YAFFS2 is more
>>>> commonly used). UBIFS is the only read-write filesystem which
>>>> works on top of UBI, thus the only possible choice for
>>>> overlay support.
>>>
>>> Not the only possibility surely? Currently we generate two
>>> images for the BTHOMEHUBV2B. Both use ubi. One has pure ubifs
>>> on top. The other has a squashfs/jffs2 overlay making use of
>>> gluebi. Everything works apart from sysupgrade but the only
>>> reason for doing things that way was that it was a natural
>>> progression from the pre-ubi arrangement and it worked out of
>>> the box. A squashfs/ubifs overlay is certainly cleaner. I'll
>>> see what I need to do to get it working.
>>
>> Ah, ok, now I understand the question :) And yes, you should use
>> squashfs/ubifs for overlay and disable gluebi alltogether. gluebi
>> is deprectated and was meant only for transition. ubiblock offers
>> a much cleaner way for read-only filesystems and UBIFS makes much
>> more sense than jffs2-on-gluebi.
>
> The penny has finally dropped! When I first made images using the
> new ubi support a few weeks ago the squashfs/jffs2 gluebi overlay
> worked out of the box, and the squashfs/ubifs overlay did not. I
> assumed I would have to generate the squashfs images for the latter
> case in some special way, preformatting an empty ubifs partition
> perhaps, or adding some magic to tell the kernel to mount
> rootfs_data as ubifs. I have just realised that the images work
> fine as they are, as long as the gluebi/mtd code doesn't get there
> first and attempt a jffs2 mount. So all that needs to be done to
> move over to a squashfs/ubifs overlay is to disable gluebi in the
> kernel configuration. I should like to ask John whether he would be
> happy for me to submit a patch to do that, on xway at least, not on
> xrx200 to avoid affecting the other lantiq nand boards?
sorry i should have mentioned this.
"gluebi is dead, long life ubiblock !!!"
we backported ubiblock from 3.15, it allows raw r/o access to the
squash. ubifs runs without intermediate gluebi/mtd layer, thus making
the whole setup much simpler. from what i understand, ubiblock will
obsolete gluebi in upstream so we decided to switch early.
this should be done for xway and xrx200.
John
>
> Or would it be better to find some way of enabling the
> volume_identify code in procd to distinguish a jffs2 rootfs_data
> from a ubifs rootfs_data. just in case in the future someone needs
> gluebi in the kernel for some other reason?
>
> Thank you
>
> Ben
>
>
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
