I.MX93，A55 boot failure when M33 is initialized from U-boot

[vinisha]

Hello NXP Engineers,

We are attempting to initialize the M33 core from U-Boot on the i.MX93 EVK board, but we are encountering some issues during the process. Below are the steps we followed for M33 initialization. As you can see, the auxiliary core is up and running, and we are able to observe the demo code being executed through the M33 debug port:

u-boot=> fatload mmc 0:1 0x98000000 sdk20-app.bin
13680 bytes read in 4 ms (3.3 MiB/s)
u-boot=> cp.b 0x98000000 0x201e0000 0x10000
u-boot=> bootaux 0x1ffe0000 0
## Starting auxiliary core addr = 0x1FFE0000...

However, when we attempt to boot the A55 using the "boot" command, we encounter the following failure conditions:

[    1.874795] remoteproc remoteproc0: imx-rproc is available
[    1.880384] remoteproc remoteproc0: attaching to imx-rproc
[    1.885904] Unable to handle kernel paging request at virtual address ffff8000433d3e00
[    1.893806] Mem abort info:
[    1.896591]   ESR = 0x0000000096000005
[    1.900331]   EC = 0x25: DABT (current EL), IL = 32 bits
[    1.905635]   SET = 0, FnV = 0
[    1.908681]   EA = 0, S1PTW = 0
[    1.911814]   FSC = 0x05: level 1 translation fault
[    1.916684] Data abort info:
[    1.919553]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[    1.925030]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[    1.930079]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[    1.935379] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082031000
[    1.942069] [ffff8000433d3e00] pgd=10000000fffff003, p4d=10000000fffff003, pud=0000000000000000
[    1.950763] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[    1.957016] Modules linked in:
[    1.960060] CPU: 0 PID: 26 Comm: kworker/u4:1 Not tainted 6.6.23-lts-next-g812033a2bd7c #1
[    1.968308] Hardware name: NXP i.MX93 11X11 EVK board (DT)
[    1.973779] Workqueue: events_unbound deferred_probe_work_func
[    1.979610] pstate: 00400009 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    1.986560] pc : rproc_handle_resources.constprop.0+0x64/0x18c
[    1.992384] lr : rproc_boot+0x37c/0x57c
[    1.996206] sp : ffff80008245b9f0
[    1.999508] x29: ffff80008245b9f0 x28: ffff800081b3e510 x27: ffff00007fbcfb98
[    2.006632] x26: 0000000000000007 x25: ffff800083610000 x24: ffff8000433d3e00
[    2.013756] x23: 0000000000000000 x22: ffff000004caa038 x21: ffff800082163798
[    2.020880] x20: 0000000000000000 x19: ffff000004caa000 x18: 0000000000000006
[    2.028004] x17: ffff800082109330 x16: 000000009fc9d337 x15: c0ffee00c0ffee00
[    2.035128] x14: c0ffee00c0ffee00 x13: c0ffee00c0ffee00 x12: c0ffee00c0ffee00
[    2.042252] x11: c0ffee00c0ffee00 x10: c0ffee00c0ffee00 x9 : c0ffee00c0ffee00
[    2.049376] x8 : c0ffee00c0ffee00 x7 : c0ffee00c0ffee00 x6 : c0ffee00c0ffee00
[    2.056500] x5 : ffff0000043ce400 x4 : ffff8000823d5000 x3 : 000000003f0015fc
[    2.063624] x2 : 00000000c0ffee00 x1 : ffff8000433d3e04 x0 : ffff8000823d5000
[    2.070748] Call trace:
[    2.073185]  rproc_handle_resources.constprop.0+0x64/0x18c
[    2.078661]  rproc_boot+0x37c/0x57c
[    2.082136]  rproc_add+0x144/0x17c
[    2.085525]  imx_rproc_probe+0x4d0/0x5e0
[    2.089433]  platform_probe+0x68/0xc8
[    2.093091]  really_probe+0x148/0x2b0
[    2.096739]  __driver_probe_device+0x78/0x12c
[    2.101081]  driver_probe_device+0x3c/0x15c
[    2.105250]  __device_attach_driver+0xb8/0x134
[    2.109679]  bus_for_each_drv+0x88/0xe8
[    2.113501]  __device_attach+0xa0/0x190
[    2.117323]  device_initial_probe+0x14/0x20
[    2.121491]  bus_probe_device+0xac/0xb0
[    2.125313]  deferred_probe_work_func+0x80/0xb8
[    2.129829]  process_one_work+0x138/0x248
[    2.133833]  worker_thread+0x320/0x438
[    2.137568]  kthread+0x110/0x114
[    2.140783]  ret_from_fork+0x10/0x20
[    2.144357] Code: 6b020063 8b22c098 91001301 540007c4 (b862c880) 
[    2.150431] ---[ end trace 0000000000000000 ]---

We suspect that this is a memory address issue, so we tried reserving the M33 address in the Device Tree Source (DTS) as shown below:

	reserved-memory {
		#address-cells = <2>;
		#size-cells = <2>;
		ranges;

		linux,cma {
			compatible = "shared-dma-pool";
			reusable;
			alloc-ranges = <0 0x80000000 0 0x40000000>;
			size = <0 0x10000000>;
			linux,cma-default;
		};

		ethosu_mem: ethosu_region@C0000000 {
			compatible = "shared-dma-pool";
			reusable;
			reg = <0x0 0xC0000000 0x0 0x10000000>;
		};

		vdev0vring0: vdev0vring0@a4000000 {
			reg = <0 0xa4000000 0 0x8000>;
			no-map;
		};

		vdev0vring1: vdev0vring1@a4008000 {
			reg = <0 0xa4008000 0 0x8000>;
			no-map;
		};

		vdev1vring0: vdev1vring0@a4010000 {
			reg = <0 0xa4010000 0 0x8000>;
			no-map;
		};

		vdev1vring1: vdev1vring1@a4018000 {
			reg = <0 0xa4018000 0 0x8000>;
			no-map;
		};

		rsc_table: rsc-table@2021e000 {
			reg = <0 0x2021e000 0 0x1000>;
			no-map;
		};

		vdevbuffer: vdevbuffer@a4020000 {
			compatible = "shared-dma-pool";
			reg = <0 0xa4020000 0 0x100000>;
			no-map;
		};

		ele_reserved: ele-reserved@a4120000 {
			compatible = "shared-dma-pool";
			reg = <0 0xa4120000 0 0x100000>;
			no-map;
		};

                cm33_reserved: cm33_reserved@1ffe0000 {
                        compatible = "shared-dma-pool";
                        reg = <0 0x1ffe0000 0 0x10000>;
                        no-map;
                };	
	};

Despite these changes, the issue persists. We would greatly appreciate any suggestions or solutions from NXP regarding this problem.

Thank you in advance.

Best regards,

Vinisha.