riscv-openocd
riscv-openocd copied to clipboard
riscv
Track and clarify differences with upstream OpenOCD
After the most recent merge #976 the difference with upstream version used looks like so (some differences are omitted):
> git checkout 1f512eac32e614e893565741f93ea3739a522797
...
> git diff d4575b647a3603200a9bb4a784d170f792ab88d0 --stat
.github/*
...
HACKING | 26 +
Makefile.am | 6 +-
configure.ac | 3 +-
contrib/loaders/flash/gd32v/gd32vf103.inc | 8 +
doc/openocd.texi | 278 +++++++++-
git-hooks/*
src/flash/nor/tcl.c | 3 +-
src/helper/Makefile.am | 2 +
src/helper/base64.c | 157 ++++++
src/helper/base64.h | 17 +
src/jtag/drivers/ftdi.c | 448 +++++++++++++++-
src/rtos/FreeRTOS.c | 763 ++++++++++++++++++++-------
src/rtos/hwthread.c | 49 +-
src/rtos/rtos.c | 266 ++++++++--
src/rtos/rtos.h | 52 +-
src/rtos/rtos_standard_stackings.c | 213 +++++++-
src/rtos/rtos_standard_stackings.h | 5 +
src/server/gdb_server.c | 176 +++++--
src/target/breakpoints.c | 213 ++++----
src/target/breakpoints.h | 2 +-
src/target/dsp563xx.c | 3 +-
src/target/riscv/*
...
src/target/target.c | 96 ++--
src/target/target.h | 12 +-
tcl/board/esp32c2-*
...
tcl/board/sifive-*
...
tcl/interface/ftdi/arty-onboard-ftdi.cfg | 7 +
tcl/interface/ftdi/digilent-hs2-cjtag.cfg | 17 +
tcl/interface/ftdi/olimex-arm-jtag-cjtag.cfg | 27 +
tcl/interface/ftdi/olimex-arm-usb-ocd-h-cjtag.cfg | 22 +
tcl/interface/ftdi/olimex-arm-usb-tiny-h-cjtag.cfg | 27 +
"tcl/target/1986\320\262\320\2651\321\202.cfg" => tcl/target/1986Be1T.cfg | 0
"tcl/target/\320\2721879x\320\2611\321\217.cfg" => tcl/target/K1879x61R.cfg | 0
tcl/target/esp*
tcl/target/gd32vf103.cfg | 105 +++-
tools/filter_openocd_log.py | 120 +++++
Some of these files seem suspicious, namely:
contrib/loaders/flash/gd32v/gd32vf103.inc
src/target/dsp563xx.c
tcl/interface/ftdi/*
tcl/target/gd32vf103.cfg
Regarding contrib/loaders/flash/gd32v/gd32vf103.inc -- it was moved and re-generated in the upstream.
> git grep gd32vf103.inc
contrib/loaders/flash/gd32vf103/Makefile:all: gd32vf103.inc
src/flash/nor/stm32f1x.c:#include "../../../contrib/loaders/flash/gd32vf103/gd32vf103.inc"
> diff contrib/loaders/flash/gd32vf103/gd32vf103.inc contrib/loaders/flash/gd32v/gd32vf103.inc
2,4c2,8
< 0x83,0x57,0x06,0x00,0x13,0x06,0x26,0x00,0x23,0x90,0xf6,0x00,0x83,0x27,0x05,0x00,
< 0x13,0xf7,0x17,0x00,0xe3,0x1c,0x07,0xfe,0x93,0xf7,0x47,0x01,0x63,0x98,0x07,0x00,
< 0x93,0x85,0xf5,0xff,0x93,0x86,0x26,0x00,0xe3,0x9c,0x05,0xfc,0x73,0x00,0x10,0x00,
---
> 0x6f,0x00,0x80,0x00,0x73,0x00,0x10,0x00,0x03,0x2b,0x06,0x00,0x63,0x0c,0x0b,0x04,
> 0x83,0x2a,0x46,0x00,0xb3,0x87,0x6a,0x41,0xe3,0x88,0x07,0xfe,0x03,0xdb,0x0a,0x00,
> 0x23,0x10,0x67,0x01,0x93,0x8a,0x2a,0x00,0x13,0x07,0x27,0x00,0x83,0x2b,0xc5,0x00,
> 0x93,0xf7,0x1b,0x00,0xe3,0x9c,0x07,0xfe,0x93,0xf7,0x4b,0x01,0x63,0x90,0x07,0x02,
> 0x63,0xe6,0xda,0x00,0x93,0x0a,0x06,0x00,0x93,0x8a,0x8a,0x00,0x23,0x22,0x56,0x01,
> 0x93,0x85,0xf5,0xff,0x63,0x88,0x05,0x00,0x6f,0xf0,0x1f,0xfb,0x13,0x05,0x00,0x00,
> 0x23,0x22,0xa6,0x00,0x13,0x85,0x0b,0x00,0x6f,0xf0,0xdf,0xf9,
The change to src/target/dsp563xx.c is made by 53ec10b61d to create riscv repeat_read
There is a significant difference in src/jtag/drivers/ftdi.c and tcl/interface/ftdi/*. Some commits are quite recent (2022). @timsifive, can you please clarify whether these changes are RISC-V specific in some way? Is it possible to start upstreaming them without upstreaming the main RISC-V-specific part?
The ftdi changes let a user debug a target using cJTAG OSCAN1 protocol. It was added in https://github.com/riscv/riscv-openocd/pull/320. I'm not sure if it's ever seen significant use.
There are significant FreeRTOS changes as well. They support 64-bit targets, and also reorganize a bunch of code so it was easier to support RISC-V with 2 different call stack conventions. This is the one that seems the hardest to upstream since you probably need to check that it still works on some non-RISC-V target before sending it upstream. I don't remember any users ever asking about RISC-V FreeRTOS so probably it's not used much.
The breakpoints changes are recent, and are causing quite a few conflicts when merging changes down. I'd prioritize upstreaming these just to reduce the work required in resolving these conflicts.
The rtos changes primarily let gdb correctly access registers from individual threads that are not the current one. This is probably important in conjunction with hwthread and multiple harts.
