Для чого нам потрібен завантажувач окремо від нашої прикладної програми в мікроконтролерах?

Навіщо нам потрібна окрема програма в одній пам'яті флеш-програми мікроконтролера, зокрема STM32F103, яку називають завантажувачем?

Що в ньому особливого, щоб він не був відокремлений від основної прикладної програми?

Взагалі кажучи, чи завантажувач мікропроцесорної системи (скажімо, PowerPC MPC8270) виконує таку ж роботу, як і мікроконтролера (скажімо, ARM STM32F103), або вони роблять принципово різні роботи один від одного, і все ж обидва називають "завантажувачем" ?

Завантаження завантажувача на мікроконтролері відповідає за оновлення основної мікропрограми через канал зв'язку, окрім заголовка програмування. Це корисно для оновлення мікропрограмного забезпечення в полі над BLE, UART, I2C, SD-картами, USB і т. Д. Буде вкрай незручно вимагати від клієнтів придбання програмістів просто для оновлення програмного забезпечення на своїх пристроях.

Причина, по якій завантажувач тримається окремо, полягає в надійності. Завантажувач і код програми розміщуються в окремих розділах спалаху, так що код програми може бути стертий та переписаний завантажувачем, не змінюючи нічого, що стосується коду завантажувача.

Якщо завантажувач і додаток зберігалися разом, код завантажувача потрібно буде скопіювати до оперативної пам’яті, перш ніж він міг працювати, оскільки будь-яке оновлення мікропрограмного забезпечення видалить код завантажувача миттєво. Якби живлення було вимкнено за допомогою коду завантажувача в оперативній пам’яті, а спалах стирався, пристрій було б цегляним.

1. Так що процес завантаження може відновитись після помилок. Припустимо, під час оновлення є помилка зв'язку або відключається живлення. Якщо завантажувач був частиною програми, яку ви оновлювали, користувач не міг би повторити спробу, не використовуючи спеціальне обладнання для перезавантаження на завантажувач.

2. Деякі мікроконтролери не можуть виконати код з оперативної пам'яті. Якщо завантажувач змішався з іншим програмним забезпеченням, то ви насправді не зможете оновити своє програмне забезпечення, оскільки ви не можете стерти сторінки з флеш-пам’яті, з яких ви зараз виконуєтесь. Робота полягає в тому, щоб спочатку записати новий код на другу половину спалаху, а потім перейти до нього. Потім новий код копіює себе на першу половину спалаху. Звичайно, недоліком є ​​те, що спалювання спалаху зазвичай повільне, і тепер, коли вам доведеться це зробити вдвічі, процес завантаження може зайняти до двох разів довше. Також цей обхід обмежує розмір програми не більше половини від загальної кількості спалаху.

3. Добре написані завантажувачі намагаються перевірити, чи дійсний код існує на пристрої, перш ніж намагатися його виконати. Якщо завантажувач та інший код змішалися разом, то як ви могли бути впевнені, що ваша програма перевірки спрацює, якщо весь код не завантажиться?

4. Аутентифікація. Захищені завантажувачі намагаються перед виконанням перевірити, чи відповідає завантажений додаток цифровому підпису. Але якщо завантажувач та інший код були змішані разом, то ви не можете контролювати, що працює на пристрої, оскільки, як тільки користувач завантажує новий код, ви не можете контролювати, що відбувається при запуску.

Вони, як правило, знаходяться там, щоб дозволити оновити свою основну прикладну програму.

Вам потрібен код, який знає, як стерти і перепрограмувати частину внутрішньої спалаху, яка не може бути основною програмою, оскільки коли вона сама буде стерта, вона не зможе перепрограмувати.

Завантажувач дозволяє MCU спілкуватися з чимось іншим, щоб прийняти нову програму, зберегти її та запустити її після скидання. Якщо у вас не було завантажувача, то для доступу до пам'яті та встановлення програми потрібен програміст.

На додаток до інших правильних відповідей про те, що дозволяють перепрограмувати основну прошивку з завантажувача, ще однією перевагою того, що завантажувач буде окремим, є те, що ви можете логічно відокремити завдання "зробити один раз під час завантаження" від коду, який вам потрібен під час виконання. Потім, після того, як завантажувач закінчить свої початкові завдання конфігурації, основна вбудована програма може вивезти завантажувач із усім його вже не потрібним кодом із пам'яті, заощадивши значну кількість оперативної пам’яті. Цього можна досягти і іншими способами, але розділення завантажувача / вбудованого програмного забезпечення значно полегшує роботу багатьох архітектур.

Коротка відповідь, тому що програмне забезпечення є приголомшливим.

Ви можете мати все, що завантажувач - це "чисте обладнання". Але набагато простіше, щоб завдання завантажувача були записані як програмне забезпечення, а потім інтерпретувалися апаратними засобами.

Ці завдання можуть передбачати налаштування апаратного забезпечення для "справжнього" програмного забезпечення для запуску (наприклад, на Raspberry Pi (через @ErikF)), мати протокол для заміни "справжньої" програми перед її запуском (перевірити шпильку, якщо цей штифт встановлюється потім перепрошивати реальну програму) або навіть налаштовувати програмне середовище для "реальної" програми.

У меншому масштабі програмного забезпечення, коли ви запускаєте виконувану програму, програма для переміщення завантажувача додатків робить такі речі, як завантаження частин даних у пам'ять, іноді виправляє адреси, налаштовує аргументи до основних чи інших глобальних речей, створює бібліотеки, надані вашою ОС, та потім переходить до початку _mainкоду. Деякі з цих речей можна виконати завантажувачем.

У мікроконтролері деякі завдання, які виконує завантажувач, можуть бути розділені на програму. Компілятор для вашої платформи може автоматично ввести код "установки" у кожен виконуваний файл.

Але наявність його в завантажувальному пристрої означає, що той самий компілятор може працювати на різних апаратних засобах, оскільки завантажувач може "приховати" різницю між платформами.

Крім того, що спалах основної програми не ризикує завантажувачем (і можливістю перепромінювати основну програму), а мати нетривіальний завантажувач - це дуже чудова річ.

Одна з відповідей, яка не була висвітлена, - це необхідність відокремлення проблем через обмеження мови С.

Зазвичай завантажувачі записуються в суміші Асамблеї та С, з дуже ранньою стадією завантаження в Асамблеї.

Це робиться для налаштування певних речей, таких як:

• виділення C стека
• зчитування покажчика стека в регістр
• зчитування лічильника програм в реєстр
• оголошення векторів скидання
• завантаження другого ступеня (initramfs) в оперативну пам'ять.

Це дуже приблизне наближення до кроків, які я робив, і я описую процес завантаження ARM, він знову відрізняється для x86 та інших архітектур.

Однак принципова причина залишається тією ж: розподіл стеку C потрібно робити з монтажу.

Однією з питань, на яку поки не відповіли, є різниця між завантажувачами на мікроконтролерах та мікропроцесорними системами.

Мікроконтролер

Більшість мікроконтролерів мають вбудовану пам'ять ПЗУ, яка містить код програми. Для зміни цього коду зазвичай потрібен пристрій програміста, який підключається до інтерфейсу програмування мікроконтролера (наприклад, ISP на ATMega). Але такі інтерфейси програмування зазвичай часто не дуже зручні у використанні, порівняно з іншими інтерфейсами, оскільки вони можуть бути недоступними у заданому контексті. Наприклад, хоча майже на кожному комп'ютері є порти USB, інтерфейс SPI, необхідний для провайдера, набагато рідше, а інші інтерфейси, такі як PID-інтерфейс, що використовується в ATXMega, підтримуються лише спеціальним програмним забезпеченням.

Так, наприклад, якщо ви хочете оновити програмне забезпечення зі звичайного комп'ютера без зовнішнього обладнання, ви можете використовувати завантажувач, який читає з іншого типу інтерфейсу (наприклад, RS232, USB або RS232 через USB, як на Arduino) для програмування пристрою через загальні інтерфейси.

Однак, якщо вам не потрібна ця функція, завантажувач абсолютно не є обов'язковим. Мікроконтролер все ще може запустити його код повністю без завантажувача.

Мікропроцесор

На мікропроцесорі все трохи інакше. Хоча більшість мікропроцесорів оснащено ПЗУ, який є достатньо великим для завантажувача, ці ПЗУ недостатньо великі, щоб вмістити повну ОС. Таким чином, мета завантажувача - ініціалізувати обладнання, шукати завантажувальну ОС, завантажувати її та запускати її. Тому завантажувач є критичним для кожного завантаження.

У системах x86 / x64 цей завантажувач завантажень є або BIOS, або UEFI (в основному це новіша версія BIOS).

Іноді у вас навіть є кілька завантажувачів, що працюють в ланцюзі. Наприклад, якщо у вас є система з подвійним завантаженням у Windows та Linux, ви можете отримати таке:

• BIOS / UEFI завантажується і знаходить встановлений GRUB. Потім він завантажує GRUB (= Grand Unified Bootloader)
• GRUB знаходить якийсь Linux та завантажувач Windows. Користувач вибирає завантажувач Windows.
• Запускається завантажувач Windows і знаходить встановлені Windows 7 та Windows 10. Користувач вибирає Windows 10.
• Нарешті, Windows 10 завантажується.

Тож у цьому випадку було три програми, які можна вважати завантажувачем. І GRUB, і завантажувач Windows в основному є, щоб дати користувачеві більш зручний варіант вибору завантаження, ніж BIOS / UEFI. Він також дозволяє запустити декілька ОС з одного жорсткого диска або навіть одного і того ж розділу.

TLDR

Тож як в обох системах завантажувач робить щось подібне (допомагаючи користувачеві вибрати, який код для завантаження), вони обидва сильно відрізняються тим, як вони це роблять і що саме роблять.