Hello Peng, On Fri, Oct 09, 2026 at 12:27:37PM +0800, Peng Fan wrote: > On Wed, Sep 23, 2026 at 08:42:23PM +0200, Francesco Valla wrote: > >On Wed, Sep 23, 2026 at 09:48:58AM -0600, Mathieu Poirier wrote: > >> On Tue, Sep 22, 2026 at 10:19:48PM +0200, Francesco Valla wrote: > >> > On Tue, Sep 22, 2026 at 09:43:52AM -0600, Mathieu Poirier wrote: > >> > > On Wed, Sep 16, 2026 at 11:10:57PM +0200, Francesco Valla wrote: > >> > > > Add rings for multiple vdevs, as well as the required virtio nodes > >> > > > for > >> > > > I2C, SPI and GPIO functionalities. On top of that, add example > >> > > > peripherals using all of them. > >> > > > > >> > > > NOTE: this is a Proof-Of-Concept, not meant to be integrated! > >> > > > > >> > > > Signed-off-by: Francesco Valla <[email protected]> > >> > > > --- > >> > > > arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts | 128 > >> > > > +++++++++++++++++++-- > >> > > > 1 file changed, 119 insertions(+), 9 deletions(-) > >> > > > > >> > > > diff --git a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts > >> > > > b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts > >> > > > index bd14ba28690c..dfa3b122ac5f 100644 > >> > > > --- a/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts > >> > > > +++ b/arch/arm64/boot/dts/freescale/imx93-11x11-frdm.dts > >> > > > @@ -53,6 +53,32 @@ button-k3 { > >> > > > }; > >> > > > }; > >> > > > > >> > > > + gpio-keys-virtio { > >> > > > + compatible = "gpio-keys-polled"; > >> > > > + poll-interval = <100>; > >> > > > + > >> > > > + button-v1 { > >> > > > + label = "Button V1"; > >> > > > + linux,code = <BTN_3>; > >> > > > + gpios = <&v_gpio 23 GPIO_ACTIVE_LOW>; > >> > > > + }; > >> > > > + > >> > > > + button-v2 { > >> > > > + label = "Button V2"; > >> > > > + linux,code = <BTN_4>; > >> > > > + gpios = <&v_gpio 24 GPIO_ACTIVE_LOW>; > >> > > > + }; > >> > > > + }; > >> > > > + > >> > > > + leds { > >> > > > + compatible = "gpio-leds"; > >> > > > + > >> > > > + led { > >> > > > + gpios = <&v_gpio 18 GPIO_ACTIVE_HIGH>; > >> > > > + label = "LED V"; > >> > > > + }; > >> > > > + }; > >> > > > + > >> > > > reg_usdhc2_vmmc: regulator-usdhc2 { > >> > > > compatible = "regulator-fixed"; > >> > > > off-on-delay-us = <12000>; > >> > > > @@ -89,11 +115,6 @@ linux,cma { > >> > > > linux,cma-default; > >> > > > }; > >> > > > > >> > > > - rsc_table: rsc-table@2021e000 { > >> > > > - reg = <0 0x2021e000 0 0x1000>; > >> > > > - no-map; > >> > > > - }; > >> > > > - > >> > > > >> > > Why is the resource table removed? There is no mention of that in the > >> > > changelog... > >> > > > >> > > >> > You are obviously right, the commit message here should have been a > >> > poem, not a form of hermetic poetry. My bad. > >> > > >> > The resource table here is causing problems with how Zephyr is managing > >> > it at its side. If it is kept in a separate memory location and copied > >> > there at runtime by the remote processor firmware during its startup > >> > (which is the current Zephyr behavior), then there might be a race > >> > condition when the aforesaid firmware is loaded and started by Linux > >> > *and* at least one of the vdev drivers (here including rpmsg_bus) is > >> > built-in. In this case, the copy of the resource table done by the > >> > remote processor might - depending on the async execution of the two > >> > processors - overwrite the status bit set by the Linux driver: > >> > > >> > Firmware load and startup (echo start > /sys/.../state) > >> > | > >> > | > >> > V > >> > The vdev devices get registered (by register_virtio_device()) > >> > | > >> > | > >> > V > >> > If a driver is built-in, it probes and sets the vdev status > >> > inside the resource table @rsc-table. > >> > . > >> > . (in the mean time) > >> > . > >> > The remote processor starts up and copies the resource table from its > >> > dedicated section to @rsc-table. > >> > > >> > Depending on the system load and the complexity of the firmware, the two > >> > operations can happen in whatever sequence, causing a race condition. > >> > >> This would happen regardless of this patchset. > >> > > > >Correct, *if* the remote processor is copying the resource table to a > >specific location and expects the host to use that. On Zephyr (which is > >clearly outside the scope here) this can be enabled through the > >CONFIG_OPENAMP_COPY_RSC_TABLE option. I am keeping that disabled, and > >removing the rsc-table node here. > > > >I am planning to reason on this and propose a proper fix in a separate > >patchset. > > The previous workaround for this was to add a delay in start function. > > https://lore.kernel.org/all/[email protected]/ > https://lore.kernel.org/linux-remoteproc/[email protected]/ >
That would *kind of* work, but it's clearly unfit for upstream. > > > >> > > >> > This is somewhat masked if vdev drivers are built as modules, as the > >> > devices does not probe immediately but only after the modules have been > >> > loaded, giving the remote processor time to start. Note that this is not > >> > a solution! but a workaround. > >> > > >> > If the rsc-table node is not there, the startup logic falls back to the > >> > classic rproc_elf_find_loaded_rsc_table(). > >> > >> We can't remove @rsc-table to make a problem go away. > >> > > > >I need to re-take a look at the NXP SDK to understand what's the real > >purpose of having the rsc-table here. Judging from the commit message > >that introduced support for such facility [1], it seems the SDK is not > >really using it. > > > >Maybe someone from NXP can comment on this? > > Linux needs to parse resource table to setup vring. When RPROC(remote > processor) > is booted by ROM or System Manager, there is no elf for Linux to use, so a > pre-defined address is used rsc-table. > Yes, that's clear, or it wouldn't know where to find the resource table. > > If RPROC is booted by Linux using remoteproc, rsc-table in DT is not needed. > But RPROC is not aware it is booted by ROM, U-Boot, Linux. So it will always > publish the resource table to rsc-table address. > > And we need one DTB/Image to support mutiple boot cases. > That's also clear. However, current setup for i.MX93 platforms is not really working for the Linux+Zephyr case, or at least not in all conditions. If the firmware is loaded and started by the Linux kernel, the resource table is copied to the rsc-table address before the CM33 is started. However, at the beginning of its boot process, the CM33 itself will clear its DTCM memory [1] to avoid ECC failures, actually overriding the resource table the Linux kernel just wrote there. (Note that I linked only the Zephyr case, but the official NXP SDK has a similar routine). Regardless of what the CM33 does after (i.e., even if it copies the resource table to the same location), it will lose any update the Linux kernel did in the mean time to the resource table. If e.g. the virtio_rpmsg_bus module is built-in, the readiness of the rpmsg stack at Linux side will be lost most of the times. This is probably working fine for firmwares based on the rpmsg-lite library by NXP, which AFAICT doesn't use the status bits found inside the resource table, but it's interfering with the way the OpenAMP stack works. ATM I do not have a solution to propose. I'm still thinking about it. In the mean time, I decided to load and boot the CM33 firmware before the Linux kernel starts. > Hope this explains. > > Regards > Peng Thank you! Regards, Francesco [1] https://github.com/zephyrproject-rtos/zephyr/blob/main/soc/nxp/imx/imx9/imx93/m33/imx93_m33_startup.S#L18
