Identify your bootloader version:

[bibikalka]

In a strict sense, the procedure doesn't leave the bootloader intact - it first writes the newer version (which is part of the stock ROM) to later replace it back with the original one. And this "later" may be crucial - if in-between something bad happens (bad battery level, bad cable, power outage on the PC side), game over.
What's the ratio of successful vs. bricking here?
Unfortunately, nobody seems to have followed the path @Vlasp had suggested a year ago: to trim down stock ROMs to explicitly exclude bootloader files and install instructions (and possibly add su, and disable ota and ads). I understand that with FF we're no longer limited to signed ROMs, so this should be feasible, and scriptable for future ROM versions, no? (If I could extend days to 36 hours...)

Just saw this - a bit of a weird concern. Given that TWRP/Flashfire are super robust, the 2 zips can be flashed in the same sequence pretty much every time, so the # of devices with issues is probably about 0. I presume the conversation is about this post.

 

[Master Melab]

While playing with AFTV2 tools quite a bit, I thought it'd be convenient to have some way to identify what bootloader version one has (given bricking implications & all). Doing checksums on the full TEE1 & UBOOT partitions is not very useful, because the empty area in the partitions may have junk, and that would impact the checksum. So something slightly different is needed.

Here is what I propose, one can read the first few bytes of TEE1 & UBOOT partitions, and then look at them with a hex editor. Fairly low tech, but there you go ... Unfortunately, "hexdump" is not present by default on Fire, so a few more manipulations are required. First, run this with adb (can also be read with AFTV2 tools):

adb shell
su
mkdir /sdcard/tmp/
dd if=/dev/block/mmcblk0p4 of=/sdcard/tmp/04_uboot.img
dd if=/dev/block/mmcblk0p9 of=/sdcard/tmp/09_tee1.img
cd /sdcard/tmp
md5 *.img
exit
exit
adb pull /sdcard/tmp

Then, with a hex editor (such as Frhed), look at the first few bytes of these images on your PC. On linux it's even easier, just do "cat -c 8 *.img | hexdump". You should see something like the following:

04_uboot.img: UBOOT: 88 16 88 58 [COLOR="Red"]b4 33 06 00[/COLOR] 4c 4b 00 00 "LK"
09_tee1.img:  TEE1:  88 16 88 58 [COLOR="Red"]00 3c 10 00[/COLOR] 54 45 45 00 "TEE"

The 4 bytes in red are key to identify the version. Please see the table below for the data I've compiled so far. Let's add to it as more versions become available/known (if your combination is not listed, please post here):

UBOOT
d8 27 06 00 Unreleased, 5.0.0, (Build date Saturday, August 1, 2015, 10:39 PM GMT)
b4 33 06 00 5.2.2_053820 5.0.1
54 3f 06 00 5.2.2_055120 5.0.1
e4 3b 06 00 5.4.1_112720 5.1.1
38 34 06 00 5.4.2_168620 5.1.2
78 34 06 00 5.4.4_271020 5.1.4
b8 3c 06 00 5.5.2_153420 5.3.1.0

TEE1
00 3c 10 00 Unreleased, 5.0.0, (Build date Saturday, August 1, 2015, 10:39 PM GMT)
00 3c 10 00 5.2.2_053820 5.0.1
00 3c 10 00 5.2.2_055120 5.0.1
00 3c 10 00 5.4.1_112720 5.1.1
00 3c 10 00 5.4.2_168620 5.1.2
00 3c 10 00 5.4.4_271020 5.1.4
90 84 11 00 5.5.2_153420 5.3.1.0

@DoLooper, @kirito9, @sd_shadow, @Kramar111, @zeroepoch, @hwmod, @Tomsgt

Are you talking about the first-stage bootloader? If you are, is it verified by the boot ROM?

 

[CoolChenz]

thx

 

[wfg97079]

Device is at 5.3.1.0

uboot:
88 16 88 58 C0 9B 0E 00 54 45 45 00 00 00 00 00
Tee1
4B 42 50 4F 98 0B 00 00 A8 0B 00 00 00 00 00 00

Can anyone identify?

 

[i.REN]

I suppose it's on 5.1.2 but I'm not sure what that means pertaining to unlock the bootloader.