Re: [PATCH v3 3/5] remoteproc: k3-r5: Add support for IPC-only mode for all R5Fs
flat view
From: Jan Kiszka <jan.kiszka@siemens.com>
Date: 2023-11-02 10:07:58
Also in:
linux-remoteproc, lkml
On 13.02.22 21:12, Suman Anna wrote:
Add support to the K3 R5F remoteproc driver to configure all the R5F cores to be either in IPC-only mode or the traditional remoteproc mode. The IPC-only mode expects that the remote processors are already booted by the bootloader, and only performs the minimum steps required to initialize and deinitialize the virtio IPC transports. The remoteproc mode allows the kernel remoteproc driver to do the regular load and boot and other device management operations for a R5F core. The IPC-only mode for a R5F core is detected and configured at driver probe time by querying the System Firmware for the R5F power and reset state and/or status and making sure that the R5F core is indeed started by the bootloaders, otherwise the device is configured for remoteproc mode. Support for IPC-only mode is achieved through .attach(), .detach() and .get_loaded_rsc_table() callback ops and zeroing out the regular rproc ops .prepare(), .unprepare(), .start() and .stop(). The resource table follows a design-by-contract approach and is expected to be at the base of the DDR firmware region reserved for each remoteproc, it is mostly expected to contain only the virtio device and trace resource entries. NOTE: The driver cannot configure a R5F core for remoteproc mode by any means without rebooting the kernel if that R5F core has been started by a bootloader. This is the current desired behavior and can be enhanced in the future if the feature is needed.
This change surfaced some complex issue in the K3 core: Turning on the RTI1 watchdog also powers up R5F core 1. And this could happen either in U-Boot or in the kernel. If the kernel finds the core running, it also expects a resource table in the reserved RAM. But as the core is supposed to start via remoteproc, there is none, rather often garbage. Sometimes, a consistency check catches that, but not always: [ 38.372844] remoteproc remoteproc18: 41000000.r5f is available [ 38.380324] platform 41400000.r5f: R5F core may have been powered on by a different host, programmed state (0) != actual state (1) [ 38.394910] platform 41400000.r5f: configured R5F for IPC-only mode [ 38.401941] platform 41400000.r5f: assigned reserved memory node r5f-dma-memory@a1000000 [ 38.476997] remoteproc remoteproc19: 41400000.r5f is available [ 38.484661] remoteproc remoteproc19: attaching to 41400000.r5f [ 38.491092] Unable to handle kernel paging request at virtual address ffff80000dffffff [ 38.503704] Mem abort info: [ 38.509760] ESR = 0x0000000096000007 [ 38.514071] EC = 0x25: DABT (current EL), IL = 32 bits [ 38.519578] SET = 0, FnV = 0 [ 38.523095] EA = 0, S1PTW = 0 [ 38.526355] FSC = 0x07: level 3 translation fault [ 38.528974] cal 6f03000.cal: Neither port is configured, no point in staying up [ 38.531775] Data abort info: [ 38.541866] ISV = 0, ISS = 0x00000007 [ 38.545765] CM = 0, WnR = 0 [ 38.548814] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000082fdc000 [ 38.555831] [ffff80000dffffff] pgd=10000008fffff003, p4d=10000008fffff003, pud=10000008ffffe003, pmd=1000000886609003, pte=0000000000000000 [ 38.568623] remoteproc remoteproc18: powering up 41000000.r5f [ 38.569338] Internal error: Oops: 0000000096000007 [#1] PREEMPT SMP [ 38.574440] remoteproc remoteproc18: Booting fw image am65x-mcu-r5f0_0-fw, size 932 [ 38.580644] Modules linked in: usbserial ti_cal videobuf2_dma_contig ti_k3_r5_remoteproc(+) videobuf2_memops pci_endpoint_test videobuf2_v4l2 rti_wdt watchdog videobuf2_common at24 st_lsm6dsx_i2c(+) optee_rng st_lsm6dsx kfifo_buf pm16d17 rng_core tee_stmm_efi tpm_ftpm_tee fuse dm_mod ip_tables x_tables ipv6 [ 38.589862] remoteproc remoteproc18: remote processor 41000000.r5f is now up [ 38.615533] CPU: 1 PID: 283 Comm: (udev-worker) Not tainted 6.1.54-cip6 #1 [ 38.615546] Hardware name: SIMATIC IOT2050 Advanced PG2 (DT) [ 38.615553] pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 38.641945] pc : rproc_handle_resources.constprop.0+0x8c/0x164 [ 38.647788] lr : rproc_boot+0x2fc/0x57c [ 38.651628] sp : ffff800009d53740 [ 38.654934] x29: ffff800009d53740 x28: ffff00087f7d77f8 x27: ffff0008048f4c10 [ 38.662068] x26: 0000000000000001 x25: ffffffffffffffff x24: ffff80000e000000 [ 38.669199] x23: ffff00080227e038 x22: 0000000000000000 x21: ffff8000092bb1b0 [ 38.676333] x20: ffff00080227e000 x19: 0000000000000000 x18: 000000000000028e [ 38.683464] x17: 0000000000000000 x16: 000000006d958cac x15: ffffffffffffffff [ 38.690597] x14: ffffffffffffffff x13: ffffffffffffffff x12: ffffffffffffffff [ 38.697728] x11: ffffffffffffffff x10: ffffffffffffffff x9 : ffffffffbfffffff [ 38.704862] x8 : ffffffffffffffff x7 : fffffdffffffffff x6 : ffffffffffdfffff [ 38.711994] x5 : ffff000802be1f00 x4 : ffff80000e000100 x3 : 00000000000000fd [ 38.719127] x2 : 00000000ffffffff x1 : ffff80000e000003 x0 : ffff80000e000000 [ 38.726260] Call trace: [ 38.728703] rproc_handle_resources.constprop.0+0x8c/0x164 [ 38.734196] rproc_boot+0x2fc/0x57c [ 38.737689] rproc_add+0xcc/0x16c [ 38.741004] k3_r5_probe+0x44c/0xe14 [ti_k3_r5_remoteproc] [ 38.746501] platform_probe+0x68/0xc0 [ 38.750168] really_probe+0xbc/0x2dc [ 38.753742] __driver_probe_device+0x78/0x114 [ 38.758099] driver_probe_device+0xd8/0x15c [ 38.762282] __driver_attach+0x94/0x19c [ 38.766119] bus_for_each_dev+0x74/0xd0 [ 38.769954] driver_attach+0x24/0x30 [ 38.773529] bus_add_driver+0x154/0x20c [ 38.777363] driver_register+0x78/0x130 [ 38.781198] __platform_driver_register+0x28/0x34 [ 38.785901] k3_r5_rproc_driver_init+0x20/0x1000 [ti_k3_r5_remoteproc] [ 38.792437] do_one_initcall+0x64/0x1dc [ 38.796272] do_init_module+0x48/0x1d0 [ 38.800023] load_module+0x185c/0x1cc4 [ 38.803770] __do_sys_finit_module+0xa8/0xfc [ 38.808040] __arm64_sys_finit_module+0x20/0x30 [ 38.812571] invoke_syscall+0x48/0x114 [ 38.816320] el0_svc_common.constprop.0+0xcc/0xec [ 38.821053] do_el0_svc+0x2c/0xd0 [ 38.821077] el0_svc+0x2c/0x84 [ 38.821095] el0t_64_sync_handler+0xf4/0x120 [ 38.831698] el0t_64_sync+0x18c/0x190 (this crash was with a stable kernel, but same issue with head of tree) This raises several questions: - Is it a hardware property that RTI1 powers up core 1 as well? - If so, how can we use both watchdog and remoteproc so that the latter loads the firmware for the former? We are currently doing that from U-Boot, but what if that is not desired? Should the watchdog driver take care to not leave core 1 in a different power state behind? - Can and should we do more while parsing the resource table to prevent such crashes? Jan -- Siemens AG, Technology Linux Expert Center _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel