Ver la versión completa : [OFICIAL]: Scene Dingoo A320
Esto viene de aquí (http://www.gp32spain.com/foros/showthread.php?t=56469&page=47).
Creo que ya va siendo hora de dedicarle un hilo exclusivo a la scene de la Dingoo para que posteeis vuestros avances, aplicaciones, emuladores, juegos y cualquier cosa que vayais programando :)
Para empezar, la aplicación para resucitar la A320 (http://www.megaupload.com/?d=2V2X65SR) (gracias a A600 por postearlo)
El SDK se puede descargar aquí (http://x11.gp2x.de/a320/)
-- Instalación
Descomprimir 20091214224673499.rar en c:, crear el directorio c:\s2dsdk y descomprimir ahí los subdirectorios inc y lib del 200811281249773499.rar. Ejecutar el c:\cygwin\cygwin.reg y editar el cygwin.bat con lo siguiente:
SET MIPSLIB=c:/cygwin/mipseltools/lib
SET MIPSTOOLS=c:/cygwin/mipseltools/include
SET S2DINC=c:/s2dsdk/inc
SET S2DLIB=c:/s2dsdk/lib
PATH=c:\cygwin\mipseltools\bin;c:\cygwin\bin;C:\WI NDOWS\SYSTEM32;
Abrir una ventana de DOS, ejecutar el cygwin.bat y ya se pueden compilar los ejemplos con build.bat
-- FTP Ingenic
Todos los ficheros se pueden descargar desde megaupload
Parte1 (http://www.megaupload.com/?d=JMEHCKGP)
Parte2 (http://www.megaupload.com/?d=4F94ECV0)
El código fuente que nos interesa está en 3sw\02rtos\01uCOS\ucosii_0430.rar
-- Ingenic Media Extension Instruction Set (MXU)
Instrucciones de la CPU de Ingenic para mover, sumar, restar, etc con su equivalente en C
jz_mxu.h (http://pastebin.com/f442c9e6e)
-- Programa para desempaquetar y empaquetar el firmware
Click! (http://www.mediafire.com/download.php?mwwjmd0nmnj)
-- Código fuente de apps/emus
A320speed (http://www.mediafire.com/download.php?zzz2tchnzzm)
Centipede by Seagal (http://www.mediafire.com/download.php?umket2qzyud)
-- Tips and tricks
- Por defecto el LCD se inicializa a 16 bpp, para cambiarlo usamos __lcd_set_bpp(n) (untested)
/* n=1,2,4,8,16 */
#define __lcd_set_bpp(n) \
( REG_LCD_CTRL = (REG_LCD_CTRL & ~LCD_CTRL_BPP_MASK) | LCD_CTRL_BPP_##n )
- Escribimos en el buffer de sonido con pcm_write (ucosii\jz4740\drv\codec\i2s_jz4740.c) y cambiamos el formato, sample rate, volumen, número de canales, etc con pcm_ioctl (untested)
pcm_ioctl(PCM_SET_SAMPLE_RATE, 44100); //48000,44100
pcm_ioctl(PCM_SET_FORMAT, AFMT_S16_LE);
pcm_ioctl(PCM_SET_CHANNEL, 1);
pcm_ioctl(PCM_SET_VOL, 100); /* 100% */
int pcm_write(char *buffer, int count)
Hay un ejemplo en ucosii\audio\wave\vplay.c
- La velocidad del micro se cambia con sys_pll_init(n);
- La dirección del framebuffer la obtenemos con lcd_get_frame (untested) y el estado de la cruceta/botones con kbd_get_status (untested)
Aquí pongo la utilidad Burn Tool / Recovery Tool para recuperar / desbrickear una Dingoo A320 mal flasheada, traducida casi completamente al inglés, unicamente quedan sin traducir algunos mensajes de salida al hacer el Burn del Firmware, por dificultad de traducirlos incluso con un editor hexa (debido a la codificación ininteligible de los caracteres chinos que se encuentran harcodeados en la propia aplicación), si tuviera el código fuente otro gallo cantaría, pero siendo el programa de Chinachips no creo lo suelten :D
http://img186.imageshack.us/img186/9610/unbricker01.th.jpg (http://img186.imageshack.us/img186/9610/unbricker01.jpg)
Descarga: Recovery Tool [English]
(http://www.megaupload.com/?d=8URR223O)
En el paquete incluyo la aplicación traducida al inglés, el DOC que le enviaron a A600 con las instrucciones en inglés, el DL para la Dingoo A-320 y los drivers para Windows XP/Vista, a parte de un archivo con la suma MD5 del contenido para verificación. Para usarlo se necesita además del archivo HXF de firmware de la Dingoo A320, si lo teneis del anterior paquete o bajado de la web de Dingoo bien, si no lo teneis se puede descargar de aqui:
Descarga: Firmware 1.03 (http://www.dingoo888.com/manage/download/A320-V1.03.rar)
Unicamente se necesita el DL (System DL Config) y el HXF (Firmware) para hacer el flasheo / unbrick (Burning System) pero tened en cuenta que despues del unbrick se borra todo ya que antes del flasheo del firmware la utilidad formatea la NAND (por si acaso, antes de realizarlo, extraed la MiniSD, si es que teneis alguna introducida), eso incluye a los emuladores incluidos de serie, pero podeis bajarlos de la web de Dingoo (zona de Descargas (http://www.dingoo888.com/service.asp?classid=4)) extraer el contenido y copiarlos todos los archivos dentro del directorio GAME de la NAND de la Dingoo.
Descarga: Emuladores Dingoo A320 (http://www.dingoo888.com/manage/download/20090327190712.rar)
Recordad escanearlo con un antivirus antes de ejecutarlo en Windows y tened en cuenta que al ser una modificación del programa original y no uno propio no hay garantias, ni de que funcione correctamente ni que pueda o no causar algún fallo, así que si lo vais a usar hacedlo solo bajo vuestra propia responsabilidad :)
_Seagal_
07/04/2009, 10:53
Os dejo aqui los codigos fuentes actualizados del miniemulador del centipede.
Por ahora, y como estoy haciendo pruebas constantemente, tengo los codigos fuentes del millipede y el centipede por separado.
http://www.mediafire.com/?sharekey=bb039bfdede2cd9c8ef1259ff1b60e816252a174 7da20095ce018c8114394287
para poder compilar el emu del centipede hay que modificar el fichero 's2dbase_audio.h' de las librerias sd2 y poner a publicas estas variables privadas:
//### data members:
private:
// audio frequency
s32 m_iFrequency;
// audio buffer size
s32 m_iSize;
// audio length
s32 m_iLength;
// audio buffer
s16* m_pBuffer;
};
con cambiar el 'private' de ahí arriba por 'public' es suficiente.
ATENCIÓN !!
Estas modificaciones como cualquier otra del firmware puede enladrillar tu dingoo, así que ten bien claro lo que haces y si eres capaz de solucionarlo.
Modificar velocidad CPU
Original de zhnqw de los foros de a320home (http://www.a320home.cn/read.php?tid=5&fpage=2) para modificar la velocidad por defecto del micro en el firmware.
Tenemos que abrir el HXF de actualización del firmware con un editor exadecimal y buscar la cadena "030005240614043C00F48434", por defecto funciona a 336Mhz y podemos cambiarlo usando los siguientes valores:
336Mhz=0614 043C 00F4
366Mhz=D015 043C 80B7
380Mhz=F216 043C 40A2
400Mhz=D717 043C 0084
420Mhz=0819 043C 00B1
< - >
Modificar Firmware
Primero descargar la aplicación (http://www.mediafire.com/download.php?mgx2nt2v2n2) AdvanceTool2.
Descomprimimos el rar y ejecutamos el programa.
http://img12.imageshack.us/img12/2738/advancetoo l.jpg
El Botón marcado como ( 1 ) es para seleccionar el archivo HXF del firmware, una vez seleccionado nos creará una carpeta llamada "out_hxf"
Copiamos o renombramos la carpeta a otra llamama "in_hxf"
Hacemos las modificaciones que creamos necesarias al contenido de la carpeta si sabemos lo que hacemos.
Y presionamos el boton marcado como ( 2 ) que nos pedira un nombre para crear el HXF resultante, recuerda que para actualizar desde la dingoo el nombre tiene que ser "a320.HXF".
Información sobre los archivos y carpetas.
ccpmp.bin: Supongo que es el programa principal del firmware.
codecs: Drivers para la reproducción multimedia.
game: Recursos gráficos de algunos de los juegos que nuestro caso no se usan.
ivres: ????
system:
*code: Emulador de GBA, reproductor Flash, y mas ficheros de los juegos esos que no usamos.
*fon: Fuentes bmf, visor y creador de fuentes junto con el src aquí (http://www.mediafire.com/download.php?m3uywen2zmz)
*nls: Idiomas
*res: Skins e imagenes usadas por el firmware, con restos de programas o funciones que no usamos y que pueden ser eliminadas.
user_data: Archivos de configuración.
He estado haciendo algunas pruebas tratando de modificar el framebuffer con _lcd_get_frame pero sin resultado :( Sólo cuando salgo del programa aparece durante un instante la pantalla cambiada así que algo falla (slcdtest.c)
frame = _lcd_get_frame();
while (1) {
for (i = 0;i < 320 * 240;i++) {
frame[i] = 0xf81f;
}
__dcache_writeback_all();
while (REG_SLCD_STATE & SLCD_STATE_BUSY);
__dmac_channel_set_doorbell(dma_chan);
mdelay(100);
mdelay(2000);
for (i = 0;i < 320 * 240;i++) {
frame[i] = 0x07e0;
}
__dcache_writeback_all();
mdelay(2000);
for (i = 0;i < 320 * 240;i++) {
frame[i] = 0x00ff;
}
__dcache_writeback_all();
while (REG_SLCD_STATE & SLCD_STATE_BUSY);
__dmac_channel_set_doorbell(dma_chan);
mdelay(100);
mdelay(2000);
for(i = 0;i < 320 * 240;i++)
{
frame[i] = 0xffe0;
}
__dcache_writeback_all();
while (REG_SLCD_STATE & SLCD_STATE_BUSY);
__dmac_channel_set_doorbell(dma_chan);
printf("REG_DMAC_DMADBR = 0x%08x\n", REG_DMAC_DMADBR);
mdelay(2000);
keyVal = _kbd_get_key();
if (keyVal == 0x00000800){
return -1;
}
Por lo menos he conseguido poner el LCD a 8bpp con
REG_SLCD_CFG &= ~SLCD_CFG_DWIDTH_MASK;
REG_SLCD_CFG |= SLCD_CFG_DWIDTH_8_x1;
así que en teoría se podría mejorar dramáticamente el rendimiento de los emus usando 8bpp en vez de 16bpp
Y estos son los valores de todos los botones:
0x80000000 (A)
0x00200000 (B)
0x00000040 (Y)
0x00010000 (X)
0x08000000 (Down)
0x10000000 (Left)
0x00100000 (Up)
0x00040000 (Right)
0x00000100 (LS)
0x20000000 (RS)
0x00000400 (Select)
0x00000800 (Start)
0x00000080 (Power)
Rivroner
10/04/2009, 17:35
A ver si alguien se anima a hacer un port del Pituka de la GP32 o del Caprice de la GP2X y me la compro :D
El pituka en la GP32 a 164 mhz tira de lujo la verdad :)
A ver si alguien se anima a hacer un port del Pituka de la GP32 o del Caprice de la GP2X y me la compro :D
jzPituka es el único emu que quiero en la Dingoo :)
<---->
Por fin he conseguido pintar el LCD [wei4] Es tan sencillo como ejecutar _lcd_set_frame(); cada vez que queramos actualizar el LCD.
unsigned short *frame;
frame = _lcd_get_frame();
for(i = 0;i < 320 * 240 / 3;i++)
{
frame[i] = 0xf800;
}
for(;i < 320 * 240 / 3 * 2;i++)
{
frame[i] = 0x07e0;
}
for(;i < 320 * 240 / 3 * 3;i++)
{
frame[i] = 0x001f;
}
_lcd_set_frame();
Rivroner
10/04/2009, 18:57
¿Y cuando lo portas :quepalmo:?
jzPituka es el único emu que quiero en la Dingoo :)
<---->
Por fin he conseguido pintar el LCD [wei4] Es tan sencillo como ejecutar _lcd_set_frame(); cada vez que queramos actualizar el LCD.
unsigned short *frame;
frame = _lcd_get_frame();
for(i = 0;i < 320 * 240 / 3;i++)
{
frame[i] = 0xf800;
}
for(;i < 320 * 240 / 3 * 2;i++)
{
frame[i] = 0x07e0;
}
for(;i < 320 * 240 / 3 * 3;i++)
{
frame[i] = 0x001f;
}
_lcd_set_frame();
Probablemente use un double buffer interno o algo asi, de manera que el get_frame devuelve el que no se esta viendo.
Estas funciones me estan devolviendo las ganas de intentar el SDL port...
Estas funciones me estan devolviendo las ganas de intentar el SDL port...
Yo y millones de devs a lo largo del mundo mundial te estaríamos eternamente agradecidos :)
@A600, te llaman: http://dingoo-scene.blogspot.com/2009/04/a600-would-you-answer-some-questions.html xDDD
Hey, nos mencionan aquí también :)
If you’re a developer for Dingoo, this is the place to be
The Spanish GP2x forum appears to be where hard core coders for the A320 hang, including Seagal and A600! Click here for a Babelfish translation. You can also find the source code for Seagal’s Millipede emulator, and A600’s overclocking utility there, among other things.
Cada vez que leo mas cosas de la consola, me entran mas ganas de pillarla xD
Hola, estoy buscando info sobre el SO, y parece ser que es gratuito si no es con fines comerciales, es decir que se puede descargar para modificarlo uno mismo, el problema es que habría que portarlo a la dingoo y no se si sería mejor invertir el esfuerzo en portar el rockbox.
Como nuevo usuario de la Dingoo (esta ya en Spain pero tardara unos dias en llegarme), quisiera aportar algo al conocimiento de este foro, sobre todo en la parte de desarrollo. Espero poder ayudar en la programación para este aparato.
En el blog.tipesoft.co m podeis descargar las fuentes de unos primeros ejemplos con las SDK comentados para ayudar a su entendimiento (los he añadido para entender como se usan y no me ha resultado especialmente dificil).
Bueno espero que me ayudeis en lo posible en la creación de un primer juego sencillo. Ya habrá tiempo para alguno más complejo.
< - >
Siento lo de la dirección del blog, pero al ser nuevo no me deja postear links
Alguien mas que se une a la scene, lo encontre un un post de EOL:
http://blog.tipesoft.com/
Edito, vaya no había visto que ya lo has puesto aquí, pues ya de paso pongo tu link ;)
Como nuevo usuario de la Dingoo (esta ya en Spain pero tardara unos dias en llegarme), quisiera aportar algo al conocimiento de este foro, sobre todo en la parte de desarrollo. Espero poder ayudar en la programación para este aparato. Bienvenido jorgehj :brindis:
Un blog interesante y una buena iniciativa :)
Por cierto, hacía mucho tiempo que no escuchaba hablar del Velázquez Visual (ni sabía que se iba a llamar Velneo y que se van a basar en QT), aunque el tema del desarrollo de aplicaciones en Windows con tecnologías de Microsoft como .NET nunca ha sido de mi interes tu blog tiene buena pinta :D
Lo de Velneo es una pasada, están realizado un magnifico port de Velazquez Visual con las QT que compro Nokia. El resultado es que no tardando mucho podremos ejecutar nuestas aplicaciones de gestión en dispositivos nokia (Te haces una idea viendo en youtube un video al respecto).
MS y .NET es con lo que nos ganamos la vida (por el momento), Velneo es el futuro de las aplicaciones de gestión (no lo dudo)... C y C++ un amigo olvidado...
El blog lleva poco tiempo montado (unos tres meses), la verdad que WordPress es un lujo. Estamos montando la tienda de comercio electrónico y el resultado es bueno. Dentro de unos cuantos meses empezaremos a comercializar los primeros productos para la nube realizados en Velneo.
NOVEDADES
- Emulador de PC Engine (http://a320.freeforums.org/download/file.php?id=4&sid=0763f9e1e4e96c767d6ab3e12ade12dc): Procede de la Gemei pero funciona...más o menos.
Instalación:
1. Copiar la carpeta PCROMS dentro de /GAME, en nuestra Dingoo
2. Copiar nuestros ROMS de PC Engine sin comprimir dentro de esta carpeta.
3. Editar el archivo Pceroms.txt incluyendo el nombre y extensión de todos los roms que hayamos metido. Al ejecutar el emulador sólo aparecerán listados los juegos que hayamos puesto en este documento.
4. Ejecutar el emulador neco760.app desde "3D Games".
- Emulador de Neo-Geo Pocket (http://www.mediafire.com/?umiyntd3r5g): Al igual que el anterior, procede de la Gemei.
- Yi-Chi King Fighter: (http://www.gadgetmiser.com/dingoo/Yi-chi%20King%20fighter.rar) Shot'em-up de bastante calidad.
Supongo que en la gemei el de pc engine tira mejor no? He probado con otras roms aparte de la que viene y no me tira ninguna :S
El king fighter ese tambien es de la gemei? Va de pm!
que el ritmo no pare! :D
digo yo que si arrancan, funcionaran igual de rendimiento en la gemei ke en la dingoo no?
pues entonces va en ambas a pedales y cuesta arriba xDDD
Es que no tiene ninguna opción de configuración (a lo mejor con FS podría ser algo jugable), es muy poco compatible y va a pedales como digo. Bueno, ya lo habrás probado. Por eso preguntaba, no se si es un emu que se portó como curiosidad a la gemei o ya venía en ella.
MÁS COSILLAS:
"Nuevo" juego de acción en 3D: World Road (http://www.mediafire.com/download.php?emh3ntnzdgn), del estilo Knights of the Round. Debe provenir directamente de la Gemei por que hay cosas que no funcionan bien (no se pueden cambiar las opciones ni el idioma, que por defecto viene en chino) aunque es totalmente jugable y va muy bien.
MÁS COSILLAS:
"Nuevo" juego de acción en 3D: World Road (http://www.mediafire.com/download.php?emh3ntnzdgn), del estilo Knights of the Round. Debe provenir directamente de la Gemei por que hay cosas que no funcionan bien (no se pueden cambiar las opciones ni el idioma, que por defecto viene en chino) aunque es totalmente jugable y va muy bien.
http://img76.imageshack.us/img76/3486/linkv.jpg????
(mensaje eliminado, foro equivocado, disculpen las molestias)
http://img76.imageshack.us/img76/3486/linkv.jpg????
No se parece en nada al Zelda si es lo que insinuas :D, es más del estilo The Legend Of Silkroad pero en 3D y con un sólo personaje seleccionable.
Hola, estoy buscando info sobre el SO, y parece ser que es gratuito si no es con fines comerciales, es decir que se puede descargar para modificarlo uno mismo, el problema es que habría que portarlo a la dingoo y no se si sería mejor invertir el esfuerzo en portar el rockbox.
Definitivamente mejor portar rockbox.
En el FTP de Ingenic hay un port de uCOS-II para el JZ4740, así que no debería ser muy complicado. Sin embargo, también hay un port de linux, así que es, por lo menos, IGUAL de complicado. Puestos a invertir esfuerzo, mejor hacerlo con linux, ya que hay mucho más desarrolladores y software que para uCOS-II. El kernel de linux seguro que ocupa más RAM que el de uCOS-II, pero con 32M totales no creo que la diferencia sea significativa.
Yo ya tengo los datasheet de todos los integrados de la dingoo, a excepción de la gestión de energía (conversión y carga de batería). Lo único que se necesita es eso, la información del LCD y la configuración GPIO de la CPU. Esto último se puede averiguar mediante ingeniería inversa, y el controlador de LCD sospecho que es un ILI9325, más que nada por el nombre del archivo (y cadenas de texto en el interior) que viene con la aplicación de unbricking.
No se parece en nada al Zelda si es lo que insinuas :D, es más del estilo The Legend Of Silkroad pero en 3D y con un sólo personaje seleccionable.
No hombre! que te estaba pidiendo un link XDDDDD
No hombre! que te estaba pidiendo un link XDDDDD
Joer, no me he enterao :). Ya tienes el link de descarga, mira bien...
Yo ya tengo los datasheet de todos los integrados de la dingoo, a excepción de la gestión de energía (conversión y carga de batería). Lo único que se necesita es eso, la información del LCD y la configuración GPIO de la CPU. Esto último se puede averiguar mediante ingeniería inversa, y el controlador de LCD sospecho que es un ILI9325, más que nada por el nombre del archivo (y cadenas de texto en el interior) que viene con la aplicación de unbricking.
Bien pensado, booboo. No se me había ocurrido mirar lo del ILI9325.
En el SVN de rockbox hay una aplicación para analizar los DL:
HOW TO disassemble (Ex: VX767_V1.0.dl)
STEP 1:
./dl_analyser VX767_V1.0.dl
=======================HEADER=====================
File magic: CCDL
File Type : 0x00010000
Offset : 0x00020001
Size : 0x00000004
BuildDate : 2008/03/26 09:59:19
PaddindSum: 0x0
=====================IMPT HEADER==================
Header magic : IMPT
Header Type : 0x00000008
Offset : 0x000000a0
Size : 0x0000007c
PaddindSum : 0x0
=====================EXPT HEADER==================
Header magic : EXPT
Header Type : 0x00000009
Offset : 0x00000120
Size : 0x00000108
PaddindSum : 0x0
=====================RAWD HEADER==================
Header magic : RAWD
Header Type : 0x00000001
Offset : 0x00000230
Size : 0x000058a0
Paddind1 : 0x0
BSS Clear Code : 0x80f82714 start at file 0x2944
mem_place_start : 0x80f80000 start at file 0x230
memsize : 0x5a58
mem_end(BSS end): 0x80f85a58
Paddind2Sum : 0x0
=====================IMPORT SYMBOL==================
number symbols : 0x4
PaddindSum : 0x0
Sym[00] offset 0x0000 padding 0x0 flag 0x20000 address 0x80f82750 name: printf
Sym[01] offset 0x0008 padding 0x0 flag 0x20000 address 0x80f82758 name: udelay
Sym[02] offset 0x0010 padding 0x0 flag 0x20000 address 0x80f82760 name: delay_ms
Sym[03] offset 0x001c padding 0x0 flag 0x20000 address 0x80f82768 name: get_rgb_lcd_buf
=====================EXPORT SYMBOL==================
number symbols : 0x7
PaddindSum : 0x0
Sym[00] offset 0x0000 padding 0x0 flag 0x20000 address 0x80f826dc name: init_lcd_register
Sym[01] offset 0x0014 padding 0x0 flag 0x20000 address 0x80f80160 name: get_ccpmp_config
Sym[02] offset 0x0028 padding 0x0 flag 0x20000 address 0x80f82690 name: get_bklight_config
Sym[03] offset 0x003c padding 0x0 flag 0x20000 address 0x80f81120 name: init_lcd_gpio
Sym[04] offset 0x004c padding 0x0 flag 0x20000 address 0x80f804d0 name: rgb_user_init
Sym[05] offset 0x005c padding 0x0 flag 0x20000 address 0x80f806a4 name: get_rgb_frame_buf
Sym[06] offset 0x0070 padding 0x0 flag 0x20000 address 0x80f8269c name: lcd_set_direction_mode
STEP 2:
mips-linux-objdump -bbinary -mmips -D VX767_V1.0.dl > 767.as
STEP 3:
for function lcd_set_direction_mode(address 0x80f8269c)
we translate that address into 'file address'
file address = 0x80f8269c - 0x80f80000 + 0x230 = 0x28CC
STEP 4:
Find code in 767.as use this 'file address'
< - >
En una página china he encontrado un ejemplo en C para inicializar el ILI9325
Yo ya tengo los datasheet de todos los integrados de la dingoo, a excepción de la gestión de energía (conversión y carga de batería). Lo único que se necesita es eso, la información del LCD y la configuración GPIO de la CPU. Esto último se puede averiguar mediante ingeniería inversa, y el controlador de LCD sospecho que es un ILI9325, más que nada por el nombre del archivo (y cadenas de texto en el interior) que viene con la aplicación de unbricking.Para completar algo más sobre el tema, ya que A600 ha empezado hablando sobre el analizador de DLs de RockBox y el ejemplo en forma de código fuente para iniciar el LCM Ilitek ILI9325, pongo más info y documentación técnica sobre este CI/IC:
- Página web: Ilitek ILI9325 (http://www.ilitek.com/products-txt-e.asp?ck=17)
- Documentación: Ilitek ILI9325 Datasheet (http://www.mediafire.com/?2ki5jntytoi)
- Ejemplo de inicialización: Blog ChinaUnix (http://blog.chinaunix.net/u2/63184/showart_523260.html)
Molondro
20/04/2009, 15:55
Que emoción, qué intriga :) los sceners parace que disfrutáis más descubriendo cosas que cuadno os lo dan todo mascado :)
He contactado con Sofía de Dingoo y me ha confirmado que ellos no pueden proporcionar absolutamente ninguna información sobre el hardware.
Esto es lo que he identificado a partir de una foto de la placa:
* CPU: Ingenic JZ4732 (presuntamente un JZ4740 destinado a exportación).
* Flash: Samsung K9GAG08U0M-PCB00 (2G x 8 bit NAND).
* RAM: Elpida μPD45128163 (128Mbit SDRAM). Dos chips, o sea 256Mbits = 32MBytes.
* Salida TV: Chrontel CH7024.
* Receptor FM: RDA microelectronics RDA5800C.
Los datasheets están disponibles en la web de cada fabricante, a excepción de la flash NAND que me he vuelto loco para encontrar. Si alguien no encuentra este último que lo diga.
En cuanto a hardware no hay mucho más que rascar, a excepción del LCD, gestión de energía y GPIO. El CH7024 probablemente se controle con el bus I2C, mientras que es seguro en el caso del RDA5800C.
El LCD ya comenté que podría ser un ILI9325, pero hay que confirmarlo.
En cuanto a la gestión de energía, investigaré un poco más cuando tenga la mía y la destripe, Creo que lo único que habrá que averiguar es cómo se controla la retroiluminación del LCD y la carga de la batería. Para esto último seguramente habrá un chip que se encargue de esto de forma independiente y la CPU se limite a leer si la carga está en curso y el voltaje de la batería.
Averiguar la configuración y función de las entradas/salidas genéricas de la CPU (GPIO) tampoco debería ser demasiado complicado. Lo más sencillo para empezar es, usando el SDK, hacer un programa que lea la configuración para averiguar qué es salida y qué es entrada. Luego se observan las entradas ante todo tipo de eventos (pulsaciones de botones, conexión cacble USB, conexión salida TV, conexión de alimentación externa, fin de la carga de la batería, etc) y se deduce a qué corresponde cada cosa. Con las salidas hay que ir cambiándolas a ver qué pasa y es algo más laborioso.
Por supuesto siempre está la posibilidad de desensamblar e interpretar el firmware original, pero es una tarea titánica. Seguramente sería más sencillo empezar por el .DL que viene con la aplicación de unbricking.
Como ya he comentado, creo que de cara a portar aplicaciones y emuladores probablemente sea más productivo portar linux que portar las aplicaciones una a una. Sólo veo algunos inconvenientes que podríamos debatir: por lo que sé los códecs de vídeo que vienen de fábrica funcionan muy bien y deben estar optimizados para este procesador (MIPS+XBurst) o por lo menos para esta arquitectura (MIPS). Reinventar esta rueda no es un asunto trivial.
....
Da gusto leer a alguien que controla tanto de hardware :brindis:
Como ya he comentado, creo que de cara a portar aplicaciones y emuladores probablemente sea más productivo portar linux que portar las aplicaciones una a una. Sólo veo algunos inconvenientes que podríamos debatir: por lo que sé los códecs de vídeo que vienen de fábrica funcionan muy bien y deben estar optimizados para este procesador (MIPS+XBurst) o por lo menos para esta arquitectura (MIPS). Reinventar esta rueda no es un asunto trivial.
Desde el punto de vista del usuario final linux es, sin duda, el camino a seguir. La versión del mplayer para linux que hay en el ftp de Ingenic, por lo que he podido ver con un vistazo rápido, hace uso del Ingenic Media Extension Instruction Set, al igual que la versión para ucos.
Desde el punto de vista del usuario final linux es, sin duda, el camino a seguir. La versión del mplayer para linux que hay en el ftp de Ingenic, por lo que he podido ver con un vistazo rápido, hace uso del Ingenic Media Extension Instruction Set, al igual que la versión para ucos.
Cierto, no lo había comprobado.
En todo caso antes de meterse a desarrollar un firmware basado en linux hay que valorar bien las opciones. En mi opinión la facilidad para portar software sólo compensa si el nuevo firmware ofrece un nivel de funcionalidad por lo menos similar al original en todos los aspectos. Me preocupa sobre todo el tema de las optimizaciones XBurst como ya he dicho, porque no hay documentación al respecto. Si el MPlayer que proporciona Ingenic sirve, perfecto, una cosa menos. Faltaría ver si los emuladores actuales están también optimizados, que lo dudo.
Hoy ha llegado mi A320. A ver si en los próximos días tengo un rato para desmontarla y documentar adecuadamente el hardware. Lo primero que hay que hacer es encontrar las señales RX/TX de la UART para tener acceso a una consola independiente del display y poder depurar el proceso de arranque del bootloader y del kernel de linux.
He contactado con Sofía de Dingoo y me ha confirmado que ellos no pueden proporcionar absolutamente ninguna información sobre el hardware.
Esto es lo que he identificado a partir de una foto de la placa:
* CPU: Ingenic JZ4732 (presuntamente un JZ4740 destinado a exportación).
* Flash: Samsung K9GAG08U0M-PCB00 (2G x 8 bit NAND).
* RAM: Elpida µPD45128163 (128Mbit SDRAM). Dos chips, o sea 256Mbits = 32MBytes.
* Salida TV: Chrontel CH7024.
* Receptor FM: RDA microelectronics RDA5800C.
Los datasheets están disponibles en la web de cada fabricante, a excepción de la flash NAND que me he vuelto loco para encontrar. Si alguien no encuentra este último que lo diga.
En cuanto a hardware no hay mucho más que rascar, a excepción del LCD, gestión de energía y GPIO. El CH7024 probablemente se controle con el bus I2C, mientras que es seguro en el caso del RDA5800C.
El LCD ya comenté que podría ser un ILI9325, pero hay que confirmarlo.Respecto al hardware de la Dingoo, me he llevado una sorpresa al abrir la mia hoy, resulta que no tengo los mismos chips de RAM ni de NAND Flash MLC, es más de NAND Flash solo tengo un solo chip, de 4 GB, pero no 2 de 2 GB como se ven en las fotos del blog de Scene-Dingoo, es Samsung también pero no es el mismo. Los modulos de RAM, si, tengo 2 pero son de otro fabricante y después de contrastar las caracteristicas del Elpida me ha resultado intrigante... verás:
Memoria RAM:
- Cantidad total: 32 MiB
- Modulos: 2x 16 MiB
- Fabricante: Hynix
- Modelo (Part Number): HY57V281620FTP-6
- Características (Organización): 128 Mbit (4 Bank x 2M Word x 16 bits Synchronous DRAM)
- Interfaz: LVTTL
- Frecuencia de reloj máxima: 166 MHz
- Info General: Databook, Device Operation Documentation, etc. (http://www.hynix.com/products/consumer/consumer_sub.jsp?menuNo=1&m=2&s=0&menu3=03&RK=01&RAM_NAME=SDR%20SDRAM&SUB_RAM=128Mb)
- Info Tecnica: Datasheet (http://www.hynix.com/datasheet/eng/consumer/details/consumer_01_HY57V281620FTP.jsp?menu1=01&menu2=02&menu3=03&menuNo=1&m=2&s=0&RK=01)
Memoria NAND Flash:
- Cantidad total: 4.13 GB / 3.84 GiB
- Modulos: 1x
- Fabricante: Samsung
- Modelo (Part Number): K9LBG08U0M-PCB00 NAND Flash MLC
- Info General: Samsung K9LBG08U0M (http://www.samsung.com/global/business/semiconductor/productInfo.do?fmly_id=672&partnum=K9LBG08U0M)
La diferencia técnica entre según los datasheets entre los modulos de RAM que salen en las fotos de Scene-Dingoo, Elpida µPD45128163G5-A75-9JF y los de mi Dingoo A320, Hynix HY57V281620FTP-6, es que la frecuencia de reloj máxima del Elpida es de 133 MHz, mientras que el del Hynix es de 166 MHz máximo.
Del chip de NAND Flash de Samsung que lleva mi A320 tampoco he encontrado información tecnica detallada, como un datasheet, simplemente la información escueta que da Samsung en su web.
Respecto a la pantalla LCD y al posible driver IC ILI925 que usa, al desmontar la Dingoo me he fijado el número del modelo de LCD que viene serigrafiado FTP280P04N-01, no he conseguido mucha info sobre esto salvo en la web del fabricante chino de LCDs Shengbite, concretamente en una hoja Excel que se puede descargar con su catalogo de LCDs en el cual vienen las características de cada LCD que fabrica.
Catalogo Shengbite de LCDs (http://www.shengbite.com/cn/images/1.xls)
Concretamente el modelo FTP280P04N si viene, pero no como FTP280P04N-01 su FPC, unicamente el FTP280P04N-00 (registro 523), pero por las características parece coincidir en todo lo demás, incluido el ILI9325 como CI controlador del LCD.
Estos son los datos extraidos y traducidos (en parte gracias a Google Language Tools):
Pantalla LCD:
- Modelo: FTP280P04N
- Modelo FPC (Flexible Printed Circuit): FPC-FTP280P04N-01
- Longitud del pliege FPC: 27.80
- Driver IC: ILI9325
- Cristal TFT: PVI P4928QC1-1.0
- Tamaño de pantalla: 2.8"
- Retroiluminación (Backlight): Blanca, 4 LED chips en paralelo
- Descripción: En la base de 280C05 para IC y LCD
- Numero de pixels: 240RGBx320
- Numero de Pines: 37
- Tipo de Interfaz (?): 16
- Definición del Pin Nº 1: DB0
- Modo y colores de pantalla (display): 262K TFT/Transmissive
- Perspectiva de la dirección: 12:00
- Dimensiones: 69.2 x 50.0 x 2.75
- Area Activa: 57.6 x 43.2
Como digo no tiene porque ser correcto, y más los detalles (como lo del tipo de interfaz = 16, no se a que se refiere), pero parece coincidir bastante. Tengo fotos hechas, las subiré luego a mi cuenta de Mediafire para quien quiera ver el hardware de una Dingoo A320 distinto al de Scene-Dingoo.
Booboo, si mañana desmontas tu Dingoo ya nos contaras si se parece el interior a la mia o a la de Scene-Dingoo (o a ninguna de las dos xD).
Actualización:
Subidas las fotos del hardware de la Dingoo A320, para quienes tengais curiosidad podeis descargar el "pack" de 48 MiB con 40 fotos desde aquí (http://www.mediafire.com/?yzmxnh0nbmn).
En todo caso antes de meterse a desarrollar un firmware basado en linux hay que valorar bien las opciones. En mi opinión la facilidad para portar software sólo compensa si el nuevo firmware ofrece un nivel de funcionalidad por lo menos similar al original en todos los aspectos. Me preocupa sobre todo el tema de las optimizaciones XBurst como ya he dicho, porque no hay documentación al respecto. Si el MPlayer que proporciona Ingenic sirve, perfecto, una cosa menos.
A mí en particular, me haría mucho más feliz un port de las SDL para usar con el firmware actual que un linux.
Faltaría ver si los emuladores actuales están también optimizados, que lo dudo.
De eso no te quepa la menor duda :D
Yo espero portar el XRick este fin de semana si tengo tiempo libre que tengo ganas de viciarme al Rick Dangerous :)
El FTP de ingenic esta bastante bien, a parte del mplayer, tienen los fuentes del GTK, tinyx, qtopia y cpufreqd.
Desde el desconocimiento, no sé si esto te ayudaria booboo:
ftp://ftp.ingenic.cn/4hw/Jz4740_Board_Design%20Guide_EN.pdf
Ahi estan las especificaciones necesaria spara hacer una placa en la que montar el JZ4740.
Y aqui algo de una placa de desarrollo con muchos esquemas que no entiendo:
ftp://ftp.ingenic.cn/4hw/01_DEV_board/DB4740_Leo/hw/v1.1/sch_db4740_leo_v1.1.pdf
Y mas informacion sobre la plataforma PAVO que llaman ellos:
ftp://ftp.ingenic.cn/4hw/02_RDK/RD4740_Pavo/
Espero que te sirva de algo :P
La diferencia técnica entre según los datasheets entre los modulos de RAM que salen en las fotos de Scene-Dingoo, Elpida µPD45128163G5-A75-9JF y los de mi Dingoo A320, Hynix HY57V281620FTP-6, es que la frecuencia de reloj máxima del Elpida es de 133 MHz, mientras que el del Hynix es de 166 MHz máximo.
Es normal que los chips sean diferentes pero equivalentes. La frecuencia de trabajo especificada por el fabricante es la máxima, por lo que si el diseño de la Dingoo contempla el funcionamiento a, digamos, 133MHz, servirían tanto los chips de 133MHz como los de 166MHz.
Del chip de NAND Flash de Samsung que lleva mi A320 tampoco he encontrado información tecnica detallada, como un datasheet, simplemente la información escueta que da Samsung en su web.
Algo no me cuadra. En la información que das primero indicas que sólo hay un chip y que es de 4G pero luego dices que el modelo es K9LBG08U0M-PCB00 de 2GB.
Respecto a la pantalla LCD...
- Driver IC: ILI9325
Creo que esto, junto con lo que yo comenté del fichero .DL son indicios suficientes como para asumir que el controlador es un ILI9325. Una cosa menos.
De todas formas, echando un vistazo al datasheet del ILI9325 uno se da cuenta de que el controlador es muy sencillo y que se ocupa simplemente del refresco del LCD. Se trata de saber simplemente el modo de interfaz en el que está configurado en el hardware de la A320.
Como digo no tiene porque ser correcto, y más los detalles (como lo del tipo de interfaz = 16, no se a que se refiere), pero parece coincidir bastante. Tengo fotos hechas, las subiré luego a mi cuenta de Mediafire para quien quiera ver el hardware de una Dingoo A320 distinto al de Scene-Dingoo.
Sí, por favor. Yo haré lo mismo y así podremos comparar.
Booboo, si mañana desmontas tu Dingoo ya nos contaras si se parece el interior a la mia o a la de Scene-Dingoo (o a ninguna de las dos xD).
Es posible que tarde unos días, ando un poco liado esta semana.
< - >
A mí en particular, me haría mucho más feliz un port de las SDL para usar con el firmware actual que un linux.
La cuestión es que seguramente sea más sencillo portar linux (partiendo de lo que proporciona Ingenic, por supuesto) y luego las SDL sobre linux que la SDL directamente sobre el firmware actual (o directamente hardware). En fin... todo es cuestión de ponerse. Yo voy a empezar a trastear este fin de semana a ver cómo se ve la cosa de complicada.
< - >
El FTP de ingenic esta bastante bien, a parte del mplayer, tienen los fuentes del GTK, tinyx, qtopia y cpufreqd.
Desde el desconocimiento, no sé si esto te ayudaria booboo:
Sí, lo primero que hice fué hacerme un mirror completo del FTP de Ingenic. Les eché un vistazo a los esquemáticos mientras intentaba identificar el chip FM.
La verdad es que en estos casos en que la CPU está pensada para una aplicación tan específica (PMP) y el fabricante proporciona un "diseño de referencia" y una placa de evaluación, los diseños finales no suelen apartarse mucho, con lo cual si uno sabe dónde mirar, aunque los diseños no sean idénticos se pueden deducir muchas cosas.
Es normal que los chips sean diferentes pero equivalentes. La frecuencia de trabajo especificada por el fabricante es la máxima, por lo que si el diseño de la Dingoo contempla el funcionamiento a, digamos, 133MHz, servirían tanto los chips de 133MHz como los de 166MHz.Eso me suponía, pero me ha parecido curioso :D
Algo no me cuadra. En la información que das primero indicas que sólo hay un chip y que es de 4G pero luego dices que el modelo es K9LBG08U0M-PCB00 de 2GB.Fallo mio al escribir lo de 2 GiB en los detalles (gracias, corregido), de hecho eso no viene en la web de Samsung, es algo que he escrito porque estoy seguro que la NAND Flash de mi Dingoo es de 4 GB, más que nada porque cuando la conecto me aparece como el tamaño total de disco, pero solo tiene un chip (ya verás en las fotos el hueco que hay en el circuito impreso) así que tiene que ser de 4 GB.
Creo que esto, junto con lo que yo comenté del fichero .DL son indicios suficientes como para asumir que el controlador es un ILI9325. Una cosa menos.
De todas formas, echando un vistazo al datasheet del ILI9325 uno se da cuenta de que el controlador es muy sencillo y que se ocupa simplemente del refresco del LCD. Se trata de saber simplemente el modo de interfaz en el que está configurado en el hardware de la A320.Bueno es saberlo, documentarse del hardware de la A320 y su funcionamiento no es ta siendo sencillo (y menos viendo que los de Dingoo Digital no acceden a dar dicha info). Lo del GPIO sería interesante conocerlo y documentarlo, se que el usbtool permite ver los valores de GPIO para entrada como las pulsaciones de los botones, el pad direccional o incluso el boton de ON/OFF, es más, lo he probado, visto y anotado los valores por curiosidad. Se podria modificar o basarse en la parte de GPIO en el código de USBTool de RockBox para conseguir todos los valores posibles y a ser posible no solo los de entrada, es una idea nada más :)
Estoy subiendo las fotos, en cuando termine de subirse todo el paquete (son casi 50 MiB en 40 fotos a una resolución alta) pondré el enlace en el post de antes sobre las características de la RAM, NAND Flash y LCD.
Uncanny, tu dingillo es de la remesa con la caja negra ? , es mas que nada por curiosidad para saber si el cambio de hardware coincidió con el de embalaje ...
La mía es de la caja blanca y con las mismas especificaciones que puso booboo.
Ram: ELPIDA D45128163G5 A75-9JF 0824XEB0C x 2
Flash: Samsung 901 K9GAG08U0M-PCB0 x 2
Y como modelo/serie en la caja aparece: A320WH9083980
Uncanny, tu dingillo es de la remesa con la caja negra ? , es mas que nada por curiosidad para saber si el cambio de hardware coincidió con el de embalaje ...
La mía es de la caja blanca y con las mismas especificaciones que puso booboo.
Ram: ELPIDA D45128163G5 A75-9JF 0824XEB0C x 2
Flash: Samsung 901 K9GAG08U0M-PCB0 x 2
Y como modelo/serie en la caja aparece: A320WH9083980Que va, Dingoo blanca como la nieve, con su caja también blanca, da las que le gustaría a Chicho Terremoto vamos xD.
Si con el número de modelo/serie te refieres a eso que viene en el minicodigo de barras pues es A320WH9084252. Es más, tengo otra Dingoo A320 (si, otra más xD), sin abrir la caja aun, del mismo tipo parece, la compré una semana después así y el número tampoco coincide ni con la que uso ni con la tuya y es A320WH9084224.
Por si de alguna forma sirviera de referencia, la batería tiene la fecha 20081211, mientras que por ejemplo la de Scene-Dingoo es 20090208.
Que va, Dingoo blanca como la nieve, con su caja también blanca, da las que le gustaría a Chicho Terremoto vamos xD.
Si con el número de modelo/serie te refieres a eso que viene en el minicodigo de barras pues es A320WH9084252. Es más, tengo otra Dingoo A320 (si, otra más xD), sin abrir la caja aun, del mismo tipo parece, la compré una semana después así y el número tampoco coincide ni con la que uso ni con la tuya y es A320WH9084224.
Por si de alguna forma sirviera de referencia, la batería tiene la fecha 20081211, mientras que por ejemplo la de Scene-Dingoo es 20090208.
Bueno esto va a ser como con la 360, "a partir de la A320WH9084224" es con un solo chip para la flash y tiene un lector samsung... diiiiigo memoria :)
Estoy subiendo las fotos, en cuando termine de subirse todo el paquete (son casi 50 MiB en 40 fotos a una resolución alta) pondré el enlace en el post de antes sobre las características de la RAM, NAND Flash y LCD.
Ya las tengo. A ver si hoy mismo puedo hacer lo propio.
Algunas observaciones:
- En la zona de la cruceta hay pads para soldar micropulsadores (que sustituirían a la cruz de goma). En cambio no es así en el caso de los pulsadores.
- Los "test points" TP1 y TP2 están convenientemente etiquetados como TXD y RXD, con lo cual ya tenemos acceso a la consola (será necesario un conversor LVTTL a RS232, tengo varios por aquí). Se echa de menos un plano general pero creo que están detrás del LCD, ¿correcto?. También por el número de vías ("agujeritos") y su distribución deduzco que estos TP están justo detrás de la CPU (por lo que SEGURO que no hay un punto de conexión equivalente por el otro lado).
- Tener sólo un chip flash y por lo tanto el hueco del otro libre es una ventaja: se puede añadir un segundo chip (aunque esto evidentemente no lo puede hacer cualquiera, y todavía habría que ver si el SO lo reconoce y aprovecha).
Que emoción, qué intriga :) los sceners parace que disfrutáis más descubriendo cosas que cuadno os lo dan todo mascado :)
lo que yo no sabia es que ahora todo el mundo tiene la carrera de electronica, o no soy el unico que no se entera de que estan hablando? hablan de portar linux como si fuera un trabajo del insti. :(
Aiken
< - >
* RAM: Elpida μPD45128163 (128Mbit SDRAM). Dos chips, o sea 256Mbits = 32MBytes.
Mbits o Mbytes?
Aiken
lo que yo no sabia es que ahora todo el mundo tiene la carrera de electronica, o no soy el unico que no se entera de que estan hablando? hablan de portar linux como si fuera un trabajo del insti. :(
Aiken
< - >
Mbits o Mbytes?
Aiken
256Mbits = 32MBytes
lo que yo no sabia es que ahora todo el mundo tiene la carrera de electronica, o no soy el unico que no se entera de que estan hablando? hablan de portar linux como si fuera un trabajo del insti. :(
En mi caso sí, soy ingeniero electrónico. Lo de portar linux lo veo factible (que no fácil) porque Ingenic (el fabricante de la CPU) proporciona un parche completo para el kernel que se supone que te da la mayoría de la faena hecha.
Mbits o Mbytes?
256Mbits = 32 MBytes
8 bits = 1 byte
< - >
Ok. Ya he desmontado la Dingoo y he hecho un buen montón de fotos que subiré en cuanto pueda, pero yo diría que es EXÁCTAMENTE igual a la de Uncanny (RAM Hynnix y un sólo chip NAND flash de 4GB).
Mucho cuidado al desmontar la dingoo porque como ya sabeis la batería está SOLDADA, lo cual significa que la estais desmontando ALIMENTADA. Si se os va el destornillador y tocais en algún lado podeis hacer un corto y cargarosla.
Lo realmente interesante es que he pinchado con el osciloscopio en TP1/TXD y TP2/RXD y he verificado que sale algo por ahí al darle al reset (57600 baudios 8N1). Cuando tenga algo más de tiempo soldaré cables y conectaré al conversor LVTTL-RS232 para ver qué es lo que sale. Lo de soldar los cables va a estar complicado porque hay que soldarlos de manera que quepan en el ridículo espacio que hay entre el LCD y el circuito impreso y salgan por un lado del LCD, y no se si tengo por aquí cables tan finos (que además serán complicados de manipular).
Seguiré informando...
Actualización: he instalado un conector para hacer accesibles desde el exterior los pines TXD, RXD y GND. Fotos y demás cuando haya secado el pegamento mañana...
Renuente
22/04/2009, 16:12
Gracias por la info booboo, esperamos esas fotos.
Ya las tengo. A ver si hoy mismo puedo hacer lo propio.
Algunas observaciones:
- En la zona de la cruceta hay pads para soldar micropulsadores (que sustituirían a la cruz de goma). En cambio no es así en el caso de los pulsadores.Como de electrónica entiendo lo justo (y eso que me gusta esta ciencia) no alcanzo a ver cuales son las posibles ventajas/desventajas, unicamente se que los micropulsadores se usa en algunos joypads y joysticks, especialmente en las palancas direccionales, así que me supongo que usar micropulsadores electrónicos da mayor respuesta y precisión ¿algo así?
- Los "test points" TP1 y TP2 están convenientemente etiquetados como TXD y RXD, con lo cual ya tenemos acceso a la consola (será necesario un conversor LVTTL a RS232, tengo varios por aquí). Se echa de menos un plano general pero creo que están detrás del LCD, ¿correcto?. También por el número de vías ("agujeritos") y su distribución deduzco que estos TP están justo detrás de la CPU (por lo que SEGURO que no hay un punto de conexión equivalente por el otro lado).Si, aunque ya habrás podido comprobarlo cuando lo has abierto (supongo que las tuyas serán más detalladas y certeras que las mias, al menos a mi me ha costado conseguir un nivel de detalle decente), tenía una foto del plano general pero al parecer no enfoqué correctamente y salía bastante borrosa, por lo que no tenía utilidad alguna.
- Tener sólo un chip flash y por lo tanto el hueco del otro libre es una ventaja: se puede añadir un segundo chip (aunque esto evidentemente no lo puede hacer cualquiera, y todavía habría que ver si el SO lo reconoce y aprovecha).Aun así bueno es saberlo :)
En mi caso sí, soy ingeniero electrónico.Se nota, porque controlas bastante, te envidio la verdad, como ya te digo la electrónica para mi es un tema apasionante en el que nunca he podido meterme de lleno :)
Ok. Ya he desmontado la Dingoo y he hecho un buen montón de fotos que subiré en cuanto pueda, pero yo diría que es EXÁCTAMENTE igual a la de Uncanny (RAM Hynnix y un sólo chip NAND flash de 4GB).
Mucho cuidado al desmontar la dingoo porque como ya sabeis la batería está SOLDADA, lo cual significa que la estais desmontando ALIMENTADA. Si se os va el destornillador y tocais en algún lado podeis hacer un corto y cargarosla.Vaya, tenemos lo mismo dentro de la A320, por ahora parece que quienes la han desmontado tienen esa misma o la misma que aparece en Scene-Dingoo, habrá que ver si la negra u otra Dingoo blanca tienen otras diferencias en los componentes de hardware.
Lo de la batería, pues si, hay que tener cuidado, ya estaba advertido al ver las fotos de Scene-Dingoo y encima está pegada a base de bien con la superficie adhesiva esa que hay que despegarla con cuidado y paciencia para no liarla :D
Como de electrónica entiendo lo justo (y eso que me gusta esta ciencia) no alcanzo a ver cuales son las posibles ventajas/desventajas, unicamente se que los micropulsadores se usa en algunos joypads y joysticks, especialmente en las palancas direccionales, así que me supongo que usar micropulsadores electrónicos da mayor respuesta y precisión ¿algo así?
Los micropulsadores tienen otro tacto diferente... hacen "clic". Los botones de "select" y "start" llevan micropulsadores. De todas formas lo decía más como curiosidad que otra cosa.
Lo de la batería, pues si, hay que tener cuidado, ya estaba advertido al ver las fotos de Scene-Dingoo y encima está pegada a base de bien con la superficie adhesiva esa que hay que despegarla con cuidado y paciencia para no liarla :D
El parche adhesivo en mi caso estaba muy bien pegado a los chips pero la batería ha salido sin a penas estirar, yo diría que no estaba ni pegada. De todas formas en el hueco que ocupa no tiene espacio para moverse. De hecho estoy pensando que no tiene mucho sentido pegar la batería a un par de chips ya que se está forzando innecesariamente la soldadura. Si el objetivo es pegar la batería a algo para que no se mueva es mucho mejor pegarla por el otro lado al interior de la parte trasera de la carcasa.
Ya veré lo que hago cuando la vuelva a montar si no se queda fija.
Los micropulsadores tienen otro tacto diferente... hacen "clic". Los botones de "select" y "start" llevan micropulsadores. De todas formas lo decía más como curiosidad que otra cosa.Es lo que tiene pecar de ignorancia en estos temas (salvo en lo del "clic", eso si xD)
El parche adhesivo en mi caso estaba muy bien pegado a los chips pero la batería ha salido sin a penas estirar, yo diría que no estaba ni pegada. De todas formas en el hueco que ocupa no tiene espacio para moverse. De hecho estoy pensando que no tiene mucho sentido pegar la batería a un par de chips ya que se está forzando innecesariamente la soldadura. Si el objetivo es pegar la batería a algo para que no se mueva es mucho mejor pegarla por el otro lado al interior de la parte trasera de la carcasa.Cuando lo abrí me supuse que el razonamiento detrás de ello podría venir de que si hubieran pegado o sujetado de otra forma la batería a la parte interna de la carcasa inferior, podría dificultar o resultar problemático el desmontaje (pensemos en un técnico de su empresa) y llevarse las soldaduras de los cables por delante si no tiene cuidado al extraerla, o simplemente es para facilitar el proceso de montaje, que puede resultar más sencillo hacerlo así que de la otra forma.
Hay que ver cuánto habéis avanzado en la investigación en tan pocos días, y qué actitud tienen las empresas de no dar información del hardware a los programadores. ¡Se perjudican ellos mismos!
Has entrado en nuestra comunidad por la puerta grande booboo. Estoy expectante por saber los mensajes que aparecen por el puerto serie, jeje. El sistema operativo y los drivers que trae!!
Aunque no tengo la consola, me gusta la dingoo negrita. Curiosamente en el trabajo he tenido que convertir una librería de C++ a C. Puedo intentar portar algo de las SDL o crear una pequeña librería. Lo que se podría hacer al principio es hacer funciones para convertir las llamadas de la SDL al api de la dingoo.
DMusta1ne
22/04/2009, 22:39
Así da gusto leeros. Bienvenido booboo, parece que has llegado y arrasado.
¡Ánimo tíos!
Por si os interesa. Jorgehj ha actualizado el blog con algunas
"Descargar e instalar las SDK de Dingoo A320"
http://blog.tipesoft.com/?p=824
"Dingoo A-320: Hola mundo en C++ con Visual Studio 2008"
http://blog.tipesoft.com/?p=827
Un saludo y gracias por el esfuerzo que hacéis en documentar el hardware.
A mi me llegó ayer y la verdad es que funciona muy bien (cruzaré los dedos ^_^U)
Otro que la ha reservado :d y muy interesado con la consolilla :p
Bueno... ya tengo el invento terminado y he capturado el output del arranque del firmware que viene de fábrica, ahora a trastear con linux.
Ya pondré enlaces a las fotos y todo eso en cuanto tenga 10 mensajes (es lo que tiene ser nuevo):
NAND Booting...ECD755B6..
loader size = 0x00051670
.00000114:1..
OK
NAND Loading...
get ccpmp_config ok!!!
ccpmp_config.firmware_name = A320.HXF. ccpmp_config.update_key = 123, ccpmp_config.lcm.width = 320, ccpmp_config.lcm.height = 240.
loader normal mode...
Creating ftl device...
id:EC D7 55 B6 78
id:00 00 00 00 00
id:00 00 00 00 00
id:00 00 00 00 00
OK.
usb_connect = 0
into lcd_init.
loader -- into lcd_init.
into init_lcd_gpio.
out init_lcd_gpio.
loader -- init_lcd_gpio ok.
into Init_LCM_MOUDLE_ILI9325!!!
out Init_LCM_MOUDLE_ILI9325!!!
loader -- init_lcd_register ok.
loader -- out lcd_init.
Start decode...
OK 153602.
out lcd_init.
get_lcd_brightness -- value = 3.
00001550:1.00002D31:1.len is 0x 500000
os_len = 0x 23a078. checksum = 0x0a232c05.
1 - ret = 0
2 - ret = 1
Run image...
c_main enter------!!
kseg init OK!
new loader, system config ok!
intc init OK!
intc lib OK!
the os is start
Actualización: he instalado un conector para hacer accesibles desde el exterior los pines TXD, RXD y GND. Fotos y demás cuando haya secado el pegamento mañana...
¿Se podría usar el conector de los auriculares? Me refiero a cortar las pistas que llevan el audio izdo/dcho al conector y soldarle sendos cables a los pines TXD y RXD.
Creo que así quedaría un "Dingoo Debug Kit" bastante apañado :D
Impresionante el trabajo de investigación que estás haciendo booboo. Sobre el sistema operativo, tiene pinta de ser una versión reducida de Linux. De ser un sistema propio, le habrían puesto un nombre en vez de "the os".
¿Se podría usar el conector de los auriculares? Me refiero a cortar las pistas que llevan el audio izdo/dcho al conector y soldarle sendos cables a los pines TXD y RXD.
Creo que así quedaría un "Dingoo Debug Kit" bastante apañado :D
Si, supongo que se podría pero entonces te quedas sin la función de auriculares: habría que cortar las pistas que llevan el audio hasta los conectores.
Puedes ver en las fotos lo que yo he hecho. Creo que es lo suficientemente aseado (en el siguiente mensaje... que este es el 9).
Si, supongo que se podría pero entonces te quedas sin la función de auriculares: habría que cortar las pistas que llevan el audio hasta los conectores.
Se puede usar el conector de TVOUT para sacar el audio.
Impresionante el trabajo de investigación que estás haciendo booboo. Sobre el sistema operativo, tiene pinta de ser una versión reducida de Linux. De ser un sistema propio, le habrían puesto un nombre en vez de "the os".
El sistema operativo es, casi con toda seguridad, uCOS-II. Es un sistema multitarea en tiempo real bastante básico. Seguramente los mensajes que se ven durante el arranque son casi todos del bootloader, que es el código que se encarga de cargar en memoria y landar el sistema operativo.
La gracia de este micro es que tiene una ROM interna que permite cargar lo que quieras en la RAM(caché) vía USB. Es decir, te puedes cargar completamente todo el contenido de la flash y el sistema es recuperable (primero se carga en RAM-caché un código que inicializa la SDRAM, luego se carga en la SDRAM otro código que ya sirve para inicializar y grabar la flash).
< - >
Vale, a ver si ahora me deja poner los enlaces a lo que he hecho para acceder a la consola:
http://img257.imageshack.us/img257/6008/p1010205tpl.jpg (http://www.imagehosting.com/)
http://img82.imageshack.us/img82/6432/p1010208.jpg (http://www.imagehosting.com/)
http://img82.imageshack.us/img82/4572/p1010210.jpg (http://www.imagehosting.com/)
http://img61.imageshack.us/img61/2927/p1010215.jpg (http://www.imagehosting.com/)
http://img167.imageshack.us/img167/8941/p1010217.jpg (http://www.imagehosting.com/)
http://img510.imageshack.us/img510/9471/p1010219.jpg (http://www.imagehosting.com/)
Joer casi nada el currele que te has pegao.
Gracias por la fotos, booboo :brindis:
¿Se podría usar un cable DKU-5 en vez de la placa que has usado tú?
*****, eres un fiera xD
Yo creo que si mandas estas fotos a CraigX, lo mismo te regala una de esas que tiene para desarrolladores :rever:
Gracias por la fotos, booboo :brindis:
¿Se podría usar un cable DKU-5 en vez de la placa que has usado tú?
Las señales TXD/RXD son de 3.3V, por lo poco que he mirado de ese cable creo que sí, que es básicamente un conversor USB-serie LVTTL 3.3V.
Lo que yo he usado es esto (más bien sólo la placa de arriba de las dos que forman esto):
http://www.sureelectronics.net/goods.php?id=393
Es barato pero los portes se te comen.
< - >
*****, eres un fiera xD
Yo creo que si mandas estas fotos a CraigX, lo mismo te regala una de esas que tiene para desarrolladores :rever:
¿Cómo contacto con él?
Las señales TXD/RXD son de 3.3V, por lo poco que he mirado de ese cable creo que sí, que es básicamente un conversor USB-serie LVTTL 3.3V.
Pues me viene de perlas porque mi ordenador no tiene puerto serie :)
¿Cómo contacto con él?
Craigx creo que no manda kits de desarollo sino Dingoos normales. De todas formas, puedes intentar contactar con él en los foros de gp32x (http://www.gp32x.com/board/)
Craigx creo que no manda kits de desarollo sino Dingoos normales.
A eso me refería, ahora que ha convertido su Dingoo en una de desarrollo, que le regalen una normal [wei]
Muy interesante las imagenes, ademas, con lo que habeis dicho, podemos esperar que en no demasiado tiempo se pueda hacer funcionar alguna version de linux en el aparatito? y si se consigue hacer funcionar, que se podria llegar a hacer con un linux en esta maquinita? traer ports de otros emuladores?.
Saludos, y suerte a los que estais investigando con el aparatito.
Pon un post allí con las fotos, verás como se quedan flipados. Además como Craigix tienen contactos con fabricantes electrónica lo mismo se ilusiona y nos hace una craddle.
@booboo: ¿tienes alguna foto donde se vea la placa entera?
http://img82.imageshack.us/img82/6432/p1010208.jpg
@booboo: ¿tienes alguna foto donde se vea la placa entera?
A ver si te sirven estas:
http://img514.imageshack.us/img514/2165/p1010180.jpg
http://img4.imageshack.us/img4/2597/p1010196ifi.jpg
http://img144.imageshack.us/img144/8517/p1010197f.jpg
Se me ocurre que quizás lo que quieres ver es por dónde he sacado los cablecillos de detrás del display. No he hecho fotos de eso porque me faltaban manos. Mi display tiene TRES bandas de gomaespuma adhesiva por detrás que puedes ver en la foto: arriba, abajo y por el lado por donde se conecta. Yo he sacado los cables por el otro lado precisamente porque no hay banda de gomaespuma. Eso significa que han salido justo por el lado contrario a donde había colocado el conector, por lo que si te fijas bien en alguna de las fotos que he puesto se ve como los cables pasan hasta el otro lado discurriendo entre la placa y la carcasa.
Quería haber sacado los hilos por el mismo lado por donde está conectado el display, muy cerca del borde inferior, e incluso he quitado un trocito de banda de gomaespuma con ese fin, pero al final resulta que era casi imposible que los cables se quedasen en su sitio mientras se vuelve a montar todo. Incluso sacándolos por donde los he sacado he tenido que utilizar un par de gotas minúsculas de loctite para mantenerlos pegados al circuito impreso por detrás del LCD.
Por cierto, si te vas a poner a ello, vas a tener que utilizar cables MUY finos porque hay MUY poco sitio detrás del display. Yo iba a usar cable de wrapping de 0,45mm pero al final he usado cobre esmaltado de 0,30mm que era lo que tenía a mano. Prefiero el aislamiento plástico al esmaltado, pero 0,45mm era demasiado grueso, y 0,30mm está así así...
< - >
Muy interesante las imagenes, ademas, con lo que habeis dicho, podemos esperar que en no demasiado tiempo se pueda hacer funcionar alguna version de linux en el aparatito? y si se consigue hacer funcionar, que se podria llegar a hacer con un linux en esta maquinita? traer ports de otros emuladores?.
Saludos, y suerte a los que estais investigando con el aparatito.
Un sistema operativo como uCOS-II es más que suficiente para una consola de juegos o un PMP, que no necesitan de todas las funcionalidades avanzadas de linux. Además uCOS-II es más compacto y consume menos recursos. La cuestión es que en realidad hay recursos de sobra (tanto flash como RAM) y meter linux aporta una UNICA gran ventaja: proporciona un entorno de desarrollo conocido para el que ya están escritos muchos emuladores y aplicaciones cuyo portado sería muy sencillo.
En los sistemas operativos de alto nivel para ordenadores hay siempre una barrera muy bien definida entre el kernel del sistema operativo y las aplicaciones. El kernel tiene un punto de entrada a través del cual proporciona todos los servicios a TODAS las aplicaciones. En cambio en los sistemas "empotrados" y con sistemas operativos en tiempo real tipo uCOS-II esto no suele ser así. El sistema operativo y la aplicación "principal" que corre en el aparato forman una imágen monolítica que es lo que hemos estado llamando "firmware", y es el fabricante del firmware el que decide si proporciona un punto de entrada para otras aplicaciones y el API que usa. Es por eso que aunque sabemos que el sistema operativo es uCOS-II en realidad con eso no ganamos nada, ya que desconocemos el API del firmware de chinachip.
No obstante, existen unas librerías S2D que Dingoo proporciona para las que SI que hay un API público, de modo que a la hora de programar hay que ceñirse UNICAMENTE al API que proporcionan estas librerías.
Obviamente como uCOS-II no implementa un modo "protegido" (no tengo claro si quiera que se pueda en esta CPU) cualquier aplicación que hagamos puede acceder directamente al hardware sin más que escribiendo en las direcciones de memoria oportunas. Sin embargo, ello se estará haciendo de forma concurrente al sistema operativo y por lo tanto los resultados son impredecibles, como creo que ya ha comprobado alguien con el tema del overclocking.
estoy aprendiendo mucho gracias a vosotros.
que hilo mas ilustrativo.
gracias famigos!! :brindis:
Por cierto, si te vas a poner a ello, vas a tener que utilizar cables MUY finos porque hay MUY poco sitio detrás del display. Yo iba a usar cable de wrapping de 0,45mm pero al final he usado cobre esmaltado de 0,30mm que era lo que tenía a mano. Prefiero el aislamiento plástico al esmaltado, pero 0,45mm era demasiado grueso, y 0,30mm está así así...
Muchas gracias por la fotos y la detallada explicación.
Por aquí tengo cable AWG30 aunque antes de tirarme al río, voy a ver me puedo apañar como en los tiempos de la GP32 con printfs redireccionados a un fichero para "debuguear".
Muchas gracias por la fotos y la detallada explicación.
Por aquí tengo cable AWG30 aunque antes de tirarme al río, voy a ver me puedo apañar como en los tiempos de la GP32 con printfs redireccionados a un fichero para "debuguear".
Bueno... eso te sirve obviamente para desarrollar aplicaciones para el firmware actual. En mi caso (bootloader+kernel) la consola es necesaria porque el sistema de archivos no está todavía disponible en esa fase.
Toma lección de sistemas operativos a cargo del maestro booboo. Entonces no estaba yo muy descaminado al proponer funciones proxy para portar la SDL. Funciones SDL_xxx que llamen al api público que proporciona el fabricante.
Toma lección de sistemas operativos a cargo del maestro booboo. Entonces no estaba yo muy descaminado al proponer funciones proxy para portar la SDL. Funciones SDL_xxx que llamen al api público que proporciona el fabricante.
Portar la SDL puede no ser viable. Todo depende del API S2D (no me lo he mirado).
En todo caso portar la SDL sólo tiene sentido como una forma de proporcionar un API conocido y bien documentado a los programadores de aplicaciones, luego falta que éstos se pongan a programar.
Me parece más directa (y más entretenida, para qué nos vamos a engañar) la alternativa de portar linux. Si ingenic no proporcionara un kernel ni me lo plantearía (la tarea sería enorme), pero existiendo un kernel que teóricamente funciona, la cosa parece viable, y de un plumazo habríamos portado no sólo la SDL sino también casi cualquier otra librería disponible para linux.
Nota: sólo miré por encima la SDL hace ya algún tiempo... soporta framebuffer como salida de video ¿verdad?.
Nota: sólo miré por encima la SDL hace ya algún tiempo... soporta framebuffer como salida de video ¿verdad?.
Creo recordar que si, aunque como tu, solo lo ojee e hice un par de programas simplones.
Este post me encanta. Estoy estudiando ingeniería electrónica y este post solo me reafirma: me encanta lo que estudio :D
He iniciado el port de oswan (Wonderswan y Wonderswan Color) a Dingoo A-320
Podeis descargar las fuentes de mis primeras aproximaciones en mi blog: blog.tipesoft.com
La parte gráfica ha sido sencilla con las SDK de s2d sustituyendo las llamadas a SDL.
La parte de sonido será un poco más compleja, por lo que solicito ayuda para portalas.
Portar la SDL puede no ser viable. Todo depende del API S2D (no me lo he mirado).
En todo caso portar la SDL sólo tiene sentido como una forma de proporcionar un API conocido y bien documentado a los programadores de aplicaciones, luego falta que éstos se pongan a programar.
Me parece más directa (y más entretenida, para qué nos vamos a engañar) la alternativa de portar linux. Si ingenic no proporcionara un kernel ni me lo plantearía (la tarea sería enorme), pero existiendo un kernel que teóricamente funciona, la cosa parece viable, y de un plumazo habríamos portado no sólo la SDL sino también casi cualquier otra librería disponible para linux.
Nota: sólo miré por encima la SDL hace ya algún tiempo... soporta framebuffer como salida de video ¿verdad?.
Si, soporta framebuffer, yo he estado mirandomelo pero la integracion con el sdk no mola al usar c++, habra que mirar otra libreria que parece que tiene funciones de mas bajo nivel para la dingoo e intentar portarlo con esas.
¿Qué problema hay con C++? Como dije, todo lo que está en C también es C++, ya que es un superconjunto de C. Además con los extern "C" puedes crear una API de C desde C++. Puedes llamar a clases en tus funciones y nadie se entera desde fuera. He estado estudiando el código de la SDL y creo que no es difícil hacer el port. Es mucho trabajo, porque hay que implementar muchas funciones, pero no es difícil. Lo que sería difícil es hacerlo con acceso al hardware y sin tener una librería del fabricante.
¿Qué problema hay con C++? Como dije, todo lo que está en C también es C++, ya que es un superconjunto de C. Además con los extern "C" puedes crear una API de C desde C++. Puedes llamar a clases en tus funciones y nadie se entera desde fuera. He estado estudiando el código de la SDL y creo que no es difícil hacer el port. Es mucho trabajo, porque hay que implementar muchas funciones, pero no es difícil. Lo que sería difícil es hacerlo con acceso al hardware y sin tener una librería del fabricante.
Yo al menos desde c++ no he conseguido compilar correctamente las SDL.
Ultimamente he tenido poco tiempo de trastear con la dingoo... acabo de probar el proceso de recuperación del firmware original para asegurarme de que cuando empiece a tocar la flash no voy a acabar con un pisapapeles de 60€.
Aprovechando que tengo la consola serie, he aquí el output de la actualización de firmware:
************************************************** **************
USB INIT THE PMP!
into new prog!!
the param is 1
it USB BURN P, wo!
ECD755B6the uloader check sum is ok!
erase block = 00000000
the uloader is burn ok!
the seltest check sum is ok!
the offs = 00040000
the block = 00000000
nand_nb_pages_per_blk = 00000080
nand_page_size = 00000800
the dst = 80E00000
write block = 00000001
write block = 00000002
write block = 00000003
here!
burn run over, please reset!!!
the ret is 00000001
loader_for_burn begin...
get ccpmp_config ok!!!
ccpmp_config.firmware_name = A320.HXF. ccpmp_config.update_key = 123, ccpmp_config.lcm.width = 320, ccpmp_config.lcm.height = 240.
into lcd_init.
loader -- into lcd_init.
into init_lcd_gpio.
out init_lcd_gpio.
loader -- init_lcd_gpio ok.
into Init_LCM_MOUDLE_ILI9325!!!
out Init_LCM_MOUDLE_ILI9325!!!
loader -- init_lcd_register ok.
loader -- out lcd_init.
out lcd_init.
Creating ftl device...
id:EC D7 55 B6 78
id:00 00 00 7E FF
id:00 00 00 7E FF
id:00 00 00 7E FF
ret = 1
begin erase_all_flash..
chip is 0, size = 4096M.
blk_size = 512K.
num of block = 8192.
chip is 1, size = 0M.
chip is 2, size = 0M.
chip is 3, size = 0M.
end erase_all_flash.
loader_for_burn -- wait for burn...
udc_loop.
USB 1.1
USB 2.0
USB 2.0
Safely remove.
loader_for_burn -- burn ok, sytem will be reboot...
Ahora me voy a poner a programar una aplicacion con el SDK para leer los valores de inicialización de los registros de configuración de SDRAM, flash, LCD y GPIO, que son fundamentales para que cualquier bootloader funcione . En cuanto tenga esa información ya la pondré por aquí...
Confío en que sea lo único que tenga que programar en windows. Por cierto... con Ubuntu 8.04 no funcionaba la Dingoo (acceso normal a flash interna y tarjeta) y he tenido que actualizar a 9.04. Al parecer es necesario un kernel muy reciente...
Confío en que sea lo único que tenga que programar en windows. Por cierto... con Ubuntu 8.04 no funcionaba la Dingoo (acceso normal a flash interna y tarjeta) y he tenido que actualizar a 9.04. Al parecer es necesario un kernel muy reciente...Pues si, con Ubuntu 8.04 no se monta la NAND Flash por USB, cosa que me mosqueó bastante al principio, hasta que lo probé en otra distro y veía que si la montaba automáticamente, en cambio si funciona arrancar en modo USB-Boot (se puede comprobar con lsusb -v e "interactuando" con la Dingoo A320 a traves de la herramienta usbtool de RockBox), no tengo clara la razón, aunque yo también pienso que debe ser un problema del kernel (versión 2.6.24) o de alguno de sus modulos, ya que un cat /proc/partitions y un fdisk muestra que no detecta bien la tabla de particiones del dispositivo, ni por supuesto, el sistema de archivos que usa (FAT32), sería cosa de compilar otra versión superior del kernel usando la config del actual y comprobarlo, pero bueno, al menos a partir de la 8.10 esto no ocurre ni con la 9.04 como bien has comprobado.
A ver si puedo estudiarme el SDK y ver que se puede hacer con él, aunque primero intentaré preparar un toolchain de compilación cruzada para mipsel en Linux para usar el S2D SDK, y en caso de que no vaya bien o tenga alguna desventaja (creo que en Windows se genera un ejecutable extra para Win32 además de para la Dingoo) pues nada, se usa una VM via VirtualBox con Windows y a tirar millas...
Gracias por la info sobre la salida en el proceso de restauración del firmware, y por tu labor de investigación con la A320 :brindis:
Yo estuve haciendo pruebas y los proyectos que generan ejecutable para win32 no se compilan porque se necesita el SDK de directX.
Asi que creo que si quieres .exe con emulador empotrado no hay ams remedio que compilar desde windows :(
No tiene por qué ser así, la SDL tiene un modelo de drivers que permite compilar sólo los drivers que necesitas. Por ejemplo en Windows puedes elegir los drivers DirectX o Windib, y en Linux están el framebuffer y el svgalib. Además el compilador GCC está también en muchos sistemas.
He encontrado el driver para de lcd pero no lo he podido descargar en rar, aunque tienen el fuente disponible y he hecho copy&paste de aqui:
http://read.pudn.com/downloads138/sourcecode/embed/588844/ili932x.h__.htm
http://read.pudn.com/downloads138/sourcecode/embed/588844/ili9325fb.c__.htm
http://read.pudn.com/downloads138/sourcecode/embed/588844/ili9325.c__.htm
Espero que sirva de algo :P
Hola
Estoy trasteando con el sdk de la A320 pero estoy viendo que muchas veces compilo en windows y se me ejecuta perfectamente pero luego cuando conpilo el target.app no corre y deja colgada la consola, cuando antes si funcionaba perfectamente.
Estoy desde VS2008 y solo tengo un par de algoritmos en el ::Exec() y ::Render() y dos funciones que he metido PutPixel() y DrawLine()
simplemente pinta un cubo en 3d y lo gira, en windows como ya dije corre perfectamente pero en la consola no.
Y las veces que tras cambios en el codigo consigo que corra el cubo se ve 3 veces, como si al escribir en la memoria de video se escribiese 3 veces....
alguna idea ?
uso la funcion PutPixel() que hay en blog . tipesoft . com
Si es cosa del framebuffer A600 averiguó como acceder a él. Si no, no te puedo ayudar.
Pues si, con Ubuntu 8.04 no se monta la NAND Flash por USB, cosa que me mosqueó bastante al principio, hasta que lo probé en otra distro y veía que si la montaba automáticamente, en cambio si funciona arrancar en modo USB-Boot (se puede comprobar con lsusb -v e "interactuando" con la Dingoo A320 a traves de la herramienta usbtool de RockBox), no tengo clara la razón, aunque yo también pienso que debe ser un problema del kernel (versión 2.6.24) o de alguno de sus modulos, ya que un cat /proc/partitions y un fdisk muestra que no detecta bien la tabla de particiones del dispositivo, ni por supuesto, el sistema de archivos que usa (FAT32), sería cosa de compilar otra versión superior del kernel usando la config del actual y comprobarlo, pero bueno, al menos a partir de la 8.10 esto no ocurre ni con la 9.04 como bien has comprobado.
Si haces un dmesg se puede apreciar claramente que hay un montón de errores de comunicación USB y simplemente no se puede leer ni el primer sector (partición) del dispositivo de bloques que debería ser la dingoo. Definitivamente es un problema de la capa USB en esos kernels.
A ver si puedo estudiarme el SDK y ver que se puede hacer con él, aunque primero intentaré preparar un toolchain de compilación cruzada para mipsel en Linux para usar el S2D SDK, y en caso de que no vaya bien o tenga alguna desventaja (creo que en Windows se genera un ejecutable extra para Win32 además de para la Dingoo) pues nada, se usa una VM via VirtualBox con Windows y a tirar millas...
En el FTP de ingenic tienes ya un toolchain mipsel para compilar lo que quieras:
ftp://ftp.ingenic.cn/3sw/01linux/00toolchain/mipseltools-gcc412-glibc261.tar.bz2
Lo descomprimes en /opt/ y añades el subdirectorio bin al path:
PATH=/opt/mipseltools-gcc412-glibc261/bin:$PATH
En el FTP de ingenic tienes ya un toolchain mipsel para compilar lo que quieras:
ftp://ftp.ingenic.cn/3sw/01linux/00toolchain/mipseltools-gcc412-glibc261.tar.bz2
Lo descomprimes en /opt/ y añades el subdirectorio bin al path:
PATH=/opt/mipseltools-gcc412-glibc261/bin:$PATHGracias por la info :brindis:
De hecho lo tenía descargado, cuando lo has dicho me he acordado de que me descargué los paquetes que subió A600 con el contenido del FTP de Ingenic, así que perfecto, menos trabajo que hacer :D
A parte he visto en la web de Ingenic (http://www.ingenic.cn/eng/productServ/kfyd/Linux/pfCustomPage.aspx) que han colgado un paquete con el código fuente (como tiene que ser) y los scripts del toolchain, perfecto por si se quiere modificar y hacer otro toolchain con una versión distinta de GCC, Binutils, GNU C Library y el resto de la pesca :)
Bueno... después de pegarme un buen rato con el SDK y con el visual studio (debía hacer como 6 años que no programaba en windows), he logrado compilar un programa para obtener el estado de los periféricos integrados que me interesaban.
Voy a hacer un inciso para dar mi opinión personal sobre el SDK: salvo que se me esté escapando algo, es la mayor mierda que me he echado a la cara en toda mi vida (y he tenido que lidiar con algunas importantes). Warnings por un tubo en los headers, documentación inexistente... en fin, lamentable a más no poder. Hay que tener moral para ponerse a programar usando esto, así que ya tenemos otro buen motivo para intentar portar linux.
Bueno, a lo que iba. Esto es lo que he sacado: tened en cuenta que el "printf" de la clase Log de S2D no pone ceros a la izquierda aunque se lo especifiques, así que 4400 equivale a 0x00004400 y donde no veáis nada es que el valor es 0x00000000.
Esto es lo que se obtiene con salida por LCD:
CPM_CPCCR = 40422220
CPM_CPPCR = 1B00050A
CPM_I2SCDR = 4
CPM_LPCDR = 9
CPM_MSCCDR = 4
CPM_UHCCDR = 2
CPM_LCR = F8
CPM_CLKGR = 8200
CPM_SCR = 1580
CPM_HCR = 4
CPM_HWFCR = 4
CPM_HRCR = 4
CPM_HWCR = 4
CPM_HWSR = 4
CPM_HSPR = 4
CPM_RSR = 1
EMC_BCR = C0000001
EMC_NFCSR = 55
EMC_DMCR = 59E3211
EMC_RTCSR = 83
EMC_RTCNT = 4
EMC_RTCOR = 17
EMC_DMAR0 = 20F8
SLCD_CFG = 4400
SLCD_CTRL = 1
SLCD_STATE =
SLCD_DATA = 80000022
SLCD_FIFO =
LCD_CFG = 80000000
LCD_VSYNC =
LCD_HSYNC =
LCD_VAT =
LCD_DAH =
LCD_DAV =
LCD_PS =
LCD_CLS =
LCD_SPL =
LCD_REV =
LCD_CTRL =
LCD_STATE =
LCD_IID =
LCD_DA0 =
LCD_SA0 =
LCD_FID0 =
LCD_CMD0 =
LCD_DA1 =
LCD_SA1 =
LCD_FID1 =
LCD_CMD1 =
GPIO 0
GPIO_PXDAT =
GPIO_PXIM = FFFFFFFF
GPIO_PXPE = FF
GPIO_PXFUN = FFFFFFFF
GPIO_PXSEL =
GPIO_PXDIR =
GPIO_PXTRG =
GPIO 1
GPIO_PXDAT = 40000
GPIO_PXIM = DFFFFFFF
GPIO_PXPE = 2418000
GPIO_PXFUN = 9FF9FFFF
GPIO_PXSEL = 20000000
GPIO_PXDIR = 20060000
GPIO_PXTRG = 20000000
GPIO 2
GPIO_PXDAT = 8080000
GPIO_PXIM = 7FFDFFFF
GPIO_PXPE = 7014FFFF
GPIO_PXFUN = 3714FFFF
GPIO_PXSEL = 20000
GPIO_PXDIR = 8080000
GPIO_PXTRG = 20000
GPIO 3
GPIO_PXDAT = 98
GPIO_PXIM = C7B13F98
GPIO_PXPE = F1A02100
GPIO_PXFUN = A7803F00
GPIO_PXSEL = 3FCEC067
GPIO_PXDIR = D0200090
GPIO_PXTRG = 384EC067
Y esto es lo que se obtiene con la salida TV:
CPM_CPCCR = 40432220
CPM_CPPCR = 1B00050A
CPM_I2SCDR = 4
CPM_LPCDR = D
CPM_MSCCDR = 4
CPM_UHCCDR = 2
CPM_LCR = F8
CPM_CLKGR = 8200
CPM_SCR = 1580
CPM_HCR = 4
CPM_HWFCR = 4
CPM_HRCR = 4
CPM_HWCR = 4
CPM_HWSR = 4
CPM_HSPR = 4
CPM_RSR = 1
EMC_BCR = C0000001
EMC_NFCSR = 55
EMC_DMCR = 59E3211
EMC_RTCSR = 83
EMC_RTCNT = 17
EMC_RTCOR = 17
EMC_DMAR0 = 20F8
SLCD_CFG = 4400
SLCD_CTRL = 1
SLCD_STATE =
SLCD_DATA = 80000022
SLCD_FIFO =
LCD_CFG = 900
LCD_VSYNC = A
LCD_HSYNC = 7D
LCD_VAT = 36C0112
LCD_DAH = 2240364
LCD_DAV = 1B010B
LCD_PS =
LCD_CLS =
LCD_SPL =
LCD_REV =
LCD_CTRL = 2000000C
LCD_STATE = 30
LCD_IID =
LCD_DA0 = 265020
LCD_SA0 = 266000
LCD_FID0 = BEAFBEAF
LCD_CMD0 = C0009320
LCD_DA1 =
LCD_SA1 =
LCD_FID1 =
LCD_CMD1 =
GPIO 0
GPIO_PXDAT =
GPIO_PXIM = FFFFFFFF
GPIO_PXPE = FF
GPIO_PXFUN = FFFFFFFF
GPIO_PXSEL =
GPIO_PXDIR =
GPIO_PXTRG =
GPIO 1
GPIO_PXDAT = 40000
GPIO_PXIM = DFFFFFFF
GPIO_PXPE = 2418000
GPIO_PXFUN = 9FF9FFFF
GPIO_PXSEL = 20000000
GPIO_PXDIR = 20060000
GPIO_PXTRG = 20000000
GPIO 2
GPIO_PXDAT = 280000
GPIO_PXIM = 7FFDFFFF
GPIO_PXPE = 703CFFFF
GPIO_PXFUN = 371CFFFF
GPIO_PXSEL = 20000
GPIO_PXDIR = 8280000
GPIO_PXTRG = 20000
GPIO 3
GPIO_PXDAT = 100098
GPIO_PXIM = C7B13F98
GPIO_PXPE = F1A02100
GPIO_PXFUN = 27803F00
GPIO_PXSEL = 3FCEC067
GPIO_PXDIR = D0300090
GPIO_PXTRG = 384EC067
Cuando tenga un rato ya iré posteando las conclusiones. De momento se puede apreciar que cuando la salida es por LCD éste está configurado en modo SLCD (smart LCD, bit 31 de LCD_CFG puesto a 1) mientras que cuando la salida es a TV está configurado en modo "estándar".
En teoría ahí está toda la información necesaria para hacer una inicialización mínima de la CPU (de lo cual se encarga el loader secundario) y para configurar el kernel para que el framebuffer funcione sobre el LCD.
Joer, no entiendo ni un 1% de lo que has hecho pero vaya curradas que te pegas.
He encontrado el driver para de lcd pero no lo he podido descargar en rar, aunque tienen el fuente disponible y he hecho copy&paste de aqui:
http://read.pudn.com/downloads138/sourcecode/embed/588844/ili932x.h__.htm
http://read.pudn.com/downloads138/sourcecode/embed/588844/ili9325fb.c__.htm
http://read.pudn.com/downloads138/sourcecode/embed/588844/ili9325.c__.htm
Espero que sirva de algo :P
Ojo... no hay que calentarse la cabeza demasiado con el tema del LCD. El controlador ILI9325 tiene varios modos de funcionamiento y el código que enlazas tiene pinta de ser para el modo MCU ("bus de microcontrolador"), por lo que es de escasa o nula utilidad. En ese modo sí que tiene registros varios y tal.
Sin embargo, tal y como imaginaba, en la dingoo este LCD está conectado en modo SLCD o "smart LCD". No hay mucha información al respecto (ninguna, en realidad), pero por lo que sé en este modo el controlador se comporta como si fuera una simple SRAM, es decir, un buffer que representa la pantalla. La CPU de la dingoo se encarga de transferir de forma continuada los "pantallazos" desde la SDRAM al LCD, y todo ocurre automáticamente. Con todo esto lo que quiero decir es que no hay registros que configurar en el propio display, sino en el controlador LCD de la dingoo, al que hay que decirle poco más que el tamaño y configuración de esa "SRAM" que es el LCD.
En otro mensaje también comento que la cosa cambia en modo TV out, ya que aquí se trata de comunicarse con el CH7024 que genera la salida de vídeo compuesto y el interfaz es distinto, pero sigue siendo muy simple: es un "churro" de datos con señales de sincronismo horizontal y vertical. Aquí aunque el modelo de comunicaciones es igualmente simple (la CPU escupe datos contínuamente y el CH7024 los convierte a una señal de TV), es necesario configurar inicialmente algunos parámetros del CH7024 (tiempos de barrido y demás, para poder soportar PAL y NTSC, etc), pero eso se hace por un bus serie a parte (seguramente el I2C, he de confirmarlo).
< - >
Joer, no entiendo ni un 1% de lo que has hecho pero vaya curradas que te pegas.
Ummm... perdón. La verdad es que la idea es que el que sabe de qué va el asunto aproveche la información, pero entiendo que para los demás todo esto es un poco marciano. Voy a intentar ir explicando un poco mejor las cosas:
Llamar CPU al procesador de la dingoo es un poco incorrecto. En realidad es un SOC (system on a chip), es decir, un conjunto de CPU y periféricos (LCD, timers, PLL, I2C, etc). Estos periféricos se configuran y se usan mediante una serie de registros que ocupan posiciones de memoria. Por ejemplo, el registro EMC_DMCR está en la dirección 0xB3010080. En varios sitios del código fuente disponible en el FTP de Ingenic (el fabricante de la CPU... quiero decir del SOC) hay un fichero llamado jz4740.h en el que se encuentran definiciones para todas esas direcciones, de forma que utilizamos el nombre EMC_DMCR en lugar de la dirección 0xB3010080 que es mucho más difícil de recordar.
(Nota: normalmente todas esas definiciones junto con una explicación profusa de cómo funciona el periférico en cuestión y el propósito de cada bit de cada registro están en el manual del SOC, que no está disponible, por lo que hay que darse con un canto en los dientes por tener el código fuente ese y que además tenga algunos comentarios. Lo que hay en el FTP de Ingenic es el datasheet, que contiene las características generales del SOC, eléctricas, pines, etc... pero que no describe lo más mínimo su funcionamiento)
Lo que yo ye posteado es un listado de los valores leídos de un buen número de esos registros (aquellos que me interesan) obtenidos mediante un programa compilado a tal efecto con el SDK. Lo que comentaba como curiosidad es que los valores leídos de los registros de configuración del LCD son diferentes según la dingoo esté sacando la imágen por el LCD o por la salida TV, lo cual es lógico porque hay que configurar el hardware de forma distinta.
P- ¿Para qué necesito todo esto?.
R- Para correr un kernel de linux en la dingoo.
P- ¿Pero Ingenic no proporciona ya un kernel con soporte para este SOC?
R- Sí, pero hay que configurarlo en función de lo que se haya conectado externamente al SOC, sobre todo la memoria SDRAM, memoria flash (NAND en este caso), LCD y alguna cosa más. El firmware original realiza la configuración inicial de los periféricos que comunican con las memorias y con el LCD, de modo que examinando esos registros con un programa que corre bajo el firmware original podemos ver qué valores se han usado y deducir la configuración necesaria para el kernel de linux.
Además, hay algunos periféricos que deben ser configurados incluso antes de cargar el kernel, como es el caso del PLL (genera los distintos relojes para todo el SOC) y el bus al que está conectado la SDRAM, ya que si la SDRAM no es accesible difícilmente podremos cargar ahí el kernel.
P- ¿Qué es "alguna cosa más"?
R- Me refería sobre todo a GPIO (general purpose input/output), es decir, pines de salida. Aquí no se trata de periféricos como tal, sino a funciones auxiliares de control. Por ejemplo (me lo estoy inventando), imagina que el LCD que se ha usado, además de conectarse al SOC a través de los pines dedicados a tal efecto y que implementan el protocolo de transferencia de los pixels, tiene una "particularidad": un pin que enciende o apaga la retroiluminación. Aunque configuremos adecuadamente la comunicación con el LCD, como no averigüemos qué pin GPIO se usa para controlar la retroiluminación y lo inicialicemos para encenderla no vamos a ver nada.
Ademas de lo que me has dicho he visto que A600 posteo ya los drivers del LCD :(
Pero como soy un cansino, pues no me rindo [wei] y buscando una actualizacion del MPlayer en la pagina de ingenic primero me he bajado el de linux y claro eso no valia para nada, pero después he encontrado uno que se llamaba ucosii_bsp_mplayer_20080326.tgz (ftp://ftp.ingenic.cn/3sw/02rtos/01uCOS/ucosii_bsp_mplayer_20080326.tgz) así que me lo he bajado y nada mas abrir el README, me encuentro con esto:
This packet include following source:
1.ucos core code,just for test,not buissness use.
2.most driver of JZ4740,for free
3.some muti-media software
He seguido investigando y están los fuentes con los drivers para uCOS:
Audio i2c.c
Radio: FM_RD5807.h y FM_RD5807.c
i2c.c
Botones: key.c y key.h con algo que pone "__gpio_get_pin" (no se si buscas algo de esto sobre los GPIO)
LCD: slcd.c ¿es este el driver bueno? Con cosas como: "InitLCDgpio(void) y #define PIN_RESET_N (32*1+18) /* LCD_SPL: GP B18 */"
Luego RTC, touch y tpanel, que creo que a la Dingoo no se aplicaría
Sobre los GPIOS, esta el gpio.c con cosas como:
///* LCD display off */
//__gpio_as_output(GPIO_DISP_OFF_N);
//__gpio_clear_pin(GPIO_DISP_OFF_N);
//
///* No backlight */
//__gpio_as_output(94); /* PWM0 */
//__gpio_clear_pin(94);
bsp.h
#define GPIO_PW_I 97
#define GPIO_PW_O 66
#define GPIO_LED_EN 92
#define GPIO_DISP_OFF_N 93
jz4740.h
#define GPIO_PXPIN(n) (GPIO_BASE + (0x00 + (n)*0x100)) /* PIN Level Register */
#define GPIO_PXDAT(n) (GPIO_BASE + (0x10 + (n)*0x100)) /* Port Data Register */
#define GPIO_PXDATS(n) (GPIO_BASE + (0x14 + (n)*0x100)) /* Port Data Set Register */
#define GPIO_PXDATC(n) (GPIO_BASE + (0x18 + (n)*0x100)) /* Port Data Clear Register */
#define GPIO_PXIM(n) (GPIO_BASE + (0x20 + (n)*0x100)) /* Interrupt Mask Register */
#define GPIO_PXIMS(n) (GPIO_BASE + (0x24 + (n)*0x100)) /* Interrupt Mask Set Reg */
#define GPIO_PXIMC(n) (GPIO_BASE + (0x28 + (n)*0x100)) /* Interrupt Mask Clear Reg */
#define GPIO_PXPE(n) (GPIO_BASE + (0x30 + (n)*0x100)) /* Pull Enable Register */
/*
* LCD_D0~LCD_D17, LCD_PCLK, LCD_HSYNC, LCD_VSYNC, LCD_DE
*/
#define __gpio_as_lcd_18bit() \
do { \
REG_GPIO_PXFUNS(2) = 0x003fffff; \
REG_GPIO_PXSELC(2) = 0x003fffff; \
REG_GPIO_PXPES(2) = 0x003fffff; \
} while (0)
Aunque me digas que tampoco te vale de mucho yo voy a seguir, hasta que me digas que he encontrado el santo grial :spam:
Puck2099
30/04/2009, 12:29
Joe, este hilo es la bomba.
De verdad, me encanta leer estos "ataques" a bajo nivel, casi me dan ganas de comprar una Dingoo para trastear y todo :)
Joe, este hilo es la bomba.
De verdad, me encanta leer estos "ataques" a bajo nivel, casi me dan ganas de comprar una Dingoo para trastear y todo :)
Ya lo dije yo en un post de EOL, en la WIZ no hay nada que rascar porque todas las especificaciones son abiertas y trasparentes, pero aqui sí [wei]
Puck2099
30/04/2009, 12:58
Ya lo dije yo en un post de EOL, en la WIZ no hay nada que rascar porque todas las especificaciones son abiertas y trasparentes, pero aqui sí [wei]
Bueno, no te creas, a muchas posibilidades todavía no explotadas en la Wiz a través de los registros de la consola :angel1:
Aquí como dices tenéis el aliciente de la investigación e ingeniería inversa que también mola lo suyo [wei]
Bizkaitarra
30/04/2009, 13:01
Bueno, no te creas, a muchas posibilidades todavía no explotadas en la Wiz a través de los registros de la consola :angel1:
Aquí como dices tenéis el aliciente de la investigación e ingeniería inversa que también mola lo suyo [wei]
Pero si no tengo entendido mál con la wiz también se puede trastear para obtener el código de un juego no libre por ingeniería inversa. Así que nada, si es por trastear vamos a sacar el starcraft por ingenieria inversa :P
Puck2099
30/04/2009, 13:06
Pero si no tengo entendido mál con la wiz también se puede trastear para obtener el código de un juego no libre por ingeniería inversa. Así que nada, si es por trastear vamos a sacar el starcraft por ingenieria inversa :P
Bueno, pero eso no tiene nada que ver con la Wiz y el código que podrías sacar está en ensamblador de x86, así que de poco te iba a servir...
starcraft por ingenieria inversa :P
Off-Topic total: Con que se liberaran los fuentes del StarLite DS (http://www.youtube.com/watch?v=L9G_1EZWVwg) me conformaba, ¡¡estúpidas cartas de Cease&Desist!! :ametra:
Bizkaitarra
30/04/2009, 13:34
Bueno, pero eso no tiene nada que ver con la Wiz y el código que podrías sacar está en ensamblador de x86, así que de poco te iba a servir...
Bueno, más emoción, luego solo tienes que traducir instrucción de ensamblador x86 por instrucción equivalente del arm... diversión asegurada ;)
Ademas de lo que me has dicho he visto que A600 posteo ya los drivers del LCD :(
Pero como soy un cansino, pues no me rindo [wei] y buscando una actualizacion del MPlayer en la pagina de ingenic primero me he bajado el de linux y claro eso no valia para nada, pero después he encontrado uno que se llamaba ucosii_bsp_mplayer_20080326.tgz (ftp://ftp.ingenic.cn/3sw/02rtos/01uCOS/ucosii_bsp_mplayer_20080326.tgz) así que me lo he bajado y nada mas abrir el README, me encuentro con esto:
En serio, no perdáis más tiempo investigando lo que hay en el FTP de Ingenic. Yo ha me lo he mirado TODO con tranquilidad y sé lo que hay y para qué sirve.
He seguido investigando y están los fuentes con los drivers para uCOS:
Audio i2c.c
Radio: FM_RD5807.h y FM_RD5807.c
i2c.c
Botones: key.c y key.h con algo que pone "__gpio_get_pin" (no se si buscas algo de esto sobre los GPIO)
LCD: slcd.c ¿es este el driver bueno? Con cosas como: "InitLCDgpio(void) y #define PIN_RESET_N (32*1+18) /* LCD_SPL: GP B18 */"
Luego RTC, touch y tpanel, que creo que a la Dingoo no se aplicaría
Sobre los GPIOS, esta el gpio.c con cosas como:
///* LCD display off */
//__gpio_as_output(GPIO_DISP_OFF_N);
//__gpio_clear_pin(GPIO_DISP_OFF_N);
//
///* No backlight */
//__gpio_as_output(94); /* PWM0 */
//__gpio_clear_pin(94);
bsp.h
#define GPIO_PW_I 97
#define GPIO_PW_O 66
#define GPIO_LED_EN 92
#define GPIO_DISP_OFF_N 93
En efecto, todo eso constituye las "particularidades" del diseño de la placa de desarrollo para la que Ingenic proporciona el software, pero NO de la dingoo.
Como verás esos #define indican claramente que un pin GPIO se usa para activar/desactivar el display, pero eso no nos sirve de nada. El interfaz de datos principal de un LCD tiene que estar conectado por narices al controlador LCD del JZ4740, pero otras señales auxiliares del LCD de la dingoo como la retroiluminación, reset, etc... se pueden conectar a cualquier GPIO y dependen del diseño, y aunque los diseñadores no se suelen calentar la cabeza mucho y es bastante posible que todas estas cosas sean parecidas en la dingoo, te aseguro que no van a ser iguales.
Insisto: TODO lo que hay en el FTP de ingenic es software de soporte de las placas de desarrollo. Ahora bien, el JZ4740 es un SOC de propósito TAN específico que una de las placas de desarrollo que al parecer existen es, literalmente, un diseño de referencia para un PMP. La placa es la PAVO (mola el nombre).
Valeeee, aceptamos barco...
En cualquier caso como el proceso de brickeo/unbrickeo lo he asimilado bastante bien, aquí me tienes como "sujeto de experimentos 1" :shock:
·Muchas gracias por la traducción a lenguaje inteligible por el común de los mortales booboo.
Supongo que ya lo tendréis más que visto, pero vi unos pdfs con esquemás de PAVO (es tan buen nombre como el webOS de Palm :risas:) que creo podrían servir (no creo que hayan cambiado mucho la placa de la Dingoo respecto del PAVO:
ftp://ftp.ingenic.cn/4hw/02_RDK/RD4740_Pavo/hw/V1.3.1/sch_rd4740_pavo_v1.3.1.pdf
ftp://ftp.ingenic.cn/4hw/02_RDK/RD4740_Pavo/RD4740_Pavo-HW%201.2_EN.pdf
Y también seguro que habéis visto(jz-hacking):
http://code.google.com/p/jz-hacking/wiki/Index?tm=6
Espero no molestar, lo cierto es que el post vale más para darte las gracias que para otra cosa ^_^U
Edit: http://vm-kernel.org/
"# emulator
1. qemu-jz: jz4740 based pavo demo board emulator.
2. qemu-omap3: beagle board and omap3530 emulator.
3. simbcm: bcm1250 emulator
# virtualization
1. kvm-mips: KVM MIPS porting
# linux porting
1. jz-hacking: hack jz soc based devices."
Danielo515
04/05/2009, 00:49
Mecagoenla!! LLevo como 4 días entrando al foro y mirando solo en la portada buscando algo con respecto a la dingo, incluso algún día entré en el foro de otras consolas en busca de cosas de la dingo, y no se porqué me da hoy por entrar en el de gadets tecnológicos¡y me encuentro con esto! dios! ahora sí que tengo ganas de que me llegue el cacharro y fastidiar mi media de 9 en mis estudios XD. Habría sido más facil leerme esto en 4 días! ja ja ja, en fin, mala suerte buscando...
No son horas así que seré breve:
- Tengo identificadas la mayoría de funciones GPIO (cuando tenga un rato veré la forma de postearlo todo).
- He averiguado cómo configurar correctamente la SDRAM y la flash.
- He adaptado el u-boot (el que hay en el FTP de Ingenic) a la Dingoo.
- He arrancado un kernel linux de prueba. Es el que hay en el FTP de Ingenic configurado para la placa PAVO, así que evidentemente falla por todas partes, ahora simplemente hay que adaptarlo como he hecho con el u-boot.
Por cierto, estaba equivocado y a diferencia de lo que dije anteriormente, sí que hay que configurar registros del LCD, así que mis más sinceras disculpas a aquellos a los que haya confundido. Como ya sabéis Ingenic no proporciona drivers para el LCD IL9325, así que habrá que currarselo.
Por cierto, al que quiera hacer experimentos similares a lo que yo estoy haciendo, decirle que el FTP de Ingenic tiene un peligro que no veas. Hay cosas que están en un montón de sitios distintos, otras que no funcionan, etc. A parte del kernel de linux, lo más reciente y fiable parece ser el ucosii_0430.rar y usbboot1.4a-tools.zip. Este último es el que al final me ha servido para averiguar cómo inicializar el SOC, ya que incluye además del código fuente de la aplicación (para Windows) el código fuente de los programitas que se cargan por USB en RAM para llevar a cabo todo el proceso de inicialización y grabado de la flash.
El nand-boot que hay en el FTP de Ingenic directemente no funciona (no hace un __gpio_as_nand, entre otras cosas).
Aquí el kernel arrancando (insisto: configuración PAVO, así que falla casi todo)
U-Boot 1.1.6 (May 4 2009 - 04:13:34)
Board: Dingoo A320 (CPU Speed 336 MHz)
DRAM: 32 MB
Flash: 0 kB
NAND: 4096GiB
*** Warning - bad CRC or NAND, using default environment
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 3 0
A320 # bootm 0x81100000
## Booting image at 81100000 ...
Image Name: Linux-2.6.24.3
Image Type: MIPS Linux Kernel Image (gzip compressed)
Data Size: 1857876 Bytes = 1.8 MB
Load Address: 80010000
Entry Point: 80332440
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
Starting kernel ...
Linux version 2.6.24.3 (booboo@inspiron) (gcc version 4.1.2) #3 PREEMPT Mon May 4 04:13:56 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)
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: 27968k/32768k available (3230k kernel code, 4800k reserved, 790k data, 176k init, 0k highmem)
Mount-cache hash table entries: 512
net_namespace: 64 bytes
NET: Registered protocol family 16
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Time: jz_clocksource clocksource has been installed.
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
TCP reno registered
Total 4MB memory at 0x1400000 was reserved for IPU
Power Management for JZ
yaffs May 4 2009 04:10:24 Installing.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
jzlcd use 1 framebuffer:
jzlcd fb[0] phys addr =0x00480000
LCDC: PixClock:9333333 LcdClock:12923076
Console: switching to colour frame buffer device 60x34
fb0: jz-lcd frame buffer device, using 512K of video memory
JzSOC onchip RTC installed !!!
JzSOC: char device family.
Jz generic touch screen driver registered
JZ4740 SAR-ADC driver registered
UDC starting pnp monitor thread
JZ UDC hotplug driver registered
Serial: 8250/16550 driver $Revision: 1.5 $ 2 ports, IRQ sharing disabled
o•É¥…±á250: ttyS0 at MMIO 0x0 (irq = 9) is a 16550A
serial8250: ttyS1 at MMIO 0x0 (irq = 8) is a 16550A
RAMDISK driver initialized: 2 RAM disks of 4096K size 1024 blocksize
loop: module loaded
Jz CS8900A driver for Linux (V0.02)
eth%d: CS8900A rev ; detected
Linux video capture interface: v2.00
JzSOC Camera Interface Module (CIM) driver registered
Ingenic CMOS camera sensor driver registered
Driver 'sd' needs updating - please use bus_type methods
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 69 at 0x0022ff000
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 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 103 at 0x0033ff000
Bad eraseblock 104 at 0x00347f000
Bad eraseblock 105 at 0x0034ff000
Bad eraseblock 106 at 0x00357f000
Bad eraseblock 107 at 0x0035ff000
Bad eraseblock 108 at 0x00367f000
power cable insert!
Bad eraseblock 109 at 0x0036ff000
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 115 at 0x0039ff000
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 139 at 0x0045ff000
Bad eraseblock 207 at 0x0067ff000
Bad eraseblock 208 at 0x00687f000
Bad eraseblock 209 at 0x0068ff000
Bad eraseblock 225 at 0x0070ff000
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 4117 at 0x080aff000
Bad eraseblock 4118 at 0x080b7f000
Bad eraseblock 4239 at 0x0847ff000
Bad eraseblock 4240 at 0x08487f000
Bad eraseblock 4242 at 0x08497f000
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-ohci jz-ohci.0: JZ OHCI
jz-ohci jz-ohci.0: new USB bus registered, assigned bus number 1
jz-ohci jz-ohci.0: irq 3, io mem 0x13030000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
Initializing USB Mass Storage driver...
usb 1-1: new low speed USB device using jz-ohci and address 2
usb 1-1: device descriptor read/64, error -62
usb 1-1: device descriptor read/64, error -62
usb 1-1: new low speed USB device using jz-ohci and address 3
usb 1-1: device descriptor read/64, error -62
usb 1-1: device descriptor read/64, error -62
usb 1-1: new low speed USB device using jz-ohci and address 4
usb 1-1: device not accepting address 4, error -62
usb 1-1: new low speed USB device using jz-ohci and address 5
usb 1-1: device not accepting address 5, error -62
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
mice: PS/2 mouse device common for all mice
JzSOC Watchdog Timer: timer margin 60 sec
JZ SD/MMC card driver registered
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
JzSOC On-Chip I2S controller registered (DAC: DMA(play):4/IRQ36,
ADC: DMA(record):3/IRQ35)
JZ I2S OSS audio driver initialized
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Root-NFS: No NFS server available, giving up.
VFS: Unable to mount root fs via NFS, trying floppy.
VFS: Cannot open root device "<NULL>" or unknown-block(2,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00 3072 mtdblock0 (driver?)
1f01 3072 mtdblock1 (driver?)
1f02 117760 mtdblock2 (driver?)
1f03 120832 mtdblock3 (driver?)
1f04 241664 mtdblock4 (driver?)
1f05 503808 mtdblock5 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(2,0)
Danielo515
04/05/2009, 08:44
boobo, dios tío, eres un crack. Se nota que entiendes de lo que hablas ¿de donde sacas tanto conocimiento y en que cantidad de cerebros la metes?
Ver un linux corriendo en la dingo sería la hostia, yo creo que un avance en la scene brutal para una consola tan cerrada y minoritaria.... de momento.
Felicidades!
Y muchas gracias por dedicarle tanto y compartirlo
@booboo: supongo que conocerás el proyecto de ejecutar Linux (http://vm-kernel.org/blog/2009/02/24/linux-on-onda-vx747/) en el Onda747 (http://www.rockbox.org/twiki/bin/view/Main/OndaVX747)(prácticamente el mismo hardware que la Dingoo y similares)
Renuente
04/05/2009, 16:10
Grac ias por el curro booboo :brindis:
@booboo: supongo que conocerás el proyecto de ejecutar Linux (http://vm-kernel.org/blog/2009/02/24/linux-on-onda-vx747/) en el Onda747 (http://www.rockbox.org/twiki/bin/view/Main/OndaVX747)(prácticamente el mismo hardware que la Dingoo y similares)
Si. De hecho estoy utilizando su herramienta usbtool para cargar el kernel y demás desde linux.
En cuanto al hardware... la configuración GPIO me consta que es completamente diferente, así como el LCD, así que no sirve de mucho.
Eché un vistazo al kernel que han usado y llegué a la conclusión de que está basado en un "release" antiguo de Ingenic y que han hecho algunos cambios/fixes. Por lo primero prefiero usar lo de Ingenic y cuando ya tenga algo medio funcionando entonces analizar con cuidado los fixes que hicieron para el onda por si hay algo relevante.
Estoy ahora mismo intentando averiguar alguna cosa más del GPIO y mirando a ver cómo enfoco lo del LCD. El problema es que tanto el JZ4740 como el LCD tienen varios modos de interfaz y lo suyo es hacer tanta ingeniería inversa del software como sea posible para averiguar cómo están conectados, porque lo que es el hardware no vale la pena meterse si disponer de un aparato de rayos X.
Del exámen de los registros del JZ4740 sé que el LCD está conectado en modo SLCD. A modo de resumen diré que el modo LCD es para LCDs "tontos" que tienen drivers de pixel y poco más, mientras que el modo SLCD es para LCDs "inteligentes". Paradójicamente, hubiera preferido que estuviera en modo LCD porque mirando los registros del JZ4740 prácticamente lo tendría todo hecho. En cambio, el modo SLCD es muy simple desde el punto de vista del JZ4740 pero lo jodido está en configurar los registros del LCD, cuyo valor depende además de cómo esté conectado el display. En fin, todo un poema.
Me estoy pensando si intentar leer los registros del propio LCD o directamente desensamblar el A320_PD27_ILI9325_RLS.dl, y creo que voy a hacer esto último, porque así por lo menos averiguaré cuáles son las señales GPIO auxiliares involucradas en el control del LCD.
Son 11K, es viable, el problema es que yo no había visto una instrucción MIPS en la vida y estoy aprendiendo a marchas forzadas (y no me apetece).
El trabajo de booboo es impresionante y encima lo cuenta por aquí para que todos aprendamos. Muchísimas gracias.
Romenelen
04/05/2009, 17:35
Hola a todos. Este es mi primer post en este foro.
Me he registrado principalmente para daros las gracias por lo que estais haciendo. Tengo una Dingoo y estoy alucinando con lo que estais sacando para ella.
Tengo pequeñas nociones de electrònica (FPII de electricidad) y ninguna de programaciòn, pero habeis conseguido que me enganche sòlo por ver como avanzais en el desarrollo para este pmp. Gracias booboo por la explicaciòn de unos post atràs.
Un saludo y que no decaiga.
dreamfrank a la pregunta de como lee la dingo la información de una aplicación para que se pueda usar como un sim:
#ifndef WIN32
typedef struct tagSYMBOLENTRY
{
unsigned long address;
const char* name;
} SYMBOLENTRY;
#define DL_EXPORT_SYM(sym) \
__attribute__ ((section (".export_string"))) \
static const char _string_##sym[] = #sym;\
__attribute__ ((section (".export_table"))) \
static const SYMBOLENTRY _sym_##sym = { (unsigned long)&sym, _string_##sym };
/* file extension name */
int GetFileType(char* pname)
{
if (pname)
strcpy(pname, "NGC");
return 0;
}
/* to get defualt path */
int GetDefaultPath(char* path)
{
if (path)
strcpy(path, "A:\\GAME");
return 0;
}
/* module description, optional */
int GetModuleName(char* name, int code_page)
{
if (name && (0 == code_page)) // ansi
strcpy(name, "szNeoPop760.SIM");
return 0;
}
DL_EXPORT_SYM(GetFileType)
DL_EXPORT_SYM(GetDefaultPath)
DL_EXPORT_SYM(GetModuleName)
#endif /* WIN32 */
Con mucha paciencia de desensamblado el fichero A320_PD27_ILI9325_RLS.dl y creo que ya tengo toda la secuencia de configuración GPIO para el LCD y, lo que es más importante, los valores de inicialización de los registros del propio LCD.
Con eso debería tener suficiente para modificar el driver SLCD del kernel de Ingenic y que el framebuffer funcione, aunque casi que primero lo pruebo "a pelo" usando el usbtool.
No creo que tenga tiempo de hacer nada de esto en lo que queda de semana, así que que nadie contenga la respiración.
(...)
No... si al final sólo es cuestión de prescindir del sueño y tal.
http://img22.imageshack.us/img22/4320/06052009083.jpg (http://img22.imageshack.us/my.php?image=06052009083.jpg)
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?
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?
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
Rivroner
06/05/2009, 07:55
No tengo una Dingoo ni me la pienso comprar pero, ¡Booboo, ole tus webos tío :D!
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 [wei], 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 :starw:
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/
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 :D!
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 [wei], 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 :starw:
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).
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 [wei]
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 :llorosa:
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 :rever: :rever: :rever: :rever: :rever: :rever:
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 :brindis:
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
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 [wei]
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 :llorosa:
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).
http://img50.imageshack.us/img50/4498/annotated.jpg (http://img50.imageshack.us/my.php?image=annotated.jpg)
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 :brindis:
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).
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).
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.
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" :D
booboo eres el de siempre? si es asi me has sorprendido estas hecho un crack
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.
booboo eres el de siempre? si es asi me has sorprendido estas hecho un crack
creo que lo estas confundiendo con otro.... xd
creo que lo estas confundiendo con otro.... xd
Ostrás, no caía hasta que lo has dicho...
gasancoooooooooo
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.
http://www.youtube.com/watch?v=3YyINLtEdR0
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
tal y como está ahora cubre todos mis conocimientos linuxeros, mount, cd y ls es de lo poco que se usar, y para colmo con el mount nunca me aclaro con cual dispositivo hay que montar XDDDDDD (o no monto nada, o monto el dispositivo que no es).
Joe macho si me tocan los euromillones, mañana te subvenciono[wei]
Bueno, al lío, lo de que no tenía RTC supongo que malinterprete lo que leí, y se referían a que no tiene HW para controlar el resto de la máquina cuando está apagada, es decir, que pongas una alarma y todos los días a las 8:00AM se encienda la consola sola y comience a reproducir un MP3 por ejemplo como hacen muchos móviles.
Sobre lo del interfaz, pues como te dije no tengo ni idea de dispositivos empotrados y de que es prioritario usar los recursos mínimos, así que mi pregunta es la siguiente, para no meter la pata de nuevo.
Si yo me cojiera el jz-crosstools y el mipseltools-gcc412-glibc261 de Ingenic, ¿podría ponerme a compilar las SDL para el futuro linux de la dingoo? ¿podría compilar también cualquier aplicación que usara framebuffer? ¿o es mejor coger directamente una debian-mipsel y tirar con binarios precompilados?
Joe macho si me tocan los euromillones, mañana te subvenciono[wei]
Bueno, al lío, lo de que no tenía RTC supongo que malinterprete lo que leí, y se referían a que no tiene HW para controlar el resto de la máquina cuando está apagada, es decir, que pongas una alarma y todos los días a las 8:00AM se encienda la consola sola y comience a reproducir un MP3 por ejemplo como hacen muchos móviles.
De lo que pone en el datasheet yo interpreto que el JZ4740 sí que tiene esa función. El problema es el hardware auxiliar. Me explico:
No me he metido a investigar a fondo cómo funciona el módulo RTC del JZ4740, y no voy a hacerlo de momento, así que hablaré de la experiencia que tengo acerca de cómo funcionan este tipo de dispositivos en muchos otros microcontroladores:
- El RTC forma parte de un dominio de alimentación separado del resto. Si el ingeniero de turno lo hizo todo bien, sigue funcionando aunque el resto de la CPU esté en en halt (alimentada pero consumiendo muy poco). En muchos micros es incluso posible quitar la alimentación al resto de la CPU.
- El RTC dispone de una función de alarma, gracias a la cual puede programarse para que haga una de estas dos cosas (o las dos): generar una interrupción o cambiar el estado de un pin de salida (esto último lo he visto MUY poco).
- Si lo que puede hacer es la interrupción, entonces la forma de reanudar el sistema a una hora dada consiste en poner la CPU "a dormir" y que la interrupción la despierte. Dependiendo de lo "profundo" del modo de sueño este desperar puede ser un reset o una reanudación de la ejecución donde lo dejó. Evidentemente cuanto más "profundo" sea el sueño menor consumo.
- Si lo que puede hacer es cambiar el estado de un pin, entonces con ayuda de poco más que unos transistores externos se puede hacer que la CPU tenga capacidad para "apagarse" ella misma la alimentación y "reconectarla" usando este pin especial a la hora programada. Evidentemente el "despertar" es siempre un reset y el consumo mientras "duerme" es ridículo, en realidad sólo lo que consuma el propio módulo RTC.
Como ya he dicho, esto último lo he visto sólo en micros muy recientes, por lo que lo más seguro es que sea lo otro. Además requiere como ya he dicho hardware externo y un diseño muy cuidadoso (que, sin ánimo de polemizar, no es habitual en los chinos). Y además ese consumo "ridículo" inherente a tener la CPU sin alimentar en absoluto sólo es necesario literalmente en sistemas que tienen que funcionar años enteros con una batería.
Así que creo que la dingoo seguramente funcionará de la primera forma. Por ota parte, estoy CASI seguro de que la dingoo tiene capacidad para "quitarse" a sí misma la alimentación por software (*), y que cuando la apagas realmente la CPU no está alimentada en absoluto. También estoy casi seguro de que o el RTC no tiene capacidad para activar la alimentación o no lo han implementado. Por lo tanto para tu aplicación de alarma la A320 debería estar encendida (aunque en modo de bajo consumo).
(*) Lo deduzco porque hay un pin GPIO que está conectado al botón de on/off, y porque cuando dejas colgada a la consola (que me ha pasado mucho mientras programaba la initialización del hardware) el botón deslizante de apagado no funciona (luego el apagado es por software).
Sobre lo del interfaz, pues como te dije no tengo ni idea de dispositivos empotrados y de que es prioritario usar los recursos mínimos, así que mi pregunta es la siguiente, para no meter la pata de nuevo.
Si yo me cojiera el jz-crosstools y el mipseltools-gcc412-glibc261 de Ingenic, ¿podría ponerme a compilar las SDL para el futuro linux de la dingoo?
Sí. El "curro" estaría principalmente en:
- Configurar adecuadamente la SDL para que soporte sólo framebuffer y alsa/oss (aún no se cuál de los dos utilizaré en el kernel... creo que ya hablé del tema en otro mensaje).
- Hacer el compilado cruzado: normalmente si lo que vas a compilar está bien hecho (y la SDL lo está) ya te da alguna opción para especificar el compilador cruzado que hay que utilizar (se especifica el prefijo, que en este caso sería "mipsel-linux-". Si no, tienes que trastear con el sistema de build. Como digo, no creo que sea el caso de la SDL, pero no puedo asegurarlo.
¿podría compilar también cualquier aplicación que usara framebuffer? ¿o es mejor coger directamente una debian-mipsel y tirar con binarios precompilados?
Pues no lo puedo afirmar con seguridad, porque hasta ahora todo lo que he corrido en la A320 lo he compilado yo mismo (busybox), pero estoy casi seguro (referencia: linux para el onda VXnosqeué) de que cualquier binario debian-mipsel funcionará. Otra cosa es que por lo que sea interese compilar con opciones especiales el binario en cuestión (estoy pensando en el mplayer, en el que incluiría únicamente el soporte de framebuffer para adelgazarlo mucho, ya que soporta una burrada de tipos de salida de video).
creo que lo estas confundiendo con otro.... xd
a vale , pensaba que era MR gasanco por eso lo decia , digo si que ha cambiado este chaval jeje
sigue asi booboo
Vaya, así que lo de Alarma/Calendario de momento nada.
Bueno, con respecto a lo del SDL le echaré un vistazo. Yo personalmente me decidiría por ALSA que es un driver más moderno y OSS está casi obsoleto, lo que no sé es si ALSA es más pesado que OSS.
El mplayer también lo provee Ingenic para linux, con lo que supongo son optimizaciones para su CPU, ademas es una versión moderna "MPlayer-1.0rc2-20090218"
Madre mía booboo, en unos días has armado un mini Linux para la consola con cero de información del fabricante. Veo que tanto Alsa como Oss son drivers de sonido, pero creo que lo prioritario sería implementar las funciones básicas de vídeo usando las librerías del soft3d. No creo que el Linux de Ingenic implemente el acceso específico al framebuffer de la Dingoo. A no ser que hayáis sacado ya los registros para escribir en la pantalla. Si he dicho algo raro me lo decís.
Madre mía booboo, en unos días has armado un mini Linux para la consola con cero de información del fabricante. Veo que tanto Alsa como Oss son drivers de sonido, pero creo que lo prioritario sería implementar las funciones básicas de vídeo usando las librerías del soft3d. No creo que el Linux de Ingenic implemente el acceso específico al framebuffer de la Dingoo. A no ser que hayáis sacado ya los registros para escribir en la pantalla. Si he dicho algo raro me lo decís.
Te debes haber saltado unos cuantos mensajes. El framebuffer era al mismo tiempo lo más complicado y lo más prioritario pero después de muchas horas de sueño perdido ya está resuelto. De hecho ayer colgué un video de linux arrancando en el framebuffer.
En teoría a día de hoy ya se podría usar la SDL para acceder a pantalla, y con ella cualquier programa que la use. Aunque falta por supuesto el sonido y el teclado (esto último es muy fácil pero voy a meterme primero con el sonido).
Una vez funcionen video, audio y teclas ya se tiene un Linux lo suficientemente funcional como para empezar a portar cosas para él (asi dicho parace que fuera poca cosa XDDDD).
Una vez funcionen video, audio y teclas ya se tiene un Linux lo suficientemente funcional como para empezar a portar cosas para él (asi dicho parace que fuera poca cosa XDDDD).
Teclado, olvidas el teclado, que he estado mirando esta mañana y es casi trivial.
Estoy buscando la forma de ordenar y publicar toda la información, seguramente en un wiki, pero me va a llevar algo de tiempo por cuestiones que no vienen al caso.
Teclado, olvidas el teclado, que he estado mirando esta mañana y es casi trivial.
Estoy buscando la forma de ordenar y publicar toda la información, seguramente en un wiki, pero me va a llevar algo de tiempo por cuestiones que no vienen al caso.
¿pero que utilidad tiene dar soporte a teclado si no tiene un puerto para enchufarlo? ¿es necesario para teclear via terminal? A mi por lo pornto se me ocurre que podría ser util un teclado virtual manejado con el pad como el sterm de la gp2x (o algo similar al sistema de grabar iniciales en los arcades antiguos para mas datos).
¿pero que utilidad tiene dar soporte a teclado si no tiene un puerto para enchufarlo? ¿es necesario para teclear via terminal? A mi por lo pornto se me ocurre que podría ser util un teclado virtual manejado con el pad como el sterm de la gp2x (o algo similar al sistema de grabar iniciales en los arcades antiguos para mas datos).
Tiene un usb que se puede usar para enchufar dispositivos si no me equivoco, yo con un menú clásico con sus iconcitos me apaño, para desarrollar y testear cosas si que es practico aunque lo seria mas configurar el usb como red y teclear desde el pc por telnet/ssh.
Menudo curro te estás pegando booboo !!
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.
·Era éso en lo que estaba pensando, pero como bien dices habrá que ver cómo se comporta la peque.
Muchas gracias por esas contestaciones tan extensas, yo iba a comentarte que habían distros de mips aquí: http://www.linux-mips.org/wiki/Distributions pero creo que ya lo tendrás más que visto.
Jamás había oído hablar de Busybox hasta hoy.
¿pero que utilidad tiene dar soporte a teclado si no tiene un puerto para enchufarlo? ¿es necesario para teclear via terminal? A mi por lo pornto se me ocurre que podría ser util un teclado virtual manejado con el pad como el sterm de la gp2x (o algo similar al sistema de grabar iniciales en los arcades antiguos para mas datos).
Me he expresado mal. Cuando he dicho "teclado" me refería a las techas que tiene la A320. El subsitema de input de linux tiene que reconocer las pulsaciones y generar los correspondientes eventos para que puedan ser leídos por los programas de usuario.
La idea que llevo es "mapear" cada uno de los botones a una tecla estándar, a ser posible una que tenga sentido: el joypad a las flechas, el botón A a la tecla que suelen usar los emuladores como botón A, etc... así el kernel se encarga de todo y desde el punto de vista de las aplicaciones lo único que pasa es que hay un teclado al que le faltan la mayoría de las teclas. En lo relativo al teclado lo único que habría que modificar de un emulador determinado serían todas aquellas funciones que se controlen con una tecla que no esté disponible en la A320.
Lo de tener un teclado virtual lo veo poco útil dadas las características de la consola. El propósito de todo este fregado es única y exclusivamente tener un entorno ejecución linux, de forma que el portado de emuladores y otras aplicaciones sea lo más sencillo y directo posible, y de paso, la gente pueda programar aplicaciones nuevas rápidamente y con los conocimientos que ya tiene.
Este es el plan:
1- Kernel funcionando con soporte completo de hardware y un rootfs mínimo.
2- Aplicación "principal" que sustituya a la del firmware y que proporciona el menú de reproducción, configuración, ejecución de aplicaciones, etc.
3- Emuladores y todo lo demás (lanzados por la aplicación "principal").
En cuanto tenga el soporte de hardware a medias, ya puede alguien ponerse a trabajar en la aplicación principal (yo no creo que pueda, además de que no es mi especialidad), y también en portar emuladores y demás.
Es evidente que al principio sin la aplicación "principal" lista la A320 sería poco usable a nivel general, pero ¿qué mas dá?... si logramos hacer un arranque dual no cuesta nada arrancar en linux y con un menú patatero lanzar un emulador o lo que sea. Siempre será mejor poder usar un emulador de esa forma que no poder en absoluto (o tener que portarlo usando el SDK de Dingoo).
Por cierto... respecto a la aplicación "principal" sugiero reutilizar diseños e ideas existentes, por ejemplo rockbox. Ahora que lo menciono seguramente alguien se preguntará por qué no he ido directamente a intentar portar rockbox a la dingoo. La respuesta es que rockbox es un firmware monolítico que está muy bien para dispositivos de potencia limitada como los reproductores mp3, pero que creo que se queda corto para la Dingoo. Y además Ingenic proporciona gran parte del trabajo hecho con linux, mientras que con rockbox hay que rehacerlo todo (aunque tener el código para linux es una excelente referencia).
< - >
Tiene un usb que se puede usar para enchufar dispositivos si no me equivoco, yo con un menú clásico con sus iconcitos me apaño, para desarrollar y testear cosas si que es practico aunque lo seria mas configurar el usb como red y teclear desde el pc por telnet/ssh.
En efecto, tiene un puerto USB que puede funcionar en modo host (como un PC), pero eso requiere de un hub externo con alimentación propia, ya que la A320, a diferencia de un PC, no proporciona los +5V del puerto USB.
Hay soluciones más sencillas que ya he estado explorando: el hardware USB de la A320 soporta lo que en linux se llama "modo gadget", que no es más el el modo "periférico". Linux implementa varios tipos de periférico: CDC ACM, ethernet y almacenamiento masivo entre otros.
1- CDC ACM: es algo más complicado pero se puede resumir en que es un puerto serie sobre USB. Cuando conectas la A320 a un PC con linux aparece el dispositivo /dev/ttyACM0. Lanzas el minicom y listo, ya tienes acceso por terminal (en la A320 tiene que estar corriendo getty sobre /dev/ttygserial).
Insisto: esto ya lo he probado y funciona perfectamente. La pega es que sólo proporciona un puerto serie Y NADA MÁS. Para transferir ficheros habría que recurrir a un protocolo sobre puerto serie (xmodem, zmodem, etc) o usar la miniSD.
Nota: sobre un sólo puerto serie se pueden tener varios pseudoterminales usando la aplicación screen.
2- Ethernet: en la dingoo aparece un interfaz de red llamado usb0, y cuando la conectas a un PC con linux debería aparecer como un adaptador ethernet USB (digo "debería" porque en la prueba rápida que he hecho esta mañana no ha sido así...). A partir de ahí configuras los interfaces de red de la forma apropiada y a hacer telnet, ssh o lo que sea.
Esta opción tiene un problema: hay que habilitar el soporte de red en el kernel, lo cual lo "engorda" mucho (pero mucho mucho, aunque se ponga lo mínimo) consumiendo un recurso escaso de la A320 que es la RAM.
La principal ventaja es que sobre la red así construida se puede hacer de todo y simultáneamente (transferir archivos con FTP o SCP, tener varios terminales abiertos, etc).
3- Este modo gadget hace a la dingoo visible para el PC como uno o varios dispositivos de almacenamiento, de forma similar a como hace el firmware original. Aquí obviamente podemos transferir archivos sin problemas, pero nada de terminal.
Y alguien se preguntará ¿no se puede configurar el kernel para que la A320 se comporte como un dispositivo compuesto ("composite"), siendo al mismo tiempo una línea serie CDC ACM y un dispositivo de almacenamiento masivo?.
Pues en teoría sí, pero hay que desarrollar el driver. En el kernel de que dispongo (2.6.24.3) hay que hacerlo casi todo. En el kernel maś reciente (2.6.28.x) este asunto está más avanzado y es más sencillo de hacer, ya que han separado cada gadget en una capa que gestiona el USB y otra que implementa la funcionalidad, de forma que escribir un driver gadget compuesto se hace reutilizando las funcionalidades existentes (con la notable excepcción del almacenamiento masivo... aaaaaarrg!!!). Portar toda la faena de Ingenic al último kernel es inviable, y "portar hacia atrás" los drivers gadget del último kernel al de Ingenic tampoco es sencillo.
Así que creo que de momento la forma de desarrollar para linux en una A320 sin consola RS232 como la mía va a ser mediante un terminal serie CDC ACM, transfiriendo los archivos con zmodem o con miniSD. Más adelante quizás me plantee hacer el dispositivo compuesto para el kernel 2.6.24.3, o MEJOR AÚN, quizás alguien lo haga por mí aunque paradójicamente con esto precisamente sí que es IMPRESCINDIBLE una A320 con consola RS232 como la mía (no puedes depurar el funcionamiento del dispositivo compuesto a través de una consola vía CDC ACM en el propio dispositivo compuesto).
Si se me ocurre alguna otra alternativa ya lo comentaré.
Menudo curro te estás pegando booboo !!
Compartiendo aprendemos y ganamos todos. Y como ya he dicho me lo estoy pasando teta.
< - >
Jamás había oído hablar de Busybox hasta hoy.
Yo llevo haciendo electŕonica y programación para sistemas empotrados muchos años y los últimos han sido con versiones empotradas de linux. Busybox es un conjunto de aplicaciones estándar de línea de comandos pensadas para sistemas empotrados. El objetivo es consumir el mínimo de recursos y ocupar el mínimo de espacio. Están todas las aplicaciones básicas necesarias: sheel, ls, telnet, find, cp... hay literalmente cientos. Todas compiladas en un ejecutable monolítico (el que he compilado para la dingoo ocupa 2MB con la libc incluida, es decir, un ejecutable totalmente estático).
Si tuvieras que instalar una or una las aplicaciones te puedes ir perfectamente a 20-40MB que no están disponibles en casi ningún sistema empotrado. La A320 en realidad es una excepción porque al ser un media player necesariamente cuenta con mucho espacio de almacenamiento. En cualquier caso siempre es mejor el busybox porque las aplicaciones consumen espacio en disco, pero cuando corren también consumen RAM, así que cuanto más pequeñas sean mejor.
Ah, entonces es que no me habías leído XDDDDDD
Una vez funcionen video, audio y teclas...
En cuanto a lo que dices del entorno principal/lanzador de aplicaciones; creo que se podría portar el Gmenu2x (supongo que habrá código fuente disponible o si no se podrá pedir al autor), es una alternativa muy configurable bonita y con un consumo de recursos realmente pequeño.
Así da gusto (y envidia, sana, pero envidia xD), gracias booboo por hacer tan interesante y aleccionador este hilo :brindis:
2- Ethernet: en la dingoo aparece un interfaz de red llamado usb0, y cuando la conectas a un PC con linux debería aparecer como un adaptador ethernet USB (digo "debería" porque en la prueba rápida que he hecho esta mañana no ha sido así...). A partir de ahí configuras los interfaces de red de la forma apropiada y a hacer telnet, ssh o lo que sea.
Esta opción tiene un problema: hay que habilitar el soporte de red en el kernel, lo cual lo "engorda" mucho (pero mucho mucho, aunque se ponga lo mínimo) consumiendo un recurso escaso de la A320 que es la RAM.
La principal ventaja es que sobre la red así construida se puede hacer de todo y simultáneamente (transferir archivos con FTP o SCP, tener varios terminales abiertos, etc).Una duda respecto a este punto del que hablas ¿esto sería así incluso aunque configures el kernel para que lo compile como módulo y lo cargue bajo demanda, es decir, cuando se conecte el USB para usarlo en modo CDC Ethernet? Lo pregunto porque si fuera así, como módulo, supongo que no habría problema, aunque si lo dices porque habría que trabajar casi necesariamente con un kernel Linux monolítico (como supongo que estás haciendo ahora) entonces si que sería problema el consumo extra de RAM por compilar el soporte de red del kernel.
Una cosilla, ¿ha visto alguien si hay alguna razón de hardware por la que el problema de los botones B/Y exista?
La idea que llevo es "mapear" cada uno de los botones a una tecla estándar, a ser posible una que tenga sentido: el joypad a las flechas, el botón A a la tecla que suelen usar los emuladores como botón A
Solo para aportar mi granito de arena en esto: en muchas consolas el teclado (joypad, botones) está mapeado no a un teclado normal sino a un dispositivo joystick permanentemente enchufado a la consola. Si lo haces así será más fácil portar los emuladores de otras consolas portátiles que ya están preparados para leer de un joystick.
De todas maneras, cambiar en los emuladores "lectura de joystick" a "lectura de teclado" no es nada difícil. Si te es más fácil mapear los botones a un teclado con menos teclas que a un joystick, pues que sean los programadores de emuladores los que trabajen :D
En cuanto a lo que dices del entorno principal/lanzador de aplicaciones; creo que se podría portar el Gmenu2x (supongo que habrá código fuente disponible o si no se podrá pedir al autor), es una alternativa muy configurable bonita y con un consumo de recursos realmente pequeño.
Gracias chipan, ayer me tiré todo el día buscando GUIs SDL incluso echando un vistazo al rockbox para ver si es suficientemente modular como para sacar el interfaz exclusivamente.
Afortunadamente GMenu2x (http://gmenu2x.sourceforge.net/page/GMenu2X) es libre y esta disponible en SourceForge :)
<->
Tu que sabes booboo, ¿como sería de pesado usar el sw_suspend y como de útil o inútil?
Puede que no sea posible, o incluso que sea solo un par de segundos mas rápido que un arranque normal, por eso lo pregunto.
Solo para aportar mi granito de arena en esto: en muchas consolas el teclado (joypad, botones) está mapeado no a un teclado normal sino a un dispositivo joystick permanentemente enchufado a la consola. Si lo haces así será más fácil portar los emuladores de otras consolas portátiles que ya están preparados para leer de un joystick.
No estoy nada de acuerdo. Hay muchos juegos/emus que no tienen soporte para joystick y puede llegar a ser un coñazo añadírselo. Las SDL de la GP32 usaban el método comentado por booboo y no podía ser más cómodo o yo, por ejemplo, para la Xbox uso un wrapper de pad -> teclado y/o ratón que me permite emular el teclado/ratón añadiendo una sóla línea de código.
No estoy nada de acuerdo.
Bueno, en realidad pensaba en juegos y emus de la Gp2x, donde tanto la SDL como la minilib mapean los controles como un joystick cualquiera :D
De todas formas es verdad que desde el punto de vista del programador da prácticamente igual una forma o la otra. Pero si se mapea como joystick, los programas de la Gp2x serán más fáciles de portar :)
Ah, entonces es que no me habías leído XDDDDDD
En cuanto a lo que dices del entorno principal/lanzador de aplicaciones; creo que se podría portar el Gmenu2x (supongo que habrá código fuente disponible o si no se podrá pedir al autor), es una alternativa muy configurable bonita y con un consumo de recursos realmente pequeño.
En efecto, el código fuente está disponible. Parece la mejor alternativa.
Ayer hice un intento rápido con el sonido que me sirvió para, de entrada, saber que el soporte OSS del kernel de ingenic no funciona (gran petada cuando accedes al dispositivo), así que el debate OSS ("legacy" pero más compacto, no soporta audio simultáneo de varias aplicaciones, cosa que en la A320 no es problema) versus ALSA (default a día de hoy, más pesado, audio simultáneo) ya está zanjada. Ahora he de hacer funcionar ALSA. Ya he compilado libid3tag, libmad y madplay para la A320, pero tengo algún problema con la librería libasound que supongo que solucionaré rápidamente en cuanto tenga tiempo de sentarme con la A320. A ver si pronto puedo colgar un vídeo del madplay reproduciendo un mp3.
< - >
Así da gusto (y envidia, sana, pero envidia xD), gracias booboo por hacer tan interesante y aleccionador este hilo :brindis:Una duda respecto a este punto del que hablas ¿esto sería así incluso aunque configures el kernel para que lo compile como módulo y lo cargue bajo demanda, es decir, cuando se conecte el USB para usarlo en modo CDC Ethernet? Lo pregunto porque si fuera así, como módulo, supongo que no habría problema, aunque si lo dices porque habría que trabajar casi necesariamente con un kernel Linux monolítico (como supongo que estás haciendo ahora) entonces si que sería problema el consumo extra de RAM por compilar el soporte de red del kernel.
En principio no hay problema en utilizar módulos en el kernel. Hay dos opciones, o se tiene un kernel mínimo que lleve un initrd empotrado que cargue los módulos necesarios para acceder al soporte donde está el rootfs, lo monte y haga el pivot_root, o bien se tiene un kernel mínimo pero con esos módulos compilados monolíticamente. Lo segundo es más sencillo, y además lo primero no tiene sentido en un entorno donde las opciones de arranque son prácticamente invariantes.
La PEGA es que habilitar la carga dinámica de módulos ya engorda el kernel en 300K (de código, más la RAM necesaria que imagino que no será mucha). A eso súmale otros 300K de código más bastante RAM para el soporte mínimo de red.
Ir cargando módulos en un sistema como la A320, donde el hardware es invariante y no hay eventos "hotplug", no tiene sentido excepto para desarrollo. Por eso yo soy partidario de tener un kernel lo más compacto y ligero posible. Sin embargo, eso complica el desarrollo de drivers hardware e impide la comunicación vía ethernet, por lo que creo que la mejor opción es tener un sistema de arranque que permita seleccionar a) firmware original, b)kernel normal c) kernel desarrollo.
Voy a empezar a trabajar YA en un un firmware original modificado para que en lugar de cargar directamente el ccpmp cargue el u-boot y éste a su vez pueda lanzar el firmware original o un kernel/rootfs en la miniSD. Creo que se ma ha ocurrido una forma de hacerlo bastante sencilla y que se instalaría como cualquiera de los firmwares "custom" que han salido ya.
< - >
Una cosilla, ¿ha visto alguien si hay alguna razón de hardware por la que el problema de los botones B/Y exista?
Ah!... comprobé el asunto pero se me olvidó comentarlo por aquí.
No es un problema de hardware. El hardware puede leer perfectamente y de forma totalmente independiente los dos botones. De hecho hay un pin GPIO dedicado para cada botón de forma independiente.
Por lo tanto es un puñetero bug. Y además me atrevo a aventurar que debe ser un bug tonto y muy fácil de arreglar, pero ya sabéis cómo son los chinos para estas cosas.
< - >
Solo para aportar mi granito de arena en esto: en muchas consolas el teclado (joypad, botones) está mapeado no a un teclado normal sino a un dispositivo joystick permanentemente enchufado a la consola. Si lo haces así será más fácil portar los emuladores de otras consolas portátiles que ya están preparados para leer de un joystick.
De todas maneras, cambiar en los emuladores "lectura de joystick" a "lectura de teclado" no es nada difícil. Si te es más fácil mapear los botones a un teclado con menos teclas que a un joystick, pues que sean los programadores de emuladores los que trabajen :D
Interesante idea. No lo sabía. Me costaría un pelín más que lo del mapeo de teclas porque Ingenic ya proporciona un driver para esto, mientras que tendría que hacer yo el de joystick (que es simple en todo caso).
Sin embargo, salvo que haya algo que se me escape, me da a mí que lo de las teclas es más práctico, ya que absolutamente TODOS los emuladores deben tener soporte para teclado, mientras que quizás haya alguno que no tenga soporte de joystick. Por otra parte se me ocurre que en los emuladores siempre será necesario poder reconfigurar los mapeos de teclas a gusto del usuario... ¿se puede hacer esto con los botones del joystick? (no he usado muchos emuladores, y nunca ninguno con joystick).
< - >
Tu que sabes booboo, ¿como sería de pesado usar el sw_suspend y como de útil o inútil?
Puede que no sea posible, o incluso que sea solo un par de segundos mas rápido que un arranque normal, por eso lo pregunto.
TIENE que ser posible, simplemente porque el firmware original lo hace. Otra cosa es que sea complicado de dilucidar cómo funciona el hardware o que la función de suspend no esté bien implementada en alguno de los drivers de Ingenic (esto es lo que más miedo me da). En cualquier caso todo esto es solventable con tiempo y paciencia.
En cuanto a su utilidad, un firmware basado en linux que SUSTITUYA el firmware original DEBE implementar la función suspend. Aunque sólo tarde 5 segundos en cargar, es una eternidad comparado con la respuesta instantánea del suspend.
< - >
Bueno, en realidad pensaba en juegos y emus de la Gp2x, donde tanto la SDL como la minilib mapean los controles como un joystick cualquiera :D
De todas formas es verdad que desde el punto de vista del programador da prácticamente igual una forma o la otra. Pero si se mapea como joystick, los programas de la Gp2x serán más fáciles de portar :)
¿Qué tal un mapeo simultáneo y/o configurable?. No lo sugeriría si lo del joystick no me pareciera, a priori, relativamente sencillo de hacer.
¿Qué tal un mapeo simultáneo y/o configurable?. No lo sugeriría si lo del joystick no me pareciera, a priori, relativamente sencillo de hacer.
De todas formas, haz lo que te parezca más fácil en espacio de kernel, que ya tienes bastante trabajo. Cambiar de botones a teclado en los emuladores y programas será la parte fácil de cualquier port. Y además la práctica totalidad de emuladores y juegos de PC tienen entrada por teclado y no por joystick.
Hola,
Estoy intentando conseguir el arranque dual. Sobre el ccpmp.bin sé que:
1- Se carga en 0x80004000.
2- El tamaño de datos a cargar está en el segundo DWORD.
3- Una vez cargado, el loader salta a la posición 0x80004008.
El ccpmp.bin completo ocupa 5MB, pero sólo algo más de 2MB están ocupados. El resto está libre para poner lo que queramos, aunque sólo se cargará si se modifica adecuadamente segundo DWORD. He comprobado que poniendo 0x00500000 (=5MB) en el segundo DWORD todo sigue funcionando correctamente.
La estrategia es:
1- Portar u-boot y configurarlo para que carge un kernel y un root filesystem de la miniSD. Esto ya está hecho y funciona perfectamente si cargo directamente este u-boot en memoria y lo ejecuto.
2- Modificar el u-boot para que su dirección de carga sea 0x80404000 (0x80004000 + 4MB).
3- "Incrustar" el u-boot en el offset +4M del archivo, lo que equivaldría una vez cargado en memoria a la posición 0x80404000, que es para lo que he compilado el u-boot.
4- Parchear las primeras instrucciones de ccpmp.bin en 0x80004008 con un salto a la posición donde estará cargado el u-boot (0x80404000).
5- En esa posición poner un código ASM que compruebe el estado de una tecla: si no está pulsadan ejecuta las instrucciones que se parchearon y salta otra vez al ccpmp.bin, con lo que el sistema debería arrancar de nuevo. Si la tecla está pulsada, continúa ejecutando u-boot, el cual monta la miniSD y carga el kernel, etc.
Todo eso ya está hecho, pero me encuentro con un problema: el u-boot funciona perfectamente si lo cargo directamente en memoria en la posición 0x80404000. Sin embargo, cuando lo "incrusto" en el ccpmp.bin:
a) El arranque normal de la A320 funciona correctamente: es decir, se salta a la posición 0x80404000, allí se comprueba que la tecla no está pulsada, se ejecutan las instrucciones eliminadas en el parcheo y se salta otra vez al ccpmp.bin. Todo OK.
b) El arranque u-boot funciona pero sólo hasta que empieza la carga del kernel (o quizás la inicialización de la miniSD, no lo sé seguro). Da una excepción "TLB load".
Sospecho que el problema es que el loader del firmware original avanza bastante en la configuración de la CPU (el TLB tiene que ver con la MMU) mientras que u-boot espera un sistema mucho más "virgen".
¿Alguien que sepa más que yo de la arquitectura MIPS puede sacar alguna conclusión de todo esto?
Lo siguiente es la captura de consola cuando se arranca con la techa pulsada (estoy usando SELECT, pero se puede cambiar fácilmente).
NAND Booting...ECD755B6..
loader size = 0x00051670
..
OK
NAND Loading...
get ccpmp_config ok!!!
ccpmp_config.firmware_name = A320.HXF. ccpmp_config.update_key = 123, ccpmp_con.
loader normal mode...
Creating ftl device...
id:EC D7 55 B6 78
id:00 00 00 00 00
id:00 00 00 00 00
id:00 00 00 00 00
OK.
usb_connect = 1
into lcd_init.
loader -- into lcd_init.
into init_lcd_gpio.
out init_lcd_gpio.
loader -- init_lcd_gpio ok.
into Init_LCM_MOUDLE_ILI9325!!!
out Init_LCM_MOUDLE_ILI9325!!!
loader -- init_lcd_register ok.
loader -- out lcd_init.
Start decode...
OK 153602.
out lcd_init.
get_lcd_brightness -- value = 3.
len is 0x 500000
os_len = 0x 500000. checksum = 0x26f75489.
1 - ret = 0
2 - ret = 1
Run image...
U-Boot 1.1.6 (May 12 2009 - 02:54:16)
Board: Dingoo A320 (CPU Speed 336 MHz)
DRAM: 32 MB
Flash: 0 kB
Using default environment
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
MMC card found
================================================== ===========
Exception:
SP:81EAAA28
EPC:81FBBEE8
CAUSE:00800008 TLB load
Reg dump:
ra = 81FC1D38 fp = 00000027 gp = 81FCBDD0 t9 = 81FBBED8
t8 = FFFFFFFF s7 = 00000003 s6 = 00000000 s5 = 0000005C
s4 = B0010168 s3 = B0010158 s2 = 81FCE490 s1 = 81FCE490
s0 = 00000000 t7 = 00000000 t6 = 00000000 t5 = 81FCA844
t4 = 00000020 t3 = 81EAAD48 t2 = 00000004 t1 = 00000009
t0 = 81FCDFBC a3 = 00000000 a2 = 00000004 a1 = 00000000
a0 = 81FCDFBC v1 = 00000012 v0 = 00000000 AT = 00000000
LO = 00001CD1 HI = 00003000 ST = 10000402 EPC = 81FBBEE8
Madremia que currada de nuevo!!
Si el cargador de la dingoo avanza tanto en la inicializacion, no se podria hacer algo como un loader pero en el orden contrario, es decir, carga el loader, si no hay tecla, resetea todos los valores y pasa a cargar el loader de la dingo, si hay tecla, se sigue iniciarlizando para linux, si hay otra tecla, kernel desarrollo, etc.
Se que es hablar por hablar, porque la currada te la estas dando tu, pero me gustaria saber cual es el problema de dicha opcion.
Asi mismo, no debe de ser sencillo el reseteo de los valores de la cpu, pero sino, antes de iniciar el arranque del kernel, no se podria hacer un reset?
Saludos
me gustaría ayudarte, pero sintiendolo mucho no tengo ni idea de lo que puede pasar.
Estoy desarrollando un emulador de WonderSwan para Dingoo A320.
Codificando la parte de sonido no veo como desde las SDK puedo reproducir desde un buffer PCM (solo hay una función LoadPCM para carga desde fichero).
¿Como puedo implementar la parte de sonido sin las SDK?
¿Existe algún emulador con código fuente libre en el que funcione correctamente el sonido?
Madremia que currada de nuevo!!
Si el cargador de la dingoo avanza tanto en la inicializacion, no se podria hacer algo como un loader pero en el orden contrario, es decir, carga el loader, si no hay tecla, resetea todos los valores y pasa a cargar el loader de la dingo, si hay tecla, se sigue iniciarlizando para linux, si hay otra tecla, kernel desarrollo, etc.
Sí, supongo que se podría. Estoy casi seguro de que el problema viene de que el loader inicializa la MMU, y yo de eso no tengo ni idea (arquitectura MIPS), ni siquiera se si es posible revertir esa inicialización, aunque supongo que bastaría con cambiar la configuración de la MMU a la misma que usa el kernel o a alguna otra que no entre en conflicto. En problema es que yo no se nada de la MMU de este procesador, ni de cómo configura la MMU el loader, y ni siquiera de cómo lo hace linux.
Me podría hacer el ánimo de aprender e ir haciendo pruebas, pero es que el proceso es AGÓNICO, ya que implica:
1- En linux preparar el código que quiero probar y meterlo en el ccpmp.bin.
2- En windows, meter el ccpmp.bin dentro de un archivo de actualización firmware HXF.
3- En windows, actualizar el firmware con el fichero anterior.
Además de necesitar dos ordenadores (o reiniciar), el proceso de actualización de firmware tarda como 5 minutos. Desarrollar haciendo pruebas a ciegas sólo funciona si es sencillo y rápido hacer cada prueba.
Asi mismo, no debe de ser sencillo el reseteo de los valores de la cpu, pero sino, antes de iniciar el arranque del kernel, no se podria hacer un reset?
Sí, pero es que entonces volvemos al principio: la ROM de la A320 lee el loader de NAND, éste carga el ccpmp.bin, etc.
Que yo sepa, no hay forma de hacer un reset del sistema sin que éste arranque como se supone que debe hacerlo después del reset (lo cual, si lo piensas es lógico, ya que el reset, por definición, debe llevarte obligatoriamente a un estado conocido de incio). La única excepción es la que ya conocemos de pulsar un botón, que lo único que hace es que la ROM se de cuenta de la pulsación e inicie una secuencia de arranque alternativa.
Las secuencias de arranque alternativas de la ROM son cuatro, no nos son útiles (para un arranque dual controlable sin la ayuda del USB desde el PC) y no son modificables (precisamente por estar en ROM). De ahí que yo haya "pinchado" en un punto de la secuencia de arranque en el que puedo "entrar" fácilmente.
Y hago énfasis en "fácilmente"; ya que modificar el archivo ccpmp.bin es sencillo y contamos con herramientas para alterar los contenidos de los archivos HXF.
Por supuesto, la forma CORRECTA pero más complicada de hacerlo es reemplazar el propio loader por uno parcheado que lea la tecla SELECT en una etapa muy temprana de la inicialización del sistema (antes de haber trasteado con la MMU) y si está pulsado que cargue u-boot de la NAND en lugar de ccpmp.bin.
El problema es que esto ya requiere recurrir a herramientas más especializadas para grabar la NAND. Lo de modificar únicamente el ccpmp.bin tenía el atractivo de que se puede crear y distribuir un HXF que cualquiera puede instalar en su dingoo como cualquier otra actualización de firmware.
Conforme escribo me doy cuenta de que seguramente sea más fácil seguir este camino que pretender "desinicializar" la MMU (y ojo, que lo de que el problema está en la inicialización de la MMU es una sospecha... igual no es eso o además de eso hay problemas con otros periféricos).
¿Alguien que sepa más que yo de la arquitectura MIPS puede sacar alguna conclusión de todo esto?
La única persona que conozco que sabe bastante de MIPS es Exophase. Ahora que los foros de gp32x están caídos, lo puedes encontrar en los foros de openpandora.
< - >
¿Existe algún emulador con código fuente libre en el que funcione correctamente el sonido?
Creo que el port del SDLPAL del programador chino flyspy reproduce el sonido desde un buffer, pero no hay código fuente disponible. Puedes probar a contactar con Subzero en su blog (http://www.5idoudou.net/subzeroblog/) y pedírselo.
Ayer vi la noticia de una empresa española que tiene pensado sacar un portatil/netbook/UMPC con linux que usa un micro Mips ( Ingenic ) , parece que les importa mucho el software libre y supongo que no les importará ayudar a la causa :)
http://www.iunika.com/ No veo una dirección de contacto por ningún sitio o estoy torpe...
Me consta que nos lee gente no hispanoparlante para seguir el progreso, y las traducciones automáticas son nefastas. Yo preferiría no mudarme de foro. ¿Le importa a alguien si en adelante posteo en inglés?.
Por otra parte, lo que debería hacer es dedicar algo de tiempo a publicar toda la información que he ido averiguando de forma ordenada en un wiki o algo así... cuesta hacerse el ánimo.
Do as you wish, I haven't got any problem so If you wan't to write in english, I'll keep reading you; And I think I can help to anyone who can't understand you.
If you wan't to write in english,
You begin so good. WTF is "wan't"?? [wei5]
Cachondeos a parte ya hay un wiki, échale un vistazo por si te interesa más que crear uno desde cero:
http://a320.bluwiki.com/
You begin so good. WTF is "wan't"?? [wei5]
Cachondeos a parte ya hay un wiki, échale un vistazo por si te interesa más que crear uno desde cero:
http://a320.bluwiki.com/
Es un errorcillo por postear a escondidas.
Danielo515
13/05/2009, 19:11
Me consta que nos lee gente no hispanoparlante para seguir el progreso, y las traducciones automáticas son nefastas. Yo preferiría no mudarme de foro. ¿Le importa a alguien si en adelante posteo en inglés?.
Por otra parte, lo que debería hacer es dedicar algo de tiempo a publicar toda la información que he ido averiguando de forma ordenada en un wiki o algo así... cuesta hacerse el ánimo.
Desgraciadamente lo más probable es que sea lo mejor para la comunidad, pero no puedo evitar sentir un poco de rabia y rencor hacia los anglosajones cuando ellos no hablan otra cosa que inglés, que tienen mucha gente muy buena haciendo muchas cosas, y les escriben todo en perfecto inglés, que hay miles de tutoriales en inglés, y que por muchos hispanoparlantes que les lean, ellos siguen escribiendo en inglés.
Se que la vida es así, que es lógico, que el inglés está muy extendido, pero ****, me da rabia, y cuando que tenemos un crack aquí rompiendo barreras, hala, se lo llevan ellos. Y tu escribiendo en inglés, yo leyendo en inglés y los dos hablamos español.
Si te van a ayudar, me parece genial, si crees que va a animar a muchos a colaborar, me parece genial, si es por pena.... que se chinchen [wei]
por que no pones tus respuestas en los 2 idiomas
por que no pones tus respuestas en los 2 idiomas
No creo que a booboo le haga demasiada gracia tener que escribir sus ya de por sí largos (a la par que interesantes) posts dos veces.
Mi opinión: usa el idioma que prefieras.
por que no pones tus respuestas en los 2 idiomas
Porque es mucha faena.
Probablemente lo mejor sea que haga lo que tendría que haber hecho ya de organizar y publicar toda la info en inglés. Yo personalmente soy de la opinión de que, por educación, con UNA sola persona que no esté de acuerdo en que postee en inglés es suficiente para no hacerlo.
De todas formas era un apaño. Lo que toca es lo del wiki o un blog, o wiki + blog. Prometo que de este fin de semana no pasa.
a mi me da igual el idioma en el que lo pongas per en un foro en español siempre nos gusta leer en ese idioma
Porque es mucha faena.
Probablemente lo mejor sea que haga lo que tendría que haber hecho ya de organizar y publicar toda la info en inglés. Yo personalmente soy de la opinión de que, por educación, con UNA sola persona que no esté de acuerdo en que postee en inglés es suficiente para no hacerlo.
De todas formas era un apaño. Lo que toca es lo del wiki o un blog, o wiki + blog. Prometo que de este fin de semana no pasa.
Ten en cuenta que si posteas en ingles siempre hay alguien dispuesto a traducir los textos al español, al menos las partes mas relevantes ;)
Porque es mucha faena.
Probablemente lo mejor sea que haga lo que tendría que haber hecho ya de organizar y publicar toda la info en inglés. Yo personalmente soy de la opinión de que, por educación, con UNA sola persona que no esté de acuerdo en que postee en inglés es suficiente para no hacerlo.
De todas formas era un apaño. Lo que toca es lo del wiki o un blog, o wiki + blog. Prometo que de este fin de semana no pasa.
Y usar Google Code ? puedes subir cosas, poner noticias, wiki... todo facilito sin complicarse la vida. Y feeds :)
http://code.google.com/p/dingoodev/
Si alguien quiere el password para usarlo no problem, o lo pongo aquí que somos todos de fiar. Edit : Si tienes una cuenta de google se puede añadir al proyecto y pasas a ser administrador.
Renuente
13/05/2009, 21:36
¿Fuga de cerebros? booboo, si es lo mejor para todos pues se escribe en el idioma de los piratas, pero no abandones nuestro foro. :brindis:
Porque es mucha faena.
Probablemente lo mejor sea que haga lo que tendría que haber hecho ya de organizar y publicar toda la info en inglés. Yo personalmente soy de la opinión de que, por educación, con UNA sola persona que no esté de acuerdo en que postee en inglés es suficiente para no hacerlo.
De todas formas era un apaño. Lo que toca es lo del wiki o un blog, o wiki + blog. Prometo que de este fin de semana no pasa.
No se si lo sabes, pero esta pagina tiene blogs personales, asi que podrias publicar alli los contenidos.
A mi me da igual que publiques en ingles, pero si es un problema y vas a publicar fuera del foro, deja una url porfavor.
Otra cosa que podrias hacer es escribir en ingles y que alguien lo escribiese en castellano, seguro que luego guando lo leas te retuerces de dolor, pero al menos si alguien no puede enterarse de algo, seguro que le vendra bien.
Saludos y muchas graicas por todo el trabajo
Romenelen
13/05/2009, 22:52
Si tu crees que posteando en inglès avanzaràs màs pues adelante.
Por favor, Booboo, no te lo tomes mal. Me parece extraordinario el curro que te estàs pegando, pero me gustarìa seguir enterandome de los avances que estais consiguiendo. Si alguien se molesta en traducir lo que vaya posteando Booboo, vale, habrà que tirar con ello.
Un saludo.
Rivroner
13/05/2009, 22:58
Las tildes son para el otro lado :D ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
ezelkow1
14/05/2009, 05:27
First, sorry this is in english, but I dont know spanish. Booboo, i posted this on dingoo-scene but wasnt sure if you were watching the comments on there. I noticed on the ingenic ftp site that they had updated the uboot patches as well as their linux kernel patch. They also have updated english documentation for uboot which hopefully will come in handy so we wont have to try to decipher the chinese anymore.
Just figured I would post this in case you hadnt already noticed. The patches may just be for android since looking around on the ftp I do see some references to it, so it looks like they may be trying to port android to their products as well.
< - >
Downloaded the changelog for the linux patch. Looks like its an update to the mtd driver for invalid partitions, and to support partitions larger than 4gb.
linux-2.6.24.3-jz-20090506.patch.gz
* Whether a partition works over mtdblock-jz or not could be determined by the
value of mtdblock_jz_invalid in partition_info[] in drivers/mtd/nand/jz47xx_nand.c.
And which mode a partition works with, cpu mode or dma mode, could be determined by the
value of cpu_mode in partition_info[] in drivers/mtd/nand/jz47xx_nand.c.
* The BCH ecc position in nand oob was changed to 24.
* Fix a bug when a NAND partition's size exceeds 4GB.
* Support Jz4755.
The uboot changes appears to have changed some defines
u-boot-1.1.6-jz-20090506.patch.gz
* Change the size of Nand SPL from 256 KB to 32KB.
* You can define CFG_NAND_BCH_WITH_OOB in include/configs/xxx.h to conform
NAND ECC with linux kernel.
* APUS use 4K pagesize nand and 8bit BCH with eccpos equal to 24 as default.
* Add Jz4755 platform: CETUS board.
They also look like they have updated the uboot precompiled windows tools
Las tildes son para el otro lado :D ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
esque el xiquet es valencià. [wei]
Danielo515
14/05/2009, 09:39
Ten en cuenta que si posteas en ingles siempre hay alguien dispuesto a traducir los textos al español, al menos las partes mas relevantes ;)
Te estas ofreciendo voluntario?
Por cierto ¿por qué aparecen dos botones de quote? uno de ellos me lleva a una página de publicidad chunga.
En serio booboo, do as you wish, pero no abandones este languaje tan precioso.
Una cosilla ; ¿Cómo se compila y se crea un ejecutable para la Dingoo?. Es que no consigo entenderlo xD . Trabajo con el Visual C++ 2008.
Gracias.
Kiwiz, en este blog (http://blog.tipesoft.com/?tag=dingoo-a320) hay unos artículos en español que están muy bien. El autor explica desde cómo instalar el SDK hasta crear videojuegos o portar aplicaciones. Leelos en orden cronológico, de abajo a arriba.
Conocía ese blog , gracias de todas formas , pero la duda que me surge es si debo crear un archivo ".app" (una aplicación).
Ayer hice uno de mis posts mogollónicos pero no se que he hecho (sería la hora) que se ha perdido (probablemente le dí a "vista previa" y me fuí a dormir... brilante, sí señor). Intentaré ser breve y pulsar esta vez el botón correcto:
Ya funciona el sonido, y como era de esperar casi inmediatamente he identificado los GPIO que controlan el amplificador (uno es el mute, el otro no lo tengo claro del todo aún).
Me ha costado tanto porque la secuencia de acontecimientos ha sido algo así como esto:
1- Veo que el kernel de Ingenic tiene driver OSS y ALSA. OSS está obsoleto, así que presumo que el bueno debe ser el ALSA, pero por si acaso, decido darle un tiento al OSS aunque sea para descartarlo.
2- La primera prueba que hago del OSS (cat /dev/urandom > /dev/dsp) acaba en un segfault del kernel, con lo cual deduzco que el driver ni siquiera funciona y asumo que mi presunción inicial era correcta: ALSA es el bueno.
3- Me paso un huevo de horas intentado hacer funcionar ALSA (es muy complejo, innecesariamente complejo para la A320, hacen falta librerías, etc) sin éxito, hasta que al final de casualidad me doy cuenta de algo que me hace sospechar que es el driver el que no funciona.
4- De pura desesperación vuelvo a OSS. Esta vez en vez de el "cat", compilo el madplay con soporte OSS... y funciona !!!.
Por lo visto la calidad de código deja mucho que desear. ALSA directamente NO funciona. OSS funciona, pero como hagas algo "no estándar" en lugar de gestionar bien el error, peta.
El caso es que paradójicamente para la A320 lo que toca es OSS. Es más ligero y más simple de programar, y las únicas pegas son que carece de algunas características como el uso simultáneo por varias aplicaciones o el resampling automático si el hardware no soporta la frecuencia de muestreo seleccionada por el software. Esas dos características las proporciona ALSA, y son imprescindibles para un sistema operativo moderno, pero NO son necesarias en la A320 donde sólo va a utilizarse una aplicación en un momento dado.
No obstante, teniendo OSS que funciona, depurar ALSA para averiguar por qué no va es viable (que no agradable). De momento me quedo con lo que funciona.
De la funcionalidad básica necesaria para poder correr linux + aplicaciones en la A320 ya tengo miniSD + vídeo + audio, y sólo falta las teclas que se hace en una tarde. Con eso linux ya es usable para jugar emuladores y demás, si bien no es sustituto del firmware ya que para eso hay que hacer funcionar todo lo demás (FM, TV out, NAND, etc).
Con una salvedad: es necesario un PC para arrancar linux. Como ya sabéis mis intentos de conseguir un arranque dual parcheando el ccpmp.bin han topado con el escollo de la excepción TLB. No voy a avanzar más por ahí porque la única forma de hacerlo es prueba-y-error y el proceso es agónico, ya que requiere un flasheo completo del firmware con la herramienta de unbricking y la cosa tarda como 5 o 10 minutos. Es inviable.
Voy a ver si se puede "pinchar" en algún punto anterior del proceso de arranque, pero en tal caso sería necesario modificar la NAND flash directamente (lo del ccpmp.bin tenía la ventaja de que usaba las herramientas y el proceso estándar de actualización del firmware original).
El proceso de arranque normal (no USB boot) viene a ser algo así:
1- Tras el reset arranca el código en ROM del la CPU (IPL=initial program loader).
2- El código en ROM carga 4K (8K?) de código desde la NAND flash en la caché de instrucciones y lo ejecuta. Este es el SPL=secondary program loader.
3- El SPL inicializa la SDRAM y carga otro código algo más grande. Este código debe estar en una posición fija de la flash, porque el SPL dado su tamaño reducido no puede "entender" un sistema de archivos, sea del tipo que sea. Llamemos a este código TPL=tertiary program loader.
4- El TPL ya tiene un tamaño importante, de modo que hace una inicialización completa del hardware (incluyendo el LCD y mostrando las imágenes de arranque), entiende el sistema de archivos del ChinaChip y carga el ccpmp.bin.
Los pasos (3) y (4) son suposiciones fundadas en lo que he observado.
Vaya, parece que ya lo tienes practicamente todo... pfff menudo curro, y lo mejor es que lo has hecho en un tiempo record (un par de semanas) y casi completamente funcional, que por lo que veo, lo unico que te falta de momento es arreglar el tema de las letras y tratar de ver como se arranca la dingoo para conseguir hacer funcional el dual boot, y que el proceso de "actualización" sea flasheando la memoria interna y reinstalando el nuevo "firmware" con el firmware oficial + linux. Es eso? es un poco por encima lo que me ha parecido que queda por hacer.
Ah, y puesto que parece que ya lo tienes practicamente encaminado, voy a hacerte un par de preguntas respecto al linux:
1. Cuanto hardware queda disponible una vez cargado linux? para hacernos una idea de que software podria llegar a correr en esta mini versión de linux (por ejemplo, alguna distro "light" de openoffice?).
2. Que hay que hacer para hacer funcionar un programa de linux (por ejemplo, de PDA) en esta versión? habra que adaptarlos o hay que reescribirlos de nuevo?.
3. Y dispone de shell básico funcional? vamos, si se podra tener algo tipo "bash" para poder trastear con la dingoo los curiosos del linux.
Vamos, y felicidades por el curro, y a ver cuando lo terminas para que la gente pueda empezar a sacar programitas.
Saludos.
1. Cuanto hardware queda disponible una vez cargado linux? para hacernos una idea de que software podria llegar a correr en esta mini versión de linux (por ejemplo, alguna distro "light" de
openoffice?).
Dado el tamaño y resolución de la pantalla y la ausencia de teclado, lo del openoffice no tiene el más mínimo sentido, como no lo tiene un entorno gráfico de ventanas.
Ten en cuenta que la A320 no tiene interface red, con lo cual su UNICA utilidad es jugar, y quizás algo tipo agenda y tal.
Que bien, que vale, que configurando el USB en modo host, usando un hub alimentado externamente, y conectando un teclado y un stick USB-ethernet externo se puede conseguir una especie de ordenador, pero sería poco útil en la práctica.
2. Que hay que hacer para hacer funcionar un programa de linux (por ejemplo, de PDA) en esta versión?A habra que adaptarlos o hay que reescribirlos de nuevo?.
Habrá que adaptar casi cualquier cosa EXEPTO los emuladores (que ese era el propósito original), debido sobre todo a que las aplicaciones están pensadas para un sistema con ratón o pantalla táctil, y la A320 carece de ambos.
Voy a insistir una vez más en que el propósito de portar linux a la A320 es contar con un entorno de programación bien documentado y para el que hay miles de programadores dispuestos a ponerse manos a la obra y para el que portar aplicaciones es casi inmediato (para aquellas susceptibles de correr en un entorno sin puntero). Ni más ni menos.
3. Y dispone de shell básico funcional? vamos, si se podra tener algo tipo "bash" para poder trastear con la dingoo los curiosos del linux.
Saludos.
Sí, ya tengo un shell funcionando, pero se controla desde el PC precisamente porque la A320 no tiene teclado.
Para el usuario final lo que tiene que haber es una aplicación principal que hará las mismas funciones que el firmware original: ser un menú desde el que se lanzan otras aplicaciones o archivos de medios (música, vídeo, etc).
javili23
15/05/2009, 15:02
booboo eres una maquina, quiero agradecerte desde aqui todo el curro que te estas pegando. Estoy deseando hincarle el diente a ese linux en mi dingoo.
Una pregunta booboo, ¿será posible usar el USB serial con XP? (como en la GP2X con estos drivers (http://wiki.gp2x.org/wiki/Tcp/ip_over_usb#Installing_the_USB_Gadget_driver))
Ok, gracias por las respuestas, de todas formas parece que me expresé mal, obviamente no se podria utilizar un openoffice al uso, si no, mas bien a lo que me refería es a un programa que de visualización de archivos de openoffice, vamos, para poder ver texto del writer, documentos .doc de word, presentaciones de Powerpoint y Impress, lector de pdf, etc...
No se si esto seria posible (la visualización de los archivos adaptada a la pantalla) y el scroll de arriba/abajo.
Creo que esto seria bastante util, ya que quedaria una especie de PDA "bastante apañadita" y seria muy util para llevar archivos de texto y presentaciones donde se necesite, y al ser un programa que se podria lanzar desde un menu y cargar archivos desde un explorador no necesitaria de un entorno grafico, no?.
Bueno, se agradece la respuesta y si no se puede pues bueno, dejo de preguntar, pero como existen cosas similares para psp y nds pues pensaba que se podria hacer algo similar y mas potente al ser la dingoo mas potente que estas dos.
Saludos.
Bueno, ahora que lo dices Ruxy, me gustaria probar el festival de Linux que e sun programa TTS, ya que la dingoo lleva un TTS solo que pronuncia en ingles :(
Aunque puede que sea muy pesado...
Podria ser una opcion muy interesante si se puede utilizar en español tambien, pero supongo que este tipo de programas seran ya mas pesados... no se si la dingoo lo aguataria, por el procesador con 400Mhz aun, pero con 32Mb de RAM... no se que requerimientos necesitara, ya que nunca he utilizado este tipo de programas en linux, pero imagino que sera bastante pesado.
De todas formas me conformo con un lector que deje visualizar por pantalla ficheros de Opeoffice, Word, pdf y demas... :D
Una pregunta booboo, ¿será posible usar el USB serial con XP? (como en la GP2X con estos drivers (http://wiki.gp2x.org/wiki/Tcp/ip_over_usb#Installing_the_USB_Gadget_driver))
En principio sí, sólo hay que activar el gadget USB ethernet en el kernel de la A320. Cuando la arrancas aparece un interfaz llamado usb0.
En teoría cuando la conectas a un PC en éste se debería cargar automáticamente el módulo cdc_ether y debería aparecer también un interfaz usb0. El resto es configuración estándar IP.
Pero he escrito "en teoría" porque en mi PC (Ubuntu 9.04) no apareció el interfaz usb0. No indagué más en ese momento. Sin embargo, mas adelante, pensé que sería perfecto tener un dispositivo USB compuesto (consola + mass storage) y me tomé la molestia de ver qué cambios se han hecho en la parte de gadgets USB del kernel desde la versión que tengo para la A320 hasta la más reciente (usando los changelog), y parece ser que todo el tema de los gadgets es relativamente reciente y en el kernel que tengo para la A320 estaba todavía un poco verde. De hecho hay muchos fixes tanto del gadget serie como del gadget ethernet, e incluso ya se soportan gadgets compuestos. Desgraciadamente existe serie + ethernet pero NO serie + mass storage que creo que es lo que nos interesaría.
Creo que en otro mensaje comenté que aquí hay dos opciones: o se implementa el gadget compuesto con lo que hay en el kernel que tenemos para la A320, o se hace un "backport" de toda la sección de gadgets desde un kernel reciente. Ambas opciones son una pasada de faena, y la segunda ni siquiera nos proporcionaría la combinación serial + mass storage.
< - >
Ok, gracias por las respuestas, de todas formas parece que me expresé mal, obviamente no se podria utilizar un openoffice al uso, si no, mas bien a lo que me refería es a un programa que de visualización de archivos de openoffice, vamos, para poder ver texto del writer, documentos .doc de word, presentaciones de Powerpoint y Impress, lector de pdf, etc...
Disculpa... no había caido en esa aplicación.
No se si esto seria posible (la visualización de los archivos adaptada a la pantalla) y el scroll de arriba/abajo.
Openoffice no corre ni de coña con 32M (por no hablar del servidor X y demás que también tendría que funcionar). Y aunque lo hiciera habría que adaptar todo el interfaz para que fuera funcional con sólo las techas que tiene la A320.
Creo que esto seria bastante util, ya que quedaria una especie de PDA "bastante apañadita" y seria muy util para llevar archivos de texto y presentaciones donde se necesite, y al ser un programa que se podria lanzar desde un menu y cargar archivos desde un explorador no necesitaria de un entorno grafico, no?.
Openoffice necesita un servidor X con su gestor de ventanas y todo. Olvídalo.
Y de todas formas, con 320x240 no vas a ver casi nada.
Quizás alguien se podría hacer el ánimo de hacer un lector de PDF (adaptando uno existente para salida a framebuffer en lugar de X) o algo así. Siempre puedes pasar casi cualquier cosa a PDF. Pero insisto en que la limitación de memoria es abrumadora.
Bueno, se agradece la respuesta y si no se puede pues bueno, dejo de preguntar, pero como existen cosas similares para psp y nds pues pensaba que se podria hacer algo similar y mas potente al ser la dingoo mas potente que estas dos.
Saludos.
No conozco las características de esas dos, pero yo diría que ni de coña es más potente que la PSP, por no hablar de la abrumadora diferencia de pantalla, tanto en tamaño como resolución.
En todo caso no digo que no se pueda, digo que el portado sería una faena monstruosa y que para la pantalla que tiene la A320 no vale la pena.
< - >
Bueno, ahora que lo dices Ruxy, me gustaria probar el festival de Linux que e sun programa TTS, ya que la dingoo lleva un TTS solo que pronuncia en ingles :(
Aunque puede que sea muy pesado...
Yo también sospecho que festival será demasiado pesado. Sin embargo creo que hay por ahí precisamente una versión para sistemas con pocos recursos, y siempre te queda espeak que es más ligero (y la síntesis de peor calidad, pero se entiende).
Una vez que el funcionamiento de linux en esta unidad, todo es más fácil.
Pero el uso de un teclado virtual será indispensable!
Una vez que el funcionamiento de linux en esta unidad, todo es más fácil.
Pero el uso de un teclado virtual será indispensable!
gp2x usa linux y no trae un teclado virtual por defecto..
Es decir, portar linux, como ha dicho booboo, supone poder tener las sdl y portar juegos que corran sobre estas librerias pintando en el FB, es decir, rapido y bonito.
Se podrian crear algunas funciones para volver al menu del sistema, que se tendria que implementar, pero como han dicho, nada de servidor de X, sino todo sobre el FB, como se hace en la gp2x.
Ademas, de esta forma se podria ver la potencia de la consola, ya que se podria compilar un emulador de gp2x sin cores en encamblador, solo C puro y ver como va de bien en la dingoo.
La verdad que si es facil pòrtar el menu que dijeron hace unos post, seria la caña.
Saludos
Hola,
Acabo de implementar el teclado y lo que he hecho es no calentarme la cabeza y utilizar el mapeo de teclado del SNES9X:
D-Pad: flechas
Botón A: 'd'
Botón B: 'c'
Botón X: 's'
Botón Y: 'x'
Botón hombro izquierdo: 'a'
Botón hombro derecho: 'z'
START: enter
SELECT: espacio
Si alguien tiene alguna sugerencia mejor, por favor que lo diga.
Para el tema del volumen del audio y la retroiluminación de la pantalla se me han ocurrido un par de cosas y también quisiera oír comentarios:
En ambos casos lo suyo es implementar estas funciones en los drivers correspondientes. Esto está muy bien para un sistema de escritiorio pero me parece que no es muy adecuado para la Dingoo. Me explico:
La implementación en los drivers proporciona un API estándar para que luego los programas de modo usuario hagan lo que crean conveniente. Cuando uno tiene un interfaz gráfico X éste gestiona el teclado de forma que cuando se detectan las teclas especiales de subir/bajar volumen y retroiluminación se envían a una aplicación concreta que es la única que habla con los drivers y que hace los ajustes pertinentes. Para que todo esto funcione debe haber una entidad que gestione el teclado y luego distribuya los inputs (X) y hacer una aplicación que se encargue de gestionar los inputs de esas teclas especiales que X le manda.
Pero en la A320 no tenemos gestor X, y cada aplicación leerá directamente los inputs, así que al no haber un "intermediario" que los redirige a distintas aplicaciones no podemos tener una aplicación de usuario en background que se encargue del volumen y la retroiluminación. En todo caso ya sabéis que interesa tener las menos aplicaciones corriendo al mismo tiempo, para no consumir memoria. Se da además la circunstancia de que en un sistema con el hardware tan rígido como es la A320 tenemos muy claro desde ya mismo cómo deben funcionar tanto el volumen como la retroiluminación.
Lo que he pensado es, en vez de gestionar esas funciones desde los drivers correspondientes hacerlo directamente desde el driver de teclado GPIO. De esa forma, INDEPENDIENTEMENTE de qué aplicación esté corriendo uno podría modificar el volumen y la retroiluminación utilizando una combinación especial de teclas.
También a este respecto me gustaría oír opiniones sobre qué combinaciones de teclas serían las más idóneas para estos propósitos. He de confesar que no me he llegado a leer ni el manual de la A320 así que no se ni cómo se hace en los emuladores del firmware original, pero me da igual porque cómo lo haga el firmware original no necesariamente tiene que ser lo más conveniente para el usuario (que ya sabemos cómo son los chinos).
en los emuladores ke trae la dingoo se da volumen pulsando arriba mientras das al boton de apagar, y para quitarle es lo mismo pero dandole abajo. Creo que esta implementado en cada emu, y no en el firm en si.
Me encanta este hilo, y ya que puedo aportar "algo"
Puesto que la GP32 y Dreamcast usan este mismo mapeo de botones, salvo el "select" que no recuerdo muy bien que tecla tenía asignada, puede ser muy conveniente usar el mismo, He aquí mi sugerencia:
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
Me encanta este hilo, y ya que puedo aportar "algo"
Puesto que la GP32 y Dreamcast usan este mismo mapeo de botones, salvo el "select" que no recuerdo muy bien que tecla tenía asignada, puede ser muy conveniente usar el mismo, He aquí mi sugerencia:
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
Si alguien más puede confirmar que este es el mapeo que se utiliza en la GP32 (¿qué hay de la GP2X?), me parece una excelente idea utilizarlo.
¿Cuántas horas puede durar la batería?
Si alguien más puede confirmar que este es el mapeo que se utiliza en la GP32 (¿qué hay de la GP2X?), me parece una excelente idea utilizarlo.
La GP32 sólo tiene dos botones (A y B) pero más o menos es como dice LTK666. En la GP2X el pad se utiliza como un joystick cualquiera.
Sobre las teclas para subir/bajar volumen y retroiluminación yo apostaría por power + arriba/abajo para el volumen y power + dcha/izda para la iluminación.
< - >
flatmush está desentrañando los misterios de la librería entry.a para no tener que usar las S2D.
Esto es lo que ha descubierto por ahora:
void abort()
int printf(const char*, ...)
int sprintf(char*, const char*, ...)
int fprintf(FILE*, const char*, ...)
void* malloc(size_t)
void* realloc(void*, size_t)
void free(void*)
size_t fread(void*, size_t, size_t, FILE*)
size_t fwrite(const void*, size_t, size_t, FILE*)
int fseek(FILE*, long int, int)
size_t strlen(const char*)
void _lcd_set_frame()
void* _lcd_get_frame()
void lcd_flip()
void __icache_invalidate_all()
void __dcache_writeback_all()
void _kbd_get_status(KEY_STATUS*)
unsigned long int GetTickCount()
int _sys_judge_event()
Ha subido un ejemplo para pintar la pantalla usando un double buffer aquí (http://flatmush.juliusparishy.com/a320/DoubleBuffer.zip)
El hilo original se puede leer aquí (http://forum.openhandhelds.org/viewtopic.php?f=35&t=981&p=13806#p13806)
<-->
Otro ejemplo más:
Here is another sample, this one loads a texture and displays it on the screen, get it here (http://flatmush.juliusparishy.com/a320/Texture.zip)
The texture "test.tga" has to be located on the root of the internal drive, it has to be a 24-bit tga top-left to bottom right at the minute, since extra code would just bloat the sample.
¿Cuántas horas puede durar la batería?
Muchas. Le hice una carga completa cuando la compré y me he tirado un mes jugando a diario probando juegos y emuladores durante horas, enciendo y apagando constantemente, escuchando música, he visto Dragon Ball Evolution enterita y dos episodios de Prison Break y aún me quedan dos cuadritos de bateria. Yo diria que es infinita :)
Muchas. Le hice una carga completa cuando la compré y me he tirado un mes jugando a diario probando juegos y emuladores durante horas, enciendo y apagando constantemente, escuchando música, he visto Dragon Ball Evolution enterita y dos episodios de Prison Break y aún me quedan dos cuadritos de bateria. Yo diria que es infinita :)
·Puede que se deba a que cuando la conectas al ordenador se te cargue un poquito.
·Puede que se deba a que cuando la conectas al ordenador se te cargue un poquito.
Exacto, asi es, dura tanto por las recargas cuando lo conecta al PC por USB, de todas maneras dura bastante la bateria, hay teneis las pruebas que hizo A600.
·Puede que se deba a que cuando la conectas al ordenador se te cargue un poquito.
Puede que no. Los roms los metí todos de una vez ya que los tenia preparados y para los videos y música utilizo una tarjeta MiniSD de 2 Gb para no andar concectando y desconectando la consola.
Efectivamente la batería es infinita. Yo no la he cargado nunca y conectada al oredenador solo ha estado conectada dos veces y lo juesto para pasarle roms. Musica no he metido nunca y los videos van en la minisd, asi que sí, es infinita. Estos chinos se forran si se ponen a hacer coches electricos.
Puede que no. Los roms los metí todos de una vez ya que los tenia preparados y para los videos y música utilizo una tarjeta MiniSD de 2 Gb para no andar concectando y desconectando la consola.
Lo cierto es que sólo he tenido que cargarla una vez, pero siempre había pensado que era debido a que la conectaba al PC.
Sin resquemor, que no iba con mala intención ni de ir de listillo (me he reileído y sonaba a éso).
_Seagal_
16/05/2009, 19:15
Otro ejemplo más:
thanks a600! no lo habia visto.
Mañana lo probaré con otro source de un emu de la recreativa del mikie (juegazo, aunque la version de recreativa es 100 veces mas chunga que la de spectrum) que he encontrado.
Si alguien más puede confirmar que este es el mapeo que se utiliza en la GP32 (¿qué hay de la GP2X?), me parece una excelente idea utilizarlo.
·No puedo comentarte nada al respecto(no llegué a tener ninguna GP), pero sí decirte que control que comentó A600 (power +arriba/abajo para subir/bajar volumen y +derecha/izquierda para retroiluminación) me parecen buenos.
Una pregunta, ¿no podrían ser almacenados en un .txt que fuera leído al arranque de sistema y que así cada cual se lo configurase a gusto? (o si en un futuro fuese posible, vamos) yo no los cambiaría pero como cada cual tiene sus gustos...
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.
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.
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!!!
Simplemente alucinante :brindis: y sólo tarda 5 segundos en arrancar Linux.
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 :)
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.
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.
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 :(
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
Simplemente alucinante :brindis: 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).
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.
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.
Que no soporte 8bpp no es un poco putada por el rendimiento de los emuladores y juegos??
Saludos
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.
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)?.
No es un procesador acelerador dedicado, sino más bien un conjunto de instrucciones SIMD (single instruction multiple data) que vienen muy bien para aplicaciones multimedia.
Me consta que el mplayer que hay en el FTP de Ingenic sí que utiliza este conjunto de instrucciones.
Y la librería jpeg se llama "jpeg-6b-idctmxu-jz4740-080422.tgz", dado que el conjunto de esas instrucciones Ingenic lo denomina "MXU" sospecho que en efecto sí que hace uso de esa aceleración.
¿Podrá usarse para "agilizar" alguna tarea en el futuro?
Mientras los de Ingenic no proporcionen el manual de procesador con la descripción detallada del funcionamiento de cada instrucción, lo dudo. Sacar el funcionamiento de cada instrucción por ingeniería inversa, sobre todo teniendo ejemplos funcionales de código, es posible, pero es un faenón que no le deseo ni a mi peor enemigo.
En el datasheet del jz4740 pone esto:
256×16 bits internal palette RAM
Se supone que si usamos un framebuffer de 8bpp, se copiarán a la GRAM del LCD los colores de 16 bits que tengamos definidos en la paleta, ¿no?
Esta es la función usada para definir la paleta:
static int jzfb_slcd_setcolreg(u32 regno, u8 red, u8 green, u8 blue)
{
u16 *ptr, ctmp;
if (regno >= NR_PALETTE)
return 1;
red &= 0xff;
green &= 0xff;
blue &= 0xff;
jzfb_slcd.palette[regno].red = red ;
jzfb_slcd.palette[regno].green = green;
jzfb_slcd.palette[regno].blue = blue;
if (jzfb_slcd.bpp <= 8) {
if (((jzfb_slcd.cfg & MODE_MASK) == MODE_STN_MONO_SINGLE) ||
((jzfb_slcd.cfg & MODE_MASK) == MODE_STN_MONO_DUAL)) {
ctmp = (77L * red + 150L * green + 29L * blue) >> 8;
ctmp = ((ctmp >> 3) << 11) | ((ctmp >> 2) << 5) |
(ctmp >> 3);
} else {
/* RGB 565 */
if (((red >> 3) == 0) && ((red >> 2) != 0))
red = 1 << 3;
if (((blue >> 3) == 0) && ((blue >> 2) != 0))
blue = 1 << 3;
ctmp = ((red >> 3) << 11)
| ((green >> 2) << 5) | (blue >> 3);
}
ptr = (u16 *)jzfb_slcd.pal;
ptr[regno] = ctmp;
REG_DMAC_DDA(dma_chan) = PHYS(&slcd_palette_desc);
} else
printf("No palette used.\n");
return 0;
}
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.
< - >
Exacto.
¿Puedes explicar cómo y por qué afecta al rendimiento?. Si lo entiendo bien quizás pueda intentar arreglarlo cuando me meta a fondo con el framebuffer.
¿Puedes explicar cómo y por qué afecta al rendimiento?. Si lo entiendo bien quizás pueda intentar arreglarlo cuando me meta a fondo con el framebuffer.
¿8bpp vs 16 bpp? Tenemos que manejar el doble de bytes así que,sí o sí, tiene que afectar al rendimiento.
En el datasheet del jz4740 pone esto:
Se supone que si usamos un framebuffer de 8bpp, se copiarán a la GRAM del LCD los colores de 16 bits que tengamos definidos en la paleta, ¿no?
Esta es la función usada para definir la paleta:
En efecto, tiene pinta de que el LCD implementa internamente la paleta para modos de 8bpp, lo cual significa que modificando el código del driver framebuffer se debería poder hacer que el display soporte modos 8bpp de forma nativa.
Sin embargo hay dos "peros":
- Esperaba no tener que meterme a programar el controlador del display. Tuve que obtener los valores de inicialización de los registros (como unos 50 !!!) y su secuencia (con retardos y todo) desensamblando el .dl que venía con el unbricker. La idea era utilizar el mismo enfoque que usa el firmware original: se inicializa el LCD en un modo y se trabaja en ese modo sin volver a tocar nada.
- La forma en que está conectado el LCD en la A320 tiene muy mala sombra. Hay un pin que se llama RS# que se usa para indicarle al LCD si se va a acceder a un registro o a la memoria de imágen (tanto en lectura como en escritura). El controlador SLCD del JZ4740 controla automáticamente esta señal. Para ello usa el bit 31 del dato que escribes y lo pone en el pin correspondiente. Pues bien, resulta que, seguramente por un fallo garrafal de diseño en la A320 han conectado esta señal RS# del LCD al pin equivocado del JZ4740.
Obviamente la función de manejar RS# automáticamente está ligada a un pin concreto del JZ4740, de modo que al conectarla a otro pin estamos obligados a hacerlo manualmente (se configura como GPIO de salida y listo). Donde nos hubiéramos limitado a escribir un valor en el LCD, ahora tenemos que activar RS#, escribir el valor, y desactivar RS# (esta es una de las cosas que me llevó de calle para hacer funcionar el display y que no hubiera adivinado ni en mil años de no haber desensamblado el .dl).
Este "apaño" de manejar manualmente la señal RS# no supone un gran problema si usamos el LCD en un solo modo: al principio se escriben todos los registros de configuración y se deja el pin RS# desactivado. Se configura la DMA para que vaya escribiendo continuamente los datos al display y listo.
El problema es que si se quieren cambiar registros del display se podría hacer también usando DMA (sin más que activar el bit 31), pero no se puede por la chapuza. Hay que parar el DMA, modificar los registros, y volver a arrancar el DMA. O mejor aún, aprovechar para escribir los registros antes de iniciar cada ciclo DMA.
Como véis, la cosa se complica significativamente cuando podría ser muy fácil.
< - >
¿8bpp vs 16 bpp? Tenemos que manejar el doble de bytes así que,sí o sí, tiene que afectar al rendimiento.
Hasta ahí ya había llegado yo, simplemente quería saber si había alguna otra implicación que se me escapaba.
¿Se nota realmente tanto en el rendimiento?.
Lo digo porque con la cantidad se cosas que hay que hacer en un emulador, el -al final de toda la cadena- hacer una simple conversión 8bpp->16bpp usando una tabla paleta no me parece tan costoso (se haría en todo caso en el driver framebuffer). Es una percepción, no tengo mucha idea de emuladores.
Supongo que si la limitacion de los 8bpp se salta con una conversion, la perdida de rendimiento no sera tan grande, pero normalmente, cuando se usan los 16bpp creo recordar que se activan las tranparencias en los emuladores, y eso si que hace que la emulacion sea mas lenta, ya que todo se hace por micro, no hay apaño que valga, por eso lo de la perdida de rendimiento.
Pero bien pensado, no tiene porque ser asi en todos los emuladores.
Saludos
Hasta ahí ya había llegado yo, simplemente quería saber si había alguna otra implicación que se me escapaba.
Ya lo suponía :D
Lo digo porque con la cantidad se cosas que hay que hacer en un emulador, el -al final de toda la cadena- hacer una simple conversión 8bpp->16bpp usando una tabla paleta no me parece tan costoso (se haría en todo caso en el driver framebuffer). Es una percepción, no tengo mucha idea de emuladores.
Así no creo que el rendimiento bajara demasiado. Con lo de la caída de rendimiento me refería a tener que trabajar a 16 bpp durante todas las operaciones que hiciéramos con la imagen.
Disculpad si me salgo un poco de la temática pero, ¿de qué sirve una smart LCD?.
Se supone que tiene una memoria intermedia que "vuelca" a pantalla, pero ¿para qué sirve ésto en la vida real?.
Gracias y perdón por el offtopic.
El problema es que si se quieren cambiar registros del display se podría hacer también usando DMA (sin más que activar el bit 31), pero no se puede por la chapuza. Hay que parar el DMA, modificar los registros, y volver a arrancar el DMA. O mejor aún, aprovechar para escribir los registros antes de iniciar cada ciclo DMA.
Como véis, la cosa se complica significativamente cuando podría ser muy fácil.
Pues menuda putada. Entonces, ¿para usar la función resize del ILI9325 hay que liar la de Dios?
Pues menuda putada. Entonces, ¿para usar la función resize del ILI9325 hay que liar la de Dios?
Esteeeee... ¿me puedes recordar qué es exáctamente esa función?
< - >
Disculpad si me salgo un poco de la temática pero, ¿de qué sirve una smart LCD?.
Se supone que tiene una memoria intermedia que "vuelca" a pantalla, pero ¿para qué sirve ésto en la vida real?.
Gracias y perdón por el offtopic.
Lo que voy a explicar es una simplificación, pero servirá:
Un display es una matriz de píxels. Los píxels no están iluminados contínuamente, ya que eso obligaría al display a "recordar" el estado de cada uno de ellos. Lo que se hace es un barrido iluminando sucesivamente todos los píxels de cada línea. Como el barrido es muy rápido el ojo humano no lo percibe y la persistencia de la visión hace el resto.
Por lo tanto, los LCD "tontos" no son más que una enorme matriz de píxels con unos cuantos chips controladores que lo único que hacen es permitir ir seleccionando e iluminando cada línea por separado. Alguien debe encargarse de ir haciendo el barrido con una temporización bastante precisa.
Esa temporización tan precisa (y para tantos datos) no se puede lograr programáticamente (mediante instrucciones de un procesador), de modo que se utiliza un controlador especial. En los SoC (system-on-chip) como el JZ4740 este controlador está integrado junto con la CPU y un montón de periféricos más en un sólo chip (de ahí lo de SoC). El controlador LCD lo que hace es, de forma independiente a la CPU, ir tomando los datos de una zona de memoria y enviándolos al LCD junto con las señales adecuadas para ir haciendo el barrido.
Todo eso es para los LCD "tontos". Necesitas un controlador externo que haga el barrido.
Los LCD inteligentes llevan el controlador de barrido integrado junto con cierta cantidad de memoria (como mínimo la suficiente para almacenar el estado de todos los píxels). De esta forma, para la CPU son poco más que una memoria externa en la que escriben las imágenes. El controlador integrado del LCD va leyendo su memoria intera y generando el barrido.
Decía que es paradójico que hayan utilizado un LCD inteligente en la A320 porque el JZ4740 lleva un controlador LCD propio y se podría haber utilizado un LCD "tonto" seguramente más barato, y porque la sincronización de las imágenes es más sencilla en este caso (insisto: siempre que la CPU disponga de un controlador LCD integrado).
Entonces por un error de diseño, implemetar el modo 8 bits supondría un trabajo que probablemente no compensaría en el rendimiento neto dado.
Esteeeee... ¿me puedes recordar qué es exáctamente esa función?
Si es lo que yo pienso, es una funcion que tienen algunos controladores y/o LCDs para ajustar a la resolucion nativa de la matriz del LCD imágenes de otras resoluciones. Esa funcion sirve para muchas cosas pero en estos foros la gente estará pensando principalmente en que la funcion de reescalado por hardware libera a la CPU de los cálculos necesarios para poner a pantalla completa los emuladores que tienen una resolución bastante diferente de la original del LCD.
En ejemplos prácticos... un emulador de Gameboy solo pinta un area de 166x144 pixels en el LCD y eso hace que se vea demasiado pequeño; lo que se hace normalmente es obligar al emulador a redimensionar esa matriz a la resolucion del LCD (ya sea con un simple reescalado por aproximación o usando filtros) antes de escribirla en el framebuffer, con el consecuente gasto de recursos que ello conlleva. Sin embargo con la funcion de reescalado del ILI9325 se podría hacer que el emulador enviase el area de 166x144 al ILI9325 y que éste, sin hacer que la CPU gastase un solo ciclo, hiciese que esa pequeña area ocupase la pantalla al completo.
Que me corrijan si me equivoco.
Estaba yo jugando a hacer ports rápidos de programas y me he acordado del gmenu2x que alguien mencionó (leed los comentarios del video!)
http://www.youtube.com/watch?v=-z8Dq9f5-h8
Esteeeee... ¿me puedes recordar qué es exáctamente esa función?
Es una función que permite redimensionar una imagen con un factor 1/2 ó 1/4 ideal, por ej, para mostrar una imagen de 640x480. Copio/pego del pdf:
8.2.7. Resizing Control Register (R04h)
When the RSZ bits are set for resizing, the ILI9325 writes the data according to the resizing factor so that the original image is displayed in horizontal and vertical dimensions, which are contracted.
ILI9325 supports resizing function (x1/2, x1/4), which is performed when writing image data to GRAM. The resizing function is enabled by setting a window address area and the RSZ bit which represents the resizing factor (x1/2, x1/4) of image. The resizing function allows the system to transfer the original-size image data into the GRAM with resized image data.
Perfecto para jugar al Broken Sword 1/2 de PSX con el ScummVM que, a pesar de mostrarlos a 640x480, se ve claramente que la resolución original es 320x240.
< - >
Sin embargo con la funcion de reescalado del ILI9325 se podría hacer que el emulador enviase el area de 166x144 al ILI9325 y que éste, sin hacer que la CPU gastase un solo ciclo, hiciese que esa pequeña area ocupase la pantalla al completo.
^^
El ILI9325 no permite ese tipo de reescalados. Es mucho más simple y chusco :D
< - >
Estaba yo jugando a hacer ports rápidos de programas y me he acordado del gmenu2x que alguien mencionó (leed los comentarios del video!)
http://www.youtube.com/watch?v=-z8Dq9f5-h8
¡Perfecto!
Yo en la GP2X no lo llegué a instalar porque no la usé ni 10 horas pero, por lo que he leído, es bastante bueno.
Estaba yo jugando a hacer ports rápidos de programas y me he acordado del gmenu2x que alguien mencionó (leed los comentarios del video!)
http://www.youtube.com/watch?v=-z8Dq9f5-h8
Madreeeemiaaaaaaaaa, ya veras cuando lo pongan en dingoo-scene o como se llame la pagina, que locura xDDD
Por cierto, aqui si que va el autentico :hype:
¡Perfecto!
Yo en la GP2X no lo llegué a instalar porque no la usé ni 10 horas pero, por lo que he leído, es bastante bueno.
En la GP2X lo he usado poco pero en la Gizmondo lo tengo puesto como menú por defecto y mejora bastante la experiencia, todo está mucho más accesible y organizado. ¿Alguien sabe donde se puede bajar para la Dingoo?
Increible ver ese GMenu2x booboo (y ese Tux cada vez que inicias Linux en la Dingoo), aunque sea una prueba de concepto, ilusión da al menos, sobre todo con esas pruebas con SDL, incluido el propio GMenu2x :D
Estaba yo jugando a hacer ports rápidos de programas y me he acordado del gmenu2x que alguien mencionó (leed los comentarios del video!)
http://www.youtube.com/watch?v=-z8Dq9f5-h8
Increible, gran trabajo booboo. Por cierto, este comentario por un tal craigix estaba en el video que has colgado:
Excellent work! It's great to see a system coming to life for the open source scene, it reminds of of the early GP32 days.
Es un trabajo maravilloso. :brindis:¿Podemos utilizar este sistema como dispositivo similar llamado Gemei X-760 + que utiliza exactamente el mismo hardware?
El dingoo es un clone de Gemei X-760 +!
Creo que podría haber problemas con los botones porque no tienen los mismos; y luego habría que ver si el LCD es el mismo, pero en principio no debería haber problema.
Fantastico ese gmenu2x!!
Si se portan todas las librerias SDL, se podria hacer un port del fenix?
Saludos.
Es un trabajo maravilloso. :brindis:¿Podemos utilizar este sistema como dispositivo similar llamado Gemei X-760 + que utiliza exactamente el mismo hardware?
El dingoo es un clone de Gemei X-760 +!
Si es un clon exacto no veo por qué no. Pero desconozco si el proceso de arranque y todo lo demás funciona igual, por lo que a menos que consiga una de esas no puedo ayudar gran cosa.
Tengo uno Gemei X-760+ y me gustaría poner a prueba!
Gracias:brindis:
Tengo uno Gemei X-760+ y me gustaría poner a prueba!
Gracias:brindis:
Hardware donations welcome :-)
< - >
Creo que he subido todo lo necesario para que todo el mundo pueda empezar a programar en para linux en la A320:
http://code.google.com/p/dingoo-linux/
Es la primera vez que uso google code así que me ha costado un poco. Iré añadiendo más info conforme el tiempo lo permita (estoy de mudanza).
Cualquier comentario para mejorar la guía que he hecho (y que está en la sección wiki del proyecto) será bienvenido.
Creo que he subido todo lo necesario para que todo el mundo pueda empezar a programar en para linux en la A320:
Habrá que darle un tiento :)
< - >
Estoy desarrollando un emulador de WonderSwan para Dingoo A320.
Codificando la parte de sonido no veo como desde las SDK puedo reproducir desde un buffer PCM (solo hay una función LoadPCM para carga desde fichero).
¿Como puedo implementar la parte de sonido sin las SDK?
¿Existe algún emulador con código fuente libre en el que funcione correctamente el sonido?
joyrider ha conseguido que funcione más o menos usando las S2D. Tienes la info aquí (http://a320.freeforums.org/pie320-0-1-pacman-emulator-t323-20.html)
Con eso que ha subido boo boo y una miniSD se puede cargar linux en la dingoo ¿no?
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.