Support TI Hercules SoC

[stephanosio]

This is an epic for Texas Instruments Hercules™ SoC support.

Hercules™ is a family of system-on-chips from Texas Instruments that focuses on functional safety for mission-critical automotive and industrial applications. This SoC, depending on series, embeds a Cortex-R4(F) or Cortex-R5F processor as well as a number of built-in hardware error detection and recovery blocks.

This task aims to expand the application of Zephyr RTOS to industrial sectors where functional safety and system reliability are primarily of concern, and provide a reference platform for functional safety certification, such as IEC 61508 and ISO 26262.

Phase 1 Tasks
Implement basic platform support to get the kernel up and running

• Refactor and fix Cortex-R device tree #19696 Refactor Cortex-R port
• Cortex-R Port Improvement for 2.2 #19698 Improve Cortex-R port
• Support Cortex-R Core stephanosio/CMSIS_5#1 Implement preliminary Cortex-R support on CMSIS: CMSIS-Core(R)
• Add provisions for supporting multiple CMSIS variants #19717 Refactor CMSIS #19875 Add provisions for supporting multiple CMSIS variants
• ext: hal: cmsis: Add CMSIS-Core(R). #19964 Add CMSIS-Core(R) to the Zephyr repository
• #TBD Implement base platform support for Hercules (NOTE: soc definitions, dts, import TI drivers)
• #TBD Implement Hercules clock control support
• #TBD Implement Hercules VIM (vectored interrupt manager) support
• #TBD Implement Hercules RTI (real-time interrupt) support
• #TBD Implement Hercules SCI (serial communication interface) support
• #TBD Implement Hercules IOMM (I/O multiplexing and control module) support
• #TBD Implement Hercules GIO (general-purpose I/O module) support
• #TBD Implement Hercules PMM (power management module) support
• #TBD Support RM46L852 SoC
• #TBD Support LAUNCHXL2-RM46 board
• #TBD Support RM57L843 SoC
• #TBD Support LAUNCHXL2-RM57 board

Phase 2 Tasks
Implement safety-critical hardware block support

• #TBD Implement Hercules PBIST (programmable built-in self-test) support
• #TBD Implement Hercules STC (self-test controller) support
• #TBD Implement Hercules CCM (CPU compare module) support
• #TBD Implement Hercules DCC (dual-clock comparator) support
• #TBD Implement Hercules ESM (error signaling module) support
• #TBD Implement Hercules CRC (cyclic redundancy check) support
• #TBD Implement Hercules safety subsystem (NOTE: This subsystem should utilise the safety-critical hardware blocks above to check for system errors and implement a recovery mechanism for each scenario)

Phase 3 Tasks
Implement peripheral hardware block support

• #TBD Implement Hercules ADC support
• #TBD Implement Hercules N2HET support (NOTE: N2HET is a timer coprocessor for handling specialised I/O tasks)
• #TBD Implement Hercules I2C support
• #TBD Implement Hercules SPI support
• #TBD Implement Hercules CAN support
• #TBD Implement Hercules LIN support (NOTE: LIN support should be added to the existing SCI driver implementation from Phase 1)
• #TBD Implement Hercules USB support
• #TBD Implement Hercules Ethernet support

Note

• The drivers generated by TI HALCoGen are licensed under the 3-clause BSD licence which, I suppose, should not be a problem. A further discussion on how to integrate them into the Zephyr project will have to be made.
• A series of pull requests and/or issues for each task will be created in the future.
• The development phase 1 aims to provide basic platform support and therefore its task list consists only of the essential tasks that are required to get the platform up and running. More essential tasks, if deemed necessary, may be added.
• The development phase 2 and 3 may be executed in parallel if more devs are willing to join this effort; however, they must be executed after phase 1 as the base platform definitions must be available in order to implement them.

[carlescufi]

The drivers generated by TI HALCoGen are licensed under the 3-clause BSD licence which, I suppose, should not be a problem. A further discussion on how to integrate them into the Zephyr project will have to be made.

This should not be a problem at all. We already have 3-clause BSD license drivers in our modules/hal folders.

[ioannisg]

Add non-Cortex-M CMSIS variants to the Zephyr codebase (minor refactoring will be required)

Can you create a separate issue for that?

[stephanosio]

Add non-Cortex-M CMSIS variants to the Zephyr codebase (minor refactoring will be required)

Can you create a separate issue for that?

@ioannisg #19717

[legath]

is hal must be created from HALCOGEN library? or could i try to write more simple support?
just want to help with this port...

[stephanosio]

is hal must be created from HALCOGEN library? or could i try to write more simple support?
just want to help with this port...

@legath I was suggesting that we use the drivers generated by the HALCoGen either as whole or in part. The peripheral register mapping files such as reg_*.h can be used as is, and some core peripheral drivers such as BIST and VIM can be also used with no or minimal modifications. As for the rest, we could write custom Zephyr-specific driver implementations as necessary using the peripheral register mapping files provided by the HALCoGen.

Have a look here:
https://github.com/stephanosio/hal_ti/tree/hercules_support/hercules

[stephanosio]

Closing since I lack the bandwidth to upstream this. Please feel free to re-open if someone else is planning to take over.

[Mcode5A]

@stephanosio I would like to reopen and contribute to it, I'm currently at a project with that setup and we have to make it work. Thanks