xorbital has quit [Remote host closed the connection]
vampirefrog has joined #openocd
nerozero has joined #openocd
MGF_Fabio has joined #openocd
joconor has quit [Ping timeout: 268 seconds]
vampirefrog has quit [Quit: Leaving]
vampirefrog has joined #openocd
Haohmaru has joined #openocd
Hawk777 has quit [Quit: Leaving.]
<Haohmaru>
so i butchered the openocd code and built it, i got "cmsis_dap_init_samd_cold_plug" now but i still get a -4 result on the chip-erase command
<Haohmaru>
i did have to improvise a bit since the changes couldn't be exactly placed in the current openocd code
<PaulFertser>
Does that cold plug actually results in the target halting?
<Haohmaru>
yes
<Haohmaru>
i also see the debug info printed from the new command
<PaulFertser>
Haohmaru: ok, so what if you try to do arp_examine right after that?
<Haohmaru>
is that a command?
<PaulFertser>
Like "$_TARGETNAME arp_examine"
* Haohmaru
scratches head
<Haohmaru>
where's that supposed to go?
<PaulFertser>
Haohmaru: after executing samd_cold_plug
<Haohmaru>
is that $ thing supposed to be atsame5?
<PaulFertser>
Haohmaru: that $ thing is supposed to expand to a Tcl variable defined in your target config.
<Haohmaru>
User : 60 2 command.c:601 command_run_line(): invalid command name "arp_examine"
<PaulFertser>
Haohmaru: you didn't pass $_TARGETNAME to the interpreter?
<Haohmaru>
^ this is the command from the sourceforge page from yesterday
<Haohmaru>
so "init" should be before the cold_plug?
<PaulFertser>
Haohmaru: I would expect it to. But probably you do need arp_examine after it and before chip-erase.
<Haohmaru>
my "shell" i guess you mean my terminal.. is lxterminal from LXDE
<Haohmaru>
right, i forgot... the "cold_plug" command gives an error and says it has to be ran *before* "init"
<Haohmaru>
altho i don't think i saw this message in the code i "transplanted" so this error message must be from openocd originally, not from this specific modification
<PaulFertser>
OK, so do it before init.
<PaulFertser>
By shell I mean command interpreter
<PaulFertser>
Not your terminal emulator of course.
<Haohmaru>
then i have no clue
<PaulFertser>
And again, you're not showing logs...
bvernoux has joined #openocd
<Haohmaru>
i guess it has to be single-quotes, then it turns into atsame5.cpu or something
<PaulFertser>
If you're using something POSIX-shell compatible, yes.
<PaulFertser>
Haohmaru: I think if you just need to unlock it, get a version that was current back then when that discussion took place. Probably something changed regarding dap/mem-ap access etc.
<Haohmaru>
hm
<PaulFertser>
Probably examination used to ignore that access. Probably the chip-erase command ignored whether it's examined or not.
<Haohmaru>
so an openocd version from 2017-ish you say
<Haohmaru>
0.10.0 ?
<PaulFertser>
Probably
<PaulFertser>
If I had that board before me I'd just read the datasheet carefully and would fix in the current HEAD whatever needs to be fixed...
<Haohmaru>
if i was a magician.. ;P~
<Haohmaru>
v0.10.0 ./configure says it doesn't have jimtcl
<Haohmaru>
oh wait, my fault
<Haohmaru>
low coffee levels
<Haohmaru>
hm, no actually, i copied the jimtcl source files into the empty jimtcl folder... just like i did for the $current version openocd yesterday
<Haohmaru>
maybe it's a too new version
<Haohmaru>
okay i guess it has to be v0.77
<Haohmaru>
do i need libjaylink?
<Haohmaru>
is that for $segger debuggers
<Haohmaru>
okay, it's compiling... but now i think the problem is building an old source code with a too new compiler x_x
<Haohmaru>
bluh
<Haohmaru>
okay, i'll butcher it after some coffee
<Haohmaru>
"-Werror" such much fun
<karlp>
./configure --no-werror iirc.
<PaulFertser>
Or probably --disable-werror yes
<PaulFertser>
Also, you're not supposed to copy jimtcl, use git submodules...
<karlp>
and yeah, werror should never be in release builds IMO.
<karlp>
but can't change history
<PaulFertser>
It's not in release _builds_ :)
<PaulFertser>
But you mean default in tarballs
<PaulFertser>
Guess I agree, yes.
<karlp>
I'm fine with it being on by default in CI and git builds, but yeah, werror in release bundles is just anti-consumer.
<PaulFertser>
Probably configure should detect if it's running not from a git repo and then disable it.
<karlp>
many ways I would guess, I dont't touch autohell if I can help it though :)
<Haohmaru>
i don't schprachen ze git.. i just used the "Download .zip" from M$github and then extract the stuff and copy/paste the files...
<Haohmaru>
okay it's building with --disable-werror
<PaulFertser>
git is one of the few things I have always been happy with, the only regret is that I didn't learn it earlier
<Haohmaru>
i do use it a little bit but only via "git gui" and only for one of 3 very basic tasks which i've learned which buttons to press
<Haohmaru>
any improvisation or wrong move and i'm stuck and i have to /join #git or throw everything out in rage
<Haohmaru>
once i submitted a theme to kicad, it involved git... after i succeeded i had grown beard on my beard, and i don't feel like repeating that process even tho i have a wonderful new theme
<Haohmaru>
i'd rather splosh it on my website with instructions
<Haohmaru>
it compiled
<Haohmaru>
no atsame5x.cfg >:/
<Haohmaru>
i guess it's not merely the .cfg
<Haohmaru>
what if...
<Haohmaru>
i tell it it's a samd2x and just do the "cold_plug" and then "mwb <address_of_DSU_register> <value_for_chip_erase>" ?
<Haohmaru>
could that fool openocd to do the right thing?
<PaulFertser>
Haohmaru: ou probably can just try samd5 instead for this chip-erase, it's essentially the same.
<Haohmaru>
samd5?
<Haohmaru>
my actual chip *is* samd51
<PaulFertser>
Haohmaru: not e5?
<Haohmaru>
but it's part of the E5x/D5x so it's a cortex-M4F
<Haohmaru>
samd2x is M0+
<PaulFertser>
Haohmaru: ah ok
<PaulFertser>
Haohmaru: yeah, you can manually mww to 0x40000000 this value, (1<<16) | (1<<5) | (1<<1), then to 0x41002100 (1<<4)
<PaulFertser>
Haohmaru: the last should be "mwb", not w
<Haohmaru>
hm, what's the first one for?
<PaulFertser>
/* Enable access to the DSU by disabling the write protect bit */
<Haohmaru>
oh
<Haohmaru>
for the DSU chip-erase i was doing "mwb 0x41002000 0x10"
<PaulFertser>
Haohmaru: writing to 0x40000000 is expected to fail according to the comments
<PaulFertser>
/* intentionally without error checking - not accessible on secured chip */
<Haohmaru>
yeah, so is there a version of the "mww" command which can ignore the errors? ;P~
<PaulFertser>
What happened later? Your log is incomplete
<Haohmaru>
it stops there
<karlp>
it ran your command, it reported the error, end of story?
<karlp>
just ignore it if you want.
<Haohmaru>
oh wtf
<Haohmaru>
it goes up to 527, did debian truncate my paste?
<Haohmaru>
well, Error: 525 224 arm_adi_v5.c:378 mem_ap_write(): Failed to write memory at 0x40000000
<Haohmaru>
and result -4
<Haohmaru>
it doesn't try the "mwb" command at all
<PaulFertser>
Probably try it on the next run then
<Haohmaru>
oh
<Haohmaru>
now openocd remains connected, and periodically spews out some stuff (waiting for gdb i think?)
<Haohmaru>
ooh, i think it might have gotten erased now
<Haohmaru>
yeah, no LEDs blink after POR
<Haohmaru>
muchos thanks PaulFertser
<PaulFertser>
Haohmaru: great to hear
<Haohmaru>
evil security bit
<Haohmaru>
i guess that's good ;P~
<Haohmaru>
i guess the DSU can't be used from the firmware itself, i tried DSU.CTRL.bit.CE = 1; yesterday but it didn't seem to do anything
<Haohmaru>
altho if the PAC thing is required - i didn't have that
zkrx has quit [Ping timeout: 256 seconds]
zkrx has joined #openocd
<Haohmaru>
how can i help to get this working in the current version?
<karlp>
redo the steps now that you have the steps all worked out, see where it fails again.
<Haohmaru>
the worked out steps were to... use an older version of openocd (which doesn't have same5x support) and fool it that i'm using samd2x and then (with the cold_plug modification) manually poke the two registers needed for chip-erase
<Haohmaru>
the current version with the (butchered to compile) "cold_plug" modifications fails with -4 on the chip-erase command
<Haohmaru>
i guess either something in openocd has changed since v0.10.0 which makes the "cold_plug" mod not work, or my butchering broke it
<Haohmaru>
(huh, or both)
<Haohmaru>
at least it seems the firmware can erase the chip, the PAC thing was needed
<Haohmaru>
but i guess that won't help if you cannot change the firmware via the debugger on a "locked" chip
<Haohmaru>
shouldn't the RESET be left low after this?
Foxyloxy_ has joined #openocd
Foxyloxy has quit [Ping timeout: 252 seconds]
merethan has joined #openocd
<Haohmaru>
hm, i managed to erase the chip with the butchered current openocd, but no idea wtf's going on
<karlp>
fucking 5000 khz jtag is slower than 921600 serial for flashing esp32.
<karlp>
10M jtag only works 70% of the time :|
<Haohmaru>
is that a bootloader thing?
<Haohmaru>
doesn't the esp32 have some proper "programming" port or is it still drowned in layers of silly bootloaders like the previous ones?
<karlp>
jtag is slower than their rom bootloader, is my complaint.
<Haohmaru>
oh
<Haohmaru>
i can't reproduce the success
<Haohmaru>
the first invocation caused openocd to "loop" spewing out data... i ctrl+C'd it, then repeated the command and this was the (successiful) output: https://paste.debian.net/hidden/1b5d5b5a/
<Haohmaru>
an interesting little thing i saw there is this: Debug: 134 155 cortex_m.c:2637 cortex_m_examine(): [atsame5.cpu] reset happened some time ago, ignore
<Haohmaru>
i don't think i've seen this one before
bvernoux has quit [Quit: Leaving]
Haohmaru has quit [Quit: saionara]
MGF_Fabio has quit [Ping timeout: 255 seconds]
<zapb_>
What is the difference between '--enable-verbose-usb-io' and '--enable-verbose-usb-comms' ? Except that the former is not used at all?
<zapb_>
borneoa___, any idea?
<PaulFertser>
zapb_: hey! Still no idea what happened to the server back then. I didn't have a session to see all serial output running at that moment and there was nothing obviously wrong (other than old OOM messages) on VNC screen either. So I just rebooted it...
merethan has quit [Ping timeout: 268 seconds]
<borneoa___>
zapb_: no idea. Maybe it was used by the old zy1000 driver and we have no use anymore
<zapb_>
borneoa___, looks like they have the same intention, right? I would drop it then
<zapb_>
PaulFertser, okay, strange. Thanks for your support anyway!
nerozero has quit [Ping timeout: 252 seconds]
slobodan has joined #openocd
vampirefrog has quit [Remote host closed the connection]
geep has quit [Read error: Connection reset by peer]
bryanb has quit [Read error: Connection reset by peer]
lh has quit [Read error: Connection reset by peer]
bryanb has joined #openocd
mawk` has joined #openocd
drath42_ has joined #openocd
lh has joined #openocd
dreamcat4 has quit [Read error: Connection reset by peer]
mawk has quit [Ping timeout: 256 seconds]
youthpastor has quit [Read error: Connection reset by peer]
drath42 has quit [Ping timeout: 256 seconds]
drath42_ is now known as drath42
shoragan_ has joined #openocd
shoragan has quit [Ping timeout: 256 seconds]
olerem has quit [Ping timeout: 256 seconds]
dnm_ has joined #openocd
youthpastor has joined #openocd
dnm has quit [Read error: Connection reset by peer]
dnm_ is now known as dnm
haxar has quit [Ping timeout: 246 seconds]
a3f has quit [Remote host closed the connection]
dreamcat4 has joined #openocd
vampirefrog has joined #openocd
mawk` is now known as mawk
a3f has joined #openocd
geep has joined #openocd
gzlb has quit [Ping timeout: 268 seconds]
HelloShitty has quit [Ping timeout: 268 seconds]
HelloShitty has joined #openocd
gzlb has joined #openocd
olerem has joined #openocd
haxar has joined #openocd
slobodan has quit [Ping timeout: 268 seconds]
dan922 has joined #openocd
<dan922>
Hello
<dan922>
I'm trying to have some low level interaction with a RiscV device with debug extensions. I would like to control the dtm via the jtag state machine to read the idcode register's value. Could someone tell me what's the right tms and tdi sequence for this?
<PaulFertser>
dan922: hi!
<PaulFertser>
dan922: for jtag level commands you have irscan and drscan
<PaulFertser>
dan922: you do not need to know about how they translate into tms and tdi
<PaulFertser>
Proper JTAG state machine is implemented in OpenOCD already.
<dan922>
Yeah, but the thing is that the hardware I'm using is not really supported by openocd. Could you give me code pointers for the irscan command?
<PaulFertser>
dan922: you just start OpenOCD without telling the target, just define the JTAG tap (or even just rely on autodetection).
<PaulFertser>
Then you'll have irscan command available in telnet.
<dan922>
How does this telnet connection work? I guess I can just create a service which relays and dumps the commands to a specific riscv core on the card that I work with.
<PaulFertser>
dan922: telnet to OpenOCD? It just works over a TCP socket.
<PaulFertser>
Just so that you can have interactive session with it.
<dan922>
Aha. I'm really more after the JTAG interaction with the dtm. Since I can't connect openocd to the card that I work with, an interactive session won't help.
<PaulFertser>
dan922: do you have a physical JTAG connection or not?
<dan922>
I don't, I have an array of RiscV cores accessible on an AXI bus and the JTAGs are behind a custom IP which translates the AXI bus messages to tms/tdi inputs.
<dan922>
Also the AXI bus is accessible from a pcie bar mapping.
<dan922>
The translation I can do for this, but I need a sequence of tms/tdi to be able to do the translation.
<dan922>
I guess it also works if I connect to something more simple like an esp32-c3 and dump the command that's getting emitted when I try to get the idcode.
<PaulFertser>
dan922: ah ok that makes it clearer
<PaulFertser>
dan922: openocd has remote-bitbang driver
<PaulFertser>
dan922: so guess you can extend OpenOCD to support that AXI bus messages to remote bitbang protocol and then run other OpenOCD instance against it.
<PaulFertser>
Or if you just need the sequence you can just run OpenOCD with remote bitbang against "netcat" TCP server to just see the sequence.