Seems to me that Ubuntu 22.04 is probably too new and my attempts at build 4.4 stable could be related to tools versions. What are people using on their PC to do Rock Pi S builds?
What Linux to use as build system for Rock Pi S?
- x64 / aarch64 machine with at least 2GB of memory and ~35GB of disk space for a VM, container or native OS,
- Ubuntu Jammy 22.04 x64 or aarch64 for native building or any Docker capable x64 / aarch64 Linux for containerised,
I was trying to build the radxa u-boot and kernel, but Iāll try the armbian build instead. Iām using Ubuntu 22.04 on my build system. So, I should be using exactly what you are. Thanks!
I can build Armbian, but even the prebuilt images donāt boot on the Rock Pi S V13. The supported Debian image works, but I canāt get the u-boot and kernel to build on my development system which is a newly installed Ubuntu 22.04. Iāve got to say that this is annoying and Iāve been building Linux going all the way back to the 0.99 days.
Welcome to the club of old farts 
Armbian project started around 10 years ago because we face similar troubles you face today. Armbian build system is solving many problems you need to solve, before lifting up from some generic Linux (ubuntu). Build system is also dragging all necessary tool-chains (one is not enough) with it https://github.com/armbian/build/blob/master/lib/general.sh#L1544-L1556
Why there are so different compilers? Because (mainly) u-boot code can easily be some proprietary u-boot fork from 5-10 years ago, dragging from some older chip (as cheap as possible) ā¦ and might need some special compilers in order to build things together. One could clean the code to be built with recent compilers, but its a lot of work, it is expensive and nobody is interested to cover even for a lot more critical things & bug fixes.
Embedded Linux is wild west, custom hw, custom software. There are thousands of private kernels and u-boots and other boot loaders ā¦ Not just one, like you might be used in the simple x86 world. Things has been greatly improved in past decade, but certain things are changing slowly or not at all.
This is expect as HW is not officially supported. No Armbian folks is throwing weeks of work at it ATM as there are so many work and so little resources. Usually things breaks apart if there is nobody adjusting the always changing code (and changing HW revisions) and fix generic bugs that comes around.
But luckily there is someone having interest to get it working again:
Yea, I understand the difficulty of embedded. Iāve had a career in it. My first embedded Linux was on Coldfire (m68k), then Blackfin, Ubicom, and ARM. It just was irritating me that there is an official image, but I couldnāt even rebuild it. My day job involves chips only documented for the very large customers. I donāt get what secrets they are trying to hide given that they are all using the same IP to build their SoCs.
I did however succeed in building the vendorās kernel and could install it over the debian prebuilt image. Given that the kernel is what I want to mess with, I guess Iām fine now. I havenāt looked to see what is wrong with the Armbian image, but at the moment, I donāt need it.
1 Like
I suspect I know what is the problem with Armbian build. The build is creating an image that doesnāt have /boot on a FAT partition. I assume that there is a configuration option for this. So, Iāll go looking for it when I have time.
Nope, that is not the problem. FAT is not needed here. That is just a method to allow people to edit boot config files on Windows PC. I think we donāt need that.
I will also check when possible, currently its not.
I changed the Armbian board config for the Rock Pi S to create a FAT boot partition. Now my Armbian image boots.