For the last time.
Quote:
Not by far, he's not claiming that! He said that 1) SDA specification does require using only exFAT for SDXC cards (according to the SDA spec as he claims
It does. Read it.
Quote:
refusing to read section 5.3.2 CSD Register, bits FILE_FORMAT_GRP and FILE_FORMAT bits.),
I did read that section. For the 3rd time - under the table, describing FILE_FORMAT bits, it says "A more detailed description is given in the File System Specification". Go and read through it. And you'll see, that that part 2 of the spec clearly standardizes, that only MBR scheme is used (no partitionless layout allowed as well) and only one FAT FS formatted volume, with further requirements to its paramaters. Those (write once, btw) bits thus have only one correct value, after formatting the card - 0.0, "Hard disk-like file system with partition table". And it is exactly that "more detailed description" for those bits, which you don't want to see, because then you must admit - your were not a genius with this argument, but a stubborn, arrogant clown. Here is an excerpt for SDSC cards for example:
Quote:
3. FAT12/FAT16 File System
3.1. Volume Structure
The volume structure of the Standard Capacity SD Memory Card, whose capacity is 2GB or less, is
specified in this section. It defines the logical structure of the Data Area. For the identification of the
Data Area as a partition, the first sector has Master Boot Record and Partition Table. And the Standard
Capacity SD Memory Card uses the FAT file system (ISO/IEC 9293) and supports both FAT12 and
FAT16 as the file system type.
And for the exFAT:
Quote:
5. exFAT File System
5.1. Volume Structure
The volume structure of the Extended Capacity SD Memory Card is specified in this section. For the
identification of the Data Area as a partition, Master Boot Record and Partition Table exist in the first
sector of the card as well as the Standard Capacity SD Memory Card. The exFAT file system shall be
applied to the Extended Capacity SD Memory Card.
Also, further specifications follow - only 1 record in the Partition Table e.g. meaning no multiple volumes on cards and other parameters' specification.
Quote:
but he also said that if a machine has only SD card as its storage, then it would be MBR (obviously contradicting his first claim)
What exactly I contradicted? SDA wants MBR partitioned scheme and FAT FSs. See the quotes above. Where tf is contradiction? To what? Your delusional perceptions?
Quote:
furthermore that an OSL can be loaded without an ESP,
Absolutely can! Just try it by yourself. I showed you screenshots, I showed videos. How can I show to you it works yet?
Quote:
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 (translation: "not having ESP" = "without any FAT partition"),
Quote:
Doesn't demand. Not even having ESP. It works. Try by yourself. But this one is interesting: "(translation: "not having ESP" = "without any FAT partition")" What? Your "translation" sucks as your understanding the UEFI or your BOOTBOOT. Didn't you know, that a FAT FS can be an ordinary FAT, not marked as ESP neither in MBR nor in GPT? Surprise!
and that he has many tests for this. It is only logical to ask to share with one of those "many" tests with us, a disk image that fulfills all of these criteria, because I'm pretty sure it doesn't exists but I would like to see zaval to prove me wrong so that I can learn something new. If he can't provide such an image, all he is doing is cheap talk. No offense, that's what it is without an evidence.
You have hung here, right? What the evidence you want? I have shown you several months ago. Not convincing? Then do it yourself. Create a vhd, partition it with MBR, create a FAT there, non ESP, create a folder "bztsucksballs" and put there your bootboot cr4p. then launch it via UEFI shell or through UEFI Boot Manager and will run. I did this with my OSL on an x86 laptop, several ARM SBCs, x64 qemu and VBox VMs and aarch32 and aarch64 qemu VMs. Do it yourself.
nullplan wrote:
Why the phrase "never use the other file system" rather than "never use another file system"? It puts in my mind an image of a redneck in a bar telling me "we're tolerant, we have both kinds of music: Country and western." Even just that sections mentions more than two FSes, so I don't really get it. It could be construed to mean "if a FAT variant is used, then SCSD cards must use FAT12/FAT16, HCSD cards must use FAT32, and XCSD cards must use exFAT". Is that what this section is supposed to mean?
I quoted above, the beginnings of the chapters for the SDSC and SDXC cards, they tell straight what FS shall be used. Here is the start of chapter 2, where again they claim what they see as compatible. There is no a single line in the spec of a kind: "if other FSs are used" or "other FSs can be used" etc. Like it or not, but this is how they standardize their technology. I'm ok with this, I see, why they did so - SD cards are removable storages and FAT FS there are the best fit for many reasons.
Quote:
2. Features
- Compatibility with FAT File System
- Standard Capacity SD Memory Card complies with ISO/IEC 9293 (FAT12 /FAT16).
- High Capacity SD Memory Card complies with FAT32 File System.
- Extended Capacity SD Memory Card complies with exFAT File System.
- CHS parameter recommendation
- Cluster size recommendation
- Boundary Unit recommendation for User Data area alignment
- Long File Name support (Optional for FAT12/FAT16/FAT32. exFAT supports Long
File Name by default.)
I very dislike the only thing about the bzt obsession around this - he misleads people. Esp. given how hard he is trying to do this. Literally every post of him is an emphasize either like "exFAT is not a requirement for SDXC cards" or that "UEFI demands GPT/ESP", suggesting people format USB sticks/SD cards in GPT... where both are just not needed.
I'm glad ARM is moving to UEFI/ACPI. I told this months ago here. This embracing the standrads will make it easier for us, OS development enthusiast to write our things for the ARM architecture.
As of the bzt's understanding of this move, and consclusions made, it is, as always, a very badly biased trash, not worth attention.
Code:
if(IsBztTalkingAbout("UEFI, GPT, SD card FSs, ARM, exFAT") == TRUE){goto BetterIgnoreThatSh1t;}