Port to GD32 RISC-V (gd32vf103cbt6) Sipeed Longan Nano?

[zoobab]

Hi,

Just got a GD32 RISC-V, which is pin to pin compatible with the stm32f103.

How hard would it be to port DirtyJTAG there?

The library unicore-mx does not seem to have support for it...

[jeanthom]

Taking a look at a WIP patch for libopencm3 (https://github.com/libopencm3/libopencm3/pull/1234/files), it looks like the most significant change lies in NVIC controller, which is much different than ST's.

Does the GD32VF103 have a built-in USB DFU bootloader?

[robertlipe]

Flyby answer as I was just reading about DirtyJTAG, but I have G32V experience.

Yes, GD32VF103 has a highly integrated USB controller and often ships with a DFU boot loader. (I'll admit I've always gone straight for JTAG, which is sort of how I got here...) Certainly the Longan Nano ships with one: https://longan.sipeed.com/en/get_started/blink.html#usb-dfu-download. OK, That page is talking about PlatformIO, but that's the gateway to DFU. I think that basic recipe (fiddling with buttons) is common to most GD32V eval boards.

I'm a RISC-V guy and not an STM32 dude and never heard of NVIC, but looking at that PR it looks like tomato/tomahto interrupt controllers. The GD32V does have a mode simpler than ECLIC, which was chosen here. If you don't NEED a complicated interrupt nesting scheme CLIC and PLIC are way simpler and match more naturally to other RISC-V processors - you take an exception/interrupt, save some amount of registers, jump through the mtvec register, interrogate mtcause for exception or interrupt sources, handle them, and them mret. SiFive (yet another RISC-V vendor) has a good "Interrupt Cookbook" that explains that all very well. So if that's the part that's giving anyone pause, take the simpler route.

That patch Is bulky, but largely because it's trying really hard to provide the ST103F spellings for things, which seems a pretty reasonable goal for opencm3 as I understand it. A project starting from scratch on GD32VF103 would probably use https://github.com/Nuclei-Software/nuclei-sdk instead.

I haven't gone over it line by line, but that seems a pretty reasonable approach to me. Lots of STF103 projects move to GD32V without drama; lots of RTOSes have done exactly that.

So I'm not volunteering to do the work, but it's probably pretty straight forward and that CL (which still hasn't landed, for reasons not clear) seems like a reasonable start.

Good luck!

[jeanthom]

Hi Robert, thanks for your advice! In early January @phdussud rewrote all the code that was relying on interrupts to make things a bit quicker, so this should not be a problem anymore.

I started working on STM32F4 support (as getting genuine STM32F1 from Chinese vendors is quite complicated nowadays), which requires extensive Makefile modifications, so I guess we could use that as a starting point to allow compiling DirtyJTAG with on a radically different architecture.

Do you know if the DFU bootloader on the Sipeed dev board is stored in the flash or in ROM?

[robertlipe]

Chip supply is generally a mess in our corner of the industry right now.

If you're refactoring for similar chips, the BL602 and ESP32-C3 are also low-cost RISC-V parts that may show up in your request list. They're not clones of the STM32F103 like the GD32V is. BL602 like on Pinecone and Pinenut can be really inexpensive, but the USB implementation on it is just a CH302, which would only give you a serial protocol experience (fine for GDB) and not a USBFS one (no DFU).

I'm not on team DFU, so I have no personal knowledge of your question. Mine boot from Flash. I use Segger or sometimes FTDI2232H parts to program the flash right at the boot vector and off I go without futzing with switches as is required by DFU on these. There are mixed messages on this; the data sheets say there are three boot options: Flash, SRAM, and "System Memory", but I've never seen a reserved address space for that system memory while Flash and SRAM are definitely represented. https://github.com/esmil/gd32vf103inator makes a good case for DFU being in ROM somewhere. He went to great lengths to provide his own DFU implementation in Flash. It makes sense for it to be in permanent ROM somewhere so it's less brickable, but it's also less fixable. So I'll answer "ROM", but darned if I know where.

On Tue, Apr 27, 2021 at 2:27 PM Jean THOMAS @.***> wrote:

Hi Robert, thanks for your advice! In early January @phdussud https://github.com/phdussud rewrote all the code that was relying on interrupts to make things a bit quicker, so this should not be a problem anymore.

I started working on STM32F4 support (as getting genuine STM32F1 from Chinese vendors is quite complicated nowadays), which requires extensive Makefile modifications, so I guess we could use that as a starting point to allow compiling DirtyJTAG with on a radically different architecture.

Do you know if the DFU bootloader on the Sipeed dev board is stored in the flash or in ROM?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jeanthom/DirtyJTAG/issues/75#issuecomment-827859786, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD3YNOPYDZECMN3XM2MDTK4FZNANCNFSM4VHJY5SQ .

[robertlipe]

AHA! Here it is inside https://dl.sipeed.com/LONGAN/Nano/DOC/GD32VF103_User_Manual_EN_V1.2.pdf in section 2.3.1 we have our answer.

The flash memory consists of up to 128 KB main flash organized into 128 pages with 1 KB capacity per page and a 18 KB Information Block for the Boot Loader. [...] Normal flash is 0x0800 0000 - 0x0801 FFFF. Information Block Boot loader area 0x1FFF B000- 0x1FFF F7FF 18KB Option bytes Block Option bytes 0x1FFF F800 - 0x1FFF F80F 16B Note: The Information Block stores the boot loader. This block cannot be programmed or erased by user.

So basically, there's a write protected 18K at the end of flash that's "special" and holds the DFU boot code.

Now I've learned something about these chips, too. Thanx!

On Tue, Apr 27, 2021 at 4:03 PM Robert Lipe @.***> wrote:

Chip supply is generally a mess in our corner of the industry right now.

If you're refactoring for similar chips, the BL602 and ESP32-C3 are also low-cost RISC-V parts that may show up in your request list. They're not clones of the STM32F103 like the GD32V is. BL602 like on Pinecone and Pinenut can be really inexpensive, but the USB implementation on it is just a CH302, which would only give you a serial protocol experience (fine for GDB) and not a USBFS one (no DFU).

I'm not on team DFU, so I have no personal knowledge of your question. Mine boot from Flash. I use Segger or sometimes FTDI2232H parts to program the flash right at the boot vector and off I go without futzing with switches as is required by DFU on these. There are mixed messages on this; the data sheets say there are three boot options: Flash, SRAM, and "System Memory", but I've never seen a reserved address space for that system memory while Flash and SRAM are definitely represented. https://github.com/esmil/gd32vf103inator makes a good case for DFU being in ROM somewhere. He went to great lengths to provide his own DFU implementation in Flash. It makes sense for it to be in permanent ROM somewhere so it's less brickable, but it's also less fixable. So I'll answer "ROM", but darned if I know where.

On Tue, Apr 27, 2021 at 2:27 PM Jean THOMAS @.***> wrote:

Hi Robert, thanks for your advice! In early January @phdussud https://github.com/phdussud rewrote all the code that was relying on interrupts to make things a bit quicker, so this should not be a problem anymore.

I started working on STM32F4 support (as getting genuine STM32F1 from Chinese vendors is quite complicated nowadays), which requires extensive Makefile modifications, so I guess we could use that as a starting point to allow compiling DirtyJTAG with on a radically different architecture.

Do you know if the DFU bootloader on the Sipeed dev board is stored in the flash or in ROM?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/jeanthom/DirtyJTAG/issues/75#issuecomment-827859786, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACCSD3YNOPYDZECMN3XM2MDTK4FZNANCNFSM4VHJY5SQ .