В процессе серийного производства электронных устройств следующим этапом после монтажа печатных плат является стенд серийной прошивки и тестирования. На нем производится прошивка микроконтроллера/микропроцессора, запуск платы и ее проверка в том или ином объеме. Естественно, как и монтаж плат, работа стенда также должна быть мах автоматизирована. В крайнем случае, ручные операции, от которых не удалось избавиться, должны быть предельно просты, интуитивно понятны и монотонны. В статье описывается процесс разработки подобного стенда под микропроцессор IMX6ULL. В конце приводится ссылка на исходный код стенда, который может быть адаптирован под другие семейства микропроцессоров с архитектурой ARM. Итак, в процессе работы с отладочной платой мы более-менее убедились в том, что выбранный микропроцессор нас более-менее устраивает, - нужные интерфейсы поддерживаются, быстродействия хватает и появилось понимание примерного размера финальной прошивки. Останавливаем свой выбор на данном процессоре. Пора приступать к разработке печатной платы. Среди прочих требований к плате нужно продумать решение трех вопросов: где будет храниться образ ядра Linux (прошивка, image):  SPI флеш, NAND флеш, microSD карта или еще что-либо; как эта прошивка будет поставляться в серийно выпускаемые изделия; как будет задаваться загрузочный интерфейс процессора; Варианты ответов на каждый вопрос: Проще всего использовать microSD карту. В этом случае вам нужно лишь подготовить N-ное количество microSD карт с образом ядра вставить их во все изготовленные устройства. Но такой способ может не подойти, если: необходимо разработать устройство в индустриальном исполнении (рабочие температуры от -40 С); вы хотите осложнить доступ к прошивке устройства; устройство может подвергаться вибрациям; у вас есть строгие ограничения по себестоимости конечного изделия и каждый цент на счету (microSD карта + разъем заведомо дороже, чем микросхема флеш-памяти распаянная на плате); у вас есть строгие ограничения по габаритам конечного изделия; Если microSD-карта не подходит, - остается выбор между NOR и NAND памятью. В целом, при выборе типа памяти нужно отталкиваться от размера финальной прошивки. Если до 32 Мб, - то лучше выбрать микросхему памяти NOR (цена - меньше, ресурс - выше), если больше 32 Мб - то остается NAND. Если выбор пал на микросхему памяти, распаянную на плате, то есть два варианта: образ ядра прошивается в микросхему до распайки на плате. В этом случае микросхемы по-очередно извлекаются из катушки, устанавливаются в программатор (наподобие такого), затем упаковываются обратно в катушку. Очень трудоемкий и не технологичный процесс. образ ядра прошивается в микросхему после распайки на плате с помощью микропроцессора. Процессор нужно каким-либо образом запустить (при этом загрузочная микросхема флеш памяти пуста!), доставить ему образ прошивки, которую процессор и загрузит в м/сх памяти. Звучит как нечто, что очень сложное в реализации, зато это снижает количество ручных операций в процессе производства. Забегая вперед скажу, что мы выбрали именно этот вариант и нам удалось его автоматизировать. При работе с отладочными платами вы почти наверняка встречали нечто подобное:        переключатель, задающий загрузочный режим. Дело в том, что процессоры, как правило, поддерживают несколько различных вариантов загрузки, таких как SPI, QSPI, SDHC, UART и пр. Какой-именно вариант загрузки использовать определяется фьюз-битами. Процессор может вычитать фьюз-биты из регистров, либо определив состояние определенных GPIO. Какой именно способ процессору использовать, в свою очередь, задается состоянием двух других ножек (BOOT_MODE0 и BOOT_MODE1). Также можно встретить вариант одного-единственного варианта загрузки, заданного резисторами: Если габариты позволяют и не жалко несколько ножек процессора, то лучше выбрать один из этих вариантов (переключатель или резисторы). В случае же, если вы ограничены в габаритах (наш случай) или нужно высвободить ножки процессора под другие задачи, то остается только третий вариант, - "прожигать" фьюз-биты. Итак, в нашем случае, ответы на три озвученных ранее вопроса были такими: Образ хранится в микросхеме памяти. SPI NOR флешка. Флешка прошивается уже будучи распаянной на плате. "Прожиг" фьюз битов. Решением задачи при такой постановке вопроса стал разработанный стенд серийной прошивки и первоначального тестирования. Устройство, под которое был разработан стенд: SoM-модуль, на борту стандартный для SoM-модулей набор: Процессор, память RAM, память flash, физика ethernet, физика wi-fi. По всем четырем граням расположены контактные площадки в форме полу-отверстий с шагом 1.5мм.   А вот и собственно сам стенд: С аппаратной точки зрения, все довольно тривиально: по центру набор пружинных контактов под тестируемый SoM, который прижимается сверху вертикальным зажимом. Из подведенной к модулю периферии: UART, JTAG, Ethernet. Ну и питание. В ручную, процедура прошивки и прожига фьюз-битов выглядит следующим образом: Тестируемое устройство устанавливается в стенд подключается usb-uart переходник, программатор JLink, Ethernet-кабель, подается питание. Запускается openocd сервер (openocd.exe); Производится подключение к openocd серверу по telnet (openocd клиент); Открывается COM-порт, назначенный USB-UART переходнику; Сброс процессора (через консоль openocd-клиента): Грузим образ u-boot (через консоль openocd-клиента): Грузим образ ядра linux (через консоль openocd-клиента): Запускаем работу процессора (через консоль openocd-клиента): В это время должен стартануть u-boot и в консоли com-порта появятся логи загрузки. Нажимаем enter, чтобы остаться в консоли u-boot. Определите флешку (консоль COM-порта): И прошейте флешку (консоль COM-порта): Прожгите фьюз-биты (консоль COM-порта): Ребутните процессор (консоль COM-порта): После этого процессор должен ребутнуться и загрузить ядро линукс с флешки без помощи программатора. Естественно, шаги с 3-его по 13-й можно автоматизировать. По-питонячьи это выглядит так: Исходники можно найти тут. Скрипт может быть относительно легко адаптирован под другие семейства процессоров с архитектурой ARM (семейства IMX компании NXP, по крайней мере). В планах - замена шага №6 (загрузка factory образа по JTAG занимает очень много времени) на загрузку с TFTP-сервера с помощью u-boot утилиты tftp.