Originally posted by danboid
View Post
Announcement
Collapse
No announcement yet.
UEFI Boot Support Published For RISC-V On Linux
Collapse
X
-
Originally posted by SystemCrasher View PostUEFI 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.
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
- Likes 1
Comment
-
Originally posted by phuclv View PostCan you provide decent ext4 or NTFS support in such a small space?
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.
- Likes 1
Comment
-
Originally posted by SystemCrasher View PostUEFI 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.Last edited by techzilla; 09 March 2020, 04:19 PM.
Comment
-
Originally posted by starshipeleven View PostMost 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.
Comment
-
Originally posted by phuclv View Postthe 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.
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
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/# )
Comment
-
Originally posted by phuclv View PostIt'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.
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.
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:
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, sorryLast edited by SystemCrasher; 28 March 2020, 12:50 PM.
Comment
-
Originally posted by SystemCrasher View PostSo 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.
Originally posted by SystemCrasher View PostOn 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.
Comment
-
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
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.
Comment
Comment