PM43 címkenyomtató megmentése: rossz firmware, 200 000 forintos alaplapcsere helyett

Egy teljesen ép, keveset használt ipari címkenyomtató állt a polcon, és egyetlen téves firmware miatt hulladék lett volna belőle. Nem hagytuk.

A saját műhelyünkben használt Intermec márkájú PM43 címkenyomtatóra (az Intermec mára a Honeywell része) tévedésből rossz firmware került. A gép többé nem indult el rendesen, és minden hivatalos út zsákutcának tűnt. A szervizek alaplapcserét javasoltak, nagyjából 200 000 forintos költséggel. Volt, aki az egész gépet lecserélte volna. Egy másik elektronikai csapat is nekifutott, és nem boldogult vele. Maga a gyártó, a Honeywell sem tudta megoldani és megjavítani. Mi ennél tovább mentünk.

Mi történt a géppel?

A nyomtató régi hardverrevíziójú, a hozzá való firmware pedig a P10-es család. Rá viszont az xA változat került, amelyet a PM43A típushoz készítettek. A gép ettől kezdve a Bluetooth-LED-nél megállt. A hiba jellegéből arra következtettünk, hogy az indítókód (a bootloader) valószínűleg ép, a rá épülő kernel, az FPGA-konfiguráció és a fájlrendszer viszont nem megfelelő.

Ilyenkor az ember a megszokott eszközökhöz nyúlna, de egyik sem működött:

• USB-s frissítés: a gép addig sem jut el, hogy a frissítőt elindítsa.
• Soros konzol: a hátsó RS-232 porton és a panelen sem találtunk használható kimenetet.
• JTAG: a processzor reset-lába nem működött, ezért a gépet nem lehetett megbízhatóan megállítani.

Miért nem javítja meg senki?

Egy panelcsere kiszámítható és gyors. Ehhez a hibához viszont nem találtunk dokumentált helyreállítási utat, és a gyártó, a Honeywell sem tudott segíteni: a processzor részletei csak nyílt forrásokból deríthetők ki. A válasz ezért mindenhol ugyanaz volt: cseréljük ki az alaplapot, vagy az egész gépet.

Egy ép gép esetén ez azt jelenti, hogy egy tökéletesen működő hardver kerül a hulladékba egy szoftveres hiba miatt. Ez volt az, ami nem hagyott nyugodni.

A kulcs: a processzor saját, beépített módja

A PM43 fő processzora egy NXP (Freescale) i.MX25. Az ilyen chipek gyárilag tartalmaznak egy ROM-ba égetett soros letöltő módot, amelyet a panelen egy jumper beállításával lehet elérni. Ebben az állapotban a processzor USB-n megjelenik a számítógépen, és kívülről utasítható. Ezt a módot eredetileg a gyártás használja.

Az előző próbálkozások itt akadtak el: a ROM-letöltő a RAM-ba tölt be, a gép memóriájának (DDR2) beállításai viszont nem ismertek, így futtatható kódot sem lehet elindítani. Mi másik irányból közelítettünk: a processzor beépített NAND-vezérlőjét közvetlenül, a számítógépről irányítottuk. Így a gép memóriájának működésére sem volt szükség, és az érintetlen bootloader sem került veszélybe.

Hogyan épült fel a megoldás?

• Saját eszköz: megírtuk a saját USB-kliensünket a ROM-letöltő protokollhoz. Kiderült, hogy az i.MX25 a régebbi, gyártóspecifikus „bulk” protokollt használja, nem a mai eszközöknél megszokott HID-et.
• Hardver feltérképezése: a kernel és a firmware elemzéséből megtudtuk a NAND memória partíciós térképét (bootloader, FPGA, kernel, fájlrendszer), és a firmware-csomag belső felépítését (FPGA-konfiguráció, Linux-kernel, UBI fájlrendszer-kép).
• Az első jel: a NAND-chip azonosítója kiolvasható volt. Ez egyértelműen egy Samsung K9F1G08U0D (128 MB) memóriát jelzett, vagyis az adatsín, a vezérlőjelek és az órajel rendben van.
• Védelem: a kódba beégettük, hogy a bootloader-partíción semmit sem írhat felül. Ez volt a visszaút biztosítéka.
• Írás és ellenőrzés: a firmware részeit a megfelelő partíciókba képeztük le, a memória saját hibajavító (ECC) elrendezésében, hogy a rendszer utána helyesen olvassa vissza. Az írás után mindent visszaolvastunk és összehasonlítottunk.

Ami közben a legtöbb időt vitte

A munka nagyobb része nem a „nagy ötlet”, hanem a részletek kiderítése volt. Néhány példa, amelyekből később mi is tanultunk:

• Az USB-eszköz átadása a Windows és a Linux (WSL) között több ponton megbukott: a virtuális gép leállt, ha nem volt futó folyamat, a jogosultságok nem engedték az eszköz elérését, az ékezetes útvonal pedig elrontotta a parancsokat.
• A memóriaolvasás egy ponton megállt: a ROM minden lapolvasásnál lefagyott, és csak a gép újraindítása segített. Végigmentünk a gyanúsítottakon (lábkiosztás, ready/busy jel, lapméret, USB-időzítés), és mindet kizártuk. A ROM háttérben futó watchdogja is gyanús lett, amit az eszköznek rendszeresen „etetnie” kell.
• Menet közben a saját tévedéseinket is rögzítettük: egy hibás státuszlekérdezést, egy rossz pad-címet, egy rossz regisztercímet. Mindegyik félrevezethetett volna, de így visszakövethetőek maradtak.

Az eredmény

A nyomtató újra működik, és a megfelelő firmware fut rajta. Nem kellett alaplapot cserélni, és az ép, keveset használt gép nem lett elektronikai hulladék.

Mit tanultunk belőle?

• A ROM-letöltő mód gyakran nem „csak betöltő”. A parancsai tetszőleges memória- és perifériaelérést adnak, így egy teljes vezérlőt a gazdagépről is meg lehet hajtani, a gép saját RAM-jának ismerete nélkül.
• A dokumentáció hiányát a nyílt forráskód pótolja. A Linux-kernel, az U-Boot és a barebox forrásából kiolvashatók a regiszterek és a sorrendek, de verzióra érzékenyek.
• A „lefagyás” nem mindig a megfigyelt művelet hibája. A rejtett változókat (watchdog, órakapuk) is gyanúsítani kell, és minden kísérlet előtt tiszta állapotból kell indulni.
• A javítás gyakran olcsóbb és fenntarthatóbb a cserénél. Egy ép gép kidobása nem csak pénz, hanem hulladék is.

Miért írjuk le?

Mert ugyanez a hozzáállás van a munkánk mögött. A legtöbb akadály nem technikai, hanem az, hogy valaki feladja. Ha nálatok is van olyan gép, rendszer vagy eszköz, amire azt mondták, hogy „nem éri meg javítani”, vagy egyedi rendszert, beágyazott megoldást, hálózati vagy biztonságtechnikai fejlesztést kell építeni, nézd meg az egyedi rendszereket és az üzemeltetést, vagy írj nekünk.