Как стать автором
Обновить

Комментарии 14

output/target — правидьнее будет сказать скелет файловой системы. И стоит тогда упомянуть output/image — тут лежать коечные файлы образов.

Путь к конфигу ядра можно указать в настройках, и сохранять командый make save-update-defconfig
О создании полноценной конфигурации платы, external tree и прочем — в следующей статье. От простого с ложному.
Команды «save-update-defconfig» не существует. Наверно, имелось ввиду " make linux-update-defconfig"?

Скелет файловый системы — не хотелось бы путаницы со skeleton. Так-то output/target и не совсем скелет. Это файловая система, в которой отсутвуют только файлы устройств(/dev ) и не настроены правана файлы.
Да, вы правы, комнада make linux-update-defconfig. Но для чего тогда использовать cp, если команда известна?
Честно говоря, привык хранить полный конфиг ядра.
Поправил, добавил использование команды linux-update-defconfig
Спасибо за комментарий.
output/target… output/host… output/build… output/image...

А ещё Makefile понимает параметр O=<путь к корневому каталогу сбоки> с помощью которого можно сборку вести в произвольном месте, в том числе за пределами buildroot.
Спасибо за статью. Сам хотел что-то подобное написать, но времени не нашлось. Вместо root_overlay, на мой взгляд, лучше наваять скрипт post_build.sh, в котором устанавливать нужные конфиги и файлы с нужными правами с помощью install в target-fs. В Buildroot есть пункты для pre-build, post-build скриптов, которым передает корневую директорию сборки в качестве аргумента.
Можете сказать почему вы пришли к такому выводу?
На мой взгляд, это удобнее и надежнее. Я пробовал оба варианта, скриптами процесс всякой подготовительной работы автоматизируется и переносится из одной версии buildroot в другой.
В папке board/<ваше_имя_к_конфигам> файлы можно располагать как угодно, в своем порядке, там же держится сам скрипт. В post-build можно не только заменить файлы, но и права назначить и всяческие проверки добавить, которые устанавливают файлы в зависимости от наличия тех, или иных пакетов в итоговой сборке.
Также можно с помощью средств шелла менять нужные строчки в дефолтных системных конфигах.
В комментарии выше я наврал — скрипту из buildroot передается target-fs, а не корневая директория, прошу прощения.
Ну и пример:
install -m 0644 $BOARD_DIR/inittab $1/etc/

Где: $BOARD_DIR — переменная билдрута. $1 — путь к target-fs, передается билдрутом в качестве аргумента скрипту.
мой опыт:
1.roofs_overlay. Удобно когда нужно иметь файл гарантированного содержания. Который не поменяется с обновлением версий.Наглядно, понятно, новый в проекте человек сходу всё видит и понимает. Ну и порядок- сразу видно, какой файл куда попадёт.
2. Вариант со скриптами. Удобно, что можно прогнать sed/awk и внести изменения в любой конфиг, который может поменяться с обновлением пакета.Я тоже так делаю.

Насчет обновления buildroot, удобно хранить в external_tree свои наработки. Это избавляет лишней работы.

Насчет прав, есть механизм BR2_ROOTFS_DEVICE_TABLE. Он позвоялет создавать файлы( в тч устройств) с нужными правами.Можно менять права на имеющиеся файлы, насколько я понял. Детально ещё не пробовал с ним работать.
Обо всех этих механизмах в дальнейших статьях напишу. Две уже готовы, ещё 2 надо дописать.

В итоге я использую оба метода. Они оба хороши по-своему.
Да, права на каталоги выставляются нормально, как и владелецс группой.
Можно все ложить в оверлей, а уже в пост скрипте изменить его в зависимости от условий
Спасибо Вам за ваш труд, жду следующих статей!

Насчет root_overlay — дело вкуса, мне кажется. Конкретно против external_tree ничего против не имею, саму строчку в конфиге buildroot считаю лишней. Особенно потому, что она заменяется строчкой cp -frP <путь_к_external_tree> $1 в скрипте. Плюсы — можно держать несколько external_tree и гибко их менять. Так и использую.

Мне кажется, мы с Вами немного разные цели преследуем. У меня нет новичков, работаю в небольшой компании. А когда им был — скрипт для меня был понятнее :). Там и задокументировать все можно. А наработки у меня в своей системе сборки раскладываются в зависимости от платформы по соответствующим папкам в дереве проекта. Платформ несколько, и они отличаются. Мне проще в зависимости от платформы забрать свежие наработки из проекта, чем из проекта копировать в одно и то же место, создавая путаницу.
Резюмирую, сказав так: возможностей много, весь вопрос задач конкретного проекта и личных предпочтений.

"Buildroot собрал образы, которые можно запустить в Qemu и убедиться, что они работают."

На этом этапе лучше запускать output/images/start-qemu.sh
kоторый рожает сам buildroot. Cкрипт start-qemu.sh запустит виртуальную машину точно с корректными параметрами. В моем случае это
#!/bin/sh
(
BINARIES_DIR="${0%/*}/"
cd ${BINARIES_DIR}

if [ "${1}" = "serial-only" ]; then
EXTRA_ARGS='-nographic'
else
EXTRA_ARGS='-serial stdio'
fi

export PATH="/home/a/QtFromGit/myb/buildroot/output/host/bin:${PATH}"
exec qemu-system-x86_64 -M pc -kernel bzImage -drive file=rootfs.ext2,if=virtio,format=raw -append "rootwait root=/dev/vda console=tty1 console=ttyS0" -net nic,model=virtio -net user ${EXTRA_ARGS}
)

Иногда возникает желание работать с системой buildroot НЕ из-под каталога buildroot (чтобы не делать cd лишний раз). Это возможно, укажите утилите make положение папки buildroot. Пример работы из-под домашнего каталога:

cd ~ git clone
git://git.buildroot.net/buildroot #будет создана папка buildroot
#не надо делать cd buildroot
make clean -C buildroot
make -C buildroot qemu_x86_ssh_defconfig
make -C buildroot

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории