Coreboot 26.09 i GRUB2 2.14 na ThinkPadzie T400 – kompilacja, naprawa błędów i własny motyw graficzny

Lenovo ThinkPad T400 to laptop, który mimo swojego wieku nadal potrafi zaskoczyć możliwościami modernizacji. Wymiana procesora, rozbudowa pamięci RAM czy instalacja dysku SSD to jednak dopiero początek. Znacznie ciekawsze możliwości otwiera alternatywne oprogramowanie układowe. Tym razem postanowiłem zbudować Coreboot 26.09 z GRUB2 2.14 jako głównym payloadem dla ThinkPada T400, zastępując dotychczas wykorzystywany SeaBIOS graficznym środowiskiem rozruchowym.

Cel był konkretny: zachować sprawną konfigurację sprzętową, uruchamiać Debiana 13 bezpośrednio przez GRUB2, a jednocześnie przygotować własne menu graficzne w natywnej rozdzielczości 1280 × 800 pikseli. Dodatkowo chciałem pozostawić SeaBIOS jako alternatywny payload oraz zachować dostęp do narzędzi diagnostycznych Coreinfo, NVRAMCUI, Memtest86+ i Tint.

Realizacja okazała się bardziej wymagająca, niż początkowo zakładałem. Kompilacja GRUB2 2.14 przyniosła konflikty typów w libgcrypt, problemy z linkowaniem jądra GRUB oraz konieczność dopracowania zawartości CBFS. Wszystkie najważniejsze przeszkody udało się jednak pokonać. Efektem jest działający ThinkPad T400 z Corebootem 26.09, GRUB2 2.14 i autorskim motywem graficznym.

ThinkPad T400 z Core 2 Quad Q9100 – konfiguracja sprzętowa

Podstawą projektu jest Lenovo ThinkPad T400, model 6474-D8B, który przeszedł już wcześniej szereg modernizacji. Najważniejszą była wymiana fabrycznego procesora na czterordzeniowy Intel Core 2 Quad Q9100. Jest to jednostka taktowana zegarem 2,26 GHz, wyposażona w cztery rdzenie i charakteryzująca się TDP wynoszącym 45 W. Jej zastosowanie w T400 wymagało również odpowiedniej modyfikacji płyty głównej, w tym obwodu GTLREF.

Laptop dysponuje 8 GB pamięci RAM, dyskiem SSD oraz matrycą Samsung LTN141AT09-201 o rozdzielczości 1280 × 800 pikseli. Za obsługę grafiki odpowiada Intel GMA 4500MHD, a komputer pracuje pod kontrolą Debiana 13 Trixie ze środowiskiem Cinnamon.

Wcześniej wykorzystywałem Coreboot 26.09 z SeaBIOS 1.17.0. Firmware działał stabilnie, obsługiwał uśpienie S3 oraz pozwalał korzystać z dodatkowych payloadów diagnostycznych. Nie chodziło zatem o naprawę niesprawnego komputera, lecz o dalsze rozwijanie jego możliwości.

Warto przypomnieć, że Coreboot odpowiada przede wszystkim za inicjalizację sprzętu, a następnie przekazuje sterowanie do wybranego payloadu. Może nim być SeaBIOS, GRUB2 lub inne kompatybilne środowisko. Dzięki temu zmiana sposobu uruchamiania systemu nie wymaga porzucenia samego Coreboota.

Dlaczego zdecydowałem się na GRUB2 zamiast SeaBIOS?

SeaBIOS jest bardzo dobrym rozwiązaniem dla starszych komputerów, ponieważ zapewnia klasyczne środowisko BIOS, zgodność z tradycyjnym sposobem rozruchu i obsługę wielu systemów operacyjnych. GRUB2 jako payload Coreboota oferuje jednak inne możliwości.

Najważniejszą zaletą jest bezpośrednie uruchamianie jądra Linuksa z poziomu firmware. GRUB2 może samodzielnie obsłużyć kontroler SATA, odczytać tablicę partycji, rozpoznać system plików ext4 i załadować jądro wraz z initramfs. Nie potrzebuje do tego SeaBIOS ani dodatkowego GRUB-a uruchamianego z dysku.

Drugim powodem była grafika. GRUB2 obsługuje framebuffer, obrazy JPEG, fonty PF2 oraz własne motywy. Można więc zastąpić tradycyjny ekran tekstowy interfejsem dopasowanym do konkretnego komputera.

W moim przypadku zależało mi na stylistyce klasycznych ThinkPadów: czarnym tle, czerwonych akcentach i przejrzystym menu. Grafika miała uzupełniać funkcjonalność, a nie ją ograniczać. Jednocześnie chciałem zachować możliwość uruchamiania SeaBIOS oraz narzędzi diagnostycznych bezpośrednio z menu nowego GRUB2.

Konfiguracja Coreboot 26.09 z GRUB2 2.14

Budowę nowego firmware prowadziłem w środowisku WSL, korzystając z oddzielnej kopii katalogu źródłowego Coreboota. To ważne, ponieważ wcześniejsza, działająca konfiguracja z SeaBIOS pozostała nienaruszona. Mogłem więc wprowadzać zmiany, testować kompilację i analizować błędy bez utraty poprzedniego projektu.

W konfiguracji Coreboota wybrałem płytę Lenovo ThinkPad T400 oraz GRUB2 2.14 jako główny payload. Najważniejsze ustawienia wyglądały następująco:

CONFIG_PAYLOAD_GRUB2=y
CONFIG_PAYLOAD_BUILD_GRUB2=y
CONFIG_GRUB2_STABLE=y
CONFIG_GRUB2_INCLUDE_RUNTIME_CONFIG_FILE=y
CONFIG_GRUB2_RUNTIME_CONFIG_FILE="grub.cfg"
CONFIG_SEABIOS_SECONDARY_PAYLOAD=y

Istotna była również zmiana trybu wyświetlania. Wcześniejszy firmware wykorzystywał VGA Text Mode, natomiast graficzny GRUB2 wymagał odpowiedniego framebufferu. Zachowałem inicjalizację grafiki przez libgfxinit i włączyłem obsługę linear framebuffer.

CONFIG_GENERIC_LINEAR_FRAMEBUFFER=y
CONFIG_LINEAR_FRAMEBUFFER=y

Konfiguracja płyty głównej, chipsetu Intel GM45, kontrolera pamięci i pozostałych elementów sprzętowych została zachowana. Zmiany dotyczyły przede wszystkim rodzaju głównego payloadu oraz obsługi grafiki.

Jako dodatkowe payloady pozostawiłem SeaBIOS, Coreinfo, NVRAMCUI, Memtest86+ i Tint. Zachowane zostały również pliki konfiguracji CMOS, czyli cmos.default i cmos_layout.bin. Dzięki temu nowe środowisko rozruchowe miało oferować tę samą funkcjonalność diagnostyczną co wcześniejsza konfiguracja.

GRUB2 2.14 – pierwszy problem kompilacji: conflicting types w libgcrypt

Pierwsza próba kompilacji GRUB2 2.14 zakończyła się błędami w pliku grub-core/commands/pgp.c. Kompilator zgłaszał niezgodność deklaracji kilku funkcji kryptograficznych. Najważniejszy komunikat wyglądał następująco:

error: conflicting types for '_gcry_kdf_open'

Podobne problemy dotyczyły funkcji _gcry_kdf_final oraz _gcry_sexp_build. Po analizie komunikatów błędów okazało się, że różne nagłówki wykorzystywały odmienne typy parametrów. W jednym miejscu występował size_t, natomiast w drugim grub_size_t.

Na używanym toolchainie różnica ta miała znaczenie. W omawianej kompilacji typ size_t występował jako unsigned long, podczas gdy grub_size_t odpowiadał unsigned int. Powstawały więc sprzeczne deklaracje tych samych funkcji, których kompilator nie mógł zaakceptować.

Na początku poprawiłem odpowiednie deklaracje bezpośrednio w wygenerowanym nagłówku include/grub/gcrypt/gcrypt.h. Po zamianie problematycznych wystąpień size_t na grub_size_t kompilacja przeszła przez wcześniejszy błąd. Rozwiązanie było jednak tymczasowe.

Podczas kolejnej próby budowania GRUB2 problem powrócił. Okazało się, że nagłówek jest generowany automatycznie, więc ręczne zmiany nie pozostawały w nim na stałe. Konieczne było odnalezienie rzeczywistych plików źródłowych odpowiedzialnych za jego utworzenie.

Poprawka libgcrypt w plikach gcrypt.h.in i gcrypt-int.h

Analiza skryptu autogen.sh ujawniła sposób powstawania nagłówka gcrypt.h. GRUB2 wykorzystuje dwa pliki wejściowe oraz skrypty sed odpowiedzialne za przetwarzanie deklaracji funkcji biblioteki libgcrypt.

Właściwe pliki źródłowe znajdowały się w katalogu:

grub-core/lib/libgcrypt/src/gcrypt.h.in
grub-core/lib/libgcrypt/src/gcrypt-int.h

W pierwszym z nich znajdowały się deklaracje publiczne, a w drugim deklaracje wewnętrzne, między innymi funkcji _gcry_kdf_open, _gcry_kdf_final i _gcry_sexp_build.

Poprawka polegała na zamianie sześciu problematycznych wystąpień size_t na grub_size_t. Cztery dotyczyły parametrów długości danych przekazywanych do funkcji KDF, jedno długości wyniku, a ostatnie wskaźnika wykorzystywanego przez funkcję budującą wyrażenia S-expression.

Po zabezpieczeniu oryginalnych plików zmodyfikowałem deklaracje, a następnie wygenerowałem ponownie nagłówek z użyciem mechanizmu stosowanego przez GRUB2.

Do importowania deklaracji służyły skrypty import_gcrypth.sed oraz import_gcrypt_inth.sed. Kontrola wygenerowanego gcrypt.h potwierdziła, że poprawione typy znalazły się w odpowiednich miejscach.

Najważniejszy wniosek: podczas naprawiania błędów kompilacji GRUB2 nie zawsze wystarczy zmodyfikować plik wskazany w komunikacie kompilatora. Jeżeli dany nagłówek powstaje automatycznie, trzeba odnaleźć jego źródło. W przeciwnym razie kolejna konfiguracja projektu może przywrócić pierwotny problem.

Błąd kernel.img – nieprawidłowy adres 0x9054 zamiast 0x9000

Po rozwiązaniu konfliktu typów w libgcrypt GRUB2 przeszedł do dalszych etapów kompilacji. Następna przeszkoda pojawiła się przy generowaniu końcowego payloadu przez grub-mkstandalone.

Narzędzie zgłosiło następujący błąd:

grub-core//kernel.img is miscompiled: its start address is 0x9054 instead of 0x9000: ld.gold bug?

GRUB2 oczekiwał adresu początkowego 0x9000, natomiast wygenerowany obraz rozpoczynał się pod adresem 0x9054. Różnica wynosiła zaledwie 84 bajty, ale była wystarczająca, aby proces tworzenia payloadu zakończył się niepowodzeniem.

Diagnostyka doprowadziła do ustawienia TARGET_IMG_BASE_LDOPT. W konfiguracji GRUB2 2.14 wykorzystywana była opcja linkera:

TARGET_IMG_BASE_LDOPT="-Wl,--image-base"

W używanym środowisku kompilacji rozwiązaniem okazało się zastąpienie jej ustawieniem:

TARGET_IMG_BASE_LDOPT="-Wl,-Ttext"

