Jump to content

Recommended Posts

Posted

I installed armbian on a micro sd to be able to install it on my Dq08 RK3528. 
The boot succeeded on the sd card perfectly. 
I wanted to install armbian on the memory of the box with "armbian-install" I followed the instructions I did the 2. and Then I did the 5. it ask me to poweroff and since it does not want to turn on or be recognized by my peripherals connected. I've tried rebooting from an sd but it doesn't work. But I tried on another box with the same sd and it worked. So I think the box is brick. I've decided to do the tutorial from the sellers on aliexpress with the usb to usb cable. With the av button, the software doesn't even recognise it. 
I don't know what to do now.

image.png

Posted

What I have seen with most android devices, including android tv boxes is that there is a key burned on the CPU which is used to identify the bootloader that is run on the device. This is generally done by the device manufacturer to make sure that device is not tempered with and to make sure 3rd party software is not installed on the same.

 

I believe by installing bootloader, you have bricked the device as armbian bootloader is not signed by any OEM key. I am not rockchip person, and don't own any rockchip devices, so I can't say whether this can be recovered or not. Probably others can comment here.

Posted

The short answer is that Armbian doesn't support TV boxes, so don't expect anything to work.

 

Second, if your box is an rk3528 as you say, then there really is no support other than some very experimental work being done in support of that chip in tv boxes.

What build of armbian did you install on sd that worked for you?

 

Posted
23 minutes ago, SteeMan said:

Second, if your box is an rk3528 as you say, then there really is no support other than some very experimental work being done in support of that chip in tv boxes.

What build of armbian did you install on sd that worked for you?

 

That's a build with my patches and hacks. There are some problems. I haven't tried installing it because it's enough for me that it works from the SD card.

 

1 hour ago, Gunjan Gupta said:

I believe by installing bootloader, you have bricked the device as armbian bootloader is not signed by any OEM key. I am not rockchip person, and don't own any rockchip devices, so I can't say whether this can be recovered or not. Probably others can comment here.

 

I rewrote the original U-Boot and nothing broke. This means U-Boot is not signed.

 

Maybe it's SPL. What if you write a copy of the bootloaders from Android onto an SD card, will the bootloader use them? Or does it only check EMMC.

 

There is also this report:

 

 

Posted
3 minutes ago, jpegqs said:

Maybe it's SPL. What if you write a copy of the bootloaders from Android onto an SD card, will the bootloader use them? Or does it only check EMMC.

Can't say. As I said I don't own any rockchip device and hence never looked into rockchip specific details. The answer to that can vary based on SoC's bootrom implementation

Posted
11 hours ago, hotnikq said:

Stop thinking

 

11 hours ago, hotnikq said:

I think

lol

I can't find the CLK and gnd pins. There are only pins for the uart and pins for another supply. You can see the pictures of the card in this post : 

 

Posted

This is a shot in the dark, but try the golden round pad beside the heatsink above the konsemi chip. That can be the clk. For ground, you can use the one available on the side for uart. Or you can also use metal shields on top of usb ports.

 

That box of yours is already soft-bricked. What more can go wrong?!!! lol

Posted
1 hour ago, Gunjan Gupta said:

What more can go wrong?!!!

I can completely destroy it.

There, it's just a matter of putting the bootloader back in the eMMC. I'm looking in the datasheet, everyone says you have to access the maskroom. Wouldn't it be better if I short-circuited something wrong.

 

1 hour ago, Gunjan Gupta said:

but try the golden round pad beside the heatsink above the konsemi chip.

Even if I tried with the pad and it doesn't work.

Posted
10 minutes ago, jins said:

Even if I tried with the pad and it doesn't work.

Alright then, one less place to look. Honestly, if its not already posted by someone on the internet and its not marked on the board, then you have to find it out yourself either using trial and error or by using a logic analyser.

Posted
On 12/3/2023 at 7:07 PM, jins said:

I can completely destroy it.

Please, dont, some children have worked on it.

 

Step 1: You Just need to short the clk and gnd from MMC while connect the device on USB - Male to Male
use linux!  flash the loader with rkdeveloptool

fee961a5306314be81adba1c2b698b71.jpg

image.thumb.png.a4e5057a6adf3dd62ec65e7f5af2c51f.png
 

Posted

@hotnikq Yes it's perfect, that's what I wanted to do except that the person who made my box stuck the radiator on these pins so I couldn't see it. I tried to remove the radiator but the processor came with it...  

Posted
3 hours ago, jins said:

 Yes it's perfect, that's what I wanted to do except that the person who made my box stuck the radiator on these pins so I couldn't see it. I tried to remove the radiator but the processor came with it...  

 

The heatsink is held on by glue, you need to carefully insert a thin knife into the gap until the knife passes through the glue.

I removed the heatsink today and replaced the glue with a thermal pad. Because at the factory the heatsink was poorly glued to the edge of the chip, so the chip overheats under heavy load.

 

It's too late, but maybe it will be useful to someone.

Posted
3 hours ago, jpegqs said:

insert a thin knife into the gap until the knife passes through the glue.

Yeah, the processor and copper wires are ripped out, so it's impossible to re-solder it.

I tried heating the glue and it didn't melt, so your technique with the knife is the best.

 

3 hours ago, Energokom said:

did you tear off the processor along with the radiator?

the processor is still attached to the radiator, the card is dead, I'm keeping it for parts. 

Posted (edited)
8 hours ago, jins said:

the processor is still attached to the radiator

I took off my radiator for an hour and a half.

It is very strongly glued to the processor.

It is removed as follows: swing clockwise, counterclockwise, slowly increasing the amplitude. And in the end, he pulls away.

At the radiator itself, almost all the ribs are broken off.

 

I removed the radiator to replace it with a more massive one: 25x25x10.

Although in fact, it turned out that the processor is not very hot. There is no need to change the radiator.

Edited by Energokom
Posted (edited)

Sorry for the inconvenience, I posted it in the other thread but it seems it's dead. My bad.

 

Greetings. I have an X88 Mini 13, which has 2 USB ports and an SD slot and is 100% unbrickable because it has both easily reachable UART pins and (less) easily reachable eMMC clock and ground testpoints at the bottom of the board. I want it to be a Retroarch machine and play PS1-era games or older on a CRT monitor. I decided to go cowboy mode and flash it to eMMC anyways to try and see what is wrong in the boot process.

 

I had already flashed the Armbian-built U-Boot to eMMC and successfully booted both the stock Android 13 ROM and the generated Armbian image before. However this approach is slow and takes up a valuable USB port which only lets me use either a mouse or a keyboard at once. I have no SD card nor the want to buy a new one so despite the warnings I decided to try my luck and flash it to the eMMC, knowing that I can always access MaskROM and UART easily. I want to help you guys make it possible to flash Armbian to the eMMC and banish the spyware China ROM to oblivion forever, so you can somewhat count on me if you want to try stuff.

 

Observations:

1. The boot process seems to go into a loop with U-Boot SPL not knowing what to do with the eMMC partition table. It might be invalid. It either ignores the USB ports or crashes the bootloader telling me to RESET the board due to some invalid FAT stuff. We need to investigate further.

2. In MaskROM mode, rkflashtool doesn't seem to detect the eMMC's data (this behavior seems to be universal even if the board boots something)

3. In MaskROM mode, writing to partitions fails with an error about not having mtdtools available.

4. Writing to the eMMC from rkflashtool in MaskROM calculating the sector sizes by hand works fine. I've erased and then restored U-Boot and the DDR loader this way successfully.

 

Here is the UART output from my FT232H:

Taken from FTDI FT232H, over picocom, Ubuntu 22.04, 1.5M baud. Fresh boot, no USB devices attached.

DDR V1.06 1ab0bfbe2d huan.he 23/06/05-10:37:12
LP4/4x derate disable, other dram:1x trefi
ddrconfig:15
DDR3, 324MHz
BW=32 Col=11 Bk=8 CS0 Row=16 CS=1 Die BW=16 Size=4096MB
tdqss: cs0 dqs0: 241ps, dqs1: 96ps, dqs2: 361ps, dqs3: 434ps, 

change to: 324MHz
clk skew:0x7d

change to: 528MHz
clk skew:0x7d

change to: 780MHz
clk skew:0x7d

change to: 1056MHz(final freq)
clk skew:0x7d
PHY drv:clk:41,ca:41,DQ:41,odt:145
vrefinner:50%, vrefout:50%
dram drv:34,odt:120
cs 0:
the read training result:
DQS0:0x41, DQS1:0x40, DQS2:0x3c, DQS3:0x36, 
min  : 0x7  0xe  0xd  0xd  0xc  0x0  0x1  0x8 , 0xe  0xf  0x9  0x9  0x3  0x5  0x3  0x5 ,
       0x7  0x8  0x5  0x8  0x5  0x5  0x1  0x1 , 0x2  0x5  0x7  0x1  0xb  0x6  0x7  0x4 ,
mid  :0x21 0x29 0x28 0x27 0x27 0x1c 0x1c 0x22 ,0x29 0x2a 0x24 0x22 0x1f 0x1f 0x1e 0x1e ,
      0x1f 0x23 0x20 0x23 0x21 0x1d 0x1c 0x1d ,0x1a 0x22 0x24 0x1b 0x26 0x1f 0x23 0x1e ,
max  :0x3c 0x45 0x43 0x42 0x43 0x38 0x37 0x3d ,0x44 0x46 0x40 0x3c 0x3b 0x3a 0x39 0x38 ,
      0x37 0x3f 0x3b 0x3e 0x3e 0x35 0x38 0x3a ,0x33 0x3f 0x42 0x35 0x42 0x38 0x3f 0x39 ,
range:0x35 0x37 0x36 0x35 0x37 0x38 0x36 0x35 ,0x36 0x37 0x37 0x33 0x38 0x35 0x36 0x33 ,
      0x30 0x37 0x36 0x36 0x39 0x30 0x37 0x39 ,0x31 0x3a 0x3b 0x34 0x37 0x32 0x38 0x35 ,
the write training result:
DQS0:0x9d, DQS1:0x89, DQS2:0xad, DQS3:0xb7, 
min  :0x7f 0x8d 0x8c 0x89 0x8b 0x7b 0x7a 0x83 0x81 ,0x72 0x73 0x70 0x6f 0x68 0x65 0x67 0x68 0x70 ,
      0x90 0x99 0x97 0x90 0x98 0x8d 0x8c 0x94 0x95 ,0x9c 0xa5 0xa7 0x9c 0xa7 0x9f 0xa9 0x9f 0xa2 ,
mid  :0x96 0xa4 0xa2 0x9f 0xa1 0x91 0x8e 0x98 0x9b ,0x8b 0x8d 0x88 0x86 0x81 0x7e 0x7e 0x7d 0x8a ,
      0xa4 0xb0 0xac 0xa8 0xaf 0xa1 0xa4 0xad 0xb0 ,0xb4 0xbd 0xc0 0xb5 0xc1 0xb6 0xbf 0xb7 0xbc ,
max  :0xad 0xbb 0xb8 0xb6 0xb8 0xa7 0xa3 0xad 0xb6 ,0xa5 0xa7 0xa0 0x9d 0x9b 0x97 0x96 0x92 0xa5 ,
      0xb8 0xc8 0xc2 0xc0 0xc6 0xb6 0xbd 0xc7 0xcb ,0xcc 0xd6 0xda 0xce 0xdc 0xce 0xd6 0xcf 0xd7 ,
range:0x2e 0x2e 0x2c 0x2d 0x2d 0x2c 0x29 0x2a 0x35 ,0x33 0x34 0x30 0x2e 0x33 0x32 0x2f 0x2a 0x35 ,
      0x28 0x2f 0x2b 0x30 0x2e 0x29 0x31 0x33 0x36 ,0x30 0x31 0x33 0x32 0x35 0x2f 0x2d 0x30 0x35 ,
out
U-Boot SPL board init
U-Boot SPL 2017.09-armbian (Jan 13 2024 - 20:49:05)
unknown raw ID 0 0 0
unrecognized JEDEC id bytes: 00, 00, 00
Trying to boot from MMC2
Card did not respond to voltage select!
mmc_init: -95, time 12
spl: mmc init failed with error: -95
Trying to boot from MMC1
spl: partition error
Trying fit image at 0x4000 sector
## Verified-boot: 0
## Checking atf-1 0x00080000 ... sha256Failed to get clk index 0, ret=-19
Failed to get clk index 0, ret=-19
Failed to get clk index 0, ret=-19
Failed to get clk index 0, ret=-19
(cc61149bc7...) + OK
## Checking uboot 0x00200000 ... sha256Failed to get clk index 0, ret=-19
Failed to get clk index 0, ret=-19
(ee97a7743b...) + OK
## Checking fdt 0x00308d30 ... sha256Failed to get clk index 0, ret=-19
Failed to get clk index 0, ret=-19
(2867f75977...) + OK
## Checking atf-2 0xfe48d000 ... sha256Failed to get clk index 0, ret=-19
Failed to get clk index 0, ret=-19
(63ede63c1e...) + OK
## Checking atf-3 0xfe490000 ... sha256Failed to get clk index 0, ret=-19
Failed to get clk index 0, ret=-19
(922a3e8dc5...) + OK
Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00080000)
Total: 72.877/114.698 ms

 

Addendum: If it loops enough times, it always ends up crashing. Most of the time it looks like this:

Jumping to U-Boot(0x00200000) via ARM Trusted Firmware(0x00080000)
Total: 72.635/114.473 ms

INFO:    Preloader serial: 0
NOTICE:  BL31: v2.3():v2.3-623-g7bfd76051:cl
NOTICE:  BL31: Built : 05:11:46, Jul 21 2023
INFO:    rk_otp_init finish!
INFO:    ARM GICv2 driver initialized
INFO:    nonboot_cpus_off: clst_st=0xc0e, core_st=0xe1e0 boot_cpu=0
INFO:    dfs DDR fsp_param[0].freq_mhz= 1056MHz
INFO:    dfs DDR fsp_param[1].freq_mhz= 324MHz
INFO:    dfs DDR fsp_param[2].freq_mhz= 528MHz
INFO:    dfs DDR fsp_param[3].freq_mhz= 780MHz
INFO:    idle_st=0x0, pd_st=0x0
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 1
INFO:    rk_otp_init finish!
INFO:    RK3528 SoC (0x101)
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9
Error: Invalid FAT entry: 0x002a7758
### ERROR ### Please RESET the board ###

 

I haven't been able to rebuild U-Boot but at first glance it seems it can't detect a valid partition table. It might also be unable to mount EXT4 volumes but it doesn't seem to be the case since I can boot from USB when the original firmware and the custom U-Boot is installed. I keep running out of SSD space and it's bothersome to expand my Ubuntu partition so I'll try it sometime later. Maybe I'll try manually installing the Armbian rootfs, kernel and initrd to the eMMC reusing the manufacturer's partition table.

Edited by HydraCL
additional info
Posted

This comment describes a recovery method without shorting the pins. I haven't tried this method.

 

Quote

The method I used to recover was as follows:

 

Power off the device and insert a blank (very important) SD card.
Open RKDevTool.
Press and hold the reset button, then insert a USB-to-USB cable (do not connect the power, USB will supply power). RKDevTool will prompt that a LOADER device has been detected.
Use RKDevTool's firmware upgrade function to flash RK3528_DC_DQ08_Multi_WIFI_13_20231213.1628.img. This DQ08 firmware is incorrect for my device (H96MAX M7) as I do not have my own firmware, but it suffices for now.
Power off, insert the SD card with Armbian, and it boots successfully.
Under Armbian, I use dd to flash my backed-up Android.img to eMMC.
Now eMMC can boot the original Android, and the SD card can boot Armbian.

 

Posted
On 1/14/2024 at 5:37 PM, HydraCL said:

Greetings. I have an X88 Mini 13

 

Hello there! I have this "X88 Pro 13". RK3528 chip and Android 13 on it. I'm posting on the thread every thing I'm doing and tryign, consider I'm not expert in linux neither armbian, just an enthusiast with some knowledge about PCs and tech devices :)

 

 

I would love to completly dump the firmware first. I tryed rkdump tool (using Windows 10) but it failed as device has read protection, so I could only dump uboot.img and some other partitions.

I managed to boot Armbian from SD card, so if there is a way to dump all the partitions (completly firmware) from Armbian I would love to have help with doing it first. If it is possible to put the files on the SD card I can then extract them in a PC running Ubuntu 22.04 LTS.

 

Board has UART pins (needs soldering but that's not problem) and I have an UART USB dongle (CP2102 chip) that I believe I can use  with it. But I don't know which software to use and how to use it. Any information would be helpful to me and to learn few things about it. I'm really interested on how this RK chips is "unbricable" ;)

 

Also I have been reading about "MaskROM mode" and I'm a little confused about those modes. I can put device in "loader" with the hidden button, but I don't get what mask mode is for.

 

 

Posted
4 hours ago, fedes_gl said:

I managed to boot Armbian from SD card

 

You need to rebuild the U-Boot with this patch to disable the read limit. Then write the patched U-Boot to an SD-card with Armbian and boot into loader mode with the card inserted.

It's also possible to patch the binary code of the original U-Boot from EMMC, but it's long to explain.

Posted
19 hours ago, jpegqs said:

You need to rebuild the U-Boot with this patch to disable the read limit.

 

Thank you. Would you please explain me how do I do that? I could dump the uboot partition, I have "uboot.img" file. 
Also I have flashed a working version of Armbian to an SD card. It boots from my device. 

 

 

19 hours ago, jpegqs said:

It's also possible to patch the binary code of the original U-Boot from EMMC, but it's long to explain.

 

If the SD card patch allows to fully dump the entire firmware, then I have no need to touch the EMMC.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines