Totally bricked when downgrading. Is there a Jtag pinout/service manual? Or buy new?

**singalen** · 07-26-2011, 03:13 PM

Hi,

After downgrade attempt my Spica doesn't even turn on. Is there anything I can do?
I'm OK with making an own jtag - my friend can do this.

(And don't you try to do what I did!)

I tried to downgrade from CyanogenMod-7.1.0-RC0-Spica-alpha4, flashed SGM-froyo-BETA2.1.zip from recovery.
Wiped all caches before and after application.

Spica stopped booting: after first bootlogo screen went dark every time. I could still boot to recovery or download mode.

I flashed CM 6.1 one package via Odin, which helped me before.

After the flash finished, the phone didn't reboot - and didn't ever since.

Battery removal didn't help.
Looks like I need new phone or is there anything I can do?

**tom3q** · 07-26-2011, 03:23 PM

The JTAG connector is hidden behind the sticker with IMEI, with following pin-out:

I have successfully flashed a fully bricked phone (after using a wrong bring-up image from i5800 in a lame 3rd party service center...) using just (ARM Linux) GDB connected to J-Link GDB server (OpenOCD should also do) and my OneNAND flasher, attached to this post. I believe you need to flash Pbl and Sbl using it, attached them too.

The way it works is very simple. Target flash image has to be uploaded at address 0x50000000 (beginning of the RAM) and the flasher can be uploaded anywhere in the RAM. Then you jump to the flasher, wait several seconds until it completes and reset the phone. You can make sure that it completed by adding a breakpoint at the last instruction of the flasher which is just an infinite loop. You can extract the address (or rather offset) by disassembling the resulting binary using objdump, like

Code:

armv6zk-unknown-linux-gnueabi-objdump -D -b binary flasher.bin --architecture=arm

In (ARM Linux) GDB it would look like:

Code:

> restore boot.bin binary 0x50000000
> restore flasher.bin binary 0x51000000
> break *0x510000ec # this address depends on flasher compilation options, it's just an example
> jump *0x51000000

OneNAND flasher written be me (see code comments for more details): flasher.tar.gz

Bootloader images: bootloaders.tar.gz

**nipungupta7** · 07-26-2011, 05:11 PM

Guys don't you think we should find out what is the ugly cause after all these bricks. I am not much afraid of losing my Spica, but afraid of losing the thrill and excitement of being here at Samdroid, which I may lose if I lose my phone

**spica234** · 07-26-2011, 05:21 PM

Thank you tom3q

Sent from my GT-I5700 using Tapatalk

**tom3q** · 07-26-2011, 06:10 PM

Originally Posted by nipungupta7

Guys don't you think we should find out what is the ugly cause after all these bricks. I am not much afraid of losing my Spica, but afraid of losing the thrill and excitement of being here at Samdroid, which I may lose if I lose my phone

It's just a wrong design of flash memory handling by Samsung. Especially the whole XSR system, which is not only a kernel module, but a complete system for managing NAND flash memories including partition layout, bad block remapping, internal meta data, etc.

The primary (also called primitive) boot loader (Pbl) relies on correctness of these meta data when loading the second (secure?) boot loader (Sbl), in the same time not having any fail-safe recovery system (usb download mode), provided only by Sbl. So guess what can happen if a kernel level code (XSR module) corrupts some meta data. Same can happen with Odin which just uploads the images to the phone and they are handled by the boot loader using its internal XSR code.

Other point is why the meta data get corrupted. To me it looks like a bug in XSR code, most probably a race condition which triggers only when some specific conditions are met, which can be some kernel configuration options, some events received from OneNAND controller, some requests received from the user space, pretty much everything.

**singalen** · 07-26-2011, 06:14 PM

Thank you a lot tom3q! Will try to compile and run this. We happen to have jlink here at work, will see.

What do you think, could Odin include additional range checks and prohibit flashing in an overriding file? It won't give a 100% guarantee, but at least some level of security.

BTW, once I flashed that image and it was OK. Is it possible that bootloader was moved in 2.3? That ROM's logo size is 112687 bytes - should it overwrite bootloader?

**tom3q** · 07-26-2011, 06:22 PM

The logo can't overwrite any of the boot loaders, because it's located after both of them. The only thing it can overwrite is the param block, but it begins at 192th kilobyte of the logo partition. This case should be recoverable from a serial console, using an UART JIG and a TTL-RS232 level converter.

We don't have Odin sources, so we can't modify it (not counting binary patching). Anyway, Odin won't be used anymore with my kernel, which will use only recovery based flashing (and because of getting rid of kernel level XSR and accessing the flash directly with Linux MTD API and some other magic which I will describe a bit later, because it's not ready yet).

As for boot loaders, most of ROMs don't touch it. Also they can't be moved, because their location is hard coded into respective lower level boot loaders (i.e. Ibl has the location of Pbl hard coded and Pbl has the location of Sbl hard coded). My guess is that you met a kernel level XSR meta data corruption, which caused Sbl to flash the image incorrectly. In addition that CM One image contains both Pbl and Sbl inside and they get flashed, so if the flashing fails they can be left corrupted.

**Maxxd** · 08-17-2011, 02:44 PM

Originally Posted by tom3q

It's just a wrong design of flash memory handling by Samsung. Especially the whole XSR system, which is not only a kernel module, but a complete system for managing NAND flash memories including partition layout, bad block remapping, internal meta data, etc.

The primary (also called primitive) boot loader (Pbl) relies on correctness of these meta data when loading the second (secure?) boot loader (Sbl), in the same time not having any fail-safe recovery system (usb download mode), provided only by Sbl. So guess what can happen if a kernel level code (XSR module) corrupts some meta data. Same can happen with Odin which just uploads the images to the phone and they are handled by the boot loader using its internal XSR code.

Other point is why the meta data get corrupted. To me it looks like a bug in XSR code, most probably a race condition which triggers only when some specific conditions are met, which can be some kernel configuration options, some events received from OneNAND controller, some requests received from the user space, pretty much everything.

In other words, it's a bug we can't predict

**singalen** · 08-17-2011, 03:10 PM

Originally Posted by Maxxd

In other words, it's a bug we can't predict

Well, there always could be some facilities, like basic sanity/consistency checks, CRCs for the metadata (whatever it is) etc.

BTW still waiting for my friend to solder a jack to JTag. Will let you know how it goes.

**sunbeam96** · 08-19-2011, 12:07 AM

@tom3q
Is it possible to flash Spicas with other OS (kind of Linux for ARMs, Windows Mobile, MeeGo) using JTag?

It would be great having Spica with MeeGo.

Tapatalked from my Galaxy Spica