Jump to content

dziobak

Members
  • Posts

    26
  • Joined

  • Last visited

Posts posted by dziobak

  1. Igor, I checked config (diffs) already but see nothing directly about USB. So, I think there is maybe some indirectly conneted to USB, but this is above my knowledge. Weird thing, but 100% repeatable.

     

    Also, when JMicron controllers are not detected, lsusb shows this values (port 1 and 3 with JMicron controllers) on 3.1 Genesys Logic Hub:

     Hub Port Status:
       Port 1: 0040.02c0 lowspeed
       Port 2: 0000.0203 lowspeed enable connect
       Port 3: 0000.02e0 lowspeed
     

    When detected OK, there is:

     Hub Port Status:
       Port 1: 0000.0203 lowspeed enable connect
       Port 2: 0000.0203 lowspeed enable connect
       Port 3: 0000.0203 lowspeed enable connect

     

    Don't know what that status means. Empty port has 0000.02a0

  2. I made more checking of latest kernels. Last non-problematic compiled kernel was 5.6.5 trunk.117. First problematic was 5.6.5 trunk.118. DTB files are same for both. So there must be something new in 118 or something with kernel's config. Is there a changelog for kernel trunks?

  3. Werner, thank you for suggestion. I checked usb-storage but no luck, same result like uas. I'm starting to think if this is something with voltage control on USB lines? Or stuck USB state when reboot and not reset properly? Both JMicron's controllers have own power supply, so normal reboot not cut them off. When cold booted, I turn off entire power strip with connected powers to OPi3, both JMicron's and external fan.  

  4. More to above. Problem is after every reboot, JMicron is not detected. But when Bionic is cold booted JMicron's detecting is OK.

    Tested on kernel 5.6.8 #trunk.120 and #trunk.122. After reverting to "good" 5.6.5 #trunk.111 must be also cold booted to detect JMicron, then UAS is properly detected after each reboot.

  5. Ubuntu Bionic, kernel 5.6.5 #trunk.120 not detect of UAS JMicron (USB ID 152d:0561). I use two controllers for NAS and both dissapearing. After reverting to kernel #trunk.111 all is working. Tested two times, there is something weird, JMicron is not detected on second (and next) boot on kernel #trunk.120. Also, when changed kernel to #trunk.111 JMicron is correctly detected on second boot also.

  6. I think so. First, change values in StabilityTester.sh to shows correct voltage values, try this (if not, try other regulators):

     

    REGULATOR_HANDLER="/sys/class/regulator/regulator.4"

    and set min freq value to 1000000 (there is no need to test lowest frequencies).

     

    Next, get current DTB file (/boot/dtb/allwinner/sun50i-h6-orangepi-lite2.dtb for Lite 2) and convert this binary to source, by:

    dtc -I dtb -O dts -o sun50i-h6-orangepi-lite2.dts sun50i-h6-orangepi-lite2.dtb

    open source file for editing, change voltage value for problematic frequency (after decoding numbers are hex, but you can put decimal inside) +10mV (first value of 3), write then generate DTB:

    dtc -I dts -O dtb -o sun50i-h6-orangepi-lite2.dtb sun50i-h6-orangepi-lite2.dts

    put new binary in /boot/dtb/allwinner/

    reboot, use StabilityTester

  7. If this is no load, then CPU work with lowest frequency with voltage like original (no undervoltage reason for freeze). Problem can be when freq > 1GHz, where we try use lowest possible, stable voltage (less voltage = less heat = no CPU throttling). My stable values may not work for all CPUs, so StabilityTester is best tool for check this. But not in case, when freeze is when CPU work with lowest frequencies (no system load).

  8. Use StabilityTester

    Put correct values in stabilityTester.sh. For OPi3 I used this:

    MINFREQUENCY=1000000 #Only test frequencies from this point.
    MAXFREQUENCY=2000000 #Only test frequencies upto this point.
    COOLDOWNTEMP=55000 #Cool down after a test to mC degrees
    COOLDOWNFREQ=720000 # Set to this speed when cooling down
    
    CPUFREQ_HANDLER="/sys/devices/system/cpu/cpu0/cpufreq";
    SCALINGAVAILABLEFREQUENCIES="scaling_available_frequencies";
    SCALINGMINFREQUENCY="scaling_min_freq";
    SCALINGMAXFREQUENCY="scaling_max_freq";
    
    SOCTEMPCMD="/sys/class/thermal/thermal_zone0/temp"
    
    REGULATOR_HANDLER="/sys/class/regulator/regulator.4"
    REGULATOR_MICROVOLT="microvolts"

     

  9. I did stability tests of voltage for CPU frequency from 1080 to 1800MHz.

    My metodology of searching for good, stable values was run StabilityTester (with default loop of 10), then add 10mV to values that not pass and repeat. This give me following results:

    CPU MHz 1080 1320 1488 1640 1800
    mV 880 880 930 980 1050

     

    I used above as target and min values for DTS/DTB, leaving max on defaults.

     

     

     

  10. In your uart log state, that uboot is started. I bet, there is problem with boot.scr (compiled boot.cmd file), which uboot will read and run. This file is script what to do for uboot (i.e. read kernel to memory, run)

  11. @martinayotte

    There are 3 LEDs, according to my OPi3

    Specification: http://www.orangepi.org/Orange Pi 3/

    "LED: Power LED, Status LED and USB3.0 LED"

     

    In /sys tree there are two controls only (for red power and green status)

    I have turn off red power (dont like this intensive color in dark) and green set as USB activity signaling. But can't turn off red USB LED.

     

  12. Allwinner H6 Orange Pi 3 kernel 5.88.190609 (5.1.7).

    Booting OK, but there is stability problem: 4 crashes in 2 hours after change to new kernel.

     

    Quote

    root@OrangePi:~# date
    Mon Jun 10 13:49:33 CEST 2019
    root@OrangePi:~# grep -a "Startup finished in" /var/log/syslog |grep kernel
    Jun 10 11:50:28 OrangePi systemd[1]: Startup finished in 11.725s (kernel) + 14.851s (userspace) = 26.576s.
    Jun 10 12:01:06 OrangePi systemd[1]: Startup finished in 11.447s (kernel) + 11.827s (userspace) = 23.275s.
    Jun 10 12:15:41 OrangePi systemd[1]: Startup finished in 11.280s (kernel) + 11.967s (userspace) = 23.248s.
    Jun 10 12:21:17 OrangePi systemd[1]: Startup finished in 12.093s (kernel) + 11.463s (userspace) = 23.556s.

    #some early message in logs when kernel booting

    root@OrangePi:~# grep -a "Current system time" /var/log/syslog
    Jun 10 11:49:43 OrangePi fake-hwclock[447]: Current system time: 2019-06-10 09:49:35
    Jun 10 11:50:24 OrangePi fake-hwclock[424]: Current system time: 2019-06-10 09:50:15
    Jun 10 12:01:04 OrangePi fake-hwclock[431]: Current system time: 2019-06-10 10:00:56
    Jun 10 12:15:39 OrangePi fake-hwclock[428]: Current system time: 2019-06-10 10:15:30
    Jun 10 12:21:16 OrangePi fake-hwclock[425]: Current system time: 2019-06-10 10:21:07

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines