Hallo zusammen,
ich hab 2 ELFs für AVR:
1. ./default_2/Application.elf
2. ./default_btl/Bootloader.elf (kompiliert mit .text=0x1E000)
Ziel:
Beide sollen in 1 ELF, Fuses & Lockbits aus Application übernehmen.
Klar hab ich gegoogelt und sowohl hier als auch in anderen Foren bereits
einiges dazu gesehen, ich wende mich an Euch, weil ich dennoch nicht
weiter komme...
schaut man in die ELFs zeigt sich folgendes für den Bootloader:
avr-readelf -S ./default_btl/bootloader.elf
1
There are 7 section headers, starting at offset 0x18fc:
Ich flashe die so erstelle Application.elf ins Target.
Er bootet dort in die Application, springt dann zum Bootloader mit:
1
void(*start)(void)=0xF000;// word-adr of bootloader start
2
start();
Nach dem Sprung zuckt das Display kurz, danach ist er leider wieder in
der Application.
Testweise lasse ich den Bootloader blinken und Chars am UART ausgeben.
Beides ist nach dem Sprung nicht zu sehen.
Folgendes funktioniert:
Bootloader.hex flashen
Bootloader.hex flashen (ohne Erase Device)
--> jump to 0xF000 ... blinkt und zeigt Chars am UART
--> Der Fehler muss also in meiner avr-objcopy Akrobatik liegen.
Was auffällt:
- die "size" von .text in Bootloader.elf ist nur 17d4
- die "size" von .bootloader in Application.elf ist 1a1c
Frage:
- wie kann man die beiden ELFs wie gewünscht mischen?
Probier mal stattdessen die Hex-dateien zu kombinieren, das dürfte
wesentlich einfacher sein, brauchst auch keine speziellen Tools dazu
denn das ist Plaintext, musst nur beim ersten den End-of-file Record
entfernen. Kann man auch gut scripten. Siehe auch:
https://de.wikipedia.org/wiki/Intel_HEX
Hallo Bernd,
hex mergen klappt schon, funktioniert mit diversen Möglichkeiten, ein
combi.hex zu bauen.
Kennst Du einen Weg, aus so einem combi.hex ein combi.ELF (inkl. Fuse &
Lock -Bits) zu erstellen?
war vorhin ein Tippfehler...
Folgendes funktioniert:
Application.hex flashen
Bootloader.hex flashen (ohne Erase Device)
--> jump to 0xF000 ... blinkt und zeigt Chars am UART
--> Bootloader kann aus App angesprungen werden
Viele Grüße
>Kennst Du einen Weg, aus so einem combi.hex ein combi.ELF (inkl. Fuse &>Lock -Bits) zu erstellen?
Das geht nicht. In der HEX Datei gibt es keine Sections mehr
die man in eine ELF Datei packen könnte. Das eigentliche
Problem sind ja wohl auch nur die Fuses und Lockbits.
Wir haben 2 Projekte mit allen Sourcen:
1. Application.elf
2. Bootloader.elf
daraus kann man ihex machen & diese kombineren zu combi.hex.
combi.hex hab ich aufgespielt --> App & Boot lassen sich nutzen.
Könnte man nun ein vollwertiges combi.elf generieren aus
- combi.hex und aus
- den Fuse- Lock-Infos aus Application.elf
??
Jetzt hab ich einen Modus, der für mich funktioniert ....
Schritt 1: ./default_btl/bootloader.elf bauen mit .text=0x1E000
Schritt 2: daraus ein verlinkbares Objekt erzeugen mit einem Script:
(Ich hab hier einfach ein Makefile des AVR-Studio4 abgeändert)
Schritt 4: ./default2/application.elf bauen
..fertig
application.elf enthält nun auch den Bootloader in der section .btl_text
auf Byte-Adresse 0x1E000 (=0xF000 Word-Adresse).
Aus bootloader.elf hab ich lediglich .text extrahiert, da ich momentan
noch nicht so recht wusste, wie die .data section im Makefile der
application zu verlinken und zu addressieren ist.
>>Vielleicht hat dazu noch jemand einen Vorschlag.<<
--> diese Lösung funktioniert also nur, wenn der Bootloader-Code auf
.data verzichten kann! (Variablen-Initialisierung fällt also weg)
ELF-Flasher schrieb:> Aus bootloader.elf hab ich lediglich .text extrahiert, da ich momentan> noch nicht so recht wusste, wie die .data section im Makefile der> application zu verlinken und zu addressieren ist.>>>>Vielleicht hat dazu noch jemand einen Vorschlag.<<
Du könntest einen kleinen Umweg über ein Binary machen.
Dazu Schritt 2 ersetzen durch:
Peter Danegger hat mir hier mal den wertvollen Tipp gegeben, die
Applikation unbedingt mit dem bootloader zu flashen. Danach hast Du
zwar nicht gefragt, aber ich halte das für wichtig.
Zum Thema: srecord heißt zwar nicht so, kann aber recht viel.
Stefan E. schrieb:> Du könntest einen kleinen Umweg über ein Binary machen.> Dazu Schritt 2 ersetzen durch:
Das hat prima funktioniert!
Witzig, durch den *.bin - Zwischenschritt werden .text und .data in eine
gemeinsame .text gesteckt, die dann nachher so einfach in die .btl_text
wandern kann.
@Karl:
Ja ... hab auch gerade ein eigentümliches Verhalten:
Flashe ich den Bootloader und über diesen die App --> alles gut
Flashe ich Boot & App gemeinsam, springe dann den Boot an, so hängt er
dann irgend wo im Nirvana... Der Program-Counter ist bei 0xE.... da
sollte momentan gar kein Code sein.
holger schrieb:> Das geht nicht.
Kannst du so nicht sagen.
> In der HEX Datei gibt es keine Sections mehr> die man in eine ELF Datei packen könnte.
Die könnte man ja wieder synthetisieren, indem man zu jeder HEX-Datei
angibt, in welcher ELF-Section sie landen soll.
Aber ich kenne auch kein fertiges Tool, welches sowas anbietet.
Ich bin übrigens mittlerweile bei mir dazu übergegangen nicht mehr zu
versuchen alles in eine Datei zu quetschen, stattdessen hat sich
rausgestellt daß ich sowieso für jedes Produkt ein selbstgestricktes
Produktions-Tool brauche mit dem in der Produktion dann geflasht wird,
eeprom daten je nach gewünschter Konfiguration erzeugt und geflasht
werden, etc. also verteile ich alle Dateien die draufgeflasht werden
sollen separat und das jeweilige Tool flasht die dann einfach alles was
bei dem Produkt drauf muss der Reihe nach drauf.
Da Bootloader und Anwendungen hier in separaten Repositories gepflegt
werden spare ich mir bei jedem Update eines Teils den Aufwand jedesmal
wieder die anderen Teile von anderswo einsammenzusammeln und alles
zusammenzumergen (man stelle sich vor ich fände einen Bug im Bootloader,
dann wäre ich einen halben Tag lang beschäftigt neue Firmwarefiles für
alles neu zu generieren, zu testen und zu deployen), ich tausche
stattdessen einfach auf der Produktionsmaschine die eine einzige Datei
aus, die anderen bleiben wie sie sind und zusammengeführt wird es erst
beim Flashen selbst. Find ich einfacher zu handhaben.
Für Produkte die der Kunde selbst updaten können soll bekommt er
ebenfalls nicht einfach nur eine nackte Datei und kryptische Anweisungen
sondern er bekommt ein idiotensicher zu bedienendes Windows-Tool das
falls nötig auch mehrere einzelne Firmwaredateien im Bauch hat und die
an Ort und Stelle mit einem Mausklick automatisch einzeln in der
richtigen Reihenfolge aufspielt.
Eine eigene Frage?
Dieser Thread ist über 9 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
