slobodan has quit [Read error: Connection reset by peer]
slobodan has joined #openocd
urja has quit [Read error: Connection reset by peer]
gzlb has quit [Quit: WeeChat 4.2.1]
gzlb has joined #openocd
urja has joined #openocd
slobodan_ has joined #openocd
slobodan has quit [Read error: Connection reset by peer]
firelegend has joined #openocd
slobodan__ has joined #openocd
slobodan_ has quit [Ping timeout: 255 seconds]
zjason``` is now known as zjason
bvernoux has joined #openocd
firelegend has quit [Ping timeout: 250 seconds]
Hawk777 has joined #openocd
Heisey has joined #openocd
<Heisey>
I'm having an issue with flashing/debugging an STM32F4 MCU via CLion... I am not sure what's changed, but it used to work for me and it no longer works. The symtpom I see is that the MCU's flash simply doesn't change.
<Heisey>
The other tools do work (ST's programmer and IDE for step debugging and breakpoints)
<Heisey>
I have a feeling this might have to do with my board configuration file... but I seem to recall that configuration files worked out of the box
<PaulFertser>
Heisey: hi
<PaulFertser>
Heisey: please use some pastebin to show OpenOCD output.
<PaulFertser>
Heisey: does clion allow to enter GDB commands interactively? You can try "compare-sections" to verify.
<PaulFertser>
Heisey: board configuration file is unlikely to be a problem here if we talk about the flash memory inside MCU as that's defined by target configuration file which is sourced normally.
Haohmaru has quit [Quit: saionara]
jybz has quit [Quit: Ciao !]
nerozero has quit [Ping timeout: 255 seconds]
slobodan has joined #openocd
slobodan__ has quit [Ping timeout: 260 seconds]
slobodan_ has joined #openocd
slobodan has quit [Ping timeout: 260 seconds]
slobodan has joined #openocd
slobodan_ has quit [Read error: Connection reset by peer]
jybz has joined #openocd
bero has joined #openocd
<bero>
Hi, we'd like to help get the patches from the RISC-V fork of openocd (https://github.com/riscv-collab/riscv-openocd/) upstream. Given the large number of commits there, I doubt it's feasible to submit the patches one by one -- would it be acceptable to squash them into a few patches and submit those? (e.g. one patch "Add RISC-V", then one for adding specific boards, etc.)?
slobodan has quit [Remote host closed the connection]
slobodan has joined #openocd
<PaulFertser>
bero: I think you'd need to discuss it with borneoa___ , probably on weekend. But why do you say "Add RISC-V" in the first place? The first commit introducing support for at least some features was in 2018!
<borneoa___>
bero: yes, that has already been done once in the past. My only concern is that the contributors don't get mentioned anymore, which I think isn't fear. If you get a way to list the contributors in the commit message, that would be nice.
<PaulFertser>
You just can take the current support and replace it with your code in one go, that's guaranteed to break some usecases for existing users.
<PaulFertser>
s/can/can't/
<bero>
Yes, wasn't the best example, it should have been something like "generic RISC-V improvements" or so.
<bero>
Should be easy enough to extract the contributors from the fork's commits
<PaulFertser>
bero: well, it's better still be reviewable somehow.
<PaulFertser>
bero: are you coordinating this effort with Tim Newsome ?
<bero>
yes, that's the plan
<borneoa___>
bero: the commit message should report the feature, e.g. "target: risc-v: add support for xxx" and in the rest of the message highlight that the feature was already in the fork and the patch moves it upstream
<bero>
yes, makes sense
<PaulFertser>
bero: for a big change like that please try your best to not regress anything, and also run clang static check locally prior to submitting and other automated ways. Also please check src/target/riscv/ to see what kind of issues was fixed before, e.g. b8735bbf7ed7eedb0590edbf2a22929b401887ba .
<borneoa___>
bero: pay attention that cJTAG feature was already proposed upstream and put on hold as it doesn't fit in current framework. I have a framework rework in my TODO list, but time is never enough
<borneoa___>
PaulFertser: OpenOCD v0.12 breaks build on distro that have installed the new libgpiod v2.x.y. I'm going to merge a build fix next weekend, so tagging asap v0.13 could help distro maintainers. In mean time, they could still disable the driver that uses libgpiod v1 or taking the fix. What you think is the best approach in this case? New tag or document the workaround on the mailing list (or both)?
<PaulFertser>
borneoa___: tagging in a hurry might be problematic too because code would propogate to many distros without any -rc stages which were useful in the past IIRC. And distro maintainers who are building with that new "great improved" API are surely facing the issues with plenty other software already so OpenOCD wouldn't be anything special. We can probably tag 0.12.1 for their convenience, that's
<PaulFertser>
not risky in any way I guess.
gzlb has quit [Ping timeout: 260 seconds]
gzlb has joined #openocd
<borneoa___>
bero: to save time for either you and maintainers, please send the patches one by one (don't wait to have the whole series ready). And maybe even communicate in advance on the mailing list that you are squashing the patches for feature XYZ, maybe listing the main patches you are taking in
<borneoa___>
PaulFertser: yes, 0.12.1 should be appropriate. Let's check if there is anything else that could be interesting to be part of it. I don't remember any other important fix