Lets save some bricks...

Status
Not open for further replies.
Search This thread

js22

Senior Member
Feb 12, 2011
79
26
I've been reading up on SGS hardware and bootloaders, and I feel like there's a very good chance that there's a way (within reach? ??) to to fix a totally bricked phone.

NOTE: I'm no expert on this stuff. If I'm missing something totally stupid, please forgive me. Anyways, here goes...


The user manual for the s5pc110 chip describes the booting process; it has 3 levels. On hw reset the cpu begins executing code that lives in ROM. The ROM code loads the primary bootloader from a source selected by external pin inputs. The PBL pretty much just loads the SBL, which does the major setup and loads the kernel.

The important thing, which I haven't seen anyone discuss, is that the initial ROM code includes the ability (poorly documented, of course) to load the PBL from UART or USB.

Repeat : non-eraseable code in our phones which is executed on hw reset can load a bootloader over serial or USB into memory and then execute it.

From other threads, we know that Samsung is able to restore a bricked phone without opening it up. Why should they have all the fun?

The first step is asserting the proper pins. This is done by connecting the proper resistance betw pins 4 & 5. The 'jig' thread describes using 301k to get into download mode, but this is happening in the SBL. Many other R values are desribed in the 'fun with resistors' thread and in the fsaXXXX-i2c.c kernel source. One of them does a reboot and connects a (3.3V) UART to the D+/D- pins.

One thing that is described in the docs is that the ROM code tries UART first and then fails over to USB. Since UART is so much simpler, I'd say that's where to begin.

We already learned in that thread that connecting at 115200 baud and banging on RETURN brings up a "SBL>" prompt with lots of cool commands available. But as TheBeano pointed out, that's not much use if the SBL is toast.

What I'm wondering is whether there's a way to interrupt the normal boot while its still running ROM code. There's no reason the ROM would set up the UART at the same baud rate as the SBL and kernel. Maybe just a lower baud and banging on RETURN is enough.

For anybody with the time and the hardware, that should be easy enough to try. TheBeano?

There's probably some handshake/protocol issues to figure out to get a bootloader loaded and executing, but we do have a known good one (the PBL) to play with.

If that can be made to work, it would be a huge step towards a working solution. There is code floating around (I saw it on the teamhacksung git) that ports u-boot bootloader to our phones. AFAIK, nobody around here has tried it. But if we are able to test bootloaders w/o flasing, then maybe we (someone with a clue about bootloaders,that is) can open the door to safe, open-source booting.


So that's it. Is this crazy-talk, or do you guys n gals think it just ... might ... work?
 

Odia

Guest
Jan 4, 2009
668
785
I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible ;)

I will add a little insight without giving too much away :)

Its also possible to start the phone via JTAG and pass the control over to USB or UART, even to enter DLM and flash the phone without repairing the current IBL/PBL/SBL within the phone which are damaged, e.g. the loaders are running in RAM this is done via CMM or JNAND ...

I have the full unstripped source code for the PBL and SBL and may consider releasing them if some input starts in this thread, its all too easy just to give them out without the scene thinking on its feet ;)

Oh BTW: My dog spoke to another dog who's owner works for Samsung and he told him that the 2.3.3 release, will be released when its f**king ready and not 1 day before.
 
Last edited:

TheBeano

Senior Member
Jul 18, 2010
355
218
Sorry I meant to post to this thread earlier. I looked at this a while ago but the main thing that baffled me was that according to the CPU data sheet, to enable booting from USB or UART you needed to set some bits on the processor OM pins, and I couldn't see how to do that without internal access to the hardware, unless they are wired up to, or switched by, the fsa9480 somehow?

I've looked at the schematic fragments from the service manual but they weren't much help. If anyone has a schematic that shows what is connected to the application processor OM pins that would be a big help. Obviously the bootloader sources would be great too!
 

Odia

Guest
Jan 4, 2009
668
785
Obviously the bootloader sources would be great too!

Come on guys, lets have some input here, and I will give out snippets of info to help, just in case anyone is in any doubt to what I said, take a look at the attached screendump ;)
 

Attachments

  • sbl.jpg
    sbl.jpg
    107.5 KB · Views: 5,224
  • Like
Reactions: dmezh

azzledazzle

Senior Member
Dec 12, 2010
5,136
1,995
XDA Sucks !
Maybe this thead has to move to Rom development not many devs in general ;)

If you have the sources then its possible to make our own bootloaders and dual boot :) whatever we want maybe win 7 (it's a joke)

Hey, off topic here, but i have seen these phones on ebay, chinese own brand of course, but dual boot, runs both android and windows on one phone.

so it is possible for someone who knows how to.... would be very interested in seeing this develop :D

http://cgi.ebay.co.uk/W6000-Dual-Ca...ile_Phones&hash=item230f1eea0a#ht_3411wt_1139
 
  • Like
Reactions: Aljosko

TheBeano

Senior Member
Jul 18, 2010
355
218

Fuma

Senior Member
Nov 12, 2010
252
17
Thanks, there were some schematics in that first one named "Samsung GT-i9000 Schematics.pdf" that had me going for a while, but they are from a different phone! Some Mediatek thing. The service manual files only have excerpts from the full schematics.


different phone? I9000B? sorry. thought it was all I9000.
well i tired...:)
 

Fuma

Senior Member
Nov 12, 2010
252
17
mmm...well if i stumble upon more stuff i'll send your way . it might help.
 

js22

Senior Member
Feb 12, 2011
79
26
Sorry I meant to post to this thread earlier. I looked at this a while ago but the main thing that baffled me was that according to the CPU data sheet, to enable booting from USB or UART you needed to set some bits on the processor OM pins, and I couldn't see how to do that without internal access to the hardware, unless they are wired up to, or switched by, the fsa9480 somehow?


Yeah, it's got to be the fsa9480. That plus (possibly) the volume/power/etc buttons are the only possibilities. The fsa switches which lines from inside the phone are connected to the micro-USB pins 2 & 3 (aka D+/D-). But it also has (at least) 2 digital outputs called JIG and BOOT which feed back to the CPU. BOOT presumably causes a hardware reset, so the JIG line is free to determine the boot mode.

We know the normal boot is from OneNand. Looking at table 6.3 of the data sheet tells us that the only pin that matters is OM5. Pins OM[4:0] determine which of the 4 different OneNAND boot modes is used, and that mode is the same regardless of OM5. So they are almost certainly just fixed. If OM5 is 0, the chip boots normally (directly from OneNAND). If it is 1, the ROM will first try to negotiate a UART connection, then try a USB connection, and only then (if I'm reading it right), fail over to a normal OneNAND boot.

So it's hard to imagine any scenario other than pin OM5 connected to the JIG output of the fsa9480.

From the Samsung source code linux/drivers/usb/gadget/fsa9480_i2c.h, there are a few interesting resistor choices (I'm not sure what the 5 bits represent; maybe they are for setting/reading the switch state over i2c) :


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

The 301K case (Factory Mode Boot ON USB) is the familiar "jig" people on xda use. But USB protocol is fairly complex, and since the whole idea of using the fsa switch is very non-USB compliant (the thing sends analog audio over D+/D- lines !) I don't think we can assume anything about what the ROM code does to "negotiate a connection". In addition, I think that all the people who have already looked into this were specifically trying to get into "download mode" (i.e., Loke protocol to talk with Odin). So who knows what else was going on beforehand.


I'm most curious about the behavior with a 619k resistor (Factory Mode Boot ON UART). The nice thing with UART mode is that we already know from TheBeano's thread that there is output at 115200 baud that appears at some point in the boot process. By putting a scope probe on the Tx line and simultaneously watching the text output in a terminal emulator, it should be very simple to see if any kind of negotiating is going on at an early (ROM) bootloader stage. Maybe it involves different baud rate, banging on a key, or pressing/holding a button. But (for someone with time and the right hardware) this is very do-able. If there is any hint of negotiation going on before the NAND-based bootloaders begin, we know we're onto something promising.


Like Odia pointed out, any stuff that we load during the ROM bootloader stage is not being flashed to the OneNAND; it is simply being loaded into RAM and executed. So even with no clue how to write a bootloader, I can imagine writing a "hello world"-grade program to, say, toggle a GPIO. That would clearly establish that the UART bootload procedure works.

So I think its an exciting prospect. Some of it is way beyond my abilities, but there are some easy steps early on that could really generate some intense developer interest.

I've got a I897 and a scope, but no connectors or cables to sacrifice. I may get a breakout board from Sparkfun to mess around with. In the meantime, I'd love to hear if anybody with a resistor/cable combo can sniff out anything interesting.

Also, I'm glad to see some response. I guess my title was a little cryptic, but at first it was just me and the crickets.
 
Last edited:

js22

Senior Member
Feb 12, 2011
79
26
Found an interesting post about the ROM bootloader : http://blog.maurus.be/index.php/2011/01/samsung-i9000-irom-dump/

Another interesting link : http://chdk.wikia.com/wiki/GPL_Disassembling

Lets just say that the ROM code from my phone (Captivate) is definitely talking to the serial ports (all 4) and the USB OTG port.

I just sent off a quick order to Sparkfun for their USB micro-B breakout (the male connector with all 5 pins broken out) and a 3.3V FTDI (USB/serial) board. Just in case I find myself w/ too much time on my hands.
 

Fuma

Senior Member
Nov 12, 2010
252
17
js22 thats actually sounds promising.
waiting for more updates.
Goodluck
 

js22

Senior Member
Feb 12, 2011
79
26
e-fuse bits anybody ?

The one nagging concern I've been having about this scheme is the option built into the s5pc110 processor (our cpu) of "secure booting". The iROM code checks a set of "e-fuse" bits, and if one of them is non-zero, it uses the rest as an encryption key to verify that the bootloader it loads is signed. The e-fuse bits, as their name implies, are write-once. After the phone has been configured for either secure or non-secure booting, that choice cannot be altered.

I have been kinda assuming that secure booting is not enabled, b/c there is a similar option for JTAG access, and we know it is not enabled. Also, the phone is running an open-source OS and there is no real infrastructure in Android for DRM. Basically, if there is nothing to protect, why bother ?

After poking around in the data sheet, I haven't found anything that specifically says : "this is where you can read the e-fuse bits". I did, however, see a region of SFR space located at 0xE0E0_0000 that is called SECKEY. The boot ROM checks the values of several words near the start of this area, and takes a different branch if it finds any non-zero value.

I tried a viewmem dump of this stretch of memory, and got all zeros.

So either :
a) my Captivate does not have secure booting enabled, or
b) I don't know what I'm doing.


Does anybody have any more info on the e-fuses ?
 

js22

Senior Member
Feb 12, 2011
79
26
Oops. I just checked and any read from the SFR address range (0xE0E00000 and up) returns zero. At least if you're using viewmem.
 

Odia

Guest
Jan 4, 2009
668
785
The one nagging concern I've been having about this scheme is the option built into the s5pc110 processor (our cpu) of "secure booting". The iROM code checks a set of "e-fuse" bits, and if one of them is non-zero, it uses the rest as an encryption key to verify that the bootloader it loads is signed. The e-fuse bits, as their name implies, are write-once. After the phone has been configured for either secure or non-secure booting, that choice cannot be altered.

I have been kinda assuming that secure booting is not enabled, b/c there is a similar option for JTAG access, and we know it is not enabled. Also, the phone is running an open-source OS and there is no real infrastructure in Android for DRM. Basically, if there is nothing to protect, why bother ?

After poking around in the data sheet, I haven't found anything that specifically says : "this is where you can read the e-fuse bits". I did, however, see a region of SFR space located at 0xE0E0_0000 that is called SECKEY. The boot ROM checks the values of several words near the start of this area, and takes a different branch if it finds any non-zero value.

I tried a viewmem dump of this stretch of memory, and got all zeros.

So either :
a) my Captivate does not have secure booting enabled, or
b) I don't know what I'm doing.


Does anybody have any more info on the e-fuses ?

Its using none secure boot and your quite right JTAG access is also none secure.
 

midas5

Senior Member
Mar 24, 2011
303
30
So, the source code to the IROM would answer all our questions.
It would probably take me a week to reverse engineer it, unfortunately, I don't have the time right now.
The I9000 is a fairly open platform. Would samsung themselves be prepared to give this source code out.
If we could get to a point where any hacker could un-brick their own phones without even having to unscrew the case, using pin 4-5 resistors, and a 3 Volt UART cable or a USB cable, developers would be much more willing to experiment more.
I have a method to force the IROM to try alternative boot methods, and specifically not run the PBL, SBL, but without more information on what to try in order to talk to the IROM directly, is it difficult to proceed further.
To force IROM to ignore PBL and SBL, just do a heimdall dump in Linux and press CTRL-C half way through. It results in a bricked phone, with only the IROM working. I have been told a 301K Resistor will help switch it back to loading PBL and SBL but I have not tested this yet.

Does anyone have contacts within Samsung that might be able to help, or shall I try to use my contacts to source the information?
 
  • Like
Reactions: jutezak

midas5

Senior Member
Mar 24, 2011
303
30
The IROM looks like it would try to use the USB in OTG mode. Thus expecting the external USB device to be a gadget and not a PC Host. This can have advantages and disadvantages.
1) Disadvantage: Not many Android developers will have USB Gadget test hardware.
2) Advantage: The I9000 itself might be a good USB gadget development tool. Changing the kernel usb driver so that it can respond correctly to commands from the IROM over USB. Potentially, we could then use one I9000 connected directly to another I9000 and the healthy I9000 could automatically unbrick the bricked I9000.

For development though, I think using the UART option would be easier to do, as any Android developer would have a serial port, and then just need a RS232 levels RS232 to 3.3V levels converter, wired up to a Micro-USB connector and the correct resistor on the ID pin.
It is also easier to write a Serial port controlling application than USB controlling applications.

I think that we would still need to reverse engineer the IROM in order to analyze it and discover what the protocol is for loading software directly into the I9000 RAM and running it without going through the boot of IBL/PBL/SBL.
We would then need to write our own boot loader to put in this RAM in order for it to reach a mode where it can program the flash and possibly provide the same functions as the current "download mode".
If we can get it as far as partitioning, and writing the IBL/PBL/SBL. That would be enough.
There are other advantages of this IROM interface. We could use it to root the phone by writing an "su" to the /system folder.

A stepping stone to this could be a "hello world" program that simply controls a GPIO. For example, flashing the LEDs that light the BACK key or writing a message to the screen.
Having the current source code to the IBL/PBL/SBL would really help here as it contains the routines to display characters and graphics on the display etc.
 

TheBeano

Senior Member
Jul 18, 2010
355
218
I'm partway through disassembling the ROM boot code, it's pretty interesting! The serial protocol is definitely in there, but I haven't worked with ARM code before so it may take some time. If anyone has already worked it out or is nearly there please let me know now!! :)
 
Status
Not open for further replies.

Top Liked Posts

  • There are no posts matching your filters.
  • 19
    I've been reading up on SGS hardware and bootloaders, and I feel like there's a very good chance that there's a way (within reach? ??) to to fix a totally bricked phone.

    NOTE: I'm no expert on this stuff. If I'm missing something totally stupid, please forgive me. Anyways, here goes...


    The user manual for the s5pc110 chip describes the booting process; it has 3 levels. On hw reset the cpu begins executing code that lives in ROM. The ROM code loads the primary bootloader from a source selected by external pin inputs. The PBL pretty much just loads the SBL, which does the major setup and loads the kernel.

    The important thing, which I haven't seen anyone discuss, is that the initial ROM code includes the ability (poorly documented, of course) to load the PBL from UART or USB.

    Repeat : non-eraseable code in our phones which is executed on hw reset can load a bootloader over serial or USB into memory and then execute it.

    From other threads, we know that Samsung is able to restore a bricked phone without opening it up. Why should they have all the fun?

    The first step is asserting the proper pins. This is done by connecting the proper resistance betw pins 4 & 5. The 'jig' thread describes using 301k to get into download mode, but this is happening in the SBL. Many other R values are desribed in the 'fun with resistors' thread and in the fsaXXXX-i2c.c kernel source. One of them does a reboot and connects a (3.3V) UART to the D+/D- pins.

    One thing that is described in the docs is that the ROM code tries UART first and then fails over to USB. Since UART is so much simpler, I'd say that's where to begin.

    We already learned in that thread that connecting at 115200 baud and banging on RETURN brings up a "SBL>" prompt with lots of cool commands available. But as TheBeano pointed out, that's not much use if the SBL is toast.

    What I'm wondering is whether there's a way to interrupt the normal boot while its still running ROM code. There's no reason the ROM would set up the UART at the same baud rate as the SBL and kernel. Maybe just a lower baud and banging on RETURN is enough.

    For anybody with the time and the hardware, that should be easy enough to try. TheBeano?

    There's probably some handshake/protocol issues to figure out to get a bootloader loaded and executing, but we do have a known good one (the PBL) to play with.

    If that can be made to work, it would be a huge step towards a working solution. There is code floating around (I saw it on the teamhacksung git) that ports u-boot bootloader to our phones. AFAIK, nobody around here has tried it. But if we are able to test bootloaders w/o flasing, then maybe we (someone with a clue about bootloaders,that is) can open the door to safe, open-source booting.


    So that's it. Is this crazy-talk, or do you guys n gals think it just ... might ... work?
    5
    I am actually very surprised that no one has replied to this, it is actually a very good idea and also very possible ;)

    I will add a little insight without giving too much away :)

    Its also possible to start the phone via JTAG and pass the control over to USB or UART, even to enter DLM and flash the phone without repairing the current IBL/PBL/SBL within the phone which are damaged, e.g. the loaders are running in RAM this is done via CMM or JNAND ...

    I have the full unstripped source code for the PBL and SBL and may consider releasing them if some input starts in this thread, its all too easy just to give them out without the scene thinking on its feet ;)

    Oh BTW: My dog spoke to another dog who's owner works for Samsung and he told him that the 2.3.3 release, will be released when its f**king ready and not 1 day before.
    4
    WE HAVE HELLO WORLD

    Rebellos! You are the man!

    Ok, steps to reproduce:

    1. Perform UnBrickable mod from the first post in this thread. http://xdaforums.com/showthread.php?t=1206216

    2. With the phone off, Insert battery into phone. Press power on button for 1 second. Observe message on internal UART:
    Code:
    Insert an OTG cable into the connector!
    ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
    Uart negotiation Error

    3. Insert the OTG Cable (standard USB cable plugged into USB port on phone-- OTG port) and obvserve message on internal UART port:
    Code:
    ������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������
    Uart negotiation Error

    4. on a Linux system run the "dltool" and use this firmware http://xdaforums.com/attachment.php?attachmentid=698077&d=1314105521 from Rebellos
    Code:
    adam@Adam-Desktop:~/Desktop/dltool$ sudo ./smdk-usbdl -f ./s5pc110_test/s5pc110_testcode.bin  -a D0020000
    SMDK42XX,S3C64XX USB Download Tool
    Version 0.20 (c) 2004,2005,2006 Ben Dooks <ben-linux@fluff.org>
    
    S3C64XX Detected!
    => found device: bus 001, dev 050
    => loaded 16384 bytes from ./s5pc110_test/s5pc110_testcode.bin
    => Downloading 16394 bytes to 0xd0020000
    => Data checksum af84
    => usb_bulk_write() returned 16394
    adam@Adam-Desktop:~/Desktop/dltool$

    5. Observe Internal UART message:
    Code:
    Hey you!
    Out there on the road,
    Always doing what you are told,
    Can you help me?
    which repeats every 20 seconds.

    GREAT WORK!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    3
    TheBeano what service manual will help you? full one?
    http://www.filesonic.com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar full one.

    http://megaupload.com/?d=C0JHS7A8 - service training manual 01/2011
    2
    ^^ Thanks.... So what do we have when the primary bootloader is destroyed?

    Here is a general purpose video describing what we have so far.