Forum: Compiler & IDEs avr-objcopy -O binary -> sehr große Datei


von ich (Gast)


Lesenswert?

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?

von Hc Z. (mizch)


Lesenswert?

Ohne Kenntnis der Quelldatei (Format, Größe, Ausgabe von z.B. objdump 
-ah) lässt sich da nichts sagen.

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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

von ich (Gast)


Lesenswert?

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.

von Marvin S. (demo)


Lesenswert?

Zeig doch einfach mal deine Hex-Datei...

Gruesse

Marvin

von Stefan B. (stefan) Benutzerseite


Lesenswert?

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.

von ich (Gast)


Lesenswert?

# 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

von ich (Gast)


Lesenswert?


von Stefan B. (stefan) Benutzerseite


Lesenswert?

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.

von Stefan E. (sternst)


Lesenswert?

> 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.

von Stefan E. (sternst)


Lesenswert?

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.

von ich (Gast)


Lesenswert?

Alles klar! Das war's. Dankeschön!

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
Noch kein Account? Hier anmelden.