OK So this hasnt been heavily discussed yet – the below is just my personal opinion.
I came into the project a bit later, but decided to support this effort because I personally think it’s best to center around a build system designed to deal with the peculiarities of weird embedded hardware, vendor patched kernels, and all of the nonsense necessary to support that stuff. Yocto/openembedded is an extremely popular system in and out of industry designed to do that, and it makes sense to use it. It starts with nothing and produces all of the stuff (not just the kernel) that you actually need to bootstrap the system, including the weird partition requirements, the bootloader, the kernel, the kernel modules, udev configuration, and the devicetree, all sprinkled and baked up with the rockchip rkbin secret sauce. Eventually we’ll probably have it build the stm32 firmware as well.
I like the use of an immutable base system and A/B firmware because it makes it very easy to update and much harder to break. This is a UX thing, and I think it’s important to minimize the amount of time people have to spend opening up their calculators and being frustrated if something breaks. I think a very highly curated distribution is proper here because of the peculiarity of the hardware. IMO if you ultimately just dump users to a vanilla ubuntu shell, that’s a bit rougher than most people want. And you don’t really have the resources to do the full ubuntu X11 desktop either. So you just spend all of your time shoehorning ubuntu onto something it wasnt really designed for.
But setting Ubuntu aside, I agree with you that users must be able to easily add their own software. The system currently supports an overlayfs partition, so data and configuration can persist across updates of the underlying system. This currently requires that packages designed for user installation manage their data within these overlays.
Yocto (even with RAUC’s A/B system) doesnt have to be run as immutable root. It’s perfectly fine to have a read/write rootfs and do local package installation. We have explored some possibilities for perhaps automating the reinstallation of local packages after system update so whether we can support this in some way remains to be seen, but it is a goal. Probably this will serve well as a repository of packages or package recipes designed and/or configured specifically for the picocalc hardware.
So bringing Ubuntu (and lots of other software) back into the discussion: my first question is why not containers/podman? We can support persistence in the overlayfs so you could have a persistent ubuntu environment that is about as resource efficient (except for disk space) as it can get. You can pass through all the hardware you want with –privileged or –device. I mean, I’m running builds out of a privileged ubuntu container running in colima on my mac so I already know the UX is pretty good. Honestly I’m going to try this soon. I think we can deliver a better Ubuntu user experience on this limited hardware via Calculinux + Ubuntu container than trying to do ubuntu root anyway. Or am I missing the point?
If you do want to run an ubuntu root, the Calculinux build already builds everything you need; start with the wks image for the sd card; delete partitions 3-6, add ubuntu arm rootfs as partion 3, leave room for 1-2GB swap as partition 4, copy the zboot image into /boot. The only other things you’ll have to do is modify /boot/boot.scr to remove the RAUC stuff, do a static boot of partition 3, and then probably the hardest part of the whole thing – handle the kernel modules and initrd.
