Documentation for device tree files is in Documentation/devicetree/bindings/regulator/ in Linux source. You should also consult PneH64 schematic.
Posts by jernej
-
-
I see you fixed it for the Tanix T6 with this patch:
This is not a fix but workaround. Consequently, it was later removed when I found a proper solution for Tanix TX6.
The LE patches are only patches for the dts of the Tanix TX6, does this mean if I apply these patches in the pineH64 dts, the board will boot from emmc? Probably it's a better fix that enables the HS DDR mode?
Yes, same approach should work for PineH64 too, just make sure that you properly specify regulators. This was main issue with Tanix TX6.
-
Sorry, I'm being unclear. Let me rephrase - most cheap H6 TV boxes have fixed CPU voltage. This means that most of the time CPU is powered with excessively high voltage which of course generates more heat. You can't do anything about it because this depends on the chip which is soldered on the board. Contrary to TV boxes, SBC with H6 have adjustable voltage regulator connected to CPU and that allows kernel to lower voltage when lower frequency is set and thus avoid higher temperatures. While SBCs seems unattractive at first glance (plain board, usually no remote nor power supply included), for similar or even higher price, they are most of the time better designed.
But that is already off topic here. Please open new topic or ask in general topic such questions.
-
Yeah, I saw such issues when there was a bug in display driver when using more than one plane. In this case video is one plane and GUI overlay another. For some reason overlay plane gets clipped to the visible size of video plane.
Can you tell me more about your setup? What is your display resolution and refresh rate? What is the frame rate of the videos which can cause this issue? Board is OrangePi PC, right?
-
This sounds like clock issue to me. serafis Do you have access to RPi4? I modeled most changes against it so it should behave the same, except if some AW specific driver is at fault. RPi4 PT test image is in this thread.
-
I only have LG B8 TV with passthrough support for some formats (no AVR inbetween) where all works fine, so no, I have no idea what could be wrong. I'll do some more testing.
Make sure you have selected correct HDMI output - one with the name of your AVR (or is it TV?) device.
-
lesgar I found the issue and fixed it. Passthrough now works also on H6. Update link is in OP.
-
Exactly. Passthrough is just that - audio is passed as-is, without decompression.
lesgar I just noticed that passtrough doesn't work on H6 as of yet. I have to investigate what's going on.
-
OrangePi 3 is reasonable choice, everything works great except ethernet may from time to time not come up at boot. But this may be fixed by ATF update I should do. This is actually the board I test more often.
-
Yes, graphics is the same as on S905X3, but as I said, mesa is just now getting proper support for it. However, there are binary driver available but I always prefer mesa over them. In the past already happen that binary drivers weren't totally compatible with another SoC and SoC designer refused to release appropriate variant due to various reasons.
My recommendation would be H6, at least from Allwinner. There is still a lot of potential to unlock while already mostly on feature parity with older ones. To be honest, I don't think you need more than 3 GiB of RAM. I'm still working with 2 GiB and even 1 GiB boards and I don't see any downside. Regarding hot cpu - most cheap H6 boxes are crap because they lack precise CPU voltage management. This tends to cause higher temperatures due to higher voltage used. Additionally, in the future, H6 will get its own LE kernel settings (currently shared with other 64-bit Allwinner SoCs), which will also allow lower temperatures (at least in theory).
-
Ok, I'll prepare H6 update soon. BTW, H616 can't be supported at the moment. It's pretty different SoC and there is no documentation nor sources available for it. Also it's uses newer GPU which is just now getting support in mesa.
-
as far as I understand Allwinner always tries SD first.
Unless secure boot is enabled. In that case eMMC has higher priority. However, I'm not sure how to check for secure mode. If it is really enabled, I'm not sure if it is possible to run third party images.
-
Well, depends on your audio setup. AVR users usually prefer that audio encoded in codecs mentioned in OP are decoded on AVR instead on ARM board. I tested this on my TV where there is no real difference where audio is decoded except that TV tells me which audio codec is used in information panel and in case of Atmos I also get visible notification. However, if there is an issue and passthrough is enabled for unsupported codec on your device, you will probably get "machinegun" noise which can even damage your speakers.
-
-
Finally there was some momentum to crack audio passtrough support on mainline kernel. Thanks to the RPi4 effort, I gained better understanding what needs to be done. I believe that first variant is ready to be tested.
What works:
DTS, Dolby, Dolby+, DTS-HD MA, Atmos
What doesn't work:
- If screen resolution is set to other than 1080p @ 60 Hz audio dropouts may happen.
Before you begin:
- make sure you have selected digital HDMI output in audio settings
- enable audio passthrough and specific codecs in audio settings
Test updates for A64, H3 and H6 can be found here (currently based on LE 10.0.1):
(other updates can be added on request)
Source:
https://github.com/jernejsk/LibreELEC.tv/commits/passthrough-10.0
Please share your experience, especially if it doesn't work.
-
Add correct lines to scripts/uboot_helper. You have to create H2 section and add your board. Then copy project/Allwinner/devices/H3 to H2. After that, you're on your own
-
There will be no official support for BananaPi Zero due to low amount of RAM.
-
I forgot to list OrangePi 3 board.
Thanks for nice words! To be fair, RK and AML projects are covered with very good developers too, but they have a bit less time to work on LE. We also work together on common features and one peripheral used on those SoCs is even the same (HDMI encoder), so improvements one make directly benefit others.
