Coreboot w ThinkPadzie T400 – naprawa Coreinfo i NVRAMCUI, konfiguracja CMOS i błędna suma kontrolna

Coreboot w ThinkPadzie T400 może działać prawidłowo, uruchamiać system operacyjny i obsługiwać wszystkie podzespoły, a jednocześnie sprawiać problemy z dodatkowymi programami uruchamianymi bezpośrednio z firmware. Przekonałem się o tym podczas modernizacji własnego Lenovo ThinkPad T400, w którym po instalacji Coreboota z SeaBIOS dwa dodatkowe payloady, Coreinfo i NVRAMCUI, nie działały poprawnie. Rozwiązanie okazało się związane z konfiguracją CMOS, a dalsza diagnostyka doprowadziła do jeszcze ciekawszego problemu dotyczącego sumy kontrolnej i zegara RTC.

To trzecia część dokumentacji mojego projektu ThinkPad T400 Quad Core. W pierwszej opisałem odczyt i programowanie pamięci SPI oraz instalację Coreboota, natomiast w drugiej modyfikację GTLREF2, pin mod i uruchomienie procesora Intel Core 2 Quad Q9100. Tym razem zajmę się dopracowaniem firmware, ponieważ po zakończeniu modyfikacji sprzętowej chciałem doprowadzić wszystkie jego funkcje do prawidłowego działania.

Co istotne, nie korzystałem z gotowego obrazu. Firmware zostało samodzielnie skompilowane ze źródeł Coreboota dla Lenovo ThinkPad T400, a jako główny payload wybrałem SeaBIOS 1.17.0. Dodatkowo umieściłem w pamięci SPI kilka narzędzi diagnostycznych i użytkowych, które można uruchamiać bez dostępu do systemu operacyjnego.

Cały proces diagnostyki wykonałem na działającym komputerze z Debianem 13 Trixie, korzystając również ze środowiska WSL Ubuntu na drugim komputerze. Dzięki temu mogłem analizować źródła Coreboota, przygotowywać kolejne kompilacje i sprawdzać zawartość obrazów ROM bez ingerowania w firmware ThinkPada aż do momentu, gdy miałem gotową i zweryfikowaną poprawkę.

Dodatkowe payloady w Coreboocie – do czego służą?

Coreboot odpowiada przede wszystkim za inicjalizację sprzętu. Nie jest klasycznym BIOS-em wyposażonym we wszystkie usługi, do których przyzwyczaiły użytkowników starsze komputery. Po przygotowaniu platformy uruchamia tak zwany payload, czyli program przejmujący dalszą kontrolę nad procesem startowym.

Najbardziej znanym przykładem jest SeaBIOS, który zapewnia zgodność z tradycyjnym sposobem uruchamiania systemów operacyjnych. Można jednak przygotować również dodatkowe payloady pełniące funkcje diagnostyczne, konfiguracyjne lub nawet rozrywkowe.

W moim ThinkPadzie T400 zainstalowałem następujące programy:

• SeaBIOS 1.17.0 – główny payload zapewniający obsługę tradycyjnego rozruchu BIOS i uruchamianie Debiana z dysku SSD.
• Memtest86+ – narzędzie do sprawdzania poprawności działania pamięci RAM.
• Tint – niewielką grę przypominającą Tetrisa, działającą bezpośrednio jako payload.
• Coreinfo – program wyświetlający informacje o sprzęcie i środowisku Coreboota.
• NVRAMCUI – tekstowy interfejs umożliwiający przeglądanie oraz zmianę dostępnych ustawień CMOS.

Po pierwszej instalacji rozszerzonej konfiguracji SeaBIOS uruchamiał Debiana bez problemów. Działały również Memtest86+ i Tint. Dwa pozostałe payloady zachowywały się jednak inaczej.

Po wybraniu Coreinfo otrzymywałem czarny ekran. Z kolei NVRAMCUI wyświetlał komunikat o rozpoczęciu uruchamiania, po czym pojawiały się nieprawidłowe znaki w górnej części ekranu. Nie widziałem właściwego interfejsu konfiguracji CMOS.

Ponieważ sam Coreboot poprawnie inicjalizował procesor Q9100, pamięć RAM i grafikę Intel, nie wyglądało to na problem dotyczący podstawowego działania platformy. Postanowiłem więc sprawdzić konfigurację dodatkowych payloadów.

Coreinfo i NVRAMCUI – diagnostyka libpayload oraz konsoli VGA

Pierwszym podejrzanym była biblioteka libpayload, czyli zestaw funkcji umożliwiających programom uruchamianym przez Coreboota korzystanie między innymi z konsoli, klawiatury i wybranych zasobów sprzętowych.

Coreinfo i NVRAMCUI wykorzystują libpayload, ale niekoniecznie z identyczną konfiguracją. Dlatego w środowisku WSL sprawdziłem pliki konfiguracyjne znajdujące się w drzewie źródeł Coreboota.

payloads/coreinfo/.lp.config
payloads/nvramcui/.lp.config
payloads/libpayload/.config

W obu konfiguracjach były włączone mechanizmy wyświetlania obrazu przez VGA oraz konsolę framebuffer Coreboota:

CONFIG_LP_VIDEO_CONSOLE=y
CONFIG_LP_VGA_VIDEO_CONSOLE=y
CONFIG_LP_COREBOOT_VIDEO_CONSOLE=y

Aktywna była również obsługa konsoli szeregowej i klawiatury PC. Istniała natomiast różnica dotycząca biblioteki odpowiedzialnej za tekstowy interfejs użytkownika.

Coreinfo korzystał z TinyCurses:

CONFIG_LP_TINYCURSES=y

NVRAMCUI używał PDCurses:

CONFIG_LP_PDCURSES=y

Początkowo podejrzewałem, że problem wynika z nieprawidłowego wyboru konsoli albo konfliktu pomiędzy VGA text mode a framebufferem. W głównej konfiguracji Coreboota miałem bowiem aktywny klasyczny tryb tekstowy:

CONFIG_MAINBOARD_USE_LIBGFXINIT=y
CONFIG_VGA_TEXT_FRAMEBUFFER=y
CONFIG_SEABIOS_VGA_COREBOOT=y

Co ważne, SeaBIOS, Tint i Memtest86+ działały w tej konfiguracji prawidłowo. Nie chciałem więc przełączać całego firmware na graficzny framebuffer tylko po to, aby naprawić dwa programy.

Ostatecznie okazało się, że nie musiałem zmieniać ustawień VGA ani przebudowywać libpayload z inną obsługą konsoli. Dalsza analiza doprowadziła mnie do konfiguracji CMOS. Był to znacznie bardziej obiecujący kierunek, szczególnie w przypadku NVRAMCUI.

Dlaczego NVRAMCUI nie działał? Problem z CONFIG_USE_OPTION_TABLE

NVRAMCUI nie jest zwykłym programem wyświetlającym tekst na ekranie. Musi otrzymać informacje o dostępnych ustawieniach firmware, ich nazwach, położeniu w CMOS oraz dozwolonych wartościach.

Podczas analizy konfiguracji mojego Coreboota znalazłem następujące ustawienia:

CONFIG_OPTION_BACKEND_NONE=y
# CONFIG_USE_OPTION_TABLE is not set
CONFIG_HAVE_OPTION_TABLE=y

Oznaczało to, że płyta główna obsługuje tablicę opcji CMOS, ale w przygotowanej kompilacji nie był aktywny backend pozwalający korzystać z tych ustawień podczas działania firmware.

Co ciekawe, odpowiedni plik konfiguracyjny znajdował się w źródłach:

src/mainboard/lenovo/t400/cmos.layout

W obrazie Coreboota był również obecny wygenerowany plik:

cmos_layout.bin

Sprawdziłem to narzędziem cbfstool:

build/cbfstool build/coreboot.rom print

Obecność tablicy w systemie plików CBFS nie oznacza jednak automatycznie, że zostanie ona udostępniona uruchamianemu payloadowi.

Potwierdzenie znalazłem bezpośrednio w kodzie źródłowym Coreboota, w pliku:

src/lib/coreboot_table.c

Fragment odpowiedzialny za kopiowanie tablicy CMOS do struktur informacyjnych Coreboota jest warunkowany przez:

#if CONFIG(USE_OPTION_TABLE)

Wewnątrz tego bloku następuje odczyt:

cbfs_map("cmos_layout.bin", NULL);

Oznacza to, że przy wyłączonym USE_OPTION_TABLE tablica nie jest przekazywana do struktur, z których może korzystać NVRAMCUI. Sam program w swoim kodzie próbuje pobrać tablicę opcji i nie może prawidłowo kontynuować pracy, jeśli jej nie otrzyma.

Była to pierwsza konkretna przyczyna, którą mogłem wskazać na podstawie kodu, a nie przypuszczeń dotyczących wyświetlania obrazu.

Konfiguracja CMOS w Lenovo ThinkPad T400 – cmos.layout i cmos.default

Przed włączeniem obsługi CMOS sprawdziłem dokładnie, jakie ustawienia udostępnia konfiguracja Lenovo T400. Było to szczególnie istotne, ponieważ niektóre opcje wpływają bezpośrednio na sposób pracy sprzętu.

W pliku cmos.layout zdefiniowano między innymi tryb SATA, konfigurację grafiki, przydział pamięci UMA, ustawienia kontrolera EC, komunikacji bezprzewodowej i urządzeń wskazujących.

Przykładowe pozycje wyglądały następująco:

408 1 e 10 sata_mode
414 1 e 1 wlan
415 1 e 1 trackpoint
952 2 e 12 hybrid_graphics_mode
954 4 e 11 gfx_uma_size

Szczególną uwagę zwróciłem na sata_mode oraz hybrid_graphics_mode. Mój ThinkPad T400 ma zintegrowaną grafikę Intel GMA 4500MHD i korzysta z dysku SSD pracującego w trybie AHCI. Nie chciałem, aby po zmianie konfiguracji Coreboota przypadkowo aktywował się niewłaściwy tryb grafiki albo kontrolera SATA.

Oprócz cmos.layout w katalogu płyty znajdował się również plik:

src/mainboard/lenovo/t400/cmos.default

Jego zawartość okazała się zwykłym tekstem opisującym domyślne ustawienia CMOS. Wśród nich znajdowały się:

boot_option=Fallback
debug_level=Debug
sata_mode=AHCI
hybrid_graphics_mode=Integrated Only
gfx_uma_size=32M
trackpoint=Enable
wlan=Enable

Były to wartości odpowiednie dla mojego egzemplarza T400. Trzeba jednak odróżnić tekstowy plik źródłowy od binarnego obrazu CMOS wykorzystywanego w pamięci SPI. Coreboot podczas kompilacji przekształca ustawienia domyślne do odpowiedniej postaci binarnej.

Nie można również zakładać, że aktualna zawartość fizycznej pamięci CMOS jest taka sama jak wartości opisane w pliku źródłowym. Właśnie dlatego przed zmianą firmware wykonałem osobny zrzut CMOS z działającego laptopa.

Włączenie USE_OPTION_TABLE i kontrola nowej kompilacji Coreboota

Po wykonaniu kopii dotychczasowego ROM-u oraz pliku .config zmieniłem backend opcji w make menuconfig. Zamiast konfiguracji bez aktywnego backendu wybrałem korzystanie z CMOS.

Najważniejsza zmiana wyglądała następująco:

# CONFIG_OPTION_BACKEND_NONE is not set
CONFIG_USE_OPTION_TABLE=y
# CONFIG_STATIC_OPTION_TABLE is not set

Ostatnia linia jest szczególnie istotna. Nie chciałem wymuszać odtwarzania wartości domyślnych przy każdym uruchomieniu. Zależało mi na aktywowaniu mechanizmu konfiguracji CMOS i zachowaniu możliwości normalnego zapisywania ustawień.

Porównałem również nową konfigurację z wcześniejszą wersją za pomocą polecenia diff. Dzięki temu potwierdziłem, że nie zmieniłem przy okazji ustawień procesora, inicjalizacji grafiki, SeaBIOS ani dodatkowych payloadów.

Następnie uruchomiłem kompilację:

make -j4

Po jej zakończeniu otrzymałem komunikat:

Built lenovo/t400 (ThinkPad T400)

Nowy obraz zawierał już wszystkie wymagane elementy:

cmos.default 256
cmos_layout.bin 1840
img/nvramcui 51057

W przeciwieństwie do poprzedniego ROM-u tym razem w CBFS znajdował się także binarny cmos.default. Przed flashowaniem wyodrębniłem go za pomocą cbfstool i sprawdziłem jego zawartość narzędziem nvramtool.

build/cbfstool build/coreboot.rom extract -n cmos.default -f /tmp/t400_cmos_default.bin

build/util/nvramtool/nvramtool -y src/mainboard/lenovo/t400/cmos.layout -D /tmp/t400_cmos_default.bin -a

Odczyt potwierdził obecność prawidłowych ustawień AHCI, Integrated Only, 32M UMA i pozostałych wartości domyślnych. Cała analiza odbywała się na pliku w WSL, bez dostępu do fizycznej pamięci CMOS laptopa.

Jak Coreboot przywraca ustawienia CMOS podczas uruchamiania?

Kolejnym etapem było sprawdzenie, co stanie się z ustawieniami zapisanymi w laptopie po aktywowaniu USE_OPTION_TABLE. Nie mogłem zakładać, że dotychczasowa zawartość CMOS jest poprawna, ponieważ wcześniejszy firmware nie korzystał z tego backendu.

W źródłach Coreboota znalazłem funkcję sanitize_cmos(), która odpowiada za kontrolę poprawności danych CMOS i ich ewentualne odtworzenie.

W pliku:

src/drivers/pc80/rtc/option.c

znajduje się warunek uwzględniający STATIC_OPTION_TABLE, błąd CMOS oraz poprawność sumy kontrolnej:

CONFIG(STATIC_OPTION_TABLE) || cmos_error() || !cmos_lb_cks_valid()

Jeżeli zachodzą odpowiednie warunki, Coreboot może odczytać cmos.default z CBFS i przywrócić objęty kontrolą fragment pamięci CMOS wraz z zapisaną sumą kontrolną. Mechanizm uwzględnia również wybudzanie z S3, podczas którego nie powinno dochodzić do niepotrzebnego resetowania ustawień.

Sprawdziłem także miejsce wywoływania tej funkcji. W mojej wersji źródeł znajduje się ono w pliku:

src/lib/bootblock.c

Najważniejszy fragment ma postać:

bootblock_soc_early_init();
bootblock_mainboard_early_init();
if (CONFIG(USE_OPTION_TABLE))
sanitize_cmos();

Oznacza to, że kontrola CMOS odbywa się bardzo wcześnie, podczas działania bootblocka, przed dalszą inicjalizacją większości elementów platformy.

Była to ważna informacja. Zależało mi, aby w przypadku wykrycia nieprawidłowej sumy kontrolnej firmware mógł odtworzyć ustawienia jeszcze przed etapami, na których są one potrzebne do konfiguracji sprzętu.

Kopia fizycznego CMOS i bezpieczna aktualizacja regionu BIOS

Przed wgraniem nowego Coreboota wykonałem kopię rzeczywistej zawartości CMOS ThinkPada. W Debianie 13 narzędzie nvramtool jest dostępne w pakiecie coreboot-utils, a w moim systemie znajdowało się pod ścieżką:

/usr/sbin/nvramtool

Do utworzenia kopii wykorzystałem:

sudo /usr/sbin/nvramtool -b "$HOME/t400_cmos_before_options.bin"

Powstał plik o rozmiarze 256 bajtów. Następnie przeniosłem go na komputer z WSL i odczytałem z wykorzystaniem cmos.layout.

Wynik ujawnił nieprawidłową sumę kontrolną oraz wiele ustawień innych niż domyślne. Przykładowo WLAN i TrackPoint były w odczytanym obrazie wyłączone, a gfx_uma_size miało nieprawidłową wartość 0x0. Nie przeszkadzało to wcześniej w uruchamianiu T400, ponieważ dotychczasowy Coreboot korzystał z konfiguracji bez aktywnego backendu opcji CMOS.

Po weryfikacji nowej kompilacji przygotowałem kompletny obraz pamięci SPI o rozmiarze 8 MB. Zachowałem pierwsze 6 MB z oryginalnego zrzutu Lenovo, obejmujące między innymi Intel Flash Descriptor, Intel ME i GbE, natomiast ostatnie 2 MB pochodziły z nowej kompilacji Coreboota.

Ostateczny obraz miał rozmiar 8388608 bajtów, a jego suma SHA-256 wynosiła:

d00055b3cd26cb3c38114ac53ddcb160c97d14b4b7f5fe09dacb0477855db388

Przed wgraniem porównałem pierwsze 6 MB z oryginalnym zrzutem oraz ostatnie 2 MB z nowym build/coreboot.rom. Oba porównania zakończyły się powodzeniem.

Aktualizację przeprowadziłem wewnętrznie przez flashrom, zapisując wyłącznie region BIOS o adresach od 0x600000 do 0x7FFFFF. Nie zmieniałem obszarów Intel ME, GbE ani deskryptora SPI. Taka metoda była wcześniej sprawdzona na tym konkretnym egzemplarzu T400, dlatego nie wymagała ponownego wylutowywania pamięci Macronix MX25L6405D.

Podkreślam, że nie jest to uniwersalny układ regionów dla wszystkich komputerów. Przed aktualizacją firmware zawsze trzeba sprawdzić rozkład pamięci SPI, wykonać niezależny backup i upewnić się, że istnieje realna możliwość przywrócenia poprzedniego obrazu.

Coreinfo i NVRAMCUI po aktualizacji – wszystkie payloady działają

Po poprawnym flashowaniu i ponownym uruchomieniu ThinkPada przyszedł czas na najważniejszy test. SeaBIOS wystartował prawidłowo, a Debian 13 uruchomił się bez problemów. Następnie sprawdziłem dodatkowe payloady.

Tym razem NVRAMCUI wyświetlił pełny interfejs ustawień CMOS. Program pozwalał przeglądać konfigurację zamiast pokazywać nieprawidłowe znaki. Co jeszcze ciekawsze, poprawnie uruchomił się również Coreinfo, który wcześniej kończył się czarnym ekranem.

Nie musiałem zmieniać ustawień VGA text mode ani konfiguracji bibliotek TinyCurses i PDCurses. W praktyce wszystkie payloady zaczęły działać po aktywowaniu USE_OPTION_TABLE, dodaniu właściwych danych CMOS i przebudowaniu firmware.

W przypadku NVRAMCUI związek z tablicą opcji jest dobrze uzasadniony analizą kodu źródłowego. Program wymaga dostępu do konfiguracji CMOS, a wcześniejsza kompilacja Coreboota nie udostępniała jej w wymagany sposób.

Nie mogę natomiast jednoznacznie stwierdzić, że dokładnie ten sam mechanizm odpowiadał za czarny ekran Coreinfo. Jego poprawne działanie po aktualizacji jest faktem potwierdzonym testem, ale nie wyizolowałem osobnej zmiany, która pozwalałaby wskazać przyczynę z całkowitą pewnością.

Na tym etapie mogłem już uznać, że konfiguracja dodatkowych payloadów została doprowadzona do oczekiwanego stanu. Pozostał jednak problem, który ujawnił się dopiero podczas kontroli CMOS z poziomu Debiana.

CMOS checksum is bad – dlaczego suma kontrolna nadal była nieprawidłowa?

Po uruchomieniu nowego Coreboota sprawdziłem ustawienia za pomocą narzędzia nvramtool:

sudo /usr/sbin/nvramtool -a

Wszystkie najważniejsze wartości wyglądały prawidłowo. SATA pracowało w trybie AHCI, grafika była ustawiona na Integrated Only, a TrackPoint i WLAN były włączone. Mimo to pod listą ustawień pojawiał się komunikat:

nvramtool: Warning: coreboot CMOS checksum is bad.

Program pokazywał również dwie różne wartości:

Computed checksum: 0x16f
Stored checksum: 0x14f

Było to interesujące, ponieważ wcześniej, przed aktywowaniem USE_OPTION_TABLE, również widziałem różnicę wynoszącą dokładnie 0x20:

Computed checksum: 0x20
Stored checksum: 0x0

Zacząłem więc analizować, skąd bierze się ta powtarzająca się wartość. Najpierw sprawdziłem sumę kontrolną przygotowanego obrazu cmos.default, odczytanego wcześniej z nowego ROM-u.

build/util/nvramtool/nvramtool -y src/mainboard/lenovo/t400/cmos.layout -D /tmp/t400_cmos_default.bin -c

Otrzymałem:

