El kernel de Linux se bloquea en "Iniciando kernel ..."

El kernel de Linux se bloquea en "Iniciando kernel ..."

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 bootmcomando.

En un depurador puedo capturar que la PC está atascada en una yieldinstrucció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.maparchivo. Utilice el siguiente comando para identificar la log_bufdirecció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 fieldque almacena el sizecampo. uncompressed linux kernel.No u-bootestá completando este campo con el tamaño sin comprimir, que linux kernelluego usa para cambiar su tamaño stack, poniendo así el sistema en un estado indefinido.

Una vez que u-bootse imprime el Starting kernel...mensaje, el siguiente mensaje debería ser Uncompressing Linux... done, booting the kerneldespués de que u-boot transfiera un SMM Handlerpara que el kernel se haga cargo de la ejecución, y tal vez kernelesté buscando este campo. Si está trabajando en un x86sistema 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=efifbo earlyprintk=vga. Menciono ambos ya que hubo un cambio en el momento de la confirmación 69c1f396f25b805aeff08f06d2e992c315ee5b1e de earlyprintk a earlycon.

información relacionada