can't build mmal for aarch64
libbkmz opened this issue · comments
I'm trying to build userland in custom debian arm64v8. But on the make stage I getting this errors:
[ 21%] Building C object host_applications/linux/libs/sm/CMakeFiles/vcsm.dir/user-vcsm.c.o
/data/userland/host_applications/linux/libs/sm/user-vcsm.c: In function ‘vcsm_vc_hdl_from_ptr’:
/data/userland/host_applications/linux/libs/sm/user-vcsm.c:604:15: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
map.addr = (unsigned int) usr_ptr;
^
/data/userland/host_applications/linux/libs/sm/user-vcsm.c: In function ‘vcsm_usr_address’:
/data/userland/host_applications/linux/libs/sm/user-vcsm.c:802:14: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
return (void*)map.addr;
^
/data/userland/host_applications/linux/libs/sm/user-vcsm.c: In function ‘vcsm_usr_handle’:
/data/userland/host_applications/linux/libs/sm/user-vcsm.c:830:15: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
map.addr = (unsigned int) usr_ptr;
^
/data/userland/host_applications/linux/libs/sm/user-vcsm.c: In function ‘vcsm_lock’:
/data/userland/host_applications/linux/libs/sm/user-vcsm.c:939:14: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
usr_ptr = (void *) lock_unlock.addr;
^
/data/userland/host_applications/linux/libs/sm/user-vcsm.c:946:22: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
cache.addr = (unsigned int) usr_ptr;
^
/data/userland/host_applications/linux/libs/sm/user-vcsm.c: In function ‘vcsm_lock_cache’:
/data/userland/host_applications/linux/libs/sm/user-vcsm.c:1101:15: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
munmap( (void *)chk.addr, chk.size );
^
/data/userland/host_applications/linux/libs/sm/user-vcsm.c:1182:22: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
cache.addr = (unsigned int) usr_ptr;
^
/data/userland/host_applications/linux/libs/sm/user-vcsm.c: In function ‘vcsm_unlock_ptr_sp’:
/data/userland/host_applications/linux/libs/sm/user-vcsm.c:1267:15: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
map.addr = (unsigned int) usr_ptr;
^
cc1: all warnings being treated as errors
host_applications/linux/libs/sm/CMakeFiles/vcsm.dir/build.make:62: recipe for target 'host_applications/linux/libs/sm/CMakeFiles/vcsm.dir/user-vcsm.c.o' failed
make[3]: *** [host_applications/linux/libs/sm/CMakeFiles/vcsm.dir/user-vcsm.c.o] Error 1
CMakeFiles/Makefile2:4470: recipe for target 'host_applications/linux/libs/sm/CMakeFiles/vcsm.dir/all' failed
make[2]: *** [host_applications/linux/libs/sm/CMakeFiles/vcsm.dir/all] Error 2
CMakeFiles/Makefile2:1083: recipe for target 'interface/mmal/CMakeFiles/mmal.dir/rule' failed
make[1]: *** [interface/mmal/CMakeFiles/mmal.dir/rule] Error 2
Makefile:444: recipe for target 'mmal' failed
make: *** [mmal] Error 2
root@367ddd07ca47:/data/userland/build/raspberry/release# uname -a
Linux 367ddd07ca47 4.15.0-15-generic #16-Ubuntu SMP Wed Apr 4 13:58:14 UTC 2018 aarch64 GNU/Linux
root@367ddd07ca47:/data/userland/build/raspberry/release# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/6/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.3.0-18+deb9u1' --with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs --enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-6 --program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --enable-plugin --enable-default-pie --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-arm64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-arm64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-arm64 --with-arch-directory=aarch64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-multiarch --enable-fix-cortex-a53-843419 --enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)
I think you have come across one of the reasons why we don't have full support for 64bit userland. The GPU, the VC4 is 32 bit, and here we are passing pointers around from the VC4 to the Arm, and of course they are different sizes in a 64bit build. Someone need to write a translation layer that can handle the different addressing. We have never done that.
At least, that is how I understand it.
Ok, and how can I build it? I want to cross-compile ffmpeg and mpv for hardware decoding on my RPI 3B+. And It's really hard...
You can't - that's one of the reasons we don't support 64bit kernels/userspace.
Technically MMAL doesn't require VCSM, but has several optimisations that do require it (zero copy buffers mainly).
However part of MMAL is storing a userspace pointer within a 32bit field that is passed to the GPU. https://github.com/raspberrypi/userland/blob/master/interface/mmal/mmal_buffer.h#L73
That fails badly if userspace is using 64bit pointers. There needs to be a load of changes made to the MMAL framework to store a lookup table of cookies that can be passed across instead of actual pointers. It also doesn't help that the IPC structures have been defined with types such as void * which change size if you change to 64bit, so all of those need fixing too.
It is a a fixable problem, but isn't our priority.
There may be a solution for FFMpeg and MPV coming in the form of a V4L2 M2M codec driver, but it's not complete quite yet.
Closing this issue as questions answered/issue resolved.
Small question, are there any plans that contain fixing this issue or would this have to be a volunteer effort? If the latter then could this issue be reopened and maybe a tag help-wanted tag added?