Propose a new application for reading DIMM SPD directly

[Michael Shen]

On Tue, Feb 8, 2022 at 3:11 PM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> On Tue, Feb 08, 2022 at 01:10:37PM +0800, Michael Shen wrote:
> > Hi Openbmc,
> >
> > We would like to propose an application that directly reads the DIMM
> > SPD over HW interface(mostly I2C/I3C).
>
> Who is "we"?

Google BMC team. Benjamin Fair is our techlead for this project. Just CC him.

>
> > If I understand correctly, the main method for obtaining the SPD
> > information in openbmc is from SMBIOS which is prepared by BIOS. And
> > We are exploring another way that excludes the involvement of BIOS.
>
> Unless you're proposing that the BIOS itself comes to the BMC to get the SPD
> data, I'm somewhat surprised you could come up with a hardware design to make
> this work.  Due to the number of DIMM channels and the limited number of CS pins
> on JEDEC DIMMs, you're going to have muxes on the bus somewhere.  Mixing muxes
> and multi-master access is pretty problematic.

Yes, we need an additional MUX for switching the master(between BIOS or BMC).
However, compared to the single-master(BIOS only) design, this MUX is
the only hardware difference.

> Either the BIOS and BMC are
> fighting over the mux, which is going to mess with the mux driver's view of the
> world, or you've got one mux for each in which case you're switching masters
> onto a bus, which violates a few i2c design rules.

BIOS owns the MUX select pin and it can decide who owns the SPD(I2C/I3C) bus.
>From my understanding, BIOS only needs to read SPD during the POST stage.
For the rest of time, BIOS will hand over the SPD bus to BMC.

>
> > The architecture of this application will be similar to the
> > openbmc/smbios-mdr (the dimm part). The main difference will be the
> > data source (changed from SMBIOS to SPD).
> >
> > Currently the code is still being implemented, and we plan to support
> > DDR5 SPD first, then expand to other DDR generation(if needed).
>
> Hopefully you're leveraging the existing kernel drivers for reading SPD EEPROMs.
> This creates you a sysfs file containing the whole of the EEPROM content.  You'd
> just need to write a parser for JEDEC SPD format data.

Yes, the data is coming from the sysfs file. And the SPD parser is one
of the main parts.
The second main part is a D-Dus service that exposes data from SPD to
D-Bus interface.

>
> You should take a look at what is already existing in fru-device (part of
> entity-manager repository).  This is already doing this for IPMI-format EEPROM
> data.  We should be able to replicate/enhance this code, in the same repository,
> to handle SPD format.

I am not sure if it's a good idea to put it into the entity-manager
repo. As you said EM
is designed for IPMI-format EEPROM. Adding another parser into that
repo may violate
EM's design.