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

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

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

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

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

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

[schmidtbag]

But with armv7, or armv8, they should have addressed a lot of standard problems, that are still a plague today..

I agree, but keep in mind the largest markets for arm: phones, tablets, network devices, embedded devices, and servers. ARM servers already have everything you're asking for. As for the rest of the stuff, those come with an OS pre-installed that the user is not expected to ever replace. So, even though development boards and hobbyists are a decent sized market, we're kinda an outlier. I feel your pain, but ARM doesn't really have much of an obligation to support us.

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

If you think that sounds bad, I suspect RISC-V won't be much better. That may be open source, but the tweaks companies make to it don't have to be.

[starshipeleven]

Most SoCs or most new SoCs?

All SoCs that are running Linux, can't speak for others.

Because there's plenty out there that don't do this.

You are wrong, at most there is some hardware outside the SoC (like a switch or a modem in a embedded modem-router) where the bootloader is doing initialization, but it's not initializing the SoC hardware itself.

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.

Are you stupid? How does it work on x86 then? The kernel reads ACPI tables and knows what hardware is there.

Generic ARM images have the dtb subsystem enabled, and therefore come with all dtbs of all boards that were upstreamed in a folder located in the /boot folder, as long as the bootloader provides the dtb name (or provides the full dtb on its own) it will work the same.

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

You said "The purpose of the BIOS is to act like a medium between the mainboard and the kernel.", which is not as clear as you might have thought.

Again... you're missing the point. The problem is expecting the user to do this themselves.

This was not clear from your original post though.

Still, manufacturers like Librecomputer are doing this for example, their uboot is using the efi subsystem (which is upstream) and passing the dtb file to Linux kernel on boot, so they can boot a generic EFI image https://libre.computer/2019/02/18/ub...ato-with-uefi/

This will NOT work with Windows because it's using dtb and not ACPI, even if it's EFI boot.

Anyway, to my understanding, only ARMv8 servers seem to have "built-in" ACPI support.

Servers have full UEFI firmware in a "BIOS chip", but UEFI is a huge PITA to work with so it's 100% impossible that anyone outside of high-end hardware will ever want to deal with it unless forced.
see the various UEFI implementations for raspi https://github.com/andreiw/RaspberryPiPkg

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.

No we don't need ACPI and full UEFI unless we need to boot Windows.

Don't DTBs still need to be manually configured per-device?

It's an ACPI equivalent, duh. Of course each board has its own dtb. They are usually drived by a "master dtb" published by the SoC manufacturer as part of the basic Linux support for that SoC. To create your board's dtb you only need to enable or disable what was actually connected or not in the end device. It's a piece of cake if compared to Coreboot.

For decent boards they are usually merged upstream, but the uboot bootloader can also store the board's dtb in itself and then pass it to a booting Linux kernel, similar to what a BIOS does with ACPI tables.

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.

Yes they do. If you replace the stock uboot with a more modern one that can boot efi and embed in it the dtb file (or use a device where the board has a dtb that was upstreamed) you will be able to use a generic EFI image.
Also on ARMv7 because uboot can do that also there.

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

Yes it's correct, but since ARM has a very neat split between the board initialization and the bootloader, and the former is usually done by a bootROM which you can't touch anyway, you can usually replace the bootloader, it's not as arcane and hard as with Coreboot.

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.

The outlier is x86 with its standardized ecosystem, mostly because of Windows.

Everything else is a Wild West of random stuff where none cares about running a generic OS image.

[schmidtbag]

You are wrong, at most there is some hardware outside the SoC (like a switch or a modem in a embedded modem-router) where the bootloader is doing initialization, but it's not initializing the SoC hardware itself.

I'm beginning to question if we're talking about the same thing...

Are you stupid? How does it work on x86 then? The kernel reads ACPI tables and knows what hardware is there.

Are you stupid? Because I didn't say anything that suggested that the kernel doesn't read ACPI tables. You aren't paying much attention today.
I'm saying that ARM devices don't normally have an ACPI table to begin with and anything you to do provide one (or something similar) is not supplied by the device itself (again, not talking about server hardware here). For noobs, this is a problem. For experienced users, this is tedious.

Generic ARM images have the dtb subsystem enabled, and therefore come with all dtbs of all boards that were upstreamed in a folder located in the /boot folder, as long as the bootloader provides the dtb name (or provides the full dtb on its own) it will work the same.

Yes, I've noticed that. As far as I'm aware, DTB doesn't automatically do all the work for you; you still need to configure it for each platform you put it on. DTB makes life much easier, but not as easy as a BIOS. When the hardware itself provides the means for an easy selection of boot devices or hardware addressing, you can boot up something generic and it "just works" (again, assuming you have the right drivers). The average consumer-grade ARM platform doesn't have that luxury, and that's what tuxd3v was complaining about.

