내 임베디드 장치에서 보안 부팅을 성공적으로 활성화했습니다. 문제는 이 모드에서 시작할 때 다음 줄 이후에 프로세스가 중단되는 것 같다는 것입니다.
Starting kernel ...
U-boot가 커널을 메모리에 복사하고 bootm명령을 실행하면.
디버거에서 PC가 yield명령에 멈춘 다음 할당에 걸리는 것을 포착할 수 있었습니다. pc = pc-4즉 본질적으로 루프입니다.
저는 이전에 그렇게 낮은 수준의 Linux에 노출된 적이 없었기 때문에 어디서부터 살펴봐야 할지 잘 모르겠습니다. 그러나 안전 모드가 아닌 경우에도 커널 이미지를 성공적으로 부팅할 수 있다는 것을 알았으므로 이는 공급업체에 대한 질문이 더 적절할 수 있습니다.
1) 일반적으로 스위칭 단계를 수행하는 U-boot에 대한 진단 정보는 어디에서 찾을 수 있습니까?
2) 실행이 언제 커널에 완전히 넘겨지나요? 즉, U-boot는 언제 만료됩니까?
답변1
아마도 다음 절차를 사용하여 Linux 초기 인쇄의 메모리를 덤프할 수 있습니다. 그 이유는 커널이 시작 중이지만 콘솔이 초기화되기 전에 정지되기 때문일 수 있습니다. 또한 uboot의 커널 진입점에 내용을 인쇄하고 제어가 커널로 전송되었는지 확인합니다.
파일 을 찾으세요 System.map. log_buf주소를 식별하려면 다음 명령을 사용하십시오 .
grep __log_buf System.map
이것은 다음과 같이 출력됩니다
c0352d88 B __log_buf
보드를 웜 부팅합니다(RAM의 내용은 삭제되어서는 안 됩니다).
Uboot의 메모리 덤프(c0352d88) __log_buf. 커널 콘솔 인쇄를 덤프합니다. 이렇게 하면 정지가 발생하는 위치를 정확히 확인할 수 있습니다.
답변2
나는 한때 같은 문제에 직면했고 해결책을 찾았습니다. 문제는 u-boot structure field저장된 것 중 하나가 압축되지 않은 크기로 필드를 채우지 않고 size나중에 uncompressed linux kernel.해당 크기를 사용하여 크기를 조정하므로 시스템이 정의되지 않은 상태로 남아 있다는 것입니다.u-bootlinux kernelstack
u-boot이 메시지가 인쇄 되면 u-boot가 a를 호출하여 커널이 실행을 인계받게 하고 아마도 이 필드를 찾는 후에 Starting kernel...다음 메시지가 표시되어야 합니다 . 기본 기반 시스템을 사용하는 경우 압축 해제는 다음 파일 디렉터리에 있습니다.Uncompressing Linux... done, booting the kernelSMM Handlerkernelx86
arch/x86/boot/uncompressed/head_32.S
arch/x86/boot/uncompressed/piggy.S
해결책은 여기에서 최신 u-boot를 사용하는 것입니다.https://github.com/andy-shev/u-boot
그러나 사용자 정의 u-boot를 사용하는 경우 이 필드를 찾아야 합니다.
답변3
x86? 를 사용 earlycon=efifb하거나 시작하세요 earlyprintk=vga. 커밋 69c1f396f25b805aeff08f06d2e992c315ee5b1e 중에 earlyprintk에서 earlycon으로 변경이 있었기 때문에 두 가지를 모두 언급했습니다.