Ethernet Loader (Deutsch)

From Ethersex_Wiki
Jump to: navigation, search

Bootloader einrichten (TFTP)

Da ich mindesten 6h mit Fehlersuche verschwendet habe, hier eine Anleitung wie man den TFTP-Bootloader verwendet.
Ganz wichtig, es darf per tftp NIE das ethersex.hex File geladen werden.

Vorteile des Bootloaders

  • Durch den Einsatz eines Bootloaders benötigt man (vom Flashen des Bootloaders einmal abgesehen) keine Flash-Hardware mehr.
  • Der ISP-Port blockiert den Ethernet-Port (zumindesten bei der AVR NET-IO bzw. beim Einsatz bestimmter Programmieradapter)
  • Update und Entwicklungen können bequem vom Schreibtisch aus vorgenommen werden

Benötigt werden:

  • Bootloader im ethersex.hex Format
    • Firmware Builder
      • enc_mac = die MAC-Adresse vom Hardwareboard
      • enc_ip = IP-Adresse vom Board
      • enc_ip4_netmask = passende Maske vom Netz
      • etherrape_gateway = default GW
      • tftp_ip = die IP-Adresse vom tftpd Server, also des PCs auf dem der tftpd läuft
      • tftp_image = Name des binaries, das im tftpboot-Verzeichnis liegt. z.B. esex.bin
  • oder
    • config-File für die AVR Net-IO
      • Load a Default Configuration --->
        • (x) Ethernet Bootloader
      • als Start und dann an die Gegebenheiten anpassen. Im Bootloader werden nur UDP und TFTP zum Nachladen der Firmware benötigt.
      • Network --->
        • (x) UDP support
        • (x) UDP broadcast support
        • (x) Ethernet(ENC28J60)support -> Etherrape IP-Adresse: "IP-ADRESSE eintragen" (Dieser Eintrag erscheint nur wenn bootp nicht aktiv ist)
      • Applications ->
        • (x) TFTP support
        • Bootloader configuration ->TFTP-o-matic (Dieser Eintrag erscheint nur wenn Network --> bootp nicht aktiv ist)
          • TFTP IP address: "IP-ADRESSE DES TFTP-SERVERS"
          • TFTP image to load: "esex.bin" (Name des BIN-files) (evtl. ist hier der absolute Pfad nötig /tftpboot/esex.bin)
  • eigentliche Firmware im ethersex.bin Format
    • das make erzeugt immer eine ethersex.hex und eine ethersex.bin und wird z.B. als esex.bin auf den tftpd-Server kopiert
  • tfpd-Server
    • Linux: atftpd, tftpd oder tftpd-hpt
    • Windows: tftp32.exe
      • BESCHREIBUNG FÜR WINDOWS wenn nicht DHCP verwendet wird
      • der Windows Rechner muss die IP haben die vorher in Ethersex als Server eingestellt worden ist
      • esex.bin einfach in das Verzeichnis vom TFTP-Server (Windows) kopieren
      • Programm starten und freuen -- sobald der Ethersex startet holt er sich automatisch neue Firmware esex.bin (Name der eingestellt ist)
      • anschließend könnt ihr die Datei aus dem Verzeichnis löschen oder Programm schließen ansonsten wird der nach jedem starten vom ESEX wieder neu gelasht

Wichtig!

  • Der Bootloader funktioniert nicht ohne weiteres mit dem Atmega32, da dort der Bootloaderbereich zu klein ist. Es wird ein Atmega644 oder ein 1284p benötigt.
  • der ethersex Bootloader funktioniert als TFTP-Client
  • auf der Linux bzw. Windows Maschine muss ein TFTPD (TFTP-Server) laufen.
  • das ethersex sucht auf dem TFTP-Server seine Firmware lädt sie selbständig in seinen Flash.

Installation

  • auf dem klassischem Weg wird die ethersex.bin erstellt (make menuconfig; make)
  • Der tftpd wird wie von der Distribution vorgesehen gestartet. Das ethersex.bin kommt in das /tftpboot Verzeichniss

Anpassung der FUSE-Bits

Damit das Ganze funktioniert, müssen die FUSE-Bits angepasst werden. Mit dem Tool FUSE-Calc kann man sich durch anklicken seine FUSE-Bits zusammenstellen. Für den atmega644(p) hier ein Beispiel.

avrdude -p m644p -c ponyser -P /dev/ttyS0 -U lfuse:w:0xff:m -U hfuse:w:0xd8:m -U efuse:w:0xfc:m

Flashen des Bootloaders

Der Bootloader wird als .hex auf klasischem Weg geflasht.

avrdude -p m644p -c ponyser -P /dev/ttyS0 -U flash:w:<bootloader.hex> -v

(Statt <bootloader.hex> ist natürlich der korrekte Name des Hex-Files anzugeben; selbstverständlich ohne "<>". Wichtig: unbedingt das <bootloader.hex> flashen, mit dem Flashen des <bootloader.bin> funktioniert der Bootloader nicht, weil dieser in den falschen Bereich im Flash geschrieben wird)

Spätestens nach einem Reboot der Hardware versucht der Bootloader per tftp die eigentliche Firmware zu laden und zu starten.

Eine einmal auf diesem Weg installierte Firmware ist immer auf dem Board und der Bootloader holt nur auf händische Anfrage ein neues esex.bin vom tftp-Server

LOCKBITS Bootloaderschutz

Wenn der Bootloader instaliert ist sollten noch die Lockbits gesetzt werden. Bitte nur die Fuses mit Boot Loader Protections Mode3 setzen.

Dadurch wird verhindert das der Bootloader überschrieben wird, wenn das Image in den Bereich vom Bootloader kommt. Dies Passiert wenn das Image für den ATMEGA 644 größer als 90% ist. (bei mir 90,3% da BL 9,7%)

Durch die Lockbits bekommt man dann am TFTP Server die Meldung ERR, aber der Bootloader funktioniert weiterhin.

Wenn mit SPI der Bootloaader neu geflasht wird, werden die Lockbits vom Bootloader Mode3 wieder auf Mode1 gesetzt. D.h. immer beim neuflash über SPI, den Boot Loader Protections Mode3 setzen.

ALS FAUSTFORMEL: BIN-File nicht größer als 90% -- ca. 10% braucht der Bootloader

Für ATmega644P:

avrdude -p m644p -c ponyser -P /dev/ttyS0 -U lock:w:0x0F:m

Händisches laden eines neuen Images (Ecmd_Reference)

Anm.: Voraussetzung für das ECMD "bootloader" sind die Optionen "General Setup -> Prompt all possible options" (CONFIG_EXPERT) und "General Setup -> Enable bootloader jump" (BOOTLOADER_JUMP) im menuconfig. Per Telnet sich mit dem ethersex verbinden (telnet <IP-Ethersex> 2701). Dort "bootloader" oder "wdreset" eingeben.

Oder per Web-Browser: http://<IP-Ethersex>/ecmd?bootloader.

Wenns nicht auf Anhieb klappt:

(a) Fehlerbild:

Ethersex holt sich zwar vom TFTP-Server ein neues Binärfile und schreibt es in seinen Speicher - aber dann geht nichts mehr übers Netzwerk (kein Ping, kein Telnet, etc).

(b) Ursachen:

b1) In Bootloader-Image und im Binärfile werden unterschiedliche MAC-Adressen verwendet.

oder:

b2) "make" hat keine wesentliche Änderung an .config festgestellt und daher das identische Binary nochmals erzeugt; Image wird zwar neu geladen und auch geflasht - Controller zeigt aber das identische Verhalten

(c) Abhilfe:

für b1) ARP-Cache löschen oder warten

für b2) "make clean && make"

mögliche Probleme

Bei Einsatz des Add-On Boards kann es vorkommen, dass der SD-Kartenleser nicht mehr einwandfrei initialisiert wird. Die LED neben dem SD-Kartenslot leuchtet ständig und es erscheint die Meldung im Debug-Mode: „sd_reader: fat_create_file: invalid parameters.“ Dann muss die SD-Karte einmal entfernt und wieder eingesetzt werden. Die LED leuchtet dann auch nicht mehr dauerhaft.