yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] TheBeano:
So far it looks like a really simple protocol:

1. Intro: Phone sends 0xAA, waits for 0xAA back

2. Data start: Phone sends 0xCC, waits for 0xCC back

3. Phone receives 4 bytes, possibly the entry point address?

4. Phone receives exactly 0x15400-6 bytes (I think). It looks like you have to pad it if your code isn't that long.

5. Phone receives and checks a 16-bit checksum of all the bytes in step 4.

6. Phone sends three 0xbb characters to mark end of transfer.

Does anyone recognize this protocol, is it a standard thing?

It looks like any error messages will be sent back down the serial line, and possibly displayed to the screen as well. The code is loaded to IRAM at 0xD0020000.
[Hardware Hacking General] js22:
Wow, thats awesome !

I made a little progress, but not nearly that much. Been going though the iROMcode by hand, figuring our whats what.

I saw that that baud rate div UBRDIV was 0x23 and UBRSLOT was 0x888, but wasnt sure what the uart clock is. If it is 33.3333 MHz, that comes out to 57600 baud.

I did watch in terminal program at 115200 baud and saw that there is indeed some 'gibberish' on the serial line before the PBL starts printing output. Wasn't sure if it was binary, a different baud rate, or both. At 57600, its still gibberish. Was thinking of writing a simple code to read binary values from UART at diff baud rates and print them. Now I guess we just need to watch for 0xAA.

I suppose the simplest 'hello world' program could just print 'hello world'. Seeing as how we're already hooked up to the UART.

The u-boot code on teamhacksung git (think it comes from ODroid project) includes stuff to pad code length and compute checksum. IIRC, that was in the samsung-specific part, so it is for fixing up the u-boot PBL to be accepted by the iROM IPL.

Could use that to fix up hello world program. But it may be just as easy to just go ahead and build u-boot and try loading that. I don't know how its configured to behave 'out of the box' but its prolly a safe bet that it : a) prints output to uart, and b) doesn't flash anything unless you tell it.

This whole project is looking really good, IMO. Wish I had more time to work on it, but its looking like a busy week. Stupid day job! Stupid friends! Stupid other stuff!
[Hardware Hacking General] AdamOutler:
Wow, this thread is great...

Let me see if I got this....

Step 1. plug in 619kOhm resistor jig

Step 2. use a Samsung microUSB UART cable http://www.gsm-technology.com/index.php/en_US,details,id_pr,7954,menu_mode,categories.html

Step 3. ???

You guys are doing great work! Odia appears to know something which he is not sharing.
[Hardware Hacking General] TheBeano:
I'm not sure about the resistor value yet, will need to experiment. I don't think that cable will work, you need a USB to low-voltage serial converter and a resistor on the plug, as described in the Fun with resistors thread.

It may be possible to use USB without the serial converter, as the USB download code in the ROM is very similar, and hopefully it just looks like a serial port to the computer. You would still need some sort of USB adapter or cable with a resistor on it though.
[Hardware Hacking General] AdamOutler:
My Arduino Atmega has several uart compatible connections which would work at 9600bps, it has higher speed ports as well. I've got several breadboards and spare microsd cables. I wonder if I can come up with something. It would be interesting to see.

edit:

I just found this library http://arduino.cc/en/Reference/Firmata It should do the trick if I can hook it up to my computer.

Any idea on the settings for this protocol? line endings?
[Hardware Hacking General] js22:
Hardware-wise, the important thing is that you get a USB micro-B male connector with all 5 (not 4 !!!) pins broken out. micro-A will not fit, and many pre-built cables only have 4 conductors attached. (The official USB spec only requires 4 wires; the fifth pin is either shorted to GND or not.) In order to be sure I got something usable, I ordered the following :

http://www.sparkfun.com/products/10031

Also, you need a way to send the serial Tx/RX to your computer that is compatible w/ 3.3V signalling levels. I used the following :

http://www.sparkfun.com/products/9873

Both parts have the pins nicely labeled.

I just hacked these two together on an ugly perf-board. The connections are :

GND : GND

Tx : D+

Rx : D-

And the resistor (619k) from ID to GND. I just grabbed a bunch of resistors and measured them in series until I hit 619k. Do not hold them with your fingers while measuring - you'll get a bad reading. The value should be within about 1% (6k).

I keep the USB/serial gizmo plugged in to the computer and a terminal program (minicom on linux) running. With the phone powered off, plug the gizmo into it. It will immediately put out some binary data (presumably 0xAA, possibly at 57600 baud) and then switch over to the PBL with text output at 115,2000 baud.

If/when I get time, I want to try the serial approach. Doing the disassembly by hand is tedious (but fun !) and it at least seems do-able for the UART code. The USB code is pretty huge. It might "just work" if you try it, but actually debugging/analyzing/understanding what is going on is more than I could aspire to.
[Hardware Hacking General] AdamOutler:
js22, from what I can see here, this may be enough to save some bricks with a $20 arduino, if i'm reading right. http://xdaforums.com/showpost.php?p=9260580&postcount=29
[Hardware Hacking General] js22:
That is the command interface to the SBL (secondary boot loader). If it is running, then you're really not bricked all that badly. What we're trying to do here is be able to recover in situations where the secondary bootloader or even the primary bootloader (PBL) are damaged. The only thing that comes before that is the IBL (initial boot loader ?), which is built into iROM inside the chip. IOW, anything short of physical hardware damage (or failure to back up IMEI data) will be 100% recoverable.
[Hardware Hacking General] .Slane.:
It's like the power of a RiffBox without using JTag ! Very interesting thread from the beginning !
[Hardware Hacking General] TheBeano:
Well I am less encouraged now. Using the RID_FM_BOOT_xxx_UART resistors sets bits 1-5 of the OM Register to 9. It actually says so in the PBL bootloader output: "OM=0x9, device=OnenandMux(Audi)". This will always try to boot from NAND first.

We need the OM register to be 0x10 or higher to go straight to the UART/USB download. I tried all the other resistor values but no dice. Maybe there is some other combo that will do it, or access on a circuit board test point to the right OM pin.

If the ROM fails to load the PBL from NAND then it tries to download from SDMMC2, then tries the serial download, then the USB download. So if you have a bricked phone this is worth a try, connect up a serial adapter with a 619K resistor and see if there are any error messages on the serial port.
[Hardware Hacking General] js22:
Hmm, the post I wrote from work isn't here; maybe I forgot to click submit....

Anyway, i tried reading binary values from UART, hoping to see 0xAA. I definitely got binary values, but the problem is that no matter which baud rate I choose, I get something. Wish I got some kind of framing error or some indication that baud is incorrect.

But there definitely are bytes being sent before PBL prints its ASCII output.

As for the OM value, I noticed that as well. Maybe we need to hold a button down while booting? They seem to love that. Another (weak) possibility is that they are referring to the value of OM after it is masked and right-shifted by one bit. That is the value the ROM code uses for all its decisions. The low order bit just selects which clock to use; by the time code starts running it is too late for that to matter.

Maybe when I get time I can try watching the Rx line on a storage scope. Tried that w/ a non-storage scope I had handy, but had trouble triggering on the right byte.
[Hardware Hacking General] AdamOutler:
I'm building a universal jig in accordance with the values mentioned in this post http://xdaforums.com/showpost.php?p=12703456&postcount=12

1 0 1 1 0 150K UART Cable
1 1 0 0 0 255K Factory Mode Boot OFF-USB
1 1 0 0 1 301K Factory Mode Boot ON-USB
1 1 1 0 0 523K Factory Mode Boot OFF-UART
1 1 1 0 1 619K Factory Mode Boot ON-UART

My jig is a piece of perf-board with a set of dip switches to control which resistance value I'm using as well as a breakout for the microusb port. I plan on hooking it up to my arduino tonight to play around and see what I can see over various protocols and speeds. It's not finished yet, but here's a picture of what I have so far.

I have 3 extra dip switches on this setup.. any other resistance values I should check?

What speed settings have you found to produce the most sensable output?
[Hardware Hacking General] js22:
Those values look fine, unless you want to mess around with analog audio out. Just be sure to measure the resistance and adjust if necessary. As far as speed, everything from the PBL on runs at 115200 baud and outputs ASCII text. Its the first few bytes from the ROM bootloader (aka IBL) that are definitely not ASCII, and whose baud rate is uncertain.
[Hardware Hacking General] Fuma:
quick question if i may.

How can you damage/ change the imei with out intentionally trying?

i mean this does not supposed to change when flashing stuff...so why backing up the efs in the first place,if imei wracks the phone?

sorry but after so much reading i dont get it... recover efs should fix the imei so what kind of imei screwup will brick the phone?
[Hardware Hacking General] js22:
I don't know firsthand, but apparently when you install CyanogenMod 7 (CM7), you essentially erase the entire flash, resize the partitions, and put the info back. They give a very specific list of steps and promise that if you deviate at all you *will * be screwed and *won't* get any help or sympathy.

I think most other ROMs these days leave most of the flash alone, and only replace kernel, system, and initramfs. So they're pretty safe.

I'm not sure, but I think some of the one-click Odin ROMs might try to over-write the bootloaders; if you interrupt them in the middle, you can be left with a bricked phone.

Not an expert on any of this; that's just what I think I remember I read somewhere.
[Hardware Hacking General] TheBeano:
I looked at the OM register after boot, using:

viewmem 0xe010e100 0x32 | busybox hexdump -C

(see back up the thread for link to viewmem).

It is set to 9, including the bottom crystal control bit, and doesn't change with various resistors on the USB port (working on the assumption that the USB port switch is hardwired to the OM register, so it should change even after boot).

But as far as I can see the RID_FM_BOOT_xxx_UART resistors are the only ones that make the PBL output the line about the OM register, so the PBL obviously thinks its important.

There are a couple of bytes output at boot before the PBL message, which are consistently read as 0x10, 0x31 at 115200, but the PBL boot message appears instantly afterwards so I think it's probably the PBL producing them.
[Hardware Hacking General] js22:
Okay, back at work I looked at the data sheet again and realize that what I said about right-shifting the OM doesn't make sense. Bits OM[3:0] are in fact = 0x9 for OneNandMux. The bit we need set to boot from UART is OM[5]; i.e. OM =0x29.

I tried a few key combos and still get OM=9 and the PBL.

But I looked through the iROM code a little, and I'm not sure I agree about the boot selection process you describe. Shortly after a reset, execution arrives at location 0x59dc . The OM register is loaded into r4, right-shifted one bit, masked w/ 0x1F then compared to a bunch of values. However, these compares (CMP) are followed by a test for equality (typically BNE). So if we manage to get the OM[5] bit set, each of the tests fail until the "default" case at 0x5aa4, where r8 is set to 0x10. This is followed by another series of tests for equality which all fail until 0x5c94 where the r8 == 0x10 test succeeds.

From there, the code branches to 0x87f4 to 0x8640, which is where the UART sends out its 0xAA. Of course, each of the other boot sources also ends up here if they fail, but if the bit OM[5] is set, none of those other branches should have been taken.

Does this make sense, or did I miss something ? I hope I didn't, but OTOH I don't want to sound too sure...
[Hardware Hacking General] TheBeano:
The test at 5a94 is checking to see whether the right-shifted OM Register value is between 0xf and 0x18. Any other value goes to an OM Setting error message. So it will take anything with the top bit (was bit 5 before shift) set, but not bit 4-before-shift set, just because that combination isn't in the table I guess.

ROM:0D005A94 CMP R4, #0xF
ROM:0D005A98 BLS omSettingError
ROM:0D005A9C CMP R4, #0x18
ROM:0D005AA0 BCS omSettingError
ROM:0D005AA4 MOV R8, #BOOTTYPE_10_UART_OR_USB
ROM:0D005AA8 B _Boot_Type_In_R8 (0x5ac8)
[Hardware Hacking General] midas5:
Has anyone got any ideas regarding how we could find out if the fsa9480 remembered a setting after a reboot.

For example, if OM5 is set, will we get stuck in the IROM trying to boot from USB/UART or does the IROM with OM5, try USB/UART first, and if that fails, falls back to normal onenand?

If the IROM gets stuck in boot only from USB/UART mode, it would look very like a brick!
[Hardware Hacking General] AdamOutler:
On the development board this pin/register is set with a switch. Wouldnt it require more then setting a vaue to a memory location to trigger a pin?

How about this test...... Continuously write to i2c to ensure activity and then attempt to locate a clock signal with a scope. Ext-i2c seems to be the best bet to corrupt the pbl, fail the checksum, and force uart/otg boot.
[Hardware Hacking General] AdamOutler:
edit: double post
[Hardware Hacking General] AdamOutler:
Btw... continuous reading from i2c Address 0x03 which I believe to be the battery would generate the required clock and data pulses on the i2c bus, thus allowing for testing of i2c entry points and access to a bricked phone's OneNAND.

midas5, it's possible that the inactive USB port could have switched over to i2c mode.

From what I was reading on the BADA code, it looks like

RID_CEA936A_TY_2,	/* 1 1 0 1 1	442K	CEA936A Type-2 Charger(1) */

or

RID_TTY_CONVERTER,	/* 1 0 1 0 1	121K	TTY Converter */

may hold some special significance during the boot sequence.
[Hardware Hacking General] AdamOutler:
That was just line noise. however, this is a typo.

check_download: micorusb_status1 = 400, key_value = 0

micor usb. ;)
[Hardware Hacking General] androcheck:
I also tried this with your compiled i2c-tools (nice idea, btw) and could reproduce your described behaviour.
[Hardware Hacking General] androcheck:
I wrote 0x0c into the MANUAL_SW2 (0x14) register and did a normal reboot (pressing power button -> reboot) and after the phone was up again, the value was still in there.

But when I powered off the phone and powered it on again (without removing battery) the value was back to 0x00. So it seems the register values get reset at poweroff.

But it's interesting enough that the register 0x14 did not get reset by the initialization code in the fsa-driver during the bootup of the kernel. I'm running a Gingerbread kernel and it seems that Samsung uses a different initialization there (they no longer use the hidden 0x1b register in gingerbread like they did in froyo to reset the chip).
[Hardware Hacking General] midas5:
From the fsa source code we have this:

/* CONTROL Register*/

#define REGISTER_CONTROL 0x02

/* Manual SW1 Register*/

#define REGISTER_MANUALSW1 0x13

/* Manual SW2 Register */

#define REGISTER_MANUALSW2 0x14

/* Hidden Register*/

#define HIDDEN_REGISTER_MANUAL_OVERRDES1 0x1B

/* Control Register */

#define CON_SWITCH_OPEN (1 << 4)

#define CON_RAW_DATA (1 << 3)

#define CON_MANUAL_SW (1 << 2)

#define CON_WAIT (1 << 1)

#define CON_INT_MASK (1 << 0)

#define CON_MASK (CON_SWITCH_OPEN | CON_RAW_DATA | \

CON_MANUAL_SW | CON_WAIT)

/*

* 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))

/* HIDDEN REGISTER */

fsa9480_write(client, HIDDEN_REGISTER_MANUAL_OVERRDES1, 0x01); //RESET

* Name : fsa9480_MakeRxdLow()

* Description : Make UART port to OPEN state.

* Probably used to remove the pull up resistor from the d+, d-.

* Useful when outputting analogue audio L/R.

fsa9480_write(&fsa9480_i2c_client, HIDDEN_REGISTER_MANUAL_OVERRDES1, 0x0a);

/* Manual switch 2 */

/* reset manual2 s/w register */

fsa9480_write(&fsa9480_i2c_client, REGISTER_MANUALSW2, 0x00);

/* reset manual2 s/w register */

manual2 &= ~(0x1f);

/* BOOT_SW : High , JIG_ON : GND */

manual2 |= (0x1 << 3) | (0x1 << 2);

/* BOOT_SW : LOW , JIG_ON : GND */

manual2 |= (0x1 << 2);

/* ID Switching : ID connected to bypass port */

manual2 |= 0x2;

bit 0 = unknown

bit 1 = ID connected to bypass port.

bit 2 = JIG_ON: GND

bit 3 = BOOT_SW: High

bit 4 = unknown

bits 5-7 probably do not do anything.

So, we have documentation on some of the bits of the registers, and what they do.

We need to experiment with other undocumented parts of the registers.

When testing, sending a 0 to a register bit might activate OM5, or sending a 1 to a register bit might activate OM5.

I.e. We need to test sending 1 and sending 0 to trigger the OM5.

Another problem is that GPIOs can have multiple states. resistor pulled high, resistor pulled low, shorted to high, shorted to low, not-connected.

I.e. It might be a combination of 1,2 or even 3 bits that might give the output we need.
[Hardware Hacking General] Rebellos:
//cutted out wrong info//

Also UART boot is tried at the end of ALL "normal" bootable combinations, dunno what are the requirements yet, probably some serious errors, unable to trigger without JTAG/some brillant I2C injecting of AdamOutler idea. ;d

In any of the following combinations, the normal boot is performed:

//edit:

Also, there doesn't seem to any communication through I2C be performed from iROM in first stage.

//edit2:

If after testing all combinations of FSA9480 registers to check if OM pins state changes, it won't change (it probably will in some way, would be good to write macro which change registers + reads OM after every change)

Other idea is that some mux gate that can modify OM is connected to the pins under battery.
[Hardware Hacking General] TheBeano:
It is bit 5 in the hardware, see the CPU manual "OM Pin configuration" table. The value read from the OM register gets shifted right early on in the boot code (location 0D0059F4) so the value in R4 at 0D005A94 where it does the above test should be between 0x10 and 0x17.

The "normal" boot sequence starting at 0D005AD0 tries NAND, then SDMMC2 (sub at 0D00728C), then UART, then USB.

The "external" boot sequence triggered by OM[5] starts at 0D005C94. It tries UART first, then USB, then all the other boot sources. I notice that this checks the reset status register and will only do the external download from a cold start, so setting OM[5] using some I2C hack and rebooting probably won't work. On a warm start it boots from NAND.
[Hardware Hacking General] AdamOutler:
Very interesting.... So now that we can read the IROM... Is it possible to modify it for testing? Like... Say, boot from UART/MMC/MoviNAND/OneNAND instead of the other way around? Seems like it would be easy to simply change the order of operations... Then we would have a development IROM. The phone could be JTAGed with the new IROM. Any phone equipped with this development IROM would be unbrickable. Question is, can we write to the IROM over JTAG now?
[Hardware Hacking General] AdamOutler:
there does not need to be i2c communications to hijack the bus. Just jump on the bus, generate a clock pulse and tell everyone on the bus to call you 'master'. the i2c bus is a hardwire and supposedly its EXTernal.

The application processor supports master and slave modes natively. Its likely that it assumes slave naturally until commanded to become master. I2c is an inexpensive and industry standard method of Inter Integrated Chip communication. The problem is finding which two lines are the EXT- I2C lines because i2c can be shut down to save power when not in use.. Then the entire system can be hijacked.
[Hardware Hacking General] midas5:
I think you misunderstand how the i2c bus works. It does now have a dedicated clock line. The data line is set and then a state transition on the "clock' line causes the receiving end to "capture" the data bit. The next clock transition can be very soon or delayed. So, you are unlikely to get a regular clean clock signal at a specific frequency so detection will be hard.
[Hardware Hacking General] midas5:
I have done quite a few tests now with setting the fsa registers and Om does not change. Is it possible to change the Om register, or is it only set at boot time? Has anyone got a development board for the S5PC100 chip and can tell the answer?
[Hardware Hacking General] lilstevie:
you cannot just write iROM, it is true ROM.
[Hardware Hacking General] connexion2005:
Using JTAG I have full access to all addressable blocks of the 512MB NAND. However I'm certain the iROM as mentioned is nowhere in these addressable blocks and is a seperate "untouchable" chip or address range. Of course I have no real idea. :)
[Hardware Hacking General] Rebellos:
Sorry, haven't noticed the OM shifting and masking, edited my previous post to not lead people into mistake.

iROM looks to be exactly the same in all S5PC110, no way to change it without ordering brand new bulk S5PC110 serie directly from Samsung.
[Hardware Hacking General] AdamOutler:
No, I understand it quite well. When the i2c bus is inactive, it has no master. This condition occurs during boot up, before the bus has been initialized in the microprocessor. At that point, unless something has tied up the lines with a active low signal, it is possible to jump on the bus and send a write operation to any device. It's a 2 wire hardline to practiaclly everything. With this, I believe it would be possible to send a single write operation to the PBL and fail the checks done by the iROM.
[Hardware Hacking General] AdamOutler:
The OM bits on the development board are set by switches. It is likely that they are inputs only and changing them would require separating the processor/OneNAND ball-soldered connections or cutting traces on the multilayered circuit board. Locating them is very problematic. I attempted to gain an XRay of the board but my XRay did not have the resolution required to examine the extreme small archetecture required by the board.

I can tell you for a fact that the OM values are set by pins on the board.. We don't know if that can be overridden somehow.

TheBeano,

The OneNand has an address on the i2c bus. If commanded by I2C-EXT to write a bit high or low to the PBL, or even write an entire 0xFF segment, the PBL is then perminantly invalidated and will fail checksum every time. It would be possible to rewrite the entire OneNand via I2C, but it would require pausing the CPU so that it does not grab Master status and attempt to override the bus.

So, the setup would be... Apply power and ground to battery pins 1 and 3 and immediately or within a few miliseconds, blast the I2C bus with the command to write a random hexidecimal value at 0x400000(not sure on this address0x4000?) of the OneNand. Upon every reboot after this, the IBL/PBL would be invalidated, thereby failing checksum, and this would enable UART booting.

:D