[Draft] Add support for WCH CH32V SoC/CH32V307V-EVB-R1 board #49886

soburi · 2022-09-04T00:18:53Z

Add support for WCH CH32V307, and CH32V307V-EVB-R1 which is the evaluation board of this SoC.
Currently, Blinky and Hello World sample worked and it be able to debug and flash.

CH32V307 is built with a RISC-V core and STM32 cloned peripherals.
It is a similar configuration to GigaDevice GD32VF103.

HAL problems

I think it can use the gd32 driver by adding a modification to vendor-supplied HAL.
(Add APIs that are compatible with GD32 HAL's one.)
Or maybe good to create a "generic STM32 clone HAL".

This point will need to discuss.

OpenOCD problems

The link is OpenOCD binaries that support CH32V307.
http://file.mounriver.com/tools/MRS_Toolchain_Linux_x64_V1.50.tar.xz

The source is not officially provided.
It will probably also become a problem.
(unofficially https://github.com/kprasadvnsi/riscv-openocd-wch)

So, I think complete this PR more a little time.

If using GPIO without the interrupts, GPIO can work even without EXTI. Adding #ifdef guard to divide the code that depends on EXTI. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

zephyrbot · 2022-10-02T07:16:10Z

The following west manifest projects have been modified in this Pull Request:

Name	Old Revision	New Revision	Diff
hal_wch	N/A	soburi/hal_wch@`a2d01f4` (main)	N/A

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

carlocaione · 2022-10-03T08:27:08Z

arch/riscv/Kconfig

I'm fine with adding this but adding weak symbols and blurring the distinction between PLIC and CLIC is something that must be justified a bit better. Why do you need this? To save some code or do you actually need this to be able to implement support for this board?

I think it make improvement to introduce the weak symbol, but that is not mainly intention in this PR.
Rewrite it based on current code.

I consider to create another PR to introduce the weak symbol.

carlocaione · 2022-10-03T08:28:14Z

west.yml

we usually do not pull directly from outside repos. See the other modules in this file.

I need to submit it to zephyr as the new module.
I will update it after approve it.

Added HAL module for WCH devices Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

This patch introduces modules/hal_wch, which contains CMakeLists.txt and Kconfig to build WCH SoCs. WCH's CH32V SoCs have STM32 compatible peripherals. Zephyr already supports GD32 peripherals, which are compatible with STM32's one. So it is possible to use the GD32 drivers for such peripherals. The HAL implements GD32 compatible layer, and It can use with the GD32 drivers. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

Add wch(Nanjing Qinheng Microelectronics Co., Ltd) binding prefix. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

Add support for the WCH QingKe core's systick timer. The timer is built-in the WCH QingKe processor core. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

Add support for the PFIC interrupt controller which is used with the WCH QingKe processor core. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

Add the condition that use the WCH PFIC interrupt controller to arch/riscv/irq.h and soc_common_irq.c. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

Add support for WCH CH32V307 SoC. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

Add a basic support for WCH CH32V307V-EVT-R1. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

gmarull

Definitely a no-go to re-use GD32 drivers. While CH devices are yet another ST clone, we can't re-use Zephyr drivers because we're using HALs underneath.

It's interesting because we could probably have generic drivers for ST/GD/CH if they were native, but definitely not with current approach. But still, these clones are not 100% equal, registers are named differently to start with...

github-actions · 2022-12-04T00:30:04Z

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.

tagunil · 2023-01-20T23:11:05Z

Definitely a no-go to re-use GD32 drivers. While CH devices are yet another ST clone, we can't re-use Zephyr drivers because we're using HALs underneath.

It's interesting because we could probably have generic drivers for ST/GD/CH if they were native, but definitely not with current approach. But still, these clones are not 100% equal, registers are named differently to start with...

Could you please point me to any specific differences or other issues that could prevent using ST peripheral drivers for these clones?

gmarull · 2023-01-27T10:23:22Z

Definitely a no-go to re-use GD32 drivers. While CH devices are yet another ST clone, we can't re-use Zephyr drivers because we're using HALs underneath.
It's interesting because we could probably have generic drivers for ST/GD/CH if they were native, but definitely not with current approach. But still, these clones are not 100% equal, registers are named differently to start with...

Could you please point me to any specific differences or other issues that could prevent using ST peripheral drivers for these clones?

HAL license?

tagunil · 2023-01-27T10:43:15Z

Definitely a no-go to re-use GD32 drivers. While CH devices are yet another ST clone, we can't re-use Zephyr drivers because we're using HALs underneath.
It's interesting because we could probably have generic drivers for ST/GD/CH if they were native, but definitely not with current approach. But still, these clones are not 100% equal, registers are named differently to start with...

Could you please point me to any specific differences or other issues that could prevent using ST peripheral drivers for these clones?

HAL license?

As far as I can see, HALs are licensed under 3-clause BSD.

gmarull · 2023-01-27T11:28:16Z

Definitely a no-go to re-use GD32 drivers. While CH devices are yet another ST clone, we can't re-use Zephyr drivers because we're using HALs underneath.
It's interesting because we could probably have generic drivers for ST/GD/CH if they were native, but definitely not with current approach. But still, these clones are not 100% equal, registers are named differently to start with...

Could you please point me to any specific differences or other issues that could prevent using ST peripheral drivers for these clones?

HAL license?

As far as I can see, HALs are licensed under 3-clause BSD.

Right, so in theory it could be done. However, in case of GD32 for example, register names are different, and part numbers do not follow STM32, see for example the big IP differences between F403/F450. I'd only go for unified drivers if they are implemented natively, where you have freedom on how to organize code properly and account for multiple vendors differences. I doubt that ST maintainers have any interest in going that path, even though it would be nice to see.

tagunil · 2023-01-27T11:47:25Z

Definitely a no-go to re-use GD32 drivers. While CH devices are yet another ST clone, we can't re-use Zephyr drivers because we're using HALs underneath.
It's interesting because we could probably have generic drivers for ST/GD/CH if they were native, but definitely not with current approach. But still, these clones are not 100% equal, registers are named differently to start with...

Could you please point me to any specific differences or other issues that could prevent using ST peripheral drivers for these clones?

HAL license?

As far as I can see, HALs are licensed under 3-clause BSD.

Right, so in theory it could be done. However, in case of GD32 for example, register names are different, and part numbers do not follow STM32, see for example the big IP differences between F403/F450. I'd only go for unified drivers if they are implemented natively, where you have freedom on how to organize code properly and account for multiple vendors differences. I doubt that ST maintainers have any interest in going that path, even though it would be nice to see.

I think these differences could be accounted for even with current approach, at least for simple peripherals like UARTs and timers. But I agree that this path is infeasible without some degree of maintainer support.

soburi · 2023-02-04T14:48:11Z

@tagunil

Ideally, libopencm3 is a generic firmware for STM32clone, so I'd like to use it, but unfortunately the license is GPL, so I can't incorporate it into zephyr.

Since the low-level HAL of STM32 is BSD licensed, It may be possible to support combined with it and 'forked' gd32 driver.
However, even in this case, it seems that various F103 clones that are highly compatible with the original can be used, but I think that clones such as F4XX will require individual support. (Otherwise we'll be in #ifdef hell!)

findlayfeng · 2023-04-24T01:34:51Z

@soburi Hello, is this PR still working?
I can do something.

soburi · 2023-04-24T02:35:34Z

@findlayfeng

As an issue, I'm worried about how better way to make HAL, but I can't find a good approach, so I've stuck.

Of course, I can solve it by simply importing the HAL provided by WCH, but I'm consider if I can create a common HAL for STM32(F103) clones.

findlayfeng · 2023-04-24T04:10:06Z

I think the HAL provided by WCH should be imported directly.
although it looks very similar to stm32(f103), we are not maintainers of the hardware and don't need to consider whether they are consistent.

soburi requested review from dcpleung, galak, kgugala, nashif and pgielda as code owners September 4, 2022 00:18

soburi marked this pull request as draft September 4, 2022 00:19

zephyrbot added area: Timer Timer area: RISCV RISCV Architecture (32-bit & 64-bit) area: Interrupt Controller area: Devicetree labels Sep 4, 2022

zephyrbot requested review from KangJianX, andyross, carlocaione, edersondisouza, fkokosinski, katsuster, mbolivar-nordic, mgielda and tgorochowik September 4, 2022 00:19

zephyrbot assigned kgugala Sep 4, 2022

soburi force-pushed the add_ch32v307v_evb_r1 branch from bab3e08 to c1cdc50 Compare September 4, 2022 00:52

drivers: gpio: gd32: Make possible to compile without EXTI

f140164

If using GPIO without the interrupts, GPIO can work even without EXTI. Adding #ifdef guard to divide the code that depends on EXTI. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

soburi force-pushed the add_ch32v307v_evb_r1 branch from c1cdc50 to 5eb04d5 Compare October 2, 2022 07:15

zephyrbot added manifest west manifest-hal_wch DNM This PR should not be merged (Do Not Merge) labels Oct 2, 2022

soburi force-pushed the add_ch32v307v_evb_r1 branch 2 times, most recently from 63d92f7 to 4cd45f5 Compare October 2, 2022 14:50

soburi force-pushed the add_ch32v307v_evb_r1 branch 3 times, most recently from be8ee3d to d36d437 Compare October 2, 2022 17:46

carlocaione requested changes Oct 3, 2022

View reviewed changes

soburi added 8 commits October 3, 2022 19:42

manifest: [DNM] Add WCH HAL

0b11367

Added HAL module for WCH devices Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

dts: bindings: vendor-prefixes: Add wch prefix

a424b05

Add wch(Nanjing Qinheng Microelectronics Co., Ltd) binding prefix. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

drivers: timer: add WCH QingKe core systick driver

454e985

Add support for the WCH QingKe core's systick timer. The timer is built-in the WCH QingKe processor core. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

drivers: interrupt-controller: add WCH PFIC driver

fba3096

Add support for the PFIC interrupt controller which is used with the WCH QingKe processor core. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

soc: riscv: riscv-privilege: Add supoort for WCH PFIC

10c7728

Add the condition that use the WCH PFIC interrupt controller to arch/riscv/irq.h and soc_common_irq.c. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

soc: riscv: Add initial support for WCH CH32V307 SoC

23aebb6

Add support for WCH CH32V307 SoC. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

boards: riscv: Add support for WCH CH32V307V-EVT-R1 board

d87ac35

Add a basic support for WCH CH32V307V-EVT-R1. Signed-off-by: TOKITA Hiroshi <tokita.hiroshi@gmail.com>

soburi force-pushed the add_ch32v307v_evb_r1 branch from d36d437 to d87ac35 Compare October 3, 2022 12:07

gmarull requested changes Oct 4, 2022

View reviewed changes

soburi mentioned this pull request Oct 6, 2022

drivers: gpio: gd32: add dependency on the EXTI #50879

Merged

github-actions bot added the Stale label Dec 4, 2022

github-actions bot closed this Dec 19, 2022

[Draft] Add support for WCH CH32V SoC/CH32V307V-EVB-R1 board #49886

[Draft] Add support for WCH CH32V SoC/CH32V307V-EVB-R1 board #49886

Uh oh!

Conversation

soburi commented Sep 4, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

HAL problems

OpenOCD problems

Uh oh!

zephyrbot commented Oct 2, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

carlocaione Oct 3, 2022

Choose a reason for hiding this comment

Uh oh!

soburi Oct 3, 2022

Choose a reason for hiding this comment

Uh oh!

carlocaione Oct 3, 2022

Choose a reason for hiding this comment

Uh oh!

soburi Oct 3, 2022

Choose a reason for hiding this comment

Uh oh!

gmarull left a comment

Choose a reason for hiding this comment

Uh oh!

github-actions bot commented Dec 4, 2022

Uh oh!

tagunil commented Jan 20, 2023

Uh oh!

gmarull commented Jan 27, 2023

Uh oh!

tagunil commented Jan 27, 2023

Uh oh!

gmarull commented Jan 27, 2023

Uh oh!

tagunil commented Jan 27, 2023

Uh oh!

soburi commented Feb 4, 2023

Uh oh!

findlayfeng commented Apr 24, 2023

Uh oh!

soburi commented Apr 24, 2023

Uh oh!

findlayfeng commented Apr 24, 2023

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

soburi commented Sep 4, 2022 •

edited

Loading

zephyrbot commented Oct 2, 2022 •

edited

Loading