Jump to content

megi

Members
  • Posts

    66
  • Joined

  • Last visited

Everything posted by megi

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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
  7. 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
  8. ttyS numbers are assigned semi-randomly, unless you name them specifically in the "alias" section in DTS. So that's the problem here.
  9. Linux 5.4 now uses a different cpufreq driver for H6. I guess it needs to be enabled in Armbian's Linux defconfig.
  10. WiFi powers down on `ip link set wlan0 down` So if you don't have it configured, it should be off.
  11. 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.
  12. 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
  13. Linux 5.4 contains the code changes, dts changes will be included in 5.5. So yes, and no.
  14. 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.
  15. 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
  16. 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.
  17. 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.
  18. 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.
  19. 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.
  20. Interesting. If we can find someone with output: (raw=2), that would mean that your OPiLite2 is actually from the fastest bin. Here are some details: https://lkml.org/lkml/2019/10/31/763
  21. Actually, turns out, it's not entirely clear what efuse value<->soc bin mapping is actually used, because Allwinner code is a bit confusing. So I encourage H6 board owners to run this tool and post results, so that we can figure out how to make CPU bin<->OPP mapping work in mainline Linux.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines