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

[starshipeleven]

This is one of the big problems in ARM...

Sorry what? There is no blobs and shit and no need to know obscure crap for board init. If x86 hardware had a bootROM like that instead of relying on blobs and NDAs and shit, you could remove UEFI shitshow firmware from all boards and substitute it with a simple and secure bootloader instead.

[tuxd3v]

Remember, the problem at hand is there's no such thing as a fully generic and fully functional ARMv8 image that will work cross-platform with any device you put it in. Stuff like DTB or custom UEFIs don't fix that.

Agree

I don't think ARM ever predicted their CPUs were going to be used in this way. They were originally for embedded devices, really crappy phones, and routers.

That makes sense, if you go back to last decade, MIPS was in High End devices, ARM was trying to show up..
But with armv7, or armv8, they should have addressed a lot of standard problems, that are still a plague today..

Everybody tough that because ARM will license cores,
It will be a common standard there, something "wonderful",
The problem is that there are now, a zillion standards there( one per CPU vendor, and one per board..sometimes more, depending on the board revision..),
Or resuming it, no standard at all..

[Space Heater]

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..

What do you mean they exist in part? They've existed since 2014, it's just up to the companies that make the SoCs to implement them, and the consumers that buy them to demand it. There's nothing inherently server-specific about them, it's just that the server market won't tolerate a special snowflake image of an OS, whereas the embedded and mobile SoC markets have never had that luxury and thus consumers don't demand it.

[schmidtbag]

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.

Most SoCs or most new SoCs? Because there's plenty out there that don't do this. Also, to my understanding, you're only focusing on the booting part, but not the hardware addressing part, which is the bigger problem. Booting an ARM device with a generic image, though tedious, is easy. In some cases, you can get by using a single dd command and you're good to go. Getting all of your hardware to work properly on a generic image isn't so easy.

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".

I never said it did any more than that...

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.

Again... you're missing the point. The problem is expecting the user to do this themselves. The nice thing about a BIOS chip is it's all done for you out-of-the-box, regardless of what OS you use. You could say "then just use whatever is already provided in a pre-made disk image" but that's exactly what people want to see go away.
Anyway, to my understanding, only ARMv8 servers seem to have "built-in" ACPI support. That's what we want to see in stuff like phones and developer boards in order to make it easier for home users any hobbyists to get into ARM.

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.

Don't DTBs still need to be manually configured per-device? It's a huge step in the right direction since it allows most of your setup to be generic, but it doesn't solve the problem of needing something custom for each platform.

Remember, the problem at hand is there's no such thing as a fully generic and fully functional ARMv8 image that will work cross-platform with any device you put it in. Stuff like DTB or custom UEFIs don't fix that. This is also why we still don't really see anyone offering a typical installer that we so commonly use on x86. Again, ARM servers are the only exception here.

IT needs to be addressed, by both teams HardWare/Software..

Everything on the Linux side of things is fine. The board manufacturers (or ARM themselves) are the ones who need to change something.

In my point of view, ARM should have addressed that problem from the beginning..

I don't think ARM ever predicted their CPUs were going to be used in this way. They were originally for embedded devices, really crappy phones, and routers.

[tuxd3v]

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".

This is one of the big problems in ARM...
At Least some ROM bootloaders, are only used to load a U-Boot( or other ) payload, that assumes control from there on..

[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..

[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..

[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

[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]

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.