I’ve been using Linux for the last 16 years as my primary desktop OS, however, I have no experience working with ARM SBC devices. I’m planning to buy a Rock Pi 4, and I’d like to run openSUSE on it, who has an Aarch64 build- https://en.opensuse.org/Portal:ARM Is there any reason I wouldn’t be able to do this? They claim it’s also working with the Mali 860 as well, and I have no problems with tinkering a bit or compiling apps from source to get it running, just as long as it doesn’t require a compiling the kernel with custom patches. I’d appreciate any info that can be provided.
It will not work. Perhaps in 6-12 months when mainline support emerges, matures, … Now, you have to work out with 4.4 based kernel builds what you found on radxa download, Armbian, …) or experimental mainline 5.3.y Armbian (Ubuntu/Debian), Ayufan Ubuntu, Debian, …
Do you know why it won’t work?
Mainstream distributions rely on upstream kernel where support for this hardware is basic, immature and not (very well) tested. I am not familiar particularly with Suse, but Ubuntu, for example, only supports a few.
Currently they should maintain several different kernel / u-boot branches like Armbian do. But this complicates things a lot …
I don’t think very highly of Canonical or Ubuntu, to put it as nicely as I possibly can. However, it looks like the openSUSE developers are willing to work on getting hardware working that does not yet run. I don’t yet own the hardware, but I will probably end up getting it, and it will probably be soon, so I will likely see if I can get it running. I still have a lot to learn about the platform yet though. They have this posted on their site though, if anyone more experienced with the hardware wants to work with them to get it running-
Feel free to join the openSUSE Arm mailing list as well as the #openSUSE-arm IRC channel for questions or help. We are also actively looking for people to enable hardware we don’t support yet. If you have an armv8 or armv7 based device that doesn’t work yet and are willing to spend some time to get it working with openSUSE, please contact us on the mailing list.
And here is the list of hardware they already have working, which I just now found, while trying to find more info- https://en.opensuse.org/openSUSE:OpenSUSE_on_your_ARM_board There are a lot of boards there already, and I noticed they have the Rock64, but also the Rock960 is there as well, which seems to be nearly identical hardware to the Rock Pi 4, so it may already work if it’s just driver issues, that are the main barrier.
As soon as I get my hands on the hardware, I will definitely do some experimenting. I just wasn’t sure I wanted to buy it over a RasPi 4, until I knew for sure that I could run all the software I want to run on it. But the hardware is significantly better than the RasPi 4, and I’m sure I will be able to do enough with it, to be quite happy with it, so I’m pretty sure I’m just going to buy it. The Rock Pi really is a great board and a good value.
Ubuntu is crap. Agree, but this doesn’t change facts regarding the essentials - low level support. Once this is done (by anyone), you can deploy any distribution - userland is the cheap/irrelevant component in this game. Mainlining takes years and RK3399 is getting into the final stage. My estimation is based on experiences and is just an estimation …
I have nothing against OpenSuse, but they are general purpose mainstream distribution. Like Ubuntu (sorry for comparing with it :), Debian, Arch, Manjaro … All of those supports ARM/ARM64 and have theoretical support for many different boards. But do their images really work? Anyone tested? Do you need to DIY a lot of stuff or is it plug and play? Do you have to add a lot of patches or just a few to their general purpose arm64 kernel? Many key things are still under development …
Armbian “supported”/WIP list is almost the only real indication if ARM SBC board is ready to use:
The rest is mainly big gamble or needs developers attention/help like:
… while they don’t support not even close or on the level what Armbian now. When things are developed in open space it means if a person that works for Opensuse creates a support for XYZ you can have it on Debian. And vice versa.
I do agree with you once again. I have 100+ boards and only one Rpi (which I anyway don’t use). I do encorage you to play with it, perhaps even port a Linux of your choice to it.
… which not necesarelly means with a mainline kernel. But for Armbian its not a problem to use special kernel since it was designed for this purpose. This means you can use a hardware way before, before become obsolete, and simply upgrade a kernel to mainline, when its good enough.
Some, usually advanced and most interesting features, needs more years to get to the mainline. Some never came. With Armbian you can use stock kernel and wait for good times to come.
I understand, what you mean, the hardware obviously can’t run, without full driver support in the kernel, either directly or through custom patches or modules. Though, It doesn’t take years to get patches mainlined into the kernel, at least not anymore. It may have at some time in the past, but now days, kernel development moves at a fairly rapid pace. Patches are usually accepted when they are ready, and by ready, I mean when they are fully up to the high quality standards set by Linus lol.
But as I also mentioned previously, openSUSE has already pre-built packages for other RK3399 SoC’s.
The Rock960 is nearly identical hardware, except overpriced, and the Firefly-RK3399 is very close as well. So, I’m sure it will probably take a bit of work to get it running, but I really don’t think it will end up being too difficult. I could be completely wrong about it, I don’t know for sure, since I am not too familiar with the platform specifics, and I probably won’t know until I end up getting the hardware and try to get it running. But either way, as soon as I can get my hands on the board, I will find out for sure, one way or the other.
I have not taken a look at Armbian yet, since I haven’t had an ARM SBC yet. But I’ve been planning to take a look at it though, precisely because I haven’t used it yet. I like to know what’s available, especially with specialized distros. Though, their website doesn’t even seem too certain about what distro it’s based off of lol, and a lot of information that is there is somewhat ambiguous. But one of the things that really appealed to me about a SBC, is the ease of being able to write to a SD card and pop in a new OS, just like that. So, it makes it very easy to try everything available. Anyway, thanks for all the info, I do appreciate it.
So far it does.
Only if SoC is popular, patches are coming in. RK3399 is popular and first board appeared on the market in 1/2018. Now do the math. RK3399 is not fully mainlined but close. Of course extended versions or upgrades of this chip will not take two years to get mainline support.
Boot, check and see the level of support. Those boards tries to be for different customers and supported by corporations while support can only be the same due to Linux licence. I would suspect Linaro is pushing their 96boards.org stuff to anyone interested. Opensuse can only have what Linaro gave them. Check 96boards.org to understand the level of support … if you don’t have hw to see on your own.
Isn’t it obvious? Debian/Armbian Userspace: application versions, relations and cosmetics is irrelevant from our perspective. Armbian is a Linux build system in its core (similar to Yocto/buildroot but not that powerful or complex) and we could easily support Opensuse if there would have enough of their experts around. Or that would be my PC distro of choice.
I think I understand what you mean a bit better now. I briefly skimmed through Radxa’s git repository a bit, and it looks like they are using a custom kernel branch, containing thousands of custom changes. I know many months back, I had read something on kernel development that mentioned that some ARM manufactures were having to maintain a separate kernel branch, based off of the 4.4 kernel, because of custom changes that weren’t compatible with newer kernels for some reason. But at the time I read it, I figured it was referring to smartphone manufactures, which I don’t care too much about, and so I didn’t pay much attention to it. So I don’t remember why it said they were having to use the older kernel or why they had trouble getting the changes into the main kernel. I wish I had paid closer attention to it now, or could at least remember where I read it. But now that I vaguely remember it, and after having poked around the git repo a bit, what you’ve been saying makes much more sense to me now.
Once I get the hardware, I will still see if I can get openSUSE running, though I realize there is a good chance I won’t be successful with it. But it should be an interesting learning experience none the less lol, and it’s probably a good way to quickly learn more about the ARM platform as well. So, either way, even if the effort isn’t successful, it should still be a worthwhile endeavor.
What I was jokingly referring to, about Armbian, was in their documentation, where it says in several places something similar to this for example, “Lightweight Debian or Ubuntu based distribution specialized for ARM developing boards.” on this page, for example- https://docs.armbian.com/
I realize it’s really mostly only semantics anyhow, since Ubuntu is Debian based. I also did not realize that Armbian was a build system. As I mentioned previously, I’m really not familiar with it, and have not used it yet. Thank you once again though for all of the helpful information, I do really appreciate all of it.
You can’t develop drivers / initial board support on a moving kernel. You always have to pick some, usually latest LTS, and create support for your hardware. Then port upstream … if you can afford that. Until you don’t have a working functionality you can’t port it. And there are exceptions, fatal failures or too big changes which means certain features has to be written from scratch. Its a complex and expensive project.
Bulk of this work is still done by Rockchip and SoC pioneers.