Reserve peripherals for the proper core on iMX8M-Plus

iMX8M-Plus is a HMP with 4 A53 cores plus 1 M7 core.
Based on the need of the given application, the several hadrdware peripherals must be reserved to the proper core (A53 running TorizonCore/Linux or M7 running a RTOS). The RDC (Resource Domain Controller) is responsible to give access to the right core types (or both of them).
The successfull approach of TorizonCore is that I, as a customer, can keep my focus on the application and not on the OS. But when the job is allocating one of the peripherals to the core, the things are not so easy.
I try to describe what I see:

  • at the boot, u-boot reserves some lof the peripherals to Cortex-M7, based on root/arch/arm/dts/imx8mp-verdin-u-boot.dtsi
  • this file on Toradex repo has been inspired by a dtsi from NXP that has been customized to execute a given demo example on EVK board.
  • I’m not sure that this is the best dtsi for a Verdin iMX8M-Plus running TorizonCore. As an example, UART4 is reserved to Cortex-M7, but on this SoM UART4 is used by Linux to drive the wifi/BT module.
  • in this topic, @hfranco.tx explained how the peripherals reservation works
  • as he explained, if one of the reserved peripherals is needed on Linux side, only two options are possible:
    1. set the proper Peripheral Domain Access Permissions (RDC_PDAPn) register in u-boot
    2. fix the u-boot source code.
  • but the second option is the opposite as TorizonCore philosophy

My question is: how can I customize a TorizonCore image, so that u-boot sets the proper Peripheral Domain Access Permissions (RDC_PDAPn) for the peripherals necessary to my application?
Is u-boot-initial-env-sd the key point?

Second question: u-boot reserves DDR region to Cortex-M too. But how can I customize TorizonCore (not rebuilding u-boot) so that a different region of DDR is reserved?

Third question: from TorizonCore side, don’t you think that a “clean” dtsi in uboot would be better? Why reserving I2C3 for Cortex-M?

I know that the questions are not easy, but I hope that Toradex engineers can consider them and give ideas.

Hi @vix,

I apologize for the delay.

From my understanding, you are correct about the points made.

Unfortunately, as this is a change to the u-boot device tree, it’s not possible to achieve this by modifying the u-boot-inital-env-sd file. If you need to change the device tree, a patch to u-boot is needed (which I also agree is the opposite from the TorizonCore philosophy, but since the Cortex-M is not yet fully supported, in this case, a patched u-boot will be needed).

You can achieve that by using an overlay on the Linux device tree that reserves the RAM needed y Cortex-M, so Linux won’t touch it and cause any errors.

Although I agree with you, in the Cortex-M case we try to inherit NXP code so we don’t break support with the SDK that comes from NXP. I know this is not ideal, but rewriting the u-boot code would require more time to test everything and create a new device tree that could break the SDK.

Let’s that a step back first, before going into the Cortex-M rabbit hole, can you share with me which peripherals you need to access and use on the Cortex-M side?

Best Regards,
Hiago.

Hi @hfranco.tx

Unfortunately, as this is a change to the u-boot device tree, it’s not possible to achieve this by modifying the u-boot-inital-env-sd file. If you need to change the device tree, a patch to u-boot is needed (which I also agree is the opposite from the TorizonCore philosophy, but since the Cortex-M is not yet fully supported, in this case, a patched u-boot will be needed).

I’m not sure if what I need is a modified u-boot device tree.
I try to explain what is the scenario:

  • u-boot loads the firmware into Cortex-M and starts the execution
  • the firmware on Cortex-M configures some peripherals (as an example, UART2)
  • from this moment onward, I need that Cortex-A doesn’t access and/or try to reconfigure that peripherals (as an example, UART2). This must be true when Cortex-A is running either u-boot (a short time between the start of Cortex-M until the start of TorizonCore) or TorizonCore
  • for TorizonCore I can use the proper device tree overlay, and this is enough
  • for u-boot, should I configure something to be sure about this? Or is this not a real risk? Isn’t enough adding some mw.l ... in u-boot-initial-env-sd to configure the RDC before starting the Cortex-M?

I hope you can understand and give me some suggestion.

You can achieve that by using an overlay on the Linux device tree that reserves the RAM needed y Cortex-M, so Linux won’t touch it and cause any errors.

Ok

Let’s that a step back first, before going into the Cortex-M rabbit hole, can you share with me which peripherals you need to access and use on the Cortex-M side?

The list is not 100% complete, bu basically:

  • some GPIOs
  • one (or two) SPI
  • one (or two) I2C
  • one (or better two) UART: I think to UART1 and UART2 so that they don’t conflict with UART3 (TorizonCore debug console) and UART4 (used for WiFi/BT module on Verdin Plus)

I hope that this helps

Hi @vix,

I haven’t tried modifying the register for RDC directly on u-boot, I believe the safer way would be first test only with the Linux overlay and if that’s not enough, try to change the u-boot code/device tree to modify the RDC.

Ok, in this case, have you tried to disable these peripherals from Linux first instead of diving into U-boot or RDS stuff? Or this wasn’t enough?

Bes Regards,
Hiago.

Ok, in this case, have you tried to disable these peripherals from Linux first instead of diving into U-boot or RDS stuff? Or this wasn’t enough?

Not yet. It’s on my TODO list.
I let you know.

1 Like