UEFI Boot Support Published For RISC-V On Linux

[starshipeleven]

What systemcrasher said with the added lack of suitability for RAID arrays inherent in UEFI.

UEFI can boot fine from a EFI partition made with mdadm RAID1 and metadata 0.9

[starshipeleven]

Its still efi specification. And so, it uses PE EXEs and so on.

It's a header yo

[phuclv]

UEFI is CRAP. This thing has been designed by WINTEL in their private manors, without giving crap about anything but Windows and x86. It goes as bad as demanding separate FAT32 partition (what a bullshit bingo!) and using PE EXE files from Windows, fairly uncommon in Linux world.

It's not FAT32. FAT16 is also allowed and most Linux distros actually create FAT16 by default. There's no need for any fancy file system for such a tiny partition with just a few files. Besides the driver is simple enough to be embedded in the firmware. Can you provide decent ext4 or NTFS support in such a small space? Having a separate boot partition is a good thing because there are all sorts of issues that could happen with the use of hidden sectors in MBR. Some old boot loaders like LILO, DOS and grub in some configs even have to hardcode the sector number because they don't understand file systems with only 1 or 2 small stages, and that way they easily break after each update

And for the reason why PE is used:

a note on p.18, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."

https://en.wikipedia.org/wiki/Portab...ble#cite_ref-2

[starshipeleven]

Can you provide decent ext4 or NTFS support in such a small space?

Most motherboards have 8MB or bigger (usually much bigger, 64 or 128 MB aren't uncommon) SPI chips for the board firmware. I can literally fit a whole Linux embedded firmware in there (OpenWrt) with access to all common Linux filesystems in there.

If you only need boot from that filesystem (i.e. read-only support is enough) you can get away with much less https://efi.akeo.ie/ or even the filesystem support of uboot (that usually fits the whole bootloader and stuff in 128k of flash with room to spare).

Also there are commercial EFI drivers that add NTFS support, and they aren't particularly big either.

Then again, Fat16/32 is fine for me, I'm just pointing out flaws in your logic.

[techzilla]

UEFI is CRAP. This thing has been designed by WINTEL in their private manors, without giving crap about anything but Windows and x86. It goes as bad as demanding separate FAT32 partition (what a bullshit bingo!) and using PE EXE files from Windows, fairly uncommon in Linux world. Needless to say, it quite hostile in terms of developing this crap from Linux. Well, "typical" Linux toolchains aren't meant to generate PE crap - so it at very least warrants one some weird custom toolchain, isn't it?! Because in Linux we normally using ELF files - and it would be default output format of all toolchains around. EFI being evil enough to demand separate toolchain.

Well, some few things like uboot or kernel got around of it by using custom hacks. But these only cover bare minimum stubs and so on! However, attempt to develop any EFI extenstion (well, it "extensible", after all) would immediately bring issue back on board anyway, isn't it? So, how about "extensible" firmware, where attempts to "extend" it using Linux is pain? Doesn't it imply this code is going to be virtually readonly for you, you Linux nuts?

How about something else, where Linux would be first-class citizen, from scratch? I'm sorry to inform you but firmware mandating FAT32 and PE EXEs looks really hostile to Linux. And especially to firmware components development using Linux.

You are hostile to empowering us everyday plebeians, freedom for Google and Apple only. I don't buy anything with a non-standard boot any longer, and nobody should. Your magical "UEFI" alternatives don't exist, and that is why you support them, you oppose simply to prevent users from supporting themselves on their own hardware. You'll say literally anything, as long as it ensures everyday user can't engineer their own technology.

You don't like that the UEFI spec calls for PE? What are you writing that is impact by that choice, what entitles you to keep us all chained to device OEMS? Why should anyone even listen to your personality disordered expressions of totalizing hatred? What a load of nonsense, Windows doesn't need any help these days, and x86 is entrenched because we lack a market acceptable standardized boot platform. ARM commissioned studies, at great expense, proving this is the largest reason for ARM failing to penetrate the data center. Not that anyone with a couple brain cells couldn't figure out, after looking at their drawer of past SOCs. What interest are you defending, how do you benefit from us throwing out our devices every year?

Linux setting the hardware platform you say? You mean like the Chromebook? Or the Android phone? Or any other platform that always seems to lack the one thing the ARM studies says is absolutely necessary for users. Apple doesn't allow others to sell hardware, but they used UEFI for themselves of course. They can be empowered, just not any of us. If you think MS is your largest problem in 2020, you're a liar that hates everyone as much as you hate yourself.

UEFI is separate so that we don't need to hack the boot process for each specific motherboard, it liberates all of us from unnecessary engineering Google pays an army to do for them. Your problems are less serious than all of ours, says ARM Holdings, and my junk drawer of unused boards. I argue that your problems are just expressions of self-hatred, I don't even think you actually benefit from whatever your doing here, you just enjoy oppressing others.

[phuclv]

Most motherboards have 8MB or bigger (usually much bigger, 64 or 128 MB aren't uncommon) SPI chips for the board firmware. I can literally fit a whole Linux embedded firmware in there (OpenWrt) with access to all common Linux filesystems in there.

If you only need boot from that filesystem (i.e. read-only support is enough) you can get away with much less https://efi.akeo.ie/ or even the filesystem support of uboot (that usually fits the whole bootloader and stuff in 128k of flash with room to spare).

Also there are commercial EFI drivers that add NTFS support, and they aren't particularly big either.

Then again, Fat16/32 is fine for me, I'm just pointing out flaws in your logic.

the UEFI doesn't require a board to contain such a huge ROM. It's for everyone to use so it must also work on boards with tiny firmware. Are you sure there are UEFI with built-in NTFS support? I've never even seen one that supports exFAT

[starshipeleven]

the UEFI doesn't require a board to contain such a huge ROM.

The specification does not talk about sizes, but the actual UEFI firmwares for x86 for sure are big and bloated so yes they need that space. The same system with Coreboot or even Linuxboot takes less than 1/4 of the space, and having so much available space is one of the reason Linuxboot was even designed (where you basically use a Linux kernel as a bootloader).

It's for everyone to use so it must also work on boards with tiny firmware.

Yes and no. If we are talking of UEFI boot interfaces yes it's tiny and even u-boot bootloader can do that without growing beyond the usual 128k (or 256k). Afaik uboot only does this from FAT partitions and can't load UEFI filesystem drivers.

But UEFI also to provides APIs for UEFI-native applications, modules and drivers, which means you now have some baggage. And of course since there is all this API you need to factor in all the "value-added" software that is integrated in it by the UEFI firmware vendor to offer more features in their own SDK so that the OEM will chose them over others (American Megatrends, Insyde and others exist and have their own different UEFI firmware SDK, hardware brands like Asus, HP, Dell and others buy the SDK from these companies instead of developing the firmware from scratch)

Also there is the fact that in many cases it's cheaper to get bigger flash chips anyway because of economies of scale, and the fact that lower-capacity chips are not manufactured at high volumes (or at all) anymore.

Are you sure there are UEFI with built-in NTFS support? I've never even seen one that supports exFAT

I didn't say I've seen them or that it makes sense to have them at all, I said that such drivers exist.
UEFI has a driver interface and just as there are opensource UEFI drivers (that are extracted from GRUB codebase) there are proprietary UEFI drivers from the usual suspects (Paragon for example https://www.paragon-software.com/tec...ink-business/# )

[SystemCrasher]

It's not FAT32. FAT16 is also allowed and most Linux distros actually create FAT16 by default. There's no need for any fancy file system for such a tiny partition with just a few files.

I would basically agree, BUT once again, this spec made MS unjust favor, quoting something they have already implemented. Reminds OOXML story, where MS basically did a feeble attempt to document their actual Office implementation and call it "standard". Ending up with 6000 pages monster full of bugs, inconsistencies and odds, to extent MSOffice miserably failed very basic testcases when people actually attempted to generate files using OOXML specs. I'd say such way of doing things sucks a lot.

Do you need small, simple, nice filesystem? Ok, how about creating working group, gathering specs from all interested parties and designing one in team play, the way best fit for task and so EVERYONE implementing it, to ensure equal starting conditions instead of wintel almost-monopoly making favors to self once more? That clearly came to point where anti-trust agencies should kick in and do what they are supposed to - to ensure fair competition, the way it meant to be.

Besides the driver is simple enough to be embedded in the firmware.

OTOH it doesn't really addresses plenty of modern-day usecases and scenarios, ranging from lack of integrity/redundancy to survive somewhat flakey storages (like cheap flash based things) to e.g. no any compression, not even simplest one, and therefore slower boot times if storage proves to be slow, etc.

Can you provide decent ext4 or NTFS support in such a small space?

UBoot reads ext4 (and maybe even writes to it). Grub does even ZFS and btrfs. So cool story, but I'd say, they don't mind soldering 16MB flash ROM with full fledged GUI, more than enough to boot e.g. whole full Linux like openwrt, not just boot loader, and then someone moans about drivers size. That's what called double standards.

Having a separate boot partition is a good thing because there are all sorts of issues that could happen with the use of hidden sectors in MBR. Some old boot loaders like LILO, DOS and grub in some configs even have to hardcode the sector number because they don't understand file systems with only 1 or 2 small stages, and that way they easily break after each update

On other hand, old boot approach had very little assumption about filesystems and so on - that's what I really like about it. That's how masterpiece of engineering happens - it proven to be extremely future proof.

And for the reason why PE is used:

Most hilarious bullshit I ever read. This alone implies some weird technical restrictions on CPU and then plenty of cruft to deal with such a strange situation, to begin with. Say, "MCU like" things can do thumb2 - and physically incapable of doing full ARM mode. Some of these even run Linux. But sure, they do not run Windows, so wintel gives no crap about stuff like that, let these Linux nuts go to their ghetto and struggle with their problems on their own.

And no, PE isn't "just header". Its executable format. The fact Linux kernel put quick-n-dirty hack to mimic it doesn't imply you can easily repeat this trick with e.g. drivers/runtime services/shells/modules under Linux. You basically would need custom PE toolchain to develop all that - which isn't anyhow native to Linux. So your system compiler can e.g. build grub, or something. But it would fail to build UEFI things. PE native to Windows and VS, its real reason. Everything else is pretty lame excuse. At which point Linux clearly put at second-class citizen. Esp from dev point of view.

p.s. techzilla, you should rename into consumerzilla, that would be far more true statement, sorry

[phuclv]

So cool story, but I'd say, they don't mind soldering 16MB flash ROM with full fledged GUI, more than enough to boot e.g. whole full Linux like openwrt, not just boot loader, and then someone moans about drivers size. That's what called double standards.

How many actual UEFI implementations do have real GUI? Among all that I've been able to access probably just 1/10 have a GUI with mouse, others are just simple TUI with unintuitive UX

On other hand, old boot approach had very little assumption about filesystems and so on - that's what I really like about it. That's how masterpiece of engineering happens - it proven to be extremely future proof.

the simplicity is what makes them fragile. In reality it has a big assumption about the partition that they are aligned to 1MB or so to embed the intra stage if they don't want to hardcode the numbers

[SystemCrasher]

Well, I never measured percentage, but I've seen GUI-based UEFIs in PCs. Which are nearly full blown OSes to put it straight. Whatever, E in EFI stands for Extensible. And that "extensible" part happens as PE EXE modules. Which are inconvenient to develop under Linux - so Linux devs are at inherent disadvantage. And if we aren't going to "extend" it anyway, I guess it can be drastically simplified by orders of magnitude, resulting in far more trustworthy code.

the simplicity is what makes them fragile. In reality it has a big assumption about the partition that they are aligned to 1MB or so to embed the intra stage if they don't want to hardcode the numbers

I have very opposite system-level experience: the more complicated some thing is, the more failure points it brings and the harder it to foresee all possible failure modes. When one needs e.g. some mission-critical systems it quite a problem. On PCs, (U)EFI things manage to fail boot sequence for pretty arcane reasons, say, press key on keyboard at "wrong" time - and whole computer hangs, refusing to boot at all.

Still, oldschool PC boot not just can boot out of nearly any filesystem, it can even co-exist with e.g. some ARM boot sequences, etc.