Raspberry Pi & alternative

taz je 7. apr 2019 ob 16:10 izjavil:

rPi 4 (več verzij)

1. april :D

Q6600 jaz še vedno uporabljam v kleti za 3D modeliranje, skupaj z 8GB rama in GTX260 216sp za CUDA podporo. Pač poleg 3D tiskalnika imam še en PC za generirat g-kodo in delanje popravkov na 3D modelu. Pa zadeva lavfa kar tekoče SolidWorks.

Za PCoIP ne vem, za priklop z RDP na Win10 mi pa odlično deluje Remmina na Ubuntu MATE.

Poglejte Nvidia Jetson Nano Developer Kit... jaz sem ga včeraj dobil. Petarda.

Cr00k je 12. apr 2019 ob 18:14 izjavil:

Poglejte Nvidia Jetson Nano Developer Kit... jaz sem ga včeraj dobil. Petarda.

Ce mas za kaj rabit zgleda kr kul. :)

Mogoče kdo ve, kje nabaviti nvidia Jetson Nano v eu?

Tenkju.

Torej npr. tole: https://www.aliexpress.com/item/3284946... ?

Ni mi jasno, kako je lahko izven Kitajske cena samo čipa 5$, Kitajci pa imajo skupaj s PCB po 2,5$.

Ce na Digikey pogledas ceno za BME280 senzor, je cena za en kos $6.5 ce vzames samo en kos. Ce jih vzames 1000 je pa cena za en kos $2.7 :) Pri deset tisoc je pa cena verjetno se nizja. :)

Buo, skratka naročim in poročam. :)

Pogledat je treba za kak Real Time operating system za RPi.

https://www.freertos.org/about-RTOS.html ali kaj podobnega.

1ms locljivost tezko dosezes z operacijskim sistemom, ki ni narejen posebaj za te reci, ker ti lahko neka I/O operacija od kaksnega drugega procesa zakasni zadeve.

Al to, al pa kak Ardiuno kot buffer, da lahko dogodke obdelas dovolj hitro, RPi pa potem pobira te stvari od Arduina.

Kdo uporablja PREEMPT_RT? https://wiki.linuxfoundation.org/realti...

Hvala vsem za odgovore.

Razvija se rešitev, kot jo je BigWhale opisal. Arduino bo buffer in bo komuniciral z malino. Lahko da se bo celo celotna zadeva na arduino preselila, da ne bo treba met dveh ploščic...

Kakorkoli, hvala!

Dzhimen je 19. jul 2019 ob 00:43 izjavil:

Hvala vsem za odgovore.

Razvija se rešitev, kot jo je BigWhale opisal. Arduino bo buffer in bo komuniciral z malino. Lahko da se bo celo celotna zadeva na arduino preselila, da ne bo treba met dveh ploščic...

Kakorkoli, hvala!

Potem se splaca pogledat tudi ESP32 boarde. Zadeve imajo ze WiFi in BT in so dovolj zmogljive za marsikaj.

kihc je 12. jul 2019 ob 22:14 izjavil:

Torej npr. tole: https://www.aliexpress.com/item/3284946... ?

Ni mi jasno, kako je lahko izven Kitajske cena samo čipa 5$, Kitajci pa imajo skupaj s PCB po 2,5$.

Evo, tole sem dobil, zadeva deluje b.p.

pierch je 9. avg 2019 ob 08:39 izjavil:

Good news za rockchip naprave.

Bo to pricurljalo tudi na OrangePi RK3399 in podobne?

Ker je S-T bolj stabilen, kot pa moji povsod raztreseni zapiski ... zaznamek za naslednjič, ko ga bom potreboval.

RPi 2/3/3+ in 64-bit Fedora 28/29/30: Zadeva kot mini strežnik načeloma deluje brez težav (kar pomeni, da grafike nisem niti povohal). Kar je moteče je to, da Fedora načeloma pravilno uporabi drevo naprav (Device Tree; DT) priloženo jedru in ne tistega, ki mu ga da na voljo GPU. Stvar je moteča, ker je potrebno za vsak na GPIO/SPI/I2C/... dodan kos strojne opreme posebej pacati DTB in telovaditi s podtikanjem tega DTB-ja na pravo lokacijo od koder se ga bo naložilo. Pri vsakem "dnf upgrade" to postane faktor tveganja.

Pogled pod havbo pokaže, da DTB dejansko naloži U-Boot, ki v nadaljevanju zgodbe zažene EFI zagon, kateremu posreduje naslov naloženega drevesa. Če drevesa ni mogel najti, pa mu posreduje vgrajeno/od_naprave_dostavljeno drevo. Za tukajšnjo razlago naj zadošča, da na RPi to drevo naloži GPU na naslov, ki ga U-Boot pozna, druge naprave pa imajo lahko to rešeno tudi drugače.

Dejanski fragment skripte, ki (posredno) zažene Grub izgleda tako:

if fdt addr ${fdt_addr_r}; then
  bootefi ${kernel_addr_r} ${fdt_addr_r}
else
  bootefi ${kernel_addr_r} ${fdtcontroladdr}
fi

Prevedeno v slovenščino, se glasi tako: preveri DT na naslovu ${fdt_addr_r}. Če tam DT obstaja, potem se kot EFI aplikacijo zažene blob naložen na naslovu ${kernel_addr_r}, posreduje pa se mu DT iz naslova ${fdt_addr_r}. Če DT tam ne obstaja, se zažene isto EFI aplikacijo, vendar z DT-jem na naslovu ${fdtcontroladdr}.

Spremenljivke imajo sicer ta pomen:
${fdt_addr_r}: naslov kamor je U-Boot (morda) naložil DTB za to napravo. V danem primeru se naloži DTB priložen Fedora jedru, ki prihaja iz kernel.org.
${kernel_addr_r}: naslov kamor je U-Boot naložil /EFI/BOOT/BOOTAA64.EFI iz EFI particije. Na Fedori je to shim, ki ve kako ugotoviti kje najti Grub za Fedoro (in še kaj drugega, če je tam in opremeljeno z ustreznim opisom).
${fdtcontroladdr}: Naslov, na katerem U-Boot pri svoji lastni inicializaciji (ker konec koncev mora tudi U-Boot vedeti kakšno strojno opremo ima - MMC, USB, NIC, ...) najde DT za napravo. Na RPi je to DT, ki ga je naložil GPU, preden je predal kontrolo U-Boot, ki deluje na CPU-ju.

Cilj je torej, da se fedorinega (oz. kernel.org) DT-ja ne naloži, temveč se EFI-ju pošlje DT, ki ga je pripravil GPU. Na srečo standardna U-Boot zagonska sekvenca predvideva tudi zagon skripte (/boot.scr) v katero lahko podtaknem, kar je potrebno, da bi to dosegel. Najprej moram preprečiti, da bi U-Boot sploh našel DTB za napravo, za vsak primer pa moram poskrbeti, da če je na ${fdt_addr_r} slučajno že sintaktično pravilen DT (se zgodi, pogled pod havbo U-Boot lahko radovednim pokaže zakaj), da ta ne bo spoznan.

Za ta namen zadošča skripta, ki jo shranim v boot.cmd:

setenv fdtfile nofile.dtb
mw.b ${fdt_addr_r} 0 1

Prva vrstica "pokvari" spremenljivko v kateri je zapisano ime DTB-ja za SoC in, ki ga bo U-Boot poskušal najti in naložiti. Druga vrstica pa pokvari prvi byte DT-ja, ki se bi slučajno že nahajal na naslovu ${fdt_addr_r}. Oboje skupaj zagotovi, da bo bootefi uporabil DT, ki ga je za SoC že pripravil GPU.

Skripto je potrebno še prevesti (kot root):

mkimage -A arm64 -T script -C none -d boot.cmd boot.scr
sudo cp boot.scr /boot/efi/

mkimage je orodje, ki se ga na Fedori najde v paketu uboot-tools (sudo dnf install uboot-tools).

E, voila. Sedaj se lahko v /boot/efi/config.txt po mili volji dodaja razne dtoverlay=... ukaze, kot to lahko počno uporabniki raspbiana. GPU bo config.txt prebral, postoril, kar je potrebno, naflikal stvari v DT in šele potem prepustil nadzor U-Boot na CPU-ju. Temu zaradi sveže dodane /boot/efi/boot.scr skripte ne bo uspelo uporabi fedorinega DTB-ja, kar pomeni, da bo uporabljen "tapravi", ki ga je pripravil GPU. Da bo stvar dejansko delovala je v config.txt verjetno potrebno ohraniti dtoverlay=upstream, kar pa načeloma ni težava. Fedora ta dodatek privzeto že ima.

Zame je fora samo to, da imam neko standardno AArch64 distribucijo, glede na to, da RPi fundacije te stvari ne zanimajo. Stock distribucije (64- in 32- bitne) načeloma delajo b.p., ker gonilniki za strojno opremo obstajajo, kar je ni preveč zaprte (kreh, Broadcom, kreh, VC4, kreh, naj jih koklja brcne, kreh).

Moj žulj je bil samo to, da skoraj vse, kar priključiš na 40-pin konektor ima gonilnike, ne moreš pa jedru enostavno pojasniti kaj je kje priključeno, ker DT overlayi še nimajo izdelanih orodij. No, dokler to delo ne bo zaključeno, bo izgleda potrebno malo popacati U-Boot, da se izkoristi to, kar RPi že ima. Na kakšnem drugem SoC (kreh, Rockchip, kreh, lenobe lene, ki ničesar ne porinejo do konca do kernel.org, kreh, naj vas tudi koklja brcne) sem to moral urediti z malo bolj obsežno skripto.

Na koncu dneva mi je pomembno to, da ima 64 bitkov, ARM in ravno prav nastvljeno logiko, da vem, da me "dnf upgrade" ali "apt-get update/upgrade" ne bosta prisilila, da naokoli vlečem SD kartice. Tudi, če bodo U-Boot spreminjali, ne verjamem, da bodo radikalno spremenili zagonsko sekvenco, ki je bolj ali manj nespremenjena že najmanj 3 leta (morda pa še več, ampak dlje nazaj nisem rabil gledati).

Vsakomur svoje. Na koncu dneva je rezultat tega heca to, da lahko že danes vsakdo, ki si to zaželi, uporablja 64-bitno stock Fedoro in 95% raznih tutorialov na netu, ki se začnejo z "v config.txt dodaj ..."

Ker nimam RPi 4 pri roki, ne vem kakšno je stanje vanilla jedra zanj, ampak s 4 Gib RAM in spodobnih 64-bitnim CPU je pravzaprav greh gor poganjati 32-biten OS.

Za ceno večje porabe RAM dobim nekaj meni pomembnih aplikacij, ki se izvajajo hitreje, ker imam 3x več splošnih registrov (30 na aarch64, 10 na arm) in čisto mimogrede tudi hitrejši context-switch, kar mi pride prav pri moji uporabi.

Kot sem že enkrat napisal: "vsakomur svoje." Kaj komu pomeni "OK" je odvisno od človeka, ne strojne opreme. Čar je predvsem v tem, da imamo izbiro in si lahko izbiramo tisto, kar nam bolj ustreza.

Sedaj ... če bi samo še lahko prepričal clang, da mi ne bo delal miscompile za AArch64.

AndrejO je 1. sep 2019 ob 21:40 izjavil:

Za ceno večje porabe RAM dobim nekaj meni pomembnih aplikacij, ki se izvajajo hitreje, ker imam 3x več splošnih registrov (30 na aarch64, 10 na arm) in čisto mimogrede tudi hitrejši context-switch, kar mi pride prav pri moji uporabi.

Kot sem že enkrat napisal: "vsakomur svoje." Kaj komu pomeni "OK" je odvisno od človeka, ne strojne opreme. Čar je predvsem v tem, da imamo izbiro in si lahko izbiramo tisto, kar nam bolj ustreza.

Sedaj ... če bi samo še lahko prepričal clang, da mi ne bo delal miscompile za AArch64.

absolutno, vsaj moznost izbire official aa64 distrota nebi bla slaba, ceprav vprasanje kdaj ...

Brezplačna Orangepi 4 z RK3399 in AI chipom.

https://twitter.com/orangepixunlong/sta...

https://comstrok.si/namizni-racunalniki...

Ceneje in hitreje. Poglej še na ebay za thincliente. Zastonj so.

seminal je 20. jan 2020 ob 12:59 izjavil:

A obstaja kakšen thin client za pija? Fural bi iz VM tako da če je kakšen za winse, oz ubuntu važno da dela čim bolj tekoče, in da večino "težkega" dela opravi virtualka.

Poglej si rpitc. Drugače pa RPI4 z virt-viewer (SPICE protokol) dela solidno.

Tole vidim da je za winse vse. Je kaj za linux oz ubunto podobnega pa da je free?