Hi folks!
With UEFI the defactor standard it seems reasonable to improve the tianocore payload integration.
I'm having trouble to compile "stable" and "master" is totally broken as packages have been removed.
Instead of the current approach of maintaining patches in our tree, I'd like to use a repo that has those patches applied and is known to be working.
A good candiate is [1], as it's maintained, has bug-fixes and features upstream tianocore doesn't provide, and it's known to work with coreboot out of the box.
Similar to seabios, we should use this repo without additional in-tree patches to build a working payload.
Please tell me what you think about the proposed solution.
[1]: https://github.com/MrChromebox/edk2
Hi,
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.
A good candiate is [1], as it's maintained, has bug-fixes and features upstream tianocore doesn't provide, and it's known to work with coreboot out of the box.
Agreed. We don't even have to switch the upstream repo btw. In git, it's as easy as `git fetch https://github.com/MrChromebox/edk2 fbgop` instead of the current "stable" reference.
IIRC, we currently try to apply the local patches to any ref. As that's never supposed to work, we should only apply them if "stable" is selec- ted. Or get rid of the current "stable" altogether.
Nico
Hi,
What are Google's and Intel's plan on migrating to a stable UEFI payload on x86 coreboot ?
On Wed, 2019-02-13 at 10:15 +0100, Nico Huber wrote:
Hi,
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.
A good candiate is [1], as it's maintained, has bug-fixes and features upstream tianocore doesn't provide, and it's known to work with coreboot out of the box.
Agreed. We don't even have to switch the upstream repo btw. In git, it's as easy as `git fetch https://github.com/MrChromebox/edk2 fbgop` instead of the current "stable" reference.
IIRC, we currently try to apply the local patches to any ref. As that's never supposed to work, we should only apply them if "stable" is selec- ted. Or get rid of the current "stable" altogether.
I'll prepare a patch on gerrit.
Nico
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.
Nico
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
Also, there may be users interested in the "whole" UEFI experience, with secure boot validating binaries loaded from a https server via their infiniband controllers and IPoIB implemented by on-PCIe firmware delivered as EBC bytecode. I don't see yabits providing support for that.
Patrick
Am Do., 14. Feb. 2019 um 23:05 Uhr schrieb Matt DeVillier matt.devillier@gmail.com:
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
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Hi,
It seems the Tianocore Coreboot payload (CorebootPayloadPkg/CorebootModulePkg) will be replaced in future by UefiPayloadPkg... See also: https://firmwaresecurity.com/2018/09/14/uefipayloadpkg-uefi-payload-project-... The preliminary implementation is available in: https://github.com/tianocore/edk2-staging/tree/UEFIPayload
Kind regards, Sumo
On Thu, Feb 14, 2019 at 8:09 PM Patrick Georgi via coreboot < coreboot@coreboot.org> wrote:
Also, there may be users interested in the "whole" UEFI experience, with secure boot validating binaries loaded from a https server via their infiniband controllers and IPoIB implemented by on-PCIe firmware delivered as EBC bytecode. I don't see yabits providing support for that.
Patrick
Am Do., 14. Feb. 2019 um 23:05 Uhr schrieb Matt DeVillier matt.devillier@gmail.com:
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
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Paul Manicle, Halimah DeLaine Prado _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Matt DeVillier -
Nico Huber -
Patrick Georgi -
Patrick Rudolph -
Sumo