Archive > 19.7 Legacy Series

Feature request: UEFI compatible Installation of Serial Image

(1/2) > >>

karl047:
Hi,
it will be nice, when the serial Image of the next major update works with UEFI too, like the VGA Version.

regards,
karl

franco:
That may be something to be done indeed. The question is if all serial hardware, mostly embedded and or older varieties are ok with this. I will try to provide a test image for this when I have a bit of time.


Cheers,
Franco

karl047:
Thank you, when you want I can test it later  ;)

skyjam:
I'm interested aswell

Current appliances should all support UEFI...

pietrushnic:
0.02$ from Open Source Firmware perspective:


* What problem are we trying to solve here? My feeling is that forcing everyone to use UEFI cause more problems then it solves. If the only value is working VGA/HDMI or other videos output, we should probably ask our selves if cause not lays in closed source nature of provided firmware. Going further, if this is OS responsibility to address those problems? I know that UEFI starting to be de-facto standard, but it would be great if that feature request would not cause problems to users that want to promote open source firmware and buy from hardware vendors that support that approach e.g. PC Engines and Protectli. So maybe to keep both sides happy there is a need for both UEFI and legacy version of the system?
* It is up to hardware vendors if they want to sell hardware, which is UEFI compatible. It is probably very easy if we consider closed source firmware, which is typically sold by the offshore manufacturer as part of the hardware. Security and quality of that closed firmware are very questionable. If anyone knows network appliance hardware with good support for UEFI compatible firmware please let me know. Of course, closed source firmware is not my story, so I would recommend open source firmware. Having UEFI compatible open source firmware is a very complex topic. First, it is expensive to develop and even impossible for some platforms (assuming current market state). Independent BIOS Vendors have long-lasting agreements with silicon vendors and because of that development on their side is cheaper and easier, but they target hardware that ships in a huge volume that's why silicon vendors care. Open source firmware development companies typically rely on reverse engineering. This state should change since there are signs from big silicon vendors that they want to open ecosystem - we will see. So first let's convince hardware vendors. Second, even if there will be a real need for that support keeping everything up to date and according to spec is non-zero effort work. What UEFI spec we should comply to? Who will test that, on which hardware and with which version of firmware? Do we have resources to keep up with UEFI spec? What features we want to support?

* What stack of open source firmware should be chosen? For PC Engines we started working on UEFI compliant environment over 2 years ago and presented the state of our work here, the stack was coreboot -> Tianocore payload (UEFI) -> UEFI-aware bootloader -> UEFI-aware OS. We will continue that work and if there is interest in hackers community I can schedule some blog post how to use UEFI support on PC Engines. Over 3 years of maintaining PC Engines firmware we received maybe 5 inquiries with interest in UEFI compatible firmware - almost all from non-commercial entities. Another software stack could be to write everything in edk2 (UEFI implementation), but that means the implementation of drivers in edk2, what can be very expensive and truly will mimic already existing closed source firmware. The last thing that we have to evaluate e.g. for Protectli FW6x (KabyLake) is the behavior of edk2+FSP, if this would be good enough to boot an OS, then maybe it is worth to go that path.

Personally, I like Qubes OS approach to the topic. They support both boot modes legacy and UEFI, but to get their certification you have to use open source firmware like coreboot.

Navigation

[0] Message Index

[#] Next page