To revive this topic a bit and maybe give some hope. Recently, there was a patch submitted to linux-sunxi ML to fix ethernet on another board, but with Motorcomm Ethernet PHY with adding some extra properties. I have no idea why it would work, but it doesn't hurt to try at this point. gadget_guy would you be willing to test? What do you prefer? Patch? Image? Update file? LE11 or LE12 nightly?
Posts by jernej
-
-
Recently we spoke about many issues in clock driver. Guess what, I found one. HDMI clock isn't set correctly. That's why I have troubles with some displays, in this case LG TV. It seems that monitors are more forgiving, but fps would suffer.
-
I may have seen the DRAM init issue, if that is the one that causes the device not to boot
Correct. If you have serial connected, you would see that wrong amount of memory is detected.
-
I have been running for just about 3 days with schedutil governor, no freezing, no problems at all.
Glad to hear it. I have wondered if you forget to report
But I assumed silence is good in this case.It looks to me you found the cause of the freezing with this patch.
Great, I'll submit it as a fix, not only to LE, but in mainline Linux in general. If you don't mind, I would submit it with your "Reported-by:" and "Tested-by:" tags (you can give them to me via PM, but in the end, they will be publicly visible in commit message).
Thank you so much for helping solve this.
I think thanks goes to you, with your insane amount of testing. I just chimed in with ideas.
P.S. I make a few more improvements in nightly LE12 images. Network related patch is reverted and there is also a bugfix for ocassional DRAM init issue and possible HEVC decoding issue. On top of that, there is full 10-bit display pipeline support and GPU DVFS.
If only we can figure OPi 3 LTS network issue now
-
frakkin64 I devised a patch for reparenting. It's as simple as http://ix.io/4ItK (just build tested). Not sure about delay though. It may be too low (manual mentions 20 us). What I found interesting is that D1 CCU driver also reparents CPU during frequency switch, even though D1 user manual also claims that DVFS is supported on that clock. Would you try it?
-
Speaking of the GPU, I noticed that the OPP tables (sun50i-h6-gpu-opp.dtsi) are not included for any device other than Beelink GS1.
Yeah, GS1 was first, but then nobody actually updated and tested other boards.
I also assume the Tanix TX6 does dynamic frequency scaling (just with a fixed voltage?).
Correct (for CPU). GPU scaling should just work, if table is included.
I started looking at the clock code, and like everything it is a lot of indirection, macros, etc that takes years to fully understand -- and even then, there are things probably still not understood.
My research of bugs often lead me to clocks. So yeah, it's complex mechanism and, at least in the past, source of many issues.
I guess I am thinking that's why this isn't the root cause, the other factor is the scaling up/down of the frequency probably has an inherent delay and I would expect for the CPU clock to be adjusted the CPU is actually halted and the CCU has an inherent delay to wait for the clock to lock before releasing the CPU halt and perhaps that timing is greater than the regulator stabilization time (which worst case is 44us).
That's entirely possible.
I found something. H6 user manual has description how to properly adjust CPUX PLL. I'm sure that at least delay at the end is missing. However, I also noticed that many other SoCs, like A64 and H3, reparent CPU clock to something stable, like 24 MHz, switch CPUX PLL and then reparent back. I suppose that this is also valid option, at least until we can figure out more direct process.
-
frakkin64 I was recently reminded of the similar GPU issue on H6: https://lore.kernel.org/linux-arm-kern…HGUjKi@kista/T/ Maybe it's worth checking it out?
Anyway, I think fixing regulator values in DT is still worth it.
-
This is a very good research and find. I always thought ramp delay is in us and it has never occurred to me to be coefficient. Anyway, if this is the culprit, I would ask you to send patch to Linux mailing lists to update all H6 boards with AXP805. It would also explain why my primary H6 development board - Tanix TX6 - doesn't show this kind of issues. It use fixed voltage regulator instead of AXP805.
-
Dear all,
finally I wrote experimental support for 10-bit HDMI output on Allwinner H6, so HDR videos should render without any processing, directly to TV. Note, due to missing HW decoding driver features, only VP9 is rendered in 10-bit, while HEVC is still rendered in 8-bit. However, due to proper settings in HDMI output, it should be better colourwise anyway.
Please test.
Source: https://github.com/jernejsk/LibreELEC.tv/commits/h6-10bit
Update file: http://jernej.libreelec.tv/test/h6-10bit/
-
My understanding with DVFS is you have to switch the voltage first, then bump the clock.
For raising frequency yes. For lowering it, it's the other way around.
I guess I am wondering if you don't wait for the voltage ramp-up and you have adjusted the clock before the voltage is stablized would that cause SoC to crash (i.e. not enough voltage/current to support the higher clock rate).
You can easily adjust ramp up time in DT with regulator-ramp-delay. For testing purposes, you can set it to some ridiculous high number, like 100 ms.
-
If you check other interrupts, you'll notice that they are offset by 32 in regards to numbers in manual. First 32 interrupts are special.
-
Can you test some other frequency? IIRC it's possible to select opp through sysfs. If it doesn't matter which frequency is selected, as long as it's not switched, then the bug is in frequency switching code.
I have to give you big thank you for your patience in debugging this issue.
-
This also solves the Ethernet issue.
Great, I'll revert that.
Is there a reference document that indicates the voltages @ frequencies that should be used?
No, just values used in vendor (BSP) kernel. Another possibility would be code, which actually switches frequency.
-
Ethernet issue is related to commit f8e03eae5, reverted and it is working.
Can you try reverting https://github.com/LibreELEC/Libr…d72b21619a96da0 instead?
-
It seems to me this clock-latency-ns DT node is largely informational?
TBH I don't know. But waiting a bit more doesn't hurt much.
-
frakkin64 if you don't mind messing with DT, there are some differences between mainline and bsp worth testing. BSP DT has clock latency set to 2000000 and it's missing opp points for 1608 MHz and 1704 MHz. Would you mind testing this? It's all in sun50i-h6-cpu-opp.dtsi.
-
So it's either a combination of scheduler + iommu disabling, or it didn't run long enough, or it is frequency switching.
Frequency switching can be a bit tricky, true.
Can you trigger the config target via scripts/build, or do you usually do that outside of the LE build system?
Easiest way is to execute make ARCH=arm64 menuconfig in LE linux build folder and change whatever you want. Then you diff changes between .config in build folder and linux.aarch64.conf and pick changes that are of interest. Don't take all changes, there are some magic values, which are replaced by build script.
-
Note that this is just test, IOMMU benefits are big. It protects unallocated memory being used by HW (in other words, it prevents HW corrupting memory) and it allows any amount of free memory to be allocated to video decoding (otherwise only CMA memory can be used, which is limited in size).
