Building a root file system

In this post we are going to build a root file system from scratch using Busybox and test it on QEMU.

Download the latest version of BusyBox (1.20.2 for the time being)

Extract the file and get into directory

$ cd busybox-1.20.2

Let’s use the default configuration and modify it according to our needs.

$ make ARCH=arm CROSS_COMPILE=arm-linux-  defconfig

$ make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig

Under the same menu you go to “Open the menu “Installation  Options (make install behavior) –> (./_install) BusyBox installation prefix

This option means that the root file system will be installed inside _install directory. You can change it if you like. Let’s leave it as it is.

Start building our root file system.

$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- install

If the compilation ends successfully the root file system will be in _install directory.

$ cd _install

It seems that some of the directories that we are accustomed to see in a normal Linux distro are missing. We will create them manually.

$ mkdir proc sys dev etc etc/init.d

$ cd ..

We will now create a bash script in order to mount some devices automatically after the boot.

$ touch etc/init.d/rcS

Modify its content as

mount -t proc none /proc

mount -t sysfs none /sys

Now change the file’s mode as executable.

$ chmod +x etc/init.d/rcS

Then create an image of the root file system and compress it.

$ cd ..

$ gzip –c rootfs.img > rootfs.img.gz

We had created a kernel image in the previous examples. You can copy the kernel image to BusyBox directory. We can try our fresh root file system on QEMU

$ qemu-system-arm -M versatilepb -m 128M -kernel zImage -initrd rootfs.img.gz -append “root=/dev/ram rdinit=/sbin/init”

QEMU will boot the kernel and load the root file system. Just press “ENTER” to see shell prompt.

QEMU-Busybox

In this post we are going to build a root file system from scratch using Busybox and test it on QEMU.

Download the latest version of BusyBox (1.20.2 for the time being)

Extract the file and get into directory

$ cd busybox-1.20.2

Let’s use the default configuration and modify it according to our needs.

$ make ARCH=arm CROSS_COMPILE=arm-linux-  defconfig

$ make ARCH=arm CROSS_COMPILE=arm-linux- menuconfig

Under the same menu you go to “Open the menu “Installation  Options (make install behavior) –> (./_install) BusyBox installation prefix

This option means that the root file system will be installed inside _install directory. You can change it if you like. Let’s leave it as it is.

Start building our root file system.

$ make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- install

If the compilation ends successfully the root file system will be in _install directory.

$ cd _install

It seems that some of the directories that we are accustomed to see in a normal Linux distro are missing. We will create them manually.

$ mkdir proc sys dev etc etc/init.d

$ cd ..

We will now create a bash script in order to mount some devices automatically after the boot.

$ touch etc/init.d/rcS

Modify its content as

mount -t proc none /proc

mount -t sysfs none /sys

Now change the file’s mode as executable.

$ chmod +x etc/init.d/rcS

Then create an image of the root file system and compress it.

$ cd ..

$ gzip –c rootfs.img > rootfs.img.gz

We had created a kernel image in the previous examples. You can copy the kernel image to BusyBox directory. We can try our fresh root file system on QEMU

$ qemu-system-arm -M versatilepb -m 128M -kernel zImage -initrd rootfs.img.gz -append “root=/dev/ram rdinit=/sbin/init”

QEMU will boot the kernel and load the root file system. Just press “ENTER” to see shell prompt.

QEMU-Busybox

Introduction to Buildroot

Making root file systems have multiple methods:

1 use busybox handmade
Busybox itself contains a very Linux command, but if you need to compile other programs, you need to download, compile, if it needs some dependency library, you also need to manually download, compile these dependencies.
If you want to make a minimal file system, you can use BusyBox handmade.

2 automatic production using Buildroot
It is a high system that is highly configured, compiles the kernel, configures compiles to compile root file systems. When compiling some app, it will automatically download the source code, download its dependency library, and automatically compile these programs.
Buildroot’s syntax is similar to the general Makefile syntax, it is easy to master.

3 use YOCTO
NXP, ST and other companies use YOCTO, but YOCTO syntax is complicated, and YOCTO is 10GB, download and installation is difficult, ordinary notebook compiles may take 2-3 days or even longer, very uncomfortable for beginners (we don’t It is recommended to use the YOCTO build file system).

Based on the above features, we choose Buildroot.

Buildroot is a set of makefile and patches that simplify and automate the build, bootable Linux environment for embedded systems.
(Including the BootLoader, Linux kernel, file system that contains various apps). BuildRoot runs in the Linux platform, you can build embedded Linux platforms for multiple target boards using cross-compilation tools. Buildroot automatically builds the required cross-compilation toolchain, create a root file system, compiles the Linux kernel image, and generates a boot loader for the target embedded system, or it can perform any independent combination of these steps. For example, you can use the installed cross-compilation toolchain separately, and BuildRoot only creates a root file system.

Building a root file system

Now that we have learned the process of building the kernel and applications, the next logical step is to understand the process of making a root file system. As explained in Chapters 2 and 4, there are three techniques that can be used for this purpose.

■ Using the initrd/initramfs: The initrd was discussed in detail in Chapters 2 and 4. In this section we discuss initramfs. The scripts at the end of this section can be used to create these images.

■ Mounting the root file system over the network using NFS: This makes sense during the development stages; all changes can be done on the development (host) machine and the root file system can be mounted across the network from the host. The details of how to mount the root file system using NFS can be obtained from the documentation that is part of the kernel source tree under Documentation/nfsroot.

Listing 8.3 mkinitrd

# create ramdisk image file /bin/rm -f /tmp/ramdisk.img dd if=/dev/zero of=/tmp/ramdisk.img bs=1k count=$2

# Setup loop device

# Create filesystem

fi mkdir /tmp/ramdisk0

chown -R root /tmp/ramdisk0/*

chgrp -R root /tmp/ramdisk0/*

ls -lR /tmp/ramdisk0

# unmount umount /tmp/ramdisk0 rm -rf /tmp/ramdisk0

# unhook loop device /sbin/losetup -d /dev/loop0

■ Burning the root file system into flash: This is done during the production stage. The image of the root file system to be run on the target (such as JFFS2 or CRAMFS) is created on the host and is then burned to flash. The various tools that are available for making the images are explained in Chapter 4.

Listing 8.3 shows a generic initrd script. Its usage is:

mkinitrd <rfs-folder> <ramdisk-size>

■ <rfs-folder> is the absolute path of the parent directory containing the root file system.

■ <ramdisk-size> is the size of initrd.

The script creates an initrd image /tmp/ramdisk.img that could be mounted as an ext2 file system on the target. It uses a loopback device / dev/loopO to copy files from the root file system folder <rfs-folder> to the target image /tmp/ramdisk.img.

Дополнительно:  Ошибка driver_irql_not_less_or_equal файл ndis.sys в windows 7

As you can mount the initrd image as the root file system, you can also similarly mount the initramfs image as the root file system. Initramfs is based on the RAMFS file system and initrd is based on ramdisk. The differences between RAMFS and ramdisk are shown in Table 8.1. The initramfs image can be created using mkinitramfs script. Its usage is:

Continue reading here: Embedded Graphics

Was this article helpful?

Copy the rootfs contents on microSD

Format a new microSD.

~/debian_jessie$ sudo rsync -axHAX --progress target-rootfs/ /media/$USER/rootfs/

Unmount the microSD, insert it in your board, insert the DPI cable to see the Kernel bootstrap
messages and boot.

Create the root filesystem

When your multistrap.conf file is ready launch type:

  • if you are using a board without FPU like FOX Board G20, Aria G25 or Arietta G25 type for example:
~/debian_jessie$ sudo multistrap -a armel -f multistrap_boardname.conf
  • if you are using a board with FPU like Acqua A5 type:
~/debian_jessie$ sudo multistrap -a armhf -f multistrap_acqua.conf

At the end of this procedure the directory target-rootfs directory will contents
the whole rootfs tree to be moved into the second partition of an Acme board bootable microSD.

Configure now the Debian packages using the armel CPU emulator QEMU and chroot to
create a jail where dpkg will see the target-rootfs as its root (/) directory.

~/debian_jessie$ sudo cp /usr/bin/qemu-arm-static target-rootfs/usr/bin
~/debian_jessie$ sudo mount -o bind /dev/ target-rootfs/dev/
~/debian_jessie$ sudo LC_ALL=C LANGUAGE=C LANG=C chroot target-rootfs dpkg --configure -a

At this prompt:

Building a root file system

Reply with < No >.

Some other prompt will appear during the configuration. Reply to them as you like.

When finished the target rootfs will be almost ready to be moved on the
target microSD but it still needs some last extra configuration file before using it.

Based on type board you are using select one of these script to create the the
right configuration files:

~/debian_jessie$ chmod +x arietta.sh
~/debian_jessie$ sudo ./arietta.sh

create now the target root login password:

~/debian_jessie$ sudo chroot target-rootfs passwd
Enter new UNIX password: type your password
Retype new UNIX password: type your password again
passwd: password updated successfully

If you want to take a look to the packages installed type:

~/debian_jessie$ sudo chroot target-rootfs dpkg --get-selections | more

Check the Debian version installed:

~/debian_jessie$ cat target-rootfs/etc/debian_version
8.2

Add more packages if needed by typing:

~/debian_jessie$ sudo LC_ALL=C LANGUAGE=C LANG=C chroot target-rootfs apt-get update
~/debian_jessie$ sudo LC_ALL=C LANGUAGE=C LANG=C chroot target-rootfs apt-get install packagename

Please note that will be possible to add packages also directly on the target board. In than case the
command will be simply:

# apt-get install packagename

then remove the qemu-arm-static executable:

~/debian_jessie$ sudo rm target-rootfs/usr/bin/qemu-arm-static

Profile description

Building a root file system

Building a root file system

  • In / dev directory:
     MKNOD Console C master number number / * C means character device file * /        
     MKNOD NULL C main device number number
    

    The above operations belong to a static creation of various nodes (ie equipment files);

    MDEV is a simplified version of UDEV, but also to create device files by reading kernel information;

    There are two main purposes for MDEV:

    • Initialization / dev directory;
    • Dynamic update (not only updated / dev directory, also supporting hot-swapping, access, implementing certain actions);

    To use MDEV, you need a kernel to support the SYSFS file system. In order to reduce the read and write to Flash, you must support the TMPFS file system, so make sure the kernel has set the config_sysfs and config_tmpfs configuration items;

    To start the kernel, you will automatically run the MDEV and need to modify two files:

    • / etc / fstab comes from mounting file systems;

      #device    mount_point    type    options    dump    fsck order
       proc       /proc         proc     defaults   0         0
       tmpfs      /tmp          tmpfs    defaults   0         0
       sysfs      /sys          sysfs    defaults   0         0
       tmpfs      /dev          tmpfs    defaults   0         0
      
    • /etc/init.d/rcs joins the automatic run command;

      mount -a
      mkdir /dev/pts
      mount -t devpts devpts /dev/pts
      echo /sbin/mdev > /proc/sys/kernel/hotplug
      mdev -s
      

    Also note: MDEV is initiated by the init process, before using the MDEV constructor / dev directory, the init process is to be used to use the device file / dev / console, / dev / null, so to manually create these two device files:

    Mkdir -P / NFS_ROOT / MINI_ROOTFS / DEV / * Build / dev directory in the file system directory * /
    cd /nfs_root/mini_rootfs/dev
    sudo mknod console c 5 1
    sudo mknod null c 1 3
    
  • INIT -> BusyBox (there is BUSYBOX compiled);

  • Create a / etc directory and enter this directory to create a configuration file initTab;

    What are the applications currently in the kernel run, this information is available in a virtual file system PROC provided by the kernel, executing a command PS view;

    mount -t proc none / proc / * Plug the virtual file system PROC in / proc directory * /
     After the PS / * is executed, after the PS command is required, see which programs in the / proc directory * /
    

    If you don’t want to manually mount, you can modify it in the configuration file, change to automatic mount;

    For example, add a script in the / etc / inittab configuration file:

    ::sysinit:/etc/init.d/rcS
    

    Increase the RCS file under the /etc/init.d directory, the content is:

    mount -t proc none /proc
     CHMOD + X /ETC/INIT.D/RCS / * Adds the runable properties * /
    

    Increase the RCS file in the /etc/init.d directory, the contents of the file are:

    mount -a
    

    Then in / etc directoryAdd files fSTAB, Means that when the «mount -a» command is executed, the / etc / fstab file will be read, and the mount file system is performed according to the content in this configuration file;

    #device     mount-point    type     options   dump   fsck order
     proc          /proc       proc     default    0        0  
    
    • Device to be mounted, it is meaningless for the field system of the Proc file system, which can be any value;
    • Mount-point hook;
    • TYPE file system type, such as Proc, Jffs2, YAFFS, etc., or Auto automatically detect file types;
    • Options Mounting parameters, separated by commas;
  • Profile specified by the configuration file;

  • When making a cross-compilation tool chain, a GLIBC library has been generated (locations in /gcc-3.4.5-glibc-2.3.6/ARM-LINUX/LIB, this directory is not a glibc library, such as ctrl.o, libstdc ++ .a and other files, the GCC tool itself is generated, can use it directly to build the root file system;

    mkdir -p /nfs_root/mini_rootfs/lib
    cd /gcc-3.4.5-glibc-2.3.6/arm-linux/lib
     CP * .so * / nfs_root / mini_rootfs / lib -d / * plus -d "is originally a link file, copying is still a link file, otherwise copy the link to which the link is directed, resulting in excessive files * /
    
  • Architecture Other Directory

    Other directories can be empty catalog, such as Proc, MNT, TMP, SYS, etc .;

The steps to build a root file system are somewhat chaos, summarized in this:

  • After busybox configuration, compile, after installation, there will be bin, linuxrc, sbin, usr, etc. in the installation directory;
  1. Tab key automatic

    Busybox Settings ->
    	Busybox Library Tuning ->
    		[*] Tab completion
    
  2. To use the loading module

    Linux Module Utilities ->
    	[*] insmod
    	[*] rmmod
    	[*] lsmod
    	[*] modprobe
    
  • Create an ETC / INITTAB file

    #/etc/inittab
    ::sysinit:/etc/init.d/rcS
    console::askfirst:-/bin/sh
    ::ctrlaltdel:/sbin/reboot
    ::shutdown:/bin/umount -a -r
    
  • Create an ETC / Init.D / RCS file

    #!/bin/sh
    ifconfig eth0 192.168.3.10
    mount -a
    mkdir /dev/pts
    mount -t devpts devpts /dev/pts
    echo /sbin/mdev > /proc/sys/kernel/hotplug
    mdev -s
    

    Note: To perform CHMOD + X etc / init.d / rcs, plus executable permissions;

  • Create an ETC / FSTAB file

    Mounts in the ETC / FSTAB when performing «mount -a» in the script file RCS;

    #device    mount_point    type    options    dump    fsck order
     proc       /proc         proc     defaults   0         0
     tmpfs      /tmp          tmpfs    defaults   0         0
     sysfs      /sys          sysfs    defaults   0         0
     tmpfs      /dev          tmpfs    defaults   0         0      
    
  • Build a DEV directory

    Create / dev directory in the file system directory built by mkdir -p dev / * * /
    cd dev
    sudo mknod console c 5 1
    sudo mknod null c 1 3
    
  • Build another directory

    mkdir proc mnt tmp sys 
    
  • Build a lib directory

    mkdir -p lib
    cd ./lib
    cp /work/s3c2440/tools/gcc-3.4.5-glibc-2.3.6/arm-linux/lib/*.so* ./ -d
    
  • The minimum root file system has been basically constructed, and some tools can be used to make the root file system into the flash file to flash, and the NFS mount can also be set;

Build a Debian Linux root filesystem

This article illustrates how to build an Debian Linux root filesystem to
on the armel and armhf boards made by Acme Systems

A Debian Stretch 9.x will be generated but it is possible to change Debian version
changing the name in any script and configuration file provided here

Requirements

To create the rootfs contents you need a Linux PC (we used a Debian or Ubuntu)
with the some packages installed. Type these commands to install them:

sudo apt-get update
sudo apt-get install multistrap qemu qemu-user-static binfmt-support dpkg-cross

Use Multistrap to generate the rootfs contents

Multistrap is a tool that automates the creation of complete, bootable,
Debian root filesystems. It can merge packages from different repositories.
Extra packages are added to the rootfs simply by listing them. All
dependencies are taken care of.

Дополнительно:  Как обойти root права

Create a working directory in your home directory:

mkdir debian_stretch
cd debian_stretch

Download the configuration file for your board:

Read Multistrap man page to understand each directive
meaning.

Create the root filesystem

If you are using an armhf board use one of the command below:

sudo multistrap -a armhf -f multistrap_roadrunner.conf
sudo multistrap -a armhf -f multistrap_acqua.conf

If you are using an armel board use one of the command below:

sudo multistrap -a armel -f multistrap_aria.conf
sudo multistrap -a armel -f multistrap_arietta.conf

At the end of this procedure the directory target-rootfs directory will contents
the whole rootfs tree to be moved into the second partition of an Acme board bootable microSD.

Configure now the Debian packages using the armel CPU emulator QEMU and chroot to
create a jail where dpkg will see the target-rootfs as its root (/) directory.

sudo cp /usr/bin/qemu-arm-static target-rootfs/usr/bin
sudo mount -o bind /dev/ target-rootfs/dev/
sudo LC_ALL=C LANGUAGE=C LANG=C chroot target-rootfs dpkg --configure -a

At this prompt Reply with < No >:

Building a root file system

Some other prompt will appear during the configuration. Reply to them as you like.

When finished the target rootfs will be almost ready to be moved on the
target microSD but it still needs some last extra configuration file before using it.

Based on type board you are using download one of these script to create the the
right configuration files:

Then launch it by typing for example:

chmod +x aria.sh
sudo ./aria.sh

create now the target root login password:

sudo chroot target-rootfs passwd

Enter new UNIX password: 
Retype new UNIX password: 
passwd: password updated successfully

If you want to take a look to the packages installed type:

sudo chroot target-rootfs dpkg --get-selections | more

Check the Debian version installed:

cat target-rootfs/etc/debian_version

Add more packages if needed by typing:

sudo LC_ALL=C LANGUAGE=C LANG=C chroot target-rootfs apt-get update
sudo LC_ALL=C LANGUAGE=C LANG=C chroot target-rootfs apt-get install package1 package2 ...

then remove the qemu-arm-static executable:

sudo rm target-rootfs/usr/bin/qemu-arm-static

Enable the root access via ssh

By default the sshd server is installed inhibiting the root login via ssh.
To enabled it change in target-rootfs/etc/ssh/sshd_config this line:

#PermitRootLogin prohibit-password
PermitRootLogin yes

Copy the rootfs contents on microSD

Format a new microSD.

sudo rsync -axHAX --progress target-rootfs/ /media/$USER/rootfs/

Unmount the microSD, insert it in your board, insert the DPI cable
to see the Kernel bootstrap messages and boot.

In case you have used a remote Linux server to made your rootfs contents use this
command to compress the filetree and save download time:

cd target-rootfs
sudo tar -cvjSf ../rootfs.tar.bz2 .

To move the rootfs contents inside the bootable Linux microSD use:

sudo tar -xvjpSf rootfs.tar.bz2 -C /media/$USER/rootfs 
sync

Systematic Interpretation

What improvements we have done?
We are based on the Buildroot official 2020.02 long-term support version to adapt 100ASK-STM32MP1MP1MP1MP157-PRO development board, on this basis, a large number of cropping systems for the St Yocto release system, add support for QT5.12 EGLFS libraries on the basis of ensuring the minimum system At the same time, it also supports OpenCV3 programming MQTT library Swupdate OTA upgrades, and we will also provide how to add your own package tutorial in Buildroot, and the source code is saved on Gitee, the link address isEveryone can submit Issue or Pull Request on it.

INIT (short-to-English: Initialization) is a program used to generate all other processes in UNIX and class UNIX systems. It exists in a daemon, its process number is 1. After loading the Linux kernel during boot, the Linux kernel loads the init program, which completes the rest of the boot process, such as loading the run level, load service, boot the shell / graphical interface, and more.

What is the SYSTEMV daemon?
System V (abbreviated as sysv) is the most widely used in most Linux issues. In SystemV, there is a first program running after the kernel is loaded. This program is called init. INIT does something, one of them is to load a series of scripts to launch a variety of system services, such as networks, SSH daemons, and more. The running level in System V describes some states. E.g:

  • Run level 0: Pause
  • Run Level 1: Single User Mode
  • Run Level 6: Restart

The systemv problem is that it needs to be carefully adjusted. Suppose you have a network file system (NFS) client that is running at startup. There is no significance to run NFS before the network is working properly. Therefore, you must make sure it waits to start until the network has been working properly. Systemv init is a strict order for service startup settings. Each service is allocated with a priority number, and init will start the service in priority order. If you need to ensure that the service is started after the network is connected, you must manually assign a higher priority to the service. This must be done by someone (usually a package maintor) for each service running on the computer.

Building a root file system

All System V initialization scripts are stored in the /etc/rc.d/init.d/ or /etc/init.d directory. These scripts are used to control the startup and closing of the system. Often, you will find a script that starts the SSH server or network in this directory, use /etc/init.d/s50sshd Start to turn a service with /etc/init.d/s50sshd Stop.

What is the SYSTEMD daemon?
SYSTEMD This name is from a convention in UNIX: the suffix identity of the system daemon (English: Daemon, also known as a background process) in UNIX. In addition, SYSTEMD is also a borrowed English term D system, which is used to describe a person who has a rapid adaptation of the environment and solves the difficulties.

Systemd is a centralized system and setup management program (init) under the Linux computer operating system, including daemon, library, and application software, by Lennart Poettering. Its development goal is to provide a better framework to represent the dependencies between system services, and achieve parallel launch of service when system initialization, and achieve the effect of lowering the SHELL system overhead, eventually replacing the currently used System V and BSD style Init program. At present, most Linux distributions have used systemD instead of the original Xaxaxasystem V.

Building a root file system

What can you do with Buildroot we offer?
Quickly implement your own ideas, add your own app, learn how busybox and how to compile generation, used to debug kernel or applications, and more.

Configuration Compile BUSYBOX

Make menuConfig / * will create a .config file * /
 Make / * Compile BUSYBOX, make sure that the cross_compile of Makefile has been modified * /
 Make install / * or "make config_prefix = / path / from / root install" 
                                     * Really implemented "make config_prefix = / Work / NFS_ROOT / FS_MINI Install" Prerequisitated * In / Work Directory, you have created / nfs_root / fs_mini directory
                  */

Compile, after installation, it will be in the corresponding path folder (ie / Work / NFS_ROOT / FS_MINI) is: / bin, / linuxrc, / sbin, / usr, etc .;

Root file system

For root file systems, the development board can start it as a network root file system or produce it as a file (image file) to burn into the development board;

Network file systems can use NFS, you need to pay attention to two points:

  1. Make sure the server allows that directory to be mounted;
  2. After the board is started, go to mount;
  • Modify the configuration file for NFS services

    vi /etc/exports
     / * Will need to be mounted to increase the file system directory to the configuration file * /
     Sudo /etc/init.d/nfs-kernel-server restart / * restart NFS service * /
     Sudo Mount -t NFS server address: / can be mounted directory / MNT / * can first check if it can be mounted on the computer * /
    
  • Manually mount (start the root file system from Flash, use the command to mount NFS)

    ifconfig eth0 up
    ifconfig eht0 192.168.3.11
    mkdir /mnt
     Mount -t NFS -O NOLOCK server address: Directory / MNT in the root file system
    
  • Can start directly from NFS directly

    You need to set the startup parameters, set the format to refer to the NFSROOT.TXT document under the Linux kernel / Documentation directory;

    / * Format: noinitrd root = / dev / nfs nfsroot = [<server-ip>:] <root-dir> [, <nfs-options>] ip = <client-ip>: <server-ip>: <gw -ip>: <netmask>: <hostname>: <device>: <autoconf> * /
    set bootargs noinitrd root=/dev/nfs nfsroot=192.168.3.5:/work/nfs_root/mini_rootfs ip=192.168.3.10:192.168.3.5:192.168.3.1:255.255.255.0::eth0:off init=/linuxrc console=ttySAC0
    

