want AGESA 1.0.0.9 identifiers

[wesolows]

There are a number of new token IDs since AGESA 1.0.0.1 that are recognised and perhaps in some cases required by firmware. In principle these should have been documented after AMD pub 55483 rev. 1.52 up to and including rev. 1.70 but it's likely many are undocumented. The new unrecognised tokens used by AMD on their Ethanol-X board for Milan are:

Bool 0BCBD809 APCB_TOKEN_UID_DF_PICKER_THROTTLE_EN
Dword E8516128 APCB_TOKEN_UID_GNB_ADDI_FEAT_OFF_RAMP
Dword 8D4076DD APCB_TOKEN_UID_GNB_ADDI_FEAT_ON_RAMP
Word A4BAC3D5 APCB_TOKEN_UID_FCH_IC_SDA_RX_HOLD
Word 545D7662 APCB_TOKEN_UID_FCH_IC_SDA_HOLD_OVERRIDE
Word 9518F953 APCB_TOKEN_UID_FCH_IC_SDA_TX_HOLD
Byte F5768CEE APCB_TOKEN_UID_GNB_ADDI_FEAT_DSM_DETECTOR
Byte B051E421 APCB_TOKEN_UID_RESERVED_DRAM_MODULE_DRTM
Byte ADC833E4 APCB_TOKEN_UID_PSP_SEV_DISABLE
Byte 96A5ED6E APCB_TOKEN_UID_MEM_DISABLE_TCCD_EQUAL_5_READ_COMMAND_SPACING
Byte 6CAD6DA9 APCB_TOKEN_UID_DV_ARBITER_MAX
Byte 640DD003 APCB_TOKEN_UID_DV_ARBITER_MIN
Byte 31A6AFAD APCB_TOKEN_UID_GNB_ADDI_FEAT_DSM
Bool 9D6EE05E APCB_TOKEN_UID_DF_NPS1_4_INT_RDIMM_4_NON_INT_NVDIMM

We need to add support for these identifiers.

[daym]

Most of those are straightforward, except APCB_TOKEN_UID_GNB_ADDI_FEAT_DSM_DETECTOR and APCB_TOKEN_UID_GNB_ADDI_FEAT_DSM.

In the actual APCB, in the beginning in Milan those were both Bool. MilanPI 1.0.0.4 changed them both to Byte.

I guess we need to have two extra variants. Sigh.

[wesolows]

One of the things I have learned recently is that images built with the fastspew branch and booted on milan-gimlet result in an inability to write FCH registers via SMN. The same software works as expected on the main branch that delivers 1.0.0.1 firmware. While it is possible that this is a configuration (APCB) issue or a bug unique to the 1.0.0.9 fastspew ABL, the most likely explanation is that this has been broken somehow in firmware. Without the ability to test anything other than 1.0.0.1 and my manually hacked-up 1.0.0.9-fastspew, we aren't able to pin this down. The release notes don't indicate that this was changed at all; indeed, in 1.0.0.6 they actually changed some of their x86 code to use SMN for (FCH-bound) GPIO control, so my initial naive understanding is that this is supposed to work. We need to get to a point where we can do enough differential diagnosis to identify the specific cause of this behaviour and either correct whatever we are doing wrong or file a bug with AMD.