극한의 Pi 부팅 최적화

 (kittenlabs.de)
4P by GN⁺ | ★ favorite | 댓글 1개
  • SolarCamPi는 사진 촬영 때만 Raspberry Pi Zero 2 W를 켰다가 끄는 오프그리드 태양광 카메라라서, 부팅 시간 자체가 배터리 수명을 좌우함
  • Debian 12 arm64 Lite 기준으로 /init.sh를 첫 유저 공간 코드로 측정했을 때, 초기 부팅은 약 12초와 9.5Ws를 소비함
  • HDMI, LED, HAT/PoE/LCD, 카메라·디스플레이 자동 탐지, initramfs를 줄이면서 불필요한 대기와 탐지를 제거했고, 전류는 136.7mA → 120.6mA로 낮아짐
  • Buildroot 2024.02.1과 맞춤 커널로 옮긴 뒤 드라이버, 압축, KASLR, 일부 완화 기능을 제거해 3.5초 미만에 Linux 유저 공간 프로그램까지 도달함
  • 입력 전압을 5.0V에서 3.6V까지 낮추자 총 에너지는 1.754Ws → 1.438Ws로 줄었지만, 사양 밖 동작이라 안정성·신뢰성 검증이 남아 있음

SolarCamPi가 부팅 시간을 줄여야 했던 이유

  • SolarCamPi는 태양광 기반 WiFi 카메라로, Raspberry Pi Zero 2 W를 주기적으로 부팅해 사진을 찍고 WiFi로 클라우드 서비스에 업로드한 뒤 다시 종료함
  • 서유럽 겨울처럼 전력이 부족한 환경에서는 Pi가 켜져 있는 매초가 곧 전력 비용이 됨
  • 유저 공간 애플리케이션의 서버 연결과 사진 업로드는 이미 가능한 한 최적화돼 있었고, 수면 중 전력을 줄이도록 전자 회로도 설계된 상태였음
  • 남은 절감 경로는 두 가지였음
    • 소비 전류를 줄임
    • 실행 시간을 줄임
  • 전류만 낮추는 방식이 항상 이득은 아님
    • CPU turbo를 꺼서 전류가 줄어도 실행 시간이 늘면 총 에너지는 오히려 커질 수 있음
    • 목표는 전류와 시간 그래프 아래 면적을 최소화하는 것임

측정 장비와 테스트 방식

  • 임베디드 부팅 최적화에서는 변경 후 실제 실행을 빠르게 확인해야 하므로, SD 카드 탈착과 전원 조작을 줄이는 도구가 중요함
  • 사용 장비는 다음과 같음
  • Power Profiler Kit II는 테스트 대상 장치에 전원을 공급하면서 시간별 전력 소모와 8개 디지털 입력 상태를 함께 측정함
    • Raspberry Pi의 GPIO 핀을 디지털 입력에 연결함
    • 애플리케이션의 첫 동작으로 GPIO를 토글해 전원 인가부터 유저 공간 코드 실행까지의 시간을 측정함
  • USB-SD-Mux는 microSD 카드와 장치 사이에 들어가는 인터포저로, 컴퓨터가 카드를 가져와 내용을 다시 쓰고 장치에 돌려줄 수 있게 함
    • 카드를 빼고 리더기에 꽂은 뒤 다시 장치에 넣는 반복 작업을 없앰
    • 온보드 GPIO로 테스트 대상의 리셋이나 전원 제어도 자동화할 수 있음
  • USB-UART 콘솔은 부팅 실패나 WiFi 문제처럼 시스템이 깨질 때 상태를 확인하는 데 필요함

Debian 기준 부팅 측정

  • 깨끗한 Debian 12 bookworm arm64 Lite 이미지에서 /boot/firmware/cmdline.txt에 init=/init.sh를 추가함
  • 이 설정은 커널이 systemd보다 먼저 /init.sh를 유저 공간의 첫 프로세스로 실행하게 만듦
  • 예시 init.sh는 GPIO4를 토글한 뒤 exec /sbin/init으로 systemd 부팅을 이어감
  • 초기 측정에서는 약 12초 후 디지털 입력 0이 low가 되며 init.sh 실행이 확인됨
  • 이 부팅 과정은 총 1.90 coulomb을 사용함
    • 1.9As * 5.0V = 9.5Ws
    • AA 알카라인 배터리 하나는 약 13500Ws의 에너지를 제공할 수 있음

소비 전류 줄이기

  • HDMI 인코더를 완전히 비활성화하자 전류가 136.7mA에서 122.6mA로 줄어듦
    • 카메라 데이터를 인코딩해야 하므로 GPU 자체는 끌 수 없었음
    • 카메라나 GPU가 필요 없는 애플리케이션이라면 GPU 비활성화도 시도할 수 있음
  • activity LED 비활성화만으로 2mA를 절약해 전류가 122.6mA에서 120.6mA로 낮아짐
  • 카메라 LED가 있는 경우 비활성화할 수 있음
    • LED가 이미지에 반사될 가능성도 줄어듦
  • turbo 설정 변경 테스트에서는 현재 변경 상태의 Pi가 1.62As를 사용함
    • 강제 turbo 없이 실행하면 1.58As를 사용함
    • 알 수 없는 이유로 turbo/boost 모드를 끄면 GPIO4 기본 상태가 반전되어 init.sh에서 극성을 바꿨음

부팅 시간 줄이기

  • 전류는 약 13% 줄었지만, Linux 첫 출력이 콘솔에 나타나기 전까지 여전히 약 8초가 걸렸고 이 구간에서 약 1As를 소비함
  • Raspberry Pi 계열은 GPU가 먼저 초기화됨
    • GPU는 SD 카드에서 bootcode.bin을 찾음
    • Pi 4 이상은 EEPROM을 사용함
  • bootcode.bin의 BOOT_UART를 켜면 자세한 UART 로그를 볼 수 있음
    • 원본 bootcode.bin 백업이 필요하며, 변경 과정은 잠재적으로 파괴적임
  • 부트로더는 연결된 HDMI 모니터의 비디오 파라미터를 자동 탐지하려고 EDID 응답을 기다림
    • HDMI를 사용하지 않으므로 EDID 문자열을 하드코딩해 탐지를 피함
  • HAT, PoE 팬, LCD, 터치스크린 관련 I2C EEPROM 탐지도 비활성화함
    • 이 옵션들은 I2C 버스 응답을 기다리기 때문에 필요 없으면 끌 수 있음
  • MIPI 카메라와 디스플레이 자동 탐지도 시간을 사용함
    • 사용 카메라가 HQ Camera IMX477로 정해져 있어 camera_auto_detect=0, display_auto_detect=0으로 끄고 dtoverlay=imx477을 직접 로드함
  • 위 변경으로 자체 보고 부팅 시간이 5.38초에서 4.75초로 줄었고, auto_initramfs=1 제거로 initramfs를 끄면 4.47초까지 내려감
  • SD 주변장치를 100MHz로 오버클럭하는 sdtweak 방식은 측정 가능한 부팅 성능 차이를 만들지 못함
    • 쓰기 접근에서 데이터 손상 위험이 있어 원격 IoT 장치에는 바람직하지 않음

커널 로딩 병목과 Buildroot 전환

  • 이 시점에서는 커널 로딩이 가장 느린 작업 중 하나였음
    • kernel8.img 9,276,375바이트 로딩에 약 1.54초가 걸림
    • 전송 속도는 약 6MiB/s
  • 커널 로딩은 내부 독점 VideoCore IV 프로세서를 쓰는 GPU가 수행함
    • 로더 코드가 비효율적이거나 보수적 설정을 사용할 가능성은 있지만, 블랙박스라 레지스터나 파라미터를 유용하게 조정할 수 없었음
  • GPU 프로세서 코어 오버클럭은 이론적으로 가능했고 커널 로드 시간을 20% 줄였음
    • 신뢰성 같은 부작용을 알 수 없어 권장되지 않음
  • 시스템을 Raspbian/Debian에서 Buildroot 2024.02.1 기반 맞춤 배포판으로 옮김
    • native aarch64 툴체인 사용
    • glibc와 Raspberry Pi userland 도구는 유지
  • 맞춤 커널에서는 다음을 제거하거나 줄임
    • 사운드 지원
    • 대부분의 블록 장치·파일시스템 드라이버, 단 SD/MMC와 ext4는 유지
    • RAID, USB, HID, DVB
    • 비디오·프레임버퍼 지원
    • 터널, 브리징, 방화벽 등 고급 네트워킹 기능
    • Gzip 커널 압축과 모듈 압축
  • 커널과 모듈을 모두 압축하지 않는 방식은 GPU가 더 오래 로딩하더라도 전체 에너지 관점에서는 이득이었음
    • Gzip 압축 해제는 많은 에너지를 쓰고 사실상 추가 재배치 단계를 포함함
  • KASLR도 비활성화함
    • KASLR은 커널 메모리 로드 주소를 무작위화해 익스플로잇 작성을 어렵게 하지만, GPU 로딩 후 커널 재배치가 필요함
    • 이 사용 사례에서는 네트워크 공격 표면이 매우 제한적이고 애플리케이션 소프트웨어가 모두 root로 실행됨
    • Spectre 같은 추측 실행 취약점 완화 기능도 비활성화함
  • 결과 커널 크기는 8.5MiB 비압축이었고, 비교용 Gzip 압축 크기는 4.1MiB였음
    • 원래 Raspbian 커널은 25MiB 비압축, 8.9MiB Gzip 압축이었음

최종 결과와 입력 전압 최적화

  • 최종적으로 Linux 유저 공간 프로그램까지 3.5초 미만에 도달함
  • Linux 커널 내부에서 쓰인 시간은 약 400ms였음
  • 총 에너지 소비는 0.364As * 5.0V = 1.82Ws
    • stock Debian의 유저 공간 도달 에너지 9.5Ws와 비교하면 약 5분의 1 수준임
  • 게시 후 Graham Sutherland / Polynomial은 Pi Zero의 레귤레이터가 5.0V 입력에서 효율적이지 않다고 지적함
  • 테스트 시나리오와 완성품에서는 입력 전압을 4.0V까지 낮출 수 있었음
    • 5.0V: 350.94mAs * 5.0V = 1.754Ws
    • 4.0V: 390.77mAs * 4.0V = 1.563Ws
    • 3.6V: 399.60mAs * 3.6V = 1.438Ws
  • 전압을 낮추면 mC, 즉 mAs는 전류 증가 때문에 늘지만 총 에너지는 크게 줄어듦
  • 3.6V 동작은 스위칭 레귤레이터를 더 이상적인 동작점에서 쓰면서 에너지를 추가로 약 20% 줄였지만, 기술적으로 사양 밖이라 안정성·신뢰성 검증이 더 필요함

공개된 설정과 코드

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • Raspberry Pi 계열의 전력 관리는 확실히 약점 중 하나임. 그래서 새 Pico 2가 기대되는데, 외부 하드웨어 없이도 비교적 깊은 절전 상태로 들어가기 쉬워진 것처럼 보이기 때문임
    비슷한 용도의 카메라를 Google Coral mini로 만든 적이 있는데, 카메라는 HQ cam만큼 좋지 않지만 내장 RTC로 대기/깨우기를 아주 쉽게 지원해서 주기적으로 촬영하는 앱에는 딱 맞았음. 고해상도 이미지를 처리할 만큼 성능과 2GB 메모리도 있었음
    HQ camera를 물리적으로 연결할 수는 있지만, 아는 한 Coral에서 그걸 관리할 소프트웨어 파이프라인은 없음
    Raspberry Pi 생태계가 훨씬 성숙했고, Coral 라인을 Google이 계속 공급할지보다 Raspberry Pi의 향후 공급 가능성을 더 신뢰함. 그래도 하드웨어의 좋은 전력 지원이 얼마나 유용한지 확실히 느꼈음
    아이러니하게도 다음 버전 카메라는 외주 업체가 Raspberry Pi로 만들었고, 전력 문제는 훨씬 큰 배터리를 넣어서 보완했음. 덕분에 개봉도 안 한 Coral dev mini와 카메라 100개가 쌓여 있어서, 좋은 아이디어를 찾거나 팔아야 하는 처지가 됨

    • Coral 라인은 이미 죽었거나 단종된 것 아닌가 싶음. coral.ai 사이트도 2021년 이후 업데이트가 없어 보이고 저작권 표기도 2020년임
      공식 Twitter 계정을 찾으려고 "google coral twitter"를 검색했더니 두 번째 결과가 남는 보드 100개를 팔려는 당신 트윗이라니 당황스러움
    • Pi는 항상 벽 전원으로만 써봐서 흥미로움. Pi 하드웨어가 Coral 같은 전력 최적화를 못 하는 건지, 아니면 Pi의 전력 관리 소프트웨어 지원이 부족한 건지 궁금함
      외부 하드웨어로 전력을 관리한다고 한 걸 보면 단순한 소프트웨어 문제만은 아닌 듯함
    • 저전력 동작용으로 PRU 장치가 있는 BeagleBone 하드웨어도 살펴봤는지 궁금함. 시스템이 잠든 동안에도 PRU는 깨어 있을 수 있음
    • 요즘 기성 카메라로는 안 되는 어떤 작업을 하는지 궁금함

  • 애플리케이션을 커널에 링크된 initramfs로 묶으면, 단순한 경우에는 파일시스템 마운트가 필요 없어져 꽤 많이 줄일 수 있음
    어떤 경우에는 BusyBox init 같은 것도 최소한의 부팅만 수행하는 간단한 bash 스크립트로 대체 가능함. devtmpfs, proc, sysfs 등을 마운트하고, 가능하다면 glibc를 버리는 것도 검토할 만함
    initramfs를 커널에 묶기 전에 chroot로 필요한 애플리케이션 의존성이 모두 있는지 테스트하면 좋음. chroot에서 실행된다면 커널도 부팅 중 실행할 수 있고 개발 반복이 훨씬 빨라짐
    커널 모듈을 끄고 필요한 기능만 커널에 링크해 넣으면 공간과 부팅 시간을 더 줄일 수 있음. gzip 대신 zstd 압축도 테스트해볼 만함

    • 반대로 커널과 initramfs 로딩이 느리다면, 실용적으로 가능한 가장 작은 이미지로 부팅한 뒤 사용자 공간이 시작된 후 나머지 소프트웨어를 불러오는 쪽이 더 빠를 수 있음
      이전 부팅 단계가 하드웨어 성능을 충분히 못 쓰거나, 이미지가 커서 로딩과 병렬로 다른 일을 하는 편이 나은 경우가 여기에 해당함
    • 여러 의사 파일시스템을 마운트하려고 꼭 셸 스크립트가 필요한 건 아님. 애플리케이션 안에서 직접 할 수 있음
      그러면 남는 건 정적 링크된 바이너리 하나가 들어 있는 initramfs뿐임

  • Pi 부팅 시간을 줄이는 좋은 글이 두 개 더 있음
    https://www.furkantokac.com/rpi3-fast-boot-less-than-2-secon...
    http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry...
    이 두 글을 참고해서 Pi로 디지털 액자를 만들었고, 키오스크 모드 브라우저까지 매우 빠르게 부팅되게 했음. 요구사항이 아주 적으면 꽤 인상적인 부팅 시간을 얻을 수 있음

    • 첫 번째 글을 읽어보니 원글도 start_cd.elf를 쓰면 이득이 있을 것 같음. 그래픽 하위 시스템이 제거된 3단계 부트로더이고, 로딩 시간이 0.5초 개선됐다고 함
    • 링크 고마움. 혹시 그 키오스크 사진 액자 코드도 공개되어 있나요?

  • 진짜 비극은 bootcode.bin GPU 코드가 독점 블랙박스이고 소스 코드가 없다는 점임
    해킹과 취미용 프로젝트가 수정할 수 없는 숨겨진 비밀 블랙박스를 가져야 한다니 끔찍함

    • Pi 펌웨어는 ThreadX이고, 나중에 Microsoft가 인수해 Azure RTOS로 이름을 바꿨음
      지금은 자유 오픈소스 소프트웨어임
      https://www.theregister.com/2023/11/28/microsoft_opens_sourc...
      그렇다고 Pi 펌웨어 전체가 자동으로 자유 오픈소스가 되는 건 아님. 드라이버는 아니기 때문임. 하지만 원한다면 그렇게 할 수는 있음
    • bootcode 소스가 공개되면 너무 극단적인 개조가 가능해져서 RPI가 정상 동작을 보장할 수 없게 되는 건가 싶음. 아니면 독점 드라이버 로딩과 관련이 있을 수도 있음
      내부에 뭐가 있길래 닫아둬야 하는지 궁금함

  • 글 전체는 마음에 들지만 이 부분은 확신이 안 듦
    CPU 터보를 꺼서 전류 소모를 조금 아끼는 건 나쁜 선택이고, 느려진 시간 때문에 빨리 끝내고 끄는 것보다 더 많은 에너지를 쓴다는 부분임
    컴퓨터공학 수업에서 전력 소모는 클럭 주파수의 제곱에 비례한다고 배웠음. 즉 클럭을 두 배로 올리면 전력은 네 배가 된다는 뜻임
    그렇다면 클럭 상승의 2차 증가분이, 작업 시간이 늘면서 발생하는 고정 전력 소모의 곱보다 큰지 확인하려면 실제 전력 차이를 측정해야 할 것 같음
    관련해서 Pi CPU가 데이터시트에서 유도 가능하거나 레지스터로 실시간 노출되는 세밀한 전력 소모 정보를 제공하면 좋겠음

    • 그 설명은 완전히 맞지는 않음. 칩의 스위칭 전력은 정적 누설을 제외하면 전압의 제곱 곱하기 주파수에 비례함
      대부분의 칩은 더 높은 클럭 속도에 도달하려면 더 높은 전압이 필요하므로 거기서 2차 관계가 생김
      하지만 Raspberry Pi에는 동적 전압 제어가 없는 것으로 알고 있어서, 전압을 낮추지 않고 클럭만 낮추면 전체 스위칭 에너지 소모에는 영향이 없을 것 같음
    • 이건 race to idle이라는 잘 알려진 전력 최적화 전략임. CPU 외에도 전력을 쓰는 주변장치가 많고, CPU 작업이 끝나기 전까지는 끌 수 없기 때문에 효과가 있음
      물론 최적점도 있음. CPU를 너무 많이 오버클럭하면 와트당 성능이 너무 떨어져 race to idle이 더 이상 통하지 않음
    • 지속적인 작업부하라면 괜찮은 경험칙이지만 전체 이야기는 아님. 구성요소가 켜져 있기만 해도 항상 일정한 정적 전력 소모가 있음
      그래서 현대 임베디드 시스템은 종종 "race-to-sleep"이나 "race-to-halt" 전략을 써서 작업을 매우 빨리 실행한 뒤, 다음 이벤트가 올 때까지 대부분의 구성요소를 꺼둠
    • 장치가 아무것도 하지 않아도 기본적으로 쓰는 전력 오버헤드가 있음. 벤치마크에서도 터보를 켜면 전류 소모는 10% 늘지만 부팅 시간이 11% 줄어 전체 에너지 사용량에 작지만 측정 가능한 차이가 난다고 나옴
    • 흥미로운 내용임. 공유해줘서 고마움
      어떤 계산을 1초에 하는 데 1J가 든다면, 예를 들어 1GHz에서 1W라면, 완벽한 구형 소 모델에서는 같은 계산을 0.5초에 하려면 2J가 든다는 뜻인가 봄. 2GHz에서 4W가 되니까
      다만 그건 CPU 소모만 본 것이고, 전체 시스템에 4W의 고정 소모가 있다면 1GHz에서는 CPU 1J와 시스템 4J로 총 5J가 들고, 2GHz에서는 CPU 2J와 시스템 2J로 총 4J가 듦
      제대로 이해한 게 맞다면, 전체 시스템 전력 소모가 터보 상태 CPU 전력 소모와 비슷하면 터보를 쓰는 게 맞고, 아니면 그렇지 않다는 뜻인가?

  • 인상적임. 하지만 이런 글을 읽을 때마다 Pi Zero에서 Plan 9 부팅을 녹화했던 게 떠오름: https://taoofmac.com/space/blog/2020/09/02/1900#resurrecting
    GIF는 실시간 출력임

    • 그 자체로는 멋짐
      하지만 원글 프로젝트에 필요한 카메라와 Wi-Fi 드라이버를 로드할 수 있을지는 별개임

  • 개인적으로 Linux 배포판의 부팅 시간은 전반적으로 꽤 아쉽고, 이런 약한 하드웨어에서는 그 문제가 훨씬 커짐
    MQ-Pro SBC에서도 비슷한 최적화를 해봤음. 노트북에서도 이걸 꽤 체감함. MacBook은 예외일지도 모르지만, 어쨌든 짜증나는 부분임

    • 부팅 시간을 무엇으로 정의하느냐에 따라 많이 달라짐. 예를 들어 Windows는 첫 UI가 뜨는 시간에 최적화하지만, 그 뒤에도 나머지가 계속 로드되고 PC는 몇 초 동안 사실상 쓸 수 없음
    • M1 MacBook은 내 Windows 데스크톱 PC보다 시작하는 데 한 자릿수 배 정도 더 오래 걸림
      일단 켜진 뒤 로그인만 다시 하는 건 순식간이지만, 재부팅은 시간이 꽤 걸림
    • Linux도 설정을 잘 맞추면 꽤 빠르게 부팅할 수 있음. [0]에 관련해서 쓴 적이 있음
      다만 배포판은 합리적인 이유로 매우 범용적인 커널과 initramfs를 만들고, 이 조합은 부팅이 특별히 빠르지 않음
      [0]: https://blog.davidv.dev/posts/minimizing-linux-boot-times/
    • 배포판이 여기서 얼마나 할 수 있는지는 잘 모르겠음. 사용자 공간 쪽 부팅 시간은 무시할 만한 경우가 많음
      존재하지 않는 Wi-Fi를 NetworkManager가 90초 기다리는 식의 끔찍한 오설정이 없다면 말임. 내 Linux 박스는 graphical.target까지 약 4초가 걸리고, 대부분은 Wi-Fi 연결과 ntpd 때문인데 둘 다 원칙적으로는 선택 사항임
      정말 빠른 부팅을 원하면 부트로더 호환 계층, 추상화, initramfs 같은 동적 설정 가능성을 다 버리면 됨. 하지만 그러면 하드웨어 공급업체에게 좌우되므로 그만한 가치가 없음
    • 이 말은 좀 의아함. 내 경우 Linux 부팅은 오래된 기계와 느린 저장장치에서도 매우 빠름
      예를 들어 Linux를 올린 MacBook Air 11은 로그인 화면까지 너무 빨리 떠서 부팅 로그를 거의 못 봄. systemd-analyze 기준 graphical target까지 4초 미만임
      핵심은 두 가지로 보임. 데스크톱 환경을 쓰지 않고, 텍스트 모드로 부팅한 뒤 필요할 때 startx를 하거나 가벼운 로그인 관리자(lightdm)로 X에 부팅함. 데스크톱 환경이 없으면 서비스 수가 한 자릿수 배로 줄어 오래된 하드웨어에서 부팅 중 I/O 압박이 크게 낮아짐. X를 실행해도 부팅된 시스템은 200MB 미만임
      또 하나는 EFI stub이 속도를 올릴 수 있음: https://wiki.archlinux.org/title/EFISTUB

  • 첫 직감은 다른 코어를 쓸 수 없을까였음. 사진을 찍고 클라우드로 전송하는 데 정말 Linux가 필요한가?
    하드웨어 쪽 사람은 아니라서, 최소 예산으로 이 작업을 어떻게 완성할 수 있을지 궁금함. 흥미로운 글이었음

    • 나도 처음 든 생각이 같았음
      지금 식탁 위에 ESP32-CAM 두 개가 있어서일 뿐이지만, ESP32-CAM 구성이 어떻게 비교될지 궁금했음. 아마 2메가픽셀 이미지까지만 괜찮을 텐데, 시작 시간과 전력 소모는 둘 다 거의 한 자릿수 배 낮을 것 같음
      궁금하면 여기에 세부 정보가 있음: https://components101.com/modules/esp32-cam-camera-module
    • 이 프로젝트는 카메라와 무선 네트워크를 쓰는데, 둘 다 꽤 복잡한 드라이버가 필요하다는 게 문제임
      원칙적으로 베어메탈로도 가능하지만, 필요한 주변장치를 동작시키는 건 쉽지 않음

  • 커스텀 커널이 왜 이렇게 늦게 나왔는지 궁금했음. 최적화하려면 LFS나 소스 기반 배포판에서 시작하지 않나? 이런 장치에 자율 소프트웨어 업데이트가 꼭 필요한 것도 아닌 듯함
    또 이런 장치에서 EFI/BIOS를 최적화할 수 있는지도 궁금함. 적어도 내 일반 Arch Linux 데스크톱에서는 부팅 시간의 상당 부분을 차지함
    $ systemd-analyze
    Startup finished in 10.076s (firmware) + 1.339s (loader) + 1.569s (kernel) + 2.974s (initrd) + 3.894s (userspace) = 19.854s

    • 그들이 쓴 Buildroot가 정확히 이런 목적의 도구임. Buildroot에서는 자기만의 "배포판"을 설정하고, 거기서 단일 부팅 이미지를 생성함
      Raspberry Pi 하드웨어는 정확히 모르지만, 다른 많은 임베디드 SoC는 u-boot로 동작하는 꽤 최소한의 부트로더를 갖고 있고 보통 매우 빠름. 사용자 입력을 기다리는 지연 시간을 0으로 설정하면 특히 그렇음
    • 실제 환경에서 LFS 프로젝트의 매뉴얼대로 LFS를 쓰고 싶지는 않을 것임. GNU를 컴파일하는 일이 너무 많기 때문임
      최소 커널과 busybox 시스템이 훨씬 덜 고통스럽고, Gentoo도 나쁜 선택은 아님
    • 덕분에 내 부트로더(systemd-boot)를 최적화해야 한다는 것과, 내 펌웨어가 의외로 훌륭하다는 걸 알게 됨
      > systemd-analyze
      Startup finished in 3.259s (firmware) + 35.127s (loader) + 1.823s (kernel) + 2.927s (userspace) = 43.138s

  • 3.5초는 멋지지만, 전체 시나리오가 정말 몇 분마다 Wi-Fi에 연결해서 이미지를 업로드하는 것이라면 ESP32가 전력 소모 면에서 훨씬 나은 선택이었을 것임
    Pi용 카메라 모듈에 ESP32-CAM 호환 카메라에는 없는 특정 기능이 꼭 필요한 경우가 아니라면 말임

    • ESP32는 PSRAM 4MB까지만 지원하는데, RPi HQ Camera의 단일 정지 이미지만 해도 18MB임
    • MIPI CSI 인터페이스가 있는 조금 더 고급 마이크로컨트롤러를 추천할 수는 있겠지만, 그 외에는 동의함
      마이크로컨트롤러가 거의 힘들이지 않고 할 수 있는 일을 하려고 너무 많은 작업을 하는 것처럼 보임
답변달기