Attention is currently required from: Keith Hui.
Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/73690 )
Change subject: nb/intel/snb: Normalize spd_addresses in devicetree ......................................................................
Patch Set 5:
(1 comment)
Commit Message:
https://review.coreboot.org/c/coreboot/+/73690/comment/4e020c43_96d3f998 PS3, Line 15: to native raminit as well.
Without knowing what Haswell does, I was at first thinking about using 0x01-0x0f for index into spd. […]
The Haswell code always receives SPD info from C code, and abstracts the interface so that it doesn't depend on pei_data.h stuff. The plan is to allow any Haswell mainboard to use either MRC or (not yet complete) native raminit without needing to specify the same information twice (which is the status quo for Sandy Bridge).
Haswell code after CB:51448 has mainboards fill in the `spd_info` struct by implementing `mb_get_spd_map()`, see `raminit.h`:
``` #define SPD_MEMORY_DOWN 0xff
struct spd_info { uint8_t addresses[4]; unsigned int spd_index; };
/* Mainboard callback to fill in the SPD addresses */ void mb_get_spd_map(struct spd_info *spdi); ```
The `addresses` array should be easy to understand: it stores the SMBus addresses in the same order your patches do (C0S0, C0S1, C1S0, C1S1; C = Channel, S = Slot). The main difference is the `SPD_MEMORY_DOWN` macro: it can be used instead of a SPD address to indicate that a slot contains onboard memory, which does not have a SPD EEPROM.
For onboard memory, boards include a SPD file in CBFS. This file contains one or more sets of SPD data (to handle different types of onboard memory), and is treated like an array. The correct SPD data is chosen according to a "SPD index", usually obtained by reading the state of some GPIOs. The code to read and index the SPD file is the same for all mainboards, so it got moved to common code. Mainboards only need to supply the SPD index.
The reason why only one SPD index is supported is because Haswell MRC.bin has a bug: `struct pei_data` has a `spd_data[4][SPD_LEN]` array to provide individual SPD data for each slot, but MRC.bin only uses the SPD data in the first index (`spd_data[0][x]`). Sandy Bridge MRC.bin has the same bug, the code currently `memcmp()`'s the SPD data across all slots to make sure it matches.
To find boards using SPD files in CBFS, grep for `HAVE_SPD_IN_CBFS`. For Sandy Bridge, there's `samsung/lumpy`, one of `hp/snb_ivb_laptops`, `lenovo/s230u`, `lenovo/x1_carbon_gen1`, `lenovo/t430s` (T431S) and `google/link`.
Actually, CB:73097 added support for yet another Sandy/Ivy Bridge board not too long ago! 😄