AGESA versions of fam15h/fam16h? Version string is v0.001

[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', ' ', ' ', ' ', ' '}

Also, I wonder if there's an AGESA changelog somewhere, to learn if
any security vulnerabilities or bugs have been fixed since AMD has
shared some AGESA revision with coreboot. If these problems are
serious enough, I could try to ask AMD to share the latest AGESA code
available for these platforms.

[awokd]

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.
> Also, I wonder if there's an AGESA changelog somewhere, to learn if
> any security vulnerabilities or bugs have been fixed since AMD has
> shared some AGESA revision with coreboot. If these problems are
> serious enough, I could try to ask AMD to share the latest AGESA code
> available for these platforms.

There are AGESA release notes for the PI blobs, such as
3rdparty/blobs/pi/amd/00730F01/FT3b/AGESA_Release_Notes.txt. Not finding
an equivalent under vendorcode (or generic internet searches)...

[Kyösti Mälkki]

On Wed, Jan 15, 2020 at 10:26 PM awokd via coreboot
 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