[OpenOCD-devel] SWDAP support
Dear OpenOCD developers, As you might already know, ARM designed the SWDAP probe ( [ https://os.mbed.com/teams/mbed/wiki/SWDAP | https://os.mbed.com/teams/mbed/wiki/SWDAP ] ). This programmer/debug probe is intended to be used with pyOCD. However, I would like to use it with OpenOCD. Is that possible? If no, do you intend to support the SWDAP in the (near) future? Kind greetings, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] New release?
Hi @OpenOCD developers, I really like the initiative from Mr. Liviu Ionescu: > For a few releases per year I can handle the multi-platform binary > distribution, > as I already did. I provide 32/64 Windows, 32/64 Linux, and macOS binaries. I think it would be great to make these binaries downloadable from the official OpenOCD website. Talking about distributing the binaries, what's actually the "official website"? I'm a bit puzzled, because I found two websites: 1. http://openocd.org/ Looks very basic. I think a nicer website would be great (just my personal opinion). 2. http://openocd.net This website is apparently offline for the moment. I remember it was a very good-looking website. You can visit a snapshot through http://web.archive.org. Looking at the (snapshot of) this website, it looks like it belonged to "Hochschule Augsburg". Kind greetings, Kristof ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] New release?
Hi, I agree with Mr. Ionescu and Mr. McDowell. A few releases per year would be great. Also, the project should no longer carry the experimental 0 number. It's a mature and popular software. Please don't forget the Windows users. Releases for both Windows and Linux (and why not MacOS) would be great. Will the release be downloadable from http://openocd.org/? Shouldn't the website become a more professional https domain instead of plain http? Kind greetings, Kristof Mulier - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "Jonathan McDowell" Cc: "openocd-devel" Verzonden: Woensdag 8 mei 2019 22:33:44 Onderwerp: Re: [OpenOCD-devel] New release? > On 8 May 2019, at 23:00, Jonathan McDowell wrote: > > ... I asked this question back in September and didn't get any responses; this makes two of us interested in this. anyone else that would like to have a more active versioning scheme for the project? > I've been pondering whether I should just > start packaging snapshots instead. from a practical point of view, I think that 2-4 minor releases per year would be fine, with some of them turned to major releases (that break compatibility), when needed. I also think that the project is mature enough to go past the experimental 0 major number (according to https://semver.org, which is a proposal that for me makes a lot of sense). regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Building OpenOCD for Windows
Hi Liviu, Thank you very much for your mail. If I get stuck somewhere (while compiling OpenOCD), I'll get back to you. Thanks a lot for your help. You are a very kind man :-) Regards, Kristof - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" , i...@sikando.com Verzonden: Maandag 13 mei 2019 23:06:38 Onderwerp: Re: [OpenOCD-devel] Building OpenOCD for Windows > On 13 May 2019, at 12:28, > wrote: > > ... the OpenOCD compilation into a standalone Windows executable happens in > Msys2 on Windows. So no need to install Linux or a virtual Linux machine on > your computer. you no longer need kludges like Msys2, the modern approach is to use Windows System for Linux (WSL), from Microsoft. the WSL2, announced for June, will include a full Linux kernel, tightly coupled with the Windows NT kernel. > Do you think your scripts would run in Msys2 - perhaps with some tweaks? I already tweaked my QEMU build script to run on WSL, so I guess the OpenOCD script can also be tweaked in a similar manner. unfortunately I currently have no resources to do this. > The reason I'm interested in building OpenOCD has everything to do with the > startup I'm working in: > https://embedoffice.com/ > If you have time to check out our website, please let us know what you think > about our initiative I don't know, I agree that Eclipse is very complicated and inconsistent, and personally I think it is on the down slope, and cannot recommend it for medium/long term developments. if you can make your IDE portable and functional on Windows/Linux/macOS, and base it on an open source extensible architecture, allowing 3rd parties to easily add functionality, it might work. however, if I would have to bet, I would bet on Visual Studio Code. actually I plan to rewrite the GNU MCU Eclipse plug-ins as extensions for VSCode, including the OpenOCD debug plug-in. regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Building OpenOCD for Windows
Hi Bob, Thank you for your reply. This approach you describe in https://mindchasers.com/dev/openocd-darsena-windows creates a Windows executable to be run in Cygwin. For software experts, that is certainly good. Most software experts don't bother installing Cygwin, or they just switch entirely to Linux to do the development. The people I'm trying to give a voice are pure hardware experts with limited software exposure. Some of them are even still developing in assembly (not joking) and learning C today. They are comfortable in Windows, on which they use a PCB drawing tool like Eagle. These people need a "standalone" Windows executable, one that runs natively on Windows (no need for Cygwin). To build a standalone executable for such people, I found the following source: https://www.playembedded.org/blog/building-openocd-under-windows-using-msys2/ With that step-by-step guide, I was able to successfully build a standalone executable that simply runs on Windows. Unfortunately, the build relies on a repository from a guy named "Alex Pux". It is not the official Gerrit repository, so the result of the build is not really up-to-date. It would be awesome to have a similar step-by-step guide to build OpenOCD into a standalone Windows executable, pulling in the latest Gerrit repository to get the most up-to-date version. Kind greetings, Kristof Mulier - Oorspronkelijk bericht - Van: "Bob Cochran" Aan: "Liviu Ionescu" , "openocd-devel" Cc: "info" Verzonden: Zondag 19 mei 2019 04:42:56 Onderwerp: Re: [OpenOCD-devel] Building OpenOCD for Windows On 5/8/19 3:44 PM, Liviu Ionescu wrote: > (I created a separate thread, since this is not related to the original > message, and I would like the question related to the new release to be > debated) > >> On 8 May 2019, at 21:44, >> wrote: >> >> Hi Mr. Liviu, >> >> Compiling OpenOCD from the source code into a working executable on Windows >> is quite difficult. I noticed you're one of the few people able to do that >> (for which I thank you). Hi, FYI - we documented how we build OpenOCD on Windows 10 using Cygwin here: https://mindchasers.com/dev/openocd-darsena-windows So far, we have only used it to work with FTDI FT2232H, but we're going to test it soon with CMSIS-DAP. Bob > you're welcome > >> I've tried doing this myself as well, and the best guide I've found so far >> is this one: >> https://www.playembedded.org/blog/building-openocd-under-windows-using-msys2 >> / >> It works. Unfortunately, it's not the latest version. It uses a repository >> from a guy named "Alex Pux" (see chapter 4.2 in the guide). It's not using >> the actual OpenOCD gerrit repository. >> >> How do you compile OpenOCD for Windows? > well, you should differentiate compiling OpenOCD intended to run on your > specific machine, from creating production grade distributions which include > standalone binaries intended to run on any machine, which is a more difficult > undertaking. > > my build scripts address only the later case, and are available from a > separate git project: > > https://github.com/gnu-mcu-eclipse/openocd-build > > the scripts run on CentOS 6 Docker containers, to create the Linux and > Windows binaries, and on macOS 10.10 to create the macOS binaries. > > the Windows binaries are cross compiled with mingw-w64 gcc-7.4. separate 32 > and 64-bit binaries are provided. > > > according to GitHub analytics, since 2015, there were 143 K downloads, which > I guess is an important figure. > > > compiling OpenOCD for development purposes or for local use is currently not > supported very well by the current scripts; it is possible, but it is > tedious, since the scripts will always run the steps to validate the binaries > and pack the result in an archive. > > > FYI, I had a similar problem with QEMU, and for it I added a separate script, > to build the native binaries. on windows it requires the new Microsoft WSL > (Windows System for Linux), which allows to run an Ubuntu inside Windows, so > the script takes the same approach, cross compiling with mingw-w64 gcc-7.4. > >> Do you have a guide on how to do >> that? > the README in the above link provides some info. > > however the full details are in the scripts themselves. > > > regards, > > Liviu > > > > ___ > OpenOCD-devel mailing list > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel > ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Non-ASCII characters in OpenOCD config files.
Hi OpenOCD developers and enthusiasts, I got in trouble many times because of non-ascii characters in some filenames. For example: openocd/scripts/target/1986ве1т.cfg openocd/scripts/target/к1879xб1я.cfg Could you please rename them? Thank you very much. Kind greetings, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Non-ASCII characters in OpenOCD config files.
Hi Andreas, One such problem I ran into is this one: I'm making a Windows installer executable and MSI for my software. I'm using Advanced Installer (https://www.advancedinstaller.com/ )for that purpose. My software has a resources directory in which I put several programs (including an OpenOCD Windows build) and other things. The Windows installer generated by Advanced Installer crashes when it tries to unpack the files with those weird non-ascii characters. I can imagine many other problems arise when people try to open the said files with certain softwares. It's just risky to put non-ascii characters in filenames. What do you think? Kind greetings, Kristof Mulier Van: "Andreas Fritiofson" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 mei 2019 17:01:58 Onderwerp: Re: [OpenOCD-devel] Non-ASCII characters in OpenOCD config files. On Tue, May 21, 2019 at 4:50 PM < [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] > wrote: Hi OpenOCD developers and enthusiasts, I got in trouble many times because of non-ascii characters in some filenames. Hi! What kind of trouble was that? /Andreas ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] How do I simply "ping" a chip with OpenOCD?
Dear OpenOCD developer, My question about how to "ping" a chip with OpenOCD (related to autoprobing) got an outstanding answer on StackOverflow from @ [ https://stackoverflow.com/users/6552613/nattgris | nattgris ] : https://stackoverflow.com/questions/56951820/how-to-ping-a-chip-detect-if-a-chip-is-connected-with-openocd Nevertheless, there are a few practical things that need some more attention. More in particular step-by-step guidance for OpenOCD newbies (like me) to put the theory in practice. Please have a look at the StackOverflow post. Maybe you can help (and grab the +50 bonus points). Thank you very very much. Kind greetings ^_^ Kristof Van: "kristof mulier" Aan: "openocd-devel" Cc: "Tommy Murphy" Verzonden: Dinsdag 9 juli 2019 15:55:49 Onderwerp: Re: How do I simply "ping" a chip with OpenOCD? Dear OpenOCD developer, I've posted the question about "pinging" a chip on StackOverflow. I've done my best to describe it as detailed as possible. Please have a look: https://stackoverflow.com/questions/56951820/how-to-ping-a-chip-detect-if-a-chip-is-connected-with-openocd Thank you so much ^_^ Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "kristof mulier" , "openocd-devel" Verzonden: Maandag 8 juli 2019 20:38:54 Onderwerp: Re: How do I simply "ping" a chip with OpenOCD? Maybe look at section 10.7 Autoprobing of the openocd user's guide? ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] How do I simply "ping" a chip with OpenOCD?
Dear OpenOCD developer, I've posted the question about "pinging" a chip on StackOverflow. I've done my best to describe it as detailed as possible. Please have a look: https://stackoverflow.com/questions/56951820/how-to-ping-a-chip-detect-if-a-chip-is-connected-with-openocd Thank you so much ^_^ Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "kristof mulier" , "openocd-devel" Verzonden: Maandag 8 juli 2019 20:38:54 Onderwerp: Re: How do I simply "ping" a chip with OpenOCD? Maybe look at section 10.7 Autoprobing of the openocd user's guide? ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] How do I simply "ping" a chip with OpenOCD?
Dear OpenOCD developer, I would like to do something uncommon with OpenOCD. Instead of connecting to the chip, I'd like to merely detect the chip. The procedure I have in mind would look like this: 1. Start OpenOCD with the probe config file (eg. stlink.cfg ) given as -f parameter. So OpenOCD knows what probe to use, but doesn't know what chip it will find. 2. OpenOCD detects a chip and reports this somehow (eg. write something to stdout). If possible, this action should not be intrusive to the chip (like resetting it). 3. OpenOCD shuts down. Here are some more notes about the procedure: Note 1: It would be nice if OpenOCD doesn't reach the "server" state where I need to setup a Telnet or GDB client to interact with it. I'd be happy to get the chip detection reported in a more convenient way, like getting the chip info on the stdout channel. Note 2: The detection should be non-intrusive to the chip. However, if OpenOCD doesn't find anything, I'd like to have a backup method where OpenOCD tries to find a chip more aggressively (like holding down the nRST pin). I can invoke this other approach myself if needed (so there's no need for OpenOCD to do that automatically). Note 3: At first, I'll just apply this "chip detection" only on STM32 chips with an STLinkV2 or STLinkV3 probe, later on other probes and chips as well. Note 4: Some boards only have an SWD connection (no JTAG). Thank you very much :-) Kind greetings, Kristof Mulier PS: I only have basic user-knowledge about OpenOCD. ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] How do I simply "ping" a chip with OpenOCD?
Hi @Tommy Murphy, Thank you for referencing me to Section 10.7 in the OpenOCD manual. I've observed the given example: openocd.cfg file: source [ find interface/olimex-arm-usb-tiny-h.cfg ] reset_config trst_and_srst jtag_rclk 8 Because my chip connects through the STLink probe and uses SWD transport protocol (instead of JTAG), I made a few modifications to the example: openocd.cfg file: source [ find interface/stlink.cfg ] transport select hla_swd reset_config srst_only adapter_khz 480 I connect a NUCLEO_F303K8 board to my PC for this test. Then I issue the following command in my console: > openocd -s "C:\...\scripts" -f "C:\...\openocd.cfg" OpenOCD outputs the following and then terminates: Open On-Chip Debugger 0.10.0+dev-00921-gef8c69ff9 (2019-07-06-01:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 480 kHz Info : Listening on port for tcl connections Info : Listening on port for telnet connections Info : clock speed 480 kHz Error: BUG: current_target out of bounds So I end up with two questions concerning autoprobing. Q1: Unfortunately, In my example given above OpenOCD doesn't do any autoprobing as described in Section 10.7. Is this because OpenOCD doesn't support autoprobing with the SWD protocol? Or am I simply making a mistake in my .cfg file? Q2: I also noticed that the autoprobing example from Section 10.7 configures the reset behaviour of OpenOCD. Does this mean that autoprobing will always be "intrusive" in the sense that it resets the chip? Thank you very much for your help ^_^ Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "kristof mulier" , "openocd-devel" Verzonden: Maandag 8 juli 2019 20:38:54 Onderwerp: Re: How do I simply "ping" a chip with OpenOCD? Maybe look at section 10.7 Autoprobing of the openocd user's guide? ORIGINAL MESSAGE FROM KRISTOF: Dear OpenOCD developer, I would like to do something uncommon with OpenOCD. Instead of connecting to the chip, I'd like to merely detect the chip. The procedure I have in mind would look like this: 1. Start OpenOCD with the probe config file (eg. stlink.cfg ) given as -f parameter. So OpenOCD knows what probe to use, but doesn't know what chip it will find. 2. OpenOCD detects a chip and reports this somehow (eg. write something to stdout). If possible, this action should not be intrusive to the chip (like resetting it). 3. OpenOCD shuts down. Here are some more notes about the procedure: Note 1: It would be nice if OpenOCD doesn't reach the "server" state where I need to setup a Telnet or GDB client to interact with it. I'd be happy to get the chip detection reported in a more convenient way, like getting the chip info on the stdout channel. Note 2: The detection should be non-intrusive to the chip. However, if OpenOCD doesn't find anything, I'd like to have a backup method where OpenOCD tries to find a chip more aggressively (like holding down the nRST pin). I can invoke this other approach myself if needed (so there's no need for OpenOCD to do that automatically). Note 3: At first, I'll just apply this "chip detection" only on STM32 chips with an STLinkV2 or STLinkV3 probe, later on other probes and chips as well. Note 4: Some boards only have an SWD connection (no JTAG). Thank you very much :-) Kind greetings, Kristof Mulier PS: I only have basic user-knowledge about OpenOCD. ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] OpenOCD logo or icon
Dear developers, Does OpenOCD already have a logo / icon? If not, I'd love to draw a few, so you can pick one you like :-) Kind greetings, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Logo OpenOCD
Dear developers, As I've seen no logo from OpenOCD anywhere, I've designed one myself in inkscape and added it to this mail. openocd_logo_01.png -> a black-and-white version openocd_logo_02.png -> a coloured version Please let me know if you like it. I can send you the .svg files too. Kind greetings, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] can't run openocd after compiling from the git repository
Hi Attila, What guide did you use to compile the OpenOCD source code? Personally I use this one: https://www.playembedded.org/blog/building-openocd-under-windows-using-msys2/ I've also spoken to the writer Rocco Marco Guglielmi. He encouraged me to use mingw32.exe instead of mingw64.exe to build the source code (in other words: he encouraged me to compile a 32-bit version instead of a 64-bit version). The 32-bit version is compatible with both 64-bit and 32-bit computers, and seems to be more stable (but I don't know why). Some time ago, I was worried that the build-OpenOCD-tutorial from the link above is not giving me the latest OpenOCD builds. That's because it pulls a git repository from a guy named "Alex Pux", and I did not see it pulling the official OpenOCD git repository. However, Mr. Rocco Marco Guglielmi ensured me that there's nothing to worry about. This git repository that's pulled from "Alex Pux" is just containing the build recipes. Within those build recipes is the command to pull the official OpenOCD git repository. So you do get the latest OpenOCD build. Also, Mr. "Alex Pux" is one of the lead developers of MSYS2, so you can trust his resources. Best of luck. Kind greetings, Kristof Mulier Van: "Attila Csosz" Aan: "openocd-devel" Verzonden: Zondag 28 juli 2019 08:26:57 Onderwerp: [OpenOCD-devel] can't run openocd after compiling from the git repository Hi, I've compiled openocd on mingw-w64 platform from the git repository by using the following commands #! /bin/sh ./bootstrap ./configure --enable-stlink --enable-ftdi --disable-doxygen-html --disable-werror make make install After starting it says: "d:\msys64\usr\bin\openocd.exe" -f "d:\msys64\usr\share\openocd\scripts\board\stm32f4discovery.cfg" Open On-Chip Debugger 0.10.0+dev-00922-gefa20839-dirty (2019-07-28-06:45) Licensed under GNU GPL v2 For bug reports, read [ http://openocd.org/doc/doxygen/bugs.html | http://openocd.org/doc/doxygen/bugs.html ] 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 Error: error creating socket: No such file or directory Board: stm32f4discovery I've successfully used the OpenOCD-20190426-0.10.0 binary previously however I'd like to compile it from source. What may the problem? Thanks for your help Attila ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Latest DAPLink firmware doesn't work with OpenOCD.
Dear OpenOCD developers, I've bought the SWDAP probe from ARM (see https://github.com/ARMmbed/mbed-HDK-Eagle-Projects/tree/master/DAPLink/Probes/SWDAP , distributed by L-Tek). This probe works fine with OpenOCD. But when I flash the latest DAPLink firmware v0254 onto the probe (see https://github.com/ARMmbed/DAPLink), it doesn't work anymore. Even earlier DAPLink firmware versions v0253 and v0252 make OpenOCD crash. Please have a look at my StackOverflow question, where I explain all the details: https://electronics.stackexchange.com/questions/465577/daplink-firmware-doesnt-operate-with-openocd You can also have a look at the GitHub issue on DAPLink (but the StackOverflow question goes into more details): https://github.com/ARMmbed/DAPLink/issues/665 It's not sure if the problem originates from the DAPLink firmware or from OpenOCD. Kind greetings, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Nuvoton probe and chip support
Dear OpenOCD developers, I'm trying to get the Nuvoton board "NuMaker-M032SE V1.3" to work (see https://www.nuvoton.com/hq/board/numaker-m032se). This board has: - Target chip: M032SE3AE - On-board flash/debug probe: Nu-Link2-Me I looked around in the "scripts/target" folder from my OpenOCD installation, and found the "numicro.cfg" file. I suppose this is the correct target config file. I also looked around in the "scripts/interface" folder to find the config file for this "Nu-Link2-Me" flash/debug probe. Unfortunately, I can't find the right file. Do you have a config file for this flash/debug probe? Thank you so much. Kind greetings, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Nuvoton probe and chip support
Hi @Tommy Murphy, Thank you very much for your quick reply. This is certainly helpful. Unfortunately, I'm not a hero in these kind of things (building OpenOCD from the sources). In fact, I use the following guide to make my Windows build: https://www.playembedded.org/blog/building-openocd-under-windows-using-msys2/ This OpenOCD for Windows build-tutorial makes use of a repository from Alex Pux (founder of MSYS2). I think it pulls the latest master branch from Git (or some other version control system) and builds it. In other words: as long as this Nuvoton probe support doesn't make it to the main branch, I'm screwed... Why didn't it actually make it to the main branch? Kind greetings, Kristof Van: "Tommy Murphy" Aan: "kristof mulier" , "openocd-devel" Verzonden: Zondag 17 november 2019 17:19:38 Onderwerp: Re: Nuvoton probe and chip support Doesn't look like that probe is supported in the master openocd project: [ https://repo.or.cz/openocd.git/tree/HEAD:/src/jtag/drivers | https://repo.or.cz/openocd.git/tree/HEAD:/src/jtag/drivers ] However this fork seems to have support for it: [ https://github.com/OpenNuvoton/OpenOCD-Nuvoton/blob/master/src/jtag/drivers/nulink_usb.c | https://github.com/OpenNuvoton/OpenOCD-Nuvoton/blob/master/src/jtag/drivers/nulink_usb.c ] Not sure why it was never upstreamed. But you might be able to merge/reconcile the latter repo with the former (the master) and build your own version with the requisite support? Hope this helps. ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Building OpenOCD xPack
Hi @everyone, I would like to draw attention to the question from @Tommy Murphy. Git The openocd git repo is at: [ https://sourceforge.net/p/openocd/code/ci/master/tree/ | https://sourceforge.net/p/openocd/code/ci/master/tree/ ] And can be cloned with: git clone git://git.code.sf.net/p/openocd/code Gerrit (zylin) But there is also a gerrit repo at: [ http://openocd.zylin.com/#/admin/projects/openocd | http://openocd.zylin.com/#/admin/projects/openocd ] Or at: [ http://openocd.zylin.com/#/q/status | http://openocd.zylin.com/#/q/status:open ] Which can be cloned with: git clone [ http://openocd.zylin.com/openocd | http://openocd.zylin.com/openocd ] As @Tommy Murphy says, this whole situation is confusing. Where does the actual development happen? To build OpenOCD from the source code with the xPack method (see [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] ), I have to open the file ~/Downloads/openocd-xpack.git/scripts/build.sh and adapt the last three lines: OPENOCD_GIT_URL=git://git.code.sf.net/p/openocd/code OPENOCD_GIT_BRANCH=master OPENOCD_GIT_COMMIT=HEAD What would happen if I give another value to the OPENOCD_GIT_URL variable, such as: OPENOCD_GIT_URL= [ http://openocd.zylin.com/openocd | http://openocd.zylin.com/openocd ] In what way would this impact the build? Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "Liviu Ionescu" Cc: "kristof mulier" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 20:59:19 Onderwerp: Re: Building OpenOCD xPack Is some or all of the OpenOCD development actually done on the zylin repo? All the emails that I get about commits seem to relate to that. Or is that just for reviewing commits before the are accepted to the master openocd repo? [ http://openocd.zylin.com/#/c/5405/ | http://openocd.zylin.com/#/c/5405/ ] I find it all a bit confusing to be honest... From: Liviu Ionescu Sent: Tuesday 21 January 2020 19:11 To: Tommy Murphy Cc: kristof.mul...@telenet.be ; openocd-devel Subject: Re: Building OpenOCD xPack > On 21 Jan 2020, at 20:36, Tommy Murphy wrote: > > ... Maybe all development IS done on the master branch? I guess so, I can't find a separate branch in the official repo. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Latest DAPLink firmware doesn't work with OpenOCD.
Hi Antonio, First of all many thanks for getting the SWDAP probe functioning with OpenOCD ^_^. Probe hardware problem --- I've replaced the three 470Ω resistors with 24Ω resistors (see https://github.com/ARMmbed/mbed-HDK-Eagle-Projects/issues/1#issuecomment-575122948) Probe firmware selection - The firmwares for the SWDAP probe can be found at: https://github.com/ARMmbed/DAPLink/releases The firmware naming convention is: [Version]_[Probe Chip]_[Target Chip]_[Offset].bin The "Probe chip" must match the chip on the probe itself. For the SWDAP, that's the LPC11U35. The "Target Chip" must only match your target if you're planning to use the drag-and-drop flashing feature. But since I'm going to flash with OpenOCD (not through drag-and-drop in the file explorer), this "Target Chip" field doesn't matter. The latest v0254 release has a "general" firmware being "target-agnostic" (the target-field in the name is empty). As I'm not using the drag-and-drop flashing, this choice makes most sense to me. So I've downloaded the "0254_release_package_f499eb6e.zip" from the releases page. After unzipping, I choose the target-agnostic "0254_lpc11u35_0x.bin" firmware binary and put that on my SWDAP probe. Note: Here is explained how exactly I "put" this firmware on my SWDAP probe: https://electronics.stackexchange.com/questions/465187/how-to-update-the-swdap-firmware Probe failure with OpenOCD --- I'm happy to read in your mail that you successfully flashed your target chip with your SWDAP probe and OpenOCD: > Then, with the HW fix, I succeed to run the interface with any FW > version from v0240 to v0254 available in > https://github.com/ARMmbed/DAPLink/releases > I have used as target a STM32F411, and the FW I have flashed is always > the one named > 02XX_lpc11u35_lpc824xpresso_0x.bin > that seams compatible with the STM32 (there is no specific one for STM32!) > All these FW are either cmsis-dap V1.00 or V1.10 Unfortunately, I still have a failure in OpenOCD when I attempt to flash. OpenOCD outputs the following: $ Open On-Chip Debugger 0.10.0+dev-00973-g80f1a92bd (2019-12-02-17:58) $ Licensed under GNU GPL v2 $ For bug reports, read $ http://openocd.org/doc/doxygen/bugs.html $ swd $ srst_only separate srst_nogate srst_open_drain connect_deassert_srst $ $ Error: CMSIS-DAP command CMD_INFO failed. Maybe because the probe firmware could be cmsis-dap V2 instead of cmsis-dap V1? The problem is: I don't know if the firmware is cmsis-dap V1 or cmsis-dap V2. I have no idea where I can see that particular information. On the release page of the probe's firmwares, I simply download the zipped folder "0254_release_package_f499eb6e.zip". I don't know if that's cmsis-dap V1 or V2. Patching OpenOCD - It is truly amazing you were able to patch OpenOCD: > cmsis-dap v2 is a game changer! Does not use USB HID anymore but USB > bulk! The driver in OpenOCD does not support it! > The cmsis-dap messages seams the same, but the protocol below is different. > I have sniffed the USB communication by pyocd and quickly patched > OpenOCD to behave in the same way. It works fine. > I have just pushed in gerrit a test "work-in-progress" proof-of-concept. > http://openocd.zylin.com/5394 > It will require some additional work before being ready for merge, but > it's functional. Unfortunately, I don't know how to build OpenOCD for Windows with your patch in it. The way I build OpenOCD is simply following this guide: https://www.playembedded.org/blog/building-openocd-under-windows-using-msys2/ Perhaps I should change a few commands in the guide to include your patch. But I don't know how. Any help on this is highly appreciated :-) Again many many thanks for your help. I appreciate it very much. Kind greetings, Kristof > Hi Kristof, > > thanks for the SWDAP device you have shipped to me. I succeed to make > it working with OpenOCD. > > First of all, a critical HW issue, already logged in > https://github.com/ARMmbed/mbed-HDK-Eagle-Projects/issues/1 > You need to replace the resistors R9, R11 and R13, otherwise the > interface will not work properly, even with the original cmsis-dap FW > programmed in SWDAP. > Without this change I get errors even with adapter speed at 1 kHz. > > Then, with the HW fix, I succeed to run the interface with any FW > version from v0240 to v0254 available in > https://github.com/ARMmbed/DAPLink/releases > I have used as target a STM32F411, and the FW I have flashed is always > the one named > 02XX_lpc11u35_lpc824xpresso_0x.bin > that seams compatible with the STM32 (there is no specific one for STM32!) > All these FW are either cmsis-dap V1.00 or V1.10 > > In the same repository there are FW that are instead cmsis-dap v2 ! > But only one is available for SWDAP, 0254_lpc11u35__0x.bin > Other
Re: [OpenOCD-devel] Compliance with OpenOCD license
Thank you @Tommy Murphy, I searched on the xpack website and discovered some build instructions here: https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md I noticed that docker is being used. Does this mean that the resulting binaries cannot run natively on Windows? Do they need a docker layer to run on? Van: "Tommy Murphy" Aan: "kristof mulier" , "openocd-devel" Verzonden: Maandag 20 januari 2020 19:12:36 Onderwerp: Re: Compliance with OpenOCD license > please help us to find a better way to build OpenOCD for Windows. On this specific issue I would recommend that you (and anybody else having issues with building OpenOCD) have a look at Liviu Ionescu's xPack OpenOCD project and the docker based build scripts that he provides for (cross) building OpenOCD for Linux/Windows/32/64 bit. By default they build using his own repos/tarballs but with a small tweak (or maybe it can already be parameterised) you can build from any other repo including the master OpenOCD ones. [ https://xpack.github.io/ | https://xpack.github.io/ ] [ https://xpack.github.io/openocd/ | https://xpack.github.io/openocd/ ] Hope this helps. From: kristof.mul...@telenet.be Sent: Monday 20 January 2020 17:41 To: openocd-devel Subject: [OpenOCD-devel] Compliance with OpenOCD license Dear OpenOCD developers, We're building a new IDE for microcontrollers (see https://embeetle.com). Our IDE uses OpenOCD to flash the microcontroller. I compile OpenOCD for Windows using the guide from Rocco Marco: https://www.playembedded.org/blog/building-openocd-under-windows-using-msys2/ To comply with the OpenOCD license, we will: 1. Mention on our website that we use OpenOCD as a third-party tool in our IDE. 2. Show the OpenOCD license on our website (along with licenses of other third-party tools we're using). 3. Show the OpenOCD license in the license agreement the user has to accept when first opening our IDE. However, the OpenOCD license also states that we must provide the OpenOCD source code to our users. But we have a few questions related to this requirement: 1. Do we have to host the OpenOCD source code on our server? Or is linking to the OpenOCD GitHub enough? 2. If we must host the OpenOCD source code on our server, then please help us to find a better way to build OpenOCD for Windows. The guide from Rocco Marco (see link above) is a sequence of commands to create (build?) the OpenOCD binary. To be honest, I simply follow the procedure blindly, and I'm happy to get the binaries in the end. The sequence of commands should be altered somehow such that the source code is pulled in and zipped to some location. But I don't have a clue how. If you have another guide on how to build OpenOCD (and pull in the source code simultaneously), please let me know. ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Compliance with OpenOCD license
Hi @Liviu Ionescu, > The scripts have lots of configuration environment > variables, if you want to build a more recent version, > you need to tweak them. > [..] Uh oh... I have not even the foggiest idea how to "tweak" your build scripts. To be honest, I was hoping to simply run the build script and watch the OpenOCD Windows binaries showing up magically :-) Unfortunately it doesn't seem to be that simple. > However please note that the scripts are not specific > for generating production binaries, which have certain > requirements, and are less suitable for experimenting > with builds. When I'm "experimenting with a build" this is what I do: I connect the microcontroller and the probe. Then I start OpenOCD and feed it with the right config files. If OpenOCD connects to the chip and is able to flash a firmware, I consider the experiment to be successful. So for this kind of "experiments", a "production binary" is perfectly fine. I don't need a "debug binary". Many thanks for your help :-) ----- Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "Tommy Murphy" , "openocd-devel" Verzonden: Maandag 20 januari 2020 20:46:23 Onderwerp: Re: [OpenOCD-devel] Compliance with OpenOCD license > On 20 Jan 2020, at 21:36, kristof.mul...@telenet.be wrote: > > ... I conclude this particular OpenOCD executable was built last summer. That's correct. Since OpenOCD has no release schedule, I have no idea when to make xPack releases. > .. I suppose your > instructions to build the OpenOCD xPack will run smoothly in Ubuntu? Yes. The scripts have lots of configuration environment variables, if you want to build a more recent version, you need to tweak them. There is also a script to build native binaries, intended for debug sessions, but I'm not sure you can generate Windows binaries. However please note that the scripts are not specific for generating production binaries, which have certain requirements, and are less suitable for experimenting with builds. After playing with the scripts you'll probably prefer to use the already made binaries. FYI, I plan for a new release shortly. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Compliance with OpenOCD license
Dear OpenOCD developers, We're building a new IDE for microcontrollers (see https://embeetle.com). Our IDE uses OpenOCD to flash the microcontroller. I compile OpenOCD for Windows using the guide from Rocco Marco: https://www.playembedded.org/blog/building-openocd-under-windows-using-msys2/ To comply with the OpenOCD license, we will: 1. Mention on our website that we use OpenOCD as a third-party tool in our IDE. 2. Show the OpenOCD license on our website (along with licenses of other third-party tools we're using). 3. Show the OpenOCD license in the license agreement the user has to accept when first opening our IDE. However, the OpenOCD license also states that we must provide the OpenOCD source code to our users. But we have a few questions related to this requirement: 1. Do we have to host the OpenOCD source code on our server? Or is linking to the OpenOCD GitHub enough? 2. If we must host the OpenOCD source code on our server, then please help us to find a better way to build OpenOCD for Windows. The guide from Rocco Marco (see link above) is a sequence of commands to create (build?) the OpenOCD binary. To be honest, I simply follow the procedure blindly, and I'm happy to get the binaries in the end. The sequence of commands should be altered somehow such that the source code is pulled in and zipped to some location. But I don't have a clue how. If you have another guide on how to build OpenOCD (and pull in the source code simultaneously), please let me know. ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Compliance with OpenOCD license
Waw, that is marvellous. Thank you very much @Liviu Ionescu I will try to run the build scripts. The result will be an xPack, right? I've got no idea what an xPack actually is, but I suppose the Windows binaries for OpenOCD will be somewhere inside the xPack ;-) - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "Tommy Murphy" Cc: "kristof mulier" , "openocd-devel" Verzonden: Maandag 20 januari 2020 19:52:45 Onderwerp: Re: [OpenOCD-devel] Compliance with OpenOCD license > On 20 Jan 2020, at 20:43, Tommy Murphy wrote: > > Over the years Liviu's approach is by far the simplest that I have come > across for cross compiling for Windows and for compiling for Linux. The build scripts are quite complex, but the point is to generate standalone binaries the run effortlessly on all supported platforms, in other words without unusual and possibly incompatible dependencies. The supported platforms are: - Windows 32 - Windows 64 - Linux x86_64 - Linux i686 - macOS x86_64 Experimental support was recently added for: - Linux armhf - Linux aarch64 (yes, you can run OpenOCD on Raspberry Pi class systems!) Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Compliance with OpenOCD license
Thank you @Liviu Ionescu, I just downloaded an xPack from https://github.com/xpack-dev-tools/openocd-xpack/releases and behold, there are Windows binaries inside! I run the OpenOCD executable and it prints: $ xPack OpenOCD, 64-bit Open On-Chip Debugger 0.10.0+dev (2019-07-17-11:28) $ Licensed under GNU GPL v2 So I conclude this particular OpenOCD executable was built last summer. Thank you @Liviu Ionescu :-) > "Well if you insist, you can do it, but the purpose of > the xPack OpenOCD project is exactly to avoid users having > to run any build scripts and instead use the provided > binaries." I'm grateful for the xPacks you provide. I'm happy to have them discovered today. However, sometimes I'm trying a new microcontroller and need the latest bleeding-edge OpenOCD build. Therefore, I will try to follow your guide to build the OpenOCD xPack. I'm currently instal- ling Virtual Box on my Windows 10 computer to run an Ubuntu virtual machine. I suppose your instructions to build the OpenOCD xPack will run smoothly in Ubuntu? - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "Tommy Murphy" , "openocd-devel" Verzonden: Maandag 20 januari 2020 20:18:11 Onderwerp: Re: [OpenOCD-devel] Compliance with OpenOCD license > On 20 Jan 2020, at 21:09, kristof.mul...@telenet.be wrote: > > Waw, that is marvellous. > Thank you very much @Liviu Ionescu You're welcome! > I will try to run the build scripts. Well if you insist, you can do it, but the purpose of the xPack OpenOCD project is exactly to avoid users having to run any build scripts and instead use the provided binaries. > The result will be an xPack, right? Not exactly, if you run it on Windows the result will be an error :-( > I've got no idea what an xPack actually is, https://xpack.github.io > but I suppose the Windows binaries for OpenOCD will be somewhere inside the > xPack ;-) The windows binaries, together with all other binaries (linux, mac) are available from: https://github.com/xpack-dev-tools/openocd-xpack/releases Arm binaries are available from https://github.com/xpack-dev-tools/pre-releases/releases/tag/v1.0 If you are using the arm-none-eabi-gcc, you might also be interested of https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases Enjoy, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Building OpenOCD xPack
Hi @Liviu, Hi @Tommy, I'm following the guide(s) on the xPack website. However, I got stuck when executing the fourth command on the Prerequisites page (see https://xpack.github.io/xbb/prerequisites/): $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $( lsb_release -cs ) stable" This is the output I get: Hit:1 http://be.archive.ubuntu.com/ubuntu eoan InRelease Hit:2 http://be.archive.ubuntu.com/ubuntu eoan-updates InRelease Hit:3 http://be.archive.ubuntu.com/ubuntu eoan-backports InRelease Get:4 http://security.ubuntu.com/ubuntu eoan-security InRelease [97,5 kB] Ign:5 https://download.docker.com/linux/ubuntu eoan InRelease Err: 6 https://download.docker.com/linux/ubuntu eoan Release 404 Not Found [IP: 13.225.38.15 443] Reading package lists... Done E: The repository 'https://download.docker.com/linux/ubuntu eoan Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. What should I do? --- By the way, I note down every single step of my journey to get OpenOCD compiled on this page: https://forum.embeetle.com/t/building-openocd/137 this way - if the OpenOCD xPack build succeeds - I've got a trace back. --- Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "kristof mulier" , "Liviu Ionescu" Cc: "openocd-devel" Verzonden: Maandag 20 januari 2020 21:33:33 Onderwerp: Re: [OpenOCD-devel] Compliance with OpenOCD license The instructions definitely work on Ubuntu. I've been using Ubuntu 18 lately. Other distros probably work as well. Don't forget to read the "prerequisite" instructions for installing docker. Once that's done it should be trivial to pull and run the build process. As I mentioned earlier if you want to build from the upstream master openocd repo rather than Liviu's snapshots then you may need to pass additional options to build.sh or maybe edit even edit the scripts. I can't remember offhand but I could check later if necessary. Best to pipeclean the build process as is first before changing anything in any case. From: kristof.mul...@telenet.be Sent: Monday, January 20, 2020 7:58:25 PM To: Liviu Ionescu Cc: Tommy Murphy ; openocd-devel Subject: Re: [OpenOCD-devel] Compliance with OpenOCD license Hi @Liviu Ionescu, > The scripts have lots of configuration environment > variables, if you want to build a more recent version, > you need to tweak them. > [..] Uh oh... I have not even the foggiest idea how to "tweak" your build scripts. To be honest, I was hoping to simply run the build script and watch the OpenOCD Windows binaries showing up magically :-) Unfortunately it doesn't seem to be that simple. > However please note that the scripts are not specific > for generating production binaries, which have certain > requirements, and are less suitable for experimenting > with builds. When I'm "experimenting with a build" this is what I do: I connect the microcontroller and the probe. Then I start OpenOCD and feed it with the right config files. If OpenOCD connects to the chip and is able to flash a firmware, I consider the experiment to be successful. So for this kind of "experiments", a "production binary" is perfectly fine. I don't need a "debug binary". Many thanks for your help :-) - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "Tommy Murphy" , "openocd-devel" Verzonden: Maandag 20 januari 2020 20:46:23 Onderwerp: Re: [OpenOCD-devel] Compliance with OpenOCD license > On 20 Jan 2020, at 21:36, kristof.mul...@telenet.be wrote: > > ... I conclude this particular OpenOCD executable was built last summer. That's correct. Since OpenOCD has no release schedule, I have no idea when to make xPack releases. > .. I suppose your > instructions to build the OpenOCD xPack will run smoothly in Ubuntu? Yes. The scripts have lots of configuration environment variables, if you want to build a more recent version, you need to tweak them. There is also a script to build native binaries, intended for debug sessions, but I'm not sure you can generate Windows binaries. However please note that the scripts are not specific for generating production binaries, which have certain requirements, and are less suitable for experimenting with builds. After playing with the scripts you'll probably prefer to use the already made binaries. FYI, I plan for a new release shortly. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Building OpenOCD xPack
Thank you @Tommy Murphy! I will proceed with the workaround you proposed :D Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 15:50:24 Onderwerp: Re: Building OpenOCD xPack That issue is unfortunate but is ultimately a problem at the docker repo end. The workaround here worked for me to get docker installed: [ https://github.com/docker/for-linux/issues/833#issuecomment-544236041 | https://github.com/docker/for-linux/issues/833#issuecomment-544236041 ] However when adding the user to the docker group I always found that I had to reboot rather than just logout and login again: [ https://xpack.github.io/xbb/prerequisites/#configure-docker-to-run-as-a-regular-user | https://xpack.github.io/xbb/prerequisites/#configure-docker-to-run-as-a-regular-user ] Once all that's done and then I install git the build proceeds fine on 19.10 as per the following instructions: [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] Hope this helps. Cheers Tommy From: Tommy Murphy Sent: Tuesday 21 January 2020 14:24 To: kristof.mul...@telenet.be Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack I tried Ubuntu 19.10 and get the same error as Kristof. Looks like a problem with the docker repos: [ https://github.com/docker/for-linux/issues/833 | https://github.com/docker/for-linux/issues/833 ] There's a workaround in that issue. I generally try to stick to LTS versions for production work. Hope this helps Cheers Tommy From: Tommy Murphy Sent: Tuesday 21 January 2020 12:54 To: kristof.mul...@telenet.be Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack Hi Kristof I just followed the prerequisites installation instructions to install docker on a clean Ubuntu 18 virtual machine and it all worked fine for me. See attached. Cheers Tommy From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 11:56 To: Tommy Murphy Cc: Liviu Ionescu ; openocd-devel Subject: Building OpenOCD xPack Hi @Liviu, Hi @Tommy, I'm following the guide(s) on the xPack website. However, I got stuck when executing the fourth command on the Prerequisites page (see https://xpack.github.io/xbb/prerequisites/): $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $( lsb_release -cs ) stable" This is the output I get: Hit:1 http://be.archive.ubuntu.com/ubuntu eoan InRelease Hit:2 http://be.archive.ubuntu.com/ubuntu eoan-updates InRelease Hit:3 http://be.archive.ubuntu.com/ubuntu eoan-backports InRelease Get:4 http://security.ubuntu.com/ubuntu eoan-security InRelease [97,5 kB] Ign:5 https://download.docker.com/linux/ubuntu eoan InRelease Err: 6 https://download.docker.com/linux/ubuntu eoan Release 404 Not Found [IP: 13.225.38.15 443] Reading package lists... Done E: The repository 'https://download.docker.com/linux/ubuntu eoan Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. What should I do? --- By the way, I note down every single step of my journey to get OpenOCD compiled on this page: https://forum.embeetle.com/t/building-openocd/137 this way - if the OpenOCD xPack build succeeds - I've got a trace back. --- Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "kristof mulier" , "Liviu Ionescu" Cc: "openocd-devel" Verzonden: Maandag 20 januari 2020 21:33:33 Onderwerp: Re: [OpenOCD-devel] Compliance with OpenOCD license The instructions definitely work on Ubuntu. I've been using Ubuntu 18 lately. Other distros probably work as well. Don't forget to read the "prerequisite" instructions for installing docker. Once that's done it should be trivial to pull and run the build process. As I mentioned earlier if you want to build from the upstream master openocd repo rather than Liviu's snapshots then you may need to pass additional options to build.sh or maybe edit even edit the scripts. I can't remember offhand but I could check later if necessary. Best to pipeclean the build process as is first before changing anything in any case. From: kristof.mul...@telenet.be Sent: Monday, January 20, 2020 7:58:25 PM To: Liviu Ionescu Cc: Tommy Murphy ; openocd-devel Subject: Re: [OpenOCD-devel] Compliance with OpenOCD license Hi @Liviu Ionescu, > The scripts have lots of configuration environment > variables, if you want to build a more recent version, > you need to tweak them. > [..] Uh oh... I have not even the foggiest idea how to "tweak" your bu
Re: [OpenOCD-devel] Building OpenOCD xPack
Thank you @Tommy Murphy. I thought it would be this way, but I'm happy to get it confirmed. Basically I'm a hardware guy (PCB design, ...) who's also getting involved into software design in the past few years. I'm very thankful to people like you (@Tommy Murphy) and @Liviu Ionescu, for helping me out :-) Kind greetings. Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 16:01:18 Onderwerp: Re: Building OpenOCD xPack Great - another thing to note in case it was not clear - even when running on, say, Ubuntu 19.10 the xPack stuff builds under an older Linux (CentOS 6 I think) docker image with a newer than default compiler resulting in Linux executables that run on a wider set of distros/versions than if built natively. A bit like the Holy Build Box approach mentioned earlier ( [ https://github.com/phusion/holy-build-box | https://github.com/phusion/holy-build-box ] ). This is another clear benefit of building using the xPack scripts. From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 14:58 To: Tommy Murphy Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack Thank you @Tommy Murphy! I will proceed with the workaround you proposed :D Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 15:50:24 Onderwerp: Re: Building OpenOCD xPack That issue is unfortunate but is ultimately a problem at the docker repo end. The workaround here worked for me to get docker installed: [ https://github.com/docker/for-linux/issues/833#issuecomment-544236041 | https://github.com/docker/for-linux/issues/833#issuecomment-544236041 ] However when adding the user to the docker group I always found that I had to reboot rather than just logout and login again: [ https://xpack.github.io/xbb/prerequisites/#configure-docker-to-run-as-a-regular-user | https://xpack.github.io/xbb/prerequisites/#configure-docker-to-run-as-a-regular-user ] Once all that's done and then I install git the build proceeds fine on 19.10 as per the following instructions: [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] Hope this helps. Cheers Tommy From: Tommy Murphy Sent: Tuesday 21 January 2020 14:24 To: kristof.mul...@telenet.be Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack I tried Ubuntu 19.10 and get the same error as Kristof. Looks like a problem with the docker repos: [ https://github.com/docker/for-linux/issues/833 | https://github.com/docker/for-linux/issues/833 ] There's a workaround in that issue. I generally try to stick to LTS versions for production work. Hope this helps Cheers Tommy From: Tommy Murphy Sent: Tuesday 21 January 2020 12:54 To: kristof.mul...@telenet.be Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack Hi Kristof I just followed the prerequisites installation instructions to install docker on a clean Ubuntu 18 virtual machine and it all worked fine for me. See attached. Cheers Tommy From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 11:56 To: Tommy Murphy Cc: Liviu Ionescu ; openocd-devel Subject: Building OpenOCD xPack Hi @Liviu, Hi @Tommy, I'm following the guide(s) on the xPack website. However, I got stuck when executing the fourth command on the Prerequisites page (see https://xpack.github.io/xbb/prerequisites/): $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $( lsb_release -cs ) stable" This is the output I get: Hit:1 http://be.archive.ubuntu.com/ubuntu eoan InRelease Hit:2 http://be.archive.ubuntu.com/ubuntu eoan-updates InRelease Hit:3 http://be.archive.ubuntu.com/ubuntu eoan-backports InRelease Get:4 http://security.ubuntu.com/ubuntu eoan-security InRelease [97,5 kB] Ign:5 https://download.docker.com/linux/ubuntu eoan InRelease Err: 6 https://download.docker.com/linux/ubuntu eoan Release 404 Not Found [IP: 13.225.38.15 443] Reading package lists... Done E: The repository 'https://download.docker.com/linux/ubuntu eoan Release' does not have a Release file. N: Updating from such a repository can't be done securely, and is therefore disabled by default. N: See apt-secure(8) manpage for repository creation and user configuration details. What should I do? --- By the way, I note down every single step of my journey to get OpenOCD compiled on this page: https://forum.embeetle.com/t/building-openocd/137 this way - if the OpenOCD xPack build succeeds - I've got a trace back. ------- Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "kristof mulier" , "Liviu Iones
Re: [OpenOCD-devel] Building OpenOCD xPack
My apologies to bother you guys again, But I got stuck once more. I successfully completed the prerequisites (see https://xpack.github.io/xbb/prerequisites/) so I can start updating the git repos (see "How to build distributions" in the guide at https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md): $ cd ~ /Downloads/openocd -xpack.git $ git checkout master warning: unable to rmdir 'scripts/helper' : Directory not empty Branch 'master' set up to track remote branch 'master' from 'origin' . Switched to a new branch 'master' $ git remote add upstream git: / /git.code.sf.net/p /openocd/code $ git remote -v origin https://github.com/xpack-dev-tools/openocd-xpack.git (fetch) origin https://github.com/xpack-dev-tools/openocd-xpack.git (push) upstreamgit://git.code.sf.net/p/openocd/code (fetch) upstreamgit://git.code.sf.net/p/openocd/code (push) $ git merge upstream/master merge: upstream/master - not something we can merge For some reason, the merging fails. But I have no clue why exactly. Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 16:14:23 Onderwerp: Re: Building OpenOCD xPack No problem Kristof. All the kudos goes to Liviu though for developing the scripts. I just use them! From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 15:10 To: Tommy Murphy Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack Thank you @Tommy Murphy. I thought it would be this way, but I'm happy to get it confirmed. Basically I'm a hardware guy (PCB design, ...) who's also getting involved into software design in the past few years. I'm very thankful to people like you (@Tommy Murphy) and @Liviu Ionescu, for helping me out :-) Kind greetings. Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 16:01:18 Onderwerp: Re: Building OpenOCD xPack Great - another thing to note in case it was not clear - even when running on, say, Ubuntu 19.10 the xPack stuff builds under an older Linux (CentOS 6 I think) docker image with a newer than default compiler resulting in Linux executables that run on a wider set of distros/versions than if built natively. A bit like the Holy Build Box approach mentioned earlier ( [ https://github.com/phusion/holy-build-box | https://github.com/phusion/holy-build-box ] ). This is another clear benefit of building using the xPack scripts. From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 14:58 To: Tommy Murphy Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack Thank you @Tommy Murphy! I will proceed with the workaround you proposed :D Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 15:50:24 Onderwerp: Re: Building OpenOCD xPack That issue is unfortunate but is ultimately a problem at the docker repo end. The workaround here worked for me to get docker installed: [ https://github.com/docker/for-linux/issues/833#issuecomment-544236041 | https://github.com/docker/for-linux/issues/833#issuecomment-544236041 ] However when adding the user to the docker group I always found that I had to reboot rather than just logout and login again: [ https://xpack.github.io/xbb/prerequisites/#configure-docker-to-run-as-a-regular-user | https://xpack.github.io/xbb/prerequisites/#configure-docker-to-run-as-a-regular-user ] Once all that's done and then I install git the build proceeds fine on 19.10 as per the following instructions: [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] Hope this helps. Cheers Tommy From: Tommy Murphy Sent: Tuesday 21 January 2020 14:24 To: kristof.mul...@telenet.be Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack I tried Ubuntu 19.10 and get the same error as Kristof. Looks like a problem with the docker repos: [ https://github.com/docker/for-linux/issues/833 | https://github.com/docker/for-linux/issues/833 ] There's a workaround in that issue. I generally try to stick to LTS versions for production work. Hope this helps Cheers Tommy From: Tommy Murphy Sent: Tuesday 21 January 2020 12:54 To: kristof.mul...@telenet.be Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack Hi Kristof I just followed the prerequisites installation instructions to install docker on a clean Ubuntu 18 virtual machine and it all worked fine for me. See attached. Cheers Tommy From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 11:56 To: Tommy
Re: [OpenOCD-devel] Building OpenOCD xPack
Hi @Tommy Murphy and @Liviu Ionescu, I've tried some more things to get the merge done. Here is what I tried: # Navigate to the git repo # $ cd ~ /Downloads/openocd -xpack.git # Checkout the master # --- $ git checkout master warning: unable to rmdir 'scripts/helper' : Directory not empty Branch 'master' set up to track remote branch 'master' from 'origin' . Switched to a new branch 'master' # Make sure Git knows the upstream remote repo # -- -- $ git remote add upstream git: / /git.code.sf.net/p /openocd/code # View the Git remote repos info # -- $ git remote -v origin https://github.com/xpack-dev-tools/openocd-xpack.git (fetch) origin https://github.com/xpack-dev-tools/openocd-xpack.git (push) upstream git://git.code.sf.net/p/openocd/code (fetch) upstream git://git.code.sf.net/p/openocd/code (push) # Fetch the upstream repo # --- $ git fetch upstream warning: no common commits remote: Enumerating objects: 62390, done. remote: Counting objects: 100% (62390/62390), done. remote: Compressing objects: 100% (26325/26325), done. remote: Total 62390 (delta 51266), reused 43580 (delta 35902) Receiving objects: 100% (62390/62390), 14.18 MiB | 4.84 MiB/s, done. Resolving deltas: 100% (51266/51266), done. >From git://git.code.sf.net/p/openocd/code * [new branch]master -> upstream/master * [new branch]v0.6.1 -> upstream/v0.6.1 * [new tag] v0.6.1 -> v0.6.1 [...] # Checkout the upstream master # $ git checkout upstream/master Note: checking out 'upstream/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at f9809950 mips_ejtag: there is no DCR.MIPS64 bit # Checkout the local master again # --- $ git checkout master Previous HEAD position was f9809950 mips_ejtag: there is no DCR.MIPS64 bit Switched to branch 'master' Your branch is up to date with 'origin/master' . # Try to merge # $ git merge upstream/master fatal: refusing to merge unrelated histories What am I doing wrong? Kind greetings, Kristof Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 16:43:05 Onderwerp: Re: Building OpenOCD xPack Did you first pipeclean the standard xPack build process by just running the script that pulls the build scripts and then running, say, bash ~/Downloads/xpack-openocd-build/scripts/build.sh --win64 Just to make sure that that works? I was going to separately try to configure the scripts to build from upstream by configuring some or all of the following env vars: OPENOCD_GIT_URL OPENOCD_GIT_BRANCH OPENOCD_GIT_COMMIT I just didn't get a chance to try this yet but should be able to in the next hour or so. I don't think that trying to merge Liviu's openocd forked repo with the master/upstream repo is going to work (easily). But I've never tried it. From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 15:39 To: Tommy Murphy Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack My apologies to bother you guys again, But I got stuck once more. I successfully completed the prerequisites (see https://xpack.github.io/xbb/prerequisites/) so I can start updating the git repos (see "How to build distributions" in the guide at https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md): $ cd ~ /Downloads/openocd -xpack.git $ git checkout master warning: unable to rmdir 'scripts/helper' : Directory not empty Branch 'master' set up to track remote branch 'master' from 'origin' . Switched to a new branch 'master' $ git remote add upstream git: / /git.code.sf.net/p /openocd/code $ git remote -v origin https://github.com/xpack-dev-tools/openocd-xpack.git (fetch) origin https://github.com/xpack-dev-tools/openocd-xpack.git (push) upstreamgit://git.code.sf.net/p/openocd/code (fetch) upstreamgit://git.code.sf.net/p/openocd/code (push) $ git merge upstream/master merge: upstream/master - not something we can merge For some reason, the merging fails. But I have no clue why exactly. Kind greetings, Kristof Mulier Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 16:14:23 Onderwerp: Re: Building OpenOCD xPack No problem Kristof.
Re: [OpenOCD-devel] Building OpenOCD xPack
Hi @Tommy Murphy, The folder ~/Downloads/openocd-xpack.git/scripts does not contain a file defs-source.sh : $ cd ~/Downloads/openocd-xpack.git/scripts $ ls --all . .. helper $ cd helper $ ls --all . .. common-functions-source.sh container-functions-source.sh .git host-functions-source.sh LICENSE README.md templates.sh So I don't know how to proceed... Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 17:44:16 Onderwerp: Re: Building OpenOCD xPack Sorry - obviously change the URL, beanch and/or commit as necessary. I just used the latest mirror repo, master branch and latest commit in this example. At the moment you MUST provide ALL of these - e.g. you cannot omit the commit expecting the script to default to the latest. From: Tommy Murphy Sent: Tuesday 21 January 2020 16:42 To: kristof.mul...@telenet.be Cc: openocd-devel Subject: Re: Building OpenOCD xPack FWIW this worked for me to use Liviu's xPack Project OpenOCD build scripts to build from the upstream master repo instead of Liviu's repos/snapshots... Edit your local copy of ~/Downloads/openocd-xpack.git/scripts/defs-source.sh https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L41 and add the following at the end of the file: OPENOCD_GIT_URL=git://git.code.sf.net/p/openocd/code OPENOCD_GIT_BRANCH=master OPENOCD_GIT_COMMIT=f98099507f509db9a18c70365490a6b9f67108db and then build as normal: bash ~/Downloads/openocd-xpack.git/scripts/build.sh --all (or instead of --all any combination of --linux32, --linux64, --win32, --win64 etc.). From: Tommy Murphy Sent: Tuesday 21 January 2020 16:06 To: kristof.mul...@telenet.be Cc: openocd-devel Subject: Re: [OpenOCD-devel] Building OpenOCD xPack As I said I would not try to merge Liviu's repo with upstream just yet. In any case the scripts will try to pull his stuff anew anyway while building. It won't use anything local. Did you pipeclean the standard xPack build process as I asked? From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 16:04 To: Tommy Murphy Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack Hi @Tommy Murphy and @Liviu Ionescu, I've tried some more things to get the merge done. Here is what I tried: # Navigate to the git repo # $ cd ~ /Downloads/openocd -xpack.git # Checkout the master # --- $ git checkout master warning: unable to rmdir 'scripts/helper' : Directory not empty Branch 'master' set up to track remote branch 'master' from 'origin' . Switched to a new branch 'master' # Make sure Git knows the upstream remote repo # -- -- $ git remote add upstream git: / /git.code.sf.net/p /openocd/code # View the Git remote repos info # -- $ git remote -v origin https://github.com/xpack-dev-tools/openocd-xpack.git (fetch) origin https://github.com/xpack-dev-tools/openocd-xpack.git (push) upstream git://git.code.sf.net/p/openocd/code (fetch) upstream git://git.code.sf.net/p/openocd/code (push) # Fetch the upstream repo # --- $ git fetch upstream warning: no common commits remote: Enumerating objects: 62390, done. remote: Counting objects: 100% (62390/62390), done. remote: Compressing objects: 100% (26325/26325), done. remote: Total 62390 (delta 51266), reused 43580 (delta 35902) Receiving objects: 100% (62390/62390), 14.18 MiB | 4.84 MiB/s, done. Resolving deltas: 100% (51266/51266), done. >From git://git.code.sf.net/p/openocd/code * [new branch]master -> upstream/master * [new branch]v0.6.1 -> upstream/v0.6.1 * [new tag] v0.6.1 -> v0.6.1 [...] # Checkout the upstream master # $ git checkout upstream/master Note: checking out 'upstream/master'. You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout. If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example: git checkout -b HEAD is now at f9809950 mips_ejtag: there is no DCR.MIPS64 bit # Checkout the local master again # --- $ git checkout master Previous HEAD position was f9809950 mips_ejtag: there is no DCR.MIPS64 bit Switched to branch 'master' Your branch is up to date with 'origin/master' . # Try to merge # $ git merge upstream/master fatal: refusing to merge unrelated histories What am I doing wrong? Kind greetings, Kristof Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "Liviu Ionescu" , "openocd-devel" Verzonden:
Re: [OpenOCD-devel] Thank you for xPack
Hi @Liviu Ionescu, I found the new donate button on the xPack website, and I've just donated €60. Kind greetings, Kristof - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Verzonden: Dinsdag 21 januari 2020 17:20:32 Onderwerp: Re: Thank you for xPack > On 21 Jan 2020, at 11:29, kristof.mul...@telenet.be wrote: > > I was looking for a "donations" button on your xPack website, > but couldn't find one. Added at the end of the home page. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Building OpenOCD xPack
Hi @Tommy Murphy, I did not issue the command: $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash But I issued the following commands instead: $ rm -rf ~/Downloads/openocd-xpack.git $ git clone --recurse-submodules --branch xpack-develop https://github.com/xpack-dev-tools/openocd-xpack.git \ ~/Downloads/openocd-xpack.git Note the flag --branch xpack-develop in the command. The guide from Liviu shows one example with and one without this flag. I'm not sure if this flag has anything to do with the problem? Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 18:01:43 Onderwerp: Re: Building OpenOCD xPack > The folder ~/Downloads/openocd-xpack.git/scripts does not contain a file > defs-source.sh : Are you sure that you did this to retrieve them? [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash Definitely that file should exist - see the build scripts repo: [ https://github.com/xpack-dev-tools/openocd-xpack/tree/xpack/scripts | https://github.com/xpack-dev-tools/openocd-xpack/tree/xpack/scripts ] Just to clarify - by adding the following to .../scripts/defs-source.h at the end of the file you can build from the upstream//master repo: OPENOCD_GIT_URL=git://git.code.sf.net/p/openocd/code OPENOCD_GIT_BRANCH=master OPENOCD_GIT_COMMIT=HEAD Liviu - yes, HEAD instead of a commit id works fine. From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 16:53 To: Tommy Murphy Cc: openocd-devel Subject: Re: Building OpenOCD xPack Hi @Tommy Murphy, The folder ~/Downloads/openocd-xpack.git/scripts does not contain a file defs-source.sh : $ cd ~/Downloads/openocd-xpack.git/scripts $ ls --all . .. helper $ cd helper $ ls --all . .. common-functions-source.sh container-functions-source.sh .git host-functions-source.sh LICENSE README.md templates.sh So I don't know how to proceed... Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 17:44:16 Onderwerp: Re: Building OpenOCD xPack Sorry - obviously change the URL, beanch and/or commit as necessary. I just used the latest mirror repo, master branch and latest commit in this example. At the moment you MUST provide ALL of these - e.g. you cannot omit the commit expecting the script to default to the latest. From: Tommy Murphy Sent: Tuesday 21 January 2020 16:42 To: kristof.mul...@telenet.be Cc: openocd-devel Subject: Re: Building OpenOCD xPack FWIW this worked for me to use Liviu's xPack Project OpenOCD build scripts to build from the upstream master repo instead of Liviu's repos/snapshots... Edit your local copy of ~/Downloads/openocd-xpack.git/scripts/defs-source.sh https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L41 and add the following at the end of the file: OPENOCD_GIT_URL=git://git.code.sf.net/p/openocd/code OPENOCD_GIT_BRANCH=master OPENOCD_GIT_COMMIT=f98099507f509db9a18c70365490a6b9f67108db and then build as normal: bash ~/Downloads/openocd-xpack.git/scripts/build.sh --all (or instead of --all any combination of --linux32, --linux64, --win32, --win64 etc.). From: Tommy Murphy Sent: Tuesday 21 January 2020 16:06 To: kristof.mul...@telenet.be Cc: openocd-devel Subject: Re: [OpenOCD-devel] Building OpenOCD xPack As I said I would not try to merge Liviu's repo with upstream just yet. In any case the scripts will try to pull his stuff anew anyway while building. It won't use anything local. Did you pipeclean the standard xPack build process as I asked? From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 16:04 To: Tommy Murphy Cc: Liviu Ionescu ; openocd-devel Subject: Re: Building OpenOCD xPack Hi @Tommy Murphy and @Liviu Ionescu, I've tried some more things to get the merge done. Here is what I tried: # Navigate to the git repo # $ cd ~ /Downloads/openocd -xpack.git # Checkout the master # --- $ git checkout master warning: unable to rmdir 'scripts/helper' : Directory not empty Branch 'master' set up to track remote branch 'master' from 'origin' . Switched to a new branch 'master' # Make sure Git knows the upstream remote repo # -- -- $ git remote add upstream git: / /git.code.sf.net/p /openocd/code # View the Git remote repos info # -- $ git remote -v origin https://github.com/xpack-dev-tools/openocd-xpack.git (fetch) origin https://github.com/xpack-dev-tools/openocd-xpack.git (push) upstream git://git.code.sf.net/p/openocd/code (fetc
Re: [OpenOCD-devel] Building OpenOCD xPack
Hi @Tommy Murphy and @Liviu Ionescu, The build was successful! I transferred the build outputs to Windows 10 and unzipped xpack-openocd-0.10.0-14-win32-x64.zip . Then I run openocd.exe : C:\Users\Kristof\ubuntu_shared\xpack-openocd-0.10.0-14-win32-x64\xpack-openocd-0.10.0-14\bin > openocd.exe Open On-Chip Debugger 0.10.0+dev-01032-gf9809950 (2020-01-21-17:32) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html embedded:startup.tcl:26: Error: Can't find openocd.cfg in procedure 'script' at file "embedded:startup.tcl", line 26 Info : Listening on port for tcl connections Info : Listening on port for telnet connections Error: Debug Adapter has to be specified, see "interface" command embedded:startup.tcl:26: Error: in procedure 'script' at file "embedded:startup.tcl", line 26 The errors are normal because I did not attach any probe. But the point is: the OpenOCD build worked!!! As you can see, it prints: Open On-Chip Debugger 0.10.0+dev-01032-gf9809950 Is this really the latest bleeding-edge version? If anyone can confirm, I would be very happy :-) Many thanks to @Tommy Murphy and @Liviu Ionescu for all the help. Kind greetings, Kristof Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 18:11:25 Onderwerp: Re: Building OpenOCD xPack if you don't use the curl command then you need to do the two commands listed on the instructions page: $ rm -rf ~ /Downloads/openocd-xpack.git $ git clone --recurse-submodules https://github.com/xpack-dev-tools/openocd-xpack.git \ ~/Downloads/openocd-xpack.git the other stuff is about using the develop branch but I have never used it and maybe it's not up to date or something? I suspect that that's more for Liviu when HE'S maintaining the scripts as opposed to an "end user" like you or me who should stick with master? From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 17:09 To: Tommy Murphy Cc: openocd-devel Subject: Re: Building OpenOCD xPack Hi @Tommy Murphy, I did not issue the command: $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash But I issued the following commands instead: $ rm -rf ~/Downloads/openocd-xpack.git $ git clone --recurse-submodules --branch xpack-develop https://github.com/xpack-dev-tools/openocd-xpack.git \ ~/Downloads/openocd-xpack.git Note the flag --branch xpack-develop in the command. The guide from Liviu shows one example with and one without this flag. I'm not sure if this flag has anything to do with the problem? Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 18:01:43 Onderwerp: Re: Building OpenOCD xPack > The folder ~/Downloads/openocd-xpack.git/scripts does not contain a file > defs-source.sh : Are you sure that you did this to retrieve them? [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash Definitely that file should exist - see the build scripts repo: [ https://github.com/xpack-dev-tools/openocd-xpack/tree/xpack/scripts | https://github.com/xpack-dev-tools/openocd-xpack/tree/xpack/scripts ] Just to clarify - by adding the following to .../scripts/defs-source.h at the end of the file you can build from the upstream//master repo: OPENOCD_GIT_URL=git://git.code.sf.net/p/openocd/code OPENOCD_GIT_BRANCH=master OPENOCD_GIT_COMMIT=HEAD Liviu - yes, HEAD instead of a commit id works fine. From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 16:53 To: Tommy Murphy Cc: openocd-devel Subject: Re: Building OpenOCD xPack Hi @Tommy Murphy, The folder ~/Downloads/openocd-xpack.git/scripts does not contain a file defs-source.sh : $ cd ~/Downloads/openocd-xpack.git/scripts $ ls --all . .. helper $ cd helper $ ls --all . .. common-functions-source.sh container-functions-source.sh .git host-functions-source.sh LICENSE README.md templates.sh So I don't know how to proceed... Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 17:44:16 Onderwerp: Re: Building OpenOCD xPack Sorry - obviously change the URL, beanch and/or commit as necessary. I just used the latest mirror repo, master branch and latest commit in this example. At the moment you MUST provide ALL of these - e.g. you cannot omit the commit expecting the script to default to the latest. From: Tommy Murphy Sent: Tuesday 21 January 2020 16:42 To: kristof.mul...@telenet.be Cc: openocd-devel Subject: Re: Building OpenOCD xPack FWIW this
Re: [OpenOCD-devel] Building OpenOCD xPack
Thanks!! You and Liviu made my day :D Van: "Tommy Murphy" Aan: "kristof mulier" , "Liviu Ionescu" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 19:28:01 Onderwerp: Re: Building OpenOCD xPack > The build was successful! Great. The whole process is easier than I probably made it seem! Just follow Liviu's instructions and then edit the scripts/defs-source.sh file. In fact Liviu just accepted a Pull Request from me that adds the required defines commented out so they just need to be uncommented: [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L43 | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L43 ] > Is this really the latest bleeding-edge version? If anyone can confirm, Yes - that's the latest commit in the OpenOCD master repo at the moment: [ https://repo.or.cz/openocd.git/shortlog/f98099507f509db9a18c70365490a6b9f67108db | https://repo.or.cz/openocd.git/shortlog/f98099507f509db9a18c70365490a6b9f67108db ] [ https://repo.or.cz/openocd.git/commit/f98099507f509db9a18c70365490a6b9f67108db | https://repo.or.cz/openocd.git/commit/f98099507f509db9a18c70365490a6b9f67108db ] From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 18:23 To: Tommy Murphy ; Liviu Ionescu Cc: openocd-devel Subject: Re: Building OpenOCD xPack Hi @Tommy Murphy and @Liviu Ionescu, The build was successful! I transferred the build outputs to Windows 10 and unzipped xpack-openocd-0.10.0-14-win32-x64.zip . Then I run openocd.exe : C:\Users\Kristof\ubuntu_shared\xpack-openocd-0.10.0-14-win32-x64\xpack-openocd-0.10.0-14\bin > openocd.exe Open On-Chip Debugger 0.10.0+dev-01032-gf9809950 (2020-01-21-17:32) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html embedded:startup.tcl:26: Error: Can't find openocd.cfg in procedure 'script' at file "embedded:startup.tcl", line 26 Info : Listening on port for tcl connections Info : Listening on port for telnet connections Error: Debug Adapter has to be specified, see "interface" command embedded:startup.tcl:26: Error: in procedure 'script' at file "embedded:startup.tcl", line 26 The errors are normal because I did not attach any probe. But the point is: the OpenOCD build worked!!! As you can see, it prints: Open On-Chip Debugger 0.10.0+dev-01032-gf9809950 Is this really the latest bleeding-edge version? If anyone can confirm, I would be very happy :-) Many thanks to @Tommy Murphy and @Liviu Ionescu for all the help. Kind greetings, Kristof Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 18:11:25 Onderwerp: Re: Building OpenOCD xPack if you don't use the curl command then you need to do the two commands listed on the instructions page: $ rm -rf ~ /Downloads/openocd-xpack.git $ git clone --recurse-submodules https://github.com/xpack-dev-tools/openocd-xpack.git \ ~/Downloads/openocd-xpack.git the other stuff is about using the develop branch but I have never used it and maybe it's not up to date or something? I suspect that that's more for Liviu when HE'S maintaining the scripts as opposed to an "end user" like you or me who should stick with master? From: kristof.mul...@telenet.be Sent: Tuesday 21 January 2020 17:09 To: Tommy Murphy Cc: openocd-devel Subject: Re: Building OpenOCD xPack Hi @Tommy Murphy, I did not issue the command: $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash But I issued the following commands instead: $ rm -rf ~/Downloads/openocd-xpack.git $ git clone --recurse-submodules --branch xpack-develop https://github.com/xpack-dev-tools/openocd-xpack.git \ ~/Downloads/openocd-xpack.git Note the flag --branch xpack-develop in the command. The guide from Liviu shows one example with and one without this flag. I'm not sure if this flag has anything to do with the problem? Van: "Tommy Murphy" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 21 januari 2020 18:01:43 Onderwerp: Re: Building OpenOCD xPack > The folder ~/Downloads/openocd-xpack.git/scripts does not contain a file > defs-source.sh : Are you sure that you did this to retrieve them? [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash Definitely that file should exist - see the build scripts repo: [ https://github.com/xpack-dev-tools/openocd-xpack/tree/xpack/scripts | https://github.com/xpack-dev-tools/openocd-xpack/tree/xpack/scripts ] Just to clarify - by adding the followin
Re: [OpenOCD-devel] Building OpenOCD xPack
Hi @Liviu, Thank you for reminding us. I promise I won't distribute them with these names. I will certainly not push them to the xPack repos. Kind greetings, Kristof - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "Tommy Murphy" , "openocd-devel" Verzonden: Dinsdag 21 januari 2020 19:33:32 Onderwerp: Re: Building OpenOCD xPack > On 21 Jan 2020, at 20:23, kristof.mul...@telenet.be wrote: > > and unzipped xpack-openocd-0.10.0-14-win32-x64.zip. As I mentioned before, the resulting archives are tagged with a version number specific to the xPack release. I guess there are also some files inside the archive which mention this version. Using these binaries for personal usage is perfectly fine, but please be sure you do not make public releases with archives having these exact names, since they may be confusing for people using the xPack binaries. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] cmsis-dap leds stay off while connect
Hi Antonio and Roman, OpenOCD operation with CMSIS-DAP probes === I'm happy to see you're working on OpenOCD support for CMSIS-DAP probes. Some weeks ago, I tried to use OpenOCD with the SWDAP-probe from ARM. The SWDAP is the official ARM probe designed according to the CMSIS-DAP standard. The probe operated just fine with OpenOCD, up to the moment I flashed the latest firmware to the probe. Please have a look at my StackOverflow post: https://electronics.stackexchange.com/questions/465577/daplink-firmware-doesnt-operate-with-openocd I've also posted the problem on the DAPLink GitHub page: https://github.com/ARMmbed/DAPLink/issues/665 Background info === The reason I'm asking help for the SWDAP (and therefore CMSIS-DAP- compliant probes in general) has to do with the microcontroller IDE I'm working on: Embeetle IDE (https://embeetle.com) Embeetle IDE also has a webpage about the SWDAP probe here: https://embeetle.com/#hardware/probes/swdap And even about OpenOCD: https://embeetle.com/#manual/flash/openocd Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] cmsis-dap leds stay off while connect
Hi @Antonio Borneo, Many thanks for your reply, and the time you spend to help me out. I can send you an SWDAP probe. Or I can send you the funds over PayPal so you can buy one directly from the store: https://www.l-tek.com/web-shop/l-tek-swdap-interface/ Please let me know what you prefer. Many thanks :-) Kind greetings, Kristof Mulier - Oorspronkelijk bericht - Van: "Antonio Borneo" Aan: "kristof mulier" Cc: "Roman Elshin" , "openocd-devel" Verzonden: Donderdag 2 januari 2020 12:34:25 Onderwerp: Re: [OpenOCD-devel] cmsis-dap leds stay off while connect On Tue, Dec 31, 2019 at 9:43 AM wrote: > > Hi Antonio and Roman, > > OpenOCD operation with CMSIS-DAP probes > === > I'm happy to see you're working on OpenOCD support for CMSIS-DAP probes. > Some weeks ago, I tried to use OpenOCD with the SWDAP-probe from ARM. The > SWDAP is the official ARM probe designed according to the CMSIS-DAP > standard. The probe operated just fine with OpenOCD, up to the moment I > flashed the latest firmware to the probe. Hi Kristof, I have seen the messages about the daplink issue, but without the adapter I though I cannot do that much, so I dropped it. I have read again all the threads (very quickly, I have to admit) and also downloaded the daplink code from https://github.com/armmbed/DAPLink It is a special implementation of CMSIS-DAP for mbed. The original FW you had in your board was a v0244 or older, because OpenOD recognizes it as Info : CMSIS-DAP: FW Version = 1.0 This string has been changed in DAPLink FW file source/daplink/cmsis-dap/DAP.c with commit https://github.com/ARMmbed/DAPLink/commit/48417e9f8541f51bf2ca2e26a7ee69c5fcb34b80 so the newer FW you have tested v0252 and v0253 report Info : CMSIS-DAP: FW Version = 1.10 and both do not work with OpenOCD. I don't have a cmsis-dap v1.10 to verify if there is already something wrong in OpenOCD. The DAPLink FW v0254 adds many changes. Between them it stops reporting the CMSIS-DAP version "1.10", reporting instead the DAPLink version "0254". Checking the code of DAPLink, looks like it is possible to recompile it for STM32F103 (ST-Link)! Maybe I will have a look at it using an old Nucleo board, but it will depends on my spare time. Or maybe some other OpenOCD developer could take this reply as a hint. Antonio > > Please have a look at my StackOverflow post: > https://electronics.stackexchange.com/questions/465577/daplink-firmware-doesnt-operate-with-openocd > > I've also posted the problem on the DAPLink GitHub page: > https://github.com/ARMmbed/DAPLink/issues/665 > > > Background info > === > The reason I'm asking help for the SWDAP (and therefore CMSIS-DAP- > compliant probes in general) has to do with the microcontroller IDE > I'm working on: Embeetle IDE (https://embeetle.com) > > Embeetle IDE also has a webpage about the SWDAP probe here: > https://embeetle.com/#hardware/probes/swdap > > And even about OpenOCD: > https://embeetle.com/#manual/flash/openocd > > > Kind regards, > Kristof Mulier > > > > > ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Cannot flash to nRF52833
Hi everyone, I'm one of the cofounders of Embeetle IDE - a new free microcontroller IDE. We're using OpenOCD to flash the microcontrollers. So first I'd like to express my gratitude to all of you for this free software. Currently, I'm trying to support a set of microcontrollers from Nordic Semiconductor . I start with the nRF52833 microcontroller (on the PC10100 development board). Unfortunately, OpenOCD has a problem with the flash protection of this device. Everything is explained in my post on the Nordic DevZone: [ https://devzone.nordicsemi.com/f/nordic-q-a/59106/i-m-trying-to-support-nrf52833-in-embeetle-ide-but-flashing-through-openocd-gdb-doesn-t-work | https://devzone.nordicsemi.com/f/nordic-q-a/59106/i-m-trying-to-support-nrf52833-in-embeetle-ide-but-flashing-through-openocd-gdb-doesn-t-work ] Your help is greatly appreciated. Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Cannot flash to nRF52833
Dear Mr. Alan Carvalho de Assis and Mr. Tomas Vanek, Thank you very much for your quick reply. I've tried the command to mass erase the chip. From GDB: (gdb) monitor nrf51 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection Unfortunately, this doesn't work. OpenOCD seems to be unable to handle the chip's write protection. I'm using the following version: Open On-Chip Debugger 0.10.0+dev-00973-g80f1a92bd (2019-12-02-17:58) As you can see, I built this OpenOCD on December 2nd 2019 for Windows 10. I've built it using the xPack method from Mr. Liviu Ionescu (see https://xpack.github.io/ and https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build ) I've just built OpenOCD again today. Now I've got the following version: Open On-Chip Debugger 0.10.0+dev-01133-ge03de33c (2020-03-15-08:55) How can I be sure that merge 5348 (see http://openocd.zylin.com/#/c/5348/) is included in this build? Anyhow, it doesn't look good because I still get the same problem when trying a mass erase: (gdb) monitor nrf51 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection Many thanks for your help ^_^ Kind regards, Kristof Mulier --- On 3/14/20 at 23:35, tom_...@users.sourceforge.net wrote: > The problem was solved by http://openocd.zylin.com/5348 > Please use a newer OpenOCD build. > Tomas --- On 3/14/20 at 23:40, acas...@gmail.com wrote: > Hi Kristof, > I just you missed the mass erase command to fix it, I faced same issue > with nRF51 some years ago: > https://acassis.wordpress.com/2015/10/21/nrf51822-and-openocd-cannot-erase-protected-sector-at-0x0/ > > > I think nRF52833 is just same nRF52833 but for industrial grade. I > also used OpenOCD with nRF52: > https://acassis.wordpress.com/2018/04/03/how-to-install-nuttx-on-nordic-nrf52832/ > > > BR, > Alan --- On 3/14/20 at 22:57, kristof.mul...@telenet.be wrote: > Hi everyone, > I'm one of the cofounders of Embeetle IDE - a new free microcontroller IDE. > We're using OpenOCD to flash the microcontrollers. So first I'd like to > express my gratitude to all of you for this free software. > > Currently, I'm trying to support a set of microcontrollers from Nordic > Semiconductor . I start with the nRF52833 microcontroller (on the PC10100 > development board). Unfortunately, OpenOCD has a problem with the flash > protection of this device. Everything is explained in my post on the Nordic > DevZone: > > https://devzone.nordicsemi.com/f/nordic-q-a/59106/i-m-trying-to-support-nrf52833-in-embeetle-ide-but-flashing-through-openocd-gdb-doesn-t-work > > > Your help is greatly appreciated. > Kind regards, > Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Cannot flash to nRF52833
Hi Alan, Thank you very much for your reply. Right now, I'm using an OpenOCD version that I've built today. But I still got this problem: (gdb) monitor nrf5 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection Did the patch http://openocd.zylin.com/#/c/5348/ make it to the master branch? Is there a way to test if the patch is actually in my build? Once again a big thank you to both of you (@Alan and @Tomas) Kind greetings, Kristof Mulier > On 3/15/20, acas...@gmail.com wrote: > Hi Kristof, > I think the nRF52833 has something different from nRF52832 related to > flash protection. > > I think you should to test Tomas' suggestion. > Please note that his patch was include on Dec 12 2019 (you are using > an older version) : > http://openocd.zylin.com/#/c/5348/ > > BR, > Alan > > --- > > On 3/15/20, kristof.mul...@telenet.be wrote: > Hi Alan, > Thank you for your quick response. > I've tried the command nrf5 mass_erase: > > (gdb) monitor nrf5 mass_erase > Flash protection of this nRF device is not supported > Failed to check chip's write protection > > But without success. > What am I doing wrong here? > > > >> --- >> >> On 3/15/20, acas...@gmail.com wrote: >> >> Hi Kristof, >> you are using the command to nrf51, but your nrf52. >> As you could see in the second command I sent you, you should use: >> nrf5 mass_erase >> >> BR, >> Alan >> >> --- >> >> On 3/15/20, kristof.mul...@telenet.be wrote: >> Dear Mr. Alan Carvalho de Assis >> and >> Mr. Tomas Vanek, >> >> Thank you very much for your quick reply. I've tried the >> command to mass erase the chip. From GDB: >> >> (gdb) monitor nrf51 mass_erase >> Flash protection of this nRF device is not supported >> Failed to check chip's write protection >> >> Unfortunately, this doesn't work. OpenOCD seems to be >> unable to handle the chip's write protection. I'm using >> the following version: >> >> Open On-Chip Debugger 0.10.0+dev-00973-g80f1a92bd >> (2019-12-02-17:58) >> >> As you can see, I built this OpenOCD on December 2nd 2019 >> for Windows 10. >> I've built it using the xPack method from Mr. Liviu Ionescu >> (see https://xpack.github.io/ and >> https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build >> ) >> >> >> I've just built OpenOCD again today. Now I've got the following >> version: >> >> Open On-Chip Debugger 0.10.0+dev-01133-ge03de33c >> (2020-03-15-08:55) >> >> How can I be sure that merge 5348 (see >> http://openocd.zylin.com/#/c/5348/) >> is included in this build? >> Anyhow, it doesn't look good because I still get the same problem >> when trying a mass erase: >> >> (gdb) monitor nrf51 mass_erase >> Flash protection of this nRF device is not supported >> Failed to check chip's write protection >> >> Many thanks for your help ^_^ >> Kind regards, >> Kristof Mulier >> >> --- >> >> On 3/14/20 at 23:35, tom_...@users.sourceforge.net wrote: >>> The problem was solved by http://openocd.zylin.com/5348 >>> Please use a newer OpenOCD build. >>> Tomas >> >> --- >> >> On 3/14/20 at 23:40, acas...@gmail.com wrote: >>> Hi Kristof, >>> I just you missed the mass erase command to fix it, I faced same issue >>> with nRF51 some years ago: >>> https://acassis.wordpress.com/2015/10/21/nrf51822-and-openocd-cannot-erase-protected-sector-at-0x0/ >>> >>> >>> I think nRF52833 is just same nRF52833 but for industrial grade. I >>> also used OpenOCD with nRF52: >>> https://acassis.wordpress.com/2018/04/03/how-to-install-nuttx-on-nordic-nrf52832/ >>> >>> >>> BR, >>> Alan >> >> --- >> >> On 3/14/20 at 22:57, kristof.mul...@telenet.be wrote: >>> Hi everyone, >>> I'm one of the cofounders of Embeetle IDE - a new free microcontroller >>> IDE. >>> We're using OpenOCD to flash the microcontrollers. So first I'd like to >>> express my gratitude to all of you for this free software. >>> >>> Currently, I'm trying to support a set of microcontrollers from Nordic >>> Semiconductor . I start with the nRF52833 microcontroller (on the >>> PC10100 >>> >>> development board). Unfortunately, OpenOCD has a problem with the flash >>> protection of this device. Everything is explained in my post on the >>> Nordic >>> DevZone: >>> >>> https://devzone.nordicsemi.com/f/nordic-q-a/59106/i-m-trying-to-support-nrf52833-in-embeetle-ide-but-flashing-through-openocd-gdb-doesn-t-work >>> >>> >>> Your help is greatly appreciated. >>> Kind regards, >>> Kristof Mulier >> >> >> > ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Cannot flash to nRF52833
Hi Tomas, Thank you very much :-) Please let me know when you've finished the patch. I'll wait for your message and build OpenOCD again. You're awesome! Kind greetings, Kristof Mulier Van: "Tomas Vanek" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Maandag 16 maart 2020 14:35:53 Onderwerp: Re: [OpenOCD-devel] Cannot flash to nRF52833 Kristof, I confim there is a problem in mass_erase of nRF52833 and 840 Paradoxically the mass erase is completed just fine (you may check using 'flash erase_check 0') and the bogus error message is generated afterwards because protection cannot be read. I'll prepare a patch. [ http://openocd.zylin.com/#/c/5348/ | http://openocd.zylin.com/#/c/5348/ ] addressed the sector by sector erase only and I missed the check after mass erase. I recommend you to standard flash programming by 'program' command [ http://openocd.org/doc/html/Flash-Programming.html#Flash-Programming | http://openocd.org/doc/html/Flash-Programming.html#Flash-Programming ] or 'reset init' 'flash write_image erase ...' for combined erase/programming of device. Tom On 15/03/2020 19:06, [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] wrote: Hi Alan, Thank you very much for your reply. Right now, I'm using an OpenOCD version that I've built today. But I still got this problem: (gdb) monitor nrf5 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection Did the patch [ http://openocd.zylin.com/#/c/5348/ | http://openocd.zylin.com/#/c/5348/ ] make it to the master branch? Is there a way to test if the patch is actually in my build? Once again a big thank you to both of you (@Alan and @Tomas) Kind greetings, Kristof Mulier BQ_BEGIN On 3/15/20, [ mailto:acas...@gmail.com | acas...@gmail.com ] wrote: Hi Kristof, I think the nRF52833 has something different from nRF52832 related to flash protection. I think you should to test Tomas' suggestion. Please note that his patch was include on Dec 12 2019 (you are using an older version) : [ http://openocd.zylin.com/#/c/5348/ | http://openocd.zylin.com/#/c/5348/ ] BR, Alan --- On 3/15/20, [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] wrote: Hi Alan, Thank you for your quick response. I've tried the command nrf5 mass_erase: (gdb) monitor nrf5 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection But without success. What am I doing wrong here? BQ_BEGIN --- On 3/15/20, [ mailto:acas...@gmail.com | acas...@gmail.com ] wrote: Hi Kristof, you are using the command to nrf51, but your nrf52. As you could see in the second command I sent you, you should use: nrf5 mass_erase BR, Alan --- On 3/15/20, [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] [ mailto:kristof.mul...@telenet.be | ] wrote: Dear Mr. Alan Carvalho de Assis and Mr. Tomas Vanek, Thank you very much for your quick reply. I've tried the command to mass erase the chip. From GDB: (gdb) monitor nrf51 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection Unfortunately, this doesn't work. OpenOCD seems to be unable to handle the chip's write protection. I'm using the following version: Open On-Chip Debugger 0.10.0+dev-00973-g80f1a92bd (2019-12-02-17:58) As you can see, I built this OpenOCD on December 2nd 2019 for Windows 10. I've built it using the xPack method from Mr. Liviu Ionescu (see [ https://xpack.github.io/ | https://xpack.github.io/ ] and [ https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build | https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build ] ) I've just built OpenOCD again today. Now I've got the following version: Open On-Chip Debugger 0.10.0+dev-01133-ge03de33c (2020-03-15-08:55) How can I be sure that merge 5348 (see [ http://openocd.zylin.com/#/c/5348/ | http://openocd.zylin.com/#/c/5348/ ] ) is included in this build? Anyhow, it doesn't look good because I still get the same problem when trying a mass erase: (gdb) monitor nrf51 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection Many thanks for your help ^_^ Kind regards, Kristof Mulier --- On 3/14/20 at 23:35, [ mailto:tom_...@users.sourceforge.net | tom_...@users.sourceforge.net ] wrote: BQ_BEGIN The problem was solved by [ http://openocd.zylin.com/5348 | http://openocd.zylin.com/5348 ] Please use a newer OpenOCD build. Tomas --- On 3/14/20 at 23:40, [ mailto:acas...@gmail.com | acas...@gmail.com ] wrote: BQ_BEGIN Hi Kristof, I
[OpenOCD-devel] Support for GigaDevice microcontrollers
Hi, We received a couple of boards from GigaDevice (one of them is RiscV-based): GD32VF103C-START (MCU: GD32VF103C ) RiscV -based GD32E231C-START (MCU: GD32E231C ) ARM -based GD32E232K-START (MCU: GD32E232K ) ARM -based GD32E230C-EVAL (MCU: GD32E230C8) ARM-based OpenOCD doesn't seem to support them. Nor the microcontrollers, neither the GD-Link onboard debugger/programmer. Do you have plans to support them? I've contacted GigaDevice to ask for their distribution channels in Europe. If you'd like to have a board, please contact me. I can send you one. Many thanks ^_^ Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Support for GigaDevice microcontrollers
Hi @jmn I just got the following reply from Reuben Townsend from GigaDevice: Hi Kristof, the GD-LINK uses the CMSIS-DAP interface and for the GD32E230 MCU, you can use the stm32f0x.cfg configuration file. Attached is a script you could use. It didn't work on my computer. I'll ask him what to do for the Risc-V board. Anyway, the script he sent me is this one: interface cmsis-dap transport select swd source [find target/stm32f0x.cfg] What surprises me is that the GD-Link is based on cmsis-dap - which is an ARM Cortex standard. Not sure how they combine that with a Risc-V processor. For the datasheet on this Risc-V processor, see: [ https://www.google.com/url?sa=t=j==s=web=1=2ahUKEwja5ffQ-o3pAhX1JMUKHR90DC4QFjAAegQIDRAB=https%3A%2F%2Fdl.sipeed.com%2FLONGAN%2FNano%2FDOC%2FGD32VF103_Datasheet_Rev1.0.pdf=AOvVaw3vDRLt14BC1Msb24ENRqRL | https://www.google.com/url?sa=t=j==s=web=1=2ahUKEwja5ffQ-o3pAhX1JMUKHR90DC4QFjAAegQIDRAB=https%3A%2F%2Fdl.sipeed.com%2FLONGAN%2FNano%2FDOC%2FGD32VF103_Datasheet_Rev1.0.pdf=AOvVaw3vDRLt14BC1Msb24ENRqRL ] Kind regards, Kristof Van: "j. m. norris" Aan: "openocd-devel" Verzonden: Woensdag 29 april 2020 16:57:25 Onderwerp: Re: [OpenOCD-devel] Support for GigaDevice microcontrollers Kristof, Can you send a link for the RiscV board documentation? I might be able to help as I've work with other RiscV boards. Regards jmn ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Support for GigaDevice microcontrollers
Hi @Jim,
Thanks for your reply ^_^
Mr. Reuben Townsend sent me a configuration file that should be used for the
GD32VF103 board with GD-Link (onboard probe):
# Script for GD32VF103 with GD-Link
# ==
adapter_khz 1000
reset_config srst_only
adapter_nsrst_assert_width 100
interface cmsis-dap
transport select jtag
set _CHIPNAME riscv
jtag newtap $_CHIPNAME cpu -irlen 5 -expected-id 0x1000563d
set _TARGETNAME $_CHIPNAME.cpu
target create $_TARGETNAME riscv -chain-position $_TARGETNAME
$_TARGETNAME configure -work-area-phys 0x2000 -work-area-size 20480
-work-area-backup 0
# Work-area is a space in RAM used for flash programming
if { [ info exists WORKAREASIZE] } {
set _WORKAREASIZE $WORKAREASIZE
} else {
set _WORKAREASIZE 0x5000
}
# Allow overriding the Flash bank size
if { [ info exists FLASH_SIZE] } {
set _FLASH_SIZE $FLASH_SIZE
} else {
# autodetect size
set _FLASH_SIZE 0
}
# flash size will be probed
set _FLASHNAME $_CHIPNAME.flash
flash bank $_FLASHNAME gd32vf103 0x0800 0 0 0 $_TARGETNAME
riscv set_reset_timeout_sec 1
init
halt
# === END == #
Unfortunately, it doesn't work on my computer. I get the following output in
OpenOCD:
C:\beetle_projects\gd32vf103c_ start> "C:/embeetle/openocd_0.10.0_
dev01138_64b/bin/openocd.exe" -f openocd_chip.cfg -s
"C:/embeetle/openocd_0.10.0_ dev01138_64b/scripts" -c "init; reset halt"
Open On-Chip Debugger 0.10.0+ dev-01138-g1891c2d2 (2020-03- 21-09:19)
Licensed under GNU GPL v2
For bug reports, read
[ http://openocd.org/doc/doxygen/bugs.html |
http://openocd.org/doc/doxygen/bugs.html ]
DEPRECATED! use 'adapter speed' not 'adapter_khz'
DEPRECATED! use 'adapter srst pulse_width' not 'adapter_ nsrst_assert_width'
DEPRECATED! use 'adapter driver' not 'interface'
Error: flash driver ' gd32vf103' not found
Error: Target has not been initialized
Any idea what could be wrong?
Kind regards,
Kristof
Van: "j. m. norris"
Aan: "kristof mulier"
Cc: "openocd-devel"
Verzonden: Woensdag 29 april 2020 18:10:40
Onderwerp: Re: [OpenOCD-devel] Support for GigaDevice microcontrollers
Kristof,
The CMSIS-DAP related bits in that file should be fine. However, there are
other
things in the file that are specific to the ARM, e.g, flash and PLL bits. So
you can't
use the file as-is. You'll have to do some modifications for the RISCV (if
any).
As far as combining it, it's just a matter of hooking up the CMSIS-DAP block
interface
into the right places in the RISCV block in the Verilog.
Regards,
Jim
==
On 4/29/20 10:34 AM, [ mailto:kristof.mul...@telenet.be |
kristof.mul...@telenet.be ] wrote:
Hi @jmn
I just got the following reply from Reuben Townsend from GigaDevice:
Hi Kristof, the GD-LINK uses the CMSIS-DAP interface
and for the GD32E230 MCU, you can use the stm32f0x.cfg
configuration file.
Attached is a script you could use.
It didn't work on my computer. I'll ask him what to do for the Risc-V board.
Anyway, the script he sent me is this one:
interface cmsis-dap
transport select swd
source [find target/stm32f0x.cfg]
What surprises me is that the GD-Link is based on cmsis-dap - which is an ARM
Cortex standard. Not sure how they combine that with a Risc-V processor. For
the datasheet on this Risc-V processor, see:
[
https://www.google.com/url?sa=t=j==s=web=1=2ahUKEwja5ffQ-o3pAhX1JMUKHR90DC4QFjAAegQIDRAB=https%3A%2F%2Fdl.sipeed.com%2FLONGAN%2FNano%2FDOC%2FGD32VF103_Datasheet_Rev1.0.pdf=AOvVaw3vDRLt14BC1Msb24ENRqRL
|
https://www.google.com/url?sa=t=j==s=web=1=2ahUKEwja5ffQ-o3pAhX1JMUKHR90DC4QFjAAegQIDRAB=https%3A%2F%2Fdl.sipeed.com%2FLONGAN%2FNano%2FDOC%2FGD32VF103_Datasheet_Rev1.0.pdf=AOvVaw3vDRLt14BC1Msb24ENRqRL
]
Kind regards,
Kristof
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Support for GigaDevice microcontrollers
Hi @Paul, Thank you so much for your research! Do you recommend to use the "tool-openocd-gd32v" from platformio? Or should I somehow pull this particular riscv commit and build OpenOCD from sources (although I'd need a little help to pull this through)? Kind regards, Kristof - Oorspronkelijk bericht - Van: "Paul Fertser" Aan: "kristof mulier" Cc: "j. m. norris" , "openocd-devel" Verzonden: Woensdag 29 april 2020 19:13:28 Onderwerp: Re: [OpenOCD-devel] Support for GigaDevice microcontrollers On Wed, Apr 29, 2020 at 07:59:49PM +0300, Paul Fertser wrote: > On Wed, Apr 29, 2020 at 06:53:50PM +0200, kristof.mul...@telenet.be wrote: > > Error: flash driver 'gd32vf103' not found > > I guess you want "tool-openocd-gd32v" from platformio. This driver is > not in upstream OpenOCD. I did some searching for you, the code in question is in https://github.com/diodep/riscv-openocd/commits/riscv And still not accepted by riscv openocd maintainers due to quality issues: https://github.com/riscv/riscv-openocd/pull/399 -- 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] Support for GigaDevice microcontrollers
[ https://github.com/sifive/freedom-tools/issues | https://github.com/sifive/freedom-tools/issues ] >. Find the GDB manual and other documentation resources online at: < [ http://www.gnu.org/software/gdb/documentation/ | http://www.gnu.org/software/gdb/documentation/ ] >. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) target remote localhost: Remote debugging using localhost: bfd requires xlen 8, but target has xlen 4 (gdb) monitor reset halt "monitor" command not supported by this target. (gdb) monitor flash erase_address 0x0800 0x0001 "monitor" command not supported by this target. As you can see, the "monitor" command simply doesn't work. It's the first time this happens to me. I have absolutely no clue how to solve this. Kind regards, Kristof Mulier Van: "Tomas Vanek" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Donderdag 30 april 2020 09:23:09 Onderwerp: Re: [OpenOCD-devel] Support for GigaDevice microcontrollers Hi Kristof, On 29/04/2020 17:34, [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] wrote: Hi @jmn I just got the following reply from Reuben Townsend from GigaDevice: Hi Kristof, the GD-LINK uses the CMSIS-DAP interface and for the GD32E230 MCU, you can use the stm32f0x.cfg configuration file. Please be aware there are at least two patches for GD32 devices in gerrit [ http://openocd.zylin.com/4592 | http://openocd.zylin.com/4592 ] [ http://openocd.zylin.com/5246 | http://openocd.zylin.com/5246 ] They cannot be applied cleanly to the current git master and authors seem not responding. Tom ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Support for GigaDevice microcontrollers
Hi @Paul , Thank you very much for your suggestions. I've tried them with the following results: C:\beetle_projects\gd32vf103c_start> "C:/embeetle/gnu_riscv_xpack_64b/bin/riscv-none-embed-gdb.exe" warning: Couldn't determine a path for the index cache directory. GNU gdb (xPack GNU RISC-V Embedded GCC, 64-bit) 8.3 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later < [ http://gnu.org/licenses/gpl.html | http://gnu.org/licenses/gpl.html ] > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "--host=x86_64-w64-mingw32 --target=riscv-none-embed". Type "show configuration" for configuration details. For bug reporting instructions, please see: < [ https://github.com/sifive/freedom-tools/issues | https://github.com/sifive/freedom-tools/issues ] >. Find the GDB manual and other documentation resources online at: < [ http://www.gnu.org/software/gdb/documentation/ | http://www.gnu.org/software/gdb/documentation/ ] >. For help, type "help". Type "apropos word" to search for commands related to "word". (gdb) set arch riscv:rv32 The target architecture is assumed to be riscv:rv32 (gdb) tar ext : Remote debugging using : warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command. 0x0800 in ?? () (gdb) file "C:/beetle_projects/gd32vf103c_start/build/myApp.elf" A program is being debugged already. Are you sure you want to change the file? (y or n) [answered Y; input not from terminal] Reading symbols from C:/beetle_projects/gd32vf103c_start/build/myApp.elf ... (gdb) load Loading section .init, size 0x236 lma 0x800 Loading section .text, size 0x1860 lma 0x8000240 Loading section .sdata2._global_impure_ptr, size 0x4 lma 0x8001aa0 Loading section .init_array, size 0x4 lma 0x8001aa4 Loading section .data, size 0x68 lma 0x8001aa8 Start address 0x800015c, load size 6918 Transfer rate: 808 bytes/sec, 1383 bytes/write. (gdb) monitor reset run cmsis-dap JTAG TLR_RESET cmsis-dap JTAG TLR_RESET cmsis-dap JTAG TLR_RESET JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7) Hart 0 didn't run coming out of reset in 1s; dmstatus=0x4f03a2; Increase the timeout with riscv set_reset_timeout_sec. Hart 0 unexpectedly reset! Note: Hart is halted due to the halt-on-reset bit is set, please continue your program by appropriate debugger commands or operations!! (gdb) monitor shutdown shutdown command invoked (gdb) quit A debugging session is active. Inferior 1 [Remote target] will be detached. Quit anyway? (y or n) [answered Y; input not from terminal] Detaching from program: C:/beetle_projects/gd32vf103c_start/build/myApp.elf , Remote target Remote communication error. Target disconnected.: Not a directory. It looks like the firmware flashed successfully. However, the monitor reset run command seems to cause troubles. Unfortunately, the led on the board is not blinking. The firmware I got from Reuben Townsend should make an led blink. I'll send a mail to Reuben (engineer at GigaDevice) to ask him about the upstream OpenOCD support. By the way - if you're interested in this RISC-V development board (the GD32VF103C-START), just let me know. There is currently no European distributor for this board. But I can get you one through my contacts in GigaDevice. Kind regards, Kristof ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Support for GigaDevice microcontrollers
Hi @Paul, Thank you for your quick reply. > You can use "compare-sections" after "load" to be sure. I just tried. It looks good: (gdb) compare-sections Section .init, range 0x800 -- 0x8000236: matched. Section .text, range 0x8000240 -- 0x8001aa0: matched. Section .sdata2._global_impure_ptr, range 0x8001aa0 -- 0x8001aa4: matched. Section .init_array, range 0x8001aa4 -- 0x8001aa8: matched. Section .data, range 0x8001aa8 -- 0x8001b10: matched. Thanks for the suggestion :-) @Paul: Getting the RISC-V board to Russia shouldn't be a problem. I've added you on LinkedIn. Perhaps we can continue the conversation there. @everyone: Feel free to contact me for the RISC-V board from GigaDevice :-) Kind regards, Kristof - Oorspronkelijk bericht - Van: "Paul Fertser" Aan: "kristof mulier" Cc: "Tomas Vanek" , "j. m. norris" , "openocd-devel" Verzonden: Donderdag 30 april 2020 13:15:15 Onderwerp: Re: [OpenOCD-devel] Support for GigaDevice microcontrollers On Thu, Apr 30, 2020 at 01:02:16PM +0200, kristof.mul...@telenet.be wrote: > It looks like the firmware flashed successfully. You can use "compare-sections" after "load" to be sure. > Unfortunately, the led on the board is not blinking. The firmware I > got from Reuben Townsend should make an led blink. How about, ahem, debugging? :) Like you do "monitor reset halt", then "stepi" few times to see it really runs through the startup code, then probably "tb main", "c" etc. > By the way - if you're interested in this RISC-V development board > (the GD32VF103C-START), just let me know. If you can get it sent to Russia (sigh) I'd be glad to get one, sure, thank you for the offer :) -- 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] xPack build for OpenOCD is broken
1. Background info -- Before jumping into the details, I'll first provide some background info. I'm using the xPack from @Liviu Ionescu to build OpenOCD for both Windows and Linux. You can find more info on his website: [ https://xpack.github.io/openocd/ | https://xpack.github.io/openocd/ ] I follow the instructions with a slight modification. After cloning the openocd-xpack.git, I open the file "scripts/defs-source.sh" and uncomment the last three lines. This action ensures that the latest OpenOCD source code on the master-branch gets built. 2. Sidenote --- For a step-by-step guide on how to build OpenOCD, please consult my web- page: [ https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build | https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build ] I've noted down every step of the build process - including the way I install the Ubuntu VM. It's very verbose, leaving no room for misinter- pretations :-) 3. The error message The error message I get is printed below. I think it's an issue with the OpenOCD git server: Cloning "openocd.git" from "git://git.code.sf.net/p/openocd/code" ... Cloning into 'openocd.git' ... remote: Enumerating objects: 63643, done. remote: Counting objects: 100% (63643/63643), done. remote: Compressing objects: 100% (27437/27437), done. remote: Total 63643 (delta 52300), reused 43882 (delta 36038) Receiving objects: 100% (63643/63643), 14.39 MiB | 5.97 MiB/s, done. Resolving deltas: 100% (52300/52300), done. Submodule 'jimtcl' ( https://repo.or.cz/jimtcl.git ) registered for path 'jimtcl' Submodule 'src/jtag/drivers/libjaylink' ( https://repo.or.cz/libjaylink.git ) registered for path 'src/jtag/drivers/libjaylink' Submodule 'tools/git2cl' ( https://repo.or.cz/git2cl.git ) registered for path 'tools/git2cl' Cloning into '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/jimtcl' ... fatal: unable to access 'https://repo.or.cz/jimtcl.git/' : Failed to connect to repo.or.cz port 443: Connection timed out fatal: clone of 'https://repo.or.cz/jimtcl.git' into submodule path '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/jimtcl' failed Failed to clone 'jimtcl' . Retry scheduled Cloning into '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/src/jtag/drivers/libjaylink' ... fatal: unable to access 'https://repo.or.cz/libjaylink.git/' : Failed to connect to repo.or.cz port 443: Connection timed out fatal: clone of 'https://repo.or.cz/libjaylink.git' into submodule path '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/src/jtag/drivers/libjaylink' failed Failed to clone 'src/jtag/drivers/libjaylink' . Retry scheduled Cloning into '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/tools/git2cl' ... fatal: unable to access 'https://repo.or.cz/git2cl.git/' : Failed to connect to repo.or.cz port 443: Connection timed out fatal: clone of 'https://repo.or.cz/git2cl.git' into submodule path '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/tools/git2cl' failed Failed to clone 'tools/git2cl' . Retry scheduled Cloning into '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/jimtcl' ... fatal: unable to access 'https://repo.or.cz/jimtcl.git/' : Failed to connect to repo.or.cz port 443: Connection timed out fatal: clone of 'https://repo.or.cz/jimtcl.git' into submodule path '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/jimtcl' failed Failed to clone 'jimtcl' a second time, aborting I've tried to build OpenOCD twice today, and got the same error each time. Is this a temporary hiccup, or some URL that is pointing to something that moved? Thank you very much :-) Kind greetings, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] xPack build for OpenOCD is broken
Hi Liviu, Many thanks for your quick reply. I'm happy to hear you're working on the xPack Build Box (v3.1). Your efforts to make software like OpenOCD easier to build, makes it available to much more people. You're my hero! You said: > "Most probably the urls need to be moved away from SourceForge" I agree. SourceForge is flooded with ads. They're flickering all over the place. I believe a software like OpenOCD deserves a better place to live. Kind greetings, Kristof - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Vrijdag 20 maart 2020 16:48:06 Onderwerp: Re: xPack build for OpenOCD is broken > On 20 Mar 2020, at 17:21, kristof.mul...@telenet.be wrote: > > I'm using the xPack from @Liviu Ionescu to build OpenOCD for both Windows > and Linux. You can find more info on his website: > https://xpack.github.io/openocd/ Hi Kristof, Thank you for reporting this issue, and for using my build scripts. > https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build One small comment: your explanations on how to install docker are ok, but I would still use the official Docker steps: https://docs.docker.com/install/linux/docker-ce/ubuntu/ > The error message I get is printed below. I think it's an issue with the > OpenOCD git server: > > Cloning "openocd.git" from "git://git.code.sf.net/p/openocd/code"... > Cloning into 'openocd.git'... > remote: Enumerating objects: 63643, done. > remote: Counting objects: 100% (63643/63643), done. > remote: Compressing objects: 100% (27437/27437), done. > remote: Total 63643 (delta 52300), reused 43882 (delta 36038) > Receiving objects: 100% (63643/63643), 14.39 MiB | 5.97 MiB/s, done. > Resolving deltas: 100% (52300/52300), done. > Submodule 'jimtcl' (https://repo.or.cz/jimtcl.git) registered for path > 'jimtcl' > Submodule 'src/jtag/drivers/libjaylink' > (https://repo.or.cz/libjaylink.git) registered for path > 'src/jtag/drivers/libjaylink' > Submodule 'tools/git2cl' (https://repo.or.cz/git2cl.git) registered for > path 'tools/git2cl' > Cloning into > '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/jimtcl'... > fatal: unable to access 'https://repo.or.cz/jimtcl.git/': Failed to > connect to repo.or.cz port 443: Connection timed out > fatal: clone of 'https://repo.or.cz/jimtcl.git' into submodule path > '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/jimtcl' failed > Failed to clone 'jimtcl'. Retry scheduled > Cloning into > '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/src/jtag/drivers/libjaylink'... > fatal: unable to access 'https://repo.or.cz/libjaylink.git/': Failed to > connect to repo.or.cz port 443: Connection timed out > fatal: clone of 'https://repo.or.cz/libjaylink.git' into submodule path > '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/src/jtag/drivers/libjaylink' > failed > Failed to clone 'src/jtag/drivers/libjaylink'. Retry scheduled > Cloning into > '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/tools/git2cl'... > fatal: unable to access 'https://repo.or.cz/git2cl.git/': Failed to > connect to repo.or.cz port 443: Connection timed out > fatal: clone of 'https://repo.or.cz/git2cl.git' into submodule path > '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/tools/git2cl' failed > Failed to clone 'tools/git2cl'. Retry scheduled > Cloning into > '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/jimtcl'... > fatal: unable to access 'https://repo.or.cz/jimtcl.git/': Failed to > connect to repo.or.cz port 443: Connection timed out > fatal: clone of 'https://repo.or.cz/jimtcl.git' into submodule path > '/Host/home/kristof/Work/openocd-0.10.0-14/openocd.git/jimtcl' failed > Failed to clone 'jimtcl' a second time, aborting I have no idea why this happened, but the error message is obvious, git was not able to install the submodules. > I've tried to build OpenOCD twice today, and got the same error each time. > Is this a temporary hiccup, or some URL that is pointing to something that > moved? I guess you'll get exactly the same error if you do a 'git clone --recurse-submodule git://git.code.sf.net/p/openocd/code' in any environment. I did and I got exactly the same timeouts. Most probably the urls need to be moved away from SourceForge (which is highly unreliable) and repo.or.cz. --- Since the git servers time outs are not under the control of my build scripts, I'm afraid I can't fix this. --- FYI, I'm working on a new version of the xPack Build Box (v3.1) which adds support for Arm 32/64-bits. A new version of the xPack OpenOCD binaries is scheduled soon. If you (or som
Re: [OpenOCD-devel] xPack build for OpenOCD is broken
Hi @Liviu, You said: > "Perhaps we can agree on a schedule, and make the xPack binaries the > default/recommended OpenOCD binaries, for those who do not want to > bother with compiling them from sources." I agree full 100%. Perhaps they can be even made downloadable from the official OpenOCD website? You also said: > "As such, you would not have to run the scripts yourself." That would be true for 95% of the users. But sometimes I need the bleeding-edge-version to try some fix that someone pushed for some specific microcontroller. I'm trying out all sorts of microcontroller boards, adding them to our new free microcontroller IDE (see https://embeetle.com) Shouldn't OpenOCD have a logo? I've designed one that can be used: https://embeetle.com/icons/tools/openocd.png and for the combo OpenOCD + GDB: https://embeetle.com/icons/tools/openocd_gdb.png Any ideas? Kind greetings, Kristof Mulier - Oorspronkelijk bericht ----- Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Vrijdag 20 maart 2020 17:22:34 Onderwerp: Re: xPack build for OpenOCD is broken > On 20 Mar 2020, at 18:07, kristof.mul...@telenet.be wrote: > > Hi Liviu, > > Many thanks for your quick reply. I'm happy to hear you're working on > the xPack Build Box (v3.1). Your efforts to make software like OpenOCD > easier to build, makes it available to much more people. > You're my hero! Thank you! Once the new build environment will be in place it'll be also easier for myself to make new releases. Perhaps we can agree on a schedule, and make the xPack binaries the default/recommended OpenOCD binaries, for those who do not want to bother with compiling them from sources. As such, you would not have to run the scripts yourself. > You said: >> "Most probably the urls need to be moved away from SourceForge" > > I agree. SourceForge is flooded with ads. They're flickering all > over the place. I believe a software like OpenOCD deserves a better > place to live. The adds are only annoying, I don't mind them since I visit the site very rarely, but the timeouts are benign. Now it seems https://repo.or.cz suffers from similar issues. Personally I would move the project to GitHub. Create an organisation called OpenOCD and transfer everything there. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] xPack build for OpenOCD is broken
Hi Liviu, I just compiled OpenOCD successfully using xPacks. The build is no longer broken. Thanks for your replies yesterday :-) - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Vrijdag 20 maart 2020 17:22:34 Onderwerp: Re: xPack build for OpenOCD is broken > On 20 Mar 2020, at 18:07, kristof.mul...@telenet.be wrote: > > Hi Liviu, > > Many thanks for your quick reply. I'm happy to hear you're working on > the xPack Build Box (v3.1). Your efforts to make software like OpenOCD > easier to build, makes it available to much more people. > You're my hero! Thank you! Once the new build environment will be in place it'll be also easier for myself to make new releases. Perhaps we can agree on a schedule, and make the xPack binaries the default/recommended OpenOCD binaries, for those who do not want to bother with compiling them from sources. As such, you would not have to run the scripts yourself. > You said: >> "Most probably the urls need to be moved away from SourceForge" > > I agree. SourceForge is flooded with ads. They're flickering all > over the place. I believe a software like OpenOCD deserves a better > place to live. The adds are only annoying, I don't mind them since I visit the site very rarely, but the timeouts are benign. Now it seems https://repo.or.cz suffers from similar issues. Personally I would move the project to GitHub. Create an organisation called OpenOCD and transfer everything there. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] xPack build for OpenOCD is broken
Hi @Liviu > "Sure, I concentrated deeply all night long and fixed it with the power of my > mind. :-)" Thanks! Your witchcraft is highly appreciated. Humble greetings, Kristof - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Zaterdag 21 maart 2020 11:04:55 Onderwerp: Re: xPack build for OpenOCD is broken > On 21 Mar 2020, at 12:00, kristof.mul...@telenet.be wrote: > > The build is no longer broken. Sure, I concentrated deeply all night long and fixed it with the power of my mind. :-) > Thanks for your replies > yesterday :-) You're welcome! Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] OpenOCD dev01138 cannot flash to nRF52 due to protected sectors
Hi, OpenOCD fails to flash my nRF52 microcontroller. Below is some more explanations. The board === I've got an nRF52 microcontroller from Nordic Semiconductor. More in particular the nRF52833 mcu on the PCA10100 board. See: [ https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52833-DK | https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52833-DK ] The OpenOCD version === This morning, I built OpenOCD with the xPacks method. It builds the most recent version of the master repo, which is dev01138 at the moment of writing. Flashing == I succeeded to flash about two or three times this morning. Unfortunately, now I constantly get an error related to "protected sectors" that cannot be erased: (gdb) monitor nrf5 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection (gdb) monitor flash erase_check 0 successfully checked erase state Bank is erased (gdb) monitor program "C:/Users/Kristof/nordic_test/build/myApp.elf" target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0xfffe msp: 0xfffc ** Programming Started ** Adding extra erase range, 0x387c .. 0x3fff Cannot erase protected sector at 0x0 failed erasing sectors 0 to 3 embedded:startup.tcl:460: Error: ** Programming Failed ** in procedure 'program' in procedure 'program_error' called at file "embedded:startup.tcl", line 525 at file "embedded:startup.tcl", line 460 Your help is greatly appreciated. Notes I'm doing all this to support the nRF52 series in the free Embeetle IDE. I hope there is a solution to the problem that only involves OpenOCD - such that we don't need to add proprietary softwares (like JLink, ...) to Embeetle IDE. Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] OpenOCD dev01138 cannot flash to nRF52 due to protected sectors
Hi Tomas, My apologies. I never used gerrit before, I'll look into it right after writing this email. The problem is fixed. The OpenOCD launcher accidentally pointed again to an older version. Such a stupid mistake. My sincere apologies. With dev01138, I get the following output: (gdb) monitor nrf5 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection (gdb) monitor flash erase_check 0 successfully checked erase state Bank is erased (gdb) monitor program "C:/Users/Kristof/nordic_test/build/myApp.elf" target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0xfffe msp: 0xfffc ** Programming Started ** Adding extra erase range, 0x387c .. 0x3fff ** Programming Finished ** As you can see - it works just fine. There is only that misleading output after the 'mass_erase' command. But that's not a big deal. You're right about the GDB 'load' command. It works on most boards, but not all. I've just tried it now - it seems to work on the Nordic boards :-) Kind greetings, Kristof Mulier Van: "Tomas Vanek" Aan: "kristof mulier" , "openocd-devel" Verzonden: Zaterdag 21 maart 2020 13:49:58 Onderwerp: Re: OpenOCD dev01138 cannot flash to nRF52 due to protected sectors Hi Kristof, I would highly appreciate if you register to our gerrit at [ http://openocd.zylin.com/ | http://openocd.zylin.com ] and start using it instead of spamming the openocd-dev mailing list. Some time ago you wrote: Please let me know when you've finished the patch. If you were in gerrit, I would add you as a reviewer of [ http://openocd.zylin.com/5522 | http://openocd.zylin.com/5522 ] As I didn't find your mail in the gerrit users list I relied on you notice the gerrit message about new patch. Unfortunately it seems you didn't. Moreover the error message looks like you are still using an old openocd version (compiled from git master before December 12th, when [ http://openocd.zylin.com/5348 | http://openocd.zylin.com/5348 ] was merged) instead that one you've recently compiled. BTW: If you use gdb, why don't you use gdb 'load' command? It's quite simple, as gdb 'load' re-reads image (if changed) then does both flash erase and programming. I personally prefer using two gdb commands 'make' and 'load' over using any super-sophisticated IDE ;-) Tom On 21/03/2020 11:56, [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] wrote: BQ_BEGIN Hi, OpenOCD fails to flash my nRF52 microcontroller. Below is some more explanations. The board === I've got an nRF52 microcontroller from Nordic Semiconductor. More in particular the nRF52833 mcu on the PCA10100 board. See: [ https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52833-DK | https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52833-DK ] The OpenOCD version === This morning, I built OpenOCD with the xPacks method. It builds the most recent version of the master repo, which is dev01138 at the moment of writing. Flashing == I succeeded to flash about two or three times this morning. Unfortunately, now I constantly get an error related to "protected sectors" that cannot be erased: (gdb) monitor nrf5 mass_erase Flash protection of this nRF device is not supported Failed to check chip's write protection (gdb) monitor flash erase_check 0 successfully checked erase state Bank is erased (gdb) monitor program "C:/Users/Kristof/nordic_test/build/myApp.elf" target halted due to debug-request, current mode: Thread xPSR: 0x0100 pc: 0xfffe msp: 0xfffc ** Programming Started ** Adding extra erase range, 0x387c .. 0x3fff Cannot erase protected sector at 0x0 failed erasing sectors 0 to 3 embedded:startup.tcl:460: Error: ** Programming Failed ** in procedure 'program' in procedure 'program_error' called at file "embedded:startup.tcl", line 525 at file "embedded:startup.tcl", line 460 Your help is greatly appreciated. Notes I'm doing all this to support the nRF52 series in the free Embeetle IDE. I hope there is a solution to the problem that only involves OpenOCD - such that we don't need to add proprietary softwares (like JLink, ...) to Embeetle IDE. Kind regards, Kristof Mulier BQ_END ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
Hi Tommy Murphy,
Thanks for your reply.
It seems like there is a national issue with the internet in
Belgium (especially Flanders) right now.
Lots of Belgians complain about outages today.
I'll try again tonight or tomorrow.
Kind regards,
Kristof
Van: "Tommy Murphy"
Aan: "kristof mulier"
Cc: "Liviu Ionescu" , "johan" , "matic"
, "openocd-devel"
Verzonden: Zondag 30 augustus 2020 14:38:38
Onderwerp: Re: [OpenOCD-devel] Missing libusb shared object file in xPack
build.
"Repo outages" not "drop outages".
From: Tommy Murphy
Sent: Sunday, August 30, 2020 1:36:33 PM
To: kristof.mul...@telenet.be
Cc: Liviu Ionescu ; johan ; matic
; openocd-devel
Subject: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
I did a build last night and another this morning (after doing sudo rm -rf
~/Work to clean all downloads off) with the openocd repo (i.e. those last three
lines of def-source.sh uncommented) and both went fine. Sometimes network
issues and drop outages can cause build failures but very rarely in my
experience.
Note that all of the steps that I carried out are all itemized in Liviu's
instructions.
From: kristof.mul...@telenet.be
Sent: Sunday, August 30, 2020 11:09:37 AM
To: Tommy Murphy
Cc: Liviu Ionescu ; johan ; matic
; openocd-devel
Subject: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
Hi @Tommy Murphy,
Thank you very much for sharing the precise commands
you enter to build OpenOCD :-)
I've tried this morning, but got the following problem:
Downloading "libusb-win32-src-1.2.6.0.zip" from
"http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-src-1.2.6.0.zip;
...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 178 100 178 0 0 52 0 0:00:03 0:00:03 --:--:-- 52
100 434 100 434 0 0 105 0 0:00:04 0:00:04 --:--:-- 1272
100 421 100 421 0 0 97 0 0:00:04 0:00:04 --:--:-- 97
100 503 100 503 0 0 112 0 0:00:04 0:00:04 --:--:-- 112
100 417 100 417 0 0 80 0 0:00:05 0:00:05 --:--:-- 814
0 0 0 0 0 0 0 0 --:--:-- 0:02:14 --:--:-- 0
curl: (7) Failed to connect to netcologne.dl.sourceforge.net port 443:
Connection timed out
It seems like the libusb sourceforge page is down?
I'll try again this afternoon.
Kind regards,
Kristof Mulier
Van: "Tommy Murphy"
Aan: "Liviu Ionescu" , "kristof mulier"
Cc: "johan" , "matic" , "openocd-devel"
Verzonden: Zaterdag 29 augustus 2020 21:36:25
Onderwerp: Re: [OpenOCD-devel] Missing libusb shared object file in xPack
build.
Liviu's scripts build his snapshot sources.
If you want to build from the openocd repo then uncomment the three lines here:
[
https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L41
|
https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L41
]
FWIW here are all of the commands that I run (all itemised in Liviu's
instructions) to do a "default" build using his scripts on a clean VM
installation of Ubuntu 18.04:
https://xpack.github.io/xbb/prerequisites/
sudo apt-get install -y apt-transport-https ca-certificates curl
software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
version_name=$(lsb_release -cs)
sudo add-apt-repository "deb [arch=amd64]
https://download.docker.com/linux/ubuntu ${version_name} stable"
sudo apt-get update
sudo apt-get -y install docker-ce
sudo docker run hello-world
sudo groupadd docker
sudo gpasswd -a ${USER} docker
sudo service docker restart
shutdown -r now
docker run hello-world
rm -rf ~/Downloads/openocd-xpack.git
git clone --recurse-submodules
https://github.com/xpack-dev-tools/openocd-xpack.git
~/Downloads/openocd-xpack.git
bash ~/Downloads/openocd-xpack.git/scripts/build.sh --all
From: Liviu Ionescu
Sent: Saturday 29 August 2020 19:21
To: kristof.mul...@telenet.be
Cc: Tommy Murphy ; johan ; matic
; openocd-devel
Subject: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
> On 29 Aug 2020, at 21:18, kristof.mul...@telenet.be wrote:
>
> ... I got it running properly
told you so!
> So what would change in these commands to achieve that? ... defs-source.sh'
> file (uncommenting the last three lines)? Or is it something else?
Keine Ahnung, I never used the scripts with different repos. those three lines
were added by Tommy.
Liviu
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
Hi @Tommy Murphy,
Thank you very much for sharing the precise commands
you enter to build OpenOCD :-)
I've tried this morning, but got the following problem:
Downloading "libusb-win32-src-1.2.6.0.zip" from
"http://sourceforge.net/projects/libusb-win32/files/libusb-win32-releases/1.2.6.0/libusb-win32-src-1.2.6.0.zip;
...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 178 100 178 0 0 52 0 0:00:03 0:00:03 --:--:-- 52
100 434 100 434 0 0 105 0 0:00:04 0:00:04 --:--:-- 1272
100 421 100 421 0 0 97 0 0:00:04 0:00:04 --:--:-- 97
100 503 100 503 0 0 112 0 0:00:04 0:00:04 --:--:-- 112
100 417 100 417 0 0 80 0 0:00:05 0:00:05 --:--:-- 814
0 0 0 0 0 0 0 0 --:--:-- 0:02:14 --:--:-- 0
curl: (7) Failed to connect to netcologne.dl.sourceforge.net port 443:
Connection timed out
It seems like the libusb sourceforge page is down?
I'll try again this afternoon.
Kind regards,
Kristof Mulier
Van: "Tommy Murphy"
Aan: "Liviu Ionescu" , "kristof mulier"
Cc: "johan" , "matic" , "openocd-devel"
Verzonden: Zaterdag 29 augustus 2020 21:36:25
Onderwerp: Re: [OpenOCD-devel] Missing libusb shared object file in xPack
build.
Liviu's scripts build his snapshot sources.
If you want to build from the openocd repo then uncomment the three lines here:
[
https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L41
|
https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L41
]
FWIW here are all of the commands that I run (all itemised in Liviu's
instructions) to do a "default" build using his scripts on a clean VM
installation of Ubuntu 18.04:
https://xpack.github.io/xbb/prerequisites/
sudo apt-get install -y apt-transport-https ca-certificates curl
software-properties-common
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
version_name=$(lsb_release -cs)
sudo add-apt-repository "deb [arch=amd64]
https://download.docker.com/linux/ubuntu ${version_name} stable"
sudo apt-get update
sudo apt-get -y install docker-ce
sudo docker run hello-world
sudo groupadd docker
sudo gpasswd -a ${USER} docker
sudo service docker restart
shutdown -r now
docker run hello-world
rm -rf ~/Downloads/openocd-xpack.git
git clone --recurse-submodules
https://github.com/xpack-dev-tools/openocd-xpack.git
~/Downloads/openocd-xpack.git
bash ~/Downloads/openocd-xpack.git/scripts/build.sh --all
From: Liviu Ionescu
Sent: Saturday 29 August 2020 19:21
To: kristof.mul...@telenet.be
Cc: Tommy Murphy ; johan ; matic
; openocd-devel
Subject: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
> On 29 Aug 2020, at 21:18, kristof.mul...@telenet.be wrote:
>
> ... I got it running properly
told you so!
> So what would change in these commands to achieve that? ... defs-source.sh'
> file (uncommenting the last three lines)? Or is it something else?
Keine Ahnung, I never used the scripts with different repos. those three lines
were added by Tommy.
Liviu
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
Hi, To everyone who is following the e-mail chain between me, Liviu Ionescu and Tommy Murphy about the build failure: the story came to and end. We have a conclusion: Beware of the location where you unzip the build output. I copied the build output to a folder on my Ubuntu VM that is shared with the Windows host OS. Unzipping it there - even though it's done on the Ubuntu VM - kills all the symlinks. Kind regards, Kristof ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
ibc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/librt.so.1: libpthread.so.0 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libpthread.so.0 libpthread.so.0 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libpthread.so.0 libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_PRIVATE) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 /lib/x86_64-linux-gnu/libudev.so.1: ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 libpthread.so.0 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libpthread.so.0 libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.9) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.6) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.25) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.28) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.16) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.8) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.2) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.17) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.26) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.30) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 I don't need an immediate fix. I just want to inform you that building the OpenOCD executable for Linux doesn't work for the latest master branch (unless I'm doing something wrong myself here). Again my sincere thanks to all of you (Liviu Ionescu, Tommy Murphy, ...) that are helping people like me to build OpenOCD for Windows/Linux/Mac. Kind regards, Kristof Mulier Van: "Tommy Murphy" Aan: "Liviu Ionescu" Cc: "kristof mulier" , "johan" , "matic" , "openocd-devel" Verzonden: Zondag 30 augustus 2020 15:35:09 Onderwerp: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build. I wanted to do a completely clean new build with nothing carried over from the previous run. From: Liviu Ionescu Sent: Sunday, August 30, 2020 2:27:09 PM To: Tommy Murphy Cc: kristof.mul...@telenet.be ; johan ; matic ; openocd-devel Subject: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build. > On 30 Aug 2020, at 15:36, Tommy Murphy wrote: > > ... sudo rm -rf ~/Work to clean all downloads off cleaning the Work/cache folder is not necessary, on the contrary. regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Patch for RISC-V microcontrollers
Dear developers, I was in contact with Mr. Leo Tzagkarakis from GigaDevice. He sent me a patch file to be applied on OpenOCD such that it can work with the GigaDevice RISC-V based microcontrollers. I've put the file on our server, so you can download it: [ https://new.embeetle.com/downloads/openocd_riscv_patch.rar | https://new.embeetle.com/downloads/openocd_riscv_patch.rar ] Is there a specific reason this patch didn't make it yet to the master branch? Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
Hi @Liviu Ionescu and @Tommy Murphy, Sorry for my late reply. The way I attempt to execute OpenOCD = In my last e-mail, I told you that I executed OpenOCD after the build without specifying *how* exactly. My apologies for that. So here is what I did: 1. I copied everything from ~/Work/openocd-0.10.0-14/deploy/ into another folder: $ cd ~/Work/openocd-0.10.0-14/deploy $ cp -R * /media/sf_ubuntu $ cd /media/sf_ubuntu 2. I extracted the zipped file "xpack-openocd-0.10.0-14-linux-x64.tar.gz" in that folder. The extraction itself I did from the standard Ubuntu file explorer (so not from the terminal). 3. I navigate into the extracted folder, and execute OpenOCD from there: $ cd /media/sf_ubuntu/xpack-openocd-0.10.0-14-linux-x64/xpack-openocd-0.10.0-14/bin $ ./openocd --version ./openocd: error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory Tommy Murphy's build = So @Tommy Murphy, you successfully built OpenOCD (with the last three lines in the build script uncommented), and it just works? Could it be that my Ubuntu version is the culprit (I'm using Ubuntu 20.04.1 LTS). Although this shouldn't matter, because eventually the build happens in Docker... Suggestions about the how-to-build pages = @Liviu Ionescu, I also don't know how I screw things up. It seems like the heavens don't want me to build OpenOCD... Based on your build instructions, I wrote a guide (mainly for my own use) on how to build OpenOCD: https://new.embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build In this guide, I literally documented every single step. I made that guide a couple of months ago, because I've had so many troubles with building OpenOCD in the past. I took the "write everyting down" approach, like really every single click. It's as if I'm explaining to my grandmom how to do it. Somehow I thought this guide would save me from further issues, which it did as long as I only tested the Windows executables. Trouble started when I tested the Linux executable a couple of days ago. So my only suggestion: write it as if you're explaining it to your grandmom (hopefully she is not a computer scientist). I'm really thankful for all the efforts you made and still make! I'll make another donation, because you're my OpenOCD hero! Kind regards, Kristof Mulier - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "Tommy Murphy" Cc: "kristof mulier" , "johan" , "matic" , "openocd-devel" Verzonden: Maandag 31 augustus 2020 14:14:20 Onderwerp: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build. > On 31 Aug 2020, at 15:08, Tommy Murphy wrote: > > ... the xPack project pages with all those pages, it seems that people always find creative ways to mess things up, so my conclusion is that those pages need improvements. I'm open to any suggestions. Kristof? what is wrong with those pages, such that you could not make it? Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Logo voting
Hi, I've registered the votes today from: - Liviu Ionescu - Moritz Fischer - Oliver Spencer Your votes are now added to the "document": [ https://new.embeetle.com/figures/logo_matrix.png | https://new.embeetle.com/figures/logo_matrix.png ] @Tommy Murphy, I received your mail about the USB cable in logos A1 and A6. You certainly have a point (not all probes/ dongles are USB-based). Two ideas come to my mind: 1. The cable in the logo is not necessarily a USB-cable. It is a general, non-detailed cable. But I admit that it looks somewhat like USB - so perhaps this "argument" is not really satisfying. 2. Perhaps some colleague OpenOCD developers will change their vote after reading your mail. So maybe A1 or A6 won't be selected after all. 3. Once this first round has finished and we have a "winner logo", we can still organize a second round . Say logo X gets selected, then I'll draw a couple of logos that look very much like logo X, with some subtle differences between them. Kind of a second iteration step to reach the "optimal" logo :-) In this second round, I can pay extra attention to draw some of them with a cable that looks more "general" (not just USB). It would be painful if you really dislike the final logo, so I'll do my best to find a good compromise. ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Logo voting: new page
Hi @Tommy, I'm sorry for the confusion. Each logo has a number. There are currently 9 logos. So they are numbered logo_1 , logo_2 , logo_3 , ..., logo_9 . You should order the logos from "most liked" to "least liked" (disliked). For example, you really like logo_2 , then logo_4 , then logo_3 , etc: mylist = [ 2, 4, 3, 5, 6, 8, 9, 7, 1 ] or more explicitely: mylist = [ logo_2 , logo_4 , logo_3 , logo_5 , logo_6 , logo_8 , logo_9 , logo_7 , logo_1 ] Next, I will assign "points" to each of them: logo _ 2 : +4 logo _ 4 : +3 logo _ 3 : +2 logo _ 5 : +1 logo _ 6 : +0 logo _ 8 : -1 logo _ 9 : -2 logo _ 7 : -3 logo _ 1 : -4 The logo you like most gets +4. The logo you really dislike most gets -4. Kind regards, Kristof Van: "Tommy Murphy" Aan: "kristof mulier" , "openocd-devel" Verzonden: Vrijdag 9 oktober 2020 12:34:25 Onderwerp: Re: Logo voting: new page The voting is not clear to me - what do 2nd and 3rd preferences get? 1st preference = +4 2nd preference = ? 3rd preference = ? 4th preference = -4 If 2nd gets +2 and 3rd gets -2 then it is not linear? From: kristof.mul...@telenet.be Sent: Friday 9 October 2020 10:43 To: openocd-devel Subject: [OpenOCD-devel] Logo voting: new page Dear developers and contributors, Thank you for all the e-mails with your votes. Some of you had concerns about the voting mechanism: one could only vote for a favorite, but there was no way to express your dislike for one or more logos. NEW VOTING MECHANISM = That's why I propose a new system. Each of you can send me a list of logo-numbers. The first logo in your list gets +4 points. The last one gets -4 points. Linear and simple. NEW LINK = I abandoned the "logo-matrix", because everyone(*) selected logos from the first row. There was no point in keeping the matrix. We're back to a linear selection (just one "row", no more matrix). You can find the new logo voting page here: https://new.embeetle.com/figures/logo_votes.png (*) I received only one vote for a logo in row B, so I added that logo to the new page. TWO NEW LOGOS == You will notice I've drawn two new logos (nr. 8 and 9). This was a request from Jens Bauer. SOME FINAL THOUGHTS 1. Please don't forget to send me your "list" of logos, ordered from most favorite (+4) to least (-4). 2. Please feel free to suggest modifications to one or more logos, or a suggestion for drawing a new one. 3. My goal is that everyone feels comfortable with the final logo we choose. I know that this project is like a "baby" to many of you. It's normal to get emotionally attached to something you've invested so much time in. That's why it's important we find a logo everyone likes :-) Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Offer for new website
Dear OpenOCD developers, We use OpenOCD in the Embeetle IDE. We are grateful for this free software, and also for the countless times you have helped us to fix certain problems. Although we didn’t contribute to the source code itself (yet), we feel part of the OpenOCD community. We’d like to do something back, something bigger than just drawing a logo. We had a great idea that we’d like to share with you. THE IDEA My colleague Johan designed a simple, elegant javascript-css skeleton that we based our website on: https://embeetle.com On the same skeleton, we also built this website: https://qscintilla.com And I use it for my personal consultancy-website: https://chipdesk.com What do you think about giving OpenOCD a new look? Johan would like to send you the javascript-css code and he is happy to help with the practical implementations. Maybe the new OpenOCD version being released soon (see mail from @Paul Fertsen) is the perfect moment for this ^_^. Once implemented, users can download the new version on the download page of the new OpenOCD website. EXTRA CONTENT = We have some nice content on our Embeetle website about OpenOCD: https://embeetle.com/#embedded-dev/software/dev-tools/flash/basics And here [not yet ready]: https://embeetle.com/#embeetle-ide/troubleshoot/flash And this [build instructions]: https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build We plan to write more pages in the future. It would be nice to add similar content to the OpenOCD website. Of course - we’d only add content to a test-version of the website, so you (the OpenOCD developers) can first check it before pushing anything to the public website. SOME FINAL THOUGHTS === If you like this idea, would you like to have a meeting to discuss it further? We could hold a zoom meeting / skype / ... Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Logo
Dear OpenOCD community, I've registered some more votes from community members (thank you). I also had the request from Martin Meyer to draw a new logo inspired on the typical open-source symbol. Please have a look, it's logo nr. 10: [ https://new.embeetle.com/figures/logo_votes.png | https://new.embeetle.com/figures/logo_votes.png ] After adding the logo, I scaled all your scores. So a +4 => +5, +3 => +4, etc. This way I create an extra spot for the new logo. For those who already voted, please send a new ordered list (most to least favorite) . You can also leave it as is, in which case the new logo gets the neutral (zero) score in your row. @Jens, thank you for your kind words. I tried to send you a thank-you mail (to [ mailto:j...@plustv.dk | j...@plustv.dk ] ) but the mail bounced back. Not sure why. Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Logo voting: new page
Dear developers and contributors, Thank you for all the e-mails with your votes. Some of you had concerns about the voting mechanism: one could only vote for a favorite, but there was no way to express your dislike for one or more logos. NEW VOTING MECHANISM = That's why I propose a new system. Each of you can send me a list of logo-numbers. The first logo in your list gets +4 points. The last one gets -4 points. Linear and simple. NEW LINK = I abandoned the "logo-matrix", because everyone(*) selected logos from the first row. There was no point in keeping the matrix. We're back to a linear selection (just one "row", no more matrix). You can find the new logo voting page here: https://new.embeetle.com/figures/logo_votes.png (*) I received only one vote for a logo in row B, so I added that logo to the new page. TWO NEW LOGOS == You will notice I've drawn two new logos (nr. 8 and 9). This was a request from Jens Bauer. SOME FINAL THOUGHTS 1. Please don't forget to send me your "list" of logos, ordered from most favorite (+4) to least (-4). 2. Please feel free to suggest modifications to one or more logos, or a suggestion for drawing a new one. 3. My goal is that everyone feels comfortable with the final logo we choose. I know that this project is like a "baby" to many of you. It's normal to get emotionally attached to something you've invested so much time in. That's why it's important we find a logo everyone likes :-) Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Logo
Dear OpenOCD developers, Let's have a look again at choosing a logo for OpenOCD? As you might remember, I've drawn a couple of samples, which you can find here: [ https://new.embeetle.com/figures/logo_matrix.png | https://new.embeetle.com/figures/logo_matrix.png ] Some of you already voted for a logo: - Tomas Vanek - Anton Krug - Antonio Borneo - Andreas Bolsch - Tommy Murphy - Vladimir Zapolskiy - Oleksij Rempel - Jan Matyas - Paul Fertser - Tarek Bouchkati The votes are also listed on the figure (see link at the top). Please feel free to: - Change your mind (just send me a mail to change your vote). - Make suggestions for a new logo. I'm happy to make new drawings. Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Logo
Dear OpenOCD community, How large is the community of OpenOCD developers/contributors? In other words - how many votes should we collect before a fair decision can be taken? https://new.embeetle.com/figures/logo_votes.png I'm also curious for the vote of Mr. Dominic Rath - the original OpenOCD developer ^_^. Can anyone contact him? Kind regards, Kristof Mulier PS: @Jens, thank you for your vote. Page is updated. - Oorspronkelijk bericht - Van: "Jens Bauer" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Zaterdag 10 oktober 2020 20:22:01 Onderwerp: Re: [OpenOCD-devel] Logo Hi Kristof. Sorry about the bounce. This is due to that I'm attempting to get my *very* broken mail-server working with a new Linux release. I do not expect the 'permanent error' that you experienced to happen again. Here's an update on my vote, which include the new 'keyhole' icon: [8, 9, 1, 10, 6, 2, 3, 5, 4, 7] (I just realized that number 1 could also be seen as 'chip-on-a-leash') Love Jens On Sat, 10 Oct 2020 19:52:13 +0200 (CEST), kristof.mul...@telenet.be wrote: > Dear OpenOCD community, > > I've registered some more votes from community members > (thank you). I also had the request from Martin Meyer > to draw a new logo inspired on the typical open-source > symbol. Please have a look, it's logo nr. 10: > > https://new.embeetle.com/figures/logo_votes.png > > After adding the logo, I scaled all your scores. So a > +4 => +5, +3 => +4, etc. This way I create an extra > spot for the new logo. > > For those who already voted, please send a new ordered > list (most to least favorite). You can also leave it as > is, in which case the new logo gets the neutral (zero) > score in your row. > > @Jens, thank you for your kind words. I tried to send > you a thank-you mail (to j...@plustv.dk) but the mail > bounced back. Not sure why. > > Kind regards, > Kristof Mulier > > > > > > > > ___ > OpenOCD-devel mailing list > OpenOCD-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openocd-devel ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Missing libusb shared object file in xPack build.
Hi Liviu (and other OpenOCD developers), I just completed another build of OpenOCD on my Ubuntu VM. I'm following the XPack guide from @Liviu Ionescu, see: [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] The executable for Windows works great. I just tested it on my Windows 10 computer. The executable for Linux doesn't work. I only tested the 64-bit Linux executable (because my Ubuntu is 64-bit Ubuntu 20.04.1 LTS), and I always get this error: $ ./openocd --version ./openocd: error while loading shared libraries: libusb-0.1.so.4: cannot open shared object file: No such file or directory Now I tried setting the LD_LIBRARY_PATH env variable to make sure OpenOCD finds all shared object files: $ export LD_LIBRARY_PATH = "~/xpack-openocd-0.10.0-14-linux-x64/bin" But the error persists. This is the content of the /bin/ folder in my OpenOCD folder: $ ls -l total 4816 -rwxrwx--- 1 root vboxsf 73232 Aug 29 14 : 14 libftdi1.so.2.4.0 -rwxrwx--- 1 root vboxsf 22840 Aug 29 14 : 14 libhidapi-hidraw.so.0.0.0 -rwxrwx--- 1 root vboxsf 992288 Aug 29 14 : 14 libiconv.so.2.6.0 -rwxrwx--- 1 root vboxsf 57848 Aug 29 14 : 14 libudev.so -rwxrwx--- 1 root vboxsf 22808 Aug 29 14 : 14 libusb-0.1.so.4.4.4 -rwxrwx--- 1 root vboxsf 111464 Aug 29 14 : 14 libusb-1.0.so.0.1.0 -rwxrwx--- 1 root vboxsf 3634432 Aug 29 14 : 14 openocd So there is a shared object file ' libusb-0.1.so.4.4.4 ' , but it seems like OpenOCD is looking for ' libusb-0.1.so.4 ' . Why? ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
Hi Liviu, I'm indeed experimenting :-) The reason I did those merges is because of this part in your guide (see https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md) Update git repos = To keep the development repository in sync with the original OpenOCD repository, in the xpack-dev-tools/openocd Git repo: > checkout master > merge from upstream/master > checkout xpack-develop > merge master > checkout xpack > merge xpack-develop So that's what I really tried to do. Apparently I made a mistake. Kind regards, Kristof - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" , "johan" , "matic" Verzonden: Zaterdag 29 augustus 2020 18:37:35 Onderwerp: Re: Missing libusb shared object file in xPack build. > On 29 Aug 2020, at 19:28, kristof.mul...@telenet.be wrote: > > What did I do wrong? For one, you merged different Git repos. This shows that you are far from understanding the build process. :-( > but I > still want to be able to compile OpenOCD from the sources :-) Sure, you're free to experiment, but you're on your own. Good luck! Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
> The key trick there is 'in the xpack-dev-tools/openocd Git repo'. Right, so I stay in the git repo that I cloned like this: $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash $ cd ~/Downloads/openocd-xpack.git So the "merge from upstream/master" is simply the pull command, and I don't need to specifically clone the official OpenOCD repo (git://git.code.sf.net/p/openocd/code)? - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" , "johan" , "matic" Verzonden: Zaterdag 29 augustus 2020 18:45:08 Onderwerp: Re: Missing libusb shared object file in xPack build. > On 29 Aug 2020, at 19:42, kristof.mul...@telenet.be wrote: > > To keep the development repository in sync with the original OpenOCD > repository, in the xpack-dev-tools/openocd Git repo: The key trick there is 'in the xpack-dev-tools/openocd Git repo'. But this will probably not solve your problem. Use ldd -v to check dependencies. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
> Once you have this running properly, > you can start experimenting with any > other commit, the build scripts do not > care what content they build. I got it running properly - so I feel entitled now to start experimenting with another commit (preferably the master branch of the official OpenOCD repo). So what would change in these commands to achieve that? I refer to the commands you posted in your previous mail: $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash $ sudo rm -rf ~/Work/openocd-* $ bash ~/Downloads/openocd-xpack.git/scripts/build.sh --linux64 Is it the trick with the '~/Downloads/openocd-xpack.git/scripts/defs-source.sh' file (uncommenting the last three lines)? Or is it something else? My sincere apologies for the hassle. I appreciate your help so much! Kind regards, Kristof - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "Tommy Murphy" , "johan" , "matic" , "openocd-devel" Verzonden: Zaterdag 29 augustus 2020 20:11:21 Onderwerp: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build. > On 29 Aug 2020, at 21:06, kristof.mul...@telenet.be wrote: > > does this pull the latest > master branch from the official OpenOCD git repo before doing the build? Negative, this is a production build that pulls a specific commit from my openocd fork. Once you have this running properly, you can start experimenting with any other commit, the build scripts do not care what content they build. Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
f kristof 3167422 Aug 29 17:54 xpack-openocd-0.10.0-14-win32-x64.zip -rw-rw-rw- 1 kristof kristof 104 Aug 29 17:54 xpack-openocd-0.10.0-14-win32-x64.zip.sha Sadly, I get the same old 'libusb-0.1.so.4' missing error... What did I do wrong? Thanks for all your help :-) - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" , "johan" , "matic" Verzonden: Zaterdag 29 augustus 2020 16:22:55 Onderwerp: Re: Missing libusb shared object file in xPack build. > On 29 Aug 2020, at 16:30, kristof.mul...@telenet.be wrote: > > $ ls -l > total 4816 > -rwxrwx--- 1 root vboxsf 73232 Aug 29 14:14 libftdi1.so.2.4.0 > -rwxrwx--- 1 root vboxsf 22840 Aug 29 14:14 libhidapi-hidraw.so.0.0.0 > -rwxrwx--- 1 root vboxsf 992288 Aug 29 14:14 libiconv.so.2.6.0 > -rwxrwx--- 1 root vboxsf 57848 Aug 29 14:14 libudev.so > -rwxrwx--- 1 root vboxsf 22808 Aug 29 14:14 libusb-0.1.so.4.4.4 > -rwxrwx--- 1 root vboxsf 111464 Aug 29 14:14 libusb-1.0.so.0.1.0 > -rwxrwx--- 1 root vboxsf 3634432 Aug 29 14:14 openocd > > So there is a shared object file 'libusb-0.1.so.4.4.4', but it seems like > OpenOCD is looking for 'libusb-0.1.so.4'. Why? Most probably because you have a broken build. You changed something in the build scripts that should not be changed. The original binaries were tested on multiple distributions/platforms, including Ubuntu 20, and all were ok: https://travis-ci.org/github/xpack-dev-tools/openocd-xpack/builds/702320342 To check file's dependencies, use 'ldd -v '. But mainly fix the build script. Or use the provided binaries, they just work; the reason for the xPack distribution to exist is exactly to avoid issues like this. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
Hi @Tommy Murphy, Thank you very much. I did not change the build scripts - except for commenting out the last three lines in: ~/Downloads/openocd-xpack.git/scripts / defs-source.sh Commenting out these last three lines enables the pulling of the latest OpenOCD git repo. Did you refer to this guide from Liviu: [ https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md | https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md ] Kind regards, Kristof Van: "Tommy Murphy" Aan: "Liviu Ionescu" , "kristof mulier" Cc: "johan" , "matic" , "openocd-devel" Verzonden: Zaterdag 29 augustus 2020 19:23:34 Onderwerp: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build. If you follow Liviu's build instructions to the letter everything will build perfectly every time. I've done it many times myself. Once you have his stuff building as is you can experiment with changing the build scripts or sources according to your requirements if necessary. But start first by just building everything without any changes. Is suggest starting with a clean (virtual) machine and doing everything from scratch before making any changes. Hope this helps. From: Liviu Ionescu Sent: Saturday, August 29, 2020 5:37:35 PM To: kristof.mul...@telenet.be Cc: johan ; matic ; openocd-devel Subject: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build. > On 29 Aug 2020, at 19:28, kristof.mul...@telenet.be wrote: > > What did I do wrong? For one, you merged different Git repos. This shows that you are far from understanding the build process. :-( > but I > still want to be able to compile OpenOCD from the sources :-) Sure, you're free to experiment, but you're on your own. Good luck! Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net [ https://lists.sourceforge.net/lists/listinfo/openocd-devel | https://lists.sourceforge.net/lists/listinfo/openocd-devel ] ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Missing libusb shared object file in xPack build.
Thanks @Liviu, That's simple indeed! I'm trying it right now. However, I was wondering: does this pull the latest master branch from the official OpenOCD git repo before doing the build? I remember one had to uncomment the last three lines in '~/Downloads/openocd-xpack.git/scripts/defs-source.sh' to achieve just that. Is that correct? Kind regards, Kristof - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "Tommy Murphy" , "johan" , "matic" , "openocd-devel" Verzonden: Zaterdag 29 augustus 2020 19:59:41 Onderwerp: Re: [OpenOCD-devel] Missing libusb shared object file in xPack build. > On 29 Aug 2020, at 20:34, kristof.mul...@telenet.be wrote: > > Did you refer to this guide from Liviu: > https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/README-BUILD.md On a Ubuntu 20 VM, with curl, git and docker installed: $ curl -L https://github.com/xpack-dev-tools/openocd-xpack/raw/xpack/scripts/git-clone.sh | bash $ sudo rm -rf ~/Work/openocd-* $ bash ~/Downloads/openocd-xpack.git/scripts/build.sh --linux64 $ '/home/ilg/Work/openocd-0.10.0-14/linux-x64/install/openocd/bin/openocd' --version xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev (2020-08-29-17:49) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html I doubt that it can be anything simpler than this. And, to quote a company with a fruit logo, "it just works". Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Patch for RISC-V microcontrollers from GigaDevice causes build trouble
Hi Jan, Thank you very much for your reply. I'm currently applying the build scripts from @Liviu Ionescu on the RISC-V OpenOCD fork you pointed at: [ https://github.com/riscv/riscv-openocd/ | https://github.com/riscv/riscv-openocd/ ] I'll try the OpenOCD executables on my GigaDevice GD32VF103C-START board: [ https://new.embeetle.com/#supported-hardware/giga/boards/gd32vf103c_start | https://new.embeetle.com/#supported-hardware/giga/boards/gd32vf103c_start ] Fingers crossed. Let's hope it will work! Kind regards, Kristof Mulier Van: "Jan Matyáš" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Donderdag 17 september 2020 08:35:54 Onderwerp: Re: [OpenOCD-devel] Patch for RISC-V microcontrollers from GigaDevice causes build trouble Hi Kristof, no; the RISC-V OpenOCD fork resides here: [ https://github.com/riscv/riscv-openocd/ | https://github.com/riscv/riscv-openocd/ ] This is where the development of RISC-V support takes place and where multiple developers contribute. And I am not the author, merely a contributor. (My personal riscv-openocd repo is just a personal space to work on individual little contributions.) I personally do not plan any work on supporting GigaDevice chips. Kind regards, Jan On Wed, Sep 16, 2020 at 5:42 PM < [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] > wrote: Hi Jan, Thank you very much for your reply. I noticed you have forked OpenOCD on GitHub and you added RISC-V support: [ https://github.com/JanMatCodasip/riscv-openocd | https://github.com/JanMatCodasip/riscv-openocd ] Do you by accident also support the GigaDevice microcontrollers with RISC-V core? If not - would the patches that GigaDevice sent me (see [ https://new.embeetle.com/downloads/openocd_riscv_patch.rar | https://new.embeetle.com/downloads/openocd_riscv_patch.rar ] ) be helpful for your fork? Hopefully you can push your RISC-V support to the OpenOCD master branch. That would be awesome ^_^ Kind regards, Kristof Mulier Van: "Jan Matyáš" < [ mailto:jmat...@codasip.com | jmat...@codasip.com ] > Aan: "kristof mulier" < [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] > Cc: "openocd-devel" < [ mailto:openocd-devel@lists.sourceforge.net | openocd-devel@lists.sourceforge.net ] > Verzonden: Woensdag 16 september 2020 15:49:23 Onderwerp: Re: [OpenOCD-devel] Patch for RISC-V microcontrollers from GigaDevice causes build trouble Dear Kristof, I only had a moment to look at the Jenkins build result: [ http://build.openocd.org/job/openocd-gerrit-build/TARGET=mingw64/lastFailedBuild/console | http://build.openocd.org/job/openocd-gerrit-build/TARGET=mingw64/lastFailedBuild/console ] Based on the log, it appears that the build failed due to code style issues (as checked by the [ http://checkpatch.pl/ | checkpatch.pl ] script). You may wish to point your contact person at GigaDevice at this log so that they can update their code accordingly (fix the code style), provided they intend to upstream the code. Kind regards, Jan On Wed, Sep 16, 2020 at 12:45 PM < [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] > wrote: BQ_BEGIN Dear Developers, I applied the patch from GigaDevice (see my earlier mail) on the OpenOCD source code. Then I pushed to gerrit. Unfortunately, Jenkins replied that the build failed: [ http://openocd.zylin.com/#/c/5835/ | http://openocd.zylin.com/#/c/5835/ ] I have no idea how to fix this, as I'm not familiar with the source code, nor with what this patch actually does. I got this patch from Mr. Leo Tzagkarakis (who works at GigaDevice). It is the company- patch they use to get their RISC-V microcontrollers working with OpenOCD. I thought it would be great if this patch makes it to the official repo, but my attempt failed. I hope someone more knowledgeable can help to fix this. Kind regards, Kristof PS: I've put the patch on our server. You can download it here: [ https://new.embeetle.com/downloads/openocd_riscv_patch.rar | https://new.embeetle.com/downloads/openocd_riscv_patch.rar ] ___ OpenOCD-devel mailing list [ mailto:OpenOCD-devel@lists.sourceforge.net | OpenOCD-devel@lists.sourceforge.net ] [ https://lists.sourceforge.net/lists/listinfo/openocd-devel | https://lists.sourceforge.net/lists/listinfo/openocd-devel ] BQ_END ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Patch for RISC-V microcontrollers from GigaDevice causes build trouble
Dear Developers, I applied the patch from GigaDevice (see my earlier mail) on the OpenOCD source code. Then I pushed to gerrit. Unfortunately, Jenkins replied that the build failed: [ http://openocd.zylin.com/#/c/5835/ | http://openocd.zylin.com/#/c/5835/ ] I have no idea how to fix this, as I'm not familiar with the source code, nor with what this patch actually does. I got this patch from Mr. Leo Tzagkarakis (who works at GigaDevice). It is the company- patch they use to get their RISC-V microcontrollers working with OpenOCD. I thought it would be great if this patch makes it to the official repo, but my attempt failed. I hope someone more knowledgeable can help to fix this. Kind regards, Kristof PS: I've put the patch on our server. You can download it here: [ https://new.embeetle.com/downloads/openocd_riscv_patch.rar | https://new.embeetle.com/downloads/openocd_riscv_patch.rar ] ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Patch for RISC-V microcontrollers from GigaDevice causes build trouble
Hi Jan, Thank you very much for your reply. I noticed you have forked OpenOCD on GitHub and you added RISC-V support: [ https://github.com/JanMatCodasip/riscv-openocd | https://github.com/JanMatCodasip/riscv-openocd ] Do you by accident also support the GigaDevice microcontrollers with RISC-V core? If not - would the patches that GigaDevice sent me (see [ https://new.embeetle.com/downloads/openocd_riscv_patch.rar | https://new.embeetle.com/downloads/openocd_riscv_patch.rar ] ) be helpful for your fork? Hopefully you can push your RISC-V support to the OpenOCD master branch. That would be awesome ^_^ Kind regards, Kristof Mulier Van: "Jan Matyáš" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Woensdag 16 september 2020 15:49:23 Onderwerp: Re: [OpenOCD-devel] Patch for RISC-V microcontrollers from GigaDevice causes build trouble Dear Kristof, I only had a moment to look at the Jenkins build result: [ http://build.openocd.org/job/openocd-gerrit-build/TARGET=mingw64/lastFailedBuild/console | http://build.openocd.org/job/openocd-gerrit-build/TARGET=mingw64/lastFailedBuild/console ] Based on the log, it appears that the build failed due to code style issues (as checked by the [ http://checkpatch.pl/ | checkpatch.pl ] script). You may wish to point your contact person at GigaDevice at this log so that they can update their code accordingly (fix the code style), provided they intend to upstream the code. Kind regards, Jan On Wed, Sep 16, 2020 at 12:45 PM < [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] > wrote: Dear Developers, I applied the patch from GigaDevice (see my earlier mail) on the OpenOCD source code. Then I pushed to gerrit. Unfortunately, Jenkins replied that the build failed: [ http://openocd.zylin.com/#/c/5835/ | http://openocd.zylin.com/#/c/5835/ ] I have no idea how to fix this, as I'm not familiar with the source code, nor with what this patch actually does. I got this patch from Mr. Leo Tzagkarakis (who works at GigaDevice). It is the company- patch they use to get their RISC-V microcontrollers working with OpenOCD. I thought it would be great if this patch makes it to the official repo, but my attempt failed. I hope someone more knowledgeable can help to fix this. Kind regards, Kristof PS: I've put the patch on our server. You can download it here: [ https://new.embeetle.com/downloads/openocd_riscv_patch.rar | https://new.embeetle.com/downloads/openocd_riscv_patch.rar ] ___ OpenOCD-devel mailing list [ mailto:OpenOCD-devel@lists.sourceforge.net | OpenOCD-devel@lists.sourceforge.net ] [ https://lists.sourceforge.net/lists/listinfo/openocd-devel | https://lists.sourceforge.net/lists/listinfo/openocd-devel ] ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Offer for website
Dear OpenOCD developers, We use OpenOCD in the Embeetle IDE. We are grateful for this free software, and also for the countless times you have helped us to fix certain problems. Although we didn’t contribute to the source code itself (yet), we feel part of the OpenOCD community. We’d like to do something back, something bigger than just drawing a logo. We had a great idea that we’d like to share with you. THE IDEA My colleague Johan designed a simple, elegant javascript-css skeleton that we based our website on: [ https://embeetle.com/ | https://embeetle.com ] On the same skeleton, we also built this website: [ https://qscintilla.com/ | https://qscintilla.com ] And I use it for my personal consultancy-website: [ https://chipdesk.com/ | https://chipdesk.com ] What do you think about giving OpenOCD a new look? Johan would like to send you the javascript-css code and he is happy to help with the practical implementations. Maybe the new OpenOCD version being released soon (see mail from @Paul Fertsen) is the perfect moment for this ^_^. Once implemented, users can download the new version on the download page of the new OpenOCD website. EXTRA CONTENT = We have some nice content on our Embeetle website about OpenOCD: [ https://embeetle.com/#embedded-dev/software/dev-tools/flash/basics | https://embeetle.com/#embedded-dev/software/dev-tools/flash/basics ] And here [not yet ready]: [ https://embeetle.com/#embeetle-ide/troubleshoot/flash | https://embeetle.com/#embeetle-ide/troubleshoot/flash ] And this [build instructions]: [ https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build | https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build ] We plan to write more pages in the future. It would be nice to add similar content to the OpenOCD website. Of course - we’d only add content to a test-version of the website, so you (the OpenOCD developers) can first check it before pushing anything to the public website. SOME FINAL THOUGHTS === If you like this idea, would you like to have a meeting to discuss it further? We could hold a zoom meeting / skype / ... Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] OpenOCD (or GDB) hangs when trying to flash a RISC-V chip from a single console.
Hi Andreas, Thank you very much for your reply. One of the config files indeed had a hidden 'init' somewhere. Removing that fixed the error. Now it's replaced with another error. I'll first try to fix this one myself - I'll call for help if all options don't work. Many thanks for your help. Kind regards, Kristof Mulier Van: "Andreas Fritiofson" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Dinsdag 27 oktober 2020 20:13:42 Onderwerp: Re: [OpenOCD-devel] OpenOCD (or GDB) hangs when trying to flash a RISC-V chip from a single console. On Tue, Oct 27, 2020 at 7:36 PM < [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] > wrote: Error: The 'gdb_port' command must be used before 'init'. I do not understand what this error message is trying to tell me. As you can see in my previous mail, I do invoke the 'gdb_port' command first before anything else. How can I solve this? That depends on what the config files are doing. Not all of the sourced files are in our tree so I have no way of telling if any of them contains a hidden 'init'. Obviously something is doing init since the JTAG chain is probed before the gdb_port command is evaluated. /Andreas ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] OpenOCD (or GDB) hangs when trying to flash a RISC-V chip from a single console.
I have to add something to my previous mail. GDB no longer hangs, but produces the following error message: Run flash-remote function: == flash-remote( elf_file = application.elf , openocd_path = openocd , probe_file = ../config/openocd_probe.cfg , chip_file = ../config/openocd_chip.cfg , ) xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-dirty (2020-10-26-06:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html jtag Info : CMSIS-DAP: SWD Supported Info : CMSIS-DAP: JTAG Supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (JTAG) Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 0 nTRST = 0 nRESET = 1 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : cmsis-dap JTAG TLR_RESET Info : cmsis-dap JTAG TLR_RESET Info : JTAG tap: riscv.cpu tap/device found: 0x1000563d (mfg: 0x31e (Andes Technology Corporation), part: 0x0005, ver: 0x1) Info : JTAG tap: auto0.tap tap/device found: 0x790007a3 (mfg: 0x3d1 (GigaDevice Semiconductor (Beijing)), part: 0x9000, ver: 0x7) Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 5 -expected-id 0x790007a3" Info : datacount=4 progbufsize=2 Info : Examined RISC-V core; found 1 harts Info : hart 0: XLEN=32, misa=0x40901105 Info : starting gdb server for riscv.cpu on Info : Listening on port for gdb connections Error: The 'gdb_port' command must be used before 'init'. Remote communication error. Target disconnected.: Success. make: *** [../config/makefile:622: flash] Error 1 make: Leaving directory 'C:/embeetle/beetle_projects/gd32vf103c_start/build' The main takeaway from this is the error message: Error: The 'gdb_port' command must be used before 'init'. I do not understand what this error message is trying to tell me. As you can see in my previous mail, I do invoke the 'gdb_port' command first before anything else. How can I solve this? Kind regards, Kristof Mulier Van: "kristof mulier" Aan: "openocd-devel" Verzonden: Dinsdag 27 oktober 2020 17:24:45 Onderwerp: [OpenOCD-devel] OpenOCD (or GDB) hangs when trying to flash a RISC-V chip from a single console. I'm running into quite a complicated problem. When I flash my RISC-V chip with two consoles - one for OpenOCD and another for GDB - the flash succeeds. When I try to flash it from a single console - a procedure I've successfully applied on countless ARM-based chips - it fails. I'll give more details below. FLASHING FROM TWO CONSOLES == To flash my GD32VF103CBT6 chip (GD32VF103C-START board from GigaDevice) I spawn two consoles: one for OpenOCD and another for GDB. It kind of works - I have to increase the remote timeout before instructing the microcontroller to reset and run: # after loading the firmware to the chip: (gdb) set remotetimeout 3000 (gdb) monitor reset run But aside from this issue with, the firmware flashes successfully. However, I might miss some anomalies in the output that some of you can better detect. Therefore, I've added the OpenOCD and GDB output to this mail: - openocd_output.txt - gdb_output.txt And also the OpenOCD config files: - openocd_chip.cfg - openocd_probe.cfg The OpenOCD version is compiled by GigaDevice themselves. They followed the xPack build procedure from Liviu Ionescu. The result can be found here, for Linux: [ https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z | https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z ] for Windows: [ https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z | https://new.embeetle.com/downloads/beetle_tools/windows/openocd_giga_0.10.0_dev_64b.7z ] FLASHING FROM A SINGLE CONSOLE In Embeetle IDE we aim to do the flashing procedure in a single console. That's why we give the following .gdbinit file to GDB at startup: define flash-remote echo \n echo \n echo \n Run flash-remote function: echo \n == echo \n flash-remote( echo \n elf_file = $arg0 , echo \n openocd_path = $arg1 , echo \n probe_file = $arg2 , echo \n chip_file = $arg3 , echo \n ) echo \n echo \n file $arg0 target extended-remote | $arg1 -f $arg2 -f $arg3 -c "gdb_port pipe; log_output openocd.log" load monitor reset run monitor shutdown quit end As you can see, this .gdbinit file instructs GDB to launch OpenOCD and hook into its GDB server. When launching
Re: [OpenOCD-devel] Offer for website
Hi Stuart,
ABOUT THE WEBSITE
=
You have a point. Yesterday, Johan and I talked about
this, and we fully understand the hesitation you and
other OpenOCD members feel about a javascript-based
website (in the sense that javascript is responsible
for showing static content). Johan told me:
> "It is perfectly possible to create a fully static
> website without javascript, but with a similar menu
> to ours."
This of course throws a new question in the group: do
you (OpenOCD developers) like the style - the "look and
feel" - of our website (https://embeetle.com)?
Johan will join the OpenOCD mailing list after the
weekend to join the discussions. He looks forward to
help out with the webdesign. It's one of the many
things he's very good at :-)
ABOUT EMBEETLE IDE
==
You said:
> "[..] bit hard to make a browser-based development
> environment without some sort of client-side code
> executing, whether it be JavaScript, Adobe Flash,
> Sun Java applets, etc."
Embeetle is not a browser-based IDE. It's a desktop
application intended for Linux and Windows. Is there
something about the homepage that made you think our
IDE is browser-based? If yes, that means we made a
mistake in our "communication strategy". Please tell
us, so we can make the appropriate changes ^_^
Kind regards,
Kristof Mulier
- Oorspronkelijk bericht -
Van: "Stuart Longland (VK4MSL)"
Aan: "openocd-devel"
Verzonden: Zondag 25 oktober 2020 00:32:48
Onderwerp: Re: [OpenOCD-devel] Offer for website
On 24/10/20 11:40 pm, kristof.mul...@telenet.be wrote:
> I don't think this is an issue. All modern browsers can
> handle javascript.
Yes, most modern browsers can execute JavaScript.
Do you want your browser to execute ${WEBSITE}'s JavaScript?
Do you have the time to review the minified JavaScript code that website
calls up to see if it is safe?
Do you have the expertise to conduct such a review?
I'm fine with JavaScript on a site that actually requires it to
accomplish the task it is designed for. These are called client-side
web applications. They're not simple web pages. Embeetle's own service
would be a good example here: bit hard to make a browser-based
development environment without some sort of client-side code executing,
whether it be JavaScript, Adobe Flash, Sun Java applets, etc.
Pages where the content is updated "live", sure, JavaScript all the way.
Rendering *static* menus and text on a page is not a job that JavaScript
is required for. It's a bg attack surface for little benefit.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
___
OpenOCD-devel mailing list
OpenOCD-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Does it matter when you pass the elf file to GDB?
Hi Liviu, Thank you for your reply. So your Eclipse plug-in also starts GDB without executable and then passes the executable with the 'file' command? Kind regards, Kristof Mulier - Oorspronkelijk bericht - Van: "Liviu Ionescu" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Maandag 26 oktober 2020 18:48:18 Onderwerp: Re: [OpenOCD-devel] Does it matter when you pass the elf file to GDB? > On 26 Oct 2020, at 17:33, kristof.mul...@telenet.be wrote: > > ... Should one always do it at GDB startup (on the commandline)? The Eclipse OpenOCD debug plug-in never passes the executable via the command line. Regards, Liviu ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] Offer for website
Hi David, I think you missed my most recent mails about this subject. I now fully understand the hesitation to rely on javascript for static content generation. No more need to convince me ;-) Kind regards, Kristof Mulier - Oorspronkelijk bericht - Van: "David Riley" Aan: "kristof mulier" Cc: "Paul Fertser" , "openocd-devel" Verzonden: Zondag 25 oktober 2020 14:55:09 Onderwerp: Re: [OpenOCD-devel] Offer for website On Oct 24, 2020, at 9:40 AM, kristof.mul...@telenet.be wrote: > > Hi Paul, > I think I get the point now. You are blocking javascript, > are you? > > Yes, Johan's website makes use of javascript to generate > the menu and load the content pages. So if you block > javascript, it won't work. > > I don't think this is an issue. All modern browsers can > handle javascript. It is an issue for many people who do not allow javascript to run unless explicitly trusted. - Dave ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] OpenOCD (or GDB) hangs when trying to flash a RISC-V chip from a single console.
I'm running into quite a complicated problem. When I flash my RISC-V chip with two consoles - one for OpenOCD and another for GDB - the flash succeeds. When I try to flash it from a single console - a procedure I've successfully applied on countless ARM-based chips - it fails. I'll give more details below. FLASHING FROM TWO CONSOLES == To flash my GD32VF103CBT6 chip (GD32VF103C-START board from GigaDevice) I spawn two consoles: one for OpenOCD and another for GDB. It kind of works - I have to increase the remote timeout before instructing the microcontroller to reset and run: # after loading the firmware to the chip: (gdb) set remotetimeout 3000 (gdb) monitor reset run But aside from this issue with, the firmware flashes successfully. However, I might miss some anomalies in the output that some of you can better detect. Therefore, I've added the OpenOCD and GDB output to this mail: - openocd_output.txt - gdb_output.txt And also the OpenOCD config files: - openocd_chip.cfg - openocd_probe.cfg The OpenOCD version is compiled by GigaDevice themselves. They followed the xPack build procedure from Liviu Ionescu. The result can be found here, for Linux: [ https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z | https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z ] for Windows: [ https://new.embeetle.com/downloads/beetle_tools/linux/openocd_giga_0.10.0_dev_64b.7z | https://new.embeetle.com/downloads/beetle_tools/windows/openocd_giga_0.10.0_dev_64b.7z ] FLASHING FROM A SINGLE CONSOLE In Embeetle IDE we aim to do the flashing procedure in a single console. That's why we give the following .gdbinit file to GDB at startup: define flash-remote echo \n echo \n echo \n Run flash-remote function: echo \n == echo \n flash-remote( echo \n elf_file = $arg0 , echo \n openocd_path = $arg1 , echo \n probe_file = $arg2 , echo \n chip_file = $arg3 , echo \n ) echo \n echo \n file $arg0 target extended-remote | $arg1 -f $arg2 -f $arg3 -c "gdb_port pipe; log_output openocd.log" load monitor reset run monitor shutdown quit end As you can see, this .gdbinit file instructs GDB to launch OpenOCD and hook into its GDB server. When launching GDB, we not only pass this .gdbinit file, but also give it a couple of flags on the commandline. This is our flash target in the makefile, so you can see the flags for yourself: GDB_FLASHFLAGS = \ -n \ -batch \ -x ../config/.gdbinit \ -ex "flash-remote $(ELF_FILE) openocd ../config/openocd_probe.cfg ../config/openocd_chip.cfg" \ .PHONY : flash flash : $(ELF_FILE) $(GDB) $(GDB_FLASHFLAGS) In short, GDB starts in batch mode, is given a .gdbinit file with a user-defined-function and that same function is then called with the proper arguments. We've applied this technique to countless other chips (ARM-based ones) and it always worked. However, when running this flash target, I get the following output: Run flash-remote function: == flash-remote( elf_file = application.elf , openocd_path = openocd , probe_file = ../config/openocd_probe.cfg , chip_file = ../config/openocd_chip.cfg , ) xPack OpenOCD, x86_64 Open On-Chip Debugger 0.10.0+dev-dirty (2020-10-26-06:00) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html jtag Info : CMSIS-DAP: SWD Supported Info : CMSIS-DAP: JTAG Supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (JTAG) Info : SWCLK/TCK = 1 SWDIO/TMS = 1 TDI = 1 TDO = 1 nTRST = 0 nRESET = 1 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : cmsis-dap JTAG TLR_RESET Info : cmsis-dap JTAG TLR_RESET Info : Then it hangs. Nothing happens - I have to kill the process. There is no openocd.log file to be found. What could the problem be? Kind regards, Kristof Mulier openocd_chip.cfg Description: Binary data openocd_probe.cfg Description: Binary data C:\Users\Gebruiker\beetle_projects\gd32vf103c_start_baremetal\build>riscv-none-embed-gdb.exe riscv-none-embed-gdb.exe: warning: Couldn't determine a path for the index cache directory. GNU gdb (xPack GNU RISC-V Embedded GCC, 64-bit) 8.3 Copyright (C) 2019 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistri
Re: [OpenOCD-devel] Offer for website
Hi Paul, 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 don't know when you took this screenshot. The website has been unstable some days ago because Johan was doing experiments on it. Please let me know if it works now. Kind regards, Kristof Mulier - Oorspronkelijk bericht - Van: "Paul Fertser" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Zaterdag 24 oktober 2020 15:28:17 Onderwerp: 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
Re: [OpenOCD-devel] Offer for website
Hi Marc, Thank you for your reply. ABOUT THE WEBSITE = I can reassure you - Johan's websites are NOT Wordpress-based. Our first Embeetle website was made in Wordpress, but there were too many problems. So we decided to throw Wordpress in the bin and start from scratch. Johan designed a clean website structure that all of us (Embeetle developers) can easily add content to. Personally, I'm not versed in web development - so I was happy my Embeetle colleague Johan took this task on his shoulders. Once he finished the backend, I just needed HTML and some basic CSS to add new pages. Each new page appears automatically in the menu on the left (Johan's backend takes care of that). I just talked to Johan, and we have the following questions: - Do you (OpenOCD developers) have basic HTML knowledge to add content that way? Or would you prefer some kind of markup system? - If you're worried it would be hard to add content to the website, Johan can make an admin page where you can add a new page directly in the browser. The admin page would provide a basic editor in which you can enter the HTML for the new page (or edit HTML of an existing page). - Johan's website structure is NOT a blog. A blog is typically less organized than a hierarchical menu. Do you (OpenOCD developers) prefer a blog or a website? If you prefer a website, we can offer one in the same style and structure as ours (https://embeetle.com). ABOUT NIKOLA This looks interesting indeed. However, neither me, nor my colleague Johan knows the Nikola framework. It would take us quite some time to get used to it. We'll look into it and give some feedback later. ABOUT HTTPS === I asked Johan about https, and he replied: "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" Why don't we setup a zoom/skype meeting to talk these things through? To have a successfull meeting, we should certainly invite the OpenOCD developers that are involved in the website. But I have no idea who that is? Kind regards, Kristof Mulier - Oorspronkelijk bericht - Van: "dev" Aan: "kristof mulier" , "openocd-devel" Verzonden: Vrijdag 23 oktober 2020 20:01:13 Onderwerp: Re: [OpenOCD-devel] Offer for website Hi Kristof, I would love to see a new website on openocd.org. The current one looks quite ugly and old. However, personally I would prefer to have a blog-like website as the current one. It's easier to publish new content. To reduce maintenance (security updates etc.) I would rather use a static website like Nikola [1] than WordPress. We should also update the website to httpS... Any opinions on that? Best regards, Marc [1] https://getnikola.com/ On Fri, 2020-10-23 at 13:07 +0200, kristof.mul...@telenet.be wrote: > Dear OpenOCD developers, > > We use OpenOCD in the Embeetle IDE. We are grateful for this free > software, and also for the countless times you have helped us to > fix certain problems. Although we didn’t contribute to the source > code itself (yet), we feel part of the OpenOCD community. > > We’d like to do something back, something bigger than just drawing > a logo. We had a great idea that we’d like to share with you. > > THE IDEA > > My colleague Johan designed a simple, elegant javascript-css skeleton > that we based our website on: > https://embeetle.com > > On the same skeleton, we also built this website: > https://qscintilla.com > > And I use it for my personal consultancy-website: > https://chipdesk.com > > What do you think about giving OpenOCD a new look? Johan would > like to send you the javascript-css code and he is happy to help > with the practical implementations. > > Maybe the new OpenOCD version being released soon (see mail from > @Paul Fertsen) is the perfect moment for this ^_^. Once implemented, > users can download the new version on the download page of the new > OpenOCD website. > > EXTRA CONTENT > = > We have some nice content on our Embeetle website about OpenOCD: > https://embeetle.com/#embedded-dev/software/dev-tools/flash/basics > > And here [not yet ready]: > https://embeetle.com/#embeetle-ide/troubleshoot/flash > > And this [build instructions]: > https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build > > We plan to write more pages in the future. It would be nice to > add similar content to the OpenOCD website. Of course - we’d only > add content to a test-version of the website, so you (the OpenOCD > developers) can first check it before pushing anything to the public > website. > >
Re: [OpenOCD-devel] Offer for website
Hi Paul, I think I get the point now. You are blocking javascript, are you? Yes, Johan's website makes use of javascript to generate the menu and load the content pages. So if you block javascript, it won't work. I don't think this is an issue. All modern browsers can handle javascript. Kind regards, Kristof Mulier - Oorspronkelijk bericht - Van: "Paul Fertser" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Zaterdag 24 oktober 2020 15:28:17 Onderwerp: 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] Does it matter when you pass the elf file to GDB?
Dear OpenOCD developers, To flash microcontrollers, I usually launch GDB and make it connect to OpenOCD. Then I issue these commands: file my_application.elf load When GDB starts, it always complains there is no file assigned for debugging. Obviously, that's because I assign the file after GDB started (with the file command). Alternatively, one can pass the .elf immediately to GDB when launching the tool (as a commandline argument). GDB no longer complains at startup. Is there any difference between these two approaches? I always thought it doesn't matter, but the following discussion raises suspicion that there is a difference (see [ https://github.com/sifive/freedom-tools/issues/22 | https://github.com/sifive/freedom-tools/issues/22 ] ): > You can get gdb into 32-bit mode by using "set arch riscv:rv32". > However, you can still run into problems if gdb and the target > disagree on the size and/or number of FP registers. Generally, > the best way to start gdb is to give it a binary compiled for the > target, and let gdb grab arch info from the binary instead of > using defaults. > However, I would expect that when gdb connects to openocd, > that openocd then supplies gdb with target architecture info, > so this should work automatically, even if no binary is supplied > to gdb. So, does it actually matter when you pass the .elf file to GDB? Should one always do it at GDB startup (on the commandline)? Thanks for your help ^_^ Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Website Offer
Hi Paul, Michael and Andrzej, I just talked to my colleague Johan. Here are some of his quotes in our discussion: > I fully understand their hesitation to use javascript. > The Sikando website [consultancy website] is also fully > static, with no javascript. > Many years ago, I tried to "live" without javascript, > because I felt like them that the internet should be > "structured information with semantic markup with > hyperlinks", the original idea from tim Berners-Lee. > Ultimately, I gave up on that, because I felt I was > missing out too much stuff because I couldn't use so > many websites. > > It is perfectly possible to create a fully static > website without javascript but with a similar menu > to ours. > Functionality that wouldn't work includes the folding > sections within a page, possibly popup notes, ... > > I also understand their desire to stay in control of > their website. Of course, we could find an arrangement > for that (I become an OpenOCD member, we sign some kind > of contract, the OpenOCD organization rents its own > server on Contabo, whatever). Johan concluded that he will join the OpenOCD developers mailing list. Soon he'll be around here ^_^ Is there anything else - website-related or other - we could help you with? Kind regards, Kristof Mulier ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] New logo matrix to vote on
Hi Paul, I've added the non-curly USB cable icon. It's icon A6: https://embeetle.com/figures/logo_matrix.png Your vote is registered :-) Kind regards, Kristof - Oorspronkelijk bericht - Van: "Paul Fertser" Aan: "kristof mulier" Verzonden: Dinsdag 28 juli 2020 11:35:55 Onderwerp: Re: [OpenOCD-devel] New logo matrix to vote on Hey Kristof! I personally prefer number 3 from your original post (USB cable without a loop, A1 is nice too but I'd rather see no loop there) but that's not available in your new matrix. Not sure if you should bother with that, I'm fine with whatever final choice. -- 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] Launch OpenOCD from GDB in one console
Hi @Tommy Murphy, Thanks a lot. I've read the sections you suggested, and got it working! All that needed to be done is modifying the first line in the .gdbinit file: target extended-remote | openocd -f ../config/flash_config/openocd_probe.cfg -f ../config/flash_config/openocd_chip.cfg -s "C:/path/to/scripts" -c "gdb_port pipe; log_output openocd.log" monitor reset halt monitor flash erase_address 0x800 0x0020 monitor reset halt file foobar.elf load monitor reset run monitor shutdown quit Then I launch GDB in the usual way: $ arm-none-eabi-gdb -x ../config/flash_config/.gdbinit Huray, it works! Thanks ^_^ Kind regards, Kristof Mulier Van: "Tommy Murphy" Aan: "openocd-devel" , "kristof mulier" Verzonden: Maandag 27 juli 2020 11:53:24 Onderwerp: Re: Launch OpenOCD from GDB in one console Have you reviewed section 7.3 of the openocd users guide about using the pipe option and section 21.1 about using gdb in this context? From: kristof.mul...@telenet.be Sent: Monday, July 27, 2020 10:29:10 AM To: openocd-devel Subject: [OpenOCD-devel] Launch OpenOCD from GDB in one console Dear developers, As you might know, I'm working in a startup building a new (free!) IDE for microcontrollers: Embeetle IDE. To flash code we generally use a combination of OpenOCD and GDB. Both are launched as targets from the makefile in two separate consoles. I was wondering if it's possible to flash from just one makefile target (in one console). Let me first explain the way we do it now. The makefile target openocd looks like this: .PHONY : openocd openocd : $(OUTPUT_FILENAME) .elf $(OCD) $(OCDFLAGS) with the following flags: OCDFLAGS_DASHBOARD = -f ../config/flash_config/openocd_probe.cfg \ -f ../config/flash_config/openocd_chip.cfg \ -s " $(dir OCD ) ../scripts " \ -c " init; reset halt " \ Target gdb looks like this: .PHONY : gdb gdb : $(OUTPUT_FILENAME) .elf $(GDB) $(GDBFLAGS) With the following flags: GDBFLAGS_DASHBOARD = -x ../config/flash_config/.gdbinit \ So if the user clicks the flash button, we first launch target openocd and then target gdb shortly after. GDB then runs its commands from .gdbinit , which actually instructs GDB to connect to OpenOCD and initiate the flash: # .gdbinit file target remote localhost: monitor reset halt monitor flash erase_address 0x800 0x0020 monitor reset halt file foobar.elf load monitor reset run monitor shutdown quit Now is there a way to do all this from just one makefile target, and therefore also from one console? I heard about the possibility to launch OpenOCD from a GDB session, like: (gdb) target remote | openocd ... I tried it, but the console gets locked and no longer accepts gdb commands to be executed. ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] Launch OpenOCD from GDB in one console
Dear developers, As you might know, I'm working in a startup building a new (free!) IDE for microcontrollers: Embeetle IDE. To flash code we generally use a combination of OpenOCD and GDB. Both are launched as targets from the makefile in two separate consoles. I was wondering if it's possible to flash from just one makefile target (in one console). Let me first explain the way we do it now. The makefile target openocd looks like this: .PHONY : openocd openocd : $(OUTPUT_FILENAME) .elf $(OCD) $(OCDFLAGS) with the following flags: OCDFLAGS_DASHBOARD = -f ../config/flash_config/openocd_probe.cfg \ -f ../config/flash_config/openocd_chip.cfg \ -s " $(dir OCD ) ../scripts " \ -c " init; reset halt " \ Target gdb looks like this: .PHONY : gdb gdb : $(OUTPUT_FILENAME) .elf $(GDB) $(GDBFLAGS) With the following flags: GDBFLAGS_DASHBOARD = -x ../config/flash_config/.gdbinit \ So if the user clicks the flash button, we first launch target openocd and then target gdb shortly after. GDB then runs its commands from .gdbinit , which actually instructs GDB to connect to OpenOCD and initiate the flash: # .gdbinit file target remote localhost: monitor reset halt monitor flash erase_address 0x800 0x0020 monitor reset halt file foobar.elf load monitor reset run monitor shutdown quit Now is there a way to do all this from just one makefile target, and therefore also from one console? I heard about the possibility to launch OpenOCD from a GDB session, like: (gdb) target remote | openocd ... I tried it, but the console gets locked and no longer accepts gdb commands to be executed. ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] GigaDevice support
Hi Tomas, > "Please believe me, we (maintainers) have no time to gather changes from > every fork of OpenOCD on github and everywhere. And moreover if we did so it > would be quite unfair to the authors of lots of changes which are already > waiting in the gerrit." I didn't realize this before. My apologies. I'll contact GigaDevice and explain it to them. About the free GigaDevice boards, are you (and/or some of your co-workers) interested? Kind regards, Kristof Mulier Van: "openocd-devel" Aan: "openocd-devel" Verzonden: Maandag 30 november 2020 10:50:40 Onderwerp: Re: [OpenOCD-devel] GigaDevice support Hi Kristof, On 22/11/2020 11:57, [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] wrote: Hi Marc, Tomas, Karl and others, I noticed some activity on Gerrit regarding the Risc-V based GigaDevice GD32VF103 microcontroller: [ http://openocd.zylin.com/#/c/5839/ | http://openocd.zylin.com/#/c/5839/ ] I just want to inform all of you that GigaDevice forked OpenOCD a couple of days ago: [ https://github.com/GigaDevice-Semiconductor/openocd | https://github.com/GigaDevice-Semiconductor/openocd ] In their fork, they're adding support for their chips. It can be a first step to upstream these fixes to the official OpenOCD repo. I'm in contact with some engineers at GigaDevice. They're very kind and helpful, so please don't hesitate to post questions/ideas/issues/... on their GitHub page. Kind regards, Kristof Mulier On 29/11/2020 16:06, [ mailto:kristof.mul...@telenet.be | kristof.mul...@telenet.be ] wrote: BQ_BEGIN 2. GigaDevice recently forked OpenOCD and applied some fixes/additions to support some of their MCUs (see [ https://github.com/GigaDevice-Semiconductor/openocd | https://github.com/GigaDevice-Semiconductor/openocd ] ). Maybe it's good to have a look at this fork and merge their fixes with yours? In any case, it would be sad if part of the OpenOCD community keeps working on GigaDevice MCU support in the official OpenOCD repo, and other part of the community (including the GigaDevice engineers) does the same work in their own fork. I think it's good to contact GigaDevice to discuss this - what do you think? I can help with putting you in contact with the right people. BQ_END I'm afraid you misunderstand how our project works. [ http://openocd.org/doc/doxygen/html/patchguide.html | http://openocd.org/doc/doxygen/html/patchguide.html ] clearly states: -- Submitting patches to the OpenOCD Gerrit server OpenOCD is to some extent a "self service" open source project, so to contribute, you must follow the standard procedures to have the best possible chance to get your changes accepted. - Please believe me, we (maintainers) have no time to gather changes from every fork of OpenOCD on github and everywhere. And moreover if we did so it would be quite unfair to the authors of lots of changes which are already waiting in the gerrit. So if GidaDevice people want to contribute upstream, they can send changes to gerrit as anybody other do (including ST Microelectronics). If they preferred to create a fork, it's their business and we can't do anything about it... If you have a contact to "the right people" please forward him this mail. Tom ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
[OpenOCD-devel] GigaDevice support
Hi Marc, Tomas, Karl and others, I noticed some activity on Gerrit regarding the Risc-V based GigaDevice GD32VF103 microcontroller: http://openocd.zylin.com/#/c/5839/ I just want to inform all of you that GigaDevice forked OpenOCD a couple of days ago: https://github.com/GigaDevice-Semiconductor/openocd In their fork, they're adding support for their chips. It can be a first step to upstream these fixes to the official OpenOCD repo. I'm in contact with some engineers at GigaDevice. They're very kind and helpful, so please don't hesitate to post questions/ideas/issues/... on their GitHub page. Kind regards, Kristof Mulier - Oorspronkelijk bericht - Van: "Marc Schink (Code Review)" Aan: "kristof mulier" Cc: "Tomas Vanek" , "Karl Palsson" Verzonden: Zondag 22 november 2020 11:27:58 Onderwerp: Change in openocd[master]: flash/nor: Add GigaDevice GD32VF103 driver Marc Schink has posted comments on this change. ( http://openocd.zylin.com/5839 ) Change subject: flash/nor: Add GigaDevice GD32VF103 driver .. Patch Set 2: > More than 70% of code is common for both stm32f1.c and gd32vf103.c In terms > of the long term maintenance the duplicated code is pain. I know but it somehow feels wrong to use the stm32f1 driver for a different MCU family with different architecture. I didn't compare both drivers. Are you sure that we don't need some ugly hacks to make the GD32VF work with the current stm32f1 driver? -- To view, visit http://openocd.zylin.com/5839 To unsubscribe, visit http://openocd.zylin.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: Ia17e1d28649def0e9164e30c2b9163cb57a97029 Gerrit-PatchSet: 2 Gerrit-Project: openocd Gerrit-Branch: master Gerrit-Owner: Kristof Mulier Gerrit-Reviewer: Karl Palsson Gerrit-Reviewer: Marc Schink Gerrit-Reviewer: Tomas Vanek Gerrit-Reviewer: jenkins Gerrit-HasComments: No ___ OpenOCD-devel mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] [openocd:tickets] Re: #289 Error: The specified debug interface was not found (ft232r)
Hi Avinash, I find the build scripts from Liviu Ionescu very easy to use and they always work. It seems like you're working on Windows. No problem - on this page you will see exactly what to do: [ https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build | https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build ] Hope this helps. Kind regards, Kristof Mulier Van: "openocd-devel" Aan: "openocd-devel" Cc: "avinash chavan" Verzonden: Maandag 28 december 2020 13:31:06 Onderwerp: [OpenOCD-devel] [openocd:tickets] Re: #289 Error: The specified debug interface was not found (ft232r) Hello Sir @Tommy Murphy, I have used sources which is readily available on internet, but if I have to build it accordingly what would be the exact procedure? Do I need to build it in different software(eg. MS visual 2017) or can I just build it through command prompt? If you have any source file for above required interface, can you share it to me? Thank You! Avinash [ https://sourceforge.net/p/openocd/tickets/289/ | [tickets:#289] ] Error: The specified debug interface was not found (ft232r) Status: new Milestone: 0.10.0 Created: Sat Dec 26, 2020 12:50 PM UTC by avinash chavan Last Updated: Mon Dec 28, 2020 12:30 PM UTC Owner: nobody Hello, I am using Picoevb board and I have to program my FPGA through memory via OPENOCD software. I am getting following error; C :\ OpenOCD - 20200729 - 0 . 10 . 0 >** openocd . exe - f flash . cfg ** Open On - Chip Debugger 0 . 10 . 0 ( 2020 - 07 - 29 ) [ https : // github . com / sysprogs / openocd ] Licensed under GNU GPL v2 libusb1 09 e75e98b4d9ea7909e8837b7a3f00dda4589dc3 For bug reports , read http : // openocd . org / doc / doxygen / bugs . html Error : The specified debug interface was not found ( ft232r ) The following debug adapters are available : 1 : ftdi 2 : usb_blaster 3 : usbprog 4 : jlink 5 : vsllink 6 : rlink 7 : ulink 8 : arm - jtag - ew 9 : hla 10 : osbdm 11 : opendous 12 : aice 13 : cmsis - dap 14 : xds110 15 : st - link How to include ft232r interface into my pkg? I am new into this. I have downloaded updated source files but I am not seeing any openocd.exe file there to run my command , So I want to know everything related to it. please provide me the link to that particular source files for above needs. Thank You! Avinash Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to [ https://sourceforge.net/p/openocd/tickets/ | 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. | 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 mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: [OpenOCD-devel] #289 Error: The specified debug interface was not found (ft232r)
Hi @Tommy Murphy, I also can't send mail to avina...@users.sourceforge.net Same error message Van: "Tommy Murphy" Aan: "avinash chavan" , "kristof mulier" Cc: "openocd-devel" Verzonden: Maandag 28 december 2020 15:38:48 Onderwerp: Re: #289 Error: The specified debug interface was not found (ft232r) BTW I keep getting this bounce in response to my emails... sfi-mx-3.v28.lw.sourceforge.com rejected your message to the following email addresses: avinash chavan (avina...@users.sourceforge.net) From: Tommy Murphy Sent: Monday, December 28, 2020 2:27:02 PM To: avinash chavan ; kristof.mul...@telenet.be Cc: openocd-devel Subject: Re: [OpenOCD-devel] #289 Error: The specified debug interface was not found (ft232r) Bear in mind that to use Liviu's scripts to build from the official upstream openocd repo you'll need to edit this file: https://github.com/xpack-dev-tools/openocd-xpack/blob/xpack/scripts/defs-source.sh#L41 From: kristof.mul...@telenet.be Sent: Monday, December 28, 2020 12:39:49 PM To: avinash chavan Cc: openocd-devel Subject: Re: [OpenOCD-devel] [openocd:tickets] Re: #289 Error: The specified debug interface was not found (ft232r) Hi Avinash, I find the build scripts from Liviu Ionescu very easy to use and they always work. It seems like you're working on Windows. No problem - on this page you will see exactly what to do: [ https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build | https://embeetle.com/#embedded-dev/software/dev-tools/flash/openocd_build ] Hope this helps. Kind regards, Kristof Mulier Van: "openocd-devel" Aan: "openocd-devel" Cc: "avinash chavan" Verzonden: Maandag 28 december 2020 13:31:06 Onderwerp: [OpenOCD-devel] [openocd:tickets] Re: #289 Error: The specified debug interface was not found (ft232r) Hello Sir @Tommy Murphy, I have used sources which is readily available on internet, but if I have to build it accordingly what would be the exact procedure? Do I need to build it in different software(eg. MS visual 2017) or can I just build it through command prompt? If you have any source file for above required interface, can you share it to me? Thank You! Avinash [ https://sourceforge.net/p/openocd/tickets/289/ | [tickets:#289] ] Error: The specified debug interface was not found (ft232r) Status: new Milestone: 0.10.0 Created: Sat Dec 26, 2020 12:50 PM UTC by avinash chavan Last Updated: Mon Dec 28, 2020 12:30 PM UTC Owner: nobody Hello, I am using Picoevb board and I have to program my FPGA through memory via OPENOCD software. I am getting following error; C :\ OpenOCD - 20200729 - 0 . 10 . 0 >** openocd . exe - f flash . cfg ** Open On - Chip Debugger 0 . 10 . 0 ( 2020 - 07 - 29 ) [ https : // github . com / sysprogs / openocd ] Licensed under GNU GPL v2 libusb1 09 e75e98b4d9ea7909e8837b7a3f00dda4589dc3 For bug reports , read http : // openocd . org / doc / doxygen / bugs . html Error : The specified debug interface was not found ( ft232r ) The following debug adapters are available : 1 : ftdi 2 : usb_blaster 3 : usbprog 4 : jlink 5 : vsllink 6 : rlink 7 : ulink 8 : arm - jtag - ew 9 : hla 10 : osbdm 11 : opendous 12 : aice 13 : cmsis - dap 14 : xds110 15 : st - link How to include ft232r interface into my pkg? I am new into this. I have downloaded updated source files but I am not seeing any openocd.exe file there to run my command , So I want to know everything related to it. please provide me the link to that particular source files for above needs. Thank You! Avinash Sent from sourceforge.net because openocd-devel@lists.sourceforge.net is subscribed to [ https://sourceforge.net/p/openocd/tickets/ | 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. | 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 mailing list OpenOCD-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openocd-devel
Re: Porting the P Multilink Universal adapter
Did anyone contact P Micro directly, to ask them if they can change the license on that dll? If not - I'm willing to give it a try ^_^ Kind regards, Kristof Mulier
Re: Porting the P Multilink Universal adapter
Hi Antonio, > I'm really skeptical they would agree to change the license. Why would they not agree? They sell hardware. If more people can use their hardware (eg. through OpenOCD), that's better for their sales. Kind regards, Kristof - Oorspronkelijk bericht - Van: "Antonio Borneo" Aan: "kristof mulier" Cc: "openocd-devel" Verzonden: Maandag 11 oktober 2021 10:47:25 Onderwerp: Re: Porting the P Multilink Universal adapter On Mon, Oct 11, 2021 at 9:52 AM wrote: > > Did anyone contact P Micro directly, to ask them if they can change the > license on that dll? > > If not - I'm willing to give it a try ^_^ > > Kind regards, > Kristof Mulier Hi Kristof, thanks for your offer. I'm really skeptical they would agree to change the license. It could be more realistic asking for the USB protocol description, eventually under NDA, limited to the only purpose of supporting their adapter in OpenOCD. But in this case, we need someone interested/available in doing the driver's coding. Antonio
Orbtrace probe
Hi Antonio, Hi Mike, I'd like to add the price too. Dave just told me on the Discord channel: > Pricing is 100 EUR for the board and 30 EUR for the case, > so 130 EUR + P + Taxesbut it's a PROJECT to join. > If you want a PRODUCT that should deffo work put a 0 on > the end of the price and buy a JTrace. This was my previous mail: - --- My friend Dave Marples (mubes on Github/Discord) has been working on a debug/trace probe together with Vegherd Erikson (zyp). It will be available very very soon indeed, called ORBTrace. It's a dinky little thing (see .png figure added to this mail) that offers both TRACE and CMSIS-DAP debug. It's tested with OpenOCD, PyOCD and BlackMagic probe. It will read SWD to file at around 1.5MBytes/sec using OpenOCD on a STM32F427. An initial quantity of 150 units has been made and there's a waiting list at Issue 1 at [ https://github.com/orbcode/orbtrace | https://github.com/orbcode/orbtrace ] It should be viewed as a project not a product, and it's fully open source. Early adopters are sought to help expand it's capabilities. There's a Discord to join at [ https://discord.gg/P7FYThy | https://discord.gg/P7FYThy ] to learn more. Dave is d...@marples.net if you want direct contact. I told Dave about the discussion here, and he's going to join the mailing list now ^_^ - --- Kind regards, Kristof Mulier
