Wie kann ich U-Boot auf AT91RM9200 testen

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

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

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