Dlaczego druga wersja naszego narzędzia do flashowania działała na Linuksie

Narzędzia produkcyjne to też oprogramowanie — i zwykle projektuje się je na samym końcu. Produkt dostaje przeglądy architektury, standardy kodowania i plan testów. Narzędzie, które zapisuje firmware do każdego egzemplarza opuszczającego fabrykę, dostaje tyle czasu, ile zostanie.

A leży ono na ścieżce krytycznej każdej wyprodukowanej sztuki. Jeśli działa wolno, wolno działa cała linia. Jeśli jest niestabilne, pojawiają się fałszywe błędy wyglądające jak usterki sprzętowe — i operator, który przestaje ufać stanowisku.

W Samsungu pracowałem nad dwiema generacjami takiego narzędzia: zapisywało ono obrazy do pamięci eMMC na płytach głównych telewizorów Smart TV. Najciekawsze nie jest jednak samo narzędzie, a to, dlaczego druga wersja porzuciła fundament pierwszej.

Pierwsza wersja działała na bare metal — i miało to sens

Pierwsza wersja działała na bare metal i była to decyzja uzasadniona. Do pamięci trzeba sięgnąć bardzo wcześnie, zanim istnieje cokolwiek przypominające system operacyjny. Bare metal daje mały plik wynikowy, szybki start, brak zależności do utrzymywania i pełną kontrolę nad czasem wykonania. Narzędzie działało i faktycznie usprawniło proces, dla którego je zbudowano.

Koszty przychodzą później i nie objawiają się jako jedna spektakularna awaria. Przychodzą jako powolny podatek:

Każdy sterownik jest twój. Kontroler eMMC, warstwa transportowa, kwestie timingu — to twój kod, a co ważniejsze, twoja errata.
Nie ma systemu plików. Obrazy są przesunięciami na nośniku, nie plikami. Narzędzie musi znać układ pamięci, więc zmiana zestawu obrazów oznacza zmianę narzędzia.
Każda zmiana sprzętu ląduje na twoim biurku. Nowa rewizja płytki albo pamięć eMMC od alternatywnego dostawcy staje się projektem sterownikowym — w kodzie, który czytał wyłącznie twój zespół, bez upstreamu, z którym można skonfrontować obserwacje.
Diagnostyka to tylko to, co sam zbudowałeś. Żadnego shella, żadnych logów, żadnych standardowych narzędzi — jedynie te mechanizmy, o których pomyślałeś, zanim okazały się potrzebne.

Żaden z tych punktów nie jest argumentem przeciw bare metal jako takiemu. To argumenty o tym, gdzie z czasem przenosi się praca, a to inne pytanie niż „co najszybciej postawić na nogi”.

Druga wersja: jądro Linuksa i świadomie mała przestrzeń użytkownika

Drugą wersję — RomWriter — zaprojektowałem wokół jądra Linuksa z minimalną przestrzenią użytkownika i kierowałem zespołem, który ją zbudował.

Ujęte jako wymiana, po stronie zysków:

Stosy MMC i USB przetestowane przez tysiące innych produktów. Pamięć od drugiego dostawcy zwykle staje się zmianą konfiguracji, a nie śledztwem w sterowniku. Dziedziczysz cudze poprawki, zamiast samodzielnie odkrywać cudze błędy.
Prawdziwy system plików. Obrazy stają się plikami. Narzędzie przestaje musieć wiedzieć, co jest w zestawie obrazów, co rozdziela dwie rzeczy, które nie miały powodu być ze sobą powiązane.
Zwykła diagnostyka. Shell, logi jądra, standardowe narzędzia. Kiedy coś zachowuje się dziwnie o trzeciej w nocy na linii produkcyjnej, różnica między „podłącz debugger, który sam napisałeś” a „przeczytaj log” to różnica między straconą a uratowaną zmianą.

I po stronie kosztów, uczciwie:

Czas startu. Inicjalizacja jądra nie jest darmowa, a na stanowisku wykonującym tysiące cykli czas rozruchu to budżet przepustowości, nie szczegół.
Rozmiar obrazu. Znacznie większy niż plik wynikowy bare metal.
Konfiguracja jądra do utrzymywania. Wymieniłeś utrzymywanie sterowników na utrzymywanie konfiguracji. Zwykle to dobra wymiana, ale nie jest darmowa.

Dyscypliną, która sprawia, że to działa, jest utrzymanie przestrzeni użytkownika naprawdę minimalną. Scenariusz porażki jest oczywisty po fakcie: rozluźnij to ograniczenie i nie zbudowałeś narzędzia do flashowania, tylko małą dystrybucję Linuksa — i teraz utrzymujesz dystrybucję.

Druga połowa układanki: niech płytka sama się rozpozna

Równolegle zintegrowałem obsługę USB 2.0 Mass Storage i systemu plików FAT w bootloaderze telewizora, tak aby płytka mogła sama rozpoznać się i wybrać właściwy dla siebie obraz.

Brzmi to jak drobne udogodnienie. W rzeczywistości jest to ciekawsza zmiana projektowa, bo przenosi decyzję tam, gdzie informacja już jest. Wcześniej coś poza płytką — konfiguracja stanowiska albo operator — musiało wiedzieć, który obraz należy do którego sprzętu. To kategoria błędu, której nie eliminuje żadna staranność, bo zależy od tego, czy ludzie i konfiguracja pozostaną zgodni z rewizją płytki, której nie widzą.

Kiedy płytka sama się rozpoznaje i wybiera, awaria „właściwa płytka, zły obraz” przestaje być możliwa, a nie tylko staje się mniej prawdopodobna. To bardzo różne gwarancje.

Co z tego zostaje na przyszłość

Cztery rzeczy, które zabrałbym do dowolnego projektu sprzętowego:

Produkcja jest środowiskiem docelowym. Zasługuje na taką samą uwagę architektoniczną jak produkt. Ma wymagania, budżety przepustowości, tryby awarii i użytkowników.
„Wszystko jest nasze” to koszt, nie tylko zaleta. Posiadanie kodu oznacza posiadanie jego erraty. Korzystaj z gotowych rozwiązań tam, gdzie zostały porządnie przetestowane przez innych na dużą skalę.
Przenoś rozpoznanie do tego, co ma być rozpoznane. Wybieraj projekty, w których awaria staje się niemożliwa, a nie takie, w których staje się nieprawdopodobna.
Wracaj do fundamentów, gdy podatek staje się widoczny. Pierwsza wersja nie była błędem. Była słuszna w świetle tego, co wiedzieliśmy wtedy — a jej przepisanie było słuszne w świetle tego, co wiedzieliśmy później.

Punkt drugi budzi najwięcej oporu, zwykle odruchowo, a nie na podstawie analizy. Bare metal wydaje się rygorystyczny. Czasem faktycznie jest. Ale „kontrolujemy wszystko” i „utrzymujemy wszystko” to to samo zdanie — a tylko jedno z nich trafia do planu.

Jeśli prowadzisz produkt od prototypu w stronę linii produkcyjnej, a kwestia narzędzi produkcyjnych jest wciąż nierozstrzygnięta — właśnie tym się zajmuję albo napisz do mnie.