cyrozap has quit [Remote host closed the connection]
akaWolf has quit [Ping timeout: 256 seconds]
hanetzer has quit [Ping timeout: 248 seconds]
akaWolf has joined #openocd
hanetzer has joined #openocd
<hanetzer>
so, is there some mapping between the romtable (as given by dap info) and what one 'should' plop in the cfg file for the target?
Hawk777 has joined #openocd
zjason` has joined #openocd
zjason has quit [Ping timeout: 248 seconds]
f00b4r_ has quit [Ping timeout: 255 seconds]
f00b4r_ has joined #openocd
Haohmaru has joined #openocd
uartist has quit [Quit: Ping timeout (120 seconds)]
uartist has joined #openocd
Hawk777 has quit [Quit: Leaving.]
nerozero has joined #openocd
indy has quit [Ping timeout: 252 seconds]
indy has joined #openocd
<borneoa_>
zapb__: it builds on arch Linux, with the message '+: command not found'. Ok. In configure.ac the wrong line is expanded as a single '+' in case of autoconf >=2.70, which is my case. Have you checked what happens with older autoconf? I suspect that the line gets expanded as multiple lines with the first triggering error for the '+' and getting ignored, while the other having no more any sense without the first one
<borneoa_>
zapb__: yes, replicated on Ubuntu 20 with autoconf 2.69. The line is expanded with first line starting as '+ {' that gives error and is ignored. The second line is continuation of the first and ends with '}' and this alone triggers error. Of course, the other lines of the same expansion are not executed.
<borneoa_>
zapb__: so libjaylink 0.3.0 has a regression with Autoconf<=2.69
<karlp>
still failing to auto anything, after 40 years.
<Haohmaru>
but at least it's automatic
<PaulFertser>
I can't see how cmake is any better or easier to debug when issues surface, its custom silly langugage isn't helping much.
<karlp>
I didnt' say anything about cmake.
* Haohmaru
is innocent too
<karlp>
also sorry, only 30 years, guess I can't complain for another 10 years.
<Haohmaru>
in 10 years, the chip shortage would have ended ;P~
<Haohmaru>
(maybe)
<Haohmaru>
hm, i wonder if the current situation makes my stlink3 valuable.. it had some chunky stm32 cortex M7 on it
<Haohmaru>
but i think it was BGA
<PaulFertser>
So what's hot these days, Meson? But it's clearly optimised for another usecase
<Haohmaru>
PaulFertser in #C++-general i often hear cmake, meson, ninja, and a few others
<Haohmaru>
no clue about any of them, since i still use my IDE to build my own sh*t
<Haohmaru>
there is no consensus, they kinda say that none of them are ideal
<Haohmaru>
that's my impression
<karlp>
I'd say hand written makefiles would probably be sufficient. you don't need to care about obscure unices.
<karlp>
I know it's not happening after the fact, but damn, the amount of pain that autohell _still_ inflicts is just absolutely bonkers.
<PaulFertser>
autoconf makes it easy to compile openocd for windows
<Haohmaru>
who even uses.. ;P~
<PaulFertser>
Also, with autoconf you're dealing with regular POSIX shell scripts, so you do not need to learn a new language to understand the issues when they happen.
<milkylainen>
autotools might be dysfunctional, but nothing else solved anything any better.
* karlp
coughs
<karlp>
as long as you define the problem space to include building for sunos 5.2
merethan has quit [Remote host closed the connection]
merethan has joined #openocd
zjason` is now known as zjason
Haohmaru has quit []
merethan has quit [Remote host closed the connection]
merethan has joined #openocd
merethan has quit [Remote host closed the connection]
merethan has joined #openocd
<hanetzer>
https://brpaste.xyz/b01LUQ is there any particularly useful info in doing `chip.dap info`? some configs use cti in their target declarations but apparently that's aarch64 only atm
<PaulFertser>
hanetzer: if ROM DAP table is sane it can be used to auto-detect dbgbase for cortex-a cores.
<zapb__>
borneoa_, PaulFertser: thanks for testing! I'll release 0.3.1 and fix the issue
<borneoa_>
hanetzer: aarch64 requires the CTI to halt the cores, so it's mandatory using it for debug. But CTI is also useful to halt N cores in sync. In STM32MP15 it can be used to sync cortex-m and cortex-a. Also STM32H7 uses CTI to sync two cortex-m.
<borneoa_>
zapb__: you are welcome
<hanetzer>
so. I have two targets (cpu cores); do I need to wire up reset events for both, or am I missing something? in theory (and practice, tested using u-boot's mw command) writing *anything* to 0x12020004 resets the soc
<PaulFertser>
I think adding reset handling for the very first target is enough.
<hanetzer>
and what about work-area stuff?
<PaulFertser>
(we're discussing a case when SRST can't be connected physically)
<hanetzer>
yeah. its muxed with an emmc reset signal and I can't 'get at it'
<PaulFertser>
I'm not sure how working areas are normally used on cortex-a targets.
<PaulFertser>
If you plan to use verify_image you'll need working area on the "current" target.
<hanetzer>
something like this: `${_TARGETNAME}0 configure -event reset-assert "${_TARGETNAME}0 mww 0x12020004 0xdeadbeef"` should work, right?
<hanetzer>
if I only define for cpu0, then cpu1 asks 'how to reset'
<PaulFertser>
Sorry, I do not know for sure, probably cpu1 needs an empty handler then.
<hanetzer>
so same hting but "" instead of the mww stuff yeh?
<hanetzer>
(this is all working against a machine with u-boot installed and who's bootcmd is 'true' so it doesn't keep booting and go to linux; atm I'm without access to serial due to hw failure and a stupid debug header)
<PaulFertser>
hanetzer: that's why the example had "catch" around that mww.
<PaulFertser>
reset halt can be problematic, certain devices really reset internal debug state too :/
<hanetzer>
which example, again? sorry, a bit brain frazzled being 'this close' to being able to work
_whitelogger has joined #openocd
<hanetzer>
beh. so frustrating :/
<hanetzer>
especially since most every aspect 'works' for the most part aside from this lmao
<PaulFertser>
So with the catch it shouldn't stop on an exception there.
<hanetzer>
putting aside resets. any idea why attempting to halt the second cpu/target would result in 'timeout waiting for DSCR bit change' ?
<hanetzer>
cpu0 has no issue for the most part.
<PaulFertser>
You need to wait for someone who really worked with cortex-a. I think I never did :)
<PaulFertser>
Probably the second core isn't powered on/started at the moment you're trying to halt it? To be able to halt you need to let it run first.
<hanetzer>
hrm.
<hanetzer>
I wonder if its possible to have openocd send a 'reset' command to u-boot over serial, and if that'd help at all lulz
<PaulFertser>
You didn't show the log of reset attempt with catch wrapping the mww command.
<PaulFertser>
But I need to sleep now, see you tomorrow.
emeb has joined #openocd
<hanetzer>
PaulFertser: same result, sorry. and have a good rest :)
zjason has quit [Read error: Connection reset by peer]