Introduction to mClinux features
1. The memory management unit MMU has been removed and has full network functionality.
2. Complete file system support, using the romfs file system as the root file system, requires less space than the normal ext2 file system.
3. The flat executable file format is used: the elf format has a large file header, and the flat file simplifies the file header and some segment information.
4. Small size and strong portability.
Figure 1 Schematic diagram of the development environment
Common mClinux-based embedding
Construction method of system development environment
In the development process of embedded systems, it is usually necessary to establish a cross-compilation environment. Figure 1 is a schematic diagram of a common embedded system development environment. The debugging based on Ethernet should generally connect the host and user boards to the LAN. Take the development environment of mClinux + S3C4510B as an example. The usual practice is to install the RedHat Linux operating system on the host and install the toolchain arm-elf-tools developed for ARM. In this way, the user program edited and compiled on the host machine can download the compiled executable file to the user board via Ethernet. There are mainly the following download methods.
FTP mode
First, you need to open a HyperTerminal, set the corresponding communication parameters, and then power on the system, you can see the startup information of mClinux in the HyperTerminal. This indicates that the IP address of the host is: 10.5.22.247, and the IP address of the user board is 10.5.22.8. Run the following command to configure the IP of the user board:
# ifconfig eth0 10.5.22.8
Eth0 refers to a network device. It should be noted that the IP address of the user board needs to be in the same network segment as the IP address of the host. Otherwise, it is difficult to access the host normally.
At this time, if you can ping the host, you can access the host's network resources through FTP.
Next select the directory where the user program is stored. It should be noted that if the user board is using the romfs file system, only a few directories can be accessed (eg tmp, var, etc.). After selecting the storage directory, you can access the host through FTP. Type the following command:
# cd /tmp
# ftp 10.5.22.247
Then enter the username and password to determine if you have access rights. After successful login, you need to determine the file transfer format. FTP can use binary and ascii to transfer files. The binary method is chosen here. Enter the following command to get the file:
# binary
# get filename
# bye
After executing #bye, you can exit FTP. At this point you can type the ls command to see if the file has been transferred to the selected directory. The next thing to do is to change the permissions of the file. If there is no executable permission, the program cannot be run in the user board.
# chmod 755 filename
The parameter "7" here means the right to read, write and execute; the "5" only means the right to have read and execute. After completing the above configuration, you can execute the user program with the following command:
# 。. /filename
NFS mode
Using NFS (NetWork File System) can make the development and debugging of embedded applications more convenient, and share files between different machines and different operating systems. Therefore, NFS has been widely used in embedded development. application. At present, it is relatively difficult to configure NFS under the mClinux-2.4-x version. The following is a detailed description of the configuration problem.
Server (Sever) settings
First you need to set up the /etc/exports file under Linux, which is the main configuration document for NFS. In the shell terminal under Linux, do the following:
# vim /etc/exports
Modify this default empty file to have only one line below:
/home/tmp *(rw,no_root_ squash)
This means that in any case, the client can access the /home/tmp directory on the server side.
Next, you need to open the following two processes on the server side:
1. Turn on the NFS service
# /etc/rc.d/init.d/nfs start
Start the NFS service: [ OK ]
StarTIng NFS quotas: [ OK ]
Start the NFS daemon: [ OK ]
Start NFS mounted : [ OK ]
2. Open the portmap service
# /etc/rc.d/init.d/portmap start
After the configuration is complete, you can use the following methods to test whether the NFS configuration is successful (note that the firewall should be shut down under Linux): mount yourself on the host machine to see if it is successful. For example, execute under the host/directory:
Mount 10.5.22.247: /root/ /home/zhang/mount
Then go to the /home/zhang/mount/ directory to see if you can list all the files and directories in the /root/ directory. If yes, the configuration of NFS on the server is successful.
Client (Client) settings
Compared with the Sever end setting, the client side uses mClinux, which is relatively complicated to set up. It needs to recompile the mClinux kernel and configure it. You need to set Customize Kernel SetTIngs and Customize Vender/User SeTIngs (NEW).
1. Configure Customize Kernel SetTIngs
[ * ] Customize Kernel Settings
Go to the settings of File systems, you can see Network file systems---, select NFS File system support.
2. Set Customize Vender/User Setings (NEW)
[ * ] Customize Vender/User Setings(NEW)
In the Customize Vender/User Setings project, after selecting Network Applications, you need the portmap service, [*] portmap. Then select the mount and umount services to make mClinux support mount and umount instructions. The mClinux-2.4-x kernel does not support NFS mount enough. This makes it difficult to add NFS service to mClinux, and the NTFS file system is rewritten in the newer mClinux version mClinux-2.6-x. In the BusyBox, select mount and umount and mount NFS support, so that the client configuration is complete. Finally recompile the kernel, the instructions are as follows:
# make menuconfig ------------- Kernel
# make dep ------------- Looking for dependencies
# make clean------------Clear files generated when the kernel was previously constructed
# make lib_only-----------This command compiles the library file
# make user_only----------Compile user application files
# make romfs ----------Generate romfs file system
# make image----------Generate romfs.o file
# make
After recompiling, it will be there. . . The image.rom file is generated in the /image/ directory. It is the compressed image of the kernel in the rom, and it can be written to the Flash of the user board. After the user board restarts, the new kernel has started working, and then NFS mount can be done in the terminal (for example, in minicom). Enter the following command:
#mount -t nfs 10.5.22.247:/home/tmp /var/tmp /nfsmount -o nolock
# mount
After executing the two instructions, you will see the following information in minicom under Linux:
Rootfs on / type rootfs (rw)
/dev/rom0 on / type rootfs (ro)
/proc on/proc type proc (rw)
/dev/ram0 on/var type ext2 (rw)
/dev/ram1 on /disk type ext2 (rw)
10.5.22.247: /home/tmp on /var/tmp type nfs (rw,v3,rsize=8192,hard, udp,nolock,addr=10.5.22.2)
This will mount the host's /home/tmp directory to the /var/tmp directory on the user board.
Conclusion
By comparing the above two methods, it can be seen that the NFS approach has obvious advantages in terms of development efficiency. After all, user-developed programs often fail to debug at once, and NFS makes it possible for multiple people to develop a program at the same time. In fact, in addition to the two methods mentioned in the article, there are other embedded development tools in the Ethernet environment, such as telnet, etc., limited to the length, no longer detailed.
Common file system under embedded linux
• RomFS: Read-only file system, can be placed in the ROM space, or in the system's RAM, commonly used in embedded Linux
Root file system
• RamFS: a memory file system formed using the VFS's own structure, using the system's RAM space
• JFFS/JFFS2: Log File System for Flash
• Yaffs: Designed specifically for Nand Flash
• proc: Provides a mechanism for kernel and kernel modules to send information to processes to view information loaded by system modules
• devFS: device file system
Ext2fs on Linux
• Support 4 TB storage, file name up to 1012 characters
• Selectable logic blocks
• Fast symbolic links
• Ext2 is not suitable for flash devices
• Designed for block devices like IDE devices, the logical block size must be 512 byte, 1 KB, 2 KB, etc.
• Good management of sector-based erase/write operations is not provided
• If a single byte is erased in one sector, the entire sector must be copied to RAM, then erased, then rewritten
• Ext2fs does not prevent crashes in the event of a power failure
• File system does not support wear leveling, reducing flash life
Advantages and disadvantages of the jffs/jffs2 file system
• Log file system
• Provides better crash, power failure security
• jffs2 supports uniform wear on flash
• Performing a flash erase/write/read operation at the sector level is better than the Ext2 file system
• JFFS2 will slow down significantly when the file system is nearly full - garbage collection
Advantages of Nand's yaffs file system
• Log file system designed specifically for Nand flash
• jffs/jffs2 is not suitable for large-capacity Nand flash
• jffs logs are built into RAM via jffs_node, taking up RAM space: about 128MB of Nand requires about 4MB of space to maintain nodes
• Scan log nodes need to be started when starting, not suitable for large-capacity Nand flash
• FAT system has no logs
Compile yaffs file system
• What is the latest patch upgrade for mtd?
• Interface update, suitable for yaffs
• Not compatible with the original mtd driver, need to be rewritten
• If using the old mtd driver you need to define MTD_OLD = -DCONFIG_YAFFS_USE_OLD_MTD in the Makefile
• Reference documentation: yaffs-rootfs-howto
• The latest version of the yaffs website: http://
Using the yaffs file system
• You can see information about the yaffs system via the cat /proc/yaffs command.
• mount -t yaffs /dev/mtdblock/0 /mnt/yaffs
About the Linux file system
JFFS Full name: The Journalling Flash File System was originally developed by Axis Communications of Sweden and improved by David Woodhouse of Red Hat. Appears as an actual file system for raw flash chips for micro-embedded devices. The JFFS file system is log structured, which means it is basically a long column of nodes. Each node contains some information about the file—probably the name of the file, maybe some data. Compared to Ext2 fs, JFFS is becoming more and more popular in diskless embedded devices because of these advantages:
1 JFFS Performing a flash erase/write/read operation at the sector level is better than an Ext2 file system.
2 JFFS provides better crash/power-down security than Ext2. When a small amount of data needs to be changed, the Ext2 file system copies the entire sector into memory (DRAM), merges the new data in memory, and writes back the entire sector. This means that in order to change a single word, a read/erase/write routine must be performed on the entire sector (64 KB) - this is very inefficient. If the luck is poor, when a data failure or other accident occurs while merging data in DRAM, the entire data set will be lost because the flash sector is erased after the data is read into DRAM. JFFS attaches files instead of rewriting entire sectors and has the ability to crash/power down security.
3 This is probably the most important point: JFFS is specifically created for embedded devices like flash chips, so its entire design provides better flash management.
To build a JFFS file system, you must first have a hardware device FLASH and an operating system that supports the JFFS file system.
Abstract: This paper mainly analyzes the jffs file system mechanism of uclinux 2.4 kernel. I hope to be able to help the vast number of engineers based on uclinux development products.
Keywords: uclinux vfs jffs
Affirmation: This document is released in accordance with the spirit of free software open source, and anyone can get, use and re-publish it for free, but you have no restrictions on others to re-publish your content. The purpose of this article is to make it useful to the reader, but without any warranty or even an implied warranty for a specific purpose. See the GNU General Public License (GPL) and the GNU Free Documentation Agreement (GFDL) for more details.
You should have received a copy of the GNU General Public License (GPL) with the documentation. If not, write to:
The Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA02139, USA
Welcome to point out the errors and questions in the documentation.
First, the special nature of flash reading and writing
For embedded systems, flash is a very common device, and most embedded systems build file systems on top of flash. Due to the special nature of flash operations, file systems and ordinary disks on flash are made. The file system on the page is very different. The special features of the flash operation include:
(1) A single byte cannot be erased. The smallest erase unit is a block, sometimes called a sector. A typical block size is 64k. Different flashes will be different, refer to the specifications of the flash chip.
(2) The write operation can only operate on a location that is originally empty (that is, the content of the address is all f). If the location is not empty, the write operation does not work, that is, if you want to rewrite an existing content. The space can only be read out of the sector to ram, rewritten in the ram, and then write the entire sector.
Because of these special writes, creating files on devices like flash has its own unique characteristics. Let's take jffs as an example for analysis.
Second, the introduction of jffs architecture
1, storage structure
In jffs, all files and directories are treated the same, using a jffs_raw_inode
The entire flash is composed of one raw inode array, one directory has only one raw inode, and the file is composed of one or more raw inodes.
2, the file composition
When the file system is mounted on the flash device, the flash is scanned to create a jffs_file structure and a node list according to all the raw inodes belonging to a file on the flash.
The figure below shows the composition of a file
A file is composed of several jffs_nodes. Each jffs_node is created according to jffs_raw_inode on flash. jffs_file mainly maintains two linked lists.
Version linked list: mainly describes the creation of the node sooner or later, that is, version_head points to the oldest node, which means that the most old node to be recycled during garbage collection is the oldest node.
Area linked list: This linked list is mainly created for reading and writing files. The file data area represented by the node pointed to by version_head is 0~~~n-1, and the nodes in turn are n~~~m-1 m~~~~o -1 ……. Where n "M" = "" p = "" / "
3, operation
The read operation of the file should be relatively simple, but the write operation, including changing the file name, etc., is to cause the birth of a new jffs_node, and at the same time to write a matching raw inode to the flash, such an operation may lead to the front The data on a jffs_node is completely invalid, resulting in the space of the raw inode corresponding to the flash becoming dirty.
The following example may be more clear.
The range list of a file is composed of the above three jffs_node, when we do the following write operation
Lseek( fd, 10, SEEK_SET );
Write( fd, buf,40 );
The first and last nodes are truncated, the second node is completely replaced by new data, the node will be taken from the list, and the flash space becomes dirty. If you do the following write operation
Lseek( fd, 23, SEEK_SET );
Write( fd, buf,5 );
At this point, the second node is split into two nodes, and a new node is created, and the elements of the range list become five.
Energy 5000 Puffs,Rechargeable Vape 5000 Puffs,Energy Drink Disposable Vape,Energy 5000Puffs Disposable Vape
Nanning Nuoxin Technology Co., LTD , https://www.nx-vapes.com