Názory k článku
PCI-Express na Raspberry Pi 4
-
No nějak si neumím představit, proč k malému ARMu určeném hlavně na bastlení a drobné projekty cpát výkonnou GK. I kdyby to všechno tak nějak chodilo, tak ten úsporný ARM tu grafiku stejně nebude stíhat krmit daty. A kdybych chtěl něco na výpočty s GPU - no, taky bych si uměl představit deset lepších způsobů, než ničit tuhle malou destičku.
-
Hračičkování se nikam nepodělo (to bych si doma jinak nerenovoval staré Atari ST a nečekal Didaktik na to samé), ale RPi je pěkná hračka už sama o sobě, a ničit ji odstraňováním čipů kvůli nesmyslu, který nemá prakticky žádný použitelný význam... Je to sice zajímavé, že ten čip tohle má a umí, nicméně to je tak vše. To, že má vyvedenou sběrnici bych zjistil i z datasheetu.
-
Tohle ještě není tak hrozný, mě se něco podobnýho povedlo už v roce 2018 (viz blog v popisku videí) na mnohem pomalejším čipsetu než je Rpí. Ten můj SoC má jen 580MHz a 256MB RAM (původem z routeru) a i tak jsem na něm zprovoznil minetest s nádhernejma 5 FPS :-D a dokonce blender. A drivery grafiky (AMD Polaris) fungujou s minimálními úpravami i na MIPSu.
-
Transparentní asi ne ono není ani vůbec jasný zda to ten mód PCIe device mód opravdu umí, ty registry můžou být jen pozůstatky z jiného ořezaného modelu. Ten původní HDL to ale bude umět (si člověk v syntéze zvolí jakej typ řadiče chce vygenerovat), ale zrovna v tomhle mediateku se někomu povedlo spojit oznámení o link up se signálem resetu řadiče.
Nicméně i kdyby HW fungoval bezchybně, tak transparentní PCIe asi nepůjde. Jednak ten řadič funguje jako pevně definované zařízení co má vlastní adresu (nemyslím že by řadič mohl být schopný přijímat RAW pakety), ale i v módu "naklonované zařízení" nejspíš nebude systém schopný detekovat, že PCIe řadič zapsal do RAM. V SoC jsou asi 2-3 mechanismy jak může kód sledovat zápis do RAM (breakpoint MIPSovýho jádra, něco jako monitor DRAM řadiče a pak adresa pro user přerušení), ale jsou to jen jednotlivé adresy a možná to ani nebude přístupné z jiného mastera než CPU.
Co by možná šlo udělat by byl nějaký nentransparentní bridge, kde by měly oba vocore nějaký speciální protokol. Samozřejmě by to vyžadovalo přepis každého driveru použité PCIe karty.
Jinak wifi jsem testoval minimálně, rychlost byla před lety dost slabá.
-
V kombinaci třeba s tímhle by to mohl bej zajímavej bastl. https://www.czc.cz/kouwell-pe-115h/144462/produkt
-
Proč tam složitě napojovat tuhle kartu, když stačí nějaký boxík na disky připojit přes USB 3? SATA je takový evergreen pod každou zprávičkou o RPi a občas sem někdo hodí i nějakou konkurenční desku, pro kterou sice neexistuje funkční systém, ale má SATA port. Co už pak ale nikdo nezmiňuje je napájení, protože ty desky ho ošetřené nemají a tahle karta taky ne.
-
Nemyslím si, nvmi potřebuje PCIE linky, a u lowend CPU jsou k dispozici třeba jen 4 a ty jsou vyvedené na slot pro grafiku, nebo chipset, takže na nvmi nezbývá místo. Narozdíl od toho lowend chipset nabídne klidně 4 SATA porty. A pokud myslíte použití nvme konektoru pro SATA, pak se ušetří leda kabeláž a místo a i to je diskutabilní, jelikož na klasické ATX desce je místo tak na dva, pokud by se použily vícepatrové konektory tak na čtyři, ale to nevím jestli se dělá...
-
Bože, se mi zdá, že tady opravdu málokdo chápe účel zařízení jako je RPi...jasně, hodíme tam SATA porty, pak pro jistotu nějaké NVME (co kdyby někomu chybělo), k tomu PCI-E sloty, aby to všechno podporovalo, tak tam dáme jiný CPU (třeba Ryzen G, co by ne) a vlastně to kvůli tomu uděláme celé do formátu mATX a předěláme napájení na běžný ATX PSU. A celé se to bude prodávat za několikanásobek ceny.
-
chapu ironii, nicmene pokud nekdo chce neco jako "rpi" tak napr.:
ROCKPro64 s PCIe:
https://www.pine64.org/rockpro64/NanoPC-T4 s NVMe:
https://www.friendlyarm.com/index.php?route=product/product&product_id=225oboje je podporovane Armbianem...
-
Pravda, AHCI mě nenapadlo.
Nicméně koukám na spoustu quirků pro různé AHCI řadiče https://github.com/torvalds/linux/blob/master/drivers/ata/ahci.c#L247 - ale snad by implementace standardu stačila...
-
Mně to přijde hodně zajímavá úprava. Příklad využití: Dnes vzniká několik velice kvalitních DSP projektů pro audio výhybky, pro které výkon RPi4 bohatě dostačuje na stereo čtyřkanálovou výhybku. Problém ale je s výstupními zvukovkami, protože I2S RPi umí jen stereo a kvalitní USB multikanály jsou docela drahé. Tenhle mod umožňuje (netestoval jsem) použít běžné PCIe karty (třeba výbornou Xonar D2X), příp. starší PCI karty + PCI-e->PCI bridge (nové PCIe zvukovky (kromě creativu) jsou stejně původní PCI karty s přidaným onboard bridgem). Těchhle stále ještě velice slušných karet je plný ebay.
Proč na to nepoužít x86 tenkého klienta s PCI-e/PCI portem za stejnou cenu? Protože USB-C na RPi lze přepnout do USB-gadget režimu, kernel obsahuje USB-audio gadget driver a RPi lze tak nakonfigurovat jako USB 2in/8out zvukovku s velice výkonným DSP, konfigurovaným přes webový prohlížeč na hostiteli (navíc USB-ethernet gadget s auto konfigurací sítě). Takže to lze mít jako standalone výhybku s analogovým i SPDIF stereo vstupem, tak i jako stereo USB zvukovku s integrovanou výhybkou.
-
Jak je to s aktuálním jádrem a přístupem k autorům daného HW/IP (dwc2 apod)? Výše popsaný projekt vyžaduje řadu úprav/dodělávek ve stávajících ovladačích (jak generic - např. gadget UAC2, tak i specifických pro RPi) a to lze řešit pouze na nejnovějším jádru. Na příslušných mailinglistech (linux-usb, alsa-devel) se nikdo nebude zabývat kódem backportovaným na historický androidí kernel 4.4 apod.
Na RPi se USB-gadget řeší přímo s chlápky ze Synopsys (tvůrce IP core dwc2/3) a audio se správci alsy, commity jdou do mainline kernelu.
