Orangepi 3 h6 allwiner chip

[martinayotte]

15 hours ago, AZ8 said:

Is this a proper way to install boot? I do not want to tun nand-sata-install and erase mmc.

That is really not the way to install Armbian to eMMC !

Why you don't want to use nand-sata-install ?

[AZ8]

14 minutes ago, martinayotte said:

That is really not the way to install Armbian to eMMC !

Why you don't want to use nand-sata-install ?

Because I dont want to erase mmc

 

If this is not possible, I will backup partition with dd, install using nand-sata-install  and restore partition from backup

[martinayotte]

17 minutes ago, AZ8 said:

Because I dont want to erase mmc

 

If this is not possible, I will backup partition with dd, install using nand-sata-install  and restore partition from backup

Why ?

Restoring a backup could lead to trouble too ... Restoring /boot/armbianEnv.txt and /etc/fstab could lead to trouble too ...

[062621AM]

11 hours ago, AZ8 said:

Because I dont want to erase mmc

 

If this is not possible, I will backup partition with dd, install using nand-sata-install  and restore partition from backup

Copy out your program config and files?

[GeorgeP]

Remember that the H6 boards are still very much in development stage.

If you aren't prepared to lose some data then IMHO you should choose a more stable platform.

 

[JORGETECH]

Has anyone tried out Panfrost in this device? I used this guide to compile both DRM and Mesa but glxinfo still reports llvmpipe in use. I am running armbian's sunxi-dev 5.3.6 kernel, does that version have the necessary patches or do I need another kernel?

[LukeHack]

I'm using it since the 19/10/08 kernel release, no problem with glxgear nor compositing, glxinfo tell me direct rendering is enable, the driver support

also good video decoding..

i'm waiting for h264 encoding support.. then i will total happy

[LukeHack]

18 hours ago, JORGETECH said:

Has anyone tried out Panfrost in this device? I used this guide to compile both DRM and Mesa but glxinfo still reports llvmpipe in use. I am running armbian's sunxi-dev 5.3.6 kernel, does that version have the necessary patches or do I need another kernel?

You'd better try the new kernel release, i made it work w/o recompiling anything, just apt full-upgrade on armbian, switch to the new kernel and it will be ok

[JORGETECH]

On 10/19/2019 at 12:03 PM, LukeHack said:

You'd better try the new kernel release, i made it work w/o recompiling anything, just apt full-upgrade on armbian, switch to the new kernel and it will be ok

Did you build Mesa and DRM from source?

[jcaron]

On 10/18/2019 at 11:52 PM, LukeHack said:

I'm using it since the 19/10/08 kernel release, no problem with glxgear nor compositing, glxinfo tell me direct rendering is enable, the driver support

also good video decoding..

i'm waiting for h264 encoding support.. then i will total happy

 

Hi, could you provide a few more details about how you got this to work? I just can't get X to use panfrost on my Orange Pi 3, it's stuck on llvmpipe.

 

Kernel:

Linux orangepi3 5.3.7-sunxi64 #5.98.191020 SMP Sun Oct 20 02:43:11 CEST 2019 aarch64 GNU/Linux

 

Logs about panfrost:

sun4i-drm display-engine: bound 1100000.mixer (ops 0xffff000010becf50)
sun4i-drm display-engine: bound 6510000.tcon-top (ops 0xffff000010bf1138)
sun4i-drm display-engine: bound 6515000.lcd-controller (ops 0xffff000010be9450)
sun4i-drm display-engine: bound 6000000.hdmi (ops 0xffff000010bec2f8)
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] No driver support for vblank timestamp query.
[drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0
sun4i-drm display-engine: fb0: sun4i-drmdrmfb frame buffer device
panfrost 1800000.gpu: clock rate = 432000000
panfrost 1800000.gpu: bus_clock rate = 100000000
panfrost 1800000.gpu: mali-t720 id 0x720 major 0x1 minor 0x1 status 0x0
panfrost 1800000.gpu: features: 00000000,10309e40, issues: 00000000,21054400
panfrost 1800000.gpu: Features: L2:0x07110206 Shader:0x00000000 Tiler:0x00000809 Mem:0x1 MMU:0x00002821 AS:0xf JS:0x7
panfrost 1800000.gpu: shader_present=0x3 l2_present=0x1
[drm] Initialized panfrost 1.0.0 20180908 for 1800000.gpu on minor 1

Mesa is 19.3.0 from packages (it was bumped to this version a few days ago).

 

I added a file /etc/X11/xorg.conf.d/02-panfrost.conf containing:

Section "ServerFlags"
        Option  "AutoAddGPU" "off"
        Option "Debug" "dmabuf_capable"
EndSection

Section "OutputClass"
        Identifier "Panfrost"
        MatchDriver "sun4i-drm"
        Driver "modesetting"
        Option "PrimaryGPU" "true"
EndSection

But still nothing but llvmpipe.

 

Did I miss something? Does the mesa from packages include panfrost support? Should I build from source? If you built from source, what options did you use?

 

Thanks!

 

[PiotrO]

3 hours ago, jcaron said:

I'm using it since the 19/10/08 kernel release, no problem with glxgear nor compositing, glxinfo tell me direct rendering is enable, the driver support

@jcaron

Are You using mesa on t720 or mali blob?

 

 

[jcaron]

12 hours ago, PiotrO said:

@jcaron

Are You using mesa on t720 or mali blob?

 

 

 

I'm not sure I understand the question, but I'm using Panfrost (or at least trying to), which as far as I understand, is the blob-less driver.

 

Not quite sure whether mesa from packages is actually configured with panfrost support, though, is there a way to check that?

[megi]

20 hours ago, jcaron said:

Did I miss something? Does the mesa from packages include panfrost support? Should I build from source? If you built from source, what options did you use?

 

Thanks!

 

T720 is blacklisted by panfrost driver in mesa.

[jcaron]

1 minute ago, megi said:

T720 is blacklisted by panfrost driver in mesa.

 

Ah indeed, I see that it's actually not whitelisted in the mesa panfrost driver. I also see the mesa panfrost driver blacklists Chromium which is my target use case, so it seems the panfrost+mesa route is not yet viable.

 

So what options are there to be able to use the T720 GPU at the moment, if any?

 

* Only using vendor system images such as those provided

* Use armbian + binary driver + X11 driver (e.g. as described here: https://linux-sunxi.org/Xorg + https://linux-sunxi.org/Mali_binary_driver)? Is this actually applicable to the T720 or just the Mali 400 (probably with different drivers)?

 

In the latter case (if that is even possible), is there any automated process to achieve that (e.g. download a specific Armbian image, install specific packages...) or is still a very manual process?

 

Thanks in advance for any hints!

[JORGETECH]

4 hours ago, jcaron said:

 

Ah indeed, I see that it's actually not whitelisted in the mesa panfrost driver. I also see the mesa panfrost driver blacklists Chromium which is my target use case, so it seems the panfrost+mesa route is not yet viable.

 

So what options are there to be able to use the T720 GPU at the moment, if any?

 

* Only using vendor system images such as those provided

* Use armbian + binary driver + X11 driver (e.g. as described here: https://linux-sunxi.org/Xorg + https://linux-sunxi.org/Mali_binary_driver)? Is this actually applicable to the T720 or just the Mali 400 (probably with different drivers)?

 

In the latter case (if that is even possible), is there any automated process to achieve that (e.g. download a specific Armbian image, install specific packages...) or is still a very manual process?

 

Thanks in advance for any hints!

Forget about using the binary driver in armbian. ARM only provides binary drivers for select boards and of course the Orange Pi 3 in not one of them (and none of those boards even have a T720 to begin with), in theory you can compile the drivers from ARM yourself but you need their commercial DDK to compile them (nasty!).

 

Debian does provide binary drivers for some Midgard GPUs in their "contrib" and "non-free" repos, but there is none for the T720 (I guess that is because ARM does not provide them).

 

I have not tried Xunlong's system images so I don't know if they have binary drivers included but even if they had them they would be for the ancient BSP 3.4.x kernel.

 

And I was not aware of the Mali T720 blacklist in Mesa, is that really true? I read some IRC logs where they were testing the Mali T720 so that seems a bit weird and it does not seem as something that could not be reenabled in compile time.

 

EDIT:

 

Ok, so I found Mali T720 H6 userspace binary drivers here: https://github.com/jernejsk/H6-mali-userspace

 

I guess those drivers are from the Android port (and maybe the vendor Linux images), I remember there was a way to use that kind of drivers using something called "libhybris" but I've never tried that so I don't have any experience with that approach.

Edited October 21, 2019 by JORGETECH
Additional information

[jernej]

@JORGETECH You found Mali T720 fbdev drivers on my github account. I can assure you that they are not Android related. However, using this fbdev driver is very painful on mainline kernel. I guess it's meant to be used with BSP kernel. I had to make one hack in mainline kernel in order to use it, but I don't have patch for that anymore. There is also proper wayland and gbm version for Mali T720, which is hosted on pine64.org wiki. Note that gbm version is successfully used in LibreELEC with mainline kernel. So there is a possibility to use binary driver, it's just that there is no guide how to use it. I would prefer panfrost but unfortunately, support for T720 is in very early stage.

[dolphs]

hi - would it be possible to bump dev build to " KERNELBRANCH="branch:orange-pi-5.4" please,

as the H6 boards, eg "orangepioneplus", are in WIP anyway?

 

Yet manually updated  "~/armbian/config/sources/sun50iw6.conf ", but no success compiling with 

" ./compile.sh BRANCH=dev RELEASE=buster BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no EXPERT=yes BUILD_MINIMAL=yes "

This result in dtb issues :

  DTC     arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dtb
  DTC     arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dtb
scripts/Makefile.lib:306: recipe for target 'arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dtb' failed
scripts/Makefile.lib:306: recipe for target 'arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dtb' failed
scripts/Makefile.build:509: recipe for target 'arch/arm64/boot/dts/allwinner' failed
Makefile:1244: recipe for target 'dtbs' failed
[ error ] ERROR in function compile_kernel [ compilation.sh:382 ]
[ error ] Kernel was not built [ @host ]
[ o.k. ] Process terminated

 

[Werner]

Patches probably have to be cleaned up since some are most likely merged into upstream and now obsolete.

Check if any of them failed to apply and why.

Some patches can be applied even though their content has been merged to upstream already. Go to the log directory and check where exactly the error has occurred.

 

The other solution would be being patient until @martinayotte finds some free time to play with 5.4 sources

[martinayotte]

8 hours ago, Werner said:

until @martinayotte finds some free time to play with 5.4 sources

I will try to find some free time, which still the "missing ingredient" ...

[dolphs]

19 hours ago, Werner said:

Some patches can be applied even though their content has been merged to upstream already. Go to the log directory and check where exactly the error has occurred.

 

cheers for that, just attached logs from "~/armbian/output/debug ", grep-ped on FAILED, failed, error etc but too many bogus ( warnings ) for me atm

 

10 hours ago, martinayotte said:

I will try to find some free time, which still the "missing ingredient" ...

would be so much appreciated :-), hope u have time to quickly browse to the logs attached

 

TiA!

logs.tar.gz

[Werner]

duplicate_node_names

As guessed probably duplicate entries due to merges into upstream.

 

Just did a quick look, maybe you can find something here:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi?h=v5.4-rc4

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64/boot/dts/allwinner/sun50i-h6-orangepi-3.dts?h=v5.4-rc4

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/log/arch/arm64/boot/dts/allwinner/sun50i-h6-beelink-gs1.dts?h=v5.4-rc4

Compare the latest commits with the patches Armbian provides and check for duplicates. Disable certain patches and it MAY compile just fine.

[martinayotte]

7 hours ago, Werner said:

Disable certain patches and it MAY compile just fine.

I think so too ...

[JORGETECH]

On 10/21/2019 at 7:38 PM, jernej said:

@JORGETECH You found Mali T720 fbdev drivers on my github account. I can assure you that they are not Android related. However, using this fbdev driver is very painful on mainline kernel. I guess it's meant to be used with BSP kernel. I had to make one hack in mainline kernel in order to use it, but I don't have patch for that anymore. There is also proper wayland and gbm version for Mali T720, which is hosted on pine64.org wiki. Note that gbm version is successfully used in LibreELEC with mainline kernel. So there is a possibility to use binary driver, it's just that there is no guide how to use it. I would prefer panfrost but unfortunately, support for T720 is in very early stage.

So in theory the GBM version could be used? Is it possible to use Xorg on top of GBM or do you have to use Wayland (+ xwayland)?

[jernej]

10 minutes ago, JORGETECH said:

So in theory the GBM version could be used?

GBM version is already used in LE, just not for any kind of desktop environment, but for direct rendering.

11 minutes ago, JORGETECH said:

Is it possible to use Xorg on top of GBM or do you have to use Wayland (+ xwayland)?

AFAIK you need X11 version for Xorg, but yes, GBM is needed for Wayland server, whereas wayland version is used by wayland clients. Usually GBM and wayland support are combined into one mali blob, but IIRC, for T720, there are two separate blobs.

[dolphs]

Hi - In an effort to get this going I failed hopelessly ...

Logs say basically grepping on duplicate the "sun50i-h6.dtsi" patch should be disabled

compilation.log:arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:707.21-719.5: ERROR (duplicate_node_names): /soc/i2c@5002000: Duplicate node name
compilation.log:arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:721.21-733.5: ERROR (duplicate_node_names): /soc/i2c@5002400: Duplicate node name
compilation.log:arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:735.21-747.5: ERROR (duplicate_node_names): /soc/i2c@5002800: Duplicate node name
compilation.log:arch/arm64/boot/dts/allwinner/sun50i-h6.dtsi:1177.18-1185.5: ERROR (duplicate_node_names): /soc/ir@7040000: Duplicate node name

So tried to disable it by creating empty file sun50i-h6.dtsi.patch in to ~/armbian/userpatches ,but alas

Meanwhile will do some more digging as I expect more to come as rc5 has seen the light ( but dev kernel is still on kernel [ 5.4.0-rc4 ] ) and in the end I hopefully learnt how to properly exclude armbian patches

TiA! :-)

[martinayotte]

38 minutes ago, dolphs said:

So tried to disable it by creating empty file sun50i-h6.dtsi.patch in to ~/armbian/userpatches ,but alas

When trying to upgrade to newer branch, what I'm usually do when such duplicate nodes appears, instead of disabling patches, I comment out the duplicate offending nodes, and then compile.

Anyway, I will try to find some "missing time ingredient" in the following days, and Armbian will then be ready for a commit ...

[dolphs]

I should dive in to this as I am unable to find where to comment it (out).

Last thing that ran through my mind is wether boot should stay on april version or can we move to the october one which is tagged three weeks ago?

[megi]

If anyone wants to see their H6 SoC bin (how efficient/fast your SoC is/overclocking potential), you can use this tool:

 

https://megous.com/dl/tmp/regtool

 

Download it, make it executable, and run it as: ./regtool h6-soc-bin

 

My output:

SoC bin: slow chip (bin=1)

[megi]

Actually, turns out, it's not entirely clear what efuse value<->soc bin mapping is actually used, because Allwinner code is a bit confusing. So I encourage H6 board owners to run this tool and post results, so that we can figure out how to make CPU bin<->OPP mapping work in mainline Linux.

[martinayotte]

1 hour ago, megi said:

So I encourage H6 board owners to run this tool and post results,

I've ran it on all my H6, all of them (OPiOne+, OPi3 and PineH64) reports "SoC bin: slow chip (bin=1)" except my OPiLite2 which gives "SoC bin: normal chip (bin=3)"

So, I presume you wish to see its dump_h6_ths :

 

 

THS:
0x05070400 : 01df002f
0x05070404 : 00000003
0x05070408 : 0016d000
0x0507040c : 00000000
0x05070410 : 00000003
0x05070414 : 00000000
0x05070418 : 00000000
0x0507041c : 00000000
0x05070420 : 00000000
0x05070424 : 00000000
0x05070428 : 00000000
0x0507042c : 00000000
0x05070430 : 00000005
0x05070434 : 00000000
0x05070438 : 00000000
0x0507043c : 00000000
0x05070440 : 05a00684
0x05070444 : 05a00684
0x05070448 : 00000000
0x0507044c : 00000000
0x05070450 : 00000000
0x05070454 : 00000000
0x05070458 : 00000000
0x0507045c : 00000000
0x05070460 : 00000000
0x05070464 : 00000000
0x05070468 : 00000000
0x0507046c : 00000000
0x05070470 : 00000000
0x05070474 : 00000000
0x05070478 : 00000000
0x0507047c : 00000000
0x05070480 : 04e904e9
0x05070484 : 00000000
0x05070488 : 00000000
0x0507048c : 00000000
0x05070490 : 00000000
0x05070494 : 00000000
0x05070498 : 00000000
0x0507049c : 00000000
0x050704a0 : 07b907a8
0x050704a4 : 00000000
0x050704a8 : 00000000
0x050704ac : 00000000
0x050704b0 : 00000000
0x050704b4 : 00000000
0x050704b8 : 00000000
0x050704bc : 00000000
0x050704c0 : 0000072c
0x050704c4 : 0000077a
0x050704c8 : 00000000
0x050704cc : 00000000
0x050704d0 : 00000000
0x050704d4 : 00000000
0x050704d8 : 00000000
0x050704dc : 00000000
0x050704e0 : 00000000
0x050704e4 : 00000000
0x050704e8 : 00000000
0x050704ec : 00000000
0x050704f0 : 00000000
0x050704f4 : 00000000
0x050704f8 : 00000000
0x050704fc : 00000000