Open en-sc opened 11 months ago
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.
After the most recent merge #976 the difference with upstream version used looks like so (some differences are omitted):
Some of these files seem suspicious, namely: