Learning to build an embedded Linux system v0.1 (Full Version)

Chapter 1 Preface The purpose of this article is to introduce the general process of establishing and developing an embedded Linux system. A small Linux system can be transplanted to other hard disks, floppy disks, USB disks, and Flash ROM ......

What should I do to build an embedded Linux system? That is, what is the content of this article? I will first introduce a context that can be used as an outline of our subsequent work: the first step is to build a cross-compilation environment for readers who have no cross-development experience. It may be difficult to accept this concept at the moment. First of all, we need to understand two concepts: Generally, the machines we work on are called development machines and hosts. The systems we make will be placed on a certain machine, such as a mobile phone or another PC, this host is called the target host. We generally have a set of development tools on the development machine. We call them Native Development Kits. We generally use them to write programs. So what is the cross-compiling environment? In fact, it is not mysterious at all, that is, installing a development tool on the development machine, the program compiled by this development tool, such as the kernel, system work or our own program, is run on the target host. So some beginners may ask, simply using native development tools to compile programs for the target host is not enough? At least I thought so. Generally, our development machines are both x86 platforms, and Native Development Kits are also used for x86 platforms. Our target hosts may be PowerPC, IXP, MIPS ...... Therefore, our cross-compilation environment is for a specific type of platform. Generally speaking, the cross-development environment requires binary tool programs, compilers, and C-linked libraries. The three types of software commonly used in embedded development are: binutils GCC uclibc, you need to make the selection based on your actual needs.

Step 2: Compile the kernel development tool for a certain type of hardware platform. In this step, we need to use the tool created in step 1 to compile the kernel. This is very simple for people with kernel compilation experience;

Step 3: Create the root file system, that is, build the bin, Dev, proc ...... This pile of directories and some necessary files; in addition, we also need to install some common tool software for our target system, such as LS, ifconfig ...... Of course, one way is to find the source code of these tools and compile it with the cross-compilation tool established in the first step. However, these software are large in quantity and some are large in size, this step is not suitable for embedded systems. We generally use busybox to complete this step, including the system boot software init. Finally, we need to create initialization boot files for the system, such as inittab ......

Step 4: Start the system. In this step, we copy all the established targets, files, programs, kernels, and modules to the target memory, such as hard disks. Then install bootloader for the system. For embedded systems, there are many boot programs available for us. However, many of them have restrictions on hardware platforms. Of course, if you are working on x86, you can directly use LILO for guidance. In fact, this article uses Lilo. In this step, the target storage device is mounted to the target machine. If it succeeds, the system can be started. Of course, for some special platforms, it cannot be copied like a hard disk, and requires a card reader, burning ...... But the basic methods are the same!

Step 5: optimize and personalize the system through the first four steps, we have a system that can work normally. In this step, it is time to make full use of your imagination ......

In this article, the working environment project root directory/home/Kendo/Project ------>; I will specify it to the path: $ prjroot subdirectory and the bootstrap loader program that describes the directory content of the bootloader target board, for example, Build-tools such as lilo build a cross-compilation platform tool source code debug debugging tool and all the documents used in the doc project of all relevant packages images compiled kernel image, and the root file system of Linux kernel source code rootfs of each kernel version of the kernel. The system application system to be used by the sysapps target board, such as thttpd, TMP, such as udhcpd, stores temporary files, tools, compiled cross-platform development tool chains, and C-linked libraries.

Working script #! /Usr/bin

Export project = Skynet export prjroot =/home/$ {project} export target = i386-linux export prefix =$ {prjroot}/tools export target_prefix =$ {prefix}/$ {target} Export path =$ {prefix}/bin: /bin:/sbin:/usr/bin:/usr/sbin

CD $ prjroot

Chapter 2 create a cross-compilation environment in another Post published in Cu with the same name. I will introduce a method for creating a cross-compilation environment manually. Currently, there are two ways to create a cross-compilation environment, including creating a root file. Generally, you can customize the Maximum program by hand. The disadvantage is that the process is complicated and especially prone to errors, pay attention to this "pole" word, including experienced developers; it is convenient to automatically create without it.

Because the previous article described the general method for creating a cross-compiling environment by hand, this article does not intend to repeat this step. If you are interested, you can search for the post, note that when preparing the tool chain, you should pay attention to the matching of each tool version and the Patches required for each tool. I suggest you search for these two items on Google, prepare a list. Otherwise ...... This chapter describes how to automatically create a cross-compiling environment. Purpose: for commercial hardware platforms, manufacturers will provide you with an Development Kit. I have used ixp425 and MIPS from XX manufacturers, which is very convenient. I remember my first contact with embedded development, I used this development kit to automatically create a cross-compiling environment, compile the kernel, create a root file system, and create a RAM disk three or four times. I still don't know what I did, oh, silly enough ...... Therefore, it is recommended that readers who do not have experience in this area should first try the manual creation method, and the following content in this chapter, it is sent to a friend who has been deeply hurt by it and does not want to experience this job again, but wants to improve the rate of interaction and work on a general platform without a commercial development kit.

Build cross-development toolchain preparation tools: buildroot-0.9.27.tar.tar only need one software? Yes, you don't need to prepare others. buildroot is actually a collection of scripts and patches. You only need to specify the corresponding version in buildroot for other required software, such as GCC and uclibc, it will be automatically downloaded for you. In fact, it takes time for buildroot to download all the work required to the Internet. Unless you have enough bandwidth, software download may take up to 80% of the time, all the required work chains are on my local hard drive. After I decompress buildroot, I create a new DL folder and copy the compressed package of the source code of all tools, buildroot does not need to be downloaded online.

My Software List: Linux-libc-headers-2.4.27.tar.bz2 Gcc-3.3.4.tar.bz2 binutils 2.15.91.0.2.tar.bz2 uclibc 0.9.27.tar.bz2 genext2fs_1.3.orig.tar.gz ccache-2.3.tar.gz

Copy it to $ {prjroot}/build-tools, unzip [root @ Skynet build-tools] # tar jxvf buildroot-0.9.27.tar.tar [root @ Skynet build-tools] # cd buildroot to configure it: [root @ Skynet build-tools] # Make menuconfig target architecture (i386) --->; on the hardware platform, choose i386 build options --->; under the compilation option, what is important is ($ {prjroot}/tools) toolchain and header file location? Where is the compiled tool chain? If you like me, all the toolkit is local and you don't need to download it online automatically, you can clear the wget command option; toolchain options --->; toolchain options --- the kernel Header Options header file will be automatically downloaded, but it should be ensured that it is the same version as the kernel you are going to use; [] use the daily snapshot of uclibc? Use the latest uclibc snapshot binutils version (binutils 2.15.91.0.2) --->; binutils version GCC compiler version (GCC 3.4.2) --->; GCC version

Build/install C ++ compiler and libstdc ++? [] Build/install Java compiler and libgcj? Supported languages. I didn't select Java [] Enable ccache support? Enable the support of ccache. It is used for caching the header file during compilation and compiling the program. It will be a little slow for the first time, but the speed will be very satisfactory in the future ...... --- GDB options select GDB support based on your needs

Package selection for the target --->; I did not select any one, because I plan to manually create a tool chain such as the root file system and busybox. Target options --->; specifies the type of the file system. Select ext2 as needed;

After the configuration is complete, compile it: [root @ Skynet build-tools] # Make

This job takes a lot of time. My toolkit is all local, and it also takes me an hour and 13 minutes. If you want to download it all, it will take me an hour or two to get the network speed normally.

After a long wait (in fact, it is not long. I played a few games and it soon passed ):...... Make [1]: leaving directory '/home/Skynet/build-tools/buildroot/build_i386/genext2fs-1.3 'touch-C/home/Skynet/build-tools/buildroot/build_i386/genext2fs-1.3/genext2fs #-@ find/home/Skynet/build-tools/buildroot/build_i386/root/lib-type F-name /*. so/* | xargs/home/Skynet/tools/bin/i386-linux-uclibc-strip -- remove-Section =. comment -- remove-Section =. note -- strip-unneeded 2>;/dev/null | true; /home/Skynet/build-tools/buildroot/build_i386/genext2fs-1.3/genext2fs-I 503-B 1056/-D/home/Skynet/build-tools/buildroot/build_i386/root- q-D target/default/device_table.txt/home/Skynet/build-tools/buildroot/root_fs_i386.ext2

Success !!!

Check the trophy and let me see what it has done: [root @ Skynet] # cd tools [root @ Skynet tools] # ls Bin-ccache i386-linux i386-linux-uclibc include info lib libexec man USR

Bin: All compilation tools, such as GCC, are here, but some specified prefixes are added. Bin-ccache: if you do not select support for ccache in toolchain optaion, there is no such item; i386-linux: Link file; actually pointing to include i386-linux-uclibc: uclibc related tools; include: header file for cross development tools; Info: GCC info file; LIB: link library files for cross-development tools ;......

Now you can add the xxx/bin directory where the compilation tool is located to path.

Test tool chain if you write a program and compile it with a i386-linux-gcc, the running program will tell you :. /test: linked against GNU libc because the program running library will find the default/lib:/usr/lib, however, our current uclibc library is not there (although there is nothing wrong with the target machine), so we can only temporarily compile it statically and try whether it can work. Of course, you can also try chroot after creating the root file system ......

Chapter 3 compiling the kernel This chapter aims to create a suitable kernel for the target machine. For kernel creation, I have two points worth considering: 1. Functional options, should be able to meet the needs, as small as possible; 2. Small is not the ultimate goal, stability is;

Therefore, it is best to have a list of hardware platforms of the target machine and a list of required functions before compiling the kernel so that the kernel can be reduced more rationally.

Prepare the linuxlinuxkernel source code. I chose linux-2.4.27.tar.bz2.

Compile and copy linux-2.4.27.tar.bz2 to $ {prjroot}/kernel, unzip # cd linux-2.4.27 // configuration # Make arch = i386 cross_compile = i386-linux-menuconfig // build source code dependency # Make arch = i386 cross_compile = i386-linux-clean Dep // build kernel Image # Make arch = i386 cross_compile = i386-linux-bzimage arch specifies the hardware platform, cross_compile specifies that this is a cross-compilation and the compiler name is a i386-linux-XXX, where no path is specified for the compiler because I have previously added it to the environment variable path.

It's a long wait ...... OK, the compilation is complete, 673 K, a little bigger. If you want to move it to another platform, you may have to find a way to do the work below 512.

After the kernel is compiled, copy the kernel and configuration file to $ {prjroot}/images. # Cp ARCH/i386/boot/bzimage ${prjroot}/images/bzImage-2.4.27-rmk5 # cp vmlinux ${prjroot}/images/vmlinux-2.4.27-rmk5 # cp system. map ${prjroot}/images/System-2.4.27-rmk5 # cp. CONFIG ${prjroot}/images/2.4.27-rmk5

I used a suffix to rename the kernel to manage multiple different versions. Of course, you do not need, it is also feasible to create a corresponding folder for each version of the kernel under images.

After the complete kernel compilation of the kernel module is installed, the rest of the work is to establish and install the module, because my kernel does not select the support of the module (this is a little less scalable, however, for my system, the function is basically fixed, and the impact is not very big), so the remaining steps are also saved. If you still need the support of the module, you should: // create Module # Make arch = i386 cross_compile = i386-linux-modules // install kernel module to $ {prjroot}/images # Make arch = i386 cross_compile = i386-linux-/>; install_mod_path =$ {prjroot}/images/modules-2.4.18-rmk5/>; modules_install

The last step is to establish dependency for the module, instead of using native depmod, instead of using a cross-compilation tool. We need to use the depmod. pl script in busybox. Unfortunately, I did not find this script in busybox1.0.0. Therefore, we borrowed depmod. pl in scripts in busybox0.63. Copy depmod. Pl to the $ {prefix}/bin directory, that is, the bin directory of the Cross-compilation toolchain. # Depmod. PL/>;-K. /vmlinux-f. /system. MAP/>;-B $ {prjroot}/images/modules-2.4.27-rmk5/lib/modules >;/>; $ {prjroot}/images/modules-2.4.27-rmk5/lib/modules/2.4.27-rmk5/modules. dep

Note: I will only mention kernel copying when porting the kernel and module content later, because my system does not support modules. To use a module, copy it to the corresponding directory in the same way.

Attachment, kernel compilation list attachment, kernel Selection: Kernel compilation record: Code maturity level options do not select loadable module support do not select Processor type and features according to the actual, select the processor type General setup --->;

Networking Support

PCI support (any) PCI Access Mode

PCI device name database

System V IPC

Sysctl support (ELF) kernel core (/proc/kcore) Format

Kernel support for elf Binaries

Power Management Support

Memory technology devices (MTD) --->; MTD device, I use a CF card, no

Parallel Port support --->; do not select Plug and Play configuration --->; my system does not require plug-and-play. Do not select

Block devices --->;

Loopback device support

RAM disk support (4096) default RAM disk size (new)

Initial RAM disk (initrd) Support

Multi-Device Support (raid and LVM) --->; no

Networking options --->;

ATA/IDE/MFM/rll support --->; the default

Telephony support --->; not selected

SCSI support --->; not selected

Fusion MPT device support --->; not selected

I2o device support --->; not selected

Network Device Support --->; select according to the actual situation

Amateur Radio support --->; not selected

IRDA (infrared) support --->; no

ISDN subsystem --->; not selected

Old CD-ROM drivers (not SCSI, not IDE) --->; not selected

Input core support --->; not selected

Character devices --->;

Virtual Terminal

Support for console on virtual terminal

Standard/generic (8250/16550 and compatible uarts) Serial support

Support for console on Serial Port

Multimedia devices --->; not selected

File systems --->;

Kernel automounter version 4 Support (also supports V3)

Virtual Memory File System Support (former shm fs)

/Proc file system support

Second extended FS Support

Console drivers --->;

VGA text console used for display debugging

Do not use sound for the remaining three --->; USB support --->; kernel hacking --->;

Chapter 4 Create a root file system 1. When creating a directory to build a workspace, The rootfs folder is used to store the root file system. # cd rootfs creates various directories based on the basic structure of the root file system: # mkdir bin Dev etc lib proc sbin tmp usr var root home # chmod 1777 TMP # mkdir usr/bin usr/lib usr/sbin # ls Dev etc lib proc sbin tmp usr var # mkdir var/lib var/lock var/log var/run var/tmp # chmod 1777 var/tmp

For a single user system, root and home are not required. After preparing the skeleton of the root file system, install the previously created file in the corresponding directory. 2. Copy the Link Library and copy the uclibc library file to the created lib Folder: # cd $ {prefix}/lib [root @ Skynet lib] # Cp *-*. so $ {prjroot}/rootfs/lib [root @ Skynet lib] # cp-D *. so. [* 0-9] $ {prjroot}/rootfs/lib

3. Copy the kernel image and kernel module because there is no module, the copy module saves time and creates a new boot directory, copy the kernel we just created # cd/home/Kendo/control-Project/DAQ-module/rootfs/# mkdir boot # cd $ {prjroot}/images # cp bzImages-2.4.18-rmk5/home /Kendo/control-Project/DAQ-module/rootfs/boot

4. Create the device files under/dev in Linux, store all the device files in/dev, and use the mknod command to create basic device files. The mknod command requires the root permission, but even the root user is used. A new user was created for Embedded production, but later I forgot to use it ...... # Mknod-m 600 mem C 1 1 # mknod-M 666 null C 1 3 # mknod-M 666 zero C 1 5 # mknod-M 644 random C 1 8 # mknod-m 600 tty0 C 4 0 # mknod-m 600 tty1 C 4 1 # mknod-m 600 ttys0 C 4 64 # mknod-M 666 tty C 5 0 # mknod-m 600 console C 5 1. After basic device files are created, create a symbolic link: # ln-S/proc/self/FD # ln-s FD/0 stdin # ln-s FD/1 stdout # ln-s FD/2 stderr # ls console FD mem null random stderr stdin stdout tty tty0 tty1 ttys0 zero

