Propose a new application for reading DIMM SPD directly

[Ed Tanous]

On Wed, Feb 9, 2022 at 11:56 AM Patrick Williams <patrick at stwcx.xyz> wrote:
>
> 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 at 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.

The other thing to recognize is that in these systems, the bmc
controls the CPU init state machine, so in practice, the BMC can
generally read the JEDEC eeproms long before the host would even want
to access them, and can hold off the host until the read is complete,
which mostly renders this race condition moot (daemon crashes might
still have problems.)

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

This seems like a nitty gritty design detail that's best handled in
code when we review it.  I think the important bit here is that there
are paths where this could work without a significant design issue.

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

So long as it can function properly in its current design, i have no
problem with FruDevice adding more parsing types.  In fact, there's
already patchsets out to add Linkedins proprietary fru type to
FruDevice, so in terms of design, Patricks request seems reasonable.



>
> --
> Patrick Williams