• 1
  • 19
  • 20
  • 21
  • 22(current)
  • 23
hardware acceleration on allwinner A10/A20 with vdpau and OpenGLES (zero-copy)
(2017-09-01, 17:22)mosterta Wrote: The code only supports a non-X11 desktop (i.e. framebuffer), which means that you cannot run chromium together with this code, since chromium requires X11 (afaik there is no "framebuffer-enabled-chromium")

Thanks @mosterta, I hadn't picked up on that. I was half-relying on chromium for things that Kodi doesn't handle well, like soundcloud, youtube etc. But if Kodi works smoothly, I can probably survive without it.
As as note: I'm not familiar with Kodi source and hadn't realised how closely tied to hardware it really was. In a way it's counter-intuitive that I can run 1080p video in VLC in X11 using sunxi-vdpau, but I can't do the same with Kodi without using a framebuffer desktop. I don't see why this is the case, currently - but as I say I haven't (yet) investigated the details and dependencies involved.

(2017-09-01, 17:22)mosterta Wrote: question 1: Nobody has ever tried to get the code running on Allwinner R40/V40 (AFAIK), so don't expect an "plug&play" solution. There is probably code to change, just to name a few: disp driver detection in kodi and using the correct API (which might not be implemented), sound driver detection, etc..)

Trust me to be the first one to try this hardware! Confused
Well if you or others can give me a couple of pointers with the main bits of brokenness, I can probably get it built!
But do you think I will likely have a smooth-functioning solution? ie stable and performant. If the chances are good that I can have a solid build, it's worth it.

(2017-09-01, 17:22)mosterta Wrote: question 2: In principle every distro can be used, as far as the linux kernel patches requires for this code are integrated, correct u-boot is used (I do see issues with libvdpau-sunxi on different u-boot versions) and all the libraries mentioned in post#1 are compiled.

Ok fine. But some of the links in post #1 are old already, right? These two at least:
Quote:- Sunxi-kernel kernel extension for the UMP module (add CMA support)
https://github.com/mosterta/linux-sunxi/..._sunxi-3.4
- it needs my version of kodi sources, still based on Kodi 14.2 (Helix)
https://github.com/mosterta/xbmc/tree/he...es_support

As far as other build deps go, I assume you're referencing general kodi build instructions as at https://github.com/xbmc/xbmc/blob/master...ADME.linux.

When I have a few hours spare, I'll try a new build and see where it fails. Thanks again.
Reply
(2017-09-01, 19:56)danryu Wrote:
(2017-09-01, 17:22)mosterta Wrote: The code only supports a non-X11 desktop (i.e. framebuffer), which means that you cannot run chromium together with this code, since chromium requires X11 (afaik there is no "framebuffer-enabled-chromium")

Thanks @mosterta, I hadn't picked up on that. I was half-relying on chromium for things that Kodi doesn't handle well, like soundcloud, youtube etc. But if Kodi works smoothly, I can probably survive without it.
As as note: I'm not familiar with Kodi source and hadn't realised how closely tied to hardware it really was. In a way it's counter-intuitive that I can run 1080p video in VLC in X11 using sunxi-vdpau, but I can't do the same with Kodi without using a framebuffer desktop. I don't see why this is the case, currently - but as I say I haven't (yet) investigated the details and dependencies involved.
kodi does work on X11 as well, actually this is the usual way on Linux. But when I started changing kodi for allwinner/libvdpau-sunxi support I started with an A10 with 512MB memory, and I didn't want to waste memory for X11. With saying this, my code could possibly also run on X11, but this is not tested (ast least by me)

(2017-09-01, 17:22)mosterta Wrote: question 1: Nobody has ever tried to get the code running on Allwinner R40/V40 (AFAIK), so don't expect an "plug&play" solution. There is probably code to change, just to name a few: disp driver detection in kodi and using the correct API (which might not be implemented), sound driver detection, etc..)

Trust me to be the first one to try this hardware! Confused
Well if you or others can give me a couple of pointers with the main bits of brokenness, I can probably get it built!
But do you think I will likely have a smooth-functioning solution? ie stable and performant. If the chances are good that I can have a solid build, it's worth it.

(2017-09-01, 17:22)mosterta Wrote: question 2: In principle every distro can be used, as far as the linux kernel patches requires for this code are integrated, correct u-boot is used (I do see issues with libvdpau-sunxi on different u-boot versions) and all the libraries mentioned in post#1 are compiled.

