Adding SOC WCH ch32v307 and board scdz ch32v307evt #91702

SoftwareArchitekt · 2025-06-16T14:01:11Z

Adding SOC WCH ch32v307 and board scdz ch32v307evt
all remarks from old request are included

dts: add riscv/wch/ch32v307 and packages wch has provide a ch32v307 soc series Signed-off-by: SoftwareArchitekt <[email protected]>

adding from scdz the ch32v307evt-board, it is build on a ch32v307vc-soc which have a risc-v qingKeV4F-Core Signed-off-by: SoftwareArchitekt <[email protected]>

miggazElquez · 2025-06-17T08:50:48Z

soc/wch/ch32v/qingke_v4f/vector.S

@@ -18,9 +18,11 @@ GTEXT(__initialize)

 SECTION_FUNC(vectors, ivt)
 	.option norvc
+    #ifndef SOC_CH32V307


If you remove these two lines, you have to change the value written into mtvec (to 0x7 in this case).

miggazElquez · 2025-06-17T08:57:45Z

dts/riscv/wch/ch32v307/ch32v307.dtsi

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


Two question about this, related to the change in vector.S:

In my tests, for the ch32v303, without the jump in vector.S to the non-aliased space (0x0800 ....) the code will only work if I put the address of the flash at 0, not 0x08000000. And if I put the jump in vector.S, then I have to put the address at 0x08000000 (which make sense). It seems strange to me that this is different for the ch32v307 ?

Also, without this jump, do you really have access to the full 480 KB ? For me, it should probably be something between 128 KB and 288KB depending on SRAM_CODE_MODE, and probably 288 KB (and 32 KB of RAM) as this is what minichlink do if I recall correctly.

my plan was, to ectract this discussion out of this PR to open a new issue for it. Because in doc CH32FV2x_V3xRM.PDF you can read in chapter 1.3:

The user selects the startup mode after reset by setting the status value of BOOT pins. After the system is reset
or the power is reset, the value of the BOOT pin will be latched again.
The program flash memory, system memory and internal SRAM have different access methods in different
startup modes:
l When it is started up from the program flash memory, the program flash memory address will be mapped
to the 0x00000000 address area and can also be accessed in the start address area 0x08000000.
l When it is started up from the system memory, the system memory address will be mapped to the address
area 0x00000000 and can also be accessed in the original address area 0x1FFFF000.
l When it is started up from the internal SRAM, it can be only accessed from 0x20000000 address area.
When the CH32F2x is started up in this area, it is necessary to set the vector table offset register through
the NVIC controller to remap the vector table to SRAM. For CH32V2x and CH32V3x, such action is not
required.

this means, the memory mirrored address depences on the pins, and with a jump to 0x8000000 you can run in trouble.
What is your proposal?

In any case, I think it's important that the code is working, and I think that in the current state it isn't working ? Correct me if I'm wrong.

Maybe I'm understanding it wrong, but with Zephyr I think we are always in the program flash memory. It seems that the "system memory" is not really writable. For the part with the internal SRAM I don't really understand how it works ?
But as we know that we are in program flash memory (we compiled zephyr for it) it is possible to jump to 0x0800 0000.
The downside is that the access to flash should be slower. But anyway, if we are reading the code from the 0-wait area, at 0x0, is should be described as such in the device tree imo, for the address because it doesn't work with the wrong address, and for the size, because if we put 480 then Zephyr won't complain if we have too much code to fit in the 0-wait area.

Or maybe there is a way in Zephyr to describe this situation of 480 Kb of Flash, with a part of it aliased in another place ?

@VynDragon you understand all of this better than me, if you have any advice.

miggazElquez · 2025-06-17T08:59:50Z

boards/scdz/ch32v307evt/ch32v307evt.yaml

+toolchain:
+  - cross-compile
+  - zephyr
+ram: 64


And these two value are incompatible with what is declared in the device tree.

please check again

nordicjm · 2025-06-17T09:14:59Z

boards/scdz/ch32v307evt/ch32v307evt-pinctrl.dtsi

+			drive-push-pull;
+			slew-rate = "max-speed-10mhz";
+		};
+		group2 {


newline gap between child nodes

please check again

nordicjm · 2025-06-17T09:15:04Z

boards/scdz/ch32v307evt/ch32v307evt-pinctrl.dtsi

+			bias-pull-up;
+		};
+	};
+


Suggested change

please check again

nordicjm · 2025-06-17T09:15:12Z

boards/scdz/ch32v307evt/ch32v307evt.dts

+		compatible = "gpio-keys";
+
+		user_button0: sw0 {
+            label = "User SW0";


indent is off

please check again

fix ram size to be aligned with soc, fix some file layouts Signed-off-by: SoftwareArchitekt <[email protected]>

fix document error for build-docs run Signed-off-by: SoftwareArchitekt <[email protected]>

miggazElquez · 2025-06-17T15:04:19Z

When pushing modification, you should rebase your changes to keep only the necessary commits and force push. See https://docs.zephyrproject.org/latest/contribute/guidelines.html#contribution-workflow, 14th bullet point.

sonarqubecloud · 2025-06-17T15:21:55Z

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

miggazElquez · 2025-06-17T15:25:11Z

Which commit you mean?

At first your pull request had two commits, and it was correct. But you pushed two new commits, and these two new commits shouldn't appear, they should be squashed into the first two commit. The contribution guideline will explain this better than me

SoftwareArchitekt added 2 commits June 16, 2025 15:22

soc: add wch/ch32v307

fb259d0

dts: add riscv/wch/ch32v307 and packages wch has provide a ch32v307 soc series Signed-off-by: SoftwareArchitekt <[email protected]>

boards: adding ch32v307evt from scdz

0475f7c

adding from scdz the ch32v307evt-board, it is build on a ch32v307vc-soc which have a risc-v qingKeV4F-Core Signed-off-by: SoftwareArchitekt <[email protected]>

github-actions bot added area: RISCV RISCV Architecture (32-bit & 64-bit) platform: WinChipHead labels Jun 16, 2025

github-actions bot requested review from carlocaione, edersondisouza, fkokosinski, katsuster, kgugala, mgielda, npitre, nzmichaelh, tgorochowik, VynDragon and ycsin June 16, 2025 14:02

github-actions bot assigned nzmichaelh Jun 16, 2025

miggazElquez reviewed Jun 17, 2025

View reviewed changes

nordicjm requested changes Jun 17, 2025

View reviewed changes

nordicjm requested a review from kartben June 17, 2025 09:15

SoftwareArchitekt added 2 commits June 17, 2025 13:48

boards: fix ram size

98f1821

fix ram size to be aligned with soc, fix some file layouts Signed-off-by: SoftwareArchitekt <[email protected]>

boards: doc fix

22bc8a5

fix document error for build-docs run Signed-off-by: SoftwareArchitekt <[email protected]>

SoftwareArchitekt requested a review from nordicjm June 19, 2025 03:00

Adding SOC WCH ch32v307 and board scdz ch32v307evt #91702

Are you sure you want to change the base?

Adding SOC WCH ch32v307 and board scdz ch32v307evt #91702

Conversation

SoftwareArchitekt commented Jun 16, 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!

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!

Choose a reason for hiding this comment

Uh oh!

miggazElquez commented Jun 17, 2025

Uh oh!

sonarqubecloud bot commented Jun 17, 2025

Quality Gate passed

Uh oh!

miggazElquez commented Jun 17, 2025

Uh oh!

Uh oh!