Zyxel NSA320S és a Debian Linux – 3. rész

Az előző bejegyzésben eljutottam odáig, hogy a soros konzolon lévő NSA320S U-Boot-ja képes egy pendriveról beolvasni egy Linux kernelt. Sajnos, az NSA320S nincs (még) a támogatott eszközök listáján, így ez önmagában nem sokat ér. Ebben a bejegyzésben a kernellel és az alaplapra integrált RTC chippel futott köreimről írok.

Első lépés, egy működőképes Linux kernel előállítása

Az NSA320S-hez még nincs támogatás a Linux kernelben, de a 88F6702 típusú (illetve ezzel kompatibilis) Kirkwood SoC és az NSA320S egyéb összetevőinek nagy része már támogatott. Ez azt jelenti, hogy elindítható egy Linux kernel a gépen, csak nem inicializálja megfelelően az eszközt. Device Tree leíró fájl nélkül szinte semmi nem bírható működésre, ez itt nem a plug-and-play kényelmes világa. A SATA, az USB, az I2C busz, a GPIO portokra kötött előlapi ledek, kapcsolók nyilván sem fognak maguktól működni, hiába van kompatibilis driver a kernelben.

Első lépés az NSA320S pontos felépítésének a felderítése volt. Az eredeti Zyxel kernel forráskódjához nem sikerült hozzájutnom, így csak a működő Zyxel rendszeren tudtam keresgélni, illetve némi infó az alaplapról is kibogarászható volt. Ezek mellett itt-ott próbálgatásra kellett hagyatkoznom, hogy az újabb kernelhez létrehozzak egy működő configot, dts fájlt és drivereket.

Az ARMv5 kompatibilis kernelt egy 64 bites Ubuntu linuxon az alábbiak szerint hoztam létre:

apt-get install build-essential gcc-arm-linux-gnueabi u-boot-tools
tar Jxvf linux-3.18.4.tar.xz
patch -p0 < linux-3.18.4-nsa320s.patch
cd linux-3.18.4
make -j4 CROSS_COMPILE=arm-linux-gnueabi- ARCH=arm zImage dtbs
cat  arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa320s.dtb > zImage-nsa320s
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux+DTB -d zImage-nsa320s uimage

A patch fájl tartalmazza az alap config fájlt, a hozzáadott drivereket és az NSA320S kompatibilis DTS fájlt is.

Jelenleg működnek már:

1. Bebootol a 3.18.4 kernel az NSA320S vason.
2. Működnek a SATA portok.
3. Inicializálva van, és működik a gigabites Ethernet.
4. Működnek az USB portok.
5. Írtam egy kernel drivert a HT1382 RTC-hez, ami ezzel akár működhetne is, de erre még visszatérek.
6. A hűtőventilátor fordulatszámának hőmérséklet függő szabályozását (PWM) a Zyxel fejlesztői a korábbi LM chipről az MCU-ra tették át, így ezzel nem sok teendő van.
7. A hőmérséklet és a ventilátor fordulatszáma lekérdezhető.

Amik még nincsenek rendben, fontossági sorrendben:

1. Az alaplapon lévő MCU egy Holtek HT66F30, amihez sajnos nincs Holtek programozóm/debuggerem. Egy AVR, PIC vagy MSP esetén nem lenne ilyen nyűgös a dolog. Néhány lényeges feladatot nem a SoC, hanem ez a HT66F30 lát el, ez felel pl. azért, hogy áramszünet után a NAS a beállításoktól függően a újrainduljon vagy kikapcsolva maradjon. Lehetőségként persze ott van az MCU és a SoC közötti I2C busz figyelése, alkalmasint rá is lógatom erre az USBee analizátort.
2. Az előzőhöz kapcsolódik a PowerDown problémája, azaz nem ártana, ha az NSA320S kikapcsolható volna.
3. A Wake-on-Lan lehetőségét én nem használom, de azért illene ezt is működőképessé tenni.
4. Az előlapi kapcsolók és ledek azok, amikben nem sok ördöngősség van. Ezek mezei, GPIO portra lógatott ledek és kapcsolók. Ezt nem olyan nagy feladat rendbe tenni, csak némely funkció kialakításához kellhet a kernel mellett valamiféle userspace megoldás is.

A végleges config fájlt is tartalmazó kernel patch elérhető (lesz) a bejegyzésem utolsó (talán a 4.) részében. Jelenleg, félkész és némileg teszteletlen állapotában nem látom értelmét publikussá tenni. Hacsak nem szállna be valaki a fejlesztésbe… 🙂

HT1382 RTC

Az alaplapon van egy elemmel ellátott HT1382 típusú RTC, azaz az NSA320S elvileg áramtalanított állapotában is őrzi a pontos időt. Ez hasznos funkció volna, hiszen a fájlszerveren komoly jelentősége lehet egy fájl létrehozási vagy módosítási dátumának. A 3.18-as kernelben nyoma sincs kompatibilis drivernek, ezért írtam egyet a specifikáció alapján. Nem volt nagy kaland, a driver kész, írható-olvasható az I2C buszon, 0x68 címen elérhető HT1382. Meglepetésként ért, hogy a chip nem „ketyeg”. Linux alatt beállítható és kiolvasható az óra, csak épp a másodperceket tartalmazó regisztert nem lépteti a HT1382. A specifikáció szerint az egyetlen erre vonatkozó flag beállítása rendben, de mégsem lépkednek a másodpercek. Ha szoftveresen minden rendben, akkor mi a bánat van?

A HT1382 külső kristályról fut(na), de nem fut. Az alaplapot átnézve vannak furcsaságok. A HT1382 mellett ott van az SDA04A jelzésű, vélhetően 32768 Hz-es kvarc, de a C168 és C169 kondenzátorok nincsenek beforrasztva az alaplapra. A HT1382 a specifikációja szerint nem is igényli ezeket, mert a chipbe integrálva vannak a 12,5pF értékű kondenzátorok is. Az X1, X2 bemenetek kristályra kötött vezetősávjai hosszan a Kirkwood RTC bemenetei (RTC_XIN/RTC_XOUT) felé futnak el, de átkötések (R316 és R317) hiányában tulajdonképpen nincsenek is bekötve. Vajon miért lógattak egy ekkora „zavargyűjtő” antennát a kristálybemenetre? Enyhén szólva problémásnak érzem itt-ott a tervezést…

Tulajdonképpen csak két hibalehetőség van:

1. Hibás a HT1382. Ez elképzelhető, mert a Holtek fórumán olvasható panaszok szerint közel 4% a hibás chipek aránya.
2. Hibás a kristály. Ez is lehetséges, de cserélni eléggé nehéz. A mérete a kellemetlen kategóriába eső kb. 1 x 3 mm, de ennél nagyobb gond, hogy csak nehézkesen beszerezhető.

Nekiállnék megjavítani, de egyelőre vannak kétségeim. A legújabb gyári Zyxel kernelben nyomát sem látom az I2C buszon, 0x68 címen lógó egyszerű RTC chip támogatásának. Elvileg userspace szoftverrel is elérhető lehet az I2C, de az kinek és miért volna jó? A kernel drivert 1 órába sem tellett megírni hozzá, nyilván nem ez a gond. Erős a gyanúm, hogy nem véletlenül nincs a kernelben a driver. A gyártóknak bevett szokása, hogy egy adott hibaszázalék fölött egyszerűen a funkció szoftveres letiltásával vagy mellőzésével orvosolják a problémát. Jelenleg emiatt hajlok arra, hogy ne áldozzam időmet a problémás alkatrész cseréjére.

Zyxel rendszer alatt, telneten keresztül pl. az alábbi parancsokkal ellenőrizhető az óra:

i2cget -y 0 0x68 0;sleep 2;i2cget -y 0 0x68 0

Ha 2 másodperc alatt sem lépnek a 0-ás regiszterből kiolvasható másodpercek, akkor a probléma a fentivel azonos. Természetesen a HT1382 kicsit több munkával ugyan, de bármilyen I2C buszra köthető RTC chippel kiváltható. Talán később visszatérek még erre.

Egyébként nagyon sok eszköznél használnak a gyártók a Kirkwood mellett külön RTC chipet. Miért? Linux alatt támogatott, jól specifikált. Nyilván valami oka mégis van annak, hogy a gyártási költségek rovására is ennyire kerülik a gyártók a Kirkwood RTC-jét.

JTAG elérési pontok

Nekem nem volt szükségem a JTAG kapcsolatra, de ha már úgyis kibogarásztam, akkor megosztom ezt az infómorzsát. A JTAG az alaplap TP3-TP8 tesztpontjain érhető el.

A következő bejegyzésben a Debian telepítésről lesz szó. A jelenlegi állapotában már telepíthető és működőképes állapotú a kernel és a Debian rendszer. Sikerült megoldanom, hogy a Debian netboot telepítő beavatkozás nélkül konfigurálja fel a hálózatot, így az NSA320S-re akár szétszerelés és soros konzol nélkül, SSH-n keresztül telepíthető és testre szabható a legújabb Debian Linux. Remélem, hogy hamarosan már a végleges kernellel és beállításokkal futhat a Debian az NSA320S vason.

Folytatás következik…

Hivatkozások:

http://www.madadmin.com/zyxel-nsa320s-es-debian-linux-1-resz/
http://www.madadmin.com/zyxel-nsa320s-es-debian-linux-2-resz/
http://www.madadmin.com/zyxel-nsa320s-es-debian-linux-4-resz/
http://www.madadmin.com/zyxel-nsa320s-es-debian-linux-5-resz/
http://forum.doozan.com/
http://forum.nas-central.org/
https://www.kernel.org/
http://www.marvell.com/embedded-processors/kirkwood/
http://www.holtek.com.tw/english/docum/consumer/1382.htm