Banana Pi – krótka recenzja

Jak wspomniałem, zamówiłem Banana Pi. Zamówienie na Aliexpress, cena – 50 dolarów z wysyłką do Polski. Zdziwieniem i niejakim problemem był fakt, że mało kto na Aliexpress obsługuje PayPala. Przynajmniej ze sprzedających Banana Pi z darmową wysyłką. Tu porada – WBK oferuje coś takiego jak karty internetowe. Tanie, bezpieczne (prepaid), wygodne, ekologiczne (są wirtualne, otrzymujemy tylko PDF, bez plastiku), działają. Można doładowywać. Polecam.

Sprzęt przybył do mnie do domu 14 dni od dokonania płatności. Trochę szczęścia, bo kumpel, który zamówił kilka dni wcześniej, dostał równocześnie, a ze śledzenia paczki[1] wynikało, że przyleciały jednym samolotem. Cła itp. nie ma z uwagi na wartość – zwolnione z cła są przesyłki do 150, tylko nigdy nie pamiętam czy euro, czy dolarów.

Jako dystrybucję wybrałem Raspbiana dla Banana Pi 3.0. Nagrałem na kartę microSD Goodram[2] (się naprawiła), podłączyłem identycznie, jak Raspberry Pi, czyli aktywny hub UnitekY-206P, jeden kabel do dysku, drugi do Banana Pi do gniazda zasilania, trzeci (sygnał) z Banana do huba. Włączenie zasilania i… nic.

Odłączyłem dysk, nadal nic. W końcu odłączyłem kabel sygnałowy do huba i… ruszyło. Jest zauważalnie szybciej, niż na rpi. Znajomy podłączał z monitorem i stwierdził, że spokojnie nadaje się do komfortowego przeglądania poczty i WWW (oczywiście bez flasha). Tak na szybko: jest jeden LED, którym można sterować analogicznie jak w rpi, na dodatek umieszczony w miejscu, gdzie go widać. Przygotowany obraz działa, ale szału nie czyni – jest trochę śmieci, które można usunąć, typu pakiety w cache apta. Zgłoszone, pewnie poprawią przy następnym wydaniu.

Nie udało mi się uzyskać działającej konfiguracji z podłączeniem dysku. Zarówno podłączenie kabla sygnałowego do huba, jak i dysku 2,5″ powodują u mnie zgaśnięcie wszystkich LEDów i zwis Banana Pi (prąd jest pobierany, więc nie wyłączenie). Podejrzewałem problem z USB lub ładowaniem modułu kernela (nie wiedziałem jeszcze o naprawieniu się karty microSD). Ale nie, podłączenie samego kabla czy pendrive nie powoduje problemów.

Ostatecznie wziąłem ładowarkę od komórki i podłączyłem Banana do niej, a dysk do huba USB. W takiej konfiguracji działa[3]. Tyle, że tak nie może zostać. Zadałem pytanie na forum o Banana Pi, parę osób odpisało. Nie jestem sam. Wygląda, że albo Banana Pi jest bardziej wrażliwe, albo znaczenie ma feature Raspberry Pi pozwalający na zasilanie po USB (czego Banana Pi nie ma).

Podsumowując, zapowiada się ciekawie, choć pracowicie (znaczy będzie zabawa). Już przytargałem multimetr i będę starał się wyjaśnić o co chodzi z zasilaniem. Parę pomysłów mam, ale brakuje mi kabelków do testów.

Poza tym, developerzy ciężko pracują i przepraszają, że nie opublikowali źródeł sterownika do karty sieciowej (łamiąc GPL, nawiasem). Czyli obecnie 1 Gbit można mieć działający, ale tylko pod warunkiem użycia zamkniętego kernela/modułu, ze źródeł się nie da. Mam nadzieję, że się uwiną szybko, bo Banana Pi zapowiada się ciekawie.

[1] W pozytywnym szoku byłem, jak dzień czy dwa po płatności dostałem maila z numerem przesyłki i mogłem śledzić na stronie Poczty Polskiej.

[2] Wcześniej tradycyjne zdjęcie journala z ext4, zgłoszone devom, dla odmiany przyjęli do wiadomości, więc jest szansa, że kolejne wydania będą przyjazne dla nośników flash by default.

[3] Zwykle, bo czasem w momencie podłączania huba do Banana Pi potrafi zwisnąć. Ale jak wszystko jest podłączone przy starcie, działa OK.

Raspberry Pi, Raspbian i problemy z kartami microSD

Jakieś siedem tygodni temu pisałem, że padła mi karta microSD (Kingston) w Raspberry Pi. Wymieniłem na nową (Goodram). Zamontowana oszczędnie, tj. bez journala i z symlinkiem /var/lib/transmission-daemon/info kierującym na dysk twardy. Wczoraj robię aktualizację systemu, a tu nagle:

Preparing to replace libssl1.0.0:armhf 1.0.1e-2+rvt+deb7u7 (using .../libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb) ...
Unpacking replacement libssl1.0.0:armhf ... dpkg: error processing /var/cache/apt/archives/libssl1.0.0_1.0.1e-2+rvt+deb7u10_armhf.deb (--unpack):
error creating directory `./usr/share/doc/libssl1.0.0': Input/output error
Segmentation fault Segmentation fault -bash: mbrtowc.c:92: __mbrtowc: Assertion `status == __GCONV_OK || status == __GCONV_EMPTY_INPUT || status == __GCONV_ILLEGAL_INPUT || status == __GCONV_INCOMPLETE_INPUT || status == __GCONV_FULL_OUTPUT' failed.

Piękne, prawda? Oczywiście kluczowy jest input/output error. Fsck, są błędy, naprawiony filesystem. Coś mnie tknęło i sprawdziłem badblocks (badblocks -sv). Tak jest, błędy w okolicy 90% karty (dead link). Sztuk prawie 30. Wygląda, że karta Goodram wytrzymała w komfortowych warunkach raptem 7 tygodni. Masakra.

Z tego wszystkiego zacząłem sprawdzać, co pisze na dysk (iotop -ao). Wyniki (sortowane po ilości zapisów, czas działania kilka godzin) są ciekawe:

3192 be/4 root 8.00 K 4.03 M 0.00 % 0.00 % rsyslogd -c5
2184 be/4 root 240.00 K 880.00 K 0.00 % 0.00 % nmbd -D
3341 be/4 ntp 248.00 K 188.00 K 0.00 % 0.00 % ntpd -p /var/run/ntpd.pid -g -u 102:104
5256 be/4 root 0.00 B 160.00 K 0.00 % 0.00 % [kworker/u2:2]
2911 be/4 root 208.00 K 88.00 K 0.00 % 0.00 % -bash

Jak widać, głównie rsyslog. I raczej nie ma tego wiele.

I tu zaczyna się część najciekawsza. Pamiętacie uszkodzoną kartę Kingstona? Przygotowałem się do pozbycia się jej, poleciał shred. Stwierdziłem, że uruchomię badblocks na niej. I… niespodzianka. Teraz nie zgłasza błędów. Ani w teście odczytu (domyślny), ani w niedestrukcyjnym teście zapisu (badblocks -nvs). Naprawiło się?

Zaczynam podejrzewać jakiegoś buga z przejściówką microSD -> SD (ale są dwie różne, bo każda karta miała swoją), gniazdem w rpi (ale działało OK, poza tym i badblocks, i fsck robię w laptopie). Zagadka.

Ostatecznie zmniejszyłem rozmiar partycji ext4 na karcie Kingstona i działa do tej pory bez problemu. Czyli jakieś 3 tygodnie bezproblemowego działania, bo wpis zacząłem tworzyć 12 czerwca.

UPDATE: Zwariowałem. Goodram, który ewidentnie miał błędy, bo nie tylko badblocks je wykazywał, ale nawet shred puszczony przed wyrzuceniem powodował błędy IO i nie mógł dobrnąć do końca (a próbowałem nie raz), teraz działa. Nagrałem Raspbiana dla Banana Pi, test badblockiem i… czysto. WTF?

Raspberry Pi – sterowanie LED i odczyt temperatury CPU i dysku

Parę dni temu zamówiłem opisywanego wcześniej Banana Pi, którego mam nadzieję użyć jako następcę Raspberry Pi w NAS. Nie wiem co stanie się z obecnym rpi, więc dla pamięci zapiszę parę przydatnych rzeczy, których używam.

Oczywiście do Raspberry Pi można podłączyć LEDy, termometry i ogólnie cuda na kiju (czy tam raczej na GPIO), ale warto też wiedzieć, że jest wbudowany czujnik, z którego można czytać temperaturę CPU. Podobnie jak LED, którym można sterować. Wszystko z wiersza poleceń Linuksa, bezpośrednio z powłoki, bez dodatkowych skryptów czy też bibliotek.

Temperatura CPU

Nie pamiętam już źródła, ale temperaturę CPU w Raspberry Pi odczytać można z /sys/class/thermal/thermal_zone0/temp Jednostka w której jest podawana to tysięczne stopnia Celsjusza, więc pewnie warto będzie zamienić na coś bardziej ludzkiego, np. na stopnie Celsjusza z dokładnością do jednej dziesiątej stopnia (zaokrąglanie):

awk '{printf("%.1f\n",$1/1e3)}' /sys/class/thermal/thermal_zone0/temp

Temperatura dysku

Skoro już sprawdzamy temperaturę, to warto też czytać ją z dysku, o ile taki mamy podłączony do Raspberry Pi. Główna zaleta jest taka, że mniej podatna na chwilowe zmiany i bardziej związana z temperaturą otoczenia. Praktycznie każdy dysk ma czujnik temperatury i można czytać z niego dane przy pomocy S.M.A.R.T. Pobranie samej wartości w stopniach Celsjusza z /dev/sda:

/usr/sbin/smartctl -A /dev/sda | grep -i temp | awk '{print $10}'

Ponieważ zdarzyło mi się raz, że nazwa dysku podczas pracy zmieniała się z /dev/sda na /dev/sdb (nie mam pojęcia czemu) i miałem dziurę w logach, to w skrypcie do logowania obu tych danych stosuję na to obejście (przy okazji pozwoli na czytanie z większej ilości dysków). Cały skrypt (który uruchamiam z crona co godzinę):

#!/bin/bashlogger -t temperature "RPi `awk '{printf("%.1f\n",$1/1e3)}' /sys/class/thermal/thermal_zone0/temp`"for i in `ls /dev/sd?`; dologger -t temperature "Disk `/usr/sbin/smartctl -A $i | grep -i temp | awk '{print $10}'`"done

Sterowanie LED

Większość opisów sterowania LED przy pomocy Raspberry Pi dotyczy tych podłączanych przez GPIO, ale samo rpirównież umożliwia użytkownikowi sterowanie jednym z wbudowanych LEDów. Od razu ostudzę zapał – jest to jedna zielona dioda z kilku LEDów w różnych kolorach świecących się i migających podczas pracy, więc użyteczność OOTB jest mierna. Można się oczywiście bawić w zasłonięcie pozostałych LEDów czy wyprowadzenie na obudowę „światłowodem” tej jednej, albo wyprowadzenie jej w określone miejsce na obudowie, co niewątpliwie zwiększy czytelność, ale to już trochę inna bajka. Polecenia przepisane z wpisu Raspberry Pi – Control the on board LED lights (polecam wpis; blogi znikają, wolę mieć backup).

Wyłączenie triggera (domyślnie pokazuje aktywność mmc0):

echo none > /sys/class/leds/led0/trigger

Zapalenie LED:

echo 1 >/sys/class/leds/led0/brightness

Zgaszenie LED:

echo 0 > /sys/class/leds/led0/brightness

Nie wykorzystuję tego w praktyce z uwagi na wspomnianą małą widoczność. Można w prosty sposób oprogramować i sygnalizować… cokolwiek, w dodatku na minimum 3 stanach (zgaszony/migający/zapalony). Przy odrobinie chęci można dodać obsługę częstotliwości migania. Jeśli chodzi o potencjalne zastosowania, to pierwsze co mi przyszło do głowy, to sygnalizacja temperatury z poprzednich akapitów. Wersja z kilkoma częstotliwościami świetnie nadaje się do informowania o aktualnym zużyciu pasma.