von *.out zu *.ldr ?

[Klausi (Gast)]

Hallo zusammen,
kann mir jemand erklären was der GNU-Compiler als .out File ausgibt?
Wie komme ich zu dem benötigten *.ldr-File um eine bootfähige Datei zu 
erhalten. Ich bin Anfänger in Sachen Kommandozeile daher bitte ich um 
konkrete Anweisungen.
Vielen Dank im vorraus,
viele Grüße

[Jörg W. (dl8dtl) (Moderator)]

Klausi schrieb:
> kann mir jemand erklären was der GNU-Compiler als .out File ausgibt?

Sehr wahrscheinlich eine ELF-Datei.

> Wie komme ich zu dem benötigten *.ldr-File um eine bootfähige Datei zu
> erhalten.

Indem du erst einmal sagst, was für dich eine .ldr-Datei ist und
wie diese aussehen soll.  Falls es sich um eine Intel-Hex-Datei
handelt, geht es mit

objcopy -O ihex foo.out foo.ldr

Je nach Umgebung kann das "objcopy" auch noch einen Präfix haben,
beispielsweise heißt es beim AVR-Crosscompiler avr-objcopy, oder
bei ARM arm-none-eabi-objcopy.

[Klausi (Gast)]

Hi,
ich gehe auch davon aus, dass es sich um eine Intel-Hex-Datei handelt. 
Und schonmal viele Dank für den Hinweis.

Ich möchte die GNU-Toolchain für ADSP Blackfins in Betrieb nehmen und 
konnte schon mit dem dafür von Analog Devices geschriebenen Compiler

bfin-elf-gcc.exe

meine main-Datei kompilieren.
Ich erhalte dann eine .out Datei.

Ich möchte von Section5 den ICE-Bear-Programmer nenutzen mit dem 
zugehörigen Flash-Tool, das verlangt ein *.ldr File.

Ich vermute dass ich auch so was wie ein "Linker-discription-File" zu 
der *.out Datei einbinden muss in der z.B. die Speicherbereiche des 
Prozessors beschrieben sind.

Wo ist der Unterschied zwischen *.ldr und *.out bzw *.elf.?

Was macht --> objcopy -O ihex foo.out foo.ldr?

Wie bekomme ich *.out und ggf. *.ldf(Linker discriction File) zusammen?

Viele Grüße

[Noname (Gast)]

>Ich möchte von Section5 den ICE-Bear-Programmer nenutzen mit dem
>zugehörigen Flash-Tool, das verlangt ein *.ldr File.
Was das genau für eine Datei ist und wie sie ggf. erzeugt wird, sollte 
in der Dokumentation stehen dieses "ICE-Bear"-Programmers stehen.
Es kommt halt darauf ob der einzeln oder mit einem Compiler verkauft 
wird. Falls einzeln sollte das Format irgendwie allgemeingültig benannt 
sein. Falls nicht, dann eine proprietäre Software nötig sein.

Das Linker-File wird im allgemeinen dafür benutzt die absoluten Adressen 
der out oder hex datei festzulegen. Es braucht also nicht mehr 
nachträglich mit dem out oder hex "vereinigt" oder "verrechnet" zu 
werden.  Alle Adressinformationen sind schon vorher aus dem Linker-File 
gelesen worden um das hex file zu erzeugen.

[Klausi (Gast)]

Ich habe gerade gesehen, dass in der Toolchain so was ähnliches ist wie 
in

objcopy -O ihex foo.out foo.ldr

verwendet:

bfin-elf-objcopy.exe

ok, das probiere ich morgen mal aus, aber das mit der 
Speicherbereichs-Beschreibung in einem *.ldf und der Einbindung in die 
bootfähige Datei weiß momentan noch nicht weiter.

Viele Grüße

[Noname (Gast)]

>aber das mit der Speicherbereichs-Beschreibung in einem *.ldf und der >Einbindung 
in die bootfähige Datei weiß momentan noch nicht weiter.

Habe ich doch beantwortet. Was ist unklar geblieben?

[Klausi (Gast)]

Danke für die Antwort. Als Ich meinen 3. Beitrag schrieb, habe ich den 
von Nomame noch nicht gesehen.
Viele Grüße

[Jörg W. (dl8dtl) (Moderator)]

Tante Gugel spuckt mir das hier aus:

http://docs.blackfin.uclinux.org/doku.php?id=toolchain:ldr-utils

[Klausi (Gast)]

Hallo, Danke für den Link.

Ich konnte jetzt ein *.ldr erzeugen, mit

$ bfin-elf-ldr -T bf537 -c --bits 16 --dma 8 blink.ldr blink --bmode 
para

In meiner zur .ldr gewandelten main.c sind aber bisher noch keine Linker 
discription Infos. Geht das? Gibt es sowas wie default Einstellungen so 
das man sich erstmal nicht drum kümmern braucht?

Viele Grüße

[Jörg W. (dl8dtl) (Moderator)]

Ich habe keine Ahnung, wie deine "Linker Description Infos" aussehen
sollen.  Der Linker hat ja sein Werk bereits vollbracht (und dafür
muss er die Information über zu benutzende Speicherbereiche etc.
bereits gehabt haben).

Da das etwas komplett Blackfin-eigenes ist und nichts mit der normalen
GNU-Toolchain zu tun hat, musst du wohl dort weiterfragen, wenn du
der Meinung bist, dass da was nicht stimmt.  Hast du denn schon
probiert, ob dein Programmer mit der entstandenen Datei zurecht kommt
und ob der Code ausgeführt wird?

[Klausi (Gast)]

Nein, hab ich noch nicht, bin ich aber dran, es fehlt noch ein Treiber 
den ich bald bekomme. Okay also der Linker macht das, interessant, hab 
ich keinen Plan von, muss mich unbedingt mal aufschlauen. Aber das mit 
den ldf ist doch bei Mikrocontrollern durchaus normal, ich kenne es 
zumindest auch so von Texas Instruments. Vielleicht hat auch das Tool 
mit dem ich das *.ldr per jatg lade, die Inteligenz das Speichermapping 
für den entsprechenden Prozessor vorzunehemen - mit dem entsprechendem 
Treiber - den ich bald für meinen Prozessor bekomme.
Viele Grüße

[Klausi (Gast)]

Hi, ich hänge mal so ein *.ldf als Datei an, vielleicht hat jemand eine 
Idee wo sowas richtig eingebaut hingehört und wie man das macht.
Viele Grüße

[Jörg W. (dl8dtl) (Moderator)]

Klausi schrieb:
> Nein, hab ich noch nicht, bin ich aber dran, es fehlt noch ein Treiber
> den ich bald bekomme. Okay also der Linker macht das, interessant, hab
> ich keinen Plan von, muss mich unbedingt mal aufschlauen.

Da es der Linker ist, der sämtliche Verschieblichkeiten der zu
linkenden Objektmodule (relocation records) auflösen muss und
die entsprechenden absoluten Werte da eintragen, muss er
notgedrungen derjenige sein, der um die Speicheraufteilung Bescheid
weiß.

> Vielleicht hat auch das Tool
> mit dem ich das *.ldr per jatg lade, die Inteligenz das Speichermapping
> für den entsprechenden Prozessor vorzunehemen

Nein, siehe oben.  Der Linker hat das an dieser Stelle alles bereits
absolut erzeugt.  Dein Downloader kann es nur noch an die richtige
(oder falsche ;-) Stelle im Flash packen.

Klausi schrieb:
> Hi, ich hänge mal so ein *.ldf als Datei an

Das wiederum sieht wirklich wie ein Linkerscript aus.  Zum Vergleich,
ein GNU-Linkerscript für einen ARM sieht ungefähr so aus:

OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
OUTPUT_ARCH(arm)
ENTRY(ResetException)

/* Memory Spaces Definitions */
MEMORY
{
    sram   (W!RX) : ORIGIN = 0x20000000, LENGTH = 0x0000C000 /* sram, 48K */
    flash  (W!RX) : ORIGIN = 0x00400000, LENGTH = 0x00040000 /* Flash, 256K */
}

SECTIONS
{
    .fixed :
    {
        . = ALIGN(4);
        _sfixed = .;
        KEEP(*(.vectors))
        *(.text*)
        *(.rodata*)
        *(.glue_7)
        *(.glue_7t)
        . = ALIGN(4);
        _efixed = .;            /* End of text section */
    } >flash

...