Lanzamiento de DOOM en la calculadora HP Prime G2



Instalar DOOM en cualquier dispositivo es como izar el estandarte del ganador en una fortaleza caída. Me hicieron la pregunta "bueno, ¿empezaste la perdición?" al menos 35 veces cuando se enteraron de que estaba jugando con esta calculadora. Decidí no decepcionar a la audiencia y lograr el lanzamiento de DOOM. En el camino, se convirtió en una buena prueba del rendimiento del equipo, además de revelar errores desagradables. ¡Entonces vamos!



Noticias del proyecto



Para aquellos que se preguntan cómo conseguí que DOOM funcionara, pueden saltarse este capítulo y pasar al siguiente. Simplemente presenta el estado actual del proyecto.



Como recordará en las partes anteriores ( parte 1 y parte 2 ), me dediqué a poner Linux en una calculadora, reconstruir u-boot, kernel, rootfs. Desde entonces, he estado muy involucrado en la calculadora e incluso descubrí a fondo lo que se hizo en u-boot, kernel y árbol de dispositivos. Tienes que entender que este es mi hobby, en mi tiempo libre de mi principal trabajo y familia, por lo que no todo va rápido, y en ocasiones es algo ilógico, simplemente porque hoy hay ánimo para hacer esto y no de otra manera.



La principal noticia tuvo lugar, gracias al usuario Alx2000y, quien me invitó a una charla en un carrito, donde la gente vio su firmware para Xiaomi Gateway en un procesador similar. Incluso hay un artículo sobre Habré sobre el tema . La gente ya ha avanzado mucho en este tema, ampliando increíblemente la funcionalidad del dispositivo. Y me ayudó mucho a vencer el problema de la nand. Como recordará, al principio borré mi imagen de nand por estupidez. Como resultado, obtuve una cantidad bastante grande de sectores defectuosos "virtuales", lo más desagradable es que los sectores defectuosos estaban al principio y no permitían que u-boot se escribiera allí. A continuación se muestra una lista de sectores defectuosos, la mayoría de ellos son virtuales.



=> nand bad
Device 0 bad blocks:
  00000000
  00020000
  00040000
  00060000
  012c0000
  04e20000
  05280000
  094c0000
  17b20000
  1ff80000
  1ffa0000
  1ffc0000
  1ffe0000
=> 
      
      





Lenar, del chat anterior, me ayudó mucho, el problema se resolvió con solo dos comandos en u-boot:



nand erase.chip
nand scrub.chip
Really scrub this NAND flash? <y/N>
y
      
      





Después de eso, verificamos la cantidad de sectores defectuosos y, ¡he aquí, hay muchos menos de ellos!



=> nand bad

Device 0 bad blocks:
  1ff80000
  1ffa0000
  1ffc0000
  1ffe0000
      
      





Como resultado, ahora puedo cargar u-boot en el sector cero y arrancar. Por el momento, la calculadora se puede cargar simplemente aplicando energía y estará completamente cargada con Linux, con una pantalla de trabajo y la capacidad de ejecutar programas a través de UART. Incluso funciona correctamente para DOOM. "Pero, hay un matiz" (C). Aparentemente, el controlador del teclado se superpone de alguna manera con el controlador ubifs y, como resultado, si presiona cualquier tecla del teclado, la calculadora se bloquea instantáneamente. Un pánico de kernel incluso voló sobre mí una vez, pero no pensé en guardarlo para al menos encontrar el lugar de esta intersección. Entonces, por ahora, todo funciona en initramfs con seguridad. En mi canal de telegramas se publicó un video que demuestra el trabajo de cargar nand, lanzar DOOM y congelar .



Por otras buenas noticias, intenté poner ubuntu en nand, también funciona correctamente. Los paquetes, por supuesto, no se pueden instalar, pero en general se puede trabajar y usar, lo que también es conveniente. Pero sin un teclado que funcione, estos juegos todavía carecen de significado práctico.



En la última parte, me quejé de que u-boot tiene un comportamiento diferente cuando se ejecuta en nand y desde la RAM. Pasé dos días hurgando en los códigos fuente de u-boot para averiguar qué estaba pasando. Y todo resultó ser trillado (incluso avergonzado). La utilidad uuu, al iniciar u-boot desde la memoria, pasa allí sus variables de entorno. Más precisamente, llama a mfgtool_args y, como resultado, la línea de la variable de entorno de arranque se ve así:



bootargs=rdinit=/linuxrc g_mass_storage.stall=0 g_mass_storage.removable=1 g_mass_storage.file=/fat g_mass_storage.ro=1 g_mass_storage.idVendor=0x066F g_mass_storage.idProduct=0x37FF g_mass_storage.iSerialNumber= mtdparts=gpmi-nand:4m(boot),8m(kernel),1m(dtb),1m(misc),-(rootfs) clk_ignore_unused
      
      





Por supuesto, si arranca desde nand, entonces, con tales parámetros, los ubifs de la cuarta sección no serán visibles. Por lo tanto, después de cargar u-boot en la RAM, establecí a la fuerza las siguientes variables de entorno:



setenv bootargs  console=ttymxc0,115200 ubi.mtd=4 root=ubi0:rootfs rootfstype=ubifs mtdparts=gpmi-nand:4m(boot),8m(kernel),1m(dtb),1m(misc),-(rootfs)
      
      





Y todo funciona muy bien.



Permítame explicar por qué es necesario: si actualiza el cargador de arranque en el sector cero, la capacidad de trabajar a través de mfgtool (utilidad uuu) desaparece. Y en esta etapa, consistente en desarrollo y depuración, es la herramienta principal. Por lo tanto, es más fácil dejar la utilidad uuu ejecutándose y cargar u-boot manualmente cada vez.



Lanzamiento de DOOM



Pasando a la parte divertida: ejecutar DOOM en la calculadora. Como puedes imaginar, no fue en vano que escribí sobre todos los problemas al principio. Puedes ejecutar DOOM cuando se carga en un flash NAND, allí puedes poner tarjetas de todo tipo, todas las versiones posibles de DOOM y, en general, lo que quieras. Pero cuando se ejecuta en RAM, estamos limitados por el tamaño de la imagen rootfs en aproximadamente 15 MB (la práctica ha demostrado que 16 todavía se mueven). En este sentido, tuve que seleccionar la versión de DOOM y realizar el montaje correcto, además de aprender a trabajar con él.



Resultó que todas las cosas buenas se inventaron para nosotros hace mucho tiempo, y DOOM se puede ensamblar directamente en buildroot sin moverse del sofá. Descubrí esto cuando busqué en Google todas las posibles variantes de DOOM para sistemas integrados y traté de construirlos. Al final resultó que, es suficiente para ejecutar:



make menuconfig
      
      





Y elige DOOM. Esto se hace en " Target packages ---> Games --->



"





Tenemos dos versiones de DOOM a nuestra disposición: chocolate-doom y prboom . Después de experimentar un poco, me di cuenta de que chocolate-doom no quiere encajar en initramfs. A menos que, si elimina los archivos wad por completo. Estaba tratando de encontrar archivos de taco recortados que encajaran con la fatalidad del chocolate. Pero ella se negó a trabajar con ellos. Como resultado, intenté instalar la versión chocolate en nand (junto con prboom) y la probé allí. Seleccioné parámetros, etc. El experimento resultó en el siguiente método de lanzamiento:



export SDL_NOMOUSE=1 
chocolate-doom -geometry 320x240 -bpp 24 -nomouse
      
      





El resultado me decepcionó mucho: esta versión de doom de forma incorrecta (o, por el contrario, correctamente) estira la pantalla, dejando franjas anchas en los bordes de la pantalla, lo que realmente no me gustó.





La versión chocolate de DOOM. Una raya negra es visible debajo.



Al inicio, mi chocolate doom me dice qué hace el cambio de tamaño de la ventana:



I_InitGraphics: 320x240 mode not supported on this machine.
I_InitGraphics: Auto-adjusted to 320x200x32bpp.
      
      





Por lo tanto, me decidí por prboom. Hice la imagen junto con los archivos WAD compartidos y el propio prboom , eliminé todas las cosas innecesarias. Pero, de todos modos, durante mucho tiempo no pude hacerlo funcionar. Leí todo tipo de manuales, busqué cómo configurar para que todo funcionara correctamente. La imagen se muestra, reacciona a los botones, pero la pantalla se estira torpemente y muestra curvas de color. Hasta que encontré los parámetros de lanzamiento ideales en algún foro.



En general, para nuestra calculadora, el lanzamiento de prboom es el siguiente: apague el mouse y luego ejecute prboom con los siguientes parámetros:



export SDL_NOMOUSE=1 
/usr/games/prboom -width 320 -height 240 -nosound -vidmode 32bit
      
      





El parámetro clave aquí: "-vidmode 32bit"



.





Estuve buscando parámetros adecuados durante mucho tiempo, y solo con esto comenzó todo. Por conveniencia, escribí todo en el script d.sh. Finalmente todo funciona, ¡incluso puedes jugar!





Especialmente para ti, he preparado un ensamblaje actualizado de flash_utility con DOOM , que puedes ejecutar en tu calculadora incluso sin flashearlo, y mostrar a tus amigos, dicen, que DOOM funciona en mi calculadora. Basta con desmontar la calculadora, cerrar los contactos descritos en la primera parte y ejecutar



sudo uuu doom.uu
      
      





Al final de todos los pasos, recibirás una calculadora, con linux y DOOM. Para iniciar DOOM, deberá iniciar sesión y ejecutar en la calculadora:



./d.sh
      
      





Para resumir



¡DOOM funciona! ¿Puedo jugarlo? Bueno, localmente, descargando desde una computadora, puede hacerlo. Se ve genial y hermoso, pero de hecho, no es realmente lo que quieres obtener. Es realmente genial cuando estás en el metro, agarra una calculadora y sácala de tus piernas anchas, enciéndela (el modo de ahorro de energía no funciona en este momento) e inicia DOOM. Es genial jugar en el metro con una calculadora en DOOM, Duke Nukem 3D, Quake I, II, III, etc. Pero el hecho es que DOOM se ejecuta en esta pieza de hardware. Pero aún queda mucho trabajo por hacer.



En general, no hay suficiente al menos una pequeña comunidad alrededor de esta calculadora (al menos más que yo), por lo que hay probadores de problemas, hay alguien con quien hablar y compartir, para escuchar consejos. El autor original claramente se ha enfriado con este proyecto, aunque hizo un trabajo titánico. Lo entiendo bien y no puedo reprocharle que no quiera ayudar ni siquiera con consejos sobre este proyecto. Bueno, dio pequeñas recomendaciones, pero claramente ya no dependía de él. Por lo tanto, si tiene ideas, una calculadora, un deseo de ayudar, al menos con un consejo, escriba aquí o en el carrito, ¡estaré encantado!



PD: ¿Por qué estoy haciendo esto?



Muy a menudo me preguntan "¿para qué"? Comprendo intelectualmente que es una estupidez responder a esta pregunta, pero de todos modos responderé.



¿Por qué un artista pinta un cuadro o un autor escribe un libro? Seamos honestos, el 90% de los libros, pinturas y otras obras puede que no vean la luz en absoluto, y de los que sí lo hacen, una fracción del por ciento se conocerá y ganará una amplia gama de lectores. En pocas palabras, la mayoría de los creadores están haciendo un trabajo "inútil". Además, muchas obras ni siquiera encuentran a sus lectores, pero ¿por qué no deberían hacerlo? ¿Qué impulsa a esta gente? Todo es bastante común. Están impulsados ​​por un simple sentimiento:





En pocas palabras, lo haces porque es genial y está apurado. Y, curiosamente, en el futuro traerá grandes beneficios, aunque no tan obvios como parece.



Archivos para descargar










All Articles