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
Andreas M. schrieb: > Ob das aber wirklich für allgemeine Anwendungen taugt - fällt mir schwer > das vorzustellen. Etwas mit FPGA und Hyperram wird immer eine Spezialanwendung bleiben. Aber die gibt es eben auch. Ein großer Vorteil von Hyperram ist die Anzahl der IOs. Es kostet nur 12 IOs am FPGA, klassischer DRAM braucht grob 3 mal so viele. Und der Speichercontroller im FPGA kann auch sehr klein sein. Also schon halbwegs sinnvoll zwischen SDR SPI und DDR RAM.
Bradward B. schrieb: > 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. Und was hat eine c-lib Funktion mit dem Linux Kernel zu tun? print\* hat nun mal eine maximal ungünstige Definition, wenn es um ressourcen geht, da kann aber der Linux Kernel nix für und die Funktion ist unter Windows oder Mac und auch im Embedded Bereich nicht schlanker. Hat schon einen Grund warum es z.b. in der newlib iprint\* gibt.
:
Bearbeitet durch User
> Und was hat eine c-lib Funktion mit dem Linux Kernel zu tun? Die C-Programmierschnittstelle zählt halt zum Betriebssystem resp. zum Lieferumfang, siehe POSIX-Standard: https://de.wikipedia.org/wiki/POSIX#Spezifikation Das ist schon das Interessante an der Diskussion, ob oder was es an Linux auf einem FPGA braucht, insbesonders wenn man auf Embedded Systeme fokussiert. Embedded Systeme brauchen genau genommen keine Mensch-Maschine Interface (sie Headless Betrieb für RasbPi) oder andere als die vom PC gewöhnte. Trotzdem steckt da oft Ausgabe von "Menschen lesbare Meldungen" drin. Insbesonders bei der Entwicklung/Wartung wird eine solche Schnittstelle verlangt; verweist man das als Hardwareentwickler auf die Möglichkeiten des debuggings per ILA, blinkender LED, o.ä., steht man schnell im shitstorm, der von der "Applikations-Entwicklung" losgetreten wurde, weil die nun mal gern Tonnenschwere log-files haben wollen ... ;-) SCNR Und was ist der Linux-Kernel ? Insbesonders einer für embedded ? Bei einer Recherche danach stößt man auf etliche "Kernel aus der Linux-Community" wie: * Zephyr * HURD * RIOT * LynxOS * RTEMS * FreeRTOS ..
:
Bearbeitet durch User
Bradward B. schrieb: > Bei einer Recherche danach stößt man auf etliche "Kernel aus der > Linux-Community" wie: Ja genau. Nur haben die zum Großteil (hab mir nicht alle angeguckt) genau nichts mit Linux zu tun. Es sind eben kleine Betriebsysteme. Davon gibt es recht viele. Und Linux ist eben auch eines aber noch lange nicht jedes kleine Betriebsystem ist Linux.
Bradward B. schrieb: > Und was ist der Linux-Kernel Na der Linux Kernel halt. Der Unixoide Kernel von Linus Torvalds, ursprünglich für i386 geschrieben. "Linux" ist der "Produktname" dieses einen Kernels, nicht der Name des Teams dahinter. Das was hier drin ist: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git Zephyr, Hurd usw. gehören nicht dazu, das sind "Konkurrenzprodukte", selbst wenn es eine Schnittmenge der Entwicklerteams gibt.
Bradward B. schrieb: > Die C-Programmierschnittstelle zählt halt zum Betriebssystem resp. zum > Lieferumfang, siehe POSIX-Standard: > https://de.wikipedia.org/wiki/POSIX#Spezifikation Der Linux Kernel ist aber kein vollständiges Betriebssystem, sondern eben nur ein Kernel. Es gibt beim Linux-Kernel an der Schnittstelle zum Userspace gar kein "printf". "printf" kommt aus dem user-space aus "irgend" einer library. Und die kann der Entwickler der Applikation selbst aussuchen. Für Linux gibt es mindestens vier verschiedene Implementierungen die C/Posix bereitstellen.
Hmmm schrieb: > Antti L. schrieb: >> billig > > Hast Du dazu eine ungefähre Zahl? > 59 EUR vielleicht > 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. Ich habe nur eine Zahl, es nimmt 800mW von USB. Etwa 300 davon ist der FT2232H schon. Stromweise kann man auch mit weniger auskommen, wir haben 4 FS3303 draufgepackt, die haben keine light load mode und nehmen relative viel strom in idle.
> Also als Linux in den Neunzigern startete, lief es ohne X auf Maschinen > mit 4 MB, mit XFree86 waren 8 MB das Minimum. Als ich Ende 90/Anfang 91 auf Linux umgestiegen bin, da hatte ich einen 80386SX mit 4MB Ram. Darauf lief etwas spaeter auch X, allerdings hab ich dann schnell auf 6MB aufgeruestet. Damit lief dann Linux mit X11 aehnlich schnell und brauchbar wie ein Interactive Unix auf einem 486/33. Natuerlich nur 256 Farben... .-) Interessant fuer Embeddedbetrachtungen sind aber Sharp Zaurus. Die hatten anfang der 2000er einen Intel Xscale mit 400Mhz und 640x400pixel. Da lief eine eigene Grafikoberflaeche Qtopia drauf die wohl QT-Basiert war. Da lief durchaus schnell und brauchbar. Also z.B Opera als Internetbrowser, einfache Videos. Da will aber heute wohl keiner mehr wahr haben weil alles durch bergeweise aufgeblasene Softwarelayer lahm geworden ist. > Das ist schon das Interessante an der Diskussion, ob oder was es an > Linux auf einem FPGA braucht, insbesonders wenn man auf Embedded Systeme > fokussiert. Sobald du irgendwas mit Netzwerk machst. Aber in der Tat denke ich auch oft das heute die Systeme zu aufgeblasen sind. Das aendert sich aber gerade! Grosse Kunden fangen an ihren Zulieferern an Vorgaben bezueglich Energieverbrauch zu machen. Soll heissen die rechnen aus wieviele Energie deine Geraete in ihrer Lebensdauer verbrauchen und wollen da von dir das du 30-50% runter gehst wenn deine Geraete weiter auf der bevorzugten Beschaffungsliste bleiben sollen. Da wird so manche faule Entwicklungsabteilung aufwachen. .-) Vanye
Vanye R. schrieb: >> Das ist schon das Interessante an der Diskussion, ob oder was es an >> Linux auf einem FPGA braucht, insbesonders wenn man auf Embedded Systeme >> fokussiert. > > Sobald du irgendwas mit Netzwerk machst. Aber in der Tat denke ich auch > oft das heute die Systeme zu aufgeblasen sind. Das aendert sich aber > gerade! Wenn du damit Netzwerk-Client mit Browser-Frontend meinst, ok. Wenn zwingend dropbox multi-user als Server laufen muss: bedingt ok, POSIX kann man auch auf NuttX, Zephyr etc. haben. Wenn high performance, Echtzeit und robust (was zum Einsatz eines FPGA motiviert) ist man automatisch bei UDP und nutzt das besser auf bare metal. Einen gut mit DMA verzahnten UDP-Treiber oder gar Core hat man so deutlich schneller verifiziert als eine Linux-basierte Lösung, ganz abseits der Probleme des Linux-Stacks mit bösartiger Paketflut. Im Gegensatz zu 32 MB reichen dafür 32 kB on-chip BRAM (für das gesamte Fernsteuerungs-OS) und ich spare mir einen Chip und aufwendige RAM-Caches. Warum sollte ich also Linux hernehmen? (NB: ich bin alter Linux-Hase). Was den Energieverbrauch unter Netzwerk-Vollast angeht, wäre bei mir die Schmerzgrenze bei ~750 mW, im Idle eher bei 50mW. Aber stromsparend würde ich das nicht nennen :-)
Martin S. schrieb: > Was den Energieverbrauch unter Netzwerk-Vollast angeht, wäre bei mir die > Schmerzgrenze bei ~750 mW, im Idle eher bei 50mW. Aber stromsparend > würde ich das nicht nennen :-) Wie soll das funktionieren? Ein guter GBit Phy braucht selbst im EEE Modus bei Null Traffic gut 50mW.
Bradward B. schrieb: > steht man schnell im > shitstorm, der von der "Applikations-Entwicklung" losgetreten wurde, > weil die nun mal gern Tonnenschwere log-files haben wollen ... Dazu fällt mir ein, das coreboot leider auch sehr mainboardabhängig ist, oder warum Skyrim u.a. so übel ist, denn die Skriptwelten da mal zu optimieren, fiel den Entwicklern eher nicht ein. Man kann auch die KI über Ram-boots und zur FPGA-World usw. fragen, und ich bekomme da auch ziemlich gute Antworten. Problem: Ich kann mir leider nicht alles merken..:( (aber kopieren, ein interessanter part war): "Bandbreite vs. Leistung: Ein Flaschenhals kann die Bandbreite sein. Werden komplexe Linux-Tasks oder grafische Benutzeroberflächen gefordert, sind klassische SDRAM/DDR-Architekturen in der Regel performanter als HyperRAM. Dennoch ist das Setup ideal für kompakte Linux-Stacks (z.B. auf speziellen RISC Architekturen)"
:
Bearbeitet durch User
> Wenn high performance, Echtzeit und robust (was zum Einsatz eines FPGA > motiviert) ist man automatisch bei UDP und nutzt das besser auf bare > metal. Ich glaube nicht das du entscheidest ob du UDP willst oder nicht. Es ist eher so das der Kunde dir sagt welchen industriellen Feldbus er haben moechte. Und selbst wenn dann vielleicht ganz weit unten noch UDP ausgetauscht wird, in den Schichten darueber schlackern dir doch die Ohren weil das so abgehoben und komplex wird. Vanye
Antti L. schrieb: > 32Mbyte HyperRAM Wie hoch ist denn da die Speicherbandbreite? Und hat man da auch so 'ewige' Latenzen wie bei DDRx-RAM?
Rick D. schrieb: > Antti L. schrieb: >> 32Mbyte HyperRAM > Wie hoch ist denn da die Speicherbandbreite? > Und hat man da auch so 'ewige' Latenzen wie bei DDRx-RAM? Ja es gibt latenz leider, ist alles interne SDRAM. Der LiteX HyperRAM controller ist nicht das aller schnellste leider, dh der HyperRAM mit anderen IP könnte schon mehr. Bootzeit 52 sekunden Bootzeit VexRisc+DDR3 40 sekunden Dh der boot ist schon langsamer als mit DDR3 abwer nicht so viel.
Vanye R. schrieb: >> Wenn high performance, Echtzeit und robust (was zum Einsatz > eines FPGA >> motiviert) ist man automatisch bei UDP und nutzt das besser auf bare >> metal. > > Ich glaube nicht das du entscheidest ob du UDP willst oder nicht. Es ist > eher so das der Kunde dir sagt welchen industriellen Feldbus er haben > moechte. Und selbst wenn dann vielleicht ganz weit unten noch UDP > ausgetauscht wird, in den Schichten darueber schlackern dir doch die > Ohren weil das so abgehoben und komplex wird. > Und unter Linux ist es weniger komplex? Es ging um Netzwerk als Argument pro Linux. Da setze ich jetzt mal Ethernet oder allenfalls noch EtherCAT als paketbasierte Voraussetzung an. Nächste Entscheidung wäre dann UDP oder TCP/IP, was darüber läuft, ist typischerweise ein portierbarer (C/C++) Stack. Wenn man sich Komplexitäten einbrocken will, kann man das ja machen, solange debugbar. Andreas M. schrieb: > Martin S. schrieb: >> Was den Energieverbrauch unter Netzwerk-Vollast angeht, wäre bei mir die >> Schmerzgrenze bei ~750 mW, im Idle eher bei 50mW. Aber stromsparend >> würde ich das nicht nennen :-) > > Wie soll das funktionieren? Ein guter GBit Phy braucht selbst im EEE > Modus bei Null Traffic gut 50mW. Idle heisst hier: Phy aus. Für das WLAN-Modul bzw. den 100Mbit Phy den ich einsetze geht das schon. Deutlich aufwendiger ist schon, das FPGA in den periodischen Schlaf zu schicken. Das Linux-Powermanagement ist allerdings nicht gerade für seine Einfachheit bekannt (auch unter SBI). Wie auch immer, ich klinke mich hier mal aus, da wohl auf die interessanten Details keine Antworten mehr kommen.
Ob S. schrieb: > 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) "Microkernel" heißt, daß alles außer Prozeßscheduler, Speicherverwaltung und IPC in separate Prozesse ausgelagert ist (nicht Threads, wohlgemerkt). Wenn Module geladen werden (können), heißt das "modularer Kernel".
Martin S. schrieb: > Idle heisst hier: Phy aus. Für das WLAN-Modul bzw. den 100Mbit Phy den > ich einsetze geht das schon. Deutlich aufwendiger ist schon, das FPGA in > den periodischen Schlaf zu schicken. Das Linux-Powermanagement ist > allerdings nicht gerade für seine Einfachheit bekannt (auch unter SBI). Ok, das wäre für mich eher Standby :-). Idle heißt bei uns auf dem Bus ist nix los. Wobei die 750mW Da auch schon sportlich sind, naja gut, wir haben zwei Phys im SoC. Warum bei 100 MBit eigentlich einen FPGA? Da reicht doch ein oller Cortex-M4 mit 100 MHz, also uns zumindest. Wir verwenden ein (kommerzielles) RTOS + lwIP. Stromsparen geht doch mit einem MC viel einfacher. Ich vermute mal der FPGA macht noch mehr wo's dann wirklich aufs Timing ankommt?
Andreas M. schrieb: > > Warum bei 100 MBit eigentlich einen FPGA? Da reicht doch ein oller > Cortex-M4 mit 100 MHz, also uns zumindest. Wir verwenden ein > (kommerzielles) RTOS + lwIP. Stromsparen geht doch mit einem MC viel > einfacher. Ich vermute mal der FPGA macht noch mehr wo's dann wirklich > aufs Timing ankommt? Ja, Realtime ist relevant, aber dazu wäre FPGA nicht zwingend. Cortex flog wegen architektureller Schwächen der MPU raus, und da DSP-Leistung benötigt wurde, hat sich der Ansatz zumindest unter Volllast als am stromsparendsten erwiesen. Den höchsten Stellenwert hat allerdings die vollständige Verifikation des Systems in der Simulation. Half auch beim Debuggen immens. Konnte vor ca. 14 Jahren übrigens auch uClinux vom SPI-Flash booten, siehe auch Schwesterarchitektur ZPUino von Alvaro Lopes. War aber nicht praktikabel :)
Florent hat blog geschrieben ünber das Linux setup, link: https://enjoy-digital.github.io/posts/trenz-tel0025/
Beitrag #8072143 wurde vom Autor gelöscht.
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.