(Journal) A successful attempt at fixing a hard-hardbricked Redmi Note 9 (Global) on Fedora

(Journal) A successful attempt at fixing a hard-hardbricked Redmi Note 9 (Global) on Fedora - Redmi Note 9 Guides, News, & Discussion

A long time ago, I posted in a forum thread about my difficulty in trying to revive my M2003J15SG and after having my ethereal Windows install bricked. I switched to Fedora and tried my hand there, where surprisingly, things worked very well. I'm not calling this a guide because I'm basically piecing this together from my bash_history and recollection. I have used the word guide too many times to keep that sentence but yeah, it may be shaky in some places.
Disclaimer
Code:
/*
* Your warranty is... still valid?
*
* I am 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.
*
* I have removed the part about laughing at you because I'm not a meanie :3
*
* But yeah, this text is as-is. We provide this work to you without
* warranty of any kind, express or implied and in no event shall the authors
* be liable for any claim, damages or other liability in any way, shape or form,
* arising from, out of, in connection with the work
*
*/
A few things to note
This is an attempt to document my experience with BROM recovery of a phone that I bricked because I flashed an incorrect littlekernel image. If you're able to use other methods (using fastboot, recovery mode, hell, even preloader mode, you should probably go with that, this is a last resort).
This guide does involve opening your device, you will need a heat gun, a few picks and a screwdriver. No, this is not optional.
If you've read the excellent guide by VD171 on bypassing authentication and flashing, you may notice the important text that states
> Once you get "Protection disabled" at the end, without disconnecting phone and usb, run SP Flash Tool
That's because if you do disconnect and attempt to reconnect your device, it won't be recognized anymore. On Windows, this manifests as the infamous "USB device not recognized" error. This isn't you installing incorrect drivers, that's the device behaving erratically.
To have a second go at it, you have to press Vol Up + Power for about 60 seconds before you can retry.
To enter BROM mode, you need to press Vol Down and no other key, and then plug in your device.
This guide while being Fedora-specific, could be translated to other Linux distros assuming you have the necessary packages installed and have the appropriate permissions and udev rules set
This model of device doesn't need the kamakiri-specific kernel patch
On RHEL-like distros like Rocky Linux and... RHEL, you may need to disable SELinux. I have mine disabled at install so I'm not sure how this guide will behave with SELinux enforcement enabled.
Click to expand...
Click to collapse
Ingredients
Stock MIUI ROM V11.0.5.0.QJOMIXM (the fastboot variant), which you can get from XiaomiFirmwareUpdater
SP Flash Tool v5.2020 for Linux, which you can get from SPFlashTools
VD171's readback_ui_bak.xml, which you can get from their XDA Forums thread
VD171's scatterfiles for V11.0.5.0.QJOMIXM, which you can get from their XDA forums thread
You'll specifically need MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt and MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt
mtkclient, an MTK device exploit kit, which you can find on their GitHub (you'll need their master branch, not their releases, so there'll be instructions on how to fetch it)
A box of chocolate chip cookies
Click to expand...
Click to collapse
a) Preparing the computer
Step 0: Extract all ingredients and put them into one directory for ease of access
You can do this via the command line or through your file manager, it's just for convinence. This guide will assume that everything is done in one neat folder.
Click to expand...
Click to collapse
Step 1: Install all the dependencies you'll need
Bash:
sudo dnf install android-tools git libusb-devel python3 python3-pip systemd-udev
Step 2: Prevent Linux from interfering with MediaTek serial connections
Bash:
sudo touch /etc/udev/rules.d/20-mm-blacklist-mtk.rules
echo "ATTRS{idVendor}==\"0e8d\", ENV{ID_MM_DEVICE_IGNORE}=\"1\"" | sudo tee /etc/udev/rules.d/20-mm-blacklist-mtk.rules
echo "ATTRS{idVendor}==\"6000\", ENV{ID_MM_DEVICE_IGNORE}=\"1\"" | sudo tee -a /etc/udev/rules.d/20-mm-blacklist-mtk.rules
Step 3: Clone mtkclient and install its dependencies
Bash:
git clone https://github.com/bkerler/mtkclient
cd mtkclient
pip3 install -r requirements.txt
python3 setup.py build
sudo python3 setup.py install
Step 4: Install mtkclient's bundled udev rules
Bash:
sudo usermod -a -G dialout $USER
sudo cp Setup/Linux/*.rules /etc/udev/rules.d
Step 5: Reload udev rules
Bash:
sudo udevadm control --reload-rules
sudo udevadm trigger
Step 6: Return to previous directory
Bash:
cd ..
b) Preparing the device
This is where you basically follow this iFixit guide for the purposes of just disconnecting the battery cable. So, just stop at Step 12, then put the back cover on just flush enough that you can now click the volume and power buttons and insert a cable into the USB-port but not too much so that you have to go through the effort of reopening it again (because, well, you'll have to).
Attempting to skip this will yield you STATUS_EXT_RAM_EXCEPTION.
Click to expand...
Click to collapse
c) Backing everything up
Alongside ROM and userdata, your EMMC contains your IEMI, your bootloader lock state, MAC addresses, calibration data, the whole nine yards. It's always a good idea to back things up before we get started.
Step 1: Copy readback_ui_bak.xml to the SP Flash Tool directory
Bash:
cp ./readback_ui_bak.xml ./SP_Flash_Tool_v5.2020_Linux/readback_ui_bak.xml
Step 2: Connecting your device and applying the exploit
Start off by running the exploit.
Bash:
cd mtkclient
chown +x mtk
./mtk payload
Once it says Preloader - Status: Waiting for PreLoader VCOM, please connect mobile, hold down Vol Down and connect your phone to the computer. If everything goes according to plan, you'll get an output similar to this.
Code:
Port - Device detected :)
Preloader - CPU: MT6768/MT6769(Helio P65/G85 k68v1)
Preloader - HW version: 0x0
Preloader - WDT: 0x10007000
Preloader - Uart: 0x11002000
Preloader - Brom payload addr: 0x100a00
Preloader - DA payload addr: 0x201000
Preloader - CQ_DMA addr: 0x10212000
Preloader - Var1: 0x25
Preloader - Disabling Watchdog...
Preloader - HW code: 0x707
Preloader - Target config: 0xe7
Preloader - SBC enabled: True
Preloader - SLA enabled: True
Preloader - DAA enabled: True
Preloader - SWJTAG enabled: True
Preloader - EPP_PARAM at 0x600 after EMMC_BOOT/SDMMC_BOOT: False
Preloader - Root cert required: False
Preloader - Mem read auth: True
Preloader - Mem write auth: True
Preloader - Cmd 0xC8 blocked: True
Preloader - Get Target info
Preloader - BROM mode detected.
Preloader - HW subcode: 0x8a00
Preloader - HW Ver: 0xca00
Preloader - SW Ver: 0x0
Preloader - ME_ID: [redacted]
Preloader - SOC_ID: [redacted]
PLTools - Loading payload from mt6768_payload.bin, 0x264 bytes
PLTools - Kamakiri / DA Run
Kamakiri - Trying kamakiri2..
Kamakiri - Done sending payload...
PLTools - Successfully sent payload: [redacted]/mtkclient/mtkclient/payloads/mt6768_payload.bin
Click to expand...
Click to collapse
Step 3: Open SP Flash Tool
Bash:
cd ../SP_Flash_Tool_v5.2020_Linux
chmod +x flash_tool
sudo ./flash_tool
Yes, I'm aware, it's technically not advisable to grant superuser privileges to, a flashing tool but... I can't get it to work otherwise, if you know how to make it work on Fedora, drop a comment.
Click to expand...
Click to collapse
Step 4: Load the Download Agent (DA)
Click "Choose" and go to (common directory)/mtkclient/mtkclient/Loader/xiaomi_9_DA_6765_6785_6768_6873_6885_6853.bin
Click to expand...
Click to collapse
Step 5: Configure SP Flash Tool
Go to Options > Option
In General, uncheck "Storage Lifecycle Check"
In Connection, select "UART"
COM Port: /dev/ttyACM0 (it may not be the exact number, it'll just look something similar to this)
Baud rate: 921600
In Download
Uncheck "USB Checksum"
Uncheck "Storage Checksum"
Click to expand...
Click to collapse
Step 6: Backup device contents
Start by going to the "Readback" tab, it should already be populated with values that correspond to images from pgpt to otp. If you are presented with an empty table, you've need to go back and check if you've copied readback_ui_bak.xml to the correct directory.
If it shows up, then click "Read Back" and if all goes according to plan, you should see the green checkmark show up eventually.
Click to expand...
Click to collapse
d) Flashing stock firmwareStep 1: Copy scatterfiles to ROM directory
Bash:
cp ./MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt
cp ./MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt
Step 2: Flash the firmware
Return to the "Download" tab and select the MT6768_Android_scatter--V11.0.5.0.QJOMIXM--boundary_false.txt scatterfile we just copied in the ROM's images directory
Select "Firmware Upgrade" from the drop-down menu and then hit "Download". If all goes according to plan, you should see a green checkmark.
Click to expand...
Click to collapse
Step 3: Restore bootloader status (optional)
In case you had an unlocked bootloader before imploding your phone and don't want to bother with Xiaomi's rigmarole, then by restoring seccfg, you should get it back.
Step 3.1: Copy over seccfg from our backup
You're probably going to be using a new terminal window because SP Flash is still running, navigate to your common directory first. The backup we did earlier stored all the images within the SP Flash Tool directory. We need to use sudo because flash_tool was running with root privileges and so, was writing with root privileges as well.
Bash:
sudo cp ./SP_Flash_Tool_v5.2020_Linux/seccfg ./merlin_global_images_V11.0.5.0.QJOMIXM_20200609.0000.00_10.0_global/images/seccfg
Step 3.2: Change the scatterfile, select the image and flash it
Change the scatterfile to MT6768_Android_scatter--V11.0.5.0.QJOMIXM--download_true--boundary_false.txt and un-select everything except seccfg
Select "Download Only" from the drop-down menu and then hit "Download". Fingers crossed, green checkmark, you should get your unlock back.
Click to expand...
Click to collapse
Step 4: Reconnect your battery and first boot
If you've reached this point and everything has worked as expected, reconnect your battery, long press the Power button and you should be greeted with a boot animation and hopefully a functioning phone.
Click to expand...
Click to collapse
e) Packing it up
Basically, just... follow the iFixit guide from Step b) in reverse and seal up your phone. I don't use this phone regularly so I never bothered sealing it, relying only on the plastic clips. You probably should but that's outside the scope of this journal.
Click to expand...
Click to collapse

f) Upgrading to Android 11 (optional)
As of this writing, LineageOS supports this device under the codename merlinx (the x is because of a conflict with the Moto G3 Turbo, which shares the same codename) and according to their install documentation, they expect a base of Android 11 and this guide flashes Android 10.
I personally used the V12.5.4.0.RJOMIXM firmware (available from XiaomiFirmwareUpdater, again, use the fastboot version) but I did an ever-so-slight change. The entire song-and-dance of needing the bypass exploit is because of "upgrades" made to the payload. I modified flash_all.sh to omit flashing the payload and the modification looks something like this (the other comment-outs were already there in the file)
Bash:
(...)
#fastboot $* flash preloader `dirname $0`/images/preloader_merlin.bin
#if [ $? -ne 0 ] ; then echo "Flash preloader error"; exit 1; fi
#fastboot $* flash efuse `dirname $0`/images/efuse.img
#if [ $? -ne 0 ] ; then echo "Flash efuse error"; exit 1; fi
fastboot $* flash logo `dirname $0`/images/logo.bin
if [ $? -ne 0 ] ; then echo "Flash logo error"; exit 1; fi
fastboot $* flash tee1 `dirname $0`/images/tee.img
"Flash preloader error"; exit 1; fi
(...)
I also commented out the reboot command at the end so I could flash LineageOS's recovery and flash the OS that I wanted.
Bash:
(...)
#fastboot $* reboot
#if [ $? -ne 0 ] ; then echo "Reboot error"; exit 1; fi
(...)
Of course, you need to boot into fastboot mode (by taking a turned off device and pressing Power + Vol Down) before you execute the script
Code:
cd merlin_global_images_V12.5.4.0.RJOMIXM_20220325.0000.00_11.0_global
chmod +x flash_all.sh
./flash_all.sh
Click to expand...
Click to collapse
Sources
https://github.com/bkerler/mtkclient
https://github.com/bkerler/mtkclient/issues/94
https://www.hovatek.com/blog/my-experience-unbricking-a-dead-boot-lg-stylo-6/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4221065/
https://forum.xda-developers.com/t/...for-merlin-redmi-10x-4g-redmi-note-9.4238149/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4223107/
https://forum.xda-developers.com/t/...omi-redmi-10x-4g-xiaomi-redmi-note-9.4223093/

Wow !
Really amazing guide !
Nice, nice
Thank you very much for contribution

Related

[Bootloader] U-boot for the multi-boot support

Hi!
As with Galaxy S2, I have ported the u-boot bootloader to the Galaxy Nexus. It can be chainloaded from samsung bootloader (loaded instead of linux kernel) safely.
It could be useful to have multiple ROMs on one device or test other OS like Ubuntu or Genode.
Detailed installation guide is available at Ksys Labs LLC wiki http://ksyslabs.org/doku.php?id=gnex_uboot .I'll just copy-paste it here
Happy hacking and don't forget to visit our wiki at http://ksyslabs.org !
===== Rationale ======
There were a couple reasons to port u-boot to Galaxy Nexus
* Security: we cannot trust the proprietary samsung bootloader
* Implementing dual-boot for original and custom firmware
* Booting Genode operating system
===== Demo =====
===== Compilation from source =====
Source code is in https://github.com/Ksys-labs/uboot-tuna
There exist two branches of interest
* master - contains the official stable releases. may be force-pushed and rebased, beware
* tuna-fosdem-hacks contains the u-boot that was used for FOSDEM 2013 to demo booting Genode
To compile, you need to have the ARM cross-compiler. I recommend codesourcery 2010q1-188 because that's what I'm using and some users reported that newer compilers produce broken binaries.
There are two ways to use the u-boot. One is flashing it instead of the Samsung SBL bootloader. The other one is chainloading it from the SBL.
Flashing instead of SBL has the following advantages
* Faster boot time than chainloading
* Ability to use the standard partitioning layout
There is a number of issues and therefore we do not recommend flashing it instead of SBL
* No Fastboot support (preliminary USB RNDIS and DHCP BOOTP support is available), you'll have to use OMAPFlash to restore the device if you flash a non-working kernel
* No display initialization. You'll have to disable the "Check for Bootloader initialization" option in kernel config
By default, the chainloaded version is compiled. It is loaded (by the SBL) to the address **0x81808000**.
If you want to build the SBL replacement version, edit the **include/configs/omap4_tuna.h** file and uncomment the **#define TUNA_SPL_BUILD** line. X-loader loads the bootloader to the address **0xa0208000**.
Code:
export PATH=/home/alexander/handhelds/armv6/codesourcery/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-none-eabi-
U_BOARD=omap4_tuna
make clean
make distclean
make ${U_BOARD}_config
make -j8 ${U_BOARD}
mkbootimg --kernel u-boot.bin --ramdisk /dev/null -o u-boot.aimg
===== Installation =====
==== Chainloaded Mode ====
You'll need the root access to your device.
You can take the prebuilt u-boot here. http://ksyslabs.org/lib/exe/fetch.php?media=gnex-uboot-chainloaded.img
The u-boot has the support for android boot images. When flashed instead of the SBL, it boots the kernel off the "Boot" partition. When chainloaded, it looks for the kernel in **/system/boot/vmlinux.uimg** . Additionally, it first looks for the **/system/boot/boot.scr.uimg** so you can put custom commands there and override the kernel image.
It also supports booting custom images from **/sdcard/boot/vmlinux.uimg** and **/sdcard/boot/boot.scr.uimg**
If you need larger images, I suggest that you use the **tuna-fosdem-hacks** branch, format the cache partition to ext2 and put the files to **/cache/media/boot/**
push the files to your device via adb
Code:
adb push gnex-uboot-chainloaded.img /sdcard/
adb hell
now, in the device shell, do the following
Code:
su
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/boot > /sdcard/vmlinux.uimg
mount -o remount,rw /system
mkdir /system/boot
cp /sdcard/vmlinux.uimg /system/boot/
cat /sdcard/gnex-uboot-chainloaded.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
sync
reboot
Instead of installing gnex-uboot-chainloaded.img via dd, you can use fastboot
Code:
fastboot flash:raw boot u-boot.img
===== Replacing samsung bootloader =====
OMAP4 devices cannot be bricked completely because the CPU has a firmware loader in the OTP (one-time programmable) memory. When the device is powered, it tries booting from USB.
Make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed. The installation procedure is roughly the same, but use **sbl** partition. And also install xloader from http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
Code:
adb push gnex-xloader-working.img /sdcard/
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
There exists a Samsung recovery tool which can unbrick the devices with corrupted xloader/SBL. You will need a computer running Windows XP.
Search the internet for the archive named "OMAPFlash_tuna.zip" which has md5 "ddbf07a1d36b044c40af5788a83b5395". We cannot upload it here because of the unclear license status.
===== Making images =====
You can either use Android's mkbootimg to produce ANDROID! type images (not recommended) or u-boot's mkimage (in the u-boot tools directory) to make boot images. Using ANDROID! format is discouraged because the loader code in the u-boot is buggy and may fail in some corner cases such as large images.
==== making a custom boot image ====
Code:
mkimage -A arm -O linux -T kernel -C none -a 0x80008000 -e 0x80008000 -n linux -d zImage vmlinux.uimg
#alternatively, just do that when compiling linux
#do not forget to add mkimage to your PATH variable
make uImage
==== making a custom boot script ====
Code:
mkimage -A arm -O linux -T script -C none -a 0x84000000 -e 0x84000000 -n android -d boot.scr boot.scr.uimg
===== Booting Modes =====
The bootloader supports several boot modes. Each boot mode is indicated by the color of the LED and activated by a combination of hardware buttons. It also supports the Android "reboot to recovery" and "reboot to bootloader" features
* Normal Boot -> no keys are pressed, cyan LED
* Recovery Boot -> Volume Up key pressed, green LED
* Custom Boot -> Volume Down key pressed, blue LED
* USB RNDIS mode -> both Volume keys pressed, purple LED
===== Pitfalls =====
* No Fastboot or DFU (RNDIS BOOTP is untested) -> not a big deal if you're chainloading, right?
* Serial number is always 0123456789abcdef or sth like that. Anyone to fix that?
* UART support is quirky. The device will likely hang if booted with the UART cable. Workaround: boot without the UART cable and plug right after the purple LED flashes.
===== A sample boot script for android =====
Make a boot.scr.uimg from it and push it to the correct location.
Code:
setenv bootargs "mem=1G vmalloc=768M omap_wdt.timer_margin=30 mms_ts.panel_id=18
no_console_suspend console=ttyFIQ0";
setenv loaddaddr 0x82000000;
setenv devtype mmc;
setenv devnum 0;
setenv kernel_part 0xc;
setenv kernel_name /media/boot/vmlinux.uimg;
echo Load Address: ${loaddaddr};
echo cmdline:${bootargs};
if ext4load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then
bootm ${loaddaddr};
exit 0;
elif ext2load ${devtype} ${devnum}:${kernel_part} ${loaddaddr} ${kernel_name}; then
bootm ${loaddaddr};
exit 0;
else
echo failed to boot custom image;
fi

Nice!
Before there actually wasn't any dual boot stuff for Nexus but now there is really much....
I will laugh if someone ports still another dual boot loader to Nexus, E.g BootiQi dual boot loader or what it is..., (for Jét it is JétQi) but I don't remember the original dual boot files names...

Any toro support?
Sent from my Galaxy Nexus using xda app-developers app

saber.srod said:
Any toro support?
Sent from my Galaxy Nexus using xda app-developers app
Click to expand...
Click to collapse
You may try it out. It is flashed instead of kernel, not overwriting the bootloader, so should be safe. As we don't have any Toro devices, we're not particularly interested in providing support for them unless someone steps up with a patch

Also, make sure to have an old version of x-loader (PRIMEKK14) because newer ones have the security hole which allowed booting unsigned bootloaders fixed.
Click to expand...
Click to collapse
do you have PRIMEKK14 file?
cause I couldn't find it on this thread:
http://forum.xda-developers.com/showthread.php?t=1587498
or this one is PRIMEKK14?
http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
any enlightenment please?

savantist said:
do you have PRIMEKK14 file?
cause I couldn't find it on this thread:
http://forum.xda-developers.com/showthread.php?t=1587498
or this one is PRIMEKK14?
http://ksyslabs.org/lib/exe/fetch.php?media=gnex-xloader-working.img
any enlightenment please?
Click to expand...
Click to collapse
The latter one is the one I'm using on my phone so it should work.

sp3dev said:
The latter one is the one I'm using on my phone so it should work.
Click to expand...
Click to collapse
I wanna use the chainloaded method, so first thing I should do is fastboot-ing that .img just like another bootloader file? then chainload the u-boot file?
but it looks like I'm replacing samsung SBL (replacing SBL method) if I do that, doesn't it?

savantist said:
I wanna use the chainloaded method, so first thing I should do is fastboot-ing that .img just like another bootloader file? then chainload the u-boot file?
but it looks like I'm replacing samsung SBL (replacing SBL method) if I do that, doesn't it?
Click to expand...
Click to collapse
Yes, you can actually fastboot it via
"fastboot flash:raw boot u-boot.img"
and no, you don't need to mess with xloader for chainloading

sp3dev said:
Yes, you can actually fastboot it via
"fastboot flash:raw boot u-boot.img"
and no, you don't need to mess with xloader for chainloading
Click to expand...
Click to collapse
so it's ok to do chainloading in PRIMELC03 bootloader? If yes, I'm success...

finally "The Great Sp3dev"
nice work like always,
playing with it now,let's see where it goes
Sent from my Galaxy Nexus using xda premium

sp3dev said:
The latter one is the one I'm using on my phone so it should work.
Click to expand...
Click to collapse
ah, I bricked my phone with your gnex-xloader-working using following script... It is only 128K. Is that right?
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
Is PRIMEKK14 bootloader the only one to work since we only have http://forum.xda-developers.com/showthread.php?t=1587498 this thread for bootloader and there's no flashable version of PRIMEKK14?
I use OMAPFlash to save it having PRIMEKK15 bootloader and I do not have the courage to do it again...

dlhxr said:
ah, I bricked my phone with your gnex-xloader-working using following script... It is only 128K. Is that right?
Code:
cat /sdcard/gnex-xloader-working.img > /dev/block/platform/omap/omap_hsmmc.0/by-name/xloader
Is PRIMEKK14 bootloader the only one to work since we only have http://forum.xda-developers.com/showthread.php?t=1587498 this thread for bootloader and there's no flashable version of PRIMEKK14?
I use OMAPFlash to save it having PRIMEKK15 bootloader and I do not have the courage to do it again...
Click to expand...
Click to collapse
Oh well, I specially edited the post so that chainloaded users don't flash loader. You only need the xloaded if you flash u-boot instead of SBL. Otherwise, treat u-boot just as linux kernel.
As for replacing bootloader, I guess PRIMEKK15 should also work, I just didn't notice when the security check was introduced. Yeah, use OMAPFlash to recover anyway. And note that you cannot use my precompiled u-boot to replace SBL. As written in the beginning of the post, you need to change a define in config and recompile because the load address and partition layout are different for chainloading and direct booting cases.

Very nice! Keep the good work up! :good:

sp3dev said:
Oh well, I specially edited the post so that chainloaded users don't flash loader. You only need the xloaded if you flash u-boot instead of SBL. Otherwise, treat u-boot just as linux kernel.
As for replacing bootloader, I guess PRIMEKK15 should also work, I just didn't notice when the security check was introduced. Yeah, use OMAPFlash to recover anyway. And note that you cannot use my precompiled u-boot to replace SBL. As written in the beginning of the post, you need to change a define in config and recompile because the load address and partition layout are different for chainloading and direct booting cases.
Click to expand...
Click to collapse
Some feedback here. I flashed u-boot to boot partition and save the original boot image to /system/boot/vmlinux.uimg.
Without any key pressed it shows
Code:
Wrong Image Format for boot command
Error: can't get kernel image!
Not booting xxxxxxxxx
Fail to boot
The characters on the screen does not show well and some of them can't be recognized....
When I press the volume up, it boot into recovery.
When I press the volume down, it shows
Code:
File not found /media/boot/vmlinux.uimg
Unrecognized filesystem type
Fail to boot
Something is wrong with my procedure?

Another small question. I want to make a zip to flash the U-boot, but always failed. I have to use fastboot command to flash gnex-uboot-chainloaded.img to boot.img.
What is in my updater-script.
Code:
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");
package_extract_file("gnex-uboot-chainloaded.img", "/tmp/gnex-uboot-chainloaded.img");
package_extract_file("META-INF/com/google/android/switch_boot.sh", "/tmp/switch_boot.sh");
set_perm(0, 0, 0777, "/tmp/switch_boot.sh");
run_program("/tmp/switch_boot.sh");
set_perm(0, 0, 0777, "/system/boot/vmlinux.uimg");
unmount("/system");
What is in my switch_boot.sh
Code:
#!/sbin/sh
cat /dev/block/platform/omap/omap_hsmmc.0/by-name/boot > /tmp/vmlinux.uimg
mkdir /system/boot
cp /tmp/vmlinux.uimg /system/boot/
cat /tmp/gnex-uboot-chainloaded.img /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
It seems the last line doesn't work...
Code:
cat /tmp/gnex-uboot-chainloaded.img /dev/block/platform/omap/omap_hsmmc.0/by-name/boot
If I use the following command in updater-script,
Code:
package_extract_file("gnex-uboot-chainloaded.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
The device enters bootloader directly showing no boot image after reboot....

dlhxr said:
If I use the following command in updater-script,
Code:
package_extract_file("gnex-uboot-chainloaded.img", "/dev/block/platform/omap/omap_hsmmc.0/by-name/boot");
The device enters bootloader directly showing no boot image after reboot....
Click to expand...
Click to collapse
That's because SBL expects the boot partition to contain the image in ANDROID! format. It creates the image itself when you flash via fastboot with the ":raw" suffix.
Try that
Code:
mkbootimg --kernel gnex-uboot-chainloaded.img --ramdisk /dev/null -o u-boot.aimg
Not sure why the original boot image didn't work for you. Are you copying the boot.img to vmlinux.uimg or the raw zImage? you should do the former, the u-boot expects either the "ANDROID!" image or the one made with mkimage.
If anything, you could try repacking the boot image yourself or try mine to see if it boots (it's for jb 4.1.1 though)
http://rghost.ru/44686398

chainloading method, in fact it works on PRIMELC03 too...
btw,
if I flash the xloader (replacing bootloader method), then how am I gonna back to original samsung bootloader/PRIMELC03 since there isn't fastboot support in your u-boot bootloader?
using odin? or omapflash? :crying:
thanks.

savantist said:
chainloading method, in fact it works on PRIMELC03 too...
Click to expand...
Click to collapse
ok, I probably didn't make it clear enough. chainloading works with any bootloader and is safe.
savantist said:
btw,
if I flash the xloader (replacing bootloader method), then how am I gonna back to original samsung bootloader/PRIMELC03 since there isn't fastboot support in your u-boot bootloader?
using odin? or omapflash? :crying:
thanks.
Click to expand...
Click to collapse
if you can boot android or recovery, thenuse dd it to /dev/block/blah-blah-blah, otherwise - omapflash.

sp3dev said:
ok, I probably didn't make it clear enough. chainloading works with any bootloader and is safe.
if you can boot android or recovery, thenuse dd it to /dev/block/blah-blah-blah, otherwise - omapflash.
Click to expand...
Click to collapse
you wrote it on wrong part on first page yesterday, makes me little bit confused, but it's corrected now...
but to do "replacing bootloader method", one should flash PRIMEKK14 or PRIMEKK15 bootloader before, right?
wow... omapflash...

savantist said:
you wrote it on wrong part on first page yesterday, makes me little bit confused, but it's corrected now...
but to do "replacing bootloader method", one should flash PRIMEKK14 or PRIMEKK15 bootloader before, right?
wow... omapflash...
Click to expand...
Click to collapse
well, some bootloaders after PRIMEKK may work, but I have not tested and we had some new phones with the recent firmware versions from stock, and u-boot failed to work there until xloader was downgraded

[Q] Rooting

I am not that tech-savvy, but I want to root my Htc-Evo-4g. It runs on a MVNO called FreedomPop. Can I get a one click installer from the computer or something easy to do? And a video showing me how to do it? And could you show me some absolutely need to get things when rooted? Thanks :laugh:

Evo4gOwner said:
I am not that tech-savvy, but I want to root my Htc-Evo-4g. It runs on a MVNO called FreedomPop. Can I get a one click installer from the computer or something easy to do? And a video showing me how to do it? And could you show me some absolutely need to get things when rooted? Thanks :laugh:
Click to expand...
Click to collapse
Some more info would be useful. Reboot to the bootloader and list your Hboot version. If you don't know how to do this, power the phone completely off. Once it's off, hold down the volume down button and the power button until the bootloader screen appears. Your Hboot version will be listed in one of the lines of info in the top left left corner of your screen. To reboot your phone, simply use the volume buttons to navigate the bootloader menu and highlight the "Reboot" option, then use the power button to select. The phone will then reboot to the Android OS.

Rooting
Evo4gOwner said:
I am not that tech-savvy, but I want to root my Htc-Evo-4g. It runs on a MVNO called FreedomPop. Can I get a one click installer from the computer or something easy to do? And a video showing me how to do it? And could you show me some absolutely need to get things when rooted? Thanks :laugh:
Click to expand...
Click to collapse
I had this whole thing written up, but my post hiccupped. My phone was originally on Sprint then switched to Ting. The carrier info was not affected by RUU or rooting. I very recently ran the RUU back to stock and re-rooted. Sorry, I don't have links, but I do have the filenames (and I do have the files so I could upload them somewhere).
The stickies here will have more background info. I'm a techie so I only take the notes I need to get by, but like to have a step-by-step so I'm fairly thourough.
There used to be a one-click sort of option, but HTC took that ability away. None of the steps are super hard but it's nice to have a techie background. The linux LiveCD may be scary for the inexperienced.
Here are my notes:
The steps to rooting this phone (any HTC are) -
Prerequisite: Android SDK (or at least fastboot and adb - when you connect your phone to the PC "adb devices" should identify it)
1. Unlock bootloader using HTCdev.com
WARNING: THIS WILL FACTORY RESET YOUR PHONE
Select Device - All Other Supported Models
Settings->Battery and uncheck Fast boot
Hold Volume Down + Power
Fastboot (Volume buttons to move, power to select)
Connect to PC
run "fastboot oem get_identifier_token"
Copy result (minus INFO) Right Click > Mark > highlight the block of text > Right click to copy (include start and end)
Copy emailed Unlock_code.bin to where fastboot.exe is
*** START HERE IF YOU ALREADY HAVE Unlock_code.bin ***
run "fastboot flash unlocktoken Unlock_code.bin"
Volume buttons to move, power to select
to relock your boot loader run "fastboot oem lock"
2. Install custom recovery (TWRP in my case)
Enable USB Debugging
Settings - More - Mobile Network Sharing - Check HTC Sync Manager
or Developer Options - Check USB Debugging ???
copy the SuperSU.zip to the SD Card
copy the UPDATE-SuperSU-v2.01.zip to the SD Card (you may be able to go straight to 2.01)
reboot to bootloader
go into fastboot
fastboot.exe flash recovery TWRP-Recovery-2.7.1.0b-jewel-CPTB.img
fastboot erase cache
go into bootloader
go into recovery
it may boot normal the first time
if it does shut down
boot into bootloader
and retry fastboot - recovery
3. Use TWRP to install SuperSU to get rooted, or just install a rooted rom.
in TWRP, choose install
navigate to your SuperSU.zip
install it
choose install
navigate to your UPDATE-SuperSU-v2.01.zip
install it
choose reboot system
4. Follow the instructions in S-Off_instruct.txt to get S-Off
--
To run the RUU (which puts your phone back into a stock build) I needed to relock the bootloader
boot into bootloader
fastboot
fastboot oem lock (in android sdk)
prerequisites:
you need to be "relocked"
set Dev Options - USB debugging is on
run the RUU as admin in Windows
RUU_JEWEL_CL_JB43_SENSE50_MR_Sprint_WWE_4.13.651.4_R…igned_one_step.exe
full name RUU_JEWEL_CL_JB43_SENSE50_MR_Sprint_WWE_4.13.651.4_Radio_1.13.11.1105_NV_3.02_003_PRL25007_release_353492_signed_one_step.exe
note: can run "adb reboot bootloader" rather than holding power and volume down to get into the bootloader
--
After running Firewater S-Off
(bootloader info)
*** TAMPERED ***
*** UNLOCKED ***
JEWEL PVT SHIP S-OFF RL
HBOOT-2.10.0000
RADIO-1.13.11.1105
OpenDSP-V33.1.0.45.1128
eMMC-boot
Mar 4 2014,14:26:40:1728
-- (Settings - About - Software info)
Android 4.3
Sense 5.0
Software 4.13.651.4
HTC API 5.45
PCI 3.02_003
PRL 24018
=============================================
contents of S-Off_Instruct.txt:
# To get S-Off on an HTC Evo 4G LTE (Jewel) with HBoot 2.10
#
# Boot a Linux 32 bit LiveCD (such as Ubuntu 12.04)
# these apps are in the Linux32BitApps folder
extract android-studio zip to ~/Downloads
extract jdk zip to ~/Downloads
copy firewater to ~/Downloads
sudo update-alternatives --install "/usr/bin/javac" "javac" "/home/ubuntu/Downloads/jdk1.8.0_05/bin/javac" 1
sudo update-alternatives --install "/usr/bin/java" "java" "/home/ubuntu/Downloads/jdk1.8.0_05/bin/java" 1
sudo update-alternatives --set "javac" "/home/ubuntu/Downloads/jdk1.8.0_05/bin/javac"
sudo update-alternatives --set "java" "/home/ubuntu/Downloads/jdk1.8.0_05/bin/java"
sudo nano /etc/profile
# add the text below to the end
JAVA_HOME=/home/ubuntu/Downloads/jdk1.8.0_05
PATH=$PATH:$JAVA_HOME/bin:/home/ubuntu/Downloads/android-studio/sdk/platform-tools
export JAVA_HOME
export PATH
ANDROID_SDK_HOME=/home/ubuntu/Downloads/android-studio/sdk
export ANDROID_SDK_HOME
# reload system-wide PATH
. /etc/profile
cd ~/Downloads/android-studio/bin
./studio.sh
# firewater
# http://firewater-soff.com/instructions/
# copies the file to the phone and runs it locally on the phone
adb reboot # <-important!!!!
adb wait-for-device push firewater /data/local/tmp
adb shell
su
chmod 755 /data/local/tmp/firewater
/data/local/tmp/firewater
#--------------------------------------------------
# Notes for installing java from a tar.gz file for normal usage
#sudo mkdir -p /usr/lib/jvm
## copy jdk zip to /usr/lib/jvm
#cd /usr/lib/jvm
#sudo tar zxvf jdk-8-linux-i586.tar.gz
#sudo rm jdk-8-linux-i586.tar.gz
#sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_05/bin/javac" 1
#sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_05/bin/java" 1
#sudo update-alternatives --set "javac" "/usr/lib/jvm/jdk1.8.0_05/bin/javac"
#sudo update-alternatives --set "java" "/usr/lib/jvm/jdk1.8.0_05/bin/java"
sudo nano /etc/profile
# add the text below to the end
## JAVA_HOME=/usr/lib/jvm/jdk1.8.0_05
## PATH=$PATH:$JAVA_HOME/bin
## export JAVA_HOME
## export PATH

Teclast X70 3G SoFIA Atom x3-C3130 Quad Core 7 Inch Android 4.4 Tablet PC IPS Screen

The Teclast X70 3G SoFIA Atom x3-C3130 Quad Core 7 Inch Android 4.4 Tablet is a very cheap tablet with some pretty good specifications, lets have a look on these here:
- Android 4.4 OS
- 7 inch 1024x600 IPS capacitive touch screen
- SoFIA Atom x3-C3130 Quad Core Max 1.8GHz
- 512MB LPDDR2 RAM and 4GB EMMC
- Support Bluetooth/WIFI/GPS/OTG/3G Phone Call function
- Front 0.3MP + Rear 2.0MP camera
- 187*113*8.9mm and 270g
What I especially like about it is the very cool slim design. Typical for other cheap tablets is that they are normally bulky and cheaplooking. But not the Teclast X70, it still looks really nice.
It should come with preinstalled Youtube/Facebook/Twitter/MSN/Android market/Skype/Calculator/Google Mail/Google maps/iReader/Quick Office. And support audio types like MP3/WMA/FLAC/OGG/AAC/WAV/APE.
{
"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"
}

Great device, How about battery life?

Battery life sucks, at least on mine, the 2nd available Intel Atom x3 AKA SoFIA on the market but what more can you ask for; an approx USD 79 Android device from Intel...
Been hunting & trying to root this sucker, nothing seems to work ATM & i found the Flash Tool/ USB driver/ Firmware for X70 here mirrored here just in case it disappear... Updates : Found quite a few more here...
More info...
Hacking
After some hex editing, X70 recovery.fls can be unpack, at least there are some leads as adb command only list out its path but not its partition name, this means custom recoveries such as PhilZ Touch or TWRP is possible... Updates : The included FlsTool won't repack it back to the correct fls format...
Intel SoFIA uses 2ndbootloader
Code:
[COLOR="blue"]mkbootimg[/COLOR]
usage: mkbootimg
--kernel <filename>
--ramdisk <filename>
[ [COLOR="Blue"]--second <2ndbootloader-filename>[/COLOR] ]
[ --cmdline <kernel-commandline> ]
[ --board <boardname> ]
[ --base <address> ]
[ --pagesize <pagesize> ]
-o|--output <filename>
Use osm0sis's AIK or Carliv's CIK to unpack/ repack... :good:
adb shell ls -l /dev/block/platform/soc0/e0000000.noc/by-name
Code:
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID001 -> /dev/block/mmcblk0p2
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID022 -> /dev/block/mmcblk0p7
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID068 -> /dev/block/mmcblk0p8
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID069 -> /dev/block/mmcblk0p11
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID070 -> /dev/block/mmcblk0p9
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID071 -> /dev/block/mmcblk0p3
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID074 -> /dev/block/mmcblk0p12
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID076 -> /dev/block/mmcblk0p10
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID115 -> /dev/block/mmcblk0p1
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID118 -> /dev/block/mmcblk0p5
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID119 -> /dev/block/mmcblk0p4
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID120 -> /dev/block/mmcblk0p6
lrwxrwxrwx root root 2015-07-17 10:39 ImcPartID121 -> /dev/block/mmcblk0p13
recovery.fstab
Code:
#
# Copyright (C) 2013 Intel Mobile Communications GmbH
#
# Sec Class: Intel Confidential (IC)
#
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID068 /system ext4 defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID069 /data ext4 defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID070 /cache ext4 defaults defaults
/dev/block/mmcblk1p1 /sdcard vfat defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID076 /nvm_fs_partition ext4 defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID074 /misc emmc defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID071 /boot emmc defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID119 /recovery emmc defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID120 /recoverym emmc defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID001 /mobilevisor emmc defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID013 /splash_screen emmc defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID115 /mvconfig emmc defaults defaults
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID118 /secvm emmc defaults defaults
fstab.sofia3g
Code:
#
# Copyright (C) 2013 Intel Mobile Communications GmbH
#
# Sec Class: Intel Confidential (IC)
#
# Android fstab file.
#<src> <mnt_point> <type> <mnt_flags and options> <fs_mgr_flags>
# The filesystem that contains the filesystem checker binary (typically /system) cannot
# specify MF_CHECK, and must come before any filesystems that do specify MF_CHECK
#
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID068 /system ext4 ro wait
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID069 /data ext4 nosuid,journal_async_commit,nodev,nodiratime,noatime,noauto_da_alloc,discard,data=ordered wait,encryptable=footer
/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID070 /cache ext4 nosuid,nodev wait
/devices/soc0/e0000000.noc/ef010000.l2_noc/e1000000.ahb_per/e1400000.sd/mmc_host/mmc1 auto vfat defaults voldmanaged=sdcard1:auto,noemulatedsd
/devices/soc0/e0000000.noc/ef010000.l2_noc/e2000000.ahb_per/e2100000.usb/usb1 auto auto defaults voldmanaged=usbdisk:auto
#/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID076 /nvm_fs_partition ext4 nosuid,nodev,data=journal wait,check
To reboot to stock 3e recovery
With the device at power off state, USB cable unplug, press & hold Volume Up, now press & hold Power button & it'll vibrate once then let go Power. Keep on holding Volume Up until you see the boot logo then let go & it boots up the stock 3e recovery.
To reboot to fastboot
There is no button combination to boot to fastboot however with the adb command -> adb reboot fastboot, you can boot to fastboot with correct adb driver installed at all the 3 modes...
At fully booted up Android OS
Even while the device at off-state ! (Charger init)
And the unknown Safe mode
There is no Intel Droidboot only distorted yellow screen but fastboot command works.
fastboot
fastboot getvar all
Code:
(bootloader) version-baseband: 23569
(bootloader) version-bootloader: 1525.100_M1S1
(bootloader) product: SF_3G
(bootloader) secure: NO
(bootloader) [COLOR="Blue"]unlocked: [B]NO[/B][/COLOR]
(bootloader) off-mode-charge: 1
(bootloader) ========== parition type ==========
(bootloader) system parition type: ext4
(bootloader) userdata parition type: ext4
(bootloader) cache parition type: ext4
(bootloader) radio parition type: raw
(bootloader) dsp parition type: raw
(bootloader) hypervisor parition type: raw
(bootloader) boot parition type: raw
(bootloader) recovery parition type: raw
(bootloader) splash parition type: raw
(bootloader) mvconfig parition type: raw
(bootloader) secvm parition type: raw
(bootloader) prg parition type: raw
(bootloader) psi parition type: raw
(bootloader) slb parition type: raw
(bootloader) nvm parition type: raw
(bootloader) ucode_patch parition type: raw
(bootloader) ===================================
(bootloader) ========== parition size ==========
(bootloader) system parition size: 0x40000000
(bootloader) userdata parition size: 0x4b960000
(bootloader) cache parition size: 0x40000000
(bootloader) radio parition size: 0x0
(bootloader) dsp parition size: 0x0
(bootloader) hypervisor parition size: 0x100000
(bootloader) boot parition size: 0x1080000
(bootloader) recovery parition size: 0x1180000
(bootloader) splash parition size: 0xa80000
(bootloader) mvconfig parition size: 0x80000
(bootloader) secvm parition size: 0x400800
(bootloader) prg parition size: 0x800
(bootloader) psi parition size: 0x20000
(bootloader) slb parition size: 0x100800
(bootloader) nvm parition size: 0x180000
(bootloader) ucode_patch parition size: 0x3800
(bootloader) ===================================
(bootloader) max-download-size: 0x38fff00
all:
finished. total time: 0.215s
fastboot oem unlock
Code:
...
(bootloader) Unlocking the bootloader means the following:
(bootloader) All user data will be deleted
(bootloader) Any securely stored data will be inaccessible
(bootloader) Warranty will be void
(bootloader) After unlocking you have to execute
(bootloader) > fastboot format userdata
(bootloader) > fastboot format cache
(bootloader) or carry out a factory reset from recovery
(bootloader) To confirm the unlock, please execute the command
(bootloader) > fastboot oem unlock confirm
OKAY [ 0.050s]
finished. total time: 0.050s
i don't intend to unlock mine yet as it will be getting LP update soon or i won't be able to update it, i donno... Initial look at the Flash Tool, tutorial, it seems SoFIA devices should be unbrickable & should be upgradable too, in spite of unlocked bootloader & rooting however i wouldn't want to risk it...
Updates : fastboot flash recovery twrp-recovery.img doesn't work... Flashing the Firmware doesn't overwrite the bootloader, it will remain unlock if you have unlocked it, fastboot oem lock doesn't work...
Unknown PTEST mode
To boot to PTEST mode => With the device at power off state, USB cable unplug, press & hold both Volume Up + Down, now press & hold Power button & it'll vibrate once then let go Power. Keep on holding both volume button until you see boot logo then let go & it boots up to a screen that says...
Code:
Press volume up or down key to exit PTEST Mode
Now plug-in USB cable to PC
Unknown device at Device Manager
For adb, you can use google adb driver
One of the CDC is Intel USB, use the one included in the Flash USB Driver folder
i've tried alot of CDC driver, non-worked, except for MediaTek CDC driver that i have, seems compatible, attach below CDC.zip...
All the drivers needed for Flash Tool to work are installed
As the device i own is not X70, i only tried the upload, seems to be working except for a compatible ebl.fls is needed for a successful upload...
Final Note
Use this guide at your own risk !
Unknown Safe mode
With the device at power off state, USB cable unplug, press & hold Volume Down, now press & hold Power button & it'll vibrate once then let go Power. Keep on holding Volume Down until it boots up
View attachment 3417538
Safe mode at the bottom left corner
Manage to unpack X70 system.img too...
Updates
Hmm, Chuwi Vi7 seems to be the exact clone, wonder if the firmware can be used on X70 or mine... Not compatible... Even X70 system.img won't boot on mine...
Further digging, its a single SIM device C3230 with better spec...
Cross-comparison
Found a few more X3...
Vido M7S
Onda V719 3Gs
Digma Plane 7.7
4good T700i
mediacom smartpad iPro 3G
iBall Slide Brillante
BLUEING S706
Updates - 08-Aug-2015
Found out my device is in fact actually an oem of X70 & damn Intel for making such cheap device while you can't even use fastboot to install custom recoveries to root it...
Updates : Hmm, it seems to be an oem of an oem, found it on default.prop...
There seems to be some headers needed to boot up the recovery, found out the included FlashTool has a back-end DOS program that can unpack & extract image parts from the FLS file.
Code:
[COLOR="Blue"]FlsTool -x recovery.fls[/COLOR]
FlsTool v.1.20
[Loading] recovery.fls (Fls2)
[Extract] 13905 recovery/meta.json
[Extract] 844 recovery/recovery.fls_inj_PSI_ver.txt
[Extract] 914 recovery/recovery.fls_inj_EBL_ver.txt
[Extract] 64320 recovery/recovery.fls_inj_PSI.bin
[Extract] 144084 recovery/recovery.fls_inj_EBL.bin
[Extract] 2048 recovery/recovery.fls_ID0_CUST_SecureBlock.bin
[Extract] 617168 recovery/recovery.fls_ID0_CUST_LoadMap0.bin
[Extract] 32430 recovery/recovery.fls_ID0_CUST_LoadMap1.bin
[Extract] 7786496 recovery/[COLOR="Blue"]recovery.fls_ID0_CUST_LoadMap2.bin[/COLOR]
recovery.fls_ID0_CUST_LoadMap2.bin is the stock 3e recovery.img
Need to figure out the correct way to repack the stock 3e recovery.fls & when it boots then will try it out on the ported TWRP, hopefully it boots too...
In the mean time, i have also contacted Intel, hopefully they'll respond or we'll have to figured ourselves how to repack custom recoveries so that it'll boot on our device to root it or wait for exploit root software to work on our SoFIA x3 device... Updates : They never respond...
Anyone wants to explore then here is the Guide, FlashTool & Firmware for my device... Not compatible for X70
Updates - 10-Aug-2015
Feedback from our Russian counterpart seems true that X70 recovery partition size is only 8MB only, no custom recoveries would fit except old version !
Code:
FlsTool v.1.20
This tool can do several different operations of FLS files.
Use the 'Action' option to select to required operation.
Actions:
-p [ --pack ] Packing multiple FLS files into one
-i [ --inject ] Inject NVM, Certificates or Security into FLS file
-x [ --extract ] Extract all image parts from the FLS file(s)
--extract-fls Extract embedded files from the FLS file(s)
--extract-prg Extract PRG file
-b [ --to-bin ] Convert a single Hex file to binary file
--hex-to-fls Create an Fls from a Prg file
--sign Formerly known as FlsSign
--to-fls2 [ arg ] Force output file format to Fls2
--to-fls3 [ arg ] Force output file format to Fls3
-d [ --dump ] Dump the meta data of an FLS file.
--sec-pack Dump all SecPack data of an FLS file.
HexToFls options:
--prg arg Choose a PRG file to create the Fls from
--psi arg Add a PSI to the Fls file (replaces if '-r' option)
--ebl arg Add an EBL to the Fls file (replaces if '-r' option)
--meta arg Inject any meta file to the Fls file (Equal to --version or -v in HexToFls)
--xml arg Add an XML file to the Fls file (replaces if '-r' option)
--zip arg Add a ZIP file to the Fls file (replaces if '-r' option)
--script arg Add a Script file to the Fls file (replaces if '-r' option)
--tag arg Specifies the memory region tag to insert the input file (replaces if '-r' option)
Inject options:
-n [ --nvm-path ] arg Path to the NVM input files
Generic Options:
-o [ --output ] arg Output path
-r [ --replace ] [ arg ] Defaults to replace when trying to add a section which is already existing
-v [ --verbose ] [ arg ] Set verbosity
--prompt [ arg ] Prompt before quitting
--version Show the version of this tool
-h [ --help ] Show command line help
Please specify an input file
Code:
FlsTool -d recovery.fls > partlist.txt
Code:
{
"addr": "0x1CC00000",
"length": "[COLOR="Blue"]0x00800000[/COLOR]",
"class": "Cust",
"tag": "RECOVERY:3#77",
"options": [ ],
},
recovery partition size of 0x00800000 in decimal is 8388608 = 8MB only...
X70 Flash Tool Driver Installation & firmware download
Typically, installing the Intel USB driver that comes with the firmware will work ( right-click it & Run as Administrator ) & if it doesn't then follow below guide.
With the device at power off state, USB cable unplug, open Device Manager, plugin the USB cable & an unknown device will appear, quickly double-click it & manually install the FlashUSB.inf included in the FlashUSB_Driver folder.
To download the firmware successfully, follow the guide that comes with it.
Again : Use at your own risk
Great product interview/ review by armdevices.net
Updates
Hmm, even Asus Zenpad 7.0 uses the x3 too AKA SoFIA but with better spec, the Z170 series & Z370 series
Updates - 17-08-2015 Finally, got ROOT access
Use FlsTool to download the x70-unsecured-boot.fls then most of the existing exploit rooting software will work, i think...
Updates
WARNING : For heaven sack's, noobs & newbies, pls READ EVERYTHING FIRST before hands on ! On & off, i got just too many pm regarding brick devices... There is only one post so pls read it, unlock your bootloader first before flashing the unsecured boot fls...
If you're using JOI then use JOI-unsecured-boot.fls...
Updates
Feedback seems some are not able to root with existing exploit rooting software, fyi, i manually root mine using adb commands then unroot & only tried iroot/ vroot & it works so i presume Kingo, Baidu & others will work too... Try giving the exploit software a helping hand first before using it...
Code:
adb root
adb remount
Updates - 23-08-2015 Since many still couldn't root it...
i'll share my manual rooting script here...
On Linux
Code:
adb root
sh root.bat
[COLOR="blue"]OR[/COLOR]
chmod 777 root.bat
./root.bat
On Windows
Code:
adb root
root.bat
[COLOR="blue"]OR[/COLOR]
Double-click root.bat
If you don't have a working adb then use the one from here... :good:
What to do once you got ROOT :good:
Install Xposed Installer => XDA :good:
Install GravityBox [KK] => XDA => youtube overviews & tutorials :good:
[GUIDE] Extreme Battery Life Thread ( Greenify+Amplify+Power Nap ) :good:
More info here, enjoy your New Custom ROM with Extreme Battery Life :laugh:
Must have Modules
More Modules
All Modules
Updates - 07-09-2015
Got just too many miss call, i can hardly hear it so i purchase this inexpensive mini bluetooth speaker strap to my sling bag & problem solved... :laugh:
Updates - 09-09-2015 => 4pda users IMEI problem
i've already told you guys here that i'm not able to login b'cos of that site super unreasonable Russian captcha but still nobody post reply here...
i wouldn't even bother to reply when i saw his thread here while the previous user ask exactly the same problem & he don't even bother to reply with the solution that he had...
Funny though, i don't have such IMEI problem after so many flashing on my X70 clone...
Possible other Solutions
Xposed IMEI Changer
Repair imei number in android => On x3, to check IMEI No. is *#06#
Others possible solutions
Updates
Thanks to Invisibot for sharing his findings & solutions for IMEI... :good: Mirrored here the software & the manual just in case it disappear
Updated JOI 7 lite unsecured boot.fls - 13-09-2015
i can't believe oem actually disabled the swap partition until i unpack Chuwi vi7 & discovered how it is enabled...
Huge apks now start up almost immediately though it takes quiet awhile for the OS to stabilize after every reboot but i guess its worth it as apps are more responsive after that...
Updated X70 unsecured boot.fls with swap enabled - 15-09-2015
Added X70 C6F9 unsecured boot.fls with swap enabled - 24-09-2015
X70 C5F9 => 512MB RAM
X70 C6F9 => 1GB RAM
Updates - 2016
Refer to here for TWRP & flash SuperSU to ROOT...

I don't want to be rude, but what's the point in starting a thread for a device, list some official specs but no hands-on? This routine (hunt for thanks or OP threads?) just creates parallel threads on the forum for the same device. I mean, the next person who actually owns or have access to the device and wants to post a real review of it might not want to post it here. That person might want to be the OP for that thread.

MacArthur67 said:
I don't want to be rude, but what's the point in starting a thread for a device, list some official specs but no hands-on? This routine (hunt for thanks or OP threads?) just creates parallel threads on the forum for the same device. I mean, the next person who actually owns or have access to the device and wants to post a real review of it might not want to post it here. That person might want to be the OP for that thread.
Click to expand...
Click to collapse
Well, I actually truly planned to get the device when I created the topic, but changed my mind. If you check my profile and other posts, you would notice that I actually always post a hands-on or review also in my posts if I get the device.
Anyone that actually got the device and want to add a review, can just contact me and I will put in up in post #1 - so no! its not a problem at all.
Parallel threads are not allowed in here, so anyone creating a thread for this, should actually first check if there is an existing one.
There is no real advantage of being a OP for at thread (other than I have a lot of work also answering questions like yours now). If I for instance post your review in #1, I would also write the credits/name for the review so they can thank you and not me.

s7yler said:
Well, I actually truly planned to get the device when I created the topic, but changed my mind. If you check my profile and other posts, you would notice that I actually always post a hands-on or review also in my posts if I get the device.
Anyone that actually got the device and want to add a review, can just contact me and I will put in up in post #1 - so no! its not a problem at all.
Parallel threads are not allowed in here, so anyone creating a thread for this, should actually first check if there is an existing one.
There is no real advantage of being a OP for at thread (other than I have a lot of work also answering questions like yours now). If I for instance post your review in #1, I would also write the credits/name for the review so they can thank you and not me.
Click to expand...
Click to collapse
Yes I know that parallel threads are against the forum rules but a thread with only a news about a forthcoming device is not a real thread on a developer forum. It shouldn't be allowed in the first place in my opinion. This is not a news site/forum so what's the point in just echoing here what you have read in a press release on some other site? If people can read your echo here they can also read the original news where you found it. You seem to mass produce short and very trivial reviews of various devices from some reason and then you always leave the thread more or less. It's very counterproductive on a developer site and it's about time that someone tell you that. I'm just sorry it had to be me. Next time at least wait until you have the device or let people with a real interest in the device start the thread and write the review. You don't need to be an Einstein to understand that on a developer forum it would be a great advantage if the OP of a tread has a real interest in the device the thread is all about. Your interest seems to be something completely different that I can't really figure out, but in any case it's counterproductive on a developer forum. Peace!

MacArthur67 said:
Yes I know that parallel threads are against the forum rules but a thread with only a news about a forthcoming device is not a real thread on a developer forum. It shouldn't be allowed in the first place in my opinion. This is not a news site/forum so what's the point in just echoing here what you have read in a press release on some other site? If people can read your echo here they can also read the original news where you found it. You seem to mass produce short and very trivial reviews of various devices from some reason and then you always leave the thread more or less. It's very counterproductive on a developer site and it's about time that someone tell you that. I'm just sorry it had to be me. Next time at least wait until you have the device or let people with a real interest in the device start the thread and write the review. You don't need to be an Einstein to understand that on a developer forum it would be a great advantage if the OP of a tread has a real interest in the device the thread is all about. Your interest seems to be something completely different that I can't really figure out, but in any case it's counterproductive on a developer forum. Peace!
Click to expand...
Click to collapse
"If people can read your echo here they can also read the original news where you found it"
No not always, I get info directly from the manufactures sometimes. And sometimes I write texts myself. That you can't read somewhere else. Of course it is not always so, depends on the info/news and devices. I love phones and tablets, and that's why I like to be a news poster. If I don't post, someone else would do.
You seem to mass produce short and very trivial reviews of various devices from some reason and then you always leave the thread more or less
No, I follow every single thread I make (else I would probably also not answer in this old thread here now) and if people have real interest in the device I also answer or follow up with news. If people ask something already answered I don't reply, that's right. Else I could spend the whole day answering questions from people. And I would say on 80% of the threads I make, I also always follow up with a full video review of the device.
Next time at least wait until you have the device or let people with a real interest in the device start the thread and write the review.
Doesn't work that way, as the manufactures already post info before the device is released. And many want info as soon it is possible, not 1 month after when the device already is old again.
a great advantage if the OP of a tread has a real interest in the device
Well, it is not really up to you to judge if I have real interest in a device or not. If I am going to test it I will have real interest in it. But some devices are more interesting than others, also after they have been received.
I don't see anything bad in creating threads that can gather people around a device. In these people can help, discuss & develop the device. I see that in my Elephone P8000 thread, my Jiayu S3 thread and UMI ZERO thread, for some devices like for example the UMI IRON it doesn't happen but that's not really my fault. I personally still love the phone.
And PS. I'm from Denmark, so you should really try to be a little more nice to one from your neighbouring country.

Teclast 3G x70
Hello freinds
Please could someone help me, because i am very stuck with the problem and no one over the internet doesnt know how to help me.
My tablet Teclast 3G x70 suddenly become dead and I have luck to repair it by reflashing procedure, but the IMEI has been lost
Please maybe somebody know how to repair it, because I have already tried everything I know...
Thank you

You guy always said already tried everything, what actually have you tried, list out everything so its easier to trouble-shoot & to narrow things down...
First of all, did you guys even read the included guide/ tutorial, i flash so many times on my X70 clone, never even once loose the IMEI, try rebooting to stock 3e recovery & do a Factory Reset or using fastboot to do that, that should reset everything back to normal ...
Code:
adb reboot fastboot
fastboot format userdata
fastboot format cache
Refer to here for more IMEI repair info....

to : yuweng TECLAST X70 3G
Hello dear friend Yuweng
I come from 4 PDA forum you must be aware of.
And there is no one can resolve this issue.
First of all I want to thank you for the ROOTING guide - I get root with your help
And about IMEI : i have tried everything you advise to do to recover IMEI
I think it is maybe impossible to recover IMEI because it is INTEL platform like Google Nexus for example (need special hardware to recover IMEI)
Thank you

Your username ends with il then only i try 012.net.il then only realize it... :laugh: All Android OS comes from Google so this means all Android devices are more or less the same, i guess its just a corrupted partition or file missing that causes this IMEI issues, same as many Android devices are experiencing...
Ok, try below command, give me a download link to it & i'll make a comparison to see which file is missing...
Code:
adb shell su -c "ls -R" > myx70.txt
After that, try to follow exactly as the FlashTool_E2 guide to download the firmware all over again, one of the pdf stated single-threaded download mode, multi-threaded download mode, try & see if that makes a different.... :fingers-crossed: Russian translated version here...
Updates
Hmm, that pdf stated 15 firmware files, that means modem.fls, mvconfig.fls & thread.fls is missing, wonder if that causes the IMEI to disappear...
[email protected] said:
Hello dear friend Yuweng
I come from 4 PDA forum you must be aware of.
And there is no one can resolve this issue.
First of all I want to thank you for the ROOTING guide - I get root with your help
And about IMEI : i have tried everything you advise to do to recover IMEI
I think it is maybe impossible to recover IMEI because it is INTEL platform like Google Nexus for example (need special hardware to recover IMEI)
Thank you
Click to expand...
Click to collapse

to : yuweng TECLAST X70 3G
Helo again dear friend
It is very nice you still support this thread
I did get the file myx70.txt you need
Please check it, Thank you

to : yuweng TECLAST X70 3G
Helo again dear friend
It is very nice you still support this thread
I did get the file myx70.txt you need
https://www.mediafire.com/?0iskyl3hazaketo
Please check it, Thank you
By the way it is some softwareprogram I have been informed in that can do everything including restoring IMEI
But I cant use it bacause it is in CHINESE
it called Rabbit Root and it is web page is: http://www.7to.cn/#

When i ask you to do a Factory Reset using the stock 3e recovery & you said you did it but your myx70.txt says otherwise... Few files missing, seems like it is not initialize properly...
Code:
./data/media/0:
91 WireLess
Alarms
Android
AppGame
DCIM
Download
GOLauncherEX
GoStore
MIUI
Mihome
Movies
Music
Notifications
Pada
Pictures
Podcasts
Ringtones
XPOSED IMEI Changer_1.3_apk-dl.com.apk
baidu
com.91.channel.repository
dianxin
libs
mgyun
nd
system
system.info
tencent
tmp
xutils
To reboot to stock 3e recovery
With the device at power off state, USB cable unplug, press & hold Volume Up, now press & hold Power button & it'll vibrate once then let go Power. Keep on holding Volume Up until you see the boot logo then let go & it'll boots up the stock 3e recovery.
Click to expand...
Click to collapse
Press the power button once & you'll see the stock 3e recovery menu
Use the volume down key to go to wipe data/ factory reset & press power button
Use the volume down key to go to Yes -- delete all user data & press power button
Do the same for cache partition
reboot system now
* Manually format the internal sdcard as well if Factory Reset doesn't remove it
That software you pointed out, the IMEI repair is for MTK devices only.
Updates
Check with dAverk how he did it, every detail like where he got the firmware from, the step by step that he took on flashing the firmware, this will narrow things down as why IMEI is lost on you guy's x70 & not him... i believe if you guys follow his steps exactly, you should be able to get the IMEI working again... :fingers-crossed:
Firmware flashing bricks the device, Factory Reset corrupts the IMEI was a thing in the past ( Jellybean/ ICS/ GB issues ), it shouldn't happened on KitKat/ Lollipop devices, i believe...

OK I have reflashed this tablet with all FIRMWARES i have found on this forums
I cant get to Boot Menu ( Power ON+Volume UP) - tablet continue to load and nothing happens
And the ADB command doesnt help
adb reboot fastboot
fastboot format userdata
fastboot format cache
The tablet reboots and I get GREEN screen
https://www.mediafire.com/?0pkb7pk89d8c33s

What have you done to yourself, that green screen is the fastboot screen, you'll need adb driver & fastboot.exe for it to work...
i already mentioned, be specific, all FIRMWARES, which one ? JOI, X70 from geekbuying or chinagadgetsreviews & etc, may be they are all different, i donno, i didn't download all to check if they are identical, may be thats the cause of your green screen problem & IMEI problem ?
This is a General not Development thread, i don't intend to start a new one, i shouldn't even be sharing these infos here...
Warnings : Use this guide at your own risk ! For Developers ONLY
These infos are the results of spending many hours with FlsTool( linux version ) & flstool.exe
Code:
./FlsTool -x recovery.fls
./FlsTool --extract-prg recovery.fls
./FlsTool -x system.fls
./FlsTool --extract-prg system.fls
./FlsTool -x mvconfig_smp.fls
./FlsTool --extract-prg mvconfig_smp.fls
./FlsTool -x mobilevisor.fls
./FlsTool --extract-prg mobilevisor.fls
After unpack, these individual fls files contains PRG, EBL, PSI, meta files & the actual Android img file or binary files. Each of these extracted files, PRG, EBL, PSI, meta files are identical.
When you use dd command to backup these partition, it is not an Android image file nor a fls file & a dd restore with either the dd backed up or the fls file won't boot or work correctly
Eg.
Code:
adb shell su -c "dd if=/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID119 of=storage/sdcard1/recovery.img"
adb shell su -c "dd if=storage/sdcard1/recovery.img of=/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID119"
[COLOR="blue"]OR[/COLOR]
adb shell su -c "dd if=storage/sdcard1/recovery.[COLOR="Blue"]fls[/COLOR] of=/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID119"
[COLOR="blue"]OR[/COLOR]
fastboot flash recovery recovery.img
fastboot flash recovery recovery.[COLOR="blue"]fls[/COLOR]
[COLOR="blue"]OR[/COLOR]
fastboot flash system system.img
fastboot flash system system.[COLOR="blue"]fls[/COLOR]
When Hex edit/ compare those files, they are totally different. Eg. dd backed up recovery.img with recovery.fls is not the same.
The recovery.fls when unpack has three different regions, i think the existing FlsTool version 1.20 has bugs, it doesn't repack it back to the correct format.
recovery.fls_ID0_CUST_LoadMap0.bin is identical to mobilevisor.fls_ID0_CODE_LoadMap0.bin
recovery.fls_ID0_CUST_LoadMap1.bin is identical to mvconfig_smp.fls_ID0_CUST_LoadMap0.bin
recovery.fls_ID0_CUST_LoadMap2.bin is the actual Android recovery.img that can be unpack with AIK or CIK as already explained on this post here
Even if it works, custom recoveries such as PhilZ Touch or TWRP which is also using the dd command for backups, will not be able restore it correctly as it is not a fls file or an Android image file.
As for the boot.fls, what i did was change the default.prop & repack it back.
Code:
ro.secure=1 [COLOR="Blue"]<= Change to [B]0[/B][/COLOR]
ro.allow.mock.location=0 [COLOR="blue"]<= Change to [B]1[/B][/COLOR]
ro.debuggable=0 [COLOR="blue"]<= Change to [B]1[/B][/COLOR]
ro.adb.secure=1 [COLOR="Blue"]<= Change to [B]0[/B][/COLOR]
Unpack boot.fls
Code:
./FlsTool -x boot.fls
./FlsTool --extract-prg boot.fls
After unpack/ repack with AIK, copy image-new.img to the same folder.
Repack boot.fls
Code:
./FlsTool --psi boot/boot.fls_inj_PSI.bin --prg boot_0.fls --ebl boot/boot.fls_inj_EBL.bin image-new.img --tag BOOT_IMG -o new-boot.fls
After this, any exploit rooting software should work.
Found two new link for X70 (C6F9) -Android4.4.4-V1.05-5726 may be this one will solved the IMEI issues, i donno...
Source 1
Source 2
Conclusion : You can't do much on Intel x3 but to bug your device manufacturer to release the firmware then only rooting is possible otherwise forget it, its file system is not regular Android image, use the device as it is or you'll brick it in doing so...
4Good T700i 3G users
Since you guys confirmed X70 firmware can be downloaded successfully & the camera doesn't work after that, meaning the firmware is almost compatible except for the camera driver.
Since 4Good doesn't release the firmware, the correct way is to create an ebl.fls file, upload the boot.bin then port an unsecured-boot.fls & root it...
Code:
./FlsTool -x boot.fls
./FlsTool --extract-prg boot.fls
./FlsTool --hex-to-fls boot/boot.fls_inj_EBL.bin --prg boot_0.fls --psi boot/boot.fls_inj_PSI.bin --tag BOOT_IMG -o ebl.fls
View attachment 3475319
View attachment 3475321
Hex edit boot.bin & extract the boot.img( look for the header ANDROID! ), with above mentioned technique to make an unsecured boot.fls, unlock the bootloader, download this unsecured boot.fls then root it & the firmware stays as stock with both camera working.
View attachment 3475504
Or upload the boot.bin & i'll port an unsecured-boot.fls for you guys...
View attachment C5F9-ebl.fls.zip
View attachment C6F9-ebl.fls.zip
Or after rooting, copy all 4Good camera *.so files, flash x70 system.fls ONLY then manually use any ROOT Explorer to copy back these 4Good camera *.so files over & both cameras should work on 4Good after a reboot...
Theoretically, you can also dd the system.img, mount it, make changes then repack it back to fls file but then again, these files will be huge & i don't even know whether it works, never try that...
Code:
adb shell su -c "dd if=/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID068 of=storage/sdcard1/system.img"
adb pull storage/sdcard1/system.img
mkdir sys
sudo mount -t ext4 -o loop system.img sys/
Do whatever you want with the files & folders at [COLOR="Blue"]sys/[/COLOR]
sudo ./make_ext4fs -s -l 1024M -a system new.img sys/
sudo umount sys
./FlsTool --prg system_0.fls --ebl system/system.fls_inj_EBL.bin --psi system/system.fls_inj_PSI.bin new.img --tag SYSTEM -o new-system.fls
Download it with FlashTool_E2
Updates - Nov 2015
Thanks to benderit for sharing his detailed findings & how-tos for backing up/ creating a restored boot.img/ system.img via fastboot for x3 devices without FlashTool_E2 ROM... :good:
Updates - Jan 2016
Refer to here on how to create system.img on Win OS & using fastboot to flash it... :good:
Updates
The adb command adb shell ls -l /dev/block/platform/soc0/e0000000.noc/by-name correspond to recovery.fstab as shared on this post here EXCEPT for ImcPartID022 & ImcPartID121.
Hex editing the partition ImcPartID121 show that it is empty while ImcPartID022 shows there are some data inside it, i cannot tell whether its the bootloader or the IMEI info.
Those that lost their IMEI can use below command to backup & check whether there is data in it or its empty( all zero ). If its empty means the IMEI info might be at this partition...
Code:
adb shell su -c "dd if=/dev/block/platform/soc0/e0000000.noc/by-name/ImcPartID022 of=storage/sdcard1/ImcPartID022.img"
adb pull storage/sdcard1/ImcPartID022.img

To yuweng
Everything seems to be OK. And now after a week of try I finally understand that it was not worth trying. Because it finally become clear that it is nothing to do with IMEI. Very good yuweng.
It is seems that actually no one know how to resolve it.
And what is about trying different firmwares?
I just don't understand how would it help.
And about that all android systems are similar it also mistake.
If you want to restore IMEI on Nexus 4 you need special equipment.

The reason for your case i guess is everyone is new on your side, as the saying too many cooks spoil the broth...
Fyi, my previous device, the MTK, bcos of one Russian DEV shared his findings, thousands of users save hundreds of dollars each.... :good:
Bcos of one DEV shared his unpack/ repack script, i discovered that MTKs ROM can ported over to hundreds if not thousands of similar devices...
And Yes, i've also seen many that says they will never use PhilZ Touch or TWRP ever again bcos it corrupts their device, the reason for this is bcos no DEV is working on that device & end users just blindly installing it & complaining after that... The same at 4pda, few that swear to throw away their X70 too... :laugh: We need more DEVs to look into it then it will become a better Android device...
OT : And Yes, you can actually port 4Good firmware to work on X70 & vice-versa, when DEVs starts to work on it, if there is one, bcos it is an exact clone while mine is different, i donno, may be the newer X70 (C6F9) is compatible, i didn't try it...
Port means identify & taking parts of the firmware from other similar device & make it work on yours while flashing the whole firmware will normally leads to a brick device...

at now we tried flash 7 block of mmc (because we found many diffs in this block) from working device on dead[imei] - but nothing happens. Try work with whole mmc.

it seems that InvisiBot have already made the discovery... :good:
Haven't took a deep look at InvisiBot's findings yet, but found out my device is indeed an exact clone of x70 (C6F9), first flash the recovery.fls, got a landscape 3e stock recovery instead of the original portrait, then proceed to flash the system.fls, everything works except for bluetooth & wifi, last flash the boot.fls & now i got x70 (C6F9) ROM fully working on my device... :laugh:
i guess intel/ Teclast must have made some improvement to libhoudini, overall, it performs better than the original stock ROM with Xposed installed & with zram enabled ...
Updates
Guys, as i've always mentioned it on my other threads, users always feedback it doesn't work, pls describe every little steps that you took, it will be easier to trouble-shoot, narrow things down & solve your problems....
According to InvisiBot, he began experiment by Hex editing partition ImcPartID022 & that bricks his x70 & in doing so he found out there is a hidden feature that you can still download by holding the Power button for 10 seconds then release it & FlashTool_E2 will automatically start to download on your brick device, this mean intel x3 is truly unbrickable... :good:
Thats where he discovered that you guys use the erase whole flash at FlashTool_E2 & that erases the IMEI info, luckily he manage to get his IMEI back...
View attachment 3478674
WARNING : Never use both the erase whole flash option, it will delete your IMEI info ! You guys with the IMEI problem never even once mentioned that...
Conclusion
Indeed the partition ImcPartID022 contains both the IMEI info, device serial number & adb command => adb devices serial no. which is the same as SIM 1, good job InvisiBot... :good:
Code:
[COLOR="blue"]Setttings[/COLOR] => [COLOR="blue"]About tablet [/COLOR]=> [COLOR="blue"]Status [/COLOR]=> [COLOR="blue"]SIM 1[/COLOR]/ [COLOR="blue"]SIM 2[/COLOR]
On my x70 clone or shall i say an actual x70 (C6F9) rebrand, the offset is at different location.
Device serial no => 0x1AAC8
SIM 1 => 0x24360
SIM 2 => 0x2436C
adb command => adb devices serial no => 0x2549C
So do make a backup of partition ImcPartID022, this is the only partition that FlashTool_E2 cannot restore if you brick it.
Attention to InvisiBot
Since you said you're making a How-to Guide i'm not going to spoil the soup... :laugh: Don't forget to make one in English Language for sharing with XDA member here too... :good:
Attach below is my empty IMEI for your R&D, i think it should be the same as X70 C6F9...
View attachment EMPTY-C6F9-IMEI.zip
Search for the reference text as below
#IMEI01#
#IMEI02#
#ADB-SN#
##INTEL-X3-S/N## <= This is the 16 digit alphanumeric Serial number display at Settings => SIM1/ SIM2
Updates - Restore invalid IMEI
For those who lost their IMEI, you can try this Thanks to Invisibot & buxbux for the link... :good:
Don't ask me how-to, i've never loose my IMEI before so i donno how to use it, you'll have to find that out yourself...

[Guides & Links] how to root ASUS ZenPad 3 8.0 (Z581KL)

This procedure supplements what was posted on 2ch.
this procedure is for firmware v3.3.18 or less.
If your firmware is v3.3.20, you may be able to downgrade to v3.3.18 with the procedure described at the end of this post.
for necessary files, download from the follwoing URL.
hZtZtpsZ://wZwZwZ.axfc.net/u/3777377
Z←remove
(PASS Z581KL)　(差分＝Difference，キーワード＝KEYWORD，ダウンロード＝Download，こちら＝HERE，cacheに置くもの＝Things to put in the cache)
1.extract boot image
turn on debug mode.
then, reboot recovery mode.
Code:
$ adb reboot recovery
after that, mount the system using the terminal volume button and the power button.
Code:
$ adb push dirtycow /tmp/
$ adb push run-as /tmp/
$ adb shell
[email protected]_1:/ $ cd /tmp
[email protected]_1:/tmp $ chmod 777 dirtycow
[email protected]_1:/tmp $ chmod 777 run-as
[email protected]_1:/tmp $ ./dirtycow ./run-as /system/bin/run-as
[email protected]_1:/tmp $ run-as
[email protected]_1:/tmp # dd if=/dev/block/mmcblk0p41 of=/tmp/boot.img
[email protected]_1:/tmp # chmod 777 /tmp/boot.img
[email protected]_1:/tmp # exit
[email protected]_1:/tmp $ exit
transfer boot.img to PC.
Code:
$ adb pull /tmp/boot.img ./
2.unpacking the boot.img
"mkbootimg_tools-master" is useful because it outputs log of ramdisk size.
(However, binary "mkbootfs" and "mkbootimg" are 32-bit versions.
if your environment is 64-bit, you need to bring 64-bit binaries from CarlivImageKitchen64 etc)
for example, using mkbootimg_tools-master looks like this:
Code:
$ ./mkboot bootimg_source/boot.img bootimg_output
Unpack & decompress bootimg_source/boot.img to bootimg_output
kernel : kernel
ramdisk : ramdisk
page size : 2048
kernel size : 29041019
[COLOR="Red"]ramdisk size : 2924316 <- refer to this value later[/COLOR]
base : 0x80000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 earlyprintk vmalloc=256M build_version=3
ramdisk is gzip format.
Unpack completed.
directories after unpacking boot.img looks like this:
bootimg_output
|--ramdisk
|--kernel
`--others(img_info,ramdisk.packed,etc)
3.install SuperSU manually
overwrite the contents of "initrd差分.7z" under directory "ramdisk".
("su" is an empty directory, but also to put it under "ramdisk")
(for "sbin", you only need to add launch_daemon.sh without deleting the existing files)
(permissions on files/directories should be the same as original or other file/directories)
4.repacking the boot.img
for example, using mkbootimg_tools-master looks like this:
Code:
$ ./mkboot bootimg_output boot_patched.img
mkbootimg from bootimg_output/img_info.
kernel : kernel
ramdisk : new_ramdisk
page size : 2048
kernel size : 29041019
ramdisk size : 2924316
base : 0x80000000
kernel offset : 0x00008000
ramdisk offset : 0x01000000
tags offset : 0x00000100
cmd line : console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom msm_rtb.filter=0x237 ehci-hcd.park=3 androidboot.bootdevice=7824900.sdhci lpm_levels.sleep_disabled=1 earlyprintk vmalloc=256M build_version=3
ramdisk is gzip format.
Repack image utility by [email protected]
Check and add the kernel
Check and add the ramdisk
Build the new image
'boot_patched.img' successfully repacked
Kernel size: 29041019, [COLOR="Magenta"][COLOR="Red"]new ramdisk size: 2924316[/COLOR][/COLOR], test_patched.img: 31969280.
test_patched.img has been created.
...
at this time, it is necessary to adjust so that the value of "new ramdisk size" becomes
the same value as "ramdisk size" when unpack.
if the size of "ramdisk" is different from when unpacked, Z581KL will not start.
therefore, deleting unnnecessary files stored under ramdisk/res/images/charger and adding dummy files.
(the difference of about several bytes seems to be no problem)
(once wrong boot.img is written, Z581KL will no start until you write the original boot.img)
however, the size of the original boot.img and the modified boot.img can be different.
(in my environment, the original boot.img was about 67MB, while the modifyed boot.img was
about 32MB)
5.insert modified boot.img
using dirtycow, adb push, and dd, insert the modified boot.img into the /dev/block/mmcblk0p41
also, put "su.img" and "SuperSU.apk" in /cache
then,reboot Z581KL.
"Verification Error" is always displayed when starting up, but if you wait for a while
it will start normally.
that's all.
**********************
Firmware downgrade procedure
1. your firmware is v3.3.20.0
2. download firmware from asus's support page. (UL-P008-WW-3.3.18.0-user.zip)
3. rename the zip file ( UL-P008-WW-3.3.18.0-user.zip -> UL-P008-WW-5.3.9.0-user.zip )
4. Place the zip file in an arbitrary directory on the SD card and insert this SD card into Z581KL
5. The update dialog is displayed as it is ( or it is displayed when restarted )
If the firmware is v 5 or higher (currently v 5.3.9.0 is published),
this procedure may indicate an error and the downgrade may fail.
In that case, for now I have no choice but to give up ...

I am sorry if my comment sounds unprofessional. Can you express steps 2-5 in a vulgar manner. Is mkbootimg a tool? ttps://forum.xda-developers.com/android/software-hacking/development-mkbootimg-tools-t2895954

I am experiencing permission denied while performing: adb pull /tmp/boot.img ./
i.imgur.com/TSO0v1g.png

About mkbootimg it is right.
Download all files with ZIP from GitHub's "Clone or download" button described in that URL.
About "adb pull" command, sorry.
Before doing it, you need to change the permissions of boot.img to 777.
[email protected]_1:/tmp # dd if=/dev/block/mmcblk0p41 of=/tmp/boot.img
[email protected]_1:/tmp # chmod 777 /tmp/boot.img
[email protected]_1:/tmp # exit
[email protected]_1:/tmp $ exit

By the way, I would like you to tell me.
Is there a procedure like this that you successfully downgraded the firmware?
1. your firmware is v3.3.20.0
2. download firmware from asus's support page. (UL-P008-WW-3.3.18.0-user.zip)
3. rename the zip file ( UL-P008-WW-3.3.18.0-user.zip -> UL-P008-WW-5.3.9.0-user.zip )
4. Place the zip file in an arbitrary directory on the SD card and insert this SD card into Z581KL
5. The update dialog is displayed as it is ( or is it displayed when restarted? )

yamada_2501 said:
By the way, I would like you to tell me.
Is there a procedure like this that you successfully downgraded the firmware?
1. your firmware is v3.3.20.0
2. download firmware from asus's support page. (UL-P008-WW-3.3.18.0-user.zip)
3. rename the zip file ( UL-P008-WW-3.3.18.0-user.zip -> UL-P008-WW-5.3.9.0-user.zip )
4. Place the zip file in an arbitrary directory on the SD card and insert this SD card into Z581KL
5. The update dialog is displayed as it is ( or is it displayed when restarted? )
Click to expand...
Click to collapse
Correct. This is exactly what I've done. My factory firmware was v3.3.20.0. I downloaded the 3.3.18.0 firmware from ASUS website and rename it to the 5.3.9.0 firmware. I was able to downgrade the system using the standard procedures.
---------- Post added at 04:11 AM ---------- Previous post was at 03:55 AM ----------
yamada_2501 said:
About mkbootimg it is right.
Download all files with ZIP from GitHub's "Clone or download" button described in that URL.
About "adb pull" command, sorry.
Before doing it, you need to change the permissions of boot.img to 777.
[email protected]_1:/tmp # dd if=/dev/block/mmcblk0p41 of=/tmp/boot.img
[email protected]_1:/tmp # chmod 777 /tmp/boot.img
[email protected]_1:/tmp # exit
[email protected]_1:/tmp $ exit
Click to expand...
Click to collapse
Thank you. I was able to successfully pull that boot.img. However, is there any mkbootimg alternative for windows. It seems like a linux system tool.
---------- Post added at 04:20 AM ---------- Previous post was at 04:11 AM ----------
yamada_2501 said:
About mkbootimg it is right.
Download all files with ZIP from GitHub's "Clone or download" button described in that URL.
About "adb pull" command, sorry.
Before doing it, you need to change the permissions of boot.img to 777.
[email protected]_1:/tmp # dd if=/dev/block/mmcblk0p41 of=/tmp/boot.img
[email protected]_1:/tmp # chmod 777 /tmp/boot.img
[email protected]_1:/tmp # exit
[email protected]_1:/tmp $ exit
Click to expand...
Click to collapse
I was able to find this post (ttps://forum.xda-developers.com/redmi-1s/general/guide-unpack-repack-kernel-t2908458). I am not sure if it work. Would you please verify and please post the steps. When I use this tool, I am getting a intrid folder instead of ramdisk folder as describe in your post. The link below is what I have. The red boxed files are the original files. Green arrowed file is the original boot.img
i.imgur.com/8d05Zis.png
Also, would you please provide the codes you used in step 5.
Update:
I was somehow able to push boot.img and the other two files in by modifying step 1's code. However, I think the boot.img I created has an error. Perhaps because of sizing error. I am not able to start the machine. Now, is stuck at fastboot options menu. How can I get back to the recovery menu and perhaps push the original boot.img back.

If you connect to the PC with the fastboot menu activated,
and execute the " fastboot reboot recovery " command on the PC,
will not you get to the recovery menu?

yamada_2501 said:
If you connect to the PC with the fastboot menu activated,
and execute the " fastboot reboot recovery " command on the PC,
will not you get to the recovery menu?
Click to expand...
Click to collapse
No, when I execute that command, it shows me a bunch of options as shown in the screenshot below.
i.imgur.com/ZJsh5Ub.png

Sorry, I can only think about this as other means....
1.Power off your device
2.pressing and holding Volume Down and Power Button at the same time
3.Boot in recovery mode
1.Power off your device
2.pressing and holding Volume Up and Power Button at the same time
3.Boot in Fast boot options menu
4.select "USB debug mode"
１．Boot in Fast boot options menu
2.Use fastboot command from PC to start Z581KL from original boot.img on PC
-> fastboot boot ./boot.img

yamada_2501 said:
Sorry, I can only think about this as other means....
1.Power off your device
2.pressing and holding Volume Down and Power Button at the same time
3.Boot in recovery mode
1.Power off your device
2.pressing and holding Volume Up and Power Button at the same time
3.Boot in Fast boot options menu
4.select "USB debug mode"
１．Boot in Fast boot options menu
2.Use fastboot command from PC to start Z581KL from original boot.img on PC
-> fastboot boot ./boot.img
Click to expand...
Click to collapse
The combination button will not get me to the recovery mode. USB debugging mode requires a OS system. I've been trying to flash/boot the original boot.img from my computer but it has some permission error.
i.imgur.com/rmK65Z9.png
Is it possible to get this permission error fix and flash or boot the original boot.img?

I already upgraded to Nougat 5.3.9.0. Could I downgrade to 3.3.18 without bricking it?

I could get blueborne to work on JP_V5.5.0_220170616.
But shell whose uid=bluetooth is seemingly useless for rooting...
Does anyone know how to get root from bluetooth shell?

is there any guide to flash a ww rom over operator rom?
thanks

How to insert the modified boot.img into the /dev/block/mmcblk0p41 by using dirtycow, adb push, and dd?

tomo_ward said:
How to insert the modified boot.img into the /dev/block/mmcblk0p41 by using dirtycow, adb push, and dd?
Click to expand...
Click to collapse
His original instruction left out commands to acquire permission to access boot.img. Read the reply threads between yamada and me. He addressed the instruction to acquire the permission. In order to insert the modified boot.img, you re-execute step 1, but instead of doing an adb pull on the last command of step 1, do an adb push.
However, the issue of this guide is the fact that you need to push the boot.img out, unpack and repack it. The risk of this is that the chance of you getting wrong modified size boot.img. There is no way to re-acquire permission to replace the wrong boot.img with the original one once you can't boot into the system; therefore, you end up with a Z581Kl that just do not boot. I had to send mine Z581KL back to factory in order to fix the effect.
If you are willing to take the risk and does success, please provide the boot.img you have successfully modified. That will definitely be a gospel.

thank you.
I'll try to get Root my Z581KL

Should I change file permission of patched_boot.img before run "dd" command?
[email protected]_1:/tmp # chmod 777 /tmp/patched_boot.img #Do I need?
[email protected]_1:/tmp # dd if=/tmp/patched_boot.img of=/dev/block/mmcblk0p41

Was anyone able to get a boot.img that works?

Cannot download the needed ZIP file.
Any backup?

Uqbar said:
Cannot download the needed ZIP file.
Any backup?
Click to expand...
Click to collapse
None has it any more?

LG G4 fails to complete LOS 14.1 boot after battery drained to zero [Fixed]

The battery of a rooted, UsUed LG G4 running LineageOS 14.1 was accidentally allowed to drain to zero. After re-charging above 50%, the device failed to boot. The LOS boot screen "bubble on a string" animation would continue indefinitely.
The phone still booted to TWRP, download mode, and fastboot mode.
Originally, it was suspected that this was ILAPO. However, this suspicion was incorrect.
After extensive work creating a boot sector that would allow logging and a ton of help from @steadfasterX, it was discovered that various files in /data/system had been corrupted and had sizes of zero. Android would try to read values from these files, fail, and repeat.
First, a full TWRP backup of the phone was made and copied off-device. Then, I made a second backup of /data/system. Next, I deleted the following zero-byte files from /data/system using TWRP (or ADB after launching TWRP).
packages.list
packages.xml
profiles.xml
netpolicy.xml
notification_policy.xml
If this doesn't work, I would have considered deleting other zero-byte files in /data/system. I used "ls -laS" to get a size-ordered list of files in my current directory.
After a reboot, android re-created the files and booted to the lockscreen.
All of the apps in /data/data had already been cleared. Otherwise, Android would probably have choked on the differences between the user IDs that it wanted to assign to apps and the ownership of the various app folders.
The following links suggest ways to restore some apps from previously created backups
GitHub - joshuabragge/twrp-manual-restore: Automate individual app restores from an android TWRP backup
Automate individual app restores from an android TWRP backup - GitHub - joshuabragge/twrp-manual-restore: Automate individual app restores from an android TWRP backup
github.com
https://www.semipol.de/posts/2016/07/android-manually-restoring-apps-from-a-twrp-backup/
(Permanent archive: https://web.archive.org/web/2019083.../android-restoring-apps-from-twrp-backup.html)
There is no warranty on this solution. It was a makeshift effort created by an amateur. If you choose to duplicate it, you do so at your own risk. You may permanently destroy your phone.
Old post below:
I'm trying to understand whether a particular G4 (H815) has ILAPO. Its been sneezing, has a sore throat, and now can't taste anything^H^H oops, I mean:
- Previously, the phone would get hot during use.
- The phone has been UsUed.
- The battery was accidentally allowed to discharge to zero.
- After the battery was recharged, the phone was unable to boot past the Lineageos "bubble on a string" animation. The animation simply continues forever.
- The phone can boot to TWRP, fasboot, download mode, etc.
Attempts to fix:
- Tried renaming /sdcard/Android to /sdcard/Android.old but this had no effect.
- Tried clearing cache and dalvik cache but this had no effect
- (NEW) Tried attaching to computer and launching "adb logcat" during animation. Device is never found. If I remember correctly, "USB debugging" was off when the device died. (ADB does work in TWRP.)
- (NEW) Tried creating a custom 4-core (2 core for boot) boot image using the instructions here https://forum.xda-developers.com/t/...tom-x-cores-boot-image-ilapo-tempfix.3718389/ and used "fastboot flash boot boot.img" to flash it. This doesn't seem to work.
-- If I reboot into TWRP after a long period of waiting for the lineageos splash screen, I get a CPU temperature of 46 C. I don't know what temperature was generated in the same situation the modified boot image was installed.
Most of the info on ILAPO suggests that phones with it can't get past the LG logo. That is not the case here. Is this ILAPO or something different? Does anyone have ideas as to what might be an appropriate fix?
Is it possible to retrieve boot logs using TWRP in order to figure out when/where/why the boot hangs?

electricfield said:
I'm trying to understand whether a particular G4 (H815) has ILAPO. Its been sneezing, has a sore throat, and now can't taste anything^H^H oops, I mean:
- Previously, the phone would get hot during use.
- The phone has been UsUed.
- The battery was accidentally allowed to discharge to zero.
- After the battery was recharged, the phone was unable to boot past the Lineageos "bubble on a string" animation. The animation simply continues forever.
- The phone can boot to TWRP, fasboot, download mode, etc.
Attempts to fix:
- Tried renaming /sdcard/Android to /sdcard/Android.old but this had no effect.
- Tried clearing cache and dalvik cache but this had no effect
- (NEW) Tried attaching to computer and launching "adb logcat" during animation. Device is never found. If I remember correctly, "USB debugging" was off when the device died. (ADB does work in TWRP.)
- (NEW) Tried creating a custom 4-core (2 core for boot) boot image using the instructions here https://forum.xda-developers.com/t/...tom-x-cores-boot-image-ilapo-tempfix.3718389/ and used "fastboot flash boot boot.img" to flash it. This doesn't seem to work.
-- If I reboot into TWRP after a long period of waiting for the lineageos splash screen, I get a CPU temperature of 46 C. I don't know what temperature was generated in the same situation the modified boot image was installed.
Most of the info on ILAPO suggests that phones with it can't get past the LG logo. That is not the case here. Is this ILAPO or something different? Does anyone have ideas as to what might be an appropriate fix?
Is it possible to retrieve boot logs using TWRP in order to figure out when/where/why the boot hangs?
Click to expand...
Click to collapse
Sounds like the ilapo. Is the battery charged now? I don't know which LOS version you have installed but if you use mine:
follow FAQ #7 of my LOS thread

steadfasterX said:
Sounds like the ilapo. Is the battery charged now? I don't know which LOS version you have installed but if you use mine:
follow FAQ #7 of my LOS thread
Click to expand...
Click to collapse
Thank you for your reply. You seem to know more about G4 issues than anyone. I really appreciate your help.
The battery is charged now.
Unfortunately, I am using the microg version of LOS 14.1, rather than your 16.0.
I tried following the instructions in your FAQ #7, but I can't do step 1 (boot android). The only way for me to exit the bootloop is by removing the battery. There is no "debug" in /cache after I mount cache in TWRP.
I also looked at FAQ #1. ADB never finishes waiting for the device. In fact "lsusb" doesn't show the phone during OS boot (ADB is fine when TWRP is loaded).
Any other ideas?

electricfield said:
Thank you for your reply. You seem to know more about G4 issues than anyone. I really appreciate your help.
The battery is charged now.
Unfortunately, I am using the microg version of LOS 14.1, rather than your 16.0.
I tried following the instructions in your FAQ #7, but I can't do step 1 (boot android). The only way for me to exit the bootloop is by removing the battery. There is no "debug" in /cache after I mount cache in TWRP.
I also looked at FAQ #1. ADB never finishes waiting for the device. In fact "lsusb" doesn't show the phone during OS boot (ADB is fine when TWRP is loaded).
Any other ideas?
Click to expand...
Click to collapse
As written in my mentioned FAQ taken battery out is needed in your case. Step 2 iirc.
If you dont use my LOS then no way. The cache/debug is something I've added and no one else has.
Option1:
You can just flash my LOS 16 or /e/ ROM (take a full backup before in TWRP) and use that for debugging your current issue. Why using microg btw? /e/ is great
Option2:
The other option would be pulling the boot img of your current LOS (in TWRP: adb pull /dev/block/bootdevice/by-name/boot ) and rebuilding it as insecure (i.e. usb debug on and adb root ) but if you never did that before it it will be hard i guess. AiK might work here or using mAid which includes bootimgtool.
Option3:
Also you can attach that boot img here and if i ever find the time i can do option2 for you but don't expext that this happens soon .

Thank you again for your help.
I'm a little afraid that installing a new & different ROM will increase the level of complexity. I'll do it if I must, though.
I started looking at option #2. Retrieving the boot image was fine, but unpacking presents a problem.
$ ./unpack-bootimg.sh boot.img.original
Found a secondary file after the ramdisk image. According to the spec (mkbootimg.h) this file can exist, but this script is not designed to deal with this scenario.
Is there a guide anywhere?

electricfield said:
Thank you again for your help.
I'm a little afraid that installing a new & different ROM will increase the level of complexity. I'll do it if I must, though.
I started looking at option #2. Retrieving the boot image was fine, but unpacking presents a problem.
$ ./unpack-bootimg.sh boot.img.original
Found a secondary file after the ramdisk image. According to the spec (mkbootimg.h) this file can exist, but this script is not designed to deal with this scenario.
Is there a guide anywhere?
Click to expand...
Click to collapse
thousands.. But the problem is that our device is sensitive when it comes to packaging the boot.img again. Bootimgtool is working in 9 of 10 times though.
Boot mAid . Open a terminal. Type bootimgtool --help .important is to use "-v qcom". Then extract the ramdisk with gzip and cpio, then modding the default.prop to make it insecure , then using gzip and cpio again to rebuild the ramdisk, finally using bootimgtool to construct the boot.img again. Sounds harder than it is but i have no access to my pc until monday so i cannot give all the needed cmds atm. There are plenty of guides out there and tools ofc which allow unpack,repack etc. That's why i mentioned AIK which does exactly the above but it fails sometimes to build a correct working boot.img.
So my suggestion is try your luck with one of the tools or wait until I've access to my pc. Consider joining my TG group then for easier support (see my sig)

steadfasterX said:
thousands.. But the problem is that our device is sensitive when it comes to packaging the boot.img again. Bootimgtool is working in 9 of 10 times though.
Boot mAid . Open a terminal. Type bootimgtool --help .important is to use "-v qcom". Then extract the ramdisk with gzip and cpio, then modding the default.prop to make it insecure , then using gzip and cpio again to rebuild the ramdisk, finally using bootimgtool to construct the boot.img again. Sounds harder than it is but i have no access to my pc until monday so i cannot give all the needed cmds atm. There are plenty of guides out there and tools ofc which allow unpack,repack etc. That's why i mentioned AIK which does exactly the above but it fails sometimes to build a correct working boot.img.
So my suggestion is try your luck with one of the tools or wait until I've access to my pc. Consider joining my TG group then for easier support (see my sig)
Click to expand...
Click to collapse
Thank you once again. I'm really impressed by how much help you have been able to give so far.
Unfortunately, I have no phone with which to join the Telegram group.
I made the modified boot image, but adb is still unable to speak to the phone during boot. I note that lsusb does not show the phone during boot -- maybe the system hangs before USB is activated. However, I could have made the boot image incorrectly.
Here is what I did:
[[email protected] extract]$ bootimgtool -i boot
Image size: 41943040
Page size: 4096
Kernel size: 22456976
Ramdisk size: 1672742
Second stage size: 0
Device tree size: 0
Kernel load address: 0x00008000
Ramdisk load address: 0x01000000
Second stage load address: 0x00f00000
Device tree load address: 0x00000000
Tags load address: 0x00000100
Product name:
Command line: maxcpus=4 boot_cpus=0-1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x37 boot_cpus=0-1 buildvariant=userdebug
[[email protected] extract]$ bootimgtool -x boot -v qcom
[[email protected] extract]$ gunzip ramdisk
[[email protected] ex]$ cpio -i < ../ramdisk
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
In default.prop, I added:
persist.service.adb.enable=1
persist.service.debuggable=1
[[email protected] ex]$ find > /tmp/filelist
[[email protected] ex]$ cpio -o < /tmp/filelist > ../ramdisk.modified
This produces
-rw-r--r-- 1 android users 4166400 Jan 2 17:29 ramdisk.gunzip.original
-rw-r--r-- 1 android users 4162048 Jan 2 17:31 ramdisk.modified
-rw-r--r-- 1 android users 1672742 Jan 2 17:16 ramdisk.img.original
I don't understand why the "modified" gunzipped file is slightly smaller than the original.
[[email protected] extract]$ mv ramdisk.modified.gz ramdisk.img
[[email protected] extract]$ cp boot boot.original
[[email protected] extract]$ bootimgtool -v qcom -c boot
Overwrite 'boot'? [y/N] y
-rw-r--r-- 1 android users 25370624 Jan 2 17:38 boot
-rw-r--r-- 1 android users 41943040 Jan 2 17:37 boot.original
I am wary because I don't understand why the new file is so much smaller than the original. However, I decided to proceed. Uploaded modified boot to /sdcard/boot.modified
Inside adb:
/dev/block/platform/soc.0/f9824900.sdhci/by-name # ls -al boot
lrwxrwxrwx 1 root root 21 Jan 1 04:16 boot -> /dev/block/mmcblk0p38
/dev/block/platform/soc.0/f9824900.sdhci/by-name # cp /sdcard/boot.modified /dev/block/mmcblk0p38
Plugged in device. On computer "adb wait-for-device". Reboot device.
Unfortunately, no action from adb.

electricfield said:
Thank you once again. I'm really impressed by how much help you have been able to give so far.
Unfortunately, I have no phone with which to join the Telegram group.
I made the modified boot image, but adb is still unable to speak to the phone during boot. I note that lsusb does not show the phone during boot -- maybe the system hangs before USB is activated. However, I could have made the boot image incorrectly.
Here is what I did:
[[email protected] extract]$ bootimgtool -i boot
Image size: 41943040
Page size: 4096
Kernel size: 22456976
Ramdisk size: 1672742
Second stage size: 0
Device tree size: 0
Kernel load address: 0x00008000
Ramdisk load address: 0x01000000
Second stage load address: 0x00f00000
Device tree load address: 0x00000000
Tags load address: 0x00000100
Product name:
Command line: maxcpus=4 boot_cpus=0-1 console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 msm_rtb.filter=0x37 boot_cpus=0-1 buildvariant=userdebug
[[email protected] extract]$ bootimgtool -x boot -v qcom
[[email protected] extract]$ gunzip ramdisk
[[email protected] ex]$ cpio -i < ../ramdisk
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
In default.prop, I added:
persist.service.adb.enable=1
persist.service.debuggable=1
[[email protected] ex]$ find > /tmp/filelist
[[email protected] ex]$ cpio -o < /tmp/filelist > ../ramdisk.modified
This produces
-rw-r--r-- 1 android users 4166400 Jan 2 17:29 ramdisk.gunzip.original
-rw-r--r-- 1 android users 4162048 Jan 2 17:31 ramdisk.modified
-rw-r--r-- 1 android users 1672742 Jan 2 17:16 ramdisk.img.original
I don't understand why the "modified" gunzipped file is slightly smaller than the original.
[[email protected] extract]$ mv ramdisk.modified.gz ramdisk.img
[[email protected] extract]$ cp boot boot.original
[[email protected] extract]$ bootimgtool -v qcom -c boot
Overwrite 'boot'? [y/N] y
-rw-r--r-- 1 android users 25370624 Jan 2 17:38 boot
-rw-r--r-- 1 android users 41943040 Jan 2 17:37 boot.original
I am wary because I don't understand why the new file is so much smaller than the original. However, I decided to proceed. Uploaded modified boot to /sdcard/boot.modified
Inside adb:
/dev/block/platform/soc.0/f9824900.sdhci/by-name # ls -al boot
lrwxrwxrwx 1 root root 21 Jan 1 04:16 boot -> /dev/block/mmcblk0p38
/dev/block/platform/soc.0/f9824900.sdhci/by-name # cp /sdcard/boot.modified /dev/block/mmcblk0p38
Plugged in device. On computer "adb wait-for-device". Reboot device.
Unfortunately, no action from adb.
Click to expand...
Click to collapse
Ok i haven't followed every step bc I'm in half sleep mode already but you did one step wrong : you cant use cp like you did to copy the boot img. Either use the IMG button within TWRP flash menu or use fastboot flash boot boot.img to actually flash the modded boot img

Thank you, once again.
I think that something must be wrong with the boot image.
After "fastboot flash boot boot.modified", I get a blue light. The screen is blank with a cursor in the upper-left hand corner.
"fastboot flash boot boot.original" restores it to its previous state. i.e., it gets to the first lineageos splash screen bubble.
I'm suspicious of the difference between the file sizes of the original and modified boot images.

electricfield said:
Thank you, once again.
I think that something must be wrong with the boot image.
After "fastboot flash boot boot.modified", I get a blue light. The screen is blank with a cursor in the upper-left hand corner.
"fastboot flash boot boot.original" restores it to its previous state. i.e., it gets to the first lineageos splash screen bubble.
I'm suspicious of the difference between the file sizes of the original and modified boot images.
Click to expand...
Click to collapse
Ignore the size diff. That's bc of diff compressing tools but does not matter. Your cpio cmd is unusual . Cpio has switches to create directories and that is not used in yours above . Thats likely the reason why it does not boot at all. Again sorry that i can't help better atm but without my pc..

Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1

electricfield said:
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
Click to expand...
Click to collapse
ro.debuggable=1 is better (allows adb root)
security.perf_harden shouldn't be added (or.changed if it was there)
Rest looks ok. At least as long as you really changed these values directly or added them at the top (ro. values can be set only once)
Otherwise you should wait until tomorrow then i can share a 100% working way

electricfield said:
Thanks.
I changed the ramdisk extraction command to:
gzip -dc ../ramdisk.img | cpio -imd
and the creation command to:
find . ! -name . | LC_ALL=C sort | cpio -o -H newc -R root:root | gzip > ../new-boot.img-ramdisk.gz
Bootimgtool then produced a boot image that booted. After fastboot flash, the device is in the same state as before (splash screen).
Unfortunately, "adb wait-for-device" produces nothing. "lsusb" does not show the phone.
Can you confirm the lines to change in default.prop?
In default.prop, I changed:
ro.adb.secure=0
ro.secure=0
security.perf_harden=0
ro.debuggable=0
persist.sys.usb.config=mtp,adb
I added:
persist.service.adb.enable=1
persist.service.debuggable=1
Click to expand...
Click to collapse
Oh wait! Pls share the bootimgtool command you are using to create the new boot.img

Thank you, again.
The bootimgtool command is the same one as I used before (no change). Before running it, I renamed the new ramdisk to ramdisk.img.
bootimgtool -v qcom -c boot.modified3
Followed by bringing the phone into fastboot mode and running
fastboot flash boot boot.modified3
The phone boots to the lineageos splash screen but no response to "adb wait-for-device".
I'll try ro.debuggable=1 and get rid of security.perf_harden in a few minutes, but I wonder if they are unlikely to change anything given that the device does not show up in (linux) lsusb.

electricfield said:
Thank you, again.
The bootimgtool command is the same one as I used before (no change). Before running it, I renamed the new ramdisk to ramdisk.img.
bootimgtool -v qcom -c boot.modified3
Followed by bringing the phone into fastboot mode and running
fastboot flash boot boot.modified3
The phone boots to the lineageos splash screen but no response to "adb wait-for-device".
I'll try ro.debuggable=1 and get rid of security.perf_harden in a few minutes, but I wonder if they are unlikely to change anything given that the device does not show up in (linux) lsusb.
Click to expand...
Click to collapse
That wont change anything if adb does not come up. Just for completeness.
Ok so if you renamed it to ramdisk.img then all.good that was the thing i had in mind (that you didn't and not.used the -r switch). Well ok then without my pc the only thing i can think of might be the USB cable but thats very unlikely

Thanks again for your help.
The boot image that was flashed is definitely the correct one. I extracted it to another folder and checked it before flashing.
I re-made the boot image, but the result is the same (no adb, no device in lsusb).
What "-r switch" are you referring to in your previous message?
The USB cable works fine for ADB in TWRP, so I doubt it is the problem.

electricfield said:
Thanks again for your help.
The boot image that was flashed is definitely the correct one. I extracted it to another folder and checked it before flashing.
I re-made the boot image, but the result is the same (no adb, no device in lsusb).
What "-r switch" are you referring to in your previous message?
The USB cable works fine for ADB in TWRP, so I doubt it is the problem.
Click to expand...
Click to collapse
The -r (iirc) switch was related to bootimgtool. That way you can choose your newly created ramdisk.img but when you renamed it to ramdisk.img it works without.

Thanks.
I would deeply appreciate if you were able to guide me in making the boot image correctly when you have your computer on Monday.
On the other hand, if this method won't work, its best if I know that so that I can try the next thing....

electricfield said:
Thanks.
I would deeply appreciate if you were able to guide me in making the boot image correctly when you have your computer on Monday.
On the other hand, if this method won't work, its best if I know that so that I can try the next thing....
Click to expand...
Click to collapse
ok here you go, this must be added /changed in default.prop:
Code:
ro.adb.secure=0
ro.secure=0
ro.debuggable=1
persist.service.adb.enable=1
persist.service.debuggable=1
persist.sys.usb.config=adb
thumbs pressed

Thank you.
I rebuilt the boot image with these entries, but "adb wait-for-device" still does not work during boot.
Any other ideas?

Develop Bugs

welcome