Blackfin GCC - Standalone!

[Sebastian B. (sfreak)]

Hi,

im Thread "Welchen DSP? ***" kam das Thema ja schon auf: uCLinux ist 
ganz nett aber fuer reine Signalverarbeitung zu fett und fuer viele 
Aufgaben unnoetig kompliziert. VisualDSP ist zum debuggen recht 
komfortabel aber teuer. Man kann zwar angeblich mit ein Paar Tricks die 
90-Tage Testversion mehrfach installieren aber eine weniger 
(dunkel)graue Loesung waere schoener...

Da liegt es natuerlich nahe den GCC fuer Standalone-Applikationen zu 
benutzen. Allerdings ist die Dokumentation dafuer arg spaerlich. 
http://www.section5.ch/software ist die einzige Quelle fuer 
Beispielprogramme die mir bislang untergekommen ist.

Berichtet doch mal ueber eure Erfahrungen! Benutzt jemand den Compiler 
schon so?

Wie sieht es aus mit debuggen, ich vermute mal ganz stark das ich das 
Onboard-JTAG vom EZKIT BF537 nicht mir gdb benutzen kann? (zugegeben ich 
war bislang zu faul da sebst nachzuforschen weil ich bislang VisualDSP 
benutze)

[Strubi (Gast)]

Hallo,

Es gibt auch noch eine weitere Resource mit etwas Dokumentation:

http://www.johanforrer.net/BLACKFIN/index.html

Das Onboard-JTAG der EZKITs ist in der Tat kaum nutzbar, da "closed". 
Zwar ist die Ansteuerung bei den neueren EZKITs theoretisch moeglich, da 
es sich um einen Cypress-Chip handelt, aber besonders amerikanische 
Hersteller reagieren etwas empfindlich, wenn man ihre Produkte 
reverse-engineert :-)
Abgesehen davon ist das Ding saulahm, was uns vor einiger Zeit dazu 
bewogen hat, eine eigene JTAG-Toolchain (ICEbear / gdbproxy-Portierung) 
zu machen.

Funktioniert eigentlich genauso wie die freien msp430-gcc-Tools - fuer 
die, die's kennen. Also JTAG anstecken, gdbproxy starten, mit dem 
Insight (grafischem GDB) drauf connecten (per "target remote"). Gibt 
auch unter blackfin.uclinux.org ne Parallelport-Version davon, 
allerdings ist die weniger stabil (dafuer billig). Bietet 
Sourcecode-Debugging wie unter VDSP, und sogar etwas mehr per Scripting, 
was grade nuetzlich ist, wenn man Register auflisten oder z.b. Bits als 
Flag-Namen ausgeben will.

Die Standalone-Schiene wird von den uClinux-Leuten leider wirklich etwas 
stiefmuetterlich behandelt. Das Problem war aber frueher nur eine 
fehlender vernuenftige libc, inzwischen kann man ganz gut die newlib 
verwenden. Damit ist das ganze nicht mehr wirklich Blackfin-spezifisch, 
wenn man die entsprechenden Setuproutinen beachtet, ergo findet man 
Dokumentation auf allen moeglichen Seiten zu Standalone-Programmierung 
von ARM7-CPUs.

Wuerde mich auch mal interessieren, wie das Feedback so zum 
"standalone"-Support ist. Trotz uClinux-lastiger Projekte mache ich doch 
noch recht viel standalone, das Prototyping der Linux-Treiber geschieht 
meist erst mal mit dem oben veroeffentlichten "shell"-Program.

Ich habe von einigen Roboterbastlern aus den Staaten (siehe auch 
www.surveyor.com) vernommen, dass sie fast nur "standalone" machen 
(Robotersteuerung, JPEG-Kompression der Live-Kamerabilder, ...)

Generell stelle ich fest, dass viele, die mal eben "schnell" was mit dem 
Blackfin machen wollen, vor der GNU-Toolchain zurueckschrecken. Bei 
groesseren Projekten allerdings stellt sich raus, dass der GNU-Compiler 
die effizientere Alternative ist und sich der Aufwand meiner Meinung 
nach auszahlt. Was ich allerdings nicht machen wuerde: ein Projekt von 
VDSP nach GNU portieren (und schon gar nicht umgekehrt).

Gruss,

- Strubi

[T. H. (pumpkin)]

Moin,

also ich habe mich, nach langem Zögern und Zaudern, endlich mal 
rangemacht mich mit dem GCC für den Blackfin zu beschäftigen. Die 
Wiki-Pages von

  http://blackfin.uclinux.org/

sind teilweise schlimmer als stiefmütterlich .

Mein erstes Ziel ist es, bare metal (standalone) Applikationen für den 
Blackfin zu bauen - und zwar auf einer Windoze. Hierzu habe ich in die 
aktuelle Eclipse (Ganymede) die Blackfin-Plugins eingebunden. Zusätzlich 
die aktuelle Blackfin-Toolchain für Win installiert:

  http://blackfin.uclinux.org/gf/project/toolchain/frs/

Da ich mir nicht sicher war und auf der sicheren Seite sein wollte habe 
ich zusätzlich coLinux installiert (Ist das für bare metal nötig? Ich 
denke nicht. Ist es für den Upload zum Board nötig?):

  http://blackfin.uclinux.org/gf/project/bfin-colinux/frs

Nach einigen Versuchen hats dann geklappt ein erstes Testprojekt auf 
Basis der Blackfin-Toolchain zu erstellen:

#include <cdefbf537.h>

int
main(void)
{
  *pPORTGIO_CLEAR = 0x0000;

  while( 1 );
  return( 0 );
}

Kompiliert unter Eclipse in Win:

make all 
Building file: ../main.c
Invoking: Blackfin ELF C Compiler
bfin-elf-gcc -O0 -g3 -Wall -c -fmessage-length=0 -mcpu=bf537-0.2 -MMD -MP -MF"main.d" -MT"main.d" -o"main.o" "../main.c"
Finished building: ../main.c
 
Building target: bftest1
Invoking: Blackfin ELF C Linker
bfin-elf-gcc -mcpu=bf537-0.2 -o"bftest1"  ./main.o   
Finished building target: bftest1

Freude! Scheint ja zu laufen. Aber, wie gehts weiter? Ich sehe im 
Verzeichnis keine ELF oder ähnliches. Wenn ich das richtig sehe kann ich 
aus dem ELF ein LDF + x machen (Was VisualDSP dann draufschieben kann? 
Oder wie oder was?). Das Wiki lässt mich im Dunkeln - da passt nichts 
zusammen. Die hier

  http://docs.blackfin.uclinux.org/doku.php?id=toolchain:eclipse

beschriebenen Schritte sind mir ebenso suspekt - verstehe ich das 
richtig, dass ich diese Sachen nur für ucLinux brauche?

Ein paar Schubser in die richtige Richtung wären nett...   :^)

[FL (Gast)]

Hallo,

hier auch meine Erfahrungen mit der GNU-Toolchain für Standalone:

Ich benutzte das ganze auf einem Linux-Host und habe mir den 
JTAG-Debugger von Strubi (http://www.section5.ch) zugelegt. Im Moment 
debugge ich damit auf einem ADSP-BF537-STAMP-Board, bald wird der 
Wechsel auf eine eigene Platine erfolgen (mal sehen, ob das auf Anhieb 
klappt...)

Nach einigen Anfangsschwierigkeiten funktioniert das ganze jetzt 
zuverlässig und auch einigermaßen komfortabel (mit insight).

Mein Fehler am Anfang war, dass ich auch die von der uClinux-Webpage 
stammenden Version von gdbproxy (ein kleines Programm, das zwischen gdb 
und dem JTAG-Adapter vermittelt) installiert hatte und versehentlich 
diese statt der Version von Strubi verwendet habe. Da stimmten dann 
Registerzuordnungen nicht und der Prozessor verhielt sich im 
Debugging-Modus total anders als erwartet.

Ansonsten kann ich nur zustimmen, dass Doku für Standalone nur sehr 
spärlich zu finden ist. Die wichtigste Informationsquelle ist meist das 
"Hardware Reference Manual" und die "Programming Reference" des 
Prozessors, ansonsten muss man hoffen, dass man irgendwo Infos über 
Google findet...
Ich vermisse bisher vor allem ein "printf", welches Ausgaben an den 
RS232-Port schickt -- bei Verwendung von printf aus der newlib gibt es 
Fehler zur Compile-Zeit, so dass ich eigene Ausgaberoutinen geschrieben 
habe, die aber bisher deutlich weniger komfortabel sind als die 
formatierte Ausgabe über "printf".

Mit den Tools von Strubi habe ich aber bisher nur gute Erfahrungen 
gemacht (abgesehen davon, dass oben beschriebener Anfängerfehler 
vielleicht im Benutzerhandbuch des ICEbear-Adapters aufgeklärt werden 
sollte ;-) )

