Add a hal for Nuclei RISC-V core and SoCs

[soburi]

This PR adds support for GigaDevice GD32V SoC and SiPeed Longan Nano board that is use the SoC.
Currently, the west module dependency points to https://github.com/soburi/hal_nuclei.

Support:
GPIO
UART (UART0 only, pins are fixed)

WIP:
Support pinctrl.
Add SPI and other drivers.

Origin

Nuclei Software Development Kit
https://github.com/Nuclei-Software/nuclei-sdk

Fork and modifying to work with ZephyrRTOS
https://github.com/soburi/hal_nuclei

Purpose

Driver and Board Support Package for Nuclie RISCV core and SoC

Mode of integration

As External Module.
Same as other HAL modules are so.

Pull Request

#34970

(As a part of GigaDevice GD32V support PR)

Description

It is a BSP that is needed to support Nuclei's RISC-V core based SoCs.
I sent another PR to support GigaDevice GD32V SoCs.
This package is used by the PR.

Dependencies

No other module needs to work on this.

Revision

https://github.com/soburi/hal_nuclei
ce2159a6320d9b72ed52a609bcce0fb0e2dd5261

License

Apache-2.0

[nandojve]

I noted that hal_nuclei/SoC is, in fact, GD32VF103 Firmware Library. On my view, a hal_gigadevice should be created. That could aggregate all GigaDevice MCUs at same place, including ARM and RISC-V devices.

GigaDevice uses same peripheral on both ARM and RISC-V (some exceptions like interrupt controller) and all drivers developed to GD32 should be shared between both architectures always possible.

@soburi ,

What do you need from hal_nuclei that is not on hal_nuclei/SoC?

[soburi]

I noted that hal_nuclei/SoC is, in fact, GD32VF103 Firmware Library. On my view, a hal_gigadevice should be created. That could aggregate all GigaDevice MCUs at same place, including ARM and RISC-V devices.

Previously, https://github.com/riscv-mcu/GD32VF103_Firmware_Library is distributed by GigaDevice as SDKs.
The repository's README references https://github.com/Nuclei-Software/nuclei-sdk that provides more good support for the SoC.
nuclei-sdk seems newer, I select it.

GigaDevice uses same peripheral on both ARM and RISC-V (some exceptions like interrupt controller) and all drivers developed to GD32 should be shared between both architectures always possible.

I agree it.

@soburi ,

What do you need from hal_nuclei that is not on hal_nuclei/SoC?

nuclei/NMSIS/Core contains header files for CPU core related defines such as registers etc.
Any other files are not included from CMakeLists.txt.

[galak]

The module repo contains various .a files that should not be allowed.

[carlescufi]

@soburi thanks for the submission.
This was discussed in today's Technical Steering Committee meeting, and we had a couple of additional questions for you:

• Are you employed by GigaDevices? If not, do you have contact with them? Being employed by the silicon vendor is not a requirement.
• Are you willing to maintain the port for the foreseeable future? This means reacting to GitHub issues being filed, updating the HAL repo and board support when required and other maintainer-related tasks.
• We noticed that the original HAL repo contains files that are not Apache v2 licensed. Could you run a tool like scancode toolkit and post a summary of the licenses found?
• As @galak mentioned, precompiled libraries are not allowed, so please remove those

[soburi]

@carlescufi,

Thanks for checking this PR.

Are you employed by GigaDevices? If not, do you have contact with them? Being employed by the silicon vendor is not a requirement.

I'm not an employee of GigaDevice. and not in contact with them so well.
(I'm just a user of their board and chip. and I want to run Zephyr on it.
This chip is released a past year ago but has not to do support Zephyr yet.
To me, it looks like GigaDevice has not much attention to Zephyr.
So I added to support this chip to Zephyr.
I want GigaDevice to contribute to Zephyr!)

Are you willing to maintain the port for the foreseeable future? This means reacting to GitHub issues being filed, updating the HAL repo and board support when required and other maintainer-related tasks.

Yes, I can handle problems and maintain this ports.

We noticed that the original HAL repo contains files that are not Apache v2 licensed. Could you run a tool like scancode toolkit and post a summary of the licenses found?
As @galak mentioned, precompiled libraries are not allowed, so please remove those

Correct the problems and pushed. (https://github.com/soburi/hal_nuclei/commit/7b31adc247673bf12fd655361c479a0d4b551787)
Remove static link libraries and files that do not explicitly mention licenses.

I attach to this PR the result of scancode (gziped html).
(run scancode -clpeu --classify --summary --verbose --html scancode.html [dir])

scancode.html.gz

[carlescufi]

@soburi thank you very much for the clarifications, the attached scan report and the modifications to the PR. Would you mind removing the doc/ folder from the HAL repo so we avoid the GPL licenses? I do not think we need that in Zephyr. Please attach another report after doing that, and hopefully there will only be Apache and BSD after that.

[carlescufi]

@fanghuaqi thank you for your comment in the PR. Can you state, on behalf of GigaDevice, that you intend to help @soburi maintain this port in the future?

[soburi]

@carlescufi

Would you mind removing the doc/ folder from the HAL repo so we avoid the GPL licenses?

I forgot.
I correct it and re-pushed. (https://github.com/soburi/hal_nuclei/commit/b22713f28040fd42be0f533eb444678b9933b9d6)

The result of scancode is here.
Only Apache2 and BSD3-Clause are remain.

scancode2.html.gz

[fanghuaqi]

@fanghuaqi thank you for your comment in the PR. Can you state, on behalf of GigaDevice, that you intend to help @soburi maintain this port in the future?

Hi @carlescufi ， I am the maintainer from Nuclei System Technology, not on behalf of GigaDevice, by the way, our doc under doc/ folder are also apache 2.0 license.

If you would like to maintain a HAL for nuclei, I would prefer to maintain it in nuclei-sdk directly, we can discuss which files we need to add?

Thanks
Huaqi

[olofj]

I am not sure I understand why we are bringing in full SoCs as HALs + external sources like this now. There are native drivers in Zephyr for lots of SoCs, why does this one need to use out-of-tree drivers like this? They don't integrate into Zephyr natively this way, and just makes it awkward.

It would be a lot easier if you did lightweight ports of the peripherals as native Zephyr drivers. I'd expect that at least some of the peripherals are standard ones, they might even already have working drivers in Zephyr.

[soburi]

@olofj

Thank you for your mention.

Please tell me about your concerns.
Is it concern about the overall policy about zephyr?
Or is it a problem with this PR?

I wrote the code regarding the existing implementation of other SoCs. If my code violates zephyr's manner, I will correct it.
If it is problem with zephyr overall, it is a bit difficult for me to answer shortly.
I want to discuss.

Regards.

[nandojve]

I would like suggest a structure to accommodate both ARM and RISC-V:

1. Add a hal_gigadevice
   This will have all SoC related code, something like this proposal
2. Instead add hal_nuclei or even a sdk_nuclei, I believe the relevant part is NMSIS. NMSIS is pretty close to ARM CMSIS. I think this will better scale since NMSIS is supposed to be used by any other new manufacturer than GigaDevices.
3. sdk_nuclei can use hal_gigadevice as submodule, same with NMSIS.
4. Once all gigadevices are at same repository, as consequence it is possible share any gd32 zephyr drivers between ARM and RISC-V.

This ARM+RISC-V build for both ARM and RISC-V. It can be a prove of concept related to the structure proposed above. The gd32f403z_eval was tested on HW and works. RISC-V part implements the structure but don't have a working code yet. It should be reworked using NMSIS to have a functional code. Docs should be Ignored since it is just a structure proposal.

This is just a structure proposal that, I think, can inspire some ideas and help to move forward.

[soburi]

@nandojve

Thanks for the comments.

I was worried about how source code structure is good for this SoC in coding.
The suggestion is sound good.

I pushed sources to hal_nuclei which is a single repository.
and after, remove files that are licensed unclearly.
As a result, now it contains only NMSIS (headers about Nuclei core) and GigaDevice peripheral driver.
I think splitting Nuclei's source and GigaDevice's source will make it easy to maintain.

NMSIS is like an ARM's CMSIS, I think it may good for creating that own directory.
GigaDevice peripherals are also used by other GigaDevice's ARM SoCs. It was maybe good to split into hal_gigadevice.

As so result of the above, I think the directory structure will be like this.

modules
 |- hal
    |- nuclei
         |- NMSIS
    |- gigadevice
         |- GD32VF103_Firmware_Library
         |- (other GigaDevice SoC's driver add in future...)

I'll try to it. (https://github.com/soburi/hal_gigadevice)