yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] midas5:
I though that we were not interested in the sbl. But here there might be a point. Say if a phone has been flashed with a wrong bootloader. It might fail to work with usb but might still work with sdcard if the sdcard is the same on both models but the usb driver is different.
[Hardware Hacking General] AdamOutler:
If we could get an SBL onto the SDCard and somehow make the phone boot from it, then we'd have a chance. Most of the bricks I've seen will stop at the PBL and never even enter the SBL. I'm not sure what is going on at that point, but we don't see any output from the SBL. It may be that it's on a wrong partition or the PBL set up wrong values that the SBL attempts to access and it results in a freeze. I don't know...

However, if we can find a way to boot an SBL from the drive without accessing download mode, then we'd be good to go...

Any chance you can figure out what those folders are supposed to be called? I'm not good at C, but I can muddle my way through it.
[Hardware Hacking General] midas5:
From what I can see, the PBL can only load from onenand.

Can you post the serial text during boot up for:

1) A successful boot

2) One where only the PBL loads.

I can then maybe see where in the source code the PBL is failing.
[Hardware Hacking General] AdamOutler:
I thought I should add this is another thing for a PBL/SBL mismatch condition which was just reported today...

So, that pretty much sums up what we know about external aspects.
[Hardware Hacking General] midas5:
I would like to see the USB IDs of the "Unrecognised device"

If the computer is seeing a USB device, we might be able to recover this.
[Hardware Hacking General] midas5:
The brick "code" segments in your last post are missing.
[Hardware Hacking General] AdamOutler:
nope... that's it. nothing at all. not until hard reboot triggered by keypress.

You should PM that member I mentioned for the information... I was not able to get anything off this device. I was able to get it to reboot and watch the USB data... it was an invalid response, just some garbage sent across the USB. I use linux, not windows though. You should PM him. manojsuper
[Hardware Hacking General] AdamOutler:
I hard bricked my phone today... I flashed bootloaders without specifying repartition. The source was my other phone. I dd'd the data from one phone into heimdall. to my other phone.

It has NOTHING for UART output. nothing at all. However, oddly, it's making a USB connection.. I can see this:

SEC S5PC110 Test B/D

and this as another message

System MCU

however, it will not enumerate as a device on USB.

[120909.127380] usb 1-1.5: new high speed USB device using ehci_hcd and address 40
[120938.612342] usb 1-1.5: USB disconnect, address 40

Any ideas?
[Hardware Hacking General] jutezak:
It seems to be in a certain state for (nearly) 30 seconds, and then gives up. But why and what? Would it do anything different in Windows, it being a low level USB stack that is probably not tested against Linux?

More likely it doesn't support enumeration (as that seems a fairly complex protocol) but just expects talking to a certain address/endpoint. Fair enough for an initial system load function (special Samsung driver and tool required).
[Hardware Hacking General] midas5:
The "SEC S5PC110 Test B/D" is the IROM trying to boot from serial/usb.

It will try for a short time during boot then give up.

You cannot dd the PBL/SBL from another phone. It will not work.

The boot.bin and sbl.bin are not in the same format as a dd image.

All that is needed is us to understand the usb protocol for the Test B/D mode and you would be able to recover that phone.

It basically loads something from the USB into RAM and runs it.

It would be nice to get to a stage where we can get something running in RAM that would let us read and write to any location in the onenand.

We could then use that to recover from this Test B/D mode.
[Hardware Hacking General] juicyhusk:
Please take a look at my thread I started but have had no interest with yet:

http://xdaforums.com/showthread.php?p=15912120#post15912120

I just uploaded pictures of my internal phone chips, etc AND my sim card writer which has a usb to serial communications

I'm sure I can put together by soldering parts together, and if sucessful, I'll pay the shipping to send to someone else in need, or someone that can help me, with the idea maybe instead of buying a $100+ box, we can ship to each other in need of a cheap, but workable device, I'll gladly pay for shipping to the first 10 ppl we can help
[Hardware Hacking General] AdamOutler:
I've got a spare captivate mainboard here... ima tear it apart to locate OM5.... Wait for this and it may help you.
[Hardware Hacking General] juicyhusk:
Yes I can't wait to see what the outcome is.
[Hardware Hacking General] AdamOutler:
This processor is branded Apple A4!!!

Just kidding

W5J
N2G6CC
[Hardware Hacking General] AdamOutler:
I popped off the XOM resistor and I was not able to find any change...

Then I hooked the bricked device to my bus pirate.



[/code]

[/code]

You can't see it, but that's a ton of 10's and at the end there's 3 0A's.... is this what we're looking for?
[Hardware Hacking General] midas5:
Which resistor did you boot up with?

Was is the boot-uart or boot-usb

You could try the boot-usb one and see if any USB IDs appear.

How certain are you that you got the correct resistor for OM5 ?

Is this output from the usb port or is it output from the jtag uart ?

Is this output from the bricked phone that has never worked, or is it the output from a phone that did work, and all you did was remove the resistor?
[Hardware Hacking General] AdamOutler:
1. That was a 619k resistor

2. UART

3. Will do.

4. As long as the S5PC110 chip's datasheet was accurate, and was describing the chip and not the circuit board which the chip attaches to... That pin is in fact AA-2, which is the signal named xOM5.

5. USB Port.

6. I now have two bricks... This is the bootloader mismatch brick. I bricked my dev phone by uploading a bad(dd'ed) PBL and SBL... My dev phone does nothing and I have not tried it yet.

I have a RIFF JTAG box inbound. I'll be able to get the OM value from the PBL as soon as it arrives.
[Hardware Hacking General] midas5:
The bootloader mismatch brick is a brick that I think still needs JTAG or OM5 changing.

The dd'ed PBL should be recoverable via the USB as it is now in IROM download mode as proved by the "SEC S5PC110 Test B/D" message.

Someone just needs to write some software that the IROM understands that will let us write to flash the new PBL and SBL.

For example, getting from the IROM to LOKE mode would do it.

The IROM download works like this:

1) Download some code from the PC via USB to the phone.

2) IROM executes the code from RAM.

I think there was some code posted to this forum earlier that could work with the IROM download mode. I think it was some samsung test board software.
[Hardware Hacking General] AdamOutler:
wasn't the xOM5 supposed to change the boot order completely? I can't read the processor manual because I'm at work. It's in there though under the boot section. I included it in the All-in-One GalaxyS Hack Pack. http://xdaforums.com/showthread.php?t=1111866

I posted that software in the All-In-One GalaxyS Hack Pack

http://xdaforums.com/showthread.php?t=1111866

I tried to use the UART download mode, but I could not activate the AA value nor could I manage to make it respond to anything. I don't know enough to do it I guess.
[Hardware Hacking General] midas5:
I think that is the correct output for IROM serial download/boot. I would have to check though. Have you tried pressing/sending "CR/LF" (0xa, or 0xd) when seeing this?
[Hardware Hacking General] midas5:
I have looked closer at the IROM.

That output is wrong.

You should be seeing text along the lines of "Failed to load from OneNand", "Failed to load from MMC".

before it starts trying to boot over serial.
[Hardware Hacking General] midas5:
The above it wrong. I was looking at the wrong path through the code.

The above is correct for OM=9.

As you have changed the OM state, making OM5=1, OM should = 0x29 now.

I will trace that path through the IROM when I get a moment.
[Hardware Hacking General] AdamOutler:
My copy-pasta may be wrong as well. I think it's possible that the bus pirate was not able to supply the proper amperage and the device was resetting continuously causing that first funny character to appear then resetting before the "1" appears... dunno... However, I'm hoping this RIFF box shows up soon so I can verify XOM5...

Can you verify that XOM5 WILL in fact change the OM=0x9? That's my main question right now... If OM=0x9 is hard coded to say 0x9 then I would never be able to confirm that the OM value was changed.
[Hardware Hacking General] midas5:
I think your riff box will tell us that. You should be able to read the OM register with the riff box.

The Samsung chip manual says XOM5 should affect the OM value.

Something I would like to know is if changing the XOM5 value after boot up, causes the OM register to change.
[Hardware Hacking General] midas5:
I looked at some of the IROM code.

Following the OM5 path.

It does not appear to go into download mode unless the unit is reset using the "XnRESET" pin.

I.e. Bit 0 of e010a000 has to be set.

A "WARM" reset will not set that bit.

It might be set from power off. i.e. No battery to plug in battery, but the chip manual does not imply that.

If the Bit 0 is not set, even with OM5 set, it will attempt other things like onenand etc.
[Hardware Hacking General] midas5:
I have just tested.

A normal COLD boot sets bit 1. I.e. Remove battery, Insert battery and then boot.

bit 1 is cleared as soon as the phone tries a normal idle sleep (i.e. screen blanks after period of non-use)
[Hardware Hacking General] midas5:
The IROM looks that is should be quiet, and just sit for a timed period (not sure how long yet) waiting for a 0xAA input on serial port 2. I have not diagnosed the code fully yet, there might be a timeout waiting for 0xAA, and then it outputs a char, then goes into the timeout waiting for 0xAA again.

Not sure of the baud rate yet either.

MOV R1, #0x23 ; '#' ; #35 ; Baud rate divisor

With your other brick, with the onenand failing but OM5 not set, you should be seeing IROM messages saying things like "OneNand failed checksum" etc.

That message is at the same Baud rate as 0x23 here.

Do you see any messages ?

It would be useful to see the COM port output on the onenand corrupted brick. Can you post it here?
[Hardware Hacking General] midas5:
For serial bootloader.

1) Remove battery. (Ensures the XnRESET is set correctly)

2) Insert battery. (Ensures the XnRESET is set correctly)

3) Switch on phone. (with OM5 set)

4) You should get 0xAA byte sent from the phone to the PC.

5) Reply with 0xAA byte sent from PC to phone.

6) Phone should respond with sending a 0xCC from phone to PC.

7) Reply with a 0xCC byte sent from the PC to the phone.

8) Download can begin.

It uses COM2.

Not sure of the baud rate yet either.

MOV R1, #0x23 ; '#' ; #35 ; Baud rate divisor

With your other brick, with the onenand failing but OM5 not set, you should be seeing IROM messages saying things like "OneNand failed checksum" etc.

That message is at the same Baud rate as 0x23 here.

Do you see any messages ?

It would be useful to see the COM port output on the onenand corrupted brick. Can you post it here?
[Hardware Hacking General] AdamOutler:
^^ This may explain the funny characters at boot on the PBL/SBL mismatch with hard reset? Could be saying something at the wrong baud rate. I don't know. The improper PBL brick does not say any such thing.

I've been busy with Heimdall One-Click lately.. http://xdaforums.com/showthread.php?t=1191924 The idea is to remove as much operator error as possible making for a safer flash. As soon as I get the RIFF JTAG box, i'll be back on trying to revive bricks.

The baud rate would be most helpful. I will see if I can hit it with my logic analyzer to see if it looks like any recognizable data.
[Hardware Hacking General] AdamOutler:
Midas, what do you make of this?

/*
* EXT_UCLK0 = external clock. (XpwmECLK PAD input)
* EXT_UCLK1 = generated clock by SYSCON.
*
* Here, UART Clock Source = EXT_UCLK1 (= 66.5Mhz)
*/
__REG_UART(UCON_OFFSET) = 0xe45;
__REG_UART(UBRDIV_OFFSET) = 0x23;
__REG_UART(UDIVSLOT_OFFSET) = 0x0080;

/* Clock Setting. */
/* Input clock = 133 MHz assumed. so UART clock = 66.5 MHz (133/22= 66.5). */
*(volatile u32 *)(0x7e00f028) &= ~0x70000;
*(volatile u32 *)(0x7e00f028) |= 0x10000;
#ifdef CONFIG_SEC_LOG_BUF
sec_log_buf_init();

66.5mhz seems quite high and I have nothing which can communicate at that frequency.
[Hardware Hacking General] midas5:
I will look into it.

The clock to baud rate conversion is actually quite complicated. The actual clock rate varies depending on platform. So i think i will have to work it out by comparing how the PBL sets it up to the IROM.

What rate is the PBL output?
[Hardware Hacking General] xpcomputers:
It says:

133/22...

And surely that wouldn't be 66.5Mhz!

If it really is divide by twenty-two, then you are looking at more like 6Mhz give or take a bit...

That it only based on what is written, don't have a clue whether that its the right value.

Mike

Garbled meaning induced by swype when posting from XDA app on SGS I9000. ;)
[Hardware Hacking General] midas5:
The clock rate calculation is like this.

baud = CLK / ((16*(UBRDIV+1)) + (number of 1s in UDIVSLOT))

So, in your case:

UBRDIV = 35, number of 1s in UDIVSLOT = 1

baud = CLK / 577

