Posts by dtech

Quote from vissy

Sorry for the mixup. Now up and running from NAND

Unfortunately, USB drives cannot be used for this purpose. But I'm glad it was finally resolved.

Quote from vissy

dtech I have a Wetek Core that has been gathering dust for a few years. I wanted to see if I could get it up and running with this LibreElec image.

Device is on WeOs 3.0.1 so not able to use remote to force sdcard boot. I tried using android 5.1.1. recovery to install sd-card update img. I get an error unable to mount via android recovery.

What could I do to install/boot into LibreElec? Any help is appreciated.

A quick question before we delve into deeper diagnostics:
Did you try to install according to the description in the leading post on this topic?

Quote from dtech

NAND install image for SD card: Download the NAND install image (*-sdcard.zip), extract it, and copy the contents of the file to the root folder of an FAT32-formatted SD card. Disconnect the power cord from the device, insert the prepared SD card, and plug in the power jack while pressing the reset button*. You need to hold the button about 8-10 seconds until the LibreELEC installation begins.
* The reset button on M8S+ is located behind the A/V connector, but on the Mecool and WeTek devices, the reset button is located behind the hole on the bottom of the device.

Quote from Pollostrio

Hello, sorry if this is simple to do but I’m very new to this and I need help.

I have successfully installed LibreELEC-M8S-Plus.arm-9.2.8.17-update on my Pandora with the S812 chip, and when I start it, it stays on the logo and doesn't move beyond that.

There is no SD card inserted, so I assume that’s normal.

What do I need to put on the SD card for it to move beyond that? What files are needed? Any step-by-step guide?

The NAND install images in the scdard ZIP files are made exclusively for that specific device (M8S+ and KII only), so if you install it on a different device, you risk potential bricking. In this case, the only solution is to restore the original ROM image from the device manufacturer.

It's funny when a patch looks like this:

+    // uncomment next block  enable SPDIF output to GPIO HEADERS
+    /*
+    pinctrl-0 = <&spdif_out_h_pins>;
+    */
+    // uncomment next block  enable I2S output to GPIO HEADERS
+    /*
+    pinctrl-0 = <&i2s_out_ch01_pins>, <&i2s_out_lr_clk_pins>, <&i2s_out_ao_clk_pins>;
+    */
+    // uncomment next block  enable SPDIF + I2S output to GPIO HEADERS
+    /*
+    pinctrl-0 = <&spdif_out_h_pins>, <&i2s_out_ch01_pins>, <&i2s_out_lr_clk_pins>, <&i2s_out_ao_clk_pins>;
+    */
+    pinctrl-names = "default";

In other words, these are not compiled into dtb by default, because you have to manually uncomment the option you want.
So this patch needs another patch, or this patch needs to be modified.

Quote from drollo

Hi, I own a T95z plus aswell and I had some issues whith LE12 like bad network connection, not working remote hardware, etc. And I would like ti try this dtb you have uploaded. Can it be applied on an already deployed box with LE12 or must by applied on a new installation from scratch?

Sure, it will work, you can apply the above procedure to an existing system as well. It will help with Ethernet, but it doesn't include the VFD display pins, and unfortunately we haven't been able to figure out the mystery of the remote control yet, even though I measured it before.

Quote from extremeaudio

Any chance I can get that dtb?

Please try the appropriate dtb for your system from the attachments.
Unzip and copy the following line to the amlogic folder on the SD card, then edit the first line in uEnv.ini:

dtb_name=/amlogic/meson-gxm-q200-zte-gbe.dtb

This DTB only includes the Ethernet PHY modification, but nothing else specific to the box.

EDIT: iperf3 results with the modified DTB on Sunwell T95Z Plus (2GB/16GB) @ LibreELEC v12.0.2:

LibreELEC:~ # iperf3 -c 10.60.0.30
Connecting to host 10.60.0.30, port 5201
[  5] local 10.60.0.82 port 36232 connected to 10.60.0.30 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   107 MBytes   899 Mbits/sec    0    408 KBytes
[  5]   1.00-2.00   sec   112 MBytes   941 Mbits/sec    0    426 KBytes
[  5]   2.00-3.00   sec   111 MBytes   933 Mbits/sec    0    426 KBytes
[  5]   3.00-4.00   sec   111 MBytes   929 Mbits/sec    0    426 KBytes
[  5]   4.00-5.00   sec   112 MBytes   941 Mbits/sec    0    451 KBytes
[  5]   5.00-6.00   sec  98.0 MBytes   822 Mbits/sec    0    569 KBytes
[  5]   6.00-7.00   sec   101 MBytes   849 Mbits/sec    0    757 KBytes
[  5]   7.00-8.00   sec   111 MBytes   932 Mbits/sec    0    757 KBytes
[  5]   8.00-9.00   sec   104 MBytes   870 Mbits/sec    0    757 KBytes
[  5]   9.00-10.00  sec   112 MBytes   941 Mbits/sec    0    757 KBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.06 GBytes   914 Mbits/sec    0             sender
[  5]   0.00-10.01  sec  1.06 GBytes   911 Mbits/sec                  receiver
iperf Done.

Logs:
LE v12.0.2: https://paste.libreelec.tv/united-eft.log
LE v13-nightly (20250226-23a3c47): https://paste.libreelec.tv/real-escargot.log

Quote from raindrop

I always ran earlier builds of kszaq or wrxtasy LE 8.2.5 on these old boxes, and had a habit of adding a remote.conf  file before trying a remote. I had no idea that your builds have remote files built-in.

After reading your last message, I deleted my 'modded' conf file from the SD card and rebooted the LibreElec, and what you know: factory remote worked (including ok button) without needing an external remote.conf file.

I guess I was being too smart to add a remote.conf file before trying a remote .

I suspected something similar might be going on in the background, so I thought either you didn't try at all, or the battery died when you first tried, or something like that...

But then I'm glad we finally solved this mystery.

Quote from raindrop

Well, I added following line in my remote.conf file for my factory remote (factory_code = 0xfe010001).

0x13 28  ; Enter

.... and now OK button is working . I have not tested the remote.conf files that you have linked from your github page but I believe those files would have worked too.

Thank you for all your help.

Okay, so there's some misunderstanding between us here. If your factory "working" configuration with code 0xfe010001 works, then why didn't the box work after a fresh installation, without any external configuration file? Because the remote control configuration linked from GitHub is part of my Generic_S912 image by default, and if there is no external remote.conf, it will be loaded automatically. (You can find this file on your own box here: /etc/amremote/remote.conf.)

It has the same factory code (0xfe010001) and also contains the line that you added to yours (0x13 28  # Enter (OK)). This is quite a paradox for me, because with a fresh installation, it should have worked with this built-in remote control already during the installation wizard without any external remote.conf being added.

I note that this was not built-in by default into the earlier builds of kszaq or wrxtasy to my knowledge, so their images definitely require an external remote.conf to work, but mine contains the two most common types built in. So, in my own images, if there is an external remote.conf, these built-in configs are ignored by the remote-config script.

Quote from raindrop

Hmm, the remote.conf file on my Nexbx A1 clone has no key-code 28. Maybe that's why OK button does not work. This remote also worked with H96 Pro+. File is attached below and it has comments in the file but I am not sure how accurate are the comments.

That would be better, but it's a completely different code config:
factory_code = 0xfe010001
^ The sample above, which I linked from GitHub, also had this code. If this were good, then the remote control should work by default, because this is included in my image by default.

However, what you need should be:
factory_code = 0xdf000001

I just found another one with the right code, which already has 28 for OK button (attached). I think this might be good.

The problem is that the remote.conf what I found has no explanations, so I can't bind the function button to the IR code.
In the modifications to the IR code tables I made earlier, I commented everything, so for example the OK button code is 28:

LibreELEC-AML/projects/S912/devices/Generic_S912/filesystem/etc/amremote/remote.conf at master · dtechsrv/LibreELEC-AML

'Just enough OS' for Kodi for some Amlogic TV boxes - dtechsrv/LibreELEC-AML

github.com

You can find keyboard codes for Linux here, most of them are the same on Kodi:

linux/include/uapi/linux/input-event-codes.h at master · torvalds/linux

Linux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.

github.com

However, if this is the only button that doesn't work, try this first:
0x06 28

But, if your remote.conf contains any comments or explanations, you can send it and I can help you make a working one based on them.

Quote from chewitt

I got rather distracted with some recent discoveries on the hardware decoders. I need to circle back and cherry-pick the older device tree and then do some fixups for changes; some of the kernel bindings have evolved since LE11 days.

If I have some free time, I will try to collect my fixes from that time slot, because the network stack fixes of the S905Ds (similar to the GXMs) were never included in the official images, but they were implemented incorrectly. This affected most internal tuner boxes and the Vero4+ as well. In addition, OSMC's support for the latter has ended recently, so it is possible that the number of LE users may start to increase on these boxes.

Quote from extremeaudio

Thanks for this, but my original query was pertaining to the non working lan on the box.

Sorry, I didn't mean to off-topic. As far as I remember, the T95Z Plus has the same ZTE chip instead of Realtek GbE.

Regarding this, I sent a DTB patch to chewitt a few years ago (including LED GPIOs and VFD display), and it was included, sometime around the LE11 test versions. However, since then this DTB has completely disappeared from the current AMLGX images.

The Ethernet patch was based on this:

T95Z Plus (ethernet working for kernel 5.3.0)

I tried to install Armbian_19.11.3_Aml-g12_buster_legacy_5.3.0_20191126.img.xz to my T95Z Plus box (S912 with 3GB RAM) but got only wifi running. Any ethernet…

forum.armbian.com

I've since checked, and the Ethernet chip of T95Z Plus is exactly the same as yours:

raindrop Did you try the remote control config file I sent?

I'm only asking because I saw that you edited your previous post many times, even after the time I replied...

Quote from chewitt

If the wiki is wrong, anyone can submit a correction.

Fix "installtointernal" typos by dtechsrv · Pull Request #59 · LibreELEC/documentation

If this can help us forget this stupid typo forever, then here we go...

Quote from chewitt

No progress due to other priorities over the last week. Read: https://wiki.libreelec.tv/hardware/amlogic#install2internal

I don't understand why, but this script was never available under the name install2internal, and it's even referred to by that name in the official documentation, but in fact its original name was always installtointernal.

I still have this script in my legacy build, and I've even received feedback from users who couldn't run the install2internal script. Of course, if it has a different name, how the hell would it run?! I don't know who started spreading this typo, but it's already driving me crazy...

installtointernal -> This is the correct name, it's always been this!

On my legacy amlogic images, only the amremote format is supported, so you need a compatible remote.conf file.

I only found one "in theory" match for yours, so I don't know if it will work.

Please download the attached file, extract its content, and place it here: /storage/.config/, then restart your box.

Don't be confused by the file name, the remote control of the A1 and the A95X are identical.

Quote from chewitt

the 45 degree rotation on the chip makes Amlogic unlikely

There is a HD18Q marking on the PCB, so I'm 99% sure that there is an Amlogic S805 SoC under the heatsink.

It looks very similar to the Eny EM6Q-MXQ PCB, which also had a 45 degree heatsink, although there is no battery for the RTC.

Quote from fragtion

The faulty lwfinger driver was defined here: https://github.com/dtechsrv/Libre…88EU/package.mk . Perhaps you could update this, as it appears to be your repo after all?

It may perform better on some devices, while it may not on others. Unfortunately, this is a double-edged sword, and since I can't test it, I wouldn't want to modify it, because it's an inherited driver from the official LE repo. In addition, I already indicated that I have never used this driver at all.

Quote from dtech

... I have never used the RTL8188EU made by lwfinger in my images.

My LE-AML repo is freely forkable, so anyone can modify it. However, I don't want to put more devices and/or drivers in my repo that I can't test. (There are already several devices in 3rdParty that I don't own.)