💾 Archived View for callistix.srht.site › projects › minimal_rpi › pages › 006_reducekernel.gmi captured on 2024-03-21 at 15:11:55. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2024-02-05)
-=-=-=-=-=-=-
I'm now removing more functionality from the kernel, some of it by trial and error, with the goal to arrive at the minimum possible kernel, which still allows me to compile the kernel itself.
I've now disabled the following options from the "General" section:
CONFIG_SYSVIPC CONFIG_SYSVIPC_SYSCTL CONFIG_SYSVIPC_COMPAT CONFIG_POSIX_MQUEUE CONFIG_POSIX_MQUEUE_SYSCTL CONFIG_CROSS_MEMORY_ATTACH CONFIG_AUDIT CONFIG_AUDITSYSCALL CONFIG_GENERIC_IRQ_INJECTION CONFIG_GENERIC_IRQ_DEBUGFS CONFIG_IPC_NS CONFIG_NETFILTER_XT_TARGET_AUDIT CONFIG_SECURITY_SELINUX CONFIG_AUDIT_GENERIC CONFIG_AUDIT_COMPAT_GENERIC
The compile time is much longer now, ~86 minutes? That's odd, I need to look into why this is the case. But first I'll check if it boots correctly and if the network works properly.
While compiling I was reading about the different C library implementations, and if `musl` is really the best choice to replace `glibc`. I found this comparison [1] and I'm now convinced that I want to use `musl`, as it seems the most performant and complete implementation, when compared to other replacements. I don't know though if that website is recent and up to date. But still, I think `musl` is a good compromise between speed and features. Also, `sta.li` uses `musl` [2]. Leaving here the link to the manual for later [3].
This also raises the concern if I can throw the Filesystem Hierarchy Standard [4] overboard and roll out something simpler. Maybe even simpler than `sta.li`? (aka get rid of symlinks and patch sources to use the correct directories). Patching sources for some Linux tools... I'm sure this can be done. :)
Now, 3 days later, I might have found the reason for the longer compile time. I'm storing the kernel sources on an external `ext4` formatted USB harddrive, connected to one of the USB3.0 ports of the RPi. The other USB3.0 port is connected to a KVM switch, to share my keyboard, mouse, and monitor between different PCs, including the RPi. The KVM switch can be used in passive mode (powered over the USB port) or active mode (through a dedicated power source). I usually have it running in active mode by powering it from another laptop, but that day I took the laptop somewhere else and left the switch in passive mode. Now that the switch was running entirely on USB power provided by the Raspberry this was apparently too much for the little board. I found the USB (mechanical) harddrive in a weird state, and I was worried, as it was clicking periodically which I though was a harddisk failure. At the same time voltage warning appeared in the console, and the KVM switch wasn't working properly.
I connected the harddrive to my PC and found no issues, but I took a backup just in case. Meanwhile I was investigating how much current my charger actually delivers and what the RPi needs. I'm using an Anker PowerPort 10 USB hub [5] for the RPi, which seems to have a max. current of 2.4A per port, and a max. output of 12A in total across all ports. But the Raspberry 4 specs say that it needs at least 3A, so it's actually underpowered. I don't have access to a better charger right now (all USB chargers I own have either 1A or 2A), but I connected the KVM switch to the Anker, which should allow at least this device to draw slightly more current than from a laptop USB port (apparently rated at 2.1A).
My hope is that if I drive the KVM switch actively and I don't overclock the RPi or anything, it will have just about enough power. We'll see how that goes.
I rewrote my bash script to install the compiled files into their respective directories, after taking a backup of boot:
#!/bin/bash
KERNEL=v8-callistix
ARC_PATH="${HOME}/archive/backups"
ARC_FILE="rpi_boot"
ARC_DATE=$(date +%y%m%d-%H%M%S)
ARC=${ARC_PATH}/${ARC_FILE}_${ARC_DATE}.tar.gz
SRC_PATH="${HOME}/Sources/github.com/raspberrypi/linux"
# backup /boot
echo "Backing up /boot ..."
tar -czf ${ARC} -C / boot
# /boot/firmware
sudo rm -fv /boot/firmware/*.dtb /boot/firmware/initrd.* /boot/firmware/vmlinuz*
sudo cp ${SRC_PATH}/arch/arm64/boot/dts/broadcom/bcm2711-rpi-4-b.dtb /boot/firmware
sudo cp ${SRC_PATH}/arch/arm64/boot/dts/broadcom/bcm2711-rpi-400.dtb /boot/firmware
sudo cp ${SRC_PATH}/arch/arm64/boot/dts/broadcom/bcm2711-rpi-cm4-io.dtb /boot/firmware
sudo cp ${SRC_PATH}/arch/arm64/boot/dts/broadcom/bcm2837*.dtb /boot/firmware
sudo cp ${SRC_PATH}/arch/arm64/boot/Image.gz /boot/firmware/vmlinuz-$KERNEL
# /boot
sudo rm -fv /boot/System.map* /boot/config-* /boot/initrd.* /boot/vmlinuz*
sudo cp ${SRC_PATH}/arch/arm64/boot/Image.gz /boot/vmlinuz-$KERNEL
sudo cp ${SRC_PATH}/System.map /boot/System.map-$KERNEL
sudo cp ${SRC_PATH}/.config /boot/config-$KERNEL
# /root
sudo rm -fv /initrd.* /vmlinu*
sudo ln -s boot/vmlinuz-$KERNEL /vmlinuz
The only manual step would be to adjust `/boot/firmware/config.txt` to point to the correct kernel name in case we would change it.
It reboots fine with a boot time of about 7 to 8 seconds until the login prompt. I should start measuring this a bit better maybe, as it takes a little between the last boot log timestamp and the login prompt appearing. And it's also taking a bit between power on and the boot logs starting to count.
[1] Comparison of C/POSIX standard library implementations for Linux
[3] musl 1.1.24 (Draft) Reference Manual
[4] Wikipedia: Filesystem Hierarchy Standard
[5] Amazon: Anker PowerPort 10
⬅ 5. Kernel build using Debian as base image
➡ 7. Reducing the kernel further #2
⬆ The minimal Raspberry 4 project
Created: 17/Jan/2024
Modified: 25/Jan/2024