On Wed, Jan 15, 2020 at 10:26 PM awokd via coreboot <[email protected]> wrote: > > Mike Banon: > > If you know, please tell the AGESA versions of fam15h/fam16h AMD > > vendorcode. For fam14h it is v1.103 - so no questions - but for fam15h > > and fam16h it says v0.001: #define AGESA_VERSION_STRING {'V', '0', > > '.', '0', '.', '0', '.', '1', ' ', ' ', ' ', ' '} > > From hacking on the code itself, it seems f16kb is a newer fork of AGESA > than f15tn, which is newer than f14. For example, a couple failures to > initialize a variable in f14 were already addressed in f15 and f16, and > the MMIO allocation seems a bit more fleshed out in f16 than f15.
This is true. Just assume zero correllation with the version string of the scrubbed AGESA with anything you may find embedded in proprietary OEM blobs. Also, the build of MullinsPI binaryPI, that SAGE or AMD AES pushed to 3rdparty/blobs, (AFAIR tagged 1.0.0.4 or 1.0.0.A) has a change (relevant ECC fix) that they never upstreamed to whatever AMD department was responsible of the MullinsPI upstream. Furthermore, that change was incomplete for configurations without UMA (like the headless pcengines/apu2 variants) so proper ECC support requires a binary-patched AGESA blob. Neither of these relevant ECC fixes are in the official MullinsPI source package (1.0.0.J is last I am aware of), should an industry partner request the source from AMD under NDA for product development. Same goes for IOMMU feature, ACPI tables from AGESA are broken and coreboot has to override IVRS at least. Regards, Kyösti Mälkki _______________________________________________ coreboot mailing list -- [email protected] To unsubscribe send an email to [email protected]
