임베디드 장치에서 보안 부팅을 성공적으로 활성화했습니다. 문제는 이 모드로 부팅할 때 프로세스가 다음 줄 바로 뒤에서 멈춘 것처럼 보인다는 것입니다.
Starting kernel ...
U-boot가 커널을 메모리에 복사하고 bootm명령을 실행하면.
디버거에서 PC가 yield명령에 이어 할당이 따라오는 것을 캡처할 수 있습니다 pc = pc-4. 따라서 본질적으로 루프입니다.
나는 이전에 리눅스를 이렇게 낮은 수준으로 키워본 적이 없어서 어디서부터 시작해야 할지 잘 모르겠습니다. 하지만 보안 모드가 아닐 때도 커널 이미지를 성공적으로 부팅할 수 있다는 점을 알았으므로 이는 공급업체에 더 적절한 질문일 수 있습니다.
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중 하나에 있습니다.sizeuncompressed linux kernel.u-bootlinux kernelstack
u-boot메시지를 인쇄 하고 나면 u-boot가 커널이 실행을 인계할 수 있도록 Starting kernel...다음 메시지가 Uncompressing Linux... done, booting the kernel전송 되어야 하며 아마도 이 필드를 찾고 있을 것입니다. 기반 시스템 에서 작업하는 경우 압축 해제는 다음 파일 디렉터리에 있습니다.SMM 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으로 변경이 있었기 때문에 둘 다 언급하고 있습니다.