Ich brauche mal Eure Hilfe beim Konstruieren verschiedener Anwendungsszenarien. In embedded devices kommt es gelegentlich vor, dass ein Teil der Firmware nicht aktualisiert werden kann (ROM) oder darf (mögliche Gründe?). In einigen Firmwares findet man daher dass Funktionsaufrufe vorsorglich indirekt über call tables erfolgen, deren Zieladresse dann ggf geändert werden kann. Wie häufig ist dieser Fall in der Praxis? Wer hat sonst noch Bedarf an einem effizienten Mechanismus zum "Verbiegen" einer einzelnen Instruktion, bzw. eines Funktionsaufrufs? Alberne Vorschläge verbitte ich mir :-) Hintergrund: Ich schreibe gerade an einem Aufsatz (neudeutsch: Paper) über die ARM v7-M (Cortex-M3/M4) Flash Patch und Breakpoint unit und würde gerne ein paar realistische Szenarien beschreiben. Vielen Dank Marcus
Flash unterteilen für die Bereiche: - Boot-Loader - Firmware - Parameter - ??? Bootloader ist eigenständiges Programm Firmware ist eigenständiges Programm Beide können gegenseitig angesprungen werden Parameterbereich darf bei FW Update nicht überschrieben werden Lösbar über Bereichsaufteilung im Linkerscript. Eine Tabelle für Funktionsaufrufe halte ich für Sinnlos. Wenn der Kompiller eine Funktion übersetzt, dann weiß man nicht ob der immer relative Calls oder absolute Calls macht. Sobald absolute Calls in einer Funktion drin sind, kann man dies nicht "frei" verschieben. Erst ab ARM9 gibt es sowas wie eine MMU, die ein Betriebssystem nutzen kann um beliebige Programme an beliebiger Speicherstelle ausführen zu können.
Ich will ja nicht undankbar erscheinen,... Plan schrieb: > [...] > > Lösbar über Bereichsaufteilung im Linkerscript. aber ich wollte eigentlich kein Fallbeispiel für das man FPB nicht braucht. ;-) > Eine Tabelle für Funktionsaufrufe halte ich für Sinnlos. Na ja, wenn Du ein Firmware ROM(!) hast und entdeckst dort später einen Fehler kann das im Einzelfall durchaus sinnvoll sein, vorausgesetzt, die Tabelle befindet sich in einem beschreibbaren Speicherbereich. Dummerweise weiß man vorher nicht, welche Funktion betroffen sein wird. Daher müsste man alle Funktionen (oder wenigstens eine sorgfältig definierte Untermenge davon) indirekt aufrufen. Das ist wegen des zusätzlichen Aufwands natürlich unschön. Im Prinzip könnte man das relativ bequem über den SVC machen, sofern der nicht anderweitig verwendet wird. Ich habe einen Kunden, der verwendet call tables für diesen Zweck. > Wenn der Kompiller eine Funktion übersetzt, dann weiß man nicht ob der > immer relative Calls oder absolute Calls macht. Sobald absolute Calls in > einer Funktion drin sind, kann man dies nicht "frei" verschieben. Ich will ja nicht eine existierende Funktion verschieben, sondern statt einer Funktion eine andere aufrufen. Absolute, oder relative Adressierung ist dabei egal. > Erst ab ARM9 gibt es sowas wie eine MMU, die ein Betriebssystem > nutzen kann um beliebige Programme an beliebiger Speicherstelle > ausführen zu können. Genaugenommen gab es die schon beim ARM7[12]0T aber auch das ist eigentlich nicht, wonach ich suche. Vielleicht muss ich mal kurz erklären, was FPB eigentlich macht: 1. Der Prozessor holt sich durch Addressierung seines Speichers Instruktionen. 2. Eine dieser vom Prozessor erzeugten Adressen stimmt mit einem Vergleichwert überein, der vorher ins FPB programmiert wurde. 3. Dem Prozessor wird vom FPB eine andere Instruktion untergeschoben, als die, die im Speicher an dieser Adresse liegt. Ich kann also beliebige einzelne Instruktionen ersetzen. Wenn das Sprünge sind, dann kann ich z.B. den Programmlauf verändern. Ich kann aber auch ganze Funktionen umleiten, wenn ich statt der ersten Instruktion der Funktion einen weiteren Sprung zurückgebe. Meine Frage ist nicht wie ich das mache, sondern: Wer kennt (idealerweise aus eigener Erfahrung) konkrete Anwendungsfälle, die einen Vorteil von einem solchen Mechanismus hätten? Vielen Dank Marcus
Ich denke mal, das ist hauptsächlich für Debugger da.
Hallo Marcus. Du kannst damit einen Rucksack bauen. Also eine Adresse ueberschreiben mit einem Sprung an eine fest vorgegebene Adresse. Dort liegt eine "alternative Funktion" zu dem was sonst abgearbeitet wuerde. Aehnlich Deinem Beispiel mit Call Table. Selbst modifizierender Code waere natuerlich eine weitere Anwedung als eine Art Sicherheitsmechanismus im Programm gegen auslesen, ist aber hoellisch anfaellig gegen Stromunterbrechungen. Dann natuerlich bei Stromverlust und retten einiger weniger Parameter ins Flash als EEPROM Ersatz. Ist zwar ein anderer hintergrund als der, den Du beschrieben hast aber man braucht zur Flash Programmierung dasselbe Prinzip. Vielleicht faellt mir ja noch was ein. Gruss, Robert
Robert Teufel schrieb: > Du kannst damit einen Rucksack bauen. Also eine Adresse ueberschreiben > mit einem Sprung an eine fest vorgegebene Adresse. Dort liegt eine > "alternative Funktion" zu dem was sonst abgearbeitet wuerde. Aehnlich > Deinem Beispiel mit Call Table. Genau. Das ist ja sozusagen die Standardanwendung (neben Debug natürlich). Bisher habe ich nur bei einem einzigen Kunden (entfernte ex-Kollegen von Dir) die Reaktion gesehen "Super, genau das brauchen wir. Unsere aktuelle Softwarelösung kann damit abgelöst und die Firmware vereinfacht werden". Wer von Euch kann eine ähnliche Aussage treffen und ein Beispiel nennen? Szenarien, was man damit alles realisieren kann, kann ich mir selbst ausdenken. Aber wird das auch gemacht? > Selbst modifizierender Code waere natuerlich eine weitere Anwedung als > eine Art Sicherheitsmechanismus im Programm gegen auslesen, ist aber > hoellisch anfaellig gegen Stromunterbrechungen. Ich fürchte, das ist etwas weit hergeholt. > Dann natuerlich bei Stromverlust und retten einiger weniger Parameter > ins Flash als EEPROM Ersatz. Ist zwar ein anderer hintergrund als der, > den Du beschrieben hast aber man braucht zur Flash Programmierung > dasselbe Prinzip. Wie meinen? Meine Frage "Wer kennt (idealerweise aus eigener Erfahrung) konkrete Anwendungsfälle, die einen Vorteil von einem solchen Mechanismus hätten?" scheint sich indirekt zu beantworten. Im Microcontroller Bereich scheint diese Eigenschaft des FPB selten bis gar nicht gefragt zu sein. Gruß Marcus PS: Bist Du nächste Woche auf der EW? Ich werde Mi und Do da sein.
Marcus Harnisch schrieb: >> Selbst modifizierender Code waere natuerlich eine weitere Anwedung als >> eine Art Sicherheitsmechanismus im Programm gegen auslesen, ist aber >> hoellisch anfaellig gegen Stromunterbrechungen. > > Ich fürchte, das ist etwas weit hergeholt. Alles schon erlebt :-( > >> Dann natuerlich bei Stromverlust und retten einiger weniger Parameter >> ins Flash als EEPROM Ersatz. Ist zwar ein anderer hintergrund als der, >> den Du beschrieben hast aber man braucht zur Flash Programmierung >> dasselbe Prinzip. > > Wie meinen? Anwender braucht eigentlich EEPROM, will es aber nicht extra auf's Board machen aus Kostengruenden. Er hat auch noch ein paar KB Flash uebrig und moechte dort, wenn das System in Power Down / Power Off geht ein paar Parameter abspeichern. Das ist sehr haeufig der Fall. > PS: Bist Du nächste Woche auf der EW? Ich werde Mi und Do da sein. Yeap Mi/Do ich auch
Robert Teufel schrieb: >>> Dann natuerlich bei Stromverlust und retten einiger weniger Parameter >>> ins Flash als EEPROM Ersatz. Ist zwar ein anderer hintergrund als der, >>> den Du beschrieben hast aber man braucht zur Flash Programmierung >>> dasselbe Prinzip. >> >> Wie meinen? > Anwender braucht eigentlich EEPROM, will es aber nicht extra auf's Board > machen aus Kostengruenden. Er hat auch noch ein paar KB Flash uebrig und > moechte dort, wenn das System in Power Down / Power Off geht ein paar > Parameter abspeichern. Das ist sehr haeufig der Fall. Und in wiefern würde FPB da helfen? >> PS: Bist Du nächste Woche auf der EW? Ich werde Mi und Do da sein. > Yeap Mi/Do ich auch Prima. Dann sehen wir uns ja vielleicht. -- Marcus
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.