Coreboot w Lenovo ThinkPad T400 – dump BIOS-u, programowanie SPI i instalacja SeaBIOS

Coreboot w Lenovo ThinkPad T400 to jeden z tych projektów, które z pozoru wyglądają dość prosto: przygotować obraz firmware, zaprogramować pamięć SPI i uruchomić komputer. W praktyce najwięcej czasu zajmują zwykle nie same polecenia w terminalu, lecz dostęp do kości BIOS-u, wykonanie pewnego dumpu, znalezienie działającego sposobu programowania oraz upewnienie się, że w gotowym obrazie nie uszkodziliśmy regionów Intel Management Engine, GbE czy Flash Descriptor. W moim przypadku cała operacja zajęła około czterech godzin i wymagała między innymi wylutowania pamięci SPI z płyty głównej.

Bohaterem projektu jest Lenovo ThinkPad T400, Machine Type 6474-D8B. Laptop ma chipset Intel GM45, zintegrowaną grafikę Intel GMA 4500MHD i na tym etapie nadal pracował z oryginalnym procesorem Intel Core 2 Duo P8400. Coreboot nie był jednak celem samym w sobie. To pierwszy etap większego projektu, którego dalszą częścią będzie uruchomienie w T400 czterordzeniowego Core 2 Quad Q9100.

Zanim jednak zacząłem modyfikować sprzęt, chciałem przygotować pewną bazę i upewnić się, że sam Coreboot działa poprawnie na fabrycznej konfiguracji procesora.

Dlaczego Coreboot w ThinkPadzie T400?

ThinkPad T400 należy do generacji komputerów, która jest bardzo wdzięczna do eksperymentów z alternatywnym firmware. Platforma Intel GM45 jest od dawna obsługiwana przez Coreboot, a sam T400 jest jednym z lepiej poznanych modeli z tej epoki.

W moim przypadku dodatkową motywacją była planowana instalacja procesora Core 2 Quad. T400 fabrycznie nie był oferowany z czterordzeniowymi jednostkami Penryn, dlatego taki upgrade wymaga zarówno modyfikacji sprzętowej, jak i firmware, które będzie potrafiło poprawnie zainicjalizować nietypową konfigurację.

Nie chciałem jednak wykonywać wszystkiego naraz. Najbezpieczniejszy scenariusz wygląda następująco: najpierw Coreboot na oryginalnym P8400, później modyfikacja GTLREF i ponowny test nadal na P8400, a dopiero na końcu instalacja Q9100. Dzięki temu w przypadku problemów wiadomo, na którym etapie zostały wprowadzone.

Przed rozpoczęciem prac T400 miał już zaktualizowany oficjalny BIOS Lenovo do wersji 3.24 oraz Embedded Controller 1.06. Sam EC pozostaje przy tej operacji osobnym firmware i nie jest zastępowany przez Coreboot.

Pamięć BIOS w Lenovo ThinkPad T400

Po rozebraniu laptopa okazało się, że zastosowana pamięć SPI to Macronix:

MX25L6405DMI-12G

Jest to pamięć 64 Mbit, czyli dokładnie:

8 MiB
8 388 608 bajtów

Układ występuje tutaj w 16-nóżkowej obudowie SOP16.

Macronix MX25L6405DMI-12G Datasheet → MX25L6405D.pdf

I właśnie w tym miejscu zaczęła się pierwsza poważniejsza walka. Początkowo próbowałem wykonać odczyt bez wylutowywania pamięci, korzystając z klipsa i prostego adaptera wykonanego jako swoisty „pająk”. Samo połączenie było elektrycznie poprawne i wykorzystywało wymagane sygnały SPI: VCC, GND, CS, CLK, MOSI, MISO, WP oraz HOLD.

W praktyce programator nie był jednak w stanie stabilnie komunikować się z pamięcią zamontowaną na płycie.

To dość typowa sytuacja przy programowaniu in-circuit. Programator widzi wtedy nie tylko sam układ flash, ale również pozostałą część elektroniki podłączoną do jego linii. Rezystancje, inne układy, pojemności oraz zasilanie płyty mogą skutecznie uniemożliwić poprawny odczyt.

Po kilku próbach uznałem, że dalsza walka z klipsem nie ma sensu.

Wylutowanie MX25L6405D i programowanie przez TL866II Plus

Najbardziej ryzykowną częścią całej operacji było wylutowanie pamięci SPI. W T400 układ znajduje się w miejscu, w którym trzeba uważać między innymi na pobliskie plastikowe elementy socketów pamięci RAM.

Po wyjęciu MX25L6405D z płyty umieściłem ją w odpowiedniej przejściówce SOP16 i podłączyłem do programatora TL866II Plus.

Co ciekawe, właśnie ten programator wcześniej nie sprawdził mi się przy pracy z ThinkPadem T420. Tym razem sytuacja była odwrotna. Po fizycznym wyjęciu układu z płyty TL866II Plus komunikował się z nim bez problemu i pozwolił wykonać stabilny odczyt.

To dobra lekcja na przyszłość: nie warto automatycznie skreślać programatora tylko dlatego, że nie zadziałał w innym komputerze. Ogromne znaczenie ma sposób podłączenia kości. Bezpośrednie programowanie w adapterze daje zupełnie inne warunki niż próba dostępu do układu pracującego na płycie głównej.

Dump został wykonany w Xgpro w formacie BIN.

Dlaczego dump BIOS-u miał więcej niż 8 MiB?

Tutaj pojawiła się kolejna ciekawostka. MX25L6405D ma fizycznie 8 388 608 bajtów, natomiast zapisany przez Xgpro plik miał:

8 388 880 bajtów

czyli dokładnie 272 bajty więcej.

Na końcu pliku znajdował się również blok zawierający między innymi ciąg:

Configuration

Ponieważ fizyczna przestrzeń adresowa pamięci kończy się po 8 MiB, wszystko znajdujące się dalej nie mogło być częścią właściwej zawartości flasha. W tym przypadku dodatkowe dane zostały dopisane przez oprogramowanie podczas zapisywania pliku.

Dlatego przygotowałem czysty obraz o dokładnej długości pamięci:

head -c 8388608 MX25L6405D@16PIN.BIN > t400_stock_8mb.bin

• MX25L6405D BIOS dump → t400_stock_8mb.zip

Następnie policzyłem SHA256. Dla mojego oryginalnego obrazu T400 otrzymałem:

e83a286a3902e9a54c2b6eb77a87314444830755ce4d6eb196ba91b7c59be635

Ten plik stał się kopią referencyjną. Oryginału nie modyfikowałem później w żaden sposób.

Analiza dumpu BIOS-u za pomocą ifdtool

Zanim zacząłem budować Coreboot, chciałem dokładnie wiedzieć, jak wygląda układ pamięci mojego konkretnego T400. Do analizy wykorzystałem ifdtool dostarczany razem z Coreboot.

Oryginalny obraz został podzielony na następujące regiony:

Flash Descriptor: 0x000000 - 0x000FFF
Intel ME: 0x001000 - 0x5F5FFF
GbE: 0x5F6000 - 0x5F7FFF
Platform Data: 0x5F8000 - 0x5FFFFF
BIOS: 0x600000 - 0x7FFFFF

To bardzo ważna informacja. Cała pamięć ma 8 MiB, ale właściwy region BIOS-u zajmuje tylko ostatnie 2 MiB. Pierwsze około 6 MiB zawiera między innymi Intel Management Engine, Flash Descriptor, dane GbE oraz Platform Data.

Na tym etapie zdecydowałem, że nie będę modyfikował żadnego z tych obszarów. Nie wykonywałem me_cleaner, nie ustawiałem HAP, nie zmieniałem descriptorów i nie próbowałem odblokowywać dodatkowych regionów.

Celem pierwszego uruchomienia było zachowanie możliwie dużej części oryginalnego firmware i zastąpienie wyłącznie regionu BIOS.

Konfiguracja Coreboot dla Lenovo ThinkPad T400

Coreboot budowałem pod WSL z Ubuntu. Źródła znajdowały się w katalogu:

~/coreboot

Po przejściu do katalogu uruchomiłem konfigurator:

cd ~/coreboot
make menuconfig

Wybrałem producenta Lenovo oraz model ThinkPad T400.

Co ciekawe, po zapisaniu konfiguracji polecenie:

make savedefconfig

wygenerowało bardzo krótki plik:

CONFIG_LOCALVERSION="T400-coreboot"
CONFIG_VENDOR_LENOVO=y
CONFIG_BOARD_LENOVO_T400=y

Oznaczało to, że praktycznie wszystkie pozostałe ustawienia odpowiadały domyślnym wartościom przygotowanym przez Coreboot dla T400.

W pełnym pliku .config szczególnie istotne były:

CONFIG_ROM_SIZE=0x00800000
CONFIG_CBFS_SIZE=0x200000
CONFIG_MAINBOARD_USE_LIBGFXINIT=y
CONFIG_INTEL_GMA_ADD_VBT=y
CONFIG_PAYLOAD_SEABIOS=y
CONFIG_USE_CPU_MICROCODE_CBFS_BINS=y

Czyli fizyczny ROM ma 8 MiB, obszar Coreboot/CBFS zajmuje 2 MiB, grafika inicjalizowana jest przez libgfxinit, a jako payload zastosowany został SeaBIOS.

W konfiguracji wybrałem również klasyczny tryb VGA text mode. Na pierwszym etapie nie potrzebowałem logo, splash screena ani dodatkowych payloadów. Najważniejsza była prostota oraz możliwie niewielka liczba zmian względem domyślnej konfiguracji T400.

SeaBIOS jako payload dla Coreboot

Coreboot sam w sobie nie jest pełnym odpowiednikiem klasycznego BIOS-u z punktu widzenia systemu operacyjnego. Po wykonaniu inicjalizacji sprzętu przekazuje sterowanie do payloadu.

W tym projekcie wybrałem SeaBIOS. Dzięki temu T400 nadal może zachowywać się z punktu widzenia systemu podobnie do komputera z tradycyjnym BIOS-em. Ma to znaczenie również dlatego, że zainstalowany na SSD Debian był wcześniej uruchamiany w klasycznym trybie BIOS/GRUB.

SeaBIOS został zbudowany automatycznie podczas kompilacji Coreboot. W obrazie znalazł się również SeaVGABIOS.

Kompilację uruchomiłem poleceniem:

make -j$(nproc)

Build zakończył się poprawnie komunikatem:

Built lenovo/t400 (ThinkPad T400)

Gotowy plik coreboot.rom miał dokładnie:

8 388 608 bajtów

czyli 8 MiB.

Jak połączyłem Coreboot ze stockowym firmware T400?

Tutaj wykonałem dodatkowy krok bezpieczeństwa. Mimo że gotowy obraz Coreboot miał 8 MiB, nie chciałem bezrefleksyjnie używać całej jego zawartości. Miałem już przecież potwierdzony, działający dump oryginalnego firmware i dokładnie znałem jego podział.

Z obrazu Coreboot wyciągnąłem więc ostatnie 2 MiB:

dd if=build/coreboot.rom of=coreboot_bios_2mb.bin bs=1M skip=6 count=2

Powstały plik miał:

2 097 152 bajty

Następnie wykonałem kopię oryginalnego dumpu:

cp t400_stock_8mb.bin t400_coreboot_full_8mb.bin

i podmieniłem w niej wyłącznie ostatnie 2 MiB:

dd if=coreboot_bios_2mb.bin of=t400_coreboot_full_8mb.bin bs=1M seek=6 count=2 conv=notrunc

W efekcie powstał pełny obraz 8 MiB, w którym pierwsze 6 MiB pochodziło z oryginalnego firmware Lenovo, natomiast region BIOS od adresu 0x600000 zawierał Coreboot.

Weryfikacja obrazu przed programowaniem SPI

Przy firmware nie warto opierać się na założeniu, że „powinno być dobrze”. Skoro można coś sprawdzić binarnie, lepiej to zrobić.

Najpierw porównałem pierwsze 6 MiB oryginalnego dumpu i przygotowanego obrazu:

cmp -n 6291456 t400_stock_8mb.bin t400_coreboot_full_8mb.bin && echo "OK - pierwsze 6 MiB identyczne"

Wynik:

OK - pierwsze 6 MiB identyczne

Następnie sprawdziłem ostatnie 2 MiB:

cmp <(tail -c 2097152 t400_coreboot_full_8mb.bin) coreboot_bios_2mb.bin && echo "OK - ostatnie 2 MiB to coreboot"

Również tutaj wynik był prawidłowy:

OK - ostatnie 2 MiB to coreboot

Finalny obraz otrzymał SHA256:

407334ce77ca201687f2bfa662d139ba2ba5e5311729a449535377ff8b08cdbb

Na końcu ponownie uruchomiłem ifdtool na gotowym pliku:

~/coreboot/util/ifdtool/ifdtool -d t400_coreboot_full_8mb.bin

Układ regionów nadal wyglądał dokładnie tak samo:

Flash Descriptor: 00000000 - 00000fff
BIOS: 00600000 - 007fffff
Intel ME: 00001000 - 005f5fff
GbE: 005f6000 - 005f7fff
Platform Data: 005f8000 - 005fffff

Dopiero wtedy uznałem obraz za gotowy do programowania.

Programowanie MX25L6405D przez TL866II Plus

Do pamięci został zapisany pełny plik:

t400_coreboot_full_8mb.bin

W Xgpro format pliku ustawiłem jako BINARY, tryb ładowania jako Normal, a początek pliku i bufora na adres 0x00000.

Programowanie przebiegło prawidłowo. TL866II Plus kolejno wykonał kasowanie, zapis i weryfikację pamięci. Program poprawnie odczytał również identyfikator producenta i układu Macronix.

Po wcześniejszych problemach z programowaniem in-circuit był to moment, w którym cały proces wreszcie stał się przewidywalny.

Pozostało ponownie wlutować MX25L6405D na płytę główną. Tutaj szczególnie ważna jest prawidłowa orientacja układu. Pin 1 wskazuje charakterystyczne zagłębienie na obudowie pamięci i musi odpowiadać oznaczeniu na PCB.

Po lutowaniu warto dokładnie obejrzeć wszystkie wyprowadzenia pod powiększeniem. Wystarczy niewielki mostek między dwoma pinami, aby cały komputer odmówił uruchomienia.

Pierwszy start ThinkPada T400 z Coreboot

Pierwszy test wykonałem w absolutnie minimalnej konfiguracji.

Laptop nie miał jeszcze zamontowanego dysku, Wi-Fi, touchpada, głośników ani baterii. Podłączone były tylko elementy niezbędne do sprawdzenia POST-u: procesor Core 2 Duo P8400, pamięć RAM, klawiatura i matryca.

Po naciśnięciu przycisku Power ThinkPad T400 uruchomił się i wyświetlił obraz.

Po kilku godzinach rozbierania laptopa, walki z dostępem do pamięci SPI, nieudanych prób programowania bez jej wylutowania, budowania własnego obrazu i lutowania kości z powrotem ten moment był zdecydowanie najważniejszą częścią całej operacji.

Coreboot działa.

Na tym etapie nie interesował mnie jeszcze pełny test Debiana, Wi-Fi, audio czy zarządzania energią. Pierwszym celem było potwierdzenie, że płyta startuje, RAM jest inicjalizowany, grafika działa, a SeaBIOS przejmuje kontrolę.

I dokładnie to udało się osiągnąć.

Co dalej z ThinkPadem T400?

Instalacja Coreboot to dopiero pierwszy etap większej modernizacji tego egzemplarza.

Następny krok będzie znacznie bardziej sprzętowy. Docelowo T400 ma otrzymać czterordzeniowego Intel Core 2 Quad Q9100. Procesor ma cztery rdzenie, 12 MB pamięci L2 i TDP 45 W, dlatego projekt wymaga również odpowiedniej modyfikacji sygnału GTLREF oraz zmian przy samym procesorze.

Do tego przygotowane jest mocniejsze chłodzenie stosowane w wersjach T400 z bardziej rozbudowanym układem graficznym, a jako materiał termiczny planuję zastosować PTM7950.

Zanim jednak Q9100 trafi do socketu, T400 przejdzie pełne testy jeszcze na P8400. Następnie wykonana zostanie sama modyfikacja GTLREF i ponowny start ze starym procesorem. Dopiero gdy również ten etap zakończy się sukcesem, przyjdzie czas na cztery rdzenie.

W takich projektach warto zmieniać jedną rzecz naraz. Dzięki temu nie tylko łatwiej znaleźć ewentualny błąd, ale też znacznie lepiej rozumie się, co faktycznie dzieje się ze sprzętem.

Ten konkretny Lenovo ThinkPad T400 przeszedł już z oryginalnego BIOS-u Lenovo na samodzielnie zbudowany Coreboot z SeaBIOS, przy zachowaniu oryginalnych regionów Intel ME, GbE i Flash Descriptor. Najbardziej problematyczna okazała się nie sama kompilacja firmware, lecz fizyczny dostęp do pamięci SPI i wykonanie pewnego odczytu oraz zapisu. Ostatecznie rozwiązaniem było wylutowanie MX25L6405D i użycie TL866II Plus. Pierwszy POST zakończył się sukcesem, więc można przejść do kolejnego etapu projektu – przygotowania T400 pod Core 2 Quad.