为何GoLang的hello程序在Tina SDK编译的镜像无法运行，sipeed的Tina镜像反而可以运行

walker2048 LV 4

问题说明

一直都想用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.dtsi

		CPU0: 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交叉编译的程序，希望能找到问题和解决方案。