Ok fine. But some of the links in post #1 are old already, right? These two at least:
Quote:- Sunxi-kernel kernel extension for the UMP module (add CMA support)
https://github.com/mosterta/linux-sunxi/..._sunxi-3.4
- it needs my version of kodi sources, still based on Kodi 14.2 (Helix)
https://github.com/mosterta/xbmc/tree/he...es_support

As far as other build deps go, I assume you're referencing general kodi build instructions as at https://github.com/xbmc/xbmc/blob/master...ADME.linux.

When I have a few hours spare, I'll try a new build and see where it fails. Thanks again.

you need the 3.4 kernel, since this is the only one with support for proper monitor support (+ hardware support for video decoding)
regarding kodi: this is an old stream. Use
https://github.com/mosterta/xbmc/tree/ma...ered_vdpau
Reply
(2017-09-01, 23:23)mosterta Wrote: you need the 3.4 kernel, since this is the only one with support for proper monitor support (+ hardware support for video decoding)
regarding kodi: this is an old stream. Use
https://github.com/mosterta/xbmc/tree/ma...ered_vdpau

I've had a few hours to attempt a build as mentioned in #317.
I could do with some guidance on the basic kernel build. Taking the tree at https://github.com/mosterta/linux-sunxi/..._sunxi-3.4 and following the general instructions at http://linux-sunxi.org/Linux_Kernel#Compilation doesn't get me very far.
I'm attempting the build on the BPI M2 Berry itself. Is this wrong? Should I be cross-compiling on a Linux x86/64 platform for some reason? I've assumed not so far.
After I hack-fix some error about not finding include/linux/compiler-gcc6.h, I still run into problems pretty fast:

Code:
$ make -j4 ARCH=arm  uImage modules
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
make[1]: 'include/generated/mach-types.h' is up to date.
  CC      kernel/bounds.s
  GEN     include/generated/bounds.h
  CC      arch/arm/kernel/asm-offsets.s
  GEN     include/generated/asm-offsets.h
  CALL    scripts/checksyscalls.sh
  CC      init/main.o
  CHK     include/generated/compile.h
  HOSTCC  usr/gen_init_cpio
  CC      arch/arm/vfp/vfpmodule.o
  UPD     include/generated/compile.h
  AS      arch/arm/vfp/entry.o
  AS      arch/arm/vfp/vfphw.o
  CC      init/do_mounts.o
  GEN     usr/initramfs_data.cpio
  AS      usr/initramfs_data.o
  LD      usr/built-in.o
  CC      arch/arm/kernel/elf.o
  CC      arch/arm/vfp/vfpsingle.o
  AS      arch/arm/kernel/entry-armv.o
  AS      arch/arm/kernel/entry-common.o
  CC      arch/arm/kernel/irq.o
  CC      arch/arm/kernel/opcodes.o
  CC      init/do_mounts_rd.o
  CC      arch/arm/vfp/vfpdouble.o
  CC      arch/arm/mm/dma-mapping.o
  CC      arch/arm/kernel/process.o
  CC      init/do_mounts_initrd.o
  LD      arch/arm/vfp/vfp.o
  LD      arch/arm/vfp/built-in.o
  CC      init/initramfs.o
  CC      arch/arm/kernel/ptrace.o
  CC      arch/arm/mm/extable.o
  CC      init/calibrate.o
  CC      arch/arm/mm/fault.o
  CC      init/version.o
  CC      arch/arm/mm/init.o
  CC      arch/arm/kernel/return_address.o
  LD      init/mounts.o
init/do_mounts_rd.o: In function `return_address':
/barrel/kodi_build/linux-sunxi-ump_sunxi-3.4/arch/arm/include/asm/ftrace.h:51: multiple definition of `return_address'
init/do_mounts.o:/barrel/kodi_build/linux-sunxi-ump_sunxi-3.4/arch/arm/include/asm/ftrace.h:51: first defined here
init/do_mounts_initrd.o: In function `return_address':
/barrel/kodi_build/linux-sunxi-ump_sunxi-3.4/arch/arm/include/asm/ftrace.h:51: multiple definition of `return_address'
init/do_mounts.o:/barrel/kodi_build/linux-sunxi-ump_sunxi-3.4/arch/arm/include/asm/ftrace.h:51: first defined here
scripts/Makefile.build:429: recipe for target 'init/mounts.o' failed
make[1]: *** [init/mounts.o] Error 1
Makefile:947: recipe for target 'init' failed
make: *** [init] Error 2
make: *** Waiting for unfinished jobs....
  CC      arch/arm/mm/iomap.o
arch/arm/kernel/return_address.c:62:2: warning: #warning "TODO: return_address should use unwind tables" [-Wcpp]
#warning "TODO: return_address should use unwind tables"
  ^~~~~~~
arch/arm/kernel/return_address.c:65:7: error: redefinition of ‘return_address’
void *return_address(unsigned int level)
       ^~~~~~~~~~~~~~
In file included from include/linux/ftrace.h:19:0,
                 from arch/arm/kernel/return_address.c:12:
/barrel/kodi_build/linux-sunxi-ump_sunxi-3.4/arch/arm/include/asm/ftrace.h:48:21: note: previous definition of ‘return_address’ was here
extern inline void *return_address(unsigned int level)
                     ^~~~~~~~~~~~~~
scripts/Makefile.build:307: recipe for target 'arch/arm/kernel/return_address.o' failed
make[1]: *** [arch/arm/kernel/return_address.o] Error 1
Makefile:947: recipe for target 'arch/arm/kernel' failed
make: *** [arch/arm/kernel] Error 2
  CC      arch/arm/mm/fault-armv.o
  CC      arch/arm/mm/flush.o
  CC      arch/arm/mm/idmap.o
  CC      arch/arm/mm/ioremap.o
  CC      arch/arm/mm/mmap.o
  CC      arch/arm/mm/pgd.o
  CC      arch/arm/mm/mmu.o
  CC      arch/arm/mm/vmregion.o
  CC      arch/arm/mm/proc-syms.o
  CC      arch/arm/mm/alignment.o
  CC      arch/arm/mm/highmem.o
arch/arm/mm/alignment.c: In function ‘do_alignment’:
arch/arm/mm/alignment.c:327:15: warning: ‘offset.un’ may be used uninitialized in this function [-Wmaybe-uninitialized]
   offset.un = -offset.un;
               ^~~~~~~~~~
arch/arm/mm/alignment.c:749:21: note: ‘offset.un’ was declared here
  union offset_union offset;
                     ^~~~~~
  AS      arch/arm/mm/abort-ev7.o
  AS      arch/arm/mm/pabort-v7.o
  AS      arch/arm/mm/cache-v7.o
  CC      arch/arm/mm/copypage-v6.o
  CC      arch/arm/mm/context.o
  AS      arch/arm/mm/tlb-v7.o
  AS      arch/arm/mm/proc-v7.o
  CC      arch/arm/mm/cache-l2x0.o
  LD      arch/arm/mm/built-in.o

Am I definitely attempting to build the right kernel? The sun8i appears to be supported by kernels here: http://www.armbian.com/kernel/
and a link here from the kernel Mainlining page suggests that V40/R40 support is perhaps already in the Linus tree - http://lists.infradead.org/pipermail/lin...88712.html.

Anyway if you could offer advice on kernel choice and a supported build process, I'd be grateful. It's lonely here in M2Berry-land.
Reply
the kernel in https://github.com/mosterta/linux-sunxi/..._sunxi-3.4 does not support the H3/V/R40, but what you need from the repository are the UMP patches.
563e0154269acffaa36ec3b678e4b35cbf7ee1c0
67de2b9320eeb1fe205d29a49742919c1613da68

but as you noted correctly only by e.g. the armbian kernel. the official one may support the V/R40, but AFAIK it does not support the disp2 interface and related HDMI code.
you can compile the kernel native on the BPI M2, in this case you don't need the ARCH=arm parameter

The complete build is pretty complex. If you still can wait for some time: Currently I am preparing a LibreElec build for the OrangePi H3, I still face some issue which I must resolve first. But when it is finished, it may be much more easier to adapt it to the V/R40.
Reply
(2017-09-11, 22:29)mosterta Wrote: but as you noted correctly only by e.g. the armbian kernel. the official one may support the V/R40, but AFAIK it does not support the disp2 interface and related HDMI code.
you can compile the kernel native on the BPI M2, in this case you don't need the ARCH=arm parameter

The complete build is pretty complex. If you still can wait for some time: Currently I am preparing a LibreElec build for the OrangePi H3, I still face some issue which I must resolve first. But when it is finished, it may be much more easier to adapt it to the V/R40.

