Moritz Fischer

After a brief overview of the Linux Kernel FPGA manager framework and it's (short) history, we'll look at what's new with the FPGA Manager framework in the Linux Kernel, what's still missing, outlook on how to fix things, and leave some time for discussion.

We're gonna look at multi-tasking on small Cortex-M class MCUs like the ARM Cortex-M0.

After a brief general overview of the Cortex-M0 programming model, exception handling and other basics required, we'll start our deep-dive into one specific implementation in the Chromium-EC firmware. We'll look at startup code, how tasks are implemented, how to deal with priorities and peripheral interrupts.

The Chromium-EC firmware is a little (RT)OS that runs (mostly) on ARM cores of the Cortex-M class (M0/M3/M4), and powers Google's Chromebooks as well as other devices (Project Sulfur SDR). It's permissive license makes it attractive for (ab)use in other projects, since Kernel and U-Boot integration are already existing.

Google’s chromebooks and routers use off the shelf Microcontrollers (MCU) to do power sequencing, fan control, PWM and other hardware control tasks one typically encounters in embedded systems. Interestingly enough the firmware is available under (3 clause) BSD license and thus open for hacking, abusing and modifying to your needs.

We’ll look at a bunch of MCU options and eval boards to get started with, their availability and pricing in low quantities as well as ways to hook them up to your embedded platform. Moreover we’ll look at hardware level requirements your SoC / board will have to provide in order to make it all work.

We’ll cover existing driver / software support in upstream Linux and U-Boot, as well as parts that are or were missing.

Typical tasks of an embedded controller for a chromebook or random other devices like mine - which is everything but a laptop - will be discussed. Topics covered will include boot selection, firmware upgrades, watchdog timers and others.

Finally I’ll share my experiences building a real world Zynq based system using chromium-ec on an STM32 MCU and my experiences adapting the software to my needs and interacting with the community. Examples include replacing the coreboot bootflow with U-Boot, creating device drivers for things like buttons and issues encountered in making things work.

So you created your cool SDR app on your desktop PC, awesome! How do you port it to an embedded SDR?

Using a Yocto / OE based toolflow we'll walk through a couple of simple examples on how to cross compile your applications & efficiently deploy them to an embedded SDR.

FPGA Manager & devicetree overlays - Making FPGAs first class citizens in the upstream Linux Kernel

Static System on Chip (SoC) configurations commonly found in today's embedded systems can be easily described by devicetree files. These files provide the kernel with the necessary information about hardware devices, their connections, clocks, resets and other properties that could be either runtime probed, or would be provided by the BIOS on normal PC systems.

FPGAs have been present in embedded systems for a long time. Their reconfigurability allows for in-the-field upgrades to large parts of a system's functionality. For this kind of reconfigurability it is sufficient to reload the FPGA image once at boot, and to present the peripherals in the programmable logic parts to the Linux Kernel in the same way as any other hardware.

With FPGA based SoCs such as Altera's SocFPGA and Xilinx Zynq this model of reconfiguration poses its challenges, as runtime reconfiguration (and even partial reconfiguration) may cause parts of the fabric-based logic to temporarily (or permanently!) disappear. In that case presenting the FPGA based logic to the kernel might lead to issues as the corresponding device drivers don't get unloaded properly when the corresponding logic goes away.

Vendor trees (that contain modifications to the Linux Kernel, that have not been upstreamed) provide userland applications with a capability to reload the FPGA image. In this case a hybrid system with in kernel drivers and userland applications is quickly forced into using ugly hacks to make it all work together.

FPGA manager is a vendor-neutral framework currently under development (will be in 4.4), that allows reloading FPGA images in a safe, clean and intuitive manner, while nicely integrating with the Linux Kernel's driver model.

To model the dependencies of FPGA based IP in processor based SoC's the SimpleFPGA bus was developed. It allows to specify dependency topologies to reconfigure SoC busses at runtime, while dealing with issues such as runtime clock control, resets, as well as loading the correct (partial) bitstreams through FPGA Manager.

Originally developed to support the BeagleBone Black's capes that require runtime pinctrl, devicetree overlays can be used to change the Linux Kernel's representation of the devicetree at runtime. Recently merged into upstream devicetree overlays provide a very natural and clean way to describe modifications to the devicetree, while keeping the whole system in a coherent state.

This talk will give a brief intro to devicetree, the problems related to runtime reconfiguration and then describe the SimpleFPGA bus and FPGA Manager frameworks. Some simple examples using devicetree overlays will be given that will demonstrate why the three elements make for such a compelling combination.

Although some of the currently available SDRs come with means of adding FPGA based acceleration to boost performance, almost nobody is making use of them. One of several reasons for that is, that the learning curve is quite steep for a beginner.

This talk will briefly describe a way to add hardware acceleration to Zynq based SDRs, that has already been successfully used in Jonathon Pendlum's GSoC project.

I'll give an overview of where we are at the moment, what the development experience right now is like, what parts are still missing, and what I'm planning on adding.