OSDev.org

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

That's why Brendan did it right, blocking you.

Duplicate threads should be locked.

I've created a new thread because you were trolling in the other too. Please don't pollute the forum with your off-topic posts. I've reported both of you, in case any moderator are listening.
For all the other forum members, please ignore them, and let us discuss ARM SystemReady.

Cheers,
bzt

bzt wrote:I've created a new thread because you were trolling in the other too. Please don't pollute the forum with your off-topic posts. I've reported both of you, in case any moderator are listening.
For all the other forum members, please ignore them, and let us discuss ARM SystemReady.

Cheers,
bzt

You duplicated your nonsense after being pointed to your absolutely false statements. not being able to prove your statements, you went and duplicated your thread, repeating those bullsh1t statements.

And do you really think, you have a bit of credibility to recommend for others whom to ignore. if there was a poll of what to do with your pathologic behavior here, you would have been kicked out of here in minutes. You managed to piss off everyone over here. Just a note to your "please, ignore them". But thread duplication after being pointed to the obvious misleading statements, with repeating them again, is an ask to get banned without warning. This thread is NOT about SystemReady, it's a duplicate of your idiocy, generated in the previous thread.

"let us discuss ARM SystemReady"... your pile of verbiage, showing complete ignorance about ARM, UEFI, SDA specs ARE NOT discussion of ARM SystemReady. You didn't even know, that not every volume (not even FAT one) is an ESP! Go read the specs, you are blaming here, spitting up your toxic saliva, "genius".

It's too much of you. your delusions about CIA rootkits, "stupid Intel and M$ engineers". Repulsive, ignorant and arrogant. Giving sh1tty advices, making fights with everyone dared to point to your errs and now duplicating threads.

zaval wrote:

bzt wrote:I've created a new thread because you were trolling in the other too. Please don't pollute the forum with your off-topic posts. I've reported both of you, in case any moderator are listening.
For all the other forum members, please ignore them, and let us discuss ARM SystemReady.

Cheers,
bzt

You duplicated your nonsense after being pointed to your absolutely false statements. not being able to prove your statements, you went and duplicated your thread, repeating those bullsh1t statements.

You latched onto one "bullsh1t" statement (OK, after rereading, two statements) out of his whole post and freaked out about it. bzt then freaked out about you freaking out about it, and pretty soon the thread was buried in vituperative debate on that single point and allegations of trollery. Neither you nor bzt is really a troll, but you both have explosive tempers with very short fuses.

If anyone else had engaged with that particular point in his post in such a way that you thought they were being mislead by him, then you would have some cause to *civilly* express your disagreement (your expression of disagreement was very much not civil). Since nobody did engage with that particular point before you did, and since the two of you have already kicked this particular dead horse several miles down the road, how about you just ignore that bit of "bullsh1t" and discuss some of his other points, or, at the very least give others the space to do so.

And do you really think, you have a bit of credibility to recommend for others whom to ignore.

I will decide for myself who I want to ignore, whatever either of you says. I doubt either of you want my opinion, but if you do, how about you ignore *each other*, rather than exploding every time the other one opens his mouth?

if there was a poll of what to do with your pathologic behavior here, you would have been kicked out of here in minutes. You managed to piss off everyone over here.

I can't speak for everyone here, but the way the two of you interact pisses me off a lot more than either one of you does individually.

Just a note to your "please, ignore them". But thread duplication after being pointed to the obvious misleading statements, with repeating them again, is an ask to get banned without warning. This thread is NOT about SystemReady, it's a duplicate of your idiocy, generated in the previous thread.

On most forums I've been on, if the mods caught it before bzt did, your initial post in the other thread probably would have been deleted and you would have been sent a warning about civil behavior.

If the flamewar had become well developed before the mods caught it, the either, a) The mods would have deleted the flamewar posts and directed everybody to discuss the rest of the OP or, b) The thread would have been locked. At that point, depending on how many warnings you had received in the past about your mutual flamewars, a) You would both have been sent warnings about civil behavior, b) you both would have received temporary bans to cool you down (and to demonstrate that the mods were serious), or c) you both would have been permabanned.

If bzt opened a new thread after the mods had locked it (for whatever reason), he would probably receive at least a temporary ban. However, if the mods had not yet locked the initial thread, I'm not sure what most forums would do, as I don't think I've seen anything like this before. If you followed him to the new thread, it would probably just be treated as an extension of the initial flameware and treated the same way. If you didn't, and other people engaged in civil discussion in the new thread, it would probably be allowed to slide.

"let us discuss ARM SystemReady"... your pile of verbiage, showing complete ignorance about ARM, UEFI, SDA specs ARE NOT discussion of ARM SystemReady. You didn't even know, that not every volume (not even FAT one) is an ESP! Go read the specs, you are blaming here, spitting up your toxic saliva, "genius".

How's about you engage with the below. I've snipped out the parts you find so offensive:

bzt wrote: 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).

<snip>

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.

<snip>

Cheers,
bzt

If you can't engage civilly with the above, how about you allow everyone else to do so, and form their own opinions on whether bzt is a genius, an idiot, or somewhere in between.

zaval wrote: It's too much of you. your delusions about CIA rootkits, "stupid Intel and M$ engineers". Repulsive, ignorant and arrogant. Giving sh1tty advices, making fights with everyone dared to point to your errs and now duplicating threads.

As for "stupid Intel and M$ engineers", my experience is that groups of humans (including, but not limited to, corporations) tend to be stupider than the sum of their parts. You and bzt are the paramount example of this: On your own, you are each quite intelligent. When put together, you do nothing but generate meaningless, rage-filled noise. So please, ignore each other and give the rest of us some peace.

linguofreak wrote:bzt then freaked out

Correction: I've never freaked out, and I wasn't angry at all. People often try to accuse me of these things which I don't understand because I was calm all along (well, if anything then I was sad and felt sorry). Please do not assume such things, because written posts lack metacommunication and there's no emoji for sarcasm so you'll be probably wrong.

Otherwise I understand that you don't want to assume that he is a troll, neither did I at first. I even gave him a second chance after he provided Ukrainian translation for one of my projects. But no use, just see how he "thanked" me that chance.

If you answer to his post, he'll just keep derailing this topic too. And I'm much more interested in ARM SystemReady and Base Boot Requirements Specification than in that nonsense, so please let's focus on the topic. For example, what that two statements would be? You forgot to write why do you think they are not valid (if you think so, and you weren't just referring to zaval's opinion, that part is unclear).

Cheers,
bzt

bzt wrote:

linguofreak wrote:bzt then freaked out

Correction: I've never freaked out, and I wasn't angry at all. People often try to accuse me of these things which I don't understand because I was calm all along (well, if anything then I was sad and felt sorry). Please do not assume such things, because written posts lack metacommunication and there's no emoji for sarcasm so you'll be probably wrong.

Whatever your actual feelings, immediately calling him a liar does not communicate "not angry".

Otherwise I understand that you don't want to assume that he is a troll, neither did I at first. I even gave him a second chance after he provided Ukrainian translation for one of my projects. But no use, just see how he "thanked" me that chance.

It's not that I don't want to assume he's a troll, it's that trolling is not the only way to misbehave on the internet.

If you answer to his post, he'll just keep derailing this topic too. And I'm much more interested in ARM SystemReady and Base Boot Requirements Specification than in that nonsense, so please let's focus on the topic. For example, what that two statements would be? You forgot to write why do you think they are not valid (if you think so, and you weren't just referring to zaval's opinion, that part is unclear).

I was referring to zaval's opinion. The two statements I was referring to are the two he reacted to in the original thread:

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

and,

"(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)"

As for my opinion on those points:

1) It is possible for two standards (e.g, UEFI and SDXC) to conflict, so that there is no standards-compliant way to deal with things when both are applicable to a situation.

2) AFAICT, zaval is *technically* correct about the use of exFAT on SDXC being mandatory, however:

3) This just demonstrates that the standards committee involved was batsh*t crazy, because:

4) Consumers are unlikely to have read the specification, so it can only realistically constrain manufacturers, that is, they can only constrain the filesystem the card ships with, therefore:

5) There is no guarantee that an end-user won't format it with NTFS or ext4, or write it over from /dev/random , with the result that:

6) It is poor engineering for any manufacturer to assume that exFAT will be the only filesystem used on their cards and to include hardware that accelerates FAT operations and misbehaves when presented with another filesystem. There are doubtless cards that do this, meaning that as OS developers we have an adversarial implementation to deal with, but consumers that haven't read the standard will simply think "these SD cards sure are failing a lot, maybe I should try another brand", and consumers that have read the standard *should* be appalled by the poor engineering and use a different brand of SD card.

A good manufacturer will simply build a card that can be used with any FS and comply with the standard by shipping it pre-formatted with exFAT. As OS developers, our code can assume that if it was successfully booted from an SDXC card that is formatted with something other than exFAT, then the card is *probably* well manufactured. However, when building installation images, it may be advisable to provide an image that can be used on a pathologically correct SDXC card.

1) It is possible for two standards (e.g, UEFI and SDXC) to conflict, so that there is no standards-compliant way to deal with things when both are applicable to a situation.

They do not conflict. SD cards were designed to be portable/removable storages. UEFI doesn't demand using/having ESP and GPT at all, moreover - on a removable device. You really cannot use an SDXC card for putting there your UEFI OSL, not to mention - creating there an ESP, but UEFI considers, that ESP is on the non-removable storage and always FAT32, there is no conflict, because by the definition any SD card is for removable storage role and cannot use anything other than MBR with just one FAT partition. You won't blame Bluray disk for the same eh? It cannot be an ESP home as well, but it's not "conflict". It's common sense. If you need so badly to install from an SD card, then use something simpler - SDSC, SDHC, they are perfectly suitable for the preinstallation launch of your OSL by UEFI, due to the FAT presence/support in both spec (SD/UEFI resp.)

That misinformation so crazily repeated by this thread duplicator is why I "latched on". there is half of a dozen of BS statements in his original post, twisting each other and all the "conclusions" of this fake "expert". and he went, after pointing to them, and repeated that nonsense here again... Anyway, I promised myself to not react to his delusions anymore. I came in to respond to your quoted statement only.

What is against standards is when a single board computer (hey, RPi) doesn't have anything except SD card as storage. But even then, it's a "budget" scenario. So if it was made for budget scenarios, - don't use expensive SDXC cards.

And also, I don't think specifying a FS in their spec is "poor" engineering. it was clearly made for optimizing/simplifying internal controller tasks. Relying on the fact, that there is a specified FS formatted layout, it might do things better - faster, protect flash array against wear etc. SD cards are made for placing there pics and vids, why should they care about weirdos wanting there ext4 or anything else? any normal commercial OS, would format a card the standardized way. So your point about users, not reading the spec and formatting what they want is moot. if that user was "smart" enough to format it into ext4 or NTFS, BUT failed to look in the spec, then it's him, who is to blame and not "stupid" engineers. I see only one stupid in this nonsense argument, buttah I promised ignoring him.

linguofreak wrote:Whatever your actual feelings, immediately calling him a liar does not communicate "not angry".

You've just assumed that, and you have assumed it wrong. I replied with that because I have empirical proof, rock-solid evidence that what he says is false and he's just trying to derail (yet another) topic.

linguofreak wrote:It is possible for two standards (e.g, UEFI and SDXC) to conflict, so that there is no standards-compliant way to deal with things when both are applicable to a situation.

See? You admit that too. UEFI does not support exFAT. And by the way, the SDXC standard does not say anywhere cards must be exFAT formatted, and zaval is the only person in the entire globe who is unable use other file systems on SDXC cards. Even his pal kzinti couldn't produce a bootable UEFI image with exFAT, no matter how hard he tried, he ended up using a plain simple FAT32 partition.

Now that we have discussed that (with you too), let's focus on ARM SystemReady. Estimates when it will became available? What do you think, what manufacturers will adopt that standard?

Cheers,
bzt

bzt wrote:

linguofreak wrote:It is possible for two standards (e.g, UEFI and SDXC) to conflict, so that there is no standards-compliant way to deal with things when both are applicable to a situation.

See? You admit that too. UEFI does not support exFAT. And by the way, the SDXC standard does not say anywhere cards must be exFAT formatted, and zaval is the only person in the entire globe who is unable use other file systems on SDXC cards. Even his pal kzinti couldn't produce a bootable UEFI image with exFAT, no matter how hard he tried, he ended up using a plain simple FAT32 partition.

I've run across the information that the SDXC standard requires exFAT from other sources than zaval, and have also run across SD cards below the SDXC size range that misbehave when you try to partition them (rather than leaving them as flat FAT32), so I can well believe that there are SDXC cards that misbehave when formatted to anything other than flat exFAT. But *most* cards I've run across take being partitioned just fine, and as I've said, I believe that a card without FAT acceleration hardware that ships with FAT-whatever is the sanest way to implement the standard, and regard any card that cannot be arbitrarily formatted by the user (as most can) as subpar.

Has anybody heard of anything about U-Boot providing a firmware interface? It certainly can run on UEFI, but I can't find in the source where it provides the UEFI interfaces (as suggested by the EBBR)? It looks to me it's just using UEFI, not providing it, which means you'll need Tianocore too on IoT devices (unacceptable bloat for small sensors)...

Cheers,
bzt

I think the issue is that IoT is not well defined. For example, there is also a Ubuntu distribution "for IoT". You are right that Tianocore cannot run on small MCUs but people seem to use the term "IoT" for all kinds of embedded devices, from MCUs to more powerful SoCs in TVs or cars.

Has anybody heard of anything about U-Boot providing a firmware interface? It certainly can run on UEFI, but I can't find in the source where it provides the UEFI interfaces (as suggested by the EBBR)? It looks to me it's just using UEFI, not providing it, which means you'll need Tianocore too on IoT devices (unacceptable bloat for small sensors)...

funny, I mentioned using uboot's UEFI a lot here, even posted links to videos, showing runs on such machines. I'll leave finding the UEFI pieces in its code for your excersice, just say, that it does provide UEFI to some degree. It's maybe not full yet, but, honestly, it's pretty capable and certainly usable. It does even provide some Boot Manager functionality. Namely, it does support BootOrder, BootXXXX variables and processes them correctly. I've been able to create programmatically a Load Option for my OS even on a RISCV64 machine! what I also mentioned about.

again, maybe could be useful, the vids are lame, but they at least give some insight about what one should do to start a UEFI loader with uboot manually on a real machine.

1: this is the run on the most supported RK3399 SoC, Rock Pi 4B, in this case. Even GOP is shining. RPi sucks balls compared to this beast, btw.
2: some exotics - qemu's virt machine on RV64! with UEFI capable uboot as FW.

I didn't make video with the Load Option creation and when the loader is started through it, the latter would be the same as in the above vids, just it would get started automatically, instead of manual typing the fatload and bootefi sequence.
Because I don't have any installer yet, and I needed the code path in the loader to be tested, with the installed OS scenario, I created a UEFI app, that simulated the OS installation by creating a proper UEFI Load Option for the OS instance. It interacted with the user asking it to pick a volume (drive) for the loader and for the OS, among those, it found. currently, only SFSP capable (FAT) ones are enumerated, but later, the same could be done for non-FAT, for the OS (via enumerating the Block/Disk IO handles). then, it created the Load Option and saved the volumes' UEFI device paths into its descriptor for both both the loader Home Volume and OS Boot Volume in FilePathList[0] and FilePathList[1] resp. now loader can be tested for both pre installation run and normal, post installation one. setting these variables and figuring out the devices, getting user input and overall process worked as a charm with edk2 (ovmf) on VBox and qemu, for x64, x86, arm and arm64, but I didn't expect it would work with uboot on RV64. but it did! so, you can use Console Output, even GOP in some cases, Console Input, SFSP, this, btw, is available even for the freaking ext4 volumes! here comes extensibility of UEFI; it lets you set BootOrder and BootXXXX variables, what concludes, it's definitely an impressive minimal set of functionality, more than enough for an OS development enthusiast to rely upon in his/her UEFI OSL affair.

The ARM ecosystem has absolutely zero platform standardization. It's like going back to the times before the IBM PC was invented.

For every ARM system you have to manually craft a device-tree for the Linux Kernel and a customized boot loader is required. Also hardware support by SOC vendors is abysmal.

Unless there is going to be a cross-vendor initiative for a standardized platform that can replace features like UEFI and ACPI, I really hope ARM is going nowhere - we have this mess with smartphones already.

For x86 I can still install a modern Linux Kernel on a Pentium Pro computer from 1995 if I would like to. ARM however, is currently only suited for systems that you expect throw away after a few years.