Support for orange pi 3 lts

[Ukilana]

Please add support for orange pi 3 lts. I have this board, ready to do all the tests. I tried to install the version from OPi 3, but wi-fi and bluetooth did not work. Being an inexperienced developer, I tried to replace files with files from stock firmware, but nothing came of it. I can also provide the Android source code from the manufacturer, if it helps you. Thanks

[Sekilsgs2]

I'm trying install opi 3 image to lts version - butr always getting many errors about misc partitions and other.. Please say how i'm need install opi 3 images to lts version?

[afaulkner420]

Wifi and Bluetooth won't work on any kernel above 5.10.y at the moment. The driver hasn't been successfully ported. I am currently working on bringing up the board, and supporting it on armbian. As soon as this is done, and everything is working, you will probably find out some how! Feel free to try my images as I'm uploading them!

Check this forum

https://forum.armbian.com/topic/19846-orange-pi3-lts/page/5/#comment-137176

[Sekilsgs2]

i'm successful run glodroid on opi 3 lts. But interface very slow - why? Panfrost running - where maybe problem?

[rsglobal]

@Sekilsgs2 ,

Nice, thanks )

Today I've received opi3-lts as well and got the following issue:

[    2.739623] sun50i-h6-pinctrl 300b000.pinctrl: request() failed for pin 65
[    2.746507] sun50i-h6-pinctrl 300b000.pinctrl: pin-65 (4022000.mmc) status -517
[    2.753736] sun50i-h6-pinctrl 300b000.pinctrl: could not request pin 65 (PC1) from group PC1  on device 300b000.pinctrl
[    2.754213] sunxi-mmc 4022000.mmc: Error applying setting, reverse things back

How did you solved it?

[Sekilsgs2]

Today I've received opi3-lts as well and got the following issue:

Good day bro :)

