[OFICIAL]: Scene Dingoo A320

[SinMan]

esto significa que todo lo que tenga un acceso directo al framebuffer (Vease SDL, linux o lo que sea) está mas cerca ¿no?.
Debo suponer que el linux ya arranca ¿no?

Bueno el Kernel panic! de la última linea dice que arrancar no arranca, pero también parece que el problema viene de que no puede montar el sistema de ficheros, no así de algun internal desconocido del hardware.

<-->

Por cierto booboo, aunque no tengo ni idea de electrónica ni de dispostivos móviles. Me llevo pegando con Linux desde el 98, cuando tenías que recompilarte el kernel y configurarte todo a mano cada vez que instalabas, cuando no tenia internet y dolorosamente me entere de que si no compilas el soporte de la pila TCP no tienes servidor X , así que si me pasas los ficheros ahora que funciona el LCD, porque no tengo consola serie como tu, puedo pegarme con la configuración

[Ruxy]

He visto en una entrevista de un portavoz de los que hacen la dingoo, y dice que con esto se puede programar juegos para la dingoo, asi que supongo que se podran hacer otras cosas.

Hecharle un vistazo "hache te te pe"://soft3d.org/

[booboo]

esto significa que todo lo que tenga un acceso directo al framebuffer (Vease SDL, linux o lo que sea) está mas cerca ¿no?.
Debo suponer que el linux ya arranca ¿no?

Depende de lo que entiendas por "linux". Linux es el kernel más todo el conjunto de aplicaciones que corren bajo él.

El proceso de arranque de un sistema típico es el siguiente:

1- BIOS (ROM en el caso del JZ4740). Carga el bootloader de algún sitio y le transfiere el control.
2- El bootloader es un programa mínimo cuyo único propósito es cargar el kernel de algún dispositivo de almacenamiento masivo, para lo cual requiere un mínimo "entendimiento" de cómo acceder a tal dispositivo y de dónde, dentro de éste, está el kernel.
3- El kernel: toma el control del sistema inicializando todos los dispositivos, monta un sistema de archivos desde algún dispositivo de almacenamiento masivo.
4- El kernel ejecuta /sbin/init en el sistema de archivos montado.
5- El /sbin/init lee un fichero de configuración y va lanzando los distintos ejecutables y scripts necesarios para poner todo en marcha.

(Para los puristas: hay bootloaders que pueden cargar el kernel a través de red, y es posible hacer que el kernel monte un sistema de archivos también a través de la red. También he omitido el paso intermedio del initrd por no complicarlo más)

Hasta ahora lo que tengo llega al paso 4, pero sencillamente porque:

1- No he configurado aún el kernel para reconocer la NAND flash ni la miniSD. Esto es MUY sencillo (bueno, por lo menos lo segundo) ya que (a diferencia del LCD) la A320 no tiene ninguna particularidad especial con respecto al diseño de referencia que proporciona Ingenic. Si no he hecho esto es porque mientras intentaba hacer funcionar el framebuffer estaba utilizando un kernel con casi todo deshabilitado, con el fin de minimizar la posibilidad alguna interferencia entre dispositivos.

2- No he buscado aún una distribución MIPSEL, pero la cosa es tan sencilla como elegirla y colocarla en la miniSD (aunque el que logró arrancar linux en el onda dice que tuvo problemas con el DMA simultáneo del LCD y de la miniSD... ya veremos... en todo caso puedo examinar la solución que adoptó él si se me presenta el mismo problema).

3- No está resuelto el tema del acceso desde el PC. Me explico: la A320 no tiene teclado, así que ¿cómo accedemos a la consola?. La solución es configurar el dispositivo USB como "gadget" en modo CDC, con lo cual se comporta, desde el punto de vista del PC, como un terminal serie. Para el acceso desde el PC como dispositivo de almacenamiento masivo externo se usa también el modo "gadget" pero la variante correspondiente. Todo esto está ya implementado en el kernel de linux, pero no del CDC y montar una consola con login por ahí no lo he hecho nunca, así que aún tengo que mirarlo.

Una vez tenga un sistema que arranque y que permita acceder por consola, ya estará todo lo necesario para que más genta vaya haciendo experimentos y mejorando el soporte de hardware (sin necesidad de desmontar y soldar en la consola para tener una consola serie RS232 como tengo yo).

Por cierto, el proceso de arranque "real" ahora mismo en la A320 es el siguiente:

1- Reset de la consola con el botón "B" pulsado: la ROM entra en modo de actualización de firmware, que te permite básicamente subir código y ejecutarlo en la caché de instrucciones o en la SDRAM (aunque ésta no está inicialmente accesible).

2- Usando usbtool (que es un rewrite hecho por los del onda del usb_boot para windows que proporciona Ingenic) se carga un pequeño programa en la caché de instrucciones (0x80000000-0x80003FFF) y se ejecuta. Este programa inicializa la SDRAM. Ahora ya se puede cargar lo que sea directamente en SDRAM.

3- Usando usbtool de nuevo se carga el kernel (zImage... que porcierto NO compila en el kernel que proporciona Ingenic... hay que hacer un par de "fixes") en la dirección 0x80600000 y se ejecuta.

Evidentemente todo esto requiere tener el PC conectado al lado, lo cual dado que linux aún no es usable en la A320 no creo que sea problema. Es obviamente posible meterlo todo en la NAND flash y que arranque directamente de ahí el kernel, o mejor aún, dar una opción de "dual boot" que arranque el firmware original o el kernel de linux dependiendo de el estado de un botón, pero creo que de momento eso no es prioritario, y en el caso del arranque dual es algo más complicado porque en lugar de meter en NAND un bootloader cualquiera hay que o bien "parchear" el del firmware original o bien averiguar cómo carga el firmware original y qué parámetros le pasa para emular el mismo comportamiento.

Como veis, aún hay mucho que rascar. Mi prioridad es llegar cuanto antes a un punto en el que CUALQUIERA pueda arrancar el kernel en su Dingoo y hacer experimentos... a partir de ahí el número de gente implicada debería crecer rápidamente.

< - >

Por lo que leo casca donde antes, pero ya lo muestra por pantalla, asi que galtaria toda la adaptacion a esta maquina, que no es moco de pavo.

Me encanta este hilo, me hace darme cuenta que no tengo npi de nada, pero me encanta xD

Saludos

Ya he explicado dónde y por qué casca.

Esto es lo que falta por hacer, no necesariamente en orden de importancia, y con una estimación de la dificultad:

1- Soporte miniSD: necesario para poder montar un root filesystem. Esto debería ser trivial: el kernel de Ingenic ya tiene un driver para ésto, y las únicas particularidades de la Dingoo son los pines GPIO que se usan para detectar la tarjeta insertada y para activar/desactivar la alimentación de la tarjeta. El primero ya lo sé, y el segundo aunque no sé cual és, sí que conozco el estado de los pines GPIO cuando el firmware original está usando la miniSD, así que puedo obviarlo al principio y luego una vez funcione el acceso ir cambiando el estado de los pines hasta que deje de funcionar. No obstante, tengo fundadas sospechas de que en la A320 la miniSD está siempre alimentada. No sería una buena práctica de diseño, pero no me extrañaría porque ya he visto una chapuza en la forma en que está conectado el LCD.

2- Soporte NAND flash: necesario si eventualmente se desea tener un arranque directo de linux en la consola. El soporte de la NAND flash debería ser trivial por motivos similares a los anteriores, sin embargo el cómo grabar inicialmente lo que tiene que ir en la NAND flash es algo más complicado. En todo caso, como ya he comentado, esto es casi lo último que habría que hacer.

3- Soporte teclas: también trivial. El kernel de Ingenic ya lo tiene y sólo hay que configurar los pines GPIO que ya he identificado en su totalidad (los de los botones, quiero decir).

4- Soporte encendido/apagado: Me parece que el kernel de Ingenic también tiene esto pero no acabo de tener claro cómo funciona (tanto en el kernel como el propio hardware). Dificultad media.

5- Soporte carga batería: estoy casi seguro de que de esto se encarga un chip específico. Todo lo más indicará si está cargando la batería, y quizás se pueda controlar la carga (sólo activar/desactivar) con un pin GPIO. En el kernel no hay soporte de esto porque es trivial y en todo caso debe encargarse una aplicación de usuario. Dificultad media.

6- Lectura nivel batería: si, como imagino, se usa el convertidor ADC del micro, debería ser trivial. Hay soporte del ADC en el kernel de Ingenic, y una aplicación de usuario leería el nivel.

7- Sonido: dificultad media-alta. El kernel tiene soporte alsa/oss, pero no tengo claro por qué los dos (si alsa funciona, hay una capa que emula oss sobre alsa, no tendría sentido tener los dos). Además aquí hay algunos elementos auxiliares que no tengo ni idea de momento de cómo van: control de volumen, micrófono, selección de auriculares/altavoces internos, entrada del audio de la radio, etc.

8- Radio FM: dificultad media. No hay driver específico en el kernel para este chip, pero tengo la documentación y el chip se comunica por el bus I2C para el que sí que hay soporte en el kernel. Se puede escoger entre escribir un driver de kernel que funcione sobre I2C (tengo ejemplos... creo recordar que en uCOS-II Ingenic hay algún driver para otro modelo de chip) o directamente que la aplicación de usuario que se haga para "oir la radio" comunique directamente por el bus I2C con el chip de radio. Tengo los datasheet del chip de radio, pero no he mirado si a parte del bus I2C hay algún otro pin GPIO involucrado. Es casi seguro que como mínimo habrá un pin dedicado a controlar la alimentación, y de nuevo lo descubriré cuando logre por lo menos comunicar con el chip por el bus I2C y entonces empiece a cambiar estados de pines de salida cuya función aún no he identificado (a penas 4 ó 5) hasta que deje de poder comunicar con el chip de radio. Además esta parte "conecta" con el sonido, ya que el chip de radio saca el sonido como si fuera un codec de audio (formato I2S), por lo que éste entra en la dingoo y luego "sale" por el cana de audio out, es decir, es como si el sonido de la radio entrara por el micro y se rutara directamente a la salida de audio., o en otras palabras, "grabar" y "reproducir" simultáneamente.

9- Salida TV: dificultad alta. Esto creo que va a tener mucha tela. Tengo toda la información del chip que se usa, pero no de los pines GPIO auxiliares que con seguridad se usan (para controlar la alimentación y alguna cosa más). Además, cuando la A320 pasa a modo TV el controlador LCD se cambia de modo SLCD ("smart LCD") al modo normal, y ambos drivers no son compatibles. Tengo la ventaja de que conozco el estado de todos los registros del controlador LCD y demás cuando la dingoo está en modo TV out (hice un .app con el SDK para averiguar esto). La solución más sencilla sería tener los dos drivers (SLCD y LCD normal) como módulos y descargar uno y cargar otro cuando se quiera cambiar a modo TV out, pero es que el driver SLCD por fuerza tiene que estar metido en el kernel, no puede estar como módulo porque entonces no se vería nada en el arranque porque el framebuffer no existiría. Vamos... que esta parte es (después de la del framebuffer que ya está resuelta) la más complicada y sobre la que maś información hay todavía que averiguar.

10- Gestión de energía: suspender/reanudar. En teoría el kernel ya lo soporta, pero esto suele plantear problemas.

11- Gestión del reloj: gestión de la frecuencia de trabajo de la CPU: ya está soportado en el kernel.

No se si me dejo alguna función de la dingoo... como por ejemplo el RTC (reloj en tiempo real)... si a alguien se le ocurre que lo diga.

Tampoco estoy seguro 100% de que el micrófono esté conectado a un codec de audio como tal... es posible que esté conectado al ADC o algo así.

< - >

No tengo una Dingoo ni me la pienso comprar pero, ¡Booboo, ole tus webos tío !

Pues para lo que entretiene el precio es de coña. Obviamente yo estoy mucho más "entretenido" con el kernel de linux que con los emuladores... pero bueno.

A modo de opinión personal, a mí la A320 me parece, como portable media player:

1- El LCD es un modelo pensado para orientación vertical, lo cual hace que como ya ha apuntado alguien, pierda rápidamente visibilidad si se mira desde la izquierda. A mí no me molesta en absoluto, pero creo que la elección del display ha sido un error de diseño puesto que hay displays a precios similares que no presentan este "problema" (lo pongo entre comillas porque insisto en que a mí no me molesta, y yo soy MUY maniático para estas cosas).

2- Lo que sí que me molesta es que mi LCD tiene un pixel "muerto" totalmente blanco. No se ve casi pero como he dicho soy muy maniático. Como la estoy usando para desarrollar no me importa demasiado.

3- La calidad del sonido deja algo que desear y yo (que tengo MUY buen oído) mientras escucho música con el volumen al mínimo (al irme a la cama, por ejemplo) puedo escuchar "interferencia" procedente seguramente de la comunicación digital con la miniSD. Insisto: tengo muy buen oído y sólo es con el volumen al mínimo en una situación muy particular (silencio absoluto).

< - >

Bueno el Kernel panic! de la última linea dice que arrancar no arranca, pero también parece que el problema viene de que no puede montar el sistema de ficheros, no así de algun internal desconocido del hardware.

Como ya he dicho, en ese kernel directamente estaba deshabilitado el soporte NAND flash y miniSD, además de que no había miniSD insertada y aunque la hubiera habido no tenía un root filesystem. En cuanto logré que funcionara el framebuffer posteé la foto y me fuí a dormir.

Por cierto booboo, aunque no tengo ni idea de electrónica ni de dispostivos móviles. Me llevo pegando con Linux desde el 98, cuando tenías que recompilarte el kernel y configurarte todo a mano cada vez que instalabas, cuando no tenia internet y dolorosamente me entere de que si no compilas el soporte de la pila TCP no tienes servidor X , así que si me pasas los ficheros ahora que funciona el LCD, porque no tengo consola serie como tu, puedo pegarme con la configuración

No te preocupes porque eso ya lo he hecho yo y me conozco al dedillo prácticamente todas (y son una barbaridad) las opciones de configuración del kernel.

El soporte TCP seguramente va a estar deshabilitado porque no tiene sentido que no sea así al no haber ningún dispositivo de red (y además ocupa un huevo). El linux que se meta en la maquinita tampoco llevará las X, ya que es un overhead brutal para una sola aplicación que hay que correr (que haría las funciones del firmware original, posiblemente con otro "look"). Lo más sencillo es que esta aplicación se programe directamente sobre una versión de la SDL compilada con soporte video-out sólo para framebuffer.

< - >

He visto en una entrevista de un portavoz de los que hacen la dingoo, y dice que con esto se puede programar juegos para la dingoo, asi que supongo que se podran hacer otras cosas.

Hecharle un vistazo "hache te te pe"://soft3d.org/

Eso es el SDK con el que, en efecto, se programa para la Dingoo bajo el firmware original.

Yo he utilizado eso para hacer un programita sencillo que muestra el contenido de todos los registros de los periféricos del procesador para saber cual es la configuración "funcional" que debo obtener (tipo de SDRAM, NAND flash, LCD, etc).

[SinMan]

Depende de lo que entiendas por "linux". Linux es el kernel más todo el conjunto de aplicaciones que corren bajo él.

Como se pase Stallman por aquí te corta los webs, el kernel mas todo el conjunto de aplicaciones se llama GNU/Linux, pásate por barrapunto y busca los flames al respecto

No se si me dejo alguna función de la dingoo... como por ejemplo el RTC (reloj en tiempo real)... si a alguien se le ocurre que lo diga.

Me temo que no tiene RTC, por lo que lei el SOC no lo tiene integrado y vosotros abriéndola no habéis visto ningún chip auxiliar para ello, ademas sería raro que teniéndolo no hubieran hecho una cutre-aplicación de reloj

El soporte TCP seguramente va a estar deshabilitado porque no tiene sentido que no sea así al no haber ningún dispositivo de red (y además ocupa un huevo). El linux que se meta en la maquinita tampoco llevará las X, ya que es un overhead brutal para una sola aplicación que hay que correr (que haría las funciones del firmware original, posiblemente con otro "look"). Lo más sencillo es que esta aplicación se programe directamente sobre una versión de la SDL compilada con soporte video-out sólo para framebuffer.

Ya he visto que en el FTP de Ingenic a parte del GTK para X con Tiny X, tienen un GTK-framebuffer.

Una vez mas, eres el amo

[A600]

o mejor aún, dar una opción de "dual boot" que arranque el firmware original o el kernel de linux dependiendo de el estado de un botón

Eso sería, simplemente, cojonudo

[chipan]

Molan estas respuestas tan curradas, asi me voy empapando de conocimientos muchas gracias por dejarlo todo tan claro.
Segun he podido leer, evitar el kernel panic de la foto es algo trivial... sin embargo hacer funcionar absolutamente todo el hardware puede ser una taréa titánica

[booboo]

Como se pase Stallman por aquí te corta los webs, el kernel mas todo el conjunto de aplicaciones se llama GNU/Linux, pásate por barrapunto y busca los flames al respecto

Lo sé, lo sé... no he querido afinar tanto.

Me temo que no tiene RTC, por lo que lei el SOC no lo tiene integrado y vosotros abriéndola no habéis visto ningún chip auxiliar para ello, ademas sería raro que teniéndolo no hubieran hecho una cutre-aplicación de reloj

En la página 6 del datasheet del JZ4740:

RTC (Real Time Clock)
32-bit second counter
1Hz from 32768hz
Alarm interrupt
Independent power
A 32-bits scratch register used to indicate whether power down happens for RTC power

Además en la configuración del kernel de Ingenic aparece claramente la opción RTC para la placa PAVO (diseño de referencia para PMP).

Por otra parte, aquí puedes ver claramente el cristal principal del sistema (12 MHz) que sirve de entrada al PLL que genera todos los demás relojes (CPU, periféricos, USB, etc) y a parte la típica "latita" redonda de los cristales de 32768Hz que se suelen usar para los RTC (en la foto he puesto por error 32768KHz, debería poner Hz o bien haber puesto una coma entre el 2 y el 7).

Ya he visto que en el FTP de Ingenic a parte del GTK para X con Tiny X, tienen un GTK-framebuffer.

No olvides que sólo hay 32MB de RAM, y que el kernel de linux ocupa bastante (ya procuraré adelgazarlo quitando todo lo no necesario, pero por lo menos serán 3 ó 4 MB). Cualquier aplicación que metamos ocupará más memoria, y no hay swap (se podría tener, pero no tiene sentido). Meter un gestor de ventanas y todo el conjunto de widgets de GTK no tiene sentido porque están pensados para usarse en un sistema con puntero de pantalla (ratón) y en la dingoo obviamente no hay.

Creo que lo que toca es, una vez que el kernel arranque bien y soporte todo el hardware, desarrollar una aplicación "principal" parecida a lo que muestra el firmware original, y para eso con la SDL sobre framebuffer sobra. Además tener cargada en memoria la SDL consume recursos pero serían recursos que en cualquier caso consumiría de todas formas las aplicaciones que lanzara (emuladores, players, etc).

< - >

Eso sería, simplemente, cojonudo

Por supuesto. Pero habrá que esperar porque antes viene todo lo demás.

Había pensado buscar la forma de "lanzar" el kernel como una aplicación más desde dentro del firmware original, pero eso puede dar mil problemas, ya que aunque no es una buena práctica, muchas veces los drivers inicializan los dispositivos haciendo ciertas presunciones respecto al estado inicial de los mismos (es decir, asumiendo que están como se quedan después del reset). Además, está el problema de cómo "sobreescribir" en memoria de forma "ordenada" el firmware antiguo por el nuevo, la configuración de la MMU (mapeo de memoria física a virtual) que no controlo y que no me apetece nada tener que aprender, la caché, etc. Un lío, vamos.

Por otra parte, coger el bootloader de ingenic y "parchearlo", aunque habría que hacerlo en ensamblador, es muy muy sencillo porque sólo hay que leer un registro para saber el estado de un botón y entonces cambiar el nombre del archivo que carga (ccpmp.bin) y posiblemente la dirección de carga, aunque como ccpmp.bin se carga en 0x80004000 y vmlinux (la imágen "plana" del kernel) en 0x80010000 bastaría con añadir un padding de 0x80010000 - 0x80004000 nops al principio de la imágen del kernel.

Fíjate que estamos hablando simplemente de leer una posición de memoria, examinar un bit, y si el bit tiene un determinado valor cambiar "ccpmp.bin" por "vmlinux" o cualquier otro nombre.

Por supuesto habría que añadir el archivo vmlinux en el firmware, pero eso ya sabemos que es fácil con las herramientas actualmente existentes (y que han permitido sacar firmwares alterados).

Lo único que no me gusta de este enfoque es el tener que alterar el bootloader en la flash, más que nada porque creo que está "embebido" en ccpmp.bin y por lo tanto al actualizar el firmware se sobreescribiría y habría que repetir la modificación. Me explico: creo que el proceso de actualización del firmware hace algo MUY parecido a lo que yo hago cargando el kernel de linux: primero carga uno o varios pequeños binarios que inicializan el hardware como lo haría el bootloader, y luego carga directamente en SDRAM el ccpmp.bin pasándole un parámetro que le dice que en lugar de haber sido cargado directamente de la NAND por el bootloader ha sido cargado vía USB y que debe realizar una actualización del firmware. Entonces lo que hace ya es borrar la flash, meter el bootloader, meterse a sí mismo, etc. Algo así debe ser.

< - >

Molan estas respuestas tan curradas, asi me voy empapando de conocimientos muchas gracias por dejarlo todo tan claro.
Segun he podido leer, evitar el kernel panic de la foto es algo trivial... sin embargo hacer funcionar absolutamente todo el hardware puede ser una taréa titánica

Titánica sería si además de no disponer del manual del micro (tenemos el datasheet, que no explica cómo funcionan los periféricos) no tuviéramos tampoco ejemplos de software. Pero disponemos de un kernel linux teóricamente funcional que sólamente hay que configurar o parchear con las particularidades de la A320.

Es complicado pero perfectamente factible. Además, un soporte incompleto del hardware en linux puede ser aceptable si se puede tener junto con el firmware original (ver mensajes sobre el dual boot): por ejemplo imagina que la radio FM y la salida TV no funcionan, pero tienes el SNES9X que funciona en linux: arrancas en linux y juegas con uno los mejores emuladores de SNES que hay (o eso me han dicho), con la única limitación de que no puedes oir la radio al mismo tiempo (no creo que nadie quisiera hacerlo) y de que no puedes hacerlo en la TV (qué se le va a hacer).

[Nekete]

Una preguntilla.
Aunque el LCD sea de 320x240(o 240x320 éso según cómo lo mires), podría llegar a sacar más "calidad de vídeo" al CHRONTEL metiéndole como input una resolución de 720x480 ó 720x576 que por lo que leí era su máximo.

Vamos, que si se llega a coseguir hacer funcionar el CHRONTEL podría pasársele una señal con mayor resolución y si esto haría que se viese mejor la imágen.

Muchas gracias por tu esfuerzo, espero que te diviertas trasteando

PD: Si ahora conectas la Dingoo conectada a la tele, ¿qué sale?(es mera curiosidad).

[booboo]

Una preguntilla.
Aunque el LCD sea de 320x240(o 240x320 éso según cómo lo mires), podría llegar a sacar más "calidad de vídeo" al CHRONTEL metiéndole como input una resolución de 720x480 ó 720x576 que por lo que leí era su máximo.

Vamos, que si se llega a coseguir hacer funcionar el CHRONTEL podría pasársele una señal con mayor resolución y si esto haría que se viese mejor la imágen.

Es una idea interesante que no se me había ocurrido. Como ya comenté me consta que el CH7024 (del que aún no me he mirado el datasheet) se utiliza en modo LCD normal, lo cual significa que el JZ4740 "escupe" los datos serie como si lo que hubiera al otro lado fuera un panel LCD normal. Nada impide configurar una resolución mayor, siempre que la configuración del controlador LCD del JZ4740 y del CH7024 sea coherente, y, por supuesto, esté dentro de los parámetros máximos de cada uno (el datasheet menciona 800x600 máximo en el controlador LCD del JZ4740).

Esto ciertamente podría ser una ventaja a la hora de reproducir vídeo, por ejemplo, pero me da a mí que en ese caso la A320 no daría la talla en cuanto a potencia.

En cuanto a los emuladores... bueno... en principio diría que NO se benefician en absoluto de la mayor resolución, por ejemplo, si pasas un juego con output 320x240 a 640x480 lo que tendrás es que donde antes había un píxel ahora hay cuatro que son exáctamente iguales. No ganas nada y sí que pierdes mucho tiempo moviendo el cuádruple de datos.

