On my platform I have NOR flash that is smaller than my rootfs size so would like to use a compressed rootfs that decompresses and runs out of RAM on boot.
As far as I can tell, this doesn’t seem to be something that’s supported by Mender out of the box (please correct me if I’m wrong!) so I’ve been looking into how I can achieve this. I wanted to ask if I’m on the right track or if I’m missing anything with my current plan:
- I’m thinking of using squashfs to compress the rootfs, but am not strictly tied to it and could be convinced to use something different if it’s better supported with Mender or if squashfs is a bad idea.
- It looks like Mender only supports ubifs for flash devices, so I was thinking of having a standard setup (like what’s in
meta-mender-qemu) that’s something like:
- mtd0: uboot
- mtd1: ubi layer with ubifs volumes
ubifs doesn’t look like it’s strictly necessary for what I want to do (I could just use mtd raw flash devices) but does give the advantage of wear leveling and allows file based access, which is useful for point 2. below.
- In each of the
rootfsubifs volumes, I would then have:
- Kernel image
- Device tree binary
- Squashfs rootfs file
- It looks as though the Mender uboot code assumes that the ubifs volume it boots from contains the rootfs directly:
So I would need to update the boot arguments to tell the kernel to boot with the squashfs rootfs on the current partition.
Will I need to do any work to allow
mender-artifactto wrap the above three items into an artifact that clients can install? I suppose all it really need to do is consider the kernel, squashfs file and dtb as a ubifs volume, so should just work?
Are there any hints about how I can go about achieving this in Yocto? Should I be making a new
image.bbclassand extending the
mtdimgclass similar to what