[OFICIAL]: Scene Dingoo A320

[booboo]

Como ya tenía el vídeo, el sonido y el teclado funcionando, he portado (compilado más bien) la SDL y el madplay para hacer una demo rápida:

http://www.youtube.com/watch?v=CCGW4ZZMNmo

La SDL no va bien en los modos de 8bpp, (con paleta), ya lo miraré, pero me da a mí que debe ser la implementación del framebuffer de Ingenic que no es muy allá.

Por cierto, ¿alguien conoce DirectFB?... ¿vale la pena que la porte?

He creado un sitio en google code y estoy subiéndolo todo. En breve en sus pantallas.

[otto_xd]

Muchas gracias, que pasada.

Por cierto, a que velocidad esta lanzandose linux y las demos??

De sdl tienes portado solo la parte grafica y de controles o tb tienes el audio??

Saludos, y gracias de nuevo.

[Juarrox]

Booboo, creo que deberías parar... las fuerzas del universo se pueden sentir ofendidas ante semejante poder y forzar la destrucción del mundo.


... ahora en serio, eres un CRACK ! Esto es scene!!!

[A600]

Simplemente alucinante y sólo tarda 5 segundos en arrancar Linux.

[nazca]

Que grande, por dios...

[Nekete]

Muchas gracia booboo, qué ganas de poder ver a tux en mi Dingoo

Una preguntilla, sabes si el mplayer o el libjpeg que tiene colgado Ingenic usan el "multimedia accelerator" que se supone tiene el JZ4732(JZ4740)?.
¿Podrá usarse para "agilizar" alguna tarea en el futuro?

edit:Lo digo porque el que tienen colgado parece genérico de los Jz47xx y algunos de ellos no tienen dicho acelerador.

Gracias

[booboo]

Por cierto, a que velocidad esta lanzandose linux y las demos??

A 336MHz. Es lo que viene por defecto y pensaba dejarlo así. Se puede cambiar en cualquier momento con el módulo cpufreq, que está hecho por los de Ingenic pero que aún no he probado (la experiencia con los de Ingenic me ha enseñado que el hecho de que el código para hacer algo esté no significa que además funcione).

De sdl tienes portado solo la parte grafica y de controles o tb tienes el audio??

Vídeo + sonido + input.

Decía que más que "portar" lo que he hecho ha sido "compilar". No he tocado una sola línea de código de momento, me he limitado a configurar el build para mips y quitar todo lo que no tiene sentido incluir en la A320.

ESA ES LA GRACIA DE TENER LINUX EN LA A320.

Quizás podría ser interesante cambiar una línea del código para no tener que especificar cada vez SDL_NOMOUSE, pero creo que eso es todo. Por supuesto tengo que investigar por qué no funcionan los modos de 8bpp, pero ya he dicho que estoy casi seguro de que es problema de la implementación del framebuffer de Ingenic.

Respecto al framebuffer, quiero hacer unas cuantas cosas importantes: examinar la "optimización" que hizo del framebuffer el que hizo el port para el onda vx747, sospecho que tendría que ver con que me da que el código de Ingenic está contínuamente enviando los datos (por DMA) a la memoria del display, en lugar de hacerlo de forma sincronizada con el refresco de éste. Esto, además de transferir muchos más datos de los necesarios (que por mucho DMA que se use siempre afecta al rendimiento global) hace que al no estar sincronizado el refresco de las imágenes se aprecien "cortes" en el barrido (no se expresarlo mejor, en inglés creo que se dice "tearing").

(hay como mínimo dos buffers implicados: el del framebuffer, desde el cual el kernel envía por DMA al del display, y el del propio display)
(hay como mínimo tres procesos que ocurren simultáneamente y que deben sincronizarse para tener un vídeo perfecto: el usuario está escribiendo en el framebuffer, el kernel está enviando datos del framebuffer a la memoria interna del display, y el controlador del display está leyendo la memoria interna e iluminando los píxeles. Paradójicamente sería todo más simple si el LCD no fuera "smart" y tuviera esa memoria interna, sino que refrescara los píxels según el barrido que hiciera el controlador interno del JZ4740, que para eso está. Lo gracioso es que los displays "tontos" creo que son más baratos, y además éste aunque es "smart" también puede funcionar en modo "tonto", pero en la A320 está conectado en modo "smart" y no hay nada que hacer, puesto que es una cuestión de hardware).

Respecto al sistem operativo, como mínimo habría que pasar a utilizar la uclibc en lugar de la libc estándar, que es muchísimo más pesada. Pero eso son ya palabras mayores, porque hay que recompilar el toolchain entero.

[chipan]

Me suena que A600 encontró la manera de poner la dingoo a 8 bits; creo que lo he leído en elgun hilo, pero a ver quien lo encuentra ahora.

[A600]

Me suena que A600 encontró la manera de poner la dingoo a 8 bits; creo que lo he leído en elgun hilo, pero a ver quien lo encuentra ahora.

Sí, pero sin saber dónde se almacena la paleta no sirve de mucho

[otto_xd]

Pues a excepcion de los modos de 8b, parece que se puede recompilar los juegos para sdl de otras consolas, nop?

Gigante señor booboo, gigante ^^
^
Saludos

[booboo]

Simplemente alucinante y sólo tarda 5 segundos en arrancar Linux.

Notas:

1- La imágen del framebuffer aparece en pantalla después de un par de procesos que consumen tiempo pero que no "ves" más que por la consola serie: la carga del kernel y su descompresión. No creo que sea en total más de un par de segundos. Tengo que confirmarlo, pero creo que u-boot no usa DMA para leer la tarjeta miniSD y por lo tanto podría tardar menos en cargar el kernel. Luego cuando el kernel vaya en la NAND habrá que ver qué velocidad de carga se consigue desde allí.

2- Hay un segundo de retardo forzado para que el kernel reconozca la miniSD antes de montar el root filesystem (parámetro rootdelay=1). Esto es para dar tiempo al subsistema hotplug de darse cuenta de que la tarjeta está insertada y cree el dispositivo correspondiente. La putada es que ese retardo no se puede especificar en fracciones de segundo. El cambio para hacerlo sería trivial, pero estaría alterando el formato de un parámetro estándar del kernel y no me hace gracia para ganar 1/2 segundo. Por supuesto este retardo no ocurriría en un arranque desde NAND (que se initializa completamente por sí sola, es decir, no depende de hotplug).

3- Una vez el kernel ha montado el root filesystem se carga el proceso init (que va incluido en busybox) que lanza un script de arranque mínimo. Este script una de las cosas que hace es montar un disco ram en /dev y crear todos los dispositivos ahí, de forma similar a como funciona udev.

3.1- El busybox que he puesto lleva casi absolutamente todos los comandos, por lo que es bastante tocho. Sobran muchos comandos que no tienen sentido en la A320 (ifconfig, adduser, por citar un par) por lo que podría adelgazar una burrada. Si además lo compilamos con la uclibc, entonces ya ni te digo. Todo eso es tiempo que se ahorraría en el arranque.

3.2- El sistema udev es uno de los mayores avances recientes en linux: proporciona un sistema de dispositivos dinámico absolutamente imprescindible para un sistema operativo moderno de escritorio o de servidor. Pero para la A320 el conjunto de dispositivos de sistema va a ser siempre el mismo, así que puede formar parte del root filesystem desde el principio. Me consta que el proceso inicial de escanear /sys e ir creando los dispositivos en /dev consume unos cientos de milisegundos que se pueden ahorrar.

4- La salida de consola por el puerto serie está activada. Esto ralentiza el arranque cuando mucho output porque el puerto serie va a 57600 baudios, el buffer es limitado, y cuando se llena los printk son bloqueantes. No se cuánto se gana si se suprime la salida por consola serie, pero se nota claramente que es más rápido (en el primer video que subí la salida por consola serie está desactivada).

< - >

Me suena que A600 encontró la manera de poner la dingoo a 8 bits; creo que lo he leído en elgun hilo, pero a ver quien lo encuentra ahora.

A mí me suena algo también, pero OJO, que podemos estar hablando de cosas distintas.

Resulta que el controlador SLCD del JZ4740 puede conectarse a un LCD "smart" con un bus de 8, 9, 16 ó 18 bits. De hecho en el archivo jz4740.h ha definiciones tipo "gpio_as_lcd 8bit" que lo que están haciendo es configurar la comunicación con el LCD por un bus de 8 bits, pero que NO TIENEN NADA QUE VER con los bits por píxel de visualización efectiva en el display, ni de cómo se traduce el contenido de la memoria a colores de píxel.

Que alguien se mire el datasheet (yo no puedo ahora) del IL9325 para ver si soporta modo de 8 BITS POR PIXEL (no de 8 bits de bus).

[chipan]

A mí me suena algo también, pero OJO, que podemos estar hablando de cosas distintas.

Resulta que el controlador SLCD del JZ4740 puede conectarse a un LCD "smart" con un bus de 8, 9, 16 ó 18 bits. De hecho en el archivo jz4740.h ha definiciones tipo "gpio_as_lcd 8bit" que lo que están haciendo es configurar la comunicación con el LCD por un bus de 8 bits, pero que NO TIENEN NADA QUE VER con los bits por píxel de visualización efectiva en el display, ni de cómo se traduce el contenido de la memoria a colores de píxel.

Que alguien se mire el datasheet (yo no puedo ahora) del IL9325 para ver si soporta modo de 8 BITS POR PIXEL (no de 8 bits de bus).

Si; eso tambien me sonaba, pero visto el comentario de A600 puede que me haya hecho la picha un lío.

[A600]

Que alguien se mire el datasheet (yo no puedo ahora) del IL9325 para ver si soporta modo de 8 BITS POR PIXEL (no de 8 bits de bus).

Por lo que he podido ver, lo más "parecido" es un modo de ahorro de energía de 8 colores pero 8 bpp parece que no lo soporta.

[otto_xd]

Que no soporte 8bpp no es un poco putada por el rendimiento de los emuladores y juegos??

Saludos

[A600]

Respecto al framebuffer, quiero hacer unas cuantas cosas importantes: examinar la "optimización" que hizo del framebuffer el que hizo el port para el onda vx747, sospecho que tendría que ver con que me da que el código de Ingenic está contínuamente enviando los datos (por DMA) a la memoria del display, en lugar de hacerlo de forma sincronizada con el refresco de éste. Esto, además de transferir muchos más datos de los necesarios (que por mucho DMA que se use siempre afecta al rendimiento global) hace que al no estar sincronizado el refresco de las imágenes se aprecien "cortes" en el barrido (no se expresarlo mejor, en inglés creo que se dice "tearing").

El tearing, por los posts que he leído, afecta más a unas Dingoos que a otras aunque yo en la mía no lo he notado en absoluto.

< - >

Que no soporte 8bpp no es un poco putada por el rendimiento de los emuladores y juegos??

Exacto.