The change was added to the nightly builds. Try the latest nightly build and see if it works properly or not.
1 Like
This doesn’t work for me. I have installed this on H96 pro+ with the same gigabit ethernet and I have the same problem. I tried both methods, changing the dtb as well as the nightly build.
I have a H96+ Pro and never had any issue with 1gigabit.
This mid should. Help t95 max with ZTE gigabit phy, at least the 2/32 model (the square box)
Maybe you have a complete different issue
There are many different versions of H96 Pro+. Mine has the exact same transceiver as mentioned in this post:
Couple of people there have also mentioned that it does not work for them. May be your problem was unique and we all have a common problem.
Do you know if you have problem with transmitted (meaning out from the H96+) ethernet traffic or with the received (received by H96+)?
I do not know. Can you tell me how to test it?
It is not complicated but requires some degree of knowledge. The tool you need to use is iperf3
@Menion Do you mind testing the latest nightly with a default DTB and see if everything works correctly?
We’re trying to determine if the change Adam made works or not, and whether it introduced any regressions.
No I didn’t. I have my box in the man cave but the VPR is in assistance. I try to do what I can as soon as possible.
But there are already confirmation that at least it is not causing regression. It remains to confirm if the patched dtb solves the issue, but I would be surprised if it does not since the modification is trivial
Adam patched the kernel, not the DTB. That’s why we need this tested by someone who knows exactly what’s going on and has the hardware with the problem.
The kernel? Why the kernel? Anyhow I will try to move it on another tv
I tested the nightly
First I reverted the 8.95.3 to the old dtb with cali_val and immediately reproduced the issue at gigabit speed.
Then I loaded the nightly on the T95z max, my box with ZTE, I can confirm that the kernel modification fix my issue as the modified dtb
I then loaded the same nightly (from same SD) on my H96+ pro, with Realtek phy and it is working fine (note that the nightly img.gz has problem on the filesystem labels, so it won’t work)
So I confirm that the patch solves my issue and it does not cause any regression on realtek (other people confirmed that there is no regression).
Anyhow I would prefer to revert the kernel modification and remove the cali_val from dts instead.
And I would also add a pr_debug printing the default content of this register. This beacause I am pretty sure that the eth register 2 (where cali_val is written) bit 18:17 are the RX clock screw (in 2ns) and it would have be usefull to have freedom to change them via dts
I tried the nightly build and I still have the same issue. Ethernet stops working completely when file transfer starts…