July 2, 2020 | 2:00 – 3:30 pm Registration Fees: Complimentary to all OSS+ELC NA Attendees
Join us to learn more about the leading Open Source RTOS built with safety and security in mind. Attendees will learn why Zephyr is gaining the attention of developers, with its support for BLE, OpenThread, LTE-M/NB-IoT cellular communications, and more.
Zephyr overview – John Round, NXP
Intro to West – Marti Bolivar, Nordic Semiconductor
Overview of Bluetooth – Martin Woolley, Bluetooth
Security Issues – David Brown, Linaro
Safety Certification – Kate Stewart, The Linux Foundation
Use Case – Michael Gielda, Antmicro
How to Register: Pre-registration is required. To register for Zephyr Mini-Summit, add it on to your Open Source Summit + Embedded Linux Conference North America registration.
Written by Colin Riley, an Engineer and Writer at Domipheus Labs
This part of a series of posts detailing the steps and learning undertaken to design and implement a CPU in VHDL. You can find more articles from Colin on his blog via http://labs.domipheus.com/blog/. To read more from this series, click here.
For those who follow me on twitter, you’ll have seen my recent tweets regarding Zephyr OS running on RPU. This was a huge amount of work to get running, most of it debugging on the FPGA itself. For those new to FPGA development, trying to debug on-chip can be a very difficult and frustrating experience. Generally, you want to debug in the simulator – but when potential issues are influenced by external devices such as SD cards, timer interrupts, and hundreds of millions of cycles into the boot process of an operating system – simulators may not be feasible.
Blog posts on the features I added to RPU to enable Zephyr booting, such as proper interrupts, exceptions and timers are coming – but it would not have been possible without a feature of the RPU SoC I have not yet discussed.
Most real processors will have hardware features built in, and one of the most useful low-level tools is tracing. This is when at an arbitrary time slice, low level details on the inner operation of the core are captured into some buffer, before being streamed elsewhere for analysis and state reconstruction later.
Note that this is a one-way flow of data. It is not interactive, like the debugging most developers know. It is mostly used for performance profiling but for RPU would be an ideal debugging aid.
For the avoidance of doubt; I’m defining “A Trace” to be one block of valid data which is dumped to a host PC for analysis. For us, dumping will be streaming the data out via UART to a development PC. Multiple traces can be taken, but when the data transfer is initiated, the data needs to be a real representation of what occurred immediately preceding the request to dump the trace. The data contained in a trace is always being captured on the device in order that if a request is made, the data is available.
These requirements require a circular buffer which is continually recording the state. I’ll define exactly what the data is later – but for now, the data is defined as 64-bits per cycle. Plenty for a significant amount of state to be recorded, which will be required in order to perform meaningful analysis. We have a good amount of block rams on our Spartan 7-50 FPGA, so we can dedicate 32KB to this circular buffer quite easily. 64-bits into 32KB gives us 4,096 cycles of data. Not that much you’d think for a CPU running at over 100MHz, but you’d be surprised how quickly RPU falls over when it gets into an invalid state!
It goes without saying that our implementation needs to be non-intrusive. I’m not currently using the UART connected to the FTDI USB controller, as our logging output is displayed graphically via a text-mode display over HDMI. We can use this without impacting existing code. Our CPU core will expose a debug trace bus signal, which will be the data captured.
We’ve mentioned the buffer will be in a block ram; but one aspect of this is that we must be wary of the observer effect. This issue is very much an issue for performance profiling, as streaming out data from various devices usually goes through memory subsystems which will increase bandwidth requirements, and lead to more latency in the memory operations you are trying to trace. Our trace system should not effect the execution characteristics of the core at all. As we are using a development PC to receive the streamed data, we can completely segregate all data paths for the trace system, and remove the block ram from the memory mapped area which is currently used for code and data. With this block ram separate, we can ensure it’s set up as a true dual port ram with data width the native 64bit. One port will be for writing data from the CPU, on the CPU clock domain. The second port will be used for reading the data out at a rate which is dictated by the UART serial baud – much, much, slower. Doing this will ensure tracing will not impact execution of the core at any point, meaning our dumped data is much more valuable.
Lastly, we want to trigger these dumps at a point in time when we think an issue has occurred. Two immediate trigger types come to mind in addition to a manual button.
Comparison with the data which is to be dumped; i.e, pipeline status flags combined with instruction types.
The implementation is very simple. I’ve added a debug signal output to the CPU core entity. It’s 64 bits of data consisting of 32 bits of status bits, and a 32-bit data value as defined below.
This data is always being output by the core, changing every cycle. The data value can be various things; the PC when in a STAGE_FETCH state, the ALU result, the value we’re writing to rD in WRITEBACK, or a memory location during a load/store.
We only need two new processes for the system:
trace_streamout: manages the streaming out of bytes from the trace block ram
trace_en_check: inspects trigger conditions in order to initiate a trace dump which trace_streamout will handle
The BRAM used as the circular trace buffer is configured as 64-bits word length, with 4096 addresses. It was created using the Block Memory Generator, and has a read latency of 2 cycles.
We will use a clock cycle counter which already exists for dictating write locations into the BRAM. As it’s used as a circular buffer, we simply take the lower 12 bits of the clock counter as address into the BRAM.
Port A of the BRAM is the write port, with it’s address line tied to the bits noted above. It is enabled by a signal only when the trace_streamout process is idle. This is so when we do stream out the data we want, it’s not polluted with new data while our slow streamout to UART is active. That new data is effectively lost. As this port captures the cpu core O_DBG output, it’s clocked at the CPU core clock.
Port B is the read port. It’s clocked using the 100MHz reference clock (which also drives the UART – albeit then subsampled via a baud tick). It’s enabled when a streamout state is requested, and reads an address dictated by the trace_streamout process.
The trace_streamout process, when the current streamout state is idle, checks for a dump_enable signal. Upon seeing this signal, the last write address is latched from the lower cycle counter 12 bits. We also set a streamout location to be that last write +1. This location is what is fed into Port B of the BRAM/ circular trace buffer. When we change the read address on port B, we wait some cycles for the value to properly propagate out. During this preload stall, we also wait for the UART TX to become ready for more data. The transmission is performed significantly slower than the clock that trace_streamout runs at, and we cannot write to the TX buffer if it’s full.
The UART I’m using is provided by Xilinx and has an internal 16-byte buffer. We wait for a ready signal as then we know that writing our 8 bytes of debug data (remember, 64-bit) quickly into the UART TX will succeed. In addition to the 8 bytes of data, I also send 2 bytes of magic number data at the start of every 64-bit packet as an aid to the receiving logic; we can check the first two bytes for these values to ensure we’re synced correctly in order to parse the data eventually.
After the last byte is written, we increment our streamout location address. If it’s not equal to the last write address we latched previously, we move to the preload stall and move the next 8 bytes of trace data out. Otherwise, we are finished transmitting the entire trace buffer, so set out state back to idle and re-enable new trace data writes.
Triggering a dump using dump_enable can be done a variety of ways. I have a physical push-button on my Arty S7 board set to always enable a dump, which is useful to know where execution currently is in a program. I have also got a trigger on reading a certain memory address. This is good if there is an issue triggering an error which you can reliably track to a branch of code execution. Having a memory address in that code branch used as trigger will dump the cycles leading up to that branch being taken. There are one other types of trigger – relying on the cpu O_DBG signal itself, for example, triggering a dump when we encounter an decoder interrupt for an invalid instruction.
I hard-code these triggers in the VHDL currently, but it’s feasible that these can be configurable programmatically. The dump itself could also be triggered via a write to a specific MMIO location.
Parsing the data on the Debug PC
The UART TX on the FPGA is connected to the FTDI USB-UART bridge, which means when the FPGA design is active and the board is connected via USB, we can just open the COM port exposed via the USB device.
I made a simple C# command line utility which just dumps the packets in a readable form. It looks like this:
I have also been working on a rust-based GUI debugger for these trace files, where you can look at known memory (usually the stack) and register file contents at a given packet by walking the packets up until the point you’re interested in. It was an excuse to get to know Rust a bit more, but it’s not completely functional and I use the command line C# version more.
The easiest use for this is the physical button for dumping the traces. When bringing up some new software on the SoC it rarely works first time and end up in an infinite loop of some sort. Using the STAGE_FETCH packets which contain the PC I can look to an objdump and see immediately where we are executing without impacting upon the execution of the code itself.
Using the data to debug issues
Now to spoil a bit of the upcoming RPU Interrupts/Zephyr post with an example of how these traces have helped me. But I think an example of a real problem the trace dumps helped solve is required.
After implementing external timer interrupts, invalid instruction interrupts, system calls – and fixed a ton of issues – I had the Zephyr Dining Philosophers sample running on RPU in all it’s threaded, synchronized, glory.
Why do I need invalid instruction interrupts? Because RPU does not implement the M RISC-V extension. So multiply and divide hardware does not exist. Sadly, somewhere in the Zephyr build system, there is assembly with mul and div instructions. I needed invalid instruction interrupts in order to trap into an exception handler which could software emulate the instruction, write the result back into the context, so that when we returned from the interrupt to PC+4 the new value for the destination register would be written back.
It’s pretty funny to think that for me, implementing that was easier than trying to fix a build system to compile for the architecture intended.
Anyway, I was performing long-running tests of dining philosophers, when I hit the fatal error exception handler for trying to emulate an instruction it didn’t understand. I was able to replicate it, but it could take hours of running before it happened. The biggest issue? The instruction we were trying to emulate was at PC 0x00000010 – the start of the exception handler!
So, I set up the CPU trace trigger to activate on the instruction that branches to print that “FATAL: Reg is bad” message, started the FPGA running, and left the C# app to capture any trace dumps. After a few hours the issue occurred, and we had our CPU trace of the 4096 cycles leading up to the fatal error. Some hundreds of cycles before the dump initiated, we have the following output.
What on earth is happening here? This is a lesson as to why interrupts have priorities 🙂
I’ve tried to reduce the trace down to minimum and lay it out so it makes sense. There are a few things you need to know about the RPU exception system which have yet to be discussed:
Each Core has a Local Interrupt Controller (LINT) which can accept interrupts at any stage of execution, provide the ACK signal to let the requester know it’s been accepted, and then at a safe point pass it on to the Control Unit to initiate transfer of execution to the exception vector. This transfer can only happen after a writeback, hence the STALL stages as it’s set up before fetching the first instruction of the exception vector at 0x00000010. If the LINT sees external interrupts requests (EXT_INT – timer interrupts) at the same time as decoder interrupts for invalid instruction, it will always choose the decoder above anything – as that needs immediately handled.
And here is what happens above:
We are fetching PC 0x00000328, which happens to be an unsupported instruction which will be emulated by our invalid instruction handler.
As we are fetching, and external timer interrupt fires (Packet 01)
The LINT acknoledges the external interrupt as there is no higher priority request pending, and signals to the control unit an int is pending LINT_INT (Packet 2)
As we wait for the WRITEBACK phase for the control unit to transfer to exception vector, PC 0x00000328 decodes as an illegal instruction and DECODER_INT is requested (Packet 5)
LINT cannot acknowledge the decoder int as the control unit can only handle a single interrupt at a time, and its waiting to handle the external interrupt.
The control unit accepts the external LINT_INT, and stalls for transfer to exception vector, and resets LINT so it can accept new requests (Packet 7).
We start fetching the interrupt vector 0x00000010 (Packet 12)
The LINT sees the DECODE_INT and immediately accepts and acknowledges.
The control unit accepts the LINT_INT, stalls for transfer to exception vector, with the PC of the exception being set to 0x00000010 (Packet 20).
Everything breaks, the PC get set to a value in flux, which just so happened to be in the exception vector (Packet 25).
In short, if an external interrupt fires during the fetch stage of an illegal instruction, the illegal instruction will not be handled correctly and state is corrupted.
Easily fixed with some further enable logic for external interrupts to only be accepted after fetch and decode. But one hell is an issue to find without the CPU trace dumps!
So, as you can see, trace dumps are an great feature to have in RPU. A very simple implementation can yield enough information to work with on problems where the simulator just is not viable. With different trigger options, and the ability to customize the O_DBG signal to further narrow down issues under investigation, it’s invaluable. In fact, I’ll probably end up putting this system into any similarly complex FPGA project in the future. The HDL will shortly be submitted to the SoC github repo along with the updated core which supports interrupts.
Open Source Summit North America, which takes place on June 29-July 2, will take place as a virtual event for the first time ever this year. OSS NA is the leading conference for developers, architects, and other technologists – as well as open source community and industry leaders – to collaborate, share information, learn about the latest technologies and gain a competitive advantage by using innovative open solutions.
The Zephyr Project will be featured in several sessions including:
Monday, June 29:
11:30 am – 12:20 pm: IoT Root of Trust – Knowing Who We are and Who to Trust – David Brown, Linaro
When an IoT device connects to the cloud, how do we know it is a device we should trust? How do we know the device is running the intended firmware. How does the device know that it can trust the cloud service? How does the lifecycle of a device affect its identity. The bootloader plays a key role in establishing this trust.
In this presentation, David Brown will cover the notion of trust and identity as it relates to the initial bootloader. What is meant by “root of trust”. The talk will cover various aspects of identity, including: secure boot, attestation, device identity, and provisioning. Although MCUboot will be used for specific examples, the presentation is generally applicable. Add it to your schedule here.
Tuesday, June 30:
11:15 am – 1:05 pm: (Tutorial) Zephyr RTOS juicy features using simple evaluation boards and robots – Maksim Masalski, Intel
During that tutorial Maksim will give introduction into Zephyr RTOS and its features using inexpensive educational microcomputers initially designed to involve kids into the world of the programming. This way developers and makers can easily start development of the hardware IoT prototypes powered by Zephyr RTOS. Maksim will describe powerful features of the open-source Zephyr RTOS and will demonstrate them using development boards and robots. After the tutorial, attendees will know more about Zephyr RTOS, will know more about Bluetooth Mesh, what applications can use Zephyr and how they can start using Zephyr for their IoT project development with help of the vast open-source community. Add it to your schedule here: https://sched.co/c3VP
Wednesday, July 1:
9:00 – 9:20 am: (Keynote) Open Source in Safety Critical Applications: The End Game – Kate Stewart, Senior Director of Strategic Programs at the Linux Foundation
The last 20 years have seen a tremendous surge of new technologies and capabilities emerge from open source software. Open source building blocks have become increasingly attractive as the base for innovative new products. Safety critical applications are now starting to consider using them as well. This talk will look at some of the challenges and approaches to building trust and confidence in open source used in safety critical software coming to new products near you… or perhaps, even in you. Add this to your schedule: https://sched.co/c3ZE
Zephyr devices can be connected in two possible (direct and in-direct) ways to the internet. Directly using Modem/WiFi/Ethernet medium or in-directly via local radio through Gateways like Linux. Upgrading such Zephyr system in the field is a complex task and must be robust, secure.
This talk will details various possible update solutions available like UpdateHub, Hawkbit, SWUpdate for Zephyr. Using a NXP FRDM-K64F board as an example, we will discuss and demo different possible ways for updating Zephyr system. Add this to your schedule: https://sched.co/c3St
2:35 – 3:25 pm: Managing the Wind – Remote management for Zephyr devices with LwM2M – Frederic Desbiens, Eclipse Foundation
LightweightM2M (LwM2M) by OMA SpecWorks is a device management protocol designed for sensor networks and the demands of a machine-to-machine (M2M) environment. It is designed for the remote management of devices and is based on the Contrained Application Protocol (CoAP, RFC 7252), which itself provides an interaction model similar to the client/server model of HTTP.
The Zephyr RTOS from the Linux Foundation possesses built-in support for LwM2M. In this presentation, you will discover how to leverage LwM2M to manage Zephyr-based devices. You will understand the pros and cons of using Zephyr’s built-in LwM2M client. You will also learn about various LwM2m servers, including the Eclipse Leshan open source project, which you can use to build your own LwM2M management server. Add this to your schedule: https://sched.co/c3X0
Kate Stewart, Senior Director of Strategic Program at The Linux Foundation, will be on-site at the LF Member Summit on Tuesday, March 10 – Thursday, March 12 at Lake Tahoe, California. Kate will give a few talks, most notably about “Open Source in Safety Critical Applications.”
This talk will look at some of the challenges and approaches to building trust and confidence in open source used in safety critical software coming to new products near you… or perhaps, even in you. Add this to your schedule here. https://sched.co/a8cB
This blog originally ran on the Antmicro website. For more Zephyr development tips and articles, please visit their blog.
Zephyr Project member Antmicro helps its customers build advanced, modular, software-centric, edge to cloud AI systems backed by a sound, open-source-driven methodology. With so much momentum in open digital design happening not only in the US but globally, we’re not wasting any second of it; and traditionally, the forthcoming Embedded World 2020 in Nuremberg, Germany, between February 25-27, provides a great opportunity to meet with European partners, customers and like-minded people interested in our technologies.
Over the years Antmicro has been at the forefront of the FPGA SoC technology, designing effective high-speed signal platforms for edge computing (especially in CV/MV multi-camera applications). Coupled with end-to-end services of writing FPGA IP, AI/camera processing, BSPs and drivers (Linux, Zephyr), we are uniquely positioned to leverage open FPGA development workflows, tools and languages such as Chisel and Migen.
Antmicro’s Zynq Video Board is a smart piece of open hardware for image processing with an open FPGA MIPI CSI-2 IP core for grabbing video streams. Fully open source, the board features HDMI, Ethernet, and SD card support, and will use Xilinx Zynq (or other Enclustra FPGA SoMs) to allow interfacing up to two 2-lane MIPI CSI-2 cameras. Fittingly, the camera sensors are controlled by Zephyr RTOS (see and learn more at booth #4-170) running on a VexRiscV RISC-V softcore written in LiteX, a likewise open source SoC generator.
What is perhaps even more exciting, at the recent RISC-V Summit Antmicro unveiled its rapid turnaround chiplet-based ASIC series, GEM. Utilizing zGlue’s smart ASIC SiP development tech (#4A-364), Antmicro engineers are now capable of creating full-blown custom hardware within a practical, quick-prototyping / quick-tape-out process, employing all the benefits of modern open digital design. In Nuremberg, we will be showing the GEM series in the context of our OSHW development services (baseboard, modules), BSP development (GEM running Zephyr on a Raven RISC-V soft CPU), FPGA development (GEM built around two Lattice iCE40 FPGAs) and AI development (live video analysis in Lattice iCE40 with a neat MIPI CSI-2 switch for on-the-fly re-routing to the camera), demonstrating a complete overview of our design approach.
Advanced edge AI systems
Thanks to innovative edge computing platforms (be it GPGPU-, FPGA- or heterogeneous CPU-based) and custom ASIC accelerators, Deep Learning has been making its way to new use cases, with Antmicro’s in-depth competence spanning all of these areas.
An outstandingly successful use case in the civil defence area has been that of the SkyWall Auto, a world-first automatic counter-drone system for which Antmicro has developed the identification and tracking module. SkyWall Auto has already proven its ability to physically capture drones in front of US military and government agencies during recent high-profile tests, successfully engaging multi-rotor and fixed-wing targets during a range of scenarios. This solution, based on specially trained neural networks to enable AI-driven capture of trespassing drones, will be another highlight of our booth this year.
Another example of our scalable design approach featured here will be a high-speed industrial stereovision camera platform for AI-supported 3D vision processing in real time. Comprising a stereovision camera module based on Antmicro’s UltraScale+ Processing Module, and our own TX2 Deep Learning baseboard for object tracking, detection and classification, the device is a modular concept that can be easily expanded or adapted to larger industrial systems, such as the X-MINE smart mining project we’ve been participating in.
What helps us achieve high quality and offer effective scalability in our edge AI solutions is our open Renode simulation framework, and the practices of Continuous Integration / Continuous Development available in the Renode Cloud Environment, which allow us to perform reproducible builds, mitigate the black box effect and ensure traceability of the software stack. At this year’s show, see how we use our custom CI setups deployed in RCE with a broad list of demonstrator tests. Renode’s capability to co-simulate SoC and FPGA components with Verilator, or to connect blocks running in physical eFPGAs to enable a “divide-and-conquer” HW/SW co-design philosophy, resonates perfectly with the hybrid SoC FPGA nature of the EOS S3 platform we’ll be showing as well (read more below).
Open source software/BSP and hardware development
Our presence at EW 2020 will naturally revolve around non-proprietary software and hardware as we strongly believe that open source is changing the world of tech for the better by making useful tools accessible, transparent and easily modifiable. Also, the lack of vendor lock-in gives us and our customers the freedom to develop solutions based on the best technologies available.
We’re happy to see more of our customers make use of our open source-oriented vision and the new design methodologies we promote. Antmicro has recently added a Zephyr port to QuickLogic’s Quick Feather development board for the EOS S3 and the soon-to-be-released addition to the open source Tomu tiny USB family of devices, nicknamed Qomu – both of which will be showcased by Antmicro at EW 2020. The EOS S3 is now also supported in Antmicro’s Renode open source simulation framework for rapid prototyping, development and testing of multi-node systems, offering a more efficient hardware/software co-design approach to Zephyr developers. You can see this support, as well as other Renode demos, in action at our booth.
We are very excited to be coming back to Embedded World with a range of captivating technology demonstrators. The Antmicro team can’t wait to meet you, so visit us in Hall 4A-621 or schedule a meeting beforehand at email@example.com, and let’s talk tech!
Linaro Connect Budapest 2020 will take place on March 23-27 at the Corinthia Hotel in Budapest, Hungary. There are several Zephyr sessions planned by Zephyr Project members and community contributors. Please see the schedule below.
On Monday, March 23:
At 2:30-2:55 pm, Vincent Wan, Embedded Software Engineer for Texas Instruments, will present Power Management in Zephyr. He’ll showcase the current state of power management in the Zephyr RTOS, using a TI MCU platform as a case study. It goes over the current features, the steps involved in adding support for a new platform, and on-going development. Add it to your schedule here.
At 3-3:25 pm, Manivannan Sadhasivam, Kernel Engineer for Linaro, will give a talk about LoRa (Long Range) meeting Zephyr. LoRa (Long Range) is a low power wireless technology targeted for IoT applications. LoRa enables long-range transmissions (more than 10 km in rural areas) with low power consumption through the Chirp spread- spectrum modulation technique. There are multiple attempts from the community for adding LoRa support to Zephyr RTOS. This session goes through all of the efforts taken so far, motivation, current status, and future plans of the Zephyr-LoRa work. To add this session to your schedule, click here. To review references for this session – click here: https://www.semtech.com/lora/what-is-lora or https://github.com/zephyrproject-rtos/zephyr/pull/18998.
At 3:30-3:55 pm, Paul Sokolovsky, IoT Engineer at Linaro, will present an update on LAVA testing for baremetal systems. One of important goals of Linaro LITE team is to ensure continuous integration and validation for the projects it works with. This session covers recent work on improving test coverage for Zephyr and OpenAMP projects, using Linaro’s popular LAVA testing platform. Click here to add this to your schedule.
On Tuesday, March 24:
At 10-10:25 am, Maureen Helm, Software Engineer at NXP and Zephyr Project Chair of the Technical Steering Committee, will present Open Source Enabled Edge Processing. In the last five years, we have seen an explosion of open source in the IoT and embedded industry driven by a shift towards edge processing. Projects like Zephyr have grown from incubation to mainstream, addressing a growing need for common software infrastructure in embedded microcontroller applications that operate on the edge. In this talk we will take a look back at the expansion of open source in this industry in recent years and explore some insights into where it will go in the future. Click here to add it to your schedule.
The 16th Annual Workshop on Operating Systems Platforms for Embedded Real-Time Applications will be held at ECRTS 2020 in Modena, Italy from July 7-10, 2020. The OSPERT workshop itself takes place on July 7.
OSPERT is a satellite workshop of the 32nd Euromicro Conference on Real-Time Systems (ECRTS 2019), the premier European venue for presenting research into the broad area of real-time and embedded systems. OSPERT is open to all topics related to providing a reliable operating environment for real-time and embedded applications.
The Linux Foundation’s Kate Stewart will give a keynote on July 7 about the RTOS landscape and how Zephyr is the leading RTOS for IoT and embedded devices.
Stay tuned here for more details. For more information about the conference, please visit the ECRTS website.
Embedded World 2020 takes place on February 25-27, 2020 in Nuremberg, Germany. Now in its 18th year, the conference covers all aspects of the development and application of embedded systems, from fundamental technologies to development processes and special fields of application. With nearly 2,000 participants and 31,000 visitors the conference has over the years become an international meeting place for the professional embedded developer community.
Several of the Zephyr Project leaders from Bluetooth SIG, the Linux Foundation, Nordic Semiconductor and NXP will be giving presentations.
On Wednesday, February 26:
At 11:30 – 12 pm, Prof. Robert Oshana with NXP Semiconductors, will give a presentation titled, “Practical Software Testing Techniques and Guidelines for Embedded Systems.” Embedded technology has revolutionized sectors of the industry in ways that were previously never thought possible. For this reason, product testing is becoming increasingly important. Ensuring that our embedded technology functions properly is a priority for most companies, regardless of where that technology happens to be located. In this presentation we will explore white box and black box techniques for testing embedded systems, talk about system and performance testing, and summarize some of the unique testing requirements and approaches for real-time embedded systems. Topics include static and dynamic analysis techniques, exploratory testing, equivalence partitioning and boundary value analysis, and hueristics based testing methods.
At 12:30-1 pm, Kate Stewart with the Linux Foundation will give a presentation titled, “Safety Certification and Open Source – Can They Work Together?”
The last 20 years have seen a tremendous surge of new technologies and capabilities emerge from open source software. These open source building blocks have become increasingly attractive as the base for innovative new products. Safety critical applications are now using them as well, but we lack infrastructure to assess when this software is safe to use, that can keep up with the rate of change of open source development. Her talk will look at some of the challenges and approaches to building trust and confidence in open source used in safety critical software coming to new products. The approaches taken by 3 open source projects (Linux, Xen, Zephyr) will be discussed and contrasted.
At 12:30-1 pm, Pal Kastnes with Nordic Semiconductor, will give a presentation titled, “Bluetooth Security – A Technical Overview & Implementation Guide for Embedded Developers.” The Bluetooth specifications enable advanced security features to accommodate a wide variety of embedded applications and systems. This session will provide implementation guidelines to help embedded developers understand the range of security options available when developing with Bluetooth, as well as some best practices to follow when securing Bluetooth devices and solutions.
At 4-4:30 pm, Martin Woolley with Bluetooth SIG will give a presentation titled, “Bluetooth Location Services and High Accuracy Direction Finding.”Bluetooth can be used for many types of location service and it’s an area forecast to experience the biggest growth in the next few years, with 431 million location related devices shipping in 2023. In 2019, Bluetooth acquired a new capability which allows the direction of a signal to be accurately determined using one of two methods known as Angle of Arrival (AoA) or Angle of Departure (AoD). Come to this session and hear about this Bluetooth location services and the new direction finding feature, how it works and the uses it’s likely to be put to.
At 4-4:30 pm, Prof. Robert Oshana with NXP Semiconductors, will give a presentation titled, ” Guidelines, Tips and Tricks for Managing Open Source Software for Embedded Systems.” Open source software is ubiquitous in embedded computing. Whether you are using the Linux or Zephyr operating system, open source machine learning components, or any other form of community based software, its important to understand the basic guidelines and principles for developing and managing open source software. This presentation will use multiple actual industry examples to demonstrate practical tips and tricks for open source software development. Topics include developing an open source policy, understanding the basics of licensing open source software, how to update promptly, using a binary repo manager, how to particpate in the community and upstream software, how to use the proper build tools, tips for how and when to fork, and other practical examples. With the right framework and understanding, open source development for embedded systems can be more efficient, and less risky and error prone for the developer and the organization.
At 2-2:30 pm, Prof. Robert Oshana with NXP Semiconductors, is giving a presentation titled, “RISC-V Hardware and Software Technology for Industry.” RISC-V is a free and open ISA enabling a new era of processor innovation through open standard collaboration. The RISC-V foundation now has close to 300 member companies and universities, and growing. This talk will focus on the state of the technology for RISC-V. We will discuss the latest developments in the RISC-V foundation regarding technology development, discuss some of the new communites like openHW Group that are dedicated to creating high quality open source RISC-V implementations for the masses. We will discuss industry adoption of RISC-V, using actual examples of how to incorporate RISC-V into a corporate design flow. We will discuss what is being done to manage hardware and software fragmentation in this growing community, and the state of the RISC-V ecosystem. We will show examples of how to innovate by using the powerful instruction extension capability of the ISA.
This is a half-day, single-track event designed to introduce you to the leading Open Source RTOS built with safety and security in mind. Attendees will learn why Zephyr is gaining the attention of developers, with its support for BLE, OpenThread, LTE-M/NB-IoT cellular communications, and more. Learn about the latest security enhancements with Zephyr OS LTS, as well as the progress toward Functional Safety Certification. In the second half of the session, attendees will receive hands-on experience with boards which have been graciously donated by Zephyr Platinum Member Nordic. Stay tuned for specifics.
The Zephyr Project will be on-site at this year’s Embedded Linux Conference in Lyon, France on October 28-31. Join us at one of the 13 presentations given by Zephyr community leaders like BayLibre, Bluetooth SIG, Intel, the Linux Foundation, Nordic Semiconductor, PHYTEC Messtechnik GmbH, Synopsys and more!
Monday, October 28:
11:30 am – 12:05 pm – Bluetooth Mesh and Zephyr – Martin Woolley, Bluetooth SIG
This session will explain the fundamental technical concepts of Bluetooth mesh, including models, messages, publish/subscribe, node composition and security keys and will explore what’s involved in implementing firmware that uses Bluetooth mesh on the Zephyr RTOS platform. Add it to your schedule here.
12:20 – 12:55 pm – Multi-core Application Development with Zephyr RTOS – Alexey Brodkin, Synopsys
This presentation will examine multi-core application options and considerations using the Zephyr. We’ll start from exploration of use-cases where multiple CPU cores might be beneficial for deeply embedded system including both asymmetric & symmetric multiprocessing (AMP & SMP). Then we’ll discuss current state of multi-core support in Zephyr: what is already implemented and what’s still missing. And in the end we will highlight challenges associated with designing high performance software applications for multi-core hardware using samples on boards currently supported in upstream Zephyr project. Add it to your schedule here.
4:20 – 4:55 pm – Panel Discussion – Building Safe Systems with Open Source Software – Lukas Bulwahn, BMW AG; Kate Stewart, the Linux Foundation; Nicole Pappler, TUV SUD Product Service GmbH; Nicholas McGuire, OSADL; Paul Sherwood, CodeThink & Trustable
This panel will discuss the challenges on technology, software engineering, safety methods, organization and ecosystem when building safe systems with open-source software. Add it to your schedule here.
4:20 – 4:55 pm – Precision Timeouts in Zephyr: Past, Present and Future – Piotr Ziecik, Nordic Semiconductor
In this session, Piotr Zięcik will give insight into Zephyr timing infrastructure and cover recent activities aimed to improve real-time capabilities of this operating system, as well as compare the achieved performance with real-world requirements. Piotr Zięcik will also present plans for long-term evolution of Zephyr timing infrastructure. Add it to your schedule here.
The Zephyr RTOS build system currently supports generating a single application image. This build is isolated from other related images, such as bootloaders, secure vs. nonsecure Arm TrustZone images, multi-core applications communicating via IPC mechanisms, etc. Different Zephyr downstream distributions have solved this problem in different ways, but there’s so far no consensus on how to solve this problem upstream. This BoF is meant to keep the conversation going among anyone who is interested in this topic. Add this to your schedule here.
Tuesday, October 29:
2:25 – 3 pm – Zephyr OS Memory Protection – Andrew Boie, Intel
In this presentation we describe the MPU-based memory protection features we have introduced in the Zephyr RTOS, showing novel techniques for working around the limitations of MPU hardware, implementing security domains in a physical memory map (no virtual memory), and maintaining API compatibility with platforms that do not have an MPU. We will show the permission management system to control access to kernel objects and device driver instances, and how both static and dynamically allocated kernel objects are managed. There will be some discussion on how global objects are routed to application memory domains and how we automatically manage size/alignment constraints of common MPU hardware. We will show how simple it is to define system calls. We have implemented futex-like capabilities to implement IPC mechanisms with no system calls required for uncontended locks. We will conclude with ongoing areas of development. Add it to your schedule here.
2:25 – 3 pm – Open Source and Functional Safety: Two Approaches to Bridge the Culture Clash – Kate Stewart, the Linux Foundation
This talk will summarize the current state of Zephyr and the project’s plans for going after Functional Safety certifications, while still handling any potential security issues. This will be contrasted with the ELISA project and how the team on ELISA is working towards new processes and tools to help Linux be confidently used in functional safety applications. Add it to your schedule here.
3:15 – 3:50 pm – A Dive into Zephyr Device Driver Model – Tomasz Bursztyka, Intel
Besides the kernel, the second most important part of an OS is how all peripherals are exposed to the user, finally enabling the OS to access the world outside of the CPU it is running on. Zephyr solves this by proposing a very simple yet flexible device driver model, deeply integrated with the device tree (DTS), making porting hardware to it efficient and easy. Through real use cases and from a developer perspective, this model will be explained as well as the life cycle of a device driver, whether it is native or ported from an existing HAL. Add it to your schedule here.
4:20 – 4:55 pm – Writing your own Gadget with Zephyr OS – Andrei Emeltchenko, Intel
In this talk, the author describes possible ways of connecting IOT devices using embedded boards running Zephyr OS, connected to host PC via USB. In particular, the following sample cases are explained: Export custom radios from Zephyr to Linux host (IEEE 802.15.4 and Bluetooth) so that Zephyr board behaves as a radio adapter for Linux. Author outlines the possibility of making IP bridge out the Zephyr-based SOC board. The device in this scenario behaves like USB Ethernet controller using ECM or RNDIS protocols. Part of the presentation is dedicated to OS drivers for the Zephyr-based boards. Add it to your schedule here.
5:10 – 5:45 pm – Device Tree: Past, Present and Future – Neil Armstrong, BayLibre
Neil will present you the history of Device Tree from its origins, how it has been used for ARM and now RISC-V from the PowerPC codebase, all the very different current usage and an overview of its future application and evolutions. Add it to your schedule here.
5:10 – 5:45 pm – Building a Debug Probe with the Zephyr RTOS – Johann Fischer, PHYTEC Messtechnik GmbH
The talk is about whether it would be possible (and how) to build a debug probe on top of the Zephyr RTOS. Zephyr already has a reasonably stable USB device stack with CDC-ACM and MSD support. The author will give a overview about the structure of debug probe software like DAPLInk, and the USB device stack in Zephyr. Furthermore, the author will introduce the implementation of the components and their interaction in Zephyr. Add it to your schedule here.
Wednesday, October 30:
11:30 am – 12:05 pm – The Journey of Leading Open Source Engineering Team in China – Jocelyn Li, Intel
In this talk, Jocelyn will talk about the various challenges and share how she led the open source engineering team by changing her mindset, embracing the open source development model and role-modeling the way. – Reluctant to discuss via mailing list – Embracing community – Submitting patches with good quality change log and code – Discussion and debating – Upstream vs Product
2:25 – 3 pm – Running Linux on Constrained IoT Device – Rui Silva, Linaro and Tushar Khandelwal, Arm
This presentation will talk about the work we have been doing to do memory optimizations in Linux kernel and file systems and uses it to build an IoT device frameworks that run on a small platform with limited ram and XIP flash. Add it to your schedule here.
If you want more Zephyr, stay an extra day and attend the Zephyr Mini-Summit on Thursday, October 31. This half-day, single-track event designed to introduce you Zephyr and offer a hands-on experience with boards donated by Zephyr Project member Nordic Semiconductor. Please add the Zephyr Mini-Summit to your current Open Source Summit Registration.