yashsingh1/xdaforums huggingface dataset:
[Thunderbolt General] miss.jupiter:
I am not too sure if anyone has come across the same issue as I have but I wanted to share this with everyone.

Basically I had noticed that I was having major issues w/my contacts loading up when initiating my dialer and most of my widgets were not loading up, and last but not least a lot of my apps continuously force closed through out the day.

Long story short... if you're having these issues I suggest you uninstall Launcherpro. I actually was utilizing Launcherpro plus but apparently, Launcherpro has been the root of the problem for most of these issues and also was a major part as to why my battery would not stay at full charge for long. And to my surprise I was actually able to confirm with a tier 2 tech support rep...

Once I uninstalled it I was able to use my phone flawlessly again.

AGAIN... I'm sorry if this has already been mentioned previously but I was going insane thinking that I had a defective phone, so for anyone that is having these issues please know that Launcherpro apparently is not compatible quite yet to the TBolt.
[Thunderbolt General] doctajay:
I haven't had a issues with LP on my Tbolt, and to be honest I feel like my battery has actually improved since I installed it.
[Thunderbolt General] magicriggs:
All phoes react different. When I got my tbolt I was having issues with my sms. This was like 3 hours after I got the phone. So I did a factory reset on my device and no problems whatsoever. (Knock on wood) hope this helps.
[Thunderbolt General] ethan.r.besbris:
i cant get lpp to show my sms notification count in the dock, so i switched to go launcher...
[Thunderbolt General] droid fetish:
+1 launcher pro rocks:D
[Thunderbolt General] aj356:
I was wondering why my contact would take forever to load up when I wanted to make a phone call lol. Works fine now that I uninstalled Launcherpro. Thanks!
[Thunderbolt General] ikon8:
The dialer contacts problem was solved in another thread. All you have to do is change the dock shortcut to something else and then change it back to the dialer, works perfectly fine now. I've been using LPP since day1 and haven't had any of the other issues you're having so I'm not sure what's going on there.
[Thunderbolt General] aj356:
I guess I missed that thread lol. Back to normal now :)
[Thunderbolt General] bmcclure937:
My LPP is fine.
[Thunderbolt General] miss.jupiter:
Wow really thanks so much for the feedback guys. I thought I was going crazy.
[Desire General] Sleehond:
Hello people!

I have some strange problems with my battery, at least, i think my battery is not doing the right things.

The problems:

1) battery is on charger. When reached 90% the LED is on green. For me pretty strange, since you expect a green LED on 100%, right?

2) When my battery is on about 15% my phone already shuts down. Why already on 15%, i mean for me 5-10% is more obvious.

My question to you:

Is my battery dead?

Is my battery giving wrong indications or something?

Thanks in advance!
[Desire General] TheGhost1233:
That the light turns green at 90% is normal in all AOSP rom's. That your phone shuts off at 15% is probably because you "calibrated" your battery once. In the calibration thread they mention a fix somewhere.
[Desire General] Sleehond:
Yes i have calibrated the battery before indeed. Can't find this fix so far. Anyone else who can find this fix. Theghost1233 thanks for your reply ;-)
[Hardware Hacking General] js22:
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?
[Hardware Hacking General] Odia:
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.
[Hardware Hacking General] TheBeano:
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!
[Hardware Hacking General] Odia:
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 ;)
[Hardware Hacking General] manosv:
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)
[Hardware Hacking General] Fuma:
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
[Hardware Hacking General] azzledazzle:
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
[Hardware Hacking General] TheBeano:
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.
[Hardware Hacking General] Fuma:
different phone? I9000B? sorry. thought it was all I9000.

well i tired...:)
[Hardware Hacking General] TheBeano:
It's the schematic for a cheap phone with the Mediatek MT6225 processor, the "CSL Blueberry" I think. They have an "i9000" model so maybe that's how it started. :)
[Hardware Hacking General] Fuma:
mmm...well if i stumble upon more stuff i'll send your way . it might help.
[Hardware Hacking General] js22:
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.
[Hardware Hacking General] Fuma:
js22 thats actually sounds promising.

waiting for more updates.

Goodluck
[Hardware Hacking General] js22:
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 ?
[Hardware Hacking General] js22:
Oops. I just checked and any read from the SFR address range (0xE0E00000 and up) returns zero. At least if you're using viewmem.
[Hardware Hacking General] Odia:
Its using none secure boot and your quite right JTAG access is also none secure.
[Hardware Hacking General] midas5:
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?
[Hardware Hacking General] midas5:
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.
[Hardware Hacking General] TheBeano:
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!! :)
[Hardware Hacking General] AdamOutler:
I decided to play around with this to see if I could start something... I had my arduino loop 0xAA into the UART

I received this as the first few characters.

0|5|FF|

On my working phone I received

It's for sure receiving this information. Is there any more analysis you can do on that bit of code you were talking about? I don't know where to even find the PBL or IBL code, however this does represent a change.

I believe this:
[code]Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.

which is missing from the log above is generated when the PBL reads the environmental variables from Param.ifs. We need to look at the params... This could save some bricks.
[Hardware Hacking General] midas5:
Adam,

Good work. We have a new mode to play with. while booted on a working phone, have you tried the viewmem for OM5 with the 619k and vol up/dn?
[Hardware Hacking General] midas5:
Hi. Has anyone tried watching the uart output while pressing the reset button? it is on the back of the i9000, between the camera and the speaker?
[Hardware Hacking General] js22:
I've got a Captivate; I don't think it has a reset button.

Is this a easily-accesible kind of button an average user would press, or a tiny hidden one ?
[Hardware Hacking General] azzledazzle:
its a tiny one, i made a post about it because i didnt know what it would do lol.

it will take a pin to push it in, i will try it next time i re-flash, but until then im not ready for the consequences lol
[Hardware Hacking General] js22:
Well, I yielded to temptation and opened up my Captivate. The Board is quite a bit different from the i9000 pictured in the service manual from early in this thread. The FSA9480 chip (aka U301) is on the other side of the board : it is facing the back panel of the phone, or up as you are digging into it. I'll post a (not so great) picture I took of it.

The markings on the chip are PKNAR and N4. Slightly different from the markings for the i9000 (PAHB8 and N4), but those are probably manufacturing date codes.

Because the chip is on the back side of the board (i.e. "up"), it turns out you don't have to do very much disassembly to get at it. Just remove the 6 screws holding the case together, pry the case apart, and then remove the speaker module. The speaker module hides the chip just a little.

As before there are two gold test points adjacent to the FSA9480. Although they look huge in the photos, they're pretty darn small. But I was able to get a scope probe tip on them and watch them as i connected my USB adapter. Both lines remain low (0V) with a 619k resistor. I had hoped that one of them was OM5.

[EDIT : I meant I had hoped one of them was the "JIG" line from the FSA chip; I hoped the other one was OM5 :) ]

I was a little nervous doing brain surgery on my (under warranty), one-and-only daily driver, and I got a little more so when I saw it boot-looping : it never got past the PBL stage. Later I remembered that it never gets past PBL stage unless a battery is connected. But I was spooked enough so I carefully put everything back together, and felt much better when everything booted up and worked fine, with no unsightly cracks or left-over parts.

There are still a few things left to check (watch OM bits with pull-up applied to test points, watch OM bits with variety of resistors applied to pins 4&5), but I'm feeling like we're running out of options for reaching our original goal of accessing the iROM UART mode.

So far, the only avenue that should work (still not tested) is by corrupting the IBL causing the iROM code to fail-over to UART. But if a phone is bricked already, I don't see how it would be possible to modify the IPL.
[Hardware Hacking General] AdamOutler:
Why not force that pin high? I have a brick here... what would be the required logic level?
[Hardware Hacking General] AdamOutler:
Here's a picture of mine... I believe it's the one to the left
[Hardware Hacking General] kngthdn:
js22, midas5,

Thanks for the replies and suggestions. I'm actually mailing the phone to Adam so he can see if it's outputting any meaningful messages, etc., which is practical since I'm also here in the US. The jig I have definitely doesn't help as-is, unfortunately... even following the instructions in the post above. I don't think anything I flashed is actually corrupted, the bootloaders just don't coexist well. (It looks like at least 4 or 5 other people over on the Continuum thread have made the same mistake as I did; now there's a large warning in the OP.)

Also, Adam,

Sorry I haven't sent the phone yet! I'll try to send it tomorrow morning. Apparently FedEx doesn't do return labels, so I'm just going to stick a pre-addressed USPS envelope with postage already on it in with the phone. I'll PM you with the tracking # once it's shipped. :)
[Hardware Hacking General] js22:
The pin that needs to be forced high (OM5) is on the underside of the CPU. Impossible to get at there. We had hoped it was connected to the FSA9480 chip (that would be soooo sensible) but its looking like it is not.
[Hardware Hacking General] AdamOutler:
This is a link to the Samsung S5PC110 processor data sheet. I'm pretty sure this is ours. Anyways.. check this link out

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

Page 464 has some good reading for anyone interested...

6.1 OVERVIEW OF BOOTING SEQUENCE
S5PC110 consists of 64KB ROM and 96KB SRAM as internal memory. For booting, internal 64KB ROM and
internal 96KB SRAM regions can be used. S5PC110 boots from internal ROM to enable secure booting, which
ensures that the image cannot be altered by unauthorized users. To select secure booting or normal booting,
S5PC110 should use e-fuse information. This information cannot be altered after being programmed.
The booting device can be chosen from following list:
• General NAND Flash memory
• OneNAND memory
• SD/ MMC memory (such as MoviNAND and iNAND)
• eMMC memory
• eSSD memory
• UART and USB devices
At system reset, the program counter starts from the iROM codes in internal ROM region. However, the system
reset may be asserted not only on booting time, but also on wakeup from low power modes. Therefore, the iROM
code must execute appropriate process according to the reset status (refer to Table 6-1).

he boot loader is largely composed of iROM, first and second boot loaders. The characteristics of these boot
loaders are:
• iROM code: Contains small and simple code, which is platform-independent and stored in internal memory
• First boot loader: Contains small and simple code, which is platform-independent and stored in external
memory device. Related to secure booting.
• Second boot loader: Contains complex code, which is platform-specific and stored in external memory device.

This is some good information!
[Hardware Hacking General] AdamOutler:
So, I've determined that this phone has a bad secondary bootloader and/or param.lfs. I need to somehow toast the secondary bootloader to make the MMC an option to the processor.

Any ideas on how to get access to the file or wipe the internal SD? All I can see is primary bootloader over UART
[Hardware Hacking General] AdamOutler:
page 833 outlines parameters for i2c which we need to check out.

• Four channel Multi-Master, Slave I2C BUS interfaces
(one channel for general purpose, one channel for PMIC, two channel for HDMI dedicated)
• 7-bit addressing mode
• Serial, 8-bit oriented, and bidirectional data transfer
• Supports up to 100kbit/s in the Standard mode
• Supports up to 400kbit/s in the Fast mode.
• Supports master transmit, master receive, slave transmit and slave receive operation
• Supports interrupt or polling events.
[Hardware Hacking General] AdamOutler:
I don't think we want to touch the IBL. Even the riff jtag does not write to that block of memory. I've got some boards on order which will allow me to jtag with ease. I can play around with my phone quite a bit easier after that.

Btw... that captivate reset hole is not a reset. Its the back of the headphone jack connector... if you're talking about the hole between the camera and the sim card.
[Hardware Hacking General] js22:
I'm not saying it's a very appealing option, but the only one we know of that gets us into the UART download mode of the iROM.
[Hardware Hacking General] TheBeano:
With the default settings on the OM pins the CPU will only try to boot off the MMC if the IBL is not loading or has a bad checksum. If the IBL is OK the CPU will launch that, and the IBL will then load the PBL and chain to it.

If you just toast the SBL (partition or checksum), the PBL will still load and will just give up on loading the SBL.

Currently the only way to change the bootloaders if the phone is already bricked is to use JTAG, and if you have that you might as well just reflash everything anyway.