Hi35xx Vx00 Linux Development Environment User Guide PDF
Hi35xx Vx00 Linux Development Environment User Guide PDF
User Guide
Issue 01
Date 2018-05-15
Copyright © HiSilicon Technologies Co., Ltd. 2018. All rights reserved.
No part of this document may be reproduced or transmitted in any form or by any means without prior
written consent of HiSilicon Technologies Co., Ltd.
, , and other HiSilicon icons are trademarks of HiSilicon Technologies Co., Ltd.
All other trademarks and trade names mentioned in this document are the property of their respective
holders.
Notice
The purchased products, services and features are stipulated by the contract made between HiSilicon
and the customer. All or part of the products, services and features described in this document may
not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all
statements, information, and recommendations in this document are provided "AS IS" without
warranties, guarantees or representations of any kind, either express or implied.
The information in this document is subject to change without notice. Every effort has been made in
the preparation of this document to ensure accuracy of the contents, but all statements, information,
and recommendations in this document do not constitute a warranty of any kind, express or implied.
Purpose
This document describes the Linux development environment of the Hi3536C V100. This
document also explains how to set up the Linux and network development environments, burn
the Linux kernel, and root file system, and start Linux-based applications.
After reading this document, customers will clearly understand the Linux development
environment.
Related Versions
The following table lists the product versions related to this document.
Hi3536C V100
Hi3521D V100
Hi3531D V100
Hi3520D V400
Hi3518E V200
Hi3518E V201
Hi3516C V200
Hi3521A V100
Hi3531A V100
Intended Audience
This document is intended for:
Technical support personnel
Software development engineers
Change History
Changes between document issues are cumulative. Therefore, the latest document issue
contains all changes made in previous issues.
Issue 01 (2018-05-15)
This issue is the first official draft release.
Issue 00B03(2017-12-20)
This issue is the third draft release.
Issue 00B02(2017-11-20)
This issue is the second draft release, which incorporates the following changes:
The prefix of "hisilicon$" is deleted throughout the document.
Chapter 1 Development Environment
In section 1.2, Table 1-1 is modified.
Section 1.3.2 is modified.
Chapter 3 Linux Kernel
Section 3.1 is updated.
Section 3.1.1 and section 3.1.2 are added.
Chapter 4 Root File System
Section 4.2.1, 4.2.2, and 4.3 are modified.
In section 4.3.2 and section 4.3.3, the "./" symbol is added at the beginning of the paths.
Contents
2 U-Boot .............................................................................................................................................. 3
3 Linux Kernel................................................................................................................................... 3
3.1 Kernel Source Codes ........................................................................................................................................ 3
3.1.1 Downloading the Kernel Source Code from the Linux Open Source Community ................................. 3
3.1.2 Installing the Patch .................................................................................................................................. 3
3.2 Configuring the Kernel..................................................................................................................................... 3
3.3 Compiling the Kernel and Generating the Kernel Image uImage .................................................................... 3
Figures
Figure 4-1 Structure of the root file system's top directory ................................................................................... 3
Tables
1 Development Environment
cross compilation mode, that is, in host+target machine (evaluation board) mode. The host
and target machine are typically connected through the serial port. However, they can also be
connected through the network port or Joint Test Action Group (JTAG) interface, as shown in
Figure 1-2.
The processors of the host and the target machine are different. A cross compilation
environment must be built on the host for the target machine. After a program is processed
through compilation, connection, and location, an executable file is created. When the
executable file is burnt to the target machine by some means, the program can then run on it.
After the target machine's bootloader is started, operational information about the target
machine is transmitted to the host and displayed through the serial port or the network port
and displayed. You can control the target machine by entering commands on the host's
console.
After a cross compilation environment is set up on the Linux server, and the Windows console
is connected to the reference board (REFB) through the serial port or network interface, the
developer can develop programs on the Windows console or on the Linux server through
remote login. Table 1-2 describes the software running in the Linux development
environment.
Although a Windows console exists in the development environment, many operations can be completed
on the Linux server, such as replacing the HyperTerminal with Minicom. Therefore, you can adjust the
development environment to your personal preferences.
Software Description
Windows console Operating Windows 98, Windows me, Windows 2000, Windows
system (OS) XP, or Windows 7
Application Putty, HyperTerminal, Trivial File Transfer Protocol
software (TFTP) server, and DS-5.
Linux server OS Ubuntu, Redhat, and Debian are supported, and there
are no special requirements. The kernel 2.6.18 or later
is supported. Additionally, full installation is
recommended.
Application Network file system (NFS), telnetd, Samba, and VIM,
software and ARM cross compilation environment. (For details
about the GCC versions, see Table 1-1.)
Other application software varies according to the
actual development requirements. The required
software is pre-installed by default. You need only
configure the software before using it.
Target board Boot Fastboot
program
OS HiSilicon Linux (HiLinux for short). The HiLinux
kernel is developed based on the standard Linux
kernel, and the root file system is developed based on
the BusyBox. (For details about the kernel and
BusyBox versions, see Table 1-1.)
Application Supports common Linux commands, such as telnetd
software and gdb server.
Program Uclibc and Glibc
development (For details about the versions of the development
library libraries, see Table 1-1.)
A cross compiler obtained from other sources (such as Internet) may not be compatible with
the existing kernel, and may result in unexpected issues during development.
A toolchain release package is seperately provided and contains two compilation toolchains:
arm-hisiv5x0-linux (based on Uclibc) and arm-hisiv6x0-linux (based on Glibc). For details
about the toolchain versions, see Table 1-1. In this document, arm-hisiXXX-linux is used to
represent the two toolchains.
To install the cross compiler, perform the following steps:
Step 1 Go to the toolchain directory and run the following command to decompress the toolchain:
cd toolchain
tar -xvf arm-hisiXXX-linux.tgz
2 U-Boot
3 Linux Kernel
3.1.1 Downloading the Kernel Source Code from the Linux Open
Source Community
Step 1 Go to the website www.kernel.org.
Step 2 Click HTTP or https://www.kernel.org/pub/.
Step 3 Click linux/.
Step 4 Click kernel/.
Step 5 Click v3.x/ or v4.x/
Step 6 Download linux-3.18.20.tar.gz (or linux-4.9.37.tar.gz).
----End
This section uses kernel linux-3.18.y as an example to describe how to install patches to the Linux
kernel, which applies to linux-4.9.y as well.
----End
If you are not familiar with the kernel and Hi35xx Vx00 platform, do not change the default
configuration. However, you can add modules as required.
The configuration files can be classified into the following types based on the boot medium of the flash
memory: hi35xx_full_defconfig and hi35xx_nand_defconfig. The former is used for configuring the SPI
NOR flash and SPI NAND flash, and the latter is used for configuring the parallel NAND flash. (Not all
platforms support the parallel NAND flash. For details, see Table 1-1.)
The two parameters ARCH = arm and CROSS_COMPILE = arm-hisiXXX-linux- must be added
after the make command during kernel compilation. The CROSS_COMPILE parameter indicates the
toolchain. In this document, the CROSS_COMPILE = arm-hisiXXX-linux- parameter indicates the
following two situations:
Hi35xx_V100R001C01SPCxxx corresponds to Uclibc. If the Uclibc toolchain is used, the
CROSS_COMPILE parameter is set to arm-hisiv5x0-linux-.
Hi35xx_V100R001C02SPCxxx corresponds to Glibc. If the Glibc toolchain is used, the
CROSS_COMPILE parameter is set to arm-hisiv6x0-linux-.
If errors occur during kernel compilation, execute commands in the following sequence:
make ARCH=arm CROSS_COMPILE=arm-hisiXXX-linux- clean
make ARCH=arm CROSS_COMPILE=arm-hisiXXX-linux- menuconfig,
make ARCH=arm CROSS_COMPILE=arm-hisiv100nptl-linux- uImage.
A common Linux root file system consists of all the directories in the root file system's top
directory structure. In an embedded system, the root file system needs to be simplified. Table
4-1 describes some directories that can be ignored.
Directory Description
/home, /mnt, /opt, and /root Directories that can be expanded by multiple users.
/var and /tmp The /var directory stores system logs or temporary service
program files.
The /tmp directory stores temporary user files.
/boot The /boot directory stores kernel images. During startup, the
PC loads the kernel from the /boot directory. For an
embedded system, the kernel images are stored in the flash
memory or on the network server instead of the root file
system to conserve space. Therefore, this directory can be
ignored.
Empty directories do not increase the size of a file system. If there is no specific reason, you are advised
to retain these directories.
The following takes busybox-1.20.2 as an example to describe how to configure the BusyBox,
which applies to busybox-1.20.2 as well.
For details about the CFLAGS configuration, see Table 4-2.
To configure the BusyBox, you need to go to the directory of the BusyBox, decompress the
source code file, and then run the following command:
1. cp osdrv/opensource/busybox/busybox-1.20.2/config_XXX_xx_softfp_neon
osdrv/opensource/busybox/busybox-1.20.2/.config //Specify a configuration file.
XXX indicates the toolchain, and xx indicates the CPU. For details, see Table 4-2.
2. make menuconfig
The configuration GUI of the BusyBox is the same as that of the kernel. By using the simple
and intuitive configuration options, you can configure the BusyBox as required. Pay attention
to the following two options that are displayed after you choose BusyBox Settings > Build
Options:
[*]Build BusyBox as a static binary (no shared libs)
[*] Build with Large File Support (for accessing files > 2 GB)
(arm-hisiv500-linux-) Cross Compiler prefix
() Path to sysroot
(-mcpu=cortex-a9 -mfloat-abi=softfp -mfpu=neon) Additional CFLAGS
() Additional LDLIBS
the option is deselected, the compiled BusyBox has a dynamic link. In this case, the
BusyBox has a small size but requires the support of the dynamic library.
The second option is used to select a cross compiler recommended in the SDK. After
configuration, you need to save the settings and close the BusyBox.
For details about the options of the BusyBox, see the BusyBox Configuration Help.
If the BusyBox is compiled and installed successfully, the following directories and files are
generated in the _install directory of the BusyBox:
drwxrwxr-x 2 xxx XXX 4096 October 18 10:58 bin
lrwxrwxrwx 1 xxx XXX 11 October 18 10:58 linuxrc -> bin/busybox
drwxrwxr-x 2 xxx XXX 4096 October 18 10:58 sbin
drwxrwxr-x 4 xxx XXX 4096 October 18 10:58 usr
Step 2 Provide required files in the etc, lib, and dev directories.
1. For the files in the etc directory, see the files in /etc of the system. The main files include
inittab, fstab, and init.d/rcS. You are recommended to copy these files from the
examples directory of the BusyBox, and then modify them as required.
2. You can copy device files from the system by running the cp –R file command or
generate required device files by running the mknod command in the dev directory.
3. The lib directory is used to store the library files required by applications. You need to
copy related library files based on applications.
----End
After the preceding steps are completed, a root file system is generated.
If you have no special requirements, the configured root file system in the SDK can be used directly. If
you want to add applications developed by yourself, you only need to copy the applications and related
library files to the corresponding directories of the root file system.
4.3.1 CRAMFS
CRAMFS is a new file system that was developed based on Linux kernel V2.4 and later.
CRAMFS is easy to use, easy to load, and has a high running speed.
The advantages and disadvantages of CRAMFS are as follows:
Advantages: CRAMFS stores file data in compression mode. When CRAMFS runs, the
data is decompressed. This mode can save the storage space in flash memory.
Disadvantages: CRAMFS cannot directly run on flash memory, because it stores
compressed files. When CRAMFS runs, the data needs to be decompressed and then
copied to the memory, which reduces read efficiency. Also, CRAMFS is read-only.
For Linux running on the board to support CRAMFS, you must add the cramfs option when
compiling the kernel. The process is as follows: After running make menuconfig, choose
File > systems, select miscellaneous filesystems, and then select Compressed ROM file
system support (the option is selected in the SDK kernel by default).
The mkfs.cramfs tool is used to create the CRAMFS image. To be specific, the CRAMFS
image is generated after you process a created file system by using mkfs.cramfs. This
procedure is similar to the procedure for creating an ISO file image using a CD-ROM. The
related command is as follows:
./mkfs.cramfs ./rootfs./cramfs-root.img
Where, rootfs is a created root file system, and cramfs-root.img is the generated CRAMFS
image.
4.3.2 JFFS2
JFFS2 is on the successor of the JFFS file system created by David Woodhouse of RedHat.
JFFS2 is the actual file system used in original flash chips of embedded mini-devices. As a
readable/writable file system with structured logs, JFFS2 has the following advantages and
disadvantages:
Advantages: The stored files are compressed. The most important feature is that the
system is readable and writable.
Disadvantages: When being mounted, the entire JFFS2 needs to be scanned. Therefore,
when the JFFS2 partition is expanded, the mounting time also increases. Flash memory
space may be wasted if JFFS2 format is used. The main causes of this are excessive use
of log files and reclamation of useless storage units of the system. The size of wasted
space is equal to the size of several data segments. Another disadvantage is that the
running speed of JFFS2 decreases rapidly when the memory is full or nearly full due to
trash collection.
To load JFFS2, perform the following steps:
Step 1 Scan the entire chip, check log nodes, and load all the log nodes to the buffer.
Step 2 Collate all the log nodes to collect effective nodes and generate a file directory.
Step 3 Search the file system for invalid nodes and then delete them.
Step 4 Collate the information in the memory and release the invalid nodes that are loaded to the
buffer.
----End
The preceding features show that system reliability is improved at the expense of system
speed. Additionally, flash chips with large capacity, the loading process is slower.
To enable kernel support for JFFS2, you must select the JFFS2 option when compiling the
kernel (the released kernel of HiSilicon supports JFFS2 by default). The process is as follows:
After running the make menuconfig command, choose File > systems, select miscellaneous
filesystems, and then select Journaling Flash File System v2 (JFFS2) support (the option is
selected in the SDK kernel by default).
To create a JFFS2 file system, run the following command:
./mkfs.jffs2 –d ./rootfs -l –e 0x20000 -o rootfs.jffs2
You can download the mkfs.jffs2 tool from the Internet or obtain it from the SDK. rootfs is a
created root file system. Table 4-3 describes the JFFS2 parameters.
Parameter Description
d Specifies the root file system.
l Indicates the little-endian mode.
e Specifies the buffer size of the flash memory.
o Exports images.
4.3.3 YAFFS2
YAFFS2 is an embedded file system designed for the NAND flash (including the SPI NAND
flash and parallel NAND flash). As a file system with structured logs, YAFFS2 provides the
loss balance and power failure protection, which ensures the consistency and integrity of the
file system in case of power failure.
According to the difference between the boot media of flash memories, if the Hi35xx
supports only SPI NAND flash, the tool to make the YAFFS2 file system is
mkyaffs2image100. If the Hi35xx supports the SPI NAND flash and parallel NAND flash,
the tools to make the YAFFS2 file system are the mkyaffs2image100 and
mkyaffs2image610.
The parallel NAND flash is supported only by Hi3531D V100 and Hi3531A V100.
4.3.4 ubifs
For details about the introduction and usage of the UBIFS file system, see the UBI File
System User Guide.
4.3.5 initrd
The initrd is equivalent to the store media and supports the formats such as ext2 and cramfs.
Therefore, the kernel must support both initrd and CRAMFS. The following configurations
must be complete to enable the initrd to work normally. Generally, the following
configurations are complete in the SDK by default. If you change the configurations by
mistake, do as follows:
Choose Device Drivers > Block devices, and select RAM block device support and
Initial RAM disk (initrd) support.
Choose File > systems, and select Miscellaneous filesystems and Compressed ROM
file system support.
To create an initrd image, perform the following steps:
Step 1 Create a CRAMFS image. For details, see section 4.3.1 "CRAMFS."
Step 2 Create an initrd image based on the created CRAMFS image by running the mkimage -A
arm -T ramdisk -C none -a 0 -e 0 -n cramfs-initrd -d ./cramfs-image cramfs-initrd
command.
----End
4.3.6 SquashFS
SquashFS is a read-only file system based on the Linux kernel and features high compression
rate.
SquashFS has the following features:
Compresses data, inode, and directories.
Retains 32-bit UID/GIDS and file creation time.
Supports a maximum of 4 GB file system.
Detects and deletes duplicate files.
To use SquashFS, perform the following steps:
Step 1 Create a kernel image supporting SquashFS. Go to the kernel directory, and run the following
commands:
cp arch/arm/configs/hi35xx_xx_defconfig .config
make ARCH=arm CROSS_COMPILE=arm-hisiXXX-linux- menuconfig (Save and then
exit)
make ARCH=arm CROSS_COMPILE=arm-hisiXXX-linux- uImage
Enable the option supporting the xz compression algorithm:
File systems --->
[*] Miscellaneous filesystems --->
<*> SquashFS 4.0 - Squashed file system support
[*] Include support for XZ compressed file systems
Step 2 Create the image of the SquashFS file system by using mksquashfs stored in
SDK/package/osdrv/tools/pc_tools. To use mksquashfs, run the following command:
./mksquashfs rootfs ./ rootfs.squashfs.img -b 64K –comp xz
where rootfs is the created root file system; rootfs.squashfs.img is the generated image of the
SquashFS file system; -b 64K indicates that the block size of the SquashFS file system is 64
KB (which determines the actual block size of the SPI flash); –comp xz indicates that the
algorithm for compressing the file system is XZ. You need to modify the parameters as
required.
----End
5 Application Development
Before running applications, you need to write and read the file system. You are recommended to use the
YAFFS2 or JFFS2 file system.
To create CRAMFS, YAFFS2 or JFFS2, you need to create corresponding file system (see
section 4.3 "Introduction to File Systems"), burn the root file system to the specified address
in the flash memory, and set the related boot parameters. In this case, new applications can
run properly after Linux starts.
To enable new applications to run automatically when the system starts, edit the /etc/init.d/rcS file, and
then add the paths of the applications to be started.
A
ARM advanced RISC machine
C
CRAMFS compressed RAM file system
D
DMS digital media solution
E
ELF executable and linkable format
G
GCC GNU compiler collection
GNU GNU's not Unix
I
IP Internet Protocol
J
JFFS2 journaling flash file system version2
JTAG joint test action group
P
PC personal computer
S
SDRAM synchronous dynamic random access memory
SDK software development kit
U
UBIFS unsorted block image file system