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

Merge up to commit '1293ddd65713d6551775b67169387622ada477c1' from upstream #816

Merged
merged 206 commits into from
Apr 5, 2023

Conversation

timsifive
Copy link
Collaborator

@timsifive timsifive commented Mar 17, 2023

This includes https://sourceforge.net/p/openocd/mailman/message/37710818/, which should fix #814.

No regressions against spike, HiFive Unleashed, and HiFive1.

erhankur and others added 30 commits June 10, 2022 21:56
Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I21506526e3ebd9c3a70a25ba60bf83aee431feb6
Reviewed-on: https://review.openocd.org/c/openocd/+/7016
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
There is an accsess to wrong index, when arm semihosting_basedir
command not used or basedir set to empty string.

Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I3afa049d74b30496f5c03ba4ef67431784f81bdc
Fixes: ce5027a ("semihosting: add semihosting_basedir command")
Reviewed-on: https://review.openocd.org/c/openocd/+/7005
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
While an ADIv5 DAP can only have 256 AP, ADIv6 can provide till
2**40 (1,099,511,627,776) AP per DAP.
The actual trivial code implementation for ADIv5 (that uses an
array of 256 ap in the struct adiv5_dap) cannot be extended as-is
to handle ADIv6.

The simple array of 256 AP can be reused as a dynamic storage for
ADIv6 ap:
- the ADIv5 AP number is replaced by the ADIv6 base address;
- the index of the array (equal to ADIv5 AP number) has no link to
  any ADIv6 property;
- the ADIv6 base_address has to be searched in the array of AP.

The 256 elements in the AP array should be enough for any device
available today. In future it can be easily increased, if needed.

To efficiently use the 256 elements in the AP array, the code
should associate one element of the array to an ADIv6 AP (through
the AP base address), then cancel the association when the AP is
not anymore needed. This is important to avoid saturating the AP
array while exploring the device through 'dap apreg' commands.

Add a reference counter in the struct adiv5_ap to track how many
times the struct has been associated with the same base address.
Introduce the function dap_get_ap() to associate and return the
struct, and dap_put_ap() to release the struct. For the moment the
code covers ADIv5 only, so the association is through the index.
Use the two functions above and dap_find_get_ap() throughout the
code.
Check the return value of dap_get_ap(). It is always not NULL in
the current ADIv5-only implementation, but can be NULL for ADIv6
when there are no more available AP in the array.
Instrument dap_queue_ap_read() and dap_queue_ap_write() to log an
error message if the AP has reference counter zero, meaning that
the AP has not been 'get' yet. This helps identifying AP used
without get/put, e.g. code missed by this patch, or merged later.
Instrument dap_cleanup_all() to log an error message if an AP has
reference counter not zero at openocd exit, meaning that the AP
has not been 'put' yet.

Change-Id: I98316eb42b9f3d9c9bbbb6c73b1091b53f629092
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6455
Reviewed-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Tested-by: jenkins
Add flags to 'dap create' command and set the field adi_version
in struct adiv5_dap.

Actually only ADIv5 is functional. Other patches are needed to get
ADIv6 working.

Split from change https://review.openocd.org/6077/

Change-Id: I63d3902f99a7f139c15ee4e07c19eae9ed4534b9
Signed-off-by: Kevin Burke <kevinb@os.amperecomputing.com>
Signed-off-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6456
Tested-by: jenkins
ADIv5 MEM-AP registers are a subset of ADIv6 MEM-AP registers and
are located at different offset.

To prepare for introducing ADIv6, add 'struct adiv5_dap *' as
argument to ADIv5 registers macro.
Check the ADI version and use the proper address.
Both adapter drivers rshim and stlink are ADIv5 only, so let them
use the ADIv5 macros only.

Split from change https://review.openocd.org/6077/

Change-Id: Ib861ddcdab74637b2082cc9f2612dea0007d77b1
Signed-off-by: Kevin Burke <kevinb@os.amperecomputing.com>
Signed-off-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6457
Tested-by: jenkins
Required for parsing ADIv6 ROM tables.

Split from change https://review.openocd.org/6077/

Change-Id: I849543b7b4a4455b10bd9fc7da38a37849d71700
Signed-off-by: Kevin Burke <kevinb@os.amperecomputing.com>
Signed-off-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6458
Tested-by: jenkins
By accessing invalid AP in JTAG mode, it's possible to trigger the
error:
	JTAG-DP STICKY ERROR
After that the sticky error is never cleared and the whole DAP
gets not anymore accessible.

Clean-up the sticky error once detected.

Change-Id: I8b07263b30f9e46645f0c29084b8f1626e241f45
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6430
Tested-by: jenkins
swd and dap-direct are not implemented yet

Split from change https://review.openocd.org/6077/

Change-Id: I6d73d8adf6a6090001c5d4771325fb1d63c45e3c
Signed-off-by: Kevin Burke <kevinb@os.amperecomputing.com>
Signed-off-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6459
Tested-by: jenkins
ADIv5 reports:
	Accessing AP registers or debug resources in connected
	device through an AP can be subjected to other variable
	response delays in the system. A debugger that can adapt
	to these delays and avoid wasting WAIT scans operates more
	efficiently and provides higher maximum data throughput.

The existing code in OpenOCD uses extra tck only for accessing
resources through an AP.

Extend the use of extra tck also for accessing an AP register.

Split from change https://review.openocd.org/6077/

Change-Id: I2082362e098d09f4ba0668e01f5196afc965c8f3
Signed-off-by: Kevin Burke <kevinb@os.amperecomputing.com>
Signed-off-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6460
Tested-by: jenkins
During enter in SWD read DP_DPIDR without selecting the register
bank through DP_SELECT_DPBANK.
Handle the different format of DP_SELECT register.

Change-Id: Iea1b8eb6ec94177e16a430d5885595a38e833eeb
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6697
Tested-by: jenkins
ADIv5 DAP can only have 256 AP, while ADIv6 can provide till
2**40 (1,099,511,627,776) AP per DAP.

Reuse the field ap_num in struct adiv5_ap, currently used on ADIv5
to hold the ADIv5 AP number (apsel), to contain the ADIv6 AP base
address.

Convert struct adiv5_ap->ap_num to 64 bit and initialize it to
DP_APSEL_INVALID for unused AP.
Restrict dap_find_get_ap() to ADIv5 only. To be enhanced.
On ADIv6, let dap_get_ap() return an already allocated AP, or
allocate and return an unused AP.
Add function is_ap_num_valid() and use it.

Change-Id: Ib2fe8c7ec0d08393cd91c29fdac5d632dfc1e438
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6461
Reviewed-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Tested-by: jenkins
On ADIv6 the system root ROM table is found by reading the DAP DP
registers BASEPTR0 and BASEPTR1.

Add option 'root' to the commands 'dap info' to let it retrieve
the system root ROM table's AP from DAP DP, then use such AP for
following dump.

Change-Id: I1789457a005faa3870c5d14f763378d2f6a5f095
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6462
Tested-by: jenkins
ADIv6 adds AP that only contain a ROM table in the AP itself, that
can point to other AP containing either another AP level ROM table
or a MEM-AP to be parsed as usual.

To handle recursive AP access, reorganize the code to:
- pass the depth==0 from the command 'dap info';
- print the AP number as first line, adding proper indentation on
  depth>0;
- align the following print with proper indentation.

Change-Id: I5b811810c807fc51b307bd60f67817d9de2aa095
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6466
Tested-by: jenkins
ADIv6 adds AP that only contain a ROM table in the AP itself, that
can point to other AP containing either another AP level ROM table
or a MEM-AP to be parsed as usual.

Add support for parsing AP level ROM tables.

Change-Id: Ic25863b16463b8a6adc3b15e26db7fdca858d6df
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6467
Tested-by: jenkins
Configuration file can specify, as target's debug AP, an AP that
contains a ROM table that points, in turn, to other APs.
Current code in cortex_a and aarch64 is not able to handle a
return from dap_lookup_cs_component() that points to another AP.

While it could be interesting to specify 'root' as target's debug
AP, drop any found value if it's not in the starting AP.

Change-Id: Id206e4fa7a29e9402c8e2393026817b410bbb8bd
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6826
Tested-by: jenkins
Arm "CoreSight System-on-Chip SoC-600" specification describes a
bridge "Access Port v1 adapter" aimed to "connect a legacy Access
Port (AP) ... into an CoreSight Architecture v3 system".

A ROM table can be located in the "legacy" part of the system,
on the legacy AP behind the APv1 adapter.

For the purpose of scanning the ROM tables, consider an ADIv6
SoC-600 APv1 adapter as an ADIv5 AP.

Change-Id: I97d42fb77013c1251fb68d0caa4274086bf38a70
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/6827
Tested-by: jenkins
Add Ampere Altra ("Quicksilver") and Ampere Altra Max ("Mystique")
target/board configuration files.

The target configuration file supports silicon and emulation.
The board configuration files support 1 and 2 socket platforms.

Tested on Ampere emulation and silicon

Change-Id: I036c798a50624e30ab51ccd2895b6f60c40be096
Signed-off-by: Daniel Goehring <dgoehrin@os.amperecomputing.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/5591
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Tested-by: jenkins
ESP32 is a dual core Xtensa SoC
Not full featured yet. Some of the missing functionality:
-Semihosting
-Flash breakpoints
-Flash loader
-Apptrace
-FreeRTOS

Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I76fb184aa38ab9f4e30290c038b5ff8850060750
Reviewed-on: https://review.openocd.org/c/openocd/+/6989
Tested-by: jenkins
Reviewed-by: Ian Thompson <ianst@cadence.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
ESP32-S3 is a dual core Xtensa SoC
Not full featured yet. Some of the missing functionality:
-Semihosting
-Flash breakpoints
-Flash loader
-Apptrace
-FreeRTOS

Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: I44e17088030c96a9be9809f6579a4f16dbfc5794
Reviewed-on: https://review.openocd.org/c/openocd/+/6990
Tested-by: jenkins
Reviewed-by: Ian Thompson <ianst@cadence.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: Id685408281478cec0e7e886dbedb3b8972c7b652
Reviewed-on: https://review.openocd.org/c/openocd/+/7020
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-by: Ian Thompson <ianst@cadence.com>
Custom user syscalls can be handled with target events in the TCL scripts.
This patch gives another opportunity to handle custom syscalls in the c files.
Besides that some utility functions are also exported for the custom handlers.

Signed-off-by: Erhan Kurubas <erhan.kurubas@espressif.com>
Change-Id: Ice13d527540a0de0b2a8abda912ae3dcff3834b7
Reviewed-on: https://review.openocd.org/c/openocd/+/6889
Tested-by: jenkins
Reviewed-by: Ian Thompson <ianst@cadence.com>
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
In order to facilitate debugging multiple cores, specify the coreid and
the hwthread rtos in the imx8m target configuration.

Change-Id: Ibd871517a160ceca15002fb10e27cb793f14d086
Signed-off-by: Alvin Šipraga <alsi@bang-olufsen.dk>
Reviewed-on: https://review.openocd.org/c/openocd/+/7019
Tested-by: jenkins
Reviewed-by: Antonio Borneo <borneo.antonio@gmail.com>
Commit 6c01516 ("aarch64: add support for "reset halt"")
introduces the register setting to halt at reset vector, but:
- does not consider the case 'srst_pulls_trst' that makes useless
  setting the registers as they will be erased by the pulled trst;
- does not clean sticky errors in case of 'srst_gates_jtag'.

Avoid any register initialization on 'srst_pulls_trst' and move
the cleaning of sticky errors in the common block.

Change-Id: I6f839f06f7b091e234ede31ec18096e51f017bcd
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Fixes: 6c01516 ("aarch64: add support for "reset halt"")
Reviewed-on: https://review.openocd.org/c/openocd/+/7034
Tested-by: jenkins
Reviewed-by: Christian Hoff <christian.hoff@advantest.com>
Commit 20adf85 ("linuxgpiod: add SWDIO buffer") introduces an
additional gpio for SWDIO direction, but does not release it at
driver's exit.

Release the gpio at exit.

Change-Id: If7ea31f79ffed04af585864e49bcf1f35e118bdd
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7032
Tested-by: jenkins
Reviewed-by: Steve Marple <stevemarple@googlemail.com>
We already have a helper to release the gpio.
Extend it to also release its corresponding gpio chip.

As side effect, remove comparison with NULL.

Change-Id: I47cd446edfaead662d63c3330f25a791b747e882
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7033
Tested-by: jenkins
Reviewed-by: Steve Marple <stevemarple@googlemail.com>
Commit b9526f1 ("semihosting: permit redirection of
semihosting I/O to TCP") introduces a new comparison with NULL.

Remove it.

Change-Id: Ice4333c50d16f7592f0ff86b1640217fa42e34f6
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Fixes: b9526f1 ("semihosting: permit redirection of semihosting I/O to TCP")
Reviewed-on: https://review.openocd.org/c/openocd/+/7031
Tested-by: jenkins
Change-Id: I83d2477e8bc837aeac69bd5d08fdd923fd00a37c
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7023
Tested-by: jenkins
Remove trailing '.'
While there, add newline to file's last line.

Change-Id: I3a727e406b572d051b28e17688c24627e55520c4
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7024
Tested-by: jenkins
OpenOCD project is switching to SPDX tags.
Replace the few FSF boilerplate in tcl folder.

Change-Id: I15b146eb77cc491ed7355178f684f3e76fc763b4
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7025
Tested-by: jenkins
Reviewed-by: Tarek BOCHKATI <tarek.bouchkati@gmail.com>
The SPDX tag is aimed at machine handling and it's thus expected
to be placed in the first line.

Change-Id: I3992856eeb28b333c38d010ef286e22471ede263
Signed-off-by: Antonio Borneo <borneo.antonio@gmail.com>
Reviewed-on: https://review.openocd.org/c/openocd/+/7026
Tested-by: jenkins
@TommyMurphyTM1234
Copy link
Collaborator

checkpatch fails because a bunch of the upstream code doesn't pass it. My plan is to ignore the code style check and merge this anyway. But not until someone reviews it.

Hi @timsifive - thanks for updating the upstream merge. Apologies if it's a dumb question, but what exactly needs to be reviewed? I presume not all ~ 200 commits that are part of this PR, but, rather, something more specific?

Copy link
Collaborator

@JanMatCodasip JanMatCodasip left a comment

Choose a reason for hiding this comment

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

I'd be happy to take a look but will be able to get to this only in few days (estimated: Fri/Mon). I'll leave this up to you whether you'd be willing to wait a moment prior to merging.

@timsifive
Copy link
Collaborator Author

Hi @timsifive - thanks for updating the upstream merge. Apologies if it's a dumb question, but what exactly needs to be reviewed? I presume not all ~ 200 commits that are part of this PR, but, rather, something more specific?

@TommyMurphyTM1234 This is not a dumb question. I honestly don't really know. My experience has been that when people review code, even these crazy merges, sometimes they find bugs. So I stick with the process. :-)

@JanMatCodasip I can certainly wait a few days for your review.

@TommyMurphyTM1234
Copy link
Collaborator

Hi @timsifive - since my first question above wasn't dumb after all, I'll try again. :-D

checkpatch fails because a bunch of the upstream code doesn't pass it.

Is this because upstream does not actually enforce checkpatch passing before accepting patches and (often?) accepts patches even if they fail the check?

@timsifive
Copy link
Collaborator Author

checkpatch fails because a bunch of the upstream code doesn't pass it.

Is this because upstream does not actually enforce checkpatch passing before accepting patches and (often?) accepts patches even if they fail the check?

I have never dug into why upstream code does not satisfy checkpatch. All I know is that we're getting errors that would have been obvious to anyone using the tool, in code that was not modified in this branch. This is not a new thing.

@erhankur
Copy link
Contributor

Several checkpatch rules were added just before 0.12.0-rc1 tag. Now errors coming because the new checkpatch runs against the old codes. e.g. I see a lot of xtensa related errors that were fine during the review stage.

@TommyMurphyTM1234
Copy link
Collaborator

Several checkpatch rules were added just before 0.12.0-rc1 tag. Now errors coming because the new checkpatch runs against the old codes. e.g. I see a lot of xtensa related errors that were fine during the review stage.

Thanks @erhankur - that's interesting and could explain some (or all?) of the discrepancies alright.

@erhankur
Copy link
Contributor

Instead of disabling the checkpatch for the next PRs, I'd suggest getting the commit count in the branch and running git diff against just PRs commit. Something like;

cnt=$(git rev-list --count HEAD ^origin/riscv)
git diff HEAD~${cnt} \
 filterdiff \
 -x "a/src/jtag/drivers/libjaylink/*" \
 ....

@timsifive
Copy link
Collaborator Author

timsifive commented Mar 22, 2023

Instead of disabling the checkpatch for the next PRs, I'd suggest getting the commit count in the branch and running git diff against just PRs commit. Something like;

That is better than the current fixed count of 20, but does not actually solve the problem of checkpatch failing because of existing code. (I just tried the commands manually, and checkpatch still complained about all kinds of old code.)

A few representative errors:

WARNING:EMBEDDED_FILENAME: It's generally not useful to have the filename in the file
#772: FILE: COPYING:16:
+All contributions to OpenOCD are subject to this COPYING file.
WARNING:TYPO_SPELLING: 'addres' may be misspelled - perhaps 'address'?
#8413: FILE: contrib/loaders/flash/rsl10/rom_launcher.S:24:
+    // variables are already set, addres to jump is in r3
                                   ^^^^^^
CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#39024: FILE: src/flash/nor/em357.c:712:
+       LOG_INFO("flash size = %d KiB", num_pages*page_size/1024);
CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'last >= bank->num_sectors'
#64189: FILE: src/flash/nor/stmsmi.c:319:
+       if ((last < first) || (last >= bank->num_sectors)) {

And so on...

There are 1694 of them.

@JanMatCodasip
Copy link
Collaborator

JanMatCodasip commented Apr 3, 2023

@timsifive Could you please check riscv/encodings.h and gdb_regs.h files. It seems that this merge is trying to bring in older versions from upstream, compared to what is in the riscv-openocd repository.

Edit: I take this back, this was my oversight. Both these files were changed in the trunk (riscv branch) only after this branch was forked.

@TommyMurphyTM1234
Copy link
Collaborator

That is better than the current fixed count of 20, but does not actually solve the problem of checkpatch failing because of existing code. (I just tried the commands manually, and checkpatch still complained about all kinds of old code.)

@timsifive and others - do you think it's of any use to flag the issue on the OpenOCD development mailing list or via an OpenOCD SourceForge issue and ask if there might be any willingness to align historical patches or the codebase as a whole with the latest checkpatch requirements? If there is then I am happy to raise the issue there. And maybe to help upstream if necessary.

@JanMatCodasip
Copy link
Collaborator

JanMatCodasip commented Apr 3, 2023

I have quick-reviewed this merge visually and it looks all right.

I noticed just a detail: In spi.c, the entry "micron mt25qu01" should be right before "micron mt25ql02" (not after it). This is really a little thing, but it'd be good to clean it up so that it no longer shows up in the diffs against upstream.

JanMatCodasip
JanMatCodasip previously approved these changes Apr 3, 2023
Change-Id: I7537c122d581ec1848a1e7902874506e0bbb6e31
Signed-off-by: Tim Newsome <tim@sifive.com>
@timsifive timsifive dismissed stale reviews from JanMatCodasip and GregSavin via d031d50 April 4, 2023 17:51
@timsifive
Copy link
Collaborator Author

Thanks, @JanMatCodasip. I moved the flash device entry.

@timsifive
Copy link
Collaborator Author

@timsifive and others - do you think it's of any use to flag the issue on the OpenOCD development mailing list or via an OpenOCD SourceForge issue and ask if there might be any willingness to align historical patches or the codebase as a whole with the latest checkpatch requirements? If there is then I am happy to raise the issue there. And maybe to help upstream if necessary.

This is probably an improvement, and some people there seem to really enjoy this kind of work. (Look at e.g. replacing unsigned with unsigned int everywhere.)

Copy link
Collaborator

@JanMatCodasip JanMatCodasip left a comment

Choose a reason for hiding this comment

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

I have quick-reviewed this by comparing the branch:

  • against the upstream base, and
  • again the riscv-openocd trunk (riscv branch)

The merge looks all right.

@timsifive timsifive merged commit c6ba416 into riscv Apr 5, 2023
@timsifive timsifive deleted the from_upstream branch April 5, 2023 15:47
@TommyMurphyTM1234
Copy link
Collaborator

@timsifive and others - do you think it's of any use to flag the issue on the OpenOCD development mailing list or via an OpenOCD SourceForge issue and ask if there might be any willingness to align historical patches or the codebase as a whole with the latest checkpatch requirements? If there is then I am happy to raise the issue there. And maybe to help upstream if necessary.

This is probably an improvement, and some people there seem to really enjoy this kind of work. (Look at e.g. replacing unsigned with unsigned int everywhere.)

Hi @timsifive - sorry, I don't understand your reply. Are you expressing positivity or negativitity towards what I suggested? If the former then I will raise the issue upstream if you/others think it might be of any use in making future downstream <-> upstream merges easier. But if you/others think it's of no real use then I won't bother.

@timsifive
Copy link
Collaborator Author

I was a bit on the fence about it, because I thought it would only affect things when merging down. But now it's affecting every other PR (until we get enough changes merged that this is far in history again). So yes, this would be helpful.

@TommyMurphyTM1234
Copy link
Collaborator

I was a bit on the fence about it, because I thought it would only affect things when merging down. But now it's affecting every other PR (until we get enough changes merged that this is far in history again). So yes, this would be helpful.

Thanks @timsifive - ok, I will raise the issue upstream via a SourceForge issue or on the openocd-devel mailing list to see what others there think. I wouldn't expect any quick action given that obvious rebuttals are (a) it could cause instability by changing lots of historical patches and already committed code and (b) why are you doing development in a fork and not upstream in the master project. But let's see what happens....

@TommyMurphyTM1234
Copy link
Collaborator

I was a bit on the fence about it, because I thought it would only affect things when merging down. But now it's affecting every other PR (until we get enough changes merged that this is far in history again). So yes, this would be helpful.

Thanks @timsifive - ok, I will raise the issue upstream via a SourceForge issue or on the openocd-devel mailing list to see what others there think. I wouldn't expect any quick action given that obvious rebuttals are (a) it could cause instability by changing lots of historical patches and already committed code and (b) why are you doing development in a fork and not upstream in the master project. But let's see what happens....

I've posted here about this so let's see what people have to say about it.

@TommyMurphyTM1234
Copy link
Collaborator

TommyMurphyTM1234 commented Apr 7, 2023

I was a bit on the fence about it, because I thought it would only affect things when merging down. But now it's affecting every other PR (until we get enough changes merged that this is far in history again). So yes, this would be helpful.

Thanks @timsifive - ok, I will raise the issue upstream via a SourceForge issue or on the openocd-devel mailing list to see what others there think. I wouldn't expect any quick action given that obvious rebuttals are (a) it could cause instability by changing lots of historical patches and already committed code and (b) why are you doing development in a fork and not upstream in the master project. But let's see what happens....

I've posted here about this so let's see what people have to say about it.

Hi @timsifive

As mentioned by @AntonioBorneo here:

would adding (via some script/automation?) Checkpatch-ignore: ... (not sure if a wildcard can be used for "all checks"?) to the commit comments for patches pulled from upstream be a workable option or has that been tried before and found to be problematic?

timsifive pushed a commit that referenced this pull request Jun 14, 2023
* rtos/FreeRTOS: pxCurrentTCB should be used for judgment.

The current TCB is stored in pxCurrentTCB, which is somehow RISC-V-specific, should not be overwritten from upstream (#816).

* fix the code style check.

Signed-off-by: Chao Du <duchao@eswincomputing.com>
Change-Id: I9ffa8947f0cb9e93c7d96866882a5a1e8e69afad

* revert some over-changes in last commit.

Change-Id: Ie88bd75b59190503db11ee4538281bd13b554e50
Signed-off-by: Chao Du <duchao@eswincomputing.com>

---------

Signed-off-by: Chao Du <duchao@eswincomputing.com>
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.

OPENOCD command: read_memory $address 64 $count, displaying 32-bit values with count=1