USB flash disk and mobile hard disk mounting series problems

Solutions to the series of problems related to USB flash drives and mobile hard drives-general Linux technology-Linux technology and application information. For details, refer to the following section. By tmsonhust

The USB flash drive has been successfully mounted to the Board a few days ago. Today, let's test the mobile hard drive.

I first inserted the mobile hard disk on my computer and tried to check the size and partition of the hard disk, the file system format and the VID and PID of the hard disk. Then turn on the Board Sub-power, linux boot, manually loaded with the gpio driver, the Board can support USB storage devices, because I have compiled the support for USB storage into the kernel, even loading ohci-hcd.ko before can now save. I connected a wire of the mobile hard disk to a USB port. The Super Terminal did not respond. I pulled it and plugged it in again. It was still the same. The mobile hard disk was a little responsive and lit up, but it cannot change the fact that it is not identified, and there is no sign of rotation at all. I took down the hard disk and looked at it on the left and right. It doesn't look like an unknown manufacturer. Why can't I identify it? Is it necessary to modify the usb product registration form of unusual_devs.h? I don't need to open this file first, as a result, I am dumpfounded. I know how to fill in so much information, and the information in MS is all-encompassing. Some vendors I know are listed. It seems that this road is a bit unfeasible and should not be included. I am optimistic about the strength of this mobile hard drive manufacturer. Suddenly I don't know how to get inspiration. I plugged in another line of the mobile hard drive. Oh, my God, I was so moved to cry that the Super Terminal immediately responded, A line of Hard Disk identification information is printed, which indicates that the driver is working normally and there is no conjecture about the information in the product registration form. Although it was identified in this way, it was still a bit of atmosphere. It was actually a problem, so I checked the role of the two lines: one is a data line, one is the auxiliary power supply line. Obviously, when it is inserted on our board, the power supply of the single-use data line is insufficient. Obviously, it cannot work, and it must be plugged into another line for auxiliary power supply.

Now, the problem of identification is solved, and mounting is required. The mount method is very simple. Just mount it. Combined with the information printed during recognition, I used the following command: mount-t ntfs/dev/scsi/host0/bus0/target0/lun0/part1/mnt/usb. It seems to be a great deal. The problem is that the device file cannot be found, I was wondering how the device files could not be found in this directory. I suddenly thought that the Linux kernel does not support ntfs file format by default. I opened it. the config file looks at it. Sure enough, # CONFIG_NTFS_FS is not set, change it to CONFIG_NTFS_FS = y, re-compile the kernel, mount it, and OK. You can see the information on the hard disk, but there is still a problem. Because Chinese characters are not supported, many files named after Chinese characters on the hard disk cannot be displayed, I remember this problem also occurred when identifying the mobile hard disk on my computer. The solution is very simple. You only need to add the parameter-o iocharset = cp936 to the mount. However, today is like a ghost, and the parameter is incorrect. cp936 and iocharset cp936 cannot be identified. The specific error message is as follows:

Unable to load NLS Charset cp936
FAT: IO charset cp936 not found

With the ntfs experience, combined with some information searched on the Internet, it is assumed that there may be a corresponding option in the kernel that is used to support cp936 and open it. as expected, the config file says: # CONFIG_NLS_CODEPAGE_936 is not set, change it to # CONFIG_NLS_CODEPAGE_936 = y, re-compile the kernel, and mount the file with the-o parameter will not report an error. In this way, the problem of unsupported Chinese characters is also solved.

So far, both the USB flash drive and the mobile hard drive can be mounted to the board. However, it is not perfect that there is a long path for the device files during each mounting process, which is very troublesome, mount/dev/sda, And the strange thing is that sda and sdb files cannot be found in the dev directory, I thought it was haisi who modified the kernel and changed the code that generated the device file. Later, by comparing haisi's code with the standard code 2.6, it confirmed the error of my idea, the representation of/dev/scsi/host0/bus0/target0/lun0 starts from 2.6 and is a unified representation, the top relationship of usb mounting can be displayed in a hierarchical manner. What should we do now, Baidu + google? There is information on the Internet that users can choose to create device files when creating file systems, so there are no sda and sdb device nodes in our/dev directory. It is estimated that the file system is not included in order to keep it simple. How can we add it? It's hard to redo the file system, obviously, this is obviously a bit of a cool-killing tool. One command mknod can be done. The same is true for setting up an sda node mknod sda 8 0 1 and creating sdb and sda1 nodes, after the setup, I immediately went to/dev and looked at it. There was an extra sda and then mounted/dev/sda. There was no error, which means the mounting was successful, in order not to knock on the mknod command every time, I wrote them into an initialization script/etc/init. d/rcS, so that these device nodes are automatically created every time the system starts. Today, I found a problem when searching materials on the Internet. For embedded development boards, it seems that everyone is using the device files in this long path to mount the device, I think the reason for this is that the file system does not set up the sda and sdb device nodes, in this way, even if the USB driver identifies your USB flash drive as sda or sdb in ascending order, it cannot find the corresponding sda and sdb device files.

A little bit of discovery in the debugging process is so exciting and I feel so good that I can record the debugging process today.