Una cosilla, ¿ha visto alguien si hay alguna razón de hardware por la que el problema de los botones B/Y exista?
Usuario Registrado
Una cosilla, ¿ha visto alguien si hay alguna razón de hardware por la que el problema de los botones B/Y exista?
Forero PRO
Solo para aportar mi granito de arena en esto: en muchas consolas el teclado (joypad, botones) está mapeado no a un teclado normal sino a un dispositivo joystick permanentemente enchufado a la consola. Si lo haces así será más fácil portar los emuladores de otras consolas portátiles que ya están preparados para leer de un joystick.Iniciado por booboo
De todas maneras, cambiar en los emuladores "lectura de joystick" a "lectura de teclado" no es nada difícil. Si te es más fácil mapear los botones a un teclado con menos teclas que a un joystick, pues que sean los programadores de emuladores los que trabajen
Usuario Registrado
Gracias chipan, ayer me tiré todo el día buscando GUIs SDL incluso echando un vistazo al rockbox para ver si es suficientemente modular como para sacar el interfaz exclusivamente.
Afortunadamente GMenu2x es libre y esta disponible en SourceForge
<->Tu que sabes booboo, ¿como sería de pesado usar el sw_suspend y como de útil o inútil?
Puede que no sea posible, o incluso que sea solo un par de segundos mas rápido que un arranque normal, por eso lo pregunto.
Última edición por SinMan; 08/05/2009 a las 11:43
CPC Fan
No estoy nada de acuerdo. Hay muchos juegos/emus que no tienen soporte para joystick y puede llegar a ser un coñazo añadírselo. Las SDL de la GP32 usaban el método comentado por booboo y no podía ser más cómodo o yo, por ejemplo, para la Xbox uso un wrapper de pad -> teclado y/o ratón que me permite emular el teclado/ratón añadiendo una sóla línea de código.
Forero PRO
Bueno, en realidad pensaba en juegos y emus de la Gp2x, donde tanto la SDL como la minilib mapean los controles como un joystick cualquiera
De todas formas es verdad que desde el punto de vista del programador da prácticamente igual una forma o la otra. Pero si se mapea como joystick, los programas de la Gp2x serán más fáciles de portar
Usuario Registrado
En efecto, el código fuente está disponible. Parece la mejor alternativa.
Ayer hice un intento rápido con el sonido que me sirvió para, de entrada, saber que el soporte OSS del kernel de ingenic no funciona (gran petada cuando accedes al dispositivo), así que el debate OSS ("legacy" pero más compacto, no soporta audio simultáneo de varias aplicaciones, cosa que en la A320 no es problema) versus ALSA (default a día de hoy, más pesado, audio simultáneo) ya está zanjada. Ahora he de hacer funcionar ALSA. Ya he compilado libid3tag, libmad y madplay para la A320, pero tengo algún problema con la librería libasound que supongo que solucionaré rápidamente en cuanto tenga tiempo de sentarme con la A320. A ver si pronto puedo colgar un vídeo del madplay reproduciendo un mp3.
< - >En principio no hay problema en utilizar módulos en el kernel. Hay dos opciones, o se tiene un kernel mínimo que lleve un initrd empotrado que cargue los módulos necesarios para acceder al soporte donde está el rootfs, lo monte y haga el pivot_root, o bien se tiene un kernel mínimo pero con esos módulos compilados monolíticamente. Lo segundo es más sencillo, y además lo primero no tiene sentido en un entorno donde las opciones de arranque son prácticamente invariantes.Así da gusto (y envidia, sana, pero envidia xD), gracias booboo por hacer tan interesante y aleccionador este hiloUna duda respecto a este punto del que hablas ¿esto sería así incluso aunque configures el kernel para que lo compile como módulo y lo cargue bajo demanda, es decir, cuando se conecte el USB para usarlo en modo CDC Ethernet? Lo pregunto porque si fuera así, como módulo, supongo que no habría problema, aunque si lo dices porque habría que trabajar casi necesariamente con un kernel Linux monolítico (como supongo que estás haciendo ahora) entonces si que sería problema el consumo extra de RAM por compilar el soporte de red del kernel.
La PEGA es que habilitar la carga dinámica de módulos ya engorda el kernel en 300K (de código, más la RAM necesaria que imagino que no será mucha). A eso súmale otros 300K de código más bastante RAM para el soporte mínimo de red.
Ir cargando módulos en un sistema como la A320, donde el hardware es invariante y no hay eventos "hotplug", no tiene sentido excepto para desarrollo. Por eso yo soy partidario de tener un kernel lo más compacto y ligero posible. Sin embargo, eso complica el desarrollo de drivers hardware e impide la comunicación vía ethernet, por lo que creo que la mejor opción es tener un sistema de arranque que permita seleccionar a) firmware original, b)kernel normal c) kernel desarrollo.
Voy a empezar a trabajar YA en un un firmware original modificado para que en lugar de cargar directamente el ccpmp cargue el u-boot y éste a su vez pueda lanzar el firmware original o un kernel/rootfs en la miniSD. Creo que se ma ha ocurrido una forma de hacerlo bastante sencilla y que se instalaría como cualquiera de los firmwares "custom" que han salido ya.
< - >Ah!... comprobé el asunto pero se me olvidó comentarlo por aquí.
No es un problema de hardware. El hardware puede leer perfectamente y de forma totalmente independiente los dos botones. De hecho hay un pin GPIO dedicado para cada botón de forma independiente.
Por lo tanto es un puñetero bug. Y además me atrevo a aventurar que debe ser un bug tonto y muy fácil de arreglar, pero ya sabéis cómo son los chinos para estas cosas.
< - >Interesante idea. No lo sabía. Me costaría un pelín más que lo del mapeo de teclas porque Ingenic ya proporciona un driver para esto, mientras que tendría que hacer yo el de joystick (que es simple en todo caso).Solo para aportar mi granito de arena en esto: en muchas consolas el teclado (joypad, botones) está mapeado no a un teclado normal sino a un dispositivo joystick permanentemente enchufado a la consola. Si lo haces así será más fácil portar los emuladores de otras consolas portátiles que ya están preparados para leer de un joystick.
De todas maneras, cambiar en los emuladores "lectura de joystick" a "lectura de teclado" no es nada difícil. Si te es más fácil mapear los botones a un teclado con menos teclas que a un joystick, pues que sean los programadores de emuladores los que trabajen
Sin embargo, salvo que haya algo que se me escape, me da a mí que lo de las teclas es más práctico, ya que absolutamente TODOS los emuladores deben tener soporte para teclado, mientras que quizás haya alguno que no tenga soporte de joystick. Por otra parte se me ocurre que en los emuladores siempre será necesario poder reconfigurar los mapeos de teclas a gusto del usuario... ¿se puede hacer esto con los botones del joystick? (no he usado muchos emuladores, y nunca ninguno con joystick).
< - >TIENE que ser posible, simplemente porque el firmware original lo hace. Otra cosa es que sea complicado de dilucidar cómo funciona el hardware o que la función de suspend no esté bien implementada en alguno de los drivers de Ingenic (esto es lo que más miedo me da). En cualquier caso todo esto es solventable con tiempo y paciencia.
En cuanto a su utilidad, un firmware basado en linux que SUSTITUYA el firmware original DEBE implementar la función suspend. Aunque sólo tarde 5 segundos en cargar, es una eternidad comparado con la respuesta instantánea del suspend.
< - >¿Qué tal un mapeo simultáneo y/o configurable?. No lo sugeriría si lo del joystick no me pareciera, a priori, relativamente sencillo de hacer.Bueno, en realidad pensaba en juegos y emus de la Gp2x, donde tanto la SDL como la minilib mapean los controles como un joystick cualquiera
De todas formas es verdad que desde el punto de vista del programador da prácticamente igual una forma o la otra. Pero si se mapea como joystick, los programas de la Gp2x serán más fáciles de portar
Última edición por booboo; 08/05/2009 a las 15:33 Razón: Edición automática anti doble-post.
Forero PRO
De todas formas, haz lo que te parezca más fácil en espacio de kernel, que ya tienes bastante trabajo. Cambiar de botones a teclado en los emuladores y programas será la parte fácil de cualquier port. Y además la práctica totalidad de emuladores y juegos de PC tienen entrada por teclado y no por joystick.
Usuario Registrado
Hola,
Estoy intentando conseguir el arranque dual. Sobre el ccpmp.bin sé que:
1- Se carga en 0x80004000.
2- El tamaño de datos a cargar está en el segundo DWORD.
3- Una vez cargado, el loader salta a la posición 0x80004008.
El ccpmp.bin completo ocupa 5MB, pero sólo algo más de 2MB están ocupados. El resto está libre para poner lo que queramos, aunque sólo se cargará si se modifica adecuadamente segundo DWORD. He comprobado que poniendo 0x00500000 (=5MB) en el segundo DWORD todo sigue funcionando correctamente.
La estrategia es:
1- Portar u-boot y configurarlo para que carge un kernel y un root filesystem de la miniSD. Esto ya está hecho y funciona perfectamente si cargo directamente este u-boot en memoria y lo ejecuto.
2- Modificar el u-boot para que su dirección de carga sea 0x80404000 (0x80004000 + 4MB).
3- "Incrustar" el u-boot en el offset +4M del archivo, lo que equivaldría una vez cargado en memoria a la posición 0x80404000, que es para lo que he compilado el u-boot.
4- Parchear las primeras instrucciones de ccpmp.bin en 0x80004008 con un salto a la posición donde estará cargado el u-boot (0x80404000).
5- En esa posición poner un código ASM que compruebe el estado de una tecla: si no está pulsadan ejecuta las instrucciones que se parchearon y salta otra vez al ccpmp.bin, con lo que el sistema debería arrancar de nuevo. Si la tecla está pulsada, continúa ejecutando u-boot, el cual monta la miniSD y carga el kernel, etc.
Todo eso ya está hecho, pero me encuentro con un problema: el u-boot funciona perfectamente si lo cargo directamente en memoria en la posición 0x80404000. Sin embargo, cuando lo "incrusto" en el ccpmp.bin:
a) El arranque normal de la A320 funciona correctamente: es decir, se salta a la posición 0x80404000, allí se comprueba que la tecla no está pulsada, se ejecutan las instrucciones eliminadas en el parcheo y se salta otra vez al ccpmp.bin. Todo OK.
b) El arranque u-boot funciona pero sólo hasta que empieza la carga del kernel (o quizás la inicialización de la miniSD, no lo sé seguro). Da una excepción "TLB load".
Sospecho que el problema es que el loader del firmware original avanza bastante en la configuración de la CPU (el TLB tiene que ver con la MMU) mientras que u-boot espera un sistema mucho más "virgen".
¿Alguien que sepa más que yo de la arquitectura MIPS puede sacar alguna conclusión de todo esto?
Lo siguiente es la captura de consola cuando se arranca con la techa pulsada (estoy usando SELECT, pero se puede cambiar fácilmente).
Código:NAND Booting...ECD755B6.. loader size = 0x00051670 .. OK NAND Loading... get ccpmp_config ok!!! ccpmp_config.firmware_name = A320.HXF. ccpmp_config.update_key = 123, ccpmp_con. loader normal mode... Creating ftl device... id:EC D7 55 B6 78 id:00 00 00 00 00 id:00 00 00 00 00 id:00 00 00 00 00 OK. usb_connect = 1 into lcd_init. loader -- into lcd_init. into init_lcd_gpio. out init_lcd_gpio. loader -- init_lcd_gpio ok. into Init_LCM_MOUDLE_ILI9325!!! out Init_LCM_MOUDLE_ILI9325!!! loader -- init_lcd_register ok. loader -- out lcd_init. Start decode... OK 153602. out lcd_init. get_lcd_brightness -- value = 3. len is 0x 500000 os_len = 0x 500000. checksum = 0x26f75489. 1 - ret = 0 2 - ret = 1 Run image... U-Boot 1.1.6 (May 12 2009 - 02:54:16) Board: Dingoo A320 (CPU Speed 336 MHz) DRAM: 32 MB Flash: 0 kB Using default environment In: serial Out: serial Err: serial Hit any key to stop autoboot: 0 MMC card found ============================================================= Exception: SP:81EAAA28 EPC:81FBBEE8 CAUSE:00800008 TLB load Reg dump: ra = 81FC1D38 fp = 00000027 gp = 81FCBDD0 t9 = 81FBBED8 t8 = FFFFFFFF s7 = 00000003 s6 = 00000000 s5 = 0000005C s4 = B0010168 s3 = B0010158 s2 = 81FCE490 s1 = 81FCE490 s0 = 00000000 t7 = 00000000 t6 = 00000000 t5 = 81FCA844 t4 = 00000020 t3 = 81EAAD48 t2 = 00000004 t1 = 00000009 t0 = 81FCDFBC a3 = 00000000 a2 = 00000004 a1 = 00000000 a0 = 81FCDFBC v1 = 00000012 v0 = 00000000 AT = 00000000 LO = 00001CD1 HI = 00003000 ST = 10000402 EPC = 81FBBEE8
Forero PRO
Madremia que currada de nuevo!!
Si el cargador de la dingoo avanza tanto en la inicializacion, no se podria hacer algo como un loader pero en el orden contrario, es decir, carga el loader, si no hay tecla, resetea todos los valores y pasa a cargar el loader de la dingo, si hay tecla, se sigue iniciarlizando para linux, si hay otra tecla, kernel desarrollo, etc.
Se que es hablar por hablar, porque la currada te la estas dando tu, pero me gustaria saber cual es el problema de dicha opcion.
Asi mismo, no debe de ser sencillo el reseteo de los valores de la cpu, pero sino, antes de iniciar el arranque del kernel, no se podria hacer un reset?
Saludos
◄|| SECHS ||►
me gustaría ayudarte, pero sintiendolo mucho no tengo ni idea de lo que puede pasar.
Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadiala latencia es el problema intrinseco de stadia, el público abandona google stadia, stadia mal.
Usuario Registrado
Estoy desarrollando un emulador de WonderSwan para Dingoo A320.
Codificando la parte de sonido no veo como desde las SDK puedo reproducir desde un buffer PCM (solo hay una función LoadPCM para carga desde fichero).
¿Como puedo implementar la parte de sonido sin las SDK?
¿Existe algún emulador con código fuente libre en el que funcione correctamente el sonido?
Usuario Registrado
Sí, supongo que se podría. Estoy casi seguro de que el problema viene de que el loader inicializa la MMU, y yo de eso no tengo ni idea (arquitectura MIPS), ni siquiera se si es posible revertir esa inicialización, aunque supongo que bastaría con cambiar la configuración de la MMU a la misma que usa el kernel o a alguna otra que no entre en conflicto. En problema es que yo no se nada de la MMU de este procesador, ni de cómo configura la MMU el loader, y ni siquiera de cómo lo hace linux.
Me podría hacer el ánimo de aprender e ir haciendo pruebas, pero es que el proceso es AGÓNICO, ya que implica:
1- En linux preparar el código que quiero probar y meterlo en el ccpmp.bin.
2- En windows, meter el ccpmp.bin dentro de un archivo de actualización firmware HXF.
3- En windows, actualizar el firmware con el fichero anterior.
Además de necesitar dos ordenadores (o reiniciar), el proceso de actualización de firmware tarda como 5 minutos. Desarrollar haciendo pruebas a ciegas sólo funciona si es sencillo y rápido hacer cada prueba.
Sí, pero es que entonces volvemos al principio: la ROM de la A320 lee el loader de NAND, éste carga el ccpmp.bin, etc.Asi mismo, no debe de ser sencillo el reseteo de los valores de la cpu, pero sino, antes de iniciar el arranque del kernel, no se podria hacer un reset?
Que yo sepa, no hay forma de hacer un reset del sistema sin que éste arranque como se supone que debe hacerlo después del reset (lo cual, si lo piensas es lógico, ya que el reset, por definición, debe llevarte obligatoriamente a un estado conocido de incio). La única excepción es la que ya conocemos de pulsar un botón, que lo único que hace es que la ROM se de cuenta de la pulsación e inicie una secuencia de arranque alternativa.
Las secuencias de arranque alternativas de la ROM son cuatro, no nos son útiles (para un arranque dual controlable sin la ayuda del USB desde el PC) y no son modificables (precisamente por estar en ROM). De ahí que yo haya "pinchado" en un punto de la secuencia de arranque en el que puedo "entrar" fácilmente.
Y hago énfasis en "fácilmente"; ya que modificar el archivo ccpmp.bin es sencillo y contamos con herramientas para alterar los contenidos de los archivos HXF.
Por supuesto, la forma CORRECTA pero más complicada de hacerlo es reemplazar el propio loader por uno parcheado que lea la tecla SELECT en una etapa muy temprana de la inicialización del sistema (antes de haber trasteado con la MMU) y si está pulsado que cargue u-boot de la NAND en lugar de ccpmp.bin.
El problema es que esto ya requiere recurrir a herramientas más especializadas para grabar la NAND. Lo de modificar únicamente el ccpmp.bin tenía el atractivo de que se puede crear y distribuir un HXF que cualquiera puede instalar en su dingoo como cualquier otra actualización de firmware.
Conforme escribo me doy cuenta de que seguramente sea más fácil seguir este camino que pretender "desinicializar" la MMU (y ojo, que lo de que el problema está en la inicialización de la MMU es una sospecha... igual no es eso o además de eso hay problemas con otros periféricos).
CPC Fan
La única persona que conozco que sabe bastante de MIPS es Exophase. Ahora que los foros de gp32x están caídos, lo puedes encontrar en los foros de openpandora.
< - >Creo que el port del SDLPAL del programador chino flyspy reproduce el sonido desde un buffer, pero no hay código fuente disponible. Puedes probar a contactar con Subzero en su blog y pedírselo.
Última edición por A600; 13/05/2009 a las 00:50 Razón: Edición automática anti doble-post.
No colecciono gifs
Ayer vi la noticia de una empresa española que tiene pensado sacar un portatil/netbook/UMPC con linux que usa un micro Mips ( Ingenic ) , parece que les importa mucho el software libre y supongo que no les importará ayudar a la causa
http://www.iunika.com/ No veo una dirección de contacto por ningún sitio o estoy torpe...
Usuario Registrado
Me consta que nos lee gente no hispanoparlante para seguir el progreso, y las traducciones automáticas son nefastas. Yo preferiría no mudarme de foro. ¿Le importa a alguien si en adelante posteo en inglés?.
Por otra parte, lo que debería hacer es dedicar algo de tiempo a publicar toda la información que he ido averiguando de forma ordenada en un wiki o algo así... cuesta hacerse el ánimo.
Citar
Marcadores