megi

Not sure. I'm running my 5.6 and 5.7 branches on various orange pis and throttling seems to work for me. (Just tested on H6 (Opi3) and H5 (Opi PC 2), and H3 (Opi One), to be sure)
So maybe it's some extra patch in armbian.

If people with H6 devices without USB3 hub had problems connecting some USB3 peripherals, there has been and issue discovered now, where TXVBOOSTLVL was left to the default value instead of set to 7 (max). I haven't checked what the default value is (it's not documented), so I'm not sure if it will have any effect, but the patch is here:
 
https://megous.com/git/linux/commit/?h=opi3-5.4&id=ea8b455817276a043ee0508a8b159dca84c13c53
 
It may or may not help. On Opi3 I see no change, probably because HUB is really close to the SoC, but on boards without a HUB, SoC's USB3 phy will have to drive the signal over the longer cable and this patch might benefit those boards.

Linux 5.4 contains the code changes, dts changes will be included in 5.5. So yes, and no.

cheers I was aware of that, but thought more enhancements are on its way in 5.5 ( not just for H6 btw ) but looking closer this seems to be old news ;), nite nite

Those mainline PHY patches will work for boards that don't have switchable VBUS on usb3 ports, like Orange Pi 3. It's a bit of a compromise to get at least some allwinner USB3 code into the mainline Linux. I should probably port back to my 5.4 branch the older version of the patches that can also be used with other boards that need to enable VBUS regulators.

Thank you, all. Looks like vlad59 found the interesting value. So far it looks like, noone reported raw=7 and we have one report of raw=2, so the meanings should be raw=1 -> slow, raw=2 -> normal, raw=3 -> fast bin.
 

Yes, reading the bin is part of the commit f328584f7bff86858249bb358f1adcecde48388a
It's store in SID memory, as a part of ChipID bytes.
https://patchwork.kernel.org/patch/10903381/
How to set values is docummented in the dt-bindings patch.

5.4-rc1 contains patch to support using multiple DVFS tables based on H6 SoC speed bin. There are 3 bins slow/normal/fast and depending on which you happen to have on your board, you may lower the voltages for the same frequency. The fastest bin can deal with the lower voltages. Until this is configured in the DTS, everyone needs to use values for the worst bin (that is, to use higher voltages), because kernel can't assume it's running on a better bin.

There are other issues too (interrupt frequency being too high for example). All the ths patches in my ths-5.3 tree are probably the latest and the most debugged code for thermal sensors on H6 and other soc atm, since the last version (v5) was posted to mailing list by Yangtao Li.

This is a known bug in the THS driver. Fix is:
https://megous.com/git/linux/commit/?h=ths-5.3&id=555de6dfd8d7473d37e07047cb576accb620f896

This already works with 5.1 if armbian is still using my kernel patches. All that's needed is putting firmware in /lib/firmware.

Everything necessary is built in. It's just a dd for u-boot and cp for kernel and dtb, and that's it. You don't even need /lib/firmware or /lib/modules.
 

Everything necessary is built in. It's just a dd for u-boot and cp for kernel and dtb, and that's it. You don't even need /lib/firmware or /lib/modules.
 

I now have Bluetooth working with mainline linux on Orange Pi 3.
It's in my opi3-5.1 branch. So, test if you like.

@froezus Nice! Thank you. I've changed your patch, so that it uses R_WDOG only on H6.
 
https://megous.com/dl/tmp/0001-Fix-reset-issue-on-H6-by-using-R_WDOG.patch
 
It's still a hack, but at least it doesn't touch other SoCs.
 
U-boot will also need patching, because it doesn't use ATF for reset.
 
I tested it on Opi3, and it works. :))

@kexec I've changed the code and tested it on my board and EDID reading works for me with patches that I've sent to the mailing list, today: https://lkml.org/lkml/2019/4/5/857
 
So hopefully all this will be working in armbian soon.

@kexec I've changed the code and tested it on my board and EDID reading works for me with patches that I've sent to the mailing list, today: https://lkml.org/lkml/2019/4/5/857
 
So hopefully all this will be working in armbian soon.

Yes, HDMI works. Enabling it in DTS + the a64-de2 bus in config is enough.