Co naprawdę dzieje się w Raspberry Pi 4B – diagnostyka vcgencmd na czystym Bookworm Lite z 1 GB RAM
Czysty Raspberry Pi OS Lite w wydaniu Bookworm, postawiony na Raspberry Pi 4B z jednym gigabajtem pamięci, jest lekki tylko dopóty, dopóki sprzęt pracuje w swoich widełkach. System bez pulpitu nie pokazuje błyskawicy niedoboru zasilania ani nie rysuje wykresu temperatury. Jedynym szybkim oknem na firmware układu VideoCore pozostaje polecenie vcgencmd. Ten artykuł omawia, skąd się ono bierze, które odczyty mają znaczenie na płytce z 1 GB RAM i jak czytać je tak, żeby nie pomylić zwalniania procesora z brakiem pamięci albo z wolną kartą.
Dlaczego lekka baza i tak wymaga pomiaru sprzętu
Obraz Lite nie uruchamia środowiska graficznego, więc zużycie procesora w spoczynku bywa niewielkie, a temperatura często wygląda „zdrowo”, dopóki nie pojawi się kompilacja, serwer albo dłuższy zapis na kartę. Wrażenie lekkości potrafi maskować dwa problemy, które na Raspberry Pi 4B psują stabilność niezależnie od tego, jak mało pakietów doinstalowano.
Pierwszy to zasilanie. Płytka oczekuje stabilnych 5 V na wejściu. Gdy zasilacz, kabel albo złącze nie dowożą prądu, firmware obniża taktowanie i zapamiętuje ten fakt. Drugi to ciepło. Czujnik siedzi w samym układzie scalonym, nie w obudowie i nie w pomieszczeniu. Na płytce z 1 GB RAM dochodzi trzecia, osobna oś: pamięć. Jeden gigabajt szybko znika w pamięci podręcznej plików, w usłudze i w swap. vcgencmd tego trzeciego problemu nie zmierzy. Właśnie dlatego warto znać granicę narzędzia. Pokazuje ono stan, który widzi firmware, a nie to, co widzi jądro w free.
Na czystym systemie pomiar ma jeszcze jedną zaletę. Nie ma pulpitu, przeglądarki ani stosu usług, które same grzeją układ i same zjadają RAM. Odczyt zrobiony zaraz po instalacji jest linią bazową. Każde późniejsze spowolnienie można porównać z tą linią, zamiast zgadywać, czy winna jest nowa usługa, zasilacz, czy po prostu ciepło w zamkniętej obudowie.
Skąd bierze się vcgencmd na Bookworm Lite
vcgencmd nie jest programem jądra i nie czyta zwykłych plików z /proc jako głównego źródła. Rozmawia z firmware przez kanał mailbox układu graficznego. Stąd część wyników wygląda inaczej niż odczyty linuksowe i stąd część komend w ogóle nie ma odpowiednika w systemie plików.
Na aktualnym Bookworm polecenie dostarcza pakiet raspi-utils. W starszych obrazach ten sam plik przychodził z libraspberrypi-bin. Na oficjalnym obrazie Lite narzędzie zwykle już jest. Sprawdzenie jest krótkie: command -v vcgencmd powinno wskazać /usr/bin/vcgencmd. Dawna ścieżka /opt/vc/bin/vcgencmd należy do poprzedniej epoki i na świeżym Bookworm nie należy jej szukać w pierwszej kolejności.
Jeśli powłoka zgłasza brak polecenia, doinstalowanie ogranicza się do sudo apt update i sudo apt install raspi-utils. Sam pakiet jest mały i pasuje do idei lekkiej bazy. Nie dokłada pulpitu.
Uprawnienia bywają drugim progiem. Dostęp do urządzenia, przez które idzie rozmowa z firmware, ma tradycyjnie grupa video. Użytkownik założony przy pierwszym starcie obrazu zwykle do niej należy. Konto dodane później, albo sesja uruchomiona w bardzo ograniczonym kontekście, może dostać odmowę. Wtedy groups pokaże, czy brakuje video. Dopisywanie użytkownika do grupy jest zwykłą sprawą administracyjną, nie obchodzeniem zabezpieczeń. Po zmianie grupy potrzebna jest nowa sesja logowania.
Lista tego, co rozumie akurat ta para firmware i narzędzia, nie jest wyryta w kamieniu. vcgencmd commands wypisuje nazwy dostępne na tej płytce. Artykuł opisuje komendy stabilne i użyteczne na Pi 4B. Jeśli którejś nie ma na liście, nie trzeba jej wymuszać. Albo firmware jest stare, albo dana funkcja dotyczy innego modelu, na przykład odczytów przetwornika znanego szerzej z nowszych płytek.
Warto też znać format odpowiedzi, bo skrypty często się na nim wykładają. Temperatura wraca jako temp=47.8'C z apostrofem, nie ze znakiem stopnia. Zegar wraca w hercach, a liczba w nawiasie to identyfikator zegara, nie megaherce. Napięcie ma postać volt=0.8625V. Flaga dławienia ma postać throttled=0x0. Każdy z tych ciągów jest tekstem do przeczytania, nie gotową liczbą dla programu, dopóki się go nie potnie.
Temperatura układu – measure_temp i progi, które naprawdę liczy firmware
Najczęściej używana komenda to vcgencmd measure_temp. Zwraca temperaturę krzemu, nie powietrza nad płytką. Różnica ma znaczenie praktyczne. W otwartej obudowie czujnik może pokazywać nieco ponad 40°C, podczas gdy radiator jest ledwie ciepły. W szczelnej obudowie bez przewiewu ten sam czujnik dochodzi do progu dławienia, choć obudowa z zewnątrz wydaje się tylko letnia.
Odczyt warto powtórzyć w dwóch stanach. Pierwszy to spoczynek, kilka minut po starcie, bez kompilacji i bez kopiowania dużych plików. Drugi to świadome obciążenie, na przykład dłuższe liczenie albo instalacja pakietu. Sam pojedynczy strzał nic nie mówi o zapasie. Pi 4B w spoczynku na Lite często siedzi wyraźnie poniżej 50–55°C, jeśli w pomieszczeniu nie jest gorąco i jeśli zasilanie nie zmusza układu do dziwnej pracy. To orientacja, nie norma fabryczna. Liczy się trend i odległość od progu.
Progi trzyma firmware, a nie artykuł i nie „zdrowy rozsądek”. Klasyczny obraz dla tej generacji jest taki: około 80°C rdzenie ARM zaczynają być cofane w taktowaniu, a około 85°C dławienie obejmuje szerzej także część graficzną. Obok tego istnieje miększy próg, soft limit, często ustawiony niżej, historycznie w okolicy 60°C. Między miękkim a twardym progiem firmware może już obniżać częstotliwość, zanim dojdzie do twardej ochrony. Dokładne liczby na danej płytce warto potwierdzić przez vcgencmd get_config temp_limit oraz vcgencmd get_config temp_soft_limit, a nie przyjąć z pamięci. Jeśli klucz nie wraca, ta wersja firmware po prostu go nie wystawia i zostaje obserwacja zegara oraz flagi dławienia.
Bit miękkiego progu pojawia się też w vcgencmd get_throttled, o czym niżej. Sama temperatura bez tej flagi nie mówi, czy układ już zareagował. Może być 72°C i pełne taktowanie. Może być 61°C i już aktywny miękki limit, jeśli tak ustawiono konfigurację. Dlatego measure_temp czyta się razem z zegarem ARM, a nie jako osobną ciekawostkę.
Jednostka w odpowiedzi jest pułapką dla skryptów. Ciąg kończy się apostrofem i literą C. Stopień Celsjusza jest w domyśle. Porównanie tekstowe z °C zawsze się nie uda. Do ręcznej diagnostyki wystarczy odczyt okiem. Do progu alarmowego w własnym skrypcie wycina się liczbę sprzed apostrofa.
Jest też drugi, linuksowy termometr: plik strefy termicznej, zwykle /sys/class/thermal/thermal_zone0/temp, z wartością w tysięcznych stopnia. Na Pi 4B to na ogół ten sam czujnik, podany inną drogą. Zgodność co do jednego stopnia jest dobrym znakiem. Rozjazd o kilka stopni bywa kwestią chwili pomiaru, bo oba odczyty nie są atomowe. Rozjazd duży i stały jest powodem, by sprawdzić, czy nie czyta się innej strefy, a nie powodem, by uśredniać „na oko” i iść dalej.
Czego temperatura nie powie: nie wskaże, czy gorąco bierze się z napięcia, z braku radiatora, z pracy karty SD tuż pod układem, czy z usługi, która wpadła w pętlę. Na płytce z 1 GB RAM pętla usługi bywa szczególnie myląca. Proces zjada procesor, układ się grzeje, firmware obniża taktowanie, a wszystko zwalnia jeszcze bardziej. measure_temp pokaże skutek. Przyczynę w procesach pokaże już top albo ps, nie VideoCore.
Zegary i napięcia wewnętrzne – measure_clock oraz measure_volts
vcgencmd measure_clock wymaga nazwy zegara. Bez niej narzędzie nie zgaduje, o który blok chodzi. Na Pi 4B codziennie potrzebny jest przede wszystkim vcgencmd measure_clock arm. Odpowiedź w rodzaju frequency(48)=600169920 oznacza około 600 MHz. Identyfikator w nawiasie można zignorować przy czytaniu ręcznym. Herce dzieli się przez milion, gdy chce się megaherce.
Domyślny dolny bieg ARM na tej płytce to zwykle 600 MHz. Górny, przy pracy, to zwykle 1,5 GHz, o ile konfiguracja albo nowsza polityka firmware nie ustawia inaczej. Część płytek i obrazów celuje wyżej, także w 1,8 GHz. Nie warto kłócić się z pamięcią o „właściwą” liczbę. vcgencmd get_config arm_freq pokazuje częstotliwość, jaką firmware uważa za docelową, a measure_clock arm pokazuje częstotliwość w tej sekundzie. Rozjazd między nimi w spoczynku jest normalny. Rozjazd pod obciążeniem, gdy docelowe jest 1500, a pomiar uparcie siedzi przy 600, jest już objawem. Wtedy patrzy się na temperaturę i na get_throttled, a nie na „zepsuty procesor”.
Inne zegary warto znać z nazwy, nawet jeśli na serwerze bez pulpitu rzadko są winowajcą. core to zegar części wspólnej, na Pi 4 często w okolicy 500 MHz, zależnie od obciążenia i konfiguracji. v3d dotyczy bloku grafiki trójwymiarowej. h264 i pokrewne dotyczą bloków wideo. isp to blok obróbki obrazu, istotny przy kamerze. emmc wiąże się z torem pamięci masowej widzianym przez firmware. hdmi, pixel, vec, dpi, uart, pwm i hevc dopełniają mapę. Na Lite bez monitora i bez kamery większość z nich może być niska albo mało ciekawa. Mierzy się je wtedy, gdy problem dotyczy obrazu, kamery albo dziwnego zachowania portu szeregowego, a nie „wolnego SSH”.
Jedna pułapka interpretacyjna wraca przy każdym pomiarze zegara. Governor o nazwie ondemand, albo nowszy odpowiednik polityki skalowania, celowo zrzuca częstotliwość w bezczynności. Niski measure_clock arm tuż po zalogowaniu nie jest awarią. Awarią jest niski zegar wtedy, gdy układ ma pracę i gdy jednocześnie get_throttled nie jest zerem. Żeby to odróżnić, pomiar robi się w trakcie obciążenia, nie przed nim.
vcgencmd measure_volts bez argumentu, albo z argumentem core, pokazuje napięcie rdzenia, nie napięcie zasilacza. W spoczynku na Pi 4B często widać wartości rzędu 0,85–0,90 V. Pod obciążeniem firmware podnosi napięcie punktu pracy, nierzadko w okolice 1 V lub wyżej, zależnie od taktowania i od tego, czy w konfiguracji ruszano over_voltage. To napięcie wewnętrzne. Jego „ładny” odczyt nie dowodzi, że wtyczka 5 V jest zdrowa.
Osobne tory pamięci odpytuje się nazwami sdram_c, sdram_i oraz sdram_p. To odpowiednio napięcie kontrolera, części wejścia-wyjścia i części fizycznej pamięci, w przybliżeniu takie, jak wystawia zasilacz układu na płytce. Wartości kręcą się zwykle koło 1,1 V. Sam fakt, że komenda coś zwraca, potwierdza, że firmware widzi te rail’e. Drobne różnice między płytkami są normalne. Gwałtowny, niestabilny odczyt albo wartość wyraźnie poza okolicą oczekiwaną jest już powodem, by przestać podkręcać i wrócić do zasilania oraz do wersji firmware, a nie by „dokręcać” napięcie na ślepo.
Tu dochodzi najważniejsze rozróżnienie całej diagnostyki zasilania. Niedobór 5 V nie pojawia się jako niska liczba w measure_volts core. Rdzeń może mieć poprawne 0,86 V, a wejście płytki może już siadać pod obciążeniem portów USB, dysku i samego SoC. Informację o zbyt niskim napięciu wejściowym niesie get_throttled, bo wykrywa ją układ zarządzający zasilaniem i przekazuje do firmware. Na Pi 4B nie ma w vcgencmd prostego, codziennego woltomierza szyny 5 V w stylu nowszych odczytów przetwornika. Kto chce znać wolty na wtyczce, mierzy je miernikiem na pinach zasilania pod obciążeniem. Kto chce wiedzieć, czy firmware już ukarał płytkę za słabe zasilanie, czyta flagę dławienia.
Argumenty, których nie ma na danej płytce, kończą się komunikatem o złej komendzie albo o braku obsługi. To nie jest usterka systemu Lite. To granica modelu. Lista z vcgencmd commands oraz krótka próba measure_volts i measure_clock z jawną nazwą bloku wystarczają, by nie opierać diagnostyki na poradniku pisanym pod inną generację.
Flaga get_throttled – historia niedoboru prądu i przegrzania
vcgencmd get_throttled jest komendą, od której warto zaczynać, gdy płytka „czasem zwalnia”, zrywa sieć albo resetuje się pod obciążeniem. Zwraca jedną liczbę szesnastkową. Zero, zapisane jako throttled=0x0, oznacza, że firmware nie widzi ani bieżącego dławienia, ani śladu dławienia od ostatniego startu. Każda inna wartość jest tropem, nie ozdobnikiem.
Liczba jest maską bitową. Młodsze bity mówią o stanie teraz. Starsze, od bitu 16 w górę, mówią o tym, co zdarzyło się od uruchomienia, nawet jeśli w tej sekundzie jest już dobrze. To rozróżnienie ratuje diagnostykę. Pomiar zrobiony po ustąpieniu objawu nadal pokaże, że niedobór napięcia albo przegrzanie już wystąpiły.
Bit 0 oznacza wykryty w tej chwili niedobór napięcia, czyli undervoltage. Bit 1 oznacza, że częstotliwość ARM jest w tej chwili ograniczona. Bit 2 oznacza, że układ jest w tej chwili dławiony. Bit 3 oznacza, że działa miękki limit temperatury. Te cztery bity gasną, gdy warunek ustąpi. Nie są pamięcią.
Bit 16 oznacza, że niedobór napięcia już się zdarzył. Bit 17 oznacza, że ograniczanie częstotliwości ARM już się zdarzyło. Bit 18 oznacza, że dławienie już się zdarzyło. Bit 19 oznacza, że miękki limit temperatury już zadziałał. Te bity zostają do następnego restartu. Restart czyści historię. Dlatego pomiar „dla pewności” robi się po typowym obciążeniu, a nie tuż po restarcie w chłodnym pokoju i na lekkim zasilaniu biurkowym, które później i tak zostanie zamienione na słaby przewód.
Czytanie szesnastkowe nie wymaga kalkulatora, jeśli pamięta się kilka wzorców. 0x50000 to bity 16 i 18: w przeszłości był niedobór napięcia i było dławienie, a teraz jest spokój. 0x50005 dokłada bity 0 i 2: problem trwa nadal. 0x80000 to sam ślad miękkiego limitu temperatury. 0x8 to ten limit aktywny w tej chwili. Wartości mieszane, na przykład ślad niedoboru napięcia razem ze śladem temperatury, znaczą tyle, że płytka dostała dwa niezależne powody do zwolnienia. Jeden pomiar nie rozstrzyga, który był pierwszy.
Na Pi 4B próg wykrycia niedoboru leży poniżej nominalnych 5 V, w okolicy 4,63 V, po stronie układu zasilania, a nie w pliku konfiguracyjnym użytkownika. Krótki zapad, krótszy niż rzut oka na miernik, wystarczy, by zapalić bit historii. Stąd klasyczny obraz: miernik na spoczynku pokazuje 5,1 V, a get_throttled po kopiowaniu na dysk USB ma ustawiony bit 16. Winny bywa cienki kabel, słaby zasilacz „ładowarkowy”, wspólna listwa z innymi urządzeniami albo dysk, który startuje prądem znacznie wyższym niż prąd podtrzymania.
Dławienie z bitu 2 i ślad z bitu 18 nie tłumaczą się same. Mogą iść z temperatury, z napięcia, albo z obu. Dlatego flaga bez measure_temp i bez powtórzenia testu na innym zasilaczu jest tylko połową diagnozy. Praktyczny porządek jest prosty. Najpierw odczyt flagi na zimno, zaraz po starcie. Potem kilka minut realnej pracy, jakiej płytka ma służyć. Potem znowu flaga, temperatura i measure_clock arm. Jeśli bity 16 lub 18 zapaliły się przy temperaturze dalekiej od progu, pierwsze podejrzenie pada na zasilanie. Jeśli zapaliły się przy temperaturze przy progu, a napięciowe bity milczą, pierwsze podejrzenie pada na chłodzenie i obudowę.
Na systemie bez pulpitu nie pojawi się ikona błyskawicy ani termometru. Flaga jest tą ikoną. Warto ją sprawdzić zanim uzna się, że „Bookworm Lite jest wolny” albo że „1 GB RAM nie wyrabia”. Oba zdania bywają prawdziwe, ale throttling daje taki sam objaw: komendy wloką się, a obciążenie procesora wygląda nisko, bo rdzenie nie dostają pełnego zegara.
Jest też skutek uboczny, o którym łatwo zapomnieć przy jednym gigabajcie. Obniżone taktowanie wydłuża każdą kompilację i każdy backup. Dłuższa praca mocniej grzeje. Dłuższe grzanie głębiej wchodzi w limit. Karta SD jest zajęta dłużej, pamięć podręczna się nie wyrabia, pojawia się swap. Z zewnątrz wygląda to jak „za mało RAM”. Flaga dławienia pozwala rozciąć ten węzeł, zanim zacznie się dokładanie usług monitorujących, które same zjedzą brakującą pamięć.
Pamięć, podział ARM-GPU i konfiguracja widziana przez firmware
Na płytce z 1 GB RAM każdy megabajt oddany firmware graficznemu jest megabajtem zabrany procesom. vcgencmd get_mem arm oraz vcgencmd get_mem gpu pokazują podział, jaki widzi firmware. Odpowiedzi mają postać arm=...M i gpu=...M. Suma nie musi równać się dokładnie 1024. Część przestrzeni rezerwuje start i sam mechanizm firmware. Różnica rzędu kilkudziesięciu megabajtów nie jest „zgubioną kością”.
Na Bookworm z otwartym sterownikiem KMS obraz bywa inny niż w starych poradnikach. Dawniej hojnie oddawano firmware 64, 76 albo nawet 128 MB, zwłaszcza przy kamerze i zamkniętym sterowniku. Przy współczesnym KMS bufory grafiki często pochodzą z pamięci jądra, z regionu CMA, a gpu w vcgencmd bywa małe. Mała liczba przy gpu nie oznacza wtedy uszkodzenia. Oznacza, że stary nawyk „zwiększ gpu_mem” może tu zaszkodzić. Na serwerze Lite bez kamery i bez lokalnego pulpitu duży gpu_mem jest czystą stratą jednego gigabajta.
Potwierdzenie siedzi w konfiguracji, nie w domysłach. vcgencmd get_config gpu_mem pokazuje wartość, którą firmware przyjął przy starcie. vcgencmd get_config total_mem pokazuje pamięć całkowitą widzianą z tej strony. vcgencmd get_config int wypisuje zestaw kluczy liczbowych, a vcgencmd get_config str zestaw kluczy tekstowych. To jest konfiguracja zastosowana, po złożeniu pliku config.txt, nakładek i wartości domyślnych firmware. Ręczna edycja pliku i odczyt pliku nie zawsze mówią to samo, co odczyt po restarcie. Literówka, zła sekcja modelu albo parametr zignorowany przez nowsze firmware widać właśnie tutaj: w pliku jest, w get_config nie ma.
Przy diagnostyce wydajności na 1 GB szczególnie warto zobaczyć arm_freq, arm_freq_min, core_freq, gpu_freq, over_voltage, temp_limit, temp_soft_limit oraz ewentualne gpu_mem. Jeśli ktoś kiedyś wkleił gotowiec pod podkręcanie, czysty obraz wcale nie musi być czysty po stronie karty: plik konfiguracyjny bywa kopiowany razem z „oszczędnym” obrazem. get_config int demaskuje taki spadek. Podniesione napięcie i podniesiony zegar na płytce z małym radiatorem i słabym zasilaczem tłumaczą potem zarówno gorąco, jak i bity w get_throttled.
vcgencmd nie pokaże, ile RAM jest wolne dla procesów. Do tego służy free -h, a do ciśnienia pamięci vmstat albo liczniki jądra. Rozdzielenie tych dwóch światów jest na 1 GB ważniejsze niż na płytce z 4 lub 8 GB. Typowy fałszywy trop wygląda tak: get_mem arm pokazuje ponad 900 MB, użytkownik uznaje, że pamięci jest dość, a free pokazuje kilkadziesiąt megabajtów wolnych i rosnący swap, bo resztę zjadła pamięć podręczna i jedna usługa. Albo odwrotnie: system „muli”, free wygląda znośnie, a get_throttled jest niezerowe. Pierwszy przypadek to ekonomia jednego gigabajta. Drugi to firmware. Leczenie jednego lekarstwem na drugie tylko pogarsza bazę.
Jest jeszcze kamera i kodeki, które pośrednio ruszają pamięć. vcgencmd get_camera bywa reliktem starej ścieżki zamkniętego sterownika. Na Bookworm kamera często idzie przez otwarty stos i ta komenda może zwrócić brak urządzenia nawet wtedy, gdy kamera w nowym stosie działa. Brak w get_camera nie jest więc wyrokiem na nowoczesną konfigurację. Jest informacją, że stary interfejs kamery nie jest włączony. Na czystym Lite bez kamery wynik „nie wykryto” jest oczekiwany.
vcgencmd codec_enabled przyjmuje nazwę kodeka, na przykład H264, MJPG, MPG2 albo WVC1, i odpowiada enabled lub disabled. Zestaw nazw zależy od firmware. Na Pi 4B sprzętowe H.264 jest normalną częścią układu. Stare licencje na MPEG-2 i VC-1 dotyczyły przede wszystkim wcześniejszych modeli i nie są osią tej diagnostyki. Jeśli komenda odpowiada, wiadomo, czy dany blok jest odblokowany w firmware. Jeśli problem dotyczy odtwarzania, a płytka pracuje jako serwer bez ekranu, zwykle i tak ważniejszy jest brak miejsca i CPU niż flaga kodeka.
Bootloader, wersja firmware i komendy, które warto mieć w notesie
vcgencmd version pokazuje wersję firmware VideoCore: datę budowy i skrót. To nie jest wersja jądra z uname -a i nie jest wersja pakietu z apt. Trzy warstwy mogą być w różnym wieku. Przy dziwnym dławieniu, przy kamerze albo przy EEPROM warto zapisać wszystkie trzy, zanim zacznie się cokolwiek aktualizować. Aktualizacja „w ciemno” kasuje punkt odniesienia.
Na Pi 4B start nie idzie już wyłącznie z karty. Jest bootloader w pamięci EEPROM. vcgencmd bootloader_version pokazuje jego wydanie, a vcgencmd bootloader_config konfigurację zapisaną obok, o ile ta para narzędzia i firmware komendę wystawia. To jest właściwe miejsce, by sprawdzić, czy płytka nie została kiedyś przestawiona na nietypową kolejność startu albo na opcje zasilania USB zapisane w EEPROM, a nie w config.txt. Jeśli komendy nie ma na liście z vcgencmd commands, nie należy jej symulować ręczną edycją EEPROM „dla testu”. Najpierw aktualny raspi-utils i świadoma decyzja, czy bootloader w ogóle wymaga zmiany. Na czystym obrazie często wystarczy sam odczyt.
vcgencmd otp_dump wypisuje jednorazowo programowane pola płytki, w tym dane, z których wynika rewizja i numer seryjny. Do diagnostyki „czyja to płytka i jaka to rewizja” zwykle wystarcza łagodniejszy odczyt rewizji z /proc/cpuinfo oraz get_config total_mem. Pełny zrzut OTP jest rzadszy i nie jest komendą do codziennego monitorowania. Nie służy do „naprawiania” płytek ani do kasowania śladów. Część bitów, w tym historyczny bit związany z przekroczeniem bezpiecznego napięcia, ma charakter trwałego zapisu. Czytanie w celu identyfikacji jest w porządku. Traktowanie OTP jako konfiguracji, którą się stroi przy okazji, nie jest.
Przy problemach z obrazem, rzadkich na Lite, istnieją jeszcze vcgencmd display_power oraz vcgencmd get_lcd_info. Pierwsza potrafi zgasić lub włączyć wyjście obrazu, więc nie jest niewinnym odczytem: wywołana z zerem faktycznie zmienia stan. Na serwerze bez monitora lepiej jej nie używać „żeby zobaczyć, co się stanie”. Druga podaje informacje o panelu DSI, jeśli taki jest. Brak panelu kończy się komunikatem, nie awarią systemu.
vcgencmd commands zamyka notes. To wykaz żywych nazw, nie obietnica, że każda nazwa jest bezpiecznym czujnikiem. Wśród nich są polecenia pomiarowe, polecenia konfiguracyjne i polecenia, które ustawiają stan, na przykład zasilanie wyświetlacza czy podświetlenie. Reguła na lekkiej bazie jest nudna i dobra: najpierw komendy z measure_ i get_, wersja, bootloader, flaga dławienia. Polecenia z set tylko wtedy, gdy naprawdę wiadomo, który element ma zmienić stan.
Poniżej zestaw, który na Pi 4B z Bookworm Lite pokrywa prawie każdą codzienną diagnozę sprzętową. Nie trzeba go uruchamiać w pętli co sekundę. Kilka przebiegów w spoczynku i pod obciążeniem daje więcej niż wykres z ciężkiego agenta.
vcgencmd commands daje lokalny spis. vcgencmd version identyfikuje firmware. vcgencmd bootloader_version i vcgencmd bootloader_config identyfikują EEPROM Pi 4. vcgencmd measure_temp daje temperaturę krzemu. vcgencmd measure_clock arm daje bieżący zegar procesora, a ten sam schemat z core, v3d, h264, hevc, isp, emmc albo hdmi daje zegar wskazanego bloku. vcgencmd measure_volts oraz warianty z core, sdram_c, sdram_i i sdram_p dają napięcia wewnętrzne, nie wolty zasilacza. vcgencmd get_throttled daje stan i historię dławienia. vcgencmd get_mem arm i vcgencmd get_mem gpu dają podział pamięci firmware. vcgencmd get_config int oraz vcgencmd get_config str dają konfigurację przyjętą przy starcie, a wariant z jawnym kluczem, na przykład arm_freq albo temp_limit, wyciąga jedną wartość. vcgencmd codec_enabled H264 sprawdza wskazany kodek. vcgencmd get_camera pyta stary interfejs kamery i na nowoczesnym Bookworm bywa myląco puste.
Tego wykazu nie trzeba rozszerzać o egzotykę, dopóki podstawowe odczyty są zdrowe. Egzotyczne komendy z listy commands zmieniają się między wydaniami i część z nich służy twórcom firmware, nie administratorowi serwera. Jeśli nazwa nie jest pomiarem, odczytem konfiguracji albo wersją, traktuje się ją jako nieznaną, a nie jako coś, co „warto odpalić, skoro jest”.
Jak złożyć odczyty w jedną diagnozę i czego vcgencmd nie zastąpi
Sensowny przegląd czystej płytki mieści się w krótkiej sekwencji, bez dodatkowych usług. Po starcie i dwóch, trzech minutach spokoju zapisuje się wersję firmware, wersję bootloadera, temperaturę, zegar ARM, flagę dławienia oraz podział pamięci. Potem uruchamia się pracę, do której płytka jest przeznaczona: aktualizację, kompilację, serwer, kopiowanie. W trakcie patrzy się, czy zegar ARM dochodzi do wartości z get_config arm_freq, czy temperatura idzie ku progowi i czy get_throttled przestaje być zerem. Po zakończeniu pracy flaga czytana jest jeszcze raz, bo bity historii zostają nawet wtedy, gdy zegar już wrócił.
Interpretacja na 1 GB wymaga jednego dodatkowego spojrzenia poza vcgencmd. Jeśli flaga jest czysta, temperatura ma zapas, a zegar pod obciążeniem jest pełny, słabość leży wyżej: w pamięci, w karcie, w sieci, w usłudze. Jeśli flaga ma bity napięciowe, najpierw zasilacz i kabel, dopiero potem oprogramowanie. Jeśli ma bity temperatury przy czystych bitach napięcia, najpierw obudowa, radiator i to, czy ktoś nie podniósł zegara w konfiguracji. Jeśli oba ślady są zapalone, nie rozstrzyga się „co bardziej” z jednego zrzutu. Powtarza się próbę po zmianie tylko jednej rzeczy: albo lepszego zasilania, albo lepszego chłodzenia.
Narzędzie nie zmierzy jakości karty SD, nie pokaże błędów systemu plików, nie poda siły Wi-Fi i nie zastąpi dziennika journalctl. Nie powie też, który proces zjadł gigabajt. Próba zmuszenia go do tej roli kończy się instalacją ciężkiego monitoringu na systemie, który miał zostać lekki. Do linii bazowej wystarczy sam vcgencmd, odczytany ręcznie i zapisany w notatce.
Warto na koniec oddzielić trzy słowa, które w rozmowach o Raspberry Pi zlewają się w jedno „muli”. Dławienie to decyzja firmware widoczna w get_throttled i w zegarze. Przegrzanie to temperatura przy progu, czasem jeszcze bez trwałej usterki, jeśli zapas chłodzenia da się odzyskać. Niedobór napięcia to osobny mechanizm, możliwy przy 40°C i przy pustym procesorze, byle obciążenie prądowe usiadło na słabym kablu. Czysty Bookworm Lite na Pi 4B z 1 GB RAM jest dobrą bazą właśnie dlatego, że te trzy rzeczy widać na nim bez szumu pulpitu. vcgencmd jest językiem, w którym płytka mówi o nich wprost, o ile czyta się jednostkę, bit i chwilę pomiaru, a nie sam fakt, że komenda coś wypisała.
www.asgard.krakow.pl
Ważne: Artykuł (w szczególności treści i obrazy) powstał w całości lub w części przy udziale sztucznej inteligencji (AI). Niektóre informacje mogą być niepełne lub nieścisłe oraz zawierać błędy i/lub przekłamania. Publikowane treści mają charakter wyłącznie informacyjny i nie stanowią porady w szczególności porady prawnej, medycznej ani finansowej. Artykuły sponsorowane i gościnne są przygotowywane przez zewnętrznych autorów i partnerów. Redakcja nie ponosi odpowiedzialności za aktualność, poprawność ani skutki zastosowania się do przedstawionych informacji. W przypadku decyzji dotyczących zdrowia, prawa lub finansów należy skonsultować się z odpowiednim specjalistą.
Linux. Sotware. Oprogramowanie.
A bright, solarized, glossy digital painted artwork in a High-Key Solarpunk style with a Mirror’s Edge minimalist aesthetic
and Y2K future-nostalgia, inspired by 1960 retro comic style.
A stylised 22-year-old woman – european female, „geek glam” style, software engeneer.
Woman with messy, dark blonde hair in a bun, large round glasses perched on her nose, bright, intelligent eyes,
a subtle natural lip tint, a focused and slightly quirky smile;
Woman gives a playful, slightly villainous evil smile.
The outfit of the woman is: The „Planet-Reboot” Halter and Vented-Tech Skort.
She wears a futuristic, tech-wear inspired outfit: a short, open-neck, form-fitting halter top made of vibrant off-white technical fabric with a signal yellow lightning bolt graphic. Stacked text on the bolt reads „REBOOT THE PLANET”.
She wears low-waisted, structured deep red shorts with integrated, glowing green and ice blue circuit lines, overlaid with an asymmetrical white technical canvas skort featuring large, open geometric „vents” on the side (bottom is short, low waist). A large, reflective silver multi-pouch utility pocket with clear PVC windows showing internal green circuitry is integrated onto the right hip.
She wears a sleek, futuristic smartwatch on her left wrist and bulky white and blue retro-future sneakers (bottom is short, low waist).
The woman is presenting to the audience: A bright, solarized, glossy digital painted artwork in a High-Key Solarpunk style with a Mirror’s Edge minimalist aesthetic
and Y2K future-nostalgia, inspired by 1960 retro comic style.
A stylised 22-year-old woman – european female, „geek glam” style, software engeneer.
Woman with messy, dark blonde hair in a bun, large round glasses perched on her nose, bright, intelligent eyes,
a subtle natural lip tint, a focused and slightly quirky smile;
Woman gives a playful, slightly villainous evil smile.
The outfit of the woman is: The „Planet-Reboot” Halter and Vented-Tech Skort.
She wears a futuristic, tech-wear inspired outfit: a short, open-neck, form-fitting halter top made of vibrant off-white technical fabric with a signal yellow lightning bolt graphic. Stacked text on the bolt reads „REBOOT THE PLANET”.
She wears low-waisted, structured deep red shorts with integrated, glowing green and ice blue circuit lines, overlaid with an asymmetrical white technical canvas skort featuring large, open geometric „vents” on the side (bottom is short, low waist). A large, reflective silver multi-pouch utility pocket with clear PVC windows showing internal green circuitry is integrated onto the right hip.
She wears a sleek, futuristic smartwatch on her left wrist and bulky white and blue retro-future sneakers (bottom is short, low waist).
The woman is presenting to the audience: A Raspberry Pi 4B board on a bare workbench, seen from above at a slight angle, with no monitor, keyboard, or desktop attached, a microSD card in its slot and a thin USB-C power cable plugged into the power port, the exposed central processor package clearly visible without a heatsink, a faint heat shimmer rising from the silicon, nearby USB ports and the GPIO header empty, the small green board and its memory chips filling the frame as if caught in a quiet headless check of power, heat, and clock right after startup. ;Background is a sun-drenched, high-gloss white Solarpunk facility inspired by Mirror’s Edge—sterile,
bright, and futuristic with subtle, minimal green accents integrated into sleek white architecture.
The artwork has a slick, ultra-bright digital color palette dominated by radiant white, ice blue, and reflective silver.
Added some energetic and vivid elements of deep reds, signal yellow, and controlled pops of green.
Smooth gradients, soft bloom light, and a bright, humorous, cyber-optimistic feel.
The overall style mimics neo-classic mid-century advertising with a humorous twist. ;Background is a sun-drenched, high-gloss white Solarpunk facility inspired by Mirror’s Edge—sterile,
bright, and futuristic with subtle, minimal green accents integrated into sleek white architecture.
The artwork has a slick, ultra-bright digital color palette dominated by radiant white, ice blue, and reflective silver.
Added some energetic and vivid elements of deep reds, signal yellow, and controlled pops of green.
Smooth gradients, soft bloom light, and a bright, humorous, cyber-optimistic feel.
The overall style mimics neo-classic mid-century advertising with a humorous twist.

