Здесь есть рядом похожая тема Buildroot: создание образа и перепрошивка i.MX6ULL, но ... не хочется сорить - там немного о другом.

Вопрос: в BuildRoot (последних) есть дефаултные конфигурации:

Заказываем дефаултный конфиг:

А дальше правим конфигурации под свои потребности...
Образ .img собран, накатан на SD-карточку, загружен...
Вся загрузка через UART идёт на отладочную консоль ... до login и далее ...

Но локальный монитор при этом глухо не инициализируется, только UART-консоль.
В обсуждениях (на вопрос "куда копать") пишут:

Может кто прояснить происходящее?
Как называется эта технология?
... Куда копать?

Я самый простой orangepi попробовал. Не строил ничего. Скачал их образ с интернета. Не работает команда shutdown -h now. Она ребут делает. Попробовал смонтировать RAM диск. После рестарта все, что писал сохраняется в директории. То есть он сделал вид, что монтирует, а сам тупо в директорию пишет. Забил. Оно сырое.
Nano pi NEO немного дороже, но гораздо стабильнее. Я решил не тратить время на сырой софт.

Это всё (Orange Pi vs Nano Pi ... или vs Rapsberry Pi) к самому типу SBC/SoC не имеет никакого отношения:
- для того же Orange Pi есть ... ну не меньше 2-х десятков авторов-технологий сборки OS, и каждая ведёт себя по-разному
- есть постоянно обновляемые сборки от независимого проекта Armbian - очень приличные сборки и очень умный проект ... не в пример "оригинальной" сборке от производителя Orange Pi
- я сам с помощью BuildRoot, простейшими усилиями, собирал 3-4 вариантов минимальных конфигураций CLI Linux ... всё очень адекватно.

Я самодельные сборки не хочу делать. Мой проект требует установки несокльких пакетов для работы с сетью и т.д.. Каждый компилировать времени нет. А на дебиан или убунту, федору можно простой командой ставить.
Я не знал, что много есть альтернатив. Спасибо. Посмотрю внимательнее. Rapsberry Pi конечно крутой. Я на нем ставил Астериск и писал драйвер для USB FXO/FXS. Работает как часы. Там для телефона каждую миллисекунду передается 8 точек голоса. Никаких проблем не было.

Это никакие не самодельные сборки. А самые что ни на есть стандартные сборки Linux, когда системе сборки только указываются требуемые ядро, пакеты... а система сборки сама ownload с домашних страниц всех проектов их скачивает (исходники) и собирает. Большой плюс, что может собирать кросс-компиляцией (на x86 станет собирать образ для PPC).

На "дебиан или убунту, федору" всё ставится пакетными системами , пакеты, которые компилируются ровно из тех же исходников (других в природе просто нет).
Только пакетные дистрибутивы имеют размер раз в 10 больше, чем собранные под целевые требования (1Gb, к примеру, вместо 75Mb ).
На сегодня размер - это вовсе уже мало для кого ограничивающий фактор, но в этих пакетных дистрибутивах (даже если это на ARM, типа Armbian) по умолчанию сконфигурированы 2-3 десятка демонов-сервисов, которые могут тупо без нужды нагружать систему ... или нужно щепетильно разбираться кого там из них нужно останавливать.
P.S. как пример, ... смешно : практически во всех пакетных дистрибутивах устанавливаются и запускаются ... сервисы SMB ... "услужливо"

потому что не надо черпать всякую каку из чужих источников - архив голого дистрибутива нативного дебьяна (для архитектуры armel или armelhf) весит ~60-70MB, о каких гигабайтах идет речь? туда напихивают медийных файлов или кучу ненужных на момент старта пакетов (самбу, гцц и прочее)..
зайдите на сайт debian, там есть инструкция как самому сплодить дистрибутив, аскетичнее некуда. более того даже оттуда можно еще повыкидывать доки, локали и еще уменьшить размер

Сегодня размер не так критичен. У меня есть масса вещей сделать, что я не хочу тратить время на сборки или вылизывание. Если встанет вопрос о конечном продукте -- тогда и буду вылизывать. Производительности тоже хватает, а если нет, то знаю как найти кто жрет время процессора.

производители телевизоров, медиаприставок, роутеров, видеорегистраторов и подобной нечисти дружно улыбаются при этой фразе..
не смешивайте продакшн и отладку..


видимо для начала посмотреть "а не выводит ли изображение u-boot?" раз уж он инитит hdmi, то и выводить наверно что-то может - логотип или картинку или просто строчки
далее после загрузки системы посмотреть командой

существование устройств fb0/fb1 и подобных
если их нет, то смотреть в конфиге ядра раздел поддержки графики на предмет фреймбуфера для этого АРМа
если есть, то либо утилитой fbset смотреть текущие параметры либо копаться в каталоге /sys/class/graphics/fb0 возможно какого-то enable или blank не хватает..
в клиническом случае подебажить драйвер фреймбуфера, хотя бы момент старта, параметров и успешного выхода в конце инита..

ЗЫ да, и проверить - может надо через строку для ядра передать параметры для разрешения hdmi

U-boot выводит текстовый протокол своей загрузки, до момента загрузки ядра.

Нет их, /dev/fb* - с самого начала проверено.

Каким образом "проверить"?

Но всё это не самое главное в этой теме.
А то, как средствами BuildRoot собрать hard realtime систему Xenomai Cobalt?
Когда для патченья ядра под проект Adeos, патч ipipe, Xenomai в своих инструкциях используют не команду patch, а свой собственный скрипт патченья ... почти в 500 строк кода shell.
Как это объяснить BuildRoot?

Вы разрабатывали для массового производства? Откуда дровишки? Самый главный вопрос поскорее выйти на рынок, а не размер памяти. Сегодня память стоит совсем недорого.

Это точно.
Тем более, что чипов памяти меньше какого-то лимита просто не становится на рынке. И этот лимит, минимум постоянно увеличивается.

P.S. Не про RAM, но близкая аналогия: а вы попробуйте купить на рынке SD-карточку 4Gb ... не говоря уже про 2Gb. Я недавно пробовал . Не говоря уж о том, что 2Gb и 8Gb стоят примерно одинаковую цифру денег.

Верно. А что касается эффективного использования памяти и других рессурсов, то я это тоже умею.

Про массовое производство:
В 1997 году я сделал иммобилайзер для автомобиля на 68HC05J1, который впоследствии продавался.
Програмно исполнены RFID, I2C ну и вся логика. У него пол килобайта програмной памяти всего.

На этой картинке справа внизу program transfer module.


он сделан на PIC16C71 с 23 байтами памяти.

Я, кстати, на этом же чипе сделал приемник модема FSK 1200/2200. Это при 1 мегагерце системном. Такое делают на DSP с 25-30 мегагерцами.

Но сегодня развитие технологии разработки идет по пути как сделать дешевле, где работа и задержка по времени тоже имеют цену.
Это я к тому, что я не от поиска легких путей выбираю такие решения. Делать устройство на минимуме ресурсов я тоже умею.

Собрать пропатченное ядро отдельно и указать BuildRoot путь к нему.