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 <[email protected]> Sent: 2018年10月8日 19:50 To: Carol Zhu <[email protected]> Cc: Otavio Salvador <[email protected]>; Max Krummenacher <[email protected]>; Bing Song <[email protected]>; Eagle Zhou <[email protected]>; Tom Hochstein <[email protected]>; meta-freescale Mailing List <[email protected]>; Jun Zhu <[email protected]> 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 <[email protected]<mailto:[email protected]>> 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
-- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
