Why can't ARM SBC run official and native ARM linux distro like openSUSE out of the box

[imjtrial]

Dear all,

 

Official ARM distro are there and ARM devices are everywhere.

 

Why can't *ALL* ARM SBC run official Linux ARM distro out of the box like all x86 devices does.

 

I really want to know the reason behind this situation and is there a way out?

 

Thanks

[tkaiser]

20 minutes ago, imjtrial said:

Why can't *ALL* ARM SBC run official Linux ARM distro out of the box like all x86 devices does.

 

Since almost all ARM SBC use SoCs that were made with Android or very special purposes in mind. So each SoC maker is doing his own things and we need for every chip family own software. Besides that there's optimizations needed, when you take a vendor (Android) kernel with vendor (Android) settings and combine it with a Linux userland performance will simply suck (well, today same is even true when using community's mainline stuff). That's one of the reasons Armbian exists since we did a lot of research here and ship with 'per device' optimized settings.

 

So even if some (64-bit) SBC now start to ship with an universal bootloader I doubt you get the same overall performance booting an OpenSUSE compared to an optimized Armbian build.

 

But things will improve but not with all SBC but only starting with ARMv8 and it will need a few more years until dedicated distros like ours aren't necessary any more. As a starting point: https://www.cnx-software.com/2014/01/31/arm-unveils-system-base-architecture-specification-to-standardize-arm-based-servers/

[zador.blood.stained]

x86/x64 has an onboard firmware - BIOS and/or EFI that provide basic services (RAM initialization, input (i.e. USB) and output (i.e. video) initialization, storage device access, other peripheral device enumeration) and a lot of devices like sound, network and display are connected to enumerable buses (like PCI/PCIe). As a result you can boot any OS with any kernel that supports your peripherals, and you still can have some BIOS/EFI provided fallbacks i.e. for USB input devices and display output.

 

A typical ARM SBC has no such things. In-SOC BootROM usually can only do a minimal system initialization and preparations to read and launch the second stage loader (example). And most of peripherals are non-enumerable memory-mapped devices. So an "official Linux ARM distro" in order to work "Out of the box" has to provide separate images because those images contain unique for the SoC and board

• second stage bootloader that initializes DRAM and loads the next stage. Each SoC may have a different DRAM controller, this controller may support different DRAM types (DDR2/3/4) and speeds, so it would require different DRAM controller init code and data (type, speed and sometimes size and number of banks)
• "main" bootloader (u-boot) that again needs to "know" what hardware it runs on so it must contain correct drivers, configuration for those drivers and some logic to load and execute a Linux kernel
• hardware description for the kernel (Device Tree)
• kernel command line, especially location of the root file system (by device node or UUID)
• a Linux kernel that has all necessary drivers to run on this hardware

 

Things started to improve for some newer arm64 devices where there is an onboard SPI flash with u-boot and ATF so it can start a Linux kernel with minimal additional configuration, but currently it's still an exception more than a rule and can be found on more expensive ($50+) devices.

[imjtrial]

Got the basic idea and the whole picture now. Really helps!

 

Just ordered a ROCK64 as my ARM SBC and I salute to all members here providing the optimized ARM images!!