You said "The purpose of the BIOS is to act like a medium between the mainboard and the kernel.", which is not as clear as you might have thought.

I didn't specify the duration or when it happens. That doesn't make me wrong.

This was not clear from your original post though.

It was made abundantly clear by tuxd3v, who is the person my original post was addressing.

Still, manufacturers like Librecomputer are doing this for example, their uboot is using the efi subsystem (which is upstream) and passing the dtb file to Linux kernel on boot, so they can boot a generic EFI image https://libre.computer/2019/02/18/ub...ato-with-uefi/

But... that's still a device-specific disk image. It's a great step in the right direction, but the topic at hand is trying to have a true generic cross-compatible image; that link does not fit such a description.

No we don't need ACPI and full UEFI unless we need to boot Windows.

I agree; ACPI and a full UEFI by themselves aren't necessary. My point is we want the device to provide such things, so people can more easily use a generic installer or disk image (for any OS) with relative ease. With a BIOS, you don't need to implement ACPI, DTB, UEFI, or whatever else yourself. Do you not understand this?

It's an ACPI equivalent, duh. Of course each board has its own dtb. ... To create your board's dtb you only need to enable or disable what was actually connected or not in the end device.

Then you've completely missed the point of this whole discussion. I'm not denying anything you're saying there, but it's not fixing the underlying problem, which I feel I have stated way too many times by now.

Yes they do. If you replace the stock uboot with a more modern one that can boot efi and embed in it the dtb file (or use a device where the board has a dtb that was upstreamed) you will be able to use a generic EFI image.

You're still not getting it...
You can't take the SD card from something like a Raspberry Pi and put it in a Cubieboard and expect it to boot up with all the hardware working. You have to make changes. It's possible to have the OS carry over just fine (assuming you don't have something like blacklisted drivers or a very specific xorg.conf) but in most cases, you only have a single SD card to boot from, which includes your OS. That makes portability cumbersome. But hypothetically, let's say your Linux install is on a USB hard drive, where you're using the SD card just for booting, DTB, and the EFI. That makes a very dramatic improvement in portability, since you're basically substituting the SD card for what could have been an on-board BIOS chip. But that brings us full-circle to the original problem:
Why can't the manufacturers just provide that functionality out-of-the-box, directly on the hardware, like you find on x86 BIOS chips? We know it's possible because ARM servers do it.

The outlier is x86 with its standardized ecosystem, mostly because of Windows.

Well if you account for all devices and architectures then yeah, x86 is very much an outlier. But in terms of most PCs and rack-mounted servers, x86 is not an outlier. As far as I'm aware, POWER (or at least certain variants of it) and SPARC have at least some firmware. And like I said, ARM servers do it too. I'm not sure about anything else, since it isn't really something I extensively look into.

[tuxd3v]

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.

I mean exactly that,
They are not a global standard for all boards..so they 'exist in part'..
On Servers probably all( or maybe not all, but majority ), they implement it, but for developers that buy a sbc, its a nightmare..

I own several SBCs, and I am in need to create a build system, that I am finishing, or almost, exactly because of that..
In 99% of the cases you get, something that is lacking drivers, or have outdated kernels, or even a mix of this, with kernel headers missing, or a buggy DTB..

How will you develop a kernel driver in this environment?
You need to roll out your own image,
But some boards doesn't even have mainline kernels, or if have, they lack a complete DTB, or drivers for it..

[tuxd3v]

All SoCs that are running Linux, can't speak for others.
You are wrong, at most there is some hardware outside the SoC (like a switch or a modem in a embedded modem-router) where the bootloader is doing initialization, but it's not initializing the SoC hardware itself.

The Boot Loaders that exists in some SoCs in the form of a ROM, are very limited in functionality!
Also,
They are not standard across all Soc Vendors, sometimes they are not even Standard on all SoCs from the same vendor..
The ROM bootloader,
Is has a tinny ROM space.. some times around 20kB,
And it usually only has the ability to initialise some core components( like the ability to load, the boot loader from spi flash, or usb, or sd card, or even in FEL mode flash a new boot0 ROM( to sdcard, flash, etc )

So its not that it initialise all hardware,
That is wrong, it is a tinny peace..
Compile bootloader like uboot, and you will see that it has >500KB of size.

Bottom Line, does it initialise all hardware in the SoC?
No it doesn't,
Because it only has facilities to to basic stuff that permits him to load a payload, that will assume control from there on..

So it doesn't do 99% of the requirements,like you stated..
It does 10-20% or even less than that..the rest is done by the payload it loads( at that time will be loaded to the Global RAM )