BCM63XX SPI port

Wireless

Gondolom akad itt egy pár nálam embedded linuxban járatos emberke, így teszek egy próbát a problémámmal.

Van egy BCM6348 alapú vasam (Netgear DG834GT). OpenWRT fent van rajta, az SPI buszát szeretném birizgálni.
0. pontként mondjuk szeretném meglengetni a valamelyik lábát, hogy megbizonyosodjak róla, hogy az SPI lábak ki vannak veztetve oda ahová én képzelem, pld nem hagytak ki golyókat a BGA alól, stb.

A kmod-bcm63xx-spi ami rántja a kmod-spi-bitbanget, illetve kmod-spi-dev.

Illetve feltettem az spidev_test programot, amivel tudnék majd próbálkozni.
Alapállapotban nincs semmi releváns a /dev alatt.

root@OpenWrt:/# lsmod | grep spi
bcm63xx_spi 2528 0
spidev 4592 0
spi_bitbang 3360 1 bcm63xx_spi

mknod /dev/spi0 c 153 0
segítségével sikerrel létrehoztam az eszközfájlt, azonban az
spidev_test -D /dev/spi
kilép:
can't open device: No such device or address hibával.

  • 2133 megtekintés

Igen ezt vizslattam.
Ha jól veszem észre, akkor el sem jut odaáig, hogy írjon ki valamit. (transfer fv)
Amit végképp nem értek, az az, hogy kétféle hibakód van No such file és No such file or bad address.
Namármost ha nincs /de/spidev1.1 akkor az elsőt dobja, ha van a másodikat. Tehát valami nem smakkol már az eszköz megnyitásakor.

BTW. mi van ha az mknod paraméterezésével van a gond?
Ez a major / minor értéket valami DavinciDSP-s fórumból vettem át.
Ez a két szám sw (kernelmodul) vagy hw függő?

Gugliztam picit azóta.

Ideírom hadd maradjon meg az utókornak.

Tehát az mknod vár egy filedescriptornevet, azt hogy milyen módú az eszköz, és a major ill. minor számát.
Első paraméter rendben. /dev/spiakármi
Második: karakteres az eszközünk.
A major számot a cat /proc/devices megmondja a modul betöltése után.
A minor számokat dinamikusan kapják az eszközök.

Egyelőre a dolog passzolásra áll részemről.

Valószínűleg az van, hogy a kernelmodulban lévő bcm63xx_spi_probe függvényben történik a probléma mert a platform_get_resource(..)- vagy a platform_get_irq(...) -ERRNO-t dob. Valószínűleg inkább az első lesz a ludas, feltehetően azért mert ennél a boardnál elvileg nincs szükség az SPI-re.

Az a gáz hogy a debug kissé nehézkes, mert még rá kellene jönnöm, hogy hogyan tudnám a buildroot által létrehozott könyvtárszerkezetben adott függvény deklarációját / implementációját gyorsan elérni, illetve, hogy hogyan tudnám csak magát az adott kernelmodult minden sallang nélkül lefordítani, illetve becsomagolni.

A kernelmodult, ha a kernel resze, csak a kernellel egyutt forgathatod, viszont a dolognak megvan az a szepsege, hogy az egyszer leforditott kernelben a make parancs altalaban csak a valtozott reszeket forgatja ujra. Nem tudom, hogy csinaltak a sracok, de roppant hatekony ez igy.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

No alakul a molekula.
Sikerült módban pörgetni az spi modulokat.
Elvileg a Kconfig azt írja hogy lenne ilyen opció a menüconfigban, ha a "depends on DEBUG_KERNEL" sor teljesül.
Beraktam mindent ami kernel és debug, de így sem lett elérhető, ezért a Makefileba fő kókány megoldásként beírtam egy
EXTRA_CFLAGS += -DDEBUG sort. Így a dmesg bőbeszédűbb, illetve mostmár pontosan tudom hol akad el. (spidev.c, spidev_open-ben)
Illetve rájöttem egy RTFS jellegű apróságra: 


 * SPI has a character major number assigned.  We allocate minor numbers
 * dynamically using a bitmask.  You must use hotplug tools, such as udev
 * (or mdev with busybox) to create and destroy the /dev/spidevB.C device
 * nodes, since there is no fixed association of minor numbers with any
 * particular SPI bus or device.
 */

#define SPIDEV_MAJOR			153	/* assigned */
#define N_SPI_MINORS			32	/* ... up to 256 */

Azonban az mknod /dev/spidev1.1 c 153 32 sem segített, a spidev_test változatlanul bukik,
a dmesgben 

spidev: nothing for minor 32

nyomot hagy.

Edit:
A 2.6.31-es kernelben már több mese van arról hogy mit hogyan:

Do not try to manage the /dev character device special file nodes by hand.
That's error prone, and you'd need to pay careful attention to system
security issues; udev/mdev should already be configured securely.

Tehát jobb lenne megkerülni az mknodot.
A hotplug2 fent van, azonban nem találtam semmi információt a témában, hogy hogyan kellene vele az spit összebarátkoztatni. Valakinek nincs véletlenül valami ötlete?

( v | 2009. 09. 22., k – 11:05 )

Én is OpenWRT-t tervezek rakni az ugyanilyen eszközömre. Te hogy raktad rá, CFE-n keresztül? Vagy a Windowsos Netgear fw toolt lehet erre használni?

Igen CFE-n keresztül toltam fel. Az a baj, hogy olyan CFE van rajta, amihez kell a soros hozzáférés, hogy flashelni tudd. (Van olyan ami recovery módba rakva várja a firmwaret.)
Az openwrt TOH-ban leírtam hogyan kell össztehozni.
A windowsos toolt nem próbáltam. A buildroot elég sokféle imaget legenerál, meg kellene nézni milyen formátumú firmwaret emészt meg a tool, hátha épít olyat is.

Igen, nekem pont ez a gondom, hogy nincs soros portom, es azt probalnam valami modon megkerulni. Nezegettem a Windowsos toolt, es annak van valami trukkje, ugyanis nem bootolo eszkozre is ra tudja lanon keresztul tolni az image-et, de meg nem jartam utana, hogy a CFE-t veszi-e ra valahogy hogy TFTP szervert inditson, vagy valami mast csinal-e. (Lehet, hogy ha nem tud a CFE bootolni, akkor automatikusan recovery modba kerul?)

Ha a CFE-t nem tudod bootolni, akkor halott az eszköz.
Esetleg ha megeresztessz rajta egy frissítést miközben megy a wireshark okosabbak lehetünk.
A windowsos toolt én igazából sohasem használtam, mivel az enyém egy angliából behozott SKY internetszolgáltató által rebagged típus, amire csak fondorlatos módszerekkel lehetett a gyári fw-t felvarázsolni.

A windowsos toolt én igazából sohasem használtam, mivel az enyém egy angliából behozott SKY internetszolgáltató által rebagged típus, amire csak fondorlatos módszerekkel lehetett a gyári fw-t felvarázsolni.
Pl a windowsos tool-lal :) Nekem is ilyen van.

Egyebkent az usb-t sikerult eletre lehelni rajta, vagy ne hijack-eljem a topicot?

Én annak idején egy modded firmwaret vadásztam valahonnan, amit a webes felületen kellett feltölteni, majd abból már lehetett a gyárira frissíteni. A skyos felületről a gyári fwt nem lehetett feltolni.

Az USB egyelőre nem működik. Van a SOCnak egy USB enable lába, azt kellene megtalálni és felhúzni tápra, feltéve hogy nem voltak szemetek, és nem hagytak ki golyókat a BGA alól. Majd végigtaperolom a hiányzó ellenállásokat mérőtüskével, és meglátjuk.

Sikerült életre lehelni.
A három ilyenemből egyről lekaptam a BGA-t, és ez alapján megkerestem az USB vel összefüggő lábakat.
http://www.f-x.fr/wikini/wakka.php?wiki=Bcm6348PinOut/

Egyedül az USB FLT van elvezetve a D+ D- on kívül.
Érdekes módon valószínűleg vissza van vezetve a proci valamelyik egyéb lábára, mert semerre nem sikerült megtalálnom padról padhoz vezető sáv másik végét, illetve nem mutat ellenállást sem a GND, illetve semmelyik tápkörrel sem.
Beforrasztott procival 90K ellenállással van húzva a föld felé. Kétlem, hogy GPIO-hoz lenne kötve, mert azoknak kisebb az ellenállásuk ha 0ra vannak állítva.
Szerencsére egy átmenő vián keresztül van bevezetve valamelyik belső rétegre.
Így a via fejét felcsiszolva forrasztottam rá egy 2K-s felhúzót a 3V3 felé, és így jó.

Dokumentálva:
http://users.atw.hu/balubati/blog/index.php?entry=entry100615-145816