FORUMS
Remove All Ads from XDA

Hacking Boot Modes from Exynos 4210

5,224 posts
Thanks Meter: 9,890
 
By AdamOutler, Inactive Recognized Developer on 2nd December 2011, 05:23 AM
Post Reply Email Thread
We've sucessfully violated Samsung's Hardware-Based-Chain-Of-Trust once before by modifying the hardware , causing the device to boot from USB at which point we can upload an interceptor bootloader and then any unsigned code of choice.. This was done to resurrect dead devices and help promote development

It's time now to tackle the Galaxy S2(Exynos) platform. A lot of lessons were learned last time.. So we'll start this thing off by saying that it looks like they've removed UART functionality in this edition of Samsung processors. I can understand why... We were able to access a root prompt when the kernel loaded up to charge the battery, as well as clear the download counts, flash partitions and have other full access to the Serial Administration Console... So, it looks like there's no UART available.

I took the liberty of creating the Galaxy S2 Hack Pack which will help out. This contains the Public processor manual, the i9100 service manual and a ton of other helpful tools.

Contained within the Level 3 service manual was a processor pinout with each pin labeled. I yanked that out of the processor manual, put it into GIMP, flipped it, labeled it prepaired it. This contains all the pins and they're labeled.. but they're small, so I enlarged the ones we're concerned with.



Here's the i9100 board. I obtained this great image from ifixit.



Now, we can apply the overlay to the board and....


Now if we look to the left in the picture above we can see that there are 5 resistor switches. The right side is low and the left side is high. there are 3 high, 1 low and 1 disconnected.

The Development board for this processor shows only 5 switches though, 2 of the 7 signals we are concered with (xOM0 and xOM6) are hardwired and non-switchable. This leaves a promissing 5 switches.. However I don't know what to make of the one which is disconnected. Logically the shortest path would apply here and look something like this:



So, since xOM5 switched boot mode from OneNAND to UART>USB>OneNAND on the Hummingbird.. Considering xOM6 doesn't count on this device.. I'm thinking xOM5 could control boot mode on this device as well.

Any input? I have a i9100 here.
The Following 7 Users Say Thank You to AdamOutler For This Useful Post: [ View ] Gift AdamOutler Ad-Free
2nd December 2011, 08:51 PM |#2  
according to the documentation in the processor manual the xOM register may be read from 0x1000_0008, this is the OP_MODE register and it should contain a 8 bit binary word (2 hexidecimal digits) which displays the xOM value.
2nd December 2011, 08:51 PM |#3  
Senior Recognized Developer
Flag Gdańsk
Thanks Meter: 3,469
 
Donate to Me
More
I've got many useful data already, but missing the most important one - complete Exynos manual. All I've got about CPU alone is 4,3MB document called "SEC_Exynos4210_pulbic_manual_Ver.0.00.01.pdf" it's incomplete.
Can you people look for newer version or any related documentation? It's very important to me to get such.
(Yes, I also have OrigenBoard schemas)

What may help in looking is that Exynos4210 marking is S5PV310/S5PC210 (don't mix up with Hummingbird which is S5PV210/S5PC110/S5PC111), sometimes it's also called as Exynos4 which is wrong name, because it's probably different CPU, but Samsung tends to mix up their own products so who knows.
The Following User Says Thank You to Rebellos For This Useful Post: [ View ]
2nd December 2011, 09:30 PM |#4  
The The xOM0 pin controls clocks. This pin is for sure irrelevant to changing boot order.

Here's some documentation relating to the boot
Code:
Owing to the recent increase in the prices of NOR flash memory and the moderately priced DRAM and NAND
flash, customers prefer to execute boot code on NAND flash and execute the main code on DRAM.
The boot code in Exynos4210 can be executed on external NAND flash. It will copy NAND flash data to DRAM. To
validate the NAND flash data, Exynos4210 comprises of hardware Error Correction Code (ECC). After the NAND
flash content is copied to DRAM, main program will be executed on DRAM. NAND flash controller uses
ACLK_133 clock, which is from clock controller (FSYS).
Analysis: ECC is used.. This may prevent changes to a live bootloader

Code:
Auto boot: The boot code is transferred to internal SRAM during reset. After the transfer, the boot code will be
executed on the SRAM.
Analysis: Code is executed in SRAM, this is different from DRAM in Hummingbird. It is possible that code may be injected somehow during reset... point of weakness to examine.

Code:
64 KB ROM for secure booting and 128 KB RAM for security function
Analysis: I do not like this Secure Ram thing.. We need more documentation to figure out how SRAM works.


Code:
The Watchdog Timer (WDT) in Exynos4210 is a timing device that resumes the controller operation after
malfunctioning due to noise and system errors. WDT can be used as a normal 16-bit interval timer to request
interrupt service. The WDT generates the reset signal.
Analysis: the Watchdog timer will initiate a reset if not reset. this timer must be reset every 65,536 units of measure. Apparently this is powered by the 100 MHz ACLK_100 signal. This could be a window of opportunity.. however it might be entirely too small if this is a 1:1 clock.

here is the Watchdog Timer calculation
Code:
1/(CLK/(Prescaler value + 1)/Division_factor)
where
CLK=100,00,000
prescaler value is 0 to 2^8-1. (0-255)
Division_Factor is 16, 32, 64, or 128.

So, the watchdog timer on this device can reset anywhere between .0003 seconds and .000000017 seconds... acording to my calculations.

Code:
Once the watchdog timer is enabled, the value of watchdog timer data (WTDAT) register cannot be automatically
reloaded into the timer counter (WTCNT). Therefore, an initial value must be written to the watchdog timer count
(WTCNT) register, before the watchdog timer starts.
Analysis: If we manage to get code booted onto the device, the watchdog must be kicked frequently during the boot sequence or disabled all together.

The watchdog timer may be disabled by setting 0x1006_0000 bit0 to a 0. this would render the watchdog useless as it will not reset the device.

We need manuals to find out the boot modes of this device. I will probe more this weekend, but we really need the finalized manuals.
2nd December 2011, 10:59 PM |#5  
chrisrotolo's Avatar
Senior Member
Flag Corona, CA
Thanks Meter: 469
 
Donate to Me
More
Smile
just dropping in to say thank you guys for all your hard work. You guys rock the world!! I just ordered my Galaxy Tab 7.0 Plus HSPA+ with voice feature from Malaysia. This mod will be a huge help for development,etc.
3rd December 2011, 06:30 AM |#6  
This is a stock device
Code:
# viewmem 0x10000008 |hexdump
[INFO] Reading 4 bytes at 0x10000008...
0000000 2001 1011                              
0000004
The bits we are looking at is the "20". 20 makes out to b00100000..
Translated:
xOM0=0
xOM1=0
xOM2=0
xOM3=0
xOM4=0
xOM5=1
xOM6=0


Meaning these binary values must be inverted from HIGH to LOW... Or I am reading the wrong area of memory.

Rebellos, you mentioned that the device takes the OM register into memory at startup and it's likely not changed dynamically. Any insight here?
3rd December 2011, 07:10 PM |#7  
I thought I would begin locating UART. So... here's what I'm doing..

I set up the device to connect on startup to my wifi
I rooted the device
I purchased market app QuickSSHd and set it up to begin a root ssh connection
I removed the device from its case and taped the battery in place so that I could work with the board itself
Finally, I made this script which causes the device to echo "ttySAC0" to /dev/ttySAC0... same for SAC1 and SAC2. It also increments a counter so I know the device is still operational.

Code:
check=0;
mknod /dev/ttySAC0 c 204 64;
mknod /dev/ttySAC1 c 204 65;
mknod /dev/ttySAC2 c 204 66;
while [ 0 ]; do 
    echo -e "ttySAC0\n\n">/dev/ttySAC0;
    echo -e "ttySAC1\n\n">/dev/ttySAC1;
    echo -e "ttySAC2\n\n">/dev/ttySAC2;
    check=`let $check+1`;
    echo $check;
done;
Now I can probe the device and find the UART consoles. Each ttySAC corresponds to UART... UART0=SAC0, UART1=SAC1, UART2=SAC2.

We are most concerned with UART2, however, it would appear thus far, that I cannot locate any UART consoles on this device.

Here's how I probe:
4th December 2011, 04:22 AM |#8  
Senior Recognized Developer
Flag Gdańsk
Thanks Meter: 3,469
 
Donate to Me
More
UsbBoot seems to be invoked directly only when OM values are
0 low, 1 low, 2 high, 3 high, 4 high, 5 high, 6 high, 7 low

OM7 and OM0 looks to me to be irrevelant to booting order. But all of the infos I get are more or less guess.

Too bad for us. As default only OM5 seems to be high or all are low.

I badly need updated CPU manual, the one I have is nearly useless.

described as OM register = 0x10000008
non stated in manual other OM register = 0x10020000 (offset 0 of PMU block)
OM cache also used by iROM to inform IBL if it's supposed to invoke USB or UART boot is 0x10020980
They seems to differ alot between themselves, Adam is unable to find UART which is also bad.
Probably i'm stuck until Sammy release more detailed documentation about CPU. :/
4th December 2011, 05:04 AM |#9  
I too am stuck as I cannot probe for more information without some sort of live debugging interface like UART. It seems that samsung may have messed up here because UART is available on models after this one like i777. We need more information. Here's what we need to continue and save bricked Exynos devices.

1. Datasheets on Exynos processor
2. Schematics or documantation. showing AP UART testpoints and/or locations
7th December 2011, 04:29 PM |#10  
I just wanted to link this topic in http://forum.xda-developers.com/show....php?t=1313588

This shows the UART output we are expecting.. However the i9100 was made incorrectly so research on this device will be impossible. I am looking for a i777 to continue this project.
1st February 2012, 03:19 AM |#11  
E:V:A's Avatar
Inactive Recognized Developer
Flag -∇ϕ
Thanks Meter: 2,216
 
More
Lightbulb
Quote:
Originally Posted by AdamOutler

I thought I would begin locating UART. So... here's what I'm doing..
...
We are most concerned with UART2, however, it would appear thus far, that I cannot locate any UART consoles on this device.

Hi, 2 things: (on a GT-I9100)

1. Why are you making new SAC devices, are they not already present?
Another way to check device types is by:

# cat /proc/tty/drivers
Code:
/dev/tty             /dev/tty            5       0              system:/dev/tty
/dev/console         /dev/console        5       1              system:console
/dev/ptmx            /dev/ptmx           5       2              system
/dev/vc/0            /dev/vc/0           4       0              system:vtmaster
rfcomm               /dev/rfcomm         216    0-255           serial
g_serial             /dev/ttyGS          253    0               serial                  "Datarouter" & see dun: (10,123)
ttySAC               /dev/s3c2410_serial 204    64-68           serial                  SAmsung Console (UART)
serial               /dev/ttyS           4      64-67           serial
pty_slave            /dev/pts            136    0-1048575       pty:slave
pty_master           /dev/ptm            128    0-1048575       pty:master
pty_slave            /dev/ttyp           3      0-255           pty:slave
pty_master           /dev/pty            2      0-255           pty:master
unknown              /dev/tty            4      1-63            console
However, these are not always immediately available, when
not in use. E.g. You will not have an /dev/rfcomm unless you have
activated Bluetooth. In addition you can check your ttySAC's with:

# cat /proc/tty/driver/ttySAC
Code:
serinfo:1.0 driver revision:
0: uart:S3C6400/10 mmio:0x13800000 irq:16 tx:0 rx:0 DSR|CD
1: uart:S3C6400/10 mmio:0x13810000 irq:20 tx:205473 rx:1666 RTS|CTS|DTR|DSR|CD
2: uart:S3C6400/10 mmio:0x13820000 irq:24 tx:0 rx:0 DSR|CD
3: uart:S3C6400/10 mmio:0x13830000 irq:28 tx:0 rx:0 DSR|CD
4: uart:S3C6400/10 mmio:0x13840000 irq:320 tx:0 rx:0 CTS|DSR|CD
2. Have you set the USB connection behavior in the PhoneUtils (service/engineering) menu?

Dial: *#7284#

Code:
UART:
[o] MODEM*
[ ] PDA
USB:
[ ] MODEM
[o] PDA*
* is default SGS2 setting.

However, my problem is that if I change to USB-MODEM, then my PC no longer find the correct drivers, and I have no clue where to find them. Perhaps the Bada guys may know something about this...

---------------------------------- adendum --------------------------------

[EDIT 2012-02-15]
On second thought, this is really some kind of MUX, so you have to put your UART to point to PDA (AP)!
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes