yashsingh1/xdaforums huggingface dataset:
[Hardware Hacking General] AdamOutler:
No. that was just to prove that the information was only being transmitted on D+ and D-.... I'm running primary and redundant power and grounds now from two different areas of the Arduino board.

You're talking about 0x31.... that is NOT what I am seeing. that is what is represented when it is copied and pasted into this window. Like I said, in my linux terminal window it's not a "1", it's a funky 1/2 japaneese 1/2 hex character.

I'll try to write some smarter interperater code tonight. I guess I need certain input to trigger certain events.
[Hardware Hacking General] js22:
As for the idea of intentionally invalidating the IBL/PBL, that is indeed very "courageous". I'm very curious what we would see on the UART output. It would be a big step forward that might eventually lead to a true un-bricking solution. But for now there are only two known fixes for a phone in that condition : 1) pay Samsung or someone else lots of money, or 2) spend $150 on a Riff box _and_ perform some crazy super-human soldering.
[Hardware Hacking General] midas5:
Can you capture the whole output in raw format, and then do a hexdump on the funky 1

My guess is it is two chars on top of each other.
[Hardware Hacking General] AdamOutler:
the extremely high baud rate did not allow any data capture.

10 31 A D | |
1 +-----------------------------+
2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D A D
-----------------------------------------------------------
20 20 20 53 61 6D 73 75 6E 67 20 50 72 69 6D 69 74 69 76 65 20 42 6F 6F 74 6C 6F 61 64 65 72 20 28 50 42 4C 29 20 76 33 2E 30 A D
Samsung Primitive Bootloader (PBL) v3.0
20 20 20 43 6F 70 79 72 69 67 68 74 20 28 43 29 20 53 61 6D 73 75 6E 67 20 45 6C 65 63 74 72 6F 6E 69 63 73 20 43 6F 2E 2C 20 4C 74 64 2E 20 32 30 30 2D A 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D A 2B 6E 31 73 74 56 50 4E 20 20 20 20 20 2
Copyright (C) Samsung Electronics Co., Ltd. 200-
----------
+n1stVPN 2688
2B 6E 50 67 73 50 65 72 42 6C 6B 20 20 20 20 36 34 20 A D
+nPgsPerBlk 64
50 42 4C 20 66 6F 75 6E 64 20 62 6F 6F 74 61 62 6C 65 20 53 42 4C 3A 20 50 61 72 74 69 74 69 6F 6E 28 33 29 2E A D
PBL found bootable SBL: Partition(3).
10 31 A D
1
2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D A D
-----------------------------------------------------------
20 20 20 53 61 6D 73 75 6E 67 20 50 72 69 6D 69 74 69 76 65 20 42 6F 6F 74 6C 6F 61 64 65 72 20 28 50 42 4C 29 20 76 33 2E 30 A D
Samsung Primitive Bootloader (PBL) v3.0
20 20 20 43 6F 70 79 72 69 67 68 74 20 28 43 29 20 53 61 6D 73 75 6E 67 20 45 6C 65 63 74 72 6F 6E 69 63 73 20 43 6F 2E 2C 20 4C 74 64 2E 20 32 30 30 2D A 2D 2D 2D 2D 2D 2D 2D 2D 2D 2D A 2B 6E 31 73 74 56 50 4E 20 20 20 20 20 2
Copyright (C) Samsung Electronics Co., Ltd. 200-
----------
+n1stVPN 2688
2B 6E 50 67 73 50 65 72 42 6C 6B 20 20 20 20 36 34 20 A D
+nPgsPerBlk 64
50 42 4C 20 66 6F 75 6E 64 20 62 6F 6F 74 61 62 6C 65 20 53 42 4C 3A 20 50 61 72 74 69 74 69 6F 6E 28 33 29 2E A D
PBL found bootable SBL: Partition(3).
[Hardware Hacking General] js22:
Doesn't seem screwy, just a "busy" output format.

The non-indented lines are hexadecimal values (without the leading "0x" familiar to C programmers). The indented lines are what those values would look like (if they are printable).

