On 04/06/2018 12:20 PM, Patrick Georgi wrote:
Am Mi., 4. Apr. 2018 um 18:10 Uhr schrieb Aaron Durbin via coreboot <coreboot@coreboot.org mailto:coreboot@coreboot.org>:
> Agree, but coreboot use old commit from edk2. Is it fine to push vUDK2018? I guess? I'm not really sure who uses edk2. I guess tianocore payload? Patrick is on holiday right now, but he would probably the best person to answer that.It's used for the tianocore payload, indeed. And yes, updating to a newer commit is fine.
> I believe coreboot should stick to edk2 releases not to random commits > in the tree.That sounds like a reasonable guideline.
Ok, I will push vUDK2018.
However if a release isn't fit for use as a coreboot payload, I'd go for (not so) random commits that fix problems rather than stick to another project's schedule and keep things broken.
> Can anyone tell what tests were made against tianocore payload? There > are patches in payload/external/tianocore/patches and I'm not sure > against what hardware those should be validated.The payload integration stuff is provided on a best-effort basis, so right now "it builds and it boots on one system" is good enough. If you want to support the default payload selection for your board(s), I'll appreciate your effort, and we could tighten up the policy around it (so that you, and others who volunteer to test, would have to sign off on updates that might affect their supported systems).
Can you tell what is this "one system"?
I did ECC2017 presentation about support of tianocore payload on PC Engines apu{2,3,4,5}. With couple patches I was able to port that support on top of vUDK2018.
https://github.com/3mdeb/edk2/pull/2/files
Truly I just need one patch payloads/external/tianocore/1_CorebootPayloadPkg_pcinoenum.patch - other patches are not exactly needed for apu{2,3,4,5} support. My modification probably should lend somewhere in edk2, but I'm not sure how much they are interested.
I just wonder how to solve situation where edk2 customization is needed to boot given platform and in the same case customization may affect behavior of other platforms.
Ideally we'd have automated hardware testing, but that's a sore point for years now. :-(
Internally we use RTE (Remote Test Environment) it is open hardware: https://github.com/3mdeb/rte-schematics
Our plan is to create commercial service on top of that platform with firmware development, validation and remote debugging services. We are in preparation of marketing materials, so some offer should appear soon. I already had email discussion with Patrick, but we didn't moved forward.
Some blog posts about RTE: https://3mdeb.com/firmware/minnowboard-turbot-remote-firmware-flashing-with-... https://3mdeb.com/firmware/pc-engines-apu2-python-robot-framework-validation...
Best Regards,
Am Fr., 6. Apr. 2018 um 17:15 Uhr schrieb Piotr Król piotr.krol@3mdeb.com:
Can you tell what is this "one system"?
Sorry, "any one system" - just the system that the developer who last touched the payload integration happened to test with.
As said, there's little rigor around the payload integration. All professional deployments I know use separately built payload binaries. And as said, if you want to take this on, we can certainly tighten up the rules going forward.
Regards, Patrick
-
Patrick Georgi -
Piotr Król