On Thu, Feb 14, 2019 at 3:11 PM Nico Huber nico.h@gmx.de wrote:
On 14.02.19 09:28, Patrick Rudolph wrote:
On Wed, 2019-02-13 at 10:15 +0100, Nico Huber wrote:
On 13.02.19 09:45, Patrick Rudolph wrote:
With UEFI the defactor standard it seems reasonable to improve the tianocore payload integration.
I agree that UEFI may seem ubiquitous (we've slept too long, never pro- vided an alternative), but why should we focus on tianocore?
Tianocore isn't the only UEFI implementation. There is Yabits and, IIRC, somebody was working on a Boot-Services implementation for Linux (don't know the state of it, though). So why not put the effort into something that benefits our infrastructure more? Yabits uses libpayload, afaik. Would be nice to have more payloads upstream that use it. And if core- boot developers would put as much effort into Yabits as they put into merely getting tiano to compile, it would likely flourish much better.
There's yabits as payload integration in coreboot already.
Yabits didn't receive updates in the last few month. Looking at the code base it's more a Proof-of-Concept.
I fear it'll stay this way if everybody interested in UEFI runs after Tianocore. Open-source development isn't about waiting for somebody else to do the job. At least, it wasn't always.
I think these are completely separate issues however: one being providing a working Tianocore implementation to users who need a payload with EFI boot support, and the other being the best place to focus development effort.
I've gone ahead and created a new 'coreboot' branch based on my fbgop branch, with a little bit of cleanup. We can offer that as a working (or even default) option, and then figure out the best path forward. But it's pretty minimal effort to offer a better working default option
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org