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

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 путь к нему.

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


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

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...