The Arm SoC/Platform Changes Finally Sent In For Linux 5.3: Jetson Nano, New SoCs

[phoronix]

Phoronix: The Arm SoC/Platform Changes Finally Sent In For Linux 5.3: Jetson Nano, New SoCs

The Arm SoC/platform changes arrived a bit late to the Linux 5.3 merge window ending this weekend. The Arm SoC/platform changes were only sent in on Friday night but include Librem 5 Developer Kit support in terms of the DeviceTree bits as well as improving the NVIDIA Jetson Nano support and various other SoC/platform additions...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-5.3-Arm-SoC-Platforms

[tuxd3v]

What is missing ARM big, is a Standard bootloader to any board out there..
with each vendor implementing its way of booting its cpu..
Boot loaders exist,
But the lacking of a common way to boot a generic armv8 image is still astonishing..

Should be there,
A final description HAL layer, that describes the hardware in the same way for every single CPU out there..
Also, the same could be said about the booting partitions number and so on..

[Jedibeeftrix]

How does Pi3 support stand right now?

[schmidtbag]

What is missing ARM big, is a Standard bootloader to any board out there..
with each vendor implementing its way of booting its cpu..
Boot loaders exist,
But the lacking of a common way to boot a generic armv8 image is still astonishing..

Should be there,
A final description HAL layer, that describes the hardware in the same way for every single CPU out there..
Also, the same could be said about the booting partitions number and so on..

To my knowledge, both of the problems you mentioned are because there's no BIOS chip. That means this is a hardware issue. Your complaints are valid, but if you're expecting software developers to address these problems, it ain't gonna happen.

[Space Heater]

What is missing ARM big, is a Standard bootloader to any board out there..
with each vendor implementing its way of booting its cpu.
...
But the lacking of a common way to boot a generic armv8 image is still astonishing...

Standards already exist[1][2] that accomplish this, but so far it has primarily been ARM server vendors that think they are important enough to implement. ARM itself doesn't seem to be able to enforce this as they just sell the core IP and do not require a specific SoC implementation standard.

[1] SBSA - Server Base System Architecture
[2] SBBR - Server Base Boot Requirements

[starshipeleven]

To my knowledge, both of the problems you mentioned are because there's no BIOS chip. That means this is a hardware issue. Your complaints are valid, but if you're expecting software developers to address these problems, it ain't gonna happen.

Are you aware that the "bios chip" is just a SPI NOR flash chip containing a firmware?

Are you also aware that in most SoCs the initialization phase is 99% dealt with by a bootROM which is integrated in the SoC itself and can already initialize the system and load a payload (usually a bootloader to boot an OS) from any available storage medium connected?

You can just place the UEFI firmware image at the beginning of the storage device you also place your OS on, this is DEFINITELY just a software thing.

[schmidtbag]

Are you aware that the "bios chip" is just a SPI NOR flash chip containing a firmware?

Uh... yes? Do you seriously not understand what I'm getting at here? Sure, the BIOS is mostly just software, but it's not software that open-source developers are (or should be) responsible for. In other words, it's not software anyone but the manufacturer can edit. It's software that comes with your hardware, because it's device-specific. The purpose of the BIOS is to act like a medium between the mainboard and the kernel. It's what allows your OS to so easily detect and address your hardware, so you don't have to do it manually (which is the case for ARM). Pretty much the benefit of a BIOS chip is that the hardware manufacturer provides it for you, where they did all the hard work. So the only thing the user has to do is get the drivers to operate the hardware. But on ARM, there is no such thing, so, you need a custom disk image that explicitly tells the kernel what the hardware is and where it is addressed.
I really don't see how it's realistic to modify existing software to allow existing ARM devices to just simply "work" on a generic kernel. Without a BIOS or something similar, we're just going to have to deal with custom kernels if we want full hardware support.

You can just place the UEFI firmware image at the beginning of the storage device you also place your OS on, this is DEFINITELY just a software thing.

Except... that doesn't solve the problem. You still need to do some tedious device-specific tweaking. Sure, once you get that UEFI, you shouldn't have to worry about it ever again (at least if you don't swap out your boot device), but the fact you have to do it at all is still enough of a turnoff to some people, and a barrier of entry for noobs. To my knowledge, there are devices out there that come with a UEFI (I think some of the Windows 10 laptops) but it's still rare.

[starshipeleven]

Uh... yes? Do you seriously not understand what I'm getting at here? Sure, the BIOS is mostly just software, but it's not software that open-source developers are (or should be) responsible for.

As I said " in most SoCs the initialization phase is 99% dealt with by a bootROM which is integrated in the SoC itself and can already initialize the system and load a payload".

That's the "tedious device-specific tweaking" part of the x86 BIOS firmware, which you don't need to do on ARM because it's done already by a firmware stored in an integrated ROM memory inside the SoC itself.

The board is in "CPU + RAM + storage initialized" phase when it hands over control over a bootloader stored in the storage, which means your code does not need to do much beyond loading an OS.

The purpose of the BIOS is to act like a medium between the mainboard and the kernel.

Wrong, a BIOS is doing board initialization, then loading an OS and passing it the information about the hardware. End of its job. It's not running anymore after the OS is loaded, it's not an "interface".

on x86 this "passing the information about the hardware" is called ACPI tables, and you can have anything, even u-boot do it as it's just exposing a static binary in a standard location during boot.

On Linux there is also a thing called dtb (device tree) that does the same job the ACPI does but it's less prone to issues, and in embedded you usually define that.

This dtb can either be embedded in the bootloader, or selected on boot by the kernel if the bootloader provides the name of it. Of course this does not work with Windows but it's MUCH easier to make than ACPI.

Most projects, like Armbian and OpenWrt and things from Linaro already ship generic kernels with a dtb wherever possible.

OpenSUSE is also working on the same front https://www.suse.com/media/article/U...f%20U-Boot.pdf

https://www.youtube.com/watch?v=qJAkJ3nmWgM

[tuxd3v]

Standards already exist[1][2] that accomplish this, but so far it has primarily been ARM server vendors that think they are important enough to implement. ARM itself doesn't seem to be able to enforce this as they just sell the core IP and do not require a specific SoC implementation standard.

[1] SBSA - Server Base System Architecture
[2] SBBR - Server Base Boot Requirements

Yes they exist in part, but for the Server market and its, lets say, "a new thing"..
They should be applied to all devices..that's the problem..

[tuxd3v]

To my knowledge, both of the problems you mentioned are because there's no BIOS chip. That means this is a hardware issue. Your complaints are valid, but if you're expecting software developers to address these problems, it ain't gonna happen.

IT needs to be addressed, by both teams HardWare/Software..
There are always a thing that acts like a bios, and that firmware is loaded first, simply it is loaded from the sdcard/SPI flash/etc.. but it acts like if it was a bios..

Its one of the major concerns and damage ARM Hardware credibility,
In my point of view, ARM should have addressed that problem from the beginning..