I'm a novice at best and am still in the process of learning linux, but was wondering if either of you guys might be able to shed light on what mmcblock I need? When I run the command to blank flash, this is the output:
c:\Programs\blankflash>qflash.exe -com5 -ramload MPRG8960.hex -mbn 33 MSM8960_bootloader_singleimage.bin -v -o
Motorola qflash Utility version 1.3
qflash - com5 is an invalid port
Invalid COM port entered
c:\Programs\blankflash>qflash.exe -com5 -ramload MPRG8960.hex -mbn 33 MSM8960_bootloader_singleimage.bin -v -o
Motorola qflash Utility version 1.3
COMPORT :COM5
RAMLOADER :MPRG8960.hex
type is 0x21
7 mbn file name MSM8960_bootloader_singleimage.bin type 33
verbose mode on
Motorola qflash dll version 1.6
RAMLOADER VERSION: PBL_DloadVER2.0
------------------------------------------------------
DEVICE INFORMATION:
------------------------------------------------------
Version : 0x8
Min Version : 0x1
Max Write Size: 0x600
Model : 0x90
Device Size : 0
Description : Intel 28F400BX-TL or Intel 28F400BV-TL
------------------------------------------------------
Using passed in packet size, changing from 0x600 -> 0x600
EXTENDED_LINEAR_ADDRESS_REC @ 0x2a000000
Write 65536 bytes @ 0x2a000000
100EXTENDED_LINEAR_ADDRESS_REC @ 0x2a010000
Write 11840 bytes @ 0x2a010000
100START_LINEAR_ADDRESS_REC @ 0x2a000000
No data read from USB. This may not be an error. Trying again...
No data read from USB. This may not be an error. Trying again...
No data read from USB. This may not be an error. Trying again...
No data read from USB. This may not be an error. Trying again...
No data read from USB. This may not be an error. Trying again...
Still no data, giving up!
dmss_go : failed to receive ACK
Error loading MPRG8960.hex into device
The error loading the MPRG8960.hex is what makes me wonder if that hex file is unique to the Moto M and the XT926 needs its own... however I'm not sure where that hex needs to be pulled from on an XT926.
From the XDA post, qflash should return an output like this:
C:\Android>qflash.exe -com10 -ramload MPRG8960.hex -mbn 33 MSM8960_bootloader_si
ngleimage.bin -v -o
Motorola qflash Utility version 1.3
COMPORT :COM10
RAMLOADER :MPRG8960.hex
type is 0x21
7 mbn file name MSM8960_bootloader_singleimage.bin type 33
verbose mode on
Motorola qflash dll version 1.6
RAMLOADER VERSION: PBL_DloadVER2.0
------------------------------------------------------
DEVICE INFORMATION:
------------------------------------------------------
Version : 0x8
Min Version : 0x1
Max Write Size: 0x600
Model : 0x90
Device Size : 0
Description : Intel 28F400BX-TL or Intel 28F400BV-TL
------------------------------------------------------
Using passed in packet size, changing from 0x600 -> 0x600
EXTENDED_LINEAR_ADDRESS_REC @ 0x2a000000
Write 65536 bytes @ 0x2a000000
100EXTENDED_LINEAR_ADDRESS_REC @ 0x2a010000
Write 11840 bytes @ 0x2a010000
100START_LINEAR_ADDRESS_REC @ 0x2a000000
EOF_REC
Sleeping for 3s
-----------------------------------------------------
RAM DOWNLOADER INFORMATION
-----------------------------------------------------
cmd : 0x2
description : QCOM fast download protocol targ
version_number : 0x7
compatible_version: 0x2
max_block_size : 0x400
flash_base_address: 0x0
flash_id_len : 0x4
flash id : eMMC
window_size : 0x1e
number_of_sectors : 0x80
-----------------------------------------------------
sdl_send_security_mode: secutiry mode 0x0
Flashing MSM8960_bootloader_singleimage.bin 1969664 bytes into device
Keeping the first packet (1024 bytes) as hostage
Will release it if all is flashed well
100
Hostage released!
done
Is there a way to create a bootloader single image bin from the firmware files, or is there an easy way for an XT926 user to compile this on their end? I don't want to ask anyone to take a significant amount of time to simply compile a file they don't need and won't use, and if it is time intensive, I'm more than happy to pay someone for their time. I thought about sending my phone in, however I don't believe it's right because I was the idiot that misread something that caused this, combined with the fact I have an unlocked bootloader that I'll lose since it seems may have already started rolling out an update to fix the exploit in 4.4.2.