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

Track and clarify differences with upstream OpenOCD #979

Open
en-sc opened this issue Dec 14, 2023 · 4 comments
Open

Track and clarify differences with upstream OpenOCD #979

en-sc opened this issue Dec 14, 2023 · 4 comments
Assignees

Comments

@en-sc
Copy link
Collaborator

en-sc commented Dec 14, 2023

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 
@en-sc en-sc self-assigned this Dec 14, 2023
@en-sc
Copy link
Collaborator Author

en-sc commented Dec 14, 2023

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,

@en-sc
Copy link
Collaborator Author

en-sc commented Dec 14, 2023

The change to src/target/dsp563xx.c is made by 53ec10b to create riscv repeat_read

@en-sc
Copy link
Collaborator Author

en-sc commented Dec 14, 2023

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?

@timsifive
Copy link
Collaborator

timsifive commented Dec 14, 2023

The ftdi changes let a user debug a target using cJTAG OSCAN1 protocol. It was added in #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.

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

No branches or pull requests

2 participants