Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding platform support for Juniper QFX5210 #3270

Merged
merged 2 commits into from
Sep 6, 2019
Merged

Adding platform support for Juniper QFX5210 #3270

merged 2 commits into from
Sep 6, 2019

Conversation

ciju-juniper
Copy link
Contributor

This switch has 64 QSFP28 (40G/100G) ports, 2 SFP+ (1G/10G) ports on Broadcom Tomahawk II chipset. CPU used in QFX5210-64C-S is Intel Broadwell-DE. The machine has Redundant and hot-swappable Power Supply (1+1) and also has Redundant and hot swappable fans (3+1).

- What I did
Adding platform support for Juniper QFX5210

- How I did it

  • Added the device specific files, bcm configuration, portmapping file for Broadcom TH2
  • Developed / ported the device drivers for platform specific CPLDs
  • Developed the platform scripts

- How to verify it
Execute the following commands:

  1. show platform summary
  2. show interface status
  3. show interface transceiver eeprom
  4. sfputil show presence
  5. sensors
  6. show platform psustatus

- Description for the changelog
Adding platform support for Juniper QFX5210

- A picture of a cute animal (not mandatory but encouraged)

This switch has 64 QSFP28 (40G/100G) ports, 2 SFP+ (1G/10G) ports
on Broadcom Tomahawk II chipset. CPU used in QFX5210-64C-S is
Intel Broadwell-DE. The machine has Redundant and hot-swappable
Power Supply (1+1) and also has Redundant and hot swappable fans (3+1).

Signed-off-by: Ciju Rajan K <crajank@juniper.net>
Signed-off-by: Ciju Rajan K <crajank@juniper.net>
@msftclas
Copy link

msftclas commented Aug 2, 2019

CLA assistant check
All CLA requirements met.

@ciju-juniper
Copy link
Contributor Author

Attaching the test logs
TestLogs.txt

@@ -0,0 +1,1579 @@
/*
* SFP driver for juniper qfx5210_64x sfp
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not use optoe module?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SFPs / QSFPs are managed by a CPLD in QFX5210 platform. So we need a cpld driver to detect the presence of pluggables. The same driver is used for the SFP eeprom mapping to sysfs and the other sfp specific parameters.

AFAIK, optoe driver support only eeprom and port_name in sysfs. Other parameters are CPLD dependent and need to be read from user space.

At this point in time, our preference is to use sfp cpld driver. Please let me know if there are any concerns with this approach.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, for eeprom and port_name in sysfs please reuse optoe driver. for others like reset, lpmode, presense, it is fine to use cpld driver.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will have to change the OIR logic, validate a number of optics, etc if we move to optoe driver. It will take some good amount of time. Meanwhile we need to get the SONiC workflow in place as Juniper is contributing for the first time. So if the qfx5210 platform support is added to SONiC image, it will immensely help us.

Please allow this initial commit. We will address it in the subsequent commit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can open an issue for moving to optoe driver. Please let us know if this is acceptable to you for merging the qfx5210 platform patches.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main reason to use optoe module is that we can deliver unified feature to the sonic user across different platform. For example, recently optoe module adds support of osfp and qsfp-dd. If we allow different platform to provide their own optical eeprom modules, it will be difficult to deliver features across platforms.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lguohan As I requested before, can I phase in the optoe changes in the subsequent commit?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you give us an ETA to move optoe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lguohan ETA will be 9/21. Three weeks from now. Shall try to finish it as early as possible.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lguohan As per our last discussion, could you merge this patch set?

Copy link
Collaborator

@lguohan lguohan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use optoe driver

@lguohan lguohan merged commit fdcb69d into sonic-net:master Sep 6, 2019
mssonicbld added a commit that referenced this pull request Apr 27, 2024
…atically (#18735)

#### Why I did it
src/sonic-utilities
```
* 9b463ca5 - (HEAD -> master, origin/master, origin/HEAD) [chassis][voq] Add fabric capacity monitoring cmds (#3255) (8 hours ago) [jfeng-arista]
* df94636b - Display target firmware version through CLI (#3274) (34 hours ago) [mihirpat1]
* cd5c0580 - Fix db_migrate.py show error and back trace while loading configuration on Linecard (#3257) (2 days ago) [Hua Liu]
* d48a8308 - Add Multi ASIC support for apply-patch (#3249) (3 days ago) [Xincun Li]
* b143ea6d - [chassis][voq]Add fabric monitoring commands. (#3239) (4 days ago) [jfeng-arista]
* 07d6d277 - [fast/warm-reboot] Retain TRANSCEIVER_INFO tables on fast/warm-reboot (#3240) (7 days ago) [Stepan Blyshchak]
* 8e5ff74f - Revert "Revert "route_check: Skip route checks if bgp feature is not enabled"" (#3270) (7 days ago) [anamehra]
* eb165f36 - Fix double hex to decimal conversion (#3267) (7 days ago) [Yuanzhe]
```
#### How I did it
#### How to verify it
#### Description for the changelog
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants