Posts by Menion

So, I have tried to add the MMD standard disable EEE in a custom quick driver for the ZTE chip: no luck unfortunately

So we need some info about the phy configuration

Good point, in fact the RTL8211F init function in the amlogic driver disable eee as well:

/* we want to disable eee */

phy_write(phydev, RTL8211F_MMD_CTRL, 0x7);

phy_write(phydev, RTL8211F_MMD_DATA, 0x3c);

phy_write(phydev, RTL8211F_MMD_CTRL, 0x4007);

phy_write(phydev, RTL8211F_MMD_DATA, 0x0);

Instead looking at the 4.18.x code, I see that now it is managed by MMD access (new standard)

So, I will now try to backport everything on the amlogic kernel and see if it helps

Bye

Hi all

There are out there a number of TV Box that mount this gigabit transceiver instead of the more popular RTL8211F.

Almost all of them work ok at gigabit speed with the Android stock firmware, while deliver a non working (or insane slow) gigabit connection with the Linux Kernel used by Libreelec and Coreelec.

It is not the case of some tv box with this PHY but with 100Mbit line transformers that run only 100Mbit

There are a number of reference to the issue around, like this one:

T95Z Plus 3/32Gb display and network problems under 8.90.5

A (bad) workaround is to force the link speed to 100Mbit. Community and myself have already verified that the dts we use is aligned with the android stock one.

So the only explanation I have is that there are some tweaks in the linux kernel used by the android firmware. I have already tried all the 4 combination of TX delay in the S912 stmmac glue driver, but it does not help, so I am 99% sure that the problem is with the RX delay (RX clock screw) configuration in the PHY.

Using my company email I have already tried to reach out the tv box manufacturer and ZTE in order to try to gather some info, still waiting if I can succeed.

There is absolutely no information in internet about this transceiver, also the ZTE website does not even mention that they make transceiver!

But it is possible that amlogic has some knowledge of this phy. Because of my work I know how this chinese manufacturer work, it is possible that they used this PHY to reduce BOM cost and after having hit design problems, they have asked amlogic for support, so that is why it is possible that they have info on this.

I know that some of you, in particular @chewitt, have contacts with Amlogic, so maybe it is worth to try to see if they know anything.

Bye

Hi

I have the same problem with the 2/16Gb version of t95z (square enclosure).

The problem is 99.9% caused by wrong setting of the TX delay in the RGMII interface

The problem has been addressed in mainline adding configurable tx-delay in dts bindings:

001676.html

Also something similar has been done in PHY driver:

[2/2] net: phy: realtek: fix enabling of the TX-delay for RTL8211F - Patchwork

No the reason why the gigabit connection works in Android stock image and not in libreelec (and coreelec) even if the dts are identical, in my opinion can be explained by either they modified the stmmac driver or the gigabit PHY is of a vendor which driver is not compiled in the Amlogic kernel used by libreelec/coreelec, forcing to fallback to gen_phy

I am looking into it, but I need some guidance on the build system of the kernel

Bye

It is Mali400 not Mali450 for both of them (as far as I know from the available informations)

Anyhow without a mainline support for OpenGL (either close or open source) it is of no use for Kodi

There are some progress for Mali400 GPU, but it would cover only some of the allwinner SoC

It is already backed beyond the highest stretch goal

The main problem I see here is that the VPU driver would use new V4L APIs that have not been accepted in mainline kernel yet, so it would not be mainline-able soon

And the V4L community is ALWAYS argumenting with the mainline community on everything basically, like kids in the kindergarten....

Quote from afl1

Sorry this is marginal issue and common for all kodi platform. It have to be fix by kodi team. For fixing ask on kodi forum.

Quote from afl1

No issue on K3 Pro

One thing here: also from your screenshot I see that the BER, signal quality and such parameters are not working in the tvheadend frontend plugin in the amlogic build (also 8.2.x.x are affected). But the plugin version is the same of the Android official Kodi 16.x, and there everything works fine, with the same backend. In my case the backend is on another server, so it is not a problem with the DVB drivers in amlogic kernel

Quote

Sorry this is marginal issue and common for all kodi platform. It have to be fix by kodi team. For fixing ask on kodi forum.

pepeq, afl1 I have filled a bug in Kodi tracker, it has been CC to a developer, so there is the chance someone will work on it

Bye

Quote from afl1

Try this test version LibreELEC-S905.arm-9.0-devel-20180119165613-r27922-gae5b693.tar

Hello afl1

I was about to test it. Since I have several Libreelec running in my house, I don't want to update one my running libreelec installation on one of the box, since it will trigger the migration of my sql database.

So, since I run libreelec on SD, I just made a new SD with 8.90.2 image and tried to reboot in order to test your build (after upgrading of course).

But the box, with a fresh SD 8.90.2 is not booting at all.....

Now, is it possible to just swap a SD if you are already in boot from SD mode?

Or I need to follow another procedure?

Bye

GDPR-2 there is one thing to check for 3D playback. 3D playback is not supported by any TV in 4K, so far there is even no standard for 3D in 4K. What happens with libreelec when the output resolution is set to 4k, is that when starting a 3D playback, the output is a kind of weird. My projector still says 4k, but no valid format is detected. I guess it is just a completely wrong screen type set by libreelec.

The correct behaviour is to swith to 1080p and send the 3D mode over HDMI (as it is already perfectly done today when the output resolution is 1080p)

Bye

Hello

Do you know if it is possible to play, with good color diethering (or similar) HDR contents on non HDR TV?

The playback "works", but I think the color are unsaturated

Quote from snoopyjoe

Yeah I was getting the same problem as Menion with the auto update stating there was an update but never downloading. After checking the log file it seems the LibreElec config addon is timing out trying to connect to the auto update server.

More specifically, this is the error which eventually throughs a urllib2 404 error.

ERROR: Traceback (most recent call last):

File "/home/kszaq/ocz/le-master/build.LibreELEC-S905.arm-8.2-devel/LibreELEC-settings-12c5f24/.install_pkg/usr/share/kodi/addons/service.libreelec.settings/oe.py", line 284

followed by:

File "/usr/lib/python2.7/urllib2.py", line 556, in http_error_default

HTTPError: HTTP Error 404: Not Found

I can post the full pastebin log file if anyone wants to take a look at but after reading it looks like the auto update may be suspended until the transition to the Leia builds are complete.

Display More

The only plugin I have on my 4 boxes is tvheadend client. I will try to check the logs if they show something meaningful

Quote from Poida

Providing you have disabled intro video or you will not get the update notification unless you go to LE configuration and click on the auto-update setting which will then force a re-check for updates (sort of manual auto-update)

What is "intro video"? On my 4 systems, autoupdate does not work. Nothing happens at the startup, but if go in Libreelec settings, and I check for update, I get the notification popup, but again, no update start or even asked for start

I am on Libreelec 8.2.1.2, update is set to auto, notification is enabled, but I don't get any popup or whatever of the availability of 8.2.2.2.

This on 4 different A95X box, all of them upgraded through several version, but all got DTB updated on 28/10.

That is the point!

But if you check the patchset they have proposed:

+#define COMPAT_FE_SET_PROPERTY    _IOW('o', 82, struct compat_dtv_properties)
+#define COMPAT_FE_GET_PROPERTY    _IOR('o', 83, struct compat_dtv_properties)
+
+static int dvb_frontend_handle_compat_ioctl(struct file *file, unsigned int cmd,
+                                           unsigned long arg)
+{
+       struct dvb_device *dvbdev = file->private_data;
+       struct dvb_frontend *fe = dvbdev->priv;
+       struct dvb_frontend_private *fepriv = fe->frontend_priv;
+       int i, err = 0;
+
+       if (cmd == COMPAT_FE_SET_PROPERTY) {
+               struct compat_dtv_properties prop, *tvps = NULL;
....................................................
...................................................

That is why I am confused....

kszaq, in the linux_media there is a guy who was attempting to implement it, I wanted to implement it by myself, but I have so few time now (full time job and two twins...)

I see that Mauro Carvalho approved the patch series, but I see that they have implemented COMPAT specific ioctl, which puzzle me (because it would require the user space app to understand that the kernel is 64bit and call it...)

Can you point me to the compat ioctl patch you have implemented in your kernel tree?

For the 3D: the issue is that when playing 3D movie, libreelec shall switch to 1080p

Bye

Hello

I have tried a 4K HDR H265 sample (LG: Dolby Vision UHD 4K Demo | 4K Media)

The output is perfect, VPR detects YUV 12 bit with HDR metadata and the colours are correct, meaning that everything is ok.

kszaq do you think that something can be done to fix 3D playback with video output set to 4K? Also, I have a curiosity here: the tvheadend server (not frontend plugin) is 64 bit right? Because the mainline linux_media lack of compat_ioctl so it cannot work with 32bit userland on 64 bit kernel