• Content Count

  • Joined

  • Last visited

Posts posted by Gavinb

  1. Hi


    I've just started work on the 5.4 kernel, will be testing that and getting relevant DTB changes into the patches. Once completed and working, I'll package things up as an overlay for those that want to use the MIPI-DSI.

    If I get a chance to afterwards, I'll have a look at the dev branch to get something working there.


  2. I'm currently looking into a new project which will use (hopefully) the Rpi Waveshare hdmi based 4" lcd touch screen, linked to the pine64/Sopine

    I'm at research stage, and will be looking into using a current 5.x kernel.

    If anyone has any info on the waveshare lcd's I need to watch out for or suggestions to get further info (specifically the touch driver side), please post a response.

    Progress on the project will be posted here, links will be added once I have some basics running.


    This can hopefully open up the waveshare displays to other devices.

    @Igor Yes I've read This post but am willing to do what I can to get Armbian to support the displays as best I can.





  3. Quote

    1. Looks like 5.6 mainline will contain all but HDMI Audio and MsgBox.  Are we likely to have an official build based on 5.6 shortly after that becomes available?

    2. Using the vagrant build method I tried cloning first just Gavinb's v9-a64-dsi branch, but got an early error in when trying to create the config file

    Should we clone the whole repo then point build at the specific branch? If so, how do we do that?


    1 - Can't say how Armbian itself will move forward, as this is a specific branch for my requirements.

    2 - Haven't worked with vagrant, so can't answer. Not that this branch has, and probably will remain fallen behind Armbian master.


  4. @karlitos Hi, haven't made any progress the last 2 weeks, am on leave for holidays and only return on the 13th Jan when I can catch up on other test's that are being done during this time by someone else. He's currently checking through other kernel builds, so will generate patches once we can comfirm we have things workings on the I2c side.

  5. Thanks  @pszypowicz problem I'm having is getting the I2C lines unlocked

    [    9.381132] i2c i2c-0: mv64xxx: I2C bus locked, block: 1, time_left: 0
    [    9.381155] Goodix-TS 0-005d: i2c test failed attempt 2: -110
    [    9.409109] Goodix-TS 0-005d: I2C communication failure: -110

    I have commited some debugging checks into the kernel, will be continuing with it today, after I sort out mac-addr issues I'm experiencing here in the office for the network changes we've had.

    Image does work on the pine64, by adding in a patch to copy the sopine-baseboard.dts over the pine64.dts, should do the same on overwrite of the pine64-lts.

  6. Hi


    I'm jumped into this, using the above mentioned kernel and trying to run it on a Pine64-Lts (Sopine) board.

    I have the Pine64 7" Lcd display which I'm trying to get running on the pine board.

    I've patched the kernel to get the dtb's into a deb file and installed into the image.

    However I'm getting a Bad Linux ARM64 Image Magic from u-boot when trying to start the kernel.

    I've also noticed that the DT_fixup_script is failing on bad format as well.

    Patchwork I've already done can be found here


    If anyone could suggest what I should be looking for to resolve the issue, I'd appreciate it.



    U-Boot SPL 2019.04-armbian (Oct 08 2019 - 12:26:14 +0200)
    DRAM: 2048 MiB
    Trying to boot from MMC1
    NOTICE:  BL3-1: Running on A64/H64 (1689) in SRAM A2 (@0x44000)
    NOTICE:  Configuring SPC Controller
    NOTICE:  BL3-1: v1.0(debug):c9f55c0
    NOTICE:  BL3-1: Built : 12:26:03, Oct  8 2019
    NOTICE:  DT: sun50i-a64-sopine-baseboard
    INFO:    Configuring AXP PMIC
    NOTICE:  PMIC: fixing DRAM voltage from 1.24V to 1.20V
    INFO:    PMIC: DRAM voltage: 1.22V
    INFO:    PMIC: setup successful
    NOTICE:  SCPI: dummy stub handler, implementation level: 000000
    INFO:    BL3-1: Initializing runtime services
    INFO:    BL3-1: Preparing for EL3 exit to normal world
    INFO:    BL3-1: Next image address: 0x4a000000, SPSR: 0x3c9
    U-Boot 2019.04-armbian (Oct 08 2019 - 12:26:14 +0200) Allwinner Technology
    CPU:   Allwinner A64 (SUN50I)
    Model: SoPine with baseboard
    DRAM:  2 GiB
    MMC:   mmc@1c0f000: 0, mmc@1c11000: 1
    Loading Environment from EXT4... *** Warning - bad CRC, using default environment
    In:    serial
    Out:   serial
    Err:   serial
    Net:   phy interface7
    eth0: ethernet@1c30000
    230454 bytes read in 12 ms (18.3 MiB/s)
    starting USB...
    USB0:   USB EHCI 1.00
    USB1:   USB OHCI 1.0
    USB2:   USB EHCI 1.00
    USB3:   USB OHCI 1.0
    scanning bus 0 for devices... 1 USB Device(s) found
    scanning bus 1 for devices... 1 USB Device(s) found
    scanning bus 2 for devices... 1 USB Device(s) found
    scanning bus 3 for devices... 1 USB Device(s) found
           scanning usb for storage devices... 0 Storage Device(s) found
    Autoboot in 1 seconds, press <Space> to stop
    switch to partitions #0, OK
    mmc0 is current device
    Scanning mmc 0:1...
    Found U-Boot script /boot/boot.scr
    3042 bytes read in 2 ms (1.5 MiB/s)
    ## Executing script at 4fc00000
    U-boot loaded from SD
    Boot script loaded from mmc
    104 bytes read in 1 ms (101.6 KiB/s)
    20693 bytes read in 4 ms (4.9 MiB/s)
    0 bytes read in 2 ms (0 Bytes/s)
    Applying kernel provided DT fixup script (sun50i-a64-fixup.scr)
    ## Executing script at 44000000
    Wrong image format for "source" command
    5408013 bytes read in 268 ms (19.2 MiB/s)
    6866080 bytes read in 339 ms (19.3 MiB/s)
    Bad Linux ARM64 Image magic!
    SCRIPT FAILED: continuing...
    Card did not respond to voltage select!


  7. Not sure about working with v3.10.y of the kernel, as am working dev level on 4.14.y (However I locked it at 4.14.59, for beta purposes).

    What I can tell you is we've been doing our own custom board, based on the R18/A64 with lpddr3 ram, so Sopine is the dev board.


    I did do some tests today, working on figuring out why cpu_freq scaling is not working, (Can post image caps later, not at work atm), and went through the following:-


    Downloaded and run Armbian script to build a fresh image Pine64so, Cli, Next, Stretch. Flashed onto an sdcard, and &^%$ it didn't boot.

    Looked at the script, and yes U-Boot is 2018.something, so reverted it to 2017.11 as the tag, and rebuilt it, (again after adding 'debs' back to the clean level)

    And what do you know, it boots this time, however Cpu_Frequency scaling still does not work :(


    I'm compared the Kernel config files between a working system, being the OrangePi Zero with what I have for the Pine based board, not much differences other than the order everything is in.


    Anyway, there's my bit in here to current known issues.



  8. Hi, yes we have.

    Just to update as well, we have managed to got the phy to respond to processor at uboot level by slowing down the MDC clock.

    Found a reference path

    our u-boot 2017.11 did not have the MDIO_CMD_MDC_DIV_128 definitions and setting up miiaddr |= MDIO_CMD_MDC_DIV_128 resolved the clock issue.


    Our next step is to resolve why the phy isn't transmitting data

  9. I am currently developing a custom board which is based of the Pine64/Pine64-R18 dev board.

    I previously had an issue with the ethernet not working at u-boot level using the sopine based R18 board, this I resolved by patching u-boot with the relevant emac sections that were missing from the device tree.


    On the custom board we have used the R18 processor with the LAN8720 ethernet-phy chip rather than the RTL8211 used by the pine, and can't get the ethernet to initialise.

    We have checked rmii clock timings etc and compared the custom board to the Pine and have noticed the following:-


    MDC has been measured to be running at 18.6Mhz, resulting in 53ns pulse periods, on both our custom and the pine64 board.

    The minimum MDC clock period for both the lan8720 and rtl8211 however is 400ns according to datasheet.

    The ethernet is not working on the LAN, yet it is on the RTL.

    It seems the RTL is capable of running at that speed, although spec is 400ns, but the LAN is conforming to it's spec.


    Any ideas on how to slow this clock speed down to the minimum 400ns period would be appreciated.






  10. I agree the pins are used for the WiFi module, however I do not have a physical device connected. I am in the process of trying to isolate those pins from it.

    However there seems to be a different issue that's arisen with the current merges going on, in the sense that the working PB based overlay, tested in 4.14.41, causes the board to go into kernel-panic mode when the kernel starts up on any newer version, I.e 42 and 43.

    I'll open a different thread for that after a bit more testing, as this can wait until we start piecing everything together in the project with it own full device-tree.




  11. Hi


    I have been trying to allocate specific gpio's as input via the Device Tree, this ultimately being for a custom made board.

    I can and have successfully allocated pins PB0, PB1, PB3 & PB5, which are showing in /dev/inputs/by-path and have been verified working with evtest.


    Working code :-

    / {
      fragment@0 {
        target = <&pio>;
        __overlay__ {
          input_0: input_0 {
            pins = "PB0";
            function = "gpio_in";
      fragment@1 {
        target-path = "/";
        __overlay__ {
          button_1 {
            compatible = "gpio-keys";
            pinctrl-names = "default";
            pinctrl-0 = <&input_0>;
            Button_1 {
              label = "Button_1";
              linux,code = <2>;
              gpios = <&pio 1 0 1>;

    However, I need to use GPIO PG2, PG3 PG4 & PG5.

    When changing the allocation, both 'pins = "PB0";' in fragment0 and 'gpios = <&pio 1 0 1>;' to PG2 and &pio 6 2 1, then overlay is successfully installed, but however not working.


    / {
      fragment@0 {
        target = <&pio>;
        __overlay__ {
          input_0: input_0 {
            pins = "PG2";
            function = "gpio_in";
      fragment@1 {
        target-path = "/";
        __overlay__ {
          button_1 {
            compatible = "gpio-keys";
            pinctrl-names = "default";
            pinctrl-0 = <&input_0>;
            Button_1 {
              label = "Button_1";
              linux,code = <2>;
              gpios = <&pio 6 2 1>;

    I have verified that the pins I intend to use are in fact IRQ pins, and can control the pins via sysfs, by manually exporting, setup and echo to toggle them.

    I've haven't seen anything that stands out in the balance of the std Device Tree structure that might be causing this issue.


    Any suggestions as to where else I could look into resolving this would be appreciated.



    Gavin B