T95z Plus case LED stays on

I have a T95z plus (2gb/16gb S912). The case is hexagonal and it has an LED light that goes all the way around it. The remote control has a button to cycle this LED between 3 colors, random and off. I have the most recent CE installed. I can’t control the LED with the remote anymore (not completely unexpected) but the real problem is when the box turns off, this light stays on. With the box on, the light is a light blue. With the box off, the light is dark blue instead of completely off. I have the VFD display working correctly (displays the time and icons and turns off when the box is powered down).

How can I fix this so the LED light is off when the box is off? It worked fine under android (but android had a ton of other problems on this box). CE works great so far except for this one issue.

Any help appreciated, thanks!

There will most likely be some proprietary binary on Android used for controlling the LED, it took one of our developers a long time to get the vfd working for the myriad of devices that exist and that was only after one of the device vendors released the source.

Maybe you could open the device up and disconnect it?

The onboard leds are controlled by u-boot when using CE.
On Android the leds are controlled by Android itself, not u-boot.

I don’t know if this u-boot is compatible with yours. May you are able to make a u-boot log?
As I have seen the PCB here: https://forum.freaktab.com/filedata/fetch?id=601623&d=1475728076&type=full there is a UART connection (GND/TX/RX/3.3V).

What DTB file you are using for this box? gxm_q201?

The dtb is gxm_q201_2g_1gbit

The rom in the internal memory on the box is one made by superceleron from freaktab for this box as the box has never worked quite right since the day I bought it (I’m running coreelec from sd card). Don’t know if installing superceleron’s rom changed the u-boot from what the box came with originally or not. Coreelec works better than superceleron’s android rom but nothing is ever perfect I guess. I have this LED problem and I’m also noticing an intermittent HDMI CEC issue using my tv’s remote control with the box. Under android it was network connectivity issues.

I’ve never made a u-boot log before but if there are instructions somewhere I can probably follow them.

Please extract the android DTB and post it. If we can figure out which pins the LED is connected to, we’ll have a better chance of figuring out how to turn the led off.

I used putty to ssh into the box.

command does not seem to have grabbed the android dtb. I got a zipped file in the corelec downloads via smb but the dtb is zero bytes

login as: root
root@’s password:




CoreELEC (official): 8.95.7 (S912.arm)
CE-LivingRM:~ # dd if=/dev/dtb | gzip > /storage/downloads/dtb.img.gz
0+0 records in
0+0 records out
0 bytes (0B) copied, 45.041638 seconds, 0B/s
CE-LivingRM:~ #

I booted to the android install on the internal and tried to copy the dtb from the dev folder to the sd card or even a usb drive using root explorer but I get an error and no file

You need to execute the command from instruction above in Android

If you are able to handle a SSH connection you may also able to update your u-boot:



Create with a second micro SD card a bootable card. Insert this card and press the reset button while power on. Than it should load the u-boot from the SD card and you can check if it is compatible and running. But I guess it should work without any problem…
As you have DDR3 ram SoC use the u-boot_q201_v2.2_green_PCB.tar.gz.

How will that resolve his LED problem?
Don’t we need the original DTB to see what pins the LEDs are connected to?

As the other “cheap” S912 gxm boxes (different brand and different design) where complete the same. Just the PCB looks different and the “quality” of the parts is different. But on all boxes the LEDs, Network, reset button,… are connected at the same pins.

I guess they manufacture of the “cheap” boxes buy a reference design, place their stickers on it - done…

The Minix U9-H isn’t a “cheap” box because the parts inside are expensive - but also the hardware connection is the same like the others.

The T95z looks the same on my first look of the PCB.

will changing the u-boot also allow me to enable sleep on this box and allow wake/power on from HDMI-CEC?

If it is compatible, yes!

Well, that is encouraging. Hopefully I have time to look into this tonight when I get home.

OK, I made a new 8gb micro sd card with the latest CE (8.99.1) on it.

I also made a linux mint live USB for my computer.
under linux my new micro sd card was /dev/sde

I downloaded the u-boot_q201_v2.2_green_PCB.tar.gz file and extracted the 2 files from it.
I opened a terminal window and ran the 2 commands
dd if=u-boot.bin.sd.bin of=/dev/sde conv=fsync,notrunc bs=1 count=444
dd if=u-boot.bin.sd.bin of=/dev/sde conv=fsync,notrunc bs=512 skip=1 seek=1
in linux. (I had to add sudo to the front to make them work). They seemed to do something and not give me any errors

I’ve booted my T95z+ from the new micro sd card and it appears to boot fine. I do see the original superceleron custom rom splash screen for a second or 2 before the coreelec logo comes up (Is that normal?)

How do I tell if it’s actually using the new u-boot from the SD card (or confirm I actually wrote it correctly)?

I did not do the final step of writing the new u-boot to the internal storage on the box yet…

Also, i tried enabling sleep but the box does not wake up properly (light changes back from dark blue to light blue but tv screen stays black and i can’t ssh into the box). Had to pull power cord to shut it off and restart.


I am not sure but maybe if you press and hold the reset button while power on it may load the u-boot from the SD card.

Do you have a any Android image file? So you can make a recovery SD card with Amlogic “Burn Card Maker”? If yes you can go back easily to the original u-boot because the recovery image is also rewriting the u-boot. So you can go on by the next step: Upgrade u-boot

But remember: All risk are on your side if you brick the system. But the Amlogic S912 system is almost unbrickable…

EDIT: I took a stock rom image (7.1.2, 3G) and this is the data: remote.conf (3.2 KB)
This remote is configured in the H96Pro+ u-boot (0xE51AFB04). So your original IR remote should work: NEC_0xE51AFB04_remote_config.zip (825 Bytes)

DTB: dtb.txt (79.6 KB)

u-boot.bin.sd.bin is only loaded if the internal bootloader partition is empty (at least the area with BL2). This happens automatically, after deleting the internal bootloader (u-boot.bin) from the bootloader partition and the reboot. The reset button is equivalent to the “run update” command and in this case only ensures that the aml_autoscript on the FAT partition of the SD card is loaded and executed by the u-boot, otherwise one would always boot to the Android.
To simplify the guide, it is sufficient if the u-boot.bin.sd.bin is written to the 0 sector on the CoreELEC SD card, the CE partition table remains untouched. The second SD card is no longer needed. (it’s just a suggestion)

I did press and hold the reset button to get the box to boot to the coreelec sd card with the new u-boot.

If I’m understanding bumerc correctly, the only way to actually boot from the u-boot on the newly prepared SD card is to toast the one in the internal memory on the box otherwise the bootloader on the internal storage starts the box and then hands off to the sd card to load the OS. Yes?

@Portisch I can confirm @bumerc is correct.

u-boot is not loaded from sdcard unless emmc/nand bootloader partition is empty

@Iziku by very careful flashing u-boot to internal, as long as you have the original firmware img (not zip) then it is almost impossible to brick your device but you could end up with headache if it goes pear shaped

Before installing the new uboot, I recommend that you determine the current clock frequency of the RAM memory from the BL2 and compare this value with the set clock frequency in the uboot to be installed. The RAM initialization issues can be avoided.

Execute the following commands via ssh:

mount -o rw,remount /flash
dd if=/dev/bootloader of=/flash/ddr_clk.bin bs=1 count=2 skip=41482
hexdump -e '"%d"' /flash/ddr_clk.bin
rm /flash/ddr_clk.bin

The hexdump shows the current Clk. Rate in Mhz.

1 Like