Apa itu boot loader, dan bagaimana saya mengembangkannya?


53

Saya sudah bertemu banyak proyek di mana mikrokontroler AVR menggunakan dengan bootloader (seperti Arduino), tapi saya tidak mengerti konsepnya dengan sangat baik.

Bagaimana saya bisa membuat bootloader (untuk mikrokontroler apa saja)?

Setelah menulis bootloader saya, bagaimana programnya diprogram ke mikrokontroler (seperti program .hex yang dibakar di flash rom AVR, atau metode lain)?


10
Anda memberi tag dengan tag bootloader , apakah Anda membacanya? Jika demikian, apakah Anda membaca Arduino Bootloader , Arduino Bootloader Follow On , Arduino Bootloader , Alat atau metode yang baik untuk memahami struktur bootloader , dan pertanyaan Arduino Bootloader Details ? Itu semua membahas bagian dari pertanyaan awal Anda. Saya sudah memangkasnya ke hal-hal baru.
Kevin Vermeer

Sebuah makalah tentang metode Desain BootLoader
yahya tawil

2
@KevinVermeer Saya pikir pertanyaannya lebih mudah.
richieqianle

Jawaban:


103

Bootloader adalah program yang berjalan di mikrokontroler untuk diprogram. Ia menerima informasi program baru secara eksternal melalui beberapa sarana komunikasi dan menulis informasi itu ke memori program prosesor.

Ini berbeda dengan cara normal memasukkan program ke dalam mikrokontroler, yaitu melalui perangkat keras khusus yang dibangun ke dalam mikro untuk tujuan itu. Pada PIC, ini adalah antarmuka seperti SPI. Jika saya ingat benar, AVR menggunakan Jtag, atau setidaknya beberapa dari mereka melakukannya. Either way, ini memerlukan beberapa perangkat keras eksternal yang menggoyangkan pin pemrograman tepat untuk menulis informasi ke dalam memori program. File HEX yang menggambarkan konten memori program berasal dari komputer tujuan umum, jadi perangkat keras ini terhubung ke komputer di satu sisi dan pin pemrograman khusus mikro di sisi lain. Perusahaan saya membuat programmer PIC antara lain sebagai sampingan, jadi saya cukup akrab dengan proses ini pada PICs.

Poin penting dari pemrograman eksternal melalui perangkat keras khusus adalah ia berfungsi terlepas dari isi memori program yang ada. Mikrokontroler memulai dengan memori program terhapus atau dalam keadaan tidak dikenal, sehingga pemrograman eksternal adalah satu-satunya cara untuk membuat program pertama menjadi mikro.

Jika Anda yakin tentang program yang ingin Anda muat ke dalam produk Anda dan volume Anda cukup tinggi, Anda dapat meminta pabrikan atau distributor program chip untuk Anda. Chip disolder ke papan seperti chip lainnya, dan unit siap untuk pergi. Ini bisa cocok untuk sesuatu seperti mainan, misalnya. Setelah firmware selesai, cukup banyak dilakukan, dan akan diproduksi dalam volume besar.

Jika volume Anda lebih rendah, atau yang lebih penting, Anda mengharapkan pengembangan firmware dan perbaikan bug yang sedang berlangsung, Anda tidak ingin membeli chip yang sudah diprogram. Dalam hal ini chip kosong dipasang di papan tulis dan firmware harus dimuat ke chip sebagai bagian dari proses produksi. Dalam hal ini jalur pemrograman perangkat keras harus tersedia entah bagaimana. Ini bisa melalui konektor eksplisit, atau bantalan pin pogo jika Anda bersedia membuat fixture uji produksi. Seringkali produk tersebut harus diuji dan mungkin dikalibrasi pula, sehingga biaya tambahan penulisan program ke prosesor biasanya minimal. Terkadang saat prosesor kecil digunakan, firmware uji produksi khusus pertama kali dimuat ke dalam prosesor. Ini digunakan untuk memfasilitasi pengujian dan kalibrasi unit, maka firmware yang sebenarnya dimuat setelah perangkat keras dikenal baik. Dalam hal ini ada beberapa pertimbangan desain sirkuit untuk memungkinkan akses ke jalur pemrograman cukup untuk proses pemrograman untuk bekerja tetapi juga tidak terlalu merepotkan sirkuit. Untuk detail lebih lanjut tentang ini, lihat mypenulisan pemrograman dalam sirkuit .

Sejauh ini bagus, dan tidak perlu bootloader. Namun, pertimbangkan sebuah produk dengan firmware yang relatif kompleks yang Anda inginkan dapat diperbarui di lapangan atau bahkan memungkinkan pelanggan akhir untuk meningkatkan. Anda tidak dapat mengharapkan pelanggan akhir untuk memiliki gadget pemrogram, atau tahu cara menggunakannya dengan benar bahkan jika Anda menyediakannya. Sebenarnya salah satu pelanggan saya melakukan ini. Jika Anda membeli opsi penyesuaian bidang khusus mereka, Anda mendapatkan salah satu programmer saya dengan produk.

Namun, dalam kebanyakan kasus Anda hanya ingin pelanggan menjalankan program pada PC dan memperbarui firmware secara ajaib. Di sinilah bootloader masuk, terutama jika produk Anda sudah memiliki port komunikasi yang dapat dengan mudah berinteraksi dengan PC, seperti USB, RS-232, atau ethernet. Pelanggan menjalankan program PC yang berbicara dengan bootloader yang sudah ada dalam mikro. Ini mengirimkan biner baru ke bootloader, yang menuliskannya ke memori program dan kemudian menyebabkan kode baru dijalankan.

Kedengarannya sederhana, tetapi tidak, setidaknya tidak jika Anda ingin proses ini menjadi kuat. Bagaimana jika kesalahan komunikasi terjadi dan firmware baru rusak pada saat ia tiba di bootloader? Bagaimana jika daya terputus selama proses boot? Bagaimana jika bootloader memiliki bug dan craps sendiri?

Skenario sederhana adalah bahwa bootloader selalu berjalan dari reset. Mencoba berkomunikasi dengan tuan rumah. Jika tuan rumah merespons, maka ia memberi tahu bootloader bahwa tidak ada yang baru, atau mengirimkannya kode baru. Ketika kode baru tiba, kode lama ditimpa. Anda selalu menyertakan checksum dengan kode yang diunggah, sehingga bootloader dapat mengetahui apakah aplikasi baru itu utuh. Jika tidak, ia tetap berada di bootloader secara konstan meminta unggahan sampai sesuatu dengan checksum yang valid dimuat ke dalam memori. Ini mungkin dapat diterima untuk perangkat yang selalu terhubung dan mungkin di mana tugas latar belakang dijalankan pada host yang menanggapi permintaan bootloader. Skema ini tidak baik untuk unit yang sebagian besar otonom dan hanya sesekali terhubung ke komputer host.

Biasanya bootloader sederhana seperti dijelaskan di atas tidak dapat diterima karena tidak ada kegagalan yang aman. Jika gambar aplikasi baru tidak diterima secara utuh, Anda ingin perangkat melanjutkan menjalankan gambar yang lama, tidak mati sampai unggahan yang berhasil dilakukan. Untuk alasan ini, biasanya sebenarnya ada dua modul khusus dalam firmware, pengunggah dan bootloader. Pengunggah adalah bagian dari aplikasi utama. Sebagai bagian dari komunikasi reguler dengan tuan rumah, gambar aplikasi baru dapat diunggah. Ini membutuhkan memori terpisah dari gambar aplikasi utama, seperti EEPROM eksternal atau menggunakan prosesor yang lebih besar sehingga setengah ruang memori program dapat dialokasikan untuk menyimpan gambar aplikasi baru. Pengunggah hanya menulis gambar aplikasi baru yang diterima di suatu tempat, tetapi tidak menjalankannya. Ketika prosesor diatur ulang, yang bisa terjadi atas perintah dari tuan rumah setelah unggahan, bootloader berjalan. Ini sekarang adalah program yang sepenuhnya mandiri yang tidak memerlukan kemampuan komunikasi eksternal. Ini membandingkan versi aplikasi saat ini dan yang diunggah, memeriksa checksum mereka, dan menyalin gambar baru ke area aplikasi jika versi berbeda dan memeriksa checksum gambar baru. Jika gambar baru rusak, itu hanya menjalankan aplikasi lama seperti sebelumnya.

Saya telah melakukan banyak bootloader, dan tidak ada dua yang sama. Tidak ada bootloader serba guna, terlepas dari apa yang ingin Anda percayai oleh beberapa perusahaan mikrokontroler. Setiap perangkat memiliki persyaratan dan keadaan khusus dalam berurusan dengan tuan rumah. Berikut adalah beberapa konfigurasi bootloader dan terkadang pengunggah yang saya gunakan:

  1. Bootloader dasar. Perangkat ini memiliki saluran serial dan akan terhubung ke host dan dihidupkan sesuai kebutuhan. Bootloader dijalankan dari reset dan mengirim beberapa respons permintaan unggah ke host. Jika program unggahan berjalan, itu akan merespons dan mengirim gambar aplikasi baru. Jika tidak merespons dalam waktu 500 ms, bootloader akan menyerah dan menjalankan aplikasi yang ada. Untuk memperbarui firmware, Anda harus menjalankan aplikasi pembaru pada host terlebih dahulu, kemudian sambungkan dan nyalakan perangkat.

  2. Pengunggah memori program. Di sini kami menggunakan ukuran berikutnya PIC yang memiliki memori program dua kali lebih banyak. Memori program secara kasar dibagi menjadi 49% aplikasi utama, 49% gambar aplikasi baru, dan 2% bootloader. Bootloader akan dijalankan dari reset dan menyalin gambar aplikasi baru ke gambar aplikasi saat ini dalam kondisi yang tepat.

  3. Gambar EEPROM eksternal. Seperti # 2 kecuali bahwa EEPROM eksternal digunakan untuk menyimpan gambar aplikasi baru. Dalam hal ini prosesor dengan memori lebih besar juga akan secara fisik lebih besar dan di sub-keluarga yang berbeda yang tidak memiliki campuran periferal yang kami butuhkan.

  4. TCP bootloader. Ini adalah yang paling kompleks dari semuanya. PIC 18F besar digunakan. 1/4 memori terakhir memegang bootloader, yang memiliki salinan lengkap sendiri dari tumpukan jaringan TCP. Bootloader dijalankan dari reset dan mencoba untuk terhubung ke server unggah khusus di port yang dikenal di alamat IP yang sebelumnya dikonfigurasi. Ini untuk instalasi besar di mana selalu ada mesin server khusus untuk seluruh sistem. Setiap perangkat kecil akan check-in dengan server unggah setelah reset dan akan diberikan salinan aplikasi baru yang sesuai. Bootloader akan menimpa aplikasi yang ada dengan salinan baru, tetapi hanya menjalankannya jika checksum diperiksa. Jika tidak, itu akan kembali ke server unggah dan coba lagi.

    Karena bootloader itu sendiri merupakan bagian rumit dari kode yang berisi tumpukan jaringan TCP penuh, itu juga harus dapat diupgrade. Cara kami melakukannya adalah agar server unggah memasukkannya ke aplikasi khusus yang tujuannya hanya untuk menimpa bootloader setelah dieksekusi, lalu mengatur ulang mesin sehingga bootloader baru akan berjalan, yang akan menyebabkan server unggah mengirim gambar aplikasi utama terbaru. Secara teknis kesalahan daya selama beberapa milidetik diperlukan aplikasi khusus untuk menyalin gambar baru dari bootloader akan menjadi kegagalan yang tidak dapat dipulihkan. Dalam praktiknya ini tidak pernah terjadi. Kami baik-baik saja dengan kemungkinan yang sangat kecil karena perangkat ini adalah bagian dari instalasi besar di mana sudah ada orang yang akan melakukan perawatan pada sistem, yang terkadang berarti mengganti perangkat yang disematkan untuk alasan lain.

Semoga Anda dapat melihat bahwa ada sejumlah kemungkinan lain, masing-masing dengan pengorbanan risiko, kecepatan, biaya, kemudahan penggunaan, waktu henti, dll.


1
Semua AVR kecuali keluarga Xmega (yang memiliki antarmuka 2-kawat baru) menggunakan antarmuka SPI sambil tetap disetel ulang. Yang lebih besar juga memiliki JTAG, beberapa memiliki pemrograman paralel, dan yang lebih kecil mungkin memerlukan tegangan tinggi jika reset telah dikonfigurasi ulang sebagai I / O. Beberapa MCU, seperti Parallax Propeller dan keluarga Motorola / Freescale 68HC08, tidak memiliki perangkat keras pemrograman minimal tetapi bootloader dalam ROM.
Yann Vernier

Ini membandingkan versi aplikasi saat ini dan yang diunggah, memeriksa checksum mereka, dan menyalin gambar baru ke area aplikasi jika versi berbeda dan memeriksa checksum gambar baru. Ya tetapi bagaimana jika daya terputus di tengah tindakan ini, akan ada gambar yang rusak di "area aplikasi". Saya kira mungkin lebih baik memiliki aplikasi bootloader -ailsafe-yang menulis aplikasi baru di mcu flash dan jika checksum valid, ia juga menulis di suatu tempat "ok untuk mem-boot aplikasi baru". Jadi pada awalnya, ia memeriksa apakah boleh mem-boot aplikasi baru, jika tidak terus mengeksekusi sendiri (aplikasi yang gagal)
Ervadac

@ Er: Jika daya gagal di tengah menyalin versi baru ke arus, maka versi checksum saat ini akan gagal ketika daya kembali dan bootloader berjalan lagi. Saya biasanya meletakkan kata checksum di bagian paling akhir gambar sehingga setiap tulisan parsial memiliki peluang kegagalan checksum yang sangat baik.
Olin Lathrop

Hai. Saya dapat merekomendasikan Anda tipe bootloader 5 - alih-alih TCP stack, Anda dapat mengimplementasikan UDP. Kemudian gunakan TFTP untuk mengunduh pembaruan atau protokol asli.
i486

22

Apa konsep dari bootloader?

Bayangkan skenario ini: Anda memiliki cukup banyak penyimpanan di mikrokontroler Anda - cukup untuk menyimpan lebih dari 2-3 program atau aplikasi yang tidak tergantung satu sama lain. Misalkan ketika Anda mem-boot perangkat Anda, Anda mungkin ingin dapat memilih yang mana yang akan dijalankan. Jadi, apa yang Anda perlukan untuk mendukung ini? Anda akan memerlukan program awal yang kemudian memungkinkan Anda memilih di antara yang lain saat boot.

Bagaimana itu bekerja?

Bootloader adalah program itu - ini adalah hal pertama yang dijalankan dan dapat memuat aplikasi lain ke tempat-tempat tertentu dalam memori (baik persisten seperti FLASH, atau volatile seperti RAM) dan kemudian melompat ke program yang diinginkan di mana ia kemudian akan mengambil alih eksekusi dari sana .

Bagaimana cara membuat avr bootloader (atau untuk mikrokontroler apa saja)?

Saya belum pernah membuat bootloader tetapi ini adalah bagaimana saya pikir saya akan melakukannya: mulai menulis program firmware seperti biasanya - tetapi pastikan itu diletakkan di area sedemikian rupa sehingga selalu menjadi hal pertama yang dijalankan ketika perangkat melakukan boot. Di luar kepala saya, beberapa fungsi yang saya inginkan dari program kecil ini: kemampuan untuk mengunggah program baru ke tempat yang tersedia di memori, menghapus program yang diunggah sebelumnya, memilih program mana yang akan dijalankan (jika ada lebih dari satu), dan memiliki semacam struktur data penyimpanan (tabel loncatan yang dapat tumbuh?) untuk dapat mengingat di mana program lain berada dan melompat ke sana. Interaksi dapat dilakukan melalui UART di mana ia dapat menyajikan Anda menu terminal yang sangat sederhana dan kemampuan untuk mengunggah firmware melalui saluran yang sama.

Bagaimana ini diprogram ke mikrokontroler (seperti program .hex apa pun yang dibakar pada flash rom dari avr, atau metode lain)?

Jika itu adalah chip yang benar-benar kosong tanpa bootloader yang ada yang dapat memperbarui sendiri, maka Anda perlu membakar ke FLASH seperti yang Anda jelaskan menggunakan teknik apa pun yang diperlukan untuk mencapai itu (ICSP dalam kasus AVR).

Ini sama sekali tidak komprehensif tentang apa "bootloader" itu. Bergantung pada apa yang Anda inginkan dari satu atau sistem yang dirancang untuk Anda, Anda dapat merancang satu untuk mengunggah barang ke lokasi yang ditentukan dalam RAM alih-alih FLASH, dan memulai eksekusi di setiap lokasi memori sewenang-wenang. Atau mungkin Anda menginginkan yang mampu memilih sistem operasi mana yang akan dimuat ketika PC Anda boot (lihat grub misalnya). Bootloader untuk mikrokontroler 8-bit cenderung sangat sederhana.

Catatan tentang Arduino: Bootloader ini hanya mengelola satu program AFAIK, juga mengambil alih port serial untuk mengelola pengunggahan firmware dan hal-hal lainnya .


FYI, jawaban ditulis untuk mengatasi poin-poin asli yang sekarang telah diedit.
Jon L

3

Konsep "boot" loader mirip dengan konsep "priming" pompa. Dengan kata lain, Anda perlu "sesuatu" yang memuat program ke alamat yang diberikan dan kemudian mulai menjalankan program di alamat yang diberikan. Sesuatu itu, adalah boot loader. Dalam kasus paling sederhana, boot loader "muncul" di alamat awal yang ditentukan CPU (nol, kemungkinan besar), memuat program ke segmen memori yang diperlukan, mentransfer kontrol ke sana, dan "menghilang." Tampilan dan penghilangan dikendalikan oleh perangkat keras "eksternal". Salah satu kemungkinan implementasi adalah dengan menggunakan ROM yang diaktifkan melalui reset "perangkat keras", dan dinonaktifkan dengan reset "perangkat lunak". Pemuat dalam ROM dapat sesederhana atau serumit yang dibutuhkan, dan perlu ditulis dalam bentuk biner yang dimengerti oleh CPU tertentu. Jika ruang alamat yang digunakan oleh ROM tidak diperlukan, penonaktifan ROM tidak akan diperlukan. Jelas, EEPROM, ePROM, flash PROM, dll. Dapat digunakan sebagai pengganti ROM.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.