Poprawkę wprowadziłem w plikach configure.ac oraz configure. Następnie wymusiłem ponowne linkowanie kernel.img. Tym razem obraz został wygenerowany prawidłowo, a grub-mkstandalone zakończył działanie bez błędów.

Warto zaznaczyć, że pojawienie się tekstu ld.gold bug? nie dowodzi automatycznie, że podczas kompilacji faktycznie wykorzystywano linker Gold. Jest to komunikat diagnostyczny GRUB2 związany z wykryciem nieprawidłowego adresu obrazu.

Po zastosowaniu obu poprawek powstał plik default_payload.elf o rozmiarze około 1,5 MiB. Kontrola za pomocą narzędzia readelf potwierdziła poprawny format ELF32, architekturę Intel 80386 oraz oczekiwany punkt wejścia.

Class: ELF32
Machine: Intel 80386
Entry point address: 0x9000

W ten sposób udało się uzyskać działający na poziomie kompilacji payload GRUB2 2.14 przeznaczony dla platformy i386-coreboot.

GRUB2 jako payload Coreboota – moduły SATA, ext4 i obsługa grafiki

Poprawne wygenerowanie pliku ELF nie oznacza jeszcze, że przygotowany GRUB2 będzie potrafił uruchomić system operacyjny. Należy również zapewnić dostępność modułów obsługujących kontroler dyskowy, system plików, tablicę partycji i grafikę.

W konfiguracji GRUB2 uwzględniłem moduły ahci, part_msdos, ext2 oraz search_fs_uuid. Dzięki nim możliwe jest odnalezienie partycji systemowej Debiana 13 na dysku SATA, wykorzystując jej identyfikator UUID.

Do obsługi graficznego menu przygotowałem także dodatkowe moduły:

CONFIG_GRUB2_EXTRA_MODULES="all_video gfxterm_background jpeg"

Ich zadaniem jest zapewnienie obsługi framebufferu i obrazów JPEG wykorzystywanych przez motyw. Po kompilacji sprawdziłem dostępność odpowiednich modułów oraz ich obecność w wygenerowanym payloadzie.

Sam plik grub.cfg został dołączony do firmware jako etc/grub.cfg. Wbudowana konfiguracja startowa GRUB2 sprawdza obecność tego pliku w CBFS, a następnie wykonuje jego zawartość.

Dzięki temu cała konfiguracja rozruchowa znajduje się wewnątrz firmware. Nie trzeba polegać na pliku konfiguracyjnym zapisanym na dysku SSD tylko po to, aby wyświetlić główne menu.

Bezpośrednie uruchamianie Debiana 13 przez GRUB2

ThinkPad T400 działa pod kontrolą Debiana 13 Trixie, zainstalowanego na dysku SSD. Dysk wykorzystuje klasyczną tablicę partycji MBR, natomiast partycja systemowa została sformatowana jako ext4. Nie ma osobnej partycji /boot.

W grub.cfg zastosowałem wyszukiwanie partycji na podstawie UUID. W przypadku tego konkretnego komputera najważniejsze polecenia wyglądają następująco:

insmod ahci
insmod part_msdos
insmod ext2
insmod search_fs_uuid
search --no-floppy --fs-uuid --set=root 26b3def0-4b63-427c-95af-1cfffad8fc78
linux /vmlinuz root=UUID=26b3def0-4b63-427c-95af-1cfffad8fc78 ro
initrd /initrd.img

Moduł ext2 w GRUB2 obsługuje również funkcje potrzebne do odczytu typowego systemu plików ext4. Wyszukiwanie partycji po UUID jest natomiast wygodniejsze niż poleganie wyłącznie na nazwach urządzeń, których kolejność może się zmieniać.

Ścieżki /vmlinuz oraz /initrd.img wykorzystują dowiązania symboliczne obecne w Debianie. Dzięki temu nie trzeba na stałe wpisywać do konfiguracji GRUB2 numeru wersji jądra. Aktualizacja pakietów jądra może zmienić pliki docelowe bez konieczności edytowania ścieżek w firmware.

Podany UUID należy oczywiście traktować jako identyfikator konkretnej instalacji. W innym komputerze konieczne będzie jego zastąpienie prawidłową wartością.

Oprócz Debiana menu zawiera również SeaBIOS oraz narzędzia diagnostyczne, do których dostęp zapewniają dodatkowe payloady zapisane w CBFS.

Własny motyw graficzny GRUB2 dla ThinkPada T400

Jednym z najbardziej widocznych elementów modernizacji jest autorski motyw GRUB2 przygotowany specjalnie dla ThinkPada T400. Założeniem było zachowanie klasycznego charakteru laptopa i wykorzystanie stylistyki znanej z komputerów ThinkPad.

Motyw opiera się na ciemnym tle, czerwonych elementach graficznych i czytelnym układzie menu. Grafika została przygotowana w rozdzielczości 1280 × 800 pikseli, odpowiadającej natywnej rozdzielczości matrycy T400.

Obraz źródłowy został przeskalowany i zapisany jako JPEG przy użyciu ImageMagick. Pozwoliło to uzyskać plik background.jpg zajmujący zaledwie 85 317 bajtów. Niewielki rozmiar grafiki ma znaczenie, ponieważ wszystkie elementy motywu muszą zmieścić się w ograniczonej przestrzeni firmware.

Finalny wariant motywu wykorzystuje osobny plik theme.txt oraz font16.pf2 w formacie PF2. Font jest ładowany bezpośrednio z CBFS, podobnie jak konfiguracja motywu.

Najważniejsze ustawienia graficzne w grub.cfg przedstawiają się następująco:

if loadfont (cbfsdisk)/font16.pf2; then
set gfxmode=1280x800,auto
terminal_output gfxterm
set theme=(cbfsdisk)/theme.txt
export theme
fi

Wykorzystanie CBFS pozwala przechowywać wszystkie zasoby wewnątrz pamięci SPI. GRUB2 nie musi odczytywać tapety ani fontu z partycji systemowej Debiana. Menu pojawia się jeszcze przed uruchomieniem systemu operacyjnego i jest częścią przygotowanego firmware.

Efekt końcowy jest bardzo satysfakcjonujący. Graficzny interfejs wygląda spójnie z konstrukcją T400 i dobrze komponuje się z klasycznym wyglądem starszych ThinkPadów.

CBFS i FMAP – jak zmieścić GRUB2 oraz SeaBIOS w 2 MiB BIOS-u?

Przygotowanie własnego firmware dla T400 wymaga również uwzględnienia ograniczeń pamięci SPI. Laptop wykorzystuje kość Macronix MX25L6405D o pojemności 8 MiB, jednak dostępny region BIOS obejmuje jedynie ostatnie 2 MiB pamięci.

Jego zakres wynosi od 0x600000 do 0x7FFFFF. Pozostała przestrzeń zawiera między innymi Intel Flash Descriptor, Intel Management Engine oraz inne regiony związane z platformą.

Coreboot wykorzystuje mapę FMAP oraz system plików CBFS, w którym przechowywane są poszczególne komponenty firmware. Do analizy i modyfikacji jego zawartości służy narzędzie cbfstool.

build/cbfstool build/coreboot.rom print

W przygotowanym obrazie znalazły się między innymi mikrokody procesora, etapy Coreboota, pliki CMOS, GRUB2, SeaBIOS oraz dodatkowe narzędzia diagnostyczne.

Finalny wariant z pełnym motywem graficznym zawiera również następujące elementy:

etc/grub.cfg
theme.txt
background.jpg
font16.pf2
fallback/payload
img/seabios

Główny payload GRUB2 zajmuje w CBFS około 532 KB, natomiast SeaBIOS około 73 KB. W obrazie znajdują się również Coreinfo, NVRAMCUI, Tint i Memtest86+.

