Building kernel for raspberry pi 4 b on a host machine(ubuntu 18.04)

Question

I am new to linux and I really need your help.

I am working on project for my end of studies internship : controlling sensors and displaying the result on an LCD screen.

For that I will use Raspberry and create a QT application for displaying the result of the sensors.

The boot time needs to be very minimal (maximum 20s). So for that, I want to create a minimal kernel for my raspberry Pi-4B.

 sudo apt install git bc bison flex libssl-dev make libc6-dev libncurses5-dev
 sudo apt install crossbuild-essential-arm64
 git clone --depth=1 https://github.com/raspberrypi/linux
 cd linux/
 export KERNEL=kernel8
 make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- bcm2711_defconfig
 make -j8 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Image modules dtbs
 
 mkdir mnt
 mkdir mnt/fat32
 mkdir mnt/ext4
 sudo mount /dev/mmcblk0p1 mnt/fat32
 sudo mount /dev/mmcblk0p2 mnt/ext4
 sudo env PATH=$PATH make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_MOD_PATH=mnt/ext4 modules_install
 sudo cp mnt/fat32/kernel8.img mnt/fat32/kernel8-backup.img

These are the steps that I followed but I got an error.

cp: cannot stat 'mnt/fat32/kernel8.img': No such file or directory

and

$ sudo cp arch/arm64/boot/dts/overlays/*.dtb* mnt/fat32/overlays/
cp: target 'mnt/fat32/overlays/' is not a directory

So I tried to create it.

$ mkdir mnt/fat32/overlays
mkdir: cannot create directory ‘mnt/fat32/overlays’: Permission denied

can anyone please help me I am stuck in this error for 2 weeks now and I need to build my kernel to start working on it!

I don't know also if this version of kernel and this configuration are minimal. can I have a minimal boot time with this configuration (I think of changing the boot sequence and just enable the devices needed for my application at first but of course i don't know how to do it) If anyone can help please en-light me !! even if you just know a good tutoriel to recommand me or something..

I will be grateful if someone could help

Answer 1

I don't use Ubuntu but as far as I know, resent versions use systemd.

goldilocks noted in a comment:

Most of the boot time is the userland OS. The kernel only does what it needs to do, which is service that userland. Compiling the kernel won't change any of that or the time it takes. If you want to reduce boot time, you need to consider what services are being started then.

To elaborate this, systemd is working parallel starting services on boot up. To optimize this it has very good analyzing tools. I would use systemd-analyze to reduce boot time step by step. For example, my current testing installation Raspberry Pi Operating system based on Buster with Graphical User Interface uses:

~$ systemd-analyze time
Startup finished in 5.870s (kernel) + 12.550s (userspace) = 18.421s
graphical.target reached after 12.405s in userspace

Maybe it is possible to reduce boot time in userspace to a significant amount. Look what Units take most time:

~$ systemd-analyze blame | head
     32.306s apt-daily-upgrade.service
     31.476s apt-daily.service
      6.997s hciuart.service
      3.084s dev-mapper-rpi.vg09\x2droot.lv.device
      1.102s udisks2.service
      1.064s man-db.service
       935ms lvm2-monitor.service
       854ms systemd-resolved.service
       834ms rpi-eeprom-update.service
       662ms systemd-udev-trigger.service

Only apt-daily-upgrade.service and apt-daily.service need about 32s. Disabling these services will help. But because of asynchronous executing it will not reduce boot up by 64s. There is a critical chain:

~$ systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@" character.
The time the unit takes to start is printed after the "+" character.

graphical.target @12.405s
└─multi-user.target @12.405s
  └─hciuart.service @5.405s +6.997s
    └─basic.target @5.300s
      └─sockets.target @5.299s
        └─dbus.socket @5.299s
          └─sysinit.target @5.296s
            └─systemd-timesyncd.service @4.982s +312ms
              └─systemd-tmpfiles-setup.service @4.825s +118ms
                └─local-fs.target @4.796s
                  └─run-user-1000.mount @11.439s
                    └─local-fs-pre.target @2.053s
                      └─lvm2-monitor.service @1.113s +935ms
                        └─dm-event.service @1.381s
                          └─systemd-journald.socket @1.096s
                            └─-.mount @1.005s
                              └─system.slice @1.005s
                                └─-.slice @1.005s

It is not surprising that the graphical.target needs the most time. It is strongly recommended to use a version without a GUI. But even with GUI, disabling the hciuart.service will reduce boot up by 7s. Maybe there is work to avoid side effects?

This may also help to reduce your Ubuntu installation. Good luck :-)