Cómo comprobar el tipo de sistema operativo de placa única Linux
En primer lugar, al cargar el kernel generado por el arranque, ¡no se mostrará nada! Es decir, después de que u-boot imprime la siguiente información: Iniciando kernel..., no aparece ningún resultado en la pantalla.
Aquí debemos presentar brevemente la salida de la placa Beaglebone Black. Tiene un micro HDMI que se convierte para conectarse a la tarjeta de visualización gráfica (que puede controlar la pantalla LCD directamente) en el SOC AM3358 utilizado. Obviamente, esta salida no es adecuada para su uso durante el desarrollo, ya que depende de controladores más complejos. Los SBC suelen tener una interfaz JTAG que se puede utilizar para mostrar la salida y depurar el funcionamiento del SBC. Este enfoque está más orientado al hardware y también puede ser el preferido por los ingenieros de hardware. Para mí, usar un puerto serie para entrada y salida es una forma más apropiada. El circuito del puerto serie y el controlador son relativamente simples y adecuados para el desarrollo inicial. AM3358 tiene 6 puertos serie (UART0 ~ UART5). El pin UART 0 negro del Beaglebone se puede extraer directamente, **** 6 en total. Dado que el SOC funciona con voltaje TTL (3,3 V), la interfaz no se convierte en la capa física eléctrica para que cumpla con el estándar RS232, por lo que no se puede conectar directamente al puerto serie de ningún dispositivo, como el puerto serie. de una PC. La buena noticia es que existen cables USB a serie en el mercado con una interfaz TTL de 3,3 V que le permiten conectar su puerto serie directamente al puerto USB de su PC.
En una PC con LINUX, utilizando el software del terminal minicom, puede monitorear e interactuar con el proceso de arranque de Beaglebone Black a través de un dispositivo USB a RS232.
El kernel comienza sin ningún resultado observable, lo cual es un problema complicado porque no hay información para juzgar. El primer paso en el arranque del kernel es descomprimir el kernel en una región que comienza en una dirección física fija, que en los SOC de TI suele ser 0x8000 8000, ya que los SOC de arquitectura ARM de TI suelen comenzar en 0x8000 0000. En versiones anteriores de arranque normal, la descompresión comenzaba y terminaba con el resultado "Descomprimiendo Linux... listo, arrancando el kernel". ¿Cómo sé adónde fue? ¿Por qué sale mal?
Bueno, en una placa de circuito, generalmente hay varios tubos de visualización LED que se iluminan escribiendo bits binarios en un área de memoria. Por lo tanto, antes de configurar el kernel y habilitar el mecanismo de dirección virtual, se puede encontrar la dirección física que controla un LED específico y escribir un 1 directamente en el bit de dirección correspondiente, iluminando así el LED específico. Una vez habilitado el mecanismo de dirección virtual, esto ya no es posible porque es imposible saber cuál es la dirección virtual que corresponde a la dirección física, o incluso determinar la correspondencia entre las direcciones. Sin embargo, al menos todavía es posible saber si el kernel ha pasado por una determinada parte del proceso de arranque antes de que se active el mecanismo de dirección virtual. Desafortunadamente, el uso de este método solo puede verificar que el kernel se haya ejecutado correctamente hasta el punto en que se inicia la habilitación de la memoria virtual. Si se configura el mecanismo de memoria virtual, saltará a la función "start_kernel" del kernel, que es un programa en C.
¡A partir de ahora, el kernel básicamente ejecuta código C!
¿Por qué se completa la descompresión sin "Descompresión Linux...completada, iniciar kernel"? Resulta que el kernel usa el árbol de descripción del dispositivo para crear el dispositivo, y el dispositivo en serie no se crea al principio (antes de leer y analizar el árbol de descripción del dispositivo). Si crea y usa estos dispositivos desde el principio, ¡volverá a la antigua forma de usar variables estáticas para almacenar dispositivos y controladores! Por lo tanto, un kernel que utiliza un blob de árbol de dispositivos para especificar un dispositivo no podrá generar información similar durante la fase de descompresión al comienzo del arranque.
Dado que el dispositivo se especifica a través del árbol de dispositivos, también puede consultar el archivo fuente del árbol de dispositivos para ver cómo se describe uart0. A juzgar por el archivo "am335x-boneblack.dts" y los archivos que contiene, uart0 requiere un controlador multiplexor de pines llamado "pinctl-single" para configurar los pines cuando está habilitado. En el archivo de configuración del kernel, hay una opción para seleccionar este controlador, ¡pero no la uso porque estoy buscando un kernel mínimo! Al reconfigurar las opciones del kernel para seleccionar este controlador, ¡el resultado del arranque del kernel resultó bien!
Por cierto, explique la multiplexación de pines: en términos generales, los chips SOC integran la CPU y muchos otros periféricos, como controladores serie, controladores USB, etc. El pin de salida del chip no puede generar completamente todas las conexiones periféricas, por lo que existe el fenómeno de que se conectan múltiples señales periféricas a un pin. Por ejemplo, la señal RX del puerto serie 0, la señal SDA de I2C 2 y otras 6 señales, ****, ¡use un pin! Si necesita configurar este pin como la señal RX del puerto serie 0, debe escribir 0 en la dirección de memoria (registro); si necesita configurar este pin como la señal SDA de I2C 2, debe escribir 3. El controlador más sencillo para gestionar esta multiplexación (configurando cuatro bytes por pin) se llama pinctl-single. Anteriormente, el kernel no podía generar información porque el controlador no estaba seleccionado en la configuración.
El kernel completa el inicio, finalmente carga el sistema de archivos raíz en la memoria e intenta ejecutar el programa de inicio en el directorio raíz. El contenido de este sistema de archivos raíz inicial son los comandos más simples y más utilizados. El enfoque más común es utilizar los resultados generados por klibc y Busybox como contenido de este sistema de archivos. Los sistemas de archivos de memoria (dispositivos de bloques que no son de memoria) y los sistemas de archivos raíz iniciales del kernel son invenciones de LINUX que aumentan la flexibilidad al tiempo que reducen la complejidad del kernel.
Se inició el kernel y se ejecutó SHELL (sh.shared) de klibc, ¡pero se descubrió que el kernel no podía reconocer la tarjeta MMC (o eMMC de 4 GB)! Según el resultado del proceso de arranque del kernel, descubrí que no podía cargar el controlador de energía para la MMC correspondiente. Al observar los archivos fuente del árbol de dispositivos, descubrí que el mmc del Beaglebone black utiliza el controlador de energía más simple: el regulador fijo, y este controlador falta en la configuración del kernel. ¡Esto es nuevamente culpa de la configuración mínima del kernel! Reconfigure y verifique el controlador y ahora todo se ve bien.
En este punto nació un pequeño sistema. Funciona en una pizarra Beaglebone con MMC, USB y tarjetas de red. Por supuesto, esta sigue siendo una configuración relativamente menor y es posible que deba agregar los controladores necesarios más adelante según sea necesario. El siguiente paso es comenzar a compilar los distintos programas que construyen el sistema. El primero es "systemd", el último y más popular sustituto del programa INIT de UNIX/Linux.