yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] androcheck:
Something different:

I just did a normal boot with a 619k resistor on my (non-bricked) Galaxy S (GT-I9000) and just noticed a small difference in the output of the PBL.

While you guys always had an output like this:

Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.

it shows for me:

Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused version.

I have bought my device from Germany via ebay, but personally never updated or flashed a new bootloader. So why is my bootloader "e-fused"??

I looked again on my PBL dump (dumped from /dev/block/bml1 with "dd") with an Hexeditor.

And when I looked at the end of the dump, which is trailed by a long series of "00"s, I saw that the very last 7 bytes are (in hex): 65 2D 66 75 73 65 64, which in ASCII means: "e-fused".

Any ideas which implications this may have? Especially when I would flash new bootloaders with Gingerbread?

Could this also be (another) cause for some bricks we saw already?
[Hardware Hacking General] js22:
Hmm, that's interesting. The output actually comes from the SBL. It looks like you have a slightly different SBL than we do. Using the "strings" command on my Sbl.bin, I found the following :

<1> "IROM e-fused - "
<2> "Non Secure Boot Version."
<3> "IROM non e-fused version."
<4> "this target is e-fused. fusing stop.."
<5> "non e-fused. fusing continue.."

(I added the numbers and the quotes).

These are the only strings in the binary which contain the substring "fuse". Items 4 and 5 are from a different section; they are apparently for reporting to the user the progress of a fusing operation. Items 1,2 and 3 are in a group of strings for generic boot messages, including the "OM =" message.

Without some very unlikely trickery, there is no way for this copy of the program to produce output identical to yours. (Note that item 1 includes the "-" character).

As for the PBL binary, mine also contains the ending that you mention : lots of zeros, followed by the ASCII characters "e-fused".

Keep in mind that "e-fused" and secure mode are two different things : First you choose which mode you want (secure or non), and then you (optionally) burn the e-fuse bits. Once they are set, there is no going back.

In your case and mine the e-fusing has been done. This is clear from the UART output. In my case, the UART output also makes clear that it it is in non-secure mode. It seems strange, but looking though the SBL strings, there is no string that could be used to print out "Secure Boot Version" or anything similar. Seems to me that that is one thing the user would certainly want to know about !

In your case, the absence of the text 'Non Secure Boot Version" might mean that you are locked into secure boot mode, but its not a certainty.

One option to try is investigating the strings in your copy of the SBL (e.g., Sbl.bin). Using linux, just run :

# strings Sbl.bin > my_strings.txt

and browse through the output file.

Another tack:

Maybe TheBeano can help clarify a bit more, but immediately after a system reset, the iROM code peeks at several locations beginning at 0xE0E00000 (SYS_SECURE_KEY). If the the secure key (bit 80, IIRC) is non-zero, then the code takes a different branch.

If I run :

# adb shell viewmem 0xe0e00000 0x32 | hexdump -C

I get all zeros :

00000000 5b 49 4e 46 4f 5d 20 52 65 61 64 69 6e 67 20 35 |[INFO] Reading 5|
00000010 30 20 62 79 74 65 73 20 61 74 20 30 78 65 30 65 |0 bytes at 0xe0e|
00000020 30 30 30 30 30 2e 2e 2e 0d 0a 00 00 00 00 00 00 |00000...........|
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |..............|

I'm not absolutely positive, but I think this is a definitive test for secure vs. non secure boot mode. Try it and let us know what you get.

p.s.: Just a reminder: viewmem is a small binary linked to earlier in this thread; it is not a standard tool in linux.
[Hardware Hacking General] androcheck:
Hi!

thanks for your response!

Ok, I just did this. I grabbed a copy of my SBL using

dd if=/dev/block/bml4 of=sbl.bin

The resulting file is exact 1310720 bytes long. I also did a md5sum on it:

# md5sum sbl.bin
141dcae8289eaa18888246ebd4cc450f sbl.bin

Looking into the file with "strings" gives me the following strings containing "fus":

