yashsingh1/xdaforums huggingface dataset:
[BLU R1 HD Guides, News, & Discussion] mrmazak:
the only reason I moved towards the awkward layout of the update process was because, as far as I know writing to the preloader in a shell is also blocked (using DD). [MENTION=5355478]ColtonDRG[/MENTION] tried to write to it with the readback of preloader made with spft. The file had matched md5 from what was already in phone. the test was just to write to that area. And repeated "not allowed" faults came up.

A new preloader file was saved back from phone with a different flashtool program and the file, when opened in notepad++ looked like all other preloader.bin files I have seen. (it didnt have all the extra null blocks)

this new file has not been tested (to my knowledge) in shell, or twrp.

I did try to use this new file in spft and if soft bricked my phone. I was able to restore with the other flashtool program, so i suppose that in it self shows it is writeable. ?

edit.

i went back and tried to just flash preloader and in shows 100% done in flash program(miricle box) but when phone rebooted screen shows "TOOL DL image Fail!"

but if i flash preloader.bin, with lk.bin, boot, and tee1, tee2 it recovers.

i have been able to cross flash the preloader from the prime and non prime phones. verified with md5.

but my test shows preloader not flashing by itself, it needs at least one of the other files along with it(not sure which ones yet).

i am continuing to narrow down the minimum amount of files needed to be flashed, in hopes of figuring out the process needed to come back from 6.6 preloader.

edit 2

I went back and flashed just preloader.bin and lk.bin and it worked. admittedly i do not know what miricle box does different than spft but it has been able to write the preloader. Although the program for me anyway has been very "flakey" need to delete drivers before every new connection. and when done need to hold power button on phone about 15 seconds to force it to power back on..

phase one seems to be verified. There is a program that will flash the preloader.

phase two find a way for program to connect to 6.6 preloader. (the hard part)
[BLU R1 HD Guides, News, & Discussion] bibikalka:
Interesting findings ! I did not realize that a simple "DD" does not copy the preloader directly. Another thing to be careful about is that if they are using eFUSE on BLU, than the new preloader may save its version number, and refuse to boot if the older preloader is flashed back (anti-rollback).

But this also indicates that for anti-bricking safety one should be careful to remove the preloader line from all the future updates before applying them in TWRP.
[BLU R1 HD Guides, News, & Discussion] :
You want me to mirror YOUR zips?

Sure, I'll do that since you requested it. I am already mirroring the official zips.
[BLU R1 HD Guides, News, & Discussion] mrmazak:
i dont know if it is relevent but reading the parts of the preloader that are readable. there are several lines that have efuse on them.....
[BLU R1 HD Guides, News, & Discussion] mrmazak:
i just modified the update script, removed the checks and left the u-boot in. but changed the lk.bin amd preloader.bin.

if flashed in twrp. no problem with twrp flashing prelader. I went back and forth and did readback then compaired the md5. th prepreloader is changing.

the script is real rough and hacked. but works. Can you look it over and pollish it, i did leave some reference to files not included in the zip.
[BLU R1 HD Guides, News, & Discussion] bibikalka:
OK. But explain to me first, who is the intended audience for such a script ? Is this for people with root on V6.6 and new bootloader to reflash the old version back ? Could this also depend on the bootloader unlock status ? Note that in this post the same commands failed :

http://xdaforums.com/showpost.php?p=68731132&postcount=22

[MENTION=6932609]_bfritz[/MENTION] - was your bootloader unlocked as you tried to flash V6.6 update in post #22 ?
[BLU R1 HD Guides, News, & Discussion] mrmazak:
As of now the audience for this is for the ones who have twrp. I don't know about the unlocked bootloader or not.

I think the stock recovery may also flash this, because it does not need the wipe commands of custom recovery. But I did not test it. I might do testing with stock recovery if I have time. Next week or so.
[BLU R1 HD Guides, News, & Discussion] mrmazak:
I did another breakdown on the update script. Now i have it working with only command is the "assert ......preloaderp6601......." section and it does write it.

In the testing i found out that the "assert" tag will fail the script if the file it is linked to is missing. and if file is missing it will throw error 7.

---------- Post added at 02:36 AM ---------- Previous post was at 01:43 AM ----------

was that file (preloader_p6601.bin) in the update? With the "assert" tag used it will crash the script if it cannot find the files for the command being given.

because i just put together a script with this exact code and it worked for me. Flashed in twrp.
[BLU R1 HD Guides, News, & Discussion] _bfritz:
Yes. I unlocked the bootloader while on v6.1.

---------- Post added at 04:05 AM ---------- Previous post was at 03:40 AM ----------

It was the preloader image in the first version of the modified update zip for v6.1 to v6.6.

From a TWRP adb session:

# cd /external_sd/roms/
# ls -l BLU_R0010UU_V6.1_to_6.6_mod.zip
-rwxrwxrwx 1 root root 224505242 Sep 13 01:41 BLU_R0010UU_V6.1_to_6.6_mod.zip

# md5sum BLU_R0010UU_V6.1_to_6.6_mod.zip
82bbc6d7fb6b316c3cb2517d49d3023e BLU_R0010UU_V6.1_to_6.6_mod.zip

# sha1sum BLU_R0010UU_V6.1_to_6.6_mod.zip
e66f1d5e53556ca9c9c95fce6528582bcb6c1638 BLU_R0010UU_V6.1_to_6.6_mod.zip

# unzip -l BLU_R0010UU_V6.1_to_6.6_mod.zip preloader_p6601.bin
Archive: BLU_R0010UU_V6.1_to_6.6_mod.zip
Length Date Time Name
-------- ---- ---- ----
4194304 07-25-16 23:04 preloader_p6601.bin
-------- -------
4194304 905 files

# unzip -p BLU_R0010UU_V6.1_to_6.6_mod.zip preloader_p6601.bin | sha1sum
c3bb623bbbeac28fdfe699814508ffeba2c4f416 -

c3bb623bbbeac28fdfe699814508ffeba2c4f416 is also the checksum on my dd backup of /dev/block/mmcblk0boot0 .

I made that backup right after unlocking the bootloader and installing TWRP.
[BLU R1 HD Guides, News, & Discussion] mrmazak:
I got a different md5 on the preloader.bin when i did a read-back with spft and when i did it with miricle-box.

The spft file had md5 that matched a DD backup that [MENTION=5355478]ColtonDRG[/MENTION] did. And that backup did not work.

When I open a prloader.bin from any other phone i found online , in notepad++ , in first line it had "file info".

But when I open the spft saved preloader there was very many unreadable assci characters in the header and the end of file was too long. The file size is double that of the update preloader.

The file that did work was the one saved with miricle-box. When I open this file is looks much more similar to what I have for comparison. I cannot explain what is done different.

I did get my phone to go back and forth between the prime v6.1 preloader and the non-prime v12 preloader. both by using miricle-box and by using twrp.

i can share the update.zip with you if you can tear it appart and test with it.
[BLU R1 HD Guides, News, & Discussion] _bfritz:
Not sure if this helps at all, but the dd backup will be the entire 4MB partition:

$ ls -l mmcblk0boot0_preloader.bin
-rwxr-xr-x 1 brad users 4194304 Sep 12 23:26 mmcblk0boot0_preloader.bin

$ binwalk mmcblk0boot0_preloader.bin

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
0 0x0 Mediatek EMMC Flash Image Version 1
512 0x200 Mediatek Boot Header Version 1
532 0x214 Boot section Start 0x800 End 0x40800 Load-by-Bootrom
2056 0x808 Mediatek File Info File Type: ARM-Bootloader EMMC-Boot-Region Signature Type: SINGLE and PHASH Load Address: 0x200D00 File Length: 148988 Maximum Size: 262144 Content Offset: 0x300 Signature Lenght: 292 Jump Offset: 768 POST_BUILD_DONE

$ hexdump -C --length 128 mmcblk0boot0_preloader.bin
00000000 45 4d 4d 43 5f 42 4f 4f 54 00 00 00 01 00 00 00 |EMMC_BOOT.......|
00000010 00 02 00 00 ff ff ff ff ff ff ff ff ff ff ff ff |................|
00000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00000080

Whereas the preloader that SPFT needs is a 148988 byte chunk of that partition image:

$ dd if=mmcblk0boot0_preloader.bin of=preloader_n325b.bin bs=1 skip=2048 count=148988

$ ls -l preloader_n325b.bin
-rw-r--r-- 1 brad users 148988 Sep 17 08:23 preloader_n325b.bin

$ sha1sum preloader_n325b.bin
9275ab177b61ecd32b7f472906a2d7476afb85f3 preloader_n325b.bin

$ hexdump -C --length 128 preloader_n325b.bin
00000000 4d 4d 4d 01 38 00 00 00 46 49 4c 45 5f 49 4e 46 |MMM.8...FILE_INF|
00000010 4f 00 00 00 01 00 00 00 01 00 05 03 00 0d 20 00 |O............. .|
00000020 fc 45 02 00 00 00 04 00 00 03 00 00 24 01 00 00 |.E..........$...|
00000030 00 03 00 00 01 00 00 00 4d 4d 4d 01 0c 00 01 00 |........MMM.....|
00000040 01 00 00 00 4d 4d 4d 03 64 00 07 00 90 01 00 00 |....MMM.d.......|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00000080

Took me a while to figure that out after my first soft brick.
[BLU R1 HD Guides, News, & Discussion] bibikalka:
Great catch !!! That's why TWRP would refusing to write the 4Mb image - it would not fit !!!

So it's interesting that that assert command actually writes the preloader starting from a certain offset which is not zero. While dd does start from zero, at least when reading. But I now wonder if one tries to dd the preloader, if it would start from the same non-zero offset of 2kB. I think this pretty much explains all the preloader confusion that out there !

Btw, what was the nature of your soft brick ?
[BLU R1 HD Guides, News, & Discussion] mrmazak:
That does help explain what I was seeing. And perhaps also puts light onto why you can DD copy the boot0 section but not write to it.

Could it be that first chunck that starts "EMMC BOOT" is write protected and the next section is writeable.

I want to know if what I have tested on my phone will also work on others. But am concerned if I post untested update.zip, that someone will blindly just use it without knowing the risks. Or without knowing how to use it.

***file removed***
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I haven't really read this thread but seeing you are testing on your own phone have you upgraded to 6.6 via OTA and then was able to switch back to prior 6.6 preloader?

If not, really that should be the test.
[BLU R1 HD Guides, News, & Discussion] mrmazak:
Yes in the end that may be what I do. But I am looking at it like this. I am tring to help those who are "stuck in quicksand" and I don't think jumping in there with them is the best choice at this time, not yet. And I was also more-so reaching out to some who are apparently more versed in Android and Linux than me. I found something out by dumb luck and thought it would benefit a more experienced dev. And as it turns out the more experienced dev has also figured the same thing out and has explained what it means, instead of me just saying "look at this, what does it mean?"
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Sounds good.

But at this time it isn't confirmed to work, for flashing 6.6 preloader to prior preloader.

No one has actually downgraded from 6.6.
[BLU R1 HD Guides, News, & Discussion] tonydd:
Thanks
[BLU R1 HD Guides, News, & Discussion] bibikalka:
A good way to test this is to try to dd the preloader in (with & without the 2kb starting offset), and see what works by reading it back and doing checksums. Obviously, no reboots in between, if you don't want a brick :D Hopefully, by the end of the tests you should be able to leave it in a good state.

