ARM about to standardize boot

[bzt]

Not entirely sure this is the right topic, but it's more about the theory and overall boot procedure I guess.

It looks like ARM has decided to use UEFI, and demands SoC manufacturers to comply. The current buzzword is ARM SystemReady. They say that this should standardize the boot environment on IoT devices, however I'm not sure what they were thinking. IoT devices are particularly short on resources, and TianoCore requires 64M of RAM to even get booted. No IoT devices I have programmed so far have that kind of RAM. Not sure how this is viable in real life applications.

I guess they'll have to reimplement UEFI from ground up according to Base Boot Requirements Specification, I don't think porting TianoCore as-is could work because of its resource wasting nature. Thoughts?

Another issue I see with this is, it only allows booting into EL2, so EL3 hypervisor kernels are impossible and they must find a dirty workaround to circumvent the entire BBR (you can't access EL3 system registers from EL2, so you can't just simply elevate level with an eret).

Standardized way to read and write sectors on SD cards (with BLOCK_IO_PROTOCOL) also missing. Only SIMPLE_FILE_SYSTEM_PROTOCOL is mandatory (which means stranded to FAT on ESP, forget to implement your own file system, or looking for arbitrary GPT partition entries, like BIOS Boot Partition.)

Good things: GOP support on ARM SoC, no more VC/Mali/whatever specific code to change screen resolution. ACPI tables to describe the hardware instead of that device tree hack. Standardized GPT partitioning, with loader files on the ESP.

(note: this also demands NOT to use exFAT on the SD cards, as they must be GPT partitioned instead, with ESP formatted to FAT16/FAT32)

Cheers,
bzt

[Korona]

Is GOP support mandated by UEFI? This would indeed be helpful.

[Schol-R-LEA]

Are they intending to use TianoCore as the required implementation, or only as a reference implementation, and allow smaller configurations to use, say, Das U-Boot? U-Boot is a good deal lighter than TianoCore, IIUC, and while it would still be quite a heavyweight solution for many IoT applications, I am pretty sure it can be configured to boot with a 1MiB footprint.

While that's quite a bit for general embedded use, my understanding is that for IoT applications, 1 MiB or more is typically used for the TCP/IP stack (while that much memory certainly isn't required to support the base TCP/IP stack, these days it is a lot easier to throw memory at it rather than trying to squeeze it into a smaller memory footprint, especially if you add things like an HTTPS server or SCADA interface into the mix).

Also, correct me if I am wrong, but don't many - perhaps most - of the MCU-class ARM SoCs today have a significant amount of memory on-chip, in addition to whatever gets added by a given SBC or microcontroller? I have no real experience with IoT devices, but that was my impression regarding ARM devices specifically.

For commercial applications you generally aren't going to use an ARM for something that could be done in less than 1MiB anyway, but would stick to an 8-bit or 16-bit MCU for small enough use cases. In maker uses, too, many would use an Arduino or similar rather than an ARM SBC if the application isn't that demanding. I suspect that 32-bit RISC-V MCUs are going to be taking over a good chunk of the space between 1 MiB and 64 MiB applications, too, though it is still early days for them and we'll have to see how that goes.

Finally, I get the impression that ARM (and Nvidia, should that deal go through) want to move away from MCU-class processors, even in their SoC intellectual property. Whether this a wise move is left as an exercise for the readers.

[bzt]

Is GOP support mandated by UEFI? This would indeed be helpful.

Well, not exactly. But GOP is the only protocol to deal with video cards in UEFI (UGA was obsoleted), and the linked BBR specification explicitly lists GOP as a recommended protocol (meaning if video is supported, it is supposed to implement GOP).

Are they intending to use TianoCore as the required implementation, or only as a reference implementation

I don't know, that's why I'm asking, what you think.

and allow smaller configurations to use, say, Das U-Boot?

They only mention the possibility of a non-EDK2, but UEFI compatible loader in EBBR recipie (which then gives U-Boot as example, but it is strange as to my best knowledge U-Boot doesn't provide UEFI interfaces). They list something called LinuxBoot as a possibility in LBBR recepie, which is very confusing, because coreboot used to be LinuxBoot, but they had to change their name, and now the BBR spec is linking to an entirely different project by that name? Very very confusing... Anyway, none of the well-known and usual boot loaders are allowed by the spec, they all must be UEFI compliant. The Figure 4-1 Relationships among SBBR, ESBBR, EBBR, and LBBR on page 14 is a complete mess, makes absolutely no sense at all. It's more like a marketing chart than a serious technical figure.

U-Boot is a good deal lighter than TianoCore, IIUC, and while it would still be quite a heavyweight solution for many IoT applications, I am pretty sure it can be configured to boot with a 1MiB footprint.

Yes it is, U-Boot and all the other solutions are pretty lightweight compared to TianoCore.

While that's quite a bit for general embedded use, my understanding is that for IoT applications, 1 MiB or more is typically used for the TCP/IP stack (while that much memory certainly isn't required to support the base TCP/IP stack, these days it is a lot easier to throw memory at it rather than trying to squeeze it into a smaller memory footprint, especially if you add things like an HTTPS server or SCADA interface into the mix).

Yes, it's not uncommon for IoT to have 2 or 4MiB of RAM, however that's still far less than 64MiB.

Also, correct me if I am wrong, but don't many - perhaps most - of the MCU-class ARM SoCs today have a significant amount of memory on-chip, in addition to whatever gets added by a given SBC or microcontroller? I have no real experience with IoT devices, but that was my impression regarding ARM devices specifically.

The problem with adding more RAM is that it makes the production as well as the TCO more expensive (needs larger bus width, which means more transistors, which means more power consumption etc.). Take a look at Linksys routers or D-Link routers (both using some ARM SoC), I wouldn't call them typical IoT devices, rather something more advanced, above the IoT grade, yet most of them have 4MiB of RAM, some have 16MiB and 32MiB is extremely rare and that's the max in the SOHO class. Routers with 64MiB RAM or more are considered high-class, only found in the most expensive, top gigabit routers.

For commercial applications you generally aren't going to use an ARM for something that could be done in less than 1MiB anyway, but would stick to an 8-bit or 16-bit MCU for small enough use cases. In maker uses, too, many would use an Arduino or similar rather than an ARM SBC if the application isn't that demanding. I suspect that 32-bit RISC-V MCUs are going to be taking over a good chunk of the space between 1 MiB and 64 MiB applications, too, though it is still early days for them and we'll have to see how that goes.

I agree. This whole thing questions the viability of ARM in IoT devices (I agree it's more likely that someone chooses an Arduino-class MCU instead). About RISC-V I don't know. I'm watching it closely because I see potential in it, but for now boards are insanely expensive and it's not wide-spread yet, so it's hard to tell its strengths and weeknesses. We'll see, definitely worth keeping an eye on it.

Finally, I get the impression that ARM (and Nvidia, should that deal go through) want to move away from MCU-class processors, even in their SoC intellectual property. Whether this a wise move is left as an exercise for the readers.

Despite of that, they are marketing this for IoT, that's what's confusing. For a tablet or desktop PC maybe, there's nothing wrong with ARM using UEFI when you have at least 1GiB of RAM, but for smaller devices as they advertise, I don't know... (FYI: ARM ServerReady is UEFI for servers, and now ARM SystemReady aims at smaller than server devices and IoT)

Cheers,
bzt

[zaval]

(note: this also demands NOT to use exFAT on the SD cards, as they must be GPT partitioned instead, with ESP formatted to FAT16/FAT32)

FALSE statement, bzt.

1) SDA specification does require using only exFAT for SDXC cards
2) UEFI doesn't demand using GPT, nor even having ESP. I'm testing my things on x86 hardware, ARM SBCs, x86 and ARM VMs, provided by emulators without either GPT or ESP and not a single time I faced rejecting to boot my UEFI OSL.

Why are you doing this? You've been pointed to the specs so many times, showing your statements about this are wrong and you keep repeating them again and again.

Most ARM platforms just use eMMC/UFS/NVMe/SATA as their main persistent storage, so there one could put ESP, and make that storage GPT partitioned. If that's so horribly needed. I am wondering why, btw, for example a 32 GB eMMC would need 128+ partitions, but anyway.

