Re: Propose a new application for reading DIMM SPD directly

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

On Tue, Feb 08, 2022 at 04:23:12PM +0800, Michael Shen wrote:
> On Tue, Feb 8, 2022 at 3:11 PM Patrick Williams <patrick@stwcx.xyz> wrote:
> > On Tue, Feb 08, 2022 at 01:10:37PM +0800, Michael Shen wrote:
> > > 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.

That seems like it might work.  You'll have to deal with the time when the BIOS
has the mux in the BMC code somehow.  Ideally I'd ask for the mux select to also
be fed to the BMC as an input GPIO so that you can differentiate between "we
don't own the mux" and "all the devices are NAKing us".

> > 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.

I'm not sure why it would be an issue.  Hopefully one of the maintainers of that
repo can weigh in.  I wouldn't expect "parsing only IPMI-format EEPROMs" is a
design but just the current state of implementation.

-- 
Patrick Williams

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]