Hay un "pero" a la afirmación anterior: al parecer hay una librería con un nombre bastante exótico (que por eso no recuerdo) que se usa en muchos emuladores y que hace exáctamente eso, duplica el ancho y el alto de salida de vídeo, pero en lugar de limitarse a poner cuatro píxeles iguales donde sólo había uno tiene cierta inteligencia y detecta patrones de líneas y demás en los píxeles adyacentes, haciendo un antialiasing que sí que mejora el resultado final. Esta librería necesita bastante potencia, así que no procede en la A320.

Muchas gracias por tu esfuerzo, espero que te diviertas trasteando

Teta. Me lo estoy pasando teta, aunque necesariamente iré yendo más lento porque ahora, con la novedad, le estoy dedicando demasiado tiempo a esto.

Como ya he comentado, mi intención es tener algo más o menos operativo y para entonces haber publicado de forma ordenada toda la información y herramientas, para que más gente se pueda meter a ello y la cosa gane cierta inercia.

PD: Si ahora conectas la Dingoo conectada a la tele, ¿qué sale?(es mera curiosidad).

Nada. No sale nada. Para que salga algo hay que reconfigurar el controlador LCD del JZ4740 en modo LCD normal y además configurar el CH7024, y seguramente alguna cosa más del GPIO que ignoro.

[A600]

En cuanto a los emuladores... bueno... en principio diría que NO se benefician en absoluto de la mayor resolución, por ejemplo, si pasas un juego con output 320x240 a 640x480 lo que tendrás es que donde antes había un píxel ahora hay cuatro que son exáctamente iguales. No ganas nada y sí que pierdes mucho tiempo moviendo el cuádruple de datos.

A la inversa, se puede usar la función resize del ILI9320 para mostrar imágenes de 640x480 a 320x240. El método que usa es bastante chusco (pintar el primer pixel de cada cuadrante) pero todo lo que sea quitarle trabajo a la CPU, bienvenido sea. Tengo curiosidad de ver cómo quedará el Bermuda Syndrome con sus sprites no demasiado grandes en una pantalla de 2.8"

[dtagua]

booboo eres el de siempre? si es asi me has sorprendido estas hecho un crack

[chipan]

Hay un "pero" a la afirmación anterior: al parecer hay una librería con un nombre bastante exótico (que por eso no recuerdo) que se usa en muchos emuladores y que hace exáctamente eso, duplica el ancho y el alto de salida de vídeo, pero en lugar de limitarse a poner cuatro píxeles iguales donde sólo había uno tiene cierta inteligencia y detecta patrones de líneas y demás en los píxeles adyacentes, haciendo un antialiasing que sí que mejora el resultado final. Esta librería necesita bastante potencia, así que no procede en la A320.

Creo que estas hablando del Super Sidekic... nah! olvidalo, broma interna del foro.
Creo que estas hablando de los scalers de Kreed; el 2xsai, el Super 2xsai, el Super Eagle y derivados (scalers tremendamente extendidos).
¡Veis! yo tambien aporto.

[dj syto]

booboo eres el de siempre? si es asi me has sorprendido estas hecho un crack

creo que lo estas confundiendo con otro.... xd

[chipan]

creo que lo estas confundiendo con otro.... xd

Ostrás, no caía hasta que lo has dicho...

Spoiler: Ver

gasancoooooooooo

[booboo]

booboo eres el de siempre? si es asi me has sorprendido estas hecho un crack

No, no creo. No había participado en este foro nunca antes.

Volviendo a la A320, acabo de configurar y compilar el soporte miniSD y ya funciona. También he puesto un root filesystem mínimo para tener un login y evitar el feo "kernel panic".

Arranca tan rápido porque lo que está pasando es lo siguiente:

1- Usando usbtool se carga el .bin minúsculo que inicializa el hardware.
2- Usando usbtool se carga una imágen del kernel con un initrd empotrado que actúa como root filesystem.

En el momento en que se lanza el kernel, la inicialización es muy rápida y encima cuando ejecuta /sbin/init lo está haciendo de un disco RAM, y ese /sbin/init es el busybox compilado estáticamente para mipsel.

[media]http://www.youtube.com/watch?v=3YyINLtEdR0[/media]

Uncompressing Linux...Ok, booting the kernel.Linux version 2.6.24.3-a320 (booboo@inspiron) (gcc version 4.1.2) #69 PREEMPT Thu May 7 03:27:19 CEST 2009
CPU revision is: 0ad0024f (Ingenic JZRISC)
CPU clock: 336MHz, System clock: 84MHz, Peripheral clock: 84MHz, Memory clock: 84MHz
JZ4740 PAVO board setup
Determined physical RAM map:
 memory: 04000000 @ 00000000 (usable)
User-defined physical RAM map:
 memory: 02000000 @ 00000000 (usable)
Initrd not found or empty - disabling initrd
Zone PFN ranges:
  Normal          0 ->     8192
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->     8192
Built 1 zonelists in Zone order, mobility grouping off.  Total pages: 8128
Kernel command line: mem=32M console=ttyS0,57600n8
Primary instruction cache 16kB, VIPT, 4-way, linesize 32 bytes.
Primary data cache 16kB, 4-way, VIPT, no aliases, linesize 32 bytes
Synthesized clear page handler (25 instructions).
Synthesized copy page handler (44 instructions).
Synthesized TLB refill handler (20 instructions).
Synthesized TLB load handler fastpath (32 instructions).
Synthesized TLB store handler fastpath (32 instructions).
Synthesized TLB modify handler fastpath (31 instructions).
PID hash table entries: 128 (order: 7, 512 bytes)
Console: colour dummy device 80x25
console [ttyS0] enabled
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 28552k/32768k available (1987k kernel code, 4216k reserved, 476k data, 1172k init, 0k highmem)
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
Time: jz_clocksource clocksource has been installed.
Total 4MB memory at 0x400000 was reserved for IPU
yaffs May  7 2009 02:22:41 Installing. 
io scheduler noop registered
io scheduler deadline registered (default)
Serial: 8250/16550 driver $Revision: 1.5 $ 2 ports, IRQ sharing disabled
7•É¥…±á250: ttyS0 at MMIO 0x0 (irq = 9) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 8) is a 16550A
loop: module loaded
Nand DMA request channel 0.
NAND device: Manufacturer ID: 0xec, Chip ID: 0xd7 (Samsung NAND 4GiB 3,3V 8-bit) planenum:4
Nand using two-plane mode, and resized to writesize:8192 oobsize:256 blocksize:0x100000 
Scanning device for bad blocks
Bad eraseblock 5 at 0x0002ff000
Bad eraseblock 6 at 0x00037f000
Bad eraseblock 7 at 0x0003ff000
Bad eraseblock 8 at 0x00047f000
Bad eraseblock 10 at 0x00057f000
Bad eraseblock 11 at 0x0005ff000
Bad eraseblock 12 at 0x00067f000
Bad eraseblock 13 at 0x0006ff000
Bad eraseblock 14 at 0x00077f000
Bad eraseblock 16 at 0x00087f000
Bad eraseblock 17 at 0x0008ff000
Bad eraseblock 19 at 0x0009ff000
Bad eraseblock 20 at 0x000a7f000
Bad eraseblock 21 at 0x000aff000
Bad eraseblock 22 at 0x000b7f000
Bad eraseblock 23 at 0x000bff000
Bad eraseblock 24 at 0x000c7f000
Bad eraseblock 25 at 0x000cff000
Bad eraseblock 26 at 0x000d7f000
Bad eraseblock 27 at 0x000dff000
Bad eraseblock 30 at 0x000f7f000
Bad eraseblock 31 at 0x000fff000
Bad eraseblock 32 at 0x00107f000
Bad eraseblock 33 at 0x0010ff000
Bad eraseblock 34 at 0x00117f000
Bad eraseblock 35 at 0x0011ff000
Bad eraseblock 36 at 0x00127f000
Bad eraseblock 37 at 0x0012ff000
Bad eraseblock 38 at 0x00137f000
Bad eraseblock 39 at 0x0013ff000
Bad eraseblock 40 at 0x00147f000
Bad eraseblock 41 at 0x0014ff000
Bad eraseblock 43 at 0x0015ff000
Bad eraseblock 44 at 0x00167f000
Bad eraseblock 47 at 0x0017ff000
Bad eraseblock 48 at 0x00187f000
Bad eraseblock 49 at 0x0018ff000
Bad eraseblock 50 at 0x00197f000
Bad eraseblock 53 at 0x001aff000
Bad eraseblock 54 at 0x001b7f000
Bad eraseblock 55 at 0x001bff000
Bad eraseblock 56 at 0x001c7f000
Bad eraseblock 58 at 0x001d7f000
Bad eraseblock 59 at 0x001dff000
Bad eraseblock 64 at 0x00207f000
Bad eraseblock 65 at 0x0020ff000
Bad eraseblock 66 at 0x00217f000
Bad eraseblock 67 at 0x0021ff000
Bad eraseblock 68 at 0x00227f000
Bad eraseblock 70 at 0x00237f000
Bad eraseblock 73 at 0x0024ff000
Bad eraseblock 76 at 0x00267f000
Bad eraseblock 77 at 0x0026ff000
Bad eraseblock 80 at 0x00287f000
Bad eraseblock 81 at 0x0028ff000
Bad eraseblock 84 at 0x002a7f000
Bad eraseblock 85 at 0x002aff000
Bad eraseblock 86 at 0x002b7f000
Bad eraseblock 87 at 0x002bff000
Bad eraseblock 88 at 0x002c7f000
Bad eraseblock 91 at 0x002dff000
Bad eraseblock 92 at 0x002e7f000
Bad eraseblock 93 at 0x002eff000
Bad eraseblock 94 at 0x002f7f000
Bad eraseblock 95 at 0x002fff000
Bad eraseblock 96 at 0x00307f000
Bad eraseblock 98 at 0x00317f000
Bad eraseblock 99 at 0x0031ff000
Bad eraseblock 100 at 0x00327f000
Bad eraseblock 101 at 0x0032ff000
Bad eraseblock 102 at 0x00337f000
Bad eraseblock 104 at 0x00347f000
Bad eraseblock 105 at 0x0034ff000
Bad eraseblock 106 at 0x00357f000
Bad eraseblock 108 at 0x00367f000
Bad eraseblock 110 at 0x00377f000
Bad eraseblock 111 at 0x0037ff000
Bad eraseblock 112 at 0x00387f000
Bad eraseblock 113 at 0x0038ff000
Bad eraseblock 114 at 0x00397f000
Bad eraseblock 116 at 0x003a7f000
Bad eraseblock 117 at 0x003aff000
Bad eraseblock 118 at 0x003b7f000
Bad eraseblock 119 at 0x003bff000
Bad eraseblock 120 at 0x003c7f000
Bad eraseblock 121 at 0x003cff000
Bad eraseblock 122 at 0x003d7f000
Bad eraseblock 123 at 0x003dff000
Bad eraseblock 124 at 0x003e7f000
Bad eraseblock 125 at 0x003eff000
Bad eraseblock 127 at 0x003fff000
Bad eraseblock 128 at 0x00407f000
Bad eraseblock 129 at 0x0040ff000
Bad eraseblock 130 at 0x00417f000
Bad eraseblock 131 at 0x0041ff000
Bad eraseblock 132 at 0x00427f000
Bad eraseblock 133 at 0x0042ff000
Bad eraseblock 134 at 0x00437f000
Bad eraseblock 136 at 0x00447f000
Bad eraseblock 137 at 0x0044ff000
Bad eraseblock 138 at 0x00457f000
Bad eraseblock 139 at 0x0045ff000
Bad eraseblock 140 at 0x00467f000
Bad eraseblock 207 at 0x0067ff000
Bad eraseblock 208 at 0x00687f000
Bad eraseblock 209 at 0x0068ff000
Bad eraseblock 4096 at 0x08007f000
Bad eraseblock 4097 at 0x0800ff000
Bad eraseblock 4098 at 0x08017f000
Bad eraseblock 4099 at 0x0801ff000
Bad eraseblock 4100 at 0x08027f000
Bad eraseblock 4101 at 0x0802ff000
Bad eraseblock 4103 at 0x0803ff000
Bad eraseblock 4129 at 0x0810ff000
Bad eraseblock 4239 at 0x0847ff000
Bad eraseblock 4240 at 0x08487f000
Bad eraseblock 4267 at 0x0855ff000
Creating 6 MTD partitions on "NAND 4GiB 3,3V 8-bit":
0x000000000-0x000400000 : "NAND BOOT partition"
0x000400000-0x000800000 : "NAND KERNEL partition"
0x000800000-0x008000000 : "NAND ROOTFS partition"
0x008000000-0x010000000 : "NAND DATA1 partition"
0x010000000-0x020000000 : "NAND DATA2 partition"
0x020000000-0x040000000 : "NAND VFAT partition"
JZ SD/MMC card driver registered
mmc0: new high speed SD card at address b368
Freeing unused kernel memory: 1172k freed
mmcblk0: mmc0:b368  1948672KiB 
 mmcblk0: p1
Algorithmics/MIPS FPU Emulator v1.5
init started: BusyBox v1.13.4 (2009-05-06 23:51:16 CEST)
starting pid 108, tty '': '/etc/init.d/rcS'
========== Mounting /proc and /sys filesystems 
========== Initializing device infrastructure 
kernel.hotplug = /sbin/mdev
========== Loading modules 
========== Populating /dev/shm 
========== Mounting other core filesystems 
========== Setting up system parameters 
sysctl: /etc/sysctl.
(none) login: root
login[129]: root login on 'ttyS0'
~ # ls -la /dev/mmc*
brw-rw----    1 root     root     179,   0 Jan  1 00:00 /dev/mmcblk0
brw-rw----    1 root     root     179,   1 Jan  1 00:00 /dev/mmcblk0p1
~ # mkdir /mnt/flash
~ # mount /dev/mmcblk0p1 /mnt/flash
~ # ls -la /mnt/flash/
drwxr-xr-x   14 root     root         4096 Jan  1 00:00 .
drwxr-xr-x    7 root     root            0 Jan  1 00:00 ..
-rwxr-xr-x    1 root     root    735819776 Jan 22  2009 akira.avi
drwxr-xr-x    5 root     root         4096 Apr 27  2009 audiob~1
drwxr-xr-x    3 root     root         4096 Jan 14  2009 data
drwxr-xr-x    4 root     root         4096 Apr 27  2009 images
drwxr-xr-x    3 root     root         4096 Jan 14  2009 lifeblog
drwxr-xr-x    6 root     root         4096 Apr 27  2009 music
drwxr-xr-x    2 root     root         4096 Feb 10  2009 others
dr-xr-xr-x    2 root     root         4096 Jan 14  2009 pb
drwxr-xr-x    2 root     root         4096 Jan 14  2009 playli~1
drwxr-xr-x    4 root     root         4096 Jan 14  2009 private
-rwxr-xr-x    1 root     root       213872 May  3  2009 reg.app
drwxr-xr-x    4 root     root         4096 Feb 10  2009 sounds
drwxr-xr-x    4 root     root         4096 Jan 14  2009 system
-rwxr-xr-x    1 root     root       212624 Jan  1  1980 target.app
drwxr-xr-x    3 root     root         4096 Apr 27  2009 videos