[meta-freescale] [PATCH 01/14] linux-libc-headers: Use linux-libc-headers v4.9 for L4.9.123-2.3.0_8mm_ga

[Gary Bisson]

Hi Carol,

On Mon, Oct 8, 2018 at 11:30 AM Carol Zhu <carol.zhu at nxp.com> wrote:

> Hi Gary,
>
>
>
> I updated my local build env to the latest master branch and try building
> the vpu hantro.
>
> But I got a small build issue:
>
> | ./ewl/ewl_x280_common.c: In function 'EWLMallocLinear':
>
> | ./ewl/ewl_x280_common.c:775:25: error: storage size of 'dma_phys' isn't
> known
>
> |      struct dma_buf_phys dma_phys;
>
> |                          ^~~~~~~~
>
> | ./ewl/ewl_x280_common.c:799:17: warning: assignment to '__u64' {aka
> 'long long unsigned int'} from 'struct ion_heap_data
> (*)[(sizetype)(heap_cnt)]' makes integer from pointer without a cast
> [-Wint-conversion]
>
> |      query.heaps = &ihd;
>
> |                  ^
>
> | ./ewl/ewl_x280_common.c:819:35: error: 'struct ion_allocation_data' has
> no member named 'fd'
>
> |      info->ion_fd = allocation_data.fd;
>
> |                                    ^
>
> | ./ewl/ewl_x280_common.c:821:31: error: 'DMA_BUF_IOCTL_PHYS' undeclared
> (first use in this function); did you mean 'DMA_BUF_IOCTL_SYNC'?
>
> |      ret = ioctl(info->ion_fd, DMA_BUF_IOCTL_PHYS, &dma_phys);
>
> |                                ^~~~~~~~~~~~~~~~~~
>
> |                                DMA_BUF_IOCTL_SYNC
>

What platform are you building for?

I only tried 8M (Nitrogen8M) and this worked for me. But maybe the encoder
part needs to be modified for 8MM.

It goes into >k4.14 branch as the incorrect LINUX_VERSION_CODE, so I did a
> update about the include directory of version.h, plz take a check.
>
> ---
> a/recipes-bsp/imx-vpu-hantro/imx-vpu-hantro/0002-Fix-version.h-inclusion-to-be-from-kernel-build-fold.patch
>
> +++
> b/recipes-bsp/imx-vpu-hantro/imx-vpu-hantro/0002-Fix-version.h-inclusion-to-be-from-kernel-build-fold.patch
>
> @@ -34,7 +34,7 @@ index 56b4332..0be43ce 100755
>
>   ENV += -I$(LINUX_KERNEL_ROOT)/drivers/staging/android/uapi
>
>
>
> +# LINUX_VERSION_CODE from kernel build folder instead of toolchain headers
>
> -+INCLUDE_HEADERS += -I$(LINUX_KERNEL_BUILD)/include/generated/uapi
>
> ++ENV += -I$(LINUX_KERNEL_BUILD)/include/generated/uapi
>

If you have a fix please submit it.

<snip>

> Thanks for your fix. It looks flexible and do fix the build problem.
>
> But I am still a little bit confused.
>
> For my understanding, the version of libc-headers should match the one of
> kernel, or the compatibility couldn’t be guaranteed.
>

No the toolchain header doesn't have to match the kernel version exactly as
the ABI is backward compatible.


> And our current release maintain both libc-header and Linux-imx recipes to
> make them version match.
>
> eg: https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imKernel
> headerx/meta-bsp/recipes-kernel/linux-libc-headers?h=rocko-4.9.123-2.3.0_8mm_ga
> <https://source.codeaurora.org/external/imx/meta-fsl-bsp-release/tree/imx/meta-bsp/recipes-kernel/linux-libc-headers?h=rocko-4.9.123-2.3.0_8mm_ga>
>
> For people using pre-built toolchains, they’re supposed to choose proper
> version, which would be better.
>

As ABI is backwards compatible, people shouldn't have to worry about kernel
headers:
https://elinux.org/images/1/15/Anatomy_of_Cross-Compilation_Toolchains.pdf

If libc-headers could be backwards compatible except this “
> LINUX_VERSION_CODE”, then it’s ok with version mismatch.
>

Exactly, if the issue is only LINUX_VERSION_CODE then it should be taken
from kernel directly.

Also, since some headers are NXP-specific (ion.h), then even if you use a
pre-built toolchain with same version headers it won't work anyway as those
headers will be missing.

Regards,
Gary
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20181008/128c337b/attachment.html>