Mobil/SBC pro Debian s funkční Wi-Fi

[jauznevimco]

Dobry vecer vespolek,


me hledani vhodneho zarizeni uz proslo radu slepych ulicek a proste se nedokazu dobrat niceho kloudnyho.


Ucel:
Nechavam fotak nekde venku a potrebuju k tomu dalkovy ovladani (hodne dalkovy, VPN pres LTE ... jedno, jestli skrz interni modem, nebo pres USBckovej).
Fotak se zarizenim komunikuje vyhradne pres 2,4 GHz Wi-Fi (max 72 Mbit/s) na velmi kratkou vzdalenost (max 2 metry).
Zarizeni tedy musi mit nejakou moznost, jak k nemu dostat druhej interfejs... at uz USB LTE modem, nebo rovnou podporu pro LTE.
Zarizeni nastavuji na miste, touchscreen se hodi.
Rozumna spotreba, 3 W v idle jsou fakt maximum.


Co vymyslis za blbosti, takovy zarizeni prece davno existuje, jmenuje se smartphone! Si najdi neco, na cem dobre pobezi tucnak!


Ze pry sirokou podporu ma SoC Qualcomm sdm845...

Tak tedy:
Sony Xperia XZ2 Compact s LineageOS
Vse skvele svizne, podarilo se v Termuxu rozbehnout debian pres proot, nainstalovat dependencies, rychle to odsejpa, super... a to je konec.
Zatimco mi tohle nejak mizerne fungovalo na prehistorickym Android 7 telefonu, na Androidu novejsim uz ne.
Novej Android uz nepusti aplikaci z prootu primo k Wi-Fi, takze konecna... (jop, nestaci jen obycejna TCP konektivita, z nejakyho duvodu aplikace chce sahat primo po adapterech).

Port postmarketOS existoval jen experimentalne a je to cesta proslapana vlastne jen jednim clovekem pred radou let.
Z Androidu cesta nevede vubec a jiny Linux-based OS pro tenhle telefon zrejme vubec neexistuje.



OnePlus 6T s Mobian bookworm
+ podarilo se vse rozbehat, beha to hezky svizne
+ ma to touch a vyhody s tim spojene
+ je to celkem normalni Debian
- Wi-Fi hapruje. Moc. Nejdele to spojeni s fotakem udrzelo sotva 6 hodin, bezne se to dokaze rozsypat klidne i po hodine, hruza. Nepodarilo se mi k temto chybam dohledat nic relevantniho:

Kód: [Vybrat]

ath10k_snoc 18800000.wifi: failed to install key for vdev 0 peer <MAC_adresa>: -110
wlan0: failed to remove key (2, ff:ff:ff:ff:ff:ff) from hardware (-110)
- workaround za pouziti USBckove Wi-Fi neni mozny; protoze USB OTG v Mobianu bookworm vubec nefunguje
? nejak se mi nedari vypnout randomizaci MAC adresy, ale v profilu pro pripojeni je dano permanent, tak snad to respektuje... pravdepodobne tedy nesouvisi
- Wi-Fi na bookwormu nikdo neopravi, vyvoj se soustredi na Debian Trixie, kteryzto nelze pouzit (dependency hell vedouci k bricknuti zarizeni)... na bastrl typu jadro z Trixie a userspace z Debianu si netroufnu, na to nemam znalosti a ani nevim, jestli je neco takovyho vubec mozny.

Cili uz jsem tam skoro byl, ale nakonec je to vlastne plny neresitelnych problemu.


OnePlus 6T s Ubuntu Touch:
+ Ocekavani velika, ma to stavet vlastne na jakoze puvodnim Android 9, takze by treba Wi-Fi nemusela byt zmrsena...
- S Ubuntu ma spolecnej tak leda nazev, z pohledu klacku pod nohy userovi nahazenych je to snad horsi jak iOS. Defaultne read-only root filesystem, oficialni permanentni workaround na to nefunguje; docasny reseni jako remount / jako RW sice jakoze funguje, ale zas na tom oddilu nenechali zadny volny misto...
"Do rootfs vubec nesahejte, pouzivejte kontejnery!"
Smysl tohodle systemu naprosto nechapu, zcela nevhodne pro me pouziti.


OnePlus 6T s postmarketOS:
Jdu prubnout ted. Zelezo se tvari se to celkem podporovane, jak to bude vypadat v praxi je otazka, asi bude spousta srandy s pokusy tam vecpat vsechny dependencies, kdo vi, jestli pro AlpineLinux vubec existuji. Achjo.


OnePlus 6T s Winblows 10 ARM
Fakt to existuje; postup jsem nezkousel... https://github.com/n00b69/woa-op6
A pod woknama pustit x86 verzi v emulaci... treba tam bude Wi-Fi drzet?
Nicmene to uz jsme fakt ve sfere totalniho bizaru a hledani proof of concept neceho, co by prece melo fungovat uplne fpoho na jakymkoliv normalnim zeleze...



Zda se, ze vice nejakych zazracnych variaci na Linux na tom asi nejnadejnejsim telefonu nerozbehnu.
Znalosti na kompilaci vlastniho jadra s tim ci onym spravnym firmwarem a ovladacem nemam, tak nezbyva, nez koukat po nejakym jinym zeleze...


Oldie but goodie:
Raspberry Pi Zero 2W s Raspberry Pi OS bookworm x64
- pomalyyyy (holt, jen 400 MB dostupne RAM)
- nema touchscreen, nastaveni pres VNC je mozne, ale otrava (VNC neni touch-friendly, aplikace touch ocekava, lovit miniaturni posuvniky prstem je fakt otrava)
- navzdory ocekavani nestabilni onboard Wi-Fi (relativne mene casto to hapruje pri pouziti se starsi verzi Raspberry Pi OS); https://github.com/raspberrypi/linux/issues/5770 --- z Raspberry tvrdi, ze za chyby na urovni mmc/sdio muze vetsinove napajeni, to ale neni muj pripad, mam to promereno...
- chybi RTC... rucni nastavovani data/casu po kazdym startu je fakt otrava, ne vsude je k dispozici sit pro NTP
+ s tim starsim jadrem se spojeni udrzi treba 12-14 hodin, coz jakztakz jde a je to vlastne nejlepsi dosazeny vysledek
? vyse zmineny problem s Wi-Fi muze byt resitelny USB hubem a nejakou "known good" USB Wi-Fi?


Potencialni kandidat zajimavyho zeleza:
Radxa Zero 3W
https://radxa.com/products/zeros/zero3w/#techspec
+ dostatek RAMeti, eMMC, nebude to tak liny, jako puvodni RPi Zero 2W
- vsechna ostatni negativa RPi pretrvavaji (chybejici RTC, touchscreen)
- Wi-Fi je loterie... opet pripojeno pres mmc/sdio, budto Broadcom AP6212, nebo AIC8800... pricemz vim, ze AIC8800 je strasnej kram se zmrsenym SW nejen pro Linux, nybrz i pro Winblows (ktery je schopnej sestrelit komplet do modra)
cili stejne asi budu muset pouzit USBckovej hub pro Wi-Fi (k fotaku) a USBckovej modem (pro LTE konektivitu)



Existuji nejake dalsi alternativy (at uz zelezo, nebo OS), ktere by staly za zminku?
Neco, k cemu by sel pripadne nejak pribastlit rozumne velkej dotykovej displej (tak do velikosti toho mobilu)?



Diky za napady.

[Reklama]

[redustin]

Je opravdu debian nezbytný, nestačil by android a napsat si k tomu vhodnou appku? Také jsem (na průmyslových tabletech s hodně specifickými požadavky na HW) řešil debian a androidí appka v kioskovém režimu, nahrávaná přes adb (tablet nemá připojení k netu) se ukázala jako jediné schůdné řešení. Všechen HW bych na těch pár vyhovujících tabletech bez androidího kernelu/supportu nikdy nerozchodil... Ale dělám v javě, takže s vlastním programováním nebyl žádný problém. Největší matlání bylo s API androidu a jeho "bezpečnostními" prvky.

[Exceptions]

mnoho let ke spokojenosti na podobné věci používám mobil jolla, je tam linux, usb, mohu použít seriový port, přidat kernel moduly, spotřeba jako běžný telefon.

Viděl jsem myslím OnePlus 6T s https://postmarketos.org a mám dojem, že na stabilitu wifi si dotyčný nestěžoval.

Ono takových zařízení je docela dost, ale omezení na touch screen a spotřebu pár watů to dost omezuje, stejně tak není jasné jaký SW tam vlastně pro komunikaci s foťákem spouštíš.

[jauznevimco]

Je opravdu debian nezbytný, nestačil by android a napsat si k tomu vhodnou appku?

Cozpak o to, appka pro Android existuje a vicemene neni duvod, proc by nemela fungovat aspon v rezimu "naprogramovani predem". Zadrhel je prave ten vzdalenej pristup pres cellular...


Fotak dela APcko a posila z DHCP nejakou adresu 192.168.122.x/24; dale posila 192.168.122.1 (svoji IP) jako gateway... (coz je samozrejme blbost, protoze ta defaultni routa nema kam jit)

Vysvetli Androidu, ze tuhle routu nema pouzivat a ma jako defaultni gateway pouzivat jen a pouze mobilni sit... :/

Pri rucnim nastaveni adres snad nebylo mozny ulozit nastaveni site bez defaultni gateway (? -- nejsem si jistej, je to uz cca rok, co jsem to zkousel).

Kdyz uz jsem to chtel nejak osolichat pres "route", tak tam si to vsechno zilo svym zivotem v ruznych namespacech. Aby to vubec nejak fungovalo, musel jsem psat nejakej divne dlouhej prikaz pro import vseho z namespacu do te hlavni routovaci tabulky a pak to teprve zacalo delat, co ma.
S Androidem se moc nekamaradim, mozna tam na to nejakej postup pro automatizaci je, ale prekazek spousta a je to fluidni dle verze (takze ani nevim, jestli by to tedka na novejsim telefonu fungovalo).

mnoho let ke spokojenosti na podobné věci používám mobil jolla, je tam linux, usb, mohu použít seriový port, přidat kernel moduly, spotřeba jako běžný telefon.

Hmm, takze se obloukem vracime k SailfishOS, kterej tady uz par lidi vychvalovalo... saaafra. Tak ze bych pro zacatek zkusil sehnat nejakou podporovanou Xperii a prubnul to? Asi lepsi varianta, nez za to vysypat 300 ecek a pak se divit :-) 
Diky za info, omrknu, co se kde nabizi, at to muzu aspon prubnout.

Viděl jsem myslím OnePlus 6T s https://postmarketos.org a mám dojem, že na stabilitu wifi si dotyčný nestěžoval.

To jsem zkousel vcera a vubec to nedopadlo, Wi-Fi se tam chova zdaleka nejhur. Na 5 GHz bez ruseni latence lita vysoko pres vterinu, prumer ve stovkach ms, i pouhe psani do sshcka a oprava preklepu byla neprijemna.

K samotnymu testu s fotakem ani nedoslo...
pmOS je AlpineLinux, s nimz jsem nemel zadne zkusenosti. Takze nastalo ohromne diveni, ze on tam neni ani zadny glibc, takze nejaky peklo stran dependencies mne dohnalo hned na zacatku. Tudy cesta nepovede.

Ono takových zařízení je docela dost, ale omezení na touch screen a spotřebu pár watů to dost omezuje, stejně tak není jasné jaký SW tam vlastně pro komunikaci s foťákem spouštíš.

qDslrDashboard, snazim se to rozbehnout tedy s buildem urcenym puvodne jakoze pro Raspberry Pi x64 (neni verejny). Proto ta fixace na debian, v nem ty vsechny potrebny dependencies jsou.

Ten touch samotnej neni uplne tvrdej pozadavek, ale bodlo by to.


Ja zatim omrknul varianty dotykovych obrazovek pro nejakou tu malinu/Radxu (kde jsem uz i zjistil, ze Wi-Fi se uz dava patrne jen broadcom + podpora primo v jejich OS distru.. takze mozna by to slo).

[kuba77]

SailfishOS funguje zrovna i na té Xperii XZ2 Compact i Oneplus 6T, jen nejde o oficiálně podporované zařízení od Jolly, takže bez té jejich vrstvy pro Android appky, ale měl by na nich jít použít Waydroid.

[Reklama]

[redustin]

Vysvetli Androidu, ze tuhle routu nema pouzivat a ma jako defaultni gateway pouzivat jen a pouze mobilni sit... :/

Rootnutý android by IMO neměl být v tomhle problém, ne? Chápu nerootnutý (můj případ), tam je všechno low-level boj a spoustu věcí nejde, ale v rootnutém androidu by mělo jít téměř vše jako v linuxu. Divil bych se, kdyby měl androidí kernel jiné síťování, aby mu nešela nastavit defaultní gateway nebo ignorování konkrétních nastavení posílaných DHCP serverem.

[okias]

postmarketOS na OnePlus 6/6T by měl být nejlépe podporovaná volba. WiFi mě funguje stabilně, tak snad to bude stejně v tvém případě

[jauznevimco]

SailfishOS funguje zrovna i na té Xperii XZ2 Compact i Oneplus 6T, jen nejde o oficiálně podporované zařízení od Jolly, takže bez té jejich vrstvy pro Android appky, ale měl by na nich jít použít Waydroid.

Tak nevim, asi jsem vemeno, ale zatimco na OnePlus 6T mi probehne pres MsmDownloadTool aspon factory reset Android 9, ale chcipne mi hned pokus tam nacpat LineageOS16 stahlej primo z navodu.
Nacez to dospelo do stavu, ze uz ani z fastbootu nenabehnu do TWRP, bez ohledu na probehnuvsi obnovu do tovarniho nastaveni. Proste to zustane viset. By si jeden myslel, ze pri bootu z fastboot primo do TWRP nebude zalezet na obsahu kdejakych ruznych Androidich partitions, ale evidentne teda zalezi, protoze se to podelalo po experimentech s postmarketOS.

Navic ten MsmDownloadTool, kterej provadi obnovu do tovarniho nastaveni, neobnovuje uplne vsechno, ale jenom oddil A ... Bcko je schopnej nechat spatnej a nikterak mu to nevadi.



Na Sony to jde mnohem lip, po tydnu snazeni se mi tam konecne aspon podarilo vecpat stock firmware... tak snad tu pochodim trosku lip.

Vrstva pro Android appky mne nikterak netrapi... (joo, jiny by to bylo, pokud by tahle vrstva umela pristup k Bluetooth, to by mne pak zajimalo naramne, avsak pro trochu jiny ucel mimo toto vlakno).

Rootnutý android by IMO neměl být v tomhle problém, ne? Chápu nerootnutý (můj případ), tam je všechno low-level boj a spoustu věcí nejde, ale v rootnutém androidu by mělo jít téměř vše jako v linuxu. Divil bych se, kdyby měl androidí kernel jiné síťování, aby mu nešela nastavit defaultní gateway nebo ignorování konkrétních nastavení posílaných DHCP serverem.

Omrknul jsem svy starsi poznamky...
For byl v tom, ze Android zvesela ignoruje, co je nastaveny v hlavni routovaci tabulce, protoze ma svych routovacich tabulek bambilion a reseni je v tomhle snadno zapamatovatelnym prikazu, kterej musis pustit po pichnuti se na Wi-Fi:

ip rule add from all lookup main pref 1

Neprisel jsem na to, jak tohle v Androidu, ne tak jeste rootnutym, zautomatizovat.
Mozna to resitelne je, treba i snadno... ale Android a jeho specialitky a rozdily mezi verzema neznam a nemam kapacity na to se tim zaobirat, takze to neni moje volba c.1.

postmarketOS na OnePlus 6/6T by měl být nejlépe podporovaná volba. WiFi mě funguje stabilně, tak snad to bude stejně v tvém případě

O sve zkusenosti s pmOS jsem uz psal o nejakej post vejs, Wi-Fi tam byla ze vsech zkousenych OS bezkonkurencne nejhorsi i na domacim petigigu. Navic se tento system ukazal pro moje pouziti jako zcela nevhodny a termin "dependency hell" dostal zcela nove rozmery, protoze nepouziva ani glibc...

[jauznevimco]

Tak se Sailfishem jsem taky prilis nepochodil, opet kvuli dependency hell. Jakmile se musi sahat na glibc, je zrejme, ze tudy cesta nepovede. 



Dumam, kudy dal. Test z Mobian Trixie (posledni weekly image)... fajn, aplikaci tam nerozbehnu, ale pingat mi to vydrzi bez problemu treba 15 hodin, bez jedinyho ztracenyho paketu.

Tak si rikam okej, tady by kernel a firmware mohl byt pouzitelnej...


A jal jsem se delat nejakou uberprasarnu...
kernel 6.12-qcom z mobian trixie (pod trixie dokazalo jadro odnekud korektne vycist MACovku Wi-Fi a byla staticka)
rootfs z mobian bookworm (kteryzto byl dodavan s kernelem 6.1; tohle jadro mi vzdycky vyplivlo v dmesg hlasku, ze nelze zjistit MACovku Wi-Fi a generuji si nahodnou... https://gitlab.com/msm8998-mainline/linux/-/issues/21 )

... prendat /lib/firmware a /lib/modules z rootfs trixie do rootfs bookwormu + zmenit UUID rootfs, aby odpovidalo UUID, ktery ma trixie...

Super, dokazalo to nabootovat a jakztakz i fungovat.
Jenze:
1) pri prvnim bootu po flashi to Wi-Fi vubec nevidelo a nedokazalo nacist moduly
2) po rebootu to najednou dokazalo moduly nacist a vse fungovalo
ale 3) Wi-Fi s jadrem z trixie, co s trixie userspace umelo vycist MACovku patrne z /persist partition, ji najednou zas vycist neumi a je random po kazdym bootu?!
4) kleklo to po cca sedmi hodinach tak jako tak.


Tak jsem zmatenej... Moduly pro starej kernel 6.1, jakoz i stary firmwary, jsem dal komplet fuc a furt nic. Delam neco na prvni pohled spatne (krom toho, ze takovy prasarny by se delat nemely :-) )?

Znalosti na pousteni se do buildeni svyho vlastniho mainline kernelu a device tree nemam...

Nakolik uz jsem fakt v koncich, zacinam byt vice naklonenej variante zkusit ten SBC od Radxa/OKDO... toto se neda. :/

[k3dAR]

naprosto obecne, kdyz menis jadro, pokud se pouziva initramfs, tak muze byt potreba ho pregenerovat, obzvlast pokud bys puvodni initramfs k danemu jadru pretahl z jineho rootfs...
nevim jak v tom tel, ale v desktopu (*buntu, Debian):

Kód: [Vybrat]

# pro aktualne bezici jadro
update-initramfs -u
# pro vsechny jadra
update-initramfs -u -k all
# pro konkretni jadro
update-initramfs -u -k 6.11.0-26-generic


[Sox37]

Nebylo by možné použít nějaký funkční base systém (např. ten Ubuntu Touch, PostmarketOS atd.) a pak v něm v kontejneru rozjet ten Debian Bookworm (nebo něco nejbližšího tomu RPI)? Tím by se vyřešily problémy s glibc a userspace. Podle mě by u všech runtime měl jít network stack sdílet s hostem. Na kontejnery se dá použít např. chroot, systemd-nspawn, crun nebo lxc.

[František Ryšánek]

Opožděně zareaguji na původní dotaz: co tak pozoruji, hodilo by se něco třeba se 2 CPU jádry na co nejjemnější litografii, plus požadovaná bezdrátová výbava, optimalizováno na co nejnižší příkon, zároveň co nejvíc otevřené, s dostupnými ovladači...

Nemám :-)

Jemná litografie, důraz na spotřebu a úsporná rádia - toto vše se vyskytuje v telefonním světě, který ale není svobodný. Navíc i ten důraz na spotřebu kulminoval někdy začátkem století ještě před nástupem matlání (výdrž na baterku měsíc apod.) - Androidové founy nikdy tak důsledné se spotřebou nebyly, designové kritérium zdá se být spíš "stačí když to vydrží na jedno nabití asi den, hlavně ať to má aspoň 8 CPU jader a OpenGL".

Takže zatímco mobilní matlafouny míří někam ke 5 ... 4 ... 3 nm (údajným nanometrům), na průmyslových boardech jako nejskromnější vidím několik posledních generací DMP Vortex86 (už nevím jestli končí na 40 nm, nebo třeba 28 nm, tuším UMC) a z holdingu DMP výrobce desek ICOP si přilepšuje i.MX8 od NXP. Pokud se týče spotřeby, tak úspornější varianty Vortex86 boardů berou něco jako 3W (bez wifi, bez LTE a bez displeje), i.MX8 je tuším zhruba o 1 Watt níž a možná se do toho vešla i wifi... Boardy a počítače s i.MX8 vidím v "průmyslu" i u dalších výrobců - spotřeba bude podle mého podobná. Není to určeno na micropower přežívání někde z baterky, jsou to spíš "relativně levné" a příkonově úsporné počítače na nějaké to nenáročné HMI, s trvalým napájením ze sítě.

Mrkněte třeba na tenhle board:
https://www.icop.com.tw/datas/upload/files/Product/SBC/NX8MM-35/NX8MM-D168%20carrier%20boardBLOCK%20DIAGRAM2024.jpg
https://www.icop.com.tw/product/NX8MM-35#!
Má to onboard jakousi wifinu (model jsem nezkoumal) a do MiniPCI-e slotu se SIM paticí by se dal strčit LTE modem. Viděl jsem tuším modely LTE kartiček prodávané jmenovitě pro "IoT" nasazení = relativně pomalé a snad i optimalizované na příkon.

Ve světě x86 je jako nejúspornější od DMP určen patrně Vortex86EX, případně EX2. Viz třeba tenhle board:
https://www.icop.com.tw/product/VEX-6225
Onboard žádné rádio, spotřeba něco jako 3W. Dva sloty MiniPCI.e, asi by se dala osadit požadovaná rádia. Problém je, že každé rádio si za jízdy vezme hravě 1W, pokud ne víc.

Požadované 2-3W mají být průměrná spotřeba, nebo nepřekročitelná obálka? Wifi rádio musí být neustále ready, nebo by se dalo nějak utlumovat/vypínat? Pokud neustále ready, třeba by se dal omezit na tu krátkou vzdálenost vysílaný výkon a taky rychlost.

Intelův ATOM je dodnes úsporný spíš naoko. Takový Alder Lake N, v "booksize" počítači s pasivním chlazením, umí topit tak, že na žebrech sotva udržíte ruku. Pokud mohu soudit, úspornější bratranec Quark je prakticky mrtev - vypadá to na experiment, který skončil jako slepá vývojová větev.

[redustin]

Pokud to dobře chápu, pro úspěšné vyřešení problému je potřeba ultra-low-power (tj. kvalitní drivery všech komponent s implementovanou podporou jejich power saving režimů) zařízení schopné běžet na baterie, které má současně dobrou podporu wifi a mobilních dat. K tomu je potřeba custom software pro přenos ovládání toho foťáku někam do internetu.

První požadavek splňuje každý moderní androidí mobil od rozumného výrobce (aby měl stabilní wifi atd.), napájení posílené třeba nejaký fotovoltaickým dobíječem. Žádné jiné cenově rozumné řešení neznám, linuxové desky mají buď dobrou podporu v linuxu, nebo jsou úsporné (tj. opravdu moderní čipy, ne RPi-style = téměř vždy vendor kernel bez kvalitní podpory v mailnline, obrovský problém nainstalovat běžný linux atd.).

A k tomu bude vždy potřeba custom software. Tudíž buď mohu napsat něco pro debian, nebo mohu napsat androidí aplikaci. Z android studia (kde lze appka snadno testovat v debuggeru) ji přes USB kabel nahrát do mobilu + příp. jí ručně přes adb  povolit režim device owner (aby měla přístup k potřebnému HW). Appku rovnou psát s ohledem na power saving -  např. https://developer.android.com/develop/background-work/background-tasks/awake , řídit si vypínání displeje atd.

IMO by cesta standardní (tj. skvělý poměr cena/parametry) HW (bez boje) + custom SW (boj 1) vytvořený ve frameworku specializovaném na bateriová zařízení vedla k požadovanému cíli (vzdálené ovládání toho foťáku v přírodě) rychleji a spolehlivěji, než custom HW (boj 1) a custom SW (boj 2).

[k3dAR]

[...] Boardy a počítače s i.MX8 vidím v "průmyslu" i u dalších výrobců [...]

sice by se mu to "trochu" prodrazilo, ale s i.MX8 je linuxovej telefon Librem 5 ;-)

[jauznevimco]

naprosto obecne, kdyz menis jadro, pokud se pouziva initramfs, tak muze byt potreba ho pregenerovat, obzvlast pokud bys puvodni initramfs k danemu jadru pretahl z jineho rootfs...
nevim jak v tom tel, ale v desktopu (*buntu, Debian):

Kód: [Vybrat]

# pro aktualne bezici jadro
update-initramfs -u
# pro vsechny jadra
update-initramfs -u -k all
# pro konkretni jadro
update-initramfs -u -k 6.11.0-26-generic


Oprava a omluva, nevyjadril jsem se presne, co jsem udelal.

Ja jsem pouzil celou

Kód: [Vybrat]

/boot partition z trixie a rootfs z bookworm, pricemz initrd byl umisten rovnez v ramci te /boot partition.
Do obsahu /boot jsem vubec nezasahoval, to jsem jenom pres abootimg rozbalil ke cteni, abych z boot configu dokazal vytahnout cmdline pro zjisteni, jake je to spravne UUID pro rootfs.

Ja tedy zasahoval jen do rootfs, abych z trixie presypal /lib/firmware a /lib/modules + zmenil jeji UUID, aby z nej slo nabootovat. 

Požadované 2-3W mají být průměrná spotřeba, nebo nepřekročitelná obálka? Wifi rádio musí být neustále ready, nebo by se dalo nějak utlumovat/vypínat? Pokud neustále ready, třeba by se dal omezit na tu krátkou vzdálenost vysílaný výkon a taky rychlost.

Celej for je zhruba v tom, ze aplikace ma mj. intervalometr (nebo fotak cvaka intervalometrem externi, neni prilis podstatne).
Typicky si aplikace/telefon 20 vterin spokojene idluje, sepne intervalometr, do aplikace pristane JPEG nahled fotky (snad do 2 Mpix rozliseni), aplikace vyjede nejaky info (EXIF, histogram, spocita nejakou umelou hodnotu Luminance) a pripadne upravi nastaveni fotaku (na tohle vsechno mam experimentalne urcenou hranici trech vterin).

Tedy naprostou vetsinu casu si to idluje, ale kdyz prijde prace, melo by ji to stihnout behem tech 3 vterin, nez zase sepne intervalometr (jasne, interval se da treba o vterinu prodlouzit, ale radsi ne). Raspberry Pi Zero 2W (4 jadra A53 na 1 GHz) tenhle provoz zvlada celkem obstojne, jen narazi na limit RAMeti.


