i.MX95: ARM/CM7: LPI2C/Flexio backport and eDMA SG fix

[PetervdPerk-NXP]

Summary

• Backport ARM64 LPI2C changes to the imx95 arm target
• eDMA fix TCM address calcuation for scatter-gatter
• Add FlexIO driver for imx95 (backport from i.mxrt)

Impact

NavQ95

[acassis]

@PetervdPerk-NXP thank you for this improvement. I noticed iMX93/95 are missing a Documentation page dedicated to the chip itself, including the listing of supported peripherals.

[simbit18]

Hi @PetervdPerk-NXP, please align CMake with Make

if(CONFIG_IMX9_FLEXIO)
  list(APPEND SRCS imx9_flexio.c)
endif()

https://github.com/PetervdPerk-NXP/nuttx/blob/8678d668401979afdac7161324f18c65c6b6e8dc/arch/arm/src/imx9/CMakeLists.txt#L67

[simbit18]

@PetervdPerk-NXP, could you help us with this PR #18367 ?

[jlaitine]

I know that commenting on a PR is probably not the right place for this; this PR is all fine by me.

But a little bit related to this PR - it would be nice, if there was some common place in NuttX source tree for SoC specific files/drivers which are not specific for a specific CPU architecture. For i.MX93/95 more or less every driver and header file is almost a copy of each other in "arm64" and "arm". Only because the SoC just happens to have both Cortex-A and Cortex-M cores, but all the memory maps and peripherals are the same.

Of course, this is the way how we must do it now, when such place doesn't exist.

[PetervdPerk-NXP]

I know that commenting on a PR is probably not the right place for this; this PR is all fine by me.

But a little bit related to this PR - it would be nice, if there was some common place in NuttX source tree for SoC specific files/drivers which are not specific for a specific CPU architecture. For i.MX93/95 more or less every driver and header file is almost a copy of each other in "arm64" and "arm". Only because the SoC just happens to have both Cortex-A and Cortex-M cores, but all the memory maps and peripherals are the same.

Of course, this is the way how we must do it now, when such place doesn't exist.

I think for some drivers it could make sense, but we gotta be careful about architecture specific details i.e. 32-bit vs 64-bit. AARCH64 vs ARMv7, usage of eDMA memory mapping / translation. Different hardware erratums per chip, different peripheral versions/features for example LPI2C on i.MX95 is version 1.3 with 8 fifo buffers.

There are some drivers that work across chips/architectures i.e. SJA1000 #11868 maybe you could start experimenting by converting a driver that could be hardware agnostic i.e. FlexCAN or FlexIO.

[acassis]

I know that commenting on a PR is probably not the right place for this; this PR is all fine by me.

But a little bit related to this PR - it would be nice, if there was some common place in NuttX source tree for SoC specific files/drivers which are not specific for a specific CPU architecture. For i.MX93/95 more or less every driver and header file is almost a copy of each other in "arm64" and "arm". Only because the SoC just happens to have both Cortex-A and Cortex-M cores, but all the memory maps and peripherals are the same.

Of course, this is the way how we must do it now, when such place doesn't exist.

Yes, it happens to many stm32xx chips as well. But I think it remounts from the decision that Greg took in the past, where duplication is better than having small differences that end-up creating many #ifdefs inside the drivers. If you see the arch/arm/src/stm32/ you will notice it. Most of the drivers are shared between F1, F2, F3 and F4 and it makes the driver more complex to read and maintain.

But for iMX93 and iMX95 maybe the drivers are 100% compatible. Maybe in this case we could have arch/arm64/src/common/imx.

In fact, Espressif guys already did it, see: arch/risc-v/src/common/espressif/ for reference.

[raiden00pl]

Yes, it happens to many stm32xx chips as well. But I think it remounts from the decision that Greg took in the past, where duplication is better than having small differences that end-up creating many #ifdefs inside the drivers. If you see the arch/arm/src/stm32/ you will notice it. Most of the drivers are shared between F1, F2, F3 and F4 and it makes the driver more complex to read and maintain.

At the time Greg made this decision, it made sense. Now, with several new chip families released every year, I don't think this is a good solution. As the author of several stm32 ports, I'm not interested in adding support for additional families in the current state. The amount of code duplication has already reached a level that exceeds the bounds of good taste.

Maybe this is a good time to think about how to solve this problem better? in my case I'm mainly interested in stm32, but probably other architectures have or will have the same problem soon.

[jlaitine]

Yes, it happens to many stm32xx chips as well. But I think it remounts from the decision that Greg took in the past, where duplication is better than having small differences that end-up creating many #ifdefs inside the drivers. If you see the arch/arm/src/stm32/ you will notice it. Most of the drivers are shared between F1, F2, F3 and F4 and it makes the driver more complex to read and maintain.

At the time Greg made this decision, it made sense. Now, with several new chip families released every year, I don't think this is a good solution. As the author of several stm32 ports, I'm not interested in adding support for additional families in the current state. The amount of code duplication has already reached a level that exceeds the bounds of good taste.

Maybe this is a good time to think about how to solve this problem better? in my case I'm mainly interested in stm32, but probably other architectures have or will have the same problem soon.

This is not a very urgent topic, but I agree that it would be good to start thinking about it. All the points in this discussion are very valid.

Just to clarify, I had a bit narrower scope in mind; I was referring to the CPUs and peripheral drivers only within the same SoC. Many SoC:s contain several CPU cores of different architectures.

For example, i.MX95 has 4 Cortex-A cores, 1 Cortex-M7 and 1 Cortex-M33. And you can run NuttX in any of those CPU subsystems, depending on the need. That is, for that SoC (i.MX95), the peripheral IPs are the same, but the drivers get duplicated in arch/arm and arch/arm64. The same applies for i.MX93, where you can run nuttx in both Cortex-A cores and in Cortex-M33, also in that case the peripheral drivers would be duplicated in the source tree - with only very minor differencies like cache line width, register widths in cpu etc..

[raiden00pl]

@jlaitine The same applies to stm32-based MPUs, such as the STM32MP1 and STM32MP2. From what I've analyzed, for stm32 this can be solved with a small number of ifdefs, making the code portable across different architectures. It's probably possible for other vendors as well. For stm32 it's a little easier because we can always refer to ChibiOS where it's nicely organized from the beginning: https://github.com/ChibiOS/ChibiOS/tree/master/os/hal/ports/STM32