Pewnie kilka osób kupiło sobie te urządzenia. Jakiś czas temu były dostępne na iBood w dość dobrej cenie. Wyglądu i innych pierdołek nie będę komentował, ponieważ każdy zainteresowany znajdzie sobie zdjęcia na necie.

Co mamy w środku:

CPU: 88F6281 A1 (DDR2) 1200MHz
RAM: 256 MB
NAND: 128 MB
NIC: RTL8111DL
USB: Dwa porty USB 2.0
HDD: Wewnętrzny port SATA I/II oraz zewnętrzny port eSATA
Inne: Wentylator (średni jakościowo), 3 przyciski (power, reset, copy), pięć dwukolorowych diód sterowanych programowo (+ jedna stała na przycisku power) oraz głośniczek.

Nie chciałbym opisywać tu możliwości oryginalnego oprogramowania, które w przypadku tego urządzenia jest naprawdę dobre, ale na uruchomieniu innego systemu. Docelowo będzie to Arch Linux.

W tej chwili mam już działające testowo urządzenie ze skompilowanym kernelem 3.1.10-6. Stabilność jest dość wysoka z wyjątkiem szyny i2c, która potrafi zawisnąć kiedy działa fancontrol.

Patche kernela, które użyłem pochodzą z http://pastebin.com/LkF8Q1dH
Dodatkowo mamy kernel debiana tu: https://github.com/peeter123/NSA310-320-debian
Dyskusja na temat instalacji debiana znajduje się tutaj: http://forum.nas-central.org/viewtopic.php?f=249&t=5145

Temat założyłem, aby dowiedzieć się czy jest jakiekolwiek zainteresowanie tym sprzętem. Jeżeli tak to postaram się coś więcej napisać.

PS. Poprosiłem ZyXELLa o udostępnienie patchy kernela oraz sterowników. Dziś dostałem potwierdzenie przesłania zgłoszenia do odpowiedniego działu oraz termin (13 kwietnia) do którego zostanie udostępniony kod.

Edit 27.03.2011
Szybkie testy



Edit 28.03.2011

Katalog z pakietami
http://jumbofiles.com/user/Fatum/99676/NSA310

Plik ArchLinuxARM-NSA310-28032012.tar.gz zawiera zmodyfikowaną najnowszą wersję oryginalnego systemy ArchLinuxARM.
Zmiany
-Usunięty pakiet linux oraz linux-headers
-Dodany pakiet linux-nsa310 oraz linux-nsa310-headers
-Dodany plik /etc/fw_env.config (dla uboot-env)
-Dodano regułę udev dla cryptodev
-Skrypt /etc/rc.d/netfix który po prawidłowej instalacji uboot-env ustawia mac katry sieciowej na podstawie zapisów w env uboota (takie chwilowe obejście). Powinno się go dopisać przed inicjalizacją sieci w rc.conf

Kernel zawiera wszystkie patche jak oryginalny + obsługę NSA310 + moduł lm85 oraz sieci. Dodatkowo zawiera patche na działanie diód (wyżej był podany link) który powoduje miganie diód hdd/usb w momencie zapisu/odczytu. Jest też rollback wspomnianego gdzieś niżej w postach commita dla i2c. Powodował on zawieszanie komunikacji z lm85



Ogólny skrócony opis instalacji:


1. Tworzymy partycję i formatujemy ją na ext2
2. Montujemy pena i wypakowujemy zawartość pliku ArchLinuxARM-NSA310-28032012.tar.gz na niego
3. Jeżeli wszystko przebiegło sprawnie to możemy podłączyć kabel i wpiąć pena do usb

|Wygląd złącza:
*|-|*|*|*
Kolejno mamy
GND|Pusto|TX|RX|VCC

Oczywiście jest to opis wyjść, więc przewody RX/TX podłączamy odwrotnie. Wystarczą nam przewody GND, TX oraz RX

4. Ustawiamy ulubiony program (np. putty) na odpowiedni port com z parametrami 115200/8/1/N/N (Speed/Data bits/Stop bits/Parity/Flow Control)
5. Uruchamiamy NSA310 i przerywamy bootowanie dowolnym klawiszem (komunikat Hit any key to stop autoboot)
6. Wydajemy polecenia

Jeżeli chcemy uruchomić wbudowane oprogramowanie wystarczy dać
7. Po restarcie zatrzymujemy i dajemy polecenie



Jeżeli mamy jakiś problem (np. timeout – literka T) można spróbować triku z restartem. Czekamy aż wróci nam linia komend i dajemy


zatrzymujemy bootowanie i ponownie



Jeżeli pen dalej nie będzie rozmawiał z NSA310 po resecie softwareowym to zmieniamy pena na innego

8. Jeżeli USB wystartowało to wydajemy komendy:
Zakładając, że mamy 1 HDD i jednego pena

9. Jeżeli wszystko przebiegło prawidłowo to logujemy się do systemu przez root/root
Zmiany do automatycznego uruchamiania przygotuję trochę później

Edit 5
Uwaga! Ten opis jest mocno nieaktualny - pliki z hostingu wcięło.
Proszę zapoznać się z wątkiem ZyXEL NSA3xx i nowy instalator

Ja "jadę" na debianie od stycznia. Wszystko chodzi ok - na jajku 2.6.38 z wkompilowanym dodatkowo sterownikiem do mv643xx nawet samba się nie wiesza. Z usprawnień.. jednego nasa bootuje z pendrive'a, drugiego z pierwszej partycji (tam gdzie trzyma swapa) i nie ruszam flasha (poza configiem uboota). Kiedyś nawet wracałem do oryginalnego firmware-u i działa.

Edit: jak zawiesić i2c? trzeba coś robić, czy sam z siebie? Samba na 3.1 nie zawiesza nasa?

Edit 2: Automatyczna instalacja debiana
Potrzebujemy pendrive sformatowany fatem, firmware 4.22 (można spokojne zrobić downgrade z 4.4) i następujące pliki:
uImage
initrd.gz
linux.tgz
nsa310-ali.zip

Ostatnie archiwum zawiera w sobie pliki:
usb_key_func.sh
nsa310_check_file_C0
checksumfile
nsa310.sh

Kopiujemy jądro, initrd.gz, linux.tgz oraz zawartość archiwum nsa310-ali.zip na pendrive (powinno być razem 7 plików) i restartujemy nasa. Do swoich potrzeb można modyfikować nsa310.sh i initrd.gz (uboot env powinien dostosowywać się do nowego rozmiaru pliku)

Jak działa skrypt? Wydaje mi się, że następująco
usb_key_func.sh kopiuje na sda1 jądro i initrd, modyfikuje ustawienia uboota i restaruje system
initrd uruchamia skrypt nsa310.sh który formatuje sda2 na ext4, rozpakowuje linux.tgz przygotowany debootstrap-em (user: root passwd: root), modyfikuje uboota i restart.. i mamy wgranego debiana bez rozkręcania i seriala

Dostęp przez ssh , ip z dhcp

Miłego testowania, wsparcie dla firmware >= 4.40 wkrótce

Edit: cały proces trwa kilka minut, więc cierpliwości..
od restartu z podłączonym penem po ok 1 minucie jest następny restart
z dyskiem 500GB formatowanie i rozpakowanie systemu trwa ok 7:30 - dioda sys miga na zielono, hdd na czerwono, następuje restart i po 20s mamy dostęp do debiana
Z dyskiem 2TB wszystko trwa ok 22 minuty

Edit: po uruchomieniu warto wygenerować nowe certyfikaty, ustawić locales i ew. poprawić sources.list apta
Edit 4: Automatyczna instalacja Debiana
Pobieramy 2 archiwa :
wersja aktualna nsa310-ali.zip i linux.tgz - poprawiony link
wersja 20120506 nsa310-ali.zip i linux.tgz
Zawartość pierwszego archiwum rozpakowujemy na pendrive z systemem plików fat, drugie archiwum w całości kopiujemy na pendrive. Uruchamiamy nasa z wpiętym pendrivem. Po kilku minutach (ok 7 od uruchomienia OFW z dyskiem 500GB) NAS się wyłączy - mamy moment na odpięcie pena a po włączeniu - dostęp do Debiana przez ip z dhcp (user root,password root)

Skrypty działają na firmware 4.40, użytkownicy 4.22 muszą zmienić nazwę pliku checksumfile.422 na checksumfile (nie sprawdzałem, ale powinno działać)

Skrypty formatują dysk! Zarchiwizuj ważne pliki przed instalacją
Jeśli nie chcesz formatować dysku, w pliku nsa310.sh dodaj # w linijce
(nie próbowałem na 4.22! - tam jest inny system plików)

Tryb recovery

Dodałem skrypt recovery.sh który ustawia fabryczne ustawienia uboot'a i pozwala wrócić do oryginalnego softu. Żeby uruchomić tryb recovery należy zmienić nazwę pliku recovery.bak na recovery i uruchomić nasa z wpiętym pendrivem. Po zakończeniu nas się wyłączy - po odpięciu pena system wstanie na ofw

Skrypty w wersji testowej! Używasz ich na własną odpowiedzialność!
W przypadku niepowodzenia może konieczne okazać się rozkręcenie urządzenia i wyjęcie dysku lub podłączenie kabelka serwisowego

Edit: Debian wheezy znajduje się tutaj https://www.dropbox.com/sh/ftv4dz1i4jbs9lh/It0EkD65R9
Cała instalacja jak powyżej, zastępujemy plik linux.tgz

Ja mam system na usb. Jeden swap w zram a drugi na dysku. Sam dysk sformatowany na ext3. Dzięki temu przy braku aktywności dysk przechodzi do stanby. Na ext4 dysk mi się nie wyłączał (jakaś aktywność co kilka sekund).



Hmm. Aż tak nie testowałem samby. Przez weekend to nadrobie.

i2c odpalić demona fancontrol i obciązyć system. Sensors po odpaleniu juz nic nie odczyta a w logach mam problem z lockem na i2c. Nie pomaga restart. Tylko wyłączenie całkowite.

Edit:
Dziwnie zachowuje się też sterownik r8168. Niby działa, ale zmiana mac powoduje czasem zawieszenie transmisji (oczywiście down, mac, up). Ponowny "restart" sieci przywraca działanie. Na r8169 działa ok. Zostałem więc przy r8169, ponieważ mam skrypt który przy starcie odczytuje mac z parametrów uboota i poprawia go w systemie. Na r8168 miałem 50/50 % szans na poprawne działanie sieci.

Samba u mnie błyskawicznie zawieszała nasa przy kopiowaniu na 3.2. Potrzeba kilkadziesiąt sekund kopiowania dużego pliku i zwiecha..nawet po fastethernecie i niezależnie od sterownika. W drugą stronę kopiowanie działa nieco lepiej.

Testowałem przez chwilę sambę i działa stabilnie. Kilka giga w obie strony przeszło bez problemu.

Co do i2c to

dmesg:
[ 6518.112680] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 6520.112634] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 6522.112615] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 6524.112566] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 6526.112536] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 6528.112505] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 6530.112511] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 6532.112451] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
[ 6534.112419] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0

i sensors (po długiej pauzie)
lm85-i2c-0-2e
Adapter: mv64xxx_i2c adapter
in0: +1.90 V (min = +1.90 V, max = +1.90 V)
Vcore: +1.71 V (min = +1.71 V, max = +1.71 V) ALARM
+3.3V: +2.51 V (min = +2.51 V, max = +2.51 V)
+5V: +3.80 V (min = +3.80 V, max = +3.80 V)
+12V: +9.12 V (min = +9.12 V, max = +9.12 V)
fan1: 143 RPM (min = 143 RPM)
temp1: -110.0°C (low = -110.0°C, high = -110.0°C) ALARM
M/B Temp: -110.0°C (low = -110.0°C, high = -110.0°C)
temp3: FAULT (low = -110.0°C, high = -110.0°C)

Widać bzdury. Wentylatora już nie można zasterować.

I tu ciekawostka bo na płycie jest chyba ADT7476arqz, a działa jako lm85 (tak jak oryginalnym sofcie). Sterownik adt7475 nie działa prawidłowo.
Dodatkowo w oryginalnym sofcie mamy na szynie i2c niby:

002e - lm85
004a - i2s_i2c
0051 - pcf8563

lm85 - ok
i2s_i2c - dźwięk??? (buzzer?). Ale moduły nie są zainstalowane
pcf8563 - rtc. Ale to jest zrobione przez mv_rtc i działa bez sterowników oraz podania urządzenia w kernelu.

Edit:
i2c ma cos spaprane z commitem eda6bee6c7e67b5bd17bdbced0926f5687f686d5. Zrobię kompilację z bez tego patcha i zobaczymy co z tego wyjdzie.

Edit 2:
Chyba zadziałało. System obciążony, fancontrol działa dodatkowo watch sensors. Zero problemów z i2c

Ja się zastanawiam nad zakupem tego NAS`a, jego konkurentem jest iOmega Iconnect i w zasadzie nie wiem na co się zdecydować, widzę że platforma sprzętowa podobna, ale ze wsparciem to już zupełnie inna bajka.

Mam oba urządzenia. iConnect faktycznie działa out of box. Co do NSA310 to mniej popularny sprzęt. Jeżeli chodzi o parametry to oba sprzęty są do siebie zbliżone. Teraz zależy do czego chcemy je używać. Ja mam na iConnect serwerek, który zastąpił mi maszynę na atomie. Robi dokładnie to samo a zjada mniej energii. WiFi mam całkowicie wywalone (wyciągnięta karta). NSA310 kupiłem faktycznie jako NAS. Ma mi służyć jako backup.

Trochę się rozchorowałem, ale przez weekend udało mi się potestować stabilność NSA pod Arch Linux. Uruchomione miałem usługi typu samba sabnzbd itp. Nie miałem ani jednej zawieszki, nawet pod mocnym obciążeniem. Na sambę i z samby przerzuciłem sporo giga. Bez wspomnianego commita szyna i2c działała stabilnie i fancontrol mógł bez przeszkód sterować wentylatorem. Jak mi troche chorubsko przejdzie to postaram się wystawić kernel i pakiety dla nsa, oraz zrobić krótką instrukcję instalacji.

Zrób też małe testy wydajnościowe (ile idzie przez siec, jakie obciążenie cpu jest itd).

Myślałem by postawić na tym sambę, rtorrenta/transmission, ftp, apache/lighttp i ewentualnie serwer wydruku. Tp-link nie wyrabia, a wydaje mi się że ram-mod niewiele zmieni, stąd decyzja o zakupie.

Przetestuję wydajność. Wiadomo, że będzie zależeć od dysku oraz sieci (tu nie jestem pewien sterownika r8169). Już mogę powiedzieć coś na temat sabnzbd który jest mocno obciążający i zasobożerny. Portafił mi ściągać pliki binarne z prędkością do 3 megabajtów na sekundę. Jest to maksymalny limit mojego łącza. Spora ilość mieszanych połączeń (plain/ssl). Procek prawie ma max. Czuć było spowolnienie na interfejsie www. Nie przeszkadzało to aby przekopiować pliki po sambie.

@ZiP
Kolega ma bardzo podobną konfigurację właśnie na iConnect. A kupił go bo był tańszy od print servera

Wybór jednak padł na Zyxel`a. Jeden zasilacz będzie mniej, bo dysk i tak mam 3,5". Lulo, co do klienta torrentów, przecież dostępny jest transmission pod ffp.

@fatum
Czy możesz gdzieś zamieścić jakieś gotowe kernele i obrazy Arch'a, dla tego Zyxela?
Sam chciałbym na nim zainstalować Arch Linux ARM. Może skrobniesz jakiś tutorial?

Arch'a używałem już na TonidoPlug (kopia SheevaPlug) i byłem bardzo zadowolony - lekkość i szybkość działania.

Zabawkę już dostałem, na razie katuje go z FFP, i ku mojemu pozytywnemu zdziwieniu, transmission daje radę z paczką która zajmuje 250 GB, gdzie przy tp-linku ten torrek powoduje ogólne zamulenie.
@Fatum, również będę Ci wdzięczny za opis, myślę że wiele on ułatwi w przygodzie z tym sprzętem.

Jak będę miał wieczorem chwilę czasu, to wrzucę gdzieś mój aktualny uImage oraz paczki linux-nsa310-3.1.0-6, oraz headers do tego. Ogólnie jest potrzebny kabel do komunikacji. Nie mam żadnego automatycznego skryptu. Sam system trzeba pobrać ze strony Arch Linux ARM http://archlinuxarm.org/os/ArchLinuxARM-armv5te-latest.tar.gz i rozpakować (do testów) na pena sformatowanego jako ext2 (Spod linucha tak aby atrybuty były poprawne). Po umieszczeniu plików rozpiszę mniej więcej kroki.


Edit:

Pierwszy post zaktualizowany.

Potwierdzam - na jajku 3.1 + debian+ samba chodzi dobrze. Na 3.2 wywala się.. w patchu widziałem dużo zmian w sterowniku r8169 (doszły jumbo-frames do i8168?)

Nie mam pojęcia. Sterownik r8169 jest dokładnie taki jak w zródłach kernela. Wiekszość kodu pochodzi z pliku na pastebin.

Edit:
Teraz zauważyłem. Debian? Skompilowałeś kernel? Chciałbym wiedzieć czy to problem kernela czy samego pakietu samby.

Hmn.. na jajkach do 3.1 włącznie chodzi spoko - samba z repozytoriów debiana, kernel mój, waniliowy+patch z forum.
W 3.2 samba zawiesza system . Nie kompilowałem samby własnoręcznie. Patrzyłem w patch 3.2 i stąd wniosek o jumbo-frames i innych zmianach w r8168

Można przekompilować jajko 3.2 ze sterownikiem r8169 w module (lub bez) i spróbować jak działa r8168 (http://code.google.com/p/r8168/). Na 3.1 wydawało mi się, że r8169 jest bardziej stabilny niż r8168. Na 3.2 może być inaczej.

Też zwiecha.. przerabiałem to wiele razy. Nie pamiętam czy r8168 ma jumbo frames włączone. Może to jest przyczyna na nowym jajku.
Edit: @fatum dałbyś radę skompilować kernel 3.2? Jak nie będzie kłopotów z sambą, to będzie znaczyło, że to kłopot z debianem

@osa
Jak będę miał trochę czasu to może się skuszę Ogólnie musiałbym zminimalizować patche tylko do obsługi sprzętu. Wywalić dodatki ledów i tych z oryginalnego kernela archa. Sam config mógłby być oparty o istniejący. Może w weekend powalczę z tematem.

Edit:
Dobra zrobiłem test inaczej
Odpaliłem archa ale na jajku peeter123 z NSA310-320-debian

Jako że wszystko jest wkompilowane w kernel to moduły nie były potrzebne.

Przekopiowałem z samby 3giga danych. Te same dane wrzuciłem z powrotem na sambę. Wszystko działa.


Edit 2:
Używasz jumbo frames? W commit f33486042a73eeda295d146092af06d40db1e221 jest patch dla 8168d: "r8169: corrupted IP fragments fix for large mtu."