Armbian for OrangePi PC2, AllWinner H5

[zador.blood.stained]

13 minutes ago, Electromanic said:

Hey can anyone explain me why I'm getting 5 fps when playing a video on my OrangePi PC2 H5?

Because there is no hardware accelerated video decoding, at least on Armbian, and even on official images hardware decoding capabilities are limited.

[Electromanic]

4 hours ago, zador.blood.stained said:

Because there is no hardware accelerated video decoding, at least on Armbian, and even on official images hardware decoding capabilities are limited.

Thanks for the reply, now it make sense to me. I hope someday they gonna release a patch for this bug because I can only use this board as a server and it's kind of useless.

[Menion]

Hi

Is there any problem on bringing 4.12 kernel for H5 in Armbian? It should get rid of most of the patches implemented so far, plus it add support for USB OTG

Bye

[zador.blood.stained]

2 hours ago, Menion said:

Is there any problem on bringing 4.12 kernel for H5 in Armbian? It should get rid of most of the patches implemented so far, plus it add support for USB OTG

(IMO) There is no point on switching to 4.12 since Icenowy just made a first 4.13 branch: https://github.com/Icenowy/linux/tree/sunxi64-4.13-rc5

While it doesn't have some features that could be added (I can already hear "there is no DVFS! let's use Megous' branch instead") it's still a good candidate for a development branch since it has a WIP DRM display driver, support for the Pinebook, and the SoPine.

if/when she posts a 4.13.y branch (for a stable kernel version, not a release candidate) we can try switching sun50i-dev to that branch, but we still need to update the u-boot (ideally to v2017.09).

[Menion]

3 hours ago, zador.blood.stained said:

(IMO) There is no point on switching to 4.12 since Icenowy just made a first 4.13 branch: https://github.com/Icenowy/linux/tree/sunxi64-4.13-rc5

While it doesn't have some features that could be added (I can already hear "there is no DVFS! let's use Megous' branch instead") it's still a good candidate for a development branch since it has a WIP DRM display driver, support for the Pinebook, and the SoPine.

if/when she posts a 4.13.y branch (for a stable kernel version, not a release candidate) we can try switching sun50i-dev to that branch, but we still need to update the u-boot (ideally to v2017.09).

 

Actually I think you got a wrong impression of my (old) DVFS questions. First in 4.12 branch there is no DVFS support for H5. In the 4.12 branch, compared to the 4.11.y WIP used for the H5, as written, what I think it could be very useful to test, use and provide feedbacks to the community, is the USB OTG, which has always been a problem on Allwinner SoC, on A20 for example is still far from being perfect (if you try to connect a DVB-T to it you will understand why...)

As always, my are just questions, I don't want to push anything, anyone. Unfortunately I miss most of the understanding of the internal Armbian branching policy, so I cannot even try to be of any help for you (for the moment)

There is no need to be harsh

Bye

[zador.blood.stained]

7 minutes ago, Menion said:

USB OTG, which has always been a problem on Allwinner SoC, on A20 for example is still far from being perfect (if you try to connect a DVB-T to it you will understand why...)

You can't really compare A20 and H3 in the host mode. A20 will use rather limited host emulation (MUSB) mode by the OTG controller. H3, H5 and A64 OTG port can be multiplexed to a "real" EHCI/OHCI host which doesn't have any limitations (as long as the OTG port can provide enough power to your DVB-T tuner).

 

16 minutes ago, Menion said:

There is no need to be harsh

Sorry, I didn't try to be harsh or rude, I just already said on the previous page that I'm planning to upgrade when 4.13 is released and I didn't think that OTG may be of interest to anyone since H5 (compared to A64) has enough USB host controllers for most use cases.

[awhite2600]

I've been running the Xenial desktop build on an Orange Pi PC 2 for about 6 months. I've had no issues running some basic services (Apache, FTP server, Open VPN, Pi-Hole). I am new to Linux and have been using the OPi2 as a learning tool. I have used computers as a profession for over 30 years - mostly Windows and MS-DOS before that.

 