You do not need to manually create device files. I heard that the script makedev under RedHat/Dev can implement this function, but I have not tried it ......

Basically, I want to use a hard disk or a CF card as a storage device. I also need to create related files for them, because my CF is on the target machine, you can treat them like this. First, let's take a look at the had attributes below RedHat: # ls-L/dev/hda BRW-RW ---- 1 root disk 3, 0 Jan 30 2003/dev/hda # ls-L/dev/hda1 BRW-RW ---- 1 root disk 3, 1 Jan 30 2003/dev/hda1 comparison, we can see that, the had type is B, that is, block device. The number of the had is 3, and the number of the had increases from 0. The root limit is RW-RW ----, that is, 660. Therefore: # mknod-M 660 hda B 3 0 # mknod-M 660 hda1 B 3 1 # mknod-M 660 hda2 B 3 2 # mknod-M 660 hda3 B 3 3

5. Add basic applications. In the future, system applications can be divided into three types: basic system tools, such as LS and ifconfig ...... Some service programs and management tools, such as web and telnet ...... Self-developed applications

Here, we will first add basic system tools. I have thought about downloading the code of these tools and cross-compiling them, but it is really troublesome to use busybox, which is simple and easy to use ...... Download busybox-1.00.tar.gz to the sysapps directory and decompress it: # tar zxvf busybox-1.00.tar.gz # cd busybox-1.00 // enter the configuration menu # Make target_arch = i386 cross = i386-linux-Prefix =$ {prjroot}/rootfs menuconfig // establish dependency # Make target_arch = i386 cross = i386-linux-Prefix =$ {prjroot}/rootfs Dep // compile # Make target_arch = i386 cross = i386-linux-Prefix =$ {prjroot}/rootfs // install # Make target_arch = i386 cross = i386-linux-Prefix =$ {prjroot}/rootfs install

# Cd $ {prjroot}/rootfs/bin # ls addgroup busybox chown delgroup echo kill ls MV Ping RM sleep adduser chgrp CP deluser grep ln mkdir netstat PS rmdir umount ash chmod date dmesg hostname Login mount pidof PWD sh VI suddenly has so many commands ...... Description of busybox configuration: A. If runtime SUID/SGID configuration via/etc/busybox is selected during compilation. every time the conf system runs a command, "using fallback SUID method" will appear to remove it, but I still created a file busybox for it in/etc. b. Do you want to build busybox with a cross compiler? (I386-linux-gcc) Cross Compiler prefix This specifies the name of the Cross Compiler (in fact, the command line at compile time has been specified ......) C. The ($ {prjroot}/rootfs) busybox installation prefix under the installation option specifies the installation directory of the compiled tool. D. is static or dynamic? That is, whether to select [] Build busybox as a static binary (no shared libs). The biggest benefit of dynamic compilation is that it saves valuable space. Generally, dynamic compilation is used, however, I had a problem with dynamic compilation before (in fact, it was a library problem, but it was not about busybox). Out of inertia, I chose static compilation and paid a lot of space for it. E. Separate other commands as needed.

6. When the system initialization file kernel is started, the last initialization action is to start the INIT program. Of course, most of the Linux release kits use init similar to System V init, you can download the System V init package online and download it for cross-compilation. In addition, I also found a very good article to explain how to write the initialization file, BSD-init, which will be attached later. However, for embedded systems, busybox init may be more appropriate. When you select a command in step 1, you should compile the init. # Cd $ {prjroot}/rootfs/etc # vi inittab my inittal file is as follows: # specify the initialization file: sysinit:/etc/init. d/RCS # open a serial port with a baud rate of 9600: respawn:/sbin/Getty 9600 ttys0 # shell: respawn:/bin/sh # restart action:: restart:/sbin/init # action when shutting down, detach all file systems: shutdown:/bin/umount-a-r

Save and exit;

Write the RCS Script: # mkdir $ {prjroot}/rootfs/etc/init. d # cd $ {prjroot}/rootfs/etc/init. d # vi RCS my script is as follows :#! /Bin/sh

# Set Path =/sbin:/bin export path

Syslogd-M 60 klogd

# Install/proc Mount-n-t proc NONE/proc

# Reinstall root file system by read/write mode (need:/etc/fstab) Mount-n-o remount, RW/

# Reinstall/proc Mount-n-o remount, RW-T proc NONE/proc

# Set lo IP address ifconfig lo 127.0.0.1

# Set eth0 IP address # Of course, this is just a matter of expediency. The last thing we do is to guide the network STARTUP script in this step, like RedHat, automatically read all specified configuration files to start ifconfig eth0 192.168.0.68 netmask 255.255.255.0

# Set route # Similarly, the script for starting a route should be run here to read the route configuration file route add default GW 192.168.0.1

# There is still a script for running the service program. Which one has a ready-made script? # In fact, the three steps of NIC/routing/service can be combined in one step. In this step, a loop is made to run all the feet in the specified startup directory, let's do this first, make sure the system can be started normally, and then write this script.

# Set hostname mylinux

Save and exit.

Compile the fstab file # vi fstab my fstab is simple:/dev/hda1/ext2 defaults 1 1 NONE/proc defaults 0 0

Chapter 5 enables mylinux to start the previous chapter. We copied the compiled kernels, applications, and configuration files to the subdirectories corresponding to the rootfs directory. In this step, these files are transplanted to the memory of the target machine. Here, I took another hard disk and hung it on my development machine for testing, because my book is used to write documents, and my PC is used as a development machine, no other machine ...... However, this chapter only describes a general process and does not affect your work on the target host. In the future, the hard disk serial numbers identified by the target machine will be hda, And I will directly mount it, it will be HDB, HDC ...... In this way, it is a bit difficult to install lilo (although it can also be implemented ). So I thought of another method: to mount the new hard disk to the primary of ide0, and after entering Linux, it will be considered as had; the original host's RedHat hard disk, I changed it from primary of ide0 to primary of ide1, because its lilo has been installed and basically does not affect the use of the system;

Partitioning and formatting the BIOS is changed to starting from the second hard disk. That is, starting from my original development machine, the new hard disk is recognized as had. # Fdisk/dev/hda delete all existing partitions with the D parameter and create a new partition with the N parameter, which is also formatted in/dev/hda1 # mkfs. ext2/dev/hda1

I installed bootloader on the X86 platform, so I used lilo directly. If you are on this platform, of course, there are many excellent bootloaders for you to choose from, you only need to view the corresponding instructions. Compile the Lilo configuration file. The configuration file name is target. Lilo. conf, which is placed in the $ {prjroot}/rootfs/etc directory. The content is as follows: boot =/dev/hda disk =/dev/hda BIOS = 0x80 image =/boot/bzImage-2.4.18-rmk5 label = linux root =/dev/hda1 append = "root =/dev/ hda1 "Read-Only

// Create a folder, prepare for Mount # mkdir/mnt/CF // mount the target hard disk # Mount-T ext2/dev/hdc1/mnt/CF back to rootfs # cd $ {prjroot }/ rootfs copies all files to the target hard disk # cp-R */mnt/CF

In this way, all our files are installed on the target hard disk. Of course, it cannot be booted because no bootloader is available. Run the following command: # lilo-r/mnt/CF-c etc/target. lilo. conf warning: lba32 addressing assumed added Linux *-R: Change the root target to/mnt/Cf. In this way, the configuration file is/mnt/CF/etc/target. lilo. conf, which is the previously created file. Of course, to complete this step, you need lilo22.3 or a later version. If your version is too old, such as the redhat9.0, the following information will appear: # lilo-r/mnt/CF-c etc/target. lilo. conf fatal: Open/boot. b: No such file or directory at this time, you need to upgrade your LILO or reinstall one.

Start the system # umount/mnt/CF # reboot

Change the BIOS to boot from ide0, that is, the target hard disk. If everything goes well, you will go smoothly into a system that belongs to you.

Let's look back at our workspace [root @ Skynet lib] # DF/dev/hda1 filesystem 1k-blocks used available use % mounted on/dev/hda1 3953036 1628 3750600 1%/mnt/CF

I spent kb in total. It seems that there is no way to put it in a floppy disk ^ o ^, but it is not my goal to keep it small.

[Root @ Skynet] # ls $ {prjroot} files in the bootloader build-tools debug Doc images kernel rootfs sysapps TMP tools directory are as planned at the beginning of this article.

[Root @ Skynet] # ls build-tools/buildroot buildroot-0.9.27.tar.tar contains the buildroot source code and compressed package, in fact, buildroot also includes the GNU other tool source code, compiled files and many other content, it is our most important folder, but it has not been of much use now. If you like it, you can delete it (not recommended ).

[Root @ Skynet] # ls images 2.4.18-rmk5 bzImage-2.4.18-rmk5 System-2.4.18-rmk5 vmlinux-2.4.18-rmk5 kernel image and profile etc. If you have modules, as there is a corresponding directory

[Root @ Skynet] # ls kernel/linux-2.4.27 linux-2.4.27.tar.bz2 kernel source code and compressed package

[Root @ Skynet] # ls rootfs/bin boot Dev etc home lib linuxrc proc root sbin tmp usr var make the root file system, top priority, pay attention to backup ......

[Root @ Skynet] # ls sysapps/busybox-1.00 busybox-1.00.tar.gz source package, maybe you still want to add/delete some commands ......

[Root @ Skynet] # ls tools bin i386-linux i386-linux-uclibc include info lib man this is also very important, we have made a good cross-development tool chain. If you want to continue developing programs, this directory is very important.

Other directories are empty.

Chapter 6 describes how to further debug mylinux. You can use commands such as chroot/mnt/CF/bin/sh on the development machine so that we can work on the target root file system.

Multiple users are supported because I have compiled a large number of commands of multiple users when compiling busybox. Now the key is to create a corresponding file for it; go to the original development machine and enter the rootfs directory, switch the root directory # chroot rootfs // bin/sh A and create the/etc/passwd file. The content of my file is as follows: Root: X: 0: 0: Root:/root: /bin/bash B. Create the/etc/group file. The content of my file is as follows: Root: X: 0: Bin: X: 1: SYS: X: 2: kmem: x: 3: TTY: X: 4: Tape: X: 5: daemon: X: 6: Disk: X: 7: C. Create a password for root. # passwd Root

Try addgroup/addusr ...... This heap command. Restart the instance and start it from the target hard disk. log on to the Console port 9600 and try again (because ttys0 is enabled in inittab. In the future, the target machine does not have a video card, need to go to the console or SSH for management) mylinux login: root password:

Busybox v1.00 (2004.10.10-+ 0000) built-in Shell (Ash) Enter 'help' for a list of built-in commands.

~ # Succeeded ......

The httpd option is added to the web server busybox, But I didn't select it during compilation, so I should install it myself. The software I use is thttpd-2.25b.tar.gz, Which is moved to the sysapps directory. [Root @ Skynet sysapps] # tar zxvf thttpd-2.25b.tar.gz [root @ Skynet sysapps] # cd thttpd-2.25b // configure [root @ Skynet thttpd-2.25b] # cc = i386-linux-gcc. /configure -- Host = $ target ...... I386-linux-gcc-static htpasswd. o-O htpasswd-lcrypt make [1]: Warning: clock skew detected. your build may be incomplete. make [1]: leaving directory '/home/Skynet/sysapps/thttpd-2.25b/extras' // copy to the root file directory [root @ Skynet thttpd-2.25b] # cp thttpd $ {prjroot}/rootfs/usr/sbin // trip processing [root @ Skynet thttpd-2.25b] # i386-linux-strip $ {prjroot}/rootfs/usr/sbin/thttpd

From: http://www.lslnet.com/linux/docs/linux-4529.htm