Database Users

Developing methods to recover bricks without JTAG

I have not seen anything in the Captivate forums about UART, I2C, or really anything other then Download Mode/Recovery Mode. We could use some developers to help with this project. It's an interesting combination of hardware, software, and inter-chip communications protocols...
I think everyone knows about the 301Kohm resistor between pins 4 and 5. Did you know about the 150Kohm or the 619Kohm resistors? How about the middle battery pin?
Watch this video.
Resources
Users
One-Click Unbrick was relesed This will unbrick softbricked phones http://forum.xda-developers.com/showthread.php?t=1153310
Kernel developers
UART Kernel debug log AND shell terminal (like adb shell without adb active) On the captivate you can get into the SBL prompt, then type
Code:
printenv
setenv SWITCH_SEL 6543
printenv
saveenv
This changes the SWITCH_SEL value from 65 to 6543 and enables extra output. This will give you a kernel debug output and drop you into a shell prompt.
Developers
bootloader source code For a simlilar samsung device: http://forum.xda-developers.com/showthread.php?t=1018862&page=68
here is the iROM,: I've rehosted it here: http://teamkomin.googlecode.com/svn-history/r75/branches/IROMcode/bootdumps.rar
here: http://www.mediafire.com/file/c9bg6gyk1cuapsz/bootdumps.rar
and here: ftp://adamoutler.dyndns.org/bootdumps.rar
we need help deciphering it. We think the annotations may be wrong. This is the unchangable code in the first few blocks of memory. There must be a way to communicate with this.
Hardware guys
S5PC110 processor datasheethttp://www.mediafire.com/file/3znisgfm3amxgpj/S5PC110_EVT1_UM10.pdf This is the processor in our phones. This documents everything which is capable natively with the processor. It is 2425 pages long.. I read through it and added some notes here.. This is the meat of the manual: http://forum.xda-developers.com/showthread.php?t=1018862&page=51
FSA9280A datasheet http://www.mediafire.com/?d4e21efhuktctcb This is the first time we've had access to this manual. Our phones use the FSA9480A chip, this chip is functionally the same. The datasheet here describes all functions available to the USB switching device. From the FSA9280 datasheet we've located all resistor values. http://forum.xda-developers.com/showpost.php?p=14408452&postcount=62
All
The All-In-One GalaxyS HackPack hardware, software and documentation on our phones http://forum.xda-developers.com/showthread.php?t=1111866
It has been revealed from a source which is not to be mentioned that the OM pins/registers are fixed and cannot be changed on the processor without removing the processor from the device or making some hardware modifications.
Here's some must read threads.
Fun with resistors:http://forum.xda-developers.com/showthread.php?t=820275 This thread shows all known resistor values
Lets save some bricks:http://forum.xda-developers.com/showthread.php?t=1018862 This thread deals with ways to revive phones from the dead. We are hacking the heck out of them in here.
Development platform booting from MMC http://hi.baidu.com/j2h3344/blog/item/85740dfc0be35951d7887dd5.html This is the platform used to develop our phones. We need to find these OM bits, or access them somehow.
the middle battery pin http://forum.xda-developers.com/showpost.php?p=13448859&postcount=253 This may be the answer. We could use some help in this area.
Download the GalaxyS Hack Pack here: http://forum.xda-developers.com/show....php?t=1111866
Known Causes of hard Bricking
1. PBL(Primitive bootloader) and SBL(secondary bootloader) were not designed for the phone
2. Mismatched PBL/SBL combination
3. SBL does not fit in the Partition information table, or location does not match Partition Information Table
4. Bad USB cables
5. power loss
6. Damaged PBL/SBL
--Theoretical--
7. Something known as Secondary Bootloader Rotation may be to blame for improper bootloaders sometimes. Apparently when flashing, the SBL and SBL2 blocks may switch places. In this case you may have the proper PBL, but the SBL is not proper for the device.
Hardware Used
If you're looking to help, you'll need some development hardware. I use an Arduino Mega. http://www.bizoner.com/arduino-atme...e-p-180.html?zenid=9mg23h688slfjgh88910o5jfd2 This is a programmable interface. You can use this code to talk to the phone. http://forum.xda-developers.com/showpost.php?p=13351363&postcount=223
Here's some plans for a communications adapter http://forum.xda-developers.com/showthread.php?t=925034
The plan
If we can get into a bricked phone via UART or the i2C bus, or the USB bus, or any other method available to U301, we can corrupt the PBL(boot.bin) in the OneNand which will cause the processor to search for a PBL and SBL on USB, UART and MMC.
If we can locate an additional communications port somewhere on the phone we can change or corrupt the code running in memory and then cause the processor to reboot into USB or UART mode.
So far we know of UART only and have eliminated that as a solution on it's own.
{
"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"
}
Using SBL, it is very likely possiblity that Windows7 phone or iOS, or ubuntu could be ported over.... Basically, full control.
Why you should help
We've been working on ways to recover these phones for months now. We're comming to an end. We need massive amounts of testing to figure out this last bit.
This is a call to duty. Every developer who has ever released a boot.bin, SBL.bin, param.ifs or a PIT with their release needs to be a part of this. Every member who has ever bricked a phone while using one of the many tools which are designed to upgrade your phone can help. Anyone who wants to feel secure while flashing their phone should put some effort into this because it's expensive and requires superhuman soldering to JTAG these phones. If you've even thought about using Odin3, we need your help.
Update: UnBrickable Captivate http://forum.xda-developers.com/showthread.php?t=1206216

Seems interesting / promising, unfortunately I can't help BC I moved back to Morocco (Africa) and only brought 1 captivate with me. Good luck that is all I can say.
Sent from my SGH-I897 using XDA Premium App

Really interesting and very cool.
But I have a fully bricked captivate which I still have cause it was a friends who just went onto the Inspire. Always have wondered if I could recover the hard brick.
Wish I could help but I'm pretty useless with Soldering and taking apart my phone. But if development moves along with this I'd love to support. The idea of porting those OS and helping everyone saving hard bricked phones would be great.
Good Luck!
Sent from my SGH-I897 using XDA App

im bookmarking this. i can only help in fabrication. im not a super genius dev. but threads/projects like this do interest me.

Middle battery pin? Reminds me of the battery jig trick on the original PSP.
All-in-all, this looks promising, I'll be following it.

Posted up the iROM in the first post. this is the code which we hope to establish communications...
Keep in mind, this could be over the USB port, the Middle battery terminal, or even the headphone port.

But I have a fully bricked captivate which I still have cause it was a friends who just went onto the Inspire. Always have wondered if I could recover the hard brick.
Click to expand...
Click to collapse
I'M GETTING ONE OF THOSE IN THE AM!!!!!
i have a fully bricked cappy that i bricked lastnight. i was able to recover from the phone..!..pc icon but then failed @95% via odin3 v1.00.
i will mail you the cappy if you can fix it and use it as a test mule for future brick\unbrick attempts...... the outer glass is broken thanks to a fall from my lap to the concrete

I think I actually discussed this with you before. I ran twice into some instance where no action would make difference on the phone, no response to key combos, no response to charger or USB. But, download mode was still accessible via USB Jig.
What could've happened there?

cumanzor said:
I think I actually discussed this with you before. I ran twice into some instance where no action would make difference on the phone, no response to key combos, no response to charger or USB. But, download mode was still accessible via USB Jig.
What could've happened there?
Click to expand...
Click to collapse
Not really positive at this point, id suspect corrupted pbl.bin or param.lfs partitions. I've seen some weird stuff with the pbl. One phone would only output uart when volume + was held for 5 seconds.
Basically from my understanding... The IROM loads into the processor. This is the first 40000 bytes and it's protected memory. The iROM brings up basic functionality for the processor, including the initial factory UART/MMC load of PBL & SBL. The IROM then instructs the phone to load the IBL/PBL(Initial Boot Loader/Primitive Boot Loader). The IBL initializes memory for the SBL(Secondary Boot Loader) , then the PBL loads Params(a partition on the OneNAND) and checks the pins on the processor for commands. The PBL then makes more memory available for applications, then locates and and loads the SBL. The SBL initializes other functions and then locates and loads the kernel.
The SBL is responsible for Download Mode and the SBL prompt. it is basically the system's "BIOS" for lack of a better word. I'm not sure of the steps which can be skipped for sucessful download mode.

The iRom download it broken.
Ill look at it once your reupload

Some kid reported the iROM code as being in violation of the terms of agreement of the hosting website... It must have been a kid because Samsung would not do that. Just as we have a right to use tools to disassemble our phones, take pictures, annotate those pictures and post them on the internet, we have the same right to the IROM. It's not hurting Samsung's sales, nor is it intellectual property of Samsung. We bought the phones and it came with this. The only intellectual property in this document belongs to the person who disassembled and annotated this code.
I've rehosted it here: http://teamkomin.googlecode.com/svn-history/r75/branches/IROMcode/bootdumps.rar
here: http://www.mediafire.com/file/c9bg6gyk1cuapsz/bootdumps.rar
and here: ftp://[email protected]/bootdumps.rar username xda password developers
Lets not be childish and hinder progress anymore by clicking buttons. I've removed that ability.

I think this is a wonderfull bunch of work that is being done here and if i can offer any assistance please let me know. If you would like a private IRC channel to discuss your work in with other developers I would be more than happy to provide to a quiet private place to do so. Just shoot me a pm if i can be of any assistance.

We can really use some SGS folks to help. Check out the lets save some bricks thread mentioned in the first post.

Two quick questions:
1. How would you manage to get these files? First, aren't they burned into the nand? Secondly, wouldn't they be assembled already? How do you disassemble them?
2. Do you have any good links/books on how to learn arm assembly? I know some x86, but I've never found a good link to arm based stuff (or any sort of dev platform, for that matter).
Sorry about being semi-offtopic.

Subscribed, and very interested in following progress on this.
Also: Sending PM.

Nothing revolutionary to add just yet.
However, I just finished adding a JTAG breakout to my collection. This is what my current test setup looks like:
We could use some more DIYer's on this project. The biggest thing to have is an Arduino and a microUSB breakout board. We need to figure out how to get this phone to boot from MMC, USB, or UART... and we know Samsung does this to bricks.

this looks interesting.. gonna keep my eye on it

AdamOutler said:
Nothing revolutionary to add just yet.
We could use some more DIYer's on this project. The biggest thing to have is an Arduino and a microUSB breakout board. We need to figure out how to get this phone to boot from MMC, USB, or UART... and we know Samsung does this to bricks.
Click to expand...
Click to collapse
i can build anything, the purchase of and arduino and making the breakout board are easy but i would have no idea what to do with it afterwards.
it is funny the time you posted this because my friend found out about a club that works with arduino boards making all sorts of things and asked me if i wanted to go to there meetings. this thread popped up the next day.
well i may buy an arduino board or 2 but im not sure if even then i can be helpful

Well, a pretty much unexplored area of the phone is the middle battery terminal. The middle battery terminal is a ADC(analog to digital converter) pin. We know for a fact that it triggers something called EXT-I2C (External Inter-Integrated Circuit). EXT-I2C can be used to communicate with any chip on the I2C bus. The I2C bus connects with everything on the phone... Call Processor, OneNand, Memory and Application Processor. Using the EXT-I2C, we would have full control over the phone.
I know the middle battery terminal has something to do with it because I managed to get my phone to boot-loop with the pin disconnected and I saw messages about EXT-I2C NACK( EXT-I2C not acknowledged) when playing with resistance values and watching the UART output on my Arduino MEGA.
The unanswered questions are,
How to reproduce that EXT-I2C message?
What are the Addresses on the I2C bus?
Which pins control the I2C bus?
Here's some of the possible I2C bus connections:
USB VCC
USB Ground
USB D+
USB D-
Batt+ (when powered on USB)
Batt- (when powered on USB)
BSI (Battery Signal Indicator - middle battery pin)
Headphone Left Audio
Headphone Right Audio
Headphone Video
Headphone Ground
all External-SDCard (MMC) connections
all SIM connections
This is something you can bring to the table at that Arduino club. You can also read up on this hackaday article http://hackaday.com/2011/05/11/i2c-101/

If anyone has a good idea of which pins may be OM pins here, let me know..
Side facing LCD screen
Side facing back of unit

The Captivate Development Platform mod AKA UnBrickable Mod

Background
First off, big thanks to TheBeano and Midas5 for teaching me about UART, decompiling bootloaders and figuring out how the OM values work. Their initial work and dedication in "Lets Save Some Bricks" inspired me greatly. Since the work started we've analyzed UART outputs, hacked the heck out of the SBL prompt, obtained both decompiled and source for bootloaders, and generally learned a **** ton about our devices... Mind you, that's a Metric **** ton, not the Imperial **** ton, which is equivalent to nearly 2000 assloads. The reason I'm branching this operation at the current point is because this modification is specific to our device. The proper modifications for other Samsung devices have not been identified yet. We're first! Yay! We need to focus on Captivate firmware development now. The firmware may encompass all GalaxyS models as well, but this modification will only work on the Captivate.
introduction
I'm not kidding when I say UnBrickable. Modifying the OM pins means you can boot from USB, UART or MMC. This makes the phone quite UNBRICKABLE. There is nothing you can do software wise to prevent the device from booting into this mode. We are communicating with the unrewritable, efused IROM on the processor. It's the thing that makes the system on a chip into a "system on a chip".I am here now to tell you how to turn your Samsung Captivate into a KIT-S5PC110 development board. The KIT-S5PC110 development board is the platform used to develop our phones. There are some differences between this mod and the official development platform. The S5PC110 has a removable internal SDCard and no touchscreen.
Why would you want to do this? When you plug in the battery and connect it to the computer in "off" mode, it will become an S5PC110 board awaiting download of a program to run. This occurs long before anything like software or firmware enters the processor. This is the IROM of the device awaiting commands or a power on signal.
Because it is accepting a memory flash, anything may be put onto the device to perform a boot sequence..... Apple iOS (iPhone4 has the same processor) WP7 (mango supports this processor).
This will be a replacement for JTAG once we are able to make some firmware. How could it possibly be better then JTAG? Let's count the ways....
1. The only part required is a wire.
2. No shipping time.
3. No cost for a box to interface the computer.
4. Permanent.
5. Can be done as a preventive measure.
6. Gives the ability to test new Bootloaders temporarily.
7. Allows development of the entire system.
8. Removes worry about flashing and acts as a backup.
After performing this mod:
Remove the battery, replace the battery, your phone will connect to the computer via USB and await commands. Otherwise it will pretty much act like a captivate. See the Special Instructions section.
Modification
You will need:
1. Get someone who knows what they're doing with a soldering iron. If they don't know what flux is, then they don't know what they're doing. You can send me a PM(my username @gmail.com) or Connexion2005(aka MobileTechVideos.com). Note: I do not work for/with mobiletechvideos.com.
2. soldering iron - make sure it's sharp, if it's not sharp, then sharpen it, flux it and retin it.
3. flux
4. solder
5. tweezers
6. A relay (for the wire contained within)
getting started:
You will need a very small peice of wire. Tear apart the relay unravel the coil within and grab about 12cm~ of wire. The fact that it comes from a relay is important because relays generally have very small wire which are individually treated with a non-conductive coating.
Take the 12cm~ wire from the relay and tin the very edge of it. No more then 1/32". If you tin more then 1mm, cut off the excess. It is desirable to have a slight bit of excess solder on the tip of this wire.
performing the modification:
1. tear apart your phone... remove 6 #0 phillips screws from the back. Two of them are under the battery slide flap. The slide flap must be up on one end and down on the other in order to get to these screws... Don't LIFT the slide flap, just rotate it at an angle. Once the 6 screws are out, then you can separate the back from the front. Make sure to take out your SIM and external SDCard before you do this.
{
"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"
}
2. remove the mainboard... there's a single screw and 5 connectors which require removal. Remove them. Pull the board out and place it on your workspace
3. remove the EM shield from the processor side.
4. remove the OM5 resistor in the picture below. It's coated in glue. I've found the best thing is to just coat the area in flux and let it do the work while prodding with the iron to move the resistor out of place.
5. Connect the active side of xOM0 resistor to the active pad on OM5's resistor pads.
http://i51.tinypic.com/160zmty.jpg
6. reassemble the phone.
Special Instructions
This replaces the battery charging sequence. The normal battery charging sequence can be activated by holding power for 4 seconds.
To turn on the device, and operate in normal mode, you must hold the power button for 5 seconds.
3 button Download mode works as usual, however you must not have the S5PC110 drivers installed on the computer. You can use your custom rom menu option, adb reboot download, or use a terminal to "reboot download". 301Kohm Factory Mode JIGs work as well, but you must press power to bypass the S5PC110 mode.
Conclusion
Congratulations. You now have a device which works like a KIT-S5PC110 with an OM Value of 29. Now get to developing some serious custom software. See here for setting up the UART output http://forum.xda-developers.com/showthread.php?t=1235219
reading material
Creating your own Samsung Bootloaders: http://forum.xda-developers.com/showthread.php?t=1233273
KIT-S5PC110 manual: http://www.mediafire.com/?94krzvvxksvmuxh
how to use DNW: http://tinyurl.com/dnw-how-to
Flash using openOCD and DNW: http://www.arm9board.net/wiki/index.php?title=Flash_using_OpenOCD_and_DNW
another DNW example: http://www.boardset.com/products/mv6410.php
ODroid dev center: http://dev.odroid.com/projects/uboot/wiki/#s-7.2
drivers and utilities
This will be an ever expanding list
Windows Drivers http://forum.xda-developers.com/attachment.php?attachmentid=678937&d=1312590673
Windows Download Tool DNW: http://forum.xda-developers.com/attachment.php?attachmentid=678938&d=1312590673
Windows Command Line tool: http://forum.xda-developers.com/showpost.php?p=17202523&postcount=27
Linux DNW Utility: http://dev.odroid.com/projects/uboot/wiki/#s-7.2
Linux Detector tool: http://forum.xda-developers.com/showthread.php?t=1257434
Linux Automated UnBricker:http://forum.xda-developers.com/showthread.php?t=1242466
firmware
Bootloader Hello World by Rebellos http://forum.xda-developers.com/attachment.php?attachmentid=698077&d=1314105521
UnBrick tool http://forum.xda-developers.com/showthread.php?t=1242466

Great work adam. cant wait to see this used to reflash bootloaders or something.

now we need firmware... i figured adam would have flashed something already , and thought about getting back from that flash later

https://github.com/teamhacksung/uBoot
possibility of uBoot on our devices... so much nicer than our current bootloaders. initial work has been done by codeworkx for compatibility with our boards, but (obviously) hasn't been tested

COOOL
looks good

Very exciting work y'all! Any plans on using it to dual boot Andbuntu/iOS?

Wow dude, you do some great work. Keep us posted!
Now if it only was a light sabor too....

i did a little bit of reading and definitly agree it would be cool to get uboot on our phones,
along with unbicking devices.
I would love to help sadly I have no knowledge of this low level stuff, or soldering skills.
I will watch this thread closely. Good luck guys.
http://www.linuxfordevices.com/c/a/...s-UBoot-the-universal-open-source-bootloader/

I was attempting to see what i could "upload" from my daily phone. I messed up my daily phone while performing this modification. I was trying to remove the xOM5 resistor and got impatient. I broke it off, it took the pad with it and I and was left with only a .001mm wire on the board. I attempted to solder it for about 6 hours straight and after a while I swiped off 5 resistors in a line. I'm sure I could repair it, but I just went and bought another phone.
Lesson: Take your time, and don't try to force anything. That glue is tough and it acts as a heat sink. Remove the glue from one side of the resistor, heat the entire resistor up and let it slide off. Don't try to speed it up.
Once you perform this modification everything works just fine. No problems. It's a risky procedure though.
I still have not tested any firmware sucessfully. I tried a few precompiled uboots, but I did not yet try the uboot mentioned above.

This looks awesome, although I'm hesitant to do it, because there's always that chance that I will need to RMA. Sorry about your phone Adam, I think everyone in the forum is probably in love with you now though!
Sent from my SAMSUNG SGH-I897 using XDA Premium App

I would add that when doing this work, you should use ESD protections. Wrist strap (you can rig a homemade version), ESD mat, etc. Not as big of a risk in a humid environment, but as relative humidity drops, the risk increases. You can never be to safe if your phone is valuable to you. Typically, consumer electronics are hardened to ESD through connectors and the housing, but when you are directly handing the PCBA, you are potentially bypassing the hardware filters.

I need something to flash with this bad boy now.
Sent from my GT-I9000 using XDA Premium App

Adam, thanks for all your work, and everyone else for that matter. Connexion never responded to my PM about jtag work, but this little modification is so damned easy I went ahead and did it. I'll be patiently waiting for a firmware we can use to reflash bricked phones in the future.
Again, thanks a ton!

I don't need to rework the board do I? As in is picture 4 simply for reference?

Proxyep said:
I don't need to rework the board do I? As in is picture 4 simply for reference?
Click to expand...
Click to collapse
Picture 6.

Adam, did you try tracing the i2c?
It might give us an un-brick mode without even soldering om5.

So what would this exaclty do?, dont wanna do it till i know exactly what it does.
Sent from my Cappy with Glitch V11 LL at 1.6GHz stable, Juwe's RAM script, V6 script, V8 kickass kernel tweaks, and 3G booster script using XDA Premium App

midas5 said:
Adam, did you try tracing the i2c?
It might give us an un-brick mode without even soldering om5.
Click to expand...
Click to collapse
No, I have not been messing with hardware since I found the OM5 mod. I wish to develop this further. If you can get me a pin number to trace I will do that. Please look up the pin in the S5PC110 manual and I will trace it... I've been very busy locating software for this mod.
b-eock said:
So what would this exaclty do?, dont wanna do it till i know exactly what it does.
Sent from my Cappy with Glitch V11 LL at 1.6GHz stable, Juwe's RAM script, V6 script, V8 kickass kernel tweaks, and 3G booster script using XDA Premium App
Click to expand...
Click to collapse
Currently we are running into this:
Code:
��������������������������������������������������������������������������������
Uart negotiation Error
Secure Fail Error
Secure Fail Error is likely because the uBoot I am loading violates the S5PC110 chain of trust. I am working to locate software which will not violate the chain of trust.
See this post for more:
popfan said:
I found this while waiting for the reply from Samsung.
http://www.aesop.or.kr/?document_srl=266600&mid=Board_Download_S5PC100
This is Linux Native - Complier Package
Please note this is in Korean.
One more found:
http://www.aesop.or.kr/?mid=Board_Download_S5PC100&page=2&document_srl=75581
USB OTG-Mon Binary ??
Last one - S5PC100 Code Visor Debug resource
http://www.aesop.or.kr/?document_srl=267106&mid=Board_Download_S5PC100
Click to expand...
Click to collapse
I have a 3 day waiting period for my id on that site to become active, at which point, I believe we will have a solution.

I believe the binary on this page will be the solution http://www.aesop.or.kr/?mid=Board_Download_S5PC100&page=2&document_srl=75581

b-eock said:
So what would this exaclty do?, dont wanna do it till i know exactly what it does.
Sent from my Cappy with Glitch V11 LL at 1.6GHz stable, Juwe's RAM script, V6 script, V8 kickass kernel tweaks, and 3G booster script using XDA Premium App
Click to expand...
Click to collapse
Allows you to boot from things other than the internal sdcard, and overwrite memory on the phone. Basically, if you break a bootloader, this is the only thing that could fix it beyond re-jtaging it.
At this point, there's no real point unless a) your device is bricked or b) Adam gets the software half up and running, in which you could do it as a pre-emptive measure.

How to hack hardware binary and bend it to your will

Before you start on actually modifying your hardware, you must know what it is you're after. Don't just go using your finely tuned soldering iron without doing some research first... http://twitpic.com/75maxq
I wanted to share some tricks I use when locating UnBrickable Mod on various devices because it has been requested many times. Overall, the methods I'm going to talk about can be called "reverse engineering", "hacking", or "circuit bending".
Each device is different so different methods may be used. I'll start with what I feel is the best method to use and move my way on through less accurate and more destructive/difficult methods. The methods I'm using here can be used on nearly ANY device for nearly ANY purpose, not just locating boot modes. Using the techniques I'm laying out here, you can locate any physical memory register on any chip.
For the purposes of this familiarization guide, we will be locating the xOM5 resistor which changes the S5PC110 boot mode from "boot from OneNAND" to "Boot from USB, then OneNAND". Other modes are available such as booting from SDCard or MMC but these modes do not allow dual booting into the standard OneNAND boot so they are not practical unless you have a NAND failure.
By reading the S5PC110 processor manual, we can see on page 6-8, this is achieved by setting the xOM bits to 101001 (hex value 29). These binary values correspond to pins on the processor. These pins can be set high or low, and they ARE set high and low on the development board for the S5PC110 development boards. On other processors like OMAP4460, or Exynos, different pins are used but the functionality is the same.
All binaries and reading materials used are availabe in the GalaxyS hack pack: http://forum.xda-developers.com/showthread.php?t=1111866
For installation of binaries, you can use the market app "mount rw/ro" and drop the binaries in your /system/bin folder. See here for more information on direct access to Linux and installing binaries: http://forum.xda-developers.com/showthread.php?t=1030107
For the purposes of this thread we will be using a S5PC110 chip which is what the entire GalaxyS series of device is based upon.
With this knolwedge in hand, lets continue into HOW we can locate these pins.
how to locate the xOM resistor cluster
If you orient the S5PC110 processor with the PIN-0 dot at the lower left corner, you will find the xOM cluster at the lower right corner. These resistors will always be near this location because the pins on the board are near this location. It's never a good idea to have "runs" on a board longer than necessary. Therefore, these resistors will always be near this corner.
NOTE: You need not remove the processor. This is only for illustration.
{
"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"
}
For other devices, see the pinouts on the processor manual.
Methods for locating modificaton
Monitoring memory locations in real-time
You will need:
viewmem installed in /system/bin
bash installed in /system/bin
Market App: QuickSSHD allows you to terminal into the device.
1. we locate the xOM registers on the device. According to the processor manual
OM_STAT 0xE010_E100 R OM status register 0x0000_0000
Click to expand...
Click to collapse
the OM registers are at 0xE010E100. So we know where to look in memory to monitor changes.
2. ssh into your device. See QuickSSHD for more information. Once you are in, assume super-user, get into a bash terminal, and use the viewmem utility.
Code:
$ su
# bash
bash-4.1#viewmem 0xE010E100 0x4|hexdump
[INFO] Reading 4 bytes at 0xe010e100...
0000000 0009 0000
0000004
3. Short and test. While shorting the high value to the active side, NOT THE VISIBLY GROUNDED SIDE, monitor output from the terminal.
The PullUp resistors are 10Kohm and the Pulldown resistors are 100Kohm. This means there's 10x more force behind a digital high than a digital low, in other words, you can short any low value high without a problem...
Code:
viewmem 0xE010E100 0x4|hexdump
[INFO] Reading 4 bytes at 0xe010e100...
0000000 0029 0000
0000004
the 29 signifies that the device is modded properly. A value of 0x9 is a standard production device. When you see 0029, you've located the proper resistor for the modification.
Using overlays
Take a picture of the board, then use an annotated pinout to locate the proper pins on the processor. This allows for a visual of the device as though the processor were removed.
here's a picture of my own annotated overlay. Use this and we'll walk through overlay logic.
Now, with a xOM value of 0x9, that's a binary value of 001001, use your calculator in "programmer" or "scientiffic" mode if you don't believe me.
Broken Down:
xOM5=0
xOM4=0
xOM3=1
xOM2=0
xOM1=0
xOM0=1
xOM 3 and 1 are both high values, all the rest are low. We can use this to our advantage. We can see that 4 resistors are connected to ground on one side and 2 are not. Those two are obviously xOM3 and xOM1.
If we look at the processor pinout, we can see that if xOM3 and xOM1 resistors were swapped, one would be very much longer than the other so there's only one logical solution.
Moving on to the shortest ones, xOM4 and xOM2 would obviously be closest to the top of the resistor cluster, and it's also obvious wich one would be which.
Now that leaves two resistors in the middle. One is high and one is low. by drawing it out you can see that if xOM5 were on the right, then xOM1 would be very much longer than xOM5, so xOM5 must be on the left.
So, we've located all xOM values with this method.
Using relative positioning
This method is not nearly as scientiffic... Since there are now 10 guides made for modifying xOM5 on different boards, a resistor may be picked and chosen as though it were from anothe board. See here for various modifications: http://forum.xda-developers.com/showthread.php?t=1236273
Verification from this method may be made using UART. you would be expecting an output like this over the UART on your device.
See here for info on UART: http://forum.xda-developers.com/showthread.php?t=1235219
If the modification was sucessful, UART will output a line which states OM=0x29.
Using a multimeter
You can remove the processor from a device and trace out the pins manually. This method is only appropriate for a broken device.
conclusion
So, these are my methods for hacking hardware and making it do what I want. I'd like to hear others. Lets hack up some hardware and talk about it here.

+1
Good that every chip component is configureable on lowest level by set of external passive elements - opens big possibilities to change any hardware into something different.
Worth to add - always think twice, or even once more before short circuiting anything. If between some V line and another there is positive voltage, like +1V, it still doesn't mean that second one is GND. First one can be +2V and second one +1V. READ carefully all datasheets and documentation. Don't connect any power line straight to another without resistor - this will cause high current go through some component and probably damage it.
Example of bad test - there are some capacitors on the left of Adam's needle when testing resistor. It's highly possible that these capacitors are ARM_CORE stabilisers, which is 1.2V and can handle up to about 1.4V. Adam is operating with 1.8 or 2.8V from other V line - accidentally touching the capacitor with needle can damage CPU core.
If you never been doing any hardware mods but feels like you want to start - prepare for some victims in your electronic devices. That's all of my experiences for now.
//Damn me and my bad habit of reserving posts in Adam's thread. Sorry. :d

very informative

Excellent and authoritative article! Though I'm personally too scared to do anything like this on my phone!

I've gotten replies from people that removing a BGA chip is almost impossible. A tutorial on how to unsolder one would be helpful for aspiring hardware hackers.

Master Melab said:
I've gotten replies from people that removing a BGA chip is almost impossible. A tutorial on how to unsolder one would be helpful for aspiring hardware hackers.
Click to expand...
Click to collapse
It IS almost impossible. It's rediculously difficult. You'll end up pulling a pad or two off the board. You must heat up the entire chip with a heat gun or a hot air station, then pull it off... Meaning you're heating up the entire chip to the point where the solder melts. It takes a multi-thousand dollar professional setup in order to make sure no damage is done. I use a digital temperature controlled heat gun. It works, but it's not accurate.

If you could replace the pads with a socket or something like that you'll be set to go.

we need to get you a better camera

elmanortega said:
we need to get you a better camera
Click to expand...
Click to collapse
HAHHAHHAHHA. funny story about that...
You see, my 6 year old tried to do unbrickable mod on that today..
I no longer have a dedicated camera

I wish i could try it, but i am sure i wont be able to, lol

Thank you very much for this guide.
Could you also describe what tools (soldering iron etc) do you use?

I use a Radio Shack digital soldering iron. It's nothing special but it's temperature controlled and has a fine point.

I made some more overlays
here is Exynos4210
This is from OMAP 4460, but I'm pretty sure it applies to OMAP 4430 as well

verry intresting, soon i try

Seriously this guys work is awsome, learnt quite abit from your work, thank you very much!
Sent from my Desire HD using XDA App

cdesai said:
I wish i could try it, but i am sure i wont be able to, lol
Click to expand...
Click to collapse
Same here but why dont giveit a try... just encourage

AdamOutler said:
... It takes a multi-thousand dollar professional setup in order to make sure no damage is done. I use a digital temperature controlled heat gun. It works, but it's not accurate.
Click to expand...
Click to collapse
Sorry Adam, you have a great writeup, but this is really a BS statement!
-- You can easily unsolder a BGA chip with a $5 micro-blow-torch! You just have to make sure you shield the surrounding components from the excessive heat. Put a small piece of copper (a penny?) on top of the chip, then put a piece of low-temperature (lead-free) solder on top of the coin, so you can get an idea when you have enough heat. Continue 10-20 seconds. Very carefully try to jam a few sharp toothpicks under any space between chip and PCB. Never bend!
This technique is well known and well demonstrated on YouTube, ever since the HP/Nvidia scandal of video chips falling of the MOBO after dust blocking the fan intake with (purposely) under-dimensioned and faulty heat-sink design.
The problem is getting it back ON! Then you need to invest in a professional heat plate and re-balling grid.

excuse me mister, i have done it, n my tab turn back on, now i have another problem, the screen is black and the bottom light is on, could you help me?

^^ good idea! I've always used a high power and small heat gun. It works for 99% of the pads, but I always lose 1 or 2. I never intend to put them back on.
apram75 said:
excuse me mister, i have done it, n my tab turn back on, now i have another problem, the screen is black and the bottom light is on, could you help me?
Click to expand...
Click to collapse
This is the wrong place to post that. And it does not really make sense that you did this in context.

Unsoldering a BGA is easy.
Doing it without causing unrecoverable damage is a different story. Same for resoldering it back on.
However it is getting easier nowadays - temp-controlled hot air rework stations have dropped drastically in price - http://www.amazon.com/Updated-Aoyue-Digital-Soldering-absorber/dp/B006FA481G/ref=pd_cp_hi_3
Also, reflowing a BGA without removing it (such as for Xbox360 RRoD fixes) is a LOT easier than remove-and-replace.
Also - my personal favorite deal in terms of soldering irons is http://www.amazon.com/Aoyue-937-Dig...ref=sr_1_1?s=hi&ie=UTF8&qid=1331244730&sr=1-1 - The Aoyue 937 is amazing considering it is <$50.

[Q][GT-I9100] What is this chip?

We're trying to complete the list of known components for the GT-I9100, but have a huge
problem trying to identify and find the correct chip specifications for a few of the chips.
One of them (U504) can be seen in the photograph and schematic below.EDIT: This chip have probably been resolved to be the MAX8922L as shown in post #6.
So the next chip we would like to resolve is the U303 shown in post #9.
U303 has been resolved as shown in post #13.​
{
"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"
}
We need this info in order to complete the "The all-in-one Galaxy S2 Hack Pack" in the
add-on post "The GT-I9100 Hack Pack AddOn-1". (For further details see that thread.)
As is shown in that link, it is listed by its Samsung part-number as:
"SS6000GQW / IC-POWER SUPERVISOR". But that chip is nowhere to be found on internet,
so it must be something else, or at least very similar to something else.
The other chips we need info about, are:
Code:
[SIZE=2]U101 Duplexer/Antenna Switch Module
[/SIZE][strike][SIZE=2]U303 Samsung:1203-006847 ? ? "AA1 114" / "IC-POWER SUPERVISOR"[/SIZE][/strike]
[SIZE=2] [strike]U504 Samsung:1203-006884 ? ? "SS6000GQW / IC-POWER SUPERVISOR"[/strike][/SIZE]
[SIZE=2] F100 Samsung:2910-000125 ? ? "DUPLEXER-SAW" [/SIZE]
Thanks in advance.

I think that some kind of voltage comparator which enables the charging, see connected to power mosfet.
But maybe I am wrong, could you post block diagram with higher res? Text on pins is mostly unreadable...
And it also has current monitor, see a voltage divider which acts surely as current meter (for battery I guess)

HeliumX10 said:
I think that some kind of voltage comparator which enables the charging, see connected to power mosfet.
But maybe I am wrong, could you post block diagram with higher res? Text on pins is mostly unreadable...
And it also has current monitor, see a voltage divider which acts surely as current meter (for battery I guess)
Click to expand...
Click to collapse
This part in bold! And afterwards the answers

HeliumX10 said:
... could you post block diagram with higher res? Text on pins is mostly unreadable...
Click to expand...
Click to collapse
zylor said:
...And afterwards the answers.
Click to expand...
Click to collapse
According to the diagram above, the pinouts are as follows:
Code:
[SIZE=2]pin name i/o path/connection path-end-point
-------------------------------------------------------------------------------
1 VIN
2 ISET o CHG_CUR_M
3 GND
4 LDO V_BUS_LDO_5V
5 IEOC GND
6 EN|SET i CHG_EN ("Q500")
7 GND
8 CHGSB o CHG_ING_IN
9 PGB o TA_nCONNECTED MAX8922 ?? ?GPIO charging connected?
10 BATT V_BAT
11 GND [/SIZE]
This shows an 11th pin connected to GND. However, looking at the photo you can easily see that there are only 5 pins on each side, so unless there is also a grounded (not-visible) mid-pad, the schematics cannot be trusted. Which is also not anything new, for Samsung's service manuals.

E:V:A said:
A
This shows an 11th pin connected to GND. However, looking at the photo you can easily see that there are only 5 pins on each side, so unless there is also a grounded (not-visible) mid-pad, the schematics cannot be trusted. Which is also not anything new, for Samsung's service manuals.
Click to expand...
Click to collapse
Yes, also there is maybe not 11th pin present, its grounded as two others.
What about notice of MAX8922 - it really could be it! Same pinout (yes other called pin names but with same functions), same package type. Will continue in its studying and comparing

^^ Ha! You're right, I had a second look at that datasheet. Dammit, I can't remember why I made that note! I might have seen it as a potential candidate on Maxim website, but didn't have time to check datasheet... However, I do remember thinking that the package doesn't (according to datasheet) have the exact same form factor. I.e. The side pins are too far from the edge. But reading the package notes, they also say that package shape may vary...
Pin descriptions fit best to the Maxim MAX8922L which has a "10 TDFN-EP" package. The "EP" part stand for Exposed Pad, and should be grounded, as it is, including the factory test input pin, #7.
In addition, we know the resistor values, and can calculate the maximum "fast_charge" current,
that depend on what is connected to the "CHG_CUR_M" line. (No Connection => Maximum)
Code:
ISET is connected to GND via 3 resistors in series:
R529 = 300 ohm,1%,1/16W,TP,1005
R531 = 300 ohm,1%,1/16W,TP,1005
R533 = 215 ohm,1%,1/16W,TP,1005
--------------------------------
= 815 Ohm
=> [B]I([I]fast_charge[/I])[/B] = 1500V/815Ohm = [B]1.84 A[/B]
while IEOC is connected to GND via R532:
R532 = 6.34K ohm,1%,1/16W,TP,1005.
=> [B]I([I]top_off[/I])[/B] = 150V/6340Ohm = 0.0236 A = [B]23.6 mA[/B]
However, I doubt any of the PCB traces can handle this kind of current to/from the micro-USB port. Please let me know, if you know more about this...

Is there a possibility there are more resistors in parallel with those at the other end of CHG_CUR_M?
Actual charge current setting is 650 mA.
Edit: never mind, that would make the current higher not lower... brain is fried...

Entropy512 said:
Is there a possibility there are more resistors in parallel with those at the other end of CHG_CUR_M?
Click to expand...
Click to collapse
That chip is a funny little devil, in that it can supply up to 2.3A in short periods (576 μs / 217 Hz) when in "GSM RF Test Mode". In addition, I now believe that the "M" part of "CHG_CUR_M", stand for "measurement", and is used by the PMIC to determine charging current. (I have not traced these lines, so don't take it as a fact.)

U303 [1203-006847] "Power Supervisor"
The next chip we would like to document is the chip "U303". This is a 8-pin chip which is probably a power supervisor for the "UME300" MoviNAND memory. However, the only thing known about this chip is the following.
Code:
[SIZE=2]Type: ? Power Supervisor
Package: 8-pin
Label: "AA1 114"
SamDesc: "Samsung IC-POWER SUPERVISOR;"
SamPartNo: 1203-006847
Description:
Located close to the Modem (UPC300) and next to the Dual Comparator, LDO
(U603,U610) and the SD card slot, it does look related to power, as it
would not make any sense to place this chip here, if not. In addition it
is surrounded by the resistors and capacitors: C300, C304, C356, C358,
R623. It could be a power chip for the UME300 MoviNAND chip.
-------------------------------------------------------------------------------
Pin Function Description Path/Connection
-------------------------------------------------------------------------------
1 ?? Seem connected to "TP_eMMC_EN" test point
2
3
4
5
6 C358 1000nF,10%,10V,X5R,TP,1005
7 C356 1000nF,10%,10V,X5R,TP,1005
8 C300 100nF,10%,6.3V,X5R,0603
-------------------------------------------------------------------------------
[/SIZE]
Here is the picture:

E:V:A said:
Code:
ISET is connected to GND via 3 resistors in series:
R529 = 300 ohm,1%,1/16W,TP,1005
R531 = 300 ohm,1%,1/16W,TP,1005
R533 = 215 ohm,1%,1/16W,TP,1005
--------------------------------
= 815 Ohm
=> [B]I([I]fast_charge[/I])[/B] = 1500V/815Ohm = [B]1.84 A[/B]
while IEOC is connected to GND via R532:
R532 = 6.34K ohm,1%,1/16W,TP,1005.
=> [B]I([I]top_off[/I])[/B] = 150V/6340Ohm = 0.0236 A = [B]23.6 mA[/B]
However, I doubt any of the PCB traces can handle this kind of current to/from the micro-USB port. Please let me know, if you know more about this...
Click to expand...
Click to collapse
Youre right - as I expect standarts for most phones is 1,5 Amps (discharge) or 1.0 A (fast charge) max (myself measurment in other phones and battery internal circuit shuts down when 2.0 amps so 1,67 Amps is a little overdimensed for measurements because of standarts +-15% tolerances in resistors.
Could you post (or link) the full schematics of this phone ? Maybe it was posted before, but dont have so much time to spend with searching (hate me ).
I could participate even with next searched chip, but want to look at the full wirings first.

^^ There are no full schematics available AFAIK. The ones I have above are only the ones present in the GT-I9100 Service Manual in the "Hack Pack". Look there.

As I discuss in the thread linked below, we have the full PCB schematics of the GT-N7000 (Galaxy Note) which is very similar to that of the I9100. I think tracing some of those chips can be very informative!
"[GT-N7000][REF] Service Manual and Full Schematics"

U303 has been resolved to be the "Low Noise Dual 300mA LDO Regulator": Ricoh RP150K011B
Code:
[URL="http://www.samsungonderdelen.com/product-1203-006847.htm"]1203-006847[/URL] IC-MULTI REG.;RP150K011B,PLP,8P,4x4x1.6m
This is almost the same as for U704 (RP150K009A).

What is this chip?
Hi everybody.....This is picture of my GT-I9100 motherboard,when I connect on charger this is happened and warranty not cover this they said that is water damage,they not believe me that is not water damage...anybody know what is this component and can I (in service) replace it,thanks....

charging corrent
Actual charge current setting is 650 mA.
Click to expand...
Click to collapse
some one in this topic says he manged to get 1A charging current by shorting r529 or r531:
http://forum.xda-developers.com/galaxy-s2/accessories/charging-current-t1085999/page2
did some one else test it?
is it really possible to achieve 1A charge current?
also did someone mange to get otg+charging at the same time?
according to the otg spec it is supposed to be possible, but with a different resistor between id pin and gnd of the micro usb connector in the otg adapter.
i tried different resistors with no success

Controlling the FSA9480

Hi folks,
I have a hardware/software project that I'm building on a Galaxy Nexus phone and I would like to exert full control over the FSA9480 chip that switches the phone's pogo pins and micro-USB port between the USB and charging circuits.
The overall goal is to have a USB accessory plugged into the phone at all times, including in a pogo-pin based charging dock. Since the default "auto" switching mode keeps the phone in USB-host mode as long as the OTG cable is plugged in, the phone will not currently charge in the pogo dock.
Thanks to Adam's great thread on the FSA chip, I've been able to control the FSA chip via the i2c interface, using the i2c tools in his hack pack. (Heading to those threads to leave my thanks as soon as I get this FP in).
Even though I can check the registers and in fact see that the switches inside the FSA chip are in the modes I specify, the phone doesn't do the things I expect it to, like charge or enter USB accessory mode. I suspect this is because I've unloaded the FSA kernel module in order to access the i2c device. I was hoping that merely connecting the wires to the right places via the FSA would do things like enable the USB connection or allow the device to charge. Alas, that does not seem to be the case.
Since Google has declined to share the source for this phone, I've been poking around and assuming that their driver is similar to this code and this header. I love that fsa9480_SetManualSW is exported, but I have no idea how I might access that method, if it is in fact in the Nexus code. I'm searching through the lib/*.so files now to see if there's anything FSA related there, but so far no luck.
So that's where I am - I can control the device, but that doesn't appear to be enough to do the things I want to do. I'm not sure where to go next - I don't think I should have to write my own kernel driver, but I'll be damned if I know what to try next.
Does anyone have any ideas how I might exert software control over this FSA chip, or barring that, what else I need to fool with on the i2c bus so that the phone charges or enters the proper USB mode when I set the FSA mode manually?
Many thanks in advance and I hope this is the right place for this question (Q&A section did not seem like the place for this type of question).
Peter

You're taking an interesting approach to this. However, there are a couple of things you need to explain and understand better.
1) What are these "pogo-pins" you're talking about? [There is no such thing well defined, please be specific and use correct terms for whatever it is you're trying to describe.]
2) What make you believe there is a FSA9480 in your Nexus? [There probably isn't! I know the driver is called so, but that chip probably never existed in production.]
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
4a) You say you can "control the chip" with I2C, can you give some examples of this? But I don't know what you're actually controlling, as it doesn't make sense the way you have explained it.
4b) You also say you have unloaded the Kernel module... How did you do that?
5) It seem that you're confusing the chip signal directions. I.e. whether certain pins are designated as input or output signals...
6) There are more switches/multiplexers built into your phone. It's of essence to understand which ones you're actually controlling.

E:V:A said:
You're taking an interesting approach to this. However, there are a couple of things you need to explain and understand better.
Click to expand...
Click to collapse
Certainly happy to explain as much as I can... let's see:
1) What are these "pogo-pins" you're talking about? [There is no such thing well defined, please be specific and use correct terms for whatever it is you're trying to describe.]
Click to expand...
Click to collapse
I got the term "pogo pins" from this thread. They are three tiny pins on the side of the Galaxy Nexus. They allow for car and desktop docks. They provide charging through the outermost pins and a digital signal of some kind (don't care about that one for this project) on the center.
2) What make you believe there is a FSA9480 in your Nexus? [There probably isn't! I know the driver is called so, but that chip probably never existed in production.]
Click to expand...
Click to collapse
I've simply assumed from the kernel messages and from screwing around via the i2c bus (as explained before). It may not be there, it may be something completely different, but from the software side, it behaves exactly like I'd expect the 9480 to...
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
Click to expand...
Click to collapse
Yes, I glossed over that fact. Expansion: We've got a USB accessory that we would prefer to never disconnect from the phone. Since even having just the OTG cable connected drains the battery, our app is already managing power by binding/unbinding the fsa9480 driver. When unbound, the driver leaves the phone pins in (afaik) a floating state and the accessory/OTG cable does not draw current. When we want to poll the accessory, our app binds the fsa9480 driver, which results in the USB system seeing the OTG cable and connecting everything up nicely. When it's done, it unbinds the driver again and saves battery.
Since we don't want to/can't disconnect the accessory from the micro usb port, charging is an issue. So we'd like to charge the phone via the side pins (what I perhaps erroneously called the "pogo pins"). Since we're only polling for short periods, we'd like to be able to switch from USB host mode to charging mode during the period in which we are not accessing the device.
Now, I had forgotten that dedicated chargers short D+/D-. My hope was that by controlling the fsa9480, I could connect the +5V and GND pins to the battery and charge the phone, while keeping the USB accessory offline. I'm afraid I'm so tired and burnt out this may not be making sense, so please tell me what's confusing!
4a) You say you can "control the chip" with I2C, can you give some examples of this? But I don't know what you're actually controlling, as it doesn't make sense the way you have explained it.
4b) You also say you have unloaded the Kernel module... How did you do that?
Click to expand...
Click to collapse
Sure! Where to start...
OK, so based on Adam's thread "Build Your Own Music Dock", linked above, I grabbed the spec sheet for the fsa9280a, which he claims is "functionally the same" as the 9480.
As you can see in the datasheet, the chip is controlled via the i2c bus. Looking at the file layout of the Nexus, I figured out the address of the chip on the bus and started plugging in commands outlined in the datasheet.
for example, setting the "Manual Switch 1" register on my Nexus is done by the command
Code:
i2cset 4 37 19 <your value>
(4 being the bus where the chip is located, 37 (0x25) being the address of the device, and 19 (0x13) being the address of the register)
The datasheet outlines all the register addresses, default values, values under certain conditions, etc. I assured myself that the datasheet was valid and I was communicating with the device I thought I was by setting and observing registers.
That "Manual Switch 1" register controls where the different wires are connected and is very important to me, as far as I know.
this is the block diagram from the spec sheet in Adam's thread above. I should have linked directly to the spec sheet, sorry.
{
"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"
}
And this is the register description from the same document
So... let's simplify my goals and say that I want to charge the phone from the micro usb port without connecting the USB host device (USB HS in the block diagram) to the micro USB connector: I'd want DP_CON and DM_CON floating and Vbus_in (on the micro connector) connected to Vbus_out (on the blue CHARGER IC in the upper left). I set the proper registers to do that, and things "should just work", right? (this is assuming I do things like initing the device, etc in the proper order, which I think I am)
They don't. Because I'm confident that the proper registers are set on the FSA, I'm assuming that the internal connections are all as I expect. Thus, my suspicion is that I need to do something more to get Android to start charging off the current coming in through Vbus_in...
Oh, and before I forget: unless I unbind/unload the driver for the FSA9480, I can't write to its address via the i2c tools because the driver already owns that address. I think of this driver as a kernel module, maybe that's incorrect or imprecise. Apologies.
5) It seem that you're confusing the chip signal directions. I.e. whether certain pins are designated as input or output signals...
Click to expand...
Click to collapse
I hope the block diagram cleared this up. I too was confused by the Vbus_in/Vbus_out thing. I really should have linked that datasheet.
6) There are more switches/multiplexers built into your phone. It's of essence to understand which ones you're actually controlling.
Click to expand...
Click to collapse
Agreed.
With that massive clarification, does that help? I'm starting to think this is something hovering right at the intersection of hardware and software. Maybe it's time I looked at writing my own device driver, or expanding the existing one?

E:V:A said:
3) Obviously (!) you cannot charge your phone and have it play (OTG) host at the same time. Why? Because charging means to short D+ and D-.
Click to expand...
Click to collapse
You had better explain that slowly to my Nook, because it's sitting beside me here charging and connected to two keyboards and a USB audio adapter.
Shorting D+ and D- is a convention to tell the device that it can draw a lot of current.
Even without the data lines shorted, a device can charge.
Moreover, if you tell your device in software to do a high current charge, it can.
Solution: use host mode and charge at the same time.
One connector does it all.

One thing I noticed while playing with the FSA chip was some of the registers would not change. They may be overridden by resistor values.
To put the device in host mode, short pin 4-5. To put it in charging mode short 3-4. It may be possible to change the host mode to charge the battery over i2c.
This may or may not be possible.
The main problem I was having was in the SBL most registers would stay static.

Playing with I2C sounds like fun, but all that stuff already has drivers.
The drivers that I've seen already have user hooks in the file system to get things done.
For example:
Code:
echo 1500000 > /sys/devices/platform/bq24073/force_current
Sets the charging current on a Nook touch to maximum.
(Your device probably uses something different.)

@Renate NST: Yes, I should have been more careful with my words. I meant charging as operating as a high current Dedicated Charging Port (DCP). But then again thebeerbaron already understood this.
@thebeerbaron: Here are your "pogo-pins" (right side is towards the top of the phone):
The pins and their function is loosely described in this thread, and very nicely used in this thread, so it seem that the following is true:
Code:
[SIZE=2]P1 +5V
P2 Signal: 1-wire interface, using MFM encoding
P3 GND[/SIZE]
(check these!)
I don't have the Samsung parts list of the GT-I9250 so I still don't know what those chips are. But U601 is a Fairchild chip and could be another type of switch. On the other side of this board you find the multiplexers U809 and U810 configured like this:
So how did you unbind/unload that "driver"? [I'm curious to see what driver/Kernel module this is.]
And here is another relevant hack for a wireless charger, But the interesting part is the Kernel hack mentioned:
For those of you wanting to charge at AC speeds instead of USB, Fast Charge Mod is here!
1) Install Franco Kernel (Milestone 1)
2) Run this script to activate it from the terminal (minus quotes):
Code:
echo 1 > /sys/kernel/fast_charge/force_fast_charge
and the UI Mode Manager code over here.

E:V:A said:
I meant charging as operating as a high current Dedicated Charging Port (DCP).
Click to expand...
Click to collapse
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.

Renate NST said:
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.
Click to expand...
Click to collapse
Well, Samsung try to conform to the "Battery Charging 1.1" standards, and that's how DCP is defined in there. The limitations are then also present in the chips and/or in the one or more PMIC Kernel drivers. So your NST is either not conforming to any standards or just have a hell-of-a-hacked Kernel, or both.
This project is interesting because it's exploring some hybrid between kernel hacking and hardware tweaking, and not just building a regular charger, which we all know how to do. If you are interested in knowing what kind of crazy hardware is included in a Galaxy class Samsung phone, you can have a look here.

Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Still, it's a useful thing to do if you want to use your device docked.
The kernel on my Nook is stock. I'm just giving commands to control the charge current.

Renate NST said:
Ok, but I can still pump 1.5 Amps into my Nook while using host mode.
I'm not sure how you are differentiating things here.
Click to expand...
Click to collapse
I don't know about the NST, but my Nook Tablet has several additional pins dedicated to charging the device, it's not a true USB port.
What's going on here is trying to convince the USB port to go into host mode, where it natively supplies 5VDC, but instead reverse it, use the 5V line to charge the device and supply 5V from an external source.
While the NT has a dedicated charging circuit, this device repurposes its usb pins based on input conditions. So here's what I see being required
1. Ground USB pin 4 to activate HOST mode.
2. shut off 5V power supply from FSA chip
3. set registers in FSA to charging mode.

Renate NST said:
Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Click to expand...
Click to collapse
It's pointless to discuss standards of what should and should not happen unless we are on the same page. Here are the specs.

Sorry.
/me wanders off elsewhere.

Sorry for the slow reply folks, I appreciate the input, but got sidetracked onto another project today. Wearing many hats means making a lot of context switches!
Renate NST said:
Shorting D+ and D- is a convention to tell the device that it can draw a lot of current...Solution: use host mode and charge at the same time.
One connector does it all.
Click to expand...
Click to collapse
I haven't tried charging during host mode, as we were trying to keep the external wiring changes to a minimum. Based on what I found last night though, we may go with a completely external solution...
AdamOutler said:
To put the device in host mode, short pin 4-5. To put it in charging mode short 3-4. It may be possible to change the host mode to charge the battery over i2c.
This may or may not be possible.
The main problem I was having was in the SBL most registers would stay static.
Click to expand...
Click to collapse
If we go with the external wiring solution, this will be what we do. When I set the FSA to various modes over i2c, it did not charge or connect the USB device as it should. This is very likely because the kernel is listening to the FSA for state changes and telling other devices how to behave based on those states. That's sad.
What is the SBL?
Renate NST said:
Playing with I2C sounds like fun, but all that stuff already has drivers.
The drivers that I've seen already have user hooks in the file system to get things done.
For example:
Code:
echo 1500000 > /sys/devices/platform/bq24073/force_current
Sets the charging current on a Nook touch to maximum.
(Your device probably uses something different.)
Click to expand...
Click to collapse
Yes, this is how things should behave. Unfortunately, the Samsung engineers who wrote this device driver were rather short sighted.
If you wade through this mailing list discussion (sorry, I apparently can't link until 8 posts... https://lkml.org/lkml/2011/6/29/124), you'll see the engineers need several attempts to get their code approved. The most interesting part to note (for me), is that they create the device file /sys/bus/i2c/devices/.../switch, which accepts input from userspace and sets the FSA9480 "manual switch 1" register appropriately. Unfortunately for me, they only coded a small portion of the possible states for this register and will not accept arbitrary values. UGH!
I sat down with the GN last night and tried using the /sys/bus/i2c/devices/.../switch device to set the manual mode. What I discovered is that even though this obviously passes values into the driver module (it prints a kernel message when I set a bogus value), the values don't "stick". In the driver code (I'm still not 100% sure I have the right source, but I think I'm close.. again, sorry for lack of clickability: https://bitbucket.org/franciscofranco/android-tuna-omap/src/388ae9aa9b26/drivers/misc/fsa9480.c), it has a _detected function, which gets called whenever the cable changes and overrides any manual settings I put in. For example, I set the "switch" file to "AUDIO", yet the phone remained in USB accessory mode, and plugging/unplugging did nothing. Sigh.
The lesson is, apparently, that I need to write my own driver module, which can replace this fsa9480.c transparently and allow me to ignore cable change detections and provide me with a way of setting the FSA state manually (with more flexibility than the Samsung engineers allowed). We're thinking about a different approach, but this may yet get done...
E:V:A said:
So how did you unbind/unload that "driver"? [I'm curious to see what driver/Kernel module this is.]
Click to expand...
Click to collapse
Some great background info in here, thanks! I'll have to sit down and process this another day.
To unbind the fsa9480 driver, I do:
Code:
echo -n "4-0025" > /sys/bus/i2c/drivers/fsa9480/unbind
And to bind it, I do:
Code:
echo -n "4-0025" > /sys/bus/i2c/drivers/fsa9480/bind
E:V:A said:
This project is interesting because it's exploring some hybrid between kernel hacking and hardware tweaking, and not just building a regular charger, which we all know how to do.
Click to expand...
Click to collapse
Yep, that's what's interesting and what's making this difficult. It's kind of a gray area of where the topic experts are and what I need to learn...
Thanks for your input all... maybe something will come along that'll save me from writing a kernel module... fingers crossed!

I am very interested in the outcome of this project. I purchased the GNex thinking I could charge it while at the same time, connecting an SSD (via SATA->USB converter) to the phone for media playback. Thanks for your hacking skills!

Renate NST said:
Generally speaking, as far as standards go, you're not supposed to even try to charge something while it's in host mode.
Still, it's a useful thing to do if you want to use your device docked.
The kernel on my Nook is stock. I'm just giving commands to control the charge current.
Click to expand...
Click to collapse
Not true. https://github.com/CyanogenMod/andr...mmit/c7016a2513abfd522b02633b79d2f21bcb99d4e2 - The USB charging standard defines an Accessory Charger Adapter. It's signaled with a particular resistor value (36k if the code comments are correct...) on the ID pin.
Although while I thought the I9100/I777/N7000 used an FSA9480, it looks like the MAX8997 handles the task on these devices... hmm... The FSA might support this mode though, so instead of trying to force-override it, look to see if there's a particular resistor value you can hijack or, in this case, a resistor value that is standardized to provide the function you want.
I hate when I only have access to github's web interface and not the ability to grep my hard drive at home.