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

[Carol Zhu]

Hi Gary,

My platform is 8mm and yes, the h1 encoder part needs to be modified.
I’ll submit a patch about this.
Thanks.


B.R.
Carol
From: Gary Bisson <gary.bisson at boundarydevices.com>
Sent: 2018年10月8日 19:50
To: Carol Zhu <carol.zhu at nxp.com>
Cc: Otavio Salvador <otavio.salvador at ossystems.com.br>; Max Krummenacher <max.oss.09 at gmail.com>; Bing Song <bing.song at nxp.com>; Eagle Zhou <eagle.zhou at nxp.com>; Tom Hochstein <tom.hochstein at nxp.com>; meta-freescale Mailing List <meta-freescale at yoctoproject.org>; Jun Zhu <junzhu at nxp.com>
Subject: Re: [meta-freescale] [PATCH 01/14] linux-libc-headers: Use linux-libc-headers v4.9 for L4.9.123-2.3.0_8mm_ga

Hi Carol,

On Mon, Oct 8, 2018 at 11:30 AM Carol Zhu <carol.zhu at nxp.com<mailto: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://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.codeaurora.org%2Fexternal%2Fimx%2Fmeta-fsl-bsp-release%2Ftree%2Fimx%2Fmeta-bsp%2Frecipes-kernel%2Flinux-libc-headers%3Fh%3Drocko-4.9.123-2.3.0_8mm_ga&data=02%7C01%7Ccarol.zhu%40nxp.com%7Cd15c89e71f234bffae2108d62d142f1a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636745962056160606&sdata=L1Tmr%2FyYeVnIcIrF6BlL%2FKXPc52gw3HR5U7%2FyvAS%2F74%3D&reserved=0>
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<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Felinux.org%2Fimages%2F1%2F15%2FAnatomy_of_Cross-Compilation_Toolchains.pdf&data=02%7C01%7Ccarol.zhu%40nxp.com%7Cd15c89e71f234bffae2108d62d142f1a%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636745962056170614&sdata=Yq3Lzvr5MHGGMlZXi0fYLeW6NCGrVvB1zop7lAzoVfY%3D&reserved=0>

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/20181009/7165b384/attachment.html>