[zaval]

Is GOP support mandated by UEFI? This would indeed be helpful.

GOP is required if the platform has video output device. That is if a display could be attached to the board, then the board UEFI is required to have GOP.

[zaval]

Standardized way to read and write sectors on SD cards (with BLOCK_IO_PROTOCOL) also missing. Only SIMPLE_FILE_SYSTEM_PROTOCOL is mandatory (which means stranded to FAT on ESP, forget to implement your own file system, or looking for arbitrary GPT partition entries, like BIOS Boot Partition.)

Fantasies again?

5. If a platform includes the ability to boot from a disk device, then the
EFI_BLOCK_IO_PROTOCOL, the EFI_DISK_IO_PROTOCOL, the
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL, and the
EFI_UNICODE_COLLATION_PROTOCOL are required.

A compliant implementation should provide EFI_BLOCK_IO_PROTOCOL.

[zaval]

U-Boot is a good deal lighter than TianoCore, IIUC, and while it would still be quite a heavyweight solution for many IoT applications, I am pretty sure it can be configured to boot with a 1MiB footprint.

This bent to linux thing has improved its UEFI support significnatly, but still, unfortunately, you may easily notice the inclination to be not UEFI compliant, but rather "let's have what grub and linux expect and that's all" kind of attitude. Nevertheless, I was able to run my loader on a RockPi 4B (RK3399) board and test some important things - file reads, GOP support, event/timer/notification callbacks, boot variables - unlike the previous experience, this time everything worked good. The boring and lame video of a Boot Screen demo applied blatantly.

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

Or, the shorter, but still lame af variant, but with a more badass visual appearance.
https://www.youtube.com/watch?v=Ph-yxR00x7g

[bzt]

Why are you doing this? You've been pointed to the specs so many times

You should ask this from yourself, not from me. You're the one who is not reading the specs, and in fact doesn't even know what the topic is about.

1) SDA specification does require using only exFAT for SDXC cards

Nope, it does not. I leave you as a homework to read the SDA spec and figure out why you're wrong (hint: section 5.3.2 CSD Register, bits FILE_FORMAT_GRP and FILE_FORMAT bits.)

2) UEFI doesn't demand using GPT, nor even having ESP.

Yes, UEFI does demand these (see section 13.3.1 System Partition, it explicitly states that partitionless layout is allowed on diskettes (floppies) only and not on other media, and section 13.3.1.1 File System Format states that the partition must be an EFI System Partition).

But we're not discussing UEFI here, in case you haven't noticed, the topic is about the ARM BBR specification, which explicitly states that

Code: Select all

7.3.2   System volume format
The system firmware must support the disk partitioning schemes that are required by the UEFI specification [UEFI§2.6.2][UEFI §13.3.1]. 

Note the wording: "must support", "required".

I'm testing my things on x86 hardware, ARM SBCs, x86 and ARM VMs, provided by emulators without either GPT or ESP and not a single time I faced rejecting to boot my UEFI OSL.

Lies. I will tell you this from eye to eye. You're a liar.
1. You can't test ARM SystemReady because it's not implemented yet, it has just been announced, about a week ago.
2. Show us your configuration and disk image which doesn't have any ESP (neither partitionless, MBR or GPT) but boots FS0:\EFI\BOOT\BOOTX64.EFI (or any other OSL). Go on, show us a working example! You said you have PoCs, so show us one!

Most ARM platforms just use eMMC/UFS/NVMe/SATA as their main persistent storage, so there one could put ESP, and make that storage GPT partitioned.

You can't have a GPT partitioning scheme and an exFAT only device at the same time. You're contradicting yourself. And have you read the title of the topic? This is about ARM SystemReady and not about "most ARM platforms".

A compliant implementation should provide EFI_BLOCK_IO_PROTOCOL.

Take this for example. You've absolutely no clue what you're talking about. The ARM SystemReady BBR specification explicitly lists the protocols that must be implemented in "Appendix C Required UEFI Protocols". Block IO Protocol is not listed there, only the Simple File System Protocol. And just for the records, block IO isn't listed in "Appendix D Optional UEFI Protocols" either. Meaning an ARM BBR compliant implementation isn't required to implement Block IO Protocol, which is a big problem.

Cheers,
bzt

[iansjack]

1. You can't test ARM SystemReady because ... it has just been announced, about a week ago.

No - it was announced several months ago: https://community.arm.com/developer/ip- ... -ecosystem

[bzt]

1. You can't test ARM SystemReady because ... it has just been announced, about a week ago.

No - it was announced several months ago: https://community.arm.com/developer/ip- ... -ecosystem

Right, the report about it was a week ago, this does not change the fact that ARM SystemReady is only announced and hasn't been implemented yet. No VM exists to test it yet, so zaval can't do "testing in emulators" as he claims (and if he was talking about something else, then he was off-topic).

I really would like to see at least one test case (with VM configuration and disk image) where he boots an OSL without an ESP file system (neither partitionless floppy, MBR nor GPT partitioned as he claims).

Cheers,
bzt

[zaval]

1) SDA specification does require using only exFAT for SDXC cards

Nope, it does not. I leave you as a homework to read the SDA spec and figure out why you're wrong (hint: section 5.3.2 CSD Register, bits FILE_FORMAT_GRP and FILE_FORMAT bits.)

Yes, it does. You are sticking to those bits like to a lifebuoy. I understand, you want to be always right and you cannot see facts, you don't like but hey, dude, here is a portion of reality to you, it's not that bad - under the table, describing those bits, there is a line "A more detailed description is given in the File System Specification". Have you ever looked at it? Get real a bit, come back to Earth, open for yourself that freaking part of the SD specification finally, and you'll find out, that the only valid values for those bits are 0.0. Here, a more detailed answer, posted to your previous false about the same topic, just 5 days ago. It was a 100th time. There couldn't be any sane reason to repeat it 101th. Notice, I highlighted in RED the part of the spec, telling very clearly what FSs SHALL be used.

2) UEFI doesn't demand using GPT, nor even having ESP.

Yes, UEFI does demand these (see section 13.3.1 System Partition, it explicitly states that partitionless layout is allowed on diskettes (floppies) only and not on other media, and section 13.3.1.1 File System Format states that the partition must be an EFI System Partition).

You stated several times, you are a genius here, but still pretend to be this dense? How on earth, "partitionless" layout, being allowed "only" on diskettes, proves, that UEFI does demand using GPT? ESP is a convention, not requirement, GPT is one of the supported partitioning schemes, and not the only one, and moreover is not a requirement to be used exclusively.

But we're not discussing UEFI here, in case you haven't noticed, the topic is about the ARM BBR specification, which explicitly states that

Code: Select all

7.3.2   System volume format
The system firmware must support the disk partitioning schemes that are required by the UEFI specification [UEFI§2.6.2][UEFI §13.3.1].

Note the wording: "must support", "required".

UEFI does require to support MBR, GPT and El Torito. So, if a machine has only SD card as its storage, then it would be MBR. Because UEFI does support it, and SD spec requires it and only it as the partitioning scheme.

I'm testing my things on x86 hardware, ARM SBCs, x86 and ARM VMs, provided by emulators without either GPT or ESP and not a single time I faced rejecting to boot my UEFI OSL.

Lies. I will tell you this from eye to eye. You're a liar.
1. You can't test ARM SystemReady because it's not implemented yet, it has just been announced, about a week ago.
2. Show us your configuration and disk image which doesn't have any ESP (neither partitionless, MBR or GPT) but boots FS0:\EFI\BOOT\BOOTX64.EFI (or any other OSL). Go on, show us a working example! You said you have PoCs, so show us one!

I have shown. Even the above videos do show. Better check it by yourself. Create a virtual disk, partition it with MBR, put there an ordinary FAT partition, put in it your OSL and start it from, for example, the UEFI "shell". It will work. It's ARM, it's UEFI, it's boot on ARM in the UEFI environment.

Most ARM platforms just use eMMC/UFS/NVMe/SATA as their main persistent storage, so there one could put ESP, and make that storage GPT partitioned.

You can't have a GPT partitioning scheme and an exFAT only device at the same time. You're contradicting yourself. And have you read the title of the topic? This is about ARM SystemReady and not about "most ARM platforms".

Oh, naive innocence again. What you quoted, meant: "since you wrongly believe, you necessarily need GPT and ESP, then relax, you can have it, because those platforms have eMMC etc as their main storage, where GPT is ok, just like FS is not required to be of a particular type".

This RPi-like way of doing stuff, where SD cards are the only storage is a big PITA, because it breaks so many standards and intentions. But even in this enthusiast ARM SBCs space, boards with only SD cards as storage are rare. Even then, if you wanna stay compliant, not break anything and not get in troubles, just use SDSC/SDHC cards for your setup - with MBR, ordinary (not ESP), single FAT, as required by SDA, it will be still perfectly UEFI compliant. This way is clear? Or will be playing fool again?
You started this topic with these lines:

It looks like ARM has decided to use UEFI, and demands SoC manufacturers to comply.

My reactions are in accordance to this claim. ARM cannot invent "other" UEFI, there is only one UEFI and its spec, and only it, is the ultimate source for reference.

A compliant implementation should provide EFI_BLOCK_IO_PROTOCOL.

Take this for example. You've absolutely no clue what you're talking about. The ARM SystemReady BBR specification explicitly lists the protocols that must be implemented in "Appendix C Required UEFI Protocols". Block IO Protocol is not listed there, only the Simple File System Protocol. And just for the records, block IO isn't listed in "Appendix D Optional UEFI Protocols" either. Meaning an ARM BBR compliant implementation isn't required to implement Block IO Protocol, which is a big problem.

In this light, your SystemReady is either UEFI compliant or not. If it is, then again, - look at the quote from the UEFI spec, I showed - block IO protocol is a requirement if the platform has block devices on. If it's not, then your impression about "ARM deciding to use UEFI" is wrong and this SystemReady is SystemNotReady, if it comes to UEFI. This is enough. And the logic adds its 2c - the block IO protocol is the underlying protocol beneath SFSP, the latter uses the former, if there weren't block IO protocol, SFSP would fail. I don't know why they didn't list it, but nobody should care because if it's UEFI, then this protocol will be available.

[bzt]

Dear Zaval,

Better check it by yourself.

I would check it, but so far you haven't showed us anything that we could check! Enough of cheap talk, show us your code!

Get real a bit, come back to Earth, open for yourself that freaking part of the SD specification finally, and you'll find out, that the only valid values for those bits are 0.0.

UEFI does require to support MBR, GPT and El Torito. So, if a machine has only SD card as its storage, then it would be MBR.

And show us a SD card image that's exFAT only but has a partitioning table at the same! Good luck with that!

Until you show a working PoC for these, you're nothing more than a troll, and I'll just skip your posts and ask all forum members to do the same. That's how it works in civilized discussions, your statements must be emprirecally proven by showing us working examples. So far you have shown nothing, so there's no reason to take you seriously.

Have a nice day,
bzt

[kzinti]

Until you show a working PoC for these, you're nothing more than a troll, and I'll just skip your posts and ask all forum members to do the same. That's how it works in civilized discussions, your statements must be emprirecally proven by showing us working examples. So far you have shown nothing, so there's no reason to take you seriously.

Look who is talking and heating up a thread again.

[bzt]

Until you show a working PoC for these, you're nothing more than a troll, and I'll just skip your posts and ask all forum members to do the same. That's how it works in civilized discussions, your statements must be emprirecally proven by showing us working examples. So far you have shown nothing, so there's no reason to take you seriously.

Look who is talking and heating up a thread again.

It is you, @kzinti and @zaval. Ain't didn't call zaval "lifebuoy", "dude", "naive" and all the other things, he was the one who become personal and tried to insult me. Nonetheless zaval told obvious lies, getting into contradiction with himself within one post. I've just kindly asked for a PoC.

If you think that's "heating up" or if you have any problem with me asking for a PoC at all, then you're part of the problem too.

This isn't the first time that zaval is trying to insult me in his very first post and then someone else tying to paint me the bad guy. It is quite boring after the third or fourth time TBH, you should come up with something more creative.

Cheers,
bzt