Database Info

[DEV][GUIDE][REF] Customize Internal Partition Layout for MTD Devices

See Post #2 for current known stock partition parameters for various devices. Your contributions for missing devices are welcome and appreciated. Cheers!
Introduction
This guide / reference aims to be a complete article on customizing, resizing and/or re-ordering the internal partition layout on most (any?) Android MTD-based device. I have seen many questions around the various forums on how to get more internal data so I thought I'd share my developments. Hopefully this will become a valuable resource for kernel builders/hackers.
The guide is especially valuable (and, in the case of my kernel builds, originally designed for) the Xperia 2011 line, but from what I know it could be applied to nearly any Android device where kernel source/flashing is possible.
I would like to gather stock partition information for various devices and place them into Post #2. If you can at least give me your Partition Info from ATAG (see "Gathering information" section), I can create a reference for all kernel developers. Thank you!
Requirements
Android SDK
Ability to build a kernel (this guide does not teach that)
Ability to flash a kernel (unlocked bootloader, etc)
Bootloader which exposes Partition info via ATAG on startup (see "Gathering information" section)
Device which uses MTD Partition Map (Don't know how to check this, I think most Android devices do anyway)
Warning
As far as I know, following this guide and using precise calculation that you double and triple check before flashing will not result in a hard brick - however I can not guarantee it. Some devices may have "obscure" partition maps or some "protected" sectors for one reason or another, and modifying these *may* result in either a hard-brick (unlikely) or a permanent inability to restore your device to 100% stock (very likely) for warranty and/or DRM purposes. You have been warned. I/we/anyone may not be held accountable for any of these events should they occur, for you are doing this at your own risk and with your own responsibility.
Gathering information
The first thing you'll want to do for the sake of accuracy is to flash to a 100% stock firmware. In the case of Xperia 2011 devices, flash the latest stock FTF for your device.
With the stock firmware now installed, the second thing you will need to do is to flash a custom kernel that is rooted and has busybox installed. In most cases, a CM7/9/10 kernel will do nicely.
Power-off your device. Execute the following command from shell/console, and then press enter:
Code:
adb wait-for-device && adb shell dmesg
After pressing enter, the console will wait at the prompt as intended. Now, power on your device and immediately plug in the USB cable. I assume the ADB drivers are already installed.
Shortly (5-15 seconds) you should see a mass output from the kernel followed by a return to your shell prompt. If you don't, either your kernel or bootloader does not support it. Try a different kernel. If you still don't, then sorry but I think we can't do it for your device.
Scroll right to the top of the dmesg output, you should see something similar to this:
Code:
<6>[ 0.000000] Initializing cgroup subsys cpu
<5>[ 0.000000] Linux version 2.6.32.9-KRsH ([email protected], Linaro 4.7) (gcc version Linaro 4.6.2 20111004) #8 PREEMPT Thu Oct 25 15:57:27 EST 2012
<4>[ 0.000000] CPU: ARMv7 Processor [511f00f2] revision 2 (ARMv7), cr=10c53c7d
<4>[ 0.000000] CPU: VIPT nonaliasing data cache, VIVT ASID tagged instruction cache
<4>[ 0.000000] Machine: zeus
<6>[ 0.000000] Partition (from atag) system -- Offset:2e4 Size:9c4
<6>[ 0.000000] Partition (from atag) userdata -- Offset:ca8 Size:be0
<6>[ 0.000000] Partition (from atag) cache -- Offset:1cb4 Size:32c
<6>[ 0.000000] Partition (from atag) appslog -- Offset:1888 Size:42c
<4>[ 0.000000] Memory policy: ECC disabled, Data cache writeback
...see those "Partition (from atag)" lines? That's what we need! Copy this information down and move on to the next section.
Additional verification and hidden partitions (optional)
As far as I know, this is only possible with Xperia 2011 devices. If you know of a method for other devices, please let me know.
We can additionally verify the ATAG information and map extra "hidden" partitions such as boot (kernel) by examining the SIN files inside an FTF. I will assume that you know how to use Flashtool already as I won't go into much detail here.
First, we need to enable the development features of Flashtool. In the program folder, open "config.properties" and edit/add the line like so:
Code:
devfeatures=yes
Next, extract your stock FTF bundle with any ol' ZIP extractor, load Flashtool, and select "Tools" > "SIN Editor", and open a particular SIN file that you want to verify/unhide. In this example, we will open system.sin. The "Partition Info" field is what we want. Behold:
Code:
STOCK SIN:
system: 0400000001000080E4020000C4090000
-- --|------||------|
| | | |
type? (elf/yaffs) _/ | | \____ byte-reversed size
| |
unknown ____/ \____________ byte-reversed offset
The second last 8-bytes are the offset and the last 8-bytes are the size. By "byte-reversed" I mean that you read each byte from end to beginning, but not swap the bytes themselves. Thus the size above, reading "C4090000" is actually "000009C4". And as you can see, this matches 100% to our ATAG of 9c4 for system size. Correct sir! Additionally, the offset of "E4020000" > reversed to "000002E4" also matches.
So now, we can open "kernel.sin" and do the same, because we also want to partition "boot" (why not?). In this device (Xperia Play/Xperia Neo L), kernel.sin gives us 03000000220000808002000064000000 which means that the size is 64 and the offset is 280.
Calculations
From the partition info via ATAG, we can now build "stock" mtdparts information to apply to our kernel. Using the example(s) above, we can now build this information:
Code:
system : [email protected]
userdata : [email protected]
cache : [email protected]
appslog : [email protected]
boot : [email protected]
Note the syntax of size@offset. Next, we must convert the hex values to decimal, then multiply by 128 (I do not know if 128 is the same multiplier for all devices, please double check and let me know). This will give us the exact sizes and offsets in kilobytes.
Code:
system : [email protected]
userdata : [email protected]
cache : [email protected]
appslog : [email protected]
boot : [email protected]
Alright, so that is a 100% stock partition map for this device - except we also have the boot (kernel) mapped now too. Here is a (crappy) visual representation of it:
Code:
reserved | boot | /system | /data | appslog | /cache |
first 80MB | 12.5MB | 312.5MB | 380MB | 133.5MB | 101.5MB |
Note: Not to scale :)
You may have noticed that the order we (and ATAG) lists the partitions in does not match the actual order of the partitions. It is quite important to retain the order of the partitions as specified in ATAG, because that's the order they will be mapped in. I.e. system will remain mtdblock0 and cache will remain mtdblock2. Any extra partitions should always go after these defaults.
Formatting for kernel
To specify the mtdparts parameter for the kernel to use is trivial. Doing this will over-ride the ATAG map (from bootloader) and everything in the system - including Recovery - will see your map from the kernel. Search your default config file in your kernel for the value "CONFIG_CMDLINE" and you should find a value like this :
Code:
CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc"
Using the information we have above about our partition map, we add a new parameter here with "mtdparts=msm_nand:". The syntax is as follows:
Code:
mtdparts=msm_nand:[size]@[offset](name){,[size]@[offset](name)}{...}
Remember that we converted our size and offsets to kilobytes (for better readibility) so we need to specify size unit of k. The new parameter, from our above examples, becomes this:
Code:
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
Don't forget to retain the order! And so, our full line looks like this:
Code:
CONFIG_CMDLINE="console=ttyMSM2,115200n8 androidboot.hardware=semc mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)"
NOTE: Depending on your kernel, you may also need to enable the following line in your config:
Code:
CONFIG_MTD_CMDLINE_PARTS=y
And we're all done. If you build your kernel now, you will be able to mount (or at least dd from) the appslog and boot partitions.
Resizing partitions
This is somewhat trivial, the most difficult part is probably over - but this step can be tedious, albeit not very complicated. Anybody with an above average IQ would have already figured this out - we simply change the size of one partition and adjust the offsets of it's following partitions to accommodate for the change. Here is one good example that I use for the MIUI ROM for the Xperia Play and Neo L, compared to the stock examples shown above:
Code:
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot)
...and a visual representation of this new map:
Code:
reserved | boot | /system | /data |/cache|
first 80MB | 12.5MB | 280MB | 639MB | 8MB |
Note: Not to scale :)
Hopefully that's enough to make sense. Remember to verify your modified partitions. This can easily be done by adding the size+offset of a partition, giving the offset of the next partition. E.g. in this mod, userdata ends at 1036288 (654848+381440) which matches the offset for the next partition - cache.
Troubleshooting/Recovering from modified partitions
In some cases, your new kernel may not boot. A common issue is that the kernel logo will show, and the device will shortly reboot (kernel bootloop). This can be solved by formatting your partitions with fastboot after flashing the new kernel, usually system and userdata are all that is needed:
Code:
fastboot format system
fastboot format userdata
If you wish to return to a stock partition layout, sometimes flashing a non-modified kernel is not enough. You may get stuck on kernel logo even after formatting system and userdata. In this case, flashing a stock Firmware and setting your phone back to scratch should result in a 100% original device. But if your phone is still bricked, sorry but it's not my fault. You probably did something wrong.
#####
OK, that's the guide done for now. Any questions or suggestions on the guide, please let me know! Also, refer to post #2 for some stock partition map reference.

Finding Stock Partition Info For Your Device
Three methods:
Most reliable - See the section "Gathering info" above to get it from ATAG
Only shows size without offset - do "cat /proc/mtd" from adb shell. Can be used to test if you're on stock partitions or not, or to verify partition is big enough for update ZIP's (with sed/grep).
Xperia 2011 Only - Examine SIN header as outlined above. This method is difficult to determine mtd block order but I'm 99% sure the order is same for all Xperia 2011 devices (system=mtd0, userdata=mtd1, cache=mtd2).
Stock Partition Parameters for Various Devices
Xperia 2011 Range:
Code:
[B]anzu (Arc) (LT15) (HDPI):[/B]
(03) kernel - [email protected] ([email protected]) (unmapped)
(04) system - [email protected] ([email protected])
(05) amss - [email protected] ([email protected]) (unmapped)
(06) amss_fs - [email protected] ([email protected]) (unmapped)
(08) adsp - [email protected] ([email protected]) (unmapped)
(09) userdata - [email protected] ([email protected])
(10) vendor - [email protected] ([email protected])
(0B) fota0 - [email protected] ([email protected]) (unmapped)
(0C) fota1 - [email protected] ([email protected]) (unmapped)
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](appslog),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1),[email protected](boot)
[B]ayame (Arc S) (LT18) (HDPI):[/B]
(03) kernel - [email protected] ([email protected]) (unmapped)
(04) system - [email protected] ([email protected])
\ this is odd, there is 2048k unallocated between boot and system (SEMC made a mistake?)
(05) amss - [email protected] ([email protected]) (unmapped)
(06) amss_fs - [email protected] ([email protected]) (unmapped)
(08) adsp - [email protected] ([email protected]) (unmapped)
(09) userdata - [email protected] ([email protected])
(10) vendor - none
(0B) fota0 - [email protected] ([email protected]) (unmapped)
(0C) fota1 - [email protected] ([email protected]) (unmapped)
mtdparts=msm_nand:[email protected](system),[email protected](userdata),[email protected](cache),[email protected](boot),[email protected](amss),[email protected](amss_fs),[email protected](adsp),[email protected](fota0),[email protected](fota1)
[B]haida (Neo V) (MT11) (HDPI):[/B]
[I]Same as ayame (Arc S) (LT18)[/I]
[B]hallon (Neo) (MT15) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
[B]iyokan (Pro) (MK16) (HDPI):[/B]
[I]Same as ayame (Arc S) (LT18)[/I]
[B]mango (Mini Pro) (SK17) (MDPI):[/B]
??
[B]satsuma (Active) (ST17) (MDPI):[/B]
??
[B]smultron (Mini) (ST15) (MDPI):[/B]
??
[B]urushi (Ray) (ST18) (HDPI):[/B]
??
[B]phoenix (Neo L) (MT25) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
[B]zeus/zeusc (Play) (R800) (HDPI):[/B]
[I]Same as anzu (Arc) (LT15)[/I]
R800a (and probably i/at, but not x) has unallocated vendor partition. Needs one-time flash of Vendor-enabled FTF (e.g. phoenix or anzu) to allocate it otherwise the vendor map will present I/O errors.

Reserved again (just in case)

Thanks for the info. You have used the same for MIUI for Neo L and Play and we have good internel memory..
Thanks for sharing

Very nice work mate! (Especially for using ATAGs...)
I just started the related thread:
"[DEV][REF] El Grande Partition Table Reference"
To collect detailed partition info from various devices...

E:V:A said:
Very nice work mate! (Especially for using ATAGs...)
I just started the related thread:
"[DEV][REF] El Grande Partition Table Reference"
To collect detailed partition info from various devices...
Click to expand...
Click to collapse
Heh nice! Yours looks a bit more hardcore than mine, I've never used any of those tools
I started this guide so I can port kernels to various devices for Xperia 2011 range, and also to help other devs appeal the users who crave for more internal partition space. But so far, none of these people seem to have the patience to lend a hand with gathering data

Xperia Arc (anzu - LT15i_4.1.B.0.587_Generic Global World)
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
I've been talking to wedgess about the use of the cache partition... been poking around and he pointed me in your direction... so, here we go! :highfive:

[NUT] said:
Xperia Arc (anzu - LT15i_4.1.B.0.587_Generic Global World)
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
I've been talking to wedgess about the use of the cache partition... been poking around and he pointed me in your direction... so, here we go! :highfive:
Click to expand...
Click to collapse
Awesome, thanks for the partition info. I *hope* to get all Xperia 2011 device info so I can build Turbo Kernel for all. From what I can see, Arc partitions are identical to Play and Neo L. So maybe all Xperia 2011 devices are the same.
Since the cache partition is not an FTF file, it goes after vendor - so offset would be 940544 (kb). The size I am not sure and might vary per device. /proc/mtd (or /proc/partitions) should tell you.
Also, you can remove vendor partition - because all ROM's just mount it to the folder at /system/vendor so any vendor files you need can go into system partition, and then you can remap/reclaim vendor.

CosmicDan said:
Awesome, thanks for the partition info. I *hope* to get all Xperia 2011 device info so I can build Turbo Kernel for all. From what I can see, Arc partitions are identical to Play and Neo L. So maybe all Xperia 2011 devices are the same.
Since the cache partition is not an FTF file, it goes after vendor - so offset would be 940544 (kb). The size I am not sure and might vary per device. /proc/mtd (or /proc/partitions) should tell you.
Also, you can remove vendor partition - because all ROM's just mount it to the folder at /system/vendor so any vendor files you need can go into system partition, and then you can remap/reclaim vendor.
Click to expand...
Click to collapse
Might be different for the Arc S (ayame) ... i'm looking into the official firmware release now to confirm... but as i used a FTF for my LT15i to gain size on my userdata a while back this is what i get from the dmesg ATAG lines...
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
cache 32C @ FA4 103936 @ 512512 101Mb
userdata D20 @ 12D0 430080 @ 616448 420Mb
Seeing cache between system and userdata ... but no vendor partition anymore
I also notice my endpoint at 918Mb of 1000MB (as sony states in their whitepaper: 1GB) that would be inside the phone ... lost space or do you know a reason perhaps?

[NUT] said:
Might be different for the Arc S (ayame) ... i'm looking into the official firmware release now to confirm... but as i used a FTF for my LT15i to gain size on my userdata a while back this is what i get from the dmesg ATAG lines...
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
cache 32C @ FA4 103936 @ 512512 101Mb
userdata D20 @ 12D0 430080 @ 616448 420Mb
Seeing cache between system and userdata ... but no vendor partition anymore
I also notice my endpoint at 918Mb of 1000MB (as sony states in their whitepaper: 1GB) that would be inside the phone ... lost space or do you know a reason perhaps?
Click to expand...
Click to collapse
1GB = 1024MB, not 1000MB
Well on stock zeus/phonex, as the OT shows, boot + system + data + appslog (vendor) + cache = 940MB. Along with the ~80MB of reserved data at the beginning for radio/baseband and such, that comes to 1020MB. I assume the last missing ~4MB of the full 1GB is reserved for remapping bad blocks (i.e. wear-leveling).
That FTF is completely weird, just like the 420MB space mod for some devices is actually dangerous (size of one partition overlaps the offset of another by about 20MB). If you visualize your map you just showed, there is some wasted space after /system map. Anyway, the cache partition on zeus board goes right at the end, after vendor. So yeah the maps are obviously different, however I think the 1020MB NAND size is possibly the same for all msm-7x30/Snapdragon S2 SoC devices (not just Sony).
Could you ensure you have flashed a 100% original/genuine FTF file and get full ATAG information again?

CosmicDan said:
1GB = 1024MB, not 1000MB
Click to expand...
Click to collapse
well... thats open for debate in some way, GB != GiB. For me 1GB should be 1024Mb though ...
CosmicDan said:
Well on stock zeus/phonex, as the OT shows, boot + system + data + appslog (vendor) + cache = 940MB. Along with the ~80MB of reserved data at the beginning for radio/baseband and such, that comes to 1020MB. I assume the last missing ~4MB of the full 1GB is reserved for remapping bad blocks (i.e. wear-leveling).
Click to expand...
Click to collapse
most likely yes... sounds fair atleast...
CosmicDan said:
That FTF is completely weird, just like the 420MB space mod for some devices is actually dangerous (size of one partition overlaps the offset of another by about 20MB). If you visualize your map you just showed, there is some wasted space after /system map. Anyway, the cache partition on zeus board goes right at the end, after vendor. So yeah the maps are obviously different, however I think the 1020MB NAND size is possibly the same for all msm-7x30/Snapdragon S2 SoC devices (not just Sony).
Click to expand...
Click to collapse
i've been playing around with wedgess' kernel:
Code:
system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata 1258 @ CA8 601088 @ 414720 587Mb
cache 40 @ 1F00 8192 @ 1015808 8Mb
EOD: 1024000 1000Mb
Thats what i am using now, thanks to your guide
{
"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"
}
CosmicDan said:
Could you ensure you have flashed a 100% original/genuine FTF file and get full ATAG information again?
Click to expand...
Click to collapse
Will report back with the defaults from the stock rom later... going to bed now... 7:36am here now... haven't been sleeping yet :silly:

Yeah true, the whole kilobyte/kibibyte thing.... they still display KB/MB instead of KiB/MiB in most things even though they're in 1024 unit (shell listings, file explorer properties, etc.) but storage vendors do use true 1000 units, 32GB SDCard for example... but then the software doesn't so it's stupid and confusing So yeah, most people have not adopted it, thus it's better to assume that all KB/MB/etc measurements are done in powers of 1024 still.... because they're old school
I wonder, in pther Android ROM's is it corrrect? In MIUI/Turbo UI it shows 639MB in Storage (instead of MiB) so I assume even Android OS itself is also "wrong" haha. Titanium Backup is the *only* app I know of that shows sizes in power of 1000.... and that confuses a lot of people.

CosmicDan said:
Yeah true, the whole kilobyte/kibibyte thing.... they still display KB/MB instead of KiB/MiB in most things even though they're in 1024 unit (shell listings, file explorer properties, etc.) but storage vendors do use true 1000 units, 32GB SDCard for example... but then the software doesn't so it's stupid and confusing So yeah, most people have not adopted it, thus it's better to assume that all KB/MB/etc measurements are done in powers of 1024 still.... because they're old school
I wonder, in pther Android ROM's is it corrrect? In MIUI/Turbo UI it shows 639MB in Storage (instead of MiB) so I assume even Android OS itself is also "wrong" haha. Titanium Backup is the *only* app I know of that shows sizes in power of 1000.... and that confuses a lot of people.
Click to expand...
Click to collapse
Code:
SIN name HEX [email protected] DEC (in k) SIZE
amss.sin: ??? E4 @ 10 29184 @ 2048 28Mb
amss_fs_anzu.sin: ??? 68 @ F4 13312 @ 31232 13Mb
adsp.sin: ??? 6C @ 15C 13824 @ 44544 13Mb
fota0.sin: ??? 5C @ 1C8 11776 @ 58368 11Mb
fota1.sin: ??? 5C @ 224 11776 @ 70144 11Mb
kernel.sin: boot 64 @ 280 12800 @ 81920 12Mb
LT15i: anzu
system.sin: system 9C4 @ 2E4 320000 @ 94720 312Mb
userdata.sin: userdata BE0 @ CA8 389120 @ 414720 380Mb
vendor.sin: vendor 42C @ 1888 136704 @ 803840 133Mb
cache 330 @ 1CB4 104448 @ 940544 102Mb
EOD: 1044480 1020Mb
LT18i: ayame
system.sin: system C80 @ 2F4 409600 @ 96768 400Mb
cache 360 @ 1CB4 110080 @ 506368 107Mb
userdata.sin: userdata D20 @ 12D0 430080 @ 616448 420Mb
EOD: 1046528 1022Mb
MK16i/a: iyokan
system.sin: system C80 @ 2F4 409600 @ 96768 400Mb
cache 360 @ 1CB4 110080 @ 506368 107Mb
userdata.sin: userdata D20 @ 12D0 430080 @ 616448 420Mb
EOD: 1046528 1022Mb
your welcome

Great thanks. It seems the anzu has 2MB unused... is that your device? If so, do you know how to use dd? Can use dd to dump partition, if its mapped bad it will give I/O error.
Sent from Xperia Play (R800a) with Tapatalk

CosmicDan said:
Great thanks. It seems the anzu has 2MB unused... is that your device? If so, do you know how to use dd? Can use dd to dump partition, if its mapped bad it will give I/O error.
Sent from Xperia Play (R800a) with Tapatalk
Click to expand...
Click to collapse
Yep, I have the anzu, and I know how to use dd... Will test that some time later would it be possible to dump all of the nand flash?
Sent from my LT15i using xda app-developers app

[NUT] said:
Yep, I have the anzu, and I know how to use dd... Will test that some time later would it be possible to dump all of the nand flash?
Sent from my LT15i using xda app-developers app
Click to expand...
Click to collapse
Sure, should be. Say you wanted to dump entire flash to one image, just add another partition to mtdparts parameter with offset 0 and size of 1020MB (in anzu case). Then you can dd from that new mtdblock device to sdcard. But I think you may get lots of I/o errors on the first 80MB, I am really not sure. Just make sure you don't try to write to it LOL.
Also I think our devices need bs=4096 (4KB) because that is the sector size of our nand chip.
EDIT: Maybe there is some unused space at the end of that first 80MB, I am not sure. Because baseband and adsp firmware is less than 80MB.
Sent from Xperia Play (R800a) with Tapatalk

CosmicDan said:
Sure, should be. Say you wanted to dump entire flash to one image, just add another partition to mtdparts parameter with offset 0 and size of 1020MB (in anzu case). Then you can dd from that new mtdblock device to sdcard. But I think you may get lots of I/o errors on the first 80MB, I am really not sure. Just make sure you don't try to write to it LOL.
Also I think our devices need bs=4096 (4KB) because that is the sector size of our nand chip.
EDIT: Maybe there is some unused space at the end of that first 80MB, I am not sure. Because baseband and adsp firmware is less than 80MB.
Sent from Xperia Play (R800a) with Tapatalk
Click to expand...
Click to collapse
From what i know from using dd: it does a byte4byte copy, in any sector size you like but in any case it will read what the disk says there is, as long as there is a disk... so the o/i errors should only occur on those parts that are either damaged or non existent...
I'll do a partition as last option in the config_cmdline grabbing the theoretical maximum of 1024Mb and see if it will fly.
As the NAND flash chip has no logic that makes it a disk like entity other then direct access through MTD software logic (hence yaffs2 as filesystem of choice) i strongly doubt it will use the last 2/4Mb in the end as wear leveling buffer...

[NUT] said:
I'll do a partition as last option in the config_cmdline grabbing the theoretical maximum of 1024Mb and see if it will fly.
Click to expand...
Click to collapse
Well... it doesn't ... it craps out on the first sector it seems, but even if i skip the first sector it still doesn't want to go, probably because the partition size was wrong in the first place, but it's strange anyway.
Building a new testkernel with [email protected] which is one less in size, if 0 counts as the first, the last probably didn't exist
EDIT: nope, that one didn't fly either... dunno why, dd isn't very elaborate on it's errors

[NUT] said:
Well... it doesn't ... it craps out on the first sector it seems, but even if i skip the first sector it still doesn't want to go, probably because the partition size was wrong in the first place, but it's strange anyway.
Building a new testkernel with [email protected] which is one less in size, if 0 counts as the first, the last probably didn't exist
EDIT: nope, that one didn't fly either... dunno why, dd isn't very elaborate on it's errors
Click to expand...
Click to collapse
I think that beginning part is "read-protected" in userspace, I'm not sure. I will def. like to try this but my linux machine is awaiting repairs, I want to see if I can write to the amss (SBL) partition. Probably not though

CosmicDan said:
I think that beginning part is "read-protected" in userspace, I'm not sure. I will def. like to try this but my linux machine is awaiting repairs, I want to see if I can write to the amss (SBL) partition. Probably not though
Click to expand...
Click to collapse
I would agree with you, except if I skip the first 92 Mb of the NAND with dd it still doesn't read... maybe the 'read-protection' foils that plan as well... I don't know ...

Lenovo IdeaTab A2107A -F -H Tablet [FAQ]

