GNU objcopy (WinAVR 20100110) 2.19 Beim Versuch, ein binäres Image einer Firmware mit objcopy zu erzeugen, entsteht eine 10 MB Datei! Was könnten Ursachen sein?
Ohne Kenntnis der Quelldatei (Format, Größe, Ausgabe von z.B. objdump -ah) lässt sich da nichts sagen.
Binary ist tatsächlich 10MB groß. Eingabedatei ist fehlerhaft. GNU objcopy hat einen Bug. Ähnliches gab es schon einmal http://www.mail-archive.com/bug-binutils@gnu.org/msg04318.html http://sourceware.org/bugzilla/show_bug.cgi?id=5556 Damals war es eine fehlerhafte Eingabedatei bzw. fehlerhafte Linkeraufrufzeile beim Erzeugen der Eingabedatei
Danke stefan für die perfekte Antwort! Allerdings löst > Adding -Wl,--build-id=none to linker flags fixed the issue, thanks. mein Problem nicht :-( elf ist ca 60 kB, hex 110 kB groß. Mit objcopy aus dem hex das bin zu erzeugen hat das selbe Ergebnis. Mit hex2bin funktioniert es soweit. Wie kann ich >Eingabedatei ist fehlerhaft. ausschließen? Im Bugtracker ist von PT_LOAD zu lesen - worum handelt es sich dabei? Wie kann ich mein darauf elf/hex prüfen, u.A. auch um die Auswirkung der Linkeroption zu prüfen? Danke.
Zeig doch einfach mal deine Hex-Datei... Gruesse Marvin
Das PT_LOAD brauchst du hier nicht zu beachten. Im Bugtracker wird ein Executable erzeugt, also eine datei im ELF Format und die hat ein PT_LOAD Segment. http://statifier.sourceforge.net/statifier/statified_layout.html Dein objcopy sollte eine sog. raw binary erzeugen, d.h. ein Speicherabbild. "objcopy can be used to generate a raw binary file by using an output target of `binary' (e.g., use -O binary). When objcopy generates a raw binary file, it will essentially produce a memory dump of the contents of the input object file. All symbols and relocation information will be discarded. The memory dump will start at the load address of the lowest section copied into the output file." http://sourceware.org/binutils/docs-2.20/binutils/objcopy.html#objcopy Versuche näher zu beschreiben, wie du die Tools verwendest und mit welchen Eingabedateien du sie fütterst und was du rausbekommst. Ggf. die Eingabedateien und den Anfang der Ausgabedatei (bzw. ein ZIP Archiv) anhängen.
# readelf -h -l my.elf ELF Header: Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00 Class: ELF32 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: Atmel AVR 8-bit microcontroller Version: 0x1 Entry point address: 0x0 Start of program headers: 52 (bytes into file) Start of section headers: 40296 (bytes into file) Flags: 0x86 Size of this header: 52 (bytes) Size of program headers: 32 (bytes) Number of program headers: 4 Size of section headers: 40 (bytes) Number of section headers: 8 Section header string table index: 5 Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x0000b4 0x00000000 0x00000000 0x08d7c 0x08d7c R E 0x1 LOAD 0x008e30 0x00808000 0x00008d7c 0x00edc 0x00edc RW 0x1 LOAD 0x009d0c 0x00808edc 0x00808edc 0x00000 0x00dac RW 0x1 LOAD 0x009d0c 0x00a10000 0x00a10000 0x00024 0x00024 RW 0x1 Section to Segment mapping: Segment Sections... 00 .text 01 .data 02 .bss 03 .xeeprom
OK, wenn du keine Kommandozeile rausrückst, gebe ich dir mal zwei vor (aus dem Artikel Beispiel Makefile):
1 | # Binary des FLASHs erzeugen |
2 | avr-objcopy -O binary -R .eeprom my.elf my.bin |
3 | # Binary des EEPROMs erzeugen |
4 | avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 -O binary my.elf my.eep |
Wenn das immer noch Probleme macht, interessieren uns für die weitere Lösungssuche die Dateien my.elf, my.bin und my.eep EDIT: Welche Targetarchitektur hast du, weil bei dir die Sektion .xeeprom statt üblicherweise .eeprom auftaucht? Xmega, welcher? Möglicherweise funktionieren die Kommandozeilen oben deswegen nicht.
> LOAD 0x009d0c 0x00a10000 0x00a10000 0x00024 0x00024 RW 0x1
Da ist der Grund für dein Mega-Binary. Wenn du was in dem Adressbereich
um 10M hast, und dieses mit ins Binary nimmst (ohne weiteres
Adressmapping), dann muss das Binary zwangsläufig so groß werden. Also
sorge dafür, dass diese Sektion nicht mit ins Binary kommt, und es wird
auf ein paar k zusammenfallen.
Stefan B. schrieb: > EDIT: Welche Targetarchitektur hast du, weil bei dir die Sektion > .xeeprom statt üblicherweise .eeprom auftaucht? Xmega, welcher? Ich denke eher, dass es darum geht, den Compiler/Linker Adressen für ein externes EEPROM erzeugen zu lassen. Es gab hier ja kürzlich mehr als einmal entsprechende Fragen dazu.
Bitte 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.