The very first line contains the values 0x10 and 0x31. It looks like minicom responds to the (non-printable) char 0x10 by printing a little "hey this is binary" icon, a box with tiny little 0's and 1's in it. Very cute. Note that the box is twice as wide as a normal character. If you stare very closely at the box as it is printed on your screen, you will notice that the right-hand half contains a normal-sized digit '1' sloppily superimposed on top of it. That is actually the second byte, 0x31, the ASCII value for the character '1'. When you cut and paste, the '1', is not dumped on top of the icon, but after it.

The next two values on the first line, 0x0A and 0x0D are ASCII for carriage return and line feed ('\r' and '\n') respectively. Although they're not visible on the screen, they just make sure that any text that follows starts on a fresh line. (whether on a real computer or not :p).

Anyway, going through the printout , its easy to see that 0x20 = space, 0x2D='-', etc.
[Hardware Hacking General] js22:
I did a little mucking around today. No breakthoughs, but I learned a little more.

I used a digital scope and watched the UART line coming from the phone.

With battery removed, I set the scope to trigger in single mode ; i.e., stop as soon as you see one event. Apart from glitches (fixed w/ a 10k pull up or down resistor), I always see a single solitary 0x10 as the first byte.

If I continue acquiring single triggers (i.e., without un/re-plugging phone) I either see the solitary 0x10, a solitary 0x31, or a huge chunk of text. All of the chunks I was able to catch and decipher began with 0x2D (the '-' character), but when I continued to parse the bits manually, I seemed to get something else for the following bytes. (I don't understand this, it should just be a series of 0x2D.)

My scope is able to capture data at a high sampling rate and let you "zoom in" to the waveform after the event has been acquired, but not infinitely. The time between the 0x10, the 0x31, and the other chunks of text are long enough that i wasn't able to measure them very well. Suffice it to say that they are "very far apart".

The 0x10 and 0x31 are gold-plated, 8N1 serial bytes with perfect bit timing at 115200kbps; they are very clearly not some kind of "garbage" picked up due to incorrect UART settings.

So the big (disappointing) news is that there do not appear to be any secret missing bytes at some other baud rate or polarity or what-not. A solitary 0xAA byte does not appear anywhere. (It shouldn't, until we can figure out a way to set the OM5 bit, but a guy can hope....)

The other thing I did was take a teensy stab at disassembling the boot.bin file. (aka "IPL+PBL"). I don't have any respectable tools, just GNU binutils and that perl script I mentioned on the first or second page of this thread. Although the iROM code disassembled pretty nicely (data regions diassembled into garbage, but subsequent code regions were aligned correctly), this code wasn't nearly as cooperative. I ended up with lots of garbage code that I could see was mis-aligned.

I didn't have any big plans for figuring out the IPL+PBL code, but I was curious to see if it is printing the 0x10 and 0x31 characters to the UART. TheBeano, are you able to diassemble that code ?
[Hardware Hacking General] AdamOutler:
^^That was my formatting btw... I wrote that into my Arduino.

if (Serial1.available()) {
int inByte = Serial1.read();
Serial.print(inByte, HEX);
Serial.print("|");
Message= Message + " |" + (char)inByte;
if ( inByte == 13 ){
Serial.println("");
Serial.print(Message);
Message="";
}
}

What I meant was it seems like some of the bytes were not what they should be. Like there was corruption or something. I can't figure out why this was in here when I never saw it when strictly passing serial 1 to serial 0

|0 |o |d |e | |� |� |� |m |o |d |e� |� |ѥ |� |� |� |m |o |d� |ѥ |� |� |� |m | |�

That's some corrupted data. Also, the secondary bootloader section was missing.

Let me know if I can do anything to help out... I just got done soldering a header on my JTAG port. Tomorrow I'm going to get the plug worked out. Then I'm going to try to figure out a way to JTAG with my Arduino...

Even if I can't Arduino JTAG, I'm hoping that Connexion2005 will help me out and JTAG with his riff box.

So, other then a few more hours of prep work, I am almost ready to replace the PBL with a LOLcat.jpg. Does anyone have any more suggestions?
[Hardware Hacking General] TheBeano:
Well the 0x31 ("1") is coming from the IBL, it sends it just after it has loaded the PBL from NAND and just before it chains to the PBL:

RAM:D002288C LDR R0, =ULCON2 ; UART Channel 2 Line Control Register
RAM:D0022890 LDR R1, a1111 ; "1111"
RAM:D0022894 STR R1, [R0,#0x20] ; Transmit to UART2
RAM:D0022898 LDR R7, =0x40204000 ; PBL load address
RAM:D002289C BX R7

By the way the uBoot source is massively helpful for understanding the Samsung code, especially:

board\samsung\aries\lowlevel_init.S

uart_asm_init: confirms that the baud rate in the ROM and the IBL is set to 115200

cpu\s5pc11x\start.S

shows board setup and boot type selection from OM register (MMCSD but not UART boot)
[Hardware Hacking General] TheBeano:
Yes, don't do it! :) Rather than overwrite the PBL, which as midas points out doesn't change the IBL, I would try to corrupt the IBL, so that the ROM refuses to load it because its checksum is invalid. If you just flash a bad PBL the ROM and the IBL may quite happily load and chain to it and it will crash.

I must stress there is still not much point to this until we know whether we can get the ROM download mode triggered externally.
[Hardware Hacking General] AdamOutler:
^^ Wait.. I thought we established that if the primary boot loader was damaged then the unit would boot from a MMC.... What is the equivalent of a bootloader panic? Check that section. It's likely that most bricks come from a primary or secondary bootloader that was corrupted during Odin3. My black screen brick finished the entire Odin3 1-click and then never started back up. That's the brick I'm trying to recover.
[Hardware Hacking General] TheBeano:
Now that I understand about the IBL, I think the only part the ROM takes a checksum of is the IBL. I will have to go back over the ROM disassembly to check. Of course most people will have a damaged or invalid PBL or SBL rather than IBL, so the ROM download mode will never kick in unless it is forced.
[Hardware Hacking General] midas5:
Adam,

What uart output does your blank screen brick output?

It is good progress that we now know that the 0x31 is coming from the IBL and not the irom.
[Hardware Hacking General] AdamOutler:
My phone is not bricked yet.

Im working on the hardware portion of JTAG before I start on the software. Once I have a good plug-n-play jtag then I will brick the heck out of this phone. Im working with these small 0.1 mm pins now and using a 50" tv with a video camera zoomed In to about 20x magnification like a microscope working on this plug for my jtag port in the picture above. This will allow me to play around with no concequences.... although its not looking good and it may be a few more days if I need to order parts. :(.
[Hardware Hacking General] TheBeano:
Cool, while you have all this setup could you please see if you can find the FSA9480 (U301) on the board and see whether its pins are accessible?

The location is in the Troubleshooting section of the service manual which was linked to earlier in this thread, on PDF page 8-10. I'm not sure how different the US circuit boards are though. Ricthofen in the "Fun with resistors" thread said it wasn't marked with anything like "FSA9480".

The schematic says the BOOT pin is "E3", not sure where that would be on the package. In the schematic it has at least 27 pins which is more than the FSA9280, so the FSA9280 datasheet won't apply. There are also a couple of test points next to U301 on the service manual diagram page 8-10.

If you can get at the pin, you could also measure it to see if it actually is going high with some resistor values on the USB port, which would mean that the BOOT_MODE signal is going to the wrong place. One option to try to force external boot mode would be to use a pullup resistor to try to make the BOOT pin go high. Don't just short it high though!

An even more unlikely longshot is that one of the test points around the processor is connected to the OM5 pin. This is on the service manual page 8-8, the processor is UCP400.
[Hardware Hacking General] AdamOutler:
well, I've got to figure out something now.. I was testing out my jtag connection which I had glued to a piece of plexiglass. I pressed really hard and I guess the glue was not dried... When i pulled it up, it took the jtag and the pads with it. So, this phone can't get bricked as is... I've got to figure out something else....

judging by the name of the pins it's likely that chip has several rows of connections... like a processor on a computer. a would be the outer set of pins e would be the inner. I doubt it could be accessed.
[Hardware Hacking General] TheBeano:
Ouch! I guess the phone still works though? :(

I was hoping U301 might be in five rows with E being one of the outer rows, but that's probably wishful thinking! I did find this teardown of the Galaxy Tab that says it's a flip-chip package marked "PAHB8, N4".

I'm petrified of taking my phone apart because I'm so ham-fisted that I always break one of those little film connectors when I try to fix gadgets. I'll get hold of a Bus Blaster when Seeedstudio have them back in stock and give JTAG a try though, at least the I9000 JTAG points are a bit more usable.
[Hardware Hacking General] AdamOutler:
Yep. Phone still works. The only thing is that I cannot brick it as-is, but I've got another phone under warranty which has a bad "menu" LED, so I may end up sending that one back...

Anyways... here's the part numbers you will want for the header and socket to perform a JTAG.

header for the bottom: http://www.mouser.com/ProductDetail/Panasonic/AXT612124/?qs=2rFUEsTwVNwSdqVM5XnLHw==

receptical for the top :http://www.mouser.com/ProductDetail/Panasonic/AXT512124/?qs=2rFUEsTwVNy9TGVyeT43Dg==

I found a video camera helps out quite a bit to use as a microscope so you know if you've got good connections or not. I'm still trying to work out something for the receptical side of the connector... this failed because the substrate was made out of plexiglass

I thought i'd put it out there... For communications with the UART I'm using an Arduino ATmega1280 board. If anyone wants one they are $35 from here: http://www.bizoner.com/arduino-atmega1280-mega-board-with-usb-cable-and-9v-power-cable-p-180.html The bonus of buying this board over a dedicated uart is that you can repurpose it for other communications, electronics, or robotics projects later.

I'm looking for someone who can make me a board like this:

Can anyone help me out with this board? I need it as a backup to JTAG in case I absolutely destroy my phone.
[Hardware Hacking General] .Slane.:
Hi Adam, can this kind of piece be useful ? http://www.gsm-technology.com/index.php/en_US,details,id_pr,8048,menu_mode,categories.html
[Hardware Hacking General] AdamOutler:
No, I'm running a captivate. The JTAG port is only 2.5mm in size and the connector is so proprietary, I was only able to find 1 connector which worked out of 20 close matches I tested. The contacts are 0.2mm wide and there's 14 of them. .. It's so very small it's rediculous.
[Hardware Hacking General] Fuma:
is this the right layout for the i9000?

and i know its enough for riffbox.

Adam for the captivate ,these are the pins right ?

in general will a s5pc110 detailed spec would help? found one that i didnt have.

http://www.multiupload.com/MYB0XVSAVU

and this we already know right ? (it's from the s5pc110 manual)

(i'm still understanding this,so sorry for making stupid remarks or questions...)
[Hardware Hacking General] TheBeano:
Yes, it is in the service manual too (linked back up the thread). I also posted a link to a JTAG jig you can buy for the I9000 (but not the Captivate).

Yes that's the development board schematic, which is nice but not the same as the I9000 schematic.

If only the phone was like that, it would be easy. :) We have been looking at ways of getting the OM5 pin to go high in the phone, without much success so far. This is still a reasonable summary of the current status.
[Hardware Hacking General] AdamOutler:
dmesg output

150kohm resistor hooked up:

<4>[TSP] TA Detect!!!
<4>fsa9480_interrupt
<4>[FSA9480] FSA9480_ReadIntRegister
<6>ldo38_control : turn ON LDO3 and LDO8 (cur_stat=0, req=1)
<4>[otg_clock_enable] clk_enable(otg_clock) OK.
<4>[FSA9480] FSA9480_ProcessDevice (dev1 : 0x8, dev2 : 0x0)
<4>UART
<4>DmaAddr=@34560000 Total=32768bytes PrdSz=2048 #Prds=4, dmaEnd 0x34568000
<7>touch_led_control: 1
<4>xrun: occurred buffer xrun[0]

301K:

<4>[otg_clock_enable] clk_enable(otg_clock) OK.
<4>DmaAddr=@34560000 Total=32768bytes PrdSz=2048 #Prds=4, dmaEnd 0x34568000
<4>[FSA9480] FSA9480_ProcessDevice (dev1 : 0x0, dev2 : 0x1)
<4>JIG USB ON attach or detach: 1FSA9480_DEV_TY2_JIG_USB_ON --- ATTACH
<4>[FSA9480] usb_switch_mode: Path = PDA
<4>[FSA9480_Enable_AP_USB] Enable AP USB
<4>[ap_usb_power_on]AP USB Power ON, askon: 0, mtp : 0
<4>!!!!!!!!!!! [ap_usb_power_on]AP samsung_kies_mtp_mode_flag0, mtp:0
<4>xrun: occurred buffer xrun[0]
bash-4.1#

619k:

<4>[TSP] TA Detect!!!
<4>fsa9480_interrupt
<4>[FSA9480] FSA9480_ReadIntRegister
<7>touch_led_control: 1
<4>DmaAddr=@34560000 Total=32768bytes PrdSz=2048 #Prds=4, dmaEnd 0x34568000
<6>ldo38_control : turn ON LDO3 and LDO8 (cur_stat=0, req=1)
<4>[otg_clock_enable] clk_enable(otg_clock) OK.
<4>[FSA9480] FSA9480_ProcessDevice (dev1 : 0x0, dev2 : 0x4)
<4>FSA9480_DEV_TY2_JIG_UART_ON --- ATTACH
<6>set_dock_state : 0X2
<4>JIG UART ON
<4>xrun: occurred buffer xrun[0]

It took about 5 seconds for the 619k to turn "JIG UART ON".
[Hardware Hacking General] AdamOutler:
full dmesg output hooked to a 619k resistor. http://pastebin.com/30D55v86

Line 145 shows the familiar MNDIE Init line:D
[Hardware Hacking General] AdamOutler:
I just need a boot.bin now... I may have one which will work.... Dunno.

How are these files generated? We have about 10 on our phones and only 3 choices from this thing.
[Hardware Hacking General] TheBeano:
If you just dump your phone's bml1 partition it should already be in the right format with IBL and PBL loaded:

su

dd if=/dev/block/bml1 of=/sdcard/bml1.bin

This will give you a PBL which will then still try to load an SBL from NAND, but at least it's a proof of concept.
[Hardware Hacking General] AdamOutler:
^^ Will that work for a CRAMFS?

Here is the moviNAND fusing tool. It is actually not linked in this thread http://www.hotfilesearch.com/download/57491635-moviNAND.Fusing.Tool.exe.html

I am at work right now, so I'd like to just talk about this before I go home and try some actual work...

the moviNAND tool requires 3 items. Here's what is needed

1. bootloader

2. Kernel -got it.

3. ROM

1. The bootloader is questionable. Samsung splits the bootloader into 3 files. IBL, PBL and SBL. The bootloader is expected to be in a single file for the moviNAND tool

2. The kernel is expected to be in a zImage standard. I have a kernel squared away.

3. The ROM is expected to be in a CRAMFS file.

I tried to just load up #1 and #2 last night and it was not accepted. I belive moviNAND requires all 3 files to be present before it creates a filesystem. I need to make a CRAMFS.

I need help with #1 and #3

help me with bootloader...:: I need a boot.bin file which will work. I can pull my PBL and half-ass it, but I realy would like to get a working single boot.bin like uboot compiled for our phones.

Help me with ROM in CRAMFS...: All guides which I have found for CRAMFS involve compiling a CRAMFS kernel. I don't have the tools to do so because my compiler 30 day trial expired. If anyone can help me here, that would be awesome. Can i just use the mkcramfs tool to generate a file, then copy a working captivate /system/ into it?

The primary bootloader is going to be the more difficult part of this. If anyone can do some research to figure out how to make a single bootloader file, that would be great.

Another option to explore is that it is possible to write to memory locations from within moviNAND tool... If it is possible to do a memory dump from one memory location to another on the phone, it may be possible to create a moviNAND?

here's memory locations of different partitions... where would I need to start an image and what commands would I use to create an image?

1 blk = 40000 (256KB)

Partition Name START LEN

BOOT 00000000 0000 0003FFFF 0001
PIT 00040000 0001 0003FFFF 0001
EFS 00080000 0002 009FFFFF 0028
SBL 00A80000 002A 0013FFFF 0005
SBL2 00BC0000 002F 0013FFFF 0005
PARAM 00D00000 0034 004FFFFF 0014
KERNEL 01200000 0048 0077FFFF 001E
RECOVERY 01980000 0066 0077FFFF 001E
FACTORYFS 02100000 0084 11E7FFFF 047A
DBDATAFS 13F80000 04FE 085FFFFF 0218
CACHE 1C580000 0716 022FFFFF 008C
MODEM 1E880000 07A2 00C7FFFF 0032
07D4 1F500000

How do I make a bin file of everything from PIT to PARAM?
[Hardware Hacking General] AdamOutler:
What do we have to dump memory from one location to another?
[Hardware Hacking General] AdamOutler:
Phone was recovered back to 2.2 stock with odin 1click from a black screen brick :D...

I'd like to point out the differences in the first and second logs. It seems that something happened after booting from a 619k resistor... It's like it recovered itself..... wierd huh? Anyways... I'll be testing on another phone. I've sucessfully recovered a black-screen bricked phone with a few resistors.... this is a big leap for me because last time odin3 said everything was sucessfull, i ended up with a black screen that would not download.

We've also proved that black screens don't mean the phone is completely bricked. :D

I've got another test comming soon, On tuesday the next brick should arrive at my house.
[Hardware Hacking General] midas5:
Is there anyone who can link together some dpdt switches and automate some resistor value tests from 0 to 1meg. I.e. Set resistor value, wait 5 seconds. Read om5 then try the next.
[Hardware Hacking General] AdamOutler:
I can rig together a fully automated version of that. I could have a relay turn on and off power and have digital outputs turn on and off a relay for the reresistor

The problem is how to read OM5?
[Hardware Hacking General] androcheck:
Hi again!

hehe.. I never thought I would read a sentence like this on xda. :) :)

But regarding the black-screen brick:

I am not sure what happened with the two different resitor values, but I think you still had intact PBL and SBL.

Maybe just the PARAM partition was damaged. This is the partition bml6, where the param.lfs from Odin files gets flashed to. This partition is formatted with the proprietary and strange "j4fs" filesystem and normally is mounted under "/mnt/.lfs" on a running phone.

AFAIK on this partition all the pictures are stored which get displayed by the SBL (like the inital Samsung logo, the typical "bricked" phone-to-pc picture.. and so on..).

Maybe you still had an intact SBL but it wasn't able to display the picture because the param partition was corrupted.

As the error message in your log

Error(offset,length,j4fs_end,nErr)

also contains "j4fs" this also would point in this direction.

Did you see the yellow download mode logo in this case? This would imply that this logo is not stored in PARAM.lfs. Where does it come from then?

But I'm just guessing here.. You are doing great work! Thanks for all the experiments you are doing! :)
[Hardware Hacking General] midas5:
Leave the phone powered on an running.

Using ./adb shell and viewmem dump the OM register location 0xe?????? (number in previous post).

Quote:

"viewmem 0xe010e100 0x32 | busybox hexdump -C

The first byte displayed is the OM value,... "

So, set resistor value, wait 5 seconds, read the OM register with viewmem, repeat for next value.

No need to reboot the phone each time.

A good alternative could be modify the viewmem program to output a different result if the OM5 is set. Then just stop the scan at that point.

It could take a long time if steps are in 1K Ohm steps.
[Hardware Hacking General] androcheck:
I also would be very interested in the results of such a test! If this would be possible this would be great! :)
[Hardware Hacking General] midas5:
Are you using an Arduino Board?

If so, how to you get the 3.3volt serial output. From the Arduino specs I have seen, it outputs 5V serial.

I am thinking of purchasing an Arduino Board.