Vlákno názorů k článku Staré X11 desktopy přes XWayland, možná první notebook s RISC-V od Martin Vancl - Jak to vlastně bude u RISC-V? Bude tam...
-
Existuji i ARM platformy s ACPI/UEFI - typicky to jsou serverove reseni (Cavium, Qualcomm, AMD).
Pro embedded se bezne pouziva DeviceTree, protoze neni treba dynamicke konfigurace platformy. Bohuzel ARM hracky jsou vznikle z teto oblasti trhu, takze proto to je takove, jake je.
Prakticky vam ale postaci vymenit zkompilovany DT, pokud je distro postaveno rozumne a procesory jsou stejneho druhu (coz u ARM neplati.. neni jenom jeden ARM a rozsireni jsou omnoho ruznorodejsi nez u x86, kde se nedavno taky uz nektere distra rozloucili s podporou starsich cpu).
-
V praxi to distra řeší tak, že mají distribuční kernel se všemi moduly, v /boot mají zkompilované všechny Device Trees, a U-Boot skriptem detekuje na čem jede a podle toho předá kernelu příslušný DT blob. Takže třeba Manjaro ARM má jen jeden image, ale funguje to na několika desítkách podporovaných Aarch64 desek.
-
Samozrejme, že Linuxový kernel vie rozumne modulárne načítať ovládače, na platformách ako x86-64 alebo aj aarch64 presne to robí.
Vtip je v tom, že na SBC a ďalších platformách, ktoré vyžadujú DT nemá ako zdetekovať prítomnosť hardvéru, pre ktorý by mal tie ovládače načítať. Použité zbernice nepodporujú plug-and-play, jeden blbý poke a celá platforma môže vytuhnúť až do resetu.
Preto je tam DT, ktoré popisuje, aký hardvér je k dispozicií a ako ho adresovať.
Riešenie je buď podporovať enumeráciu hardvéru, alebo mať nejaké runtime služby ako sú UEFI, ktoré jadru dajú vedieť, čo je k dispozícii. DT je riešenie z pozície toho, čo bolo v možnostiach autorov jadra.
-
Hodně těch SBC má DTB ve flashi (pár Mb SPI), ale nikdo to dobrovolně nepoužije, protože je to X generací zastaralý. Linux se hýbe hodně rychle a i pro svoje relativně primitivní výrobky (SoC, jedna LPDDR4, hromada I2C a podobných low-tech periferií) musím DTS syntaxi upravovat pomalu pro každou minor verzi Linuxu. DTB v desce která pamatuje Linux 4.x je nepoužitelnej, takže si distra nesou svoje a skript v u-bootu jen podle pár konstant v SPI určí, v čem je a co načíst.
Je to vlastně obdoba zmršených ACPI tabulek v noteboocích. Windows si taky nosí svoje opravený pro každej model notebooku s sebou a proto např. na tolika laptopech zlobí v Linuxu suspend: protože Linux nemá přibalený ty novější tabulky a tak použije ty nefunkční co jsou v "BIOSu".
4. 7. 2022, 17:38 editováno autorem komentáře
-
To s tou modularitou byla spis recnicka otazka narazejici na "Manjaro ARM má jen jeden image, ale funguje to na několika desítkách podporovaných Aarch64 desek". Jestli ma opravdu jeden image a tahne sebou pokazde v RAM vsechno, tak potes koste.
Moje takova idealni predstava by byla, aby bootloader nebo cokoliv z devicetree nacetl co potrebuje k mountu root filesystemu, nahral to z pametoveho zarizeni spolu s kernelem (ktery v sobe nebude obsahovat vlastne skoro zadne ovladace), a kernel by si nacetl zbytek.
-
Netaha to v RAM, ty DT binarky jsou asi soucasti /boot stromu.
Ad "ideal" - vzdyt to tak i funguje - mas na desce bootloader (v spi nebo emmc), ktery ma svoje DT, jak to nabehne tak si to namounti z eMMC neco kde je /boot a vybere si kernel+initrd+DT, pripadne DT se vezme z nejake dedikovane partisny.
Co je nestandardni na tech deskach je i samotny bootloader - to neni jako v biosu, ze to nacte konec prvniho sektoru a jede se :) spis ten uboot pripomina grub2, ze jakmile rozbijes jeho skript/config, tak bootovani je otazkou velkeho dialogu na commandlajne :-) Ale bootloader taky casto zastupuje to co dela na PC BIOS ... tj. inicializaci pameti a nekterych periferii.
A to jsme nenatukli to, ze pred bootloaderem muze bezet nejaky pre-boot, ktery nataha firmware do ruznych skrytych procesoru a jednotek (napr. pro usb radic, sitovky, atd).
Imho chovat se k tomu jako k embedded custom reseni je asi nejlepsi co jde delat, protoze ta hracka fakt neni PC (i kdyz po spravnem rozbehnuti OS se tak chovat a vypadat muze).
-
@mhi je to skoro jak popisuješ v ideální variantě. V RAMce nic nepotřebnýho nezavazí :-) ono se to *tolik* neliší od zavádění PC, rozdíl je jen v tom, že ten univerzální firmware (BIOS) není na desce ale nese si ho operační systém s sebou.
Zapneš desce napájení, naskočí pár regulátorů a pustí se napětí do SoC. V socce je pár kB ROMky s prvním firmwarem (boot rom), kterej nahodí hodiny, ARM sběrnice, několik periferních sběrnic jako SPI, SDIO, eMMC, USB, inicializuje on-chip SRAM (pár desítek kB) a pak v nějakým pořadí zkouší z těch sběrnic tahat spustitelnej kód. Pořadí je buď na pevno, nebo se dá ovlivnit určitou kombinací pinů (přepínače, jumpery, pevně na desce). Dejme tomu že se mu něco povede stáhnout z eMMC, magic number nebo součet sedí, tak to nakopíruje na správnej offset v té SRAM a skočí do toho. S trochou štěstí to bude u-boot SPL. Ten spustí a vytrénuje DDR PHY, čímž se adresní prostor rozšíří o pár GB RAM, pak načte z předem známé adresy velkej u-boot.
Ten obvykle udělá pár power management kroků, aby byl boot rychlejší (dosud běžel jen cpu0 na nejmenší rychlost, takže nařídí PMICu zvednout napětí do jader, clock controlleru zvednout takt na maximum, PSCI voláním spustí ostatní jádra nebo komplexy). Pak podle vestavěnýho skriptu najde storage, najde /boot, zjistí co za desku to je, a podle toho sestaví název devicetree blobu (kterých je v /bootu distribuce hodně). Vezme kernel, commandline parametry, initramfs, devicetree blob, to všechno nakopíruje na určitý adresy v RAM (v tomto kroku obrovsky pomáhá ten vyšší takt), a skočí do toho. Pak už je to klasika Linux.
Ještě se tam na určitou adresu v RAM kopíruje jedna binárka, ARM Trusted Firmware. Ta slouží pro obsluhu platformy (trochu obdoba ACPI). Implementuje to mimo jiné Power State Coordination Interface (PSCI), přes kterou se ovládá power management včetně věcí jako suspend to RAM. Je to Arm-Thumb program, neběží to na aplikačních procesorech vedle Linuxu, ale na samostatným Cortex-M jádře, který tam slouží jako platform controller (napájení, instrumentace, bezpečnost, atd).
