Hallo zusammen,
kennt sich jemand mit GCC M68k aus? Weil ich von Linux überhaupt
keine Ahnung habe, habe ich versucht, alles 1:1 aus dem Artikel
nachzubauen. Inkl. der dort angegebenen Versionen von OpenSuse, GDB usw.
Das war für mich zwar nicht ganz einfach, aber dank Google hat es
einigermaßen geklappt. Allerdings komme ich mit Google bei meinem
momentanen Problem nicht weiter!
Ich bekomme einfach keine Verbindung zwischen GDB und meinem Target.
Sobald ich versuche, wie in der Anleitung beschrieben, eine Verbindung
aufzubauen, passiert Folgendes:
1
(gdb) targ rem | m68k-bdm-gdbserver pipe /dev/bdmicd0
2
Remote debugging using | m68k-bdm-gdbserver pipe /dev/bdmicd0
3
trying kernel driver: /dev/bdmicd0
4
m68k-bdm: architecture CPU32 connected to /dev/bdmicd0
5
Process /dev/bdmicd0 created; pid = 0
6
Ignoring packet error, continuing...
7
warning: unrecognized item "timeout" in "qSupported" response
8
Ignoring packet error, continuing...
9
Ignoring packet error, continuing...
10
Ignoring packet error, continuing...
11
Ignoring packet error, continuing...
12
Ignoring packet error, continuing...
13
warning: Invalid remote reply: timeout
In der im Artikel verlinkten Sammlung ist extra ein Prüfprogramm
enthalten (bdm-cpu32-chk). Wenn ich das ausführe, werden die Register,
der Speicher usw. getestet - alles ist einwandfrei. Ich schließe daraus,
dass die Hardware-Verbindung an sich funktioniert. Nur will GDB trotzdem
nicht!
Könnt ihr mir weiterhelfen? Hoffentlich habt ihr eine Idee...
Grüße
Steffen
P.s.: Ich verwende einen M68336 statt des im Artikel angegebenen
MC68332. Ich habe aber nichts gefunden, dass spezifisch auf diesen
Prozessor angepasst wurde. Auch nicht im Patch.
Nachtrag: Anders als im Artikel arbeite ich mit OpenSuse 32 bit. Und -
womöglich auch nicht ganz unwichtig - ich bin in einer virtuellen
Maschine unterwegs. Der Zugriff auf meinen Zielprozessor funktioniert
prinzipiell aber aus meiner VM heraus (siehe Eröffnungsbeitrag)!
der im Artikel verlinkte BDM code ist uralt (die Entwickler scheinen die
Dateidownloads schon lange nicht mehr auf Stand zu halten).
Hol' dir die BDM Tools direkt aus dem entsprechenden git Repository:
https://sourceforge.net/p/bdm/code/ci/master/tree
Das funktioniert bei mir (weitgehend) problemlos. Zumindest für ColdFire
BDM.
Ich hatte gehofft, wenn ich alles 1:1 nachbaue, würde es
funktionieren...
Danke für Deinen Link und den Hinweis, ich werde das heute Abend
ausprobieren!
-> Prima, autoconf läuft durch! Nur leider existiert weiterhin keine
Datei namens "Configure" :-(
Versuch 3 - Erneut "Autoconf" aufrufen - aber diesmal ohne Parameter
Ich komme hier vom Hundertsten ins Tausendste. Ich möchte doch
eigentlich etwas ganz anderes, nämlich nur die BDM Tools installieren.
Muss man bei Linux studiert haben, um ein Programm zu bauen?
Na egal. Was muss ich denn machen, damit ich die BDM Tools gebaut
bekomme? Es gibt eine Datei namens "Makefile.am". Ist sie der Schlüssel?
Steffen H. schrieb:> Muss man bei Linux studiert haben, um ein Programm zu bauen?
Ähem. Studiert zu haben ist natürlich grundsätzlich kein Fehler, aber
hier - mit Verlaub - reicht es völlig, wenn man lesen (und verstehen)
kann ;).
Das ist uralte, (wahrscheinlich) nicht mehr gepflegte Software, trotzdem
funktioniert sie noch recht gut. Die Entwickler haben sich sogar die
Mühe gemacht, ein vernünftiges README (das ist wörtlich zu nehmen)
dazuzulegen und da steht folgendes drin:
1
If working from a git checkout you need to bootstrap:
2
3
$ cd bdm/m68k
4
$ config/bootstrap
5
$ cd ../..
6
$ mkdir build
7
$ cd build
8
$ ../bdm/m68k/configure
9
$ make
10
$ make install
Wenn man sich daran hält, dann funktioniert das auch ohne Studium ;)
Ach so, ich hab so ein "Git Checkout"? In der Anleitung aus dem Artikel
M68k GCC hatte ich von der selben Seite heruntergeladen und da hatte
ja alles gleich geklappt. Ich dachte, ich würde jetzt das Gleiche tun...
Puh, mit dem Tipp von Markus hat es jedenfalls funktioniert. Vielen
Dank!
Leider bekomme ich auch mit der neuen Version der BDM-Tools weiterhin
die Fehlermeldung aus meinem Eröffnungspost:
1
(gdb) targ rem | m68k-bdm-gdbserver pipe /dev/bdmicd0
2
Remote debugging using | m68k-bdm-gdbserver pipe /dev/bdmicd0
3
trying kernel driver: /dev/bdmicd0
4
m68k-bdm: architecture CPU32 connected to /dev/bdmicd0
5
Process /dev/bdmicd0 created; pid = 0
6
Ignoring packet error, continuing...
7
warning: unrecognized item "timeout" in "qSupported" response
8
Ignoring packet error, continuing...
9
Ignoring packet error, continuing...
10
Ignoring packet error, continuing...
11
Ignoring packet error, continuing...
12
Ignoring packet error, continuing...
13
warning: Invalid remote reply: timeout
Wenn ich den gdbserver von der Kommandozeile aufrufe, passiert auch
nichts:
m68k-bdm: architecture CPU32 connected to /dev/bdmicd0
4
Process /dev/bdmicd0 created; pid = 0
Kann ich den gdbserver irgendwie testen? Also beispielsweise einzelne
Kommandos an mein Target senden und seine Antwort empfangen? Die
Hardware-Verbindung funktioniert ja prinzipiell, da "bdm-cpu32-chk
/dev/bdmicd0" sauber durchläuft.
Oder muss ich da noch irgendwas konfigurieren? Ich habe ja bspw.
nirgends mein Prozessor-Derivat angegeben (nur allgemein "CPU32"). Oder
irgendwelche Timing-Parameter.
Markus F. schrieb:> wo hängt denn dein BDM dran? Parallelport?
Ja genau. Und mein Interface ist das ICD (mit dem GAL). BD32
funktioniert damit übrigens auch.
Der -t Parameter hat mir leider nicht weitergeholfen. Ich probiere jetzt
seit gestern Abend rum, komme aber nicht weiter. Ich hab alles vor- und
rückwärts ausprobiert. Es ist wirklich zum verzweifeln.
Es gibt in den BDM Tools ja auch noch das Unterverzeichnis "M683xx", das
scheinbar noch besser mit der CPU32 funktionieren soll. Um das zu
verwenden, muss man sich aber scheinbar mit Unix noch besser auskennen.
Ich bekomme die Installation jedenfalls nicht hin :-(
Eine Idee habe ich noch: In den alten Anleitungen steht, dass GDB
gepatcht werden muss. Im Artikel M68k GCC steht davon aber nichts
mehr (und in einer der unzähligen READMEs, die ich mittlerweile gelesen
habe, stand auch etwas in der Richtung, dass das nicht mehr notwendig
sei).
Kannst Du (oder jemand anderes) das bestätigen?
Steffen H. schrieb:> Kannst Du (oder jemand anderes) das bestätigen?
Da kann ich leider nicht weiterhelfen. Ich benutze BDM nur mit
ColdFire-Boards und da gibt's das Problem nicht.
Hallo Stefan,
lese mal ...
Beitrag "Re: Motorola MC68332 und BD32"
Da wird der BDM Mode ein wenig genauer beschrieben. Erfüllt deine
Schaltung diese Anforderungen ?
Hast Du schon ein Programm auf den Controller geladen ? oder ist der
noch "jungfräulich" ;)
Hmmm, mit der Konfiguration habe ich vor ca. 15 Jahren mal schaffen
müssen... wenn ich es recht erinnere, ist es beim BDM über Parallel
elementar wichtig, den Parallelen Porttreiber richtig zu konfigurieren
(also ob EPP etc). Wie man das unter Linux macht, weiss ich nicht,
damals unter Windows mußte ich das in der BIOS Konfiguration verbiegen.
Das BDM Interface war damals extrem fehleranfällig und empfindlich, es
wollte nur in ganz bestimmten Konfigurationen laufen (bei der VM tippe
ich mal auf heftige Virtualisierungsprobleme).
Good luck!
G. S. schrieb:> Da wird der BDM Mode ein wenig genauer beschrieben. Erfüllt deine> Schaltung diese Anforderungen ?
Ja, auf der Hardware-Seite passt es. Ich bekomme mit BD32 eine
Verbindung und kann damit Register auslesen und auch debuggen. Alles
funktioniert.
Auch mit den BDM Tools kann ich prinzipiell auf die Hardware zugreifen:
es gibt extra ein Testprogramm namens "bdm-cpu32-chk", welches genau das
prüft. Es funktioniert bei mir einwandfrei.
G. S. schrieb:> Hast Du schon ein Programm auf den Controller geladen ? oder ist der> noch "jungfräulich" ;)
Es ist bereits ein Programm geladen (externer ROM).
geezer schrieb:> Das BDM Interface war damals extrem fehleranfällig und empfindlich, es> wollte nur in ganz bestimmten Konfigurationen laufen (bei der VM tippe> ich mal auf heftige Virtualisierungsprobleme).
Ja, das kann ich bestätigen. Ich habe erst mit dem public-domain Nachbau
begonnen und bin dann zum ICD gewechselt. Vor Kurzem habe ich mir nun
einen Pentium-I gekauft und Windows 95 darauf installiert. Inzwischen
läuft es recht stabil.
Leider habe ich den GDB immer noch nicht ans Laufen gebracht.
Thread beobachten
Seitenaufteilung abschalten