( SPYFF | 2025. 08. 12., k – 08:42 )

Örülök ez jól esett! Nagyon régóta szerettem volna ezt a posztot megírni és "lezárni" a kísérletezést és használni a routert. Amit itt nem részletezek, az a szívás része. Ez nem a router hibája, nekem kellett sokat tanulnom. Csak ízelítőnek leírok párat.

* Elkövettem azt a hibát, hogy valami telefon mellé adott Type-C kábellel próbáltam eleinte a routert. Egy Type-C port van, ezen kapja a tápot és itt van a CH340 UART modem is. Random fagyások voltak 3-5 perc után "megmagyarázhatatlan" okból. Persze a magyarázat egyszerű volt, a kábel volt silány, beszereztem egy kicsit minőségibb kábelt (AlzaPower, 0.5M 100W) és így simán meg lehet táplálni PC-ről.

* Ha már soros konzol, eleinte szívtam azzal, hogy "lekésem" a bootmenüt, mert bekapcsolásig nincs /dev/ttyUSB0 eszköz. Picocom/minicom-ot mindig rögtön az után kellett indítanom, hogy csatlakoztattam a routert ez elég idegesítő volt. A megoldás csak annyi, hogy egy tio nevű toolra váltottam, talán itt hup-on futottam bele. Ez figyeli a fájlrendszert és egyből csatlakozik az eszközre, amint az feltűnik.

* Egy idő után elvesztettem a konzol kimenetet. Ez viszonylag egyszerű volt, u-bootban meg kellett adni kernel argumentumként a serial tty nevét és memóriacímét. Ezt később el lehetett hagyni, mert u-boot EFI boottal ezt jól passzolta tovább GRUB-nak ami pedig a kernelnek.

* Eleinte próbáltam megkerülni a GRUB-ot: úgy betölteni az installert, hogy DTB+kernel+initramfs. Sajnos ezzel az a gond, hogy az u-boot által megkövetelt initramfs formáum eltér attól amit a GRUB próbál betölteni. Úgy sikerült, sikerült csak, hogy memóriába betöltöttem az initramfs-t, de u-boot booti parancsának nem adtam meg csak kernel argumentumként (initrd=${ramdsk_addr_r}). Ezzel sem jutottam sokra, az initig nem jutott el a dolog... Nem tudta kitömöríteni a tömörített initramfs-t sajnos ezzel nem tudtam mit kezdeni, GRUB-al viszont ment.

* Az a "pazar" ötletem támadt, hogy u-boot egyből NVMe-ről töltse be a kernelt. Erre jó pár hétvégém ráment, tök feleslegesen. Nem volt zsákutca, sikerült összehozni de akkora efforttal, amennyit nem ért ahhoz képest, hogy egy filléres pendrive-ra rakom a /boot partíciót. Ugyanis sem OpenWRT, sem mainline u-boot nem tud PCIe-t R3 minin. Levlistán bár ott egy éve az RFC patch, nem került be azóta sem. Fejlesztő (Frank Wunderlich) githubján ott a fork, CI buildeli is, de az meg EFI bootot meg EXT4 fájlrendszert nem tud... :-) Forkoltam tehát a forkot, buildconfigban engedélyeztem az EFI bootot, de hogy az OpenWRT u-bootot ne piszkáljam, azt csináltam, hogy chainloadoltam azzal a forkolt, PCIe supportos u-bootot, ami meg betöltötte a GRUB-ot NVMe-ről ami a kernelt. Sok hűhó semmiért, ráadásul ez elég gáz is, hogy a stock OpenWRT u-boo mellé még kell egy másik is...

* Amiről végül PR-t is nyitottam Debian kernelhez, az a clock driverek hiánya. A clock driver modulok az initramdisk-en voltak, amit képtelen volt kicsomagolni, mert bizonyos clock driverek hányoztak... :-) Fordítottam egy saját kernelt, azonos konfiggal mint az installer, azt leszámítva hogy az összes MT7986 clock drivert builtinre állítottam (=y). Így betöltött, de nem akartam eltérni a stock-tól. Ami működött végül, az az volt, hogy megnéztem Mediatek alapú Chromebookoknál mit csinál az Ubuntu installere. Feltűnt, hogy a GRUB-ban bizonys notebookokra külön menuentry van, ebből lestem ki a clk_ignore_unused kernel argumentumot. Ezt beírva a telepítő GRUB menuentry-jébe eljutott az init-be, ahonnan már be tudta tölteni a clock drivereket. Sejtelmem sincs, mi és hogyan javította meg ezt Trixie-re, RC1-ben még ez az argumentum kellett. Buildconfigban nem találom nyomát =y-nak, továbbra is modulként fordul minden. Szerintem berakták az installer initramdiskjébe ezeket a modulokat is, a telepítés utáni /etc/initramfs-tools/initramfs.conf-t nem csekkoltam.