Question

I am trying to change some sys values but I don’t seem to be having much success.

In my case I am trying to change values of files in the folder

“/sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0”

e.g. the file bInterfaceClass which currently has value 09

My tries:
(In shell, as root)

chmod 777 bInterfaceClass
echo 07 >> bInterfaceClass

I didn’t receive an error but when looking up the value

cat bInterfaceClass

It is still 09

Now looking up this file in Root Explorer, I can see that the last modification date of the file has changed, so my guess: something resets the value of such a sys file as soon as it changes. Can anyone shine some more light on this issue? How can I change the value?

Many thanks!

Answer 1

THIS IS HACKERY, you have been warned! 🙂

Instructions here are not generally found on the Internet, but can be great for testing interfaces and capabilities without significantly changing system code. THESE CAN BE USED TO ADDRESS ANYTHING WHICH IS BEING OVERWRITTEN without warning or cause. Using these, you can sometimes see based off of using dmesg ps and logcatwhat exactly is causing you so many problems, while testing a solution.

The is likely in the Kernel with things like this getting written over, maybe a system service or script internally. A quality perm fix would be in the /drivers folder of the kernel. I can only assume this is on a Beagle or Panda Board, maybe a Moto device. If it is Beagle or Panda, this will be easier (yay Linaro, AOSP support, big community!).

If this is something that does not need to Hold USB open, but merely have the desired number present you can try below:

Open up your boot.img and open he Root Disk/Ramdisk and finally one of your init..rc files. You can use this tool: https://github.com/dsixda/Android-Kitchen – requires Linux and a few packages, great tool!

If you are lucky, this will appear as part of the init.rc files (which you can check in-system) or in the /system/etc folder as one of the class main or core scripts.

You can declare the value you want if you look for it in the:

on init

Section of the init.platform.rc and look where

/sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0

is initialized,

then in the .rc file

chmod 777 /sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0/bInterfaceClass
write /sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0/bInterfaceClass 07

Then if doing that and initializing it as such does not hold by that alone, open the normal init.rc and add

on nonencrypted 
write /sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0/bInterfaceClass 07

and also

on property:vold.decrypt=trigger_shutdown_framework
write /sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0/bInterfaceClass 07

as those two properties or functions will cover you at the end of the inits to set that property again (you already gave it 777 privilages earlier as part of the on init)

If you want something you can play with without flashing new Boot.img files:

Declare your script in the system/bin as a service in the init.platform.rc (don’t worry most every .rc file is linked and includes each other) using:

service usbchanger /system/bin/sh /system/bin/usbchanger.sh
      class late_start
      user root   
      disabled

Then in the normal init.rc

on nonencrypted 
     start usbchanger

on property:vold.decrypt=trigger_shutdown_framework
     start usbchanger

Your script will then become a constantly running service (you can do the same with a binary). This is totally a desired trait when doing debugging and testing new features/fixes because you can change the values and running commands while the system is open and does not require you to re-flash after every change. However, for production you should not have this going. Its bad code to do that generally when really, it should be in the kernel or core.