Hallo Leute, nachdem ich schon länger danach suche, versuche ich auch mal hier mein Glück: Für eine neue Produktgeneration müssen wir uns demnächst für einen neuen Prozessor entscheiden. Dabei scheint der Cyclone V (mit HPS) von Altera interessant zu sein. Allerdings ergibt sich da ein Problem: Es soll auf dem internen Prozessor Linux laufen. Es gibt wohl im Mainline-Kernel Treiber dafür, jedoch frage ich mich, wie das läuft, wenn ich eine Schnittstelle im FPGA-Teil des SoC implementieren will. Dann müsste man doch einen Linux-Treiber für diese Schnittstelle schreiben, oder? Es gibt ja bereits fertige IP-Cores für dieses FPGA, aber nirgends finde ich eine Angabe, ob für diese auch Linux-Treiber angeboten werden. Würde nur gerne wissen, ob mein Gedankengang stimmt (Ich habe keine allzugroße Erfahrung und versuch mich erstmal in die grundlegende Funktionsweise des FPGAs einzulesen). Danke im Voraus, Gruß, Freddy
Tach, das mit Linux auf FPGA würde ich mir sehr gut überlegen, denn das ist eher ein akademischer Spass (oder proof of concept) als wirklich brauchbar, der Aufwand steht auch in keinem Verhältnis. Du musst in der Tat Treiber dafür schreiben und sicherstellen, dass auch der entsprechende Bus-Support von Altera bereitgestellt wird, sonst artet das ziemlich aus. Wenn ihr also nicht gerade 10'000 davon im Jahr raushaut, würde ich mir gut überlegen, ob sich ein zusätzlicher kleiner ARM oder Blackfin (µcLinux-Geheimtip!) nicht gegenüber den Entwicklungskosten rechnet.
Er redet über Cyclone V SoC -- da ist ein Dual-Core ARM mit 800 MHz drin. Habe selber ein DevKit auf dem Tisch -- Linux zum Laufen zu bringen und mit dem FPGA zu kommunizieren ist ganz easy :-) Treiber für Ethernet/USB und anderen Kram ist von Hause aus da. Wenn man selber was implementieren möchte, dann müssen natürlich die Treiber selber geschrieben werden. Kest
Bei kommerziellen IP-Cores: einfach bei der 3rd party anfragen, was die geplant haben. Bei eigenen IP-Cores: selbst den Treiber schreiben oder dafür eine Firma mit ins Boot holen, die sich damit auskennt. Ich kenne da (mindestens) eine Firma, die einen da unterstützen kann. Also einfach bei Interesse / Bedarf mal anfragen. @Fitzebutze: Dafür dass Du scheinbar keine Ahnung hast, um was es beim Altera SoC geht, hast Du sehr viel von Deiner Unwissenheit hier zur Schau gestellt...
Erstmal danke an alle =) @Fritzbude: Es geht allerdings um ca. 10k insgesamt =) @Kest: Vom Developer Board hab ich schon gelesen, bin mir aber aufgrund von fehlendem Wissen unsicher, ob man die Treiber einfach nehmen kann. Würde doch nur mit der entsprechenden Hardware außenrum funktionieren... Wobei... Ethernet-Phy müsste ja fast immer gleich sein, von der Ansteuerung her, USB geht direkt drauf... Ich brauch allerdings ne Displayansteuerung über LVDS mit verschiedenen Displayauflösungen. Dafür müsste ich noch was finden. @Michael: Hm. Glaub das werd ich gleich mal machen. Fragen kost ja nix ^^
Manche DevKits haben Erweiterungsstecker, an die könntest Du Deinen Display anschließen. Um vom Linux aus da was auszugeben bräuchtest Du eine FPGA-Komponente, die LVDS/Display-Signale generieren kann und natürlich einen FrameBuffer, den Du vom Linux aus mit Daten beschreiben kannst. Wie schwer es ist, die Treiber anzupassen kann ich nicht abschätzen. Bin selber dabei soetwas zum Laufen zu bekommen. Kest
Bei uns geht es nicht darum, die Developerkits zu verwenden, sondern den Chip auf ein eigenes Board zu platzieren, falls das nicht klar geworden sein sollte. Das ändert auch die umliegende Peripherie, weswegen ich mir Sorgen mache, dass große Änderungen an den Treibern bzw. eigenes Treiberschreiben nötig wäre. Das wäre ein Ausschlusskriterium für den SoC, weil der Aufwand dann erheblich höher ist, als bei "normalen" ARM-Prozessoren (bei denen die nötigen Schnittstellen alle direkts vorhanden sind).
Bezüglich Kontakt zum Treiber-Entwickler: Ich bin mir nicht sicher, ob der Firmeninhaber möchte, dass er hier genannt wird => PN an mich Was LVDS angeht, so haben das SoC-Board von Altera und Arrow einen HSMC, an dem man ein Display anschließen kann. Ich hab schon eine Android-Demo live und in Farbe am SoCkit von Arrow gesehen und das könnte das Display gewesen sein: http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=68&No=653 Wenn das SoC auf ein eigenes Board kommen soll, dann kann man die eigene Hardware ja an den Eval-Boards anlehnen. Die Schaltpläne der SoC-Boards sind auf www.rocketboards.org verfügbar und so viele Möglichkeiten des Pin-Multiplexings hat man beim HPS nicht. Und solange man z.B. für Ethernet keinen ausgefallenen PHY nimmt, sondern sich an dem orientiert, was Altera oder Arrow auf den Boards haben, gibt es auch keinen Stress mit dem Treiber (denn Ethernet läuft ja auf beiden Eval-Boards unter Linux) Nun noch 2 Fragen zum letzten Post von Freddy: - welche benötigten Schnittstellen hat ein "normaler" ARM, die beim SoC fehlen? - warum ist die Treiberentwicklung bei einem "normalen" ARM einfacher, als beim SoC? (Cortex-A ist Cortex-A und Linux ist Linux)
Fehlende Schnittstellen: - SPI/I2C/USB/UART jeweils zwar vorhanden, aber leider zu wenige - PCIe - MIPI CSI - LVDS - SDHC leider auch nur einmal Warum die Treiberentwicklung schwieriger sein sollte? Die festen HPS-Schnittstellen werden genauso sein, wie bei anderen Prozessoren auch, jedoch stelle ich mir die variablen, über IP-Cores realisierten Schnittstellen schwerer vor in Linux zu implementierten (bzw. eben Treiber zu finden, an denen man nicht mehr viel ändern muss).
> SPI/I2C/USB/UART jeweils zwar vorhanden, aber leider zu wenige und > SDHC leider auch nur einmal Das ist ja gerade das tolle an einem FPGA, davon kann man sich soviele machen wie man will bzw. wie Platz oder Pins da sind. - LVDS Hat jedes FPGA wohl mehr als nen normaler ARM - PCIe gehen auch soviele wie Platz da ist (natürlich braucht man nen IP Core) und ist natürlich vom FPGA abhängig. Die neuen haben sowas aber in Hardware Implementiert. Du hast aber in einem Punkt recht, das muß erst mal alles zusammengeschustert werden, synthetisiert werden, getestet werden und dann auch noch konfiguriert werden. Aber in Sachen Treiber nimmt sich das wohl nichts. Bei nen normalem ARM ist halt die Harware schon fertig, und wenn du noch was zusätzlich brauchst haste halt Pech gehabt. Bei nem FPGA machste dir das dann halt noch dazu.
Uwe schrieb: > Bei nen normalem ARM ist halt die Harware schon fertig, und wenn du noch > was zusätzlich brauchst haste halt Pech gehabt. Ne dann baut man sich nen kleines FPGA an den externen Bus dran oder nimmt fertige Controller mit USB / SPI ;-) > Aber in Sachen Treiber nimmt sich das wohl nichts. Eh doch, die vom normalen ARM SoC sind fertig und vom Hersteller getestet, also anschalten+loslegen ;-) Und auch gerade so Dinge wie Displays ansteuern, da sind die in den ARMs eingebauten Controller schon sehr leistungsfähig, das muss man im FPGA erstmal gescheit hinbekommen.
Ja, LVDS mag ein FPGA-SoC mehr haben, aber das ist auch nicht mein Problem. Mein Problem in dem Fall ist, dass es durch die Konfigurierbarkeit des FPGAs eben keine Festen Schnittstellen (im FPGA-Teil!) gibt, und somit wahrscheinlich auch keine fertigen Treiber (oder Treiber die man sehr schnell anpassen kann, ohne sau tief einzusteigen). Und gerade bei Grafik und PCIe ist ein Treiber selbst schreiben relativ aufwändig. Klar, bei einem reinen ARM-Prozessor muss man auch Treiber haben, aber die gibt's eben schon komplett fertig vom Hersteller, weil er die einmal machen muss und fertig. Da weiß der Hersteller ja aber auch schon, was beim Entwickler später für Schnittstellen im Prozessor sind (weil eben fest). Ich glaube mittlerweile, den Aufwand kann keiner so direkt einschätzen. Hab echt schon ewig gelesen, aber es ist sehr anwendungsabhängig. Sicher bin ich mir, dass die reinen Prozessoren "einfach" sind, da eben der Hersteller bereits Treiber anbietet. Beim FPGA-SoC mag es auch "einfach" sein, kann jedoch auch ziehmlich aufwendig werden, wenn man den Treiber eben doch komplett selbst schreiben muss, weil kein passender vorhanden ist. Und so wie ich das bisher überblicke, sind nur für wenige IP-Cores auch direkt Linux-Treiber vom jeweiligen Anbieter vorhanden. Ich denke damit hat sich das Thema dann auch. Danke für eure Meinungen, ich werd das nochmal mit den Chefs abklären, was die so sagen. Hat mir aber sehr geholfen hier die verschiedenen Einschätzungen zu bekommen =)
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.