First need axp806 working - if no - change rsb to i2c And some pacthes -

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
index 40be5ad6d..3c6e9e875 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi
@@ -566,8 +566,7 @@
        };

        mmc2: mmc@4022000 {
-           compatible = "allwinner,sun50i-h6-emmc",
-                    "allwinner,sun50i-a64-emmc";
+           compatible = "allwinner,sun50i-h6-emmc";
            reg = <0x04022000 0x1000>;
            clocks = <&ccu CLK_BUS_MMC2>, <&ccu CLK_MMC2>;
            clock-names = "ahb", "mmc";

diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index dd1c2a610..9a641c7d2 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -1221,6 +1221,7 @@ static const struct of_device_id sunxi_mmc_of_match[] = {
    { .compatible = "allwinner,sun50i-a64-mmc", .data = &sun50i_a64_cfg },
    { .compatible = "allwinner,sun50i-a64-emmc", .data = &sun50i_a64_emmc_cfg },
    { .compatible = "allwinner,sun50i-h5-emmc", .data = &sun50i_h5_emmc_cfg },
+   { .compatible = "allwinner,sun50i-h6-emmc", .data = &sun50i_a64_emmc_cfg },
    { .compatible = "allwinner,sun50i-a100-mmc", .data = &sun50i_a100_cfg },
    { .compatible = "allwinner,sun50i-a100-emmc", .data = &sun50i_a100_emmc_cfg },
    { /* sentinel */ }
@@ -1434,7 +1435,7 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
                  MMC_CAP_SDIO_IRQ;

    /*
-    * Some H5 devices do not have signal traces precise enough to
+    * Some H5 and H6 devices do not have signal traces precise enough to
     * use HS DDR mode for their eMMC chips.
     *
     * We still enable HS DDR modes for all the other controller
@@ -1443,6 +1444,8 @@ static int sunxi_mmc_probe(struct platform_device *pdev)
    if ((host->cfg->clk_delays || host->use_new_timings) &&
        !of_device_is_compatible(pdev->dev.of_node,
                     "allwinner,sun50i-h5-emmc") &&
+       !of_device_is_compatible(pdev->dev.of_node,
+                    "allwinner,sun50i-h6-emmc") &&
        !of_machine_is_compatible("allwinner,sun7i-a20") &&
        !of_machine_is_compatible("olimex,a64-olinuxino-2ge8g"))
        mmc->caps      |= MMC_CAP_1_8V_DDR | MMC_CAP_3_3V_DDR;

[Sekilsgs2]

And if uboot fail for axp chip - kernel fail too - need using ATF v2.2..

[Sekilsgs2]

lts version have bug - RSB not working for axp chip.. tested on different uboot versions and ATF - if change to i2c - all working and with latest ATF 2.4 or 2.5

[Sekilsgs2]

Please say why UI performance very bad - animations very slow and overal UI performance very bad for this HW configuration (on stock 9 android from orange pi - ui performance very good) - what is the reason for this? How i'm can proper debug perfomance issue ?

[rsglobal]

You can try https://perfetto.dev/ tracing

[rsglobal]

https://ui.perfetto.dev/#!/record/android

[Sekilsgs2]

Yes im find this. But kernel dont have proper configs for ftrace - im trying recompile with needed and try again. Current kernel dont have any useful info without needed configs

[Sekilsgs2]

Here trace file for perfetto or GPU inspector.. https://mega.nz/file/gGpWjYyS#Rou5jsVR7X7SaKqX_KnEuNVGThR96WHvDWUEFIJojzw

I'm see that renderthread from app settings have very very unstable time of drawed frame - needed 16.5 ms but we have 15~28ms - i'm see that we have many time to dequeueBuffers and queueBuffers. How you think about this trace - where maybe problem? Bo managment in Mesa (panfrost)?

[rsglobal]

Not sure, but looks like some CPU overhead.

Try setting debug.renderengine.backend property to threaded

[rsglobal]

You can also use simpleperf to see distribution of the function calls during setting scrolling.

[rsglobal]

Also you can enable performance bars:

adb shell setprop debug.hwui.profile visual_bars
adb shell stop
adb shell start

[rsglobal]

Also setting debug.hwui.show_layers_updates to true will help to identify regions which required full redraw (and such redraws consumes more CPU!)

[rsglobal]

Probably I can't help you further. I don't have much experience in debugging UI performance.

[rsglobal]

One more link related to lags caused by stretch effect: https://support.google.com/pixelphone/thread/132936922/how-to-turn-of-android-12-overscroll?hl=en

[Sekilsgs2]

Also you can enable performance bars:

adb shell setprop debug.hwui.profile visual_bars
adb shell stop
adb shell start

Yes i'm did this first and see that no frames with good timing - all frame above green line :) This meant that we have terrible UI performance (( Need trace all functions which make things too long..

[Sekilsgs2]

Current i'm cant find who make cpu loading every frame - maybe you can explain me some info - You can see from screenshot - https://mega.nz/file/gP4VBIDY#vqD7BFuvxk5gR-y1GBPNsiY5TrMhtdJVZgcVS86vWKU

that many many time each frame spend for dequebuffer - who make this ? where in source code - mesa3d, gbm_mesa, panfrost or ?

[rsglobal]

@Sekilsgs2 ,

Panfrost interaction with Android isn't optimized well. 1/3 of DrawFrame time can be reduced only by just caching fb->handle importing and other expensive stuff.

[Sekilsgs2]

@Sekilsgs2 ,

Panfrost interaction with Android isn't optimized well. 1/3 of DrawFrame time can be reduced only by just caching fb->handle importing and other expensive stuff.

But panfrost have bo caching in mesa driver - this not helping?

[rsglobal]

Only for cases when buffer is created by the same process. Android imports buffers which for some reason takes a lot of time. You can see it using inferno tool.

вт, 17 мая 2022 г., 20:31 Sekilsgs2 @.***>:

@Sekilsgs2 https://github.com/Sekilsgs2 ,

Panfrost interaction with Android isn't optimized well. 1/3 of DrawFrame time can be reduced only by just caching fb->handle importing and other expensive stuff.

But panfrost have bo caching in mesa driver - this not helping?

— Reply to this email directly, view it on GitHub https://github.com/GloDroid/glodroid_manifest/issues/187#issuecomment-1129133782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIU6BI5K5QCKOHMPY3UPDZTVKPJWNANCNFSM5RBRA3GA . You are receiving this because you commented.Message ID: @.***>

[Sekilsgs2]

Only for cases when buffer is created by the same process. Android imports buffers which for some reason takes a lot of time. You can see it using inferno tool.

mdaa.. to find where problem need know where this is delay

[rsglobal]

Try this one: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16583

[rsglobal]

@Sekilsgs2 ,

You can also apply this hunk to mesa3d, which will make all GPU rendering synchronous and capture the perfetto trace again. This time it will be much easier explore the trace.

diff --git a/src/gallium/frontends/dri/dri_helpers.c b/src/gallium/frontends/dri/dri_helpers.c
index b158808c79291..f4cbcbab631e3 100644
--- a/src/gallium/frontends/dri/dri_helpers.c
+++ b/src/gallium/frontends/dri/dri_helpers.c
@@ -113,10 +113,14 @@ dri2_create_fence_fd(__DRIcontext *_ctx, int fd)
    struct st_context_iface *stapi = dri_context(_ctx)->st;
    struct pipe_context *ctx = stapi->pipe;
    struct dri2_fence *fence = CALLOC_STRUCT(dri2_fence);
+   struct dri_screen *driscreen = dri_screen(_ctx->driScreenPriv);
+   struct pipe_screen *screen = driscreen->base.screen;

    if (fd == -1) {
       /* exporting driver created fence, flush: */
       stapi->flush(stapi, ST_FLUSH_FENCE_FD, &fence->pipe_fence, NULL, NULL);
+      screen->fence_finish(screen, NULL, fence->pipe_fence, -1);
    } else {
       /* importing a foreign fence fd: */
       ctx->create_fence_fd(ctx, &fence->pipe_fence, fd, PIPE_FD_TYPE_NATIVE_SYNC);

[Sekilsgs2]

@Sekilsgs2 ,

You can also apply this hunk to mesa3d, which will make all GPU rendering synchronous and capture the perfetto trace again. This time it will be much easier explore the trace.

diff --git a/src/gallium/frontends/dri/dri_helpers.c b/src/gallium/frontends/dri/dri_helpers.c
index b158808c79291..f4cbcbab631e3 100644
--- a/src/gallium/frontends/dri/dri_helpers.c
+++ b/src/gallium/frontends/dri/dri_helpers.c
@@ -113,10 +113,14 @@ dri2_create_fence_fd(__DRIcontext *_ctx, int fd)
    struct st_context_iface *stapi = dri_context(_ctx)->st;
    struct pipe_context *ctx = stapi->pipe;
    struct dri2_fence *fence = CALLOC_STRUCT(dri2_fence);
+   struct dri_screen *driscreen = dri_screen(_ctx->driScreenPriv);
+   struct pipe_screen *screen = driscreen->base.screen;

    if (fd == -1) {
       /* exporting driver created fence, flush: */
       stapi->flush(stapi, ST_FLUSH_FENCE_FD, &fence->pipe_fence, NULL, NULL);
+      screen->fence_finish(screen, NULL, fence->pipe_fence, -1);
    } else {
       /* importing a foreign fence fd: */
       ctx->create_fence_fd(ctx, &fence->pipe_fence, fd, PIPE_FD_TYPE_NATIVE_SYNC);

Thanks! But if you have build for rpi3 lts - it would be great, because im dont have hdd space now for building android :(

[rsglobal]

Looks like PLLs aren't set correctly, so we have only about a half of CPU GPU DRAM ... frequencies.

[Sekilsgs2]

Looks like PLLs aren't set correctly, so we have only about a half of ~CPU~ GPU DRAM ... frequencies.

Kernel issues?

[rsglobal]

I just read PLL register using devmem tool. Calculated real frequency by the formula from H6 user manual, then I updated GPU and DRAM clock register while playing with UI and performance noticeably changed. Not 60FPS yet, but much better than before. There are panfrost driver issues which may contribute to the performance as well.

So I have no idea if it kernel issues or not )

[rsglobal]

GPU:
# devmem 0x3001030 
0xb0002301 ---------------------v
      ^^ (((0x23+1) * 24Mhz ) / 2) = 432MHz

720MHz (0xb0003b01) seems to work fine. 780MHz - system starts lagging

[Sekilsgs2]

GPU:
# devmem 0x3001030 
0xb0002301 ---------------------v
      ^^ (((0x23+1) * 24Mhz ) / 2) = 432MHz

720MHz (0xb0003b01) seems to work fine. 780MHz - system starts lagging

Im using this patch for my edited kernel - but ui performance not good. https://github.com/clementperon/linux/commit/2f34555fd93c852276f449be1cf5b5168b8f55f8

[rsglobal]

Aha. Thanks for the patch. I will include it into the GD kernel + add DRAM freq bump.

[rsglobal]

You may also try latest updates from v0.7.6. for better UI performance.

[rsglobal]

Board manufacturer (Xunlong) is the only company that has a profit from selling their devices. GloDroid team will add OPI3 LTS support once this board will be supported by the kernel.org, or at least we will see any up-streaming activity.

[fcassia2017]

Dear @Sekilsgs2 and @rsglobal could you please share a SD image of whatever build you got running on the Orange pi 3 LTS, so we can do further testing? Thanks in advance.