john@mond:~/Desktop$ strings sbl.bin | grep -i "fus"
IROM e-fused version.
IROM non e-fused version.
start %d partition fusing
relocate & fusing continue..
this target is e-fused. fusing stop..
non e-fused. fusing continue..
not relocate & fusing continue..

So it looks different than the one of yours.

Ok, I did this too and I also get only zeros:

root@galaxyS :/data/john# ./viewmem 0xe0e00000 0x32 | hexdump -C
[INFO] Reading 50 bytes at 0xe0e00000...
00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000030

I also just noticed that I have a different build date in the SBL header output:

-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010

Board Name: ARIES REV 03
Build On: Jun 4 2010 21:25:36
-----------------------------------------------------------

Seems that mine is an older version.

If you are interested I can upload you the complete output of strings or the whole binary somewhere.
[Hardware Hacking General] js22:
Unless I'm mistaken about something, the fact that the viewmem command shows all zeros is a pretty good proof that your phone isn't using secure mode. Maybe if TheBeano gets a chance to look at the iROM code, he can confirm.

In general, its hard to see why Samsung would try locking down one particular variant of the Galaxy S when all the others are open.
[Hardware Hacking General] midas5:
Also, do not under any circumstances set any of them to non zero. It cannot be undone, even with jtag and will brick the phone. Read the manual (link elsewhere in this thread) for explanation.
[Hardware Hacking General] midas5:
I get exactly the same md5sum.

Interestingly, the sbl.bin that I flashed (from xwjvb) has a different md5sum

8d9373eafb7b05aca33b37b75d6f33a4 *Sbl.bin

(The /dev/block/bml4 does have the same md5sum as yours)

So, the flash process does not overwrite every byte of the sbl partition.

I found the same happen with the PBL, the first 0x4000 bytes of the PBL are not changed with a flash.

Also, flashing the sbl seems to change both /dev/block/bml4 and /dev/block/bml5.
[Hardware Hacking General] TheBeano:
Yes it's the 16 bytes starting at 0xE0E00018. If they are zero then it doesn't use secure booting.
[Hardware Hacking General] AdamOutler:
Just thought I'd post this. I was surfing around the hacking and prototyping sites and came across a Seeeduino Mega on clearance for $39.99. The seeduino can be switched between 5V and 3.3V with a simple switch.

link:http://www.seeedstudio.com/depot/cl...ath=77&zenid=c1517c52f0362e99199f952bc54d99b4

The Seeeduino is basically an Arduino Mega with a few extra IO pins and a few extra switches for power.
[Hardware Hacking General] TheBeano:
Automated resistor test jig mk 1 is underway, have just made a high-precision motorized variable resistor... out of Lego. :) Stay tuned.
[Hardware Hacking General] AdamOutler:
^^ That's awesome. Make sure you get video documentation. Stepper motors. test equipment combined and a blog = front page on hackaday.com.
[Hardware Hacking General] midas5:
Has anyone got any idea how the resistor value is detected? i am thinking that if we had a DAC connected to the usb id pin, we might be able to generate all the values we need using the DAC instead of all those resistors? Has anyone measured what the resistance is between pin 4 and pin 1 when no battery or usb power is applied? We could then calc what volts is equivalent to which resistor value. Alternatively, measure the volts value on pin 4 when various resistors are attached.
[Hardware Hacking General] TheBeano:
From the FSA9280 block diagram it uses an ADC and also has float detection on the ID pin, so it will have some sort of pullup arrangement, but it measures such a wide range of resistance that I would guess it's probably something more sophisticated than just a voltage divider.

I guess it's probably been designed to be robust to cope with miswired/shorted plugs etc so it might not totally blow up if you put some voltage in there. If you want to experiment you should be able to read the I2C ADC registers from code to see what values it thinks it's reading.
[Hardware Hacking General] midas5:
In my post, i meant to ask someone to test the resistance between pin 4 and 1.

I will test it once i receive my arduino test kit!
[Hardware Hacking General] midas5:
Can you test what range of r values cause each mode. It would be good to know how accurate the r value needs to be. I do hope your lego finds us our OM != 9 value.
[Hardware Hacking General] midas5:
Are the power and vol up/down buttons connected to the fsa chip? i.e. Is there any other input to the fsa chip that the would maybe be used to change modes?
[Hardware Hacking General] AdamOutler:
I'ts not really measurable. With black on pin 4, 8.75 Mega Ohms... however there is some capacitance messing with the numbers... It keeps changing. 8.75 seemed to be the value it settled down to for the longest.

With Red on pin 4, there is an open condition displayed which says there is some sort of transistorized/diode circuit between the two pins internally. Which makes sense... With that much resistance, it's likely they are employing a volt or ohm meter of some sort and the unit actually knows the voltage and therefore can calculate out resistance somewhere.

Hey, another cool thing to get with an Arduino is a battery backpack... It allows you to take your code mobile like this:http://www.hyundaiaftermarket.org/forum/index.php?/blog/3/entry-26-arduino-ef-meter/ Although, a 9V will work as well, it's not rechargable. I have a few other arduino projects on my blog as well.
[Hardware Hacking General] js22:
SHORT VERSION :

I don't think looking for undocumented resistor values is going to yield anything.

MORE WORDS:

We don't know a lot about the FSA9480, but what we do know comes from 3 sources :

a) Source code. e.g., Samsung Froyo kernel : ./drivers/usb/gadget/fsa9480_i2c.c

b) The partial schematic shown numerous times in this thread.

c) The (partial) datasheet for Fairchild's FSA9280, which is similar.

Note : I haven't looked at other samsung released kernels : could be more info out there.

Note : Fairchild's website doesn't even hint at the existence of the 9480; they describe the 9280 as the newest and best. The 9480 seems to be the same thing, but with added ability to switch manually between 2 UARTS and 2 USBs : one each for the "Applications processor (aka "AP", our CPU) and the "Communications Processor" (aka "CP", the radio chip.) The AP is the power-on default.

From (b), we know that the vol up/down/power buttons are not connected to the FSA chip directly. I went digging through Samsung's linux kernel code ( ./linux/drivers/input/keyboard/s3c-keypad.c), and it looks like all three buttons are connected to the CPU's keypad interface, a special subset of GPIO pins with a little extra functionality (e.g., wake up and interrupt). Explains the occasional bizarre (mis-/non-) behavior of the buttons, but doesn't really help us here.

Also from (a) we get the list of R values corresponding to (many, many) possible modes. These fall into two categories :

1) "ordinary" modes. When the value of R changes, the chip automatically switches the appropriate pair of wires to the DP and DM pins of the USB connector. In addition, the chip sends an interrupt to the CPU. The CPU (if enabled) responds by reading out the new R value over the i2c bus and taking the appropriate actions.

2) "special" modes. When the value of R changes and is found to be one of the "special" modes, the DP and DM pins are automatically routed as before, there might be an interrupt (???) and one or both of the outputs JIG or BOOT are activated. It is the presence of these dedicated outputs that make the modes "special". Only the physical output lines are able to alter the early boot behavior where i2c bus is not functional.

From the list of R values from the kernel code, we already know of 4 special modes :

619k : RID_FM_BOOT_ON_UART

523k : RID_FM_BOOT_OFF_UART

301k : RID_FM_BOOT_ON_USB

255k : RID_FM_BOOT_OFF_USB

"BOOT_ON" or "BOOT_OFF" tells us the status of the BOOT output (input to the CPU). And "FM" stands for Factory Mode, which is pretty much synonymous with using a "jig". This is explicitly described in the Fairchild literature as being meant for "factory programmability". So I think we can be pretty sure that the "JIG" output from the fsa9480 is active when in any of these 4 modes.

Anyway, it seems like the above 4 modes cover the only cases we care about. The problem is that forcing the the JIG output high (which is probably already happening, but we have no way of confirming) doesn't affect the OM[5] pin.
[Hardware Hacking General] AdamOutler:
^^ I've got some observations based on what I've seen so far.

RID=Resistor Identification

FM=Factory Mode

BOOT= Boot the phone up or not

UART=serial mode

USB=USB mode

I believe the BOOT line tells the processor to boot.

I believe JIG line is likely the line which connects to pin 4 of the MicroUSB connector.

The U301 Fairchild FSA9480 is called a MUX. A MUX is a multiplexer. It's job is to route signals to the MicroUSB port. It takes many inputs and turns it into one output.

From what I can tell, The JIG line tells the MUX to route the desired input to the MicroUSB port. Also, certain values will BOOT the phone.

The processor has many power management modes of operation, none of which are "OFF". There is Normal, Idle, Deep idle, Stop, Deep stop, and sleep.

http://www11.multiupload.com:81/fil...42C10B07813118568C45AAF/S5PC110_EVT1_UM10.pdf

It may be possible to play with some of the BOOT_OFF modes and push commands to memory before boot. There may be some way to set the OM register using uart boot off.

I do believe there must be some undocumented resistor values.

js22, you mentioned the i2c bus. How can we get access to this?
[Hardware Hacking General] midas5:
How sure are you of these definitions? RID_FM_BOOT_ON_UART could mean something else. i.e boot while muxed to the UART, and turn power on. It might have nothing to do with boot mode and OM5. We already know that other modes are labelled wrongly.

I am suggesting that we actually do a test to prove the accuracy of the current list of resistors or not.
[Hardware Hacking General] midas5:
I meant between pin 4 and 1 not between 4 and 5.
[Hardware Hacking General] TheBeano:
Couldn't you have written this BEFORE I made a big elaborate test jig to look for undocumented resistor values? :)

Seriously I agree that it's a longshot, but it's probably still worth doing even to rule it out. It could also make it easier to test for things like charger detection on the USB D+ and D- pins, which I notice are also inputs into the switch mode on the FSA9280 data sheet.

This is correct, we know the JIG output goes straight to the power management IC and tells it to turn the phone on without the power button being pressed, and we know the phone switches on automatically in all of these modes.

One thought did occur to me, Samsung decided to use 619K (RID_FM_BOOT_ON_UART) for the car dock accessory, which is an odd decision but perhaps they chose it because it turned the phone on automatically, and if they then discovered that it also put the phone into UART boot mode they may have just disconnected the BOOT line from the CPU, having no other use for it themselves. Alternatively perhaps you really do have to do something extra as well as having this resistor value to get the BOOT line to work.
[Hardware Hacking General] AdamOutler:
How do we know this? The Schematics show only 4 pins going to USB and an extra-long jig pin. I still think jig is pin4 on the microusb, so the fairchild knows which i/o to switch to. What other pin could jig be hooked to?
[Hardware Hacking General] midas5:
The fsa chip has a usb id pin, so i assume that is connected to the micro usb port pin 4
[Hardware Hacking General] AdamOutler:
Ah ha! I missed that one.
[Hardware Hacking General] AdamOutler:
This is the newest SBL so far.

Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010

Board Name: ARIES REV 03
Build On: Feb 1 2011 10:54:21
[Hardware Hacking General] AdamOutler:
Guys! The galaxy S 4g teardown was posted. I don't see a JTAG port. http://www.ifixit.com/Teardown/Samsung-Galaxy-S-4G-Teardown/4977/1

Ok.. So, now, what does that mean? Duh... No jtag port=FSA chip must be used. Great news right?

Alright.. So, even bigger news... My phone has a slightly different FSA chip... Check this result from the 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),

I searched on the fairchild website... http://www.fairchildsemi.com/ds/FS/ Ok.. so we still don't have a datashet, but we have a similar one. http://www.fairchildsemi.com/ds/FS/FSA9280A.pdf

The FSA9280A and FSA9288A are high-performance
multimedia switches featuring automatic switching and
accessory detection for the USB port. These switches allow
the sharing of a common USB port to pass audio, USB data /
charging, as well as factory programmability. In addition, the
FSA9280A / FSA9288A integrate detection of accessories,
such as headphones, headsets (MIC / button), car chargers,
USB chargers, and UART data cables with the ability to use
a common USB connector. The FSA9280A / FSA9288A can
be programmed for manual switching or automatic switching
of data paths based on accessory detected. FSA9280A /
FSA9288A include an integrated 28V over-voltage and 1.5A
over-current protected FET.

The important statement here is: The FSA9280A / FSA9288A can be programmed for manual switching or automatic switching of data paths based on accessory detected.

So... we need that resistance testing done pronto!

The data sheet specifies: UART Serial Link and Factory-Mode... those are two separate modes. It's quite possible we have not yet found Factory-Mode. It would be nice to have that code which was mentioned by the second poster in this thread. It's likely that Samsung has changed the code for their release PBLs.
[Hardware Hacking General] TheBeano:
I meant the JIG signal coming out of the FSA9480 JIG pin, which Richthofen traced to the PMIC (here).
[Hardware Hacking General] manosv:
I saw a post in the thread with the jig that someone posted i thought i share it

http://xdaforums.com/showpost.php?p=9171146&postcount=200

Also look at this thread there is a guy that owns anyway jig maybe he can help debug the process

http://xdaforums.com/showthread.php?t=917229
[Hardware Hacking General] AdamOutler:
Can anyone define these acronyms i'm seeing in the picture above?

DP

DM

CP

TA

IF

They have TX and RX lines. They are connected to the microUSB mux.

so, the JIG line definately controls if the phone boots or not.

The BOOT pin, likely controls if the phone boots to charge or android mode.

I want to get ahold of the I2C bus. I also need to know what is being transmitted when the phone is first plugged into the usb cable and power is applied. Anyone with a scope, can you scope the D+ and D- lines while plugging a phone which is off into power?
[Hardware Hacking General] TheBeano:
DP = USB D+

DM = USB D-

CP = Call Processor (modem)

TA = ???

IF = The TXD and RXD lines chosen by the switch in the PMIC, which will be either the CP or the AP (Application Processor) UART TXD/RXD.
[Hardware Hacking General] TheBeano:
The JTAG points are the eight rectangular green pads on the bottom right of this picture. The circuit board looks basically the same layout as the circuit board in the I9000 service manual. The FSA9480 (U301) is the second-from-top chip in this picture, marked "PB1AV N4".
[Hardware Hacking General] AdamOutler:
Can you point me to this source? Is it the actual bootloader source, or is it the source for the dev platform?
[Hardware Hacking General] js22:
Sorry bout that. All this talk about jigs is what made me think about it more.

The while point is : suppose the fsa chip wanted to assert pin OM5 on the CPU. What output lines does it have available? Only JIG and BOOT. And we already know which R values assert them.

Hmmm... Good point. I guess if Sammy wired our phones up right, they would automatcally download firmware from our car's audio amp. lol

But what does happen to the BOOT line? Do we know of any behavior that is different for BOOT ON or OFF ?
[Hardware Hacking General] js22:
Not the bootloader, but rather the code for the linux kernel. I dont have the link handy, but it is the source code samsung released for Froyo on the Captivate. Sumpn like opensorce.samsung.com.

Anyway, it shows how an already booted, up and running system interacts with the fsa9480 chip. The CPU is a master on the i2c bus, and the fsa is a slave. So i2c isn't really relevant to the early boot process. It might get used in SBL but thats too late to matter for us.

BTW, the linux code for the fsa9480 was written by samsung, and it does explicitly say "factory mode" on the lines defining the RID_FM_* values. It is possible (looking likely? ) that they just lifted that name from the (uncensored) Fairchild data sheet, even though they planned to use the mode differently (see prev post).
[Hardware Hacking General] AdamOutler:
We aren't really concerned with the way linux handles the i2c bus. That's way after the communication we are seeing. We are basically communicating with the bios for lack of a better term.

The processor has to be master after the kernel boots. The processor handles i2c master and slave natively according to the datasheets. Js22 can you scope that initial communication for me? I really still believe there is something we are missing.

Where can we get that obligation and able code?

Btw... what is uart2? Are we using uart1 or uart2?