Database Users

[UnBrickable Mod] Running Nexus S Bootloaders and hopefully porting AOSP the easy way

Hey guys, I've been interested in getting AOSP running on the Captivate, just like the NexusS. Since I now have an UnBrickable Phone, I figured I'd flash the firmware, but it didn't work. I need a new partition table. I found that the partitions are hidden within the bootloader image, so that didn't work... There is no direct upload without proper partitioning and the partition tables are not in the same format. I was talking to Rebellos and he said it would be possible... Then he came up with the mod out of the blue.
The linux commands used were as follows, the sleep is added so you can copy and paste.
Code:
sudo smdk-usbdl -f ./HIBL.bin -a D0020000
sleep 3
sudo smdk-usbdl -f ./nexus_sbl.bin -a 33040000
which loads the HIBL to memory address 0xD0020000 and the SBL to memory Address 0x33040000. At this point it is executed by the HIBL and....
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
All buttons worked properly! this means there is no work for volume+ volume - or power... There will probly be something else though.
I asked Rebellos to explain here so we can all learn something. I'm attaching the HIBL and the SBL to this post.
Warning: Since unlocking NexusS requires format of the MoviNAND and SDCard be prepaired to format all information on your phone, including EFS. Have a backup of all critical information.

Some general (and less-general) stuff about bootloaders analyse:
How to extract SBL from fused image?
(as the one in Nexus S, where IBL, PBL and SBL are together in bootloader.img)
Bootloaders are usually aligned to memory blocks of size like 4, 8, 16, 32KBs. The gaps between them are filled with 0x00 bytes.
SBL is the largest bootloader, so the thing is to open file in hex editor (personally I prefer XVI32), find the largest solid block of data and erase everything before first non-zero byte block. This way you've got Sbl.bin image.
Why is correct entry point (EP) of bootloader so important?
It comes out from ARM specification. Enough to say is that in most of cases code is non-relocatable
More info: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka3698.html
How to find correct bootloader EP?
In all SGS series SBLs I've seen so far EP is always written on 0x20 offset of SBL image, 32bit int in Little Endian notation.
Taking as example Nexus S SBL, in hex editor following bytes are:
Code:
00 00 04 33
So correct EP = 0x33040000
Way more complicated thing is when (as we can see in Samsung Waves) SBL (BL3) does not have entrypoint in file. Then it's mainly matter of correct analyse and some guessing.
Most of string pointers are stored and used in ARM assembly this way:
Code:
<code>
LDR R4, [some_string_ptr] ;this means LoaD Register (or Load Data Register) from given address, which means we are loading address of some_string
<code>
some_string_ptr DW some_string
some_string DB "string_example"
some_string_ptr will be valid pointer only when code is loaded into valid location (data stored under some_string_ptr doesn't change)
The fastest way is to load such code into any address in IDA disassembler, find few string pointers and see on which address are these pointing. Remember that LDR are also used to obtain CPU SFRs (Special Function Registers) addresses and constant data (this is matter of practice). Example:
We have loaded code under 0x10000000, some random LDRs taken from code:
LDR R0, 0x43000204
LDR R3, 0x12345678 ;looks like magic-const
LDR R8, 0xABCDABCD ;this one also
LDR R1, 0xFFFFFFFF ;looks like error return value or bit mask
LDR R1, 0xE0010000 ;doesn't match the rest, SFR probably (always keep CPU reference manual opened)
LDR R2, 0x43122508
LDR R0, 0x4311270A
LDR R0, 0x430F0100
The rest of LDR are in 0x43****** area, code entrypoint is usually aligned, as I said before, so first entrypoint try would be 0x43000000. You'll recognize you've got valid entrypoint by IDA properly matching strings X-refs to LDR instructions.
Example of code with invalid entrypoint:
Code:
TEXT:4148EA20 LDR R1, =0x42593D59
TEXT:4148EA24 MOV R0, R4
The same code, with valid entrypoint:
Code:
TEXT:4248EA20 LDR R1, =pSecBootFixedSeedKey ; "Fixed one for Samsung 3G platform. This"...
TEXT:4248EA24 MOV R0, R4
Got any more questions? Suggestions? Problems? Feel free to ask here or PM me.

First.
Pls post a bit more detailed instructns... would love 2 try this out wen my unbrickable cappy gets here n Monday.
Sent from my Transformer TF101 using XDA Premium App

psycho2097 where did you send yours to have it done at?

BloodSkin said:
psycho2097 where did you send yours to have it done at?
Click to expand...
Click to collapse
To me. You can also pm Connexion2005. He's done the mod as well.
Apparently the Nexus S works with odin, but it's not flashing for some reason... I was able to get the partition table here.. see attached file: http://forum.xda-developers.com/attachment.php?attachmentid=709328&stc=1&d=1315096743
Boot the nexus S bootloader as above, while holding VOL+ and VOL-, then use heimdall to download the part.pit.

AdamOutler said:
To me. You can also pm Connexion2005. He's done the mod as well. I'm still working with it..
Apparently the Nexus S works with odin, but it's not flashing for some reason... I was able to get the partition table here.. see attached file: http://forum.xda-developers.com/attachment.php?attachmentid=709328&stc=1&d=1315096743
Boot the nexus S bootloader as above, while holding VOL+ and VOL-, then use heimdall to download the part.pit.
Click to expand...
Click to collapse
Why not try Heimdall? Or have you already?

Kyuta Syuko said:
Why not try Heimdall? Or have you already?
Click to expand...
Click to collapse
I tried. read above.. I used heimdall to download the partition table... however there is a problem with heimdall's repartitioning ability.

Awesome, I love that someone is working on this and that AdamOutler is one of the ones leading the pack. You have done some great things on the development side of the Captivate and I know you actually work on these things instead of bringing the idea to light but never really going anywhere with it. I am very excited to watch the progress on this. Good luck.

AdamOutler said:
I tried. read above.. I used heimdall to download the partition table... however there is a problem with heimdall's repartitioning ability.
Click to expand...
Click to collapse
Guess I missed that last part. What kinda problem?

Kyuta Syuko said:
Guess I missed that last part. What kinda problem?
Click to expand...
Click to collapse
Not quite sure.. it seems to not be able to set the partition in stone. I contacted Benjamin Dobell about it. Its a problem with heimdall
This is a bit different though.. even Odin fails in this case. I am still working with it.

AdamOutler said:
Not quite sure.. it seems to not be able to set the partition in stone. I contacted Benjamin Dobell about it. Its a problem with heimdall
This is a bit different though.. even Odin fails in this case. I am still working with it.
Click to expand...
Click to collapse
I only asked because I personally prefer to use Heimdall over Odin. It's how I flash back to stock and how I flashed from 2.2 to 2.3 =|
Is it just the Windows version of Heimdall that has this problem or is it all variations? I use it on my laptop running Kubuntu since it likes to detect my phone better.

Kyuta Syuko said:
I only asked because I personally prefer to use Heimdall over Odin. It's how I flash back to stock and how I flashed from 2.2 to 2.3 =|
Is it just the Windows version of Heimdall that has this problem or is it all variations? I use it on my laptop running Kubuntu since it likes to detect my phone better.
Click to expand...
Click to collapse
I run Ubuntu primarily and I have all other platforms in virtual machines. It's a problem with Heimdall's ability to repartition.

AdamOutler said:
I run Ubuntu primarily and I have all other platforms in virtual machines. It's a problem with Heimdall's ability to repartition.
Click to expand...
Click to collapse
I figured you ran some Linux Distro =| Well at least I'm not experiencing any issues with my phone currently... Hope he gets that fixed soon. Sorry to derail the topic =/

I'm trying to flash some Nexus S firmware. Odin does not seem to work, it fails at repartitioning even with the part.pit I downloaded using Heimdall.... So I did some research and found that the device requires fastboot unlock or upload of firmware before I can unlock it for use with Odin...
To get Fastboot, i followed instrutctions on the Nexus S forums.... Instead of pushing power on, I simply held the proper key combination (Power + Volume up) while uploading the SBL.
I've never used fastboot and I can't quite figure out why it's not working. I see "FASTBOOT MODE" on my screen.
Here's what I see in my UART Debug window
Code:
��������������������������������������������������������������������������������
Uart negotiation Error
-------------------------------------------------------------
Hummingbird Interceptor Boot Loader (HIBL) v1.0
Copyright (C) Rebellos 2011
-------------------------------------------------------------
Calling IBL Stage2 ...OK
Testing DRAM1 ...OK
iRAM reinit ...OK
cleaning OTG context ...OK
Chain of Trust has been successfully compromised.
Begin unsecure download now...
0x00000000BL3 EP: 0x33040000
Download complete, hold download mode key combination.
Starting BL3 in...
Set cpu clk. from 400MHz to 800MHz.
IROM e-fused - Secure Boot Version.
-----------------------------------------------------------
Samsung Secondary Bootloader (SBL) v3.0
Copyright (C) Samsung Electronics Co., Ltd. 2006-2010
Board Name: HERRING REV 03 (JTAG)
Build On: Jan 20 2011 17:19:41
-----------------------------------------------------------
MMC MAG8DE 15264 MB
Re_partition: magic code(0xffffffff)
Muxed OneNAND 512MB (0x50) Sync
Scanning Bad Block .......
Bad Block 2047 (0)
Partitions loading success
Read image(PARAM) from flash .......
Done
init_fuel_gauge: vcell = 4193mV, soc = 100
PMIC_IRQ1 = 0xe8
PMIC_IRQ2 = 0x0
PMIC_IRQ3 = 0x1
PMIC_IRQ4 = 0x0
PMIC_STATUS1 = 0xc0
PMIC_STATUS2 = 0x2c
PMIC_STATUS3 = 0xff
PMIC_STATUS4 = 0xff
PMIC_STATUS5 = 0xff
PMIC_SMPL = 0x80
Key scan = 0x50
keypad_scan: handler name = fastboot
Check Power Key ... Skip!
BOOT_MODE_FASTBOOT (HW_RST(0x00000001), INFORM(0x00000000))
So that says I just booted into fastboot
I see this in the linux "lsusb" command
Code:
Bus 001 Device 122: ID 18d1:4e20 Google Inc.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x18d1 Google Inc.
idProduct 0x4e20
bcdDevice 1.00
iManufacturer 1 Google, Inc
iProduct 2 Android 1.0
iSerial 3 30325181F24700EC
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 32
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 50mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 66
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 66
bDeviceProtocol 3
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Connection timed out
Device Status: 0x0001
Self Powered
So obviously, it's detecting as a Google device now..
however...
Code:
[email protected]:~/Desktop/nexus firmware$ fastboot oem unlock
< waiting for device >
I can't seem to do the fastboot commands with this. Any ideas?

Dang just lost internet at work. I'm no pro but I saw a topic on the nexus section that seemed to indicate people had problems with this command in LiNux but running it in windows fixed the problem for about 3 people. Best of luck!
edit :internet back! here was the topic: http://forum.xda-developers.com/showthread.php?t=685449
Sent from my GT-I9000 using Tapatalk

The waiting for device command typically means it's not being seen correctly. Type fastboot devices and see if you see anything. Fastboot is what I'll be playing with when I return from the trip. Nexus S firmware is the purest Android experience possible on any phone. This would be a major breakthrough and more importantly, make the Captivate the first in line for Android updates just as the Nexus S is.
Also if fastboot works, it's very easy to make a one click Nexus S firmware installer with the flash all command fastboot has.

Awesome stuff.
Sent from my SGH-I897 using XDA Premium App

And now im back on stock
Sent from my SAMSUNG-SGH-I897 using xda premium

If you get the unbrickable mod to work on your phone then wouldn't you be able to flash a sense rom that has the same resolution as the galaxy s.
Sent from my GT-I9000 using XDA Premium App

ameedi600 said:
If you get the unbrickable mod to work on your phone then wouldn't you be able to flash a sense rom that has the same resolution as the galaxy s.
Sent from my GT-I9000 using XDA Premium App
Click to expand...
Click to collapse
Endless capabilities
Sent from my SAMSUNG-SGH-I897 using xda premium

CM7 MAC Address Fix

I could not post directly in the development thread as I joined simply to share my solution. If anyone can confirm and prepare a better guide please post to CM7 thread by whistelstop.
You will need your factory mac address.
MAC Addresses all being the same is due to the nvs_map.bin file required by the tiwlan driver. dmseg driver will tell you it is looking for it and defaulting mac address.
I am running CM7 mileage will vary in stock rom.
http://www.omappedia.org/wiki/Porting_MCP_WLAN_to_Android#TxBiP_Calibration
I used the calibration instructions in terminal emulator on cm7 Kindle as "su"
#wlan_cu –b
# / w p 1 l 2 f 2
# / t b v 21
# / t b t 1 0 0 0 0 0 0 0
#/ q
New nvs_map.bin file will be ceated in /data/misc/wifi/
#cp /data/misc/wifi/nvs_map.bin to /sdcard/nvs_map.bin
connect to linux/windows host copy file to pc
open with hex editor I used xvi32 for windows.
link to my source for instruction for byte order and editing.
http://processors.wiki.ti.com/index...ce_(CLI)_User's_Guide#Editing_the_MAC_Address
Short instructions:
Editing the MAC Address
After the TX BIP runs, there is a new file called nvs_map.bin in Linux that contains the MAC address and the calibration data. The document SWAA044_NVS_INI_File_Functions_AN.pdf contains the format of the NVS file. If MAC address fields are manually edited with a hex editor, the byte order should be low byte first, followed by the high byte:
MAC address low register (offset 0x01 to 0x02)
MAC address LSB (offset 0x3 to 0x06)
MAC address high register (offset 0x08 to 0x09)
MAC address MSB (offset 0x0A to 0x0D)
The MAC address LSB and MAC address MSB, respectively, are shown in bold in the
following code for 08:00:28:12:34:56:
0000: 01 6d 54 56 34 12 28 01 71 54 00 08
For 11:22:33:44:55:66:
0000: 01 6d 54 66 55 44 33 01 71 54 22 11 00 00
Using a hex editor, you should change the bold numbers to the MAC address you
want to use.
Be careful about byte order and look closely at examples.
Good Luck
Please confirm instructions yourself and use at your own risk

Just tried that and it worked beautifully!
Thanks for that - great find!

TheKid2 said:
I could not post directly in the development thread as I joined simply to share my solution. If anyone can confirm and prepare a better guide please post to CM7 thread by whistelstop.
You will need your factory mac address.
MAC Addresses all being the same is due to the nvs_map.bin file required by the tiwlan driver. dmseg driver will tell you it is looking for it and defaulting mac address.
I am running CM7 mileage will vary in stock rom.
As I can not post links you will need to google my text and find correct link (noob)
maybe a moderator can fix for me.
######.omappedia.org/wiki/Porting_MCP_WLAN_to_Android#TxBiP_Calibration
I used the calibration instructions in terminal as "su"
#wlan_cu –b
# / w p 1 l 2 f 2
# / t b v 21
# / t b t 1 0 0 0 0 0 0 0
#/ q
New nvs_map.bin file will be ceated in /data/misc/wifi/
#cp /data/misc/wifi/nvs_map.bin to /sdcard/nvs_map.bin
connect to linux/windows host copy file to pc
open with hex editor I used xvi32 for windows.
link to my source for instruction for byte order and editing.
##processors.wiki.ti.com/index.php/OMAP35x_Wireless_Connectivity_WL1271_Command_Line_Interface_(CLI)_User%27s_Guide#Editing_the_MAC_Address
Short instructions:
Editing the MAC Address
After the TX BIP runs, there is a new file called nvs_map.bin in Linux that contains the MAC address and the calibration data. The document SWAA044_NVS_INI_File_Functions_AN.pdf contains the format of the NVS file. If MAC address fields are manually edited with a hex editor, the byte order should be low byte first, followed by the high byte:
MAC address low register (offset 0x01 to 0x02)
MAC address LSB (offset 0x3 to 0x06)
MAC address high register (offset 0x08 to 0x09)
MAC address MSB (offset 0x0A to 0x0D)
The MAC address LSB and MAC address MSB, respectively, are shown in bold in the
following code for 08:00:28:12:34:56:
0000: 01 6d 54 56 34 12 28 01 71 54 00 08
For 11:22:33:44:55:66:
0000: 01 6d 54 66 55 44 33 01 71 54 22 11 00 00
Using a hex editor, you should change the bold numbers to the MAC address you
want to use.
Be careful about byte order and look closely at examples.
Good Luck
Please confirm instructions yourself and use at your own risk
Click to expand...
Click to collapse
I'll verify tomorrow. Thanks for taking the time to help run this to ground and get a workaround.

** Deleted **
For new driver only ....

so next cm7 build will get the fix
right?

As it was my first post forum would not allow me to post links I am hoping someone will clean up solution and add to development thread.

whistlestop said:
I'll verify tomorrow. Thanks for taking the time to help run this to ground and get a workaround.
Click to expand...
Click to collapse
love this rom , I have four of these running on my router now with original factory mac addresses, Thank You for your work. I know from personal experience hours and hours can just disappear when you get involved with a project of this type.

Is there a way to get the factory MAC address while still in CM7 or do I have to load the stock ROM to get it and then go back to CM7?

I have not found am method other than loading stock software back on device.
If you only have one kindle on your network you most likely will never have a problem.
If you had more than one running cm7 you could have router issues as they all were reporting same mac address. You will not have any issues unless another cm7 kindle shows up on the same wireless access point as yours.

Unless you have a router log or something with your former mac address, I think you have to reload stock to find it. Thats what I did anyway.
Thanks to the OP for posting this; worked like a charm!

direct editing
could we use a hex editor to change the local file on the kindle?
I spotted one at the market place, and combined with SU privileges it might get the job done.

jfb9301 said:
could we use a hex editor to change the local file on the kindle?
I spotted one at the market place, and combined with SU privileges it might get the job done.
Click to expand...
Click to collapse
any hex editor should work. I am so use to using laptop still adjusting to touch keyboard.

Hopefully better instructions
having just stumbled through to OPs instructions (hats off to the OP for finding this). Successfully I might add, I thought I'd write up a hopefully more clear method of achieving this.
As I have had difficulty with the adb.exe command (connection issues, probably from a dodgy connection if I have too many USB devices plugged in) I chose to use applications local to my Kindle itself for as much as I could.
Apps:
adb.exe (the one that came with Kindle_Fire_Utility worked for me) grab a copy of this useful tool here kindle fire utility thread
Root explorer from the android market android market link
HexEditor android market link
Kindle fire
Computer
Data:
Your original MAC address - this might suck to get, as you will have to get it from your Kindle booted to stock Kindle Fire Firmware. I had installed CM7 using TWRP, so I booted to TWRP did a backup of my current CM7 OS, did a restore to the KF OS, booted to stock(rooted) opened up settings/device and nabbed that pesky MAC address, rebooted to TWRP, restored CM7.
Instructions:
connect KF to computer
open the computers start menu and select run, type CMD in the box
navigate to kindle_fire_utility/tools
type command: adb shell
adb should open and start communication with you Kindle
within the shell you have to type the following (be mindful of the spaces as they are important, ignore the #s as they are to make this post put the spaces in):
#wlan_cu –b
# / w p 1 l 2 f 2
# / t b v 21
# / t b t 1 0 0 0 0 0 0 0
#/ q
now use ctrl-c to end ADB, and command:
exit
to close cmd, you are done with windows.
now the kindle part...
open root explorer
/data/misc/wifi
select nvs_map.bin and copy to the sdcard, I made two copies and named the second nvs_map.bin.bak just in case things got screwed from this point on.
exit root explorer
open HexEditor
open /sdcard/nvs_map.bin and change the digits in the very first line of the file
(example from OPs post)
following code for 08:00:28:12:34:56:
0000: 01 6d 54 56 34 12 28 01 71 54 00 08 00 00
For 11:22:33:44:55:66:
0000: 01 6d 54 66 55 44 33 01 71 54 22 11 00 00
save the file
use root explorer to copy it back to /data/misc/wifi
long press the file and set permissions to RW-RW-RW-
Reboot.....
Done
---------- Post added at 04:09 PM ---------- Previous post was at 03:11 PM ----------
I confimed MAC address using my wifi router (DDWRT) is awesome.
Does anyone know a way to get CM7 to cough up the kindles MAC address?

I'm having some difficulties with these instructions. I've tried with the WiFi setting from CM7 on and off, and also with the full instructions from the omappedia.org site, and it's still not working. A quick Google didn't come up with anything.
This is my output (from an ADB shell, obviously):
Code:
# insmod /system/etc/wifi/tiwlan_drv.ko
# start wlan_loader
# ifconfig tiwlan0 up
# wlan_cu –b
ERROR - IpcWpa_Sockets_Open - can't connect the socket
******************************************************
Connection to supplicant failed
******************************************************
ERROR - IPC_STA_Private_Send - error sending Wext private IOCTL to STA driver (ioctl_cmd = 800003, res = -1, errno = 19)
ERROR - driver is not in RUNNING state!
user_main, start
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, poWer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
/ D S
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, poWer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
.../Driver> Start, sTop, stAtus
ERROR - IPC_STA_Private_Send - error sending Wext private IOCTL to STA driver (ioctl_cmd = 8000001, res = -1, errno = 19)
ERROR - Failed to start driver!
I have tried it with and without the first three lines (going straight to wlan_cu -b), and the / D S line is an unsuccessful attempt to start the driver. An attempt to just push through all the commands gives an error message with every line, and does not create the nvs_map.bin file.
Anyone have any ideas?

I had wifi on, and did not run the first 3 commands. No thoughts beyond that.
For reference, I am on the latest CM7 with the updated video stuff by wistlestop (I think)

csyria6919 & jfb9301,
I can confirm, you'll get the errors csyria6919 gets with WiFi OFF - turn on Wifi on the KF and then the ADB commands work without errors.
VERY NICE Fix - +1 thanks to TheKid2!
~J

csyria6919 said:
I'm having some difficulties with these instructions. I've tried with the WiFi setting from CM7 on and off, and also with the full instructions from the omappedia.org site, and it's still not working. A quick Google didn't come up with anything.
This is my output (from an ADB shell, obviously):
Code:
# insmod /system/etc/wifi/tiwlan_drv.ko
# start wlan_loader
# ifconfig tiwlan0 up
# wlan_cu –b
ERROR - IpcWpa_Sockets_Open - can't connect the socket
******************************************************
Connection to supplicant failed
******************************************************
ERROR - IPC_STA_Private_Send - error sending Wext private IOCTL to STA driver (ioctl_cmd = 800003, res = -1, errno = 19)
ERROR - driver is not in RUNNING state!
user_main, start
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, poWer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
/ D S
\> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, poWer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
.../Driver> Start, sTop, stAtus
ERROR - IPC_STA_Private_Send - error sending Wext private IOCTL to STA driver (ioctl_cmd = 8000001, res = -1, errno = 19)
ERROR - Failed to start driver!
I have tried it with and without the first three lines (going straight to wlan_cu -b), and the / D S line is an unsuccessful attempt to start the driver. An attempt to just push through all the commands gives an error message with every line, and does not create the nvs_map.bin file.
Anyone have any ideas?
Click to expand...
Click to collapse
Hi,
I only used docs as reference. Wifi should be turned on on Kindle. I issued all command from terminal emulator running on Kindle. Hope you have found solution that works for you. Also there are spaces in between just about every letter in the commands.
Let us know if you were successful.

Hello,
I am hearing about cpu utilization issue in another thread. http://forum.xda-developers.com/showthread.php?t=1411895
Can anyone running cm7 and using nvs_map file check utilization connected to secure network. My installation is not exhibiting cpu behavior stuck at 1008 that is being described. Wondering if using calibration file is actually improving performance.
As a side not same file can be used in the current build of ics they are developing in that thread.
cpu scaling issue does not show up on unsecured net. Need a few people to sound off here to determine if my kindles are the only ones not having scaling issue.
Thanks

Is there somewhere in cm7 to check cpu utilization, I looked everywhere ended up downloading task manager from market. Seems like task manager, and performance monitor should be in there somewhere. I am sure I am overlooking something simple.
Thanks

TheKid2 said:
Is there somewhere in cm7 to check cpu utilization, I looked everywhere ended up downloading task manager from market. Seems like task manager, and performance monitor should be in there somewhere. I am sure I am overlooking something simple.
Thanks
Click to expand...
Click to collapse
I used your guide, got CM7 on my device and will check that once I get home.
To check CPU utilization I'd recommend CPU Spy https://market.android.com/details?id=com.bvalosek.cpuspy

[REF] GT-I9305 hardware hacking

Dear Hardware Hackers, Geeks and Modders,
it always takes some time for me to switch over to a "new" device
Recently i bought a GT-I9305 for cheap, to be more exactely bought two; a broken and a working one.
Anyway, as always i need to disassemble my toys, see what's inside and investigate how things work out on the hardware base.
To follow my descriptions and findings in this thread it is recommended to grab the service manual, e.g. at cpkb.org.
As usual there are already many technical threads covering some of the hardware issues.
It's time to put some light on the unknown details here.
Starting a few weeks ago there'd been some time for reverse engineering, study documents, read posts and draw some conclusions.
I hope you'll enjoy my discoveries and give some feedback.
It might take some time though to write down everything even more detailed and get it little bit structured to post it here.
SD-card mode or complete brick recovery by re-write internal bootloader:
The sboot bootloader is capable to start from external SD-card as well and detects the media it has been started from.
To re-write the bootloader in the internal eMMC, we need an external boot media and block the internal boot process at power up.
The SD-card needs a special structure with the sboot binary right in place.
There's already a detailed thread about this procedure (see the reference links below).
Anyway, as you might have read elsewhere, replacing KNOX bootloader with an older one will not work.
The first time a KNOX bootloader is installed on the device,
some hardware protected blocks on the eMMC become active to meet the requirements of the KNOX function.
This process could not be reverted by simply overwrite the sboot section.
We need other tools for this. This might be covered later.
Prevent booting from internal eMMC by blocking MMC_CMD:
GT-I9300:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R313
GT-I9305:
eMMC44_CH4: MMC_CMD is blocked by shorting the pull-up resistor R634
Please refer to the service manual for the correct position of the components.
Bootloader recovery will need some proof of concept, to be 100% certain that it works in the same way, as it does on GT-I9300.
SD-card booting by changing the CPU boot mode (permanently):
The boot code is set at power up by reading the logic level at special IO pins (XOM6:0).
These logic levels are set by a bunch of resistors and could be tweaked.
The boot modes for Exynos 4412 known so far:
Code:
XOM[5:1] : 1st device : 2nd device
5b'00010 : SDMMC_CH2 : USB
5b'00011 : eMMC43_CH0 : USB
5b'00100 : eMMC44_CH4 : USB
5b'10011 : eMMC43_CH0 : SDMMC_CH2
5b'10100 : eMMC44_CH4 : SDMMC_CH2
GT-I9305 (default, might need some approval by reading the registers):
Code:
XOM[5:1]
5b'10100 : eMMC44_CH4 : SDMMC_CH2
XOM0 : R612 10K PU
XOM1 : R614 100K PD
XOM2 : R615 100K PD
XOM3 : R609 10K PU
XOM4 : R616 100K PD
XOM5 : R610 10K PU
XOM6 : R617 100K PD
GT-I9305 (SD-card boot mode, needs testing!!!):
Code:
XOM[5:1]
5b'00010 : SDMMC_CH2 : USB
XOM0 : R612 10K PU (no change here)
XOM1 : R614 100K PD (no change here)
XOM2 : R615 10K PU (changed from PD to PU)
XOM3 : R609 100K PD (changed from PU to PD)
XOM4 : R616 100K PD (no change here)
XOM5 : R610 100K PD (changed from PU to PD)
XOM6 : R617 100K PD (no change here)
This relationship had been partly reverse engineered and concluded from other designs.
May need some approval though.
Same here, external booting from SD-card will need some proof of concept, to be 100% certain that it works without flaws.
There's a uncertainty concerning standard sboot, to allow a complete boot into system level (e.g. recovery) using a non default boot mode.
Maybe the code is bound to the device (internal eMMC only) in some way, or external SD-card is not fully supported as boot media.
Anyway, it is straight forward to build up a SD-card for testing.
The kernel boot parameter and parts of recovery image will need some tweaks to use the right device to boot from.
Direct access to Exynos 4412 debug UART:
The debug UART is permanently accessible on connector HDC401 (no need to block the USB port for this feature).
AP_TXD : HCD401, pin 11 (LVTTL 1.8V)
AP_RXD : HCD401, pin 17 (LVTTL 1.8V)
Please refer to the service manual for the position of connector HCD401.
These signals are fully tested and working.
The best would be to get the counter part of Panasonic AXE620124AW1 for a direct connection,
but this parts seems tobe hard to find.
As an alternative you'll need some very fine soldering iron and some tiny wires.
This way you could solder the wires directly to the pins of the connector.
You'll need some 1.8V level converter (+ USB UART) as already to be found in many projects.
Set up your terminal to 8N1 at 115200Bit/s and there you go.
E.g. enter S-Boot command line by hitting enter at boot up:
Code:
PMIC rev = PASS2(4)
cardtype: 0x00000007
SB_MMC_HS_52MHZ_1_8V_3V_IO
mmc->card_caps: 0x00000311
mmc->host_caps: 0x00000311
mmc_initialize: mmc->capacity = 30777344
Samsung S-Boot 4.0-1153417 for GT-I9305 (May 29 2013 - 17:22:39)
EXYNOS4412(EVT 1.1) / 2047MB / 15028MB / Rev 2 / I9305XXBME3
initialize_ddi_data: usable! (0:0x0)
PARAM ENV VERSION: v1.0..
init_fuelgauge: fuelgauge power ok
get_battery_detect: battery is missed
init_fuelgauge: battery is not detected, vcell(3858), soc(59)
init_fuelgauge: POR status
fuelgauge_por: POR start: vcell(3858), vfocv(3871), soc(59)
fuelgauge_por: update SDI M0 parameter
fuelgauge_por: RCOMP(0x0063), TEMPCO(0x0930)
fuelgauge_por: POR finish: vcell(3856), vfocv(3901), soc(55)
get_table_soc: vcell(3855) is caculated to t-soc(62.486)
init_fuelgauge: start: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_fuelgauge: finish: vcell(3855), vfocv(3898), soc(55), table soc(62)
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL1:0x00
init_microusb_ic: MUIC: CONTROL2:0x3b
init_microusb_ic: MUIC: CONTROL2:0x3b
PMIC_ID = 0x02
PMIC_IRQSRC = 0x00
PMIC_STATUS1 = 0x10
PMIC_STATUS2 = 0x00
PMIC_PWRON = 0x02
PMIC_IRQ1 = 0x0c
PMIC_IRQ2 = 0x00
s5p_check_keypad: 0x0
s5p_check_reboot_mode: INFORM3 = 0 ... skip
s5p_check_upload: MAGIC(0xc0c0c0c0), RST_STAT(0x10000)
microusb_get_attached_device: STATUS1:0x38, 2:0x00
s5p_check_download: 0
microusb_get_attached_device: STATUS1:0x38, 2:0x00
check_pm_status: chargable jig, LPM boot
AST_CHARGING..
cmu_div:1, div:7, src_clk:800000000, pixel_clk:57153600
s6e8ax0_read_id :: retry: 1
s6e8ax0_read_id :: 0xd1
<start_checksum:373>CHECKSUM_HEADER_SECTOR :4096
<start_checksum:375>offset:50, size:6296
<start_checksum:379>CHECKSUM_HEADER_INFO : NeedChecksum:0 PartNo:20
Not Need Movinand Checksum
Movinand Checksum Confirmation Pass
autoboot aborted..
S-BOOT #
S-BOOT # help
Following commands are supported:
* chipinfo
* help
* log
* reset
* boot
* load_kernel
* printenv
* setenv
* saveenv
* findenv
* checksum_need
* usb
* upload
* keyread
* readadc
* usb_read
* usb_write
* sdcard
* mmcdtest
* fuelgauge
To get commands help, Type "help <command>"
S-BOOT #
That's it by now!
Consider this as a starter, i'll try to add, correct or change some things from time to time and i hope it's human readable
Please give me some feedback or tell me your thoughts
I will add pics as soon as possible and further details if there's some interest.
I will also give some credits soon, because some of these findings are based on information from the curious around here
Credits:
AdamOutler
E:V:A
References:
GT-I9300 hard-brick-fix
http://forum.xda-developers.com/galaxy-s3/general/galaxy-s-iii-gt-i9300-hard-brick-fix-t1916796
Totally Revolutionary SDCard Bootloader For Galaxy S III
http://forum.xda-developers.com/galaxy-s3/general/totally-revolutionary-sdcard-bootloader-t2061437
Port SDCard Recovery to Other Exynos4412 Devices
http://forum.xda-developers.com/showthread.php?p=34732948
Knox reset
http://forum.xda-developers.com/showthread.php?t=2504258
eMMC sudden death research
http://forum.xda-developers.com/showthread.php?t=2096045
NOTE:
I am not responsible for any damaged devices.
The technical information may need some verification by experiments!
It would be nice to add a remark and refer to this post, if you use the pics and information from this thread :highfive:
Cheers,
scholbert

technical info, datasheets... stuff
eMMC function, structure and usage
1. Basic info
The onboard eMMC is the mass storage of our device.
There's much more under the hood, than you might expect and notice during normal usage within the OS.
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
If you upgraded to JB/KK bootloder another part is setup up and configured:
RPMB (KNOX counter, etc.)
I found no information about the size, but it's a multiple of 128K and may be set up between 128-512K.
Once activated the information stored in this area is controlled by internal security mechanism of eMMC.
Only trusted code is granted access and even worse, from a users sight it acts like OTP memory.
To get some info about the eMMC built in your device the sysfs entries are a good place to start.
We could grep the type of device form here, e.g. the eMMC in my GT-I9305 gives this output:
Code:
# cd /sys/class/block/mmcblk0/device
# cat name
MAG4FB
# cat manfid
0x000015
# cut -b 19,20 cid
f7 // this is the firmware revision in hex
# cat date
09/2012
See the datasheet attached (this is the exact part)
2. EFI partition and GPT
The first block of USER area of starts with traditional MBR.
Next block starts with the header for the EFI partition which is the base container for all other parts.
Code:
[SIZE="2"]45 46 49 20 50 41 52 54 Signature "EFI PART"
00 00 01 00 GPT version 1.0
00 02 00 00 header size 512 Bytes
5B DF 6D 84 CRC32 of header
00 00 00 00 reserved
01 00 00 00 00 00 00 00 Current LBA (location of this header copy)
FF 9F D5 01 00 00 00 00 Backup LBA (location of the other header copy)
22 00 00 00 00 00 00 00 First usable LBA for partitions (primary partition table last LBA + 1)
DE 9F D5 01 00 00 00 00 Last usable LBA (secondary partition table first LBA - 1)
41 4E 44 52 4F 49 44 20 4D 4D 43 20 44 49 53 4B ANDROID MMC DISK
02 00 00 00 00 00 00 00 Starting LBA of array of partition entries (always 2 in primary copy)
80 00 00 00 Number of partition entries in array
80 00 00 00 Size of a single partition entry (usually 128)
28 53 B2 A4 CRC32 of partition array
00 00 00 00[/SIZE]
The rest of this block is the GPT.
Reference:
http://en.wikipedia.org/wiki/GUID_Partition_Table
Other useful reading:
http://forum.xda-developers.com/showpost.php?p=31254495
3. PIT
This is another essential part of the USER area of eMMC and defines all partitions used by the OS.
Here's the definition of the internal structure:
Code:
[SIZE="2"]typedef int __s32;
typedef unsigned int __u32;
#define PARTITION_MAGIC 0x12349876
typedef struct _partition_header {
__u32 dwMagic; /* MAGIC CODE */
__s32 nCount; /* PARTITION (OneNAND + MOVINAND) */
/* PIT Option. */
__s32 dummy[5];
} __attribute__((packed)) partition_header;
typedef struct _partition_info {
__s32 nBinType; /* BINARY_TYPE_ (AP or CP?) */
__s32 nDevType; /* PARTITION_DEV_TYPE_ */
__s32 nID; /* PARTITION ID */
__s32 nAttribute; /* PARTITION_ATTR_ */
__s32 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
__u32 dwBlkSize; /* BLOCK SIZE / OFFSET IN BLOCKS */
__u32 dwBlkLen; /* BLOCK LENGTH */
__u32 dwOffset; /* FILE OFFSET (obsolete) */
__u32 dwFileSize; /* FILE SIZE (obsolete) */
char szName[32]; /* PARTITION NAME */
char szFileName[32]; /* FILE NAME */
char szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
} __attribute__((packed)) partition_info;[/SIZE]
Example:
Code:
[SIZE="2"]BOOTLOADER:
00 00 00 00 nBinType; /* BINARY_TYPE_ (AP or CP?) */
02 00 00 00 nDevType; /* PARTITION_DEV_TYPE_ */
50 00 00 00 nID; /* PARTITION ID */
02 00 00 00 nAttribute; /* PARTITION_ATTR_ */
01 00 00 00 nUpdateAttr; /* PARTITION_UPDATE_ATTR_ */
00 00 00 00 dwBlkSize; /* BLOCK SIZE / BLOCK OFFSET */
C6 06 00 00 dwBlkLen; /* BLOCK LENGTH */
00 00 00 00 dwOffset; /* FILE OFFSET (in TAR) */
00 00 00 00 dwFileSize; /* FILE SIZE */
szName[32]; /* PARTITION NAME */
42 4F 4F 54 4C 4F 41 44 45 52 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szFileName[32]; /* FILE NAME */
73 62 6F 6F 74 2E 62 69 6E 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
szDeltaName[32]; /* DELTA FILE NAME FOR BOOTLOADER FOTA */
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00[/SIZE]
4. Complete partition table (GT-I9305)
Code:
[SIZE="2"]Block Size = 0x200
BOOT AREA:
Partition Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
BOOTLOADER sboot.bin 0x00000000 0x06C6 0x000D8C00 0x50 0x50
TZSW tz.img 0x000D8C00 0x0138 0x00027000 0x51 0x51
DDI-DATA (DATA) - 0x000FFC00 0x0001 0x00000200
USER AREA:
Partition Name Image Name OFFSET LEN in BLK LEN OS Partition Physical Partition
eMMC MBR (MBR) - 0x00000000 0x0001 0x00000200
EFI PART (GPT) - 0x00000200 0x0001 0x00000200
PIT m3.pit 0x00004400 0x0010 0x00002000 0x46 0x46
MD5HDR md5.img 0x00006400 0x0800 0x00100000 0x47 0x47
BOTA0 - 0x00400000 0x2000 0x00400000 0p1 0x01
BOTA1 - 0x00800000 0x2000 0x00400000 0p2 0x02
EFS efs.img 0x00C00000 0xA000 0x01400000 0p3 0x03
m9kefs1 m9kefs1.bin 0x02000000 0x2000 0x00400000 0p4 0x04
m9kefs2 m9kefs2.bin 0x02400000 0x2000 0x00400000 0p5 0x05
m9kefs3 m9kefs3.bin 0x02800000 0x2000 0x00400000 0p6 0x06
PARAM param.bin 0x02C00000 0x4000 0x00800000 0p7 0x07
BOOT boot.img 0x03400000 0x4000 0x00800000 0p8 0x08
RECOVERY recovery.img 0x03C00000 0x4000 0x00800000 0p9 0x09
RADIO modem.bin 0x04400000 0x2c000 0x05800000 0p10 0x0A
TOMBTONES tombstones.img 0x09C00000 0x80000 0x10000000 0p11 0x0B
CACHE cache.img 0x19C00000 0x200000 0x40000000 0p12 0x0C
SYSTEM system.img 0x59C00000 0x300000 0x60000000 0p13 0x0D
HIDDEN hidden.img 0xB9C00000 0x118000 0x23000000 0p14 0x0E
OTA - 0xDCC00000 0x4000 0x00800000 0p15 0x0F
USERDATA userdata.img 0xDD400000 0x0000 0p16 0x10
[/SIZE]
5. DDI-DATA
In the hidden boot0 partition the values like the flash count are stored.
Triangle away is able to modify this data.
It's stored at 0x000FFC00 on the boot0 partition of emmc.
Code:
struct ddi_data {
int magic; // must be 0x12340012
int custom_flash_count;
int odin_count;
int binary_type; // 0 = samsung official, 1 = custom, 2 = "Unknown"
char model_name[16];
int rom_type; // this is the first 4 bytes of the decrypted 16 bytes
in the param partition. 0xFF000000 = samsung, 0xEE000000 = custom }
For details please refer to this post:
http://forum.xda-developers.com/showthread.php?p=28953690#post28953690
Further useful reading:
http://wiki.cyanogenmod.org/w/EMMC_Bugs
Thesis:
Remove KNOX bit by eMMC low level format command:
With KNOX activation at booloader level, there's an area which stores the KNOX bit information called RPMB.
During research of the eMMC sudden death, some firmware files for the eMMC controller had been reverse engineered and some of the custom commands had been discovered.
Read this and follow ups:
http://forum.xda-developers.com/showpost.php?p=49548099&postcount=121
By changing the boot mode and boot up completely from SD-card into special recovery, it might be possible to send this command with a tool called mmc-utils:
https://github.com/BenGardiner/mmc-utils
Because this will wipe out everything, it would be a great adventure and you'll need a proper backup of all significant parts from the internal eMMC. Otherwise device specific parameters will be lost forever.
See this remark as a reference as well:
http://forum.xda-developers.com/showpost.php?p=51297844&postcount=135
I'll spent some time to think about a useful SD-card layout... :laugh:
TBC
scholbert

All this looks knowledgeable
How are you at ROM/Kernel building?

Hi f0xy!
f0xy said:
All this looks knowledgeable
Click to expand...
Click to collapse
Thanks for this feedback!
I know these experiments are only for the fearless with good eyes.
For the average user there's no need to hack boot mode or stuff, unless there's some evil bricked device
I guess folks need pix
f0xy said:
How are you at ROM/Kernel building?
Click to expand...
Click to collapse
Depends...
On a hobbyist level i build many kernels, tweaked drivers and kernel code for personal use over the years.
Little less if we speak about building ROMs.
I might help out on some issues, but don't count on me for bigger projects.
Time is always lacking and often i'm too lazy to clean up the code for git
Cheers,
scholbert

Hi,
just added the complete partition table for GT-I9305 and some other stuff in the second post...
I try to sum up facts floating around as well and put it in the context of GT-I9305, so some info here is no breaking news
Anyway, enjoy the tech ride!
Regards,
scholbert

@mad_ady I seen your post in boeffla, some info here may be of help? Or maybe the @op can provide some help for you?
Regards

Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?

Hi mad_ady!
mad_ady said:
Thanks for the references. It helped me better understand where the partitioning information is kept. I didn't know our devices (I own a GT-9300) had a MBR/GPT table. I wonder, do other (non-samsung) devices use similar partitioning schemes? Or are there also other ways of keeping the partition layout that are in use?
Click to expand...
Click to collapse
Yeah i guess other devices with onboard eMMC use GPT tables as well.
Though it is not completely clear at which level these are accessed.
I assume that the bootloader or even kernel is able to read this table during start up and is also aware of the sizes and boundaries.
The PIT table plays another role in this game.
AFAIK this is the reference for Odin/Heimdall and should match GPT boundaries.
Some experts are needed to confirm this or i'll have to dig a little deeper myself
Regards,
scholbert

Hi there,
i made a comparison between the cmdline passed to the kernel by "old" and "new" bootloaders.
Just started some investigation to fix "offline charging" with KK stock running on devices which still got the old bootloader.
Here's the default cmdline "old" vs. "new":
Code:
[SIZE="2"]JB 4.1.2 (I9305XXBME3) KK 4.4.4 (I9305XXUFNJ1)
console=ram console=ram
loglevel=4 loglevel=4
androidboot.baseband=mdm androidboot.baseband=mdm
sec_debug.level=0 sec_debug.level=0
sec_watchdog.sec_pet=5 sec_watchdog.sec_pet=5
androidboot.debug_level=0x4f4c androidboot.debug_level=0x4f4c
[email protected] [email protected]
- [email protected]
- [email protected]
s3cfb.bootloaderfb=0x5ec00000 s3cfb.bootloaderfb=0x5ec00000
lcdtype=96 lcdtype=96
consoleblank=0 consoleblank=0
lpcharge=0 -
lpj=3981312 lpj=3981312
vmalloc=144m vmalloc=176m
oops=panic oops=panic
pmic_info=67 pmic_info=67
cordon=<32-Byte hash value> cordon=<32-Byte hash value>
- connie=GT-I9305_OPEN_EUR_<32-Byte hash value>
androidboot.emmc_checksum=3 androidboot.emmc_checksum=3
- androidboot.boot_salescode=
- androidboot.odin_download=1
androidboot.bootloader=I9305XXBME3 androidboot.bootloader=I9305XXUFNJ1
- androidboot.selinux=enforcing
- androidboot.warranty_bit=1
- androidboot.sec_atd.tty=/dev/ttySAC2
androidboot.serialno=<16-Byte serial> androidboot.serialno=<16-Byte serial>
snd_soc_core.pmdown_time=1000 snd_soc_core.pmdown_time=1000[/SIZE]
As you might see there's the keyword lpcharge, which is not present on the "new" bootloaders.
On the new bootloaders there's the additional parameter android.bootmode=charger, if you start up with a charger plugged in.
On KK stock some proprietary binaries identify this keyword to activate offline charging.
Some kernel drivers (battery) react to this string as well and there's a patch already.
There'd been some attempts to fix this in initial ramdisk by hi-jacking cmdline present in /proc/cmdline and replace lpcharge=1 with android.bootmode=charger .
My first idea was, to make use of a similar function at kernel level and append android.bootmode=charger to the "old" bootloader cmdline, if lpcharge is set to 1 (similar to a conditional CONFIG_CMDLINE_EXTEND function).
The kernel itself will put this in /proc/cmdline afterwards and user space tools will be satisfied.
Some years ago i tweaked some kernel code for Archos tablets, which made use of custom ATAG keys to hand over some device specific parameters. Maybe i'll get something out of it
For my personal reference:
http://forum.xda-developers.com/galaxy-tab-3/general/kitkat-t31x-t2892792/post55863790#post55863790
TBC
Cheers,
scholbert

Hello.
Thanx for your Thread. For some summary about I9300 and I9305.
:good:
Please I need some input for my low brain...
I'm playing with I9300 and Tizen RD-PQ stuff...
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Thanx for every input.
Best Regards

The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n

Hi!
adfree said:
My questions.
How to dump whole mmcblk0 ? Without direct eMMC Hardware...
Maximum 11 GB I can dump in internal sdcard...
http://forum.xda-developers.com/showpost.php?p=59503847&postcount=14
If I try to dump to external SD... I can only dump 4 GB...
Click to expand...
Click to collapse
See mad_ady's comment:
mad_ady said:
The 4GB is a FAT32 limitation. You can try to format your external SD to ext3 or you can try to mount (via CIFS/NFS) a remote storage on which to dump.
Or, you can dump the device in blocks, starting with a specific offset and having a specific length:
http://superuser.com/questions/3807...m-the-specified-offset-but-not-dd-bs-1-skip-n
Click to expand...
Click to collapse
From kernel level it is only possible to dump user area (unless you use a specific kernel with mmcblk0boot0 and mmcblk0boot1 enabled).
Read again this quote form my second post:
The area we may access from within Android OS is called USER area (all partitions belong to this area).
This part could be easily accessed and you may back up all data of this area to a disk image.
Apart from that, the eMMC is used as secure boot media.
On some of the ICS kernels there was a block device called /dev/mmcblk0boot0 (protected by ro-flag).
This device node is missing on most of the S3 devices and hence it is not possible to access this part.
Anyway, it is hidden area where Samsung placed the bootloader and stuff, the BOOT area.
If you are using still ICS bootloader it consists of at least 2 parts:
2MB area for BL1 (s-boot+TZSW+ddi-data)
2MB area for BL2 (not used, zeroed out)
Click to expand...
Click to collapse
adfree said:
RD-PQ sboot seems to work with I9300...
RD-PQ dump shows uboot at address 0x10000 and Tizen PIT is at 0x8000...
Tizen 32 MB dump for study...
http://forum.xda-developers.com/showpost.php?p=55514573&postcount=36
Click to expand...
Click to collapse
Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
adfree said:
My theory... sboot is maybe at end of eMMC...
I can only check if I dump whole eMMC...
Click to expand...
Click to collapse
Nope... it's at the very start of eMMC in a seperate area, normally hidden from user (see my comments above).
See datasheet attached, maybe this helps to understand how eMMC works.
EDIT:
Found the exact part which is soldered on my GT-I9305 mainboard.
See second post for reference as well:
http://forum.xda-developers.com/showpost.php?p=56747098&postcount=2
I'll leave this older datasheet her as well... this is at least a similar part.
Good luck and best regards,
scholbert

Interesting geek stuff... did you made any progress here, e.g. booting with RD-PQ?
Click to expand...
Click to collapse
I have problems to check my progress... because broken/damaged Display...
I see only black...
In Android I can use ADB stuff to see something...
Writing 32 MB RD-PQ dump not kill I9300... (no idea if this could kill IMEI, EFS or other Security stuff)
But I can't see where it hangs or if something is on Display...
Writing only s-boot-mmc.bin (200 KB sboot) from RD-PQ...
I have no idea yet, how to check if really written or ignored by I9300 sboot...
Code:
getprop ro.bootloader
Gives no anwser...
And this feature looks like Kernel related stuff...
Example why I am unsure if 200 KB sboot is accepted...
In I9300 you can find easily string ODIN in sboot...
But in RD-PQ is no ODIN text string... then why my I9300 works without problems with Odin...
I need some time to buy cheap working Display...
So I can see "visual effects" on Display...
1 goal would be this:
SDCARD MODE
COPY BINARY FROm SDCARD..
COPY BINARY TO EMMC..
SDCARD DOWNLOAD COMPLETED.
Click to expand...
Click to collapse
In Tizen world it seems mandatory to restore uboot... it contain the THOR string for THOR Downloader...
https://lists.tizen.org/pipermail/general/2013-November/002707.html
For me it is not clear enough... if RD-PQ sboot loads uboot...
sboot AND uboot is executed...
OR it is or feature...
Only uboot could be enough to executed...
About dump mmcblk0...
Code:
dd if=/dev/block/mmcblk0 skip=0 count=10000000 of=/sdcard/dump_v1.bin
dd if=/dev/block/mmcblk0 skip=10000000 count=10000000 of=/sdcard/dump_v2.bin
dd if=/dev/block/mmcblk0 skip=20000000 of=/sdcard/dump_v3.bin
This seems to work... but last 1 is again 11 GB + big...
It starts after with beginning...
I need proper count value... need some time and calculator...
I hope next week I have working Display for my testdevice...
Best Regards

eMMC hacking.... SD card boot... remove KNOX bootloader... finally?
Hi again,
i'd like to refer to a software package which seems to have leaked from a service center or similar some time ago.
Please refer to this thread, which explains how to revive hard bricked S3 devices and other Exynos devices:
http://forum.xda-developers.com/galaxy-s3/general/samsung-s3-i9300-note2-n7100-i9500-s4-t2647558
I found this package at several other places in the web as well, and it might be useful for some smart experiments :angel:
Here's what i got from it...
S3 repair contains a test suite for low level tests and tasks to setup up S3 from scratch.
You'll have to prepare a MicroSD card with a low-level tool (similar to dd command in linux).
The write script gives an idea about the offsets used on the SD card (multiples of 512 bytes), so i translated those to hex values:
emmc_auto.sbl.bin:1:499OFF: 0x00000200 LEN: 0x0003e600
E4412_S.TN.bl1.bin:9500:16OFF: 0x004a3800 LEN: 0x00002000
S5E4412_asb.bin:20000:40000OFF: 0x009c4000 LEN: 0x01388000
asb.ramfs:80000:97000OFF: 0x02710000 LEN: 0x02f5d000
From what i got by investigating the hex data of these binaries, the functions should be:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- S5E4412_asb.bin -> a standalone tool and testsuite compiled as a ready to run binary (no elf format here!)
- asb.ramfs -> a proprietary RMFS formatted ramdisk which carries some test files (e.g. test pattern, test videos, etc.)
A quite interesting piece of code is the S5E4412_asb.bin file.
So grepping some strings in this binary file gave this section, which is responsible for
vendor boot size change with CMD62 (refer to the eMMC datasheet as well) and seems to restore the bootloaders:
Code:
0x093DB6 0x2B APP STEP] Step 1. BL Download Address Set
0x093DE6 0x2D APP STEP] Step 2. DRAM Download Address Set
0x0943CA 0x0A NA,\NA0\NA
0x0943D6 0x0A NA$\NA(\NA
0x0943FE 0x2D APP STEP] CMD 0xEFAC62EC : RESPONSE 0x%08x %
0x094432 0x2B APP STEP] CMD 0xCBAEA7 : RESPONSE 0x%08x %
0x094462 0x32 APP STEP] Boot Partition Size : RESPONSE 0x%08x %
0x09449A 0x32 APP STEP] RPMB Partition Size : RESPONSE 0x%08x %
0x09472A 0x24 APP STEP] CMD 6 : RESPONSE 0x%08x %
0x094756 0x2B APP STEP] BL1 & BL2 loading Address : 0x%x
0x094786 0x2C APP STEP] Dram Image loading Address : 0x%x
0x0947B6 0x34 APP STEP] BL1 & BL2 compare address for Read : 0x%x
0x0947EE 0x35 APP STEP] Dram Image compare address for Read : 0x%x
As user Oranav pointed out in the eMMC sudden death research thread, there might be commands
which should initiate low level formatting of the eMMC chip:
CMD62 (ARG: 0xEFAC62EC)
CMD62 (ARG: 0xFAC0021)
This might probably delete all the chip metadata (incl. wear leveling state and bad block info)
and if these commands are correct, it will also reset KNOX counters and stuff.
In other words this is a full factory wipe of eMMC cells.
These are some snippets in S5E4412_ASB.bin located at:
0x8A41C0:
Code:
A5 A2 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
71 1F 04 00
AB C2 9E FF
5A 7B B6 F0
83 68 AE 0F
CD 12 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
1D 28 04 00
...and again at:
0x8C43F0
Code:
2D A2 04 00
CD A4 04 00
80 22 06 00
EC 62 AC EF = CMD62 (ARG: 0xEFAC62EC)
00 00 04 12
31 0C 62 00
AB C2 9E FF
5A 7B B6 F0
9F 1B 04 00
83 68 AE 0F
47 0F 04 00
21 00 AC 0F = CMD62 (ARG: 0xFAC0021)
EE CC DE 00
A9 40 35 FF
BD AE 33 F1
80 97 72 00
This could be some approval for the usage of these commands at least, because these sections are pure ARM assembly and seem to be associated with eMMC low level setup.
I'll have to find out some offsets for this machine code to try a disassembly.
Maybe this will lighten things up even more.
EDIT:
BTW, found one of the main return addresses which is at 0x40008000 (physical address at the beginning of DRAM). Let's see if this is correct.
EDIT2:
Bingo... just had a look in my boot logs i once grepped during UART session:
Starting kernel at 0x40008000...
Conclusion:
The ASB test suite (S5E4412_asb.bin) is booted/started at the same offset as the linux kernel does.
Let's see what this may give us
Another thing to mention is, that included in S5E4412_asb.bin there's a M0 test bootloader (GT-I9300).
Have a look at offset 0x08d8fe8 inside the binary
So in the end i wonder, if someone has ever used this "Service" card together with a real UART connection to the board.
Apart from the automated test and setup process, my guess is, that there should be some command line or some kind of a test menu which may give alternative choices to proceed certain tasks.
P.S.: Maybe it's hard to understand what i like to point out here... but imagine we use the following:
- emmc_auto.sbl.bin -> a bootloader suitable to start from SD card only
- E4412_S.TN.bl1.bin -> trustzone binary which sets up this part of the SoC for SD card boot
- recovery.img -> kernel + recovery to start completely from SD card (eMMC not touched here!!!)
P.P.S: Let's see if the SD card boot files look for a signature here.....
Stay tuned!
scholbert

... further experiments
Hi,
i made further progress with my attempts to boot my GT-I9305 completely from external MicroSD.
As proposed in my last post i prepared a card with the following commands:
Code:
echo "Exynos4412 FWBL1+BL2"
dd if=./emmc_auto.sbl.bin of=/dev/sda bs=512 seek=1
echo "Exynos4412 TZSW"
dd if=./E4412_S.TN.bl1.bin of=/dev/sda bs=512 seek=9500
Next is to prepare the board.
You'll need Anyway JIG or a dedicated UART connection as described in my first post.
To block access to internal eMMC the resistor R634 on the GT-I9305 mainboard got shorted.
Insert the MicroSD with the proprietary boot files into the socket.
Connect to a terminal and attach supply voltage of 3.8-4.0V to the battery connector.
Press the power button and hold it.
Here's the output so far:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422650 usec
<OK>
Inp32(uAddr) : 0x0
LINUX Bootingøq!ñ¥¡Õ
At this point there are no further outputs, as there's nothing to be executed.
Like known from the sboot, hitting enter on your terminal from the very beginning gives a commandline interface.
Unfortunately, it seems that the watchdog is not stopped at this point and maybe the PMIC is not fully initialized.
This leads to repeated resets.
Anyway if you're fast enough, you may get this command list from the proprietary bootloader:
Code:
BL>help
CMD LIST
LOG
WAIT
USB
GET
JUMP
RUN
RUN2
INIT
INIT2
DMC
CLK
DVFS
ASV
DVFSQA
EMA
PMIC
SD
EMMC
ZIP
ABB
RESET
DUMP
MEMCPY
MEMCMP
MEMSET
OUTP32
INP32
SETBITS
GETBITS
COPYRUN
MEMCPY_RUN
PATTERN
BOOT
CTA
ASB
COM
HELP
H
TEST
TN
<OK>
BL>
Some of these commands play an important role for starting up the ASB test suite if present.
These command are included in BL2 and they seem to be interpreted by ASB:
Code:
TN M0|PMIC
INIT2 3|init2|TEST
EMMC
0x10020800 1|TEST RUN
I started to mod these, but as far as i did not start the ASB image yet there's nothing to observe.
By looking at other logs from brick recoveries, i found a relationship between the first output of ASB and these commands.
My idea is that by changing these we could influence the behaviour of the ASB code for educational purpose.
As described above, without parts of ASB the PMIC seems not to be fully initialized,
because i found out that you need to hold the power button to keep the board alive.
This is little strange, as i am pretty sure that this was not the case in the begining, but maybe i'm wrong.
Anyway as far as i observed it, the board starts normally from internal eMMC after my experiments had finished.
At least nothing indicates that something got damaged...
Just to check out what happens i put a raw recovery image at position 20000 (0x9c4000) on the card.
This is the beginning of kernel code.
Afterwards i started a new terminal session and i saw that the first command of kernel code got printed,
but unfortunately after the bootcode jumps to this code there's no further output.
Something is still missing.
Could be something obvious (e.g. missing TAGS at 0x40000100) or could be not.
Maybe it would be a good idea to compile a version of u-boot and try again.
Let's see
scholbert

....grrrr
Hi again!
First of all, nice to see that at least two guys follow my binary surgery.
Second, i must admit that the platform is not that responsive as i first thought.
Due to all this signing stuff, it is easy to break something and CPU simply stops executing code.
So for now there's nothing, than further logging outputs from the console.
1. I removed some of the start up commands from BL2, which leaves TN M0|PMIC & INIT2 3|init2|TEST for ASB code.
This is what i got then:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[CHIPID] E4412 EVT1.1
LOTID WNO X Y IDS HPM ASV_GRP FUSE SHIFT
[LOG]N571A 18 201 195 22 22 8 -1 100000 80
There's no auto booting anymore at this point.
2. I put anything back, apart from the RUN command.
During this test i used a modified ASB binary with sboot from I9305XXALI4 put in the right place.
Unfortunately the output stops after "FW Booting"
The device kept being powered though. Which is a good thing from my guess.
Here's the log:
Code:
TN default
<OK>
<OK>
[DVFS] INT(1) : 0
DRAM Type : LPDDR2 16G
[DVFS] MIF(3) : 0
[EPLL][VPLL][CLK_DIV] OK
<OK>
[LOCK SW/HW]ARM:0/0 INT:0/0 G3D:0/0 MIF:0/0 SHIFT:0/0
[DVFS] ARM(0) : 5
[DVFS] INT(1) : 0
[DVFS] G3D(2) : 0
[DVFS] MIF(3) : 0
[SD_INIT
SDMMC_HighSpeed:DONE]
SD_READ: 20000 20000 0x40008000 -> 422818 usec
<OK>
Inp32(uAddr) : 0xea00007e
FW Booting
Right now it's a bit to early for further conclusions, but maybe the signing stuff got broken at some point in both cases.
It could also be that some of the signatures is especially for GT-I9300, or in other words the CPU on GT-I9305 uses a different key set.
That's it by now, but i won't give up yet
Cheers,
scholbert

Wow, that's one of the most insightful threads about 4412 I've seen for a while.
Replying here on OP's PM for further reference:
* At LenovoK860 uboot sources:
These seem to contain private keys for some batch of 4412 - that's the first time I see private signing keys of any Exynos to leak. Previous leaks were just wild security-dropping bootloader stages signed with private keys, but no keys included.
These keys can either match batch customized for Lenovo or match all 4412 (Exynos4 public key hash fuses, in theory, meant to be factory/OEM customizable) - I'd say the latter since neither GS3 or any common device built on S5PC2xx I've seen was expected to have any grade of real security, so probably neither Lenovo or Samsung cared to customize any of Exynoses used around.
There is a way to check it by comparing dumps from 0x10100000 area between GS3 and LenovoK860 CPUs (I'm uncertain, as I'm really rusty). Probably there's also other way by comparing Lenovo stage1 public keys with GS3 0x1010_0000 dumps, considering how pubkey is validated against these bits (no idea, don't remember).
* At My and Adam's tries:
We were quite succesfull in running UBoot on I9300 and GalaxyCam GC100.
What we couldn't achieve was kernel booting - Exynos4 kernels require TZSW to be fully operating and communicating with it. I couldn't get it to load up properly.
There's quite of history of our tries under https://github.com/Rebell/exynos4_uboot/commits/master
Another option is, of course, disabling TZSW support in kernel and not booting it at all - it doesn't seem to work out-of-the-box either, and would make impossible to boot any non-modded kernels.
AFAIR (and boy, was it while ago), referenced sources were building and fusing to the SD card flawelessly and supporting both fastboot and UART terminal with most (all?) of the commands working (yes, it can do raw R/W to eMMC and whatnot in SVC mode without TrustZone supervisor interfering, because it's not loaded at all yet). Just kernel wouldn't boot. I'd say you should give it a try (if you didn't already).
The crucial part we used there was FWBL1 (there https://github.com/Rebell/exynos4_uboot/tree/master/sd_fuse) - first, already signed, stage of bootloader hat's doing nothing but loading another stage of bootloader without any security (kudos to Odroid).
We couldn't find any equivalent of signed FWBL1 for Exynos4210 (GS2 CPU) that would allow us booting eMMC hardbricked GS2 devices.
* At ASB:
First time I hear of it. Never seen this stuff before.

... just an update
Hi,
it's been a while now that i found some time to fiddle around with one of my i9305 mainboards.
In the meantime there'd been some nice conversation via PM with Rebellos as well.
u-boot on Galaxy S3
Find the sources here:
https://github.com/Rebell/exynos4_uboot
So i finally gave it a try, jumped on his work and compiled a version of u-boot for Galaxy S3 devices.
As a prerequisite you'll have to block eMMC and to make it short...
It just works!!!
Attached you'll find a log from external sdcard boot.
Maybe i'll do some tweaks in the near future, e.g. remove the annoying "pmic_s5m8767_init" messages,
as there is no such device on our S3.
s-boot for Tizen on Galaxy S3
On the Tizen Wiki (https://wiki.tizen.org/wiki/Flash_Tizen_2.2.1_Image_to_Reference_Device)
there's a link to a tar with image files (Tizen_RD-PQ_System_20131107_1.tar), which contains a s-boot file.
Unfortunately the signature of BL1 inside the s-boot image seems not fit the mass production units.
In other words no boot message here at all... at least while trying to boot from sdcard.
mass production sboot on external SD-card
On the other hand the mass production units sboot images are ready to boot from sdcard as well.
Find the second log attached below.
The error messages are normal, because i blocked eMMC all the time, to prevent bricking during my experiments.
security key validation
As you'll see in the logs i dumped the region at 0x10100000 for the security key values.
Here's a snippet of the secure boot function header in the u-boot sources:
Code:
#define MAX_EFUSE_DATA_LEN 16
typedef struct
{
unsigned char rsa_n[128]; /* RSA Modulus N */
unsigned char rsa_e[4]; /* RSA Public Exponent E */
} RawRSAPublicKey;
typedef struct
{
RawRSAPublicKey rsaPubKey; /* RSA PublicKey */
unsigned char signedData[20]; /* HMAC Value of RSA PublicKey */
} PubKeyInfo;
/* Secure Boot Context */
typedef struct
{
RawRSAPublicKey stage2PubKey; /* Stage2 RSA Public Key */
unsigned char code_SignedData[128]; /* RSA Signature Value */
PubKeyInfo pubKeyInfo; /* Stage1 RSA PublicKey and it's HMAC value */
unsigned char func_ptr_BaseAddr[48]; /* Function pointer of iROM's secure boot function */
unsigned char test_eFuse[MAX_EFUSE_DATA_LEN];
unsigned char reservedData[36];
} SecureBoot_CTX;
If i assume S3 still uses V1.1 security with 1024Bit RSA (BL1.bin is 8192Byte) the efuse key would be 128Bit, which results in 4 registers with 32Bit length.
Exported to a hex dat file this is 16Byte of Hex data.
Dump at 0x10100000 gives:
Code:
10100000: 0d19a391 2a0502af 1576987a 212121bc .......*z.v..!!!
We'll have to re-arrange the bytes for little endian order:
Code:
91a3190d af02052a 7a987615 bc212121
... use a hex-editor and put these into a file named: eFuseData.dat
Next i took codesigner_v21 and tried to validate stock BL1 files if they match.
codesigner_v21 -v1.1 <BL1.bin> <eFuseData.dat> -VERIFY
Unfortunately no succes yet... signature verification always failed.
This is a mistery, because the position of the key should be correct and i used valid bootloader files as well.
Anyway this had been only a proof of concept if we got the right tool and the right efuse values.
TBC
Cheers,
scholbert

@scholbert
Please, need collection of GT-I9305 Bootloader....
Something like this:
http://forum.xda-developers.com/galaxy-s3/general/guide-extract-bootloader-make-flashable-t2864264
http://forum.xda-developers.com/galaxy-s3/general/ref-galaxy-s3-stock-kernel-bootloaders-t2189063
For now I was only able to find
RESTORE_BOOTLOADER_I9305XXALI4.zip
http://forum.xda-developers.com/showpost.php?p=32760677&postcount=1
I need few more for stupid tests.
For now my test GT-I9300 PCB is able to start this sboot.bin from GT-I9305... with tweezer.
sboot.bin is copied successfully... but not start in "normal mode"...
Here I can see other method... sboot.bin is not copied to eMMC but fully executed from eMMC, with Boot menu:
http://forum.xda-developers.com/showpost.php?p=64664423&postcount=278
I will check if GT-I9305 has similar Bootloader and if it will executed on my GT-I9300 test PCBs.
Thanx in advance.
Best Regards

I found this:
I9305XXUFNL1-DBT.zip
Here is sboot.bin from GT-I9305 inside... I have attached.
Search for text String THOR... you can find:
Code:
- Thor is connected!
This could mean... I9305 is Tizen enebled... not only this...
Chance to play with U-Boot.
Tried on I9300 with no luck...
Volume + or Volume - do nothing... maybe Hardware Keys different...
I hope to find something working for my I9300...
Btw.
First time I saw THOR string also in Note 4 N910C:
http://forum.xda-developers.com/showpost.php?p=64663039&postcount=65
Best Regards

[Q] Bricked, no bootloader - recoverable?

Hi all,
Is there any way to recover my bricked Defy if the bootloader is not running (corrupt eMMC)? RSDLite will detect the phone as "Blank OMAP3630" if the option "TI Blank Flash" is selected, but flashing then fails immediately with "Error sending TI ROM data packet request. Device API Error: 0xE003009F".
Looking at the TI SoC documentation, the OMAP ROM code tries to boot from USB (hence the device is detectable for 3 seconds), so it should be possible to upload the original Motorola bootloader to RAM, execute it, then communicate with the (now running) bootloader to erase the eMMC and reflash it. The first file in the SBF (3.4.2-177UK) is the RAM downloader, which looks like the bootloader itself (it contains the same strings, eg. "OK to program" etc.) Can this be uploaded with only the OMAP ROM code running, or is it impossible to do anything if the eMMC is blank? Alternatively, would it be possible to load the bootloader from the SD card? This is possible on GP (ie. unsecured) OMAP devices.
Some background on the failure:
- MB525, green lens, CM710, running great for 2 years
- Got into a boot loop at the skater animation, for no apparent reason
- Used stock recovery to wipe data/cache (mistake?), didn't complete, battery out/in and booted to lock screen then froze, battery out/in and back into boot loop
- Used CWM recover to wipe data/cache, didn't complete, after a few seconds spontaneously rebooted to black screen, bricked
- Battery is fully charged
- With empty battery and plugged in, the white LED comes on, but in this state the processor is not running as the battery is trickle charged. When the voltage comes up, the OMAP starts, tries to boot over USB (3 seconds) and then hangs
- Various combinations of power/battery/volume up/down make no difference, the bootloader is not running
- I think the eMMC is corrupt (possibly hardware failure?)
Thanks for your help!

Defy boot process
Here's a summary of what I've learnt so far about the Defy boot process, from the many great posts on this forum and various other sites including the droid-developers wiki:
SoC:
- Defy SoC is Texas Instruments OMAP3630, locked by eFuse in HS (high security) mode, JTAG is disabled
- OMAP contains core boot ROM that runs first to start the boot chain
- OMAP contains Motorola 128-bit RSA public key hash programmed in eFuses, used to validate external bootstrap code (mbmloader)
- OMAP supports booting from external memory (MMC, NAND, NOR) and peripheral booting (USB, UART3)
- OMAP boot sequence is set by sys_boot pins, Defy configured boot sequence is 0b00101, ie. MMC2 then USB (only)
Storage:
- External flash is Sandisk SDIN5D2-2G (2GB eMMC, BGA package) connected to OMAP MMC2 interface, mapped as mmcblk1 in linux
- eMMC device is physically located under the metal can between the connectors for SIM card and battery
- eMMC behaves as conventional 512-byte sector hard disk and is partitioned with FAT MBR
- eMMC does not use separate ECC area, unlike the NAND flash used on the Droid, ECC is handled transparently by eMMC device
- SD card is connected to OMAP MMC1 interface, mapped as mmcblk0 in linux
The Defy (stock) power-on reset boot process works as follows:
- OMAP boot ROM code starts
- OMAP reads boot configuration 0b00101 from sys_boot pins
- MMC2 boot is selected
- OMAP reads first eMMC sector (the MBR)
- OMAP finds the first valid partition entry in the MBR
- OMAP reads the first eMMC partition (which is the Defy CG63/mbmloader) as a raw image (not a filesystem)
- OMAP processes the CH table (OMAP clock and SDRAM settings) from the first sector of the image (possibly unsigned)
- OMAP validates the public keys, PPA and ISW stored in the image, using the eFuse key hash
- OMAP copies the ISW (which is MLO, or the actual Motorola mbmloader bootstrap executable) into internal RAM
- mbmloader (if validated) is executed from RAM, otherwise the boot process skips to USB (below)
- mbmloader validates and loads mbm (the Motorola bootloader) from the second eMMC partition
- mbm detects the "volume up" button if pressed to interrupt boot and display the bootloader screen
- mbm displays the boot logo and loads lbl (linux bootloader)
- lbl loads the stock linux (android) kernel (or the stock recovery kernel, if the "volume down" button is pressed)
- linux kernel displays the startup animation
If MMC2 boot fails (no valid MBR/mbmloader):
- USB boot is selected
- USB is initialised (device is now detectable as TI OMAP3630 for 3 seconds)
- OMAP sends ASIC ID
- OMAP waits 300ms for response
- If no response, OMAP halts (infinite loop)
- USB host can send command to change boot device or upload (signed) boot image (unknown format) for execution in RAM
Therefore if the device is trying to boot via USB, it probably means that the eMMC MBR or the first partition (containing mbmloader) is corrupt, or the eMMC is blank. Presumably if the mbm (and mbmbackup?) partition is corrupt, the device will hang with screen off and no USB boot (unless mbmloader can exit to OMAP USB boot), and if lbl or the kernel is corrupt then mbm will stop and display the bootloader screen.
eMMC partition table for Defy (start/end sectors), based on a dump of mmcblk1 from a working Defy, noting respective CGs for SBF:
Code:
Device Boot Start End Blocks Id System CG ID Function
0 255 128 64 mbr FAT MBR
1 * 256 511 128 83 Linux 63 mbmloader Motorola bootstrap
2 1024 2047 512 83 Linux 30 mbm Motorola bootloader
3 2048 3071 512 83 Linux 55 mbmbackup
4 3072 31358975 15677952 5 Extended 65 ebr FAT EBR
5 4096 5119 512 83 Linux 56 bploader
6 5120 6143 512 83 Linux 31 cdt.bin CG table
7 6144 14335 4096 83 Linux 38 pds
8 14336 15359 512 83 Linux 34 lbl Linux bootloader
9 15360 16383 512 83 Linux 57 lbl_backup
10 16384 18431 1024 83 Linux 42 logo.bin mbm startup logo
11 18432 22527 2048 83 Linux 41 sp
12 22528 23551 512 83 Linux 61 devtree
13 23552 24575 512 83 Linux 62 devtree_backup
14 24576 32767 4096 83 Linux 45 bpsw
15 32768 49151 8192 83 Linux 35 boot Stock android kernel and ramdisk
16 49152 65535 8192 83 Linux 47 recovery Stock recovery kernel and ramdisk
17 65536 94207 14336 83 Linux 33 cdrom
18 94208 95231 512 83 Linux 44 misc
19 95232 96255 512 83 Linux 43 cid
20 96256 104447 4096 83 Linux 53 kpanic
21 104448 774143 334848 83 Linux 39 system
22 774144 775167 512 83 Linux 32 prek
23 775168 776191 512 83 Linux 46 pkbackup
24 776192 1185791 204800 83 Linux 40 cache
25 1185792 31358975 15086592 83 Linux 37 userdata
My understanding is that if the eMMC is blank, I need to flash an SBF that contains at least the RAM downloader, CG64, CG63, CG30, CG65 and CG31 to reinstate the eMMC partition structure and bootloader. I think RSDLite should be capable of this (with "TI Blank Flash" enabled), unless the flash loader (RAM downloader) somehow depends on some content of the eMMC containing valid data. I don't know if such an SBF exists, and in any case RSDLite so far fails with "Error sending TI ROM data packet request", and I don't know why (tested under XP and Windows 7/8).
Awesome references:
http://forum.xda-developers.com/showthread.php?t=1443678
http://www.droid-developers.org/wiki/Booting_chain
http://www.droid-developers.org/wiki/Mbmloader
http://blog.opticaldelusion.org/search/label/sbf_flash
https://docs.google.com/spreadsheets/d/1jF8LjoS1yiMxn775QDm-cn5kxpoYw_biIC70uf9_ldY/pub?single=true&gid=0&output=html

OMAP Peripheral Boot - booting via USB
I've found out a little more about the OMAP USB peripheral boot mode, as a possible way to unbrick my Defy. The Texas Instruments OMAPFlash command line tool (for Windows) can be used to send executable code to the OMAP3630 (first into internal RAM, and then into SRAM), via the ROM code peripheral boot. This might allow the eMMC to be reflashed without a functioning Motorola bootloader (which is needed by RSDLite).
I think the unbricking process could work as follows:
- The Defy OMAP3630 starts in USB peripheral boot mode (OMAP ROM code - 1st bootstrap), because the eMMC is corrupt/blank
- OMAPFlash uploads a signed USB bootloader executable (2nd bootstrap) to internal RAM, via the OMAP ROM code
- Defy validates the uploaded 2nd bootstrap and executes it - this is the USB equivalent of mbmloader
- OMAPFlash communicates with the now running 2nd bootstrap and uploads the signed Motorola bootloader (mbm) to SRAM
- Defy executes mbm from SRAM and is now running the Motorola bootloader
- RSDLite can now be used to flash the eMMC with a special .SBF file containing mbr, mbmloader, mbm and ebr
- Defy can now boot mbm normally from eMMC and can be reflashed via RSDLite with a normal full .SBF
The following would be needed:
- OMAPFlash configured for Defy - available and possible
- USB bootloader (2nd bootstrap) for the Defy, signed with Defy private key - not available?
- Motorola bootloader (mbm) for the Defy, signed with Defy private key - available, as dumped from eMMC on working phone
- .SBF file with CG64, CG63, CG30 and CG65 - can be created, as all these signed binaries are available from eMMC dump
OMAPFlash is supplied with an unsigned OMAP3 2nd bootstrap and a version signed with the TI private key. There is also one available for the Droid (called pbrdl.bin), signed with the Droid private key (Droid is OMAP4). None of these will run on the Defy. (The TI OMAPFlash installer is available via http at 59.124.231.13/index.php/OMAPFlash, as a new user I can't post a direct external link).
OMAPFlash also seems to be able to flash the eMMC directly via a binary driver that it uploads to the device, but the documentation claims that this is only possible for OMAP4 devices (and it would still need a signed 2nd bootstrap).
So, to use this method, we need a signed OMAP3 2nd bootstrap file (pbrdl.bin) for the Defy. Does it exist?

RSDLite - reason for "TI Blank Flash" not working
With the "TI Blank Flash" option selected, RSDLite detects the phone as "Blank OMAP3630", but fails to flash the full .SBF with the message "Error sending TI ROM data packet request. Device API Error: 0xE003009F".
The reason for this is that RSDLite attempts to send the RAM downloader in the .SBF, which is 315392 bytes. The OMAP internal RAM is only 65536 bytes and some of this is used for workspace by the ROM code. In fact the Defy seems to refuse to accept a file uploaded via USB peripheral boot (the USB connection is terminated) if it will exceed about 28664 bytes. The reason for this is not clear (it is not publicly documented for HS devices).
So I think that for RSDLite to be used with the "TI Blank Flash" option, there would need to be a special .SBF with a small sized RAM downloader that fits into the OMAP RAM. Maybe this small RAM downloader would be the signed Defy 2nd bootstrap that can download and execute mbm. I don't know if such an .SBF file exists.

When Linux is the Solution
Hi @Teedub, I had the same Problem with my Defy+. Dead, no bootloader,no recovery, Nothing. RSDLite didn't recognize my phone. So I tried sbf_flash on Linux. After downloading sbf_flash I typed this on the terminal
Code:
./sbf_flash name_of_the_sbf.sbf
And magically, it loaded the bootloader and flashed my Rom .
So I suggest you to try this program. It's very useful when RSD LIte does't want to work

[TOOL] Newflasher (xperia command line flasher)

Disclaimer:
newflasher tool was made for testing and educational purposes, ME is not responsible for what you do on/with your device using newflasher, you must agree that you using newflasher on your own risk, I am not responsible if you brick your device or anything else!
How to use:
OPTIONAL STEP 1:
- if you have missing flash driver just double click exe and confirm driver extraction, an exe will become available, run it and install driver.
OPTIONAL STEP 2:
- this step is optional, this step dump trim area, you can do this and keep those file somewhere on your pc in case you hard brick your device so give it to servicians to repair your phone.
STEP 1:
- Download right firmware for your device using XperiFirm tool, put newflasher.exe into firmware dir created by XperiFirm tool. Before you double click newflasher.exe do in mind something, newflasher tool is programed to flash everything found in the same dir!!! So tool flash all .ta files, all .sin files, boot delivery (whole boot folder), partition.zip, in short all files found in dir! If you no want to flash something just move file which you no want to flash OUT OF FOLDER! Partition.zip .sin files can be flashed only if you extract partition.zip into newly created folder called partition!
STEP 2:
- To start flashing phone put your phone into flash mode, double click newflasher.exe and wait wait wait until your device gets flashed, thats it. Look into log to see if something goes wrong! If all right you are done. If not post your log so I can look!
SOME MORE THINGS:
"You do not need to unlock bootloader or to root the phone if you want to flash a stock firmware from XperiFirm.
There are no files in the stock firmware that need to be deleted. Prompts will ask you to skip some files.
Feel free to press N to every prompt since:
- TA dumping it's not related with DRM keys.
- Flash persist_* files only if you know what you are doing, since you will lose your attest keys. Backup persist partition.
If you need the firmware on both A and B slot use fastboot commands to choose the inactive partion and re-flash."
Happy flashing!
Supported platforms:
- Newflasher is working on Windows, Linux, Android and Darwin, just chose right newflasher binary. With Android version you can flash phone by using another phone!
Changelog:
- version 1: Sorry a lot of work is done in pre pre alpha version and I can't count every changes, just folow development process about version 1, a lot of work is done before it started working. One esential change was done to tool improvement and it is described in one of the my posts related to moving function "erase:" to the section before function "flash:", it is realy improvement and more safer than in time when it was at the start of flashing routine.
- version v2 (15.Aug.2017)
Implemented free disk space safety check, it was missing and danger in case flashing process gets interupted because of the lack of the free disk space needed for sin extractions and temporary files. I have also include GordonGate flash driver prompt so in case somebody have missing flash drivers, simple need to double click exe and folow drivers archive extraction procedure, later need to install these drivers trought Windos device mannager. Also I have implemented an realy pre pre alpha version of the maybe non working trim (why maybe? Because I don't own xzp so can't test) area dump routine, in case it is working we can dump some esentials trim area units from device (probably not a full dump as like it was on every oldest xperia models - no permissions for dumping drm key unit)
- version v3 (23.09.2017)
Some more security checks, it's now a bit safer than v2
- version v4 (21.10.2017)
Updated trim area dumper, now it stores log to the trimarea.log but dump is now in .ta format and writen to the 01.ta and 02.ta
- version v5 (22.10.2017)
Updated trim area dumper, add progress meter, fix y-n prompt (thanks @pbarrette)
- version v6 (22.10.2017)
Updated trim area dumper
- version v7 (23.10.2017)
Updated trim area dumper, newflasher redesigned a bit, fix new partitioning for Oreo
- version v8 (24.10.2017)
Fix trim area dumper
- version v9 & v10 (25.10.2017)
Workaorunds on trim area dumper
- version v11 (07.04.2018)
Support for 2018 devices
- version v12 (29.04.2018)
Try fix doublefree bug/crash (most noticed on Linux 64 bit binary)
- version v13 (01.05.2018)
Fix doublefree bug/crash by removing dynamic allocation from function get_reply
- version v14 & v15 (12.06.2019)
Sony XPeria 1 support added.
- version v16 (16.06.2019)
LUN0 detection optimized.
- version v17 (24.06.2019)
LUN0 detection bug fixed.
- version v18 (10.08.2019)
Untested fix for https://forum.xda-developers.com/cr...wflasher-xperia-command-line-t3619426/page105
Using builtin mkdir instead of calling it trought system call
- version v19 (08.10.2019)
Implemented prompt for flashing persist partition; print skipped .sin files
- version v20 (13.12.2019)
implemented prompt for flashing bootloader,bluetooth,dsp,modem,rdimage to booth a,b slots
- version v21 (29.06.2020)
implemented battery level status check before flashing, flashing bootloader,bluetooth,dsp,modem,rdimage to booth a,b slots is mandatory now and is flashed by default right now, more info, try fix previously reported isue on sync and powerdown command reported 2-3 years ago so I have disabled it and now enabled for test, implemented Macos support (curently need to be tested! If you have plan to test please flash only cache.sin DO NOT flash the rest because of safety for your device!)
- version v22 (30.06.2020)
trying to fix battery capacity retrieval
- version v23 (04.07.2020)
removed battery capacity retrieval (not going to work that way), fix trim area dump file name, new gordongate drivers
- version v24 (04.07.2020)
new feature - now you can run newflasher from script or console with your own command, e.g. newflasher getvar:Emmc-info , I didn't tested all the list of commands, if you do it share them with us!
- version v25 (09.07.2020)
New trim area dump tool, with this change trim area dump is created in 3 secconds. Do in mind this not dump protected units like drm key...etc! Some changes in scripting feature from v24
- version v26 (10.07.2020)
Added 4 diferent reboot modes, reboot to android, reboot to fastboot, reboot to bootloader, power off
- version v27 (11.07.2020) (not yet released)
Workaround in mac libusb
- version v28 (12.07.2020)
Workaround to sync response bug; Fully implemented support for Mac. I'm tested myself on mac 10.14 but confirmed working on mac 10.15 too
- version v29 (12.07.2020)
Mac proper libusb deinitialisation
- version v30 (13.07.2020)
Preparation for Debian packaging; I'm noticed that hex modified arm64 fake pie binary is not working so its now compiled with ndk and its true pie binary now
- version v31 (14.07.2020)
Fix cosmetic bug https://forum.xda-developers.com/showpost.php?p=83056693&postcount=1212 which might confuse somebody
- version 32, not yet released
- version 33 (30.07.2020)
Allow bootloader unlocking with newflasher; Try fix sync response bug for win and darwin too
- version 34 (08.08.2020)
Added support for 32bit sized trim area units (as trim area api changed in xperia mark 2 line) (not yet released because of bug)
- version 35 (08.08.2020)
Updated support for 32bit sized trim area units (as trim area api changed in xperia mark 2 line); Move trim area dumps out of root folder so it not get acidentaly flashed, dumps is now inside folder tadump
- version 36 (27.08.2020)
Some improvements and and possible bug fixes
- version 37 (09.12.2020)
Added support for Xperia 5 II with emmc instead of ufs (not working)
- version 38 (10.12.2020)
Fixed impropper implementation from v37
- version 39 (13.12.2020)
Since mark 2 devices protocol is changed a bit and on some devices OKAY reply is not in separated usb poacket, instead it is merged with data packet, added support for it
- version 40 (03.01.2021)
Temporary solution for determining partition 0 sin file caused by two diferent emmc csd info we found recently on mark 2 devices
- version 41 (03.01.2021)
Removed temporary solution from version 41 so right lun0 sin file get flashed and seccond lun0 get skipped or booth skipped if lun0 sin file do not match device storage size
- version 42 (11.03.2021)
Fix bug in flashing booth slots when current slot is A, thanks to @chrisrg for discovering bug!
- version 43 (12.06.2021)
Support for Mark 3 devices
- version 44 (19.06.2021)
Fully Mark III device implementation
- version 45 (20.06.2021)
Implemented battery level check and prompt user to take a risk and continue flashing or stop flasing if battery level is less than 15 percent
- version 46 (08.07.2021)
Fix problem with filenames which contain "_other", it need to be always flashed to the diferent slot
- version 47 (15.07.2021)
Removed prompt for persist.sin flashing, now its by default skip. Implemented bootloader log retrieval at the end of flashing for better understanding when something goes wrong. Implemented firmware log history retrieval for those who want to know history of the flashed firmwares
- version 48 (19.07.2021)
Flash bootloader,bluetooth,dsp,modem,rdimage to booth slots only on a,b devices
- version 49 (31.07.2021)
Support for XQ-BT41
- version 50 (12.08.2021)
Workin progress on asynchronous usb to make it more like synchronous, added progress bar during send-receive usb packets and more logging. Increased usb timeout to 2 minute. Trying fix sync command at the end of flashing as reported here -> https://github.com/munjeni/newflasher/issues/42
- version 51 (12.08.2021)
Fix empry line printed while receiving usb packets, thanks @elukyan
- version 52 (01.10.2021)
Implemented userprompt for keeping userdata, thanks @OhayouBaka for figuring out! Removed bootloader log retrieval
- version 53, 54, 55 (20.0822022)
Fix trimarea dumper crash on big endian machines, update building makefiles
Credits:
- without @tanipat and his pc companion debug logs this tool will never be possible! Thank you a lot for your time providing me logs! (by the influence of others, He was disappointed me with last post, but I still appreciate his help and can't forget it)
- without @thrash001 who helped testing our tool I never be continue building our tool since I don't have device for testing, thanks mate!
- didn't forgot @beenoliu, thanks mate for testing!
- thanks to @porphyry for testing linux version!
- thanks to @Snow_Basinger for providing sniff log from 2018 device and for testing on his 2018 device
- thanks to @frantisheq for testing newflasher on his 2018 device and for notify about doublefree bug
- thanks to @serajr for providing me some logs which helped me to figure out some things related to 2018 devices
- thanks to @noelex for helping in Xperia 1 implementation
- thanks to @Meloferz for testing on his xperia 1 mark II
- thanks to github contributors, testers and reporters: vog, noelex, TheSaltedFish, solarxraft, pbarrette, MartinX3, kholk
- thanks to Chirayu Desai for tracking addition to Debian and thanks to vog for initiating all that
- thanks to @elukyan for testing and providing me usb sniff logs for mark 3 devices imlementation, thank you so much
Common errors and how to solve:
https://forum.xda-developers.com/t/tool-newflasher-xperia-command-line-flasher.3619426/post-72610228
Source code:
https://github.com/munjeni/newflasher

let me start for you and report

here my log..
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Error writing command!
Drücken Sie eine beliebige Taste . . .

Common errors and what you need to do:
ERROR: TIMEOUT: failed with error code 997 as follows:
Overlapped I/O operation is in progress.
FIX --------> https://forum.xda-developers.com/t/tool-newflasher-xperia-command-line-flasher.3619426/post-84603931
Error, didn't got signature OKAY reply! Got reply: FAILFailed to verify cms
FIX---------> Make sure to flash right rom model e.g. if your device is SO-01L you need to flash rom model SO-01L or e.g. your phone is H8314 you need to flash rom H8314 ... etc, otherwise you might hardbrick your phone!
Bootloop caused by rooback protection e.g. by flashing an OLD rom over NEWER one e.g. you have android 11 and want back to android 10 that will bootloop your phone if your phone have rollback protection
https://forum.xda-developers.com/t/...-xq-at51-with-flashtool.4119707/post-84509417
in short explanation your bootloader need to be unlocked. Than by relocking bootloader rollback index (rollback protection) is reset to zero. Than you can flash oldest rom because index in that case is zero so you won't get bootloop related to rollback protection.
It was confirmed working:
https://forum.xda-developers.com/t/...-xq-at51-with-flashtool.4119707/post-84637803
https://forum.xda-developers.com/t/...-xq-at51-with-flashtool.4119707/post-84673613
If neither help you to solve problem you should read boot log to get idea, use this command line option for newflasher:
newflasher Read-TA:2:2050

what I got
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#6&3a757eec&0&1#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: Universal Serial Bus controllers
Device Instance Id: USB\VID_0FCE&PID_B00B\6&3A757EEC&0&1
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
A device attached to the system is not functioning.
- Error reaply! Device didn't replied with OKAY or DATA
Press any key to continue . . .
wait for others to report

Hm, you successfully wrote command but error on reaply Lets see new version is out

Today I have free time for development, I don't know when I will get free time again, so guys if you hurry to have flasher I am here and waiting. I do not have 2017 device model so I can't test, so can't continue development without your tests

Driver is the right.
here the next:
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Successfully write 0x0 bytes to handle.
- Error writing command!
Drücken Sie eine beliebige Taste . . .

Strange! Maybe run as admin is need?

It would be great if tanipat debug newflasher with monitoring studio so I can compare whats going on? New version is out again.
Edit:
Curent version is safe so you no need to care for brick! Tool currently nothing write to internal mem! I will tell when it is ready for flashing! Now its just pre pre alpha version, only read from phone

in the windows devicemanager is it correct as "SOMC Flash Device"
the next one:
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Error write! Need nBytes: 0x18 but done: 0x0
- Error writing command!
Drücken Sie eine beliebige Taste . . .

Can you right click on .exe and run as admin?

the same
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Error write! Need nBytes: 0x18 but done: 0x0
- Error writing command!
Drücken Sie eine beliebige Taste . . .
---------- Post added at 08:42 PM ---------- Previous post was at 08:41 PM ----------
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
get_reaply:[0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
get_reaply:[0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Successfully read 0x0 bytes from handle.
Raw input [0x0]:
- Error reaply: less than 4!
Drücken Sie eine beliebige Taste . . .
Sorry, i must disconnect the device for the next start

Thanks a lot! Seems some good progress here! I had set timeout to 60 secconds, seems it was not enought and caused timeout, now I have set to 120 secconds and donesome small modification, hope we get luck now, new version is out

Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Error reaply: less than 4!
Drücken Sie eine beliebige Taste . . .
and this, without disconect a view seconds later again start the exe
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
ERROR: TIMEOUT: failed with error code 997 as follows:
▄berlappender E/A-Vorgang wird verarbeitet.
- Error reaply: less than 4!
Drücken Sie eine beliebige Taste . . .

Hmm strange realy. See https://www.lifewire.com/how-to-fix-code-31-errors-2623184 its seems your driver is not working propertly, maybe you have old flashtool driver and not one for newer device (which can be installed by installing sony pc companion software), I have no idea by now, unable to figure out why that happens Did you flashed by sony pc companion your device allready and you are sure it is working, can you confirm? Probably if you allready installed flashtool driver you will need to uninstall and reinstall pc companion, have no idea by now what might be a problem

so, i have erase the driver. restart windows, install the flashtool driver. start the exe:
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Error reaply: less than 4!
Drücken Sie eine beliebige Taste . . .
now i erase the driver, restart windows and let windows install the driver over windows.
(i hope you can undersood my english)

Many thanks! Yes I understand you. I must go now, hope somebody figure out if driver is problem or bug in my tool, see you guys tommorow

New version is out, let me know please! I have researched a bit, seems get overlapped result caused some problems and returns imediatelly before thing complete, I have set to "wait complete" hope it is ok now

good morning, so i have reinstall sony companion and start the repair, the new driver is isntall but:
Code:
--------------------------------------------------------
newflasher.exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&15c311e1&0&2#{a5dcbf10-6530-11d2-901f-00c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&15C311E1&0&2
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Error reaply: less than 4!
Raw input [0x0]:
Drücken Sie eine beliebige Taste . . .
---------- Post added at 10:27 AM ---------- Previous post was at 10:18 AM ----------
and this is from my windows7 32bit pc, only sony companion is install.
Code:
--------------------------------------------------------
newflasher (2).exe by Munjeni @ 2017
--------------------------------------------------------
Device path: \\?\usb#vid_0fce&pid_b00b#5&448f588&0&1#{a5dcbf10-6530-11d2-901f-00
c04fb951ed}
Class Description: USB-Controller
Device Instance Id: USB\VID_0FCE&PID_B00B\5&448F588&0&1
- Successfully write 0x18 bytes to handle.
- Successfully read 0xd bytes from handle.
Raw input [0xD]:
00000000 4F 4B 41 59 31 30 34 38 35 37 36 30 30 OKAY104857600
- Successfully write 0xe bytes to handle.
- Successfully read 0x9 bytes from handle.
Raw input [0x9]:
00000000 4F 4B 41 59 47 38 31 34 31 OKAYG8141
- Successfully write 0xe bytes to handle.
ERROR: GetOverlapped_in_Result: failed with error code 31 as follows:
Ein an das System angeschlossenes Gerõt funktioniert nicht.
- Error reaply: less than 4!
Raw input [0x0]:
Drücken Sie eine beliebige Taste . . .