linux-imx-headers #19

thochstein · 2018-10-24T16:49:36Z

No description provided.

otavio

Thank you for this work; I think we got in a nice looking recipe as initial work and it can be used as base for further improvements.

See the comments I made. Easy stuff 👍

otavio · 2018-10-24T17:01:34Z

recipes-kernel/linux/linux-imx-headers_4.9.123.bb

+S = "${WORKDIR}/git"
+
+do_compile() {
+}


Please:

do_compile[noexec] = "1"

recipes-kernel/linux/linux-imx-headers_4.9.123.bb

otavio · 2018-10-24T21:11:09Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-base_1.14.imx.bb

-    -I${STAGING_KERNEL_DIR}/drivers/staging/android/uapi \
-    -I${STAGING_KERNEL_BUILDDIR}/include/generated/uapi \
-    " \
+    CPPFLAGS="-I${STAGING_DIR_TARGET}${includedir}/imx" \


Please use ${STAGING_INCDIR}/imx as it is smaller.

recipes-kernel/linux/linux-imx-headers_4.9.123.bb

otavio · 2018-10-25T12:14:11Z

It seems good; we just need to double check what else we can move to depend on the new linux-imx-headers. Suspects are:

As those should be part of this PR and we can merge them all in one shot.

thochstein · 2018-10-25T14:47:49Z

recipes-bsp/imx-vpu/imx-vpu_5.4.38.bb

    oe_runmake CROSS_COMPILE="${HOST_PREFIX}" PLATFORM="${PLATFORM}" INCLUDE="${INCLUDE_DIR}" all
 }

 do_install () {
    oe_runmake PLATFORM="${PLATFORM}" DEST_DIR="${D}" install
 }

-PACKAGE_ARCH = "${MACHINE_ARCH}"
+PACKAGE_ARCH = "${MACHINE_SOCARCH}"


This line is redundant to MACHINE_SOCARCH_FILTER.

You're right ... however, it does not hurt.

In fact, after we finish going over the recipes, I will rework them one more time, globally, to avoid duplication but first I wish to go over the minimal set of changes which allow use to prove it keeps all working.

otavio · 2018-10-25T19:54:51Z

recipes-multimedia/gstreamer/gstreamer1.0-plugins-imx_git.bb

@@ -35,7 +33,8 @@ EGLVIVSINK_PLATFORM = "${@bb.utils.contains('DISTRO_FEATURES', 'wayland', 'wayla
                          'fb', d),d)}"

 EGL_PLATFORM_CONF = "--egl-platform=${EGLVIVSINK_PLATFORM}"
-EXTRA_OECONF = "--kernel-headers=${STAGING_KERNEL_DIR}/include ${PACKAGECONFIG_CONFARGS}"
+
+EXTRA_OECONF = "CFLAGS="-I${STAGING_INCDIR}/imx""


You must keep the previous:

EXTRA_OECONF = "--kernel-headers=${STAGING_INCDIR}/imx ${PACKAGECONFIG_CONFARGS}"

otavio · 2018-10-26T01:50:49Z

Hello Tom,

I made a small rework on the recipes to simplify its use and also to allow for later improvements with easy.

Take a look at the class and please try it at your side. Assuming it works, we can merge it.

gibsson · 2018-10-26T08:19:07Z

It seems good; we just need to double check what else we can move to depend on the new linux-imx-headers. Suspects are:

imx-lib

imx-test

imx-uuc

imx-vpu

imx-alsa-plugins

gstreamer1.0-plugins-imx

imx-gst1.0-plugin

As those should be part of this PR and we can merge them all in one shot.

But in that case what's the plan for machines that use a kernel older than 4.9? Do they have to stick to sumo?

Having a look at meta-freescale-3rdparty, it seems that many vendors are still using 3.14/4.1:
https://github.com/Freescale/meta-freescale-3rdparty/tree/master/recipes-kernel/linux

Do we consider that every board vendor must be aligned with NXP's latest at all time or do we create as many linux-imx-headers recipes as there are kernel versions supported? Note that for i.MX6, nothing prevents people to stay on 4.1 or 3.14 but still use latest graphics/vpu libs.

That's for the above reason that I am not fond of this approach.

otavio · 2018-10-26T13:05:56Z

Hello @gibsson, thanks for joining the review :-)

But in that case what's the plan for machines that use a kernel older than 4.9? Do they have to stick to sumo?

Having a look at meta-freescale-3rdparty, it seems that many vendors are still using 3.14/4.1:
https://github.com/Freescale/meta-freescale-3rdparty/tree/master/recipes-kernel/linux

Do we consider that every board vendor must be aligned with NXP's latest at all time or do we create as many linux-imx-headers recipes as there are kernel versions supported? Note that for i.MX6, nothing prevents people to stay on 4.1 or 3.14 but still use latest graphics/vpu libs.

That's for the above reason that I am not fond of this approach.

I understand your concern and yes, it is going to cause some problems. Many of those board are outdated because vendors are not paying attention to community BSP.

There many side benefits of having this in a general way, mainly:

reduces build time for multiple boards
provides a global ABI for all boards
reduce dependencies

So we will need to ping vendors to update their machines and in case they don't do that, remove broken boards. This ultimately is not a bad thing as if they don't care why should we care?

gibsson · 2018-10-26T13:15:11Z

Hello @gibsson, thanks for joining the review :-)

Hello, also happy to be part of the discussion.

But in that case what's the plan for machines that use a kernel older than 4.9? Do they have to stick to sumo?
Having a look at meta-freescale-3rdparty, it seems that many vendors are still using 3.14/4.1:
https://github.com/Freescale/meta-freescale-3rdparty/tree/master/recipes-kernel/linux
Do we consider that every board vendor must be aligned with NXP's latest at all time or do we create as many linux-imx-headers recipes as there are kernel versions supported? Note that for i.MX6, nothing prevents people to stay on 4.1 or 3.14 but still use latest graphics/vpu libs.
That's for the above reason that I am not fond of this approach.

I understand your concern and yes, it is going to cause some problems. Many of those board are outdated because vendors are not paying attention to community BSP.

I understand but I wouldn't discard them though. Especially those using 4.1 kernels, it's still fairly recent in the NXP world, many vendors haven't switched to 4.9 yet (not just on the Yocto BSP).

There many side benefits of having this in a general way, mainly:

reduces build time for multiple boards

How so? You still need to build the kernel so I'm not sure to follow.
Actually it increases the build time for 3rd-party vendors as it downloads both the vendor kernel + the full NXP tree just for the headers.

provides a global ABI for all boards

But the ABI stays the same for all kernels, as long as you use 4.9 based on NXP fork you'll have the same.

reduce dependencies

How so? You still need to build the kernel for those packages to be useful.
Here you replacing the kernel dependency on kernel-header dependency (which in turns downloads the full kernel anyway).

So we will need to ping vendors to update their machines and in case they don't do that, remove broken boards. This ultimately is not a bad thing as if they don't care why should we care?

Once again, I don't think it's only a matter of updating the recipe, some vendors haven't switched to 4.9 yet because they haven't run all their tests on it.

All in all, I think this approach locks things down for unnecessary reasons (as it works fine without that approach today in a more flexible manner).

otavio · 2018-10-26T13:32:43Z

I understand your concern and yes, it is going to cause some problems. Many of those board are outdated because vendors are not paying attention to community BSP.

I understand but I wouldn't discard them though. Especially those using 4.1 kernels, it's still fairly recent in the NXP world, many vendors haven't switched to 4.9 yet (not just on the Yocto BSP).

They can still keep using old Yocto Project releases. I am sorry but their slowness cannot block things to improve.

There many side benefits of having this in a general way, mainly:

reduces build time for multiple boards

How so? You still need to build the kernel so I'm not sure to follow.
Actually it increases the build time for 3rd-party vendors as it downloads both the vendor kernel + the full NXP tree just for the headers.

We make more binaries SoC arch and as consequence, more recipes are skip when doing multiple machines.

For you, it may not be a big deal but for customers which use multiple machines and for vendors who have multiple machines, it has a huge impact.

provides a global ABI for all boards

But the ABI stays the same for all kernels, as long as you use 4.9 based on NXP fork you'll have the same.

Yes but this is not guaranteed by the layer until we force it to stick to a static set of headers.

reduce dependencies

How so? You still need to build the kernel for those packages to be useful.
Here you replacing the kernel dependency on kernel-header dependency (which in turns downloads the full kernel anyway).

So we will need to ping vendors to update their machines and in case they don't do that, remove broken boards. This ultimately is not a bad thing as if they don't care why should we care?

Once again, I don't think it's only a matter of updating the recipe, some vendors haven't switched to 4.9 yet because they haven't run all their tests on it.

All in all, I think this approach locks things down for unnecessary reasons (as it works fine without that approach today in a more flexible manner).

I respect your view @gibsson but vendors will need to upgrade or move to mainline Linux kernel.

In fact, many vendors do not upgrade at all. Those, I am not concerned as this is their decision.

All we can do to assist faster upgrades, we do. We have shared tree for Linux and U-Boot which allows for reducing work duplication and sooner or later they need to upgrade.

Following changes are included: ecc2161 fix build error by gcc 8.2 7c7562b fix build error 114d98b launch dhcpd for usb<n> to avoid ipaddress lost in host machine 675c264 auto mount nfs by usb if command line have nfsroot= e05cc55 fix build error when gcc over 7.0 1b40fd0 Fix Sync command wait for wrong pid 1a58f13 Add OS DeviceInterfaceGUID to function fs 0c45898 write time too long to failure send response in time 87201ac mkfs.ext2 work, report status every 50ms e4aa701 dual dir ucopy work 77498f4 ufb copy work 06156a3 Update pid b7c19b0 wcie auto load winusb driver aa9e77a add super speed and MS_OS_DESC support 20d819c add functionfs to usb gadget support f2526dc Add ACmd, Sync, Open Command ce808f3 Create new daemon by use function_fs Signed-off-by: Otavio Salvador <[email protected]>

thochstein · 2018-10-26T14:45:47Z

recipes-bsp/imx-test/imx-test_git.bb

@@ -56,8 +56,8 @@ do_compile() {
    oe_runmake V=1 VERBOSE='' \
               CROSS_COMPILE=${TARGET_PREFIX} \
               INC="-I${STAGING_INCDIR} \
+                    -I${STAGING_IMX_INCDIR}" \


Isn't the order here wrong? The source headers should have a higher priority than the sysroot headers, in which case line 58 is also wrong.

You are right, can you fix it?

Use a common file to make easier update, maintain and create others U-Boot recipes like U-Boot fw-utils. Signed-off-by: Joris Offouga <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

thochstein · 2018-10-26T14:47:17Z

classes/use-imx-headers.bbclass

+DEPENDS_imx_append = " linux-imx-headers"
+PACKAGE_ARCH_imx ?= "${MACHINE_SOCARCH}"
+
+STAGING_IMX_INCDIR = "${STAGING_INCDIR}/imx"


STAGING_INCDIR_IMX seems a better name since the word order follows the directory order.

Great, mind to fix it?

Initial support for fw utils for qoriq Signed-off-by: Joris Offouga <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

thochstein · 2018-10-26T14:47:55Z

classes/use-imx-headers.bbclass

+#
+# Copyright 2018 (C) O.S. Systems Software LTDA.
+
+DEPENDS_imx_append = " linux-imx-headers"


This needs to be DEPENDS_append_imx, right?

Yes, it is indeed better

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

One of the advantages in using upstream mesa is that we have the freedom to use gl or gles2 for qtbase. So follow meta-qt5's default here which is desktop-gl and give other layers a more simple chance to change default if necessary. Notes: * Did performance tests with my images and did not find any performance issues. * Some recipes in meta-qt5-extra fail to build when qtbase is build for gles2. A patch addressing imx was applied [1] - but honestly it is not the way to go: use meta-qt5's default which is fine. [1] schnitzeltony/meta-qt5-extra@0972828 Signed-off-by: Andreas Müller <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

Signed-off-by: Andreas Müller <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

Add a separate package for installing custom i.MX kernel headers. This way packages depending on these headers will need to be rebuilt only when the headers change instead of for every kernel change. Headers are installed to ${includedir}/imx, in the expected sub-folder, and dependents of the headers will need to add this include path. Signed-off-by: Tom Hochstein <[email protected]>

Signed-off-by: Tom Hochstein <[email protected]>

Find ion.h and version.h in linux-imx-headers instead of kernel. Signed-off-by: Tom Hochstein <[email protected]>

This builds on top of original recipe provided by Tom and do minor style and simplicity rework. - Add minor comments on the recipe for why it is doing each specific step - Add ALLOW_EMPTY for PN so it can be installed with SDK - Fix minor code style issues Signed-off-by: Otavio Salvador <[email protected]>

This reworks make use of linux-imx-headers and set it as SoC arch compatible. Signed-off-by: Otavio Salvador <[email protected]>

The code does not require anything that is machine specific and just use standard Linux APIs so it has no reason to depend on Linux kernel. Signed-off-by: Otavio Salvador <[email protected]>

This reworks make use of linux-imx-headers and set it as SoC arch compatible. Signed-off-by: Otavio Salvador <[email protected]>

Signed-off-by: Tom Hochstein <[email protected]>

…aders Signed-off-by: Tom Hochstein <[email protected]>

Signed-off-by: Tom Hochstein <[email protected]>

This allow to easy reuse of binary packages among similar SoCs. The usual use for this is to share SoC specific packages among different boards independently of the kernel version it is using, as far it is ABI compatible with the official version it will just work. Following recipes has been reworked to make use of the class: - imx-lib - imx-test - imx-vpu-hantro - imx-vpu - imx-alsa-plugins - gstreamer1.0-plugins-base - gstreamer1.0-plugins-imx - imx-gst1.0-plugin Signed-off-by: Otavio Salvador <[email protected]> Signed-off-by: Tom Hochstein <[email protected]>

*update to lsdk 1812 tag include the following changes d3111f0 - Merge pull request #28 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 3de6197 - Fixed build failure issue. 850f7b0 - Merge pull request #27 in DQNS/vpp from ~NXA12342/vpp:18.01 to 18.01 bb942a3 - dpdk/ipsec: add locks on session data hash updates 2e647f4 - Merge pull request #26 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 f242992 - PVT: ipsec: Fixed capability matching for openssl based sha1 authentication d7133de - Adding copyright for IPsec protocol offload work a0a8384 - Fixed copyright issue 8ac7782 - Fixed Debian pkg errors with Ubuntu 18.04 99f3b56 - Address compilation issues with Java > 1.8 09ba9a8 - Introducing env variables to include non-standard include in libs paths 9a24604 - glibc 2.27 fix 25c590a - Optimizing Crypto Dequeue Node to prevent buffer losses d8409f4 - Merge branch '18.01' of ssh://bitbucket.sw.nxp.com/~nxa19696/vpp into 18.01 731a2e5 - Added option for enabling RSS 3a97655 - Merge pull request #19 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 e47fe7d - Enable use of Maximum QP in Sec Device when available 723d633 - Merge pull request #18 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 a99e163 - PVT:dpdk_plugin: introducing IPSec protocol offload support 5f9b2c1 - Fixed Port detection mechanism for DPAA platforms f5724cd - Fixed debian pkg support for ARM64 platforms 29755c5 - Upstreamed: Fix to start Crypto Dev 351b6fd - Added support for Single CPU usecase with events 49ddf3b - ipsec: workaround for crypto devices having single queue d6adb7d - Tune config file for caam_jr driver b4a490c - Adjusting number of buffers for LS1012 ee5b872 - Merge pull request #13 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 b40602f - Merge branch '18.01' of ssh://bitbucket.sw.nxp.com/~nxa19696/vpp into 18.01 d8edb01 - Introduced Check for Heap allocation failure 7c551f6 - Merge pull request #12 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 43bef3e - Tuning Memory requirements for LS1012 ff02d6e - README_nxp updated 984ef5b - Adjusting Socket Memory requiremets Signed-off-by: Chunrong Guo <[email protected]>

*update to lsdk 1909 tag include the following changes: 4e8d2e5 - Merge pull request #19 in DASH/optee_os from ~NXA19713/optee_os:master to master 94bd7cc - Copyright header update. 9c09a28 - Merge pull request #18 in DASH/optee_os from ~NXA19713/optee_os:master to master 587183a - plat-ls:add LS1028ARDB platform Signed-off-by: Chunrong Guo <[email protected]>

*update to lsdk 1812 tag include the following changes d3111f0 - Merge pull request Freescale#28 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 3de6197 - Fixed build failure issue. 850f7b0 - Merge pull request Freescale#27 in DQNS/vpp from ~NXA12342/vpp:18.01 to 18.01 bb942a3 - dpdk/ipsec: add locks on session data hash updates 2e647f4 - Merge pull request Freescale#26 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 f242992 - PVT: ipsec: Fixed capability matching for openssl based sha1 authentication d7133de - Adding copyright for IPsec protocol offload work a0a8384 - Fixed copyright issue 8ac7782 - Fixed Debian pkg errors with Ubuntu 18.04 99f3b56 - Address compilation issues with Java > 1.8 09ba9a8 - Introducing env variables to include non-standard include in libs paths 9a24604 - glibc 2.27 fix 25c590a - Optimizing Crypto Dequeue Node to prevent buffer losses d8409f4 - Merge branch '18.01' of ssh://bitbucket.sw.nxp.com/~nxa19696/vpp into 18.01 731a2e5 - Added option for enabling RSS 3a97655 - Merge pull request Freescale#19 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 e47fe7d - Enable use of Maximum QP in Sec Device when available 723d633 - Merge pull request Freescale#18 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 a99e163 - PVT:dpdk_plugin: introducing IPSec protocol offload support 5f9b2c1 - Fixed Port detection mechanism for DPAA platforms f5724cd - Fixed debian pkg support for ARM64 platforms 29755c5 - Upstreamed: Fix to start Crypto Dev 351b6fd - Added support for Single CPU usecase with events 49ddf3b - ipsec: workaround for crypto devices having single queue d6adb7d - Tune config file for caam_jr driver b4a490c - Adjusting number of buffers for LS1012 ee5b872 - Merge pull request Freescale#13 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 b40602f - Merge branch '18.01' of ssh://bitbucket.sw.nxp.com/~nxa19696/vpp into 18.01 d8edb01 - Introduced Check for Heap allocation failure 7c551f6 - Merge pull request Freescale#12 in DQNS/vpp from ~NXA19696/vpp:18.01 to 18.01 43bef3e - Tuning Memory requirements for LS1012 ff02d6e - README_nxp updated 984ef5b - Adjusting Socket Memory requiremets Signed-off-by: Chunrong Guo <[email protected]>

*update to lsdk 1909 tag include the following changes: 4e8d2e5 - Merge pull request Freescale#19 in DASH/optee_os from ~NXA19713/optee_os:master to master 94bd7cc - Copyright header update. 9c09a28 - Merge pull request Freescale#18 in DASH/optee_os from ~NXA19713/optee_os:master to master 587183a - plat-ls:add LS1028ARDB platform Signed-off-by: Chunrong Guo <[email protected]>

otavio requested changes Oct 24, 2018

View reviewed changes

otavio reviewed Oct 24, 2018

View reviewed changes

thochstein commented Oct 24, 2018

View reviewed changes

recipes-kernel/linux/linux-imx-headers_4.9.123.bb Show resolved Hide resolved

thochstein commented Oct 25, 2018

View reviewed changes

otavio reviewed Oct 25, 2018

View reviewed changes

otavio approved these changes Oct 26, 2018

View reviewed changes

otavio requested a review from angolini October 26, 2018 01:55

thochstein commented Oct 26, 2018

View reviewed changes

u-boot-qoriq: use a u-boot-qoriq-common include

1925b1c

Use a common file to make easier update, maintain and create others U-Boot recipes like U-Boot fw-utils. Signed-off-by: Joris Offouga <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

thochstein commented Oct 26, 2018

View reviewed changes

u-boot-qoriq: Add recipe fw-utils

bb4dcaa

Initial support for fw utils for qoriq Signed-off-by: Joris Offouga <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

thochstein commented Oct 26, 2018

View reviewed changes

guochunrong and others added 11 commits October 26, 2018 14:04

ls1046ardb-be : remove qe-ucode

1da981a

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

ls1012afrwy: update KERNEL_DEVICETREE

a44459f

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

rcw: add ls1088ardb_pb support

3ca6320

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

ls1088ardb_pb: add machine config

03d5ab3

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

linux-fslc: upgrade to 4.18.12

c2df166

Signed-off-by: Andreas Müller <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

ppa: update LICENSE

df9b306

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

ls1012afrwy-32b: add machine config

5922dac

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

optee-os-qoriq: support qoriq-arm64

f3abc1c

Signed-off-by: Chunrong Guo <[email protected]> Signed-off-by: Otavio Salvador <[email protected]>

gstreamer1.0-plugins-base: Use linux-imx-headers instead of kernel

8007991

Signed-off-by: Tom Hochstein <[email protected]>

thochstein and others added 10 commits October 26, 2018 14:23

imx-vpu-hantro: Replace kernel dependence with linux-imx-headers

5a3ebf0

Find ion.h and version.h in linux-imx-headers instead of kernel. Signed-off-by: Tom Hochstein <[email protected]>

imx-lib: Use linux-imx-headers

92f94da

This reworks make use of linux-imx-headers and set it as SoC arch compatible. Signed-off-by: Otavio Salvador <[email protected]>

imx-test: Use linux-imx-headers

b172aa6

This reworks make use of linux-imx-headers and set it as SoC arch compatible. Signed-off-by: Otavio Salvador <[email protected]>

imx-uuc: Drop virtual/kernel dependency

083f1bb

The code does not require anything that is machine specific and just use standard Linux APIs so it has no reason to depend on Linux kernel. Signed-off-by: Otavio Salvador <[email protected]>

imx-vpu: Use linux-imx-headers

8171cf7

This reworks make use of linux-imx-headers and set it as SoC arch compatible. Signed-off-by: Otavio Salvador <[email protected]>

imx-alsa-plugins: Replace kernel dependence with linux-imx-headers

f257d8f

Signed-off-by: Tom Hochstein <[email protected]>

gstreamer1.0-plugins-imx: Replace kernel dependence with linux-imx-he…

46510a1

…aders Signed-off-by: Tom Hochstein <[email protected]>

imx-gst1.0-plugin: Replace kernel dependence with linux-imx-headers

700abd5

Signed-off-by: Tom Hochstein <[email protected]>

otavio merged commit bc937ad into Freescale:master Oct 26, 2018

thochstein deleted the L4.9.123-2.3.0-pr1 branch November 1, 2018 15:47

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

linux-imx-headers #19

linux-imx-headers #19

thochstein commented Oct 24, 2018

otavio left a comment

otavio Oct 24, 2018

otavio Oct 24, 2018

otavio commented Oct 25, 2018 •

edited

Loading

thochstein Oct 25, 2018

otavio Oct 25, 2018

otavio Oct 25, 2018

otavio commented Oct 26, 2018

gibsson commented Oct 26, 2018

otavio commented Oct 26, 2018

gibsson commented Oct 26, 2018

otavio commented Oct 26, 2018

thochstein Oct 26, 2018

otavio Oct 26, 2018

thochstein Oct 26, 2018

otavio Oct 26, 2018

thochstein Oct 26, 2018

thochstein Oct 26, 2018

otavio Oct 26, 2018

linux-imx-headers #19

linux-imx-headers #19

Conversation

thochstein commented Oct 24, 2018

otavio left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otavio commented Oct 25, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otavio commented Oct 26, 2018

gibsson commented Oct 26, 2018

otavio commented Oct 26, 2018

gibsson commented Oct 26, 2018

otavio commented Oct 26, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

otavio commented Oct 25, 2018 •

edited

Loading