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

[Correo Fernando-ruiz (E-mail)]

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
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
>
>
>
>