Forum | Documentation | Website | Blog

Skip to content
Snippets Groups Projects
Select Git revision
  • main default protected
1 result
Blame History Permalink
suraj-sonawane.rst 25.97 KiB

Upstream Zephyr Support on BeagleBone AI-64 R5

Introduction

The goal of the project is to upsteam Zephyr RTOS support to run on Cortex R5 processor cores loaded from A72 core running Linux through remoteproc. Some work has already been done by a previous year Gsoc contributor ( VIM , GPIO ), but not all the PR's have been merged. Therefore, I will be adding peripheral support for those PR's that were not merged ( J721E, Board support, DIM Timer support ) and also adding peripheral support for ADC, I2C, SPI, TI-SCI on TDA4VM SoC. The Cortex R5 processor cores are designed to provide deeply embedded real-time and safety-critical systems, so adding Zephyr RTOS support for R5 core in TDA4VM will be very helpful for users.

Summary links

Status

This project is currently just a proposal.

Proposal

About

Project

Project name: Upstream Zephyr Support on BeagleBone AI-64 R5.

Description

Overview

Zephyr is a small, yet scalable, full-featured OS with an architecture that allows developers to focus on applications requiring a real-time OS.

BeagleBone AI-64, is built on a proven open source Linux approach, bringing a massive amount of computing power to the hands of developers in an easy to use single board computer. Leveraging the Texas Instruments TDA4VM SOC with dual 64-bit Arm® Cortex®-A72, C7x DSP along with deep learning, vision and multimedia accelerators, developers have access to faster analytics, more data storage options, more high speed interfaces including all the connectors you’ll need on board to build applications such as Autonomous Robotics, Vision and Video Analytics, Hi-End Drones, Media Servers, and Smart Buildings.

TI-SCI

  • Texas Instruments’ System Control Interface (TISCI) defines the communication protocol between various processing entities to the System Control Entity on TI SoCs. This is a set of message formats and sequence of operations required to communicate and get system services processed from the System Control Entity in the SoC.
  • TISCI protocol is used to talk to the system software.

Power and Clock Management Public APIs are provided to perform:

Drivers needed to implement TI-SCI:
  • Mailbox controller driver
  • SCIClient Driver:
    The SCIClient is an interface to the TI-SCI protocol for RTOS and non-OS based applications. It exposes the core message details, valid module/clock IDs to the higher level software and abstracts the communication with the firmware based on the TI-SCI protocol. These APIs can be called by power, resource and security RTOS drivers or any other non-OS or RTOS based higher level software to be able to communicate with DMSC for its services. The higher level software is expected to populate the necessary message core parameters. The SCIClient would wrap the core message with the necessary protocol header and forward this to the DMSC. The SCIClient relies on the CSL-FL layer to program and interact with the Secure Proxy Threads. The SCIClient's goal is to ensure there is no duplication of the interface to the DMSC from different software components which need to interact with the DMSC or other System Control Entities in future devices.
Device Management and Security Control (DMSC)

The Device Management and Security Control (DMSC) subsystem is a processing entity on Jacinto 7 family of devices which performs centralized boot, power, security, and resource management functions, and System Firmware is the firmware which executes on the subsystem. System Firmware implements the Texas Instruments System Control Interface (TISCI) which client software can use to request various services related to device power, resources, and security functions.

J721E Device ID:
  • The device IDs represent SoC subsystems that can be modified via DMSC TISCI message APIs.
  • Some Secure, Power, and Resource Management DMSC subsystem TISCI message APIs define a device ID as a parameter allowing a user to specify management of a particular SoC subsystem.
J721E Clock ID:
  • TISCI message Power Management APIs define a device ID and clock ID as parameters allowing a user to specify granular control of clocks for a particular SoC subsystem.

DM Timer Controller

In TDA4VM, there are thirty timer modules in the device. MCU_TIMER0 to MCU_TIMER9 are in MCU domain and TIMER0 to TIMER19 in MAIN domain. All timers include specific functions to generate accurate tick interrupts to the operating system.

Timers Features

  • Interrupts generated on overflow, compare, and capture.
  • Programmable divider clock source (2n, where n = [0-8])
  • Dedicated input trigger for capture mode and dedicated output trigger/PWM signal
  • Generates a 1-ms tick clock when functional clock is 32.768 kHz

For each timer implemented in the device, there are two possible clock sources: • 32-kHz clock • System clock

Each timer supports three functional modes: • Timer mode • Capture mode • Compare mode The capture and compare modes are disabled by default after core reset.

ADC

Analog-to-Digital Converter (MCU_ADC) module contains a single 12-bit ADC which can be multiplexed to any 1 of 8 analog inputs (channels). Integrated in the MCU domain are two instances, each with the following main features:

  • 4 MSPS rate with a 60 MHz sample clock
  • Single-ended or differential input options
  • Each ADC module can be configured and transformed into digital test inputs
  • Programmable 16 steps Finite State Machine (FSM) sequencer

I2C

Device MAIN domain contains seven multi-master Inter-Integrated Circuit (I2C) interfaces, each with the following main features:

  • Compliancy to the Philips I2C-bus specification version 2.1
  • Support of standard mode (up to 100 Kbps) and fast mode (up to 400 Kbps)
  • Support of 7-bit and 10-bit device addressing modes
  • Support of multi-master transmitter/slave receiver and receiver/slave transmitter modes
  • Built-in FIFOs with programmable size of 8 to 64 bytes for buffered read or write
  • 8-bit-wide data access
  • Support of Auto Idle, Idle Request/Idle Acknowledge handshake, and Asynchronous Wakeup mechanisms
  • Low power consumption

SPI

Integrated in MAIN domain eight Multi-channel Serial Peripheral Interface (MCSPI) modules have the following main features:

  • Serial clock with programmable frequency, polarity, and phase for each channel
  • Wide selection of MCSPI word lengths, ranging from 4 to 32 bits
  • Up to four master channels, or single channel in slave mode
  • Support of different master multichannel modes
  • Single interrupt line for multiple interrupt source events
  • Support of start-bit write command
  • Support of start-bit pause and break sequence

Implementation Overview

Initial configuration:

1. Write Kconfig and device tree filels (Already done by previous year gsoc contributor) - Write Kconfig and device tree filels: Already done by previous year gsoc contributor in this PR.

2. Add Flash and debug support: Zephyr supports Building, Flashing and Debugging via west extension commands. To add west flash and west debug support, we need to create a board.cmake file in board directory. This file’s job is to configure a “runner” for your board. (There’s nothing special you need to do to get west build support for board.) West is “pluggable”: you can add your own commands to west without editing its source code. These are called west extension commands, or just “extensions” for short.

  1. Write the code implementing the command.
  2. Add information about it to a west-commands.yml file.
  3. Make sure the west-commands.yml file is referenced in the west manifest.

Driver Development:

1. Devicetree bindings: A devicetree binding declares requirements on the contents of nodes, and provides semantic information about the contents of valid nodes. Zephyr devicetree bindings are YAML files in a custom format (Zephyr does not use the dt-schema tools used by the Linux kernel).

2. API Definitions: Available under "include/drivers/". Provides a general way of unteracting with driver instances.

Add basic support for Device Manager using TISCI:

  • Device Manager enable and release a module.

  • This configures both power and clock details for the module and keeps track of its usage.

  • Add support driver to allow communication with system controller entity within the SoC using the mailbox client.

  • There are some existing APIs by using this API's we can add basic support for Device Manager using TISCI:
    • Device configuration and control APIs

      TISCI Message ID

      Message Name

      0x0200

      TISCI_MSG_SET_DEVICE

      0x0201

      TISCI_MSG_GET_DEVICE

      0x0202

      TISCI_MSG_SET_DEVICE_RESETS
  1. TISCI_MSG_SET_DEVICE : Request for a device state to be set. This is used to set or release various resets of the hardware block. This is typically used for hardware blocks which require special handling prior to specific resets being released. Typical example is when starting up a processing entity like ICSS/DSP, the device must be requested with resets asserted, required firmware loaded and the required resets released in appropriate order for operation of the device.
  2. TISCI_MSG_GET_DEVICE : Retrieve the hardware block state. This requests information regarding the state of a device including the device’s programmed state, current state, number of resets, and the number of times a device lost context.
  3. TISCI_MSG_SET_DEVICE_RESETS : Set the state of device reset state. This is used to set or release various resets of the hardware block. This is typically used for hardware blocks which require special handling prior to specific resets being released. Typical example is when starting up a processing entity like ICSS/DSP, the device must be requested with resets asserted, required firmware loaded and the required resets released in appropriate order for operation of the device.

Software

C, RTOS

Hardware

BeagleBone AI-64

Timeline

Timeline summary

Date Activity
February 26 - March 28 Connect with possible mentors, review past year's work(PR's), overview the Zephyr codebase, read documentation on adding board support, and create a proposal.
March 28 - April 2 Proposal review and Submission.
April 3 - April 30 Start working on studying the unmerged PR's . Getting familiar with Hardware and looking deeper in Zephyr code base. Also looking into TI-SCI TI-SCI implementation idea.
May 1 - May 10 Start bonding
May 11 - May 31 Focus on College Exams
June 1 - June 2 Start coding and introductory video
June 3 Release introductory video and complete milestone #1
June 10 Complete milestone #2
June 17 Complete milestone #3
June 24 Complete milestone #4
July 1 Complete milestone #5
July 8 Submit midterm evaluations
July 15 Complete milestone #6
July 22 Complete milestone #7
July 29 Complete milestone #8
August 5 Complete milestone #9
August 12 Complete milestone #10
August 19 Submit final project video, submit final work to GSoC site and complete final mentor evaluation

Timeline detailed

Open hardware computers for makers, educators and professionals