Thanks @mosterta. I can certainly wait a bit, I have a lot to do on it in headless mode anyway and can run the Kodi frontend on a separate node for now.

Does the work you're doing on LibreElec/H3 mean that there could even be a LibreElec build for H3-based boards like the bPi M2 Berry as well? That would be awesome. Which kernel tree would that be based on? Any chance of it being quite recent, ie a 4.x branch?
Good luck with your progress.
Reply
(2017-09-12, 12:41)danryu Wrote:
(2017-09-11, 22:29)mosterta Wrote: but as you noted correctly only by e.g. the armbian kernel. the official one may support the V/R40, but AFAIK it does not support the disp2 interface and related HDMI code.
you can compile the kernel native on the BPI M2, in this case you don't need the ARCH=arm parameter

The complete build is pretty complex. If you still can wait for some time: Currently I am preparing a LibreElec build for the OrangePi H3, I still face some issue which I must resolve first. But when it is finished, it may be much more easier to adapt it to the V/R40.

Thanks @mosterta. I can certainly wait a bit, I have a lot to do on it in headless mode anyway and can run the Kodi frontend on a separate node for now.

Does the work you're doing on LibreElec/H3 mean that there could even be a LibreElec build for H3-based boards like the bPi M2 Berry as well? That would be awesome. Which kernel tree would that be based on? Any chance of it being quite recent, ie a 4.x branch?
Good luck with your progress.

The difference between H3 based OrangePi and BananaPi M2 is hopefully only a different fex file and u-boot, while the other code keeps the same. It is based on the 3.4 kernel and there is no chance that there will be a newer kernel, since the newer (official) kernel lacks support of the disp2 interface. My Allwinner Kodi version is based/depending on it.
Reply
I have updated my LibreElec repository on github https://github.com/mosterta/LibreELEC.tv: branch libreelec-8.0_allwinner
this is a fork of an H3 Allwinner repository, but my repository supports libvdpau-sunxi together with my kodi allwinner implementation.
Currently only H3 OrangePi(X) is supported (tested on OrangePI PC), and also the support is only alpha. I did not set up a completely new build after I got LibreElec working, so I could have missed some files, or it may currently work by accident and it may not work after a full recompilation. Long words, don't expect (yet) and out of the box solution.

Support for other Allwinner SoC and -boards may be added, maybe also for A20 bananapi and A10 Mele (since I own these boards)
Reply
(2017-09-27, 00:14)mosterta Wrote: I have updated my LibreElec repository on github https://github.com/mosterta/LibreELEC.tv: branch libreelec-8.0_allwinner

Thanks, great news - and the forums are finally back!

So shall I go ahead and build an image off your LibreELEC tree? Which I assume includes the various patches you listed in #1.
I'll follow the procedure at https://wiki.libreelec.tv/compile unless you advise otherwise.
What should I use as PROJECT and ARCH values for the main build?
Reply
(2017-10-08, 16:59)danryu Wrote:
(2017-09-27, 00:14)mosterta Wrote: I have updated my LibreElec repository on github https://github.com/mosterta/LibreELEC.tv: branch libreelec-8.0_allwinner

Thanks, great news - and the forums are finally back!

So shall I go ahead and build an image off your LibreELEC tree? Which I assume includes the various patches you listed in #1.
I'll follow the procedure at https://wiki.libreelec.tv/compile unless you advise otherwise.
What should I use as PROJECT and ARCH values for the main build?

The LibreElec is based on the work from here:
http://www.microdev.it/wp/en/tag/libreelec-en/

so for PROJECT you should use PROJECT=H3 and for ARCH you should use one of the following values (only opipc is tested by myself)
SYSTEM=opi2
SYSTEM=opione
SYSTEM=opipc
SYSTEM=opiplus
SYSTEM=opilite
SYSTEM=opipcplus
SYSTEM=opiplus2e
Reply
(2017-10-11, 19:51)mosterta Wrote: so for PROJECT you should use PROJECT=H3 and for ARCH you should use one of the following values (only opipc is tested by myself)
SYSTEM=opi2
SYSTEM=opione
SYSTEM=opipc
SYSTEM=opiplus
SYSTEM=opilite
SYSTEM=opipcplus
SYSTEM=opiplus2e

Attempting a build of your libreelec-8.0_allwinner branch, the compile went fine for some time, until it attempts to patch the file "u-boot-01-led-support-default-state.patch".

Is this expected or anticipated? Any tips appreciated.

Build and command and failure shown below:

Code:
$ PROJECT=H3 ARCH=arm SYSTEM=opiplus make image
..........
..........
...........
Select compiled-in fonts (FONTS) [N/y/?] n
*
Bootup logo
*
Bootup logo (LOGO) [N/y/?] n
#
configuration written to .config
#
make[1]: Leaving directory '/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/linux-5ea667f'
CHECKOUT      u-boot
Cloning into bare repository 'sources/u-boot/u-boot-master.git'...
POST git-upload-pack (140 bytes)
remote: Counting objects: 13705, done.
remote: Compressing objects: 100% (9551/9551), done.
remote: Total 13705 (delta 3830), reused 13705 (delta 3830), pack-reused 0
Receiving objects: 100% (13705/13705), 20.05 MiB | 9.60 MiB/s, done.
Resolving deltas: 100% (3830/3830), done.
Checking connectivity... done.
UNPACK   u-boot
   APPLY PATCH (project)   /hd/kodi_build/LibreELEC.tv/projects/H3/patches/u-boot/u-boot-01-led-support-default-state.patch
patching file arch/arm/Kconfig
Hunk #1 FAILED at 584.
1 out of 1 hunk FAILED -- saving rejects to file arch/arm/Kconfig.rej
patching file board/sunxi/board.c
patching file drivers/led/led_gpio.c
patching file drivers/led/led-uclass.c
patching file include/led.h
Makefile:12: recipe for target 'image' failed
make: * [image] Error 1
Reply
(2017-10-16, 12:30)danryu Wrote:
(2017-10-11, 19:51)mosterta Wrote: so for PROJECT you should use PROJECT=H3 and for ARCH you should use one of the following values (only opipc is tested by myself)
SYSTEM=opi2
SYSTEM=opione
SYSTEM=opipc
SYSTEM=opiplus
SYSTEM=opilite
SYSTEM=opipcplus
SYSTEM=opiplus2e

Attempting a build of your libreelec-8.0_allwinner branch, the compile went fine for some time, until it attempts to patch the file "u-boot-01-led-support-default-state.patch".

Is this expected or anticipated? Any tips appreciated.

Build and command and failure shown below:

Code:
$ PROJECT=H3 ARCH=arm SYSTEM=opiplus make image
..........
..........
...........
Select compiled-in fonts (FONTS) [N/y/?] n
*
Bootup logo
*
Bootup logo (LOGO) [N/y/?] n
#
configuration written to .config
#
make[1]: Leaving directory '/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/linux-5ea667f'
CHECKOUT      u-boot
Cloning into bare repository 'sources/u-boot/u-boot-master.git'...
POST git-upload-pack (140 bytes)
remote: Counting objects: 13705, done.
remote: Compressing objects: 100% (9551/9551), done.
remote: Total 13705 (delta 3830), reused 13705 (delta 3830), pack-reused 0
Receiving objects: 100% (13705/13705), 20.05 MiB | 9.60 MiB/s, done.
Resolving deltas: 100% (3830/3830), done.
Checking connectivity... done.
UNPACK   u-boot
   APPLY PATCH (project)   /hd/kodi_build/LibreELEC.tv/projects/H3/patches/u-boot/u-boot-01-led-support-default-state.patch
patching file arch/arm/Kconfig
Hunk #1 FAILED at 584.
1 out of 1 hunk FAILED -- saving rejects to file arch/arm/Kconfig.rej
patching file board/sunxi/board.c
patching file drivers/led/led_gpio.c
patching file drivers/led/led-uclass.c
patching file include/led.h
Makefile:12: recipe for target 'image' failed
make: * [image] Error 1

Sorry for the late reply, but I was away some days. The error is not expected or anticipated. Indeed all the patches for u-boot should be disabled. I had done this on my build, but somewhen when I merge these came back in. So please rename all patches in
projects/H3/patches/u-boot and don't use them. It should build then. Unfortunatly I am not sure, which other patches came back in. I have to check that.
Reply
Hello.
There is a media console 3Q AB493HW (1 GB of RAM, Allwinner A10). Debian 8.9 Jessie

According to instructions from the post #1:
1) Kernel https://github.com/linux-sunxi/linux-sunxi (branch sunxi-3.4)
+
https://github.com/mosterta/linux-sunxi/...5cbf7ee1c0
- https://github.com/mosterta/linux-sunxi/...9c1613da68
  Ok

2) libump https://github.com/mosterta/libump/tree/mosterta/master (branch master)
  Ok

3) libvdpau https://github.com/mosterta/libvdpau (./configure --disable-dri2)
  Ok

4) libvdpau-sunxi https://github.com/mosterta/libvdpau-sunxi (branch master)
- make

Code:
gcc -MD -MP -MQ h265.o -fpic -Wall -O0 -g  -DUSE_UMP=1 -c h265.c -o h265.o
gcc -shared -Wl,-soname,libvdpau_sunxi.so.1 -I. device.o presentation_queue.o surface_output.o surface_video.o surface_bitmap.o video_mixer.o decoder.o h264.o mpeg12.o mpeg4.o mp4_vld.o mp4_tables.o mp4_block.o msmpeg4.o h265.o -lrt -lm -lpthread -lUMP -L /root/mosterta/libvdpau-sunxi -lcedar_access -o libvdpau_sunxi.so.1
/usr/bin/ld: cannot find -lcedar_access
collect2: error: ld returned 1 exit status
Makefile:85: ошибка выполнения рецепта для цели «libvdpau_sunxi.so.1»
make: *** [libvdpau_sunxi.so.1] Ошибка 1

How to fix?
Reply
(2017-10-22, 23:02)mosterta Wrote: Sorry for the late reply, but I was away some days. The error is not expected or anticipated. Indeed all the patches for u-boot should be disabled. I had done this on my build, but somewhen when I merge these came back in. So please rename all patches in
projects/H3/patches/u-boot and don't use them. It should build then. Unfortunatly I am not sure, which other patches came back in. I have to check that.

@mosterta

Sorry also for replying late - I am just juggling a lot of projects. 
So I attempted a rebuild: I renamed the dir projects/H3/patches/u-boot/patch to "altpatch", did a make clean, and executed 
PROJECT=H3 ARCH=arm SYSTEM=opiplus make image
again.
After about 40 minutes of building it fails as shown below.  If this is anticipated, please let me know how to get past this. Otherwise I have to start lengthy hacking ....

Code:
Run 'nofork' applets directly (FEATURE_SH_NOFORK) [N/y/?] n
Use $HISTFILESIZE (FEATURE_SH_HISTFILESIZE) [N/y/?] n
*
* System Logging Utilities
*
klogd (KLOGD) [N/y/?] n
logger (LOGGER) [N/y/?] n
syslogd (SYSLOGD) [N/y/?] n
make[1]: Leaving directory '/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init'
Executing (init): make ARCH=arm HOSTCC=/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc CROSS_COMPILE=/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/armv7ve-libreelec-linux-gnueabi- KBUILD_VERBOSE=1 install
make[1]: Entering directory '/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init'
rm -f .kernelrelease
echo 1.25.1 > .kernelrelease
/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/scripts/gen_build_files.sh /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init
/bin/sh /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/applets/busybox.mkll /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/include/autoconf.h include/applets.h > busybox.links
make -f scripts/Makefile.build obj=scripts/basic
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,scripts/basic/.fixdep.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer       -o scripts/basic/fixdep scripts/basic/fixdep.c
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,scripts/basic/.split-include.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer       -o scripts/basic/split-include scripts/basic/split-include.c
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,scripts/basic/.docproc.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer       -o scripts/basic/docproc scripts/basic/docproc.c
scripts/basic/split-include.c: In function 'main':
scripts/basic/split-include.c:134:6: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result]
     fgets(old_line, buffer_size, fp_target);
     ^
make -f scripts/Makefile.build obj=applets
 scripts/basic/split-include include/autoconf.h include/config
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,applets/.usage.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer      -Iinclude -Iinclude -o applets/usage applets/usage.c
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,applets/.applet_tables.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer       -o applets/applet_tables applets/applet_tables.c
applets/usage.c: In function 'main':
applets/usage.c:52:3: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
  write(STDOUT_FILENO, usage_array[i].usage, strlen(usage_array[i].usage) + 1);
  ^
applets/applet_tables.c: In function 'main':
applets/applet_tables.c:204:4: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result]
   fgets(line_old, sizeof(line_old), fp);
   ^
 applets/usage_compressed include/usage_compressed.h applets
 applets/applet_tables include/applet_tables.h include/NUM_APPLETS.h
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,applets/.usage_pod.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer      -Iinclude -Iinclude -o applets/usage_pod applets/usage_pod.c
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/armv7ve-libreelec-linux-gnueabi-gcc -Wp,-MD,applets/.applets.o.d    -Iinclude -Ilibbb  -include include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.25.1)" -DBB_BT=AUTOCONF_TIMESTAMP -march=armv7ve -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -fomit-frame-pointer -Wall -pipe -Os0 -flto -ffat-lto-objects           -Wold-style-definition             -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(applets)"  -D"KBUILD_MODNAME=KBUILD_STR(applets)" -c -o applets/applets.o applets/applets.c
applets/usage_pod.c: In function 'main':
applets/usage_pod.c:74:3: warning: format not a string literal and no format arguments [-Wformat-security]
  printf(usage_array[i].aname);
  ^
cc1: error: argument to '-O' should be a non-negative integer, 'g', 's' or 'fast'
make[2]: *** [scripts/Makefile.build:198: applets/applets.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:372: applets_dir] Error 2
make[1]: *** Waiting for unfinished jobs....
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/scripts/mkconfigs include/bbconfigopts.h include/bbconfigopts_bz2.h
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/scripts/generate_BUFSIZ.sh include/common_bufsiz.h
make[1]: Leaving directory '/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init'
Makefile:12: recipe for target 'image' failed
make: *** [image] Error 1
Reply
(2017-11-06, 23:44)danryu Wrote:
(2017-10-22, 23:02)mosterta Wrote: Sorry for the late reply, but I was away some days. The error is not expected or anticipated. Indeed all the patches for u-boot should be disabled. I had done this on my build, but somewhen when I merge these came back in. So please rename all patches in
projects/H3/patches/u-boot and don't use them. It should build then. Unfortunatly I am not sure, which other patches came back in. I have to check that.

@mosterta

Sorry also for replying late - I am just juggling a lot of projects. 
So I attempted a rebuild: I renamed the dir projects/H3/patches/u-boot/patch to "altpatch", did a make clean, and executed 
PROJECT=H3 ARCH=arm SYSTEM=opiplus make image
again.
After about 40 minutes of building it fails as shown below.  If this is anticipated, please let me know how to get past this. Otherwise I have to start lengthy hacking ....

Code:
Run 'nofork' applets directly (FEATURE_SH_NOFORK) [N/y/?] n
Use $HISTFILESIZE (FEATURE_SH_HISTFILESIZE) [N/y/?] n
*
* System Logging Utilities
*
klogd (KLOGD) [N/y/?] n
logger (LOGGER) [N/y/?] n
syslogd (SYSLOGD) [N/y/?] n
make[1]: Leaving directory '/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init'
Executing (init): make ARCH=arm HOSTCC=/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc CROSS_COMPILE=/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/armv7ve-libreelec-linux-gnueabi- KBUILD_VERBOSE=1 install
make[1]: Entering directory '/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init'
rm -f .kernelrelease
echo 1.25.1 > .kernelrelease
/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/scripts/gen_build_files.sh /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init
/bin/sh /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/applets/busybox.mkll /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/include/autoconf.h include/applets.h > busybox.links
make -f scripts/Makefile.build obj=scripts/basic
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,scripts/basic/.fixdep.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer       -o scripts/basic/fixdep scripts/basic/fixdep.c
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,scripts/basic/.split-include.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer       -o scripts/basic/split-include scripts/basic/split-include.c
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,scripts/basic/.docproc.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer       -o scripts/basic/docproc scripts/basic/docproc.c
scripts/basic/split-include.c: In function 'main':
scripts/basic/split-include.c:134:6: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result]
     fgets(old_line, buffer_size, fp_target);
     ^
make -f scripts/Makefile.build obj=applets
 scripts/basic/split-include include/autoconf.h include/config
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,applets/.usage.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer      -Iinclude -Iinclude -o applets/usage applets/usage.c
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,applets/.applet_tables.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer       -o applets/applet_tables applets/applet_tables.c
applets/usage.c: In function 'main':
applets/usage.c:52:3: warning: ignoring return value of 'write', declared with attribute warn_unused_result [-Wunused-result]
  write(STDOUT_FILENO, usage_array[i].usage, strlen(usage_array[i].usage) + 1);
  ^
applets/applet_tables.c: In function 'main':
applets/applet_tables.c:204:4: warning: ignoring return value of 'fgets', declared with attribute warn_unused_result [-Wunused-result]
   fgets(line_old, sizeof(line_old), fp);
   ^
 applets/usage_compressed include/usage_compressed.h applets
 applets/applet_tables include/applet_tables.h include/NUM_APPLETS.h
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/host-gcc -Wp,-MD,applets/.usage_pod.d  -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer      -Iinclude -Iinclude -o applets/usage_pod applets/usage_pod.c
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/toolchain/bin/armv7ve-libreelec-linux-gnueabi-gcc -Wp,-MD,applets/.applets.o.d    -Iinclude -Ilibbb  -include include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D"BB_VER=KBUILD_STR(1.25.1)" -DBB_BT=AUTOCONF_TIMESTAMP -march=armv7ve -mabi=aapcs-linux -Wno-psabi -Wa,-mno-warn-deprecated -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=neon-vfpv4 -fomit-frame-pointer -Wall -pipe -Os0 -flto -ffat-lto-objects           -Wold-style-definition             -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(applets)"  -D"KBUILD_MODNAME=KBUILD_STR(applets)" -c -o applets/applets.o applets/applets.c
applets/usage_pod.c: In function 'main':
applets/usage_pod.c:74:3: warning: format not a string literal and no format arguments [-Wformat-security]
  printf(usage_array[i].aname);
  ^
cc1: error: argument to '-O' should be a non-negative integer, 'g', 's' or 'fast'
make[2]: *** [scripts/Makefile.build:198: applets/applets.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [Makefile:372: applets_dir] Error 2
make[1]: *** Waiting for unfinished jobs....
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/scripts/mkconfigs include/bbconfigopts.h include/bbconfigopts_bz2.h
 /hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init/scripts/generate_BUFSIZ.sh include/common_bufsiz.h
make[1]: Leaving directory '/hd/kodi_build/LibreELEC.tv/build.LibreELEC-H3.arm-8.0-devel/busybox-1.25.1/.armv7ve-libreelec-linux-gnueabi-init'
Makefile:12: recipe for target 'image' failed
make: *** [image] Error 1

Please use the latest version of the repository. There was an error in file config/optimze (first line)
Reply
(2017-11-02, 10:36)ZigZag69 Wrote: Hello.
There is a media console 3Q AB493HW (1 GB of RAM, Allwinner A10). Debian 8.9 Jessie

According to instructions from the post #1:
1) Kernel https://github.com/linux-sunxi/linux-sunxi (branch sunxi-3.4)
+
https://github.com/mosterta/linux-sunxi/...5cbf7ee1c0
- https://github.com/mosterta/linux-sunxi/...9c1613da68
  Ok

2) libump https://github.com/mosterta/libump/tree/mosterta/master (branch master)
  Ok

3) libvdpau https://github.com/mosterta/libvdpau (./configure --disable-dri2)
  Ok

4) libvdpau-sunxi https://github.com/mosterta/libvdpau-sunxi (branch master)
- make

Code:
gcc -MD -MP -MQ h265.o -fpic -Wall -O0 -g  -DUSE_UMP=1 -c h265.c -o h265.o
gcc -shared -Wl,-soname,libvdpau_sunxi.so.1 -I. device.o presentation_queue.o surface_output.o surface_video.o surface_bitmap.o video_mixer.o decoder.o h264.o mpeg12.o mpeg4.o mp4_vld.o mp4_tables.o mp4_block.o msmpeg4.o h265.o -lrt -lm -lpthread -lUMP -L /root/mosterta/libvdpau-sunxi -lcedar_access -o libvdpau_sunxi.so.1
/usr/bin/ld: cannot find -lcedar_access
collect2: error: ld returned 1 exit status
Makefile:85: ошибка выполнения рецепта для цели «libvdpau_sunxi.so.1»
make: *** [libvdpau_sunxi.so.1] Ошибка 1

How to fix?
please use the latest version from github. There was an error in the Makefile using the wrong filename for libcedar_access

But there is an dependency of this version to the latest version of kodi
https://github.com/mosterta/xbmc
branch
allwinner-krypton

please use this version of kodi and not the branch mentioned in my post #1
Reply
  • 1
  • 19
  • 20
  • 21
  • 22(current)
  • 23

Logout Mark Read Team Forum Stats Members Help
hardware acceleration on allwinner A10/A20 with vdpau and OpenGLES (zero-copy)2