Lenovo IdeaTab A2107A -F -H Tablet [FAQ]
We need a clearing house of concise information for the A2107A to address FAQ
(Much of this information can be useful to other MTK devices)
-----------------------------------------------------------------------------------------------------------
Please reply to this thread with any FAQ items you wish to see here.
-----------------------------------------------------------------------------------------------------------
Q: Why are you doing this? Creating a FAQ?
A: Because my brain hurts and I'm a slow reader. There are a few A2107A threads, but the main one has well over 1800 posts. We need to learn, not just follow recipes. We need to build our understanding with unhindered flow of information.
Q: What are the main threads for A2107A users?
A:
Lenovo IdeaTab a2107
Lenovo IdeaTab A2107A-F roms
Lenovo IdeaTab A2107A-F
A2107A-H Firmware update, Custom Rom and CWM Recovery (calling feature - unlocked)
[ROM] SE for Lenovo A2107A-F and A2107A-H
Q: Should I buy an A2107A?
A: At this point (Sept 2013), new ones are not a good value, but used/refurbs can be a good value. Lenovo themselves have better values: A1000 and A3000. I would like to know and post if these have 3G GSM SIMs? UPDATE: If you really want a 3G SIM tablet, this may be still king. The A1000 has no SIM. The A3000 has an LTE SIM.
Q: Are there custom ROMs? (NEW)
A: Depends on what "custom" means to you. I've stripped some stock ones down: http://forum.xda-developers.com/showthread.php?p=46201425 and makbro collected some... chinese, foxtrot, pemergency: http://forum.xda-developers.com/showpost.php?p=37409096&postcount=800 which I also mirrored here: https://drive.google.com/?authuser=0#folders/0B8PcIZoLeGNuWS1JUnA2UXdPYUE
Q: What is different about MTK devices from my phone (Motorola, Samsung, etc)?
A: MediaTek SoCs are cheap. They seem to be unique in that they allow for some low level fiddling where others don't. The low level fiddling is done with MediaTek software called SP Flash Tool (Smart Phone Flash Tool).
Q: It seems, this little beast is a lot more complicated to mess with, than other devices?
A: MediaTek devices are a pain in some respects... but once you use and understand MediaTek's SP Flash Tool -- you actually bypass a lot of complexity. You are able to write blocks anywhere in flash. And also, read blocks anywhere from flash. So you are in full control.
Q: Can I get an update.zip and put it on my sdcard?
A: Some folks (myself included) have grabbed OTAs, but they are not full flashes, they are just updates. Lenovo has not released official update.zip files for these devices. You may find something, I'd like to know. (You have other paths with CWM Recovery and also SP Flash Tools)
Q: What is the difference between a -H and a -F model?
A: There are 3 distinct hardware profiles: -H with 1 GSM SIM slot, -H with 2 GSM SIM, and -F with no SIM. Check the A2107A wiki here: http://forum.xda-developers.com/wiki/Lenovo_IdeaTab_A2107A
Q: Are there different Official ROMs?
A: Yes, there are at least different -H ROMs for US, Europe, and China. The Chinese ROMs enable a Phone App on the -H. To my knowledge there is just one -F ROM.
Q: What are the current stock ROMs?
A: If you have a US -H and OTA it as of Sept 2013 -- you will get Android 4.0.4 (ATT build A2107A_A404_000_033_121011_ATT)
A: If you have a US -F and OTA it as of Sept 2013 -- you will get Android 4.0.3 (build A2107A-F_S486_130221).
Q: Can I root after an OTA?
A: Yep, root4.03.zip etc should work fine. [Assuming there will never be 4.1 OTAs]
Q: Can I flash -H to a -F?
A: First, ask why do you want to do this? The phone software on a Tablet without phone (SIM) hardware won't get you anywhere. Yes, you can flash -H onto -F, and you will likely not like the results. It is jerky and sluggish and has some errors. For example audio breaks up horribly and swiping between homescreens is jittery. You'll want to go back to a -F ROM, and it's hard.
Q: Does the -F model have FM Radio hardware?
A: Yes! Tapping into it though is not easy. It's not as simple as grabbing the FM_Radio_1.0.apk from the -H ROM and installing it. Apparently the kernel driver on -F is missing, because the app wants to close and can't find any signals. On the SAME -F device, using the -H ROM, I'm able to hear FM Radio.
Q: Who do we owe thanks to?
A: Lots of folks, but makbro, FoxtrotKZ, and pemergency have to be at the top of the list.
Q: Are there custom ROMs for the -H?
A: Yes, check out makbro's post http://forum.xda-developers.com/showpost.php?p=37409096&postcount=800
Q: Are there recovery ROMs for the -H?
A: Yes, check makbro's post above and ClearSky or ANTIKIRPICH are within makbros posted SP_Flash_Tool_FULL_A2107.rar here:
https://docs.google.com/file/d/0By3a11Z9icECSXVLWUl4djc3WTg/edit?pli=1
(this is a very good rar/zip/tarball to grab, almost all you need... props go to FoxtrotKZ)
Q: Are there custom ROMs for the -F?
A: ShilohDaniel has stripped the stock ROM and I believe added some things -- calling it "A2107A-F Bare Bones ROM." thread: http://forum.xda-developers.com/showthread.php?t=2213225
Q: Are there recovery ROMs for the -F?
A: Not really. Once I broke my -F I pushed ClearSky (-H) on it. It was semi-operational, but then getting the right partitioning back to -F was horrible. In this respect, getting CWM on and going with Bare Bones ROM wouldn't get you fixed. I hope to change that.
Q: Will Lenovo release more OTAs? JB?
A: No, they already have a new line-up. They are "done" with these devices. The only thing that would change that is if a partner like AT&T needs a security fix.
Q: Is there a JellyBean ROM for either the A2107A-F or the A2107A-H?
A: No, are you volunteering?
Q: Does Lenovo respond to questions on their forums?
A: Probably not the questions that you would ask. Their answers are more "Well have you tried turning it off and then on again?" When I asked if there were model variants they had no idea. They didn't know if different features were enabled (with different ROMs) in different countries. Their online support chat was able to find a few product PDFs that show several long model numbers. (those PDFs are on the wiki)
Q: Can I use all these untrusted tools inside a VMware virtual machine instead of my daily rig?
A: Yes. I encourage it. Also, if you are using VMware snapshots or VirtualBox snapshots you can roll back and try different drivers. It seems trying to replace ADB USB drivers that don't work with MTDRT is very hard. Rolling back is much easier than trying to expunge the already installed driver so you can try another.
Q: What is MTK Droid Tools?
A: A Windows app that will convert a "firmware.info" to a scatter.txt file.
A: This tool is also able to root some devices and do a backup. I imagine if it gets that far it can restore too.
Q: What is MTK Rom Studio?
A: A Windows app that will convert a "firmware.info" to a scatter.txt file too I think. (I haven't used it)
Q: Why would I want a *_scatter.txt file?
A: It contains the partition information for your device. This is something you need to feed SP Flash Tool so it can flash the bits in the right places. You can make one from a working device by dumping a "firmware.info" file with a tool like the gscript backup method or presumably MTK Droid Tools will build you one right off, I'm sure doing the same thing to get the data which is dumped to firmware.info.
Q: Can I brick my -F or -H?
A: Probably not. There is a Meta Mode that you can get into even if your PRELOADER is broken/overwritten. I verified this today by writing zeroes to the first 16K of flash, broke my -F, then wrote over a known good firmware. makbro believes it's unbrickable and also yuweng has good info: http://forum.xda-developers.com/showpost.php?p=34914486&postcount=3
Q: How do I get into Meta Mode?
A1: While plugged into PC... Hold down Reset, hold VolUp, release Reset, release VolUp
A2: While off... hold VolUp, plug into PC, release VolUp
A3: While off... hold Reset, plug into PC, hold VolUp, release Reset, release VolUp
Q: Can someone help me unbrick my tablet?
A: I haven't seen a bricked A2107A-* that I could not fix. Please post to the original Lenovo IdeaTab a2107 thread.
Q: How do I use SP Flash Tool?
A: I'd like to write a FAQ on it too since there are many pitfalls, but I fear I don't have enough time to do everything. For now, here is a tutorial: http://forum.xda-developers.com/showthread.php?t=1982587
Q: What should I know about SP Flash Tool?
A: SP Flash Tool allows you to read or write any chunk of nvram/flash. It's normal operation though is to load a *scatter.txt file which describes different image chunks and allows you to "download" (write) them to MTK devices. You can think of the NVRAM as a disk (block device) and this scatter file describing the sizes of PARTITIONS. I think in one error I ran across even says your PMT (partition table?) doesn't match. So the download will write blocks of your NVRAM from image files on your WIndows computer.
Q: When I try to Download (write) a scatter and set of image files to my tablet with SP Flash Tool, I get a PMT does not match. What is causing this?
A: Well, for some reason you have to "Format". Not only do the Format, but you must select "Whole Flash". (assuming this next part) Then it write the PMT to your tablet to match the scatter file you have loaded. At this point you can Download (write) successfully. You will want to have a good backup of your NVRAM block or /data/nvram directory first!
Q: What is a PMT?
A: A partition table that holds the addresses to all the other partitions. I believe the PMT block is created by SP Flash Tool dynamically from scatter file. It's comparing the scatter file with what is sitting at the PMT address on the flash. If these two mismatch, you get the error you mentioned. If you want to force a new PMT that matches your scatter file's layout, you have to do a "Format" in SP Flash Tool. This will get you back to a PMT on flash that matches your scatter file, then SP Flash Tool will be happy and allow you to use Download (write to flash). SPFT is very picky about the scatter file matching the PMT on flash, even the __NODL_ in the scatter has to match the PMT.
Q: How do I get into Factory Mode?
A: Turn Off completely. (no power from USB, you might even hit the reset button)
A: Press and hold Power On and VolUp for 12 sec
A: Observe a menu similar to recovery but with tests etc
Q: How do I get into Recovery Mode?
A: Turn Off completely. (no power from USB, you might even hit the reset button)
A: Press and hold Power On for 4 sec, release, then hold VolUp and VolDown at the same time for up to 10 sec
A: Observe the stock Recovery or CWM if you've replaced the stock
Q: Why is SP Flash Tool giving me errors?
A: SP Flash Tool is not quality software, IMHO. I've had it give me BROM ERROR:S_DL_GET_DRAM_SETTING_FAIL(5054))... over and over, then I exited out and got back into the program and flashing worked fine. Also, make sure you have PRELOADER etc files associated with the blocks even though you don't have them selected to Download/write to flash. For some reason, SPFT checks these things even if they are irrelevant.
Q: I don't have a scatter file, or I have an incorrect scatter file... how do I create one if my device won't boot?
A: Interestingly enough, SPFT reads the PMT during a Download/write. It puts all the values of the PMT in it's log file. You can go look at the log file and fix your scatter file. This is cheating... knowing exactly what your scatter file needs to look like to match your device.
Q: I renamed the scatter file from MT6575_Android_scatter_emmc.txt to my_failed_attempt_scatter.txt is that ok?
A: Obviously you didn't know to ask this question and it's just contrived.... but yes you just screwed up, the file name of the scatter matters. I hate this, I lost like 2 weeks to this. Don't rename it. I've found some names that work, but just don't go there, leave the name and organize things with directories instead of file names.
(Some dumb Questions I had early on... that didn't seem to be answered clearly)
Q: How do a SBF or ODIN a A2107A
A: MediaTek's method is through software called SP Flash Tool. This is similar in function to Motorola SBF or Samsung ODIN.
Q: How do I get into Fastboot?
A: I don't think you do on MTK devices.
Q: How do I boot into the Bootloader?
A: Not sure if they have a bootloader menu. I think this is irrelevant. After an OTA, I was never able to. But with all the methods of gaining root and flashing, I guess I don't see why you need it.
Q: Does this device have a locked bootloader? Can I unlock it?
A: I'm not sure. If it does, you could probably overwrite the bootloader easy enough. Can the stock bootloader boot a homebrewed kernel? So far, I have seen no one produce a homebrew kernel for either the -F or -H. Hacks come from the stock kernels or the Lenovo A750 phone.
Q: Can the A2107A run Cyanogenmod (CM9, CM10)?
A: No. Cyanogenmod may run on MTK (MediaTek) chips soon, but even after that it will be a bunch of work.
Q: Why do I want to root my device?
Q: How do I root my device?
Q: Why do I want to install a custom recovery like CMW (Clockwork Mod) Recovery?
Q: How do I install CWM?
<-- Click Thanks If you found the information here useful, please!

Backup / root / recovery
Lenovo IdeaTab A2107A -F -H Tablet FAQ
CONTINUED DETAILS!
(but applicable for MT65xx devices)
Backup -- Post 3
Root -- Post 4
Recovery -- Post 5

Topic #1 - Backup
Before you start rooting, I highly recommend getting a full dump of your ROM. And why not? MediaTek makes it easy! At the very least, get a dump of the NVRAM partition. And if you really want to be risky, you'll just get a copy of /data/nvram.
Why Backup?
* First, so you can get back to a factory state.
* This is really good if you return your device or have it serviced.
* It's also good if you are going to sell it.
* Last, if you break it (semi-brick it) you can go back to this known working state.
Methods:
* SP Flash Tool - covered here
* rua1's MKDRT MediaTek Droid Root Tool - covered elsewhere
* Mobile Uncle backup of MEI - may cover here soon
SP Flash Tool BACKUP
If you are big on making images of hard drives, your going to like this tool. But, SP Flash Tool has some bugs and is designed a bit weird.
There are 4 main features to be concerned about: "Format", "Download" (write partition blocks), "Read back" memory, "Write memory".
To backup, you really want to be using the Read memory tab of the interface. But first, you need to make the tool happy.
replaces http://forum.xda-developers.com/showthread.php?p=46595925
Perfect Total Backup of your Firmware
Here is a cookbook for doing a total backup of your MTK device with MediaTek's SP Flash Tool. No rooting, you might even do this before you ever boot! I have basically done this with both of my devices before I fiddled too much. I recommend doing it before you do anything really.
1. Install VCOM Drivers. I'd use this: https://docs.google.com/file/d/0B8PcIZoLeGNuUTFIT1J2eXNFd28
2. Install SP Flash Tool. I'd use this: https://docs.google.com/file/d/0B8PcIZoLeGNuVDluTXk4QXdQaUU
3. Grab a -H scatter file with accompanying block images, just to make SP Flash happy. I'd use this: https://docs.google.com/file/d/0B8PcIZoLeGNuM3lxakdIU2hvWTA
4. Run SP Flash Tool, Open Scatter File
5. Don't play with anything, go into the "Read back" tab (This will read your flash to a file on your PC)
6. Click on any items in the list, then click the "Remove" button
7. Now click the "Add" button
8. Double click on the "N/A" under Read Flag
9. Type a file name to write to, like "WHOLE_ROM"
10. Now it will popup a window "Readback block start address"
11. Leave "Hex" selected, Start Address" 0x0000, Length: 0x323E4000, Click OK
12. Click the "Read back" button
13. SPFT now waits for you to connect your device and put it in Meta Mode
14. Without plugging your tablet in, tap the Reset Button on the back under the camera
15. Hold VolUp, plug in USB, Release VolUp (putting it in Meta Mode) <--- Important
16. You will see the progress bar moving. Total backup takes forever, because in this mode SPFT seems to not do USB HIGHSPEED
That's IT! Go to bed, check on it in the morning.
If you ever restore, just go into Recovery and Wipe Data and Cache. (as these are large and we didn't back them up above)
Note: "Length" in Step 11 is extra long. If you have a 4 or 8GB model it actually backs up part of your cache partition block too. But this is the right length for the 16GB model and it doesn't hurt to backup too much.
(If anyone would like to share there's with me, that would be great. I only want stock dumps though, for comparison purposes.)

Topic #2 - Root
Note: MediaTek is very different as you have low level access to their Flash. Ask
yourself if you really need root. MediaTek's tool SP Flash Tool is very powerful. You can dump your stock rom, replace your recovery image, or blow on another SPFT ROM. So, unless you want your STOCK ROM ROOTED, you can probably skip rooting your stock ROM in the first place.
Why Root?
You have very little ability to do backups or change your device without rooting it. You can use vendor tools to do backup/restore of your user data, whatever they determine is your user data. You can use Android "Factory Reset" which just wipes the data and cache partitions. If you want to do more, you need to root.
More access like:
* Complete backups of ROM (although a bit sketchy to backup a running system)
* Install busybox
* Install apps requiring root, Root Explorer and WiFi sharing
* Install drivers, like OpenVPN, alternative wireless drivers, OTG, FM Radio?
* Install sshd server etc
* Do custom theming?
* Performance tweaks
* Remove APKs from /system/apps (scary)
Different Methods - I think all rely on the same mechanism
1. 4.03root.zip (requires working ADB and Windows)
2. setools/seroot (syserr's port of 4.03root.zip to linux shell, instead of .bat)
3. SRS Root (requires working ADB and Windows)
4. rua1's MKDRT MediaTek Droid Root Tool (requires working ADB and Windows)

Topic #3 - CWM (Clock Work Mod) Recovery
Why?
CWM Recovery is awesome. It allows you to install custom ROMs as long as they are "CWM" compatible. CWM Recovery is a lot like a typical stock Recovery but better. For new people, a Recovery is basically a minimal Android system that allows you to do maintenance on the device and reload etc the main operating system. On MTK devices the Recovery image sits on the RECOVERY partition. You usually press certain buttons early in the boot process to "boot into Recovery."
Different Methods
* SP Flash Tool
* MobileUncle (requires root)
* rua1's MKDRT MediaTek Droid Root Tool (requires root)
* dd / flash_image (requires root)
SP Flash Tool Method
Disconnect Tablet from PC
Run SP Flash Tool (exe)
Select Scatter File
Uncheck all block partition checkboxes except for Recovery.
Click on the Recovery text/tag and then find the CWM Recovery image you desire.
Select Download, SPFT waits for device
Hit reset on Tablet
Press VolUp, connect USB, Release VolUp (to get to Meta Mode)
SPFT ALWAYS finds device this way.
You should see progress bars moving, and it complete

lenovo s6000-h
hi syserr,
your reading was really interesting and help me a lot to better understand the device i just bought.
i think it's quit similar. I m looking/searching information as much as i can at the moment.
thks

fragargon said:
hi syserr,
your reading was really interesting and help me a lot to better understand the device i just bought.
i think it's quit similar. I m looking/searching information as much as i can at the moment.
thks
Click to expand...
Click to collapse
I get paid with "Thanks." So, thanks! :good:
I've often wondered if forums are the right structure to capture this information. When I finally decided to dive in deep, I had to make notes of which posts had good information - it took 3 days of solid reading to make sense of it all. There are plenty of posts that have incorrect information or irrelevant information.
Good luck.

I need some help!
Thank you for helping
But I can not I download:
S6000-H (16GB model, WiFi and 3G)
S6000_A422_000_015_130503_WW_SMS.rar - 495.90 MB
I have problems installing the program and set the theme on the device
I'm not familiar with these settings. Explain the preliminary
My device: S6000-H_A422_101_022_131101_WW_SMS
Put a new link for download. Please
Who can help????

Scatter file
syserr said:
Topic #1 - Backup
Before you start rooting, I highly recommend getting a full dump of your ROM. And why not? MediaTek makes it easy! At the very least, get a dump of the NVRAM partition. And if you really want to be risky, you'll just get a copy of /data/nvram.
Why Backup?
* First, so you can get back to a factory state.
* This is really good if you return your device or have it serviced.
* It's also good if you are going to sell it.
* Last, if you break it (semi-brick it) you can go back to this known working state.
Methods:
* SP Flash Tool - covered here
* rua1's MKDRT MediaTek Droid Root Tool - covered elsewhere
* Mobile Uncle backup of MEI - may cover here soon
SP Flash Tool BACKUP
If you are big on making images of hard drives, your going to like this tool. But, SP Flash Tool has some bugs and is designed a bit weird.
There are 4 main features to be concerned about: "Format", "Download" (write partition blocks), "Read back" memory, "Write memory".
To backup, you really want to be using the Read memory tab of the interface. But first, you need to make the tool happy.
replaces http://forum.xda-developers.com/showthread.php?p=46595925
Perfect Total Backup of your Firmware
Here is a cookbook for doing a total backup of your MTK device with MediaTek's SP Flash Tool. No rooting, you might even do this before you ever boot! I have basically done this with both of my devices before I fiddled too much. I recommend doing it before you do anything really.
1. Install VCOM Drivers. I'd use this: https://docs.google.com/file/d/0B8PcIZoLeGNuUTFIT1J2eXNFd28
2. Install SP Flash Tool. I'd use this: https://docs.google.com/file/d/0B8PcIZoLeGNuVDluTXk4QXdQaUU
3. Grab a -H scatter file with accompanying block images, just to make SP Flash happy. I'd use this: https://docs.google.com/file/d/0B8PcIZoLeGNuM3lxakdIU2hvWTA
4. Run SP Flash Tool, Open Scatter File
5. Don't play with anything, go into the "Read back" tab (This will read your flash to a file on your PC)
6. Click on any items in the list, then click the "Remove" button
7. Now click the "Add" button
8. Double click on the "N/A" under Read Flag
9. Type a file name to write to, like "WHOLE_ROM"
10. Now it will popup a window "Readback block start address"
11. Leave "Hex" selected, Start Address" 0x0000, Length: 0x323E4000, Click OK
12. Click the "Read back" button
13. SPFT now waits for you to connect your device and put it in Meta Mode
14. Without plugging your tablet in, tap the Reset Button on the back under the camera
15. Hold VolUp, plug in USB, Release VolUp (putting it in Meta Mode) <--- Important
16. You will see the progress bar moving. Total backup takes forever, because in this mode SPFT seems to not do USB HIGHSPEED
That's IT! Go to bed, check on it in the morning.
If you ever restore, just go into Recovery and Wipe Data and Cache. (as these are large and we didn't back them up above)
Note: "Length" in Step 11 is extra long. If you have a 4 or 8GB model it actually backs up part of your cache partition block too. But this is the right length for the 16GB model and it doesn't hurt to backup too much.
(If anyone would like to share there's with me, that would be great. I only want stock dumps though, for comparison purposes.)
Click to expand...
Click to collapse
I do not understand. How Lenght you have used : 0x323E4000
11. Leave "Hex" selected, Start Address" 0x0000, Length: 0x323E4000, Click OK
The scatter file, there is no partition at this address
Yours scatter file :
EBR2 0x23e0000
{
}
ANDROID 0x23e4000
{
}
CACHE 0x224e4000
{
}
USRDATA 0x425e4000
{
}
FAT 0x626e4000
{
}
__NODL_BMTPOOL 0xffffffffffff0050
{
}
I used to read back:
0x3c3c00000 + from firmware.info
0x00600000 = preloader
0x3c9c00000 – CACHE scatter file with MTKDroid

I used to read back:
0x3c3c00000 + from firmware.info
0x00600000 = preloader
0x3c9c00000 – CACHE scatter file with MTKDroid
Click to expand...
Click to collapse
when doing this with a hex calculator i got : 3C4200000 - check this wit a hex calculator

Explain how it is with hex
fragargon said:
when doing this with a hex calculator i got : 3C4200000 - check this wit a hex calculator
Click to expand...
Click to collapse
OK , OK I understand.
But the address you left partition to get 3C4200000 - cache or else.explain how
This is scater file: posted by you:
MT6575_Android_scatter_emmc
PRELOADER 0x0
{
}
DSP_BL 0x40000
{
}
MBR 0x600000
{
}
EBR1 0x604000
{
}
__NODL_PMT 0x660000
{
}
__NODL_NVRAM 0xa60000
{
}
__NODL_SECCFG 0xd60000
{
}
UBOOT 0xd80000
{
}
BOOTIMG 0xde0000
{
}
RECOVERY 0x13e0000
{
}
SEC_RO 0x19e0000
{
}
__NODL_MISC 0x1fe0000
{
}
LOGO 0x2040000
{
}
__NODL_EXPDB 0x2340000
{
}
EBR2 0x23e0000
{
}
ANDROID 0x23e4000
{
}
CACHE 0x224e4000
{
}
USRDATA 0x425e4000
{
}
FAT 0x626e4000
{
}
__NODL_BMTPOOL 0xffffffffffff0050
{
}

Alex1948 said:
OK , OK I understand.
But the address you left partition to get 3C4200000 - cache or else.explain how
Click to expand...
Click to collapse
this value 0x3C4200000 is the sum of=> 0x3C4200000 = 0x3c3c00000 (from firmware.info) + 0x00600000 (preloader)
Code:
partname size start adress map to
android 0x0000000040000000 0x0000000010980000 2 /dev/block/mmcblk0p6
cache 0x0000000007e00000 0x0000000050980000 2 /dev/block/mmcblk0p7
usrdata 0x0000000349fa0000 0x0000000058780000 2 /dev/block/mmcblk0p8
whilst this is not really friendly I'll try answer.
when hex number i advice you to use an hex calculator because this is 16 base not 10base that's why you would be better using a hex calculator.
this all about readback the memory for backup purpose so according to my file:
I do not understand. How Lenght you have used
Click to expand...
Click to collapse
take my file as example and i would bump the partition cache, i would do:
readback: start adress:0x0000000050980000
: size : 0x0000000007e00000 = 126 Mb
: lenght: 0x0000000050980000+0x0000000007e00000 = 0x0000000058780000 (end adress)
this should result by a file.img of 126Mb with by spft on readback memory starting adress at 0x0000000050980000 and ending at 0x0000000058780000.
you can see that this overlapted the next partition 0x0000000058780000 (userdata) so i bet that spft does this to not overlapted start adress of next partition:
0x0000000050980000+0x0000000007e00000-0x00000000000001=0x000000005877ffff
i hope this explanation is readable and will answer your question.

What Scatter file ?
fragargon said:
this value 0x3C4200000 is the sum of=> 0x3C4200000 = 0x3c3c00000 (from firmware.info) + 0x00600000 0x3c3c00000 (from firmware.info) + 0x00600000 (preloader)
Code:
partname size start adress map to
android 0x0000000040000000 0x0000000010980000 2 /dev/block/mmcblk0p6
cache 0x0000000007e00000 0x0000000050980000 2 /dev/block/mmcblk0p7
usrdata 0x0000000349fa0000 0x0000000058780000 2 /dev/block/mmcblk0p8
whilst this is not really friendly I'll try answer.
when hex number i advice you to use an hex calculator because this is 16 base not 10base that's why you would be better using a hex calculator.
this all about readback the memory for backup purpose so according to my file:
take my file as example and i would bump the partition cache, i would do:
readback: start adress:0x0000000050980000
: size : 0x0000000007e00000 = 126 Mb
: lenght: 0x0000000050980000+0x0000000007e00000 = 0x0000000058780000 (end adress)
this should result by a file.img of 126Mb with by spft on readback memory starting adress at 0x0000000050980000 and ending at 0x0000000058780000.
you can see that this overlapted the next partition 0x0000000058780000 (userdata) so i bet that spft does this to not overlapted start adress of next partition:
0x0000000050980000+0x0000000007e00000-0x00000000000001=0x000000005877ffff
i hope this explanation is readable and will answer your question.
Click to expand...
Click to collapse
My bewilderment came from that and MTKDroid do the same, add preloader - in my case CACHE : 0x3c3c00000 (from firmware.info) + 0x00600000(preloader) = 0x3C9C0000(that we used from READ BACK with SPFT).
I understand that the scatter file created with MTKDroid Tool is not good ???

Alex1948 said:
My bewilderment came from that and MTKDroid do the same, add preloader - in my case CACHE : 0x3c3c00000 (from firmware.info) + 0x00600000(preloader) = 0x3C9C0000(that we used from READ BACK with SPFT).
I understand that the scatter file created with MTKDroid Tool is not good ???
Click to expand...
Click to collapse
lol :silly:
sometimes you should read back what you wrote, i really don't understand what you mean but i am sure you are not reading what i have wrote because this
================+++>
============++>
=========+>
in my case CACHE : 0x3c3c00000 (from firmware.info) + 0x00600000(preloader) = 0x3C9C0000(that we used from READ BACK with SPFT).
Click to expand...
Click to collapse
i wish you a good night! :cyclops:

????
fragargon said:
lol :silly:
sometimes you should read back what you wrote, i really don't understand what you mean but i am sure you are not reading what i have wrote because this
================+++>
============++>
=========+>
i wish you a good night! :cyclops:
Click to expand...
Click to collapse
Please forgive me greatly.
I asked a simple question : if scatter file made ​​with MTKDroid TOOL is good or no , work or no.
So , good night !

fragargon said:
i hope this explanation is readable and will answer your question.
Click to expand...
Click to collapse
Thanks for trying to explain, it's appreciated!
Alex1948 said:
Please forgive me greatly.
I asked a simple question : if scatter file made ​​with MTKDroid TOOL is good or no , work or no.
So , good night !
Click to expand...
Click to collapse
I believe "MTK Droid Root & Tools" does give you a good scatter file, but I've actually never used it.
Background: During the time I used it, I had major problems with ADB drivers on Windows. I ended up soft-bricking my device by playing with the "Test" tab in SP Flash Tools. So when I came back to working on things again, with a new device to donate the ROM, I wanted to be absolutely sure I knew what I was doing. First thing was "Read back" the ENTIRE ROM of the new device. This is an insurance policy. I had made backups with the GScript mtk*backup.sh scripts that run ON the unit, so I never went back to MTK DRT.​Something I think everyone that wants to do HEX math should to is start playing with the python interpreter... it is AWESOME. :good:
Code:
$ more MT6575_Android_scatter_emmc.txt
....
ANDROID 0x123e4000
{
}
CACHE 0x324e4000
{
}
USRDATA 0x525e4000
{
}
FAT 0x726e4000
{
}
__NODL_BMTPOOL 0xffffffffffff0050
{
}
$ python
Python 2.7.3 (default, Sep 26 2013, 16:35:25)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> hex(0x324e4000-0x123e4000)
'0x20100000'
Alex1948, if you are wondering why the length of my full/entire/whole dumps seems arbitrary... my answer is in some cases I was guessing at large enough numbers. My device (A2107A-*) has at least 5 different partitioning schemes from the factory. I want extra length, I didn't want to tell someone to read too short.
Why I am reading to the start address of CACHE is because that is the end of ANDROID. This is just looking at the physical real addresses in the scatter file. How those addresses are calculated from firmware.info/dumchar_info is a different story. I think you are aware of adding the 0x600000. This is only added to the lines in the file that are not preloader or dsp_bl:
Code:
$ more dumchar.txt
preloader 0x0000000000040000 0x0000000000000000 2 /dev/[B]misc[/B]-sd
dsp_bl 0x00000000005c0000 0x0000000000040000 2 /dev/misc-sd
mbr 0x0000000000004000 0x0000000000000000 2 /dev/[B]block[/B]/mmcblk0
ebr1 0x000000000005c000 0x0000000000004000 2 /dev/block/mmcblk0p1
pmt 0x0000000000400000 0x0000000000060000 2 /dev/block/mmcblk0
nvram 0x0000000000300000 0x0000000000460000 2 /dev/block/mmcblk0
seccfg 0x0000000000020000 0x0000000000760000 2 /dev/block/mmcblk0
uboot 0x0000000000060000 0x0000000000780000 2 /dev/block/mmcblk0
bootimg 0x0000000000600000 0x00000000007e0000 2 /dev/block/mmcblk0
recovery 0x0000000000600000 0x0000000000de0000 2 /dev/block/mmcblk0
sec_ro 0x0000000000600000 0x00000000013e0000 2 /dev/block/mmcblk0p5
misc 0x0000000000060000 0x00000000019e0000 2 /dev/block/mmcblk0
logo 0x0000000000300000 0x0000000001a40000 2 /dev/block/mmcblk0
expdb 0x00000000000a0000 0x0000000001d40000 2 /dev/block/mmcblk0
ebr2 0x0000000000004000 0x0000000001de0000 2 /dev/block/mmcblk0
fac 0x0000000010000000 0x0000000001de4000 2 /dev/block/mmcblk0p6
android 0x0000000020100000 0x0000000011de4000 2 /dev/block/mmcblk0p7
cache 0x0000000020100000 0x0000000031ee4000 2 /dev/block/mmcblk0p2
usrdata 0x0000000020100000 0x0000000051fe4000 2 /dev/block/mmcblk0p3
fat 0x00000000762fc000 0x00000000720e4000 2 /dev/block/mmcblk0p4
bmtpool 0x0000000000a00000 0xffffffffff9f0050 2 /dev/block/mmcblk0
So my code here:
Code:
if block != 'misc':
start = start + 0x600000
Is only adding the offset to the partitions that don't have that "misc" in their block device name.
I'm explaining a lot. I'm hoping somewhere in this you have the answer you are looking for.
We should have discussed this here:
[GUIDE][UTIL][MT65xx] Create Scatter File and Dump Full ROM
http://forum.xda-developers.com/showthread.php?p=47809842

Tks
syserr said:
Thanks for trying to explain, it's appreciated!
I believe "MTK Droid Root & Tools" does give you a good scatter file, but I've actually never used it.
Background: During the time I used it, I had major problems with ADB drivers on Windows. I ended up soft-bricking my device by playing with the "Test" tab in SP Flash Tools. So when I came back to working on things again, with a new device to donate the ROM, I wanted to be absolutely sure I knew what I was doing. First thing was "Read back" the ENTIRE ROM of the new device. This is an insurance policy. I had made backups with the GScript mtk*backup.sh scripts that run ON the unit, so I never went back to MTK DRT.​Something I think everyone that wants to do HEX math should to is start playing with the python interpreter... it is AWESOME. :good:
Code:
$ more MT6575_Android_scatter_emmc.txt
....
ANDROID 0x123e4000
{
}
CACHE 0x324e4000
{
}
USRDATA 0x525e4000
{
}
FAT 0x726e4000
{
}
__NODL_BMTPOOL 0xffffffffffff0050
{
}
$ python
Python 2.7.3 (default, Sep 26 2013, 16:35:25)
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> hex(0x324e4000-0x123e4000)
'0x201000000'
Alex1948, if you are wondering why the length of my full/entire/whole dumps seems arbitrary... my answer is in some cases I was guessing at large enough numbers. My device (A2107A-*) has at least 5 different partitioning schemes from the factory. I want extra length, I didn't want to tell someone to read too short.
Why I am reading to the start address of CACHE is because that is the end of ANDROID. This is just looking at the physical real addresses in the scatter file. How those addresses are calculated from firmware.info/dumchar_info is a different story. I think you are aware of adding the 0x600000. This is only added to the lines in the file that are not preloader or dsp_bl:
Code:
$ more dumchar.txt
preloader 0x0000000000040000 0x0000000000000000 2 /dev/[B]misc[/B]-sd
dsp_bl 0x00000000005c0000 0x0000000000040000 2 /dev/misc-sd
mbr 0x0000000000004000 0x0000000000000000 2 /dev/[B]block[/B]/mmcblk0
ebr1 0x000000000005c000 0x0000000000004000 2 /dev/block/mmcblk0p1
pmt 0x0000000000400000 0x0000000000060000 2 /dev/block/mmcblk0
nvram 0x0000000000300000 0x0000000000460000 2 /dev/block/mmcblk0
seccfg 0x0000000000020000 0x0000000000760000 2 /dev/block/mmcblk0
uboot 0x0000000000060000 0x0000000000780000 2 /dev/block/mmcblk0
bootimg 0x0000000000600000 0x00000000007e0000 2 /dev/block/mmcblk0
recovery 0x0000000000600000 0x0000000000de0000 2 /dev/block/mmcblk0
sec_ro 0x0000000000600000 0x00000000013e0000 2 /dev/block/mmcblk0p5
misc 0x0000000000060000 0x00000000019e0000 2 /dev/block/mmcblk0
logo 0x0000000000300000 0x0000000001a40000 2 /dev/block/mmcblk0
expdb 0x00000000000a0000 0x0000000001d40000 2 /dev/block/mmcblk0
ebr2 0x0000000000004000 0x0000000001de0000 2 /dev/block/mmcblk0
fac 0x0000000010000000 0x0000000001de4000 2 /dev/block/mmcblk0p6
android 0x0000000020100000 0x0000000011de4000 2 /dev/block/mmcblk0p7
cache 0x0000000020100000 0x0000000031ee4000 2 /dev/block/mmcblk0p2
usrdata 0x0000000020100000 0x0000000051fe4000 2 /dev/block/mmcblk0p3
fat 0x00000000762fc000 0x00000000720e4000 2 /dev/block/mmcblk0p4
bmtpool 0x0000000000a00000 0xffffffffff9f0050 2 /dev/block/mmcblk0
So my code here:
Code:
if block != 'misc':
start = start + 0x600000
Is only adding the offset to the partitions that don't have that "misc" in their block device name.
I'm explaining a lot. I'm hoping somewhere in this you have the answer you are looking for.
We should have discussed this here:
[GUIDE][UTIL][MT65xx] Create Scatter File and Dump Full ROM
http://forum.xda-developers.com/showthread.php?p=47809842
Click to expand...
Click to collapse
Thank you very much.I understand something.and conversely :ANDROID 0x123e4000+0x20100000(lenght) = CACHE 0x324e4000
I wrote on the other thread

A3000 hardware
Just a note, in Europe and likely in Asian the A3000 SIM version is dual SIM, organised much the same as the A2107A. One SIM is expected to be used for data (HSDP+, this is the European high speed 3G, up to 42mbs, I get 18mbs off my local tower) and one for SMS and Voice. You can run SMS on the Data SIM if you are provisioned, I do. The European firmware does not support GSM voice (again) but Asian and Middle Eastern does. Why Lenovo does not include voice support in the European firmware is a mystery.
Many thanks for the A2107A FAQ, I'm selling one now, replaced by a A3000.

Not create worry... but I have a very cheap ($75 sale) Lenovo A1000 coming. This has JB, FM Radio, and dual-core. This is going to work out better for a in-dash car system.

Partitioning 16 GB A2107A-H
Does anyone please have an EBR1 and EBR2 (or other means) by which I can repartition my internal SD flash so that the system and other partitions are larger?
I have read about an apk to do this for the 4 GB model, and also the limitation to one of the partitions (32-bit addressing?) to 2 GB, but have not found anything available for the 16 GB model.
Could anyone please advise and/or upload the necessary files?
Also, does anyone have a view on the "best" ROM? It seems all have compromises in some way, including the stock ROM. Pemergency looks good unless someone tells me otherwise.

Orange Yumo aka Huawei Ascend G740 Rooting, General Discussion Thread

Quadrant ~ 5000.
Antutu ~ 14000.
http://consumer.huawei.com/en/mobile-phones/features/g740-l00-en.htm
Rooting:
1. Install latest Framaroot 1.6.1 from here http://forum.xda-developers.com/showthread.php?t=2130276
2. Launch and choose Gandalf. It will be rooted in a second.
3. Reboot and enjoy.

Battery screenshots, 100% to 8%, GREAT screen on time, 5h 41m.
Here is the partition table, i've backuped the recovery.img using this command dd if=/dev/block/mmcblk0p14 of=/sdcard/recovery.img bs=4096 but when trying to generate cwm recovery here http://builder.clockworkmod.com/ it failed.
If anyone is interested in getting a working cm with this device, i can provide the necessary files from my device.
[email protected]:/ # parted /dev/block/mmcblk0 print
parted /dev/block/mmcblk0 print
Model: MMC SEM08G (sd/mmc)
Disk /dev/block/mmcblk0: 7818MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Number Start End Size File system Name Flags
1 17.4kB 280kB 262kB sbl1
2 280kB 542kB 262kB sbl2
3 542kB 1066kB 524kB sbl3
4 1066kB 1328kB 262kB rpm
5 1328kB 2377kB 1049kB tz
6 2377kB 4474kB 2097kB aboot
7 4474kB 6571kB 2097kB aboot2
8 6571kB 6579kB 8192B ssd
9 8389kB 12.6MB 4194kB fsg
10 12.6MB 16.8MB 4194kB modemst1
11 16.8MB 21.0MB 4194kB modemst2
12 21.0MB 54.5MB 33.6MB oeminfo
13 54.5MB 122MB 67.1MB fat16 modem
14 122MB 138MB 16.8MB recovery
15 138MB 155MB 16.8MB recovery2
16 155MB 159MB 4194kB misc
17 159MB 164MB 4194kB splash
18 164MB 172MB 8389kB ext4 persist
19 172MB 180MB 8389kB tombstones
20 180MB 181MB 655kB pad
21 185MB 197MB 12.6MB boot
22 197MB 466MB 268MB ext4 cust
23 466MB 667MB 201MB ext4 cache
24 667MB 1741MB 1074MB ext4 system
25 1741MB 2923MB 1183MB ext4 userdata
26 2923MB 7818MB 4895MB fat32 grow
Click to expand...
Click to collapse

Hello, a just installed an app from the playstore that bricked my yumo. It just show the orange logo and doesn't boot up. Anybody knows where can i download the firmware to reinstall it or should i go to for repair? Tried factory reset from recovery but still nothing. Thanks.

ione2380 said:
Hello, a just installed an app from the playstore that bricked my yumo. It just show the orange logo and doesn't boot up. Anybody knows where can i download the firmware to reinstall it or should i go to for repair? Tried factory reset from recovery but still nothing. Thanks.
Click to expand...
Click to collapse
If factory reset doesn't work, return it for repair, there isn't a custom recovery for it yet, if it was i would backup my device and give you the backup for a restore. I've checked the huawei website, there isn't a firmware to download from them.. so no luck this way. What app did you install?
Ask orange for the firmware maybe they will give it if we will have future problems...

I have tested it successfully with a Huawei Ascend G740 from Yoigo (Spain).
Thank you!

GeekRMX said:
Thank you!
I have tested it successfully with a Huawei Ascend G740 from Yoigo (Spain) following this tutorial
Great device!
Click to expand...
Click to collapse
why do you post a link with the same method described by me in the op over 2 weeks ago? please remove the link because it's advertising.

ione2380 said:
Hello, a just installed an app from the playstore that bricked my yumo. It just show the orange logo and doesn't boot up. Anybody knows where can i download the firmware to reinstall it or should i go to for repair? Tried factory reset from recovery but still nothing. Thanks.
Click to expand...
Click to collapse
Try the Nandroid backup / rrestore method. This method is used for backing up the original ROM and recover it when something wrong occures.
I assume that you do not have a backup image of your original ROM.
What you can do is ask someone to do a full Nandroid Backup of their Huawei G740/Orange Yumo and send it to you or get a custom working ROM.
I suggest flashing the custom ROM or someones else's Nandroid Backup using ADB.
search google for : simple-adb-backup-backs-up-your-android-phone-from-the-desktop-no-root-required
search google for: nandroid-backup-restore-for-android-4-2
After you solve this, if you solve it please post how you did it step by step.

full nandroid backup requires a cwm recovery which we do not have for yumo/g740, if we had i could have helped him.
also the bootloader is locked...
i think he sent it to service.

I had no other way but sent it to service. I don't know why but they gave me a new one? Maybe orange doesn't have firmware either?
For anyone who has root just stay away from an app called srs manager from google play. It will brick your yumo.?
Sent from my Note 3 SM-N9005 using Tapatalk.

ione2380 said:
I had no other way but sent it to service. I don't know why but they gave me a new one? Maybe orange doesn't have firmware either?
For anyone who has root just stay away from an app called srs manager from google play. It will brick your yumo.?
Sent from my Note 3 SM-N9005 using Tapatalk.
Click to expand...
Click to collapse
Did it came also with 4.1.2? Of course they have it because it is customized with lots of orange applications.

Yes, still 4.1.2
Send from my Note 3.

hey all,i just upload full backup from my orange yumo,the backup is compatible in TWRP recovery tool https://docs.google.com/file/d/0B4VVn6aokJwXVmFSOUlmcmlfT3c/edit

can you add please twrp recovery for our orange yumo ?

Well..there more to do..yumo has locked bootloader. This will have to be unlocked first,then we can talk about custom recovery. I'm interested in this too.
Sent from Omega pwd GT-I9505/smart phones,dumb people.

kimitza said:
Well..there more to do..yumo has locked bootloader. This will have to be unlocked first,then we can talk about custom recovery. I'm interested in this too.
Sent from Omega pwd GT-I9505/smart phones,dumb people.
Click to expand...
Click to collapse
we know that bootloader is locked, you can try this method to unlock it, http://www.huaweidevice.com/worldwide/servicePolicy.do?method=getUnlockStep .. maybe it works...

True,it can be done, but as long as we don't have an image with the original firmware,i'll take no chances. it's my gf's phone )..

I need some files
Hey all.I need some folders from main root ..Can anyone zip the following folders ""/system/app""and ""/xbin""from main sistem?i deleted some files and i dont want to send it back in service.You can use ES file explorer

emilutzzu said:
Hey all.I need some folders from main root ..Can anyone zip the following folders ""/system/app""and ""/xbin""from main sistem?i deleted some files and i dont want to send it back in service.You can use ES file explorer
Click to expand...
Click to collapse
/system/app https://mega.co.nz/#!Wddw2RqQ!Iszumj2H3mCzGnefl7mKhiAhSkZ79fJh_G3i64wwoeE
/system/xbin https://mega.co.nz/#!DE0VFYYa!ZV-2Tg4ZmFvDc9ZviMIi0kp6-alpASvY2lI3m4-uupY
there is no /xbin folder

to unlock bootloader send a mail to [email protected] with this content:
Dear sir/madam,
I tried applying for a bootloader unlock code at unlock url which I cannot post because of XDA forum restricting me, but my device (Ascend G740) was not listed. I supply the data via this mail in the hope to get a bootloader unlock code via this way instead.
Product Model: Huawei Ascend G740-L00
SN: xxxxxxxxxxxxxxxxxxx
IMEI: xxxxxxxxxxxxxxxxx
ProductID: xxxxxxxx
I hope to hear from you soon.
Yours sincerely,
Click to expand...
Click to collapse
filling your details in a couple days shall receive an answer with the unlock code and podreis follow the process explained on the website of huawei
PS: it works, I already have unlocked

i just go a new update, from L00V100R001C109B140_JB to L00V100R001C109B146_JB, still 4.1.2, don't know the changes because they are not specified.

[GUIDE] How to Recover from a bad NON-HLOS.bin flash -no sound/phone app unresponsive

Device: i9505 / Qualcomm Snapdragon, locked to T-Mobile UK, went striaght from Samsung Stock ROM to CM11 on purchase in 2013.
Computing Platform: Macbook Pro - OSX Yosemite
Flash tool of choice: Heimdall 1.4.0 - cmd line !!!
Context:
I updated from CM11 to CM12 - no issues. I decided to update to the Radio/Modem to the latest for Lollipop.
Went to the relevant thread, downloaded 'I9505XXUHOB8_MODEM_and_I9505_XXUHOB8_WiFi_FIX' which included the modem.bin and the non-hlos.bin files.
Flashed via Heimdall on the cmd line, all went ok.
Booted the phone, wifi ok, cell data transfer ok, BUT no sound (touch sounds ok, no ring tone, or ringer adjustment tones), phone app unresponsive - very laggy, forced reboot, no sound on calls
Tried other touted solution of mixing and matching various versions of modem and non-hlos - no luck.
Aim: Fix issue without having to ReFlash stock ROM - after all its only two files that caused an issue, just needed to know why?
After a lot of googling and searching xda, I got nowhere, only option seemed to be flash stock FW.
Started reading a lot around the modem.bin and non-hlos.bin - seemed not much info about at high level for the non-hlos.bin; began reading in depth about flashing and boot-loaders.
Solution: the modem.bin and non-hlos-bin that are flashed need an associated (or close) version of the bootloader of the same!
I downloaded the BL_I9505XXUHOB8_user_low_ship_MULTI_CERT (also tested with BL_I9505XXUHOB7_user_low_ship_MULTI_CERT which worked fine with the above XXUHOB8 modem and non-hlos!)
Untarred all into a single folder/directory ie XXUHOB8 :
[email protected] 1 myusername staff 12147712 26 Feb 09:23 NON-HLOS.bin ----> XXUHOB8 MODEM binary
[email protected] 1 myusername staff 52304896 26 Feb 09:23 modem.bin ----> XXUHOB8 NON-HLOS binary
[email protected] 1 myusername staff 1313312 25 Feb 16:45 aboot.mbn ----> XXUHOB8 Bootloader Files
[email protected] 1 myusername staff 153696 25 Feb 16:45 rpm.mbn ----> XXUHOB8 Bootloader Files
[email protected] 1 myusername staff 94772 25 Feb 16:44 sbl1.mbn ----> XXUHOB8 Bootloader Files
[email protected] 1 myusername staff 152168 25 Feb 16:44 sbl2.mbn ----> XXUHOB8 Bootloader Files
[email protected] 1 myusername staff 270664 25 Feb 16:45 sbl3.mbn ----> XXUHOB8 Bootloader Files
[email protected] 1 myusername staff 217068 25 Feb 16:45 tz.mbn ----> XXUHOB8 Bootloader Files
I inspected the .PIT file, determined the order (may not be necessary, but I was unclear, so...),
put phone into download mode (from complete power off, Volume Up & Home & Power button, then release power button and press Volume Up to proceed)
and then ran the following:
Code:
heimdall flash --APNHLOS NON-HLOS.bin --MDM modem.bin --SBL1 sbl1.mbn --SBL2 sbl2.mbn --SBL3 sbl3.mbn --ABOOT aboot.mbn --RPM rpm.mbn --TZ tz.mbn --verbose --no-reboot
Turned the phone off by holding the power button.
Then back into download mode
Next I reflashed CF-Auto-Root using heimdall - again untarred to a folder:
[email protected] 1 myusername staff 9199616 7 Aug 2014 recovery.img ----> CF-Auto-Root Recovery Image
[email protected] 1 myusername staff 17330396 7 Aug 2014 cache.img.ext4 ----> CF-Auto-Root Cache File
then flashed using the following:
Code:
heimdall flash --RECOVERY recovery.img --CACHE cache.img.ext4 --verbose --no-reboot
turned phone off, holding power button.
Then booted into Recovery (Volume Up & Power)
CF-Auto-Root took over and did its thing.
At this stage I had lost custom recovery to Samsung Stock Recovery, so to get it back, again using Heimdall...
unaterred CWM Touch into a folder:
[email protected] 1 myusername staff 8878080 29 Feb 2008 recovery.img ----> CWM Image file
Powered off completely.
Back into Download mode
then flashed as per:
Code:
heimdall flash --RECOVERY recovery.img --verbose --no-reboot
Turned off completely using power button.
Then booted into recovery to check that CWM was back, and it was.
Whilst in CWM, wiped the cache and Dalvik, refalshed my CM12 nightly, and rebooted.
ALL FIXED! and all without having to reflash stock!
HTH
Peace to all.

Got the same problem with my S4 LTE (H3G) .. been playing with ROMs and somewhere something broke the incall sound.. been trying to fix it for ages ( different roms. old nandroid backups,titanium backups) .. nothing helped. I can listen to music from the speaker , but its silent as a stone, when gotta use it for incall talks. The phone speaker and the ear speaker I mean.
The only way I found to workaround is to use bluetooth phones with mic.. Imagine walking around with these for 6+ hours ..
Back on the subject.. Really want to try out your way , but got an Windows Desktop.. Can you point me out how to do it on Windows , please?
Thanks

Hi there,
Heimdall works on Windows too, is cross platform.
Or you can use Odin (someone will have to give you the guidelines there) , or Heimdall frontend (comes in the distro)
Cheers
Sent from my GT-I9505 using XDA Free mobile app

So to expand a little, you will download the flashable bundles in tar format, Google for how best to untar on Windows, I used to use cygwin as my command line back in the day. Then if you use the above guide, and use heimdall, you can use the above commands as they are stated.
Hth
Sent from my GT-I9505 using XDA Free mobile app

Update...
My phone is still working great. My proximity sensor was not responding as well as expected and I was going to recalibrate by command line. However, I never got the time, and a good few days later is working perfectly on its own now, so I guess there is self calibration and one should just be patient
Sent from my GT-I9505 using XDA Free mobile app

[INFO] BOOT PROCESS: ANDROID vs. LINUX

NOTE:
I'm not a developer or Android expert. All information provided here is copied from different internet sources and is to the best of my knowledge. I'll not be responsible for any harm to you or your device resulting from this.
1. PC BOOT PROCESS
Before diving into Android boot process, let's have a look at Linux PC first.
Power Button Pressed
Power On Self Test (POST); identify the devices present and to report any problems
BIOS / UEFI
Necessary hardware initialization (keyboard, disk etc.)
Disk (MBR)
DOS Compatibility Region code (optional)
Bootloader
Active/boot partition (Boot sector)
Kernel
Initrd / initramfs (init)
Services/daemons/processes
BIOS / UEFI is the first software code that is hard-coded on board and runs after we press power button. BIOS runs in real (16 bit) mode of processor, thus it can not address more than 2^20 bytes of RAM i.e. routines can't access more than 1 MiB of RAM, which is a strict limitation and a major inconvenience.
When creating partitions, MBR is saved in LBA0, GPT header in LBA1 and primary GPT in LBA2-33, LBA34 (35th) is the first usable sector. Backup or secondary GPT is saved in last 33 LBAs, last usable sector by OS is ( Total LBAs - 33 ). Partitioning software aligns GPT partitions at larger boundaries, e.g. at LBAs that are multiple of 2,048 to align to 1,048,576 bytes (512 bytes * 2048 = 1 MiB) boundaries. So first sector of first partition is LBA 2048 and so on.
When a system boots, driver of a filesystem is to be loaded in RAM in order to use that filesystem, but driver is itself a file, inside some filesystem. It's like a chicken and egg scenario. So the solution is to always load (as a BIOS/UEFI standard) the first sector on the bootable storage (0/0/1 C/H/S in older schemes and LBA0 in newer), which is (legacy or protective) MBR. This communication between BIOS/UEFI and storage media is through commands which are specific to host controller e.g. ATA commands for devices with SATA/AHCI interface on PC.
Master Boot Record (MBR)
1st 512 bytes (1 sector) at the start of 1st valid disk
Bootstrap code (446 bytes) + Partition Table (64 bytes)
Executable code: Bootloader 1st stage scans partition table and finds 1st sector of active partition (or may point towards intermediate stage)
Partition table provides information about active/bootable partition (and all others as well)
Small size of 64 bytes limits the number of maximum (primary) partitions to 4
Since bootloader unable to understand filesystem (inodes etc.) yet, so MBR is itself executable
Last 2 bytes are boot signatures i.e. to find immediately if disk/drive is bootable or not and hence switch to the next
DOS Compatibility Region
This stage is specific to legacy GRUB, GRUB 2 (default bootloader on most of modern Linux ditros) splits this stage to stage 2 and 3
31.5 KiB / 63 sectors next to MBR, contains filesystem utilities
Still loaded by BIOS routines (or bootloader may use it's own drivers)
Required by certain hardware, or if "/boot" partition (sector containing stage 2) is above 1024 cylinder heads of disk, or if using LBA mode
Volume Boot Record (VBR) / Partition Boot Record (PBR)
Sector no. 63 (64th sector) and above may contain Volume Boot Record or Partition BR, very similar to MBR
Also called Volume Boor Sector, it may be the first boot sector on any partition
NTFS saves VBR as metadata file name $Boot at first clusters, which also contains cluster number of file $MFT. $MFT describes all files on the volume; file names, timestamps, stream names, lists of cluster numbers where data streams reside, indexes, security identifiers (SID's), and file attributes like "read only", "compressed", "encrypted", etc.
If disk isn't partitioned, it's the first boot sector of disk
Boot Partition (if exists)
In MBR scheme, a partition can be marked bootable / active using a flag, usually the first partition of disk
Windows stage 1 bootloader reads and loads only the "Active Partition" from MBR Partition Table
Bootsector or VBR/PBR is read by stage 1 or 1.5 (2 or 3 on GRUB2) bootloader which loads stage 2 (4 on GRUB2) or actual bootloader
MBR / VBR Contains:
Jump instruction (first 3 bytes) i.e. "goto boot code" command
Filesystem header
Executable boot code, usually contains jump instruction for next adjacent sector(s) containing stage 2 bootloader
End of sector (similar to boot signature)
Stage 1 or 1.5 (or 3 on GRUB2) bootloader reads the filesystem table (like MFT / FAT) on partition and loads actual bootloader as a regular file
Bootloader (Actual)
Loaded by previous bootloader from the filesystem of same partition
Loads all necessary filesystem drivers (if any further required)
Configuration is read from database e.g. /boot/grub/ on Linux (GRUB) and <"System Reserved" Partition>/Boot/BCD on Windows (BOOTMGR)
Windows:
BCD is binary file, can be read and modified by commandline tool bcdedit.exe or GUI tool EasyBCD
NTLDR on XP simply used C:\ as active partition reading C:\Boot.ini
Linux:
GRUB makes use of modules to offer extra functionality for complex boot processes
It can show a boot menu to user if needed or configured e.g. for multi-booting or in safe/recovery mode or boot from USB/Network etc.
Locates and loads the kernel of desired OS and ramdisk in RAM
If GRUB is unable to handle the kernel of an OS like Windows, it can be configured for CHAINLOADING i.e. read and execute bootsector of the partition containing Windows bootloader
'os-prober' helps 'grub-install' and 'grub-update' finding Windows boot partition (System Reserved) by reading bootloader configuration in that partition
Kernel
1st MB of kernel from same partition (/boot) loaded in RAM by bootlader in read mode, then switch to protected mode (32-bit) and move 1MB ahead clearing 1st MB
Then swith back to real mode and do same with initrd (if it's separate from kernel)
Kernel contain ramfs drivers to read rootfs from initrd and mount it
Initramfs
Contains minimal filesystem and modules (required drivers which aren't carried by kernel) to access real rootfs (hard driver, NFS etc.)
udev or specific scripts load required modules
<ramdisk>/init is usually a script which loads necessary drivers and mounts real rootfs
finally init switch_root's to real rootfs and executes <real rootfs>/sbin/init; sysV (traditional), upstart (Ubuntu's initiative) or systemD (the latest widely accepted)
init > getty (on virtual terminals) > login (program) > motd > login shell > bashrc / bash_profile​Read more about LINUX CONSOLE & VIRTUAL TERMINALS
UEFI
UEFI can understand filesystem contrary to BIOS, hence no limitation of MBR code (446 bytes)
Needs an EFI System Partition (ESP), preferrably of minimum 550MB
ESP partition is formatted as FAT32 but can understand other filesystems such as FAT12 (floppy), FAT16, ISO9660 (CD/DVD), UDF etc.
EFI firmware reads directly <ESP_Partition>/EFI/<vendor>/<boot_programs> as configured in boot manager (which disk, which partition, which program)
Boot programs make use of EFI firmware or EFI shell or GUI Boot Manager to load kernel
If boot program is just the disk, (no partition and no program configured), then fallback program <disk>/<ESP partition>/BOOT/BOOTX64.EFI is executed
Secure boot feature verifies signature of boot program before loading
Multi-booting is easy, just read different entry from ESP partition unlike relying on single bootloader to chain load all available OS's
EFISTUB feature of Linux kernel allows booting kernel directly as a boot_program
UEFI works better with GPT than MBR
Must read:
ANDROID PARTITIONS & FILESYSTEMS
2. ANDROID BOOT SEQUENCE
There might be a single or multiple bootloaders (to give directions how to boot). For a typical android device (most common Qualcomm SoC / ARM processor), boot sequence is as follows:
BootROM (like BIOS on PC). It's integrated with SoC.
Processors, bootloaders
POST
SBL
Parallel loading related stuff from different partitions.
Application BootLoader (aboot)
Primary Boot Mode (if no Kernel detected or if bootloader/download mode key combination applied)
Bootloader/Download Mode
Secondary boot
Kernel (hardware detection and populating /sys, /dev/ and /proc directories as the processes start) and initramfs (creating rootfs and other pseudo filesystems on rootfs)
Init (first process with PID "1". It initiates further loading of processes and daemons)
System / OS (ROM)
Recovery (if recovery mode key combination applied. It's a kernel with UI to perform basic troubleshooting operations)
3. BOOTLOADERS
Bootloader(s) facilitate the the initial starting up of device by taking control from SoC, performing necessary checks, loading required components and then hand over the charge of booting to kernel. RAM is detected at first stage to start loading configuration of other hardware (like keypad, display etc.) in it.
There exist(ed) multiple bootloaders which are executed by different processors, on different devices with different (partition) names like RPM (PBL), DBL (Device Boot Loader; CFG_DATA or sbl1), SBL2, SBL3 (QCSBL) and OSBL (Operating System Boot Loader) etc.
In a nutshell, on modern ARM devices (Qualcomm SoC):
BootROM / iROM and PBL
iROM run by CPU0 on power button press, loaded in iRAM (before RAM is initialized)
It may set up RAM and execute PBL in RAM or leave this for SBL. iROM/PBL is hard-coded on SoC, written during CPU production process and it's closed source.
On devices (such as open boards or some tablets) which support booting from multiple sources like eMMC/sdcard/USB/UART/Network like a PC BIOS, there is an extra stage between iROM and PBL:
IBL (Initial BL)
It's also loaded in iRAM. Depending on CPU pin settings (hidden and soldered or exposed for manual switching) informed by iROM, IBL passes boot mode selection to PBL and optionally checks PBL integrity if itself e-signed by iROM.
SBL or XBL (Preloader)
IBL calls SBL from eMMC/SDCard which supports LCD output. SBL initializes the DDR RAM, loads the trusted firmware (TZ) and the RPM firmware if not loaded by BootROM. SBL calls the final bootloader after self testing the device.
Uboot is open-source secondary bootloader for embedded devices. However sources of SBL can also be obtained from Qualcomm.
ABOOT (APPSBL; predecessor of Little Kernel)
ABOOT loads Partition Table, kernel, splash screen (logo) and modem. It's also responsible for charging mode and fastboot mode. Memory addresses in RAM for boot/recovery partitions are hard-coded in aboot.
Other examples of final (i.e. just before kernel) bootloaders are uboot (traditional Linux bootloader for embedded devices) or manufacturers' developed BL's like hboot (used by HTC) and redboot etc.
Manufacturers put their limitations (say of network carrier i.e. SIM lock and others) at this stage. USB protocol isn't enough and communication with bootloader to hack such restrictions require special devices (called Flashing Box or Service Box in common language), even sometimes a protocol like JTAG i.e. talk directly to microprocessor.
As a norm, all of these stage-1,2,3... bootloaders are simply called BOOTLOADER. While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Coming back to the booting process, after initializing boot process, bootloader (if it's locked) checks the integrity of boot.img (normal boot) or recovery.img (recovery boot), loads them in RAM and transfers control to kernel offering it with "phys_initrd_start" address of compressed (cpio, gzipped) initramfs.
4. KERNEL & INITRAMFS
Once the kernel is loaded and extracted in RAM by bootloader along with parameters, kernel starts executing. Kernel is in fact a self-contained (static) executable binary, made up of many object files (.o) linked together at compile time. Once the architecture and CPU are identified, architecture-dependent code is executed as per parameters passed from bootloader. Then arch-independent stage is executed which includes setting up drivers (display, touch etc.), filesystems like rootfs, tmpfs, proc, ext4 etc. and initializing console as well (if configured). Here the kernel-space ends and user-space begins (what they call it).
Kernel extracts compressed initramfs in rootfs (which itself is ramfs or tmpfs) and executes /init binary which subsequently reads its configuration files /init.rc and other /*.rc files written in Android specific init language. With the help of kernel, init mounts pseudo filesystems /sys and /proc and populates /dev directory containing device node files. Then it mounts /system and all other partitions including /data (also decrypts it if encrypted) and sets (SELinux security) policies, system properties and environment variables (PATH, EXTERNAL_STORAGE etc.). Additionally init also look after any hardware changes (ueventd) and started services changes (watchdog) occurring dynamically.
Finally init starts the runtime located on the system partition. One of the major last processes started by init is Zygote (Java virtual machine) which compiles apps to run for specific architecture (mostly arm / arm64).
DEVICE TREE BLOB
Device Tree Blob (DTB) - created by DT Compiler (DTC) from DT Source (DTS) text - is a mapping of hardware components on a board/SoC and usually a part of kernel source.
PC hardware usually support hardware enumeration through ACPI i.e. kernel may enquire (probe) the buses - PCI (internal devices), USB (external devices), SCSI (storage devices), HDMI/DVI/VGA (display devices) etc. - which device is connected to it.
Buses on embedded devices (including Android devices) mostly don't support enumeration (hardware discovery) because there are usually fixed set of devices and no option for a different OS to be loaded on device. Therefore OS needs to be informed of all connected devices and this is done by providing a standard DTB to kernel. DTB is provided by SoC / motherboard vendor and is usually a part of kernel source. During boot process, DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
We can view device tree on Adroid device by:
Code:
~# ls /sys/firmware/devicetree/base
~# ls /proc/device-tree
DTB may live on a separate dtb/odm partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but that isn't widely practiced. Usually DTB is appended to kernel zImage/Image.gz or placed at second stage inside boot.img.
VERIFIED / SECURE BOOT
Ensuring a chain of trust from Power ON up to loading of kernel is with the domain of SoC vendor (Qualcomm, Intel etc.) and OEM's. Injecting some malicious or harmful code at any point during booting is made harder to the extent of impossibility.
To ensure a secure booting chain, PBL verifies authenticity of SBL which subsequently verifies integrity of bootloaders (TZ, RPM, DSP, HYP and aboot) so that to avoid loading of unsigned images (boot, recovery, system and others). TZ, after being loaded by SBL also verifies ABOOT using a hardware-based root certificate.
A bootloader with Verified/Secure Boot implementation verifies boot.img or recovery.img (kernel, initramfs and DTB appended to kernel or on second stage of boot.img) by matching their signature with key(s) stored in "OEM keystore" (some partition like CMNLIB, KEYMASTER or with some other name) which itself is signed by OEM. Some vendors allow replacing/appending this keystore with custom one so that custom signed images can be flashed followed by re-locking of bootloader. A simple detail is given here.
At this stage, the chain of trust is handed over to "dm-verity" key stored in boot image initramfs, responsible for "Verified Boot" process of Google/AOSP. Dm-verity (a part of Verified Boot implementing Linux Device Mapper by Google) is a kernel feature i.e. it comes into action after boot image (kernel and ramdisk) is loaded in RAM. It verifies subsequently loading block devices; /system, (/vendor if it exists) and optionally others.
For details see this, this and this.
Google suggests integrating libavb (native code to verify integrity of boot.img) in bootloaders starting from Verified Boot 2.
Unlocking Bootloader
Read here to know about the risks of BL unlocking.
Unsigned kernel or recovery cannot be loaded unless bootloader is unlocked. To make any modification to OS, a critical piece of process is disabling a security system built into the Android's bootloader (aboot) that protects the read-only partitions from accidental (or intentional) modification for privacy, security and DRM. This is what's referred to as "unlocking NAND" or "unlocking bootloader." You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone. Unlocked bootloader ignores signature verification check which was initiated by BootROM and then transferred to "SBL" and then to "ABOOT" while loading kernel or recovery.
Some newer devices don't allow unlocking of bootloader directly (FRP) without permission from manufacturer to ensure more security i.e. contents of partition "devinfo" are signed by the OEM and can't be modified without their approval. After having permission, an official method is provided to unlock BL using PC. Still some functions related to Proprietary Content might be lost due to bootloader unlocking.
DRM is used to protect content from being copied.
Certain pre-loaded content on your device may also be inaccessible due to the removal of DRM security keys.
Click to expand...
Click to collapse
Android Rooting
Must Read: Root User and Linux Capabilities: Linux vs. Android
Note: Unlocking Bootloader and Rooting breaks "Verified Boot". It can be dangerous.
In order to perform some privileged task on Android, we need to "root" the device first. Since it's impossible to start a process with elevated privelages from within running Android OS, rooting usually involves running a root process (su-daemon) from boot with all capabilities. Superuser requests are made by any non-privelaged programs by executing "su" binary and permissions are managed by an app.
In early days, rooting usually involved booting into a custom recovery which in turn mounted and modified /system files. Usually some daemon's executable binary was replaced with a custom script. In order to address the OTA and other issues caused by improving security features (SELinux, Verfied Boot, SafetyNet etc.), systemless root method was introduced which is used by latest apps like Magisk. It involves modifying /boot image and putting some files on /data as well. So a new init service is injected fulfilling all necessary requirements of new security mechanisms.
In both cases, a locked bootloader won't boot custom recovery or modifed kernel (boot.img). See Verified Boot. Therefore bootloader needs to be unlocked for rooting.
However it is possible to gain root sometimes without unlocked bootloader but not always.
Other methods of rooting a phone from within a running ROM using some sort of One-Click rooting solution (KingRoot, Z4Root, KingoRoot etc.) depend on some vulnerability or exploit in Android OS. Making such security breaches is getting harder and harder with every new release of Android and with improved defense mechanisms, though it varies for different vendors too. The most prominent was with the release of Lollipop and Marshmallow when systemless method had to be introduced beacuse the previous methods failed to work. When phone is rooted using one of such improper root methods, there is a high probability to face "incomplete root" like messages at some point. If such a rooting method works for your device, it's alarming. This exploit is also a way for malware to enter your device. For examples, see Magisk Installation - Exploits, this and this. A very popular exploit dirty cow was patched later.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded. Or if you are expert in coding, you can mimic the custom recovery image look like the factory signed firmware and flash it through stock recovery. But this exploit isn't a universal solution either.
So the proper way to rooting which doesn't need any vulnerability, goes through unlocked bootloader. While buying a new phone this must be considered. Keeping you away from root access and unlocked bootloader goes in favor of vendors. By forcing you to use their ROMs (with bundle of useless bloatware apps), they earn a lot from you - money as well as forced loyalty - by collecting data, showing ads and using a lot of other tactics. Go for a brand that provides kernel source and ability to unlock bootloader (on customer's responsibility and with voided warranty obviously).
FIRMWARE UPDATE PROTOCOLS (BOOTLOADER MODE)
Likewise BL, on every device there might be a single or multiple BL modes with different names like bootloader mode, download mode, emergency mode (EDL), ODIN (Samsung), nvFlash tool etc. When we boot in BL mode, device is stuck on boot logo. Some factory flashers work in these modes such as MiFlasher (Xiaomi) and SP Flash Tool (for MTK devices). Bootloader or Download Mode is accessible even if device is soft bricked i.e. if Recovery and/or ROM isn't accessible.
Download Mode
Download Mode (certain button combination while powering on device; usually Vol. Up + Vol. Down or Vol. Down for longer duration + Power) is an official method used by many vendors to flash factory firmware / updates using Flasher (software). Emergency Download Mode (EDL), as it's called on Xiaomi Devices, can also be accessed through fastboot/adb commands or by using some jigs/jumpers. However, to ensure more security, EDL is disabled on some newer devices.
Download Mode is primary to bootloader mode (at PBL or SBL stage) and can be used without unlocking bootloader.
Odin (Samsung), QPST/QFIL work in Download mode (Qualcomm HS-USB QDloader 9008).
When we boot in Download mode, device is stuck on blank screen.
Fastboot Mode
Fastboot - provided by ABOOT - is a software development tool and a standard communication protocol for Android bootloader. It's an alternate of recovery flashing that works in BootLoader mode (aboot) and comes bundled on most of the recent ARM Qualcomm devices. It's a minimal UI through commandline to interact with device in case of failure or to modify / flash partitions. Some OEM's provide fastboot with limited functionality e.g. 'fastboot oem' commands not working and some devices haven't at all. It's up to the discretion of mobile phone vendor.
Fastboot mode is used to perform operations through commands when device is connected to PC through USB. It works even when phone is not switched on in Recovery or ROM or even if android isn't installed on phone. You can read here what operations we can perform through fastboot mode.
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
INIT PROCESSES & SERVICES: ANDROID vs. LINUX
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
RESOURCES:
From the bootloader to the kernel

RESERVED

RESERVED

RESERVED

RESERVED

You have to firstly unlock bootloader to modify partitions "boot" or "recovery" and to gain root access on /system. If bootloader is locked, you only have write access to /cache and /data partitions. Everything else is read-only on device and bootloader will prevent unsigned images from being flashed to the phone.
Click to expand...
Click to collapse
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.

NikosD said:
I'm under the impression that unlocking the bootloader is not mandatory for rooting the device.
You can root the device with a locked bootloader and gain full access to /system partition.
Click to expand...
Click to collapse
Yeah I think my brief statement is a bit misleading because rooting is out of the scope of this thread. I have added some details to first post.

Thank you very much for all this useful info.
Some more comments.
A locked bootloader won't boot custom recovery or modified kernel (boot.img)
Click to expand...
Click to collapse
It happens to have a budget Chinese tablet with Oreo 8.0 and MediaTek SoC, which I can root using a modified/patched boot.img with Magisk v17.1 inside of course - I mean full root without problems - keeping the bootloader locked before and after rooting.
In addition to that, there are some hacks for certain devices to flash custom recovery without unlocking bootloader using some kind of Firmware Flasher tool (SPFlasher, MiFlasher etc.) in Download Mode because Download Mode provides access to device even before bootloader/fastboot is loaded
Click to expand...
Click to collapse
The tablet mentioned above, belongs to this category too.
Using SPFT (Smart Phone Flash Tool), I can flash custom recovery TWRP for my device without unlocking the bootloader.
So, I have two questions:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Thank you.

NikosD said:
1) Is it rare to have such a device or is it common nowadays to be able to root and flash custom recovery TWRP with locked bootloader ?
Click to expand...
Click to collapse
I'm not sure how common it is but I must say these are exploits. Developers are making use of these vulnerabilities for positive and negative purposes. But these are not a "long-term" solution for rooting.
2) How is technically possible to patch boot.img for rooting and flash TWRP using SPFlashTool (even in download mode before bootloader) without complains afterwards from bootloader, verified boot, dm-verity and all these safety checks that validate digital signature of Vendor ?
I mean you can do whatever you want before bootloader starts, but how can you escape from security traps after the initialization of bootloader verifications ?
Click to expand...
Click to collapse
That's what my point is. Fastboot code verifies signatures/hashes only when flashing the image and doesn't verify or fails to verify integrity if image is already flashed. This is not the desired behavior so it's an exploit and it should be closed. Letting unsigned images be flashed in Download Mode is another exploit which is common with Chinese vendors as far as I have come across some instances. They don't address "loopholes" seriously. Failure to stop security breaches at or after bootloader level is definitely on SoC Vendor or OEM's part. I have added a paragraph in first post with some useful details and links.
This link explains:
The Qualcomm SoC is analyzed in the previous chapter dload / edl mode, the mode in the firmware image download process does not do any verification, can be directly written into the brush.
Click to expand...
Click to collapse
It's badly translated from Chinese but is informative.
Exploiting Qualcomm EDL Programmers is a complete series on this subject summarized here.

mirfatif said:
Only NAND (eMMC) and USB modules (drivers) are activated at this stage.
Click to expand...
Click to collapse
Hey pal, I'd like to know if you could help me with an issue I'm facing. I have a Moto G5 that isn't booting to any ROM (it either bootloops in bootlogo or in boot animation), and also on TWRP and during the boot animations the device is slow as hell (like 0.5 FPS on TWRP and even less on boot animation; on TWRP the device also takes a few seconds to complete even the simplest tasks - like the press of a button or the swipe of a slider - here's a video that shows differences between how stuff works on fastboot and how slow things are on TWRP, it takes like 2 hours to completely flash a custom ROM, i.e.).
I know much of the issue will be device-specific, but my point (and the reason I quoted that specific part of your OP) is that, on fastboot mode, the device is snappy and responsive. When I press a button it completes the corresponding task immediately, frames don't stutter (not that there are any animations to be rendered in fastboot, but when I switch from one option to another using the volume keys, it does so on screen as it should, with no lag), and so on. Stock recovery also seems to be ok with speed, but it's even harder to measure than fastboot because, in almost 10 years meddling with android devices, I have always found stock recoveries (and CWM in the pre-TWRP times) to be somewhat slow. Stock recovery definitely looks snappier than TWRP, though. Tried several ROMs, both custom and stock, and the issues remain on all of them.
I got to this post by researching if fastboot mode was stored on the same NAND chip as recovery, OS and so on (found out that yes, it's all on the same chip). If it wasn't, I could just assume it was a hardware fault on the NAND chip, and that would be the reason that fastboot was running fine but recovery and OS weren't, but since they're all on the same cell, I can only think that some part of the system (I mean as in every single code that runs on the device, not only the OS) that loads on TWRP and on normal boot, but not on fastboot (and possibly not on stock recovery) are faulty, thus being a software issue (either solvable with just a normal USB cable or needing a flash box).
So, my question is: which are the differences in the parts of system loaded by fastboot and by TWRP? Are there any parts that are loaded by TWRP that aren't loaded by the stock recoveries on most devices?
I know it's a rather complicated question and some stuff might be device-specific, but if there is anything you could tell me that are more generic to every Android device, it would help me a lot. Thanks in advance.