From gniibe at fsij.org Tue Nov 12 07:09:18 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Tue, 12 Nov 2019 15:09:18 +0900 Subject: GD32VF103 In-Reply-To: <87blu1jh36.fsf@jumper.gniibe.org> References: <87blu1jh36.fsf@jumper.gniibe.org> Message-ID: <87mud1bp81.fsf@iwagami.gniibe.org> Hello, RISC-V MCU port of Chopstx starts working somehow. See "riscv" branch of Chopstx. The target MCU is GD32VF103, which uses "Bumblebee" core (with RISC-V 32bit IMAC instruction set and ECLIC module (Enhanced Core-Local Interrupt Controller)). Only it works for Longan nano with example-led. Niibe Yutaka wrote: > I got a board with GD32VF103 (named Longan Nano), which has a 32-bit > RISC-V core and GD's peripherals. Please note that while GD32F103 is > STM32F103 clone-like with ARM Cortex-M3 core, GD32VF103 comes with RV32 > IMAC core. [...] > When it is configured by BOOT0/BOOT1 pins, it can be seen as USB DFU > board. I accessed it by dfu-util. I realized that dfu-util needs GD32VF103 specific change. Now, I use this one: https://github.com/riscv-mcu/gd32-dfu-utils I wasted two days with normal dfu-util, which resulted wrong flash content here and there. I wanted to use OpenOCD for the development, but it seems it's not yet mature for the target. I am looking at: https://github.com/riscv-mcu/riscv-openocd Someday, hopefully in near future, we will be able to use OpenOCD. For the core, I read the documents available at: https://github.com/nucleisys/Bumblebee_Core_Doc I think that the documentation is young yet. For example, I was not able to find the address of its TIMER module and ECLIC module. The MCU starts from the address 0x00000000, which is the alias of 0x08000000 flash memory. When we use the standard ABI of position independent code, assuming start address of 0x08000000, access to RAM at 0x20000000 by PC relative addressing mode fails, because the PC is actually, around 0x00000000. At the start up, we need to jump to the 0x08000000 world. For those information, I dug it out from the code at: https://github.com/riscv-mcu/GD32VF103_Firmware_Library For MCU, interrupt controller is important. I tried not to use ECLIC specific features, but only use CLIC feature-set. For CLIC, I read the document, which is available at: https://github.com/riscv/riscv-fast-interrupt/blob/master/clic.adoc It seems that interrupt controller(s) is not yet standardized in the RISC-V world. It runs at 96MHz, just like GD32F103, when we want to use its USB module. Bumblebee core supports M and U mode (Machine mode and User mode). In Chopstx, I don't put any assumption for mode of applications, so, Chopstx application can run at U-mode. But, it seems for me that U-mode is not that useful for MCU with no MPU. -- From gniibe at fsij.org Wed Nov 20 04:23:48 2019 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 20 Nov 2019 12:23:48 +0900 Subject: Chopstx 1.17 Message-ID: <871ru32ptn.fsf@iwagami.gniibe.org> Hello, Chopstx 1.17 is released. tag release/1.17 Tagger: NIIBE Yutaka Date: Wed Nov 20 11:38:03 2019 +0900 commit 0e5994506aa46d39d232389b0652fafc48feec36 It has fixes for USB drivers. Thanks to Jeremy Drake to find the bug. Other changes are basically from RISC-V port. Rename of functions, and introduce chx_running function, not assuming global variable running. The implementation chopstx.c now requires ticks_to_usec function (it should have been so). I created a branch, STABLE-BRANCH-1, to maintain stable versions from now on. In the riscv branch, I introduced major internal change (of chx_idle). I realized that Cortex-M3/M4 requires major update to keep up the change. I will call it version 2.0, when finished. --