Linux on arm board

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

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

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

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

Источник

Установка Linux на ARM. Подробная пошаговая инструкция и советы

Установка Linux на ARM — это довольно интересная тема. Даже принимая только то, что это довольно-таки необычно. Почему необычно? П отому что в ARM-процессорах совсем другая архитектура, чем у тех, для которых рассчитано большинство дистрибутивов Линукс.

Для тех , кто не знает, ARM — архитектура маленьких микр оп роцессоров. Если простым языком, то это архитектура процессора у маленьких компьютеров или мобильных телефонов. Поэтому вопрос : вы часто видели Linux на смартфоне (процессоре ARM)?

Основная масса больших и привычных ПК имеют архитектуру х86 или AMD64. Данные процессоры рассчитаны на трудо- и ресурсоемкие задачи:

• редактирование фотографий;
• редактирование музыки или видео;
• работа с базой данных;
• программирование и т.д .

Но в т о ж е время ARMка имеет более низкое энергопотребление при должной производительности, а это как раз очень важно для небольших устройств. И поэтому она распространена в «маленьких» устройствах.

Какие операционные системы подходят для ARM?

В принципе на ARM — устройствах можно запустить любую операционную систему, которая была скомпилирована под данную архитектуру. Поэтому обычные Линукс версии, которые мы уже привыкли наблюдать на своих ПК , просто не подойдут , д аже если они легковесны и подходят по другим параметрам. Но в т о ж е время в сети можно найти приличное количество уже «готовых» дистрибутивов Linux для ARM — процессоров. Ярким представителем является известный всем Android, из менее известных, но популярных — Kali Linux.

Кстати, а вы знали, что популярный Android мегакорпорации Google — это всего лишь «операционка» на основе ядра Linux ? Пр ит ом, что Андроид является самой популярной операционной системой для мобильных телефонов — этот факт, как видите, малоизвестен. Но вообще нужно понимать, что Linux здесь является всего лишь «ядром». А ядро — это всего лишь основной функционал, предполагающий использование устройствами опций аппаратной системы, драйверов, управления, утилиты для командной строки и др. Семейство Linux подразумевает совокупность всех операционных систем, использующих его ядро, но это не есть самостоятельное ядро. Различие всем системам «семейства» придает графическая оболочка, но это совсем другая история. Однако возможность использовать эти ОС без графической оболочки, а только через текстовую командную строку, расширяют сферу их применения. Именно поэтому их можно «заметить» в необычных местах:

• в сетевом оборудовании;
• в производственных станках;
• в начинке самолета или автомобиля;
• даже в современных стиральных машинах.

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

1. Debian. Это одна из самых старых версии Линукса, большое сообщество, много программ , написанных для этой системы, стабильность работы и мн.др. Его можно «найти» практически везде, также и в ARM — процессорах.
2. Ubuntu. Кто не слышал о б Убунту, тот не слышал о Линукс. С читается , что у него бо л ее продвинутое интерфейсное оформление, чем у Дебиан, да и вообще он сам более продвинутый. Встречается в ARM — процессорах, но совсем недавно анонсирована Ubuntu Phone — специальная ОС для смартфонов, которая будет призвана конкурировать с Android. Проект анонсирован, но пока должного «движения» не замечено.
3. Kali, Arch, Gentoo и др. , и каждый со своей отличительной особенностью , и каждый используется в ARM — системах.

На самом деле , этот список можно продолжать очень долго, потому что прогресс не стоит на месте, а земля наша слави тся умельцами. И многие разработчики «подтачивают» тот или иной дистрибутив Linux под ARM — процессор.

Установка Linux на ARM — устройство

Как правило, приобретая какое-либо устройство на ARM — процессоре, вы его получаете уже с предустановленной ОС. Чаще всего на таких устройствах идет Android. Допустим, вы все равно хотите установить Linux на это ARM — устройство. Тогда у вас есть 2 пути:

1. Полноценная «перепрошивка» на «чистое железо» ;
2. Установка «внутри» или «рядом» с Android (или другой системы, суть от этого не меняется).

При полной «перепрошивке» вы потеряете весь предустановленный производителем функционал. Вряд ли это будет то, чего вы добиваетесь. Поэтому тут можно воспользоваться вторым способом и установить Linux, не удаляя основную операционную систему вашего устройства. Для этого нужно будет настроить запуск chroot-окружения внутри Андроид. Но зато на выходе вы получите 2 параллельно установленные операционные системы и сможете использовать то одну, то другую. С т ак им подход ом можно поэкспериментировать на смартфонах или планшетах, где есть экран. А на простых безэкранных устройствах с таким способом могут возникнуть трудности.

Советы при установки Linux на ARM — устройство

На самом деле , совет будет один. Подумайте , прежде чем устанавливать Linux на свое ARM — устройство, тем более если на нем уже предустановлена производителем ОС. Потому что это не что иное , как хакинг — то есть преднамеренно е вмешательство в работу операционной системы. И никто , кроме вас , разделять риски работы устройства не будет.

Сама технология установки Linux на ARM еще в довольно «сырой» форме. Да, есть какие-то наработки и отдельные дистрибутивы. Есть умельцы, которые делают это и говорят, что это круто. Но в целом материала и стабильности в этом мало. Это не касается тех устройств, в которых Linux предустановлен производителем!

Но в т о ж е время четко вырисовывается тенденция, что за ARM — процессорами будущее. Этому свидетельствует даже тот факт, что первое место в рейтинге суперкомпьютеров ТОП — 500 в 2021 году с большим отрывом по производительности от конкурентов занимает машина на ARM — процессорах!

У ARM — процессоров масса преимуществ , поэтому, скорее всего , в обозримом будущем они будут стоять на наших персональных компьютерах. А это значит, что Linux на ARM — устройстве не будет диковинкой! А нужно ли вам это сейчас — решать вам.

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Linux on arm board

This project includes various files needed to run Linux on Arm boards, especially for development environments used to build Arm binaries.

The files are grouped by named releases:

• qemu — files used to run Arm Linux on QEMU

The supported Arm architectures are:

• armhf for 32-bit devices
• arm64 for 64-bit devices

As development environments for building Arm binaries, the Ubuntu 16.04.6 LTS (xenial) was selected, as it was the first major release that supported 64-bit Arm devices.

At uname -a they identify as:

• Linux ubu18-arm64 4.15.0-72-generic #81-Ubuntu SMP Tue Nov 26 12:21:09 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
• Linux ubu16-arm64 4.15.0-72-generic #81

16.04.1-Ubuntu SMP Tue Nov 26 16:31:09 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
Linux ubu16-armhf 4.15.0-72-generic-lpae #81

16.04.1-Ubuntu SMP Tue Nov 26 19:06:09 UTC 2019 armv7l armv7l armv7l GNU/Linux

Please note that the original kernel 4.4 that was distributed with Ubuntu 16 is not stable and under heavy loads some aplications crash with strange errors, like Internal compiler error.

A machine to run QEMU

Preferably a Linux machine, but macOS is also known to work.

In this case a headless Ubuntu 18.04 server Intel NUC with i7 and 32GB RAM was used ( ilg-xbb-linux.local ).

On Linux, the QEMU versions available on more conservative distributions, like Ubuntu 18.04, are too old to be usable, and in this case it is necessary to recompile QEMU form sources.

In this case the separate folder must be added to the PATH.

On some distributions there might be a separate qemu-utils which needs to be installed with the package manager.

On macOS, QEMU can be installed via Homebrew.

An install folder

Any place is fine, but somewhere in the HOME folder is better, for example:

Ubuntu cloud images

Ubuntu makes official images to be used in cloud environments, and these images can also be used directly by QEMU.

This saves quite a lot of time to generate local instances of the images, and is the prefered method.

The Ubuntu cloud images have a default user called ubuntu , but no password, and it is not possible to log to the machine.

The password must be paased as a separate user date file, created with the following sequence

The cloud-localds tool can be installed on Ubuntu with:

For convenience, this file can also be downloaded from the releases section.

There are other small trimmings that can be done:

Ubuntu home-made virtual disks

Before cloud images was discoverd, it was common to create the virtual images in house, but this process takes quite some time.

For convenience, ready to use virtual disk images are provided. The files are pristine, as they resulted after the initial install, without any changes. Due to GitHub limitations, the large files are split into several parts, and must be reassembled after download.

How to prepare the images yourself

For those who want to create the images themselves, the steps are documented in the separate HOW-TO-BUILD file.

How to extract the kernel and initrd yourself

For those who want to extract these files themselves, the steps are also documented in the separate HOW-TO-BUILD file.

These steps should be performed after the image is functional, but are documented here, before all specific versions install steps, since they apply to all versions.

The images, as they are published, are as generic as possible. You can continue to use them as is, or further customise them.

For example you can continue to use the initial user, or, if you prefer, you can add your own user and configure local settings.

Preferably add the locale settings to the shell .profile :

For long tasks it is also recommended to start them inside a screen session:

To power down the virtual machine, shutdown as usual:

In QEMU it is also possible to use Ctrl-A C, which will bring the QEMU prompt, and issue the system_powerdown command.

Ubuntu virtual disks

Ubuntu 18 arm64 (64-bit) cloud image

The Ubuntu system virtual image can be downloaded directly from Ubuntu.

Apart from the image itself, there are also several small files that need to be made available.

• the EFI raw image, is the monitor that identifies the kernel and the initrd and boots the system; it must be 64 MB long
• the EFI variable raw image, is the place where EFI can store different setting; it must be 64 MB long
• the cloud user data raw image, where different settings are passed to the generic cloud image (like passwords)
• the manifest file; it is not really needed by QEMU, it is downloaded for convenience, to know what packages are available

The first two must be passed to QEMU in this order as pflash drives.

$ touch .hushlogin ubuntu@ubuntu:

$ sudo touch /etc/cloud/cloud-init.disabled exit logout Ubuntu 18.04.3 LTS ubu18-arm64 ttyAMA0 ubu18-arm64 login: . «>

Subsequent restarts will be less verbose and do not start the cloud services.

With these options it is also possible to remotely login as user ubuntu via the port forwarder:

Ubuntu 16 arm64 (64-bit) image

TODO: update to cloud image

Download a ready to use home-made image

For 64-bit Arm Ubuntu 16.04.6, the image is:

• ubu16-arm64-hda.qcow2 ; it is about 2.4GB large and must be assembled from 3 parts.

The commands to download and reassemble are:

Download ready to use kernel and initrd

For 64-bit Arm Ubuntu 16.04.6, the ready to use files are:

The commands to download them are:

Start the virtual machine

With these new files available, it is possible to start the new virtual machine. If you work with a remote machine, preferably start qemu within a screen session. To allow for remote access to the virtual machine, add a forwarder to the ssh port (for example via port 30064).

After the system boots, you can login as user primus password primus (primus is latin for first).

Now it is also possible to remotely login as the new user.

The armhf (32-bit) image

TODO: update to cloud image

Download a ready to use home-made image

For 32-bit Arm Ubuntu 16.04.6, the image is:

• ubu16-armhf-hda.qcow2 ; it is about 2.4GB large and must be assembled from 3 parts.

The commands to download and reassemble are:

Download ready to use kernel and initrd

For 32-bit Arm Ubuntu 16.04.6, the ready to use files are:

The commands to download them are:

Start the virtual machine

With these new files available, it is possible to start the new virtual machine. If you work with a remote machine, preferably start qemu within a screen session. To allow for remote access to the virtual machine, add a forwarder to the ssh port (for example via port 30064).

After the system boots, you can login as user primus password primus (primus is latin for first).

Now it is also possible to remotely login as the new user.

Although running a virtual machine sacrifices some performance, QEMU is resonably fast, and for experimenting and even running some build scripts, it is acceptable.

About

Various files needed to run a Linux system on Arm boards

Источник