[coreboot] Problem with tianocore compilation in coreboot-sdk:1.50

[Piotr Król]

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 at coreboot.org <mailto:coreboot at 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-rte-remote-testing-environment/
https://3mdeb.com/firmware/pc-engines-apu2-python-robot-framework-validation-automation/


Best Regards,
-- 
Piotr Król
Embedded Systems Consultant
http://3mdeb.com | @3mdeb_com