[AT&T Samsung Galaxy Note I717] darkspr1te:
The geeky bits

Ok, as i said it's still a work in progress at the moment.

I used the i717 bootloaders (thats why we have a brick as it's not getting to the aboot loader or little kernel as some other refer to it) and E160 modem and application cpu as my first target is getting odin mode back.

I was able to also use the E120 bootloaders (screen was messed up though )

I've just got home from a very long shift so i will do a full and clear write up ( STILL a work in progress ) tomorrow (20th)

but i will explain the basic now as you do need to download large files before we continue.

First you need to download the same firmware as you were originally on before the brick, The reason is because between versions i suspect there is minor changes in partition tables (that why the n7000 roms brick )

If you dont have the latest QPST (2.7.3xx or higher ) please google for it now, there are many sites that offer it. (links will folllow tomorrow)

also down load :-

ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00.tar (or tar.md5 )

i717-GB-Modem.tar (or .md5)

now my initital work was based off a chinese link for the A820L

http://blog.csdn.net/su_ky/article/details/7773273

To save you the time of many hours of translation and cross reference here is the quick run down

When the phone is in QDLoad mode its because the PBL (Stored in ROM , read only memory) could not start SBL1 or SBL2 , it stores the error in IRAM location 0x3FF18 and then goes to QDLoad fail mode. At this point it has tried uart, sd-card before hand and those failed too.

IRAM is the small built in memory of the MSM8660 CPU, it has not initiated the main SYSTEM ram yet so our memory space ro running code is 87k and 256k (refer to document 8960_boot_architecture.pdf found the unlock bootloaders section.

Now because our partition table and or our bootloaders are damaged (or we have emmc brick bug) we have to rewrite that data again to revive our bricks.

This is where it gets hard, and where my warnings now come into play.

right now you must think of the EMMC chip (its the name for the internal SD-CARD we boot from and store our normal data, imei and all the other data of the system, it is just a sc-card with better security for our purpose)

This emmc chip holds all of you settings for phone function and we must not loose that,

But...

we have to write data to the chip to boot again, I am not fully aware of all the memory locations so this is assumptions on my part.

we are going to write a basic bootloader that turns the whole phone into a sd-card, then write new bootloaders

using QPST we upload 8660_msimage.mbn (its a out of the box emmc factory image) this file is ment for setting up of dev versions of the phone, it made up of the following parts

sector 0 partition table or (partition0.bin AFTER patching with info from patch0.xml) I do not have a real copy of the original of this, it can be pulled from a working SVH-E160x using the code at the end.

after the MBR (which is the first part of the partiton make up, EBR follows, we can have 3 primary partitions and the fourth is a extended which is just another partiton table pointing to the next EBR and so on, upto 29 parititons i think)

anyway, after the MBR is SBL1, which chainloads SBL2 then that side loads RPM, gets a go signal then loads SBL3, when SBL3 is done most of the device hardware has been mapped into the cpu's memory table, SDRAM is now ready for larger code,

aboot now loads

some of the above loading functions occur at the same time and some wait on go signals from other code in other CPU's and some fail due corruption and or security check fails( JTAG users can watch the memory as it changes and halt, change data and continue which is why JTAGers's have more power , we dont have loader outputting data yet so no feed back, hence the brick)

when aboot is loaded we now have access to odin, so thats the goal, get aboot loaded for now who cares about the rest of the funtions.

we do need to care about those function later so thats why we will backup the entire system, i dont know if this will really work when restored and bring back all of our settings, thats later,

So onto the writing and possibly overwriting of important information, WARNING, i dont know yet if we are overwriting imei or simalr data yet so proceed at your own risk.

We will get the required from factory (qualcomm test or dev board not samsung factory in the box for consumer) from the MUI phone firmware

http://bigota.d.miui.com/QDN43/Mioneplus_QDN43_fastboot_Android_4.0_d3d83nmdk2.zip

from this zip we want 8660_msimage.mbn, patch0.xml, partition0.bin MPRG8660.hex ( this file is uploaded first, its a serial bootloader that is loaded at 0x2a000000 (start of PBL IRAM space 256k in size) and that setups a emmc to command access (we use revskill to upload the same file and dump memory , sadly ive not found a way of pulling the entire emmc to a backup, if we can figure that out we can pull the entire boot chain, fix it and send it back with what ever versions we desire, for now revskill is used to read the PBL error so we can at least see why we cant boot, not quite jtag but best we got ))

so now we have a phone running a basic bit of code that allows us to use code sent to serial port to write (possibly read) the emmc

we then use QPST to write the 8660_msimage.mbn as a one to one copy to the very start of the emmc , reboot phone and then when the phone restarts, it sets up the ram, some hardware (charging system, you will now notice your phone gets warmer that before when plugged in) and gives us direct access to the emmc as if it was a sd-card

at this point you could move the phone to any pc and it's just a sd-card branded qualcomm

BUT at this point the pc or any other computer you connect it too only see's the partition table contained in the 8660_msimage.mbn file , you other data is there so i advise the next step you MUST do.

connect the phone to a linux computer (use a live cd or live usb if you are not a normal linux user)

you will then run the following command

dd if=/dev/sd? of=/mount/location/shv-e160-full-emmc.bin bs=512

? is the letter of the drive , use dmesg and look for sdb or sdc , if you dont understand this part then i would suggest waiting for a possible script/one click solution. right now i am still booting only 1 in 20 boots and do not yet know why the boots fail and why some work.

of=/mount... this is where you will place the entire 16GB (32GB for 32gb models ) which should be a one to one copy of the system

the bs=512 is very important, it's block size, again, if you dont understand then maybe wait.

Thats enough for now, i am going to spend a hour or two working on some theories i came up with today.

user with working phones, please google how to backup parts of your phone, this may happen to you so it's best to backup asap !!!

from the blog.csd site a script to grab the partition table data, if a working usr could please run this and post the file, it does not contain user data only the partiton table and a direct 1 to 1 restore for any phone, i think it possible to write that direct back to a QDLoad mode phone, re write the bootloaders from linux and bingo working phone. i dont have backups as it's not my phone, it belongs to a client who knows i like to tinker with electronics.

anyway, once i have the partition file i can overlay it on my test phone (which i can activate QSLoad at any time, hence it's unbrick-able dev mode)

once the partition file is written to my phone, i can build a script to backup your important data, write known working bootloaders, and reboot the phone into a usable device.

here is the script in python (user linux live cd with a copy of adb, just google adb linux pack, there is a windows and linux allin one pack)

or you can get the original from the link above, i've not tested this as i dont have a device in adb mode but i've read through it and it looks sound but never tested by me.

Well i hope that enlightens you, am sorry i dont have a all in one solution for you, it's still a dev project and most of the information i have has only been collected over the past week, i only discovered it's QSDload after getting a msm8660 schematic and i still dont know what i am trully shorting out to trigger the QSDload when ever i want, even when it's booted

If any one from the unbrickable project(s) want to get in touch to share info i would be happy, i am also sure this is a usable solution for HTC phones as well

oh and one last thing

i read only a hour ago (via cell phone while in a car so not 100%) that once the phone is in QSDload and stays in QSDload on every power cycle then we can write the partition table to a SD-CARD and it will boot that, i have not tested that yet, i will try and see if the 8660_msimage.mbn file written to a sd-card works

I also suspect that some of my good boots have been when i've mixed up the sdcard with system.img.ext4 etc on it with the one with just update.zip on it. it's one my list of things to check , any suggestions are welcome as to how i correctly format the card (heads,cylinders, block size etc)

ok folks, hope this helps

COPY TEXT BELOW ONLY INTO A FILE AND RUN WITH PYTHON (linux is easier, may be possible to use a vm box, i am but linux is my main os and windows is the vm)