TFTP-Bootloader: Eine kurze Einführung -------------------------------------- Der TFTP-Bootloader ermöglich bei Verwendung des ATmega644, ATmega644P und ATmega1284P ein Update des NetIO über das Netzwerk. Hierzu wird einerseits eine EtherKISS-Version mit Bootloader benötigt, sowie auf einem Rechner ein TFTP-Server, und optional ein Syslog-Server, welcher zur Ausgabe von Meldungen des Bootloaders dient. Nach dem Einspielen einer neuen Version wird der TFTP- und Syslog-Server nicht mehr benötigt und wird erst wieder beim nächsten Update notwendig. ACHTUNG!!! Derzeit verfügt der TFTP-Bootloader für den ATmega1284P NICHT (!) über die Sicherheitsfunktionen des Loaders für den ATmega644! Es ist möglich mit einer entsprechend großen HEX-Datei den Bootloader ZU ÜBERSCHREIBEN! Gleiches gilt für HEX-Dateien mit Daten, die an die entsprechenden Adressen geschrieben werden sollen. Einen wirksamen Schutz gegen das Überschreiben des Bootloaders bietet derzeit nur das Setzen der entsprechenden Lockbits, die ein Schreiben in der Bootloadersektion in Hardware unterbinden. Der TFTP-Bootloader startet bei jedem Kaltstart ("REBOOT"-Kommando oder beim Einschalten) vor der eigentlichen EtherKISS-Firmware und versucht, vom TFTP-Server eine neue EtherKISS-Version zu laden. Zu diesem Zweck führt der Bootloader intern eine Art Versionszähler, den er zur Bildung des angeforderten Dateinamens benutzt. Nach einem erfolgreichen Flash-Vorgang wird dieser Zähler erhöht, und somit eine neue Datei angefordert. Die alte Datei kann auf dem TFTP-Server verbleiben und wird nicht erneut geflasht, zu diesem Zweck müsste sie entsprechend umbenannt werden. Die Einstellungen des TFTP-Bootloaders können nur von EtherKISS aus verändert werden, der Bootloader selbst hat keinerlei Kommandointerface. Die Übergabe der Werte zwischen EtherKISS und dem Bootloader passiert über das EEPROM. Einstellbar sind der abzufragende TFTP-Server, der Syslog-Server und der zu ladende Dateiname. Wir der "prog."-Jumper gesetzt, so gibt der Bootloader seine normalerweise nur über Syslog ausgegebenen Meldungen auch über die serielle Schnittstelle aus (9600 Baud). Weiterhin werden in diesem Fall auch die fest eincompilierten Standardwerte für TFTP- und Syslog-Server (beide 192.168.0.100) verwendet. Der Bootloader ist gegen Überschreiben durch sich selbst geschützt, er kann nur mit Hilfe eines ISP-Programmers aufgespielt und durch eine neue Version ersetzt werden. Wird mit Hilfe des Loaders geflasht, so ist die Einstellung der EESAVE-Fuse egal, das EEPROM bleibt immer erhalten. Installation des Bootloaders: ----------------------------- Hierzu gibt es zwei Varianten: Variante 1: (bevorzugt) * Neue Fuses setzen * Mit einem ISP-Programmer das passenden HEX-File aufspielen, welches EtherKISS und den Bootloader in einem enthält * Einstellungen des Bootloaders mit den passenden Befehlen in EtherKISS vornehmen Variante 2: Diese Variante konfiguriert den Bootloader vor der Installation und lädt dann EtherKISS mit Hilfe des Loaders. Sie ist komplizierter, dauert länger und sollte daher nur im Ausnahmefall benutzt werden. * Altes EtherKISS durch neues EtherKISS mit Bootloader-Unterstützung ersetzen. Hier reicht noch das EtherKISS-HEX ohne eingebauten Bootloader * Mit Hilfe der Bootloader-Konfigurationsbefehle die Einstellungen des Bootloaders vornehmen * Fuses ändern. Achtung: die EESAVE-Fuse muss so gesetzt sein, dass das EEPROM beim folgenden ISP-Flashvorgang erhalten bleibt! * Den Bootloader separat mit einem Programmer am ISP-Anschluss einspielen * Den nun startenden Bootloader zum erneuten Aufspielen von EtherKISS nutzen Fuses: ------ Damit der Bootloader beim Start anstatt der eigentlichen Firmware zuerst gestartet wird, müssen die Fuses verändert werden. Geschieht dies nicht, dann wird, auch wenn der Bootloader im Flash ist, weiterhin direkt EtherKISS gestartet! EtherKISS kann grundsätzlich auch mit diesen Fuses betrieben werden, auch wenn sich kein Bootloader im ATmega befindet. Die Bootloader-Sektion wird dann zwar angesprungen, sollte aber leer sein bzw. nur 0xFFs enthalten, die vom ATmega als NOP-Befehle interpretiert und die Sektion somit durchlaufen wird bis durch den Überlauf des Programmzählers wieder an Andresse 0 regulär gestartet wird. Die neuen Fuses des ATmega644 und ATmega1284P für den Betrieb mit einem Bootloader sind folgende: L-Fuse: 0xF7 H-Fuse: 0xD0 (war D7) E-Fuse: 0xFF TFTP- und Syslog-Server: ------------------------ Hier können beliebige Programme verwendet werden. Gute Erfahrungen haben wir mit der Verwendung von TFTP32 für Windows gemacht. Kommandos zur Konfiguration: ---------------------------- EtherKISS enthält nun drei neue Kommandos um die Einstellungen des Bootloaders im EEPROM verändern und anzeigen zu können. TFTPSERVER setzt die abzufragene TFTP-Server-IP-Adresse (Default: 192.168.0.100) SYSLOG setzt die IP-Adresse des Syslog-Servers (Default: 192.168.0.100) TFTPFILE setzt den zu ladenden Dateinamen (max. 15 Zeichen, Default: EKISS_###.hex) Der Dateiname kann optionale Ersetzungstellen (#-Zeichen), welche für die Versionierung benötigt werden, beinhalten. Nähere Infos dazu siehe unter "Sonstiges". Sonstiges: ---------- Der TFTP-Bootlaoder wurde ursprünglich von Jens Mundhenke, DL4AAS, geschrieben. Er wurde von mir modifiziert und inzwischen bei etlichen ATmega-Projekten bei DB0TVH, DB0YI, DB0HEX und etlichen anderen Relaisfunkstellen eingesetzt. Die nachfolgende Beschreibung gibt noch etliche Tipps und nennt mögliche Stolperfallen bei der Verwendung des Loaders. Sie ist der nicht-EtherKISS-spezifische Text, den es sonst immer als Anleitung dazu gibt ;) Bekannte Probleme: ------------------ * Nach dem Einschalten wird die "Boot"-Meldung, und manchmal auch die "Svr x.x.x.x"-Meldung, nicht über SYSLOG versendet, bei schon laufendem Board kommen beide Meldung an. Scheint so, als sei der ENC-Chip nach dem Einschalten noch nicht so weit, bzw. der Link ist noch down. Vielleicht hilft hier ein kleines delay() weiter. Das Problem ist eigentlich nur Kosmetik und passiert nur, wenn man frisch einschaltet. * Die SYSLOG-Meldung mit der TFTP-Serveradresse wird manchmal an die Broadcast-Adresse versendet. Alle folgenden Meldungen werden an die richtige SYSLOG-IP versendet. Kommt nur sehr selten und in der Regel auch nur nach dem Einschalten vor. Kann bzw. wird wohl mit dem ersten Problem zusammenhängen, so dass die notwendigen ARP-Pakete der Anfrage oder der Antwort verloren gegangen sind, der Stack daher noch keine ARP-Einträge aufbauen konnte, und daher an die Broadcast-MAC oder -IP sendet. * Ganz selten ist beim Start auch ein "Malformed Packet" in WireShark zu sehen, welches nur aus Null-Bytes besteht. Dies wird wohl eines der beiden Pakete sein, mit denen der ENC-Netzwerkchip zu Anfang durchgespült wird. Dagegen kann man nix machen, das sollte auch im Code so bleiben. * Die Ansteuerung eines LCD-Displays durch den Bootloader ist aus Platzgründen nicht möglich. Die Debugausgaben erfolgen daher ausschliesslich an den Syslog-Server, oder bei entsprechender Jumperstellung auch am seriellen Anschluss. Verhalten: ---------- * Der Bootloader startet immer, egal wie der Jumper NORMAL/PROG gesetzt ist, der Jumper beeinflusst nur, ob die fest eincompilierten Werte oder die Werte aus dem EEPROM genommen werden. * Es wird immer versucht, die Datei vom TFTP-Server zu laden. Wird sie dort vorgefunden, dann wird sie gebrannt, EGAL OB SIE SCHON GEFLASHT WURDE ODER NICHT! Daher sollte DRINGEND ein Dateiname mit Ersetzungsstellen verwendet werden, damit wiederholtes Laden der selben Datei nicht geschieht! * Wird der TFTP-Server nicht gefunden (ARP und/oder IP), oder hat er die gewünschte Datei nicht, dann wird die Applikation gestartet. Der Bootloader bleibt bei Problemen mit dem Netzwerk generell nicht stehen, sondern startet immer die Applikation. * Jeder Boot des Boards, und wenn eincompiliert auch der Grund des Reboots (als Zahl), wird beim Start per Konsole (SYSLOG und seriell) ausgegeben. * Der benutzte TFTP-Server und die abgefragte Datei (nach ###-Ersetzung) werden immer über die Konsole zur Kontrolle ausgegeben. * In der Stellung PROG werden KEINE Einstellungen aus dem EEPROM geladen, es werden die eincompilierten Defaultwerte verwendet. ACHTUNG: Dies gilt NICHT für die serielle Nummer der zu ladenden Datei, sofern mit Ersetzungszeichen im Dateinamen gearbeitet wird! Hier wird die Nummer immer aus dem EEPROM geladen! Es empfiehlt sich daher, als Default einen Dateinamen OHNE Ersetzungszeichen einzucompilieren, und später einen Dateinamen mit Ersetzungsstellen im EEPROM zu hinterlegen. * Jeder erfolgreiche Flash-Vorgang erhöht den internen Versionszähler um eins. Dies ist unabhängig davon, ob ein versionierter Dateiname hinterlegt wurde oder nicht. Der Zähler kann somit auch bei nicht versioniertem Dateinamen als Flash-Zähler missbraucht werden. * Wenn der Versionszähler den Wert 255 erreicht hat, springt er wieder auf 0 und beginnt erneut hochzuzählen. Nach der Datei "file_255.hex" wird also die Datei "file_000.hex" erwartet. Was man NICHT machen sollte: ---------------------------- * Der Bootloader und EtherKISS brauchen IMMER die gleichen Einstellungen für MAC, IP, Netzmaske und Router. Vor allem zwischen den Teilen abweichende MAC oder IP bereiten erhebliche Probleme, da beide Teile dann unterschiedliche ARP-Anfragen stellen und andere Netzwerkgeräte dann ggf. noch die Einstellungen des jeweils anderen Teils kennen, und so die Pakete schlicht nicht ankommen. Daher: IMMER in beiden Teilen konsistent sein, wird ein Teil geändert, dann ist auch der andere neu zu compilieren und einzuspielen! Alternativ im EEPROM abweichende Werte hinterlegen, diese werden von beiden Teilen gemeinsam genutzt. * Bei Dateinamen mit Ersetzungstellen MÜSSEN es immer drei Rauten (###) im Dateinamen sein! Der Bootloader sucht aus Gründen der Codegrösse nur nach dem Vorhandensein einer Raute, geht aber davon aus, dass es drei sind und ersetzt diese Stellen mit der Dateiversionsnummer! Was an der Stelle der ersten Raute und den beiden folgenden Stellen steht wird gnadenlos überschrieben, auch wenn es eigentlich gar nicht ersetzt werden soll! * Die Rauten sollten nicht am Ende des Dateinamens sein, besser sind sie mitten drin aufgehoben. (Beispiel: "file_###.hex") * Soll der Bootloader gestartet werden, dann sollte generell per Watchdog rebootet werden. Ein Anspringen der Adresse des Bootloaders, auch wenn es laut Doku möglich sein soll den Loader so aus der Applikation heraus zu starten, hat sich als nicht sicher erwiesen. Das Board bleibt dann manchmal in einer Endlosschleife hängen. Daher: Reset IMMER per Watchdog ("REBOOT"-Kommando) ausführen! Dieser wird vom Bootloader beim Start sofort wieder deaktiviert.