#FOSDEM Februari 4, 2017 brabo Insane Adding Machines presents: frosted #FOSDEM Februari 4, 2017 brabo

Free Operating System for tiny embedded devices frosted Free Operating System for tiny embedded devices License: GPL Developed by: Insane adding machines Non-profit development team Research on Free Software for IoT Management platform: github Decentralized Copyleft

Target ARM® Cortex-M® CPU

Target ARM® Cortex-M® CPU

Cortex-M features 32-bit architecture Low power Physical addressing (no MMU) Integrated network Bus: I2C/SPI/UART/USB-OTG Multimedia (DSP) (M4/M7) Accelerated Floating point processing (M4/M7)

Cortex-M software state of the art Baremetal programming Single-threaded Event-loop + IRQ handling “Real-Time” OS Basic support for threads (no process handling) “centralized” IRQ handling No advanced OS features (filesystems, terminals) No multiplexing drivers Cryptic, unique, non portable API No application safety in any case

Embedded Linux Not feasible: Linux is no longer designed for the embedded world Even Non-MMU Linux (uCLinux) has too high resource requirements

Goals POSIX API Allows to port existing *NIX applications and libraries Fast learning process for linux developers Hard Kernel/userspace separation Physical memory segmentation Safe process environment Isolated from kernel Isolated from other processes System and drivers functions exposed via standard syscalls Real Time Ultra Low Power TCP/IP connectivity Free kernel-space code All kernel code is GPL

POSIX Embedded conformance

Components

Flash Kernel code area size is fixed Base applications and shell scripts are compiled as flat binaries and stored into XipFS XipFS gets mounted under /bin at startup

Application code Goal: port ANY *nix executable with no modifications Reality: possibly something is missing Some less-popular calls not yet implemented in libC s/fork/vfork

Application executables In bFLT format (to allow relocation/XiP) Use arm-frosted-eabi-gcc toolchain Compile with: -fPIC -mlong-calls -fno-common -msingle-pic-base -mno-pic-data-is-text- relative Link with: -fPIC -mlong-calls -fno-common -Wl,-elf2flt -lgloss See Userland repository

Context separation Processes execute in their own context No access to supervisor code No access to kernel memory No access to other tasks’ stack Separate stack pointer

System Interrupts

Scheduler Double list (idling, running) Round-robin policy Multiple priority levels Timeslice calculation based on priority Special Real-time priority Voluntary pre-emption (task_suspend) Locks: processes sleep while waiting for semaphore/mutex Real time: task_resume in RT tasks forces immediate scheduling after IRQ events Latency for RT tasks is predictable

Scheduler

Repositories Frosted kernel Kernelspace code Makefile environment to build full system GCC-based Toolchain arm-frosted-eabi Required to compile applications and libraries Common headers System specific API definition (ioctl values, syscall mapping) Frosted-userland Example applications and libraries Unicore-mx Hardware abstraction layer

Repositories and interdependencies (via git-submodules)

Toolchain Build time from sources: 25-50 minutes Periodic binary releases for x86_64 on github Nightly builds available at: http://archive.trexotech.com Why? Built-in libraries to compile applications Automatically resolve system include paths Able to produce “flat” binaries Nice side effect: The toolchain can compile the kernel too No other toolchain is required to build the full system

Kernel configuration If your board has a pre-defined config, use make defconfig TARGET=boardname Run make menuconfig to customize kernel features and supported drivers

Userland configuration Selection of components based on menuconfig Selected apps are archived in a XipFS that will be mounted at startup on /bin When the system starts, /bin/init is executed If /bin/init.sh is present, it will be parsed using the default shell (/bin/fresh)

Compilation Now that frosted is configured, type make to build

Linking and image creation The binaries produced by the build are: kernel.elf: kernel executable in ELF format kernel.img: image version of the kernel Padded up to selected kernel size to be placed at the beginning of the flash apps.img: XipFS image containing the userland programs, generated by frosted-userland image.bin: concatenation of kernel.img and apps.img to facilitate flashing/running

Running on qemu Qemu can emulate a M3 target, based on TI stellaris LM3S, with UART and Ethernet Unfortunately, with only 256KB Flash and 64KB RAM, allowing only basic system We provide a modified qemu with a “tuned” LM3S, closer to nowadays real HW: 1MB Flash 256KB RAM To run on qemu: Compile for LM3S Run “make qemunet”

Continuous integration Code is verified at every commit by Jenkins Build Non-regression tests on real and synthetic (qemu) targets Non-regression tests running on four different boards http://jenkins.trexotech.com

Flashing to target Depending on the target type, one of the following mechanisms must be used to flash the system: If the target supports st-link Run st-flash as indicated If the target has an MBED bootloader: Copy image.bin directly to the USB storage If the target supports DFU format: Image.bin must be converted to .dfu with dfu-utils before transferring it

Thank you! Questions? Comments? http://www.github.com/insane-adding-machines irc.freenode.net / #frosted