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.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.