Problem :
In the current pldm design, the LED PDR's of Processors & LED PDR's of DIMMS are generated and attached to Processor FRU PDR (entity type, instance number , container) obtained from Host boot.
As the LED's are attched to processors & DIMM's , if the FRU(proc & dimm) are not plugged in on the system, then host will not send the FRU PDR's of processors & DIMM, so host will not be able to toggle the led for non-populated parts.
Usecase
Host needs a way to toggle an LED associated with Processor
Solution
Host boot now added one more layer of FRU for both Processors and DIMM.
Host boot now sends:
Memory Module(DIMM) under Memory Board entiity
Processor Module(DCM) under Physical Socket entity
So, irrespective of whether a DIMM or ProcessorModule is present, host will always send Memory Board & Physical Socket , so from pldm side, we need to modify the above mentioned led PDR's with the same entity type , instance number & container id for both Memory Board entiity & Physical Socket entity from hostboot.
rfrandse
commented
1 year ago
Problem : In the current pldm design, the LED PDR's of Processors & LED PDR's of DIMMS are generated and attached to Processor FRU PDR (entity type, instance number , container) obtained from Host boot.
As the LED's are attched to processors & DIMM's , if the FRU(proc & dimm) are not plugged in on the system, then host will not send the FRU PDR's of processors & DIMM, so host will not be able to toggle the led for non-populated parts.
Usecase Host needs a way to toggle an LED associated with Processor
Solution
Host boot now added one more layer of FRU for both Processors and DIMM.
Host boot now sends:
So, irrespective of whether a DIMM or ProcessorModule is present, host will always send
Memory Board&Physical Socket, so from pldm side, we need to modify the above mentioned led PDR's with the same entity type , instance number & container id for both Memory Board entiity & Physical Socket entity from hostboot.