Bootloader + SD-Karte

Mach es anders:
Binde einen externen Speicherbaustein an, oder benütze einen Bereich auf 
der SD Karte, auf dem du im RAW Format zugreifst.
Die Firmware (entschlüsselt) liest die FW File, vergleicht Sie, ob die 
CRC,usw. stimmt und schreibt sie in den von dir definierten Speicher.
Anschliesend wird in den Bootloader gesprungen, der dann den Speicher in 
den Flash kopiert -> Fertig.

Hast du Probleme mit dem Platz im BL-Bereich? Wenn nicht, wirds 
komplizierter. Dinge über die nachgedacht werden muss:

- für die Funktionen brauchst du dann Pointer, die auf eine fixe Adresse 
im Flash zeigen. Linker muss genau wissen wo er die hinpackt. Verändert 
sich die Länge der Funktionen und sind die nahtlos hintereienander 
verlinkt, bekommt man Probleme, da sie nicht mehr da sind, wo die fixen 
Adressen hinzeigen.

- Kann der Controller gleichzeitig aufs Flash schreiben, während er das 
Programm ausführt (gleichzeitig lesender Zugriff)? Manche Controller 
verwenden zwei Bänke um genau das zu umgehen oder führen den Code aus 
dem RAM aus

- was ist mit den benötigten Interrupt-Vektoren?

Das gibt es sicher noch andere Dinge, die mir gerade nicht einfallen...

FW Update:
- Firmware liegt verschlüsselt auf der SD Karte
- Bootloader liesst blockweise von SD (z.B. 128 Bytes), entschlüsselt, 
und ruft eine Funktion auf, die den Block ins Flash schreibt (diese muss 
u.U. im RAM liegen)
Flash Algs verwenden idR. eine feste Blockgrösse, welche sich auf den 
Flash Vorgang abbildet. Dies könnte auch die Grösse für den Block 
(De-)Crypt sein.

Nutzen der Funktionen:
In deinem Bootloader liegt eine Tabelle an immer der gleichen Adresse, 
welche Function Pointer auf deine shared functions liegen  (ähnlich der 
Interrupt Vector Table). Wo dann die Funktionen selbst liegen, was sie 
aufrufen und wie gross die sind, ist für den späteren Verlauf egal.
Allerdings sollten sie nicht auf globale Daten zugreifen, wenn deine FW 
ein eigenes "startup" hat, da globale Daten im RAM vom Bootloader nach 
dem FW start nicht mehr gültig sind (neues ZI / load).

Random .. schrieb:

> Nutzen der Funktionen:
> In deinem Bootloader liegt eine Tabelle an immer der gleichen Adresse,
> welche Function Pointer auf deine shared functions liegen  (ähnlich der
> Interrupt Vector Table).

Die Tabelle sollte aber nicht im Bootloader Image liegen, sondern in dem 
Image, in dem die SD-Karten Funktionen liegen. Wenn das 
Applikations-Image und der Bootloader die Start-Adresse (Address der 
Tabelle) dieses Images kennen, können die dort die Adressen der 
Funktionen nachschlagen.

Billy _. schrieb:
> - für die Funktionen brauchst du dann Pointer, die auf eine fixe Adresse
> im Flash zeigen. Linker muss genau wissen wo er die hinpackt.

Und grade das ist extrem aufwändig beim Gnu LD von AVR-GCC, weil man dan 
ein komplexes Linkerskript hacken muss.

In der Praxis hättest Du dann 3 Teile:
 - Den SD Kartenzugriff
 - die eigentliche Applikation
 - den Bootloader

Und die sind dann auch nicht mehr unabhängig voneinander. Blöderweise 
will man den SD Zugriff aber manchmal updaten - sei es weil Karten 
exotische Fehlerzustände haben oder weil $Kunde SDXC mit ExFAT haben 
will.

Und der SD Zugriff dürfte dann auch keine Buildins wie memcpy() aufrufen 
- oder müsste eigene Kopien mitbringen. Die RAM Belegung ist dann auch 
ein interessantes Problem - die FAT Implementierungen hier haben alle 
irgendwelche Globals.

Witzigerweise hat aber grade das Default-Format einer SD(HC) Karte sehr 
viel Platz hinter dem Sektor 0 mit der Partitionstabelle - für eine AVR 
Firmware würde das locker reichen. Da kommt ein Luser ohne Admin Rechte 
unter Windoof nicht mal ran, wäre aber von einem Bootloader leicht 
auszulesen.

Olaf schrieb:
>> Kann man den Code für den SD-Karten Zugriff ebenfalls als eine Art
>> Image ab einer bestimmten Adresse in den Speicher schreiben
>> und vom Bootloader von von der FW auszugreifen und nutzen?
>
> Sowas kannst du selbstverstaendlich tun. Allerdings kann diese Section
> dann selber nicht mehr bei einem Firmwareupdate geaendert werden.

Du kannst eine Firmware installieren, die dann den Bootloader oder das 
SD-Image aktualisiert.

> Dann
> koennte man sie aber auch direkt in den Bootloader schreiben.

Klingt nach einer guten Idee.