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

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


B.R.
Carol

From: Carol Zhu
Sent: 2018年10月8日 15:23
To: 'Gary Bisson' <gary.bis...@boundarydevices.com>
Cc: Otavio Salvador <otavio.salva...@ossystems.com.br>; Max Krummenacher 
<max.oss...@gmail.com>; Bing Song <bing.s...@nxp.com>; Eagle Zhou 
<eagle.z...@nxp.com>; Tom Hochstein <tom.hochst...@nxp.com>; meta-freescale 
Mailing List <meta-freescale@yoctoproject.org>; Jun Zhu <jun...@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 Gary,

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.
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/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.
If libc-headers could be backwards compatible except this “LINUX_VERSION_CODE”, 
then it’s ok with version mismatch.

B.R.
Carol
From: Gary Bisson 
<gary.bis...@boundarydevices.com<mailto:gary.bis...@boundarydevices.com>>
Sent: 2018年10月8日 13:41
To: Carol Zhu <carol....@nxp.com<mailto:carol....@nxp.com>>
Cc: Otavio Salvador 
<otavio.salva...@ossystems.com.br<mailto:otavio.salva...@ossystems.com.br>>; 
Max Krummenacher <max.oss...@gmail.com<mailto:max.oss...@gmail.com>>; Bing Song 
<bing.s...@nxp.com<mailto:bing.s...@nxp.com>>; Eagle Zhou 
<eagle.z...@nxp.com<mailto:eagle.z...@nxp.com>>; Tom Hochstein 
<tom.hochst...@nxp.com<mailto:tom.hochst...@nxp.com>>; meta-freescale Mailing 
List <meta-freescale@yoctoproject.org<mailto:meta-freescale@yoctoproject.org>>; 
Jun Zhu <jun...@nxp.com<mailto:jun...@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,

This is fixed already by pointing to the kernel header directly.
https://github.com/Freescale/meta-freescale/commit/387b285adc25aa244bfe90f4083320304af237c5<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Fmeta-freescale%2Fcommit%2F387b285adc25aa244bfe90f4083320304af237c5&data=02%7C01%7Ccarol.zhu%40nxp.com%7C654b648140334e84263808d62ce0aa1e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636745740783724551&sdata=UOwKTxkpJkS8RrYN%2FpcPN%2Bw7PzvH80uEhPZ1s641cJA%3D&reserved=0>
https://github.com/Freescale/meta-freescale/commit/476c63185e6864f82e938247235e7ad8ad20af4b<https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FFreescale%2Fmeta-freescale%2Fcommit%2F476c63185e6864f82e938247235e7ad8ad20af4b&data=02%7C01%7Ccarol.zhu%40nxp.com%7C654b648140334e84263808d62ce0aa1e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636745740783734564&sdata=VqJwukIDu8zLnmPIgQvGUcpFvMN7YnZnH4bgXUIy3HE%3D&reserved=0>

Changing the toolchain header is not flexible enough. First, this is Yocto, but 
you need to think about people using other build systems like Buildroot where 
such change will never be merged.

Also there's the case of people using pre-built toolchains, you can't control 
their headers versions.

All in all, you shouldn't rely on toolchains headers, especially for 
LINUX_VERSION_CODE.

Also, in the future, NXP will provide 4.14 kernel version, but what if someone 
wants to stick to a 4.9 (GA) kernel? Do you plan on having libc-headers for all 
next kernel releases? Doesn't sound like a scalable approach.

Regards,

Gary Bisson
Boundary Devices, LLC
www.boundarydevices.com<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.BoundaryDevices.com&data=02%7C01%7Ccarol.zhu%40nxp.com%7C654b648140334e84263808d62ce0aa1e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636745740783744573&sdata=9qHz%2F0HecMxcspuAz%2B%2FJSjznf3q3YegF7P%2B5U%2B5R6tA%3D&reserved=0>


On Mon, Oct 8, 2018 at 5:15 AM Carol Zhu 
<carol....@nxp.com<mailto:carol....@nxp.com>> wrote:
Hi Otavio,

Sorry for the late reply, I just come back from our National Day Holiday.

The current poky master has linux-libc-headers v4.18 but our kernel version is 
4.9.123, the two version are mismatch.
And when compiling vpu hantro, I got build break.
It needs to do LINUX_VERSION_CODE check, which relies on the Linux/version.h 
from Linux-libc-headers.
So I have to downgrade the Linux-libc-headers to 4.9 to match with our kernel 
version.


B.R.
Carol
-----Original Message-----
From: Otavio Salvador 
<otavio.salva...@ossystems.com.br<mailto:otavio.salva...@ossystems.com.br>>
Sent: 2018年10月2日 1:49
To: Carol Zhu <carol....@nxp.com<mailto:carol....@nxp.com>>; Tom Hochstein 
<tom.hochst...@nxp.com<mailto:tom.hochst...@nxp.com>>
Cc: meta-freescale Mailing List 
<meta-freescale@yoctoproject.org<mailto:meta-freescale@yoctoproject.org>>
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

On Sun, Sep 30, 2018 at 5:55 AM Yuqing Zhu 
<carol....@nxp.com<mailto:carol....@nxp.com>> wrote:
> Hold linux-libc-headers v4.9 in meta-freescale layer, which matches
> the current linux-imx version in L4.9.123-2.3.0_8mm_ga.
>
> Signed-off-by: Yuqing Zhu <carol....@nxp.com<mailto:carol....@nxp.com>>

I already reported multiple times that we cannot change this recipe.

Both Max and Gary raised the same concerns about it making all packages machine 
specific which is forbidden. Please align with Tom about the incoming work of 
using a set of imx specific headers instead.

--
Otavio Salvador                             O.S. Systems
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ossystems.com.br&amp;data=02%7C01%7Ccarol.zhu%40nxp.com%7Cb3d3ad002e774a24ae6808d627c633e2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636740129563654748&amp;sdata=7gWSdDOkNN4c0EZiO7oXayw5X5Hum9JTo4XHCOvtYYQ%3D&amp;reserved=0<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.ossystems.com.br&data=02%7C01%7Ccarol.zhu%40nxp.com%7C654b648140334e84263808d62ce0aa1e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636745740783744573&sdata=HMUaXsY%2Boae5xn%2B0nBReFw6xwwMG9%2F1UykGymqtuMVg%3D&reserved=0>
        
https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.ossystems.com.br&amp;data=02%7C01%7Ccarol.zhu%40nxp.com%7Cb3d3ad002e774a24ae6808d627c633e2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636740129563654748&amp;sdata=T4EZfBHWgktjyz00XYdVi0rZCADIMj9CXIRjgFPECus%3D&amp;reserved=0<https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcode.ossystems.com.br&data=02%7C01%7Ccarol.zhu%40nxp.com%7C654b648140334e84263808d62ce0aa1e%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C636745740783754577&sdata=NCD9Q6Wma3M3%2BS8p4fXnFpuAx90RzxM22tAMMarCXzs%3D&reserved=0>
Mobile: +55 (53) 9 9981-7854          Mobile: +1 (347) 903-9750
-- 
_______________________________________________
meta-freescale mailing list
meta-freescale@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-freescale

Reply via email to