BeagleBoard/GSoC/2023 Proposal/PrashanthS

From eLinux.org
Jump to: navigation, search


GSoC Proposal for Zephyr on R5/M4F (K3)

About Student: Prashanth S
Mentors: NishanthMenon, Vaishnav Achath
Code: https://github.com/slpp95prashanth/gsoc-application/tree/cc-task/
Wiki: http://elinux.org/BeagleBoard/GSoC/ProposalTemplate
GSoC: GSoC entry

Status

This project is currently just a proposal.

Proposal

I have completed the Cross Compilation Task CC-Task

The goal of the project is to add Zephyr RTOS support to run on Cortex R5 processor cores loaded from A72 core running Linux through remoteproc and add few peripheral support (Interrupts, Gpio, UART, Timers) on TDA4VM SoC. The Cortex R5 processor cores are built 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 the users.

About you

Github: slpp95prashanth
School: Bannari Amman Institute of Technology
Country: India
Primary language : English, Tamil
Typical work hours : 9AM - 6PM
Previous GSoC participation: I am learning embedded systems only through open source community, I like to contribute back to community and I believe GSoC gives me an opportunity to do so with Mentors and this is very helpful for a newbie to contribute to open source. I participated in GSoC 2022 and contributed to the RTEMS community developing the CAN framework and DCAN peripheral support for Beaglebone Black. GSoC 2022
Other Contributions: I developed a very minimal firmware which can be used as a learning tool kit (helped me a lot in understanding interrupt vectors, ARM modes, ethernet drivers ...). Beaglebone black

About your project

Project name: Zephyr on R5/M4F

Description

Current SoCs frequently feature heterogeneous remote processor units in asymmetric multiprocessing (AMP) setups, which may be running several Linux or other real-time OS instances. One such SoC is TDA4VM, with heterogeneous multicore support it can run different operating systems simultaneously. TDA4VM has Dual 64-bit Arm® Cortex®-A72 microprocessor subsystem at up to 2.0 GHz, Six Arm® Cortex®-R5F MCUs at up to 1.0 GHz, Two C66x floating point DSP, up to 1.35 GHz, 40 GFLOPS, 160 GOPS and 3D GPU PowerVR® Rogue 8XE GE8430, up to 750 MHz, 96 GFLOPS, 6 Gpix/sec.

Zephyr is a small real-time operating system for connected, resource-constrained and embedded devices supporting multiple architectures. Zephyr allows for easy handling of multiple configuration options, APIs and external components, and is well suited to structured application development. Another benefit of Zephyr is that it targets some very serious protocol and standard implementations, being e.g. the first open source RTOS to introduce TSN support – by way of Antmicro’s contribution. The rising popularity of TSN in automotive and aerospace applications, and just about everywhere else, could be a very important reason to start using Zephyr in your TSN-capable product.

The goal of the project is to add Zephyr RTOS support to run on Cortex R5 processor cores loaded from A72 core running Linux through remoteproc and add few peripheral support (Interrupts, Gpio, UART, Timers) for TDA4VM. The Cortex R5 processor core are built to provide deeply embedded real-time and safety-critical systems. So adding Zephyr RTOS support for R5 cores in TDA4VM will be very helpful for the product developers.

Programming Languages: Assembly Programming, C.

I got introduced to embedded linux through Beaglebone Black, which is helping me in understanding the basics. I like to take this opportunity to contribute to beagleboard. I also developed a very minimal firmware which can be used as a learning tool kit (helped me a lot in understanding interrupt vectors, ARM modes, ethernet drivers ...), which might be helpful for a beginner to get started. Beaglebone black

The device is partitioned into three functional domains, each containing specific processing cores and peripherals:

  • Wake-up (WKUP) domain
  • Microcontroller (MCU) domain
  • MAIN domain

Zephyr Device Model: The device model paves way for the communication between the applications and the hardware. The device model creates the mapping between the generic apis for the applications to the hardware specific apis. This makes the application more portable across different platforms.

GPIO Controller: The GPIO pins are grouped into banks (16 pins per bank and 9 banks per module), which means that each GPIO module provides up to 144 dedicated general-purpose pins with input and output capabilities; thus, the general-purpose interface supports up to 432 (3 group instances × (9 banks × 16 pins)) I/O pins.

Adding GPIO hardware specific information to the device tree, defining the gpio apis and registering to the Zephyr device model.

__subsystem struct gpio_driver_api {                                            
      int (*pin_configure)(const struct device *port, gpio_pin_t pin,               
           gpio_flags_t flags);                                                 
#ifdef CONFIG_GPIO_GET_CONFIG                                                   
      int (*pin_get_config)(const struct device *port, gpio_pin_t pin,              
            gpio_flags_t *flags);                                               
#endif                                                                          
      int (*port_get_raw)(const struct device *port,                                
          gpio_port_value_t *value);                                            
      int (*port_set_masked_raw)(const struct device *port,                         
           gpio_port_pins_t mask,                                               
           gpio_port_value_t value);                                            
      int (*port_set_bits_raw)(const struct device *port,                           
         gpio_port_pins_t pins);                                                
      int (*port_clear_bits_raw)(const struct device *port,                         
           gpio_port_pins_t pins);                                              
      int (*port_toggle_bits)(const struct device *port,                            
        gpio_port_pins_t pins);                                                 
      int (*pin_interrupt_configure)(const struct device *port,                     
               gpio_pin_t pin,                                                  
               enum gpio_int_mode, enum gpio_int_trig);                         
      int (*manage_callback)(const struct device *port,                             
             struct gpio_callback *cb,                                          
             bool set);                                                         
      uint32_t (*get_pending_int)(const struct device *dev);                        
#ifdef CONFIG_GPIO_GET_DIRECTION                                                
      int (*port_get_direction)(const struct device *port, gpio_port_pins_t map,    
          gpio_port_pins_t *inputs, gpio_port_pins_t *outputs);                 
#endif /* CONFIG_GPIO_GET_DIRECTION */                                          
};

Interrupt Controller: The Interrupt Controller manages the interrupt from different peripherals to the CPU. If a peripheral raises an interrupt to the interrupt controller, the controller inturn raises an interrupt to the CPU. Then the PC jumps to the ISR, where the ISR gets the information of the interrupted peripheral from the interrupt controller and calls the corresponding interrupt handler.

Vectored Interrupt Manager (VIM): The interrupts to Cortex R5F are managed through VIM in TDA4VM. The VIM supports 512 interrupt inputs per core. Each interrupt can be either a level or a pulse (both active-high). The VIM has two interrupt outputs per core CoreN_IRQn and CoreN_FIQn.

VIM Interrupt Vector Table (VIM RAM): For each VIM interrupt core, there is an associated interrupt vector table (VIM RAM) that is used to store the address of ISRs. During register vectored interrupt and hardware vectored interrupt, VIM accesses the interrupt vector table using the vector value to fetch the address of the corresponding ISR. Note that both interrupt vector tables are identical in their memory organisation.

Taking AM263x SDK VIM source code as reference, I have planned to implement VIM controller support for Zephyr.

Timer Controller: The Zephyr system tick is generated through the timer module. In TDA4VM, The interrupt from the timer module can be caused through overflow, compare or capture.For each timer implemented in the device, there are two possible clock sources: 32-kHz clock and System clock. There are 20 TImers in MAIN Domain from TIMER 0 to TIMER 19. The timer can issue an overflow interrupt, a timer match interrupt, and a timer capture interrupt. Each internal interrupt source can be independently enabled and disabled in the interrupt-enable register and disabled in the interrupt-disable register. When the interrupt event is issued, the associated interrupt status bit is set in the timer status register.

Positive increment value = (INTEGER[Fclk × Ttick ] + 1) × 1e6) – (Fclk × Ttick × 1e6) Negative increment value = (INTEGER[Fclk × Ttick ] × 1e6) – (Fclk × Ttick × 1e6)

For Example: To generate 1-ms tick with a 32.768-kHz clock:

  • [31-0] POSITIVE_INC_VALUE = 232,000
  • [31-0] NEGATIVE_INC_VALUE = –768,000
  • [31-0] LOAD_VALUE = 0xFFFF FFE0

References:

Timeline

Date Status Details
Submission Of Proposal
  • Interaction with mentors.
  • Getting familiar with hardware and Zephyr code base.
  • Get the board and other required hardware ready.
May 4th to May 28th Community Bonding
  • Interaction with the community.
  • Flash Linux image on A72 core.
  • Getting familiar with hardware and Zephyr code base.
  • Understanding multiprocessor environment and IPC.
  • Understanding remoteproc on how to load firmware from linux to other processor cores.
  • Boot minimal Cortex R5 firmware from Linux running on A72 core through remoteproc.
  • Add UART support for debug prints in the minimal firmware.
  • Setting up the Zephyr build environment.
June 5th MileStone #1
  • Introductory Video.
  • Create essential board directory, defconfig and device tree bindings for board.
  • Adding UART controller support in Zephyr.
July 10th to July 14th Midterm Evaluations
  • Deliverables
    • Documentation for the features developed.
    • Source files for the developed modules.
July 14th to Aug 20th Work Period
  • Adding UART support in Zephyr.
  • Adding Timers and System Tick in Zephyr.
  • Bring up Shell through UART in Zephyr.
Aug 21st to Aug 28th Final Week
  • Deliverables
    • Documentation for the features developed.
    • Source files for the developed modules.
Aug 29th to Nov 6th Extended Coding Period
  • Adding Interrupt Controller support.
  • Adding UART in Interrupt mode.
  • Adding Gpio controller driver in Zephyr.
  • Upstream the developed features to Zephyr.
Nov 6th Final Evaluations
  • Deliverables
    • Documentation for the features developed.
    • Source files for the developed modules.

Experience and approach

My personal Projects:

  • Developed a learning tool kit for Beaglebone Black to understand the minimum support required for a general system to boot and understand how to configure peripherals like GPIO, Ethernet, UART, Timers and Interrupt support Beaglebone black.
  • Developed a learning application to understand LwIP with shell (few commands) by porting it to work on linux userspace. LwIP application LwIP.
  • Developed a basic application to understand .wav audio files and amplify the audio data through software Amplify audio signal.

Contingency

I try to gather the docs required for the project, ask beagleboard community, Zephyr community (as the project is to add BSP support on Zephyr) and other open source communities.

Benefit

Adding BSP support for TDA4VM SoC in Zephyr,

  • I will be creating documents in parallel. I believe, this will be helpful for beginners to learn adding new BSP support for Multiprocessor environment.
  • Will help users to develop real time applications on Zephyr.

Quotes

"a decent Zephyr port on the R5 on BBAI-64 with good amount of examples and proper west integration around remoteproc would make the development flow for R5 cores much easier than it is now(+all the other benefits that Zephyr offers)"
- Vaishnav M A
"This will also directly tie into enabling openAMP on tda4vm"
- Nishanth Menon

Pull Request Link

Cross Compilation Task PR #173.