buildroot builds the root file system and toolchain of the hisi platform

I used arm-hisiv300-linuxthe toolchain to Buildrootcompile as an external toolchain, and encountered many compilation problems.

https://blog.csdn.net/duapple/article/details/128516133?spm=1001.2014.3001.5501

For the toolchain not used here hisi, we still choose an external toolchain, download the toolchain remotely and install it. The compilation process went smoothly. Except for some packages that were downloaded very slowly, no compilation problems were reported. Here is a record.

1. Download the latest source code

2. Menuconfig configuration

Target options

insert image description here

Toolchain

insert image description here

There are only three options, choose directly ARM 2014.5.

insert image description here

System configuration

insert image description here

Filesystem images

insert image description here

3. Compile and test

sudo make

all the best. Finally, the toolchain will be generated output/host/opt/ext-toolchainunder the directory.

duapple@92fa1c7e1a00:/media/data/workspace/buildroot-2022.02.8/output/host/opt/ext-toolchain$ ls 
arm-none-linux-gnueabi  bin  i686-pc-linux-gnu  lib  libexec  share
duapple@92fa1c7e1a00:/media/data/workspace/buildroot-2022.02.8/output/host/opt/ext-toolchain$ ls bin 
arm-none-linux-gnueabi-addr2line  arm-none-linux-gnueabi-cs         arm-none-linux-gnueabi-gcc-ar      arm-none-linux-gnueabi-ld       arm-none-linux-gnueabi-size
arm-none-linux-gnueabi-ar         arm-none-linux-gnueabi-cs-daemon  arm-none-linux-gnueabi-gcc-nm      arm-none-linux-gnueabi-nm       arm-none-linux-gnueabi-strings
arm-none-linux-gnueabi-as         arm-none-linux-gnueabi-elfedit    arm-none-linux-gnueabi-gcc-ranlib  arm-none-linux-gnueabi-objcopy  arm-none-linux-gnueabi-strip
arm-none-linux-gnueabi-c++        arm-none-linux-gnueabi-g++        arm-none-linux-gnueabi-gcov        arm-none-linux-gnueabi-objdump  cache
arm-none-linux-gnueabi-c++filt    arm-none-linux-gnueabi-gcc        arm-none-linux-gnueabi-gdb         arm-none-linux-gnueabi-ranlib
arm-none-linux-gnueabi-cpp        arm-none-linux-gnueabi-gcc-4.8.3  arm-none-linux-gnueabi-gprof       arm-none-linux-gnueabi-readelf

This toolchain can be used directly by setting environment variables. Then you can use this toolchain to compile linux-3.4the kernel in Hi SDK.

export PATH=$PATH:/media/data/workspace/buildroot-2022.02.8/output/host/opt/ext-toolchain/bin
cp arch/arm/configs/hi3518ev200_full_defconfig .config
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage -j12

Finally burn uImageand rootfs.jffs2.

Here I burn arm-hisiv300-linuxthe kernel compiled with the toolchain, and arm-none-linux-gnueabithe toolchain compiles the root file system, and the system can also be started directly and run successfully.

Tips: In the final test, it was found that it is better not to use hisi's compilation toolchain to compile the Buildroot root file system. In this way, the compilation process does not report errors, which is very smooth.

4. Integrate the kernel in Hi SDK

Try to use buildroot to compile the kernel. I tried kernels from 3.4 to 5.10. Kernels below 5.0 can be compiled, but they cannot be started after burning. It should be that hisi has adapted this version of the kernel, so the official kernel cannot be used directly. Version. Finally, use the toolchain generated by buildroot to compile the kernel in the Hi SDK.

But you can integrate the kernel in Hi SDK into Buildroot. This can also solve /lib/modulethe problem that after the root file system is started, there is no kernel module below. In addition, it can also solve the problem that /dev/console and other devices cannot be created when the squashfs root file system starts. Since Buildroot cannot recognize the kernel configuration, devtmpfs cannot take effect, resulting in devtmpfs not being mounted on it /dev.

First package the kernel into .tar.xza format file.

tar cvf linux-3.4.y.tar linux-3.4.y
xz -z linux-3.4.y.tar -0

Then put the packaged kernel into Buildroot:

sudo cp linux-3.4.y.tar.xz /media/data/workspace/buildroot-2022.02.8/dl/linux/

Finally, you need to configure Buildroot to compile the kernel and set a custom version:

insert image description here

Then save the configuration and exit, just recompile. This is the Linux kernel in the Hi SDK that will be compiled using the toolchain generated by Buildroot. After the compilation is complete, output/imagesour uImagefiles will be generated under . uImageAt this time, burn and use tftp rootfs.jffs2.

insert image description here

At this time, it can be found that the startup will not report /lib/modulesan error, and the loadable ko file has also been placed in the corresponding location. In addition, the configuration in the kernel devtmpfshas also taken effect, and devtmpfsthe directory is mounted under /dev. Logically speaking, squashfs can start normally, and it will not report an error and cannot enter the console because it cannot be /devcreated below ./dev/console

squashfstest

insert image description here

OK, it starts normally.

# cat /proc/version
Linux version 3.4.35 (root@92fa1c7e1a00) (collect2: error: ld returned 1 exit status) #3 Mon Jan 2 23:44:06 CST 2023
# uname -a
Linux buildroot 3.4.35 #3 Mon Jan 2 23:44:06 CST 2023 armv5tejl GNU/Linux
# cat /usr/lib/os-release
NAME=Buildroot
VERSION=2022.02.8
ID=buildroot
VERSION_ID=2022.02.8
PRETTY_NAME="Buildroot 2022.02.8"
#