TFTP-Bootloader: Eine kurze Einfhrung
--------------------------------------

Der TFTP-Bootloader ermglich bei Verwendung des ATmega644 und ATmega644P
ein Update des NetIO ber das Netzwerk. Hierzu wird einerseits eine EtherKISS
-Version mit Bootloader bentigt, 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 bentigt und wird erst wieder beim nchsten
Update notwendig.

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 fhrt
der Bootloader intern eine Art Versionszhler, den er zur Bildung des
angeforderten Dateinamens benutzt. Nach einem erfolgreichen Flash-Vorgang
wird dieser Zhler erhht, und somit eine neue Datei angefordert. Die alte
Datei kann auf dem TFTP-Server verbleiben und wird nicht erneut geflasht,
zu diesem Zweck msste sie entsprechend umbenannt werden.

Die Einstellungen des TFTP-Bootloaders knnen nur von EtherKISS aus verndert
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 fr TFTP- und Syslog-Server (beide 192.168.0.100) verwendet.

Der Bootloader ist gegen berschreiben durch sich selbst geschtzt, er kann
nur mit Hilfe eines ISP-Programmes aufgespielt oder durch eine neue Version
ersetzt werden.


Installation des Bootloaders:
-----------------------------

Hierzu gibt es zwei Varianten:

Variante 1: (bevorzugt)

* Aufspielen eines passenden HEX-Files, welches EtherKISS und den Bootloader
  in einem enthlt

* Einstellungen des Bootloaders mit den passenden Befehlen vornehmen

* Neue Fuses setzen


Variante 2:

Diese Variante konfiguriert den Bootloader vor der Installation und ldt dann
EtherKISS mit Hilfe des Loaders. Sie ist komplizierter, dauert lnger und
sollte daher nur im Ausnahmefall benutzt werden.

* Altes EtherKISS durch neues EtherKISS mit Bootloader-Untersttzung ersetzen. Hier
  reicht noch das EtherKISS-HEX ohne eingebauten Bootloader

* Mit Hilfe der Bootloader-Konfigurationsbefehle die Einstellungen des Bootloaders
  vornehmen

* Den Bootloader separat per ISP einspielen

* Fuses ndern

* Den nun startenden Bootloader zum erneuten Aufspielen von EtherKISS nutzen


Fuses:
------

Damit der Bootloader beim Start anstatt der eigentlichen Firmware zuerst gestartet
wird, mssen die Fuses verndert werden. Geschieht dies nicht, dann wird, auch wenn
der Bootloader im Flash ist, weiterhin direkt EtherKISS gestartet!

Die neuen Fuses fr den Betrieb mit Bootloader sind folgende:

L-Fuse: 0xF7
H-Fuse: 0xD0 (war D7)
E-Fuse: 0xFF


TFTP- und Syslog-Server:
------------------------

Hier knnen beliebige Programme verwendet werden. Gute Erfahrungen haben wir mit der
Verwendung von TFTP32 fr Windows gemacht.


Kommandos zur Konfiguration:
----------------------------

EtherKISS enthlt nun drei neue Kommandos um die Einstellungen des Bootloaders im EEPROM
verndern und anzeigen zu knnen.

TFTPSERVER <IP-Adresse>      setzt die abzufragene TFTP-Server-IP-Adresse (Default: 192.168.0.100)
SYSLOG <IP-Adresse>          setzt die IP-Adresse des Syslog-Servers (Default: 192.168.0.100)
TFTPFILE <Dateiname>         setzt den zu ladenden Dateinamen (max. 15 Zeichen, Default: EKISS_###.hex)

Der Dateiname kann optionale Ersetzungstellen (#-Zeichen), welche fr die Versionierung bentigt werden,
beinhalten. Nhere Infos dazu siehe unter "Sonstiges".


Sonstiges:
----------

Der TFTP-Bootlaoder wurde ursprnglich 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 mgliche 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 zusammenhngen, so dass die
  notwendigen ARP-Pakete der Anfrage oder der Antwort verloren gegangen sind, der Stack daher noch keine
  ARP-Eintrge 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 durchgesplt
  wird. Dagegen kann man nix machen, das sollte auch im Code so bleiben.

* Die Ansteuerung des LCD-Displays durch den Bootloader ist aus Platzgrnden nicht mglich.


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 gewnschte 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 fr 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 spter
           einen Dateinamen mit Ersetzungsstellen im EEPROM zu hinterlegen.

* Jeder erfolgreiche Flash-Vorgang erhht den internen Versionszhler um eins. Dies ist unabhngig davon, ob
  ein versionierter Dateiname hinterlegt wurde oder nicht. Der Zhler kann somit auch bei nicht versioniertem
  Dateinamen als Flash-Zhler missbraucht werden.

* Wenn der Versionszhler den Wert 255 erreicht hat, springt er wieder auf 0 und beginnt erneut hochzuzhlen.
  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 fr 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 Netzwerkgerte 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 gendert, dann ist auch der andere neu zu
         compilieren und einzuspielen!

* Bei Dateinamen mit Ersetzungstellen MSSEN es immer drei Rauten (###) im Dateinamen sein! Er sucht aus Grnden
  der Codegrsse 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 mglich 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 hngen.

  Daher: Reset IMMER per Watchdog ("REBOOT"-Kommando) ausfhren! Dieser wird vom Bootloader beim Start sofort wieder   deaktiviert.



