Accessing Broadcom SDK
It’s no secret that gaining access to the Broadcom SDK is challenging. Broadcom is notoriously secretive and restrictive, making it difficult for researchers or small development teams to start a project.
There is the OpenBCM repository, but it’s read-only and has’t been updated in years. Plus, it misses some critical components to run on Trident4 series.
However, there is no limit to a researcher’s ingenuity and curiosity.
Timon Krack at the Karlsruhe Institute of Technology has found a workaround. Feel free to contact him at timon.krack@kit.edu
What uses a relatively fresh SDK package, is open, and is supported by hardware vendors?
It’s SONiC!
We’ll share his findings on how to run custom code directly on the Trident4 with step-by-step instructions and an example.
Step by Step
Install SONiC
Since the system under test is Aurora 830, Netberg SONiC 202411.n0 was deployed (sonic-broadcom-202411.n0.bin)
apt update
| apt update may fail due to a “not yet valid” certificate. This is because the date is wrong and needs to be updated upon the start. |
To fix, add the NTP servers. A different one can be added here.
# config ntp add 2a00:1398::c:1
# config ntp add 2a00:1398::c:2
# ntpdate -s 2a00:1398::c:2
Install some utility packages and compiler
# sudo apt install binutils g++ cmake libthrift-dev make thrift-compiler libboost1.74-dev lz4 nano htop unzip
The example
Download sonic_td4_netbergExample from this link, unzip and enter the “netbergExample” directory.
Download and install the SAI development libraries. For instance, this can be done by running the “downloadSaiDev.sh” script, which automatically searches SONiC’s files to identify the version in use and downloads it from SONiC’s repositories.
After downloading the files, in my case libsaibcm-dev_12.3.6.2_amd64.deb and libsaibcm_12.3.6.2_amd64.deb, install them using “apt install ./libsai*.deb”
Disable SONiC components
Using SONiC Feature control, we stop SONiC’s components that currently run the SDK instance internally.
Run:
sudo config feature state swss enabled
sudo config feature state syncd enabled
Run the example
As described by Timon:
Compile (chmod +x compile.sh; ./compile.sh) and run (./netbergExample) the example application. A pre-built binary is available at ./netbergExample
After initializing the SDK, it will drop you into a Broadcom shell.
We can run any command here, including “cint file.cint” to run a CINT script, or “bsh” to enter the SDKLT-shell.
I included an example CINT script, start with “cint example.cint”. Turns out, the bcm_field_… API can still be used – I checked, they map it internally to the new SDKLT API.
Of course, the new functions like bcmlt_entry_allocate… etc. are equally available.
As a bit of additional context how this works:
SONiC uses the Switch Abstraction Interface (SAI); which is implemented by Broadcom using their SDK. The SAI binaries include the Broadcom SDK binaries. If we link SAI, we therefore also
link the SDK in the C++ application. I first use normal SAI commands to initialize the SDK. Then, you notice these lines:
extern “C” {
extern int sh_process_command(int u, char *c) __attribute__((weak));
}
This declares a function that is only contained in the Broadcom SDK. The linker will find it automatically at runtime. This function processes commands entered in the Broadcom shell, which I simulate with a simple command line.
This can be done with any function, including bcm_… and bcmlt_…
It is also possible to just include the header files from a older version of the SDK / SDKLT and use all of the functions directly in the C code. I did not include that in this example.
Functions added or modified since the latest version available publicly cannot be used like this; however, I found that to be very rare. I was able to do everything I needed with the
older header files; I think most of the changes are internal and not to the API.
For any questions, feel free to contact <timon.krack@kit.edu>