Skip to content
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

[PORT] Add GD32VF103 support and Sipeed Longan Nano Board support #959

Merged
merged 27 commits into from
Aug 15, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
27 commits
Select commit Hold shift + click to select a range
2657560
Add hacky GD32VF103 support
KarlK90 Jul 9, 2021
19b971c
Add board support for gd32vf103 longan nano
KarlK90 Jul 10, 2021
ddb8378
Disable -Werror for now
KarlK90 Jul 10, 2021
771bbe8
Use https github as submodule
KarlK90 Jul 10, 2021
3db2089
Minor clean ups
KarlK90 Jul 10, 2021
23e3b16
Use JTAG for jlink flashing
KarlK90 Jul 10, 2021
790d90b
Set FreeRTOS to RISC-V (doesn't compile)
KarlK90 Jul 11, 2021
e5bd6bd
Update nuclei-sdk with __riscv_flen fix
KarlK90 Jul 12, 2021
ab1979e
Revert "Disable -Werror for now"
KarlK90 Jul 12, 2021
3eb54d8
Add stm32 license header
KarlK90 Aug 3, 2021
c6d495d
Remove dependencies to external libraries for the dcd driver
KarlK90 Aug 7, 2021
7682829
Add correct endpoint count for GD32VF103
KarlK90 Aug 7, 2021
b473923
Remove redundant linker files
KarlK90 Aug 7, 2021
6e287a7
Cleanup include paths and use linker files from nuclei-sdk
KarlK90 Aug 7, 2021
733a362
Use nuclei-sdk functions for init code
KarlK90 Aug 7, 2021
1d2a57a
Remove unsuitable clock configurations from init code
KarlK90 Aug 7, 2021
60d0311
Correctly initialize and handle the system tick
KarlK90 Aug 7, 2021
66d566f
Use functions provided by the nuclei-sdk hal
KarlK90 Aug 7, 2021
0399996
Code style changes
KarlK90 Aug 7, 2021
4cebde6
Remove unnecessary define guard
KarlK90 Aug 7, 2021
8b78067
Use linear buffer for GD32VF103
KarlK90 Aug 7, 2021
27f147f
Minor style changes
KarlK90 Aug 7, 2021
1b6540a
Update systick reload value
KarlK90 Aug 9, 2021
09e4348
move gd32vf103 to its own family
hathach Aug 15, 2021
37d9f94
add gd32vf103 to riscv ci
hathach Aug 15, 2021
73f8fae
change toolchain to riscv-none-embed-gcc-xpack for ci
hathach Aug 15, 2021
c4a6a5c
skip freertos example for gd32vf103
hathach Aug 15, 2021
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions .github/workflows/build_riscv.yml
Original file line number Diff line number Diff line change
Expand Up @@ -16,6 +16,7 @@ jobs:
family:
# Alphabetical order
- 'fomu'
- 'gd32vf103'
steps:
- name: Setup Python
uses: actions/setup-python@v2
Expand Down
3 changes: 3 additions & 0 deletions .gitmodules
Original file line number Diff line number Diff line change
Expand Up @@ -124,3 +124,6 @@
[submodule "hw/mcu/mindmotion/mm32sdk"]
path = hw/mcu/mindmotion/mm32sdk
url = https://github.com/zhangslice/mm32sdk.git
[submodule "hw/mcu/gd/nuclei-sdk"]
path = hw/mcu/gd/nuclei-sdk
url = https://github.com/Nuclei-Software/nuclei-sdk.git
Comment on lines +127 to +129
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nuclei-sdk is too overkill as submodule for just low level mcu driver. Furthermore, TinyUSB shouldn't reply on other project to provide hal layer. It is best to just use the mcu driver from the vendor, I think https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library would be a much better sub-module, since we only need a basic one.

Copy link
Contributor Author

@KarlK90 KarlK90 Aug 3, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I completely agree that the nuclei-sdk is overkill for this port, but I had chosen it over the multiple other repositories of the GD32VF firmware on github because their repository is the most up to date one and actively maintained by nucleisys which provided the RV32 core IP. Furthermore there is a bug in the GD32VF startup code in all libaries that throws an compilation error if -Wundef and -Werror is used with GCC, for which I had opened a PR. Therefore I would vote to keep this despite being more then necessary, what do you think?

The other repositories:

https://github.com/riscv-mcu/GD32VF103_Firmware_Library (Semi-official, contains a note to use nuclei-sdk, last activity in October 2020)

https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library (Is this official?, last real activity in November 2020)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pull the nuclei and did a quick check, the https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library is more updated in term of the mcu driver. The last activities you said in 2020 is update the mcu lib to v1.1. while nuclei still uses the v1.0 version. nuclei is more maintained by it is mostly for their platform, tinyusb is only interested in low level mcu driver (clock, register def). Therefore I think it make more sense to move to the said repo.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused the latest firmware library from GigaDevice is 1.1.2 from June 2021 but can only be found on http://www.gd32mcu.com/en/download/0?kw=GD32VF1 so all the repos are outdated. Judging from the activity in repositories all but nuclei-sdk seem to be unmaintained, as no pull request are merged or answered.

I hope that I don't bother you with this discussion, but I think that nuclei-sdk is the better choice from a maintenance perspective and I would happily open a PR to update the supplied firmware in nuclei-sdk. If that is not an option at all, I'll switch to the suggested https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library repository.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not bothered at all, I have looked a bit more closer. To be honest, at first I thought Nuclei is a 3rd party, but look like they are IP creator similar to ARM. And Giga put Nuclei's N200 risc-v core into their silicon. Furthermore, Nuclei seems to spend much more effort on the software/firmware side than Giga does. And I could see why you prefer to go with their sdk. Feel free to correct me if I get it wrong.

https://github.com/Nuclei-Software/NMSIS is indeed a really great repo which is set to do what CMSIS does for ARM. I think we could actually depend on this nmsis. However, I still don't want to force any other users to use nuclei sdk just to run the usb stack. They may already be on another platform/framework, that could cause an conflict. Unless there is something that we would really need from sdk that we couldn't write it ourself.

To sum up, do you think it is good enough to just add 2 submodules

This is actually very similar to stm32 with an cmisis and driver combo, https://github.com/hathach/tinyusb/blob/master/hw/bsp/stm32f103bluepill/board.mk#L2

Note: when integrating tinyusb to an application, you can freely use nuclei, and have your own board setup, just changes the include path to the corresponding. The idea is if we use an smaller set of files (mcu lib), it would be more portable.

Copy link
Contributor Author

@KarlK90 KarlK90 Aug 5, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not bothered at all, I have looked a bit more closer.

That is good to hear!

You are totally right about Nuclei, they provided the N200/BumbleBee Core for the GD32VF103 to GigaDevice and kind of co-developed the firmware library. I'm not sure why GigaDevice doesn't show a bit more effort with their firmware, it is a bit frustrating.

I still don't want to force any other users to use nuclei sdk just to run the usb stack. They may already be on another platform/framework, that could cause an conflict. Unless there is something that we would really need from sdk that we couldn't write it ourself.

I'm totally with you that we don't want conflicts in other projects. I think you are referring to namespace conflicts, like multiple definitions of the same symbol, but correct me here? My point is that the parts that we include and actively use in the compilation of tinyusb from nuclei-sdk is really just the NMSIS library and the gd32vf103 firmware library with modifications from nuclei to play along nicely with NMSIS (see below). The other header and source files related to different socs are not included in the build, it is just the bare minimum. So the conflicts should not increase by using nuclei-sdk and should be the same as using the separate NMSIS and GD32VF103 firmware repositories.

On the other hand I had started to change the current port to use the two independent repositories as suggested and ran into trouble. The NMSIS library wants specific defines that describe the capabilities of the GD32VF103. Unfortunately we can't just use this file because the GD32VF103 doesn't have a FPU and has other IRQs defined. So we would have to provide this block ourselfs in a separate header file before including nmsis_core.h in the dcd driver.

But by doing so we have a board specific header-file in a rather generic driver, which is not good. The nuclei-sdk provides these defines in gd32vf103.h which is different from the gd32vf103.h that is supplied with the firmware library. And they actually modified the firmware library in other parts to play a long nicely with NMSIS framework. The GD32VF103 firmware library is really just meant to be used on its own. There maybe even more conflicts that but I haven't explored that way further.

Given the above reasons and addressing your concerns about the conflicts could a dependency on just nuclei-sdk be the better option? What do you think?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is good to hear!

You know this much better than me, there is obvious reason why you prefer the nuclei sdk

You are totally right about Nuclei, they provided the N200/BumbleBee Core for the GD32VF103 to GigaDevice and kind of co-developed the firmware library. I'm not sure why GigaDevice doesn't show a bit more effort with their firmware, it is a bit frustrating.

Yeah, I figured it out, Giga doesn't spend much effort like ST do with their stm32

But by doing so we have a board specific header-file in a rather generic driver, which is not good. The nuclei-sdk provides these defines in gd32vf103.h which is different from the gd32vf103.h that is supplied with the firmware library. And they actually modified the firmware library in other parts to play a long nicely with NMSIS framework. The GD32VF103 firmware library is really just meant to be used on its own. There maybe even more conflicts that but I haven't explored that way further.

Given the above reasons and addressing your concerns about the conflicts could a dependency on just nuclei-sdk be the better option? What do you think?

My ultimate goal is not having usb stack to depend on nuclei-sdk to run. User should just compile it with any GD32VF103_Firmware_Library variant, especially one downloaded from the Giga site since that is what user will do. With that in mind, in the fact the nuclei has to modify the library to get it work with nmsis, I think we actually have to change the approach a bit.

  1. We can keep using nuclei-sdk, and use it for running example only ie. bsp folder.
  2. However we shouldn't use any of nuclei-sdk and/or nmsis within the src folder, i.e the dcd_synopsys.c. The reason is it will force user to use the modified firmware lib from nuclei and not be able to use official lib downloaded from Giga website. Even it is not well maintained, it is still what most user would use (unfortunately).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good to me! I'll change the implementation to meet these constraints, maybe the core code in src can even be implemented without any reliance on any gd32vf103 firmawre library or nmsis/nuclei-sdk.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for patiently following my suggestion, yeah, the example bsp is mostly for demonstrating/testing and maintaining. If nuclei-sdk make it easier for us, no problem at all, I wasn't sure before and kind of worry it will become an dependency due to the nmsis. If we could get it dcd_synopsys neutral then that would be no problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perfect! I have cleaned up and fixed a bug with the systick timer not beeing reloaded. I decided to go with nuclei-sdk inside bsp for obvious reasons ;-). Let me know what you think!

Empty file.
9 changes: 6 additions & 3 deletions examples/device/cdc_msc_freertos/src/FreeRTOSConfig.h
Original file line number Diff line number Diff line change
Expand Up @@ -150,11 +150,14 @@ extern uint32_t SystemCoreClock;
//--------------------------------------------------------------------+
// Interrupt nesting behavior configuration.
//--------------------------------------------------------------------+
/* Cortex-M specific definitions. __NVIC_PRIO_BITS is defined in core_cmx.h */
#ifdef __NVIC_PRIO_BITS
#if defined(__NVIC_PRIO_BITS)
// For Cortex-M specific: __NVIC_PRIO_BITS is defined in core_cmx.h
#define configPRIO_BITS __NVIC_PRIO_BITS
#elif defined(__ECLIC_INTCTLBITS)
// RISC-V Bumblebee core from nuclei
#define configPRIO_BITS __ECLIC_INTCTLBITS
#else
#error "This port requires __NVIC_PRIO_BITS to be defined"
#error "FreeRTOS configPRIO_BITS to be defined"
#endif

/* The lowest interrupt priority that can be used in a call to a "set priority" function. */
Expand Down
Empty file.
9 changes: 6 additions & 3 deletions examples/device/hid_composite_freertos/src/FreeRTOSConfig.h
Original file line number Diff line number Diff line change
Expand Up @@ -150,11 +150,14 @@ extern uint32_t SystemCoreClock;
//--------------------------------------------------------------------+
// Interrupt nesting behavior configuration.
//--------------------------------------------------------------------+
/* Cortex-M specific definitions. __NVIC_PRIO_BITS is defined in core_cmx.h */
#ifdef __NVIC_PRIO_BITS
#if defined(__NVIC_PRIO_BITS)
// For Cortex-M specific: __NVIC_PRIO_BITS is defined in core_cmx.h
#define configPRIO_BITS __NVIC_PRIO_BITS
#elif defined(__ECLIC_INTCTLBITS)
// RISC-V Bumblebee core from nuclei
#define configPRIO_BITS __ECLIC_INTCTLBITS
#else
#error "This port requires __NVIC_PRIO_BITS to be defined"
#error "FreeRTOS configPRIO_BITS to be defined"
#endif

/* The lowest interrupt priority that can be used in a call to a "set priority" function. */
Expand Down
3 changes: 3 additions & 0 deletions hw/bsp/board_mcu.h
Original file line number Diff line number Diff line change
Expand Up @@ -130,6 +130,9 @@
#elif CFG_TUSB_MCU == OPT_MCU_RX63X || CFG_TUSB_MCU == OPT_MCU_RX65X
// no header needed

#elif CFG_TUSB_MCU == OPT_MCU_GD32VF103
#include "gd32vf103.h"

#else
#error "Missing MCU header"
#endif
Expand Down
2 changes: 1 addition & 1 deletion hw/bsp/fomu/family.mk
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ CFLAGS += \
-nostdlib \
-DCFG_TUSB_MCU=OPT_MCU_VALENTYUSB_EPTRI

# Cross Compiler for RISC-V
# Toolchain from https://github.com/xpack-dev-tools/riscv-none-embed-gcc-xpack
CROSS_COMPILE = riscv-none-embed-

# All source paths should be relative to the top level.
Expand Down
20 changes: 20 additions & 0 deletions hw/bsp/gd32vf103/boards/sipeed_longan_nano/board.h
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
#ifndef _NUCLEI_SDK_HAL_H
#define _NUCLEI_SDK_HAL_H

#include "gd32vf103c_longan_nano.h"

// 4 bits for interrupt level, 0 for priority.
// level 0 = lowest priority, level 15 = highest priority.
#define __ECLIC_INTCTLBITS 4

#define __SYSTEM_CLOCK 72000000
#define HXTAL_VALUE ((uint32_t)8000000)

#define SOC_DEBUG_UART GD32_COM0

#define DBG_KEY_UNLOCK 0x4B5A6978
#define DBG_CMD_RESET 0x1
#define DBG_KEY REG32(DBG + 0x0C)
#define DBG_CMD REG32(DBG + 0x08)

#endif
13 changes: 13 additions & 0 deletions hw/bsp/gd32vf103/boards/sipeed_longan_nano/board.mk
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
LONGAN_NANO_SDK_BSP = $(GD32VF103_SDK_SOC)/Board/gd32vf103c_longan_nano
LINKER_SCRIPTS = $(LONGAN_NANO_SDK_BSP)/Source/GCC

# All source paths should be relative to the top level.
LD_FILE = $(LINKER_SCRIPTS)/gcc_gd32vf103xb_flashxip.ld # Longan Nano 128k ROM 32k RAM
#LD_FILE = $(LINKER_SCRIPTS)/gcc_gd32vf103x8_flashxip.ld # Longan Nano Lite 64k ROM 20k RAM

SRC_C += $(LONGAN_NANO_SDK_BSP)/Source/gd32vf103c_longan_nano.c
INC += $(TOP)/$(LONGAN_NANO_SDK_BSP)/Include

# Longan Nano 128k ROM 32k RAM
JLINK_DEVICE = gd32vf103cbt6
#JLINK_DEVICE = gd32vf103c8t6 # Longan Nano Lite 64k ROM 20k RAM
197 changes: 197 additions & 0 deletions hw/bsp/gd32vf103/family.c
Original file line number Diff line number Diff line change
@@ -0,0 +1,197 @@
/*
* The MIT License (MIT)
*
* Copyright (c) 2019 Ha Thach (tinyusb.org)
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* all copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*
* This file is part of the TinyUSB stack.
*/

#include "board.h"
#include "drv_usb_hw.h"
#include "drv_usb_dev.h"

#include "../board.h"

//--------------------------------------------------------------------+
// Forward USB interrupt events to TinyUSB IRQ Handler
//--------------------------------------------------------------------+

void USBFS_IRQHandler(void) { tud_int_handler(0); }

//--------------------------------------------------------------------+
// MACRO TYPEDEF CONSTANT ENUM
//--------------------------------------------------------------------+

#define USB_NO_VBUS_PIN

// According to GD32VF103 user manual clock tree:
// Systick clock = AHB clock / 4.
#define TIMER_TICKS ((SystemCoreClock / 4) / 1000)

#define BUTTON_PORT GPIOA
#define BUTTON_PIN GPIO_PIN_0
#define BUTTON_STATE_ACTIVE 1

#define UART_DEV SOC_DEBUG_UART

#define LED_PIN LED_R

void board_init(void) {
/* Disable interrupts during init */
__disable_irq();

#if CFG_TUSB_OS == OPT_OS_NONE
SysTick_Config(TIMER_TICKS);
#endif

rcu_periph_clock_enable(RCU_GPIOA);
rcu_periph_clock_enable(RCU_GPIOB);
rcu_periph_clock_enable(RCU_GPIOC);
rcu_periph_clock_enable(RCU_GPIOD);
rcu_periph_clock_enable(RCU_AF);

#ifdef BUTTON_PIN
gpio_init(BUTTON_PORT, GPIO_MODE_IN_FLOATING, GPIO_OSPEED_50MHZ, BUTTON_PIN);
#endif

#ifdef LED_PIN
gd_led_init(LED_PIN);
#endif

#if defined(UART_DEV)
gd_com_init(UART_DEV);
#endif

/* USB D+ and D- pins don't need to be configured. */
/* Configure VBUS Pin */
#ifndef USB_NO_VBUS_PIN
gpio_init(GPIOA, GPIO_MODE_IN_FLOATING, GPIO_OSPEED_50MHZ, GPIO_PIN_9);
#endif

/* This for ID line debug */
// gpio_init(GPIOA, GPIO_MODE_AF_OD, GPIO_OSPEED_50MHZ, GPIO_PIN_10);

/* Enable USB OTG clock */
usb_rcu_config();

/* Reset USB OTG peripheral */
rcu_periph_reset_enable(RCU_USBFSRST);
rcu_periph_reset_disable(RCU_USBFSRST);

/* Configure USBFS IRQ */
ECLIC_Register_IRQ(USBFS_IRQn, ECLIC_NON_VECTOR_INTERRUPT,
ECLIC_POSTIVE_EDGE_TRIGGER, 3, 0, NULL);

/* Retrieve otg core registers */
usb_gr* otg_core_regs = (usb_gr*)(USBFS_REG_BASE + USB_REG_OFFSET_CORE);

#ifdef USB_NO_VBUS_PIN
/* Disable VBUS sense*/
otg_core_regs->GCCFG |= GCCFG_VBUSIG | GCCFG_PWRON | GCCFG_VBUSBCEN;
#else
/* Enable VBUS sense via pin PA9 */
otg_core_regs->GCCFG |= GCCFG_VBUSIG | GCCFG_PWRON | GCCFG_VBUSBCEN;
otg_core_regs->GCCFG &= ~GCCFG_VBUSIG;
#endif

/* Enable interrupts globaly */
__enable_irq();
}

void gd32vf103_reset(void) {
/* The MTIMER unit of the GD32VF103 doesn't have the MSFRST
* register to generate a software reset request.
* BUT instead two undocumented registers in the debug peripheral
* that allow issueing a software reset.
* https://github.com/esmil/gd32vf103inator/blob/master/include/gd32vf103/dbg.h
*/
DBG_KEY = DBG_KEY_UNLOCK;
DBG_CMD = DBG_CMD_RESET;
}

//--------------------------------------------------------------------+
// Board porting API
//--------------------------------------------------------------------+

void board_led_write(bool state) {
state ? gd_led_on(LED_PIN) : gd_led_off(LED_PIN);
}

uint32_t board_button_read(void) {
return BUTTON_STATE_ACTIVE == gpio_input_bit_get(BUTTON_PORT, BUTTON_PIN);
}

int board_uart_read(uint8_t* buf, int len) {
#if defined(UART_DEV)
int rxsize = len;
while (rxsize--) {
*(uint8_t*)buf = usart_read(UART_DEV);
buf++;
}
return len;
#else
(void)buf;
(void)len;
return 0;
#endif
}

int board_uart_write(void const* buf, int len) {
#if defined(UART_DEV)
int txsize = len;
while (txsize--) {
usart_write(UART_DEV, *(uint8_t*)buf);
buf++;
}
return len;
#else
(void)buf;
(void)len;
return 0;
#endif
}

#if CFG_TUSB_OS == OPT_OS_NONE
volatile uint32_t system_ticks = 0;
void eclic_mtip_handler(void) {
system_ticks++;
SysTick_Reload(TIMER_TICKS);
}
uint32_t board_millis(void) { return system_ticks; }
#endif

#ifdef USE_FULL_ASSERT
/**
* @brief Reports the name of the source file and the source line number
* where the assert_param error has occurred.
* @param file: pointer to the source file name
* @param line: assert_param error line source number
* @retval None
*/
void assert_failed(char* file, uint32_t line) {
/* USER CODE BEGIN 6 */
/* User can add his own implementation to report the file name and line
number,
tex: printf("Wrong parameters value: file %s on line %d\r\n", file, line)
*/
/* USER CODE END 6 */
}
#endif /* USE_FULL_ASSERT */
68 changes: 68 additions & 0 deletions hw/bsp/gd32vf103/family.mk
Original file line number Diff line number Diff line change
@@ -0,0 +1,68 @@
# https://www.embecosm.com/resources/tool-chain-downloads/#riscv-stable
#CROSS_COMPILE ?= riscv32-unknown-elf-

# Toolchain from https://nucleisys.com/download.php
#CROSS_COMPILE ?= riscv-nuclei-elf-

# Toolchain from https://github.com/xpack-dev-tools/riscv-none-embed-gcc-xpack
CROSS_COMPILE ?= riscv-none-embed-

# Submodules
NUCLEI_SDK = hw/mcu/gd/nuclei-sdk
DEPS_SUBMODULES += $(NUCLEI_SDK)

# Nuclei-SDK paths
GD32VF103_SDK_SOC = $(NUCLEI_SDK)/SoC/gd32vf103
GD32VF103_SDK_DRIVER = $(GD32VF103_SDK_SOC)/Common/Source/Drivers
LIBC_STUBS = $(GD32VF103_SDK_SOC)/Common/Source/Stubs
STARTUP_ASM = $(GD32VF103_SDK_SOC)/Common/Source/GCC

include $(TOP)/$(BOARD_PATH)/board.mk

SKIP_NANOLIB = 1

CFLAGS += \
-march=rv32imac \
-mabi=ilp32 \
-mcmodel=medlow \
-mstrict-align \
-nostdlib -nostartfiles \
-DCFG_TUSB_MCU=OPT_MCU_GD32VF103 \
-DDOWNLOAD_MODE=DOWNLOAD_MODE_FLASHXIP \
-DGD32VF103

# mcu driver cause following warnings
CFLAGS += -Wno-error=unused-parameter

SRC_C += \
src/portable/st/synopsys/dcd_synopsys.c \
$(GD32VF103_SDK_DRIVER)/gd32vf103_rcu.c \
$(GD32VF103_SDK_DRIVER)/gd32vf103_gpio.c \
$(GD32VF103_SDK_DRIVER)/Usb/gd32vf103_usb_hw.c \
$(GD32VF103_SDK_DRIVER)/gd32vf103_usart.c \
$(LIBC_STUBS)/sbrk.c \
$(LIBC_STUBS)/close.c \
$(LIBC_STUBS)/isatty.c \
$(LIBC_STUBS)/fstat.c \
$(LIBC_STUBS)/lseek.c \
$(LIBC_STUBS)/read.c

SRC_S += \
$(STARTUP_ASM)/startup_gd32vf103.S \
$(STARTUP_ASM)/intexc_gd32vf103.S

INC += \
$(TOP)/$(BOARD_PATH) \
$(TOP)/$(NUCLEI_SDK)/NMSIS/Core/Include \
$(TOP)/$(GD32VF103_SDK_SOC)/Common/Include \
$(TOP)/$(GD32VF103_SDK_SOC)/Common/Include/Usb

# For freeRTOS port source
FREERTOS_PORT = RISC-V

# For flash-jlink target
JLINK_IF = jtag

# flash target ROM bootloader
flash: $(BUILD)/$(PROJECT).bin
dfu-util -R -a 0 --dfuse-address 0x08000000 -D $<
Loading