How do I access both M7 and A53 consoles simultaneously on Verdin plus module?

Technical Support
, , , ,
2

Hi @mhwm,

I believe I replied to you by email with all the information. But I will also write the answer here so others can benefit from this information.

I know why the kernel is panicking at this point, let me try to explain here, and let me know if you have any questions.

For BSP 6, the following code was added to u-boot downstream source: u-boot-toradex.git - U-Boot bootloader for Apalis and Colibri modules

Although this code was committed by Toradex, this was copied from NXP u-boot downstream source code.
The Resource Domain Controller - RDC is the part of the processor which controls the resources that are being used by the cores (Cortex A’s, M7…). Because this code is from NXP and NXP has a demo that involves sound play/control with the cortex-M7, they’ve set the control of the I²C3 to the cortex-M7. That’s why when you launch the cortex M7, even though we’re not using this peripheral, M7 takes control of it, and the kernel panics while trying to request the I²C 3.

This is clear when we check the 3.2.4.2 Peripheral Mapping of the iMX8M Plus Reference Manual:

  • I²C 3 is controlled by the RDC_PDAP68 register.
  • RDC_PDAP68 address is 0x303D0510.

Checking this value inside u-boot, we can see that the default value is 0xff:

Verdin iMX8MP # md.l 0x303d0510 1
303d0510: 000000ff                             ....

However, as soon as we launch u-boot with the bootaux command, the value changes to 0xc:

Verdin iMX8MP # md.l 0x303d0510 1
303d0510: 0000000c                             ....

Checking the Reference Manual again, 0xff means that all cores have access to this peripheral, while 0xc means that this peripheral is only accessed by M7 (check 3.2.5.6 Peripheral Domain Access Permissions (RDC_PDAPn) of the RM).
The 0xc is exactly the code that is being set by u-boot in the commit shown above:

#define PDAP_D1_ACCESS 0x0000000C /* D1W|D1R */

Now we have two options, and both of them work:

  • Manually right this value again in u-boot:
Verdin iMX8MP # mw.l 0x303d0510 0xff
Verdin iMX8MP # md.l 0x303d0510 1
303d0510: 000000ff                             ....
  • Fix the u-boot source code.
  • Or disable the I²C in the Linux device tree:
&i2c3 {
        status = "disabled";
};

The best solution here is to disable the i2c3 in the HMP device tree overlay because we don’t have to make deep changes like patching u-boot.

If, for instance, you want to specifically use I2C3 this will be a problem, and a u-boot patch or before booting linux writing 0xff to memory will be needed. Otherwise, you should be fine.

After that being said, I have a preliminary overlay that enables RPMSG and Remote Proc for the Verdin MPlus. Please download the source code and the compiled overlay for BSP 6/TorizonCore 6 (kernel 5.15 downstream): Download - Toradex File Sharing Platform

This will not enable all the features of the low-power demo, but you will be able to run the rpmsg and remote proc demos. For the low-power demo, please take a look at the NXP device tree: imx8mp-evk-rpmsg.dts « freescale « dts « boot « arm64 « arch - linux-toradex.git - Linux kernel for Apalis, Colibri and Verdin modules

The same nodes will need to be added to this overlay to make it work. We haven’t tested the low-power demo, only the rpmsg and the remote proc, usually this is what we test on our side.
For the remote proc, there is a known issue where sometimes the remote proc breaks because the firmware tries to get I²C3, and the kernel freezes. We’re working on that.

I’m updating our documentation about the HMP, so if you have any suggestions on how we can improve, please let me know.

Sorry for the long message, I wish you a wonderful year.

Best Regards,
Hiago

1 Like