Hi
innerhalb unserer Arbeitsgruppe versuchen wir uns an Softcores.
Mittlerweile haben wir den Microblaze (da alles Xilinx, XUP) gut im
Griff. Jetzt hatten wir mal recherchiert, inwiefern da ein Linux drauf
läuft. Bei Xilinx direkt wird das BlueCat Linux angeboten, welches für
eine Uni aber defakto viel zu teuer ist.
Hier nun die Fragen:
Kennt jemand eventuell eine OS Portierung? Wie kann man jene ins EDK
einbinden (wahrscheinlich eher nicht)? Gibt es fertige Ports für den
MicroBlaze? Wie kann man eigene Hardware Treiber (zB. GPIO Lämpchen ;-)
) in den Kernel implementieren?
Für Anregungen wäre ich sehr dankbar.
Eugi
Schlecht recherchiert sag ich da nur. Klar, wenn ihr die
"one-click-bauchpinsel-und-hintern-abwisch"-Suites nehmen wollt, kostet
das was. Die können/dürfen aber eben nur für Services und Tools Geld
verlangen. Der Kernelsource und die Laufzeitumgebung sind zwangsweise
GPL und damit kostenlos.
Nur mal so ein gaaanz kleiner Hint: Lad dir einen aktuellen
2.6er-Kernelsource und schau in den arch-Ordner ;)
Auch das hier könnte möglicherweise helfen:
http://www.uclinux.org/
Und wenn es die Bauchpinsel-Lösung sein soll:
http://www.petalogix.com/
Nur als Hinweis: Mir fällt gerade ein, dass ich mal irgendwo gelesen
hatte, dass man für größere OS und MicroBlaze auch externen RAM braucht,
da der interne BRAM nicht mehr ausreicht. Vielleicht könnte jemand, der
mehr Erfahrung hat auch etwas dazu sagen. Würde mich auch interessieren,
in welchen Fällen man mit dem internen BRAM auskommt.
eugler schrieb:> Jetzt hatten wir mal recherchiert, inwiefern da ein Linux drauf> läuft.
Ist das nicht das MontaVista Linux, was die bei den Xilinx Boards immer
mal einsetzen? Ich hatte sowas mal auf dem ML405 getestet, naja, ging
schon, aber war ein Kampf bis dahin. Leider ist das schon mehr als 3
Jahre her, da weiß ich nicht mehr viel drüber...
> dass man für größere OS und MicroBlaze auch externen RAM braucht,> da der interne BRAM nicht mehr ausreicht. Vielleicht könnte jemand, der> mehr Erfahrung hat auch etwas dazu sagen.
Sicher braucht man für Linux externes RAM. Da der Kernel allein schon so
1-1.5MB gross ist, sind für vernünftiges Arbeiten 8MB wohl die
Untergrenze. Mit Mühe gehen evtl. auch 4MB, das hat dann aber vom
Look&Feel nicht mehr viel mit Linux zu tun...
> Würde mich auch interessieren,> in welchen Fällen man mit dem internen BRAM auskommt.
Wenn man kein Betriebssystem hat ;) Ein reiner Scheduler braucht nicht
viel Platz, aber wenn es dann mit Filesystemen und Netzwerk losgeht,
sind solche Sparsysteme dann bei der Entwicklung eher hinderlich.
> Ist das nicht das MontaVista Linux, was die bei den Xilinx Boards immer> mal einsetzen?
Bei der PPC-Variante. Der Microblaze hatte recht lange keine MMU,
deshalb das uCLinux.
Georg A. schrieb:> Wenn man kein Betriebssystem hat ;) Ein reiner Scheduler braucht nicht> viel Platz, aber wenn es dann mit Filesystemen und Netzwerk losgeht,> sind solche Sparsysteme dann bei der Entwicklung eher hinderlich.
Danke für die Info Georg! Meine Idee ist, in Zukunft ein altes Microchip
PIC Projekt (64 KB Program Memory) mit MicroBlaze mit einfachem
Scheduler oder sogar mit Endlosschleife zu realisieren. Der Microblaze
wird dann mit einem LCD und einigen ADC-Interfaces in VHDL
kommunizieren. Kannst Du mir da einen Spartan-3A/E empfehlen, ab dem
sich das ganze implementieren lassen würde?
Danke,
Anguel
Der Microblaze-Core allein braucht je nach Konfig ca. 10-15% eines
3S1600E. Kleinperipherie (UART, TIMER, GPIO, evtl. auch ein Interface zu
SRAM/Flash) kostet noch ein paar % mehr. D.h. das SOC würde schon in
einen 3S500E bequem reingehen. Der 1600E hat aber nur 36*2KB=72K
Blockram, kommt mir da schon knapp vor. Wie das Codeverhältnis
Microchip/Microblaze wirklich ist, kann ich nicht beurteilen, mit war
der PIC immer zuwieder. Der MB hat trotz RSIC sicher mächtigere Befehle,
erst recht wenn es mehr als 8Bit-Rechnung ist, aber die sind halt auch
32Bit lang...
Georg A. schrieb:> Auch das hier könnte möglicherweise helfen:> http://www.uclinux.org/
Danke für die vielen Inspirationen. Das uLinux Projekt war mir nicht
geläufig. Das scheint aber genau das zu sein, was wir brauchen. Nach
einer ersten Übersicht ist da der MB als Schalter beim Kernel bauen ja
auch schon drin.
> Und wenn es die Bauchpinsel-Lösung sein soll:>> http://www.petalogix.com/
Naja, die EDK Integration der Linux Distribution muss nicht unbedingt
sein, auch wenn ich beim System-Bauen nicht darauf verzichten möchte (da
wir keine FPGA bzw. VHDL Cracks sind).
Also, Vielen Dank.
Danke für die ausführlichen Infos Georg! Es ist echt super, eine
konkrete Vorstellung von den Anforderungen zu haben. Andererseits ist es
doch ernüchternd, dass ein größerer PIC doch mehr Speicher als ein FPGA
bietet ;) Andererseits habe ich auch gesehen, dass man die Progs wohl
auch vom Flash ausführen kann, wenn man keine hohen Geschwindigkeiten
braucht:
http://www.xilinx.com/support/answers/23748.htm
Ob das in der Praxis was taugt, und ob das mit dem internen Flash eines
3AN läuft, müsste man wohl austesten.
Georg A. schrieb:> Der Microblaze-Core allein braucht je nach Konfig ca. 10-15% eines> 3S1600E. Kleinperipherie (UART, TIMER, GPIO, evtl. auch ein Interface zu> SRAM/Flash) kostet noch ein paar % mehr. D.h. das SOC würde schon in> einen 3S500E bequem reingehen. Der 1600E hat aber nur 36*2KB=72K> Blockram, kommt mir da schon knapp vor. Wie das Codeverhältnis> Microchip/Microblaze wirklich ist, kann ich nicht beurteilen, mit war> der PIC immer zuwieder. Der MB hat trotz RSIC sicher mächtigere Befehle,> erst recht wenn es mehr als 8Bit-Rechnung ist, aber die sind halt auch> 32Bit lang...
Anguel S. schrieb:> Andererseits ist es> doch ernüchternd, dass ein größerer PIC doch mehr Speicher als ein FPGA> bietet ;)
Naja, 64kByte RAM auf einem PIC ist schon doch was anderes als 64kByte
DualPort BlockRam im FPGA, der mit 300+ MHZ laufen kann. Der BlockRAM
ist leider das teuerste an den FPGAs. Daher sollte man möglichst
externen SDRAM anschließen.
Beim PIC ist es nicht mal RAM, sondern Programm-Flash :) Schade
eigentlich, ich wollte das alte PIC Design um einige schnelle
Peripherals in VHDL ergänzen und dachte, dass da eine Single-Chip Lösung
mit FPGA und MicroBlaze möglich wäre. So wie es aussieht, braucht man da
aber wohl doch externen RAM :( Ist es eigentlich beim Spartan-3AN
einfach und üblich, aus dem internen Flash z.B. Strings während des
Programmablaufs in den RAM einzulesen, oder ist der Flash nur dazu
gedacht, den Programmcode beim Start des FPGAs einmal reinzuladen?
Christian R. schrieb:> Naja, 64kByte RAM auf einem PIC ist schon doch was anderes als 64kByte> DualPort BlockRam im FPGA, der mit 300+ MHZ laufen kann. Der BlockRAM> ist leider das teuerste an den FPGAs. Daher sollte man möglichst> externen SDRAM anschließen.
> Ist es eigentlich beim Spartan-3AN einfach und üblich, aus dem> internen Flash z.B. Strings während des Programmablaufs in den RAM> einzulesen, oder ist der Flash nur dazu gedacht, den Programmcode> beim Start des FPGAs einmal reinzuladen?
Du bist definitiv PIC-verseucht... Wenn im FPGA ein Microblaze läuft,
ist es dem piepegal, woher er seine Befehle oder seine Daten bekommt,
solange sie über den Speicherbus kommen. Es gibt keine unterschiedlichen
MOVEs für Flash vs. RAM... Wo da in dem Adressbereich welcher Speicher
sitzt, ist dir überlassen. Oft wird aber ein kleiner Teil des Blockrams
als Bootloader ab Adresse 0 benutzt (heisst dann LMB und erlaubt
maximale Geschwindigkeit).
Es ist auch möglich, das externe Flash für Bitstream und CPU-Daten
gleichzeitig zu nutzen. Man kann der Konfiguration sagen, dass sie von
"oben" her das Flash auslesen soll, während die CPU danach normal von
unten her bootet.
Georg A. schrieb:> Es ist auch möglich, das externe Flash für Bitstream und CPU-Daten> gleichzeitig zu nutzen. Man kann der Konfiguration sagen, dass sie von> "oben" her das Flash auslesen soll, während die CPU danach normal von> unten her bootet.
Hm, da muß ich als Laie doch nochmal reinhaken (aus Unverständnis ;-)).
Muss denn der "Bitstream", also die FPGA Konfiguration nicht eh auf
einem Nicht-Flüchtigem Speicher, sprich Flash, liegen? Gleich im
Anschluß die Frage: Macht der CoolRunner auf dem Spartan 3E Starter Kit
das Management des selbigen? Das OS kann man dann doch auch auf den
Flash legen, bzw. einen Loader, der es zB. von einer CF Karte liest. Der
DDR RAM kann doch dann dem MB für Heap bzw. Stack zur Verfügung gestellt
werden. Immerhin kann er 32 Bit Adressieren, oder?
PS: Mich bitte nicht gleich zerreißen, wenn irgendwas inhaltlich falsch.
