Bricked MXQ Pro 4K

    Quote from chewitt

    You have erased (overwritten) u-boot on the internal storage. Android recovery files won't work as there is no u-boot to provide the recovery app, and imaging recovery.img to an SD card won't work as it contains u-boot for emmc, not u-boot for SD/USB.

    Create a USB or SD from https://test.libreelec.tv/12.0/Amlogic/w…etek-hub.img.gz and see if the device boots to LE?

    If yes, download this backup-file and transfer it to /storage over SSH, then run "emmctool w /storage/backup-hub.tar.gz" and it will expand and restore a raw emmc (dd) backup of the original Android OS to the box. You should then be able to boot the LE12 "box" image .. or have another go at ruining things with Armbian, as you like.

    If the device boots but gets stuck at u-boot, you found the issue that resulted in "wetek-hub" (booting upstream u-boot) images being discontinued. The box sees noise on the UART and boots to console. If you have the UART connected you should be able to access the console and run the commands in here: https://github.com/LibreELEC/Libr…_autoscript.src (or one of the other bootscripts in that folder) to boot into LE. If using a USB stick you might need to run "usb start" first.

    Hi chewitt, I seemed to have done the same during an attempt to install Armbian on my S905 based board. I am getting the same eMMC output over UART, hence how I ended up here via a google search. I'm using an MXQ Pro 4K. Any chance you'd be willing to provide assistance?


    I took your image, and modified the boot parition with the respective DTBs for my box. This was the looping output:

    GXBB:BL1:08dafd:0a8993;FEAT:EDFC318C;POC:3;RCY:0;EMMC:0;READ:0;CHK:F3;SD:0;READ:0;CHK:0;
    no sdio debug board detected
    TE: 106615

    BL2 Built : 09:01:42, Oct 11 2016.
    gxb g88b04d6 - haixiang.bao@droid05

    set vcck to 1100 mv
    set vddee to 1000 mv
    Board ID = 2
    CPU clk: 1536MHz
    DDR chl: Rank0+1 same @ 912MHz
    PGSR0: 0x81c001ff.Retry...
    DX0GSR2: 0x00030001.Retry...
    DX1GSR2: 0x00030001.Retry...
    DX2GSR2: 0x00030001.Retry...
    DX3GSR2: 0x00030001.Retry...
    PGSR0: 0x81c001ff.Retry...
    DX0GSR2: 0x00030001.Retry...
    DX1GSR2: 0x00030001.Retry...
    DX2GSR2: 0x00030001.Retry...
    DX3GSR2: 0x00030001.Retry...
    PGSR0: 0x81c001ff.Retry...
    DX0GSR2: 0x00030001.Retry...
    DX1GSR2: 0x00030001.Retry...
    DX2GSR2: 0x00030001.Retry...
    DX3GSR2: 0x00030001.Retry...
    PGSR0: 0x81c001ff.Retry...


    Any help would be greatly appreciated, thanks!

    Moving to a separate thread as your problem has nothing to do with the (entirely different) WeTek Hub issue.

    Amlogic boards always boot from eMMC if signed Amlogic boot code is present in the right sector on eMMC, and you have flashed a ROM image with incompatible (has the wrong RAM chip timing details) u-boot to eMMC so the board is stuck in a boot loop.

    The best option is (re)flashing the original Android ROM to eMMC using Amlogic Burning Tool to restore the correct u-boot. The less simple option is manually shorting pins on the eMMC flash chip to temporarily disable the chip so it is not seen and the board will then attempt to boot from SD/USB media. It's not difficult to short the pins, but the problem will be finding a signed u-boot version that supports the board (as they need to support the right RAM timing data) and supports booting from SD card (as the compatible u-boot in an Android ROM will be for eMMC boot and on GXBB/S905 that means the AML signature in the wrong location).

    I do not have a collection of old Android boot ROMs (aside from WeTek Play2/Hub) and the only GXBB boards LE provides bootable SD card images for are WeTek Play2 (and Hub, but that has issues), Odroid C2 (which will not boot on anything else due to internal hardware checks), and the NanoPi-K2. So our options are limited and I have low time/interest in changing that.

    Searching for old S905 MXQ Android ROMs is the right direction. Flash them and see if they at least boot to a kernel. If they do you can force recovery boot to run Linux again. If they don't, you didn't make anything worse than it already is.

    Thanks for the feedback. Based on your comments + additional research around on different sites it seems that drastic measures have to be taken if I'd like to ever use the device again outside of a doorstop.

    I've decided to use this an a opportunity to refresh my micro soldering skills and attempt to transplant the eMMC to a writer in an attempt to source another image. My follow up question boils down from a partition/uboot perspective is if I was able to source another device/image running close enough hardware it "wouldn't really care", in theory could I dd that image to the bricked eMMC and would it operate again normal? Obviously i'd just be using uboot, and running armbian.

    If you can send some high quality photos of the PCB, I can try to search in my ROM repository to see if I can find a ROM that you can use to restore your box.

    However, you will probably need a USB A-A cable.

    Quote from deimos

    I've decided to use this an a opportunity to refresh my micro soldering skills and attempt to transplant the eMMC

    You need to be a whizz with a hot air gun to do that, and you need to read/write content from the chip to 'fix' things which will be a major undertaking. I'd go find/test a bunch of Android ROMs first, as the chances of success will be a lot higher.

    Quote from deimos

    Here are photos of the PCB. Let me know what you find.

    If you can't find a suitable IMG, you can try to configure and compile u-boot for your ddr memory type. You could use this log as a configuration basis for gxbb lpddr3 device. If necessary, we could try it together.

    Quote from deimos

    Here are photos of the PCB. Let me know what you find.

    Sorry for the late reply, but I haven't seen one with such a memory configuration so far, so unfortunately I certainly don't have a suitable ROM for this MXQ Pro (GXBB).

    Quote from bumerc

    If you can't find a suitable IMG, you can try to configure and compile u-boot for your ddr memory type. You could use this log as a configuration basis for gxbb lpddr3 device. If necessary, we could try it together.

    Hi Bumerc,

    Thanks for taking the time to respond - I appreciate it! I'll take a look at the attached link, but yes I would appreciate any assistance in trying to keep this out of becoming e-waste :)

    Quote from deimos

    Hi Bumerc,

    Thanks for taking the time to respond - I appreciate it! I'll take a look at the attached link, but yes I would appreciate any assistance in trying to keep this out of becoming e-waste :)

    Ok, I'll try to configure a test version tomorrow, you have to write it to the SD card and start it by shorting the emmc pins 29-30, because the device is currently in bootloop.

    deimos

    Here is the archive with new u-boot + diff file with the changes I made for now.

    The u-boot sources are for android 7 from this repository

    u-boot@p201_lpddr3

    Write it to the SD card via DD (Description).

    Code
    # Find out the name of the block device

lsblk

# /dev/sdX, you have to replace sdX with your block device

dd if=u-boot.bin.sd.bin of=/dev/sdX conv=fsync,notrunc bs=512 skip=1 seek=1
dd if=u-boot.bin.sd.bin of=/dev/sdX conv=fsync,notrunc bs=1 count=440

    If you are using Windows, use Amlogic BootCardMaker.

    Attach the uart output

    Edited 4 times, last by bumerc (June 29, 2024 at 6:33 PM).

    Okay. I daily drive linux, so I'll dd it to the card, should that suffice?

    Regarding shorting the EMMC, do we know if there's a standard BGA169 to solder pad mapping?

    Quote from deimos

    Okay. I daily drive linux, so I'll dd it to the card, should that suffice?

    Regarding shorting the EMMC, do we know if there's a standard BGA169 to solder pad mapping?

    You have 48 pins (right/left) around the chip. In this arrangement, in most cases DAT0/1 bus is connected to pins 29/30. The pins are counted from the INDEX ^

    Datasheet

    I'm just wondering why the manufacturer has integrated an EMCP chip as DDR memory, but solders an extra EMMC chip on the PCB. Maybe because of the encrypted firmware for this chip variant or for other cost reasons.

    edit:

    Have you perhaps saved the uart log from the original bootloader? It would make configuration easier for us. The most important point would be the RAW/Column addressing, which must match. Unfortunately, I could not find a datasheet for this chip..

    Edited once, last by bumerc (June 30, 2024 at 10:00 AM).