
He habilitado correctamente el arranque seguro en un dispositivo integrado. El problema es que cuando inicio en este modo, el proceso parece quedarse atascado justo después de la línea:
Starting kernel ...
una vez que U-boot ha copiado el kernel en la memoria y ha emitido un bootm
comando.
En un depurador puedo capturar que la PC está atascada en una yield
instrucción seguida de una asignación a pc = pc-4
, es decir, esencialmente un bucle.
Nunca antes había mencionado Linux a un nivel tan bajo, así que no estoy seguro de por dónde empezar a buscar. Sin embargo, noté que pude iniciar exitosamente la imagen del kernel cuando no estaba en modo seguro, por lo que esta podría ser una pregunta más apropiada para el proveedor.
1) En general, ¿dónde puedo encontrar información de diagnóstico de U-boot con respecto a la etapa de transferencia de ejecución?
2) ¿En qué punto la ejecución se entrega completamente al kernel? es decir, ¿cuándo dejará de existir U-boot?
Respuesta1
Quizás pueda volcar la memoria de las primeras impresiones de Linux utilizando el siguiente procedimiento. La causa puede ser que el kernel se está iniciando pero se colgó antes de que se iniciara la consola. También coloque impresiones en el punto de entrada del kernel de uboot y confirme que el control se haya entregado al kernel.
Encuentra el System.map
archivo. Utilice el siguiente comando para identificar la log_buf
dirección:
grep __log_buf System.map
Esto generará algo como
c0352d88 B __log_buf
Arranque la placa en caliente (el contenido de la RAM no debe borrarse).
En Uboot volcamos la memoria de __log_buf
(c0352d88). Volcará las impresiones de la consola Kernel. Para que pueda identificar dónde ocurre exactamente el colgado.
Respuesta2
Me he enfrentado al mismo problema y he encontrado una solución. El problema está en uno de los u-boot structure field
que almacena el size
campo. uncompressed linux kernel.
No u-boot
está completando este campo con el tamaño sin comprimir, que linux kernel
luego usa para cambiar su tamaño stack
, poniendo así el sistema en un estado indefinido.
Una vez que u-boot
se imprime el Starting kernel...
mensaje, el siguiente mensaje debería ser Uncompressing Linux... done, booting the kernel
después de que u-boot transfiera un SMM Handler
para que el kernel se haga cargo de la ejecución, y tal vez kernel
esté buscando este campo. Si está trabajando en un x86
sistema basado, la descompresión se realizaría en los siguientes directorios de archivos:
arch/x86/boot/uncompressed/head_32.S
arch/x86/boot/uncompressed/piggy.S
La solución es utilizar la última fuente de u-boot aquí:https://github.com/andy-shev/u-boot
Sin embargo, si está utilizando un u-boot personalizado, debe buscar este campo.
Respuesta3
x86? Arranque con earlycon=efifb
o earlyprintk=vga
. Menciono ambos ya que hubo un cambio en el momento de la confirmación 69c1f396f25b805aeff08f06d2e992c315ee5b1e de earlyprintk a earlycon.