Wir haben kleine DIP40 Format PCB mit Lattice Certus-NX 40 und 32Mbyte HyperRAM, und es hat gerade Linux gebootet. LiteX ist manchmal echt cool. HyperRAM ist auch cool when man IP Core dafür hat.
Beitrag #8063450 wurde von einem Moderator gelöscht.
Antti L. schrieb: > Wir haben kleine DIP40 Format PCB mit Lattice Certus-NX 40 und 32Mbyte > HyperRAM, und es hat gerade Linux gebootet. LiteX ist manchmal echt > cool. HyperRAM ist auch cool when man IP Core dafür hat. Wenn du wenigstens Details nennen würdest wie du was gemacht hast, damit andere das nachmachen können aber das interessiert nun wirklich keinen.
Angehängte Dateien:
-
enjoy-digital.jpg
56 KB
> Wenn du wenigstens Details nennen würdest wie du was gemacht hast, damit > andere das nachmachen können aber das interessiert nun wirklich keinen. Ja mein fehler zu wenig infos, OK here: - DIP 40 format (PCB size 18x55mm) - 34 IO davon 8 als LVDS benutzbar - Lattice Certus-NX 40 - 32MByte SPI Flash - 32Mbyte HyperRAM - 2 RPi MIPI stecker mit 22 pins - FTDI FT2232 für JTAG und UART console/FIFO - PCB 8 lagen ohne HDi - schematic wird veröffentlicht bald Ich habe sch+PCB gemacht, und ein kleines test mit Propel+Radiant wobei ich meine eigene open source HyperRAM IP getestet habe. Dann habe ich eine PCB zu enjoy-digital nach Frankreich gesendet, und vor ein paar stunden kam das bild was ich angehängt habe zurück, Linux bootete mit LiteX, dh LiteX HyperRAM und LiteX SD Card IP cores laufen auch OK. Ich habe danach selber ausprobiert, und es bootet Linux auf meinen Tisch auch. Die Lösung FPGA+HyperRAM ist platzmässig sehr klein und nimmt auch wenig strom. Und es kann schon Linux! Der FPGA ist 66% voll mit dem Basis SoC.
Hast du vielleicht mal eine Quelle zu dem LiteX. Ich interessiere mich auch dafür.
Und noch eine Frage: Geht das mit einem Mainline Kernel oder braucht man absurde Anpassungen, die dann nach einem Jahr sowieso niemand mehr wartet?
Martin schrieb: > Hast du vielleicht mal eine Quelle zu dem LiteX. Ich interessiere mich > auch dafür. https://github.com/enjoy-digital/litex https://github.com/litex-hub/linux-on-litex-vexriscv
Martin schrieb: > Und noch eine Frage: Geht das mit einem Mainline Kernel oder braucht man > absurde Anpassungen, die dann nach einem Jahr sowieso niemand mehr > wartet? https://github.com/litex-hub/linux-on-litex-vexriscv das Linux-on-LiteX projekt hat 64 mitwirkende und ich glaube es ist relative mainstream Linux mit buildroot Bei mir wird angezeigt: Linux version 6.9.0
Nemopuk schrieb: > Wofür ist das gut? Deine Frage ist allgemein, was willst du wissen? Wofür ist FPGA gut? Wofür ist embedded Linux gut? Wofür ist diese Platine gut? Wofür ist FPGA+HyperRAM gut? FPGA+HyperRAM ist gut weil: - billig - klein PCB fläche etwa 13*30 mm - PCB Routing ist einfach - wenig Stromverbrauch - Linux fähig Unsere Platine ist gut weil es ein Demo Platform ist für kleine Linux fähige Lösung.
Ein Linux, was "bare metal" also ohne Emulation Windows - Exen ausführen könnte, wäre der Tod von Microsoft. ;-O mfg
Antti L. schrieb: >> Wofür ist das gut? > Deine Frage ist allgemein, was willst du wissen? Wofür ist Linux auf diesem Board gut?
Lotta . schrieb: > Ein Linux, was "bare metal" also ohne Emulation Windows - Exen > ausführen könnte, wäre der Tod von Microsoft. Tut mir Leid, dich enttäuschen zu müssen, aber das kann der Linux Kern schon lange. Nur wollen die meisten für Windows erstellten Programme auch auf Funktionen von Windows Bibliotheken zugreifen (ohne dll läuft bei Windows nicht viel). Diese muss mann dann doch irgendwie nachbauen. Das ist aber nicht die Aufgabe des Kernels, sondern an dem Punkt macht Wine weiter.
:
Bearbeitet durch User
Yet another linux booting... Man vergebe mir die vernichtende Kritik, aber damit holt ihr heutzutage wirklich niemand hinterm Ofen mehr vor. Kommt 15 Jahre zu spät, der Markt ist gut gesättigt, und der Teufel steckt so im Detail, dass ich LiteX für nachhaltige Entwicklung eher nicht bewerben würde.
Antti L. schrieb: > billig Hast Du dazu eine ungefähre Zahl? Wenn man in seiner Anwendung einen FPGA braucht, ist das natürlich in jedem Fall interessant, ansonsten ist die Alternative irgendein ARM-SoC. Antti L. schrieb: > wenig Stromverbrauch Auch da wären Zahlen interessant. Und natürlich Performance-Benchmarks.
> Yet another linux booting... ... > wirklich niemand hinterm Ofen mehr vor. Kommt 15 Jahre zu spät, der > Markt ist gut gesättigt, und der Teufel steckt so im Detail, Sehe ich etwas anders, die Zahl der im industriellen Einsatz von FPGA's benutzen Linuxe ist recht überschaubar und immer recht speziell auf die jeweilige Chip-Familie und tool-chain. Da kommt ne weitere Option weg von Xilinx Zynq mit PetaLinux gerade recht. Unix auf Lattice hatte ich persönlich noch nicht evaluiert, könnte für einige Nischen interessant sein. Lattice hat ja den Ruf einige preiswerte FPGA-Familien mit praktischen Hard-IP-Cores am Start zu haben und eben "kein Chinese" zu sein. Wenn allerdings die genannten 32 MB komplett fürs Linux benutzt werden, wäre das ein ziemlich dicker "footprint", Linux sollte ja schon 4 MB akzeptabel laufen. Das Linux ist bei FPGA/SoC eh oft nur ne Dreingabe zur Erleichterung der Systementwicklung (siehe Red Pitaya). Spannend sind da oft Bootzeiten, FPGA, CPLD setzt man auch dorthin wo nach PowerUp nicht viel (BootUp-)Zeit ist. https://www.latticesemi.com/en/Products/FPGAandCPLD/Certus-NX Und wenn das Ganze klein bleibt, weil man keinen Kühlkörper braucht dann tun sich etliche Anwendungen auf für die die üblichen Verdächtigen zu gross sind. Es soll je Medizintechnik, wie beispielsweise Ultraschalldiagnostic geben, die man schlucken kann ... um mal ein Beispiel zu nennen: https://www.houstonmethodist.org/blog/articles/2025/sep/capsule-endoscopy-how-the-pill-camera-works-why-you-might-need-it/
:
Bearbeitet durch User
Ich verstehe noch nicht, warum ich einen Linux Rechner verschlucken sollte. Was kann der großartig besser, als andere Sensoren ohne Linux?
> Ich verstehe noch nicht, warum ich einen Linux Rechner verschlucken > sollte. Was kann der großartig besser, als andere Sensoren ohne Linux? Frag mal deine Kaffeemaschine, Waschmaschine, dein Auto, die smarten Öhrstöpseln oder irgendein anderes Alltagsgerät auf dem irgendein Projectmanager entschieden, da Linux drauf lauf zu lassen (weil man ja heute ein Betriebssystem (für die [wireless] Verbindung) braucht und nicht selbst das Rad nochmal erfinden möchte).
:
Bearbeitet durch User
Bradward B. schrieb: > weil man ja heute ein Betriebssystem (für die [wireless] Verbindung) > braucht Aber das Board dieses Threads hat doch gar keine Verbindungen dieser Art. Ich meine das Foto in Beitrag "Re: Linux läuft von HyperRAM" Mit Ethernet, Wlan, Bluetooth macht Linux für mich Sinn. Allerdings kommen mir dann 32 MB RAM arg knapp vor. Für viel mehr als den Kernel wird es wohl nicht reichen. Also kein Java, Python, Go, Webserver, ...
:
Bearbeitet durch User
Nemopuk schrieb: > Also kein Java, Python, Go, Webserver, ... Entwickeln will man auf der Maschine wohl nicht, aber gegen z.B. Python in Form von Micropython oder die üblichen Webserver spricht da nun nichts. Siehe die kleinen MIPS-Dinger, die in vielen Routern sind, und von denen einige auch nicht mehr haben. Ich verstehe von FPGA nun nicht soviel, aber als Projekt finde ich es gut. Soll ja kein Produkt werden, soweit ich das sehen kann, sodass viele Einwände hier für mich nicht ganz so nachvollziehbar sind.
Jack V. schrieb: > Entwickeln will man auf der Maschine wohl nicht Davon war auch keine Rede. 32 MB reichen nicht mal für die Laufzeit-Bibliotheken. Ein Go Programm könnte so gerade gehen, aber nur ein ganz kleines. > aber gegen ... die üblichen Webserver spricht da nun nichts. Es fällt mir schwer, mir einen Nginx oder Apache samt PHP, Weblogic oder JBoss auf 32 MB RAM vorzustellen. Nicht mal der "kleine" Jetty wird darauf laufen. Offenbar haben wir unterschiedliche Vorstellungen von "üblichen“ Webservern unter Linux. > aber gegen z.B. Python in Form von Micropython Micropython ist für Mikrocontroller ohne Linux. Gibt es überhaupt einen Fork für diesen FPGA?
:
Bearbeitet durch User
Nemopuk schrieb: > Es fällt mir schwer, mir einen Nginx oder Apache samt PHP […] Dann setz’ es halt mal selbst auf, und staune. Die Art Software leidet noch nicht an dem Bloat, der mit späteren Framework-Orgien in die Entwicklung Einzug gehalten hat. Freilich wird’s nicht zum Betrieb einer regulären Webseite geeignet sein, aber um zu zeigen, dass es geht, und für kleinere Anwendungen, wie Webinterfaces? Dafür sind 32MB fast schon üppig. Alternativ frage dich, wie wohl das Webinterface erwähnter Router ausgeliefert wird. Nemopuk schrieb: > Micropython ist für Mikrocontroller ohne Linux. Nicht unbedingt: „MicroPython runs on a wide range of microcontrollers, as well as on Unix-like (including Linux, BSD, macOS, WSL) and Windows systems.“ Ich verstehe, dass du das Projekt aus irgendeinem Grund nicht zu mögen scheinst. Aber das ist kein Grund, sich was zusammenzudichten, um es schlecht aussehen zu lassen.
:
Bearbeitet durch User
Jack V. schrieb: > Ich verstehe, dass du das Projekt aus irgendeinem Grund nicht zu mögen > scheinst. Das ist nicht der Punkt. Der Punkt war, welchen Benefit Linux auf einem Rechner ohne Netzwerk bringt. Wir sind allerdings abgedriftet.
Nemopuk schrieb: > Der Punkt war, welchen Benefit Linux auf einem Rechner ohne Netzwerk > bringt. Der Punkt für mich ist an dieser Stelle, wozu das hier wichtig ist. Ich meine: Wenn ich meine Projekte so anschaue, bringt kaum eines einen „Benefit“ für jemanden, außer mir. Wenn nicht Gründe dem entgegenstehen würden, würde ich die hier auch zeigen, weil ich weiß, dass einige andere User hier die genauso cool finden würden, wie ich – ohne, dass sie objektiv irgendeinen Nutzen für die meisten Leute hätten. So what?
:
Bearbeitet durch User
Nemopuk schrieb: > Mit Ethernet, Wlan, Bluetooth macht Linux für mich Sinn. Allerdings > kommen mir dann 32 MB RAM arg knapp vor. Für viel mehr als den Kernel > wird es wohl nicht reichen. Also kein Java, Python, Go, Webserver, ... Viele FPGA-Projekte kommunizieren per SPI mit ihrer Aussenwelt. Einige SPIs wird auch dieses Zwergerl recht leicht zustandebringen. Die brauchen so generische Dinge wie Ethernet, WLAN, BT folglich nicht. Und Java, Python, Go, Webserver natürlich auch nicht. Den Wert eines UNIX als Betriebssystem schmälert das übrigens nicht.
> Mit Ethernet, Wlan, Bluetooth macht Linux für mich Sinn. Allerdings > kommen mir dann 32 MB RAM arg knapp vor. Für viel mehr als den Kernel > wird es wohl nicht reichen. Also kein Java, Python, Go, Webserver, ... Also als Linux in den Neunzigern startete, lief es ohne X auf Maschinen mit 4 MB, mit XFree86 waren 8 MB das Minimum. Auch ein Webserver braucht nicht sonderlich viel RAM, bspw. der CERN-httpd läuft auf einer Maschine (Next Cube) mit 8 bis 32 MB. Die kleinste Linuxdistri war IMHO Knoppix, das kam auf zwei 1,44 Disketten daher. Kein Vergleich zu den heutigen Gigabyte-Fressern. Als Beispiel für ein "kleines Linux" ausserhalb des FPGA bereiches, sei auf diese Businesscard mit Linux verwiesen, Anbindung wohl über USB: https://www.golem.de/news/allwinner-soc-diese-visitenkarte-ist-ein-linux-mini-pc-1912-145734.html Schon für die Einbindung eine filesystems macht ein betriebssystem Sinn, das will man nicht selbst programmieren, dazu ne kleine shell auf einem taskswitchenden Kernel -> fertig. Und für manche recht das Ganze zur bootzeit, also nimmt man "Das U-boot". Manche wollenen noch verschiedene Nutzer mit Rechteverwaltung und (RAM-) Speicherzugriffsschutz, auch das kann ein kleines Linux. Aber ja micro-python ist IMHO eine ernsthafte Alternative um einer Software-Community den Zugriff auf embedded Hardware zu ermöglichen. Das wäre das, was man heute als "small footprint" solutions bezeichnet. auch da gibt es Arbeiten in Richtung Lattice, ein Einstiegspunkt für eine Recherche darüber ist IMHO: * https://fupy.github.io/ Ein Stichwort für Python auf Xilinx FPGA/Zynq wäre PYNQ: * https://www.digikey.de/de/articles/build-and-program-fpga-based-designs-quickly-python-jupyter-notebooks?srsltid=AfmBOor0btgg65Z1OU4xdrs_tqvgPOJNrPDZ_7tORBhDAYFXzpr9V8bQ * http://www.pynq.io/ Problem der "community" mit solchen FPGA-komplexe Softeware-Projekte ist IMHO eher die Lernkurve und der Zeitaufwand, das ist nicht so niedrig wie bei solchen Schul-Lehr-Projekten wie RaspberryPico.
Bradward B. schrieb: > Frag mal deine Kaffeemaschine, Waschmaschine, dein Auto, die smarten > Öhrstöpseln oder irgendein anderes Alltagsgerät Viele von solchen Geräten haben aber kein Linux, sondern ein RTOS. Beispielsweise die Infotainment-Systeme von Autos nutzen oft QNX. Android Auto ist natürlich Linux. Earbuds sind zu ressourcen-beschränkt, für BLE braucht's auch kein Linux. Manche smarte Waschmaschinen nutzen ESP32 und dementsprechend FreeRTOS. Waschmaschinen und Kaffemaschinen sind extrem kostenoptimiert, da tun ein paar MB RAM schon weh. Interessantes Beispiel: Der Thermomix läuft unter Linux 😉 iA.: Grafikdisplay und/oder Internet-Anbindung: Wahrscheinlich Linux. Sonst eher RTOS.
> Viele von solchen Geräten haben aber kein Linux, sondern ein RTOS. Hm könnte man nicht sagen, das Linux ein kleiner OS-Kernel mit Sonderlocken für jede (im Bürobereich gebräuchliche)Hardware ist ?!. Reduziert man diesen Sonderlockerei auf das im Embedded nötige und garantiert die Echtzeit die für das jeweilige Gerät gerade nötig ist hat man ein Linux (aka essentiell nötiges OS). Da braucht man nicht viel, das meldet sich per UART an der debugschnittstelle und über eine Terminalemulation kann über die shell ein bißchen konfigurieren. oder als ausbauvariante per http Webseiten ausliefern lassen (für diejenigen, die mit derschnöden commandline schon überfordert sind). > Beispielsweise die Infotainment-Systeme von Autos nutzen oft QNX. Hintergrundinfo: ein großer deutscher Hersteller von Car-Infotainment war Becker Autoradio in Pforzheim, der seine Geräte auch als OEM zu BMW, Audi, Daimler und Porsche lieferte, die diese ab Werk einbauten. Dort arbeite man zuerst mit VxWorks und wechselte ca. 2002 zu QNX da dies besser im Speicherschutz galt. Mitte der Nuller kam durch Firmenaufkäufe sogar der QNX-Hersteller in die selben Hände wie der Hardwarehersteller, das hiess dann HarmanBecker International (o.ä.). So um 2010 hat man bei Harman mit Embedded Linux experiementiert, beispielsweise die bootzeit auf unter eine Sekunde gedrückt indem man bei dem Selbsttests etc. aufräumte. Volkswagen hat wohl mit Cariad versucht, was eigenes aus dem Boden zu stampfen, man erinnert sich an das Getöse: Beitrag "Cariad SE Erfahrungen" > Interessantes Beispiel: Der Thermomix läuft unter Linux Wohl auch die vielen China-scopes etc.. Linux ist mir auch schon bei Rohde&Schwarz (Funk-Geräten) begegnet. Linux soll ja oft essentieller Bestandteil des BSP sein, mit dem dann das Gerät "fertig" entwickelt wird. Aber manche nehmen allein wegen der geklärten Rechtslage lieber ein RTOS.
:
Bearbeitet durch User
Bradward B. schrieb: > Reduziert man diesen Sonderlockerei auf das im Embedded nötige Dann ist es immer noch ein Linux Kernel mit seinen Vor- und Nachteilen.
Obwohl die Diskussion abdriftet, etwas Senf: - In 32 MB geht schon was rein, aber dann geht's in die Details der Code-Dichte. Die ist beim klassischen RISC-V (ohne 'c') suboptimal. - Speicherverwaltung: Hier offenbart sich meist Fehler Nr. 1 in der Firmware-Entwicklung, Memory-Fragmentierung sorgt in Embedded für keine stabilen 24/7 Produkte. Sprich, man ist wieder bei no-mmu (ex. uClinux) und strikten Memory-Modellen. Nicht ohne Grund werden für die "stable legacy" immer noch modifizierte 2.6er Kernels verwendet, die kritische Bereiche trotz fehlender virtueller pages schützen können (Blackfin CPLB). Das wären die interessanten Details gewesen, neben klassischer Angaben wie f_max, BogoMIPS, usw. Dann typische Entwickler-Fragen: - Debugging: Kernel-Debugging, oder debugbare Simulationsmodelle vorliegend? (wie Renode-Cosimulation) - Board-Supply-Package: Support vom Hersteller? Sprich, Linux auf dem FPGA macht für mich kaum Sinn mehr, spätestens bei dem BSP-Gefrickel aus der ZynQ-Schiene hat sich das nicht gerechnet. Als proof of concept und clickbait geht natürlich alles. Aber vielleicht ist da ein Doom-Port mit Hardware-Bresenham der bessere Aufhänger für FPGA-Influtrenzer.
Nemopuk schrieb: > Nur wollen die meisten für Windows erstellten Programme auch auf > Funktionen von Windows Bibliotheken zugreifen (ohne dll läuft bei > Windows nicht viel). Richtig. Schon viele grundlegende Komponenten des Kernels sind in eine DLL ausgelagert und fast das gesamte Kernel-Interface zu Anwendungen in weitere. Das ist halt ein echter Micro-Kernel. So wie Hurd. Nur Jahrzehnte früher fertig gewesen ;o)
Antti L. schrieb: > Die Lösung FPGA+HyperRAM ist platzmässig sehr klein und nimmt auch wenig > strom. Und es kann schon Linux! Der FPGA ist 66% voll mit dem Basis SoC. 66% von einem FPGA zu verballern und dann einen Softcore zu haben ... na gut kann man machen. Das Linux darauf bootet - gar keine Frage, warum sollte das auch nicht gehen, ist dem dem Linux egal auf was für einer Architektur es laufen soll. Gut schon mal, das es ein 32 Bit Core ist, bei nur 32MB kann der dann zumindest halbwegs effizient genutzt werden. Bei 64 Bit wird da viel verplempert, gerade wenn viele Pointer im Spiel sind. Aber: Schon mal die Performance gemessen? Rein rechnerisch kommt Hyperram bei 8 Bit und 200MHz ja höchstens auf 400 MB/s brutto. Also etwa genauso viel wie ein 32Bit 100 MHz SDRAM, Technik von vor 30 Jahren. Nur dummerweise erzeugen Read/Write Umschaltung und Random Access bei Hyperram viel mehr Overhead als beim klassischen SDRAM, da ich dort zumindest innerhalb einer Row direkt rumspringen kann. Und selbst beim SDRAM kostet das, weshalb man die Daten in Burst in Caches liest. Ich weis das momentan überall das Thema Hyperram immer mehr aufpoppt, weil die Hardware viel einfacher beherrschbar ist als DDR RAM. Ob das aber wirklich für allgemeine Anwendungen taugt - fällt mir schwer das vorzustellen. Selbst die Hersteller der Hyperrams schreiben ja, das der Anwendungsfall eher so Streaming Sachen sind, also große Datenblöcke am Stück gelesen oder geschrieben werden sollen.
> 66% von einem FPGA zu verballern und dann einen Softcore zu haben ... na > gut kann man machen. Das Linux darauf bootet - gar keine Frage, warum > sollte das auch nicht gehen, ist dem dem Linux egal auf was für einer > Architektur es laufen soll. Gut schon mal, das es ein 32 Bit Core ist, > bei nur 32MB kann der dann zumindest halbwegs effizient genutzt werden. > Bei 64 Bit wird da viel verplempert, gerade wenn viele Pointer im Spiel > sind. Man kann davon ausgehen, das das ein unspezifisches reference design ist, mit dem der Hersteller des Evalboards modulweise zeigen resp. testen will, das das (Eval-Board) an sich funktionsfähig ist. Der Certus-NX ist auch kein besonders großer FPGA, er zählt heuzutage eher zu den Kleinen mit 39k Logikzellen (? 1xLC = 2x4erLUT + 2xFF ?). Als Anwendung wird bspw. Motorsteuerung genannt. Für das finale Design wird man sich wohl eher mit einem simplen Kommando--Interpreter nach dem UART begnügen, der im wesentlichen paar selbsttest durchkloppt und config-register beschreibt. Im Zusammenhang mit Diskussion wie "fett" Linux tätsächlich ist, finde ich es recht bezeichnend, das bspw. Xilinx schon von der Benutzung des printf() aus den standard libraries abrät und ein (völlig ausreichendes) abgespeckter xil_printf() (ca 1k groß) mitliefert.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.