Android USB client mass-storage cannot be automatically mounted to the host (1)

Test Platform: nvidia arm architecture

Operating System: andorid (NVIDIA modified)

 

Recently, I am engaged in Android USB client and found that when the client is connected to the client and host of the Android system respectively, ADB can be used in the two functions of Android USB client, mass-storage cannot be used, that is, machines with Android systems cannot mount their own sdhccards and their memory cards to the host and display them.

Enter LS-L/dev/SD *

When a node named/dev/SDB is displayed on the terminal, the system tries to mount and prompts that the unknown file system cannot be mounted.

 

Okay, check the init. RC on the Android system and find that the Mount mode is vold.

 

View the original vold code, find that you need to read vold. conf, and check UMS

========================================================

We can roughly guess that the problem may be caused by the Android system:

1. The configuration of rootfs/etc/vold. conf may be faulty.

2. vold programs may be faulty

3. Problems with Linux driver/USB/gadget/f_mass_storage.c

4. ums functions may be faulty

========================================================

 

If you have guessed the problem, the next step is to confirm it step by step.

1. First check the/etc/vold. conf file. The code is in/out/target/product/XX/system/etc/vold. conf.

 

 

Volume_sdcard {<br/> media_path/devices/platform/tegra-sdhci.3/mmc_host/mmc0/mmc0: 0001/block/mmcblk0/mmcblk0p4 <br/> media_type MMC <br/> mount_point/sdcard <br/>}< br/> ums path unavailable. Personal Experience: generally, you can find a node containing the "UDC" character under/sys/devices/platform/<br/> and enter its subdirectory. The lun0 node is displayed. 

Go to/sys/devices/Platform

At this time, there will be two phenomena: 1, there is a corresponding node; 2, there is no

1. If yes, check whether the node corresponds to your f_mass_storage driver. That is to say, this node is created by your mass_storage driver. If not, create it.

2. If not, create it in f_mass_storage.c.

 

My case is first, there is a node named shdc-udc.0/lun0 under the directory, but it does not correspond to the mass-storage driver in my g_android, so I have to recreate one.

There will be a series of device_register actions in/ARCH/ARM/Mach-xxx/nvodm_board.c provided by NVIDIA

Add two sentences to create a node under/sys/devices/platform.

Static struct platform_device fsg_platform_device = <br/>{< br/>. name = "usb_mass_storage", <br/>. id =-1, <br/>}; <br/> static void _ init tegra_machine_init (void) <br/>{< br/> .... <br/> (void) platform_device_register (& fsg_platform_device); <br/> .... <br/>}< br/> Add the two okay statements. 

We will find that the/sys/devices/platform/usb_mass_storage/lun0 directory is generated

These actions correspond to the content of the mass-storage driver in your Linux driver.

The last step is to add the newly created UMS (which starts the USB Mass-storage function) path to your vold. conf file.

Volume_sdcard {<br/> media_path/devices/platform/tegra-sdhci.3/mmc_host/mmc0/mmc0: 0001/block/mmcblk0/mmcblk0p4 <br/> media_type MMC <br/> mount_point/sdcard <br/> ums_path/devices/platform/usb_mass_storage/lun0 <br/> // Add <br/>} 

======================================

 

Open the machine, enter the system, start it, and find that it still does not work. In the ADB terminal, enter sdutil ums enabel to start ums. In fact, I have started ums after the machine is started.

Logcat shows that ums has crashed a lot of stack problems.

The estimation is related to memory allocation or pointer.

It is estimated that there is a problem with the vold code.

Go to the android source code directory/system/CORE/vold

Open all the code in the directory, add the print statement, and trace the code.

When you ums enable

1. Enter pai_dispatch.c to execute the do_set_ums_enable function.

Static int do_set_ums_enable (char * cmd) <br/>{< br/>... <br/> If (! Strcmp (CMD, vold_1__enable_ums) <br/> return volmgr_enable_ums (true); <br/> return volmgr_enable_ums (false); <br/>} 

It calls volmgr_enable_ums (bool enable) in the volmgr. c file)

 

Int volmgr_enable_ums (bool enable) <br/>{< br/>... <br/> volume_t * V = vol_root // The linked list stores information about each storage device, such as state. ums_path and mount_point are from/etc/vold. conf <br/> while (v) <br/>{< br/> If (V-> ums_path) <br/> If (enable) {<br/>... <br/> volmgr_shutdown_volume (v, _ cb_volstopped_for_ums_enable_false); // if the program executes this sentence, it will be suspended. <br/>... <br/>}< br/>} 

First, let's take a look at how the program reads and stores the/etc/vold. conf configuration information.

These functions are volmgr_readconfig, volmgr_config_volume, and so on. I will not elaborate on them here, but I will give a rough introduction,

First, a large linked list will be created to compare volume_xx in vold. conf to determine the number of members, such as volum_sdcard1 volum_sdcard2.

Indicates two members.

A linked list is created in each member to store ums_path mount_point.

Finally, these things are organized into a linked list v.

========================================================== =

Continue with the above Code

Tracking volmgr_shutdown_volume () ---> volmgr_stop_volume () ---> _ cb_volstopped_for_ums_enable ()

Staitc void _ cb_volstopped_for_ums_enable (volume_t * V, void * Arg) <br/>{< br/> char * devdir_path <br/>... <br/> devdir_path = blkdev_get_devpath (V-> Dev-> disk); // The disk is suspended. <br/>... <br/>} 

Continue to blkdev. C.

Char * blkdev_get_devpath (blkdev_t * BLK) <br/>{< br/> .... <br/> char * dp = malloc (256); <br/> sprintf (DP, "% S/vold/% d: % d", BLK-> major, BLK-> minor); // <br/>}< br/> after debugging, it is found that BLK is a null pointer. <Br/> check whether the function _ cb_volstopped_for_ums_enable is called. <br/> V-> Dev-> disk NULL pointer is found. <br/> 

Continue to return to the trail and find that V-> Dev-> disk is always empty

No wonder, Ma hasn't done any exception.

Elsewhere, we found that V-> Dev and V-> Dev-> disk are of the same type. In some cases, V-> Dev-> major is used, in some cases, use V-> Dev-> disk-> Major

I can't see V-> Dev-> disk initialization. It's a tragedy...

So I tried to input V-> Dev as a parameter, instead of V-> Dev-> disk.

You can find that the device numbers in/dev/vold/are the same as those in V-> Dev-> Major: V-> Dev-> minor.

When the machine is started, the USB client cable is inserted. The host can automatically mount mass-storage.

 

 

Oh, yeah success!

========================================================== =

I don't know why V-> Dev-> disk is empty. Reading .. It is estimated that it can be cleared in the past few days.

I am not writing well, and I am not very detailed. I just have some debugging views and experiences and hope to help myself and everyone. Thank you.