News Raspberry Pi 5: Kleinst-PC nutzt „Chiplet-Design“ mit eigenem I/O-Controller

[ModellbahnerTT]

Das ganze ARM Ökosystem ist aber dennoch viel weiter.

Da habe ich so meine Zweifel weil man immer noch für jedes System ein anderes Image braucht und es kein coreboot oder ähnliches dafür gibt.

Wer braucht schon 4 oder gar 8 GB RAM auf so einem Board?

So manche Anwendung freut sich über mehr RAM.

 

[Blutschlumpf]

Lol, was für ne Begründung, als ob das nicht vollkommen belanglos ist ob der PC/Pi jetzt 3, 5 oder 20 Watt braucht während er ein Spiel emuliert solange das die Kühllösung vor kein Problem stellt.
Daneben steht dann vermutlich der 65 Zoll OLED, der 150W verbraucht und der Av-Receiver mit nochmal 40W.

Verstehe mich nicht falsch, für so Dinge wie einen Homeserver, der 24/7 läuft mach das einen großen Unterschied ob 3 oder 5 Watt idle verbraucht werden, aber doch nicht für nen Rechner der bei den meisten Leuten keine 3 Stunden im Monat läuft.

Wem der Stromverbrauch wichtig ist, der sollte bei x86 übrigens nicht nach einem Mini-PC gucken, sondern nach einem Notebook.
Für 100-150 bzw. 150-200 € bekommt man gebrauchte Notebooks mit Intel Generation 6/7 bzw. 8, die bekommt man idle auf Region 2 Watt (ohne Bildschirm) und die haben einen vielfaches der Performance eines jeden Raspberry.

 

[Piktogramm]

@ModellbahnerTT
Mir leuchtet nicht sorecht ein, was du da argumentierst. Meine Aussage war nicht, dass ARM perfekt sei. Bootloader sind bei den ganzen ARM SoCs uneinheitlich und oftmals eine Krankheit. Aber ARM versucht Uefi vereinheitlicht durchzudrücken und entwickelt fröhlich mit U-Boot. Den Ansatz gibt es bei RISC-V so nicht. Das was es da vereinheitlicht gibt, beruht allenfalls darauf, dass hinter den meisten größeren SOCs IP von SiFive steckt.

Vor allem ändert es auch nichts, dass man zu ARM gehen kann und da CPU Cores, Bus und Interconnect IP bekommt, GPU, MMU, IP für Peripherie samt PHY. Bei RISC-V gibt es keine solche Anlaufstelle, die einem ein komplettes Paket schnüren kann.

Auch ist das Softwareökosystem bei RISC-V deutlich abgeschlagen. Allein schon solche Sachen, dass die Vektorerweiterung "kurz" vor der Finalisierung nochmal deutlich "durcheinandergewürfelt" wurde. Es gibt jetzt Risc-V Cores kaufbar, die die Vektorerweiterung vom Draft implementieren und gleichzeitig kommen die ersten Designs mit der finalen 1.0. Naja und keine zwei Jahre Vektorerweiterung, entsprechend mies ist die Softwareunterstützung. Allein wenn ich mir OpenSSL AES Implementierung ansehe. Da scheint es keinen Zugriff auf Vektorregister zu geben[1]. Das ist echt alles nicht sooo berauschend.

Bei Grafik und RISC-V basierten SoC wird es noch schlimmer. Mehr oder weniger die einzige nutzbare Grafik IP ist PowerVR und deren Treiber sind mies.

[1]https://github.com/openssl/openssl/blob/master/crypto/aes/asm/aes-riscv64.pl
Vergleichend Dazu ARMv7: https://github.com/openssl/openssl/blob/master/crypto/aes/asm/bsaes-armv7.pl nutzt Neon Register. Nutzt also die bescheidenen Vektorfähigkeiten der alten Architektur.

ABER: Ich finde RISC-V schon toll. Offene ISA, halbwegs transparente Entwicklung, interessante IP drumherum.

 

[Th3Dan]

Ein Offenes System. Das ist es.
Wobei das auch relativ gesehen werden muss.

Was ist an ARM groß offener als an X86?

 

[Blutschlumpf]

Es dürfte leichter sein eine Lizenz zu bekommen ARM-CPUs herzustellen.
Ist für den Verbraucher natürlich total belanglos.
Für den ist ARM eher pain in the ass sofern er nicht gerade den 0815 Pi mit relativ guter Versorgung an Software benutzt.
Hab selber 2 Adroids gehabt, habe die aufgrund des lausigen Software Support wieder verbimmelt.

 

[WinnieW2]

Ein SoC welcher auf RISC-V Kernen basiert wäre für einige(?) Nutzer von Interesse, aber da das SoC von Broadcom gefertigt wird halte ich einen Wechsel auf RISC-V in naher Zukunft nicht für realistisch.
Broadcom hat ARM-Kerne lizenziert. Weshalb sollte Broadcom dann noch zusätzlich auf RISC-V setzen?
Ergibt für mich nicht viel Sinn.

Ausser die Raspberry Pi Foundation plant wirklich was eigenes zu entwickeln, aber solange die geschäftliche Beziehung zwischen Eben Upton und Broadcom besteht wird sich da nicht so schnell etwas ändern.
Eben Upton hat z.B. die Videocore GPUs mitentwickelt.

 

[ModellbahnerTT]

Aber ARM versucht Uefi vereinheitlicht durchzudrücken und entwickelt fröhlich mit U-Boot.

Genau da sollte man jetzt bei Risc-V ansetzen und Coreboot zur Pflicht machen damit man das derzeitige Manko bei ARM von vorne herien behebt. Die Software kommt dann auch noch nahezu von alleine dazu.

 

[cbtestarossa]

Wenn ich schon UEFI lese kommt mir mein Mageninhalt hoch.

 

[HITCHER_I]

Und wo speist der POE HAT den Strom ein? Wohl nicht über die USB-C Buchse.
Dh. im Umkehrschluss, man braucht gar kein USB-C Netzteil mit PD.

 

[Piktogramm]

Ein SoC welcher auf RISC-V Kernen basiert wäre für einige(?) Nutzer von Interesse,

Es gibt RISC-V basierte SBC für weniger als 100€. Die mit SiFive IP scheinen alle noch auf alten Designs zu basieren, haben keine Crypto- und keine Vektorerweiterung. Sind also für viele Anwendungen langsamer als ein PI4.
Dann gibt es SoC aus chinesischer Produktion. Die haben zwar teils eine Vektorerweiterung, die ist aber oftmals nach 0.7 Draft der Vektorerweiterung und damit reichlich Pita. Da hat eigentlich Niemand Grund hat eine Linuxdistri und Software zu bauen, die den Draft unterstützt..

Betroffen ist u.a. der Allwinner D1 SoC. Der CPU IP ist ein XuanTie C906, der wird/wurde damit beworben RV64GCV zu beherrschen. Steht aber nur im Kleingedruckten, der mehr oder weniger inoffiziellen übersetzen Dokumentation: https://occ-intl-prod.oss-ap-southeast-1.aliyuncs.com/resource/XuanTie-OpenC906-UserManual.pdf

Imho RISC-V SBCs sind Gefummel. Das Entwickeln und Suchen nach Support ist da das Hobby. Das ist schon arg Unterschiedlich vom Raspi, wo man sich um den Unterbau kaum kümmern braucht und mit I/O Pins und Software direkt spielen kann..

Genau da sollte man jetzt bei Risc-V ansetzen und Coreboot zur Pflicht machen damit man das derzeitige Manko bei ARM von vorne herien behebt. Die Software kommt dann auch noch nahezu von alleine dazu.

Theoretisch hat ARM schon recht lange Vorschläge gemacht, wie ARM Systeme zu booten sind. Hat sich halt kein Schwein dran gehalten. In der RISC-V Foundation wird auch vorgeschlagen, dass man doch bitte OpenSBI nutzt und daran Coreboot oder U-Boot anflanscht um dann Linux (und BSDs) über etablierte Schnittstellen zu starten. Es kann aber nicht erzwungen werden und sich darauf zu verlassen, dass sich da jeder an die freiwilligen Rahmenbedingungen hält..

 

[cbtestarossa]

Wieso baut man nicht sowas wie BIOS gleich per Chip auf die Boards?
UEFI muss ja nicht sein.

 

[ModellbahnerTT]

Wieso baut man nicht sowas wie BIOS gleich per Chip auf die Boards?

Einerseits sind es die Kosten und andererseits ist der Strom verbrauch der minimal steigt.

 

[Piktogramm]

@cbtestarossa
Die Raspis haben mindestens ab den Pi4 internen Speicher für einen Bootloader, weswegen man die Dinger ohne gesteckte SD-Karte auch von anderen Medien booten kann. Es ist halt proprietäres Gefrickelt von Broadcom.

Bios will Niemand mehr im 21. Jahrhundert.

Deine Abneigung gegen UEFI verstehe ich nicht. Das ist erstmal nur eine Spezifikation mit zig Implementierungen. Ohne diese Spec gäbe es wirklich nur Wildwuchs und so gruslige Lösungen wie von Broadcom wären die Norm überall..

@ModellbahnerTT
Das ist Unsinn, vor allem da die PIs mindestens ab der 4. Generation Onboardspeicher für Bootloader haben.

Ergänzung (3. Oktober 2023)

Rein auf verdacht ist der Baustein mit 8Pins an der rechten, unteren Ecke des SoC SPI Flash/EEPROM. Von dem dürfte als aller erstes gelesen werden beim Booten.
Quelle: https://www.ghacks.net/wp-content/uploads/2023/09/Raspberry-Pi-5-specs-price-and-more_2.jpg

 

[cbtestarossa]

BIOS ähnlichlich war meine Intention.
UEFI ist ja noch mehr aufgebläht.
Ausserdem konnte man das BIOS noch per Jumper schreibschützen.
Ins UEFI können sich ja sogar Trojaner einnisten.
Keine Ahnung was man machen könnte.
Aber es ging ja darum dass dieses uneinheitliche Gefrickel aufhören soll.

Früher war ja auch noch alles gesockelt und die Bausteine viel größer.
Das Miniteil im Bild könnte so ein EEProm sein ja.
Solche Teile gabs dann später auch fürs BIOS.
Aufgelötet bringts halt nix wenn sich da mal was einnistet was nicht dort hin gehört.

Die paar Cent was n Sockel und son Minibaustein kostet macht das Kraut auch nicht mehr fett.
SATA nativ wäre auch schön.

 

[Haldi]

Wem der Stromverbrauch wichtig ist, der sollte bei x86 übrigens nicht nach einem Mini-PC gucken, sondern nach einem Notebook.
Für 100-150 bzw. 150-200 € bekommt man gebrauchte Notebooks mit Intel Generation 6/7 bzw. 8, die bekommt man idle auf Region 2 Watt (ohne Bildschirm) und die haben einen vielfaches der Performance eines jeden Raspberry.

Cool Idee.
Aber sofern man nicht gerade ein Thinkpad erwischt dürfte da der Linux Support recht dürftig sein.
Wär schon crappy wenn das Display nicht läuft für die installation, oder noch schlimmer das Netzwerk.

 

[Blutschlumpf]

Unwahrscheinlich, speziell LAN-Support ist im Linux-Kernel seit locker 20 Jahren easy-peasy.
Treibertechnisch spricht der Kernel da ne Intel IGP oder Realtek LAN an, egal ob die Sachen in nem Thinkpad oder Medion Billiggerät stecken.
Und wenn BT, Tochpad, Webcam oder der total exotische Fingerabdruckscanner nicht erkannt werden: Wayne?

Aber realistisch betrachtet sind die Masse der gebrauchten Notebooks auf dem Markt eh Thinkpads, Latitudes oder Probook/Elitebooks und nur selten typische Endkundenware.

Aber wenn du es drauf anlegst:
Ebay auf und nach Notebooks mit Scharnierbruch, Rissen, Displayschäden und so Zeug gucken, da kommste mit was Geduld preislich auch in die Raspi-Region.
Bei mir im Keller steht ein altes neongelbes Gaming-Notebook mit Wackelkontakt was auschaut als wär das 5 Jahre auf dem Bau benutzt worden und dabei 13 mal vom Gerüst runtergefallen.

 

[Piktogramm]

BIOS ähnlichlich war meine Intention.

BIOS ist eklig, das ist verkörperte IBM/PC x86 Altlast.

UEFI ist ja noch mehr aufgebläht.

Die Spezifikation (https://uefi.org/specs/UEFI/2.10/36_User_Identification.html#security-considerations) ist umfangreich, vor allem da die ACPI Spec mehr oder weniger dazugehört (https://uefi.org/specs/ACPI/6.5/),
Das ganz große ABER ist aber, dass Uefi und ACPI so viele Sachen vereinheitlicht hat und für die Vielfalt an Hard und Software so extrem viel homogenisiert, dass es dafür fast schon absurd kompakt ist.
Und eigentlich lassen sich UEFI Implementierungen vergleichsweise kompatk halten. U-Boot, Coreboot sind ja wahrlich keine Monster[1].
Das Implementierungen aufgebläht werden können ist eine andere Geschichte. Grafische Oberfläche, Fernwartung, Firmwareupdater, 20 Milliarden Fixes für Hardware die sich nicht an die ACPI Spezifikation hält, mehrere µCode Pakete für alle möglichen CPUs.

Ausserdem konnte man das BIOS noch per Jumper schreibschützen.

Verbietet die Spec nicht. Wobei die Variante das über Passwort mit Crypto zu erledigen wesentlich schlauer ist Imho.

Ins UEFI können sich ja sogar Trojaner einnisten.

Geht im Bios auch. Beschreibbarer Speicher bleibt beschreibbarer Speicher und von dem Speicher wird als alles erstes geladen und erfolgt Ausführung. Je nach Implementierung kann UEFI mehr, weil es auf CoProzessoren läuft.
Und Beschreibbarkeit. 1. Damit man Firmwareupdates machen kann und 2. damit man Log schreiben kann. Sowohl das Uefi selbst, als auch das Betriebssystem, wenn es seinen Festspeicher noch nicht eingebunden hat. Problematisch wird es nur, wo die Implementierung die Schutzmechnismen dazu verkackt.

Aber es ging ja darum dass dieses uneinheitliche Gefrickel aufhören soll.

Da gibts bisher nichts schöneres als UEFI + ACPI

Früher war ja auch noch alles gesockelt und die Bausteine viel größer.

Heißluftlötsation und Flussmittel, es ist schwerer aber nicht unmöglich. Da das in der Regel SPI Speicher ist, muss man oftmals noch nichtmal löten, sondern könnte auch direkt mit SPI drauf kontaktieren.
Schlimmer ist wie so oft, dass der propritäre Teil nicht dokumentiert ist -.-

Die paar Cent was n Sockel und son Minibaustein kostet macht das Kraut auch nicht mehr fett.

Sockel braucht platz, riesige Pads oder gar Löcher. Damit wird das Routing auf der Platine schwerer und man braucht ganz fix 1..2 mehr Lagen. Dazu extra Aufwand bei der Bestückung und Sockel + DIP Chips bzw. vergleichbare Chips sind mehrfach teurer als SMD. Du unterschätzt da die Kostenentwicklung.

SATA nativ wäre auch schön.

Manche wollen NVMe, manche wollen Sata. Stellste davon je einen Port, werden welche rumheulen was das soll. Ein Port ist zu wenig, wenn Sata/NVMe da, dann 1GBe zu lahm, ...
Realistisch hat das Ding 1PCIe2, inoffivziell PCIe3 Port. Da kann ein ASmedia HBA controller 4 Sata Ports draus machen und das ganze für ~25€ + Gebastel damit man 12V Versorgung bekommt für die HDDs. Oder man wartet auf die Computemodule, die könnten bis zu 5x PCIe ausführen.

Wobei ich da auch das Spannungsfeld sehe. Wenn man den PI zu einer universellen Plattform macht, muss man sofort gegen x84 Plattformen ankommen. Da kostet ein AlderLake-N Mobo derzeit ~110€ und günstiger wäre der Pi dann auch nicht. Nur halt um etwa eine Größenordnung langsamer... das ist nicht attraktiv.

[1]Im Vergleich zu dem, was im Jahr 2023 so alles Firmware ist.

 

[jlnprssnr]

schade auch beim 5 ruckeln also die N64 Games.Scheint wohl doch nicht so leicht zu Emulieren zu sein

Warte mal auf Updates mit Pi 5-Kompatibilität für die Emus, bevor du urteilst. Im Video läuft komplett unoptimierte Software, wie er auch sagt.

 

[Mac_Leod]

Hatte so gehofft, dass eine 16GB RAM Version kommt.
Dann wären aus 3xPi 4 1x Pi5 geworden 😔
Beeindruckend dieser Leistungssprung.
Und die Lizenzen für den Encryption Spaß sind auch diesmal dabei. /cheer

 

[HITCHER_I]

Und die Transistoren dafür wohl endlich auch.