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