Bricked Orange Pi 4 LTS after moving image from SD card to emmc

[UmutU123]

Hello everyone,

 

I somehow managed to brick my OrangePi 4 LTS. I had the Armbian running on it and decided to try the newest install in a minimal format so no desktop. Installed it, made all the setup and restarted. Since then no other image works, neither the official orangepi images nor any other armbian image. I tried booting off without the SD Card, trying to flash another OS with the SD card and read out the TTL and this is what I get:

 

DDR Version 1.25 20210517
In
channel 0
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
change freq to 416MHz 0,1
Channel 0: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,416MHz
Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB
256B stride
channel 0
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 1
CS = 0
MR0=0x18
MR4=0x2
MR5=0x1
MR8=0x10
MR12=0x72
MR14=0x72
MR18=0x0
MR19=0x0
MR24=0x8
MR25=0x0
channel 0 training pass!
channel 1 training pass!
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
change freq to 856MHz 1,0
ch 0 ddrconfig = 0x101, ddrsize = 0x40
ch 1 ddrconfig = 0x101, ddrsize = 0x40
pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD
ddr_set_rate to 328MHZ
ddr_set_rate to 666MHZ
ddr_set_rate to 928MHZ
channel 0, cs 0, advanced training done
channel 1, cs 0, advanced training done
ddr_set_rate to 416MHZ, ctl_index 0
ddr_set_rate to 856MHZ, ctl_index 1
support 416 856 328 666 928 MHz, current 856MHz
OUT

 

After this, nothing happens. Red light still on, no HDMI image, nothing. I don't know what to do from here. Not even sure if I can reset it. I tried another SD card and nothing works. Any tips?

[UmutU123]

I guess nobody here knows whats wrong?

[usual user]

4 hours ago, UmutU123 said:

I guess nobody here knows whats wrong?

Your device stalls in early firmware not even the payload (U-Boot) is reached. Which OS is used is anything but important at this point.
Make sure that a suitable firmware is used before you worry about the userspace.
Devices with Rockchip SOCs are unbrickable, you can recover at any time by restoring a suitable firmware.

[UmutU123]

@usual user So i got a dc charger but nothing I do gets me into the Maskrom mode. I am not even sure on how to flash the suitable firmware at this point. Prolly the first bricked orange pi it is lmao

[usual user]

19 hours ago, UmutU123 said:

So i got a dc charger but nothing I do gets me into the Maskrom mode.

Since the "upgrade button" is only software readable, and the firmware (U-Boot) that does it is corrupt, only this method remains.

 

19 hours ago, UmutU123 said:

I am not even sure on how to flash the suitable firmware at this point.

In MaskRom_mode I would first delete the corrupt firmware in the eMMC, so that the firmware loading falls back to the microSD card. This allows different firmware variants to be tested without having to use the clunky method to get into the MaskRom_mode.
Then I would prepare a microSD card with supposedly suitable firmware and boot the device with it. The function can be verified looking at the serial console output.
Once a suitable firmware has been identified, I would add an OS image to the microSD card to evaluate the full functionality. It may be possible to speed up the procedure if a complete image with suitable integrated firmware is already available.
Finally, if necessary, the firmware can be placed in the eMMC again.

[UmutU123]

Zitat

Since the "upgrade button" is only software readable, and the firmware (U-Boot) that does it is corrupt, only this method remains.

@usual user I tried that exact method, for whatever reason, I am not getting into MaskRom_mode. I tried shorting with ground each point, I tried shorting against each other. I tried shorting one of them. I used simple jumper cables which might be the issue (I dont think so tbh) but nothing I do works. Same red LED lighting up, no response from the board. Same output as in the first post. I think I am going to give up trying tbh, I might have really bricked the first orange pi. Usually I could get it back up but this time I am kinda hopeless. 

[usual user]

9 hours ago, UmutU123 said:

Same output as in the first post.

This says that the necessary short circuit was not present when the MaskRom code scanned for boot devices.
The short circuit must be ensured before the power supply is switched on, and must be maintained until a few seconds later. The procedure is a three-handed job. One hand fixes the PCB, one hand holds the tweezers, and one hand switches on the power supply.
This can only be reliably ensured with a shelf holder who uses Pogo pinns.

IMHO a bad board design for a tinker device. A push button or at least holes for a plug contact to connect a proper switch if necessary would be the better solution. Be grateful to your board designer.

[UmutU123]

@usual user I genuinely appreciate the time you take to answer my post. I am pretty sure, I am doing it right. I am going to keep trying once in a while. Thanks for your help, I will mark this as solved then. Next buy, I will make sure the recovery mode is easy to access haha