search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.8k stars 6.58k forks source link

Migrate old RA4M1 boards into FSP code #75440

Open soburi opened 4 months ago

soburi commented 4 months ago

Migrate old RA4M1 boards into FSP.

Objects:

Currently, Renesas RA4M1 does not use Renesas FSP (HAL). Because of the time the support was added, we can't use FSP for license incompatibility. Recently, the FSP's license changed to 3-clause BSD. So, the RA8M1 that was recently supported was added with FSP.

We need the old code to migrate into the FSP base for long-term support.

Obstacles:

The definition of the interrupt becomes an issue at this point.

The Renesas RA has an ICU (Interrupt controller Unit), Controller Unit) and performs a kind of dynamic interrupt configuration.

Normally, interrupt numbers and functions correspond one-to-one in NVIC interrupt definitions (as seen in STM32, etc.).

In the Renesas RA, interrupt functions do not correspond to numbers but are assigned by the ICU settings.

Interrupt functions are much than interrupt lines. So, defining fixed default interrupt numbers in devictree that without any conflicts is difficult. It is also difficult to ensure consistency manually, so I believe some kind of dynamic configuration will be necessary. (Configurator assigns the interrupt number at compile time in the FSP development environment.)

The current RA4M1 code considers interrupts to be dynamic interrupts and dynamically assigns numbers at initialization. (drivers/interrupt_controller/intc_renesas_ra_icu.c)

Issue:

We must decide the best way to handle and define the interrupt number.

I don't think the migration will be too complicated if this issue can be resolved.

avolkov-1221 commented 3 months ago

I don't really agree about switching to FSP in its current state, because:

  1. except the above ICU problems;
  2. the HAL reinvent many wheels, and doesn't reuse nor Zephyr's synchronization primitives (but reinvent critical section from scratch), so the performance/memory footprint price is notable and conflicts with the current locks guaranteed;
  3. nor based on YAML/DTS, but mainly on huge number of ifdefs
  4. nor used errcodes from Zephyr, but remap them to the internal ones (actually expensive operation);
  5. nor following the Zephyr's or any popular formatting rules (sorry but lines with 150+ symbols length are not acceptable anywhere)
  6. and HAL's policy regarding accepting 3rd party commits is unknown. For example, will be accepted a PR that breaks FreeRTOS/ThreadX compatibility? Why is there still IAR support if Zephyr doesn't have one, and how this code has been tested?
  7. Also the HAL is heavily based on non-atomic CMSIS volatiles without any locking (it's mean that 3rd party atomicity related patches will coming). But how any patch to them can be accepted, without common spinlocks/mutexes/etc and without common coding style rules?

Sorry, but IMHO relocate to the code which violates so many Zephyr's basic rules, and nether pass the Twister tests (in the current state) is not so good idea.