No empecemos la casa por el tejado, que parecemos GPH con la F100, que cuando la sacaron ya había ports, pero el firm era poco menos que una pre-alpha.
◄|| SECHS ||►
No empecemos la casa por el tejado, que parecemos GPH con la F100, que cuando la sacaron ya había ports, pero el firm era poco menos que una pre-alpha.
Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadiala latencia es el problema intrinseco de stadia, el público abandona google stadia, stadia mal.
CPC Fan
Ya sé por qué no tira el sonido con el REminiscence o el Xrick y sí lo hace con el ScummVM: al inicializar el audio con las SDL, sólo si lo hacemos con desired.format = AUDIO_S16SYS; funciona. Con AUDIO_S8 o AUDIO_U8 no suena. El problema ahora es que el audio suena al doble de velocidad.
Otra cosa, ¿podrías poner el volumen del audio más bajo? Me parece que por defecto está al máximo. También no estaría mal poder cambiar el audio/brillo del LCD con power + el pad tal y como hablamos en un post anterior y que los valores del volumen/brillo se guardaran automáticamente para la próxima vez que se arranque linux.
Usuario Registrado
Mmmm... sí y no. Acabo de poner una página en el wiki de google code explicando más o menos cómo hacerlo, con una salvedad: no se cómo preparar un sistema de archivos ext2/ext3 desde windows, o sea, que se puede hacer arrancar linux en la A320 pero preparar el root filesystem sigue siendo necesario hacerlo desde linux.Iniciado por chipan
En la página del wiki (QuickStartWin) hay un par de "huecos" que solicito ayuda para rellenar (lo siento, ando muy mal de tiempo):
1- ¿Cual es el driver que alguien usó para que el puerto seriel CDC ACM sea usable en Windows? (me basta con un enlace).
2- Explicación de cómo instalar el toolchain (que imagino que será cygwin-based) en Windows y cómo compilar programas.
< - >Lo que me estoy dando cuenta es que además de hacer que la A320 arranque en linux sin necesidad de usar un PC, he de buscar la forma de hacer que todo el proceso (incluyendo la preparación del rootfs) se pueda hacer desde Windows, porque ese será el caso de la mayoría de usuarios (que no programadores).
Lo del bootloader de los chinos de ChinaChip tiene delito. He "extraido" el SPL...
(recordatorio: el JZ4740 arranca código de ROM llamado IPL, que carga 8K de código de la NAND, llamado SPL, en la caché de instrucciones y le pasa el control)
.. de ChinaChip y lo he sustituido por el SPL del u-boot junto con el propio u-boot y una copia del SPL de ChinaChip, de forma que lo que arranca siempre es u-boot y luego desde ahí ya se puede escoger entre cargar el zImage (kernel linux) o bien cargar y ejecutar el SPL original de ChinaChip.
Pues bien... esos miserables 8K de código se niegan a funcionar en un contexto ligeramente diferente al que tienen normalmente (recién cargado por el IPL versus cargado por u-boot).
Así que parece que la única opción va a ser desensamblar y meterle mano directamente a esos 8K del SPL del firmware original. Hay varias opciones:
1- Entender por qué "casca" cuando lo lanza el u-boot en lugar del IPL (aunque sea en la misma dirección y todo lo demás).
2- Entender cómo carga de NAND el sistema operativo, modificar el código para que en función de la tecla SELECT cargue de una posición distinta, donde estará el u-boot, y compilar el u-boot para que funcione cargado en las mismas circunstancias en que se carga el sistema operativo del firmware original. Esto parece muy complicado.
3- Modificar el SPL de u-boot para que antes de hacer nada de nada, compruebe el estado de la tecla SELECT y si no está pulsada pase el control al código del SPL original. El problema es que todo esto tiene que seguir cabiendo en los 8K disponibles, es decir, una versión reducida del SPL del u-boot junto con el SPL original. Esto va a ser complicado porque creo que el SPL original usa unos 6K, dejando sólo unos 2K para meter lo que sea, y el SPL del u-boot, tal cual viene, ocupa unos 5K. Supongo que lo puedo adelgazar mucho a base de quitar cosas, pero lo veo difícil.
Comenté ya "casi" lo tengo porque he sido capaz de grabar el u-boot-spl y u-boot en la flash de tal forma que arranca y carga zImage desde la primera partición de la miniSD, pero aún no he logrado transferir con éxito el control al SPL original para que la A320 arranque normalmente.
En cuanto al otro tema, que es lo de proporcionar un rootfs que se pueda instalar desde windows, el problema se reduce a que desde windows sólo se puede usar FAT32 (no NTFS no sirve), y FAT32 no soporta dispositivos especiales (todo lo que en linux va en /dev) ni enlaces simbólicos.
Lo que se puede hacer es proporcionar un sistema de archivos ext2/ext3 en un único archivo "gordo" que se copiará en la miniSD junto a zImage. Cuando el kernel arranca, hay que ponerle un initramfs que monte la partición FAT32 de la miniSD, luego que monte el archivo "gordo" como un dispositivo loopback, y finalmente que monte ese loopback como raíz. Todo esto ya lo he hecho antes pero hace algún tiempo así que tengo que refrescarlo....
< - >Oops... tienes razón, no puede estar usando ALSA porque yo no incluí la libasound en el rootfs y entonces si se hubiera compilado con ALSA daría un error de librería "missing" durante la carga del ejecutable.
Lo único que se me ocurre es que esos programas usen una frecuencia de muestreo de salida para el dispositivo de audio que no esté soportada de forma nativa por el hardware. Con ALSA en estos casos se hace un resampling por software, pero me parece que con OSS simplemente no funciona. Y es posible que algunos programas estén usando frecuencias que sí que están habitualmente soportadas por el hardware del PC pero que no lo estén por el hardware de la A320 o que el driver de los chinos sea una patata y no las implemente... a saber.
¿ Podrías echar un vistazo al código de inicialización de audio de los programas que sí sacan sonido y compararlo con el de los que no sacan audio, y comprobar si la frecuencia de muestreo de salida es diferente (o algún otro parámetro relevante como los bits por muestra, etc) ?.
No exáctamente. Era la demo de transparencia y lo que se veía mal no era ningún tipo de distorsión rara, sino unas líneas extrañas. No se cómo definirlo... y no tengo la cámara aquí conmigo para hacer un vídeo.Creo que tendrá que ver con el hecho que comentabas de que se está copiando constantemente por DMA el framebuffer a la GRAM del LCD.
Ok. Le echaré un vistazo el fin de semana.¡¿Puedes pasarme el ejecutable compilado para que lo vea? (o mejor aún subir un video a youtube)
No tengo cámara así que te mando un PM con un link al ejecutable con todo lo necesario.
Ok. Lo cambio este fin de semana y genero una nueva imágen del kernel.D-Pad: flechas
Botón A: LCONTROL
Botón B: LALT
Botón X: SPACE
Botón Y: LSHIFT
Botón hombro izquierdo: TAB
Botón hombro derecho: BACKSPACE
START: RETURN
SELECT: ESCAPE
¿Todos de acuerdo en que este es el mapa de teclado más lógico?
Última edición por booboo; 28/05/2009 a las 23:44 Razón: Edición automática anti doble-post.
Usuario Registrado
Booboo,
Sí, puede crear un sistema de ficheros ext2/ext3 a partir de Windows. He utilizado el Paragon Partition Manager. Insertar el SD in lector de tarjetas del ordenador, abra el Parangon y ha creado una partición FAT32 y una ext3. Descomprime el Rootfs usando 7-Zip, copia, com o proprio Paragon, para la partición ext3 y poner el SD in MP4.
Booboo, ayúdame, por favor. ¿Donde puedo encontrar los parámetros (en el codigo fuente) de configuracion (drivers) específicos para la LCD, SRAM e GPIO del Dingoo A320? ¿hwinit, zImage? ¿Donde? Gracias!
Doug
Usuario Registrado
Eso es un problema del driver de Ingenic, que es una patata. Que no implementen frecuencias de muestreo que no soporte directamente el hardware tiene excusa, pero que no implementen la sencillísima conversión 8 bit -> 16 bit (o signed->unsigned) es para matarlos.
Lo apunto para este fin de semana.
Sí, lo se. Pero creo que lo adecuado sería compilar alguna aplicación para OSS de las que se encargan de controlar el volumen, a ser posible una de línea de comandos. Yo he programado para ALSA (donde se usa amixer o alsamixer para ese propósito) pero para OSS no tengo ni idea de cómo se hace. Si lo puedes investigar tú te lo agradecería, porque así puedo dedicarme a lo del kernel.Otra cosa, ¿podrías poner el volumen del audio más bajo? Me parece que por defecto está al máximo.
No lo he hecho aún porque he estado pensando en la forma correcta de hacerlo. Lo voy a comentar a ver si entre todos lo aclaramos un poco:También no estaría mal poder cambiar el audio/brillo del LCD con power + el pad tal y como hablamos en un post anterior y que los valores del volumen/brillo se guardaran automáticamente para la próxima vez que se arranque linux.
La forma políticamente correcta de gestionar el brillo de la pantalla y el volumen del audio es en los drivers correspondientes. En el caso del audio imagino que ya se encarga OSS y en el caso del brillo hay que escribir un driver muy sencillito para el subsistema correspondiente del kernel.
Una vez hecho esto, cualquier programa de usuario puede, comunicándose con el driver correspondiente y sin conocer nada del hardware, subir o bajar el volumen y el brillo.
Evidentemente, no mola nada que CADA emulador o aplicación que se porte tenga que incluir código específico para subir o bajar el volumen o el brillo, así que tendríamos que hacer un demonio (programa que corre en segundo plano) que fuera el único que se encargara de ello... pero al ser un demonio no tiene "input" de teclado, así que ¿cómo sabe el demonio cuándo estamos pulsando las combinaciones de teclas correspondientes para controlar el volumen y el brillo?.
La respuesta está en el sistema de eventos de usuario que tiene el subsistema input del kernel. Desde un driver es posible generar eventos especiales que no van por el canal "normal" por donde van las pulsaciones de teclas sino que van a un dispositivo especial que el demonio puede abrir y leer. De esa forma, sólo tengo que hacer que el driver de teclado genere unos eventos especiales cuando se pulse ON+arriba, ON+abajo, etc... (y no generar las pulsaciones de teclas arriba, abajo, etc en esos casos).
Como decía al principio, todo esto es muy "políticamente correcto" o muy "standard compliant" porque utiliza los mecanismos que ya proporciona el kernel. Sin embargo, volvemos a lo de siempre: en un sistema tan limitado en memoria como la A320, y al que queremos sacarle tanto jugo como sea posible, interesa optimizar las cosas un poco más.
Luego está el enfoque "guarro": desde el propio driver de teclado cuando detecte las combinaciones de teclas especiales, directamente subo o bajo el volumen (en el driver OSS de audio) o el brillo (directamente al hardware, se usa el PWM7). Esto es MUY sencillo y muy rápido de hacer... y una guarrada. Además al ocurrir todo en el kernel no hay una forma directa de que una aplicación de usuario pueda mostrar el nivel actual de volumen o de brillo, aunque esto se podría solventar fácilmente haciendo esta información accesible en /proc desde el mismo driver de teclado.
Hay una alternativa sólo un poco menos guarra en el sentido de que todo sigue pasando en el kernel pero el mecanismo de comunicación entre el driver de teclado y los otros drivers es un poco más "agnóstica", y es usando los eventos sysrq. Para el que no sepa de que hablo, en linux hay una serie de combinaciones de teclas especiales que generan eventos sysrq. Otros drivers se pueden "suscribir" a esos eventos. Se suele utilizar para realizar acciones "a ciegas" en el kernel en situaciones límite, como por ejemplo cuando ha petado la consola o el entorno gráfico, y para hacer cosas como sincronizar la caché de disco o reiniciar el sistema. El caso es que es un mecanismo de comunicación estandarizado y yo puedo, desde el driver de teclado generar unos eventos sysrq propios y especiales y luego en los otros drivers "suscribirlos" a esos eventos y actuar según interese. Todo esto tendría además la ventaja de que realmente se pueden aprovechar algunos eventos sysrq estándar de linux que pueden ser útiles en la A320, como el reinicio incondicional. Así tendríamos combinaciones de teclas para subir o bajar el volumen/brillo, para reiniciar la consola, etc.
Ah!, lo olvidaba: a diferencia de las X, el framebuffer no se puede compartir por más de una aplicación, así que no sería posible hacer algo tan bonito como lo de mostrar una "transparencia" en pantalla con el nivel de volumen o de brillo cuando se modifica, tal y como hace por ejemplo ubuntu. Digo que no se podría desde una aplicación de usuario, pero SI QUE SE PODRÍA desde el kernel, sin más que establecer otra comunicación "guarra" con el driver del framebuffer. Ahí de nuevo hay dos opciones, hacer un alpha-blending opcional con un segundo framebuffer (consume memoria y CPU, pero es simple y portable), o bien implementarlo -con dos cojones- en el LCD, ya que éste permite una especie de PIP (pincture-in-picture), es decir, mostrar el contenido rectangular (¿y escalado?) de una segunda zona del buffer de GRAM sobre el buffer principal. Esto no consumiría recursos pero sería muy poco portable (estoy pensando en la x760+ y similares).
Por último, sobre lo de guardar el nivel de brillo/volumen: esto es MUCHO más jodido de lo que parece. Me explico: hay dos opciones, o bien lo guardamos en el sistema de archivos de linux (como un archivo de configuración más) o bien lo guardamos a piñon en una zona específica de la NAND flash. Lo primero tiene el inconveniente de que estos parámetros sólo se pueden leer y fijar cuando linux YA HA ARRANCADO, luego durante el arranque el brillo del display tiene que tener un valor fijo. Lo segundo es muy complicado, sobre todo si hay que mantener el firmware original, ya que hay que buscar una zona de la NAND flash (un eraseblock entero = 512KB) que no use el firmware original. Luego, además, andar borrando ese eraseblock entero cada vez que se cambia el volumen o el brillo es una barbaridad, porque la memoria NAND de la A320 es del tipo MLC y la vida típica de un eraseblock son sólo 1000 ciclos de borrado. Cuando usamos un sistema de archivos estamos usando una capa intermedia que se encarga de hacer una traducción de sectores para "repartir" el desgaste (si escribimos 100 veces en un sector en realidad se están borrando y escribiendo en sectores físicos distintos cada vez), pero si estamos escribiendo "a pelo" en un eraseblock concreto de la NAND no hay vuelta de hoja, nos acabaremos cargando el sector.
El problema se puede solucionar con algunas estrategias especiales: cuando se borra la NAND todos los bits se ponen a 1. Para escribir lo único que podemos hacer es cambiar bits de 1 a 0, pero no al revés, para lo cual es necesario borrar TODO el eraseblock. Lo que se hace es, por ejemplo, escribir tres bytes: 0x01 <volumen> <brillo>. Cuando se va a cambiar el valor, se escribe 0x00 donde había 0x01 y se escribe de nuevo 0x01 <volumen> <brillo> pero en los tres bytes siguientes. Y así sucesivamente. Para averiguar los valores de brillo y volumen hay que ir leyendo los bytes de tres en tres en el eraseblock hasta encontrar un grupo de tres en el que el primero sea 0x01. Lo que estamos haciendo es, en lugar de "sobreescribir" los valores, invalidar los anteriores y escribir unos nuevos.
En resumen: se PUEDE hacer, pero guardar los niveles en un archivo no funciona bien del todo, y usar una zona específica de la flash (como hace el firmware original) causa problemas de compatibilidad con éste y obliga a utilizar estrategias complejas para no cargarse la NAND.
< - >LCD: en el kernel, archivos jz4740_slcd.h y jz4740_slcd.c. En el primero tienes la inicialización de los registros del LCD, y en el segundo la geomtría del LCD y algunas cosas específicas de la A320, como el tener que activar la señal RS# del display "manualmente" con un pin GPIO cada vez que se escribe en un registro de configuración del LCD.
SDRAM: en el código de hwinit.
GPIO: hay una página en el wiki de google code bastante extensa donde he detallado todo lo que se sobre el uso de los pines GPIO en la A320. Está lo más importante y conforme vaya averiguando lo que falta lo iré poniendo ahí.
Explorando el repositorio SVN de google code deberías poder examinar el historial de cambios y pedir "diffs" para ver en cada caso qué archivos han sido modificados y los cambios realizados.
Última edición por booboo; 29/05/2009 a las 00:32 Razón: Edición automática anti doble-post.
Usuario Registrado
Well at work I managed to get a good build of uclibc kernel and rootfs. I can add an initramfs very easily inside the utility so if you need that that should be simple to add. Once again doing another build at home since I kept running into build issues last night.
I would think for the nand stuff it may be in the included docs, I remmember seeing some on the nand programming and there are a few jz utilities to flash the nand.
Would you mind posting the options you used to compile sdl_gfx, would be nice to compile that with uclibc and integrate it in.
CPC Fan
Es éste y como programa de terminal, recomiendo el Tera Term
En mi caso particular, uso andLinux y la toolchain de Linux. Al instalar andLinux, comparto una carpeta por Samba para que sea accesible tanto en Windows como en andLinux. Si hace falta puedo escribir un pequeño tutorial este fin de semana.2- Explicación de cómo instalar el toolchain (que imagino que será cygwin-based) en Windows y cómo compilar programas.
Lo único que no he hecho desde Windows ha sido formatear/copiar el rootfs. Para eso he usado un CD de Ubuntu.Lo que me estoy dando cuenta es que además de hacer que la A320 arranque en linux sin necesidad de usar un PC, he de buscar la forma de hacer que todo el proceso (incluyendo la preparación del rootfs) se pueda hacer desde Windows, porque ese será el caso de la mayoría de usuarios (que no programadores).
Otra cosa: a ver si te acuerdas de mirar lo de los modos gráficos en 8bpp.
Usuario Registrado
Ya lo he puesto como "issue" en google code.
Echa un vistazo a todo lo que he metido por si me he dejado algo de todo lo que se ha hablado...
CPC Fan
El problema con el audio en 8 bits.
Usuario Registrado
Acabo de corregirlo. El código del driver de sonido OSS da miedito. No llega ni a alpha. Calidad nefasta, chapuzas y errores por un tubo... acojonante.
También he cambiado lo del teclado. Ahora luego cuelgo en google code un nuebo binario del kernel (el código en el repositorio svn, obviamente). ¿Podrías comprobar que el mapa de teclado ahora es correcto?.
Por favor prueba bien el tema del sonido porque a mi se me ha colgado una vez. Sólo una, y no me ha vuelto a pasar, pero si observas cualquier cosa rara, dímelo.
Otra cosa: ¿podrías probar qué tal funciona el control de volumen?. Sólo hay que compilar alguna utilidad que permita modificar el mixer de OSS. Lo digo porque no existe un control de volumen como tal, y lo que se hace es un desplazamiento a la derecha de los bits de las muestras.
Además, ahora que me acuerdo, el control de volumen no funcionará en el modo de 8 bits. Cuando tenga un rato lo arreglo.
Última edición por booboo; 30/05/2009 a las 06:29
CPC Fan
Es correcto.
Me ha pasado una cosa muy rara: he compilado el REminiscence con desired.format = AUDIO_S8 y no sonaba; después he probado con desired.format = AUDIO_U8 y sonaba, pero muy mal y he notado que los altavoces olían a quemado así que he reseteado rápido. Ahora, tanto con AUDIO_S8 como con AUDIO_U8 no suena, pero sí lo hace con AUDIO_S16SYS.Por favor prueba bien el tema del sonido porque a mi se me ha colgado una vez. Sólo una, y no me ha vuelto a pasar, pero si observas cualquier cosa rara, dímelo.
Otra cosa: ¿podrías probar qué tal funciona el control de volumen?. Sólo hay que compilar alguna utilidad que permita modificar el mixer de OSS. Lo digo porque no existe un control de volumen como tal, y lo que se hace es un desplazamiento a la derecha de los bits de las muestras.
He probado con GOM (The Generic OSS Mixer) y no me deja cambiar el volumen:
Siento no poder ser de más ayudaCódigo:gom: Overall information gom: ------------------- gom: gom: Configuration: gom: Mixer special file: no_mixer_opened. gom: Fade duration : 5 seconds. gom: Gomii refresh : all 30 seconds. gom: Verbosity : 1 [<=-1:ERROR, 0:QUIET, 1:NORMAL, 2:VERBOSE, >=3:DEBUG]. gom: Lock mask : (see table below). gom: Errors detected : 0. gom: gom: Current mixer information: gom: Driver used : OSS (Open Sound System) API gom: Available channels: 0 / 25 gom: ------------------------------------------------ gom: No Name Rec Volumes Vol-0 Vol-1 Locked gom: ------------------------------------------------ gom: ------------------------------------------------ gom: 0.vol -1 -1 -1 -1 1 gom: 1.bass -1 -1 -1 -1 1 gom: 2.treble -1 -1 -1 -1 1 gom: 3.synth -1 -1 -1 -1 1 gom: 4.pcm -1 -1 -1 -1 1 gom: 5.speaker -1 -1 -1 -1 1 gom: 6.line -1 -1 -1 -1 1 gom: 7.mic -1 -1 -1 -1 1 gom: 8.cd -1 -1 -1 -1 1 gom: 9.mix -1 -1 -1 -1 1 gom: 10.pcm2 -1 -1 -1 -1 1 gom: 11.rec -1 -1 -1 -1 1 gom: 12.igain -1 -1 -1 -1 1 gom: 13.ogain -1 -1 -1 -1 1 gom: 14.line1 -1 -1 -1 -1 1 gom: 15.line2 -1 -1 -1 -1 1 gom: 16.line3 -1 -1 -1 -1 1 gom: 17.dig1 -1 -1 -1 -1 1 gom: 18.dig2 -1 -1 -1 -1 1 gom: 19.dig3 -1 -1 -1 -1 1 gom: 20.phin -1 -1 -1 -1 1 gom: 21.phout -1 -1 -1 -1 1 gom: 22.video -1 -1 -1 -1 1 gom: 23.radio -1 -1 -1 -1 1 gom: 24.monitor -1 -1 -1 -1 1 gom: ------------------------------------------------ gom: -1 = unavailable, 1 = yes (or value), 0 = no (or value), /mnt/fat # ./gom -C 10 gom ERROR: Can't set volume to 10 on channel 0(vol): volume unavailable.
Usuario Registrado
Eso es normal porque el driver sólo soporta los formatos U8 y S16. Añadir los demás es sencillo pero he preferido no añadir nada a parte de la corrección para que U8 suene precisamente por si algo no iba bien reducir el campo de búsqueda.
después he probado con desired.format = AUDIO_U8 y sonaba, pero muy mal y he notado que los altavoces olían a quemado así que he reseteado rápido.
Whoa... eso SI que es RARO. Tú mismo puedes ver el cambio que he hecho en el código para que U8 funcione: han sido 5 horas intentando entender cómo funciona el driver y 10 segundos para hacer el cambio. Te explico cual era el problema y cual ha sido el cambio, porque no he hecho nada raro que pudiera afectar a tus altavoces, si bien es cierto que ahora que lo pienso por la hora que era todas las pruebas las hice con los auriculares. Y por cierto, que hay un GPIO por ahí que afecta al audio y cuya función aún no tengo clara... precisamente el efecto audible es justo lo contrario de lo que tu mencionas: cuando está en un estado determinado ese pin, los auriculares se oyen fatal, pero no afecta en absoluto a los altavoces.
El problema era el siguiente: resulta que el driver SIEMPRE (bueno... para los dos formatos soportados U8 y S16) envía el audio al hardware en formato S16, y lo que hay es código que según el formato escogido por el programa de usuario, traduce de ese formato a S16 cuando está llenando el buffer para DMA:
mono U8 --> stereo S16
stereo U8 --> stereo S16
mono S16 --> stereo S16
strero S16 --> stereo S16
(implementar conversores para los demás formatos es relativamente sencillo una vez has entendido la retorcida mente del programador que lo hizo... de hecho YA he implementado los demás formatos pero no lo he incluido todavía por el motivo que ya he mencionado antes)
Pues bien... a pesar de que el código durante el playback y grabación (no probada) siempre convierte a S16 y así lo envía al hardware, resulta que durante la inicialización del dispositivo de audio configura el hardware para un tamaño de muestra coherente con lo que el usuario ha seleccionado. En el caso de U8 tenemos que el hardware acababa configurado para muestras de 8 bit pero el driver luego le envíaba muestras de 16 bit.
Así que lo UNICO que he hecho ha sido cambiar la inicialización para que independientemente del formato de muestra seleccionado por el programa de usuario, el hardware se configure para muestras de 16 bits, que es lo que toca.
Por lo tanto, el cambio es mínimo y no veo forma de haber afectado a nada más que pueda hacer que en tu máquina suene mal. Por otra parte, como digo, lo probé con auriculares...
Esta noche lo vuelvo a probar todo bien.
Lo único que se me ocurre es lo siguiente (aunque es un poco marciano): hay varios GPIO cuya función aún no he averiguado, y en el kernel actual, en lugar de configurarlos como salida y puestos al valor que se que el firmware original pone durante el funcionamiento normal, simplemente los he ignorado durante la inicialización. Eso significa que se quedan configurados como entrada, por lo que no puede haber posible conflicto eléctrico. Ahora bien, como ese pin está conectado a la entrada de otro chip, al no estar configurado como salida la entrada de ese otro chip está "flotante", a menos que el pin lleve integrada una resistencia de pull-up o pull-down o que haya una resistencia similar externa (esas resistencias simplemente aseguran un valor "por defecto" de la señal eléctrica cuando no se expecifica explícitamente con un pin porque esté puede funcionar como salida o como entrada). Me consta que la A320 tiene un bit de configuración GPIO para deshabilitar la resistencia de pull, o sea que deben estar integradas en el pin. El valor por defecto de ese bit (que yo no modifico porque ignoro esos pines como ya he dicho) hace que el pull esté activado, por lo que el estado de la señal eléctrica no creo que sea "flotante". Todo esto lo explico porque una señal "flotante" puede tomar un valor digital u otro según el día que haga y un millón de factores más, por lo que en tu caso podría suponer un problema (saturar el amplificador o algo así) y en el mío no.
Voy a preparar un kernel que inicialice todos los GPIO desconocidos a los mismos valores que he visto en el firmware original, por si acaso. Si no lo hice en su momento es porque por el razonamiento anterior no pensaba que fuera problema.
Ah!... y en el caso de esos dos pines GPIO que sé con seguridad que tienen una función de audio, sí que los inicializo al valor del firmware original, así que tendría que ser algún otro el involucrado.
*****... eso SÍ QUE ES RARO.Ahora, tanto con AUDIO_S8 como con AUDIO_U8 no suena, pero sí lo hace con AUDIO_S16SYS.
1- Te funciona con U8 pero huele a "torrao" y reseteas.
2- No funciona con U8, pero sí que funciona con S16SYS.
No tiene sentido. Si se ha torrado eléctricamente algo se notaría independientemente del formato de muestra...
Estás siendo de MUCHAayuda. Para empezar ya se qué programa usar para controlar el mixer de OSS. Es posible que el código de los chinos simplemente no funcione en lo relativo al volumen.He probado con GOM (The Generic OSS Mixer) y no me deja cambiar el volumen:
Siento no poder ser de más ayudaCódigo:gom: Overall information gom: ------------------- gom: gom: Configuration: gom: Mixer special file: no_mixer_opened. gom: Fade duration : 5 seconds. gom: Gomii refresh : all 30 seconds. gom: Verbosity : 1 [<=-1:ERROR, 0:QUIET, 1:NORMAL, 2:VERBOSE, >=3:DEBUG]. gom: Lock mask : (see table below). gom: Errors detected : 0. gom: gom: Current mixer information: gom: Driver used : OSS (Open Sound System) API gom: Available channels: 0 / 25 gom: ------------------------------------------------ gom: No Name Rec Volumes Vol-0 Vol-1 Locked gom: ------------------------------------------------ gom: ------------------------------------------------ gom: 0.vol -1 -1 -1 -1 1 gom: 1.bass -1 -1 -1 -1 1 gom: 2.treble -1 -1 -1 -1 1 gom: 3.synth -1 -1 -1 -1 1 gom: 4.pcm -1 -1 -1 -1 1 gom: 5.speaker -1 -1 -1 -1 1 gom: 6.line -1 -1 -1 -1 1 gom: 7.mic -1 -1 -1 -1 1 gom: 8.cd -1 -1 -1 -1 1 gom: 9.mix -1 -1 -1 -1 1 gom: 10.pcm2 -1 -1 -1 -1 1 gom: 11.rec -1 -1 -1 -1 1 gom: 12.igain -1 -1 -1 -1 1 gom: 13.ogain -1 -1 -1 -1 1 gom: 14.line1 -1 -1 -1 -1 1 gom: 15.line2 -1 -1 -1 -1 1 gom: 16.line3 -1 -1 -1 -1 1 gom: 17.dig1 -1 -1 -1 -1 1 gom: 18.dig2 -1 -1 -1 -1 1 gom: 19.dig3 -1 -1 -1 -1 1 gom: 20.phin -1 -1 -1 -1 1 gom: 21.phout -1 -1 -1 -1 1 gom: 22.video -1 -1 -1 -1 1 gom: 23.radio -1 -1 -1 -1 1 gom: 24.monitor -1 -1 -1 -1 1 gom: ------------------------------------------------ gom: -1 = unavailable, 1 = yes (or value), 0 = no (or value), /mnt/fat # ./gom -C 10 gom ERROR: Can't set volume to 10 on channel 0(vol): volume unavailable.
La verdad es que el código del OSS cuando lo miras de la impresión de que alguien lo ha hecho en una tarde y que se lo dejó a medias probando cosas. Tendría sentido si a continuación lo que hubiera hecho hubiera sido lo lógico: implementar ALSA bien. De hecho el toolchain de Ingenic contiene la librería alsa (libasound), pero claro, cuando en su día probé ALSA y no funcionaba y probé OSS y funcionó a la primera, pues me quedé con OSS.
Bueno... cuando llegue a casa me pongo a ello.
CPC Fan
He estado mirando la forma de poder cambiar el volumen y me acordé de cómo se hacía en la gp2x (mirando en el google, también he encontrado soluciones casi idénticas para cualquier distribución de linux)
Lo he probado con distintos valores y el volumen de la Dingoo ni se inmuta (el valor que devuelve open("/dev/mixer", O_RDWR); es 3, por si te sirve de algo.)Código:void gp2x_init() { soundDev = open("/dev/mixer", O_RDWR); int vol =(((100*0x50)/100)<<8)|((100*0x50)/100); ioctl(soundDev, SOUND_MIXER_WRITE_PCM, &vol); } void gp2x_set_volume(int volume) { int vol = (((volume*0x50)/100)<<8)|((volume*0x50)/100); ioctl(soundDev, SOUND_MIXER_WRITE_PCM, &vol); }
Y aquí un ejemplo que usa "/dev/dsp" pero tampoco me ha funcionado:
Código:#define AUDIO_DEV "/dev/dsp" mixfd = open(AUDIO_DEV, O_RDWR); if (mixfd > -1) { ioctl(mixfd, SOUND_MIXER_READ_PCM, &oldvol); result = sound_vol; val = (result) | (result <<8); ioctl(mixfd, SOUND_MIXER_WRITE_PCM, &val); }
Usuario Registrado
¿cómo puedo descargar todo el código fuente del kernel de Dingoo Linux para hacer algunos cambios, compilar de nuevo y testarlo? No he encontrado esta opción en el código de Google.
Gracias,
developia.info
Desde el SVN de la web http://code.google.com/p/dingoo-linux/
Con subversion
svn checkout http://dingoo-linux.googlecode.com/svn/trunk/ dingoo-linux-read-only
< - >Una duda, dondees más recomendable descomprimir libs-20090518.tar.bz2? en
.../mipsel-4.1.2-nopic/mipsel-linux
o bien en
.../mipsel-4.1.2-nopic/
Última edición por LTK666; 31/05/2009 a las 14:32 Razón: Edición automática anti doble-post.
:: Developia :: http://www.developia.info :: a.k.a Uguru
Citar
Marcadores