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:
this file on Toradex repo has been inspired by a dtsifrom 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.
as he explained, if one of the reserved peripherals is needed on Linux side, only two options are possible:
set the proper Peripheral Domain Access Permissions (RDC_PDAPn) register in u-boot
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.
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?
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 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?