[coreboot] Re: On handling vendorcode

Hi Patrick.
> I'm not sure about Siemens' hwilib: if that's imported, it remains there, if this version is written for coreboot, src/drivers/siemens perhaps?

This code is basically a pure software library to access defined fields within a binary image kept inside CBFS.
Since there is no hardware this code especially deals with I am not sure about src/drivers/ as the host directory.
But I am totally fine with moving it into the tree and out of vendorcode, maybe into src/lib/siemens?

Werner

Von: Patrick Georgi via coreboot  
Gesendet: Mittwoch, 7. April 2021 10:59
An: Peter Stuge 
Cc: coreboot 
Betreff: [coreboot] Re: On handling vendorcode

Am Di., 6. Apr. 2021 um 21:21 Uhr schrieb Peter Stuge :
Patrick Georgi via coreboot wrote:
> Any objections to moving the code out there that has no other upstream
> (e.g. src/vendorcode/google/chromeos or src/vendorcode/eltan, I think?)
> while moving in code from elsewhere in the tree that fits the "it has a
> foreign upstream" description (e.g. the lzma library)?

I think that can make sense, but where would the chromeos, eltan and
other directories go instead? Someplace existing, or someplace new?
I first wanted to make sure that there are no major issues with the overall idea, but to further the discussion:

- src/vendorcode/eltan/security -> src/security/mboot
- src/vendorcode/google/chromeos is a mixed bag: some src/drivers/tpm/cr50, some src/lib (e.g. elog, vpd), some src/acpi/chromeos (acpi*)

I'm not sure about Siemens' hwilib: if that's imported, it remains there, if this version is written for coreboot, src/drivers/siemens perhaps?

The other things look to be "real" vendorcode, even if we're probably the last codebase by now that still ships (our versions of) amd/agesa.

Patrick