PX5 stuck in bootloop

[marchnz]

I have now tried 3 different versions of the android tool but on v2.3 and v2.35 i only get test device fail and nothing else, the same with Rockchip batch tool. i have remade my usb cable and tried it on 4 different computers with both windows 10 and 7 with the latest rockchip drivers. all the same, and on RKdev tool v2.74 i can Erase flash successfully and start upgrade but it will fail on Downloading 1%.
And i think maybe the bootloader is gone as it starts in maskrom mode immediately and not the loader mode.
I did get a zip file from the seller with firmware but it is not a .IMG file and i dont know if it is usable in this situation.
What can i try next?

As a test, could you try taking a full backup via USB the redscorpio rom extract tool?
This will tell us if all is ok with your cable.

That said, I think the cable is probably ok, maybe you're unlucky and the nand is bad, but let's find out.

 

[kon10]

As a test, could you try taking a full backup via USB the redscorpio rom extract tool?
This will tell us if all is ok with your cable.

That said, I think the cable is probably ok, maybe you're unlucky and the nand is bad, but let's find out.

When i tried that i get "found maskrom Device (RK3368 2207:330A #10" Rockchip device not in MCS or LOADED mode.

I have now tried to flash Hal9k_Mod_3.x_upgrade_to_Android_9.0 sdupdate.img via RKDevTool_Release_v2.74 and it went successfully. but not with other versions as it will error on test device fail. it will still not do anything if i connect it to the headunit again. No recovery or signs of life. But if i can flash that .img file it cannot be totally dead? Am i using a wrong update.img file and that is the fault with download error?
Can you maybe upload a update.img file that you have used with success?
Can i try to flash a new bootloader and see if it will go back in LOADER mode again? If so how will i do that?
Sorry for all the questions but i am totally new to all this.

 

[giostark]

Some one else had the wifi broken after the unbrick ?
Could be really related to the lose pins . I used the arduino cables as many of those have made the OTG work.
Can really an aluminium foil solve the issue?
As stated by this other user the software ask for different hardware.
My USB cable work properly. I can update zip files or explore them after the firmware installation.
Is also worthy update the MTCE to the last version?

I will try Androidtool next days. I have a KLD (Klyde) unit, is not a GS and that's for sure.

I don't know if that matters or if it can be considered a mod, but at my previous attempts to recover my bricked 2GB SOM I lifted pins 27 and 28 of the USB HUB chip. But they are soldered back now and no other modifications were made. Actually this is how I found the connector... I traced the pins 27 and 28 using a multimeter by measuring all the unused pins on the back of the unit.

My new 4GB SOM has arrived so the OTG tests I made were done using this SOM. I still can't access my bricked 2GB SOM.

I am still using my old MTCB unit in my car because I have a new problem now on which I am focused: I don't have WiFi anymore
My KLD MCU has a Realtek 8188 Adapter, but android is expecting a 8723 one ...

[    2.370745]  [0:      swapper/0:    1] [WLAN_RFKILL]: Enter rfkill_wlan_init
[    2.371090]  [0:      swapper/0:    1] [WLAN_RFKILL]: Enter rfkill_wlan_probe
[    2.371178]  [0:      swapper/0:    1] [WLAN_RFKILL]: wlan_platdata_parse_dt: wifi_chip_type = rtl8723bu
[    2.371193]  [0:      swapper/0:    1] [WLAN_RFKILL]: wlan_platdata_parse_dt: enable wifi power control.
[    2.371208]  [0:      swapper/0:    1] [WLAN_RFKILL]: wlan_platdata_parse_dt: disable wifi io reference voltage control.
[    2.371222]  [0:      swapper/0:    1] [WLAN_RFKILL]: wlan_platdata_parse_dt: wifi power controled by gpio.
[    2.371284]  [0:      swapper/0:    1] of_get_named_gpio_flags exited with status 29
[    2.371297]  [0:      swapper/0:    1] [WLAN_RFKILL]: wlan_platdata_parse_dt: get property: WIFI,poweren_gpio = 29, flags = 0.
[    2.371311]  [0:      swapper/0:    1] of_get_named_gpio_flags: can't parse gpios property
[    2.371323]  [0:      swapper/0:    1] of_get_named_gpio_flags: can't parse gpios property
[    2.371335]  [0:      swapper/0:    1] [WLAN_RFKILL]: rfkill_wlan_probe: init gpio
[    2.371351]  [0:      swapper/0:    1] _gpio_request: gpio-29 (wlan_default_wlan_poweren) status -16
[    2.371362]  [0:      swapper/0:    1] [WLAN_RFKILL]: Failed to get wlan_default_wlan_poweren gpio.
[    2.371386]  [0:      swapper/0:    1] wlan-platdata: probe of wireless-wlan.25 failed with error -1

...

[    2.747627]  [0:          khubd:   64] --mtc ann 1-1 0bda
[    2.747659]  [0:          khubd:   64] usb 1-1: New USB device found, idVendor=0bda, idProduct=8176
[    2.747676]  [0:          khubd:   64] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[    2.747684]  [1:         mkswap:  198] Buffer I/O error on device zram0, logical block 130227
[    2.747697]  [1:         mkswap:  198] Buffer I/O error on device zram0, logical block 130227
[    2.747711]  [1:         mkswap:  198] Buffer I/O error on device zram0, logical block 130227
[    2.747733]  [0:          khubd:   64] usb 1-1: Product: 802.11n WLAN Adapter
[    2.747740]  [1:         mkswap:  198] Buffer I/O error on device zram0, logical block 130227
[    2.747752]  [1:         mkswap:  198] Buffer I/O error on device zram0, logical block 130227
[    2.747764]  [1:         mkswap:  198] Buffer I/O error on device zram0, logical block 130227
[    2.747806]  [0:          khubd:   64] usb 1-1: Manufacturer: Realtek
[    2.747840]  [0:          khubd:   64] usb 1-1: SerialNumber: 00e04c000001

I don't know how to resolve this issue, so I ordered this just in case I need to physically replace it...
https://www.aliexpress.com/item/F23...module-tablet-wifi-bt-module/32657946183.html

Did you found a solution for this issue? Me too seems to have the same behavior . After brick my Erisin MTCE_LM_V3.01c , I managed to OTG the chip and reinstall a stock Firmware , but now no more Wifi. Even putting on the same ROM as the original one.
Maybe Erisin have made some hardware change , and also the software is a little bit different.
So did you change the chip or have you modified the software?
Thanks for your time.

 

[marchnz]

Some one else had the wifi broken after the unbrick ?
Could be really related to the lose pins .

I used the arduino cables as many of those have made the OTG work.
Can really an aluminium foil solve the issue?
As stated by this other user the software ask for different hardware.
My USB cable work properly. I can update zip files or explore them after the firmware installation.
Is also worthy update the MTCE to the last version?




Did you found a solution for this issue? Me too seems to have the same behavior . After brick my Erisin MTCE_LM_V3.01c , I managed to OTG the chip and reinstall a stock Firmware , but now no more Wifi. Even putting on the same ROM as the original one.

Maybe Erisin have made some hardware change , and also the software is a little bit different.

So did you change the chip or have you modified the software?
Thanks for your time

.

Yes.
No.

Resolve the DIL header connection issue and your wifi will be restored. Trace pins with a digital ohm or continuity meter. Be sure, don't guess.

 

[giostark]

Yes.
No.

Resolve the DIL header connection issue and your wifi will be restored. Trace pins with a digital ohm or continuity meter. Be sure, don't guess.

EDIT:
Hi Marc, thanks for the attention.
Now this is weird, I tried right now to flash the Malay_mod-3.2 that fail because a wrong signature and NOW after the reboot the wifi is on and working LOL .
Yesterday I managed to bend a little the pins for make them touch a little more against the insertion. But the wifi was dead.
Now I'll try to put on some other ROM for see what happen.
Technology !
I'll keep you informed ...

 

[giostark]

Boh, I flashed an other ROM and wifi still dead, so... I reset the unit and eureka the wifi is back again! So I missed the step of reset :/
Damn, this would be a mandatory attempt.
Thanks anyway Marc.

 

[woggles]

Hi all, I have the Dasaita MAX10 PX6 1280x720 model and to stop screen stuttering I was asked to upgrade and flash a DMCU.EXT with "screen:18" in the .EXT file.
That worked fine with their firmware, but it was still buggy so I used the OTG method to flash the HCT Android 10 firmware (planning to upgrade to Malaysk Rom). After flashing successfully the screen is now blank

Even in recovery mode.
https://youtu.be/bCUVQ8WM9tE

So I figure the HCT firmware doesn't support the screen:18 that is now programmed into the MCU. Is there anyway I can unbrick this thing? I can connect successfully using RTKDevTools.

Is it possible to flash an older MCU using RTKDevTools, or will I need to beg users to upload an .img of the latest Dasaita firmware that supports the "screen:18" MCU configuration?

 

[typos1]

HCT are the company who make the SoMs, so all MTCD/E units are "HCT", the HCT firmware is just a standard ROM with no modifications, other software like Dasaita's, is the same basic ROM with a few minor changes, so its not correct to say it isnt compatible with what you flashed.

What MCU are you on ?

Have you tried a bootable sdcard to get it into recovery ?

You say you flashed successfully, but the screen is now blank, what makes you think the flash was successful ?

 

[woggles]

HCT are the company who make the SoMs, so all MTCD/E units are "HCT", the HCT firmware is just a standard ROM with no modifications, other software like Dasaita's, is the same basic ROM with a few minor changes, so its not correct to say it isnt compatible with what you flashed.

What MCU are you on ?

Have you tried a bootable sdcard to get it into recovery ?

You say you flashed successfully, but the screen is now blank, what makes you think the flash was successful ?

I'm on MCU 2.62 which was flashed along with DCMU.EXT that contained "screen:18". I think that Dasaita added specific code that checks for that screen type and HCT one doesn't contain that code so fails to display anything. I think its a configuration value that it can't process (my theory anyway).

I will read up on using a bootable sdcard to get into recovery - I think recovery is loading but I cant do anything with it because the screen is also blank. See the YouTube video above - the LEDs behave exactly as they would when successfully booting into recovery.

I think the flash was successful because I got no errors when flashing (see screenshot). I have flashed the HCT image before when I was on MCU 2.58 (what the headunit came with).

More theory but I think the only way to get this working is

• 
  Flash the old MCU without the DMCU.EXT setting without the screen

• 
  
  Somehow change the screen:18 configuration without the screen

• Install Update.zip to upgrade to the latest Dasaita firmware version (that worked with the screen:18 config) without the screen

• 
  Get hold of a full .IMG of the lastest Dasaita firmware (that worked with the screen:18 config) and flash it using RKDevToolkit

 

[typos1]

I'm on MCU 2.62 which was flashed along with DCMU.EXT that contained "screen:18". I think that Dasaita added specific code that checks for that screen type and HCT one doesn't contain that code so fails to display anything. I think its a configuration value that it can't process (my theory anyway).

I will read up on using a bootable sdcard to get into recovery - I think recovery is loading but I cant do anything with it because the screen is also blank. See the YouTube video above - the LEDs behave exactly as they would when successfully booting into recovery.

I think the flash was successful because I got no errors when flashing (see screenshot). I have flashed the HCT image before when I was on MCU 2.58 (what the headunit came with).

More theory but I think the only way to get this working is

• 
  Flash the old MCU without the DMCU.EXT setting without the screen

• 
  
  Somehow change the screen:18 configuration without the screen

• Install Update.zip to upgrade to the latest Dasaita firmware version (that worked with the screen:18 config) without the screen

• 
  Get hold of a full .IMG of the lastest Dasaita firmware (that worked with the screen:18 config) and flash it using RKDevToolkit

2.62 ? Thats a very old MCU, I d be wanting to flash a much much newer one than that, particularly if I was using Android 10.

The ROM doesnt have anything MCU related in it, the MCU just changes how it displays the screen - upside-down, rotated, different resolutions etc so I dont think, personally that that is the problem - any RK3399/PX6 MTCD/E ROM from any MTCD/E manufacturer will work on your device.

To test whether your theory is right, try an Android 8 or 9 bootable sdcard and see if you can get into 8 or 9 recovery, if recovery is actually working you could also flash a different MCU in recovery with the screen blank if you can remember which buttons to press and how many times.

 

[woggles]

2.62 ? Thats a very old MCU, I d be wanting to flash a much much newer one than that, particularly if I was using Android 10.

The ROM doesnt have anything MCU related in it, the MCU just changes how it displays the screen - upside-down, rotated, different resolutions etc so I dont think, personally that that is the problem - any RK3399/PX6 MTCD/E ROM from any MTCD/E manufacturer will work on your device.

To test whether your theory is right, try an Android 8 or 9 bootable sdcard and see if you can get into 8 or 9 recovery, if recovery is actually working you could also flash a different MCU in recovery with the screen blank if you can remember which buttons to press and how many times.

Sorry MCU is v3.62 (latest). If I just insert a flash drive with the dmcu.img and not the dmcu.ext will it remove the custom screen setting? Can the ROM not read the screen settings off the MCU?

Edit. Good news is that when I take the sd card out after trying to upgrade the MCU it has a bunch of Android files on it so I'm pretty sure everything but the screen is working. Also, the radio works when I press mode a few times on the steering wheel.

Could someone please confirm the inputs in version 10 of recovery?

I have tried touch touch long touch (upgrade MCU) touch long touch (from usb) touch long touch (yes).

I put version 3.62 of the MCU image on the flash disk with dmcu.ext with contents screen:12. Still no luck but I'm feeling positive!

 

[woggles]

After sitting in the car pressing the reset switch blindly for over an hour with different dmcu.img and dmcu.ext I somehow managed to get a picture on the screen. I tried to update the firmware but it wouldn't boot so I stupidly flashed the HCT firmware again and I'm back to where I started. I can't get the recovery screen to show again.

Could someone please take a picture of the submenus of the HCT recovery? I have no idea how many times I need to scroll down to update from the USB drive and if there is a confirmation menu afterwards.

Does anyone know how I managed to get recovery to show?

 

[typos1]

After sitting in the car pressing the reset switch blindly for over an hour with different dmcu.img and dmcu.ext I somehow managed to get a picture on the screen. I tried to update the firmware but it wouldn't boot so I stupidly flashed the HCT firmware again and I'm back to where I started. I can't get the recovery screen to show again.

Could someone please take a picture of the submenus of the HCT recovery? I have no idea how many times I need to scroll down to update from the USB drive and if there is a confirmation menu afterwards.

Does anyone know how I managed to get recovery to show?

Theres no such thing as an HCT recovery - Android 10 recovery on an MTCE unit is the same for all ROMs.

I guess you ll have to start all over again and make a note of what MCU .imgs and .exts you flashed, clearly flash a different 10 ROM next time. Although before doing that you should wipe data/format flash and see if it boots after that.

I told you in an earlier post how to get into recovery with a bootable sdcard, its the best way to do it, some other methods are attached.

 

[woggles]

Theres no such thing as an HCT recovery - Android 10 recovery on an MTCE unit is the same for all ROMs.

I guess you ll have to start all over again and make a note of what MCU .imgs and .exts you flashed, clearly flash a different 10 ROM next time. Although before doing that you should wipe data/format flash and see if it boots after that.

I told you in an earlier post how to get into recovery with a bootable sdcard, its the best way to do it, some other methods are attached.

Thanks for the help - I managed to blindly flash the MCU with a DMCU.EXT with "screen:10" after taking a screenshot of the recovery. For anyone who ends up with the blank screen, in android 10 recovery to flash new DMCU.IMG with DMCU.EXT, copy to USB drive. Then once in recovery with no screen press reset 4 times, then long press, press twice then long press. The lights should flash on and off while its updating MCU.

This screen configuration is a dangerous setting to mess with!
screen:10 works with the HCT4_rk3399_9.0_IMG(20191125) (in the wrong resolution for my unit), but doesn't work on the Dasaita rom after upgrading.
screen:12 is blank for the HCT4_rk3399_9.0_IMG(20191125)
screen:18 only seems to work with HA3_rk3399_10.0_ota(20200915)升级包 and later, blank screen on HCT4_rk3399_9.0_IMG(20191125)

One last question: is the screen configuration setting required? Is there a way that I can clear it to increase the chance of it working across different firmwares? I have tried to flash with "screen:" in DMCU.EXT but that failed.

 

[typos1]

Glad you sorted it.

This is the first time I ve ever heard of a screen setting being different for different ROMs, it may be something to do with your unit being the rare 1024x720 res, not sure, but I d settle on a decent custom ROM like Malaysk's or @Hal9k_'s (I recommend Hal9k's) and you shouldnt need it to worry about it again. Hopefully.

 

[woggles]

Glad you sorted it.

This is the first time I ve ever heard of a screen setting being different for different ROMs, it may be something to do with your unit being the rare 1024x720 res, not sure, but I d settle on a decent custom ROM like Malaysk's or @Hal9k_'s (I recommend Hal9k's) and you shouldnt need it to worry about it again. Hopefully.

Thanks - it's 1280x720 which is relatively new, so it probably just wasn't supported on older roms. I'll wait for Hal9k to come out with an Android 10 version of his mod and then I'll def give it a try.

 

[typos1]

Thanks - it's 1280x720 which is relatively new, so it probably just wasn't supported on older roms. I'll wait for Hal9k to come out with an Android 10 version of his mod and then I'll def give it a try.

Sorry, I meant 1280x720.

 

[RayLen]

I had problems to boot my system after doing some **** to my system.

With the help of you guys here I managed to reflash my HU and it booted up and WORKED!

I had the PX5 model with the MTCE_LM MCU and the HCT PX5 V4.0 SOM... so I had the same hardware as some of you guys here.. luckily.. and it WORKED...

thanks a lot to all of you once again.
Especially to marchnz and to scorillo_ro

 

[Akuma666]

Hi To The Android Guru's,

I have a Dasaita PX5 unit that got bricked when I tried a factory reset. Unable to get into Recovery Mode (RM) as the lights on the soft buttons blink but will not let me invoke RM. The unit does not have a SD-Card Slot. After a lot of searching and reading on this forum, found MarchNZ's OTG upgrade thread.

The unit was running MTCE_HA_V3.14_1 with Android Version 8.0.0 provided by Dasaita. It is an Octacore 64-bit CPU / 4 GB RAM / 32 GB Disk

Fabricated the OTG cable using R1-2.2K and R2-3.3K. Connected the SoM board to Windows-7 Professional machine after loading the drivers and the board got detected on the first try. Downloaded the following to flash the bricked PX5 unit.

1) Downloaded firmware: px5_OREO_Full_OTG_13032018-UseToRecoverOrCreateNew.7z
2) Downloaded Tools: tools-master.zip

When I try to flash sdupdate-A8-Kumarai.img using the RK Tool, the process stops at "Wait For Loader Fail" step. Attached screen shot for better clarity. Tried this multiple times after "Reset Device" & "Erase Flash", but the process stoped every time at the same point.



Not sure what I am doing wrong but any help coming my way at this point will be much appreciated.

Unfortunately, due to the XDA upgrade, a few of the threads that I was going through are not accessible as of now.

Thanks in advance.

 

[marchnz]

Hi To The Android Guru's,

I have a Dasaita PX5 unit that got bricked when I tried a factory reset. Unable to get into Recovery Mode (RM) as the lights on the soft buttons blink but will not let me invoke RM. The unit does not have a SD-Card Slot. After a lot of searching and reading on this forum, found MarchNZ's OTG upgrade thread.

The unit was running MTCE_HA_V3.14_1 with Android Version 8.0.0 provided by Dasaita. It is an Octacore 64-bit CPU / 4 GB RAM / 32 GB Disk

Fabricated the OTG cable using R1-2.2K and R2-3.3K. Connected the SoM board to Windows-7 Professional machine after loading the drivers and the board got detected on the first try. Downloaded the following to flash the bricked PX5 unit.

1) Downloaded firmware: px5_OREO_Full_OTG_13032018-UseToRecoverOrCreateNew.7z
2) Downloaded Tools: tools-master.zip

When I try to flash sdupdate-A8-Kumarai.img using the RK Tool, the process stops at "Wait For Loader Fail" step. Attached screen shot for better clarity. Tried this multiple times after "Reset Device" & "Erase Flash", but the process stoped every time at the same point.

View attachment 5147135

Not sure what I am doing wrong but any help coming my way at this point will be much appreciated.

Unfortunately, due to the XDA upgrade, a few of the threads that I was going through are not accessible as of now.

Thanks in advance.

Sounds like you've followed the process to the letter.

The device is in maskrom mode, did you force that, or did that happen by itself?

If self, try another version of the tool.
Also, just to try, try erasing using an Android 6 version first.