Leon3 GRLIB No rule to make target

Ok ich habs musste mit cd den Pfad ansteuern und dann den make Befehl 
ausführen.
Ich hoffe ab jetzt gehts einigermaßen gut weiter.

tm schrieb:
> Ich hab vorher noch nie wirklich cygwin genutzt und auch der LEON
> Processor ist mir neu.
Das sind ja dann zwei Baustellen. Mit FPGA und VHDL kennst Du Dich aber 
schon aus, oder?

Duke

@ Duke Scarring

Ja mit VHDL und FPGA's hab ich bereits Erfahrung.
Hab jetzt auch die ersten Testdesigns mit dem LEON kompiliert bekommen 
:)

Ich tue mich allerdings halt noch etwas mit der GRLIB schwer, allerdings 
bin ich auch noch nicht mit dem User Manual durch.

tm schrieb:
> Ja mit VHDL und FPGA's hab ich bereits Erfahrung.
Gut.

> Hab jetzt auch die ersten Testdesigns mit dem LEON kompiliert bekommen
> :)
Hast Du auch passende Hardware zum Testen?

> Ich tue mich allerdings halt noch etwas mit der GRLIB schwer, allerdings
> bin ich auch noch nicht mit dem User Manual durch.
Hast Du ein Ziel? Was willst Du mit grlib/leon3 machen?

Duke

Duke Scarring schrieb:
>> Hab jetzt auch die ersten Testdesigns mit dem LEON kompiliert bekommen
>> :)
> Hast Du auch passende Hardware zum Testen?
>
>> Ich tue mich allerdings halt noch etwas mit der GRLIB schwer, allerdings
>> bin ich auch noch nicht mit dem User Manual durch.
> Hast Du ein Ziel? Was willst Du mit grlib/leon3 machen?

Hey,

Eine Hardware zum Testen ist vorhanden und dies ist nun der nächste 
Schritt.

Das nächste Ziel wäre für mich erstmal ein paar LED's auf dem Board 
(Cyclone 3 Starter Board) via LEON3 und GPIO's zum leuchten zu bringen.

Allerdings erkennt der GRMON bisher noch nicht den USB-Blaster.
Ich vermute dies liegt daran das die ganzen Programme nicht den 
richtigen Pfad nach Quartus haben und somit nicht auf die JTAG dll 
zugreifen können.

Zumindest deutet der Fehler

1

Could not open jtag_client.dll

darauf hin.

Als übergeordnetes Ziel möchte ich einen eigenen AHB Slave integrieren.

Gruß Tobias

tm schrieb:
> Das nächste Ziel wäre für mich erstmal ein paar LED's auf dem Board
> (Cyclone 3 Starter Board) via LEON3 und GPIO's zum leuchten zu bringen.
Ok.

> Allerdings erkennt der GRMON bisher noch nicht den USB-Blaster.
Evtl. kannst Du grmon über RS232 mit dem Leon verbinden. Ich hatte mit 
dem Xilinx-JTAG auch so meine Probleme.

Duke

Hey,

Ich bekomme nun tatsächlich eine Verbindung zwischen GRMON und Leon3 auf 
dem FPGA hin.

Leider bekomme ich bisher kein einziges Programm am laufen.
Ich bekomme ja von dem xconfig eine header Datei in der die 
Configuration meines Leon Systems drin steht oder? Ich verstehe 
irgendwie nicht ganz wie ich das ganze einbinden muss?
Ich hab einfach mal versucht die GPIO direkt über die adresse 
anzusteuern so in diese Richtung aber auch das erfolglos GRMON meldet 
mir corrupt stack

1

*(int*)0x80000500 = 0xFF; //0x80000500 ist meine LED Baseadress

Gibt es da kein Programming Guide oder irgendetwas in der Richtung von 
Gaisler?

Gruß Tobias

Hey,

Hab bemerkt das das oben genannte dadurch das es ja IO sind ein bisschen 
komplizierter ist, aber eigentlich nicht viel!
Ich habe jetzt einfach mit GRMON die IO Register ausgelesen und schreibe 
direkt in diese. Das Programm schein im Debugger auch das zu machen was 
es soll nur aus irgendeinem Grund auf der Hardware nicht hat vielleicht 
jemand eine Idee was ich falsch gemacht haben könnte?

1

int main()

2

{

3

volatile unsigned int *pio_data= (int *)0x80000500;

4

volatile unsigned int *pio_out = (int *)0x80000504;

5

volatile unsigned int *pio_dir = (int *)0x80000508;

6

*pio_dir = 0xFFFF; /* Set direction to output */

7

*pio_out = 0x0000; /* Set outputs low */

8

return 0;

9

}

Gruß Tobias

Hey,

Ich hab den oben genannten Code zum laufen gebracht. Der Fehler war im 
Exampledesign also auf der Hardwarebeschreibungsseite.

Auch erste Versuche mit der timer.h haben gut funktioniert und die LED's 
sind nun am blinken.

tm schrieb:
> Ich hab den oben genannten Code zum laufen gebracht.
Ich hätte jetz am Code auch nichts Verdächtiges entdeckt.

> Der Fehler war im
> Exampledesign also auf der Hardwarebeschreibungsseite.
Was war es denn? Es muß ja nicht jeder Deinen Fehler wiederholen?

Duke

P.S.: Ich habe mir für die IP-Cores entsprechende structs angelegt:

1

typedef struct {

2

    volatile uint32_t iodata;   // 000

3

    volatile uint32_t ioout;    // 001

4

    volatile uint32_t iodir;    // 010, for bidir port bits

5

    volatile uint32_t irqmask;  // 011

6

    volatile uint32_t irqpol;   // 100

7

    volatile uint32_t irqedge;  // 101

8

    volatile uint32_t bypass;   // 110

9

} grgpio_t;

10

...

11

grgpio_t          *gpio0      = (grgpio_t *)   0x80000400;

12

...

13

gpio0->ioout = 0x000000ff & pattern;

Hey,

War eigentlich was dämliches im Exampledesign von Gaisler wurden die IO 
Ports genutzt um Buttons einzulesen.
Ich hab dann einfach daraus einen Output gemacht und die Zeile in der 
Top die die das IO_data register beschreibt auskommentiert.

Man muss aber natürlich noch eine Zeile hinzuschreiben welche die 
gpioo.dout("Registerlänge") beschreibt und das hatte ich vergessen.

Besten Dank nochmal für die Tipps.

Gruß Tobias

Ja, die IO-Ports der grlib sind mit "bells and whistles". 
Richtungsumschaltung, Synchronisation, alternative Belgeung etc. pp. da 
kann einem leicht schwindlig werden :-)

> Man muss aber natürlich noch eine Zeile hinzuschreiben welche die
> gpioo.dout("Registerlänge") beschreibt und das hatte ich vergessen.
Mit einem SoftCore gibt es gleich noch eine Fehlerquelle mehr. Da müssen 
Hardware und Software zusammenspielen...

Duke

Hey,

Ich kann dir leider nur erklären wie es unter Windows war aber 
vielleicht hilft es ja. Ich hab um ein erstes Design in die 
Entwicklungsumgebung zu kommen per Cygwin (da ja Windows) mir ein Design 
aus dem desings ordner ausgesucht und per cd angesteuert anschließend 
hab ich make xconfig ausgeführt und danach da ich ein Altera Design habe 
make quartus-launch.
Den Befehl gibt es auch für die ise.

Gruß Tobias

René D. schrieb:
> Hat jemand da noch eine Info?
Im doc-Verzeichnis gibt eine grlib.pdf, die sollte man sich mal in Ruhe 
zu Gemüte führen.

Am einfachsten ist es, wenn man Hardware hat, die direkt unterstützt 
wird. Dazu einfach mal einen Blick in den designs-Ordner werfen.
Ansonsten sucht man sich dort was aus, was dem eigenen Board am nächsten 
kommt und müß entsprechende Anpassungen vornehmen. BTDT.

Duke

Duke Scarring schrieb:
> René D. schrieb:
>> Hat jemand da noch eine Info?
> Im doc-Verzeichnis gibt eine grlib.pdf, die sollte man sich mal in Ruhe
> zu Gemüte führen.
>

Diese habe ich auch angefangen zu lesen.

Es wird in der Installation nur der Dateistrukturbaum erklärt.

Normalerweise ist es üblich mit dem Makefile im Wurzelverzeichnis die 
Makefiles  in den Unterordnern zu steuern.

Das Ungewöhnliche für mich, was das ich ein Makefile in einem 
Unterordner starten muss.

Es wollte  es eher interessehalber mal anschauen und keine große Zeit 
investieren.

dose schrieb:
> Normalerweise ist es üblich mit dem Makefile im Wurzelverzeichnis die
> Makefiles  in den Unterordnern zu steuern.
Da funktionier dann gut, wenn hinterher nur ein Ergebniss (z.B. 
ausführbare Datei) rausfällt. Bei der grlib hast Du ja für 'zig 
verschiedene Boards ein angepasstes (und konfigurierbares) Design dabei.

Duke