rusatch

Members
  • Content Count

    54
  • Joined

  • Last visited


Reputation Activity

  1. Like
    rusatch reacted to 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    @rusatch, I am very glad to hear this!!  Thank you!
  2. Like
    rusatch reacted to 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Hi @rusatch - yes, however this is actually even easier to enable now; no patching and custom kernels should be needed   If you build Armbian from the latest top-of-tree for a sunxi device (starting with the 4.17.y kernel), two new DT overlays are provided that you can load via "/boot/armbianEnv.txt" that provide this regulator and will enable higher clock speeds to be used.  The original thread regarding this (with instructions) can be found here:  https://forum.armbian.com/topic/5051-nanopi-neo2-cpu-frequency-issue/?do=findComment&comment=58181.  I'll repeat these instructions here for others:
     
    If you would like to try to run your board at 1.3GHz, and your board has a regulator on GPIO PL6 that supports 1.3v (e.g., Orange Pi Zero Plus2 H5 with Q5 MOSFET present, Orange Pi Zero Plus with Q5 MOSFET present, etc.), then all you would have to do is the following:
     
    1.  Make sure that you know what you are doing (!).  If you enable the following on a board that does not properly have access to the CPU regulator - i.e., unmodified OrangePi board with missing Q5 MOSFET, or a board that does not have a compatible 1.1v/1.3v regulator controlled via GPIO PL6 - then your board will almost certainly crash on boot!
     
    2.  Edit /boot/armbianEnv.txt, and add these lines:
    overlay_prefix=sun50i-h5 overlays=gpio-regulator-1.3v cpu-clock-1.3GHz If you have other overlays specified in your /boot/armbianEnv.txt, simply append these two new ones following them, for example:
    overlay_prefix=sun50i-h5 overlays=spi-spidev usbhost2 usbhost3 gpio-regulator-1.3v cpu-clock-1.3GHz  
    3.  Edit /etc/default/cpufrequtils, and set the MAX_SPEED definition to 1300000:
    # WARNING: this file will be replaced on board support package (linux-root-...) upgrade ENABLE=true MIN_SPEED=408000 MAX_SPEED=1300000 GOVERNOR=ondemand  
    4.  Reboot the board
     
    That should be it!  Following reboot, you can verify proper operation at the higher CPU clock speeds using "cpufreq-info" (for example).
  3. Like
    rusatch got a reaction from 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Ooh. With overlays its very usefull. Thank you very much. Its very cool!
    Today i recieve mosfets from aliexpress, used link that was in this thread. Tomorrow i will include mosfet on board and try use overlays.
     
    update: Found additional overlay named cpu-clock-1.4GHz. Is this experemental overlay?
  4. Like
    rusatch reacted to 5kft in u-boot 2018.05 parser issue w/Armbian sunxi-next DT scripts (e.g., spi-spidev overlay configuration failure)   
    I just fixed this for the H5 boards, and have submitted a PR (https://github.com/armbian/build/pull/1056).  With these changes SPI is working for me again   Similar changes likely need to be made for the H3 DTs.
  5. Like
    rusatch reacted to 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    I'd like to make a patch explicitly for this and send a pull request to get it into the mainline, but unfortunately I don't have time to support this (much as I would like to!)...
     
    If you just want to add support for the LEDs, you could clone the official Armbian master build tree, then do a custom patch.  For example, change to ".../build" and run "compile.sh":
     
    ./compile.sh KERNEL_ONLY=yes KERNEL_CONFIGURE=no KERNEL_KEEP_CONFIG=no BRANCH=next BETA=yes BUILD_KSRC=no CREATE_PATCHES=yes BOARD=orangepizeroplus2-h5 When the build pauses for the kernel patch, edit ".../build/cache/sources/linux-mainline/linux-4.14.y/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-zero-plus2.dts", and simply add a block for the LEDs (I added mine following the existing "wifi-pwrseq" block).  E.g.,
    leds { compatible = "gpio-leds"; pwr { label = "orangepi:green:pwr"; gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>; /* PL10 */ default-state = "on"; }; status { label = "orangepi:red:status"; gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>; /* PA17 */ }; }; Save, and continue the build.  Then simply install the generated packages in ".../build/output/debs".  (It should also be possible to generate an overlay for this, but I haven't bothered to do this.)
  6. Like
    rusatch reacted to 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    Yes.  Actually I ended up commenting out the "&hdmi" block, the "&mixer0" block, and the "&sound_hdmi" block (I don't need audio support either):
    /* &hdmi { status = "okay"; }; &mixer0 { status = "okay"; }; */ &r_pio { wifi_wake: wifi_wake@0 { pins = "PL7"; function = "irq"; bias-pull-up; }; }; /* &sound_hdmi { status = "okay"; }; */  
     
  7. Like
    rusatch reacted to edupv in Hardware line is missing on /proc/cpuinfo   
    A dirty hack to make it working in orangepi PC2 immediately :
     
    Edit the file WiringOP/wiringPi/wiringPi.c (https://github.com/tumugin/WiringOP), change the function isH5(void) to :
    int isH5(void) { return 1; } then "sudo ./build".
     
    I don't know C language, so there is no better way for me.
     
     
    Edit : I have verified the following is working, other pins/functions are not tested :
    ## Tested with LED + resistor across physical pin 1 (3.3V) and pin 7 PORT=7 gpio mode $PORT out gpio write $PORT 0; ## LED on gpio write $PORT 1; ## LED off  
  8. Like
    rusatch reacted to Igor in Next major upgrade v5.60   
    Yes. Fixed.
  9. Like
    rusatch reacted to Per-Mattias Nordkvist in Controlling GPIO on OrangePi Zero Plus 2 (for newbies)   
    I just wanted to share some instructions on how to control all GPIO pins on the OrangePi Zero Plus 2 board. These instructions are meant for newbies but it can be extremely helpful if you are new to Armbian, OPI and GPIO. At least it would have been for me. 
     
    There is a total of 17 different pins to control according to the schematic below. These pins are highlighted in blue numbers that indicate what GPIO port they are available at. Use these numbers in order to know that pins to control. Look for instructions further down. 
     

     
    First off some basics: 
    Activate a pin by exporting it. For example. In order to activate IO-0 run: echo "352" > /sys/class/gpio/export Set the direction of the port.  echo "out" > /sys/class/gpio/gpio352/direction Turn it on: echo "1" > /sys/class/gpio/gpio352/value Turn it off: echo "0" > /sys/class/gpio/gpio352/value  
    To figure out what number to use for each pin follow the schematics above or read from the list below. I really have not figured out wether it is safe to control all pins(and not just IO-pins) for output but it seems to work when I verify with a voltmeter. These pins were identified using the official schematic for the board: http://linux-sunxi.org/File:ORANGE_PI-ZERO-PLUS2_V1_0.pdf
     
    If you are interested to learn how pins are identified based on the schematic please dig deeper into these files in the GIT repo: 
    https://github.com/armbian/linux/blob/sun8i/drivers/pinctrl/pinctrl-sunxi.h
    https://github.com/armbian/linux/blob/sun8i/arch/arm/mach-sunxi/include/mach/pinctrl.h
     
    GPIO Table
    SDA = 12
    SCL = 11
    IO-GCLK = 6
    IO-0 = 352
    IO-2 = 353
    IO-3 = 3
    SPI1-MOSI = 15
    SPI1-MISO = 16
    SPI1-CLK = 14
    TXD0 = 15
    RXD0 = 16
    IO-1 = 107
    IO-4 = 19
    IO-5 = 18
    IO-6 = 2
    SPI-CE0 = 13
    SPI-CE1 = 110
     
    I hope this helps someone. 
  10. Like
    rusatch reacted to thc013 in OPZ+2 H5 onboard bluetooth support?   
    enable overlay uart 1
    and add
    param_uart1_rtscts=1
     
    to armbianenv.txt
     
    and adjust /etc/init.d/ap6212-bluetooth so it looks like this
     
      # Start patching
            rfkill unblock all
            echo "0" > /sys/class/rfkill/rfkill0/state
            echo "1" > /sys/class/rfkill/rfkill0/state
            echo " " > /dev/$PORT
            devmem2 0x1f00060 b 1
            echo 10 > /sys/class/gpio/export
            echo out > /sys/class/gpio/gpio10/direction
            echo 0 > /sys/class/gpio/gpio10/value
            echo 1 > /sys/class/gpio/gpio10/value
            sleep 0.1
            hciattach /dev/$PORT bcm43xx 115200 flow bdaddr $MAC_OPTIONS
            hciconfig hci0 up
     
     and reboot
     
    oh you might need to install devmem2
     
  11. Like
    rusatch reacted to 5kft in Orange Pi Zero Plus2 H5 hardware oddity in VDD_CPUX power circuit   
    I recently purchased a number of Orange Pi and Nano Pi boards, and discovered the awesome work of the Armbian team :-)  The Orange Pi Plus2 H5 is a rather nice board - built in eMMC, H5, etc.  (I wish it had 1GB of RAM but that's a different subject.)  I'd love to use these boards for a number of projects.
     
    As a test, I modified the DTS for the board (mainline kernel) to enable support for the 1.1v/1.3v switch for VDD-CPUX using the SY8113B on the board.  I also enabled the allowed clock changes to 1.2GHz for cpufreq.  All of this worked great, but the board was very unstable at anything over 1GHz, which seemed strange, given that the CPU voltage should be switching to 1.3v.
     
    I found that when measuring the voltage of the "1V2C" testpoint on the board that VDD-CPUX was always at 1.1v - it never switched to 1.3v.  I did some further examination of the board, and I was surprised to find that the "Q5" BSN20 MOSFET was not populated on the board!  I checked all of the other passives and they are present - it is like Xunlong simply decided not to stuff this part when they built the board.
     
    So, as a test, I desoldered this part from my Orange Pi Zero rev 1.4 board and soldered it in the missing "Q5" spot on my Orange Pi Zero Plus2 board.  And now it works great!  VDD-CPUX properly switches between 1.1v/1.3v (measured at the "1V2C" TP), and I can clock the board to 1.296GHz without any problems.
     
    Would anyone have an idea why Xunlong doesn't solder this part on the board by default?  They include all the other parts in this part of the power circuit, just not this MOSFET.  I was going to buy a few more of these boards, and I'd like to be able to clock them up.  Perhaps I should just order a set of these BSN20 MOSFETs and solder them on myself when I receive the boards...?
     
    Or perhaps I should just forget Xunlong/Orange Pi and use Nano Pis?  My Nano Pi Neo Plus2 has been working perfectly since I powered it up (I enabled clocking to 1.296GHz by default as well in the DTS).  By the way, I did some extensive tests and it looks like with both of these boards DVFS and thermal throttling works fine - the clock throttles back properly at the different temperature thresholds.
     
    Thank you!
     
  12. Like
    rusatch reacted to reptile in Trigger LED on Orange PI Zero Plus   
    ok, 2nd day and starting to better understand this, will explain it loudly for myself and anyone else:
     
    Though the answer was there from the beginning, too bad that it wasn't clear for meL
    http://linux-sunxi.org/GPIO
     
    First we need to "create" or "attach" the GPIO port using this command:
     
    sudo echo XX > /sys/class/gpio/export The XX is a complex calculation of the GPIO:
     
     
    so for Orange PI Zero plus 2 H5 (should be same for h3/h2) the RED led would on GPIO PA17 and GREEN LED on GPIO PL10  (Info from here: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero_Plus_2 )
    The calculation would be (Letter A is 1, the "P" not counted): (1 -0) * 32 + 17 =  17  (For RED LED) while for Green LED: (12 - 1) * 32 + 10 = 362
     
    sudo echo 362 > /sys/class/gpio/export sudo echo 17 > /sys/class/gpio/export  
    Now lets check the status of the GPIOs:
     
    cat /sys/kernel/debug/gpio gpiochip1: GPIOs 0-223, parent: platform/1c20800.pinctrl, 1c20800.pinctrl: gpio-9 ( |reset ) out hi gpio-14 ( |sysfs ) out hi gpio-17 ( |sysfs ) in lo gpio-110 ( |sysfs ) in lo gpio-166 ( |cd ) in hi IRQ gpio-204 ( |usb0_id_det ) in lo IRQ gpiochip0: GPIOs 352-383, parent: platform/1f02c00.pinctrl, 1f02c00.pinctrl: gpio-358 ( |? ) out lo gpio-362 ( |sysfs ) in lo  
    The GPIOs should be "out" direction (i guess because we are outputting to it), so lets fix them:
    sudo echo out > /sys/class/gpio/gpio362/direction sudo echo out > /sys/class/gpio/gpio17/direction  
    Now that the direction is correct, lets try to switch them on or off:
    sudo echo 1 > /sys/class/gpio/gpio362/value sudo echo 0 > /sys/class/gpio/gpio362/value sudo echo 1 > /sys/class/gpio/gpio17/value sudo echo 0 > /sys/class/gpio/gpio17/value  
    Now that the LEDs are controllable, The  next challenge would be adding some rhythm to the led per hardware occasions such as heart beet, read/write..  i hope it will be easier than above
  13. Like
    rusatch got a reaction from xalu in Orange Pi Zero Plus 2 H5 Wont turn on with SD Card   
    You have to try use this build . There is wifi working, but without 802.11n support, and without usb.