Optimasi Boot Pi yang Ekstrem

 (kittenlabs.de)
4 poin oleh GN⁺ 2024-09-02 | 1 komentar | Bagikan ke WhatsApp
  • SolarCamPi adalah kamera tenaga surya off-grid yang hanya menyalakan Raspberry Pi Zero 2 W saat mengambil foto lalu mematikannya, sehingga waktu boot itu sendiri menentukan umur baterai
  • Berdasarkan Debian 12 arm64 Lite, ketika /init.sh diukur sebagai kode user space pertama, boot awal mengonsumsi sekitar 12 detik dan 9,5 Ws
  • Dengan mengurangi HDMI, LED, HAT/PoE/LCD, deteksi otomatis kamera dan display, serta initramfs, waktu tunggu dan deteksi yang tidak perlu dihilangkan, dan arus turun dari 136,7 mA → 120,6 mA
  • Setelah beralih ke Buildroot 2024.02.1 dan kernel kustom, driver, kompresi, KASLR, serta beberapa mitigasi dihapus sehingga program user space Linux dapat dicapai dalam kurang dari 3,5 detik
  • Menurunkan tegangan input dari 5,0 V ke 3,6 V mengurangi total energi dari 1,754 Ws → 1,438 Ws, tetapi karena beroperasi di luar spesifikasi, pengujian stabilitas dan keandalan masih tersisa

Mengapa SolarCamPi perlu memangkas waktu boot

  • SolarCamPi adalah kamera WiFi bertenaga surya yang secara berkala mem-boot Raspberry Pi Zero 2 W untuk mengambil foto, mengunggahnya ke layanan cloud melalui WiFi, lalu mematikannya kembali
  • Di lingkungan dengan daya terbatas seperti musim dingin Eropa Barat, setiap detik Pi menyala langsung menjadi biaya daya
  • Koneksi server dan unggahan foto pada aplikasi user space sudah dioptimalkan sejauh mungkin, dan rangkaian elektroniknya juga sudah dirancang untuk mengurangi daya saat tidur
  • Jalur penghematan yang tersisa ada dua
    • Mengurangi arus konsumsi
    • Mengurangi waktu berjalan
  • Menurunkan arus saja tidak selalu menguntungkan
    • Meski mematikan CPU turbo menurunkan arus, jika waktu eksekusi bertambah maka total energi justru bisa meningkat
    • Tujuannya adalah meminimalkan luas area di bawah grafik arus dan waktu

Peralatan pengukuran dan metode pengujian

  • Dalam optimasi boot embedded, karena perlu cepat memeriksa eksekusi nyata setelah perubahan, alat yang mengurangi bongkar-pasang kartu SD dan manipulasi daya sangat penting
  • Peralatan yang digunakan adalah sebagai berikut
  • Power Profiler Kit II memasok daya ke perangkat yang diuji sambil mengukur konsumsi daya dari waktu ke waktu beserta status 8 input digital
    • Pin GPIO Raspberry Pi dihubungkan ke input digital
    • Sebagai aksi pertama aplikasi, GPIO di-toggle untuk mengukur waktu dari pemberian daya hingga eksekusi kode user space
  • USB-SD-Mux adalah interposer yang ditempatkan di antara kartu microSD dan perangkat, memungkinkan komputer mengambil alih kartu, menulis ulang isinya, lalu mengembalikannya ke perangkat
    • Menghilangkan pekerjaan berulang melepas kartu, memasukkannya ke reader, lalu memasangnya kembali ke perangkat
    • Dengan GPIO onboard, reset atau kontrol daya perangkat uji juga dapat diotomatisasi
  • Konsol USB-UART diperlukan untuk memeriksa status saat sistem bermasalah, seperti kegagalan boot atau masalah WiFi

Pengukuran boot berdasarkan Debian

  • Pada image Debian 12 bookworm arm64 Lite yang bersih, init=/init.sh ditambahkan ke /boot/firmware/cmdline.txt
  • Pengaturan ini membuat kernel menjalankan /init.sh sebagai proses pertama di user space sebelum systemd
  • Contoh init.sh men-toggle GPIO4 lalu melanjutkan boot systemd dengan exec /sbin/init
  • Pada pengukuran awal, input digital 0 menjadi low setelah sekitar 12 detik, mengonfirmasi bahwa init.sh telah berjalan
  • Proses boot ini menggunakan total 1,90 coulomb
    • 1.9As * 5.0V = 9.5Ws
    • Satu baterai alkaline AA dapat menyediakan energi sekitar 13500 Ws

Mengurangi arus konsumsi

  • Setelah encoder HDMI dinonaktifkan sepenuhnya, arus turun dari 136,7 mA menjadi 122,6 mA
    • Karena data kamera harus di-encode, GPU itu sendiri tidak bisa dimatikan
    • Untuk aplikasi yang tidak memerlukan kamera atau GPU, menonaktifkan GPU juga bisa dicoba
  • Menonaktifkan activity LED saja menghemat 2 mA, menurunkan arus dari 122,6 mA menjadi 120,6 mA
  • Jika ada LED kamera, itu dapat dinonaktifkan
    • Kemungkinan pantulan LED pada gambar juga berkurang
  • Dalam pengujian perubahan pengaturan turbo, Pi pada kondisi perubahan saat ini menggunakan 1,62 As
    • Saat dijalankan tanpa turbo paksa, ia menggunakan 1,58 As
    • Karena alasan yang tidak diketahui, mematikan mode turbo/boost membalik status default GPIO4, sehingga polaritas diubah di init.sh

Mengurangi waktu boot

  • Arus berkurang sekitar 13%, tetapi sebelum output pertama Linux muncul di konsol masih diperlukan sekitar 8 detik, dan sekitar 1 As dikonsumsi di bagian ini
  • Pada keluarga Raspberry Pi, GPU diinisialisasi terlebih dahulu
    • GPU mencari bootcode.bin di kartu SD
    • Pi 4 dan yang lebih baru menggunakan EEPROM
  • Jika BOOT_UART pada bootcode.bin diaktifkan, log UART yang detail dapat dilihat
    • Cadangan bootcode.bin asli diperlukan, dan proses perubahan berpotensi merusak
  • Bootloader menunggu respons EDID untuk mencoba mendeteksi otomatis parameter video monitor HDMI yang terhubung
    • Karena HDMI tidak digunakan, string EDID di-hardcode untuk menghindari deteksi
  • Deteksi EEPROM I2C terkait HAT, kipas PoE, LCD, dan touchscreen juga dinonaktifkan
    • Opsi-opsi ini menunggu respons bus I2C, jadi dapat dimatikan jika tidak diperlukan
  • Deteksi otomatis kamera dan display MIPI juga memakan waktu
    • Karena kamera yang digunakan sudah ditetapkan sebagai HQ Camera IMX477, camera_auto_detect=0 dan display_auto_detect=0 digunakan untuk mematikannya, lalu dtoverlay=imx477 dimuat langsung
  • Dengan perubahan di atas, waktu boot yang dilaporkan sendiri turun dari 5,38 detik menjadi 4,75 detik, dan dengan mematikan initramfs lewat penghapusan auto_initramfs=1, turun lagi hingga 4,47 detik
  • Metode sdtweak yang meng-overclock periferal SD ke 100 MHz tidak menghasilkan perbedaan performa boot yang terukur
    • Karena ada risiko korupsi data pada akses tulis, ini tidak ideal untuk perangkat IoT jarak jauh

Bottleneck loading kernel dan peralihan ke Buildroot

  • Pada titik ini, loading kernel merupakan salah satu pekerjaan paling lambat
    • Loading kernel8.img berukuran 9.276.375 byte memakan waktu sekitar 1,54 detik
    • Kecepatan transfer sekitar 6 MiB/s
  • Loading kernel dilakukan oleh GPU yang menggunakan prosesor internal proprietary VideoCore IV
    • Ada kemungkinan kode loader tidak efisien atau memakai pengaturan konservatif, tetapi karena berupa black box, register atau parameter tidak dapat disesuaikan secara berguna
  • Overclock core prosesor GPU secara teori memungkinkan dan mengurangi waktu load kernel sebesar 20%
    • Tidak direkomendasikan karena efek samping seperti keandalan tidak diketahui
  • Sistem dipindahkan dari Raspbian/Debian ke distribusi kustom berbasis Buildroot 2024.02.1
    • Menggunakan toolchain native aarch64
    • glibc dan alat Raspberry Pi userland tetap dipertahankan
  • Pada kernel kustom, hal-hal berikut dihapus atau dikurangi
    • Dukungan suara
    • Sebagian besar driver perangkat blok dan filesystem, kecuali SD/MMC dan ext4 tetap dipertahankan
    • RAID, USB, HID, DVB
    • Dukungan video dan framebuffer
    • Fitur jaringan lanjutan seperti tunnel, bridging, firewall
    • Kompresi kernel Gzip dan kompresi modul
  • Membiarkan kernel dan modul sama-sama tidak terkompresi menguntungkan dari sudut pandang energi keseluruhan, meski GPU memuat lebih lama
    • Dekompresi Gzip memakai banyak energi dan pada dasarnya mencakup tahap relokasi tambahan
  • KASLR juga dinonaktifkan
    • KASLR mengacak alamat load memori kernel agar pembuatan exploit lebih sulit, tetapi setelah loading oleh GPU, relokasi kernel diperlukan
    • Dalam use case ini, permukaan serangan jaringan sangat terbatas dan semua software aplikasi berjalan sebagai root
    • Mitigasi kerentanan speculative execution seperti Spectre juga dinonaktifkan
  • Ukuran kernel hasilnya 8,5 MiB tanpa kompresi, dan ukuran kompresi Gzip untuk perbandingan adalah 4,1 MiB
    • Kernel Raspbian asli berukuran 25 MiB tanpa kompresi dan 8,9 MiB dengan kompresi Gzip

Hasil akhir dan optimasi tegangan input

  • Pada akhirnya, program user space Linux dapat dicapai dalam kurang dari 3,5 detik
  • Waktu yang digunakan di dalam kernel Linux sekitar 400 ms
  • Total konsumsi energi adalah 0,364 As * 5,0 V = 1,82 Ws
    • Dibandingkan energi untuk mencapai user space pada stock Debian, 9,5 Ws, ini sekitar seperlimanya
  • Setelah dipublikasikan, Graham Sutherland / Polynomial menunjukkan bahwa regulator Pi Zero tidak efisien pada input 5,0 V
  • Dalam skenario pengujian dan produk akhir, tegangan input dapat diturunkan hingga 4,0 V
    • 5,0 V: 350.94mAs * 5.0V = 1.754Ws
    • 4,0 V: 390.77mAs * 4.0V = 1.563Ws
    • 3,6 V: 399.60mAs * 3.6V = 1.438Ws
  • Saat tegangan diturunkan, mC, yaitu mAs, meningkat karena kenaikan arus, tetapi total energi turun signifikan
  • Operasi pada 3,6 V mengurangi energi tambahan sekitar 20% dengan memakai switching regulator pada titik operasi yang lebih ideal, tetapi secara teknis berada di luar spesifikasi sehingga diperlukan pengujian stabilitas dan keandalan lebih lanjut

Konfigurasi dan kode yang dipublikasikan

Bacaan terkait

1 komentar

 
GN⁺ 2024-09-02
Komentar Hacker News

  • Manajemen daya lini Raspberry Pi jelas merupakan salah satu kelemahannya. Karena itu, Pico 2 baru terasa menjanjikan, sebab tampaknya lebih mudah masuk ke kondisi hemat daya yang cukup dalam tanpa perangkat keras eksternal
    Saya pernah membuat kamera untuk用途 serupa dengan Google Coral mini. Kameranya memang tidak sebagus HQ cam, tetapi RTC bawaan membuat mode siaga/bangun sangat mudah didukung, sehingga pas untuk aplikasi yang mengambil gambar secara berkala. Performanya dan memori 2GB-nya juga cukup untuk memproses gambar beresolusi tinggi
    Secara fisik HQ camera bisa disambungkan, tetapi sejauh yang saya tahu tidak ada pipeline perangkat lunak di Coral untuk mengelolanya
    Ekosistem Raspberry Pi jauh lebih matang, dan saya lebih percaya pada ketersediaan Raspberry Pi ke depannya dibanding kemungkinan Google terus memasok lini Coral. Tetap saja, saya benar-benar merasakan betapa bergunanya dukungan daya yang baik di perangkat keras
    Ironisnya, kamera versi berikutnya dibuat oleh vendor eksternal dengan Raspberry Pi, dan masalah dayanya ditutupi dengan memasang baterai yang jauh lebih besar. Akibatnya saya kini menumpuk satu Coral dev mini dan 100 kamera yang bahkan belum dibuka, jadi harus mencari ide bagus atau menjualnya

    • Lini Coral sepertinya sudah mati atau dihentikan. Situs coral.ai juga tampaknya tidak diperbarui sejak 2021, dan keterangan hak ciptanya masih 2020
      Saya mencoba mencari akun Twitter resminya dengan menelusuri "google coral twitter", dan cukup mengejutkan hasil kedua adalah cuitan Anda yang ingin menjual 100 board tersisa itu
    • Menarik, karena saya selalu memakai Pi hanya dengan listrik dari stopkontak. Saya penasaran apakah perangkat keras Pi memang tidak bisa melakukan optimisasi daya seperti Coral, atau dukungan perangkat lunak manajemen daya Pi yang kurang
      Melihat disebutkan bahwa daya dikelola dengan perangkat keras eksternal, tampaknya ini bukan sekadar masalah perangkat lunak
    • Saya penasaran apakah Anda juga sempat melihat perangkat keras BeagleBone yang punya perangkat PRU untuk operasi berdaya rendah. PRU bisa tetap menyala saat sistem sedang tidur
    • Saya penasaran pekerjaan seperti apa yang Anda lakukan yang tidak bisa dilakukan kamera siap pakai saat ini

  • Jika aplikasi dibundel sebagai initramfs yang ditautkan ke kernel, untuk kasus sederhana kebutuhan me-mount filesystem bisa hilang, sehingga cukup banyak yang bisa dipangkas
    Dalam beberapa kasus, hal seperti BusyBox init juga bisa diganti dengan skrip bash sederhana yang hanya melakukan boot minimal. Layak juga mempertimbangkan untuk me-mount devtmpfs, proc, sysfs, dan lain-lain, serta meninggalkan glibc jika memungkinkan
    Sebelum membundel initramfs ke kernel, sebaiknya uji lewat chroot untuk memastikan semua dependensi aplikasi yang diperlukan sudah ada. Jika berjalan di chroot, kernel juga bisa menjalankannya saat boot, dan iterasi pengembangan menjadi jauh lebih cepat
    Dengan mematikan modul kernel dan menautkan hanya fitur yang dibutuhkan ke dalam kernel, ruang dan waktu boot bisa dipangkas lagi. Kompresi zstd sebagai pengganti gzip juga layak diuji

    • Sebaliknya, jika pemuatan kernel dan initramfs lambat, secara praktis bisa lebih cepat untuk boot dengan image sekecil mungkin lalu memuat sisa perangkat lunak setelah ruang pengguna mulai berjalan
      Ini berlaku ketika tahap boot sebelumnya tidak memanfaatkan performa perangkat keras secara penuh, atau ketika image besar sehingga lebih baik melakukan hal lain secara paralel sambil memuatnya
    • Untuk me-mount berbagai filesystem semu, tidak harus memakai skrip shell. Itu bisa dilakukan langsung di dalam aplikasi
      Dengan begitu yang tersisa hanyalah initramfs berisi satu biner yang ditautkan statis

  • Ada dua tulisan bagus lain tentang memangkas waktu boot Pi
    https://www.furkantokac.com/rpi3-fast-boot-less-than-2-secon...
    http://himeshp.blogspot.com/2018/08/fast-boot-with-raspberry...
    Dengan mengacu pada dua tulisan ini, saya membuat bingkai foto digital memakai Pi dan berhasil membuatnya boot sangat cepat sampai ke browser mode kios. Jika kebutuhannya sangat sedikit, waktu boot yang didapat bisa cukup mengesankan

    • Setelah membaca tulisan pertama, sepertinya tulisan asli juga bisa mendapat manfaat dari memakai start_cd.elf. Itu adalah bootloader tahap ketiga yang subsistem grafisnya dihapus, dan katanya waktu pemuatan membaik 0,5 detik
    • Terima kasih untuk tautannya. Apakah kode bingkai foto kios itu juga dipublikasikan?

  • Tragedi sebenarnya adalah kode GPU bootcode.bin bersifat black box proprietary dan tidak ada kode sumbernya
    Mengerikan kalau proyek hacking dan hobi harus memiliki black box rahasia tersembunyi yang tidak bisa dimodifikasi

    • Firmware Pi adalah ThreadX, yang kemudian diakuisisi Microsoft dan diganti namanya menjadi Azure RTOS
      Sekarang itu adalah perangkat lunak bebas dan open source
      https://www.theregister.com/2023/11/28/microsoft_opens_sourc...
      Namun itu tidak otomatis membuat seluruh firmware Pi menjadi bebas dan open source. Karena itu bukan driver. Tapi jika mereka mau, mereka bisa melakukannya
    • Saya bertanya-tanya apakah jika sumber bootcode dibuka, modifikasi yang terlalu ekstrem akan menjadi mungkin sehingga RPI tidak bisa menjamin operasi normal. Atau bisa jadi ada kaitannya dengan pemuatan driver proprietary
      Saya penasaran apa yang ada di dalamnya sampai harus ditutup

  • Saya suka keseluruhan tulisannya, tetapi saya kurang yakin dengan bagian ini
    Maksudnya bagian yang mengatakan bahwa mematikan turbo CPU untuk sedikit menghemat konsumsi arus adalah pilihan buruk, dan karena waktu yang menjadi lebih lambat, energinya justru lebih banyak daripada menyelesaikan pekerjaan cepat lalu mematikannya
    Di kelas ilmu komputer saya belajar bahwa konsumsi daya berbanding lurus dengan kuadrat frekuensi clock. Artinya, jika clock dinaikkan dua kali lipat, dayanya menjadi empat kali lipat
    Kalau begitu, untuk memastikan apakah kenaikan kuadratik dari peningkatan clock lebih besar daripada hasil kali konsumsi daya tetap yang muncul karena waktu kerja bertambah, sepertinya perlu mengukur selisih daya sebenarnya
    Terkait hal itu, akan bagus jika CPU Pi menyediakan informasi konsumsi daya yang rinci, yang bisa diturunkan dari datasheet atau diekspos secara real-time lewat register

    • Penjelasan itu tidak sepenuhnya tepat. Daya switching chip, jika mengabaikan kebocoran statis, berbanding lurus dengan kuadrat tegangan dikali frekuensi
      Sebagian besar chip membutuhkan tegangan lebih tinggi untuk mencapai kecepatan clock yang lebih tinggi, dan dari situlah hubungan kuadratik itu muncul
      Namun setahu saya Raspberry Pi tidak memiliki kontrol tegangan dinamis, jadi jika hanya menurunkan clock tanpa menurunkan tegangan, sepertinya tidak akan berdampak pada total konsumsi energi switching
    • Ini adalah strategi optimasi daya yang terkenal, disebut race to idle. Selain CPU, ada banyak periferal yang memakai daya, dan karena periferal itu tidak bisa dimatikan sebelum pekerjaan CPU selesai, strategi ini efektif
      Tentu saja ada titik optimalnya juga. Jika CPU dioverclock terlalu tinggi, performa per watt menjadi terlalu buruk sehingga race to idle tidak lagi berlaku
    • Untuk beban kerja berkelanjutan, itu pengalaman praktis yang cukup baik, tetapi bukan keseluruhan ceritanya. Ada konsumsi daya statis yang selalu tetap selama komponen menyala
      Karena itu, sistem embedded modern sering memakai strategi "race-to-sleep" atau "race-to-halt": menjalankan pekerjaan secepat mungkin, lalu mematikan sebagian besar komponen sampai event berikutnya datang
    • Ada overhead daya dasar yang dipakai perangkat meskipun tidak melakukan apa-apa. Di benchmark juga terlihat bahwa saat turbo diaktifkan, konsumsi arus naik 10%, tetapi waktu boot berkurang 11%, sehingga ada perbedaan kecil namun terukur pada total penggunaan energi
    • Menarik. Terima kasih sudah berbagi
      Jika suatu perhitungan membutuhkan 1J untuk dilakukan dalam 1 detik, misalnya 1W pada 1GHz, maka dalam model sapi bulat yang sempurna, melakukan perhitungan yang sama dalam 0,5 detik berarti membutuhkan 2J. Karena pada 2GHz dayanya menjadi 4W
      Namun itu hanya melihat konsumsi CPU, dan jika seluruh sistem memiliki konsumsi tetap 4W, maka pada 1GHz totalnya 5J, yaitu CPU 1J dan sistem 4J, sedangkan pada 2GHz totalnya 4J, yaitu CPU 2J dan sistem 2J
      Jika pemahaman saya benar, artinya kalau konsumsi daya seluruh sistem kira-kira sebanding dengan konsumsi daya CPU dalam kondisi turbo, maka memakai turbo adalah pilihan yang tepat, dan jika tidak, maka bukan?

  • Mengesankan. Namun setiap kali membaca tulisan seperti ini, saya teringat rekaman boot Plan 9 di Pi Zero yang pernah saya buat: https://taoofmac.com/space/blog/2020/09/02/1900#resurrecting
    GIF-nya adalah output real-time

    • Itu sendiri keren
      Namun apakah ia bisa memuat driver kamera dan Wi-Fi yang dibutuhkan proyek di tulisan asli adalah soal lain

  • Secara pribadi, menurut saya waktu boot distro Linux secara umum cukup mengecewakan, dan pada hardware lemah seperti ini masalahnya jauh lebih besar
    Saya pernah melakukan optimasi serupa di SBC MQ-Pro. Di laptop pun hal ini cukup terasa. MacBook mungkin pengecualian, tetapi bagaimanapun ini hal yang menjengkelkan

    • Banyak bergantung pada apa yang didefinisikan sebagai waktu boot. Misalnya Windows mengoptimalkan waktu sampai UI pertama muncul, tetapi setelah itu sisanya masih terus dimuat dan PC pada dasarnya belum bisa dipakai selama beberapa detik
    • M1 MacBook saya butuh waktu beberapa kali lipat, masih satu digit, lebih lama untuk mulai dibanding PC desktop Windows saya
      Setelah menyala, kalau hanya login lagi memang seketika, tetapi reboot memakan waktu lumayan
    • Linux juga bisa boot cukup cepat jika konfigurasinya disetel dengan baik. Saya pernah menulis tentang itu di [0]
      Namun distro, dengan alasan yang masuk akal, membuat kernel dan initramfs yang sangat serbaguna, dan kombinasi ini memang tidak terlalu cepat saat boot
      [0]: https://blog.davidv.dev/posts/minimizing-linux-boot-times/
    • Saya kurang yakin seberapa banyak yang bisa dilakukan distro di sini. Sering kali waktu boot sisi user space bisa diabaikan
      Kecuali ada salah konfigurasi mengerikan seperti NetworkManager menunggu Wi-Fi yang tidak ada selama 90 detik. Mesin Linux saya butuh sekitar 4 detik sampai graphical.target, dan sebagian besar karena koneksi Wi-Fi dan ntpd, yang keduanya pada prinsipnya opsional
      Jika benar-benar ingin boot sangat cepat, buang saja semua kemungkinan konfigurasi dinamis seperti lapisan kompatibilitas bootloader, abstraksi, dan initramfs. Namun itu membuat kita bergantung pada vendor hardware, jadi tidak sepadan
    • Pernyataan ini agak membingungkan bagi saya. Dalam pengalaman saya, boot Linux sangat cepat bahkan di mesin lama dan storage lambat
      Misalnya MacBook Air 11 yang menjalankan Linux menampilkan layar login begitu cepat sampai saya hampir tidak sempat melihat log boot. Menurut systemd-analyze, kurang dari 4 detik sampai graphical target
      Kuncinya tampaknya dua hal. Tidak memakai desktop environment, lalu boot ke mode teks dan menjalankan startx saat diperlukan, atau boot ke X dengan login manager ringan seperti lightdm. Tanpa desktop environment, jumlah service turun beberapa kali lipat hingga hanya satu digit, sehingga tekanan I/O saat boot pada hardware lama jauh berkurang. Bahkan saat X dijalankan, sistem yang sudah boot memakai kurang dari 200MB
      Satu lagi, EFI stub bisa meningkatkan kecepatan: https://wiki.archlinux.org/title/EFISTUB

  • Kesan pertama saya adalah, apakah tidak bisa memakai core lain? Apakah benar-benar perlu Linux hanya untuk mengambil foto dan mengirimkannya ke cloud?
    Saya bukan orang hardware, jadi saya penasaran bagaimana pekerjaan ini bisa diselesaikan dengan anggaran seminimal mungkin. Tulisannya menarik

    • Saya juga punya pikiran yang sama pada awalnya
      Mungkin hanya karena sekarang ada dua ESP32-CAM di atas meja makan saya, tapi saya penasaran bagaimana konfigurasi ESP32-CAM akan dibandingkan. Mungkin hanya akan oke sampai gambar 2 megapiksel, tetapi waktu mulai dan konsumsi dayanya sepertinya sama-sama hampir satu orde besaran lebih rendah
      Kalau penasaran, detailnya ada di sini: https://components101.com/modules/esp32-cam-camera-module
    • Masalahnya, proyek ini memakai kamera dan jaringan nirkabel, dan keduanya membutuhkan driver yang cukup kompleks
      Secara prinsip bisa saja bare-metal, tetapi membuat periferal yang diperlukan berjalan itu tidak mudah

  • Saya sempat bertanya-tanya kenapa kernel kustom baru muncul begitu terlambat. Kalau mau optimasi, bukankah biasanya mulai dari LFS atau distro berbasis source? Sepertinya perangkat seperti ini juga tidak benar-benar membutuhkan pembaruan software otonom
    Saya juga penasaran apakah EFI/BIOS pada perangkat seperti ini bisa dioptimalkan. Setidaknya di desktop Arch Linux biasa saya, itu memakan porsi cukup besar dari waktu boot
    $ systemd-analyze
    Startup finished in 10.076s (firmware) + 1.339s (loader) + 1.569s (kernel) + 2.974s (initrd) + 3.894s (userspace) = 19.854s

    • Buildroot yang mereka pakai memang alat untuk tujuan persis seperti ini. Di Buildroot, Anda mengatur "distro" sendiri, lalu menghasilkan satu image boot darinya
      Saya tidak tahu persis hardware Raspberry Pi, tetapi banyak SoC embedded lain punya bootloader yang cukup minimal yang berjalan dengan u-boot dan biasanya sangat cepat. Apalagi kalau jeda untuk menunggu input pengguna diatur ke 0
    • Di lingkungan nyata, Anda mungkin tidak akan ingin memakai LFS sesuai manual proyek LFS. Karena terlalu banyak pekerjaan mengompilasi GNU
      Sistem kernel minimal plus busybox jauh lebih tidak menyakitkan, dan Gentoo juga bukan pilihan buruk
    • Berkat ini saya jadi tahu bahwa saya perlu mengoptimalkan bootloader saya (systemd-boot), dan bahwa firmware saya ternyata sangat bagus
      > systemd-analyze
      Startup finished in 3.259s (firmware) + 35.127s (loader) + 1.823s (kernel) + 2.927s (userspace) = 43.138s

  • 3,5 detik memang keren, tetapi kalau seluruh skenarionya benar-benar hanya tersambung ke Wi-Fi setiap beberapa menit untuk mengunggah gambar, ESP32 akan menjadi pilihan yang jauh lebih baik dari sisi konsumsi daya
    Kecuali kalau modul kamera untuk Pi memiliki fitur tertentu yang memang dibutuhkan dan tidak ada pada kamera yang kompatibel dengan ESP32-CAM

    • ESP32 hanya mendukung hingga PSRAM 4MB, sementara satu gambar diam dari RPi HQ Camera saja berukuran 18MB
    • Saya bisa saja merekomendasikan mikrokontroler yang sedikit lebih canggih dengan antarmuka MIPI CSI, tetapi selain itu saya setuju
      Ini terlihat seperti melakukan terlalu banyak pekerjaan untuk sesuatu yang bisa dilakukan mikrokontroler nyaris tanpa usaha