yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] midas5:
I think it is better than that.

The I2C is a multi-master bus that uses a collision detect method controlling access to the bus and also an ACK from the receiving device. Absence of the ACK would result in the sender probably retransmitting.

So, you should be able to send messages on the bus at any time the device has power, and other devices are not actively transmitting data on the I2C bus.

I.e. Not just during boot up.

For a majority of the time, most I2C buses are idle.

Now, if there is a setting on the fsa that passes the I2C bus out to the USB connector, then this might be a winner.
[Hardware Hacking General] AdamOutler:
I sent an email to fairchild semiconductors earlier today requesting information about that.
[Hardware Hacking General] midas5:
On the development board, can this test be performed.

1) Set the OM pins

2) Boot the board

3) Read the OM register.

4) Modify the OM pins.

5) Read the OM register.

Will (3) and (5) give different results, or will the OM register stay constant until the next reboot.

I.e. Board reads the pins on power on, and puts the read value in the OM register.

The Board never reads the pins after that, so even if you change the PINs, the OM value will not change...until a reboot.
[Hardware Hacking General] midas5:
/*

* Manual Switch 1 (REGISTER_MANUALSW1)

* D- [7:5] / D+ [4:2]

* 000: Open all / 001: USB / 010: AUDIO / 011: UART / 100: V_AUDIO

*/

#define SW_VAUDIO ((4 << 5) | (4 << 2))

#define SW_UART ((3 << 5) | (3 << 2))

#define SW_AUDIO ((2 << 5) | (2 << 2))

#define SW_DHOST ((1 << 5) | (1 << 2))

#define SW_AUTO ((0 << 5) | (0 << 2))

This leaves values of 5, 6, 7, so one of those might connect the I2C to the micro usb port.
[Hardware Hacking General] AdamOutler:
What is VAudio? Video is not connected. This may be the one. Also, i believe TTY or TY2 may have something to do with I2C. I'd like to test that, but I don't have access to an oscilliscope anymore. It would be nice if TheBeano could do this with his setup.

The Datasheet for the FSA9480 chip says that it is programmable using I2C. The block diagram says that the SCL (clock) goes IN, but not out of the FSA chip. The Data line goes both ways. Of the lines available, according to the block diagram, only the middle 3 pins, D+,D- and ID would possibly be connected to the I2C. This is odd... According to the sheet, the microphone into the FSA chip can be gated onto the power line.... Of course we only have a FSA9280 datasheet, so it may be possible that things are different. However, it would appear that ground is always ground and that would make sense as you would not want to have signals without ground.

TheBeano, which values caused the unit to freeze up? This is important.
[Hardware Hacking General] TheBeano:
V_AUDIO connects the phone's audio output to pins 2 and 3 of the USB port, see the patch on the car/home dock thread. Referring to the FSA9480 (U301) circuit diagram in the service manual, AUDIO_L and R are used for the call processor (modem) USB lines. VIDEO, MIC, and ID_BYPASS are not connected.

I don't have an oscilloscope either, but you could try this for an Arduino oscilloscope: http://code.google.com/p/xoscillo/wiki/arduino

It was anything below about 70k, I tested it in batches of 10k and rebooted between tests. I suspect it was caused by noise, as the wires I have hooked up to it are pretty long and the voltage across the lower-value resistors will be pretty low.
[Hardware Hacking General] AdamOutler:
That oscope wont work. The sample rate is 7khz. Which means it can sample a 3.5khz rate max. we are looking at 100kbps, 400kbps, or 3mbps for supported i2c and double bandwidth is required for monitoring those signals... awesome find though. I will submit that to hackaday.com i have not read that one yet.

Who had the oscope earlier in this thread?

That does give me an idea though... Could be clock is the id pin.
[Hardware Hacking General] AdamOutler:
and...... it's on http://hackaday.com/2011/05/21/arduino-i2c-sniffer/
[Hardware Hacking General] AdamOutler:
Your oscope find was featured on hackaday.com yesterday and re-recommended to me by another xda member/hackaday reader today.

No luck with that i2c snuffer. Its good for recording a byte of data and that's about it. Can anyone tell me more about the i2c bus? I just got a new dev phone so im back to work on it. I need some reading material which might suggest entry points on known sensors or test points.

If anyone has an oscope, let me know. There's alot of testing to be done and id like to work with someone on this in real time.
[Hardware Hacking General] midas5:
Does anyone have a broken I9000?

If so, could someone un-solder the fsa9480 chip and do tests on the chip itself.

We could plug power into it and write to i2c registers, try various resistors and measure the voltage on the boot mode pin.

We could also apply logic to the boot mode pin and see if it is actually connected to the OM5 on the APU or not.
[Hardware Hacking General] AdamOutler:
The chip can't be desoldered by humans without highly specialized tools. The i2c bus has no registers. Its a communications bus with the phone. The pins are not accessible. They are ball soldered. Look up that method of soldering. Its used on all chips on the phone. It sandwiches the processor and onenand.
[Hardware Hacking General] AdamOutler:
Im going to be looking at tapping the lines from sensors. Camera, tilt, light, compass...
[Hardware Hacking General] AdamOutler:
gosh, I wish we could unlock all the secrets of the FSA-9480 chip.
[Hardware Hacking General] TheBeano:
So it seems quite likely that:

BOOT_ON in the resistor constant name does indeed mean the BOOT pin is on, so the BOOT signal from the FSA9480 will be high for 619K and 301K resistors on the ID pin, no other external inputs required

The MANUALSW2 I2C register that we were playing with earlier does indeed set the BOOT pin high and low.

So, the BOOT pin from the FSA9480 is not directly connected to the OM[5] pin. If it does affect it at all, as was hinted at by the BOOT_MODE signal on the block diagram, then there is some additional logic involved somewhere.

The phone boots up automatically with the 523k (BOOT_OFF) and 619k (BOOT_ON) resistors. So the BOOT signal, if it is used at all, doesn't tell the application processor to boot up.
[Hardware Hacking General] AdamOutler:
True. I think the boot signal is a signal for the kernel to start battery charging display, or actually boot Android.
[Hardware Hacking General] TheBeano:
It loads the battery charging kernel if the JIG signal is off and the power switch is off, and it has power on the USB socket (VBUS_IN). It's the JIG signal that switches on the phone automatically in the factory modes, we know this from the circuit diagrams in the service manual. So the BOOT signal goes somewhere else.
[Hardware Hacking General] AdamOutler:
Then why do the "boot off" resistors only activate charging mode and not boot?

The kernel loads up whenever power is applied. The boot on resistors actually turn the phone on.
[Hardware Hacking General] TheBeano:
Yes, I should say the JIG signal switches it on when there's no USB power. If there's no USB power then the BOOT_OFF resistors still switch the phone on. But after the SBL is loaded all the decisions are made by reading the resistor value through I2C, so there's no need for the BOOT signal at that point. So it must be doing something else.
[Hardware Hacking General] AdamOutler:
Do you agree that i2c over USB is not looking possible?
[Hardware Hacking General] TheBeano:
Yes it seems very unlikely that there is anything like that supported by the FSA9480.
[Hardware Hacking General] AdamOutler:
I'm still exploring for i2c, it's cheaper then JTAG, and, according to Google IO, its supported by the Android Open Accessory Standard ( which is an Arduino mega + usb shield + extra crap.. the extra crap brings the price to $400). So, it still makes sense to explore that.

Since the chip has a maximum i2c speed of 400khz, and the processor has a maximum i2c speed of 3mhz, 400khz would be the logical i2c bus speed on the platform. The following modification is required for Arduino to communicate at this speed:

under linux:

1. edit the twi.h in the wire library

sudo gedit /usr/share/arduino/libraries/Wire/utility/twi.h

2. change line 32 from

#define TWI_FREQ 100000L

to

#define TWI_FREQ 400000L

Speed is set to 400khz for any arduino sketch compiled there after.
[Hardware Hacking General] midas5:
But, what if the meaning of the resistors is documented wrongly? Have we really exhausted all options?
[Hardware Hacking General] midas5:
Things we still need to prove.

1) is the om5 register changeable after boot or is it fixed at boot time? If it is fixed at boot time our current tests have been wrong .

2) Have we methodically gone through every resistor value and determined which output uart and which output usb or something else. I.e. Done it, ignoring the current possibly wrong docs.

3) We need to document what tests we have done and get a second person to verify then. For example, we have not tested the 301k resistor because it does not reach a point where we can read the om5 mode.
[Hardware Hacking General] Odia:
You guys are so far off the mark its unreal.

What EXTERNAL interfaces do you have on the phone?
[Hardware Hacking General] AdamOutler:
The options are getting more and more narrow... We know for a fact that the i2c bus does not go through USB. It ends at the USB switching controller... The FSA9480.

So how do we get a phone to boot from something OTHER then OneNand when a bad PBL/SBL has been flashed?

Brick Recovery Possibilities:

external connections

USB UART

USB I2C

USB USB

BSI(Middle pin on battery)?

round connector on back of unit?

headphone jack?

Bluetooth?

External I2C?

internal connections

UART

direct connection with OneNand

direct connection with processor

replacement of OneNand

internal I2C <----High probability of sucess, low cost, supported with Android Arduino dev kit

OM register modification to enable boot from USB/UART/MMC via circuit bending?

Confirmed:

Internal JTAG (ol' faithful)

What do you want? You're not helping Odia, and I don't believe you know anything else.
[Hardware Hacking General] TheBeano:
OK... so if we accept that the OM register and the FSA9480 is a dead end, maybe there's another way to disrupt the NAND bootloader loading process in the IROM so that it will fall back to the other options.

I don't have much time for this at the moment but I would encourage others to look at the IROM closely for alternate paths that could cause the OneNAND load to fail. Looking at it again I notice I picked the wrong "Normal" boot path for the SGS, the default OM register value (9) causes it to start at D005B60, which is the boot from "OnenandMux(Audi)" that we see in the PBL output. This has a fallback to SDMMC and UART/USB.

So, something to do with the battery or power management that will not stop the processor but will cause the OneNAND to fail to init or read? The MAX8998 PMIC is (of course) a proprietary chip with no datasheet available but there's a fairly complete schematic of it in the service manual.

Or some other external input that's read during the OneNAND boot process that I've missed?

If the OneNAND load fails you should see the error message on the USB serial port, "OND Check Sum Error" or similar. You will need the 619K resistor connected to the USB port to get the serial switching active so you can see this message.. but then this might interfere with the boot process... :)
[Hardware Hacking General] midas5:
The external interfaces are:

1) micro usb

2) micro sd card interface

3) Battery terminals

4) Headphones socket

5) Rf aerial socket.

We know that factory mode resistors are detected without usb power supplied.

I think we should look more into how to boot from the micro sd card slot. So, look in the irom to see how the sd card should be formatted to allow the irom to boot from it, and then try some resistors.
[Hardware Hacking General] midas5:
From the circuit diagrams, jig output does the power up.

Also usb power alone causes it to boot into "charging" mode.

We still don't know what the boot pin is connected to.
[Hardware Hacking General] Rebellos:
I'm playing with S8530 motherboard for few days now. It is almost impossible to find OM pins connections without unsoldering almost everything or getting internal schemas (no way to leak them all, these are very well protected and available only for Samsung local departments, it probably isnt even possible to make screenshots during viewing, only making camrea shots of screen).

I haven't found yet even FSA9480 :/

The thing is that Samsung seems to hide infos about FSA9480 even from Level3 Services, there isn't any info except one box in general schema. Probably thats the difference between 9280 and 9480 ordered by Samsung - more/different resistor switch modes. I'm playing with all types of resistors now dumping OM reg dynamically, I hope it isn't being changed only during boot, that would be complicated then.

Btw. Maybe it's just me and my hope, but handset seems to take more time to restart if I toogle BOOT bit and software reset (Manual register of FSA stays the same as before reboot). However it isn't very helpful, as setting of BOOT bit requires executing code, which isn't possible when first stage of PBL is broken. ;s
[Hardware Hacking General] AdamOutler:
I know this is not even an idea to explore, but if you look at this article http://hackaday.com/2011/05/27/low-cost-low-bandwidth-wireless-arduino-to-android-communications/ someone has manage to establish communications over the magnetometer... Good thing it's not even something we need to worry about on the SGS/Captivate/SGS2
[Hardware Hacking General] Odia:
Your missing one more external interface.
[Hardware Hacking General] androcheck:
Do you count pressing buttons (or combinations of buttons) as interface?
[Hardware Hacking General] nmcc89:
What about the SIM slot? I have no idea how that would work but it's an external interface right?
[Hardware Hacking General] midas5:
Well, the buttons would be an interface.
[Hardware Hacking General] midas5:
I guess someone should look at if the irom looks at button inputs.
[Hardware Hacking General] Odia:
BINGO! At last :)
[Hardware Hacking General] Odia:
I'm pretty sure buttons are an interface :rolleyes:

But it was not the one I was trying to direct you guys too :p
[Hardware Hacking General] nmcc89:
You can call that beginner's luck. I've been following this for a little while now and it's been interesting, I don't have any electronics experience or development experience but I do have a fully bricked 8GB I9000. I managed to do it 2 weeks after I got my phone from Vodafone (in Sept '10) trying to enable the 3BR from Richthofen's thread using the update.zip method (which I think has now been removed - I believe I was one of the unlucky few with an e-fused phone, but I haven't read enough to understand exactly what I did). I was stupid, and didn't read the whole thread first - very sharp learning curve.

Anyway to cut a long story short I have a 16GB I9000 that does work (after a bit of wrangling Vodafone gave me a new phone) and they forgot to take the old one. They didn't seem particularly fussed when I told them, and the return packages they sent out (3 to date I think) haven't arrived either, which again they weirdly weren't bothered about - I just gave up phoning them to tell them. So I've acquired a paperweight which has been sitting in my drawer for 8 months, but I'd be very interested in any way of recovering it economically (I can't afford/be bothered to get it done by JTAG) so that I can use it as a test phone or something. I'd love to help if I could but I doubt I'd be much use, like I said I'm a basically a complete newbie (just an end user of custom ROMS/kernels etc) and I'm still wary Vodafone may eventually want that phone back so I don't particularly want to open it up or anything like that.
[Hardware Hacking General] AdamOutler:
Working on it..... gotta finish my DIY anyway jig first
[Hardware Hacking General] AdamOutler:
Hrm.. I could not edit the picture because firefox would not allow refresh... So, I deleted the old and edited a new picture. Here's the pinouts

Now.. this is purely speculative, but I see a clk and io pin on that.... What external 2 wire interface have we been looking for that has clock and io pins?
[Hardware Hacking General] midas5:
I think the USIM interface uses ISO7816 and not I2C. It is closer to UART than I2C. In ISO7816 the clock is a constant conventional clock signal that is normally some multiple of the UART baud rate.
[Hardware Hacking General] midas5:
If the USIM is involved in the boot process, it might be worth checking the irom for which interfaces it talks to.
[Hardware Hacking General] TheBeano:
The SIM isn't directly involved in the boot process, it's connected to the call processor (service manual p29, UCP100, sim_clk, sim_io, sim_rst from radio cc_clk, cc_io, cc_rst). The power supply is shown as CP_VSIM_1.8V , but pin 1 of the SIM doesn't go high at the start of the boot process so it must be set up later. Pullups and pulldowns on any individual SIM pin didn't affect the boot process when I tried it.

Possibly it is switched through the PMIC: the S8500 service manual shows the SIM signals going through a second analog switch in the PMIC to the AP UART #3. But that may not apply to this phone, and there's no sign of any UART other than #2 being used in the IROM, though I could have missed it.

My guess is that something on one of the SIM pins tells the PMIC to switch off the power supply to the OneNAND (there's a separate supply line on the CPU for this, VDD_M0), or otherwise disables OneNAND. That would make it try to boot from alternate sources. Of course all my previous guesses have been completely wrong. :)
[Hardware Hacking General] Odia:
Inspect the IROM again using your new found news, I am sure you will spot something.
[Hardware Hacking General] AdamOutler:
useful tools for flashing under windows

These downloads may help. I've collected them from various sources across the internet. I have not yet got my phone to communicate with them yet.

These are all windows tools

Hyperterm- establishes serial communications

moviNand_FusingTool & 512k version- creates a bootable disk

AttachHeader & windows-dltool- communicates with usb and uart on dev board
[Hardware Hacking General] AdamOutler:
Pin 1 has 3V

pin 2 is for sure an input for RST, It looks like it is a open input. It is not pulled up or down oddly.

Pin 3 requires more work to get something out of it. It seems to jump high and low every once in a while during boot.

Pin 4 is ground

Pin 5 requires more work... It seems to jump high and low during boot

Pin6 Using UART communications on the IO pin, this occurs when the ROM starts booting

5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A|4B|5A||

Very odd.. that's binary 0001 1010 0100 1011.. I need to read that ISO documentation to understand it better.
[Hardware Hacking General] b4dg3r:
The line control registers for UART channels 0-3 all seem to be referenced in the irom.

From the uP data sheet

ULCON0 = 0xE2900000

ULCON1 = 0xE2900400

ULCON2 = 0xE2900800

ULCON3 = 0xE2900C00

And from the irom dump

ROM:0D0056C0	LDR R3, =0xE2900000

ROM:0D005714	LDR R3, =0xE2900400

ROM:0D00575C	LDR R3, =0xE2900800

ROM:0D00579C	LDR R3, =0xE2900C00

ROM:0D005D34 dword_D005D34 DCD 0xE2900000

ROM:0D005D38 dword_D005D38 DCD 0xE2900400

ROM:0D005D3C dword_D005D3C DCD 0xE2900800

ROM:0D005D40 dword_D005D40 DCD 0xE2900C00

Is the irom setting up and using all 4 uart channels?

What do we know about the boot process for the baseband processor?
[Hardware Hacking General] AdamOutler:
The boot signal is supposed to turn on the baseband processor.
[Hardware Hacking General] TheBeano:
Yes there are two subs at D0056B8 and D008a2c that take R0 as the UART number (0-3) and set up the hardware for it. I've only found calls to them with R0=2 though.
[Hardware Hacking General] AdamOutler:
ISO7816 specifies 4.75v-5.25v. This uses 3v.

Table 5 - Electrical characteristics of VCC under normal operation conditions.
,--------+---------+---------+-------,
| Symbol | Minimum | Maximum | Unit |
+--------+---------+---------+-------+
| Vcc | 4.75 | 5.25 | V |
| Icc | | 200 | mA |
'--------+---------+---------+-------'

I will keep studying though.
[Hardware Hacking General] AdamOutler:
next to the MMC card, I found something called "TP". I've found that shorting it to ground resets the phone. It's separated from battery power by 1000ohms of resistance, and it floats high. I believe it is intended as a reset button.
[Hardware Hacking General] b4dg3r:
I've not found any calls to those subs with r0 != 2 either. I think it would be odd for the code to handle the other uarts to be there yet unreachable though; I presume the irom contents to be both generic and well-optimised. I can't see why dead code would be in it?

That code might reachable but in a manner that isn't easy to detect statically (by us or the disassembler.)

It could be something like a BLX R? instruction (branch with link to an address specified in a register). There are a few BLX instructions but none that look promising so far.
[Hardware Hacking General] TheBeano:
Ha! They actually have a complete duplicate set of UART2 bootloader download subs, except that the download goes to 0xD0020010 instead of 0xD0020000, and the top level sub is unreferenced. It's bizarre.

Anyway I can't find any trace of code in my IROM that accesses UART3, or any code in the default boot sequence that would check for any serial activity before loading from OneNAND. I did find that the SBL reconfigures UART3 as one of its first actions which does give the idea some credence.

But I'm wondering if there are different revisions of the IROM code. Does someone with a recent phone want to dump their ROM and compare it with the one I posted here? Instructions are in the post I linked to. It would be interesting to see if the US variants (Captivate etc.) are different too.
[Hardware Hacking General] midas5:
I have written a tool that converts x86 binary to C code. When i get a moment, i might write an ARM input plugin for it. It works by converting each input instruction to a small instruction, and then executes it. It should handle BLX instructions well. I am sitting on a beach right now so bit difficult writing the code right this second.