Pomimo rozbudowanego menu i obecności kilku dodatkowych payloadów udało się zachować 595 812 bajtów wolnego miejsca w CBFS. Oznacza to, że całe środowisko rozruchowe bez problemu zmieściło się w wyznaczonym regionie BIOS.

Sprawdziłem także mapę FMAP przy użyciu polecenia:

build/cbfstool ../images/t400-grub2-theme-v1.rom layout -w

Region BIOS rozpoczynał się pod adresem 0x600000 i zajmował dokładnie 2 MiB. Pierwsze 4 KiB zawierały FMAP, natomiast region COREBOOT zaczynał się pod adresem 0x601000.

Taką samą strukturę posiadał wcześniejszy, działający firmware z SeaBIOS. Porównanie pozwoliło potwierdzić, że układ regionów w nowym obrazie jest zgodny z poprzednią konfiguracją.

Flashowanie Coreboot 26.09 z GRUB2 do ThinkPada T400

Ostatnim etapem projektu był zapis nowego firmware do pamięci SPI. To najbardziej ryzykowna część całej operacji, dlatego rozpocząłem ją od wykonania i weryfikacji kopii bezpieczeństwa działającego BIOS-u.

Backup obejmował dokładnie 2 MiB regionu BIOS. Jego zawartość została odczytana ponownie, a porównanie sum SHA256 potwierdziło zgodność danych. Zachowanie takiego obrazu ma podstawowe znaczenie, ponieważ pozwala odtworzyć wcześniejszą konfigurację w razie nieudanego uruchomienia.

Z kompletnego obrazu Coreboota o wielkości 8 MiB wyodrębniłem końcowe 2 MiB przeznaczone do zapisu. Właśnie ten fragment został wykorzystany jako nowy region BIOS. Nie należy zakładać, że cały obraz kompilacyjny 8 MiB nadaje się do bezpośredniego zapisu na fizycznym układzie SPI.

Na ThinkPadzie T400 wykorzystałem flashrom 1.4.0. Program prawidłowo rozpoznał chipset Intel ICH9M-E oraz układ pamięci Macronix MX25L6405D. Odczyt informacji o zabezpieczeniach potwierdził, że region BIOS jest dostępny do zapisu, natomiast region Intel Management Engine pozostaje zablokowany.

Do aktualizacji zastosowałem mechanizm selekcji regionu BIOS na podstawie Intel Flash Descriptor. Polecenie wykorzystane na moim komputerze wyglądało następująco:

sudo flashrom -p internal -c MX25L6405D --ifd -i bios:"$HOME/Pobrane/t400-grub2-theme-v1-bios-2mb.bin" --noverify-all -w "$HOME/coreboot-t400-grub2/backup/t400-flash-read-8mb.bin"

W tym przypadku opcja -i wskazuje nowy, dwumegabajtowy obraz regionu BIOS, natomiast argument -w podaje pełny obraz bazowy wymagany przez używaną wersję flashrom. Dzięki selekcji regionu operacja ogranicza się do BIOS-u, bez wybierania do zapisu Intel ME, Flash Descriptor czy pozostałych obszarów pamięci.

Opcja –noverify-all pozwala pominąć weryfikację niewybranych regionów, które mogą być niedostępne ze względu na zabezpieczenia platformy. Nie zastępuje jednak weryfikacji samego zapisywanego BIOS-u.

Flashrom zakończył zapis następującym komunikatem:

Erase/write done from 600000 to 7fffff

Po zakończeniu wykonałem niezależny odczyt regionu BIOS z pamięci SPI. Suma SHA256 odczytanego pliku była identyczna z sumą przygotowanego wsadu, co potwierdziło poprawność zapisu danych.

Ważne: przedstawione polecenie dotyczy konkretnego ThinkPada T400 i wcześniej zweryfikowanego układu jego pamięci. Nie należy wykonywać go bez sprawdzenia mapy regionów i przygotowania własnej kopii bezpieczeństwa. Przy modyfikowaniu Coreboota warto również dysponować programatorem zewnętrznym, ponieważ nieudany firmware może uniemożliwić ponowne uruchomienie komputera.

ThinkPad T400 z Coreboot 26.09 i GRUB2 2.14 – efekt końcowy

Po zapisaniu i zweryfikowaniu nowego BIOS-u przyszedł czas na najważniejszy test, czyli uruchomienie komputera. Finalny obraz z pełnym motywem graficznym zadziałał prawidłowo. Coreboot zainicjalizował sprzęt, a następnie przekazał sterowanie do GRUB2 2.14.

Na ekranie ThinkPada T400 pojawiło się przygotowane menu graficzne w natywnej rozdzielczości 1280 × 800. Własne tło, font i kolorystyka dobrze współgrają z wyglądem laptopa. Menu zapewnia dostęp do Debiana 13, SeaBIOS oraz dodatkowych narzędzi diagnostycznych.

Co najważniejsze, GRUB2 pozwala bezpośrednio uruchamiać Debiana z dysku SSD. Zachowana została również dotychczasowa konfiguracja sprzętowa komputera, włącznie z czterordzeniowym procesorem Intel Core 2 Quad Q9100.

Projekt wymagał rozwiązania kilku problemów, które nie były związane bezpośrednio z samym ThinkPadem. Konflikt typów w libgcrypt oraz nieprawidłowy adres jądra GRUB2 wynikały z procesu budowania payloadu i zgodności używanych narzędzi. Ich analiza pozwoliła przygotować poprawny plik ELF, a następnie kompletny obraz Coreboota.

Równie ważne było odpowiednie przygotowanie CBFS, zachowanie układu FMAP, kontrola rozmiaru firmware i weryfikacja danych po zapisaniu ich do pamięci SPI.

Czy warto zastąpić SeaBIOS przez GRUB2 w Coreboot?

W przypadku komputera wykorzystywanego przede wszystkim z Linuksem takie rozwiązanie ma dużo sensu. GRUB2 uruchamiany jako payload Coreboota pozwala ograniczyć liczbę pośrednich etapów rozruchu, przygotować własną konfigurację startową i zbudować graficzny interfejs dostosowany do konkretnego sprzętu.

SeaBIOS nadal pozostaje wartościowym rozwiązaniem, szczególnie w przypadku starszych systemów operacyjnych i klasycznego sposobu rozruchu. Nie trzeba jednak całkowicie z niego rezygnować. Coreboot umożliwia umieszczenie go w CBFS jako dodatkowego payloadu, obok GRUB2 i narzędzi diagnostycznych.

Największą zaletą całego przedsięwzięcia jest możliwość rzeczywistego dostosowania komputera do własnych potrzeb. Modernizacja starszego ThinkPada nie musi kończyć się na wymianie procesora, dysku czy pamięci RAM. Można także zmienić oprogramowanie odpowiedzialne za inicjalizację i uruchamianie całego systemu.

Nie jest to oczywiście modyfikacja przeznaczona dla każdego. Budowanie własnego firmware wymaga znajomości Coreboota, narzędzi kompilacyjnych, architektury platformy i zasad bezpiecznego programowania pamięci SPI. Konieczne jest także przygotowanie realnej możliwości powrotu do działającej konfiguracji.

Dla entuzjastów starszych ThinkPadów, Linuksa i otwartego firmware jest to jednak bardzo ciekawa droga. ThinkPad T400 z Coreboot 26.09, GRUB2 2.14, Debianem 13 i własnym motywem graficznym pokazuje, że nawet kilkunastoletni komputer może otrzymać zupełnie nowe środowisko rozruchowe, bez utraty swojego klasycznego charakteru.

W moim przypadku projekt zakończył się sukcesem. GRUB2 2.14 został poprawnie skompilowany, zintegrowany z Corebootem i uruchomiony na fizycznym ThinkPadzie T400. A sam efekt wizualny stanowi znakomite dopełnienie wcześniejszych modernizacji tego laptopa.