Canaan K510 development kit stepping on the pit and filling the pit (little experience)
[Copy link]
I have been trying the Canaan K510 development kit for a few months. The more I try, the more I feel it is profound. I made a small gadget with great difficulty. I expect it should be completed by next week at the earliest. I have not been able to post anything for a long time. I am really embarrassed. Now I will talk about my experience for the time being:
1. How to add your own application in the target machine
Canaan officially provides a docker image, which can be used to prepare the development environment more conveniently. Generally speaking, developing an application is a two-step process:
1. Compile the img file for the target machine
Canaan's documentation is actually quite clear. If you follow the documentation step by step, you can basically complete the generation of the img file smoothly, but there are not many applications included in this img file (and there seem to be some errors in my attempts here, you can refer to my previous posts). If you need to add applications by yourself (including drivers, etc.), the official also provides a solution to write various applications by configuring the config.in file, but it feels like a big project of "reinventing the wheel". For me personally, my ability is really limited, and I certainly can't cover everything. I can only find a way to stand on the shoulders of my predecessors.
Simply put, you can follow the steps below:
(1) Assume that the target machine file generation has been completed once and the "k510_crb_lp3_v1_2_defconfig" directory already exists in the Docker container.
(2) Modify the ".config" file in the "k510_buildroot\k510_crb_lp3_v1_2_defconfig" folder on the physical machine
(3) In the docker container, execute make in the "k510_crb_lp3_v1_2_defconfig" directory
Of course, you must be very careful in the second step (change only a little at a time, and try repeatedly, and add what is missing in the system according to the prompts), otherwise you may get a prompt like the following in the third step, which will cause the compilation to fail:
According to Canaan Technical Support (ai_product@canaan-creative.com), use
make menuconfig
The command modifies the .config file, which can ensure correctness, but I have tried it and it still fails to compile.
In addition, if you are interested, you can also try:
make nconfig command and make config command
The effect is similar.
However, by using the menu configuration method, some risks of installing cross-libraries can be avoided. For example, after we cancel the installation of WCHAR, the python and ruby menus are automatically closed, which is indeed very useful.
2. Write a single application for the target machine
In the toolchian directory in the docker container, you can see that there are only three toolchains: nds641e-elf-mculib-v5d, nds641e-linux-glibc-v5d, and python.
Python is obviously not able to directly generate code that can be run on the target machine, but is used to help package or generate an integrated environment.
Enter the nds641e-elf-mculib-v5d or nds641e-linux-glibc-v5d directory, and you can see that it actually provides a C compiler, which can compile the C code source file to become an application that can be directly run on the target machine. Just put the generated application file into the target machine and confirm that the file has the x attribute before it can be executed. Of course, if you need to call an external library during execution, you also need to check whether the target machine has installed the corresponding version of the library.
Take the simplest "helloworld.c" (provided in the container) as an example, you can execute it in its directory
../../../toolchain/nds64le-linux-glibc-v5d/bin/riscv64-linux-gcc hello.c
Generate an a.out file
It can be seen that the compiled a.out has executable permissions, but when putting this file into the target machine, it loses the executable permissions because it is copied after Windows conversion. It needs to be chmod again, as follows:
2. Execute the script
In the default target system, you can use sh directly, and there is a python interpreter (but Canaan's technical support said that python is not supported. I understand that the support is not good, but it can be used in practice), but there is no compiler, which is very strange, because it is clearly seen in the .config file
In other words, in theory, you can use the compiler directly in the target machine to compile applications that support the RISC-V environment, but for some reason, using
find / -name *gcc*
Although there are some libraries, the corresponding toolchain cannot be found
Of course, this has little impact, because compiled programs are usually used directly on the target machine anyway, rather than being compiled directly on the target machine.
As mentioned earlier, the target machine has an interpretation function installed. When the interpreter translates the source program, it does not generate an independent target program, but directly executes actions based on the source code. The interpreter can also use the command line method to allow a text file (or "string") to have the "run" function, such as the following Hello, world.
Generally, the following commands are used to feel the floating-point operation speed
echo "scale=1000; 4*a(1)" | bc -l
It’s OK, at least there is no error.
As described in the previous section, you can use make config, make nconfig, or make menuconfig to modify the .config file. The img generated after make in the docker container will contain various pre-added python modules (although they may not be usable).
I tried some, such as referencing cv2 which caused the environment to crash, or numpy which could not be used because the pytest library was not secure. I felt that half of the application capabilities were wasted.
This is still under study. Canaan did not directly respond to the solution to fix the Python crash, but gave a solution (in my opinion), which is not to use opencv-python directly, but to use ctype to call .so to implement it. Original email:
3. New Interpreter and Compiler
As mentioned before, you can use make menuconfig to install some new modules on the target system. For development, you can find the following interpreters:
Just install one and try it, such as lua.
Of course, there is not much point in installing too many interpreters. The things written after #! make me dizzy.
4. Strange problems encountered and solutions
There is nothing much to say about the common problems, but here are some strange problems and the solutions I used:
1. Make "skeleton-init-sysv" exception occurs
It is probably due to permission issues. Some residual files in the target/var directory caused make to fail. You can manually enter the directory to delete them and recompile. There are many similar situations, such as:
If you encounter this, you can only delete it manually and start over. . .
2. pip install whl module
Python installation tool pip, if you want to install the whl module, you often need to change the name, and then change the name to install it on the development board. It is speculated that pip confirms the supported version based on the file name.
3. What should I do if I forget what I changed in the menuconfig in the Docker container?
Open the .config file and compare it with the .config.old file. Find the modified part and then find a blank line. There is usually something like "# Target options" below the blank line. That is the parent menu of menuconfig.
4. Why can't I see the effect of using make menuconfig?
Each time you use make menuconfig, you are actually modifying the .config file in the k510_crb_lp3_v1_2_defconfig directory. However, using the make command under k510_buildroot will regenerate .config and rename the previously modified .config file to .config.old. Therefore, you need to execute make in the k510_crb_lp3_v1_2_defconfig directory.
But this is also good, if you make a mess, you can just use k510_buildroot/make as a backup.
5. riscv64-linux-gcc.br_real is missing
Will appear
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
Tip: Try to view this file and find that it is a soft link
As I mentioned in the first section of this article, the actual linking required by the compiler is
toolchain/nds64le-linux-glibc-v5d/bin/riscv64-linux-gcc
Change this soft link
That's it.
6. Solutions to failed sanity checks
This problem appears very strangely. I have encountered it several times. It usually occurs the first time make is run, but it does not occur after the same operation is performed again. I suspect that some libraries need to be downloaded from the Internet, but the download is not successful the first time. It will be downloaded again after re-running.
If you encounter this, try a few more times and maybe it will work.
7. Get solutions from technical support
Canaan's technical support usually does not directly respond to questions, but helps solve problems in an inspiring way, and even mixes the answers in other literary works like the martial arts secret book "Nine Yang Manual". I think this is really great for the technical support of the development board. It tells the answer directly. Although it seems to reduce the detours for developers, it reduces the fun too much. For example, when asked why the text smile (blue) displayed on the screen becomes like this
The reply in the email was: "The text that displays abnormally is in Chinese, the default display is in English, and there are also requirements for the length." Although it seems wrong, after a deeper understanding, the reply actually means that in the development board, drm is used, which is displayed in layers. The phenomenon is caused by the inconsistency between the display width of the text layer and the actual length of the screen. Although I don’t quite understand the second sentence, at least the first and third sentences together can be regarded as a general understanding of the meaning. Although I haven’t found a suitable method yet, I have modified the parameters of the screen length and width in the source file according to the reply, and different display effects will indeed appear.
There are many similar replies. Although my understanding is limited and I haven't fully understood the replies, they are really interesting. If you encounter such interesting technical support, don't complain about irrelevant answers. In fact, the answers are actually in the email replies, you just need to use your brain.
Summarize
In short, developing on K510 is not too difficult. You need to do two things:
1) Use docker container to create img
This step includes preparing the libraries needed to run the compiled executable, but does not require the compiler itself; as well as the interpreter.
2) Generate executable target code
This step is divided into two types. If it is a compiled file, you can execute the compilation in the Docker container and copy the compiled file to the target machine for execution. If it is an interpreted file, it does not matter what the development environment is, even if it is written in vi, as long as it is a text file that conforms to the rules, get it to the target machine and let the interpreter process it.
| 
提升卡
变色卡
千斤顶
京公网安备 11010802033920号
