Add support for WCH CH32V303 #87125

miggazElquez · 2025-03-14T14:52:14Z

This PR add support for the SoC CH32V303 from WCH, and for the board CH32V303EVT.

Depends on #85395 for the support of west flash.

zephyrbot · 2025-03-14T14:53:14Z

The following west manifest projects have changed revision in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_wch	zephyrproject-rtos/hal_wch@`1de9d3e`	zephyrproject-rtos/hal_wch@`941f518` (`main`)	zephyrproject-rtos/hal_wch@1de9d3e4..941f5182

✅ All manifest checks OK

Note: This message is automatically posted and updated by the Manifest GitHub Action.

miggazElquez · 2025-03-14T14:57:00Z

@VynDragon if you want to take a look, as this is based on your code for the ch32v208.

boards/wch/ch32v303evt/ch32v303evt-pinctrl.dtsi

nordicjm · 2025-03-14T15:10:47Z

boards/wch/ch32v303evt/ch32v303evt_defconfig

+CONFIG_CONSOLE=y
+CONFIG_UART_CONSOLE=y
+
+CONFIG_FLASH_BASE_ADDRESS=0x08000000


why is this here?

If I don't put that, CONFIG_FLASH_BASE_ADDRESS will be set to the address of the flash in the device tree (currently 0), and minichlink fail to flash at the address 0. But if I change the address in the device tree, I can flash but Zephyr then fails to boot, I don't really know why. @VynDragon you didn't have this issue on the 208 ?

What would be the way to solve this ? I saw that some boards did change CONFIG_FLASH_BASE_ADDRESS in their defconfig, so that's why I put it there, but maybe it should be in another place ?

Oh so that's why the west flash didnt work! Ill look into it, might be a matter of fixing the runner instead of this, otherwise figuring how to make it boot in non aliased space would make it easier to use the full flash so ill see for both issues.

Well it works for me when i set

flash0: flash@8000000 { compatible = "soc-nv-flash"; reg = <0x08000000 DT_SIZE_K(128)>; };

after udpating minichlink and using minichlink -w build/zephyr/zephyr.bin 0x0
But west flash still doenst work so no clue what's going on there

a it's the -b for the runner, need to disable reset for ch32v208

Edit:" which is easy to say but almost impossible to do, i'm on my second PR just to be able to pass --no-reset in the board args.

It might be a frequency issue, for some reason on CH32V208 it works at 144MHz, but they 'highly recommend' using 120M in the RM for the F/V20x/30x serie. You added the long jump code in the ASM right?
It's only for the linking mapping within that space, otherwise the space is accessible without booting into it. (eg if your address space in zephyr is 0x08000000 it will only run in non-aliased, but if it's 0x0 it will only run in aliased due to the long jump / short jump things)

For flashing

Me neither, it's supposed to flash to 0x08000000 so with dt-flash=y and the flash address set to that and the long jump code, or 0x0 with no long jump and 0x08000000 flash address still. I think it changed between old and new minichlink version?

So before answering to you I wanted to test it one last time and now it works, I don't know what I did wrong during my tests before... because I'm quite sure I tested with the long jump, but maybe I had changed something else, I don't know. Anyway it works now, so I modified my PR to include it, it seems cleaner to me than passing the flash address directly to minichlink.

I still don't really understand the point of the long jump, even if it's clearly necessary : if the address space in zephyr is at 0x08000000, why do we need the long jump to get into non-aliased mode ? Because when testing it seems like we boot in non-aliased mode with the address space at 0x08000000, but maybe the debuggers are just confused by all this aliasing and are lying to me. (I would like to add a comment explaining this long jump things but as I don't totally understand it yet...)

I still don't really understand the point of the long jump

It's so the pc is in the right zone when the short jumps happen, eg that the pc is in the area expected when it tries to do a short jump, there is also the matter of the gp pointer, and a couple other thing i believe break when operated in not the expected area. In practice it crashes if you run it without that long jump.

Also make sure to set frequency to 120 if you use the full flash! It might be your spurious issue

Because when testing it seems like we boot in non-aliased mode

It always boot in the aliased zone?

It always boot in the aliased zone?

I think that I was fooled by the debugger, I'm not sure about what is happening but with the debugger even without the longjump I'm in non aliased space (pc = 0x0800...). I think it's not really executing the first instructions, it seems like it's just jumping to __start directly ?

Weird, I dont know what could be going on

modules/hal_wch/hal_ch32fun.h

SoftwareArchitekt · 2025-05-08T13:58:08Z

soc/wch/ch32v/qingke_v4_vector.S

I guess this file should also be located in qinke_v4f-directory

For this file I'm waiting on #87345 to be merged to rebase my code, so this file will end up in a folder for all Qingke-V4

SoftwareArchitekt · 2025-05-08T14:20:07Z

soc/wch/ch32v/qingke_v4f/pinctrl_soc.h

+/**
+ * @brief Type to hold a pin's pinctrl configuration.
+ */
+struct ch32v303_pinctrl_soc_pin {


this struct will also be used by ch32v307. This means the naming would be better qingke_v4f_pin....

Same for this, it's in the folder for all qingke v4

as you told, it is in folder for all qinke v4, so a name of a soc (ch32v303) is maybe wrong. better to use a struct qinke_v4_pinvtrl_soc_pin {

So the PR deduplicating the files was changed to just focus on the changes for the v208, so I created another PR deduplicating all the files, with the idea that when one of these two PR is merged, I would just rebase the other.

About the specific point, for the pinctrl file, naming it qingke_v4_something is maybe not the best idea, see this comment.

+1 to not naming it after the microarchitecture, as the pinctrl is a feature of the SoC, not the processor.

Update hal_wch. As the hal upstream changed name, there is now a name conflict. Rename ch32fun.h to hal_ch32fun.h to fix this conflict. Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com>

Adds support for building an image for the ch32v303. Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com>

Adds support for the CH32V303EVT board, based on the CH32V303 soc. Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com>

sonarqubecloud · 2025-05-14T16:00:15Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
15.5% Duplication on New Code

See analysis details on SonarQube Cloud

miggazElquez · 2025-05-15T10:27:26Z

The deduplication of the files is now in #90007; when one of these is merged I will rebase the other.

nzmichaelh · 2025-05-24T09:48:27Z

boards/wch/ch32v303vct6_evt/doc/index.rst

+Overview
+********
+
+The `WCH`_ CH3V303VCT6_EVT hardware provides support for QingKe 32-bit RISC-V4F


Do you happen to have a link to the schematic for the board? It's hard to check if the pin assignments etc are correct without it.

nzmichaelh · 2025-05-24T09:49:43Z

boards/wch/ch32v303vct6_evt/doc/index.rst

+Overview
+********
+
+The `WCH`_ CH3V303VCT6_EVT hardware provides support for QingKe 32-bit RISC-V4F


nit: the name seems to be "CH32V303VCT6-EVT": https://www.aliexpress.com/item/1005005257256239.html

nzmichaelh · 2025-05-24T09:50:12Z

boards/wch/ch32v303vct6_evt/doc/index.rst

+Overview
+********
+
+The `WCH`_ CH3V303VCT6_EVT hardware provides support for QingKe 32-bit RISC-V4F


nit: it's a QingKe-V4F 32-bit RISC-V, not a RISC-V4F.

nzmichaelh · 2025-05-24T09:50:27Z

boards/wch/ch32v303vct6_evt/doc/index.rst

+Hardware
+********
+
+The QingKe 32-bit RISC-V4F processor of the WCH CH32V303VCT6_EVT is clocked by an external


ditto re: RISC-V4F.

nzmichaelh · 2025-05-24T09:52:26Z

dts/riscv/wch/ch32v303/ch32v303.dtsi

+		clk_hse: clk-hse {
+			#clock-cells = <0>;
+			compatible = "wch,ch32v00x-hse-clock";
+			clock-frequency = <DT_FREQ_M(32)>;


nit: the HSE clock frequency is board specific, so probably shouldn't be set here.

nzmichaelh · 2025-05-24T09:57:56Z

dts/riscv/wch/ch32v303/ch32v303.dtsi

+};
+
+&cpu0 {
+	clock-frequency = <DT_FREQ_M(144)>;


I see this was reduced to 120 MHz on the ch32v203 to allow using the extra, higher wait state flash. Either reduce this or shrink the flash to the 256 KiB of low-wait state flash.

modules/hal_wch/hal_ch32fun.h

nzmichaelh · 2025-05-24T10:00:15Z

soc/wch/ch32v/qingke_v4f/pinctrl_soc.h

+/**
+ * @brief Type to hold a pin's pinctrl configuration.
+ */
+struct ch32v303_pinctrl_soc_pin {


+1 to not naming it after the microarchitecture, as the pinctrl is a feature of the SoC, not the processor.

zephyrproject-rtos#87125 renamed the `ch32vfun.h` header but missed some of the drivers. Fix. Signed-off-by: Michael Hope <michaelh@juju.nz>

nzmichaelh · 2025-05-24T17:58:48Z

I've sent #90438 to fix the other drivers after the ch32fun -> hal_ch32fun update.

zephyrproject-rtos#87125 renamed the `ch32vfun.h` header but missed some of the drivers. Fix. Signed-off-by: Michael Hope <michaelh@juju.nz>

zephyrbot added area: UART Universal Asynchronous Receiver-Transmitter area: GPIO area: Timer Timer area: RISCV RISCV Architecture (32-bit & 64-bit) area: Pinctrl area: Clock Control area: Interrupt Controller labels Mar 14, 2025

zephyrbot requested review from andyross, carlocaione, edersondisouza, fkokosinski, gmarull, henrikbrixandersen, katsuster, kgugala, mgielda, nordic-krch, npitre, nzmichaelh, teburd, tgorochowik and ycsin March 14, 2025 14:53

zephyrbot assigned gmarull Mar 14, 2025

zephyrbot added manifest manifest-hal_wch DNM (manifest) This PR should not be merged (controlled by action-manifest) labels Mar 14, 2025

miggazElquez force-pushed the ch32v303 branch from 72fd986 to 8f9c0c2 Compare March 14, 2025 15:00

nordicjm reviewed Mar 14, 2025

View reviewed changes

github-actions bot removed the DNM (manifest) This PR should not be merged (controlled by action-manifest) label Apr 24, 2025

VynDragon added the DNM This PR should not be merged (Do Not Merge) label Apr 24, 2025

kartben assigned nzmichaelh and unassigned gmarull Apr 25, 2025

SoftwareArchitekt reviewed Apr 27, 2025

View reviewed changes

modules/hal_wch/hal_ch32fun.h Show resolved Hide resolved

miggazElquez mentioned this pull request May 6, 2025

pinctrl: Add missing newline in .dtsi #89556

Merged

SoftwareArchitekt reviewed May 8, 2025

View reviewed changes

miggazElquez dismissed nzmichaelh’s stale review via 876fe8f May 8, 2025 18:38

VynDragon mentioned this pull request May 10, 2025

dts: wch: Enable using whole flash with CH32V208 #87345

Merged

modules: Update hal_wch

80695db

Update hal_wch. As the hal upstream changed name, there is now a name conflict. Rename ch32fun.h to hal_ch32fun.h to fix this conflict. Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com>

miggazElquez force-pushed the ch32v303 branch from 876fe8f to 06563fe Compare May 14, 2025 13:36

miggazElquez added 2 commits May 14, 2025 17:31

soc: Add support for the WCH CH32V303

77149f3

Adds support for building an image for the ch32v303. Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com>

boards: Add support for the board CH32V303EVT

9798039

Adds support for the CH32V303EVT board, based on the CH32V303 soc. Signed-off-by: Miguel Gazquez <miguel.gazquez@bootlin.com>

miggazElquez force-pushed the ch32v303 branch from 06563fe to 9798039 Compare May 14, 2025 15:32

VynDragon removed the DNM This PR should not be merged (Do Not Merge) label May 14, 2025

miggazElquez requested review from VynDragon, nzmichaelh, nordicjm and fkokosinski May 15, 2025 09:07

miggazElquez requested a review from SoftwareArchitekt May 15, 2025 10:28

nordicjm approved these changes May 21, 2025

View reviewed changes

nzmichaelh approved these changes May 24, 2025

View reviewed changes

kartben merged commit a9f2a19 into zephyrproject-rtos:main May 24, 2025
29 of 30 checks passed

nzmichaelh mentioned this pull request May 24, 2025

drivers: wch: fix the ch32vfun.h path after the recent HAL update #90438

Open

Add support for WCH CH32V303 #87125

Add support for WCH CH32V303 #87125

Conversation

miggazElquez commented Mar 14, 2025

Uh oh!

zephyrbot commented Mar 14, 2025 • edited by github-actions bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

miggazElquez commented Mar 14, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VynDragon Mar 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VynDragon Mar 14, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VynDragon Mar 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

miggazElquez Mar 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VynDragon Mar 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sonarqubecloud bot commented May 14, 2025

Quality Gate passed

Uh oh!

miggazElquez commented May 15, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

nzmichaelh commented May 24, 2025

Uh oh!

Uh oh!

zephyrbot commented Mar 14, 2025 •

edited by github-actions bot

Loading

VynDragon Mar 14, 2025 •

edited

Loading

VynDragon Mar 14, 2025 •

edited

Loading

VynDragon Mar 19, 2025 •

edited

Loading

miggazElquez Mar 19, 2025 •

edited

Loading

VynDragon Mar 19, 2025 •

edited

Loading