www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie kann ich U-Boot auf AT91RM9200 testen


Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich habe nach anfänglichen Schwierigkeiten eine komplette GNU Toolchain 
erstellt. Nun habe ich den U-Boot Bootloader angepasst und kompiliert.
Jetzt ist aber die Frage wie bekomme ich den U-Boot auf mein AT91RM9200 
Borad und kann diesen Testen / Debuggen?

Gruß Mario

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
unter folgendem link findest du hinweise:
http://www.linux4sam.org/twiki/bin/view/Linux4SAM/U-Boot

gruss
gerhard

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

danke schonmal für die Antwort.
Leider finde ich den AT91RM9200 nict in meinem SAM-BA.
Hat vielleicht jemand eine Beispielkonfiguration?

Gruß Mario

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der AT91RM9200 hatte zwar auch schon einen Bootloader im ROM, 
SAMBA-kompatibel war das aber noch nicht, wenn ich mich recht erinnere. 
Im Datasheet (Rev. G) Kapitel 13 steht, dass über den USB Device Port 
das USB DFU (device firmware upgrade) Protokoll und über den Debug Uart 
(DBGU) das X-Modem Protokoll benutzt wird.

Da zu diesem Zeitpunkt nur das interne SRAM zur Verfügung steht wirst du 
einen 2-nd stage Bootloader herunterladen müssen, der dann den 
eigentlichen U-Boot in's SDRAM lädt. Von dort kann sich U-Boot dann 
selbst in's Flash schreiben, alternativ lädt der 1st stage Bootloader 
eine Flash Routine, die dann U-Boot direkt in's Flash bringt.

Gruß,

Dominic

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
vielleicht hilft auch die atmel application note
http://www.atmel.com/dyn/resources/prod_documents/...

gruss
gerhard

Autor: Mario (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe nun die Cross Toolchain mit OpenOCD und Insight fertig.
Der U-Boot Bootloader ist auch schon übersetzt. Nun möchte ich
den U-Boot per OpenOCD in das SDRAM des AT91RM9200 Target laden
und dort Debuggen / ausführen. Geht das mit OpenOCD? Irgendwie muss
ich nun noch mein Controller Configurieren, PLL, ChipSelect,
SDRAM an Adresse 0 usw.. Wie kann ich das mit OpenOCD realisieren?

Über eine Antwort wäre ich dankbar.

Gruß Mario

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiß, der Thread ist schon ein Jahr alt, aber ich möchte ihn für 
meine gleichartigen Anfragen recyclen.

Ich habe ein AT91RM9200 basierendes System, auf dem auch schon ein 
uralter uBoot läuft. Ich würde diesen gern aktualisieren und dabei 
einige Anpassungen vornehmen.

Da ich ohne Aufwand weder USB noch DBGU kontaktieren kann und auch JTAG 
(noch) nicht zur Verfügung steht, würde ich gerne den alten uBoot nutzen 
um meinen neuen zu laden ( tftp läuft) und im RAM zu starten. Wenn der 
neue dann zufriedenstellend läuft, kann ich ja den alten nutzen, um den 
neuen zu flashen.

Meine Fragen sind nun, kann ich einen uBoot ohne größere Probleme im RAM 
starten? Da der SourceTree vom uBoot schon recht groß ist, würde ich 
mich über ein paar Hinweise freuen, wenn besondere Einstellungen für 
diese RAM-Start Aktion erforderlich sind.

Weiß zudem jemand, ob die neueren uBoot Versionen die Ablage von IPs und 
NetMask in einem EEPROM unterstützen? Ich spiele gerade mit uBoot 1.2.0, 
würde aber auch gleich auf 1.3.x wechseln, wenn das mehr Komfort bringt.

Gruß, Ulrich

Autor: Ulrich P. (uprinz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, habe einige Sachen inzwischen schon kapiert:
Der im AT91RM9200 befindliche Loader, den ich inzwischen über DBGU 
ansprechen kann, lädt einen 2nd Stage Bootloader hoch, der ein gepacktes 
Images eines uBoot ins RAM entpackt und dann dort ausführt.

Aber ich habe wohl vergessen, dass mein Board bereits einen alten, aber 
funktionierenden uBoot hat. Also kann ich per tftp [addr] [file] meinen 
neuen uBoot laden und ausführen. Dumm ist jetzt, dass mir das nicht so 
richtig gelingen will. Da die Doku und die Dateien sich wegen der 
möglichen Load-Address streiten, weiß ich jetzt nicht wirklich, wohin 
ich das Image laden soll um es dann mit go [addr] auszuführen. An die 
Adresse des existierenden uBoot im RAM kann ich den neuen ja nicht 
laden, das crasht. Wie aber kann ich die Zieladresse im neuen uBoot so 
ändern, dass ich ihn direkt aus dem RAM starten und testen kann?

Geht der uBoot überhaupt mit gcc 4.1.2 oder ist eine andere Kombination 
besser? Also älterer gcc oder neuerer uBoot? Es gab immer wieder 
Hinweise, dass uBoot sich nicht mit gcc 4.0.x verträgt, aber alle aus 
Zeiten, als uBoot noch 1.1.5 war. Ich würde es bevorzugen, wenn meine 
ganze Toolchain auf einem Level wäre...

Danke schon mal,

Ulrich

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.