Database Info

[ROOT] [REF] LG K7 install SuperSU without Kingroot (lgms330 and lgk330)

***It worked for me, but I make no guarantee of invariable results. I therefore, claim no responsibility and offer no warranty. If it does brick your phone, please pm me with the subject "SuperSU without Kingroot" so we can figure out where we went wrong.***
MetroPCS (lgms330) and the T-Mobile (lgk330) models.​
The TWRP method: It's easier than the old method in post 3 which did mess up a couple of peoples phones for some reason. The method in post 3 is still relevant for those who don't want to use TWRP for whatever reason.
You will need:
computer, usb cord, and *adb/fastboot installed
*A note to those who don't know what adb or fastboot is:
There are plenty of tutorials out there explaining how to install and use adb and fastboot.
If you are unfamiliar with these tools you may want to check out this forum.
Part 1: enable developer mode / unlock boot loader
Developer options
On your phone, open settings do the following
Enable Developer mode
{
"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"
}
Enable oem unlock (LG was nice enough to enable us to unlock our bootloader from the "developer options")
Enable adb debug
Plug your phone into your computer and run
Code:
adb devices
you will be prompted to Allow USB debugging?
​
Part 2: installing the Team Win Recovery Project.
I can confirm that the following technique works for the T-Mobile k330 too.
Abridged quoted instructions from this thread / partial copy from post #42 Senior Member: starkly_raving
Prerequisites:
1. unlocked bootloader
2. knowledge of fastboot commands.
First, connect your phone to the computer and run
Code:
adb reboot bootloader
Next, if you want to test but not replace your recovery
Code:
fastboot boot Twrp_m1_v2.img
Instead, if you want to replace your recovery partition with TWRP
Code:
fastboot flash recovery twrp-image-3.img
DOWNLOADS:
New forum has a version of TWRP with a button combination to boot into recovery.
Beta1:
twrp-image-3.img I hope you don't mind me mirroring [MENTION=805681]reemobeens19
Part 3: Installing SuperSu, Xposed framework, and Xposed installer
At the time of this writing these are the latest versions:
Xposed framework: sdk22/arm/xposed-v86-sdk22-arm.zip
Xposed installer: XposedInstaller_3.0-alpha4.apk
SuperSU: Version 2.76
Xposed uninstaller <- You need to flash this in order to completely uninstall the Xposed framework if you don't want it anymore or you want to upgrade with a newer version.
On our phone booting into TWRP can be done with the physical button combinations. If you don't feel like doing finger gymnastics you can use
Code:
adb reboot recovery
Tap install, choose the zip file(s) you downloaded, and the rest is fairly self explanatory.
If I made any errors or omissions feel free to mention it. I really hope this helps.

Xposed Follow up
Now that you have the Xposed Framework installed, you need to install the "Xposed installer" app in order to use it.
You need to go into settings -> security -> and check the box that says "Unknown sources"
If you have downloaded the XposedInstaller_3.0_alpha4.apk onto you phone, then you can use the "File Manager" app already installed on the phone; navigate to the XposedInstaller_3.0_alpha4.apk (probably in your "Download" folder); and tap on it. It will ask if you want to install it so tap install.
Xposed installer needs root access so grant it when prompted. The first time I ran the actual app it threw an error message. Either restart your phone or restart the app (I cannot remember which I did) then it should work.

OBSOLETE
Here are the old instructions for postarity. It worked for quite a few people
***I have followed this exact procedure with a 100% success rate in linux; however, I make no guarantee invariable results. I therefore, claim no responsibility and offer no warranty. If it does brick your phone, please pm me with the subject "SuperSU without Kingroot" so we can figure out where we went wrong.***​
These custom system images come with SuperSu and the appropriate Xposed framework (sdk22/arm/xposed-v86-sdk22-arm.zip) baked right in.
So many people have bricked their LG K7's trying to replace kingroot with the superb SuperSu by chainfire. I have seen many that have bricked their phones trying to flash the latest Xposed framework as well. This method will hopefully be easy enough to deter people relying on kingroot all together. (Feel free to leave feedback in the comments if there is a step that need further elaboration or isn't working)
This tutorial will work for both the MetroPCS (lgms330) and the T-Mobile (lgk330) models.​***This will wipe your device***
​You will need:
computer, usb cord, *adb/fastboot installed, the appropriate system image, and serious patience.
MetroPCS Download:
ms330_root_system.img
T-Mobile Download:
k330_root_system.img
*A note to those who don't know what adb or fastboot is:
There are plenty of tutorials out there explaining how to install and use adb and fastboot.
If you are unfamiliar with these tools you may want to check out this forum.
Developer options
On your phone, open settings do the following
Enable Developer mode
Enable oem unlock (LG was nice enough to enable us to unlock our bootloader from the "developer options")
Enable adb debug
Plug your phone into your computer and run
Code:
adb devices
you will be prompted to Allow USB debugging?
​
Someone who is proficient in Windows please verify that fastboot "sees" the device. I was having trouble getting my Windows 7 64bit machine to recognize it. It worked every time in linux though. Thanks.
ADB/Fastboot commnads
On the computer (in windows you may have to replace adb with adb.exe and fastboot with fastboot.exe)
Code:
adb reboot bootloader
Code:
fastboot oem unlock
Don’t worry about the message it returns:
Code:
FAILED (remote: Already unlocked)
or
Code:
OKAY [ 0.040s]
Let's be OCD and make certain the bootloader is unlock.
Code:
fastboot getvar unlocked
The result should be
Code:
unlocked: yes
finished. total time: 0.001s
Get ready to wait a loooooong time. Flash the correct system image for your device carrier.
DON’T PANIC!!! When you run the fastboot command to flash the system image, it will return something like “Invalid sparse file format at header magi” and hangs for what seems like an eternity. This is normal. The next message it returns is “erasing 'system'...” and then you wait another eternity for the system to be overwritten. Mine took over 6 minutes to complete.
MetroPCS
Code:
fastboot flash system ms330_root_system.img
T-Mobile
Code:
fastboot flash system k330_root_system.img
​
Wait forever for it to get to the “Android is starting…” screen by running
Code:
fastboot reboot
I have no problem with kingroot as a concept. I just want to help people avoid bricking their phones.

It says cannot load 'ms330_root_system.img'
When I did the fastboot getvar unlocked it showed, "unlocked: yes; finished total time 0.000"

IEatFood said:
It says cannot load 'ms330_root_system.img'
When I did the fastboot getvar unlocked it showed, "unlocked: yes; finished total time 0.000"
Click to expand...
Click to collapse
I assume you are on the step where you issue the fastboot command to flash the system image. I'm guessing you don't have the system image in the same directory as you are executing the fastboot command. i.e. If you downloaded the 'ms330_root_system.img' into your Downloads folder you need to change into that directory in the command prompt
Windows cmd
Code:
C:\Windows\system32>
C:\Windows\system32> cd C:\Users\IEatFood\Downloads
C:\Users\IEatFood\Downloads> fastboot flash system ms330_root_system.img
Alternitavly, you could copy/paste the 'ms330_root_system.img' into the same directory as the fastboot.exe
Linux terminal
Code:
~/ $
~/ $ cd Downloads/
~/Downloads $ fastboot flash system ms330_root_system.img

ledzepman71 said:
I assume you are on the step where you issue the fastboot command to flash the system image. I'm guessing you don't have the system image in the same directory as you are executing the fastboot command. i.e. If you downloaded the 'ms330_root_system.img' into your Downloads folder you need to change into that directory in the command prompt
Windows cmd
Code:
C:\Windows\system32>
C:\Windows\system32> cd C:\Users\IEatFood\Downloads
C:\Users\IEatFood\Downloads> fastboot flash system ms330_root_system.img
Alternitavly, you could copy/paste the 'ms330_root_system.img' into the same directory as the fastboot.exe
Linux terminal
Code:
~/ $
~/ $ cd Downloads/
~/Downloads $ fastboot flash system ms330_root_system.img
Click to expand...
Click to collapse
Alright, 'I got the invalid sparse file format at header magi'
finished. total time: 0.002s
C:\Program Files (x86)\Minimal ADB and Fastboot>fastboot flash system ms330_root
_system.img
target reported max download size of 268435456 bytes
Invalid sparse file format at header magi
erasing 'system'...
OKAY [ 0.034s]
sending sparse 'system' 1/9 (257070 KB)...
OKAY [ 8.874s]
writing 'system' 1/9...
FAILED (remote: size too large)
finished. total time: 8.915s

Now it bricked my phone.
It keeps loading Bootloader STATE: Bootloader Unlock!!

IEatFood said:
Now it bricked my phone.
It keeps loading Bootloader STATE: Bootloader Unlock!!
Click to expand...
Click to collapse
My phone is doing the exact same thing after following the tutorial

CompFreak89 said:
My phone is doing the exact same thing after following the tutorial
Click to expand...
Click to collapse
Did it run successfully? If so sometimes you have to do the factory restet. Power off. Hold Vol down and power button. When the screen comes on keep holding down the vol down button let go of the power button and then push the power button again.
If it didn't run successfully please pm be with all the details including your phone model and all the output from the command line. Don't worry we'll get you squared away.

I updated the op to use an easier more standard way with TWRP.

tried it!
can't get past the step where you fastboot it, it get's stuck on the LG logo with small letters at the top
any ideas why?
I am on K330 by the way

To everyone. Please do research before flashing anything. Somebody had an lg Stylo tot. Trying to pass it off as a MS330! Wrong. Please research.
https://www.facebook.com/Czarsuperstar/

azureee said:
can't get past the step where you fastboot it, it get's stuck on the LG logo with small letters at the top
any ideas why?
I am on K330 by the way
Click to expand...
Click to collapse
If your problem hasn't been resolved, can you please describe in further detail what happened. Were you using the obsolete instructions in post 3? Were you on the step where you reboot into the bootloader? If you're really stuck please feel free to pm me.

[email protected] said:
To everyone. Please do research before flashing anything. Somebody had an lg Stylo tot. Trying to pass it off as a MS330! Wrong. Please research.
https://www.facebook.com/Czarsuperstar/
Click to expand...
Click to collapse
Hello, I appreciate your concern. On the topic of research, I was once told "a week in the lab can save you an hour in the library." I absolutely agree and would also encourage everyone to look deeper before plunging in head first.
If you are doubting the authenticity of my efforts and files allow me to elaborate on my method. As you will see, all the files were pulled directly off my personal phone and are not second hand impostors.
First, I looked up the partition table in adb using
Code:
ls -al /dev/block/platform/*/by-name
which output:
Code:
lrwxrwxrwx root root 1970-01-10 18:59 DDR -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 1970-01-10 18:59 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 1970-01-10 18:59 abootbak -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 1970-01-10 18:59 boot -> /dev/block/mmcblk0p33
lrwxrwxrwx root root 1970-01-10 18:59 cache -> /dev/block/mmcblk0p38
lrwxrwxrwx root root 1970-01-10 18:59 config -> /dev/block/mmcblk0p21
lrwxrwxrwx root root 1970-01-10 18:59 devinfo -> /dev/block/mmcblk0p20
lrwxrwxrwx root root 1970-01-10 18:59 drm -> /dev/block/mmcblk0p28
lrwxrwxrwx root root 1970-01-10 18:59 eksst -> /dev/block/mmcblk0p19
lrwxrwxrwx root root 1970-01-10 18:59 encrypt -> /dev/block/mmcblk0p18
lrwxrwxrwx root root 1970-01-10 18:59 factory -> /dev/block/mmcblk0p35
lrwxrwxrwx root root 1970-01-10 18:59 fota -> /dev/block/mmcblk0p23
lrwxrwxrwx root root 1970-01-10 18:59 fsc -> /dev/block/mmcblk0p15
lrwxrwxrwx root root 1970-01-10 18:59 fsg -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 1970-01-10 18:59 grow -> /dev/block/mmcblk0p40
lrwxrwxrwx root root 1970-01-10 18:59 keystore -> /dev/block/mmcblk0p17
lrwxrwxrwx root root 1970-01-10 18:59 laf -> /dev/block/mmcblk0p32
lrwxrwxrwx root root 1970-01-10 18:59 misc -> /dev/block/mmcblk0p30
lrwxrwxrwx root root 1970-01-10 18:59 modem -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 1970-01-10 18:59 modemst1 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 1970-01-10 18:59 modemst2 -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 1970-01-10 18:59 mpt -> /dev/block/mmcblk0p36
lrwxrwxrwx root root 1970-01-10 18:59 persist -> /dev/block/mmcblk0p31
lrwxrwxrwx root root 1970-01-10 18:59 raw_resources -> /dev/block/mmcblk0p26
lrwxrwxrwx root root 1970-01-10 18:59 raw_resourcesbak -> /dev/block/mmcblk0p27
lrwxrwxrwx root root 1970-01-10 18:59 rct -> /dev/block/mmcblk0p24
lrwxrwxrwx root root 1970-01-10 18:59 recovery -> /dev/block/mmcblk0p34
lrwxrwxrwx root root 1970-01-10 18:59 rpm -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 1970-01-10 18:59 rpmbak -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 1970-01-10 18:59 sbl1 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 1970-01-10 18:59 sbl1bak -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 1970-01-10 18:59 sec -> /dev/block/mmcblk0p16
lrwxrwxrwx root root 1970-01-10 18:59 sns -> /dev/block/mmcblk0p29
lrwxrwxrwx root root 1970-01-10 18:59 spare1 -> /dev/block/mmcblk0p22
lrwxrwxrwx root root 1970-01-10 18:59 spare2 -> /dev/block/mmcblk0p25
lrwxrwxrwx root root 1970-01-10 18:59 ssd -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 1970-01-10 18:59 system -> /dev/block/mmcblk0p37
lrwxrwxrwx root root 1970-01-10 18:59 tz -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 1970-01-10 18:59 tzbak -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 1970-01-10 18:59 userdata -> /dev/block/mmcblk0p39
As you can see, "/dev/block/mmcblk0p37" is the block device for the system partition. From there you simply duplicate the data into a raw image by doing
Code:
dd if=/dev/block/mmcblk0p37 bs=2048 of=/storage/external_SD/system.img
To elaborate on what the command does, the input file is the system block mmcblk0p37 and the output file is created as "system.img" on the external sd card. From the man page, "bs=BYTES read and write up to BYTES bytes at a time." So it just means that the dd operation can read and write up to 2048 bytes at a time.
This process was simply repeated using a stock k330, rooted k330, stock ms330, and rooted ms330. After all the raw images were created I systematically flashed them to my personal phone using the instructions verbatim from my op to ensure that they indeed work.
I hope explaining my process sheds further light on the matter. If you want to investigate further on your own you can mount the raw image in linux. Assuming that the system.img file is in your home directory and you have the directory /mnt/tmp , simply run as root
Code:
mount -o ro ~/system.img /mnt/tmp
and you will then be able to see the contents of the image (build prop, preinstalled apps, and the like) in the /mnt/tmp folder.
If you have any further comments or questions I will happily oblige.
The whole point of my effort was to aid people in rooting there phones while mitigating the risk of bricking. I want to make the process as bullet proof as possible so all feedback is welcome. This includes testimonials from those whom this process worked. I guess the next step would be to post the TWRP backup zips to further automate of the process.

unbrick method
@azureee, I am so happy to hear that you found a solution to your problem. Thank you for sharing that link as well. I am sure it will help many people here. If you need any further explanation on installing xposed I would be happy to help.

Please update this forum to have lg-k7 tag and to have newest twrp with button combo. That way this will be on the LG K7 forum and have best TWRP. Also "fastboot boot" is only way it works, flashing will get overwritten by system. And then when you want to get to recovery it will factory reset phone. You can flash after you root.

Billybobjoe13245 said:
Please update this forum to have lg-k7 tag and to have newest twrp with button combo. That way this will be on the LG K7 forum and have best TWRP. Also "fastboot boot" is only way it works, flashing will get overwritten by system. And then when you want to get to recovery it will factory reset phone. You can flash after you root.
Click to expand...
Click to collapse
Thank you for the heads up about TWRP. I keep trying to add that tag, but it refuses to stick.
Edit: I had to delete the tag that wasn't showing up and readd it.

ledzepman71 said:
I updated the op to use an easier more standard way with TWRP.
Click to expand...
Click to collapse
Hi, thank you for the tutorial.
I do have a noob question: After unlocking the bootloader, flashing twrp and flashing supersu from within twrp will the phone be rooted? No need to install Kingroot or similar?
Thanks!

101...
saphta said:
Hi, thank you for the tutorial.
noob question: After unlocking the bootloader, flashing twrp and flashing supersu from within twrp will the phone be rooted?
Click to expand...
Click to collapse
Just go to the Play Store and download a "Root Checker" to get your answer...
Time To Learn How To Run With The *Big Dogs* if you are going to Root..

RaiderWill said:
Just go to the Play Store and download a "Root Checker" to get your answer...
Time To Learn How To Run With The *Big Dogs* if you are going to Root..
Click to expand...
Click to collapse
Thanks! I'll do that!

[GUIDE|HOW-TO|ROOT] Cube iWork 10 i15-TCL - Root / Recovery / Boot.img [WIN|LINUX]

Code:
*** Disclamer
* Your warranty is now void.
*
* We are not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about features included in this ROM
* before flashing it! YOU are choosing to make these modifications, and if
* you point the finger at us for messing up your device, we will laugh at you.
Hi guys and girls, as you may know it's pretty easy to find here on xda but on other forums (techablets for example) info and files for rooting this tablet, but who has the TCL variant /which is Dual Boot Type C one) will only find outdates files and complex guides; that's the reason why - after spending a lot of time on bootloops and fails trying to figure how the hell modify the boot.img) I finally decided to share what I found here.
First thing first: this guide collects, improves and updates how-to from Laura of techtablets; I also want to thanks @jetfin and @master.pumpgun (aka Tom on techtablets) - they know why!
I will basically divide this guide per two: first section is READY TO FLASH, where you'll find my own boot.img (from and ONLY for the latest available stock build); before flashing this image file PLEASE be sure to check if your version is the same I had when preparing the image; also you should absolutely check the MD5 of all the files you will download from here:
check MD5 on any Linux distro by simply typing
Code:
md5sum /path/to/file/file
on Windows you could maybe use this tool: WinMD5
The second section is DO IT YOURSELF, and it's for users with a different kernel/build version from mine. I'll try to eventually update the boot.img if we will receive any new OTA, which I think will never happen. I'll write the second section as soon as possible, but I can speed work up if requested and if Cube updates
- - - - - - - - - - -​
---> READY TO FLASH
Code:
PLEASE NOTE
While the general procedure here reported remains
always correct, the files provided in this part of the
guide - specially the modified boot.img may not work
into your device is the kernel and build version are different
from the one I had, so please go to Settings, About tablet
and check if your specs meet mine:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
If you want to root your i15-TCL there's an high chance you would not need nothing more than backup your data, install drivers and adb/fastboot tools and flash file you will download here! BUT you need to have the same kernel and build as I had when prepared the boot.img file, which is the latest at the moment I'm writing. If you know about a newer version lease notify me and I'll try to process it again.
Last but not least, please note that is a pretty long and detailed Guide, I tried to explain and illustrate every single step, also covering some very common issues you may have, so please don't blame on me if it's a long story to read, I'm sure that a few newbies will appreciate
First thing to do is to backup data you want to restore because we need to unlock the bootloader (unfortunately there's no way to achieve the root without that, I tried everything I could but it's not possible). Also a general backup of all your partitions (both Windows both Android) could help and make you feel more comfortable. To backup partition please refer this thread on techtablets: The big threads of how-tos. Windows users could also have to install the proper Intel driver attached to end of the post.
Once you did that install adb/fastboot:
if you use Windows you can use this tool;
if you use a Linux distro please check if the package android-tools (more info here is available for your distro, otherwise you may have to install the official Android SDK (info about that here; no need Android Studio).
Into your tablet go to Settings / About tablet and press 7 times the Build number fields to enable Developer options; now go Back and tap the new voice Developer option: be sure that the main switch is ON and so the OEM unlocking and the USB debugging ones.
Connect your tablet to your PC, open the command prompt or a Linux shell and type
Code:
adb devices
you should receive an output like
Code:
adb devices
List of devices attached
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
0123456789ABCDEF device
If not, please please stop and check previous steps, but also:
If you use Linux and you see a udev error about permissions you have two solutions: one is running the adb/fastboot by root/sudo, another one is to let udev correctly recognize your idVendor and so your device (always prefer this last way, if possible!), which you can do by following this great mini tutorial on StackOverflow
If you use Windows 64bit try to install the driver attached below; don't know if they are also available for 32bit.
Now you have the basic stuff prepared and you are ready to go to fastboot/bootloader, so this is the last time you could check if your build is the same I had, so please do it if you missed that step before. Once more, the info you read from Settings / About tablet have to be
Code:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
Into your command prompt or shell type
Code:
adb reboot-bootloader
Your device will now go to fastboot mode. You can use your Volume Down / Volume Up to move choose menu commands and Power button to pick one. At the moment you don't need to pick any, so check if you have these two lines in red:
Code:
[COLOR="Red"]SECURE BOOT - disabled
LOCK STATE - unlocked[/COLOR]
If you have these exact lines you can jump to step10. My bootloader (and also Tom one) was already unlocked; others people reported it was locked, I guess it depends from where we bought the device. So, if your bootloader has those two red lines (which means the bootloader is already unlocked) go to step 10. If you have similar lines but in white and with different text, go to next step
CAUTION: this will permanently erase your userdata partition, which is where you store the applications and their data; you may also have there downloads, music, videos and photos so BE SURE you updated your relevant stuff!! If want to go further type into your command prompt/shell
Code:
fastboot devices
and check if you have the right output, that is
Code:
0123456789ABCDEF fastboot
If so, go on by typing:
Code:
fastboot oem unlock
This will erase your data and finally unlock the bootloader. you'll see something like that
Code:
...
OKAY
[ 0.162s] finished. total time: 0.162s
Now reboot the bootloader: move between the menu with the Volume rockers and press Power when you selected the Restart bootloader command. Wait for reboot, choose Android and you are on bootloader / fastboot mode again. Now you should absolutely have those two lines in red from step 6.
Download modified boot.img rootboot_mod.img and once finished PLEASE CHECK THE MD5 of the file: it should ABSOLUTELY match this one: 53cc4b08b123489e7c73cb013742f35d
Type on command prompt/shell
Code:
fastboot flash boot /path/to/your/file/rootmod_boot.img
Let the magic happen!
Now download the custom TWRP recovery (courtesy of @vampirefo), check if MD5 is correct (3c05a8704f5a77e20a45364c7a822a2b) and flash it with
Code:
fastboot flash recovery /path/to/your/file/i15_recovery.img
Use the Volume rockers to pick the Recovery mode command and press Power to go to recovery. Swipe to allow modification, go to Mount and tap the System checkbox
Download the latest SuperSu recovery flashable version available here, check the MD5 reported in that page and then from your tablet in recovery tap Advanced and then Adb Sideload. Swipe to let sideload mode start and type into your command prompt / shell (and change the path /opt/android-sdk/platform-tools/ with the path where YOU installed adb/fasboot)
Code:
adb sideload /path/to/your/file/supersu_file_you_downloaded.zip
If you are on Linux and you have udev permissions issues again when sideloading proceed like that
Code:
cd /opt/android-sdk/platform-tools
su
Password:
[email protected]*********:/opt/android-sdk/platform-tools# ./adb kill-server
[email protected]*********:/opt/android-sdk/platform-tools# ./adb start-server
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
[email protected]*********:/opt/android-sdk/platform-tools# ./adb devices
List of devices attached
0123456789ABCDEF sideload
[email protected]*********:/opt/android-sdk/platform-tools# ./adb sideload /path/to/your/file/supersu_file_you_downloaded.zip
If you have issues on Windows or still having issues on Linux you can always copy the SuperSu zip to a USB Pen and attach the pen to the tablet using the OTG cable or paste the file to a micro SD.
Reboot your device and it's done!
Doing that instead of using the well know root.bat is much better - IMHO - because we don't have to reboot the device two times and we don't have to uninstall SuperSu and flash a new version to update binaries (SuperSu it is not able to update the binaries by itself, nor by recovery nor by app. Also remember that when a new version os SuperSU will be available: Open SuperSu app, go to Settings and tap on Reinstall. Wait for it to finish and shut down the device. Go to bootloader (or use adb when the device is still on), download latest updated flashable SuperSu zip and flash via recovery).
DOWNLOADS SECTION
rootmod_boot.img
i15_recovery.img
- - - - - - - - - - -​
---> DO IT YOURSELF
WARNING: to do that you need a Linux machine / Virtual machine!
First, be sure to have adb and fastboot working; if issues read the first section for common solutions; you should also have already unlocked your bootloader.
If you did not create a dd backup of your partition I recommend once again to do that; you should at least backup android_boot, android_recovery, android_system (but also consider android_bootloader and android_bootloader2). Please note that to check partition in a human readable mode you can use
Code:
adb shell
ls -las /dev/boot/by-name/*
Now we should create our working folders environment; you can do that by yourself or follow my suggstions.
Open a terminal as normal user; you should be in your home folder; launch the following commands one by one
Code:
mkdir -p Android/iWork10/_working/ ; cd Android/iWork10
mkdir _stockimg ; cd _stockimg
adb shell
su
dd if=/dev/block/by-name/android_boot of=/sdcard/boot.img
cd /sdcard/
md5sum boot.img > bootmd5
exit
please note that you could have to execute the exit command 2 times; just be sure to go back to your terminal into your
Code:
/home/USER/Android/iWOrk10/_stockimg
if su is still not available try to dd the same; for me the bootloader was already unlocked and I had no issue to create the dd image
Then
Code:
adb pull /sdcard/boot.img
adb pull /sdcard/bootmd5
and check if MD5 is OK with
Code:
md5sum -c bootmd5
if error recreate the boot image file, if OK go on.
Now we need to download and extract the Android Bootimg Tools; click this link and save it into the
Code:
/home/USER/Android/
folder; once downloaded (the file it's less than 8 kB) we'll extract the two file in the _working dir so to have all the stuff organized; please note that it's important to keep files organized because we'll decompress and re-compress the boot partition and the kernel it contains; if we don't move files appropriately unneeded stuff could go into the kernel! So please try to understand the process or to follow my steps
Code:
cd ../_working/
tar -zxvf ../../android_bootimg_tools.tar.gz
mkdir bootimg
./unpackbootimg -i ../_stockimg/boot.img -o bootimg/
As you can see we unpacked the stock boot.img to the folder bootimg we just created..
Now let's extract the ramdisk, that is where we were pointing from the start..
Code:
cd bootimg ; mkdir ramdisk ; cd ramdisk
gunzip -c ../boot.img-ramdisk.gz | cpio -i
Now if you are familiar with nano or pico terminal continue on terminal to apply the following mods, otherwise open your file manager to the ramdisk folder, then open the default.prop file and change
Code:
ro.secure=1
to
Code:
ro.secure=0
Save and close the editor.
Open the init.rc file and change
Code:
service media /system/bin/mediaserver
class main
user [COLOR="Red"]media[/COLOR]
to
Code:
service media /system/bin/mediaserver
class main
user [COLOR="Red"]root[/COLOR]
Please note here that if your bootloader was unlocked without your intervention you could have already user root (I had). In that case just leave as it is and close, otherwise save and close.
Go back to your terminal, you should still be into the ramdisk folder, if not navigate with cd to go to that folder and then
Code:
find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz
Now we have our new ramdisk; at this point we need to open the boot.img-cmdline file that is located into the bootimg folder and copy its content, then go back to the terminal; the terminal should be still in ramdisk folder, so
Code:
cd ..\..\
and we are into the _working folder.
Now the last command, that you CANNOT simply copy and paste. The command is something like that (hold on, don't execute it)
Code:
./mkbootimg --kernel bootimg/boot.img-zImage --ramdisk bootimg/newramdisk.cpio.gz --cmdline 'CONTENT OF YOUR boot.img-cmdline CONTENT HERE; PUT IT BETWEEN SINGLE ' BOTH AT THE START BOTH AT THE END' -o root_boot.img
Please note the double -- for kernel, ramdisk and cmdline options (while single - for -o that stays for output) and also note the single ' peaks that contain the boot.img-cmdline content.. So in my case it will be:
Code:
./mkbootimg --kernel bootimg/boot.img-zImage --ramdisk bootimg/newramdisk.cpio.gz --cmdline 'loglevel=5 androidboot.hardware=cht_cr_mrd_w firmware_class.path=/system/etc/firmware i915.fastboot=1 memmap=4M$0x5c400000 vga=current i915.modeset=1 drm.vblankoffdelay=1 enforcing=0 androidboot.selinux=permissive console=ttyS0,115200n8 bootboost=1 pm_suspend_debug=1 pstore.backend=ramoops' -o ../root_boot.img
BUT PLEASE DON'T COPY AND PASTE THIS ONE; JUST USE YOUR boot.img-cmdline FILE (I'm pretty sure they are identical but cannot be sure, SO USE YOURS)
If the command doesn't give errors or the standard output that describe the usage of a linux command (so like usage: mkbootimg --kernel <filename> --ramdisk <filename> - this means you missed something) we are done, we just need to flash it and root. So we now have our modified boot image which will let the tablet boot a rooted OS without bootloop.
If you haven't do it already go to download latest Recovery Flashable zip of SuperSU from SuperSu webpage and the custom TWRP recovery for this device that you find in the first section (also check MD5) and copy both to your internal of external sdcard (if you are not familiar with sideload)
Reboot your device to bootloader with
Code:
adb reboot-bootloader
Once it's there,
Code:
fastboot flash boot /home/USER/Android/iWork10/root_boot.img
fastboot flash recovery /path/where/you/downloaded/recovery.img
Now use the volume rockers to pick RECOVERY MODE option and press the Power button. The device will boot the TWRP recovery; allow system modifications when asked and finally flash the SuperSu zip file you downloaded and copied to the tablet (or use adb sideload /path/to/supersu/into/your/pc/supersufile.zip)
You may need to adjust settings in TWRP (timezone and language), then reboot the system and you should have rooted your i15-TCL!
It's easy, isn't it?
PLEASE NOTE: If you have errors like adb, fastboot not recognizing your device, don't ask but read the other section where I explain the most common solution for Windows and Linux; same if you don't find links for recovery, SuperSU or other read the first section, thanks!
- - - - - - - - - - -​
THANKS
@jetfin for providing a lot of goodies that saved my ****** last month (wish you all the best for the next future mate!)
@master.pumpgun (aka Tom on techtablets - amazing guy! :good
@vampirefo for custom TWRP for this device
Laura - for all the info she's made available for this device

Great job mate!
It seems very analytical and very useful for people who need a step by step guide.
Unfortunately it requires a full wipe of user data, so for now I am not willing to try this guide.
Sent from my i15-TCL using Tapatalk

RASTAVIPER said:
Great job mate!
It seems very analytical and very useful for people who need a step by step guide.
Unfortunately it requires a full wipe of user data, so for now I am not willing to try this guide.
Sent from my i15-TCL using Tapatalk
Click to expand...
Click to collapse
Well, I feel you, unlocking is always annoying but there are apps which let you backup everything.
I couldn't live without root + Link2SD into the cube!
Thanks for the nice words ?
Inviato dal mio Nexus 7 utilizzando Tapatalk

Hi brainvison,
it`s a nice, correct and clear tutorial, many thanks.
Only one question
Fortunately I have an unlocked bootloader, then I`ll do it from step 10, but I have a same kernel and build version (3.14.37/x86_64-L1-R517 and V1.0) but the date of this version is different (20160913).
What do you suggest, try it? Or could you help me to create a new version of the boot.img, please?
Nice regards
Peter
brainvision said:
Code:
PLEASE NOTE
While the general procedure here reported remains
always correct, the files provided in this part of the
guide - specially the modified boot.img may not work
into your device is the kernel and build version are different
from the one I had, so please go to Settings, About tablet
and check if your specs meet mine:
[B]Model[/B] i15-TCL
[B]Kernel[/B] 3.14.37-x86_64-L1-R517 [email protected] #1
Sat May 7 17:02:18 CST 2016
[B]Build[/B] i15-TCL_V1.0_20160507
Click to expand...
Click to collapse
​

rpeter said:
Hi brainvison,
it`s a nice, correct and clear tutorial, many thanks.
Only one question
Fortunately I have an unlocked bootloader, then I`ll do it from step 10, but I have a same kernel and build version (3.14.37/x86_64-L1-R517 and V1.0) but the date of this version is different (20160913).
What do you suggest, try it? Or could you help me to create a new version of the boot.img, please?
Nice regards
Peter
Click to expand...
Click to collapse
both kernel and build dates are different, aren't them?
I'll try to write the missing section as soon as possible, don't worry..
In the meantime could you please check a few things that could help to understand a few things?
If your bootloader is unlocked you should have no issue doing that; assuming you already have adb working, open a terminal and execute this commands (just "read" commands, no mods here)
Code:
adb shell
uname -a
cat default.prop
If errors try to execute adb root (this does NOT root, it just use adb as root user, it should work with the unlocked bootloader) before adb shell and if possible please report me the output from unameand cat
EDIT: also my advice is to backup your system partitions so to able to go back to stock if needed; at least partitions
Code:
android_boot
android_bootloader
android_bootloader2
android_recovery
android_system
To do that you could check Laura's thread from techtablets or use
Code:
dd if=/dev/by-name/your_partition of=/sdcard/your-partition.img
the if= option is where you choose the partition to backup while the of= one is the resulting file that will be created (an image .img file)
If you agree you could also upload those somewhere on the cloud so we could use them, too, it would be interesting to see what changes.. Naturally the partition I suggested do not contain any personal file, no worry about that (your data is on the android_userdata - or _data, don't remember the name here).
EDIT2: you'll need a Linux machine to mod your boot.img partition, do you have one?

brainvision said:
both kernel and build dates are different, aren't them? yes, both of the are the same date:20160913
the build.prop is:
Code:
[email protected]:/system # cat build.prop
# begin build properties
# autogenerated by buildinfo.sh
ro.build.id=LMY47I
ro.build.display.id=i15-TCL_V1.0_20160913
ro.build.version.incremental=eng.softteam.20160913.102513
ro.build.version.sdk=22
ro.build.version.codename=REL
ro.build.version.all_codenames=REL
ro.build.version.release=5.1
ro.build.version.security_patch=2016-03-01
ro.build.version.base_os=
ro.build.date=Tue Sep 13 10:26:20 CST 2016
ro.build.date.utc=1473733580
ro.build.type=userdebug
ro.build.user=softteam
ro.build.host=pdd-build
ro.build.tags=release-keys
ro.build.flavor=cht_cr_mrd_w-userdebug
ro.product.model=i15-TCL
ro.product.brand=i15-TCL
ro.product.name=cht_cr_mrd_w
ro.product.device=i15-TCL
ro.product.board=i15-TCL
# ro.product.cpu.abi and ro.product.cpu.abi2 are obsolete,
# use ro.product.cpu.abilist instead.
ro.product.cpu.abi=x86
ro.product.cpu.abilist=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist32=x86,armeabi-v7a,armeabi
ro.product.cpu.abilist64=
ro.product.manufacturer=i15-TCL
ro.product.locale.language=en
ro.product.locale.region=US
ro.wifi.channels=
ro.board.platform=gmin
# ro.build.product is obsolete; use ro.product.device
ro.build.product=cht_cr_mrd_w
# Do not try to parse description, fingerprint, or thumbprint
ro.build.description=cht_cr_mrd_w-userdebug 5.1 LMY47I eng.softteam.20160913.102513 release-keys
ro.build.fingerprint=intel/cht_cr_mrd_w/cht_cr_mrd_w:5.1/LMY47I/softteam09131026:userdebug/release-keys
ro.build.characteristics=tablet
# end build properties
#
# ADDITIONAL_BUILD_PROPERTIES
#
ro.dalvik.vm.isa.arm=x86
ro.enable.native.bridge.exec=1
sys.powerctl.no.shutdown=1
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=100m
dalvik.vm.heapsize=174m
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapminfree=512k
dalvik.vm.heapmaxfree=8m
ro.opengles.version=196609
ro.setupwizard.mode=OPTIONAL
ro.com.google.gmsversion=5.1_r1
ro.gnss.sv.status=true
ro.hwui.texture_cache_size=24.0f
ro.hwui.text_large_cache_width=2048
ro.hwui.text_large_cache_height=512
drm.service.enabled=true
keyguard.no_require_sim=true
ro.com.android.dataroaming=true
ro.com.android.dateformat=MM-dd-yyyy
ro.config.ringtone=Ring_Synth_04.ogg
ro.config.notification_sound=pixiedust.ogg
ro.carrier=unknown
ro.config.alarm_alert=Alarm_Classic.ogg
persist.sys.language=zh
persist.sys.country=CN
persist.sys.timezone=Asia/Shanghai
persist.sys.dalvik.vm.lib.2=libart.so
dalvik.vm.isa.x86.features=sse4_2,aes_in,popcnt,movbe
dalvik.vm.lockprof.threshold=500
net.bt.name=Android
dalvik.vm.stack-trace-file=/data/anr/traces.txt
# begin fota properties
ro.fota.platform=IntelZ3735F_5.1
ro.fota.id=mac
ro.fota.type=pad_phone
ro.fota.oem=hampoo-cherrytrail_5.1
ro.fota.device=i15-TCL
ro.fota.version=i15-TCL_V1.0_20160913
# end fota properties
[email protected]:/system #
I'll try to write the missing section as soon as possible, don't worry..
Many thanks
Code:
adb shell
uname -a
cat default.prop
the adb root and the cat is ok, but the uname is not found
the output of the cat is:
Code:
127|[email protected]:/ # cat default.prop
#
# ADDITIONAL_DEFAULT_PROPERTIES
#
ro.sf.lcd_density=240
ro.frp.pst=/dev/block/by-name/android_persistent
persist.intel.ogl.username=Developer
persist.intel.ogl.debug=/data/ufo.prop
persist.intel.ogl.dumpdebugvars=1
ro.ufo.use_msync=1
ro.ufo.use_coreu=1
wifi.interface=wlan0
persist.service.apklogfs.enable=1
persist.core.enabled=0
ro.secure=1
ro.allow.mock.location=0
ro.debuggable=1
ro.modules.location=/lib/modules
ro.dalvik.vm.native.bridge=libhoudini.so
persist.sys.usb.config=mtp,adb
persist.nomodem_ui=true
ro.zygote=zygote32
dalvik.vm.dex2oat-Xms=64m
dalvik.vm.dex2oat-Xmx=256m
dalvik.vm.image-dex2oat-Xms=64m
dalvik.vm.image-dex2oat-Xmx=64m
[email protected]:/ #
EDIT: also my advice is to backup your system partitions so to able to go back to stock if needed; at least partitions
Code:
android_boot
android_bootloader
android_bootloader2
android_recovery
android_system
All of my partitions expect the largest one(maybe windows) were backed up to sd with dd
If you agree you could also upload those somewhere on the cloud so we could use them, too, it would be interesting to see what changes.. Naturally the partition I suggested do not contain any personal file, no worry about that (your data is on the android_userdata - or _data, don't remember the name here).
I will upload it to somewhere, but which partitions are you need (i don't no clearly, how can I determinate, which partition is the boot, bootloader, ...)
the outputs of the /proc/partitions are the following:
Code:
[email protected]:/ # cat /proc/partitions
major minor #blocks name
254 0 102400 zram0
179 0 61071360 mmcblk0
179 1 102400 mmcblk0p1
179 2 102400 mmcblk0p2
179 3 30720 mmcblk0p3
179 4 30720 mmcblk0p4
179 5 1024 mmcblk0p5
179 6 16384 mmcblk0p6
179 7 2621440 mmcblk0p7
179 8 262144 mmcblk0p8
179 9 8388608 mmcblk0p9
179 10 1024 mmcblk0p10
179 11 8192 mmcblk0p11
179 12 102400 mmcblk0p12
179 13 16384 mmcblk0p13
179 14 48361472 mmcblk0p14
179 15 1024000 mmcblk0p15
179 48 4096 mmcblk0rpmb
179 32 4096 mmcblk0boot1
179 16 4096 mmcblk0boot0
179 64 15671296 mmcblk1
179 65 15667200 mmcblk1p1
253 0 2600764 dm-0
maybe the *p3 is the bootloader, the *p14 is the windows, maybe the *p9 included the data and *p7 is the system, but don't know, which one is the boot, bootloader2, recovery
EDIT2: you'll need a Linux machine to mod your boot.img partition, do you have one?
Click to expand...
Click to collapse
yes, I have, a debian.
One question, if we have any problem with the upload the modified bootloader, how can i restore the old one (how can I upload (which method, adb, fastboot, or the phone flash?) an original bootloader, if we have a problem with the modded bootloader)
Have you link(s) with the full original windows and andoid image of the i15-tcl? I found to i15-t, i15-td, but not for this version...
Nice regards
Peter

i have the same software version as rpeter. When i first boot in fastboot my bootloader was unlocked and secure boot was disabled. Itried flash twrp and it was succesful. Next i downloaded superSu zip from official website and i flashed it. After reboot i stuck at bootlogo. Can you share me a system image to restore?

The mmcblk0p9 partition is the system? I will share it as soon as possible.

07 is system. 09 is data partition.
https://drive.google.com/file/d/0B_QRR9kog1iZQ2ZaNzdZenQ4MkE/view?usp=sharing

@rpeter I'll read your long reply asap, now just want to tell you that to check partition in a human readable way you should use
Code:
ls -las /dev/block/by-name/*
the partition I would like you to share are
Code:
android_boot
android_bootloader
android_bootloader2
android_system
android_recovery
when using dd of course as I told you can directly point to that name convention (which are nothing but symbolic link) so
Code:
dd if=/dev/block/by-name/android_boot of=/sdcard/android_boot.img
this is for the boot partition, the other the same..
also please before uploading to cloud check the MD5 so we could verify it before installing
are you sure you wrote uname -a the right way? It's weird you don't have it...
About restoration, you could use fastboot in future, I tried it by myself.. the most important are
Code:
fastboot flash boot boot.img
fastboot flash recovery recovery.img
fastboot flash system system.img
I don't think we'll ever need the two bootloader restoration, it's just to go extremely safe but I still don't find a reason to flash them.. But backup anyway!
EDIT: please note the .img extension for the of= part of the dd command!
@boberq sorry for your issue but I have to say that it was obvious: it's not plenty of guides and how-to about this tablet but the few available are also easy to find, and they all clearly state that you need to modify the boot image before rooting, otherwise as you know now, bootloop!
so, if you guys need to immediately root you can send me the boot.img file and I do it for you, otherwise you can wait and do it by yourself - I'm going to write the how-to right now, it should be ready for tomorrow, I guess..
EDIT and yes, we don't have any full restoation image like for other variants, I asked them on Twitter https://twitter.com/CubeHeping (it seems this is their official account that I found via www.51cube.com) - please do the same, maybe they will listen to us

I flashed i15 td rom and it works without auto rotation. If rpeter share images i want flashthe stock.
---------- Post added at 12:52 PM ---------- Previous post was at 12:44 PM ----------
I flashed a i15td rom and everything is fine without auto rotate. Rpeter please share boot and system images, they help me to restore the stock rom.
Ps After first boot if i want enter to recovery , it show red triangle with green android. There was any recovery.

boberq said:
I flashed i15 td rom and it works without auto rotation. If rpeter share images i want flashthe stock.
---------- Post added at 12:52 PM ---------- Previous post was at 12:44 PM ----------
I flashed a i15td rom and everything is fine without auto rotate. Rpeter please share boot and system images, they help me to restore the stock rom.
Ps After first boot if i want enter to recovery , it show red triangle with green android. There was any recovery.
Click to expand...
Click to collapse
stock recovery is not a real recovery there.. Red triangle is the right thing.. BUT if you flashed the custom TWRP with
Code:
fastboot flash recovery recovery.img
you should have noticed that the process failed.. I don't remember the exact output but you should have seen FAILED instead of SUCCESS. If flash succeed you also need stock recovery, I guess, otherwise it should still bootloop after system restore..

@brainvision
Has anything changed about rooting?
I remember that the process was involving resetting in order to unlock bootloader, etc
Sent from my m1 note using Tapatalk

RASTAVIPER said:
@brainvision
Has anything changed about rooting?
I remember that the process was involving resetting in order to unlock bootloader, etc
Sent from my m1 note using Tapatalk
Click to expand...
Click to collapse
nope, and it never will in that direction..
you should definitively make a backup, the more you'll wait the worst it'll be!

I flashed twrp and from it i want flash supersu and i get bootloop. After this i flashed i15td rom andeverything works fine. So can i flash boot,recovery and system image and get stock without root? Or should i flash it using intel flash tool?

boberq said:
I flashed twrp and from it i want flash supersu and i get bootloop. After this i flashed i15td rom andeverything works fine. So can i flash boot,recovery and system image and get stock without root? Or should i flash it using intel flash tool?
Click to expand...
Click to collapse
you can flash them with fastboot indeed and then root again, I finished writing my how-to, I'm formatting it and update the first post in an hour max..
Never looked at Intel Flash Tool, I don't know if it permits the flash of a single partition or if you need a full image provided by OEM, can't help with that..

So i'm waiting for original images from rpeter and i'm goind to flash it. I have a twrp backup with original 20160913 firmware but after bootloop. I can sare it but i think it isnt usefull.
PS
Brainvision , can you share me your original partition images for i15TCL from May? I think it will repair my autorotation.

boberq said:
So i'm waiting for original images from rpeter and i'm goind to flash it. I have a twrp backup with original 20160913 firmware but after bootloop. I can sare it but i think it isnt usefull.
PS
Brainvision , can you share me your original partition images for i15TCL from May? I think it will repair my autorotation.
Click to expand...
Click to collapse
I do NOT recommend you to flash that because you will completely mess things up, having boot, recovery and kernel with a build date and system with a different one! You went to fast on rooting your device without reading stuff, now I suggest you to wait for @rpeter images - but anyway here it is system.img https://mega.nz/#!YBdw1bIT!GibOWLBNyXAhwEiEdXIV3JKKdMM9gXzLIYvppKn0Bgs
EDIT: guys I updated OP with the missing sectioon, please click thanks if you find it useful..
@rpeter before rooting remember to backup partition with dd, then upload when you can but backup before rooting!
if you have suggestion for the guide or you think something is not so clear please tell me that I'll try to improve..

brainvision, boberq, I'm so sorry, yesterday is one of my longest working day...
My gdrive is currently full, bu I created a dedicated place for yours in my server.
The link is: http://rpeter.dyndns.info/xda
user: xda_users
pwd: i15-tcl
It's included all partitions compressed and uncompressed version expect p9 and p14 (data and windows) and the md5 checksum file.
The output of the "identification" is here:
Code:
127|[email protected]:/ # ls -las /dev/block/by-name/*
lrwxrwxrwx root root 2016-11-12 12:21 Basic_data_partition -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2016-11-12 12:21 EFI_system_partition -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2016-11-12 12:21 Microsoft_reserved_partition -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2016-11-12 12:21 android_boot -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader2 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2016-11-12 12:21 android_cache -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2016-11-12 12:21 android_config -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2016-11-12 12:21 android_data -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2016-11-12 12:21 android_metadata -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2016-11-12 12:21 android_misc -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2016-11-12 12:21 android_persistent -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2016-11-12 12:21 android_recovery -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2016-11-12 12:21 android_system -> /dev/block/mmcblk0p7
[email protected]:/ #
I will put it somewhere fastest place, when I have enough time to do it
Nice regards
Peter

rpeter said:
brainvision, boberq, I'm so sorry, yesterday is one of my longest working day...
My gdrive is currently full, bu I created a dedicated place for yours in my server.
The link is: http://rpeter.dyndns.info/xda
user: xda_users
pwd: i15-tcl
It's included all partitions compressed and uncompressed version expect p9 and p14 (data and windows) and the md5 checksum file.
The output of the "identification" is here:
Code:
127|[email protected]:/ # ls -las /dev/block/by-name/*
lrwxrwxrwx root root 2016-11-12 12:21 Basic_data_partition -> /dev/block/mmcblk0p14
lrwxrwxrwx root root 2016-11-12 12:21 EFI_system_partition -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2016-11-12 12:21 Microsoft_reserved_partition -> /dev/block/mmcblk0p13
lrwxrwxrwx root root 2016-11-12 12:21 android_boot -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2016-11-12 12:21 android_bootloader2 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2016-11-12 12:21 android_cache -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2016-11-12 12:21 android_config -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2016-11-12 12:21 android_data -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2016-11-12 12:21 android_metadata -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2016-11-12 12:21 android_misc -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2016-11-12 12:21 android_persistent -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2016-11-12 12:21 android_recovery -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2016-11-12 12:21 android_system -> /dev/block/mmcblk0p7
[email protected]:/ #
I will put it somewhere fastest place, when I have enough time to do it
Nice regards
Peter
Click to expand...
Click to collapse
great work mate!
Thanks a lot. As you may have read I updated the OP with the new section, hope you'll find useful and clear enough, if not don't hesitate to ask, it will be a pleasure to help and to improve the how-to

[INFO] ANDROID DEVICE PARTITIONS and FILESYSTEMS

NOTE:
I'm not a developer or something even near to that. I'm a newbie and will be, seems so. All information provided here is copied and compiled from different internet sources like this and many others.
This information is according to best of my knowledge and comprehension and is just for curious souls like me who want to understand things in quite simple words. It might be wrong and I will open-heartedly welcome any correction or addition from anyone.
I'm not responsible for any harm to you or your device resulting from this.
1. PARTITION TABLE
The Phone's Internal Memory (eMMC or UFS; not the SD card) is solid-state (flash) memory, aka NAND. Raw NAND, as it's called, is basically a pure flash memory dependent on CPU to control it. But in order to use flash memory just like a traditional hard drive (block device), NAND is equipped with an (embedded multimedia) micro-controller. It's called eMMC.
eMMC can be partitioned much like a hard drive on PC. PC's have traditionally been partitioned with BIOS compatible Master Boot Record (MBR) scheme in which first sector of disk contains the details of partitions called Partition Table. Limited size of boot sector (512 bytes) puts a limitation of at maximum 4 (primary) partitions listed in MBR. Extended partition has been used for 4+ partitions.
GUID Partition Table (GPT) was introduced with UEFI booting system which isn't dependent on first boot sector and hence may contain up to 128 partitions. GPT also does CRC check, has backup GPT, identifies partitions by GUID and partitions have a label.
Android devices use GPT. We can view and manipulate GPT using Linux tools such as parted and gdisk while fdisk is the traditional tool for MBR partitions.
To view partition table on internal memory:
Code:
~# parted /dev/block/mmcblk0
(parted) p free
~# gdisk -l /dev/block/mmcblk0
(The external SD Card can also be partitioned to include a section dedicated to storing user apps (like Link2SD does) or to create partitions for secondary or tertiary OS on Android device using some multiboot kernel and recovery system). Even we can put whole OS/ROM on an SD card.
2. BRIEF INTRO
Contents of Android partitions can be partially or completely modified by flashing an image (filesystem .img or executable binary or a flashable zip) to them. But we never need to modify most of them and whatever manufacturer wrote on them, resides there unmodified (read-only) for the whole of device life. A user uses only one partition /data to save personal data like photos, music etc. All the other are for device to run. There are typically in the range of 50 partitions on an Android device but only a few partitions are modified for the purpose of adding new features or upgrading the device. A custom ROM or minor upgrade is also limited to modify /boot, /system and /data partitions usually. Most of the partitions are almost intact, containing bootloaders, firmwares, settings etc. Here is a "summarized" detail to these partitions which matter to a common but interested user.
On most devices /system and /data are larger partitions (on some devices /custom or a similar partition too) covering almost 90% of eMMC. All others are smaller ones of a few KB's or MB's.
3. SoC / CHIPSET / PROCESSORS RELATED PARTITIONS
SoC is the first component when we start a PC or Mobile phone which initialzes hardware and processors and loads bootloaders in memory to bootstrap OS. It's an integrated chip containing multiple things e.g. CPU, GPU, modem, wifi etc. It varies for device manufacturers and SoC vendors (chipset plus processor).
Some partitions are specific to SoC, most of them are closed-source executable binary blobs (like aboot, sbl, rpm, tz, cmnlib, devcfg, keymaster, lksecapp and others on a Qualcomm device), loaded step-by-step by bootloaders.
MODEM or RADIO - the phone's radio
Also called baseband, it is responsible for signals and on older devices may control wifi, bluetooth, and GPS (on most newer devices, these are handled by the kernel and ROM). Upgrades are country dependent and may improve or diminish battery performance, network signal strength, and roaming capability. It is also sometimes required to have a minimum Baseband version to use a ROM so that the RIL will play nice with the Baseband.
Modem firmware is a mini-OS for the cellular radio chip which has its own processor. Firmware is a general term, firmware exists for a lot of things on phone. The wireless chip for WiFi, GPS, and Bluetooth often has a firmware as can the GPU core among other things. These firmware files are usually located inside the SYSTEM or VENDOR partition. The modem firmware is special because it has its own separate Baseband Processor (BP) so the firmware is left out of the system image in its own partition.
Modem is not an Android-specific partition. It is tied to the hardware of the phone, but the kernel has a code allowing Android to interact with the hardware. But the baseband processor (BP) - which runs modem and is responsible for all communication through mobile networks e.g. call, SMS and internet - is totally isolated from Application Processor (the one we call CPU) and is not governed by Android kernel; it runs an independent RTOS.
RIL/Radio Interface Layer
This is not a separate partition, but a part of the ROM and is like a driver for the Radio. RIL daemons provides telephony and cellular data i.e. adds phone to smartphone. There is a matching RIL for each Baseband version and you can flash it to match your Baseband after flashing a ROM. Having mismatched RIL and Baseband can range from having no effect at all, slight battery drain, loss of roaming, or even no connection to the cell network. Many ROMs keep their RIL updated to the latest. Job of the RIL is to translate all the telephony requests from the Android telephony framework and map them to the corresponding AT commands to the modem, and back again. AT set of commands is used to communicate with modem i.e. baseband processor (BP) which is a must have processor on Android devices in addition to normal CPU i.e. Application Processor (AP).
TZ (TrustZone) - used by ARM processors as an additional lock to security features. It combines user's encryption key with a hardware specific key generated by encryption processor (like TPM on Windows) to make security breaching more difficult. It can also be used to implement Trusted Execution Environment (TEE).
RPM (Resource/Power Management) which starts executing Primary/Primitive BootLoader (PBL) in BootROM - controls power to radio, modem etc.
DSP (Digital Signal Processor) - by Qualcomm to assist in things like smooth video playback (realtime media and sensors processor) as well as runs RTOS for modem
HYP (Hypervisor) - Virtual Machine Monitor, to enable Virtual Machine platform
4. BOOTLOADERS
Bootloaders - in many steps - hand over charge to kernel after loading in RAM. These are mostly standalone ELF executable files becuase at this stage no filesystem is loaded and only executable code may work. These are all closed source components on Android device, provided by SoC vendors - either built-in or as binary blobs.
SBL - Secondary bootloader loaded by SoC, loads ABOOT in memory, also provides (Emergency) Download Mode (EDL) on many devices, a Firmware Update Protocol.
ABOOT (bootloader.img or aboot.mbn file in Factory Firmware) - Applications Bootloader is the main bootloader responsible for loading kernel or recovey and fastboot - a Firmware Update Protocol - as well.
Kernelflinger is a similar bootloader on Intel devices.
Read ANDROID BOOT PROCESS to know more about bootloaders.
5. CORE AOSP PARTITIONS
BOOT - Kernel and initramfs (modern form of of ramdisk and ramfs/tmpfs)
A kernel is a layer of code that allows the OS and applications to interface with your phone's hardware. The degree to which you can access your phone's hardware features depends on the quality of code in the kernel. Several kernel code improvements give us additional features from our hardware that the stock kernel does not. When you flash a custom ROM, you automatically get a kernel. But you can also flash a standalone kernel on top of the existing one, effectively overwriting it. These days, the difference in custom kernels is less about new features and more about alternate configurations. Choosing a custom kernel is basically choosing one that works best with your ROM.
Device Tree Blob (DTB), along with hardware drivers, are baked with kernel source in boot.img. DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly.
On a Linux system init along with scripts, binaries kernel drivers and modules (in initrd.img), kernel (vmlinuz executable) and bootloader configuration along with modules, they all reside on root or a separate partition (mounted) at /boot. While on Android, init along with a few binaries and configuration files and kernel reside in a separate partition named "boot" with a special filesystem. Boot.img is created using tools like mkbootimg after building kernel.
This is how kenrel and DTB are built:
vmlinux > Image > zImage / Image.gz > Image.gz-dtb
vmlinux: Large sized non-bootable Linux kernel (executable) with debug symbols, just an intermediate step to producing vmlinuz
vmlinux.bin: Same as vmlinux binary but with removed symbols, produced by 'objcopy'
vmlinuz: Compressed and bootable Linux kernel file; one of zImage or bzImage formats; compressed using zlib, LZMA, gzip or bzip2 etc.
zImage: Smaller format, for old kernels
bzImage: Big zImage
Image: vmlinux.bin of embedded devices
Image.gz: zImage or bzImage of embedded devices
.dts (multiple) < > .dtb (1 or more)
Converted using dtc (device tree compiler)
.dtb is appended to zImage / Image.gz i.e. zImage-dtb / Image.gz-dtb (simply concatenate)
zImage-dtb > dtb Can be extracted using split-appended-dtb
Packed as a part of kernel, "--dt" option is not needed when creating boot.img
mkbootimg --kernel *.Image.gz-dtb --ramdisk *.cpio.gz --base . . . --offset . . . --tag-address . . . --cmdline . . .
.dtb is extracted as a part of kernel by unpackbootimg
.dtb < > dtb.img
Converted using mkdtimg
dtb.img is for dtb partition or second stage of boot.img
boot.img is created by using --dt option:
mkbootimg --dt dt.img --kernel *.Image.gz --ramdisk *.cpio.gz --base . . . --offset . . . --tag-address . . . --cmdline . . .
dtb.img is extracted separately by unpackbootimg
Further Reading: Device Tree Overlays and Android Boot and Recovery Images
SYSTEM - ROM / OS
Contains system applications and libraries that have AOSP source code. During normal operation, this partition is mounted read-only; its contents change only during an OTA update or when flashing a new OS. Most ROM's don't allow root level (Admin rights in Windows) access by default. So, "rooting" is required to modify the contents of this partition. This is the actual User Interface we use on our phone i.e. system apps are installed on this partition on /system/app directory. Another important directory is /system/bin which contains executable binaries to perform each and every action by OS in background (as daemons) or by user in shell (bash) scripts or CLI (command line interface). These are native binaries (developed in C / C++ mostly) as opposed to Android apps which are developed in Java. A minimal form of Linux commands is also included in AOSP as toolbox or toybox (or user can add busybox or individual static binaries). /system/lib directory contains native libraries (shared by applications commonly) with .so extensions just like .dll on Windows.
VENDOR
This partition is replaced with a shortcut (symbolic link in fact) to /system/vendor directory. It contains system applications and libraries that do not have source code available on AOSP but added by vendors (OEM's). During normal operation, this partition is mounted read-only; its contents change only during an OTA update. It also contains SoC firmware images i.e. hardware specific libraries and binaries (OpenGL, ISP...).
Proprietary blobs (HALs) usually live in (/system)/vendor as shared libraries (.so files) which are loaded by Android binders when processes call a hardware component. HAL (hardware abstraction layer) is userspace alternative to traditional Linux's system calls for drivers and is a kind of Google's standardization for OEMs/hardware vendors, though being abandoned by mainstream Linux.
PROJECT TREBLE
In an ideal world, there should be a generic AOSP OS and a single kernel for all Android devices, not tied to hardware and vendors. But unfortunately it isn't so because unlike PC world, there is no standardization in mobile world. AOSP is heavily modified on silicon vendor (SoC) as well as phone vendor level. One of the worst outcome of this situation is almost no Long Term Support (LTS). There are delayed or none updates once the consumers have phone, making it vulnerable to security issues and missing new features. Project Treble (starting from Android-8) addresses this issue somewhat by creating a separation between hardware specific code and generic AOSP code.
Previously, phone vendors used to get AOSP code from Google, mixing it with their own cutomizations (UI, apps etc.) and the hardware specific code from SoC vendor. If a minor fix needed to be applied to AOSP code, the whole process had to be repeated because code was intermingled and fixing one thing broke the other. Google resolved this issue by specifying /vendor partition for hardware specific code, /system containing only generic code. Interaction with AOSP code will be through HIDL interfaces, thus making it possible to upgrade the both codes independently. /oem and /odm partitions were added previously for the same purpose.
USERDATA
User applications are installed in different folders under /data. Apps data (user and system) is stored in /data/data. User personal data and some apps data is stored in /data/media. /data/media is also emulated as internal SDCard at /storage/emulated and symlinked at /sdcard. Personalized and apps settings are also stored in this partition. A folder /data/dalvik contains, in simple words, extracted apps to boost loading process. Java bytecode of Android apps is converted to executable code (.odex) by Dalvik Virtual Machine, separate instance of which is launched by zygote (an Android init daemon) for every app.
This partition is not normally touched by the OTA update process. A Factory Reset wipes this partition, normally excluding /data/media i.e. personal data.
When you do a factory reset (AKA: wipe, hard reset, factory wipe, etc.), you are erasing the /data and /cache partitions. Note that a factory reset does NOT put your phone back to its factory state from an OS standpoint. OS upgrades will stay because the OS lives in /system, and that is not touched during a factory reset. So it's not a factory reset. It's a factory DATA reset actually.
RECOVERY
Holds alternate boot partition and the recovery program that lets the device boot into a recovery console for performing advanced recovery and maintenance operations. It contains a second complete Linux system i.e. independent OS, including a user-interface application, kernel and the special recovery binary that reads a package and uses its contents to update i.e. flash or wipe itself or any other partition particularly during OTA updates.
Recovery is also the most commonly used method to flash custom ROM's.
ADB sideload mode through PC is a replacement of flashing files (usually .zip) through Recovery. ADB works when phone is switched on in Recovery (or ROM). ADB/fastboot setup is to be made on PC to use this mode.
CACHE - cached (frequently accessed) data from OS usage and contains the firmware update package downloaded from server during OTA updates. Temporary holding area used by a few applications with the expectation that files can disappear at any time. Major use is by recovery and OTA updates. Recovery last_log is also written to this partition.
6. OTHER PARTITIONS
CUST - also CUSTOM or PRELOAD on some devices, it's used by stock ROM's, holding some preloaded system apps and regional settings which are installed on first use.
MISC - also FOTA on older devices
It's a tiny partition used by recovery to communicate with bootloader store away some information about what it's doing in case the device is restarted while the OTA package is being applied.
It is a boot mode selector used to pass data among various stages of the boot chain (boot into recovery mode, fastboot etc.). e.g. if it is empty (all zero), system boots normally. If it contains recovery mode selector, system boots into recovery mode.
It may also carry some necessarily required information in the form of switches to control hardware or settings related tasks such as CID (Carrier or Region ID) information and USB configurations etc.
PERSIST - contains data which shouldn't be changed after the device is shipped, e.g. DRM related files, sensor reg file (sns.reg) and calibration data of chips; wifi, bluetooth, camera etc.
Some package installers such as OpenGapps also make use of this partition to read configuration file.
EFS, MODEMST1, MODEMST2, FSG, BACKUP
These all are related to IMEI; a unique number used by GSM networks to identify and trace a mobile phone.
EFS may contain hardware info like configuration files, WiFi/BlueTooth MAC’s, IMEI (or ESN for a CDMA based device) etc.
EFS and MODEMST1 may be a single partition on some phones.
FSG (FileSystem Golden copy) and BACKUP are backups of MODEMST1 and MODEMST2 respectively. If MODEMST1 or MODEMST2 are erased (by wrong factory flashing say) and phone notices an invalid partition, FSG and BACKUP will be restored.
MODEMST1 and MODEMST2 also contains modem firmware files.
PARAM - stores a number of parameters, variables and settings of the hardware. It contains info whether MODEMST partitions are backed up or not. Also debug settings, custom ROMs flash count, current stage boot process etc.
OEM - like VENDOR, it incorporates OEM (Original Equipment Manufacturer i.e. hardware manufacturer or Mobile Phone brand) small customization (modifications) to original Android (AOSP) during OTA updates such as customized system properties values etc.
PAD - related to OEM
OTA, FOTA - OTA updates
DDR - Double Data Rate RAM
FSC - Modem FileSystem Cookies
SSD - Secure Software Download, a memory based file system for secure storage, stores some encrypted RSA keys
DEVINFO - device information including: is_unlocked (aboot), is_tampered, is_verified, charger_screen_enabled, display_panel, bootloader_version, radio_version etc. Contents of this partition are displayed by "fastboot oem device-info" command in human readable format. Before loading boot.img or recovery.img, bootloader verifies the locked state from this partition.
CONFIG/FRP/PDB - saves state of Factory Reset Protection (FRP), "Allow bootloader (OEM) unlocking" . (Developer Options), asks already associated account info. This partition is erased/reset if Factory Reset done from Settings.
DEVCFG - used by TZ for upgrades
LKSECAPP - "LK (Little Kernel) Security App", related to RPM, TZ online verification / update
LIMITS - Qualcomm Limits Management Hardware (LMh) driver in SBL writes the data in this partition to use for later reboots
SYSCFG - Qualcomm CPR (Core Power Reduction) Regulator for better performance and power saving of application processor by voltage control
DIP, MDTP - boot verification, use Qualcomm SafeSwitch technology to lock and track theft phones
CMNLIB, KEYMASTER - verified boot
SEC - contains fuse settings, mainly for secure boot (signing bootloaders for chain of trust) and oem setting
KEYSTORE - related to /data Full Disc Encryption (FDE)
MCFG - (Modem Configuration Framework) - on dual SIM devices, loads MBN (modem binary) files depending on SIM/carrier
SPLASH - splash image or boot logo which appears when device boots (at ABOOT stage).
CHGLOGO - charging screen that appears when charger is connected to powered off device.
MSADP, APDP, DPO - related to debug policies
GROW - empty for future expansion
7. FILESYSTEMS
Supported filesystems by your kernel can be viwewd by:
Code:
~# cat /proc/filesystems
Partitions with Mountable Filesystems
Following partitions are mounted during boot process:
system, vendor, odm, userdata (mounted at /data), cache, cust, persist (mounted at /persist or /mnt/vendor/persist), modem (mounted at /firmware or /vendor/firmware_mnt), dsp (mounted at /dsp or /vendor/dsp)
Modem is formatted as vfat while all others are usually ext4 or f2fs on newer devices.
All of these are listed in /fstab.* file which is processes by init. Starting with Android 8.0 (Treble release), fstab.* is moved to /vendor/etc/ and system, vendor and odm entries are included in dtb.
Other partitions don't contain a mountable filesystem. However, we may try to get an idea of the contents by reading smaller partitions e.g.:
Code:
~# cat /dev/block/bootdevice/by-name/config | strings
~# cat /dev/block/bootdevice/by-name/misc | strings
Pseudo / Virtual / in-Memory Filesystems (Kernel space)
These filesystems don't rely on a physical persistent storage but just live in RAM, to provide kernel services interfaces in user space.
rootfs (/) - mounted by kernel before calling init. More details here
sysfs (/sys) - information related to devices, populated by kernel
devpts (/dev/pts) - character device files representing slave side of pseudo terminal pairs
proc (/proc) - information related to all processes, updated as processes are started / killed
tmpfs (/dev) - all device nodes updated from sysfs, accessible from user space
configfs (/config) - intergrated with userspace sdcardfs, controls apps permissions to directories on internal/external sdcard by VOLume Daeomon, a replacement of fusefs
pstore (/sys/fs/pstore) - persistent storage, a replacement of /proc/last_kmsg, saves last kernel console messages on panic / crashes / sudden reboots, solution to volatile nature of pseudo filesystems
cgroup - cgroups manage hardware resources allocation to processes as per load
selinuxfs (/sys/fs/selinux) - implementation of Security-Enahanced Linux, a mandatory access controls (MAC) to manage file permissions, better than traditional Discretionary Access Control (DAC) mechanism (Read-Write-eXecute) of Linux
debugfs (/sys/kernel/debug) - to monitor and debug kernel space implementations from user space
tracefs (/sys/kernel/debug/tracing) - debugfs with better security
functionfs (/dev/usb-ffs/adb) - integrated with configfs, manages USB gadgets, ADB is implemented through functionfs on Android
FILESYSTEM TREE MOUNTED BY INIT: ANDROID vs. LINUX
8. Factory Firmware and Flashable ROMs:
When you flash a custom ROM, that ROM typically includes a kernel and an OS. That means the /boot and /system partitions will be modified at a minimum. Some ROMs require a clean install, so a format of the /data and /cache partitions is sometimes built into the .zip that you flash. This is essentially doing a Factory Reset.
Read here to know more about flashing partitions.
Factory Firmware contains original iamge files of almsot all important partitions. It's provided by OEM's, usually as a package which also incude a flasher software for PC. Or a general flasher software may be uses such as QFIL.
ROM Development
A ROM developer downloads AOSP source code from Google while device tree, driver binaries and kernel source code is provided by (ODM's through) OEM's, if they are generous enough. OEM's manufacture and sell devices themselves while ODM's sell to white-labelers who brand them under their own names. Original Android kernel tree is provided by Google which in turn is taken from Linux and then modified by Google for Android-specific needs.
RELATED:
An Introduction to Android Firmware

First off, don't need be like your never be a dev, lol you never know. Secondly it's a good share. Appreciated

Drivers Partition
What are partitions responsible on drivers like sound and camera,
I restored ROM using TWRP but now, Sound and Camera don't work,
any help?

saprey said:
What are partitions responsible on drivers like sound and camera,
I restored ROM using TWRP but now, Sound and Camera don't work,
any help?
Click to expand...
Click to collapse
Camera and sound are related to your rom i.e. system partition. Do factory data reset or clean install rom

Thanks, but why is my phone talking about a primary partition and a secondary partition?
Tia,
A real newbie

TommyWhite said:
Thanks, but why is my phone talking about a primary partition and a secondary partition?
Tia,
A real newbie
Click to expand...
Click to collapse
At what point talking about primary / secondary partitions? Are you creating new partitions or using some tool / app to view partitions?

Oh, I misunderstood.
It was about public storages (so whats accessible without root, right??).
It said
Public storage (primaire): /storage/emulated/0
Public storage (secondaire): /storage/94F1-34D8 (I didnt realise that was my sd card ...)
RootFs: /
System: /system
Like a said 'a real newbie'

TommyWhite said:
Oh, I misunderstood.
It was about public storages (so whats accessible without root, right??).
It said
Public storage (primaire): /storage/emulated/0
Public storage (secondaire): /storage/94F1-34D8 (I didnt realise that was my sd card ...)
RootFs: /
System: /system
Like a said 'a real newbie'
Click to expand...
Click to collapse
Something like this attachment?

mirfatif said:
Something like this attachment?
Click to expand...
Click to collapse
yes, sorry for the very late response.

While on some devices there is no bootloader partition at all and bootloader(s) resides on SoC.
Click to expand...
Click to collapse
Great post btw! With the bootloader section mentioning like the above, I have a question: I'm having a device with Snapdragon 810 SoC and wasn't able to find the bootloader partition (or at least I didn't know it has because I couldn't get it to boot into that mode). So does that mean the bootloader is on the SoC? How do I figure it out if it exists on the chip?

Hi @mirfatif , what a post! Hats off to you. By the way, where does the blobs/ HALs go when we flash a new ROM zip?

argon9898 said:
Great post btw! With the bootloader section mentioning like the above, I have a question: I'm having a device with Snapdragon 810 SoC and wasn't able to find the bootloader partition (or at least I didn't know it has because I couldn't get it to boot into that mode). So does that mean the bootloader is on the SoC? How do I figure it out if it exists on the chip?
Click to expand...
Click to collapse
Booting in bootloader (or it's equivalent; like fastboot) mode is dependent on the phone manufacturer. Though most of the hardware manufacturers allow users to access bootloader for repair/maintenance or modified boot chain, some may restrict this for Digital Rights Management or to gain forced customer loyalty , irrespective of where bootloader resides. On most phones it's a partition. You may check your partition table to know about all partitions.

azoksky said:
Hi @mirfatif , what a post! Hats off to you. By the way, where does the blobs/ HALs go when we flash a new ROM zip?
Click to expand...
Click to collapse
Thanks for mentioning. I have added this to my post. By "blolbs" you mean DTB or hardware drivers? Well AFAIK, the blobs are included in every ROM where "ROM" is boot.img and system.img at least.
A ROM developer downloads AOSP source code from Google while device tree (map of hardware components), driver binaries and kernel source code is provided by (ODM's through) OEM's, if they are generous enough. OEM's manufacture and sell devices themselves while ODM's sell to white-labelers who brand them under their own names. Original Android kernel tree is provided by Google which in turn is taken from Linux and then modified by Google for Android-specific needs. DTB and drivers are baked with kernel source in boot.img though DTB may live on a separate dtb partition as specified by AOSP (and was the proposed solution for ARM based embedded Linux devices before Android's birth) but I don't think that is widely practiced. DTB is loaded by bootloader at boot time and passed to kernel so that it can discover hardware and create node points accordingly. Proprietary blobs (HALs) usually live in (/system)/vendor as shared libraries (.so files) which are loaded by Android binders when processes call a hardware component. HAL is userspace alternative to traditional Linux's system calls for drivers and is a kind of Google's standardization for OEMs/hardware vendors.
Click to expand...
Click to collapse

Hello everyone. I tell you that one day flashing my oneplus 5 lost the wifi. The MAC address shows me the typical 02: 00: 00: 00: 00: 00 address. The way to fix it is updating the Oreo but I could never do it, it is always in bootloop, I read all the forums and there is no case, do what I always do the same. It happens in many oneplus 5. So I forgot to fix it in that way. The other thing I saw is hundreds of forums with that problem but I could not fix it either, I've been doing it for three months now. What I am trying now is to erase all the partitions except recovery or bootloader but the phone does not start anymore. What I want is to delete all the partitions associated with wifi, delete modem1, modem2, persist, fsg but nothing, I just managed to lose the imei that does not matter to me because I have back up of the efs folder and even the qcn file of the phone. I know it's a lot of work but if someone tells me that they control each partition, I could erase it, load everything from scratch and that's it. Would someone give me a hand so I can fix that damn wifi on the phone ?. Thank you.
--------------------------------------------------------------------------------------------------------------------------------------
drwxr-xr-x 2 root root 1440 1970-05-03 14:23 .
drwxr-xr-x 4 root root 1600 1970-05-03 14:23 ..
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 LOGO -> /dev/block/sde18
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 abl -> /dev/block/sde16
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 ablbak -> /dev/block/sde17
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 apdp -> /dev/block/sde31
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 bluetooth -> /dev/block/sde24
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 boot -> /dev/block/sde19
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 boot_aging -> /dev/block/sde20
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 cache -> /dev/block/sda3
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 cdt -> /dev/block/sdd2
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib -> /dev/block/sde27
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib64 -> /dev/block/sde29
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlib64bak -> /dev/block/sde30
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 cmnlibbak -> /dev/block/sde28
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 config -> /dev/block/sda12
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 ddr -> /dev/block/sdd3
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 devcfg -> /dev/block/sde39
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 devinfo -> /dev/block/sde23
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dip -> /dev/block/sde14
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dpo -> /dev/block/sde33
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 dsp -> /dev/block/sde11
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 frp -> /dev/block/sda6
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 fsc -> /dev/block/sdf4
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 fsg -> /dev/block/sdf3
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4g9n4 -> /dev/block/sde45
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4j1ed -> /dev/block/sde43
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_4t0n8 -> /dev/block/sde46
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 fw_8v1ee -> /dev/block/sde44
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 hyp -> /dev/block/sde5
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 hypbak -> /dev/block/sde6
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 keymaster -> /dev/block/sde25
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 keymasterbak -> /dev/block/sde26
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 keystore -> /dev/block/sda5
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 limits -> /dev/block/sde35
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 logdump -> /dev/block/sde40
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 logfs -> /dev/block/sde37
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 md5 -> /dev/block/sdf5
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtp -> /dev/block/sde15
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtpsecapp -> /dev/block/sde12
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 mdtpsecappbak -> /dev/block/sde13
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 minidump -> /dev/block/sde47
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 misc -> /dev/block/sda4
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 modem -> /dev/block/sde10
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 modemst1 -> /dev/block/sdf1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 modemst2 -> /dev/block/sdf2
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 msadp -> /dev/block/sde32
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 oem_dycnvbk -> /dev/block/sda7
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 oem_stanvbk -> /dev/block/sda8
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 param -> /dev/block/sda9
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 persist -> /dev/block/sda2
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 pmic -> /dev/block/sde8
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 pmicbak -> /dev/block/sde9
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 recovery -> /dev/block/sde22
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 reserve -> /dev/block/sdd1
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 reserve1 -> /dev/block/sda10
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 reserve2 -> /dev/block/sda11
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 rpm -> /dev/block/sde1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 rpmbak -> /dev/block/sde2
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 sec -> /dev/block/sde7
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 splash -> /dev/block/sde34
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 ssd -> /dev/block/sda1
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 sti -> /dev/block/sde38
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 storsec -> /dev/block/sde41
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 storsecbak -> /dev/block/sde42
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 system -> /dev/block/sde21
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 toolsfv -> /dev/block/sde36
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 tz -> /dev/block/sde3
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 tzbak -> /dev/block/sde4
lrwxrwxrwx 1 root root 16 1970-05-03 14:23 userdata -> /dev/block/sda13
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 xbl -> /dev/block/sdb1
lrwxrwxrwx 1 root root 15 1970-05-03 14:23 xblbak -> /dev/block/sdc1

thank you
This is one of the best posts that I've ever read. I'm a hobbyist and reverse engineer learn. My primary phones are Samsung S 6 7 and 8 and I've soft bricked phones them more times than I can count (but recovered) justifying it as a learning experience. Sort of like putting your hand in the fire several times and calling it a learning experience. your post opens up more questions which are great. I root all my phones and I have a fear of new security patches disguised as updates disabling what methods work last week so to speak
So if I understand finally there is a section in bootloaders which is the first bootloader that is static yet upgradable but not downgradable as you referred to like the BIOS on PCs which acts as a verification process so you can't flash downgradable security patches. Much like I've encountered with partcyborg great work on rooting the S8 snapdragon however once you upgraded to the bootloader 2 you couldn't go back to the bootloader one. This is in reference to the build, not the partition.
If someone does reply, I'd like to know can you mod a certain file and Odin in the bootloader section when flashing an update to ensure that you stay at a certain bootloader level while the other files such as AP CP and CSC remain intact from the sam mobile stock firmware.(which I assume the term combo firmware file originates)
My most recent encounters are the device and binary are not the same which I attribute to this problem.
In theory from what I understand the phone has a section that is not Factory resettable which is the NAND that contains read-only but system upgrade information? However, it can be modified by a power Superuser rooted? This obviously risking hard bricking a phone
When upgrading firmware specifically the bootloader file in Odin what file(s) {bin} are essential to the new modification patches and can those files be substituted?
Any comment is considered very helpful. Odin itself is coming out with different versions for structures (prince cosmey) for example.
I explore the system file structure often wondering what I could change or alter as simple as a 0 or 1 or a true or a false to enable or disable my ability to access what I feel I need to access.
I could buy the z3x Samprotools but it defeats my intentions to learn the details.
If you do have a suggestion on a GUI Windows-based tool it would be great. Don't know Linux just as a footnote
Once again what a great post and definition of the different sections of terminology it's just enough to educate me and confuse me at the same time keep doing what you're doing. Any tricks or tips will be very appreciated.

partitions
What are partitions responsible on drivers like sound and camera,

Curious Q.!
what about these two ?
Code:
rpm -> /dev/block/mmcblk0p2
rpmbak -> /dev/block/mmcblk0p11
my phone is MOTO-G5-PLUS (potter)
whole partition table is here:
Code:
←7←[r←[999;999H←[6n←8potter:/ # ls -l /dev/block/bootdevice/by-name
total 0
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 DDR -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 aboot -> /dev/block/mmcblk0p5
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 abootbak -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 apdp -> /dev/block/mmcblk0p45
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 boot -> /dev/block/mmcblk0p37
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cache -> /dev/block/mmcblk0p52
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 carrier -> /dev/block/mmcblk0p34
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cid -> /dev/block/mmcblk0p32
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 cmnlib -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 cmnlib64 -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cmnlib64bak -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 cmnlibbak -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 devcfg -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 devcfgbak -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dip -> /dev/block/mmcblk0p42
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dpo -> /dev/block/mmcblk0p47
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 dsp -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 frp -> /dev/block/mmcblk0p31
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 fsc -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 fsg -> /dev/block/mmcblk0p29
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 hw -> /dev/block/mmcblk0p50
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 keymaster -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 keymasterbak -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 kpan -> /dev/block/mmcblk0p36
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 limits -> /dev/block/mmcblk0p40
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 logo -> /dev/block/mmcblk0p33
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 logs -> /dev/block/mmcblk0p44
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 metadata -> /dev/block/mmcblk0p35
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 misc -> /dev/block/mmcblk0p39
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modem -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modemst1 -> /dev/block/mmcblk0p27
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 modemst2 -> /dev/block/mmcblk0p28
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 mota -> /dev/block/mmcblk0p41
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 msadp -> /dev/block/mmcblk0p46
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 oem -> /dev/block/mmcblk0p51
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 padA -> /dev/block/mmcblk0p48
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 persist -> /dev/block/mmcblk0p30
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 prov -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 provbak -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 recovery -> /dev/block/mmcblk0p38
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 rpm -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 rpmbak -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 sbl1 -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sbl1bak -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sec -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 sp -> /dev/block/mmcblk0p49
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 ssd -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 syscfg -> /dev/block/mmcblk0p43
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 system -> /dev/block/mmcblk0p53
lrwxrwxrwx 1 root root 20 1970-08-28 23:29 tz -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 tzbak -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 userdata -> /dev/block/mmcblk0p54
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 utags -> /dev/block/mmcblk0p25
lrwxrwxrwx 1 root root 21 1970-08-28 23:29 utagsBackup -> /dev/block/mmcblk0p26
potter:/ #

GEEKOFIA said:
what about these two ?
Code:
rpm -> /dev/block/mmcblk0p2
rpmbak -> /dev/block/mmcblk0p11
my phone is MOTO-G5-PLUS (potter)
Click to expand...
Click to collapse
RPM (Resource/Power Management) or Primary BootLoader (PBL); controls power to radio, modem etc.

koler386 said:
What are partitions responsible on drivers like sound and camera,
Click to expand...
Click to collapse
Kernel and system

mirfatif said:
what about these two ?
RPM (Resource/Power Management) or Primary BootLoader (PBL); controls power to radio, modem etc.
Click to expand...
Click to collapse
I got a script from a xda thread in which OP mentioned that this script is for wiping dalvik/ART cache.
Before flashing it i decided to analyse it,what i found that it was erasing my RPM partition on mmcblk0p2.
Is it really for dalvik cache ?

[ADB | FASTBOOT | LINUX COMMANDS] BootLoader, Kernel, Recovery, ROM, Root, Backup

NOTE:
I'm not a developer or something even near to that. All information provided here is copied from different sources and according to the best of my knowledge.
I have tested this on different devices using Windows 8.1 & 10. I'll not be responsible for any harm to you or your device. It works perfectly for me. You may try it on your own risk.
Save / backup your data before performing any actions.
WHAT IS ADB/FASTBOOT
ADB and fastboot are different protocols used through PC to perform different command line operations on device through USB in ROM/Recovery and bootloader mode respectively.
Android Debugging Bridge is basically used by developers to identify and fix bugs in OS (ROM). ADB works in ROM and recovery both.
Fastboot works in bootloader mode even when phone is not switched on in Recovery or ROM or even if Android isn't installed on phone. In later case, bootloader can be accessed by certain button combination while powering on device; usually Power + Vol. Down. See here the booting process of Android devices.
Fastboot/ADB setup is to be made on PC to use this mode. ADB mode has more flexibility than fastboot as it supports more types of flashable files to be flashed. ADB also supports backing up Apps and Data. ADB/fastboot commands can be used to flash recovery and boot images. It can also flash ROMs and mods like rooting solutions and XPOSED by booting into recovery. And above all, it is the only way to unlock bootloader without which the device functionality is too limited. Read here why we need to unlock bootloader.
In bootloader mode, usually boot logo or fastboot logo appears on device screen.
SETUP
Enable USB Debugging in Settings > Developer Options. If not available, Dev. Options can be accessed by tapping 5 (or 7) times Build Number in Settings > About Phone.
Allow ADB root access in Dev. Options or SuperSU. Some commands need root.
Allow data transfer over ADB when prompted on device screen. Otherwise you might get errors like device unauthorized etc. So keep screen unlocked at first connect.
Disable MTP, PTP, UMS etc. from USB computer connection on device to avoid any interruptions.
Install Android SDK or simply install 15 Seconds ADB Setup 1.4.2. It works up to Android Lollipop (AOSP 5). Credits to Snoop05
Windows 8.1 users who got error installing this setup should first install Windows Update KB2917929.
You will have to navigate to adb folder each time you start cmd. Or setup adb to work globally. On your PC, go to System Properties > Advanced System Settings > Environment Variables. Click on New (User Variables). Variables Name: ADB ( Or anything you want). Variables Value: ;C:\adb (if installed 15 seconds setup) or ;C:\SDK\paltform-tools.
Install ADB USB Drivers for your Android Device. To do this automatically, download and run ADB Driver Installer. Connect device through USB cable and install drivers.
NOTE: Spaces in file paths don't work in adb commands. Non-English characters and languages don't work either. Also the commands are case-sensitive.
There is a long list of adb/fastboot commands to perform numerous operations. Here are a few of those being listed keeping in view certain tasks:
COMMON COMMANDS
On PC run Command Prompt as Administrator.
To check connected devices when ROM is running on phone:
Code:
adb devices
To boot into bootloader mode:
Code:
adb reboot bootloader
To check connected devices when in bootloader mode:
Code:
fastboot devices
To boot into ROM:
Code:
fastboot reboot
To boot into recovery:
Code:
fastboot reboot recovery
There are some common Linux commands which can be used in combination with these commands to perform certain operation. However, ADB | FASTBOOT is not necessarily required for these Linux commands. These can be run directly from Terminal Emulator in ROM or Custom Recovery. Some of them are given below.
UNLOCK BOOTLOADER
NOTE: Some newer devices don't allow unlocking of bootloader directly to ensure more security. Instead an official method is provided to unlock BL using PC.
Read here to know about the risks of BL unlocking.
To check the bootloader status:
Code:
fastboot oem device-info
“True” on unlocked status.
If "false", run the following to unlock:
Code:
fastboot oem unlock
However these are OEM specific commands and may differ or not work on all devices. Fastboot's own commands (which are part of AOSP source and) that can unlock bootloader allowing flashing of partitions:
Code:
fastboot flashing unlock
Allow flashing of bootloader related partitions too:
Code:
fastboot flashing unlock_critical
FORMAT DATA PARTITION
This will erase your data.
Code:
fastboot format:ext4 userdata
It can be performed on other flash partitions as well. A general syntax is 'fastboot format:FS PARTITION'
FLASH RECOVERY
Download recovery.img (specific for your device) to adb folder.
To test the recovery without permanently flashing, run the following:
Code:
fastboot boot recovery.img
On next reboot, recovery will be overwritten by previous recovery.
Or to permanently flash recovery, run:
Code:
fastboot flash recovery recovery.img
fastboot reboot recovery
Stock ROM's often tend to replace custom recovery with stock one on first reboot. That's why, booting into recovery is recommended before booting into ROM.
FLASH KERNEL
Download boot.img (specific for your device) to adb folder and run following:
Code:
fastboot flash boot boot.img
FLASH ROM
Download ROM.zip (for your device) created for fastboot i.e. with android-info.txt and android-product.txt.
To wipe your device and then to flash .zip:
Code:
fastboot -w
fastboot update </path/to/your/Rom.zip>
PASSING FASTBOOT ARGUMENTS
Fastboot supports passing options. For example, while booting a modified kernel image with FramBuffer Console support, console device and its font can be provided as option:
Code:
fastboot boot -c "console=tty0,115200 fbcon=font:VGA8x8" boot-fbcon.img
GAIN ROOT (Not recommended method. Better flash directly through custom recovery).
Root is required to modify the contents of /system. You can read here further.
Download (flashable) supersu.zip and custom or modified recovery.img (having support to flash .zip files) to adb folder and run the following:
Code:
fastboot boot recovery.img
Now once you are in recovery, adb will work instead of fastboot.
To copy files from PC to device and then to extract files, run the following:
Code:
adb push supersu.zip /tmp
adb shell /sbin/recovery --update_package=/tmp/supersu.zip
BACKUP / RESTORE APPS & DATA (From/To PC)
To backup and restore all apps and their data:
Code:
adb backup -apk -shared -all -system -f C:\backup.ab
adb restore C:\backup.ab
Read here for details.
COPY WHOLE PARTITION IMAGE (within device)
This method can be used to backup whole device e.g. to backup /data/ including /data/media/ i.e. Internal SD Card which isn't backed up by custom recovery (TWRP). Or you can get any partition image for development purpose. This method retains complete directory structure as well as file permissions, attributes and contexts.
To jump from windows command prompt to android device shell:
Code:
adb shell
These commands can also be given from Recovery Terminal instead of ADB.
To get SuperUser access (in ROM):
Code:
su
To list all available partitions or mount points on device:
Code:
cat /proc/partitions
Or go to "/dev/block/platform/" folder on device. Search for the folder having folder "by-name" inside it. It's msm_sdcc.1 (on Nokia X2). Run the following:
Code:
ls -al /dev/block/platform/*/by-name
Or simply use DiskInfo app to get partition name you want to copy. Say you want to copy /data (userdata) partition. On Nokia X2DS, it is mmcblk0p25.
To confirm:
Code:
readlink /dev/block/bootdevice/by-name/userdata
Run the following to copy partition:
Code:
dd if=/dev/block/mmcblk0p25 of=/sdcard/data.img
or
Code:
cat /dev/block/mmcblk0p25 > /sdcard/data.img
or
Code:
dd if=/dev/block/bootdevice/by-name/userdata of=/sdcard/data.img
data.img will be copied to your SD card.
It also works inversely (restore):
Code:
dd if=/sdcard/data.img of=/dev/block/mmcblk0p25
data.img from your SD card will be written to device.
Similarly you can copy system.img, boot.img or any other partition. However boot.img and other partitions may not be copied in ROM but in recovery mode only. So better use recovery for dd except if you're​ going to dd recovery partition itself. You can read here more about android partitions.
COPY WHOLE FOLDER (within device)
This method can be used to backup folders like /data/media/ which isn't backed up by custom recovery (TWRP).
To jump from windows command prompt to android device shell:
Code:
adb shell
These commands can also be given from Recovery Terminal.
To get SuperUser access (in ROM):
Code:
su
To copy from Internal Memory to SD Card:
Code:
cp -a /data/media/0/. /external_sd/internal_backup/
Or if you don't have SU permission:
Code:
cp -a /external_sd/. /sdcard/
To copy from SD Card to Internal Memory:
Code:
cp -a /external_sd/internal_backup/. /data/media/0/
However, if you are copying to an SD card with FAT32 file system, android permissions of files won't be retained and you would have to fix permissions yourself. In this case, you can use tar command to create archive of files along with their attributes ( permissions: mode & ownership + time-stamps) and security contexts etc. But FAT32 FS has also a limitations of 4GB maximum file size. You may use "split" command along with "tar" to split the archive in smaller blocks. Or use exFat or Ext4 filesystem for larger file support. Ext4 would give higher writing speed in Android but not supported in Windows i.e. SD card can't be mounted in Windows. MTP however works.
To jump from windows command prompt to android device shell:
Code:
adb shell
To get SuperUser access (in ROM):
Code:
su
To copy from Internal Memory to SD Card:
Code:
tar cvpf /external_sd/internal_backup/media.tar /data/media/0/
To extract from SD Card to Internal Memory (along with path):
Code:
tar -xvf /external_sd/internal_backup/media.tar
To extract from SD Card to some other location, use "-C":
Code:
tar -xvf /external_sd/internal_backup/media.tar -C /data/media/0/extracted_archive/
COPY WHOLE FOLDER (From/To PC)
This method can be used to backup folders like /data/media/ which isn't backed up by custom recovery (TWRP).
To copy from PC to device:
Code:
adb push \path\to\folder\on\PC\ /path/to/folder/on/device/
To copy from device to PC:
Code:
adb pull /path/to/folder/on/device/ \path\to\folder\on\PC\
After copying from PC to device's Internal Memory (/data/media/), you might get Permission Denied error e.g. apps can't write or even read from Internal Memory. It's because Android (Linux) and Windows have different file permissions system. To FIX PERMISSIONS, boot into recovery and run following commands:
(Credits to xak944 )
Code:
adb shell
To take ownership of whole "media" directory:
Code:
chown -R media_rw:media_rw /data/media/
To fix permissions of directories:
Code:
find /data/media/ -type d -exec chmod 775 '{}' ';'
To fix permissions of files:
Code:
find /data/media/ -type f -exec chmod 664 '{}' ';'

HELP PLEASE! Fastboot is acting funny for first time, Huawei Honor 6X
Okay, so I have a Huawei Honor 6X. This device has been rooted and and had custom roms of sorts flashed fine, and bootloader has been unlocked several times only to later have me flash the stock firmware back thus locking bootloader, etc. So this isn't my first rodeo. However, have never seen this. Basically, going from the Stock ROM, I had enabled USB DEBUGGING and approved the little allow always toast popup. Then using my command line in linux, I issued
Code:
adb devices
.... saw it was seeing the device. Then issued
Code:
adb reboot bootloader
. Fine. I see
PHONE locked FRP Unlocked
Click to expand...
Click to collapse
on my fastboot screen. So I know my bootloader is locked. Also, I had previously gotten my unlock code from Huawei as well. But please see the attached image attached belowe here for the real picture of things because once in my fastboot mode, issuing
Code:
fastboot devices
shows my Device ID. However when trying to issue the
Code:
fastboot oem unlock bootloader
code, it acts then like it can find the device or either the devices doesn't find the command? It just says waiting for devices as you can see... wtf? This is all at the same instance. Please see attached and any help, suggestions, etc. are appreciated!

i also have problem trying to issue some fastboot command
bootloader have been unlock
except fastboot reboot command, the rest of fastboot cannot be execute
the error were
...
FAILED (remote: Command not allowed)
finished. total time: 0.00s
can i issue fastboot command from twrp terminal
i want to enable charge reboot
on fastboot
fastboot oem off-mode-charge disable
how to issue comand from within twrp terminal?

ahhl said:
i also have problem trying to issue some fastboot command
bootloader have been unlock
except fastboot reboot command, the rest of fastboot cannot be execute
the error were
...
FAILED (remote: Command not allowed)
finished. total time: 0.00s
can i issue fastboot command from twrp terminal
i want to enable charge reboot
on fastboot
fastboot oem off-mode-charge disable
how to issue comand from within twrp terminal?
Click to expand...
Click to collapse
All vendors don't allow all fastboot commands. Despite of unlocked bootloader, some commands might not work or work differently on certain devices.
No you can't control fastboot from TWRP. Bootloader / fastboot come at lower level in boot process. Recovery itself is loaded by bootloader. We can't control fastboot from recovery. However a few adb commands work in TWRP as well.

Hi guys!
BACKUP / RESTORE APPS & DATA (From/To PC)
Is it still possible on Android Nougat/Oreo on last Samsung devices?
Thanks!
Sent from my SM-G950F using Tapatalk

PIRATA! said:
Hi guys!
BACKUP / RESTORE APPS & DATA (From/To PC)
Is it still possible on Android Nougat/Oreo on last Samsung devices?
Thanks!
Click to expand...
Click to collapse
It's related to adb which is same on Nougat/Oreo, I think. So it should work similarly.

ahhl said:
i also have problem trying to issue some fastboot command
bootloader have been unlock
except fastboot reboot command, the rest of fastboot cannot be execute
the error were
Click to expand...
Click to collapse
FRP locked?
---------- Post added at 11:43 AM ---------- Previous post was at 10:50 AM ----------
Very nice guide with detailed information.

Thanks

struggling with fastboot
Fastboot doesn't want to write out my unlock file???
I'm trying to unlock the bootloader on an old HTC wildfire S, and have followed all the steps listed on the official htcdev.com site to get the unlock token from HTC, but when I run
./fastboot flash unlocktoken Unlock_code.bin
I get
target didn't report max-download-size
sending 'unlocktoken' (0 KB)
but then it just sits these forever
all other fastboot commands seem to work fine, just the flash unlock thats not being written
I can find lots of posts from people with same problem, but no answers that get me any nearer.
enviro here is debian with latest android dev installed from the standard repositories, and fastboot 1:7.0.0+r33-1
phone is wildfire s
Marvel pvt ship s-on rl
hboot 1.09.0099
microp 0451
radio 7.57.39.10m
feb 8 2012,10:29.31
branded for the uk three network.
any help would be appreciated!
chris w

Try this with that Huawei. This should.unlock the oem
Go into settings . Go all the way to the bottom to about phone, then go find build number press at a bunch of times rapidly that'll take you into developer mode. Once in developer mode back into the main menu of settings scroll down to developer options. You should find OEM bootloader unlock about three or four down in that section click unlock and you should be good to go. Good luck oh and I didn't have to back mine up first so you should be good to go.....
theburrus1 said:
Okay, so I have a Huawei Honor 6X. This device has been rooted and and had custom roms of sorts flashed fine, and bootloader has been unlocked several times only to later have me flash the stock firmware back thus locking bootloader, etc. So this isn't my first rodeo. However, have never seen this. Basically, going from the Stock ROM, I had enabled USB DEBUGGING and approved the little allow always toast popup. Then using my command line in linux, I issued
Code:
adb devices
.... saw it was seeing the device. Then issued
Code:
adb reboot bootloader
. Fine. I see on my fastboot screen. So I know my bootloader is locked. Also, I had previously gotten my unlock code from Huawei as well. But please see the attached image attached belowe here for the real picture of things because once in my fastboot mode, issuing
Code:
fastboot devices
shows my Device ID. However when trying to issue the
Code:
fastboot oem unlock bootloader
code, it acts then like it can find the device or either the devices doesn't find the command? It just says waiting for devices as you can see... wtf? This is all at the same instance. Please see attached and any help, suggestions, etc. are appreciated!
Click to expand...
Click to collapse

unknown command while flashing through fastboot
i keep getting unknown command while trying to flash recovery images or firmware, please help me

whitehat15 said:
i keep getting unknown command while trying to flash recovery images or firmware, please help me
Click to expand...
Click to collapse
What commands are you trying and which phone/android version as command has changed since oreo

@mirfatif Do you know what the fastboot update command is doing under the hood? It's obviously flashing the images to the correct partitions but how does it know what image goes where? fastboot flash boot boot.img makes sense to me but running a fastboot command on a bunch of image files in a zip file doesn't. Thanks.

jd1639 said:
@mirfatif Do you know what the fastboot update command is doing under the hood? It's obviously flashing the images to the correct partitions but how does it know what image goes where? fastboot flash boot boot.img makes sense to me but running a fastboot command on a bunch of image files in a zip file doesn't. Thanks.
Click to expand...
Click to collapse
Can you give me example of such zip file? Fastboot protocol is provided by application bootloader (aboot) which knows very well the exact boundaries of partitions on device. When flashing images, we are telling fastboot what image it is or where it is to be written.

mirfatif said:
Can you give me example of such zip file? Fastboot protocol is provided by application bootloader (aboot) which knows very well the exact boundaries of partitions on device. When flashing images, we are telling fastboot what image it is or where it is to be written.
Click to expand...
Click to collapse
The Nexus and pixel phones have had a batch file in the factory image zip file that runs fastboot flashes for the bootloader and radio and then runs a command fastboot update xyz.zip. The xyz.zip is another zip file within the factory image zip. This zip contains all the other image files, i.e. system, modem, etc. Also, I have a pixel 3 and there is no aboot partition. The kernel and recovery images are also both contained in the boot.img. These phones are getting more difficult to deal with.
These are the partitions:
127|:/dev/block/bootdevice/by-name # ls -all
total 0
drwxr-xr-x 2 root root 1440 1970-05-03 01:39:00.159934065 -0500 .
drwxr-xr-x 3 root root 1580 1970-05-03 01:39:00.159934065 -0500 ..
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.146602064 -0500 ALIGN_TO_128K_1 -> /dev/block/sdd1
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.143269064 -0500 ALIGN_TO_128K_2 -> /dev/block/sdf1
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.139936063 -0500 ImageFv -> /dev/block/sdf14
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.149935064 -0500 abl_a -> /dev/block/sde4
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.153268065 -0500 abl_b -> /dev/block/sde16
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.153268065 -0500 aop_a -> /dev/block/sde1
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.153268065 -0500 aop_b -> /dev/block/sde13
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.143269064 -0500 apdp_a -> /dev/block/sda15
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.156601065 -0500 apdp_b -> /dev/block/sda16
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.159934065 -0500 boot_a -> /dev/block/sda11
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.143269064 -0500 boot_b -> /dev/block/sda12
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.146602064 -0500 cdt -> /dev/block/sdd2
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.153268065 -0500 cmnlib64_a -> /dev/block/sde7
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.139936063 -0500 cmnlib64_b -> /dev/block/sde19
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.153268065 -0500 cmnlib_a -> /dev/block/sde6
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.149935064 -0500 cmnlib_b -> /dev/block/sde18
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.146602064 -0500 ddr -> /dev/block/sdd3
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 devcfg_a -> /dev/block/sde8
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.149935064 -0500 devcfg_b -> /dev/block/sde20
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 devinfo -> /dev/block/sdf7
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 dip -> /dev/block/sdf8
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.143269064 -0500 dtbo_a -> /dev/block/sde11
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.149935064 -0500 dtbo_b -> /dev/block/sde23
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.153268065 -0500 frp -> /dev/block/sda4
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 fsc -> /dev/block/sdf6
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.146602064 -0500 fsg -> /dev/block/sdf5
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.149935064 -0500 hyp_a -> /dev/block/sde3
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.149935064 -0500 hyp_b -> /dev/block/sde15
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 keymaster_a -> /dev/block/sde5
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.139936063 -0500 keymaster_b -> /dev/block/sde17
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.156601065 -0500 keystore -> /dev/block/sda3
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.159934065 -0500 klog -> /dev/block/sda19
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.146602064 -0500 limits -> /dev/block/sdf10
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.143269064 -0500 logfs -> /dev/block/sdf12
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.156601065 -0500 metadata -> /dev/block/sda20
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.153268065 -0500 misc -> /dev/block/sda2
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.156601065 -0500 modem_a -> /dev/block/sda13
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.156601065 -0500 modem_b -> /dev/block/sda14
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 modemcal -> /dev/block/sdd4
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.143269064 -0500 modemst1 -> /dev/block/sdf3
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.146602064 -0500 modemst2 -> /dev/block/sdf4
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.143269064 -0500 msadp_a -> /dev/block/sda17
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.149935064 -0500 msadp_b -> /dev/block/sda18
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.146602064 -0500 persist -> /dev/block/sdf2
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.143269064 -0500 product_a -> /dev/block/sda7
lrwxrwxrwx 1 root root** 15 1970-05-03 01:38:59.939956043 -0500 product_b -> /dev/block/sda8
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.149935064 -0500 qupfw_a -> /dev/block/sde9
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.143269064 -0500 qupfw_b -> /dev/block/sde21
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 sec -> /dev/block/sdd6
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.139936063 -0500 splash -> /dev/block/sdf15
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.136603063 -0500 spunvm -> /dev/block/sdf9
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.143269064 -0500 ssd -> /dev/block/sda1
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.143269064 -0500 sti -> /dev/block/sdf13
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.146602064 -0500 storsec_a -> /dev/block/sde12
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.149935064 -0500 storsec_b -> /dev/block/sde24
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.153268065 -0500 system_a -> /dev/block/sda5
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.159934065 -0500 system_b -> /dev/block/sda6
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.146602064 -0500 toolsfv -> /dev/block/sdf11
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 tz_a -> /dev/block/sde2
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.139936063 -0500 tz_b -> /dev/block/sde14
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.149935064 -0500 uefivar -> /dev/block/sdd5
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.153268065 -0500 userdata -> /dev/block/sda21
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.153268065 -0500 vbmeta_a -> /dev/block/sde10
lrwxrwxrwx 1 root root** 16 1970-05-03 01:39:00.139936063 -0500 vbmeta_b -> /dev/block/sde22
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.143269064 -0500 vendor_a -> /dev/block/sda9
lrwxrwxrwx 1 root root** 16 1970-05-03 01:38:59.939956043 -0500 vendor_b -> /dev/block/sda10
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.139936063 -0500 xbl_a -> /dev/block/sdb1
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.149935064 -0500 xbl_b -> /dev/block/sdc1
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.146602064 -0500 xbl_config_a -> /dev/block/sdb2
lrwxrwxrwx 1 root root** 15 1970-05-03 01:39:00.149935064 -0500 xbl_config_b -> /dev/block/s
Sent from my [device_name] using XDA-Developers Legacy app

jd1639 said:
The xyz.zip is another zip file within the factory image zip. This zip contains all the other image files, i.e. system, modem, etc.
Click to expand...
Click to collapse
And it also contains rawprogram_unsparse.xml or something similar with all partitions listed?
Also, I have a pixel 3 and there is no aboot partition.
Click to expand...
Click to collapse
I haven't used a device so far with A/B partitioning scheme, so I'm not sure what nomenclature they use for partitions but I think abl_* is the application bootloader.
The kernel and recovery images are also both contained in the boot.img.
Click to expand...
Click to collapse
Yes. There is no recovery partition with A/B scheme.

mirfatif said:
And it also contains rawprogram_unsparse.xml or something similar with all partitions listed?
I haven't used a device so far with A/B partitioning scheme, so I'm not sure what nomenclature they use for partitions but I think abl_* is the application bootloader.
Yes. There is no recovery partition with A/B scheme.
Click to expand...
Click to collapse
There's nothing in the zip but image files. There's one text file but it just checks for latest bootloader. There's an image, xbl_config.img. I'm not sure what that does.
Sent from my [device_name] using XDA-Developers Legacy app

jd1639 said:
There's nothing in the zip but image files. There's one text file but it just checks for latest bootloader. There's an image, xbl_config.img. I'm not sure what that does.
Click to expand...
Click to collapse
Actaully rawprogram_unsparse.xml or similar files are used by Factory Flashers such as in Download Mode or ODIN etc. If the device is booted up to the stage of application bootloader (aboot), enough detail of partitions on eMMC is already loaded, including partition names (or labels) that are assigned at the time of creating GUID partition table (GPT). When we execute fastboot update xyz.zip, it flashes all images one by one very similar to fastboot flash boot boot.img, fastboot flash system system.img and so on. Here boot and system are partition names (part_name) while boot.img and system.img are image files (img_name) that should be found in OTA update zip file. Which image file is to be written to which partition is hard-coded in fastboot command's source code:
Code:
static struct {
const char* nickname;
const char* img_name;
const char* sig_name;
const char* part_name;
bool is_optional;
bool is_secondary;
} images[] = {
{ "boot", "boot.img", "boot.sig", "boot", false, false },
{ "system", "system.img", "system.sig", "system", false, false },
...
...
}

