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)
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
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:
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... :^)
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
Ein "Ärgernis" der Standalone-Toolchain habe ich noch vergessen:
im Wiki ist beschrieben, dass man mittels
1
__attribute__((l1_data_A));
2
__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
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.?)
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
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".
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
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
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
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
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
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:
1
// SPDIF.h
2
3
#include<sys/exception.h>
4
5
// ...
6
7
EX_INTERRUPT_HANDLER(SPORT01_RXTX_ISR);
8
9
// ...
1
// SPDIF_Interrupts.c
2
3
#include"SPDIF.h"
4
5
// ...
6
7
void
8
SPDIF_InitDMAInterrupts(void)
9
{
10
// ...
11
12
register_handler(ik_ivg9,SPORT01_RXTX_ISR);
13
}
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):
SPDIF_Interrupts.o: In function `SPDIF_InitDMAInterrupts':
3
/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
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
Moin Strubi,
danke für dein Feedback - das dachte ich mir.
Habe mal ein wenig rumgemacht und meine App umgestellt. Mit
1
voidIRQ()__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.
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
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:
1
(gdb) x *$SIC_ISR
2
Error: Attempt to take contents of a non-pointer value.
Okay, Kontrolle:
1
(gdb) x 0xffc00120
2
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
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:
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:
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
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 ?
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
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
>> 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
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