Ansonsten sieht mein Workflow so aus:
- Das STAMP Board ist über Ethernet mit dem Entwicklungs-Hostrechner 
verbunden; die RS232-Schnittstelle des STAMPs hängt am COM-Port des 
Hostrechners, auf diesem läuft ein Terminal-Programm, um mit dem Board 
über "TTY" zu kommunizieren.
- Kompilieren und Linken des Codes mit dem Aufruf von "bfin-elf-gcc" 
(die "standalone-Toolchain" von http://blackfin.uclinux.org)
- Starten des U-Boot-Bootloaders auf dem STAMP-Board (der ja schon im 
Auflieferungszustand im Flash steht, ansonsten kann man ihn auch mit 
Strubis Tools Flashen)
- Über die Netzwerkschnittstelle des STAMP-Boards (TFTP) die erzeugte 
ELF-Datei ins SRAM des STAMP-Boards laden ('tftp 0x1000000 <dateiname>)
- Die Datei mittels 'bootelf 0x100000' starten

Gruß
Frank

[FL (Gast)]

Ein "Ärgernis" der Standalone-Toolchain habe ich noch vergessen:

im Wiki ist beschrieben, dass man mittels

__attribute__ ((l1_data_A));
__attribute__ ((l1_data_B));

Variablen in die Bereiche A und B des internen Data RAM des Blackfin 
"verteilen" kann, was sehr wichtig für effektive 
Signalverarbeitungsroutinen ist. Dies funktioniert aber für die 
Standalone-Toolchain nicht -- alle Variablen landen im Bereich A.
Laut Aussage im Forum von blackfin.uclinux.org ist die Funktionalität in 
der Standalone-Toolchain nicht implementiert, und man müsse ein eigenes 
Linkerscript schreiben, um Daten auch in den Bereich B zu kriegen.

Da ich bisher noch nichts mit Linker-Skripten gemacht habe und ich mich 
erst mal durch die GCC-Doku wühlen müsste: Hat schon jemand solches 
gemacht oder eine andere komfortable Möglichkeit gefunden, Daten in den 
Bereich B zu kriegen (außer die Speicheradressen "hart" zu kodieren)?

Gruß
Frank

[T. H. (pumpkin)]

Mmmh, das hatte ich schonmal gelesen und mir schlechte Laune bereitet. 
:^|


Ich habe keinen JTAG. Heute habe ich mich mal an Das U-Boot gemacht und 
das hier

  http://docs.blackfin.uclinux.org/doku.php?id=bootloaders:u-boot:loading

beschriebene Tutorial auf meiner Windoze durchgehackt. Leider mit wenig 
Erfolg wie mir scheint. Schritt für Schritt:

1.)Board auf UART Boot gestellt.
2.)http://blackfin.uclinux.org/gf/download/frsrelease/373/3962/u-boot-bf537-stamp-uart-2008R1.ldr 
organisiert.
3.)LDRViewer organisiert.
4.)Mit LDRViewer die Datei aus 2. auf das Board geschoben. Bin nicht 
sicher obs klappt, nach dem done kommt kein Output wie er im Wiki 
(http://docs.blackfin.uclinux.org/lib/exe/fetch.php?w=&h=&cache=cache&media=uboot-uart-boot.png) 
zu sehen ist.
5.)Connecten mit HyperTerminal - keine Reaktion. Versucht eine DXE zu 
senden - keine Reaktion.

Ich steh' auf dem Schlauch und bin verwirrt.

[FL (Gast)]

Hi T.H.,

ich habe Deine Schritte gerade einmal nachvollzogen und kann Dein 
Problem nicht reproduzieren. Bei mir sendet der Blackfin bei Punkt 4 
eine Antwort, und Hyperterminal kann anschliessend mit u-boot 
kommunizieren.

