Попытаемся выяснить в деталях: что конкретно происходит, когда записанная в режиме Product карта вставлена в устройство и подано питание ?

Из приведеннной выше структуры прошивочной карты следует, что если прочитать раздел ENV по его адресу в GPT, то мы получим в самом его начале содержимое общего заголовка imagewty-образа.
В котором можно увидеть имена и смещения входящих в состав образа файлов относительно начала раздела ENV. Поэтому абсолютный адрес любого файла прошивки на карте легко определяется как сумма адреса ENV и адреса файла в этом заголовке. Это означает, что с такой прошивочной карты можно без труда извлечь любой нужный файл. Тогда получается, что это может сделать загрузчик, когда такая карта вставлена в устройство и пошел процесс загрузки, т.е. загрузчик стартовал с SD-карты и получил доступ к её содержимому.

Вероятно, механизм программирования ("прошивания") внутренней eMMC-памяти заключается в извлечении нужных файлов из imagewty-образа, записанного на карту, и копирования их в соответствующие разделы на внутренней памяти устройства. И эти операции должен уметь выполнять один из вторичных загрузчиков: eGON, в качестве которого служит boot0, или загрузчик U-Boot. При этом где-то должен быть указан признак того, что нужно выполнять именно процедуру копирования в eMMC, а не обычную загрузку. Какой именно загрузчик используется - пока вопрос открытый (спойлер: это U-Boot).

Анализ структуры начала прошивочной (Product)карты показывает, что оно практически не отличается от аналогичного места на загрузочной (StartUp) карты: есть таблица разделов (GPT), первая часть вторичного загрузчика (boot0), блоб package (дерево устройств DTB и вторичный загрузчик U-Boot) - всё на месте.

Хотя из-за затертого раздела ENV отсутствуют переменные окружения, который должны содержать командные строки, необходимые для "продолжения банкета", но они требуются только для загрузки boot - "ядра", а точнее - Android Boot Image (образа загрузки Android). А учитывая, что раздел boot фактически отсутствует (он есть, но тоже затерт), то дальше и загружать нечего.

Это означает, что при подаче питания на устройство с такой вставленной прошивочной картой в принципе может (и должен) начаться обычный процесс загрузки, который завершится запуском U-Boot с переходом в его командный режим (по пробелу в терминале на последовательном порте) или каким-то автоматическим продолжением (каким ?).

В случае с загрузочной (StartUp) картой при автоматическом продолжении загрузки U-Boot загружает ядро boot, выполняя содержащуюся в ENV командную строку:
bootcmd=run setargs_mmc boot_normal.

Но из-за отсутствия на своем месте переменных ENV загрузчик U-Boot этого, естественно, сделать не сможет. Поэтому продолжение будет другим, а именно, произойдет переход к программированию (или "прошиванию") внутренней eMMC-памяти данными, содержащимися на карте в файле imagewty-образа.

Это означает, что необходимый функционал программирования либо реализован в самом U-Boot, либо U-Boot должен извлекать и запускать соответствующую программу непосредственно из imagewty-образа.

5. Для того, чтобы узнать, какой из загрузчиков занимается программированием, проведем простой эксперимент. Один и тот же imagewty-образ запишем на две разных карточки: первая в режиме StartUp, вторая - Product. И посмотрим в терминале через последовательный порт лог загрузки в обоих вариантах.

Анализ и сравнение логов показывает, что в обоих вариантах записанной карты логи загрузчика Boot0 полностью совпадают. Более того, в обоих вариантах происходит запуск вторичного загрузчика U-Boot, о чём свидетельствуют строки лога:

 Адрес   Startup   Product
 0x0c      0xc3      0xd4
 0xe0      0x00      0x11

0x11 = 17

 0xd4 - 0xc3 = 0x11