No, I mean LibreELEC image.
Posts by jernej
-
-
no need for update. It's already part of released image. Just switch to SPDIF output in settings.
-
There is internal Fast Ethernet PHY, yes. However, the only LE image that supports it on H6 is Tanix TX6. But Tanix TX6 image won't work, because Tanix TX6 doesn't have PMIC, but this one does. So there is no other way than making custom DT file for this board. As with other boards, if you want to fully take advantage of this one, then you have to customize image specifically for it. Note that NAND chip is clearly visible on photos - it is not supported by kernel.
-
if I buy Pi 3 (not LTS) the Wi-fi will work right after I start the burned final stable image, right?
yes
I was just a bit confused about that extra binary blob you mentioned
Firmware is already included in the image. However, additional blob, which is not included, allows higher speeds.
or is that just some improvement you're going to implement in future / or I can do myself to improve the speed?
I think you can do it yourself, if you place it in right place. I don't think I'll do it anytime soon.
-
I just gave you two of them. There is no installation of drivers of any kind, all of them are included in the image already. That includes USB wifi drivers.
-
I would say it's generally better to just use USB dongle. But if you really want to use on-board wifi, then yes, original Orange Pi 3 (not LTS!) version is good bet, but it still need extra binary blob for faster connection. Only other solid choice is Tanix TX6 box, with one of the Realtek wifi chips, although XRadio variant also exists, which is not (yet) supported.
Wifi which is used on all newer Orange Pi boards, like Orange Pi 3 LTS, is not supported.
-
I just began developing H616 port (covers H313, H616 and H618). At first only Orange Pi Zero2 will be supported. Once that's usable, support will be expand, hopefully to Orange Pi Zero 2W too.
-
Ok, so I guess this is really board defect, most likely soldering. With fix included in that update, I haven't had single issue as of yet.
-
http://jernej.libreelec.tv/test/opi3-lts/ Note that this is 64-bit userspace, you may need to create .nocompat file in .update folder.
-
I take it the suspend function via CEC can be disabled via the CEC adapter in the peripherals menu?
correct
-
If so, I propose that LibreELEC constantly monitors display status and forces Kodi to go into "low power mode" when it detects that the display has been off for XX minutes (perhaps 5 minutes). Also I propose that LibreELEC forces Kodi to wake from "hibernation mode" and/or "low power mode" instantly when it detects that the display has been turned back on.
This is already implemented via HDMI CEC. If I turn TV off, Kodi detects this via CEC and sends suspend signal to system immediately (no delay). Wakeup is much more complex, since it depends on SoC and its drivers. Whole procedure once worked on Allwinner SoCs (except R40), but wakeup via CEC is currently broken for some reason...
In other words, sleep part is already implemented, but you don't want it if wakeup part isn't implemented and here is the issue - only some platforms implements that.
Pi4 AFAIK doesn't have power management implemented in kernel.
-
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?
-
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.
