Hi zusammen,
ich hab einen Bootloader und eine Application wie die meisten anderen
auch.
Das Ziel war es den Bootloader updatefähig zu gestalten. Die Idee und
die Umsetzung ist, dass man den Bootloader so klein wie den RAM Speicher
hält und diesen dann nach Neustart in den RAM lädt.
Jetzt verwende ich zur Verifizierung des Loaders libs aus der
Application. Die sind aber so unheimlich groß das die meinen RAM
Speicher sprengen.
Hab also zwei getrennte Projekte und zwei Scatterfiles(Bootloader und
App) die von einander nichts wissen. Damit handle ich mir automatisch
redundanten Code ein.
Kenn mich in den Möglichkeiten nicht so aus, aber gibt es einen Ansatz
bei dem ich den gemeinsamen Code nur einmal im Speicher hab und von
Application und Bootloader bei Bedarf drauf zugreife?
Danke
Noob schrieb:> Kenn mich in den Möglichkeiten nicht so aus, aber gibt es einen Ansatz> bei dem ich den gemeinsamen Code nur einmal im Speicher hab und von> Application und Bootloader bei Bedarf drauf zugreife?
Ja.
Nur schreiben ins Flash muss von der Bootloader section erfolgen.
Um welchen Controller geht es denn?
Du kannst ja nur die Funktionen in den RAM laden welche für das kopieren
zuständig ist und dann den Flash als Zwischen Speicher missbrauchen.
Oder du baust dir einen mehr Stufigen Bootloader der im ersten Teil nur
eine Überprüfung macht was er machen soll der immer fest bleibt und
nicht aktualisiert werden muss.
Der 2te nimmt dann dein Binary endgegen speichert ihn im Flash und
startet aus dem ersten dann das Update.
Da du die libs vermutlich auch aktualisiert haben möchtest wird es nicht
funktionieren diese für beide Programme zu verwenden.
Sei kreativ.
Wenn Du Code der Applikation im Bootloader nutzen willst, bedeutet das
dass die erste Applikation nicht per Bootloader auf das Gerät kommen
kann.
Andererseits könnte man sich aber einen Rumpfbootloader vorstellen, der
ein paar Bibliotheksroutinen bereit stellt. Wenn ein Update der
Applikation angesagt ist, empfängt der Rumpfbootloader erstmal den Rest
des Bootloaders, schreibt diesen in's Ram und startet ihn. Der Code im
Ram kann dann auf die Bibliotheksroutinen zugreifen, um selber kleiner
zu sein. Oder eben auch nicht, wenn in der Bibliothek ein Fehler steckt.
Noob schrieb:> Jetzt verwende ich zur Verifizierung des Loaders libs aus der> Application.
Dann hast Du ein Henn-Ei-Problem. Die Henne kann auf das Ei nicht
zugreifen, da sie es erst ja noch legen muß.
Der Bootloader muß immer für sich allein lauffähig sein!
Es kann ja beim Updaten der Applikation das Problem auftreten, daß der
Bootloader die Applikation zwar löschen konnte, aber beim neu
Programmieren ein Fehler auftrat oder die neue Applikation schlichtweg
buggy ist.
Bestenfalls kann die Applikation auf ein API des Bootloaders zugreifen,
aber niemals umgekehrt.
Daß ein Bootloader sich ins RAM kopiert, um sich selber löschen zu
können, klingt ziemlich gefährlich und ist es auch in der Praxis.
Peter D. schrieb:> Bestenfalls kann die Applikation auf ein API des Bootloaders zugreifen,> aber niemals umgekehrt.
Hmmm, niemals ?
Das Problem dabei könnte sein, dass der Bootloader versucht, auf ein
API zuzugreifen, welches sich nicht auf dieser Adresse befindet.
In diesem speziellen Fall aber könnte sich der Bootloader darauf
verlassen, dass benötigte APIs sich auf festgelegten Adressen
befinden (CRC etc.).
Frage ist nämlich, warum der Bootloader überhaupt auf Applikation-
Routinen zugreifen soll (und muss) ?
Umgekehrt könnte das schon eher der Fall sein, aber was könnte die
Applikation dadurch überhaupt gross sparen und vor allem warum?
> Der Bootloader muß immer für sich allein lauffähig sein!
Genau.
Und sollte schnell, klein und sicher sein.
Wann muss man schonmal den Bootloader Updaten? Wenn ich meinen (PIC)
Bootloader updaten will, lade ich einen temporären, 2.Bootloader als
Applikation, der dann wiederum den Bootloader im original-Adressbereich
(als "seine" Applikation) lädt. Der eine oder andere Bootloader ist,
wenn er erstmal erfolgreich als App geladen wurde, immer eigenständig
lauffähig.
Noob schrieb:> Kenn mich in den Möglichkeiten nicht so aus, aber gibt es einen Ansatz> bei dem ich den gemeinsamen Code nur einmal im Speicher hab und von> Application und Bootloader bei Bedarf drauf zugreife?
Im Prinzip ja.
Aber dazu müßtest du dir Gedanken machen über die Architektur deines
Chips.
Bei der Lernbetty (ARM7TDMI) hatte ich das so gemacht, daß es eine
BettyBase gibt, die quasi als Betriebssystem fungiert und über SVC's von
den Apps angesprochen wird.
So ähnlich müßtest du es ebenfalls halten, also dein ganzes Zeug sauber
aufteilen in einen fest im Chip bleibenden Teil, quasi ein
Mini-Betriebssystem, einen in den RAM ladbaren Bootlader (der auf dieses
BS zurückgreift) und ladbare Apps, die ebenfalls auf das BS
zurückgreifen.
Wie du die Schnittstelle zwischen Apps und Bootlader einerseits und BS
andererseits gestaltest, ist hardwareabhängig und auch compilerabhängig.
Der GCC zum Beispiel (falls du mit einem ARM arbeiten solltest) kann
keine SVC's, da wäre ein Assembler-Wrapper dafür angesagt und das gibt
in diesem Falle schlechten Code.
W.S.
W.S. schrieb:> ist hardwareabhängig und auch compilerabhängig.
-Sobald ein Compiler zum Einsatz kommt, kann auch viel unnützes Zeug mit
geladen werden, was zusätzlichen Platz benötigt...
-Ein 2.Rettungs-Boot wäre auch nützlich, falls das 1. Bootsystem
totgepatcht wurde oder Spannungsausfall?
oszi40 schrieb:> Ein 2.Rettungs-Boot
Ach wo, sofern der eigentliche Kaltstart und Bootlader vernünftig
konzipiert worden sind.
Aber das hier ist alles nur heiße Luft, solange die eigentliche HW
unbekannt bleibt.
W.S.
So ist der Aufbau bei mir...
wobei das erste(Bootloader) Programm in der Lage ist das
zweite(Anwendung) zu aktualisieren. Damit sich das erste bei bedarf(im
Nontfall) auch selbst aktualieren kann lädt sich der Bootloader in den
RAM um sich zu überschreiben.
Im groben haben beide ein Betriebsystem, ein FileSystem, und eine
CryptoEinheit. Letztere bringt das Fass zum überlaufen.
Als Noob und ohne tieferes Verständnis dacht ich. Das ich ein drittes
Programm (CryptoEinheit) haben könnte, dass ich irgendwie ansprechen
hätte können.
Thomas E. schrieb:> Wann muss man schonmal den Bootloader Updaten? Wenn ich meinen (PIC)> Bootloader updaten will, lade ich einen temporären, 2.Bootloader als> Applikation, der dann wiederum den Bootloader im original-Adressbereich> (als "seine" Applikation) lädt. Der eine oder andere Bootloader ist,> wenn er erstmal erfolgreich als App geladen wurde, immer eigenständig> lauffähig.Noob schrieb:> Fällt wie Schuppen von den Augen :)>> Das ist simpel und würde auf den ersten Blick seine Funktion erfüllen.
Danke Thomas
