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

Technical Support
, , , ,
1

I notice that UART4 has been allocated to the BT/WIFI module. I have tried to switch the M7 console to UART1 on the primary header of the Dahlia board in FreeRTOS but subsequently booting Linux with UART1 disabled in device tree yields a kernel panic from the 8250 driver:

…
[ 0.743253] SoC: i.MX8MP revision 1.1
[ 0.746317] Bus freq driver module loaded
[ 0.755924] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
[ 0.761546] 30880000.serial: ttymxc2 at MMIO 0x30880000 (irq = 34, base_baud = 1500000) is a IMX
[ 0.768275] printk: console [ttymxc2] enabled
[ 0.768275] printk: console [ttymxc2] enabled
[ 0.776908] printk: bootconsole [ec_imx6q0] disabled
[ 0.776908] printk: bootconsole [ec_imx6q0] disabled
[ 0.787316] 30890000.serial: ttymxc1 at MMIO 0x30890000 (irq = 35, base_baud = 1500000) is a IMX
[ 0.798886] Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
[ 0.806382] Modules linked in:
[ 0.809445] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.77-6.1.0-devel+git.a8d2c55c6ae7 #1
[ 0.817982] Hardware name: Toradex Verdin iMX8M Plus WB on Dahlia Board (DT)
[ 0.825037] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=–)
[ 0.832012] pc : imx_uart_probe+0x31c/0x7d0
[ 0.836208] lr : imx_uart_probe+0x30c/0x7d0
[ 0.840401] sp : ffff800009c4bb60
[ 0.843717] x29: ffff800009c4bb60 x28: 0000000000000000 x27: ffff8000096b04c0
[ 0.850869] x26: ffff0000c0c74800 x25: 00000000fffffffa x24: 00000000fffffffa
[ 0.858019] x23: ffff0000c00fe810 x22: 000000000000002b x21: ffff0000c00fe800
[ 0.865166] x20: 0000000000000000 x19: ffff0000c0c35880 x18: ffffffffffffffff
[ 0.872316] x17: 647561625f657361 x16: 62202c3533203d20 x15: ffff0000c0c7438a
[ 0.879466] x14: ffffffffffffffff x13: 0000000000000018 x12: 0101010101010101
[ 0.886614] x11: 0000000000000000 x10: 0101010101010101 x9 : 0000000000000004
[ 0.893762] x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefefefeff6f6c
[ 0.900912] x5 : 8080808080800000 x4 : 0000000000000010 x3 : 0000000000000000
[ 0.908061] x2 : 0000000000000000 x1 : ffff80000a3f0080 x0 : 0000000000000000
[ 0.915213] Call trace:
[ 0.917663] imx_uart_probe+0x31c/0x7d0
[ 0.921507] platform_probe+0x68/0xe0
[ 0.925181] really_probe+0xbc/0x46c
[ 0.928762] __driver_probe_device+0x114/0x190
[ 0.933212] driver_probe_device+0x40/0x100
[ 0.937404] __driver_attach+0xac/0x210
[ 0.941245] bus_for_each_dev+0x70/0xd0
[ 0.945088] driver_attach+0x24/0x30
[ 0.948674] bus_add_driver+0x144/0x244
[ 0.952516] driver_register+0x78/0x130
[ 0.956364] __platform_driver_register+0x28/0x34
[ 0.961076] imx_uart_init+0x3c/0x64
[ 0.964659] do_one_initcall+0x50/0x1b0
[ 0.968501] kernel_init_freeable+0x20c/0x290
[ 0.972866] kernel_init+0x24/0x12c
[ 0.976361] ret_from_fork+0x10/0x20
[ 0.979946] Code: 2a0003f4 35001820 f9400a61 91020021 (b9400021)
[ 0.986065] —[ end trace 0dde33e43dd32bd3 ]—
[ 0.990754] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
[ 0.998418] SMP: stopping secondary CPUs
[ 1.002346] Kernel Offset: disabled
[ 1.005835] CPU features: 0x00002001,20000846
[ 1.010197] Memory Limit: none
[ 1.013255] —[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b ]—

Any help would be appreciated.

Thanks

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
3

Hi hfranco.tx,

Let me first say that I am very thankful to have your support. Secondly, I think for this discussion we should stick to getting both consoles up and working. I’m sure I’ll need help getting the low power audio working as well, but that is a bridge we can cross later, perhaps in another ticket.

To recap, I disabled UART1 in the DT, pins and all, with .dtsi patches applied via .bbappend in the linux-toradex recipe of a custom layer. Then I build and boot the image to see that all is well; no /dev/ttymxc0 device node exists but all others do. I also disabled i2c3.

Now then, I modified the “hello world” demo application from the M7 SDK to use UART1 as console rather than UART4, this in light of the allocation of UART4 to BT/WIFI onboard the Verdin module. When I run this modified “hello world” from u-boot, I see the output on pins 12,13 of the primary header on the Dahlia board as expected, so far so good.

I then patched imx-atf to place UART4 in domain 0 and UART1 in domain 1, something NXP had me do on the Mini EVK. However, when I boot M7 and subsequently boot Linux, I get the aforementioned kernel panic at the point where UART4 would be probed by the driver. With the benefit of your previous reply, upon checking the appropriate RDC_PDAP70 (UART4) and RDC_PDAP102 (UART1) in u-boot, I find that UART4 has been seized in the process of booting the M7 and running the “hello world” app but UART1 is still free. If I correct the value of RDC_PDAP70 (UART4) to free it up then Linux boots fine. Here, I surmise that my changes to imx-atf are somehow not quite enough, so I added a patch to u-boot to change UART4 to UART1 in the code that you linked. Still, I get the same results.

But, I am simply flashing the .wic to an SD card then booting the board, and I think that the u-boot from the internal mmc is running rather than my patched version. How do I prepare an image/SD card so that the Toradex Easy Installer will be able to detect and install my new custom image to the internal mmc? I need to make sure that all of my patched components are running. It is very possible that I have done all I need to in order to change the M7 console, but my patched u-boot is not running.

Sorry for the long reply. I appreciate your help.

4

Incidentally, I have been to this documentation link:

I find there this somewhat vague instruction for offline installation:

Providing the Images​

Online installation (preferred): this is the easiest method. To list images from the Internet, make sure that you connect the board via Ethernet to a network that provides Internet access (the installer relies on DHCP to configure the IP address and HTTP to download images). After some seconds you should see a list of images appearing.

Offline installation: alternatively, if you cannot connect the board directly to the internet, you can download Toradex OS and partner demo images from our website and unzip/untar it onto an SD Card or USB Flash Drive. Once you plug it into the board, the images should appear in the list of available images with an icon indicating that it is found on a local storage device.

5

Okay, I figured out how to flash the emmc with my custom image and as I suspected the changes I made have successfully moved the M7 console to UART1. I can run hello world and subsequently boot linux without kernel panic. Woot!

Thanks very much for your help.

6

Hi @mhwm,

Great that it works now! I guess this thread is solved, at least for now, am I correct? If so can you mark one of the replies as “solution” please?

Let me know if you need anything else. If you have more questions about the cortex M7, feel free to open new tickets and tag me @hfranco.tx. I’m still working on the development of our resources about the HMP.

Best Regards,
Hiago.