DSA in Barebox
The v2022.05.0 Release of barebox introduced initial support for the Distributed Switch Architecture (DSA) Framework. DSA is originally a subsystem from the Linux Kernel, which exposes the individual ports of a network switch IC as virtual network interfaces.
Switches on Embedded Devices
On many embedded devices, switches solve a common issue: many embedded applications require multiple Ethernet ports on a device, e.g. for redundant data connection, or to interface to multiple other devices. Since many SoCs have only a single Ethernet controller, switch ICs are used to multiplex the multiple network ports to the on-SoC Ethernet controller.
While for some applications forwarding packets between the external ports may be acceptable or even desirable, some applications need the external network ports to behave such as if they were connected to different network controllers. This implies that the ports are isolated one from another and traffic is not forwarded, but all traffic is sent to the SoC only.
Switch Support in a Bootloader
Especially kernel developers prefer network boot for loading new kernel or device-tree images to an embedded board. Not having to flash them on a storage medium saves some more time, but the most important speedup can be gained by just mounting the root file system over NFS instead of flashing an image with several MB to a storage device. After a rebuild, all that is required to use the new images is just a reboot of the device under test. In an earlier blog article we described how this helps developers to get close-to-instant turnaround times for testing code changes on embedded devices.
While DSA was introduced in the kernel quite some time ago, handling switches in barebox was quite cumbersome until DSA support was merged. Previously, custom board code was required to configure the different ports to whatever modus is required during boot. Now, it is possible to just configure IP addresses on the individual ports and call boot net from the barebox shell, which tries any available interface to find a server for booting.
Synergy from Porting the Subsystem
Because the barebox DSA subsystem is ported from Linux, it uses the same internal data structures and facilities. This allows reusing kernel device-tree descriptions of on-board switches for the switch setup in barebox as well. Also, porting DSA drivers from the kernel to barebox is simplified by the fact that the code shares all important data structure definitions.
This shows off one of the unique advantages of barebox: because its driver model adheres strongly to the Linux driver model, porting device drivers is as easy as can be, with only minor adjustments now and then.
Already supported are the Microchip KSZ8873, KSZ9477 and KSZ8873 and their compatible variants as well as the NXP SJA1105, for which the manufacturers have provided open documentation, which is still quire rare for network switch ICs. Support for Realtek rtl8365mb and rtl8366rb is on the way and will land upstream soon.
Unexpected Applications in the Wild
While network-booting embedded boards with switches was originally intended as a feature to speed up development in our daily work, some of our customers have found interesting applications of the possibilities offered by easily setting up network ports as network devices with DSA in barebox.
With DSA enabled, the switch can easily be configured as desired in a very early stage of the boot process. Even if the boot process should stall or stop at a later stage, this means that e.g. ports set to isolation mode won't leak any traffic to other network ports, which can reduce the attack surface and therefore increase security.
Improving Network Bandwidth
DSA works by adding so-called DSA-tags to network packets, which are a few bytes with information on which Ethernet port of the switch the packet shall exit the device. As kernel protocol stacks are usually optimized to work directly on physical network interfaces, adding these tags can cause quite some overhead and therefore limit the usable network bandwidth, on some platforms even by 50%. Configuring a switch in barebox and completely disabling DSA in the kernel is for sure not a solution which fits all use-cases, but for some it can work out quite well and avoid this overhead in the Linux system.
Initial Factory Bring-up
Last but not least, some of our customers use the DSA support in barebox for chain-loading a bring-up Linux image in their production line, which can then load the actual production image via the network and flash it onto a local storage medium in the device to be provisioned. As barebox can now easily configure the switch, the default bootloader and devicetree can be used for this task, avoiding the need for a custom image and configuration just for initial device bring-up.
Have you ever experienced an otherwise fine product that is missing just the one feature you need for your application?
So you went and got yourself one of our fancy rocket-penguin branded CandleLight dongles or, being the die hard hacker you are, went and soldered one up in your toaster oven labeled "not food safe". What's next then? How do you use this thing? Let's answer these question by grabbing a Raspberry Pi and exploring some of the possibilities.
End of January systemd 250 was added to Debian bullseye backports. With a lots of new features and fixes now comes the possibility to set the timing of CAN bus interfaces with systemd-networkd. In this blogpost I will take a look at why this helps us maintain our embedded Linux labs.
The Arria10 SoCFPGA can boot from multiple sources: SD Card, NAND flash, QSPI flash and eMMC, that can be selected via the BSEL pins. If the bootrom can not find a valid bootloader on that medium, it will fall back to JTAG. So for developing and testing, the BSEL pins can just be set to a medium that is non-existent. In case of bootstrapping, the bootrom falls back to JTAG anyway, as there is no valid bootloader, yet.
One of our projects required the addition of board support for the Digi ConnectCore 6UL SBC Pro to the Barebox bootloader. This article outlines the used development setup and required additions to the bootloader to support a board with a well supported processor. Development of the board support was done live during the monthly talks at Stratum 0, the hackerspace in Braunschweig. The video (in German) is embedded at the end of the article.