I typically install Armbian updates and reboot every few days.  After installing an update a few days ago everything became corrupt and the board fails to fully boot. This was confirmed on the console.  There is a fair amount of text. One of the first lines mentions a CRC error and scrolls away before I can read much else.

 

Thinking this was a fluke I downloaded Armbian and reimaged the card. All good...until I updated. Same problem again.

 

Being a Linux newbie I don't know where to start looking. Is this a known issue with a recent update? Any advice on how to determine the cause?

[zador.blood.stained]

4 minutes ago, awhite2600 said:

Being a Linux newbie I don't know where to start looking. Is this a known issue with a recent update? Any advice on how to determine the cause?

U-boot source was updated and it broke older images, so boot script needs to be updated manually. And the main cause of your problem is a combination of 

1. using images still marked as "development" and "no support" for anything other than development
2. updating the Armbian-specific packages on such images without understanding possible problems and ways to debug and fix those problems

For images marked as "stable" we are trying to prevent upgrade issues and maintain backwards compatibility. For images not marked as "stable" backwards compatibility is not something that is taken into account and images may break at any time without a warning.

[after]

20 minutes ago, awhite2600 said:

Being a Linux newbie I don't know where to start looking. Is this a known issue with a recent update? Any advice on how to determine the cause?

 

Yes, there's an issue with the latest update.

You can manually fix it by mounting the SD card on another computer and creating a symlink at 

/dtb/allwinner/allwinner

pointing to

/boot/dtb/allwinner

so it will look like this:

user@orangepipc2:/dtb/allwinner$ pwd
/dtb/allwinner
user@orangepipc2:/dtb/allwinner$ ls -lah
total 8.0K
drwxr-xr-x 2 root root 4.0K Aug 24 17:00 .
drwxr-xr-x 3 root root 4.0K Aug 24 17:00 ..
lrwxrwxrwx 1 root root   19 Aug 24 17:00 allwinner -> /boot/dtb/allwinner

[David DeLong]

1 hour ago, zador.blood.stained said:

U-boot source was updated and it broke older images, so boot script needs to be updated manually. And the main cause of your problem is a combination of 

1. using images still marked as "development" and "no support" for anything other than development
2. updating the Armbian-specific packages on such images without understanding possible problems and ways to debug and fix those problems

For images marked as "stable" we are trying to prevent upgrade issues and maintain backwards compatibility. For images not marked as "stable" backwards compatibility is not something that is taken into account and images may break at any time without a warning.

While I understand that this is not a support forum, but are you not open to bugs being reported? Also, would you like to get outside help with issues? The condescending tone you take with anyone on this forum only drives people away from the community and anyone willing to help.

[zador.blood.stained]

2 minutes ago, David DeLong said:

While I understand that this is not a support forum, but are you not open to bugs being reported?

Sorry, I'm just not considering this as a "bug". This is a side effect of using pre-release software that wasn't accepted upstream yet at the time (I'm talking about the u-boot and this patch in particular). While this is a support forum, Orange Pi PC2 doesn't have any Armbian releases marked "stable" and "supported" yet, and it is for a good reason.

 

9 minutes ago, David DeLong said:

The condescending tone you take with anyone on this forum only drives people away from the community and anyone willing to help.

Most of the problems with this target (Orange Pi PC2, sun50iw2-dev kernel) are already known and this breakage for older images was expected. We have help from assigned beta testers for stable images, including new image and upgrade testing, but, again, this particular target is not on the testing list. So I'm not sure that we need help with it yet, the best help for any distribution right now is writing drivers and getting them upstream.

[StuxNet]

29 minutes ago, David DeLong said:

While I understand that this is not a support forum, but are you not open to bugs being reported? Also, would you like to get outside help with issues? The condescending tone you take with anyone on this forum only drives people away from the community and anyone willing to help.

I didn't pick up on any 'condescending tone'. Don't mistaken bluntness and being forward for condescending. If the issues are result of using something for purposes other than mentioned and lack of understanding. Then perhaps that's simply the case. As such, it's not a bug and shouldn't be treated/claimed as such. I believe this is what was meant, more or less, that was lost in translation.

 "like to get outside help with issues?" I'm sure they would love to have outside help. Last I checked and AFAIK they have 4 developers. Having a 5th would be help. Not exactly reporting a bug, that's not really a bug. Nonetheless...

10 minutes ago, zador.blood.stained said:

...this is a support forum.

 

[awhite2600]

1 hour ago, David DeLong said:

While I understand that this is not a support forum, but are you not open to bugs being reported? Also, would you like to get outside help with issues? The condescending tone you take with anyone on this forum only drives people away from the community and anyone willing to help.

Perhaps I am misunderstanding the group's intention of "development" and "no support". The image has worked very well for me for 6 months. Updates have never been an issue. Maybe I am expecting too much. 

 

Again, forgive my ignorance of the Linux world. I am trying very hard to learn. The curve is steep when you've been Microsoft only for a 30 year career. (And tinkering with computers since 1980.) There is lots of good info available, but it takes time to comprehend a complex operating system. I'm doing my best to understand the relationships of U-boot, packages, updates, the Armbian specific parts, items specific to this board. I can understand it being second nature to people with specific experience. I'm sorry if it's new to me.

 

I wasn't asking for specific support, just some guidance from the knowledgable users here. Like I said, I'm trying to learn.

[awhite2600]

2 hours ago, after said:

 

Yes, there's an issue with the latest update.

You can manually fix it by mounting the SD card on another computer and creating a symlink at 

/dtb/allwinner/allwinner

pointing to

/boot/dtb/allwinner

so it will look like this:

user@orangepipc2:/dtb/allwinner$ pwd
/dtb/allwinner
user@orangepipc2:/dtb/allwinner$ ls -lah
total 8.0K
drwxr-xr-x 2 root root 4.0K Aug 24 17:00 .
drwxr-xr-x 3 root root 4.0K Aug 24 17:00 ..
lrwxrwxrwx 1 root root   19 Aug 24 17:00 allwinner -> /boot/dtb/allwinner

Thanks very much for the help. I really appreciate it. As I said in my other reply, I am doing my best to comprehend all of the intricacies of Linux in general and how it relates to Armbian and the OPi PC2 specifically.

 

I will try your suggestion, but not sure how/where I can do so. The only other Linux style environments that I have access to are a Raspberry Pi (locked into Retro Pi) and a Chromebox.  Alternatively, can I just reflash the card and perform the symlink creation before attempting to update?

[martinayotte]

If you wish to update applications without updating u-boot/kernel due to problems faced, you can use "apt-mark" to disable some unwanted updates.

 

[zador.blood.stained]

 

3 minutes ago, martinayotte said:

If you wish to update applications without updating u-boot/kernel due to problems faced, you can use "apt-mark" to disable some unwanted updates.

 

And AFAIK this (freezing the u-boot and kernel packages) was also implemented in the armbian-config.

[awhite2600]

1 hour ago, zador.blood.stained said:

 

And AFAIK this (freezing the u-boot and kernel packages) was also implemented in the armbian-config.

A huge THANKS. That is all that was needed. Sorry that this Linux newb didn't understand that option in armbian-config.  I froze the u-boot and kernel and updates ran without any damage.  

[StuxNet]

4 hours ago, awhite2600 said:

A huge THANKS. That is all that was needed. Sorry that this Linux newb didn't understand that option in armbian-config.  I froze the u-boot and kernel and updates ran without any damage.  

Don't apologize for being a newb. If I had 30 years of professional Windows exp I'd probably have been hired in my last interview for a major local corp.

 

We were all newbs once, still are and forever will be.

Just understand that I don't think @David DeLong was talking to you but rather @zador.blood.stained. In regards to 'condescension'. Furthermore it's important to understand that some people are here as script kiddies, some as mods, some as developers. Everyone approaches issues/reports/questions in a different light but it's the collective that helps you solve your problem! I wasn't part of that and neither was David but glad we could at least spur each other on. Happy hacking!

 

P.s. Way to really dive right into Linux. Took you Thirty years but way to go.

[John Brooks]

I am interested in evaluating the work-in-progress Armbian for OrangePiZeroPlus2-H5 using the mainline kernel.

 

The binary image "ARMBIAN 5.27.170614 nightly Ubuntu 16.04.2 LTS 4.11.1-sun50iw2" has worked well for me for several weeks and I would like to try building it from source. Any tips/pointers on where to grab the source and configuration for that version or is it just github master branch as of 5.27.17?

 

I have pulled and built the latest in-progress 4.13 kernel version "ARMBIAN 5.32 user-built Ubuntu 16.04.3 LTS 4.13.0-sun50iw2", and would prefer to evaluate and contribute to fixing this codebase if possible.

 

The head builds fine using the config "./compile.sh BOARD=orangepizeroplus2-h5" and the resulting image does boot.

 

Here are the issues I've seen so far testing the master branch for OPIZP2-H5:

 

1) Boot errors:

 

[  OK  ] Started Login Service.

         Starting LSB: set CPUFreq kernel parameters...

[FAILED] Failed to start LSB: Patch firmware for ap6212 adapter.

See 'systemctl status ap6212-bluetooth.service' for details.

[  OK  ] Started LSB: set CPUFreq kernel parameters.

 

root@orangepizeroplus2:~# systemctl status ap6212-bluetooth.service

● ap6212-bluetooth.service - LSB: Patch firmware for ap6212 adapter

   Loaded: loaded (/etc/init.d/ap6212-bluetooth; bad; vendor preset: enabled)

   Active: failed (Result: exit-code) since Mon 2017-09-11 18:17:48 UTC; 3min 53

     Docs: man:systemd-sysv-generator(8)

  Process: 575 ExecStart=/etc/init.d/ap6212-bluetooth start (code=exited, status

 

Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: /etc/init.d/ap6212-blue

Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: /etc/init.d/ap6212-blue

Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: sh: echo: I/O error

Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: Can't get port settings

Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: Can't initialize device

Sep 11 18:17:48 orangepizeroplus2 ap6212-bluetooth[575]: Can't get device info:

Sep 11 18:17:48 orangepizeroplus2 systemd[1]: ap6212-bluetooth.service: Control 

Sep 11 18:17:48 orangepizeroplus2 systemd[1]: Failed to start LSB: Patch firmwar

Sep 11 18:17:48 orangepizeroplus2 systemd[1]: ap6212-bluetooth.service: Unit ent

Sep 11 18:17:48 orangepizeroplus2 systemd[1]: ap6212-bluetooth.service: Failed w

 

 

2) HDMI console is not working. U-boot draws text to the HDMI console at power up, but there is no output from linux afterward and the display reports no HDMI output signal. I'm using a serial tty console for now.

 

 

3) WiFi is not working. This is the major blocker for me to do more testing with the H5 & 4.13 kernel.

 

 

root@orangepizeroplus2:~# nmcli g

STATE         CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN    

disconnected  none          enabled  enabled  enabled  enabled 

 

Armbian config reports errors on the UI:

 

I'd appreciate any tips on how to proceed and/or how I might contribute to fixing things.

 

Thanks!

-JB

@JBrooksBSI

 

[Igor]

57 minutes ago, John Brooks said:

I have pulled and built the latest in-progress 4.13 kernel version "ARMBIAN 5.32 user-built Ubuntu 16.04.3 LTS 4.13.0-sun50iw2", and would prefer to evaluate and contribute to fixing this codebase if possible.

The answer to this can be either simple or a complex one. I prefer to give simple tips in complex situations like this: start fixing things which you understand today.

 

57 minutes ago, John Brooks said:

Armbian config reports errors on the UI:

1

No idea why, but help to find out why is certainly appreciated. Sources: 

https://github.com/armbian/config (armbian-config is a separate project)

 

General collaboration info:
https://docs.armbian.com/Process_Contribute/

 

Add:

I just realized that you only wanted to test that we could fix it faster  It won't help. Especially not in this case. We call for end user testing when it's hard to find troubles.

[martinayotte]

@John BrooksThe Next-4.13 has been added by Zador for several H3 boards only 5 days ago ... So, not a lot of tests have been done ...

Why not starting by using the one well tested since months : Dev-4.11 ?

 

[zador.blood.stained]

I tested the wireless on Zero+2 H5 and it doesn't work due to firmware related issues (?). I'm kind of lost in the AP6212(A) firmware situation.

[martinayotte]

Mine is still running with 4.11.6-sun50iw2 built at the beginning of July.

I will build a Next-4.13 and give it a try ...

 

[John Brooks]

On 9/11/2017 at 2:03 PM, Igor said:

The answer to this can be either simple or a complex one. I prefer to give simple tips in complex situations like this: start fixing things which you understand today.

 

That is why I was thinking of building the 4.11 version from source so I might compare its working wifi & HDMI console to the inoperative versions in 4.13.

 

On 9/11/2017 at 2:03 PM, Igor said:

No idea why, but help to find out why is certainly appreciated. Sources: 

https://github.com/armbian/config (armbian-config is a separate project)

 

My expertise is more embedded systems/C/asm, so I didn't spot anything obvious in the shell scripts. All the --menu args appeared to correctly have 5 parameters.

 

On 9/11/2017 at 2:09 PM, martinayotte said:

The Next-4.13 has been added by Zador for several H3 boards only 5 days ago ... So, not a lot of tests have been done ...

Why not starting by using the one well tested since months : Dev-4.11 ?

 

I am not sure where to find the source & OPIZP2-H5 config for that version. Can someone point me in the right direction?

 

On 9/11/2017 at 2:13 PM, zador.blood.stained said:

I tested the wireless on Zero+2 H5 and it doesn't work due to firmware related issues (?). I'm kind of lost in the AP6212(A) firmware situation.

 

I saw another distro forum talking about an A0 and A1 firmware version for the AP6212. Any idea which version the OPIZP2-H5 needs and if that could be part of the problem? Can the (working) 4.11 driver be used with 4.13 or is there a compatibility issue?

 

Other questions/findings:

 

1) I can't seem to find register info for the Allwinner Display Engine (DE) 2.0 in either the H3 or H5 TRM. I did find a reasonable description of the DE 1 registers in the A33 TRM, but it is a generation out of date and of questionable value. Anyone have tips on where to find DE 2 info?

 

2) FYI: I'm pretty sure there is a hardware bug in the H5 (and probably H3) SPI controller when configured in slave mode. The bug is that when the H5 empties the Tx FIFO, instead of sending bytes of zeroes on subsequent master-initiated transfers, it sends a repeating 4-byte pattern of zero bytes alternating with some of the last bytes the app wrote to the Tx FIFO - ie, Tx register is not properly cleared at FIFO empty which then causes retransmitted 'garbage' slave data. My current workaround is to end each SPI slave transfer with an extra 4 bytes of zeroes.

 

Thank you for your help and pointers guys.

-JB

@JBrooksBSI

 

[Igor]

10 minutes ago, John Brooks said:

I saw another distro forum talking about an A0 and A1 firmware version for the AP6212. Any idea which version the OPIZP2-H5 needs and if that could be part of the problem? Can the (working) 4.11 driver be used with 4.13 or is there a compatibility issue?

 

https://forum.armbian.com/index.php?/search/&q=AP6212a
There were some discussions and AFAIK I made some dirty hack to fix this firmware mess. It looks like it's not working ok.

[martinayotte]

7 hours ago, John Brooks said:

I am not sure where to find the source & OPIZP2-H5 config for that version. Can someone point me in the right direction?

The Armbian build process is taking care about that. It take the kernel sources from Megous branch :

https://github.com/megous/linux/tree/orange-pi-4.11

 

[John Brooks]

42 minutes ago, martinayotte said:

The Armbian build process is taking care about that. It take the kernel sources from Megous branch

How do I select that branch during the Armbian build?

 

I am currently using "./compile.sh BOARD=orangepizeroplus2-h5" which selects the icenowy 4.13 branch.

 

-JB

@JBrooksBSI

[martinayotte]

Sorry, I thought we were talking about OPIZP2-H3.

You're right, the OPIZP2-H5 is the Icenowy branch 4.13, but 3 weeks ago, it was still on her 4.11 branch :

https://github.com/armbian/build/commit/a5ef9f10e49d9e386732e6931cbd7071c06c2151#diff-91cb477726b7e95e73f88e3c34c11d4d

 

You can revert this by editing this line :  https://github.com/armbian/build/blob/master/config/sources/sunxi64_common.inc#L30

 

[jernej]

10 hours ago, John Brooks said:

1) I can't seem to find register info for the Allwinner Display Engine (DE) 2.0 in either the H3 or H5 TRM. I did find a reasonable description of the DE 1 registers in the A33 TRM, but it is a generation out of date and of questionable value. Anyone have tips on where to find DE 2 info?

 

There is none. I started to write something about it here: http://linux-sunxi.org/DE2_Register_Guide Not much, but it is a start. Most informations can be found here: https://github.com/jernejsk/linux/blob/master/drivers/video/sunxi/disp2/disp/de/lowlevel_sun8iw7/de_rtmx_type.h

U-Boot has already DE2 & HDMI driver, while Linux has DE2 driver for V3s only. Basic DE2 driver & full HDMI driver for A64/H3/H5 are already prepared and a matter of mainlining.

[rusatch]

Hi! Just bugreport.

Build for last 2 hours with mainline kernel(thanks for add this option). Name of image - Armbian_5.32_Orangepizeroplus2-h5_Debian_stretch_next_4.13.2.img

Spoiler

U-Boot SPL 2017.09-armbian (Sep 15 2017 - 14:14:54)
DRAM: 512 MiB
Trying to boot from MMC1
NOTICE:  BL3-1: Running on H5 (1718) in SRAM A2 (@0x44000)
NOTICE:  Configuring SPC Controller
NOTICE:  BL3-1: v1.0(debug):aa75c8d
NOTICE:  BL3-1: Built : 14:14:50, Sep 15 2017
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 2017.09-armbian (Sep 15 2017 - 14:14:54 +0500) Allwinner Technology

CPU:   Allwinner H5 (SUN50I)
Model: OrangePi Zero Plus2
DRAM:  512 MiB
MMC:   SUNXI SD/MMC: 0, SUNXI SD/MMC: 1
*** Warning - bad CRC, using default environment

In:    serial
Out:   serial
Err:   serial
Net:   No ethernet found.
Hit any key to stop autoboot:  0  
38518 bytes read in 131 ms (287.1 KiB/s)
Unknown command 'bmp' - try 'help'
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
3100 bytes read in 190 ms (15.6 KiB/s)
## Executing script at 4fc00000
U-boot loaded from SD
Boot script loaded from mmc
116 bytes read in 159 ms (0 Bytes/s)
18575 bytes read in 274 ms (65.4 KiB/s)
** File not found /boot/dtb/allwinner/overlay/sun50i-h5-fixup.scr **
4472362 bytes read in 485 ms (8.8 MiB/s)
** File not found /boot/Image **
Bad Linux ARM64 Image magic!
SCRIPT FAILED: continuing...
switch to partitions #0, OK
mmc1(part 0) is current device
Scanning mmc 1:1...
starting USB...
No controllers found
USB is stopped. Please issue 'usb start' first.
starting USB...
No controllers found
No ethernet found.
missing environment variable: pxeuuid
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/000
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/00
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/0
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm-sunxi
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default-arm
No ethernet found.
missing environment variable: bootfile
Retrieving file: pxelinux.cfg/default
No ethernet found.
Config file not found
starting USB...
No controllers found
No ethernet found.
No ethernet found.
=>