Lite undringar kring det här med bootloaders

[TomasL]

Har lite funderingar till det här med bootloaders.
Tanken är naturligtvis att kunna programmera om systemet med en serielina istället för vanliga programmerare.
En fundering är då, normalt produceras en ELF-fil och en IntelHex fil, ingen av dem är väl direkt lämpliga för att ladda över till en bootloader, eller.
Vad är lämpliga filformat och lämplig teknik för att skapa detta.
Gissar att jag naturligtvis måste tillverka ett PC-program som pratar med bootloadern och skickar över data till den.
För att vidareutveckla det hela så tänkte jag också att man kan ha en dekrypterande bootloader som on-the-fly dekrypterar binärfilen innan den programmeras.
Tanken är då att använda XTEA eller nått liknande.

[Nerre]

Det är väl egentligen ingen skillnad mellan att skriva en bootladdare och skriva annan kod som körs vid boot. Bootladdaren är ju helt enkelt en kod som körs vid boot och om inget annat händer så lämnar den sen över till "nyttokoden" så att säga.

[Erik M]

Allt det där finns väl beskrivet hos MicroChip.

8-bit Bootloader
...och...
A FLASH Bootloader for PIC16 and PIC18 Devices

Så det känns lite som att gå över vatten att ge sig på.

Fast det är klart, du säger inget om i vilken miljö du befinner dig med detta...

[TomasL]

Det vet jag, dock det intressanta är vilka tekniker/filformat/handskakning etc för att skicka över den nya programvaran så säkert som möjligt, vilken bootloadern skall programmera i processorns flashminne.
Jag vet att microchip har en hel del exempel, men allt är ju numera baserat på härket Harmony, vilket inte är roligt alls.

[Erik M]

Du kan ju kolla hur Arduino löser det. Där går ju allt via bootloader.

Att köra [av]kryptering lär du inte klara dig utan, inte om du önskar se andra använda var du hittar på och fram till.

[TomasL]

Nu är väl tanken den att filöverföringen bör vara tämligen robust, sas.

[Nerre]

Det finns ju en uppsjö av olika filöverföringsprotokoll, på modem-tiden använde man ju de olika xmodem, zmodem och vad de nu hette.

Det är väl bara att välja och vraka i listan här
https://en.wikipedia.org/wiki/List_of_f ... onnections

Jag tror ju att krypteringbiten är betydligt värre att lösa.

[rvl]

Över 10 år gammal appnote för AVR: AVR230: DES Bootloader

[lillahuset]

Vi använder i våra projekt en "imagefil" som i verkligheten är en tarfil som är gzippad och innehåller ett bashscript som exekveras och vet vad det ska göra med alla ingående delar. Fördelen är att man kan skapa filer som ändrar nästan vad som helst i systemet. Vilket naturligtvis kan bli en nackdel om någon skapar en "imagefil" som installerar skadlig kod.

För nivån "under", dvs "löven" eller underordnade enheter, nöjer vi oss med hexfiler som innehåller en CRC32.

[TomasL]

Jo, naturligtvis finns det en uppsjö av filöverföringsprotokoll, men boot-rom är i regel inte så stort.
Gissar att ett vettigt sätt är att skicka en rad med programdata och någon form av vettig checksumma till processorn.

Krypteringen eller snarare dekrypteringen är nog den lättaste biten XTEA till exempel är tämligen enkel, funktionen ser ut så här:

Kod: Markera allt

void decipher(unsigned int num_rounds, uint32_t v[2], uint32_t const key[4]) {
    unsigned int i;
    uint32_t v0=v[0], v1=v[1], delta=0x9E3779B9, sum=delta*num_rounds;
    for (i=0; i < num_rounds; i++) {
        v1 -= (((v0 << 4) ^ (v0 >> 5)) + v0) ^ (sum + key[(sum>>11) & 3]);
        sum -= delta;
        v0 -= (((v1 << 4) ^ (v1 >> 5)) + v1) ^ (sum + key[sum & 3]);
    }
    v[0]=v0; v[1]=v1;
}

Det är allt.

Troligen får man skriva ett PC-program som plockar upp antingen ELF-Filen eller IntelHex-filen, avkodar denna, till en ren programavbild, krypterar den.
Ett annat PC-program ansluter till bootloadern, skickar det antal paket som behövs för en programmerings-rad samt checksumma.
För att förenkla det hela så kan man då använda fasta paketlängder, då man i förväg vet hur lång en rad är.
PC programmet måste ju också räkna ut adresser gissar jag så att bootloadern kan generera rätt interna adresser för sid-radering och rad-skrivning, alternativt så bakar man in dem i den befintliga program-binären redan när man skapar den.

[Nerre]

Filöverföringsprotokollen som användes på modem-tiden var ju inga monster, på den tiden var de flesta program små.

[bearing]

Slutet av varje rad i en intel hexfil är ju en checksumma. Tycker du inte att det är säkert nog?
Jag kan förstå din oro, för checksummor är ju inte helt säkra. Men har du varit med om att den flashade datan varit korrupt?

En CRC är säkrare, och ganska enkel att ordna.

[Icecap]

Om säkerheten är som i "dataöverföringen är felfri" är den säkraste metod ju att spara ett block i RAM och sedan ha en "riktig" checksum för det block. Är det OK kan det brännas in och nästa block kan tas emot. Då använder man en checksum som är mer avancerat än rad-checksummen men gärna båda samtidig, då borde säkerheten vara bra.

Om säkerheten är kryptering osv. kan det lösas på olika sätt, ett är att man ska logga in med ett serienummer som är behandlat på något vis. Misslyckas man 3 gg kan man enbart logga in med master-lösenord och då bara radera programminnet osv.

[sodjan]

Hela lösningen beror ju väldigt mycket på vad det är för pryl.
Många "embedded" prylar, speciellt om de är tänka att användas
av någon utan speciell teknisk kompetens, har både nerladdning
och uppdatering inbyggda. Så de kan hämta och uppdatera helt
självständigt. De flesta "TV-boxar" fungerar så, ibland tar det
bara lite längre tid att start p.g.a. någon ny uppdatering...

[opatagio]

Xmodem med CRC?