rk3399: test_dec-gst.sh fails: mpp_drm: mmap failed: Invalid argument

[jakob-tsd]

I am running the latest release-4.4 kernel (d0f8c7a plus our patches) with the latest rk3399 debian rootfs rootfs-debian-20170504-beta-4.tar.gz from Google Drive. Hardware-accelerated video decoding fails. Is there a newer/older gst I have to use with this kernel?

root@linaro-alip:~# test_dec-gst.sh
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
mpi: mpp version: bc95242 author: LongChair mpp : add a control command to retrieve available input packet free slots
hal_h264d_api: hal_h264d_init mpp_buffer_group_get_internal used ion In
mpp_drm: mmap failed: Invalid argument
mpp_drm: os_allocator_drm_alloc drm_map failed ret -22
mpp_buffer: mpp_buffer_create failed to create buffer with size 160192
mpp_hal: mpp_hal_init hal h264d_rkdec init failed ret -1
mpp_hal: mpp_hal_init could no[  554.325164] rk-vcodec ff660000.rkvdec: closed
t found coding type 7
mpp_dec: mpp_dec_init could not init hal
mpp: error found on mpp initialization
ERROR: from element /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0: Internal data stream error.
Additional debug info:
qtdemux.c(5850): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin0/GstQTDemux:qtdemux0:
streaming stopped, reason error (-5)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...

[wzyy2]

You should ask it in mpp repo.
Some changes in mpp make it broken when using 32bit userpsace in arm64 platform.

I have packed a new mpp to fix it, you could have a try.
https://github.com/rockchip-linux/rk-rootfs-build/commit/e206387bcd413e1c0c249bac95c624c0462b5554

[hizukiayaka]

Don't make the future pull request for this unless you guys know what it is used for.
You are trying to kill those full 32bits platform.

[wzyy2]

Could you explain to us that why it will kill 32bits arm platform(correct me if your platform include i386)?

From my understanding, mmap64 in glibc is just a wrap of mmap2, and mmap2 is just a wrap of mmap in arm platform, i can't find any reason that it will break things.

links:
https://github.com/lattera/glibc/blob/a2f34833b1042d5d8eeb263b4cf4caaea138c4ad/sysdeps/unix/sysv/linux/mmap64.c
https://github.com/wzyy2/linux/blob/master/arch/arm/kernel/entry-common.S#L373
https://github.com/wzyy2/linux/blob/master/mm/mmap.c#L1461

[jakob-tsd]

Hi Randy, this should not cause any problem on 32-bit kernels. 64-bit mmap is available everywhere due to large file support (LFS).

…

On 2017-06-03 07:00, Randy Li wrote: Don't make the future pull request for this unless you guys know what it is used for. You are trying to kill those full 32bits platform.

[wzyy2]

It seems kernel commit "drm/rockchip: limit gem buffer to 32bit mapping" would also slove this problem, it will be included in next release, but for mainline kernel, "mmap" will still cause problem.

[jakob-tsd]

Thanks @wzyy2 , that's good enough for me.