Edit Port del driver scc/ISA de Linux a PCI

Title:

Last edited: 5:55:28 pm on 22 March 2012 by salchicha

Ver *Información tarjeta torniquetes>http://3.0.1.45:8000/testing/80*
+@^_
_
<tt>Thursday, 22 March 2012, 5:55:16 pm</tt>
Driver scc_pci26 validado Ya se ha probado en campo y funciona correctamente :-).
_
<tt>Monday, 12 March 2012, 8:32:36 pm</tt>
Pruebas con el scc_pci26 en el pupitre con 2.6.32-bpo.5-686 Para cambiar las opciones del driver mientras se está ejecutando el cci2.x:

===CUT==
cd /dev
mknod scc2 c 34 2
echo 'D' > scc2
echo '1' > scc2
echo '0' > scc2
echo 'd' > scc2
echo 'D' > scc2
===CUT===

Siendo:
	 'D' - activar las trazas
	 'd' - desactivar las trazas
	 '1' - activar las pruebas de escritura (pone un timer para mandar mensajes de forma autónoma cada 1s)
	 '0' - desactivar las pruebas de escritura (quita el timer)

Las trazas aparecen en <tt>/var/log/debug</tt>, o bien se pueden consultar con un <tt>dmesg</tt>.
_
<tt>Thursday, 13 January 2011, 1:16:37 pm</tt>
Cambios en el port a linux2.6 Ahora la versión del núcleo que se va a usar es la "<tt>2.6.32-bpo.5-686</tt>".

Se compila en <tt>chibiko</tt>:
= root@chibiko:/home/dario# mount /home/dario/Programacion
= root@chibiko:/home/dario# su - dario
= dario@chibiko:~$ cd ~/Programacion/proyectos/sico-scc_pci26
= dario@chibiko:~/Programacion/proyectos/sico-scc_pci26$ make

_
<tt>Tuesday, 2 November 2010, 11:19:03 am</tt>
Port adicional de linux 2.2 a linux 2.6 Los fuentes están en:
= salchicha:/home/dario/Programacion/proyectos/sico-scc_pci26
Se compilan en symbiandevel:
= root@symbiandevel:/home/dario# mount /home/dario/Programacion
= dario@symbiandevel:~# cd ~/Programacion/proyectos/sico-scc_pci26
= dario@symbiandevel:~/Programacion/proyectos/sico-scc_pci26$ make

Los recursos que estoy usando para el port son:
- *PCI Kernel Drivers (Linux 2.6)>http://www.linux-support.com/cms/en/component/content/article/3-articles/81-pci-kernel-drivers-linux-26?directory=14*
- *LWN: Articles: Driver porting (to 2.6)>http://lwn.net/Articles/driver-porting/*
- Linux Device Drivers, Third Edition *PDF>http://lwn.net/Kernel/LDD3/*, *HTML>http://linuxdriver.co.il/ldd3/*.
- *Linux cross reference identifier search>http://lxr.oss.org.cn/ident?v=2.6.30*
- Tomar como ejemplo los drivers char de un núcleo 2.6: <tt>&nbsp;chibiko:/usr/src/linux-source-2.6.26/drivers/char</tt>

Para hacer el Makefile out-of-tree se han sguido los siguientes recursos:
- *Blackfin port documentation: building kernel modules>http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:modules:building&s[]=building&s[]=modules*
- *Blackfin forum: Building external (out of tree) module into kernel>http://blackfin.uclinux.org/gf/project/uclinux-dist/forum/?_forum_action=ForumMessageBrowse&thread_id=34962&action=ForumBrowse*.
_
<tt>Wednesday, 26 October 2005, 7:43:01 am</tt>
PNPBIOS support con pcmcia-cs En *este post>http://mail.matrix.de/pipermail/linux-thinkpad/2003-May/011147.html* y en *este otro>http://mail.matrix.de/pipermail/linux-thinkpad/2003-May/011143.html* dicen lo siguiente:
<blockquote>
As Tino pointed out, you can get the pnpbios functionality if you are 
building your pcmcia modules, it's just a configure option to the pcmcia 
source. Since you are on Debian I'm guessing you are already using 
make-kpkg to build your kernels. Just apt-get the pcmcia-source package 
and edit /usr/src/modules/pcmcia-cs/debian/rules. Find the calls to 
"Configure" and add "--pnp" to those lines (I think the first one is the 
one usually used, the second is for debugging). Then make-kpkg 
modules_image as usual, and you will have pcmcia modules that provide 
pnpbios support. If you need pcmcia modules anyway this is a lot easier 
than extracting a patch. I have this working with 2.4.20 mainline with 
only the low-latency patches applied.
</blockquote>
_
<tt>Tuesday, 25 October 2005, 11:03:46 am</tt>
Hex dumps de ESCD junto con explicaciónEn *este post>http://lists.freebsd.org/pipermail/freebsd-smp/2003-March/000001.html* hay un hex-dump del ESCD con explicación, obtenida usando *System Analyser V5.2 (Shareware)>http://www.sysanalyser.com/Sa.html*,

Hay un programa llamado lsescd que permite ver las asignaciones actuales. Se supone que *a partir del 2.6.10>http://glide.stanford.edu/lxr/source/drivers/pnp/pnpbios/proc.c?v=linux-2.6.10* (aprox) también se puede ver usando <tt>/proc/bus/pnp</tt>. Además, la configuración de las tarjetas se puede cambiar con un programa del pcmcia_cs (separado a pnpbios-tools en debian/unstable): lspnp/setpnp.

_
<tt>Monday, 24 October 2005, 9:54:49 am</tt>
Más info sobre ACPI y PCI ROuting Tables *Parece>http://osnews.com/comment.php?news_id=12370* que ACPI es quien "depreca" a las PCI Routing Table (_PRT). Hay un "overview" del ACPI de Linux en el *anuncio del port de ACPI de Linux a Syllabe>http://sourceforge.net/mailarchive/forum.php?thread_id=8763878&forum_id=9969*.
_
<tt>Monday, 24 October 2005, 7:42:20 am</tt>
Utilidad relacionada: dmidecode Está en la web de lan: *dmidecode.c>http://people.redhat.com/arjanv/dmidecode.c*. SIrve para interpretar los campos DMI (Desktop Management Interface) de la BIOS. Ver *Salida de dmidecode en la Via Eden DP*.
_
<tt>Monday, 24 October 2005, 7:30:49 am</tt>
Utilidades para guardar/cargar el ESCD en archivo En *este post>http://www.ussg.iu.edu/hypermail/linux/kernel/9808.0/0078.html* están las insttrucciones para el <tt>escd_dump</tt> (hay un link muerto: *escd.tar.gz>ftp://rvs.ctrl-c.liu.se/pub/wingel/pnp/escd.tar.gz*).

*Según parece>http://blog.gmane.org/gmane.linux.kernel/month=20020601*, si se compila la opción de PNPBIOS, se puede acceder al PNP en <tt>/proc/bus/pnp/escd</tt>, pero según qué placa, funciona o no... (si no funciona se consigue un bonito reboot).
_
<tt>Friday, 21 October 2005, 6:13:35 pm</tt>
Más sobre cambiar interrupciones y ACPI Ver *este artículo de lwn>http://lwn.net/Articles/146094/*, más *en google>http://www.google.es/search?hl=es&ie=ISO-8859-1&q=acpi+linux+change+interrupt&meta=*. Por otro lado, habría que estudiarse la documentación de *acpi4linux>http://acpi.sourceforge.net/*.
_
<tt>Friday, 21 October 2005, 12:28:36 pm</tt>
Sigue habiendo problemas compartiendo la IRQ Además resulta que en la estación en la qu eestamos haciendo pruebas (vest2 de iglesia), no hay manera de que no compartan interrupción. He probado:
- Poner tarjeta arriba y reset BIOS: Comparte
- Cambio a abajo y reset BIOS: Comparte
- cambio a arriba y no se hace reset de BIOS: Comparte

Con lo cual no parece haber manera sana de forzar que cambie de interrupción.

or otro lado tampoco ha habido forma de hacer que use la eth1 en vez de la eth0 (en la oficina funciona, pero en el pupitre_sc de iglesia se queda sin ping al cambiarle el interfaz de red a usar y cambiar el cable de posición :-?).

He visto que OpenSolaris tiene una función para reconfigurar la interrupciónd de un dispositivo PCI usando ACPI: *uppc_acpi_irq_configure()>http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6311029*. Sólo me falta saber si Linux tiene algo equivalente, ya que parece la única salida (le pondría la irq 5, que está libre).

Update: Lo más cercano que he encontrado es en <tt>/usr/src/scc/linux-2.4.27/drivers/acpi/pci_irq.c</tt>, la función <tt>acpi_pci_irq_enable()</tt>, pero esa no la cambia, sólo la activa. Por cierto, eso se hace en la "PCI Interrupt Routing Table", la _PRT, que se cambia usando ACPI. En *este parche>http://www.cs.helsinki.fi/linux/linux-kernel/2001-48/1922.html* incluso son capaces de cambiar la IRQ usando <tt>acpi_pci_set_current_irq</tt> :-o.

Otra opción es usar *IO-APIC>http://www.linux.org/docs/ldp/howto/Plug-and-Play-HOWTO-10.html#ss10.5*, que sí permite programar qué interrupciones usa quién.
_
<tt>Thursday, 20 October 2005, 6:12:54 pm</tt>
Pruebas compartiendo la IRQ *Este documento>http://www.scyld.com/pci_irq.html* dice que no se debe usar SA_INTERRUPT a la vez que SA_SHIRQ. Merece la pena hacer la prueba...
_
<tt>Friday, 14 October 2005, 12:23:20 am</tt>
Primera versión del driver de SICO scc_pci Ya funciona lo siguiente en el *+scc pci.c+*:
- Transmisión usando interrupciones
- Lee y tracea (aunque ignora) el estado de transmisión y de recepción
- También tracea la recepción (aunque no lo guarde para mandárselo al usuario)
Esta versión del driver está reescrita desde cero específicamente para el ESCC (frente al de INDRA que era para el SCC), con lo que se mejora en velocidad y en estabilidad (p.ej. no tiene problemas por compartir interrupciones), así como una mejora muy sustancial en legibilidad de código (en estos momentos le falta implementar parte de la recepción, pero son 620 líneas, frente a las más de 3000 de la parte equivalente del driver antiguo).
_
<tt>Thursday, 13 October 2005, 7:05:20 am</tt>
Documentación de Zilog *Página de Zilog sobre el SCC/ESCC>http://www.zilog.com/products/family.asp?fam=200* y la *página específica del z85230>http://www.zilog.com/products/partdetails.asp?id=Z85230*.
_
<tt>Thursday, 13 October 2005, 3:48:14 am</tt>
Más información
- *Búsqueda de fuentes en linux con ESCC>http://www.google.es/search?hl=es&ie=ISO-8859-1&q=ESCC+422+outb&meta=*
- *Ejemplo GPL de driver que usa una variante del scc con dma>http://wirefall.org/docs/linux-2.4.10_html/311698.html*
- *El driver scc.c de siempre>http://www.kernelhq.com/browse-view.py?fv_nr=13252*, ver las líneas 1317-1337 para la preparación a escritura, y las líneas 1231-1233 para la configuración del reloj en Rx:DPLL/Tx:RTxC, la cadena "scc->enhanced" para ver cómo activar el ESCC, y la línea 865 para ver cómo transmitir un byte. La recepción la hace en las líneas 1525-1549 (llamada desde la 1061).
- *Búsqueda de SCC 3-wire en grupos>http://groups.google.es/groups?hl=es&lr=&ie=UTF-8&q=SCC+3-wire*
- *Explicación del AX.25 de linux y de KISS>http://groups.google.es/group/rec.radio.amateur.digital.misc/browse_thread/thread/71807d0f04890994/08748e8d2ea08a2c?lnk=st&q=SCC+3-wire&rnum=3&hl=es#08748e8d2ea08a2c*
- *Búqueda de linux localtalk y scc en grupos>http://groups.google.es/groups?hl=es&q=linux+localtalk+scc*
- *Discusión de implementación de localtalk en linux>http://groups.google.es/group/linux.debian.ports.powerpc/browse_thread/thread/6ddb9cc531399c45/9c083c4e5f24ab8f?lnk=st&q=linux+localtalk+scc&rnum=3&hl=es#9c083c4e5f24ab8f*
- *Búsqieda de LocalTalk AppleTalk Farallon>http://www.google.es/search?hl=es&ie=ISO-8859-1&q=LocalTalk+AppleTalk+Farallon&btnG=B%FAsqueda+en+Google&meta=*
- *Un montón de links interesantes de LocalTalk en PCs>http://www.mandrake.demon.co.uk/Apple/ltalk/*
- *PC LocalTalk cards>http://www.mandrake.demon.co.uk/Apple/ltalk/pc_hardware.html* (viene de la anterior página) Lista tarjetas SCC para PC con driver LocalTalk para Win. Curiosamente, la tarjeta de Apple ("Apple LocalTalk PC card") usa un 6502 como coprocesador para evitar tener timings ajustados en el PC debido al acceso al SCC...
_
<tt>Wednesday, 5 October 2005, 4:49:40 pm</tt>
El CRC es CRC-CCITT Según *este doc>http://72.14.207.104/search?q=cache:mPc-BOdqRsYJ:www.alphitech.com/manuals/IP_alphi_man/atcscc04.pdf+scc+sdlc+code&hl=es*, el CRC generado por el SCC sólo puede ser CRC-16 o CRC-CCITT, y en las pruebas con INDRA ponían el analizador (DATASCOPE) a CCITT. Ese CRC es, según la documentación de Zilog, el CRC "nativo" de SDLC (es decir, el que no es CRC-16). Además, indican que el DPLL sirve para que el receptor pueda obtener la señal de reloj cuando se embebe usando FM0/FM1/NRZ/NRZI en SDLC (también lo mencionan *aquí>http://www.mactech.com/articles/mactech/Vol.02/02.04/ATalkConnections/*).
_
<tt>Wednesday, 5 October 2005, 4:30:14 pm</tt>
Información miscelánea sobre puertos serie La página *Serial communications>http://www.rdrop.com/~cary/html/serialportdocs.html* [drop.com/~cary] contiene una cantidad formidable de punteros a documentos de programación de puertos serie (tanto tipo PC (UART), como Mac/Atari (SCC) y otros: midi, usb, ieee1394...). Por desgracia, aunque los Mac usan SDLC sobre SCC para appletalk, lo usan con FM0 en vez de con NRZI (no podía ser perfecto).
_
<tt>Tuesday, 27 September 2005, 1:06:54 pm</tt>
Parece que hay un problema con el SDLC Resulta que usan el *SDLC>http://www.google.es/search?hl=es&ie=ISO-8859-1&q=sdlc+protocol&meta=*, pero en 422 y con sólo 4 hilos. Seguramente haya que configurar algo "raro" en la tarjeta para que embeba el reloj dentro de la transmisión. Tutoriales de SDLC:
- *SDLC Tutorial>http://www.sangoma.com/sdlc.htm*
- *Sync & async tutorial; SDLC Frames (HDLC framing)>http://www.sangoma.com/sync&a.htm*

¡Update! Resulta que si se usa NRZI, el reloj se embebe dentro de la transmisión, de manera que se sincroniza con los cambios de nivel de señal (ver 3-4 en el manual de Zilog). Es como sigue:
# NRZI interpreta el 0 ó 1 en vez de como señal alta/baja, como cambio en el nivel de señal (0) o no (1). 
# SDLC se asegura uqe nunca haya más de 5 bits 1 seguidos.
# Entre los dos hacen que haya un cambio de nivel de señal como mínimo cada 5 bits, lo que provoca que se pueda usar para la sincronización sin necesidad de habilitar una línea dedicada para el CLCK.
_
<tt>Thursday, 22 September 2005, 12:01:35 pm</tt>
Sobre los cuelgues del driver en la oficina Resulta que es culpa de compartir interrupción (estaban compartiendo interrupción tanto el usb, como ña eth como el scc). Para hacer que la BIOS haga una asignación de interrupciones diferente hemos seguido las sufgerencias de un *howto de estabilidad>http://www.gentoo.org/doc/en/articles/hardware-stability-p2.xml*, que se resumen en resetear el ESCD:
# Se entra en la bios
# Se entra en el menú de configuración PCI
# Se pone a "Enable" la opción de "reset ESCD".
Al salvar y salir, hace una asignación de IRQs diferentes, en la que el scc sólo comparte irq con el usb.

NOTA: Antes era "irq9: usb, eth,scc ; irq11: usb"; ahora es "irq9: usb,scc ; irq11: usb, eth".
_
<tt>Thursday, 22 September 2005, 11:56:56 am</tt>
Pruebas en Indra Resulta que la tarjeta Sealevel 5103 sólo tiene rs-232. La tarjeta que soporta tb. 422/485 es la 5102 (la que habíamos elegido inicialmente :-/ ). Se ha pedido una tarjeta de la 5102 para ver si funciona con esa...
_
<tt>Wednesday, 21 September 2005, 8:10:53 am</tt>
Información de programación del SCC Afortunadamente, el SCC se usa en los Apple con AppleTalk. Así, hay documentación básica más fácil de comprender que los manuales de Zilog en los siguientes sitios (*más>http://www.google.es/search?hl=es&ie=ISO-8859-1&q=macintosh+scc+programming+-%22source-control%22&meta=*):
- *SCC Application Info in Apple IIgs>http://apple2.org.za/gswv/a2zine/Docs/SCC_ApplicationInfo.txt*
- *macrecorder sample SCC app>http://mxmora.best.vwh.net/umpg/UMPG1.html#ref28*
_
<tt>Wednesday, 21 September 2005, 8:09:19 am</tt>
Hay un bug en el driver Después del primer write, un instante después de salir de la función de escritura (SCC_WRITE y dentro de ella, de sdlc_write), bloquea el ordenador.
_
<tt>Wednesday, 14 September 2005, 5:35:06 pm</tt>
Terminada la primera versión del port de indra que parece funcionar El código que tenemos hora mismo es:
- <tt>/usr/src/scc/linux-2.2.26-scctty/drivers/char/scc.c</tt>: Es el driver de 2.0.x portado a 2.2.x, no funciona con las ioctls de indra
- <tt>/home/dario/Programacion/proyectos/sico-scc_pci/scc_pci.c</tt>: Es una prueba de hacer el driver desde cero, pero solo implementa la inicialización, ya que se ha optado por la siguiente opción.
- <tt>/usr/src/scc/Driver-1.0-2/scc.c</tt>: Es el driver de indra modificado con los cambios de los dos anteriores de manera que funcione en kernels 2.2.x. Este es el que vamos a utilizar (en principio).

Otras versiones que no se utilizan:
- <tt>Driver-1.0-2/scc-ori.c</tt> es el driver original de indra
- <tt>Driver-1.0-2/scc.c.indra24.broken</tt> parece ser uin intento abortado de port a 2.4 hehco por indra. Está renombrado (en el tar original tenia otro nombre; no ponia lo de <tt>broken</tt>, por lo menos).
_
<tt>Thursday, 1 September 2005, 5:54 pm</tt>
Más punteros de documentación de escritura de drivers Aunque en genral son para drivers de red, aplica la mayoría del texto:
- *Linux Device Drivers, 2nd Edition: Online Book>http://www.xml.com/ldd/chapter/book/index.html* de Alessandro Rubini & Jonathan Corbet. Es el libro clásico para escribir drivers en Linux. Muy recomendable ;-).
- *The tty layer>http://www.linuxdevices.com/articles/AT5727959130.html*
- *Kernel hacking 101>http://66.249.93.104/search?q=cache:4PHZJEubJf8J:asulug.asu.edu/presentations/KernelHacking101.pdf+KERN_ERR+KERN_DEBUG&hl=es&ie=UTF-8*
- *Writing Network Device Driver for Linux>http://linux.org.mt/article/writing-netdrivers*
- *Writing the IBM APE 25 driver>http://www.cs.clemson.edu/~westall/atm/lxptalk.htm*
- Writing a network device driver *part 1>http://linuxgazette.net/issue93/bhaskaran.html* (part 2 seems to haven't been published)
- *Dos and Don't when writing a Linux Device Driver>http://janitor.kernelnewbies.org/docs/driver-howto.html* de kernel-newbies
- *Writing and ALSA Driver (for a PCI card)>http://www.alsa-project.org/~iwai/writing-an-alsa-driver/index.html*

Y no directamente relacionado, pero útil de todas formas:
- *Jun Sun's Linux/MIPS Porting Guide>http://linux.junsun.net/porting-howto/porting-howto.html* Guía para portar Linux (el kernel) a una nueva plataforma. Incluye cómo usar KGDB y también un buen repaso a una manera razonable de inicializar el bus PCI en las placas MIPS (pero la descripción es aplicable a otros ports, sólo que el x86 usa "lo que le ha dejado la BIOS", y no requiere hacer algunos de los pasos ahí descritos).
_
<tt>Thursday, 1 September 2005, 9:14:56 am</tt>
A vueltas con la inicialización Un problema posible es que la tarjeta esté en un modo ACPI que haga que no funcione (ver p.ej. el driver de la eepro100). Otro problema es la inicialización en sí de las regiones I/O. A continuación pongo un enlace que explica esto último:
- *Fail Safe Port Allocation for Linux Device Drivers>http://www.linuxfocus.org/English/November2002/article264.shtml*
El uso de mdelay()/udelay() Está explicado en:
- *Linux Device Drivers, 2nd Edition: Chapter 6: Flow of Time>http://www.xml.com/ldd/chapter/book/ch06.html*

_
<tt>Wednesday, 31 August 2005, 1:06:36 pm</tt>
Pruebas sobre DOS Usando el programilla SCC.EXE (versión parametrizada de uno de los programillas de DOS de jemplo de Sealevel), y usando el pcispy/viewpci, sí que se accede a la tarjeta y la detecta correctamente como una ESCC. He aquí lo que hemos "averiguado" cuando se ejecutaba desde DOS5:
|Device #|Vendor|Device|Class|
|01.0A|135e|5103|Unknown|

|Region|Adress|Info|
|0:|ff8ffc00|80 bytes|
|1:|0000dc00|80 bytes I/O space|
|2:|0000dfa0|10 bytes I/O space|
|irq|11|(mirado en el dump)

El programa ha reconocido la tarjeta como una 85230 al hacer:
= C:\> SCC 0xdfa0 11

Conclusión: la tarjeta funciona y las rutinas de inicialización del programa DOS son válidas.
_
<tt>Tuesday, 30 August 2005, 5:46:29 pm</tt>
Notas sobre programación del bus PCI bajo DOS
- *Programming PCI boards in DOS>http://64.233.183.104/search?q=cache:u7EoRVjFImEJ:www.omega.com/techref/das/pci_dos.html+pci+programming+DOS&hl=es&ie=UTF-8* Muy útil. Con ejemplo en ensamblador y todo.
- *Register Programming a PCI Device and Finding the Correct Address>http://digital.ni.com/public.nsf/websearch/15f094f65a17e3af8625660d0018a20a* Poco útil. Lo único que es de interés es que al mapear las direcciones I/O, hay que tener cuidado de que estén en la parte "adddressable by DOS real mode programs", es decir, dentro del primer MB y que no sean sobreescritos por los "memory managers" (es decir, emm386, qemm y similares).
- *Interfacing with PCI soundcards from DOS (thread)>http://board.flatassembler.net/topic.php?p=27905* Básicamente dicen que se puede acceder usando tanto la BIOS PCI como directamente usando los "ports 0CF8h-0CFCh, they are described in Ralf[ Brown]'s ports list". También enseñan código en ASM (x86) de cómo hacerlo usando llamadas a la PCI BIOS.
- *PCI bus info and code from a programmer's perspective>http://www.waste.org/~winkles/hardware/pci.htm* Muy completo, describe para qué son las zonas de configuración y todo. Va paso a paso. Dice tanto la manera usando la BIOS como usando los puertos. Lectura muy recomendable. Además dan un puntero a la utilidad *pciview.exe>http://www.waste.org/~winkles/hardware/PCIVIEW.ZIP*, más completa que el pcispy de matrox (está en <tt>salchicha:/home/dario/program/dos</tt>).
- *Ralf Brown's Interrupt List>http://www.cs.cmu.edu/afs/cs/user/ralf/pub/WWW/files.html* Por si se quieren usar las llamadas a la PCI BIOS.

Lo más correcto parece ser utilizar llamadas a la PCI BIOS (1Ah). En el primero de los enlaces hay un programa en ASM (x86) que muestra cómo hacerlo.
_
<tt>Tuesday, 19 July 2005, 10:10:11 am</tt>
Ya tenemos el driver de Indra Lo recibimos ayer. Mirando los fuentes, es un fork de la versión *z8530drv-1.9.dl1bke>http://www.ussg.iu.edu/hypermail/linux/kernel/9507/0328.html* (disponible por *ftp>ftp://ftp.ucsd.edu/hamradio/packet/tcpip/linux/*). Voy a mirar cuales son los cambios que han realizado...
_
<tt>Monday, 4 July 2005, 7:06:19 pm</tt>
Primera versión del driver *+scc.c+* Pero para que funcione hay que hacer un:
= mknod /dev/scc0 c 34 0
_
<tt>Monday, 4 July 2005, 12:31:55 pm</tt>
Estado del port Usando la información de *porting>http://www.linux-mag.com/1999-05/gear_01.html* *2.0 to 2.2>http://www.linux-mag.com/1999-06/gear_01.html* he hecho las partes básicas para que no use cosas que ya no existen en 2.2. Por otro lado, para ver cómo se debe hacer el soporte PCI, está el driver <tt>/usr/src/scc/linux-2.2.26-scctty/drivers/char/cyclades.c</tt> (buscar <tt>pci_find_device</tt>).
_
<tt>Thursday, 30 June 2005, 4:52:18 pm</tt>
Arreglados los problemas de la red en la epia Resulta que según *este>http://www.kerneltraffic.org/kernel-traffic/kt20030309_208.html#10* mensaje y *este otro>http://www.uwsg.indiana.edu/hypermail/linux/kernel/0302.3/1028.html* mensaje, el <tt>via-rhine</tt> se consiguió estabilizar "muy tarde". O sea que me he bajado los drivers actualizados del *repositorio de Donald Becker>http://www.scyld.com/ethercard_drivers.html* y lo he recompilado en <tt>salchicha:/usr/src/scc/rhine</tt>. Una vez puestos en la epia y regenerado el initrd ha funcionado a la perfección ;-). Eso significa que podemos usar finalmente una sarge (¡¡yiiiiipiee!!).
_
<tt>Thursday, 30 June 2005, 8:16:15 am</tt>
Problemas con la red Con el núcleo 2.2.26 me da el siguiente error por la parte de red:
= $ ping 3.0.1.170
= PING 3.0.1.170 (3.0.1.170) 56 (84) bytes of data.
= Warning: no SO_TIMESTAMP support, falling back to SIOCGSTAMP
= Warning: kernel is not very fresh, upgrade is recommended.
= From 3.0.1.176: icmp_seq=2 Destination Host Unreachable
= From 3.0.1.176: icmp_seq=3 Destination Host Unreachable
_
<tt>Thursday, 30 June 2005, 7:44:17 am</tt>
Problemas al arrancar mi flamante nuevo núcleo 2.2.26 Me da lo siguiente:
= VFS: Mounted root (ext2 filesystem) readonly.
= Freeing unused kernel memory: 56k freed
= Warning: unable to open an initial console
= kernel panic: No init found. Try passing init= option to kernel.

No arregla el anterior error el crear un initrd He cambiado el <tt>mkinitrd.conf</tt> tal y como indican en la manpage para que use <tt>genromfs</tt> en vez de <tt>mkcramfs</tt> (por no tener parcheado el núcleo 2.2.x para <tt>cramfs</tt>), y he generado un initrd para el núcleo con "<tt>mkinitrd -k -o /boot/initrd.img-2.2.26 -r /dev/hda1 2.2.26</tt>". Sin embargo igue dando exactamente el mismo error :-?.

Update: ¡Arreglado! Según *este howto>http://linuxplanet.com/linuxplanet/tutorials/3196/3/* eso es porque le falta el root=... y, efectivamente, era por eso O:-) (¡y yo que creía que lo había puesto!).
_
<tt>Wednesday, 29 June 2005, 3:49:05 pm</tt>
Problemas con el 2.0.x Resulta que *me da un error al compilar>http://lists.debian.org/debian-devel/1999/09/msg01312.html* el 2.0.40 en potato. A intentar usar el 2.2.x...
_
<tt>Wednesday, 29 June 2005, 12:08:13 pm</tt>
Cambios en el scc.c A base de ver *diff de kernel.org>http://www.kernel.org/diff/diffview.cgi?file=%2Fpub%2Flinux%2Fkernel%2Fv2.4%2Fpatch-2.4.27.bz2* partiendo desde el 2.4.27 y yendo para abajo, las versiones del kernel que han visto cambios en el scc.c son las siguientes:

NOTA: Puedes ver las *scripts para ver los cambios del scc en el kernel*.
_
<tt>Wednesday, 29 June 2005, 11:30:37 am</tt>
Cosas, cosas, cosas... Resulta que el núcleo que usan los de Indra en los PCs del scc/ISA data de 1997, pero los fuentes del driver que hay en ese núcleo son de 1995 y el driver scc cambió completamente a finales de 1996; pasó de ser un driver tipo <tt>char</tt> a tipo <tt>net</tt>.

Fuentes del driver "original" Los he puesto en <tt>salchicha:/usr/src/scc/linux-2.0.29/drivers/char/scc.c</tt> mientras que los modernos están en <tt>salchicha:/usr/src/scc/linux-2.4.27/drivers/net/hamradio/scc.c</tt> 
_
<tt>Wednesday, 29 June 2005, 10:08:43 am</tt>
PC en metro con el SCC rodando Como ejemplo de la configuración actual que usa las placas ISA, se puede ver el siguiente PC en metro:
# f9 (Linea 9)
# rlogin rur (vas a rivas urbanizaciones)
# rlogin os2 (vas a un pupitre con ethernet)
# si necesitas hacer un lsmod o similar, necesitas "<tt></tt>". Como usuario tb. puedes (/sbin/lsmod).
_
! Descripción del proyecto

Se trata de porder usar la tarjeta PCI de sealevel que tiene el chip Z8523008VSC (compatible ESCC, Z85230) con el driver de scc de linux (modificado para PCI).

La idea es:
# Ver las diferencias entre el driver ne2000 (ne.c) y el ne2000-pci (ne2k-pci.c) de Linux (que se supone simplemente un cambio de bus; el resto del chipset permaneció igual, de la misma manera que se supone que sucede con la sealevel). Otra posibilidad es unar como patrón el driver de AMD PCNet (lance.c) ya que soporta tanto ISA como PCI.
# Ver las especificaciones de sealevel para dicha tarjeta
# Ver las especificaciones de la tarjeta original (cualquiera de las soportadas por el driver scc)
# Hacer un nuevo driver de linux o modificar el scc existente para que funcione con la tarjeta PCI (intentando primero lo de modificar el existente...).

Diferencias entre la tarjeta PCI y la ISA
|Característica|PCI|ISA|Comentarios|
|Oscillator|7.37280 Mhz|4.9152 Mhz|La PCI va a 1.5x la ISA|

_
! Attachs

*+5103.pdf+*
scc.c+
scc pci.c+

- lock this page
- enter new password
- reenter same password

Send e-mail alerts to these addresses upon next save: