Open Network Linux has a number of internal APIs to simplify porting to new hardware.
To support a new switch/device, there are three large software components that need device-specific drivers (information only known by the manufacturer of the switch/device):
ONL provides plugable driver modules for (1) and (2) but currently provides no support for (3).
The rest of this PortingGuide is divided into two parts: (1) creating the ONIE installer driver and (2) creating the ONLP platform driver.
ONIE (the Open Network Installation Environment - http://onie.org) is a small piece of software that ONL expects to exist on every switch, pre-installed by the switch vendor. ONIE provides the installation and management utilities to install/uninstall/rescue a Network Operating System (a "NOS") like ONL. While ONIE is a stand alone operating system in its own right, it is intentionally stripped down and has few features outside of the bare minimum needed to bootstrap a system and invoke an NOS installer program.
ONL has an ONIE-compatible installation script called the 'ONL Installer'. That is, the ONL installer is a device-specific self-extracting shell script that, when run from ONIE, partitions available storage, installs the ONL switch image file (SWI) on to disk, and sets up the underlying boot loader (e.g., uboot or grub) with the appropriate settings so that on boot, by default, ONL loads correctly on the device. So, to port ONL to a new switch, a number of installer drivers, including for disk partitioning, installation, booting, and python integration need to be written.
TL; DR :: If you want to just jump to the code, look at the drivers in $ONL/packages/platforms/$vendor/$platform/platform-config/r(0|1)/* -- in particular, the powerpc-as5710-54x-r0b driver is a good example. Copy the directory/file layout and naming conventions and see how the driver code is called from $ONL/builds/powerpc/installer/legacy/builds/ppc-installer.sh
All the installer drivers are stored in $ONL/packages/platforms/$vendor/$platform/platform-config, where $platform corresponds to the ONIE platform identifier string and $vendor is the name of the platform vendor e.g. accton, quanta, wnc. This string is used to identify which set of drivers to load (ONL supports many systems) at boot time and is critical that it matches the ONIE identifier exactly. The rest of the directory structure for the installer driver is as follows:
./$platform/$release/
./$platform/$release/Makefile # copy from existing driver
./$platform/$release/src/lib/boot/detect.sh # Script that returns 0 if run on $platform, 1 otherwise
./$platform/$release/src/lib/boot/$platform # Script run on boot that populates device/hardware
# specific ONL OS abstractions (see below)
./$platform/$release/src/lib/install/$platform.sh # Script called from installer.sh to partition
# and install ONL and setup boot params (see below)
./$platform/src/python/$platform/__init__.py # Platform specific python library (see below)
The $platform/src/lib/boot/$platform script is in charge of writing the ONL boottime hardware abstraction configuration. Because each device has a different storage driver, storage device, management network device, etc., ONL uses a series of config files to map the specific hardware (an ethernet driver) to a device-agnostic form (e.g., primary management interface).
The following files need to be populated by the $platform boot script:
The $platform/src/lib/install/$platform.sh driver is called from the main installer script and has the job of: 1) Identifying and partitioning the device specific storage 2) Deciding the file format of the target boot partition to install the ONL loader image 3) Deciding how to update the bootloader, e.g., in the case of uboot, what the $nos_bootcmd variables should be.
The contents of this driver are sourced into the installer.sh and so the variables and functions are called in various places. There are an excess of ways that switches can be built (what storage types, etc.) and how they boot, so seading the installer.sh code along with the example platform driver code seems to be the best bet here -- FIXME!
For example, looking at the driver
$ONL/packages/platforms/accton/powerpc-accton-as5710-54x/platform-config/r0b/src/lib/install/powerpc-as5710-54x-r0b.sh
the driver first sets "platformloaderraw=1" which tells the
installer that the boot partition has no file format (as opposed
to ext2fs or fat - it is type 'raw'). Then it has the platform_bootcmd as:
platform_bootcmd='usb start; usbboot 0x10000000 0:1; setenv bootargs console=$consoledev,$baudrate onl_platform=powerpc-as5710-54x-r0b; bootm 0x10000000'
Which is a string of uboot commands, that:
The sequence of exact boot commands will vary with version of uboot (or other boot loader), available storage, and other device specific properties.
Every new networking switch/router/box has a unique layout of which devices (fans, power supplies, LEDs, SFP/SFP+/QSFP, temperature sensors, etc.) connect to which I/O devices (I2C, GPIO, etc.) and how they are managed (FPGA, CPLD). Rather than mandate one hardware approach or assume that there exists a BIOS to take care of this work for us (some platforms have a BIOS, some do not; some drivers are not supported by BIOS), ONL has created an abstraction layer to inventory, manage, and monitor these devices.
If you want to create an application in ONL that builds on top of the platform, the "application to platform" APIs are found in:
$ONL/packages/base/any/onlp/src/onlp/module/inc/onlp
See http://onlp.dev for more information