@@ -128,13 +128,13 @@ Az ötlet a következő volt: futtassuk a Windowsos programot egy VM-ben (Window
\begin{figure}[h] \label{fig:vm}
\centering
\includegraphics[width=300px]{vm}
\includegraphics[width=250px]{vm}
\caption{A mérési elrendezés}
\end{figure}
Azonban akadt egy kis probléma: néha a VM-en belül nem lehetett megnyitni a JTAG interfészt. Ezért kénytelen voltam egy régi Windows XP-re telepíteni a Logsys toolchaint és a WireSharkot. Azonban a Windowsos WireShark nem támogatja az USB folyam lehallgatását, így erre egy újabb segédprogramot, az USBPcap-et kellett telepítenem. De végül sikerült elegendő mérési adatot összegyűjtenem, ami alapján el tudtam kezdeni a Logsys GUI és az LDC közti protokoll felderítését.
A protokoll visszafejtését kezdetben szisztematikus teszteléssel végeztem: elindítottam a WireShark (vagy az USBPcap) csomagelkapását, megnyomtam egy gombot a Logsys GUI-n, leállítottam a csomagelfogást, és kielemeztem. Ezzel a módszerrel sikeresen megfejtettem az alap funkciók (tápfeszültség állítása, aszinkron reset, adatátviteli módok be-/kikapcsolása, JTAG lánc le\textit{tap}ogatása). Azonban bizonyos funkciókat nem lehetett ily módon megfejteni (ilyenek tipikusan az adatátvitelek, így például az egyik legfontosabb funkció, a JTAG interfészen keresztüli FPGA konfiguráció).
A protokoll visszafejtését kezdetben szisztematikus teszteléssel végeztem: elindítottam a WireShark (vagy az USBPcap) csomagelkapását, megnyomtam egy gombot a Logsys GUI-n, leállítottam a csomagelfogást, és kielemeztem. Ezzel a módszerrel sikeresen megfejtettem az alap funkciók (tápfeszültség állítása, aszinkron reset, adatátviteli módok be-/kikapcsolása, JTAG lánc letapogatása). Azonban bizonyos funkciókat nem lehetett ily módon megfejteni (ilyenek tipikusan az adatátvitelek, így például az egyik legfontosabb funkció, a JTAG interfészen keresztüli FPGA konfiguráció).
Így a későbbiekben nekiálltam a Logsys GUI "hagyományos" úton történő visszafejtésének is (decompile az ILSpy nevű program segítségével), amivel kiegészíthettem hiányos ismereteimet. Emellett időközben Raikovich Tamástól kaptam egy PDF-et, amiben leírja a (csomagelkapásból megfejthetetlen, bináris adatfolyamként érkező) struktúrák kiosztását. Ezenfelül fejlesztés közben jómagam is kutattam az Interneten további dokumentáció után, így akadtam például Wacha Gábor Qt alapú Logsys GUI-rekreációjára, aminek forráskódját készségesen rendelkezésemre bocsájtotta.
...
...
@@ -161,8 +161,9 @@ A saját implementációm hivatkozásánál a fájlok nevei és a sorszámok a k
\subsubsection{Státusz lekérése}
A Logsys GUI működése közben figyeli az LDC állapotleíróit (kimeneti feszültségek, kifolyó áram, túláram védelem bitje stb.), ezeket az információkat másodpercenként többször is lekérdezi az eszköztől.
@@ -317,8 +324,11 @@ Az IN kérés egy 10 bites, fixpontos kettes komplemens számot ad vissza, az OU
\subsubsection{Aktív átviteli mód lekérdezése}
Új adatátviteli mód megnyitása előtt célszerű megnézni, hogy van-e ütközés a korábban megnyitottakkal (bár ilyen esetben az LDC jelzi, hogy nem nyitható meg az átvitel). Az éppen aktív átviteli módot a következőképp kérdezhetjük le:
@@ -339,10 +349,11 @@ A visszaadott bájt jelzi az aktív átviteli módot (és 0 ha nincs megnyitva e
A kétféle JTAG módról a JTAG-ot tárgyaló fejezetben írok. Az egyes átviteli módok megnyitása/lezárása a róluk szóló fejezetben leírt kérésekkel történik.
\subsubsection{Órajel generálás}
Ha a CLK lábat nem használja egyetlen megnyitott átvitel sem, az LDC beépített négyszögjel-generátorának köszönhetően ki tudunk adni rajta egy órajelet.
Ha a CLK lábat nem használja egyetlen megnyitott átvitel sem, az LDC beépített négyszögjel-generátorának köszönhetően ki tudunk adni rajta egy órajelet (0,2 Hz és 8MHz között).
Ebben a módban TCK vonalra a megadott számú órajelpulzust lehet kiküldeni és a TMS vonal értéke a \textit{TMS} bit lesz.\cite{RT-dipterv} Ez a RUNTEST SVF parancsoknál hasznos. Ezt a módot nem használom, mivel a libxsvf elabsztrahálja előlem a RUNTEST parancsot.
Ebben a módban TCK vonalra a megadott számú órajelpulzust lehet kiküldeni és a TMS vonal értéke a \textit{TMS} bit lesz.\cite{RT-dipterv} Ez a RUNTEST SVF parancsoknál hasznos. Ezt a módot nem használom, mivel a libxsvf elfedi előlem a RUNTEST parancsot.
Ellenőrzés módban a számítógépnek ugyanannyi bájtot kell visszaolvasnia, mint amennyit elküldött.
A visszaolvasott bájtok közül csak minden második a hasznos TDO adat, a többi bájt értéke 0.\cite{RT-dipterv}
\noindent\textbf{FPGA konfigurációs fájlok}
A libxsvf-nek köszönhetően SVF és XSVF formátumú fájlokat képes a program natívan kezelni. Azonban a BIT (és JED) formátumok nem nyíltak, így azok kezeléséhez a Xilinx egyik segédprogramjával (iMPACT) át kell konvertálnom SVF-re. (ugyanezt teszi egyébként a Logsys GUI is).
A libxsvf-nek köszönhetően SVF és XSVF formátumú fájlokat képes a program natívan kezelni. Azonban a BIT (és JED) formátumok nem nyíltak, így azok kezeléséhez a Xilinx egyik segédprogramját használva (iMPACT) át kell konvertálnom SVF-re (ugyanezt teszi egyébként a Logsys GUI is).
A segédprogrammal való kommunikációhoz a libc \texttt{popen} metódusát használom, ami a Unix pipe-okat használja (a Logsys GUI pedig temporális fájlokat hoz létre ugyanerre a célra). Azonban az iMPACT-nak nem lehet megmondani, hogy ne hozzon létre logfájlt, így hogy ne szemetelje tele a munkakönyvtárat, a szubprocessz elindítása előtt átlépek a \texttt{/tmp} könyvtárba, ami Unix-szerű rendszereken általában bárki által írható és nem perzisztens tároló. Ennek következtében azonban elveszítjük a relatív útvonalak használatának lehetőségét (hiszen mappát váltunk, és az így a \texttt{/tmp}-hez képest értelmeződne).
...
...
@@ -575,8 +595,9 @@ Az adatátvitel történhet 8, 4, 2 vagy 1 MHz-es órajel mellett, ezenfelül t
@@ -728,8 +753,9 @@ A LDC képes a MISO, MOSI, CLK, RST és IOREF lábait használva szinkron BitBan
Az LDC vezérli a MOSI, CLK és RST lábakat, és a CLK fel- illetve lefutó éleire mintavételezi ezeket és a MISO lábat. Az órajel elindításához és az adatátvitel megkezdéséhez a következő két kérést kell elküldenünk:
@@ -855,7 +883,7 @@ A függvény feladata "összevárni" a homogén adatokat (legfeljebb 8-at), majd
A TMS írás feltétele, hogy a TDI "Don't Care" legyen (a kódban -1), a TMS pedig 0 vagy 1. A \texttt{dbit} egy ring countert valósít meg, ami az éppen írandó bitet jelöli ki. A \texttt{data} tárolja a kiírandó adatot, a \texttt{chk} a várt TDO értékeket, a \texttt{cmask} pedig a TDO maszkot.
Amíg a TMS írás feltétele fennáll, \texttt{data}-ban eltároljuk a kiírandó TMS értéket (a \texttt{dbit} által kijelölt biten), valamint ha TDO nem "Don't Care", akkor őt eltárojluk \texttt{chk}-ben és bebillentjük \texttt{cmask} megfelelő bitjét.
Amíg a TMS írás feltétele fennáll, \texttt{data}-ban eltároljuk a kiírandó TMS értéket (a \texttt{dbit} által kijelölt biten), valamint ha TDO nem "Don't Care", akkor őt eltároljuk \texttt{chk}-ben és bebillentjük \texttt{cmask} megfelelő bitjét.
Ha már összegyűjtöttünk 8 TCK pulzust, vagy már nem TMS írás történik, akkor \texttt{bulk\_out}-ban létrehozunk egy keretet a kiszámított értékek számára.
...
...
@@ -863,7 +891,7 @@ Ha már összegyűjtöttünk 8 TCK pulzust, vagy már nem TMS írás történik,
A TDI írás feltétele, hogy a TDI 0 vagy 1 legyen, a TMS pedig az utolsó bit kivételével 0 (az utolsó bitnél lehet más is, az lesz az 1. bájt 6. bitje, lást \ref{ssssec:JTAG xfer}/JTAG adatátvitel). A \texttt{dbit} itt is az éppen írandó bitet jelöli ki. A \texttt{data} tárolja a kiírandó adatot, a \texttt{chk} a várt TDO értékeket, a \texttt{cmask} pedig a TDO maszkot. Különbség csupán a \texttt{tmsAfter} változó jelenléte.
Amíg a TDI írás feltétele fennáll, \texttt{data}-ban eltároljuk a kiírandó TDI értéket (a \texttt{dbit} által kijelölt biten), valamint ha TDO nem "Don't Care", akkor őt eltárojluk \texttt{chk}-ben és bebillentjük \texttt{cmask} megfelelő bitjét.
Amíg a TDI írás feltétele fennáll, \texttt{data}-ban eltároljuk a kiírandó TDI értéket (a \texttt{dbit} által kijelölt biten), valamint ha TDO nem "Don't Care", akkor őt eltároljuk \texttt{chk}-ben és bebillentjük \texttt{cmask} megfelelő bitjét.
Ha már összegyűjtöttünk 8 TCK pulzust, vagy már nem TDI írás történik, esetleg elértünk egy TDI+TMS íráshoz (ami csak a TDI írás utolsó bitjeként szerepelhet), akkor \texttt{bulk\_out}-ban létrehozunk egy keretet a kiszámított értékek számára.