Hast Du auch ein STAMP-Board? Bist Du sicher, dass Du kein 
Hardware-Problem hast (z.B. den Loopback-Jumper auf dem Board gesetzt, 
serielles Kabel defekt etc.?)

[T. H. (pumpkin)]

Moin FL,

einen Defekt des Kabels kann ich ausschließen, Loopback ist auch aus - 
alles schon abgeklopft.

Allerdings habe ich kein STAMP, ich habe das EZ-Kit des 537er. Irgendwo 
im Wiki heißt es, dass das kein Problem darstellen sollte.

Welchen Output bekommst du nach dem Load aufs Board?

Was tust du, um dich zu connecten - einfach nur die Verbindung 
herstellen?

Cheers

[T. H. (pumpkin)]

Aha, dummerweise hatte ich RTS für ein anderes Projekt abgeschaltet. 
Jetzt zieht er durch. Konfiguration SW4:

 1 = On (CTS)
 2 = On (RX)
 3 = On (RTS)
 4 = Off (Loopback)

So, welche Dateitypen (bfin-elf-gcc) kann ich nun direkt mit U-Boot 
draufladen (DXE, ELF, LDR, ...?)? Ich habe hier eine Datei ohne Endung, 
am Anfang steht in der Datei "ELF".

[FL (Gast)]

Dann ist's wohl eine ELF-Datei, entsprechend solltest Du wie ich schon 
oben beschrieben habe eine Datei laden können:
- Über die Netzwerkschnittstelle des STAMP-Boards (TFTP) die erzeugte
ELF-Datei ins SRAM des STAMP-Boards laden ('tftp 0x1000000 <dateiname>)
- Die Datei mittels 'bootelf 0x100000' starten


Wenn das Netzwerk bei Dir noch nicht läuft, musst Du es entweder in 
U-Boot konfigurieren oder Dir die Datei anders aufs Board laden (z.B. 
über die serielle Schnittstelle, U-Boot ist da recht flexibel...)


P.S. Unter Linux gibt es das Kommando 'file <dateiname>', das recht 
zuverlässig den Dateityp von <dateiname> ausgibt. Bei Deiner Datei 
sollte da herauskommen, dass es ein ELF-File für die Blackfin-Plattform 
ist.

Gruß
Frank

[Martin S. (strubi)]

Hi Frank

Zu deiner Frage bzgl. Zuordnung der Variablen in Speicherbereiche:


>
> Da ich bisher noch nichts mit Linker-Skripten gemacht habe und ich mich
> erst mal durch die GCC-Doku wühlen müsste: Hat schon jemand solches
> gemacht oder eine andere komfortable Möglichkeit gefunden, Daten in den
> Bereich B zu kriegen (außer die Speicheradressen "hart" zu kodieren)?
>
>

Um die Linker-Scripte kommst du kaum herum, und mit harter Codierung 
kann man sich ins Knie schiessen :-)
Haette Dir allerdings ein simples Beispiel unter:

http://section5.ch/dsp/blackfin/blinky.tgz

In bf561_singleblink.c findest du die entsprechenden 
__attribute__-Anweisungen, um Code explizit in die im Linker-Script 
(bf561.x) definierten Sections zu plazieren.

Bin auch etwas ernuechtert ueber die diversen Ansaetze von den 
uClinux/ADI-Leuten, die standalone-Toolchain etwas nutzerfreundlicher zu 
gestalten. Im Endeffekt laeuft's wohl drauf raus, dass jeder seinen Kram 
(sprich Linkerscripte und startup.asm) fuer sein eigenes Board selber 
strickt. Am besten bedient man sich bei u-boot, oder bei den diversen 
anderen Standalone-Beispielen (bei www.surveyor.com gibt's auch Source 
fuer deren SRV1-Roboter).

Schoene Gruesse,

- Strubi

[FL (Gast)]

Hallo Strubi,

hierzu noch eine Frage:

verwendest Du U-Boot als Bootloader für Standalone-Projekte, oder 
würdest Du davon prinzipiell abraten und lieber einen eigenen simplen 
Bootloader schreiben?
Ich stehe gerade vor der Frage, ob ich U-Boot für ein eigenes Board 
anpassen soll oder lieber eine eigene Boot-Methode "von Scratch" 
aufsetzen soll.

Gruß,
Frank

[Martin S. (strubi)]

Hi Frank,

ich finde u-boot ganz ok, ist zwar fast schon ein Betriebssystem :-) 
aber sehe keinen Grund, warum man nen eigenen Bootloader basteln sollte, 
ausser es gaebe erhebliche Platzprobleme oder ganz exotische Hardware 
ohne SDRAM.
Oder die Firma mag keine GPL-Software...
ELF und LDR files kann man prima von u-boot laden, das muesste man sonst 
auch erst mal von Hand stricken...praktisch finde ich auch die 
Environment-Variablen um Nutzer-Einstellungen abzuspeichern.
Gibt sonst auch Alternativen wie RedBoot, usw, aber bin da nicht auf dem 
Stand, wie's mit Portierungen aussieht.

Viel Erfolg & schoene Gruesse,

- Strubi

[Strubi (Gast)]

Hallo an alle 'standalone'-Hacker,

habe mal ne 1.0-Version der Shell hochgeladen, wurde mal Zeit, wieder 
alles auf den Stand zu bringen. Habe allerdings nicht alles getestet, 
aber vielleicht mag ja jemand Feedback liefern :-)
Änderungen:

- Die Doxygen-Doku wurde verbessert
- Boardspezifischer Code in eigene Directories verfrachtet
- Diverse Hardware-Ansteuerungs-Beispiele hinzugefügt/verbessert (PPI, 
TWI, SPI, etc.)

Zum Compilieren benötigt man: Eine mindestens 2007er-Release 
bfin-elf-toolchain (für Debian gibts fertige Pakete).

Habe das ganze nur mit dem ICEbear getestet. Man könnte die shell 
theoretisch auch aus u-boot raus starten, aber dazu muessten alle 
bfp_msg()-Aufrufe entfernt werden, da das Programm sonst haengenbleibt. 
Zudem wären ev. noch ein paar Änderungen im Startup-Code nötig.
Falls das jemand mal umstricken wollte, wuerd ich mich um Rückmeldung 
freuen.

Der ganze Krempel liegt nach wie vor über ein paar Klicks unter 
http://www.section5.ch/software (die Links ändern so alles halbe Jahr 
mal, drum müsst ihr euch leider durchs Forum hangeln)

Schöne Grüsse,

- Strubi

[T. H. (pumpkin)]

Tach auch!

Nach längerer Abstinenz habe ich mal wieder (nunmehr erfolgreich auf 
Linux) mit dem bfin-gcc bare metal gestartet. Um gleich etwas 
sinnvolles zu machen will ich eine noch im Wachstum befindliche 
Applikation von VDSP portieren. Klar ist, dass man nicht unbedingt jede 
Extension vom VDSP portieren kann/will. Aber eines macht mich stutzig, 
folgendes stammt aus VDSP:

// SPDIF.h

#include <sys/exception.h>

// ...

EX_INTERRUPT_HANDLER(SPORT01_RXTX_ISR);

// ...

// SPDIF_Interrupts.c

#include "SPDIF.h"

// ...

void
SPDIF_InitDMAInterrupts(void)
{
  // ...

  register_handler(ik_ivg9, SPORT01_RXTX_ISR);
}

Nun ist im bfin-gcc Paket ebenfalls eine sys/exception.h enthalten. Ich 
habe es nicht direkt verglichen, aber der Inhalt des Headers scheint 
ziemlich direkt aus VDSP zu kommen. Wie dem auch sei, der Compiler 
nörgelt und der Linker meckert:

Compiler (Ausschnitt):

bfin-elf-gcc -I./include/ -g -mcpu=bf537 -std=gnu99 -Wall -pedantic   -c -o SPDIF_Transmitter.o SPDIF_Transmitter.c
In file included from SPDIF_Transmitter.c:28:
./include/SPDIF.h:130: Warnung: #pragma interrupt  wird ignoriert

Linker (Ausschnitt):

bfin-elf-ld -T bftiny.x -o ac3.dxe crt0.o main.o AC3_Process.o IEC61937_Process.o SPDIF_AnalogDigitalConverter.o SPDIF_AudioClock.o SPDIF_DigitalAnalogConverter.o SPDIF_Interrupts.o SPDIF_ProcessData.o SPDIF_Receiver.o SPDIF_Transmitter.o
SPDIF_Interrupts.o: In function `SPDIF_InitDMAInterrupts':
/media/DATEN/Blackfin_Projekte/Blackfin AC-3/bfin-gcc/SPDIF_Interrupts.c:83: undefined reference to `register_handler'

Ich habe gegen alles im bfin-gcc-Paket enthaltene gelinkt, ohne Erfolg. 
In der Doku habe ich nichts gefunden, ich gehe also davon aus, dass 
diese Funktion gar nicht implementiert ist...? Würde mich nicht stören, 
man muss es halt nur wissen - aber wenn dem so ist, warum ist dann der 
Header inklusive dieser "Altlasten" enthalten?

Cheers
TH

[Strubi (Gast)]

Hi TH,

fuer "bare metal" musst Du dein Interrupt-Handler-Environment selber 
machen. Ich bin mir nicht sicher, ob es inzwischen eine brauchbare 
"attribute ((interrupt))"-Spezifikation fuer standalone bfin-elf gibt - 
habe bisher die irq handler von Hand in Assembler gewrappt.
Die 'Altlasten' sind vermutlich irgendwelche VDK-Kernel-Konstrukte und 
wurden womoeglich nicht entsprechend bereinigt. Waere aber interessant, 
fuer gewisse Hardware ein Board supply package anzubieten (ich glaube, 
das kaeme in die libgloss rein..) um VDSP-kompatible Source-Portierung 
zu erleichtern.
Poste doch mal deine Erfolge :-)

Gruss,

- Strubi

[T. H. (pumpkin)]

Moin Strubi,

danke für dein Feedback - das dachte ich mir.

Habe mal ein wenig rumgemacht und meine App umgestellt. Mit

void IRQ() __attribute__ ((interrupt_handler));

geht es wie im GCC Manual beschrieben. Viel weiter bin ich diesbezüglich 
nicht gekommen - ich als Neuling mit GDB auf Kommandozeile, das ist 
schon ziemlich spannend. ;^)
Irgendwie bekomme ich den grafischen Insight (in Verbindung mit dem 
ICEbear) nicht angeschmissen, es passiert rein garnichts. Kannst du die 
Prozedur kurz schildern (ich muss irgendwo einen blöden Fehler 
machen...)?

Bzgl. eines Event-"Wrappers" wäre meiner Meinung nach ein Header mit den 
Prototypen und eine c-Source mit den Stubs ausreichend um die EVT 
initialisieren zu können und gleichzeitig komfortabel genug. Ähnlich wie 
in der crt0.asm vom blinky-Beispiel - halt nur umgebogen auf C. Wie man 
das VDSP-like machen könnte - keine Ahnung.

[Martin S. (strubi)]

Hi TH,

kann es sein, dass Du mit Ubuntu faehrst? Wenn sich dort der Insight 
nach dem Aufruf einfach kommentarlos wieder beendet, liegt's daran, dass 
er folgende Variable gesetzt haben will:

export GDBTK_LIBRARY=/usr/share/insight1.0

Muss irgend eine Zickigkeit der TCL/TK-Variante im Ubuntu sein. Am 
besten obigen Befehl in die .bashrc klatschen.
Bei Erfolg muesste sich die GUI zeigen. Der Rest (connect auf den 
Target, etc). ist im ICEbear-Manual beschrieben.

Die Sache mit dem Event-Wrapper ist ne gute Idee, aber ich hab an der 
Baustelle schon lange nix mehr gemacht, da ich mich momentan eher mit 
uClinux austobe. Aber gut zu wissen, dass das mit den attributes nun 
funktioniert.

Gruss,

- Strubi

[T. H. (pumpkin)]

Sehr schön, jetzt klappt Insight. Allerdings habe ich hier ein Problem 
Register anzuzeigen (du hast es ja im Manual beschrieben). Hier mal die 
Kommandozeilenversion, die gleiche Meldung kommt im Watch-Window:

(gdb) x *$SIC_ISR
Error: Attempt to take contents of a non-pointer value.

Okay, Kontrolle:

(gdb) x 0xffc00120
0xffc00120:  0x20000084

Irgendeine Idee was schief läuft?


Ich kann mich ja mal dran machen die Stubs, den Header und crt0 zu 
schreiben.

Cheers
TH

[Strubi (Gast)]

Hi TH,

du musst die entsprechenden GDB-Scripte laden:

source /usr/share/gdbscripts/mmr.gdb

Sollte eigentlich auch wo im Manual stehen.

Gruss,

- Strubi

[T. H. (pumpkin)]

Wer lesen kann...

Danke.

[Strubi (Gast)]

Achja, apropos, fiel mir gerade noch auf:

Man sollte nicht mit "x" (long word examine) auf die MMRs zugreifen, da 
koennen boese Sachen passieren (illegale Zugriffsbreite mag der Blackfin 
manchmal nicht).
Also besser mit Type cast und printf a la:

print ( (unsigned long *) 0xffc00120)[0]

Das aber nur so am Rande :-)

[T. H. (pumpkin)]

Danke für den Hinweis Martin.

FL wrote:
> Da ich bisher noch nichts mit Linker-Skripten gemacht habe und ich mich
> erst mal durch die GCC-Doku wühlen müsste: Hat schon jemand solches
> gemacht oder eine andere komfortable Möglichkeit gefunden, Daten in den
> Bereich B zu kriegen (außer die Speicheradressen "hart" zu kodieren)?


Ich habe mich an ein Linkerscript für den BF537 gesetzt um auch Bank B 
benutzen zu können. Anreiz gab mir

  http://blackfin.uclinux.org/gf/project/bfin-docs/mailman/?action=ListThreads&mailman_id=29&_forum_action=ForumMessageBrowse&thread_id=31296

Hier ein Linkerscript für den BF537:

/* 
 * Customized linker script for BF537.
 *
 * 2008, pumpkin
 *
 */

OUTPUT_FORMAT("elf32-bfin", "elf32-bfin", "elf32-bfin")
OUTPUT_ARCH(bfin)
ENTRY(start)


MEMORY
{
  l1code(x)     : ORIGIN = 0xffa00000, LENGTH = 48K

  l1data_a(rw)  : ORIGIN = 0xff800000, LENGTH = 32K
  l1data_b(rw)  : ORIGIN = 0xff900000, LENGTH = 32K
}


SECTIONS
{
  /* L1 memory sections */
  .l1code      : { crt0.o(STARTUP_SECTION) *(.l1code) } > l1code
  .l1.data.A   : { _l1_data_a = .; }                    > l1data_a
  .l1.data.B   : { _l1_data_b = .; }                    > l1data_b
  .l1.data     : { _l1_data = .; }                      > l1data_a


  .text        : { *(.text) }                           > l1code
  .bss         : { *(.bss) *(COMMON) }                  > l1data_a

  /DISCARD/   : { *.(comment) }
}

Die Deklaration erfolgt mit:

uint16_t usFoo __attribute__ ((l1_data_A)) = 0x1111;
uint16_t usBar __attribute__ ((l1_data_B)) = 0x2222;
uint16_t usBaz __attribute__ ((l1_data)) = 0x3333;

Wie im Screenshot zu sehen ist, landen die Variablen wie gewünscht in 
Bank A (usFoo und usBaz) bzw. Bank B (usBar).

Was ich nicht hinbekommen habe ist ein sensitives Mapping nach Bank A 
oder B, je nachdem ob Bank A voll ist - soweit bin ich nicht in die 
Untiefen des Linkerscriptings vorgedrungen. So wird es lediglich in Bank 
A gemapped. Vllt kann ja einer der GCC-Experten hierzu eine Meinung 
abgeben.  :^)

Cheers
TH

[T. H. (pumpkin)]

Moin moin!

Hier ein Nachtrag zum Thema Interrupt-Stubs in C und Startup-Code. Der
Startup-Code basiert auf Strubi's crt0.asm aus dem blinky-Beispiel. Die
einzelnen Event-Stubs befinden sich in der events.c (komplettiert durch
events.h).

Cheers
TH

[blkfn (Gast)]

Hallo
sorry das ich das alte thema ausgrabe

ich versuche gerade krampfhaft die sections hinzubekommen
ich war es von VDSP++ gewohnt das man sich net wirklich drum kümmen muss 
:/

da vdsp++ aber kein .ELF rauswirft welches der uboot nimmt..
dachte ich an ein kompilat mit dem GCC

gibt es mitlerweile einige linkerscripte für passende sections?
also auch für externen SDRAM ?

[Martin S. (strubi)]

Hi,

