Re: OpenID and gerrit login (Re: submodule jimtcl failure)
On Sat, Jun 22, 2024 at 04:33:42PM +0200, k...@aspodata.se wrote: > I'm perfectly fine with perl, but cloning it didn't work. Try this, it works with .git appended: GIT_SSL_NO_VERIFY=1 git clone \ https://gitorious.org/openidserver-sqlite/openidserver-sqlite.git -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: OpenID and gerrit login (Re: submodule jimtcl failure)
Hi Karl, On Fri, Jun 21, 2024 at 02:57:44PM +0200, k...@aspodata.se wrote: > > But as you are an active user of OpenOCD, it would be nice if you give > > another try to install an openid for any further contribution or to review > > the patches in gerrit. > > Which version of OpenID do you use ? I use https://gitorious.org/openidserver-sqlite/openidserver-sqlite > I use lighttp at aspodata.se just to display files (like a ftp server), > can someone recommend a self-hosting solution for it ? When I wanted to self-host I looked around and found just one implementation that wasn't PHP-based or had any other major dependencies. So if you're OK with Perl and probably installing few modules from CPAN then this can work for you. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: style error when submitting GERRIT request 8287: src/flash/nor/spi.c: add XIAO RP support
Hi Jan,
Thank you for submitting the patch!
On Sun, May 19, 2024 at 05:32:18PM +0200, Jan Cumps wrote:
> ERROR:SPACING: space required after that ',' (ctx:VxV)
> #23: FILE: src/flash/nor/spi.c:187:
> + FLASH_ID("pu p32q32", 0x03, 0xeb, 0x02, 0xd8, 0xc7, 0x00156085,
> 0x100, 0x1, 0x400),
>
> I used the same formatting rules and spaces a s the other lines in
> that source file:
I'm afraid not exactly, see:
03f0 2c 20 30 78 31 30 30 30 30 2c c2 a0 30 78 34 30 |, 0x1,..0x40|
That c2 a0 there...
> This is my first patch attempt. Do I have to change the code?
Yes, please, you need to git commit --amend the patch locally (keep
old Change-Id in the commit message), then check it locally with
included checkpatch and then push to Gerrit again.
HTH
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
Re: Problem trying to upload code to a ch32v003 board using the arduino IDE
Hi Mike, On Sun, Mar 10, 2024 at 06:58:15PM +, Mike How wrote: > Error: libusb_open() failed with LIBUSB_ERROR_ACCESS > Error: open failed It means what it says. Your user has no rights to talk to the USB device which you're using as adapter. Probably it's not added to the udev rules or probably you're not a local user and do not belong to plugdev group or something like that, feel free to send a patch if there's really some omission rather than permissions mis-configuration on your system. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: APM32F0 support
Hi, I didn't remember anything about that but https://review.openocd.org/q/message:geehy gives some hints. On Sun, Oct 15, 2023 at 11:24:01AM +0200, kristof.mul...@telenet.be wrote: > > What happens if you use stm32f0x.cfg config? > Error: Cannot identify target as a stm32x Apparently with https://review.openocd.org/c/openocd/+/7110 applied you can just use stm23f1x.cfg (f1!) config with apm32f0 (with appropriate CPUTAPID), I suggest you give it a try. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: APM32F0 support
On Sun, Oct 15, 2023 at 11:24:01AM +0200, kristof.mul...@telenet.be wrote: > Hi Paul and Liviu, > > What happens if you use stm32f0x.cfg config? > Then I get the following problem: > ** Programming Started ** > Error: Cannot identify target as a stm32x OK, so the flash driver isn't compatible. One would need to check the datasheet and see what really differs there. > > I have experience with APM32F103CBT6, it works fine with the existing > > script, just needs an ID for a newer Cortex-M variant to be set, can > > be done without modifying the stm32f1x.cfg at all, just by setting the > > variable beforehand. > > Great! But where can I find the ID for the MCU? How do I change it in > the config file? When ID is mismatched OpenOCD reports it in message. You do not need to change it in the config file though, just doing -c "set CPUTAPID 0x2ba01477" -f target/stm32f1x.cfg is enough to get APM32F103 working with OpenOCD. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Support for Geehy APM32F0 series
On Sun, Oct 15, 2023 at 10:25:12AM +0300, Liviu Ionescu wrote: > > On Sat, Oct 14, 2023 at 07:27:17PM +0200, kristof.mul...@telenet.be wrote: > >> 7th minute in the video. However, when I try this, I get the following > >> error: > >> embedded:startup.tcl:28: Error: Can't find target/apm32f0xx.cfg > >> I checked the OpenOCD installation - I cannot find an 'apm32f0xx.cfg' > >> target > >> file anywhere. That means the Geehy APM32F0 is not supported? But why does > >> the > >> video show otherwise? > > > > What happens if you use stm32f0.cfg config? > > I have no experience with APM32F0, but I had support requests > related to some other Chinese STM clones not being recognised by > existing STM scripts, and (unsurprisingly) it turned out that they > use their own device ids; in some cases the solution was to > copy/paste the script and update the id. I have experience with APM32F103CBT6, it works fine with the existing script, just needs an ID for a newer Cortex-M variant to be set, can be done without modifying the stm32f1x.cfg at all, just by setting the variable beforehand. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Support for Geehy APM32F0 series
Hello, On Sat, Oct 14, 2023 at 07:27:17PM +0200, kristof.mul...@telenet.be wrote: > 7th minute in the video. However, when I try this, I get the following error: > embedded:startup.tcl:28: Error: Can't find target/apm32f0xx.cfg > I checked the OpenOCD installation - I cannot find an 'apm32f0xx.cfg' target > file anywhere. That means the Geehy APM32F0 is not supported? But why does the > video show otherwise? What happens if you use stm32f0.cfg config? We can discuss it in IRC if you feel like it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Olimex ARM-USB-OCD-H Driver Issue
On Fri, Jul 14, 2023 at 11:27:43AM -0400, Abe Lapped wrote: > Here is a shot of my pinout, if it helps: > [1]image.png Have you tried measuring the voltage on pin 1 of the connector? It should be Vcc from the target. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Olimex ARM-USB-OCD-H Driver Issue
On Thu, Jul 13, 2023 at 06:16:13PM +, Dietmar May wrote: > I’ve used zadig for ARM-USB-OCD-H. (At least for *that* probe), do > NOT install for BOTH interface 0 and 1 - ONLY device 0. Interface 1 > is a standard FTDI comm port, which can be installed using drivers > from FTDI’s website. You would need to specify the driver > manually. Use the last option in the list. However, interface 1 is > not needed for JTAG debugging. But that also might depend on windows version. Which one were you testing that on? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Olimex ARM-USB-OCD-H Driver Issue
Hi, On Thu, Jul 13, 2023 at 01:46:04PM -0400, Abe Lapped wrote: > I have recently purchased an Olimex ARM-USB-OCD-U debugger but am > experiencing a > driver issue. I used Zadig to install WinUSB (v6.1.7600.16385) drivers for > ARM-USB-OCD-H (both interfaces 0 and 1). I think README.Windows says you need to install WinUSB for the composite device parent. > [1]https://imgur.com/a/Rjl58i3 > [2]https://imgur.com/a/eb11sSZ > After restarting my computer (Windows 10 Enterprise - x64), and connecting the > ARM-USB-OCD-H (USB-C <-> USB-C), the yellow light turns solid, and it appears > as > a USB device: > [3]https://imgur.com/a/BPue8wJ > Using the precompiled OpenOCD 0.9.0 found here: Please use current version of OpenOCD, not something from year 2015. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #394 jtag drscan : unhelpful error
Hi, > Discovering the syntax to use 'jtag drscan' is not super intuitive : > > > jtag drscan > wrong # args: should be "jtag drscan wrong arguments" I hope https://review.openocd.org/c/openocd/+/7652 and https://review.openocd.org/c/openocd/+/7653 help. --- ** [tickets:#394] jtag drscan : unhelpful error** **Status:** new **Milestone:** 0.11.0 **Created:** Fri Apr 28, 2023 09:05 PM UTC by fenugrec **Last Updated:** Fri Apr 28, 2023 09:05 PM UTC **Owner:** nobody Discovering the syntax to use 'jtag drscan' is not super intuitive : ~~~ > jtag drscan wrong # args: should be "jtag drscan wrong arguments" ~~~ Compare to another command : ~~~ > jtag configure wrong # args: should be " ..." ~~~ The source code mostly clarified what was expected, but IMO room for improvement. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #395 segfault: jtag drscan 32 1
On Fri, Apr 28, 2023 at 09:07:14PM -, fenugrec wrote: > > jtag drscan auto0.tap 32 1 > Connection closed by foreign host. > *** > openocd: src/jtag/drivers/driver.c:166: interface_jtag_add_dr_scan: Assertion > `field == out_fields + scan->num_fields' failed. > Aborted (core dumped) Should be handled by https://review.openocd.org/c/openocd/+/7654 --- ** [tickets:#395] segfault: jtag drscan 32 1** **Status:** new **Milestone:** 0.11.0 **Created:** Fri Apr 28, 2023 09:07 PM UTC by fenugrec **Last Updated:** Fri Apr 28, 2023 09:07 PM UTC **Owner:** nobody On latest master (91bd43134) : ~~~ > jtag drscan auto0.tap 32 1 Connection closed by foreign host. *** openocd: src/jtag/drivers/driver.c:166: interface_jtag_add_dr_scan: Assertion `field == out_fields + scan->num_fields' failed. Aborted (core dumped) ~~~ --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #395 segfault: jtag drscan 32 1
Hi, > > jtag drscan auto0.tap 32 1 > Connection closed by foreign host. > *** > openocd: src/jtag/drivers/driver.c:166: interface_jtag_add_dr_scan: Assertion > `field == out_fields + scan->num_fields' failed. This happens because basically all taps are in BYPASS by default, and before manual "drscan" command you naturally need to do the appropriate "irscan" on the same tap (as all DR operations are current instruction-specific). Guess we should introduce a special error message for the case. --- ** [tickets:#395] segfault: jtag drscan 32 1** **Status:** new **Milestone:** 0.11.0 **Created:** Fri Apr 28, 2023 09:07 PM UTC by fenugrec **Last Updated:** Fri Apr 28, 2023 09:07 PM UTC **Owner:** nobody On latest master (91bd43134) : ~~~ > jtag drscan auto0.tap 32 1 Connection closed by foreign host. *** openocd: src/jtag/drivers/driver.c:166: interface_jtag_add_dr_scan: Assertion `field == out_fields + scan->num_fields' failed. Aborted (core dumped) ~~~ --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #392 Regression in OpenOCD 0.11.0 and 0.12.0
On Thu, Apr 20, 2023 at 02:14:24PM -, Kristof Mulier wrote:
> (Paul Fertser) Have you tried using stlink-dap.cfg instead?
>
> Yes, we tried that today as well. No effect.
Can you please add -d3 log with stlink-dap attempt?
Another idea is to try using "reset halt; flash write_image erase ..."
instead to see if it might be higher frequency or something else in
the reset-init handler that makes the difference.
Another thing to try would be using an external swd adapter.
---
** [tickets:#392] Regression in OpenOCD 0.11.0 and 0.12.0**
**Status:** new
**Milestone:** 0.11.0
**Created:** Mon Apr 17, 2023 11:47 AM UTC by Kristof Mulier
**Last Updated:** Thu Apr 20, 2023 02:14 PM UTC
**Owner:** nobody
We discovered a regression in `OpenOCD 0.11.0` and `0.12.0`. Some `.elf` files
can be flashed with `OpenOCD 0.10.0` while versions `0.11.0` and `0.12.0` are
unable to flash the same `.elf` file.
Below I'll explain everything you need to know, to reproduce the problem.
---
# 1. System and OpenOCD builds
I'm working on a Windows 11 laptop. The OpenOCDs I'm using are all downloaded
from Liviu Ionescu's xPack project:
https://github.com/xpack-dev-tools/openocd-xpack/releases
When I refer to `OpenOCD 0.10.0`, `0.11.0` and `0.12.0`, I actualy mean this:
- **`OpenOCD 0.10.0`**
Downloaded as: `xpack-openocd-0.10.0-15-win32-x64.zip`
The `--version` output is:
```
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020-10-13-17:29)
```
- **`OpenOCD 0.11.0`**
Downloaded as: `xpack-openocd-0.11.0-5-win32-x64.zip`
The `--version` output is:
```
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-09-01-17:58)
```
- **`OpenOCD 0.12.0`**
Downloaded as: `xpack-openocd-0.12.0-1-win32-x64.zip`
The `--version` output is:
```
xPack Open On-Chip Debugger 0.12.0-01004-g9ea7f3d64-dirty (2023-01-30-15:04)
```
---
# 2. Demonstration of the problem
The target board is a `NUCLEO-F303K8`, which has a `STM32F303K8` chip onboard:
We have prepared two projects for this demonstration:
- **`f303-working`**: This project works with all the OpenOCD versions - up
to and including `OpenOCD 0.12.0`
- **`f303-failing`**: This project works with `OpenOCD 0.10.0`, but not with
`OpenOCD 0.11.0` and `0.12.0`.
Both projects are https://embeetle.com;>Embeetle projects.
However, I'll explain here how to flash the project's binaries without Embeetle
involved.
- **f303-working**
For the **f303-working** project, just download the `.elf` file from this
source: https://new.embeetle/downloads/misc/openocd_problem/f303-working.elf
Next, you need the `openocd_probe.cfg` and `openocd_chip.cfg` files.
They're very simple:
> ```sh
> # openocd_probe.cfg
> source [find interface/stlink.cfg]
> transport select hla_swd
> ```
> ```sh
> # openocd_chip.cfg
> source [find target/stm32f3x.cfg]
> reset_config srst_only
> ```
Put the `f303-working.elf`, `openocd_probe.cfg` and `openocd_chip.cfg`
files all in the same folder. Then issue the following command:
```sh
$ openocd -f openocd_probe.cfg -f openocd_chip.cfg -c "program
{f303-working.elf} verify reset; shutdown;"
```
As you will notice, this `f303-working.elf` firmware can be flashed with
both `OpenOCD 0.10.0`, `0.11.0` and `0.12.0`. The output is:
> ```sh
> xPack Open On-Chip Debugger 0.12.0-01004-g9ea7f3d64-dirty
(2023-01-30-15:04)
> Licensed under GNU GPL v2
> For bug reports, read
> http://openocd.org/doc/doxygen/bugs.html
> hla_swd
> Info : The selected transport took over low-level target control. The
results might differ compared to plain JTAG/SWD
> srst_only separate srst_nogate srst_open_drain connect_deassert_srst
>
> Info : clock speed 1000 kHz
> Info : STLINK V2J25M14 (API v2) VID:PID 0483:374B
> Info : Target voltage: 3.249572
> Info : [stm32f3x.cpu] Cortex-M4 r0p1 processor detected
> Info : [stm32f3x.cpu] target has 6 breakpoints, 4 watchpoints
> Info : starting gdb server for stm32f3x.cpu on
> Info : Listening on port for gdb connections
> [stm32f3x.cpu] halted due to breakpoint, current mode: Thread
> xPSR: 0x6100 pc: 0x203a msp: 0xfffc
> Info : Unable to match requested speed 1000 kHz, using 950 kHz
> Info : Unable to match requested speed 1000 kHz, using 950 kHz
> [stm32f3x.cpu] halted due to debug-request, current mode: Thread
> xPSR: 0x0100 pc: 0xfffe msp: 0xfffc
> Info : Unable to match requested speed 8000 kHz, using 4000 kHz
> Info : Unable to match requested speed 8000 kHz, using 4000 kHz
> ** Programming Started **
> Info : device id = 0x10016438
> Info
Re: OpenOCD 0.12.0 regression
Hello Kristof, On Wed, Apr 12, 2023 at 02:06:10PM +0200, kristof.mul...@telenet.be wrote: > I want to report a regression in OpenOCD. OpenOCD 0.12.0 is unable to flash a > certain .elf file to my NUCLEO-F303K8 board ... > Info : 125 188 stlink_usb.c:1434 stlink_usb_version(): STLINK V2J25M14 (API > v2) VID:PID 0483:374B ... > Debug: 561 1333 target.c:2410 target_write_buffer(): writing buffer of 12692 > byte at 0x2044 > Debug: 562 1335 hla_target.c:616 adapter_write_memory(): adapter_write_memory > 0x2044 4 3173 > Debug: 563 1417 stlink_usb.c:1100 stlink_usb_error_check(): > STLINK_SWD_AP_FAULT I suspect a bug in this version of STLINK firmware (as it's not like the failing operation is writing to the wrong place or the wrong size, the target has enough RAM). Have you tried upgrading it to the latest? Have you tried using stlink-dap.cfg instead? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Gerrit migration planned today, on 19th April Wed
On Wed, Apr 19, 2023 at 09:54:39AM +0300, Paul Fertser wrote: > The downtime should be minimal either way. Will send a notice when > it's all finished. Seems to be running 3.7.2 nicely so far. Please complain if anything is not to your liking. I tried to forward-port the custom change to avoid needless page refreshes and to continue showing conflicts for all changes, even those unmergeable. Not sure if that worked fine yet, needs more testing. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Gerrit migration planned today, on 19th April Wed
Hi, I plan to attempt migrating to the latest Gerrit version later today hoping that it might solve the issue with occassional time outs. The downtime should be minimal either way. Will send a notice when it's all finished. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: OpenOCD 0.12.0 regression
Hi! On Mon, Apr 17, 2023 at 02:00:03PM +0200, kristof.mul...@telenet.be wrote: > > The release pages mention the commit id used, you can try to take > > a look at the changes in the given period, perhaps you can > > identify something related to your problem. > > I'm afraid that's beyond my capabilities. I don't have any knowledge > of the OpenOCD source code. I'd simply get lost. git bisect start; git bisect bad v0.11.0; git bisect good v0.10.0 https://www.git-tower.com/learn/git/faq/git-bisect/ and you can pin-point the offending commit pretty fast since you have an easy way to reproduce it, without any knowledge of the code base at all. I do not have Nucleo F3 board with me :( -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #386 OpenOCD can't connect to Dialog DA1469x
Hi, On Wed, Mar 15, 2023 at 02:30:07PM -, Maximilian Gerhardt wrote: > Currently, the Dialog DA1469x is unsupported in OpenOCD. Only the proprietary > JLinkExe can connect it. I want to be able to use OpenOCD and other debug > adapters. Do you also hope to be able to flash this target? As that would require developing a dedicated flash driver. > OpenOCD fails at one of the very first steps, which is in the SWD protocol to > do > a LINERESET followed by the JTAG->SWD switch sequence, a LINERESET again and > reading out the IDCODE. Looking at the SWD signals with a logic analyzers and > PulseView, I compared the different signals that OpenOCD and JLinkExe produced > and found that JLinkExe does a few more LINERESETs as the first attempt of > reading IDCode actually fails, without a JTAG->SWD sequence in between. That's quite a valueable clue. You can try tweaking swd_connect_single() in src/target/adi_v5_swd.c to match the behaviour, probably by adding swd_send_sequence(dap, LINE_RESET); or changing swd_seq_jtag_to_swd[] in src/jtag/swd.h . > I'd also like to note that after using JLinkExe to connect, through some > command > sequence that I cannot reproduce anymore, openocd managed to connect using > that > config file. That's why I at least now -irlen 8 is right, it would not do that > with -irlen 4. From there I coud do a "dap info". irlen is only meaningful in JTAG mode, not in SWD. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#386] OpenOCD can't connect to Dialog DA1469x** **Status:** new **Milestone:** 0.11.0 **Labels:** swd da1469x jlink **Created:** Wed Mar 15, 2023 02:30 PM UTC by Maximilian Gerhardt **Last Updated:** Wed Mar 15, 2023 02:56 PM UTC **Owner:** nobody **Attachments:** - [dia.cfg](https://sourceforge.net/p/openocd/tickets/386/attachment/dia.cfg) (1.8 kB; application/octet-stream) - [jlink_logs.txt](https://sourceforge.net/p/openocd/tickets/386/attachment/jlink_logs.txt) (1.5 kB; text/plain) - [jlinkexe_good_connect.sr](https://sourceforge.net/p/openocd/tickets/386/attachment/jlinkexe_good_connect.sr) (3.6 kB; application/octet-stream) - [openocd_ap_info_good_connect.txt](https://sourceforge.net/p/openocd/tickets/386/attachment/openocd_ap_info_good_connect.txt) (1.8 kB; text/plain) - [openocd_bad_connect.sr](https://sourceforge.net/p/openocd/tickets/386/attachment/openocd_bad_connect.sr) (2.3 kB; application/octet-stream) Specifically, I have a custom DA14695 board, but it's the same with a [USB DevKit](https://www.renesas.com/br/en/products/wireless-connectivity/bluetooth-low-energy/da14695-00hqdevkt-u-smartbond-da14695-bluetooth-low-energy-52-usb-development-kit). Chip datasheet [see here](https://www.renesas.com/br/en/products/wireless-connectivity/bluetooth-low-energy/da14695-multi-core-bluetooth-52-soc-system-power-management-unit#document). It's a Cortex-M33 and Cortex-M0+ coprocessor (runs Bluetooth stack). Each have their own SWDIO+SWDCLK signals. I'm only interested in connecting to the Cortex-M33 main processor right now. Currently, the Dialog DA1469x is unsupported in OpenOCD. Only the proprietary JLinkExe can connect it. I want to be able to use OpenOCD and other debug adapters. So to get started with getting OpenOCD + JLink to work first without changing the debug adapter. this however fails horribly with the error Debug: 1132 515 jlink.c:2197 jlink_swd_run_queue(): SWD ack not OK: 7 JUNK Error: 1133 517 adi_v5_swd.c:144 swd_connect(): Error connecting DP: cannot read IDR While when using JLinkExe, it detects the chip just fine Found SW-DP with ID 0x0BE12477 AP0: AHB-AP (IDR: 0x14770015) Found Cortex-M33 r0p2, Little endian. OpenOCD fails at one of the very first steps, which is in the SWD protocol to do a LINERESET followed by the JTAG->SWD switch sequence, a LINERESET again and reading out the IDCODE. Looking at the SWD signals with a logic analyzers and PulseView, I compared the different signals that OpenOCD and JLinkExe produced and found that JLinkExe does a few more LINERESETs as the first attempt of reading IDCode actually fails, without a JTAG->SWD sequence in between. I'd also like to note that after using JLinkExe to connect, through some command sequence that I cannot reproduce anymore, openocd managed to connect using that config file. That's why I at least now -irlen 8 is right, it would not do that with -irlen 4. From there I coud do a "dap info". Here attached are the PulseView session files which should have the signal trace (with SWD decoding) in it, from JLinkExe and OpenOCD, next to the config file and JLinkExe output (sadly there are no verbose logs there). The OpenOCD command I'm using is 'openocd -f interface/jlink.cfg -c "transport select swd" -s . -f dia.cfg -c "gdb_memory_map disable"' I'd be happy for any pointer on how to get OpenOCD to talk to the Cortex-M33 successfully. --- Sent from sourceforge.net
Re: review.openocd.org issues?
Hi Tomas, On Sat, Mar 04, 2023 at 12:43:21PM +0100, Tomas Vanek wrote: > On 30/12/2022 21:42, Antonio Borneo wrote: > > On Fri, Dec 30, 2022 at 8:36 PM Paul Fertser wrote: > > > On Fri, Dec 30, 2022 at 07:56:40PM +0100, Antonio Borneo wrote: > > > > I have just sent 4 new patches to gerrit, then opened one of them to > > > > add a comment. > > > > The page didn't open, and after some time the browser returned a white > > > Did it feel like 5 minutes (300 seconds)? Or certainly less than that? > > Much less, 1 minute, maximum 2. > > > The review web continues to be unresponsive time to time, frequently enough > to make me annoyed. Oh, sorry to hear that, annoying major contributors is indeed bad :/ > Today I was getting 'Proxy error' or no response at all from 12:05 CET to > 12:12 (11:05 UTC) > There was no Jenkins job this time. > What could be the problem? I'm really puzzled about it. See, everything was just normal until review.openocd.org:443 xxx - - [04/Mar/2023:10:54:27 +] "GET /gitweb?p=openocd.git;a=blobdiff;f=README.OSX;h=979c64ba60944b507cffb3b9d4784ef4128bf0d7;hp=2bea870f4fce2b 0b22c5e503e3b688ecd6a891a9;hb=baf08b0a1ad656434583e3c102a350d4cf885bf9;hpb=85c1790beb955658fe8eeab2fe0904206aeb88a6 HTTP/1.1" 200 17156 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://m j12bot.com/)" review.openocd.org:443 xxx - - [04/Mar/2023:10:54:31 +] "GET /gitweb?p=openocd.git;a=blobdiff;f=README.OSX;h=979c64ba60944b507cffb3b9d4784ef4128bf0d7;hp=5fec44f2013cd9 18baffa93234d35306f116c5ec;hb=baf08b0a1ad656434583e3c102a350d4cf885bf9;hpb=10df176b0fb932d61f0dc5d6bfd0a0942501fc40 HTTP/1.1" 200 13765 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://m j12bot.com/)" review.openocd.org:443 xxx - - [04/Mar/2023:10:54:33 +] "GET /gitweb?p=openocd.git;a=blobdiff;f=README;h=00e83bbf4aafdf2eaf34adcf8e853c9b8fb6ac67;hp=62d1f777aecf022d68 78b3e7c54c9668c9e9ba6a;hb=80ca927ebc2bb1ca18aff70215222d55c1f196f8;hpb=cf692abe83a90f74cb21b1864f348cd52fe26454 HTTP/1.1" 200 73970 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12b ot.com/)" review.openocd.org:443 xxx - - [04/Mar/2023:10:54:35 +] "GET /gitweb?p=openocd.git;a=blobdiff;f=README;h=00e83bbf4aafdf2eaf34adcf8e853c9b8fb6ac67;hp=645ff652ace9087550 fa94f5f7e46cf08982da78;hb=80ca927ebc2bb1ca18aff70215222d55c1f196f8;hpb=8d8937359606a56f1cda19d858a4edcda93eacb9 HTTP/1.1" 200 25434 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12b ot.com/)" openocd.zylin.com:80 xxx - - [04/Mar/2023:10:56:58 +] "GET /190 HTTP/1.1" 301 532 "-" "Mozilla/5.0 (compatible; AhrefsBot/7.0; +http://ahrefs.com/robot/)" openocd.zylin.com:80 xxx - - [04/Mar/2023:10:57:35 +] "GET /robots.txt HTTP/1.1" 301 546 "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; h...@moz.com)" build.openocd.org:443 xxx - - [04/Mar/2023:10:57:49 +] "HEAD / HTTP/1.1" 200 5799 "https://build.openocd.org; "Mozilla/5.0+(compatible; UptimeRobot/2.0; http://www.uptimerobot.com/)" review.openocd.org:443 xxx - - [04/Mar/2023:10:54:38 +] "GET /gitweb?p=openocd.git;a=blobdiff;f=README;h=00e83bbf4aafdf2eaf34adcf8e853c9b8fb6ac67;hp=68a7ea90724b944a9b08483c30ebf5af1b99d238;hb=80ca927ebc2bb1ca18aff70215222d55c1f196f8;hpb=c4113b5f3da6bfbc544648cfdde6d3df01b0d7b4 HTTP/1.1" 502 618 "-" "Mozilla/5.0 (compatible; MJ12bot/v1.4.8; http://mj12bot.com/)" That last error is also visible in the error log: [Sat Mar 04 10:59:38.338530 2023] [proxy_http:error] [pid 1236537:tid 140232250861312] (70007)The timeout specified has expired: [client xxx] AH01102: error reading status line from remote server 127.0.0.1:8081 [Sat Mar 04 10:59:38.382246 2023] [proxy:error] [pid 1236537:tid 140232250861312] [client xxx] AH00898: Error reading from remote server returned by /gitweb And it was indeed exactly 5 minutes Apache was waiting for Gerrit's answer. Then it was happening for a while, and then it just started working normally, without restarting anything, without anything in Gerrit's logs. I tried adding disablereuse=On to the relevant ProxyPass directive, let's see if it changes anything. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: official site and 0.12 release
Hello Liviu, On Sat, Jan 21, 2023 at 11:07:07PM +0200, Liviu Ionescu wrote: > According to https://openocd.org, the latest news is that 0.12.0-rc1 is out, > but on github I see: > > - https://github.com/openocd-org/openocd/releases/tag/v0.12.0 > > > If 0.12.0 is indeed out, perhaps the site can be updated too. Indeed, I was postponing the announce a bit to make sure everything's right, and then some unexpected ISP issues came into play etc. I will update the web site soon, thank you. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Ask for help with invalid evaluation of the RTT control block address
Hi Ondřej, On Mon, Jan 16, 2023 at 01:30:42PM +0100, Ondřej Bureš wrote: > To be more specific, I built a binary file with the RTT control block at > address 0x20006878, but for some reason OpenOCD finds the RTT control block at > an address smaller by one byte than is the actual address (0x20006877) that ... > - OpenOCD version: 0.11.0-00155-ge392e485e (2021-03-15-16:44) Please try 0.12.0, there was a related fix in it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: review.openocd.org issues?
On Fri, Dec 30, 2022 at 07:56:40PM +0100, Antonio Borneo wrote: > I have just sent 4 new patches to gerrit, then opened one of them to > add a comment. > The page didn't open, and after some time the browser returned a white Did it feel like 5 minutes (300 seconds)? Or certainly less than that? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #379 Create custom jtag driver in openocd
Hi, On Thu, Dec 29, 2022 at 02:25:23PM -, Ashi Gupta wrote: > I am working on creating a custom JTAG driver for my custom interface. I am ... You have already asked about it in https://sourceforge.net/p/openocd/tickets/374/ . The answer is still the same. And if you plan to violate GPL then you shouldn't expect any support at all. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#379] Create custom jtag driver in openocd ** **Status:** new **Milestone:** 0.10.0 **Labels:** openocd **Created:** Thu Dec 29, 2022 02:25 PM UTC by Ashi Gupta **Last Updated:** Thu Dec 29, 2022 02:42 PM UTC **Owner:** nobody Hello, I am working on creating a custom JTAG driver for my custom interface. I am trying to understand Jlink.c existing driver file in openocd to create my_jtag_driver.c. Is there any documentation available to understand jlink.c driver ? Or any document to create own jtag driver ? --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: Bug report
Hi, On Wed, Dec 28, 2022 at 10:16:13PM +0530, Er.charmin Faldu wrote: > Please find the bug report I am getting, your help is required to solve it. I do not see any bug report, only the output of an OpenOCD process that had no issues working at all, it's a normal regular run. > [[1]https://github.com/STMicroelectronics/OpenOCD] This is not upstream OpenOCD. Please reproduce your issue with upstream code and give an elaborate description of what you're doing and what exactly goes wrong. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
OpenOCD 0.12.0-rc3 is out
Hello, The OpenOCD team tagged and pushed the third release candidate recently[1]. So far it looks good, and if no major issues are found we hope to release the final soon. If you think some important fix needs to be merged now, raise your voice. Please feel free to provide feedback via the devel mailing list, SourceForge tickets and IRC. [1] https://sourceforge.net/projects/openocd/files/openocd/0.12.0-rc3/ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com signature.asc Description: PGP signature
Re: review.openocd.org issues?
On Wed, Dec 14, 2022 at 06:48:55PM +, Tarek BOCHKATI wrote: > I confirm the issue, but I have more findings. When Jenkins is > running a job (build, scan-build) the access to gerrit starts to be > very slow, sometimes unreachable. Thank you for these additional details. I see that our VM has just a single CPU so I reduced the amount of executors from 2 to one and also niced the build process. Let's see if it helps... -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: review.openocd.org issues?
Hi Jonathan, On Wed, Dec 14, 2022 at 02:23:30PM +, Jonathan McDowell wrote: > I've been finding reviews.openocd.org very slow over the past few days - Thank you for the report, I'll try to take a look soonish. Gerrit shares a VM with Jenkins CI system, so probably it's slower during the compilations, but they should all be niced accordingly, so I've no idea yet. Probably the whole VM got slower for whatever reason, I'm going to try to see what exactly is happening there. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] #374 How to add a new JTAG driver support in openocd
- **status**: new --> closed - **Comment**: Hello, > I have created my driver DLL Unless you are releasing source code of that DLL under a GPL-compatible licence you are NOT allowed to distribute OpenOCD that's using it. Please keep that in mind and respect the Copyright law. Regarding your questions, this ticketing system is not a support forum, please write to the devel mailing list instead. --- ** [tickets:#374] How to add a new JTAG driver support in openocd ** **Status:** closed **Milestone:** 0.10.0 **Labels:** openocd **Created:** Thu Dec 08, 2022 01:30 PM UTC by Ashi Gupta **Last Updated:** Thu Dec 08, 2022 01:41 PM UTC **Owner:** OpenOCD-Gerrit Hello, I want to add support for a new custom JTAG driver in openocd. I have created my driver DLL that i have interfaced with openocd and create a new driver .c file (similar to jlink.c but with my driver APIs for JTAG operation). Below are the queries i have: 1. Is there any documentation available that explains how to create driver file in openocd ? I am referring jlink.c but need some more clarity on what is the JTAG data sequence and API format needed in driver to get it working with openocd ? 2. I have multiple DAPs in my system in daisy chain. How to manage this with openocd ? Do i have to manage DAP selection in my driver or can provide configuration details in cfg file ? Any example for cfg file to follow ? Thanks for the help. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] #374 How to add a new JTAG driver support in openocd
Hello, > I have created my driver DLL Unless you are releasing source code of that DLL under a GPL-compatible licence you are NOT allowed to distribute OpenOCD that's using it. Please keep that in mind and respect the Copyright law. Regarding your questions, this ticketing system is not a support forum, please write to the devel mailing list instead. --- ** [tickets:#374] How to add a new JTAG driver support in openocd ** **Status:** new **Milestone:** 0.10.0 **Labels:** openocd **Created:** Thu Dec 08, 2022 01:30 PM UTC by Ashi Gupta **Last Updated:** Thu Dec 08, 2022 01:30 PM UTC **Owner:** OpenOCD-Gerrit Hello, I want to add support for a new custom JTAG driver in openocd. I have created my driver DLL that i have interfaced with openocd and create a new driver .c file (similar to jlink.c but with my driver APIs for JTAG operation). Below are the queries i have: 1. Is there any documentation available that explains how to create driver file in openocd ? I am referring jlink.c but need some more clarity on what is the JTAG data sequence and API format needed in driver to get it working with openocd ? 2. I have multiple DAPs in my system in daisy chain. How to manage this with openocd ? Do i have to manage DAP selection in my driver or can provide configuration details in cfg file ? Any example for cfg file to follow ? Thanks for the help. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [PATCH] src/target/semihosting_common.c: add stdfd fd control command
Hi, I know you've already figured it out, so just for the reference in case someone arrives here via an Internet search. On Fri, Nov 25, 2022 at 11:57:32AM +0530, Kautuk Consul wrote: > But now the build is showing that mingw64 compiled fine but the build got > aborted: The build is aborted when a new version of the same change is uploaded, and that's exactly what happened there. Thank you for being persistent with upstreaming! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: [PATCH] src/target/semihosting_common.c: add stdfd fd control command
Hi, On Thu, Nov 24, 2022 at 10:10:59PM +0530, Kautuk Consul wrote: > So I managed to create a gerrit account and followed the instructions in > HACKING. Thanks, you did everything right. > But, I got a build failure for mingw64 as given > by: [1]https://build.openocd.org/job/openocd-gerrit-build/16294/console See, from https://review.openocd.org/c/openocd/+/7377 you follow https://build.openocd.org/job/openocd-gerrit-build/16294/ , then mingw64, then Console Output leads to https://build.openocd.org/job/openocd-gerrit-build/16294/TARGET=mingw64/console so the problem is error: implicit declaration of fcntl function which is not surprising as OpenOCD needs to be buildable as a native Windows application and that platform lacks certain common functions. > Do I have to resolve this compilation problem before anyone reviews the patch > ? After you decide how to resolve it (probably by #ifdef'ing out your whole command when building for windows or probably by finding some windows-specific way) you just --amend the patch locally (do not change the Change-Id) and send it to Gerrit again the same way. HTH :) -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: [PATCH] src/target/semihosting_common.c: add stdfd fd control command
On Wed, Nov 23, 2022 at 04:40:29PM +0530, Kautuk Consul wrote: > I don't have access to gerrit and I am not a regular contributor. It's open for public, and anybody can send and review patches there. > I am doing board bring-up for our RISCV board and I noticed this issue with > our > internal simulator so I decided to send this patch. It's an interesting patch and it might come useful to the others, thank you for sharing. > Can you please review it ? No, sorry, I can help if you have any issues with Gerrit or other OpenOCD infra, I'm not reviewing patches at all. I know the OpenOCD maintainers prefer not to review patches on the mailing list, so I'm afraid unless somebody interested decides to paste it to Gerrit, it won't get any traction. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: [PATCH] src/target/semihosting_common.c: add stdfd fd control command
Hi, On Tue, Nov 22, 2022 at 12:18:30PM +0530, Kautuk Consul wrote: > Can anyone review my patch ? > This patch can improve performance of semihosting with respect to key-strokes. Thank you for the patch. Have you considered sending it to the project's Gerrit as per instructions in HACKING? Reviewing is normally happening there. Are there any issues with Gerrit access for you? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Problem specifying CFLAGS
Hi, On Sun, Nov 06, 2022 at 05:31:12PM +0100, R. Diez wrote: > CFLAGS="-g -O0" > > to the "make" command, in order to disable optimisations that make debugging > difficult. I think instead you should be doing CFLAGS="-g -O0" ./configure instead, I just tried and it works as expected. > there is the following command: > > scan-build make CFLAGS="-std=gnu99 -I. -I../../jimtcl" > > And you wouldn't normally add such '-I' flags if there wasn't such an issue. I do not remember all the details but IIRC it was something about how scan-build interacts with autoconf-based projects and how configure uses CC variable to embed some essential additional flags, and CC is exactly what scan-build overrides. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
OpenOCD version 0.12.0-rc2 (second Release Candidate) is out
Hi, Today we tagged the second release candidate for the upcoming version. Many nice fixes went in since -rc1; in no particular order I'd like to mention support for the popular RP2040 MCU getting some polishing, improved reliability for the fast MMIO-based driver that's used on Raspberry Pi SoCs BCM2837 and BCM2711, ESP32 and generic xtensa fixups and some documentation touches; for the full list see [0]. Please help test this version and report all your findings via SF tickets, mailing list or the IRC channel. I want to remind that before the final release is tagged we are in a feature freeze state so merging of patches introducing new functionality will have to be postponed. That shouldn't discourage you from sending them for review though, and if something isn't getting traction please do not hesitate to nag on the mailing list. [0] http://sourceforge.net/p/openocd/code/ci/v0.12.0-rc2/log/?path= -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #356 fail to debug a micro:bit v2 application
Hi, On Wed, Jul 13, 2022 at 01:04:07PM -, Matei Barbu wrote: > I would ignore the error messages, but gdb fails to run correctly: > Reading symbols from > ../../target/thumbv7em-none-eabi/release/microbit_v2.elf... > (gdb) target extended-remote localhost: Remote debugging using > localhost: 0x0001ad90 in ?? () What's not correct here? Are you not able to use "load" to flash this target at that point? --- ** [tickets:#356] fail to debug a micro:bit v2 application** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Jul 13, 2022 01:04 PM UTC by Matei Barbu **Last Updated:** Wed Jul 13, 2022 01:04 PM UTC **Owner:** nobody Hello, Am i trying to flash the [TockOS](https://github.com/tock/tock/) kenel using OpenOCD on a [micro:bitv2](https://github.com/tock/tock/tree/master/boards/microbit_v2) board, but ran into difficulties. ```bash $ openocd Open On-Chip Debugger 0.11.0-rc2 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Error: flash bank name 'nrf52.flash' already exists Error: flash bank name 'nrf52.uicr' already exists -4 Info : Listening on port for tcl connections Info : Listening on port for telnet connections Info : Using CMSIS-DAPv2 interface with VID:PID=0x0d28:0x0204, serial=9904360258994e450062900c00339796990b Info : CMSIS-DAP: SWD Supported Info : CMSIS-DAP: FW Version = 0255 Info : CMSIS-DAP: Serial# = 9904360258994e450062900c00339796990b Info : CMSIS-DAP: Interface Initialised (SWD) Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 0 TDO = 0 nTRST = 0 nRESET = 1 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : SWD DPIDR 0x2ba01477 Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints Info : starting gdb server for nrf52.cpu on Info : Listening on port for gdb connections Info : accepting 'gdb' connection on tcp/ Info : nRF52833-xxAA(build code: A0) 512kB Flash, 128kB RAM undefined debug reason 8 - target needs reset Polling target nrf52.cpu failed, trying to reexamine Info : SWD DPIDR 0x2ba01477 Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints Polling target nrf52.cpu failed, trying to reexamine Info : SWD DPIDR 0x2ba01477 Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints Error: nrf52.cpu -- clearing lockup after double fault Polling target nrf52.cpu failed, trying to reexamine Info : nrf52.cpu: hardware has 6 breakpoints, 4 watchpoints Info : dropped 'gdb' connection Info : accepting 'gdb' connection on tcp/``` I would ignore the error messages, but `gdb` fails to run correctly: ```Reading symbols from ../../target/thumbv7em-none-eabi/release/microbit_v2.elf... (gdb) target extended-remote localhost: Remote debugging using localhost: 0x0001ad90 in ?? ()``` I am running Debian 5.10.127-1 (2022-06-30) x86_64 GNU/Linux natively, with ```$ gdb-multiarch -v GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git``` Am I doing something wrong? I would much appreciate your help! --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: openocd.zylin.com auth issue?
Hi Tim, On Fri, Jul 08, 2022 at 01:13:21PM -0700, Tim Newsome wrote: > I used to be able to `git push review` to open a new pull request, but that's > no > longer working: Yes, that should still work. Probably you upgraded your ssh client and it now doesn't want to use that old key of yours? You can probably get more information by trying $ ssh -vv -p 29418 tim_sif...@openocd.zylin.com > I checked and [4]https://review.openocd.org/settings/#SSHKeys shows that my > SSH > keys match. Did something change that means I need to take some extra steps? There was a recent report by zapb which was similar to yours, and afaict it was upgrade of the ssh client. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: github action for Windows binary
Hello, On Tue, May 31, 2022 at 01:44:07PM +0800, Xiaofan Chen wrote: > Thanks. I have the FTDI based adapter. The binary seems to work fine. ... > source [find interface/ftdi/jtagkey2.cfg] As a side-note, for this adapter OpenOCD uses libusb-1.0 API directly, without libftdi involved anyhow. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: [PATCH] Add partial support for Renesas MCUs with RV40F
Hi Miloslav, On Mon, May 02, 2022 at 11:13:58AM +0200, Miloslav Semler wrote: > this patch contain support for programming/erasing MCUs with RV40F type > memory inside (RA6M1, RA6M2, RA6M3, RA6T1 series). Thank you for the patch. Please consider sending it to our Gerrit server for review, see HACKING. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: cannot create a patch
On Thu, Apr 28, 2022 at 08:07:28PM +0200, Christian Groessler wrote: > > On Thu, Apr 28, 2022 at 03:40:53PM +0200, Christian Groessler wrote: > > > How can I contact the administrator? > > Write me an e-mail or let's talk on IRC or Jabber. But I think the > > issue is what I described in the previous mail to you. > > I haven't received an email by you. Can you re-send it to me? Sure, attached. But it just said that you should try to "git push review HEAD:refs/for/master" rather than to master directly. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- Begin Message --- Hi, On Wed, Apr 27, 2022 at 10:35:45PM +0200, Christian Groessler wrote: > [hp-toni:~/tmp/openocd-commit/openocd-code]$ git push review Please try git push review HEAD:refs/for/master > 5 or 6 years ago I didn't need special rights... I'm quite sure you were pushing to a different ref back then, not to master. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- End Message ---
Re: cannot create a patch
Hi, On Thu, Apr 28, 2022 at 03:40:53PM +0200, Christian Groessler wrote: > How can I contact the administrator? Write me an e-mail or let's talk on IRC or Jabber. But I think the issue is what I described in the previous mail to you. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: cannot create a patch
Hi, On Wed, Apr 27, 2022 at 10:35:45PM +0200, Christian Groessler wrote: > [hp-toni:~/tmp/openocd-commit/openocd-code]$ git push review Please try git push review HEAD:refs/for/master > 5 or 6 years ago I didn't need special rights... I'm quite sure you were pushing to a different ref back then, not to master. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: workflow for issuing a suggested patch, please (ARC processor)
Hi Jon, On Fri, Mar 18, 2022 at 10:37:56AM +, Jon Nicoll wrote: > I have made some small .c and .tcl changes which I think fix this. This has > not helped with my original problem but I would like to contribute this > change to OpenOCD. I'm unsure of the process though, can someone point me at Please see HACKING in the root of the source tree. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #342 invalid command name "hla_layout"
On Thu, Mar 17, 2022 at 03:43:46PM -, Andrew Eidsness wrote: > I think that the stellaris configuration is for the on-board ICDI which is > accessible over the board's serial port. I'm experimenting with using an > external one. There are alot of good examples in that folder though. I might > start with the stellaris one, then see what else I can do. All configs in target/ directory are target configs, they do not include the on-board ICDI or other on-board adapters. Stellaris is the name of the original line-up, and it should work with your part. > I don't know much about openocd, I'm mainly just experimenting to see what I > can > get to work. I suggest you read the official User Manual while doing so. > Thanks for your help -- this should definitely have been a forum post instead, > I'll followup there if I have any actual questions. No idea what forum you have in mind, I suggest using the mailing list or our IRC channel, I do not read any forums. --- ** [tickets:#342] invalid command name "hla_layout"** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Mar 16, 2022 08:53 PM UTC by Andrew Eidsness **Last Updated:** Thu Mar 17, 2022 03:43 PM UTC **Owner:** nobody I've checked out the v0.11.0 branch and built openocd with the config parameters listed at the end. I've actually tried several different options, the one listed at the end is "everything I could find". I've also reproduced this on the v0.10.0 that comes bundled with my OS (Ubuntu 20.04). I've connected a FlySwatter2 to a 1294xl, but I get an error when trying to launch with: $ openocd -f interface/ftdi/flyswatter2.cfg -f board/ti_ek-tm4c1294xl.cfg -c init Open On-Chip Debugger 0.11.0-dirty (2022-03-15-11:17) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Warn : Interface already configured, ignoring /usr/local/bin/../share/openocd/scripts/interface/ti-icdi.cfg:11: Error: invalid command name "hla_layout" in procedure 'script' at file "embedded:startup.tcl", line 26 at file "/usr/local/bin/../share/openocd/scripts/board/ti_ek-tm4c1294xl.cfg", line 7 at file "/usr/local/bin/../share/openocd/scripts/interface/ti-icdi.cfg", line 11 Configuration line: $ ./configure --enable-dummy --enable-rshim --enable-ftdi --enable-stlink --enable-ti-icdi --enable-ulink --enable-usb-blaster-2 --enable-ft232r --enable-vsllink --enable-xds110 --enable-osbdm --enable-opendous --enable-aice --enable-usbprog --enable-rlink --enable-armjtagew --enable-usb-blaster --enable-presto --enable-openjtag --enable-jlink --enable-jtag_vpi --enable-jtag_dpi --enable-amtjtagaccel --enable-bcm2835gpio --enable-imx_gpio --enable-ep93xx --enable-at91rm9200 --enable-gw16012 --enable-buspirate --enable-sysfsgpio --enable-xlnx-pcie-xvc --enable-remote-bitbang --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #342 invalid command name "hla_layout"
On Thu, Mar 17, 2022 at 11:27:23AM -, Andrew Eidsness wrote: > Ah, thanks! I don't see a target config for this chip, but I think I can > figure > that out. In board/ti_ek-tm4c1294xl.cfg you can see it's just sourcing target/stellaris.cfg . > This ticket can probably be closed, but I don't see a button that lets me do > that. We'll close it later, thank you for caring. --- ** [tickets:#342] invalid command name "hla_layout"** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Mar 16, 2022 08:53 PM UTC by Andrew Eidsness **Last Updated:** Thu Mar 17, 2022 11:27 AM UTC **Owner:** nobody I've checked out the v0.11.0 branch and built openocd with the config parameters listed at the end. I've actually tried several different options, the one listed at the end is "everything I could find". I've also reproduced this on the v0.10.0 that comes bundled with my OS (Ubuntu 20.04). I've connected a FlySwatter2 to a 1294xl, but I get an error when trying to launch with: $ openocd -f interface/ftdi/flyswatter2.cfg -f board/ti_ek-tm4c1294xl.cfg -c init Open On-Chip Debugger 0.11.0-dirty (2022-03-15-11:17) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Warn : Interface already configured, ignoring /usr/local/bin/../share/openocd/scripts/interface/ti-icdi.cfg:11: Error: invalid command name "hla_layout" in procedure 'script' at file "embedded:startup.tcl", line 26 at file "/usr/local/bin/../share/openocd/scripts/board/ti_ek-tm4c1294xl.cfg", line 7 at file "/usr/local/bin/../share/openocd/scripts/interface/ti-icdi.cfg", line 11 Configuration line: $ ./configure --enable-dummy --enable-rshim --enable-ftdi --enable-stlink --enable-ti-icdi --enable-ulink --enable-usb-blaster-2 --enable-ft232r --enable-vsllink --enable-xds110 --enable-osbdm --enable-opendous --enable-aice --enable-usbprog --enable-rlink --enable-armjtagew --enable-usb-blaster --enable-presto --enable-openjtag --enable-jlink --enable-jtag_vpi --enable-jtag_dpi --enable-amtjtagaccel --enable-bcm2835gpio --enable-imx_gpio --enable-ep93xx --enable-at91rm9200 --enable-gw16012 --enable-buspirate --enable-sysfsgpio --enable-xlnx-pcie-xvc --enable-remote-bitbang --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #342 invalid command name "hla_layout"
Hi, On Wed, Mar 16, 2022 at 08:53:17PM -, Andrew Eidsness wrote: > I've checked out the v0.11.0 branch and built openocd with the config > parameters > listed at the end. I've actually tried several different options, the one > listed > at the end is "everything I could find". ... > I've connected a FlySwatter2 to a 1294xl, but I get an error when trying to > launch with: > > $ openocd -f interface/ftdi/flyswatter2.cfg -f board/ti_ek-tm4c1294xl.cfg -c This looks more like a support request, please consider writing to the mailing list (-devel is fine) or asking on the IRC the next time. The problem there is that you tell OpenOCD you're using a specific evaluation board while in fact you're connecting an external JTAG adapter directly to the target chip. So you should be sourcing the target config rather than the board config. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#342] invalid command name "hla_layout"** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Mar 16, 2022 08:53 PM UTC by Andrew Eidsness **Last Updated:** Wed Mar 16, 2022 08:53 PM UTC **Owner:** nobody I've checked out the v0.11.0 branch and built openocd with the config parameters listed at the end. I've actually tried several different options, the one listed at the end is "everything I could find". I've also reproduced this on the v0.10.0 that comes bundled with my OS (Ubuntu 20.04). I've connected a FlySwatter2 to a 1294xl, but I get an error when trying to launch with: $ openocd -f interface/ftdi/flyswatter2.cfg -f board/ti_ek-tm4c1294xl.cfg -c init Open On-Chip Debugger 0.11.0-dirty (2022-03-15-11:17) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html Warn : Interface already configured, ignoring /usr/local/bin/../share/openocd/scripts/interface/ti-icdi.cfg:11: Error: invalid command name "hla_layout" in procedure 'script' at file "embedded:startup.tcl", line 26 at file "/usr/local/bin/../share/openocd/scripts/board/ti_ek-tm4c1294xl.cfg", line 7 at file "/usr/local/bin/../share/openocd/scripts/interface/ti-icdi.cfg", line 11 Configuration line: $ ./configure --enable-dummy --enable-rshim --enable-ftdi --enable-stlink --enable-ti-icdi --enable-ulink --enable-usb-blaster-2 --enable-ft232r --enable-vsllink --enable-xds110 --enable-osbdm --enable-opendous --enable-aice --enable-usbprog --enable-rlink --enable-armjtagew --enable-usb-blaster --enable-presto --enable-openjtag --enable-jlink --enable-jtag_vpi --enable-jtag_dpi --enable-amtjtagaccel --enable-bcm2835gpio --enable-imx_gpio --enable-ep93xx --enable-at91rm9200 --enable-gw16012 --enable-buspirate --enable-sysfsgpio --enable-xlnx-pcie-xvc --enable-remote-bitbang --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #339 Stm32l write to Eeprom failed
On Mon, Feb 28, 2022 at 08:18:41AM -, Milan wrote: > You mean that it was maybe luck that it works with the 0.10.0 Version? I'm > prety > sure that was the official Version. I looked around and couldn't see any possibility for it to work the way you described. > load_image works neither. Their comes no Exception, but the data is > still NULL. Running load_image after unlocking the eeprom did nothing at all? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#339] Stm32l write to Eeprom failed** **Status:** new **Milestone:** 0.11.0 **Created:** Fri Feb 25, 2022 01:39 PM UTC by Milan **Last Updated:** Mon Feb 28, 2022 08:18 AM UTC **Owner:** nobody Hi all, I try to write data to the eeprom of the stm32l151. In OpenOCD Version 0.10.0 I made a .bin File and write that with >flash write_bank 0 eePromFile.bin 0x8< in the Eeprom of the device. With the Version 0.11.0 OpenOCD say: >Error: Offset 0x0008 is out of range of the flash bank< I tried it with >program< and a hexfile but it is the same. How can I write to the Eeprom in Version 0.11.0 --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [openocd:tickets] #339 Stm32l write to Eeprom failed
On Mon, Feb 28, 2022 at 08:18:41AM -, Milan wrote: > You mean that it was maybe luck that it works with the 0.10.0 Version? I'm > prety > sure that was the official Version. I looked around and couldn't see any possibility for it to work the way you described. > load_image works neither. Their comes no Exception, but the data is > still NULL. Running load_image after unlocking the eeprom did nothing at all? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #339 Stm32l write to Eeprom failed
Hi,
On Fri, Feb 25, 2022 at 01:39:15PM -, Milan wrote:
> I try to write data to the eeprom of the stm32l151. In OpenOCD Version 0.10.0
> I
> made a .bin File and write that with >flash write_bank 0 eePromFile.bin
> 0x8<
> in the Eeprom of the device.
I can't see how it could have been working, guess you had some OpenOCD
non-upstream fork, not vanilla 0.10.0.
What I'd probably try is something like this:
mww [expr {0x4000 + 0x2 + 0x3C00 + 0xC}] 0x89ABCDEF
mww [expr {0x4000 + 0x2 + 0x3C00 + 0xC}] 0x02030405
load_image eepromfile.bin 0x0808
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
---
** [tickets:#339] Stm32l write to Eeprom failed**
**Status:** new
**Milestone:** 0.11.0
**Created:** Fri Feb 25, 2022 01:39 PM UTC by Milan
**Last Updated:** Fri Feb 25, 2022 01:39 PM UTC
**Owner:** nobody
Hi all,
I try to write data to the eeprom of the stm32l151. In OpenOCD Version 0.10.0 I
made a .bin File and write that with >flash write_bank 0 eePromFile.bin
0x8< in the Eeprom of the device. With the Version 0.11.0 OpenOCD say:
>Error: Offset 0x0008 is out of range of the flash bank<
I tried it with >program< and a hexfile but it is the same. How can I write to
the Eeprom in Version 0.11.0
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #336 Segmentation Fault with Nucelo-F429ZI
Hi Oliver, On Mon, Feb 07, 2022 at 03:44:29PM -, Oliver Walczak wrote: > @Antonio Borneo Thanx for coming back to me so quickly. I would need to > compile > openocd myself to get the patch both in Mingw and Mac, do I assume correctly? > Or > can you suggest a binary release e.g. for Mac that would include the patch? Getting latest OpenOCD on macOS is as easy as running $ brew install --HEAD openocd --- ** [tickets:#336] Segmentation Fault with Nucelo-F429ZI** **Status:** new **Milestone:** 0.11.0 **Created:** Mon Feb 07, 2022 01:45 PM UTC by Oliver Walczak **Last Updated:** Mon Feb 07, 2022 04:16 PM UTC **Owner:** nobody Issue confirmed on 2 environments: 1) DELL Lattitude 5591 / Win 10 Enterprise 21H2 Build 19044.1466 / MingW64 openocd 11.0 2) MacBook Pro M1 Max / Monterey 12.1 / homebrew openocd 11.0 Log from 1): openocd -f board/st_nucleo_f4.cfg -d3 Open On-Chip Debugger 0.11.0 Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html User : 13 3 options.c:63 configuration_output_handler(): debug_level: 3 User : 14 7 options.c:63 configuration_output_handler(): Debug: 15 11 options.c:244 add_default_dirs(): bindir=D:/a/_temp/msys/msys64/mingw64/bin Debug: 16 17 options.c:245 add_default_dirs(): pkgdatadir=D:/a/_temp/msys/msys64/mingw64/share/openocd Debug: 17 24 options.c:246 add_default_dirs(): exepath=C:/me/Software/stm32/msys64/mingw64/bin Debug: 18 32 options.c:247 add_default_dirs(): bin2data=../share/openocd Debug: 19 37 configuration.c:42 add_script_search_dir(): adding C:/Users/owalczak/AppData/Roaming/OpenOCD Debug: 20 45 configuration.c:42 add_script_search_dir(): adding C:\me\Software\stm32\msys64\home\owalczak/.config/openocd Debug: 21 53 configuration.c:42 add_script_search_dir(): adding C:\me\Software\stm32\msys64\home\owalczak/.openocd Debug: 22 61 configuration.c:42 add_script_search_dir(): adding C:/me/Software/stm32/msys64/mingw64/bin/../share/openocd/site Debug: 23 70 configuration.c:42 add_script_search_dir(): adding C:/me/Software/stm32/msys64/mingw64/bin/../share/openocd/scripts Debug: 24 81 configuration.c:97 find_file(): found C:/me/Software/stm32/msys64/mingw64/bin/../share/openocd/scripts/board/st_nucleo_f4.cfg Debug: 25 92 configuration.c:97 find_file(): found C:/me/Software/stm32/msys64/mingw64/bin/../share/openocd/scripts/interface/stlink.cfg Debug: 26 102 command.c:146 script_debug(): command - adapter driver hla Debug: 28 107 command.c:146 script_debug(): command - hla_layout stlink Debug: 30 112 hla_interface.c:242 hl_interface_handle_layout_command(): hl_interface_handle_layout_command Debug: 31 119 command.c:146 script_debug(): command - hla_device_desc ST-LINK Debug: 33 124 hla_interface.c:216 hl_interface_handle_device_desc_command(): hl_interface_handle_device_desc_command Debug: 34 133 command.c:146 script_debug(): command - hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 Debug: 36 144 command.c:146 script_debug(): command - transport select hla_swd Debug: 37 149 hla_transport.c:205 hl_swd_transport_select(): hl_swd_transport_select Debug: 38 156 configuration.c:97 find_file(): found C:/me/Software/stm32/msys64/mingw64/bin/../share/openocd/scripts/target/stm32f4x.cfg Debug: 39 166 configuration.c:97 find_file(): found C:/me/Software/stm32/msys64/mingw64/bin/../share/openocd/scripts/target/swj-dp.tcl Debug: 40 174 command.c:146 script_debug(): command - transport select Debug: 41 183 configuration.c:97 find_file(): found C:/me/Software/stm32/msys64/mingw64/bin/../share/openocd/scripts/mem_helper.tcl Debug: 42 192 command.c:146 script_debug(): command - add_usage_text mrw address Debug: 44 198 command.c:1115 help_add_command(): added 'mrw' help text Debug: 45 203 command.c:146 script_debug(): command - add_help_text mrw Returns value of word in memory. Debug: 47 209 command.c:1128 help_add_command(): added 'mrw' help text Debug: 48 215 command.c:146 script_debug(): command - add_usage_text mrh address Debug: 50 221 command.c:1115 help_add_command(): added 'mrh' help text Debug: 51 225 command.c:146 script_debug(): command - add_help_text mrh Returns value of halfword in memory. Debug: 53 232 command.c:1128 help_add_command(): added 'mrh' help text Debug: 54 237 command.c:146 script_debug(): command - add_usage_text mrb address Debug: 56 242 command.c:1115 help_add_command(): added 'mrb' help text Debug: 57 247 command.c:146 script_debug(): command - add_help_text mrb Returns value of byte in memory. Debug: 59 254 command.c:1128 help_add_command(): added 'mrb' help text Debug: 60 259 command.c:146 script_debug(): command - add_usage_text mmw address setbits clearbits Debug: 62 266 command.c:1115 help_add_command(): added 'mmw' help text Debug: 63 271 command.c:146 script_debug(): command - add_help_text mmw Modify word in memory. new_val = (old_val & ~clearbits) | setbits; Debug: 65 280 command.c:1128
[openocd:tickets] Re: #331 Error: Can't find interface/stlink.cfg in procedure 'script
Hello, On Sat, Jan 08, 2022 at 08:36:24AM -, Sachin J wrote: > • [2]Screenshot from 2022-01-08 14-03-29.png (165.2 kB; image/png) This doesn't look like a bug in OpenOCD so please use the mailing list or IRC to get help. Also please use text for texts, not image/png. I think you're trying to use old 0.10.0 release with newer stlink v3 adapter. Please upgrade to 0.11.0 or master HEAD. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#331] Error: Can't find interface/stlink.cfg in procedure 'script** **Status:** new **Milestone:** 0.10.0 **Created:** Sat Jan 08, 2022 08:36 AM UTC by Sachin J **Last Updated:** Sat Jan 08, 2022 10:26 AM UTC **Owner:** nobody **Attachments:** - [Screenshot from 2022-01-08 14-03-29.png](https://sourceforge.net/p/openocd/tickets/331/attachment/Screenshot%20from%202022-01-08%2014-03-29.png) (165.2 kB; image/png) Hai, I am working with ST Nucleo-H7A3ZI board and Zephyr micro-ROS. While trying to flash the firmware an error occurred. The terminal displays an error message: "Error: Can't find interface/stlink.cfg in procedure 'script'" I found that the file stlink.cfg is missing. How can I solve this? Thank you. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: Debugger dongle project
Hi, On Mon, Oct 11, 2021 at 02:44:08PM +0200, Antonio Borneo wrote: > Personally I would be interested in implementing a high-speed trace > port adapter for ARM targets, but I'm afraid of the missing skills (on > my side) on the high-speed PCB and cabling. https://github.com/orbcode/orbtrace is in the works and already works afaict. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Porting the P Multilink Universal adapter
Hello Christopher, On Thu, Oct 07, 2021 at 03:52:56PM +0100, Christopher West wrote: > No you would not. Unless you have permission to distribute the source code > of > the DLLs under GPL, you cannot distribute OpenOCD built to link with these > DLLs. It doesn't matter how you divide up the distribution in packages. > > That's a shame it will just have to be for my own use then. That's a shame some vendors are so anti-users that they do not release useful documentation and code for their tools. Guess they should be boycotted especially given other much more friendly tools and vendors exist. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #318 adapter driver presto - not work
On Tue, Sep 14, 2021 at 12:32:32PM -, Michal Hucik wrote: > Here is dbg output from OpenOCD. Error: 81 2255 core.c:1132 jtag_examine_chain_check(): JTAG scan chain interrogation failed: all ones Error: 82 2255 core.c:1133 jtag_examine_chain_check(): Check JTAG interface, timings, target power, etc. So it looks like no communication happens at all. At this stage there's nothing fancy going on, it's almost like communicating to a regular shift register. Probably you can attach screenshots from your LA so that one wouldn't need to install custom software to take a look? --- ** [tickets:#318] adapter driver presto - not work** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Sep 08, 2021 07:25 AM UTC by Michal Hucik **Last Updated:** Tue Sep 14, 2021 12:32 PM UTC **Owner:** nobody I'm trying a first time to use Asix PRESTO with OpenOCD. (this Presto is normally working with the Asix UP software for Windows) I tried to use in Windows precompiled OpenOCD 0.11 and in Linux fresh compiled by me. In the configuration I use "adapter driver presto", or in addition "presto_serial 013979". However, on both systems, OpenOCD cannot correctly initialize PRESTO. Linux dmesg [395089.615983] usb 2-2.2: new full-speed USB device number 29 using uhci_hcd [395089.820689] usb 2-2.2: New USB device found, idVendor=0403, idProduct=f1a0, bcdDevice= 4.00 [395089.820693] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [395089.820694] usb 2-2.2: Product: ASIX PRESTO [395089.820696] usb 2-2.2: Manufacturer: ASIX [395089.820697] usb 2-2.2: SerialNumber: A6013979 OpenOCD --debug Debug: 56 5 presto.c:139 presto_open_libftdi(): searching for PRESTO using libftdi Error: 57 7 presto.c:149 presto_open_libftdi(): unable to open PRESTO: usb_open() failed Error: 58 8 presto.c:540 presto_jtag_init(): Cannot open PRESTO Debug: 59 8 command.c:629 run_command(): Command 'init' failed with error code -100 --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #318 adapter driver presto - not work
Hi, On Tue, Sep 14, 2021 at 12:19:22PM -, Michal Hucik wrote: > I have connected OpenOCD with PRESTO, however communication with the CPU is > failed. If someone wants to take a look, then in the attachment I send > communication log on JTAG created by logic analyzer. I have communication log > with neorv32 from PRESTO and by J-Link (J-Link communication is OK). Were both performed using OpenOCD? Can you also attach -d3 output from OpenOCD in both cases please? --- ** [tickets:#318] adapter driver presto - not work** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Sep 08, 2021 07:25 AM UTC by Michal Hucik **Last Updated:** Tue Sep 14, 2021 12:19 PM UTC **Owner:** nobody I'm trying a first time to use Asix PRESTO with OpenOCD. (this Presto is normally working with the Asix UP software for Windows) I tried to use in Windows precompiled OpenOCD 0.11 and in Linux fresh compiled by me. In the configuration I use "adapter driver presto", or in addition "presto_serial 013979". However, on both systems, OpenOCD cannot correctly initialize PRESTO. Linux dmesg [395089.615983] usb 2-2.2: new full-speed USB device number 29 using uhci_hcd [395089.820689] usb 2-2.2: New USB device found, idVendor=0403, idProduct=f1a0, bcdDevice= 4.00 [395089.820693] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [395089.820694] usb 2-2.2: Product: ASIX PRESTO [395089.820696] usb 2-2.2: Manufacturer: ASIX [395089.820697] usb 2-2.2: SerialNumber: A6013979 OpenOCD --debug Debug: 56 5 presto.c:139 presto_open_libftdi(): searching for PRESTO using libftdi Error: 57 7 presto.c:149 presto_open_libftdi(): unable to open PRESTO: usb_open() failed Error: 58 8 presto.c:540 presto_jtag_init(): Cannot open PRESTO Debug: 59 8 command.c:629 run_command(): Command 'init' failed with error code -100 --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
[openocd:tickets] Re: #318 adapter driver presto - not work
Hello Michal, On Wed, Sep 08, 2021 at 07:25:38AM -, Michal Hucik wrote: > I'm trying a first time to use Asix PRESTO with OpenOCD. That's apparently a rather unusual adapter. > OpenOCD --debug > Debug: 56 5 presto.c:139 presto_open_libftdi(): searching for PRESTO using > libftdi > Error: 57 7 presto.c:149 presto_open_libftdi(): unable to open PRESTO: > usb_open() failed > Error: 58 8 presto.c:540 presto_jtag_init(): Cannot open PRESTO Can you possibly join #openwrt on Libera IRC network for an interactive debugging session today? Have you made sure it's not a permissions problem? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#318] adapter driver presto - not work** **Status:** new **Milestone:** 0.11.0 **Created:** Wed Sep 08, 2021 07:25 AM UTC by Michal Hucik **Last Updated:** Wed Sep 08, 2021 07:25 AM UTC **Owner:** nobody I'm trying a first time to use Asix PRESTO with OpenOCD. (this Presto is normally working with the Asix UP software for Windows) I tried to use in Windows precompiled OpenOCD 0.11 and in Linux fresh compiled by me. In the configuration I use "adapter driver presto", or in addition "presto_serial 013979". However, on both systems, OpenOCD cannot correctly initialize PRESTO. Linux dmesg [395089.615983] usb 2-2.2: new full-speed USB device number 29 using uhci_hcd [395089.820689] usb 2-2.2: New USB device found, idVendor=0403, idProduct=f1a0, bcdDevice= 4.00 [395089.820693] usb 2-2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [395089.820694] usb 2-2.2: Product: ASIX PRESTO [395089.820696] usb 2-2.2: Manufacturer: ASIX [395089.820697] usb 2-2.2: SerialNumber: A6013979 OpenOCD --debug Debug: 56 5 presto.c:139 presto_open_libftdi(): searching for PRESTO using libftdi Error: 57 7 presto.c:149 presto_open_libftdi(): unable to open PRESTO: usb_open() failed Error: 58 8 presto.c:540 presto_jtag_init(): Cannot open PRESTO Debug: 59 8 command.c:629 run_command(): Command 'init' failed with error code -100 --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: [PATCH]: bed671d27 openocd: remove last NULL comparisons
Hi Tommy, On Sun, Sep 05, 2021 at 08:45:46PM +, Tommy Murphy wrote: > Doesn't subtle code like that perhaps need an explanatory comment? It's a common enough idiom in C world, no need for additional comments IMHO. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #316 target/stm32h7x.cfg uses "srst_only" by default
Hi Tarek, > are you using a custom board without reset line ? if not could you please > specify the board you are using ? In any case _target_ config shouldn't assume presence of the reset line unless it's unusable without one (and I expect some comment there in that case). --- ** [tickets:#316] target/stm32h7x.cfg uses "srst_only" by default** **Status:** new **Milestone:** 0.11.0 **Created:** Sun Aug 22, 2021 10:03 PM UTC by Fleck **Last Updated:** Sun Aug 29, 2021 08:06 PM UTC **Owner:** nobody target/stm32h7x.cfg uses "srst_only" by default, had to use -c "reset_config none" for upload to work! Debug: 101 1 command.c:146 script_debug(): command - adapter srst delay 100 Debug: 103 1 command.c:146 script_debug(): command - transport select Debug: 104 1 command.c:146 script_debug(): command - reset_config srst_only srst_nogate Debug: 106 1 command.c:146 script_debug(): command - transport select Debug: 107 1 command.c:146 script_debug(): command - stm32h7x.cpu0 configure -event examine-end --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
Re: gerrit reports Merge Conflict, but git thinks branch is up to date
Hey Dietmar, On Tue, Aug 24, 2021 at 05:34:28PM -0400, Dietmar May wrote: > 6477: aarch64: reg cmd w/ force for rd & wr, sync | > https://review.openocd.org/c/openocd/+/6477 > > There's a big red Merge Conflict badge, which states "This change has merge > conflicts. Download the patch and run git rebase". Don't worry. Default merge strategy in OpenOCD Gerrit instance is "cherry-pick" so it doesn't consider other patches in the chain when checking if it can be merged. Of course the maintainers will take care to do it in the right order when submitting. > All commits compile successfully under jenkins. Then it's all fine. Thank you for contributing! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: wiki for merging gerrit changes for jenkins failures on patches
Hello, On Tue, Aug 24, 2021 at 12:38:35PM -0400, Dietmar May wrote: > So it looks like the correct way to handle multiple patches is to create a > separate local branch for each independent patchset Yes. > Is there a simpler, or better, strategy? Yes, "git rebase -i origin/master" will let you edit any patch in the series. Please tell if this works for you. > PS. I would suggest also updating the patch guide wording: ... Thank you, will look into that. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: Planned Gerrit maintenance
On Sat, Aug 21, 2021 at 10:24:21AM +0300, Paul Fertser wrote: > I'll send an additional announcement when the system is running again. OK, we've been testing the new system for many hours by now and it seems ready enough for prime-time, no looking back :) It's a major version upgrade which comes with a completely new UI, I hope that's for the good. One essential note: please remember to always _link_ your additional identities rather than trying to log in with another provider right away. The linking procedure is as follows: 1. Sign In with your _existing_ account (can be OpenID or any of the enabled OAuth providers) 2. Edit the URL to read https://review.openocd.org/login/?link (sorry, the new UI lacks the button due to a bug I believe, working on it) 3. In the new Sign In prompt select another provider you want to add. Failing to do so might lead to duplicated accounts, in this case you'll have to contact me via IRC or e-mail for manual account merging procedure. Regarding the supported authentication providers: - OpenID should work with any service still operating - Google OAuth and Github OAuth work as before - Bitbucket will likely not work due to an upstream bug I also see the plugin offers configuration for the following entities: CAS Facebook GitLab LemonLDAP Dex Keycloak Azure AirVantage Phabricator If you need one of those, please speak up; enabling support is not exactly fast, it requires registering a project with them, so we'll do it on request. Another new feature is that you can now reply by e-mail to comments, see https://gerrit-review.googlesource.com/Documentation/intro-user.html#reply-by-email for details. Take care to send your reply to ger...@openocd.org , ignoring the reply-to header Gerrit inserts automatically. I also tested an apparently very powerful colourful full-screen console application for comfortably working on reviews even when your Internet connection is sporadic or web-browser misbehaves: meet Gertty https://opendev.org/ttygroup/gertty#repo-readme . It's likely already available in your distro repository but if you want the latest version it can run nicely in Python virtualenv without affecting the rest of the system. This config file should be enough to get started: servers: - name: OpenOCD url: https://review.openocd.org username: CHANGE password: CHANGE auth-type: basic git-root: ~/.local/gertty/git/ diff-view: unified If you do not know your HTTP password, generate a new one in the Gerrit settings. Of course, such a major upgrade can't be 100 % smooth, so if you notice any issues, please talk to me, and we'll try to sort it all out. Thank you! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com signature.asc Description: PGP signature
Planned Gerrit maintenance
Hello, In about 24 hours from now, starting Sunday morning UTC please expect some downtime as we would be going through a major Gerrit upgrade. Testing migration showed promising results, all data and accounts were transferred smoothly. There is some chance Google OAuth will be broken for a while, but nothing that can't be fixed later manually so please do not hesitate to contact me on IRC or by mail if you have any problems. I'll send an additional announcement when the system is running again. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com signature.asc Description: PGP signature
Re: Support for Efm32 series 2 microcontrollers
On Thu, Aug 12, 2021 at 10:53:58AM +0200, Daniel Kowalski wrote: > Do I have to download the patch from the web, fix it up (does not apply > cleanly > to master) and work from here? The gerrit web interface has a "Download" link where you can see full git fetch command. You just run it and then checkout FETCH_HEAD and you get exactly what was pushed that way. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] #313 Website Compromised
- **status**: new --> closed
- **Comment**:
Thank you! Should be fixed by migrating to Pelican now.
---
** [tickets:#313] Website Compromised**
**Status:** closed
**Milestone:** 0.10.0
**Created:** Tue Aug 03, 2021 12:36 AM UTC by Sean Bruton
**Last Updated:** Tue Aug 03, 2021 12:36 AM UTC
**Owner:** nobody
Looks like your website was compromised. Someone has injected the following
into the HTML returned on /getting-openocd/
~~~
window.location.replace("https://REDACTED_FOR_SECURITY.tk/help/?15131619432237";);window.location.href
= "https://REDACTED_FOR_SECURITY.tk/help/?15131619432237";;http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
~~~
to reproduce:
~~~
$ echo -ne "GET /getting-openocd/ HTTP/1.1\nHost: openocd.org\n\n" | nc
openocd.org 80 | head -n 20
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 03 Aug 2021 00:34:49 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Vary: Host
X-Pingback: http://openocd.org/web/xmlrpc.php
Set-Cookie: ht_rr=1; expires=Wed, 04-Aug-2021 00:34:44 GMT; path=/
Cache-Control: max-age=3600
Expires: Tue, 03 Aug 2021 01:34:42 GMT
X-From: sfp-web-3
Vary: Accept-Encoding
ce1
window.location.replace("https://REDACTED_FOR_SECURITY.tk/help/?15131619432237";);window.location.href
= "https://REDACTED_FOR_SECURITY.tk/help/?15131619432237";;http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
http://www.w3.org/1999/xhtml; dir="ltr" lang="en-US">
http://gmpg.org/xfn/11;>
~~~
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
Re: [openocd:tickets] Re: #313 Website Compromised
On Tue, Aug 03, 2021 at 09:47:57AM +0200, Michael Schwingen wrote: > On Tue, Aug 03, 2021 at 06:53:30AM -0000, Paul Fertser wrote: > > On Tue, Aug 03, 2021 at 12:40:00AM -, sbru...@users.sourceforge.net > > wrote: > > > just opened ticket #313, looks like someone managed to compromise the > > > openocd.org website > > > > Thank you for reporting. I wonder if it's SF.net compromise because > > apparently it "resolved itself" and now the page is clean again? > > No, it's definitely not. Also, the malicious script seems to be inserted on > the start page (and probably any page), not only on "/getting-openocd": Indeed, I see it now. Somehow viewing source with chromium wasn't showing it either. Thank you!. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #313 Website Compromised
Hello,
On Tue, Aug 03, 2021 at 12:40:00AM -, sbru...@users.sourceforge.net wrote:
> just opened ticket #313, looks like someone managed to compromise the
> openocd.org website
Thank you for reporting. I wonder if it's SF.net compromise because
apparently it "resolved itself" and now the page is clean again?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
---
** [tickets:#313] Website Compromised**
**Status:** new
**Milestone:** 0.10.0
**Created:** Tue Aug 03, 2021 12:36 AM UTC by Sean Bruton
**Last Updated:** Tue Aug 03, 2021 12:36 AM UTC
**Owner:** nobody
Looks like your website was compromised. Someone has injected the following
into the HTML returned on /getting-openocd/
~~~
window.location.replace("https://REDACTED_FOR_SECURITY.tk/help/?15131619432237";);window.location.href
= "https://REDACTED_FOR_SECURITY.tk/help/?15131619432237";;http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
~~~
to reproduce:
~~~
$ echo -ne "GET /getting-openocd/ HTTP/1.1\nHost: openocd.org\n\n" | nc
openocd.org 80 | head -n 20
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 03 Aug 2021 00:34:49 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Vary: Host
X-Pingback: http://openocd.org/web/xmlrpc.php
Set-Cookie: ht_rr=1; expires=Wed, 04-Aug-2021 00:34:44 GMT; path=/
Cache-Control: max-age=3600
Expires: Tue, 03 Aug 2021 01:34:42 GMT
X-From: sfp-web-3
Vary: Accept-Encoding
ce1
window.location.replace("https://REDACTED_FOR_SECURITY.tk/help/?15131619432237";);window.location.href
= "https://REDACTED_FOR_SECURITY.tk/help/?15131619432237";;http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd;>
http://www.w3.org/1999/xhtml; dir="ltr" lang="en-US">
http://gmpg.org/xfn/11;>
~~~
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
Re: config file addition query
Hi, On Mon, Jul 12, 2021 at 04:45:53PM +, Ranjith TC wrote: > I would like to add my board config file to the OpenOCD repo. > > What is the procedure to follow? Please see HACKING in the source code. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
[openocd:tickets] Re: #310 at32f403
Hello, On Wed, Jul 07, 2021 at 12:53:20AM -, Bruno Pimenta de Oliveira wrote: > I'm trying to reprogram my board which has at32f403 chip but after install > openocd and st link it does't recognize the board. Do you think it's an OpenOCD bug? For support requests please use the mailing list or IRC. I also do not see any log attached, so "doesn't recognise" is too vague to suggest anything. > I'm following the steps of the github below, and also add some code in the > src/flash/nor/stm32f1x.c > with: > > case 0x242: / AT32F403 / > page_size = 2048; > stm32x_info->ppage_size = 2; > max_flash_size_in_kb = 512; > break; If this is known to work why not send as a patch upstream so that it can be included in all future versions? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#310] at32f403** **Status:** new **Milestone:** 0.10.0 **Created:** Wed Jul 07, 2021 12:53 AM UTC by Bruno Pimenta de Oliveira **Last Updated:** Wed Jul 07, 2021 12:53 AM UTC **Owner:** nobody Hello everyone, I'm trying to reprogram my board which has at32f403 chip but after install openocd and st link it does't recognize the board. I'm following the steps of the github below, and also add some code in the src/flash/nor/stm32f1x.c with: case 0x242: /* AT32F403 */ page_size = 2048; stm32x_info->ppage_size = 2; max_flash_size_in_kb = 512; break; https://github.com/cloidnerux/hoverboard-firmware-hack anyone can help me undestard the steps? --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
OpenOCD-devel mailing list configuration changes to handle DMARC
Hi All, Prompted by the recent discussion on the sigrok mailing list and two mails in a row where Mailman had to munge From I reconfigured the OpenOCD-devel mailing list to handle this in a way that seems to be better. In short: the mailing list no longer changes Subject and Body of the mails and so DKIM checks for the messages it redistributes shouldn't fail even without From munging or message wrapping. Theory is explained at [0] and specific mailman 2 advice (SF.net is using 2.1.21) is taken from [1]. I wasn't able to set dmarc_moderation_action to Accept as the server config prevents it. I'll try to open a ticket with SF.net support about that. Please complain if you spot any issues with the new config. [0] https://begriffs.com/posts/2018-09-18-dmarc-mailing-list.html [1] https://seanthegeek.net/459/demystifying-dmarc/ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com
Re: [OpenOCD-devel] Missing email notification on watched OpenOCD project
Hi Daniel, On Mon, Mar 29, 2021 at 12:52:54PM -0400, Daniel Goehring via OpenOCD-devel wrote: > After upstreaming patches to the OpenOCD code review server, I don't receive > email notifications for any patch activity. I've been resorting to manually > checking the review server for activity. Under "Settings -> Watched > Projects", for the 'openocd' project, all boxes are checked for email > notifications. Under "Settings -> Contact Information" and "Settings -> > Profile" the email address is correct. Even then I still do not receive > email notifications for code review activity on patches I submit or any > patch activity. What am I missing? I'll be checking the Gerrit logs today. Is this the same email address you were using there? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Cannot log into Gerrit with Yahoo OpenID
Hi! On Mon, Mar 29, 2021 at 08:11:07PM +0200, R. Diez via OpenOCD-devel wrote: > The trouble is, I cannot log into Gerrit anymore with my Yahoo OpenID. I > think that Yahoo wants OpenID users (that would probably by the Gerrit > server) to upgrade to some new OpenID version. If you can not log in with any of the methods you used before you can create a new account and then tell me information about all old accounts and the new one and I'll merge them manually (you can contact me on IRC too). > Is this a known problem? No, not really. > By the way, I find that OpenID login method problematic. I would > rather create a separate account for Gerrit, like everywhere else. Does the latest Gerrit version allow to self-host an authentication database? We're planning an upgrade soon. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] OpenOCD 0.11.0 released
Documentation: * Improve STM32 flash driver * Various typo fix and improvements Build and Release: * Add libutil to support jimtcl version 0.80 * Clang warning fixes * GitHub workflow for Win32 snapshot binaries * Handle Tcl return values consistently * Mitigation for CVE-2018-5704: Prevent some forms of Cross Protocol Scripting attacks * Support for libftdi 1.5 * Travis-CI basic support * Update libjaylink to version 0.2.0 * Update jimtcl to version 0.79 * Use external (optional) library capstone for ARM and AARCH64 disassembly This release also contains a number of other important functional and cosmetic bugfixes. For more details about what has changed since the last release, see the git repository history: http://sourceforge.net/p/openocd/code/ci/v0.11.0/log/?path= Hooray for the developers! 392 Antonio Borneo 189 Tomas Vanek 135 Marc Schink 120 Matthias Welwarsky 85 Paul Fertser 74 Tarek BOCHKATI 47 Christopher Head 31 Marek Vasut 28 Oleksij Rempel 21 Tim Newsome 20 Edward Fewell 17 Salvador Arroyo 15 Andreas Fritiofson 15 Steven Stallion 14 Karl Palsson 14 Leonard Crestez 13 Evgeniy Didin 11 Jiri Kastner 10 Bohdan Tymkiv 10 Robert Jordens 9 Omair Javaid 8 Ake Rehnman 8 Moritz Fischer 7 Andreas Färber 7 David Ung 7 Florian Fainelli 6 Andreas Bolsch 6 Felipe Balbi 6 Jan Matyas 5 Hellosun Wu 5 Jonathan McDowell 4 Cody P Schafer 4 Jonas Norling 4 Laurent LEMELE 4 Liviu Ionescu 4 Peter Mamonov 4 Spencer Oliver 3 Alistair Francis 3 Armin van der Togt 3 Aurélien Martin 3 Diego Herranz 3 Dominik Peklo 3 Girts 3 Jan Kowalewski 3 Jean-Christian de Rivaz 3 Kevin Gillespie 3 Kevin Yang 3 Liming Sun 3 Mete Balci 3 Peter Lawrence 3 Slowcoder 3 Yasushi SHOJI 2 Adam Bass 2 Adrian Negreanu 2 Alexandre Torgue 2 Alexandru Gagniuc 2 Bas Vermeulen 2 Cody Schafer 2 Darius Rad 2 Forest Crossman 2 Freddie Chopin 2 Girts Folkmanis 2 Guido Günther 2 Jerome Forissier 2 Joakim Nohlgård 2 John Pham 2 Juha Niskanen 2 Kai Geissdoerfer 2 Kevin Burke 2 Khem Raj 2 Lars Poeschel 2 Michele Sardo 2 Mikhail Rasputin 2 Mirko Vogt 2 Piotr Kasprzyk 2 R. Diez 2 Seth LaForge 2 William D. Jones 2 luca vinci 2 pierre Kuo 2 tscn92 1 Al Dyrius 1 Alberto García Hierro 1 Aleksey Shargalin 1 Alex J Lennon 1 Alexander Kurz 1 Alexandre Bourdiol 1 Alexey Brodkin 1 Anders Westrup 1 Andrea Merello 1 Andreas Kemnade 1 Angus Ainslie 1 Anton V. Kirilchik 1 Antony Pavlov 1 Austin Morton 1 Austin Phillips 1 Benedikt-Alexander Mokroß 1 Boran Car 1 Brent Roman 1 Brian Brooks 1 Byron Kubert 1 Caleb Szalacinski 1 CezaryGapinski 1 Chengyu Zheng 1 Christian Meusel 1 Christopher Hoover 1 Cliff L. Biffle 1 Damyan Mitev 1 Daniel Glöckner 1 Daniel Goehring 1 Daniel Krebs 1 Daniel Kucera 1 Daniel Trnka 1 Dennis Ostermann 1 Diego Elio Pettenò 1 Dongxue Zhang 1 EMARD 1 Erwin Oegema 1 Evan Hunter 1 Fabio Utzig 1 Faisal Shah 1 Frank Hunleth 1 Frans-Willem Hardijzer 1 Grzegorz Kostka 1 Guillaume Revaillot 1 Han Hartgers 1 Icenowy Zheng 1 Ilya Kharin 1 James Jacobsson 1 James Marshall 1 Jan Vojtech 1 Jan Čapek 1 Jerome Lambourg 1 Jim Paris 1 Jimmy 1 Jānis Skujenieks 1 Kamal Dasu 1 Keir Fraser 1 Kevin Vermilion 1 Krzysztof Hockuba 1 Luca Dariz 1 Luca Lindhorst 1 Lucas 1 Mara Bos 1 Masatoshi Tateishi 1 Matej Kogovsek 1 Mateusz Manowiecki 1 Matthias Bock 1 Megan Wachs 1 Michael Betz 1 Michael Hope 1 Michael Schwingen 1 Michael Stoll 1 Michal Potrzebicz 1 Mickaël Thomas 1 Moritz 'Morty' Strübe 1 Niklas Söderlund 1 Oleksandr Redchuk 1 Patrick Stewart 1 Paul Bartholomew 1 Peter Griffin 1 Philipp Tomsich 1 Pushpal Sidhu 1 Rahul Masurkar 1 Reto Schneider 1 Richard Watts 1 Robert Foss 1 Rocco Marco Guglielmi 1 Rod Boyce 1 Rohit Singh 1 Roman Elshin 1 Samuel Obuch 1 Sasha Kozaruk 1 Severin Junker 1 Simon Qian 1 Simon Schubert 1 Stafford Horne 1 Stefan Arnold 1 Svetoslav Enchev 1 Sylvain Chouleur 1 Tarek BOUCHKATI 1 Thomas Søhus
Re: [OpenOCD-devel] Speeding up HOST to JLink debugger exchange
Hi Alexander, On Fri, Mar 05, 2021 at 01:52:55PM +0300, Alexander Gabitov via OpenOCD-devel wrote: > This is the common mistake! Unsigned types was added for another reason to > standart. But than their sense was perverted and many programmers start use > them > for values that cant be negative. But C standart has integer promoution — all > arifmetics usually done in int. Just try to change it back to unsigned (in > this > function) and you will need several type casts. How about size_t type then? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] [OpenOCD-user] The next OpenOCD release is near, get ready
Hey Tim, On Wed, Feb 10, 2021 at 10:18:02AM -0800, Tim Newsome wrote: > What's the status of this release? I've put on hold upstreaming some more > changes from the RISC-V fork because it didn't seem worth potentially > destabilizing a release for. But it's been a long time now, and I don't want > my > fork to drift too far off mainline if I can help it. I think Antonio plans final in the coming few weeks, rc2 got no serious issues apparently. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [openocd:tickets] Re: #293 STM8 program command fails with "invalid subcommand write_image erase.."
On Sat, Jan 16, 2021 at 09:28:12PM -, Maximilian Gerhardt wrote:
> openocd -f interface\stlink-dap.cfg -f target\stm8s103.cfg -c "load_image
> {C:\Users\Max\Documents\PlatformIO\Projects\stm8_testing\.pio\build\stm8sblue\firmware.bin}
> 0x8000"
Just add "init; reset halt; " before load_image
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
---
** [tickets:#293] STM8 program command fails with "invalid subcommand
write_image erase.."**
**Status:** new
**Milestone:** 0.10.0
**Labels:** stm8 flashing
**Created:** Sat Jan 16, 2021 05:37 PM UTC by Maximilian Gerhardt
**Last Updated:** Sat Jan 16, 2021 09:38 PM UTC
**Owner:** nobody
**Attachments:**
-
[firmware.bin](https://sourceforge.net/p/openocd/tickets/293/attachment/firmware.bin)
(2.6 kB; application/octet-stream)
-
[firmware.ihx](https://sourceforge.net/p/openocd/tickets/293/attachment/firmware.ihx)
(6.3 kB; application/octet-stream)
Using PlatformIO I've generated a blinky firmware for an STM8S (firmware in
intelhex format attached).
I can also flash the target file using https://github.com/vdudouyt/stm8flash
~~~
stm8flash.exe -c stlinkv21 -u -p stm8s103?3 -c stlinkv2 -s flash -w
"C:\Users\Max\Documents\PlatformIO\Projects\stm8_testing\.pio\build\stm8sblue\firmware.ihx"
Determine FLASH area
libusb: error [init_device] device
'\\.\USB#VID_062A_5918_01#9&1953ACC1&0&0001' is no longer connected!
Due to its file extension (or lack thereof),
"C:\Users\Max\Documents\PlatformIO\Projects\stm8_testing\.pio\build\stm8sblue\firmware.ihx"
is considered as INTEL HEX format!
2576 bytes at 0x8000... OK
Bytes written: 2576
~~~
And it runs fine. Using OpenOCD, I can connect to the chip
~~~
>C:\Users\Max\.platformio\packages/tool-openocd/bin/openocd -f
>interface\stlink-dap.cfg -f target\stm8s103.cfg
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df
(2020-06-26-09:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
Info : Listening on port for tcl connections
Info : Listening on port for telnet connections
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.253616
Info : clock speed 800 kHz
Info : starting gdb server for stm8s.cpu on
Info : Listening on port for gdb connections
target halted due to undefined, pc: 0x8000
~~~
However I cannot get OpenOCD to program the target chip. Using the command
~~~
>C:\Users\Max\Downloads\xpack-openocd-0.10.0-15\bin\openocd -f
>interface\stlink-dap.cfg -f target\stm8s103.cfg -c "program
>{C:\Users\Max\Documents\PlatformIO\Projects\stm8_testing\.pio\build\stm8sblue\firmware.ihx}
> verify reset exit"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020-10-13-17:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.253616
Info : clock speed 800 kHz
Info : starting gdb server for stm8s.cpu on
Info : Listening on port for gdb connections
target halted due to debug-request, pc: 0x8000
** Programming Started **
flash
flash bank bank_id driver_name base_address size_bytes chip_width_bytes
bus_width_bytes target [driver_options ...]
flash banks
flash init
flash list
gdb_flash_program ('enable'|'disable')
nand
program [address] [pre-verify] [verify] [reset] [exit]
stm8 enable_stm8l [1/0]
stm8s.cpu stm8 enable_stm8l [1/0]
Error: invalid subcommand "write_image erase
C:\Users\Max\Documents\PlatformIO\Projects\stm8_testing\.pio\build\stm8sblue\firmware.ihx"
** Programming Failed **
shutdown command invoked
embedded:startup.tcl:583: Error:
at file "embedded:startup.tcl", line 583
~~~
Also doesn't work with the `.elf` or `.bin` versions of the firmware.
~~~
>C:\Users\Max\Downloads\xpack-openocd-0.10.0-15\bin\openocd -f
>interface\stlink-dap.cfg -f target\stm8s103.cfg -c "program
>{C:\Users\Max\Documents\PlatformIO\Projects\stm8_testing\.pio\build\stm8sblue\firmware.bin}
> 0x8000 verify reset exit"
xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020-10-13-17:29)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
srst_only separate srst_gates_jtag srst_open_drain connect_deassert_srst
Info : STLINK V2J37S7 (API v2) VID:PID 0483:3748
Info : Target voltage: 3.253616
Info : clock speed 800 kHz
Info : starting gdb server for stm8s.cpu on
Info : Listening on port for gdb connections
target halted due to debug-request, pc: 0x8000
** Programming Started **
flash
flash bank bank_id driver_name base_address size_bytes chip_width_bytes
bus_width_bytes target [driver_options ...]
flash banks
flash init
flash list
gdb_flash_program
Re: [OpenOCD-devel] Texinfo issues on master
On Mon, Jan 11, 2021 at 12:07:00PM -0600, Steven Stallion wrote: > It's more insidious than that actually - it looks like mac OS packages texinfo > 4.8, which is getting quite long in the tooth. It might just be a matter of > updating documentation to suggest users install mactex via brew or similar. Hm, if raggedright is the only real issue probably we can get back to hardcoding it inside the file, I just thought it's about time to get rid of that given no current GNU/Linux distro ships anything _that_ old. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Texinfo issues on master
On Mon, Jan 11, 2021 at 06:49:25PM +0100, Antonio Borneo wrote: > > On Mon, Jan 11, 2021 at 6:21 PM Steven Stallion via OpenOCD-devel > > wrote: > > > > > > All, > > > > > > I've recently updated to master to double check the state of mac OS > > > builds before the release is cut. I'm seeing several errors that are > > > breaking the build on Catalina - I was curious if anyone else has seen > > > this before I dig into a fix: > > > > > > ./doc/openocd.texi:10182: warning: `.' or `,' must follow @xref, not `c'. > > > ./doc/openocd.texi:10921: Unknown command `raggedright'. > > > > this 'raggedright' is in a very recent commit, but no error on my side. > > Apparently we already met this issue: > http://openocd.zylin.com/2781 My guess is that Steven installed Homebrew long time ago and didn't update Texinfo since then. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] The first Release Candidate for 0.11.0
Hello, Thanks to the concentrated efforts the project is getting closer to the new release, and the first release candidate has been tagged (v0.11.0-rc1). The source code archives are available from the usual location and the documentation on the web site updated. The purpose of the release candidate is getting wider testing to weed out the bugs, and especially regressions so please give it a good spin and report all the surfacing issues. I know Debian and Fedora maintainers are already updating the packages in their distros, and I hope the others will follow. The OpenOCD team is committed to making your lifes easier, so do not hesitate complaining about any packaging issues you face. Please consider adding "libgpiod" as a new dependency on all supported platforms as that not only allows using GPIO bitbanging for JTAG and SWD on SoCs but also works for some generic USB devices (DLN-2, CP210x, FTX, I guess more to come). This release renames some commands to provide a more consistent UI, but the old commands will still be available for a while. There's also a change that breaks compatibility with some scripts, specifically, the removal of "ocd_" prefix resulting from a grand clean-up of the command handling infrastructure and some other more minor changes to the way command results are presented. So if you do any fancy scripting or control OpenOCD via RPC, please do not be too surprised or disappointed, the clean-up was for the good :) That said, please feel free to report if your usecase is somehow made problematic by the new way, nothing is set in stone. Copy of the NEWS follows. This file includes highlights of the changes made in the OpenOCD source archive release. JTAG Layer: * add debug level 4 for verbose I/O debug * bitbang, add read buffer to improve performance * Cadence SystemVerilog Direct Programming Interface (DPI) adapter driver * CMSIS-DAP v2 (USB bulk based) adapter driver * Cypress KitProg adapter driver * FTDI FT232R sync bitbang adapter driver * Linux GPIOD bitbang adapter driver through libgpiod * Mellanox rshim USB or PCIe adapter driver * Nuvoton Nu-Link and Nu-Link2 adapter drivers * NXP IMX GPIO mmap based adapter driver * ST-Link consolidate all versions in single config * ST-Link read properly old USB serial numbers * STLink/V3 support (for ST devices only !) * STM8 SWIM transport * TI XDS110 adapter driver * Xilinx XVC/PCIe adapter driver Boundary Scan: Target Layer: * 64 bit address support * ARCv2 target support * ARM Cortex-A hypervisor mode support * ARM Cortex-M fast PC sampling support for profiling * ARM generic CTI support * ARM generic mem-ap target support * ARMv7-A MMU tools * ARMv7m traces add TCP stream server * ARMv8 AARCH64 target support and semihosting support * ARMv8 AARCH64 disassembler support through capstone library * ARMv8-M target support * EnSilica eSi-RISC target support, including instruction tracing eSi-Trace support * MIPS64 target support * Motorola SREC S6 record image file support * RISC-V target support * SEGGER Real Time Transfer (RTT) initial support (for single target, Cortex-M only) * ST STM8 target support * Various MIPS32 target improvements Flash Layer: * Atheros (ath79) SPI interface support * Atmel atmega128rfa1 support * Atmel SAM D21, D51, DA1, E51, E53, E54, G55, R30 support * Atmel SAMC2?N* support * Cypress PSoC5LP, PSoC6 support * EnSilica eSi-RISC support * Foshan Synwit Tech SWM050 support * Maxim Integrated MAX32XXX support * Nordic Semiconductor nRF51822, nRF52810, nRF52832 support * NXP Kinetis K27, K28, KE1x, KEAx, KL28, KL8x, KV5x, KWx support * Renesas RPC HF support * SH QSPI support * SiFive Freedom E support * Silicon Labs EFR-family, EZR32HG support * ST BlueNRG support * ST STM32 QUAD/OCTO-SPI interface support for Flash, FRAM and EEPROM * ST STM32F72x, STM32F4x3, STM32H7xx support * ST STM32G0xx, STM32G4xx, STM32L4x, STM32WB, STM32WL support * ST STM32L5x support (non secure mode) * TI CC13xx, CC26xx, CC32xx support * TI MSP432 support * Winner Micro w600 support * Xilinx XCF platform support * Various discrete SPI NOR flashes support Board, Target, and Interface Configuration Scripts: * 8devices LIMA board config * Achilles Instant-Development Kit Arria 10 board config * Amazon Kindle 2 and DX board config * Analog Devices ADSP-SC58x, ADSP-SC584-EZBRD board config * Andes Technology ADP-XC7KFF676 board config * Andes Technology Corvette-F1 board config * ARM Musca A board
Re: [OpenOCD-devel] make error in function ‘riscv013_test_sba_config_reg’
Hi Tommy, On Thu, Dec 10, 2020 at 08:05:28AM +, Tommy Murphy wrote: > Not sure why you seem to be reacting with such passive aggression to what was > simply some well intentioned suggestions. FWIW, I do not see any kind of aggression in what Andreas has written, he's just stating the facts AFAICT. Please take it easy. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Query regarding LLVM tool chain
On Fri, Dec 04, 2020 at 02:28:22PM +0530, Rahul Gupta wrote: > getting error in launching "Could not determine GDB version after sending > lldb.exe --version" So it's an error produced by the "HW Debugging" Eclipse plugin telling you that it doesn't know how to deal with LLDB. Seems to be totally unrelated to OpenOCD. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Query regarding LLVM tool chain
Hi, On Fri, Dec 04, 2020 at 12:58:17PM +0530, Rahul Gupta wrote: > Does open ocd support only GNU tool chain or it has support for LLVM tool > chain > also? > if OpenOcd has support for LLVM tool chain also then please comment how to > specify that in eclipse? Please clarify what kind of support you have in mind, I can't see how OpenOCD has anything to do with a toolchain. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [openocd:tickets] Re: #286 Deprecated warnings with libftdi 1.5
On Tue, Oct 27, 2020 at 10:38:10PM -, Antonio Borneo wrote:
> At a first check, seams enough replacing ftdi_usb_purge_buffers() with
> ftdi_tcioflush().
> The prototype of the functions is exactly the same, so simply run
> sed -i s/ftdi_usb_purge_buffers/ftdi_usb_purge_buffers/
> src/jtag/drivers/{openjtag.c,presto.c}
I guess you meant
sed -i s/ftdi_usb_purge_buffers/ftdi_tcioflush/
src/jtag/drivers/{openjtag.c,presto.c}
> The difficoult part now is to make 'configure' able to detect the current
> version of libftdi1 and force using one of the two API.
Probably change the .c code to use ftdi_tcioflush and add an
appropriate macro to replace it with the old function name when
pkg-config reports an older libftdi is used.
---
** [tickets:#286] Deprecated warnings with libftdi 1.5**
**Status:** new
**Milestone:** 0.10.0
**Created:** Tue Oct 27, 2020 04:12 PM UTC by MrLavender
**Last Updated:** Tue Oct 27, 2020 11:01 PM UTC
**Owner:** nobody
The build fails with libftdi 1.5 because of deprecated warnings and -Werror.
I'm sorry I don't have time to investigate further, I just worked around it
using `CFLAGS="-g -O2 -Wno-deprecated"` with `configure`.
```
src/jtag/drivers/presto.c:163:6: error: 'ftdi_usb_purge_buffers' is deprecated
[-Werror,-Wdeprecated-declarations]
if (ftdi_usb_purge_buffers(>ftdic) < 0) {
^
/usr/local/Cellar/libftdi/1.5/include/libftdi1/ftdi.h:566:9: note:
'ftdi_usb_purge_buffers' has been explicitly marked deprecated here
int DEPRECATED(ftdi_usb_purge_buffers(struct ftdi_context *ftdi));
^
/usr/local/Cellar/libftdi/1.5/include/libftdi1/ftdi.h:247:42: note: expanded
from macro 'DEPRECATED'
#define DEPRECATED(func) __attribute__ ((deprecated)) func
^
src/jtag/drivers/presto.c:177:7: error: 'ftdi_usb_purge_buffers' is deprecated
[-Werror,-Wdeprecated-declarations]
if (ftdi_usb_purge_buffers(>ftdic) < 0)
^
/usr/local/Cellar/libftdi/1.5/include/libftdi1/ftdi.h:566:9: note:
'ftdi_usb_purge_buffers' has been explicitly marked deprecated here
int DEPRECATED(ftdi_usb_purge_buffers(struct ftdi_context *ftdi));
^
/usr/local/Cellar/libftdi/1.5/include/libftdi1/ftdi.h:247:42: note: expanded
from macro 'DEPRECATED'
#define DEPRECATED(func) __attribute__ ((deprecated)) func
^
2 errors generated.
```
---
Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/openocd/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Offer for website
On Sat, Oct 24, 2020 at 03:40:30PM +0200, kristof.mul...@telenet.be wrote: > I think I get the point now. You are blocking javascript, > are you? Of course I am. I guess we just have to disagree there. I want to have access to structured information with semantic markup with hyperlinks, not to turn my computer into an inefficient thin client running a VM with some code controlled by the remote party. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Offer for website
On Sat, Oct 24, 2020 at 03:37:48PM +0200, kristof.mul...@telenet.be wrote: > I don't understand the message you want to convey > with your screenshot. It looks like the website > fails to load in your browser, right? I'm not sure if "fails to load" would be the accurate description but the fact is the result seems to be unusable. > I don't know when you took this screenshot. Just prior to posting. It looks exactly the same right at the moment. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Offer for website
On Sat, Oct 24, 2020 at 03:16:39PM +0200, kristof.mul...@telenet.be wrote: > "https is not a problem, thanks to letsencrypt. I can > set it up (for free) if it is hosted on my server. All > they would need to do is point a DNS record for their > domain (or a subdomain like new.openocd.org to experiment) > to my server at 213.136.92.230" Currently the website is hosted on SF.net. It's certainly less stable than we'd like it to, but probably not too bad. SF.net allows us to use HTTPS, just nobody bothered with it yet. I'm not sure what's better: to self-host the website or to let it stay at SF.net but I would prefer to not depend on Embeetle company for hosting because I'm afraid it might complicate things in the long run. Just my personal opinion. Another thing to decide would be what exactly OpenOCD project needs a website for. Current one allows to share the news, including links to success stories or interesting related conference talks. Current one allows to host a copy of online documentation. What else is needed? > a zoom/skype meeting ... -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Offer for website
Hey Kristof, On Fri, Oct 23, 2020 at 01:07:57PM +0200, kristof.mul...@telenet.be wrote: > My colleague Johan designed a simple, elegant javascript-css skeleton > that we based our website on: > [1]https://embeetle.com I'm attaching a screenshot and that fully expresses my personal opinion about this idea. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] The next OpenOCD release is near, get ready
Hello, Thanks to the massive efforts of the developers and maintainers involved (and I would like to specifically mention Antonio Borneo here) we seem to have gained enough momentum to be able to make another OpenOCD release pretty soon. If everything goes according to the plan, the first release candidate will be tagged in about three weeks. After that we aim to concentrate on fixing whatever would need to get fixed, so do not expect new features to get merged during the RC stages (but they still might be reviewed). When all the known problems are taken care of, we'll tag the second release candidate, and this process should be repeated for as long as there're issues to solve. If we are lucky, the final version will be ready by the end of December. So if you have some particular changes you want to see included please speak up now, and help with testing and reviewing. If you have any issues with Gerrit or other development infrastructure components, please feel free to contact me on IRC or by e-mail. To distro maintainers: if you think we can make your lifes easier, please tell us how (other than producing the releases more often and regularly), we aim for the build process to be as easy as possible for everybody. Let's get rolling! Please continue the discussion on the -devel mailing list. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com signature.asc Description: PGP signature ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] openOCD build for ARM core
Hi, On Fri, Oct 16, 2020 at 10:39:02AM +, Vimal Varghese wrote: > Is there any openOCD source code build available to make an ARM core(cortex -A > core) executable openOCD binary. OpenOCD should run on anything where GNU/Linux or *BSD runs. Of course it includes plenty of Cortex-A based SoCs, and I'm using one right atm. So what is your question really? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [openocd:tickets] Re: #280 stlink-v2 not working with bcm2835 raspberry pi
On Thu, Oct 15, 2020 at 04:25:48PM -, Christian Tenllado wrote: > Thank you a lot Antonio for the information, I have to find an alternative > debugger then. Another raspberry pi would work as an alternative debugger by jtag bitbanging. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#280] stlink-v2 not working with bcm2835 raspberry pi** **Status:** new **Milestone:** 0.9.0 **Created:** Thu Oct 15, 2020 02:42 PM UTC by Christian Tenllado **Last Updated:** Thu Oct 15, 2020 04:25 PM UTC **Owner:** nobody Hi: I am trying to use a stlink-v2 to debug a raspberry pi (bcm2835) using jtag, but I am not succeding. I have tryied with two transports, hla and dapdirect, and each of them is giving me different problems. Using the openocd snapshot from debian unstable (from 2020-08-19). The commands I use to connect and the debug output from openocd are the following: - Using hla: $ openocd -d3 -f interface/stlink-v2.cfg -c "transport select hla_jtag" -c "adapter speed 100" -c "hla newtap raspi arm -irlen 5 -expected-id 0x07b7617F" -c "target create raspi.arm arm11 -chain-position raspi.arm" Open On-Chip Debugger 0.10.0+dev-snapshot (2020-10-14-11:42) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html User : 13 5 options.c:63 configuration_output_handler(): debug_level: 3 User : 14 5 options.c:63 configuration_output_handler(): Debug: 15 5 options.c:187 add_default_dirs(): bindir=/usr/bin Debug: 16 5 options.c:188 add_default_dirs(): pkgdatadir=/usr/share/openocd Debug: 17 5 options.c:189 add_default_dirs(): exepath=/usr/bin Debug: 18 5 options.c:190 add_default_dirs(): bin2data=../share/openocd Debug: 19 5 configuration.c:42 add_script_search_dir(): adding /home/christian/.openocd Debug: 20 5 configuration.c:42 add_script_search_dir(): adding /usr/bin/../share/openocd/site Debug: 21 5 configuration.c:42 add_script_search_dir(): adding /usr/bin/../share/openocd/scripts Debug: 22 6 configuration.c:97 find_file(): found /usr/bin/../share/openocd/scripts/interface/stlink-v2.cfg Debug: 23 6 command.c:146 script_debug(): command - echo WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg User : 25 6 command.c:767 jim_echo(): WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg Debug: 26 6 configuration.c:97 find_file(): found /usr/bin/../share/openocd/scripts/interface/stlink.cfg Debug: 27 6 command.c:146 script_debug(): command - adapter driver hla Debug: 29 6 command.c:352 register_command_handler(): registering 'hla_device_desc'... Debug: 30 6 command.c:352 register_command_handler(): registering 'hla_serial'... Debug: 31 6 command.c:352 register_command_handler(): registering 'hla_layout'... Debug: 32 6 command.c:352 register_command_handler(): registering 'hla_vid_pid'... Debug: 33 6 command.c:352 register_command_handler(): registering 'hla_command'... Debug: 34 6 command.c:146 script_debug(): command - hla_layout stlink Debug: 36 6 hla_interface.c:242 hl_interface_handle_layout_command(): hl_interface_handle_layout_command Debug: 37 6 command.c:146 script_debug(): command - hla_device_desc ST-LINK Debug: 39 6 hla_interface.c:216 hl_interface_handle_device_desc_command(): hl_interface_handle_device_desc_command Debug: 40 6 command.c:146 script_debug(): command - hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 Debug: 42 6 command.c:146 script_debug(): command - transport select hla_jtag Debug: 43 6 hla_transport.c:189 hl_transport_select(): hl_transport_select Debug: 44 6 command.c:352 register_command_handler(): registering 'hla'... Debug: 45 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 46 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 47 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 48 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 49 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 50 7 command.c:352 register_command_handler(): registering 'jtag'... Debug: 51 7 command.c:352 register_command_handler(): registering 'jtag'... Debug: 52 7 command.c:352 register_command_handler(): registering 'jtag'... Debug: 53 7 command.c:352 register_command_handler(): registering 'jtag'... Debug: 54 7 command.c:352 register_command_handler(): registering 'jtag_ntrst_delay'... User : 55 7 options.c:63 configuration_output_handler(): hla_jtagUser : 56 7 options.c:63 configuration_output_handler(): Debug: 57 7 command.c:146 script_debug(): command - adapter speed 100 Debug: 59 7 core.c:1822 jtag_config_khz(): handle jtag khz Debug: 60 7 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 61 7 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed
[OpenOCD-devel] [openocd:tickets] Re: #280 stlink-v2 not working with bcm2835 raspberry pi
Hello, On Thu, Oct 15, 2020 at 02:42:26PM -, Christian Tenllado wrote: > I am trying to use a stlink-v2 to debug a raspberry pi (bcm2835) using jtag, > but This is not possible, stlink-v2 is not a generic JTAG adapter, it only supports Cortex-M targets. --- ** [tickets:#280] stlink-v2 not working with bcm2835 raspberry pi** **Status:** new **Milestone:** 0.9.0 **Created:** Thu Oct 15, 2020 02:42 PM UTC by Christian Tenllado **Last Updated:** Thu Oct 15, 2020 03:55 PM UTC **Owner:** nobody Hi: I am trying to use a stlink-v2 to debug a raspberry pi (bcm2835) using jtag, but I am not succeding. I have tryied with two transports, hla and dapdirect, and each of them is giving me different problems. Using the openocd snapshot from debian unstable (from 2020-08-19). The commands I use to connect and the debug output from openocd are the following: - Using hla: $ openocd -d3 -f interface/stlink-v2.cfg -c "transport select hla_jtag" -c "adapter speed 100" -c "hla newtap raspi arm -irlen 5 -expected-id 0x07b7617F" -c "target create raspi.arm arm11 -chain-position raspi.arm" Open On-Chip Debugger 0.10.0+dev-snapshot (2020-10-14-11:42) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html User : 13 5 options.c:63 configuration_output_handler(): debug_level: 3 User : 14 5 options.c:63 configuration_output_handler(): Debug: 15 5 options.c:187 add_default_dirs(): bindir=/usr/bin Debug: 16 5 options.c:188 add_default_dirs(): pkgdatadir=/usr/share/openocd Debug: 17 5 options.c:189 add_default_dirs(): exepath=/usr/bin Debug: 18 5 options.c:190 add_default_dirs(): bin2data=../share/openocd Debug: 19 5 configuration.c:42 add_script_search_dir(): adding /home/christian/.openocd Debug: 20 5 configuration.c:42 add_script_search_dir(): adding /usr/bin/../share/openocd/site Debug: 21 5 configuration.c:42 add_script_search_dir(): adding /usr/bin/../share/openocd/scripts Debug: 22 6 configuration.c:97 find_file(): found /usr/bin/../share/openocd/scripts/interface/stlink-v2.cfg Debug: 23 6 command.c:146 script_debug(): command - echo WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg User : 25 6 command.c:767 jim_echo(): WARNING: interface/stlink-v2.cfg is deprecated, please switch to interface/stlink.cfg Debug: 26 6 configuration.c:97 find_file(): found /usr/bin/../share/openocd/scripts/interface/stlink.cfg Debug: 27 6 command.c:146 script_debug(): command - adapter driver hla Debug: 29 6 command.c:352 register_command_handler(): registering 'hla_device_desc'... Debug: 30 6 command.c:352 register_command_handler(): registering 'hla_serial'... Debug: 31 6 command.c:352 register_command_handler(): registering 'hla_layout'... Debug: 32 6 command.c:352 register_command_handler(): registering 'hla_vid_pid'... Debug: 33 6 command.c:352 register_command_handler(): registering 'hla_command'... Debug: 34 6 command.c:146 script_debug(): command - hla_layout stlink Debug: 36 6 hla_interface.c:242 hl_interface_handle_layout_command(): hl_interface_handle_layout_command Debug: 37 6 command.c:146 script_debug(): command - hla_device_desc ST-LINK Debug: 39 6 hla_interface.c:216 hl_interface_handle_device_desc_command(): hl_interface_handle_device_desc_command Debug: 40 6 command.c:146 script_debug(): command - hla_vid_pid 0x0483 0x3744 0x0483 0x3748 0x0483 0x374b 0x0483 0x374d 0x0483 0x374e 0x0483 0x374f 0x0483 0x3752 0x0483 0x3753 Debug: 42 6 command.c:146 script_debug(): command - transport select hla_jtag Debug: 43 6 hla_transport.c:189 hl_transport_select(): hl_transport_select Debug: 44 6 command.c:352 register_command_handler(): registering 'hla'... Debug: 45 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 46 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 47 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 48 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 49 6 command.c:352 register_command_handler(): registering 'jtag'... Debug: 50 7 command.c:352 register_command_handler(): registering 'jtag'... Debug: 51 7 command.c:352 register_command_handler(): registering 'jtag'... Debug: 52 7 command.c:352 register_command_handler(): registering 'jtag'... Debug: 53 7 command.c:352 register_command_handler(): registering 'jtag'... Debug: 54 7 command.c:352 register_command_handler(): registering 'jtag_ntrst_delay'... User : 55 7 options.c:63 configuration_output_handler(): hla_jtagUser : 56 7 options.c:63 configuration_output_handler(): Debug: 57 7 command.c:146 script_debug(): command - adapter speed 100 Debug: 59 7 core.c:1822 jtag_config_khz(): handle jtag khz Debug: 60 7 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value Debug: 61 7 core.c:1785 adapter_khz_to_speed(): convert khz to interface specific speed value User : 62 7 options.c:63 configuration_output_handler(): adapter speed: 100 kHz
Re: [OpenOCD-devel] OpenOCD failed with code (1)
Hi Pavel! On Wed, Oct 07, 2020 at 02:25:02PM -0400, Pavel Bobe wrote: > I'm getting an OpenOCD failed with code (1) message and I'm not sure what's > wrong. I'm certain you're trying to use an out-of-tree target config that was created for the earlier version of OpenOCD. You should be able to easily change it to use the new syntax and dap definition commands but you'll probably be missing the support for the flash driver anyway if it's not upstream (and if it's upstream you should be using the upstream config file). HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [openocd:tickets] Re: #208 Open OCD for external qspi programming and debugging
On Mon, Aug 17, 2020 at 03:58:59AM -, Eddie Garcia wrote: > I downloaded your patch and applied it. Is it not possible to use the "load" > command from GDB? I can use the built-in OpenOCD commands to program the > external flash, but the "load" command from GDB seems to fail all the time. It should be possible unless you disable GDB memory map. Please confirm you're not doing that, and show an openocd debug log. Feel free to /join the IRC channel for a more interactive discussion. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#208] Open OCD for external qspi programming and debugging** **Status:** closed **Milestone:** 0.9.0 **Labels:** QSPI Flash **Created:** Sat Sep 29, 2018 08:58 PM UTC by Praveen **Last Updated:** Mon Aug 17, 2020 03:58 AM UTC **Owner:** nobody Hi, We want to use Open OCD + GDB to program and debug from external quad NAND flash for STM32H7xx micrcontroller. Till now we have been using internal flash. Please share any reference documents or sample projects to develop the scripts or drivers to acheive our debug environment. Thanks, Praveen --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] [openocd:tickets] #275 ST-Link v3 refuses to work with non-ST targets, RE help needed
On Mon, Jul 27, 2020 at 12:03:12PM +0200, b...@elektron.ikp.physik.tu-darmstadt.de wrote: > > I'm surprised I get no constructive feedback on this ticket. Now that > > it's trivial to try a firmware with patched-out IDCODE check why isn't > > anybody trying that? > > This is caused probably by different interpretations of "trivial" ... I'm not sure what is the possible misunderstanding here. OpenOCD is targetted at developers and surely it shouldn't be problematic for a developer to unpack/pack zip files or to run a java utility for encryption/decryption? And stlink users are of course targetting cortex-m MCUs, so STM32F7 firmware is not something alien to them. Am I missing anything essential? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [openocd:tickets] Re: #275 ST-Link v3 refuses to work with non-ST targets, RE help needed
On Mon, Jul 27, 2020 at 12:03:12PM +0200, b...@elektron.ikp.physik.tu-darmstadt.de wrote: > > I'm surprised I get no constructive feedback on this ticket. Now that > > it's trivial to try a firmware with patched-out IDCODE check why isn't > > anybody trying that? > > This is caused probably by different interpretations of "trivial" ... I'm not sure what is the possible misunderstanding here. OpenOCD is targetted at developers and surely it shouldn't be problematic for a developer to unpack/pack zip files or to run a java utility for encryption/decryption? And stlink users are of course targetting cortex-m MCUs, so STM32F7 firmware is not something alien to them. Am I missing anything essential? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#275] ST-Link v3 refuses to work with non-ST targets, RE help needed** **Status:** new **Milestone:** 0.9.0 **Created:** Fri Jul 24, 2020 04:26 PM UTC by Paul Fertser **Last Updated:** Fri Jul 24, 2020 04:26 PM UTC **Owner:** Paul Fertser For the reasons yet to be discovered, ST-Link v3 is not connecting to the Cortex-M targets not produced by ST. There's likely a way to fix this by patching the firmware, and thanks to the amazing effort by some community members patching and uploading patched versions of the firmware is now relatively easy. First, a word of warning: V3J6M2 firmware will enable permanent protection level 2, so you won't be able to debug ST-Link itself over SWD on this chip ever (reflashing via the bootloader would still be possible though). V3J2-V3J5 are known to not enable any additional protection. How to patch the firmware: 1. Download an official zip archive, the rest of this post refers to http://mobisys.silla.ac.kr/yjkim/es-lecture/-/raw/3b6768d46ed0fe4ee1acd820b0fd7d07bdf4aed2/en.stsw-link007_V2-36-26.zip (or you can get en.stsw-link007_V2-36-26.zip from the official ST website if you are ready to register with them); 2. Clone https://github.com/lujji/st-decrypt and use it to decrypt (and later encrypt prior to uploading) file f3_1.bin from STLinkUpgrade.jar, the key is ' .ST-Link.ver.3.'; 3. Start radare2 like this: r2 -a arm -b 16 -m 0x0802 f3_1.bin.dec (of course, you can use any other RE tool you like, just set it to assume Thumb* instructions and 0x0802 base address); 4. Start browsing around and doing your cool RE magic as you're used to. Of specific interest might be the function at 0x08023df8 (called from functions at 0x08025c90 and 0x08025b8e). It checks values located at 0xE0042000 (IDCODE of certain F1, F2, L1, L4, G4 devices), 0x40015800 (certain F1, L0, G0 parts), 0x5C001000 (H7 parts). I've checked the latter address and it's present just once in the whole binary and is referenced only from this single function. So chances are this is the one doing the dirty job and so it (or its call sites) can be easily patched to improve interoperability with all Cortex-M contollers. I'm lacking v3 hardware to test it myself but I'm ready to assist with digging and trying things. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [openocd:tickets] Re: #275 ST-Link v3 refuses to work with non-ST targets, RE help needed
On Mon, Jul 27, 2020 at 11:21:00AM +0200, b...@elektron.ikp.physik.tu-darmstadt.de wrote: > Rejecting non-ST MCU probably has also a deeper impact. The need to > read the MCUID! This has often problems when in sleep or even when in > reset. Even with stprog, STLINKV3 often does to to a board the > STLINK-V2(1) had no probblem. I'm surprised I get no constructive feedback on this ticket. Now that it's trivial to try a firmware with patched-out IDCODE check why isn't anybody trying that? Probably in fact I'm wrong to bother at all and nobody just gives a damn and it's a non-issue? > > First, a word of warning: V3J6M2 firmware will enable permanent protection > > level 2, so you won't be able to debug ST-Link itself over SWD on this chip > > ever (reflashing via the bootloader would still be possible though). > > V3J2-V3J5 > > are known to not enable any additional protection. > > How to patch the firmware: > > There is also a patched bootloader available that does not protect the > F723. >From reading that github ticket thread I got an impression that the protection is performed by the main firmware. And it's probably checking some byte that's flashed with the bootloader, right, but nobody has tested it yet, and also nothing prevents ST from ignoring that byte in the new not-yet-released versions of the firmware, so I wouldn't count on it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com --- ** [tickets:#275] ST-Link v3 refuses to work with non-ST targets, RE help needed** **Status:** new **Milestone:** 0.9.0 **Created:** Fri Jul 24, 2020 04:26 PM UTC by Paul Fertser **Last Updated:** Fri Jul 24, 2020 04:26 PM UTC **Owner:** Paul Fertser For the reasons yet to be discovered, ST-Link v3 is not connecting to the Cortex-M targets not produced by ST. There's likely a way to fix this by patching the firmware, and thanks to the amazing effort by some community members patching and uploading patched versions of the firmware is now relatively easy. First, a word of warning: V3J6M2 firmware will enable permanent protection level 2, so you won't be able to debug ST-Link itself over SWD on this chip ever (reflashing via the bootloader would still be possible though). V3J2-V3J5 are known to not enable any additional protection. How to patch the firmware: 1. Download an official zip archive, the rest of this post refers to http://mobisys.silla.ac.kr/yjkim/es-lecture/-/raw/3b6768d46ed0fe4ee1acd820b0fd7d07bdf4aed2/en.stsw-link007_V2-36-26.zip (or you can get en.stsw-link007_V2-36-26.zip from the official ST website if you are ready to register with them); 2. Clone https://github.com/lujji/st-decrypt and use it to decrypt (and later encrypt prior to uploading) file f3_1.bin from STLinkUpgrade.jar, the key is ' .ST-Link.ver.3.'; 3. Start radare2 like this: r2 -a arm -b 16 -m 0x0802 f3_1.bin.dec (of course, you can use any other RE tool you like, just set it to assume Thumb* instructions and 0x0802 base address); 4. Start browsing around and doing your cool RE magic as you're used to. Of specific interest might be the function at 0x08023df8 (called from functions at 0x08025c90 and 0x08025b8e). It checks values located at 0xE0042000 (IDCODE of certain F1, F2, L1, L4, G4 devices), 0x40015800 (certain F1, L0, G0 parts), 0x5C001000 (H7 parts). I've checked the latter address and it's present just once in the whole binary and is referenced only from this single function. So chances are this is the one doing the dirty job and so it (or its call sites) can be easily patched to improve interoperability with all Cortex-M contollers. I'm lacking v3 hardware to test it myself but I'm ready to assist with digging and trying things. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] [openocd:tickets] #275 ST-Link v3 refuses to work with non-ST targets, RE help needed
On Mon, Jul 27, 2020 at 11:21:00AM +0200, b...@elektron.ikp.physik.tu-darmstadt.de wrote: > Rejecting non-ST MCU probably has also a deeper impact. The need to > read the MCUID! This has often problems when in sleep or even when in > reset. Even with stprog, STLINKV3 often does to to a board the > STLINK-V2(1) had no probblem. I'm surprised I get no constructive feedback on this ticket. Now that it's trivial to try a firmware with patched-out IDCODE check why isn't anybody trying that? Probably in fact I'm wrong to bother at all and nobody just gives a damn and it's a non-issue? > > First, a word of warning: V3J6M2 firmware will enable permanent protection > > level 2, so you won't be able to debug ST-Link itself over SWD on this chip > > ever (reflashing via the bootloader would still be possible though). > > V3J2-V3J5 > > are known to not enable any additional protection. > > How to patch the firmware: > > There is also a patched bootloader available that does not protect the > F723. >From reading that github ticket thread I got an impression that the protection is performed by the main firmware. And it's probably checking some byte that's flashed with the bootloader, right, but nobody has tested it yet, and also nothing prevents ST from ignoring that byte in the new not-yet-released versions of the firmware, so I wouldn't count on it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [openocd:tickets] #275 ST-Link v3 refuses to work with non-ST targets, RE help needed
--- ** [tickets:#275] ST-Link v3 refuses to work with non-ST targets, RE help needed** **Status:** new **Milestone:** 0.9.0 **Created:** Fri Jul 24, 2020 04:26 PM UTC by Paul Fertser **Last Updated:** Fri Jul 24, 2020 04:26 PM UTC **Owner:** Paul Fertser For the reasons yet to be discovered, ST-Link v3 is not connecting to the Cortex-M targets not produced by ST. There's likely a way to fix this by patching the firmware, and thanks to the amazing effort by some community members patching and uploading patched versions of the firmware is now relatively easy. First, a word of warning: V3J6M2 firmware will enable permanent protection level 2, so you won't be able to debug ST-Link itself over SWD on this chip ever (reflashing via the bootloader would still be possible though). V3J2-V3J5 are known to not enable any additional protection. How to patch the firmware: 1. Download an official zip archive, the rest of this post refers to http://mobisys.silla.ac.kr/yjkim/es-lecture/-/raw/3b6768d46ed0fe4ee1acd820b0fd7d07bdf4aed2/en.stsw-link007_V2-36-26.zip (or you can get en.stsw-link007_V2-36-26.zip from the official ST website if you are ready to register with them); 2. Clone https://github.com/lujji/st-decrypt and use it to decrypt (and later encrypt prior to uploading) file f3_1.bin from STLinkUpgrade.jar, the key is ' .ST-Link.ver.3.'; 3. Start radare2 like this: r2 -a arm -b 16 -m 0x0802 f3_1.bin.dec (of course, you can use any other RE tool you like, just set it to assume Thumb* instructions and 0x0802 base address); 4. Start browsing around and doing your cool RE magic as you're used to. Of specific interest might be the function at 0x08023df8 (called from functions at 0x08025c90 and 0x08025b8e). It checks values located at 0xE0042000 (IDCODE of certain F1, F2, L1, L4, G4 devices), 0x40015800 (certain F1, L0, G0 parts), 0x5C001000 (H7 parts). I've checked the latter address and it's present just once in the whole binary and is referenced only from this single function. So chances are this is the one doing the dirty job and so it (or its call sites) can be easily patched to improve interoperability with all Cortex-M contollers. I'm lacking v3 hardware to test it myself but I'm ready to assist with digging and trying things. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] [openocd:tickets] #274 openocd error stmlink with stm32l053r8
- **status**: new --> closed - **discussion**: enabled --> disabled - **Resolution**: --> notabug - **Comment**: The bug tracking system is not meant for end-user support. Please read the official User Manual and if you still have any questions reach through the support channels. --- ** [tickets:#274] openocd error stmlink with stm32l053r8** **Status:** closed **Milestone:** 0.9.0 **Labels:** stm32lx flash OpenOCD ST-LINK NRST signal **Created:** Thu Jul 09, 2020 09:04 AM UTC by MURLIDHAR ROY **Last Updated:** Thu Jul 09, 2020 12:36 PM UTC **Owner:** OpenOCD-Gerrit Hi team, I am working in windows 10 system. Following these instructions from starting "https://docs.rust-embedded.org/discovery/03-setup/windows.html;. hardware/board- STM32L053R8 (Nucleo64) When I tried this command->"openocd -s C:\OpenOCD\share\scripts -f interface/stlink.cfg -f target/stm32l0x.cfg" it gives following error- **xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-00378-ge5be992df (2020-06-26-09:29) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html embedded:startup.tcl:26: Error: Can't find target/stm32l0x.cfg in procedure 'script' at file "embedded:startup.tcl", line 26** kindly suggest to me the solution. --- Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to https://sourceforge.net/p/openocd/tickets/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/openocd/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
