Clever Geek Handbook

Getting GNU / Linux on an ARM board from scratch (for example Kali and iMX.6)

tl; dr : build a Kali Linux image for an ARM computer, in a program debootstrap, linux and u-boot. If you bought some not very popular single-board device, then you might be faced with the lack of an image of your favorite distribution kit for it. Much the same thing happened with the planned Flipper One . Kali Linux for IMX6 simply does not exist (I am cooking), so I have to build it myself.











The download process is quite simple:



  1. Iron is initialized.
  2. From some area on the storage device (SD card / eMMC / etc) the bootloader is read and executed.
  3. The loader looks for the operating system kernel and loads it into some memory area and executes.
  4. The kernel loads the rest of the OS.


This level of detail is enough for my task, you can read the details in another article . The above mentioned "some" areas differ from board to board, which creates some difficulties with installation. They are trying to standardize the loading of server ARM platforms using UEFI, but as long as this is not available for everyone, you will have to collect everything separately.



Building the root filesystem



First you need to prepare the sections. Das U-Boot supports different filesystems, I chose FAT32 for /bootand ext3 for the root, this is the standard image markup for Kali under ARM. I'll use GNU Parted, but you can make the same thing more familiar fdisk. Also it needs dosfstoolsand e2fsprogsto create a file system: apt install parted dosfstools e2fsprogs.



We mark up the SD card:



  1. Mark the SD card as using MBR markup: parted -s /dev/mmcblk0 mklabel msdos
  2. Create a section by /boot128 megabytes: parted -s /dev/mmcblk0 mkpart primary fat32 1MiB 128MiB. The first missed megabyte must be left for the markup itself and for the bootloader.
  3. We create a root file system for the entire remaining capacity: parted -s /dev/mmcblk0 mkpart primary ext4 128MiB 100%
  4. If suddenly your partition files have not been created or changed, you need to execute `partprobe`, then the partition table will be re-read.
  5. Create a boot partition filesystem with label BOOT:mkfs.vfat -n BOOT -F 32 -v /dev/mmcblk0p1
  6. Create a root file system with a label ROOTFS:mkfs.ext3 -L ROOTFS /dev/mmcblk0p2


Great, now you can fill it out. To do this will require an additional debootstraputility to create a root filesystem Debian-based operating systems apt install debootstrap.



We collect FS:



  1. Mount the partition to /mnt/(use a more convenient mount point):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. Set a password for the rootcommand passwd.
  8. The preparation of the image for me ends with the filling /etc/fstabinside /mnt/.


I will load in accordance with the tags created earlier, so the content will be like this:

LABEL = ROOTFS / auto errors = remount-ro 0 1

LABEL = BOOT / boot auto defaults 0 0


Finally, you can mount the boot partition, we need it for the kernel: `mount / dev / mmcblk0p1 / mnt / boot /`



Building Linux



To build the kernel (and then the boot loader) on Debian Testing is necessary to establish a standard set of GCC, GNU Make and GNU C Library header files for the target architecture (I armhf), as well as the OpenSSL headers, console calculator bc, bisonand flex: apt install crossbuild-essential-armhf bison flex libssl-dev bc. Since the bootloader by default looks for a file zImageon the file system of the boot partition, it's time to partition the USB flash drive.



  1. Clone core too long, so just download: wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.9.1.tar.xz. Unpack it and go to the source directory:tar -xf linux-5.9.1.tar.xz && cd linux-5.9.1
  2. Configure before compilation: make ARCH=arm KBUILD_DEFCONFIG=imx_v6_v7_defconfig defconfig. The config is in the directory arch/arm/configs/. If there is none, you can try to find and download the ready one and pass the name of the file in this directory to the parameter KBUILD_DEFCONFIG. As a last resort, go straight to the next point.
  3. Optionally, you can adjust the settings: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- menuconfig
  4. And we will compile the image: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
  5. Now you can copy the file with the kernel: cp arch/arm/boot/zImage /mnt/boot/
  6. And files with DeviceTree (description of the hardware available on the board): cp arch/arm/boot/dts/*.dtb /mnt/boot/
  7. And install the modules assembled as separate files: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- INSTALL_MOD_PATH=/mnt/ modules_install


The kernel is ready. You can unmount everything:umount /mnt/boot/ /mnt/



Das U-Boot



Since the bootloader is interactive, the board itself, a storage device, and an optional USB-to-UART device are enough to test its operation. That is, you can postpone the kernel and OS for later.



The vast majority of manufacturers suggest using Das U-Boot for initial boot. Full support is usually provided in its own fork, but they don’t forget to contribute to the upstream. In my case, the board is supported in the mainline , so I ignored the fork .



We collect the bootloader itself:



  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


As a result, we get a file u-boot.imx, this is a ready-made image that can be written to a USB flash drive. We write to the SD card, skipping the first 1024 bytes. Why did I choose the target u-boot.imx? Why did I skip exactly 1024 bytes? This is what the documentation suggests . For other boards, the image building and burning process may be slightly different.



Done, you can boot. The bootloader should report its own version, some board information and try to find the kernel image on the partition. If unsuccessful, it will try to boot over the network. In general, the output is quite detailed, you can find an error in case of a problem.



Instead of a conclusion



Did you know that a dolphin's forehead is not bony? It's literally a third eye, a fatty lens for echolocation!









More articles:


All Articles