[AT&T Samsung Galaxy Note I717] darkspr1te:
I Have decided that this thread has served it's purpose and will now be closed to future posts. Please direct and 'non' SHV-E160L post's to

Brixfix V2

Please can all Ongoing jobs/works migrate to the above thread.

-----------Final Notes--------------

It has been mentioned many times that i should go back and correct the information below, i started to correct a few post's then realized i was removing the flavour in change of colour and size, parts of this thread documents my mistakes, assumptions and general lack of understanding of how we NOOBS post on XDA, It's with that in mind that i have decided to leave the mistakes in, so you can see in writing what i gained from the support of other Devs here.

Now, if you are NOOB in anyway or have a few questions please click HELP

If you are bricked and need help, read this thread first, there is NO one CLICK solution for anything, even this mentioned device.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

So you Brixed/bricced/BOD/QDL/EDLOAD/QHS-USB/05c6:9008/05c6:9025/ your device? Need a Oil and brush , Need help, follow this

One, Rules

Two, Understanding

--------------------------------------------------------------------------

Tip From the Author,

Some of you may have noticed that i did not start the original thread with a question, I did something my mentor taught me at around 9 years old but didn't put into good use until much later in life.

The tip is write things down as a question for yourself, in the writing process you get to pass the information past the part of your brain that interprets information, virtual sounding board, before posting as a question for others.

--------------------------------------------------------------------------

New Tools for debricking, goto

Brixfix V2

---------------------------Further Info Info -----------------------------

** I have Since Fixed the device and developed soultions for non shv-e160l devices. Prior posts are undergoing edit's for corrections.

** if you want the glory shot, sorry you will just have to read through.

** If you are selling this as a solution, dont. I know who you are.

---------------------------Original Post-----------------------------

Hi All

As i mentioned on this thread http://xdaforums.com/showthread.php?p=32231827#post32231827 i will be attempting to come up with a home grown debrick solution for a SHV-E160L samsung note from korea.

I will use the forum to document what i am doing, i am very new to this so correct me please if i am wrong. I have never done Android dev work at any time but i have a very good understanding of the logic behind it all. `

Things i Have :-

Phone ( SHV-E160L)

bus pirate v3 with jtag firmware

openocd compiled on ubuntu and centos 6

smd jtag adapter and relay wire ( magnetic wire)

things i still need :-

openocd target config file for MSM8660 Snapdragon cpu (and a better understanding of eMMC access, how to load boot loaders either into ram or eMMC or trigger fail over boot to sc-card, USB via software or X0M/Boot pins)

assembled jtag (it's the smallest soldering i've ever seen)

.PIT file for 32GB model (if someone could pull the .PIT file from a working unit I would be happy, specify your radio/kernel versions when uploading)

micro fine solder iron tip and 20w iron (i've got 60w but too high for this type of work)

Does anyone have a idea of the SD-CARD partition layout, files for snapdragon devices, google has given me much for other devices but not a snapdragon .

Another question, I've used the USB jig to trigger 301K mode USB-Factory and seen no activity in dmesg for usb devices, i've yet to try windows, does windows/linux behave in a different way when it comes to usb , as in windows see's the qualcom usb mode but not linux ? does the usb client device always start the comms?

using the 615K usb jig i get nothing too, no pbl message from samsung (hence i am led to think is's the pbl/sbl thats damaged)

My understanding up boot is as follows

iROM code

This loads basic settings to boot the PBL (iROM is in rom) the PBL is loaded into radio(modem) cpu and then loads the SBL(s)

PBL/SBL stored in eMMC at address ????? (need to document the address for the masked access to eMMC and jtag/openocd access unmasked access)

Once the SBL is loaded you with have the ODIN mode (USB/UART)

from what i can see of commercial JTAG boxes is the access the radio cpu via jtag, write a new PBL/SBL to the eMMC then halt/reset cpu which now loads the new bootloaders, (resurrect dead body)

The openocd TAP id for the cpu should be 0x105310E1 but thats a number i got from a riff box log, not any actual testing ( still need to solder the fine pitch connector)

Here is a log from a riff box, not sure if the address's are usable accross to opencd

Taken from gsm-forums:-

I did notice one thing, the riff box opens the serial port, i wonder if they load PBL+SBL into memory, reset the cpu, then using the serial connection activate download mode ? (like on the captive)

I also dont know how the cpu (jtag TAP id? ) and flash variables translate accross to openocd as ive not found a target config file yet ( or my searching is wrong)

in the full stock Firmware I was able to extract the .tar file which contained,

amss.bin <-- application cpu boot files ?
boot.img <-- kernel/initrd ramdrive
mdm.bin <-- modem cpu boot files
recovery.img <--- recovery image
system.img.ext4 <---- rest of the system applications

so i think we have the two cpu firmware/boot loaders in the .bin files, these bin files are just fat32 images, to access in ubuntu use

mount -o loop mdm.bin /mnt/mdmmountlocation

My guess is my first approach is getting the right PBL/SBL into the system and getting some feed back via uart, i have the jtag pinouts and further reserach says there is a UART2 on the jtag header, so when soldering up my jtag adapter i will include all pins if i can and sniff for serial logic, i happen to have a Open source logic sniffer, great tool as i do a lot of hacking into serial devices like scales and till printers .

back to topic.

When i do get to the jtag part at a minimum i should have access to the modem radio, afaik jtag devices connect in chains and most of the IC's that have jtag on the phones board all should link to the master device (i am thinking it's the modem cpu, no application) and that the Two cpu's share the eMMC memory some how, or it could be one cpu loads it into the other (it is connected via jtag down the chain) .

hopefully someone could correct me there.

Most of this is theory and my guess work, correct me if you find a mistake. most of the research is only over a few days too so i am far from finished there, does not help that most of the users speak a language that google translate just does not have a flair for.

Most of the info seems to suggest the modem cpu is the first inline so i decided to look further into the files there, notice the mdm.bin file is 23Mb, thats large, when mounted i notice the is a folder called 'image' ( amms.bin has folder called IMAGE , note the case difference, dont yet know whay)

in image folder we have :-

1.3M Sep 30 13:07 AMSS.MBN
35K Sep 30 13:07 DBL.MBN
2.2M Sep 30 13:07 DSP1.MBN
19M Sep 30 13:07 DSP2.MBN
40 Sep 30 13:07 EFS1.MBN
40 Sep 30 13:07 EFS2.MBN
40 Sep 30 13:07 EFS3.MBN
295K Sep 30 13:07 OSBL.MBN

Ah, i see amss.mbm , that must be the boot loader for the application cpu, DBL.MBM seems to be the PBL , OSBL.MBM could be the SBL

then there is the DSP/EFS files, I did do the command strings on all the files,

DBL.MBM does not have any text in the file that points to being able to do UART on boot, all text seems internal like pointers and references to the original build files e.g

D:\Q1LGT_MDM\MDM9600\modem_proc\core\boot\secboot2\dbl\target\mdm9x00\src\dbl_ddr.c
9x00B-SCAQSVZM-31613102
D:\Q1LGT_MDM\MDM9600\modem_proc\core\boot\secboot2\dbl\target\mdm9x00\src\dbl_sahara.c

but it also does contain data like this

auth_image
@p@-
@configure_hw
@flash_init
l0:eek:SBL
load_osbl_img
@DBL, Start
hw_init

so it looks more likley that dbl is first in the chain, it refers to loading osbl and configure hardware, i wonder if it means USB/UART at this stage or setting up ram and other GPIO's

in OSBL.MBM we have more interesting text

MbP?
Unable to attached to ChipInfo DAL
SAMSUNG
TOSHIBA
Flash: Failed to do initialization for probe!
ONFIx
0:ALL
Flash: Multi 2X page read not supported!
Flash: Multi 2X page write not supported!
boot_qdsps
OSBL
hw_init
hw_init_secondary
OSBL, Start
create_vector_table
ram_init
retrieve_shared
clobber_add_protection
mmu_flush_cache
OSBL, End
OSBL, Delta
osbl_sahara_load_amss
osbl_sahara_load_dsp1
osbl_sahara_load_dsp2
osbl_sahara_load_ramfs1
osbl_sahara_load_ramfs2
osbl_sahara_load_ramfs3
smem_boot_init

so it is looking more and more like DBL then SBL which then loads all of the other parts , also if you notice EFS1/2/3 are all tiny 40byte files, now i see why, they are loaded as ram-drives, so i assume those file set out the basic EFS file system in the ram.

again from research the boot stages are often counted as 3, i am assuming the real first part is in rom of the cpu (is this what triggers the qualcom download mode ) that loads DBL from eMMC and chain loads SBL

Now looking around the riff forums i see the list the info in a different way

TZ i think is Trusted Zone

RPM - Power manager ?

now how this translates to file name from full flash and to mmcblk0p1 partitions i have yet to find out, i still dont have a .PIT file from a 32gb model

More updates to come,

regards

DarkSpr1te