In-line срещу offline
В Energetika-VDS флашването на фърмуер става на нашата линия чрез специализирани програмиращи fixture-и. Когато test plan-ът на клиента изисква функционален тест, устройството преминава към партньорска тестова къща с вече зареден фърмуер. AOI работи вътрешно на всяка платка; FCT се аутсорсва.
Някои производители обединяват флашването в същия fixture като функционалния тест, така че платката се поставя веднъж и програмирането върви първо, после тестът. Това работи, когато и двете стъпки са в една сграда. В нашия setup флашването и FCT са физически разделени: ние пускаме флашването in-line, а партньорската тестова къща изпълнява функционалната последователност срещу току-що програмирания фърмуер.
За продукти без функционален тест в обхвата, флашната платка се изпраща след AOI без допълнителен тестов гейт.
Интерфейси за програмиране
Интерфейсът към чипа варира според семейството чипове:
- SWD: ARM Cortex-M, нисък брой пинове, бърз
- JTAG: стар ARM, FPGA, също debug за много чипове
- UART: програмиране базирано на bootloader, по-бавно, но без нужда от допълнителни пинове
- USB-DFU: USB-способни чипове, платката действа като USB устройство по време на програмирането
- I2C, SPI: по-рядко срещани, използвани за някои EEPROM и secure elements
Повечето производствени флашове използват SWD за ARM Cortex-M устройства и JTAG за по-стари или с по-висок брой пинове части.
Програмиране на множество образи
Свързано устройство обикновено има повече от един образ на фърмуера:
- Bootloader: малък, подписан, неизменим след производство
- Application: основен фърмуер, актуализируем по OTA
- Файлова система: конфигурация, web assets, certificate store
- Производствен дял: калибриране на всеки бр, идентичност, заводски данни
Програмирането от страна на производството записва всеки образ последователно, в правилния дял, с правилното подписване, ако е приложимо.
Вериги с подписан bootloader
Подписаният bootloader проверява подписа на приложението, преди да го стартира. Самият bootloader е подписан от secure boot механизма на чипа (хеш съхранен в eFuse, ROM-базирана проверка).
Резултат: атакуващият не може да замени приложението с произволен код, защото bootloader-ът ще откаже да го стартира. Атакуващият не може да замени bootloader-а, защото чипът ще откаже да стартира неподписан bootloader.
От страна на производството това означава:
- Ключът за подписване на bootloader е генериран и съхранен в HSM
- Ключът за подписване на приложението е генериран и съхранен в HSM
- Производствената линия достъпва подписването през API, никога не държи частния ключ
- eFuse е изгорен, за да заключи подписа на bootloader на място
Толерантност към загуба на захранване
Последователностите за програмиране трябва да толерират загуба на захранване по средата на флашването. Често срещан шаблон: запис на bootloader първи на фиксирана локация, запис на приложението в отделен регион, задаване на флаг "valid" в NVS само след проверка. Ако захранването падне по време на запис, bootloader-ът вижда липсващия флаг valid и се връща към известен добър фърмуер (или отказва да стартира, в зависимост от политиката).
Проверка
След запис, прочетете обратно флашнатия образ и изчислете неговия хеш. Сравнете с очаквания хеш. Ако се различава, маркирайте устройството като неуспех на флашването и маршрутизирайте за rework.
Това улавя редкия случай, в който самият запис е успял, но чипът е записал боклук.
Логване на всеки бр
След успешен флаш, логнете:
- Версия на фърмуера
- Хеш на фърмуера
- Референция на подписващия ключ
- Времеви маркер на програмирането
- Сериен номер на всеки бр
Тези данни живеят в производствената база данни за проследяемост. Купувачът може да направи заявка по-късно: "какъв фърмуер е изпратен на сериен XXX, подписан с кой ключ".