-
Notifications
You must be signed in to change notification settings - Fork 6.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] GigaDevice Vendor Support #38657
Comments
Hi @nandojve , your RFC is very clear about this GD devices support, since this GD32VF103 device and its peripheral drivers are released before NMSIS born, and the source code about Nuclei RISC-V core drivers are using very old Nuclei RISC-V support code, @GigaDevice-Semiconductor released their source code of gd32vf103 in github https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library, but it is not yet actively developed, and receiving any PR about it. Nowadays, more and more of our customers are familiar with NMSIS, and willing to following the source code structure we present in NMSIS and Nuclei-SDK. HAL for NMSIS will be necessary for future silicon vendors to port their devices based on Nuclei RISC-V core. Thanks |
Hi, @nandojve, Putting All SoC drivers into a single hal_gigadevice is a good suggestion. There is various way to How to introduce NMSIS to zephyr. Only GD32VF103 use NMSIS at this time, so containing NMSIS into the GD32VF103 directory in hal_gigadevice is also one possible way, I think. (I propose to the GigaDevice firmware updating with NMSIS as GigaDevice-Semiconductor/GD32VF103_Firmware_Library#2. It may be usable.) |
Hi @fanghuaqi , @soburi , Thank you for your comments. I'm favor to use nmsis and I have some doubts about create a I'm not so sure about split peripheral drivers between two distinct projects. My concern is that any peripheral driver API changes will require modifications at both places: I'll suggest that Nuclei Systems code should be used same way ARM code is. I mean, have a nmsis module which can be sync directly from https://github.com/Nuclei-Software/NMSIS and add proper vendor specific code that follows nmsis layout. The majority of users already know about ARM code structure. This is an advantage that should be explored. Let's assume nmsis module for instance:
Suggested layout:
I would like know your opinion on this topic. |
I think the structure you suggested is preferable.
As you pointed out, it can be referenced from multiple vendors and is consistent. (I thought it would be better to separate NMSIS into vendors since it is specific to nuclei. |
Add interrupt support for gd32 serial driver on #39897. |
GD32 Firmware library function name not have prefix or suffix to make it unique, Maybe we should use some trick to avoid name conflict. I find hal_espressif use a link time symbol, e.g. https://github.com/zephyrproject-rtos/hal_espressif/blob/zephyr/zephyr/esp32s2/src/linker/esp32s2.rom.alias.ld |
Hi @sbourdelin , yes we want but need wait next merge window to be open. Currently the project is only accepting docs and bug fixes to release next version. BTW: This is maintained by community and everyone is invited to contribute with some functionality. Feel free to add your name side on the above list if that is the case. |
@sbourdelin see #47227 |
Thanks i'm gonna take a look |
Hello everyone, I have a project that needs to use a tamper entry and backup register. These features are related to the RTC part which is apparently not yet done. Is anyone working on writing the RTC driver or already using this feature? |
Hi @lmikl , As far I know not one is working on RTC/Tamper. If you want I can "assigned" you then everybody know you are on it. It is recommended that you join at Zephyr discord and ping at vendors/gigadevice about this questions. |
The RTC driver implementation could not start because #52618 was not finished. It's finally done, so we can start now. |
Introduction
There is community interest to add support to GigaDevice SoC Vendor in Zephyr. Community members have intentions to support both ARM and RISC-V SoC's. This RFC was opened to serve as an umbrella to help community and Zephyr members know the initiatives.
Problem description
Currently there are some attempts to introduce support in Zephyr:
#36832
#36833
#34970
#34971
The main discussion was conducted at #34971, which is TSC tagged.
Proposed change
Give an overview about all pieces required to add GigaDevice SoC Vendor in Zephyr.
Detailed RFC
In this section of the document the target audience is the dev team. Upon reading this section each engineer should have a rather clear picture of what needs to be done in order to implement the described feature.
There are two content groups that need to be addressed: hal and drivers.
Vendors HAL
There are two vendors dependencies that should be addressed:
hal_gigadevice
andNMSIS module
.The HAL GigaDevice
This HAL is necessary to keep tracking with manufacturer firmware versions. The vendor provide an API that abstracts registers access and it is well tested. The documentation and firmware versions can be found at gd32mcu.com web site.
Some SoC series may have aditional features. This is the reason for some series have different drivers versions. For instance, F403 series not share same drivers versions with other SoC from the same series.
To address those details a directory structure is proposed. It is composed by default Zephyr module structure plus each SoC series directory. The below example uses gd32f403 ARM series and gd32vf103 RISC-V series:
The content of CMSIS and NMSIS should be replaced by proper Zephyr structure over time. In the ARM case, it is straightforward to bring up any board. The NMSIS will follow the decision of NMSIS module.
The remaining content of firmware package from vendor should not be added. The reason that is for Zephyr use case only the peripheral definitions are the essential component.
NMSIS module from Nuclei Systems
Nuclei System Technology is a RISC-V processor IP and solution provider. Nuclei Systems collaborated with GigaDevice for the first RISC-V based general-purpose MCU in the world — GD32VF103. The NMSIS is a similar core with a structure similar to ARM CMSIS. More information at www.nucleisys.com and Nuclei-Software.
It is not 100% clear yet how integrate this structure into Zephyr. The main discussion was initially made at #34971. The Nuclei Systems suggested initially that gd32vf103 drivers should be at same place of NMSIS. However, this can be a problem to share drivers and support more Nuclei Systems newer IPs. Besides GD32VF103 directory contains the RISCV directory the intention is not use that content and can be keep it for historical reasons.
Peripheral Drivers
The GD32 platform shares in many cases the same peripheral IPs. This means that community members should check for compatibility between some SoC series. The suggested list is:
Dependencies
The current dependencies are add module NMSIS from Nuclei Systems and HAL gigadevices. Those are the fundamental base to create the future port and Zephyr drivers.
Task List
The below task list is a suggestion plan to coordinate work to enable minimal support on Zephyr:
Essential List
[RFC] Add hal_gigadevice to support GigaDevice SoC Vendor #38727west.yml: Add hal gigadevice #38658ARM: Introduce gigadevice gd32f403 #38661
Add NMSIS moduleAdd support for Nuclei ICs in the main tree, insoc/riscv/
(@soburi)dts: bindings: vendor-prefixes: Add gigadevice prefix #38659ARM: Introduce gigadevice gd32f403 #38661
ARM: Introduce gigadevice gd32f403 #38661
and gd32isp flasher)ARM: Introduce gigadevice gd32f403 #38661
boards: Add support GigaDevice GD32V SoC #34970
boards: Add support GigaDevice GD32V SoC #34970
scripts: runner: Introduce gd32isp flash runner #38660
ARM: Introduce gigadevice gd32f403 #38661
RCUClock Control Driver ( @nandojve @gmarull: https://github.com/teslabs/zephyr/tree/clock-control-gd32)boards: Add support GigaDevice GD32V SoC #34970
gpio: gd32: initial support #40676
gpio: gd32: initial support #40676
pinctrl: initial support for GD32 #39974
Enable RCU Supportpinctrl: initial support for GD32 #39974
drivers: serial: gd32: Add interrupt support #39897
Boards/SoC
Boards: arm: gd32a503v_eval: introduce gd32a503v_eval board #52774
boards: arm: Add gd32e103v_eval board #36833
boards: gd32e507z_eval: add initial support #49547
Add initial support for GD32E50X and GD32E507V-START #48663
boards: arm: Introduce gd32f350r_eval board #40283
Add GD32F405xx series SoCs #41156
boards: arm: gd32f407v_start: Add initial support for gd32f407v_start #49085
Introduce GD32F4xx serial SoCs with GD32F450i_EVAL board #39909
boards: arm: GD32F450I-EVAL: add initial support #39958
boards: gd32f450v_start: add initial support #49593
boards: arm: gd32f450z_eval: add initial support #45346
boards: arm: gigadevice: Initial support for gd32f470ik #46894
Add GD32L233R-EVAL board support #52654
boards: riscv: gd32vf103v_eval: initial support #41483
boards: riscv: introduce gd32vf103c_starter board #43439
Driver Extended List
The extended list is not limited and community is encouraged to edit and add/remove entries. It is recommended complete the essential list before start with any item from the extended list to avoid unnecessary future rework.
Drivers: ADC: Introduce gd32 adc driver #42215
Drivers: CAN: Introduce CAN driver for gd32 #43342
drivers: dac: Introduce gd32 driver #41152
drivers: dma: Add GD32 DMA driver #47501
dts: bindings: dma: gd32: Redesign DMA node's cell properties #48756
drivers: ethernet: gd32: GigaDevice ENET support #47227
drivers: flash: Introduce gd32 flash controller driver #42809
drivers: i2c: Introduce GD32 I2C driver #41506
drivers: pwm: add GD32 PWM driver #41173
drivers: spi: Initial support for GD32 spi #40416
drivers: spi: gd32: support interrupt-driven mode #47499
drivers: spi: gd32: Add support DMA transfer #47504
drivers: counter: add support for GD32 timer #51955
drivers: usb: Add OTGFS USB device controller #63585
drivers: watchdog: Add support for the GD32 watchdog timers #41673
Other drivers
drivers: reset: gd32: add initial support #49378
Enhancements
Note to Community
The GigaDevice and Nuclei System community are encouraged to edit this RFC proposal.
CC: @feilongfl @soburi @fanghuaqi
Zephyr: @galak @carlescufi @olofj @cfriedt @kgugala @MaureenHelm @katsuster
The text was updated successfully, but these errors were encountered: