AnsweredAssumed Answered

Boot Partition Problem to start M4 as a remote proccessor from A35

Question asked by David Kauschke on Apr 8, 2020
Latest reply on Apr 9, 2020 by David Kauschke



we are currently trying to use the M4 on the iMX8QX as coprocessor over the AP (kernel 4.14.98 is used).

For this purpose, mk-image is used to create only the A35 partition and no M4 partition. This partition should be created by the kernel.

(according to i.MX8 Boot process and creating a bootable image)

The boot flags are set to 0x00000000 so that no further HW partitioning is performed.


According to the SCFW Porting Guide SCFW it is the same procedure as in chapter 6.9.3 AP Boots M4.


In the first step the M4 Binary (TCM) is loaded into memory via uboot command line:

load mmc 1:1 0x80280000 /boot/m4_0.bin


Afterwards, netboot is used to start Linux over TFTP/NFS.


But you can also start the M4 (TCM memory is used) directly with

load mmc 1:1 0x80280000 /boot/m4_0.bin ; dcach flush ; bootaux 0x80280000 0

On the M4 UART the logs can be viewed.


In the kernel the partition for the M4 issuccessfully created. The necessary M4 resources are assigned to the M4 partition and a shared memory partition is created (TCM memory is used) .
All this is done by a kernel module. No error messages are thrown here. The following memory areas are created:


Memreg 2 0x34000000 -- 0x37ffffff /* TCM for M4 */
Memreg 3 0x70000000 -- 0x7fffffff
Memreg 5 0x400000000 -- 0x43fffffff
Memreg 6 0x880000000 -- 0xfffffffff
Memreg 7 0x92000000 -- 0xffffffff
Memreg 8 0x90000000 -- 0x91ffffff /* shared memory for M4/A45 */
Memreg 9 0x80020000 -- 0x87ffffff
Memreg 10 0x88000000 -- 0x8fffffff /* DDR for M4 */

Memreg 11 0x118000 -- 0x1bffffff


Memreg 2,10 are moved to the M4 partition.

Memreg 8 is the shared memory partition for Linux and M4 for RPMsg. Linux/M4 both have access to it.



The partition creation and resource allocation is taken from the article (System Controller Firmware 101 - Resource management service).

If the M4 partition is booted with the following command, the function returns without errors but a long error message is displayed (see below). However, the M4 core will not boot and no logs will be output on the M4 UART.


boot_err = sc_pm_boot(ipc,pt_m4_0,SC_R_M4_0_PID0,
check_error(boot_err, "sc_pm_boot");


The Linux will continue to run and you can still access and use the system over SSH.

Does anybody have an idea what could cause it to fail?


In the medium term the goal is to load/start/stop the M4 partition from linux with different firmwares over RemoteProc (lifecycle management) and to exchange data via RPMsg.

The openAMP framework will be used for this purpose.



Thank you for your answer in advance.


Best regards,



Error log when M4 Partition is booted from linux:


[  *** ] (3 of 5) A start job is running for…e Resolution (3min 48s / 4min 34s)INFO: task kworker/2:0H:25 blocked for more than 120 seconds.

      Not tainted 4.14.98-g111dc05-dirty #34

"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

kworker/2:0H    D    0    25      2 0x00000000

Workqueue: kblockd blk_mq_run_work_fn

Call trace:

[<ffff000008085344>] __switch_to+0x94/0xd8

[<ffff0000087d01d4>] __schedule+0x18c/0x4e8

[<ffff0000087d0568>] schedule+0x38/0xa0

[<ffff0000085b1bd8>] __mmc_claim_host+0x98/0x210

[<ffff0000085b1d80>] mmc_get_card+0x30/0x40

[<ffff0000085c6b4c>] mmc_mq_queue_rq+0x1fc/0x258

[<ffff00000834229c>] blk_mq_dispatch_rq_list+0x31c/0x3a0

[<ffff0000083463c4>] blk_mq_sched_dispatch_requests+0x1ac/0x228

[<ffff000008340684>] __blk_mq_run_hw_queue+0xa4/0x118

[<ffff000008340758>] blk_mq_run_work_fn+0x60/0x70

[<ffff0000080b93fc>] process_one_work+0x1d4/0x348

[<ffff0000080b95b8>] worker_thread+0x48/0x470

[<ffff0000080bf624>] kthread+0x12c/0x130

[<ffff0000080846d8>] ret_from_fork+0x10/0x18

INFO: task kworker/0:1:34 blocked for more than 120 seconds.

      Not tainted 4.14.98-g111dc05-dirty #34

"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

kworker/0:1     D    0    34      2 0x00000000

Workqueue: events_freezable thermal_zone_device_check