RV: Driver para floppy (aka: DMA y memoria física)

Alejandro Villanueva 190921 at cepsz.unizar.es
Wed Jun 20 07:58:21 UTC 2001


SORRY AGAIN FOR THE INCONVENIENCE.

I have written a rudimentary IDE driver as well as a really simple FAT16
filesystem for GNAT/RTEMS and for C/RTEMS. I've got too a HD cache working.
Anyone interested?
*******************************************************************************************

Camilo, Fernando:

Yo me he visto forzado a escribir un driver IDE y un sistema de ficheros FAT16
para un sistema empotrado que estoy desarrollando en la Universidad de
Zaragoza. Tengo también funcional una caché de disco, pero de momento no la
estoy empleando porque no es necesario (acceso poco intensivo a disco). Si
estais interesados en el codigo fuente hacedmelo saber. Siempre es bueno que
critiquen el trabajo de uno, de manera que podamos acabar con unos drivers
mucho mejores.

PD. Implementé también un driver de Sound Blaster 16, por exigencias del guión.


On Tue, 19 Jun 2001, Correo Fernando-ruiz \(E-mail\) wrote:
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> SORRY. For the inconvenience.
> THIS IS A RTEMS CONCERN BEETWEEN
> TWO SPANISH SPEAKERS.(MORE PEOPLE INTERESTED?)
> THE SPANISH IS OUR NATURAL LANGUAGE.
> This is really a private e-mail but the camilo's isp
> doesn't work.
> 
> We want build a floppy disk device and more after this (FAT?)
> 
> Camilo ask about the seek in a rtems_device.
> 
> My answer is that the lseek.c sets the offset in the iop parameter
> for the read/write routine.
> Only at the moment of the read/write device
> the physical movement of heads is necesary.
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> Buenas...
> 
> > -----Mensaje original-----
> > De: carboleda [mailto:carboleda]En nombre de Camilo Alejandro Arboleda
> > Enviado el: martes, 19 de junio de 2001 15:39
> > Para: correo at fernando-ruiz.com
> > Asunto: Driver para floppy (aka: DMA y memoria física)
> >
> >
> > > Creo que no es un buen camino liarse con el IMFS por el momento.
> >
> > > Mejor seria tener un acceso MSDOS/ext2/minix para poder hacer
> > > intercambiables los datos entre
> > > el sistema y el mundo exterior.
> >
> > En reallidad el IMFS lo estoy leyendo para hacerme una idea
> > de como funciona
> > el sistema de archivos. Mi idea es tener soporte para FAT, ya
> > que es un
> > sistema de archivos muy sencillo.
> >
> > > Tengo un driver de FLASH que maneja la
> > > memoria en forma de fichero de dispositivo.
> > > Puedo hacer un seek y un read/write aleatorio.
> >
> > Como haces el seek? Hasta donde he visto el RTEMS ignora los
> > llamados a lseek
> > en dispositivos (ver 'deviceio.c'). Por ejemplo, si trato de
> > compilar el
> > siguiente código:
> >
> > fd = open("/dev/fd0",O_RDWR);
> > lseek(fd,10,SEEK_SET);
> >
> > este compilará bien, pero la función lseek no tendrá ningún
> > efecto porque el
> > driver no posee un callback para esta función.
> 
> No te preocupes. En el driver en lectura tienes un campo de offset en
> arg_io_readwrite...
> Este es el offset de posicionamiento dentro del fichero. El seek no llama
> a nada pero si ubica este offset (Si no estoy equivocado)
> Al menos lo incremente en cada nuevo read/write que no es poco. Un seek creo
> que unicamente
> posiciona este valor.
> 
> /rtems/c/src/lib/libc/lseek.c  ESTABA EN LO CIERTO.
> 
> El unico problema seria lseek(SEEK_END). Es necesario en el open dar al iop
> que te pasan como parametro (¿Donde?) el campo size. Asi un posterior
> SEEK_END sera valido. Mejor . No lo llames.
> 
> >
> > > No seria mejor un sistema de ficheros basado en un
> > Dispositivo o un fichero
> > > mismo?
> >
> > Esa es mi idea. Estoy estudiando el IMFS porque es el único sistema de
> > archivos que está implementado para RTEMS.
> >
> > > De esta manera el dispositivo se puede copiar en plan linux
> > > cp /dev/fd0 /tmp/disco1.img
> > > para posteriormemte poder hacer un
> > > mount -t fat /tmp/disco1.img /mnt/disco
> > >
> > > Eso seria algo mas UNIX que el invento del IMFS.
> > > Con un poco de trabajo es posible llegar a comprenderlo pero
> > > como comunicacion con el mundo exterior no es nada bueno.
> > >
> > > Mejor leyendo el fuente de GRUB se puede comenzar a pensar
> > en un FAT/ext2
> > > de solo-lectura accediendo a un dispositivo /dev/fd0.
> > Posteriormente un
> > > sistema con escritura y cache (?).
> >
> > Ya lo he mirado, pero no he obtenido mucha información,
> > porque el código no
> > posee casi documentación.
> 
> COmo todo este mundillo en general.
> 
> >
> > > El sistema de cache para la flash lo incorpora mi propio driver de
> > > dispositivo.
> > > Algo asi es necesario para el floppy/hard-disk.
> >
> > No estoy seguro, creo que yo preferiría tener un cache de
> > archivos y no un
> > cache de disco. Esto porque generalmente el programador ve
> > los archivos y
> > trabaja sobre ellos, no sobre el disco. He visto que el Minix
> > (no se si el
> > linux) trabaja con esta filosofía.
> >
> Pero hay algo que es clave en un sistema FAT. Hay dos o tres sectores
> abrasados
> y el resto no son accedidos mas que de vez en cuando. Un buen gestor LRU de
> memoria cache de sectores creo que seria un buen cache. El experto de estas
> cuestiones en Joel.
> Hizo su master en cache de discos duros (Me parece haber leido).
> 
> > > >
> > > > Tan pronto como tenga algo mas desarrollado (lease, algo en verdad
> > > > útil), te lo envío.
> > > >
> > >
> > > Te vendria bien que desarrollara alguna parte del conjunto?
> > >
> > > Podria ir haciendo una especie de sistema de ficheros FAT sobre
> > > un fichero en memoria.
> > > Una vez listo el sistema leeria del controlador de diskette.
> >
> > Sería en verdad de gran ayuda, aunque primero habría que solucionar el
> > problema del seek. De momento lo estoy haciendo a través de
> > un llamado a
> > ioctl. Dime que opinas y coordinamos.
> 
> 
> Miro un poco mas profundamente el tema del seek y te cuento.
> Pero yo si que tengo en cuenta este valor a la hora de acceder
> a la memoria del dispositivo. SI no me queda mas memoria para leer retorno
> menos
> bytes que los solicitados y punto.
> Y funciona una orden 'cat /dev/ramrtc' a la perfeccion.
> 
> MIRADO:
> Me reafirmo. Pasa del ioctl. Haz tu seek normal al byte correspondiente.
> RTEMS situa pues iop->offset al byte exacto de comienzo de lectura/escritura
> Unas reglas de geometria de H,C,S de acuerdo a la disposicion del
> diskette/harddisk
> se redondea al sector mas proximo. Se lee el bloque (Sector?) y se pasa de
> la memoria cache
> a la direccion pasada como parametro. (Que te voy a contar...)
> 
> Deja el ioctl para cuestiones de formateo y conprobaciones de crc(?) y cosas
> asi.
> 
> 
> Por cierto en mtools (mdir,mcopy,mdel, etc) de los fuentes de linux hay
> autenticas
> maravillas para implementar utilidades y el mismo filesystem de VFAT,FAT
> etc...
> Documentado como siempre pero con un codigo mas que digno preñado de
> comentarios.
> 
> Fernando RUIZ CASAS
> home: correo at fernando-ruiz.com
> work: fernando.ruiz at ctv.es
> 
> 
> >
> > Camilo Alejandro Arboleda
> > Ingeniero de Proyectos
> > Ascom Colombia S.A.
> > http://www.ascom.com
> >
> >
> >
> >
-- 
------------------------------------------------------
¿Quieres Cobrar por Navegar en Internet? 
Visita: http://www.navegana.com/dinero/flintstone.html 
------------------------------------------------------ 
Alejandro Villanueva
190921 at cepsz.unizar.es
------------------------------------------------------



More information about the users mailing list