Компиляция ядра линукс под arm

Как собрать ядро linux под arm

Операционная система linux часто используется для встраиваемых (они же embedded) устройств, которые в свою очередь часто построены на основе контроллеров с архитектурой ARM.

Исходный код

Скачать исходный код ядра linux можно с http://git.kernel.org

Например, если использовать код из проекта project:

После того как исходники будут скачаны, заходим в директорию с исходным кодом ядра linux.

Для того что бы отделить результат компиляции от исходного кода, создаем директорию build

Компилятор

Распаковываем ( например в /home/user ):

И устанавливаем переменную PATH:

Задаем переменные окружения для компиляции:

Конфигурирование ядра linux

Если нужная конфигурация уже существует ( например arch/arm/configs/colibri_pxa320_defconfig ), то выполняем:

Если необходимо создать свою конфигурацию ядра linux, или изменить существующую то запускаем:

и выбираем необходимые опции. Опции могут быть вкомпилированны в ядро или подгружаться как модули. В первом случае перед соответствующим пунктом меню отображается [*] , во втором [M].

Компиляция ядра linux

Что бы скомпилировать ядро надо выполнить команду:

Когда сборка ядра linux будет закончена, оно будет лежать в ../build/arch/arm/boot/uImage

Сброка модулей ядра linux

Если какие-то опции ядра были включены как модули, то их тоже надо скомпилировать

Что бы изменить директорию (папку) в которую modules_install установит модули, указываем путь, используя переменную INSTALL_MOD_PATH.

В дальнейшем, что бы положить модули ядра на устройство, надо просто скопировать, все что лежит в директории /home/user/tmp/modules в корень файловой системы устройства. При этом важно сохранить структуру каталогов, самый просто способ — упаковать папку, а затем разархивировать ее на приборе.

Очистка проекта

Что бы удалить все файлы, созданные при компиляции:

Если же необходимо удалить файлы, полученные при конфигурации ядра linux, нам поможет Мистер Пропер 🙂

Источник

Кросскомпиляция под ARM

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

В данном посте будут описаны:

1. Инструменты
2. Элементарная технология кросскомпиляции
3. И, собственно, HOW2

Кому это интересно, прошу под кат.

Вводная

Одно из развивающихся направлений в современном IT это IoT. Развивается это направление достаточно быстро, всё время выходят всякие крутые штуки (типа кроссовок со встроенным трекером или кроссовки, которые могут указывать направление, куда идти (специально для слепых людей)). Основная масса этих устройств представляют собой что-то типа «блютуз лампочки», но оставшаяся часть являет собой сложные процессорные системы, которые собирают данные и управляют этим огромным разнообразием всяких умных штучек. Эти сложные системы, как правило, представляют собой одноплатные компьютеры, такие как Raspberry Pi, Odroid, Orange Pi и т.п. На них запускается Linux и пишется прикладной софт. В основном, используют скриптовые языки и Java. Но бывают приложения, когда необходима высокая производительность, и здесь, естественно, требуются C и C++. К примеру, может потребоваться добавить что-то специфичное в ядро или, как можно быстрее, высчитать БПФ. Вот тут-то и нужна кросскомпиляция.

Если проект не очень большой, то его можно собирать и отлаживать прямо на целевой платформе. А если проект достаточно велик, то компиляция на целевой платформе будет затруднительна из-за временных издержек. К примеру, попробуйте собрать Boost на Raspberry Pi. Думаю, ожидание сборки будет продолжительным, а если ещё и ошибки какие всплывут, то это может занять ох как много времени.

Поэтому лучше собирать на хосте. В моём случае, это i5 с 4ГБ ОЗУ, Fedora 24.

Инструменты

Для кросскомпиляции под ARM требуются toolchain и эмулятор платформы либо реальная целевая платформа.

Т.к. меня интересует компиляция для ARM, то использоваться будет и соответствующий toolchain.

Toolchain’ы делятся на несколько типов или триплетов. Триплет обычно состоит из трёх частей: целевой процессор, vendor и OS, vendor зачастую опускается.

• *-none-eabi — это toolchain для компиляции проекта работающего в bare metal.
• *eabi — это toolchain для компиляции проекта работающего в какой-либо ОС. В моём случае, это Linux.
• *eabihf — это почти то же самое, что и eabi, с разницей в реализации ABI вызова функций с плавающей точкой. hf — расшифровывается как hard float.

Описанное выше справедливо для gcc и сделанных на его базе toolchain’ах.

Сперва я пытался использовать toolchain’ы, которые лежат в репах Fedora 24. Но был неприятно удивлён этим:

Поискав, наткнулся на toolchain от компании Linaro. И он меня вполне устроил.

Второй инструмент- это QEMU. Я буду использовать его, т.к. мой Odroid-C1+ пал смертью храбрых (нагнулся контроллер SD карты). Но я таки успел с ним чуток поработать, что не может не радовать.

Элементарная технология кросскомпиляции

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

Выглядит это так:

Какие ключи у toolchain’а можно посмотреть на сайте gnu, в соответствующем разделе.

Для начала нужно запустить эмуляцию с интересующей платформой. Я решил съэмулировать Cortex-A9.

После нескольких неудачных попыток наткнулся на этот how2, который оказался вполне вменяемым, на мой взгляд.

Ну сперва, само собою, нужно заиметь QEMU. Установил я его из стандартных репов Fedor’ы.

Далее создаём образ жёсткого диска, на который будет установлен Debian.

По этой ссылке скачал vmlinuz и initrd и запустил их в эмуляции.

Далее просто устанавливаем Debian на наш образ жёсткого диска (у меня ушло

После установки нужно вынуть из образа жёсткого диска vmlinuz и initrd. Делал я это по описанию отсюда.

Сперва узнаём смещение, где расположен раздел с нужными нам файлами:

Теперь по этому смещению примонтируем нужный нам раздел.

Копируем файлы vmlinuz и initrd и размонтируем жёсткий диск.

Теперь можно запустить эмуляцию.

И вот заветное приглашение:

Теперь с хоста по SSH можно подцепиться к симуляции.

Теперь можно и собрать программку. По Makefile’у ясно, что будет калькулятор. Простенький.

Собираем на хосте исполняемый файл.

Отмечу, что проще собрать с ключом -static, если нет особого желания предаваться плотским утехам с библиотеками на целевой платформе.

Копируем исполняемый файл на таргет и проверяем.

Собственно, вот такая она, эта кросскомпиляция.

UPD: Подправил информацию по toolchain’ам по комментарию grossws.

Источник

Linux для ARM в эмуляторе qemu

Вывести что-нибудь на экран эмулируемого устройства VersatilePB не так-то просто. Все примеры простых ядер для ARM, которые удалось найти на момент написания статьи, ограничиваются работой с последовательным портом.

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

На примере 2-х с небольшим тысяч строк кода будет подробно рассказано об инициализации памяти, зонах памяти, slab-аллокаторе применяемых в Linux.

Сборка ядра для архитектуры ARM (на примере linux-2.6.32.3)

Команды, приводимые далее взяты из файлов *.cmd. Эти файлы формируются автоматически системой сборки ядра, но никто не запрещает использовать команды непосредственно.

Ядро запускаемое в qemu ./arch/arm/boot/zImage получается отсечением ненужных секций от скомпилированного кода распаковки:

Этот код собирается из библиотеки(libgcc.a), файла содержащего точку входа (head.o), файла в который включены двоичные данные упакованного ядра (piggy.o) и кода на Си выполняющего распаковку (misc.o):

Упакованное ядро добавляется в piggy.S строкой:

piggy.o компилируется командой:

Файл piggy.gz получается командой:

Обратите внимание на две точки между директориями compressed и Image. Они означают переход на один уровень вверх в дереве файловой системы, т.е. Image расположен в arch/arm/boot/.
Такие сложности обусловлены автоматической генерацией команд сборки.

Image получается отсечением ненужных секций от скомпилированного ядра.:

Не упакованое ядро (vmlinux) получается так:

И наконец файл main.c, который мы будем рассматривать входит в состав init/built-in.o:

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

user/arm-2011.09/bin/ — путь начинающийся от домашнего каталога автора до директории, содержащий тулчейн. Если вы скопируете тулчейн для ARM в свой домашний каталог и измените «user», на имя пользователя, то у Вас всё должно получиться.

Команды объединены в исполняемый файл make (не путайте с одноименной утилитой).

Код непосредственно после отделения от дерева исходников ядра, включая всё, о чем пойдет речь в следующих постах arm_qemu_max.

Сокращенный вариант, без инициализации памяти и slab-аллокатора (только вывод на экран) arm_qemu_min.

Текст остальных статей написан. Остается только опубликовать.

Источник

Компиляция под ARM

Всем доброго времени суток

Собрался я тут компилировать систему вот по этому мануалу вот для этой железки. Процессор там Kirkwood Feroceon 88F6281. Скомпилировал crosstools-ng и toolchain, настала очередь ядра. Скачал отсюда ядро, сконфигурировал его, запускаю на компиляцией командой

CHK include/linux/version.h
CHK include/generated/utsrelease.h
CC scripts/mod/empty.o

cc1: ошибка: unrecognized command line option «-mlittle-endian»
cc1: ошибка: unrecognized command line option «-mapcs»
cc1: ошибка: unrecognized command line option «-mno-sched-prolog»
scripts/mod/empty.c:1:0: ошибка: unknown ABI (apcs-gnu) for -mabi= switch
scripts/mod/empty.c:1:0: ошибка: bad value (armv4t) for -march= switch
scripts/mod/empty.c:1:0: ошибка: bad value (xscale) for -mtune= switch
make[2]: *** [scripts/mod/empty.o] Ошибка 1
make[1]: *** [scripts/mod] Ошибка 2
make: *** [scripts] Ошибка 2

Не подскажете что я делаю не так?

Ну что я думаю по этому поводу. Хотя еще мне только предстоит ARM юзать чуть позже. CROSS_COMPILE=$CROSS_COMPILE Это строка, как мне кажется, «Масло масляное». Еще есть мысль заменить компилятор сс на gcc. Потому как странно, что он не видит «-mlittle-endian» -эта опция используется для систем AIX5 и Linux по умолчанию. Попробуйте после этого так
1)В терминале make ARCH=arm menuconfig
2)Долго выбираем в окошке нужные параметры
3)make ARCH=arm zImage -j4

CROSS_COMPILE=$CROSS_COMPILE Это строка, как мне кажется, «Масло масляное»

Не знаю почему вам так кажется, но

это я на всякий случай прописал, ибо не знаю подхватится оно автоматом или нет

Еще есть мысль заменить компилятор сс на gcс

зачем и как? Ибо я собирал по мануалу указанному выше и компилятор там из crosstool-ng специально под arm собран

заменить компилятор сс на gcc

Я думаю мне бы было полезно было использовать вот этот компилятор $HOME/cross/toolchain/arm-unknown-linux-uclibcgnueabi/bin/gcc. Но я не могу понять пока как это сделать

И советую ознакомится GNU make

ввожу make CC=$HOME/cross/toolchain/arm-unknown-linux-uclibcgnueabi/bin/gcc ARCH=arm uImage -j4
он мне выплёвывает:

CHK include/linux/version.h
CHK include/generated/utsrelease.h
CC scripts/mod/empty.o
gcc: error trying to exec ‘cc1’: execvp: No such file or directory
make[2]: *** [scripts/mod/empty.o] Ошибка 1
make[1]: *** [scripts/mod] Ошибка 2
make[1]: *** Ожидание завершения заданий.
make: *** [scripts] Ошибка 2

делаю симлинк cc1 на $HOME/cross/toolchain/arm-unknown-linux-uclibcgnueabi/bin/gcc в той же папке, выдаёт кучу такого:

cc1: /tmp/ccLcJ4l0.d: No such file or directory
cc1: empty: No such file or directory
cc1: unrecognized option ‘-quiet’
cc1: unrecognized option ‘-quiet’
cc1: error trying to exec ‘cc1’: execvp: Argument list too long
make[2]: *** [scripts/mod/empty.o] Ошибка 1
make[1]: *** [scripts/mod] Ошибка 2
make: *** [scripts] Ошибка 2

но этот файл scripts/mod/empty.o я нашёл только в исходниках ядра системы которая сейчас функционирует (т.е. /usr/src/linux-. )

Я собирал ядро под этот SoC с помощью CodeSourcery, не помню версию, но не суть важно. Попробуй им. mentor.com/embedded-software/codesourcery CROSS_COMPILE=arm-none-linux-gnueabi-

Buildroot умеет для этой железки (и не только) и загрузчик и ядро и корневую файловую систему собирать.

Ну я не пробовал. Но помоему тут надо makefile посмотреть.

Источник

Заводим GNU/Linux на ARM-плате с нуля (на примере Kali и iMX.6)

tl;dr: собираю образ Kali Linux для ARM-компьютера, в программе debootstrap , linux и u-boot .

Если вы покупали какой-нибудь не очень популярный одноплатник, то могли столкнуться с отсутствием для него образа любимого дистрибутива. Приблизительно то же самое случилось с планируемым Flipper One. Kali Linux под IMX6 просто нету (я готовлю), поэтому собирать приходится самостоятельно.

Процесс загрузки достаточно простой:

1. Инициализируется железо.
2. Из некоторой области на запоминающем устройства (SD-карта/eMMC/etc) считывается и выполняется загрузчик.
3. Загрузчик ищет ядро операционной системы и загружает его в некоторую область памяти и выполняет.
4. Ядро загружает всю остальную ОС.

Для моей задачи хватает такого уровня детализации, подробности можете прочесть в другой статье. Упомянутые выше «некоторые» области отличаются от платы к плате, что и создаёт некоторые сложности с установкой. Загрузку серверных ARM-платформ пытаются стандартизовать с помощью UEFI, но покуда это доступно не для всех, придётся собирать всё по отдельности.

Сборка корневой файловой системы

Для начала нужно подготовить разделы. Das U-Boot поддерживает разные ФС, я выбрал FAT32 для /boot и ext3 для корня, это стандартная разметка образов для Kali под ARM. Я воспользуюсь GNU Parted, но вы можете сделать то же самое более привычным fdisk . Также понадобятся dosfstools и e2fsprogs для создания ФС: apt install parted dosfstools e2fsprogs .

1. Отмечаем SD-карту как использующую MBR-разметку: parted -s /dev/mmcblk0 mklabel msdos
2. Создаём раздел под /boot на 128 мегабайт: parted -s /dev/mmcblk0 mkpart primary fat32 1MiB 128MiB . Первый пропущенный мегабайт необходимо оставить под саму разметку и под загрузчик.
3. Создаём корневую ФС на всю оставшуюся ёмкость: parted -s /dev/mmcblk0 mkpart primary ext4 128MiB 100%
4. Если вдруг у вас не создались или не изменились файлы разделов, надо выполнить `partprobe`, тогда таблица разделов будет перечитана.
5. Создаём файловую систему загрузочного раздела с меткой BOOT : mkfs.vfat -n BOOT -F 32 -v /dev/mmcblk0p1
6. Создаём корневую ФС с меткой ROOTFS : mkfs.ext3 -L ROOTFS /dev/mmcblk0p2

Отлично, теперь можно её заполнять. Для этого дополнительно потребуется debootstrap , утилита для создания корневых ФС Debian-подобных операционных систем: apt install debootstrap .

1. Монтируем раздел в /mnt/ (используйте более удобную для себя точку монтирования): mount /dev/mmcblk0p2 /mnt
2. Собственно заполняем файловую систему: debootstrap —foreign —include=qemu-user-static —arch armhf kali-rolling /mnt/ http://http.kali.org/kali . Параметр —include указывает дополнительно установить некоторые пакеты, я указал статически собранный эмулятор QEMU. Он позволяет выполнять chroot в ARM-окружение. Смысл остальных опций можно посмотреть в man debootstrap . Не забудьте, что не любая ARM-плата поддерживает архитектуру armhf .
3. Из-за разницы архитектур debootstrap выполняется в два этапа, второй выполняется так: chroot /mnt/ /debootstrap/debootstrap —second-stage
4. Теперь нужно зачрутиться: chroot /mnt /bin/bash
5. Заполняем /etc/hosts и /etc/hostname целевой ФС. Заполните по аналогии с содержимым на вашем локальном компьютере, не забудьте только заменить имя хоста.
6. Можно донастроить всё остальное. В частности я доустанавливаю locales (ключи репозитория), перенастраиваю локали и часовой пояс ( dpkg-reconfigure locales tzdata ). Не забудьте задать пароль командой passwd .
7. Задаём пароль для root командой passwd .
8. Приготовления образа для меня завершаются заполнением /etc/fstab внутри /mnt/ .

Загружать буду в соответствии с созданными ранее метками, поэтому содержимое будет таким:

LABEL=ROOTFS / auto errors=remount-ro 0 1
LABEL=BOOT /boot auto defaults 0 0

Наконец, можно примонтировать загрузочный раздел, он нам понадобится для ядра: `mount /dev/mmcblk0p1 /mnt/boot/`

Сборка Linux

Для сборки ядра (и загрузчика потом) на Debian Testing надо установить стандартный набор из GCC, GNU Make и заголовочных файлов GNU C Library для целевой архитектуры (у меня armhf ), а также заголовки OpenSSL, консольный калькулятор bc , bison и flex : apt install crossbuild-essential-armhf bison flex libssl-dev bc . Так как загрузчик по умолчанию ищет файл zImage на файловой системе загрузочного раздела, пора разбивать флешку.

1. Клонировать ядро слишком долго, поэтому просто скачаю: wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.9.1.tar.xz . Распакуем и перейдём в директорию с исходниками: tar -xf linux-5.9.1.tar.xz && cd linux-5.9.1
2. Конфигурируем перед компиляцией: make ARCH=arm KBUILD_DEFCONFIG=imx_v6_v7_defconfig defconfig . Конфиг находится в директории arch/arm/configs/ . Если такового нет, вы можете попробовать найти и скачать готовый и передать название файла в этой директории в параметр KBUILD_DEFCONFIG . В крайнем случае сразу переходите к следующему пункту.
3. Опционально можно докрутить настройки: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
4. И кроскомпилируем образ: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
5. Теперь можно скопировать файлик с ядром: cp arch/arm/boot/zImage /mnt/boot/
6. И файлы с DeviceTree (описание имеющегося на плате железа): cp arch/arm/boot/dts/*.dtb /mnt/boot/
7. И доустановить собранные в виде отдельных файлов модули: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=/mnt/ modules_install

Ядро готово. Можно всё отмонтировать: umount /mnt/boot/ /mnt/

Das U-Boot

Так как загрузчик интерактивный, для проверки его работы достаточно самой платы, запоминающего устройства и опционально устройства USB-to-UART. То есть, можно ядро и ОС отложить на потом.

Абсолютное большинство производителей предлагают использовать Das U-Boot для первичной загрузки. Полноценная поддержка обычно обеспечивается в собственном форке, но и в апстрим контрибьютить не забывают. В моём случае плата поддерживается в мейнлайне, поэтому форк я проигнорировал.

Cобираем сам загрузчик:

1. Клонируем стабильную ветку репозитория: git clone https://gitlab.denx.de/u-boot/u-boot.git -b v2020.10
2. Переходим в саму директорию: cd u-boot
3. Готовим конфигурацию сборки: make mx6ull_14x14_evk_defconfig . Это работает только если конфигурация есть в самом Das U-Boot, в ином случае вам потребуется найти конфиг производителя и положить его в корень репозитория в файл .config , или собрать иным рекомендованным производителем образом.
4. Собираем сам образ загрузчика кросс-компилятором armhf : make CROSS_COMPILE=arm-linux-gnueabihf- u-boot.imx

В результате мы получаем файл u-boot.imx , это готовый образ, который можно записывать на флешку. Записываем на SD-карту, пропустив первые 1024 байта. Почему я выбрал таргет u-boot.imx ? Почему пропустил именно 1024 байта? Так предлагают сделать в документации. Для других плат процесс сборки образа и записи может немного отличаться.

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

Вместо заключения

А вы знали, что лоб у дельфина не костистый? Это буквально третий глаз, жировая линза для эхолокации!

Источник