Pendahuluan
Saat ini, pasar menawarkan berbagai pembayar tunggal untuk setiap selera dengan harga yang terjangkau.
Sebagai aturan, berbagai majelis dari produsen dirancang untuk mengevaluasi platform dan merupakan titik awal proyek baru, oleh karena itu mereka tidak selalu cocok untuk tugas-tugas tertentu. Dalam tugas-tugas yang membutuhkan keandalan tinggi, pengembang mengajukan pertanyaan tentang bagaimana mengubah kit distribusi dan kemudian tidak membayarnya dengan revisi gambar dan sistem pembaruan yang lengkap.
Di Internet, hampir tidak ada informasi tentang apa yang seharusnya dibuat oleh rilis dan bagaimana mengimplementasikan pembaruannya, sehingga pengembang dipaksa untuk membuat "sepeda" atau menggunakan perkembangannya sendiri, yang tidak selalu 100% diuji.
Karena saya mengambil bagian dalam pengembangan perangkat lunak untuk berbagai perangkat Linux (portofolio saya bisa google dengan kata develinux) dan saya juga penulis proyek 11-bagian, saya secara teratur harus berurusan tidak hanya dengan membangun rakitan, tetapi juga dengan mengembangkan mekanisme pembaruan melalui WEB atau USB flash.
Dalam artikel ini saya ingin berbagi pengalaman dan pengetahuan saya di bidang yang relevan.
Persyaratan perakitan
Dalam proses pengembangan rakitan dan pembaruan untuk berbagai perangkat, saya mengidentifikasi beberapa persyaratan untuk diri saya sendiri:
- perakitan tidak boleh rusak ketika listrik tiba-tiba mati;
- perakitan harus dimuat dengan cepat;
- bootloader harus bekerja dengan sempurna;
- majelis harus mendukung pembaruan.
Saya akan mencoba menjelaskan persyaratan ini secara lebih rinci di bawah ini, dan setelah itu saya akan menjelaskan 3 pendekatan dalam pembagian gambar menjadi beberapa bagian dan pembaruannya.
Perakitan tidak boleh rusak saat listrik tiba-tiba mati.
Siapa yang butuh perangkat yang berhenti berfungsi setelah reboot kesepuluh? Kepada siapa pun! Jika Anda mengambil distribusi yang sudah jadi (dan ada sangat sedikit dari mereka untuk disematkan), maka tanpa file dari kotak mereka semua sangat tidak dapat diandalkan dalam hal ini. Saya ingat betul proyek tempat saya menggunakan ubuntu di bawah imx6, sistem file pada kartu rusak, kadang-kadang dari reboot kesepuluh, kadang-kadang dari keempat puluh, itu tergantung pada bintang-bintang di langit. Proyek ini menyelamatkan aufs FS. Faktanya adalah bahwa ubuntu tidak dirancang untuk dibaca hanya, dan itu harus selalu menulis sesuatu. Saya ingat situasi yang sama di proyek lain di mana yocto digunakan pada kartu SD. Secara umum, jadi perhatikan, kartu SD adalah jenis drive paling jelek yang paling cepat crash, jauh lebih andal daripada emmc dan nand. Jika Anda menggunakan kartu SD, disarankan untuk menulis sesedikit mungkin selama operasi, algoritma transfer latar belakang untuk sektor ini sangat tidak terduga, saya bekerja dengan puluhan kartu SD berbeda dari merek dunia dan tidak menemukan satu kartu pun yang bisa saya rekomendasikan.
Tetapi kartu SD memiliki beberapa keunggulan, harganya terjangkau, murah dan nyaman dalam perangkat lunak debugging.
Mengapa saya ... Dan, inilah masalahnya - root FS harus dibaca saja, seharusnya tidak ada entri di dalamnya selama operasi. Anda mungkin akan berpikir: bagaimana bisa begitu? Jutaan perangkat Android selalu menulis sesuatu dan tidak gagal. Benar, tetapi ini semua karena sebagian besar perangkat Android, pertama, memiliki baterai, dan kedua, FS root dibingkai sebagai ramdisk, dan partisi sistem dibaca hanya.
Jika sistem harus dapat diandalkan, maka segala macam hal dengan menginstal paket di root FS dapat merusak banyak. Saya merekomendasikan squashfs sebagai sistem file. Ini bekerja cepat, tidak bisa menulis apa pun, menghemat ruang karena kompresi ...
Tetapi bagaimana dengan menyimpan konfigurasi, mengunduh file, dll. kamu bertanya?
Tetapi untuk ini, Anda perlu membuat partisi RW terpisah. Jika Anda berencana untuk menulis di NAND, maka saya merekomendasikan opsi yang terbukti - UBIFS. Jika di NOR, maka jffs2. Jika saya menulis ke drive lain, saya sarankan ext4, btrfs, ReiserFS, saya tidak bisa menunjukkan FS terbaik di antara mereka, karena ada berbagai masalah dengan semua orang.
Dalam hal ini, selalu sebelum me-mount partisi rw, pastikan untuk memeriksa kesalahan partisi yang menggunakan utilitas fsck.
Perakitan harus dimuat dengan cepat
Kecepatan unduhan perangkat memengaruhi kegunaan keseluruhan. Dalam beberapa tugas, waktu pemuatan tidak lebih dari 30 detik, dalam beberapa, 5 menit diperbolehkan. Bagi saya sendiri, saya bekerja waktu hingga 1 menit, semakin sedikit semakin baik. Tunggu pengunduhan lebih dari satu menit terlalu lama, mungkin perangkatnya hang, jadi jika Anda dapat mengurangi waktu, maka lebih baik menggunakannya.
Bootloader harus berjalan dengan lancar
Loader adalah apa yang tidak akan dimulai tanpa perakitan. Baru-baru ini, saya sering mengamati bagaimana produsen papan tunggal memfasilitasi pengembangan dengan mengunggah demo untuk kartu SD dengan deskripsi cara mendaftarkan bootloader atau gambar selesai dengan bootloader, yang hanya diisi dengan perintah dd. Tetapi bagaimana jika kartu SD membeku? Hal yang sama tidak jarang terjadi. Secara pribadi, dalam latihan saya, kartu sering jatuh. Ini adalah bagaimana Anda bekerja dengan bayaran selama beberapa jam, Anda menulis perangkat lunak, tetapi dan itu semua ... kesalahan dalam kernel mulai mengalir, kartu jatuh. Tetapi bagaimana jika ini adalah perangkat yang harus bekerja di ladang tanpa me-reboot? Dan omong-omong, me-reboot termasuk watchdog tidak selalu menghidupkan kembali kartu yang hang, kartu tidak memiliki sinyal reset, ini bukan emmc, tentu saja ini lebih merupakan pertanyaan untuk sirkuit papan, jika papan memiliki reset kekuatan kartu, ini akan menghemat, tetapi ini tidak di mana-mana. Pada beberapa papan, hanya mendistorsi daya atau kartu yang membantu. Berdasarkan pengalaman saya, saya tidak merekomendasikan menyimpan bootloader pada drive dengan unit utama jika perekaman dilakukan pada drive selama operasi. Jika sistem tidak menulis apa pun ke drive dengan bootloader, dan ini jarang terjadi, maka silakan. Dalam pengalaman saya, dalam mode readonly, sistem file cacat hanya karena kesalahan perangkat keras, tetapi bukan kesalahan perangkat lunak.
Bootloader harus disimpan di tempat yang aman, pada drive yang andal, misalnya, dalam chip NOR atau EEPROM yang terpisah. Di bawah ini adalah contoh modul berdasarkan chip imx6ull, dengan SPI NOR untuk menyimpan bootloader.
Build harus mendukung peningkatan
Tanpa pembaruan, tidak ada tempat ... Saya berpartisipasi dalam banyak proyek dan tidak pernah mendapatkan perangkat lunak yang sempurna untuk pengiriman pekerjaan. Kesalahan selalu terdeteksi atau peningkatan fungsional diperlukan. Anda perlu memahami bahwa ketika orang menulis perangkat lunak, mereka akan membuat kesalahan, sementara orang menggunakan perangkat, mereka akan menginginkan lebih sedikit. Dalam 90% kasus, tidak adanya sistem pembaruan yang dipikirkan dengan matang dapat menyebabkan sakit kepala bagi pabrikan dan runtuhnya seluruh proyek. Misalnya, sistem pengawasan video telah dikembangkan untuk transportasi, sistem tersebut telah dipasang di seluruh Rusia, dan ternyata pemasar meremehkan pasar dan tidak menyediakan streaming, dan selain itu, beberapa kesalahan ditemukan dalam firmware, ditambah konsumen mulai melirik ke arah pesaing, karena mereka telah ada sesuatu yang tidak ada dalam perangkat yang dibeli ... Ya, ya, di stroberi taman aneh lebih enak dan cuacanya lebih baik (psikologi).
Apa yang harus dilakukan dalam situasi seperti itu? Jika pembaruan didukung, maka ada banyak solusi, kesalahan dapat diperbaiki, streaming siaran dapat ditingkatkan, dan fungsi dapat disesuaikan untuk konsumen, berikan konsumen firmware dengan instruksi dan hanya itu. Tetapi jika tidak didukung, maka pabrikan akan memiliki petualangan besar dengan perjalanan bisnis insinyur layanan hingga mengganti perangkat.
Sistem pembaruan pada perangkat harus dipikirkan dengan sangat detail dan diuji 100%. Satu kesalahan dalam bagian ini akan mengubah besi menjadi batu bata, jadi seharusnya tidak ada toleransi dan pengecualian.
Proses pembaruan harus tahan untuk mematikan daya, dan dalam kondisi apa pun tidak boleh merusak perangkat.
Ikhtisar pendekatan partisi untuk pembaruan di masa mendatang
Dari sekian banyak pendekatan saya dapat merekomendasikan 3 jenis yang saya implementasikan secara pribadi. Ini tidak semua pendekatan, ruang lingkup mereka berada di luar cakupan artikel ini. Ketiga jenis ini memiliki kekurangan dan jauh dari ideal, tetapi, menurut saya, mendekati rata-rata emas akal sehat.
Pendekatan No. 1
Cara termudah dan paling terjangkau:
Gambar diletakkan pada drive, misalnya kartu SD, yang di-flash dari u-boot ke drive internal perangkat, misalnya, NAND flash.
Di u-boot, Anda perlu menyiapkan skrip untuk ini.
Dari plus - ini adalah jenis pembaruan termudah, pengembangan yang akan memakan waktu maksimum 1 hari.
Kerugian dari pendekatan ini adalah kurangnya visualisasi proses dan kemampuan bootloader yang sangat terbatas, mis. tidak ada logika rumit dengan alat standar, kecuali tentu saja Anda datang dengan perintah u-boot Anda sendiri (tapi ini adalah jenis pembaruan lain, C adalah kekuatan besar). Metode ini tidak dimaksudkan untuk pembaruan melalui WEB - bermasalah untuk mengontrol integritas gambar firmware; dalam beberapa kasus, ukuran perakitan tidak boleh melebihi ukuran RAM.
Selain itu, dalam beberapa tugas diharuskan untuk menyimpan pengaturan selama peningkatan, dan ini, dengan pendekatan ini, tidak mudah untuk diterapkan.
Pendekatan No. 2
Metode yang paling dapat diandalkan dan dilindungi dari yang dipertimbangkan, tetapi yang paling sulit. Saya merekomendasikan metode ini untuk digunakan dalam pengembangan yang terutama bertanggung jawab, seperti Ini melindungi baik dari gambar yang rusak dan dari kerusakan fisik ke drive utama, karena sirkuit menggunakan yang tambahan.
Pendekatan ini menggunakan build minimal (ukuran ramdisk 8-16MB) dan yang utama. Ramdisk adalah arsip terkompresi, jadi build 16MB secara fisik akan beberapa kali lebih kecil.
Tujuan dari perakitan minimal adalah untuk mengevaluasi perakitan utama dan memuatnya.
Ramdisk di-host dengan skrip kernel dan u-boot dalam gambar FIT.
Mengapa gambar FIT dan apa fungsinya? Gambar FIT adalah format yang didukung oleh u-boot. Ini memastikan integritas semua komponen (kernel, dts, ramdisk, skrip). Membongkar gambar FIT dilakukan di u-boot, dan jika checksum tidak konvergen, u-boot akan menolak untuk memuatnya. Ini nyaman, mis. tidak perlu mengurus kontrol integritas sendiri, tidak perlu menulis beberapa file secara terpisah atau menciptakan gambar Anda sendiri, semuanya dilakukan oleh gambar FIT. Biasanya gambar FIT memakan waktu 7-20MB, itu harus ditulis ke drive terpisah yang sangat andal, misalnya, dalam qspi atau flash. Rakitan utama dapat disimpan dalam memori yang lebih murah dan tidak dapat diandalkan, misalnya, NAND flash. Karena pekerjaan utama akan berlangsung di perakitan utama, justru pekerjaan yang akan dirusak terlebih dahulu. Dalam hal ini, drive terpisah dengan rootf minimal akan datang untuk menyelamatkan.
Proses boot.
u-boot mengunduh skrip yang mencoba menggunakan pembaruan FIT (FIT2), dan kemudian firmware pabrik FIT (FIT1).
Jika FIT2 tidak ada atau integritasnya dilanggar, uji kecocokan akan gagal dan u-boot akan memuat FIT pertama (FIT1). Jika ada pembaruan FIT (FIT2), dan tidak rusak, maka ramdisknya dimuat yang memeriksa pembaruan rootfs (Rootfs2).
Jika Rootfs2 rusak, maka skrip akan menghapus pembaruan FIT (FIT2), kemudian setelah reboot gambar pabrik yang terdiri dari FIT (FIT1) dan Rootfs1 akan diunduh.
Perbarui proses.
Gambar pembaruan berisi FIT, rootfs, dan berbagai informasi perakitan, termasuk checksum dari semua komponennya. Informasi perakitan digunakan selama peningkatan untuk memantau integritas dan kompatibilitas.
Perbarui kemajuan dalam langkah-langkah:
- memeriksa gambar untuk kompatibilitas dengan perangkat keras dan perangkat lunak,
- memeriksa integritas gambar dalam file pembaruan,
- menyalin Rootfs2 dari file pembaruan ke bagian yang disiapkan sebelumnya,
- memeriksa integritas gambar yang disalin di bagian,
- salin FIT2 ke bagian yang sesuai,
- reboot
Jika proses gagal, tidak adanya atau kerusakan FIT2 tidak akan merusak sistem, seperti u-boot hanya akan menolak untuk menggunakannya dan memuat gambar pabrik. Oleh karena itu, selama peningkatan, integritas FIT2 tidak dicentang.
Setelah pembaruan, rakitan baru akan ditempatkan pada drive utama dalam bentuk FIT2 dan Rootfs2.
Metode ini tahan terhadap kerusakan mekanis pada drive dan kesalahan FS.
Jika terjadi kerusakan kritis, gambar pabrik akan mulai, tempat perangkat lunak pemulihan akan berfungsi, yang, misalnya, dapat memeriksa ulang NAND, mengunduh firmware dari jaringan menggunakan protokol SSH, dan kemudian merekamnya.
Saya memberi contoh saja pemulihan, ada banyak pilihan. Dalam pendekatan ini, proses pemulihan didorong oleh Linux penuh, yang dapat melakukan segalanya ... dan bukan bootloader seperti pada versi pertama.
Pendekatan No. 3
Jenis pembaruan ini digunakan di hampir semua proyek 11-bagian, karena telah bekerja dengan sangat baik.
Pembaruan ini cocok untuk semua ukuran perakitan, untuk semua jenis drive. Berbeda dengan tipe sebelumnya, di sini SPI NOR hanya digunakan untuk u-boot, oleh karena itu memiliki ukuran lebih kecil dan biaya lebih rendah, 1 MB sudah cukup.
Jenis pembaruan ini tidak memerlukan ramdisk yang terpisah, yang berarti bahwa waktu pemrograman disimpan untuk pengembangan dan dukungannya di masa mendatang.
Contohnya menggunakan drive kartu SD, tetapi juga bisa NAND menggunakan UBIFS, tidak ada perbedaan. Dalam pendekatan ini, tidak ada pemeriksaan RO Rootfs sebelum memuat, jika perakitan rusak, sistem tidak akan tahu bahwa itu rusak dan akan memuatnya dalam lingkaran. Di sini diasumsikan bahwa data di bagian RO tidak dapat diubah dengan cara apa pun, pendekatan ini menghilangkan kerusakan fisik drive. Jika drive tidak sehat secara fisik, maka perangkat harus dibawa ke pusat layanan, tidak ada penyembuhan diri yang disediakan. Ini adalah harga yang harus Anda bayar untuk meningkatkan kecepatan pengembangan, dukungan lebih murah dan basis elemen lebih murah, tetapi itu dibenarkan. Mengapa mengasuransikan sesuatu yang hampir tidak pernah terjadi.
Logika untuk mengunduh dan memperbarui sama seperti pada pendekatan sebelumnya.
Dalam hal pemuatan, u-boot pertama kali mengunduh pembaruan FIT (FIT2), jika tidak ada atau integritas dilanggar, u-boot memuat FIT pertama (FIT1), rakitan yang dijahit di pabrik dimulai, dan seterusnya hingga sistem diperbarui. Ketika sistem diperbarui, FIT2 dan Rootfs2 akan muncul. Dalam hal ini, saat perangkat melakukan boot, pembaruan FIT (FIT2) dimulai terlebih dahulu. Dalam skrip u-boot yang disimpan di setiap FIT, harus ditulis rootfs mana yang akan dipasang.
Partisi bersama RW
Pada bagan, ada blok partisi bersama di mana-mana, ini adalah sekelompok bagian untuk ditulis. Entri dibuat hanya di sana. Partisi bersama ditampilkan sebagai satu partisi untuk kejelasan. Sebenarnya, ada 3 di antaranya: dua kecil untuk konfigurasi yang bekerja di cermin, dan satu besar untuk yang lainnya. Selain itu, saya sarankan Anda menyimpan beberapa konfigurasi saat memperbarui, yang nyaman, misalnya, jika Anda mengkonfigurasi jaringan dan meningkatkan, Anda tidak perlu mengkonfigurasi ulang pengaturan jaringan.
Untuk meringkas
Artikel ini membahas tiga jenis majelis dengan dukungan untuk pembaruan, semua diperiksa oleh saya pribadi, Anda dapat menggunakannya dengan aman di proyek-proyek.
Saat ini, saya hanya menggunakan dua yang terakhir, karena paling cocok untuk persyaratan. Untuk kejelasan, Anda dapat melihat contoh perangkat di mana jenis pembaruan ini digunakan (detail dalam portofolio 11-bagian):
- Repeater RS485 melalui 4G / WiFi / LAN,
- Papan Kontrol Pengendali Tampilan Industri 4K V-By-One,
- sistem kontrol iklim hanggar terintegrasi,
- Pengontrol video tampilan industri 2DisplayPort-LVDS,
- sistem kontrol garis
- Gerbang VPN.
Jika artikel saya bermanfaat dan menarik, saya siap untuk membagikan pengalaman saya dan solusi teknis yang telah terbukti di bidang embedded linux di situs ini.
Terima kasih semuanya.
Gorchakov Ilya
telegram:
develinux