0x14f

Dokładnie taką samą wartość, jaka była zapisana w CMOS laptopa. Wskazywało to, że Coreboot najprawdopodobniej poprawnie przywrócił domyślny obraz, ale później jeden z bajtów objętych sumą kontrolną uległ zmianie.

Bajt stulecia RTC 0x32 – źródło różnicy 0x20 w sumie CMOS

Przełomem okazała się ponowna analiza pliku cmos.layout dla ThinkPada T400. Wśród jego wpisów znalazłem następujący komentarz:

#400 8 r 0 reserved for century byte

Wartość 400 oznacza tutaj pozycję w bitach, czyli bajt numer 50, odpowiadający adresowi 0x32 w pamięci CMOS. Jest to dobrze znany rejestr stulecia zegara RTC, wykorzystywany do przechowywania informacji o stuleciu w zapisie BCD.

Dla roku 2026 wartością stulecia jest 0x20, odpowiadające liczbie 20 zapisanej w BCD.

Następnie sprawdziłem definicję zakresu sumy kontrolnej w tym samym pliku:

checksum 392 983 984

Zapis oznacza, że suma kontrolna obejmuje obszar zaczynający się od bitu 392 i kończący na bicie 983, a jej wynik jest przechowywany od bitu 984. W przeliczeniu na bajty kontrolowany obszar obejmuje adresy od 49 do 122.

Bajt stulecia 0x32, czyli bajt numer 50, znajduje się wewnątrz tego zakresu. Komentarz informujący o rezerwacji pola nie wyklucza go automatycznie z obliczania sumy.

Aby sprawdzić hipotezę, ponownie wykonałem kopię CMOS na T400:

sudo /usr/sbin/nvramtool -b "$HOME/t400_cmos_now.bin"

Następnie odczytałem bezpośrednio jeden bajt z zapisanego pliku:

od -An -tx1 -j 50 -N 1 ~/t400_cmos_now.bin

Wynik był następujący:

20

Wszystkie wartości zaczęły do siebie pasować. W domyślnym obrazie CMOS zapisano sumę 0x14F, natomiast aktualna zawartość pamięci dawała 0x16F. Różnica 0x20 dokładnie odpowiadała wartości znajdującej się w rejestrze stulecia RTC.

To mocna przesłanka, że po przywróceniu ustawień domyślnych wartość bajtu stulecia została ustawiona na 0x20, przez co suma kontrolna przestała odpowiadać bieżącej zawartości CMOS. Nie przechwyciłem jednak operacji zapisu tego bajtu w chwili jej wykonywania, dlatego traktuję ten mechanizm jako najlepiej uzasadnione wyjaśnienie, a nie bezpośrednio zaobserwowaną sekwencję operacji.

Warto również zaznaczyć, że sam zegar RTC działał prawidłowo. Problem dotyczył spójności zakresu objętego sumą kontrolną, a nie koniecznie uszkodzenia pamięci CMOS lub kontrolera zegara.

Naprawa sumy kontrolnej CMOS za pomocą nvramtool bez ponownego flashowania

Skoro miałem już poprawne ustawienia i działający Coreboot, nie chciałem przebudowywać firmware tylko po to, aby usunąć ostrzeżenie dotyczące sumy kontrolnej. Zdecydowałem się na kontrolowane przeliczenie i zapis sumy przez nvramtool.

Przed operacją miałem zabezpieczony wcześniejszy zrzut CMOS, a aktualne ustawienia były prawidłowo odczytywane. Wykorzystałem więc zapis istniejącej już wartości debug_level:

sudo /usr/sbin/nvramtool -w debug_level=Debug

Nie zmieniałem w ten sposób poziomu logowania, ponieważ Debug był już aktywny. Operacja zapisu ustawienia spowodowała natomiast ponowne obliczenie i zapis sumy kontrolnej CMOS.

Następnie wykonałem:

sudo /usr/sbin/nvramtool -c

Otrzymałem:

0x16f

Ponowny odczyt ustawień:

sudo /usr/sbin/nvramtool -a

nie wyświetlał już ostrzeżenia o błędnej sumie kontrolnej. Wszystkie ważne ustawienia, w tym AHCI, Integrated Only, 32M UMA i obsługa TrackPointa, pozostawały bez zmian.

To jednak nie był jeszcze koniec testów. Chciałem sprawdzić, czy poprawiona suma przetrwa ponowne uruchomienie laptopa. Wykonałem więc zwykły restart T400, a po ponownym zalogowaniu do Debiana jeszcze raz uruchomiłem nvramtool.

Wynik był pozytywny. Program odczytał ustawienia bez ostrzeżenia o błędnej sumie kontrolnej. Oznacza to, że w przetestowanym scenariuszu korekta została zachowana po restarcie.

Nie musiałem ponownie flashować pamięci SPI, modyfikować cmos.layout ani zmieniać konfiguracji Coreboota. Wystarczył jeden kontrolowany zapis ustawienia CMOS i ponowna weryfikacja.

Warto przy tym pamiętać, że taki zabieg nie zmienia definicji zakresu sumy kontrolnej zapisanej w źródłach firmware. Jeśli w przyszłości bajt stulecia lub inne dane objęte kontrolą zostaną zmodyfikowane bez aktualizacji sumy, ostrzeżenie może powrócić. Trwałe rozwiązanie na poziomie projektu firmware wymagałoby osobnej analizy sposobu rozmieszczenia ustawień i zakresu kontrolowanych bajtów.

Coreboot w ThinkPadzie T400 po poprawkach – finalne wyniki

Po zakończeniu diagnostyki uzyskałem działającą konfigurację Coreboota, w której SeaBIOS poprawnie uruchamia Debiana 13, a wszystkie dodatkowe payloady są dostępne z menu firmware.

Element	Wynik po poprawkach
SeaBIOS 1.17.0	Działa
Tint	Działa
Memtest86+	Działa
Coreinfo	Działa
NVRAMCUI	Działa
CONFIG_USE_OPTION_TABLE	Włączone
cmos_layout.bin	Obecny w CBFS
cmos.default	Obecny w CBFS
Suma kontrolna CMOS	Poprawna po korekcie i restarcie
Intel Core 2 Quad Q9100	Cztery aktywne rdzenie
Debian 13 Trixie	Uruchamia się prawidłowo

Co ważne, nie była potrzebna zmiana ustawień grafiki ani modyfikowanie obszarów Intel ME i GbE. Aktualizacja dotyczyła wyłącznie regionu BIOS i konfiguracji obsługi opcji CMOS.

Projekt pokazał mi też, dlaczego przy pracy z Corebootem warto analizować jego kod źródłowy. Początkowo czarny ekran Coreinfo i nieprawidłowy interfejs NVRAMCUI sugerowały problem z obsługą konsoli. Dopiero sprawdzenie konfiguracji, struktur przekazywanych payloadom i mechanizmu CMOS pozwoliło znaleźć rzeczywistą przeszkodę dotyczącą NVRAMCUI. Z kolei pozornie drobne ostrzeżenie o sumie kontrolnej doprowadziło do analizy rejestru stulecia RTC oraz sposobu, w jaki firmware zabezpiecza ustawienia.

Nie traktuję tej modernizacji jako uniwersalnej recepty dla wszystkich komputerów z Corebootem. Poszczególne płyty mają różne definicje CMOS, inne backendy ustawień i odmienne mechanizmy inicjalizacji. Nawet w obrębie jednego modelu warto sprawdzać rzeczywistą konfigurację i wersję źródeł, zamiast bezrefleksyjnie kopiować cudze ustawienia.

W moim ThinkPadzie T400 efektem końcowym jest jednak w pełni funkcjonalne środowisko firmware, które obsługuje czterordzeniowego Intel Core 2 Quad Q9100, umożliwia uruchamianie narzędzi diagnostycznych bez systemu operacyjnego i udostępnia działający interfejs konfiguracji CMOS.

Największą satysfakcję daje mi to, że nie musiałem rezygnować z żadnego z planowanych payloadów. Coreinfo, NVRAMCUI, Memtest86+ i Tint działają, SeaBIOS uruchamia Debiana, a po ostatniej korekcie również suma kontrolna CMOS pozostaje poprawna po restarcie. To kolejny etap udanej modernizacji osiemnastoletniego ThinkPada, w którym równie ważne jak wydajność procesora okazało się zrozumienie sposobu działania całego firmware.