megi
-
Posts
66 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by megi
-
-
On 7/23/2020 at 12:40 PM, dolphs said:
Hi - Was about to spin up a new build (rc6), but it seems MakeFile has not been updated yet?
@megous @megi will you wait for rc7 which will be released coming Sunday (Monday) most likely, or could orange-pi-5.8 branch be updated please?
TiA!
I'll probably only udpate on final v5.8 release.
-
46 minutes ago, Igor said:
Before I start to dig in ... do you think this is generally broken or is it a consequence of our improvements?
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.
-
8 hours ago, hsimon806 said:
Hello,
any hints for me?
Thanks in advance!
-
Micro USB connector current rating is ~2A continuous current. Contact resistance ~2x30mOhm. I don't use it, mostly because most USB cables are usually too thin and not designed for power delivery to SBCs. (your mobile phone will not care when VBUS voltage drops to 4.5V at the end of the cable during charging, but your SBC will)
Anyway, even with custom made low resistance cabling, I was able to achieve SSD stability only when routing 5V directly to the drive. Maybe SSDs have high peak current consumption, I don't know.
So yeah, similar experience here.
-
Heatsink may not help much if the air is not moving. Place a 12cm fan next to the board and you should not have any throttling even on 1.8GHz and 100% load on all cores. (no need for a heatsink in this case) I have my fan undervolted so that it doesn't make noise. Not much airflow is needed to keep Opi3 from throttling. Otherwise you need a bigger heatsink with larger area.
-
I don't have Opi3 variant with eMMC, so I don't carry and eMMC related patches for H6 boards.
-
On 12/26/2019 at 1:15 AM, Igor said:
Yes, I can confirm that I also notice those problems, but didn't have time to look yet. However I do have HDMI. Perhaps this blacks out by random ... also possible. In any case, there is still some work.The reason for gphy not working is this:
INFO: PMIC: aldo2 voltage: 3.300V
ATF is enabling aldo2 which is half of the phy supply, whithout enabling the other half.
When Linux enables the other half later on, it's too late and phy is in a broken state. The phy regulators have to be enabled at the same time. This bug was discussed on IRC, but it looks like nobody fixed this, and the broken code got pushed to ATF master, where the Armbian is pulling it from. The fix is to downgrade ATF. The issue is basically that ATF is enabling all AXP regulators that are referenced by anything in the DTS, which is non-sensical. Device drivers should be enabling regulators for the devices they manage in a proper order.
-
1 hour ago, dolphs said:
Will give it another shot once @megi has 5.4.3 incorporated in orangepi-5.4 branch,
both default and with the " Allwinner nvmem based SUN50I CPUFreq " driver
I don't think waiting will help. I almost never update non-rc branches after release, I only merge from linux-stable.
Anyway, I can only see you're missing 1.8GHz, because Armbian changes my CPU OPP table to something else, because my OPP table has 1.8GHz operating point.
https://megous.com/git/linux/commit/?h=ths-5.4&id=8bad58044be498d409400dbf9757f2ae25c6ad9d
-
6 hours ago, SchmuseTigger said:
can anybody upload a changed file that I can import? I tried to do that change but nothing happend.
Bluetooth on Opi3 is already supported out of the box on Linux 5.5-rc1.
For 5.4:
https://megous.com/git/linux/commit/?h=opi3-5.4&id=00f1b53048ebeaec115d705d78a954c2bff944fe
https://megous.com/git/linux/commit/?h=opi3-5.4&id=1f4e6be59748a1695ecf7453a70e1c0f9d73ac14
-
ttyS numbers are assigned semi-randomly, unless you name them specifically in the "alias" section in DTS. So that's the problem here.
-
-
8 hours ago, dolphs said:
understood martinayotte, loiter for a while taking your rest!
Meanwhile booted the dev image built - just sharing some info for the ones that are interested.
One thing that immediately caught my attention it appears CPUFreq is still WIP ?
Most likely this a .config kernel thingie, which simply needs to be enabled or more work to do ?
root@orangepioneplus's password: ___ ____ _ ___ / _ \| _ \(_) / _ \ _ __ ___ _ | | | | |_) | | | | | | '_ \ / _ \_| |_ | |_| | __/| | | |_| | | | | __/_ _| \___/|_| |_| \___/|_| |_|\___| |_| Welcome to Armbian Buster with Linux 5.4.0-rc8-sunxi64 System load: 1.44 0.56 0.22 Up time: 4 min Memory usage: 12 % of 989MB IP: 192.168.10.121 CPU temp: 45°C Usage of /: 11% of 7.1G Last login: Wed Nov 27 02:34:54 2019 from 192.168.10.98 root@orangepioneplus:~# cpufreq-info cpufrequtils 008: cpufreq-info (C) Dominik Brodowski 2004-2009 Report errors and bugs to cpufreq@vger.kernel.org, please. analyzing CPU 0: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 1: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 2: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms. analyzing CPU 3: no or unknown cpufreq driver is active on this CPU maximum transition latency: 4294.55 ms.Linux 5.4 now uses a different cpufreq driver for H6. I guess it needs to be enabled in Armbian's Linux defconfig.
-
Yes.
-
WiFi powers down on `ip link set wlan0 down`
So if you don't have it configured, it should be off. -
Did you measure the heatsink/package temperature? It should be a few (~5°C, depending on the difference between room/die temps) centigrades lower than the die temperature that's reported by the driver.
For example for me, I see 43°C idle (all cores at 1.8GHz) reported by the driver, and 37-38°C measured by the IR thermometer. (no heatsink, but I use a fan) Without a fan it would be close to 50-55°C idle.
Thermal drivers and OPP tables maz be different between those two releases.
-
21 minutes ago, dolphs said:
Also check the mainlining effort page , kernel 5.5 is supposed to bring us lots of joy and perhaps by then H6 can be out of WIP stage, but is still 2-3 Months away from now ...
Looks like it is also interesting regarding CRYPTO, if you use eg ovpn or SSL ...
UPDATE
@megi Did not notice your reply earlier, btw thanks for bump to 5.4-rc6
Crypto can already be accelerated if you pick ciphers that can be accelerated with aarch64 AES instructions, because H6 has these, and they are fast.
openssl speed -evp aes-128-cbc -bytes 4096
aes-128-cbc 1324171.04k
that's > 1.2GiB/s on single core
Maybe ecb is better for benchmarking:
openssl speed -evp aes-128-ecb -bytes 4096
aes-128-ecb 537105.75k
-
5 hours ago, SchmuseTigger said:
Wait, BT is working with 5.4 RC now?
Linux 5.4 contains the code changes, dts changes will be included in 5.5. So yes, and no.
-
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.
-
Pretty much. The only problem is that the regulator is not enabled.
You'd just need to replicate these 2 small changes in the lite2 dts file:
https://patchwork.kernel.org/patch/11208939/
and then figure out the regulator for vbus, which is enabled by some gpio you can find in the lite2 schematic, and USB3 would work. You'll need the Linux 5.5 though, or to apply it on top of my tree here. https://megous.com/git/linux/log/?h=orange-pi-5.4
-
One way to get it working right now is just to enable USB3 like it was done for Opi3 and mark the VBUS regulator as regulator-always-on in dts.
-
Hmm, it looks like I never had a version of the USB3 PHY driver in my tree that includes the VBUS regulator support. Anyway, there are some mentions on LKML of patches pending to support VBUS enable via gpio-usb-b-connector driver, so hopefully in a few months it should become simpler to upstream the support for USB3 A connector on lite2, too.
-
1 hour ago, martinayotte said:
I remember seeing some patches from @megi about USB3 PHY few days ago ...
We will get those probably in his 5.4.y branch later.
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.
-
Interesting. If we can find someone with output: (raw=2), that would mean that your OPiLite2 is actually from the fastest bin.
Unable to make Panfrost work on H6
in Allwinner sunxi
Posted
One way to verify if it's this NKMP clock issue is to fix the voltage at some relatively high level for all OPPs and just keep chganging the clock. If it still crashes, it's most probably the NKMP clock.