Hallo,
angehängt ist ein kleiner Bootloader, erstmal für den LPC 2478, sollte
sich aber sehr leicht auf andere ARM-Systeme portieren lassen.
Es unterstützt das Laden von ELFs von MMC/SD-Karte von einem
ext2-Dateisystem (unterstützung von FAT oder so ließe sich mit geringem
Aufwand hinzufügen). Die Partitionstabelle im MBR wird auch
unterstützt.
Wenn er startet hat man auf der UART eine Konsole, in der man ihm
Befehle geben kann, etwas zu laden. Man kann ihn auch so konfigurieren,
dass er nach dem starten eine Datei von der MMC lädt, aus der er die
Befehle ausführt. Dadurch kann man sich das ständige Flashen des
Controllers sparen.
Das LPC2478 Board, auf dem es läuft (das ich zur Entwicklung verwendet
habe), ist das Board von gsg-elektronik.de:
http://gsg-elektronik.de/?id=64
Soweit ich weiß hat gsg-elektronik.de noch ein paar dieser Boards übrig.
Ich habe für meinen Bootloader eine kleine Webseite erstellt, die aber
höchstens unwesentlich informativer ist als dieser Beitrag:
http://sohalt.users.nerdzoo.de/pab/
Würde mich freuen über ein paar Kommentare dazu, erstrecht über
Ratschläge, Wünsche, Patches etc. :).
Danke! Werd ich gleich testen. Besonders an dem ext2-Teil und dem
MMC-Driver bin ich interessiert. Wird bei Verwendung einer SD-Karte das
4 Bit Interface des MCI verwendet?
Nein, leider nicht. Der MMC-Treiber spricht über die GPIOs des
Controllers das SPI-Interface der Karte an. Zwar sehr langsam, aber
vermutlich deutlich portabler, und es funktioniert. Daten von der MMC
werden auch nicht gecacht. Durch einen Cache ließe sich beim Lesen etwa
das doppelte der Geschwindigkeit für Dateien >> 12 kB rausholen, für
wesentlich größere Dateien ein größerer Faktor.
Die Performance ist durchaus etwas, an der sich einiges optimieren
ließe. Für das Laden von Dateien, die nichtmal hundert kB groß sind,
ist es aber OK.
Als ich damals einen Treiber für das MCI des LPC2478 schreiben wollte,
hab ich nach einiger Zeit aus Verzweiflung auf eine SPI-Implementierung
zurückgegriffen, die zwar nicht schnell ist, aber mit der man immerhin
Daten von der MMC lesen kann.
Ja, habe es auch grade gesehen in deinem Code, dass das ganze über GPIOs
läuft.
Bei Interesse kann ich dir mal meinen MMC/SD-Driver zukommen lassen. Er
basiert auf einer Implementierung von Keil, welche ich nach meinen
Bedürfnissen modifiziert habe. Es werden SDs und MMCs automatisch
unterschieden; bei Verwendung einer SD wird automatisch auf das 4 Bit
Interface umgeschaltet. Ausserdem werden die Sektoren via DMA ins Memory
übertragen, was eine durchaus brauchbare Performance zur Folge hat.
Nach aussen hin hat der Driver 3 Funktionen:
MCI_finitialize()
Bool MCI_fReadSect(SectorNumber, CountOfSectors, Buffer)
Bool MCI_fWriteSect(SectorNumber, CountOfSectors, Buffer)
Man braucht nichts weiter zu tun, als Initialisierungsfunktion
aufzurufen, welche auch den Power für die Karte ein- oder ausschaltet.
Danach kann man nach belieben mit den Lese- und Schreibfunktionen
operieren.
Was mich allerdings noch interessieren würde:
Wie kann ich eine solche ELF-Datei mit IAR EWARM erstellen? Ich habe im
Output Converter gesucht, aber neben srec und hex gibt es da nur noch
binary, was wohl nicht ganz das richtige ist.
Ideen?
An einem Treiber fürs MCI hätte ich prinzipiell schon Interesse, falls
es sich (urheberrechtlich) in meinen Bootloader einbauen ließe.
Ich kenne IAR EWARM nicht, nach flüchtigem ergoogeln laß ich irgendwo,
dass IAR EWARM ab einer gewissen Version ELF unterstützt und
standardmäßig verwendet.
Falls du die GNU Binutils für den ARM installiert hast, kannst du
objcopy verwenden, um verschiedene Programmformate zu konvertieren.
srec kenne ich nicht. Bei binary und ihex ist das Problem, dass diese
Formate keine Informationen darüber enthalten, an welche Stelle im RAM
der Code geladen werden soll, und an welcher Stelle die Ausführung
beginnen soll, mein Bootloader diese Informationen aber braucht.
Für binary wäre der Aufruf von objcopy:
arm-elf-objcopy -O elf32-littlearm -I binary --rename-section
.data=.text --set-section-flags .data=code,load,alloc,readonly
--set-start 0xa0000000 -B arm --change-section-address .data+0xa0000000
image.bin image.elf
Dabei ist bei --set-start 0xa0000000 der entry-Point (die Addresse von
_start()), wobei man bei einer binary oder ihex sowieso darauf Wert
legen muss, dass sie ganz am Anfang ist. Das 0xa0000000 nach
--change-section-address ist die Addresse, ab der aufwärts sich der Code
befindet.
Das Problem hierbei ist, dass objcopy es leider versäumt, auch einen
program header korrekt anzulegen; folglich wird es nicht funktionieren -
aber ich war immerhin nah dran.
Vielleicht gibt es ja ein Format, das IAR EWARM erzeugen kann, und
objcopy in ELF umwandeln kann, bei dem keine wichtigen Informationen
verloren gehen.
Ich habe nur GCC zum Testen. Kompiliert mein Bootloader denn mit IAR
EWARM?
Naja, um deinen Bootloader im IAR zu compilieren, muss ich erst ein
neues Projekt anlegen und die Dateien da rein pfriemeln. Bis dann alles
passt, ist das immer so eine Sache mit aus dem Internet runtergeladenem
Code. Ich habe es noch nie erlebt, dass man den einfach so compilieren
kann... Was aber nicht die Schuld des Codes ist.
Zum MCI Driver:
Ich denke nicht, dass es rechtlich Probleme geben sollte. Warum? Wenn
man etwas länger gurgelt, findet jedermann diesen Code. Und das, was ich
am Code modifiziert habe, ist auf meinem Mist gewachsen. Von daher...
Du musst das entscheiden. Wenn du magst, poste ich den Code hier (oder
kann ihn dr auch mailen).
Gruss
Ja, gerne! Ich freu mich ja immer über neue Features und Verbesserungen
für meine Progrämmchen.
Am besten vielleicht hier hochladen, alternativ an die E-Mail Addresse
schreiben, die auf der Website des Bootloaders
(http://sohalt.users.nerdzoo.de/pab/) erwähnt ist.
Vielen Dank schonmal! Ich werde es dann vermutlich eines Tages
einbauen.
