Bootloader-lockbits im ATmega64 zur laufzeit setzen

[Martin Raffelsieper (Gast)]

Hallo!

ich kämpfe immer noch mit der Bootloaderei.

Weiss jemand, was ich hier falschmache:


wenn ich folgende Zeile aufrufe (diese liegt in der Bootloader
Section)

   boot_lock_bits_set(0xCF);


, dann sollte doch anschlieesend irgendein LockBit gesetzt sein. Mit
dem JTAGICE sehe ich immer nur nicht gesetzte Lockbits.

mußß ich da noch irgendwas drumherumbauen oder was mache ich verkehr?


Gruß Martin

[Martin Raffelsieper (Gast)]

Hm, sollte sich da noch ein Bug im GCC Compiler befinden??

in den Headerfiles gibts eine __BOOT_LOCK_BITS_MASK, die wohl
verhindern soll, dass man die anderen beiden Bits (LB2, LB1) mit setzt
bzw löscht.

Die Lockbits werden aber mit einer 0 gesetzt (sehr logisch!), so dass
die MASK meines Erachtens invertiert werden müsste.


jedenfalls kann man an die boot_lock_bits_set()-Funktion übergeben was
man will, die Lockbits bleiben auf 1 (also ungesetzt) kleben, bzw
fallen sogar ungewollt auf 1 zurück.

Die LB1 und 2 Bits dagegen kann man schön verändern!


habe ich recht oder bin ich auf dem Holzweg?


Gruß Martin

[mthomas (Gast)]

Vielleicht hilft es, die Maske einfach erstmal zu deaktivieren.
Hier ein aus boot.h herausgschnittenes Makro ohne die Maske.

#define _boot_lock_bits_set_alternate_bf(lock_bits)        \
({                                                         \
    boot_spm_busy_wait();                                  \
    _asm__ __volatile_                                   \
    (                                                      \
        "mov r0, %2\n\t"                                   \
        "sts %0, %1\n\t"                                   \
        "spm\n\t"                                          \
        ".word 0xffff\n\t"                                 \
        "nop\n\t"                                          \
        : "=m" (__SPM_REG)                                 \
        : "r" ((unsigned char)__BOOT_LOCK_BITS_SET),       \
          "r" ((unsigned char) lock_bits)                  \
        : "r0"                                             \
    );                                                     \
    boot_spm_busy_wait();                                  \
})

[Martin Raffelsieper (Gast)]

ja, ich denke auch, dass man erstmal die Maske weglässt, man
setzt/löscht dann halt alle 6 Lockbits.



Gruß
martin

[Martin Raffelsieper (Gast)]

Unsinn, man kann nicht alle 6, sondern nur die 4 BLB's verändern!!!

(der SPM-Befehl greift nur auf die BLB's zu)


jedenfalls hat mthomas' Beispiel funktioniert - vielen Dank


Gruß Martin

[Peter D. (peda)]

Und kann man die Bits hin- und zurück setzen ?

Wenn man sie wieder rücksetzen kann, sind sie sinnlos.

Die heißen ja deshalb Lockbits, weil sie den Inhalt gegen fremde Augen
sperren (=lock) sollen.
Ein Rücksetzen außer durch ein Full-Erase, d.h. mit Erhalt des
Flashinhalts sperrt aber rein gar nichts.


Ich habe deshalb meinen Bootloader so geschrieben, daß er alle
Funktionen verweigert, sobald das letzte Wort unter ihm ungleich 0xFFFF
ist.
Nur ein Erase-Kommando ist noch erlaubt, welches erst den EEPROM und
dann den Flash von unten anfangend mit 0xFFFF beschreibt.


Peter

[Martin Raffelsieper (Gast)]

HM,

ich denke es ist so:

Man flasht den Bootloader und evtl eine Firmware, setzt die Boot reset
Fuse und die LB0 und LB1-Lockbits.


Somit kann man nicht mehr per SPI oder JTAG das Programm lesen oder
schreiben, der Code ist vor fremden augen geschützt.

Nur der Bootloader kann noch den Code ändern. Nur sollte dieser so
geschrieben sein, dass er keinen Einblick in den App-Bereich gestattet,
und die BLB-Bits sollten gesetzt werden.


Wenn der Bootloader auch noch über eine Verschlüsselung verfügt, ist
alles im Lack:
ein Fremder kann keine "Hackerfirmware" hineinladen, die irgendwas
seriell heraustackert, weil er dazu ja die Verschlüsselung kennen muß.


Du hast aber recht:
über einen Bootloader ohne verschlüsselung kann man quasi alles in den
Chip hineinbekommen, und die BLB-Bits wären hinfällig


Gruß Martin