fupe píše:Ahoj MEXi,
zajímavé téma. Průběžně ho sleduju a čekám na každý další přízpěvěk.
Můžeš mi/nám osvětlit pár otázek. Určitě nebudu jedinej koho to zajímá.
Tak prvně by mě zajímalo, jak hluboko se musí člověk ponořit do protokolu a všeho okolo, aby byl schopnej hledat chyby ve zdrojacích a opravovat je. Z vlastní zkušenosti vím, že poměrně hluboko.V podstatě až na úroveň jednotivých bitu/bytu. Vycházel jsi z nejakého popisu standartu EPP?
Co obnáší uprava driveru? Alespon ve zkratce. Predpokladam, ze EPP komunikaci moc zarizeni nepouziva a tak tomu nikdo pred tebou nevenoval prilis pozornosti. Čínani to chrlej po milionech, ale normalni clovek pouzije rozsirujici kartu s LPT tak maximalne na starou tiskarnu.
Kolik drátů je použito na komunikaci? LPT ma standartně 8 bitu plus nejaky rizeni okolo. EPP jeste o neco malo navic. Pouziva vsechny? Je na zacatku komunikace nejaké dohadovani co kdo komu bude posilat jako je tomu u sserialu?
Mohl by jsi sem prihodit kus komunikace z analyzatoru s nejakym velmi hrubym popisem. Idelane nahranou komunikaci aby se do toho clovek mohl podivat.
Dalsí vec co me zajima je to, co chces zkoumat na ethernetovej kartach? Obsah jednotlivych paketu? Porovnat zpusob komunikace?
Jinak, kdyby jsi chtel pujčit PCI kartu, tak tu mam jednu nevyuzitou testovaci 5i22 1.5M, klidne ti ji zapujcim na prozkoumani.
Martin
Ahoj.
Jsem na cestách, tak odpovídám trochu se zpožděním a asi Ti nebudu hned schopný poslat nějaká záznamy komunikace, to až po návratu domů, tj. asi tak za týden.
Malá vsuvka: aby ten život nebyl tak jednoduchý, tak mi hned první den cesty zdechl mobil. Ne HW, ale SW. Řekl, že se mu nepovedlo rozcryptovat něco v systému, tak jediná možnost je totální tovární reset mobilu. Tudíž všecka data v prdeli, kurva!
Proč to píšu - připomínám 2 zlatá pravidla: zálohovat, zálohovat, zálohovat a nevěřit v neomylnost techniky.
Teď věcně k EPP. EPP je docela chytrý režim komunikace přes LPT, který je do jisté míry podporován HW a ulehčuje tak procesoru práci a zrychluje komunikaci.
Používá samozřejmě 8 datových linek D0-D7, které jsou zde používány obousměrně. Kromě nich používá ještě 3 signály z PC do periferie a jednu zpět z periferie do PC.
Ty 3 linky z PC jsou:
- Write - tady je to jasné, 0 znamená přenos z PC do periferie, 1 znamená naopak požadavek čtení
- Address Strobe - když jde signál dolů, začíná komunikace, tj. přenos 1 byte po EPP. Je-li současně aktivní Write, znamená to zápis 8bit adresy do periferie. Existuje i pro čtení, ale to se asi moc nepoužívá (Mesa to pro svou práci nepoužívá). Signál Strobe je aktivní po celou dobu přenosu jednoho byte, trvá max. 10us (je tam HW watch-dog), minimálně do doby než převzetí dat potvrdí periferie tím svým výstupním drátem. Ten time-out 10us zavedl standard EPP 1.9, ve starší verzi EPP 1.7 nebyl, a tak se při chybě komunikace teoreticky mohlo stát, že by se PC zaseklo, protože by trvale čekalo na potvrzení. Možná si uvědomuješ, že při nastavení LPT v BIOSu do režimu EPP se Tě to většinou ptá jestli 1.7 nebo 1.9, a nikdo neví, co tam má nastavit a proč. Tak teď už je to jasné, a rozhodně nastavit 1.9.
- Data Strobe - signál se stejnou funkčností jako Address Strobe, ale znamená, že se přenáší datový byte. Ten se už na rozdíl od Address Strobe používá velmi často i v režimu čtení.
Zpět vede drát Wait, kterým periferie potvrzuje převzetí dat (v režimu PC->periferie) nebo připravenost dat pro PC (v režimu periferie->PC).
Celý přenos provede na straně PC hardware, procesor jen vyšle nebo přečte data, o celý ten kolotoč s hand-shakingem se postará HW (neplatí tak zcela u PCI karet, viz dále).
Takže shrnuto: přenos adresy nebo dat probíhá prakticky stejně, jen v jednom případě to signalizuje linka Address Strobe a ve druhém případě Data Strobe.
Mesa to docela elegantně využívá pro svou komunikaci. Obecně se karta Mesa (asi všechny druhy, tedy i ty přes PCI a Ethernet) vůči systému tváří jako pole registrů, ty registry jsou seskupeny do sekcí.
Takže driver Mesy (tj. v tomto případě hm2_7i90.ko) komunikuje tak, že vyšle 16-bit adresu (tj. 2 přenosy po 1 byte), kde do Mesy pošle adresu začátku nějaké sekce registrů (např. sekci registrů s I/O vstupy), a pak cyklickým voláním čtení vytahá obsah celého bloku. Adresa těch registrů umí nastavit příznak, že se má automaticky zvyšovat čítač registrů, takže přenos adresy proběhne vždy jen na začátku bloku.
Po zpracování v driveru (v tomto případě už ve vyšší vrstvě, tj. v hostmot2.ko), kdy jsou spočteny požadované náplně stepgenů pro další periodu a jsou určeny stavy I/O linek pro výstup, to zase naadresuje pole výstupních registrů a datovými přenosy to zase nasype to Mesy.
Teď k problémům: standard EPP byl stanoven nějakým volným sdružením tuším 3 firem, a je v tom bordel. Docela slušně je nadefinováno chování na vlastní sběrnici, tj. co běhá po drátech. Ale blbě bylo nadefinováno chování toho, jak se má celý ten blok EPP chovat coby periferie v tom PC. Intel někdy v době uvedení procesoru 386SL udělal chipset, kde jako první zaintegroval HW podporu tohoto standardu. No a protože ten standard blbě nebo spíš vůbec nedefinoval, jak se to má chovat v systému, tak to ti ostatní pojali tak, že vzali tohle konkrétní implementaci řekli "a takhle je to správně, tak to má být".
Takže to defacto není žádný oficiálně definovaný standard, a podle toho to vypadá.
EPP se na většině základních desek chová stejně, jako to kdysi vymyslel ten Intel, proto to většinou funguje. Ale různí výrobci rozšiřujících desek (tedy ty PCI nebo PCIexpress I/O karty) to prostě pojali trochu jinak, neudělali to jako přesnou kopii, ale různě to "vylepšili".
No a to je to, oč zde běží. Mesa ve svém driveru implementovala komunikaci podle toho původního návrhu Intelu, takže to na LPT portech na základních deskách chodí (protože ti dodrželi/okopírovali ten původní Intel design). Kdežto na těch "vylepšených" to nechodí.
Návrháři ty PCI karty s chipem MCS9865 to vyřešili dost podobně, jako je to na těch základních deskách. Jen tam nedali automatické otáčení směru komunikace, a musí se to řešit programově v driveru. To ti Číňani byli se svým návrhem mnohem "kreativnější", a udělali to totálně jinak, pojali to koncepčně odlišně. Proto pokud se mi to povede dostat do oficiálních zdrojáků LinuxCNC, tak varianta pro karty MCS9865 se bude konfigurovat jen parametrem, kdežto varianta pro ty čínské desky bude prakticky jiný driver (ten ještě nemám napsaný).
Za zmínku ještě stojí, že drivery dle EPP 1.9 by měly umět i vícebytovou komunikaci, umí na jeden pokyn procesoru poslat 1, 2 nebo 4 byte. Na sběrnici se to stále tváří jako 4 nezávislé přenosy, ale pro PC to znamená tam jen jednou poslat 32 bitů. Tohle bohužel ty čínské desky neumí. Nicméně driver Mesa s tím už z dřívějška počítá, takže umí jet jak po bytech (parametr EPP_WIDE=0) nebo 32-bitech (EPP_WIDE=1).
Samozřejmě k těm PCI I/O kartám není žádná pořádná, případně vůbec žádná dokumentace. Takže tyhle hrátky znamenaly nekonečné série iterací pokus/omyl. Musel jsem k tomu napsat testovací SW pro Linux, a na druhé straně simulátor EPP s procesorem. Přímo s Mesou se pokusy moc dělat nedají, ta Ti jen prostě řekne "nefunguje to" a hotovo.
Ale to zrovna Tobě jistě nemusím říkat, sám si podobných radovánek s nezdokumentovaným chováním jistě užíváš dost a dost ve svém projektu SSerial.
Jinak to, co jsem popisoval, je rutinní chování v 1ms servocyklech. Po startu to stejně jako u Tvého SSerialu má dohadovací fázi, kdy si PC a Mesou vyříkají, co všechno Mesa poskytuje.
Rád Ti všechno naloguju a pošlu, ale teď jsem prostě týdne mimo.
K tomu Ethernetu: chci si udělat "odposlechové pracoviště", abych mohl sledovat provoz v obou směrech (podobně, jako to používám teď u EPP).
Protože u toho Eth řešení se dost blbě dostává na konkrétní signály (má to integráče v pouzdrech, kde se prakticky nedá rozumně měřit), tak chci vytvořit speciální firmware pro tuhle Mesu, která bude ty signály duplikovat na nějaké měřitelné piny. Tady ale zatím plavu, nicméně jsem si vzal na cesty knížku a nějaká skripta o VHDL.
Poznámka: už od pohledu je mi VHDL nesympatický. Verilog mi přijde výrazně bližší. Ale Mesa bohužel vsadila na VHDL.
V tomhle bych s Tebou (případně samozřejmě i někým jiným, VHDL-potentním) rád zaspolupracoval.
No a pak s tím mám další docela velké plány, ale o těch se zatím nebudu šířit. Budou samozřejmě poté veřejné, ale až (a pokud) se mi je povede realizovat.
