Hallo, ich habe den Bootloader: http://www.mikrocontroller.net/articles/AVR_Bootloader_in_C_-_eine_einfache_Anleitung nachempfunden und für meine Zwecke für einen ATmega8 angepasst. Das Anwendungsprogramm beginnt wie üblich bei 0x0000 und der Bootloader beginnt bei 0x1800. Vom Anwendungsprogramm kann durch eine simple Abfrage via UART zum Bootloader gesprungen werden. Via UART wird dann der Inhalt des .hex files empfangen und das neue Anwendungsprogramm in den Flash-Speicher ab Adresse 0x0000 geschrieben. Das alles funktioniert hervorragend, doch jetzt kommt meine einfache Frage: Wenn bei der Übertragung der .hex File Daten ein Fehler aufgetreten ist und schon einige Pages geflashed wurden, ist das Anwendungsprogramm ab 0x0000 zerstört und es gibt nominal keine Möglichkeit mehr, den Bootloader wieder anzuschmeißen. Zwar kann ich in diesem Fehlerfall mittels AVR Studio und dem Atmel AVRISP mkII Programmer das Anwendungsprogramm via ISP wieder flashen, aber damit ist die eigentliche Strategie des Bootloader ab adsurdum geführt worden. Welche Möglichkeiten seht ihr, dieses Problem eleganter zu lösen ?
Nicht dass ich mal was mit einem Bootloader gemacht hätte, aber ist der Sinn dahinter nicht, beim Start des uC als erstes ausgeführt zu werden? Deswegen heißt er doch auch so? Das müsste er doch auch tun wenn im Programmspeicher davor nur Kauderwelsch steht. Ansonsten wäre das ganze tatsächlich relativ witzlos.
:
Bearbeitet durch User
Manfred L. schrieb: > [... > Welche Möglichkeiten seht ihr, dieses Problem eleganter zu lösen ? Benutzung der BOOTRST-Fuse. Dann wird immer zuerst der Bootloader gestartet, und der kann/darf/muss dann entscheiden, ob er was bootloaden will oder das Anwenderprogramm starten. So macht man das üblicherweise. HTH Baku
Man springt immer in den Bootloader. Der testet ob das Programm gueltig ist, und fuehrt das dann aus. Falls nicht bleibt er auf Empfang. Bedeutet beim hochladen des Programmes wird am Schluss auf Vollstaendigkeit gerueft und die zu testende Pruefsumme reingeschrieben. Dann zB nocmal ein Byte, das sagt : ok.
Purzel schrieb: > Man springt immer in den Bootloader. Der testet ob das Programm gueltig > ist, und fuehrt das dann aus. Falls nicht bleibt er auf Empfang. Bestimmt nicht, mal abgesehen davon, dass er das gar nicht prüfen kann. > Bedeutet beim hochladen des Programmes wird am Schluss auf > Vollstaendigkeit gerueft und die zu testende Pruefsumme reingeschrieben. > Dann zB nocmal ein Byte, das sagt : ok. Nein, wofür soll das gut sein? Wie kann ein Bootloader wissen, ob ein Programm nicht selbst irgendwelche Werte in den Flash schreibt und somit die Prüfsumme nicht mehr stimmt?
:
Bearbeitet durch User
Ganz einfach. Weil der Bereich der Pruefsumme natuerlich nicht vom Programm beschrieben wird. Vielleicht kann man den Programmbereich ja auch fuer das Programm schreibschuetzen.
Manfred L. schrieb: > Wenn bei der Übertragung der .hex File Daten ein Fehler aufgetreten ist > und schon einige Pages geflashed wurden, ist das Anwendungsprogramm ab > 0x0000 zerstört und es gibt nominal keine Möglichkeit mehr, den > Bootloader wieder anzuschmeißen. Doch, natürlich. Der Bootloader liegt ja im geschützten Bereich und kann sich nicht selbst überschreiben. Auch mit zerschossenem oder nur halb geflashtem Anwendungsprogramm wird der Bootloader nach wie vor funktionieren und kann z.B. eine neue Firmware flashen. > Welche Möglichkeiten seht ihr, dieses Problem eleganter zu lösen ? 1. den Bootloader per FUSE vor dem Überschreiben schützen 2. nach dem RESET immer in den Bootloader springen Wie genau man das jetzt handhabt, ob und wann der Bootloader das Programm startet, dazu gibt es viele Möglichkeiten. Welche davon praktikabel ist, hängt von Randbedingungen ab, bspw. ob es eine Möglichkeit zur Kommunikation oder zumindest Signalisierung gibt. Natürlich könnte der Bootloader eine Prüfsumme der Firmware checken und bei ungültiger Prüfsumme weiter in der Warteschleife bleiben. Aber wenn er das nicht signalisieren kann, sieht es von außen genauso aus als wäre die Firmware abgestürzt.
Jetzt ist G. schrieb: > Ganz einfach. Weil der Bereich der Pruefsumme natuerlich nicht vom > Programm beschrieben wird. So etwas ist natürlich nicht akzeptabel - Bootloader kann mir bzw. dem Programm nicht vorschreiben wo was geschrieben wird und ob. > Vielleicht kann man den Programmbereich ja > auch fuer das Programm schreibschuetzen. Das ist ja noch schlimmer. Ein Bootloader ist nur dazu da, um Programme zu flashen - nix Programmbereiche vorschreiben, nix je nach Checksum bestimmte Entscheidungen treffen.
Irgendwie hast Du die Idee von solchen Bootloadern nicht verstanden.
Ben B. schrieb: > Irgendwie hast Du die Idee von solchen Bootloadern nicht verstanden. Ich glaube du bist derjenige, der das nicht verstanden hat. Bootloader darf nur gerade geflashtes Programm (also virgin) prüfen und dazu bedarf es natürlich keinen Checksum weil das Byte für Byte verglichen wird. Alles andere ist Blödsinn.
:
Bearbeitet durch User
Der Bootloader muss das anzusprigende Program pruefen koennen. Daher muss ein Statusbyte da sein, das besagt, dass das Programm gut ist, und er muss irgendwie signalisieren koennen wenn etwas nicht gut ist. Der Bootloader darf kein unvollstaendig geflaschtes Programm anspringen. Denn sonst ist die Funktionalitaet des Geraetes unzuverlaessig. Nun aber, ..weg mit dem Troll.
Aha. Und was spricht gegen ein wenig zusätzliche Intelligenz wie z.B. das im Flash gespeicherte Programm beim Start des Controllers zu verifizieren bevor es gestartet wird? Man könnte auch je nach Menge an freiem Flash eine Kopie der ersten Version des Hauptprogramms im Flash ablegen und falls beim Flashen was schiefgeht, kann der Bootloader dieses Programm in den Flash kopieren. Dadurch geht die Funktionsfähigkeit des Geräts nicht verloren und der User hat eine zweite Chance, auf eine andere/neuere Firmware zu flashen. Das einzige Problem entsteht, wenn ein fehlerhaftes Programm nicht als fehlerhaft erkannt wird und beim Start crasht. Ich würde bei allen meinen Projekten einen extra Pin zur Steuerung des Bootloaders reservieren, wo man entweder eine LED dranhängen kann oder z.B. durch Festlegen dieses Pins auf Masse einen Flash-Vorgang forcieren kann.
Jetzt ist G. schrieb: > Der Bootloader darf kein unvollstaendig geflaschtes Programm anspringen. > Denn sonst ist die Funktionalitaet des Geraetes unzuverlaessig. > > Nun aber, ..weg mit dem Troll. Ja, aber geh nicht gleich ganz weg, bleib noch ein bisschen um etwas zu lernen, vielleicht zu lesen: Marc V. schrieb: > Bootloader darf nur gerade geflashtes Programm (also virgin) > prüfen und dazu bedarf es natürlich keinen Checksum weil das > Byte für Byte verglichen wird.
Marc V. schrieb: > Jetzt ist G. schrieb: >> Ganz einfach. Weil der Bereich der Pruefsumme natuerlich nicht vom >> Programm beschrieben wird. > So etwas ist natürlich nicht akzeptabel - Bootloader kann mir bzw. > dem Programm nicht vorschreiben wo was geschrieben wird und ob. > Nun ja - selbstmodifizierende Programme sind zwar in VN basierten Prozessoren und vielen Anderen (z.B. manche Harvard basierten Prozessoren) möglich, werden aber aus vielen Gründen heutzutage als kein guter Programmierstil angesehen, und ich habe in meinen > 20 Jahren Embedded Erfahrung noch kein Exemplar davon gesehen. Hingegen ist der hier mehrfach beschriebene (meist residente) BL sehr verbreitet, der - nach Reset immer als erstes angesprungen wird - als erste Amtshandlung ein gültiges Programm im Applikationsspeicher prüft und dann - (bei gültiger Applikation) dessen Einstiegspunkt anspringt, ansonsten im geschützten Modus bleibt, in dem er nicht mehr kann als mit einem neuen Programm versehen zu werden. Natürlich sind in solchen Architekturen Vorgaben an das Speicherlayout erforderlich. Das heisst nicht, dass diese Architektur das Mass der Dinge ist, aber so weit verbreitet wie sie ist kann sie auch nicht so schlecht sein. Viele Cortex Prozessoren unterstützen darüber hinaus auch noch einen Mix, also einen wirklich residenten BL in einem komplett isolierten Bereich, der nur durch Jumpern o.ä. beim Booten angesprungen werden kann sowie einen in BL und Applikation aufgeteilten Flashbereich. Es gibt auch Andere PODs, die gebanktes Flash unterstützen, d.h. durch Software gestuert kann der Reset aus der einen oder anderen Bank erfolgen. Das ist ganz genau eine Anwendung für einen immer involvierten BL, d.h. wenn ein gültiges Programm in Bank A ist, kann der BL in Bank A ein Image empfangen, in Bank B schreiben, verifizieren, dann ein Bit im Prozessor toggeln, durch das von B gebootet wird, und einen Reset verursachen. Sehr viele Flashbausteine haben darüber hinaus ein asymmetrisches Blocklayout, in dem ein dedizierter Block als Bootblock deklariert ist (in der Regel ist dort auch der Einstiegspunkt für den Resetvektor) und besondere Eigenschaften hat. Warum sollte es all so Dinge geben, wenn das nicht akzeptabel wäre? >> Vielleicht kann man den Programmbereich ja >> auch fuer das Programm schreibschuetzen. > > Das ist ja noch schlimmer. > Ein Bootloader ist nur dazu da, um Programme zu flashen - nix > Programmbereiche vorschreiben, nix je nach Checksum bestimmte > Entscheidungen treffen. Siehe oben. Das Problem mit einem "nur virgin flash Bootloader" besteht darin, dass Vor Ort Anwesenheit am Gerät erforderlich ist, um eine FW aufzuspielen. Das ist in vielen Anwendungen nicht genügend und in vielen Anderen gar nicht möglich, weil die Geräte gar nicht vor Ort erreichbar sind, also remote upgegraded werden können müssen. In solchen Fällen sehe ich gar keine Andere Möglichkeit, als dass der BL nach Reset als Allererstes angesprungen wird. Ob er selbstmodifizierende Programme unterstützt oder nicht, ist dann eine Detailfrage.
Ben B. schrieb: > Aha. Und was spricht gegen ein wenig zusätzliche Intelligenz wie z.B. > das im Flash gespeicherte Programm beim Start des Controllers zu > verifizieren bevor es gestartet wird? Aha. Und womit willst du Bootloader auf Richtigkeit prüfen? Bootloader dient nur dazu, flashen zu vereinfachen und hat/soll sonst keine zusätzlichen Funktionen haben, wozu auch? Genauso wie ein Programm einen Fehler haben kann, kann dies auch beim Bootloader passieren. Und dann noch zusätzlich einen Prüfprogramm irgendwo im Flash verstecken? Blödsinn.
Der Bootloader wird einmal geflasht und danach nicht mehr angefasst. Dann kann man den auch nicht zerschießen und ich sehe keinen Grund, warum er (intakten Controller vorausgesetzt) fehlerhaft werden sollte. Genau wie das im Zweifel doppelt abgelegte Hauptprogramm. Wenn da Programmierfehler drin sind, dann ist das halt so. Das ist halt die erste Version und wenn beim Update was schiefgeht, muß das Update eben wiederholt werden. Ich find das besser, als ein neues Gerät kaufen zu müssen weil nach dem Crash kein Update mehr möglich ist.
Ruediger A. schrieb: > Nun ja - selbstmodifizierende Programme sind zwar in VN basierten > Prozessoren und vielen Anderen (z.B. manche Harvard basierten > Prozessoren) möglich, werden aber aus vielen Gründen heutzutage als kein > guter Programmierstil angesehen, und ich habe in meinen > 20 Jahren > Embedded Erfahrung noch kein Exemplar davon gesehen. Tja, Erfahrung ist nicht gleich Erfahrung. Wir haben das letztlich mit RFID gemacht und zwar sind Mastertags alle im Flash, es können natürlich neue dazukommen oder verlorene können gelöscht werden. Aber beim ersten flashen sind die Nummern bekannt und werden ins Flash gebrannt. Normale Tags werden natürlich im EEPROM festgehalten. > Siehe oben. Das Problem mit einem "nur virgin flash Bootloader" besteht > darin, dass Vor Ort Anwesenheit am Gerät erforderlich ist, um eine FW > aufzuspielen. Nein, das ist natürlich nicht erforderlich und hat mit der geforderten Fähigkeit, einen Programm durch den Bootloader vor dem Start zu prüfen, nichts zu tun. Ein normaler Bootloader wartet eine gewisse Zeit auf ein vorher festgelegtes Zeichen, falls dieses nicht kommt, wird zum Flashbegin gesprungen. Wenn kein Programm existiert, geht es normalerweise durch NOP's wieder zum Bootloader und so bis in alle Ewigkeit oder bis das Zeichen kommt. > In solchen Fällen > sehe ich gar keine Andere Möglichkeit, als dass der BL nach Reset als > Allererstes angesprungen wird. Ein Bootloader wird sowohl beim Kalt- als auch beim Warmstart immer als Allererstes angesprungen, deswegen heisst er wohl auch Bootloader. > Ob er selbstmodifizierende Programme > unterstützt oder nicht, ist dann eine Detailfrage. Das ist keine Detailfrage, das ist eine Frage des Konzepts und der Sinn(losigkeit) einer solchen Möglichkeit. Ein Bootloader kann nicht wissen ob sich gewisse Flashbereiche mit Absicht oder durch Fehler geändert haben, es ist nicht seine Aufgabe und war es niemals. Ausserdem: Genauso wie gewisse Programmteile unabsichtlich zerschossen werden können, kann das auch mit CRC/Checksum passieren. Somit kann ein normal funktionierendes Programm mit fehlerhaftem CRC/CS von Bootloader als nicht funktionierend bezeichnet werden. Und dann? Leute, lass es sein, mit Gewalt etwas beweisen zu wollen, was ganz einfach nicht so ist... P.S. Zeigt mir einen BL der Programme (außer gleich nach dem Flashen) auf Richtigkeit prüft.
:
Bearbeitet durch User
Marc V. schrieb: > Ben B. schrieb: >> Aha. Und was spricht gegen ein wenig zusätzliche Intelligenz wie z.B. >> das im Flash gespeicherte Programm beim Start des Controllers zu >> verifizieren bevor es gestartet wird? > > Aha. Und womit willst du Bootloader auf Richtigkeit prüfen? Ich nehme an, du meinst "womit willst du im Bootloader ..."? Antwort: to be defined. Darüber müssen sich der Programmierer des Bootloaders und der Programmierer der Anwendung verständigen. Was bei einem custom Bootloader natürlich trivial ist (beides kommt aus einer Hand). Und bei einem fremden Bootloader ist das einfach ein Teil der Spezifikation. Da sind ja eine Menge Dinge zu spezifizieren. Schnittstellenparameter, das Format der Firmware, etc. pp. > Bootloader dient nur dazu, flashen zu vereinfachen und hat/soll sonst > keine zusätzlichen Funktionen haben, wozu auch? Komisch. ich dachte wir reden die ganze Zeit davon, daß es praktisch und nützlich ist, wenn der Bootloader entscheiden kann, ob er gültige Firmware im Flash hat oder nur Schrott. > Blödsinn. Was du für sinnvolle Funktionalität in einem Bootloader hältst und was nicht, ist allein deine Meinung. Die darfst du gerne haben. Aber du solltest sie nicht anderen aufdrücken als wäre sie ein Gesetz.
Marc V. schrieb: > Zeigt mir einen BL der Programme (außer gleich nach dem Flashen) > auf Richtigkeit prüft. Meiner: http://www.picalic.de/projects/bootloader/bootloader.html
Niemand kann mir verbieten einen Bootloader zu schreiben, der vor der Ausführung des eigentlichen Programms eine Prüfsumme berechnet. Wenn mein Programm sich selber modifiziert, passe ich meinen Bootloader entsprechend an, so dass auch hier die Prüfung noch funktioniert. Ich will ja ein garantiert laufendes Programm haben. Wenn es nicht (mehr) korrekt ist, soll das System nicht loslaufen. Ich könnte ja auch einen Bootloader schreiben, der bei Erkennung eines fehlerhaften Programms eine lauffähige Variante aus dem "Netz" läd und ins Flash schreibt. Das ist kein Blödsinn, denn ich will es so haben.
Mal eine Frage am Rande, wer bitte schreibt denn selbstmodifizierenden Programmcode auf Flash-basierten Controllern?! Weils cool ist, einfach weil man's kann, weil diese Möglichkeiten des Controllers genutzt werden müssen? Auf einem RAM-basierten System kann ich's ja verstehen, aber doch bitte nicht bei Flash mit seiner begrenzten Lebensdauer. Und die meisten Systeme wie der x86 z.B. verbieten das auch immer mehr.
Thomas E. schrieb: > Marc V. schrieb: >> Zeigt mir einen BL der Programme (außer gleich nach dem Flashen) >> auf Richtigkeit prüft. > > Meiner: > http://www.picalic.de/projects/bootloader/bootloader.html Christian H. schrieb: > Niemand kann mir verbieten einen Bootloader zu schreiben, der vor der > Ausführung des eigentlichen Programms eine Prüfsumme berechnet. Wenn > mein Programm sich selber modifiziert, passe ich meinen Bootloader > entsprechend an, so dass auch hier die Prüfung noch funktioniert. Ihr könnt in ihren eigenen Bootloadern Sommer- und Winterzeit einbauen, eure Sache. Ob das sinnvoll ist, ist etwas anderes aber immer noch eure Sache.
Ben B. schrieb: > Mal eine Frage am Rande, wer bitte schreibt denn selbstmodifizierenden > Programmcode auf Flash-basierten Controllern?! Weils cool ist, einfach Wer lesen kann (und will) ist klar im Vorteil. Daten, die sich ev. verändern können im Flash zu halten und Programme, die sich selbst modifizieren sind 2 paar Schuhe.
:
Bearbeitet durch User
Noch nie was von einem EEPROM gehört, wo man sich verändernde Daten unabhängig vom Programm ablegen kann?
Manfred L. schrieb: > Wenn bei der Übertragung der .hex File Daten ein Fehler aufgetreten ist > und schon einige Pages geflashed wurden, ist das Anwendungsprogramm ab > 0x0000 zerstört und es gibt nominal keine Möglichkeit mehr, den > Bootloader wieder anzuschmeißen. Wenn du ein fehlerhaftes Programm geflashed hast, weil der Bootloader "es nicht bemerkt hat", dann bleibt dir natürlich nur der Resetknopf! Wenn du in einer schwierigen Arbeitsumgebung flashen/updaten mußt und du deshalb mit Übertragungsfehlern rechnest, mußt du halt "was Schlaues" in Bootloader und/oder Programm einbauen. Einige Vorschläge bzw. Beispiele wurden ja schon genannt. Die Beantwortung der rein akademische Frage, wie man sich vor nicht funktionierenden Programmen (aus welchem Grund auch immer) schützen kann, wird wohl den Rahmen dieses Forums sprengen... Gruß Rainer
Hmmm die meisten kleinen Controller haben nicht genug RAM, um ein übertragenes Programm vollständig im RAM zu halten und es erst nach Überprüfung zu flashen. Sprich wenn da etwas schiefgeht, flasht man definitiv ein kaputtes Programm und der Bootloader kann nichts weiter machen, als eine Meldung Hey ist scheiße gelaufen, mach bitte nochmal. Okay, er KANN das kaputte Programm auch einfach anspringen und das Ding zur Hölle schicken... sollte man aber nicht tun, weil z.B. durch Falschkonfiguration der Pins auch Hardwareschäden entstehen können.
Beitrag #5575973 wurde von einem Moderator gelöscht.
Mir ist einfach die Notwendigkeit für selbstmodifiziernden Programmcode nicht klar.
Ben B. schrieb: > Mir ist einfach die Notwendigkeit für selbstmodifiziernden Programmcode > nicht klar. Hat ja auch rein gar nichts mit dem Thema zu tun! Gruß Rainer
Ben B. schrieb: > Hmmm die meisten kleinen Controller haben nicht genug RAM, um ein > übertragenes Programm vollständig im RAM zu halten und es erst nach > Überprüfung zu flashen. Sprich wenn da etwas schiefgeht, flasht man > definitiv ein kaputtes Programm und der Bootloader kann nichts weiter > machen, als eine Meldung Hey ist scheiße gelaufen, mach bitte nochmal. > Okay, er KANN das kaputte Programm auch einfach anspringen und das Ding > zur Hölle schicken... sollte man aber nicht tun, weil z.B. durch > Falschkonfiguration der Pins auch Hardwareschäden entstehen können. Jo, ganz genau. Auch deswegen nicht, weil so ein Programm einen Dauerreset verursachen kann*, und damit ist das Gerät gar nicht mehr erreichbar. In sofern kann ein applikationsverifizierender Bootloader auch zur Stabilität beitragen: Wenn keine konsistente Applikation geladen ist, bleibt der BL im Standalone Modus, und damit hat man immer noch die Möglichkeit, ihm eine neue passende Firmware mitzugeben. Was dann natürlich die Frage aufwirft, ob es auch legitim sein kann, einen Bootloader selber upzugraden. Wenn nicht, lässt er sich in den allermeisten Fällen so schützen, dass das gesicherte Hochfahren (von Hardware failures angesehen) garantiert ist. *Ja. Natürlich kann auch eine konsistente Applikation Dauerresets verursachen, aber durch einen verifizierenden Bootloader kann man wenigstens von so Dingen wie fehlgeschlagene oder unterbrochene Downloads recovern.
Ben B. schrieb: > Mir ist einfach die Notwendigkeit für selbstmodifiziernden Programmcode > nicht klar. Es geht hier auch nicht um den Programmcode selbst, sondern eher um (initiale) Daten, die zusammen mit dem Programmcode abgelegt werden, und die ggf. tatsächlich auch mal vom Programm selbst geändert werden können. Bei den PICs, für die mein Bootloader gedacht ist, gibt es auch welche ohne EEPROM, bei denen aber ein Teil des Programm-Flashs auf eine größere Zahl von Löschzyklen ausgelegt ist. Dieser Teil des Flashs wird dann ggf. als EEPROM-Ersatz verwendet. Solche Sachen müssen durch Eingrenzung der Prüfsumme auf den reinen Programmcode statt einfach über das ganze Flash berücksichtigt werden. Eine evtl. Prüfung dieser Daten sollte dann natürlich nicht vom Bootloader, sondern vom Applikationsprogramm selbst durchgeführt werden.
:
Bearbeitet durch User
Thomas E. schrieb: > Ben B. schrieb: >> Mir ist einfach die Notwendigkeit für selbstmodifiziernden Programmcode >> nicht klar. > > Es geht hier auch nicht um den Programmcode selbst, sondern eher um > (initiale) Daten, die zusammen mit dem Programmcode abgelegt werden, und > die ggf. tatsächlich auch mal vom Programm selbst geändert werden. Bei > den PICs, für die mein Bootloader gedacht ist, gibt es auch welche ohne > EEPROM, bei denen aber ein Teil des Programm-Flashs auf eine größere > Zahl von Löschzyklen ausgelegt ist. Dieser Teil des Flashs wird dann > ggf. als EEPROM-Ersatz verwendet. Solche Sachen müssen natürlich durch > Eingrenzung der Prüfsumme auf den reinen Programmcode statt einfach über > das ganze Flash berücksichtigt werden. Eine evtl. Prüfung dieser Daten > sollte dann natürlich nicht vom Bootloader, sondern vom > Applikationsprogramm selbst durchgeführt werden. Naja, diese Diskussionen gehen nun vermutlich etwas zu weit, aber es hat schon vorher Jemand angemerkt, dass diese Daten (die natürlich auch im selben Flash resident sein dürfen wie der Programmcode) per linker command skript in einem anderen Block als der Programmcode gelegt werden sollten. Denn ansonsten muss ja bei der Manipulation der Daten damit gerechnet werden, dass Teile des Programmcodes mit gelöscht werden. Es können auch so Sachen passieren wie dass der Code, der das Flash beschreibt, durch Verschiebungen im Layout im selben Block wie die zu schreibenden Daten liegen, und da ein Flashblock immer als Gesamtes gelöscht werden muss, bevor Teile von ihm neu geschrieben werden können, führt dieses Szenario leicht zu komplett zerschossenen Angelegenheiten. Bei meinen Kunden gibt es für Code und Daten geteilte Flashes in der Tat häufiger, aber das gemeinsame Residieren von Programmcode und Daten im selben Flashblock ist überall ein totales Nono. Die Grenze wird dort immer auf die Grenze zwischen zwei Flashblocks gelegt, und damit wäre eine Prüfsumme auch wieder legitim und konsistent.
Axel S. schrieb: > Doch, natürlich. Der Bootloader liegt ja im geschützten Bereich und kann > sich nicht selbst überschreiben. Natürlich kann sich auch ein Bootloader selbst überschreiben. Es hängt einzig von der Intelligenz seines Programmierers ab, ob bei dieser Operation am Ende ein sinnvolles Ergebnis herauskommt... Übrigens: einen "geschützten" Bereich gibt es auch nicht wirklich (wenn man mal die Sachen mit den Lock-Bits mal außen vor läßt). Bei den Megas gibt es (ohne Lock-Bits) nur den Unterschied zwischen RWW- und NRWW-Flash, wobei der Bootloader typisch im NRWW-Bereich liegt und die Applikation im RWW-Bereich. Bei den Tinys hingegen ist einfach alles NRWW. Allein aus letzterer Tatsache kann schon jeder allein unter Anwendung formaler Logik ersehen, das es 1) keinen wirklich geschützten Bereich gibt und 2) der Bootloader sich offensichtlich auch selber überschreiben kann, zumindest prinzipiell, da er ja auf Tinys die Anwendung überschreiben kann, die wie er selber dort zwingend im NRWW liegt, weil es dort einfach keinen RWW-Flash gibt... Und tatsächlich ist das auch so, bei den Megas genauso wie bei den Tinys. Diese RWW-Geschichte bei den Megas vereinfacht es nur, komplexe (und schnelle) Bootloader für Applikationen zu schreiben. Mehr steckt da nicht hinter, insbesondere keinerlei Schutzfunktionalität.
Thomas E. schrieb: > Marc V. schrieb: >> Zeigt mir einen BL der Programme (außer gleich nach dem Flashen) >> auf Richtigkeit prüft. > > Meiner: > http://www.picalic.de/projects/bootloader/bootloader.html Oder der doch hin und wieder eingesetzte U-Boot wenn dort ein uImage verwendet wird. Bei einem etwas mehr als primitiven Bootloader wird das auch eher die Regel sein als die Ausnahme.
Μαtthias W. schrieb: > Bei einem etwas mehr als primitiven Bootloader wird das > auch eher die Regel sein als die Ausnahme. Ich hätte hier auch noch den Bootloader aus den Produkten meines Arbeitgebers veröffentlichen können, der neben der Prüfung der Applikation auf Gültigkeit (bzw. gegen unerlaubte Veränderungen des Codes) noch andere "blödsinnige" Dinge wie Kopierschutz durch Verschlüsselung macht. Aber danach hätte ich alle Leser dieses Forums erschießen müssen! ;)
:
Bearbeitet durch User
c-hater schrieb: > Natürlich kann sich auch ein Bootloader selbst überschreiben. > Übrigens: einen "geschützten" Bereich gibt es auch nicht wirklich > > Bei den Megas... > Bei den Tinys... > Und tatsächlich ist das auch so, bei den Megas genauso wie bei den > Tinys. Aha! Wer hat eigentlich gesagt, daß es hier um Atmel Controller geht? Kann es eventuell sein, daß irgendwo auf der Welt noch andere Prozessorarchitekturen existieren?
cpuser schrieb: > Kann es eventuell sein, daß irgendwo auf der Welt noch andere > Prozessorarchitekturen existieren? ...und was soll das nun wieder??? Ich sagte doch schon, dass eine umfassende Diskussion der Thematik den Rahmen des Forums sprengen wird...natürlich würde mich auch brennend interessieren, wie z.B. die Weltraumleute an das Thema herangehen :-) Schönen Abend noch, Rainer
cpuser schrieb: > c-hater schrieb: > >> Natürlich kann sich auch ein Bootloader selbst überschreiben. >> Übrigens: einen "geschützten" Bereich gibt es auch nicht wirklich >> >> Bei den Megas... >> Bei den Tinys... >> Und tatsächlich ist das auch so, bei den Megas genauso wie bei den >> Tinys. > > Aha! Wer hat eigentlich gesagt, daß es hier um Atmel Controller geht? Tatsächlich erwähnt das Eröffnugsposting explizit den ATMega8. Und der hat Fuses, um den Bootloader vor dem Überschreiben zu schützen. Genau deswegen habe ich das ja geschrieben. Und ja, im Normalfall will man das genauso haben, daß weder die Firmware noch der Bootloader selber den Bootloader überschreiben kann. Andere µC bieten mehr, andere weniger. Aber wenn man mit Bootloader arbeiten will oder muß, dann tut man gut daran, einen µC mit gutem Support für Bootloader zu verwenden. Ist ja nicht so, daß man keine Auswahl hätte.
:
Bearbeitet durch User
Beitrag #5576346 wurde von einem Moderator gelöscht.
Beitrag #5576459 wurde von einem Moderator gelöscht.
Lass gut sein, Marc zeigt mal wieder seine vollständige Abwesenheit von Wissen gepaart mit Selbstüber- und Fremdunterschätzung. Marc V. schrieb: > Zeigt mir einen BL der Programme (außer gleich nach dem Flashen) > auf Richtigkeit prüft. UEFI macht Verifikation und Kryptographie, passendes Stichwort wäre "Secure Boot". Gibt es auch auf ARM (z.B. von Qualcomm oder Samsung) und ist eine Voraussetzung für viele Android-Geräte, passendes Stichwort wäre CDD. Jeder dämliche U-Boot, RedBoot oder anderer Bootloader für halbwegs fähige Hardware verifiziert den Code, bevor er ausgeführt wird (und sei es, Header und Checksumme vom Image zu prüfen und - falls inkorrekt - anzuhalten). Und nein, bei einem Update der Firmware ersetzt man den Bootloader in der Regel nicht. Außerdem zu nennen wäre jegliche Spielekonsole von Nintendo, Sony oder Sega der letzten Jahrzehnte. Inzwischen sind da Krypto-Keys fest im ROM eingebrannt, um mehrere Layer von Bootloadern gegeneinander zu verifizieren und zu sichern - aber auch ein originaler GAMEBOY verifiziert die Cartridge vor (und während) der Ausführung mit Code im internen ROM. Marc kennt aber nur seine kleine Hobbykeller-Welt mit AVRs, die er selbst beschrieben hat und sich mal wieder nicht zu schade, andere als dumm, unfähig oder schlicht blöd zu beschimpfen. Punktförmiger Horizont und so.
:
Bearbeitet durch User
Beitrag #5576493 wurde von einem Moderator gelöscht.
Beitrag #5576503 wurde von einem Moderator gelöscht.
Beitrag #5576514 wurde von einem Moderator gelöscht.
Beitrag #5576544 wurde von einem Moderator gelöscht.
Marc V. schrieb: > Wenn kein Programm existiert, geht es normalerweise durch NOP's wieder > zum Bootloader und so bis in alle Ewigkeit oder bis das Zeichen kommt. Das ist aber sehr blauäugig. Es ist sehr selten, daß der Bootloader ausgerechnet nach dem Löschen unterbrochen wird. Viel wahrscheinlicher ist es, daß die Verbindung beim Flashen gestört wird und dann ein unvollständiges Programm im Flash ist. Ob das dann nach ner Weile wieder in den Bootloader läuft, könnte passieren, muß aber nicht. Ein solches Teilprogramm kann aber gefährliche Sachen machen (Motoren oder hohe Spannungen einschalten), das muß zuverlässig unterbunden werden. Eine CRC über die Applikation ist also das mindeste, was in Bootloadern für kommerzielle Anwendungen zu finden ist. Wir benutzen auch eine CRC an einer festen Adresse im Flash. Daten im Flash können dahinter abgelegt werden. Als Bastler darf man natürlich auf eine CRC verzichten. Der Bootloader überprüft außerdem eine Gerätekennung. Eine Gerätesteuerung, die einmal als Kaffemühle eingerichte wurde, kann keine Firmware für eine Waschmaschine mehr starten.
:
Bearbeitet durch User
Beitrag #5576781 wurde von einem Moderator gelöscht.
Beitrag #5576793 wurde von einem Moderator gelöscht.
Peter D. schrieb: > Marc V. schrieb: >> Wenn kein Programm existiert, geht es normalerweise durch NOP's wieder >> zum Bootloader und so bis in alle Ewigkeit oder bis das Zeichen kommt. > > Das ist aber sehr blauäugig. Es ist sehr selten, daß der Bootloader > ausgerechnet nach dem Löschen unterbrochen wird. > Viel wahrscheinlicher ist es, daß die Verbindung beim Flashen gestört > wird und dann ein unvollständiges Programm im Flash ist. Ob das dann > nach ner Weile wieder in den Bootloader läuft, könnte passieren, muß > aber nicht. Nein, das ist normalerweise nur bei neuen uC der Fall. Ansonsten gilt: Marc V. schrieb: > Bootloader darf nur gerade geflashtes Programm (also virgin) > prüfen und dazu bedarf es natürlich keinen Checksum weil das > Byte für Byte verglichen wird. Und noch einmal: Dazu bedarf es natürlich keinen Cheksum weil das gerade geflashte Programm beim flashen Byte für Byte (oder Pageweise) geprüft wird. Wenn irgendein Byte nicht stimmt, wird es noch ein paar Mal versucht und wenn es immer noch nicht klappt, hat der BL verschiedene Müglichkeiten, Situation zu retten (oder es zumindest zu versuchen). Eine davon wäre, Userflash wieder zu löschen und eine Warnung auszugeben. So wäre es sichergestellt, dass beim nächsten Start - und das ist der Reset gleich nach dem flashen - wieder der BL angesprungen wird. Peter D. schrieb: > Ein solches Teilprogramm kann aber gefährliche Sachen machen (Motoren > oder hohe Spannungen einschalten), das muß zuverlässig unterbunden > werden. Nein, siehe oben - wenn der Flash bei einem Fehler gelöscht wird. Peter D. schrieb: > Eine CRC über die Applikation ist also das mindeste, was in Bootloadern > für kommerzielle Anwendungen zu finden ist. Wir benutzen auch eine CRC > an einer festen Adresse im Flash. Daten im Flash können dahinter > abgelegt werden. Und der Sinn des Ganzen wäre? Eine solche CRC hat nur Sinn wenn BL und Applikation aufeinander abgestimmt sind, hier war die Rede von normalen BL. Bei einem universellen BL hat es absolut keinen Sinn weil: Marc V. schrieb: > Wie kann ein Bootloader wissen, ob ein Programm nicht selbst > irgendwelche Werte in den Flash schreibt und somit die Prüfsumme > nicht mehr stimmt?
S. R. schrieb: > Lass gut sein, Marc zeigt mal wieder seine vollständige Abwesenheit von > Wissen gepaart mit Selbstüber- und Fremdunterschätzung. S. R. schrieb: > Marc kennt aber nur seine kleine Hobbykeller-Welt mit AVRs, die er > selbst beschrieben hat und sich mal wieder nicht zu schade, andere als > dumm, unfähig oder schlicht blöd zu beschimpfen. Punktförmiger Horizont > und so. @Mods: Das wird stehengelassen, aber meine Antwort darauf wird gelöscht?
@Mods: Warum wurde das gelöscht? Die ursprüngliche Frage die der TO gestellt hat, war: Manfred L. schrieb: > Wenn bei der Übertragung der .hex File Daten ein Fehler aufgetreten ist > und schon einige Pages geflashed wurden, ist das Anwendungsprogramm ab > 0x0000 zerstört und es gibt nominal keine Möglichkeit mehr, den > Bootloader wieder anzuschmeißen. Was hat seine Frage mit Verschlüsselung, Kryptographie und Checksum überhaupt zu tun ? Aber es müssen sich immer wieder ein paar Besserwisser finden, die furchtlos am Thema vorbeischreiben, nur um ihr zusammengegoogeltes Wissen vorzuzeigen.
Marc V. schrieb: > Das wird stehengelassen, aber meine Antwort darauf wird gelöscht? Die Moderation dreht mal wieder frei und löscht willkürlich Diskussionen.
S. R. schrieb: > UEFI macht Verifikation und Kryptographie, passendes Stichwort wäre > "Secure Boot". Gibt es auch auf ARM (z.B. von Qualcomm oder Samsung) und Selbst ..... wie du muss wissen, dass UEFI nichts mit mikrocontrollern zu tun hat und das es überhaupt kein Bootloader ist. Vielmehr wird der Bootloader von UEFI gestartet, aber das weisst du wahrscheinlich auch nicht, oder?
Hallo Leute, erst mal vielen Dank für Eure Beiträge, viele davon sind gut, einige hinreichend und dann gibt’s natürlich auch noch andere. Aber bitte: beendet die lästigen Einlassungen wie "dumm, unfähig oder schlicht blöd zu beschimpfen", wir sind hier doch nicht im Kindergarten, oder ? Nun zum eigentlichen Thema: Endlich hat Peter eingegriffen und die Sache mal wieder auf den Punkt gebracht, der in meinem Eröffnungspost als Fehlerfall genannt wurde. Peter D. schrieb: > Das ist aber sehr blauäugig. Es ist sehr selten, daß der Bootloader > ausgerechnet nach dem Löschen unterbrochen wird. > Viel wahrscheinlicher ist es, daß die Verbindung beim Flashen gestört > wird und dann ein unvollständiges Programm im Flash ist. Ob das dann > nach ner Weile wieder in den Bootloader läuft, könnte passieren, muß > aber nicht. Nehmen wir also genau diesen konkreten Fehlerfall auf und analysieren, was passieren kann, bzw. was passieren muss: - Der BL hat beim Checken der Prüfsumme einen Fehler erkannt. - Er beendet das weitere Flashen und signalisiert dem Server/Host, dass er mit der Übertragung nochmal von vorne beginnen soll. - Da aber die Kommunikation gestört bzw. unterbrochen ist, bleibt der BL in diesem "Erwartungs"-Loop. Jetzt gibt es zwei Möglichkeiten die Sache zu Ende zu bringen: a) die Verbindung wird wieder hergestellt und der BL verrichtet seine Aufgabe und flashed die neue Firmware so wie befohlen. b) der Server/Host wie auch der Controller werden ausgeschaltet und danach wieder eingeschaltet, um einen neuen Versuch zu starten. Fall a) ist trivial und wird nicht weiter betrachtet Fall b) ist der worst case Denn im Fall b), das habe ich jetzt aus diesem Thread gelernt, ist es ein MUSS, dass nach einem Reset ZUERST der BL ausgeführt werden muss. Und genau hier lag mein Denkfehler: das BOOTRST-Fuse ist nicht gesetzt: Manfred L. schrieb: > Vom Anwendungsprogramm kann durch eine simple > Abfrage via UART zum Bootloader gesprungen werden. Via UART wird dann > der Inhalt des .hex files empfangen und das neue Anwendungsprogramm in > den Flash-Speicher ab Adresse 0x0000 geschrieben. Damit ist mein Problem gelöst und ich bedanke mich bei Euch allen für die engagierte Diskussion. Und darüber hinaus habe ich mal wieder ne Menge dazu gelernt. Gruß Manni
Marc V. schrieb: > Dazu bedarf es natürlich keinen Cheksum weil das gerade geflashte > Programm beim flashen Byte für Byte (oder Pageweise) geprüft wird. Doch, sonst weiß der Bootloader beim nächsten Power-On ja nicht mehr, daß die Applikation noch nicht fertig geprüft wurde. Ob der Bootloader nach dem Verify die CRC selber einträgt oder sie gleich mit im Hex-File steht, ist dabei egal. Es gibt keine Garantie, daß der Bootloader immer durchläuft. Es kann immer mal jemand übers Kabel stolpern, Kaffee in die Tastatur gießen, der Strom ausfallen, Wackelkontakt usw. Marc V. schrieb: > Und der Sinn des Ganzen wäre? Daß bei einem Fehler beim Update nicht irgendein Müll ausgeführt wird. Im Hobbybereich mag es keine Rolle spielen, wenn plötzlich LEDs wild blinken, aber bei realen Maschinen sind Fehlfunktionen extrem unerwünscht.
Wer ist dieser Marc V. und aufgrund welcher Kompetenzen will diese Gestalt allgemeingültig definieren, was ein Bootloader darf und was nicht? Woher kennt er meine Applikation und kann aufgrund dieser Kenntnisse fundierte Entscheidungen treffen wie mein Bootloader auszusehen hat? Was passiert wenn mein BL eine Verifizierung mittels Checksumme implementiert? Kommt dann das Schweizer Amt für Bootloader-Normierung und legt mich in Ketten? @ Marc V.: kannst du bitte diese ISO oder SAE zitieren in der das allgemeingültige Bootloader-Verhalten festgelegt wird?
Rainer V. schrieb: > ...und was soll das nun wieder??? > Ich sagte doch schon, dass eine umfassende Diskussion der Thematik den > Rahmen des Forums sprengen wird...natürlich würde mich auch brennend > interessieren, wie z.B. die Weltraumleute an das Thema herangehen :-) Ich habe mich noch nicht oft selbst zitiert...aber
Peter D. schrieb: > Es ist sehr selten, daß der Bootloader > ausgerechnet nach dem Löschen unterbrochen wird. So unwahrscheinlich ist das aber auch nicht - immerhin dauert das Löschen einer Flash-Page je nach Hardware einige zig- bis einige hundert Millisekunden. Wenn genau in der Zeit der Vorgang durch einen Spannungsausfall abgebrochen wird, befinden sich mitunter nur teilweise gelöschte Daten im Flash! Sowas kommt in Marc V.'s Szenarien natürlich auch nicht vor - er meint wohl, das Löschen der App ist ein atomarer Befehl, der entweder durchgeführt wurde oder nicht.
Le X. schrieb: > Wer ist dieser Marc V. und aufgrund welcher Kompetenzen will diese > Gestalt allgemeingültig definieren, was ein Bootloader darf und was > nicht? Wer lesen kann (und will) ist klar im Vorteil: Marc V. schrieb: > Ihr könnt in ihren eigenen Bootloadern Sommer- und Winterzeit > einbauen, eure Sache. > Ob das sinnvoll ist, ist etwas anderes aber immer noch eure Sache.
Thomas E. schrieb: > So unwahrscheinlich ist das aber auch nicht - immerhin dauert das > Löschen einer Flash-Page je nach Hardware einige zig- bis einige hundert > Millisekunden. Wenn genau in der Zeit der Vorgang durch einen > Spannungsausfall abgebrochen wird, befinden sich mitunter nur teilweise > gelöschte Daten im Flash! Sowas kommt in Marc V.'s Szenarien natürlich > auch nicht vor - er meint wohl, das Löschen der App ist ein atomarer > Befehl, der entweder durchgeführt wurde oder nicht. LOL. Wer so auf Sicherheit bedacht ist, programmiert nur mit Akku. Peter D. schrieb: > Daß bei einem Fehler beim Update nicht irgendein Müll ausgeführt wird. > Im Hobbybereich mag es keine Rolle spielen, wenn plötzlich LEDs wild > blinken, aber bei realen Maschinen sind Fehlfunktionen extrem > unerwünscht. Deswegen macht man bei realen Maschinen kein Fernupdate, sondern direkt vor Ort. Und dann wird der Kabel zur Steuerung meistens abgezogen und es wird abgewartet, dass eine OK Meldung kommt. Falls keine kommt, wird das Ganze wiederholt. Aber meistens wird das alte Modul mit neuem ausgetauscht. Und noch einmal: Ein BL kann von Sommer- auf Winterzeit umschalten und sich danach in die Luft sprengen oder ins Weltall lansieren, üblich ist das aber nicht, es sind spezielle BL, abgestimmt auf verwendete Firmware. Und noch einmal: TO hat nach normalen BL gefragt. Und noch einmal: Rainer V. schrieb: > Rainer V. schrieb: >> ...und was soll das nun wieder??? >> Ich sagte doch schon, dass eine umfassende Diskussion der Thematik den >> Rahmen des Forums sprengen wird...natürlich würde mich auch brennend >> interessieren, wie z.B. die Weltraumleute an das Thema herangehen :-) > > Ich habe mich noch nicht oft selbst zitiert...aber
:
Bearbeitet durch User
Manfred L. schrieb: > Nun zum eigentlichen Thema: Endlich hat Peter eingegriffen und die Sache > mal wieder auf den Punkt gebracht, der in meinem Eröffnungspost als > Fehlerfall genannt wurde. > > Peter D. schrieb: >> Das ist aber sehr blauäugig. Es ist sehr selten, daß der Bootloader >> ausgerechnet nach dem Löschen unterbrochen wird. >> Viel wahrscheinlicher ist es, daß die Verbindung beim Flashen gestört >> wird und dann ein unvollständiges Programm im Flash ist. Ob das dann >> nach ner Weile wieder in den Bootloader läuft, könnte passieren, muß >> aber nicht. > > Nehmen wir also genau diesen konkreten Fehlerfall auf und analysieren, > was passieren kann, bzw. was passieren muss: > - Der BL hat beim Checken der Prüfsumme einen Fehler erkannt. Das ist nicht der Punkt um den hier die ganze Zeit debattiert wird. Natürlich kann die Datenübertragung zum Bootloader beim Flashen zusätzlich durch Prüfsummen gesichert sein (z.B. ganz schlicht die zeilenweise Prüfsumme von Intel HEX). Und natürlich sollte der Bootloader beim Flashen prüfen, ob die empfangenen Daten auch korrekt im Flash gelandet sind. Das ist nicht der Punkt. > - Er beendet das weitere Flashen und signalisiert dem Server/Host, dass > er mit der Übertragung nochmal von vorne beginnen soll. > - Da aber die Kommunikation gestört bzw. unterbrochen ist, bleibt der BL > in diesem "Erwartungs"-Loop. So weit, so trivial. Aber darum geht es nicht. Sondern darum, daß sich eine kaputte Firmware im Flash befinden kann. Mögliche Gründe gibt es viele. Z.B. wenn der Flashvorgang unterbrochen wurde (Strom weg). Oder wenn das Flash schlicht vergeßlich geworden ist. Was auch immer. Auf jeden Fall kommt der µC gerade frisch aus einem Reset und der Bootloader läuft los. Er weiß nichts (kann nichts wissen) über das was in der Vergangenheit passiert ist. Aber er muß jetzt entscheiden, ob er die Firmware im Flash starten soll oder nicht. Und in dieser Situation ist es enorm hilfreich, wenn der Bootloader eine Methode hat, um ein korrektes Firmware-Image im Flash von einem kaputten zu unterscheiden. Und das kanonische Hilfsmittel dafür ist eine Prüfsumme. Das kann man natürlich beliebig weit herunterrüsten. Man könnte eine Signatur, ein "magisches Byte" prüfen. Oder man könnte prüfen ob der Flash komplett leer ist und alles andere als "ok" werten. Oder man delegiert die Verantwortung komplett an den User und testet nur, ob er den Jumper am vordefinierten Pin gesetzt hat und springt dann in die Firmware.
Marc V. schrieb: > Selbst ..... wie du muss wissen, dass UEFI nichts mit mikrocontrollern > zu tun hat und das es überhaupt kein Bootloader ist. Wunderst du dich nicht manchmal, warum du ständig den ganzen Geisterfahrern ausweichen musst?
Axel S. schrieb: > Das kann man natürlich beliebig weit herunterrüsten. Man könnte eine > Signatur, ein "magisches Byte" prüfen. Oder man könnte prüfen ob der > Flash komplett leer ist und alles andere als "ok" werten. Oder man > delegiert die Verantwortung komplett an den User und testet nur, ob er > den Jumper am vordefinierten Pin gesetzt hat und springt dann in die > Firmware. Genau. Darauf will ich die ganze Zeit hinaus - " man kann ". Wenn es sich, wie der Peter schrieb, um eine Maschine handelt, dann werden natürlich alle möglichen Sicherheitsvorkehrungen getroffen, diese werden aber meistens nicht von Bootloader ausgeführt, sondern von (wie der S.R. schrieb) UEFI, Bootmanager oder ähnlich. Erst danach wird der eigentliche Bootloader (oder FW) gestartet. Ein BL für AVR (wie von TO gefragt) hat das alles aber nicht.
:
Bearbeitet durch User
Marc V. schrieb: > Ein BL für AVR (wie von TO gefragt) hat das alles aber nicht. Warum? Welche Norm legt das fest?
MaWin schrieb: > Marc V. schrieb: >> Ein BL für AVR (wie von TO gefragt) hat das alles aber nicht. > > Warum? Welche Norm legt das fest? ISOAVR123gljmnp32 Kann man aber nur mit Pass und gegen Entgelt kriegen.
Marc V. schrieb: > Kann man aber nur mit Pass und gegen Entgelt kriegen. Du könntest auch einfach zugeben, dass du Unrecht hast. Und zwar Unrecht auf ganzer Linie. Das was du erzählst, mag für deinen Sonderfall stimmen. Aber generell stimmt es nicht.
MaWin schrieb: > Du könntest auch einfach zugeben, dass du Unrecht hast. > Und zwar Unrecht auf ganzer Linie. LOL. Ich habe Unrecht. Zufrieden? EoD
:
Bearbeitet durch User
Hallo, Le X. schrieb: > Wer ist dieser Marc V. und aufgrund welcher Kompetenzen will diese > Gestalt allgemeingültig definieren, was ein Bootloader darf und was > nicht? > ... > @ Marc V.: kannst du bitte diese ISO oder SAE zitieren in der das > allgemeingültige Bootloader-Verhalten festgelegt wird? keine Ahnung warum, aber als Norm fällt mir hier in dem Zusammenhang die ICD-10, speziell F60.0 ein... Schöne Grüße, Martin
Wie ich bereits (in einem der gelöschten Posts) schrieb: Es gibt mehr als einen Bootloader. UEFI wird von einem Bootloader gestartet und enthält selbst einen Bootloader, der das OS startet. Sinnvollerweise prüft jeder Code den von ihm geladenen Code, denn sonst wäre ein "Secure Boot" nicht "Secure". Das gilt insbesondere für Spielekonsolen, bei denen harte Kryptographie ab First-Stage-ROM stattfindet. Wie ein Bootloader während des Flashvorgangs die Gültigkeit jedes einzelnen Bytes überprüfen können soll, ist mir etwas unklar. Vielleicht könnte uns da jemand mit Ahnung etwas aufklären? Ein IHEX hat pro Zeile eine Checksumme, aber pro Byte wird schwierig. Im Übrigen ist Flash vergesslich - auch im AVR. Allein deswegen lohnt es sich schon, zumindest die Gültigkeit des Codes sicherzustellen.
S. R. schrieb: > Im Übrigen ist Flash vergesslich - auch im AVR. Allein deswegen lohnt es > sich schon, zumindest die Gültigkeit des Codes sicherzustellen. Na klar. Besonders die des Bootloaders. Denn der ist in aller Regel älter als die Anwendung. Und wenn man mit einem Programmer den Code aufgespielt hat, dann hat der natürlich auch eine Testfunktion drin, die nach jedem Reset die Integrität des eigenen Codes prüft.
S. R. schrieb: > Wie ein Bootloader während des Flashvorgangs die Gültigkeit jedes > einzelnen Bytes überprüfen können soll, ist mir etwas unklar. Vielleicht > könnte uns da jemand mit Ahnung etwas aufklären? Ein IHEX hat pro Zeile > eine Checksumme, aber pro Byte wird schwierig. Ich habe auch keine Ahnung, habe aber meinen Onkel gefragt, der hat davon ungefähr so viel Ahnung wie Ihr alle zusammen und er hat mir folgendes gesagt:
1 | Man liest Zeile für Zeile aus dem Hexfile ins RAM, merkt sich die |
2 | Checksumme und programmiert eine Flashpage aus RAM. |
3 | Danach wird die gerade programmierte Flashpage in einen anderen |
4 | RAM Bereich wieder eingelesen und die beiden Bereiche werden Byte |
5 | für Byte miteinander verglichen. |
6 | Fertig. |
Auch wenn mein Onkel gesagt hat, dass keiner von Euch das so richtig kapieren wird, schreibe ich es trotzdem, in der Hoffnung, dass dem nicht so sei.
Thomas E. schrieb: > S. R. schrieb: >> Im Übrigen ist Flash vergesslich - auch im AVR. Allein deswegen lohnt es >> sich schon, zumindest die Gültigkeit des Codes sicherzustellen. > > Na klar. Besonders die des Bootloaders. Denn der ist in aller Regel > älter als die Anwendung. Und wenn man mit einem Programmer den Code > aufgespielt hat, dann hat der natürlich auch eine Testfunktion drin, die > nach jedem Reset die Integrität des eigenen Codes prüft. Tja, da habe ich wieder meinen Onkel bemüht und er sagte mir, dass er selten so etwas - ahm, naives - gehört habe. Er sagte mir folgendes:
1 | Wie - ahm, naiv - muss man sein, um darauf zu vertrauen, dass gerade |
2 | dieses Stück womit die Integrität geprüft wird, intakt bleibt aber |
3 | alles andere nicht? |
Das sind seine Worte, ich verstehe es nicht ganz aber Ihr seid Spezialisten, ihr werdet es sicher verstehen können.
Thomas E. schrieb: > Na klar. Besonders die des Bootloaders. Denn der ist in aller Regel > älter als die Anwendung. Der Flashbereich des Bootloader wird in der Regel nur einmal beschrieben. Kippende Bits sind daher in dem Bereich deutlich unwahrscheinlicher. @Mark Dein Onkel hat in seiner Genialität wohl vergessen was passiert, wenn während des Schreibvorgangs der Strom ausfällt. Dann läuft der Controller plötzlich mit einem fehlerhaften Programm los.
avr schrieb: > Kippende Bits Dann muß man da ein ESP einbauen. Hat Mercedes bei der A-Klasse auch gemacht. Ist Paranoia eigentlich heilbar oder weiß der Nervenarzt auch nicht mehr wie es weitergeht?
avr schrieb: > @Mark > Dein Onkel hat in seiner Genialität wohl vergessen was passiert, wenn > während des Schreibvorgangs der Strom ausfällt. Dann läuft der > Controller plötzlich mit einem fehlerhaften Programm los. Habe meinen Onkel gefragt, er sagte mir folgendes:
1 | Natürlich nicht, Bootloader wird immer als erster angesprungen. |
2 | Und der Bootloader von meinem Onkel beschreibt einen Byt mit 0xAA |
3 | vor dem flashen und mit 0x55 nach dem flashen. |
4 | So weiss er immer, ob der Flashvorgang erfolgreich war. |
5 | Aber sein BL kann noch viel mehr - Horoskop erstellen, LEDs ganz |
6 | lustig blinken lassen, Kaffeekocher einschalten, Kreuzworträtsel |
7 | erstellen und noch vieles mehr - ich habe die Hälfte vergessen. |
Aber so hat er mir das mit flashen erklärt.
:
Bearbeitet durch User
Marc V. schrieb: > Und der Bootloader von meinem Onkel beschreibt einen Byt mit 0xAA > vor dem flashen und mit 0x55 nach dem flashen. Du baust also einen Mechanismus, der weniger kann als Checksummen. Das kannst du natürlich tun.
Thomas E. schrieb: > S. R. schrieb: >> Im Übrigen ist Flash vergesslich - auch im AVR. Allein deswegen >> lohnt es sich schon, zumindest die Gültigkeit des Codes sicherzustellen. > > Na klar. Besonders die des Bootloaders. > Denn der ist in aller Regel älter als die Anwendung. Und befindet sich damit in deutlich weniger abgenutzten Bereichen des Flashs, wo die Wahrscheinlichkeit für Bitfehler deutlich geringer ist. Schlaukeks. > Und wenn man mit einem Programmer den Code > aufgespielt hat, dann hat der natürlich auch eine Testfunktion drin, die > nach jedem Reset die Integrität des eigenen Codes prüft. Sicher, Verfikation nach dem Flashen verhindert den gröbsten Unfug. Aber kurz nach dem Flashen liest man mit ziemlicher Wahrscheinlichkeit auch die korrekten Daten zurück, wenn die Zelle schon halb hinüber ist... was nach einer gewissen Zeit oder bei höherer Temperatur nicht mehr der Fall ist. Marc V. schrieb: > Man liest Zeile für Zeile aus dem Hexfile ins RAM, merkt sich die > Checksumme und programmiert eine Flashpage aus RAM. Dein Onkel ist ja ein ganz Schlauer. Im Gegensatz zu dir hat er nämlich begriffen, dass man den zu programmierenden Flashinhalt nicht byteweise prüft, sondern blockweise. Allerdings funktioniert sein Ansatz nur dann, wenn eine Zeile im Hexfile zufällig genau so viele Daten enthält, wie eine Flashpage groß ist. Wenn nicht, muss man nämlich mehrere Zeilen lesen, bevor man eine Flashpage schreiben kann. Oder man muss eine Zeile lesen und dann mehrere Flashpages schreiben. Kannst du ihm ja mal sagen. Marc V. schrieb: > Und der Bootloader von meinem Onkel beschreibt einen Byt mit 0xAA > vor dem flashen und mit 0x55 nach dem flashen. > So weiss er immer, ob der Flashvorgang erfolgreich war. Das ist auch eine sehr gute Taktik, denn damit wird dieses eine Byte doppelt so häufig beschrieben wie der Rest des Flashes.
MaWin schrieb: > Marc V. schrieb: >> Und der Bootloader von meinem Onkel beschreibt einen Byt mit 0xAA >> vor dem flashen und mit 0x55 nach dem flashen. > > Du baust also einen Mechanismus, der weniger kann als Checksummen. > Das kannst du natürlich tun. Mein Onkel sagt folgendes:
1 | Nein, natürlich nicht, dieses Byte dient nur als Flag, um einen |
2 | erfolgreichen Flashvorgang zu bezeichnen. |
3 | Checksumme wird beim flashen berechnet und mit gelesenen Byten |
4 | verglichen. Wenn die CS beim flashen und CS beim lesen gleich sind |
5 | und dieses Byte 0x55 enthält, ist alles OK. |
6 | |
7 | Mein Onkel sagte auch, dass die Prüfmethoden beim flashen und die |
8 | Prüfmethoden beim Starten des Programms nicht die gleichen sind. |
9 | Er sagte auch, dass Leute die das nicht wissen, wahrscheinlich |
10 | auch nicht viel mehr über das ganze Vorgang des flashen wissen. |
11 | |
12 | Und er sagte auch, dass so etwas von Bootmanagern geprüft wird, |
13 | nicht von Bootloadern. |
Ich habe nicht alles verstanden was er sagte, aber Ihr als Spezialisten werdet wohl keine Schwierigkeiten damit haben.
S. R. schrieb: > Allerdings funktioniert sein Ansatz nur dann, wenn eine Zeile im Hexfile > zufällig genau so viele Daten enthält, wie eine Flashpage groß ist. Wenn > nicht, muss man nämlich mehrere Zeilen lesen, bevor man eine Flashpage > schreiben kann. Oder man muss eine Zeile lesen und dann mehrere > Flashpages schreiben. Kannst du ihm ja mal sagen. Habe es ihm gesagt und er meint folgendes dazu:
1 | Natürlich liest mein BL soviele Zeilen wie nötig ein. |
2 | Und ich soll dir auch sagen, dass das für jeden normalen Menschen |
3 | auch normal ist. Er sieht nicht wo du irgendwelche Probleme siehst. |
S. R. schrieb: > Das ist auch eine sehr gute Taktik, denn damit wird dieses eine Byte > doppelt so häufig beschrieben wie der Rest des Flashes. Mein Onkel sagt folgendes:
1 | 10000 Vorgänge sind schmerzlos durchzuführen, ich werde mich |
2 | etwa ab dem 4000-sten flashen mit der doppelten Anzahl beschäftigen. |
Und mein Onkel sagte noch dazu:
1 | Wenn ich jeden Tag, aber wirklich jeden Tag - Sonntags, Feiertags |
2 | usw. ein FW Update mache wird das in etwa 11 Jahren aktuell. |
3 | Du sollst so nett sein und ihn in 11 Jahren wieder daran erinnern. |
Ich habe nicht alles verstanden, aber so hat er mir das erklärt.
Vielleicht kann dein Onkel mal erklären, was dieser ominöse "Bootmanager" sein soll? Den kennt nämlich außer deinem Onkel niemand.
MaWin schrieb: > Vielleicht kann dein Onkel mal erklären, was dieser ominöse > "Bootmanager" sein soll? Den kennt nämlich außer deinem Onkel niemand. Habe meinen Onkel gefragt und er sagte folgendes:
1 | Seh' ich aus, als hätt' ich sonst nichts zu tun? |
2 | Ich kann es aber ich habe keine Lust dazu. |
3 | Er soll mal ein bißchen googeln. |
Sorry, ich hätte dir gerne geholfen aber ich verstehe nix davon...
Beitrag #5577610 wurde von einem Moderator gelöscht.
S. R. schrieb: > Schlaukeks. Lieber Schlaukeks als Dummbrot. Und pass auf, daß du nicht aus den Bits kippst.
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.