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

Add support for GD32VF103 flash #518

Merged
merged 3 commits into from Sep 7, 2020
Merged

Add support for GD32VF103 flash #518

merged 3 commits into from Sep 7, 2020

Conversation

ZL2WRW
Copy link
Contributor

@ZL2WRW ZL2WRW commented Aug 29, 2020

Backport of GD32VF103 flash driver from https://github.com/riscv-mcu/riscv-openocd (GPL2 licensed)

This adds support for reading / erasing / writing FLASH in GigaDevices GD32VF-series RISC-V microcontrollers.
Tested with a "Longan Nano" GD32VF103 dev board, and seems to be working (flash can be read, erased and written).

ZL2WRW added 2 commits Aug 29, 2020
…riscv-openocd (GPL2 licensed)

Tested with a "Longan Nano" GD32VF103 dev board and seems to be working (flash can be read, erased and written).
@ZL2WRW
Copy link
Contributor Author

ZL2WRW commented Aug 29, 2020

I have fixed the code style errors in my pull request, however, Travis CI is still unhappy with "src/target/riscv/encoding.h" which appears to be an auto-generated file:
/*

Travis is balking at lines 52 & 53 of src/target/riscv/encoding.h
51 #define SSTATUS_VS_MASK (SSTATUS_SIE | SSTATUS_SPIE |
52 SSTATUS_SPP | SSTATUS_SUM |
53 SSTATUS_MXR | SSTATUS_UXL)

with the errors "ERROR: code indent should use tabs where possible" and "WARNING: please, no spaces at the start of a line".

I am a bit lost - do you have any idea what I have to do to fix this?

@ZL2WRW
Copy link
Contributor Author

ZL2WRW commented Aug 29, 2020

Starting with a fresh clone of mainline riscv-openocd;
git clone https://github.com/riscv/riscv-openocd
cd riscv-openocd
./bootstrap
./configure
make
("git describe" returns v20180629-1237-g91dc0c0c8)

Then I opened "src/target/riscv/encoding.h" and lines 52 & 53 seem to still have the same problem with spaces instead of tabs as when this project is built with my pull request changes.

Copy link
Collaborator

@timsifive timsifive left a comment

This looks OK to me, but I'm not really an expert on flash devices. Once this goes in here, can you do the work to upstream it into mainline OpenOCD?

@@ -0,0 +1,8 @@
/* Autogenerated with ../../../../src/helper/bin2char.sh */
Copy link
Collaborator

@timsifive timsifive Sep 2, 2020

Choose a reason for hiding this comment

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

Copy link
Contributor Author

@ZL2WRW ZL2WRW Sep 3, 2020

Choose a reason for hiding this comment

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

Yes, I think that I can upstream this into mainline OpenOCD.

I don't have the source for contrib/loaders/flash/gd32v/gd32vf103.inc as it isn't in the repository https://github.com/riscv-mcu/riscv-openocd/

../../../../src/helper/bin2char.sh simply converts a given binary file to a series of C constants.

I see two approaches that I can try:

  1. I can try to contact Kongou Hikari, the committer of contrib/loaders/flash/gd32v/gd32vf103.inc in https://github.com/riscv-mcu/riscv-openocd/ and ask for a copy of the source
  2. I can refactor contrib/loaders/flash/gd32v/gd32vf103.inc to RISC-V assembly code, that can be assembled to produce a binary file, that can then be converted with the bin2char.sh tool into an identical contrib/loaders/flash/gd32v/gd32vf103.inc

Copy link
Contributor Author

@ZL2WRW ZL2WRW Sep 3, 2020

Choose a reason for hiding this comment

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

I have managed to make contact with Kongou Hikari from nucleisys.com;

This port is done by GigaDevice, I haven't the actual source code, too. But it is basically small modification based on STM32 flash controller driver.

Since I'm very busy now so I haven't so much time to rebase this fork to upstream, when these projects finished, I will try to make some effort on it.

I will ask GigaDevice for source code, but I don't know whether or not they provide it to me.

Copy link
Collaborator

@timsifive timsifive Sep 4, 2020

Choose a reason for hiding this comment

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

If the original source is hard to dig up, I'm OK merging this as-is. It would be much better to add that source at some point, in case there is ever an issue that needs to be debugged.

Copy link
Collaborator

@timsifive timsifive left a comment

I'll merge this Monday, unless there are more comments.

@@ -0,0 +1,8 @@
/* Autogenerated with ../../../../src/helper/bin2char.sh */
Copy link
Collaborator

@timsifive timsifive Sep 4, 2020

Choose a reason for hiding this comment

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

