Перейти к содержанию

    

Buildroot: создание образа Orange Pi

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

 

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

[olej@xenix buildroot-master]$ make list-defconfigs | grep orangepi
  orangepi_lite_defconfig             - Build for orangepi_lite
  orangepi_one_defconfig              - Build for orangepi_one
  orangepi_pc2_defconfig              - Build for orangepi_pc2
  orangepi_pc_defconfig               - Build for orangepi_pc
  orangepi_pc_plus_defconfig          - Build for orangepi_pc_plus
  orangepi_plus_defconfig             - Build for orangepi_plus
  orangepi_prime_defconfig            - Build for orangepi_prime
  orangepi_win_defconfig              - Build for orangepi_win
  orangepi_zero_defconfig             - Build for orangepi_zero
  orangepi_zero_plus2_defconfig       - Build for orangepi_zero_plus2

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

[olej@xenix buildroot-master]$ make orangepi_one_defconfig
mkdir -p /home/olej/buildroot-master/output/build/buildroot-config/lxdialog
PKG_CONFIG_PATH="" make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
    obj=/home/olej/buildroot-master/output/build/buildroot-config -C support/kconfig -f Makefile.br conf
/usr/bin/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE  -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -I/home/olej/buildroot-master/output/build/buildroot-config -DCONFIG_=\"\"   /home/olej/buildroot-master/output/build/buildroot-config/conf.o /home/olej/buildroot-master/output/build/buildroot-config/zconf.tab.o  -o /home/olej/buildroot-master/output/build/buildroot-config/conf
#
# configuration written to /home/olej/buildroot-master/.config
#

А дальше правим конфигурации под свои потребности...

Образ .img собран, накатан на SD-карточку, загружен...

Вся загрузка через UART идёт на отладочную консоль ... до login и далее ...

 

Но локальный монитор при этом глухо не инициализируется, только UART-консоль.

В обсуждениях (на вопрос "куда копать") пишут:

В сторону драйвера дисплея, в mainline ядре поддержки Н3 до сих пор нет.

Сейчас пока всё делается через U-Boot, он сам настраивает HDMI, создает под это фреймбуфер и передает его ядру в готовом виде, не помню как эта технология называется.

Ядро работает только с /dev/fb*. посмотри есть они у тебя?

Может кто прояснить происходящее?

Как называется эта технология?

:laughing: ... Куда копать?

 

 

Поделиться сообщением


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

 

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

[olej@xenix buildroot-master]$ make list-defconfigs | grep orangepi
  orangepi_lite_defconfig             - Build for orangepi_lite
  orangepi_one_defconfig              - Build for orangepi_one
  orangepi_pc2_defconfig              - Build for orangepi_pc2
  orangepi_pc_defconfig               - Build for orangepi_pc
  orangepi_pc_plus_defconfig          - Build for orangepi_pc_plus
  orangepi_plus_defconfig             - Build for orangepi_plus
  orangepi_prime_defconfig            - Build for orangepi_prime
  orangepi_win_defconfig              - Build for orangepi_win
  orangepi_zero_defconfig             - Build for orangepi_zero
  orangepi_zero_plus2_defconfig       - Build for orangepi_zero_plus2

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

[olej@xenix buildroot-master]$ make orangepi_one_defconfig
mkdir -p /home/olej/buildroot-master/output/build/buildroot-config/lxdialog
PKG_CONFIG_PATH="" make CC="/usr/bin/gcc" HOSTCC="/usr/bin/gcc" \
    obj=/home/olej/buildroot-master/output/build/buildroot-config -C support/kconfig -f Makefile.br conf
/usr/bin/gcc -D_GNU_SOURCE -D_DEFAULT_SOURCE  -DCURSES_LOC="<ncurses.h>" -DNCURSES_WIDECHAR=1 -DLOCALE  -I/home/olej/buildroot-master/output/build/buildroot-config -DCONFIG_=\"\"   /home/olej/buildroot-master/output/build/buildroot-config/conf.o /home/olej/buildroot-master/output/build/buildroot-config/zconf.tab.o  -o /home/olej/buildroot-master/output/build/buildroot-config/conf
#
# configuration written to /home/olej/buildroot-master/.config
#

А дальше правим конфигурации под свои потребности...

Образ .img собран, накатан на SD-карточку, загружен...

Вся загрузка через UART идёт на отладочную консоль ... до login и далее ...

 

Но локальный монитор при этом глухо не инициализируется, только UART-консоль.

В обсуждениях (на вопрос "куда копать") пишут:

 

Может кто прояснить происходящее?

Как называется эта технология?

:laughing: ... Куда копать?

 

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

Nano pi NEO немного дороже, но гораздо стабильнее. Я решил не тратить время на сырой софт.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Я самый простой 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 ... всё очень адекватно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Это всё (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 :laughing: ).

На сегодня размер - это вовсе уже мало для кого ограничивающий фактор, но в этих пакетных дистрибутивах (даже если это на ARM, типа Armbian) по умолчанию сконфигурированы 2-3 десятка демонов-сервисов, которые могут тупо без нужды нагружать систему ... или нужно щепетильно разбираться кого там из них нужно останавливать.

P.S. как пример, ... смешно :biggrin: : практически во всех пакетных дистрибутивах устанавливаются и запускаются ... сервисы SMB ... "услужливо" :wacko:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
P.S. как пример, ... смешно :biggrin: : практически во всех пакетных дистрибутивах устанавливаются и запускаются ... сервисы SMB ... "услужливо" :wacko:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сегодня размер не так критичен.

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

не смешивайте продакшн и отладку..

 

Вся загрузка через UART идёт на отладочную консоль ... до login и далее ...

Но локальный монитор при этом глухо не инициализируется, только UART-консоль.

В обсуждениях (на вопрос "куда копать") пишут:

Может кто прояснить происходящее?

Как называется эта технология?

:laughing: ... Куда копать?

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

далее после загрузки системы посмотреть командой

ls /dev

существование устройств fb0/fb1 и подобных

если их нет, то смотреть в конфиге ядра раздел поддержки графики на предмет фреймбуфера для этого АРМа

если есть, то либо утилитой fbset смотреть текущие параметры либо копаться в каталоге /sys/class/graphics/fb0 возможно какого-то enable или blank не хватает..

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

 

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

Поделиться сообщением


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

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

далее после загрузки системы посмотреть командой

ls /dev

существование устройств fb0/fb1 и подобных

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

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

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

 

Но всё это не самое главное в этой теме.

А то, как средствами BuildRoot собрать hard realtime систему Xenomai Cobalt?

Когда для патченья ядра под проект Adeos, патч ipipe, Xenomai в своих инструкциях используют не команду patch, а свой собственный скрипт патченья ... почти в 500 строк кода shell.

Как это объяснить BuildRoot?

 

 

Поделиться сообщением


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

не смешивайте продакшн и отладку..

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Сегодня память стоит совсем недорого.

Это точно.

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

 

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
Это точно.

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

 

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

 

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

 

Про массовое производство:

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

Програмно исполнены RFID, I2C ну и вся логика. У него пол килобайта програмной памяти всего.

 

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

orbit_pro_pic.jpg

 

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
А то, как средствами BuildRoot собрать hard realtime систему Xenomai Cobalt?

Когда для патченья ядра под проект Adeos, патч ipipe, Xenomai в своих инструкциях используют не команду patch, а свой собственный скрипт патченья ... почти в 500 строк кода shell.

Как это объяснить BuildRoot?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти
Авторизация