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. Die sind aber so unheimlich groß das die meinen RAM > Speicher sprengen. Vielleicht kann man hier ansetzen. Verwendest du bereits "-Os -ffunction-sections -fdata-sections", für möglichst kleinen Code und entfernen nicht verwendeter Funktionen? Was genau braucht denn da bei den Libs so unglaublich viel Speicher? Falls du eine alternative Implementierung für SHA1 brauchst hätte ich da noch eine: https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/headers/DPA/utils/crypto/sha1.h https://github.com/Daniel-Abrecht/DPA-UCS/blob/master/src/utils/crypto/sha1.c
Edit: habe noch "-Wl,-gc-sections" vergessen, ohne das ist "-ffunction-sections -fdata-sections" ziemlich nutzlos.
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.
Angehängte Dateien:
-
scatter.PNG
56 KB
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.
Fällt wie Schuppen von den Augen :) Das ist simpel und würde auf den ersten Blick seine Funktion erfüllen.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.