hab mal eins angehängt. Per default geht das .text-Segment ins SDRAM. 
Ein paar Files werden explizit ins l1 SRAM (l1code) alloziert, das musst 
Du entsprechend ändern.

Gruss,

- Strubi

[blkfn (Gast)]

danke schön
ich versuch mich daram mal zu orientieren


gibt es sonst noch andere methodem um eventuell ein VDSP++  DXE oder LDR
mit uboot zu laden?

meine bisher erstellten hängen sich leider entweder beim laden auf oder 
starten erst garnicht
das LDR selbst geht jedoch problemlos wenn man es per JTAG reinflasht


ich glaub ja auch das es einfacher ist wenn man es mal hinbekommen hat..
aber der weg dahin ist einfach mal extrem steinig ...
zumal man leider nicht viel informationen seitens Analog bekommt was 
VDSP++ <-> Uboot  angeht
oder auch standalone GCC ...

schade

[Martin S. (strubi)]

>
> gibt es sonst noch andere methodem um eventuell ein VDSP++  DXE oder LDR
> mit uboot zu laden?

Ja, ein mit VDSP gebautes LDR kannst du auf dem BF537 mit einem Aufruf 
einer ROM-Routine laden. Sollte, wie ich glaube, sogar als Befehl 
implementiert sein. Da VDSP++ seit v4.0 aber den ELF-Standard verletzt 
(warum auch immer), kann man keine DXEs laden.

>
> meine bisher erstellten hängen sich leider entweder beim laden auf oder
> starten erst garnicht

Du musst beim LDR die Initialisierung beachten. SDRAM muss bei u-boot 
nicht neu initialisiert werden, aber du musst ev. cache und memory map 
genauer anschauen. Im prinzip musst du dein Programm an die 
u-boot-Umgebung anpassen. Ich wuerde mal mit dem JTAG schauen, wo's 
knallt.

> das LDR selbst geht jedoch problemlos wenn man es per JTAG reinflasht
>
>
> ich glaub ja auch das es einfacher ist wenn man es mal hinbekommen hat..
> aber der weg dahin ist einfach mal extrem steinig ...
> zumal man leider nicht viel informationen seitens Analog bekommt was
> VDSP++ <-> Uboot  angeht
> oder auch standalone GCC ...
>

Das ADI-Management verfolgt IMHO eine ziemlich bescheuerte Politik und 
scheint nicht zu kapieren, dass ein gewichtige Nutzercommunity gerne auf 
GCC migrieren würde... Kann man nichts machen. Wen du aber mit Fragen 
quaelen kannst: die Jungs auf blackfin.uclinux.org (immerhin eine Gruppe 
innerhalb ADI).

Gruesse,

- Strubi

[blkfn (Gast)]

Martin S. schrieb:
>>
>> gibt es sonst noch andere methodem um eventuell ein VDSP++  DXE oder LDR
>> mit uboot zu laden?
>
> Ja, ein mit VDSP gebautes LDR kannst du auf dem BF537 mit einem Aufruf
> einer ROM-Routine laden. Sollte, wie ich glaube, sogar als Befehl
> implementiert sein. Da VDSP++ seit v4.0 aber den ELF-Standard verletzt
> (warum auch immer), kann man keine DXEs laden.

ich hab mich mal an die angaben gehalten...habe ein uboot mit bootldr 
funktion drauf. leider bleibt er bei :

bfin> fatload mmc 0:1 0x1000000 /test.ldr
reading /test.ldr

409682 bytes read
bfin> bootldr
## Booting ldr image at 0x01000000 ...

hängen
mal schauen was da schief läuft
ich denk mal da ist definitv was mit dem speicher im argen :/



> Das ADI-Management verfolgt IMHO eine ziemlich bescheuerte Politik und
> scheint nicht zu kapieren, dass ein gewichtige Nutzercommunity gerne auf
> GCC migrieren würde... Kann man nichts machen. Wen du aber mit Fragen
> quaelen kannst: die Jungs auf blackfin.uclinux.org (immerhin eine Gruppe
> innerhalb ADI).

aber danke für die hilfe ...
ich werde mal weitersuchen
irgendwann wirds hoffentlich mal gehen

[blkfn (Gast)]

hi

hab es jetz hinbekommen
etwas triky mit den VDSP++ einstellungen ...
aber es geht mit bootldr