Another way is to dd in a few kB's of zeros into the preloader, read back, and see where they went. I suspect that it'll dd past the 2kb address, just the way the preloader looks in the update file. eFUSE is another issue to worry about, if V6.6 preloader can be restored back to V6.1, does it really help, and does it still boot ? Or is there an anti-rollback check?
[BLU R1 HD Guides, News, & Discussion] kal250:
So I reverted back to 6.1 then applied 6.1 to 6.6 safe update via TWRP, everything going pretty good so far, except.... Initially I simply flashed the TWRP 6.6 provided by vampirefo but there was some weird issue with solid explorer or system app remover being unable to make changes to system. Well i can confirm this issue is also present using this method, I'm wondering if the Aug security patches closed permissions or if something else is going on... I can boot into TWRP and mount system then delete apk folders with no problem, just no write access within the OS itself. Any clues or suggestions??? I have an email into solid explorer dev with logs, hopefully they see something.....
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I would suggest a different file manager, try es file explorer, I use it, and can delete anything I want.

I think the problem is the apps you are using,not the ROM.
[BLU R1 HD Guides, News, & Discussion] kal250:
Solid explorer worked without a problem in 6.5 and 12( i purchased a license because it worked well, es is too bloated for my taste), never had a problem with root access except one time my permissions were set wrong from a botched script.... This is new and unique to 6.6, getting denied in other apps that require root access as well....
[BLU R1 HD Guides, News, & Discussion] mrmazak:
I agree the newest es is bloated. I use es version 3.2.3.1 And refuse to allow it to update. I realy like this version. It does have trouble with one drive because one drive complains about the old bersion, oh well.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I am not seeing this, to me it's the apps you use, they may not work with 6.6 perhaps they need to be updated.

My point was to try es file explorer and see if you had problems with it as well going off your answer you didn't.

meaning es file explorer worked as it should, you just don't like it.

The apps that give you problems all might need to be updated, writing the author's of the apps would be your best bet.
[BLU R1 HD Guides, News, & Discussion] kal250:
I have contacted the dev and according to their response from what they see in the log is that RW access to system is being denied,they are looking into the issue, however this only happens on 6.6. so something has changed.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Can you give a link to an app other than a paid app or uninstaller that I can test. From the last post of yours suggest it's the way you root.

My root is different than yours, so I want to test a root app that doesn't work for you.
[BLU R1 HD Guides, News, & Discussion] kal250:
This app also fails, i use it when im unsure of folder locations, but its a free version that also returns with a fail(due to restriction in system)

https://play.google.com/store/apps/details?id=com.jumobile.manager.systemapp

I am rooted systemless with latest chainfire supersu binaries
[BLU R1 HD Guides, News, & Discussion] vampirefo:
That is an uninstaller, I don't use them they are of no use to me. I am looking for a rooted app that doesn't work for you that isn't an uninstaller.

Such apps as uninstallers I won't install, if you come across something else let me know.
[BLU R1 HD Guides, News, & Discussion] kal250:
Eh im sure I'll figure it out.... But thanks anyway :)
[BLU R1 HD Guides, News, & Discussion] bibikalka:
Do you have SuperSu installed ? Can you see if it's denying your app root access ?

If the root is broken in 6.6 for all apps, this is really the SuperSu issue, not anything else. But you need to troubleshoot a bit. What about RootChecker ?
[BLU R1 HD Guides, News, & Discussion] kal250:
Rootchecker shows successful root, not sure whats going on, i applied root from twrp prior to first boot after running 6.6 safe update from twrp
[BLU R1 HD Guides, News, & Discussion] _bfritz:
No display at all, starting with first boot after the failed v6.1 to v.6.6 upgrade. Just the red LED when plugged into USB. Tried to use SPFT, but phone would not show up as /dev/ttyACM0 . Neither Power + VolUp nor holding down power button did anything noticeable.

After I let the phone sit for about 36 hours, it showed back up as /dev/ttyACM0 ...although not consistently. Battery was nearly dead when I finally got the display back after a couple of SPFT downloads.

Not sure, but it seems like letting the battery discharge all the way reset something. But then SPFT was still flaky until the battery charged back up some.
[BLU R1 HD Guides, News, & Discussion] deepu458:
Hi Buddy, even i ended up in the same issue, actually i got the phone yesterday and first thing i did was unlocking bootloader which went fine and then booted back to load all the zips. Then i flashed the TWRP and followed by that i ran this zip which was there in OP and thats it the screen went off and i cant do anything with that phone. So how long do i need to wait for this phone to be backup online or do something?

Can u explain me in bit clear if there is anything i can do to make this back running? or any other solutions from this Soft or Hard brick?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
With all these problems, I can't see how this can be called safe.
[BLU R1 HD Guides, News, & Discussion] deepu458:
Yes i support your comment. i agree its my fault that I shouldn't have flashed this zip. BTw now i am getting now this error, see if i can make this to live with any way?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
I can't help you, had you flashed my 6.6 ROM, you would be up an running no problems, this method is by far the most dangerous method available and to call it safe is inexcusable.

It should be called the most risky method, so far it appears to have more bricks than confirms.

Edit.

Try this http://xdaforums.com/showthread.php?p=68036248
[BLU R1 HD Guides, News, & Discussion] _bfritz:
When I was getting "ERROR : S_DL_GET_DRAM_SETTINGS_FAIL (0x13BE)" (shows up as 5054 in Linux version of SPFT), I was able to fix it by specifying the location of a preloader image.

This post might be helpful.
[BLU R1 HD Guides, News, & Discussion] vampirefo:
Hopefully that helps him.
[BLU R1 HD Guides, News, & Discussion] deepu458:
Thx for helping out buddy with the preloader u gave me, now at least i can now see the screen where it gives 3 options to go with either Recovery or Fastboot or Normal. But when i select anyone of that it is again going to that dead screen.

How can i boot into the TWRP recovery safely and get back to a working ROM? Sry if im being a noobe. kindly help me
[BLU R1 HD Guides, News, & Discussion] _bfritz:
Same thing happened to me when recovering my R1. If I'm not mistaken, the screen you see is from the little kernel ("lk") early in the boot process.

If you download ("flash") the remaining boot partitions:

boot

recovery

logo

secro

tee1

tee2

with SPFT, I suspect it will boot again. If it still doesn't work, you might try adding lk and preloader to the download list.
[BLU R1 HD Guides, News, & Discussion] deepu458:
Thx i really do appreciate ur help, but i cant find the following list of items in SPFT. Where can i download those items?
[BLU R1 HD Guides, News, & Discussion] _bfritz:
You made a backup from TWRP before trying the modified update zip, right? ;)

I attached my copies. Standard disclaimers apply...

USE AT YOUR OWN RISK. MAY HARD BRICK YOUR PHONE. PHONE MAY EVEN BURST INTO FLAMES AND BURN DOWN YOUR HOUSE.

$ sha1sum *
98ddeaa9096bebe51a50e087a1bc9d7a2d848e89 boot.img
75ec1fde1632ec0372696043586b7c59347a6691 lk.bin
f6f428f325fe12def5c1def4d068feeb8231b34b logo.bin
6c1e6b2ffdca9490a50f93685642e7aea7b79736 r1hd-spft-scatter.txt
5899c201381cd43938bd00bc2c0266bbb2fa4e33 recovery.img
c643c0a9da2e0144f38ed55b2629b6de4f98e7fb secro.img
d665b492ea591e337aa2de3ba8b46f3ee5e5ee4a trustzone.bin
[BLU R1 HD Guides, News, & Discussion] deepu458:
Hi

Man u r the best. Thx for the help. Its my bad i didn't do the backup before i flashed the zip.

But if i use the following uploaded content i should be going with factory data reset right?
[BLU R1 HD Guides, News, & Discussion] _bfritz:
I think so, but I don't recall what state the update failure leaves the system partition in.

Other things that might be helpful...

Once you have fastboot working again, you can use:

fastboot boot twrp-3.0.2-1-r1hd-lopestom.img

using https://na.mirrors.coltondrg.com/coltondrg/r1hd/twrp-3.0.2-1-r1hd-lopestom.img to to boot TWRP and do a backup to SD card. Might be useful if you have data on the phone you don't want to lose and you're getting ready to try a factory reset.

If a factory reset does not work, this thread will help you get back to a useable state.
[BLU R1 HD Guides, News, & Discussion] deepu458:
Thanks for all the help my friend, without ur help i wouldn't had recovered my phone. So when the battery got almost dead i was able to bring back to 6.1. Then used the [MENTION=2472806]vampirefo[/MENTION] ROM thread help i was able to upgrade to 6.6.

Anyways i would like to throw a Big Thanks( [MENTION=2472806]vampirefo[/MENTION] & [MENTION=514359]bfritz[/MENTION] ) for u folks.
[BLU R1 HD Guides, News, & Discussion] _bfritz:
Happy to help. Good to hear you got it working again.
[BLU R1 HD Guides, News, & Discussion] bibikalka:
I see quite a bit of hate over here !!! :D

For the record, I don't see any bricks here, everything was recovered. I am not sure what happened to [MENTION=6409421]deepu458[/MENTION], the updated zip does not even touch the preloader.

Here is what the update looked like when _bfritz ran it first (before being fixed):

...
assert(package_extract_file("uboot.img", "/tmp/lk.img"),
write_raw_image("/tmp/lk.img", "lk"),
delete("/tmp/lk.img"));
apply_sig(package_extract_file("sig/boot.sig"), "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/boot");
show_mtupdate_stage("/cache/recovery/last_mtupdate_stage");
ifelse (
less_than_int(get_mtupdate_stage("/cache/recovery/last_mtupdate_stage"), "1") ,
(
ui_print("start to update general image");
package_extract_file("lk.bin", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/lk");
package_extract_file("secro.img", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/secro");
package_extract_file("logo.bin", "/dev/block/platform/mtk-msdc.0/11230000.msdc0/by-name/logo");
assert(package_extract_file("preloader_p6601.bin", "/tmp/preloader_p6601.bin"),
write_raw_image("/tmp/preloader_p6601.bin", "/dev/block/mmcblk0boot0"),
delete("/tmp/preloader_p6601.bin"));

So I am actually surprised that there was a semi-brick in this post :

http://xdaforums.com/showpost.php?p=68731132&postcount=22

The update failed when the preloader (V6.1) command ran, so I presume its one of the prior V6.1 image files could have caused the issue when written on the top of the same V6.1 ?
[BLU R1 HD Guides, News, & Discussion] vampirefo:
So you think this is OK? Wow no it's not, hate? Has nothing to due with hate this thread does nothing but brick people's phones it serves no purpose.

Do the right thing and remove the word safe from the title, or at least tell people the truth the risk of bricking their phone is greater than the odds of actually upgrading their phone.

Flash the zip, then brick your phone wow neat trick.

People flash this zip, cause it says safe in the title, it's not safe, nor does it upgrade a phone, it bricks the phone then people are on their own to fix their phones.

Once they fix their phone they use other methods to upgrade phone, so exactly what is the goal of this thread?
[BLU R1 HD Guides, News, & Discussion] bibikalka:
Again, only 2 posters here had this issue. The first one was not so clear in terms of what the cause was, and the bricking was mentioned only in passing, so I did inquire about that in later posts:

http://xdaforums.com/showpost.php?p=68776458&postcount=43

The 2nd bricker did pop up only recently, so I renamed the thread (no need to overreact ...).