Make arch arm cross compile arm linux gnueabihf

lategoodbye / mainline_guide.md

Raspberry Pi: How to cross-compile and use Mainline Kernel

Notes on how to set up a new Ubuntu 18.04 LTS x64 environment, how to build the Mainline Kernel and place it on a Raspberry Pi OS SD card.

1. Install tools needed:

1. Install an up-to-date cross compiler and associated toolset. This may be obtained from https://releases.linaro.org/components/toolchain/binaries/latest-7/. The directory arm-linux-gnueabihf contains the necessary compiler for ARM 32-bit and the directory aarch64-linux-gnu for ARM 64-bit.

Choose the version suited to your development machine’s architecture. For example, at the present time, for use on 64-bit Ubuntu 18.04 on an Intel-based development machine, the appropriate version is gcc-linaro-7.3.1-2018.05-x86_64_arm-linux-gnueabihf.tar.xz .

1. Get Raspberry Pi Linux Sources (try to avoid linux-next which tends to be unstable)

1. Move into the repository folder and setup cross-compiler (for ARM 64-bit replace ARCH=arm with ARCH=arm64 ):

1. Choose the kernel configuration. To do this, you need to know what model of System on a Chip (SoC) is used on your Pi. Please refer to the Raspberry Pi Wikipedia Section. Since we are building from an upstream source, then, by reference to Emma Anholt’s pages we can deduce that we should select bcm2835_defconfig for BCM2835-based models, multi_v7_defconfig for BCM2836-, BCM2837- and BCM2711-based models (ARM 32-bit) or defconfig for BCM2837- and BCM2711-based models (ARM64). For the Raspberry Pi 3B Plus (ARM 32-bit), the following is appropriate:

1. At this point you can modify the configuration using, for instance, menuconfig . This is at least necessary for Raspberry Pi 4 (32 bit) to gain USB support by enabling CONFIG_ARM_LPAE and CONFIG_PCIE_BRCMSTB :

1. Build the kernel, the modules and the device tree blobs:

To speed up compilation on a multicore machine, add the argument -j to the above command.

1. Insert an existing Raspberry Pi OS SD Card to your development machine. Please keep in mind that kernel architecture must match accordingly (Raspberry Pi OS 32 bit for arm and Raspberry Pi OS 64 bit for arm64). In Ubuntu 18.04, it will appear at /media/ /boot and /media/ /rootfs , where is the username you are logged in under.
2. Copy the kernel file to the card’s boot directory (for ARM 64-bit the kernel file is just Image ):

1. Copy the device tree blob to the card’s boot directory. The exact device tree blob file to use depends on the model. The following is for a Raspberry Pi 3B Plus, so the device tree blob’s filename is bcm2837-rpi-3-b-plus.dtb (for ARM 64-bit the source directory is arch/arm64/boot/dts/broadcom ):

1. Adjust the device tree information in /media/ /boot/config.txt :

• Add the following lines to /media/ /boot/config.txt . The filename is that of the device tree blob copied over in Step 10. If /media/ /boot/config.txt already contains a device_tree entry, replace it with this. For ARM 64-bit the kernel is Image .

• In case you need to debug kernel issues during early boot stage, try the following settings according to your setup:

Board	console= (cmdline.txt)	earlycon= (cmdline.txt)	enable_uart= (config.txt)
Raspberry Pi 3	ttyS1,115200	uart8250,mmio32,0x3f215040	0

1. Copy the kernel modules to the SD card. Note that you need to be in superuser mode for this (for ARM 64-bit replace ARCH=arm with ARCH=arm64 ):

1. Safely dismount the SD card from the development machine, put it into the target machine and reboot.

• Avoid using rpi-update , as it will overwrite your mainline binary. The downstream kernel typically has problems with the upstream device tree blob.
• In some cases (e.g. the arm64 ), the kernel image tends to be very big (

16 MB) and may hit the limit of the boot partition.

The AUX UART has a different device name with mainline kernel: /dev/ttyS1 instead of /dev/ttyS0

Источник

Ubuntu Wiki

ARMKernelCrossCompile

The following instructions show how to properly download, tweak and cross compile an Ubuntu ARM kernel from an x86 Ubuntu host.

Vanilla Ubuntu armhf omap4 kernel compilation

First install the necessary tools for source code management and compilation:

Then download the code, switch to the omap4 branch and kick a build:

At the end of the process you will have an header and an image .deb in the upper level directory:

Config modify an Ubuntu omap4 kernel

Pretty much as above, but between the ‘fdr clean’ and ‘fdr binary-omap4’ you issue:

where ‘fdr’ stands for ‘fakeroot debian/rules’.

Choose the architecture you want to do modifications (armhf in our case):

do the config changes, save and ‘fdr binary-omap4’ to start a compilation of the new kernel.

1) What’s the difference between armel and armhf? And which should i pick?

Armhf requires a cpu with an FPU unit, while armel doesn’t strictly enforce it. As a rule of thumb, remember that from Precise onward Ubuntu uses armhf, while Oneiric and previous were armel based.

To create a package for armel, you need the armel toolchain (gcc-arm-linux-gnueabi) and an armel environment:

the rest is identical to the armhf case.

2) How do i mark my custom kernel to distinguish it form the stock one?

It’s possible to a add a suffix to kernel name modifying the changelog file. So, in our example, _before_ the ‘fdr clean’, open debian.ti-omap4/changelog, look for the first line and change it from:

This way the resulting .deb packages will have the custom «

mycustomkernel» suffix in their names. Remember, only letters and numbers are allowed.

3) Ok, but what about my Beagle/XM? How do i compile a kernel for an omap3 board?

Omap3 support is fully present in mainline, so stay in the master branch (do not switch to ti-omap4) and:

4) So far all the examples were Precise based, what about the other releases?

5) After export $(dpkg-architecture -aarmhf) i get a warning, what’s that?

Yes, it’s something like dpkg-architecture: warning: Specified GNU system type arm-linux-gnueabi does not match gcc system type i686-linux-gnu and it’s harmless. Forget about it.

6) How do i compile a vanilla/upstream arm kernel that works with an Ubuntu userspace?

i assume your cwd is a checkout of Linus git tree and we are compiling an armhf kernel for an omap3 board.

a) make ARCH=arm omap2plus_defconfig

b) edit .config and modify the following options:

Since 3.5 EHCI is broken for omap3 and was disabled upstream, to enable it again:

c) make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- uImage

d) copy arch/arm/boot/uImage to the sd card first partition overwriting ubuntu stock uImage

e) insert the sd card, and reboot

KernelTeam/ARMKernelCrossCompile (последним исправлял пользователь p-pisati 2012-10-05 13:05:25)

The material on this wiki is available under a free license, see Copyright / License for details.

Источник

Заводим 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 байта? Так предлагают сделать в документации. Для других плат процесс сборки образа и записи может немного отличаться.

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

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

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

Источник