Ativei a inicialização segura em um dispositivo incorporado com sucesso. O problema é que quando estou inicializando neste modo o processo parece travar logo após a linha:
Starting kernel ...
uma vez que o U-boot copiou o kernel na memória e emitiu um bootmcomando.
Em um depurador, sou capaz de capturar que o PC está preso em uma yieldinstrução seguida por uma atribuição para pc = pc-4- essencialmente um loop.
Eu nunca mencionei o Linux neste nível tão baixo antes, então não tenho certeza por onde começar a procurar. Percebi, porém, que consegui inicializar com êxito a imagem do kernel quando não estava no modo seguro, portanto, essa pode ser uma pergunta mais apropriada para o fornecedor.
1) Em geral, onde posso encontrar informações de diagnóstico do U-boot referentes à etapa de transferência de execução?
2) Em que ponto a execução é totalmente entregue ao kernel? ou seja, quando o U-boot está extinto?
Responder1
Pode ser que você possa despejar a memória das primeiras impressões do Linux usando o procedimento a seguir. A causa pode ser que o kernel esteja inicializando, mas travou antes da inicialização do console. Coloque também impressões no ponto de entrada do kernel do uboot e confirme que o controle foi entregue ao kernel.
Encontre o System.maparquivo. Use o comando abaixo para identificar o log_bufendereço:
grep __log_buf System.map
Isso produzirá algo como
c0352d88 B __log_buf
Inicialize a placa a quente (o conteúdo da RAM não deve ser apagado).
No Uboot despeje a memória de __log_buf(c0352d88). Ele irá despejar as impressões do console do Kernel. Assim, você pode identificar onde ocorre o travamento exato.
Responder2
Eu enfrentei o mesmo problema e encontrei uma solução. O problema está em um dos u-boot structure fieldque armazena o sizedo uncompressed linux kernel.The u-bootnão está preenchendo este campo com o tamanho descompactado, que linux kernelutiliza posteriormente para redimensionar o seu stack, colocando assim o sistema em um estado indefinido.
Depois de u-bootimprimir a Starting kernel...mensagem, a próxima mensagem deve ser Uncompressing Linux... done, booting the kernelapós a transferência do u-boot SMM Handlerpara que o kernel assuma a execução, e talvez o kernelesteja procurando por este campo. Se você estiver trabalhando em um x86sistema baseado, a descompactação estará nos seguintes diretórios de arquivos:
arch/x86/boot/uncompressed/head_32.S
arch/x86/boot/uncompressed/piggy.S
A solução é usar o u-boot mais recente encontrado aqui:https://github.com/andy-shev/u-boot
No entanto, se você estiver usando um u-boot personalizado, precisará procurar este campo.
Responder3
x86? Inicialize com earlycon=efifbou earlyprintk=vga. Estou mencionando ambos, pois houve uma mudança na época do commit 69c1f396f25b805aeff08f06d2e992c315ee5b1e de earlyprintk para earlycon.