search

zephyrproject-rtos / zephyr

Primary Git Repository for the Zephyr Project. Zephyr is a new generation, scalable, optimized, secure RTOS for multiple hardware architectures.
https://docs.zephyrproject.org
Apache License 2.0
10.6k stars 6.49k forks source link

[RFC] GigaDevice Vendor Support #38657

Open nandojve opened 3 years ago

nandojve commented 3 years ago

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 and NMSIS 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:

├── gd32f403
│   ├── cmsis
│   │   └── gd
│   │       └── gd32f403
│   │           ├── include
│   │           │   ├── gd32f403.h
│   │           │   └── system_gd32f403.h
│   │           └── source
│   │               └── system_gd32f403.c
│   ├── README.h
│   └── standard_peripheral
│       ├── include
│       │   ├── gd32f403_adc.h
│       │   ├── ...
│       │   └── gd32f403_wwdgt.h
│       └── source
│           ├── gd32f403_adc.c
│           ├── ...
│           └── gd32f403_wwdgt.c
├── gd32bf103
│   ├── README.h
│   ├── riscv
│   │   ├── include
│   │   │   ├── gd32vf103.h
│   │   │   └── system_gd32vf103.h
│   │   └── source
│   │       └── system_gd32vf103.c
│   └── standard_peripheral
│       ├── include
│       │   ├── gd32vf103_adc.h
│       │   ├── ...
│       │   └── gd32vf103_wwdgt.h
│       └── source
│           ├── gd32vf103_adc.c
│           ├── ...
│           └── gd32vf103_wwdgt.c
└── zephyr
    └── module.yml

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

Boards/SoC

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.

Other drivers

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

fanghuaqi commented 3 years ago

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 Huaqi

soburi commented 3 years ago

Hi, @nandojve, Good summary about gd32, great!

Putting All SoC drivers into a single hal_gigadevice is a good suggestion.

There is various way to How to introduce NMSIS to zephyr. I think that it is good to separate it into "hal_nuclei" as an external module.

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 https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library/pull/2. It may be usable.) Or it is also conceivable to place on subsys/portability like as CMSIS.

nandojve commented 3 years ago

Hi @fanghuaqi , @soburi ,

Thank you for your comments.

I'm favor to use nmsis and I have some doubts about create a hal_nuclei.

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:hal_gigadevice and hal_nuclei. The sync process can be long because can delay Zephyr code review and acceptance. Besides that it will be two distinct git history.

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:

  ...
   ├── modules
   │    ├── hal_gigadevice
   │    │    └── GD32VF103
   │    │         ├── RISCV
   │    │         │   └── ...
   │    │         └── NMSIS
   │    │              └── ... /* non zephyr , vendor specific code */
   │    └── nmsis
   │        └── ... /* fork from  https://github.com/Nuclei-Software/NMSIS */
   └──zephyr
         └── soc
              └── riscv
                   └── nmsis
                        ├── ... /* zephyr specific */
                        └── gd32vf103
                             └── ... /* zephyr specific */

I would like know your opinion on this topic.

soburi commented 2 years ago

@nandojve

I think the structure you suggested is preferable.

...
├─ modules
│      └─ nmsis
│           └─ ... /* fork from https://github.com/Nuclei-Software/NMSIS */

As you pointed out, it can be referenced from multiple vendors and is consistent. Synching with https://github.com/Nuclei-Software/NMSIS makes it easy to maintain it.

(I thought it would be better to separate NMSIS into vendors since it is specific to nuclei. I think this structure will allow it to be correctly sharable between multiple vendors.)

cameled commented 2 years ago

Add interrupt support for gd32 serial driver on https://github.com/zephyrproject-rtos/zephyr/pull/39897. It's still in progress, suggestion are welcome.

cameled commented 2 years ago

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

cameled commented 2 years ago

Add FMC #42809 and ADC #42215 drivers, suggestion are welcome!

sbourdelin commented 2 years ago

Hi @nandojve ,

you might want to add the GD32F450Z_EVAL board : https://github.com/zephyrproject-rtos/zephyr/pull/45346

nandojve commented 2 years ago

you might want to add the GD32F450Z_EVAL board : https://github.com/zephyrproject-rtos/zephyr/pull/45346

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.

nandojve commented 2 years ago

@sbourdelin see #47227

sbourdelin commented 2 years ago

@sbourdelin see #47227

Thanks i'm gonna take a look

soburi commented 1 year ago

@nandojve Added #51955 to TIMER driver task.

lmikl commented 1 year ago

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?

nandojve commented 1 year ago

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.

soburi commented 1 year ago

The RTC driver implementation could not start because https://github.com/zephyrproject-rtos/zephyr/pull/52618 was not finished. It's finally done, so we can start now.