NVIDIA Shield TV z Tegra X1 przetestowany pod Ubuntu
Na forum xdadevelopers pojawił się obraz systemu Ubuntu dla NVIDIA Shield TV z układem Tegra X1. Wyniki testów, przeprowadzone przez właściciela strony phoronix.com z modelem NVIDIA Shield TV wyposażonym w dysk 500GB są bardzo imponujące. Bez problemu osiąga lepsze wyniki niż pozostałe platformy ARM, ale dogania procesory z rodziny Core i3 (wersje oszczędne):
Obraz systemu waży około ~2.5GB i poprawnie obsługuje porty USB, gniazdo Ethernet, WiFi oraz framebuffer. Wystepują jednak problemy z bluetooth i serwerm Xorg, który uruchamia się na "chybił, trafił". Oczywiście system nie posiada jeszcze akceleracji sprzętowej dla grafiki, ponieważ NVIDIA nie opublikowała jeszcze zamkniętych sterowników.
Wciąż niestety nie wiadomo, czy NVIDIA zdecyduje się na wydanie wersji deweloperskiej, jak to było w przypadku platformy Jetson TK1.
Więcej informacji: NVIDIA's Tegra X1 Delivers Stunning Performance On Ubuntu Linux
Reklama
CloudShell dla ODROID-XU4 jako obudowa NAS
Na stronie domowej Hardkernel pojawił się nowy produkt CloudShell przeznaczony dla ODROID-XU4. Jest to nic innego jak obudowa NAS dla projektów DIY, przeznaczona dla 2.5" dysku twardego, dodatkowo wyposażona w wyświetlacz LCD o rozdzielczości 320x240 punktów oraz odbiornik podczerwieni.
Jak wiadomo, rodzina ODROIDów nie posiada póki co złącz SATA/mSATA, dlatego zdecydowano się na zastosowanie mostka SATA↔USB3.0 opartego o układ Genesis GL3321G.
CloudShell
Obudowy dostępne są dwóch kolorach - szarym i niebieskim, natomiast wymiary po złożeniu to 47 x 25 x 21mm. Producent podaje, że prędkość odczytu wynosi 80MB/s, co jest dość dobrym wynikiem. Małe rozmiary i dodatkowy wyświetlacz LCD są oczywiście na "plus", ale pojawia się pytanie: "Czy warto?"
Jeśli nam się poszczęści, za komplet ODROID-XU4 oraz CloudShell przyjdzie nam zapłacić 430 złotych (nie licząc podatku i opłaty celnej). Znając polskie realia czuję, że będzie to ponad 600-700 złotych.
Skoro mówimy o zastosowaniu NAS, to wypadałoby się zaopatrzyć w dysk twardy. W tym momencie zderzymy się z kolejnym problemem. Co prawda dyski 2.5" sięgają już pojemnością 2TB, ale są znacznie droższe niż odpowiedniki 3.5". Na chwilę obecną koszt 2TB to kwota około kolejnych ~500 złotych, a 1TB dysku ~300 złotych.
Jak by nie liczyć, za kompletne rozwiązanie NAS o pojemności 2TB przyjdzie nam zapłacić co najmniej 1100 złotych. Co możemy mieć w tej kwocie?
- QNAP TS-112P (SATA 3G) + dysk twardy 3TB za ~850 zł
- QNAP TS-112P (SATA 3G) + dysk twardy 4TB za ~1100 zł
W rozwiązaniu dwu kieszeniowym, a więc z możlwiością stosowania RAID 1, RAID 0, JBOD:
- QNAP TS-212P (SATA 3G) + 2x 2TB za ~1200 zł
- QNAP TS-231 (SATA 6G) + 2x 1TB za ~1100 zł
QNAP TS-231
Zastosowanie dedykowanej obudowy NAS niesie za sobą dodatkowe i niewymierne korzyści. Nie będę przyklejał specyfikacji, ale warto zajrzeć na kartę produktową QNAP TS-231 i odpowiedzieć sobie na pytanie czy warto?
Owszem pojawia się pewna myśl, że CloudShell z ODROIDem można wykorzystać jeszcze do innych zadań niż NAS. Nie jest nigdzie powiedziane, że akurat do tego celu musi nam służyć. Może być również wykorzystany jako "komputerek" z funkcją udostępniania plików "po sieci" lub jako zgrabna obudowa jeśli chcemy mieć podpięty dysk twardy bez zbędnej plątaniny kabli, gdzie dodatkowo pojemność karty eMMC nie jest dla nas wystarczająca.
Ale jeśli myślisz wyłącznie o NAS, to chyba nie warto - no chyba, że masz "smykałkę" do DIY - wtedy nic i nikt nie powstrzyma :)
Bardzo jestem ciekaw Waszego zdania, czy pomysł jest trafny, czy może chybiony?
HummingBoard i2eX oraz CuBox-i 4x4 od SolidRun
Dzięki uprzejmości sklepu internetowego Kamami miałem okazję przyjrzeć się HummingBoard i2eX będącą najbardziej rozbudowaną wersją z rodziny HummingBoard oraz multimedialnej kostce Cubox-i 4x4 produkcji SolidRun.
HummingBoard i2eX - RPi na bogato
Hummingboard został wyposażony w dwurdzeniowy procesor Freescale i.MX6 (ARM A9) taktowany zegarem 1GHz z jednostką graficzną Vivante GC2000 wspierająca standardy OpenGL ES1.1/2.0 oraz Open CL 1.1. Do naszej dyspozycji dostajemy również 1GB pamięci RAM DDR3 o przepustowości 1066Mbps.
Za sprzęt przyjdzie nam zapłacić prawie 700 złotych, jednak w tej cenie dostajemy całkiem niezłe wyposażenie, którego trudno szukać w innych zestawach: złącze LVDS, MIPI CSI 2.0, gigabitowy port Ethernet, złącze PCI-Express Gen2 oraz mSATA II. Oprócz tego dwa porty USB 2.0, złącze microSD UHS-1, zegar RTC, wyjście audio SPDIF Coax, a także wyście stereofoniczne i mikrofonowe. Nie zapomniano o odbiorniku podczerwieni oraz GPIO udostępniający UART, I/O, SPI oraz I2c.
Cubox-i 4x4 pod TV
384 to kolejny produkt od SoldRun, tym razem wyposażony w czterdzeniowy Freescale i.MX6 (ARM A9) taktowany zegarem od 1GHz do 1.2GHz. Niespotykana jest ilość również pamięci RAM, której zdecydowano się włożyć 4GB. Podobnie jak w prezentowanym dziś HummingBoard za grafikę odpowiada Vivante GC2000. W środku kostki znajduje się również moduł WiFi, BlueTooth, a także odbiornik i nadajnik podczerwieni. System uruchamiany jest z karty microSD i jest w pełni zgodny z systemami dla HummingBoard. Znajdziemy również dwa gniazda USB 2.0, złącze eSATA II (3Gbps) oraz optyczne wyjście S/PDIF. Wymiary kostki to 55 x 55 x 42 mm.
Szeroki wybór oprogramowania
Producent oficjalnie wspiera szeroką gamę oprogramowania, udostępniając w tym celu pomysłowy obraz o rozmiarze 40MB z instalatorem o nazwie Ignition. Wystarczy, że wgramy go na kartę microSD, aby po chwili mieć dostęp sporej ilości obrazów z gotowymi systemami operacyjnymi, które docelowo możemy zainstalować poprzez Internet.
A jest w czym wybierać - dostępne są między innymi: Android 4.4.4, Arch Linux, Debian Jessie, Debian Whezzy, Fedora, GeexBox, OpenELEC, OpenSUSE 13.2, RedSieeve, Slackware, Snappy, Volumio oraz XBian.
Kultura pracy
Procesor chłodzony jest pasywnie za pomocą sporego radiatora. Podczas normalnego obciążenia potrafił się on rozgrzać do temperatury ponad 50°C, a przy większych obciążeniach rozgrzać się jeszcze bardziej. Jednak podczas kilkugodzinnych testów, nie wpłynęło to na stabilność pracy urządzenia.
Dobrym pomysłem okazał się montaż 25mm wentylatorka o przepływie powietrza zaledwie 5.44m3/h. Ponieważ napięcie zasilania wentylatora to 5V, a pobór prądu wynosi około 100mA, bez problemu mogłem podłączyć go do dodatkowego złącza portu USB. Nawet tak niska moc wentylatorka, pozwoliła zbić gorączkę pod obciążeniem do temperatury 35°C.
Pomiar temperatury bez wentylatora
Pomiar temperatury z wentylatorem 5.44m3/h
Pobór energii wygląda następująco:
HummingBoard i2eX | Cubox-i 4x4 | |
Idle | 3.3 W | 3.0 W |
1-core | 3.6 W | 4.3 W |
2-core | 4.8 W | 4.6 W |
3-core | - | 5.9 W |
4-core | - | 6.2 W |
glmar2-es2 | 5. 7 W | 5.9 W |
Dytsrybucje Linuksa
Wszystkie oficjalnie wspierane dystrybucje Linuksa sprawowały się dobrze, obsługując dostępne komponenty. W większości przypadków za poprawną pracę odpowiada jądro z serii 3.14.x. Dużym dla mnie zaskoczeniem jest poprawnie działająca akceleracja sprzętowa, zarówno dla środowisk graficznych jak i dekodowania materiałów wideo. W testowanych dystrybucjach OpenSuse oraz Debian Jessie wszystko działało bez najmniejszych problemów, a repozytoria pakietów nie stawiały żadnych przeszkód.
Dla osób niewymagających środowiska graficznego, którzy chcieliby wykorzystać HummingBoarda do innych celów, dostępne są również minimalistyczne obrazy systemów Debian Jessie/Whezzy oraz Ubuntu Trusty. Posiadają one usprawnione jądra 3.14 oraz 4.1 z obsługą dodatkowych elementów takich jak wyświetlaczy ze sterownikiem ILI9341. Społeczność zgromadzona wokół HummingBoard również nie wydaje się próżnować - na forum znajdziemy dobrze udokumentowane rozwiązania, czy "wypasioną" dystrybucję Ubuntu (Lubuntu, X-ubuntu, Lxde, KDE).
OpenELEC 6 z Kodi Isengard
OpenELEC 6 @ HummingBoard i2eX
Testy porównawcze
Zobacz również porównanie z pozostałymi platformami na https://www.jarzebski.pl/soc-benchmark.html
Obserwacje dodatkowe
- Pomimo wyposażenia w 1Gbps złącza Ethernet, maksymalna przepustowość to 470Mbps, wynika to z ograniczeń jednostki SoC
- HummingBoard obsługuje karty microSD UHS I, co powinno zwiększyć prędkość operacji na kartach microSD w tym standardzie. Obsługa UHS-I została celowo wyłączona ze względu problemów jądra z przełączaniem napięcia regulatora z 3.3V na 1.8V. Możliwe jest zastosowanie odpowiednich łatek na jądra mainline >=3.15, jednak tracimy wtedy akcelerację grafiki.
- System bez problemu możemy uruchomić z nośnika mSATA. Podczas testów z dyskiem SSD A-Data XPG SX300 64GB prędkość zapisu sięgała 130MB/s, a odczytu 137MB/s. Po przeniesieniu rootfs korzystanie z HummingBoard i2eX nabiera zupełnie nowego wymiaru.
Wnioski
Zarówno HummingBoard i2eX jak i Cubox-i 4x4 są niewątpliwie bardzo ciekawymi produktami. Pierwsza z nich wyróżnia się złączami mPCIE oraz mSATA, co czyni ją wyjątkową propozycją do zadań specjalnych. Cubox-i posiada z kolei 4GB pamięci RAM, gniazdo eSATA oraz zgrabne wymiary, które idealnie wpasują się w styl naszego salonu. Dobre wsparcie producenta, a także szeroka gama systemów operacyjnych sprawia, że ta już bądź co bądz leciwa konstrukcja, wciąż okazuje się interesująca.
Natrafiłem dziś na bardzo interesującą płytkę o nazwie NanoPi z układem ARM Samsung S3C2451 taktowany zegarem 400MHz oraz wyposażoną w 64MB pamięci RAM DDR2 133Mhz. Wymiary tego maleństwa to zaledwie 75mm x 30mm.
W cenie 16$ dostajemy również:
- zintegrowany moduł WiFi oraz Bluetooth (układ AP6210)
- port USB Host 1.1 (Typ A)
- port microUSB, który może posłużyć do zasilania jak i do transmisji danych (również jako Ethernet)
- port Serial Debug
- slot kart pamięci microSD
- złącze interfejsu LCD o rastrze 0.5mm z obsługą RGB 8-8-8
- złącze kamer DVP o rastrze 0.5mm z obsługą ITU-R BT 601/656 8-bit, I2C, I/O
- 40-pinowe złącze GPIO o rastrze 2.54mm zgodne z Raspberry Pi (UART, SPI, I2c, I/O)
- dodatkowe 12-pinowe złącze GPIO (I2S, I2c, UART)
Płytka obsługuje u-Boot, a także posiada wsparcie dla dystrybucji Debian oraz Linux-4.1+Qt.
Zastanawia mnie jedynie w jaki sposób rozwiązano obsługę kamer, ponieważ zastosowany tutaj układ Samsunga, który akurat nie wspiera kompresji wideo. Tak czy inaczej pozycja ta wydaje się bardzo ciekawa i może znaleźć sporą ilość zastosowań.
Więcej informacji znajdziecie na stronie producenta: http://nanopi.org
Wgrywamy firmware do NodeMCU v2 - krok po kroku
W poprzednim tygodniu opisywałem świetną płytkę NodeMCU v2 opartą na układzie ESP8266. Oprócz podstawowych zagadnień, pokazywałem również jak wgrać nowy firmware w postaci binarnej jaki przygotowali twórcy. Najnowsza dostępna wersja w dniu tego wpisu to NodeMCU 0.9.6 datowana na 2015/02/16. Możemy jednak wgrać nowszy build, a nawet skorzystać z rozwojowego drzewa dev120.
Wszystko czego będziemy potrzebowali to Linuksa, trochę czasu i odrobinę miejsca na dysku twardym (około 4GB)
ESP Open SDK
W pierwszej kolejności sklonujmy repozytorium ESP Open SDK i przygotujmy zestaw odpowiednich narzędzi:
- cd ~
- mkdir nodemcu
- cd nodemcu/
- git clone https://github.com/pfalcon/esp-open-sdk.git
- cd esp-open-sdk/
- make STANDALONE=y
W zależności od posiadanego sprzętu i prędkości sieci, proces ten może zając od kilku do kilkunastu minut. Po tym czasie powinien wyświetlić się komunikat o pomyślnym wykonaniu zadania z prośbą o modyfikację zmiennej środowiskowej PATH. W moim przypadku będzie to:
- export PATH=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/bin:$PATH
Sprawdźmy jeszcze, czy wszystko jest poprawnie, wydając poniższe polecenie:
- xtensa-lx106-elf-gcc -v
Using built-in specs.
COLLECT_GCC=xtensa-lx106-elf-gcc
COLLECT_LTO_WRAPPER=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/libexec/gcc/xtensa-lx106-elf/4.8.2/lto-wrapper
Target: xtensa-lx106-elf
Configured with: /home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/src/gcc-4.8.2/configure --build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu --target=xtensa-lx106-elf --prefix=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf --with-local-prefix=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --disable-libmudflap --with-sysroot=/home/korneliusz/nodemcu/esp-open-sdk/xtensa-lx106-elf/xtensa-lx106-elf/sysroot --with-newlib --enable-threads=no --disable-shared --with-pkgversion='crosstool-NG 1.20.0' --disable-__cxa_atexit --with-gmp=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpfr=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-mpc=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-isl=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-cloog=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --with-libelf=/home/korneliusz/nodemcu/esp-open-sdk/crosstool-NG/.build/xtensa-lx106-elf/buildtools --enable-lto --enable-target-optspace --disable-libgomp --disable-libmudflap --disable-nls --disable-multilib --enable-languages=c,c++
Thread model: single
gcc version 4.8.2 (crosstool-NG 1.20.0):
Możemy przystąpić do budowania firmware
Ponownie klonujemy repozytorium - tym razem zawierające firmware:
- cd ~/nodemcu/
- git clone https://github.com/nodemcu/nodemcu-firmware.git
- cd nodemcu-firmware.git/
Na tym etapie musimy zdecydować, czy interesuje nas gałąź master (obecnie z wersją 0.9.6), czy może chcemy spróbować deweloperskiej wersji 1.2.0. Jeśli tak, wybieramy gałąź dev120. Jeśli nie, pomijamy poniższe polecenie:
- git checkout dev120
Na koniec nie pozostaje nam już nic innego, jak wydanie polecenia kompilacji:
- make
Kiedy kompilacja dobiegnie końca, możemy przygotować nasz firmware i wgrać go NodeMCU v2 (oczywiście podłączająć go do USB):
- tools/esptool.py elf2image app/.output/eagle/debug/image/eagle.app.v6.out
- tools/esptool.py write_flash -fm dio -fs 32m -ff 40m 0x00000 app/.output/eagle/debug/image/eagle.app.v6.out-0x00000.bin 0x10000 app/.output/eagle/debug/image/eagle.app.v6.out-0x10000.bin
I praktycznie tyle. Sprawdźmy jeszcze za pomocą minicoma, czy rezultat jest zgodny z oczekiwaniami:
- minicom -D /dev/ttyUSB0 -b 9600
Po restarcie powinniśmy ujrzeć świeży firmware:
Custom firmware
Przed kompilacją i wgraniem, możemy zmodyfikować konfigurację naszego firmwareu edytując plik app/include/user_modules.h.
Właśnie tutaj zdecydujemy o dostępności poszczególnych modułów, oszczędzając tym samym cenne kilobajty.