It is definitely not 0x17C0 as that would cross over padding and other data.
I checked out some Asus laptops with those Phoenix CPUs and a maximum of 0x1700 can be observed superficially. However, that is clearly alignment padding for 0x16C0.
Inspecting the area before the microcode, it appears that it is an AMD PSP module ($PS1). Now, I’m not familiar with AMD PSP but some quick reverse engineering later, I can see the following:
The $PS1 header is 0x100 sized. At offset 0x4 (and 0x50, probably only when uncompressed ? - doesn’t matter much), we have the actual payload size. In this case: 0x15C0. At offset 0x6C, we have the full PSP module size. In this case: 0x17C0.
It’s clear that the header is 0x100, the payload is 0x15C0 (what we need for MCE) and thus, the last 0x100 bytes must be an RSA 2048-bit signature. So the format, as reversed:
The size of 0x15C0 also matches with all other Ax-series CPUIDs and is referenced at the microcode header at offset 0xA-0xC, which used to be reserved before AM5, but it seems to contain the microcode size, once multiplied by 0x10 (0x015C x 0x10 = 0x15C0).
