Updated 25th September - Summary points added at bottom of post.
Updated 27th September - More detail concerning DeviceData and use of HEX editor added.
IMPORTANT: Updated 28th September - I now know that if you have bootloader v1.06 on your XDA II, you cannot downgrade your ROM (at the moment). We will see if we can find a way round this but cannot promise anything. My thanks to gerald8297 for his patience and help using his device and thus enabling me and him to determine this.
Please read all of this post before attempting any upgrade.
This post is the second of two posts and (hopefully) contains the solution to the Country ID error problem during upgrade/downgrade of the XDA II. The first post contains the background and conclusions to an investigation into the problem and can be found here:
ROM upgrade/downgrade Country ID errors - an investigation
If you haven't already done so, I recommend that you read it so that you are aware of the reasons for the following procedures.
Firstly, something I must say to protect myself .
The procedures described in this post are the ones I used on my own XDA II and they worked for me. Although they should work for anyone else, there can be no guarantee. I cannot be held responsible or liable for any damage to, or malfunction of, your device caused by a failed upgrade. By deciding to upgrade your XDA II, you are taking full responsibility for any consequences arising out of doing so, and you may void your warranty. Flashing the ROM may cause Data Loss or even Device Malfunction.
Secondly, I would like to acknowledge all the posters to this forum for, in one way or another, providing clues to the solution to this problem and also a big thank you to itsme and softworkz for the utilities and information that have proved so helpful. And, of course, thanks to my friend merlin_uk whose input was invaluable.
These procedures require the following tools:
xda2nbftool: A description, explanation of passwords required, examples of usage and a download link for xda2nbftool are here.
A Hex editor: Any Hex Editor will do, but this is the one I used and which I describe the use of here.
IMPORTANT: Make a full backup of your XDA II as all data in main memory will be erased. Storage card and storage data should remain intact (but don't take my word for it!).
NOTE: The passwords specified in the commands and the exact format I used may be different for you depending on the version of HimaUpgradeUt you intend to use. See here for more information. Also, the operator and language strings used by me may be different to those you need to use. Don't just copy the commands listed below verbatim. Check what you need first. In my case my original operator ID was O2, but it got changed to CDL because of the reasons stated in my first post. Therefore, I wanted to get my device back to O2. This meant, for the first upgrade, using CDL as the operator ID in the nbf headers (to get past the verification) and O2 in the extra block of data (to set my device back), and then for the second upgrade, I was able to specify the correct operator for me (O2) in the nbf headers.
Obtain the set of upgrade files you require. If you have an operator-provided .EXE file, you can extract the files using Winzip or Winrar. The set of files will normally consist of:
[list:def15107cd]HimaClearJumpCode.exe
HimaGetDeviceData.exe
HimaUpgradeUt.exe
ms_.nbf
NK.nbf
Radio_.nbf
[*]Copy all these files into a folder of your choice on your PC (it is probably easier to create a new folder), then copy the xda2nbftool.exe program into the same folder.
[*]Copy the HimaGetDeviceData.exe file to any folder on your device.
Warning: DO NOT under any circumstances copy and run HimaClearJumpCode.exe on your device as it will render it unbootable. It is used by the upgrade utility to put you device into bootloader mode prior to upgrading.
[*]Execute HimaGetDeviceData.exe on your device. There will be no visible indication that it has run, but it will produce a file called DeviceData.txt in the Windows folder of the device.
Here is an example of the contents of DeviceData.txt:
Code:
U S B 3 2 1 . 7 2 . 0 0 W W E P H 1 0 C D L W W E 1 . 7 2 . 1 2 6 1 . 1 4 . 0 0
"USB 32 1.72.00WWE " is the OS Version
"PH10" is the Device Type
"CDL" is the Operator ID
"WWE" is the Language ID
"1.72.126" is the Extended ROM Version
"1.14.00" is the Radio Version
Obviously the actual content will depend on your device, but the layout of the information will be the same.
[*]Copy the DeviceData.txt file to your PC and open it using Notepad. Make a note of the current operator ID and language ID specified in this file (see step 4 above), for use later. These values are what your device is currently set to and it may surprise you to find that they are different from what you expected!. I will refer to these noted values as <operator> and <language>, to avoid confusion with specific values.
[*]Start a command prompt session on your PC and set your current directory to the folder used in step 2.
[*]Extract the decrypted versions of the nbf files by entering the following commands at the command prompt (but see note above):
Code:
xda2nbftool -x NK.nbf NK.nba 0x20040304
xda2nbftool -x ms_.nbf ms_.nba 0x20040305
xda2nbftool -x Radio_.nbf Radio_.nba 0x20040306
[*]Now modify the operator and language strings in the nbfs using the values noted from the DeviceData.txt file above by entering the following commands at the command prompt substituting <operator> and <language> with the noted values (but see note above):
Code:
xda2nbftool -sd PH10 -so <operator> -sl <language> NK.nba
xda2nbftool -sd PH10 -so <operator> -sl <language> ms_.nba
xda2nbftool -sd PH10 -so <operator> -sl <language> Radio_.nba
[*]Run the hex editor and in that open the file ms_.nba. If you are using xvi32, it will display the hex contents of the file to the left of the window and the character representation to the right of the window. At offset 74 (0x4A) you will see the operator string your device will be set to and at offset 94 (0x5E) you will see the language string your device will be set to.
NB. Your device will be set to these values irrespective of the values specified in the normal nbf headers.
To change the operator ID:
Click on the Address menu item then click on Goto.
In the window that is displayed, ensure decimal and absolute are selected, type 74 into the entry field then click OK. This will position you at the operator string location.
Using either character entry on the right or hex entry on the left, enter the operator string device should be (or what you want it to be ). Note that any non-used character positions should be edited to contain null (0x00) which can only be entered in the left hand side of the window.
To change the language ID:
Again, click on the Address menu item then click on Goto.
In the window that is displayed, ensure decimal and absolute are selected, type 94 into the entry field then click OK. This will position you at the language string location.
Using either character entry on the right or hex entry on the left, enter the language string your device should be. Again, any non-used character positions should be edited to contain null (0x00) which can only be entered in the left hand side of the window.
[*]Save the ms_.nba file.
[*]Update the crc values for each of the decrypted files by entering the following commands at the command prompt:
Code:
xda2nbftool -c -u NK.nba
xda2nbftool -c -u ms_.nba
xda2nbftool -c -u Radio_.nba
[*]Encrypt the files back into the nbf files by entering the following commands at the command prompt (but see note above):
Code:
xda2nbftool -x NK.nba NK.nbf 0x20040304
xda2nbftool -x ms_.nba ms_.nbf 0x20040305
xda2nbftool -x Radio_.nba Radio_.nbf 0x20040306
[*]Delete the nba files using Windows Explorer or by entering the following command at the command prompt:
Code:
del *.nba
[*]Run the upgrade from Windows Explorer by executing HimaUpGradeUt.exe
The first part of the upgrade is the verification process which is non-destructive, in which it generates the DeviceData.txt file on the device then compares the information in it to the information in your nbf headers (specifically the device type, the operator and the language). If an error is displayed, double check the steps detailed above and try again.
If all is well it will then display the current and new settings and give you the option to proceed with the upgrade. If you cancel at this point, nothing has changed on your device.
[*]Click the upgrade button... ONLY if you want to proceed with the upgrade.
Go make a coffee or even dinner because it takes at least 30 minutes to complete the full upgrade.
As eDsuB has pointed out, it is possible that the upgrade will fail or stop for some other reason and you are left with the bootloader screen (screen is dark and may display 'SERIAL' or 'USB'). If this happens, don't be too alarmed. Just remove your device from the cradle, reset your device, replace it in the cradle and restart the upgrade.
You may even still hit a Country ID error after it has started the upgrade, but I believe that it is some other sort of problem and it just reports it as Country ID error. If you do end up with a bootloader screen, and this was the first of two upgrades, it is OK to restart the upgrade using the second one - that is, the one with the nbf headers and the extra data in ms_.nbf set to the correct language and operator.
[*]Once the 'Congratulations' window appears, the upgrade is complete (even though the device may still indicate that the radio upgrade is in progress).
[*]Remove you device from the cradle and hard reset.[/list:def15107cd]
Hopefully your XDA II is now upgraded/downgraded.
To summarise
If, as was the case with me, you have successfully run a previous upgrade and your device has been unwittingly configured with an incorrect operator ID, you will need to run the steps detailed above twice. The first time, it is purely to set the device's language and operator IDs back to their correct values, with the nbf headers needing to be set to the incorrect values in order to allow the upgrade to proceed. The second time then becomes the 'real' upgrade, because, this time, in step 8, you will be using the desired language and operator IDs which will now match those of your device.
The information specified in the extra block of data in the operators ROM image (ms_.nbf) is used to set the device/operator/language in the device. It doesn't need to match what the device is set to already. It is this information which HimaGetDeviceData will retrieve at the beginning of any subsequent upgrade and return via the DeviceData.txt file.
The information specified in the nbf headers of all the ROM images (NK.nbf, ms_.nbf and Radio_.nbf) is used to set the device/operator/language in the software of the device. It must match the device/operator/language currently specified in the device.
Neither the ER2003Edit tool nor xda2nbftool, by themselves, update the extra block of data in the ROM image.
Anyone upgrading should check and amend (using step 9), if necessary, the information contained in the extra block of data in the operators ROM before performing any upgrade. This should be done even if the nbf headers are already correctly configured. Failure to check could lead to your device being set to an unwanted operator ID or language ID at the end of the upgrade.
Feedback concerning these procedures is most welcome. If any errors or omissions exist, please post a reply to let me know so that I can correct them. Also, please post a reply if you upgrade successfully, stating the original version/operator/language and the new version/operator/language. By doing this it will help others decide whether to upgrade or not.
You are missing a possible step that often occurs during 15.
The upgrade is canceled because of some vague reason and the device is stuck in bootloader (USB or SERIAL on screen).
This is the point when cold sweat starts drippingof your forehead . . .
Remedy: Reset device and restart the upgrade. It will take longer than 30 minutes. I flashed two times now and this happened both times . . .(didnt have any country-id or language issues)
Also: In the posting you should mention the operator you use is CDL (chances are that people take your posting literally wich for sure get a lot in the country-id trouble.)
Thanks to edsub for his comments. His advice has been incorporated into the post.
maybe this post should be sticky so it will not be lost in the mists of time
A new hope is born
Impressive discoery by dcs.
Anyway, can anyone confirm that this method is usable or workable for downgrading imate ver1.72WWE to Asia Rom 1.60 WWE.
One major doubt that, if the xda2 is in 1.72 and presumably it was wrong operator coded CDL, so the changes (suggestion by dcs) should take place on the 1.72 imate rom again or the 1.60 Asia Rom.
I once tried to change the 1.60 Rom using er2000edit to set the operator name to CDL instead of O2. The first upgrade screen was passed successfully but i was blocked in the 2nd screen which left me cold dead xda2 with 1.06 serial.
I guess much research shall be done before pursing this method. Anyhow it was a good finding. :lol:
This method does work…
I too was in a position were I could not upgrade or downgrade my O2 XDAII ROM because the operator code on the device had been changed to CDL…
Following dcs’s method sorts this nasty problem out once and for all – I can now downgrade, upgrade to any version of ROM I want!!!
Nice one dcs!!
I have exactly the same problem like yours. Thanks to dcs for your hard work.
I have updated the post slightly to (hopefully) lessen confusion about operator and language values used.
maybe incorporate this post in wiki.xda-developers.com ?
Answer to gerald8297 post - A new hope is born
Theoretically it shouldn't matter which version of the upgrade you run first.
The first upgrade is done purely to set your device operator and language values back to the values they should be (or the values you want them to be), and the nbf headers will have to match the values currently defined in your device.
The second upgrade is done to actually install the version of software you want onto your device. The nbf headers should be configured to match the (now correct) operator and language values defined in the device. Also the ms_.nbf file should be checked to ensure the extra block of data isn't going to set your device back to an unwanted value.
You say that your previous attempt at a downgrade failed at the second screen. Do you mean that the OS was installed, but it failed at the extended ROM part? If so, did you edit all 3 nbf file with ER2003Edit to set the operator before running the upgrade? If you only edited the NK.nbf file it would explain what happened. If this is the case, and you are stuck on the bootloader screen, you should be able to reset your device and rerun the upgrade.
It looks like you used the same i-mate 1.172.00WWE upgrade as I did in which case your device has been set to operator CDL and language WWE.
Good luck!
I have updated the post by adding some summary points at the end. These, hopefully will provide a better overall understanding.
FINALLY!!!!! IT WORKED!!! Thanks 102035492304923049 million times, dcs. This is the manual to use!
Excellent! I am very pleased.
Updates Made
I have made a few changes to the post to try and make things a little clearer
IMPORTANT
Updated with information about downgrading restriction.
dcs,
I am now at step 13
I edited ms_.nba ONLY using the hex editor. The 74th block is set the CDL so i changed it to O2 and put a null value on the 76th block where L of CDL used to be.
WWE remains as WWE. I am about to proceed but just a few questions.
(1)since this is my first upgrade, i need only run this once right?
(2) is ms_.nba the only file i need to edit or i also need to edit the Radio_.nba and NK.nba files?
So after upgrading... my xda2 should be 1.72 WWE and 1.17 radio right?
Thanks for all the updates on your post. Things are getting a bit clearer.
i3oyi3astos said:
dcs,
I am now at step 13
I edited ms_.nba ONLY using the hex editor. The 74th block is set the CDL so i changed it to O2 and put a null value on the 76th block where L of CDL used to be.
WWE remains as WWE. I am about to proceed but just a few questions.
(1)since this is my first upgrade, i need only run this once right?
(2) is ms_.nba the only file i need to edit or i also need to edit the Radio_.nba and NK.nba files?
So after upgrading... my xda2 should be 1.72 WWE and 1.17 radio right?
Thanks for all the updates on your post. Things are getting a bit clearer.
Click to expand...
Click to collapse
(1) As it is your first upgrade, you should only need to run it once, as long as the your device information (retrieved in DeviceData.txt) is already set to the values you want (in your case, O2 and WWE). Two upgrades are required only if the device information is incorrect to start with.
(2) Only the ms_.nba file requires editing with the hex editor.
You can see what versions of OS, Extended ROM, and Radio you are upgrading to in step 14, before you click the Upgrade button.
Hopefully, all should progress OK now
@dcs: This topic is getting better and better.
I would vote to have your info instead on the wiki pages instead of the info that is there now on upgrading.
Because there is a risk of others still wanting to stick to the old info, for starters you may want to setup a new wiki page that is linked to from the old 'upgrade' wiki page.
Its quite simple to create a wiki page, as I have just experienced for a subject on IIWPO.
I have stumbled upon sumthing last night.....
1. Waxx's Rom would make my XDA2 a CDL Device right? (I upgraded without modification of Waxx's ROM)
2. Waxx's ROM uses O2 headers (verified through ER2003edit) and the extra code on MS_.nbf says its CDL
3. If I loaded Waxx's ROM (which I did) it would turn my unit from an O2 to CDL.... correct? I could not verify since my GETDEVICE Data does not work... I dunno why.
4. Here comes the weird part..... I followed your instructions to modify my operator to become O2 again..... (change headers and offset 74).... If I understand it correctly, I should change Waxx's ROM headers from O2 to CDL ( to pass the operator test..am I correct?) and I should change OFFSET 74 to O2... correct?
5. When I tried upgrading.... (all headers = CDL, Offset = O2).... the upgrade failed.... error 120 (country code error...me thinks)....
6. I tried changing all headers to O2 and offset was still set to O2..... tried a second time..... and it worked.... get device data works now.... and it says I have an O2 machine
7. IMO Radio rom 1.17 is better than 1.14..... thanks for your help mr DCS, Mr Waxx, Mr. Gollum
Z-man said:
I have stumbled upon sumthing last night.....
1. Waxx's Rom would make my XDA2 a CDL Device right? (I upgraded without modification of Waxx's ROM)
2. Waxx's ROM uses O2 headers (verified through ER2003edit) and the extra code on MS_.nbf says its CDL
3. If I loaded Waxx's ROM (which I did) it would turn my unit from an O2 to CDL.... correct? I could not verify since my GETDEVICE Data does not work... I dunno why.
4. Here comes the weird part..... I followed your instructions to modify my operator to become O2 again..... (change headers and offset 74).... If I understand it correctly, I should change Waxx's ROM headers from O2 to CDL ( to pass the operator test..am I correct?) and I should change OFFSET 74 to O2... correct?
5. When I tried upgrading.... (all headers = CDL, Offset = O2).... the upgrade failed.... error 120 (country code error...me thinks)....
6. I tried changing all headers to O2 and offset was still set to O2..... tried a second time..... and it worked.... get device data works now.... and it says I have an O2 machine
7. IMO Radio rom 1.17 is better than 1.14..... thanks for your help mr DCS, Mr Waxx, Mr. Gollum
Click to expand...
Click to collapse
I think the error must have been related to the problem with HimaGetDeviceData, because everything you did was correct and your assumptions were also correct. Perhaps the first attempt failed, but at the same time it sorted out the HimaGetDeviceData, and also got as far as setting your device to O2?
Difficult to say what happened exactly, but main thing is you are up and running - Well Done!
I'm truly sorry about the delay.
I've finally got round to posting a a STAR100 SuperCID guide.
1. Get itsutils: http://www.xs4all.nl/~itsme/projects/xda/tools.html
2. Run pdocread.exe with no args. Take a note of the "uniqueid" value.
3. Run "pdocread -n 1 0x000000 0x10000 -b 0x4000 original-bdk1.nb" - you'll get a file.
4. Head over to http://www.spv-developers.com/strtrkCID/. Feed it the DOCID and the file you got from steps 2 and 3. It'll give you back anoter file.
5. Run "pdocwrite -n 1 patchedfile.bin 0x000000 0x10000 -b 0x4000" where patchedfile.bin is obviously to be replaced with the patched file you got from step 4.
6. There is no 6. Report feedback.
Click to expand...
Click to collapse
All credit goes to itsme - he wrote all the tools and scripts which made all this possible.
Spawning script: perl startrek_cidedit.pl cid1e62995dd1db197b00b697388760b5e3.bin -i DOPOD601 -c 11111111 -o supercid1e62995.bin 2>&1
decrypting
bufend=44bdd4609845fd0931a871b4a31ddba42d4b96386f9 e9c5dff947c035432fc15
result=b2c7c4eede400853eb232eba436f394b3d75a9adf4c e9a1e452b26ea9059dc59
sha64k=8a7e3a8462b8c851ac125710d44abc05da4916f215e 331f98420db7ae5d87a5d
buffer checksum failed
why ?
Looks like the DOCID value you entered is incorrect. It should be a long stream of hex numbers.
Fantastic !!! Working Ok on SPV F600. Now, we need how to simunlock this smartphone.
Thank you very much Zone Mr.
i run pdocread in step 1 and got a dos screen that desaper in a second,and were i find the file in step 2.
Zone-MR said:
Looks like the DOCID value you entered is incorrect. It should be a long stream of hex numbers.
Click to expand...
Click to collapse
thank you Zone-MR,can u tell me how to get a long stream of hex numbers.
wlinsong said:
thank you Zone-MR,can u tell me how to get a long stream of hex numbers.
Click to expand...
Click to collapse
i know how to do,thank Zone-MR very very much
is there someone know how to flash rom use T-flash Card?
someone can't get the docid ,because you must use the old one!
I tried to do first step but when I ran pdocread.exe I get the following message :
Could not update itsutils.dll to the current version, maybe it is inuse?
try restarting your device, or restart activesync
or maybe your device is application-locked.
I've app-unlocked my device, activesync works ok, and restarting does not help. Phone is Qtek8500.
Any ideas?
Thanks
Is the script to calculate CID area for startrek available?
I think this should use the same method on Artemis or Herald, the problem is that they have G4 DOC and we'll not be able to use pdocwrite, but on those phones we're already able to place a hacked SPL in mem with psetmem.exe and jump into it's address with modified haret version. If we have the right CID area we can use the hacked SPL to flash it.
sorry for the ignorance...
I have downloaded itsutils but where is the dpocread.exe??
do I have to connect to the device with the mtty??
Maybe a bit more explanation
I've CID unlocked my Qtek 8500 and installed new ROM 3.6.251.0. Thanks Zone, great work!
Maybe it would be useful to write more detailed instructions, so here it is :
1. Application unlock your phone using regeditstg and do the following :
HKEY_LOCAL_MACHINE\Security\Policies\Policies\0000 1001 = 2 -->Change the value data from 2 to 1
HKEY_LOCAL_MACHINE\Security\Policies\Policies\0000 1005 = 16 --> Change the value data from 16 to 40
HKEY_LOCAL_MACHINE\Security\Policies\Policies\0000 1017 = 128 --> Change the value data from 128 to 144
Reboot the phone
2. Run SDA_ApplicationUnlock tool. Reboot the phone after it finishes.
3. Download itsutil.zip from http://www.xs4all.nl/~itsme/projects/xda/tools.html , version from 2005-6-28. There is even newer version, but with that version you can not use pdocread without arguments.
4. Connect the phone with activesync
5. Run Command Prompt, go to subfolder named "build" in itsutils folder, and run pdocread without arguments
6. Note the value of "uniqueid". It will be something like : "00 00 00 00 12 03 02 14 3b 07 1b b2 04 05 07 54"
7. run pdocread again with these arguments : "pdocread -n 1 0x000000 0x10000 -b 0x4000 original-bdk1.nb". This will make original-bdk1.nb file in build folder (where the pdocread is located).
8. Upload this file and value of uniqueid to http://www.spv-developers.com/strtrkCID/. It will open a new page after few seconds. Go to bottom of the page and click the link "Download patched BDK1"
9. Download the file (it will be named like "supercidxxxxxxx.bin) to "build" folder
10. Run the pdocwrite from command prompt with these arguments : "pdocwrite -n 1 supercidxxxxxxx.bin 0x000000 0x10000 -b 0x4000". Replace supercidxxxxxxx.bin with the original name of downloaded file from step 9.
11. Wait 15-20 seconds and that is it. Reboot the phone and install the ROM you like
It works! I've got now 3.6.251.0_02.67.30 on my Qtek!
Thank's, damird, your guide is unreplaceble for such lamers like me
But maybe anyone can suggest me were can i find and how to install (if it possible) Russian t9 or only russian lang to input? Or maybe how to rollback to original ROM with this that lang... (1.02.261.1)
Thank's
added:
Problem's gone, Russian T9 added.
Damird!
Cheers mate
Hello, can you share with us this script to calculate CID area in StarTrek?
With this script we can SimUnlock the StarTrek very easy (at least I think...)
Thank you very much.
I'm confused here... is CID unlock not the same with SIM unlock?
my carrier is tmob but I'm getting cing 3125 at ebay so I need to SIM unlock the phone for it to work on tmob right?
wow, pof, I can't wait for it! i had bought one herald in China but wireless was disable by default. I hope I could unlock the CID and get a WWE rom to enable the wireless.
sokelut said:
I'm confused here... is CID unlock not the same with SIM unlock?
my carrier is tmob but I'm getting cing 3125 at ebay so I need to SIM unlock the phone for it to work on tmob right?
Click to expand...
Click to collapse
Correct, you still need to pay to carrier unlock the phone. Check the wiki for links to a few services that are known to work.
CID unlock? Error installing ROM
I'm getting an ERROR [294] INVALID VENDER ID
I did the CID unlock
It starts to install the rom but when it gets to 4% I get this error. How do i fix this?
Can anyone help?!
Need a little clarification
Im stuck in steps 3-11. I've downloaded itsutils and I don't know how to proceed.
I'm trying to use the RBMC command in the BL to extract the splash screens (as I couldnt find Orange-Israel splash screens anywhere).
I authenticated myself in the BL (btw, I have an exectuable that will do all that is written in POF's wiki). when I use the RBMC command:
rbmc d:\splash.nb 500e0000 40000
alot of garbge starts to flow to the screen in MTTY.
I guess MTTY doesnt saves the file automaticly.
Please help me dumping the Splash using this method (or any other method)
Capture the output with usb-monitor and convert it to binary file.
Pog, can you elaborate in this?
I used USB Monitor to log everything. Now I have a HEX and ASCII dump of every packet that cam from the TYTN. How do I save it into something usfull and how do I convert it to binary and then to BMP?
You can do it with unix command 'xxd' (included in vim) or with a simple C program (do a bucle in a shell script for every hex-char):
Code:
int main () {
unsigned int c;
unsigned char aux[10];
int s=read(0,aux,4);
sscanf(aux,"%x",&c);
printf ("%c",c);
return 0;
}
If you don't have access to a linux box, attach the dump here and I do it for you.
damnit, I wont have access to linux until next week...
I would appritiate your help in converting but I dont know if I did the dump correctly with USB Monitor.
First, it has several packakets with the commands I issued, than it has several LARGE packets with "junk" (I think thats the Splash screen dump).
However, I can export it to TXT and in TXT I see both the HEX and the ASCII part. Is that ok? If not, how do I dump the correct part?
knfevg said:
However, I can export it to TXT and in TXT I see both the HEX and the ASCII part. Is that ok? If not, how do I dump the correct part?
Click to expand...
Click to collapse
Yes this is correct. Attach the dump and if it is useful i make the splashscreens for u.
POF, attached is the zipped file with the TXT dump (in unicode).
It would be GREAT if you could help me.
If there is a need in some other kind of a dump, please let me know.
The dump is incomplete, you only dumped 24Kb, a whole splash screen should be at least 128Kb + 128Kb more of padding. Attached is the partial bin file.
mtty is not good for rbmc'ing... the best is to use linux 'cu' comand (included in uucp) like this:
Code:
((sleep 2 && echo rbmc file 500E0000 40000 ) | cu -l /dev/ttyUSB0 ) > dump.txt
POF,
I think I've attached the wrong file
I hope thats the correct one
there you go, splash in .nb and .bmp
pof said:
The dump is incomplete, you only dumped 24Kb, a whole splash screen should be at least 128Kb + 128Kb more of padding. Attached is the partial bin file.
mtty is not good for rbmc'ing... the best is to use linux 'cu' comand (included in uucp) like this:
Code:
((sleep 2 && echo rbmc file 500E0000 40000 ) | cu -l /dev/ttyUSB0 ) > dump.txt
Click to expand...
Click to collapse
Hi pof.
Have tried this too, but the dump.txt contains only 46 bytes. What's wrong.
mm... post the contents and we'll know
Probably it's failing because you have to authenticate to the bootloader prior to doing the rbmc command (or use a patched SPL which does not require it, for example latest HardSPL).
Pof, THANKS!!!!!
One more question.
The secondary splash is usualy the same as the prime?
What IS SubMain splash? When does it come up?
knfevg said:
The secondary splash is usualy the same as the prime?
Click to expand...
Click to collapse
Generally yes.
knfevg said:
What IS SubMain splash? When does it come up?
Click to expand...
Click to collapse
MainSplash - the one you see with the red letters at bottom when booting
SubSplash - the next one without red letters
If MainSplash and SubSplash are the same, you get the feeling that there's only 1 splash screen, but there are actually two
pof can you make me .bmp from dump?
I can xxd to hex but don't know what's next to got .bmp
Thanks
gromel said:
I can xxd to hex but don't know what's next to got .bmp
Click to expand...
Click to collapse
After you xxd the hex, the binary file you get is the actual splash.nb, so you can use nb_image_converter.exe to make a BMP, you can find it here:
ftp://xda:[email protected]/Hermes/Cooked_ROMs/Hermes_SplashScreen_Pack.zip
BTW, before using xxd you'll need to convert the dump from utf-8 to ascii.
If you can't manage to do it yourself, tell me and I'll do it for you.
Ah, now better understand.
But When I try iconv -f utf8 -t ascii dump -o output
then I got always error iconv: illegal input sequence at position 0
PS. In usb-monitor I can export as UNICODE or ANSI (ASCII).
I'm trying and trying and trying....
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://forum.xda-developers.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:-
Open serial port...OK
Connecting to the RIFF Box...OK
Firmware Version: 1.33, JTAG Manager Version: 1.44
Selected Resurrector: [Samsung E160K V1.0.4535.7001]
Connecting to the dead body...OK
Detected dead body ID: 0x105310E1 - IGNORED!
Set I/O Voltage reads as 1.79V, TCK Frequency is RTCK
Adaptive Clocking RTCK Sampling is: [Sample at MAX]
Resurrection sequence started.
Establish communication with the phone...OK
Initializing internal hardware configuration...OK
Uploading resurrector data into memory...OK
Starting communication with resurrector...OK
Detected an Initialized FLASH1 Chip, ID: 0x0015/0x0000 (KTS00M, 0x0003AB400000 Bytes = 14.68 GB)
Detected an Initialized FLASH2 Chip, ID: 0x0015/0x0000 (KTS00M, 0x000000200000 Bytes = 2.00 MB)
Flashing the dead body...OK
Resurrection complete!
Click to expand...
Click to collapse
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,
Code:
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
Code:
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 :-
Code:
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
Code:
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
Code:
auth_image
@[email protected]
@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
Code:
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
Code:
Partition 0
SBL1
SBL2
Partition 1
RPM
SBL3
eMMC APPSBoot
TZ
.PIT
Click to expand...
Click to collapse
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
CPU Boot order updates
So my digging has taken me back round to some of me early searching which i forgot about , hardware level seems to support the qualcom usb mode, but it can be disabled by manufacturer, so even if you find a resistor to the BOOT_CONFIG GPIO and ground it , it still may not work, and you could toast your board. once the qfuse is gone for that track, the maker can now use the gpio for anything else, it no longer controls the iROM branch choice ( CPU:do i start usb first or last?), it my thinking that on the first board sent out by the designers for a final production run ( those first public devices) they keep the option open to print off DEV models by changing the resistors/value of while the hardware stays same, not to be confused with dev board, that is pin/track simlar but is used to design the software mainly, sometimes hardware debug but as you change the hardware between the dev platform and production this is less helpful, google new.intrinsyc.com and apq8060, they produce a dev board that is the same as the device we hold, but everything is broken out for testing so don't expect to see this left in a bar for you to e-bay.
EDIT:
Above I refer to a dev phone and dev board, these are SURF and FFA, FFA is form factor accurate and SURF is Subscriber Unit Reference.
Here is the link, http://forum.xda-developers.com/showthread.php?t=1856327
Now from what i see, it's the same(edit:simlar) X0M pin setup as other phones, ground the right pin, reverse boot order, but this maybe two pins in the snapdragon,
[copied from other link]
Simplified table:
Code:
------------------------------------------------------------------
BC[5:0] Mapping
------------------------------------------------------------------
0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001 SDC3 followed by SDC1 (eMMC)
0b00010 SDC3 followed by SDC2 (if used)
0b00011 SDC1 (eMMC)
Click to expand...
Click to collapse
So if 0b00000 is EM boot and the docs say the the two gpio's that control this (if qfuse not blown) are taken high then it's 0b00011, so grounding those two resistors should give us 0b00000 or EM boot, the cpu docs also say they are internally grounded, the schematic says the voltage goes throught a 10k resistor, so grounding that side of the resistor that 'goes' to the cpu should change the boot order, but before trying this out, remember if you get the live side of the resistor the is no resistor between your probe and ground, that full current, short, blown, no more johnny 5.
Have you managed to unbrick the E160L?
darkspr1te said:
So my digging has taken me back round to some of me early searching which i forgot about , hardware level seems to support the qualcom usb mode, but it can be disabled by manufacturer, so even if you find a resistor to the BOOT_CONFIG GPIO and ground it , it still may not work, and you could toast your board. once the qfuse is gone for that track, the maker can now use the gpio for anything else, it no longer controls the iROM branch choice ( CPU:do i start usb first or last?), it my thinking that on the first board sent out by the designers for a final production run ( those first public devices) they keep the option open to print off DEV models by changing the resistors/value of while the hardware stays same, not to be confused with dev board, that is pin/track simlar but is used to design the software mainly, sometimes hardware debug but as you change the hardware between the dev platform and production this is less helpful, google new.intrinsyc.com and apq8060, they produce a dev board that is the same as the device we hold, but everything is broken out for testing so don't expect to see this left in a bar for you to e-bay.
Here is the link, http://forum.xda-developers.com/showthread.php?t=1856327
Now from what i see, it's the same(edit:simlar) X0M pin setup as other phones, ground the right pin, reverse boot order, but this maybe two pins in the snapdragon,
[copied from other link]
Simplified table:
Code:
------------------------------------------------------------------
BC[5:0] Mapping
------------------------------------------------------------------
0b00000 Emergency Boot from SDC3 (SD) followed by USB-HS
0b00001 SDC3 followed by SDC1 (eMMC)
0b00010 SDC3 followed by SDC2 (if used)
0b00011 SDC1 (eMMC)
So if 0b00000 is EM boot and the docs say the the two gpio's that control this (if qfuse not blown) are taken high then it's 0b00011, so grounding those two resistors should give us 0b00000 or EM boot, the cpu docs also say they are internally grounded, the schematic says the voltage goes throught a 10k resistor, so grounding that side of the resistor that 'goes' to the cpu should change the boot order, but before trying this out, remember if you get the live side of the resistor the is no resistor between your probe and ground, that full current, short, blown, no more johnny 5.
Click to expand...
Click to collapse
I think my E160L got a real brick today after I tried to flash a modified Rom downloaded from a Chinese forum. It can not be powered on after rebooting (installed successfully). I desperately need advice now on how to deal with it.
Jeff_GTA said:
I think my E160L got a real brick today after I tried to flash a modified Rom downloaded from a Chinese forum. It can not be powered on after rebooting (installed successfully). I desperately need advice now on how to deal with it.
Click to expand...
Click to collapse
Do you have any backups like nandroid ? does the 3 button boot still work ?
Regards
Have you looked into using ort-jtag. It's only about $150 (USD).
I've been looking into this myself for low-level debugging/bootloader development on SGH-T959V and SGH-I717.
All three of these devices are supported by ort-jtag and have header connectors for the jtag pins.
So I'm also getting some of these from digi-key, and making a small receptacle, much like in AdamOutler's captivate bootloader development thread. (search for k-ww)
Again, ort-jtag does support the SHV-E160L. (search that link for SHV-E160L)
PBL Dump - I think
So ive been doing some tests.
I think i managed to dump the PBL
i dumped memory and a strings search return this
Code:
pbl_error_handler.c
pbl_flash_nand.c
pbl_flash.c
dload.c
pbl_flash_nand.c
pbl_flash_onenand.c
pbl_auth\secboot_rsa_math.c
pbl_error_handler.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_auth.c
pbl_mc.c
pbl_mc.c
pbl_error_handler.c
and
Code:
qhsusb\src\dci\qhsusb_dci.c
}^PBL_DloadVER1.0
!8}^
}]^}^
Q`omm
z8}]
DEBUG
SW_ID
OEM_ID
pbl_flash_onfi.c
pbl_flash_nand.c
pbl_flash_sflashc.c
pbl_loader.c
pbl_flash_sdcc.c
pbl_auth.c
pbl_auth\secboot.c
pbl_auth\secboot_x509.c
QUALCOMM COPYRIGHT 2009BOOT ROM VERSION: 1.4QHSUSB VERSION: 00.00.08
BOOT ROM AUTHOR: DHAVAL PATEL
07 0000 SHA1
does any one want the dump that can reverse it ?
Dumps & execute address
I also need the help of other SHV-E160? owners, i need dumps from working phones, i managed to create a 8660_msimage.mbn and flashed it, but i was using i717 bootloaders and i dont think they will work, i need working dumps from working phones, starting with partition table layout, sbl1.mbn and sbl2.mbn
Does anyone know if the is is correct
SBL1 exec address 0x2A000000
SBL2 exec address 0x2E000000
as i can upload the sbl to 0x2a000000 but not the sbl2 to 0x2e000000
i can also upload the tz.mbn to 0x2a020000
i am trying to use sec boot 3 based call stack but am unsure of the real exec values
Ive seen in another post these values
"
It looks like ours deviates slightly from this.
If the headers are to be believed,
TZ is loaded at 0x2A000000
SBL3 is loaded at 0x8FF00000
APPSBL/aboot is loaded at 0x88E00000
"
the post is
http://forum.xda-developers.com/showpost.php?p=30057296&postcount=243
it does explain why i cant load into 0x2e000000
Progress
So today i made real progress, I have been able to flash a basic program to allow me to access the EMMC, i have taken a full backup and now i need to start scanning the dump for need information,
I still need help from other users so please if you are will to provide me dumps of your working device that would help me a great deal
So Part One is a sucess, I have been able to flash my own code and power on the galaxy note. next step is rebuilding the emmc partition tables, testdisk can find the partitions but is not alowing me to write a non standard partition table (which emmc seems to be formatted with)
Thanks
darkspr1te
help QPST Software Download
Hi,
I'm stuck with the same problem can you tell me what image you use to the phone. I stuck here. I' m really don't know what to do?
Thank you for your help.
tyllerdurdent said:
Hi,
I'm stuck with the same problem can you tell me what image you use to the phone. I stuck here. I' m really don't know what to do?
Thank you for your help.
Click to expand...
Click to collapse
First thing i must say is dont flash your phone just yet!! walking blindly into this could render your phone useless due to certain data being lost for good.
if you still wish to continue i will upload a basic guide and files. My method is still in development, it has many bugs ( i flashed the phone with i717 roms, working, SHV-E120 roms, working, N7000 rom complete fail)
But first some questions,
Which model phone is it?
what happened to get you to the point of needing the flash ? ( i ask so i can trace why the bricks are happening and hopefully fix it)
thank you for your help, I will be waiting your method and your files.
Thank you so much for your help.
My phone is a samsung galaxy note SHV-E160L korean version.
what happen was:
I tried to upgrade the firmware with kies and suddenly the program crash. My phone enter in an error issue with the firmware and said use emergency recovery mode.
I tried the recovery several times (uninstalling kies and install it again but that never work).
So, I download odin and this files to restore the original firmware:
CSC - GT-N7000-MULTI-CSC-OZSLPF.tar.md5
Phone - MODEM_N7000XXLR1_REV_05_CL1144476.tar.md5
Bootloader- N7000_APBOOT_N7000ZSLPF_CL558430_REV02_user_low_sh ip.tar.md5
PDA - N7000_CODE_N7000ZSLPF_CL558430_REV02_user_low_ship .tar.md5
Pit for 16GB - Q1_20110914_16GB.pit
I connect my phone and try to install the firmware again, but odin fail and my samsung became a nice brick.
The phone currently does not turn on, the phone is in download mode and I install QPST and the program recognize the system in download mode.
I want to try your method because other information I collected said that I have to send it to guarantee.
Can I install i717 rom in the E160L?
I will be waiting for your post because sincerely I don't know how to repair it.
Thank you so much.
Hello darkspr1te
First of all, nice work there (though I didn't understood most of the things there, but seems there is some good work going on on our SHV-E160's
On your comment;
( i flashed the phone with i717 roms, working, SHV-E120 roms, working, N7000 rom complete fail)
Does that mean that i717 roms can work on the SHV-E160 devices? Please share if that is the case.
The geeky bits
tyllerdurdent said:
Thank you so much for your help.
My phone is a samsung galaxy note SHV-E160L korean version.
what happen was:
I tried to upgrade the firmware with kies and suddenly the program crash. My phone enter in an error issue with the firmware and said use emergency recovery mode.
I tried the recovery several times (uninstalling kies and install it again but that never work).
So, I download odin and this files to restore the original firmware:
CSC - GT-N7000-MULTI-CSC-OZSLPF.tar.md5
Phone - MODEM_N7000XXLR1_REV_05_CL1144476.tar.md5
Bootloader- N7000_APBOOT_N7000ZSLPF_CL558430_REV02_user_low_sh ip.tar.md5
PDA - N7000_CODE_N7000ZSLPF_CL558430_REV02_user_low_ship .tar.md5
Pit for 16GB - Q1_20110914_16GB.pit
I connect my phone and try to install the firmware again, but odin fail and my samsung became a nice brick.
The phone currently does not turn on, the phone is in download mode and I install QPST and the program recognize the system in download mode.
I want to try your method because other information I collected said that I have to send it to guarantee.
Can I install i717 rom in the E160L?
I will be waiting for your post because sincerely I don't know how to repair it.
Thank you so much.
Click to expand...
Click to collapse
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
Code:
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)
Code:
import os
from struct import *
def mbr():
global offset, partitions
os.popen("adb shell su -c 'dd if=/dev/block/mmcblk0 of=/cache/partition0.bin bs=512 count=1'").close()
os.popen("adb shell su -c 'cp /cache/partition0.bin /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
f = open("partition0.bin", 'rb')
data = f.read()
f.close()
partitions = [ ]
n=0
while True:
buf = data[446+(16*n):446+(16*(n+1))]
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
partition['type'] = "MBR"
n += 1
partition['no'] = n
partitions.append(partition)
if partition['id'] == 5:
offset = partition['start']
break
def ebr():
global offset, partitions
n = 0
while True:
a = 0
os.popen("adb shell su -c 'dd if=/dev/block/mmcblk0 of=/cache/ebr bs=512 count=1 skip=" + str(offset+n) + "\'").close()
n += 1
os.popen("adb shell su -c 'dd if=/cache/ebr of=/cache/partition0.bin bs=512 count=1 seek=" + str(n) + "'").close()
os.popen("adb shell su -c 'cp /cache/ebr /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
f = open("partition0.bin", 'rb')
data = f.read()
f.close()
while True:
buf = data[446+16*a:446+16*(a+1)]
partition = dict(zip(('boot', 'id', 'start', 'size'), unpack('4I', buf)))
if partition['id'] == 5:
break
if partition['id'] == 0:
return
partition['type'] = "EBR"
partition['no'] = n
partition['start'] += n-1+offset
partitions.append(partition)
a += 1
if __name__ == "__main__":
mbr()
ebr()
os.popen("adb shell su -c 'cp /cache/partition0.bin /sdcard/partition0.bin'").close()
os.popen("adb pull /sdcard/partition0.bin .").close()
for part in partitions:
print "%s %2i, Boot: 0x%02X, Id: 0x%02X, Start: 0x%08X (%8i), Size: 0x%08X (%8i, %8i KB)" % (part['type'], part['no'], part['boot'],part['id'], part['start'], part['start'], part['size'], part['size'], part['size']/2)
Click to expand...
Click to collapse
beginning
thank you for your help,
I currently have the qpst version 2.7 build 373. You think is enough of download the same version of Chinese post QPST.2.7.374.rar
I will begin to download the other files required and I will be commenting my progress.
Thank you so much for your help, i really appreciate that you share you r knowledge.
Requests
While i try some theories if othe users could possibly provide me with :-
Original partition table via script above and also via adb
use
adb and run
Code:
cat /proc/partitions > /sdcard/partitions.txt
fdisk -l /dev/block/mmcblk0 > /sdcard/fdisklist.txt
mount > /sdcard/mountlist.txt
Then on the pc side using ADB again do the following
Code:
adb pull /sdcard/partitions.txt
adb pull /sdcard/fdisklist.txt
adb pull /sdcard/mountlist.txt
and post those files.
there are many posts on it so wont repeat but later will add a link.
along with some spell checks :laugh:
if you can dump the boot loaders from a original e160x too as my data started currupt.
i also need to talk to someone who can assist me in writing a program to take the pit file and turn it into this
Code:
<?xml version="1.0" ?>
<data>
<!--NOTE: Sector size is 512bytes-->
<program file_sector_offset="0" filename="" label="SMD_HDR" num_partition_sectors="65536" physical_partition_number="0" size_in_KB="32768.0" start_sector="1"/>
<program file_sector_offset="0" filename="sbl1.mbn" label="SBL1" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="65537"/>
<program file_sector_offset="0" filename="sbl2.mbn" label="SBL2" num_partition_sectors="3000" physical_partition_number="0" size_in_KB="1500.0" start_sector="66537"/>
<program file_sector_offset="0" filename="rpm.mbn" label="RPM" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="69559"/>
<program file_sector_offset="0" filename="sbl3.mbn" label="SBL3" num_partition_sectors="4096" physical_partition_number="0" size_in_KB="2048.0" start_sector="70559"/>
<program file_sector_offset="0" filename="aboot.mbn" label="ABOOT" num_partition_sectors="5000" physical_partition_number="0" size_in_KB="2500.0" start_sector="74655"/>
<program file_sector_offset="0" filename="" label="BOOT" num_partition_sectors="20480" physical_partition_number="0" size_in_KB="10240.0" start_sector="79655"/>
<program file_sector_offset="0" filename="tz.mbn" label="TZ" num_partition_sectors="1000" physical_partition_number="0" size_in_KB="500.0" start_sector="100135"/>
<program file_sector_offset="0" filename="partition0.bin" label="MBR" num_partition_sectors="1" physical_partition_number="0" size_in_KB="0.5" start_sector="0"/>
<program file_sector_offset="1" filename="partition0.bin" label="EXT" num_partition_sectors="22" physical_partition_number="0" size_in_KB="11.0" start_sector="69537"/>
</data>
Click to expand...
Click to collapse
*edit
the partiton0.bin provided below is 8.5kb (.5kb MBR, 8kb EBR) and in raw_program0.xml bove it say 0.5kb and 11kb, making that file 11.5kb, i dont know if the A810 has larger or smaller EBR than us, it could be they pulled extra, in my reading of the dumps i've seen lots of padded 0's after files (between sbl2/ebr/rpm) anyway if you just copy paste it will throw a error, ive got it set at 0.5 and 8.
EDIT:- Do not use this file, ive uploaded newer files later on.
some of the questions i need to answer are :-
1. what is the first partition, it's dos, around 105mb and labled smd_hdr and is filled with smd_hdr.bin (or mbn)
2. what are the real sector locations of the files, above you will see the rawpartiton0.xml file, this tells QPST where in the emmc to put the data num_partiton_sectors does match data from the pit files, but i dont know the real offsets yet, (samsung or htc could put the rest of the partiton table in cpu qfuse data areas and not write it to the emmc to confuse us and write the real files to another location and use the pit file as a base+offset calculation)
start_sector is the real location on the emmc, where it starts writing the file.
at the end is partiton locations(its a generic file containing the first few byes of default partition table, patch0.xml then updates this data), i dont have our device specific figures yet, i also dont fully understand patch0.xml and the difference in figures used.
if we have a backup of each of the different version of android partitons we could just write that in replacement of partiton0.bin and we dont need patch0.xml, this file sole job to alter the generic files, oem's have the choice of changing this data.
Code:
<?xml version="1.0" ?>
<patches>
<!--NOTE: This is an ** Autogenerated file **-->
<!--NOTE: Patching is in little endian format, i.e. 0xAABBCCDD will look like DD CC BB AA in the file or on disk-->
<!--NOTE: This file is used by Trace32 - So make sure to add decimals, i.e. 0x10-10=0, *but* 0x10-10.=6.-->
<patch byte_offset="506" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
<patch byte_offset="506" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
<patch byte_offset="458" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="16" value="NUM_DISK_SECTORS-1695744." what="Update final partition with actual size."/>
<patch byte_offset="458" filename="DISK" physical_partition_number="0" size_in_bytes="4" start_sector="208816" value="NUM_DISK_SECTORS-1695744." what="Update final partition with actual size."/>
</patches>
Click to expand...
Click to collapse
please note that it's two lines of the same code except one is partition0.bin and the other is DISK,
Do we need both? i know if i dont add the partiton0 section used in raw_program.xml then the drive is blank in linux,
now it's my understanding that the ebr comes as the forth partiton and it point to the next one , above in patch0.xml it start at NUM_DISK_SECTORS-1695744
i am still trying to better understand these figures,
Well time to grab coffee, i guess it's a dev night in.
the file MPRG8660.HEX can be renamed EMMCBLD.HEX and it triggers QPST to always look for a QDLoad mode phone and not debug, you can place all the files you need in one folder, i advise you to keep the originals in one location and only extract what your need to your worrking folder, copy emmcswdowload.exe from the QPST folder there too, we might need to do command line work, ive read that you can pre-create images in emmcswdownload (the same way 8660_msimage.mbn was created ) that you could just drop onto a phone once it's in emmc sd-card mode, almost a one click.
More info, plus help offered
Your welcome tyllerdurdent,
I am going to be putting a few hours into the dev from now actually for if you want assistance then no problems,
I also advise the following, download ubuntu live cd, it has a lot of tools your going to need to extract data you require, if we go step by step we might be good, i did a lot of test writing before i got my first boot, and that again only happens one in 20, i dont know why.
the rawpartiton0.xml above is incorrect for our devices as it states the first partion is 32mb, (i think it's ment to be amss.mbn, or NON-HLOS.mbn , our pit file which i did extract from my emmc dump says it's 105mb. i am confused and to why rawpartiton0.xml says the first bootloader is at start_sector="65537" but fdisk shows it as start 204801, i think someone needs to show me how to convert from blocks to sectors,
in patch0.xml it says
Code:
<patch byte_offset="506" filename="partition0.bin" physical_partition_number="0" size_in_bytes="4" start_sector="0" value="NUM_DISK_SECTORS-208801." what="Update MBR with the length of the EXT Partition."/>
Click to expand...
Click to collapse
208801 is where we have our ebr start,
i also think the IROM based pbl, sbl etc use the partition types in some way, why else have so many types? can any one explain that
this is a fdisk view of what i think our partition table looks like
Code:
Device Boot Start End Blocks Id System
/dev/sdb1 1 204800 102400 c W95 FAT32 (LBA)
/dev/sdb2 * 204801 205800 500 4d QNX4.x
/dev/sdb3 205801 208800 1500 51 OnTrack DM6 Aux1
/dev/sdb4 208801 208801 0 5 Extended
/dev/sdb5 212992 213991 500 47 Unknown
/dev/sdb6 221184 225279 2048 45 Unknown
/dev/sdb7 229376 234375 2500 4c Unknown
/dev/sdb8 237568 258047 10240 48 Unknown
/dev/sdb9 262144 263143 500 46 Unknown
/dev/sdb10 270336 271335 500 5d Unknown
/dev/sdb11 278528 279527 500 91 Unknown
/dev/sdb12 286720 307199 10240 93 Amoeba
/dev/sdb13 311296 511999 100352 c W95 FAT32 (LBA)
/dev/sdb14 516096 522239 3072 4a Unknown
/dev/sdb15 524288 530431 3072 4b Unknown
/dev/sdb16 532480 538623 3072 58 Unknown
/dev/sdb17 540672 741375 100352 8f Unknown
/dev/sdb18 745472 751615 3072 59 Unknown
/dev/sdb19 753664 759807 3072 5a Unknown
/dev/sdb20 761856 29843455 14540800 5b Unknown
/dev/sdb21 770048 790527 10240 ab Darwin boot
/dev/sdb22 794624 815103 10240 60 Unknown
/dev/sdb23 819200 839679 10240 94 Amoeba BBT
/dev/sdb24 843776 3911679 1533952 a5 FreeBSD
/dev/sdb25 3915776 8114175 2099200 a6 OpenBSD
/dev/sdb26 8118272 8736767 309248 a8 Darwin UFS
/dev/sdb27 8740864 9005055 132096 a9 NetBSD
/dev/sdb28 9011200 10035199 512000 95 Unknown
/dev/sdb29 10035200 30777343 10371072 90 Unknown
Oh, download wxdhex or wimlar program, you going to need a hex editor that can load BIG files , 16gb worth
i717-GB-Modem.zip IS THE SAME AS TAR?
i717-GB-Modem.zip 21.35 MB 7 0 2012-06-30 08:45:11
I could not find the i717-gb as tar file but I find it as a zip file. but I'm not sure about thif the contents are correct. Could you check
http://d-h.st/1aP
i717-GB-Modem.zip contents
META-INF
COM
GOOGLE
ANDROID
update-binary
updater-script
TMP
amss.bin
mdm.bin
Blocks and sectors
This may explain it , the different figure in the xml files
Because sectors are logical on the drive (Logical Block Addressing = LBA) you need to convert between LBA and physical (file system) sectors. This is pretty easy to do:
First - get a table of the start and end sectors of the partition table:
Code:
[[email protected] ~]# fdisk -lu /dev/hda
Disk /dev/hda: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders, total 234441648 sectors
Units = sectors of 1 * 512 = 512 bytes
Device Boot Start End Blocks Id System
/dev/hda1 * 63 208844 104391 83 Linux
/dev/hda2 208845 4401809 2096482+ 83 Linux
/dev/hda3 4401810 8482319 2040255 82 Linux swap
/dev/hda4 8482320 234436544 112977112+ 5 Extended
/dev/hda5 8482383 29447144 10482381 83 Linux
/dev/hda6 29447208 50411969 10482381 83 Linux
/dev/hda7 50412033 52516484 1052226 83 Linux
/dev/hda8 52516548 234436544 90959998+ 83 Linux
Use this to determine what partition the bad sector is in. In this case 232962120 is inside the start and end values for /dev/hda5
NOTE: This is in partition 5 - ignore partition 4 as it is the extended partition. Any block from partitions 5 through 8 will also be in partition 4, but you want the real partition, not the extended partition.
Next, calculate the file system block using the formula:
b = (int)((L-S)*512/B)
where:
b = File System block number B = File system block size in bytes (almost always is 4096) L = LBA of bad sector S = Starting sector of partition as shown by fdisk -lu and (int) denotes the integer part.
For example:
The reported sector from the smart log above is 232962120, thus:
((14858312 - 8482383) * 512) / 4096 = 796991.125
^Bad Sec. ^Start Sec. ^Cha Ching! This is the sector!
(Use the block number from the smart test section, not from the smart error log section. They are using different methods of reporting file system vs. physical blocks.)
((BadBLock - StartPartition) * 512) / 4096
You can just paste this into Google as a template
Any fraction left indicates the problem sector is in the mid or latter part of the block (which contains a number of sectors). Ignore the fraction and just use the integer.
Next, use debugfs to locate the inode and then file associated with that sector:
Click to expand...
Click to collapse
[[email protected]]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /dev/hda5
debugfs: icheck 796991
Block Inode number
796991 <block not found>
debugfs: quit
Ah! It didn't give the inode! It if did, you could have found the file with:
[[email protected]]# debugfs
debugfs 1.35 (28-Feb-2004)
debugfs: open /dev/hda5
debugfs: icheck 796991
Block Inode number
796991 41032
debugfs: ncheck 41032
Inode Pathname
41032 /S1/R/H/714197568-714203359/H-R-714202192-16.gwf
So what the heck? Why no inode? Well, remember how it said the sector might be bad?
Click to expand...
Click to collapse
the above copied from
http://timelordz.com/wiki/SMART_Rewriting_Bad_Sectors
i have a feeling we may need to shift our files (the basic files need to start odin are listed in rawpatch0 above, i dont know if that 100% true but it was the only files i wrote on by first sucess)
also
http://forum.xda-developers.com/showthread.php?p=31843525&postcount=13
in the above link they talk about the header of the qualcomm file
+------------+
|Dbl-preamble|
+------------+
|Dbl-header |
+------------+
|Dbl.bin |
+------------+
Click to expand...
Click to collapse
and
data_ptr = autodetectpage;
*data_ptr = sbl_header.codeword;
data_ptr++;
*data_ptr = sbl_header.magic;
data_ptr++;
*data_ptr = AUTODETECT_PAGE_SIZE_MAGIC_NUM;
Click to expand...
Click to collapse
now i used this in a way to find my bootloaders (i717 by this time, not shve-160l )
and to find the partitons
you will see in a hex editor at the start of each boot loader
something else to think about, my lack of success that last two days to produce a boot could be because my partitons are not clean , thats is to say if i write my sbl1 to 1000, and the trailing 0000 of the partition definition of my 99 block ebr/mbr ends at 999 , if i have dirt data between 999 and 1000 the cpu/pbl my interpret that as code(some of my boots is brick, some are into QDLoad, i have no pattern yet) , something i must test or confirm, or just worry about.
tyllerdurdent said:
i717-GB-Modem.zip 21.35 MB 7 0 2012-06-30 08:45:11
I could not find the i717-gb as tar file but I find it as a zip file. but I'm not sure about thif the contents are correct. Could you check
http://d-h.st/1aP
i717-GB-Modem.zip contents
META-INF
COM
GOOGLE
ANDROID
update-binary
updater-script
TMP
amss.bin
mdm.bin
Click to expand...
Click to collapse
Yes thats correct
updater script btw contains text, binary is the flashing exe i think,
Code:
run_program("/sbin/dd", "if=/tmp/mdm.bin", "of=/dev/block/mmcblk0p17");
run_program("/sbin/dd", "if=/tmp/amss.bin", "of=/dev/block/mmcblk0p13");
Click to expand...
Click to collapse
and a google of a simlar sansung product the skyrocket gives me a simlar pit layout
Device Name Size Part Name ODIN tar file Mount Point
mmcblk0boot0 512KB (empty) n/a (empty partition)
mmcblk0boot1 512KB (empty) n/a (empty partition)
mmcblk0p1 100MB SMD_HDR (partition info)
mmcblk0p2 500KB SBL1 sbl1.mbn
mmcblk0p3 1500KB SBL2 sbl2.mbn
mmcblk0p4 1KB (unnamed partition with '55 AA' MBR signature)
mmcblk0p5 500KB RPM rpm.mbn
mmcblk0p6 2MB SBL3 sbl3.mbn
mmcblk0p7 2500KB ABOOT aboot.mbn
mmcblk0p8 10MB BOOT boot.img
mmcblk0p9 500KB TZ tz.mbn
mmcblk0p10 500KB SSD n/a (empty partition)
mmcblk0p11 500KB PIT celox.pit
mmcblk0p12 10MB PARAM param.lfs
mmcblk0p13 98MB MODEM amss.bin /system/etc/firmware/misc
mmcblk0p14 3MB MSM_ST1 efs.img
mmcblk0p15 3MB MSM_ST2 n/a
mmcblk0p16 3MB MSM_FSG n/a
mmcblk0p17 98MB MDM mdm.bin /system/etc/firmware/misc_mdm
mmcblk0p18 3MB M9K_EFS1 efsclear1.bin
mmcblk0p19 3MB M9K_EFS2 efsclear2.bin
mmcblk0p20 3MB M9K_FSG n/a
mmcblk0p21 10MB DEVENC enc.img.ext4 /efs
mmcblk0p22 10MB RECOVERY recovery.img
mmcblk0p23 3MB FOTA n/a
mmcblk0p24 598MB SYSTEM system.img.ext4 /system
mmcblk0p25 2GB USERDATA userdata.img.ext4 /data
mmcblk0p26 302MB CACHE cache.img.ext4 /cache
mmcblk0p27 129MB TOMBSTONES tomb.img.ext4 /tombstones
mmcblk0p28 11.2GB UMS ums.rfs /mnt/sdcard
Click to expand...
Click to collapse
Other files
contents of the i717 boot loaders i used
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00
Code:
527K Jan 6 2012 aboot.mbn
115K Jan 6 2012 rpm.mbn
72K Jan 6 2012 sbl1.mbn
111K Jan 6 2012 sbl2.mbn
601K Jan 6 2012 sbl3.mbn
117K Jan 6 2012 tz.mbn
other files pulled from
ABOOT_SGH-I717M_I717MUGLA2_user_CL875155_REV00 (no bootloader but all the other system files )