OSDev.org

Posted: **Sun Apr 04, 2021 11:15 am**

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

First of all, you don't get to make up the rules as you go along. Second of all, "working" examples are not required for this argument.

zaval claims a card must be using FAT12, FAT16, FAT32, or exFAT. To that end, he cites authority. The authority is a bit wonky, but authoritative. See, here's a thing I don't understand:

That is, all Standard Capacity SD Memory Cards whose capacity is 2048MB or less shall use FAT12 /
FAT16 file system, and never use the other file system. Similarly, all High Capacity SD Memory Cards
shall use FAT32 file system, and never use the other file system. And all Extended Capacity SD Memory
Cards shall use exFAT file system, and never use the other file system. This includes the prohibition of
partial format of SD Memory Card. For example, 8GB High Capacity SD Memory Card should not be
formatted as 2GB card with FAT12 / FAT16 file system. In this case, whole area of 8GB should be
formatted with FAT32 file system.

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?

Anyway, the correct counter to an argument from authority is to either undermine the authority or counter with a stronger authority (e.g. if zaval argued you can never drive faster than 30 kph in your car, citing a contract he has with his neighbor, you can either point out that the neighbor has no jurisdiction over you, undermining the authority, or point out that a law contradicts that, countering with a stronger authority).

In this case, you can't really undermine the authority of the SD Association - defining SD cards is their only job. So you can only counter with a stronger authority. But what do you have? Documentation on two weird bits in some register. I just looked up that documentation, and from the free bits of documentation, it is not clear to me at all that that is about file systems. It could just as well be about partition tables. It says a more detailed explanation is available as part of the FS specification, which I don't have and couldn't find with a quick search. And I refuse to pay money for that drivel.

Also, you have a sentence in a completely different spec, that does not unequivocally say you can use whatever FS you like, but can be possibly construed to mean that.

In short, if that quote above is accurate, and I have no reason to suppose that it isn't, then zaval is right, and no amount of bellyaching and name-calling from you or anyone can change that.

Consequence for me is to just not support SD cards in the short term. If they want to hide their FS behind paywalls, I shall leave them to it. The camera I've used the most in the past five years is my phone, anyway, and I can talk to it just via MTP and leave talking to the internal SD card to the phone itself.

bzt wrote:Nonetheless zaval told obvious lies, getting into contradiction with himself within one post. I've just kindly asked for a PoC.

Where did he lie? What falsehood did he tell? Does the FS spec in fact not contain the above quote? Note that a lie is, by definition, a statement that is false, that the speaker knew to be false at the time the statement was made, and that the speaker told with malicious intent. That is a bit of a hurdle to clear. And if you can't clear it, you just made a false accusation. That's sure to win over hearts and minds.

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

Because calling someone a troll and a liar is in no way insulting. Nor is ignoring evidence in front of you, ignoring argument structure entirely, and - oh yeah, dragging out this bloody conversation over months. Asking for PoC when the argument is that something is not necessarily (but possibly) possible is just nonsense. Not all Nintendo Gameboys survive aerial bombardment, but at least one did. Are you asking for a PoC bombing now?

Posted: **Sun Apr 04, 2021 12:00 pm**

bzt wrote: I'll just skip your posts and ask all forum members to do the same.

I think you can trust people here to be intelligent enough to make their own decisions on which posts to read and which to ignore. Personally, I don't take kindly to being told what to do.

Posted: **Sun Apr 04, 2021 12:01 pm**

nullplan wrote:First of all, you don't get to make up the rules as you go along.

First of all, I didn't "make up the rules as I go along". This has been told many many times (last time here), and it is called "scientific method", first formalized in the 17th century, but ancient Greeks were aware of its importance too. I didn't "made that up". ROTFL. I only wish I could contribute that big to science.

nullplan wrote:Second of all, "working" examples are not required for this argument.

Yes, they would be very much needed to avoid these outbursts from you (in plural). They are called empirical evidence.

nullplan wrote:zaval claims a card must be using FAT12, FAT16, FAT32, or exFAT.

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, refusing to read section 5.3.2 CSD Register, bits FILE_FORMAT_GRP and FILE_FORMAT bits.), 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), furthermore that an OSL can be loaded without an ESP, 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"), 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.

nullplan wrote:Because calling someone a troll and a liar is in no way insulting.

How come that it did not bothered you when zaval used lot worse phrases on me? In multiple posts, may I add. How isn't that bothering you? I did call him a troll for a good reason after his many many off-topic and questionable posts all full of inadequate language (which, BTW per definition makes him a troll, and not because I said so).

nullplan wrote:Nor is ignoring evidence in front of you

Excuse me? What evidence? You said it yourself, there are no "working examples". Zaval has not shown anything, but ignored all the specification citations, that's the root of the problem. Have you missed that part? There would be no problem if zaval wouldn't be off-topic and unpolite, or would just simply share one of his allegedly many tests with us.

And how about instead of derailing the topic, we would discuss ARM SystemReady?

Cheers,
bzt

Posted: **Sun Apr 04, 2021 12:09 pm**

iansjack wrote:I think you can trust people here to be intelligent enough

Sadly the few posts above proves the opposite. Which is pretty sad. Something is very fundamentally wrong with the world when scientific method is questioned.

iansjack wrote:Personally, I don't take kindly to being told what to do.

That makes two of us. I don't take kindly when someone distracting my topic with obvious lies, calling me names, and someone else trying to paint me as the bad guy because of him. Specially when this isn't the first time. I'll always raise my voice against trolling and attempted bullying, "you eat what you cook" as they say.

Cheers,
bzt

Posted: **Sun Apr 04, 2021 1:06 pm**

I was tempted to write a long, rambly, response, but that doesn't really solve anything. bzt, you have not addressed the claim that SD cards must be FAT formatted. That claim is evidenced, and the counter-evidence does not convince me. I would quote it here, but it contains a table, and I can't recreate those in phpBB. Again, the documentation for those bits you cited could just as well be about partition tables. And it does not say you can definitely format the card with whatever FS you choose, it could at most be construed to mean that.

As for those UEFI claims: You'll hear no argument from me about that. It does sound rather daft to suggest you can get by without an ESP.

bzt wrote:And how about instead of derailing the topic, we would discuss ARM SystemReady?

Yes, we probably ought to have created a different thread for this. However, this discussion between the two of you has spanned multiple threads now, it pops up whenever either of you starts talking about SD cards, and it just gets tiresome.

...is what I was about to post, and then I get to read this:

bzt wrote:Sadly the few posts above proves the opposite. Which is pretty sad. Something is very fundamentally wrong with the world when scientific method is questioned.

Oh, get over yourself! You misunderstanding some specification is not scientific. You stopping to respond to arguments when you no longer have a fitting answer (but never explicitly conceding) is not scientific. You insulting everyone who fails to share your opinion, as above, is not scientific. You are not being scientific!

Science is when you consider all the evidence. Not just the evidence that suits you. Science is when you form a hypothesis and then test it. Not proclaim the Revealed Truth from the rooftops and institutionalize everyone who disagrees.

Damn, now you made me angry. Not gonna touch this thread again for a while!

Posted: **Sun Apr 04, 2021 4:01 pm**

For the last time.

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.

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:

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:

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.

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?

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?

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

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: Select all

if(IsBztTalkingAbout("UEFI, GPT, SD card FSs, ARM, exFAT") == TRUE){goto BetterIgnoreThatSh1t;}

Posted: **Sun Apr 04, 2021 4:45 pm**

I just installed UEFI on my Raspberry Pi 3 and it boots just fine using a single FAT32 partition with MBR. No GPT or ESP anywhere. It just works.

Posted: **Sun Apr 04, 2021 4:51 pm**

nullplan wrote:bzt, you have not addressed the claim that SD cards must be FAT formatted. That claim is evidenced, and the counter-evidence does not convince me.

Heh? Evidenced, how? There's no evidence that SD cards can only contain a single FAT file system and nothing else, as a matter of fact all the evidence says otherwise. Even @zaval wrote that it should have an MBR partitioning table (contradicting his previous claim). Just download the latest RaspiOS image, and see it yourself if you can write it on an SDXC card and use the ext4 partition on it or not.

nullplan wrote:And it does not say you can definitely format the card with whatever FS you choose

What does FILE_FORMAT = 3 ("Other/Unknown") mean then? And if we use FILE_FORMAT = 0 (partitioned) where does the spec say that there can be only one partition in that partitioning table and that must be exFAT? I can't see that anywhere in the spec, could you please cite that part? Seriously, if the SD specification says that there can be only one exFAT partition, I really would like to see that.

nullplan wrote:Yes, we probably ought to have created a different thread for this. However, this discussion between the two of you has spanned multiple threads now, it pops up whenever either of you starts talking about SD cards, and it just gets tiresome.

I agree. It is ridiculous how zaval is insisting to something that's not in the spec and empirically proven false and trolling in every post about it.

nullplan wrote:You insulting everyone who fails to share your opinion, as above, is not scientific. You are not being scientific!

It is the other way around, zaval is the one who is insulting everyone who fails to share his opinion (or should I say misbelief). I have no opinion about this, RaspiOS working is a fact, and not my "opinion". (And FYI my opinion is that zaval is deliberately trolling.)

nullplan wrote:Science is when you consider all the evidence. Not just the evidence that suits you.

Exactly. You should not ignore the evidence that RaspiOS image is working for hundred thousand people if not more, and do the test yourself.

Cheers,
bzt

Posted: **Sun Apr 04, 2021 4:54 pm**

kzinti wrote:I just installed UEFI on my Raspberry Pi 3 and it boots just fine using a single FAT32 partition with MBR. No GPT or ESP anywhere. It just works.

Please provide the steps. How did you install UEFI on Raspberry Pi 3? It isn't officially supported, UEFI compatible start.elf doesn't exists.

And who said that a properly formatted MBR partition isn't an ESP? Have you actually read the UEFI specification section 13.3 File System Format? It explicitly says that

13.3 File System Format
The file system supported by the Extensible Firmware Interface is based on the FAT file system. EFI defines a specific version of FAT that is explicitly documented and testable.
...
13.3.1 System Partition
A System Partition is a partition in the conventional sense of a partition on a legacy system. For a hard disk, a partition is a contiguous grouping of sectors on the disk where the starting sector and size are defined by the Master Boot Record (MBR), which resides on LBA 0 (i.e., the first sector of the hard disk) (see Section5.2), or the GUID Partition Table (GPT), which resides on logical block 1 (the second sector of the hard disk) (see Section 5.3.1).
...
13.3.1.1 File System Format
The first block (sector) of a partition contains a data structure called the BIOS Parameter Block (BPB) that defines the type and location of FAT file system on the drive.

Zaval claimed that he can boot an OSL without an ESP, which means without any FAT-like partition.

Cheers,
bzt

Posted: **Sun Apr 04, 2021 5:08 pm**

bzt wrote:Please provide the steps. How did you install UEFI on Raspberry Pi 3? It isn't officially supported.

You demand a lot, yet you provide very little in return. But anyways, since you can't be bothered to Google it yourself, here is what I installed: https://github.com/tianocore/edk2-platf ... rryPi/RPi3. You can find binaries and more detailed instructions here: https://github.com/pftf/RPi3/releases.

bzt wrote:And who said that a properly formatted MBR partition isn't an ESP? Have you actually read the UEFI specification section 13.3.1.1 File System Format? It says that ESP is identified by the BPB.

You are the one who keeps saying you need GPT + ESP. By definition, if you use MBR + FAT32 (type 0x0C), you are not using GPT + ESP.

You don't exactly have a good track record when it comes to reading specs and understanding them. 13.3.1.1 doesn't say anything like that.

Posted: **Sun Apr 04, 2021 5:10 pm**

kzinti wrote:You demand a lot, yet you provide very little in return. But anyways, since you can't be bothered to Google it yourself, here is what I installed: https://github.com/tianocore/edk2-platf ... rryPi/RPi3. You can find binaries and more detailed instructions here: https://github.com/pftf/RPi3/releases.

No, I don't demand a lot. Those aren't official Raspberry firmware (those can be found here), and they don't comply with ARM SystemReady either, not that matters, just saying.

kzinti wrote:You are the one who keeps saying you need a GPT/ESP. But definition, if you use MBR + a normal FAT32 partition (0x0C), you are not using GPT + ESP.

WRONG, yes you are using ESP. I've even quoted the spec.

End of discussion.

Cheers,
bzt

Posted: **Sun Apr 04, 2021 5:19 pm**

bzt wrote:No, I don't demand a lot.

Yes you do, you keep asking for PoCs and for people to prove what they say. Yet everytime you make a claim you do not provide such proofs. When called on it, you deflect and never provide anything. Given this, I fail to see why anyone should provide for any of your "demands".

bzt wrote:WRONG, yes you are using ESP. I've even quoted the spec.

Yeah, you are not going to win any argument or goodwill with this attitude.

I know I am not using an ESP because I partitioned and formatted the card myself. I used MBR and a FAT32 partition (type 0x0C) that covers the whole card. What's more, if you had even bothered to read the links I posted, they tell you that the Rpi3 UEFI implementation doesn't even work with an ESP:

https://github.com/pftf/RPi3 wrote:Note: Do not try to use GPT for the partition scheme or 0xef (EFI System Partition) for the type, as these are unsupported by the CPU-embedded bootloader.

bzt wrote:End of discussion.

You don't get to decide that. But you can stop anytime you want. Your last reply is kinda pathetic, you know?

bzt wrote:Cheers,

Have a nice day.

Posted: **Sun Apr 04, 2021 5:25 pm**

Zaval claimed that he can boot an OSL without an ESP, which means without any FAT-like partition.

hehe, bzt, it's a poor play of you. Some time ago, you (wrongly) stated, that UEFI has an independent (from the MS specification), different FAT FS, but now, you "can't" see even the difference between an ESP and non-ESP FAT FS. But there are differences. A FAT volume is only then ESP, when 1) marked as ESP in either MBR Partition Table

5.2.2 OS Types
Unique types defined by this specification (other values are not defined by this specification):
0xEF (i.e., UEFI System Partition) defines a UEFI system partition.

or GPT Partition Array:

Table 19. Defined GPT Partition Entry - Partition Type GUIDs
Description GUID Value
Unused Entry 00000000-0000-0000-0000-000000000000
EFI System Partition C12A7328-F81F-11D2-BA4B-00A0C93EC93B
Partition containing a legacy MBR 024DEE41-33E7-11D3-9D69-0008C781F39F

That is the exact, ultimate difference. hence, for example an OS treats ESP and non ESP differently. And 2), there are slight additional rectifications in the UEFI about ESP FAT, mainly this one:

Note: Although the FAT32 specification allows file names to be encoded using UTF-16, this
specification only recognizes the UCS-2 subset for the purposes of sorting or collation.

And that long names are always supported.

So, "zaval" couldn't claim what you say, and if your read my answers, you would see that, I several times repeated to you "create a vhd, with MBR, put an "ordinary" non-ESP FAT volume ... " in response to your requests for showing UEFI, not demanding GPT/ESP.

WRONG, yes you are using ESP. I've even quoted the spec.

LOL. In a conclusion, bzt, you have shown here, yet once, - you as badly don't know the UEFI spec as furiously try to prove your misunderstanding. Go read it, enough this shame. You pulled off the quote, telling the system partition is a partition in a common sense, but forgot, that UEFI defines a special type for both MBR and GPT schemes for ESP. don't be ridiculous, really.

Posted: **Sun Apr 04, 2021 5:26 pm**

kzinti wrote:
bzt wrote:WRONG, yes you are using ESP. I've even quoted the spec.
Yeah, you are not going to win any argument or goodwill with this attitude.

Excuse me, what attitude? I've just stated a fact. And I don't need to win anything, what did you think?

kzinti wrote:I know I am not using an ESP because I partitioned and formatted the card myself. I used MBR and a FAT32 partition (type 0x0C) that covers the whole card.

Let's just agree on you have no clue what an ESP is. And just for the fun of it, can you enlighten me, where is the exFAT file system in your set up? I can't see it anywhere.

kzinti wrote:You don't get to decide that.

Yes, I do. ;P Furthermore I can and I did report zaval's last post since he's obviously trolling with an improper attitude stating lies.

Cheers,
bzt

Posted: **Sun Apr 04, 2021 5:41 pm**

What does FILE_FORMAT = 3 ("Other/Unknown") mean then?

It means "other/unknown". And it shouldn't be used as it's not specified. It's UB. Good luck using a card, screwed up this way.

And if we use FILE_FORMAT = 0 (partitioned) where does the spec say that there can be only one partition in that partitioning table and that must be exFAT? I can't see that anywhere in the spec, could you please cite that part? Seriously, if the SD specification says that there can be only one exFAT partition, I really would like to see that.

In the part 2 of the specification. I quoted some above, you better read the whole thing alone.

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.

...

Code: Select all

5.1.3. Arrangement of the Partition Area
BP Length
(bytes) Field Name Contents
0 446 Master Boot Record Not Restricted
446 16 Partition Table (partition1) Refer to Table 5-2
462 16 Partition Table (partition2) All 00h
478 16 Partition Table (partition3) All 00h
494 16 Partition Table (partition4) All 00h
510 2 Signature Word 55h, AAh

Not enough? Then read the spec by yourself, your clowning is getting over bearable.

OSDev.org

ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot

Re: ARM about to standardize boot