Related
Hi i was just looking for some quick clarification if anyone is willing.
Boot into Clockwork Recovery. -DONE
Navigate to "mounts and storage". -DONE
Select "mount USB storage". -DONE
Copy /usr/src/tegratab/boot-custom-kernel.zip to the mounted filesystem. -HOW?
I tried adb push /usr/src/tegratab/boot-custom-kernel.zip /sdcard I dont believe it worked since nothing actually happened. I didnt even get my command line back. Im just waiting though, its been about 10 minutes though, I really dont think anything is happening. Actually it just finished, and now my tab is locked up. After I fix this I hope someone will be able to tell me how to properly install this. Also when I go into the android system then turn on usb storage device and try and drag and drop it says its going to take 3 hours?
I cant seem to figure out how to copy my file to "the mounted filesystem" I dont get a filesystem that I can drag and drop my zip into, I dont see or know of a command to do it through the terminal. So how can I accomplish this?
Thanks!
DKS1282 said:
Hi i was just looking for some quick clarification if anyone is willing.
Boot into Clockwork Recovery. -DONE
Navigate to "mounts and storage". -DONE
Select "mount USB storage". -DONE
Copy /usr/src/tegratab/boot-custom-kernel.zip to the mounted filesystem. -HOW?
Click to expand...
Click to collapse
Need details--
Whose kernel is this? Is it for the gTab? Where was it compiled from (source)? Is it stable? Has it been tested? Why is the guy telling you to copy the zip file onto the internal SD via ClockworkMod when you can do it more easily by other means? Can I have a look at the contents of the zip file?
really? in order to install it you have to know all that? The zip file is over 1.5 gigs.. How do you propose I get it to you?
DKS1282 said:
really? in order to install it you have to know all that? The zip file is over 1.5 gigs.. How do you propose I get it to you?
Click to expand...
Click to collapse
This kernel better be able to sing and dance for you if it's that big. What the hell is in there? I want to see what's in there now.
DKS1282 said:
really? in order to install it you have to know all that? The zip file is over 1.5 gigs.. How do you propose I get it to you?
Click to expand...
Click to collapse
This is why I asked you for the details. A compiled kernel for the gTab, along with the most useful modules, plus the installer program, is about 3MB, max.
The complete Linux kernel source, uncompressed, is around 450MB. Compressed, it is ~100MB. A compressed 1.5GB file would therefore contain a heck of a lot more than just the kernel sources. What were you expecting to happen here? Ram a boat-load of source into the tablet and it should automatically compile and install everything for you?
Actually no... I followed a link and followed directions and I actually thought I was doing well till I saw the size of the file... Im actually going to work on recompiling the kernel again. It was a version of pershoots but I think the tutorial I was working off of is incorrect as are most of them on the net. Im learning but sadly not at the pace I would like, Im new to linux and android. Thank you all for the help so far. I'll post what ive done here in a lil bit and I was wondering if I would be able to get advice on how to install it... Ill even link the tutorial I follow. Here it is http://forum.xda-developers.com/showthread.php?t=916198
Now that Ive gone over it again its an issue in the zipping... For some reason my 28.7M file zips to 1.6gb WTF? Here is the command I used
From inside the file where the contents is to be zipped zip -r /usr/src/tegratab/boot-custom-kernel *
Yes evey time I zip it it comes out to 1.6 gigs. The system file is is pretty small but after its been ziped it actually takes most of the 1.6gb... Could I possible send the meta file, kernel file, and system file? Or maybe someone could tell me how to correctly do this? Ive followed the directions in that link and thought I was getting a legit output but I guess that im not even close.
GOOD NEWS EVERYBODY! I can save you 15% on car insurance...
Actually I was able to figure out what has happened... There were some symlinks that didnt get removed so it grabbed everything in that link and zipped it as well... after I fixed the issue it zipped correctly and I was even able to get it to install... Sadly the prolific driver for the 2303 is still not included even though it shows on the kernel menuconfig as being included, I guess Im going to try again and make it modular and see if I can get the driver file to install that way.. Ill let you know how it goes and also upload and link it if I can get it to work in case someone else wants to grab it and build off it. Im also planning on helping out the forums a little bit...
Thank you again.
DKS1282 said:
Sadly the prolific driver for the 2303 is still not included even though it shows on the kernel menuconfig as being included...
Click to expand...
Click to collapse
Attach the .config (kernel configuration file) so I can look at it.
Does running dmesg on the new kernel show the driver loading/initializing?
Are the /dev/ttyUSB* device files present? Are the permissions for those serial devices correct? I'm not sure what they ought to be, but try making them read+write for all--at least while you are testing things: chmod 666 /dev/ttyUSB* as root.
Here is actually the zipped kernel file. When it compiles it does show the drivers being installed, I just cant get the device to recognize the Prolific cable. Ive tried including them, Ive tried modular, im not sure how to make it work, or if there is something im missing entirely. Thanks again.
http://www.mediafire.com/?nil9bh3spu6sp78
DKS1282 said:
Here is actually the zipped kernel file.
Click to expand...
Click to collapse
The binary is no use to me--I don't have your hardware. The .config file is what I need.
When it compiles it does show the drivers being installed, I just cant get the device to recognize the Prolific cable.
Click to expand...
Click to collapse
The real test is the dmesg output, not whether the driver is being compiled in.
However, I think your problem is that you've compiled the wrong driver. What you need is the driver for "Prolific PL-2301/2302 based cables" which is included by enabling:
config USB_NET_PLUSB
which depends on
config USB_USBNET and
config EXPERIMENTAL
The module will be called plusb.ko, I think.
Sorry for being really uneducated on this. But I can not find any of thoes that you listed in the kernel. Also I cant even find the config file. I know where im targeting it from command line but if I try to move it it says file not found, and if I try and go there visually the file isnt there.
Id love to be able to upload what you want to see, and Id love to be able to add in the items you just suggested. But alas. neither seems possible.
Its honestly odd to me.. Ive been reading a couple different posts on the net that say you install this driver for the Prolific 2303. But not the PL2303.... So why is it included when it doesn't do what its supposed to do? Ive tried a lot of different methods and none of them work. It sucks cause I see people using it. Maybe Its not the kernel and its the android OS? I really have 0 clue at this point and about to just give my resignation at my employment.
The .config file will be present in the kernel's main directory (/usr/src/tegratab/gtab-2632/.config) if you have already built a kernel.
It looks like there are 2 drivers for Prolific hardware in the source tree. One is for host-to-host cables with Prolific chips (which is not enabled by default, and which, I think, is what you want), and the other for a Prolific USB serial port adapter (which is already enabled by default).
To build the module for the first, do a make menuconfig, then select:
Device Drivers > Network device support > USB Network Adapters > Prolific PL-2301/2302 based cables
However, you should verify what you have before you build the module. Do a "lsusb" then check the USB device IDs against the USB ID database in /var/lib/usbutils/usb.ids on a regular Linux machine.
Hints:
0. See pershoot's hints to another user here and further along in the same thread.
1. Make sure that you have downloaded the correct pershoot kernel: froyo or gingerbread.
2. You don't need to include all the modules in your kernel zip file. Just overwrite the kernel proper (zImage), the wireless driver (bcm4329.ko) and then add only the prolific driver module. Otherwise you're just wasting space on the /system partition.
3. Sign the zip file after creating it.
Thank you so much for the attempt.
But my .config file is not located where you have directed me. I checked there before, I could send you a screen shot showing you this.
Thank you for showing me where the driver for the cables where, I would not have checked network adapters looking for USB.... Alas, this has not solved my problem. The cable is still undetected by the OS. Although almost EVERY other usb is detected.
Im really not sure why this wont work. It installs 100% fine I have 0 issues on this, but the Prolific 2303 usb to serial cable will not show up in log cat or anything.. Although when i adb shell and do lsusb I see it and it has a device ID and everything.
Thank you again for the help..
DKS1282 said:
But my .config file is not located where you have directed me.
Click to expand...
Click to collapse
It is created in the kernel's top-level directory (ie. the same directory as the file REPORTING-BUGS) after you do "make menuconfig".
If you still can't find it, do,
find /some/path/ -name .config
after you've finished "make menuconfig". Replace /some/path/ with your kernel source dir (or / to search everything that is mounted).
Alas, this has not solved my problem. The cable is still undetected by the OS. Although almost EVERY other usb is detected.
Click to expand...
Click to collapse
If the driver is built as a module then the kernel will recognize it only after you have loaded the module. Load the correct module first, either plusb.ko or pl2303.ko, depending on your hardware, then check for detection/initialization messages from the module by issuing a "dmesg" command immediately after the "insmod /some/path/driver.ko" command.
Im really not sure why this wont work. It installs 100% fine I have 0 issues on this, but the Prolific 2303 usb to serial cable will not show up in log cat or anything.. Although when i adb shell and do lsusb I see it and it has a device ID and everything.
Click to expand...
Click to collapse
Still lacking details:
1. Did you download the correct kernel--Froyo/GB?
2. Are you sure you're running the new kernel after flashing the zip file?
3. Did you insmod the correct module?
4. What is the USB device ID shown?
5. Did you run dmesg--not logcat--after you insmod'ed the correct module? Can I see that dmesg output?
I can not find a .config file anywhere on this computer. it just does not exist.
Yes I am using a gingerbread version.
Insmod does not install anything for me. Although I installed the modules before even packaging the kernel. Ive verified this by checking in the the correct driver files once installed.
I dont remember the device Id exactly but its something similar to 067b:2303
I didnt run dmesg, honestly, this is way beyond me. I have absolutely no clue what im doing at all... I wasnt even hired for this job.. I was supposed to create an app that will use this specific cable on this specific device, although they did not give me the device able to use the cable... So now I have to figure out how to do this, and im just going to resign and tell them im not a hacker im a developer. Thank you very much for your effort but I am turning in my resignation here now at the end of the day. Thank you again and I'll give you thanks.
You had asked a while back if dev/ttyUSBx has shown, and I did get that to show last night. its dev/ttyUSB0 Ive tried to use a usb to serial api but the app couldn't open the serial port... Im guessing because android does not support that (since they dont really support anything) I personally dont even understand why these things sell... Its a giant useless phone that can not make phone calls. Im in the wrong business I need to sell useless products to consumers.
DKS1282 said:
I can not find a .config file anywhere on this computer. it just does not exist.
Click to expand...
Click to collapse
You a) didn't search correctly, b) haven't built the kernel yet, or, c) done a "make mrproper" and cleaned up.
Yes I am using a gingerbread version.
Click to expand...
Click to collapse
Which ROM?
I dont remember the device Id exactly but its something similar to 067b:2303
Click to expand...
Click to collapse
You cannot be vague about this. Run a Terminal emulator on the gTablet (download one from Market if needed), then type in the command in bold:
Code:
$ [B]lsusb[/B]
Send me the output of lsusb.
I didnt run dmesg,...Thank you very much for your effort but I am turning in my resignation here now at the end of the day.
Click to expand...
Click to collapse
Steady on, mate--we'll get you sorted: Just send me the lsusb output and I'll build a kernel for you--if the current kernel sources include the driver code.
You had asked a while back if dev/ttyUSBx has shown, and I did get that to show last night. its dev/ttyUSB0 Ive tried to use a usb to serial api but the app couldn't open the serial port...
Click to expand...
Click to collapse
Does the app have permissions to read/write the device? Use the chmod command I gave in an earlier post to give permissions.
Next: once the actual hardware is connected to the Prolific cable, is data appearing on /dev/ttyUSB0? Run,
Code:
$ [B]hexdump -C /dev/ttyUSB0[/B]
to see if any data appears.
But, this depends on the device. Some devices need to be triggered, either electrically or by sending commands to the port, before they will send anything back. Other devices will spit data out as soon as power is applied to them.
Which kind is yours?
lsusb returns 067b:2303
My device needs to have data sent to it in order for it to start spitting out data. Otherwise there is nothing happening. It requires a 16bit hex "Start Command". So of course $ hexdump -C /dev/ttyUSB0 returns nothing.
I have the kernel I built here, as well as the gingerbread 2.3.4 rom i am using, and Ive also included the Gaps I needed to install into 2.3.4 to activate the USB feature. (why isnt that feature standard since its really the only difference for 2.3.3 and 2.3.4?
http://www.mediafire.com/?1phzkmvhtr0li
Thank you again.
Honestly you know what would fix all of this... Being able to install windows 7 on this tablet. I know the viewsonic view pad has a dual boot android / windows 7 how cool is that?
DKS1282 said:
lsusb returns 067b:2303
My device needs to have data sent to it in order for it to start spitting out data. Otherwise there is nothing happening. It requires a 16bit hex "Start Command". So of course $ hexdump -C /dev/ttyUSB0 returns nothing.
Click to expand...
Click to collapse
That's assuming that /dev/ttyUSB0 is the correct port, which may not be the case.
Right after the tablet has booted, load both the Prolific kernel modules (or only plusb.ko, if the other is built into the kernel--you still haven't sent me your .config file), attach the Prolific cable to the tablet, then attach the actual device to the cable, then run a
Code:
$ [B]dmesg > /mnt/sdcard/dmesg.txt[/B]
command. Attach the dmesg.txt so I can look at it.
Couldnt do it. Lost the job. Thanks anyway.
Hey guys, I came up with a basic set of tools which I find useful. You may redistribute , include in any custom ROMs and/or distributions.
This includes:
Rewrite /default.prop for ADB
Install and deploy busybox in /system/xbin
install bash, ipctool, strace, tcpdump, and viewmem binaries.
To install, you must be rooted.
Unzip the attached file
place it on your nook.
cd to the folder you installed
Run the following
Code:
sh /sdcard/BHT/run.sh
Please note, I use Android Market app QuickSSH to get into my nook terminal, your results may very.. I hope someone else grabs these files and makes it all more user friendly. I've got too many other things going on.
I encourage other developers to include these valuable debugging tools in their packages.
You, sir, are a monster! You get my vote.
Sent from my Nexus S using xda premium
AdamOutler said:
Hey guys, I came up with a basic set of tools which I find useful. You may redistribute , include in any custom ROMs and/or distributions.
This includes:
Rewrite /default.prop for ADB
Install and deploy busybox in /system/xbin
install bash, ipctool, strace, tcpdump, and viewmem binaries.
To install, you must be rooted.
Unzip the attached file
place it on your nook.
cd to the folder you installed
Run the following
Code:
sh /sdcard/BHT/run.sh
Please note, I use Android Market app QuickSSH to get into my nook terminal, your results may very.. I hope someone else grabs these files and makes it all more user friendly. I've got too many other things going on.
I encourage other developers to include these valuable debugging tools in their packages.
Click to expand...
Click to collapse
I can turn this into an apk, if you don't mind. By turn on adb with this method, adb will be rooted and the device will still be allowed to sleep?
brianf21 said:
I can turn this into an apk, if you don't mind. By turn on adb with this method, adb will be rooted and the device will still be allowed to sleep?
Click to expand...
Click to collapse
By all means. Please do.
My vote too. I just hope after you win that you keep up the great work on the Nook Tablet. The last two weeks or so have looked very promising towards getting custom roms on here and a lot of that has to do with Adam's hard work along with a few others
Nearly all of these are already in snowball-mod, but I'll include ipctool, and viewmem for the next release.
cfoesch said:
Nearly all of these are already in snowball-mod, but I'll include ipctool, and viewmem for the next release.
Click to expand...
Click to collapse
How did you get default.prop reread into memory? The only think I can see is the 2nd init hijack? Am I missing something a lot easier?
brianf21 said:
How did you get default.prop reread into memory? The only think I can see is the 2nd init hijack? Am I missing something a lot easier?
Click to expand...
Click to collapse
Note, I said "nearly all". I don't really see though how changing /default.prop would keep over reboots... rootfs is stored in memory and recreated every time, isn't it?
I've added the binaries to NT Hidden Settings. I have not implemented /default.prop swap yet. I have to play with hijacking init before I do. Thanks again.
brianf21 said:
I've add the binaries to NT Hidden Settings. I have not implemented /default.prop swap yet. I have to play with hijacking init before I do. Thanks again.
Click to expand...
Click to collapse
cool. where are you hosting that binary? I currently have a mirror set up at nook1.adamoutler.com for easy access... When someone gets a new device, they need to download 3 things onto their device to make it a real tablet.. nook1=hidden settings, nook2=homecatcher, nook3=market.. I may change 3 to launcherpro, but hidden settings is the number1 tool required for the nook Tablet.
AdamOutler said:
cool. where are you hosting that binary? I currently have a mirror set up at nook1.adamoutler.com for easy access... When someone gets a new device, they need to download 3 things onto their device to make it a real tablet.. nook1=hidden settings, nook2=homecatcher, nook3=market.. I may change 3 to launcherpro, but hidden settings is the number1 tool required for the nook Tablet.
Click to expand...
Click to collapse
Homecatcher? I mean, I understand if you want to keep using the B&N store and stuff, but if you don't care about the B&N stuff, then the hacked SystemUI.apk is a way better option than Homecatcher.
But then, you're advancing "launcher pro", while I would more generally say "any non-B&N launcher"...
I added another option to nt hidden settings to run adb as root. It doesn't require a reboot and it automatically turns off auto mount. I am using nemith's adbd.
remount / as rw
stop adbd
replace /sbin/adbd
remount / as ro
setprop to turn off auto mount
start adbd as root
It's not persistent after reboot, but it works and doesn't kill the battery. I am not going to bother with hkvc's hijacking init method, because it looks like you, hkvc, bauwks, and nemith will be able to replace the os soon. Thanks.
Externally Powered USB OTG - Nexus 4
This is an all-in-one patch to enable externally powered OTG (technically usb host mode) support. It's built off either the stock kernel or Franco's kernel sources, and should work with any ROM (that these kernels otherwise support). Refer to the second post for details on modifications and additions.
Again, power MUST be supplied externally, as there is no way for the phone to provide it.
Requirements:
Power MUST be supplied to both the USB device and phone. The easiest way would be by using an OTG Y-cable:
If using a traditional OTG cable, a USB Y-cable can be used:
Some powered USB hubs also send power up to the host and can be used directly with a regular OTG cable.
I am not endorsing any specific product or seller. Links are provided solely as examples, and are by no means definitive. As long as the phone and device both get 5V (charger, computer, etc.), and the data pins are connected, host mode will work (provided enough current can be supplied).
Installation:
Simply install the zip in recovery. Script will automatically install/patch necessary files. Must reinstall any time ROM is updated.
To uninstall, simply reflash your ROM. Data wipe is not necessary. If for some reason that's not an option, use the flashable unmod script to remove ROM-side modifications. Flash your kernel of choice afterwards (must flash "reset" kernel first if flashing an "anykernel").
Recovery:
(Optional)
For support in recovery, I've created a sort of "any-any" script. It replaces the recovery's kernel with the boot one. Therefore, by flashing this after the main patch, OTG will effectively be enabled in recovery (after a reboot). However, it is on the actual recovery itself to provide support for usb drives-- TWRP does. Otherwise, you'll have to manually mount any drives via linux console commands.
For your own safety/sanity, ensure the main patch works before flashing this. If recovery fails to boot after flashing, it can easily be replaced by using GooManager or similar. Worst case scenario, a new recovery can always be flashed via fastboot.
Downloads:
(Changelog at end of second post)
MAKE SURE TO DOWNLOAD THE RIGHT VERSION FOR YOUR ROM.
I don't keep track of all the different ROMs so it's on you guys to figure out which one is appropriate. The -CM builds have the two "CAF" commits that are now required for CM and its derivatives (unless they have specifically reverted the associated commits).
Franco-CM builds make use of a ramdisk mod script, which may have unpredictable results. Be ready in case it doesn't boot.
Current:
4.4.x: 2013.12.11 1604ET: [fk r199] [fk r199-CM]
4.4.x: 2013.12.06 1445ET: [aosp r7]
4.4: 2013.12.03 1522ET: [fk r197] [fk r197-CM]
4.4: 2013.12.01 1855ET: [aosp r6]
recoverymod.zip
Old:
4.3: 2013.10.27 1518ET Franco r193: [JWR] [JSS/JLS] [JWR-CM] [JSS/JLS-CM]
4.3: 2013.10.17 1957ET STOCK: [JWR] Stock kernel with OTG -- Only for stock rom
4.2: 2013.07.29 1101ET Franco r165: [JDQ]
ziddey-otg-unmod-20131002.zip
Bugs / Notes:
An OTG cable has the ID pin grounded out, which is used to trigger usb host mode. However, ID pin detection is broken in the Nexus 4 (although working for Slimport detection). Instead, we rely on detection of a "proprietary" charger (voltage on the data pins) in order to determine when to enable host mode.
Self-powered devices (e.g. digital cameras) don't send power to the phone. This will cause the device to not be detectable. Therefore, external power is still required.
Slimport cannot work concurrently with usb data due to hardware limitations (Slimport takes over the usb data pins).
USB drive will automatically mount at /storage/usbdisk0 (also accessible at /usbdisk and /mnt/usbdisk). Media scanning should occur automatically. Make sure to unmount before removal to avoid data loss.
Stock Android only supports FAT for storage. NTFS/exFAT/ext4 partitions may require the use of a third party app like StickMount (CM now supports these partitions natively!).
There appears to be a minor bug in the AOSP code that prevents available space from being reported in Settings->Storage->USB Storage. The screenshot is of CM10.1, which has this fixed
Current builds do not allow for host mode without charging. Use this as a workaround:
RussianBear said:
For those that want to stop usb charging, create a script modifying this to either 1 (disabled) or 0 (enabled). Works for me Not responsible for your phone(s) exploding.
echo 1 > /sys/module/pm8921_charger/parameters/disabled
echo 0 > /sys/module/pm8921_charger/parameters/disabled
Click to expand...
Click to collapse
Standard Disclaimer-- Flashing this patch is at your own risk, and carries no warranty or liability on my part. The assumption is that you will perform due diligence before flashing and make any necessary backups if required.
Screenshots:
Credits:
CaptainMuon, for proving that host mode is possible on the Nexus 4.
Franco, for his kernel, which this patch is based off.
garyd9, for his command to patch platform.xml.
Chainfire, for his usb host wisdom, and article on secondary storage write permissions.
arpruss, for his compiled zip-for-android
All you guys for testing!
Patch Overview:
Kernel with modified msm_otg.c -- This will REPLACE whatever kernel you currently have installed. If you flash a different kernel on top, you will obviously lose OTG capability. This contains the necessary workaround to enable usb host mode ("OTG").
Modified init.mako.rc/init.mako.usbdisk.rc -- Required for creating usb drive directories.
Precompiled modified storage_list.xml -- Allows unmounting usb drive in Settings->Storage. Hex offsets for storageDescription patched during flash.
Addition to build.prop -- Enables downloading apps from play store that require usb host mode support.
Addition to platform.xml -- Workaround to allow apps write access to usb drives
Addition to handheld_core_hardware.xml -- Activate android.hardware.usb.host.xml
android.hardware.usb.host.xml -- Enables Android API support for usb host mode.
fstab.mako (4.3) / vold.fstab (4.2) -- Required for automounting usb drive
Modules cifs.ko, ff-memless.ko, hid-dr.ko, hid-logitech.ko, and xpad.ko (/system/lib/modules). Manually insmod as needed or create an appropriate init.d script to load on boot. These are only required for certain gamepads. Refer here for more information.
Patch Details:
There seems to be an issue with detecting the state of the ID pin on the OTG cable, so we need to come up with an alternate way of determining when to switch to host mode. drivers/usb/otg/msm_otg.c (kernel) is responsible for detecting the charger type and setting host mode, among other tasks. I noticed that when connected to a powered OTG cable, the charge type becomes USB_PROPRIETARY_CHARGER (vs USB_DCP_CHARGER when connected to the wall, and USB_SDP_CHARGER to a computer). This will be the condition that we use to trigger host mode.
Standard OTG cables will have the ID pin shorted to ground. There are also usb accessory charger adapters (ACA) that provide different resistances between these pins to signal functionality (see http://en.wikipedia.org/wiki/USB_On-The-Go#OTG_Micro_Plugs). Support for accessory charger detection isn't enabled in the kernel originally, and doesn't seem to work properly anyway. However, one of the modes is essentially what we're trying to achieve (ID_A): "A charger and a B-device are attached. The OTG device is allowed to charge and enter host mode." So I've added code when USB_PROPRIETARY_CHARGER is detected to simulate the case of ID_A being detected. Following through the code for host mode, certain events are handled differently when ACA support is enabled (specifically, suspension of host mode). In these instances, we need to simulate ACA support since ID_A is technically dependent on it (run into issues with the usb controller getting stuck in a suspended state otherwise). Now we have host mode with charging working properly.
Finally, we need a method of detecting when the OTG cable is unplugged so the device can switch out of host mode. Fortunately, since power (vbus) detection does work, we can use that. Normally, changes in vbus state are ignored while in host mode, so we need to address that. From there, we simulate ACA detection for the case of no ID_A, which is just clearing the ID_A bit and charger. Afterwards, it'll automatically reset the usb state, ready to start all over again.
The dirty hacks to msm_otg.c are complete, and externally-powered OTG is functional.
Refer here for actual changes: https://github.com/ziddey/mako/commits/nightlies-4.3-JSS
No changes are needed to the kernel's .config. Do not enable Drivers->USB->OTG support (we get our support through "OTG support for Qualcomm on-chip USB controller" which is already enabled) or Support for ACA (does not work and most users don't have the proper adapter anyway).
Now we run into a problem with usb storage. Since there is no /system/etc/vold.fstab, usb drives get automatically mounted to /mnt/shell/emulated/0 (at least in CM10.1), which overloads the emulated sdcard, and causes major problems. So we create /system/etc/vold.fstab:
Code:
dev_mount usbdisk /storage/usbdisk0 auto /devices/platform/msm_hsusb_host/usb2
Update:
In 4.3, Google did away with vold.fstab, instead unifying mounting with fstab.mako (on the ramdisk). The replacement line would be:
Code:
/devices/platform/msm_hsusb_host/usb2 /storage/usbdisk0 auto defaults voldmanaged=usbdisk0:auto
Click to expand...
Click to collapse
Update:
In 4.4, mountpoint is set to auto instead of /storage/usbdisk0, and will be taken care of by vold / fuse daemon.
Click to expand...
Click to collapse
But /storage/usbdisk0 does not exist, so it will fail to mount. We will be using /init.mako.rc to create this directory and symlink associated legacy ones. This file resides in a ramdisk (which combines with the kernel to form boot.img), so we need to modify that instead of /init.mako.rc on the device itself (since it wouldn't be able to persist through a reboot). As well, we define the environmental variable SECONDARY_STORAGE. Below the analogous /storage/sdcard0 lines, add:
Code:
export SECONDARY_STORAGE /storage/usbdisk0
mkdir /storage/usbdisk0 0666 system system
symlink /storage/usbdisk0 /usbdisk
symlink /storage/usbdisk0 /mnt/usbdisk
Update:
In 4.4, usb disks must be further FUSE mounted. Rather than insert the script into init.mako.rc, it will now reside in init.mako.usbdisk.rc and be imported to init.mako.rc (strictly for ease/neatness and not standard convention):
Code:
# USB Storage -ziddey
on init
mkdir /mnt/media_rw/usbdisk0 0700 media_rw media_rw
mkdir /storage/usbdisk0 0700 root root
export SECONDARY_STORAGE /storage/usbdisk0
# Support legacy paths
symlink /storage/usbdisk0 /usbdisk
symlink /storage/usbdisk0 /mnt/usbdisk
service fuse_usbdisk0 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/usbdisk0 /storage/usbdisk0
class late_start
disabled
Click to expand...
Click to collapse
In order to enable Settings->Storage->USB Storage, res/xml/storage_list.xml in /system/framework/framework-res.apk needs to be modified. We should be able to simply inject an encoded version of our modified storage_list.xml. I'm not sure if it's possible to simply encode a single file, so I decompiled framework-res.apk in order to make the following addition to res/xml/storage_list.xml (inside StorageList):
Code:
<storage android:mountPoint="/storage/usbdisk0"
android:storageDescription="@string/storage_usb"
android:primary="false"
android:removable="true" />
After recompiling, we should now be able to extract our newly encoded storage_list.xml for use with any ROM's framework-res.apk.
To allow downloading apps from the market that require usb host support, we need to add the following to /system/build.prop:
Code:
ro.usb.host=1
To enable android api support for usb host, we need to create /system/etc/permissions/android.hardware.usb.host.xml with the following:
Code:
<?xml version="1.0" encoding="utf-8"?>
<permissions>
<feature name="android.hardware.usb.host" />
</permissions>
Now to "activate" this file, we add to /system/etc/permissions/handheld_core_hardware.xml:
Code:
<feature name="android.hardware.usb.host" />
Google assigned a different permission group for secondary storage devices (e.g. usb drives), media_rw, for which user apps cannot have write access (Chainfire has a good article on the issue here). We need to modify /system/etc/permissions/platform.xml to allow write access. Add the line in red ("officially" used by Samsung):
Code:
<permission name="android.permission.WRITE_EXTERNAL_STORAGE" >
[color=red]<group gid="media_rw" />[/color]
<group gid="sdcard_rw" />
</permission>
That's it! Externally powered usb host mode should be fully functional.
For full disclosure, these are the changes to the kernel config vs stock (really just NTFS and modules):
Code:
echo "CONFIG_INPUT_JOYSTICK=y" >> .config
echo "CONFIG_JOYSTICK_XPAD=m" >> .config
echo "CONFIG_JOYSTICK_XPAD_FF=y" >> .config
echo "CONFIG_JOYSTICK_XPAD_LEDS=y" >> .config
echo "CONFIG_INPUT_FF_MEMLESS=m" >> .config
echo "CONFIG_HID_LOGITECH=m" >> .config
echo "CONFIG_LOGITECH_FF=y" >> .config
echo "CONFIG_LOGIRUMBLEPAD2_FF=y" >> .config
echo "CONFIG_LOGIG940_FF=y" >> .config
echo "CONFIG_LOGIWHEELS_FF=y" >> .config
echo "CONFIG_HID_DRAGONRISE=m" >> .config
echo "CONFIG_DRAGONRISE_FF=y" >> .config
echo "CONFIG_CIFS=m" >> .config
echo "CONFIG_NTFS_FS=y" >> .config
# echo "CONFIG_USB_DEBUG=y" >> .config
sed 's/\(CONFIG_USB_STORAGE_DEBUG\)=y/# \1 is not set/' -i .config
Changelog:
4.4: 2013.12.01 0349ET: [fk r196] [fk r196-CM] [aosp r5] aosp includes gamepad kernel modules.
4.4: 2013.11.29 0219ET: [fk r195] [fk r195-CM] CM build attempts to patch Franco ramdisk mods on the fly, so be prepared if things go south.
4.4: 2013.11.21 1922ET: [fk r194] [aosp r2] Update to 4.4 configuration for mounting usbdisk.
4.3: 2013.10.22 2201ET r191: [JWR] [JSS/JLS] Allow potentially faster charging in host mode, re-add manual host mode
4.3: 2013.10.22 2204ET r191-CM: [JWR] [JSS/JLS] ^ + 2 "CAF" commits for CM compatibility
4.3: 2013.10.09 2148ET r190: [JWR] [JSS/JLS] Re-enable USB debug messages
4.3: 2013.10.01 1954ET r188: [JWR] [JSS/JLS] Zipalign framework-res.apk
ziddey-otg-r183-09141713.zip ziddey-otg-r183-JSS-09141713.zip Add SECONDARY_STORAGE env., do ramdisk patching during flash, include CIFS module -- rebase to r183.
ziddey-otg-r182-09041823.zip ziddey-otg-r182-JSS-09041823.zip Remove module unloading support, patch handheld_core_hardware.xml -- rebase to Franco r182.
ziddey-otg-r178-08240234.zip ziddey-otg-r178-JSS-08240238.zipDisable modversions, enable kernel wakelock stats-- rebase to Franco r178.
JSS15J 4.3.0 2013.08.13 1533ET: ziddey-otg-r174-08131533.zip First release for JSS15J. Updated to 4.3's new unified fstab (native mounting support). Using an "anyramdisk" method for compatibility with different ROMs (specifically, different su implementations). Based off Franco r174.
2013.07.29 1101ET: ziddey-otg-r165-07291101.zip Maintenance build-- rebase to Franco r165.
2013.07.14 2015ET: ziddey-otg-r163-07142015.zip Allow automatic host mode without charging-- rebase to Franco r163.
2013.07.08 1420ET: ziddey-otg-r162-07081420.zip Update storage_list.xml for compatibility with new CM nightlies-- rebase to Franco r162.
2013.06.28 1551ET: ziddey-otg-M3-06281551.zip Maintenance build-- rebase to Franco M3.
2013.06.27 0427ET: ziddey-otg-r156-06270427.zip Re-enable read-only NTFS support in kernel.
2013.06.06 1736ET: ziddey-otg-r151-06061736.zip Releases will now include modules ff-memless.ko, hid-dr.ko, hid-logitech.ko, and xpad.ko (/system/lib/modules). Manually insmod as needed or create an appropriate init.d script to load on boot. Rebase to Franco r151.
2013.05.25 0749ET: ziddey-otg-05250749.zip Fix compatibility issue with CWM (MTP crashes).
2013.05.23 2119ET: ziddey-otg-05232119.zip Start charging immediately when entering host mode. This resolves issues with proprietary chargers.
2013.05.22 2305ET: ziddey-otg-05222305.zip Rebase to Franco's r140. Revert checks for actual proprietary chargers in favor of manually disabling automatic host mode (temporary). Issue "# echo disable > /sys/kernel/debug/msm_otg/aca" to disable automatic host mode (enable to re-enable).
2013.05.17 0107ET: ziddey-otg-05170107.zip Added check for other proprietary charger case. Rebase to Franco's r137.
2013.05.15 0124ET: ziddey-otg-05150124.zip Attempt to detect actual proprietary chargers (Apple-compatible) and charge properly. Rebase to Franco's r136.
2013.05.09 1729ET: ziddey-otg-05091729.zip Should now patch precompiled storage_list.xml to address incorrect strings (Internal Storage/USB Storage). Re-enabled verbose usb debugging messages (dmesg).
2013.05.06 1846ET: ziddey-otg-05061846.zip Maintenance build. Based off Franco's current nightlies branch (r134?). Updated storage_list.xml to match current CM nightlites. Removed freshen flag to hopefully address issues with framework-res.apk not being patched (thanks sga999). Verbose usb debugging messages not enabled (unaltered r134 config)
2013.04.07 0355ET: ziddey-otg-04070355.zip Now modifies /system/etc/permissions/platform.xml to allow app write access to usb storage (thanks garyd9 for script code). Kernel build number reverted to 105 to match Franco's M1 build number.
2013.03.27.2338ET: ziddey-otg-03272334.zip Allow host mode when slimport connected (must manually enable for now. not sure if it actually works, so please report results.) Prevent forced host mode from entering suspended state so it won't get stuck (perhaps worth reinvestigating if we ever get internal power working). Allow forcing mode via /sys/kernel/debug/msm_otg/mode regardless of current state (original code had conditions that were unreasonable. it is designed to be used for debugging after all..). Forgot to reset the build number; should be 105. Would only potentially matter if using Franco's app.
2013.03.23 2000ET: ziddey-otg-03231951.zip All-in-one update now enables android api for usb host mode. Should automatically rescan media library when usb storage is connected. Kernel updated to Franco M1 (milestone), and will probably stay here for a while.
2013.03.17 1548ET: otg-aio-20130317.zip All-in-one flashable zip that includes modified kernel/ramdisk, vold.fstab, and precompiled storage_list.xml for framework-res.apk (thanks arpruss for precompiled zip-for-android). Kernel unchanged from last release (Franco r102 base), but removed unrelated line previously added to default.prop in ramdisk
2013.03.14 1648ET: otg-franco-boot-03141621.img Should have fixed all issues involving unpopulated hubs, unplugged devices, host mode timeout, and charging. Changed main mount point to /storage/usbdisk0 since that seems to be the new standard (manually update vold.fstab accordingly). Based on Franco's git as of 3/12 (after r102)
2013.03.11 2244ET: otg_boot_r3.img Interim build to address wall charging issues (do not attach/detach devices while otg cable connected to phone)
2013.03.09 0739ET: otg_boot_r2.img Should charge (faster) in host mode
2013.03.08 1128ET: otg_franco.zip Initial release in this thread.
2013.03.07 1350ET: franco-otg-201303071328.img "Pre-alpha" build posted in CaptainMuon's thread. Forces disabling of host mode on device unplug.
2013.03.07 1102ET: franco-otg-201303071032.img "Pre-alpha" build posted in CaptainMuon's thread. Forces host mode on detection of "proprietary" type charger (vs usb = sdp, wall = dcp).
References:
Typical Configuration Examples | Android Developers: http://source.android.com/devices/tech/storage/config-example.html
External Storage Technical Information | Android Open Source: http://source.android.com/tech/storage/
chainfire[dev~blog] - Is Google blocking apps writing to SD cards?: http://www.chainfire.eu/articles/113/Is_Google_blocking_apps_writing_to_SD_cards_/
Re: [OTG] [08MAR13] [DIRTY HACKS] OTG Kernel / Ramdisk / Framework (Seeking Devs)
Just for clarification this still requires external power via a y cable right?
Sent from my Nexus 4 using XDA Premium HD app
Yes, still requires external power. Currently, the hack triggers host mode when detecting "USB_PROPRIETARY" charger.
ziddey, is it possible for you to make a framework file for the stock rom? Also, you've given us .img files before. I'm assuming we can flash these .zip files during recovery (e.g. twrp)?
EDIT: I just tried this without the framework file since I'm on stock rom. I flashed the kernel through twrp, but the otg_vold zip would not flash (just said "failed"). Maybe it's not supposed to?. I manually put it in /system/etc. Let me know if I should have been able to flash it.
It works as you described, with usbdisk, no stickmount required. However, the phone is no longer charging like it did with your prior kernels. Maybe that should have been expected, but I certainly liked the fact that I had that "feature" before (with my cable from post #40...it did NOT charge with other OTG or Y-cables).
Strange, but a flash drive works, but a microsd card reader does not. It was working with your prior kernels. EDIT: It seems to be finicky, but I can get that microsd card reader to work also.
Thanks so much for your efforts!
Re: [OTG] [08MAR13] [DIRTY HACKS] OTG Kernel / Ramdisk / Framework (Seeking Devs)
Nice work man.. Will give a try
Sent from my Nexus 4 using xda app-developers app
Made some updates. Should now charge (faster) in host mode.
otg_boot_r2.img: http://d-h.st/Oky Modified kernel/ramdisk based on 3/1 git clone of Franco's kernel
an idea
what happens if you make a manual switch for usb host mode? like when we need to plug usb, we change the state?
sga999 said:
ziddey, is it possible for you to make a framework file for the stock rom? Also, you've given us .img files before. I'm assuming we can flash these .zip files during recovery (e.g. twrp)?
Click to expand...
Click to collapse
Gone back to image files again. One less step to do this way.
EDIT: I just tried this without the framework file since I'm on stock rom. I flashed the kernel through twrp, but the otg_vold zip would not flash (just said "failed"). Maybe it's not supposed to?. I manually put it in /system/etc. Let me know if I should have been able to flash it.
Click to expand...
Click to collapse
You're right; I hadn't tested it, and assumed I'd be able to just hack up a different zip for use. Pulled it for now.
It works as you described, with usbdisk, no stickmount required. However, the phone is no longer charging like it did with your prior kernels. Maybe that should have been expected, but I certainly liked the fact that I had that "feature" before (with my cable from post #40...it did NOT charge with other OTG or Y-cables).
Click to expand...
Click to collapse
I'm surprised you didn't have issues with the prior builds. I don't think I ever changed anything. That said, it should be fixed now. Let me know how it works.
Strange, but a flash drive works, but a microsd card reader does not. It was working with your prior kernels. EDIT: It seems to be finicky, but I can get that microsd card reader to work also.
Click to expand...
Click to collapse
Likely an issue on your end since I don't think anything was changed that would cause this. Are you trying to use both the flash drive and microsd at the same time? I'm not sure how that'd be handled-- upon insertion of the second drive, either nothing happens, or it overloads the first drive. As it is, I'm guessing my implementation of usbdisk isn't properly done.
Thanks so much for your efforts!
Click to expand...
Click to collapse
No problem! More of a personal challenge/desire. Really hoping that a real dev takes notice.
ereghro said:
what happens if you make a manual switch for usb host mode? like when we need to plug usb, we change the state?
Click to expand...
Click to collapse
You mean like CaptainMuon's build, where you change /sys/kernel/debug/msm_otg/mode?
Originally, there were issues with that method after unplugging the OTG cable, but that may have been fixed with the hacks to the OTG_STATE_A_IDLE case. It's possible that the other modifications will now cause problems with with the debug mode, but I'm imagining it just makes it unnecessary (except for debugging purposes) since it's not actually triggering a_host based on the ID pin, but rather by the detected charger.
Is there a particular reason you want to use a manual switch? I can re-enable it in the next build.
ziddey said:
Gone back to image files again. One less step to do this way.
You're right; I hadn't tested it, and assumed I'd be able to just hack up a different zip for use. Pulled it for now.
I'm surprised you didn't have issues with the prior builds. I don't think I ever changed anything. That said, it should be fixed now. Let me know how it works.
Likely an issue on your end since I don't think anything was changed that would cause this. Are you trying to use both the flash drive and microsd at the same time? I'm not sure how that'd be handled-- upon insertion of the second drive, either nothing happens, or it overloads the first drive. As it is, I'm guessing my implementation of usbdisk isn't properly done.
No problem! More of a personal challenge/desire. Really hoping that a real dev takes notice.
Click to expand...
Click to collapse
ziddey, I don't think you answered about me wanting a stock version of framework-res. I tried to create it with the Framework Flasher that you suggested, and it seemed to complete successfully. But when I flash it, it stops at the Nexus 'X' logo...it does a little vibration every minute or so, but never comes out of that. I even used that same tool to decompile, recompile WITHOUT any changes, sign it, etc., but the result is the same. So....either the tool isn't really working or I'm doing something else wrong. Any special instructions on how to flash the update.zip...or what it must be flashed with? I tried flashing it alone, then tried with your kernel (2 separate steps in twrp).
I haven't had enough time yet to get in much testing, but YES! Charging has returned!
No, I'm not trying both devices at the same time, so I don't know what is going on with the microsd. I'll keep trying to figure it out.
I'd like to know how to see logs of what's going on, like when you say there is "overload" (or other problems). Can you tell me what you're looking at to see errors, status, etc.?
I understand how you feel about the personal challenge. I'm that way too....I love to see things work and won't quit! But unfortunately, I don't have the expertise to help you here. But I'll certainly test it! I can't understand why dev's aren't joining you. And I may be the only one downloading your files (based on counts on dev-host). Very strange.
Did you update the apktool components? The components in wesf90's Framework Flasher (http://forum.xda-developers.com/showthread.php?t=1432152) are old and don't support JB4.2.
Down the new apktool and dependencies from http://code.google.com/p/android-apktool/downloads/list and replace the ones in wesf90's kit. That's all I did, and it seemed to work fine for me.
ziddey said:
Did you update the apktool components? The components in wesf90's Framework Flasher (http://forum.xda-developers.com/showthread.php?t=1432152) are old and don't support JB4.2.
Down the new apktool and dependencies from http://code.google.com/p/android-apktool/downloads/list and replace the ones in wesf90's kit. That's all I did, and it seemed to work fine for me.
Click to expand...
Click to collapse
I updated apktool and aapt. And everything ran perfectly. Most people who had not updated yet said it failed somehow, then after updating, it worked. But I updated the tools first, never got errors, so I think it's creating the update.zip properly. So I'll ask this one more time, and if you don't want to or can't do this, please let me know. Can you create the framework-res.apk zip file for the stock rom for me? Maybe I would then be able to compare my update.zip to yours and see what went wrong.
If I already have your kernel installed, can I just bring up twrp recovery and flash the single update.zip for the framework? Or is it more complicated than that? I'm thinking I must be missing something about how to flash the update.zip.
Can you tell me how to see logs that show the overload and other issues? Again, please just let me know, and if you don't want to answer this, I'll stop asking.
I appreciate all that you've done, and I certainly don't want to ask you too much. I just need to know if you're missing the questions or don't want to answer...which is fine.
sga999 said:
I updated apktool and aapt. And everything ran perfectly. Most people who had not uproperlyyet said it failed somehow, then after updating, it worked. But I updated the tools first, never got errors, so I think it's creating the update.zip properly. So I'll ask this one more time, and if you don't want to or can't do this, please let me know. Can you create the framework-res.apk zip file for the stock rom for me? Maybe I would then be able to compare my update.zip to yours and see what went wrong.
If I already have your kernel installed, can I just bring up twrp recovery and flash the single update.zip for the framework? Or is it more complicated than that? I'm thinking I must be missing something about how to flash the update.zip.
Can you tell me how to see logs that show the overload and other issues? Again, please just let me know, and if you don't want to answer this, I'll stop asking.
I appreciate all that you've done, and I certainly don't want to ask you too much. I just need to know if you're missing the questions or don't want to answer...which is fine.
Click to expand...
Click to collapse
Sounds like the update script is fine, the problem is with your framework. Either it's not being recompiled properly or the changes you're making are causing problems. What versions of the tools are you using?
So if this requires external power, would an external hdd with external power source work, in theory? Or does the USB itself need to carry a current to make it work?
MWBehr said:
Sounds like the update script is fine, the problem is with your framework. Either it's not being recompiled properly or the changes you're making are causing problems. What versions of the tools are you using?
Click to expand...
Click to collapse
I've tried it with no changes at all, i.e. decompile and recompile with no changes (my post #11 describes this in more detail). So as you said, the recompile must not be working.
My versions are:
aapt.exe v0.2
apktool.jar 1.5.2 but unfortunalely, frameworkflasher's runme.bat always does "echo version 1.4.3" (this threw me off for a while!)
I only replaced aapt.exe and apktool.jar. Are there other .exe or .dll files that need to be replaced also? Maybe I'm just doing an incomplete job of updating the files.
Thanks for your help.
sga999 said:
Can you create the framework-res.apk zip file for the stock rom for me?
Can you tell me how to see logs that show the overload and other issues?
Click to expand...
Click to collapse
Upload your framework-res.apk and I'll try to mod it. Not sure why it's not working for you though.
I haven't combed through the logs to look for when it's mounted, but since you created vold.fstab, it shouldn't be an issue. Maybe it didn't affect the stock rom anyway. If it did mount at /mnt/shell/emulated/0, internal storage would no longer be accessible. I had issues even opening Android settings, nevermind storage. Of course, you could simply check your mounts with the mount command, or use df to see mounts / disk space.
hp420 said:
So if this requires external power, would an external hdd with external power source work, in theory? Or does the USB itself need to carry a current to make it work?
Click to expand...
Click to collapse
In theory, yes. However, I'm imagining that a powered external hdd isn't going to be sending power out the usb port, and since the charger type is currently used to force host mode, it won't switch automatically. This could be a potential reason for the debug /sys/kernel/debug/msm_otg/mode, so I'll enable it in the next build. Unfortunately, I'm imagining that it still won't work though, seeing how it'd get stuck in a_idle. However, it does give me some ideas for trying to trace the root issue, or at least figuring out another workaround.
ziddey said:
Upload your framework-res.apk and I'll try to mod it. Not sure why it's not working for you though.
Click to expand...
Click to collapse
ziddey, here are links to my framework-res.apk and the update.zip. They are unmodified stock, i.e. I let framework flasher decompile, recompile without any changes, sign, etc. You may have no interest in the update.zip, but if what you create "matches" mine (not sure if a byte by byte compare will work), I don't think it will help for you to give yours to me. But again, just ignore that .zip if you want to.
I'm not very familiar with uploading, so if I'm not supposed to put direct links here, let me know.
http://www.mediafire.com/?wxcnozb2e5u8wps
http://www.mediafire.com/?visp1jzai8aqisp
What I mean about the log is that I don't know what log you look at. I know there's logcat, dmesg, maybe others, but I've never looked at them. So I wanted to learn a little more by looking at the same thing you look at when you notice various errors.
Thanks for your help.
edit: DO NOT DOWNLOAD. Tested by sga999 and does not work.
http://d-h.st/Z2s md5sum: 2b07609be9c462a0f4ba54c141dc2e88
your update.zip db087c101a8c07aa3606102128c96051
mine 19642b12da5a6fd372280c3e33fa8247
Report if that works. May be of interest to others. Is that stock 4.2.2 JDQ39?
ziddey said:
http://d-h.st/Z2s md5sum: 2b07609be9c462a0f4ba54c141dc2e88
your update.zip db087c101a8c07aa3606102128c96051
mine 19642b12da5a6fd372280c3e33fa8247
Report if that works. May be of interest to others. Is that stock 4.2.2 JDQ39?
Click to expand...
Click to collapse
Yours fails also! I have given it about 6 minutes, and it's stuck on the 'X'. I've waited longer than that before, maybe 10 minutes, but I don't ever think it should take more than a couple of minutes, right? UPDATE: I've now waited 11 minutes.
Yes, I gave you /system/framework/framework-res.apk from stock 4.2.2 JDQ39. That's what I'm running.
I have the unsigned and signed apk's saved from the various steps of Framework Flasher. It would be interesting to know where it goes wrong. I'm pretty sure the signed apk has the same problem, but I can't be sure I installed it properly (I read various posts about putting it in /system, fixing properties, cut/paste into /system/framework). It reboots immediately after I do the paste.
I would guess that the recompile is somehow not working. I suppose I could try to go through the individual steps on my own...but I sure had hoped to use this tool, just like you did!
Thanks for creating it for me...at least it's not something I was doing wrong with the tool!
HI, I have an S3 9300 which was damaged by water. I finally managed to revive it by using Isopropyl Alcohol and cleaning it. The piece worked perfectly fine except for the display screen which kept blurring out. Unfortunately, the S3 display gave up and i cannot see anything or even use the touch. I tried opening the display to clean out any moisture, but again unfortunately even after carefully removing the display it wont work. Now the S3 is working with no display or Touch. repairing it here in India is costing me more than a second hand unit available. so i decided to not repair it. But since the motherboard and the rest are working fine, i thought i could use it for something else like a security IP camera.
Now i have a problem, the USB debugging was not enabled before the display konked off. the S3 is not rooted either. Can anyone help me how can i get the USB debugging enabled somehow so i can operate the phone from the desktop PC using MyPhoneExplorer. this way i can install apps, use the phone for SMS, calls and use the camera too.
I just need the USB debugging on so i can do the needful.
Anybody has any ideas? how can you help me here?
i have tried putting it in download mode and flashing a rooted stock firmware. this will at least have USB debugging on by default (i think).
Please help. what can i do?
If anyone has a working display with a busted motherboard, can i buy it? how much? i live in mumbai - India
Please reply in the thread or PM me
Thanks guys.
try connecting s3 to tv via hdmi and goto settings>developer option>enabled usb debugging ?
MoonBlade said:
try connecting s3 to tv via hdmi and goto settings>developer option>enabled usb debugging ?
Click to expand...
Click to collapse
would have tried it. but the digitizer does not work either. cannot use the display or touch. secondly i dont have the MHL HDMI connector too.
francisdsa said:
would have tried it. but the digitizer does not work either. cannot use the display or touch. secondly i dont have the MHL HDMI connector too.
Click to expand...
Click to collapse
looks like you are in a bit of a trouble.. i would have suggested flashing any other rom with usb debugging already enabled like cm10.1 . but with screen not working accessing recovery to flash rom will be tricky.
MoonBlade said:
looks like you are in a bit of a trouble.. i would have suggested flashing any other rom with usb debugging already enabled like cm10.1 . but with screen not working accessing recovery to flash rom will be tricky.
Click to expand...
Click to collapse
Ha ha ha. Actually the issue is that USB debugging is not enabled. that is the reason i am jumping around trying stuff. in fact i am on ODIN FU##ng around and now the device just wont go off the download mode. still fooling around.
i think i may brick the phone... anyways, the piece was a lab rat for me...
can i salvage anything from it? can i use the camera elsewhere? anything???
do let me know
francisdsa said:
Ha ha ha. Actually the issue is that USB debugging is not enabled. that is the reason i am jumping around trying stuff. in fact i am on ODIN FU##ng around and now the device just wont go off the download mode. still fooling around.
i think i may brick the phone... anyways, the piece was a lab rat for me...
can i salvage anything from it? can i use the camera elsewhere? anything???
do let me know
Click to expand...
Click to collapse
i heard somewhere that you can use usb keyboard with your s3. but then i am not sure whether u need usb debugging to be ON for this to work. if its not needed then i think you can use the keyboard to navigate to settings to enable usb debugging.
i have never tried this though try searching a bit in google. might find a solution.
http://forum.xda-developers.com/showthread.php?t=1749902
You cannot use input device and video output simultaneously. This means you cannot change any settings. Only bet is to try to find an adaptor that allows MHL and usb simultaneously.
Sent from my GT-I9300 using Tapatalk 4
rootSU said:
You cannot use input device and video output simultaneously. This means you cannot change any settings. Only bet is to try to find an adaptor that allows MHL and usb simultaneously.
Sent from my GT-I9300 using Tapatalk 4
Click to expand...
Click to collapse
You are right.
Well, please let me know if there is any other method to control the phone from the PC and enable the USB debugging settings.......I would be delighted and thankful
any ADB command mode to start USB vai command prompt
francisdsa said:
You are right.
Well, please let me know if there is any other method to control the phone from the PC and enable the USB debugging settings.......I would be delighted and thankful
Click to expand...
Click to collapse
There's no other method.
Heres a thread about MHL and OTG : http://forum.xda-developers.com/showthread.php?t=1741583
rootSU said:
There's no other method.
Heres a thread about MHL and OTG : http://forum.xda-developers.com/showthread.php?t=1741583
Click to expand...
Click to collapse
Need to know something.
What if i flash a pre-rooted ROM from ODIN? USB debugging should be enabled on it by default.
but will i get a rooted custom ROM in odin flashable format?
will i be able to flash the ROM if the device is not rooted and USB debugging disabled?
have never tried this method and hence asking a nooby question
Please help
francisdsa said:
Need to know something.
What if i flash a pre-rooted ROM from ODIN? USB debugging should be enabled on it by default.
but will i get a rooted custom ROM in odin flashable format?
will i be able to flash the ROM if the device is not rooted and USB debugging disabled?
have never tried this method and hence asking a nooby question
Please help
Click to expand...
Click to collapse
i was just googling around . i found something interesting. i think you can enable usb debugging via adb in CWM if u have proper knowledge of adb commnads. just do a search for enabling usb debugging by changing value of a property in the settings.db file located in data/data/com.android.providers.settings/databases/settings.db
rootSU said:
There's no other method.
Heres a thread about MHL and OTG : http://forum.xda-developers.com/showthread.php?t=1741583
Click to expand...
Click to collapse
MoonBlade said:
i was just googling around . i found something interesting. i think you can enable usb debugging via adb in CWM if u have proper knowledge of adb commnads. just do a search for enabling usb debugging by changing value of a property in the settings.db file located in data/data/com.android.providers.settings/databases/settings.db
Click to expand...
Click to collapse
Thanks dude, but the issue is i dont have root or CWM installed. With no display this is will be even painful as i will blindly be shooting around and possibly brick the device.
i have spoken to a few friends if they can arrange an S3 and maybe with the USB keyboard over OTG i can enable the developer settings. Secondly have also spoken around with a few service centers and mobile repair shops if they can temporarily swap a working display from a repair piece and enable the mode for me. no one has a piece at present. fingers crossed...
by the way, you are from india.. Where are you from? which city? I am from Mumbai
francisdsa said:
Thanks dude, but the issue is i dont have root or CWM installed. With no display this is will be even painful as i will blindly be shooting around and possibly brick the device.
i have spoken to a few friends if they can arrange an S3 and maybe with the USB keyboard over OTG i can enable the developer settings. Secondly have also spoken around with a few service centers and mobile repair shops if they can temporarily swap a working display from a repair piece and enable the mode for me. no one has a piece at present. fingers crossed...
by the way, you are from india.. Where are you from? which city? I am from Mumbai
Click to expand...
Click to collapse
Flashing CWM is easy. You just need to be in download mode which is easy enough to bet into blind.
ADB is done from a computer. If the settings.db has the answer, all you do is adb pull it, make the change and adb push it. Seems simple enough to me.
rootSU said:
Flashing CWM is easy. You just need to be in download mode which is easy enough to bet into blind.
ADB is done from a computer. If the settings.db has the answer, all you do is adb pull it, make the change and adb push it. Seems simple enough to me.
Click to expand...
Click to collapse
could try that. but i read elsewhere that the settings change will not affect ti as the boot.img file also needs to be stripped and modified to work with it.
francisdsa said:
could try that. but i read elsewhere that the settings change will not affect ti as the boot.img file also needs to be stripped and modified to work with it.
Click to expand...
Click to collapse
Can't you just flash a supported custom kernel then? That's all boot image is. A kernel available in .tar? Siyah 1.9.1 tar flashed from Odin.
Then boot into recovery:
Code:
adb shell
mount system
sqlite3 /data/data/com.android.providers.settings/databases/settings.db
SELECT * FROM global;
update global set value=1 where name='adb_enabled';
SELECT * FROM global;
CTRL + C
adb shell
mount system
echo "persist.service.adb.enable=1" >> /system/build.prop
This should work. Yes, adb_enabled is the value set as 0 or 1 when turning usb debugging on or off, I tested it all
Note SELECT * FROM global; shows all the values in the global table which is where adb_enabled is. It should say 0. Then you run the update command and then SELECT again to witness the change. I noticed that this did not persist after booting into android, which is why we need to put persist in the build prop. Hope this helps.
rootSU said:
Can't you just flash a supported custom kernel then? That's all boot image is. A kernel available in .tar? Siyah 1.9.1 tar flashed from Odin.
Then boot into recovery:
Code:
adb shell
mount system
sqlite3 /data/data/com.android.providers.settings/databases/settings.db
SELECT * FROM global;
update global set value=1 where name='adb_enabled';
SELECT * FROM global;
CTRL + C
adb shell
mount system
echo "persist.service.adb.enable=1" >> /system/build.prop
This should work. Yes, adb_enabled is the value set as 0 or 1 when turning usb debugging on or off, I tested it all
Note SELECT * FROM global; shows all the values in the global table which is where adb_enabled is. It should say 0. Then you run the update command and then SELECT again to witness the change. I noticed that this did not persist after booting into android, which is why we need to put persist in the build prop. Hope this helps.
Click to expand...
Click to collapse
Huh. That's seeming a bit tough fer me especially after I left linux almost 10 years ago. But am eager to try it out. Will try so and check. yhanks fot the great info. Will revert
francisdsa said:
Huh. That's seeming a bit tough fer me especially after I left linux almost 10 years ago. But am eager to try it out. Will try so and check. yhanks fot the great info. Will revert
Click to expand...
Click to collapse
You can literally copy and paste that (line by line) into windows cmd prompt, once you have adb.exe dropped in c:\windows\system32
But yeah let me know please. I did test successfully so works for me
rootSU said:
You can literally copy and paste that (line by line) into windows cmd prompt, once you have adb.exe dropped in c:\windows\system32
But yeah let me know please. I did test successfully so works for me
Click to expand...
Click to collapse
Yea yea. Surely. I shall try tomorrow itself.
francisdsa said:
Yea yea. Surely. I shall try tomorrow itself.
Click to expand...
Click to collapse
Did not work. Flashes the Siyah kernel via odin, the phone went into a boot loop.
went into recovery mode
started ADB
here is the output
====================
C:\>adb devices
List of devices attached
4df7dfa9572f3051 recovery
C:\>adb shell
[email protected]:/ $ mount system
mount system
Usage: mount [-r] [-w] [-o options] [-t type] device directory
1|[email protected]:/ $
=============================
here are the mount paths
================
C:\>adb shell
[email protected]:/ $ mount
mount
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
/dev/block/mmcblk0p9 /system ext4 rw,nodev,noatime,nodiratime,barrier=1,data=ord
ered 0 0
[email protected]:/ $
=========================
Am stuck please help
First time posting and I wanted to say thank you to all the excellent talent here on XDA! None of this would have been done without the work of so many people.
I have a Moto G Play (2021) (XT2093-4) that I recently purchased (Best Buy - $159 US/Carrier Unlocked) and I wanted to document my adventure in to rooting, making '/system' RW, and fixing the missing LED notification light (hint: I used the charging light) (hint^2: It's not required to make '/system' RW in order to fix the LED notification light - I just wanted more control over my phone).
First, "OEM unlocking" was greyed out for me, but became available after several days of having the phone online with a SIM card.
I followed the instructions here to unlock the bootloader and root with Magisk (Non-TWRP). Along with these instructions.
Once bootloader is unlocked, you will need the 'boot.img' file from your stock firmware. I used the "Rescue and Smart Assistant" utility to grab a copy of the stock firmware (GUAMNA_RETAIL_QZAS30.Q4_39_35_9_subsidy_DEFAULT_regulatory_DEFAULT_CFC.xml) and extracted the "boot.img" file for the next steps.
Continue installing Magisk (Filenames may be different! Don't just copy and paste.):
Code:
adb install Magisk-v23.0.apk
adb push boot.img /sdcard/Download
(Follow the instruction on your phone to patch 'boot.img' in Magisk)
adb pull /sdcard/Download/magisk_patched-23000_aKKMt.img
adb reboot bootloader
fastboot flash boot_a magisk_patched-23000_aKKMt.img
fastboot flash boot_b magisk_patched-23000_aKKMt.img
You should now have a working, rooted Moto G Play. You can just stop here and have fun with your phone, but I noticed that even with root, the system partition was not RW.
I followed these instructions to make '/system' writable (Note: you will need the 'sysrw_repair.zip' that's included in the bundle and a Linux system):
Code:
adb push systemrw_1.32_flashable.zip /data/local/tmp/
adb shell
su
cd /data/local/tmp/
unzip systemrw_1.32_flashable.zip
cd systemrw_1.32/
chmod +x systemrw.sh
./systemrw.sh in=`ls -l /dev/block/by-name/super | awk '{print $NF}'` out=/data/local/tmp/systemrw_1.32/img/super_original.bin size=50
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
(On another Linux terminal)
Code:
cd /path/to/unzipped/sysrw_repair/dir/
chmod +x sysrw_repair.sh
./sysrw_repair.sh
This results in a new folder (img) with a rather large bin file (super_original.bin).
(Back on the phone adb)
Code:
exit # Exit root
exit # Exit adb
adb reboot bootloader
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
You should be able to login and have a writable '/system':
Code:
adb shell
su
mount -o rw,remount /
No errors should appear.
Last, I like having an LED indicator that tells me that I have an SMS/MMS notification waiting. Motorola thought it would be wise to eliminate that feature altogether instead of having the option to enable it. So, I forced it back on using a startup script that dumps the notifications and greps for some key words. And, if it finds something, it "breaths" the charging LED. The script loops until the notification is gone, then keeps checking for new notifications every 30 seconds. (Note: the "/data/adb/service.d/" directory is used by Magisk like an INIT service):
(Still root on the phones adb)
Code:
cd /data/adb/service.d/
cat <<EOF > ledfix.sh
#!/bin/sh
while true; do
if dumpsys notification | egrep NotificationRecord | egrep sms > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) == 0 ]]
then
echo 1 > /sys/class/leds/charging/breath
sleep 2
continue
else
sleep 2
continue
fi
elif egrep 'Charging' /sys/class/power_supply/battery/status > /dev/null
then
if [[ $(cat /sys/class/leds/charging/breath) -ne 0 && $(cat /sys/class/leds/charging/brightness) -ne 0 ]]
then
echo 0 > /sys/class/leds/charging/breath
echo 255 > /sys/class/leds/charging/brightness
elif [[ $(cat /sys/class/leds/charging/breath) == 0 && $(cat /sys/class/leds/charging/brightness) == 0 ]]
then
echo 255 > /sys/class/leds/charging/brightness
else
continue
fi
else
echo 0 > /sys/class/leds/charging/breath
echo 0 > /sys/class/leds/charging/brightness
fi
sleep 30
done
EOF
chown 0.0 ledfix.sh
chmod 0755 ledfix.sh
reboot
Now, the charging light will fade off and on about every 2 seconds if there's an SMS/MMS notification waiting. And will check for notifications every 30 seconds. I'm sure someone can come up with a better way of doing this, but this was a nice quick-and-dirty way to get what I wanted.
Hope this helps!
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
PROFSLM said:
I created an account to say thank you for this, I have already done a good portion, having unlocked the bootloader, the problem is the Rescue Smart Assistant, it won't let me log in, it keeps telling me it can't connect, and the GUI is different because of an update, there is no download button inside the program, only a greyed out rescue button. How did you manage to make the backup Boot.img? Maybe you are using a different OS, and/or version of the program (Not the app, that is already auto-installed), I'm using Windows 10, are you on Linux? I might just need to try from Linux, maybe in a VM.
I was trying to do this before I found this post, and have already installed ADB, the SDK, fastboot, and Motorola Drivers, I just need a way to get the Boot.img, and to patch it, also figure out how to flash it. The last android I rooted with a custom rom was the HTC EVO 4G with Oreo/Jellybean, so I'm a little rusty, but am able to understand technical jargon.
If anyone could help, that would be awesome. I've reinstalled different versions of Rescue Smart Assistant as well, they always upgrade on boot, same problem. I've added exceptions to my firewall and everything.
UPDATE: Was about to post this when I had updated from android 10 to 11 and decided to try logging in again a little closer to my router, to see if the connection was timing out, I think that was the cause, as I can now sign in, and the GUI seems correct from the first appearance. I don't see why I should have any trouble following the rest of the guide, but feel I should share my trials and frustrations anyways, for anyone else experiencing the same,
Thanks again.
Click to expand...
Click to collapse
You can also get the firmware from
Lolinet Mirrors
https://t.me/MotoUpdatesTracker
Search for Firmware by codename, software channel, Software Version, and build #
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
mario0318 said:
So I wasn't going crazy when I could swear a LED notification light in the upper right side above the screen blinked once whenever I rebooted the phone?
Why would Motorola include such a thing and not utilize it for more than merely a boot up indicator? Like I dont even get to see it come on while charging, it literally only blinks once during boot and that's it.
Click to expand...
Click to collapse
I know!
I don't know what triggers that light to come on. I even waited until the battery was at 6% and the light still never came on.
So, I updated the script above to make the light go full brightness if the battery is charging. The order matters, so if a notification comes in while charging, it'll "breath" the LED. Also, if the battery is full, then the light will turn off. Kind of telling you that it's time to unplug.
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
jorduino said:
I followed these steps and my touch screen stopped working. I had previously installed twrp already on it while trying to learn how to root it, and when i boot into fastboot it goed through twrp, i also used the boot.img file from lolinet, not sure which of these caused the issue. Interestingly though, the touch screen does work whilst in twrp. any suggestions on how to fix or what would be causing it? Phone does work with usb mouse over OTG
Click to expand...
Click to collapse
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
mario0318 said:
Are you absolutely sure you used the correct boot.img from an image version exactly matching your phone variant version?
Click to expand...
Click to collapse
Im not completely sure how to get the right file, but I think the first time it was the wrong one, but then when i got what i thought was the right one, it just didn't work at all and I had to recovery flash it. I had just updated so maybe the correct image wasn't available yet. Im going to try again though
Oh! Hello @latentspork. Thanks for your interest in my SystemRW project. I just came across this thread randomly...
I'm happy you got my script to work on your Motorola device by using the included sysrw_repair script
Please feel free to send me your log files from script folder. Thanks. It's useful for further development of the script
latentspork said:
The phone doesn't have enough space to complete 'lpmake' on the device and will end with an "Error 73" code. Running the "sysrw_repair_v1.32" tool on a Linux machine was a workaround because it pulls the '*.img" files to your local machine then combines them in to a single '.bin' file. But, before I did that, and because it's really annoying, I made some room to stop the phone from complaining about a lack of space:
Click to expand...
Click to collapse
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Yes that's true the included sysrw_repair script (Linux only) pulls the image files from the phone to your computer and attempts to run the same lpmake command with the same arguments that just failed with error 73 on the phone itself and now all of a sudden it just works in Linux. Go figure.
latentspork said:
(Still on the phone's adb)
Code:
rm ./img/super_original.bin
Click to expand...
Click to collapse
Why would you delete the super_original.bin ? That's your stock read-only super image which by default is automatically dumped by script for backup purposes in case you ever get a bootloop.
And if you launch the script by specifying a custom input value (in=x) like in your example above then you won't even have a super_original.bin file to begin with because script will skip the whole dumping of original super image process.
latentspork said:
This results in a new folder (img) with a rather large bin file (super_original.bin).
Click to expand...
Click to collapse
I think you mean super_fixed.bin
latentspork said:
Now it's time to flash the fixed bin file to the "super" partition:
Code:
cd /path/to/unzipped/sysrw_repair/dir/
fastboot flash super ./img/super_original.bin
fastboot reboot
Click to expand...
Click to collapse
Here in your instructions you are manually flashing the wrong file. Shouldn't you be flashing super_fixed.bin to your super partition?
Usually I only flash the super_original.bin to get back out of a bootloop...
latentspork said:
Now, on the Linux machine, I unzipped 'sysrw_repair_v1.32_proper.zip' then commented out line 39 (where it calls the "flash()" function) of the script (sysrw_repair.sh) because I wanted to flash the "super" partition myself.
Click to expand...
Click to collapse
See that's why I included that automatic flash() function in the repair script. Then you don't have to worry about manually flashing the wrong file to your super partition
Enjoy a fully read/write-able device!
Great news! New SystemRW version coming soon!
@lebigmac
I really appreciate the reply and the tool! It did work really well on my model (XT2093-4).
That's not 100% accurate. Lpmake error 73 means CAN'T_CREATE and has nothing to do with error 70 (insufficient space).
To this day I still don't know exactly what causes error 73 on some devices (mostly Motorola and others) but it looks like some kind of kernel panic. If anyone knows how to avoid this error 73 in Android please let me know! Thanks!
Click to expand...
Click to collapse
I only assumed that "Error 73" was caused by insufficient space, because the phone really did run out of space. I noticed that the phone was out of space because I got a home screen notification warning, asking me to free up space. I confirmed it with a "df -h" at the shell. Apparently, the OS takes up almost 15GB. When you add the ".img" files, there's only about 5GB left. There wasn't enough room to complete the ".bin" file. Maybe I could have used an SD card or something.
You're probably correct in that "Error 70" is the correct error for that, but on my phone, I never saw that error. I did notice that the tool was still trying to write data as the phone ran out of space, then it would throw the "Error 73". Maybe it didn't register the lack of space, or just an oddity with my model? No idea.
Why would you delete the super_original.bin ?
Click to expand...
Click to collapse
This is the file that was created when I initially ran the "./systemrw.sh" command on the phone. The result of running the command on the phone were several ".img" files and a very large "super_original.bin", but it was incomplete because the command threw an "Error 73". I was following your instructions, and I noticed that the output name of the file was "original" instead of "fixed". I probably could of outputted it to a new name to reduce confusion, but I didn't really care too much about the name as long as I had a working file.
I think you mean super_fixed.bin
...
Shouldn't you be flashing super_fixed.bin...
Click to expand...
Click to collapse
Normally, yes. But the Linux script also outputted the filename "super_original.bin". Again, as long as it worked, I was okay with it. The commands I used above were the exact commands that I ran at the time. I copied them from the terminal consoles I was using. So I don't know why it wasn't outputting the correct filename (again, I was following your instructions and was a little confused that the names came out differently - I just figured I was doing something wrong like not use the proper output command or something).
Then you don't have to worry about manually flashing the wrong file to your super partition...
Click to expand...
Click to collapse
I was really just being cautious because my previous phone broke and I didn't have a fallback.
But, at no point were there two bin files (original and fixed), so there wasn't much confusion. Where I originally had just ".img" files before running the script, I now had a single ".bin" file. I knew that was the file I needed.
But again, thank you for all the hard work on this tool! I was reading that it's worked on lots of different model phones, and it's always good to see the open source community doing things that help all kinds of people.
For moto notification for this phone at least use https://play.google.com/store/apps/details?id=br.com.itsmeton.motoledreborn or moto led reborn from the play store it just works
Hi, sorry. This can be removed. I put it in place because I was having issues with the xda app. For whatever reason, every time I tried to share this particular post, it would share a link for the post which I used originally, rather than the current post. I knew that if I commented I could get back here easily on my PC.
So what is the place holder for