Use Multistrap to generate the rootfs contents

«Multistrap is a tool that automates the creation of complete, bootable,
Debian root filesystems. It can merge packages from different repositories.
Extra packages are added to the rootfs simply by listing them. All
dependencies are taken care of.»
.

Дополнительно:  Memory management в Windows 10 (и синий экран). Как можно попытаться исправить проблему

Create a working directory in your home directory:

mkdir multistrap
cd multistrap

Download the right multistrap configuration file for your board:

Read Multistrap man page to understand each directive meanings.

Build a Debian Jessie root filesystem

Building a root file system

This article illustrates how to build an Debian Jessie root filesystem for
the all the Acme Systems boards based on Atmel MCU

Enable the root access via ssh

By default the sshd server is installed inhibiting the root login via ssh.
To enabled it change in target-rootfs/etc/ssh/sshd_config this line:

PermitRootLogin without-password
PermitRootLogin yes

Mirror file

The file output path is OUTPUT / IMAGES after compiling

Building a root file system

You can refer to the «Chapter 7 Overall System or Update Site System» to the SD / TF card to the SD / TF card, you can start the development board into the system through the TF card.

Requirements

To create the rootfs contents you need an Ubuntu PC (we used
an Ubuntu 15.04) with the some packages installed. Type these commands
to install them:

~$ sudo apt-get install multistrap
~$ sudo apt-get install qemu
~$ sudo apt-get install qemu-user-static
~$ sudo apt-get install binfmt-support
~$ sudo apt-get install dpkg-cross

Requirements

To create the rootfs contents you need an Linux PC with the some packages installed. Type these commands
to install them:

sudo apt-get update
sudo apt-get install multistrap qemu qemu-user-static binfmt-support dpkg-cross

Copy the rootfs contents on microSD

Format a new microSD.

sudo rsync -axHAX --progress target-rootfs/ /media/$USER/rootfs/

Unmount the microSD, insert it in your board, insert the DPI cable to see the Kernel bootstrap
messages and boot.

Create the root filesystem

When your multistrap.conf file is ready launch type:

if you are using a board without FPU (Floating Point Unit) like FOX Board G20, Aria G25 or Arietta G25 type for example:

sudo multistrap -a armel -f multistrap_arietta.conf

if you are using a board with FPU like Acqua A5 type:

sudo multistrap -a armhf -f multistrap_roadrunner.conf

At the end of this procedure the directory target-rootfs directory will contents
the whole rootfs tree to be moved into the second partition of an Acme board bootable microSD.

Configure now the Debian packages using the armel CPU emulator QEMU and chroot to
create a jail where dpkg will see the target-rootfs as its root (/) directory.

sudo cp /usr/bin/qemu-arm-static target-rootfs/usr/bin
sudo mount -o bind /dev/ target-rootfs/dev/
sudo LC_ALL=C LANGUAGE=C LANG=C chroot target-rootfs dpkg --configure -a

At this prompt:

Building a root file system

Reply with < No >.

Some other prompt will appear during the configuration. Reply to them as you like.

When finished the target rootfs will be almost ready to be moved on the
target microSD but it still needs some last extra configuration file before using it.

Based on type board you are using select one of these script to create the the
right configuration files:

launch the script:

chmod +x roadrunner.sh
sudo ./roadrunner.sh

create now the target root login password:

sudo chroot target-rootfs passwd
Enter new UNIX password: [type your password]
Retype new UNIX password: [type your password again]
passwd: password updated successfully

If you want to take a look to the packages installed type:

sudo chroot target-rootfs dpkg --get-selections | more

Check the Debian version:

cat target-rootfs/etc/debian_version

Add more packages if needed by typing:

sudo LC_ALL=C LANGUAGE=C LANG=C chroot target-rootfs apt-get install [packagename]

Please note that will be possible to add packages also directly on the target board. In than case the
command will be simply:

apt-get install packagename

then remove the qemu-arm-static executable:

sudo rm target-rootfs/usr/bin/qemu-arm-static

Use Multistrap to generate the rootfs contents

«Multistrap is a tool that automates the creation of complete, bootable,
Debian root filesystems. It can merge packages from different repositories.
Extra packages are added to the rootfs simply by listing them. All
dependencies are taken care of.»
.

Create a working directory in your home directory:

~$ mkdir debian_jessie
~$ cd debian_jessie
~/debian_jessie$

Download the configuration file for your board:

Read Multistrap man page to understand each directive meanings.

Previous versions of this article

Building a root file system

Compile system

[email protected]:~/100ask_stm32mp157_pro-sdk/Buildroot_2020.02.x$ make 100ask_stm32mp157_pro_ddr512m_systemD_qt5_defconfig
[email protected]:~/100ask_stm32mp157_pro-sdk/Buildroot_2020.02.x$ make all

Building a root file system

Note: When compiling, you need to be networked, you need to download some files, due to machine performance, different compilation time. Computers with poor performance, it is likely to wait for 5 to 6 hours.

The terminal prompts the terminal prompt as shown below.

Building a root file system

Build a Debian Wheezy root filesystem

Building a root file system

This article illustrates how to build an Debian Wheezy root filesystem for
the all the Acme Systems boards based on Atmel MCU

Init process and user program startup process

The last step of the kernel start is to start the init process, the code will call the init_post () function in the init / main.c file;

The execution program of the init process is usually / sbin / init, or you can write / sbin / init programs yourself, or to specify a program as the init process by bootloader incoming command line parameters «init = xxxxx» as the init process.

static int noinline init_post(void)
{
	free_initmem();
	unlock_kernel();
	mark_rodata_ro();
	system_state = SYSTEM_RUNNING;
	numa_default_policy();

	if (sys_open((const char __user *) "/dev/console", O_RDWR, 0) < 0)
		printk(KERN_WARNING "Warning: unable to open an initial console.\n");

	(void) sys_dup(0);
	(void) sys_dup(0);

	if (ramdisk_execute_command) {
		run_init_process(ramdisk_execute_command);
		printk(KERN_WARNING "Failed to execute %s\n",
				ramdisk_execute_command);
	}

	/*
	 * We try each of these until one succeeds.
	 *
	 * The Bourne shell can be used instead of init if we are
	 * trying to recover a really broken machine.
	 */
	if (execute_command) {
		run_init_process(execute_command);
		printk(KERN_WARNING "Failed to execute %s.  Attempting "
					"defaults...\n", execute_command);
	}
	run_init_process("/sbin/init");
	run_init_process("/etc/init");
	run_init_process("/bin/init");
	run_init_process("/bin/sh");

	panic("No init found.  Try passing init= option to kernel.");
}
  • Open standard input, standard output, and standard error devices;

  • If the ramdisk_execute_command variable sets the program to run, start it;

    Ramdisk_execute_command variables are divided into three cases:

    1. If the command line parameters have set «RDINIT = XXXX», ramdisk_execute_command is equal to the program specified by this parameter;
    2. If the / init program exists, ramdisk_execute_command is equal to «/ init»;
    3. Otherwise, ramdisk_execute_command is empty;
  • If the execute_command variable specifies the program to run, start it;

    The parameter of the execute_command variable is the «init = xxxx» incorporated in the command line parameter, that is, the program specified by this parameter, otherwise it is empty;

  • Try executing: / sbin / init, / etc / init, / bin / init, / bin / sh, etc.

Extended learning

In-depth understanding of learning more about Buildroot, please refer to

  • Enter the MenuConfig Package under Buildroot Select Configuration Configuration Interface
  • Buildroot Separate compiled kernel
[email protected]:~/100ask_stm32mp157_pro-sdk/Buildroot_2020.02.x$ make linux-rebuild
  • Enter the kernel Make MenuConfig Configuration Options interface under Buildroot
[email protected]:~/100ask_stm32mp157_pro-sdk/Buildroot_2020.02.x$ make linux-menuconfig
  • Buildroot Separate U-Boot
[email protected]:~/100ask_stm32mp157_pro-sdk/Buildroot_2020.02.x$ make uboot-rebuild
  • BUILDROOT compiles a package
[email protected]:~/100ask_stm32mp157_pro-sdk/Buildroot_2020.02.x$ make <pkg>-rebuild
  • Enter the busybox configuration interface under Buildroot
[email protected]:~/100ask_stm32mp157_pro-sdk/Buildroot_2020.02.x$ make busybox-menuconfig
  • BUILDROOT generates a system SDK, and finally generated directories in Output / Images / Directory

Busybox init process startup process

There are two init programs in the Linux system, which are BSD INIT and SYSTEM V INIT, which have advantages and disadvantages, and now most of the Linux release is System Vinit, but in the embedded field. Usually use busybox integrated init programs;

The process of init program includes:

  • Read the configuration file (/ etc / inittab);
  • Analytic configuration file;
  • Execute the user program according to the configuration parsing;

If there is an / etc / initTab file, the busybox init program parses it, then creates various sub-process according to its instructions, otherwise use the default configuration to create a child process; / etc / initTab file related documentation and sample code can refer to Busybox’s Examples / inittab file;

Basic concept of root file system

In Linux, all directories, files, files, files, and other partitions are managed on a directory, and this directory can be accessed by this directory to access the files on this partition. ;

Оцените статью
Master Hi-technology
Добавить комментарий