linux-odroid-c2-headers - fix missing arch/arm/include headers, required by arch/arm64/include

[mk-fg]

All headers under arch/arm64/include/asm/xen there look like this:

#include <../../arm/include/asm/xen/hypervisor.h>

But PKGBUILD removes all headers for "arm", so building dkms modules (newer rtl8812au in my case) that use these will fail.
This is not a quirk of hardkernel/linux, but is also how they are in upstream linux-3.14.

grep shows that stuff under arch/arm64/include/asm/xen are the only headers that do this kind of thing (include stuff from "arm"), so alternative fix might be applying a patch to copy these headers from "arm" to "arm64", saving ~1.3M of space (unpacked), but probably more error-prone, hence this patch.

[mk-fg]

@kmihelich
I see that you've disabled aufs to presumably have working build with gcc7, would PR for alternative fix described in hardkernel/linux#300 be welcome instead, or would it be better to wait for upstream to merge it?

[fuzzysloth]

I have to report that the related change caused AMLogic hardware decoding to fail on kodi-c2.
Many tests were performed. All of them show that upgrading to linux-odroid-c2 3.14.79-25 brake HW decoding acceleration on Kodi. You can find more details here: https://archlinuxarm.org/forum/viewtopic.php?f=15&t=11777

[mk-fg]

upgrading to linux-odroid-c2 3.14.79-25 brake HW decoding acceleration on Kodi

Didn't check it, but suspect that only relevant difference between these versions of kernel package is that one was built with gcc7 while other one with previous version, as actual fix I was trying to acheive (and apparently failed) was amended in #1498 by @zx2c4

(given the long build time, and mentioned hardkernel/linux#300 build issue, don't think I've properly checked if package actually installed those headers, only assumed that it have, which it apparently did not)

This is especially true if you see the effect when installing 3.14.79-25 without afterwards rebuilding any packages, as these - probably not even installed, as mentioned - additional headers can only have effect when building stuff.

[fuzzysloth]

Previously (and also today) I built kodi-c2 and aml-libs-c2 successfully even without linux headers installed. Also none of them depends (or makedepends) on linux-odroid-c2-headers. Also I doubt that switch to gcc-7.1.1 is an issue because I used this gcc version to rebuild both kodi-c2 and aml-libs-c2 last three days. And - as before - HW accel worked with linux-odroid-c2 3.14.79-24 but stopped working after upgrading to either 3.14.79-25, 3.14.79-26 or 3.14.79-27.

But if you think that after either kernel or gcc upgrade some packages must be rebuilt - please specify which of them should be rebuilt and in which order? And which new "depends" or "makedepends" rules should be added?

[mk-fg]

I meant that 3.14.79-25+ are the kernel packages built with gcc7, which might be the only visible difference between e.g. 3.14.79-25 and 3.14.79-24, and hence likely cause of the issue.

[fuzzysloth]

Thank you, I understood your point. However after taking it into account - today I've made a proper rebuild of aml-libs-c2 after making these changes:

diff --git a/alarm/aml-libs-c2/PKGBUILD b/alarm/aml-libs-c2/PKGBUILD
index 9b02b8422..de24b13f6 100644
--- a/alarm/aml-libs-c2/PKGBUILD
+++ b/alarm/aml-libs-c2/PKGBUILD
@@ -5,8 +5,8 @@ buildarch=8
 
 pkgname=aml-libs-c2
 pkgver=r9.296f39b
-pkgrel=1
-arch=('armv7h')
+pkgrel=2
+arch=('armv7h' 'aarch64')
 pkgdesc="ODROID-C2 Amlogic Libraries"
 url="http://www.hardkernel.com/"
 license=('Proprietary')
@@ -17,6 +17,11 @@ source=("git+https://github.com/mdrjr/c2_aml_libs.git"
 md5sums=('SKIP'
          '42c9f74fc92755a975ed524c4735db42')
 
+prepare() {
+  # Remove all pre-built shared libraries to enforce rebuild
+  find c2_aml_libs -name '*.so' | xargs rm -vf
+}
+
 pkgver() {
   cd c2_aml_libs
   printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"

Please note that I've already rebuilt kodi-c2 with gcc 7.1.1 and had it installed - see #1500.
Alas! These two changes didn't help me to get HW accelerated playback to work. The message in the kernel log is still the same:

[Sun Jul 16 13:41:25 2017] Unable to handle kernel NULL pointer dereference at virtual address 00000000
[Sun Jul 16 13:41:25 2017] pgd = ffffffc0593a6000
[Sun Jul 16 13:41:25 2017] [00000000] *pgd=0000000059973003, *pmd=0000000000000000
[Sun Jul 16 13:41:25 2017] Internal error: Oops: 96000046 [#1] PREEMPT SMP
[Sun Jul 16 13:41:25 2017] Modules linked in:
[Sun Jul 16 13:41:25 2017] AESink[608]: syscall 279
[Sun Jul 16 13:41:25 2017] Code: aa0503e4 aa0603e5 aa0703e6 d4000001 (b13ffc1f) 
[Sun Jul 16 13:41:25 2017] CPU: 2 PID: 608 Comm: AESink Not tainted 3.14.79-27-ARCH #1
...
[Sun Jul 16 13:41:25 2017] Call trace:
[Sun Jul 16 13:41:25 2017] [<ffffffc001451634>] __copy_from_user+0x14/0x60
[Sun Jul 16 13:41:25 2017] [<ffffffc0016e815c>] esparser_write+0x14/0x30
[Sun Jul 16 13:41:25 2017] [<ffffffc0016ddd60>] amstream_vbuf_write+0x80/0xd0
[Sun Jul 16 13:41:25 2017] [<ffffffc00119cb48>] vfs_write+0xa8/0x1e0
[Sun Jul 16 13:41:25 2017] [<ffffffc00119d5d0>] SyS_write+0x48/0xb0
[Sun Jul 16 13:41:25 2017] Code: f1002042 540000a4 f8408423 f1002042 (f8008403) 

AFAIK the symbol amstream_vbuf_write belongs to the kernel? Could it be that the problem was introduced to the kernel itself after rebuild with gcc 7.1.1?

[mk-fg]

If you see it in dmesg - yes, definitely backtrace from the kernel code.

introduced to the kernel itself after rebuild with gcc 7.1.1

"introduced" as in "when built with gcc 7.1.1 same code works differently" - this definitely can be the case.
For a close example, fairly sure you need rather old toolchain to build working (non-mainline) uboot-odroid-c2, as mentioned both in its PKGBUILD and odroid wiki.
Apologies for repeating it for the third time here though.

[fuzzysloth]

Thank you for clarification. I perfectly understand your point.
Just to make a baseline: the current kernel built with gcc 7.1.1 "works differently" more than 1 month already. And the difference is that HW accelerated video decoding just broke.

Also I must admit that the knowledge, hardware and the time I have at the moment is not enough to properly rebuild and test all packages involved. So now I have to give up and wait until people involved in the project and who have skills make proper builds of related components.

[Taijian]

I finally got around to installing distcc and recompiling the latest (3.14.79-27) linux-odroid-c2 with gcc 6.3.1-2.

At least on my system the problem with broken hw accelerated video decoding went away with this recompiled kernel. So from what I can tell, it really seems to be an issue with gcc 7+ and the hardkernel sources / driver blob.