Jump to content

Learnincurve

Members
  • Posts

    122
  • Joined

  • Last visited

Posts posted by Learnincurve

  1. Hi,

     

      Just want to check what the recommended approach is with today's dist-upgrade.

     

    I noticed that armbian-bsp-cli-pine64 was held back, so tried a manual install to see what the problem was.

     

    Seems like apt wants to remove linux-focal-root-current-pine64 to upgrade armbian-bsp-cli-pine64.

     

      Is this a temporary dependency issue?

     

    Obviously not performing the upgrade unless informed of the correct approach.

     

     

    BR.

     

     

  2. On 11/20/2020 at 8:26 PM, Digitalman1983 said:

    Has anyone had any luck getting the LCD working on newer kernels?

    Yes. This is working now!  You just need to enable it in armbian-conf and make sure the "goodix" module gets loaded at boot for the touchscreen. Ignore instructions of the download page for now, they are for the older legacy releases.

    If you have trouble with the touchscreen failing to load on reboot, see this post: 

     

  3. This is resolved now.  After reading https://www.raspberrypi.org/forums/viewtopic.php?t=216901 I created the following systemd service file:

     

    Unit]
    Description=unload the goodix driver ahead of reboots to allow it to properly load again when the system restarts

    [Service]
    ExecStop=/sbin/rmmod goodix
    Type=oneshot
    RemainAfterExit=true

    [Install]
    WantedBy=multi-user.target

     

    System now comes up with working touchscreen every time:)                                                                                                                                                  ~                                                                                                                                                     ~                        

  4. Hi Lucapinello,

     

    Thank you for the tip to make sure ts_uinput -d is running.   For me, the problem with reboot seems to be at a lower level (at goodix module load and before tslib gets loaded).

     

     I am trying to work out how to unload the goodix module before reboot, as a manual removal of the module leads to a working reboot, but am having some trouble writing a systemd service that runs early, before reboot

     

    BR.

  5. Armbianmonitor:

     5.10.4-sunxi64 pine64 board with goodix 7" mipi-dsi LCD touchscreen.

     

    The LCD output is working fine across reboots after enabling the dt overlay using armbian-config.

     

    For the touchscreen, I have added "goodix" to /etc/modules and the digitizer works fine from all cold boots:

    ~$ dmesg | grep -i goodix
    [    5.836601] Goodix-TS 1-005d: supply VDDIO not found, using dummy regulator
    [    5.843605] Goodix-TS 1-005d: ID k}\xfa, version: 7b6f
    [    5.866815] input: Goodix Capacitive TouchScreen as /devices/platform/soc/1c2ac00.i2c/i2c-1/1-005d/input/input5

     

    but a reboot leads to either:

    [    5.856172] Goodix-TS 1-005d: supply VDDIO not found, using dummy regulator
    [    5.856668] Goodix-TS 1-005d: i2c test failed attempt 1: -6
    [    5.886780] Goodix-TS 1-005d: ID k}\xfa, version: 7b6f
    [    5.909817] input: Goodix Capacitive TouchScreen as /devices/platform/soc/1c2ac00.i2c/i2c-1/1-005d/input/input5

    and the screen works

     

    or:

    $ dmesg | grep -i goodix
    [    5.862909] Goodix-TS 1-005d: supply VDDIO not found, using dummy regulator
    [    5.864033] Goodix-TS 1-005d: i2c test failed attempt 1: -6
    [    5.889397] Goodix-TS 1-005d: i2c test failed attempt 2: -6
    [    5.925072] Goodix-TS 1-005d: I2C communication failure: -6

     

    a double reboot works.

     

    It looks like the i2c bus is not being completely reset in time, but that multiple connection attempts  sometimes succeed.

     

    Can anyone suggest a workaround, to force a reset, add more i2c test iterations or provide more time to load from reboot?

     

    BR.

     

     

  6. I'm having the same problem on a Pine64-plus. 

     

    [    6.465215] WARNING: CPU: 2 PID: 34 at drivers/clocksource/arm_arch_timer.c:364 sun50i_a64_read_cntpct_el0+0x2c/0x38
    [    6.467239] Modules linked in: cpufreq_dt joydev sch_fq_codel goodix panel_feiyang_fy07024di26a30d pinctrl_axp209 realtek dwmac_sun8i mdio_mux i2c_mv64xxx pwm_bl
    [    6.470647] CPU: 2 PID: 34 Comm: kworker/2:1 Not tainted 5.10.4-sunxi64 #20.11.7
    [    6.472786] Hardware name: Pine64+ (DT)
    [    6.475136] Workqueue: events dbs_work_handler
    [    6.477389] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO BTYPE=--)
    [    6.479566] pc : sun50i_a64_read_cntpct_el0+0x2c/0x38
    [    6.481723] lr : arch_counter_get_cntpct_stable+0x3c/0x80
    [    6.483825] sp : ffff80001164ba30
    [    6.485913] x29: ffff80001164ba30 x28: ffff0000422b9a00
    [    6.488166] x27: ffff000043079f00 x26: ffff000077b6f098
    [    6.490462] x25: 0000000000000000 x24: ffff000042de0428
    [    6.492768] x23: ffff80001164bb30
    [    6.494818] hrtimer: interrupt took 27554375 ns
    [    6.496877] x22: 0000000000000001
    [    6.499039] x21: 0000000000000001 x20: 0000000000000018
    [    6.501309] x19: ffff80001144e000 x18: 0000000000000001
    [    6.503570] x17: 0000000000000018
    [    6.505752] pwm-backlight backlight: supply power not found, using dummy regulator
    [    6.507789] x16: 0000000000000002
    [    6.509935] x15: 0000000000000001 x14: 0000000000000001
    [    6.512194] x13: 0000000000000005 x12: 0000000000000021
    [    6.514410] x11: 0000000000000005 x10: 00000000bcd3d800
    [    6.516648] x9 : 0000000000000004 x8 : 0000000000000004
    [    6.518906] x7 : ffff800011411080 x6 : 00000000112a8800
    [    6.521209] x5 : 0000000000000010 x4 : 0000000000000012
    [    6.523465] x3 : 0000000000000050 x2 : 0000000015b25f37
    [    6.525690] x1 : 0000000000000000 x0 : 0000000015b25f3d
    [    6.527922] Call trace:
    [    6.530233]  sun50i_a64_read_cntpct_el0+0x2c/0x38
    [    6.532385]  __delay+0x24/0xa8
    [    6.534647]  __udelay+0x2c/0x38
    [    6.536827]  ccu_mux_notifier_cb+0x64/0xa0
    [    6.538965]  srcu_notifier_call_chain+0x70/0xc0
    [    6.541146]  __clk_notify+0x8c/0xc8
    [    6.543303]  clk_propagate_rate_change+0xc4/0xe0
    [    6.545451]  clk_core_set_rate_nolock+0x118/0x1f0
    [    6.547603]  clk_set_rate+0x38/0xa8
    [    6.549779]  dev_pm_opp_set_rate+0x258/0x5c8
    [    6.551994]  set_target+0x30/0x40 [cpufreq_dt]
    [    6.554186]  __cpufreq_driver_target+0x2b0/0x698
    [    6.556342]  od_dbs_update+0x140/0x1a0
    [    6.558463]  dbs_work_handler+0x40/0x78
    [    6.560609]  process_one_work+0x1f0/0x3c0
    [    6.562742]  worker_thread+0x140/0x520
    [    6.564895]  kthread+0x120/0x128
    [    6.567029]  ret_from_fork+0x10/0x30

    unloading the cpufreq-dt module helped somewhat, but manipulating the min/max cpu speeds does little to help.

     

    X is not installed, but I do have a simple graphical interface using FB.

     

    regarding the kworker threads eating CPU cycles I also noticed this post in a rpi forum, but not sure how to apply the recommended:

     

    dtparam=sd_poll_once dtoverlay=sdtweak,poll_once

    tweaks in Armbian.

     

  7. Hi,

     

    Thanks to the hard work of your team, the Pine64-plus touchscreen now works great with the mainline kernel and legacy images are no longer listed in the download options, but it looks like some of the instructions at https://www.armbian.com/pine64/

    are still referring to the "old way" of doing things:

     

    ie:

    Pine64’s own LCD with touchscreen support can simply be activated in /boot/armbianEnv.txt by setting pine64_lcd=on and adding gt9xxf_ts to /etc/modules followed by a reboot.

     

    The LCD screen is now activated by manipulating the DT overlays, which can even be done from armbian-config - hardware, and the touchscreen module is now called "goodix".

     

     Please can someone find the time to update the instructions on the page?

     

    BR.

     

     

  8. I found the solution at 

    I was expecting this to be called "cir something", but the device is already listed in the device tree as ir@1f02000. 

    I did a

    sudo fdtput -t s /boot/dtb/allwinner/sun50i-a64-pine64-plus.dtb /soc/ir@1f02000 status okay

    and rebooted. Device now shows up as /dev/input/event2

     

    Now all I need is to find some codes that can be used with it.

  9. Hi,

     

      Thank you all for so much work to fully implement the mainline kernel for the Pine64!

     

    So much is now working out-of-the-box with armbian, that there is no need to use the legacy version based on kernel 3.10.

     

    The pine64 does have CIR capabilities and the sunxi-cir kernel module is available, but we are still missing DT bindings for the device, although I see that an overlay file is present for the h5:

    /dts-v1/;
    
    / {
            compatible = "allwinner,sun50i-h5";
    
            fragment@0 {
                    target = <0xffffffff>;
    
                    __overlay__ {
                            pinctrl-names = "default";
                            pinctrl-0 = <0xffffffff>;
                            status = "okay";
                    };
            };
    
            __fixups__ {
                    ir = "/fragment@0:target:0";
                    r_ir_rx_pin = "/fragment@0/__overlay__:pinctrl-0:0";
            };
    };
    /tmp/sun50i-h5-cir.dtbs (END) 

       

     

    I would be very happy to try to implement and test this, if anyone can suggest changes to the overlay code, to shoehorn it into the pine64-plus DT. 

     

    Update:

    I did try the obvious, simple approach of changing the compatible line to compatible = "allwinner,sun50i-a64"

    , recompiling and changing the filename to

    /boot/overlay-user/sun50i-a64-pine64-cir.dtbo

     

    but this looks like it messes up the official 7 inch lcd overlay (blank screen) that otherwise loads fine. So looks like it needs more changes.

     

    Many thanks in advance for any suggestions!

     

    BR.

     

  10. 2 minutes ago, eminguez said:

    Nice!!!!

     

    Do you happen to have a link to download the latest nightly? https://minio.k-space.ee/armbian/dl/pine64/nightly/Armbian_21.02.0-trunk.7_Pine64_buster_current_5.9.11.img.xz seems to fail for me.

     

    Thanks.

    I cheated and upgraded to nightly from the latest stable build, which you can do from the armbian-config  - System menu. Otherwise I see that all of https://minio.k-space.ee/armbian/ is unavailable at the moment.  The link will probably work again later.

  11. :love::

     

    Issue is finally fixed in (at least) nightly builds !

     

    There is now a "pine64-7inch-lcd" overlay in /boot/dtb//allwinner/overlay

     

    Just add

     

     "overlays=pine64-7inch-lcd"

     

    to armbianEnv.txt and screen magically works.

     

    A BIG thank you to the team for fixing this! Pine64 is now ready for mainline kernel goodness!

     

    Armbian.jpg

  12. On 11/13/2020 at 3:45 PM, jeanrhum said:

    As I saw in these data:

    
    [    2.285937] sun6i-mipi-dsi 1ca0000.dsi: supply vcc-dsi not found, using dummy regulator

    Maybe it comes from there, because after searching about this error, I found these 2 links:

    - https://patchwork.kernel.org/project/linux-arm-kernel/patch/20181026144344.27778-17-jagan@amarulasolutions.com/

    - https://gitlab.com/pine64-org/linux/-/commit/6beba7fbeeeee35130dade8766c1797b498d0a3f

    And looking at your dts file with panel, I saw that the dldo1 node (phandle 0x04) is labelled as "vcc-hdmi" and it is referenced both in the dsi node (vcc-dsi-supply) and in the hdmi node (hvcc-supply). If I remember well about the legacy kernel, when you activated the panel, the hdmi didn't work anymore. So maybe you can try to deactivate the hdmi part...

    I'm a newbie about dts, so be careful about my analysis.

    Good suggestion!   I did try disabling hdmi stuff earlier (without success, but not sure if it was before or after adding the panel, so will try again).  I'm also a DTS-noob and finding it hard to get my head around it.  Hence my spamming of this thread, which it looks like the experts are now filtering out (can't say I blame them).

  13. Update:  I just took out the feiyang panel section in the device tree, as that gives the clearest dmesg indication that the dsi port is working:

     

    Quote

    vcc-mipi: Bringing 2900000uV into 3300000-3300000uV
    dmesg | grep dsi
    [    2.315495] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010da8a60)
     dmesg | grep panel
    [    2.315223] sun4i-drm display-engine: No panel or bridge found... RGB output disabled

    Have also discovered armbianmonitor -u. Dump at

    http://ix.io/2E03

     

  14. On 11/11/2020 at 7:15 PM, p1x3l3d said:

    Hey @Learnincurve, have you gotten any further with this? Do I understand correctly that you can't test it because you don't have the panel?

     

    I'd be willing to test if you'd like :) I have a Pine64-LTS with a LCD panel from Pine64 (and the 'playbox' as well) so if you want I could test stuff? Just tell me what to do!

     

    Cheers!

    Hi p1x313d.

     

      Thank you for your support!  No. The problem is not that I don't have the panel, I do.  My problem is lack of understanding and knowledge regarding the Device Tree.

     

    I am at the stage where I am stuck, unable to correctly set the pins (I think) for the panel. 

     

    @lex was able to do this, using an earlier kernel and  device tree, but too many internal references in the later available trees have changed, and I'm not smart enough to sort them out.

     

      If you or anyone else would like to help trying to debug, I'd be very grateful, as this is holding up being able to move to a mainline kernel for anyone with the Pine64+ and the feiyang panel.

     

    Here's my latest logging output:

     dmesg | grep dsi
    [    2.261142] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.263148] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.263985] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.264616] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.268920] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.269694] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.270269] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.270807] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.316217] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360)
    [    5.482679] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    5.482717] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get our reset GPIO
    [    5.482855] feiyang-fy07024di26a30d: probe of 1ca0000.dsi.0 failed with error -22

     

    attached, you can find my dtb and corresponding dts files, as well as the .dts of @lex's working example sun50i-a64-pine64+_MIPI.dts for patched kernel 5.3/5.4 . @lex's .dtb is attached to his earlier post in this thread, but I can re-attach it if it is no longer available to download. Note that mipi-dsi was only included in mainline from 5.6

     

     

     

    sun50i-a64-pine64-plus.dts sun50i-a64-pine64+_MIPI.dts

     

    sun50i-a64-pine64-plus.dtb

  15. Found that this isn't going to work without the Feiyang panel. Where I am stuck now is the reset-gpios for the feiyang panel   dts code extracted from @lex's dtb post earlier in this thread and modified with unique phandles for the current tree:

    dsi@1ca0000 {
                compatible = "allwinner,sun50i-a64-mipi-dsi";
                reg = <0x1ca0000 0x1000>;
                interrupts = <0x00 0x59 0x04>;
                clocks = <0x02 0x1c>;
                resets = <0x02 0x05>;
                phys = <0x44>;
                phy-names = "dphy";
                status = "okay";
                #address-cells = <0x01>;
                #size-cells = <0x00>;
                phandle = <0x8d>;
                vcc-dsi-supply = <0x04>;
    
                port {
    
                    endpoint {
                        remote-endpoint = <0x45>;
                        phandle = <0x20>;
                    };
                };
    
                panel@0 {
                    compatible = "feiyang,fy07024di26a30d";
                    reg = <0x00>;
                    avdd-supply = <0x41>;
                    dvdd-supply = <0xa5>;
                    reset-gpios = <0x23 0x03 0x18 0x00>;
                    backlight = <0xb2>;
                };
            };

    and the gpios and enable-gpios for the backlight and regulator:

        backlight {
            compatible = "pwm-backlight";
            pwms = <0x4f 0x00 0xc350 0x01>;
            brightness-levels = <0x00 0x0a 0x14 0x1e 0x28 0x32 0x3c 0x46 0x50 0x5a 0x64>;
            default-brightness-level = <0x08>;
            enable-gpios = <0x23 0x07 0x0a 0x00>; Probabløy incorrect
            power-supply = <0xb2>;
            phandle = <0xb1>;
        };
    
    
        vdd-backlight {
            compatible = "regulator-fixed";
            regulator-name = "vdd-backlight";
            regulator-min-microvolt = <0x325aa0>;
            regulator-max-microvolt = <0x325aa0>;
            gpio = <0x23 0x03 0x07 0x00>; Probably incorrect
            enable-active-high;
            phandle = <0xb2>;
        };

     

  16. I updated the system with the new dtb package and edited the tree again, this time without the feiyang panel.  Here are the the .dts snippets for dsi and d-phy:
                 

       dsi@1ca0000 {
                            compatible = "allwinner,sun50i-a64-mipi-dsi";
                            reg = <0x1ca0000 0x1000>;
                            interrupts = <0x00 0x59 0x04>;
                            clocks = <0x02 0x1c>;
                            resets = <0x02 0x05>;
                            phys = <0x44>;
                            phy-names = "dphy";
                            status = "okay";
                            #address-cells = <0x01>;
                            #size-cells = <0x00>;
                            phandle = <0x8d>;
                            vcc-dsi-supply = <0x04>;
    
                            port {
    
                                    endpoint {
                                            remote-endpoint = <0x45>;
                                            phandle = <0x20>;
                                    };
                            };
                    };
    
                    d-phy@1ca1000 {
                            compatible = "allwinner,sun50i-a64-mipi-dphy\0allwinner,sun6i-a31-mipi-dphy";
                            reg = <0x1ca1000 0x1000>;
                            clocks = <0x02 0x1c 0x02 0x71>;
                            clock-names = "bus\0mod";
                            resets = <0x02 0x05>;
                            status = "okay";
                            #phy-cells = <0x00>;
                            phandle = <0x44>;
                    };

     

    This time, dmesg is at least not displaying any mipi or dsi-related errors:

     

    # dmesg | grep dsi
    [    2.318045] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360)

    ~# dmesg | grep mipi
    [    2.275838] vcc-mipi: Bringing 2900000uV into 3300000-3300000uV

     

    so definitely closer.

     

    Now I'm going to re-visit the thread and armbian documentation to see what needs to be done to enable.

     

     

  17. I found the following code at https://mjmwired.net/kernel/Documentation/devicetree/bindings/display/panel/feiyang,fy07024di26a30d.txt:

     

    Feiyang FY07024DI26A30-D 7" MIPI-DSI LCD Panel
    
    Required properties:
    - compatible: must be "feiyang,fy07024di26a30d"
    - reg: DSI virtual channel used by that screen
    - avdd-supply: analog regulator dc1 switch
    - dvdd-supply: 3v3 digital regulator
    - reset-gpios: a GPIO phandle for the reset pin
    
    Optional properties:
    - backlight: phandle for the backlight control.
    
    panel@0 {
    		compatible = "feiyang,fy07024di26a30d";
    		reg = <0>;
            avdd-supply = <&reg_dc1sw>;
            dvdd-supply = <&reg_dldo2>;
            reset-gpios = <&pio 3 24 GPIO_ACTIVE_HIGH>; /* LCD-RST: PD24 */ backlight = <&backlight>;
    };

     

    In the regulatotrs section of my active dtb -> dts file I find

     

      reg_dc1sw = "/soc/rsb@1f03400/pmic@3a3/regulators/dc1sw";
                    reg_dcdc1 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc1";
                    reg_dcdc2 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc2";
                    reg_dcdc3 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc3";
                    reg_dcdc4 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc4";
                    reg_dcdc5 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc5";
                    reg_dcdc6 = "/soc/rsb@1f03400/pmic@3a3/regulators/dcdc6";
                    reg_dldo1 = "/soc/rsb@1f03400/pmic@3a3/regulators/dldo1";
                    reg_dldo2 = "/soc/rsb@1f03400/pmic@3a3/regulators/dldo2";

     

    but after editing the dts file like:

     

    panel@0 {
                                    compatible = "feiyang,fy07024di26a30d";
                                    reg = <0x00>;
                                    avdd-supply = <&reg_dc1sw>;
                                    dvdd-supply = <&reg_dldo2>;
                                    reset-gpios = <0x23 0x03 0x18 0x00>;
                                    backlight = <0x43>;
                            };

     

    It won't compile, so obviously I don't understand. Any tips?

  18. Closer again.

     

      I'm now using the latest "Armbian Focal mainline based kernel 5.8.y" image,  including the updated dtb .deb update.

     

      I have modified the dtb, changing the dsi section to "okay", and adding the vcc-dsi line and the feiyang panel subsection.

     

      This is what I'm getting:

    dmesg | grep dsi
    [    2.263813] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.265832] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.266675] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.267313] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.271430] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.272127] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.272671] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.273211] OF: /soc/dsi@1ca0000/panel@0: could not get #gpio-cells for /soc/hdmi@1ee0000/ports/port@0/endpoint
    [    2.318595] sun4i-drm display-engine: bound 1ca0000.dsi (ops 0xffff800010daf360)
    [    6.716321] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    6.724523] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    6.739883] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    6.752834] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    6.768429] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    6.784961] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    6.788281] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    6.856971] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    7.081487] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    7.120322] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator
    [    7.838355] feiyang-fy07024di26a30d 1ca0000.dsi.0: [drm:feiyang_dsi_probe [panel_feiyang_fy07024di26a30d]] *ERROR* Couldn't get dvdd regulator

     

    Any advice on the feiyang dvdd regulator?

     

     

     

  19. Closer:

    dmesg | grep dsi
    [    2.179940] OF: /soc/dsi@1ca0000: could not get #phy-cells for /soc/pinctrl@1c20800/rgmii-pins
    [    2.179949] sun6i-mipi-dsi 1ca0000.dsi: Couldn't get the MIPI D-PHY

     

    Looking at the         pinctrl@1c20800  section, there are quite a few differences between the original and @lex's file, so not sure how much to transpose.

     

     

    Transposing the whole section is giving far more duplicated phandle errors, so stopping here. 

    dtc -f -O dtb -o sun50i-a64-pine64-plus.dtb sun50i-a64-pine64-plus_EDITED.dts
    sun50i-a64-pine64-plus_EDITED.dts:722.13-726.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/csi-pins: duplicated phandle 0x3e (seen before at /soc/syscon@1c00000)
    sun50i-a64-pine64-plus_EDITED.dts:742.14-748.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/mmc0-pins: duplicated phandle 0x21 (seen before at /soc/bus@1000000/mixer@100000/ports/port@1/endpoint@1)
    sun50i-a64-pine64-plus_EDITED.dts:750.14-756.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/mmc1-pins: duplicated phandle 0x24 (seen before at /soc/syscon@1c00000/sram@1d00000/sram-section@0)
    sun50i-a64-pine64-plus_EDITED.dts:791.17-795.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/spdif-tx-pin: duplicated phandle 0x2c (seen before at /soc/phy@1c19400)
    sun50i-a64-pine64-plus_EDITED.dts:815.15-819.6: ERROR (explicit_phandles): /soc/pinctrl@1c20800/uart1-pins: duplicated phandle 0x2f (seen before at /soc/dma-controller@1c02000)
    sun50i-a64-pine64-plus_EDITED.dts:1249.14-1252.7: ERROR (explicit_phandles): /soc/dsi@1ca0000/port/endpoint: duplicated phandle 0x1c (seen before at /soc/lcd-controller@1c0c000/ports/port@0/endpoint@1)
    sun50i-a64-pine64-plus_EDITED.dts:1312.15-1315.8: ERROR (explicit_phandles): /soc/hdmi@1ee0000/ports/port@0/endpoint: duplicated phandle 0x23 (seen before at /soc/pinctrl@1c20800)
    sun50i-a64-pine64-plus_EDITED.dts:1341.15-1350.5: ERROR (explicit_phandles): /soc/rtc@1f00000: duplicated phandle 0x2e (seen before at /soc/pinctrl@1c20800/uart0-pb-pins)
    sun50i-a64-pine64-plus_EDITED.dts:1417.19-1453.5: ERROR (explicit_phandles): /soc/pinctrl@1f02c00: duplicated phandle 0x35 (seen before at /soc/pinctrl@1c20800/i2c0-pins)
    Warning: Input tree has errors, output forced

     

    Hopefully someone who knows anything about dtb (as I know nothing), will be able to sort out the mess and post back with advice or edited file

     

     

  20. Hi @lex and thank you for responding!  I do have a 2GB Pine64+, so would be very interested to take a look at your .dtb

     

    If you could make it available on/to this thread that would be really great!  My guess is that is should also work with the latest kernel.

     

    BR.

     

    --Marius--

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines