Linaro Connect resources will be available here during and after Connect!
Booking Private Meetings Private meetings are booked through san19.skedda.com and your personal calendar (i.e. Google Calendar). View detailed instructions here.
For Speakers Please add your presentation to your session by attaching a pdf file to your session (under Manage Session > + Add Presentation). We will export these presentations daily and feature on the connect.linaro.org website here. Videos will be uploaded as we receive them (if the video of your session cannot be published please let us know immediately by emailing connect@linaro.org).
Zephyr is already ported on number of STM32 SoC platforms, but so far was limited to run on one core. The introduction of the dual cores STM32H7 series (Providing Cortex-M7 and Cortex-M4) lead us to implement and run Zephyr on the both cores.
This talk will detail the issues and the solutions used by STMicroelectronics to enable Zephyr on the both cores,. It will cover topics like dual core boot, resources sharing and inter-core communications.
Erwan Gouriou, STMicroelectronics, is working as Linaro assignee in the IoT & Embedded group (LITE). Since 3 years, he is the STM32 referent in Zephyr RTOS project. He has introduced the current STM32 porting model in Zephyr and works with the community to extend STM32 features set... Read More →
OpenAMP's RPMsg channels are limited to small buffers. This talk describes an architecture and implementation for transmitting large buffers using RPMsg.
Xilinx, Inc. assignee to Linaro, OpenAMP maintainer
Ed is relatively new to Linaro and Xilinx, but not to the embedded software industry, having been involved with safety- and security-critical embedded operating systems and hypervisors for the last 15 years.
Today's heterogeneous SoCs are very hard to configure. Issues like which cores, memory and devices belongs to which operating systems, hypervisors and firmware is done in an ad-hoc, error prone way. System Device Trees will change all that by extending today's device trees, used by Linux, Xen, uboot, etc. to describe the full system and also include configuration information on what belongs where. This talk will describe the issues involved and the proposed solution together with a demo of a prototype.
Yocto Maintainer, Principal System Software Engineer at Xilinx, xilinx
Bruce Ashfield is currently a system software architect and Yocto technical lead at Xilinx, the world's largest supplier of FPGA solutions. Previously, at Wind River, he created a embedded products based on the Yocto project. Bruce had a particular focus in virtualization and cloud... Read More →
Stefano Stabellini serves as system software architect and virtualization lead at Xilinx, the world's largest supplier of FPGA solutions. Previously, at Aporeto, he created a virtualization-based security solution for containers and authored several security articles. As Senior Principal... Read More →
Tomas Evensen is Chief Technology Officer, Embedded Software at Xilinx. In this role he is responsible for the embedded software strategy for Xilinx All Programmable SoCs. Prior to joining Xilinx, Evensen was Chief Technology Officer at Wind River for 7 years, as well as GM for the... Read More →
This talk will give an overview of the work by the security subcommittee within the Zephyr project, including the current status of security within the project. It will cover what happens when a vulnerability is reported, as well as ongoing efforts around static analysis.
David Brown is a member of the Linaro Security Working Group, and has worked on the Linux kernel, with a focus on security for a number of years. Recently, he has been focusing on security as it relates to IoT and embedded devices, including focusing on secure booting, and secure... Read More →
Trusted Firmware M (TF-M) is an open source implementation of Platform Security Architecture (PSA) for Arm Cortex M processors. TF-M provides secure services to other cores or non-secure execution environments using PSA APIs on the M profile core. It includes services like secure storage, security audit trails, and crypto, amongst others. PSA Firmware Framework (PSA-FF) compliant APIs are used for inter-process or inter-processor communication with the secure services.
This session will discuss how to run Zephyr on a non-secure core, calling TF-M services on a secure TF-M core. A dual-core Cortex M33 will be used, with OpenAMP as the IPC protocol between the Zephyr and TF-M core. This session will also examine PSA level 1 requirements for PSA certification, such as the use of a secure boot loader.
While isolation levels greater than 1 are involved in PSA certificate, the existing runtime library for secure partition lacks security consideration and contains its own private data, this prevents secure partition calling these APIs because of potential information leakage. A new runtime library needs to be available for secure partition with security consideration at the very start of design. The design should not break the isolation requirements listed in the PSA Firmware Framework specification. This runtime library also needs to be sharable for all secure partitions to save storage on IoT device, and it needs to be read-only to avoid tampering. And the most important part, no private data could exist inside of runtime library. This new runtime library would keep security isolation consideration out of secure partition designers, which make the development environment unified for secure partition developers. And save the size for IoT software since this library is shared.
Ken Liu is a software engineer at Arm on security solutions. He has been working in silicon company for over 15 years before joining Arm and focused on network, multi-media, product system and security solutions. He is now a key member engineer of Trusted Firmware M open source p... Read More →
Edison is working in CE-OSS Firmware team in ARM company and the workplace is in Shanghai, China. His work is mainly focused on the implementation of Trust Firmware M based on the PSA Firmware Framework.
Video acquisition, processing, and rendering are key features for a variety of different embedded applications and they are heavily used in automotive, monitoring and various AI applications. More specifically, I recently had to work on implementing camera support for a microcontroller running Zephyr RTOS. There is no existing support for camera in Zephyr, but like any other component, creating a common and generic subsystem/API benefits the community and encourages video component support work. Several software proposals, including one of my own, are currently under review and maybe even part of Zephyr when you read these words. We will review a few camera basics, the different ways to drive them and how to design a suitable subsystem/API, taking into account scalability, latency and memory footprint. We will conclude with a summary of the current upstream status and the status of any outstanding pull requests.
This session will present an overview of what Functional Safety is, how it is measured and certified and how the Zephyr project is producing the first Open Source safety certified RTOS.
Getting electronic devices onto internet and well connected with each other hasn't been a trivial task for the engineering community, always challenged by end price of the product, software scalability from devices running firmware to complex devices running complete OS distro, lack of fine tuned libraries and framework to introduce security of data, over the air upgrade and configuration and calibration of devices, supporting both head and headless units. Though the industry met the end user demand and floating requirements in time, the challenges continue to exist for next generation devices where the focus is on integrating multiple key components like security, networking, graphics, AI and ML libraries and sensor control frameworks into one singe device. While solving the system integration requirements is a key thing the other equal important aspect of ensuring the software is maintained for bug fixes, long term supported, simultaneous support for multiple SOCs and controllers is very much essential.
The end equipment manufacturers have various software options to chose from and each have their own advantages and disadvantages, inbuilt features and support infrastructure. Chromium OS is one of the latest open source software distributions maintained by Google for almost a decade now has made its way into IOT segments.
In this session we look into the key components in Chromium OS that can help us overcome the software challenges in building next generation IOT devices.
- Chromium OS is initially designed for laptops, desktops and stand alone / all inone boxes, the well integrated software components like browsers, networking, security, boot options and window management can be leveraged as is for IOT devices. We go through few of these components to understand if they meet the IOT requirements.
- Chromium OS is built on Linux, thereby the OS has support for multiple latest SOCs and device drivers for various controllers. We should be discussing if chromium OS has picked up all the latest trends in Linux OS related to Power Management, security, upgraded device driver frameworks, etc.
- In general IOT devices are headless or less UI centric, we explore if chromium OS can be easily configured to boot on a headless unit ?
- Understanding the system requirements, memory requirements and power utilization are few key factors to consider if the OS fits the budget available for the end equipment.
- The new set of IOT devices are now pre-integrated with AI algorithms to help end user for better understanding of the surrounding or indecision making etc. The devices are also self learning with ML algorithms. Its important to know if Chromium OS has frameworks to download AI/ML algorithms or firmware at run time on DSPs or SOCs. Also ensure if there are HALs and APIs to exchange data to/from DSPs or SOCs running AI/ML algorithms.
The topics covered in this session should help us quickly assess if chromium os is favorable for IOT devices or if we were bringing an elephant in the room.
