Hallo Leute,
ich habe folgendes problem. Ich arbeite mit AT91RM9200 Board unter
Linux. Ich möchte nur mein Board testen ohne Bootloader und ohne Linux
Kernel. Ich habe schon eine arm-gcc Umgebung installiert und beim Suchen
nach JTAG Wiggler(von Olimex)Software habe ich Openocd gefunden. Mit der
unten angegebenen Konfiguration
./ configure --enable-parport --enable-parport_ppdev habe ich Openocd
installiert.
config-file für AT91RM9200 Board:
#daemon configuration
telnet_port 4444
gdb_port 3333
#interface
interface parport
parport_port 0x378
parport_cable wiggler
jtag_speed 0
# reset_config <signals> [combination] [trst_type] [srst_type]
#reset_config trst_and_srst
#jtag scan chain
jtag_device 4 0x1 0xf 0xe
jtag_nsrst_delay 333
jtag_ntrst_delay 333
#target configuration, what to do on a target reset
target arm920t little run_and_halt 0 arm920t_r4
run_and_halt_time 0 30
daemon_startup reset
# target_script 0 reset openocd.script
# working_area 0 0x40000000 0x4000 nobackup
#flash bank cfi 0x10000000 0x01000000 2 2 0
Mit dem Befehl openocd -d AT91.cfg starte ich Openocd. Danach bekomme
ich folgende Fehlermeldung angezeigt:
Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-01 12:00
CEST)
Error: parport.c:333 parport_init(): cannot open device. check it
exists and that user read and write rights are set
Ich bin aber als root angemeldet. Die Schreib- und Leserechte sind auch
eingestellt. Aber ich habe festgestellt, dass ich statt "parport" "lp0"
habe. kann jemand mir bitte bitte helfen???????????
Wenn ich statt "interface parport" "interface parport0"eingebe, wird
folgende Fehlermeldung angezeigt:
Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-01 12:00
CEST)
Info: configuration.c:50 configuration_output_handler(): Command
parport_port not found
Info: configuration.c:50 configuration_output_handler(): Command
parport_cable not found
Error: jtag.c:1223 jtag_init(): No valid jtag interface found
(parport0)
Error: jtag.c:1224 jtag_init(): compiled-in jtag interfaces:
Error: jtag.c:1227 jtag_init(): 0: parport
Error: jtag.c:1227 jtag_init(): 1: amt_jtagaccel
Bin eine Frau brauche eure Hilfe ;-)
Hi,
wenn du den OpenOCD via ppdev verwenden willst, solltest du auch das
ppdev Modul laden, dann sollte es auch /dev/parport0 geben. Generell
sollte man das lp Modul (das ist nur für Parport-Drucker zuständig)
rauswerfen, da es sonst zu Problemen kommen kann.
Im .cfg File ist dann auch "parport_port N" die Richtige Auswahl, also
der N-te Parport (/dev/parportN).
> Info: openocd.c:82 main(): Open On-Chip Debugger (2006-08-01 12:00> CEST)
Ich bin zwar notorisch nachlässig, wenn es um's Updaten der
Versions-Strings geht, allerdings bin ich mir sicher, dass aktuelle
Sourcen einen 2007-er String tragen. Bitte immer die aktuelle Version
aus dem SVN Repository verwenden. Wie man einen Checkout macht steht auf
der OpenOCD Webseite.
Gruss,
Dominic
Hallo Gast,
> Das sagen auch Typen, weil sie sonst nur wieder dumm angelabert werden> hier ;-)
Warst du auch schonmal eine Frau :-). Hast anscheinend Erfahrungen.
Aber ich weis am besten, was ich bin - eine Frau - und das bleibt auch
so!
Hallo,
zumindest der Parallel Port wurde jetzt ordnungsgemäß geöffnet,
allerdings gibt es ein Problem bei der JTAG Kommunikation.
Der Olimex ARM-JTAG Adapter sollte eigentlich ausreichen, zumindest
funktioniert er hier einwandfrei. Problematischer sind die Parallelports
der PCs, bei Laptops ist es noch deutlich schlimmer. Eventuell schafft
ein kürzeres Parallelport Kabel abhilfe.
Um welches Target Board handelt es sich denn?
Gruss,
Dominic
Hey,
der OpenOCD ist generell als Daemon konzipiert, d.h. er läuft (im
Hintergrund), bis ein Client eine Verbindung aufbaut.
Aktuell unterstützt der OpenOCD Verbindungen via Telnet (default port
4444) und GDB (default port 3333).
Versuch doch einfach mal eine Verbindung via Telnet zu Port 4444, sobald
der OpenOCD wie von dir beschrieben läuft.
Gruss,
Dominic
<offtopic>
> Hallo Gast,>> Das sagen auch Typen, weil sie sonst nur wieder dumm angelabert werden>> hier ;-)> Warst du auch schonmal eine Frau :-). Hast anscheinend Erfahrungen.
Zwar lange Haare, aber keine Frau :-)
> Aber ich weis am besten, was ich bin - eine Frau - und das bleibt auch> so!
Okay - das überzeugt mich halbwegs. Aber noch eine Frage - sind deine
Socken Rosa oder Blau? :-)
Btw: Bahar ist ein netter Name - vor Popstar'07 kannte ich den noch
nicht - aber die kleine süße Bahar schwärm
</offtopic>
<ontopic>
Sorry - da kann ich dir nicht weiterhelfen :-)
</ontopic>
Hallo Dominic,
hab gestern auch festgestellt und es klappt jetzt mit (gdb)target remote
localhost:3333
Ich kann jetzt mit gdb arbeiten. Jetzt muss ich mich mit Openocd Befehle
beschäftigen und versuch sie zu verstehen. Wenn ich monitor flash probe
0 eingeben, wird folgende Fehlermeldung ausgegeben:
"probing failed for flash bank '#0' at 0x10000000"
ich hab SPI Flash(AT45CS1282) an Pin NC0.
in configfile habe ich stehen:
#flash bank <driver> <base> <size> <chip_width> <bus_width>
[driver_options ...]
flash bank cfi 0x10000000 0x800000 2 2 0
Ich habe mir alles anders vorgestellt. Durch Fehlermeldungen werde ich
noch schneller alt.
Weist du woran es liegen könnte?
Bin dir echt dankbar!
mfg
> Okay - das überzeugt mich halbwegs. Aber noch eine Frage - sind deine> Socken Rosa oder Blau? :-)
Diese Frage kannst und darfst hier gar nicht stellen. Das hat nix mit
µControllern zutun. Aber du hast mich auf eine Idee gebracht. Kennt
jemand ein µici, wo man die Sockenfarbe ständig ändern kann wie eine
Lichtquelle?
Menschen, die ein Leben lang gleiche Socken tragen!!! ne ne das war
keine gute Idee...
> Btw: Bahar ist ein netter Name - vor Popstar'07 kannte ich den noch> nicht - aber die kleine süße Bahar *schwärm*
ich muss mich sofort aber sofort umbennen Bruder Gast. Das ist mir gar
nicht aufgefallen, dass sie auch so heisst.
> Sorry - da kann ich dir nicht weiterhelfen :-)
Genau das wollte ich hören bzw. sehen und lesen.
mfg
Hey,
der OpenOCD unterstütz aktuell noch keine seriellen Flashes (Atmel
Dataflash etc.). Die aktuelle SVN Revision unterstützt:
- LPC2000 internes Flash
- AT91SAM7 internes Flash
- STR7x internes Flash
- STR9x internes Flash
- externe CFI kompatible Flashes nach Intel Standard
- extern CFI kompatible Flashes nach Spansion/AMD Standard (brandneu,
und noch nicht auf allzu vielen Devices getestet)
- externe NAND Flashes an einem LPC3180 NAND Controller (lässt sich
einfach auf andere NAND Controller erweitern)
Gruss,
Dominic
Hallo Dominic,
dann kann mir Openocd auch nicht weiter helfen. Kennst du vielleicht was
ähnlichens wie Openocd aber mit spi flash unterstützung?
Vielleicht mach ich doch mit Uboot, wenn ich keine andere Lösung finde.
Das leben ist unter linux nicht teuer aber schwer.
Ich danke dir Dominic!
Hi,
was du suchst ist ja nicht nur SPI Flash Unterstützung, sondern auch
noch Unterstützung für den SPI Controller des AT91RM9200 - ein Debugger
müsste dazu Treiber für viele unterschiedliche Controller mitbringen.
Ich denke nicht, dass es soetwas gibt. Ich denke man würde in dem Fall
per Debugger einen Loader (z.B. gleich u-boot) in's RAM laden, und
diesen das SPI Flash schreiben lassen. Ich wüsste übrigens im Moment
auch keinen Windows Debugger, der mit SPI Flashes an einem AT91RM9200
umgehen kann.
Gruss,
Dominic
hallo,
der einzige debugger der das programmieren von seriellen flashes
unterstützt ist der/das peedi (http://www.ronetix.at/peedi.html).
allerdings konnte ich dein AT45CS1282 auf der liste der unterstützten
flashes nicht finden.
desweiteren ist der/das peedi nicht ganz billig.
gruss
gerhard
Hallo,
danke dir Dominic für deine Hilfe. Gerhard ich arbeite unter Linux. Der
Debugger soll möglichst billig sein, besser Open Source. Hat jemand
schon mit u-boot und AT91RM9200 gearbeitet? Und einen Uploader braucht
man auch??
mfg
Hallo,
ich hatte U-Boot für ein CSB337 (ein AT91RM9200 basiertes Board von
Cogent Computers) angepasst, allerdings habe ich das Board nicht mehr,
und da der AT91RM9200 Support in U-Boot zu der Zeit gerade in einer
Umbruchphase war hatte ich den Patch auch nie Upstream gebracht.
Unterstützung für den AT91RM9200 selbst ist in U-Boot bereits enthalten,
die Anpassungen beschränken sich also im Grunde auf den
board-spezifischen Code, etwa Clock Setup, SDRAM und Flash
Konfiguration.
Wenn dein Board via SPI Flash booten soll wirst du aber auf Probleme mit
der aktuellen U-Boot Version stossen, da der U-Boot Maintainer und die
Atmel Entwickler andere Ansichten darüber haben, wie mit solchen "Flash"
Varianten umgegangen werden soll. In U-Boot werden diese Speicherchips
als "Storage" bezeichnet, und nicht als "Memory", da Memory nach Ansicht
der U-Boot Entwickler etwas ist, das am Prozessorbus hängt, und von
diesem wie ganz normaler Speicher zumindest gelesen werden kann (also
z.B. SRAM, SDRAM oder paralleles NOR Flash).
Wenn du es "richtig" machen willst solltest du die relaventen Threads
der letzten Wochen und Monate auf der U-Boot Mailingliste durchgehen,
und evtl. dort nachfragen, was der aktuelle Stand der Dinge ist. Für
Systeme, die via NAND Flash Booten gibt es nand_spl, für SPI sollte wohl
etwas ähnliches entwickelt werden.
Wenn du nur willst, dass es funktioniert, solltest du auf AT91.com
nachsehen. Wenn ich mich recht erinnere gibt es dort AT91 spezifische
Anpassungen, die in dieser Form wohl nicht Upstream gehen werden.
Gruss,
Dominic
