New module creation: hal_wch [was: External source integration for soc/wch/ch32v00x/ch32v003fun.h]

[fabiobaltieri]

Origin

This is to request the creation of a hal_wch repository, as a direct fork of initially containing few selected headers from https://github.com/cnlohr/ch32v003fun. Current repo: https://github.com/kholia/hal_wch

Purpose

Allow Zephyr code to access the register map files of WCH CH32V family of microcontrollers, no plan to use it as an actual HAL, at least initially.

Will include more parts in the future, ble binary blobs if needed etc, same as other hal modules.

Mode of integration

Module, importing https://github.com/kholia/hal_wch as a starting point.

Maintainership

@kholia @nzmichaelh

Pull Request

https://github.com/zephyrproject-rtos/zephyr/pull/76540 (just the module) https://github.com/zephyrproject-rtos/zephyr/pull/73761 (initial soc support)

Description

The repo is a selection of relevant files from https://github.com/cnlohr/ch32v003fun, for now just the register map for the initial device, MIT licensed.

Future scope would be to have more register maps for other parts from the same vendor, potentially ble support blobs and whatever is needed for supporting these devices.

Dependencies

None.

Revision

https://github.com/kholia/hal_wch/commit/1de9d3e406726702ce7cfc504509a02ecc463554

License

MIT

Notes

Alternatives considered were to import the file directly in the main repository, but that was ruled out due to coding style and license differences. Then it was proposed to track ch32v003fun directly, but that turns out to also be problematic as the repository hosts some extra binary files and other sources with stray licenses. So here we are blank repo, just the files and license.

[nzmichaelh]

I'm happy to be a maintainer.

[cnlohr]

Please be aware I'm happy to upstream any files or direct changes that would make this easier, and to minimize the forkyness of your branch.

[fabiobaltieri]

Thanks folks, ok based on the conversation in https://github.com/zephyrproject-rtos/zephyr/pull/73761, and in light of the file license and intention to at support for more parts it seems like forking https://github.com/cnlohr/ch32v003fun into a hal_wch repo may be the the way to go. @kholia if you agree with that and can make the PR back in that form (using the whole https://github.com/cnlohr/ch32v003fun with just the extra module.yml file) I can modify this proposal to request the fork from the TSC and then we can take it from there, any further update (new device files etc) will be just a sync of the fork and west.yml update.

[kholia]

@fabiobaltieri Roger - I will get this done later today.

Update:

• https://github.com/kholia/hal_wch is up now

• https://github.com/kholia/hal_wch/blob/master/zephyr/module.yml is the Zephyr glue

I will create the PR later today.

[kholia]

@fabiobaltieri PR is up now @ https://github.com/zephyrproject-rtos/zephyr/pull/76540. Thanks!

[nandojve]

The RFC is to add 1 item but the whole hal and manufacturer details should be introduced in a way that allow the ARM and RISCV MCUs together, otherwise it does not scale up.

Questions:

1- How I should add pinctrl auto-generated files in the hal? 2- How should we add the BLE blobs for ch32v208? There will be a group that will start to work with this in Ago/24. 3- How ARM chips will be used? 4- What happen if manufacturer wants to be part of Zephyr in the future and assume the their own repos?

This is moving in a very odd way. All parts that are supported by community are simple hosted in the ZephyrProject. See, for instance GigaDevices and Atmel (MCHP).

[fabiobaltieri]

Blobs would go in the module zephyr.yml file like for any other module, don't see any particular problem with that.

Pinctrl, any issue with those going in the main Zephyr repository? There's other SoC that have them there, seems easier to manage as well.

for ARM and if the vendor wants to take control, if and when that will happen we can always reconsider the architecture of the whole repo, push whatever sha will be current at the time in a branch so that GitHub would keep it for backward compatibility and start with a new architecture in the main branch. I think it's been done before, not a problem.

I'm not saying this approach is perfect or will work forever, but I think it's the simplest with what people are working on now, and it shouldn't preclude any type of rework in the future if it turns out to be suboptimal.

[fabiobaltieri]

Updated the description, this is now a blank repo with just the relevant files. Comments welcome.

[nzmichaelh]

I've started a PR to add minichlink to the Zephyr toolchain: https://github.com/zephyrproject-rtos/sdk-ng/pull/773

@cnlohr FYI

[fabiobaltieri]

Hey, this was approved by the TSC, can we get the repo created? @nashif @stephanosio

[stephanosio]

https://github.com/zephyrproject-rtos/hal_wch has been created.

[fabiobaltieri]

Thanks folks.