小白wujian100_open仿真踩坑记——我是如何踩坑的,又是如何出坑的-阿里云开发者社区

开发者社区> 平头哥芯片开放社区> 正文

小白wujian100_open仿真踩坑记——我是如何踩坑的,又是如何出坑的

简介: 在这篇文章中,我将同时跑两个仿真,开两个终端,一左一右地对比,看看我是如何踩进那些坑里,又是如何出来的。在?进来踩坑!

在这篇文章中,我将同时跑两个仿真,开两个终端,一左一右地对比,展示我是如何踩进那些坑里(公开处刑⚠),又是如何爬出来的。话不多说,咱们开始。

仿真过程

  • 准备一个Linux系统

这里我是用虚拟机软件跑的Linux系统,虚拟机软件用的是VMware Workstation 15 Pro,跑的系统是Ubuntu18.04。其实准备虚拟机的过程也是有不少坑的(对于小白来说),比如之前装的虚拟机之前还用的好好的,可是现在突然就打不开了;再比如虚拟机和Window系统的共享文件夹的设置问题等等。不过这里主要说的是仿真的事情,虚拟机的事情先按下不表。

  • 建立工程目录

进入Linux系统,我这里是以普通用户(而不是root用户)的身份进入系统的。打开终端,依照官方的提示(这里给出wujian100的官方GitHub链接),建立工程目录。注意了,就是在这里,出现了“万 坑 之 源”,开幕雷击啊简直是。注意看下面两个终端建立工程目录时所用命令的不同,这是后面一个令人抓狂的报错的根源。
左边终端:llh@ubuntu:~$ sudo mkdir Project1
右边终端:llh@ubuntu:~$ mkdir Project2

image.png

  • 下载官方源码

进入工程目录,下载官方源码。

左边终端:

llh@ubuntu:~$ cd Project1
llh@ubuntu:~/Project1$ sudo git clone https://github.com/T-head-Semi/wujian100_open.git

右边终端:

llh@ubuntu:~$ cd Project2
llh@ubuntu:~/Project2$ git clone https://github.com/T-head-Semi/wujian100_open.git

image.png

  • 建立工具链目录

建立工具链目录,这里注意工具链目录的名称和目录结构要和官方的保持一致(见官方GitHub),因为后面编译和仿真用的脚本都是根据那个目录结构和名称来写的,不一致的话后面会出错(当然如果你自己会改脚本的话可以随意)。
左边终端:

llh@ubuntu:~/Project1$ sudo mkdir riscv_toolchain

右边终端:

llh@ubuntu:~/Project2$ mkdir riscv_toolchain

image.png

  • 下载安装官方交叉编译工具链

到平头哥的官网下载工具链。这里要注意,如果你是在Windows系统下下载的工具链,那么最好不要在Windows系统下解压,否则后续仿真有可能会出现错误(这个我也没具体考证过,我看群友的文章好像有这么说的,本着不给自己找麻烦的原则,就认为它是真的吧[手动滑稽])。我是在Windows下下载到主机与虚拟机的共享文件夹里,然后再在虚拟机里解压,然后再把对应版本的工具链安装到工具链目录下的。

解压下载完的工具包

llh@ubuntu:~/Project1$ cd /mnt/hgfs/Shared/     #进入共享文件夹/mnt/hgfs/Shared/

llh@ubuntu:/mnt/hgfs/Shared$ sudo unzip T-Head\ Tools\ package.zip

查看解压完的工具包

llh@ubuntu:/mnt/hgfs/Shared$ ll

image.png

这里我们暂时只用到RISC-V工具链,所以我们进入’T-Head RISC-V Toolchain-V1.2.2’目录,并查看都有哪些文件。

image.png

这里有4个版本的工具链,那该选哪个呢?让我们看看Readme.txt。

llh@ubuntu:/mnt/hgfs/Shared/T-Head RISC-V Toolchain-V1.2.2$ cat Readme.txt

image.png

注意了,这里出现了第二个坑。我当时看了Readme,作为一个小白,我不知道“linux平台BareMetal应用程序”是啥(后来我百度了一下,说是啥裸机的意思,BareMetal可以在虚拟机和物理机间切换。具体是个什么东西,我现在也不太清楚),于是我选了“riscv64-linux-x86_64-*.tar.gz”这个版本(名字上带linux嘛,我当然是滋瓷它啊)。结果证明,不是这个版本。。。因为后面因为环境变量的问题出现了“xxx command not found”的报错,我从报错信息中知道后面的编译脚本用的不是这个版本的工具,报错的命令名字跟我安装的那个版本的工具里的命令根本就对不上!后来我安装了“riscv64-elf-x86_64-*.tar.gz”版本的工具(就是BareMetal对应的那版),发现命令名字正好对上了。所以应该安装“riscv64-elf-x86_64-*.tar.gz”这个版本的工具(我现在也不太清楚为什么选择这个版本,我猜可能是因为工程师之前是在啥“BareMetal平台”上编译的吧)。

安装工具链

好的现在我们安装工具链吧。

左边终端:

llh@ubuntu:/mnt/hgfs/Shared/T-Head RISC-V Toolchain-V1.2.2$ cd ~/Project1/riscv_toolchain/     #回到工具链安装目录
llh@ubuntu:~/Project1/riscv_toolchain$ sudo tar -zxf /mnt/hgfs/Shared/T-Head\ RISC-V\ Toolchain-V1.2.2/riscv64-elf-x86_64-20190731.tar.gz

右边终端:

llh@ubuntu:~/Project2$ cd riscv_toolchain/
llh@ubuntu:~/Project2/riscv_toolchain$ tar -zxf /mnt/hgfs/Shared/T-Head\ RISC-V\ Toolchain-V1.2.2/riscv64-elf-x86_64-20190731.tar.gz

然后查看一下解压安装后的文件。

image.png

好的现在我们安装成功了。

  • 安装开源EDA工具

现在我们要安装两款开源的EDA工具,一款是iverilog,用于RTL文件的编译和仿真,另一款是gtkwave,用于查看仿真波形。
安装命令:sudo apt-get install iverilog verilator gtkwave
这个因为我之前已经安装过了,我就不再安装了。

  • 准备开始仿真

好了,工具已经准备好了,我们现在开始准备仿真。

设置工具路径和环境变量

因为要修改setup.csh这个文件设置路径和环境变量,所以对于Project1里的工程(即左终端对应的工程),由于它是提权创立的,为了方便修改文件,要修改一下Project1工程的setup.csh的权限,让它对普通用户可写。

左终端输入:

llh@ubuntu:~/Project1/riscv_toolchain$ cd ../wujian100_open/tools/     #进入/Project1/wujian100_open/tools/目录
llh@ubuntu:~/Project1/wujian100_open/tools$ sudo chmod 777 setup.csh

然后用Ubuntu自带的文本编辑器修改setup.csh,保存。

image.png

因为Ubuntu18.04默认用的shell是bshell,而脚本是用的是cshell脚本的语法,所以要修改一下setup脚本。

同样也因为是用的是bshell,所以要把.csh文件改为.sh文件。

左终端输入:

llh@ubuntu:~/Project1/wujian100_open/tools$ sudo cp setup.csh setup.sh

同样需要修改的还有“Srec2vmem.py”这个python脚本,因为Ubuntu18.04默认安装的是python3,python3和python2有很多不兼容的地方,所以要修改Srec2vmem.py里的执行环境,这个的修改比较简单,只是把第一行的“#!/usr/bin/env python”改成“#!/usr/bin/env python3”就行,所以直接用“vi”命令打开修改保存就行了。

左终端输入:

llh@ubuntu:~/Project1/wujian100_open/tools$ sudo vi Srec2vmem.py

image.png

然后修改保存即可。

同样地,对于Project2里的工程(即右终端对应的工程),同样需要修改这两个脚本文件。我这里就不再修改了,因为在Project1工程里已经修改过了这两个脚本文件,就直接把Project1工程的“setup.sh”“Srec2vmem.py”这两个脚本文复制到Project2工程里吧。

右终端输入:

llh@ubuntu:~/Project2/riscv_toolchain$ cd ../wujian100_open/tools/
llh@ubuntu:~/Project2/wujian100_open/tools$ cp ~/Project1/wujian100_open/tools/setup.sh ./
llh@ubuntu:~/Project2/wujian100_open/tools$ cp -f ~/Project1/wujian100_open/tools/Srec2vmem.py ./
llh@ubuntu:~/Project2/wujian100_open/tools$ ll

image.png

好的现在我们脚本文件已经修改好了,我们要执行“setup.sh”这个脚本文件,设置环境变量。

左边终端:

llh@ubuntu:~/Project1/wujian100_open/tools$ source setup.sh

右边终端:

llh@ubuntu:~/Project2/wujian100_open/tools$ source setup.sh
  • 开始仿真

好了,现在都准备好了,我们开始仿真吧。

左边终端:

llh@ubuntu:~/Project1/wujian100_open/tools$ cd ../workdir/     #进入工作目录
llh@ubuntu:~/Project1/wujian100_open/workdir$ sudo ../tools/run_case -sim_tool iverilog ../case/timer/timer_test.c     #启动仿真

我们看看执行结果如何。

image.png

好的,出现了一个错误“ make:/bin/riscv64-unknown-elf-gcc: Command not found”, make的时候找不到“/bin/riscv64-unknown-elf-gcc”这个命令,什么原因我们等会儿再说,我们先启动Project2工程的仿真。

右边终端:

llh@ubuntu:~/Project2/wujian100_open/tools$ cd ../workdir/
llh@ubuntu:~/Project2/wujian100_open/workdir$ ../tools/run_case -sim_tool iverilog ../case/timer/timer_test.c

我们看看执行结果如何。

image.png

仿真成功跑通!“唰~”的一下,行云流水般畅快~

两者的结果对比一下

image.png

结果分析

从我们的仿真过程来看,两个工程的文件内容是一模一样的,差别在于在终端上执行大部分命令时,命令前面带不带“sudo”。也就是说Project1是用root权限创立的,而Project2是用普通用户权限创立的,而这个差别会在执行“setup.sh”这个shell脚本来设置环境变量时埋下隐患,导致最后编译make时工具路径设置出问题。

因为是无法找到命令,我们来看一下Makefile里关于“/bin/riscv64-unknown-elf-gcc”的路径部分是怎么写的吧。

image.png

可以看到,“/bin/riscv64-unknown-elf-gcc”的路径由“TOOL_PATH”这个变量指定,而Makefile中并没有指定“TOOL_PATH”的值,所以Makefile执行时会从系统的环境变量中取出“TOOL_PATH”这个变量的值。而“TOOL_PATH”这个环境变量我们明明在之前的“setup.sh”脚本中已经指定了的,按理说如果这个环境变量设置成功的话,它的值会传递到Makefile中的才对。我们echo一下“TOOL_PATH”这个环境变量看看。

image.png

我们看到,“TOOL_PATH”这个环境变量确实设置成功了,那问题就出现在环境变量传递到Makefile的过程中。现在回到我们一开始说的那个问题,两个工程的文件内容是一模一样的,差别在于在终端上执行大部分命令时,命令前面带不带“sudo”。

回想之前在Project1工程(左终端)中,执行“setup.sh”脚本甚至环境变量时用的命令是:

左边终端:

llh@ubuntu:~/Project1/wujian100_open/tools$ source setup.sh

用的是普通用户身份执行,也就是用普通用户身份设置的环境变量。

而我们启动仿真时用的命令却是:

左边终端:

llh@ubuntu:~/Project1/wujian100_open/tools$ cd ../workdir/     #进入工作目录
llh@ubuntu:~/Project1/wujian100_open/workdir$ sudo ../tools/run_case -sim_tool iverilog ../case/timer/timer_test.c     #启动仿真

用的是root用户权限执行,也就是用root用户身份执行仿真(Makefile)。
所以,关键的原因在于:

root用户和普通用户的环境变量(echo $PATH)默认相同,但如果以普通用户身份登录系统修改环境变量,root用户的环境变量不受影响。这会导致通过sudo执行程序(比如make)所能看到的环境变量和不使用sudo执行程序所看到的环境变量是不同的。——引用自[CSDN博客:[Ubuntu]不同用户下环境变量问题](https://blog.csdn.net/LavenderSs/article/details/52719246?spm=a2oza.article_detail.0.0.619c180fRloKdA)

而Project2工程(右终端)因为一开始就是用普通用户身份创立的,它后续的仿真过程并不涉及到用户(权限)切换的问题,所以它最终成功跑通仿真。我一开始就是用Project1工程(左终端)的方式来仿真的,结果可想而知,先是报“command not found”的错误,我以为是环境变量没有设置成功,然后就上网找各种各样的的环境变量的设置方法,各种骚操作都来一遍,结果仍然是报这个错,搞得我很崩溃,然后我一怒之下就用了最简单粗暴的办法——把工具链里的命令全给复制到"/bin"目录下(你不是找不着吗,我直接塞你家门口!我让你再找不着!!),结果“command not found”错误倒是不报了,但是又出现了新的错误。。。后来经群友指教,觉得问题的关键在“TOOL_PATH”这个变量上,然后再去查环境变量和Makefile变量的资料,然后最终查到了用户身份(权限)的头上。

以上,就是我的踩坑-出坑记。一个小白的懵逼日常。

呼~~人生的第一篇正经博客,终终终终终终终终于写完了,虽然磨磨蹭蹭写了一大堆(水了一大堆),虽然整篇文章完全可以用最后引用的那个链接来概括……不过感觉还是挺爽的。

欢迎拍砖哦~~~ (溜

后记:关于markdown编写的文章图片不显示的问题

原来的文章发出去之后,发现文章里的图片显示不出来,只显示了类似于下面这样子的链接:

20191204 034224 的屏幕截图.png

后来查了一下,有说是因为引用的图片链接里出现了某些奇怪的字符,导致图片无法显示。然后我把图片链接复制到浏览器地址栏中访问,发现是可以访问到图片的,我又对比了一下浏览器地址栏中的图片链接和文章里的图片链接,发现是因为空格的问题

文章里的图片链接是:

https://cop-image-prod.oss-cn-hangzhou.aliyuncs.com/article/3722301684530774016/15754023480100/2019-12-04 03-42-24 的屏幕截图.png

地址栏里的图片链接是:

https://cop-image-prod.oss-cn-hangzhou.aliyuncs.com/article/3722301684530774016/15754023480100/2019-12-04%2003-42-24%20的屏幕截图.png

把链接里的空格换成"%20"就行了。

原文作者:Lianglonghui
点击查看原文

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
平头哥芯片开放社区
使用钉钉扫一扫加入圈子
+ 订阅

芯片开放社区(Open Chip Community 简称OCC),是平头哥芯片基础设施的云端载体,提供开发中心、创芯空间、技术部落等互动版块,汇聚海量应用资源,助力芯片合作伙伴构建软硬融合的芯片生态。面向芯片企业,OCC以应用驱动芯片精准定义、以全栈技术支撑芯片敏捷开发;面向开发者,OCC以芯片生态降低IoT开发门槛、以1520体系加速IoT产品落地。

官方博客
官网链接