tal y como está ahora cubre todos mis conocimientos linuxeros, mount, cd y ls es de lo poco que se usar, y para colmo con el mount nunca me aclaro con cual dispositivo hay que montar XDDDDDD (o no monto nada, o monto el dispositivo que no es).
◄|| SECHS ||►
tal y como está ahora cubre todos mis conocimientos linuxeros, mount, cd y ls es de lo poco que se usar, y para colmo con el mount nunca me aclaro con cual dispositivo hay que montar XDDDDDD (o no monto nada, o monto el dispositivo que no es).
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
Joe macho si me tocan los euromillones, mañana te subvenciono
Bueno, al lío, lo de que no tenía RTC supongo que malinterprete lo que leí, y se referían a que no tiene HW para controlar el resto de la máquina cuando está apagada, es decir, que pongas una alarma y todos los días a las 8:00AM se encienda la consola sola y comience a reproducir un MP3 por ejemplo como hacen muchos móviles.
Sobre lo del interfaz, pues como te dije no tengo ni idea de dispositivos empotrados y de que es prioritario usar los recursos mínimos, así que mi pregunta es la siguiente, para no meter la pata de nuevo.
Si yo me cojiera el jz-crosstools y el mipseltools-gcc412-glibc261 de Ingenic, ¿podría ponerme a compilar las SDL para el futuro linux de la dingoo? ¿podría compilar también cualquier aplicación que usara framebuffer? ¿o es mejor coger directamente una debian-mipsel y tirar con binarios precompilados?
Usuario Registrado
De lo que pone en el datasheet yo interpreto que el JZ4740 sí que tiene esa función. El problema es el hardware auxiliar. Me explico:Iniciado por SinMan
Joe macho si me tocan los euromillones, mañana te subvenciono
Bueno, al lío, lo de que no tenía RTC supongo que malinterprete lo que leí, y se referían a que no tiene HW para controlar el resto de la máquina cuando está apagada, es decir, que pongas una alarma y todos los días a las 8:00AM se encienda la consola sola y comience a reproducir un MP3 por ejemplo como hacen muchos móviles.
No me he metido a investigar a fondo cómo funciona el módulo RTC del JZ4740, y no voy a hacerlo de momento, así que hablaré de la experiencia que tengo acerca de cómo funcionan este tipo de dispositivos en muchos otros microcontroladores:
- El RTC forma parte de un dominio de alimentación separado del resto. Si el ingeniero de turno lo hizo todo bien, sigue funcionando aunque el resto de la CPU esté en en halt (alimentada pero consumiendo muy poco). En muchos micros es incluso posible quitar la alimentación al resto de la CPU.
- El RTC dispone de una función de alarma, gracias a la cual puede programarse para que haga una de estas dos cosas (o las dos): generar una interrupción o cambiar el estado de un pin de salida (esto último lo he visto MUY poco).
- Si lo que puede hacer es la interrupción, entonces la forma de reanudar el sistema a una hora dada consiste en poner la CPU "a dormir" y que la interrupción la despierte. Dependiendo de lo "profundo" del modo de sueño este desperar puede ser un reset o una reanudación de la ejecución donde lo dejó. Evidentemente cuanto más "profundo" sea el sueño menor consumo.
- Si lo que puede hacer es cambiar el estado de un pin, entonces con ayuda de poco más que unos transistores externos se puede hacer que la CPU tenga capacidad para "apagarse" ella misma la alimentación y "reconectarla" usando este pin especial a la hora programada. Evidentemente el "despertar" es siempre un reset y el consumo mientras "duerme" es ridículo, en realidad sólo lo que consuma el propio módulo RTC.
Como ya he dicho, esto último lo he visto sólo en micros muy recientes, por lo que lo más seguro es que sea lo otro. Además requiere como ya he dicho hardware externo y un diseño muy cuidadoso (que, sin ánimo de polemizar, no es habitual en los chinos). Y además ese consumo "ridículo" inherente a tener la CPU sin alimentar en absoluto sólo es necesario literalmente en sistemas que tienen que funcionar años enteros con una batería.
Así que creo que la dingoo seguramente funcionará de la primera forma. Por ota parte, estoy CASI seguro de que la dingoo tiene capacidad para "quitarse" a sí misma la alimentación por software (*), y que cuando la apagas realmente la CPU no está alimentada en absoluto. También estoy casi seguro de que o el RTC no tiene capacidad para activar la alimentación o no lo han implementado. Por lo tanto para tu aplicación de alarma la A320 debería estar encendida (aunque en modo de bajo consumo).
(*) Lo deduzco porque hay un pin GPIO que está conectado al botón de on/off, y porque cuando dejas colgada a la consola (que me ha pasado mucho mientras programaba la initialización del hardware) el botón deslizante de apagado no funciona (luego el apagado es por software).
Sí. El "curro" estaría principalmente en:Sobre lo del interfaz, pues como te dije no tengo ni idea de dispositivos empotrados y de que es prioritario usar los recursos mínimos, así que mi pregunta es la siguiente, para no meter la pata de nuevo.
Si yo me cojiera el jz-crosstools y el mipseltools-gcc412-glibc261 de Ingenic, ¿podría ponerme a compilar las SDL para el futuro linux de la dingoo?
- Configurar adecuadamente la SDL para que soporte sólo framebuffer y alsa/oss (aún no se cuál de los dos utilizaré en el kernel... creo que ya hablé del tema en otro mensaje).
- Hacer el compilado cruzado: normalmente si lo que vas a compilar está bien hecho (y la SDL lo está) ya te da alguna opción para especificar el compilador cruzado que hay que utilizar (se especifica el prefijo, que en este caso sería "mipsel-linux-". Si no, tienes que trastear con el sistema de build. Como digo, no creo que sea el caso de la SDL, pero no puedo asegurarlo.
Pues no lo puedo afirmar con seguridad, porque hasta ahora todo lo que he corrido en la A320 lo he compilado yo mismo (busybox), pero estoy casi seguro (referencia: linux para el onda VXnosqeué) de que cualquier binario debian-mipsel funcionará. Otra cosa es que por lo que sea interese compilar con opciones especiales el binario en cuestión (estoy pensando en el mplayer, en el que incluiría únicamente el soporte de framebuffer para adelgazarlo mucho, ya que soporta una burrada de tipos de salida de video).¿podría compilar también cualquier aplicación que usara framebuffer? ¿o es mejor coger directamente una debian-mipsel y tirar con binarios precompilados?
Betico y gepero
a vale , pensaba que era MR gasanco por eso lo decia , digo si que ha cambiado este chaval jeje
sigue asi booboo
Vive y deja vivir
Usuario Registrado
Vaya, así que lo de Alarma/Calendario de momento nada.
Bueno, con respecto a lo del SDL le echaré un vistazo. Yo personalmente me decidiría por ALSA que es un driver más moderno y OSS está casi obsoleto, lo que no sé es si ALSA es más pesado que OSS.
El mplayer también lo provee Ingenic para linux, con lo que supongo son optimizaciones para su CPU, ademas es una versión moderna "MPlayer-1.0rc2-20090218"
Game coder
Madre mía booboo, en unos días has armado un mini Linux para la consola con cero de información del fabricante. Veo que tanto Alsa como Oss son drivers de sonido, pero creo que lo prioritario sería implementar las funciones básicas de vídeo usando las librerías del soft3d. No creo que el Linux de Ingenic implemente el acceso específico al framebuffer de la Dingoo. A no ser que hayáis sacado ya los registros para escribir en la pantalla. Si he dicho algo raro me lo decís.
Usuario Registrado
Te debes haber saltado unos cuantos mensajes. El framebuffer era al mismo tiempo lo más complicado y lo más prioritario pero después de muchas horas de sueño perdido ya está resuelto. De hecho ayer colgué un video de linux arrancando en el framebuffer.
En teoría a día de hoy ya se podría usar la SDL para acceder a pantalla, y con ella cualquier programa que la use. Aunque falta por supuesto el sonido y el teclado (esto último es muy fácil pero voy a meterme primero con el sonido).
◄|| SECHS ||►
Una vez funcionen video, audio y teclas ya se tiene un Linux lo suficientemente funcional como para empezar a portar cosas para él (asi dicho parace que fuera poca cosa XDDDD).
Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadia
Usuario Registrado
Teclado, olvidas el teclado, que he estado mirando esta mañana y es casi trivial.
Estoy buscando la forma de ordenar y publicar toda la información, seguramente en un wiki, pero me va a llevar algo de tiempo por cuestiones que no vienen al caso.
◄|| SECHS ||►
¿pero que utilidad tiene dar soporte a teclado si no tiene un puerto para enchufarlo? ¿es necesario para teclear via terminal? A mi por lo pornto se me ocurre que podría ser util un teclado virtual manejado con el pad como el sterm de la gp2x (o algo similar al sistema de grabar iniciales en los arcades antiguos para mas datos).
Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadia
No colecciono gifs
Tiene un usb que se puede usar para enchufar dispositivos si no me equivoco, yo con un menú clásico con sus iconcitos me apaño, para desarrollar y testear cosas si que es practico aunque lo seria mas configurar el usb como red y teclear desde el pc por telnet/ssh.
Menudo curro te estás pegando booboo !!
Usuario Registrado
·Era éso en lo que estaba pensando, pero como bien dices habrá que ver cómo se comporta la peque.
Muchas gracias por esas contestaciones tan extensas, yo iba a comentarte que habían distros de mips aquí: http://www.linux-mips.org/wiki/Distributions pero creo que ya lo tendrás más que visto.
Jamás había oído hablar de Busybox hasta hoy.
Usuario Registrado
Me he expresado mal. Cuando he dicho "teclado" me refería a las techas que tiene la A320. El subsitema de input de linux tiene que reconocer las pulsaciones y generar los correspondientes eventos para que puedan ser leídos por los programas de usuario.
La idea que llevo es "mapear" cada uno de los botones a una tecla estándar, a ser posible una que tenga sentido: el joypad a las flechas, el botón A a la tecla que suelen usar los emuladores como botón A, etc... así el kernel se encarga de todo y desde el punto de vista de las aplicaciones lo único que pasa es que hay un teclado al que le faltan la mayoría de las teclas. En lo relativo al teclado lo único que habría que modificar de un emulador determinado serían todas aquellas funciones que se controlen con una tecla que no esté disponible en la A320.
Lo de tener un teclado virtual lo veo poco útil dadas las características de la consola. El propósito de todo este fregado es única y exclusivamente tener un entorno ejecución linux, de forma que el portado de emuladores y otras aplicaciones sea lo más sencillo y directo posible, y de paso, la gente pueda programar aplicaciones nuevas rápidamente y con los conocimientos que ya tiene.
Este es el plan:
1- Kernel funcionando con soporte completo de hardware y un rootfs mínimo.
2- Aplicación "principal" que sustituya a la del firmware y que proporciona el menú de reproducción, configuración, ejecución de aplicaciones, etc.
3- Emuladores y todo lo demás (lanzados por la aplicación "principal").
En cuanto tenga el soporte de hardware a medias, ya puede alguien ponerse a trabajar en la aplicación principal (yo no creo que pueda, además de que no es mi especialidad), y también en portar emuladores y demás.
Es evidente que al principio sin la aplicación "principal" lista la A320 sería poco usable a nivel general, pero ¿qué mas dá?... si logramos hacer un arranque dual no cuesta nada arrancar en linux y con un menú patatero lanzar un emulador o lo que sea. Siempre será mejor poder usar un emulador de esa forma que no poder en absoluto (o tener que portarlo usando el SDK de Dingoo).
Por cierto... respecto a la aplicación "principal" sugiero reutilizar diseños e ideas existentes, por ejemplo rockbox. Ahora que lo menciono seguramente alguien se preguntará por qué no he ido directamente a intentar portar rockbox a la dingoo. La respuesta es que rockbox es un firmware monolítico que está muy bien para dispositivos de potencia limitada como los reproductores mp3, pero que creo que se queda corto para la Dingoo. Y además Ingenic proporciona gran parte del trabajo hecho con linux, mientras que con rockbox hay que rehacerlo todo (aunque tener el código para linux es una excelente referencia).
< - >En efecto, tiene un puerto USB que puede funcionar en modo host (como un PC), pero eso requiere de un hub externo con alimentación propia, ya que la A320, a diferencia de un PC, no proporciona los +5V del puerto USB.
Hay soluciones más sencillas que ya he estado explorando: el hardware USB de la A320 soporta lo que en linux se llama "modo gadget", que no es más el el modo "periférico". Linux implementa varios tipos de periférico: CDC ACM, ethernet y almacenamiento masivo entre otros.
1- CDC ACM: es algo más complicado pero se puede resumir en que es un puerto serie sobre USB. Cuando conectas la A320 a un PC con linux aparece el dispositivo /dev/ttyACM0. Lanzas el minicom y listo, ya tienes acceso por terminal (en la A320 tiene que estar corriendo getty sobre /dev/ttygserial).
Insisto: esto ya lo he probado y funciona perfectamente. La pega es que sólo proporciona un puerto serie Y NADA MÁS. Para transferir ficheros habría que recurrir a un protocolo sobre puerto serie (xmodem, zmodem, etc) o usar la miniSD.
Nota: sobre un sólo puerto serie se pueden tener varios pseudoterminales usando la aplicación screen.
2- Ethernet: en la dingoo aparece un interfaz de red llamado usb0, y cuando la conectas a un PC con linux debería aparecer como un adaptador ethernet USB (digo "debería" porque en la prueba rápida que he hecho esta mañana no ha sido así...). A partir de ahí configuras los interfaces de red de la forma apropiada y a hacer telnet, ssh o lo que sea.
Esta opción tiene un problema: hay que habilitar el soporte de red en el kernel, lo cual lo "engorda" mucho (pero mucho mucho, aunque se ponga lo mínimo) consumiendo un recurso escaso de la A320 que es la RAM.
La principal ventaja es que sobre la red así construida se puede hacer de todo y simultáneamente (transferir archivos con FTP o SCP, tener varios terminales abiertos, etc).
3- Este modo gadget hace a la dingoo visible para el PC como uno o varios dispositivos de almacenamiento, de forma similar a como hace el firmware original. Aquí obviamente podemos transferir archivos sin problemas, pero nada de terminal.
Y alguien se preguntará ¿no se puede configurar el kernel para que la A320 se comporte como un dispositivo compuesto ("composite"), siendo al mismo tiempo una línea serie CDC ACM y un dispositivo de almacenamiento masivo?.
Pues en teoría sí, pero hay que desarrollar el driver. En el kernel de que dispongo (2.6.24.3) hay que hacerlo casi todo. En el kernel maś reciente (2.6.28.x) este asunto está más avanzado y es más sencillo de hacer, ya que han separado cada gadget en una capa que gestiona el USB y otra que implementa la funcionalidad, de forma que escribir un driver gadget compuesto se hace reutilizando las funcionalidades existentes (con la notable excepcción del almacenamiento masivo... aaaaaarrg!!!). Portar toda la faena de Ingenic al último kernel es inviable, y "portar hacia atrás" los drivers gadget del último kernel al de Ingenic tampoco es sencillo.
Así que creo que de momento la forma de desarrollar para linux en una A320 sin consola RS232 como la mía va a ser mediante un terminal serie CDC ACM, transfiriendo los archivos con zmodem o con miniSD. Más adelante quizás me plantee hacer el dispositivo compuesto para el kernel 2.6.24.3, o MEJOR AÚN, quizás alguien lo haga por mí aunque paradójicamente con esto precisamente sí que es IMPRESCINDIBLE una A320 con consola RS232 como la mía (no puedes depurar el funcionamiento del dispositivo compuesto a través de una consola vía CDC ACM en el propio dispositivo compuesto).
Si se me ocurre alguna otra alternativa ya lo comentaré.
Compartiendo aprendemos y ganamos todos. Y como ya he dicho me lo estoy pasando teta.Menudo curro te estás pegando booboo !!
< - >Yo llevo haciendo electŕonica y programación para sistemas empotrados muchos años y los últimos han sido con versiones empotradas de linux. Busybox es un conjunto de aplicaciones estándar de línea de comandos pensadas para sistemas empotrados. El objetivo es consumir el mínimo de recursos y ocupar el mínimo de espacio. Están todas las aplicaciones básicas necesarias: sheel, ls, telnet, find, cp... hay literalmente cientos. Todas compiladas en un ejecutable monolítico (el que he compilado para la dingoo ocupa 2MB con la libc incluida, es decir, un ejecutable totalmente estático).
Si tuvieras que instalar una or una las aplicaciones te puedes ir perfectamente a 20-40MB que no están disponibles en casi ningún sistema empotrado. La A320 en realidad es una excepción porque al ser un media player necesariamente cuenta con mucho espacio de almacenamiento. En cualquier caso siempre es mejor el busybox porque las aplicaciones consumen espacio en disco, pero cuando corren también consumen RAM, así que cuanto más pequeñas sean mejor.
Última edición por booboo; 08/05/2009 a las 00:00 Razón: Edición automática anti doble-post.
◄|| SECHS ||►
Ah, entonces es que no me habías leído XDDDDDD
En cuanto a lo que dices del entorno principal/lanzador de aplicaciones; creo que se podría portar el Gmenu2x (supongo que habrá código fuente disponible o si no se podrá pedir al autor), es una alternativa muy configurable bonita y con un consumo de recursos realmente pequeño.
Google stadia es un fracaso, google stadia funciona mal, google admite su fracaso con stadia
Let's Rock!
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.
.:: Yo, ya ni veo el código. Solo veo una rubia, una morena, una pelirroja... - Cifra (The Matrix) ::.
Citar
Marcadores