buildroot构建hisi平台根文件系统和工具链

文章介绍了如何使用Buildroot配合外部的arm-none-linux-gnueabi工具链构建hisi平台的根文件系统,避免了使用hisi专用工具链时遇到的编译问题。通过设置环境变量,可以使用生成的工具链编译内核,并成功启动系统。此外,文章还讨论了将HiSDK中的内核集成到Buildroot中的方法,解决了内核模块、devtmpfs挂载和squashfs启动的相关问题。

buildroot构建hisi平台根文件系统和工具链

前面使用了arm-hisiv300-linux 工具链来作为Buildroot的外部工具链进行编译,然后遇到了很多编译问题。

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

这里不使用hisi的工具链,我们还是选择外部工具链,从远程下载工具链并安装。编译过程一切顺利,除了有的包下载非常缓慢以后,没有再报任何的编译问题,这里做个记录。

1. 下载最新源码

2. Menuconfig配置

Target options

在这里插入图片描述

Toolchain

在这里插入图片描述

可选的只有三种,直接选择ARM 2014.5

在这里插入图片描述

System configuration

在这里插入图片描述

Filesystem images

在这里插入图片描述

3. 编译及测试

sudo make

一切顺利。最后工具链会生成在output/host/opt/ext-toolchain 目录下。

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

通过设置环境变量就能直接使用这个工具链了。然后可以用这个工具链来编译Hi SDK中的linux-3.4内核。

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

最后烧录uImagerootfs.jffs2

我这里烧录使用arm-hisiv300-linux 工具链编译的内核,arm-none-linux-gnueabi 工具链编译根文件系统,系统也是能够直接启动并运行成功的。

tips:最后测试发现,还是不使用hisi的编译工具链编译Buildroot根文件系统比较好。这样,编译过程都不报错,十分的顺利。

4. 集成Hi SDK中的kernel

尝试使用buildroot编译内核,试了3.4到5.10的内核,5.0以下的内核可以编译通过,但是烧录后无法启动,应该是hisi对该版本的内核做了适配的,因此无法直接使用官方的kernel版本。最后还是使用buildroot生成的工具链编译Hi SDK中的内核。

但是可以把Hi SDK中的kernel集成到Buildroot中去。这样还能解决根文件系统启动后,/lib/module下面没有内核模块的问题。另外还可以解决squashfs根文件系统启动无法创建/dev/console以及其它设备的问题,由于Buildroot识别不到kernel的配置,因此devtmpfs无法生效,导致devtmpfs没有挂载到/dev上。

先把kernel打包成.tar.xz格式的文件。

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

然后将打包好的kernel放到Buildroot中去:

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

最后需要配置Buildroot编译kernel,设置自定义版本:

在这里插入图片描述

然后保存配置并退出,重新编译即可。这是将使用Buildroot生成的工具链编译Hi SDK中的Linux内核。编译完成之后,会在output/images 下生成我们的uImage文件 。这时通过tftp烧录uImagerootfs.jffs2

在这里插入图片描述

此时能够发现,启动不会报/lib/modules 的错误了,并且可加载的ko文件也被放到了对应的位置。另外,kernel中配置的devtmpfs也生效了,devtmpfs目录挂载到了/dev下。按理来说,squashfs启动也能够正常了,不会因为无法在/dev下面创建/dev/console 而报错进不了console了。

squashfs测试

在这里插入图片描述

OK,启动正常。

# 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"
#
本资源为arm-linux下的海思编译工具V300 C语言有三种标准库如下: 1.Glibc glibc = GNU C Library 是GNU项(GNU Project)目,所实现的 C语言标准库(C standard library)。 目前,常见的桌面服务器中的GNU/Linux类的系统中,都是用的这套C语言标准库。 其实现了常见的C库的函数,支持很多种系统平台,功能很全,但是也相对比较臃肿庞大。 2.uClibc 一个小型的C语言标准库,主要用于嵌入式。 其最开始设计用于uClinux(注:uClinux不支持MMU),因此比较适用于微处理器中。 对应的,此处的u意思是μ,Micro,微小的意思。 uClibc的特点: (1)uClibc比glibc要小很多。 (2)uClibc是独立的,为了应用于嵌入式系统中,完全重新实现出来的。glibc在源码结构二进制上,都不兼容。 3.EGLIBC EGLIBC = Embedded GLIBC EGLIBC是,(后来)glibc的原创作组织FSF所(新)推出的,glibc的一种变体,目的在于将glibc用于嵌入式系统。 EGLIBC的目标是: (1)保持源码二进制级别的兼容于Glibc 源代码架构ABI层面兼容 如果真正实现了这个目标,那意味着,你之前用glibc编译的程序,可以直接用eglibc替换,而不需要重新编译。 这样就可以复用之前的很多的程序了。 (2)降低(内存)资源占用/消耗 (3)使更多的模块为可配置的(以实现按需裁剪不需要的模块) (4)提高对于交叉编译(cross-compilation)交叉测试(cross-testing)的支持 【目前了解到的海思交叉编译工具链的应用环境】 arm-hisiv100-linux为基于uclibc的工具链arm-hisiv200-linux 为基于 glibc 的工具链arm-hisiv300-linux为基于uclibc的工具链arm-hisiv400-linux 为基于 glibc 的工具链arm-hisiv500-linux为基于uclibc的工具链arm-hisiv600-linux 为基于 glibc 的工具链。 (在开发的时候,你编译内核所用的交叉编译跟用户的应用程序所用的交叉编译一定需要相同,不然没法调用系统内核的依赖库)   其中eglibc这种很容易被人开发者忽视,从而选错了编译工具链。 uClibcGlibc并不相同,两者有许多不同之处,有可能给你带来一些问题。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值