If the CLK was 66 Mhz. (I don't know what the right CLK answer is)

baud = 66 470 000 / 577 = 115199

The CLK can be any of:

XXTI

XusbXTI

SCLK_HDMI27M

SCLK_USBPHY0

SCLK_USBPHY1

SCLK_HDMIPHY

SCLK_MPLL

SCLK_EPLL

SCLK_VPLL

(The above are the SCLK)

PCLK

UCON reg decides on which clock to use.

So, in your example, it is using SCLK.

I think the IROM using PCLK.

Being that I don't know what the actual SCLK and PCLK is in the phone, it might be difficult to tell the actual BAUD rate.

In the next day or so I will find out what the UBRDIV, UDIVSLOT, UCON settings are for the IROM and IBL/PBL/SBL. Hopefully they will compare and give us a setting for the PCLK and SCLK.
[Hardware Hacking General] Rebellos:
Bricked my S8530 also during bada secdata experiments last days. Sadly it is loading IBL and BL3 (SBL) is bricked and I probably damaged JTAG pads :eek:

Gotta play little more with these pads, if it doesnt work... OM resistors welcome :\
[Hardware Hacking General] midas5:
I don't think we have a way out of that yet.

Broken IBL should, in theory, have a way to recover.

But not a working IBL and broken SBL.
[Hardware Hacking General] AdamOutler:
I have a couple of idle questions..... an X in front of a signal name, is that active low? What is that? Im seeing that alot.

Also, SCLK, means System Clock right? So PCLK may mean processor clock? Like a multiplier on an x86 arch processor?
[Hardware Hacking General] AdamOutler:
I just jtagged my first phone. It was the bootloader mismatch. I will work on my dev phone tomorrow. This was the one where I had removed the xOM5 resistor. This did not change OM9 value....

1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------

+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).

Set cpu clk. from 400MHz to 800MHz.
OM=0x9, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.

I suspect that xOM5 may be an active low signal, so Possibly bringing ground from another source may do the trick... However, I'd like confirmation that xOM5 sounds like it would possibly be an active low signal.

Each of the OM signals are labeled x0M* on the S5PC110 chip. I noticed several signal lines labeled XOM on the S5PC110. Removing the "xOM5" resistor did not change the signal. Therefore, there's a few possibilities...

1. Somehow the processor rotated on me and I lost orientation of the xOM5 pin.

2. The schematics are wrong.

3. The signal is an active low and the resistor was providing 5V to the processor.

Chime in... I'm up for suggestions.
[Hardware Hacking General] AdamOutler:
The device operated well for a while, and suddenly it started tweaking out...

here's the end of the uart log....

eypad_scan: key value ----------------->= 0x0
CONFIG_ARIES_REV:48 , CONFIG_ARIES_REV03:48
check_download: micorusb_status1 = 800, key_value = 0
aries_process_platform: final s1 booting mode = 3
AST_UPLOAD..
RST_STAT = 0x2
display_aries_upload_image: upload code = 0x20000000
DISPLAY_PATH_SEL[MDNIE 0x1]is on
MDNIE setting Init start!!
vsync interrupt is off
video interrupt is off
[fb0] turn on
MDNIE setting Init end!!

Modem Booting retry ...10
DRV_modem_reset!!!!!!!!!!!!!!!!!
..................................................done
Modem read success from modem partition.

[DRV_Get_Boot_Bin] : Modem Base Addr 0x831cdc000
===================================
Modem Boot first 16 bytes
0x46 0x e 0x 0 0xea 0x6c 0x69 0x48 0x55 0x 1 0xa0 0xfe 0xfd 0x 7 0x 0 0x 1 0x 0
===================================
DRV_Get_Boot_Bin: completed!
1

Here's a picture of the screen.

I replaced the xOM5 resistor and there was no change in this behavior...

This leads me to believe that the device may have had a power issue while it was being flashed which caused it to reset mid-flash and become inoperative... this would also explain the randomness I encountered trying to get it to turn on for flashing.
[Hardware Hacking General] midas5:
In digital electronics design, even if an input, when not connected, defaults to a value of say 1. It is sensible to add a resistor to tie it to 1 in order to prevent unwanted noise reception.

So, with or without the current resistor might still cause OM5 to be zero.

You might need to link with another resistor the OM5 pin to a different point.

The OM5 input is unlikely to be a 0 to 5V input. It might be something like 0V to 1V input range.

So, I would try to place a volt meter between GND and on either end of the OM5 resistor and see what the voltage is, and if there is a different between each end of the resistor.

Tell me what the volt values are.

For example, If the input floats and defaults to 5V. Adding a resistor to connect the input to 5V will not make a lot of difference whether the OM5 resistor is connected or not. But connecting that input via a different resistor to 0V will cause the input to change.

The datasheet gives us no idea of what the High/Low voltages should be on the OM5 pin.
[Hardware Hacking General] midas5:
From my examination of the IROM and IBL/PBL/SBL code.

The IROM uses the SCLK.

The IBL/PBL/SBL uses the SCLK.

IROM:

baud = SCLK / 579

IBL/PBL/SBL:

baud = SCLK / 577

Summary, both use pretty much 115200 BAUD, but the clock rate gets changed slightly between IROM and IBL so might cause a glitch or two at the transition point.
[Hardware Hacking General] midas5:
Yes. Worth a try.
[Hardware Hacking General] Zillaaah:
I am totally new to this forum so excuses if i post this in the wrong forum.

Recently i came across the two linked below, which contains a link towards repair manual/schematics for the galaxy s. It looks quite interesting.

www[dot]cpkb[dot]org/wiki/Samsung_GT-I9000_Galaxy_S_service_manual

www[dot]filesonic[dot]com/file/305248751/Samsung_GT-i9000_Galaxy_S_service_manual.rar

I am a new user so i cant post links in the normal way.
[Hardware Hacking General] AdamOutler:
We have that in The All-In-One GalaxyS Hack Pack. http://xdaforums.com/showthread.php?t=1111866
[Hardware Hacking General] Zillaaah:
I was totally unaware of that :(
[Hardware Hacking General] TheBeano:
The smdkc110_cpu_bd_pop_c_sch_rev01 development board schematic shows the OM pins connected to 100K pulldown resistors and a DIP switch that switches the pins to VDD_SYS, which is 3.0V.

In the photo you can see the XOM0 and XOM3 resistors are connected to a common bus which is probably VDD_SYS, which makes sense for OM=9, and the other resistors are pulled down to what looks like ground. You could check this with a voltmeter. So you should be able to connect the non-grounded side of the OM5 resistor to the same point as the common ends of the XOM0 and XOM3 resistors, directly if you're feeling lucky or via the same resistor value if you want to play it safe.
[Hardware Hacking General] AdamOutler:
I've got pretty high confidence about a connection between the active side of xOM0 resistor to the xOM5 signal. Everything seems to match up to the way it was expected to be. here's my worksheet.

If all goes well we can use the [/thread] tag soon enough.:-)
[Hardware Hacking General] AdamOutler:
1
-----------------------------------------------------------
Samsung Primitive Bootloader (PBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
-----------------------------------------------------------

+n1stVPN 2688
+nPgsPerBlk 64
PBL found bootable SBL: Partition(3).

Set cpu clk. from 400MHz to 800MHz.
OM=0x29, device=OnenandMux(Audi)
IROM e-fused - Non Secure Boot Version.

-----------------------------------------------------------
[Hardware Hacking General] AdamOutler:
so um... now that we have OM=29, what firmware do we run?
[Hardware Hacking General] AdamOutler:
I hereby dub this "UnBrickable Mod" aka OM5-Mod.

I'm working on firmware now.
[Hardware Hacking General] bird333:
Congrats! But that mod looks scary. Are there any alternatives?
[Hardware Hacking General] AdamOutler:
Heimdall, odin, JTAG.
[Hardware Hacking General] midas5:
beautiful !
[Hardware Hacking General] midas5:
From a cold boot, do you see any 0xAA ?
[Hardware Hacking General] bird333:
So I guess you are saying it is impossible to get into this state without doing your mod? Well, I thought I read that Samsung could repair bricks without opening the phone. I guess your discovery doesn't lead to a way to do this without opening the phone?
[Hardware Hacking General] AdamOutler:
Yes. This modifies the boot sequence of the processor. This occurs long before anything like software/firmware even enters the processor memory. This is why i have deemed it UnBrickable Mod. Once we figure out how to communicate with it, the device can be loaded with any instructions....

Were talking iOS or WP7 or even just reviving a dead device. This will even allow resurrection when JTAG has failed. its simpler to set up then JTAG with only 1 wire, and costs practically nothing... A piece of wire from a junked relay or something, a sharp soldering iron, a computer and an external sdcard..... You can likely scrounge this stuff up around the house.

We just need the software component.

My own dev phone was subject to so much abuse while playing with the JTAG UART lines that it cannot be JTAGged anymore. Its missing the TDO, NRST and GND pins. So, I will apply the mod tomorrow and attempt to work with it.
[Hardware Hacking General] AdamOutler:
Not on this properly operating device. Maybe I'll see something on my device.. It's got junk for a PBL and SBL.

I will tell you though, normally without a battery, the PBL practically non-stop tries to boot. With this mod, it takes about 5 seconds between boot attempts. This suggests it may be trying other things. I tried to DD a PBL to the sdcard with no affect. I don't know what format the files should be in to boot from SDCard...

This may be in the IBL??
[Hardware Hacking General] bird333:
Well with clear instructions on taking the phone apart and performing this mod, I may just do this. I am typically a believer in having a recovery method before 'playing' but it seems in the world of phone ROMs it's hard to have that philosophy. :) Congrats again. I look forward to your software side of things.