yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] js22:
Rambling Thought Dump....

Even though Fairchild designed the fsa9480 explicitly to allow cell phone makers to implement a factory programming mode which kicks in automaically when it senses the correct R value, maybe Samsung just didn't use the chip that way.

So the question is, how do we get into UART boot mode?

I started out feeling like it was a no-brainer. We know the UART boot mode exists, we know there is a chip (the fsa9480) explicitly designed to enable it, so had to be a piece of cake.

Now my thinking is, since it isn't easy, just how hard is it?

My understanding is that mass-produced devices usually have their chips flashed before they are assembled. In-system programming is handy for development, but there is always JTAG for that. So it could be that our dear friend OM5 is merely soldered to ground. Or possibly it is just pulled weakly to ground and there is some way of physically accessing it, like a test point somewhere on the main board. Maybe this is venturing into crazyland, but one way to find out would be to disassemble a phone : actually unsolder the CPU and go at the board with probes. I'm not saying I plan to; just that the idea is kicking around upstairs. If it turns out that there is a convenient access point, we would have a way to procede. Not as nice as a magic resistor on the usb connector, but still preferable to JTAG as a cheap, repeatable, open-source method of rescuing a phone.

Another idea I've had kicking around is finding a way to block or corrupt the IBL code as it travels from the OneNAND to the CPU's internal RAM. If the IBL isn't copied perfectly, the iROM code will detect the error and fail over to UART.

How to mess up the IBL? We've already tossed around the idea of modifying it as it is stored in the OneNAND, but that is guaranteed to permanently brick a phone until a (never before attempted) method of recovery based on UART is perfected. And in order to do this, we'd have to start with a working (non-bricked) phone.

But if the transfer of the IBL can be made to fail "on demand", that would be a reasonable way to go forward.

TBH, I don't even know where the OneNAND is or what kind of physical access we have to it. The trick is to mess with the data without breaking anything. I'm thinking of a longish wire (not connected to anything) as a noise source. Touching it to every possible contact near the OneNAND chip is bound to turn up something (clock, chip select, power, enables,???) with enough noise sensitivity to corrupt at least one bit.

Anyway, enough rambling. Time for SNL.
[Hardware Hacking General] AdamOutler:
Well, if you're interested in poking around on the phone, these pictures should help. I tore it down the other night to get high quality pictures for reference.

I probly should have taken the shield off around the processor.
[Hardware Hacking General] js22:
Although the CPU is capable of being set up to operate in slave mode, the fsa chip is not capable of being a master. As far as i2c is concerned, it just sits there waiting for commands which do not come. We know that the iROM code does not enable the i2c bus.

As for UART, the CPU has 4 nunbered 0,1,2,3. The one we talk to is 2. This is coded in ROM and (obviously) built into the circuit.

Of the various things that the fsa9480 can multiplex onto the USB connector, there are 2 diffferent UARTs. One of them is the UART2 from our CPU. Our CPU is called the AP in cellphone lingo. The other UART comes from the radio chip, which cellphone pholks call the CP.

The fsa chip always picks the UART from the AP by default. Only when instructed by the AP over the i2c bus does it switch to the other UART from the CP.
[Hardware Hacking General] midas5:
The fsa chip might be programmable via i2c. There might be an i2c message we can send to it to cause boot mode pin to change. If we can access the i2c pins of the fsa chip via the test points, we could send the message even if the phone is bricked.

I still think we have an undocument resistor value to find because the om5 is not being set with any of the current resistors.
[Hardware Hacking General] b4dg3r:
Just a thought.

The FSA Data sheet does say "Programmability I2C". Perhaps its behaviour when presented with different resistor values (i.e whether it asserts JIG/BOOT) can be set over I2C and stored in non-volatile memory in the FSA. The info in the source could just be a cut-and-paste of the FSA's default behaviour from the full data sheet.

