Tesztelhető a GNU Boot 0.1 RC1-es kiadása

FSF/GNU/GPL

A GNU Boot egy, a szabad- és nyílt forráskódú programokat promotáló GNU projekt berkeiből származó boot firmware, amely inicializálja a számítógépben található hardvert (pl. memóriavezérlő, CPU, perifériák). A GNU Boot ezután elindít egy rendszerbetöltőt az operációs rendszer betöltéséhez. Vagyis, helyettesíti a proprietray BIOS/UEFI firmware-t, amely általában megtalálható a számítógépekben. A GNU Boot kompatibilis az Intel/AMD processzoros x86 architektúrájú számítógéptípusokkal. A GNU Boot jól működik GNU/Linuxszal és BSD operációs rendszerekkel. A GNU Boot állítólag a Libreboot forkja.

Részletek a bejelentésben.

( trey | 2023. 09. 11., h – 13:08 )

GNU Boot has published its first release candidate, and we need help for testing, at first from people who are able to recover from computers that don't boot anymore.

DualBIOS-os alaplappal rendelkezők előnyben. Nem biztos, hogy érdemes belefirkálni egy sima laptopba :D Mivel a BIOS gyakorlatilag egy SPOF az x86 gépekben, nem is értem, hogy miért csak egyes alaplapgyártók gondoltak arra, hogy meg kéne fejelni egy backuppal.

trey @ gépház

+1 a gigabyte-ra. Asztali gépemet 2015-ben vettem gigabyte lappal, 2022 végéig kvázi 24/7 ment, folyamatosan volt használva játékra, melóra, mindenre is.

Tavaly eladtam, azóta munkatársamnál megy 24/7 felváltva munkára és játékra, kutya baja, gyönyörűen teszi a dolgát.

Az első számítógépemet leszámítva - valami sulinetes Celeron 533-as konfig volt - mindegyik gépemet én raktam össze. Mindegyikben Gigabyte alaplap van/volt/lesz. Volt egy nagyobb szünet, mikor nem építettem, de a nemrég összerakott gépembe is egy Gigabyte B550i Aorus Pro AX került.

Azért a gigabyte ellenében is lehet mit mondani BIOS chip témában: jó dolog a dual-bios, viszont ryzen (zen 2) idejében jött a nagy b+ amiért a mikrokódok akkorák lettek, hogy a teljes AM4 generáció (zen1-zen1+-zen2 és ugyanezek APU kiadásai) nem fért mind bele egyetlen 128megabit-es (16 megabájt) BIOS image-be. A gigabyte (és pár másik spúr alaplapgyártó is) a zen2 idején megjelent x570-es alaplapokra pedig 128megabites bios flash csippet tett. Az MSI ezzel szemben (legalábbis a felsőkategóriába) 256 megabites (32 megabájt) flash IC-t tett, így ott ez a gond nem jött elő.

Attól mert saját részre nem vásárolt még képben lehet AMD fronton is.

Nekem vegyesen voltak Intel/AMD processzorral szerelt gépeim, amiket én raktam össze. Egyikkel sem volt szopás.

*worksforme* *worksfortrey* *worksforanybody* avagy hardvert venni tudni kell?!

Nekem anno Asus-al volt rossz tapasztalatom, azóta kerülöm az Asus cuccokat. De szerencse van alternatíva.

2023-ban aki AMD-t javasol szerverbe az fogalmatlan a temaban,

+1

Tudod, a tét nélküli "IBM laborban baszom a rezet a PI tizedest végtelenig számolva" feladatokon túl is van élet. Ezeken a helyeken szeretik az állandó minőséget és némi vélt vagy valós sebességelőnyért nem váltanak hetente róla. 🤷‍♂️

trey @ gépház

AMD's total market share grew from 10.7% at the start of 2022 to 17.6% at the end of the year, while Intel fell from 89.3% at the start of the year to 82.4%. AMD's total share of the CPU market (excluding IoT and custom silicon) rose from 23.3% in 2021 to 29.6%, while Intel's share fell from 76.7% in 2021 to 70.4% in 2022.

az hogy aktualisan tobb valami nem jelent semmit. az IE is volt 90% market sharen... :)

es az intel shareje is azert zuhant mint a ko (2023-ban mar 65/34 az arany), mert olyan fasza :DDDD

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

Jaja, aki egyszer látott compute node-ot, az mindenhova azt haluzik. Nyugodtan vásárold kilószám, előlem nem viszed el.

Valójában, kaptál egy számot az AMD CEO szájábó (25%-os market share szerver piacon) és most nem nagyon tudsz vele mit kezdeni. Segítek: ez azt jelenti, hogy 4 szerverből 1-ben van AMD processzor. 🤷

Személyeskedéssel nem leszel meggyőzőbb.

trey @ gépház

( bzt | 2023. 09. 11., h – 13:38 )

Szerkesztve: 2023. 09. 11., h – 13:39

> A GNU Boot állítólag a Libreboot forkja.

Nem a Libreboot-é, hanem a coreboot-é (bár a gyökerük közös, ez utóbbi jóval többféle vason fut, és a payload támogatása is bővebb).

Egyiké sem. Idézem innen https://savannah.gnu.org/projects/gnuboot/:

GNU Boot is a coreboot distribution much like Debian is a *GNU+Linux
distribution*. GNU Boot provides an automated build system that downloads,
patches (where necessary) and compiles coreboot, GNU GRUB, various payloads and
all other software components needed to build a complete, working ROM image
that you can install to replace your current BIOS/UEFI firmware, much like a
GNU+Linux distribution (e.g. Debian) provides an ISO image that you can use to
replace your current operating system (e.g. Windows).

( bzt | 2023. 09. 11., h – 14:58 )

Szerkesztve: 2023. 09. 11., h – 16:05

> Egyiké sem. Idézem innen https://savannah.gnu.org/projects/gnuboot/:

Aham... És úgy mégis, szerinted az általad is idézett mondat

GNU Boot provides an automated build system that downloads, patches (where necessary) and compiles coreboot

mégis mi mást jelent, ha nem azt, hogy a coreboot-ot forkolja le lokálba?

Szerk: ellenőriztem, nemcsak a savannah honlap szerint coreboot alapú, hanem a forrás szerint is azt forkolja le: https://git.savannah.gnu.org/cgit/gnuboot.git/tree/resources/scripts/do…

git clone https://review.coreboot.org/coreboot || rm -Rf coreboot

Egy kis szösszenet arról, miért is fontos a Libreboot és a coreboot közötti különbség: a Libreboot csakis Szabad és Nyílt Forrásból generálja a ROM-ot, ezzel szemben a coreboot megengedi, hogy bináris blobok kerüljenek a ROM-ba. Emiatt ez utóbbi nyilván sokkal, de sokkal több vasat támogat.

SZVSZ engem csöppet sem érdekel, hogy a memóriamodulokat vagy mondjuk a képernyőfelbontást egy bináris blob inicializálja, mindaddig, amíg a ROM operációs rendszert betöltő része (ún. payload) felett teljes kontrollal rendelkezem, és azt bármikor szabadon lecserélhetem egy tisztán Nyílt és Szabad Forráskódú megoldásra. Azért nem fontos, mert ezek a bináris blobok csakis a gép indításakor futhatnak le egyszer, amint a payloadra adódik a vezérlés, többé már nem használhatók (illetve a payload könnyedén megakadályozhatja, hogy akár csak egy kis részük is rezidens maradjon, elég csak a coreboot memóriáját "not present"-ként vagy "not executable"-ként megjelölni.)

Összehasonlításképp, ezzel szemben a bináris blobok a Linux kernelben nagyon is zavarnak, mert azok mindvégig aktívak maradnak (ráadásul rendszerfelügyeleti, ring 0 jogosultsággal), míg fut a gépem.

( Raynes | 2023. 09. 11., h – 17:50 )

Emlékszem erre a projektre, hetek óta megy körülötte a cirkusz. A Librebootból forkolták, de annak egy régi verzióját, a librebootos fejlesztő meg harcol ellenük, hogy ne használja senki, vagy ha forkolják is, akkor egy újabb verziót.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Valószínűleg emiatt is van, hogy a most bejelentett, itt hivatkozott 0.1 RC1-es változat már a coreboot-ot húzza le, közvetlenül a lehető legnaprakészebb upstream repóból, és a Libreboot-ot már bottal sem piszkálja.

(Egyébként mindentől függetlenül szerintem tök felesleges ez a GNU projekt, semmi különös baj sincs a coreboot fordítással. Tapasztalatból mondom, hogy semmivel sem macerásabb, mint bármelyik másik FOSS projekt lefordítása. Annyi csak, hogy a klónozás után le kell töltetni vele a gites submoduleokat is, és onnantól megy, mint a doxaóra. A konfigurálója pont ugyanaz a KConfig, mint a Linux kernelé, a make menuconfig is pont ugyanúgy működik. https://www.coreboot.org/Build_HOWTO)

( gazsiazasz | 2023. 09. 11., h – 18:32 )

Szerkesztve: 2023. 09. 11., h – 18:35

van benne ssd raid trim támogatással? resizable bar támogatás? nvme ssd m.2 boot támogatás? exfat/ntfs/hpfs/apfs támogatás? ipv6 pxe boot? wifi pxe boot?

van benne ssd raid trim támogatással? resizable bar támogatás? nvme ssd m.2 boot támogatás? exfat/ntfs/hpfs/apfs támogatás? ipv6 pxe boot? wifi pxe boot?

Az nem az ő dolga, hanem a payloadé. Ez csak max. alacsony szintű elérést biztosít bizonyos eszközökhöz (amiket aztán a payload vagy használ, vagy nem), a többi, az eszközök által szolgáltatott adat értelmezése (raid, fájlrendszer, DHCP csomag stb.) már teljes egészében a payload-on múlik.

Ha pl. GRUB-ot adsz meg payloadnak, és behúzatod vele az ezeket kezelő GRUB modulokat, akkor tudni fogja a kigenerált ROM. Vagy ha egy Linux kernel-t adsz meg payloadnak és belefordítod ezeket a kernel modulokat, akkor is tudni fogja a ROM. (Megjegyzés: sem a GRUB, sem a Linux kernel nem használja a libpayload által biztosított API-t, hanem saját meghajtóik vannak mindenre, szóval már csak ezért is tök mindegy, hogy alapból milyen eszközökhöz biztosít elérést.)

Szerk.: Hmmm, ez érdekes. A honlapon állítottakkal ellentétben a forrás bizonysága szerint választható payloadnak a GRUB, az U-Boot, a memtest86+ és a SeaBIOS, de meglepő módon a TianoCore (UEFI) és a Linux kernel egyáltalán nem... Nem igazán értem, ezek is csont nélkül fordíthatók a coreboot build rendszerével (mondjuk a TianoCore hiába fordul le, bugos, mint állat, szóval azt még meg is értem; na de a Linux kernel payload már a legeslegelejétől fogva, mindig is támogatott volt).

Nem, ezeket most is az uefi tudja, nem a bootolt linux, memtest, akármi...

Ha egy gépen GNU Boot / coreboot / Libreboot ROM-ot használsz, akkor azt a gyári BIOS és UEFI firmware ROM-ok helyett használod. Azaz nincs is UEFI, ami bármit is tudhatna.

És nem bootol GNU/Linux-ot se (mint oprendszer), hanem csupán csak egy statikusra fordított Linux (mint kernel) van benne. Ez a speckó minimál Linux kernel nincs betöltve, hanem szerves része a ROM-nak, és gyakorlatilag csak az eszközmeghajtói vannak használva (alapból legalábbis, természetesen fordíthatsz hozzá bármilyen elvetemült kernelt).

Ha azt akarod, hogy az UEFI szolgáltatások elérhetőek legyenek egy coreboot ROM-os gépen, akkor ahhoz a TianoCore payload-ot kell belefordítanod a ROM-ba. Ez a GNU Boot-al úgy látszik nem működik még, a coreboot-al azonban igen.

( dejo v | 2023. 09. 12., k – 11:37 )

Kérdés, hogy a gyártók erre fognak építkezni, vagy mindent elkövetnek olyan BIOS kialakítására amire ezt még véletlenül sem lehet feltelepíteni?

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

A kérdés jó, de idejétmúlt. A coreboot-ot számtalan gyártó használja már évek óta, és olyan nevek tolják, mint az Intel, Asus, AsRock, MSI, Lenovo vagy épp a Google (Chromebook-ban is ilyen firmware van), de akad mutatóba egy-egy hivatalos Dell-es és HP-s gép is, valamint lelkes hozzájárulók számtalan géptípushoz csináltak már KConfig fájlokat (a hivatalosan támogatott KConfig fájlok listáját itt találod, de ez nem az összes, csak azok, amiket a saját gyártóik tartanak karban).

Mivel a GNU Boot csupán csak újracsomagolja mindezt, ezért az is működni fog minden ilyen gépen.

A teljes képhez hozzátartozik, hogy azért a nem hivatalosan támogatott gépek elég bugosak. Olyan hibajegy, hogy egyáltalán ne működne a coreboot egy adott gépen, elég kevés akad, sokkal jellemzőbb, hogy csak egy-két eszköz rakoncátlankodik, mondjuk nincs a laptopon háttérvilágítás, üres az EDID lista vagy nem látja az USB-s diszkeket, ilyesmik. Jelenlegi formájában érdemes sajátot fordítani belőle úgy, hogy tökéletesen tisztában vagy az alaplapodon található összes csip típusával, és pontosan személyre tudod szabni a make menuconfig-ban.

Ez mondjuk előnye lehet a GNU Boot-nak a jövőben, ha a konfig mappa tartalmát alaposan felduzzasztják. Jelenleg még elég szerény a felhozatal, de azért akad itt olyan proprietary csodabogár is, mint a MacBook.

Köszi. Most már csak azt kellene kiderítenem, hogy az én HP Chromebook 13 G1 gépemre ennek tudatában hogy lehetne egy alternatív oprendszert (Chrome OS Flex, vagy Linux) feltelepíteni?

Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Hát, én először is megpróbálnám kideríteni, most pontosan milyen KConfig-ú, ami benne van (driverek és beállítások miatt). Ilyent KConfig-ot lehet, találsz is neten a gépedhez. Ha ez megvan, akkor csak lecserélném benne a payload-ot egy grubra, mást nem bántanék, és ezt a ROM-ot flashelném. Eztán már ROM bazgerálás nélkül is bármi mást lehet bootolni lemezről (azt nem tudom, hogy a grub.cfg ez esetben lehet-e a lemezen, de asszem igen. Ha mégsem, akkor sem kell a ROM-ot újrafordítani, elég a cbfstool-al kicserélni a ROM imageben a grub.cfg fájt egy újra, ha változtatni akarsz).

(Megjegyzés: ez csak well-educated guess, én magam sosem használtam grubot payloadként. Igazából írtam egy saját payloadot, ami remekül működik, nincs okom bármi mást használni.)

( solt87 | 2023. 09. 12., k – 11:47 )

GNU a csizmám, coreboot-ra van felaaaaaa-kaaaaaaszt-VA.
Bútszektorát megeeeeee-ttejaaaaa róóóóózsda.
Meghekkelem olyaaaaaaan betyáááááár móóód-RA
!HOGY!
Mind egy szállig lepereg a rozsda róóóóóólla.

(hekkerstílusú piréz népdal, Átesésember Richárd gyűjtése)

( pozsarzs | 2023. 09. 13., sze – 10:04 )

Emlékszem, régen volt FreeBIOS, OpenBIOS és LinuxBIOS projekt is. Ezekből lett egyáltalán valami?

A coreboot leánykori neve a LinuxBIOS, amikor még csak Linux payloadja volt.

A másik kettőben nem vagyok biztos, mindesetre a legtöbb VM (qemu, vb, bochs stb.) szállít egy BIOS implementációt, a SeaBIOS-t (ugyancsak használható coreboot-al is). Nem tudom, milyen rokonságban van a másik kettővel, mindesetre ez számít manapság etalonnak, és FOSS. A bochsnak van még egy saját, minimál FOSS BIOS implementációja is (itt, a SeaBIOS előtt nagyon sokáig ezt használta a qemu is), de nem találtam semmi utalást rá, hogy ez rokon-e.

Én csodálkozom, hogy nem lett népszerűbb a Linux alapú BIOS/UEFI. Ugyanis ingyen van, szabványos, könnyen bővíthető, hekkelhető, moduláris, az alaplapgyártóknak olcsóbb lenne arra fejleszteni, mint BIOS gyártóktól licencelni kódokat, de örömmel belemennek, mert így zárt forráskódú, lezárt, lebutított megoldást tudnak a felhasználóra tolni, aki nem tud ellene sokat csinálni.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( ricsip v | 2023. 09. 14., cs – 15:28 )

Szerkesztve: 2023. 09. 14., cs – 15:31

Laikusoknak van róla valami tldr szintű leírás, hogy ha az alaplapgyártó által szállított "gyári" bios-t felülírom egy ilyen v. hasonló hobbiproject bios-al, akkor végülis a gép bekapcsolása és az oprendszer elindulása között mi történik gyári bios vs. hobbi-bios esetben másképpen? Jobban? Rosszabban?

Mi az oka, h. az elmúlt 30 évben award, ami, meg phoenix bios-on kívül nem volt más alternatíva?  Uefi megjelenésekor volt egy ugrás fícsörszetben, de az is már 10+ éves történet, mi történt időközben?

Pcengines apu2-n használok pl. coreboot-ot, de ott olyan mint "gyári" bios soha nem is volt, a coreboot a gyári bios-a, nincs rá más alternatíva.

Laikusoknak van róla valami tldr szintű leírás, hogy ha az alaplapgyártó által szállított "gyári" bios-t felülírom egy ilyen v. hasonló hobbiproject bios-al, akkor végülis a gép bekapcsolása és az oprendszer elindulása között mi történik gyári bios vs. hobbi-bios esetben másképpen? Jobban? Rosszabban?

Hát nincs. Régen volt itt (bár az sem laikusoknak íródott), de ez most átirányít az új doksira, ahol viszont egy büdös szó sem esik a konkrét boot folyamat lépéseiről... (én legalábbis nem találtam. Ezeknek a lépéseknek külön nevük van, arra kerestem, de semmi.)

Nagyon zanzásítva:

- a gyári BIOS inicializálja a hardvert (memóriamodulok, perifériák stb. ezt szokás Power On Self Testnek is hívni, de kicsit több annál, nemcsak teszt), feltölti az egyszintes Interrupt Vector Table-t a kiszolgálórutinok címeivel, aztán lefuttat egy rutint, ami úgy működik, ahogy azt a BIOS Boot Specification leírja (ez az, ami többek között a bootszektort betölti, az abban lévő kód felel az oprendszer betöltéséért).

- a gyári UEFI inicializálja a hardvert, betölt mindenféle memóriazabáló drivert meg cuccost, legyárt pár funkciómutatót tartalmazó C struct-ot (többszintű EFI System Table, azaz néhány táblabejegyjés további táblákra mutat), aztán lefuttat egy rutint, ami úgy működik, ahogy azt az UEFI Specification "3.1. Firmware Boot Manager" fejezetében le van írva. Ennek egy modulja, a CSM a korábbi BIOS Boot Specification-t implementálja, jellemzően az utolsó fallback boot opcióként (már ha van, az újabb gépekből már hiányzik a CSM). Ha nem CSM, akkor végignyálazza az összes diszket, hogy melyiken van EFI System Partition, és a legelső, amit talál, azt használja (lásd 13.3.1. System Partition. Ennek Microsoft©®Ⓜ™ FAT fájlrendszert kell tartalmaznia. Erről a partícióról betölt egy mindenféle nyakatekert módon előállított útvonalról egy Microsoft©®Ⓜ™ PE/COFF formátumú futtathatót, és ez az, ami az oprendszer betöltéséért felelős.

- a "hobbi-bios" (legalábbis a coreboot) inicializálja a hardvert (memóriamodulok, perifériák stb. ez az, amit KConfig-al konfigurálhatsz), majd átadja a vezérlést a ROM egy olyan részére, ami független ezektől, és szabadon lecserélhető (payload). Emiatt sokkal rugalmasabb, ez a payload implementálhatja a BIOS Boot Specification-t (SeaBIOS payload), az UEFI Specification-t (TianoCore payload), vagy akár tetszőlegesen valami egészen mást is (pl GRUB vagy Linux payload).

Mi az oka, h. az elmúlt 30 évben award, ami, meg phoenix bios-on kívül nem volt más alternatíva?

Mert a kutyának se kellett. Ami volt, az tette a dolgát, és kész. A BIOS-nak csak annyi dolga volt, hogy betöltse a boot loadert, aztán ment a kukába, semelyik modern OS sem foglalkozott vele már többet (leginkább azért, mert valós módú, és a kernelek nagyon gyorsan átkapcsolnak védett vagy mostanában még inkább long módba, így a BIOS szolgáltatások hasznavehetetlenek. Kerülőmegoldásként ideiglenesen vissza lehet kapcsolni valós módba (a Win95/Win98 ezt csinálta), vagy lehet emulálni a 16-bites utasításokat (XFree86 így váltott képernyőfelbontást) valamilyen libbel, de a modern OS-k inkább saját meghajtót használnak, semmint bármilyen módon a firmware-re támaszkodnának (WinNT illetve XOrg+Mesa)).

Uefi megjelenésekor volt egy ugrás fícsörszetben

Hát én ezt erősen megkérdőjelezném. Az UEFI nagyságrendekkel kevesebbet tud, mint amit a BIOS tudott, ellenben nagyobb, lassabb, erőforrászabálóbb és még könnyedén meg is fertőzhető mailware-el és rootkit-el. (Csak egy példa: a VBE BIOS, ami a képernyőfelbontásért felelős, mindvégig elérhető (már ha egy kernel visszakapcsol valós módba, vagy emulálja a 16-bites x86 utasításokat), ezzel szemben az UEFI GOP, ami ugyanezért felel, nemcsak gyakorlatban, de elméletileg is használhatatlan bármilyen kernel számára (csak a kernel handover előtt elérhető a spec szerint). Ugyanez igaz szinte az összes többi szolgáltatásra is, pl. BIOS funkciókkal lehetséges használni bármilyen diszket, míg UEFI alól erre semmi esély sincs. Ez ám a fejlődés!!!! Nagyobb, lassabb, sebezhetőbb, de legalább kevesebbet tud!) Pont nemrég néztem egy másik threadben, hogy UEFI-vel bootolni egy qemu-t legalább 5-6 másodperc és minimum 64 mega RAM kell neki, míg BIOS-al kevesebb, mint 0.5 másodperc (!) és elég 1 mega RAM.

Hát nem mondanám, h. mindent értettem abból amit itt hosszasan leírtál :)

Minél többet olvasok róla, nézek YT-on videókat, annál nagyobb katyvasz a fejemben ez az egész UEFI. Kíváncsi lennék vajon itt hányan vannak tisztában teljes egészében a működésével. Mármint valóban, nem csak felületesen.

Ne aggódj, a hiba nem a Te készülékedben van, az UEFI valóban egy hatalmas katyvasz. A legrosszabb, hogy a speckó rohadtul nem tér ki számos fontos dologra, és önmagának is többhelyen ellent mond... Aztán értsd, ahogy akarod. De a legeslegjobb az, hogy a referencia implementáció, a TianoCore sem felel meg a specifikációnak számtalan helyen... LOL!

Bennem egyébként az is felmerült már, hogy szándékosan lett ilyen szar a speckó, és ilyen trehány a TianoCore kódbázisa, hogy el tudja summantani a szarságait a Microsoft©®Ⓜ™. Például a "Secure" Boot-nak nevezett cucc, ami még csak véletlenül sem biztonságos, csupán csak arra jó, hogy ne lehessen szabályosan Windows-on kívül bármi mást bootolni. Tényleg csakis ez a célja, ne hagyd, hogy a név megtévesszen. (Ha kíváncsi vagy a részletekre, szívesen elmondom, legalább háromféleképp meg tudom kerülni, de ezek blackhat módszerek. Szóval a malware-knek egyáltalán nem akadály, bármi más hivatalos oprendszernek viszont az.)

De hogy konstruktív is legyek, itt egy kicsit bővebb leírás arról, hogy működik (ez még mindig csak felületes, de remélhetőleg érthetőbb, mint a korábbi leírásom. Az EDK2 a TianoCore referencia implementáció SDK-ja):

Miből áll a ROM

- A gyári UEFI egy moduláris ROM, többi kicsi fájl van egymásután pakolva benne. Minden modulnak van egy szabványos OptionROM vagy FFS-nek hívott fejléce. Ilyeneket az EDK2 GenSec és GenFFS tooljaival lehet kreálni (illetve én írtam egyet, ami Linuxon is működik EDK2 nélkül). Az OptionROM-ra szerencsére már volt egy GPL-es tool (ez, ebből is csináltam egy függőségmentes, Linuxon is futó verziót, lásd itt). Ezeket a modulokat egy Windows PE/COFF futtathatóból kell konvertálni (amiben csak annyi a különleges, hogy nem használhat semmilyen DLL-t és a fejlécben egy bájt nem a szokásos). Ebből a PE/COFF formátumból következik az is, hogy minden funkcióhívás az MS ABI-t használja.

- Namost olyan eszköz, ami ezeket a modulokat összepakolná egy ROM-á, nincs, illetve egy speciális esetet kezelő tool van csak az EDK2-ben. Van viszont 3rd party Windows-only Uefitool, ami pont ezt csinálja. Bővebb leírást itt találsz, de csak erős idegzetűeknek! Ez egy tutorial, ami azt mutatja be, hogy kell egy új fájlrendszer meghajtót hozzáadni a ROM-hoz.

ROM futása

- Tegyük fel, hogy megvan a ROM-od (az EDK2 ezt valamiért OVMF.fd néven köpi ki magából, ezt a fájlt kell flashelni). A gép bekapcsolásakor ebben a ROM-ban sorra minden "driver" típusú modul belépési pontja meghívódik két paraméterrel (lásd alább), hogy inicializálja az eszközeit, majd legvégül elindul a Firmware Boot Manager-t implementáló modul (szét van szórva a kódja a repóban, nehogy könnyen átlásd, mit csinál. A BootOrder-es rész pl OvmfPkg/Library/PlatformBootManagerLib alatt van).

- A Firmware Boot Manager dolga, hogy megkeressen egy adott FAT partíciót, illetve hogy a BootOrder alapján fájlokat keressen és töltsön be róla. Ha minden más próbálkozása csődöt mondott, akkor az EFI\BOOT\BOOT(arch).EFI nevű fájlt kéne, hogy betöltse (a gyakorlatban ez nem mindig van így, rengeteg UEFI implementáció a gyökérbeli BOOTMGR.EFI nevű fájlt tölti be, ami a Windows része, nem máté'.) A BootOrder hivatkozhat egy ROM modulra is, tipikus példa erre az UEFI Shell nevű modul hívása.

Oprendszerbetöltő futása

- Ez a betöltött fájl (milyen meglepő) ugyancsak egy PE/COFF futtatható, pont mint azok, amikből a modulok lettek készítve. Induláskor ennek is két paraméterrel hívódik a belépési pontja: az egyik arra az objektumra mutat, ami betöltötte, a másik pedig egy mutatókat tartalmazó struktúrára. Ez utóbbi A LÉNYEG (így nagybetűvel), a teljes leírását itt találod, de legyen elég annyi, hogy ez egy táblázat, tele mutatókkal.

- (kis kitérő) BIOS alatt úgy érsz el egy funkciót, hogy a kiszolgáló rutinok címei az IVT-be kerültek, tehát elég egy INT utasítással megszakítást generálni. UEFI alatt ez nem így van, ott neked kell kimazsolázni a funkció címét a fent említett táblából, összeszerkesztened egy MS ABI szabványos veremkeretet, majd meghívni a táblázatban szereplő címet. (Érdekesség: régen a gcc nem tudott MS ABI híváskonvenciót, ezért a GNU EFI-ben ezt az "uefi_call_wrapper()" nevű makró csinálta. Modernebb fordítók esetén erre már nincs szükség, azok csont nélkül kezelik az MS ABI függvényhívás konvenciót.)

- vissza a partícióról betöltött programhoz. Az UEFI által nyújtott funkciókat használva meg kell keresni és be kell töltenie az operációs rendszert. Milyen szép is volna, ha minden szükséges funkció címe szerepelne a táblában! De nem. Helyette van egy "LocateProtocol" és "HandleProtocol", aminek UUID-ket kell megadni, és ez alapján kikeresi, hogy melyik modul implementálja azt. Például, ha állítani akarsz a felbontáson, akkor "LocateProtocol"-al kikeresteted azt a modult, ami implementálja a Graphics Output Protocol-t (GOP). Ha van ilyen, akkor visszakapsz egy újabb táblát, szintén mutatókkal, többek között a "SetMode" eljárás címével. Vagy, másik példa: ha szektorokat akarsz beolvasni egy lemezről, akkor a "LocateProtocol"-al lekéred azokat a modulokat, amik implementálják a Block IO Protocol-t (BIO), majd a "HandleProtocol"-al végigiterálsz az összes eszközön, amiket ezek a modulok kezelnek, hogy megtaláld a diszkedet. Ezután az adott eszközhöz visszaadott BIO táblában lesz egy "ReadBlocks" funkció mutató, amit használhatsz az adott eszközről való olvasáshoz.

- miután a program betöltötte az operációs rendszer induló fájljait (kernel, initrd, stb.), meg kell hívni az "ExitBootServices" funkciót. Ezt követően a legtöbb UEFI szolgáltatás elérhetetlenné válik, viszont innentől nem is fogják többé a háttérben összebarmolni a memóriát. Ha ez megvan, akkor kikapcsolható az identikus címfordítás, és beállítható olyan leképezés, ami kell a kernelnek, és el lehet indítani a kernelt (erre nincs protokoll, egyszerűen a kernel belépési pontjára kell ugrani, akárhol is legyen az épp a memóriában).

Nagy vonalakban. Ennél persze sokkal macerásabb az egész, és rengeteg buktató van, amit csak kínkeserves trial-and-error módszerrel lehet workaroundolni.