mirfatif said:
Actaully rawprogram_unsparse.xml or similar files are used by Factory Flashers such as in Download Mode or ODIN etc. If the device is booted up to the stage of application bootloader (aboot), enough detail of partitions on eMMC is already loaded, including partition names (or labels) that are assigned at the time of creating GUID partition table (GPT). When we execute fastboot update xyz.zip, it flashes all images one by one very similar to fastboot flash boot boot.img, fastboot flash system system.img and so on. Here boot and system are partition names (part_name) while boot.img and system.img are image files (img_name) that should be found in OTA update zip file. Which image file is to be written to which partition is hard-coded in fastboot command's source code:
Code:
static struct {
const char* nickname;
const char* img_name;
const char* sig_name;
const char* part_name;
bool is_optional;
bool is_secondary;
} images[] = {
{ "boot", "boot.img", "boot.sig", "boot", false, false },
{ "system", "system.img", "system.sig", "system", false, false },
...
...
}
Click to expand...
Click to collapse
This is great, especially the source code. It tells me a lot. I learned something new for the day!

how to use unlock oem command when no Volume button is available on car GPS T98 10 inches UNIT.?

K1 Not booting after flashing stock image

Yesterday I flashed BitO-KU kernel with dtb and blob file provided in this thread https://forum.xda-developers.com/sh.../tweaked-kernel-nvidia-shield-tablet-t3069776 on my Shield Tablet K1. Since then the problem started and my tab didn't boot.
How problem started?
Flashed BitO-KU kernel https://forum.xda-developers.com/sh.../tweaked-kernel-nvidia-shield-tablet-t3069776
Reboot (working fine)
Flashed dtb file "tegra124-tn8-p1761-1270-a04-e-battery.dtb" (provided in same thread)
Reboot (stuck on bootloader)
Flashed blob file (provided in same thread)
Reboot (stuck on bootloader)
After that I flashed factory images provided on Nvidia official site for K1 Tablet but still not booting. Although many times I have successfully flashed firmware images before, but only this time it's not booting. I think that the dtb and blob files I flashed previously with BitO-KU kernel were for Original Shield Tablet not for K1, that's why my tablet bricked.
What's working and what's not:
Bootloader is working and able to flash files using fastboot. But it's niether showing any error nor booting after flashing firmware images.
Recovery Not Working. Flashed various versions of TWRP from official website, none of them is working. Even tried directly booting to twrp recovery instead of flashing, still not working.
Any help is appreciated.
Sorry for my bad English!

Did you flash the stock system file and the stock blob? I think the instructions (recovery image) say to flash a few other things (recovery, userdata) but I was able to just flash the system and blob (flashing stock recovery might not hurt either).
Also, please don't apologize for your bad English. Your post is very well written, and I never would have guessed you are not a native English speaker.

redpoint73 said:
Did you flash the stock system file and the stock blob? I think the instructions (recovery image) say to flash a few other things (recovery, userdata) but I was able to just flash the system and blob (flashing stock recovery might not hurt either).
Also, please don't apologize for your bad English. Your post is very well written, and I never would have guessed you are not a native English speaker.
Click to expand...
Click to collapse
Hi @redpoint73, thanks for your response. Yes I did flash the stock system file, stock blob file and stock boot file. Still it wasn't booting.
And thanks for your compliment about my English.

Hello,
I was in a similar situation but finally managed to fix this boot issue on my K1.
What I have, Nvidia Shield Tablet K1
What I did wrong, flashed via fastboot a stock ROM image from Nvidia GameWorks - SHIELD Open Source Resources and Drivers
But not the correct one for Shield K1
I had the following steps for this recovery ROM (not for K1 tablet...):
fastboot flash recovery recovery.img
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash userdata userdata.img
fastboot flash dtb tegra124-tn8-p1761-1270-a04-e-battery.dtb
fastboot reboot
Flashing them failed on userdata (not enough space) and results in K1 to be stuck on boot and the Nvidia logo for ages.
(For a K1 tablet, you don't have a userdata and dtb flash image steps). I think what messed up my K1 is the dtb flashing step because formating, erasing and flashing recovery, boot, system and userdata partitions didn't have any effects on being stuck at boot.
What I did to get out of this mess and what you need:
Stock ROM K1: nv-recovery-image-shield-tablet-k1-factory0_0_0
fastboot + adb
twrp for K1 for revovery partitions
And know your K1 partitions
Via adb shell:
cd /etc
cat recovery.fstab
shieldtablet:/etc # cd /etc
shieldtablet:/etc # cat recovery.fstab
Result:
/dev/block/platform/sdhci-tegra.3/by-name/APP /system ext4 ro wait
/dev/block/platform/sdhci-tegra.3/by-name/CAC /cache ext4 noatime,nosuid,nodev,data=writeback,nodelalloc wait,formatable
/dev/block/platform/sdhci-tegra.3/by-name/LNX /boot emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/MSC /misc emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/UDA /data ext4 noatime,nosuid,nodev,data=writeback,noauto_da_alloc wait,check,formatable,encryptable=/dev/block/platform/sdhci-tegra.3/by-name/MDA
/dev/block/platform/sdhci-tegra.3/by-name/RP3 /usercalib ext4 noatime,data=writeback wait,formatable
/dev/block/platform/sdhci-tegra.3/by-name/USP /staging emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/MDA /metadata emmc defaults defaults
/dev/block/platform/sdhci-tegra.3/by-name/SOS /recovery emmc defaults defaults
/devices/platform/sdhci-tegra.2/mmc_host* auto vfat defaults voldmanaged=sdcard1:auto,encryptable=userdata
/devices/tegra-ehci.0/usb* auto vfat defaults voldmanaged=usb:auto
/dev/block/platform/sdhci-tegra.2/by-num/p1 /sdcard vfat defaults recoveryonly
Via adb shell:
cd dev/block/platform/sdhci-tegra.3/by-name/
ls -al
Resust:
shieldtablet:/dev/block/platform/sdhci-tegra.3/by-name # ls -al
total 0
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
drwxr-xr-x 2 root root 520 2019-11-19 08:27 .
drwxr-xr-x 4 root root 600 2019-11-19 08:27 ..
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 APP -> /dev/block/mmcblk0p13
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 CAC -> /dev/block/mmcblk0p14
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 CHG -> /dev/block/mmcblk0p20
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 DTB -> /dev/block/mmcblk0p11
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 EKS -> /dev/block/mmcblk0p2
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 FB -> /dev/block/mmcblk0p3
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 FBP -> /dev/block/mmcblk0p21
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 FCG -> /dev/block/mmcblk0p22
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 FCT -> /dev/block/mmcblk0p18
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 GPT -> /dev/block/mmcblk0p24
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 LBP -> /dev/block/mmcblk0p19
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 LNX -> /dev/block/mmcblk0p12
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 MDA -> /dev/block/mmcblk0p17
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 MSC -> /dev/block/mmcblk0p15
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 NCT -> /dev/block/mmcblk0p4
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 RP1 -> /dev/block/mmcblk0p6
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 RP2 -> /dev/block/mmcblk0p7
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 RP3 -> /dev/block/mmcblk0p8
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 RP4 -> /dev/block/mmcblk0p9
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 SOS -> /dev/block/mmcblk0p10
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 TOS -> /dev/block/mmcblk0p1
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 UDA -> /dev/block/mmcblk0p23
lrwxrwxrwx 1 root root 21 2019-11-19 08:27 USP -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 2019-11-19 08:27 WB0 -> /dev/block/mmcblk0p5
MAP boot, system, blob (staging) partitions with corresponding memory block
Ex: boot -> LNX -> /dev/block/mmcblk0p12
Via adb shell and using the images from K1 ROM nv-recovery-image-shield-tablet-k1-factory0_0_0 (check if your tablet k1 has the same partitions)
dd if=boot.img of=/dev/block/mmcblk0p12
dd if=system.img of=/dev/block/mmcblk0p13
dd if=blob of=/dev/block/mmcblk0p16
By getting from another ROM: tegra124-tn8-p1761-1270-a04-e-battery.dtb (renamed tegra124.dtb)
dd if=tegra124.dtb of=/dev/block/mmcblk0p11
Still failing... and stuck at boot so I decided to restore nv-recovery-image-shield-tablet-k1-factory0_0_0 via fastboot a last time but cleaned everything first:
twrp wipe all system cache data
then
fastboot flash system
fastboot erase boot
fastboot flash boot
fastboot erase staging
fastboot flash staging blob
fastboot reboot
And my Shield Tablet K1 was working again!! And very happy to have my Nvidia Shield K1 back (with latest LineageOS 15.1 ROM and working like a charm)!
I did a lot of stock ROM erase / format / restore on these partitions before and they all failed before. But I thing here the main difference is around the DTB partition.
May be the dd if=tegra124.dtb of=/dev/block/mmcblk0p11 step did properly restore the dtb info and partition or actually "corrupt" it in a way that cause the K1 to properly boot back. I don't know.
Hope that can help someone in the same situation!