I can't think what else "Programmability I2C" could mean?
[Hardware Hacking General] TheBeano:
Interesting idea! Completely disabling the NAND would also work, probably. Unfortunately the OneNAND chip is in a package-on-package stack with the processor, that is it's basically stuck onto the top of the processor package, and it's in a combined package with the RAM. This is described in this teardown, note that the "Gb" figures in the article are gigabits, not gigabytes.

This makes it pretty hard to disrupt without messing up the processor or RAM as well, although if you had the schematic you might identify a way of doing it.
[Hardware Hacking General] js22:
Don't forget, the OM5 pin is on the CPU. The pin on the fsa chip that "should" be connected to it is BOOT. Right now (pretty certain) we know R values to turn BOOT on, but it doesn't appear to affect OM5. One of the big questions right now is : what does the BOOT pin affect?

As for programability of the fsa chip, we can't be sure of anything without the real data sheet. Looking through the linux kernel code, there is no evidence that it has any non-volatile memory. Just a typical-looking set of control and status registers.
[Hardware Hacking General] js22:
Sheesh!

Why don't they just stick the CP and the touch screen on the stack while they're at it?
[Hardware Hacking General] AdamOutler:
It might be worth it to blip ground at startup. During the time when the phone loads data into memory, when power is first applied. usb tx line has some action on it. Using that for a trigger may yield some interesting results.... it may be enough to ruin the IBL transfer or verification... assuming the power management chip dosnt shut everything down immediately on a power fluctuation.
[Hardware Hacking General] AdamOutler:
Boot tells the phone if the kernel should load or charge the battery. Boot on charges the battery. This is with power applied.

This is how I know that.
[Hardware Hacking General] androcheck:
No idea if this helps us in any way, but I accidently stumbled over a datasheet of a similiar product from a *different* manufacturer (Texas Instruments).

http://download.siliconexpert.com/pdfs/2010/9/23/7/37/40/38/txn_/manual/tsu5511.pdf

It's not related to the FSA chip, but as this datasheet is complete it describes somehow this kind of device works in general.. (and also describes how *they* do the resistor value detection, see page 12).

Maybe this input brings new inspiration?? :)
[Hardware Hacking General] androcheck:
I found that I get the full kernel output during boot (useful for kernel debugging when compiling your own kernel) when I enable the following:

In the *#9090# menu: "LOG VIA UART"

and in the *#7284# menu: UART: PDA

These settings seem to stay persistent over a reboot.

No idea what this would do, but I wouldn't recommend trying it until we know more I guess.. :)
[Hardware Hacking General] AdamOutler:
except....

setenv SWITCH_SEL 65 provides error logging

setenv SWITCH_SEL 654 provides light debug logging

setenv SWITCH_SEL 6543 provides Shell access

This also provides a shell access.

Check this out...

put busybox on an sdcard

mkdir /data/myfolder
cat /sdcard/external_sd/busybox >/data/myfolder/busybox
chmod 777 /data/myfolder/busybox
/data/myfolder/busybox tcpsvd -vE 0.0.0.0 21 ftpd -w /&

then you have an FTP right into your phone.

This can save some phones with unusable screen damage, or at least save the important data off it.
[Hardware Hacking General] AdamOutler:
Is there any way this could be ascii rather then hex? If you use the 255Kohm FM Boot Off USB cable, and hold enter, you receive ascii AA back. I'm not sure if it's just some randomness or not, but I tried a few other keys.. Each key would return a different result. However, the delete key returned something special...

0|0|0|0|42|52|44|20|42|52|44|20|0|A|D|
B R D B R D
[Hardware Hacking General] AdamOutler:
OH WOW.. I do believe there is something to this.

I have a brick here which will only give me PBL and this mode.

I'm not really sure what I'm looking at here, but it's definately something

because of the frequency of "0" I decided to linebreak after each occurance. I hit a few keys like home, page up, and delete, I did my ABCs and 123s in lower case and then upper. It seems really really random... but I'm sure it's responding to something it sees me typing.

0|
9|0|
12|4|0|
0|
52|44|20|0|
52|22|20|0|
52|45|20|0|
50|28|0|
52|44|20|0|
52|44|20|42|52|44|20|0|
52|44|20|42|52|44|20|42|52|44|20|0|
52|44|20|0|
52|44|20|0|
52|44|20|0|
52|44|20|0|
22|0|
11|45|22|0|
22|0|
4|4|22|49|0|
22|44|0|
11|0|
0|
48|0|
8|22|24|21|21|21|21|21|0|
0|
0|
24|0|
12|0|
24|0|
9|0|
25|0|
12|0|
24|0|
4|22|0|
22|0|
11|0|
22|0|
8|0|
21|2|0|
0|
0|
11|0|
22|0|
8|0|
4|0|
0|
28|0|
14|0|
28|0|
A|0|
29|0|
14|0|
28|0|
5|0|
0|
2A|0|
15|0|
2A|0|
A|0|
29|

It could be at the wrong baud rate because sometimes enter is a 0, and sometimes it's a 41. Any logical answer here? The phone never responds to anything except this mode and primary bootloader. So, this is in the primary bootloader, or the irom.
[Hardware Hacking General] androcheck:
Thanks for the note! :)

I wrote him a PM and asked if there are some "Boot" related fuinctions on the Anyway jig and if he would be so kind to measure the according resistor values for us.
[Hardware Hacking General] AdamOutler:
I got something here.

loke_init: j4fs_open success..
load_lfs_parameters valid magic code and version.
reading nps status file is successfully!.
nps status=0x504d4f43
load_debug_level reading debug level from file successfully(0x574f4c44).
init_fuel_gauge: vcell = 4188mV, soc = 94
check_quick_start_condition_with_charger- Voltage: 4188.75000, Linearized[72/87/100], Capacity: 98
init_fuel_gauge: vcell = 4188mV, soc = 94, rcomp = d01f
EXT_I2C(0) -> No ACK
EXT_I2C(0) -> No ACK
EXT_I2C(0) -> No ACK
reading nps status file is successfully!.
nps status=0x504d4f43
PMIC_IRQ1 = 0x0
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x0
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0x40
PMIC_STATUS2 = 0x2c
get_debug_level current debug level is 0x574f4c44.
aries_process_platform: Debug Level Low
keypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
EXT_I2C(0) -> No ACK
EXT_I2C(0) -> No ACK
EXT_I2C(0) -> No ACK
check_download: micorusb_status1 = 4ff, key_value = 0
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!
set_boot_mode: boot mode = 1
aries_process_platform: final s1 booting mode = 1
aries_check_vf_status() ----- aver_vf_adc : 3680
main: booting stop and power off..
loke_exit: bye~ bye!
aries_power_off: TA or USB connected
aries_power_off: WDT reset

EXT_I2C(0)..... See that? That's the I2C bus.. looking for an external connection.

I disconnected the middle pin on the battery and tried different resistance values to ground.... That's the secret. The middle pin is called the BSI. http://www.cpkb.org/wiki/Samsung_AB463446BU_battery_pinout Normally, it's a resistor that tells the phone what kind of battery is being used.

I'm using aproximately 3.1kohms and that message is hit and miss. So, now we have to figure out where the i2c bus is, how to access it, and what resistance values do what on the battery strength indicator (middle battery pin).
[Hardware Hacking General] androcheck:
Interesting finding!

But in case of a bricked SBL bin this still won't help as the output you are seeing comes from the SBL.

But another idea: as we didn't see any OM value change with a lot of different resistor values until now, I was wondering if the information if the power source comes from micro-usb connector (VBUS_IN) or from the battery (V_BAT) is taken into decision for setting the boot pin.

Unfortunately I have no 5V output on my FTDI board so until now I did all my tests with battery inserted.

@AdamOutler:

Do you see some new serial output before the PBL and SBL output begins. Maybe something different than the usual 0x10 0x31?
[Hardware Hacking General] midas5:
Hi,

My Arduino Mega 2560 arrived today. So I will be able to do my own tests soon.
[Hardware Hacking General] AdamOutler:
I did this test with battery inserted as well. I can only supply 50ma 3.3v or 500ma 5V regulated power to the unit, and it can draw up to 1A. I slipped a piece of cardboard from a razor blade and a resistor over the middle pin to test this.

Using this method, everyone can do it...

Actually, now that I got to thinking about it.. I do have a 3.3V regulated battery backpack for the arduino, so I should be able to get something, however it is expecting 3.7-4.1 from the battery... hrm.. I'll have to test it out a bit. I'm willing to bet it will handle 5V.
[Hardware Hacking General] AdamOutler:
Setting it up under ubuntu is a breeze.

1. Type:

sudo apt-get install arduino
arduino

2. copy and paste this to the arduino http://xdaforums.com/showpost.php?p=13351363&postcount=223

3. click the upload button

4. Close out the arduino program and type

sudo minicom -d /dev/ttyUSB0

5. hit ctrl+a, then "o" to access options and set it as 115200 8N1 flow controls off

6. save as /dev/ttyUSB0

From now on you can access the UART port by using minicom /dev/ttyUSB0 with no sudo.
[Hardware Hacking General] midas5:
Thank you.

I have boot output from the i9000 via my Arduino using a 619K resistor.

I have 50x300K and 50x620K, so I am waiting for other ones that I have ordered.
[Hardware Hacking General] AdamOutler:
Here is the procedure for booting from MMC

http://hi.baidu.com/j2h3344/blog/item/85740dfc0be35951d7887dd5.html

If we get it right, then we should observe this message:

OND check sum error

This is what we are trying to do. OND check sum error.

It's now a matter of figuring out the proper resistor values.

Judging by those OMpin settings and the fact that we only have OM pins... It may be possible that this represents what we need?

RID_AUD_REMOTE_S11_BTN,	/* 0 1 1 0 0	20.5K	Audio Remote S11 Button */
[Hardware Hacking General] midas5:
Is there any way to run an ssh server on the i9000?

I would like to ssh into the i9000 via the wifi interface while I change resistors on the usb port and monitor the kernel log.
[Hardware Hacking General] AdamOutler:
Quicksshd or droidssh. You can also use adb shell or adbwireless
[Hardware Hacking General] TheBeano:
Yes I use adbwireless, as it works with the app development environment.
[Hardware Hacking General] TheBeano:
So automatic testing is not going that well, it seems it's possible to "crash" the fsa9480, so it stops responding to any resistance changes, including "known" ones like the car dock, and won't start working again until you reboot the phone. I have got through one sweep of every value between 1k and 1.2MB without 5V connected to the VIN on the USB, am trying another one with 5V.

I am pleased with the test setup though: I have a custom app on the phone running a Bluetooth connection to an Arduino board, to control the motorised potentiometer and some relays to connect and disconnect the resistor to the phone socket. The app changes the resistor value and monitors the OM register address for changes.
[Hardware Hacking General] AdamOutler:
I turned this up on a 20.5K resistor with middle battery terminal disconnected

0|
0|
0|
0|
E0|0|
F8|0|
FC|0|
FE|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
0|
FF|0|
0|
0|
0|
0|

What is that? It's reproducible. see below.

Welcome to minicom 2.5

OPTIONS: I18n
Compiled on Feb 5 2011, 06:31:42.
Port /dev/ttyUSB0

Press CTRL-A Z for help on special keys

0|
24|11|2|2A|44|2|A|11|2|24|48|44|2|51|44|2|54|4|41|0|
0|
0|
E0|0|
F0|0|
F8|0|
FC|0|
FE|0|
FF|0|
FF|0|
0|
0|
0|
0|
0|
C0|0|
E0|0|
F8|0|
FC|0|
FE|0|
FF|0|
FF|0|
FF|0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
EC|FF|0|
0|
ED|0|
0|
0|
0|
D8|D8|D8|D8|FF|0|
D8|D8|D8|FF|0|
D8|D8|D8|FF|0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
FC|0|
FE|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
0|
0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
0|
0|
0|
0|
0|
0|
FF|0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
E0|0|
F8|0|
FC|0|
FE|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
FF|0|
0|
FF|0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|
0|

The randomeness in the middle was me pressing buttons and it responding with D8.

TheBeano, do you have the iROM or PBL disassembled?

Also, when you get done with that, please try the middle battery terminal with different resistors. I belive there is something we are missing there. It may need to be scoped for a clock pulse as well js22.
[Hardware Hacking General] TheBeano:
I have part of the IROM and the IBL but not the PBL. There is nothing like that in there for serial as far as I know, but it might be USB data on the serial pins. Or audio. :)
[Hardware Hacking General] AdamOutler:
TheBeano, can you post what you have so far?
[Hardware Hacking General] TheBeano:
Well you could try http://www.megaupload.com/?d=47ADC4N7 ... looks like whoever did this was totally guessing, but search for UART and you should find most of the serial stuff.
[Hardware Hacking General] TheBeano:
The UART handshakes are pretty much as described in this post. This is the function labelled "Download_BL1_From_UART ". I'm pretty sure the baud rate is 115200, based on looking at the register setup in the u-boot source (there are some comments about this in the IBL disassembly).

I2C doesn't really get used by the CPU boot process, it is initialized by the SBL to set up the peripherals and read the FSA9480 state and other things, but that is no use to us if the SBL is toasted.
[Hardware Hacking General] midas5:
From reading other threads on xda, the most interesting one for me was the one talking about some guy who tried to solder to the jtag connections on his phone and accidentally broke off the pads. So jtag was then a no-go.

He sent his brick back to samsung, and they managed to recover his phone.

His phone had not worked with the 301K download mode resistor, so Samsung certainly have a non-jtag method of recovering these phones.

The FSA9480 might have some registers that survive over a reboot.

One of these registers might be "set boot mode".

So, if we finally find out that a usb id resistor is not the answer, using the I2C interface of the FAS9480 might give us access to that "set boot mode" register.

I2C is a multi endpoint bus, so us adding a new endpoint at a test point while the phone is switched on is doable. We just need to find out which test point has the I2C bus.

We could discover this by connecting a digital capture scope/arduino to various test points and then attach a usb resistor and see the CPU interrupt and then using I2C to request the resistor value.

Another possibility might be that one resistor value connects the usb to the program interface of the FSA9480, and not to the CPU. So one might be able to program the FSA9480 like that.

E.g.

Samsung connect to USB port of I9000.

Set Resistor, program FSA9480 to set "boot mode".

Reboot phone.

CPU now boots up in "boot from UART/USB" and the recovery loads "Download mode" into RAM.

Samsung then use ODIN to complete programming of the phone flash.

If I was designing a chip like the FSA9480 and the FSA9480 had registers that survive a power-cycle, I would design it so that a particular resistor value gives me programming access to the FSA9480 registers. The developer can then control everything without opening the case of the phone.

If the FSA9480 has no registers that survive a power-cycle, then the only possible answer is that one resistor value does actually set the "boot mode" pin.

Word of warning: If we do somehow manage to set the "boot mode" register. We most certainly need to know how to un-set it otherwise the phone will never boot again.

We know the resistor values are read by the CPU from the FSA9480 via I2C.

The source code here might give us an idea as to how many registers the FSA9480 has. We could try setting arbitrary values (using a healthy phone) in these FSA9480 registers and see if OM changes. This will not give us a direct method to unbrick a phone, but it will teach us more about the FSA9480 chip.
[Hardware Hacking General] Volcacius:
Hello everyone,

