Comments 14
Путь к конфигу ядра можно указать в настройках, и сохранять командый make save-update-defconfig
Команды «save-update-defconfig» не существует. Наверно, имелось ввиду " make linux-update-defconfig"?
Скелет файловый системы — не хотелось бы путаницы со skeleton. Так-то output/target и не совсем скелет. Это файловая система, в которой отсутвуют только файлы устройств(/dev ) и не настроены правана файлы.
output/target… output/host… output/build… output/image...
А ещё Makefile понимает параметр
O=<путь к корневому каталогу сбоки> с помощью которого можно сборку вести в произвольном месте, в том числе за пределами 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
Buildroot — часть 1. Общие сведения, сборка минимальной системы, настройка через меню