Attention is currently required from: Arthur Heymans, Patrick Rudolph, Paul Menzel, Jingle Hsu, Nill Ge, Marc Jones, Nico Huber, Subrata Banik, Johnny Lin, lichenchen.carl, Tim Chu, Shelly Chang. Angel Pons has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/63882 )
Change subject: arch/x86/smbios.c: Add SMBIOS type 17 for empty DIMM slots ......................................................................
Patch Set 8:
(2 comments)
Patchset:
PS8:
But the new 'bool present' hasn't been set by all the platform codes yet, without Kconfig it seems p […]
You could invert `bool present` to `bool empty` or similar, so that the default value doesn't change the original behavior. I guess one could also consider meminfo DIMM entries with a capacity of 0 MB to be empty slots.
If one has access to SPD address info in coreboot, it's possible to know which slots are populated. For example, Haswell mainboards define the `mb_get_spd_map()` function so that northbridge code knows which slots are populated. Haswell supports up to 4 DIMM slots, but mb/asrock/h81m-hds only has 2 DIMM slots, so it only specifies the SPD addresses for 2 slots:
void mb_get_spd_map(struct spd_info *spdi) { spdi->addresses[0] = 0x50; spdi->addresses[2] = 0x52; }
In contrast, mb/asrock/b85m_pro4 has 4 DIMM slots:
void mb_get_spd_map(struct spd_info *spdi) { spdi->addresses[0] = 0x50; spdi->addresses[1] = 0x51; spdi->addresses[2] = 0x52; spdi->addresses[3] = 0x53; }
So the code that fills in meminfo could use this info to know which slots exist on a mainboard.
However, I don't see something like this on xeon_sp. How does FSP know which DIMM slots are implemented? Or does FSP just probe all possible SPD addresses? If this is the case, I guess one would need to have a mainboard-defined function for xeon_sp that provides a map of implemented DIMM slots, so that xeon_sp code skips generating meminfo entries for inexistent DIMM slots.
File src/Kconfig:
https://review.coreboot.org/c/coreboot/+/63882/comment/d572593e_925aa365 PS2, Line 819: SOC_DIMM_MAX
For memory-down you might generate type 17 as well. In that case form factor would be "other", "row of chips" or "die".
I understand that type 17 entries should be generated for memory-down as well, but what about half-populated configs? i.e. the board is designed with 2 channels of memory-down, but some SKUs only use one channel.