segfault

@segfault@lemmy.world
0 Post – 4 Comments
Joined 1 years ago

Currently, BIOS/UEFI is largely under proprietary control

This is incorrect.

The UEFI Forum makes specifications freely available at no cost at https://uefi.org/specifications, and membership is free which would then allow you to redistribute and otherwise use the specs. There are many "open specifications" that require either a one-time purchase of a single specification or a subscription for continued access to a set of specifications, that you of course then cannot share. (PCI-SIG requires a company subscription at $4000 a year to access PCIe related specs.)

edk2, the reference implementation used on everything with UEFI, is open source (BSD-2-Clause-Patent) and available on GitHub: https://github.com/tianocore/edk2.

The problem is not that it's under proprietary control, it's that every fucking company forks edk2 into proprietary products because the license allows it (because Intel required it).

  • Most ODMs/IBVs/OEMs are not willing to make their garbage "value-add" components available, let alone source code for them.
  • Many companies are not willing or unable to make available any required datasheets or provide source code for Platform Initialization (such as NDAs for 3rd party components).
  • Intel has not only gone back on its word about making more the FSP open source (FSP also uses edk2), they are trying to take control even more by shoving increasingly more shit into the FSP.
13 more...

coreboot isn't a UEFI implementation. It is comparable to the UEFI SEC+PEI phases. It then hands off control to a payload. If you want UEFI, that's going to still be edk2.

1 more...

All UEFI system firmware uses edk2. It's not just the reference implementation; Pragmatically, it's the only implementation. Independent BIOS vendors (IBVs) like AMI, Phoenix, and Insyde have built all their tooling for and around edk2. Companies like System76 and Purism use it as a UEFI payload for their coreboot based firmware.

Check with powertop that runtime power manage is enabled for devices (tunables are "Good").

It looks like it has a RTL8111H for Ethernet, which is known to be problematic with sleep. My machines don't go below C3 due runtime power management being disabled for Ethernet, but enabling it causes it to fail to come out of suspend correctly.