I found a thread about a china tablet based on the s5pv210 chip (which is almost the same as the s5pc110) where one user managed to boot from sd by altering the OM pins, which apperently are clearly marked on the board. Maybe they can help.

Link http://www.slatedroid.com/topic/15907-dev-custom-kernel-for-dropadherotab/page__st__60 post #80 and #82
[Hardware Hacking General] AdamOutler:
The fsa chip is programmable. This is why resistor testing is important. I would not expect the proper resistor combo to be available to the kernel though.
[Hardware Hacking General] AdamOutler:
I suck at reading teh assembly language

Is this the 10 we see as a first char at startup?

ROM:0D0002A4 ; =============== S U B R O U T I N E =======================================

ROM:0D0002A4

ROM:0D0002A4

ROM:0D0002A4 sub_D0002A4	; CODE XREF: USB_Bootloader_Download+28p

ROM:0D0002A4	STMFD SP!, {R4-R6,LR}

ROM:0D0002A8	MOV R5, #0

ROM:0D0002AC	MOV R0, #1

ROM:0D0002B0	MOV R1, #0xEC000000

ROM:0D0002B4	STR R0, [R1,#0x10]

ROM:0D0002B8	MOV R1, #0x64 ; 'd'

ROM:0D0002BC	MOV R0, #0

ROM:0D0002C0	BL	USBSomething

ROM:0D0002C4	ADD R5, R5, #1

ROM:0D0002C8	NOP

ROM:0D0002CC

ROM:0D0002CC loc_D0002CC	; CODE XREF: sub_D0002A4:loc_D0002F8j

ROM:0D0002CC	MOV R0, #0xEC000000

ROM:0D0002D0	LDR R4, [R0,#0x10]

ROM:0D0002D4	TST R4, #0x80000000

ROM:0D0002D8	BEQ loc_D0002E4

ROM:0D0002DC	MOV R0, #0

ROM:0D0002E0

ROM:0D0002E0 locret_D0002E0	; CODE XREF: sub_D0002A4+50j

ROM:0D0002E0	LDMFD SP!, {R4-R6,PC}

ROM:0D0002E4 ; ---------------------------------------------------------------------------

If so, we need some annotation here... this is the first bit of communication.

Keep in mind, I suck at ASM.... Is R5 and R4 the UART?

Btw.. I've rehosted the irom/pbl dumps here: http://teamkomin.googlecode.com/svn-history/r75/branches/IROMcode/bootdumps.rar

here: http://www.mediafire.com/file/c9bg6gyk1cuapsz/bootdumps.rar

and here: ftp://outleradam.dyndns.org/bootdumps.rar username xda password developers
[Hardware Hacking General] midas5:
I have been playing with resistors and used adbwireless to monitor it.

Is seems that some resistor values disable adb and disconnects me.

The 619K resistor causes adbwireless to be stopped, and a message "Car mode enabled" is displayed.

Are there any linux command line programs like openssh-server that I could run instead. I.e. a linux app, and not a android app?

The 301K resistor does not cause any problems with adbwireless.

I have looked at the fsa9480 source code, and the "manual switch" mode looks interesting.

The "hidden" register also looks interesting as sending a 0x01 to it, resets the fsa9480 chip. Sending other values to this register could be interesting.

Has anyone got a zImage that has the fsa in debug mode so you can see the attach and detach messages.
[Hardware Hacking General] AdamOutler:
Use droidssh or quicksshd for wifi ssh

619k turns usb into uart.
[Hardware Hacking General] midas5:
That is USBOTG.

USB On the go.

This is in a plain text message in the IROM also.

Maybe, we can get this to boot off a USB memory stick if we use the OTG Resistor, I.e. a Short between ground 5 and ID 4 pin.

Why would the IROM be doing anything with OTG otherwise?