linux-kernel - Re: [PATCH v4 3/3] remoteproc: imx_rproc: detect and attach to pre-booted remote cores

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250617023958.GB30636@nxa18884-linux>
Date: Tue, 17 Jun 2025 10:39:58 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Hiago De Franco <hiagofranco@...il.com>
Cc: Peng Fan <peng.fan@....com>,
	Mathieu Poirier <mathieu.poirier@...aro.org>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"linux-remoteproc@...r.kernel.org" <linux-remoteproc@...r.kernel.org>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Bjorn Andersson <andersson@...nel.org>,
	Hiago De Franco <hiago.franco@...adex.com>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Daniel Baluta <daniel.baluta@....com>,
	"Iuliana Prodan (OSS)" <iuliana.prodan@....nxp.com>,
	"Rafael J . Wysocki" <rafael@...nel.org>
Subject: Re: [PATCH v4 3/3] remoteproc: imx_rproc: detect and attach to
 pre-booted remote cores

On Mon, Jun 16, 2025 at 01:05:11PM -0300, Hiago De Franco wrote:
>Hi Peng,
>
>On Thu, Jun 12, 2025 at 02:03:17PM -0300, Hiago De Franco wrote:
>> Hi Peng,
>> 
>> On Wed, Jun 11, 2025 at 03:27:09AM +0000, Peng Fan wrote:
>> > > 
>> > > Sorry for the delay.
>> > > 
>> > > I tested it now and there must be something missing on my U-Boot:
>> > > 
>> > > Disable imx8x-cm4 rsrc 278 not owned
>> > > Disable imx8x-cm4 rsrc 297 not owned
>> > > 
>> > > It removes my nodes from the DT before starting the kernel, so I cannot
>> > > attach. Do you know what should I do in this case?
>> > 
>> > In separate partition case, UBoot will check the permission
>> > by checking the rsrc-id, saying power domain id.
>> > 
>> > You may need to remove the power-domains property
>> > from M4 node.
>> 
>> Without the power-domains property, rproc gives me a kernel panic:
>> 
>> [    1.253234] remoteproc remoteproc0: imx-rproc is available
>> [    1.258501] remoteproc remoteproc0: attaching to imx-rproc
>> [    1.263950] Unable to handle kernel paging request at virtual address ffff80005ae57d39
>> [    1.271812] Mem abort info:
>> [    1.274575]   ESR = 0x0000000096000005
>> [    1.278299]   EC = 0x25: DABT (current EL), IL = 32 bits
>> [    1.282581] mmc0: SDHCI controller on 5b010000.mmc [5b010000.mmc] using ADMA
>> [    1.283607]   SET = 0, FnV = 0
>> [    1.293701]   EA = 0, S1PTW = 0
>> [    1.296815]   FSC = 0x05: level 1 translation fault
>> [    1.301699] Data abort info:
>> [    1.304545]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
>> [    1.310079]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
>> [    1.315073]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
>> [    1.320367] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000096bf3000
>> [    1.327061] [ffff80005ae57d39] pgd=0000000000000000, p4d=1000000097085003, pud=0000000000000000
>> [    1.335750] Internal error: Oops: 0000000096000005 [#1]  SMP
>> [    1.341373] Modules linked in:
>> [    1.344414] CPU: 3 UID: 0 PID: 47 Comm: kworker/u16:3 Not tainted 6.16.0-rc1-00024-gfe5d6ab20714-dirty
>>  #857 PREEMPT
>> [    1.354932] Hardware name: Toradex Colibri iMX8QXP on Colibri Evaluation Board V3 (DT)
>> [    1.362837] Workqueue: events_unbound deferred_probe_work_func
>> [    1.368651] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
>> [    1.375601] pc : rproc_handle_resources.constprop.0+0x78/0x1d0
>> [    1.381421] lr : rproc_boot+0x368/0x578
>> [    1.385242] sp : ffff8000819f3990
>> [    1.388542] x29: ffff8000819f3990 x28: ffff80005ae57d3d x27: 0000000000000000
>> [    1.395671] x26: 0000000000000000 x25: ffff0000016ee038 x24: ffff800080f3c680
>> [    1.402793] x23: ffff8000813d6da8 x22: 00000000d999ad39 x21: ffff0000016ee000
>> [    1.409917] x20: 00000000266656c3 x19: ffff80005ae57d39 x18: 0000000000000006
>> [    1.417040] x17: ffff000002020600 x16: ffff000002020000 x15: 4addd15cca11c529
>> [    1.424164] x14: 73ebceed5d6cd787 x13: 4addd15cca11c529 x12: 73ebceed5d6cd787
>> [    1.431288] x11: 95a4e33b6b190664 x10: 9e3cdabdb09ca345 x9 : ab3734eafdd6fd1c
>> [    1.438412] x8 : d58a055de4cfb385 x7 : de97fab1791acbbe x6 : 9946d97107d0dcda
>> [    1.445535] x5 : ffff0000032b2c00 x4 : 00000000000003fc x3 : ffff0000032b2b80
>> [    1.452659] x2 : fffffffffffffff0 x1 : ffff8000814bd000 x0 : ffff8000814bd000
>> [    1.459786] Call trace:
>> [    1.462215]  rproc_handle_resources.constprop.0+0x78/0x1d0 (P)
>> [    1.468036]  rproc_boot+0x368/0x578
>> [    1.471510]  rproc_add+0x180/0x18c
>> [    1.474898]  imx_rproc_probe+0x3e4/0x540
>> [    1.475274] mmc0: new HS400 MMC card at address 0001
>> [    1.478799]  platform_probe+0x68/0xc0
>> [    1.484628] mmcblk0: mmc0:0001 Q2J55L 7.09 GiB
>> [    1.487400]  really_probe+0xc0/0x38c
>> [    1.487412]  __driver_probe_device+0x7c/0x15c
>> [    1.487424]  driver_probe_device+0x3c/0x10c
>> [    1.493941]  mmcblk0: p1 p2
>> [    1.495392]  __device_attach_driver+0xbc/0x158
>> [    1.495405]  bus_for_each_drv+0x84/0xe0
>> [    1.495417]  __device_attach+0x9c/0x1ac
>> [    1.500468] mmcblk0boot0: mmc0:0001 Q2J55L 16.0 MiB
>> [    1.503906]  device_initial_probe+0x14/0x20
>> [    1.503918]  bus_probe_device+0xac/0xb0
>> [    1.503929]  deferred_probe_work_func+0x9c/0xec
>> [    1.509863] mmcblk0boot1: mmc0:0001 Q2J55L 16.0 MiB
>> [    1.511117]  process_one_work+0x14c/0x28c
>> [    1.511132]  worker_thread+0x2cc/0x3d4
>> [    1.511142]  kthread+0x12c/0x208
>> [    1.511157]  ret_from_fork+0x10/0x20
>> [    1.517964] mmcblk0rpmb: mmc0:0001 Q2J55L 4.00 MiB, chardev (241:0)
>> [    1.518770] Code: 8b36c033 9100127c 54000924 d503201f (b9400261)
>> [    1.518777] ---[ end trace 0000000000000000 ]---
>> 
>> Currently I have the M4 partiton defined into the SCU code:
>> 
>>             /* Create partition */
>>             BRD_ERR(rm_partition_create(pt_boot, &pt_m4_0, SC_FALSE,
>>                 SC_TRUE, SC_FALSE, SC_TRUE, SC_FALSE, SC_R_M4_0_PID0,
>>                 rsrc_list, ARRAY_SIZE(rsrc_list),
>>                 pad_list, ARRAY_SIZE(pad_list),
>>                 NULL, 0));
>> 
>>             /* Name partition for debug */
>>             PARTITION_NAME(pt_m4_0, "MCU0");
>>             
>>             /* Allow AP to use SYSTEM (not production!) */
>>             BRD_ERR(rm_set_peripheral_permissions(SC_PT, SC_R_SYSTEM,
>>                 pt_boot, SC_RM_PERM_SEC_RW));
>> 
>>             /* Move M4 0 TCM */
>>             BRD_ERR(rm_find_memreg(pt_boot, &mr, 0x034FE0000ULL,
>>                 0x034FE0000ULL));
>>             BRD_ERR(rm_assign_memreg(pt_boot, pt_m4_0, mr));
>> 
>>             /* Move partition to be owned by SC */
>>             BRD_ERR(rm_set_parent(pt_boot, pt_m4_0, SC_PT));
>> 
>>             /* Check if booting with the no_ap flag set */
>>             if (no_ap != SC_FALSE)
>>             {
>>                 /* Move boot to be owned by M4 0 for Android Automotive */
>>                 BRD_ERR(rm_set_parent(SC_PT, pt_boot, pt_m4_0));
>>             }
>>         }
>> 
>>         /* Allow all to access the SEMA42s */
>>         BRD_ERR(rm_set_peripheral_permissions(SC_PT, SC_R_M4_0_SEMA42,
>>             SC_RM_PT_ALL, SC_RM_PERM_FULL));
>> 
>> I believe this SCU code is correct, at least this is more or less what
>> NXP provides as example, right?
>
>I tested the same SCU code and DTS overlay (removing the power-domains)
>with the current master branch of Linux and I got the same kernel panic.
>Maybe this part is already broken? Can you also test this on your side
>to check if this is currently working?

Does your M4 publish a resource table when M4 image built in flash.bin?

There is no common method to verify whether resource table is valid,
so if your M4 image not publish a resource table, there maybe garbage
data in it, so rproc_handle_resources may crash. NXP downstream
added a sanity check in lf-6.12 Q1 release, you may give a look.

Regards,
Peng

>
>> 
>> Best Regards,
>> Hiago.
>
>Best Regards,
>Hiago.