U spotreby se jedna o spotrebu prumernou. Rekneme tech 5 W jako prumer je rozumny maximum, ktery bych byl schopnej ze stavajicich baterek uzivit. Uz takhle taham baterek skoro tri kila, celej technickej kramek vazi neco kolem 14, k tomu nejake pochutiny, tekutiny a clovek je rad, ze je rad


Pro predstavu, ten OnePlus 6T i se zapnutym displejem na nizkem jasu si idluje se spotrebou kolem 0,5 W, s plnym jasem nejakych 1,6 W; spicky v zatezi litaji sotva nekam k tem 3 W.


Apropo, kde se tyhle prumyslovy veci kupuji? Vsude vidim akorat "cena na dotaz", patrne zamysleny opravdu jen pro prumysl s odberem poctu v radu stovek kusu minimalne?

A k tomu bude vždy potřeba custom software.

Kdyz si vezmu, ze jsem coby BFU/hobbik chtel jenom adaptovat neco, co uz davno pouzivam, na jiny zelezo... kolikrat jsem neco takovyho delal, kdo by cekal takovy zadrhele, ze? :-)
Vyvoj vlastniho SW fakt nehrozi - potrebuju to pouzivat idealne uz vcera :-) je tolikych mist, na nez chce narodni park od pristiho roku zakazat vstup, ze beztak nebude mozne stihnout tvorbu ani jen na vsech vytipovanych mistech...


---

Nu, kvuli nejakym dalsim pokusum jsem se zas na cas odmlcel. Zda se, ze tentokrat se uz i k necemu, co dava smysl, konecne dostavam.

Delal jsem test s Mobianem, rootfs bookworm, /boot trixie, na onom OnePlus 6T.


Test c. 1:
aplikace bezi + na pozadi pingam fotak
Poznatky:
1) Spojeni s aplikaci se po par hodkach zase rozpadlo (vicemene ocekavane).
2) Ping ukazal, ze tam byl nejakej kratkej packetloss, ale podle logu nedoslo k rozpadu Wi-Fi spojeni a k reconnectu.
3) Vnitrni intervalometr v aplikaci si zil dost svym zivotem; interval mel byt 23 vterin, nekdy to odpalilo za 18 vterin, nekdy za 25...
To je strasne velkej rozptyl bez ohledu na to, k jake prodleve muze dochazet na Wi-Fi; i to Raspberry Pi dokazalo interval drzet vyrazne presneji.

Tak dumam, co se to deje, ze se spojeni z aplikace rozpadlo, kdyz je Wi-Fi porad associated a ping furt leze?!


Test c.2:
aplikace + na pozadi ping + pres tcpdump si ulozim vsecho do souboru
Vysledek:
1) Intervalometr vyrazne presnejsi
2) Ztraceno <10 paketu pingu, neni problem
3) Spojeni s aplikaci se ani za 21 hodin nerozpadlo! Pak jsem to vypnul, at uplne nevystavim powerbanku fotaku.
Takze vystup z tcpdump jsem ani neprochazel, protoze problem nenastal.


Podeziram, ze by v tom mel prsty nejakej prilis agresivni power-saving (asi spis CPU/celyho SoC, nez jen Wi-Fi, nakolik pravidelny pingani bez dalsi aktivity rozpadu spojeni nepredeslo), nakolik je aplikace vzdycky cca 20 vterin idle a 3 vteriny se neco deje...
Ze by tcpdump zapisujici kazdej paket (vcetne ICMP pingu kazdou vterinu) generuje dostatecnou zatez na to, aby power-saving nenakopl?

Elementarni power-saving ficury jako auto-suspend po case neaktivity (v GNOME GUI) mam samozrejme vypnute, ale zrejme si tam jeste neco dalsiho zije svym zivotem...


Aspon uz mam nejakou jakztakz smysluplnou hypotezu, kterou zkusim dneska overit znovu + pripadne nakopnuti, kterym smerem koukat dal...