yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] AdamOutler:
True. USB OTG is a speciffic protocol. The device will only support certain pieces of hardware.

It's also possible that USB OTG is only available when there is no PBL or SBL on the phone.

Someone who is smarter then myself should attempt to trace what hardware this is looking for. You would be looking for a manufacturer/device code or a device description string.
[Hardware Hacking General] b4dg3r:
I wondered about booting via USBOTG too. There's a lot of USB-related code in the IROM dump and I can't see why else it would be there either. It looks like there's a fair bit of SDMMC stuff too so maybe that's another possibility.

That said, there is a subroutine in the IROM at 0x0D00024C which outputs "Insert an OTG cable into the connector" to the UART. I'm speculating but maybe a UART connection is required to trigger USB / SDMMC download.

I'm going to try and find time to have a dig through the IROM.

The wikipedia entry for USBOTG mentions some other resistance values for the ID pin state which might also be worth investigating:

It would be handy for the Samsung service center people if they could both power the device and flash it with one cable irrespective of the state of the battery.

I wonder how the FSA responds to these values. Do these values cause the FSA to stop responding to other resistance values as TheBeano described? The lockup state he's described sounds interesting.
[Hardware Hacking General] midas5:
I was thinking that we could write our own gadget driver to simulate the specific device code it is looking for. We could then make a zImage with this gadget driver in it, and use one working i9000 (with the gadget driver) to recover a bricked one.

Unfortunately, this needs us to get to a point where it displays the message "Insert an OTG cable into the connector".
[Hardware Hacking General] AdamOutler:
we aren't dealing with the kernel.

The boot sequence goes:

hardware

Irom

Ibl

Pbl

Sbl

Kernel

We are dealing with irom and maybe pbl.
[Hardware Hacking General] b4dg3r:
I did a search for "Insert an OTG cable into the connector" and came up with an interesting link. "How to Use USB-OTG Firmware Downloader" It's for a similar uP (S5PC100)

I can't post the URL because I've fewer than 8 posts.

Google "Insert an OTG cable into the connector"

Then translate the page from www[dot]aesop[dot]or[dot]kr "Wiki - USB-OTG Firmware Downloader" For me, it's the 4th result.

There a link to some SW - "DNW" that seems to be for downloading firmware using USB OTG to a S5PC100 on that page.
[Hardware Hacking General] midas5:
I have found out something very interesting:

http://www.armdesigner.com/xsms/html37/uploadfile/20100707120620748.pdf

That pdf document explains how to use the DNW program.

The interesting part of the document is it explains how to get the

"Insert an OTG cable into the connector!" message.

See page 20.

Here is how to get there:

"Turn on Odroid and you can see the below booting message. Be sure to press any key quickly to stop the OS booting process."

Can it really be that simple?

We turn the phone on and press some keys to get to a prompt in the IROM!
[Hardware Hacking General] lilstevie:
that isn't iROM, that is a utility run from u-boot
[Hardware Hacking General] AdamOutler:
Since we have not yet explored any i2c communications and there is a definate external I2C bus.... Here is a link to using an Arduino with i2c. http://tronixstuff.wordpress.com/2010/10/20/tutorial-arduino-and-the-i2c-bus/ I've only read over the top of it so far. I'll be reading more in detail later. This will be useful once we figure out which ones are the the i2c bus.

It would be really helpful if someone could scope out the different pins on the unit during startup.... Here's some of the pins we need while hooked to all 4 factory modes:

While hooked up to USB power

All 4 headphone connections

Batt+

Batt-

BSI(middle pin)

D+

D-

and all connections inside the battery cover

and pin 4 on the usb

While running battery power

All 4 headphone connections

BSI(middle pin)

D+

D-

and all connections inside the battery cover

and pin 4 on the usb

This needs to be scoped so we can see if there is any logic on those pins.
[Hardware Hacking General] Volcacius:
Actually I had a i9000 with broken pbl (later repaired with jtag) that connected to a pc through usb would show itself as "vSEC S5PC110 Test B/D", with ids 04e8:1234. That ID are the same the dnw driver refers to, as it's also shown here (par 7.2.2, point 7) Since iROM is a feature shared by all the s5pc110 boards, 04e8:1234 may be the id used to interface iROM with a USB OTG device, in the odroid case the TTA-20 board, which acts similarly to the anyway jig.
[Hardware Hacking General] AdamOutler:
^^ that's because you flashed a bad pbl. In that case your phone was a dev board without the dev hardware.... it was probly recoverable using the same methods as the dev board but you didn't have the om switches or removable sdcard.
[Hardware Hacking General] TheBeano:
They are able to trigger this mode because they have some handy DIP switches to set the processor's OM register: "Change the boot mode: CPU module MODE SW dip switch". If we could do this we could trigger UART or USB download mode.
[Hardware Hacking General] TheBeano:
Yes that would be proof of the CPU's IROM falling back to its download mode (tries UART first, then USB) if it can't load the PBL (actually the IBL). But this seems to be quite a rare situation or more people would be reporting it.
[Hardware Hacking General] TheBeano:
With the standard Gingerbread (JVB) kernel you should see these messages in the kernel log (dmesg) on attach and detach:

fsa9480 7-0025: dev1: 0x4, dev2: 0x0

fsa9480 7-0025: dev1: 0x0, dev2: 0x0

with different values for dev1 depending on what it has detected. When the resistance is outside the range it detects it doesn't get triggered so it doesn't log anything.
[Hardware Hacking General] AdamOutler:
I should probly already know this... how would I connect up to the dmesg device directly for monitoring of messages in real time? We don't have the screen command on arm platform. How could I set it up to just watch a device and output to the screen?
[Hardware Hacking General] TheBeano:
cat /proc/kmsg , root required I think.
[Hardware Hacking General] AdamOutler:
I was mobile and searching. I could not get that to work. Now I'm home....

It involves using BASH. We include BASH with Andromeda3. You can get bash from the Team Komin Andromeda3 repository here: http://teamkomin.googlecode.com/svn/trunk/system/xbin/bash

Copy bash to your /system/xbin or /data

bash
while [ 1 ]; do
dmesg -c
done

Realtime logging of dmesg is usable with this method... So...

using UART, you can set the SBL SWITCH_SEL to 6543 then boot normally with a 619kohm resistor and it will drop you to a UART shell where you can execute the above commands

Or you can set up a ssh server using quicksshd or sshdroid, then ssh into a shell and execute the above.

Then testing resistor values should be a breeze.
[Hardware Hacking General] midas5:
I found that the adb service was stopped on the phone using certain resistor values.

So, gathering this information via serial or ssh session is more reliable.
[Hardware Hacking General] midas5:
Which email were you responding to with this?

If it was mine, please read mine again.
[Hardware Hacking General] AdamOutler:
I see... so you are saying that a phone could act as an otg device. Then you.plug one phone into another and let one replicate the other using the iron?
[Hardware Hacking General] midas5:
The I9000 can connect to OTG devices using an OTG cable (short-pins-4-5)

So, the I9000 can be in two different modes.

1) Normal "gadget" mode acting as a USB gadget and not a USB "host". The PC is the "host"

2) OTG mode, with the I9000 acting as the USB "host" and another device acting as the USB "gadget".

So, if we have one bricked I9000 with the IROM running in OTG mode, and this in USB "host" mode. We can connect it to a usb "gadget" and talk some special protocol to recover the bricked I9000.

So, we could create our own zImage for the working I9000 to make it look like this special gadget for the IROM.

So, not exactly "replicate" one phone to the other, but just use one I9000 to get the other from "bricked" to "download" mode.

But, all this is jumping ahead. Unless we can get to that "Insert an OTG cable into the connector" we cannot do any of the above.

Has anyone done any work with the IROM disassembly in order to locate the path through the code from boot to printing the "OTG" message.

That path might not needing OM5 to get to the "OTG" message.

I do not believe the IROM will be all that different between a dev board and an actual phone.
[Hardware Hacking General] b4dg3r:
If the IROM behaves like the uP's data sheet says then it checks the OM pins before selecting the source for BL1.

There's a useful flow diagram on page 6-4 of the manual "Figure 6-2 Total Booting Code Sequence Flow Chart" that shows the process.

I think the IROM is completely non-programmable (not even one-time programmable or programmable until a fuse bit is set).
[Hardware Hacking General] AdamOutler:
Since this thread is about saving some bricks... I thought I'd announce that there is now a reliable option for JTAG on the SGS Captivate...

I had these boards made by a member on the hackaday.com forums who goes by the username k-ww.

The cardboard works as a strain relief and keeps the wires from being pulled.

This is a huge step forward for me.

Here's my plan.

1. Next week I'll be scoping all connections on the phone during boot sequence, including the JTAG port. I know there is a RX-TX connection on there somewhere. I'd like to see what it has.

2. apply 5V to each testpoint inside the phone to see if OM=0x9 can be changed.

3. Someone give me some suggestions

4. destroy PBL.

5. attempt recovery

6. send phone in for JTAG if recovery fails.

note: I do not even have a method of using a JTAG port properly at the present time, so please don't PM me about it. Ask someone with a RIFF JTAG box. Member Connexion2005 has one.
[Hardware Hacking General] earlb228:
can someone please help me? im really a dumb ass for doing this in the first place but here goes. i was reading about installing a kernel and tried to flash tytungs kernel to my phone just like u would install a rom. oh yeah, im running ultimate droid 3.3.1. i flashed the kernel and my phone wouldnt boot back up. i made a backup of my original sprint htc evo rom,but when i try to restore it, the phone just boots back into recovery. i had ultimate droid zip on my sd card so i flashed it and it works. im back to ultimate droid. but my phone still wont boot up my sprint backup. is it anything i can do without having to send my phone off for repair?
[Hardware Hacking General] js22:
Sorry I've been so quiet; I'm kinda snowed under at work and getting ready for a trip next week.

My reading of the schematics is that 2 of the un-documented pins on the JTAG connector are copies of the UART Tx/Rx pins that go to the fsa chip; i.e., pins we already have access to.

Don't hook +5V directly to any pins unless you are sure what they are AND sure that +5V is okay. It is very easy to fry a chip by exceeding its voltage limit. DAMHIKT. Also, if you apply a voltage source directly to an OUTPUT, you will be fighting with another voltage source on the chip. Somebody will lose the fight, and it might be the chip.

For probing unknown pins/testpoints, I would recommend taking a +3.3V source, running it through a 10k (???) resistor, and then using the other end of the resistor to probe. Then, if the chip is forcing 0V, the most current you can have is (3.3 - 0)/10k = 3.3 mA, which is probably safe.

Anyways, the JTAG adapter looks very nice. Ultimately, it would be much nicer to unbrick via UART or USB, but at least JTAG is known to work (with RiffBox). The biggest problem with JTAG (apart from cost, and having to disassemble the phone, and using closed source) is the high failure rate of people soldering wires to the board. Using a connector/adapter board looks like a nice way to go (especially for development).

Q : Can you re-assemble your phone with the connector soldered to the board ? IOW, does it fit back together ?

Having a strain relief on the wires is a great idea. I can't tell from the pics if you did this, but for something that will never need to be re-soldered, a great way is to use a big blob of expoxy. Solder joints by themselves are terrible for withstanding strain, and the epoxy spreads the forces out nicely.

I spent a little time a few weeks back looking at open-source JTAG solutions. The closest thing to a working solution that I found is OpenOCD. It works on the TI OMAP chip on a BeagleBoard. This has a ARM Cortex-A8 CPU core (like us), but still the overall JTAG architecture is a little bit different. Getting OpenOCD to work on our phones would definitely take a bit of OpenOCD development work before being usable. To the best of my knowledge, nobody has done this yet. The Samsung chip has a simpler JTAG setup than the TI OMAP, and (surprise) it actually complies to ARM's standards. So there is a chance that with the right configs and some luck it might "just work". It could be worth a try.

As for how to proceed, I don't think messing up the PBL will work. As mentioned before, the iROM will look for a valid IBL, succeed in finding it, the IBL will try to load the PBL and fail, and then (who knows what ???) The main point is that the iROM will not fail, so it will not attempt to boot from the eSSD, UART, USB, etc.

The Riffbox is closed-source, and AFAICT does not provide the option to mess with the IBL. I don't know if Odin allows this or not. But maybe a zipfile approach (like flashnig a new ROM/kernel/etc.) would work.
[Hardware Hacking General] AdamOutler:
I figured i'd share my current test setup.
[Hardware Hacking General] midas5:
Have we all given up on resistors now? I thought one of us had linked a stepper motor to a pot and was testing. Have no new resistor values been found? I have a few more things to try but was hoping someone had struck gold with the resistors.
[Hardware Hacking General] TheBeano:
I did one pass with no 5V on VCC and found nothing, I started another pass but it doesn't detect a resistor change if you keep 5V on VCC, so I have to add another relay to my test jig, which will happen in the next few days I guess.
[Hardware Hacking General] AdamOutler:
hackaday.com articles are right up our alleys today.

I2C 101 http://hackaday.com/2011/05/11/i2c-101/ will help with the I2C-EXT connection

Open Source Accessory Developer Kit http://hackaday.com/2011/05/11/official-android-open-accessory-development-kit-its-an-arduino/ Uses an arduino as a development platform for Android. A bit expensive, but cool none-the-less.
[Hardware Hacking General] midas5:
I would think 3 options might be needed:

1) test all resistor values with no power on VCC, battery connected.

2) test all resistor values with power on VCC, battery connected.

3) test all resistor values with power on VCC, NO battery connected.

I have also found that with no resistor connected, VID is at 3.8V.

I do not think the circuitry inside the phone is a simple resistor. The phone has protection circuitry (e.g. over voltage, short etc).

So, I think that maybe the circuit is a constant current source.

This means that no matter which resistor is connected, it will output a constant current across it. As a result the the volts appearing across the resistor will change depending on its value.

So, can we also measure the VID volts for each R value.

We can then calculate the current in all cases, and see if it is "constant current".

It would also be interesting to find out what range of resistor values work for each detected setting.

The fsa datasheet hints at over voltage protection (OVP).

Now I would not expect anyone to try to hit this limit, but it might be what changes the OM5, but a rather expensive mistake if it fries the phone!

It might cause a "tested to destruction" brick.
[Hardware Hacking General] midas5:
I2C is a very simple protocol. It can be implemented with just 2 tri-state GPIOs.
[Hardware Hacking General] sgsever:
Good, thanks
[Hardware Hacking General] AdamOutler:
I havn't located the EXT-i2c pins yet, but I've come up with a way to snoop the i2c bus.

You'll need bash in your /system/xbin folder http://teamkomin.googlecode.com/svn/trunk/system/xbin/bash

run this in a terminal

chmod 777 /system/xbin/bash
bash
while [ 1 ]
do
cat /dev/i2c*
done

every 11 seconds you can see an invalid length message, which says to me that all 0's are being transmitted constantly to several devices... The ones which are not responding and do not have addresses are 1,3,8, and 13.... those are our entry points onto the i2c bus. Those are the addresses we should likely use. We should transmit to 0 which is all addresses.

This will be useful for finding out which pins are used for i2c.
[Hardware Hacking General] midas5:
Quote from the web:

"History: After a bad bootloaders update, my i9000 died: blank screen, no vibration, no download/recovery mode, anything. The only sign of life is when I connect it to my PC (Windows 7 x64): it detects a new device, SEC S5PC110 Test B/D, which can't be installed and disappear after few seconds."

This is extremely interesting, because the "SEC S5PC110 Test B/D" is output from the IROM.

The message is at address 0x0D00C83C in the irom.

So, this might be the case of the PBL bad, causing the IROM to try and boot from USB.

Does anyone own a bricked i9000 that displays this message?

Also, I saw on another thread, regarding the JTAG. It mentioned pin 10 of the JTAG being the GND, and if pin 9 was shorted (small resistor) to pin 10, it causes the samsung phone (not the I9000) to boot from a different device. I would be curious as to what this pin 9 does on an I9000.
[Hardware Hacking General] AdamOutler:
Well, on the Captivate we've got

pins:

1-??????????

2-JTAG TRST

3-JTAG TDI

4-JTAG TMS

5-JTAG TCK

6-UART TX

7-UART RX

8-GROUND

9-JTAG NRST

10-JTAG TDO

11-??????????

12-??????????

http://www.jtagbox.com/downloads/manuals/i897/i897_pinout.jpg
[Hardware Hacking General] AdamOutler:
I'm looking at jumpering these test points.... Any of them look interesting?

Side of board facing display

Side of unit facing back

btw... looks like the OneNand has a JF6 sticker on it and the OneNand is branded KB1. Those are firmware identifiers (FROYO-UCKB1) which suggests that it was loaded prior to assembly.... however the OneNAND has a newer model then the sticker so it may just be randomness.
[Hardware Hacking General] AdamOutler:
Has anyone tried removing the battery?
[Hardware Hacking General] b4dg3r:
By jumpering do you mean shorting them together with a piece of wire?

If so, it's not something I'd recommend doing. If (for example) they're both outputs which are driving in opposite directions the it might harm the devices due to excessive current flowing. You could also exceed the safe input voltage for a device too by connecting say a 5v output to a 3.3v input. Either of these conditions could blow something up.

As TheBeano posted previously, using a resistor to connect them to a lower voltage rail (or ground) would probably be safe as long as the resistor's value is high enough to prevent excessive current being drawn if the testpoint is being driven high / low.
[Hardware Hacking General] Odia:
Why? You already know Samsung can fix a bricked phone without even opening it, what do you expect to see from jumpering TPs that you dont even understand what they are for ...

It means that JF6 was provisioned in the factory, 99% of Samsung phones have this type of sticker usually white or green, its not randomness at all.
[Hardware Hacking General] AdamOutler:
I want to find the OM pins to enable boot from mmc. If its as simple as a blob of solder on a couple of pins.... that's great. So I tried to get an xray of the board, but the resolution was insufficient to view the traces and be able to see where the processor OM pins lead to.

Ive got an oscilloscope lined up for this weekend. If I can find a 3mhz signal or a 400khz signal then I've found the i2c clock pulse.

Odia, you got any better ideas?
[Hardware Hacking General] AdamOutler:
That's not how digital logic works. You find VCC and apply it to pins. VCC versus VCC = nothing. It takes more then 3v to reverse bias TTL logic which is what were working with. I have not yet seen any ECL. Im sure its there but I've not yet seen any negative voltages.
[Hardware Hacking General] b4dg3r:
If you connect a device's output to another device's output and one is trying to drive the line high (towards VCC) and the other low (towards ground) you could blow something up. You don't know what the test points are and you could easily connect up two outputs in this manner. You could also connect up a 5v test point to a 3.3v device etc. etc. etc.

FWIW I have an Electronic Engineering degree and ten years' experience developing safety-critical embedded systems. I'm quite aware of "how digital logic works"
[Hardware Hacking General] AdamOutler:
You're talking about a short circuit. Im putting VCC behind a 1k resistor. 3.7v @ 1k = 3ma. That's not enough to burn up anything. That's a pull-up jumper.
[Hardware Hacking General] AdamOutler:
Instead of saying its not possible, try making some suggestions. Its more helpful
[Hardware Hacking General] Odia:
Yes, go back over what you already know, because you have dismissed an important aspect.

To change the operation mode you do not need to jumper anything on the PCB, read my last post, e.g. you already know its possible without opening the phone, your going in far too deep and starting to do stuff which does nothing but waste time and will lead to nothing.
[Hardware Hacking General] b4dg3r:
"Jumpering" to me suggests joining two points on the circuit board. I've never heard it used in any other context. Perhaps it means something different in the US and the UK.

I thought you might have meant joining the test points together but wasn't sure. That's why I asked you if that's what you meant in my first response. Believe it or not, my intention was to avoid potential damage to your 'phone, not to be unhelpful.
[Hardware Hacking General] AdamOutler:
It's common sense that you don't just apply voltage without protection. That's a given in circuit bending, otherwise it would be circuit shorting.

Isn't 3.7 /1000 = .0037? 3.7ma?

I've been holding something back from the conversation, for fear of demotivation of this project.... Here goes.

I had a black screen brick here. It acted as though it had no battery. It was flashed with an improper Primitive and Secondary bootloader. Only when the volume up button was held would it display UART output. 301Kohm resistor would not put the unit into download mode. USB would not produce output until the unit was turned on by 619kohm jig + volume up. Even then it would output only jiberish to the USB port on the computer... I verified this with wireshark.

The user stated that there was nothing wrong with the unit. Only a bad flash. The unit worked properly until the bad flash.

Well.... it was sent in directly to Samsung after I had looked at the unit..... Samsung said it had internal problems and it would cost $145 to repair the unit.... I assume they replaced the mainboard. I don't think there's a hidden method that Samsung is hiding from their own service bulletins. I think we must delve into the hardware more. Otherwise They would have unbricked it and sent it back to the user.

Ok.. so... well... What says you?
[Hardware Hacking General] b4dg3r:
That was a typo which is why I edited the post to remove that as soon as I'd posted it.