If the original source is hard to dig up, I'm OK merging this as-is. It would be much better to add that source at some point, in case there is ever an issue that needs to be debugged.

@timsifive timsifive merged commit 48e40f3 into riscv:riscv Sep 7, 2020
1 check passed
@protobits
Copy link

protobits commented Sep 8, 2020

Hi, I'm looking forward to using openocd to flash my Longan Nano board with the Sipeed JTAG debugger. I initially tried mainline openocd (which has the gd32vf103.cfg target) adding the interface definition cfg I got from sipeed downloads. However, I cannot flash. I then found this fork and saw that flash support was just added. I then cloned this repo, added both .cfg files but I got the same error (and a bunch of extra ones). Also, "flash banks" returns empty.
How can I go about flashing this MCU?

@ZL2WRW
Copy link
Contributor Author

ZL2WRW commented Sep 9, 2020

I have created a gist which might help you v01d - it contains an lsusb dump of my Sipeed JTAG adapator so that you can check that your hardware is the same as mine, and a copy of the OpenOCD config file that I use (admittedly it is probably a sub-optimal configuration, but it seems to work): https://gist.github.com/ZL2WRW/64728aaed55ee4aed574cc24d0d2942d

OpenOCD needs to be able to access your USB JTAG device, you can either edit permissions for the device or run riscv-openocd as root eg
$ sudo riscv-openocd -f openocd_ft2232.cfg

Then from another window telnet to port 4444 on your own computer eg
$ telnet localhost 4444

I can then erase my GD32VF103 with the following OpenOCD command:
> flash erase_sector 0 0 127
erased sectors 0 through 127 on flash bank 0 in 0.363109s

and after confirming that it is erased,
> flash erase_check 0
device id = 0x19060410
flash_size_in_kb = 0x00000080
flash size = 128kbytes
Running slow fallback erase check - add working memory
successfully checked erase state

I can program the flash:
> flash write_image longan_nano-OEM.bin 0x08000000
wrote 131072 bytes from file longan_nano-OEM.bin in 9.184813s (13.936 KiB/s)

then issue reset & resume commands to execute this code.

PS: the TTL-serial port of the Sipeed JTAG adaptor (its RXD and TXD pins) shows up as /dev/ttyUSB1 on my Linux computer and can be used for serial comms if you connect these pins to a UART on the target.

@protobits
Copy link

protobits commented Sep 9, 2020

Thanks, I eventually managed to make it work. There's an issue with this chip though since it does not support reset command over JTAG. I managed to configure openocd to make the sipeed debugger assert the reset pin so that the chip is reset from its RST pin.
However, debugging is flaky, it does not seem to respond well to breakpoints.

@ZL2WRW
Copy link
Contributor Author

ZL2WRW commented Sep 13, 2020

I can set hardware breakpoints with the following command;
> bp 0x08003ca2 1 hw
[0] Found 4 triggers
breakpoint set at 0x08003ca2

and when I > resume execution of the code, the processor halts when PC hits the breakpoint, However, you can't single step past the breakpoint (it doesn't work), you have to remove the breakpoint before you can single step out of where the breakpoint was.

@protobits
Copy link

protobits commented Sep 13, 2020

Ah, that must be it. I didn't found a pattern so I assumed it was not working right. I also set the breakpoint early in the boot (like in FLASH entry point) and it didn't stop there. I had to put it much further ahead in the execution.
Is this something to fix in openocd or is this a hardware issue?

@timsifive
Copy link
Collaborator

timsifive commented Jan 5, 2022

This code is not accepted upstream (see https://review.openocd.org/c/openocd/+/6763). There's an alternate proposal, upstream, that will be accepted (https://review.openocd.org/c/openocd/+/6704) if somebody can test it. If you're relying on this code, please test the code change upstream. I'm planning to remove this from this OpenOCD fork in my efforts to resolve differences between upstream and this fork.

XuHg-zjcn pushed a commit to XuHg-zjcn/openocd-wchlink that referenced this pull request Jul 9, 2022
* Backport of GD32VF103 flash driver from
  https://github.com/riscv-mcu/riscv-openocd (GPL2 licensed).
* Tested with a "Longan Nano" GD32VF103 dev board and seems to be
  working (flash can be read, erased and written).
* Modify src/flash/nor/gd32vf103.c to comply with Travis CI code style requirements.
* Modified README to include GD32VF103 in list of supported flash devices.

Contributed into riscv-openocd in
riscv/riscv-openocd#518, then edited a few times
to build with newer OpenOCD source (mostly changing `int` to `unsigned
int`).

Signed-off-by: Tim Newsome <tim@sifive.com>
Change-Id: Ibec4a59d1ef47febe90e5924b49c39aa45a7dfa6
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants