Important announcement: there is an English version of this forum on
Autor:
Sebastian B.
(sfreak)
Datum:
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)
Datum:
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
Autor:
T. H.
(pumpkin)
Datum:
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=toolc... 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... :^)
Datum:
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
Datum:
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
Autor:
T. H.
(pumpkin)
Datum:
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=bootl... 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... 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...) zu sehen ist. 5.)Connecten mit HyperTerminal - keine Reaktion. Versucht eine DXE zu senden - keine Reaktion. Ich steh' auf dem Schlauch und bin verwirrt.
Datum:
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.?)
Autor:
T. H.
(pumpkin)
Datum:
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
Autor:
T. H.
(pumpkin)
Datum:
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".
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Datum:
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
Autor:
T. H.
(pumpkin)
Datum:
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
Datum:
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
Autor:
T. H.
(pumpkin)
Datum:
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.
Datum:
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
Autor:
T. H.
(pumpkin)
Datum:
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
Datum:
Hi TH, du musst die entsprechenden GDB-Scripte laden:
source /usr/share/gdbscripts/mmr.gdb |
Sollte eigentlich auch wo im Manual stehen. Gruss, - Strubi
Datum:
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 :-)
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/m... 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
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
Datum:
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 ?
Datum:
Angehängte Dateien: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
Datum:
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
Datum:
> > 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
Datum:
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
Datum:
hi hab es jetz hinbekommen etwas triky mit den VDSP++ einstellungen ... aber es geht mit bootldr
E-Mail-Benachrichtigung einschalten
Neu: Seitenaufteilung einschalten