UEFI Boot Support Published For RISC-V On Linux

[phoronix]

Phoronix: UEFI Boot Support Published For RISC-V On Linux

As we've been expecting to happen with the Linux EFI code being cleaned up before the introduction of a new architecture, the RISC-V patches have been posted for bringing up UEFI boot support...

http://www.phoronix.com/scan.php?page=news_item&px=UEFI-RISC-V-Linux-Patches

[starshipeleven]

u-boot EFI implementation is master race in UEFI land. A tiny fraction of the multi-MB monsters of board firmwares used in x86 boards.

[andreano]

Does this mean that RISC-V is going to be great at booting (as in not require custom distros), unlike ARM?

At the current adoption rate of SBSA/SBBR among ARM boards, I would be unsurprised if the RISC-V ecosystem surpasses them.

[AndyChow]

Wouldn't it be funny/strange if Western Digital eventually became primarily a cpu fabless company? Could happen.

Does this mean that RISC-V is going to be great at booting (as in not require custom distros), unlike ARM?

At the current adoption rate of SBSA/SBBR among ARM boards, I would be unsurprised if the RISC-V ecosystem surpasses them.

I sure hope so. Let's get a real bios which can load a kernel, not an obscure bios only accessible through uart or spi, which loads a kernel which loads the real kernel.

[Adarion]

Goddamit, I wish people would stop bringing this bloated, insecure, backdoored, flawed, failure-by-designed UEFI crap now even to other architectures.
Can't they just follow some KISS approach?

[SystemCrasher]

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.

[danboid]

What systemcrasher said with the added lack of suitability for RAID arrays inherent in UEFI. It's a poorly thought out standard.

I'd like to see RISC-V (and ARM) kept UEFI free.

[starshipeleven]

Goddamit, I wish people would stop bringing this bloated, insecure, backdoored, flawed, failure-by-designed UEFI crap now even to other architectures.

This is not a full UEFI firmware, it is u-boot's minimal efi specification for booting, it is lean, mean and opensource

[starshipeleven]

UEFI is CRAP.

This is not a full UEFI firmware, it is u-boot's minimal efi specification for booting, it is lean, mean and opensource


read the fucking article goddamnit

[SystemCrasher]

Its still efi specification. And so, it uses PE EXEs and so on. That's what this CRAP mandates. So to create EFI things you generally have to deal with PE EXEs. Pretty much inconvenient requirement under Linux, eh? Oh sure, wintel always ensures everyone who is !MS and !intel 2nd-class citizens. The problem is: there is no even windows for RISCV, so this idiocy goes a bit too far.

Sure, Linux kernel gets it done without special toolchain - by coding whole damned PE header in assembly or so and downgrading it to mere stub. But it not going to work for arbitrary use cases (unless you're dead serious about repeating same kind of black magic linux kernel stub does). And, if nobody gives crap about arbitrary use cases, it far more logical to use something less perverted, overengineered and wintel-designed. Otherwise, at some point you'll suddenly notice it is pain to develop targeting these specs using Linux. Because you have to emit PE EXEs. Turn on your brain, dammit.

Hope it gives some idea why I think EFI specs are actively hostile to using Linux - and especially using it as development platform! Yes, you can build uboot using your usual "system" toolchain, that also builds you kernel or even apps. Now good luck to build PE EXE EFI module like that, without doing quite an unorthodox linker and asm trickery...