Background: Trying to add support for a MT7988D device (Zyxel EE4600-00, but this could be an operator specific designation) with 8GB emmc. The OEM firmware uses a dual firmware scheme with a chainloaded vendor bootloader as the final step (zloader, as a FIT image this time)
I would prefer to keep the vendor bootloader. At least as an option. This makes OpenWrt installation simpler and less risky, and it allows keeping vendor firmware in the other slot. It's even possible to switch back and forth with full functionality in place, except for vendor firmware upgrade (would overwrite OpenWrt). All this is feasible and I have it working.
The problem is partitions. The vendor table is crazy:
But I consider changing it without changing the bootloader out of the question. Too risky.
The existence of a tiny rootfs_data partition will result in a bad user experience by default. We need something larger. But how?
I've considered pointing root to one of the larger unused partitions, like misc1 or reserved1024M. But this locks us there. And becomes a problem if the vendor changes their table. Maybe unlikely, but I have a bad feeling about this. Labels, uuids and numbers could all just disappear with a vendor firmware update.
So I started thinking about extroot as the configurable alternative. Would it be acceptable to have a tiny rootfs by default and recommending extroot? Or maybe even provide a default extroot configuration?
We had similar issues with the Unifi 6 Plus. It ended up with most of the emmc unused by default. But I think that has worked out fine. Not as extreme though.
That sounds the most promising option to me.
But I foresee possible difficulties in getting it flashed to proper places from OEM firmware.
The easiness might depend on how OEM uses partitions. I see the kernel 64 MB, rootfs 128 MB, firmware 200 MB, rootfs_data 16 MB. How does OEM use them? If you could use kernel and rootfs as they are, and it is only about rootfs_data (the overlay), it might be relatively easy.
I don't understand why you think that there should be an option to still do vendor firmware updates after you have already installed OpenWrt. That kind of functionality is rarity and would be luxury. (In many modern routers you may have to change boot parameters for OpenWrt, so vendor firmware is out in any case.)
The plan is a two step install. First install an initramfs and then use that to sysupgrade. Ram booting the initramfs is of course also an option, but considered for advanced users only since console is necessary then. Installing an OpenWrt initramfs from OEM works. It ends up in one of the kernel partitions. We can't control which one directly. But that doesn't matter.
OEM boots from one of the kernel partitions. We can't change that. But we can force it to one of them after installation, using an ubootenv variable. So the dual firmware scheme is not a problem wrt final state.
I did experiment with a direct install from OEM. It's not impossible, but the dual firmware complicates it. Decided it wasn't worth the effort. Much easier to document the two step procedure for everyone. And then we have free choice of rootfs partition.
Yes. We can do that. What is the proper way to point OpenWrt to another rootfs_data partition?
I didn't mean that it should be supported. Just that it could happen if the user decides to boot OEM. This is an ISP device and it will be remotely managed by default. So there's always the possibility of unexpected upgrades if the user isn't careful (when booting OEM).
But this isn't a real problem. Just a caveat to document.
The end of the last partition is at 7864319, so I believe most of it is assigned to partitions. But most of them are not used for anything AFAICS.
OEM uses partitions up to and including "misc". I haven't seen it use anything after that. But the bootloader does refer to "firmware" and "firmware2" so they could be in use for something I haven't figured out. Likewise with "rootfs_data2". It would make sense if that was related to "rootfs2", and there could be an option to make it so
EDIT. Doh! That's only 4GB. Yes, so you're right. Or there is only 4GB. I have to check that
I have never done that myself, but there are several routers that define rootfs_data in their dts(i) files. I think that if it is defined and is found, it is then used, and no "split rootfs to /rom and rootfs_data" action will happen.
You might look these through and check if there is anything special in their sysupgrade things:
Well, that's the problem. I don't think it's possible to modify any partition attributes like labels or uuids without changing the table on the emmc. Which would work, but I'm trying to avoid
Sysupgrade is easy. It supports direct specification of the data partition on emmc. But mount_root seems to hardcode rootfs_data unless extroot is in use. Which is why I asked about that
Yes, that works and might be the best option. Worrying about the high number if using the last and most attractive partition though. It could go away. But I guess I am overthinking this? If it happens then it won't break existing installations. And we can adapt.
I was wrong. There is a blkdevparts cmdline parameter. It has been used for a few OpenWrt devices like for example
This allows redefining the table for OpenWrt without modifying the ondisk version. But it's rather ugly, having to map every partition we care about on the command line. And the feature is not yet in the filogic kernels. I don't think I want to be the first one to start this mess without very good reasons
I'll just go for the simple root=/dev/mmcblk0p38
Thanks to both of you for sharing thoughts and ideas!
And yes, @frollic was right - half of the emmc is not allocated to any partition at all. It is 8GB as I thought it was: Disk /dev/mmcblk0: 7.28 GiB, 7818182656 bytes, 15269888 sectors
Thanks for spotting that. The remaining space is empty. So there is definitely room for improvements for advanced users willing to play with this.
