Question QCOM Diag port - Moto G Power (2021)

Does anyone know how to get the QCOM modem diag port working on this phone? QCOM Mode and BP Tools are missing from the bootloader menu, fastboot oem config bootmode qcom returns "Not allowed command", and even setprop usb.sys.config diag,adb doesn't work.

Related

"Enable OEM Unlock" in developer options.

What does this actually do to tell the bootloader that it is ok to unlock.
Write a 1 byte file to the system partition?
Write one byte of the bootloader?
Searching google just gave "How to Enable OEM Unlock to unlock your bootloader" articles nothing on how it actually works.
Finally found out how it works.
While trying to find my screen resolution while offline I checked getprop with terminal and sys.oem_unlock_allowed [1] came up.
I then checked /dev/__properties__ and it was there so it is enable by writing sys.oem_unlock_allowed = 1 to /dev/__properties__
Guicrith said:
Finally found out how it works.
While trying to find my screen resolution while offline I checked getprop with terminal and sys.oem_unlock_allowed [1] came up.
I then checked /dev/__properties__ and it was there so it is enable by writing sys.oem_unlock_allowed = 1 to /dev/__properties__
Click to expand...
Click to collapse
Is there any way to prevent a user from accidentally disabling this option in Developer options?
I am asking because if you disable "OEM unlock" after installing a custom ROM in eg. a Samsung phone, the device refuses to boot with a FRP "Custom binary blocked by FRP lock" message.
timba123 said:
I'm on samsung a102u . The galaxy a10e. I added sys.oem_unlock_allowed 1 but now both sys.oem_unlock_allowed 0 and sys.oem_unlock_allowed 1 both are showing up. Is there a command to remove the sys.oem_unlock_allowed 0
Click to expand...
Click to collapse
Well actually the first one is indeed sys.oem_unlock_allowed but the second one is sys.oem_unlocl_allowed so those are not the same: probably you made a typo when adding it and thus it didn't just change the original prop's value but added a new, mistyped prop with the desired value? The K and L buttons on a QWERTY or similar keyboard are next to each other (and the Levenshtein distance between the names of the two props is only 1).
This is an excellent resource for information on bootloader unlock ability.
There are several components at play here:
ro.oem_unlock_supported is set at ROM build time; if 1, the OEM Unlocking toggle should be available. This property is not visible without root.
sys.oem_unlock_allowed is used by some "permissive" devices such as the Google Pixel to determine whether OEM unlocking should be allowed; in the case of the Pixel, this is done by checking an online whitelist of serial numbers
get_unlock_ability is controlled by the OEM Unlocking toggle. Off is 0, on is 1. If 0, the bootloader will reject fastboot flashing unlock. Can be checked in bootloader mode using ADB: fastboot flashing get_unlock_ability

My device is not detected in download mode on linux

I have redmi 3 pro and I'm using manjaro linux, I don't have Windows installed on my computer. When I boot my device into download mode lsusb recognizes my device as:
Code:
Bus 001 Device 010: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
But when I type in the command fastboot devices it doesn't show anything, so I can't flash any ROMs in download mode.
Meanwhile when my device is in fastboot mode, lsusb shows:
Code:
Bus 001 Device 012: ID 18d1:d00d Google Inc.
and fastboot devices shows:
Code:
72ee6d057d03 fastboot
How can the command fastboot detect my device in download mode?
hillz said:
I have redmi 3 pro and I'm using manjaro linux, I don't have Windows installed on my computer. When I boot my device into download mode lsusb recognizes my device as:
Code:
Bus 001 Device 010: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode)
But when I type in the command fastboot devices it doesn't show anything, so I can't flash any ROMs in download mode.
Meanwhile when my device is in fastboot mode, lsusb shows:
Code:
Bus 001 Device 012: ID 18d1:d00d Google Inc.
and fastboot devices shows:
Code:
72ee6d057d03 fastboot
How can the command fastboot detect my device in download mode?
Click to expand...
Click to collapse
Perhaps has something to do with your udev rules? Make sure they are set up properly.
Sent from my SM-G800F using Tapatalk

OP3: Possible brick

Hello,
This OP3 I got here, had a dm_verity error. Afterwards I used the Qualcomm way to get past that.
Now I'm getting the issue that it shows me the "Start do md5 checksum" list and there are 2 things in red (System : failed) and at the end it said md5 checksum failed.
I tried various amount of things I found all around the internet but this is what prevents them from fixing my problem:
- My lack of skill and probably knowledge
- Phone isn't oem unlocked
- Phone's partition can't be edited
- Bootloader version is empty (locked aswell, used an AIO tool to confirm)
- FastBoot is possible (volume up + power)
- I can't get into ADB sideload
- There's no TWRP or anything
There are some stuff in this list that most likely are the same thing (as I said, I lack knowledge).
I don't know what else I can do. Do you guys have an idea?
Much love,
rZergling
fastboot oem device-info gives:
Code:
Device tampered: false
Device unlocked: false
Device critical unlocked: false
Display panel:
Have console: true
Selinux type: <none>
Boot_mode: normal
Kmemleak_detext: false
Most likely USB debugging is off.

[GUIDE] Important partitions you must backup after you have the phone rooted, Stock firmware reinstallation guide at worst case

These partitions are important when you'll have to restore the phone back to normal from worst case.
Code:
elableinfo (/dev/block/sda4) - This partition contains Certification Image, may not important.
imeilock (/dev/block/sdg1) - This partition contains your device IMEI.
persist (/dev/block/sda8) - This partition contains your device PSN, MAC, Bluetooth.
oemowninfo (/dev/block/sda2) - This partition contains SKUID, exclusive info, etc.
simlock (/dev/block/sde63) - Carrier locked TA-1251 only. Mandatory to allow your phone boot if your phone isn't carrier locked.
Other Snapdragon 765G based Android phones can also refer this, although we can't guarantee it will 100% apply on your phone. DO NOT FOLLOW THIS GUIDE IF YOU ARE USING TA-1257 (NOKIA 8 V 5G UW from Verizon Wireless).
WARNING:
1. DO NOT SHARE YOUR CRITICAL PARTITION BACKUP IMAGES TO ANYONE ELSE TO PREVENT ABUSE, PLUS, SHARING THIS VIOLATES THE RULE OF XDA.
2. CRITICAL PARTITION BACKUP IMAGES FOR BOTH TA-1243 AND TA-1251 AREN'T INTERCHANGEDABLE.
Click to expand...
Click to collapse
To backup these partitions:
1. Unlock the bootloader and root your phone with Magisk.
2. Execute these commands:
Code:
adb shell mkdir /storage/emulated/0/bgt-critical/
adb shell su
(Confirm root permission on your phone - if you missed that or didn't confirm it, open Magisk app and grant it manually)
adb shell su -c dd if=/dev/block/bootdevice/by-name/imeilock of=/storage/emulated/0/bgt-critical/imeilock.img
adb shell su -c dd if=/dev/block/bootdevice/by-name/persist of=/storage/emulated/0/bgt-critical/persist.img
adb shell su -c dd if=/dev/block/bootdevice/by-name/oemowninfo of=/storage/emulated/0/bgt-critical/oemowninfo.img
adb shell su -c dd if=/dev/block/bootdevice/by-name/simlock of=/storage/emulated/0/bgt-critical/simlock.img
adb pull /storage/emulated/0/bgt-critical/
3. Save entire bgt-critical directory at safe place.
Additionally, you must do QCN backup in case you erased NVRAM at worst case.
To do that:
1. Root your phone with Magisk.
2. Execute this command on your PC with ADB shell for enabling Qualcomm Diag Port:
Code:
adb shell su -c setprop sys.usb.config diag,serial_cdev,rmnet,adb
3. Install QPST 2.7.496 and use QPST Software Download to backup both XQCN and QCN images, and save both of them at bgt-critical partition you have saved.
Here's how to reinstall stock firmware, in case you bricked the phone at worst situation.
Please disable automatic translation on your web browser if you can't click "CLICK TO SHOW CONTENT" button.
Click to expand...
Click to collapse
Assuming you have UFS lun0-lun6 erased, or the phone is currently at Qualcomm 900E which are considered worst situation.
1. Download following firmware, and extract it 3 times - you'll get tons of files inside.
bgt-2210-0-00WW-B01.HMDSW.7z | by Hikari Calyx for Generic Device/Other
Download GApps, Roms, Kernels, Themes, Firmware, and more. Free file hosting for all Android developers.
www.androidfilehost.com
2. Use text editor to open rawprogram0_sparse.xml and delete the string super.img inside to save time when doing part 1 flashing.
Use text editor to open rawprogram4.xml and replace the string abl.elf into BGT-abl.elf , then save it.
3. Copy prototype ABL into the firmware directory, and make sure the filename is BGT-abl.elf .
4A. (For Windows users)
Please install QPST 2.7.496 or newer and Qualcomm USB Driver before you proceed. You'd better to erase all other incompatible drivers to increase success rate.
Once installed, please copy QSaharaServer.exe and fh_loader.exe from QPST installation directory (C:\Program Files (x86)\Qualcomm\QPST\bin by default) to firmware directory.
4B. (For macOS / Linux users)
Please install Python EDL from following website:
GitHub - bkerler/edl: Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :)
Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :) - GitHub - bkerler/edl: Inofficial Qualcomm Firehose / Sahara / Streaming / Diag Tools :)
github.com
5. If your phone is currently at 900E, you must disassemble the phone by opening the back cover and make sure the motherboard is exposed.
Disconnect the battery, use a pair of tweezers to short the test point, then connect your phone to PC. Using USB 2.0 port is strongly recommended for best stability.
{
"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"
}
If you're using PC that only has USB 3.1 port you may like encounter USB port throttling issue. In this case you must buy an USB hub as workaround.
To check if your phone is properly connected:
(For Windows users)
Please open Device Manager and check if your phone is listed as Qualcomm HS-USB QDLoader 9008 / Qualcomm HS-USB Diagnostics 9008. If not you need to disconnect the phone, short the test point and connect the phone to PC again. Once it's listed you can remove the tweezer.
(For macOS / Linux users)
Please execute this command:
Code:
lsusb
and see if a device started from 05C6:9008 is listed. If yes, you can remove the tweezer and proceed to next step.
6A. (For Windows users)
Please check the COM port in Device Manager, assuming the COM port number is 8.
Open a Command Prompt or PowerShell window at directory where you have tons of firmware files extracted.
Execute this command (replace the COM port number to actual COM port number you see in Device Manager)
Code:
.\QSaharaServer -p \\.\COM8 -s 13:prog_firehose_ddr.elf
If you see a message says image uploaded successfully, you can proceed to next step.
Execute this command to upload rawprogram XML configuration:
Code:
.\fh_loader --port=\\.\COM8 --search_path=. --sendxml=rawprogram0_sparse.xml,rawprogram1.xml,rawprogram2.xml,rawprogram3.xml,rawprogram4.xml,rawprogram5.xml,rawprogram6.xml --noprompt --showpercentagecomplete --zlpawarehost=1 --memoryname=UFS
Wait for image files being uploaded, now write patch XML configuration:
Code:
.\fh_loader.exe --port=\\.\COM8 --search_path=. --sendxml=patch0.xml,patch1.xml,patch2.xml,patch3.xml,patch4.xml,patch5.xml,patch6.xml --noprompt --showpercentagecomplete --zlpawarehost=1 --memoryname=UFS
Once these commands are executed successfully, you can disconnect the phone, reconnect the battery and power it on.
Your phone should boot straight into Fastboot mode. If it doesn't boot the battery might be drained, recharge it a little bit before you proceed.
6B. (For macOS / Linux users)
Assuming you have Python EDL installed properly.
Open a terminal under the directory where you have firmware extracted, and execute this command:
Code:
edl qfil rawprogram0_sparse.xml,rawprogram1.xml,rawprogram2.xml,rawprogram3.xml,rawprogram4.xml,rawprogram5.xml,rawprogram6.xml patch0.xml,patch1.xml,patch2.xml,patch3.xml,patch4.xml,patch5.xml,patch6.xml /path/to/where/firmware/images/arelocated/ --memory=ufs --loader=prog_firehose_ddr.elf
Wait for image files being uploaded. If the flashing procedure is throttling, you may want to execute this command before connecting phone with test point shorted.
Once this command is executed successfully, you can disconnect the phone, reconnect the battery and power it on.
Your phone should boot straight into Fastboot mode. If it doesn't boot the battery might be drained, recharge it a little bit before you proceed.
7. Reinstall all other partitions with Fastboot command.
If you're Windows user, please DO NOT USE Minimal ADB and Fastboot, but use this instead: https://developer.android.com/studio/releases/platform-tools
Code:
fastboot flash partition:0 gpt_both0.bin
fastboot --set-active=a reboot-bootloader
fastboot flash xbl xbl.elf
fastboot flash xbl_config xbl_config.elf
fastboot flash abl abl.elf
fastboot flash tz tz.mbn
fastboot flash hyp hyp.mbn
fastboot flash devcfg devcfg.mbn
fastboot flash storsec storsec.mbn
fastboot flash pwinfo pwinfo.img
fastboot flash bluetooth BTFM.bin
fastboot flash modem NON-HLOS.bin
fastboot flash core_nhlos Core_NON-HLOS.bin
fastboot flash dsp dspso.bin
fastboot flash logfs logfs_ufs_8mb.bin
fastboot flash keymaster km4.mbn
fastboot flash featenabler featenabler.mbn
fastboot flash toolsfv tools.fv
fastboot flash metadata metadata.img
fastboot flash aop aop.mbn
fastboot flash qupfw qupv3fw.elf
fastboot flash imagefv imagefv.elf
fastboot flash uefisecapp uefi_sec.mbn
fastboot flash multiimgoem multi_image.mbn
fastboot flash vbmeta_system vbmeta_system.img
fastboot flash vbmeta vbmeta.img
fastboot flash dtbo dtbo.img
fastboot flash userdata userdata.img
fastboot flash recovery recovery.img
fastboot flash super super.img
fastboot flash boot boot.img
fastboot flash persist persist.img
By doing this will allow your phone boot as the bare minimal situation, but not ideally functional.
Next you must restore critical partitions you have backed up before.
Code:
fastboot erase fsc
fastboot erase modemst1
fastboot erase modemst2
fastboot flash fsg fs_image.img
fastboot flash elableinfo /path/to/bgt-critical/elableinfo.img
fastboot flash imeilock /path/to/bgt-critical/imeilock.img
fastboot flash persist /path/to/bgt-critical/persist.img
fastboot flash oemowninfo /path/to/bgt-critical/oemowninfo.img
fastboot reboot
8. Once your phone boots into normal OS, use Magisk to root your phone, and execute this command to enable Qualcomm Diag Port:
Code:
adb shell su -c setprop sys.usb.config diag,serial_cdev,rmnet,adb
9. (For Windows users) Use QPST Software Download to restore the QCN/XQCN image you backed up before. Eject SIM before you doing so to prevent issues.
10. (Skip if you're not using Carrier locked TA-1251) Reboot the phone into Fastboot mode and flash simlock partition:
Code:
adb reboot bootloader
fastboot flash simlock /path/to/bgt-critical/simlock.img
fastboot reboot
11. Enjoy your fully revived Nokia 8.3.
Reserved #3

Question Bootloop after C10 update

Hey,
I've recently updated my Nord 2 from A21 to C10. Phone was unlocked and rooted, so after having reflashed the original boot.img, I forced the installation of the official OTA through TWRP. I had to set ro.commonsoft.ota=OP515BL1 to make it work. After the installation, TWRP failed to mount /system, but that didn't surprised me. I checked that the boot partition has been well flashed.
Now every time I try to power on the phone, it directly tries to run into recovery mode. However it fails and start again and again...
Maybe the system tries to install the OTA using the original recovery, which of course fails, and because of an unknown reason, it doesn't reboot to system.
Because of the last update, fastboot is not accessible anymore using vol -, and BROM mode is not accessible using vol + / vol -.
I tried to crash the preloader using mtkclient but it didn't work.
I tried to use META mode to switch to fastboot, but preloader only answers "READY" (instead of "READYTOOBTSAF"), and nothing changes.
I try to reverse engineer preloader and lk but it's something new for me. META mode code is still present in the preloader, so I don't understand what's wrong with it. Maybe disabled by default on USB...
Does anyone has a solution to boot into BROM mode or make META mode work ?
Or maybe I could find DA authentication files somewhere ?
@Petitoto can you share a bit about how you got the meta command running?
I'm in a similar situation with a Nord 2T. While mtkclient can get some info out of the preloader, meta never seems to connect.
Code:
mtk gettargetconfig
Preloader - Status: Waiting for PreLoader VCOM, please connect mobile
Port - Device detected :)
Preloader - CPU: MT6893(Dimensity 1200)
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: 0xa
Preloader - Disabling Watchdog...
Preloader - HW code: 0x950
Preloader - Target config: 0x5
Preloader - SBC enabled: True
Preloader - SLA enabled: False
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: False
Preloader - Mem write auth: False
Preloader - Cmd 0xC8 blocked: False
Preloader - Get Target info
Preloader - HW subcode: 0x8a00
Preloader - HW Ver: 0xca00
Preloader - SW Ver: 0x0
Main - Getting target info...
Preloader - Target config: 0x5
Preloader - SBC enabled: True
Preloader - SLA enabled: False
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: False
Preloader - Mem write auth: False
Preloader - Cmd 0xC8 blocked: False
Code:
mtk meta FASTBOOT
META - Status: Waiting for PreLoader VCOM, please connect mobile
META - Hint:
Power off the phone before connecting.
For preloader mode, don't press any hw button and connect usb.
...........
META - Hint:
Power off the phone before connecting.
For preloader mode, don't press any hw button and connect usb.
...........
META - Hint:
Power off the phone before connecting.
For preloader mode, don't press any hw button and connect usb.
Hey @Beanow,
I have the same gettargetconfig output, which indicates that the phone is not in BROM mode but stuck in preloader. Trying to interact with the preloader always lead to error because of the DAA (DAA_SIG_VERIFY_FAILED for example).
I have the same issue with mtkclient and meta mode. You can use the following modified mtk-bootseq.py:
py mtk-bootseq.py FASTBOOT COMXX (or python3 mtk-bootseq.py FASTBOOT /dev/ttyACMXX on linux).
Python:
import sys
import time
from serial import Serial
BOOTSEQ = bytes(sys.argv[1], "ascii")
DEVICE = sys.argv[2]
CONFIRM = b"READY" + BOOTSEQ[::-1]
while True:
try:
s = Serial(DEVICE, 115200, timeout=0.1)
print(".\n[+] Device detected")
break
except OSError as e:
sys.stdout.write("."); sys.stdout.flush()
time.sleep(0.1)
print("<-", s.read(256))
def send(bytes):
s.write(bytes)
print("->", str(bytes))
resp = s.read(256)
print("<-", str(resp))
return resp
resp = b''
while resp != CONFIRM:
resp = send(BOOTSEQ)
print("[+] Boot sequence sent")
On another device, it works and I get:
Code:
...............................
[+] Device detected
<- b'READYREADYREADYREADYREADY'
-> b'FASTBOOT'
<- b'READYTOOBTSAF'
[+] Boot sequence sent
However, on my Nord 2, I get:
Code:
...........................................
[+] Device detected
<- b'READYREADYREADYREADYREADY'
-> b'FASTBOOT'
<- b'READY'
-> b'FASTBOOT'
<- b''
-> b'FASTBOOT'
<- b''
Then the next s.write() is hanging.
I get the same result for any other boot mode. However, the code is still present in the preloader.
I unfolded my phone to try to find a test point. I tried all golden points but I only found:
- a point which loads preloader (and not BROM...) in the same way vol + / - do (in red in the picture)
- a point which boots the phone but without Android and OnePlus pictures (what's that ??) (in green)
{
"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"
}
I don't know how test point is handled: if that's the role of preloader, it may have been disabled by the update (as the BROM and fastboot). We may need to find the DAT0 point of the eMMC to short it and prevent the BROM to find the preloader, making it to go in EDL mode. However, I think that this point isn't exposed, and I won't disassemble my phone further without beeing sure of success...
Thank you so much for the work so far!
Unfortunately I get no response at all on the Nord 2T.
Code:
.......................................
[+] Device detected
<- b''
-> b'FASTBOOT'
<- b''
-> b'FASTBOOT'
Traceback (most recent call last):
File "/media/droid-work/mtkclient/mtk-bootseq.py", line 31, in <module>
resp = send(BOOTSEQ)
File "/media/droid-work/mtkclient/mtk-bootseq.py", line 24, in send
resp = s.read(256)
File "/usr/lib/python3.10/site-packages/pyserial-3.5-py3.10.egg/serial/serialposix.py", line 595, in read
raise SerialException(
serial.serialutil.SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
How did you connect to the device that you're getting these responses?
In my case, I need to use vol+, vol- and power, like mtkclient, or the ttyACM0 won't exist.
(I've got udevadm monitor up, watching for the usb/tty to be added)
Indeed, you need to run into preloader using vol +, vol -
Maybe a driver / python module issue. I've got similar issues on my linux. Try on windows or try to reinstall drivers.
It should work at least for the first answer. Else it means that your preloader doesn't send any data, which is not the case as mtkclient works.
I also tried a different baud, because a pl_lk log from oplusreserve2 partition suggested it may be used. No luck though. Note, this was a very old log I saved early on. Definitely not reflective of latest Nord 2T update.
Code:
[PLFM] boot_tag size = 0x0
BOOT_TAG_VERSION: 0
BOOT_REASON: 0
BOOT_MODE: 0
META_COM TYPE: 0
META_COM ID: 0
META_COM PORT: 285220864
META LOG DISABLE: 0
FAST META GPIO: 5906
LOG_COM PORT: 285220864
LOG_COM BAUD: 921600
LOG_COM EN: 1
LOG_COM SWITCH: 0
MEM_NUM: 2
MEM_SIZE: 0xAE7B
MEM_SIZE: 0xAE8D
I guess I'll try windows then
Code:
python mtk-bootseq.py FASTBOOT COM4
...................................................................................................................................
[+] Device detected
<- b''
-> b'FASTBOOT'
<- b''
-> b'FASTBOOT'
<- b''
-> b'FASTBOOT'
<- b''
Windows looks to behave similar. Though windows wouldn't take the MTK VCOM driver, so this is win10 default serial, in a VM over USB passthrough.
So, same result not in a VM. Though specifically with powershell I got the same output as you did.
Code:
...........................................
[+] Device detected
<- b'READYREADYREADYREADYREADY'
-> b'FASTBOOT'
<- b'READY'
-> b'FASTBOOT'
<- b''
-> b'FASTBOOT'
<- b''
This is really a helpfull post for us. I've already a oneplus nord 2 phn,from this post i know the more information about this phn.
Thank you so much.
@Beanow So same results...
It's weird that it doesn't work on Linux. Maybe an issue related to pyserial or connection settings.
What's preventing the device to be detected by mtkclient is line 54 in mtkclient/Library/meta.py: and cdc.pid == 0x2000 should be removed. So you can try to switch to fastboot using mtkclient on Linux, but with my Nord2 I get the same results as mtk-bootseq.py on Windows
Petitoto said:
@Beanow So same results...
It's weird that it doesn't work on Linux. Maybe an issue related to pyserial or connection settings.
What's preventing the device to be detected by mtkclient is line 54 in mtkclient/Library/meta.py: and cdc.pid == 0x2000 should be removed. So you can try to switch to fastboot using mtkclient on Linux, but with my Nord2 I get the same results as mtk-bootseq.py on Windows
Click to expand...
Click to collapse
Thanks for this. No need to switch to windows anymore, to use mtk client.
Petitoto said:
It's weird that it doesn't work on Linux. Maybe an issue related to pyserial or connection settings.
Click to expand...
Click to collapse
Is it 'not working' though? It's also weird to me that I had the same output as Linux using Windows' cmd, while there was READY spam in powershell. Same drivers, same python, same libraries, but different output?
I suspect that it might be a timing issue. Maybe the serial console doesn't care about or wait for input at all. And just spams READY a few times. It would be a matter of how fast the connection is established.
Perhaps as well there's a different subsystem sending commands to the 'meta' environment and the READY spam means it's processing those commands rather than whatever we're sending.
All theories, but I would find it really hard to believe there's a problem with Linux drivers / libraries for something as basic as a UART/serial console over USB.
Petitoto said:
@Beanow So same results...
It's weird that it doesn't work on Linux. Maybe an issue related to pyserial or connection settings.
What's preventing the device to be detected by mtkclient is line 54 in mtkclient/Library/meta.py: and cdc.pid == 0x2000 should be removed. So you can try to switch to fastboot using mtkclient on Linux, but with my Nord2 I get the same results as mtk-bootseq.py on Windows
Click to expand...
Click to collapse
I also suspected this PID check and tried to log the else cases, but never reaches those for me.
So removing the check didn't help for mtkclients' meta commands.
Is it 'not working' though? It's also weird to me that I had the same output as Linux using Windows' cmd, while there was READY spam in powershell. Same drivers, same python, same libraries, but different output?
Click to expand...
Click to collapse
Differents results when using cmd and powershell? There is really no reason for that. Unless it's not the same Python environment, with different pyserial for eg. I have issues to run mtk-bootseq on Linux, but always the same output on Windows' cmd.
I suspect that it might be a timing issue. Maybe the serial console doesn't care about or wait for input at all. And just spams READY a few times. It would be a matter of how fast the connection is established.
Click to expand...
Click to collapse
Maybe. On linux, I can get different results depending on baud rate, timeout (and luck?). If there is an issue related to the connection, it might explain why the preloader doesn't answer as expected. But as other commands (like mtk gettargetconfig, but also manually handshaking connections and gathering informations in pyserial) work well, I tend to think it's just disabled.
Perhaps as well there's a different subsystem sending commands to the 'meta' environment and the READY spam means it's processing those commands rather than whatever we're sending.
Click to expand...
Click to collapse
I don't really know how it works. The code is still present in the preloader. However this functionnality is not always enabled. Maybe reversing the preloader more or analysing the log you provided on Github might help to determine whether or not it is enabled. Moreover, even if we manage to switch to fastboot, if the bootloader has been fully disabled, we may face the issue of the preloader trying to run into a non existant fastboot. Maybe the FACTFACT mode may help to reset the device, but I don't really know a lot about this mode.
So removing the check didn't help for mtkclients' meta commands.
Click to expand...
Click to collapse
Once you removed this check, if you print the data sent by the preloader, you'll get the multiple "READY" like mtk-bootseq on Windows. Moreover, I can switch to fastboot using this command on another MTK device.
Dear Sir,
Do you have any method to recover my phone as the figure show?
Thank You

Categories

Resources