A Raspberry Pi projekt elismerte, hogy hibás dizájn miatt egyes adapterekkel (kábelekkel) nem fog működni az Rpi 4

Címkék

The new pi has been released and it has a USB Type-C connector for power however people are finding some chargers are not working with it [...]

Eben Upton (az Rpi egyik létrehozója) megerősítette a probléma létezését.

Hozzászólások

Upton went on to say, "I expect this will be fixed in a future board revision, but for now users will need to apply one of the suggested workarounds. It's surprising this didn't show up in our (quite extensive) field testing program."

in a future board revision

Hat mit kepzel ez? Tehat nem a __next__, hanem az akarhanyadik, ha jol ertelmezem a mondatot.

Hát lehet elromlott az irónia detektorom, de azt gondolja hogy mint egy rendes nem garázs cég már egy picit előrébb járnak a tervezéssel, kapacitás lefoglalással a gyártósoron és esetleg nem az elsőbe fog beleférni hogy ezt a hibát javítsák. Mivel egyébiránt megy jól pl. hat tőle veszel tápot.
Én pl emlékszem hogy egy régebbi esetnél az volt a mondás, nincs hiba "rosszul tartod".
Hát ez sokkal korrektebb megoldás.

Mert ezt talaltam ki, es egesz jol mukodik.

Ha pl. a GitHub-ot hasznalnam verziozasra, akkor ott lenne a forgalom a GitHub es a ket (munkahelyi es az otthoni) gep kozott. Igy meg csak egy bridge van a git server es valamelyik gep kozt, es nincs havi kvotazas.

Nekem nagyon bejon, hogy ott van a fejlesztoi gep mellett a git server, es berakom a taskaba, ha megyek haza.

Amig nem giteltem, addig hazamenetel elott mindig bezippeltem a "working directoryt", aztan masotam pendrajvra. Amiota viszont gitelek, azota ez a masogatas teljesen eltunt az eletembol, es igy kenyelmesebb minden; a push-sal lemegy a masolas is, nekem csak le kell huznom az rpi-t a madzagokrol, es mehet a taskaba.

Azt nem tudom –mert nem igazan gondolkodtam rajta–, hogy mi lenne, ha nem egyedul lennek fejleszto a cegnel, de igy nagyon kenyelmesnek talalom. Persze kenyelmesebb lenne a GitHub onmagaban, ha nagyon gyors internet eleresem lenne mindket helyen, es nem lenne forgalmi kvota.

Azért kérdeztem erre rá, mert én pl. nem aludnék nyugodtan, ha magammal hordozgatnám a git repoimat: ha bármikor lenyúlhatják a kis dobozt, az szerintem nagyon nagy kockázat. Nekem nagy biztonságérzetet ad az, hogy legfeljebb annyi munkám veszhet el, amennyit még nem küldtem fel a GitLab-ra. Nem beszélve azokról a balesetekről, amik még érhetik, ha ott van mellettem: véletlenül leöntöm, megsül a memóriakártya, stb.

Milyen kvótára gondolsz? Nem mértem, de **szerintem** nem forgalmazhat túl sok adatot egy git, ha jól csináljuk: mivel a repóba jó esetben nem kerül be semmilyen nagyméretű "blob", ezért "csak" szövegfájlokat kell felküldeni a kapcsolaton keresztül. Plusz a felküldött cucc is csak delta, ráadásul tömörítve, ha jól értem.

Ha elhagyom/ellopjak, akkor is ott van azon a gepen az aktualis allpot, ahonnan eljottem; nem tartom nagy kockazatnak, ha viszi valaki a forrast, mert nem fog vele semmire sem menni. Ha kozben meg megadja magat a gep, ahonnan eljottem, akkor max 1 napi munka esik ki, de ilyen azert ritkan fog elofordulni. Ha a kave belemegy stb. akkor lecserelem egy ujra, de nem tartom kozvetlen mellettem, a memoriakartya ha elszall, erre nagyobb az esely, akkor az szivas lehet, de erre majd kitalalok valamit: mondjuk leszinkronizalom a kartyan levo adatokat valahova.

A kovta alatt meg azt ertem, hogy ha ott van a GitHub, de szerintem a GitLabnal is hasonlo a helyzet, akkor van egy havi kvota a forgalomra, amit ha tullepsz, akkor nem fogsz tudni adatot fel/le tolteni, vagy fizetni kell erte pluszban.

De ha a kvota nem is lenne, akkor is kenyelmes a zsebszerver, mert neha jol esik egy clone-t csinalni, es ilyenkor 1 giga adat is kozlekedhet (nalam minden anyag ott van a working tree-ben, ami a projekthez tartozik, nyilvan az .gitignore-ban fel vannak veve azok a reszek, amelyek nem track-keltek, pl. a juzertol lementett adatbazis nincs a git felugyelete alatt, de ott van tobb peldanyban a workingben, mert hova kellene mashova tennem (persze lehet linkekkel is mutagatni mashova, de elegem lett abbol, hogy egy projekthez tartozo dolgok itt-ott vannak elszorva. Miota attertem a gitre, ez az egyik legjobb dolog, hogy mindent egy directory ala tudok becsoditeni, es a verziozas (mentés) meg egy masik dolog.

"A kovta alatt meg azt ertem, hogy ha ott van a GitHub, de szerintem a GitLabnal is hasonlo a helyzet, akkor van egy havi kvota a forgalomra, amit ha tullepsz, akkor nem fogsz tudni adatot fel/le tolteni, vagy fizetni kell erte pluszban."

Tudtommal ilyen nincs, és eddig soha nem ütköztemn limitbe, de ha tudsz linket adni, azt megköszönöm.

Clone-csinálás: sima cp miért nem jó a már ott lévő anyaghoz?

Asset kezelés: lehetnek például egy bucketben valahol a felhőben.

Én egy limitbe futottam bele eddig GitHub-on: talán két éve nem tudtam 100+k ref-et egy 'git push'-sal feltölteni, de egy egyszerű for ciklussal 10k ref-enként gond nélkül felment mind. Hogy ez a korlátozás valahol dokumentálva van-e a halandó userek számára, vagy hogy még mindig így van-e, azt nem tudom.
Ami a forgalmi kvótát illeti: sorban egymás után tudtam clone-ozni a linux, gecko-dev, gcc, webkit, chromium repókat, ami összesen kb 30GB, szóval ha van is forgalmi kvóta, az sok-sok nagyságrenddel többnek tűnik, mint a napi backup-okhoz szükséges adatforgalom.

+1

Én az ilyen nagyon érzékeny dolgot úgy oldottam meg, hogy:

- vagy egy 4-8-16 GB-os virtuális gépen futott a GitLab, ahol volt LUKS / TrueCrypt / VeraCrypt, és ezt hordoztam vagy mentettem
- vagy csak a Git repo / Git Data könyvtárat (ahol az összes repo van) tartottam titkosított konténerben (lásd előző sor), a VM egy külön image-ben volt, és boot-kor mountolta fel ezta másikat, amiben csak adat volt. Így a VM-ben nem volt érzékeny adat, csak a másik konténerben

És ezeket az image-okat általában USB3 / 3.1-es keretben, SSD-n tartottam vagy nagyon gyors pendrive-on, továbbá mindig volt +2 fizikai helyen valamilyen mentés: szinkronizáltam valahova a titkosított image file-okat. Mondjuk soha nem volt így adatvesztésem.

Sakk-matt,
KaTT :)

Uppsz!!!
Mindig tanulok valami ujat. :)

Nem tudom miert bonyolitottam tul. Talan azert, mert nem regota gitezek, es nem jutott eszembe, hogy beirjam a git:// helyere a file:// -t.
Akkor az rpi-rol leveszem ezt a "terhet", mert a pendrajvval nem versenykepes (meretben sem es egyszerusegben sem...).

Koszi a felvilagositast!

mellete meg mindig berelhetsz par $-ert egy vps-t, azon hosted gitlab (vagy barmilyen git kezelo, akar a pure gitcore), aztan syncelheted fel a repot. aztan meg a pendriveot se kell vinned (engem mondjuk a notibol kiallo cuccok szoktak zavarni)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Tudom, nem mentség, de nem azt mondták, hogy csak a sajátjával megy, hanem azt, hogy nem mindennel megy.

Úgy olvastam, hogy telefonokhoz való töltőkkel általában megy, laptophoz való töltővel meg nem.

Szóval még akár az is lehet, hogy a ház minden szegletében tudnád használni.

A régi pi-k sem feltétlen mentek okos töltőkkel, mert azokon nem volt ellenállással megadva, hogy értse a töltő, adhat több ampert.
Az új pi-nél megint csak butatöltővel megy, valsz most is csak azért nem rázták le a panaszkodókat, mert a type-c elvileg előírja, hogy milyennek kell lennie az ellenállásoknak.

A régi táp + pár centes type-c adapter is valsz jól fog menni. Laptol töltővel és más, spéci okoskábellel nem megy.

Ilyenek miatt is érdemes várni egy új verzióval. Sok pHAT és board nem megy RPI 4 esetén, csak a 3B+ -ig kompatibilis.
Sok eszköznél láttam a webshop-okban, hogy: "NOT FOR RPI 4!".

Sakk-matt,
KaTT :)

Szerintem normális az, hogy egy adott eszközhöz tervezett hardver nem működik egy másik eszközön, ami eltérő felépítésű.

Majd lesznek olyan kiegészítők, amik az újhoz jók.

Biztos vannak és lesznek olyanok is, amik nem használnak hardver specifikus dolgokat, és most is működnek meg a jövőben is valószínű működnek.

Ezzel csak az a gáz, hogy a málna projekt nem erről szól. Én is elhamarkodottnak érzem a kiadást, mind szoftver, mind hardver oldalról. Ha belegondolsz, a gpio ugyanaz már generációk óta, nem véletlenül. Ráadásul pont az usb-c-nél jön elő, ami elég rendesen le van dokumentálva hogyan is kellene az éhesebb fogyasztókat ellátnia szuflával.

Az USB-C szerintem is elkúrás.

Inkább a kiegészítő boardokra gondoltam. Az egy dolog, hogy az interfész ugyanaz, de más hardver elemek jönnek utána. Biztos vagyok benne, hogy egy olyan eszköz, ami a GPIO-t adatok küldésére, mérésre, led villogtatásra, motor forgatásra használta, az továbbra is megy.

De mondjuk egy olyan board, ami bővítőkártyaként szolált és plusz ethernet csatlakozókat, vagy videokártyát, hangkártyát, ezt-azt adott a rendszerbe, az simán lehet, hogy nem csak a tüskék méretétől és helyétől függ, hanem valami olyasmitől, ami megváltozott. Pl. eddig USB volt, most meg direktbe kapcsolódik.

Persze nem tudom, hogy konkrétan melyik eszközök törtek el. Ha a villogó karácsonyfa ledek, az gáz. Ha egy lebegőpontos számoláshoz segédprocesszort tartalmazó board, az szerintem belefér.

Azért siettek szerintem, mert a konkurens gyártok még a most kiadott RPI 4-nél is erősebb hardvert árulnak már jó régóta, 2-3-4-8 GB memóriával, stb.
Ha nem adják ki, elbukják a részesedésüket a jövőben még jobban.

Szerintem a legfontosabb nagy lépés az lenne, ha raknának elsőre 2 darab SATA3 csatlakozót, amely a leggyorsabb módon csatlakozik a CPU-hoz, és nem USB-n keresztül, stb.
Onnantól lehetne RAID1-et szoftveresen csinálni.

Sakk-matt,
KaTT :)

usb3 mellett már nem szűkös a háttértár kezelés sem. UASP kompatibilis usb3-as házban már sata ssd-t is kihajt elég jó sebességgel.

Pcie 2.0 1x csatolón van az usb3 chip. CM modulon nem szoktak ilyen dolgok rajta lenni, hanem minden gyártó a maga igénye szerint azt köt rá, amit akar. Például egy sata vezérlőt.

Amúgy van egy olyan előérzetem, hogy ha kiadnak CM4 modult, esetleg az alapítványosok eleve kiadhatnak olyan io dev boardot, amin van pcie 1x slot. Sokan megvennék valsz sima haszálatra is, nem csak ipari területre. Még a vastagabb árazásukkal is.

De például az is érdekes kérdés, hogy lesz -e 4A model. Mert az A-kon nem szokott lenni extra lan és usb. A pi4 soc pedig továbbra is tartalmazza a saját usb2 portját - a 4b esetén a type-c re van kivezetve egyébként közvetlenül - usb gadget módot tud. Szóval akár az A is lehetne olyan, hogy egy tüskesor helyet hagynak pcie -nek, mégha slotot nem is kap. Most is vannak olyan boardok, ahol pcie tüskesoron van és fizikai adapter kell hozzá.

A lényeg, hogy a mostani soc-ban marha sok potenciál van. Sokféle kiegészítőt vagy spéci "ipari" megoldást el tudhatnak adni a jelenleg 4B-vel nem kiaknázható lehetőséggel. Ha felcsapunk rá egy pcie multiplexert és kompatibilis vele, akkor akár több slotos megoldás is lehet - persze osztorva az 1 lane 500-as tempóján.

Valami elvetemült már leforrasztotta az usb3 chipet és kikötötte a pi4-ről a pcie portot és egy adapterrel rákötött külső SAS kontrollert :D
https://blog.hackster.io/pci-express-on-the-raspberry-pi-4-9b03c59f7a04
http://mloduchowski.com/en/blog/raspberry-pi-4-b-pci-express/

Én eddig azt láttam, hogy mindig is voltak erősebb hw-t felvonultató gyártók a kategóriában, de
vagy kiforratlan volt a Linuxos támogatás
vagy kiegészítők terén nem vehette fel a versenyt a Pivel
vagy hozott ugyan extra ramot, cput és plusz hardverelemeket hozott a Pivel szemben de irreálisan drágábban.
Illetve ezek kombinációi.

Hasonló sikert eddig szerintem csak az Arduinok tudnak felmutatni, de az már kicsit más kategória.

A nyár egyébként is uborkaszezon szerintem. Mert ha mindez karácsony előtt történik még csak megértem a sietséget, de most nem nagyon.

A vicc, hogy kb. egy hónapja olvastam, hogy mikor lesz Pi4? Akkor azt ígérték, hogy jövő nyár előtt nem...
A type-C-hez meg annyit, hogy épp ebben a cikkben írták, hogy nem annyira szeretnék, és max. a tápnál lesz használva, ott is azért, mert a 2.5 A kevés lesz, amit a micro még tud. És épp ezért lett type-C.

Tudsz konkrét példát mutatni, amelyik pHat nem megy?
Meglepő lenne, mert teljesen azonos a kiosztásuk.

A pi ráadásul továbbra is videocore alapú, csak az újabb fejlesztésekből pár modult belepakoltak.

Az peresze látszik, hogy szoftveresen még nincs minden rendben. Máskor, ha az új képességek nem is feltétlen voltak még kiforrottak, de a régiek implementálva voltak. Most kissé trógerebbül sikerült. Lehet azért, mert picit szorongatták már őket - bár szerintem, ha kiteszik a 2018as pénzügyi jelentést, megint le fog esni az állunk. De simán lehet, hogy azért bátorkodtak erre, mert frissíthető flash-re került a boot rom - főleg abból vannak hiányosságok még.

Ha jól emlékszem CAN busz adaptereknél, és audiophile HAT moduloknál láttam, hogy pirossal ki volt írva, hogy RPI4-hez nem való (az elmúlt 1-2 hétben sok helyen láttam, ha tudom, kigyűjtöm neked). Az is lehet, hogy bizonyos javítások után jó lesz, ahogy volt a 3B+ esetén is gond, hogy le kell butítani az Ethernetet max 100 mbites kapcsolatra, különben recseg a zene, mert ott USB-n van rákötve az Ethernet és bezavar, ha a zenét UTP-n olvasod és gigabit van + hangkártya.

Sakk-matt,
KaTT :)

Jöhet a javított verzió.

--
robyboy

Jól megszívta aki ilyet rendelt és pont olyan kábele van amivel nem kompatibilis az eszköz.
Szegény most vehet másik kábelt 1000-1500 Ft-ért. :)
Bakinak baki, de nem olyan vészes.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Azt mondjuk totál nem értem, ha ott van a szabvány, ami definiálja, hogy milyen körülmények között működnek az USB Type-C eszközök, kapcsolatok, akkor miért kell okosabbnak lenni és megmutatni, hogy de nem, az hülyeség. Aztán rádöbbenni, hogy nem hülyeség, okkal van kitalálva. Komolyan csapnám tarkón azt a fejlesztőt, aki eltér a szabványtól.

Ave, Saabi.

+1
"Komolyan csapnám tarkón azt a fejlesztőt, aki eltér a szabványtól"
Meg azokat a kretén barmokat akik bár már létezik szabvány, akkora királynak hiszik magukat hogy a kis(nagy) szemétdombjukon sajátot hoznak létre, persze szarul és nem létezik két olyan eszköz ami a sajátszart pont ugyanolyan elbaltázva implementálná.
az összes ilyen gyökérne pé{&/szív}lapát..
#telenyom