Add C906L remote processor for CV1800B SoC, which is an asymmetric
processor typically running RTOS.
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
---
.../bindings/remoteproc/sophgo,cv1800b-c906l.yaml | 79 ++++++++++++++++++++++
1 file changed, 79 insertions(+)
diff --git a/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..2061c2fd6ba343c09b1a91700ea4a695d2b57f81
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/remoteproc/sophgo,cv1800b-c906l.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Sophgo C906L remote processor controller for CV1800B SoC
+
+maintainers:
+ - Junhui Liu <junhui.liu@pigmoral.tech>
+
+description:
+ Document the bindings for the C906L remoteproc component that loads and boots
+ firmwares on the CV1800B SoC.
+
+properties:
+ compatible:
+ const: sophgo,cv1800b-c906l
+
+ firmware-name:
+ maxItems: 1
+
+ mbox-names:
+ items:
+ - const: tx
+ - const: rx
+
+ mboxes:
+ description:
+ This property is required only if the rpmsg/virtio functionality is used.
+ (see mailbox/sophgo,cv1800b-mailbox.yaml)
+ items:
+ - description: mailbox channel to send data to C906L
+ - description: mailbox channel to receive data from C906L
+
+ memory-region:
+ description:
+ List of phandles to reserved memory regions used by the remote processor.
+ The first region is required and provides the firmware region for the
+ remote processor. The following regions (vdev buffer, vrings) are optional
+ and are only required if rpmsg/virtio functionality is used.
+ minItems: 1
+ items:
+ - description: firmware region
+ - description: vdev buffer
+ - description: vring0
+ - description: vring1
+ additionalItems: true
+
+ resets:
+ maxItems: 1
+
+ sophgo,syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description:
+ A phandle to the SEC_SYS region, used for configuration of the remote
+ processor.
+
+required:
+ - compatible
+ - firmware-name
+ - memory-region
+ - resets
+ - sophgo,syscon
+
+additionalProperties: false
+
+examples:
+ - |
+ c906l-rproc {
+ compatible = "sophgo,cv1800b-c906l";
+ firmware-name = "c906l-firmware.elf";
+ mbox-names = "tx", "rx";
+ mboxes = <&mbox 0 2>, <&mbox 1 1>;
+ memory-region = <&c906l_mem>, <&vdev0buffer>,
+ <&vdev0vring0>, <&vdev0vring1>;
+ resets = <&rst 294>;
+ sophgo,syscon = <&sec_sys>;
+ };
--
2.50.1On Mon, Jul 28, 2025 at 07:03:23PM +0800, Junhui Liu wrote: > Add C906L remote processor for CV1800B SoC, which is an asymmetric > processor typically running RTOS. > > Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> > --- > .../bindings/remoteproc/sophgo,cv1800b-c906l.yaml | 79 ++++++++++++++++++++++ > 1 file changed, 79 insertions(+) > > diff --git a/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml > new file mode 100644 > index 0000000000000000000000000000000000000000..2061c2fd6ba343c09b1a91700ea4a695d2b57f81 > --- /dev/null > +++ b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml > @@ -0,0 +1,79 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/remoteproc/sophgo,cv1800b-c906l.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Sophgo C906L remote processor controller for CV1800B SoC > + > +maintainers: > + - Junhui Liu <junhui.liu@pigmoral.tech> > + > +description: > + Document the bindings for the C906L remoteproc component that loads and boots > + firmwares on the CV1800B SoC. > + > +properties: > + compatible: > + const: sophgo,cv1800b-c906l > + > + firmware-name: > + maxItems: 1 > + > + mbox-names: > + items: > + - const: tx > + - const: rx > + > + mboxes: > + description: > + This property is required only if the rpmsg/virtio functionality is used. > + (see mailbox/sophgo,cv1800b-mailbox.yaml) > + items: > + - description: mailbox channel to send data to C906L > + - description: mailbox channel to receive data from C906L > + > + memory-region: > + description: > + List of phandles to reserved memory regions used by the remote processor. > + The first region is required and provides the firmware region for the > + remote processor. The following regions (vdev buffer, vrings) are optional > + and are only required if rpmsg/virtio functionality is used. > + minItems: 1 > + items: > + - description: firmware region > + - description: vdev buffer > + - description: vring0 > + - description: vring1 > + additionalItems: true > + Why not allocating these region dynamicly? I do not think firware is always avaible before staring. Allowing dynamic firmware give us max flexiblity. Regards, Inochi
On 29/07/2025 16:31, Inochi Amaoto wrote: > On Mon, Jul 28, 2025 at 07:03:23PM +0800, Junhui Liu wrote: >> Add C906L remote processor for CV1800B SoC, which is an asymmetric >> processor typically running RTOS. >> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> >> --- >> .../bindings/remoteproc/sophgo,cv1800b-c906l.yaml | 79 ++++++++++++++++++++++ >> 1 file changed, 79 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml >> new file mode 100644 >> index 0000000000000000000000000000000000000000..2061c2fd6ba343c09b1a91700ea4a695d2b57f81 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml >> @@ -0,0 +1,79 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/remoteproc/sophgo,cv1800b-c906l.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Sophgo C906L remote processor controller for CV1800B SoC >> + >> +maintainers: >> + - Junhui Liu <junhui.liu@pigmoral.tech> >> + >> +description: >> + Document the bindings for the C906L remoteproc component that loads and boots >> + firmwares on the CV1800B SoC. >> + >> +properties: >> + compatible: >> + const: sophgo,cv1800b-c906l >> + >> + firmware-name: >> + maxItems: 1 >> + >> + mbox-names: >> + items: >> + - const: tx >> + - const: rx >> + >> + mboxes: >> + description: >> + This property is required only if the rpmsg/virtio functionality is used. >> + (see mailbox/sophgo,cv1800b-mailbox.yaml) >> + items: >> + - description: mailbox channel to send data to C906L >> + - description: mailbox channel to receive data from C906L >> + >> + memory-region: >> + description: >> + List of phandles to reserved memory regions used by the remote processor. >> + The first region is required and provides the firmware region for the >> + remote processor. The following regions (vdev buffer, vrings) are optional >> + and are only required if rpmsg/virtio functionality is used. >> + minItems: 1 >> + items: >> + - description: firmware region >> + - description: vdev buffer >> + - description: vring0 >> + - description: vring1 >> + additionalItems: true >> + > > Why not allocating these region dynamicly? I do not think firware is > always avaible before staring. Allowing dynamic firmware give us max > flexiblity. I'm afraid it's not easy to do this. For firmware region, the RTOS firmware usually needs a physical address to link to, and I have researched and tested two RTOS (RT-Thread and Zephyr) on the C906L, both of them do not support position-independent execution or runtime relocation. Therefore, a reserved memory region is needed to provide a fixed physical address for the RTOS firmware. (In fact, there is already a reserved memory region for the C906L in cv1800b-milkv-duo.dts) For virtio-related regions, the RTOS firmware also needs to know the shared memory regions for communications at compile time. So, reserving memory through DT is necessary for now. > > Regards, > Inochi -- Best regards, Junhui Liu
On Wed, Jul 30, 2025 at 03:57:09AM +0000, Junhui Liu wrote: > On 29/07/2025 16:31, Inochi Amaoto wrote: > > On Mon, Jul 28, 2025 at 07:03:23PM +0800, Junhui Liu wrote: > >> Add C906L remote processor for CV1800B SoC, which is an asymmetric > >> processor typically running RTOS. > >> > >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> > >> --- > >> .../bindings/remoteproc/sophgo,cv1800b-c906l.yaml | 79 ++++++++++++++++++++++ > >> 1 file changed, 79 insertions(+) > >> > >> diff --git a/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml > >> new file mode 100644 > >> index 0000000000000000000000000000000000000000..2061c2fd6ba343c09b1a91700ea4a695d2b57f81 > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml > >> @@ -0,0 +1,79 @@ > >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > >> +%YAML 1.2 > >> +--- > >> +$id: http://devicetree.org/schemas/remoteproc/sophgo,cv1800b-c906l.yaml# > >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> + > >> +title: Sophgo C906L remote processor controller for CV1800B SoC > >> + > >> +maintainers: > >> + - Junhui Liu <junhui.liu@pigmoral.tech> > >> + > >> +description: > >> + Document the bindings for the C906L remoteproc component that loads and boots > >> + firmwares on the CV1800B SoC. > >> + > >> +properties: > >> + compatible: > >> + const: sophgo,cv1800b-c906l > >> + > >> + firmware-name: > >> + maxItems: 1 > >> + > >> + mbox-names: > >> + items: > >> + - const: tx > >> + - const: rx > >> + > >> + mboxes: > >> + description: > >> + This property is required only if the rpmsg/virtio functionality is used. > >> + (see mailbox/sophgo,cv1800b-mailbox.yaml) > >> + items: > >> + - description: mailbox channel to send data to C906L > >> + - description: mailbox channel to receive data from C906L > >> + > >> + memory-region: > >> + description: > >> + List of phandles to reserved memory regions used by the remote processor. > >> + The first region is required and provides the firmware region for the > >> + remote processor. The following regions (vdev buffer, vrings) are optional > >> + and are only required if rpmsg/virtio functionality is used. > >> + minItems: 1 > >> + items: > >> + - description: firmware region > >> + - description: vdev buffer > >> + - description: vring0 > >> + - description: vring1 > >> + additionalItems: true > >> + > > > > Why not allocating these region dynamicly? I do not think firware is > > always avaible before staring. Allowing dynamic firmware give us max > > flexiblity. > > I'm afraid it's not easy to do this. > > For firmware region, the RTOS firmware usually needs a physical address > to link to, and I have researched and tested two RTOS (RT-Thread and > Zephyr) on the C906L, both of them do not support position-independent > execution or runtime relocation. Therefore, a reserved memory region is > needed to provide a fixed physical address for the RTOS firmware. I think it is simple and possible to add PIE support for these RTOS. As the memory of CV18XX is limited, I do not want to see some reserved regions. This may hurt users who do not need this. > (In fact, there is already a reserved memory region for the C906L in > cv1800b-milkv-duo.dts) This is just preserved for vendor zsbl and I have a plan to remove it. Always let linux take care of all memory. It is good to support all firmware implementation for CV18XX. I think it is always good to use remoteproc like this: https://www.kernel.org/doc/html/latest/staging/remoteproc.html > > For virtio-related regions, the RTOS firmware also needs to know the > shared memory regions for communications at compile time. > I think you should investigate this and check if there is something you missed. I haven't see any reserved region in remoteproc binding mentions virtio. Regards, Inochi
On 30/07/2025 14:05, Inochi Amaoto wrote: > On Wed, Jul 30, 2025 at 03:57:09AM +0000, Junhui Liu wrote: >> On 29/07/2025 16:31, Inochi Amaoto wrote: >> > On Mon, Jul 28, 2025 at 07:03:23PM +0800, Junhui Liu wrote: >> >> Add C906L remote processor for CV1800B SoC, which is an asymmetric >> >> processor typically running RTOS. >> >> >> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> >> >> --- >> >> .../bindings/remoteproc/sophgo,cv1800b-c906l.yaml | 79 ++++++++++++++++++++++ >> >> 1 file changed, 79 insertions(+) >> >> >> >> diff --git a/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml >> >> new file mode 100644 >> >> index 0000000000000000000000000000000000000000..2061c2fd6ba343c09b1a91700ea4a695d2b57f81 >> >> --- /dev/null >> >> +++ b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml >> >> @@ -0,0 +1,79 @@ >> >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> >> +%YAML 1.2 >> >> +--- >> >> +$id: http://devicetree.org/schemas/remoteproc/sophgo,cv1800b-c906l.yaml# >> >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> >> + >> >> +title: Sophgo C906L remote processor controller for CV1800B SoC >> >> + >> >> +maintainers: >> >> + - Junhui Liu <junhui.liu@pigmoral.tech> >> >> + >> >> +description: >> >> + Document the bindings for the C906L remoteproc component that loads and boots >> >> + firmwares on the CV1800B SoC. >> >> + >> >> +properties: >> >> + compatible: >> >> + const: sophgo,cv1800b-c906l >> >> + >> >> + firmware-name: >> >> + maxItems: 1 >> >> + >> >> + mbox-names: >> >> + items: >> >> + - const: tx >> >> + - const: rx >> >> + >> >> + mboxes: >> >> + description: >> >> + This property is required only if the rpmsg/virtio functionality is used. >> >> + (see mailbox/sophgo,cv1800b-mailbox.yaml) >> >> + items: >> >> + - description: mailbox channel to send data to C906L >> >> + - description: mailbox channel to receive data from C906L >> >> + >> >> + memory-region: >> >> + description: >> >> + List of phandles to reserved memory regions used by the remote processor. >> >> + The first region is required and provides the firmware region for the >> >> + remote processor. The following regions (vdev buffer, vrings) are optional >> >> + and are only required if rpmsg/virtio functionality is used. >> >> + minItems: 1 >> >> + items: >> >> + - description: firmware region >> >> + - description: vdev buffer >> >> + - description: vring0 >> >> + - description: vring1 >> >> + additionalItems: true >> >> + >> > >> > Why not allocating these region dynamicly? I do not think firware is >> > always avaible before staring. Allowing dynamic firmware give us max >> > flexiblity. >> >> I'm afraid it's not easy to do this. >> >> For firmware region, the RTOS firmware usually needs a physical address >> to link to, and I have researched and tested two RTOS (RT-Thread and >> Zephyr) on the C906L, both of them do not support position-independent >> execution or runtime relocation. Therefore, a reserved memory region is >> needed to provide a fixed physical address for the RTOS firmware. > > I think it is simple and possible to add PIE support for these RTOS. As > the memory of CV18XX is limited, I do not want to see some reserved > regions. This may hurt users who do not need this. Thank you for sharing your concern about the limited memory. However, I think I have to wait until some RTOS supports PIE before I can continue to advance this patch series. At least I haven't found any guide on compiling RTOS firmware with PIE support for the two RTOSs (RT-Thread and Zephyr) I'm currently testing on the C906L. Besides, I have searched the existing remoteproc drivers in the kernel, and haven't found any driver using dynamic memory allocation for the firmware region. It may take some time to implement this feature if we really need it on CV18XX SoCs. > >> (In fact, there is already a reserved memory region for the C906L in >> cv1800b-milkv-duo.dts) > > This is just preserved for vendor zsbl and I have a plan to remove it. > Always let linux take care of all memory. It is good to support all > firmware implementation for CV18XX. Got it. > > I think it is always good to use remoteproc like this: > https://www.kernel.org/doc/html/latest/staging/remoteproc.html > >> >> For virtio-related regions, the RTOS firmware also needs to know the >> shared memory regions for communications at compile time. >> > > I think you should investigate this and check if there is something you > missed. I haven't see any reserved region in remoteproc binding mentions > virtio. Currently, in Zephyr, the only boards with OpenAMP sample support are the i.MX and STM32MP series [1]. Both of them define reserved memory regions for virtio and vrings in their respective Linux kernel device trees [2][3]. These are the only available reference targets I have at the moment. Furthermore, searching for the keyword "vring" in the remoteproc bindings yields many results, which I believe mostly pertain to reserved memory regions for rpmsg/virtio. $grep "vring" -r Documentation/devicetree/bindings/remoteproc | wc -l 24 So, at present, all my references use reserved memory for firmware regions (unless there is specific memory for the processor in hardware) and for virtio-related regions. Do you think there is anything I might have missed, or should some new feature be implemented? [1] https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table/boards [2] https://github.com/torvalds/linux/blob/v6.16/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi#L33-L49 [3] https://github.com/torvalds/linux/blob/v6.16/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts#L68-L97 -- Best regards, Junhui Liu
On Wed, Jul 30, 2025 at 08:59:15AM +0000, Junhui Liu wrote: > On 30/07/2025 14:05, Inochi Amaoto wrote: > > On Wed, Jul 30, 2025 at 03:57:09AM +0000, Junhui Liu wrote: > >> On 29/07/2025 16:31, Inochi Amaoto wrote: > >> > On Mon, Jul 28, 2025 at 07:03:23PM +0800, Junhui Liu wrote: > >> >> Add C906L remote processor for CV1800B SoC, which is an asymmetric > >> >> processor typically running RTOS. > >> >> > >> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech> > >> >> --- > >> >> .../bindings/remoteproc/sophgo,cv1800b-c906l.yaml | 79 ++++++++++++++++++++++ > >> >> 1 file changed, 79 insertions(+) > >> >> > >> >> diff --git a/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml > >> >> new file mode 100644 > >> >> index 0000000000000000000000000000000000000000..2061c2fd6ba343c09b1a91700ea4a695d2b57f81 > >> >> --- /dev/null > >> >> +++ b/Documentation/devicetree/bindings/remoteproc/sophgo,cv1800b-c906l.yaml > >> >> @@ -0,0 +1,79 @@ > >> >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > >> >> +%YAML 1.2 > >> >> +--- > >> >> +$id: http://devicetree.org/schemas/remoteproc/sophgo,cv1800b-c906l.yaml# > >> >> +$schema: http://devicetree.org/meta-schemas/core.yaml# > >> >> + > >> >> +title: Sophgo C906L remote processor controller for CV1800B SoC > >> >> + > >> >> +maintainers: > >> >> + - Junhui Liu <junhui.liu@pigmoral.tech> > >> >> + > >> >> +description: > >> >> + Document the bindings for the C906L remoteproc component that loads and boots > >> >> + firmwares on the CV1800B SoC. > >> >> + > >> >> +properties: > >> >> + compatible: > >> >> + const: sophgo,cv1800b-c906l > >> >> + > >> >> + firmware-name: > >> >> + maxItems: 1 > >> >> + > >> >> + mbox-names: > >> >> + items: > >> >> + - const: tx > >> >> + - const: rx > >> >> + > >> >> + mboxes: > >> >> + description: > >> >> + This property is required only if the rpmsg/virtio functionality is used. > >> >> + (see mailbox/sophgo,cv1800b-mailbox.yaml) > >> >> + items: > >> >> + - description: mailbox channel to send data to C906L > >> >> + - description: mailbox channel to receive data from C906L > >> >> + > >> >> + memory-region: > >> >> + description: > >> >> + List of phandles to reserved memory regions used by the remote processor. > >> >> + The first region is required and provides the firmware region for the > >> >> + remote processor. The following regions (vdev buffer, vrings) are optional > >> >> + and are only required if rpmsg/virtio functionality is used. > >> >> + minItems: 1 > >> >> + items: > >> >> + - description: firmware region > >> >> + - description: vdev buffer > >> >> + - description: vring0 > >> >> + - description: vring1 > >> >> + additionalItems: true > >> >> + > >> > > >> > Why not allocating these region dynamicly? I do not think firware is > >> > always avaible before staring. Allowing dynamic firmware give us max > >> > flexiblity. > >> > >> I'm afraid it's not easy to do this. > >> > >> For firmware region, the RTOS firmware usually needs a physical address > >> to link to, and I have researched and tested two RTOS (RT-Thread and > >> Zephyr) on the C906L, both of them do not support position-independent > >> execution or runtime relocation. Therefore, a reserved memory region is > >> needed to provide a fixed physical address for the RTOS firmware. > > > > I think it is simple and possible to add PIE support for these RTOS. As > > the memory of CV18XX is limited, I do not want to see some reserved > > regions. This may hurt users who do not need this. > > Thank you for sharing your concern about the limited memory. > > However, I think I have to wait until some RTOS supports PIE before I > can continue to advance this patch series. At least I haven't found any > guide on compiling RTOS firmware with PIE support for the two RTOSs > (RT-Thread and Zephyr) I'm currently testing on the C906L. > > Besides, I have searched the existing remoteproc drivers in the kernel, > and haven't found any driver using dynamic memory allocation for the > firmware region. It may take some time to implement this feature if we > really need it on CV18XX SoCs. > > > > >> (In fact, there is already a reserved memory region for the C906L in > >> cv1800b-milkv-duo.dts) > > > > This is just preserved for vendor zsbl and I have a plan to remove it. > > Always let linux take care of all memory. It is good to support all > > firmware implementation for CV18XX. > > Got it. > > > > > I think it is always good to use remoteproc like this: > > https://www.kernel.org/doc/html/latest/staging/remoteproc.html > > > >> > >> For virtio-related regions, the RTOS firmware also needs to know the > >> shared memory regions for communications at compile time. > >> > > > > I think you should investigate this and check if there is something you > > missed. I haven't see any reserved region in remoteproc binding mentions > > virtio. > > Currently, in Zephyr, the only boards with OpenAMP sample support are > the i.MX and STM32MP series [1]. Both of them define reserved memory > regions for virtio and vrings in their respective Linux kernel device > trees [2][3]. These are the only available reference targets I have at > the moment. > > Furthermore, searching for the keyword "vring" in the remoteproc > bindings yields many results, which I believe mostly pertain to reserved > memory regions for rpmsg/virtio. > > $grep "vring" -r Documentation/devicetree/bindings/remoteproc | wc -l > 24 > #grep -rl vring | wc -l 9 In fact, it seems not many boards add vring as memory region, But for simplifity, it is OK for me to leave the vring as an fixed region. Or just not support virtio at all... I see the document of OpenAMP says it support no-virtio mode. > So, at present, all my references use reserved memory for firmware > regions (unless there is specific memory for the processor in hardware) > and for virtio-related regions. Do you think there is anything I might > have missed, or should some new feature be implemented? > > [1] https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/subsys/ipc/openamp_rsc_table/boards > [2] https://github.com/torvalds/linux/blob/v6.16/arch/arm/boot/dts/st/stm32mp15xx-dkx.dtsi#L33-L49 > [3] https://github.com/torvalds/linux/blob/v6.16/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts#L68-L97 > Great, I think it is convincing. Thanks. Regards, Inochi
On 28/07/2025 13:03, Junhui Liu wrote:
> +
> + firmware-name:
> + maxItems: 1
> +
> + mbox-names:
> + items:
> + - const: tx
> + - const: rx
> +
> + mboxes:
First go mboxes, then mboxes-names. ALWAYS.
> + description:
> + This property is required only if the rpmsg/virtio functionality is used.
> + (see mailbox/sophgo,cv1800b-mailbox.yaml)
> + items:
> + - description: mailbox channel to send data to C906L
> + - description: mailbox channel to receive data from C906L
> +
> + memory-region:
> + description:
> + List of phandles to reserved memory regions used by the remote processor.
> + The first region is required and provides the firmware region for the
> + remote processor. The following regions (vdev buffer, vrings) are optional
> + and are only required if rpmsg/virtio functionality is used.
> + minItems: 1
Why isn't this constrained?
> + items:
> + - description: firmware region
> + - description: vdev buffer
> + - description: vring0
> + - description: vring1
> + additionalItems: true
No, drop. This needs to be constrained.
> +
> + resets:
> + maxItems: 1
> +
> + sophgo,syscon:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + A phandle to the SEC_SYS region, used for configuration of the remote
> + processor.
> +
> +required:
> + - compatible
> + - firmware-name
> + - memory-region
> + - resets
> + - sophgo,syscon
Why mboxes are not required?
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + c906l-rproc {
Node names should be generic. See also an explanation and list of
examples (not exhaustive) in DT specification:
https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
Best regards,
Krzysztof
On 28/07/2025 15:11, Krzysztof Kozlowski wrote:
> On 28/07/2025 13:03, Junhui Liu wrote:
>> +
>> + firmware-name:
>> + maxItems: 1
>> +
>> + mbox-names:
>> + items:
>> + - const: tx
>> + - const: rx
>> +
>> + mboxes:
>
> First go mboxes, then mboxes-names. ALWAYS.
Thanks, I will fix the order in the next version.
>
>> + description:
>> + This property is required only if the rpmsg/virtio functionality is used.
>> + (see mailbox/sophgo,cv1800b-mailbox.yaml)
>> + items:
>> + - description: mailbox channel to send data to C906L
>> + - description: mailbox channel to receive data from C906L
>> +
>> + memory-region:
>> + description:
>> + List of phandles to reserved memory regions used by the remote processor.
>> + The first region is required and provides the firmware region for the
>> + remote processor. The following regions (vdev buffer, vrings) are optional
>> + and are only required if rpmsg/virtio functionality is used.
>> + minItems: 1
>
> Why isn't this constrained?
Do you mean a maxItems should be added here?
>
>> + items:
>> + - description: firmware region
>> + - description: vdev buffer
>> + - description: vring0
>> + - description: vring1
>> + additionalItems: true
>
> No, drop. This needs to be constrained.
My intention is that RPMsg/OpenAMP is not the only use case for
remoteproc. There are scenarios where the remoteproc is just used for
booting the remote processor without any communication with Linux. In
such case, only the firmware region is needed, and the other regions may
not be necessary.
Additionally, the remote processor might reserve extra memory for custom
buffers or other firmware-specific purposes beyond virtio/rpmsg.
Therefore, I think only the firmware region should be required and
constrained, while allowing flexibility for additional/custom memory
regions as needed.
>
>
>> +
>> + resets:
>> + maxItems: 1
>> +
>> + sophgo,syscon:
>> + $ref: /schemas/types.yaml#/definitions/phandle
>> + description:
>> + A phandle to the SEC_SYS region, used for configuration of the remote
>> + processor.
>> +
>> +required:
>> + - compatible
>> + - firmware-name
>> + - memory-region
>> + - resets
>> + - sophgo,syscon
>
> Why mboxes are not required?
The reason is similar to "memory-region" above. The mboxes property is
only needed when RPMsg/virtio communication is used. For some use cases,
the remote processor does not need to communicate with Linux at all, so
the mailbox is not required. Would it be necessary to require the mboxes
property even in scenarios where mailbox communication is not involved?
>
>> +
>> +additionalProperties: false
>> +
>> +examples:
>> + - |
>> + c906l-rproc {
>
> Node names should be generic. See also an explanation and list of
> examples (not exhaustive) in DT specification:
> https://devicetree-specification.readthedocs.io/en/latest/chapter2-devicetree-basics.html#generic-names-recommendation
Thanks for the information, I will change the node name to a generic
"remoteproc" in the example. (Although it's not in the list, I think
it's generic enough)
>
>
> Best regards,
> Krzysztof
--
Best regards,
Junhui Liu
On 28/07/2025 19:13, Junhui Liu wrote: >> >>> + description: >>> + This property is required only if the rpmsg/virtio functionality is used. >>> + (see mailbox/sophgo,cv1800b-mailbox.yaml) >>> + items: >>> + - description: mailbox channel to send data to C906L >>> + - description: mailbox channel to receive data from C906L >>> + >>> + memory-region: >>> + description: >>> + List of phandles to reserved memory regions used by the remote processor. >>> + The first region is required and provides the firmware region for the >>> + remote processor. The following regions (vdev buffer, vrings) are optional >>> + and are only required if rpmsg/virtio functionality is used. >>> + minItems: 1 >> >> Why isn't this constrained? > > Do you mean a maxItems should be added here? > >> >>> + items: >>> + - description: firmware region >>> + - description: vdev buffer >>> + - description: vring0 >>> + - description: vring1 >>> + additionalItems: true >> >> No, drop. This needs to be constrained. > > My intention is that RPMsg/OpenAMP is not the only use case for We don't allow such syntax, that's not negotiable. Why 322 redundant memory regions are fine now? > remoteproc. There are scenarios where the remoteproc is just used for > booting the remote processor without any communication with Linux. In > such case, only the firmware region is needed, and the other regions may > not be necessary. > > Additionally, the remote processor might reserve extra memory for custom > buffers or other firmware-specific purposes beyond virtio/rpmsg. > Therefore, I think only the firmware region should be required and > constrained, while allowing flexibility for additional/custom memory > regions as needed. So how does this work exactly without the rest? Remote processor boots and works fine? How do you communicate with it? Please describe exactly the usecase. Best regards, Krzysztof
On 29/07/2025 08:27, Krzysztof Kozlowski wrote: > On 28/07/2025 19:13, Junhui Liu wrote: >>> >>>> + description: >>>> + This property is required only if the rpmsg/virtio functionality is used. >>>> + (see mailbox/sophgo,cv1800b-mailbox.yaml) >>>> + items: >>>> + - description: mailbox channel to send data to C906L >>>> + - description: mailbox channel to receive data from C906L >>>> + >>>> + memory-region: >>>> + description: >>>> + List of phandles to reserved memory regions used by the remote processor. >>>> + The first region is required and provides the firmware region for the >>>> + remote processor. The following regions (vdev buffer, vrings) are optional >>>> + and are only required if rpmsg/virtio functionality is used. >>>> + minItems: 1 >>> >>> Why isn't this constrained? >> >> Do you mean a maxItems should be added here? >> >> >>>> + items: >>>> + - description: firmware region >>>> + - description: vdev buffer >>>> + - description: vring0 >>>> + - description: vring1 >>>> + additionalItems: true >>> >>> No, drop. This needs to be constrained. >> >> My intention is that RPMsg/OpenAMP is not the only use case for > > We don't allow such syntax, that's not negotiable. Why 322 redundant > memory regions are fine now? > >> remoteproc. There are scenarios where the remoteproc is just used for >> booting the remote processor without any communication with Linux. In >> such case, only the firmware region is needed, and the other regions may >> not be necessary. >> >> Additionally, the remote processor might reserve extra memory for custom >> buffers or other firmware-specific purposes beyond virtio/rpmsg. >> Therefore, I think only the firmware region should be required and >> constrained, while allowing flexibility for additional/custom memory >> regions as needed. > > So how does this work exactly without the rest? Remote processor boots > and works fine? How do you communicate with it? > > Please describe exactly the usecase. Thank you for your clarification. The C906L remoteproc can run at two use cases: 1. Standalone mode: Only the firmware region is used. In this case, the remoteproc driver loads the firmware into the firmware region and boots the C906L. The C906L runs independently, without communication with Linux, and the mailbox is not used. 2. OpenAMP/RPMsg mode: The firmware region, vdev buffer, and vrings are used. In this scenario, the C906L runs firmware with OpenAMP support and communicates with Linux via the virtio memory regions and mailbox. To summarize: - Required: firmware region - Optional: vdev buffer, vrings, mailbox Then I can add a "maxItems: 4" to the memory-region property and remove the "additionalItems: true" line. Is this approach acceptable for you? > > > Best regards, > Krzysztof -- Best regards, Junhui Liu
On 30/07/2025 05:31, Junhui Liu wrote: > On 29/07/2025 08:27, Krzysztof Kozlowski wrote: >> On 28/07/2025 19:13, Junhui Liu wrote: >>>> >>>>> + description: >>>>> + This property is required only if the rpmsg/virtio functionality is used. >>>>> + (see mailbox/sophgo,cv1800b-mailbox.yaml) >>>>> + items: >>>>> + - description: mailbox channel to send data to C906L >>>>> + - description: mailbox channel to receive data from C906L >>>>> + >>>>> + memory-region: >>>>> + description: >>>>> + List of phandles to reserved memory regions used by the remote processor. >>>>> + The first region is required and provides the firmware region for the >>>>> + remote processor. The following regions (vdev buffer, vrings) are optional >>>>> + and are only required if rpmsg/virtio functionality is used. >>>>> + minItems: 1 >>>> >>>> Why isn't this constrained? >>> >>> Do you mean a maxItems should be added here? >>>>> >>>>> + items: >>>>> + - description: firmware region >>>>> + - description: vdev buffer >>>>> + - description: vring0 >>>>> + - description: vring1 >>>>> + additionalItems: true >>>> >>>> No, drop. This needs to be constrained. >>> >>> My intention is that RPMsg/OpenAMP is not the only use case for >> >> We don't allow such syntax, that's not negotiable. Why 322 redundant >> memory regions are fine now? >> >>> remoteproc. There are scenarios where the remoteproc is just used for >>> booting the remote processor without any communication with Linux. In >>> such case, only the firmware region is needed, and the other regions may >>> not be necessary. >>> >>> Additionally, the remote processor might reserve extra memory for custom >>> buffers or other firmware-specific purposes beyond virtio/rpmsg. >>> Therefore, I think only the firmware region should be required and >>> constrained, while allowing flexibility for additional/custom memory >>> regions as needed. >> >> So how does this work exactly without the rest? Remote processor boots >> and works fine? How do you communicate with it? >> >> Please describe exactly the usecase. > > Thank you for your clarification. > > The C906L remoteproc can run at two use cases: > 1. Standalone mode: Only the firmware region is used. In this case, the > remoteproc driver loads the firmware into the firmware region and > boots the C906L. The C906L runs independently, without communication > with Linux, and the mailbox is not used. > 2. OpenAMP/RPMsg mode: The firmware region, vdev buffer, and vrings are > used. In this scenario, the C906L runs firmware with OpenAMP support > and communicates with Linux via the virtio memory regions and mailbox. > > To summarize: > - Required: firmware region > - Optional: vdev buffer, vrings, mailbox How does your driver behave in (1)? Does it work? Best regards, Krzysztof
On 30/07/2025 08:47, Krzysztof Kozlowski wrote: > On 30/07/2025 05:31, Junhui Liu wrote: >> On 29/07/2025 08:27, Krzysztof Kozlowski wrote: >>> On 28/07/2025 19:13, Junhui Liu wrote: >>>>> >>>>>> + description: >>>>>> + This property is required only if the rpmsg/virtio functionality is used. >>>>>> + (see mailbox/sophgo,cv1800b-mailbox.yaml) >>>>>> + items: >>>>>> + - description: mailbox channel to send data to C906L >>>>>> + - description: mailbox channel to receive data from C906L >>>>>> + >>>>>> + memory-region: >>>>>> + description: >>>>>> + List of phandles to reserved memory regions used by the remote processor. >>>>>> + The first region is required and provides the firmware region for the >>>>>> + remote processor. The following regions (vdev buffer, vrings) are optional >>>>>> + and are only required if rpmsg/virtio functionality is used. >>>>>> + minItems: 1 >>>>> >>>>> Why isn't this constrained? >>>> >>>> Do you mean a maxItems should be added here? >>>>>> >>>>>> + items: >>>>>> + - description: firmware region >>>>>> + - description: vdev buffer >>>>>> + - description: vring0 >>>>>> + - description: vring1 >>>>>> + additionalItems: true >>>>> >>>>> No, drop. This needs to be constrained. >>>> >>>> My intention is that RPMsg/OpenAMP is not the only use case for >>> >>> We don't allow such syntax, that's not negotiable. Why 322 redundant >>> memory regions are fine now? >>> >>>> remoteproc. There are scenarios where the remoteproc is just used for >>>> booting the remote processor without any communication with Linux. In >>>> such case, only the firmware region is needed, and the other regions may >>>> not be necessary. >>>> >>>> Additionally, the remote processor might reserve extra memory for custom >>>> buffers or other firmware-specific purposes beyond virtio/rpmsg. >>>> Therefore, I think only the firmware region should be required and >>>> constrained, while allowing flexibility for additional/custom memory >>>> regions as needed. >>> >>> So how does this work exactly without the rest? Remote processor boots >>> and works fine? How do you communicate with it? >>> >>> Please describe exactly the usecase. >> >> Thank you for your clarification. >> >> The C906L remoteproc can run at two use cases: >> 1. Standalone mode: Only the firmware region is used. In this case, the >> remoteproc driver loads the firmware into the firmware region and >> boots the C906L. The C906L runs independently, without communication >> with Linux, and the mailbox is not used. >> 2. OpenAMP/RPMsg mode: The firmware region, vdev buffer, and vrings are >> used. In this scenario, the C906L runs firmware with OpenAMP support >> and communicates with Linux via the virtio memory regions and mailbox. >> >> To summarize: >> - Required: firmware region >> - Optional: vdev buffer, vrings, mailbox > > How does your driver behave in (1)? Does it work? The driver inits the firmware region and loads the firmware into it. Then it sets the enable bit in the C906L's control register, set the reset address for the C906L and deassert the reset bit for the C906L to boot it. Actually, the current driver only supports the first case, and it works. The second case is not implemented yet, but I believe it can be supported based on the current code structure. I originally intended to submit the OpenAMP/RPMsg-related bindings together with the driver implementation; however, I was advised to finalize the bindings in v1: https://lore.kernel.org/linux-riscv/PN0P287MB22589781F2D49353E7C66C46FE75A@PN0P287MB2258.INDP287.PROD.OUTLOOK.COM/ -- Best regards, Junhui Liu
© 2016 - 2025 Red Hat, Inc.