Posts by dtech

    Are you can add driver for rtl8192eu in your builds?

    My builds are already contain this driver in this package "RTL8192EU-aml".

    Code: projects/MXIII-S8X2/options
    ...
      # e.g. ADDITIONAL_DRIVERS="DRIVER1 DRIVER2"
        ADDITIONAL_DRIVERS="gpu-aml RTL8192CU-aml RTL8192DU RTL8192EU-aml RTL8812AU RTL8188EU-aml mt7601u-aml"
    ...

    Could you send a dmesg and an lsusb output from your MXIII-clone when the WN821N is connected during the whole boot process?

    There are KI Plus boards with an S905 processor. A photo of someone else's board does not explain the difference between the two different boot ROM logs.

    S905??? No!!!

    It is definitely GXL, not GXBB. So the SoC is S905D (or X/W/L).

    See the first post in this topic (same message was at the first time):

    GXL:BL1:9ac50e:a1974b;FEAT:ADFC318C;POC:3;RCY:0;EMMC:0;READ:0;CHK:AA;SD:0;READ:0;CHK:AA;USB:8;

    Second time... Your bootloader also contains this string:

    Code
    "Built : 15:21:58, Mar 26 2020. gxl g486bc38 - gongwei.chen@droid11-sz"

    Check the screenshot from PuTTY:

    Quote from PuTTY window

    GXL:fixed PLL lock failed

    BL1:9ac50e:bb16dc;FEAT:ADFC318C:0;POC:0;RCY:0;USB:0;SPI:0;CHK:A7;

    So, what is the next question?

    I just tested the image and it doesn't work either, after the Minix logo the black screen appears and that's it. Thank you anyway. ;)

    First time you tried v9.2.8.1?

    I only ask because it is based entirely on datrh's kernel, his kernel configuration and the same dtb.

    I just don’t understand why it doesn’t boot on your device... (But I'm trying to solve the puzzle.)

    Hola, dtech. Thanks for your work with the devices.

    I have installed the image rom sd for my Minix x8h plus (s812)but he has not taken the pot from me. So it doesn't start.

    I don't know why, I also tried the images para Amlogic universal n200 (S812, 2GB RAM, 10/100 Mbps LAN, AP6330 WiFi) But the wifi does not work in any way.

    I also tried the img for OTT M8S+ with Amlogic S812 SoC (2G/8G):but the wifi doesn't work either. The same happened to me with the MXlll img.

    What a shame, I was looking to update Kodi 18.6, in this I can only see h264 BRrips and I wanted to try another more current firmware.

    You should first try image v9.2.8 instead of v9.2.8.1 because it was made with another kernel (kszaq-based instead of datrh-based).

    Index of /3rdParty/S8X2/X8-H_Plus-S812_2G-AP6335e/ARCHIVE/

    If I understand correctly, the 9.0.2 image made by datrh with Kodi v18.6 works on your box. Is this correct?

    As for the bridging with another router in order to provide wired connection to it.

    Does this mean connecting them via ethernet? I know how it is done.

    What I suggested is an AP-bridge solution, not a client bridge, so the routers need to be connected to each other via Ethernet, not the box.

    The point is that the box is connected to a separate wireless network, not to the main router's wlan.

    You only need max. 1 meter of cable between the routers, so I think it will fit.

    People do not want wires running around their homes.

    It's easier to have the cables in the wall in advance, where you need it. But for that, I had to be put some PVC-pipes into the wall, even before painting. ;)

    Imagine 3 excited kids (plus their friends) running around a room and something protuding out of the tvbox. I give it 1 month before they break the adapter and the usb that is plugged in :P

    Rather, I would be more afraid the TV will be damaged, because that is a little more expensive than a TV box or wifi adapter.

    It seems a bit of an excuse... :sleepy:

    I have a suggestion to reverse the situation: put in an older router (e.g. 802.11g) in bridge mode that communicates well with the box.

    Forget the WAN side, connect the network cable to one of the ports on the LAN. Turn off the DHCP server and set up the wlan interface.

    Finally, connect the box to this router via WiFi. At the moment, I can't suggest a better and simpler than this solution.

    I'm sure if you have a lot of USB wifi adapters, you also have a couple of old routers. 8o

    Hi jim_p !

    chewitt is right, the wired connection is always better.

    For live streams (e.g. IPTV), even a well-functioning wireless connection can sometimes cause random delays because multiple devices are connected to it at the same time, and this sometimes puts jitter into the signal. This will make the broadcast completely unenjoyable.

    (For this, it is enough to have a smartphone connected to the same wireless network at the same time as the box. Not recommended.)

    What Da Flex suggested is actually a client bridge, which is an adapter between the WiFi and the wired connection.

    (This can still cause jitter problems with live streams because it's really just a media converter, from wireless 802.11* to wired 802.3*.)

    But for offline media (e.g. play a movie from NAS) a wireless connection may be sufficient because that can be pre-buffered.

    However, the integrated Realtek wireless driver are a really old piece (just like the kernel), and I don’t have a good experience with it either.

    But, if you have an USB WiFi adapter, try it with your box first. Like this...

    For me, this Atheros-based adapter (TP-Link WN722N) works better than the integrated Realtek.

    It’s not a piece of today either, but at least it’s stable.

    Regardless, I prefer a wired connection much more than any wireless solution.

    LibreELEC v9.2.8.1 (4K-bugfix) has been released for S8X2 devices only.


    Changes:

    • 4k-bugfix: fix 2160p resolutions support in amlogic-3.10 kernel,
    • 3rdParty images: separate Minix (datrh-based) and MXIII (Demetris-based) S8X2 builds,
    • 3rdParty images: fix X8-H Plus wifi issues and add support for X8 / X8-H devices.

    Thanks to oceanzhang for his help in debugging and testing.

    Affected devices: OTT M8S+, X8-H Plus, MXIII, MXIII-Plus/-G, Universal n200 devices and WeTek Core.

    For more information and for download links, please check the first post in this topic: #1


    Important notice for WeTek Core users:

    If anyone has tested the image for the WeTek Core, please comment because I have not received any feedback on it so far.

    If I do not receive any feedback, I will discontinue the support due to lack of interest.

    3840x2160p isn't listed all the time. Connect box with my TV (samsung) , I can switch to 2160@24p.

    But when connect to a monitor (lg 4k), I just got 1080@60p.

    Maybe Samsung reports 4k2k24hz, but LG reports same resolution as 2160p24hz.

    These two are the same, but 2160p24hz is the name in the HDMI 2.0 standard and 4k2k24hz is the name defined in HDMI 1.4.

    My TV is LG and it also only sends out 2160p*, there is no 4k2k* at all. That's why it didn't appear on the list for me either.

    Names defined in HDMI 1.4:

    • 3840x2160 (16:9): 4k2k24hz, 4k2k25hz, 4k2k30hz;
    • 4096x2160 (256:135): 4k2ksmpte.

    The names of the same resolutions in HDMI 2.0:

    • 3840x2160 (16:9): 2160p24hz, 2160p25hz, 2160p30hz;
    • 4096x2160 (256:135): smpte24hz.

    The secret is not hidden in this file (hdmi_tx_hw.c), but I am already working on it.

    Detection is already working for me, but switching the resolution is not yet.

    I've already done the patch for the kernel, now Kodi is coming. When I'm done, all HDMI 1.4 resolutions will work on Meson8/8m2.

    At least I hope so... :/

    I'm glad the m201d image worked. ;)

    Unfortunately, many manufacturers have "lied" to the 1GB so that the Android code has also been modified to show a false value.

    Just so I understand correctly, you're saying that swapping the dtb around doesn't work because the unit only checks the device tree that is baked into the kernel? If I have that right, I wish I had known that about three days ago. LOL. Oh well, live and learn.

    I learned from the case, so I rewrote it in the lead post. ^^

    IMPORTANT NOTES - Please read them carefully before asking:

    Unfortunately, there are plenty of clones from M8S. If the M8S+ image doesn't work on your M8S, try this one, if it's a 2G/8G model:

    Index of /3rdParty/S8X2/Universal-n200-S812_2G-AP6330/

    ... or MXIII image, if it's a 1G/8G:

    Index of /3rdParty/S8X2/MXIII-S802_1G-AP6330/

    (Whether S802 or S812 SoC is included does not matter at this point.)

    SCH00N3R

    1. What program do you use to write the "img.gz" file to the SD card?

    2. Have you also tried the m201d image?

    Because I have read in several forums that the V3_1 board is also suspicious that it’s only equipped with 512MB of RAM.

    3. Replacing the dtb with the meson8 kernel is not a solution because it can only read the dtb integrated into the kernel.

    Quote from the notes section of the first post on this topic:

    External DTB cannot be used with Meson8* (S802/S805/S812), because there it only takes into consideration those that are integrated into the kernel!

    Try the m201d image with the toothpick method first. If that doesn't work, try getting a smaller SDHC card.

    What does survive reboot is: during a playing video -> Setup -> Video settings -> stretch to 16:9

    Then the video looks good, but gui is still on 4:3 mode (ugly stretched).

    If this option is set to a value other than normal, it will also affect the calibration and will be completely bad.

    So, please do not use manual aspect ratio override, because calibration alone will solve this. Calibration will set the video and GUI in sync.

    For us, that’s the point now, because that’s how it can’t happen that the video is good and the GUI is bad. Either both are good or not. :)

    Anyway, I managed to find a solution to the problem, though not the way I thought.

    The disp_cap file needs to be edited. Inexplicably, the resolution is not recognized if it only includes 576cvbs:

    But, if disp_cap has been edited, it will already appear:

    (My display is already pre-calibrated, of course it won't look like this on your side in the first round, the edge of the image will hang over everywhere.)

    If you see the resolution here, the calibration data will also be saved and will not be lost after a reboot.

    Contents of the new disp_cap file:

    Code: /storage/.kodi/userdata/disp_cap
    480cvbs
    576cvbs

    And that's all. :cool:

    If you have edited the file, you will need to restart the device and then you can start the calibration, which will not be lost now.

    Be careful not to accidentally switch to 720x480i60hz if possible, because I don't think European CRT TV with 60Hz will be able to do anything.