- Use SfpOptoeBase by default to leverage new `sonic_xcvr` refactor
- Add support for `Woodleaf` product
- Move `libsfp-eeprom.so` to a different `.deb` package
- Add new logrotate configuration for arista logs
- Improve logging mechanism for the drivers (IO loglevel, fix syslog duplicates)
- Initialize chassis cards in parallel
- Refactor of `get_change_event` to fix interrupts treated as presence change
Why I did it
To implement fan control using thermalctld in DellEMC S6000 platform
Requires: Azure/sonic-linux-kernel#241
How I did it
Add thermal policies in 'thermal_policy.json'
Implemented thermal_manager.py and the necessary modules to perform fan control via thermalctld
Removed fancontrol.sh
How to verify it
Verified that the fan speeds are set based on the fan and temperature status.
Logs: S6000_fan_control_test_logs.txt
Why I did it
Adding SSD as part of platform components list.
Introducing platform_fw_au_reboot_handle to use auto-update functionality in fwutil
How I did it
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: platform/broadcom/sonic-platform-modules-dell/debian/platform-modules-s6100.install
new file: platform/broadcom/sonic-platform-modules-dell/s6100/scripts/platform_fw_au_reboot_handle
modified: platform/broadcom/sonic-platform-modules-dell/s6100/sonic_platform/chassis.py
modified: platform/broadcom/sonic-platform-modules-dell/s6100/sonic_platform/component.py
How to verify it
By running fwutil command.
Warning: fwupdate_fwimage_dir: /var/platform/fwpackage/.
Chassis Module Component Firmware Version (Current/Available) Status
--------- -------- ----------- ------------------------------- ----------------------------- ------------------
S6100-ON BIOS S6100-BIOS-3.25.0.2-9-noRP2.bin 3.25.0.2-8 / 3.25.0.2-9 update is required
FPGA smf_firmware_upgrade.tar 2.4 / 2.4 up-to-date
CPLD cpld_firmware_upgrade.tar 4 / 4 up-to-date
SSD ssd_firmware_upgrade.tar S16425cG / S16425cG up-to-date
root@sonic:~#
Why I did it
To support iTCO watchdog using watchdog APIs.
How I did it
Implemented a new watchdog class WatchdogTCO for interfacing with iTCO watchdog.
Updated reboot cause determination logic.
How to verify it
Verified that the watchdog APIs' return values are as expected.
Logs: UT_logs.txt
- Why I did it
Add support for SN2201 platform
- How I did it
Add required content for SN2201 platform
Note: still missing kernel driver support for this system. Once all is upstream will be updated as well.
- How to verify it
Install and basic sanity tests including traffic.
Signed-off-by: liora liora@nvidia.com
Depends on #9358
Why I did it
Adjust LED logical according to hw-mgmt change.
How I did it
Add a trigger to set LED to blink.
How to verify it
Manual test
For broadcom sai, we only need to upgrade the version, not necessary the token part in the url.
Co-authored-by: Ubuntu <xumia@xumia-vm1.jqzc3g5pdlluxln0vevsg3s20h.xx.internal.cloudapp.net>
#### Why I did it
Updated hw-mgmt pointer to updated branch and to include new bugfixes. The hw-mgmt submodule was previously pointing to an orphaned commit which could not be fetched from github, this has now been resolved.
#### How I did it
Updated submodule pointer.
#### How to verify it
Clone down repository and update all submodules.
Signed-off-by: Stephen Sun stephens@nvidia.com
Why I did it
Support zero buffer profiles
Add buffer profiles and pool definition for zero buffer profiles
Support applying zero profiles on INACTIVE PORTS
Enable dynamic buffer manager to load zero pools and profiles from a JSON file
Dependency: It depends on Azure/sonic-swss#1910 and submodule advancing PR once the former merged.
How I did it
Add buffer profiles and pool definition for zero buffer profiles
If the buffer model is static:
Apply normal buffer profiles to admin-up ports
Apply zero buffer profiles to admin-down ports
If the buffer model is dynamic:
Apply normal buffer profiles to all ports
buffer manager will take care when a port is shut down
Update buffers_config.j2 to support INACTIVE PORTS by extending the existing macros to generate the various buffer objects, including PGs, queues, ingress/egress profile lists
Originally, all the macros to generate the above buffer objects took active ports only as an argument
Now that buffer items need to be generated on inactive ports as well, an extra argument representing the inactive ports need to be added
To be backward compatible, a new series of macros are introduced to take both active and inactive ports as arguments
The original version (with active ports only) will be checked first. If it is not defined, then the extended version will be called
Only vendors who support zero profiles need to change their buffer templates
Enable buffer manager to load zero pools and profiles from a JSON file:
The JSON file is provided on a per-platform basis
It is copied from platform/<vendor> folder to /usr/share/sonic/temlates folder in compiling time and rendered when the swss container is being created.
To make code clean and reduce redundant code, extract common macros from buffer_defaults_t{0,1}.j2 of all SKUs to two common files:
One in Mellanox-SN2700-D48C8 for single ingress pool mode
The other in ACS-MSN2700 for double ingress pool mode
Those files of all other SKUs will be symbol link to the above files
Update sonic-cfggen test accordingly:
Adjust example output file of JSON template for unit test
Add unit test in for Mellanox's new buffer templates.
How to verify it
Regression test.
Unit test in sonic-cfggen
Run regression test and manually test.
* Add macsec-xpn-support iproute2 in syncd
Signed-off-by: Ze Gan <ganze718@gmail.com>
* Polish code
Signed-off-by: Ze Gan <ganze718@gmail.com>
* Remove useless files
Signed-off-by: Ze Gan <ganze718@gmail.com>
* Add self-compiled iproute2 to docker sonic vs
Signed-off-by: Ze Gan <ganze718@gmail.com>
* Enhance apt install for iproute2 dependencies
Signed-off-by: Ze Gan <ganze718@gmail.com>
Sonic master has moved to use SAI v1.9.1. For consistency, use the latest credo sai v0.7.2 package, built with
SAI header v1.9.1 too.
How I did it
Update credo sai url for v0.7.2
Add a debug tool crshell
- Why I did it
This is to update the common sonic-buildimage infra for reclaiming buffer.
- How I did it
Render zero_profiles.j2 to zero_profiles.json for vendors that support reclaiming buffer
The zero profiles will be referenced in PR [Reclaim buffer] Reclaim unused buffers by applying zero buffer profiles #8768 on Mellanox platforms and there will be test cases to verify the behavior there.
Rendering is done here for passing azure pipeline.
Load zero_profiles.json when the dynamic buffer manager starts
Generate inactive port list to reclaim buffer
Signed-off-by: Stephen Sun <stephens@nvidia.com>
- Why I did it
When PSU is powered off, the PSU is still on the switch and the air flow is still the same. In this case, it is not necessary to set FAN speed to 100%.
- How I did it
When PSU is powered of, don't treat it as absent.
- How to verify it
Adjust existing unit test case
Add new case in sonic-mgmt
Why I did it
Fix#9059. It provides common gbsyncd.service.j2 to start for platform specific gbsyncd docker, which must be named 'gbsyncd'.
How I did it
All of platform specific gbsyncd dockers use a common name 'gbsyncd'
Use a unique systemd service template gbsyncd.service.j2 for gbsyncd docker
- add `set_write_max` and `get_write_max` apis to Sfp API
- add `get_revision` platform API
- implement `is_midplane_reacheable` API
- add software fallback for setting Xcvr low power mode
- add `get_error_description` API
- add support for Woodleaf SKU
- various fixes/refactors/cleanups
upgrade centec arm64 sai to v1.9.1 and fix syncd compile error:
```
2021-11-21T19:58:09.0294367Z /usr/bin/ld: libSyncd.a(libSyncd_a-VendorSai.o): in function `syncd::VendorSai::queryStatsCapability(unsigned long, _sai_object_type_t, _sai_stat_capability_list_t*)':
2021-11-21T19:58:09.0297367Z ./syncd/VendorSai.cpp:439: undefined reference to `sai_query_stats_capability'
2021-11-21T19:58:09.0298900Z collect2: error: ld returned 1 exit status
```
Co-authored-by: shil <shil@centecnetworks.com>
- Why I did it
Support PSU voltage high/low thresholds and power max threshold
1. Add thresholds support for voltage and power.
2. As thresholds are not supported on all platforms, we need to check the capability first and fetch thresholds only if it is supported.
- How I did it
- How to verify it
Run regression test and manual test.
Signed-off-by: Stephen Sun <stephens@nvidia.com>
Why I did it
Fix#9059. It provides common gbsyncd.service.j2 to start for platform specific gbsyncd docker, which must be named 'gbsyncd'.
How I did it
All of platform specific gbsyncd dockers use a common name 'gbsyncd'
Use a unique systemd service template gbsyncd.service.j2 for gbsyncd docker
Signed-off-by: pettershao-ragilenetworks pettershao@ragilenetworks.com
What I did it
Add new platform x86_64-ragile_ra-b6510-32c-r0 (Trident 3)
ASIC Vendor: Broadcom
Switch ASIC: Trident 3
Port Config: 32x100G
Add new platform x86_64-ragile_ra-b6920-4s-r0 (Tomahawk 3)
ASIC Vendor: Broadcom
Switch ASIC: Tomahawk 3
Port Config: 128x100G
-How I did it
Provide device and platform related files.
-How to verify it
show platform fan
show platform ssdhealth
show platform psustatus
show platform summary
show platform syseeprom
show platform temperature
show interface status
#### Why I did it
Mellanox builds were failing intermittently due to the `issue_version` file and MFT package not building correctly in the Azure pipeline environment (both of these packages were patched to build correctly with bullseye running on the host and buster running on the dockers)
#### How I did it
Fixed two problems:
1. BLDENV is not passed to the Makefiles so the references to this were replaced with correct logic
2. `issue_version` was not defined as a target for bullseye and as such was not cached. Altered the build such that it is defined as a target for bullseye (in the case of buster it builds the file, in the case of bullseye it copies from buster)
The previous PR fixing this was reverted as it is no longer necessary for a passing build and was not a long-term fix. https://github.com/Azure/sonic-buildimage/pull/9235
#### How to verify it
Build on AZP and verify success.
Remove the "4.19..." specific code to add "-unsigned" suffix and just do so for any linux version.
For the syseeprom API part, have the Arista syseeprom class inherit from a class that can populate db.
Co-authored-by: Zhi Yuan (Carl) Zhao <zyzhao@arista.com>
Why I did it
To include capabilities fields in platform.json of DellEMC S6000, S6100, Z9332f platforms.
How I did it
Add the capabilities fields in each platform's respective platform.json.
How to verify it
Ran sonic-mgmt platform api test cases that use capabilities fields and verified that the results are as expected.
This commit fixes/avoids the following errors encountered during the
marvell-armhf build for bullseye
- Fix Marvell prestera DMA driver build failure due to kallsyms_lookup_name()
no longer being exported by the updated bullseye kernel. This is a temporary
fix that will be replaced by a future version of the DMA driver.
- Update qemu-user-static version to align with the new glibc version included
in bullseye
- Skip systemd-sonic-generator unit tests to avoid test failures. Root cause is
still TBD
#### Why I did it
Fix the following build errors observed when building marvell-armhf for bullseye
1. Marvell Prestera DMA driver uses kernel API no longer exported
ERROR: modpost: "kallsyms_lookup_name" [/sonic/platform/marvell-armhf/prestera/mrvl-prestera/cpssEnabler/linuxNoKernelModule/drivers//mvDmaDrv.ko] undefined!
2. Old qemu-user-static version does not support semop() leading to following build failure
semop(1): encountered an error: Function not implemented
3. systemd-sonic-generator unit test failure
ssg-test.cc:217: Failure
Expected equality of these values:
find_string_in_file(str_t, target, num_asics)
Which is: false
expected_result
Which is: true
Error validating Before=single_inst.service in test.service
[ FAILED ] SsgMainTest.ssg_main_40_npu (20 ms)
[----------] 4 tests from SsgMainTest (36 ms total)
[----------] Global test environment tear-down
[==========] 10 tests from 3 test suites ran. (54 ms total)
[ PASSED ] 7 tests.
[ FAILED ] 3 tests, listed below:
[ FAILED ] SsgMainTest.ssg_main_single_npu
[ FAILED ] SsgMainTest.ssg_main_10_npu
[ FAILED ] SsgMainTest.ssg_main_40_npu
3 FAILED TESTS
BRCM SAI missed implementing the SAI API "sai_query_stats_capability()" which is causing build issue.
The build issue is impacting PR(s) that need to use this API.
This PR is to stubbed BRCM SAI to add this SAI API and return not implemented so that it will fix build issue that it is causing.
No other functional changes were made.
The issu-version file for Mellanox is generated from the Mellanox SDK
libraries. The SDK is installed into a Buster docker container, but the
issu-version file goes onto the base OS, which is Bullseye. To work
around this, the issu-version build rules explicitly copies the
issu-version file to target/files/bullseye/ during the Buster build.
Because of our build infra, if caching is enabled and a cache is being
used, then for issu-version, since it is technically built as part of
Buster, then only target/files/buster/issu-version is saved into the
cache, and target/files/bullseye/issu-version isn't cached. If this
cache gets used, then target/files/bullseye/issu-version is missing, and
the final image build fails.
This is to work around the current build issue where Mellanox builds are
failing. This is so that issu-version is always "built", so that copy is
made into the bullseye directory.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
ipmihelper files are repeated for few DellEMC platforms. Removed the
files in sonic_platform since as part of debian rules,ipmihelper will be
copied to necessary directory.
* Make neccesary changed to mellanox platform code to build on Debian 11
* Revert use of backported kernel to build mft and elect to only build kernel module under bullseye
Allow mellanox platform to build and successfully switch packets in
Debian 11
Upgraded
* Mellanox SDK
* Mellanox Hardware Management
* Mellanox Firmware
* Mellanox Kernel Patches
Adjusted build system to support host system running bullseye and
dockers running buster.
Also add out of tree pca9548 mux driver to use platform data to mapping i2c bus with front panel port.
Signed-off-by: Jakkapan Jangmuang <jjangmua@celestica.com>
Co-authored-by: Saikrishna Arcot <sarcot@microsoft.com>
1. Fix build for armhf and arm64
2. upgrade centec tsingma bsp support to 5.10 kernel
3. modify centec platform driver for linux 5.10
Co-authored-by: Shi Lei <shil@centecnetworks.com>
Add an include in saibcm-modules and saibcm-modules-dnx that are now
needed due to Mellanox kernel patches.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
ISSU will likely be broken. As of right now, the issu-version file is
not being generated during build.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
The kernel already provides psample, and with module versioning being
done in modpost, having the SDK compile its own copy of psample breaks
loading dependent modules.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Remove Python 2 package installation from the base image. For container
builds, reference Python 2 packages only if we're not building for
Bullseye.
For libyang, don't build Python 2 bindings at all, since they don't seem
to be used.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
Update the build rules in saibcm-modules to use the 5.10 kernel instead
of searching for the 4.19 kernel. In addition, some code changes were
done to get it to compile. The main categories of such changes are as
follows:
* For /proc files, `struct file_operations` has been replaced with
`struct proc_ops`.
* Y2038 changes to use the new APIs, since `do_gettimeofday()` is no
longer available.
* Minor changes in how external kernel module symbols are read by
modpost.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
All docker containers will be built as Buster containers, from a Buster
slave. The base image and remaining packages that are installed onto the
host system will be built for Bullseye, from a Bullseye slave.
Signed-off-by: Saikrishna Arcot <sarcot@microsoft.com>
*Removing fake_platform environment variable. Following the merge of #9044 and Azure/sonic-swss#1978 the fake_platform environment variable is not used in any place and removing the stale references.
Signed-off-by: Sudharsan Dhamal Gopalarathnam <sudharsand@nvidia.com>
Added support for Mellanox-SN2700 based SKU for docker-sonic-vs and to differentiate platform based on hw-sku rather than on fake_platform in VS.
Currently SAI VS library uses hwsku based SAI profile to differentiate and mock different platform implementations. The same functionality in swss is achieved using a fake_platform env variable.
Using a fake_platform has some drawbacks that the vs container appears to still use a different vendor hw-sku
env
PLATFORM=x86_64-kvm_x86_64-r0
HOSTNAME=dd21a1637723
PWD=/
HOME=/root
TERM=xterm
HWSKU=Force10-S6000
SHLVL=1
fake_platform=mellanox
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DEBIAN_FRONTEND=noninteractive
_=/usr/bin/env
In order to unify the approach at both swss and vs SAI and to be uniform throughout this PR introduces the approach of using hw-sku to differentiate different platforms. This requires support for Mellanox-SN2700 HWSKU for Mellanox platform which is also addressed by this PR.
root@23c9ba83b0aa:/# show platform summary
/bin/sh: 1: sudo: not found
Platform: x86_64-kvm_x86_64-r0
HwSKU: Mellanox-SN2700
ASIC: vs
ASIC Count: 1
Serial Number: N/A
Model Number: N/A
Hardware Revision: N/A
root@23c9ba83b0aa:/# env
PLATFORM=x86_64-kvm_x86_64-r0
HOSTNAME=23c9ba83b0aa
PWD=/
HOME=/root
TERM=xterm
HWSKU=Mellanox-SN2700
SHLVL=1
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DEBIAN_FRONTEND=noninteractive
_=/usr/bin/env
root@23c9ba83b0aa:/#
Signed-off-by: Sudharsan Dhamal Gopalarathnam <sudharsand@nvidia.com>
- Why I did it
In case an app.ext requires a dependency syncd^1.0.0, the RPC version of syncd will not satisfy this constraint, since 1.0.0-rpc < 1.0.0. This is not correct to put 'rpc' as a prerelease identifier. Instead put 'rpc' as build metadata in the version: 1.0.0+rpc which satisfies the constraint ^1.0.0.
- How I did it
Changed the way how to version in RPC and DBG images are constructed.
- How to verify it
Install app.ext with syncd^1.0.0 dependency on a switch with RPC syncd docker.
Signed-off-by: Stepan Blyshchak <stepanb@nvidia.com>
* [Nokia ixs7215] Platform API fixes
This commit delivers the following fixes
- Fix bug preventing access to second PSU eeprom
- Fix bug preventing updates to front panel PSU status led
- Fix SFP reset test case failure
* Fix LGTM alert
Fixed issue introduced by PR#7857. The problem was that introduction of
using init_cfg.json.j2 template did not have instruction in
init_config.json.j2 to merge the virtual chassis default_config.json.
Ths fix is to have a separate invokiation of sonic-cfggen to combine
init_config.json and virtual chassis default_config.json
Signed-off-by: vedganes <vedavinayagam.ganesan@nokia.com>
* [202012][platform/barefoot] (#8543)
Why I did it
Pcied running by python 2.
How I did it
dropped python2 support and add python3 support for pcied in file docker-pmon.supervisord.conf.j2
How to verify it
docker exec pmon supervisorctl status
* [Netberg][nba715] Initial support for Netberg Aurora 715 switch
Signed-off-by: Andrew Sapronov <andrew.sapronov@gmail.com>
Co-authored-by: Kostiantyn Yarovyi <kostiantynx.yarovyi@intel.com>
Adding platform support for centec v682-48y8c_d.
Why I did it
Adding platform support for centec v682-48y8c_d.
This switch has 48 SFP+ (1G/10G/25G) ports, 8 QSFP28 (40G/100G) ports on CENTEC TsingMa.MX.
CPU used in v682-48y8c_d is Intel(R) Xeon(R) CPU D-1527.
How I did it
Modify related code in platform and device directory.
Upgrade sai to v1.8.
fix bug for parallel compile centec platform modules.
How to verify it
Build centec amd64 sonic image, verify platform functions (port, sfp, led etc) on centec v682-48y8c_d board.
Co-authored-by: Shi Lei <shil@centecnetworks.com>
Why I did it
Added Support for Dell EMC S5212f platform
How I did it
Implemented the support for Dell EMC S5212f platform
Platform: x86_64-dellemc_s5212f_c3538-r0
HwSKU: DellEMC-S5212f-P-25G
ASIC: broadcom
ASIC Count: 1
How to verify it
Verified the show command outputs
- Why I did it
* To support systems with dynamic port configuration
* Apply lazy initialization to faster the speed of loading platform API
- How I did it
* Add module.py to implement dynamic port configuration (aka line card model)
* Adjust chassis.py, platform.py, thermal.py, sfp.py to support dynamic port configuration
* Optimize existing code
- How to verify it
Platform regression on MSN4700, MSN3800 and MSN2700, 100% pass
Unit test covers all new changes.
Why I did it
Added Support for Alphanetworks SNJ60D0-320F platform
How I did it
Implemented the support for Alphanetworks SNJ60D0-320F platform
Platform: x86_64-alphanetworks_snj60d0_320f-r0
HwSKU: Alphanetworks-SNJ60D0-320F
ASIC: broadcom
ASIC Count: 1
How to verify it
Verified the show command outputs
- Why I did it
Bug fix:
bad_param request due to missing parser rest command while running mlxlink
- How I did it
Advance to MFT tool version to 4.17.2-12.
- How to verify it
Manually tested on all mellanox platforms.
- Why I did it
Add NVIDIA Copyright header to "mellanox" files
- How I did it
Add NVIDIA Copyright header as a comment for Mellanox files
- How to verify it
Sanity tests and PR checkers.
Why I did it
Currently the mellanox platform API is validating the file extensions of firmware packages to be installed for basic sanity checking. However, ONIE packages do not have an extension and as such if there is a "." in the name it is taken to be an extension and then fails the sanity check.
How I did it
I removed the check which ensures that ONIE images don't have a file extension.
How to verify it
Name the ONIE updater file 2021.onie and attempt to install it via fwutil install fw 2021.onie --yes
Why I did it
The fwutil update all utility expects the auto_update_firmware method in the Platform API to execute the update_firmware() call and not the install_firmware() call.
How I did it
Changed the method in the mellanox platform API component implementation.
How to verify it
Run fwutil update all with a CPLD update on a Mellanox platform and verify that it properly updates the firmware using the MPFA file.
- Why I did it
Advance to new Nvidia SAI release with the following changes:
New features:
- Align with new SDK/FW version 4.5.1006 and above and in parallel to existing used SDK/FW bundle
- Implement timestamp and egress_queue_index hostif packet attributes.
Bugs fixes:
- Fix compilation issues with gcc10
- Fix return code for buffer overflow for query enum values and query statistics capabilities
- Reduce verbosity of print in case packet ingress on invalid port
- Fix mirror Qos settings
- How I did it
Updated SAI version and submodule pointer
- How to verify it
Run regression tests from sonic-mgmt
Signed-off-by: Volodymyr Samotiy <volodymyrs@nvidia.com>
Why I did it
PCIe Gen1 settings was needed for Dell S6000 device.
How I did it
Modified from Gen2 to Gen 1 speed for Dell S6000 PCIe devices
How to verify it
Check lspci output, verify the syslogs
- Why I did it
Change thermal recover threshold from temp_trip_norm to temp_trip_high, so that thermal algorithm would set fan speed to minimum allowed earlier and save power.
- How I did it
Change thermal recover threshold from temp_trip_norm to temp_trip_high
- How to verify it
Manual test
Why I did it
Added support for the device S5224F
How I did it
Implemented the support for the platform S5224F
Switch Vendor: DellEMC
Switch SKU: S5224F-ON
ASIC Vendor: Broadcom
SONiC Image: sonic-broadcom.bin
How to verify it
Verified the show platform/interface commands
Why I did it
Added support for the device N3248PXE
How I did it
Implemented the support for the platform N3248PXE
n3248pxe_unit_test_log.txt
Switch Vendor: DellEMC
* Switch SKU: N3248PXE
* ASIC Vendor: Broadcom
* SONiC Image: sonic-broadcom.bin
How to verify it
Verified the show platform commands
Why I did it
Added support for the device N3248TE
How I did it
Implemented the support for the platform N3248TE
Switch Vendor: DellEMC
Switch SKU: N3248TE
ASIC Vendor: Broadcom
SONiC Image: sonic-broadcom.bin
How to verify it
Verified the show platform commands