为何GoLang的hello程序在Tina SDK编译的镜像无法运行,sipeed的Tina镜像反而可以运行
-
问题说明
一直都想用GoLang程序在全志D1平台上开发一些物联网应用,因为工作和其他原因,计划不断的往后推。直到今年12月,才有空搞搞。但是用全志客户服务平台上下载的Tina SDK编译完烧录到tf卡后,却连最基本的hello world程序都运行不了。但是使用sipeed魔改后的 LicheeRV_Tina_86_waft.7z 镜像却可以正常运行,让我百思不得其解。
后来我也尝试用sipeed的配置来修改全志客户服务平台的标准Tina SDK,也是不能执行。希望知道如何解决这个问题的大佬能帮忙看看。提一下建议如何配置。
hello world程序
这是GoLang官网上给出的入门程序,只使用了fmt包和最常见的Println输出函数。GoLang默认使用的静态链接方式生成可执行程序。
package main import ( "fmt" ) func main() { fmt.Println("Hello World") }
使用交叉编译命令编译程序(Ubuntu上的GoLang环境,可以省略GOOS定义,禁用CGO)
CGO_ENABLED=0 GOARCH=riscv64 go build cmd/hello.go
使用file hello指令可以看到,交叉编译是成功了的(并且后面也能在D1H硬件,sipeed的Tina系统上运行)
$ file hello
hello: ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, Go BuildID=uK6WNtbZSYpSKIdGnBa3/PtYT2uy93Wom3LrXJ4S_/bgv_bQPLteouCb_r28rl/5VDHxbzOdxdLmCOE5_xG, with debug_info, not stripped上传到开发板上(sipeed可以通过tf卡,全志官方的可以通过adb push)
在sipeed的镜像运行hello程序
可以看到,能正确执行程序,无任何报错。
在全志官方Tina SDK编译出来的镜像运行hello程序
全志的Tina SDK V2.0和V2.1版本都尝试用过以下3种配置进行编译镜像并测试,结果一致(无法运行并提示同一个错误)。
- V2.0版本SDK + d1-h_nezha-tina 默认配置(仅调整介质和增加UDISK分区)
- V2.1版本SDK + d1-h_nezha-tina 默认配置(仅调整介质和增加UDISK分区)
- V2.1版本SDK + d1-h_nezha-tina 配置并修改成sipeed的docker容器内的d1-h_nezha-tina 和 kernel config配置
在出现这个问题后,我搜索了以下几个方向,均没有解决问题。
尝试分析可能的问题
- 检查libc类型
全志官方Tina镜像的输出 ========================================= root@TinaLinux:/# /lib64xthead/lp64d/libc.so.6 GNU C Library (GNU libc) stable release version 2.29. Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 8.1.0. libc ABIs: UNIQUE ABSOLUTE For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>. sipeed镜像的输出 ========================================= root@MaixLinux:/# /lib64xthead/lp64d/libc.so.6 GNU C Library (GNU libc) stable release version 2.29. Copyright (C) 2019 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 8.1.0. libc ABIs: UNIQUE ABSOLUTE For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>.
从两者的libc配置可以看出,用的都是同一个版本的glibc。并且我的Golang也是基于glibc的,所以不是libc类型不同的问题。
- 检查Golang环境变量
$ go env GO111MODULE="on" GOARCH="amd64" GOCACHE="/home/walker/.cache/go-build" GOENV="/home/walker/.config/go/env" GOHOSTARCH="amd64" GOHOSTOS="linux" GOMODCACHE="/home/walker/go/pkg/mod" GOOS="linux" GOPATH="/home/walker/go" GOPROXY="https://goproxy.cn,direct" GOROOT="/home/walker/.bin/go" GOSUMDB="sum.golang.org" GOTOOLDIR="/home/walker/.bin/go/pkg/tool/linux_amd64" GOVERSION="go1.19.3" GCCGO="gccgo" GOAMD64="v1" AR="ar" CC="gcc" CXX="g++" CGO_ENABLED="1" GOMOD="/home/walker/vlog/100ask/Golang/go.mod" CGO_CFLAGS="-g -O2" CGO_CPPFLAGS="" CGO_CXXFLAGS="-g -O2" CGO_FFLAGS="-g -O2" CGO_LDFLAGS="-g -O2" PKG_CONFIG="pkg-config" GOGCCFLAGS="-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build989797907=/tmp/go-build -gno-record-gcc-switches"
同一个hello程序,在同一块开发板上,用sipeed的镜像可以正常运行,按道理说GoLang这边是没什么问题的,以防万一提供一下相关的环境。前面编译的时候已经关闭了CGO模式
- 检查cpu的target配置
全志官方Tina镜像的输出 ========================================= root@TinaLinux:/# cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdcvu mmu : sv39 sipeed镜像的输出 ========================================= root@MaixLinux:/# cat /proc/cpuinfo processor : 0 hart : 0 isa : rv64imafdcvu mmu : sv39
查找这个的原因是谷歌上有提出arm某设备上,设备树未正确传递arch参数给Linux内核,修改设备树后正常。但是我查找Tina SDK里关于cpu架构的配置,应该是正确配置了的。
另外通过查看cpuinfo,也可以看到在cpu的架构类型方面,两个镜像的设备树配置应该也是一样的以下是Tina SDK里关于cpu架构的设备树配置
lichee/linux-5.4/arch/riscv/boot/dts/sunxi/sun20iw1p1.dtsiCPU0: cpu@0 { device_type = "cpu"; reg = <0>; status = "okay"; compatible = "riscv"; riscv,isa = "rv64imafdcvsu"; /* riscv,priv-major = <1>;*/ /* riscv,priv-minor = <10>;*/ mmu-type = "riscv,sv39"; clocks = <&ccu CLK_RISCV>; clock-frequency = <24000000>; operating-points-v2 = <&cpu_opp_table>; cpu-idle-states = <&CPU_SLEEP>; #cooling-cells = <2>; /* d-cache-size = <0x8000>;*/ /* d-cache-line-size = <32>;*/
- 检查Linux内核启动配置
全志官方Tina镜像的输出 ========================================= root@TinaLinux:/# cat /proc/cmdline earlyprintk=sunxi-uart,0x02500000 clk_ignore_unused initcall_debug=0 console=ttyS0,115200 loglevel=8 root=/dev/mmcblk0p5 init=/sbin/init partitions=boot-resource@mmcblk0p1:env@mmcblk0p2:env-redund@mmcblk0p3:boot@mmcblk0p4:rootfs@mmcblk0p5:dsp0@mmcblk0p6:recovery@mmcblk0p7:UDISK@mmcblk0p8 cma=8M snum= mac_addr= wifi_mac= bt_mac= specialstr= gpt=1 androidboot.hardware=sun20iw1p1 boot_type=1 androidboot.boot_type=1 gpt=1 uboot_message=2018.07-ge987def5(11/07/2022-03:11:27) mbr_offset=1556480 disp_reserve=4096000,0x000000005eb3b000 androidboot.dramsize=512 root@TinaLinux:/# sipeed镜像的输出 ========================================= root@MaixLinux:/# cat /proc/cmdline earlyprintk=sunxi-uart,0x02500000 clk_ignore_unused initcall_debug=0 console=tty0 console=ttyS0,115200 loglevel=8 root=/dev/mmcblk0p7 init=/sbin/init partitions=boot-resource@mmcblk0p1:env@mmcblk0p2:env-redund@mmcblk0p3:boot@mmcblk0p4:dsp0@mmcblk0p5:recovery@mmcblk0p6:rootfs@mmcblk0p7:UDISK@mmcblk0p8 cma=8M snum= mac_addr= wifi_mac= bt_mac= specialstr= gpt=1 androidboot.mode=normal androidboot.hardware=sun20iw1p1 boot_type=1 androidboot.boot_type=1 gpt=1 uboot_message=2018.05-g0a88ac9-dirty-config-dirty(12
关于Linux内核启动命令方面,我是没找到有什么有用的信息来调整
- 反汇编hello程序
74884: a85e50ef jal ra,0x5a308 74888: 000ac517 auipc a0,0xac 7488c: 9a053503 0x9a053503 74890: 00023597 auipc a1,0x23 74894: 84d58593 addi a1,a1,-1971 # 0x970dd 74898: 00b00613 li a2,11 7489c: 84dff0ef jal ra,0x740e8 748a0: 000f1297 auipc t0,0xf1 748a4: b302e283 0xb302e283 748a8: 00029863 bnez t0,0x748b8 748ac: 000c4f97 auipc t6,0xc4 748b0: 86afba23 0x86afba23 748b4: 0140006f j 0x748c8 748b8: 000c4297 auipc t0,0xc4 748bc: 86828293 addi t0,t0,-1944 # 0x138120 748c0: 00050313 mv t1,a0 748c4: a45e50ef jal ra,0x5a308 748c8: 00016517 auipc a0,0x16 748cc: 7d850513 addi a0,a0,2008 # 0x8b0a0 748d0: a29950ef jal ra,0xa2f8 748d4: 03700293 li t0,55 748d8: 00553423 0x553423 748dc: 00029297 auipc t0,0x29 748e0: 40d28293 addi t0,t0,1037 # 0x9dce9 748e4: 00553023 0x553023 748e8: 00042297 auipc t0,0x42 748ec: b4028293 addi t0,t0,-1216 # 0xb6428 748f0: 000c4f97 auipc t6,0xc4 748f4: b85fb823 0xb85fb823 748f8: 000f1317 auipc t1,0xf1 748fc: ad836303 0xad836303
根据反汇编的748c0,咨询riscv架构群里的大佬,也找不到什么问题。以上的分析内容也是因为本人的嵌入式功底较弱,找不到问题的所在。希望有能力的大佬不吝赐教,多多指点。
总结
按正常的GoLang交叉编译流程,最简单的printf输出功能是不依赖Linux内核的,只跟libc的类型有关(glibc和musl libc)。全志的Tina SDK到底需要配置什么选项才能正常运行GoLang交叉编译的程序,希望能找到问题和解决方案。
-
-
@walker2048 go启动会调用 rdtime的指令 。然后这条指令在这个版本里面不支持。这条汇编在即使c来调一样挂。
Copyright © 2023 深圳全志在线有限公司 粤ICP备2021084185号 粤公网安备44030502007680号