regiszter átírása

Linux-haladó

Sziasztok!

Nagyon nem találok megoldást a következő problémámra, ezért fordulok hozzátok, hátha akad itt valaki ismét, aki jártasabb a témában...

Adott egy S3C2416 procis ARM gép, jelenleg 2.6.39-es kernel-lel. 2 USB portja van, amelyből az egyik HOST, a másik HOST/DEVICE módot tud. A második nem reagál mint HOST - eszközként is mondjuk csak VID 0000 / PID 0000 látszik belőle, de ez most nem érdekes. Szóval 2 HOST portra lenne szükségem. A doksi szerint reset után az alapértelmezett módja az eszköz állapot:

http://www.timll.com/chinese/download/files/S3C2416X_datasheet.pdf

116-dik oldal, 8.9 USB PHY CONTROL REGISTER (PHYCTRL) > DOWNSTREAM_PORT

Ezt kellene valahogy átbökni 1-re. Mivel magam fordítom hozzá a kernel-t, ezért akár az is tökéletesen megfelelne, ha valahol a forrás fájlokban lehetne átírni fixen. Tudna valaki segíteni?

  • 4069 megtekintés

( yorkeetech | 2012. 05. 02., sze – 20:43 )

Talán a legegyszerúbb az lenne, ha csinálnál egy modult, ami bootoláskor betölt, és megpiszkálja az adott memóriacímet.

Egyébként anno beágyazott rendszerek gyaksziról rémlik valami hasonló, igaz ott egy ledet kellett villogtatni, és elég volt a megfelelő memóriacímre belökni a megfelelően beállított biteket valahogy így:
*(long*)0x4C000080 = 0x00001011;

Nem tudom segít-e ez valamit, ha hülyeséget írtam v nem ez volt a kérdés, akkor bocs :)

----------------
"Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders" +1

hát nem szép, nem is elegáns, viszont olvashatatlan és veszélyes :)

mi egyébként anno pár egyszerű makrón keresztül piszkáltuk memóriát, valahogy így:
#define outb(n,c) (*((volatile unsigned char *)(n)) = (c))
de végülis csak példának szántam, nem tudom egyébként mi az elfogadott, sajnos ilyesmiben nem sok tapasztalatom van.

közben eszembe jutott, egyébként lehet, hogy az ilyesmit minden további nélkül meg lehet oldani udev szabályokkal, illetve az usb driver paraméterezésével.

----------------
"Saying that Java is nice because it works on all OS's is like saying that anal sex is nice because it works on all genders" +1

( vl v | 2012. 05. 02., sze – 22:07 )

Nem értem egészen, hogy mit is szeretnél. Illetve hogy hogyan képzeled ezt megoldásnak.
Ha nincs drivered ahhoz az USB porthoz a kerneledben, akkor hiába "bököd át" 1-re, akkor sem fog csinálni semmit se. Ha meg van, akkor annak kéne ezt megcsinálnia, ha jól meg van írva, akkor amúgy megcsinálja ezt magától is. Egészen pontosan a dual-mode USB portoknak van egy extra lába, ami arra való, hogy a beledugott kábel rövidrezárja, a gép meg érzékeli ezt, és eszerint állítja host vagy device módba a portot a driver (amilyen a rádugott kábel, annak megfelelően).

( FPeter84 | 2012. 05. 03., cs – 01:55 )

még1x nekifutok :)

szóval van driver, helyes a bekötés, host mód megy az egyik porton, de a másik port eszköz módban inicializálódik ha minden igaz. a módváltást magának a drivernek kéne intéznie annak megfelelően, hogy az adott INT lábra megkapja e a tápot vagy sem? azt hittem az csak a szoftveres beolvasásra van, de valami saját programnak kellene átkapcsolnia... turkálom a mach / plat fájlokat, hátha sikerül rájönnöm hogy hol a hiba. talán más GPIO INT lábra van definiálva, mint az én modulomon...

Nézd meg milyen csatlakozó van a dobozon. Ha az itt látható mini-AB akkor van esélyed működésre bírni. Kell hozzá ilyen kábel. Amikor ezt bedugod, akkor a driver érzékeli, hogy host módban kell mennie, és vált. Ha nem vált, akkor bukta. Egy szó mint 100, attól függően fog host vagy device módban menni, hogy milyen kábelt dugsz bele. A te esetedben a kábelen a csatlakozó fogja az ID lábat megfelelő állapotba húzni.

ennyire vágod a témát, hogy ilyen gyorsan megtalálod hogy hol mit nézz, vagy esetleg volt is már dolgod ezzel a platformmal? :)

eredetileg nem volt semmi vonatkozó se a gpio-cfg.c -ben, se a mach-smdk2416.c -ben, de rátaláltam erre a patch sorra:

http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050916.h…
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050917.h…
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050918.h…
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050919.h…
http://lists.infradead.org/pipermail/linux-arm-kernel/2011-May/050920.h…

volt 1 ütközés - nem talált valami sort ami mögé be kellett volna szúrnia egy másikat, de be tudtam azonosítani így pótoltam manuálisan, a fordítás is lement, de továbbra sem működik... mostmár a 4-es patch-nek megfelelően ott van a mach-smdk2416.c -ben a GPH14 és GPF2 is - de mi az a GPH14 ? miért van kettő? a GPF2-t az általam használt SOM2416-II modul KIT kapcsolásának megfelelően némi ellenállásosztón keresztül rákötöttem az eszköz aljzat bejövő táp ágára (USB mini A 1-es lába)

http://pc2car.hu/images/users/fpeter/SOM2416/KIT2416-II-sch.pdf
http://pc2car.hu/images/users/fpeter/SOM2416/SOM2416.pdf

az utóbbi az én kapcsolásom. úgy terveztem, hogy van rajta egy mini A aljzat az eszköz módnak, valamint egy normál A alj a host módnak. a két jumperrel le lehet választani a host módhoz szükséges 2x 15K PD ellenállatokat, hogy ne zavarjanak be az eszköz módba. tehát elvileg megfelel a másik kapcsolásnak...

az eredeti samsung-féle smdk2416 kapcsrajzból csak ezt a kivonatot sikerült megtalálnom:
http://read.pudn.com/downloads141/ebook/609637/SMDK2416_Users_Manual_re…
kissé szűkszavú, de ha jól értelmezem, akkor itt is egy meg nem nevezett GPIO INT lábra kötik be ellenállásosztón keresztül az aljzatból jövő 5V-ot...

ami még egy érdekes jelenség, hogy próbából lekötöttem a 2 ellenállást, így a levegőben lóg a GPF2, és amikor bedugok a HOST aljzatba egy eszközt, akkor H jelszint jelenik meg ezen a lábon, ha kihúzom akkor eltűnik. ez így volt az előző kernellel is aminél még sehol nem szerepelt a GPF2, és így viselkedik a patch-elés után is...

az USB wifi adapternél általad ajánlott módon beraktam ismét az mdev.conf-ba egy általános, minden esemény env-jét egy fájlba átirányító hotplug event-et, de semmi. a másik működő port annak rendje és módja szerint ír bele, de a problémás aljzat semmit nem mozdít...

a 4dik patch-ben ez van:

s3c24xx_hsudc_set_platdata(&smdk2416_hsudc_platdata);

amit pedig paraméterként kap:

struct s3c24xx_hsudc_platdata smdk2416_hsudc_platdata = {
.epnum = 9,
.gpio_init = smdk2416_hsudc_gpio_init,
.gpio_uninit = smdk2416_hsudc_gpio_uninit,
};

init / uninit:

void smdk2416_hsudc_gpio_init(void)
{
s3c_gpio_setpull(S3C2410_GPH(14), S3C_GPIO_PULL_UP);
s3c_gpio_setpull(S3C2410_GPF(2), S3C_GPIO_PULL_NONE);
s3c_gpio_cfgpin(S3C2410_GPH(14), S3C_GPIO_SFN(1));
s3c2410_modify_misccr(S3C2416_MISCCR_SEL_SUSPND, 0);
}

void smdk2416_hsudc_gpio_uninit(void)
{
s3c2410_modify_misccr(S3C2416_MISCCR_SEL_SUSPND, 1);
s3c_gpio_setpull(S3C2410_GPH(14), S3C_GPIO_PULL_NONE);
s3c_gpio_cfgpin(S3C2410_GPH(14), S3C_GPIO_SFN(0));
}

gondolom ezek lennének az általad emlegetett .vbus_pin, .vbus_pin_inverted paraméterek, csak nincsen mellettük magyarázat... de a GPH14-et továbbra se tudom hová tenni :S

egyelőre feladtam, mert vannak fontosabb pontjai is a projektnek - ráadásul mostmár egyértelműen kiderült számomra, hogy a procim valójában 1 USB HOST porttal rendelkezik csak, és egy belső HUB csinál belőle kettőt - vagyis cirka mindegy, hogy megy e a 2 port vagy sem, vagy csak az 1 működő portjára dugok egy újabb HUB-ot és arra megy a 3G modem meg a Wifi adapter, a korlát akkor is az USB 1.1 FullSpeed 12Mbit/sec elméleti max sebessége lesz... ahhoz hogy teljes tempóval ki tudjam használni, ahhoz idővel mindenképpen olyan procira kell váltanom, amely képes HiSpeed 480Mbit-re is...