yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] Odia:
I say it was taken to a service centre who are not fully up to speed with the latest handsets, this is off topic but it explains well how some Samsung Service Centres are useless ...

Back in the days when the Samsung U600 was introduced which was one of the first Trident platform phones to use the new MSL security, where the MSL was shadowed in the E2P (shadow copy of the OTP area) one of my friends wrote a new E2P to his phone and it made the IMEI 0044... at that time it was not known that the shadow was a manipulated version of the S/N (not IMEI), so he took the phone to a local Samsung Service Centre who could not fix it and they sent it to Samsung UK, who said the phone was a prototype and the customer should never have had it, my friend explained to them that it was on Orange contract and supplied by Orange, Samsung requested proof of this including IMEI details of the contract, these details where given and 3 month later Samsung UK returned the phone to the Service Centre unrepaired, saying give it back to the customer. By that time we had already found the algo to match the MSL S/N to the shadow copy in the E2P and I fixed it for him in 5 minutes.

So as you can see Samsung Service Centres dont know all the details and in this case nor did Samsung UK.
[Hardware Hacking General] AdamOutler:
That story just says to me "Samsung has been wrong in the past". This isn't new equipment. My board was made in early 2010. The i9000 was announced in early 2010. It's over a year old now.

We've shot down UART as a possibility of recovering bricks or booting from other sources (with the exception of the SBL).

I can't read Assembly language

We don't know how to trigger OTG booting

We don't know how to trigger MMC booting

We don't know how to destroy the PBL which would trigger MMC booting

We don't know how to get commands into the registers without JTAG

Pretty much we've got:

if SBL works, 301K resistor

if SBL works, UART is capable of putting the phone into download mode, or loading from other sources in the SBL prompt.

JTAG always works, but it's expensive.

Possible on-board hardware pins which would trigger MMC/USB booting- about 30 pins which need to be tested

Possible external i2c bus which could be of 3 different baud rates, on 25 pins, in master and slave mode and it's two wires. In order to test every combination, that would be over 300 different tests to perform.... And that's after we figure out what causes i2c to be triggered.

I'm not going to do 300 tests of i2c without some confirmation that it works. We have a bunch more tests to perform in order to figure out what causes i2c booting before that.

I'm going to be scoping the external outputs of the phone on bootloop tonight and reporting the values. If that shows nothing, then I've got no other options then to jump into the hardware.
[Hardware Hacking General] midas5:
Hey, want to play a game? Who has been closest to the solution? ;-)
[Hardware Hacking General] AdamOutler:
Nothing scoped on external pins. Nothing scoped on internal pins accessible when in an operational state. The startup blip i saw from my led was simply a saw wave. It goes low, then ramps up and it goes high then ramps down on pin 3 when power is applied to usb.

My efforts have an extremely low WAF(wife acceptance factor). Ima bend the circuits a bit then Im done with this project.
[Hardware Hacking General] midas5:
Lets think about how we would design this. I would choose the simplest solution. To me uart is not the simplest. We have to play with things like rs232 to 3v level converters etc. I thing the simplest solution is a usb cable with a particular resistor in it. So i think we should look now at factory mode usb . As someone has access to uart from the jtag now, we could now try the boot usb resistors .
[Hardware Hacking General] armacatangay:
unable to restore from nandroid back up

I am on Tweaky Rom 3.2 ( with Voodoo Kernel, CWM2.5.1.3 and ext4 enabled, I don't have external sd card)

I just flashed an additional mod but it gave me bootloops on the first boot screen (the white galaxy s logo). Tried to restore a nandroid backup but it is not going through, all i get is.....

Restoring datadata

.android_secure.img not found. Skipping restore of /sdcard..android_secure.

Restoring cache...

sd-ext.img not found. Skipping restore of /sd-ext..

Restore complete

Help please!!!
[Hardware Hacking General] lilstevie:
To be honest with you the easiest thing would be to get our hands on a samsung anyway s100 or s101 box and capture everything it does
[Hardware Hacking General] armacatangay:
Is this the right section for this... Apologies if it is, noob member here...
[Hardware Hacking General] Odia:
No because this is a serious thread not a playground.
[Hardware Hacking General] midas5:
I have a I9000.

I have looked at the usb IDs of the phone.

Running, with application->developement-usb debug off:

04e8:6877

Running, with application->developement-usb debug on:

04e8:681c

Powered off, but with battery charging:

04e8:681d

Perhaps, if we can get the IROM to boot from USB, the usb IDs will be a different number.
[Hardware Hacking General] midas5:
What we know about the FSA9480.

It is called U301 in the I9000 diagrams.

The inputs to the U301 that we have access to without unscrewing things.

The battery connector:

V_BAT

The USB connector:

USB_GND

USB_ID

USB_D+

USB_D-

USB_VCC

The outputs that we are interested in are:

JIG

BOOT-MODE

We can already drive JIG output, because this is used to turn the phone on via a USB port resistor.

Another way of turning the phone on is via the "OK" key, know to us as the Power on button on the side of the phone.

This leaves us with how to get "BOOT-MODE" triggered.

To this end, I think we are still waiting for someone with a variable resistor to try all resistor values, with and without USB_VCC and with/without a battery.

I will try a few resistors this weekend, but I only have a few different values.
[Hardware Hacking General] AdamOutler:
Captivate JTAG pinout update

pins:

1-3v

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-.2V???????

12-4.3v??????
[Hardware Hacking General] midas5:
Are you able to get some uart output with 255k and 301k resistors?
[Hardware Hacking General] AdamOutler:
I posted the 301k log earlier.
[Hardware Hacking General] midas5:
I was asking, because 301K without power on usb seems to take a different amount of time to reach the download picture than with usb power.

I was thinking that maybe this time was spent trying to boot from usb before onenand.

The time difference is only about 0.5 seconds.
[Hardware Hacking General] midas5:
Which post number. I would prefer not to look through 340 posts to find it.
[Hardware Hacking General] AdamOutler:
right here: http://xdaforums.com/showpost.php?p=13668624&postcount=305

Well, I was using a 1.5kohm jumper to bring testpoints high while monitoring the OM=0x9 value on the UART. and i sneezed.... brick. It just stopped working. I don't know what I touched, but I shorted something near the speaker, or I touched something running on ECL which would create a difference of about 5V @ 3.3ma. I doubt 5V, 3.3ma burned anything out, so I must have shorted ground to something. Either way, my dev phone is a brick.
[Hardware Hacking General] jutezak:
There is no ECL logic in a phone, as ECL is a high-power (and old) way to do logic. Typical power supply current for a simple 4 gate chip would be 14 mA, which would eat a lot of the power budget in a phone.

But there may well be negative voltages for example for power amplifiers.

Still: with 1.5K in series it is unlikely to be the cause of a defect, as logic can usually withstand ESD pulses that are a lot stronger than 5 milliamps.

But there may well have been a random configuration change because of a random crash while booting...
[Hardware Hacking General] TheBeano:
That sucks, sorry to hear it. There is a basic troubleshooting procedure in the service manual, maybe try that in case it's something fixable e.g. the power management IC? You still couldn't fix it yourself since you can't get the parts but at least it might be cheaper to get it fixed.
[Hardware Hacking General] TheBeano:
I've finished a couple of passes with +5V on pin 1 with no hits on the OM register. I previously did this with no +5V to similar lack of results. So I think we can say there isn't a "secret resistor" that triggers this. Unless of course the BOOT pin is disabled after the FSA9480 is reset by the OS. :)

I'll try some tests with different resistance values across pins 2 and 3, on the basis that this is shown in the FS9280 data sheet as one of the inputs ("charger detect") into the "Switch Control" block. I thought of a way to automatically test the response to resistor values at boot time, by switching the battery voltage off and on and using a light sensor on the screen to see whether it boots or not. But that might be overkill. Actually I guess I could just look for serial output and switch it off if it isn't the IROM bootloader protocol.

Here's the current (MK2) test jig:
[Hardware Hacking General] midas5:
I have had problems getting various resistors recognised.

It appears that the fsa chip gives up after a bit of testing. Then requires a power cycle with battery removal.

This makes it difficult to automate tests.
[Hardware Hacking General] Odia:
Are you sure its a brick? "A Brick" is usually caused by software damage, but in your case its 100% hardware, sorry could not resist it since with your sig, it seems you hate people using the term incorrectly ;)
[Hardware Hacking General] AdamOutler:
^^ Yes, I'm sure. My phone = brick. It performs the exact operational functions as a brick. It has no output and it seems to take no input. It is sturdy and it takes up space. That's a brick. Software or hardware, if it's displaying something, then it's good for a picture of whatever it's displaying. A brick is good for nothing.

As suggested earlier, it could have been a hardware triggered software issue.. Maybe I should send it for JTAG instead of repair?

Perchance can you repeat the test with the middle pin on the battery?

The phone will bootloop with the middle pin disconnected. Using UART you can see the OM9 values. Occasionally it will boot.. every 20 cycles or so. You may be able to monitor functions after booting. the BMI pin may perform a functional role in some sort of fashion.
[Hardware Hacking General] Odia:
I have never seen a brick with JTAG PADs.
[Hardware Hacking General] connexion2005:
Lol. Fail on Samsung for the typo:

Copyright (C) Samsug Electronics Co., Ltd. 2006-2010

@oard Name: ARIES REV 03

Build O`: Feb 1 2011 10:54:21
[Hardware Hacking General] Odia:
Thats caused by noise, not typos.
[Hardware Hacking General] dully:
Hi i need help. I was flashing my galaxy s and my battery fell out and now it is jist in an idle state. would the usb jig work?

Many thanks
[Hardware Hacking General] AdamOutler:
Whatever you see on your screen, search for that... we are doing research on hard bricks here. This is not a first stop for troubleshooting... however if nothing turns up, pm one of us..

Im hoping Samsung takes notice of this thread. http://xdaforums.com/showthread.php?t=1081892
[Hardware Hacking General] connexion2005:
Even though it was correct in every other spelling?
[Hardware Hacking General] AdamOutler:
From what I'm seeing on the bada project... the battery is I2C bus ID#3.
[Hardware Hacking General] AdamOutler:
I contacted one of the BADA guys... He seems very helpful.

Check this information out. Very impressive.
[Hardware Hacking General] Rebellos:
Thanks for great work, little clarification:

4 bytes are in fact DWORD size of data transferred through UART, it has to be more or equal than 6 bytes and less or equal to 0x15406 :)

Ain't sure if the size of data should contain the 4 size bytes, probably yes

because it is substracting 6 from received size, then compare it to 0x15400 and looks like tries to receive exactly received_size-6

(to be checked experimentally by someone with JTAG & I9000 - needs huge oneNAND PBL damaging, probably erasing it totally will do)

At the end of data transferred from PC to UART the 16bit checksum is transferred and compared to the checksum calculated during receiving bytes before (excluding 4 size bytes)

So, basically, there isn't internal checksum stored inside iROM, it is used only to validate if all data were transferred correctly.

The pseudocode for UART transfer is as following, every next step is executed if the step before succeed.

checksum code in receive_bytes

After UART receiving there are alot of checks that can cause Secure Fail Error or similiar and phone hang.

Magic 0x12345678 is indicator that correct code has been loaded, it is stored there during normal boot after copying next stage iROM code there.

The advanced integrity/signing checks seems to be NOT used in iROM, or I haven't found it yet. Thanks to Samsung, all in all, they could implement RSA or SHA signing there...

I'm not sure what's more is checked in received code, or are there just alot of environment preparing and just executing it from 0xD0020000, gotta look inside later.

Anybody with JTAG and brave enough to test my theory? I can try to write simple code that will write one byte to UART, that would indicate it has been executed. Altough IBL should write anything to UART informing it can't find PBL and is doing recovery boot.

But yes, it is almost sure now that totally bricked phone can be reflashed using special box in few seconds, just curious why it haven't leaked yet from some service, maybe it is available to most trustable services, only those which has got access to internal schemas.

//edit:

S8530 and I9000 IBL are 100% the same. Probably S8500 too.
[Hardware Hacking General] lilstevie:
P1000 has an identical iROM too
[Hardware Hacking General] TheBeano:
What is different is in the block diagram in the S8500 and S8530 service manuals, there's no BOOT signal shown from the FSA9480, but the USB ID pin is shown going to a block marked "JTAG FOG" as well as the FSA9480. Anyone know what that is supposed to be? It isn't shown like this at all in the I9000 service manual, only the RXD and TXD lines are shown going to JTAG points but we knew that.
[Hardware Hacking General] TheBeano:
Thanks for the analysis, that will help a lot if we get to the point of needing a serial download program. The problem at the moment is still that we don' t know how to trigger the IROM download mode when the phone is already bricked, which is usually caused by someone writing the wrong or corrupt PBL or SBL. In cases like this the IBL, which is what is checked by the IROM, is still OK so the IROM will load and launch it, and the IBL will load and launch the bad PBL/SBL, which crashes. So while it would be cool to see this protocol in action by deliberately corrupting the IBL, it would not actually solve the bricks problem.
[Hardware Hacking General] lilstevie:
that's why triggering it via usb_id is still needed,

I have a feeling that what ever it is triggered by is sent down pin4, on the tab on the 30pin connector it accessory_id (does the same job as usb_id) is also connected to jtag_usb_id
[Hardware Hacking General] midas5:
pin4 on the Micro USB connector would seem to be the most likely one.

The trigger we need is to force the IROM to boot from USB/UART instead of the internal onenand flash.

Has anyone managed to do this on any mobile phone, samsung or otherwise that contain this fsa9480 chip?
[Hardware Hacking General] androcheck:
Maybe this can help us further:

In the fsa9480 driver sourcecode (froyo and gingerbread) I saw that there are 2 registers for manual switching defined:

REGISTER_MANUALSW1 (0x13) and REGISTER_MANUALSW2 (0x14).

In our kernel only one of them is actually used (MANUALSW1). REGISTER_MANUALSW2 never gets written on our phones.

When googling around I found another driver sourcecode for the fsa9480 here.

There you see a write to the REGISTER_MANUALSW2 register (see line 355) which is commented with: "/* BOOT_SW : High , JIG_ON : GND */"

May this indicate that we could switch the BOOT pin by writing the REGISTER_MANUALSW2 register with: (0x1 << 3) | (0x1 << 2)?

I know this won't help us if we have a brick and have no way to access the i2c bus. But at least we could try this on a running system and confirm that the boot pin really goes to the OM[5] pinf of the cpu.

Anybody wants to try? :)
[Hardware Hacking General] AdamOutler:
we need to compile a custom kernel and test the resistor value anyone got a i9000 kernel source handy? i have a captivate. Thebeano has a setup for testing those kernel messages
[Hardware Hacking General] androcheck:
On Froyo I had running a self compiled kernel but I switched to Gingerbread recently and since then I still did not manage to get a own kernel booting.

I will write a small patch and switch back to froyo for trying this. But this cannot be done before the weekend as I only have one phone which I need during the week and I don't want to start an operation like this "quickly" in the evening, as things always tend to need longer than thought.. :o

The plan is to patch the fsa driver to be able to write the register 0x14 to the value 0x0c ((0x1 << 3) | (0x1 << 2)) via a sysfs file and then try to read the OM register with memview.

If this is succesfull we at least have the confirmation that the fsa chip boot pin is connected to the right pin on the processor.
[Hardware Hacking General] androcheck:
Wait..

I just realized that we have already the possibility to read and write the registers of the fsa9480 chip from the SBL commandline!

The 2 commands are usb_read and usb_write!

SBL>
SBL> help usb_read
* Help : usb_read
* Usage : usb_read reg
Read the usb ic register

SBL>
SBL> help usb_write
* Help : usb_write
* Usage : usb_write reg, val
Read the usb ic register

SBL>
SBL> usb_read
---------read fsa9480 register : multiple
(0x0 : 0x0), (0x1 : 0x28), (0x2 : 0x1e), (0x3 : 0x0),
(0x4 : 0x0), (0x5 : 0x0), (0x6 : 0x0), (0x7 : 0x1c),
(0x8 : 0x4), (0x9 : 0x0), (0xa : 0x0), (0xb : 0x8),
(0xc : 0x0), (0xd : 0x0), (0xe : 0x4), (0xf : 0x0),
(0x10 : 0x0), (0x11 : 0x0), (0x12 : 0x0), (0x13 : 0x0),

SBL>
SBL> usb_read 0x14
---------read fsa9480 register : (0x14 : 0x0)

So.. would this help us if we were be able to set the BOOT pin from the SBL commandline?

If I am rigth the command

usb_write 0x14 0xc

should do it and set the BOOT pin to high (hopefully). But I did not try it (yet)!

If anybody wants to try - DISCLAIMER:

BE CAREFUL! Be aware of the risks! I'm not responsible if anyone here bricks his/her phone!!
[Hardware Hacking General] TheBeano:
Yeah, coincidentally I have a working Gingerbread build environment but just switched to Cyanogenmod 7 and can't get a kernel build working. Sigh. :)
[Hardware Hacking General] TheBeano:
It is worth a try and you can't really hurt anything doing that, but it won't have any effect on the boot process at that point (SBL) and the chip gets reset by the driver when the kernel loads.
[Hardware Hacking General] androcheck:
Of course, I was aware that this won't influence the boot process anymore, I just was hoping that I can see some different OM value.

But you are right. I forgot that the fsa driver in the kernel resets the fsa switch during boot. So when Android was booted up the OM register was still (or back) at 0x09.

So we should try this from within a running kernel.

For reference:

This were the commands I tried in the SBL commandline:

usb_read 0x14
usb_write 0x14 0xc
usb_read 0x14
nkernel
boot
[Hardware Hacking General] midas5:
Can you read the OM setting from SBL ?

Regarding modifying the kernel. I was going to try that next. I was going to do

Echo 5 > file-1

echo 4 > file-2

That would write a 4 to reg 5

cat file-2

would read it.

We could then test with all sorts of values .

The problem i see is if the chip remembers the setting over a reboot. We could brick the phone quite easily that way.
[Hardware Hacking General] TheBeano:
I tried it using i2c-tools:

# i2cset -f 7 0x25 0x14 0xc
i2cset -f 7 0x25 0x14 0xc
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will write to device file /dev/i2c-7, chip address 0x25, data address
0x14, data 0x0c, mode byte.
Continue? [Y/n]

# busybox devmem 0xe010e100 <--------- this is the OM register
busybox devmem 0xe010e100
0x00000009

# i2cget -f 7 0x25 0x14
i2cget -f 7 0x25 0x14
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-7, chip address 0x25, data address
0x14, using read byte data.
Continue? [Y/n]

0x0c

Not very encouraging. :( I've attached the i2ctools programs if anyone wants to play. They are linked statically which is why they're so large. Source and docs on http://www.lm-sensors.org/wiki/I2CTools

Edit: I should probably add this warning from the i2ctools docs:
[Hardware Hacking General] midas5:
If you look at the fsa9480 driver source code, it looks like you have to switch the chip from "auto" mode to "manual" mode before it uses those switch values.

I don't have it with me right now, but it would probably be:

i2cset -f 7 0x25 0x14 0xc

i2cset -f 7 0x25 another-reg manual-mode.
[Hardware Hacking General] AdamOutler:
Manual mode.... Would that be a factory mode?
[Hardware Hacking General] midas5:
From the source code it looks different.

Auto mode - fsa9480 does switching based on resistors.

Manual mode - fsa9480 ignores resistors and switches based on a register setting.

There are 2 registers (MANUALSW1, MANUALSW2) to say which switch is used when in manual mode.

There is a different one to switch from Auto to manual and back again.

What we are hoping for is that one of the manual switch settings will change the "boot mode" pin state. If that happens, we then know for a fact that the fsa9480 is in fact linked to OM5. It gets us a little closer to our solution. The solution being finding which resistor sets OM5 while the fsa9480 is in "auto" mode.
[Hardware Hacking General] TheBeano:
Good point, I went through the code that was linked to earlier and set the control register (0x2) to 0x1a which is manual. This definitely affected the port as it switched off adb over USB. But setting MANUALSW2 to 0xc, 4, and 2 didn't change the OM setting after that. I did try connecting a pullup to to the ID pin, and earthing it, in case it was just switching the ID pin, but this didn't work either.
[Hardware Hacking General] midas5:
The Beano,

Are you able to post the IROM binary.

Tell me where the start point is and what location in memory it is supposed to run from, and I will take a look. We can then share info.

A snapshot of the first disassembly screen would also be useful.

I have written a tool that converts binary files to C code, but this currently only works on x86 32/64bit code in .elf files and kernel modules. It does not currently do 16bit x86 code.

I think I will try adding an ARM input filter, and use the IROM binary as my first test input.
[Hardware Hacking General] TheBeano:
Sure, here is the IROM binary. This was dumped using the program from http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/ . The code runs at 0xD0000000.

The main UART boot loader download code starts at offset 0x8640. At this point R0 is the UART number (2), R1 is the value for the baud rate divisor (UBRDIV) register (0x23), R2 is the address of the start of IRAM, and R3 is maybe bytes to load or max bytes (0x15400). Also IRAM address 0xD0035464 contains the base address of the UART (Line control register address), set by the sub at 0x843c.

If anyone can tell me what maths the function at offset 0xc66c is doing, that would be helpful, I think it's division?