Source: https://magazine.odroid.com/es/issue/full?issue=201911
Timestamp: 2020-01-21 17:28:57+00:00

Document:
Este artículo es una traducción autorizada del artículo alemán " ODROID-XU4: Tweaks unter Ubuntu 18.04 und Kernel 4.14".
Para los fanáticos de Macintosh Plus, ¡ahora existe una forma de ejecutar un emulador en ODROID-GO! Basado en el trabajo de spritesmods.com minimacplus, este proyecto aprovecha el hecho de que tanto el proyecto original como el GO usan un microcontrolador ESP32.
Alguna vez te has preguntado cómo usar todo el potencial del módulo eMMC en tu dispositivo ODROID, quizás hayas pensado que es demasiado complicado para ti. Puede resultar un poco espeluznante si eres nuevo en estos dispositivos. Además, ¿cómo usas uno? ¿Qué herramientas necesitas?
Hace unos dos años tuve una idea algo descabellada: ¿Sería posible crear un sistema de escritorio de "doble pantalla" utilizando dos ODROID, cada uno con una pantalla diferente, pero que actuasen como un escritorio unificado?
Este artículo te mostrará en detalle cómo pulir tu consola de videojuegos Monku Retro 3 (ODROID-XU4).
Play Pass: ¿Por qué Google trata de cubrir preventivamente el período previo al estreno de Stadia al lanzar un servicio indudablemente inferior? Play Pass es un servicio de suscripción mensual que te permite descargar y jugar una amplia biblioteca de juegos y otras aplicaciones de productividad que están actualmente disponibles ▶
Si has detenido en los Foros de Hardkernel el tiempo suficiente, la expresión "módulo kernel" debería serte bastante familiar. Sin embargo, si eres nuevo en el mundo de Linux, los detalles sobre qué son exactamente los módulos de kernel podrías no tenerlos muy claros. El objetivo de este artículo no ▶
November 1, 2019By Dennis PaulODROID-XU4, Mecaniqueo, Tutoriales
sed -i '/&cluster_a15_opp_table {/a
sed -i '/&cluster_a7_opp_table {/a
sed -i '/PLL_35XX_RATE(2000000000, 250, 3, 0),/i
sed -i '/{ 2000000, E5420_EGL_DIV0(3, 7, 7, 4), },/i
sed -i '/{ 1500000, E5420_KFC_DIV(3, 5, 3), },/i
November 8, 2019By @johannesbehrODROID-GO, Tutoriales
November 9, 2019By Brian ReeMecaniqueo, Tutoriales
November 1, 2019By @paspartoutODROID-GO, Tutoriales
La utilidad ogo-shell es un explorador de archivos, reproductor de audio y visor de imágenes para ODROID-GO. Principalmente lo uso para escuchar música usando los auriculares odroig-go de backofficeshow. Puede consultar el Proyecto Github y la publicación del foro si quieres probarlo. La siguiente es la historia de su desarrollo hasta el momento. ¡Espero que te guste!
Desde que recibí mi ODROID-GO el año pasado, me he divertido bastante desarrollando pequeños programas para él. Me gusta el desafío de escribir programas para dispositivos integrados con recursos limitados. Te obliga a entender mejor la pila de hardware y de software en relación a programación de alto nivel a la que estoy acostumbrado trabajar.
Un día leí un post en el foro de Cralex sobre [Solicitudes de funciones/aplicaciones] [publicación en el foro] que mencionaba un administrador de archivos integrado en el dispositivo y algunos enlaces al Proyecto 3DShell. El archivo README del proyecto describe el propósito de 3DShell de la siguiente forma:
3DShell (pronunciado 3D-Shell): es un administrador de archivos multifuncional para Nintendo 3DS que tiene como objetivo la gestión de archivos multimedia.
Y así nació la idea de ogo-shell. Debía ser un explorador o administrador de archivos que pudiera ampliarse con más y más funcionalidades, como por ejemplo poder reproducir diferentes archivos multimedia.
Desarrollo hasta ahora
Puesto que probar pequeños cambios en los programas sobre el ODROID-GO lleva su tiempo, decidí implementar las funciones relacionadas con el hardware usando nuevamente la librería SDL2. (SDL2 es una conocida librería C utilizada principalmente en juegos y proporciona acceso multiplataforma a gráficos, audio y hardware de entrada). Ésta hace posible ejecutar ogo-shell localmente en mi ordenador para que pueda testear y depurar rápidamente la lógica de las aplicaciones con facilidad.
Figura 1 - Captura de pantalla de ogo-shell ejecutándose en Linux
Después de implementar la simulación, empecé a trabajar en el administrador de archivos. Ya había creado un servidor ftp para GO, así que estaba familiarizado con las API del sistema de archivos. El administrador de archivos Rover para terminales me sirvió de inspiración, cuenta con un código C muy limpio cuya lectura es muy agradable. Llegado a este punto, quiero agradecer a todas las personas que publican su trabajo como código abierto. Sin sus esfuerzos no sería posible desarrollar proyectos como este.
Una vez completada la exploración básica de archivos, quería ver si sería posible reproducir varios archivos de audio. Logar que únicamente se reprodujeran fue relativamente fácil, pero montar un reproductor de audio en toda regla, me suponía enfrentarme a algunos desafíos.
Figura 2 - ODROID-GO y reproductor de música
Uno de ellos es la concurrencia. El reproductor no solo tiene que reproducir música, leer su música codificada desde la tarjeta SD, sino que también debe reaccionar a tus entradas mientras lo hace. Implementar esto en C tanto para la simulación como para ODROID-GO no fue tarea fácil, pero me hizo aprender más sobre los mutexes, colas y cómo funcionan.
Otro obstáculo lo tenía en el hardware ODROID-GO. El ESP32 en ODROID-GO usa la misma conexión SPI para comunicarse con la pantalla y la tarjeta SD. Esto significa que no puedes actualizar la pantalla y leer desde la tarjeta SD al mismo tiempo. Al parchear el SDK subyacente usando un mutex, me aseguré de que el programa no pueda acceder a la tarjeta SD hasta que la pantalla termine de actualizarse.
El resto fue aglutinar librerías de código abierto que se encargan de la decodificación de audio y de montar la interfaz de usuario correcta. El reproductor admite los formatos de audio habituales MP3, OGG, FLAC y WAV. Además de estos, también admite módulos en los formatos MOD, XM, IT y S3M. Existe un escenario bastante grande para los módulos de música y se pueden encontrar muchas pistas en The Mod Archive.
La segunda versión después de la versión pública (0.3.0) incluye un visor de imágenes en bruto. Sin embargo, solo puede mostrar pequeñas imágenes debido a la limitada cantidad de RAM que tiene ODROID-GO. Déjame explicarte por qué.
Figura 3: captura de pantalla del visor de imágenes
Si quieres mostrar una imagen grande, digamos una con las dimensiones 1000x1000 píxeles, lo normal es decodificar primero el archivo de imagen en la memoria y luego cambiar su tamaño desde allí a otra parte de la memoria. Puedes calcular la cantidad de espacio necesario multiplicando la cantidad de píxeles por la profundidad de color de la imagen. La mayoría de las imágenes utilizan una profundidad de color de 24 bits en el formato RGB. Eso significa que tenemos tres canales de color para los colores rojo, verde y azul y cada canal se guarda como un número entero de 8 bits. Para guardar nuestra imagen de 1000x1000, necesitamos 24 bits o 3 bytes multiplicados por un millón (1000 veces 1000) que ya son 3 millones de bytes. La cantidad de RAM a la que puedes acceder fácilmente en ODROID-GO es de 4 MB, de modo que cualquier cosa que sea mayor que 1000x1000 no cogerá en la memoria. Puesto que el modus operandi habitual no funciona, tendría que encontrar una forma más inteligente de decodificar partes de la imagen y cambiar su tamaño directamente sobre la marcha sin la necesidad de recurrir a un gran búfer de imagen en la RAM. Esta optimización puede requerir mucho tiempo y esfuerzo que aún no he querido dedicar a este proyecto.
Me he dado cuenta que conseguir un primer prototipo de una característica funcional suele ser bastante fácil y divertido. Pero pulir el software corrigiendo errores, teniendo en cuenta casos extremos y agregar características de calidad que damos por sentado, generalmente requiere mucho más tiempo y esfuerzo, y no resulta tan divertido. Esta es probablemente la razón por la que hay tantos errores en el software actual. Cuanto más complejo es el software, más tiempo y esfuerzo tendrás que invertir para que funcione correctamente.
Actualmente estoy trabajando en el soporte para chiptunes usando la librería game-music-emu que puede emular chips de sonido de viejas consolas de juegos y ordenadores. Me gusta mucho el sonido y la creatividad que tienen estas viejas canciones. Lo que también está en proceso de desarrollo es la capacidad de lanzar los emuladores go-play desde ogo-shell. Resumiendo, todavía hay muchas ideas y características que implementar y errores que corregir.
Dicho esto, ha sido bastante divertido desarrollar ogo-shell y aprender cosas nuevas mientras lo hacía. La satisfacción que obtienes cuando ves o escuchas por primera vez que tu creación funciona según lo previsto puede ser realmente adictivo. Espero haberte animado a que no solo uses programas, sino que también aprendas a crear otros nuevos, y espero que ogo-shell te sea útil.
November 1, 2019By Adrian PopaLinux, ODROID-C2, ODROID-XU4
Hace unos dos años tuve una idea algo descabellada: ¿Sería posible crear un sistema de escritorio de "doble pantalla" utilizando dos ODROID, cada uno con una pantalla diferente, pero que actuasen como un escritorio unificado? La idea era tener un odroid "maestro" que fuera más potente en el que ejecutaríamos las aplicaciones (como un XU4 o N2) y un "esclavo", preferentemente más barato, que actuase únicamente como un terminal básico sin procesamiento (un C1/C2). Investigué un poco y encontré xdmx, que es un administrador de ventanas distribuido que podría funcionar, pero resultaba que había sido abandonado hace una década, de modo que no nos era factible.
Continúe investigando y creé un sistema algo enrevesado que básicamente hacia uso de Xpra (https://xpra.org) de un modo para el cual no estaba diseñado. Funciona, pero el rendimiento era pésimo: alrededor de 0.5 fps en todo el escritorio, lo cual era muy perceptible (tienes más detalles en: https://forum.odroid.com/viewtopic.php?t=35710). Después tuve la idea de experimentar con vnc, y esta vez los resultados fueron bastante mejores.
La idea es aparentemente muy simple. En el sistema maestro, inicias una sesión X11 normal, con lightdm incluido. Usas xrandr para extender el escritorio (una vez que hayas iniciado sesión) para que el nuevo tamaño del escritorio cubra ambas pantallas (yo utilicé pantallas idénticas, aunque debería funcionar con pantallas de diferentes resoluciones haciendo algunos ajustes). Luego, inicias una sesión X11vnc que se conecte a :0 y que tenga una resolución fija que es la suma de ambas pantallas.
El esclavo puede ejecutar una imagen mínima o de escritorio, pero necesita tener Xorg y debe soportar la resolución del monitor de destino. Éste Iniciará una sesión Xorg independiente que lee los comandos de inicio desde /root/.xinitrc. El archivo apunta a un script que intentará iniciar vncviewer en una especie de bucle infinito, conectándose a la sesión del maestro. Si todo va bien, terminaras con dos pantallas replicadas, que no es lo mismo que una configuración de doble pantalla. Aquí es donde entra en juego la magia. Una vez que se inicia vncviewer, éste se mueve con la ayuda de xdotool hacía la izquierda por el ancho de la pantalla. Esto hace que lo que normalmente sería la parte izquierda del escritorio se represente fuera de la pantalla (y se superponga lógicamente con lo que hay en la pantalla izquierda), dejando espacio para el contenido de la pantalla derecha. ¿Confuso? Aquí tienes un diagrama:
Figura 01: las partes atenuadas en gris no son visibles físicamente en las respectivas pantallas
Recuerda que el sistema maestro muestra ambas pantallas, pero solo la parte izquierda es físicamente visible, y el sistema esclavo también muestra ambas pantallas (a través de VNC), pero solo la parte derecha es físicamente visible. El resultado final es la ilusión de una configuración de doble pantalla.
Mi banco de pruebas consiste en un ODROID-XU4 con Ubuntu 18.04 Mate como sistema maestro y un ODROID-N2 con Ubuntu 18.04 Mate como esclavo. Como he dicho anteriormente, el esclavo puede ser una placa menos potente (incluso de otra marcha), pero yo tenía un N2 a mano para experimentar. El maestro maneja el monitor izquierdo en la configuración mientras el esclavo está conectado al monitor derecho (este orden es importante). En mi caso, ambos monitores tienen una resolución de 1680x1050. Deberías poder llegar a 1080p por pantalla, pero no estoy seguro de si puedes tener dos pantallas 4K porque el escritorio parece estar limitado a 4096x4096 píxeles (aunque puede haber una forma de saltarse esta limitación: https://bit.ly/2JsDWMc).
El sonido debe estar conectado al maestro, pero el teclado y el ratón pueden conectarse a cualquiera de los sistemas una vez que se inicie VNC. Ten en cuenta que conectar el teclado y el ratón al esclavo puede provocar movimientos bruscos o ralentizaciones cuando haya mucha actividad en la pantalla, así que, para un mejor rendimiento, conéctalos también al maestro.
Con respecto a las redes, ambos sistemas deben estar en la misma LAN, conectados a través de Ethernet y con direcciones IP estáticas. El máximo consumo de la red que llegue a observar fue de aproximadamente unos 40 Mbps de tráfico VNC cuando reproducía video, de modo que la conexión Ethernet no debería provocar cuellos de botella.
Comencemos con la configuración del odroid maestro:
Crearemos una contraseña aleatoria de 20 caracteres para VNC (aunque la documentación dice que solo se utilizan los primeros 8 caracteres), y la copiaremos a través de ssh en el sistema esclavo. Supongo que tu esclavo tiene una cuenta sin privilegios, como es odroid.
A continuación, creamos un servicio systemd para iniciar x11vnc en el arranque. Puedes utilizar y retocar la configuración de ejemplo que hay mi página git (https://github.com/mad-ady/vnc-multiscreen.git). Tendrás que cambiar la resolución combinada para que coincida con la de tu sistema (en mi caso era 3360x1050):
# cp vnc-multiscreen/master-left/etc/systemd/system/x11vnc.service
Figura 02 - El servicio X11vnc, personalizado con la resolución de pantalla compuesta
A continuación, debemos añadir un script que se ejecute una vez que inicies sesión (nuevamente, supongo que estás utilizando el usuario odroid para el inicio de sesión de la GUI) y que use xrandr para cambiar el tamaño de tu escritorio. Podríamos haber ejecutado el script desde lightdm (antes de iniciar sesión), pero por alguna razón el fondo del escritorio abarca una única pantalla. Ejecuta los siguientes comandos con el usuario con el que inicias sesión (en el maestro):
Figura 03 – El script set-dual-screen-resolution (en el maestro) que extiende el escritorio
Deberás editar el script /usr/local/bin/set-dual-screen-resolution.sh y fijar tu resolución total en el parámetro fb (que será el tamaño del escritorio) y ajustar la resolución de tu pantalla izquierda en el parámetro panning. Si lo configuras así, el escritorio no empezará a desplazarse cuando muevas el ratón hacia borde de la pantalla.
Eso es todo sobre la configuración básica en el sistema maestro, y ahora le toca el turno al esclavo. Desactivaremos el modo GUI y crearemos y habilitaremos un servicio xorg que inicie un simple servidor X11 y un script para conectarse a vnc:
El servidor X analiza .xinitrc y lo ejecuta después del inicio. Así que haremos que inicie nuestro script de inicio VNC.
Figura 04 - El servicio de inicio Xorg y el script
El script de inicio VNC iniciará el proceso vncviewer (en un bucle) y luego moverá la ventana a la izquierda. Todo se realiza con ayuda de estos dos scripts:
Figura 05 - El script dual-screen-vnc-client
Figura 06 - El script window-positioning
Si no estás utilizando pantallas idénticas, deberás editar los dos scripts anteriores y fijar los desfases correctos de tus pantallas.
Ya tenemos hechos los pasos básicos. Puedes reiniciar ambos sistemas y después de iniciar sesión en lightdm deberías tener un escritorio extendido. Sin embargo, hay algunas cosas que no funcionarán como cabría esperar, necesitamos hacer algunos ajustes.
Figura 07 - Cómo debería verse tu escritorio
Retoques (solo en el sistema maestro)
Debes deshabilitar el mosaico del sistema de ventanas MATE (y la composición mientras estés en él), porque cuando intentes maximizar una ventana en la pantalla derecha arrastrando su barra de título hacia la parte superior, la ventana saltará a la pantalla izquierda. Puede hacerlo desde Menu -> Control Center -> Windows -> Placement -> Disable window tiling.
A continuación, debe deshabilitar el contenido de la ventana mientras la mueves, para conseguir así una experiencia más fluida: Menu -> Control Center -> Mate Tweaks -> Windows -> Do not show window content while moving windows.
Como tienes dos pantallas, sería bueno que las ventanas sepan dónde está la división entre las pantallas y permita maximizar las ventanas en cada pantalla. Para esto, necesitas adaptar lo que la librería xinerama le dice a tu servidor X sobre las pantallas disponibles. Afortunadamente, existen una librería "fakexinerama" que puedes instalar en el sistema maestro (https://www.xpra.org/trac/wiki/FakeXinerama).
Si tienes una arquitectura diferente en el maestro (arm64, x86_64), modifica la ruta del archivo de la librería. Puedes encontrar esto en:
Fake Xinerama lee la configuración de la pantalla desde el directorio de inicio del usuario de la GUI ~/.fakexinerama. El archivo empieza con el recuento de monitores (que es 2 en nuestro caso) y enumera cada monitor por línea con ajustes y resolución:
Una vez que reinicies tu sesión de escritorio, las ventanas deberían comportarse como si tuvieras dos pantallas físicas pudiendo maximizarlas en cada pantalla.
Nos falta una integración más: el protector de pantalla solo se activa en la pantalla del sistema maestro. Probablemente solo tenga en cuenta el tamaño de la pantalla, no el tamaño total del escritorio, de modo que queda visible la pantalla derecha. Puede usar gdbus para ver cuándo se activa el protector de pantalla y puedes conectarte por ssh al esclavo y apagar la pantalla con xset dpms force off. Cuando observes que el protector de pantalla se desactiva, puedes volver a habilitar la pantalla derecha.
Para hacer esto, primero debes ser capaz de pasar del maestro al esclavo sin una contraseña. Para ello crearemos una clave y copiaremos la parte pública al esclavo. Omite el primer paso si ya tiene creadas las claves.
A continuación, copia el script que vigila el estado del protector de pantalla e inícialo como parte de la sesión de escritorio del usuario. Afortunadamente, systemd también puede manejar servicios de usuario (nuevamente, en el maestro):
Asegúrese de editar (y probar) el script de sincronización del protector de pantalla, de modo que apunte a la dirección IP correcta del sistema esclavo.
El maestro (izquierda) hace todo el trabajo pesado, además tiene el rendimiento más fluido.
El esclavo (derecha) se usa para renderizar media pantalla, pero necesita transferir y renderizar la pantalla combinada (incluso si solo ve la mitad), de modo que una actividad intensa en la pantalla izquierda provocará saltos/retrasos en la pantalla derecha
Debes encender y apagar ambos dispositivos de forma independiente. Es posible apagar automáticamente el esclavo y luego apagar el maestro, pero es necesario realizar algunos ajustes (por ejemplo, un servicio systemd que se conecte al esclavo para apagarlo).
Puedes convertir fácilmente al esclavo en un sistema autónomo deshabilitando el servicio xorg y volviendo a habilitar el sistema gráfico. El maestro puede permanecer como está sin afectar a su funcionalidad.
El rendimiento es nativo en la pantalla maestra/izquierda y varía de un par de FPS a ~ 15 FPS en la pantalla esclava/derecha, dependiendo de la actividad de la pantalla. La pantalla derecha es la más adecuada para trabajar con contenido estático, como una página web, un código o un terminal.
Puede ver una demostración aquí (mil disculpas por la mala calidad del video): https://www.youtube.com/watch?v=sSqXX5doCvo&feature=youtu.be
Perfectamente, todo esto se simplificaría enormemente si solo X11VNC (o quizás con una tecnología de escritorio remoto diferente) pudiera copiar únicamente la mitad de una pantalla de datos en lugar del escritorio completo. De esta manera, se reduciría la carga de trabajo tanto en maestro como en esclavo evitando tener que recurrir a trucos para el movimiento de las ventanas. Puedes mostrar la segunda pantalla en cualquier sistema (por ejemplo, dentro de un navegador en un televisor) sin muchos problemas.
Puede lograr mejor rendimiento si el maestro es un PC (por ejemplo, un ODROID H2) y el esclavo es un ODROID ARM/ARM64. Esto se debe a que la velocidad de lectura de framebuffer en un XU4 es de aproximadamente 45 MB/s (N2 es de unos 443 MB/s), mientras que la GPU Intel alcanza aproximadamente unos 961 MB/s. Más velocidad conlleva una velocidad de actualización más rápida, pero requerirá más ancho de banda de red.
Una cosa más: la técnica anterior se puede ampliar a más de 2 monitores porque puede conectar dos clientes VNC al mismo servidor. Sin embargo, el rendimiento disminuirá considerablemente. Avísame si encuentras alguna forma de mejorar todo esto en el hilo de soporte en https://forum.odroid.com/viewtopic.php?f=52&t=36411.
November 1, 2019By Brian ReeJuegos, ODROID-XU4
November 1, 2019By Tobias SchaafAndroid, Juegos, ODROID-H2
November 1, 2019By Dave ProchnowJuegos
Si eres como yo, te estarás rascando la cabeza en este momento por la reciente presentación de Play Pass de Google. Play Pass es un servicio de suscripción mensual que te permite descargar y jugar una amplia biblioteca de juegos y otras aplicaciones de productividad que están actualmente disponibles en Play Store de Google. Este anuncio no podría llegar en un momento más inoportuno. Estamos a solo dos meses del lanzamiento oficial del servicio de streaming de videojuegos a gran escala de Google, Stadia. Entonces, ¿qué nos brinda este servicio? ¿Por qué Google trata de cubrir preventivamente el período previo al estreno de Stadia al lanzar un servicio indudablemente inferior?
Un responsable del proyecto en Google dijo lo siguiente sobre Play Pass: "Los juegos son súper importantes ... [Play Pass] no está pensado para atraer a los jugadores más entusiastas". De acuerdo, Play Pass está dirigido a aquellos usuarios de Android que podrían no decantarse por el ecosistema Stadia. Es lo adecuado. Desafortunadamente, Play Pass todavía tiene varios fallos que te harán rascarte la cabeza.
Figura 1: Google Play Pass podría estar orientado al jugador "ocasional" - Imagen cortesía de Google Play Pass
Alimentado con más de 350 juegos y aplicaciones que actualmente están disponibles en Google Play Store, Play Pass costará 4.99$ al mes con un acceso completo, ilimitado y sin publicidad a toda la biblioteca. ¿Qué pasa si ya has comprado y has jugado a "Monument Valley", por ejemplo. ¿Qué ventajas te aporta Play Pass? Tal vez muy pocas o tal vez la oportunidad de poder jugar a juegos que nunca comprarías.
Los suscriptores deben tener cuidado, los desarrolladores de juegos usan un proceso de aplicación "opcional" que permite que un juego o aplicación sea incluido en la biblioteca Play Pass. El responsable de proyecto de Google no mencionó nada sobre qué sucederá con los juegos de Play Pass cuando un desarrollador abandone este servicio de suscripción. Además, tampoco dio detalles sobre los términos de los contratos asociados a los pagos que reciben los desarrolladores por las suscripciones a los juegos.
En el momento de su lanzamiento, Google ofrece una ingeniosa promoción de 1.99$ al mes durante el primer año de suscripción a Play Pass. Del mismo modo, hay un período de prueba gratuito de 10 días. Finalmente, Google permitirá que hasta cinco miembros de la familia compartan una única suscripción. Independientemente de cómo se desarrolle Play Pass, el peor enemigo de los juegos de Android podría ser el propio Google.
Era solo cuestión de tiempo que Google Play Store incluyese un tema oscuro. Tras el lanzamiento de Android 10 el mes pasado, las aplicaciones de Google han habilitado lenta, pero de forma progresiva un tema de modo oscuro. Al igual que la aplicación Google y Gmail, Play Store ahora tiene un tema oscuro. Supuestamente, este tema oscuro se activa con la versión 16.7.21 de Play Store. De modo que, si todavía no te has pasado al lado oscuro, busca la actualización actual de Play Store o si eres un usuario de Android 10, el cambio podría estar en un tema automático que ya está activado en la nueva configuración del sistema operativo.
Finalmente, ya está aquí: el Mario Kart Tour de Nintendo. Este título tardío ya lo tenemos disponible como descarga gratuita. Jugarlo gratis, sin embargo, podría ser una cuestión diferente. Ten en cuenta que necesitarás una cuenta de Nintendo antes de poder jugar a este juego. Peor es aún, si deseas tener acceso completo a todas las carreras, trazados y karts del juego, tendrá que pagar una suscripción mensual de 4.99$. Nintendo llama a esta suscripción el "Gold Pass". Oro para Nintendo y NO para ti.
Figura 2: ¿Podría ser Mario Kart Tour el título de Mario que obligaría a los jugadores de Android a cambiar? Imagen cortesía de Nintendo
Al carecer de compatibilidad con mandos, Mario Kart Tour ofrece un rendimiento de juego bastante mediocre. Más aun por el hecho de que la interfaz de juego es únicamente vertical. Afortunadamente, los gráficos del juego son de primera categoría. De modo que, aunque conducir resulte casi imposible, seguro que se ve genial mientras estás inmerso en la carrera. Tienes más información sobre Mario Kart Tour en el video https://www.youtube.com/watch?v=V-_s4oWV1cU.
November 1, 2019By Andrew RuggeriLinux
Si has detenido en los Foros de Hardkernel el tiempo suficiente, la expresión "módulo kernel" debería serte bastante familiar. Sin embargo, si eres nuevo en el mundo de Linux, los detalles sobre qué son exactamente los módulos de kernel podrías no tenerlos muy claros. El objetivo de este artículo no es solo que sepas que es exactamente un Módulo Kernel, sino también conocer cómo interactuar y compilar el tuyo propio.
¿Qué es un módulo kernel?
El kernel de Linux es monolítico o poco flexible, lo que significa que todo lo que necesita el sistema operativo forma parte del espacio del kernel. Esto tiene la ventaja de ser más rápido que otros diseños de kernel como un micro-kernel, pero se paga el precio de carecer de modulación y flexibilidad. Los módulos kernel están diseñados para ayudar a solucionar este problema de modulación. Para añadir funcionalidades al kernel, como un nuevo controlador o formato de sistema de archivos, el código con esa nueva funcionalidad en particular se compila en un módulo kernel y luego se carga en el kernel de Linux.
Para el código de ejemplo y el resto del artículo, usare el nombre de archivo "examplemod.c"
MODULE_DESCRIPTION("Example kernel module");
MODULE_AUTHOR("ODROID");
printk(KERN_ALERT "Hello World!
printk(KERN_ALERT "Goodbye World
El código incluye un simple "hello world", ya que el objetivo de este artículo está centrado con la definición y la funcionalidad de los módulos kernel. Este ejemplo utiliza las funciones de registro del kernel para mostrar un simple saludo después de la inicialización y un adiós cuando es retirado el kernel. El código tiene dos partes que destacan y a las que hago referencia a continuación.
Estas macros ayudan a completar la información sobre el módulo, existen tipos de campos adicionales que se pueden usar como "MODULE_VERSION", "MODULE_LICENSE", etc. Más adelante veremos comandos sobre cómo ver esta información para cualquier módulo dado.
Las funciones module_init y module_exit registran las funciones simple_init y simple_cleanup que se han definido anteriormente. Estas llamadas registran qué funciones creadas por el usuario serán llamadas en la inicialización y en la salida del código. printk (), aunque a primera vista puede parecer similar o intercambiable con printf (), debemos pensar en ella de manera diferente. Como hemos mencionado anteriormente, printk es un mecanismo para el registro de mensajes del kernel y no para interactuar directamente o mostrar información al usuario. El nivel de registro, que varía de 0 a 7 (7 menos importante) se coloca antes de la cadena sin un comando, ya que forman un único parámetro que pasa a printk ().
Después de escribir el módulo, hay un par de notas a tener en cuenta antes de simplemente llamar "gcc". Los módulos kernel son bastante delicados a la hora de compilarse, se deben cumplir las siguientes reglas:
No se pueden incluir cabeceras que no sean del kernel
El módulo no debe estar vinculado a ninguna librería
Los flags del compilador utilizados para el módulo deben coincidir con los utilizados para el kernel.
Para simplificar las cosas, podemos usar el siguiente archivo MAKE:
obj-m += examplemod.o
El archivo MAKE es bastante sencillo, la parte más importante es la siguiente línea:
La ruta apunta a una ubicación donde están ubicados los Makefiles y las cabeceras del kernel. El Makefile simplemente llama al que se encuentra en esta ubicación para proporcionar la funcionalidad de cara a la compilación y también a la limpieza. Después de ejecutar el Makefile, deberíamos quedarnos con un archivo llamado examplemod.ko, este es nuestro módulo kernel compilado.
Ahora que hemos creado nuestro Módulo Kernel, es hora de cargarlo en el kernel Linux. El siguiente comando es el que se usa para cargar un archivo * .ko. Cuando se carga el módulo, se llamará a la función fijada por module_init.
$ sudo insmod ./examplemod.ko
Si eliminamos un Módulo Kernel que ha sido cargado, llamará a la función fijada por module_exit. Para eliminar nuestro Módulo Kernel o cualquier Módulo que haya sido cargado, podemos usar el siguiente comando.
$ sudo rmmod examplemod
Aunque no es un comando específico del Módulo Kernel, el siguiente comando nos permite ver lo que ha sido registrado por el kernel. Si hemos ejecutado los dos comandos anteriores, deberíamos ver las dos declaraciones printk () cerca de la parte inferior (más reciente) del registro log.
O para ver solo las últimas 2 líneas que se imprimieron..
Figura 1: Cargando y eliminando el módulo kernel, luego imprimiendo el registro del kernel
Esto mostrará todos los módulos kernel cargados actualmente. Sin embargo, esta información es bastante limitada. Si queremos profundizar podemos usar el nombre de un módulo de la lista con el siguiente comando.
Figura 2: Impresión de lsmod que muestra el ejemplomod cargado
Esto mostrará una vista más detallada del módulo. Si miramos la información del módulo de ejemplo que hemos creado, veremos la información que fijamos al comienzo del código de nuestro módulo.
$ modinfo examplemod
Figura 3: Impresión modinfo de la información para nuestro módulo kernel
Estos son solo los conceptos básicos para comprender qué es un Módulo Kernel y cómo crearlos e interactuar con ellos. En futuros artículos analizaremos los usos y aplicaciones más complejos de los Módulos de Kernel y cómo llegar a cierto nivel de interacción con ellos para que proporcionen una funcionalidad significativa.
November 1, 2019By @tony.hongODROID-N2, Mecaniqueo
Necesitaba el puerto UART de mi ODROID-N2 para trabajar con una tasa de baudios no estándar y así poder usar MIDI. Edité el código del driver UART para fijar la velocidad de baudios en 31250 cuando configuré la tasa de baudios en 38400, luego escribí el código de prueba usando wiringPi y medí la tasa de baudios.
Driver UART después de editarlo
trace_printk("Your baudrate: %ld
", baud);
trace_printk("Change to %ld
Ref. de compilación del kernel de Linux: https://wiki.odroid.com/odroid-n2/softw ... ing_kernel
Cambios de la sección de instalación
Codigó de Prueba
Figura 1 - Antes de editar: cuando se transmite 10101010, 1s/ancho de onda es la tasa de baudios, y 1s/26.088us es 38331 ~ = 38400
Figura 2 - Después de editar - 1s/32.002us es 31248 ~ = 31250
Depuración con ftrace
0) | uart_set_termios() {
0) | uart_change_speed.isra.2() {
0) | meson_uart_set_termios() {
0) 0.875 us | uart_get_baud_rate();
0) | /* Your baudrate: 38400 */
0) | /* Change to 31250 */
0) 0.250 us | uart_update_timeout();
Si tienes pensado realizar una compilación cruzada, la secuencia es la siguiente:
Instalar paquetes requeridos
Para comentarios, preguntas y sugerencias, visita el post original de los foros ODROID en https://forum.odroid.com/viewtopic.php?f=180&t=36540.
November 1, 2019By @Synportack24Juegos, Linux, ODROID-H2
El número del mes pasado de ODROID Magazine incluía el artículo "Lakka: Desarrollando la mejor consola de juegos ODROID-XU4 / XU4Q", disponible en https://magazine.odroid.com/article/lakka-building-the-ultimate-odroid-xu4-xu4q-gaming-console/. Este artículo estaba centrado en los juegos con un ODROID-XU4, sin embargo, existe un ODROID potencialmente más potente, el H2. Mientras que el ODROID-XU4 hace un trabajo increíble con los juegos retro, intentando ejecutar sistemas como Playstation o Dreamcast empieza a superar sus límites. Aquí es donde quería llegar, ¿Puede el ODROID-H2 seguir donde lo dejo ODROID-XU4?
Para ello, instalé una versión de 64 bits de Ubuntu Mate 19.04 en mi H2 y luego procedí a compilar e instalar Retroarch para la emulación (libretro.com). Mi H2 esta montado con 8 GB de RAM y un SSD Intel 660P, así que otras configuraciones con más o menos memoria o sin emmc pueden tener resultados diferentes.
Hay MUCHOS y diferentes programas y distribuciones completas de sistema operativo (como Lakka) centradas en la emulación. Elegí Retroarch para mis pruebas porque está bien documentado y se usa en muchos otros programas de emulación a modo de backend. La instalación es muy simple en ubuntu y la correspondiente documentación la puedes encontrar en: https://docs.libretro.com/development/retroarch/compilation/ubuntu/
El primer paso es agregar el ppa de libretro
# add-apt-repository ppa:libretro/testing
Después de esto, tiene la opción de instalar retroarch como paquete, lo que no garantiza la versión más reciente posible y la compilación de git es muy simple, de modo que me decante por esta opción.
# apt-get build-dep retroarch
Y tras completarse, puedes iniciar Retroarch con el siguiente comando
Una vez que inicies Retroarch, selecciona "Online Updater" desde allí, querrás ejecutar/seleccionar
A partir de ahí utilicé los siguientes emuladores
Sega - Dreamcast/NAOMI (Flycast) https://docs.libretro.com/library/flycast/
Sony - Playstation (Beetle PSX) https://docs.libretro.com/library/beetle_psx/
Sony - Playstation 2 (Play!) : this was downloaded but the results were unplayable
Me sorprendió mucho lo bien que Flycast manejaba cada juego que probaba. Mi selección de juegos estuba centrada en juegos que me permitiesen probar diferentes aspectos de la emulación y la jugabilidad. Seleccione Crazy Taxi 2 ya que es un juego pesado centrado en el 3D y debería forzar el H2. Del mismo modo, Marvel vs. Capcom 2, aunque no es 3D, es un juego bastante rápido donde se debería notar cualquier ralentización. Por último, elegí ChuChu Rocket, aunque es un juego menos conocido, nos permite probar más cuestiones sobre el emulador. No he notado ralentización, retraso o problemas gráficos peculiares. En el juego de Crazy Taxi 2 aparecían desgarros horizontales ocasionales que cubrían 2-3 fotogramas antes de desaparecer. Su campo de acción era bastante limitado y aparecía principalmente cuando la cámara se movía al entrar un pasajero en el taxi, ejecutando el juego en "tiempo de ejecución", esto no se llegaba a percibir.
Figura 1 - ChuChu Rocket
Figura 2 - Crazy Taxi 2
Figura 3 - Marvel vs Capcom
Figura 4 - Marvel vs Capcom
A diferencia de Dreamcast, existen un par de emuladores diferentes que se pueden usar para emular Playstation. Al leer la descripción de cada uno, resulta fácil encontrar la mejor elección, beetle psx. La documentación de libretro (docs.libretro.com/library/beetle_psx/) nos dice lo siguiente: “Este emulador está indicado para personas que ejecutan RetroPie en sistemas de CPU x86 más potentes. Es preciso, lo mejor que se puede pedir cuando hablamos de un núcleo PSX para RetroArch. lr-beetle-psx no está disponible para sistemas con CPU ARM (como la Raspberry Pi) debido a al bajo rendimiento de las CPU ARM".
Después de instalarlo y configurarlo todo para el emulador de Playstation, observé que era mucho más "selectivo" a la hora de cargar y ejecutar una rom. Varios de los emuladores que había configurado para probar daban errores de carga/ejecución cuando intentaba cargarlos. Con los juegos que probé (Crash Team Racing, Dino Crisis 2 y Resident Evil 2), no tuve problemas de jugabilidad. Todo iba sobre ruedas, sin ralentizaciones ni desgarros. A mitad de la secuencia de video de la introducción de Dino Crisis 2, éste se detuvo. Sin embargo, cuando empezó el juego en sí no hubo problemas.
Figura 5 - Crash Team Racing
Figura 6 - Dino Crisis 2 Opening Cutscene
Figura 8 - Dino Crisis 2 Gameplay
Figura 9 - Resident Evil 2
En general, me sorprendió bastante lo bien que ODROID-H2 manejó algunos de los sistemas de juego más modernos. Si eres un fanático de los juegos de retro y buscas actualizar a algo con un poco más de "potencia", definitivamente vale la pena echarle un vistazo al ODROID-H2, ya que podría ser un reproductor multimedia y un dispositivo de juegos retro casi perfecto.

References: resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución