Bricked Wetek Hub ... now what

Amlogic hardware is hardcoded (in silicon) to search for bootable firmware on eMMC, so unless eMMC is erased or electrically disabled to prevent u-boot from being found; the boot rom finds it and runs it. The toopick method applies to vendor u-boot, the (Android) recovery mode scripts are not implemented in upstream u-boot.

I fixed this on my own board by resoldering dry joints on the UART connector. Another user shorted a pin. It's also possible to short eMMC pins to disable it allowing SD boot to the box image and then restore the factory image. I totally understand that not everyone would be comfortable with those options, but from a pure "is it recoverable or not?" perspective, it's recoverable.

In my case once the UART pins were resoldered I don't see noise and it boots without getting stuck (the other user forced a pin to 3.3v which had a positive effect). So I didn't need to short eMMC pins on the Hub (but have done that on Play2 and some other boxes before).

There are two more options I can think of:

a) https://github.com/superna9999/li…DMI-Boot-Dongle <= but this requires hardware you don't have (and a little $) and will take a while to arrive if in-stock or you have to order parts from China to self-build.

b) I forget the commands, but it's possible to enter the u-boot console, select the emmc device:partition and then erase a block range on the device to remove u-boot. Once that's done the boot-rom will fail to find u-boot on eMMC and boot the LE board image from an SD card (from where you can dd the factory image).

GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:0;READ:0;CHK:F3;SD:800;USB:8;LOOP:1

^ This is good, it means eMMC is fully erased (and the board is not bricked, it's simply missing software). You can now boot the board from an SD card .. as long as the SD card has a working u-boot in the correct places. The LE "hub" board image has everything needed although the catch22 will be that you're likely to hit the same problem with serial UART noise. Perhaps try writing the factory image backup written to SD and see if that's found (it might not be since it's an eMMC backup and S905 puts magic boot headers in different offsets for eMMC and SD) but even if it fails at booting into Android it might get you to a recovery console or perhaps the vendor u-boot console.

thegooddoctor

https://libreelec.dtech.hu/misc/wetek-unbrick-resources/WeTek_Hub_Restore.zip

^ Download this file, unpack its contents and follow the instructions in README.TXT.

Quote from thegooddoctor

I removed the emmc module ...

^ What does that mean? Did you unsolder the eMMC chip from the PCB?

Quote from thegooddoctor

well that again didn't work

BootcardMaker writes u-boot.bin to sector 0 of the SD card, so the bootloader should start even without the eMMC module.

If this doesn't work either, then maybe you didn't follow the instructions correctly, or the SD card (or possibly the slot) is also faulty.

You can prove the device boots (and is not bricked) from SD card by writing https://chewitt.libreelec.tv/testing/LibreE…etek-hub.img.gz to a spare card. It will likely get stuck at the same point during u-boot, but you will see the initial boot stage spew text on the UART console.

Confirm it does? .. and I have an idea.

Right, so nothing is bricked, it's just missing software. I have an idea, but you'll need to be a little patient.

So did this ever get solved? My Wetek Hub seems to have gone the way of the dodo as well after flashing 11.0.3 to emmc. Now I get nothing on the screen, just the blue light shining faintly on the box.

I've tried everything in this thread except the stuff with UART as I don't have access to that cable. Can't short the emmc as there aren't any pins to short.

Hi! I've read this thread and it seems that i am in the same situation. Can't boot my wetek hub after a proper emmctool write with LibreELEC-AMLGX.arm-11.0.3-wetek-hub.img.gz image.

here is my uart log from boot:

GXBB:BL1:08dafd:0a8993;FEAT:EDFD718C;POC:3;RCY:0;EMMC:0;READ:0;CHK:0;
no sdio debug board detected
TE: 131424

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 = 1
CPU clk: 1536MHz
DDR chl: Rank0+1 same @ 912MHz
DDR0: 1024MB(auto)-2T-13
DataBus test pass!
AddrBus test pass!
-s
Load fip header from eMMC, src: 0x0000c000, des: 0x01400000, size: 0x00004000
New fip structure!
Load bl30 from eMMC, src: 0x00010000, des: 0x01000000, size: 0x0000d460
Sending bl30......................................................OK.
Run bl30...
Load bl31 from eMMC, src: 0x00020000, des: 0x1010[000, size: 0x00018190
Image: gxb_v1.1.3135-18177fc 2016-06-24 11:00:09 yun.cai@droid06]
OPS=0x13
5e 6f 6f 84 2d d9 3a f9 46 82 f2 52 [0.216829 Inits done]
secure task start!
high task start!
low task start!
Load bl33 from eMMC, src: 0x0003c000, des: 0x01000000, size: 0x0008ecf0
NOTICE:  BL3-1: v1.0(debug):bc3419d
NOTICE:  BL3-1: Built : 14:16:22, Aug 15 2016
INFO:    BL3-1: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL3-1: Preparing for EL3 exit to normal world
INFO:    BL3-1: Next image address = 0x1000000
INFO:    BL3-1: Next image spsr = 0x3c9

<debug_uart>


U-Boot 2022.10 (Jul 15 2023 - 10:05:02 +0000) wetek-hub

Model: WeTek Hub
SoC:   Amlogic Meson GXBB (S905) Revision 1f:c (13:1)
DRAM:  1 GiB
Core:  161 devices, 25 uclasses, devicetree: separate
MMC:   mmc@70000: 0, mmc@72000: 1, mmc@74000: 2
Loading Environment from nowhere... OK
In:    serial
Out:   serial
Err:   serial
[BL31]: tee size: 0
Net:   eth0: ethernet@c9410000
Hit any key to stop autoboot:  0
=>   Error initialing rntime erce optd_fasINFO:  L31: ing onormH BHe@d`x H -1:@ps"P
> <@t>
>
>
> U-` H5 202310:002 0) 7tekub
> Mo Tek HboC:  logic eson G (S9) evision 1(13:1)DM:  GiBC:  1 devces25 uasses, dceree seprae
> MMC*@@ 00, mm20001mmc@740 2
> L Enronment from owhere..K
> In: @haut:  erialrr   <INTERRUPT>
=>  hze 0et:  h0:thernt@c0000
Unknown command 'hze' - try 'help'
=> z<INTERRUPT>
=> boot
Card did not respond to voltage select! : -110
switch to partitions #0, OK
mmc2(part 0) is current device
Scanning mmc 2:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1:      LibreELEC
Retrieving file: /KERNEL
append: boot=LABEL=BOOT disk=LABEL=DISK quiet systemd.debug_shell=ttyAML0 console=ttyAML0,115200n8 console=tty0
Retrieving file: /meson-gxbb-wetek-hub.dtb
## Booting kernel from Legacy Image at 08080000 ...
   Image Name:
   Image Type:   AArch64 Linux Kernel Image (lzo compressed)
   Data Size:    11576293 Bytes = 11 MiB
   Load Address: 01c80000
   Entry Point:  01c80000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 08008000
   Booting using the fdt blob at 0x8008000
   Uncompressing Kernel Image
   Loading Device Tree to 000000003bf51000, end 000000003bf5d2a3 ... OK

Starting kernel ...

[    0.000000] OF: reserved mem: failed to allocate memory for node 'linux,cma': size 896 MiB
[BL31]: tee size: 0
LibreELEC:/ # [BL31]: tee size: 0
[BL31]: tee size: 0

I'm prepared to shorted the pins to force a boot from mSD. But i need assistance for that. Wich pins to i have to shorted. I've attached an image of my hub.

Do i need to disassemble the hub more? How do i do that? How can i take the wifi antenna connector?

Thanks in advance!

Guess not. Thanks for the brick!

Quote from thegooddoctor

it isn't bricked ...

I have a pretty good idea of what is happening and have to build an appropriate image to restore it so the older u-boot loader is installed on the NAND chip (the new u-boot loader is what is faulty --- and I don't know why it is being used if it is known to be problematic [what advantages does it provide? if any])

i have lots on my plate right now so this is a low priority item that I will eventually provide a solution for

I apreciate your help! Thanks in advance!!!

Quote from thegooddoctor

the new u-boot loader is what is faulty --- and I don't know why it is being used if it is known to be problematic

Wrong. The user hardware is faulty, which creates noise on the UART which is interpreted as keypresses causing boot to be interrupted.

Stats show a reasonably number of AMLGX installs on Hub hardware, though I have no way of knowing whether people are using the upstream u-boot image or the box image

I've been busy tinkering with something else recently so didn't find time for building a tweaked u-boot version. Soon insh'allah.