Ver la versión completa : [OFICIAL]: Scene Dingoo A320
Rivroner
19/05/2009, 01:27
¿La bicha esta overclockeada y estable que llega a 600 mhz?
Una pregunta booboo, la segunda partición ¿puede formatearse a FAT32?
C.... en to lo que se menea que no encuentro mi adaptador a minisd , ya podrían haber usado microsd/sd.
El tema de usar la nand como va ? porque nand tenemos todos :)
Y usar cramfs (http://en.wikipedia.org/wiki/Cramfs) para el sistema de ficheros ? así solo es copiar el fichero y listo, es lo que se usaba en los experimentos con qtopia y similares con la gp2x y no iva mal de rendimiento.
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.
·Muchas gracias, he leido el manual y cuando vuelva a casa por la noche lo hago (está chupadito con un manual tan sencillo).
PD: El ftp the Ingenic no me va... ¿estará saturado por tu culpa? -> Googleando encontré un mipseltools aquí: http://www.openmobilefree.net/other/xiangfu/file/?C=S;O=A
Y para poder usar las uClibc tendriamos que bajarnos de su pagina el codigo, compilar el toolchain para mips y supongo que despues sera necesario compilar de nuevo las sdl para mips, vamos, que no sirve con las que incluyes compiladas o si??
Apunta maneras eso de linux en la dingoo ^^
Saludos
¿La bicha esta overclockeada y estable que llega a 600 mhz?
¿Ein?
< - >
Una pregunta booboo, la segunda partición ¿puede formatearse a FAT32?
No. La segunda partición tiene que ser de uno de los tipos que soporta linux y que permiten atributos especiales, no tanto por los permisos, que en la A320 no tienen importancia, sino por los archivos especiales de dispositivo que van en /dev y que no pueden crearse en FAT.
Se puede conseguir arrancar de una única partición FAT, pero complica innecesariamente las cosas: se crea un archivo gordo que es una imágen de un sistema de archivos ext2 o ext3 y se mete ahí el sistema de archivos raíz. Luego ese archivo se mete en la partición FAT. Lo que hay que hacer es montar primero el sistema FAT y luego montar el archivo gordo como si fuera un dispositivo de bloques. El problema es que el kernel no puede hacer este proceso de dos pasos, por lo que necesariamente hay que meter un pequeño programa en un initramfs que se encargue de ello.
< - >
·Muchas gracias, he leido el manual y cuando vuelva a casa por la noche lo hago (está chupadito con un manual tan sencillo).
PD: El ftp the Ingenic no me va... ¿estará saturado por tu culpa? -> Googleando encontré un mipseltools aquí: http://www.openmobilefree.net/other/xiangfu/file/?C=S;O=A
El FTP de Ingenic va como el culo cuando va. Es alucinante. Por eso puse el nombre completo del archivo suponiendo que en algún lado habría una copia.
Lo suyo sería subirlo a google code, pero ocupa 170MB y el límite de tanaño de archivos es 100MB. Me suena que alguien ya hizo en su momento una copia completa de los archivos del FTP y los puso en la web alemana de GP32.
< - >
Y para poder usar las uClibc tendriamos que bajarnos de su pagina el codigo, compilar el toolchain para mips y supongo que despues sera necesario compilar de nuevo las sdl para mips, vamos, que no sirve con las que incluyes compiladas o si??
Saludos
Exacto. La libc constituye los cimientos sobre lo que se construye todo lo demás, por lo que tiene el inconveniente de que si cambias de libc, tienes que cambiarlo todo. Hasta el propio toolchain depende de ello, con lo cual creo recordar que se da la paradoja de que necesitas el toolchain para compilar la uclibc, y necesitas la uclibc para compilar el toolchain. Lo que se hacía creo recordar que era un paso intermedio en el que se compilaba un gcc capaz de compilar sólo librerías (no ejecutables), y usándolo se compilaba la uclibc, para finalmente compilar el gcc definitivo usando la uclibc.
podrias poner una explicacion en español de todo el proceso asi como si se puede hacer desde un pc con windows?. Tambien me gustaria saber si mas adelante habra que meter mas cosas para el tema de linux con lo que tendriamos que hacer todos los pasos o asi valdria para hacer de todo para la maquina
podrias poner una explicacion en español de todo el proceso asi como si se puede hacer desde un pc con windows?.
Lo siento pero ya me cuesta bastante tiempo escribirlo una vez y en inglés. Estoy seguro de que alguien de por aquí estará encantado de echarme una mano y traducirlo.
Tambien me gustaria saber si mas adelante habra que meter mas cosas para el tema de linux con lo que tendriamos que hacer todos los pasos o asi valdria para hacer de todo para la maquina
Desde windows es posible pero infinitamente más complicado. Cuando se llegue al punto de tener lista una distribución para usuarios finales, se verá si hay alguna forma de que pueda ser instalada desde windows.
Lo que hay a día de hoy sólo es de interés para los programadores. Es mejor así porque de esta forma la gente puede ya empezar a programar aplicaciones y probarlas mientras yo sigo trabajando en mejorar el soporte hardware del kernel y en el rootfs.
espero que cuando se llegue a ese punto se pueda instalar desde windows ya que hay muchos usuarios que no usamos linux. Si no pues tocara fastidiarse y tener lo que vaya saliendo sin usar linux
Luego lo pongo en castellano, para que lo pueda entender cuanta mas gente mejor.
Sobre el toolchain, por lo que he leido en la pagina de uClibc no hace falta mas que bajarte los fuentes, compilartelos para la arquitectura que quieras con libc (parece) y ya esta
How do I compile programs with uClibc?
You will need to have your own uClibc toolchain. A toolchain consists of GNU binutils, the gcc compiler, and uClibc, all built to produce binaries for your target system linked with uClibc. You can build your own native uClibc toolchain using the uClibc buildroot system.
To build your own uClibc toolchain, follow the following simple steps:
* Point your web browser here,
* Download of copy of buildroot
* Unpack the tarball on your Linux system somewhere
* Edit the Makefile as needed if you wish to change anything.
* run 'unset CC'. Then run 'unset CXX'. Some Linux systems (i.e. Gentoo) set variables such as 'CC' in the system environment which really messes things up when cross compiling.
* run 'make menuconfig'
* Select the things you want to build. If you only want a toolchain, leave everything except the toolchain disabled.
* save your buildroot configuration.
* run 'make'
* go eat a nice wholesome sandwich, drink a pop, call a friend, play a video game, and generally find something to do. While you are waiting, buildroot will download all the needed source code and then compile things up for you.
* You should now have a shiny new toolchain, and maybe even a shiny new uClibc based root filesystem or development system, depending on the options you selected.
Supongo que no, pero, tendrias que compilar linux con las nuevas uClibc?
Molondro
19/05/2009, 10:31
espero que cuando se llegue a ese punto se pueda instalar desde windows ya que hay muchos usuarios que no usamos linux. Si no pues tocara fastidiarse y tener lo que vaya saliendo sin usar linux
Siempre puedes usar una live de linux desde CD o Pendrive, que tampoco se le han caído a nadie los anillos...
Molondro eso lo sabes tu que controlas de linux. Yo no se como va linux o si hay distribuciones que te creen un entorno y que si se quita el cd ya no tengas ese entorno. Si se puede hacer asi no tendre problemas en hacerlo cuando la cosa avance ya que no quiero tener linux en el pc, con windows me sobra
Molondro
19/05/2009, 10:40
Molondro eso lo sabes tu que controlas de linux. Yo no se como va linux o si hay distribuciones que te creen un entorno y que si se quita el cd ya no tengas ese entorno. Si se puede hacer asi no tendre problemas en hacerlo cuando la cosa avance ya que no quiero tener linux en el pc, con windows me sobra
Yo no controlo Linux, lo mío es más darme de patadas con él, es una relación de amor y odio, pero si, puedes bajarte una linux live, que grabas en un CD y arrancas dese él. No hace ningún cambio en tu HD.
Lo acabo de ver. Pues nada a ver si esto termina bien y no hace falta el pc para usarlo y van saliendo cosas. Un saludo( por cierto te das patadas con el por lo que ya controlas mas que yo XDDDDD)
_Seagal_
19/05/2009, 11:18
Aqui teneis otro emu para el que le interese, aprovechando el ejemplo de doublebuffer de flatmush he portado un emu de la recreativa mikie sin usar el s2sdk (lo cual esta guay porque ocupa poco y no hay que liarse con el c++ pero es un coñazo porque todas las pruebas las he tenido que hacer en la consola.)
el emu:
http://www.mediafire.com/download.php?ujfjzoiljwf
el codigo fuente:
http://www.mediafire.com/download.php?onghdmnootk
booboo ya tengo el documento de QuickStart traducido al castellano, añademe al proyecto y lo subo o lo pongo aquí para que hagas copy&paste.
Lo que yo decía, siempre hay alguien que traduce XDDD
Es que hoy me aburría en el curro [wei2]
PD: El ftp the Ingenic no me va... ¿estará saturado por tu culpa? -> Googleando encontré un mipseltools aquí: http://www.openmobilefree.net/other/xiangfu/file/?C=S;O=A
EL FTP de Ingenic siempre ha ido como el culo así que hace tiempo subí un mirror completo a megaupload:
Link1 (http://www.megaupload.com/?d=JMEHCKGP)
Link2 (http://www.megaupload.com/?d=4F94ECV0)
Si sólo te interesa la parte del ftp dedicada a linux, bájate el segundo enlace.
EL FTP de Ingenic siempre ha ido como el culo así que hace tiempo subí un mirror completo a megaupload:
Link1 (http://www.megaupload.com/?d=JMEHCKGP)
Link2 (http://www.megaupload.com/?d=4F94ECV0)
Si sólo te interesa la parte del ftp dedicada a linux, bájate el segundo enlace.
*ups* No recordaba que cuando probé algo en windows lo había hecho justo con las indicaciones que pusiste al principio del post.
·He conseguido hacerlo funcionar, ahora falta programar cosicas poco a poco.
Un poco más de info, que booboo con las prisas lo dejó para gurús :confused:
Primero descargar el usbtool de rockbox (http://www.rockbox.org/twiki/bin/viewfile/Main/OndaVX747?rev=2;filename=usbtool).
Al arrancar en modo USB boot, la Dingoo parecerá muerta pero si hacéis un dmesg deberíais ver algo así:
[ 2018.565047] usb 1-3: new high speed USB device using ehci_hcd and address 11
[ 2018.698513] usb 1-3: configuration #1 chosen from 1 choice
Después cargáis el incializador de hardware y la Dingoo seguirá pareciendo frita, pero la salida del comando mostrará lo siguiente:
[INFO] File size: 3144 bytes
[INFO] Searching for device...
[INFO] Found device, uploading application.
[INFO] GET_CPU_INFO: JZ4740V1
[INFO] SET_DATA_ADDRESS to 0x80000000... Done!
[INFO] Sending data... Done!
[INFO] Verifying data... Done!
[INFO] Booting device STAGE1... Done!
[INFO] Done!
Luego cargáis el kernel y véis lo siguiente:
[INFO] File size: 1220608 bytes
[INFO] Searching for device...
[INFO] Found device, uploading application.
[INFO] GET_CPU_INFO: JZ4740V1
[INFO] SET_DATA_ADDRESS to 0x80600000... Done!
[INFO] Sending data... Done!
[INFO] Verifying data... Done!
[INFO] Booting device STAGE1... Done!
[INFO] Done!
Segundos después veréis el arranque en la pantalla de la Dingoo :hype:
Para "enredar" tenéis que tener instalado el programa minicom:
(Si sois usuarios de Debian/Ubuntu)
sudo apt-get install minicom
En $HOME creáis un fichero de nombre .minirc.configuration con lo siguiente en su interior:
pu port /dev/ttyACM0
pu baudrate 57600
pu bits 8
pu parity N
pu stopbits 1
pu rtscts No
Luego ejecutáis:
A320$ minicom configuration
Y voilá, ahora como dice la documentación, usuario root sin password y a enredar :brindis:
P.D.: booboo, es curioso que el comando halt funciona pero cuando le das al interruptor no se apaga [wei]
<->
Memoria libre:
# free
total used free shared buffers
Mem: 29744 13212 16532 0 268
Swap: 0 0 0
Total: 29744 13212 16532
Salida del top:
Mem: 12856K used, 16888K free, 0K shrd, 252K buff, 2624K cached
CPU: 0.1% usr 0.1% sys 0.0% nic 99.6% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 0.01 0.01 0.00 1/19 159
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND
159 151 root R 4000 13.4 0 0.2 top
151 1 root S 4000 13.4 0 0.0 -sh
150 1 root S 4000 13.4 0 0.0 /sbin/getty 57600 /dev/ttyS0 vt102
149 1 root S 4000 13.4 0 0.0 /sbin/getty 57600 /dev/tty0
1 0 root S 3936 13.2 0 0.0 init
118 2 root SW< 0 0.0 0 0.0 [mmcqd]
37 2 root SW< 0 0.0 0 0.0 [kmmcd]
5 2 root SW< 0 0.0 0 0.0 [khelper]
123 2 root SW< 0 0.0 0 0.0 [kjournald]
2 0 root SW< 0 0.0 0 0.0 [kthreadd]
3 2 root SW< 0 0.0 0 0.0 [ksoftirqd/0]
4 2 root SW< 0 0.0 0 0.0 [events/0]
32 2 root SW< 0 0.0 0 0.0 [kblockd/0]
55 2 root SW 0 0.0 0 0.0 [pdflush]
56 2 root SW 0 0.0 0 0.0 [pdflush]
57 2 root SW< 0 0.0 0 0.0 [kswapd0]
58 2 root SW< 0 0.0 0 0.0 [aio/0]
89 2 root SW< 0 0.0 0 0.0 [mtdblockd]
104 2 root SW< 0 0.0 0 0.0 [ubiblockd]
<->
¿Hay alguna imposibilidad técnica por la que no se pueden ejecutar dos tareas al mismo tiempo? Estoy tratando de lanzar el madplay y luego hacer un top, y lo que mando a background se pone en 'stopped'.
~ # madplay Franz\ Ferdinand\ -\ 03\ -\ Take\ Me\ Out.mp3 &
MPEG Audio Decoder 0.15.2 (beta) - Copyright (C) 2000-2004 Robert Leslie et al.
[1] + Stopped (tty output) madplay Franz Ferdinand - 03 - Take Me Out.mp3
Aunque no se si es por el minicom...
Memoria libre:
# free
total used free shared buffers
Mem: 29744 13212 16532 0 268
Swap: 0 0 0
Total: 29744 13212 16532
Vaya... por lo que veo, tras lanzar el linux solo quedan unos 17Mb de RAM? vaya, no me parece mucho, si es eso la RAM disponible creo que la mitad de la RAM no es mucho, no?, vamos, que pensaba que quedaria bastante mas memoria disponible para emuladores y otros programas.
Otra cosa, se podria utilizar parte de los 4Gb de memoria interna como swap? así puedes "ampliar" algo mas la memoria.
Otra cosa, se podria utilizar parte de los 4Gb de memoria interna como swap? así puedes "ampliar" algo mas la memoria.
El uso de swap en dispositivos flash es muy controvertido. Ya que los dispositivos flash tienen un numero limitado de escrituras, y en una swap cuando hay disponible poca memoria se hacen cientos de escrituras en una misma sesion. Los mas pesimistas aseguran que te podrias quedar sin todos los sectores implicados en la partición swap inservibles en unos seis meses :miedo:
Rivroner
19/05/2009, 21:23
¿Podría alguien pasarme un enlace a algún wiki o algo donde digan las caracteríticas de la máquina y hasta donde se puede overclockear y si tiene algo de aceleración 3D? Gracias :)
Algún script o pasos para compilar la toolchain? uso powerpc xD
¿Podría alguien pasarme un enlace a algún wiki o algo donde digan las caracteríticas de la máquina
Click! (http://a320.bluwiki.com/go/About_A320)
hasta donde se puede overclockear
430
y si tiene algo de aceleración 3D?
No
<--->
@booboo: en los logs del arranque de linux de páginas anteriores, se reservaban 4MB para la IPU, ¿tienes pensado desactivarlo para ahorrar memoria?
Rivroner
20/05/2009, 00:33
Gracias A600 :)
Cuando saques tu emu de CPC aprovecharé que la gente las vende baratas pa pillarme una por 30 pavos :D
¿Sólo se puede overclokear 30 mhz O_O?
Gracias A600 :)
Cuando saques tu emu de CPC aprovecharé que la gente las vende baratas pa pillarme una por 30 pavos :D
¿Sólo se puede overclokear 30 mhz O_O?
Yo estoy to jodido porque me apeteceria trastear un poco y portar el race, por ejemplo, y con eso ya la rentabilizaba, en trasteo, que a mi me costaria posiblemente meses que funcionase algo, y en juego, que la neo geo pocket me encanta.
El problema es que ya tengo el gasto de dinero cerrado de aqui a casi finales de verano :S, asi que no hay pelas pa casi nada :S
Saludos
Rivroner
20/05/2009, 00:51
Si al ritmo que va la cosa en los próximos meses media España en "gayumbos" :D
De el quickstart:
"For most automake enabled programs, you do something like this:
./configure --host=mipsel-linux --prefix=/
make"
Perdonad, pero cómo se haría si el programa en cuestión no tiene un configure.
booboo ya tengo el documento de QuickStart traducido al castellano, añademe al proyecto y lo subo o lo pongo aquí para que hagas copy&paste.
Hecho.
P.D.: booboo, es curioso que el comando halt funciona pero cuando le das al interruptor no se apaga [wei]
Hombre, cuando ejecutas halt al final lo que pasa es que la A320 se queda "parada", pero no se apaga.
Que el botón de apagado no funcione es normal, ni squiera lo he implementado. Leerlo es muy fácil (no es más que un GPIO que identifiqué el primer día), pero el apagado es por software y no he conseguido aún averiguar cómo se hace.
¿Hay alguna imposibilidad técnica por la que no se pueden ejecutar dos tareas al mismo tiempo? Estoy tratando de lanzar el madplay y luego hacer un top, y lo que mando a background se pone en 'stopped'.
Eso es porque si mandas un programa a background y éste saca cualquier output por stdout, el sistema lo detiene. Prueba con "madplay -q" y verás como funciona.
Me acabo de dar cuenta de que sería MUY conveniente tener el programa screen para poder utilizar más de una consola al mismo tiempo.
Voy a compilarlo y lo meto en el rootfs.
< - >
Vaya... por lo que veo, tras lanzar el linux solo quedan unos 17Mb de RAM? vaya, no me parece mucho, si es eso la RAM disponible creo que la mitad de la RAM no es mucho, no?, vamos, que pensaba que quedaria bastante mas memoria disponible para emuladores y otros programas.
Ten en cuenta que en esa memoria está cargado el busybox (con TODOS los applets) más la libc.
En un futuro firmware el "init" será mínimo (en lugar de ser el de busybox) y hará poco más que lanzar la aplicación principal, la cual además estará linkada con uclibc. Todo eso no debería ocupar más de 3 ó 4 MB.
De momento lo que voy a hacer es adelgazar convenientemente a busybox (quitar todo lo que no sirve para esta máquina, como es el caso de los applets de red y demás) y compilarlo todo usando uclibc.
Otra cosa, se podria utilizar parte de los 4Gb de memoria interna como swap? así puedes "ampliar" algo mas la memoria.
Eeeeeeeemmmmm... bueno... la resupuesta corta es "sí", pero creo que es mejor no usar swap en absoluto (en la configuración actual del kernel está desativado):
1- Como ya sabes el swap libera páginas de memoria que no se usan y las graba a disco. Cuando son usadas de nuevo las recupera de disco. Esto tiene sentido cuando hay en memoria alguna aplicación cargada (o partes de la misma) que no se usan. Si tienes una aplicación que realmente está utilizando 40MB de memoria no te va a servir de nada porque el sistema se hará totalmente inusable al estar todo el rato haciendo swap de páginas hacia/desde flash conforme son usadas.
2- La memoria flash tiene un número limitado de borrados/escrituras por página, aunque los sistemas de archivos basados en NAND y los controladores integrados en las tarjetas de memoria se encargan de repartir las escrituras por todos los sectores (cuando grabas 1000 veces un mismo sector en realidad estás borrando/escribiendo en 1000 sectores distintos). Aún así, se produce un desgaste que acabará haciendo inusables algunos sectores. La cuestión es si ese momento llegará dentro de 100 años o dentro de 1 mes, y el uso que se haga del swap puede cambiar mucho las cosas. Preferiría prescindir completamente de él para mantenerme en el lado "seguro".
< - >
¿Podría alguien pasarme un enlace a algún wiki o algo donde digan las caracteríticas de la máquina y hasta donde se puede overclockear y si tiene algo de aceleración 3D? Gracias :)
CPU MIPS hasta 400MHz, con algunas instrucciones SIMD para multimedia.
32MB RAM.
4GB NAND flash interna.
LCD 320x240 16 bit (65536 colores).
Radio FM.
Salida TV.
El fabricante dice que va hasta 400MHz. El PLL interno se puede configurar para que sean 430MHz y al parecer se puede hacer con éxito.
Con la CPU a 430MHz la memoria estará funcionando a 143MHz. En la primera foto que ví de las tripas de una A320 la memoria era de 133MHz, pero en todas las demás que he visto desde entonces (incluyendo la mía) los chips de memoria eran de 166MHz.
< - >
@booboo: en los logs del arranque de linux de páginas anteriores, se reservaban 4MB para la IPU, ¿tienes pensado desactivarlo para ahorrar memoria?
El problema es que NO SE qué es exáctamente la IPU. Me parece que es algo así como una memoria compartida rápida para los players de video. ¿Alguien ha averiguado algo más?.
< - >
De el quickstart:
"For most automake enabled programs, you do something like this:
./configure --host=mipsel-linux --prefix=/
make"
Perdonad, pero cómo se haría si el programa en cuestión no tiene un configure.
Al final todo se reduce a usar las herramientas GNU con el prefijo "mipsel-linux-", es decir, para compilar mipsel-linux-gcc, por ejemplo.
Si hay un Makefile, el compilador a usar suele estar definido como una variable $(CC) cuyo valor por defecto es "gcc". Cambialo por "mipsel-linux-gcc". Seguramente tendrás que cambiar también el linker $(LD) por "mipsel-linux-ld", y así con todas las demás herramientas.
< - >
Gracias A600 :)
Cuando saques tu emu de CPC aprovecharé que la gente las vende baratas pa pillarme una por 30 pavos :D
¿Sólo se puede overclokear 30 mhz O_O?
No es tanto un problema de lo que soporte el diseño en silicio sino de cómo se genera el reloj de la CPU. En estos SOC el oscilador y el PLL van integrados, de modo que puedes generar las frecuencias que el subsistema PLL te permita, y en la A320, que sepamos, sólo permite hasta 430MHz.
(en las placas base de PC el generador de reloj es un componente separado, y como tal suele ser mucho más flexible en su configuración porque el fabricante lo que quiere es abarcar el mayor mercado posible)
Rivroner
20/05/2009, 10:34
Gracias Booboo :)
Lo que pasa con el overclcock es que me he acostumbrado a los ARM que se pueden overclokear sobre un 25 % y me extrañaba que este procesador MIPS sólo suba 30 mhz más sobre el de fábrica.
Alguien puede recomendarme un sitio para crear un mailing list?
El problema es que NO SE qué es exáctamente la IPU. Me parece que es algo así como una memoria compartida rápida para los players de video. ¿Alguien ha averiguado algo más?.
Según la wiki del rockbox:
Image Processing Unit
The Jz4740 also has an IPU which has the following features:
Video frame resize
Color space conversion: 420/444/422 YUV to RGB convert
Y en el código fuente de Ingenic:
/* Define this to reserve total 4MB contineous physical memory for IPU.
* MPlayer will use IPU to optimize the decoding process.
*
* If you do not want to run the MPlayer, you can comment it.
*/
#define CONFIG_RESERVE_IPU_MEM 1
< - >
He conseguido conectar la Dingoo con XP usando el USB serial gracias a este (http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,8,1191) driver. Uso el Tera Term con los parámetros de la guía rápida y va perfecto.
Ahora sólo tengo un problemilla. He probado un par de programas para acceder a la partición ext3 bajo XP pero no hay manera así que, ¿sería posible acceder desde la Dingoo a la partición fat32, para así poder copiar y ejecutar ficheros sin tener que estar cargando el liveCD de Ubuntu cada vez que quiero copiar algo?
Gracias Booboo :)
Lo que pasa con el overclcock es que me he acostumbrado a los ARM que se pueden overclokear sobre un 25 % y me extrañaba que este procesador MIPS sólo suba 30 mhz más sobre el de fábrica.
La velocidad del micro según el fabricante es de 360MHz por lo que son 70Mhz de subida.
cdesign30
20/05/2009, 15:26
Booboo
Ayer lo intenté la versión para Linux del A320 en un Gemei X760+. Pero el arranque no tuvo éxito. La pantalla parpadea y la conexión USB se pierde después de descargar el kernel.
He utilizado los archivos originales de la A320, pero utilicé mi usbtool compilado para Windows. Creo que el fracaso se debe a que el hardware de Dingoo y Gemei son diferentes, La pantalla LCD de la X760 + es TD030WHEA1 y no encontré la documentación técnica en la web para él.
Si usted tiene alguna idea de una modificación que puedo probarme soy agradecido.
Hoy voy a intentar el arranque usando Linux live cd y después puesto los resultados.
Saludos, Doug
Booboo
Ayer lo intenté la versión para Linux del A320 en un Gemei X760+. Pero el arranque no tuvo éxito. La pantalla parpadea y la conexión USB se pierde después de descargar el kernel.
He utilizado los archivos originales de la A320, pero utilicé mi usbtool compilado para Windows. Creo que el fracaso se debe a que el hardware de Dingoo y Gemei son diferentes, La pantalla LCD de la X760 + es TD030WHEA1 y no encontré la documentación técnica en la web para él.
Si usted tiene alguna idea de una modificación que puedo probarme soy agradecido.
Hoy voy a intentar el arranque usando Linux live cd y después puesto los resultados.
Saludos, Doug
Estoy interesado en sus resultados
Bueno chavales gracias a booboo ya está la guía de inicio rápido en español, con las cuatro cosillas que puse ayer en el post, a disfrutarlo.
http://code.google.com/p/dingoo-linux/wiki/InicioRapido
<->
I've updated the QuickStart english version in order to put some help information ;)
http://code.google.com/p/dingoo-linux/wiki/QuickStart
/* Define this to reserve total 4MB contineous physical memory for IPU.
* MPlayer will use IPU to optimize the decoding process.
*
* If you do not want to run the MPlayer, you can comment it.
*/
#define CONFIG_RESERVE_IPU_MEM 1
Eso me sonaba haberlo visto. La verdad es que si el mplayer que proporciona Ingenic utiliza el IPU, habrá que dejar esos 4MB reservados. Lo idóneo sería que ser reservaran en el momento de ser necesarios (es decir, cuando arrancamos el mplayer), sin embargo me da a mí que igual que la memoria que se usa para DMA, debe tener ciertos requerimientos especiales que quizás hagan que no se pueda garantizar que se puede reservar esta memoria a menos que se haga desde el principio.
Lo que sí que se puede hacer es seleccionar de alguna forma durante el arranque si uno quiere reservarlos o no. De esa forma, en casos extremos de emuladores que necesiten el máximo de memoria siempre se puede arrancar a propósito con la configuración sin reserva IPU.
He conseguido conectar la Dingoo con XP usando el USB serial gracias a este (http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,8,1191) driver. Uso el Tera Term con los parámetros de la guía rápida y va perfecto.
Ahora sólo tengo un problemilla. He probado un par de programas para acceder a la partición ext3 bajo XP pero no hay manera así que, ¿sería posible acceder desde la Dingoo a la partición fat32, para así poder copiar y ejecutar ficheros sin tener que estar cargando el liveCD de Ubuntu cada vez que quiero copiar algo?
La partición ext2 (o ext2, o minix, o lo que sea) sólo es en realidad necesaria para el sistema de archivos /dev, que encima acaba yendo sobre un tmpfs. No obstante, yo nunca he montado un rootfs FAT, aunque supongo que sería posible siempre que nada más arrancar se monte /dev como tmpfs y se creen en ese momento los dispositivos.
De todas formas, todo esto no es necesario. El rootfs tiene que incluir los archivos básicos del sistema pero nada más. Todo lo demás, incluyendo programas ejecutables puede ir en FAT sin problemas, así que es perfectamente viable hacer la partición FAT enorme y dejar sólo 128MB o incluso menos para el rootfs ext3.
Supongo que a la partición FAT ya puedes acceder desde Windows, y lo que me estás preguntando es en realidad cómo acceder a la partición FAT desde la propia A320: primero tienes que crear un punto de montaje en el rootfs. Como incialmente está en modo read-only, hay que hacerlo así:
mount -o remount,rw /
mkdir /mnt/fat
mount -o remount,ro /
Luego simplemente montas la partición FAT en el punto de montaje recién creado:
mount /dev/mmcblk0p1 /mnt/fat
Y ya puedes ejecutar los programas que hayas puesto en la partición fat.
< - >
Booboo
Ayer lo intenté la versión para Linux del A320 en un Gemei X760+. Pero el arranque no tuvo éxito. La pantalla parpadea y la conexión USB se pierde después de descargar el kernel.
No funcionará a menos que el LCD sea el mismo y el resto de la configuración de SDRAM y GPIO sea también idéntica. De hecho aunque no es probable, se arriesga usted a dañar el hardware de su X760+, ya que configurar un pin GPIO como salida cuando es una entrada produce un conflicto eléctrico que podría dañar el pin.
He utilizado los archivos originales de la A320, pero utilicé mi usbtool compilado para Windows. Creo que el fracaso se debe a que el hardware de Dingoo y Gemei son diferentes, La pantalla LCD de la X760 + es TD030WHEA1 y no encontré la documentación técnica en la web para él.
Si usted tiene alguna idea de una modificación que puedo probarme soy agradecido
Ni idea. Lo siento. Desconozco completamente el hardware de la X760+. Quizás más adelante pueda intertarlo, pero de momento no dispongo ni del tiempo ni de la consola., así que lo veo complicado.
Supongo que a la partición FAT ya puedes acceder desde Windows, y lo que me estás preguntando es en realidad cómo acceder a la partición FAT desde la propia A320: primero tienes que crear un punto de montaje en el rootfs.
A eso me refería. Muchas gracias :brindis:
Ahora sólo me queda instalar la toolchain en el andLinux y empezar a compilar cosillas :)
A eso me refería. Muchas gracias :brindis:
Ahora sólo me queda instalar la toolchain en el andLinux y empezar a compilar cosillas :)
·Disculpa, ¿pero podrías hacer una mini-guía mientras lo haces?.
Jamás he pasado de los makes y los configures y se me está haciendo muy cuesta arriba.
Finalmente conseguí un ejemplo.o de mi ejemplo.cpp usando el mipsel-linux-g++ pero me dice
"/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status"
Lo de la guía es un decir y comprenderé que no te apetezca hacerlo, pero si me pasas el trocito del .bash_history me harás muuuuuuy feliz.
Gracias n_n
booboo:
·Gracias por la información, pero como pongo arriba en mi universidad son pro-windows y jamás he tenido que hacer nada más lejos de makes y configures(y éso por mi cuenta).
--
Si conocéis un manual de iniciación al g++ (poco formal) os lo agracería.
A eso me refería. Muchas gracias :brindis:
Ahora sólo me queda instalar la toolchain en el andLinux y empezar a compilar cosillas :)
¿Desde windows?
Lo digo porque entonces estarás usando el toolchain cygwin del SDK... y si pasamos a usar uclibc habrá que crear también un toolchain para windows/cygwin, ¿no?.
·Disculpa, ¿pero podrías hacer una mini-guía mientras lo haces?.
Jamás he pasado de los makes y los configures y se me está haciendo muy cuesta arriba.
No te creas que yo estoy mucho mejor. Siempre he compilado en Windows con MinGW o Visual Studio y de los configures casi siempre he pasado olímpicamente :D
< - >
¿Desde windows?
Lo digo porque entonces estarás usando el toolchain cygwin del SDK...
No, voy a usar andLinux que se instala como un par de servicios en XP y tiene todas las funcionalidades de linux.
·Disculpa, ¿pero podrías hacer una mini-guía mientras lo haces?.
Jamás he pasado de los makes y los configures y se me está haciendo muy cuesta arriba.
Finalmente conseguí un ejemplo.o de mi ejemplo.cpp usando el mipsel-linux-g++ pero me dice
"/bin/ld: cannot find -lgcc_s
collect2: ld returned 1 exit status"
Lo de la guía es un decir y comprenderé que no te apetezca hacerlo, pero si me pasas el trocito del .bash_history me harás muuuuuuy feliz.
Gracias n_n
booboo:
·Gracias por la información, pero como pongo arriba en mi universidad son pro-windows y jamás he tenido que hacer nada más lejos de makes y configures(y éso por mi cuenta).
--
Si conocéis un manual de iniciación al g++ (poco formal) os lo agracería.
No necesitas un Makefile. El Makefile no es más que una automatización del proceso de compilado. Desde la línea de comandos esto debería funcionar (para un programa compuesto de un único fichero fuente llamado "test.c"):
export PATH=/opt/mipseltools-gcc412-glibc261/bin:$PATH
mipsel-linux-gcc -o test test.c
ezelkow1
21/05/2009, 08:37
So I have the uclibc toolchain built. I also used their buildtool to create a new rootfs. This has java, SDL, DirectFB support and a few other things. I also built the kernel along with it in this toolchain but I cant get the kernel to come up, or at least display anything on the dingoo output, it may be actually booting but I dont have a hardwired serial to be able to tell. I probably need the rest of your patches to actually get a working kernel building through the build tool.
I got the serial login working with this rootfs as well so I have run a few things like the javavm to make sure it runs and they seem to be working. I just got it working so I havent compared my libs to yours to see if you have anything that Im missing in this, but we can probably add them later if they are needed. If you want I can upload the toolchain and rootfs somewhere, or to the google code page, but I would need access for that. Hopefully this helps you out getting linux going further since its a rootfs based off uclibc.
Just as a note, I figured I would post on here since most of the dev work is going on here, hate to keep trying to ask questions through the dingoo scene blog and hoping that you'll check them, figured I would keep the discussion to this forum. I had been replying on there as 'Evan'. It may be useful to also setup an irc channel on freenode. Freenode hosts irc rooms for any opensource or dev work out there so I figured thats a good net to open one up on if anyone wanted to. That way there could be realtime discussions.
I will idle around in #dingoo on irc.freenode.net in case.
So I have the uclibc toolchain built. I also used their buildtool to create a new rootfs. This has java, SDL, DirectFB support and a few other things. I also built the kernel along with it in this toolchain but I cant get the kernel to come up, or at least display anything on the dingoo output, it may be actually booting but I dont have a hardwired serial to be able to tell. I probably need the rest of your patches to actually get a working kernel building through the build tool.
The kernel in the google code page is 100% functional, but configuration is critical. At first I forgot to include a valid configuration file in the svn repository. Please do a "svn update" and you'll get a ".config" file.
(since this is a monolitic kernel we are booting without a bootloader, we need to embed the kernel parameters, have a look at CONFIG_CMDLINE in .config)
I got the serial login working with this rootfs as well so I have run a few things like the javavm to make sure it runs and they seem to be working. I just got it working so I havent compared my libs to yours to see if you have anything that Im missing in this, but we can probably add them later if they are needed. If you want I can upload the toolchain and rootfs somewhere, or to the google code page, but I would need access for that. Hopefully this helps you out getting linux going further since its a rootfs based off uclibc.
I'd rather check it before posting in the google code. Can you upload it to rapishare or similar and post a link?
Just as a note, I figured I would post on here since most of the dev work is going on here, hate to keep trying to ask questions through the dingoo scene blog and hoping that you'll check them, figured I would keep the discussion to this forum. I had been replying on there as 'Evan'. It may be useful to also setup an irc channel on freenode. Freenode hosts irc rooms for any opensource or dev work out there so I figured thats a good net to open one up on if anyone wanted to. That way there could be realtime discussions.
Believe it or not, I have never used IRC, plus due to current circumstances I don't spend much time online and tend to concentrate participation in short online bursts :-). A forum is the best place, and since there's lots of non spanish speaking people joinng development, we should go somewhere else.
What about a320.freeforums.org?. I'm already registered, would you please ask too the admin to create a linux-dev specific section?
ezelkow1
21/05/2009, 10:52
Sounds good, I've never used google code so I wasnt sure if there was a way to upload and not make it public, that way things could be put there and not be for public usage. I completely understand wanting to check it out first, I would definitely want someone to look over it anyway. I did notice that I probably dont have the sdl_gfx library installed, i tried compiling gmenu2x using the uclibc toolchain and it fails since it cant find the primitives header. When I tried to add the sdl_gfx package to the uclibc buildroot tool it gets part way and then has major failures which look like they are due to the patches on the kernel, lots of problems with unrecognized opcodes and the like. However you did say sdl was very picky so maybe there are some options Im not passing, if you know what you used to build the gfx lib that would be helpful.
If i can get that gfx lib built so i can have at least gmenu building with the toolchain then I think it would be good to look over it at that point.
The kernel .config may be trickier, Ill have to look over how buildroot uses a .config in the kernel. Currently what it does is download a specified kernel revision, and then apply a patch file to it that you specify. You can of course completely opt out of building the kernel in that instance, but it would be nice to be able to build everything in the single buildroot app. I have to talk to a coworker tomorrow about submitting any changes I make since he already submits changes to uclibc and its tools.
Ill send a message tomorrow to the a320 forums head and see if he can make a dev section on there.
< - >
Just looked at the .config usage and it seems pretty simple, instead of specifying a board type I can just give it your .config. I started a build now, but I did lose my original settings so hopefully the one from my memory will work and be done in the morning.
gadgetmiser
21/05/2009, 13:44
Hello, hola everyone
I am sorry for posting in English, as I don't speak Spanish. I have set up forums at forum.dingoo-scene.com where you are all welcome to come to post about Booboo Linux development, if you wish. It may be quiet there for awhile, I think, so you can avoid less technical discussions:)
I will link to it from the dingoo-scene blog as well. If anyone would like to be a moderator, please email me larry(a)dingoo-scene.com. Booboo I will make a moderator if he wishes to register.
Thank you all
ezelkow1
21/05/2009, 15:22
I think we were hoping to have it be part of just the regular a320 forums, not its own thing. That way it is with the regular discussions as well. No need to have to go to another address and another of the 10 forums to read.
Estoy dando caña al toolchain de ingenic a ver si tengo narices de compilar el mplayer para ir teniendo cosas. El mplayer de ingenic viene con un build.jz4740 pero lo ejecuto y despues de un tiempo compilando me da un error:
mipsel-linux-gcc -mips32 -O4 -I../libswscale -I../libavcodec -DHAVE_AV_CONFIG_H -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_ISOC9X_SOURCE -I..
-I../libavutil -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -I. -I.. -I../libavutil -Wall -Wno-switch -Wpointer-arith
-Wredundant-decls -O2 -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE
-DHAVE_CONFIG_H -I/home/emilio/A320/3sw/01linux/05apps/mplayer/MPlayer-1.0rc2.org/madlib/libmad-0.15.1b -I/usr/include/freetype2 -S simple_idct.c
mxu_as simple_idct.s > simple_idct_mxu.s
make: *** [simple_idct.o] Error 2
¿Alguna idea de por donde cogerlo?
Creo que el problema esta en este fichero especial con soporte para las instrucciones de ingenic que lo genera vacio simple_idct_mxu.s...
Por otra parte en este enlace he encontrado un port de la uclib para mipsel, espero que sirva para algo ;)
http://mipsel-linux-uclib.darwinports.com/
Creo que el problema esta en este fichero especial con soporte para las instrucciones de ingenic que lo genera vacio simple_idct_mxu.s...
Puede ser que el script mxu_as incluído en la toolchain no funcione como debiera.
Bueno, la verdad es que si lo ejecutas no hace nada ni siquiera un simple mensaje diciendote que parametros tienes que pasarle, le he echado un vistazo y no está en chino, pero como si lo estuviera [wei]
<->
He mandado un correo a Ingenic a ver si hay suerte, mientras tanto intentare compilar el mplayer estandar.
<->
La version estandar de mplayer, compilar... compila :hype:
~ # ls -ltr
-rw-r--r-- 1 root root 9488761 May 19 2009 Franz Ferdinand - 03 - Take Me Out.mp3
-rwxr-xr-x 1 root root 7874864 May 21 2009 mplayer
-rw-r--r-- 1 root root 2272222 May 21 2009 fiat_stilo_aceleracion.avi
~ # ./mplayer
./mplayer: error while loading shared libraries: libfontconfig.so.1: cannot open shared object file: No such file or directory
Ahora tendre que poner y quitar opciones hasta hacerlo funcionar.
<->
Partiendo de esta configuración (http://lists.mplayerhq.hu/pipermail/mplayer-users/2007-April/066904.html), la he modificado. Y ya por lo menos funciona:
~ # ./mplayer
MPlayer 1.0rc2-4.1.2 (C) 2000-2007 MPlayer Team
CPU: SGI MIPS
Usage: mplayer [options] [url|path/]filename
En el archivo adjunto está la configuración basica para que compile y funcione ahora si que me pondré a tocar los parametros.
<->
¡¡Esto va como la seda!! :hype::hype::hype:
~ # ./mplayer audiodump.wav
MPlayer 1.0rc2-4.1.2 (C) 2000-2007 MPlayer Team
CPU: SGI MIPS
Playing audiodump.wav.
Audio file file format detected.
================================================== ========================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 22050 Hz, 2 ch, s16le, 705.6 kbit/100.00% (ratio: 88200->88200)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
================================================== ========================
AO: [oss] 22050Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 3.3 (03.2) of 20.0 (20.0) 0.8%
Ahora voy a tratar de compilarlo con soporte para mp3
Buenas. Se me ocurre darle a la Dingoo un toque mas profesional y poder usarla para ver sentencias NMEA en mi trabajo.
Pero necesitaría saber que puntos exactos del hardware podría utilizar para meterle datos, no se si me explico. Por ejemplo los datos que entran de un GPS.
Mi intención es crear una aplicación similar a la "minicom" que podemos encontrar en Linux. ¿Le ventaja? Si pudiese hacer esto, me evitaría tener que sacar el portátil cada vez que quiera ver los valores de posición y no las tensiones.
No se si es muy complejo lo que pido, pero bueno, soy algo novato en todo esto y alguna meta me tendré que poner para empezar a dar caña.
¿Alguien sabe donde puede encontrar información relacionada con lo que menciono? Y de como programar?
saludos dingueros!
Buenas. Se me ocurre darle a la Dingoo un toque mas profesional y poder usarla para ver sentencias NMEA en mi trabajo.
Pero necesitaría saber que puntos exactos del hardware podría utilizar para meterle datos, no se si me explico. Por ejemplo los datos que entran de un GPS.
Mi intención es crear una aplicación similar a la "minicom" que podemos encontrar en Linux. ¿Le ventaja? Si pudiese hacer esto, me evitaría tener que sacar el portátil cada vez que quiera ver los valores de posición y no las tensiones.
No se si es muy complejo lo que pido, pero bueno, soy algo novato en todo esto y alguna meta me tendré que poner para empezar a dar caña.
¿Alguien sabe donde puede encontrar información relacionada con lo que menciono? Y de como programar?
saludos dingueros!
La A320 tiene un puerto serie interno que es muy delicado de conectar y que además no te serviría puesto que se usa para la consola del sistema.
Cualquier cosa que quieras conectar a la A320 tendrás que hacerlo por el puerto USB. El kernel ahora mismo configura el puerto USB en modo periférico, pero hay soporte y es posible configurarlo en modo host, de modo que podrías conectar un conversor USB-RS232 estándar. El GRAN problema es que la A320 no proporciona los +5V que normalmente proporciona un puerto USB host, por lo que tendrás que proporcionarlos tú por tu cuenta. Lo maś sencillo sería conectar un hub externo con alimentación independiente, que los hay y son baratos.
hola, aun no había leído el post entero... haha ya veo que tengo la suerte de hablar contigo, que eres mas o menos el que mas domina creo.
lo que necesitaría seria el puerto RX, para la función que le quiero dar. solo necesitaría mostrar el pantalla la señal que me envía otro equipo. conectando Rx y GND tendría suficiente.
El caso es que no se si actúa como un puerto RS232, del cual yo uso el pin 2 como Rx, el 3 como Tx y el 5 como masa.
Si fuese así podría intentar meter sentencia NMEA por Rx y mostrarla directamente en pantalla. Si fuese posible.
Soldar no es ningún problema. Yo también soy electrónico y bueno, estoy cansado de soldar también jaja.
No se si voy bien encaminado con lo que intento.
Saludos y gracias ;-)
Bueno, esto ya merecía un nuevo post e incluso un video, mplayer funciona con framebuffer. :D
(Esta algo borroso :brindis:)
http://www.youtube.com/watch?v=Cvoan06J5tk
El video va muy lento, por culpa del mp3lib, ahora lo estoy compilando sin soporte mp3lib porque es pesadisimo para la dingoo, ni siquiera reproduce bien un mp3 suelto. Lo que voy a hacer y viendo que el madplay va bien, es compilar el de ingenic que al menos ese si funciona y luego el mplayer usando el soporte de madplay.
P.D.: Parece que cuando reproduces un video de mayor resolucion que la pantalla no lo escala y sale solo la region visible de esa resolucion :confused:
:hype: HYPE :hype: Esto avanza!!! como mola ver los primeros programas para "Lindoo" (nombre que me he sacado de la manga para el Linux de la Dingoo).
Bueno, esto ya merecía un nuevo post e incluso un video, mplayer funciona con framebuffer. :D
(Esta algo borroso :brindis:)
http://www.youtube.com/watch?v=Cvoan06J5tk
El video va muy lento, por culpa del mp3lib, ahora lo estoy compilando sin soporte mp3lib porque es pesadisimo para la dingoo, ni siquiera reproduce bien un mp3 suelto. Lo que voy a hacer y viendo que el madplay va bien, es compilar el de ingenic que al menos ese si funciona y luego el mplayer usando el soporte de madplay.
P.D.: Parece que cuando reproduces un video de mayor resolucion que la pantalla no lo escala y sale solo la region visible de esa resolucion :confused:
mplayer -x 320 -y 240 -vo .... o -vf scale=320:240
Mira con -fs -zoom y si funciona que es mas rápido que los anteriores -sws 4
No se si perderá mucho rendimiento así pero por probar, aparte del resto de opciones para "aligerar" como -framedrop, sin salida de errores en consola -quiet, etc.
No se si perderá mucho rendimiento así pero por probar, aparte del resto de opciones para "aligerar" como -framedrop, sin salida de errores en consola -quiet, etc.
Ya digo que el problema viene del soporte mp3, si reproduzco un mp3 con mplayer suena a saltos. Por ejemplo el video que he subido a youtube que no tiene sonido y es un AVI crudo de 30MB lo reproduce perfectamente :)
Ya digo que el problema viene del soporte mp3, si reproduzco un mp3 con mplayer suena a saltos. Por ejemplo el video que he subido a youtube que no tiene sonido y es un AVI crudo de 30MB lo reproduce perfectamente :)
Ya lo decía por el escalado y por arañar un poco de rendimiento :)
ezelkow1
22/05/2009, 01:10
Booboo, I posted this over in the a320 forums as well since I figured I would try to start posting over there. I uploaded a kernel patch for 2.6.24.3
http://rapidshare.com/files/235762652/linux-2.6.24.3-dingoo.patch.gz.html
I am using that to do a build right now with uclibc and buildroot. So far it patched the kernel just fine but I wont get to test for a while and probably wont get to work on it anymore until next week.
I ran into one issue while using it, i get this error
CC drivers/mtd/mtdchar.o
CC drivers/mtd/mtd_blkdevs.o
make[3]: *** No rule to make target `drivers/mtd/mtdblock-jz.o.original', needed by `drivers/mtd/mtdblock-jz.o'. Stop.
make[2]: *** [drivers/mtd] Error 2
make[1]: *** [drivers] Error 2
So i probably have a bit more to flesh out with the patch, but its getting there
< - >
Well I did the quick hack of just copying over that .o.original, and the kernel kept building and completed. So I was able to boot using that kernel and rootfs I build all based off of uclibc.
i will keep trying and see if I can make a patch that includes the .o.original
cdesign30
22/05/2009, 15:35
Linux en el X760 +
Booboo,
Gracias por responder. Lo que usted dice es el punto de partida para mí tratar de adaptar el código fuente del A320 para la X760 +. Estoy estudiando lo que ha dicho en su anterior puestos y el código fuente de Google Code. También he conseguido LCD Pinout de la X760 + y comparar la información con el datasheet A320.
Por ahora tengo una pregunta: ¿La parte de código que contiene la información sobre la pantalla LCD es solamente en archivo jz4047.h de hwinit o esta en archivos también?
Gracias, Doug
ezelkow1
23/05/2009, 01:09
uploaded a new patch, http://rapidshare.com/files/236032489/linux-2.6.24.3-dingoo.patch.gz.html
Looks like this one generates the .o.original file and it builds completely, so it seems we now have a solution that can build a complete kernel, filesystem, and toolchain all based off of uclibc. However there are still issues booting with it that have to be worked out. for some reason the new patch wont boot correctly even though it builds correctly
< - >
So my issues earlier were problems with my rootfs being hosed up. I have 2 patches, the links are in the a320 forums thread. There is one based on 2.6.24.3 and one based on 2.6.24. Since buildroot only uses major kernel revisions I made one based on that so I could use it inside of that utility.
This properly creates everything for the kernel build. So using that patch and buildroot I am letting it run and rebuild a complete uclibc toolchain, kernel, and rootfs, it will probably take a while so Ill test it out later.
So the only thing left with uclibc is getting buildroot to also create the sdl_gfx library, so im still hoping that you will post the options you used to build that so I can incorporate it into buildroot and have that installed in the rootfs as well. Once that builds then I will tar everything up and put it somewhere.
Después de pelearme con andLinux, al fin he conseguido instalar la toolchain y compilar el nbench.
Estos son los resultados a 336 MHz:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 83.407 : 2.14 : 0.70
STRING SORT : 7.8806 : 3.52 : 0.55
BITFIELD : 3.7062e+07 : 6.36 : 1.33
FP EMULATION : 20.192 : 9.69 : 2.24
FOURIER : 7.5995 : 0.01 : 0.00
ASSIGNMENT : 0.96043 : 3.65 : 0.95
IDEA : 372.7 : 5.70 : 1.69
HUFFMAN : 26.069 : 0.72 : 0.23
NEURAL NET : 0.010387 : 0.02 : 0.01
LU DECOMPOSITION : 0.37272 : 0.02 : 0.01
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 3.541
FLOATING-POINT INDEX: 0.014
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU :
L2 Cache :
OS : Linux 2.6.24.3-a320
C compiler : mipsel-linux-gcc
libc : static
MEMORY INDEX : 0.882
INTEGER INDEX : 0.885
FLOATING-POINT INDEX: 0.008
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
y para "compararlos", aquí están los de la GP2X hechos por jcom, supongo que a 200 MHz:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 59.536 : 1.53 : 0.50
STRING SORT : 4.1241 : 1.84 : 0.29
BITFIELD : 1.5375e+07 : 2.64 : 0.55
FP EMULATION : 6.6484 : 3.19 : 0.74
FOURIER : 66.091 : 0.08 : 0.04
ASSIGNMENT : 0.5278 : 2.01 : 0.52
IDEA : 178.22 : 2.73 : 0.81
HUFFMAN : 106.16 : 2.94 : 0.94
NEURAL NET : 0.092149 : 0.15 : 0.06
LU DECOMPOSITION : 2.8164 : 0.15 : 0.11
edito: He encontrado los resultados para el famoso por estos lares Blackfin a 600 MHz:
TEST : Iterations/sec. : Old Index : New Index
: : Pentium 90* : AMD K6/233*
--------------------:------------------:-------------:------------
NUMERIC SORT : 86.84 : 2.23 : 0.73
STRING SORT : 10.02 : 4.48 : 0.69
BITFIELD : 2.1645e+07 : 3.71 : 0.78
FP EMULATION : 13.095 : 6.28 : 1.45
FOURIER : 27.918 : 0.03 : 0.02
ASSIGNMENT : 1.6257 : 6.19 : 1.60
IDEA : 300.49 : 4.60 : 1.36
HUFFMAN : 112.99 : 3.13 : 1.00
NEURAL NET : 0.033139 : 0.05 : 0.02
LU DECOMPOSITION : 1.1078 : 0.06 : 0.04
==========================ORIGINAL BYTEMARK RESULTS==========================
INTEGER INDEX : 4.137
FLOATING-POINT INDEX: 0.046
Baseline (MSDOS*) : Pentium* 90, 256 KB L2-cache, Watcom* compiler 10.0
==============================LINUX DATA BELOW===============================
CPU : Analog Devices ADSP-BF537 600(MHz CCLK) 120(MHz SCLK) 600MHz
L2 Cache : 16 KB(L1 icache) 32 KB(L1 dcache-wb) 0 KB(L2 cache)
OS : Linux 2.6.22.19-ADI-2008R1.5-svn5350
C compiler : bfin-uclinux-gcc
libc : static
MEMORY INDEX : 0.952
INTEGER INDEX : 1.097
FLOATING-POINT INDEX: 0.025
Baseline (LINUX) : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
Tendré que preparar una versión que ejecute el test a 200 MHz para que la comparación sea más justa. Por cierto, he probado a compilarlo con -msoft-float y el muy puñetero cada vez que acaba un test saca esto:
** WARNING: The current test result is NOT 95 % statistically certain.
** WARNING: The variation among the individual results is too large.
Intentaré más tarde compilar algo de lo que saqué para la GP32 para ver cómo tira en la Dingoo.
Booboo, ya que has dicho lo del USB en modo host, sería posible que conectando la Dinggo al PC, por USB el ordenador le mandase las imagenes de la pantalla para tener una pantallita externa??
En PSP por ejemplo se puede y está el codigo disponible y tal.
Se hace virtualizando una pantalla y mandando el "vídeo" a la PSP más tarde....
Salu2!
Booboo, ya que has dicho lo del USB en modo host, sería posible que conectando la Dinggo al PC, por USB el ordenador le mandase las imagenes de la pantalla para tener una pantallita externa??
En PSP por ejemplo se puede y está el codigo disponible y tal.
Se hace virtualizando una pantalla y mandando el "vídeo" a la PSP más tarde....
Salu2!
No entiendo la pregunta, ¿puedes explicarlo mejor?
No entiendo la pregunta, ¿puedes explicarlo mejor?
Lo que le he entendido es que quiere un TV OUT, pero sacando la imagen desde el USB.
Quería decir que es impresionante todo lo que estáis haciendo, y dejo caer algo, ya que existen cables usb mini b macho a mini b macho como éste (http://www.cqcinformatica.es/cable-mini-usb-5pm5pm-de-18-mt-p-1430.html)
http://www.cqcinformatica.es/images/CABLEMINIUSB5P-0.jpg
¿Podrían llegar a usarse una segunda dingoo a modo de segundo pad para jugar versus o cooperativos? Sé que suena un poco loco, seguro es dificilísimo de implementar, ya que no es solo mandar las pulsaciones, sino que está la imagen de video y conflictos que pueden salir a montones, pero todo el mundo echa en falta algo de conectividad.
Uff... lo he explicado mal xD
Lo que me gustaría saber es si es posible usar la Dingoo como pantalla del PC, conectada por USB, os dejo un enlace al foro de EOL donde está el programa en cuestion para PSP, para que me entendais mejor:
http://www.elotrolado.net/hilo_homebrew-psp-disp-agrega-una-pantalla-extra-a-tu-pc_1175267
Un saludo y gracias por responder!!
Bueno, la verdad es que si lo ejecutas no hace nada ni siquiera un simple mensaje diciendote que parametros tienes que pasarle, le he echado un vistazo y no está en chino, pero como si lo estuviera [wei]
Con Andlinux me hace lo mismo que a ti pero he probado en Windows con cygwin y el script funciona sin problemas :lol: Voy a ver si consigo que compile.
< - >
He conseguido que compile pero me da estos errores al enlazar, así que toca pulirlos:
mplayer.o: In function `exit_player_with_rc':
mplayer.c:(.text+0x279c): undefined reference to `disable_jz4740_mxu'
mplayer.o: In function `main':
mplayer.c:(.text+0x3638): undefined reference to `enable_jz4740_mxu'
libavcodec/libavcodec.a(dsputil.o): In function `dsputil_init':
dsputil.c:(.text+0xbcc4): undefined reference to `simple_idct_put'
dsputil.c:(.text+0xbcc8): undefined reference to `simple_idct_add'
dsputil.c:(.text+0xbcd0): undefined reference to `simple_idct'
libavcodec/libavcodec.a(dsputil.o): In function `quant_psnr8x8_c':
dsputil.c:(.text+0xd39c): undefined reference to `simple_idct'
libavcodec/libavcodec.a(dv.o): In function `dvvideo_init':
dv.c:(.text+0x7f0): undefined reference to `simple_idct248_put'
libavcodec/libavcodec.a(msmpeg4.o): In function `wmv2_add_block':
msmpeg4.c:(.text+0x6f4): undefined reference to `simple_idct84_add'
msmpeg4.c:(.text+0x70c): undefined reference to `simple_idct48_add'
msmpeg4.c:(.text+0x74c): undefined reference to `simple_idct84_add'
msmpeg4.c:(.text+0x7d4): undefined reference to `simple_idct48_add'
El tema de los _mxu.s al final ha sido muy sencillo: en el tar del mplayer ya vienen todos los _mxu.s así que lo único que tienes que hacer es eliminar las referencias al mxu_as en el makefile de la carpeta libavcodec. Aunque el script funciona porque tras comparar los ficheros del tar y los generados con cygwin, no hay diferencias.
< - >
El causante del fallo al enlazar era el simple_idct.o que estaba corrupto, así que un make clean lo ha solucionado.
Mi Dingoo la tiene mi hermano así que no puedo probarlo. Si alguien quiere el binario, lo subo.
Quería decir que es impresionante todo lo que estáis haciendo, y dejo caer algo, ya que existen cables usb mini b macho a mini b macho como éste (http://www.cqcinformatica.es/cable-mini-usb-5pm5pm-de-18-mt-p-1430.html)
http://www.cqcinformatica.es/images/CABLEMINIUSB5P-0.jpg
¿Podrían llegar a usarse una segunda dingoo a modo de segundo pad para jugar versus o cooperativos? Sé que suena un poco loco, seguro es dificilísimo de implementar, ya que no es solo mandar las pulsaciones, sino que está la imagen de video y conflictos que pueden salir a montones, pero todo el mundo echa en falta algo de conectividad.
Por lo que yo sé, es posible. El puerto USB de la A320 puede funcionar tanto en modo host como en modo periférico. En una de las A320 habría que ponerlo en modo host, y en la otra en modo periférico ("gadget" en la terminología del kernel) y crear un driver que hiciera que se comportara como un dispositivo HID (human interface device... un teclado o joystick, vamos).
Para la cantidad de faena que hay que hacer y la utilidad marginal que tiene, dudo mucho que alguien se ponga a ello (y si se pusiera sería mucho más adelante cuando linux ya sea un sustituto válido para el firmware original de la A320).
< - >
Uff... lo he explicado mal xD
Lo que me gustaría saber es si es posible usar la Dingoo como pantalla del PC, conectada por USB, os dejo un enlace al foro de EOL donde está el programa en cuestion para PSP, para que me entendais mejor:
http://www.elotrolado.net/hilo_homebrew-psp-disp-agrega-una-pantalla-extra-a-tu-pc_1175267
Un saludo y gracias por responder!!
Mmmm... no veo por qué no. De nuevo se trata de crear un driver "gadget" (=periférico) para el kernel que se comporte como un display auxiliar y que muestre por pantalla de la A320 todo lo que se le envíe.
Poder se puede... pero volvemos a lo mismo. Hay que implementarlo.
ezelkow1
24/05/2009, 21:56
Posted links to my rootfs, kernel, and toolchain builds from uclibc. they are on the a320 forums, the original toolchain link got mangled in the forums so i had to repost that one.
These arent the newest, i have other builds that have a few more audio codecs along with libconfuse, oil, sysfs util, and madplay along with some other libs, but it should be a good place to start.
He estado probando el mplayer y va más lento que el caballo del malo. La IPU la está usando porque reescala perfectamente pero, con sonido, pega unos tirones de escándalo y con -nosound es leeeento.
El par de avis que he probado van a tirones con el firmware oficial y eso que son de lo más normalito.
Pego el output del mplayer:
/mnt/fat/mplayer # ./mplayer gh.avi -nosound
MPlayer 1.0rc2-4.1.2 (C) 2000-2007 MPlayer Team
CPU: SGI MIPS
Terminal type `linux' is not defined.
Playing gh.avi.
Cache fill: 0.00% (0 bytes)
AVI file format detected.
[aviheader] Video stream found, -vid 0
[aviheader] Audio stream found, -aid 1
VIDEO: [XVID] 640x480 24bpp 29.970 fps 888.2 kbps (108.4 kbyte/s)
================================================== ========================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
================================================== ========================
Audio: no sound
Starting playback...
VDec: vo config request - 640 x 480 (preferred colorspace: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.33:1 - prescaling to correct movie aspect.
[swscaler @ 0xaa20e0]No accelerated colorspace conversion found
[swscaler @ 0xaa20e0]SwScaler: using unscaled yuv420p -> bgr565 special converter
VO: [fbdev] 640x480 => 640x480 BGR 16-bit
jz Dev alloc 2: vaddr = 0x2b800000, paddr = 0x1400000 size = 0x400000 ++
++ jz47 fb_w=320, fb_h=240, phy_fb=0x1140000, fbmemlen=262144, fb_line_len=640
resize: sel = 2, n=2, m=1
resize: sel = 2, n=2, m=1
++ out_width = 319, out_heigth = 239 ++
ezelkow1
25/05/2009, 20:45
If anyone managed to download the toolchain and/or any of the other stuff, can you please upload it to that a320 file site, or anywhere else so that other people can get them? It would be much appreciated, apparently the rapidshare download limit got hit.
If anyone managed to download the toolchain and/or any of the other stuff, can you please upload it to that a320 file site, or anywhere else so that other people can get them? It would be much appreciated, apparently the rapidshare download limit got hit.
I have the kernel and the rootfs. I thought I also downloaded the toolchain but I can't find it :(
I'll upload both files to megaupload right now.
edit:
kernel (http://www.megaupload.com/?d=P339ZHH3)
rootfs (http://www.megaupload.com/?d=G6V7ZFIS)
ezelkow1
Where i can put contents of third arhive? (build_root.tar.bz2) I can put build_root folder into root or into /opt or put contents of this folder into /usr?
What PATH I can set?
Thanks, and sorry for English.
< - >
Files uploaded to webfolder: http://dingooa320.ru/downloads/ezelkow1/
ezelkow1
27/05/2009, 01:18
You can really put it wherever you want, I personally just leave it in my home folder and add it to my path, but you can put it in opt if you wish and rename it to something more official. You should not put it in /usr, that is for officially installed stuff anyway, but just add /home/whatever/build_root/usr/bin and usr/include to your path, assuming you just unpacked it to a dir named build_root in your home dir.
< - >
Just did a rootfs build including mplayer, had to just hack it up so it would use mipsel for mips, so probably alot more tuning needs to take place in the build, but it built fine.
Tried testing with an xvid and got audio and video, however playback stuttered all the time and was unusable, but worked. I was hoping building with uclibc would increase performance over what a600 had seen but apparently not much.
# mplayer motion-alvin.xvid-sample.avi
MPlayer 1.0rc1.atmel.2-4.3.3 (C) 2000-2006 MPlayer Team
CPU: SGI MIPS
Playing motion-alvin.xvid-sample.avi.
AVI file format detected.
VIDEO: [XVID] 480x352 12bpp 23.976 fps 1123.4 kbps (137.1 kbyte/s)
Clip info:
Software: VirtualDubMod 1.5.10.2 (build 2540/release)
[VO_SDL] SDL initialization failed: Unable to open mouse.
notice: Can't open /dev/tty: No such device or address
================================================== ========================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffodivx] vfm: ffmpeg (FFmpeg MPEG-4)
================================================== ========================
================================================== ========================
Opening audio decoder: [liba52] AC3 decoding with liba52
No accelerated IMDCT transform found
No accelerated resampler found
AUDIO: 48000 Hz, 2 ch, s16le, 192.0 kbit/12.50% (ratio: 24000->192000)
Selected audio codec: [a52] afm: liba52 (AC3-liba52)
================================================== ========================
AO: [oss] 48000Hz 2ch s16le (2 bytes per sample)
Starting playback...
VDec: vo config request - 480 x 352 (preferred colorspace: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.36:1 - prescaling to correct movie aspect.
SwScaler: using unscaled yuv420p -> bgr565 special converter
VO: [fbdev] 480x352 => 480x352 BGR 16-bit
can't open /dev/tty: No such device or address
A: 2.9 V: 0.8 A-V: 2.062 ct: 0.008 21/ 21 189% 23% 3069.4% 20 0
MPlayer interrupted by signal 2 in module: decode_audio
#
I uploaded the uclibc toolchain to the dingoofiles repository:
http://dl.openhandhelds.org/cgi-bin/dingoo.cgi
@booboo: He estado haciendo unas pruebas compilando el REminiscence (intérprete del juego Flashback) y he notado un par de cosas:
- el sonido no, valga la redundancia, suena (probaré con SDL_Mixer)
- los gráficos muestran el mismo efecto raro que el emu de Megadrive. Se hace patente cuando movemos a Conrad por la pantalla y parece como si las líneas pares del sprite estuvieran adelantadas.
Y otra cosilla, ¿sería posible cambiar las teclas asignadas al pad/botones con alguna función a la que le pasáramos como parámetro un array con las teclas deseadas?
Rivroner
27/05/2009, 02:10
Gracias por portar eso tío :D
¿Puede ser un problema de hardware, del lcd? ¿Sólo pasa en el emu de Megadrive?
en el emu de megadrive hay algun juego que va bien. Lo del emu de megadrive puede ser que vaya mal por los distintos niveles de scrolling?, que no los pinte correctamente?. Como ya digo hay juegos que van perfectos y en los que no hace el efecto ese raro
And the first Dingoo Linux emulator is …. ScummVM!
http://www.youtube.com/watch?v=HRsnReq2s0M&feature=player_embedded
Rivroner
27/05/2009, 18:32
en el emu de megadrive hay algun juego que va bien. Lo del emu de megadrive puede ser que vaya mal por los distintos niveles de scrolling?, que no los pinte correctamente?. Como ya digo hay juegos que van perfectos y en los que no hace el efecto ese raro
¿Podría ser por los raster effects de la megadrive? :confused:
< - >
And the first Dingoo Linux emulator is …. ScummVM!
http://www.youtube.com/watch?v=HRsnReq2s0M&feature=player_embedded
Wow, thank you man O_o
Como decía en otro hilo, la Dingoo es la tapada, su scene ya ha avanzado mucho más de lo esperado y sobretodo mucho más que la de la JxD301 esa :D [wei]
Renuente
27/05/2009, 22:48
Pues a ver si hace alguien un port del picodrive.
Rivroner
28/05/2009, 00:14
Pues a ver si hace alguien un port del picodrive.
El Picodrive usaba el segundo micro así que la cosa va a estar jodidilla.
El Picodrive usaba el segundo micro así que la cosa va a estar jodidilla.
Hombre, Picodrive usa opcionalmente el segundo micro y se puede desactivar perfectamente en compilación. Por eso se ha podido portar a la Wiz, mismamente :D
Rivroner
28/05/2009, 00:22
Hombre, Picodrive usa opcionalmente el segundo micro y se puede desactivar perfectamente en compilación. Por eso se ha podido portar a la Wiz, mismamente :D
¿Está ya para Wiz? No lo he visto.
Sé que se puede desactivar el usar el segundo micro para el sonido pero pensaba que aparte afectaba tb internamente en el emu de alguna otra forma.
Lo malo es que perderá velocidad claro, aunque a 600 mhz debería ir sobrado en Wiz.
¿Está ya para Wiz? No lo he visto.
Sé que se puede desactivar el usar el segundo micro para el sonido pero pensaba que aparte afectaba tb internamente en el emu de alguna otra forma.
Lo malo es que perderá velocidad claro, aunque a 600 mhz debería ir sobrado en Wiz.
mira lo fino ke iba en la gp32 a 150 mhz y sin segundos micros ni historias.
Disculpad si ando un poco desaparecido... acabo de cambiar de curro y me tiene un poco absorvido.
Ya tenco *casi* solucionado lo del dual boot.
@booboo: He estado haciendo unas pruebas compilando el REminiscence (intérprete del juego Flashback) y he notado un par de cosas:
- el sonido no, valga la redundancia, suena (probaré con SDL_Mixer)
¿Quizás esté usando ALSA?
- los gráficos muestran el mismo efecto raro que el emu de Megadrive. Se hace patente cuando movemos a Conrad por la pantalla y parece como si las líneas pares del sprite estuvieran adelantadas.
Yo observé también alguna cosa extraña con alguna demo de la SDL. Es MUY difícil que sea cosa del LCD porque el driver del framebuffer es muy simple. Simple en el sentido de que se limita a pasarle continuamente al LCD un bloque de datos completo correspondiente a la pantalla. Por otra parte, también me parece muy difícil que sea cosa de la SDL, porque tendría que ser un bug... podría incluso ser cosa del compilador.
¿Puedes pasarme el ejecutable compilado para que lo vea? (o mejor aún subir un video a youtube)
Y otra cosilla, ¿sería posible cambiar las teclas asignadas al pad/botones con alguna función a la que le pasáramos como parámetro un array con las teclas deseadas?
Se que el subsistema input de linux permite eso si el driver está bien escrito y yo tuve cuidado de hacerlo así, pero no se cómo se hace.
Y por cierto, me acabo de dar cuenta de que pese a lo que hablamos en su día he dejado los códigos de teclas primeros que puse (los del SNES9X). Si hay consenso los cambio a los que alguien propuso (GP2X... ¿podría alguien volverlo a postear?) y subo otra imagen del kernel.
Y ya hay algún método para linuxear la dingoo desde windows?
Y ya hay algún método para linuxear la dingoo desde windows?
booboo cologo el USBBoot.cfg (http://code.google.com/p/dingoo-linux/downloads/list) para el USB_Boot.exe, pero si te digo la verdad yo no lo he probado.
Ahora pregunta para A600 y el resto de desarrolladores, y espero no colarme:
El mxu_as del toolchain de Ingenic es un script que tiene pinta de convertir ciertas instrucciones MIPS estandar a las SIMD (MXU de Ingenic) del jz. ¿Significa esto que se podria optimizar cualquier aplicación para la dingoo pasando el mxu_as a los .s?
Bueno, si booboo dice que tiene el dual boot casi listo, será mejor esperar un poco para no dejar la dingoo "OUT" mientras no salgan mas aplicaciones linux.
Disculpad si ando un poco desaparecido... acabo de cambiar de curro y me tiene un poco absorvido.
Ya tenco *casi* solucionado lo del dual boot.
Yes!
¿Quizás esté usando ALSA?
No creo. Usa el audio de las librerías SDL y si estas están compiladas con soporte OSS, deberían funcionar. Con el ScummVM, por ej, no hay problemas; pero con el REminiscence o el Xrick no suena nada.
Yo observé también alguna cosa extraña con alguna demo de la SDL. Es MUY difícil que sea cosa del LCD porque el driver del framebuffer es muy simple. Simple en el sentido de que se limita a pasarle continuamente al LCD un bloque de datos completo correspondiente a la pantalla. Por otra parte, también me parece muy difícil que sea cosa de la SDL, porque tendría que ser un bug... podría incluso ser cosa del compilador.
Creo que tendrá que ver con el hecho que comentabas de que se está copiando constantemente por DMA el framebuffer a la GRAM del LCD.
¿Puedes pasarme el ejecutable compilado para que lo vea? (o mejor aún subir un video a youtube)
No tengo cámara así que te mando un PM con un link al ejecutable con todo lo necesario.
Y por cierto, me acabo de dar cuenta de que pese a lo que hablamos en su día he dejado los códigos de teclas primeros que puse (los del SNES9X). Si hay consenso los cambio a los que alguien propuso (GP2X... ¿podría alguien volverlo a postear?) y subo otra imagen del kernel.
D-Pad: flechas
Botón A: LCONTROL
Botón B: LALT
Botón X: SPACE
Botón Y: LSHIFT
Botón hombro izquierdo: TAB
Botón hombro derecho: BACKSPACE
START: RETURN
SELECT: ESCAPE
< - >
El mxu_as del toolchain de Ingenic es un script que tiene pinta de convertir ciertas instrucciones MIPS estandar a las SIMD (MXU de Ingenic) del jz. ¿Significa esto que se podria optimizar cualquier aplicación para la dingoo pasando el mxu_as a los .s?
No. Lo que hace es convertir las instrucciones MXU para que se puedan compilar.
Rivroner
28/05/2009, 14:55
mira lo fino ke iba en la gp32 a 150 mhz y sin segundos micros ni historias.
Ese emulador no salió en GP32 ;)
Hablamos del Picodrive de Notaz que no era lo mismo que el de Megadrive de Reesy para GP32 que tb salió en GP2X pero que era peor que el Picodrive de notaz :)
Renuente
28/05/2009, 15:36
Pues que porten el que puedan, el caso es que hace falta un emu decente de Megadrive.
Novedades del emu de snes?
Joer, es el que mas me interesa
No empecemos la casa por el tejado, que parecemos GPH con la F100, que cuando la sacaron ya había ports, pero el firm era poco menos que una pre-alpha.
Ya sé por qué no tira el sonido con el REminiscence o el Xrick y sí lo hace con el ScummVM: al inicializar el audio con las SDL, sólo si lo hacemos con desired.format = AUDIO_S16SYS; funciona. Con AUDIO_S8 o AUDIO_U8 no suena. El problema ahora es que el audio suena al doble de velocidad.
Otra cosa, ¿podrías poner el volumen del audio más bajo? Me parece que por defecto está al máximo. También no estaría mal poder cambiar el audio/brillo del LCD con power + el pad tal y como hablamos en un post anterior y que los valores del volumen/brillo se guardaran automáticamente para la próxima vez que se arranque linux.
Y ya hay algún método para linuxear la dingoo desde windows?
Mmmm... sí y no. Acabo de poner una página en el wiki de google code explicando más o menos cómo hacerlo, con una salvedad: no se cómo preparar un sistema de archivos ext2/ext3 desde windows, o sea, que se puede hacer arrancar linux en la A320 pero preparar el root filesystem sigue siendo necesario hacerlo desde linux.
En la página del wiki (QuickStartWin) hay un par de "huecos" que solicito ayuda para rellenar (lo siento, ando muy mal de tiempo):
1- ¿Cual es el driver que alguien usó para que el puerto seriel CDC ACM sea usable en Windows? (me basta con un enlace).
2- Explicación de cómo instalar el toolchain (que imagino que será cygwin-based) en Windows y cómo compilar programas.
< - >
Bueno, si booboo dice que tiene el dual boot casi listo, será mejor esperar un poco para no dejar la dingoo "OUT" mientras no salgan mas aplicaciones linux.
Lo que me estoy dando cuenta es que además de hacer que la A320 arranque en linux sin necesidad de usar un PC, he de buscar la forma de hacer que todo el proceso (incluyendo la preparación del rootfs) se pueda hacer desde Windows, porque ese será el caso de la mayoría de usuarios (que no programadores).
Lo del bootloader de los chinos de ChinaChip tiene delito. He "extraido" el SPL...
(recordatorio: el JZ4740 arranca código de ROM llamado IPL, que carga 8K de código de la NAND, llamado SPL, en la caché de instrucciones y le pasa el control)
.. de ChinaChip y lo he sustituido por el SPL del u-boot junto con el propio u-boot y una copia del SPL de ChinaChip, de forma que lo que arranca siempre es u-boot y luego desde ahí ya se puede escoger entre cargar el zImage (kernel linux) o bien cargar y ejecutar el SPL original de ChinaChip.
Pues bien... esos miserables 8K de código se niegan a funcionar en un contexto ligeramente diferente al que tienen normalmente (recién cargado por el IPL versus cargado por u-boot).
Así que parece que la única opción va a ser desensamblar y meterle mano directamente a esos 8K del SPL del firmware original. Hay varias opciones:
1- Entender por qué "casca" cuando lo lanza el u-boot en lugar del IPL (aunque sea en la misma dirección y todo lo demás).
2- Entender cómo carga de NAND el sistema operativo, modificar el código para que en función de la tecla SELECT cargue de una posición distinta, donde estará el u-boot, y compilar el u-boot para que funcione cargado en las mismas circunstancias en que se carga el sistema operativo del firmware original. Esto parece muy complicado.
3- Modificar el SPL de u-boot para que antes de hacer nada de nada, compruebe el estado de la tecla SELECT y si no está pulsada pase el control al código del SPL original. El problema es que todo esto tiene que seguir cabiendo en los 8K disponibles, es decir, una versión reducida del SPL del u-boot junto con el SPL original. Esto va a ser complicado porque creo que el SPL original usa unos 6K, dejando sólo unos 2K para meter lo que sea, y el SPL del u-boot, tal cual viene, ocupa unos 5K. Supongo que lo puedo adelgazar mucho a base de quitar cosas, pero lo veo difícil.
Comenté ya "casi" lo tengo porque he sido capaz de grabar el u-boot-spl y u-boot en la flash de tal forma que arranca y carga zImage desde la primera partición de la miniSD, pero aún no he logrado transferir con éxito el control al SPL original para que la A320 arranque normalmente.
En cuanto al otro tema, que es lo de proporcionar un rootfs que se pueda instalar desde windows, el problema se reduce a que desde windows sólo se puede usar FAT32 (no NTFS no sirve), y FAT32 no soporta dispositivos especiales (todo lo que en linux va en /dev) ni enlaces simbólicos.
Lo que se puede hacer es proporcionar un sistema de archivos ext2/ext3 en un único archivo "gordo" que se copiará en la miniSD junto a zImage. Cuando el kernel arranca, hay que ponerle un initramfs que monte la partición FAT32 de la miniSD, luego que monte el archivo "gordo" como un dispositivo loopback, y finalmente que monte ese loopback como raíz. Todo esto ya lo he hecho antes pero hace algún tiempo así que tengo que refrescarlo....
< - >
Yes!
No creo. Usa el audio de las librerías SDL y si estas están compiladas con soporte OSS, deberían funcionar. Con el ScummVM, por ej, no hay problemas; pero con el REminiscence o el Xrick no suena nada.
Oops... tienes razón, no puede estar usando ALSA porque yo no incluí la libasound en el rootfs y entonces si se hubiera compilado con ALSA daría un error de librería "missing" durante la carga del ejecutable.
Lo único que se me ocurre es que esos programas usen una frecuencia de muestreo de salida para el dispositivo de audio que no esté soportada de forma nativa por el hardware. Con ALSA en estos casos se hace un resampling por software, pero me parece que con OSS simplemente no funciona. Y es posible que algunos programas estén usando frecuencias que sí que están habitualmente soportadas por el hardware del PC pero que no lo estén por el hardware de la A320 o que el driver de los chinos sea una patata y no las implemente... a saber.
¿ Podrías echar un vistazo al código de inicialización de audio de los programas que sí sacan sonido y compararlo con el de los que no sacan audio, y comprobar si la frecuencia de muestreo de salida es diferente (o algún otro parámetro relevante como los bits por muestra, etc) ?.
Creo que tendrá que ver con el hecho que comentabas de que se está copiando constantemente por DMA el framebuffer a la GRAM del LCD.
No exáctamente. Era la demo de transparencia y lo que se veía mal no era ningún tipo de distorsión rara, sino unas líneas extrañas. No se cómo definirlo... y no tengo la cámara aquí conmigo para hacer un vídeo.
¡¿Puedes pasarme el ejecutable compilado para que lo vea? (o mejor aún subir un video a youtube)
No tengo cámara así que te mando un PM con un link al ejecutable con todo lo necesario.
Ok. Le echaré un vistazo el fin de semana.
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
Ok. Lo cambio este fin de semana y genero una nueva imágen del kernel.
¿Todos de acuerdo en que este es el mapa de teclado más lógico?
cdesign30
29/05/2009, 00:04
no se cómo preparar un sistema de archivos ext2/ext3 desde windows, o sea, que se puede hacer arrancar linux en la A320 pero preparar el root filesystem sigue siendo necesario hacerlo desde linux.
Booboo,
Sí, puede crear un sistema de ficheros ext2/ext3 a partir de Windows. He utilizado el Paragon Partition Manager. Insertar el SD in lector de tarjetas del ordenador, abra el Parangon y ha creado una partición FAT32 y una ext3. Descomprime el Rootfs usando 7-Zip, copia, com o proprio Paragon, para la partición ext3 y poner el SD in MP4.
Booboo, ayúdame, por favor. ¿Donde puedo encontrar los parámetros (en el codigo fuente) de configuracion (drivers) específicos para la LCD, SRAM e GPIO del Dingoo A320? ¿hwinit, zImage? ¿Donde? Gracias!
Doug
Ya sé por qué no tira el sonido con el REminiscence o el Xrick y sí lo hace con el ScummVM: al inicializar el audio con las SDL, sólo si lo hacemos con desired.format = AUDIO_S16SYS; funciona. Con AUDIO_S8 o AUDIO_U8 no suena. El problema ahora es que el audio suena al doble de velocidad.
Eso es un problema del driver de Ingenic, que es una patata. Que no implementen frecuencias de muestreo que no soporte directamente el hardware tiene excusa, pero que no implementen la sencillísima conversión 8 bit -> 16 bit (o signed->unsigned) es para matarlos.
Lo apunto para este fin de semana.
Otra cosa, ¿podrías poner el volumen del audio más bajo? Me parece que por defecto está al máximo.
Sí, lo se. Pero creo que lo adecuado sería compilar alguna aplicación para OSS de las que se encargan de controlar el volumen, a ser posible una de línea de comandos. Yo he programado para ALSA (donde se usa amixer o alsamixer para ese propósito) pero para OSS no tengo ni idea de cómo se hace. Si lo puedes investigar tú te lo agradecería, porque así puedo dedicarme a lo del kernel.
También no estaría mal poder cambiar el audio/brillo del LCD con power + el pad tal y como hablamos en un post anterior y que los valores del volumen/brillo se guardaran automáticamente para la próxima vez que se arranque linux.
No lo he hecho aún porque he estado pensando en la forma correcta de hacerlo. Lo voy a comentar a ver si entre todos lo aclaramos un poco:
La forma políticamente correcta de gestionar el brillo de la pantalla y el volumen del audio es en los drivers correspondientes. En el caso del audio imagino que ya se encarga OSS y en el caso del brillo hay que escribir un driver muy sencillito para el subsistema correspondiente del kernel.
Una vez hecho esto, cualquier programa de usuario puede, comunicándose con el driver correspondiente y sin conocer nada del hardware, subir o bajar el volumen y el brillo.
Evidentemente, no mola nada que CADA emulador o aplicación que se porte tenga que incluir código específico para subir o bajar el volumen o el brillo, así que tendríamos que hacer un demonio (programa que corre en segundo plano) que fuera el único que se encargara de ello... pero al ser un demonio no tiene "input" de teclado, así que ¿cómo sabe el demonio cuándo estamos pulsando las combinaciones de teclas correspondientes para controlar el volumen y el brillo?.
La respuesta está en el sistema de eventos de usuario que tiene el subsistema input del kernel. Desde un driver es posible generar eventos especiales que no van por el canal "normal" por donde van las pulsaciones de teclas sino que van a un dispositivo especial que el demonio puede abrir y leer. De esa forma, sólo tengo que hacer que el driver de teclado genere unos eventos especiales cuando se pulse ON+arriba, ON+abajo, etc... (y no generar las pulsaciones de teclas arriba, abajo, etc en esos casos).
Como decía al principio, todo esto es muy "políticamente correcto" o muy "standard compliant" porque utiliza los mecanismos que ya proporciona el kernel. Sin embargo, volvemos a lo de siempre: en un sistema tan limitado en memoria como la A320, y al que queremos sacarle tanto jugo como sea posible, interesa optimizar las cosas un poco más.
Luego está el enfoque "guarro": desde el propio driver de teclado cuando detecte las combinaciones de teclas especiales, directamente subo o bajo el volumen (en el driver OSS de audio) o el brillo (directamente al hardware, se usa el PWM7). Esto es MUY sencillo y muy rápido de hacer... y una guarrada. Además al ocurrir todo en el kernel no hay una forma directa de que una aplicación de usuario pueda mostrar el nivel actual de volumen o de brillo, aunque esto se podría solventar fácilmente haciendo esta información accesible en /proc desde el mismo driver de teclado.
Hay una alternativa sólo un poco menos guarra en el sentido de que todo sigue pasando en el kernel pero el mecanismo de comunicación entre el driver de teclado y los otros drivers es un poco más "agnóstica", y es usando los eventos sysrq. Para el que no sepa de que hablo, en linux hay una serie de combinaciones de teclas especiales que generan eventos sysrq. Otros drivers se pueden "suscribir" a esos eventos. Se suele utilizar para realizar acciones "a ciegas" en el kernel en situaciones límite, como por ejemplo cuando ha petado la consola o el entorno gráfico, y para hacer cosas como sincronizar la caché de disco o reiniciar el sistema. El caso es que es un mecanismo de comunicación estandarizado y yo puedo, desde el driver de teclado generar unos eventos sysrq propios y especiales y luego en los otros drivers "suscribirlos" a esos eventos y actuar según interese. Todo esto tendría además la ventaja de que realmente se pueden aprovechar algunos eventos sysrq estándar de linux que pueden ser útiles en la A320, como el reinicio incondicional. Así tendríamos combinaciones de teclas para subir o bajar el volumen/brillo, para reiniciar la consola, etc.
Ah!, lo olvidaba: a diferencia de las X, el framebuffer no se puede compartir por más de una aplicación, así que no sería posible hacer algo tan bonito como lo de mostrar una "transparencia" en pantalla con el nivel de volumen o de brillo cuando se modifica, tal y como hace por ejemplo ubuntu. Digo que no se podría desde una aplicación de usuario, pero SI QUE SE PODRÍA desde el kernel, sin más que establecer otra comunicación "guarra" con el driver del framebuffer. Ahí de nuevo hay dos opciones, hacer un alpha-blending opcional con un segundo framebuffer (consume memoria y CPU, pero es simple y portable), o bien implementarlo -con dos cojones- en el LCD, ya que éste permite una especie de PIP (pincture-in-picture), es decir, mostrar el contenido rectangular (¿y escalado?) de una segunda zona del buffer de GRAM sobre el buffer principal. Esto no consumiría recursos pero sería muy poco portable (estoy pensando en la x760+ y similares).
Por último, sobre lo de guardar el nivel de brillo/volumen: esto es MUCHO más jodido de lo que parece. Me explico: hay dos opciones, o bien lo guardamos en el sistema de archivos de linux (como un archivo de configuración más) o bien lo guardamos a piñon en una zona específica de la NAND flash. Lo primero tiene el inconveniente de que estos parámetros sólo se pueden leer y fijar cuando linux YA HA ARRANCADO, luego durante el arranque el brillo del display tiene que tener un valor fijo. Lo segundo es muy complicado, sobre todo si hay que mantener el firmware original, ya que hay que buscar una zona de la NAND flash (un eraseblock entero = 512KB) que no use el firmware original. Luego, además, andar borrando ese eraseblock entero cada vez que se cambia el volumen o el brillo es una barbaridad, porque la memoria NAND de la A320 es del tipo MLC y la vida típica de un eraseblock son sólo 1000 ciclos de borrado. Cuando usamos un sistema de archivos estamos usando una capa intermedia que se encarga de hacer una traducción de sectores para "repartir" el desgaste (si escribimos 100 veces en un sector en realidad se están borrando y escribiendo en sectores físicos distintos cada vez), pero si estamos escribiendo "a pelo" en un eraseblock concreto de la NAND no hay vuelta de hoja, nos acabaremos cargando el sector.
El problema se puede solucionar con algunas estrategias especiales: cuando se borra la NAND todos los bits se ponen a 1. Para escribir lo único que podemos hacer es cambiar bits de 1 a 0, pero no al revés, para lo cual es necesario borrar TODO el eraseblock. Lo que se hace es, por ejemplo, escribir tres bytes: 0x01 <volumen> <brillo>. Cuando se va a cambiar el valor, se escribe 0x00 donde había 0x01 y se escribe de nuevo 0x01 <volumen> <brillo> pero en los tres bytes siguientes. Y así sucesivamente. Para averiguar los valores de brillo y volumen hay que ir leyendo los bytes de tres en tres en el eraseblock hasta encontrar un grupo de tres en el que el primero sea 0x01. Lo que estamos haciendo es, en lugar de "sobreescribir" los valores, invalidar los anteriores y escribir unos nuevos.
En resumen: se PUEDE hacer, pero guardar los niveles en un archivo no funciona bien del todo, y usar una zona específica de la flash (como hace el firmware original) causa problemas de compatibilidad con éste y obliga a utilizar estrategias complejas para no cargarse la NAND.
< - >
Booboo,
Sí, puede crear un sistema de ficheros ext2/ext3 a partir de Windows. He utilizado el Paragon Partition Manager. Insertar el SD in lector de tarjetas del ordenador, abra el Parangon y ha creado una partición FAT32 y una ext3. Descomprime el Rootfs usando 7-Zip, copia, com o proprio Paragon, para la partición ext3 y poner el SD in MP4.
Booboo, ayúdame, por favor. ¿Donde puedo encontrar los parámetros (en el codigo fuente) de configuracion (drivers) específicos para la LCD, SRAM e GPIO del Dingoo A320? ¿hwinit, zImage? ¿Donde? Gracias!
Doug
LCD: en el kernel, archivos jz4740_slcd.h y jz4740_slcd.c. En el primero tienes la inicialización de los registros del LCD, y en el segundo la geomtría del LCD y algunas cosas específicas de la A320, como el tener que activar la señal RS# del display "manualmente" con un pin GPIO cada vez que se escribe en un registro de configuración del LCD.
SDRAM: en el código de hwinit.
GPIO: hay una página en el wiki de google code bastante extensa donde he detallado todo lo que se sobre el uso de los pines GPIO en la A320. Está lo más importante y conforme vaya averiguando lo que falta lo iré poniendo ahí.
Explorando el repositorio SVN de google code deberías poder examinar el historial de cambios y pedir "diffs" para ver en cada caso qué archivos han sido modificados y los cambios realizados.
ezelkow1
29/05/2009, 00:54
Well at work I managed to get a good build of uclibc kernel and rootfs. I can add an initramfs very easily inside the utility so if you need that that should be simple to add. Once again doing another build at home since I kept running into build issues last night.
I would think for the nand stuff it may be in the included docs, I remmember seeing some on the nand programming and there are a few jz utilities to flash the nand.
Would you mind posting the options you used to compile sdl_gfx, would be nice to compile that with uclibc and integrate it in.
1- ¿Cual es el driver que alguien usó para que el puerto seriel CDC ACM sea usable en Windows? (me basta con un enlace).
Es éste (http://archive.gp2x.de/cgi-bin/cfiles.cgi?0,0,0,0,8,1191) y como programa de terminal, recomiendo el Tera Term (http://ttssh2.sourceforge.jp/)
2- Explicación de cómo instalar el toolchain (que imagino que será cygwin-based) en Windows y cómo compilar programas.
En mi caso particular, uso andLinux (http://www.andlinux.org/) y la toolchain de Linux. Al instalar andLinux, comparto una carpeta por Samba para que sea accesible tanto en Windows como en andLinux. Si hace falta puedo escribir un pequeño tutorial este fin de semana.
Lo que me estoy dando cuenta es que además de hacer que la A320 arranque en linux sin necesidad de usar un PC, he de buscar la forma de hacer que todo el proceso (incluyendo la preparación del rootfs) se pueda hacer desde Windows, porque ese será el caso de la mayoría de usuarios (que no programadores).
Lo único que no he hecho desde Windows ha sido formatear/copiar el rootfs. Para eso he usado un CD de Ubuntu.
Otra cosa: a ver si te acuerdas de mirar lo de los modos gráficos en 8bpp.
Otra cosa: a ver si te acuerdas de mirar lo de los modos gráficos en 8bpp.
Ya lo he puesto como "issue" en google code.
Echa un vistazo a todo lo que he metido por si me he dejado algo de todo lo que se ha hablado...
Echa un vistazo a todo lo que he metido por si me he dejado algo de todo lo que se ha hablado...
El problema con el audio en 8 bits.
El problema con el audio en 8 bits.
Acabo de corregirlo. El código del driver de sonido OSS da miedito. No llega ni a alpha. Calidad nefasta, chapuzas y errores por un tubo... acojonante.
También he cambiado lo del teclado. Ahora luego cuelgo en google code un nuebo binario del kernel (el código en el repositorio svn, obviamente). ¿Podrías comprobar que el mapa de teclado ahora es correcto?.
Por favor prueba bien el tema del sonido porque a mi se me ha colgado una vez. Sólo una, y no me ha vuelto a pasar, pero si observas cualquier cosa rara, dímelo.
Otra cosa: ¿podrías probar qué tal funciona el control de volumen?. Sólo hay que compilar alguna utilidad que permita modificar el mixer de OSS. Lo digo porque no existe un control de volumen como tal, y lo que se hace es un desplazamiento a la derecha de los bits de las muestras.
Además, ahora que me acuerdo, el control de volumen no funcionará en el modo de 8 bits. Cuando tenga un rato lo arreglo.
También he cambiado lo del teclado. Ahora luego cuelgo en google code un nuebo binario del kernel (el código en el repositorio svn, obviamente). ¿Podrías comprobar que el mapa de teclado ahora es correcto?.
Es correcto.
Por favor prueba bien el tema del sonido porque a mi se me ha colgado una vez. Sólo una, y no me ha vuelto a pasar, pero si observas cualquier cosa rara, dímelo.
Me ha pasado una cosa muy rara: he compilado el REminiscence con desired.format = AUDIO_S8 y no sonaba; después he probado con desired.format = AUDIO_U8 y sonaba, pero muy mal y he notado que los altavoces olían a quemado así que he reseteado rápido. Ahora, tanto con AUDIO_S8 como con AUDIO_U8 no suena, pero sí lo hace con AUDIO_S16SYS.
Otra cosa: ¿podrías probar qué tal funciona el control de volumen?. Sólo hay que compilar alguna utilidad que permita modificar el mixer de OSS. Lo digo porque no existe un control de volumen como tal, y lo que se hace es un desplazamiento a la derecha de los bits de las muestras.
He probado con GOM (The Generic OSS Mixer) y no me deja cambiar el volumen:
gom: Overall information
gom: -------------------
gom:
gom: Configuration:
gom: Mixer special file: no_mixer_opened.
gom: Fade duration : 5 seconds.
gom: Gomii refresh : all 30 seconds.
gom: Verbosity : 1 [<=-1:ERROR, 0:QUIET, 1:NORMAL, 2:VERBOSE, >=3:DEBUG].
gom: Lock mask : (see table below).
gom: Errors detected : 0.
gom:
gom: Current mixer information:
gom: Driver used : OSS (Open Sound System) API
gom: Available channels: 0 / 25
gom: ------------------------------------------------
gom: No Name Rec Volumes Vol-0 Vol-1 Locked
gom: ------------------------------------------------
gom: ------------------------------------------------
gom: 0.vol -1 -1 -1 -1 1
gom: 1.bass -1 -1 -1 -1 1
gom: 2.treble -1 -1 -1 -1 1
gom: 3.synth -1 -1 -1 -1 1
gom: 4.pcm -1 -1 -1 -1 1
gom: 5.speaker -1 -1 -1 -1 1
gom: 6.line -1 -1 -1 -1 1
gom: 7.mic -1 -1 -1 -1 1
gom: 8.cd -1 -1 -1 -1 1
gom: 9.mix -1 -1 -1 -1 1
gom: 10.pcm2 -1 -1 -1 -1 1
gom: 11.rec -1 -1 -1 -1 1
gom: 12.igain -1 -1 -1 -1 1
gom: 13.ogain -1 -1 -1 -1 1
gom: 14.line1 -1 -1 -1 -1 1
gom: 15.line2 -1 -1 -1 -1 1
gom: 16.line3 -1 -1 -1 -1 1
gom: 17.dig1 -1 -1 -1 -1 1
gom: 18.dig2 -1 -1 -1 -1 1
gom: 19.dig3 -1 -1 -1 -1 1
gom: 20.phin -1 -1 -1 -1 1
gom: 21.phout -1 -1 -1 -1 1
gom: 22.video -1 -1 -1 -1 1
gom: 23.radio -1 -1 -1 -1 1
gom: 24.monitor -1 -1 -1 -1 1
gom: ------------------------------------------------
gom: -1 = unavailable, 1 = yes (or value), 0 = no (or value),
/mnt/fat # ./gom -C 10
gom ERROR: Can't set volume to 10 on channel 0(vol): volume unavailable.
Siento no poder ser de más ayuda :(
Es correcto.
Me ha pasado una cosa muy rara: he compilado el REminiscence con desired.format = AUDIO_S8 y no sonaba;
Eso es normal porque el driver sólo soporta los formatos U8 y S16. Añadir los demás es sencillo pero he preferido no añadir nada a parte de la corrección para que U8 suene precisamente por si algo no iba bien reducir el campo de búsqueda.
después he probado con desired.format = AUDIO_U8 y sonaba, pero muy mal y he notado que los altavoces olían a quemado así que he reseteado rápido.
:confused:
Whoa... eso SI que es RARO. Tú mismo puedes ver el cambio que he hecho en el código para que U8 funcione: han sido 5 horas intentando entender cómo funciona el driver y 10 segundos para hacer el cambio. Te explico cual era el problema y cual ha sido el cambio, porque no he hecho nada raro que pudiera afectar a tus altavoces, si bien es cierto que ahora que lo pienso por la hora que era todas las pruebas las hice con los auriculares. Y por cierto, que hay un GPIO por ahí que afecta al audio y cuya función aún no tengo clara... precisamente el efecto audible es justo lo contrario de lo que tu mencionas: cuando está en un estado determinado ese pin, los auriculares se oyen fatal, pero no afecta en absoluto a los altavoces.
El problema era el siguiente: resulta que el driver SIEMPRE (bueno... para los dos formatos soportados U8 y S16) envía el audio al hardware en formato S16, y lo que hay es código que según el formato escogido por el programa de usuario, traduce de ese formato a S16 cuando está llenando el buffer para DMA:
mono U8 --> stereo S16
stereo U8 --> stereo S16
mono S16 --> stereo S16
strero S16 --> stereo S16
(implementar conversores para los demás formatos es relativamente sencillo una vez has entendido la retorcida mente del programador que lo hizo... de hecho YA he implementado los demás formatos pero no lo he incluido todavía por el motivo que ya he mencionado antes)
Pues bien... a pesar de que el código durante el playback y grabación (no probada) siempre convierte a S16 y así lo envía al hardware, resulta que durante la inicialización del dispositivo de audio configura el hardware para un tamaño de muestra coherente con lo que el usuario ha seleccionado. En el caso de U8 tenemos que el hardware acababa configurado para muestras de 8 bit pero el driver luego le envíaba muestras de 16 bit.
Así que lo UNICO que he hecho ha sido cambiar la inicialización para que independientemente del formato de muestra seleccionado por el programa de usuario, el hardware se configure para muestras de 16 bits, que es lo que toca.
Por lo tanto, el cambio es mínimo y no veo forma de haber afectado a nada más que pueda hacer que en tu máquina suene mal. Por otra parte, como digo, lo probé con auriculares...
Esta noche lo vuelvo a probar todo bien.
Lo único que se me ocurre es lo siguiente (aunque es un poco marciano): hay varios GPIO cuya función aún no he averiguado, y en el kernel actual, en lugar de configurarlos como salida y puestos al valor que se que el firmware original pone durante el funcionamiento normal, simplemente los he ignorado durante la inicialización. Eso significa que se quedan configurados como entrada, por lo que no puede haber posible conflicto eléctrico. Ahora bien, como ese pin está conectado a la entrada de otro chip, al no estar configurado como salida la entrada de ese otro chip está "flotante", a menos que el pin lleve integrada una resistencia de pull-up o pull-down o que haya una resistencia similar externa (esas resistencias simplemente aseguran un valor "por defecto" de la señal eléctrica cuando no se expecifica explícitamente con un pin porque esté puede funcionar como salida o como entrada). Me consta que la A320 tiene un bit de configuración GPIO para deshabilitar la resistencia de pull, o sea que deben estar integradas en el pin. El valor por defecto de ese bit (que yo no modifico porque ignoro esos pines como ya he dicho) hace que el pull esté activado, por lo que el estado de la señal eléctrica no creo que sea "flotante". Todo esto lo explico porque una señal "flotante" puede tomar un valor digital u otro según el día que haga y un millón de factores más, por lo que en tu caso podría suponer un problema (saturar el amplificador o algo así) y en el mío no.
Voy a preparar un kernel que inicialice todos los GPIO desconocidos a los mismos valores que he visto en el firmware original, por si acaso. Si no lo hice en su momento es porque por el razonamiento anterior no pensaba que fuera problema.
Ah!... y en el caso de esos dos pines GPIO que sé con seguridad que tienen una función de audio, sí que los inicializo al valor del firmware original, así que tendría que ser algún otro el involucrado.
Ahora, tanto con AUDIO_S8 como con AUDIO_U8 no suena, pero sí lo hace con AUDIO_S16SYS.
*****... eso SÍ QUE ES RARO.
1- Te funciona con U8 pero huele a "torrao" y reseteas.
2- No funciona con U8, pero sí que funciona con S16SYS.
No tiene sentido. Si se ha torrado eléctricamente algo se notaría independientemente del formato de muestra...
He probado con GOM (The Generic OSS Mixer) y no me deja cambiar el volumen:
gom: Overall information
gom: -------------------
gom:
gom: Configuration:
gom: Mixer special file: no_mixer_opened.
gom: Fade duration : 5 seconds.
gom: Gomii refresh : all 30 seconds.
gom: Verbosity : 1 [<=-1:ERROR, 0:QUIET, 1:NORMAL, 2:VERBOSE, >=3:DEBUG].
gom: Lock mask : (see table below).
gom: Errors detected : 0.
gom:
gom: Current mixer information:
gom: Driver used : OSS (Open Sound System) API
gom: Available channels: 0 / 25
gom: ------------------------------------------------
gom: No Name Rec Volumes Vol-0 Vol-1 Locked
gom: ------------------------------------------------
gom: ------------------------------------------------
gom: 0.vol -1 -1 -1 -1 1
gom: 1.bass -1 -1 -1 -1 1
gom: 2.treble -1 -1 -1 -1 1
gom: 3.synth -1 -1 -1 -1 1
gom: 4.pcm -1 -1 -1 -1 1
gom: 5.speaker -1 -1 -1 -1 1
gom: 6.line -1 -1 -1 -1 1
gom: 7.mic -1 -1 -1 -1 1
gom: 8.cd -1 -1 -1 -1 1
gom: 9.mix -1 -1 -1 -1 1
gom: 10.pcm2 -1 -1 -1 -1 1
gom: 11.rec -1 -1 -1 -1 1
gom: 12.igain -1 -1 -1 -1 1
gom: 13.ogain -1 -1 -1 -1 1
gom: 14.line1 -1 -1 -1 -1 1
gom: 15.line2 -1 -1 -1 -1 1
gom: 16.line3 -1 -1 -1 -1 1
gom: 17.dig1 -1 -1 -1 -1 1
gom: 18.dig2 -1 -1 -1 -1 1
gom: 19.dig3 -1 -1 -1 -1 1
gom: 20.phin -1 -1 -1 -1 1
gom: 21.phout -1 -1 -1 -1 1
gom: 22.video -1 -1 -1 -1 1
gom: 23.radio -1 -1 -1 -1 1
gom: 24.monitor -1 -1 -1 -1 1
gom: ------------------------------------------------
gom: -1 = unavailable, 1 = yes (or value), 0 = no (or value),
/mnt/fat # ./gom -C 10
gom ERROR: Can't set volume to 10 on channel 0(vol): volume unavailable.
Siento no poder ser de más ayuda :(
Estás siendo de MUCHAayuda. Para empezar ya se qué programa usar para controlar el mixer de OSS. Es posible que el código de los chinos simplemente no funcione en lo relativo al volumen.
La verdad es que el código del OSS cuando lo miras de la impresión de que alguien lo ha hecho en una tarde y que se lo dejó a medias probando cosas. Tendría sentido si a continuación lo que hubiera hecho hubiera sido lo lógico: implementar ALSA bien. De hecho el toolchain de Ingenic contiene la librería alsa (libasound), pero claro, cuando en su día probé ALSA y no funcionaba y probé OSS y funcionó a la primera, pues me quedé con OSS.
Bueno... cuando llegue a casa me pongo a ello.
He estado mirando la forma de poder cambiar el volumen y me acordé de cómo se hacía en la gp2x (mirando en el google, también he encontrado soluciones casi idénticas para cualquier distribución de linux)
void gp2x_init()
{
soundDev = open("/dev/mixer", O_RDWR);
int vol =(((100*0x50)/100)<<8)|((100*0x50)/100);
ioctl(soundDev, SOUND_MIXER_WRITE_PCM, &vol);
}
void gp2x_set_volume(int volume)
{
int vol = (((volume*0x50)/100)<<8)|((volume*0x50)/100);
ioctl(soundDev, SOUND_MIXER_WRITE_PCM, &vol);
}
Lo he probado con distintos valores y el volumen de la Dingoo ni se inmuta (el valor que devuelve open("/dev/mixer", O_RDWR); es 3, por si te sirve de algo.)
Y aquí (http://cadaver.deadbeast.net/cgi-bin/viewvc.cgi/trunk/sound.c?revision=147&root=vtwm&view=markup) un ejemplo que usa "/dev/dsp" pero tampoco me ha funcionado:
#define AUDIO_DEV "/dev/dsp"
mixfd = open(AUDIO_DEV, O_RDWR);
if (mixfd > -1)
{
ioctl(mixfd, SOUND_MIXER_READ_PCM, &oldvol);
result = sound_vol;
val = (result) | (result <<8);
ioctl(mixfd, SOUND_MIXER_WRITE_PCM, &val);
}
cdesign30
31/05/2009, 02:03
¿cómo puedo descargar todo el código fuente del kernel de Dingoo Linux para hacer algunos cambios, compilar de nuevo y testarlo? No he encontrado esta opción en el código de Google.
Gracias,
Desde el SVN de la web http://code.google.com/p/dingoo-linux/
Con subversion
svn checkout http://dingoo-linux.googlecode.com/svn/trunk/ dingoo-linux-read-only
< - >
Una duda, dondees más recomendable descomprimir libs-20090518.tar.bz2? en
.../mipsel-4.1.2-nopic/mipsel-linux
o bien en
.../mipsel-4.1.2-nopic/
Una duda, dondees más recomendable descomprimir libs-20090518.tar.bz2? en
.../mipsel-4.1.2-nopic/mipsel-linux
o bien en
.../mipsel-4.1.2-nopic/
¿Estás usando la toolchain para ucos? Deberías usar la de linux.
Yo lo descomprimí en opt/mipseltools-gcc412-glibc261/ aunque ahora que lo pienso, es más recomendable hacerlo en opt/mipseltools-gcc412-glibc261/mipsel-linux
< - >
@booboo: al menos tres personas no pueden recuperar su Dingoo con la recovery tool después de un mal flasheo. Todas presentan los mismos síntomas: la pantalla sólo muestra rayas pero funciona con el TV-OUT.
¿Puede ser que los de Dingoo estén usando un nuevo controlador de LCD? Si es así, la han cagado a base de bien...
cdesign30
31/05/2009, 16:33
Gracias LTK666,
Desta forma sólo puedo descargar archivos individuales.
¿No hay forma de descargar todos los archivos comprimidos en un archivo?
Doug
¿No hay forma de descargar todos los archivos comprimidos en un archivo?
No. Con sourceforge sí se puede pero con google code no.
Por cierto, ten en cuenta que necesitas Linux para descargarte el código fuente ya que hay ficheros cuyo nombre no es compatible con Windows.
cdesign30
31/05/2009, 17:54
Gracias A600,
¿Usted o Booboo no pueden disponibilizarlo en un site como Mediafile o Rapidshare? Necessito para modificarlo, recompilar em ambiente Linux e hacer unas pruebas en X760+. Gracias.
¿Usted o Booboo no pueden disponibilizarlo en un site como Mediafile o Rapidshare? Necessito para modificarlo, recompilar em ambiente Linux e hacer unas pruebas en X760+. Gracias.
Click! (http://www.megaupload.com/?d=BF5FRX48)
El fichero del enlace es el código fuente actualizado el 21/05
cdesign30
31/05/2009, 21:45
Gracias A600. Cuando tengo noticias escribo aquí.
Would you mind posting the options you used to compile sdl_gfx, would be nice to compile that with uclibc and integrate it in.
./configure --host=mipsel-linux --prefix=/ --disable-mmx
< - >
¿cómo puedo descargar todo el código fuente del kernel de Dingoo Linux para hacer algunos cambios, compilar de nuevo y testarlo? No he encontrado esta opción en el código de Google.
Gracias,
Tienes que instalar subversion ("apt-get install subversion") y luego:
svn checkout http://dingoo-linux.googlecode.com/svn/trunk/ dingoo-linux
cd dingoo-linux
make a320-defconfig
make zImage
Si haces algún cambio en el código que quieras enviarme para que lo incluya en el repositorio:
svn diff > mychanges.patch
Y me envías el ficherito.
< - >
@booboo: al menos tres personas no pueden recuperar su Dingoo con la recovery tool después de un mal flasheo. Todas presentan los mismos síntomas: la pantalla sólo muestra rayas pero funciona con el TV-OUT.
¿Puede ser que los de Dingoo estén usando un nuevo controlador de LCD? Si es así, la han cagado a base de bien...
Entiendo que quieres decir que el flasheo parece funcionar aunque en la pantalla no sale lo de "firmware upgrade" y luego una vez terminado salen rayas pero sí que funciona con el TV-out.
Yo diría que lo del cambio de LCD es la única explicación. La única forma de confirmarlo es que aguno de esos la destripe y haga unas cuantas fotos.
Seguramente tendrán un firmware que soporte los dos LCD y aún no lo habrán sacado, pero eventualmente lo harán. En ese momento sólo hay que sustituir el .HXF que viene con el unbricker por el nuevo .HXF.
Para el tema de linux la cosa es algo más peliaguda. Necesito el .dl de inicialización para el nuevo LCD (si no recuerdo mal el del IL9325 te lo pasó una tal Sofía de Dingoo). Evidentemente ahora que se más o menos lo que busco seguramente pueda encontrar el código en cuestión en la flash de una A320 con el nuevo LCD, pero es muuuucho más laborioso que ir directamente a donde sabes que está...
Si puedes, ponte en contacto con Sofía y coméntale el tema, a ver si te confirma que han cambiado el LCD y te proporciona una nueva herramienta de unbricking (o un nuevo .dl de inicialización).
cdesign30
01/06/2009, 00:24
Tienes que instalar subversion ("apt-get install subversion") y luego:
svn checkout http://dingoo-linux.googlecode.com/svn/trunk/ dingoo-linux
cd dingoo-linux
make a320-defconfig
make zImage
Si haces algún cambio en el código que quieras enviarme para que lo incluya en el repositorio:
svn diff > mychanges.patch
Y me envías el ficherito.
Gracias Booboo. Esta semana he de instalar una nueva versión de Linux en mi ordenador y hacer esto.
Yo diría que lo del cambio de LCD es la única explicación. La única forma de confirmarlo es que aguno de esos la destripe y haga unas cuantas fotos.
Los usuarios con problemas también pueden conectarse a un televisor y entrar el modo de información en el dispositivo sin "destriparlo".
Entre el "About" (en el menú del sistema) y presione la secuencia arriba-derecha-abajo-arriba-derecha-abajo. Un menú oculto mostra o modelo de la pantala y otras informaciones. En un Dingoo deberia aparecer "LCD MODULE: LCM_MOUDLE_ILI9325".
Otra pregunta: ¿ qué programa usted utiliza para "disassemblar" una DL? Lo unbricker de X760+ tiene una DL (GM760_TD030WHEA1_RGB.dl) que es utilizado na inicializaión de su LCD. Yo utilizei "dl_analyser" gracias a una información de A600 para obtener las entradas y "mips-linux-objdump" para "disassembrarlo", pero no sé muy bien las instrucciones de la MIPS o si estoy interpretando correctamente, aún estoy quemando la cabeza con eso.
Gracias
mragonias
01/06/2009, 01:32
He recibido hace muy pocos dias la Dingoo. Esto es lo que pone sobre el sistema:
LCD MODULE: LCM_FAIR_ILI9331_3...os concuerda?
Otra pregunta: ¿ qué programa usted utiliza para "desensamblar" una DL? Lo unbricker de X760+ tiene una DL (GM760_TD030WHEA1_RGB.dl) que es utilizado na inicializaión de su LCD. Yo utilizei "dl_analyser" gracias a una información de A600 para obtener las entradas y "mips-linux-objdump" para "desensamblarlo", pero no sé muy bien las instrucciones de la MIPS o si estoy interpretando correctamente, aún estoy quemando la cabeza con eso.
Gracias
Fixed :) un error lo tiene cualquiera
He recibido hace muy pocos dias la Dingoo. Esto es lo que pone sobre el sistema:
LCD MODULE: LCM_FAIR_ILI9331_3...os concuerda?
Concuerda que han cambiado el controlador. Posiblemente el 9325 ya no lo fabriquen (o sea más caro) y han colocado el 9331.
edit: he estado mirando el datasheet y parece que es el mismo pero sin la función resize aunque añade CABC (Content Adaptive Brightness Control) así que probablemente sólo cambie la manera de inicializarlo y de ahí que palme si lo tratamos de recuperar.
Gracias Booboo. Esta semana he de instalar una nueva versión de Linux en mi ordenador y hacer esto.
Los usuarios con problemas también pueden conectarse a un televisor y entrar el modo de información en el dispositivo sin "destriparlo".
Entre el "About" (en el menú del sistema) y presione la secuencia arriba-derecha-abajo-arriba-derecha-abajo. Un menú oculto mostra o modelo de la pantala y otras informaciones. En un Dingoo deberia aparecer "LCD MODULE: LCM_MOUDLE_ILI9325".
Muy buena puntualización.
Otra pregunta: ¿ qué programa usted utiliza para "disassemblar" una DL? Lo unbricker de X760+ tiene una DL (GM760_TD030WHEA1_RGB.dl) que es utilizado na inicializaión de su LCD. Yo utilizei "dl_analyser" gracias a una información de A600 para obtener las entradas y "mips-linux-objdump" para "disassembrarlo", pero no sé muy bien las instrucciones de la MIPS o si estoy interpretando correctamente, aún estoy quemando la cabeza con eso.
Yo también intenté utilizar alguna herramienta que ví por ahí para interpretar los contenidos de un .dl pero no funcionó. Al final me puse con un editor hexadecimal y deduje más o menos el formato, entonces extraje la sección "PRAW" entera a un fichero binario y lo desensamblé con el IDA (procesador mipsl), para a continuación dar nombre a las funciones exportadas (sección "EXPT") y a las importadas (sección "IMPT").
La verdad es que no esperaba tener que desensamblar otro .dl así que no tomé muchas notas, pero lo conservo todo así que no me sería demasiado difícil desensamblar otro .dl. No obstante, ten en cuenta que a parte de desensamblar e intepretar el contenido de la .dl, tuve que hacer bastantes experimentos para averiguar la configuración básica GPIO.
Intentar hacer que linux arranque en una x760+ sin disponer de una consola serie es casi imposible, ya que estás literalmente "ciego". Lo primero que hay que hacer es abrir la x760+, buscar los testpoints del puerto serie y conectar un adaptador LVTTL-RS232.
< - >
He recibido hace muy pocos dias la Dingoo. Esto es lo que pone sobre el sistema:
LCD MODULE: LCM_FAIR_ILI9331_3...os concuerda?
Pues eso es la confirmación: han cambiado el modelo del LCD. Yo ya he encontrado el datasheet del ILI9331 (aunque ni siquiera aparece en la web del fabricante), pero hay que tener en cuenta que la secuencia de inicialización del ILI9325 (valores escritos en unos 60 registros !!!) la saqué por ingeniería inversa del .DL que venía con el unbricker. Eso significa que para dar soporte al ILI9331 tengo primero que estudiar el datasheet del ILI9325, entender qué significan esas 60 escrituras, y luego hacer los cambios pertinentes para lograr el mismo efecto en el ILI9331.
Lo más sencillo sería obtener un .DL para el nuevo LCD de la misma fuente que lo proporcionó anteriormente (Sofía). Para mí sería mucho más sencillo. No me gusta leer datasheets porque ya lo hago bastante en el curro.
Y recemos para que no hayan cambiado algo más del hardware de la A320.
Yo no tengo inconveniente en seguir dedicando tiempo a hacer que el kernel funcione con el nuevo LCD o en la x760+, pero es sencillamente imposible si no tengo al menos un ejemplar de cada, y si empiezo a gastarme la pasta así mi mujer me echa de casa.
Yo no tengo inconveniente en seguir dedicando tiempo a hacer que el kernel funcione con el nuevo LCD o en la x760+, pero es sencillamente imposible si no tengo al menos un ejemplar de cada, y si empiezo a gastarme la pasta así mi mujer me echa de casa.
Bueno hombre, ya has hecho un trabajo titánico con lo que tenemos hasta hoy, no es bueno sobrresforzarse porque luego uno se quema y pierde el interés.
Haz cosas que te gusten y si te ves con fuerzas date de cabezazos con el nuevo LCD ;) (tambien puedes explicar un el proceso de ingeniería inversa porque así podran currarselo otros... eso es la scene).
Pues eso es la confirmación: han cambiado el modelo del LCD. Yo ya he encontrado el datasheet del ILI9331 (aunque ni siquiera aparece en la web del fabricante), pero hay que tener en cuenta que la secuencia de inicialización del ILI9325 (valores escritos en unos 60 registros !!!) la saqué por ingeniería inversa del .DL que venía con el unbricker. Eso significa que para dar soporte al ILI9331 tengo primero que estudiar el datasheet del ILI9325, entender qué significan esas 60 escrituras, y luego hacer los cambios pertinentes para lograr el mismo efecto en el ILI9331.
Parece que todos los registros coinciden a excepción del desaparecido "resize" y los nuevos dedicados al CABC.
Lo más sencillo sería obtener un .DL para el nuevo LCD de la misma fuente que lo proporcionó anteriormente (Sofía).
Le acabo de escribir un correo a Sofía así que a ver si hay suerte y se porta como la última vez :)
Parece que todos los registros coinciden a excepción del desaparecido "resize" y los nuevos dedicados al CABC.
Creo que tengo la solución:
He estado examinando los volcados que tengo de mi NAND flash y me he dado cuenta de que lo que hay a partir del offset 0x000C del segundo eraseblock es exáctamente el contenido del archivo A320_PD27_ILI9325_RLS.dl (está grabado en formato de flash de páginas de 2K en lugar de 4K, pero da igual, es muy fácil extraerlo).
Tiene sentido: el proceso de inicialización del hardware (SDRAM, LCD, etc) forma parte de las primeras fases del proceso de arranque, y este código NO SE TOCA cuando hay una actualización de firmware (se modifica el ccpmp.bin, los emuladores, etc...).
Así que lo único que necesito en principio es que alguien me pase un volcado de la NAND flash de una A320 con un LCD de los nuevos. Voy a reiniciar el ordenador en windows para volver a hacerlo con la mía (hay que usar el USB_Boot.exe) y posteo las instrucciones detalladas.
He dicho "en principio" porque aquí sí que sólo hay una oportunidad: o funciona a la primera o no puedo hacer nada, ya que no dispongo de A320 con LCD nuevo para depurar.
Creo que tengo la solución:
He estado examinando los volcados que tengo de mi NAND flash y me he dado cuenta de que lo que hay a partir del offset 0x000C del segundo eraseblock es exáctamente el contenido del archivo A320_PD27_ILI9325_RLS.dl (está grabado en formato de flash de páginas de 2K en lugar de 4K, pero da igual, es muy fácil extraerlo).
*****, entonces tiene cojones que la Sofía me dijera durante dos semanas que los ingenieros estaban "trabajando" en ello si al final resulta ser algo así :ametra:
Los que tienen la Dingoo brickeada te van a hacer un monumento.
*****, entonces tiene cojones que la Sofía me dijera durante dos semanas que los ingenieros estaban "trabajando" en ello si al final resulta ser algo así
Los que tienen la Dingoo brickeada te van a hacer un monumento.
Empezando por mi, si me dan una pista de como volvcar la NAND de mi consola lo hago con gusto, tengo el winxp no se si pueda de esta forma, eso si ya actualicé mi dingoo y me dio el problema. Afecta en algo?
salu2
*****, entonces tiene cojones que la Sofía me dijera durante dos semanas que los ingenieros estaban "trabajando" en ello si al final resulta ser algo así :ametra:
Los que tienen la Dingoo brickeada te van a hacer un monumento.
Estaban "trabajándose" a los de ChinaChip para que les dieran la información...
Empezando por mi, si me dan una pista de como volvcar la NAND de mi consola lo hago con gusto, tengo el winxp no se si pueda de esta forma, eso si ya actualicé mi dingoo y me dio el problema. Afecta en algo?
El problema que tienes es que al haber usado el unbricker con el .dl del ILI9325 eso será lo que habrá en tu NAND.
Empezando por mi, si me dan una pista de como volvcar la NAND de mi consola lo hago con gusto, tengo el winxp no se si pueda de esta forma, eso si ya actualicé mi dingoo y me dio el problema. Afecta en algo?
salu2
Como ya llevaba tiempo pensando en ello, me he hecho el ánimo y he creado un blog. Así iré posteando mas cómodamente los progresos y de paso pongo el botoncito de "donate", y así quizás en algún momento pueda comprar una x760+ o una A320 con el LCD nuevo.
Acabo de postear una entrada con las instrucciones para hacer un volcado de la NAND y enviármelo:
http://dingoo-linux.blogspot.com/
Es decir mi consola no sirve para tal efecto, en todo caso he pedido otra de color negro y ni bien me llegue (ojalá esta semana ) y si nadie a colaborado al respecto con gusto lo haré.
Gracias por todo su esfuerzo y bueno con gusto colaboraré una vez que en el curro me paguen ;)
salu2
mragonias
01/06/2009, 13:02
Pues yo que lo haria encantado (tengo la nueva LCD) no dispondre de windows hasta esta noche, ahora mismo solo Mac.
Rivroner
01/06/2009, 13:05
¿Alguien me explica lo del LCD nuevo? ¿Que son las negras? ¿En qué mejora este LCD o cambia?
Gracias :)
Se supone que si alguien con la nueva pantalla cuelga su A320.HXF y la gente que tiene la pantalla "disfuncional" actualiza su dingoo con ella se arreglaría su problema. ¿No?.
Pues yo que lo haria encantado (tengo la nueva LCD) no dispondre de windows hasta esta noche, ahora mismo solo Mac.
Parece que no va a hacer falta :) Sofía me ha mandado la recovery tool con el nuevo .dl
Click! (http://www.megaupload.com/?d=KI7J3SAV)
@ChepoXX: pruébalo en cuanto puedas para confirmar que funciona.
edit: he comparado el nuevo dl con los dumps que ha subido vapidity999 al blog (http://dingoo-linux.blogspot.com) de booboo y está ahí. Concretamente en la posición 0x4000C del fichero dump_2K.bin
Comprobado, ni bien empieza la actualización (duranto los primeros 5 segundos) la pantalla regresa a la vida, luego de terminar la actualización la dingo queda como nueva, comprobado que funciona, por lo menos en la mía a la primera. Muchas gracías booboo, A600 y sofía jeje esto servirá para todos los que estan comprando nuevas dingoos y actualicen el sistema, por otro me imagino que el nuevo controlador se deberá incorporar en las nuevas versiones de linux. Muchas gracias otra vez.
comprobado que funciona, por lo menos en la mía a la primera.
Cojonudo :brindis:
Rivroner
01/06/2009, 14:44
¿Alguien me explica lo del LCD nuevo? ¿Que son las negras? ¿En qué mejora este LCD o cambia?
Gracias :)
¿Alguien me explica lo del LCD nuevo? Gracias :brindis:
¿Alguien me explica lo del LCD nuevo? Gracias :brindis:
Es el nuevo controlador de LCD. Digamos que es el elemento que se encarga de comunicar el SOC con el LCD y que los de Dingoo han cambiado por una versión más (supuestamente) nueva, aunque a priori parecen casi idénticos.
pero lo del nuevo lcd afecta a la scene existente o futura?
pero lo del nuevo lcd afecta a la scene existente o futura?
Ahora mismo, sí (linux no funciona con las nuevas Dingoos)
Ahora mismo, sí (linux no funciona con las nuevas Dingoos)
***** vaya palo,acabo de pedir la mia a HG y estas eran una nueva remesa .
pero lo del nuevo lcd afecta a la scene existente o futura?
Mmm... no es tanto lo del nuevo LCD como el hecho de que vayan haciendo estos cambios alegremente.
Respecto a linux, la cosa se reduce a volver a repetir lo que hice con el anterior fichero .DL e incorporar lo averiguado al driver de framebuffer del kernel.
Lo que no acabo de tener muy claro es cómo hacer para que la cosa funcione en los dos LCD. Lo más sencillo es evidentemente ponerlo como una opción de compilación y luego distribuir dos binarios, pero estaría mucho mejor detectar el tipo de LCD y realizar la inicialización que toque en cada caso. No estoy seguro de que sea posible porque me parece que en la A320 no se pueden leer los registros del display por el diseño del hardware... eso suponiendo que se pueda identificar el LCD leyendo los registros... ya lo comprobaré.
***** vaya palo,acabo de pedir la mia a HG y estas eran una nueva remesa .
Ahora mismo sí afecta, pero en un futuro (posiblemente cercano) la situación puede cambiar si booboo consigue con la nueva información disponible del controlador del LCD que las nuevas Dingoos ejecuten linux.
Pero para eso booboo necesita el hardware y las donaciones para conseguirlo. Yo ya he le he mandado unos eurillos para agradecerle el inmenso trabajo que está haciendo por la scene.
***** vaya palo,acabo de pedir la mia a HG y estas eran una nueva remesa .
Tranqui. Prácticamente te puedo garantizar que el kernel soportará el nuevo LCD en breve. La cosa puede ir desde un par de días (lo que tarde en desensamblar el nuevo .DL, ver las diferencias y trasladarlas al código del driver framebuffer) hasta un mes si la cosa no funciona a la primera y he de comprar una de las nuevas A320, esperar a que llegue e instalarle la conexión de consola.
javili23
01/06/2009, 17:50
bueno, pues ayer mi dingo murio...bueno, mas bien se partio la pantalla por un golpe :(
Cual me compro? la nueva con nuevo lcd o la vieja?
adamantibus
01/06/2009, 17:59
Cual me compro? la nueva con nuevo lcd o la vieja?
No creo que puedas elegir, aunque las negras tienen más posibilidades de llevar el LCD nuevo.
No creo que puedas elegir, aunque las negras tienen más posibilidades de llevar el LCD nuevo.
En esto no estoy de acuerdo, es decir puedes ver en internet muchos videos de la dingoo negra con linux o hombrew, etc. Que la dingo negra es mas nueva es verdad pero no por ello trae el nuevo controlador de la pantalla.
La primera dingoo que se conoció con el nuevo controlador (creo que fue la mia) y de color blanca, ya me va a llegar una negra que pedi y veamos como va la cosa, pero creo que si compras una dingo nueva tiene la misma posiblidad de traiga el nuevo controlado sin importar si es negra o blanca.
Mmm... no es tanto lo del nuevo LCD como el hecho de que vayan haciendo estos cambios alegremente.
Exacto, estoes lo mas preocupante, no vaya a ser que de repente quieran cambiar el procesador, u otro elemento (audio, controles,etc) sin avisar ni con actualizaciones, etc. Todo el trabajo de poner linux quedaría en nada en las nuevas consolas.
A mi me llegó el jueves pasado, despues de esperar 15 días, es una negra:
-LCD MODULE: LCM_MOUDLE_ILI9325
y viene con firm 1.03 de serie
Saludos.
A mi me llegó el jueves pasado, despues de esperar 15 días, es una negra:
-LCD MODULE: LCM_MOUDLE_ILI9325
y viene con firm 1.03 de serie
Saludos.
es la antigua
PD:vaya tela,no sabia que los firmwares oficiales brickean las nuevas consolas.
es la antigua
PD:vaya tela,no sabia que los firmwares oficiales brickean las nuevas consolas.
No. El firmware es exactamente el mismo para todas las consolas; lo único que pasa es que si le metes uno no oficial (u oficial) y por lo que sea no se flashea correctamente, no podías recuperarlo.
< - >
Acabo de poner una página en el wiki de google code explicando más o menos cómo hacerlo, con una salvedad: no se cómo preparar un sistema de archivos ext2/ext3 desde windows, o sea, que se puede hacer arrancar linux en la A320 pero preparar el root filesystem sigue siendo necesario hacerlo desde linux.
Un post de ainu en los foros de dingoo-scene me ha descubierto una opción relativamente sencilla que no requiere linux para nada:
Se trata de flashnul (http://hdddatarecovery.blogspot.com/2009/01/flashnul.html), una utilidad open source que permite crear una imagen exacta de la tarjeta para poder replicarla. La única pega es que algún borrico podría cagarla con el programa y cepillarse el disco duro si es demasiado torpe.
El funcionamiento es muy sencillo:
flasmul -p
muestra las unidades físicas con un número asociado, así que si nuestra tarjeta es la unidad 2 con este comando:
flashmul 2 -S image.bin
creamos la imagen de la tarjeta y con
flashmul 2 -L image.bin
la grabamos.
Lo suyo sería crear imágenes ya preparadas con una partición FAT bastante grande y la partición EXT3 con el rootfs para tarjetas de 1, 2, 4 y 8 GB para que los usuarios de Windows pudieran grabarlas sin problemas.
La prueba que he hecho con una tarjeta de 2GB ha funcionado sin problemas.
No. El firmware es exactamente el mismo para todas las consolas; lo único que pasa es que si le metes uno no oficial (u oficial) y por lo que sea no se flashea correctamente, no podías recuperarlo.
lo que he leido es que no vale ningun firmware porque se pone el controlador de la antigua y se brickea.
lo que he leido es que no vale ningun firmware porque se pone el controlador de la antigua y se brickea.
Eso es falso. El firmware que viene en el rar que me mandó Sofía es exactamente igual al último publicado (1.1) y, que yo sepa, ChepoXX no ha tenido ningún problema con él.
Eso es falso. El firmware que viene en el rar que me mandó Sofía es exactamente igual al último publicado (1.1) y, que yo sepa, ChepoXX no ha tenido ningún problema con él.
pues no se que decirte,ya me pillas.porque esto que te digo lo ha dicho ChepoXX.
edit:parece que no la brickea,pero deja de ser funcional.
adamantibus
01/06/2009, 22:35
¿Y esta Sofía no podría avanzarnos si se prepara algún nuevo firmware oficial con mejoras notables? :D
¿Y esta Sofía no podría avanzarnos si se prepara algún nuevo firmware oficial con mejoras notables? :D
Yo esperaría sentado :ametra:
Cita:
pues no se que decirte,ya me pillas.porque esto que te digo lo ha dicho ChepoXX.
editarece que no la brickea,pero deja de ser funcional.
bueno te lo digo yo que he probado el nuevo firmware y me actualizó la consola a la versión 1.1 y recuperé la pantalla.
Es decir la consola vuelve a ser 100% funcional luego del semibrickeo anterior con un firmware hack.
salu2
adamantibus
01/06/2009, 22:43
Yo esperaría sentado :ametra:
Qué poca fé. :)
Qué poca fé. :)
Yo con jugar al Bermuda Syndrome y al CPC en la Dingoo voy más que sobrado, así que ya pueden sacar firms que no me interesan :D
Por cierto, ¿eres el mismo adamantibus de mundodvd?
Lo suyo sería crear imágenes ya preparadas con una partición FAT bastante grande y la partición EXT3 con el rootfs para tarjetas de 1, 2, 4 y 8 GB para que los usuarios de Windows pudieran grabarlas sin problemas.
La prueba que he hecho con una tarjeta de 2GB ha funcionado sin problemas.
Me parece que no es tan sencillo. Si la tarjeta está particionada tiene una geometría determinada (cilindros, cabezas, sectores, etc). Es un legado de los tiempos de los primeros discos duros. Además, aunque no lo parezca, no necesariamente todas las tarjetas de, por ejemplo, 8GB tienen el mismo tamaño y número de sectores. Creo que tiene que ver con el hecho de que en la NAND flash se toleran sectores defectuosos en fabricación (en incluso mucho más adelante conforme van fallando por agotar sus ciclos de borrado).
< - >
Me iba a poner ahora a desensamblar el nuevo .DL y he pensado que quizás podría ser interesante para alguien echar un vistazo a lo que hice con el anterior. Lo he colgado en google code.
adamantibus
02/06/2009, 00:15
Por cierto, ¿eres el mismo adamantibus de mundodvd?
Sí. ;)
Reconozco tu avatar pero no caigo en el nick.
Me parece que no es tan sencillo. Si la tarjeta está particionada tiene una geometría determinada (cilindros, cabezas, sectores, etc). Es un legado de los tiempos de los primeros discos duros. Además, aunque no lo parezca, no necesariamente todas las tarjetas de, por ejemplo, 8GB tienen el mismo tamaño y número de sectores. Creo que tiene que ver con el hecho de que en la NAND flash se toleran sectores defectuosos en fabricación (en incluso mucho más adelante conforme van fallando por agotar sus ciclos de borrado).
Yo he creado la imagen de la tarjeta, he borrado y formateado las particiones, creado una única partición en FAT32 y la he formateado. El programa me ha dado una réplica exacta con las particiones y los datos tal y como estaban. Si tienes por ahí una tarjeta de 2GB, puedo subir la imagen para que la pruebes.
< - >
Reconozco tu avatar pero no caigo en el nick.
josemuk y sí, Babylon 5 es la mejor serie de ciencia ficción de la historia de la TV :)
adamantibus
02/06/2009, 00:32
josemuk y sí, Babylon 5 es la mejor serie de ciencia ficción de la historia de la TV
:risas: You're right, josemuk, encantado de reencontrarte por estos lares. Yo no entiendo una mierda de la mitad de lo que habláis pero vivo un resurgir de lo retro gracias a la Dingoo y a la Wiz así que pululo por aquí empapándome de lo que puedo.
Deseando también poder revivir las glorias del CPC en alguna de las dos cacharras.
Ya he desensamblado el CCPMP_CFG_A320_LCM_FAIR_ILI9331_320_240.dl y no hay sorpresas. Ya he identificado la secuencia de inicialización y sólo me queda meter el código en el driver framebuffer (pero hoy ya no puedo más). No se aún si podré distinguir el tipo de LCD o habrá que sacar dos kernels.
Dado que la A320 es relativamente barata y gracias a las donaciones, es posible que mañana mismo pueda pedir una A320. El problema es que yo NECESITO una de las que llevan un ILI9331 y aunque lo más probable es que sea así, no tengo forma de asegurarlo cuando la compre.
Esteeeee... ¿si la pido y viene con un ILI9325 (cosa que como ya sabéis se puede averiguar sin necesidad de destriparla) habría algún voluntario con una de las del ILI9331 dispuesto a cambiarmela?. El color obviamente me da igual.
A mi me va a llegar otra para un colega, supongo que no habrá problema para cambiarla si la tuya viene con el LCD de siempre en lugar del nuevo.
ezelkow1
02/06/2009, 06:37
Posted a new uclibc toolchain and rootfs. This has all the sdl libs, screen, lrz, tremor support, just about everything you could need. Used it to build snes9x and a few other apps and they all run fine.
I also managed to get alsa building and linked, but it is not included in the posted toolchain and rootfs. I will upload that later whenever I have a larger amount of changes available. I have also posted a newer patch for the 2.6.24 kernel which includes all of booboo's latest changes.
These are all on dingoofiles. Sort by date so you can find the latest.
Posted a new uclibc toolchain and rootfs. This has all the sdl libs, screen, lrz, tremor support, just about everything you could need. Used it to build snes9x and a few other apps and they all run fine.
I also managed to get alsa building and linked, but it is not included in the posted toolchain and rootfs. I will upload that later whenever I have a larger amount of changes available. I have also posted a newer patch for the 2.6.24 kernel which includes all of booboo's latest changes.
These are all on dingoofiles. Sort by date so you can find the latest.
Thanks for working so hard ezelkow1, could you upload a video of snes9x running on the dingoo?.
Did you notice any graphical error as in the "original" megadrive emulator?
EDIT: After downloading the snes9x version I read the "no mouse" text, did you use the "export SDL_NOMOUSE=1" option?
ezelkow1, could be possible a tutorial o a script in order to build toolchain? I'm using powerc, I tried Ingenic script but fails.
Thanks in advance.
EDIT: Nekete, disculpa que quería preguntárselo a ezelkow1. Gracias de todos modos.
Háblame en apaño si quieres, que me entero mejor ^_^
No puedo darte ayuda, pues no lo sé ni yo.
Para ejemplo, un botón.
Como el snes9x no me funcionaba, intenté compilarlo de nuevo y me ha dado un error al final.
·Después de borrar el snes9x y los .o anteriores hago ésto:
export PATH=/opt/mipseltools-gcc412-glibc261/bin:$PATH
export SDL_NOMOUSE=1
make snes9x
Lo que me sale es:
.....
mipsel-linux-gcc -I/opt/mipseltools-gcc412-glibc261/mipsel-linux/include -o snes9x cpuops.o cpuexec.o cpu.o tile.o gfx.o clip.o memmap.o ppu.o dma.o unix/unix.o spc700.o soundux.o apu.o unix/svga.o dsp1.o snes9x.o snapshot.o data.o globals.o loadzip.o unzip/unzip.o unzip/explode.o unzip/unreduce.o unzip/unshrink.o -L/opt/mipseltools-gcc412-glibc261/mipsel-linux/lib -lSDL -lstdc++ -lz -lpthread
/opt/mipseltools-gcc412-glibc261/lib/gcc/mipsel-linux/4.1.2/../../../../mipsel-linux/bin/ld: cannot find -lSDL
collect2: ld returned 1 exit status
make: *** [snes9x] Error 1
algún alma caritativa podría decirme la razón de que no encuentre las SDL si al hacer pruebas con g++ sí lo hace (vamos, que funciona) :confused:
un ejemplo:
[nekete@Archival test]$ g++ -o test test.cpp -lSDL
[nekete@Archival test]$ mipsel-linux-g++ -o test test.cpp -lSDL
/opt/mipseltools-gcc412-glibc261/lib/gcc/mipsel-linux/4.1.2/../../../../mipsel-linux/bin/ld: cannot find -lSDL
collect2: ld returned 1 exit status
algún alma caritativa podría decirme la razón de que no encuentre las SDL si al hacer pruebas con g++ sí lo hace (vamos, que funciona) :confused:
El makefile del snes9x lo tengo modificado con esto:
LDLIBS = -L/opt/mipseltools-gcc412-glibc261/lib
y me compila sin problemas.
Te falta pasarle al linkador donde está la librería SDL ya compilada en tu sistema. Vamos, algo como (supongo):
-L/opt/mipseltools-gcc412-glibc261/mipsel-linux/lib
El makefile del snes9x lo tengo modificado con esto:
LDLIBS = -L/opt/mipseltools-gcc412-glibc261/lib
y me compila sin problemas.
y como va=?
y como va=?
No lo he probado demasiado pero parece que va mejor que la versión del snes9x incluída en el firmware.
No se como iran, puedes decir como va el chrono con tansparencias??Si tiene contador de fps seria la caña.
Va con sonido?
Lo conseguí hacer(no sé la razón, pero había tocado los archivos de/opt/mips.. aains u_u)
El caso es que al ir a probarlo, me dice lo siguiente:
./snes9x -dfr -nomouse Chrono\ Trigger\ -\ Crimson\ echoes.smc
usage: snes9x <options> <rom image filename>
Pero se supone que la opcion -nomouse está bien, ¿no?
La vi en:
http://www.snes9x.com/phpbb2/viewtopic.php?t=3020&highlight=nomouse
http://wiki.arcadecontrols.com/wiki/Snes9x#Command_Line_Parameters
El caso es que al ir a probarlo, me dice lo siguiente:
Renombra la rom a algo sencillo como ct.smc y prueba de nuevo.
He probado con otras rom y me pasa lo mismo :\
./snes9x -nomouse -dfr ITIME.SMC
usage: snes9x <options> <rom image filename>
Prueba entonces a quitar las opciones -nomouse -dfr
cdesign30
02/06/2009, 23:30
Booboo,
Yo publiqué una mensaje largo en comunidad Orkut Gemei brasileña acerca de sus desarrollo del Linux en X760 + , y muchas personas están interesadas en hacer una donación en los próximos días en su blog. Todos nos dio gracias a todos sus esfuerzos Booboo, acerca de lo excelente labor realizado. Gracias!
Doug
Prueba entonces a quitar las opciones -nomouse -dfr
En ese caso, me pone:
snes9x cc.smc
Rate: 11025, Buffer size: 256, 16-bit: yes, Stereo: yes, Encoded: no
Could not initialize SDL(Unable to open mouse)
Al compilarlo usé export SDL_NOMOUSE=1
¿Cómo lo hiciste funcionar tu?, yo ya no sé qué hacer :(
EDIT: Probé a compilar la versión actual de PC y me funciona bien con dichas opciones.
En ese caso, me pone:
snes9x cc.smc
Rate: 11025, Buffer size: 256, 16-bit: yes, Stereo: yes, Encoded: no
Could not initialize SDL(Unable to open mouse)
Tienes que escribir export SDL_NOMOUSE=1 antes de ejecutarlo o, mejor aún, usa
putenv("SDL_NOMOUSE=1");
al principio de la función main del unix.cpp
Booboo,
Yo publiqué una mensaje largo en comunidad Orkut Gemei brasileña acerca de sus desarrollo del Linux en X760 + , y muchas personas están interesadas en hacer una donación en los próximos días en su blog. Todos nos dio gracias a todos sus esfuerzos Booboo, acerca de lo excelente labor realizado. Gracias!
Doug
De nada. Gracias por el apoyo. A este paso esta misma semana estoy pidiendo la x760+.
(...lo paradójico que es que en total habrá jugado con la A320 unos 20 minutos desde que la compré... :D)
< - >
En ese caso, me pone:
snes9x cc.smc
Rate: 11025, Buffer size: 256, 16-bit: yes, Stereo: yes, Encoded: no
Could not initialize SDL(Unable to open mouse)
Al compilarlo usé export SDL_NOMOUSE=1
¿Cómo lo hiciste funcionar tu?, yo ya no sé qué hacer :(
EDIT: Probé a compilar la versión actual de PC y me funciona bien con dichas opciones.
El "export SDL_NOMOUSE=1" has de ejecutarlo en la A320 antes de lanzar el programa.
Alternativamente puedes usar la solución "putenv" que menciona A600.
< - >
Acabo de modificar el código del driver del framebuffer con lo que he averiguado desensamblando el .DL de las nuevas A320. En el blog (http://dingoo-linux.blogspot.com/) tenéis un enlace para descargar el zImage, que obviamente no he probado. Debería funcionar, pero nunca se sabe. Si no funciona tendré que esperar a tener una de las nuevas A320 para trastear, y en todo caso la voy a necesitar para implementar la detección del tipo de LCD. Mientras tanto habrá que hacer dos zImages distintos para cada modelo.
También he posteado una entrada sobre OSS/ALSA.
ezelkow1
03/06/2009, 02:36
If you need me to get my rootfs that has alsa up sooner I can probably do that so you have something to work with
If you need me to get my rootfs that has alsa up sooner I can probably do that so you have something to work with
I have a working rootfs with alsa, but just to factor out the userspace stuff I'll be testing both with your rootfs and mine.
No se como iran, puedes decir como va el chrono con tansparencias??Si tiene contador de fps seria la caña.
Va con sonido?
Lo acabo de probar y fluctua entre 15 y 18 fps. Van con sonido y ahora que lo he probado algo más no sé yo si va mejor que el "oficial".
Es el mismo emu que sacó el koreano cuando el lanzamiento de la gp2x (el port del snes9x que usa SDL para el Zaurus)
Lo acabo de probar y fluctua entre 15 y 18 fps. Van con sonido y ahora que lo he probado algo más no sé yo si va mejor que el "oficial".
Es el mismo emu que sacó el koreano cuando el lanzamiento de la gp2x (el port del snes9x que usa SDL para el Zaurus)
yo no tengo gp32x pero me gustaría saber, si es el mismo emulador que tal iba en la gp32x?? y por otra parte el mejor emulador de snes en la gp32x que tal va comparandolo con este.
salu2
yo no tengo gp32x pero me gustaría saber, si es el mismo emulador que tal iba en la gp32x?? y por otra parte el mejor emulador de snes en la gp32x que tal va comparandolo con este.
salu2
no existe al gp32x; solo la gp32 y la gp2x.
no existe al gp32x; solo la gp32 y la gp2x.
lo siento me refiero a la gp2X, la mas nueva de las dos.
Parece que compilando con la opción -fprofile-generate tal y como se explica aquí (http://www.gp32x.com/board/index.php?showtopic=28490&hl=generate&st=15) se genera código más optimizado, aunque esperaba mejores resultados (probaré a compilar con O2 en vez de O3)
Con el emu de CPC CAP32 y los dintintos renderers obtengo los siguientes resultados:
-----> normal fast ultra (fps)
sin 42 52 65
con 45 56 70
Parece que compilando con la opción -fprofile-generate tal y como se explica aquí (http://www.gp32x.com/board/index.php?showtopic=28490&hl=generate&st=15) se genera código más optimizado, aunque esperaba mejores resultados (probaré a compilar con O2 en vez de O3)
Con el emu de CPC CAP32 y los dintintos renderers obtengo los siguientes resultados:
-----> normal fast ultra (fps)
sin 42 52 65
con 45 56 70
El rage, emu de neo geo pocket, esta en C con SDL o usa librerias en ensamblador?
El rage, emu de neo geo pocket, esta en C con SDL o usa librerias en ensamblador?
¿Rage? El único emu de neogeo pocket que me suena es el NeoPop y sí que usa SDL y el core está en C. Aunque a mí particularmente, emular consolas con esas resoluciones en una pantalla de 320x240 me parece un crimen: o te que quedas con un sello de correos o lo reescalas, con lo que el remedio es casi peor que la enfermedad.
(probaré a compilar con O2 en vez de O3)
También prueba con -Os optimización para tamaño. En determindas CPUs con caches muy pequeñas dan mas rendimiento al no tener que estar cargando continuamente grandes bloques de instrucciones que dan mas rendimiento pensando en CPUs con mucha cache, esto lo aprendi instalando una gentoo en una mini-itx con un VIA C3, que tenian menos cache que las CPUs de Intel.
También prueba con -Os optimización para tamaño. En determindas CPUs con caches muy pequeñas dan mas rendimiento al no tener que estar cargando continuamente grandes bloques de instrucciones que dan mas rendimiento pensando en CPUs con mucha cache, esto lo aprendi instalando una gentoo en una mini-itx con un VIA C3, que tenian menos cache que las CPUs de Intel.
Gracias por el consejo. Probaré también con esa opción aunque me da a mí que el rendimiento mejorará bastante si compilo las SDL como una librería estática, con lo que todas las funciones que la usan se beneficiarán de la opción -fprofile-use.
edit: He probado con -Os y va más lento y la diferencia entre -O2 y -O3 es prácticamente inapreciable.
¿Alguien ha probado el kernel que subí a google code para los nuevos LCD?. Me gustaría confirmar que no funciona (según el único que ha puesto un comentario en el blog).
Por cierto... alguien me ha enviado el manual completo del JZ4740 :D:D:D:D:D:D:D:D:D:D
Por cierto... alguien me ha enviado el manual completo del JZ4740 :D:D:D:D:D:D:D:D:D:D
¿Se puede compartir? o es "For your eyes only" :lol:
¿Se puede compartir? o es "For your eyes only" :lol:
Digamos que alguien lo ha encontrado "por ahí" y me lo ha enviado. No he firmado nada ni me he comprometido a nada. He echado un vistazo por encima y no veo ningún aviso de confidencialidad, así que no creo que haya problema en colgarlo (en google code o donde sea, pero preferiblemente en google code). Voy a asegurarme tanto como pueda y lo cuelgo este fin de semana.
En otro orden de cosas, acabo de verificar que el driver OSS consume nada menos que 3.5MB. Algo está muy muy muy muy muy mal. Debe ser uno de los cientos de miles de bugs que debe tener, porque la parte de buffers sí que logré entenderla y son como 20K o así nada más.
Volviendo a ALSA, ¿cómo es posible que sólo la librería libasound ocupe casi 1MB?... y se supone que es la parte de usuario de comunicación con el driver del kernel, que es el que realmente soporta el hardware. No lo entiendo...
Ayer recibí una Dingoo A320 blanca con versión 1.1 y display ILI9331_3.
Se encargo hace 9 dias a DrealExtreme, por lo que seguramente todas las nuevas que se compre en DrealExtreme serán de la nuevas.
Ayer recibí una Dingoo A320 blanca con versión 1.1 y display ILI9331_3.
Se encargo hace 9 dias a DrealExtreme, por lo que seguramente todas las nuevas que se compre en DrealExtreme serán de la nuevas.
jajajaj, te has salvado del spam de milagro. Lo gracioso esque creo que no lo has hecho aposta. XDDDDDDDDDDDDDDDd
Shinosuke1991
05/06/2009, 09:13
*****, ahi formas mas digamos intimas de hablar de una pagina tios XD
Digamos que alguien lo ha encontrado "por ahí" y me lo ha enviado. No he firmado nada ni me he comprometido a nada. He echado un vistazo por encima y no veo ningún aviso de confidencialidad, así que no creo que haya problema en colgarlo (en google code o donde sea, pero preferiblemente en google code). Voy a asegurarme tanto como pueda y lo cuelgo este fin de semana.
¿Es esto (http://www.mediafire.com/?djnnnmnojzd)? El enlace lo han posteado en el Dingoo A320 forum y en una de las páginas pone "INGENIC Confidential" en letras rojas, así que debe haber un topo infiltrado :D
¿Es esto (http://www.mediafire.com/?djnnnmnojzd)? El enlace lo han posteado en el Dingoo A320 forum y en una de las páginas pone "INGENIC Confidential" en letras rojas, así que debe haber un topo infiltrado :D
En efecto, es eso. Y precisamente quería examinarlo con un poco más de detenimiento para ver sin en algún lado ponía lo de "confidential". No he mirado TODO pero he visto que sólo pone "confidential" en uno de los documentos que además no tiene ninguna relevancia, así que supongo que con quitarlo basta.
De todas formas, tendría huevos que los chinos dieran problemas con el tratamiento que hacen ellos habitualmente de los temas de propiedad intelectual.
En cuanto a lo del topo... no necesariamente. Ten en cuenta que estamos hablando de un documento que contiene información IMPRESCINDIBLE para cualquiera que desarrolle LO QUE SEA para ese procesador. Eso significa que ese documento lo tiene literalmente cientos de personas de docenas de empresas. Por mucho que se les diga que no hay que difundirlo, es sólo cuestión de tiempo.
Y a todo esto, sigo sin entender qué gana Ingenic restringiendo el acceso a esa información, sobre todo cuando el código está disponible...
Y a todo esto, sigo sin entender qué gana Ingenic restringiendo el acceso a esa información, sobre todo cuando el código está disponible...Yo les pedí amablemente dicho documento hace unas semanas argumentandoles que el motivo era puramente técnico para programar a bajo nivel y así aprovechar al máximo un aparato basado en su SoC JZ4740 (no especifiqué que me refiería a la Dingoo A320) y sorprendentemente me contestaron (eso si, de tres direcciones de email que tenía de ingenic, solo una de ellas lo hizo) aunque no es que me lo negaran, simplemente me daban el enlace a los documentos que están públicamente accesibles, así que o no me entendieron porque yo no me expliqué bien o el empleado chino en cuestión no domina mucho el inglés y no sabía por lo que le preguntaba (mira que dejé claro que no quería el DataShet, sino el Manual del Hardware), me da que pensar que si que me entendieron, pero por los motivos que fuera, para no dar una respuesta negativa directa, prefirieron darme una respuesta cordial aunque no fuera lo que les solicitaba xDD
Yo les pedí amablemente dicho documento hace unas semanas argumentandoles que el motivo era puramente técnico para programar a bajo nivel y así aprovechar al máximo un aparato basado en su SoC JZ4740 (no especifiqué que me refiería a la Dingoo A320) y sorprendentemente me contestaron (eso si, de tres direcciones de email que tenía de ingenic, solo una de ellas lo hizo) aunque no es que me lo negaran, simplemente me daban el enlace a los documentos que están públicamente accesibles, así que o no me entendieron porque yo no me expliqué bien o el empleado chino en cuestión no domina mucho el inglés y no sabía por lo que le preguntaba (mira que dejé claro que no quería el DataShet, sino el Manual del Hardware), me da que pensar que si que me entendieron, pero por los motivos que fuera, para no dar una respuesta negativa directa, prefirieron darme una respuesta cordial aunque no fuera lo que les solicitaba xDD
Mi experiencia con los proveedores chinos de componentes electrónicos y demás es que les tienes que decir lo que quieres de la forma más clara y simple que puedas, sin irte por las ramas lo más mínimo. No están acostumbrados a la redacción de cortesía. Al grano o no se enteran o si se enteran pasan o se salen por la tangente con una facilidad pasmosa. Y amigos que tratan a nivel comercial con ellos en otras áreas diferentes de la electrónica coinciden 100% conmigo.
NEWS flash: parece el que kernel de prueba que colgué en google code con soporte para el framebuffer de las nuevas A320 (ILI9331 LCD) funciona. El primer informe de que no funcionaba parece ser una falsa alarma.
Así que los usuarios de las nuevas A320 ya pueden usar linux. No me parece viable implementar el código de detección del modelo de LCD (o ya puestos el de selección si la detección no fuera posible) sin disponer de una unidad de prueba, así que sigo adelante con la compra de una A320 nueva utilizando las donaciones. Mientras tanto, colgaré DOS binarios del kernel en google code, uno para cada modelo de LCD.
Por cierto, el amigo CraigX o pasa un huevo de todo o tengo muy mala suerte. Llevo semanas intentando contactar con él por todos los medios (foros, emails a gbax, etc) y NO-HAY-FORMA. Lo más parecido a una respuesta que he obtenido ha sido un escueto mensaje en un foro de gp32x. Así que tiro la toalla. Si alguien quiere seguir intentándolo y lo logra, que le pase mi dirección de correo (iggarpe en el mail de goole punto com),
Por cierto, el amigo CraigX o pasa un huevo de todo o tengo muy mala suerte. Llevo semanas intentando contactar con él por todos los medios (foros, emails a gbax, etc) y NO-HAY-FORMA. Lo más parecido a una respuesta que he obtenido ha sido un escueto mensaje en un foro de gp32x. Así que tiro la toalla. Si alguien quiere seguir intentándolo y lo logra, que le pase mi dirección de correo (iggarpe en el mail de goole punto com),
Trata de contactar con Anarchy (webmaster de este foro y dueño de hardcore-gamer). Puede que alguna de las dingoos que ha recibido tengan el nuevo LCD y te la venda.
Trata de contactar con Anarchy (webmaster de este foro y dueño de hardcore-gamer). Puede que alguna de las dingoos que ha recibido tengan el nuevo LCD y te la venda.
¿La única forma de saberlo es usando el TV-OUT como explicaban más atras o abriéndola? ¿No se puede ver directamente en algún menú sin conectarla a la TV? El lunes lo comprobaré con una de cada color en H-G y os lo confirmo.
mragonias
05/06/2009, 21:59
si que se puede Anarchy, en el menu a la derercha del todo, en un submenu debe indicar esto:
LCD MODULE: LCM_FAIR_ILI9331_3
si que se puede Anarchy, en el menu a la derercha del todo, en un submenu debe indicar esto:
LCD MODULE: LCM_FAIR_ILI9331_3
Pero comentaban en otro post (ahora no lo localizo) que ese submenú solo aparecía en el TV-OUT (o me empieza a atacar la demencia senil) :D
Tengo una Dingoo en casa de la primera remesa. Luego hago la prueba a ver si lo veo y el lunes compruebo las que tenemos en stock.
< - >
Y un par de consultas rápidas, que tengo la consola sin nada de batería. ¿La consola carga mientras está conectada por USB al PC? ¿Cómo se sale del modo de conexión USB al quitar el cable? Se me queda la imagen del usb y solo puedo resetearla. :confused:
¿La única forma de saberlo es usando el TV-OUT como explicaban más atras o abriéndola? ¿No se puede ver directamente en algún menú sin conectarla a la TV? El lunes lo comprobaré con una de cada color en H-G y os lo confirmo.
Te lo pego en inglés del blog de booboo :D
Enter the A320 system setup "about" section and press the following key combination: up-right-down-up-right-down. A hidden info screen will be shown. Write down everything.
Si en la pantalla aparece LCD MODULE: LCM_FAIR_ILI9331_3, ésa es la buena.
< - >
Y un par de consultas rápidas, que tengo la consola sin nada de batería. ¿La consola carga mientras está conectada por USB al PC?
Creo que sí.
¿Cómo se sale del modo de conexión USB al quitar el cable? Se me queda la imagen del usb y solo puedo resetearla. :confused:
Pues eso no es normal. ¿Te pasa lo mismo si quitas el hardware con seguridad?
Te lo pego en inglés del blog de booboo :D
Si en la pantalla aparece LCD MODULE: LCM_FAIR_ILI9331_3, ésa es la buena.
< - >
Creo que sí.
Pues eso no es normal. ¿Te pasa lo mismo si quitas el hardware con seguridad?La que tengo en casa es de la primera remesa y parece que lleva un LCD de los anteriores. La cosa es que el texto no entra en la pantalla y parte queda fuera de la imagen, pero lo que se lee es: LCM_MOUDLE_ILI9325
(sí, sí: MOUDLE) :lol:
< - >
El lunes os miro las que tenemos en H-G.
Con el código para ucosII que usé para el programa de overclocking y con la ayuda de las minimal libs de rlyeh y el manual misterioso, he aquí el código fuente para overclockear la A320 con linux.
El único problemilla que tiene es que la consola desaparece (al menos con el Tera Term). Puedo escribir pero lo tengo que hacer a ciegas :(
En la siguiente tabla adjunto los fps del CAP32 a 336 y a 420 con los distintos renderers:
-----> normal fast ultra (fps)
336 42 52 65
420 59 70 84
Como siempre, no me hago responsable si achicharráis vuestra Dingoo.
edit: a 420 se cuelga/sale del emu a los pocos minutos :( (con el firmware original podía overclockear a 430 sin problemas), así que he probado a 400 y no ha habido cuelgues. Intentaré ahora a 415 a ver si hay suerte.
Enter the A320 system setup "about" section and press the following key combination: up-right-down-up-right-down. A hidden info screen will be shown. Write down everything.
Joe, pues en la mia pone:
LCM_MOUDLE_ILI9325
y seguramente algo mas, pero queda cortado por la pantalla, me ha hecho gracia lo de "MOUDLE", sep no ha sido equivocacion mia :p esta así, ¿supongo que la mia no es de las buenas no?
Como siempre, no me hago responsable si achicharráis vuestra Dingoo.
edit: a 420 se cuelga/sale del emu a los pocos minutos (con el firmware original podía overclockear a 430 sin problemas), así que he probado a 400 y no ha habido cuelgues. Intentaré ahora a 415 a ver si hay suerte.
A600 no se si sabias pero con en el firmware original y el overclock se crea una especie de bug o fallo, y es cuando pones la consola en una mayor frecuencia de cpu, y querer conectar la consola a la tv, la imagen se vuelve a blanco negro y salen rayas mientras parpadea la imagen, entre mas rápido pongas el cpu mas fuerte será el parpadeo.
A600 no se si sabias pero con en el firmware original y el overclock se crea una especie de bug o fallo, y es cuando pones la consola en una mayor frecuencia de cpu, y querer conectar la consola a la tv, la imagen se vuelve a blanco negro y salen rayas mientras parpadea la imagen, entre mas rápido pongas el cpu mas fuerte será el parpadeo.
Pues lo siento, pero no tengo ni idea de cómo solucionar ese problema.
Pues lo siento, pero no tengo ni idea de cómo solucionar ese problema.
No tienes por que sentirlo [wei][wei] lo leí en un foro en ingles y traté de probarlo y efectivamente en la television con el overclock no funciona, pero vamos que no es tu culpa ni tampoco te pido que lo arregles[wei2][wei2]
Solo que al ver que estabas viendo el tema del oc en linux, decidí comentarterlo.
pues yo he jugado a 430mhz en el televisor sin ningun problema.lo unico que he notado,es que no se puede hacer el overclok con la tv conectada,es decir que primero debemos poner la consola a 430mhz y despues conectarla a la tv.
pues yo he jugado a 430mhz en el televisor sin ningun problema.lo unico que he notado,es que no se puede hacer el overclok con la tv conectada,es decir que primero debemos poner la consola a 430mhz y despues conectarla a la tv.
suena interesante, cuando lo probé fue con la tele conectada voy a a tratar otra vez, como dices.
salu2
Con el código para ucosII que usé para el programa de overclocking y con la ayuda de las minimal libs de rlyeh y el manual misterioso, he aquí el código fuente para overclockear la A320 con linux.
El único problemilla que tiene es que la consola desaparece (al menos con el Tera Term). Puedo escribir pero lo tengo que hacer a ciegas :(
En la siguiente tabla adjunto los fps del CAP32 a 336 y a 420 con los distintos renderers:
-----> normal fast ultra (fps)
336 42 52 65
420 59 70 84
Como siempre, no me hago responsable si achicharráis vuestra Dingoo.
edit: a 420 se cuelga/sale del emu a los pocos minutos :( (con el firmware original podía overclockear a 430 sin problemas), así que he probado a 400 y no ha habido cuelgues. Intentaré ahora a 415 a ver si hay suerte.
No os calenteis la cabeza mucho con el overclocking. El código fuente de Ingenic tiene soporte para cpufreq y se puede cambiar la frecuencia de la CPU sobre la marcha sin problemas. De hecho se puede incluso utilizar los "governors" que cambian la frecuencia según demanda (al igual que en los portátiles). Me consta que ya ha quien ha activado esta opción y la ha probado con éxito, con la única salvedad de que la alguna frecuencia muy baja dejaba de funcionar el USB (tiene sentido porque el USB obtiene el reloj del PLL y sólo sirven algunas frecuencias concretas, múltipos de 48MHz).
No activé este soporte en los binarios que he colgado en google code porque no había probado si funcionaba, pero sobre todo porque quería restringir los factores a considerar en caso de que algo no funcionara bien.
Este fin de semana mismo incluyo el código para el ILI9331 en el driver del framebuffer, activo el cpufreq y cuelgo dos binarios del kernel en google code (uno para cada tipo de LCD).
< - >
Joe, pues en la mia pone:
LCM_MOUDLE_ILI9325
y seguramente algo mas, pero queda cortado por la pantalla, me ha hecho gracia lo de "MOUDLE", sep no ha sido equivocacion mia :p esta así, ¿supongo que la mia no es de las buenas no?
Y que me dices de "Interesting game". Si no se molestan en traducir correctamente lo que va a ver el usuario final, imagina lo que se van a molestar con lo que nadie más que los coders van a ver...
Yo que he estado buceando mucho en las tripas tanto de los binarios del firmware como del código de Ingenic, te aseguro que hay gazapos a punta pala.
He portado el PicoDrive y por ahora no tiene mala pinta: no hace el efecto raro del emu del firmware y parece más rápido :)
He portado el PicoDrive y por ahora no tiene mala pinta: no hace el efecto raro del emu del firmware y parece más rápido :)
Wow, impresionante.
Que version??La que tiene soporte para el chip svp??
Por cierto, el emu de neo geo pocket es el race:
http://www.personal.triticom.com/~erm/GP2X/RACE/
Saludos
Que version??La que tiene soporte para el chip svp??
La última versión con código fuente es la 1.35. No sería un problema si no fuera porque no soporta pistas de audio raw de SegaCD y el decoder de mp3 sólo soporta arquitecturas ARM y X86, aunque tampoco creo que importe demasiado porque emular SegaCD decentemente lo veo muy chungo.
Por cierto, el emu de neo geo pocket es el race:
http://www.personal.triticom.com/~erm/GP2X/RACE/
OK
La última versión con código fuente es la 1.35. No sería un problema si no fuera porque no soporta pistas de audio raw de SegaCD y el decoder de mp3 sólo soporta arquitecturas ARM y X86, aunque tampoco creo que importe demasiado porque emular SegaCD decentemente lo veo muy chungo.
OK
La verdad es que supongo que el emulador para gp2x lleva lineas y lineas de condigo en ensablador, posiblemente para los cores, y de ahi que cunda tanto el emu, pero bueno, si funciona MD de forma decente es una gran noticia :brindis:
Lo del emulador te lo digo porque parece que se puede compilar como el resto, cambiando poco codigo, ya que segun he leido en esa pagina, esta escrito para que sea altamente portable... otra cosa es que sea cierto ^^
Saludos y gracias
La verdad es que supongo que el emulador para gp2x lleva lineas y lineas de condigo en ensablador
No te puedes hacer una idea :D El 68000, Z80, YM, casi todas las rutinas gráficas, el YM/MP3 en el segundo core... El notaz es una pvta máquina.
Lo del emulador te lo digo porque parece que se puede compilar como el resto, cambiando poco codigo, ya que segun he leido en esa pagina, esta escrito para que sea altamente portable... otra cosa es que sea cierto ^^
Se puede compilar una versión para linux-gtk con un wrapper de las minimal libs que usa todos los cores en C, así que he eliminado todo lo relacionado con las gtk y copiado el búffer de video del emu al framebuffer. Lo único malo es que por ahora no hay controles y la paleta está chunga :D
No te puedes hacer una idea :D El 68000, Z80, YM, casi todas las rutinas gráficas, el YM/MP3 en el segundo core... El notaz es una pvta máquina.
Se puede compilar una versión para linux-gtk con un wrapper de las minimal libs que usa todos los cores en C, así que he eliminado todo lo relacionado con las gtk y copiado el búffer de video del emu al framebuffer. Lo único malo es que por ahora no hay controles y la paleta está chunga :D
Yo te lo pasaba para ver si era compilar y ver rendimiento [wei]
Saludos y gracias, sois unos cracks!Para cuando booboo saque un arranque dual ya existiran bastantes emus portados, y junto al menu, sera una pasada
Qué ganas tengo de jugar bien a "la mega".
:hype::hype::hype::hype::hype:
Una cosilla, ¿varía mucho el Rootfs y el kernel "antiguo" con el subido al "Dingoo file archive"?.
A600 por si te aburres de portar el pico drive puedes meterle mano al gngeo (http://gngeo.berlios.de/) [propeller]
Los cores son en C y soporta hasta raster effects, lo unico que si lo quieres optimizado el codigo asm es para x86 :(
Renuente
07/06/2009, 10:56
He portado el PicoDrive y por ahora no tiene mala pinta: no hace el efecto raro del emu del firmware y parece más rápido :)¡¡Genial, A600!! Lo cierto es que todos los emus de serie de la dingoo están lejos de ir bien del todo. Cuando booboo termine su proyecto espero que haya más movimiento en la scene y empiecen a sacar emus; a mi me interesan sobre todo de MD, CPS2 y NeoGeo.
pues yo he jugado a 430mhz en el televisor sin ningun problema.lo unico que he notado,es que no se puede hacer el overclok con la tv conectada,es decir que primero debemos poner la consola a 430mhz y despues conectarla a la tv.
+1 Eso también lo he comprobado yo, le hice overclock a 430 y se me fue la imagen, la apagué y desde entonces si quiero overclockearla y estoy conectado a la tele, desconecto TV, overclock y conecto TV de nuevo.
Tengo el LCD viejo por si acaso.
A600 por si te aburres de portar el pico drive puedes meterle mano al gngeo (http://gngeo.berlios.de/)
Ahora mismo eso no es una opción ya que linux deja libres unos 17 MB de los 32 disponibles y a mí en particular la neogeo no me llama nada, ya que el 90% son juegos de lucha y yo los aborrezco.
Ahora mismo eso no es una opción ya que linux deja libres unos 17 MB de los 32 disponibles y a mí en particular la neogeo no me llama nada, ya que el 90% son juegos de lucha y yo los aborrezco.
Acabo de subir al repositorio algunos cambios (soporte del ILI9331) y he publicado un par de binarios del kernel en google code (de momento hay que escoger uno u otro según el LCD que tengas).
Una de las cosas que he hecho ha sido hacer opcional (y deshabilitado por defecto) la reserva de 4MB para la IPU. Como aún es muy pronto para jugar con el mplayer no creo que haya problema, y el que lo necesite no tiene más que compilar el kernel con la opción activada.
Una de las cosas que he hecho ha sido hacer opcional (y deshabilitado por defecto) la reserva de 4MB para la IPU. Como aún es muy pronto para jugar con el mplayer no creo que haya problema, y el que lo necesite no tiene más que compilar el kernel con la opción activada.
Muchas gracias. Leyendo la entrada de tu blog, parece que el dual-boot está más cerca :brindis:
A600 no nos digas que no se podrá portar el emu de Neo Geo, que precisamente los juegos de Neo Geo que no van en la Dingoo son los de fútbol (no pilla ni uno de la saga Super Sidekicks) y los de lucha si van (en su mayoría)
A600 no nos digas que no se podrá portar el emu de Neo Geo, que precisamente los juegos de Neo Geo que no van en la Dingoo son los de fútbol (no pilla ni uno de la saga Super Sidekicks) y los de lucha si van (en su mayoría)
lo ke ha dicho es ke el NO lo va a hacer.
Muchas gracias. Leyendo la entrada de tu blog, parece que el dual-boot está más cerca :brindis:
A la vuelta de la esquina mismamente. He actualizado el wiki (http://code.google.com/p/dingoo-linux/wiki/DualBoot) con todo lo que he averiguado.
A la vuelta de la esquina mismamente. He actualizado el wiki (http://code.google.com/p/dingoo-linux/wiki/DualBoot) con todo lo que he averiguado.
Muchísimas gracias, qué ganitas tengo de poder independizarme del PC para arrancar Linux :)
Una pregunta, ¿cómo habéis hecho para que el "sdl-config --cflags" de mipsel-linux no os de valores tipo:
-I//include/SDL -D_GNU_SOURCE=1 -D_REENTRANT?
Como los configures van a su bola, ésos valores sueles hacer que tenga que retocar manualmente los Makefiles. ¿Qué he hecho mal? :lamer:
Una pregunta, ¿cómo habéis hecho para que el "sdl-config --cflags" de mipsel-linux no os de valores tipo:
-I//include/SDL -D_GNU_SOURCE=1 -D_REENTRANT?
Como los configures van a su bola, ésos valores sueles hacer que tenga que retocar manualmente los Makefiles. ¿Qué he hecho mal? :lamer:
Edita el sdl-config y cambia
prefix=/
por
prefix=/opt/mipseltools-gcc412-glibc261/mipsel-linux
o la ruta donde tengas los includes.
Dios, que paquete soy!
No sabía que era un script T_T
Muchas gracias A600!
lo ke ha dicho es ke el NO lo va a hacer.
Entendí que con tan poca memoria no podría hacerlo.
Entendí que con tan poca memoria no podría hacerlo.
Por un post anterior de booboo el linux actualmente deja cerca de 17 megas libres lo cual es insuficiente para emular bien al neo geo (los juegos grandes por lo menos) pero piensa que una vez terminado el port de linux definitivo ocupara unos pocos megas (menos de 5 talvez) dejando 27 28 megas libres de ram haciendo factible la emulacion de neo geo y otros emus con roms grandes. salu2
Con el último kernel subido:
# free
total used free shared buffers
Mem: 29736 8800 20936 0 160
Swap: 0 0 0
Total: 29736 8800 20936
BooBoo acabo de recibir una dingoo de color negra de dealextreme y la consola tiene la pantalla anterior, yo compré una dingoo blanca hace un mes aproximadamente y me vino con la pantalla nueva.
Al parecer se confirma que por ahora solo la consola blanca de última remesa en dealextreme viene con la pantalla nueva.
suerte y salu2
Coñe, al final se me olvidó mirar lo de las pantallas en las conoslas que tenemos en HG :(
A ver si lo puedo mirar mañana.
booboo:
Disculpa, he visto que tenías como issues el control de brillo y volumen. ¿Es posible ver el nivel de la batería actualmente?.
edit:
¿Podría proponerse también la posibilidad de acceder a la memoria de la máquina como posible incorporación futura?(o posible arranque del linux desde la misma).
Un saludo y gracias.
Entendí que con tan poca memoria no podría hacerlo.
Tal vez se pueda. He estado mirando el código fuente del gngeo y usa mmap para leer las roms con los gráficos (que suelen ser las más tochas) directamente desde un fichero .gfx sin tener que cargarlas en memoria.
De todas formas he estado modificando el NEO4ALL, el emu de NeoGeo CD del gran chui, para que en vez de desde CDs, lea los datos y las pistas de audio en formato mp3 desde la SD.
De todas formas he estado modificando el NEO4ALL, el emu de NeoGeo CD del gran chui, para que en vez de desde CDs, lea los datos y las pistas de audio en formato mp3 desde la SD.
Me resulta dificil creer que la dingo tiene la potencia para emular el neo geo cd y a la vez reproducir un archivo mp3 La Dreamcast siendo una gran consola nunca pudo hacer ambas cosas a la vez y por eso se debía grabarse los archivos en formato cd (es mas recuerdo haber hecho un tutorial de como hacerlo hace unos años).
En dc el emulador en su última versión de neo geo cd con el faze y y el fame no alcanzaba el 100% de velocidad en algunos juegos.
En todo caso suerte con el proyecto
salu2
Como posdata comento que el Aes4all es port del ngeo para dc pero que aprovecha el mmu de la consola para cargar archivos durante la partida.
Theoretically, all GNGEO supported ROMS. AES4ALL uses MMU for loading large roms, so it load rom on demand during game.
salu2
ezelkow1
10/06/2009, 01:13
Uploading a new toolchain and rootfs right now to dingoofiles. They will be labled as 06/09, so if you want them make sure to get the correct dates. Also on the toolchain make sure it unpacks into /opt/dingoo-uclibc-toolchain-05-28-09 since dingoofiles has a habit of renaming files that are uploaded.
I have tested these against waternet since it uses sdl_image, sdl_mixer, and tremor. It is fully working now built against this toolchain so at least those components are working. It also has alsa, java, and a whole bunch of other stuff built in.
Me resulta dificil creer que la dingo tiene la potencia para emular el neo geo cd y a la vez reproducir un archivo mp3 La Dreamcast siendo una gran consola nunca pudo hacer ambas cosas a la vez y por eso se debía grabarse los archivos en formato cd (es mas recuerdo haber hecho un tutorial de como hacerlo hace unos años).
En dc el emulador en su última versión de neo geo cd con el faze y y el fame no alcanzaba el 100% de velocidad en algunos juegos.
Lo acabo de probar en la Dingoo, y con overclocking y sin reproducir las pistas de audio va lentillo :(
Lo acabo de probar en la Dingoo, y con overclocking y sin reproducir las pistas de audio va lentillo
pienso que puede ser es que el neo4all esta optimizado para el cpu de la DC que es un sh4 por eso el fame y el faze emus del motorola 6800 y Z80 (emus espedicificos para la dc) y por si fuera poco usa Custom PowerVR2 graphic core (fast tile caching). De esta forma pienso que un port directo del este emu para dc obviamente pide mucho mas de lo que debería a la dingoo.
FEATURES
Close to fullspeed emulation (frameskip0 with sound-fx).
Fast FAME Motorola 68000 core by Fox68k.
Fast FAZE Zilog Z80 core by Fox68k.
Custom PowerVR2 graphic core (fast tile caching).
Autoframeskip for real speed.
Joystick is emulated with analog and digital pad + A,B,X,Y and Start/R-Trigger.
Complete menu with L-Trigger: region selector, frameskip control, graphic filtering, hardware reset...
Crystalline sound without lag.
Both control players emulated.
A lot of games work.
Pienso que debes probar el código fuente directo del emulador para pc (creo que se llama neo cd) y debería ir mucho mas rápido que el neo for all.
salu2
Pienso que debes probar el código fuente directo del emulador para pc (creo que se llama neo cd) y debería ir mucho mas rápido que el neo for all.
Que esté optimizado para Dreamcast no quiere decir que esté "desoptimizado" para las demás plataformas.
Si te refieres al NeoCD-SDL, el NEO4ALL es un port de ese emu pero usando el fame (core del 68000 mucho más rápido que el que incluye aquel). Lo he probado en mi ordenador y chupa un 15/18% de CPU mientras que el NEO4ALL, no pasa de un 4%.
¿Y no seria mas fácil portar el gngeo_2x? Lo único que habría que hacer es compilarlo con los cores en C puro, sin optimización x86, ni los cores ARM.
este creo recordar que ya usaba lo de los GFX, ¿no?
booboo:
Disculpa, he visto que tenías como issues el control de brillo y volumen. ¿Es posible ver el nivel de la batería actualmente?.
No. Estoy casi seguro de que se lee usando el ADC, pero no se si el código de Ingenic lo soporta. En todo caso es muy fácil de implementar... (pero hay muchas cosas antes).
¿Podría proponerse también la posibilidad de acceder a la memoria de la máquina como posible incorporación futura?(o posible arranque del linux desde la misma).
Linux YA puede arrancar desde la memoria interna. El problema es, como ya he dicho en otras ocasiones, que linux todavía no es un sustituto del firmware, por lo que es absolutamente necessario convivir con el firmware original.
Respecto a lo de acceder a la memoria interna de la A320... es un problema de formato. Me explico: si linux fuera lo único instalado en la A320, él se lo guisa y él se lo come: el formato en el que escribe y lee de la NAND es el mismo y por lo tanto "es compatible consigo mismo" (faltaría más). Lo mismo se puede decir del firmware original. El problema es que linux y el firmware original no usan el mismo formato. Y en el concepto "formato" entran muchas cosas:
1- La memoria NAND está organizada en páginas y bloques.
2- Para escribir hay que hacerlo en una página, y sólo se pueden cambiar bits de 1 a 0.
3- Para cambiar bits de 0 a 1 hay que borrar un bloque entero.
4- Cada página contiene una zona de información extra en la que almacena información de corrección de errores y un flag que indica si la página es "mala" (no se puede usar).
5- En cada bloque se destina una página entera para almacenar un "plano" de las páginas "malas" del bloque.
6- La vida útil de cada bloque es de sólo unos 1000 ciclos de borrado/escritura.
Por todo lo anterior, no se puede utilizar la memoria NAND como un dispositivo de bloques directamente. Entre otras cosas, aquellas áreas del dispositivo que se escribieran más frecuentemente acabarían destruidas rápidamente (por ejemplo las tablas de asignación de archivos del sistema FAT). Por eso es necesario, o bien un sistema de archivos específico para NAND que tenga en cuenta sus particularidades (yaffs2, por ejemplo), o bien una "capa de traducción" intermedia que se encargue de distribuir las escrituras y demás (UBI en linux).
Ahora piensa que la implementación de TODO lo que acabo de describir es absolutamente libre: la posición del flag de "página mala", la posición de la información de corrección de errores, la posición de la página "mapa de páginas malas en el bloque", el inicio y final de cada partición de la NAND, el sistema de archivos usado o la capa de traducción, etc...
Es evidente que los de ChinaChip no habrán reinventado la rueda por completo, pero aún así seguro que no es compatible con linux, y lograr que linux lo lea (y escriba) puede representar un esfuerzo monstruoso que creo sinceramente que no vale la pena acometer, en primer lugar porque su utilidad es marginal (existiendo la miniSD) y en segundo lugar poque quizás se tarde menos en hacer de linux un verdadero sustituto del firmware, en cuyo caso el problema desaparece.
< - >
Tal vez se pueda. He estado mirando el código fuente del gngeo y usa mmap para leer las roms con los gráficos (que suelen ser las más tochas) directamente desde un fichero .gfx sin tener que cargarlas en memoria.
El uso de mmap facilita la vida al programador, pero no consume menos memoria. Lo que se hace es utilizar el sistema de memoria virtual de linux y mapear un área de memoria virtual a un archivo. Cuando se accede a esa memoria se produce un fallo de página a lo cual el sistema responde mapeando memoria física en esa dirección virtual y cargando los datos de la posición correspondiente de disco.
Bueno... en realidad sí que puede consumir menos memoria porque con ese sistema se utiliza memoria sólo para las partes del archivo que se utilizan... con lo cual se pueden mapear todos los gráficos del juego pero sólo se consumirá RAM para los gráficos del nivel que se esté jugando en cada momento.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.