Git Product home page Git Product logo

openocd-xpack's Introduction

GitHub package.json version GitHub release (latest by date) npm (scoped) license

The xPack OpenOCD

A standalone cross-platform (Windows/macOS/Linux) OpenOCD binary distribution, intended for reproducible builds.

In addition to the the binary archives and the package meta data, this project also includes the build scripts.

Overview

This open source project is hosted on GitHub as xpack-dev-tools/openocd-xpack and provides the platform specific binaries for the xPack OpenOCD.

This distribution follows the official OpenOCD.

The binaries can be installed automatically as binary xPacks or manually as portable archives.

Release schedule

This distribution generally follows the official OpenOCD, with additional releases based on the current Git form time to time.

User info

This section is intended as a shortcut for those who plan to use the OpenOCD binaries. For full details please read the xPack OpenOCD pages.

Easy install

The easiest way to install OpenOCD is using the binary xPack, available as @xpack-dev-tools/openocd from the npmjs.com registry.

Prerequisites

A recent xpm, which is a portable Node.js command line application that complements npm with several extra features specific to C/C++ projects.

It is recommended to install/update to the latest version with:

npm install --location=global xpm@latest

For details please follow the instructions in the xPack install page.

Install

With the xpm tool available, installing the latest version of the package and adding it as a development dependency for a project is quite easy:

cd my-project
xpm init # Add a package.json if not already present

xpm install @xpack-dev-tools/openocd@latest --verbose

ls -l xpacks/.bin

This command will:

  • install the latest available version, into the central xPacks store, if not already there
  • add symbolic links to the central store (or .cmd forwarders on Windows) into the local xpacks/.bin folder.

The central xPacks store is a platform dependent location in the home folder; check the output of the xpm command for the actual folder used on your platform. This location is configurable via the environment variable XPACKS_STORE_FOLDER; for more details please check the xpm folders page.

For xPacks aware tools, like the Eclipse Embedded C/C++ plug-ins, it is also possible to install OpenOCD globally, in the user home folder:

xpm install --global @xpack-dev-tools/openocd@latest --verbose

Eclipse will automatically identify binaries installed with xpm and provide a convenient method to manage paths.

After install, the package should create a structure like this (macOS files; only the first two depth levels are shown):

$ tree -L 2 /Users/ilg/Library/xPacks/\@xpack-dev-tools/openocd/0.12.0-3.1/.content/
/Users/ilg/Library/xPacks/\@xpack-dev-tools/openocd/0.12.0-3.1/.content/
├── README.md
├── bin
│   └── openocd
├── distro-info
│   └── licenses
├── libexec
│   ├── libftdi1.2.5.0.dylib
│   ├── libftdi1.2.dylib -> libftdi1.2.5.0.dylib
│   ├── libhidapi.0.14.0.dylib
│   └── libusb-1.0.0.dylib
└── openocd
    ├── OpenULINK
    ├── angie
    ├── contrib
    └── scripts

10 directories, 6 files

No other files are installed in any system folders or other locations.

Uninstall

The binaries are distributed as portable archives; thus they do not need to run a setup and do not require an uninstall; simply removing the folder is enough.

To remove the links created by xpm in the current project:

cd my-project

xpm uninstall @xpack-dev-tools/openocd

To completely remove the package from the central xPack store:

xpm uninstall --global @xpack-dev-tools/openocd

Manual install

For all platforms, the xPack OpenOCD binaries are released as portable archives that can be installed in any location.

The archives can be downloaded from the GitHub Releases page.

For more details please read the Install page.

Versioning

The version strings used by the OpenOCD project are three number strings like 0.12.0; to this string the xPack distribution adds a four number, but since semver allows only three numbers, all additional ones can be added only as pre-release strings, separated by a dash, like 0.12.0-3. When published as a npm package, the version gets a fifth number, like 0.12.0-3.1.

Since adherence of third party packages to semver is not guaranteed, it is recommended to use semver expressions like ^0.12.0 and ~0.12.0 with caution, and prefer exact matches, like 0.12.0-3.1.

Windows drivers

Most JTAG probes require separate drivers on Windows. For more details please read the Install page.

GNU/Linux UDEV subsystem

For the JTAG probes implemented as USB devices (actually most of them), the last installation step on GNU/Linux is to configure the UDEV subsystem.

For more details please read the Install page.

Developer & Maintainer info

For information on how to build the binaries, please see the README-DEVELOPER page.

For information on the workflow used to make releases, please see the README-MAINTAINER page.

Support

The quick advice for getting support is to use the GitHub Discussions.

For more details please read the Support page.

License

Unless otherwise stated, the content is released under the terms of the MIT License, with all rights reserved to Liviu Ionescu.

The binary distributions include several open-source components; the corresponding licenses are available in the installed distro-info/licenses folder.

Download analytics

Credit to Shields IO for the badges and to Somsubhra/github-release-stats for the individual file counters.

openocd-xpack's People

Contributors

ilg-ul avatar tommymurphytm1234 avatar truhlikfredy avatar zqb-all avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

openocd-xpack's Issues

Switch all builds to use Github-hosted runners

Description

This is an extension to #18 for other operating systems.

The current Github Action files in this repository (.github/workflows/build.yml) all require self-hosted runners to be able to execute.

linux-x64:
name: 'Intel Linux OpenOCD ${{ github.event.inputs.version }} build'
timeout-minutes: 5760 # 4 days
runs-on: [self-hosted, Linux, X64]

This is an unnecessary complication if the goal is to just obtain binaries for a given OpenOCD repository. As showcased in #18, switching from the requirement of a self-hosted Linux runner machine to the Github-provided ubuntu-latest runner provides a successful build for Linux + Windows with the x86 and x64 architectures as well.

In particular, the following changes should be made:

  • Do not require a self-hosted Mac runner, make the build work on the Github-provided macos-latest runner (= #18)
  • Do not require a self-hosted Linux x64 machine to build Linux and Windows x64 and x86 images, use ubuntu-latest. (This has already been proven to work through these changes)
  • Do not require a self-hosted Linux ARM machine to build ARM32 and ARM64 binaries, use ubuntu-latest with cross-compiling toolchains for the e.g. Raspberry Pi. Repos like https://github.com/raspberrypi/tools indicate this is rather trivial by installing the gcc-arm-linux-gnueabihf (ARM32) and gcc-aarch64-linux-gnu (ARM64) packages and should not be much different than the Linux x64 runner building the Windows binaries through the MinGW toolchain.

Steps to Reproduce

  1. Fork this repo
  2. Take a look at the .github/workflows/build.yml and related files
  3. Attempt a build

Expected behaviour: The build executes without having the need for self-hosted runners.

Actual behaviour: Nothing happens if the account does not have these special self-hosted runners set-up.

Versions

Build the Windows binaries fails with missing compiler

Description

Build the Windows binaries fail when configure libiconv-1.17

Steps to Reproduce

According to "Build the Windows binaries" in
https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-MAINTAINER.md

git -C ~/Work/xpacks/openocd-xpack.git pull && \
xpm run install -C ~/Work/xpacks/openocd-xpack.git && \
git -C ~/Work/xpacks/xbb-helper-xpack.git pull && \
xpm link -C ~/Work/xpacks/xbb-helper-xpack.git && \
xpm run link-deps -C ~/Work/xpacks/openocd-xpack.git && \
xpm run deep-clean --config win32-x64 -C ~/Work/xpacks/openocd-xpack.git && \
xpm run docker-prepare --config win32-x64 -C ~/Work/xpacks/openocd-xpack.git && \
xpm run docker-link-deps --config win32-x64 -C ~/Work/xpacks/openocd-xpack.git
xpm run docker-build-develop --config win32-x64 -C ~/Work/xpacks/openocd-xpack.git

fail with log:

[bash /home/mark/Work/xpacks/openocd-xpack.git/build/win32-x64/sources/libiconv-1.17/configure --prefix=/home/mark/Work/xpacks/openocd-xpack.git/build/win32-x64/x86_64-w64-mingw32/install --libdir=/home/mark/Work/xpacks/openocd-xpack.git/build/win32-x64/x86_64-w64-mingw32/install/lib --includedir=/home/mark/Work/xpacks/openocd-xpack.git/build/win32-x64/x86_64-w64-mingw32/install/include --mandir=/home/mark/Work/xpacks/openocd-xpack.git/build/win32-x64/x86_64-w64-mingw32/install/share/man --build=x86_64-pc-linux-gnu --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-debug --disable-dependency-tracking --disable-silent-rules --disable-nls --enable-static --enable-extra-encodings]
checking for a BSD-compatible install... /usr/bin/install
checking whether build environment is sane... yes
checking for x86_64-w64-mingw32-strip... x86_64-w64-mingw32-strip
checking for a race-free mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make sets $(MAKE)... (cached) yes
checking for x86_64-w64-mingw32-gcc... x86_64-w64-mingw32-gcc
checking whether the C compiler works... no
configure: error: in `/home/mark/Work/xpacks/openocd-xpack.git/build/win32-x64/x86_64-w64-mingw32/build/libiconv-1.17':
configure: error: C compiler cannot create executables
See `config.log' for more details

Make the build folder writable by all...

[chmod -R a+w /home/mark/Work/xpacks/openocd-xpack.git/build]

Make the xpacks folder writable by all...

[chmod a+w /home/mark/Work/xpacks/openocd-xpack.git/xpacks]
error: running 'bash  scripts/build.sh --target win32-x64 --build-folder build/win32-x64 --windows --develop' failed
error: running 'docker exec --user $(id -un) openocd-0.12.0-1.1-win32-x64 xpm run build-develop --config win32-x64' failed

Versions

  • [OpenOCD version] Haven't started compiling openocd yet
  • [operating system] windows wsl ubuntu 20.04

Does xPack OpenOCD supports parallel vector format commands (PIO/PIOMAP) in SVF?

I'm trying to run an SVF sequence on my target device, which has a Cortex M4 CPU and follows the ARMv7 Architecture Profile.

After connecting to my target device, I run SVF commands via telnet. But it throws me the following error:

Error: PIO and PIOMAP are not supported

Does this version of OpenOCD have support for PIO/PIOMAP commands? Per the I'm able to use the SDR/SIR commands without any issues

Since SVF is supported in OpenOCD, I was wondering why the SVF PIO commands are not working. Is it only possible via SDR/SIR commands to read/write on a boundary scan?

Versions

  • OpenOCD version: `xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2022-09-01-17:56)'
  • Operating system: 'Linux 5.4.0-172-generic #190-Ubuntu SMP'

OpenOCD 0.11.0 release

The upstream openocd 0.11.0 is released.
Would it be possible to get an updated xpack distribution based on this?

jtagspi driver with support for 4-byte addresses (needed for large Flash Memories)

Discussed in #15

Originally posted by SteffenKlu November 22, 2021
The jtagspi driver was updated this month (https://review.openocd.org/c/openocd/+/4876/) and I am interested if
you could build a new 'xpack-openocd-0.11.xx' Tar-ball which includes those latest improvements?
I tried to flash the large SPI-Flash in an Xilinx-Board, with the existing openocd release but it failed:

[Log]
xPack OpenOCD x86_64 Open On-Chip Debugger 0.11.0+dev (2021-10-16-21:15)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
xc7_program
jtagspi_program
Info : usb blaster interface using libftdi
Error: unable to get latency timer
Info : This adapter doesn't support configurable speed
Info : JTAG tap: xc7.tap tap/device found: 0x13631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x1)
Info : JTAG tap: xc7.tap tap/device found: 0x13631093 (mfg: 0x049 (Xilinx), part: 0x3631, ver: 0x1)
Info : Found flash device 'sp s25fl256s' (ID 0x00190201)
Warn : device needs paging or 4-byte addresses - not implemented
[...]
Info : sector 9 took 2 ms
Info : Found flash device 'sp s25fl256s' (ID 0x00190201)
Warn : device needs paging or 4-byte addresses - not implemented
read 645496 bytes from file build/results/ip0170p.ppn.bin and flash bank 0 at offset 0x00000000 in 12.880716s (48.939 KiB/s)
contents differ
diff 0 address 0x00000000. Was 0x00 instead of 0xff
diff 1 address 0x00000001. Was 0x09 instead of 0xff
diff 2 address 0x00000002. Was 0x0f instead of 0xff
diff 3 address 0x00000003. Was 0xf0 instead of 0xff
diff 4 address 0x00000004. Was 0x0f instead of 0xff
[...]
More than 128 errors, the rest are not printed.
[/Log]

I hope the new enhancements to the jtagspi driver solve this problem.

Best,
Steffen

Switch Mac build to use Github-hosted runner

Description

The builder actions contained in this repository currently all rely on self-hosted runners. Specifically, the MacOS action declares

macos-x64:
name: 'Intel macOS OpenOCD ${{ github.event.inputs.version }} build'
timeout-minutes: 2880 # 2 days
runs-on: [self-hosted, macOS, X64]

However, GitHub provides, even in their free account model, access to Github-hosted runners, which include MacOS.

With the Linux build described in the above file, it suffices to replace runs-on: [self-hosted, Linux, X64] with runs-on: [ubuntu-latest] to get a successful build of OpenOCD (refer here and here). This demonstrates that it's not necessary to go through the hassle of a self-hosted runner to get the basic Linux + Windows builds.

When doing the same for MacOS however (using macos-latest), the build aborts pretty early with the error message (source)

Script "scripts/helper/build.sh" started at Tue Dec 28 12:52:33 UTC 2021.

Please install the macOS XBB and rerun.
https://github.com/xpack/xpack-build-box/tree/master/macos
Error: Process completed with exit code 1.

The build.yml and related file should be updated, or alternatives for it should be provided, which use the Github-hosted runner for MacOS, along with the necessary preperation of the runner in the form of installing XBB for MacOS, to obtain an automated build for MacOS with no self-owned hardware.

Steps to Reproduce

  1. Fork this repository
  2. Exchange MacOS Github Action in build.yml as shown in diff
  3. Trigger workflow run (e.g., in branch xpack-develop and version 0.11.0-3)
  4. Observe Github Action output

Expected behaviour: Build goes through.

Actual behaviour: Error during build (Please install the macOS XBB and rerun.) since Github Action file does not setup XBB.

Versions

Remove deprecated --enable-oocd_trace

@TommyMurphyTM1234 reported the following:

BTW - one (innocuous) warning that you may already be aware of when running the xPack openocd build script:

WARNING! Deprecated configure option (--enable-oocd_trace)
The oocd_trace driver is deprecated and will be removed in the next release.
If you regularly use this driver, please report to the OpenOCD Mailing List.

OpenOCD fails with Atmel ICE probe

Description

OpenOCD fails to launch with an Atmel ICE probe and custom board equipped with a SAMD51G18.
Flash, erase and debug session can be launched when using MPLABX or ATMEL STUDIO with the Atmel probe.
I am able to launch debug session with gdb and OpenOCD when using an STM32F4-Disco (STM32F407 and Stlink).
I have tried to reduce speed of the adapter from its initial 2000 kHz to 500kHz/50kHz/20kHz and even 2kHz.

Steps to Reproduce

openocd -d3 -f myboard_samd51.cfg

Content of "myboard_samd51.cfg":
source [find interface/cmsis-dap.cfg]
transport select swd
cmsis_dap_vid_pid 0x03eb 0x2141
set CHIPNAME samd51g18a
source [find target/atsame5x.cfg]
reset_config srst_only

Expected behaviour:

I expect to be able to launch a command line gdb (arm-none-eabi) session using "target extended-remote localhost:3333"

Actual behaviour:

I end up with following extracted message from OpenOCD when using debug level 3:

Debug: 214 506 cmsis_dap_usb.c:730 cmsis_dap_swd_read_process(): SWD ack not OK @ 0 JUNK
Debug: 215 511 command.c:626 run_command(): Command 'dap init' failed with error code -4
User : 216 513 command.c:692 command_run_line():
Debug: 217 515 command.c:626 run_command(): Command 'init' failed with error code -4
User : 218 517 command.c:692 command_run_line():
Debug: 219 519 target.c:1978 target_free_all_working_areas_restore(): freeing all working areas
Debug: 220 523 cmsis_dap_usb.c:932 cmsis_dap_swd_switch_seq(): SWD-to-JTAG

Versions

  • OpenOCD version: 0.10.0-14
  • operating system: Windows 10

Cut a release of 0.12.0-rc2

Would you be willing to do a release of the 0.12.0-rc2?

Looks like it might be another month or two before they come out with 0.12.0 proper, and there's lots of really good stuff in there.

stm32f2x.cfg missing reset part which causes problem - you cannot debug Nucleo-F207ZG

Disclaimer

The xPack OpenOCD is only a binary distribution of the standard source code
OpenOCD, and does not intend to add new functionality, or to fix existing
problems.

If you have questions/suggestions related to the procedure used to
build/publish the binary distribution, continue reading the next sections.

If you have problems related to OpenOCD functionality, please use the
official OpenOCD support channels.

Prerequisites

Before entering a new ticket, please consider the following:

  • read the documentation pages carefully (share/doc/pdf/openocd.pdf)
  • check the xPack Forums for similar problems
  • check the GitHub Issues

If you still could not find a solution, if you have interesting use
cases, if you have custom configurations, and generally if you have
any experience that you want to share with others, use the
xPack Forums, the OpenOCD section.

If you are convinced that you identified a bug related to the binary
distribution, not OpenOCD itself (if you have doubts, use the forum),
or you have a pertinent suggestion how to enhance the xPack OpenOCD
distribution, continue and register a new issue.

Description

The scritp is missing reset part which causes a big problem. You cannot debug Nucleo-F207ZG
[Description of the bug or feature]

Steps to Reproduce

Trying to debug

  1. Trying to debug Nucleo-F207ZG board with any mbed project exporting it to GNU-Make. and using eclipse to debug with opeoncd
    Expected behaviour: [What you expected to happen]
    debug is failing .. cannot reset - halt the MCU
    Actual behaviour: [What actually happened]

Versions

Latest

  • [OpenOCD version]
  • [operating system]

Please understand that without being able to reproduce the bug we cannot
identify your problem.
#openocd-org/openocd#12

Note: Remove unnecessary text after reading, before entering your ticket.

README-BUILD should reference common-versions-source.sh

Hi Liviu,

Minor documentation update for README-BUILD.md: Add a new set of definitions in the scripts/container-build.sh, with the versions of various components.

Should read: Add a new set of definitions in the scripts/common-versions-source.sh, with the versions of various components.

--
Bob

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.