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