嘉楠K510开发套件的踩坑和填坑（小心得）

尝试嘉楠K510开发套件已经有几个月了，越是尝试越是觉得博大精深，艰难地做了一个小小的玩意，预计最快下周应该能够完成。一直没有能出什么帖子，实在有点不好意思，现暂时说一说心得吧：

一、如何在目标机里面添加自己的应用

嘉楠官方提供了一个docker的image，使用这个image可以比较便捷的准备好开发环境，大体来说，开发一个应用是两个步骤：

1、编译用于目标机的img文件

       嘉楠的说明文档其实已经写的比较清楚了，按照文档一步步操作，基本可以顺利完成img文件的生成，但这个img文件中自带的应用不多（而且我这里尝试似乎还有些错误，可以参考我之前的几个帖子）。如果需要自行添加应用（包括驱动等），官方也给出了通过配置config.in文件的方案自行编写各种应用，但感觉这是一个“重造轮子”的大工程，但对于我个人来说，能力实在有限，肯定无法面面俱到，只能想办法站在前人的肩膀上。

简单说可以按照如下步骤执行：

（1）假设已经执行完成过一次正常目标机文件生成，docker容器中已经有“k510_crb_lp3_v1_2_defconfig”目录

（2）修改物理机中“k510_buildroot\k510_crb_lp3_v1_2_defconfig”文件夹下的“.config”文件

（3）在docker的容器中，执行“k510_crb_lp3_v1_2_defconfig”目录下的make

当然，在第二步操作的时候得非常小心（每次只改动一点点，而且需要反复尝试，根据提示，系统中缺少什么就补充什么），不然在第三步的时候很可能出现类似下面的提示，导致无法编译通过：

 

按照嘉楠技术支持（ai_product@canaan-creative.com）的说法，使用

make menuconfig

命令修改.config文件，这样可以保证正确性，但我尝试过，实际上也还是会发生无法编译的情况。

另外，大家有兴趣也可以尝试：

make nconfig命令和make config命令

效果是类似的。

不过在使用菜单配置的方式下，可以规避一些安装交叉库的风险，例如我们取消安装WCHAR之后，python和ruby的选单就自动关闭了，这个确实还是很有用的。

 

 

2、编写目标机所用的单个应用程序

       在docker容器内toolchian目录中，可以看到只有三个工具链：nds641e-elf-mculib-v5d、nds641e-linux-glibc-v5d、python。

 

其中python显然不是能直接生成可以在目标机中运行的代码，而是帮助打包或者生成集成环境用的。

进入nds641e-elf-mculib-v5d或者nds641e-linux-glibc-v5d目录，可以看到实际上是提供的是c的编译器，可以通过编译c代码的源文件，成为可以在目标机上直接运行的应用程序。只要将生成的应用程序文件放到目标机，确认文件具有x属性就能执行，当然如果遇到执行时需要调用外部库，还需要看目标机是否已安装对应版本的库。

以最简单的“helloworld.c”（容器自带）为例，可以在其所在目录下执行

../../../toolchain/nds64le-linux-glibc-v5d/bin/riscv64-linux-gcc hello.c

生成一个a.out文件

 

       可以看到，编译后的a.out是有可执行权限的，但是把这个文件放到目标机的过程中，因为经过了windows转换进行拷贝，丧失了可执行权限，需要再chmod一下，如下：

 

二、执行脚本

       缺省生成目标机系统中，可以直接用sh，而且有解释器python（不过嘉楠的技术支持说不支持python，我理解是支持程度不佳，但实际可以用），但没有编译器，这点很奇怪，因为从.config文件分明看到了

 

       也就是说，理论上可以直接在目标机内使用编译器编译出支持RISC-V环境下的应用，但不知道为什么，使用

       find / -name *gcc*

虽然有些库，但找不到对应的工具链

 

       当然，这个影响不大，反正一般也是在目标机上直接使用编译好的程序，而不会直接目标机上去编译。

       如前所述，目标机上已经安装了解释功能，解释器翻译源程序时不会生成独立的目标程序，而是直接根据源代码执行动作，解释器也可用命令行方式让一个文本文件（或者“字符串”）具有“运行”功能，比如下面的Hello, world。

 

       一般使用如下命令来感受一下浮点运算速度

echo "scale=1000; 4*a(1)" | bc -l

还行，起码没报错。

 

如上一节所述，可以使用make config、make nconfig或者make menuconfig修改.config文件，在docker容器内make以后生成的img中就包含了预先添加的各种python模块（虽然不一定能用）。

 

我尝试了一些，比如会导致环境崩溃的引用cv2，或者因为pytest库未安全导致无法使用的numpy，感觉把应用能力废了一半。

 

这个仍在继续研究，嘉楠方面没有直接答复修复python崩溃的修复方案，但给出了一个解决思路（我认为的），那就是不要直接用opencv-python，而是使用ctype方式调用.so来实现。邮件原文：

 

 

 

三、新的解释器和编译器

       如之前介绍，可以通过make menuconfig使目标机系统上安装一些新的模块，就开发来说可以找到解释器有这些：

 

       随便安装一个试试，比如lua。

 

当然装太多解释器也没太多意思，写在#!后面的东西把自己都绕晕了。

 

四、碰到的怪问题和解决

常规问题都没啥好说的，说几个奇奇怪怪的问题和我用的解决办法：

1、出现make“skeleton-init-sysv”异常

估计是权限原因，在target/var目录下一些残留文件导致make失败，可以手工进入目录删除，重新编译即可。类似的情况颇多，比如：

 

碰到了只能手工删除重来一遍。。。

2、pip安装whl模块

Python安装工具pip，如果希望安装whl模块，往往需要改名字，改了名字才能在开发板上安装，推测是pip根据文件名确认支持的版本。

3、忘记docker容器内menuconfig里面哪里改了怎么办？

打开.config文件，和.config.old文件相比较，找到修改的地方，再向上找到空行，空行下方一般就有类似“# Target options”字样，那里就是menuconfig的上级菜单。

4、为什么使用make menuconfig看不到效果

每次使用make menuconfig实际上是修改k510_crb_lp3_v1_2_defconfig目录下的.config文件，但在k510_buildroot下使用make命令，会重新生成.config，并将之前修改的.config文件改名为.config.old，因此需要在k510_crb_lp3_v1_2_defconfig目录下执行make。

不过这样也好，万一改乱了还可以直接用k510_buildroot/make兜底。

5、riscv64-linux-gcc.br_real 丢失的问题

会出现

ccache: error: execv of /opt/k510_buildroot/k510_crb_lp3_v1_2_defconfig/host/bin/riscv64-linux-gcc.br_real failed: No such file or directory

提示，尝试查看这个文件，发现是一个软链接

 

如我在本文第一节所述，编译器所需的实际链接是

toolchain/nds64le-linux-glibc-v5d/bin/riscv64-linux-gcc

把这个软链接改掉

 

就可以了。

6、fails sanity check的解决方法

这个问题出现得很奇怪，我碰到过几次，一般第一次make出现，但同样操作一遍就没有发生了，怀疑是需要从网络里面下载某些库，但第一次没有下载成功，重新运行以后会再次下载。

如果碰到了，不妨多试几次，也许就好了。

7、从技术支持获得解决方案

嘉楠的技术支持一般不会正面回复问题，而是用启发的方式帮助解决问题，甚至类似武侠秘籍“九阳真经”一样把答案夹杂在其它文学作品中，这点我认为作为开发板的技术支持实在是太棒了，把答案直接告诉了，虽然看似减少开发者走弯路，但让乐趣降低太多。比如问到为什么在屏幕显示的文字smile（蓝色）会变成这样

 

邮件的答复是：“这个显示异常的文字是中文，默认显示是英文，对长度也有要求”，虽然看起来好像不太对，但深入理解以后，其实答复的意思是在开发板中，使用drm，是分层显示的，其中文字层显示宽度和屏幕实际长度不一致造成的该现象，虽然第二句不太明白，但至少第一句和第三句连在一起算是大致搞懂意思了，而且尽管我还没找到合适方法，但按照答复修改了源文件中关于屏幕长宽的参数，的确会出现不同的显示效果。

类似答复还有不少，虽然悟性有限，对于答复还没理解透，但真的很有意思。大家碰到这样有趣的技术支持，不要抱怨答非所问，其实答案实际都在邮件回复里了，只是需要你自己去动脑筋。

 

总结

       简单说，在K510上做开发不算太难，需要做好两个工作：

1）使用docker容器制作img

       这个步骤中包括准备好运行编译后执行程序所用的库，但并不需要装编译器本身；以及解释器。

2）生成可以执行的目标代码

       这个步骤分为两种，如果是编译文件，那么可以在docker的容器里面执行编译，把编译后的文件拷贝到目标机执行；如果是解释文件，那无所谓开发环境，哪怕是用vi编写也行，反正只要是符合规则的文本文件，弄到目标机上，让解释器去处理就可以了。

其中python显然不是能直接生成可以在目标机中运行的代码，而是帮助打包或者生成集成环境用的。

感谢楼主无私分享心得。

嘉楠的技术支持一般不会正面回复问题，而是用启发的方式帮助解决问题

Not installing /opt/k510_buildroot/k510_crb_lp3_v1_2_defconfig/host/riscv64-buildroot-linux-gnu/sysroot/usr/libexec/dbus-daemon-launch-helper binary setuid!

You'll need to manually set permissions to root:dbus and permissions 4750

mkdir: cannot create directory '/opt/k510_buildroot/k510_crb_lp3_v1_2_defconfig/host/riscv64-buildroot-linux-gnu/sysroot/var/run': Not a directory

mkdir: cannot create directory '/opt/k510_buildroot/k510_crb_lp3_v1_2_defconfig/host/riscv64-buildroot-linux-gnu/sysroot/var/run': Not a directory

make[6]: *** [Makefile:1796: install-data-hook] Error 1

make[5]: *** [Makefile:1666: install-data-am] Error 2

make[4]: *** [Makefile:1570: install-am] Error 2

make[3]: *** [Makefile:706: install-recursive] Error 1

make[2]: *** [package/pkg-generic.mk:310: /opt/k510_buildroot/k510_crb_lp3_v1_2_defconfig/build/dbus-1.12.20/.stamp_staging_installed] Error 2

make[1]: *** [Makefile:23: _all] Error 2

make[1]: Leaving directory '/opt/k510_buildroot/k510_crb_lp3_v1_2_defconfig'

make: *** [Makefile:80: install] Error 2

请问这个怎么解决？

我没碰到类似问题，但看你贴出来的提示这个：

You'll need to manually set permissions to root:dbus and permissions 4750

应该是权限不够吧，试试用root？