Get Rid of Legacy SeaBIOS ROMs.

[mrchromebox]

Get Rid of Legacy SeaBIOS ROMs.

[reynhout]

Please keep in mind that removing legacy support from full firmware would effectively break the upgrade path for tens of thousands of existing users.

A migration script would help mitigate the pain, but it would still create a significant support load with ambiguous benefit to the user.

If SeaBIOS has become an overwhelming burden to maintain, one way forward is to deprecate and document. Describe the advantages of UEFI over BIOS booting, and provide clear instructions for getting there, but don't force people to make decisions they don't understand.

Without legacy support, switching to full firmware would be a bad suggestion for most existing users. We would be asking users (of varying skill levels) to perform an unfamiliar manual process, where the consequences of error or confusion lead to a non-bootable system, complicated recovery, and angry support requests. The advantages gained would have to be very large to outweigh that risk.

[ReddestDream]

Please keep in mind that removing legacy support from full firmware would effectively break the upgrade path for tens of thousands of existing users.

Users who choose RW_LEGACY do so because they either need/want ChromeOS or they cannot, for whatever reason, risk opening the device to remove the screw or fix the jumper to update to a FULL ROM. Users really should be making be making the decision about RW_LEGACY vs chrx/Crouton vs FULL ROM at the beginning and understand that if they need to change between, reinstallation will be necessary.

In addition, we have had success getting ChromeOS working on the UEFI firmware, but the process is currently complex and breaks autoupdating and channel switching due to the integration of ChromiumOS components:

#35

A migration script would help mitigate the pain, but it would still create a significant support load with ambiguous benefit to the user.

The migration script already exists. I made it months ago and had several users test it. I was told by @mattdevo and @coolstar that it was a bad, kludgy, risky solution that could easily break. I admit this and intended it as a temporary solution. But no one else has even given it much thought. I appreciate that you bring this up. I'd like to see more work on this as part of the transition process.

If SeaBIOS has become an overwhelming burden to maintain, one way forward is to deprecate and document. Describe the advantages of UEFI over BIOS booting, and provide clear instructions for getting there, but don't force people to make decisions they don't understand.

The major problem, as I mention above, is that is unrealistic to keep them in sync anymore. The implementation of OpRegion in Coreboot, necessary for the UEFI ROMs, has changed how the graphics work and made it difficult to keep the Legacy ROMs, which need different configuration in Coreboot, working properly. We saw this with the Backlight issues recently. It's not just a matter of compiling with a different payload anymore. Prior to 12/14, at least the UEFI firmwares still depended on SeaBIOS as shim and the VBIOS to provide graphics support. Eliminating these has improved the boot time of the UEFI ROMs and fixed numerous issues, however; the ROM types have now diverged sufficiently that Coreboot changes for one can now break the other . . . :/

In addition, maintaining two ROMs for each device effectively doubles the testing time, which already consists of testing 3 OSes in multiple versions. I test Windows 8.1, Windows 10, Linux (kernels 4.4, 4.7, and 4.10) as well as a macOS 10.11 and 10.12 on supported models (HSW/BDW) across five generation: SNB, IVB, HSW, BDW, and BYT.

As to advantages, the advantages regarding Windows and macOS I don't think interest you, so I will not discuss them here. If you are interested, let me know.

As to Linux, it is true that Linux does not benefit as much as Windows and macOS from the transition to UEFI. I'm not going to deny that. Part of the reason is that development time has not been spent there since Linux users have had the Legacy ROMs. Problem now is that we have reached the breaking point where maintaining two sets of firmware is now a great deal harder, and Linux users will now suffer will older, buggier firmware if they remain on SeaBIOS firmwares.

There is also the unfortunate decision that Debian made and Ubuntu inherited to use NVRAM to change the boot priority on UEFI firmwares in order to boot. NVRAM support does not exist in the Coreboot UEFI package (CorebootPayloadPkg). We would have to implement it, and this will take time. Until this is resolved, these distros will not work OotB, and, considering how popular they are, this looks like broken Linux support . . .

This does not mean that Linux doesn't work or is somehow less supported on the UEFI firmwares. On the contrary, I test Linux, multiple kernels, with each UEFI firmware release. Also, as you know GalliumOS has been fixed to account for this NVRAM issue. Non-Debian-based mainstream distros also do not have this issue, as they made the decision to handle UEFI booting more like how Windows does it. This issue also affects other non-Chrome PC hardware where the vendor left out NVRAM as a cost saving measure as Windows does not make much use of it.

See this these issues:

#4

#10

On this point of forcing people to make decisions they don't understand, let's all step back and realize that users are getting this for free and no one is ever forcing them to update the firmware or change firmware types. This point about user choice has to be balanced against developer time and keeping users up-to-date. We would actually love to have even more feedback from Linux users using the UEFI firmware, and we have quite a few such users on /r/chrultrabook.

There just has been this notion going around that the UEFI ROMs are the "Windows" firmware, and this is actually painful to me given the amount of testing on Linux I do. Other than the NVRAM issue, on SNB/IVB/HSW/BDW/BYT books, Linux support is at parity with Windows support on the UEFI firmwares if not exceeding it (e.g., Audio on BYT due to the missing driver for Windows). Good compliant firmware can support a variety of OSes with minimal workarounds. For example, in case you didn't know, OSI=Linux is no longer necessary on any device. We found a better way for Lulu's touchpad that makes both Windows and Linux happy at the same time. Just took more reading through ACPI manuals and kernel source . . .

We went through this same transition on /r/chultrabook with Windows users. Took several months to get everyone transitioned. Back then, the only real advantage for Windows was faster boot. People who were not ready simply didn't update the firmware until they were. Now, I agree that things were not handled the best at that point. I'm not calling for the Legacy ROMs to be somehow "pulled in the dead of night," especially for the SNB/IVB/HSW/BDW users who have had a long history with them. But we need to start taking steps toward getting rid of them.

We are also currently working on BSW support, and we are going to /need/ UEFI there to have any hope of getting it working better . . .

Without legacy support, switching to full firmware would be a bad suggestion for most existing users. We would be asking users (of varying skill levels) to perform an unfamiliar manual process, where the consequences of error or confusion lead to a non-bootable system, complicated recovery, and angry support requests. The advantages gained would have to be very large to outweigh that risk.

As I've mentioned, I'm very willing to help users transition existing Linux installs, though I do recommend eventually performing a clean installation, as Windows users had to, to ensure stability. And I discussed above, I actually don't recommend that users using other firmware/Linux installation types transition to Full ROMs at all unless they have a pressing need to. And if they decide to, I don't think it's that hard to provide some documentation for the process (which I could write up and others could edit and help with) of preserving existing installs, which the caveat that they should make proper backups and eventually just reinstall to ensure maximum stability.

The advantages of UEFI for Linux users will unfortunately have to come /as/ users transition to it, rather than before, which was the same in the case of our Windows support . . .

I'm hoping to have good dialog and cooperation on this. I don't want this transition to be overly burdensome on anyone and I know that tensions are high . . .