Glath05a-64o: platform manager #462
Conversation
aalamsi22
force-pushed
the
glath05a_64o_platform_manager
branch
from
a698a0f to
ea4a264
Compare
| platformConfig_.platformName().value() == "meru800bia" || | ||
| platformConfig_.platformName().value() == "glath05a-64o") && | ||
| (!(idpromConfig.busName()->starts_with("INCOMING")) && | ||
| *idpromConfig.address() == "0x50")) { |
There was a problem hiding this comment.
Considering this is a new platform, can we pick a different address for SCM EEPROM (outside 0x50-0x57), so we dont have to do this hack. We want to avoid all platform-specific hacks in the service code.
There was a problem hiding this comment.
Hi Somasun. This platform is using the same MERU cpu card and will require the same hack.
There was a problem hiding this comment.
In https://github.com/facebookexternal/fboss.bsp.arista/pull/31, there was discussion on following up with Intel and fixing it cleanly upstream in i2c-1801. How far are we in that discussion/effort?
There was a problem hiding this comment.
let me follow up on that discussion and get back to you.
There was a problem hiding this comment.
Based on discussions with the maintainer of the i2c-1801 driver and Intel engineers, the ultimate recommendation was to patch the driver with a kernel param that will allow us to disable the automatic device binding feature. We will add the kernel param to the driver and share it with you for review, in the meantime we hope to use the existing workaround until we arrive at an agreed upon solution.
|
@aalamsi22 has updated the pull request. You must reimport the pull request before landing. |
aalamsi22
force-pushed
the
glath05a_64o_platform_manager
branch
from
251af38 to
542764c
Compare
|
@aalamsi22 has updated the pull request. You must reimport the pull request before landing. |
4 participants
Description
Chassis eeprom is implemented as a logical eeprom. See this for more details #774
Testing
Shortened platform_manager log showing a successful run.