User:Brendlefly62/Radxa ROCK Pi 4C Plus/Build-Install-Kernel

From Gentoo Wiki
Jump to:navigation Jump to:search

Build your own kernel

Prerequisites

The linux kernel for Radxa ROCK Pi 4C Plus can be built on an ARM64 device or cross-compiled on a PC. Assuming the latter, git and crossdev are needed:

  • git, to check out the sources
  • crossdev, since an arm64 (aarch64) toolchains is required

Make sure these are installed:

root #emerge --ask --update dev-vcs/git sys-devel/crossdev

Please review the crossdev article if crossdev is not already set up.

Install the 64-bit cross-compiler toolchain:

root #crossdev --target aarch64-unknown-linux-gnu

See the crossdev article regarding possible need to specify versions of components of the toolchain using -g, -b, -k, and -l options


Get the sources

Create a build directory

user $cd /home/joe/
user $mkdir -p My_${model}_project/build/${model}

Identify and populate a sources directory

root #cd /usr/aarch64-unknown-linux-gnu/usr/src/

and retrieve sources for an appropriate version of the kernel. If this is the first custom kernel build for this board, it is probably wise to build the same version (or only a minor upgrade to a version) known to work in other distributions (e.g. Armbian or Debian). This retrieval can be done either by cloning the entire linux kernel repository and browsing it

root #cd linux
root #git branch --list --remotes
root #git branch --show-current
root #git checkout linux-<new_LTS_version>.y

or by browsing https://cdn.kernel.org/pub/linux/kernel/ to identify the version number, and then using wget to retrieve only the version needed

root #tar xvpf linux-6.1.66.tar.xz

Configure the kernel

Once the sources are retrieved, the next step is configuration. As of this writing, there is no publicly available rk3399-rock-4c-plus_defconfig. It would be possible to get one from files used to run armbian/build ([[1]], [[2]]), but if that software has already been used to generate a working kernel, it will be more effective to use that running kernel's configuration as a "seed" for making a new one. For example, where model=rk3399-rock-4c-plus --

root #cd ~/My_${model}project/build/${model}/
root #ln -snf /usr/aarch64-unknown-linux-gnu/usr/src/linux-<version> linux
root #cd ../../
root #cp kernelconfigs/<my_seed_config> build/<model>/.config
Tip
This procedure involves cross-compiling in a build directory, so lengthy command line operations can be simplified by assigning much of the repeated text to a bash variable. For example --
root #make_model='MAKEOPTS="-j16 -l4" FEATURES=" -userpriv -distcc -distcc-pump" make O=/home/joe/My_rk3399-rock-4c-plus_project/build/rk3399-rock-4c-plus/ ARCH=arm64 CROSS_COMPILE=aarch64-unknown-linux-gnu-'
will cross-compile for aarch64-unknown-linux-gnu, arm64, turning off disttcc features, allowing up to 16 compile jobs to be run in parallel, and it will output to the build directory instead of the sources directory

Save a copy of the initial .config file, and then run make commands mrproper, prepare, oldconfig, and menuconfig; and then save a copy of the new .config file

root #backup_config
root #eval ${make_model} mrproper
root #cp -v ${config_dir}/.config.bak ${model_config}
root #eval ${make_model} prepare
root #eval ${make_model} oldconfig
root #eval ${make_model} menuconfig
root #save_new_config

make targets prepare and oldconfig may generate interactive configuration questions on STDOUT that must be answered to complete configuration. When done, don't forget to save a copy of the new configuration file

Compile

Using the same "make_model" bash variable defined above, continue and build the kernel image, modules, and device tree binary blob files

root #eval ${make_model} ${image}
root #eval ${make_model} modules
root #eval ${make_model} dtbs

Create a staging directory

This is a location in which to stage the kernel image, modules, and .dtb files needed on the target system, copy those files and build a tarball to facilitate transfer and installation on the target system

root #cd ~/My_${model}project/build/${model}/
root #distrib_dir=/home/joe/My_${model}_project/build/${model}/tmp/distrib
root #mkdir -p ${distrib_dir}/{boot,lib}
root #kernel_distrib_dir=${distrib_dir}/boot

Clean distrib_dir structure if repeating this procedure

root #for x in $distrib_dir $kernel_distrib_dir; do [ [ -d $x ] ] && find $x -maxdepth 1 -type f -iname '*' -delete; done
root #[ [ -d $lib_dir ] ] && find $lib_dir -mindepth 1 -iname '*' -delete

Stage the kernel and modules

root #cp -av arch/arm64/boot/Image ${kernel_distrib_dir}/vmlinuz
root #eval ${make_model} INSTALL_MOD_PATH=${distrib_dir} modules_install

Fix the "build" and "source" symlinks

root #cd ${distrib_dir}/lib/modules/<version_number>
root #rm -v build 2>/dev/null
root #ln -snfv /usr/src/linux build
root #rm -v source 2>/dev/null
root #ln -snfv /usr/src/linux source
root #cd ~/My_${model}project/build/${model}/

Stage the dtb files (and overlays)

root #eval ${make_model} INSTALL_DTBS_PATH=${kernel_distrib_dir}/dts/ dtbs_install
root ## copy the one dtb file we need up to boot
root #cp -av ${kernel_distrib_dir}/dts/rockchip/${model}.dtb ${kernel_distrib_dir}/

Make tarball

root #cd $distrib_dir
root #tar --exclude lib/modules/<version_number>/source/ --exclude lib/firmware -cvjf vmlinuz-<version_number>.tar.bz2 boot lib
root #cd ~/My_${model}project/build/${model}/

Deploy new kernel, modules, dtb

Now copy the tarball ${distrib_dir}/vmlinuz-<version_number>.tar.bz2 to the target system, either by

  • mounting the target system storage device on the development platform and copying to its root / directory, or
  • copying it to other removeable media to transfer to the / directory on the target system, or
  • copying with scp, etc. to the / directory on the target system

Then un-archive contents from the tarball

root #cd /mnt/gentoo/
root # tar xvjf vmlinuz-<version_number>.tar.bz2

Inspect contents of target system /lib/modules/<version_number> and /boot/. Ensure the kernel and dtb files are named as the boot.scr script will expect (rename or edit joetooEnv.txt, if not).

Reboot! Observe u-boot console output...