BeagleBoard/GSoC/2023 Proposal/PrashanthS

=BeagleBoard/GSoC/Prashanth S/Proposal for Zephyr on R5/M4F (K3) = About Student: Prashanth S Mentors: Nishanth Menon, Vaishnav Achath, Kumar Abhishek, Dhruva Gole, Deepak Khatri Code: Github Wiki: GSoC Wiki 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); int (*pin_get_config)(const struct device *port, gpio_pin_t pin,                         gpio_flags_t *flags); 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); int (*port_get_direction)(const struct device *port, gpio_port_pins_t map,             gpio_port_pins_t *inputs, gpio_port_pins_t *outputs); };
 * 1) ifdef CONFIG_GPIO_GET_CONFIG
 * 1) endif
 * 1) ifdef CONFIG_GPIO_GET_DIRECTION
 * 1) 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:
 * https://www.ti.com/lit/ds/symlink/tda4vm.pdf
 * https://docs.kernel.org/staging/remoteproc.html
 * https://www.zephyrproject.org/zephyr-rtos-and-cortex-r5-on-zynq-ultrascale-2/
 * https://en.wikipedia.org/wiki/Zephyr_(operating_system)
 * https://developer.arm.com/Processors/Cortex-R5#:~:text=The%20Arm%20Cortex%2DR5%20processor,time%20and%20safety%2Dcritical%20systems.
 * J721E DRA829/TDA4VM Processors Silicon Revision 1.1 Texas Instruments Reference Manual.
 * https://docs.zephyrproject.org/3.1.0/kernel/drivers/index.html

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.