OpenOCD (und gdb): Runtime Error in procedure 'script'. Can't find openocd.cfg

[Benny B. (lpla)]

Hallo,

ich stehe gerade vor einem Problem mit OpenOCD (und gdb) und hoffe, dass 
mir jemand dabei behilflich sein kann.
Im Grunde geht es um folgendes (muss ein wenig ausholen): Ich habe mit 
der Portierung der PULPissimo Platform auf ein FPGA (ZedBoard) 
angefangen. Zu finden hier: https://github.com/pulp-platform/pulpissimo

Dabei habe ich die dortige Anleitung befolgt um es auf dem ZedBoard 
laufen zu lassen. Zur Kommunikation nutze ich das FT2232H Mini Module: 
https://www.ftdichip.com/Support/Documents/DataSheets/Modules/DS_FT2232H_Mini_Module.pdf

So weit so gut. Jetzt haben wir Änderungen an dem Core vorgenommen (und 
am SDK, aber das sollte hierfür nicht relevant sein) und alles durch 
RTL-Simulation getestet. Läuft alles super, Simulation, Synthese, etc.
Ich habe dann den Bitstream erzeugt und auf das Zedboard geladen. Dann 
in Vivado geschaut ob auch alles drauf ist und sieht auch gut aus 
soweit.

Wenn ich nun aber OpenOCD nutzen möchte, dann sieht es leider nicht mehr 
so gut aus. Der Core wird zwar scheinbar gefunden:

   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 riscv.unknown0         Y     0x00000000 0x10102001     5 0x01  0x03
 1 riscv.cpu              Y     0x00000000 0x249511c3     5 0x01  0x03
Info : clock speed 1000 kHz
Info : JTAG tap: riscv.unknown0 tap/device found: 0x10102001 (mfg: 0x000 (<invalid>), part: 0x0102, ver: 0x1)
Info : JTAG tap: riscv.cpu tap/device found: 0x249511c3 (mfg: 0x0e1 (Wintec Industries), part: 0x4951, ver: 0x2)
Info : datacount=2 progbufsize=8
Info : Examined RISC-V core; found 1024 harts

aber am Ende bekomme ich folgende Errors:

Error: Timed out after 120s waiting for busy to go low (abstractcs=0x8001002). Increase the timeout with riscv set_command_timeout_sec.
Error: Abstract command ended in error 'busy' (abstractcs=0x8001102)
Error: Timed out after 120s waiting for busy to go low (abstractcs=0x8001102). Increase the timeout with riscv set_command_timeout_sec.
Info : Listening on port 3333 for gdb connections
Ready for Remote Connections
Info : Listening on port 6666 for tcl connections
Info : Listening on port 4444 for telnet connections

Es scheint zwar eine Verbindung für die gdb Connections auf Port 3333 
hergestellt zu werden (was auch richtig ist), aber wenn ich gdb starte 
zum debuggen und auf Port 3333 verbinde, kommen auch hier wieder einige 
Errors:

Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Ignoring packet error, continuing...
Remote 'g' packet reply is of odd length: E0E

und wenn ich dann mein elf-File laden möchte:

(gdb) load
You can't do that when your target is `exec'

Dann habe ich mal über "openocd -d" geschaut ob ich was rausfinden kann. 
Das liefert mir folgendes:

Open On-Chip Debugger 0.8.0 (2014-04-29-12:22)
Licensed under GNU GPL v2
For bug reports, read
  http://openocd.sourceforge.net/doc/doxygen/bugs.html
User : 13 2 command.c:546 command_print(): debug_level: 3
Debug: 14 2 options.c:98 add_default_dirs(): bindir=/usr/bin
Debug: 15 2 options.c:99 add_default_dirs(): pkgdatadir=/usr/share/openocd
Debug: 16 2 options.c:100 add_default_dirs(): run_prefix=
Debug: 17 2 configuration.c:44 add_script_search_dir(): adding /home/basler/.openocd
Debug: 18 2 configuration.c:44 add_script_search_dir(): adding /usr/share/openocd/site
Debug: 19 2 configuration.c:44 add_script_search_dir(): adding /usr/share/openocd/scripts
User : 20 2 command.c:666 command_run_line(): Runtime Error: embedded:startup.tcl:58: Can't find openocd.cfg
in procedure 'script' 
at file "embedded:startup.tcl", line 58
Error: 21 2 server.c:238 add_service(): couldn't bind to socket: Address already in use

Jetzt bin ich ziemlich verwirrt. Wie gesagt habe ich zuerst das 
PULPissimo auf das ZedBoard portiert und bin der Anleitung aus GitHub 
gefolgt. Hat alles funktioniert und weder OpenOCD noch gdb haben 
(solche) Probleme gemacht.
Eigentlich würde ich ja nicht vermuten das es am anderen Core liegt, da 
dieser wie gesagt ausgiebig getestet wurde. Ich habe auch alle Skripte 
angepasst und den Bitstream erfolgreich auf das ZedBoard geladen und in 
Vivado geschaut ob alles passt. Da bisher auch alles ohne größere 
Komplikationen funktioniert hat, habe ich dementsprechend wenig Ahnung 
von Fehlerbehebung bei OpenOCD und gdb (falls es daran liegen sollte) 
und habe beides quasi "blind" benutzt und mich nicht auf die Suche nach 
möglichen Fehlern gemacht... ich meine wer macht das schon bei Dingen 
die funktionieren? ;)

Darum meine Frage: Hat jemand eine Idee, wieso es mit dem ursprünglichen 
PULPissimo ging, jedoch OpenOCD und gdb mit dem anderen Core diese 
Errors werfen? Ich habe weder an OpenOCD, noch an gdb etwas geändert. 
Wenn es wirklich daran liegt das irgendwelche configs fehlen, wieso war 
das vorher kein Problem?

Ich werde versuchen mithilfe des OpenOCD User's Guide 
(http://openocd.org/doc-release/html/index.html) zu schauen ob ich das 
gefixt bekomme, vor allem das mit dem config File.

Falls jemand mal ein ähnliches Problem hatte oder eine Vermutung hat 
woran es liegen könnte, wäre ich für Informationen sehr dankbar.

MfG
LPLA

[Jim M. (turboj)]

> Open On-Chip Debugger 0.8.0 (2014-04-29-12:22)

Mal auf den Kalender geschaut? Wir haben das Jahr 2020.

OpenOCD und GDB müssen sich einig über das Format des "g" Packets sein, 
sonst funktioniert das nicht. Probiere mal eine moderne Version von 
OpenOCD.

> Dann habe ich mal über "openocd -d" geschaut

Die vollen Logs bekommt man via "-d3". Und man bracht auch den 
Rattenschwanz der restlichen Parameter, damit OpenOCD korrekt 
konfiguriert wird.

[Moot S. (mootseeker)]

Versuchs mal mit GDB. Hatte auch probleme mit OpenOCD (neuste Version).

[Benny B. (lpla)]

Was mich halt wundert ist einfach, dass es ja bisher immer ging, auch 
mit dieser doch recht alten Version von OpenOCD (welche laut yum aber 
die aktuellste ist...). Kann mir halt nicht so ganz vorstellen, dass es 
am Core liegen könnte, da es sonst höchstwahrscheinlich schon bei der 
RTL-Simulation und der Synthese Probleme hätte geben sollen.

Habe es jetzt auch mal mit einer neueren Version von OpenOCD versucht 
(0.10.0 Stand 24.08.2020) aber jetzt findet er mein ftdi device nicht.
Neustart versucht, aus- und wieder eingesteckt versucht, lsusb zeigt mir 
das Modul mit genauer dieser vid und pid an nach der gesucht wird... hab 
schon die description geändert um zu sehen ob es daran lag, aber leider 
ohne Erfolg.
Sobald ich weiter komme werde ich hier ein update posten.