우리 팀은 임베디드 Linux 솔루션용 소프트웨어를 개발하고 있습니다. 우리가 직면한 문제는 시스템이 우리가 원하는 애플리케이션 실행을 시작할 준비를 하는 데 너무 많은 시간이 걸린다는 것입니다(즉, Linux 커널을 로드하는 데 너무 많은 시간이 걸립니다). 일반적으로 완료하는 데 38~43초가 걸립니다. 커널 구성을 수정하고 필요하지 않은 파일을 제거했지만 여전히 이만큼의 시간이 걸립니다.
내 질문: 커널 부팅을 더 빠르게 만드는 다른 방법이 있습니까(가급적이면 하드웨어를 변경하지 않고)? 임베디드 Linux를 충전하는 데 시간이 오래 걸리는 것이 정상입니까? 커널이 완전히 충전되기 전에 Linux 커널에 애플리케이션을 시작하도록 요청할 수 있습니까?
시스템은 텍사스 인스트루먼트(Texas Instruments)OMAP L138.
다음은 커널이 부팅될 때 터미널에 표시되는 가장 관련성 높은 메시지가 모두 포함된 이미지입니다. 내 질문에 대한 (일반적인) 답변을 갖고 있지 않지만 커널 부팅 속도를 향상시키는 데 도움이 되는 내용 중 하나를 알고 있는 사람이 있다면 그 질문에도 자유롭게 답변해 주세요!
답변1
출력에서 커널이 실제로 로드되는 지점은 다음과 같습니다.
Init version 2.86 booting
23초 후입니다. 이후,내부에사용자 공간 프로세스인 가 사용자 공간 구성을 인계받아 시작합니다. 그러나 이로 인해 필연적으로 적절한 모듈 로드를 포함하여 다양한 커널 드라이버가 활성화됩니다.
이것이 어떤 플랫폼인지는 밝히지 않았지만, 예를 들어 700Mhz 단일 코어 Raspberry Pi에서는 약 4초입니다. 따라서 이것은 여전히 매우 느리며, 이는 뭔가 잘못되었음을 나타냅니다.
0초와 19초 사이의 차이를 빼면 예상한 결과를 얻습니다. 이 격차는 MII PHY에 대한 설명으로 끝납니다.이더넷 장치 드라이버입니다.. 네트워크 없이 시스템을 부팅할 수 있는 경우 커널 외부에서 이더넷 드라이버를 구성하여 이를 확인하고 속도가 init빨라지는지 확인할 수 있습니다.
23초가 지나면 주요 병목 현상은 아마도 루트 파일 시스템의 I/O일 것입니다. 어떤 이유로 25초에서 30초 사이에 5초의 간격이 있고 마지막에는 FAT 파일 시스템 오류에 대한 메모가 있습니다. 실제로 거기에는 몇 가지 fs 버그가 있습니다. 이는 init 시스템이 존재하지 않는 파일 시스템을 마운트하려고 시도하고 있음을 의미하며 이는 시간 낭비입니다.
33~37초 사이에 관련 버그를 나타내는 더 많은 오류가 발생합니다.파일 시스템이 배열되는 방식 및/또는 이에 의존하는 소프트웨어가 구성되는 방식. 이러한 종속성 중 하나가능한RAM에 생성되어야 했지만 실패했던 tmpfs 파일 시스템입니다(따라서 /var/및 에 파일이 누락됨 /tmp). /etc/fstab여기서 요점이 불분명하다면 별도의 질문을 하고 다른 사람에게 설명을 요청할 수 있습니다.