flash chip felprogramozás hol? hogyan?

Lehet, hogy majd szükségem lenne majd pár eszköz flash memóriájának újraírására/átmásolására. Ehhez nekem sem eszközöm, sem szakértelmem nincs.
Hol lehetne ilyen szolgáltatást találni? Nyilván villamosmérnököknek lehet ehhez meg a szakértelme és a szükséges eszközparkja. Csak ilyen szolgáltatást sehol sem látok hirdetve.
Hol lehetne ilyesmit találni? Vagy csak szívességi alapon lehet ilyet?

Hozzászólások

FLASH IC típusa lendítene a dolgon. Akkor lehet jelentkezne valaki, akinek van hozzá cucca. 

Tippem szerint neked soklábú FLASH IC-d van, azt hűlégfuvóval ki kell szedni előbb, majd azt egy adapterpanelra tenni, onnan programozóba.
Ezeknél a típusoknál szokott lenni olyan hogy valamelyik cím lábat fixen GND-re teszik amíg bootol, majd emiatt sérültnek érzi a bootloader a benne lévő adatot. Ilyenkor a bootloader gyárilag TFTP-n várja az adatot. Routereknél láttam ilyen halálból feltámasztás dolgot. Persze nem mindennél működik. De lehetséges, hogy ilyen bootloader van neked is a cuccodban.

Van mit bele írnod?

Igen, soklábú. A pontos típus: 29LV160DBTI-70G. Az biztos hogy 16 Mbit-es a flash chip.

Sajnos nem láttam rajta kivezetve TTL soros portot, úgyhogy boot konzolom nem nagyon lesz hozzá.

Még nincs, de ha ezt meg tudom oldani, akkor tudok venni egy feloldott működő példányt, aminek a flash-e lehet hogy jó lesz mint forrás.

Szerintem ezek a cuccok annyira véglegesre vannak integrálva, hogy soros porti pin header, annak a helye, vagy csak sima pad-ek sincsenek a NYÁK-on. Ezért írtam, hogy szerintem kis esélyem van soros boot konzolt szerezni hozzá.

Linksys SPA2102 az eszköz.

Az az elképzelés, hogy ha sikerülne szerezni egy unlock-olt SPA2102-t, akkor annak a flash-ének az átmásolásával talán sikerülne a másik 3 ilyen eszközt is jobb belátásra téríteni, hogy ők nem úgynevezett RC eszközök, akiknek az a dolga, hogy a kezdeti konfigjukat egy nem létező szerverről letöltsék.
Kérdés természetesen, hogy ezzel az eszköz MAC-címe, egyedi kliens certje, sorozatszáma is vajon klónozódna, vagy esetleg az nem a flash-ben lakik, hanem a fő chip-ben esetleg valamilyen valamilyen tartós tárban.

OK, de ez nem egy DIP tokos EPROM foglalatban, hanem egy 48 lábú TSOP tok, amelyet frissen beültetnek a helyére, majd az áramkörben lévő mikrokontroller ír bele olyan adatokat, amelyeket nem kellene elfelejteni tápfeszültség kikapcsolásakor sem, vagy van az MCU-ban egy boot loader, vagy helyesebben firmware updater, amely valahonnan, pl. USB-n, UART-on, Etherneten TFTP-n kapott kódot beleír, majd innen, a flash memóriából futtat. Nem arra találták ki, hogy másolják a benne lévő tartalmat. Mégis hogyan? Kiforrasztja hőlégfúvóval? Biztos, hogy nem sérül a nyák, nem kócolódnak össze a lábai, valamint a chip a tárolt adattal együtt kibírja a hősokkot? Ha kiforrasztotta, mit csinál vele? Beépíti egy saját tervezésű hardware-be, amelyik kiolvassa a tartalmat, s azt elküldi USB-n PC-re, mahol file-ba írjuk? Mondjuk ez is megvan. Hogyan írjuk a tartalmat a csupasz flash memóriákba? A cél helyen kellene, de annak működéséről semmit sem tudunk. Akkor foglalat TSOP48-hoz? Lehet, hogy van ilyen csoda, bár elképzelni nem tudom. A 0.25 mm széles lábak nem sérülnek? Nincs ültetetlen PCB-je. Onnan is kiszedi a már ott lévő flash memóriát? Nem sérülnek a nyákok, majd beülteti a fene tudja, hogyan megírt memóriákat? Hogyan ülteti be? Mert géppel kéne.

Ez mennyi idő? Mennyi fejlesztés? Mennyi pénz? Megéri? Mi ez az áramkör? Nem lenne egyszerűbb egy funkcionálisan kompatibilis hardware-t tervezni elölről? Mert bármennyire ijesztő, ez tűnik egyszerűbb, járhatóbb útnak. Egyáltalán ennek az áramkörnek ismert a specifikációja? Ha nem, akkor nem lehet, hogy ennek oka van? Orvosi műszert, autót, gázkazánt, HDD-t nem biztos, hogy ilyen módon kellene otthon hekkelni. Lehetnek benne kalibrációs paraméterek, olyan adatok, ami a másik környezetben nem a kívánt eredményt adja. Lehetnek egyedi azonosítók, lehet bármi, ami nem úgy működik, hogy lemásolom, és készen is vagyunk. Még akkor sem, ha látszólag jól működik.

Jaj, bocs, benéztem valamit. Mindegy már, nem törlöm, amit írtam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

99%, hogy igazad van :) De van az a ritka eset, hogy ugy rendelik meg, hogy a memoria gyarto ceg a gyartas utan beleir nekik egy custom binarist.

Ilyen szolgaltatas amugy letezik MCU-k eseteben is, altalaban custom bootloaderek kerunlnek bele.

De ha ez az az eszkoz amit fentebb linkeltek, akkor tuti valahol ott csung egy u-boot.

itt vannak fotok a NYAK mind2 oldalarol:

https://www.aliexpress.com/item/1005003168187874.html

de en se latok igy elso blikkre soros kivezetest sehol :(

viszont volt mar dolgom olyan eszkozzel, amit bekapcskor 1-2 masodpercig egy fix ip-n el lehetett erni a lan portjan, es ha akkor azonnal ratoltad tftp-n a firmwaret akkor az felulirta, gyarilag is vszinu igy programoztak fel.

SPA2102: felső oldal, alsó oldal.

Érdekességképp: most jött egy PAP2T: alsó oldal, felső oldal

Maga a műanyag doboz kivitelének minőségén és a felhasznált chipeken látszik, hogy a PAP2T mennyivel low-costabb volt. (Nem gondolom hogy hamisítvány lenne, mert a szitázás hasonló a két nyákon. Lehet, hogy ez a PAP2T már sokadik generációs cucc, ami több költségmegtakarítási cikluson is túl volt már addigra.)
Az IVR menü is különböző a kettő között. A PAP2T-ben egy férfihang mondja, hogy Sipura IVR menu, az SPA2102-ben pedig egy női hang mondja, hogy Linksys IVR menu...

A képek jobb oldalán, a felső oldal esetén az alsó részen, az alsón oldalnál meg a felső részen, ugye? (Szerk: megtaláltam mindkettőt.)
Sajnos oszcilloszkópom nincs, ezért is keresek villamosmérnököt a történethez.

A villamosmérnökökkel az a baj, hogy amikor nem dolgoznak, akkor végre pihennének, észrevennék, hogy van élet a szakmán kívül is. Arról nem is beszélve, hogy cseppet sem motiváló a gányolás, mert ez az lenne. Nem mérnöki munka, hanem lelkes amatőröknek való hekkelés, amelyben olyan kihívások vannak, hogy tönkremegy-e a chip vagy a PCB, összekócolódnak-e a tok lábai, egyáltalán elindul-e egyedi adatokat is tartalmazó flash tartalommal a másik eszköz.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem feltétlenül Rád gondoltam. Sok esetben, más ügyekben segítettél itt a fórumban nekem. (Amit ezúton is köszönök.)
A scope amúgy sem az, hogy "csinálja meg működőre", csak van jelenleg 3 ilyen eszközöm, ami nem nagyon alkalmas másra mint papírnehezéknek.
Gondoltam, még ez az egy esély van, amit lehet érdemes megpróbálni (mármint a flash tartalmát átmásolni egyik eszközről a másikra).
De biztos van olyan nem végzett villamosmérnök, vagy egyéb eszközök firmware-ének piszkálgatásához odakeveredett egyén vagy hobbista, aki a technikai feladatot meg tudja oldani, esetleg ha a témához nagyobb mélységben is hozzá tud szólni, akkor annál jobb.

Évekkel ezelőtt próbáltam hasonló tokozású flash IC-t, valami fejlesztő boardon volt... sikerült írni és olvasni is, de eléggé elment a kedvem tőle, mert volt valami viszonylag nagy szektorméret, plusz szektoronként néhány byte(?) hibakezelésre használandó terület - nem emlékszem már pontosan...

Ennél azt írja, van 1x16 kByte, 2x8 kByte, 32x1 kByte és 31x64 kB szektor rajt.

Tényleg macera, mert kell hozzá egy board, amin ilyen tokozású flash van kiépítve, át kell forrasztani rá, megcsinálni a kiolvasását (úgy, hogy tényleg jól működjön), be a másik IC-t, kiírni rá, és utána vissza a cél boardra...

Tehát kell némi előkészület (vagy szerencse, amennyiben nagyon hasonló IC-t használt már az ember)...

Természetesen, megvannak a maga nehézségei. Azért nem én szeretném csinálni, mert pár éve próbáltam hasonló lábszámú/lábközű SDRAM chipet cserélni egy Linksys routerben, de sajnos az nem jött be. Sajnos nem lett jó az eszköz, hiába túnt jónak a datasheet alapján a beépített IC. Én max lelkes amatőr vagyok (szeretek forrasztani), kevés szabadidővel, és a szükséges ismeretek és gyakorlat és jártasság birtokában sem vagyok. Ezért keresnék majd valaki olyat, aki nálam nagyobb tapasztalattal bír, és hajlandó ilyesmire.

Amúgy rengeteg videó van fenn a neten arról, hogy chip-eket cserélnek, boardokat upgrade-elnek (legutóbb pl olyat láttam, hogy régi Apple TV-be cseréltek RAM-ot hőlégfúvó segítségével.. 256MB ram helyett 512-t raktak bele. Közben leszedték a nyákról a bios flash chip-et is, hogy Hex-editorral módosítsák az időzítéseket, egyéb paramétereit a RAM modulok inicializáló kódjának, majd a módosított tartalmat flash-elték vissza.)

Nem tűnik egyébként veszélyesebb műveletnek ez a hőlégfúvóval ki/berakás, mint forrasztgatni az IC-k lábait, sőt a végeredmény a technikából kifolyólag sokkal szebb is lesz. Megkockáztatom, hogy még egyszerűbb is.

(Ennél az Apple TV-s esetnél pl az adta a plusz bonyolultságot, hogy a BGA pad-ekre nem volt kivezetve a memóriavezérlő összes vezetéke, így azokat különböző teszt-pontokról kellett oda jumper-wire-öznie a srácnak. Na arra már azt mondom, hogy kell tudni valamit :D)

Már bocsi, de arról is rengeteg videó van, hogy két indiai a két kezével sárból földbe süllyesztett medencét épít, hálókamrával.
LIDL-ből származó hőlégfúvóval nem esnék neki, a Conrad-ból pedig most nem vennék 70-80 eFt-ért forrólevegős forrasztóállomást, ennek az egy projektnek a kedvéért.
Plusz a további részéhez sincs meg a szükséges eszközöm és jártasságom. Ezért is keresek valakit.

A topic eredetileg azzal a kérdéssel indult, hogy kihez érdemes/lehet ilyennel fordulni. Nem pedig az, hogy ~100-150 eFt és jópár hét szabadidő befektetésével hogyan lehetne beszerezni a megfelelő eszközöket és tapasztalatot, hogy végül a dolgot DIY módon oldjam meg.

Egyébként (ha már említésre került) valami ilyesmivel már neki lehet állni, csak nem árt tudni, hogy a 230V-os fűtőszálat tartod a kezedben (és megy a vezetékén), valamint némi tapasztalat sem árt hozzá...

Lehet, próbálkoznék még kicsit a szoftveres részével (valahogy rávenni firmware letöltésre)...

Volt nekem korábban Conrad-os, hasonló cuccom (igényesebb kivitelben), de most már nincs meg.

Sajnos a fórumokon amiket végigböngésztem nem volt szó debug UART lábakról, vagy default bootkor megszólítható IP címről sehol, a doksiban pedig végképp nem. Próbálkozni próbálkozhatunk, csak nem tudom mire megyünk.
Tcpdump-pal figyelgettem, hogy boot során mi történik, de a DHCP kérésen és a hazatelefonáláson kívül sajnos nem láttam semmit. Az meg sajnos kellően körül látszik bástyázva, így DNS spoofolással és custom certtel nem mentem semmire, mert a firmware látja, hogy nem én vagyok az, akit ő keres...

Nem, sajnos nem. Mivel alapból HTTPS-sel indít, a TLS kapcsolat sem épül fel hogy átirányíthassam. Ha pedig például nincs válasz, akkor nem próbálkozik újra HTTP-n. A Provisioning Guide-ban leírják, hogy a firmware-ben benne van a Linksys CA-jának a certje, és az által aláírt certeket tekint csak validnak.

Így, hogy "Linksys SPA 2102 recovery tool" nem keresgéltem, de az unlock-olási megoldások között biztos említették volna, ha létezik ilyen.

Igen, de az nem RC-s eszköz, hanem az egyik service provider által előre customizált. Az enyémek sosem voltak customizálva, és már nem is nagyon lesznek.

 

Szerk: minden esetre átolvasom még egyszer, és megnézem mi alkalmazható belőle az én helyzetemben.
Szerk2: megpróbálom az admin felület visszakapcsolós IVR-es megoldást, és a hozzá kapcsolódó kierőszakolt config resync-et... (stay tuned)
Szerk3: megpróbáltam, de a telefonos admin felület feloldás elrontás után is csak a prov.sipura.net-re próbált felcsattanni. Úgyhogy ez sajnos nem használható.

Nem bonyolult, de egy mikrokontrollert azért igényel. Nézd meg a flow chart-okat, illetve azt a megoldást, hogy nem 32 azonos méretű szektor van, hanem sok azonos, néhány eltérő, így van 35 szektor.

Az ilyesmit úgy szokás tervezni, hogy a firmware vagy data loader abban az MCU-ban van, amelyhez ezt az izét csatlakoztatták. Eléggé nyűgösnek érzem 0.5 mm lábtávolságú IC-t felprogramozni az áramkörön kívül, majd beültetni. Nem világos a koncepció. Ez nem arra van kitalálva, hogy epromégetővel beégetjük az adatot, majd betesszük az IC foglalatba. Hiszen:

PACKAGE
48-Pin TSOP
48-Ball CSP (TFBGA)
48-Ball WFBGA/XFLGA

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én is most tervezek 144 lábú LQFP tokos eszközzel és szintén rakok rá programozó csatlakozót - bár legutóbb már tüskesort nem forrasztottam be, hanem rugalmas "tapintó csúccsal" került bele a saját bootloader (gondolom, ez lesz a firmware letöltő és vezérlést átadó csoda).
A bootloader meg képes ellenőrizni és betölteni a firmware-t USB MSC eszközről vagy SPI flashről - persze a frissítő file azért titkosítva van, a kontroller meg lezárva. :)

Igen, a boot loaderre gondoltam, sőt, magam is úgy nevezem, csak elgondolkodtam azon, hogy épp boot loaderként minimális a funkciója. Átadja ugyan a vezérlést a fő programra, nem is triviális a folyamat, tekintve, hogy az entry point és a main() közé a C fordító tesz egy láthatatlan inicializálást, továbbá a hardware reset vektor szükségképpen ugyanaz akar lenni a boot loaderben és a végleges kódban, tehát a linker scriptet is gyurmázni kell. De minderre semmi szükség nem lenne, ha a boot loader nem is létezne. :) Tehát inkább az a feladata, hogy valamilyen interface-en benyeljen egy file-t, stream-et, majd flash memóriába írja. Ez viszont nem boot folyamat, hanem firmware upgrade.

Szóval ezért fogalmaztam ilyen ügyetlenül fentebb.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha a bootloader csak annyit csinal hogy berantja a fw-t valahonnan (pl kulso flash-bol) es utana elinditja, majd ez a fw kepes (csak) arra hogy modositja sajat magat az elkepeszto modon kockazatos :))

hogy az entry point és a main() közé a C fordító tesz egy láthatatlan inicializálást

Na, ez viszont mindig is erdekelt hogy ezen hogyan is lehet finomhangolni. Pl az avr-gcc valamiket beletesz magatol teljesen custom architektura eseten is, az arm-none-eabi-gcc pedig nem igazan... igaz, nem is foglalkoztam ezzel reszletesebben, csak megallapitottam h "ez ilyen", es ettol fuggetlenul minden fasza.

Nem, félreértettél. Van ez a szerintem helytelenül bootloader-nek nevezett kód a flash-ben, amely gyártáskor ICSP-n kerül az MCU flash memóriájába. Ez képes fogadni pl. USB-n megfelelő parancsokra külső file-t, amelyet bele tud írni a saját flash-ébe, de természetesen a bootloader-t nem írja felül. Aztán képes átadni a vezérlést erre a letöltött firmware-re. Mindig a bootloader indul reset után annak érdekében, hogy ha idiotizmust töltene le az ember, akkor a javított programot is le lehessen tölteni, ne zárjuk ki magunkat. Az lényegtelen, hogy USB-n adunk neki olyan parancsot, hogy induljon el a letöltött firmware, vagy timeout után indul.

Abban a kódban nem full hardware init van, csak alapok. Pl. cache vezérlő inicializálása, megszakítás vektotok báziscímének initje, órajel, stack pointer, ilyesmik. Több nem kell. Az USB, UART, portok, SPI, PWM, A/D konverteek, D/A, komparátorok, DMA, timerek már mind mehetnek a main()-ből hívott sysinit()-ből.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Igen, a boot loader inkább azért van, hogy pl. felhasználónál is frissíthető legyen a firmware (vagy szervizes által), vagy akár távoli szoftverfrissítés lehetősége miatt, de szoftverfutás szempontjából bonyolít.
...és ugye ugyanúgy kellene átadnia a futást a főprogramnak mintha nem lenne loader, ergo szépen deinicalizálni kell mindent, ill. alaphelyzetbe állítani...

...és mint olyan, többé-kevésbé lassít is az indulási folyamaton, mert ellenőriznie kell, van-e dolga egyáltalán vagy indulhat a főprogram (ergo boot).
Ok, ez utóbbi indulhat pl. egy GND / VCC-re húzás figyelésével (nyomógomb állapota) is, akkor gyors lesz a normál indulás.

Tehát valóban, sokkal több feladata van annak a kódnak.
Nem belekötni akartam, csak tetszett a körülírás. :)