[ROOT] Rooting the FireTV Cube and Pendant with FireFU - Fire TV Original Android Development

Today we’re excited to be bringing you something we’ve been working on for the last few months. Today, we’re introducing you to FireFU. FireFU is an exploit chain we’ve created to allow users to unlock (and root) their FireTV Cube and FireTV Pendant.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
https://blog.exploitee.rs/2018/rooting-the-firetv-cube-and-pendant-with-firefu/
Exploit package
This download is intended for users who are only seeking the binaries to perform the exploit.
https://download.exploitee.rs/file/amazon/FireFU/FireFU.tgz
Source Code
This is for the users who are needing to recompile the exploit or are just curious about the process.
https://gitlab.com/Exploiteers/FireFU_Exploit
https://gitlab.com/Exploiteers/amlogic_usb_mmc

This is nowhere near achievable for most XDA users though.

This is amazing. Thanks a lot.
I'm completely newbie but look forward testing this.
Can this exploit be eventually patched by Amazon so it's better to block updates if you don't use it immediately?
EDIT: I just read they can but I meant if they can patch with future updates so that the process is defeated and can't be used anymore.
Regards and congratulations.
Pino.

puppinoo said:
This is amazing. Thanks a lot.
I'm completely newbie but look forward testing this.
Can this exploit be eventually patched by Amazon so it's better to block updates if you don't use it immediately?
EDIT: I just read they can but I meant if they can patch with future updates so that the process is defeated and can't be used anymore.
Regards and congratulations.
Pino.
Click to expand...
Click to collapse
Yes the exploit is patchable. Amazon will probably patch it in the next firmware release. I'm not sure how long this exploit will last. Make sure to disable OTA update after you rooted it. This exploit also allow you to run custom roms too since it bypass the signature check in uboot SoC is similar to Odroid C2 board so you might able to run it image on the FireTV with little/no modifications.

xXhighpowerXx said:
Yes the exploit is patchable. Amazon will probably patch it in the next firmware release. I'm not sure how long this exploit will last. Make sure to disable OTA update after you rooted it. This exploit also allow you to run custom roms too since it bypass the signature check in uboot SoC is similar to Odroid C2 board so you might able to run it image on the FireTV with little/no modifications.
Click to expand...
Click to collapse
Thanks for precious info,
I already blocked URLs from Amazon on my LEDE router in dnsmasq.conf.
Really interesting. I have LibreElec installed on my Odroid C2 and the idea of installing a Linux distro on the pendant is also interesting.
BTW I stress my gratitude cause your work is amazing.
Pino.

xXhighpowerXx said:
.
Click to expand...
Click to collapse
Is the HDMI breakout adapter linked in the wiki the correct one that would be needed for this project?
https://www.amazon.com/Adapter-sign...rs-20&linkId=eca52d73a58d16cf24fb94f55bfd7ebe
From what I can tell from the pictures, that breakout board has a male adapter, but you would need a female adapter to plug the Fire TV into, correct?
Also, would it be possible to provide a little more detail on the command line steps needed? I'm a Linux novice so I'm having a little difficulty trying to figure out how to execute some of these steps. The exact commands for each step would be great. Thanks for your work!

AZImmortal said:
Is the HDMI breakout adapter linked in the wiki the correct one that would be needed for this project?
https://www.amazon.com/Adapter-sign...rs-20&linkId=eca52d73a58d16cf24fb94f55bfd7ebe
From what I can tell from the pictures, that breakout board has a male adapter, but you would need a female adapter to plug the Fire TV into, correct?
Click to expand...
Click to collapse
Correct. Something like this is what you need. This looks like the one used in the wiki.
IMO, putting the device into DFU mode is the bottleneck. You will have to set up the correct udev rules to get the Amlogic side recognized through the HDMI breakout.
(The Linux rooting commands are in the video.)

retyre said:
Correct. Something like this is what you need. This looks like the one used in the wiki.
IMO, putting the device into DFU mode is the bottleneck. You will have to set up the correct udev rules to get the Amlogic side recognized through the HDMI breakout.
(The Linux rooting commands are in the video.)
Click to expand...
Click to collapse
Thanks for confirming about the HDMI breakout. I found this on AliExpress for the cheapest option (but longest delivery time). Can you explain what you mean by the DFU mode bottleneck? I know that the Fire TV has to be put into DFU mode, but I wasn't sure if you meant that it's trickier than it seems (like maybe some computers don't have the right chipset or something along those lines). Also, I saw the video but it seems to start at step 7, which is basically where the easy parts of the process start, haha. I need more details on the earlier steps.

AZImmortal said:
Can you explain what you mean by the DFU mode bottleneck? I know that the Fire TV has to be put into DFU mode, but I wasn't sure if you meant that it's trickier than it seems (like maybe some computers don't have the right chipset or something along those lines).
Click to expand...
Click to collapse
There are so many variables here: genuine Arduino vs. counterfeit, quality of the HDMI breakout board, USB 3.0 vs. 2.0, Linux box with proper udev rules, ...
Take a look at something like this if you want to automate the last part (udev).

retyre said:
There are so many variables here: genuine Arduino vs. counterfeit, quality of the HDMI breakout board, USB 3.0 vs. 2.0, Linux box with proper udev rules, ...
Click to expand...
Click to collapse
I have an Arduino clone but I've never actually used it for real (other than flashing sketches to it to make sure that it works), but assuming that the clone is functional, then what kind of issues might prevent it from working for this project? I guess same question goes for the breakout board and USB 3.0 vs 2.0. Just trying to figure out what kind of obstacles I might encounter if I decide to try this.
retyre said:
Take a look at something like this if you want to automate the last part (udev).
Click to expand...
Click to collapse
This helps put things a little more together for me (at least I know which libusb I'd need to install). I'm still not sure that I understand how to execute step 1 or step 6 under the Rooting Process instructions though.
Thanks for the help so far.

AZImmortal said:
his helps put things a little more together for me (at least I know which libusb I'd need to install). I'm still not sure that I understand how to execute step 1 or step 6 under the Rooting Process instructions though.
Click to expand...
Click to collapse
Depending on the Linux distro, libusb may already be installed. Run dpkg -l libusb* to check.
Step 1: udev rules are set up in /etc/udev/rules.d/. You will have to create a file (e.g., 90-usb-serial.rules) with the information (usually, the subsystem, vendor-product attributes as mentioned in the wiki, name, symlink, etc.). Syntax varies by distro. You should test your rule with a less tricky device that's guaranteed to show up (e.g., a common peripheral) and see whether the name or symlink in the rule was picked up properly.
Step 6: In general, lsusb lists the USB devices connected to the Linux box. For example, if you connect just the Arduino and run lsusb, you should see the Due show up as, say, 2341:003d. If everything works as planned (i.e., the AFTV3 gets into DFU mode), you should see the correct device show up when you run lsusb (1b8e:c003). If it does not, you now have to check all the failure points: whether the sketch was flashed properly, whether the Arduino's or breakout's SCL and SDA pins are working properly, whether the USB port is the issue, whether the jumper wire or cable is the issue, and whether your udev rule was set up properly. In the event of an unsuccessful outcome (i.e., Amlogic doesn't show up in lsusb), isolating the issue can be a bear.
There's only one way to find out. Gather the paraphernalia, test it out, and post here!

retyre said:
Depending on the Linux distro, libusb may already be installed. Run dpkg -l libusb* to check.
Step 1: udev rules are set up in /etc/udev/rules.d/. You will have to create a file (e.g., 90-usb-serial.rules) with the information (usually, the subsystem, vendor-product attributes as mentioned in the wiki, name, symlink, etc.). Syntax varies by distro. You should test your rule with a less tricky device that's guaranteed to show up (e.g., a common peripheral) and see whether the name or symlink in the rule was picked up properly.
Step 6: In general, lsusb lists the USB devices connected to the Linux box. For example, if you connect just the Arduino and run lsusb, you should see the Due show up as, say, 2341:003d. If everything works as planned (i.e., the AFTV3 gets into DFU mode), you should see the correct device show up when you run lsusb (1b8e:c003). If it does not, you now have to check all the failure points: whether the sketch was flashed properly, whether the Arduino's or breakout's SCL and SDA pins are working properly, whether the USB port is the issue, whether the jumper wire or cable is the issue, and whether your udev rule was set up properly. In the event of an unsuccessful outcome (i.e., Amlogic doesn't show up in lsusb), isolating the issue can be a bear.
There's only one way to find out. Gather the paraphernalia, test it out, and post here!
Click to expand...
Click to collapse
Thanks, this helps a lot. I'll have to take a little time to experiment with my setup to see if I can figure out the syntax, but I'm definitely planning to buy the breakout board and finally put my Arduino clone to work. I'll probably have more questions when that time comes.

Finally got around to trying this. Works as described in the OP.
TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues.

retyre said:
Finally got around to trying this. Works as described in the OP.
TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues.
Click to expand...
Click to collapse
Great job. Waiting for my hdmi breakout to arrive so I can try. Can I ask you if you tried to downgrade or upgrade fw version? If not will it be easy to accomplish? I ask cause I blocked updates on my router since initial FW version and I don't want to risk now. But I'd like once rooted to upgrade to a version (possibly already rooted) with a feature added later to automatically switch framerate which my version actually lacks.
Regards.
Pino.

puppinoo said:
Can I ask you if you tried to downgrade or upgrade fw version? If not will it be easy to accomplish? I ask cause I blocked updates on my router since initial FW version and I don't want to risk now. But I'd like once rooted to upgrade to a version (possibly already rooted) with a feature added later to automatically switch framerate which my version actually lacks.
Click to expand...
Click to collapse
I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image?

retyre said:
I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image?
Click to expand...
Click to collapse
Glad it worked for you. Any chance you could show links to the board and Hdmi breakout? Thank you.
---------- Post added at 06:00 AM ---------- Previous post was at 05:56 AM ----------
Nevermind I found them in the Wiki.

retyre said:
Finally got around to trying this. Works as described in the OP.
TBH, this is not nearly as complicated as the usual hardware root method for FTV devices. If you know your way around Linux and can connect jumper wires, you should have no trouble with this. Please post here if you have issues.
Click to expand...
Click to collapse
I plan on trying this tonight. It's not clear in the instructions how to connect everything. Connect the arduino to a linux box via USB? Do I need to adb to enter the commands? I've got the breakout HDMI wired to the arduino, but then a standard HDMI cable from breakout to FireTV?

Let me clarify the first few steps in the OP (this is where I expect most of the challenge to be):
-- This is what you will need to begin: Arduino Due (this is what I have), HDMI breakout board (this is what I used because I have the pendant; if you have the cube, you will need a male HDMI as in the wiki; if you have the pendant, you can also use the male with a coupler), M/M jumper wire (this is what I used), and a Linux box (I have Ubuntu 16.04.5 LTS installed).
To install the Arduino IDE and upload the sketch, follow these steps in sequence:
1. Download the Arduino IDE. (If you use v1.6.1 or earlier, you don't have to install the Due board separately.) For Linux, download v1.6.1 from here. (Note: You don't have to do this in Linux. For Windows, use this.)
General note for Linux: It might just be easier to run everything as root (to sidestep permission issues): use sudo. As an example, sudo ./arduino to start the Arduino IDE instead of just ./arduino.
2. Connect the Due to your PC's USB port, install the Windows driver (located inside arduino-1.6.1-windows.zip; no driver needed for Linux), and choose the correct Board (Native or Programming depending on which is connected; I usually use the Programming port) and Port.
3. Download and extract the archive in the OP (FireFU.tgz).
4. Upload the sketch (hdmi_arduino.ino, from the archive) to the Due. To do this, open hdmi_arduino.ino from File and choose Upload from Sketch or just click the right-arrow. Pull up the separator at the bottom to make it easier to view the progress window.
6. Confirm that the upload and verification are successful.
You will need Linux from this point forward.
5. Check to see whether libusb is already installed:
Code:
dpkg -l libusb*
If not, install it:
Code:
sudo apt-get install libusb-1.0-0
6. Add the proper udev rules for Amlogic and fastboot as described in the OP's link. If you do not know how to manually add rules in /etc/udev/rules.d/, do the following:
-- To automate the udev rule for Amlogic (from here):
Code:
sudo apt-get install git
git clone https://github.com/khadas/utils
cd utils
./INSTALL
This will write the Amlogic rule (/etc/udev/rules.d/70-*). To add the fastboot rule, open the file (70-*) in an editor, copy-and-paste the line for Amlogic, and change the vendor and product id to match that for fastboot.
To manually add the udev rules, create a new file (say, 70-firetv3.rules) with the following in it:
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="1b8e", ATTR{idProduct}=="c003", MODE:="0666"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{idVendor}=="18d1", ATTR{idProduct}=="0d02", MODE:="0666"
-- Install fastboot and adb:
Code:
sudo apt-get install android-tools-adb android-tools-fastboot
7. Reboot for the rules to take effect.
8. Connect the following in order:
-- jumper wire to SCL, SDA, and GND on the Due ... and to the breakout board (as described in the wiki)
-- AFTV3's male HDMI to the breakout board's female HDMI (or the cube's female HDMI to the breakout board's male HDMI)
-- power to the Due (I use external power, but connecting it to USB power should work just as well)
-- micro USB to the AFTV3
-- other end of the micro USB to the Linux box's USB port
9. Check whether Amlogic, Inc. shows up:
Code:
lsusb
10. If it does, you're more than halfway there. If it does not, disconnect everything but the jumper wire and repeat step 8.

retyre said:
I updated to the latest version (6.2.5.5) before trying this. The wiki indicated it was tested on that version, so I saw no harm. If 6.2.5.5 has a feature not found in earlier versions, you should unblock the DNS on your router and let the device update to 6.2.5.5 before you try this. Without a public link to any of the update files for AFTV3, how are you planning to downgrade/upgrade or flash a prerooted image?
Click to expand...
Click to collapse
Thanks for advices. I didn't know updates URLs were still unknown. I just enabled updates and let it do its things. Now I'm on Build NS6255/1612 (hoping it's the original one and not some stealth tricky version just uploaded ). BTW I noticed the updates are incremental so it processed all the major ones one at a time. So maybe you could let it do until it reaches the version you like and after that you stop the updates. It's not a safe method I think (for them).
BTW Thanks again for advice. Stuill waiting for HDMI Breakout.

Arduino Documentation
retyre said:
-- power to the Due (I use external power, but connecting it to USB power should work just as well)
Click to expand...
Click to collapse
Documentation on the Arduino website states;
"The Arduino Due can be powered via the USB connector or with an external power supply. The power source is selected automatically.
External (non-USB) power can come either from an AC-to-DC adapter (wall-wart) or battery. The adapter can be connected by plugging a 2.1mm center-positive plug into the board's power jack.
Leads from a battery can be inserted in the Gnd and Vin pin headers of the POWER connector.
The board can operate on an external supply of 6 to 20 volts. If supplied with less than 7V, however, the 5V pin may supply less than five volts and the board may be unstable.
If using more than 12V, the voltage regulator may overheat and damage the board. The recommended range is 7 to 12 volts"

Related

Possible to access a USB flash drive

Does anyone know if it is possible to use the mini USB port to access an external hard drive, and/or a USB Flash drive/card reader.
You would need this: http://www.casecooler.com/usbab5pgech.html
for starters then you would need a program to know how to read the drive.
It is defintely possible just not sure if anyone has taken the time to do it.
It would be very useful. If someone is already interested?
my understanding is that it is not readily possible due to the device not being a USB host device.
Google it or search these forums (not just kaiser) and you will see a lot of talk about it.
jallenclark said:
You would need this: http://www.casecooler.com/usbab5pgech.html
for starters then you would need a program to know how to read the drive.
It is defintely possible just not sure if anyone has taken the time to do it.
Click to expand...
Click to collapse
Please do your research before use the phrase "It is defintely possible". For a start, when it can be connected doesnt mean it can be used. I can come out with an adapter which converts the USB-mini to a 240v-wall-plug, and it doesn't mean that you can charge your phone directly on a 240v AC power. It is like saying, if I were to use this, I'll be able to send my music from the phone to the car stereo.
The plug/socket designers came out with various plugs and sockets for a reason (i.e. so that people dont simply plug things together that does work).
Anyway, you should check on the topic 'usb host'.
I started working in this direction smtime ago but then got busy...hopefully if i get sm time in cming months, there might be smthing on the offer...

tools needed to unbrick G1

Hey guys,
Im looking to unbrick my G1 (no bootloader). I have asked some questions previously but haven't had the time to do anything besides that up to now.
I haven't had any luck here in India locating what I need with confidence, but today I happened across a helpful website.
Could anyone tell me if this is what Im looking for?
wiggler-clone
robokits.co.in/shop/index.php?main_page=product_info&cPath=12&products_id=240
pc-serial
robokits.co.in/shop/index.php?main_page=product_info&cPath=6_64&products_id=64
The wiggler look-a-like says its compatible with GCC OCD.
The pc-serial page offers a driver under the name of pl230.
I am hoping to be able to follow the unbrick page here: wiki.cyanogenmod.com/index.php?title=JTAG_for_Dream/Magic
Thanks
The unbrick process originated on this forum and was really moved along by member ezterry. You really ought to read the threads here in the dev section about this. They do tend to be long, but there is every bit of information you could possibly want to know about unbricking a dream.
http://forum.xda-developers.com/showpost.php?p=5911627&postcount=302
http://forum.xda-developers.com/showpost.php?p=5934885&postcount=6
thanks for the links. i am currently working through the multitude of posts.
Hey,
I am learning a lot and have what i think is my last issue before i order some parts. The pc-serial cable should be at 2.8 v but i only have access to converters that give 5 v output.
I first consulted the datasheet for the pl2303hx (link provided above) which states:
"RS-232 VDD. The RS-232 output signals (Pin 1 ~ Pin 3) are
designed for 5V, 3.3V or 3V operation. VDD_232 should be
connected to the same power level of the RS-232 interface.
(The RS-232 input signals are always 5V~3V tolerant.)"
which was a little confusing, so i consulted the vendor:
"It will output 5V if the jumper is shorted or else it will be 0V. But the unit is self powered and can accept 3.3V input and output levels.
which is self contradictory. but, from what i gather, the serial output will be the same as the usb input.
Lastly, from this google group discussion:
groups.google.com/group/android-platform/msg/bf66abf4515132fb
Someone states that they used an lm317 circuit to drop voltage to 2.8, and it seems like this is the route ill take.
Question is, which voltage do i control? I think if i drop usb vcc voltage i should be good?
I think i just going to buy it and see, whats 400 INR anyways (its like 8 bucks)
salsavirdi said:
"RS-232 VDD. The RS-232 output signals (Pin 1 ~ Pin 3) are
designed for 5V, 3.3V or 3V operation. VDD_232 should be
connected to the same power level of the RS-232 interface.
(The RS-232 input signals are always 5V~3V tolerant.)"
Click to expand...
Click to collapse
If you can't understand that, then you should find someone to assist you who does.
I suppose im being a overly paranoid, and would like some corroboration. Id really hate to fry my phone, im rather attached to it.

[Q] USB OTG MAP + More Memory (WIP)

Hello guys, im creating a minimal way to add up to 32GB's of memory to the nexus 7. Unfortunately im having a bit of a problem. You see the OTG cable i had was extremely mixed up from the inside. Meaning i had no way of finding out the map to the OTG and to the USB port. If anyone knows the map or knows where each item connects to please let me know.
If your wondering more about my little project, im creating a really minimal way of adding more memory to the nexus 7 (Specifically up to 32GB's). Im not going to make a guide just yet as i need to solder some cables together. But all i can tell you the afterproduct is going to be pretty cool.
Heres how it works.
I can't really say as its a bit complicated, and the proccess might be a little more complicated. I should have a guide if all goes well by the end of the week. All i can say is that it is going to involve the two parts shown below (I will tell you what they are once i get it all finished).
As i said if anyone can provide me a map to where each cable goes from the otg to the usb port. Thanks.
Full set of instructions (with pictures) here:
http://tech2.in.com/how-to/accessor...sb-otg-cable-for-an-android-smartphone/319982

Kindle Fire HD 7" eMMC access

Hi all, following on from kurohyou's excellent work on the KF2, I thought I would go about trying to develop a tutorial for unbricking a hardbricked Kindle Fire HD 7". This would be for the 2012 model, NOT the 2013.
A little bit of background on myself. I have always had a keen interest in electronics and studied microelectronics at college. I am pretty good at soldering etc even on small SMD devices, even more so now I have spent out on some decent kit (helping hands, rework station etc). Now I have decided to carry out this project as a summer hobby and hopefully I will get some support from you guys.
I have managed to piece together enough information that I think will enable me to complete this tutorial, with the exception of Linux, something that I am very new to and would need some assistance with.
I have seen common names among the forums when it comes to this type of subject, stunts513, soupmagnet, hashcode to name a few. I am hoping with the assistance of these members I can complete a comprehensive guide on unbricking a Kindle Fire HD 7", similar to http://forum.xda-developers.com/showthread.php?t=2415870
But please beware, IF YOU HAVE ANYTHING OTHER THAN A KINDLE FIRE HD 7" DO NOT USE THIS GUIDE!!
My main goal is to acquire a dead Kindle Fire HD 7" motherboard, as easily as possible. Unfortunately looking on eBay there seem to be very few from the UK and they are normally very expensive. I will keep looking but if anyone is willing to donate a non working or working motherboard for this cause I would be very grateful, just PM me if you can help. Just bear in mind due to the process it needs to go through, you will not get a working motherboard back, should you want it returned.
I aim to completely remove the eMMC from the motherboard and get exact pinout locations, as kurohyou did with his excellent KF2 guide. I will then use the same USB SD Card adaptor to see if the eMMC can even be read in the same way as the KF2. I have working knowledge of GParted in linux so I will also be using this to verify partition layouts and sizes. Once I have had any success in doing this I will update this post to reflect my progress.
There is my plan so far, if this has already been done, someone please tell me as I cannot find it anywhere.
overlode said:
Hi all, following on from kurohyou's excellent work on the KF2, I thought I would go about trying to develop a tutorial for unbricking a hardbricked Kindle Fire HD 7". This would be for the 2012 model, NOT the 2013.
A little bit of background on myself. I have always had a keen interest in electronics and studied microelectronics at college. I am pretty good at soldering etc even on small SMD devices, even more so now I have spent out on some decent kit (helping hands, rework station etc). Now I have decided to carry out this project as a summer hobby and hopefully I will get some support from you guys.
I have managed to piece together enough information that I think will enable me to complete this tutorial, with the exception of Linux, something that I am very new to and would need some assistance with.
I have seen common names among the forums when it comes to this type of subject, stunts513, soupmagnet, hashcode to name a few. I am hoping with the assistance of these members I can complete a comprehensive guide on unbricking a Kindle Fire HD 7", similar to http://forum.xda-developers.com/showthread.php?t=2415870
But please beware, IF YOU HAVE ANYTHING OTHER THAN A KINDLE FIRE HD 7" DO NOT USE THIS GUIDE!!
My main goal is to acquire a dead Kindle Fire HD 7" motherboard, as easily as possible. Unfortunately looking on eBay there seem to be very few from the UK and they are normally very expensive. I will keep looking but if anyone is willing to donate a non working or working motherboard for this cause I would be very grateful, just PM me if you can help. Just bear in mind due to the process it needs to go through, you will not get a working motherboard back, should you want it returned.
I aim to completely remove the eMMC from the motherboard and get exact pinout locations, as kurohyou did with his excellent KF2 guide. I will then use the same USB SD Card adaptor to see if the eMMC can even be read in the same way as the KF2. I have working knowledge of GParted in linux so I will also be using this to verify partition layouts and sizes. Once I have had any success in doing this I will update this post to reflect my progress.
There is my plan so far, if this has already been done, someone please tell me as I cannot find it anywhere.
Click to expand...
Click to collapse
Great job,will be useful to a lot of people if successful. And as for the support,we're all here to help ya
A lot of people spend time tinkering with Linux partitions,so getting support won't be as difficult as getting a dead motherboard,which is what worries me now. I would suggest you to buy a Fire HD,root it and leave the rest to your imagination (I would try to flash a Galaxy S3 Kernel using Odin or something )
Anyway,good luck!
I have managed to get myself a cheap Fire HD so just waiting for it to come in the post.As far as I can tell the Fire HD uses a very similar eMMC chip as the Fire 2 so I am hoping the partition structure is the same. If /dev/sdc2 is 256Kb and listed as bootloader then I think it should be straightforward to flash in the same way using the dd command.
Anyway, more updates to come
Update - I have now got a motherboard from a Kindle Fire HD 7", will go ahead and solder USB adaptor in the next few days and see what happens - more details to follow.
Ok, so I have opted to try and use a mini SD card adaptor for this project as it is very easy to kill a USB SD card adaptor if you get just one wiring point wrong, although this does have an increased risk of frying your USB port if you are VERY unlucky.
The SD card is wired like so -
https://www.dropbox.com/s/9zsrbevo97ifccj/SD%20Card%20wiring.JPG?dl=0
I drilled some very small holes close to the end of the mini SD internal connections to add stability to the wires. I used Valery_'s image to get the connection labels -
https://www.dropbox.com/s/fur0gxy72lox6yb/SD%20Card%20pinout.jpg?dl=0
For the VCC and VccQ wires, because there are two paired together it was not going to be possible to fit them into the SD card adaptor so I made a fly lead off of the main VCC wire -
https://www.dropbox.com/s/ocmw7p2dgsp4ia6/VCC%20fly%20lead.JPG?dl=0
Next I will be attempting to solder each wire onto the KFHD7 motherboard.
All done. I haven't cut the tracks that have been indicated in this picture as my PC recognises the eMMC under Windows 8 -
https://www.dropbox.com/s/1lyumxvw5h7agx4/Fire%20HD%20Pinout%20with%20VDDI.jpg?dl=0
So here is the motherboard soldered up -
https://www.dropbox.com/s/n30jpvbyhapoub7/Motherboard%20wiring%20KFHD7.JPG?dl=0
Update - after the eMMC was not recognised by Ubuntu I cut the 2 tracks in question, and still nothing. I am also now getting 0v from the card reader however the laptop still recognises SD cards inserted. I will acquire some more USB SD card adaptors and try again with those. More to follow.
Ok, a little frustrating but after checking and rechecking the solder points on the motherboard they are definitely correct, however Vcc, VccQ and Vss are still casting some doubt in my mind, considering that the VccQ and Vss points are both sides of capacitor 801 (C801). I am not 100% convinced that Vcc, VccQ and Vss have other points on the board. Reading the eMMC specifics here there are lots of Vcc, Vss and VccQ. I am not totally sure if there is a definite one that needs connecting
Any help on this would be much appreciated.
Ok, another post, sorry
Been doing some more research on the eMMC chip and I have found an official data sheet for the chip here
It seems that there are different pins for Vss and Vcc and I am wondering if this is causing the problem as I may be supplying power to the wrong part of the eMMC. Will see if R10 and T10 on the schematic lead to anywhere else and negate the need to cut the tracks, something which I still don't quite fully understand. Edit - R10 (Vss) does not seem to have a place on the board
As you can see from the following table it lists all the necessary locations for applying power to modify the eMMC -
https://www.dropbox.com/s/a7f299p492gf7qe/eMMC%20Pinout.jpg
VDDF is Vcc and VDD is VccQ .
I will check out these two pins later on and see where they lead on the board.
More to follow...
overlode said:
Ok, a little frustrating but after checking and rechecking the solder points on the motherboard they are definitely correct, however Vcc, VccQ and Vss are still casting some doubt in my mind, considering that the VccQ and Vss points are both sides of capacitor 801 (C801). I am not 100% convinced that Vcc, VccQ and Vss have other points on the board. Reading the eMMC specifics here there are lots of Vcc, Vss and VccQ. I am not totally sure if there is a definite one that needs connecting
Any help on this would be much appreciated.
Click to expand...
Click to collapse
http://forum.xda-developers.com/attachment.php?attachmentid=2784284&d=1402079403
http://forum.xda-developers.com/showthread.php?t=2775022
good luck
Valery_ said:
http://forum.xda-developers.com/attachment.php?attachmentid=2784284&d=1402079403
http://forum.xda-developers.com/showthread.php?t=2775022
good luck
Click to expand...
Click to collapse
Ok, I have put your image side by side with your top image and colour coded the points (Just bear in mind the right hand image is a mirror image of the BGA). No matter how I look at it, everything is correct and all Vcc, VccQ and Vss points are interconnected so I do not see how it is not working. Can you explain to me the need for cutting the tracks in your original image and what the version 1 and version 2 mean please?
How have you got on with this? The closest I have been is Windows 8 detecting something but Ubuntu doesn't see anything.
Cheers
overlode said:
Can you explain to me the need for cutting the tracks in your original image and what the version 1 and version 2 mean please?
Click to expand...
Click to collapse
Cutting the tracks had two goals: 1. to decrease power of supply from cardreader, 2. to protect the chips which are supplying 1.8 V
Additionally I used diode Schottky to decrease voltage to 1.6 V
There were impulses CMD and CLK, but there was a problem with signals Data0 - Data3. Level on these pinouts didn't change, was about 1 V
Supposedly the processor blocked Data0..3
I tried to connect cardreader with signal Reset on the motherboard, but there weren't Data0..3
So both in the case with 1.8 V and in the case with 3.3 V on the contact VccQ, there was a voltage about 1 V on Data0..3
I think there is a possibility of access to eMMC if OMAP is blocked and then it will make Data0..3 free (third output state Z)
Valery_ said:
Cutting the tracks had two goals: 1. to decrease power of supply from cardreader, 2. to protect the chips which are supplying 1.8 V
Additionally I used diode Shotky to decrease voltage to 1.6 V
There were impulses CMD and CLK, but there was a problem with signals Data0 - Data3. Level on these pinouts didn't change, was about 1 V
Supposedly the processor blocked Data0..3
I tried to connect cardreader with signal Reset on the motherboard, but there weren't Data0..3
So both in the case with 1.8 V and in the case with 3.3 V on the contact VccQ, there was a voltage about 1 V on Data0..3
I think there is a possibility of access to eMMC if OMAP is blocked and then it will make Data0..3 free (third output state Z)
Click to expand...
Click to collapse
I can't understand why they changed it so radically just for the KFHD 7" as the eMMC on the KF2 and the KFHD 8.9" are both easily accessible. It seems weird how they would use the OMAP to block it just on this model. Looking at the datasheet, are we missing something with VDDI, there is a suggestion to ground it via a 0.1 micro farad capacitor. Any thoughts on this?
VDDi Connections
The VDDi (K2) ball must only be connected to an external capacitor that is connected to VSS. This signal may not be left floating. The capacitor’s specifications and its placement instructions are detailed below.
The capacitor is part of an internal voltage regulator that provides power to the controller.
Caution: Failure to follow the guidelines below, or connecting the VDDi ball to any external signal or power supply, may cause the device to malfunction.
The trace requirements for the VDDi (K2) ball to the capacitor are as follows:
• Resistance: <2 ohm
• Inductance: <5 nH
The capacitor requirements are as follows:
• Capacitance: >=0.1 uF
• Voltage Rating: >=6.3 V
• Dielectric: X7R or X5R
Click to expand...
Click to collapse
Thanks to RolF2 from this post
SanDisk iNAND has three power domains assigned to VCCQ, VCC and VDDi, as shown in Table
10.
Table 10 - Power Domains
Pin Power Domain Comments
Supported voltage ranges:
High Voltage Region: 3.3V (nominal)
VCCQ Host Interface
Low Voltage Region: 1.8V (nominal)
VCC Memory Supported voltage range:
High Voltage Region: 3.3V (nominal)
VDDi Internal VDDi is the internal regulator connection to an
external decoupling capacitor.
Page 25+26 of this document explains it more. Looks like we may only need to ground VDDI with a 0.1uf capacitor. From what I can see on the motherboard all other connections already have capacitors grounding Vcc and VccQ.
Found the connection for VDDI -
https://www.dropbox.com/s/gzk11dywlmxzcmk/Fire%20HD%20Pinout%20with%20VDDI.jpg
overlode said:
Found the connection for VDDI -
https://www.dropbox.com/s/gzk11dywlmxzcmk/Fire%20HD%20Pinout%20with%20VDDI.jpg
Click to expand...
Click to collapse
I think that this will not resolve the problem. Connection of capacitor is strange. But this finding is a plus in the investigation.
Valery_ said:
I think that this will not resolve the problem. Connection of capacitor is strange. But this finding is a plus in the investigation.
Click to expand...
Click to collapse
The thing that confuses me is the fact that there are no other connections to the BGA array that come from a different source, all Vcc, VccQ and Vss connections are linked and already grounded with capacitors so you should be able to apply power to anywhere of these points. The fact that it is stated that this particular chip has 3 power domains, not 2 like the previous chips is encouraging.
As for your comment about the OMAP blocking access to the eMMC I don't think this is the case as the chip is used in a lot of nand flash technologies that do not have any OMAP device paired with them.
As soon as I get my next motherboard I am going to try the VDDI connection, it cannot do any harm as it controls internal voltage to the eMMC.
I will keep digging but I am pretty sure there is nothing more we have missed as I have been over the data sheet again and again.
Ok, I understand VDDI now, you don't need to touch this connection as it is used internally to regulate chip voltage. So back to the drawing board
Ok, I am going to make a simple voltage regulator to go inline with my USB card reader to make sure input voltage to the eMMC is 3.3v as I suspect over voltage may be causing a malfunction within the internal voltage stabiliser circuit of the eMMC. It seems over voltage triggers complete shutdown of the eMMC using internal diodes so this may explain the 1v or less output from the DAT pins.
Valery_, if I make sure input voltage is 3.3v then that would dismiss the need to cut the tracks yes?
Ok, I think this project has to be put on hold again. No matter what I try Ubuntu will not recognise the partitions of the eMMC even though the SD card adaptor flashes and then stops flashing as if being read properly. Connecting to VDDI fries your card reader instantly so do not try this!!
I just cannot see what we are missing and why this motherboard is so different from the KF2 yet not?
There has to be some way to gain access to the eMMC as the chip is so commonly used with other devices.
I will continue this project if I make any break through or if someone finds out something that we may be missing.
For the meantime I will continue with the KF2 unbricking as that is going rather well for me at the moment.
Reserved
overlode said:
Reserved
Click to expand...
Click to collapse
Maybe this information will be useful:
The MAX3002 accept VL voltages from +1.2V to +5.5V and VCC voltages from +1.65V to +5.5V, making them ideal for data transfer between low-voltage ASICs/PLDs and higher voltage systems.
Valery_ said:
Maybe this information will be useful:
The MAX3002 accept VL voltages from +1.2V to +5.5V and VCC voltages from +1.65V to +5.5V, making them ideal for data transfer between low-voltage ASICs/PLDs and higher voltage systems.
Click to expand...
Click to collapse
Isn't this just what we have been supplying though? My simple voltage regulator supplied 3.3v
picture not load
overlode said:
Ok, so I have opted to try and use a mini SD card adaptor for this project as it is very easy to kill a USB SD card adaptor if you get just one wiring point wrong, although this does have an increased risk of frying your USB port if you are VERY unlucky.
The SD card is wired like so -
Update - after the eMMC was not recognised by Ubuntu I cut the 2 tracks in question, and still nothing. I am also now getting 0v from the card reader however the laptop still recognises SD cards inserted. I will acquire some more USB SD card adaptors and try again with those. More to follow.
Click to expand...
Click to collapse
can you fix those picture? . it was prolem with dropbox
Thanks
kero2005 said:
can you fix those picture? . it was prolem with dropbox
Thanks
Click to expand...
Click to collapse
Pictures fixed, for what it's worth

[KERNEL] (Patch) USB OTG (host mode) + simultaneous charging!

(I really struggled with where to post this. Although much work and effort went into debugging unique Z5-specific issues, this is based on prior work so I put it here instead of in "original"; also, I would be very surprised if this didn't apply cleanly and work across the entire Z5 family, not just the Compact, but it might not apply beyond the Z5 so it doesn't make sense to put it in the cross-platform forum, which means I had to pick ONE Z5 family forum to post in. I've only tested on Compact, so I guess it goes here for now.)
I am attaching a set of kernel patches that will allow Z5 users to put their phone's USB port into host mode while simultaneously also allowing the phone to take a charge. In this scenario, the USB device(s) connected to the phone are not getting power from the phone like they normally would in a standard "OTG" scenario, but are sharing with the phone whatever power source is being used to charge the phone.
Acknowledgements:
HUGE thanks...
...to @ziddey for his original patch that he developed for the Nexus 4 which was the inspiration behind all of this,
...to @sollapse for being the first to successfully implement ACA support in the DWC3 driver,
...and to @Phoenix Wright for further refining that code
The patches presented here are based largely off of Phoenix Wright's work.
Background:
I used a Nexus 4 for a long time, and grew accustomed to being able to do this with my Nexus thanks to @ziddey's extremely clever hack. (My personal use-case is a phone dock in my car which both charges the phone and connects it to a USB sound card, which in turn is fed into the auxiliary input of my car's stereo head unit.) In fact, the modification ziddey came up with was both so effective and minimally-invasive that the changes were -- until relatively recently -- easy to apply to just about any Snapdragon-based device (even ones with fully-functioning OTG support, which the Nexus 4 didn'thave), since many of them shared a common USB core, and thus also shared drivers.
I was disappointed to discover upon receiving my Z5 Compact that although for some odd reason that venerable old Snapdragon USB driver was enabled in Sony's kernel's build .config, it wasn't actually being used by the hardware...I patched up the kernel, compiled it, flashed it, and the behavior of the USB port didn't change. Turns out all of the more recent Snapdragons use a new USB 3/SuperSpeed-capable core by Synopsys, part of their DesignWare series, and this core uses an entirely different driver called DWC3. And unlike the older driver, this new one does not implement support for so-called USB "accessory charging adapters" or ACAs (typically vendor-proprietary powered USB hubs that do exactly what we want: charge the phone while putting it in host mode), so in-built support for ACAs couldn't be exploited in the DWC3 driver the way that it had been in the old driver.
Fortunately, @sollapse rose to meet the challenge and whipped up some basic ACA support for the DWC3 driver included in the kernel source tree for the OnePlus One. I took what was largely a re-write of this, done by @Phoenix Wright, and essentially ported that version over to the Z5 kernel while also making some other changes and additions along the way.
Use:
Disclaimer: I cannot be held responsible if any harm should come to you or your phone on account of using these software modifications.
This was developed and tested against the Sony copyleft sources for the kernel that shipped with the last release of Lollipop for the Z5 series (32.0.A.6.200). I plan to also work on versions for the Marshmallow and Nougat kernel releases as well, but wanted to start with something as close to what I was porting from as possible and just deal with one variable at a time. Chances are good that very little changed in the USB drivers in later Z5 kernels anyway. I have also to-date only tried to apply this to an otherwise stock Sony source tree, and running on the stock Sony Lollipop ROM.
This isn't how ACAs are strictly meant to work on a device that officially supports them, but when it comes to this patch, to enable or disable "ACA mode", you need to either pass a certain parameter (aca_enable, should be set to 'Y') to the driver (dwc3) at initialization (during boot / on the kernel command line, so 'dwc3.aca_enable=Y'), or toggle the parameter after boot using sysfs (e.g. 'echo N > /sys/module/dwc3/parameters/aca_enable'). For write access to sysfs, you have to be root, so keep that in mind if you have a requirement to be able to toggle this on and off without a reboot.
Enabling ACA mode merely changes the behavior of the driver when the ID pin/pin 5 on the micro-USB cable is grounded (OTG cable), which indicates to the phone that it should switch to host mode. With ACA mode enabled, it basically doesn't engage the USB host voltage bus regulator and instead activates the battery charging circuitry; however, just like "normal" USB host mode, it still requires an actual OTG cable to work, UNLIKE ziddey's original patch. What this means is that if you want to plug, say, a thumb drive into your phone without having to also supply an external power source, you need to set 'aca_enable' back to 'N' first before this will work again.
Sometimes it is not possible to use an OTG cable in certain situations; for example, there is no way I am going to first cut out and then cut open the non-OTG micro-USB plug from my $80 Proclip car mount in order to turn it into a proper OTG cable. For these situations, ziddey's ingenious idea -- borne out of necessity by the broken ID_GND detection on the Nexus 4 -- of triggering host mode based on the type of charging adapter detected by the phone is extremely useful, and so I implemented a similar feature: by additionally setting 'prop_chg_aca_enable' to 'Y', the driver will switch to USB host mode if a so-called "proprietary" charging source is detected (which is apparently what the phone interprets the voltage injected with a USB Y-cable as).
'prop_chg_aca_enable' will have no effect if 'aca_enable' is not also toggled on. I split it out into a separate option, though, because for reasons I haven't had the time to hunt down yet, the charger detection toggle seems (based on extremely limited testing) to make the use of an OTG cable less reliable...sometimes it works, sometimes it engages the host mode but not the battery charger, sometimes it does neither. So if you already use an OTG cable with your particular set-up, I recommend you leave 'prop_chg_aca_enable' off.
Finally, as most of you surely know, the Z5 series (and the Z3+/Z4 before it) introduced a new coverless micro-USB port along with a new requirement that you the user must manually initiate a scan for attached USB gadgets in order for the port to switch over to host mode; presumably they did this so that they could keep the IP68 water ingress protection rating despite the change to a coverless port. Miraculously, when aca_enable is on, because the phone is accepting a charge instead of delivering power in this scenario, there is (in theory) no additional risk from water exposure in this mode and yet you also do NOT need to hit "Detect USB Device" on your phone before you can use the USB device...as long as both external power and a USB device are present on the cable at the moment you plug it in. If you don't have a USB device plugged into your Y-cable, only power, then the device will not be detected later. If you have a need to work around this, you can set 'no_device_timeout_enable' to 'N', which will keep the host controller on-line and engaged for as long as you have a powered OTG cable plugged in.
If you want to *really* live life on the edge, you can also set the 'force_id_polling_on' parameter of the 'qpnp_smbcharger_extension' driver to 'Y' in order to completely disable the need for tapping on "Detect USB Devices" for "normal" OTG mode.
Oh, one more thing I forgot: if you are supplying power through an OTG cable (with ID pin grounded), then you need to set 'dwc3_msm.force_float_on_bsv=N' in order to work around a change Sony made to the driver that causes it to treat powered OTG cables as if they are non-OTG. I don't know why they did this (perhaps just to further reduce the risk of water damage on account of the open port under certain circumstances?), but I added a toggle that bypasses their change.
In summary, here are all of the various driver/module options I have decided to supply to my own kernel at boot time; at a minimum #1 and #4 are mandatory when using a OTG cable and #4 and #5 are mandatory when using a non-OTG cable:
dwc3_msm.force_float_on_bsv=N
(disables Sony "innovation" that prevents a powered OTG cable from switching controller into host mode)
qpnp_smbcharger_extension.force_id_polling_on=Y
(disables the need for "Detect USB Devices" under normal OTG use -- NOTE this could reduce the integrity of the water protection!! Use with caution!)
dwc3.no_device_timeout_enable=N
(disables host mode timeout in the event controller does not detect a device)
dwc3.aca_enable=Y
(enables the new "ACA mode" which allows for the exclusive use of powered OTG cables at the expense of normal OTG use)
dwc3.prop_chg_aca_enable=Y
(additionally allows USB host mode to be triggered by a non-OTG powered Y-cable that also has a USB device attached)
I hope others find this useful, while at the same time I also hope that our USB-C future will eventually end the need for us to dabble in such hackery.
-- Nathan
Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there: https://forum.xda-developers.com/showpost.php?p=64784909&postcount=8403 (I think there was an issue with kernel panics in certain circumstances which was fixed by a msleep(), maybe something else too).
Phoenix Wright said:
Nice work! Just to let you know, I made some final changes to the patch before submitting it to SultanXDA there:
Click to expand...
Click to collapse
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan
nlra said:
Thanks! My version of the patch was based off of the final post you made to sollapse's thread, which I'll call your patch #1. I just downloaded the version of the patch you linked to (#2), and diff'd a copy of the Sultan dwc3_otg.c patched with #1 against a copy patched with #2, and this is the only difference I found:
Code:
@@ -1048,6 +1044,11 @@
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
+ /* If B_SESS_VLD went off already, proceed to enable host */
+ if (test_bit(B_SESS_VLD, &dotg->inputs)) {
+ work = 1;
+ break;
+ }
/* Ensure there's no charger before suspending */
msleep(200);
if (!dotg->ext_xceiv->bsv)
pm_runtime_put_sync(phy->dev);
} else {
...and I had actually added a single line to that 'if' block already that set work=1 indiscriminately (which you can see in my patch). (As I recall, more often than not after hitting the A_IDLE case, there would be no additional external event to trigger the workqueue again after state was set to A_HOST, which meant that OTG_STATE_A_HOST case block would never actually get executed.) It probably would be more correct for me to test for BSV before forcing another workqueue loop, so I'll try making that change and re-testing. I haven't experienced any ill effects in day-to-day use, though.
Is there a reason why you are checking BSV state twice and in two different ways here (checking the B_SESS_VLD bit in dotg.inputs, and also directly checking dotg.ext_xceiv.bsv)? Are you checking dotg.ext_xceiv.bsv directly because there is a chance that dwc3_ext_event_notify() hasn't been called by the transceiver driver yet for some reason to update the state machine inputs? What about simplifying things here down to a single test, like so?:
Code:
phy->state = OTG_STATE_A_HOST;
/* Wait, as host must be enabled after power */
if (ID_MODE == ID_A) {
acaenabled = 0;
/* If B_SESS_VLD went off already, proceed to enable host */
if (test_bit(B_SESS_VLD, &dotg->inputs)) {
work = 1;
break;
} else {
/* Ensure there's no charger before suspending */
msleep(200);
pm_runtime_put_sync(phy->dev);
}
} else {
(or substitute in "if (dotg->ext_xceiv->bsv)" for the call to test_bit() if you think that is more appropriate for some reason?)
Thanks again,
-- Nathan
Click to expand...
Click to collapse
A lot of time has passed, but if I'm not mistaken, on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.
Phoenix Wright said:
[...] on the OPO, in some circumstances (II think if you removed the otg-y cable quickly or something like that), dwc3_ext_event_notify() would be called (to signal that power was removed) after the device was suspended leading to a kernel panic (I did a lot of tests with the "extreme" cases, like removing the cables quickly). So the msleep is to make sure that it didn't happen (in such cases, the device is then suspended by the next invocation of that state machine if I'm not mistaken, in the "case OTG_STATE_A_HOST:", in the part below the "/* Charger has been removed */" comment). So the changes you proposed wouldn't work, as the msleep + direct check are there to tell if the state machine is going to be called again just after that.
Click to expand...
Click to collapse
Gotcha, thanks; makes perfect sense. I'm not sure that the same thing is necessarily happening on the Z5...it uses a different battery charge controller than the 1+1 and in fact I ripped out a lot of the 1+1-specific workarounds when preparing my version of the patch. (I still need to do more testing, but in fact I'd say there are some instances where BSV is actually not being detected properly on this platform, which could explain my initial findings...there is a debugfs file exposed where you can check current BSV detection state, but even when phone is getting power it almost always shows "0".)
Nevertheless, I ran some tests:
1. With work=1 set explicitly every time (my addition to your code for my original version of the path), everything with a powered OTG cable and aca_enable=Y worked fine for me.
2. With that removed, it almost never engaged the battery charger, though host mode almost always kicked in.
3. After adding work=1 only if B_SESS_VLD bit was set, working functionality for powered OTG cables was restored (again, as long as my new prop_chg_aca_enable=N).
So I have updated the patch to check for that bit before forcing another workqueue loop, which I believe is "more correct".
Thanks again,
-- Nathan
Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.
tarsonis666 said:
Hm sorry I gonna sound like a total noob but everyone starts out somewhere. The *.diff file is for a ROM to be compiled? Its not supposed to be flashed with TWRP or such? Or is it just a file to be overwritten in the system files?
Just today I made myself an OTG cable with charging function and was scratching my head why it's not charging.
Click to expand...
Click to collapse
You are correct, this file is used to patch the kernel (not the ROM) source and then compile the kernel binaries.
Files you flash in TWRP usually end in ".zip" or ".img".
// DevelLevel
Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.
Adamell0 said:
Hey. Has anyone compiled a kernel with this patch applied? I'm a total noob when it comes to Linux and I'm really struggling with compiling a kernel, let alone applying patches to it . I would be really grateful if someone could attach a ready kernel image.
Click to expand...
Click to collapse
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.
nlra said:
Sorry, haven't hung out around here in a while...
What specific phone model do you have, and what firmware version are you using? If it is something in the Z5 family (regular/Compact/Premium) and otherwise stock Sony firmware, let me know which model and f/w version and I can probably whip something up.
If it's some other phone model, no guarantees. If Z5 with third-party AOSP-based firmware, also no guarantees but more likely than not may be possible.
Click to expand...
Click to collapse
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.
Adamell0 said:
Thanks for your response. I have Sony Xperia Z5 Compact model E5823 with Android 7.1.1., kernel version is 3.10.84-perf-g99119bc.
Click to expand...
Click to collapse
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.
nlra said:
Gotcha; I should be able to help with this, but what I need is the Sony ROM version, not the kernel version. Can I assume that you're running the latest (last) version of 7.1.1 released for the Z5c, 32.4.A.1.54? (At this point I'd be surprised if you were running anything older, but I'm going to be pulling the kernel sources direct from Sony for the firmware version that matches what you're running, which is why I need to be sure. In all likelihood, though, even if you are running slightly older ROM, since you're already on 7.1.1, the odds of a kernel built from the latest sources not working with your ROM are likely slim-to-none.)
And you already have the bootloader unlocked on your Z5c, yes?
EDIT: -g99119bc is what is shown as the suffix on the kernel version from 32.4.A.1.54 in screenshots of "About phone" all over the internet for the Z5 series, so I'm moving forward with this assumption.
Click to expand...
Click to collapse
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.
Adamell0 said:
I'm running exactly the version you mentioned: 32.4.A.1.54. As far as unlocking bootloader goes it is still on my "to do" list, but for that I assume that the tutorial on Sony website will suffice.
Click to expand...
Click to collapse
I would advise you to not just blindly unlock the bootloader on your Z5c if you haven't done so already. Doing so on the Z5c is irreversible and has permanent consequences unless you prepare in advance / take necessary precautions. (Side note: it's because of stuff like this that I've learned to always search and read up on any potential pitfalls when it comes to doing bootloader unlocks on specific models of phones before just jumping right in!!! Sony is not entirely forthcoming in their warnings on their site about what you lose when you unlock!)
The "necessary precautions" involve backing up what is called the TA partition of the phone before unlocking the bootloader. When you unlock the bootloader, the phone zeroes out all of the DRM keys stored in this sector that are unique to your particular phone (not phone model, your specific unit! if you lose them you can never get them back! and you can't take copies of keys from another Z5c and flash them to your phone unless you want a permanent brick that will never power back on again!). So best to back this up beforehand, both so that you have the option of returning to COMPLETE stock in the future if you so desire (re-lock bootloader, etc.), but also so that you can reflash the keys back to TA while retaining the unlocked bootloader, having the best of both worlds.
Unfortunately, this is a bit of a pain to do, admittedly, since TA partition is normally heavily guarded. It's supposed to be impossible to access, but a bug in older firmwares can be exploited to gain access to it even with a locked bootloader. So this means you have to actually downgrade back to Android 6.0 Marshmallow *just temporarily*, long enough to make a backup of the TA partition. After that, you can re-upgrade back to 7.1 Nougat and proceed with bootloader unlock.
If you decide not to go to the trouble, that's fine, but at least you will be making an informed decision in advance, rather than only finding out about what you lost after it's gone, robbing you of choice.
Link to TA backup utility: https://forum.xda-developers.com/t/universal-dirtycow-based-ta-backup-v2.3514236/
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.
nlra said:
To downgrade, you'll need to get yourself a copy of Flashtool and a Sony Z5c Marshmallow ROM file; I can provide links to these in a PM if you want to go down this path. The firmware download is nearly 3 gigs, just FYI.
Click to expand...
Click to collapse
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .
Adamell0 said:
Please PM me those links if it's not a problem, while the phone is just one of many laying in my drawers having options is always a good thing .
Click to expand...
Click to collapse
Check your PM for links and general overview of how to accomplish downgrade/TA backup/upgrade.
Your kernel is also ready, tested, and attached.
Note that this is just the raw kernel with OTG patches included. If you end up backing your TA partition up, you will want to patch this kernel image with the latest version of rootkernel (which adds additional patches to restore functionality lost after bootloader unlock, but are not patches that require a kernel re-compile) and then flash that version.
Also, just in case it wasn't clear in the original post, these patches do not allow you to seamlessly use both traditional non-powered OTG as well as powered OTG...it's one or the other. Non-powered OTG will stop working, and OTG/host mode will only be possible if a power source is also applied. It is possible to disable the powered OTG mode and revert to regular non-powered mode, but it has to be done with a terminal command, and it will return back to powered-only OTG mode after the phone is rebooted.

Categories

Resources