Lets save some bricks...

midas5 · Apr 10, 2011

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.

TheBeano · Apr 10, 2011

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?

TheBeano · Apr 11, 2011

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.

js22 · Apr 11, 2011

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!

Sent from my SAMSUNG-SGH-I897 using XDA App

AdamOutler · Apr 11, 2011

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.

TheBeano · Apr 11, 2011

AdamOutler said:
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. ???

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.

AdamOutler · Apr 11, 2011

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?

js22 · Apr 11, 2011

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.

AdamOutler · Apr 11, 2011

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

js22 · Apr 11, 2011

AdamOutler said:
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

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.

.Slane. · Apr 11, 2011

js22 said:
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.

It's like the power of a RiffBox without using JTag ! Very interesting thread from the beginning !

TheBeano · Apr 12, 2011

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.

js22 · Apr 12, 2011

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.

Sent from my SAMSUNG-SGH-I897 using XDA App

AdamOutler · Apr 12, 2011

I'm building a universal jig in accordance with the values mentioned in this post http://xdaforums.com/showpost.php?p=12703456&postcount=12

Code:

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?

js22 · Apr 12, 2011

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.

Fuma · Apr 12, 2011

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?

js22 · Apr 12, 2011

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.

TheBeano · Apr 13, 2011

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.

js22 · Apr 13, 2011

TheBeano said:
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.

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...

TheBeano · Apr 13, 2011

js22 said:
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.

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.

Code:

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)

Lets save some bricks...

Senior Member

Senior Member

Attachments

Senior Member

Senior Member

Retired Senior Recognized Developer

Senior Member

Retired Senior Recognized Developer

Senior Member

Retired Senior Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Retired Senior Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts