Re: [yocto] [meta-dpdk][PATCH] [RFC] dpdk: Remove v17
Hello On Tue, 2019-09-24 at 10:40 +0800, zhe...@windriver.com wrote: > From: He Zhe > > openvswith used not to be able to work with dpdk v18. That's one of > the reasons > why we keep v17. Now that openvswitch in meta-virtulization has been > upgraded to > v2.11, officially claimed support of dpdk18, we can drop dpdk v17. > Could you send this to meta-intel list too since the README still mentions that list as the place where patches should be sent? Just in case someone is watching Intel list for updates ... Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-dpdk][PATCH] dpdk: Skip build if necessary kernel options is not included
On Mon, 2019-09-16 at 15:56 +0800, zhe...@windriver.com wrote:
> From: He Zhe
>
> dpdk depends on some kernel configuration options without which it is
> not able
> to successfully build.
>
> Signed-off-by: He Zhe
> ---
> recipes-extended/dpdk/dpdk.inc | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/recipes-extended/dpdk/dpdk.inc b/recipes-
> extended/dpdk/dpdk.inc
> index 3b997eb..9c9b397 100644
> --- a/recipes-extended/dpdk/dpdk.inc
> +++ b/recipes-extended/dpdk/dpdk.inc
> @@ -1,6 +1,11 @@
> DESCRIPTION = "Intel(r) Data Plane Development Kit"
> HOMEPAGE = "http://dpdk.org;
>
> +python () {
> +if not bb.utils.contains('KERNEL_FEATURES', 'features/intel-
> dpdk/intel-dpdk.scc', True, False, d):
> +raise bb.parse.SkipPackage("dpdk requires features/intel-
> dpdk/intel-dpdk.scc in KERNEL_FEATURES to build")
> +}
> +
I think this won't work for people who don't use yocto-kernel-cache.
Thanks,
Anuj
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-dpdk][PATCH] dpdk: support usrmerge
On Fri, 2019-08-30 at 13:58 +0800, changqing...@windriver.com wrote:
> -export
> MODULE_DIR="/lib/modules/${KERNEL_VERSION}/kernel/drivers/net"
> +export MODULE_DIR="${@bb.utils.contains('DISTRO_FEATURES','usrmerge'
> ,'/usr','',d)}/lib/modules/${KERNEL_VERSION}/kernel/drivers/net"
> export RTE_SDK = "${S}"
>
Should this be:
MODULE_DIR =
"${nonarch_base_libdir}/modules/${KERNEL_VERSION}/kernel/drivers/net"
It should then be handled automatically. Can you please check?
Thanks,
Anuj
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble using initramfs
On Fri, 2019-08-16 at 10:26 +0200, Moritz Porst wrote: > > Which branch are you using? Can you try the latest master with wic? > > There was a fix to wic to allow copying the kernel image with > > bundled > > initramfs to boot partition instead of the one without when > > INITRAMFS_IMAGE_BUNDLE is 1. > > > > > > I didn't ask the original question but have the same > problem. I have the thud branch checked out, but I couldn't > find > that fix on google. Can you elaborate on this ? > > > > Please see: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=b697aba61e55b93aa1ebf59a369d182c7a14c313 Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trouble using initramfs
On Thu, 2019-08-15 at 19:12 -0300, Antonio Teixeira wrote: > Hello. > > I've been having trouble with loading initramfs on boot when the > initramfs is bundled with the kernel image. > I've been using the following options in local.conf: > INITRAMFS_IMAGE = "core-image-minimal-initramfs" > INITRAMFS_IMAGE_BUNDLE = "1" > > I'm using the linux-intel kernel from the meta-intel layer, however, > when booting, the kernel simply doesn't load the initramfs. > > If I set INITRAMFS_IMAGE_BUNDLE to "0", copy the generated initramfs > image to the boot partition, and then point grub to the external > initramfs.cpio.gz image using the initrd option in the boot entry > config, the kernel loads it fine and everything works. Which branch are you using? Can you try the latest master with wic? There was a fix to wic to allow copying the kernel image with bundled initramfs to boot partition instead of the one without when INITRAMFS_IMAGE_BUNDLE is 1. Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [PATCH 1/3] intel-media-driver: check for "opengl" feature
Hi Hongxu I have merged these changes but could you send these to meta-intel list in future please? On Wed, 2019-07-24 at 18:11 +0800, Hongxu Jia wrote: > Since comit [a78c420 libva: check for "opengl" feature] applied in > oe-core, > and intel-media-driver depends on libva, it should check for "opengl" > feature too. > > Signed-off-by: Hongxu Jia > --- > recipes-multimedia/libva/intel-media-driver_19.2.0.bb | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/recipes-multimedia/libva/intel-media-driver_19.2.0.bb > b/recipes-multimedia/libva/intel-media-driver_19.2.0.bb > index 8656992..8084567 100644 > --- a/recipes-multimedia/libva/intel-media-driver_19.2.0.bb > +++ b/recipes-multimedia/libva/intel-media-driver_19.2.0.bb > @@ -14,6 +14,9 @@ LIC_FILES_CHKSUM = " > file://LICENSE.md;md5=6aab5363823095ce682b155fef0231f0 \ > # Only for 64 bit until this is resolved: > https://github.com/intel/media-driver/issues/356 > COMPATIBLE_HOST = '(x86_64).*-linux' > > +inherit distro_features_check > +REQUIRED_DISTRO_FEATURES = "opengl" > + > DEPENDS += "libva gmmlib" > > SRC_URI = "git://github.com/intel/media- > driver.git;protocol=https;branch=intel-media-19.2 \ -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] wic: error when using --rootfs-dir=${IMAGE_ROOTFS}/data
On Tue, 2019-07-16 at 08:38 +0200, Belisko Marek wrote:
> I have wks file with following content:
>
> part ubootenv --ondisk=mmcblk --no-table --size 12
> part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat
> --label boot --active --align 1024 --size 16
> part /root --source rootfs --ondisk mmcblk --fstype=ext4 --label
> rootA
> --align 1024 --fixed-size 300 --exclude-path data/
> part /data --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/data --ondisk
> "mmcblk" --fstype=ext4 --label data --align 1024 --fixed-size 200
>
> Basically I want to create extra data partition with content from
> rootfs /data directory. When wic image is created I'm getting strange
> errors like:
>
> Couldn't get bitbake variable from
> /home/marekbelisko/.build/tmp/sysroots/raspberrypi0-
> wifi/imgdata/${IMAGE_ROOTFS}/data.env.
> | File /home/marekbelisko/.build/tmp/sysroots/raspberrypi0-
> wifi/imgdata/${IMAGE_ROOTFS}/data.env
> doesn't exist.
If you haven't tried this already, renaming .wks to .wks.in might help.
Thanks,
Anuj
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-dpdk][PATCH] dpdk: Fix do_compile failure for qemux86 and qemux86-64
On Tue, 2019-06-11 at 11:06 +0800, zhe...@windriver.com wrote:
> From: He Zhe
>
> DPDK_TARGET_MACHINE in bbappend in other layers forms the dpdk-
> internal variable
> MACHINE_CFLAGS which is passed to dpdk compilation command line
> containing the
> first -march parameter. And EXTRA_CFLAGS in dpdk.inc is passed to
> dpdk command
> line containing the second -march parameter. By mistake, the first
> -march had
> always overwritten the second one until the following commit of GCC
> v9.1.0
> 8c0f695d83d1 ("driver: Also prune joined switches with negation").
>
> Since it was fixed, the second -march, which was core2 for qemux86-64
> or
> core2-32 for qemux86, began to take effect. But core2* does not have
> SSE4.2
> feature which is required by some dpdk instruction optimization and
> thus cause
> the following compilation failure.
>
> 9.1.0/include/smmintrin.h:179:1: error: inlining failed in call to
> always_inline
> '_mm_blendv_epi8': target specific option mismatch
> 179 | _mm_blendv_epi8 (__m128i __X, __m128i __Y, __m128i __M)
> | ^~~
>
> This patch adds DPDK_EXTRA_CFLAGS to append appropriate -march,
> corei7 which is
> minimum and clear and independent of host machine, to dpdk
> compilation command
> line to overwrite all previous ones, without having to change dpdk
> source code.
>
> Note that as we do not want to change the default tune core2* for
> qemux86*, this
> patch just fixes the compilation error. It would probably not be able
> to run on
> qemux86* with corei7 tune.
I don't think overriding arch values in recipe is appropriate. Also the
recipe is setting COMPATIBLE_MACHINE to be null because of this reason.
If the MACHINE that we're building for doesn't support the features
required, then we shouldn't be building dpdk for it in my opinion.
Thanks,
Anuj
>
> Signed-off-by: He Zhe
> ---
> recipes-extended/dpdk/dpdk.inc | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-extended/dpdk/dpdk.inc b/recipes-
> extended/dpdk/dpdk.inc
> index a0e081a..0275e0c 100644
> --- a/recipes-extended/dpdk/dpdk.inc
> +++ b/recipes-extended/dpdk/dpdk.inc
> @@ -61,6 +61,9 @@ DPDK_RTE_TARGET_x86-64 = "x86_64-native-linuxapp-
> gcc"
> DPDK_RTE_TARGET_x86 = "i686-native-linuxapp-gcc"
> DPDK_RTE_TARGET_aarch64 = "arm64-${DPDK_TARGET_MACH}-linuxapp-gcc"
> export RTE_TARGET = "${DPDK_RTE_TARGET}"
> +DPDK_EXTRA_CFLAGS = ""
> +DPDK_EXTRA_CFLAGS_qemux86 ?= "-march=corei7"
> +DPDK_EXTRA_CFLAGS_qemux86-64 ?= "-march=corei7"
>
> # The list of intel Comms platforms and their target machine
> # process mapping. The supported target machine is listed under
> @@ -100,18 +103,18 @@ do_compile () {
>
> cd ${S}/${RTE_TARGET}
> oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu"
> \
> -EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> -I${STAGING_INCDIR}" \
> +EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
> CROSS="${TARGET_PREFIX}" \
> prefix="" LDFLAGS="${TUNE_LDARGS}" WERROR_FLAGS="-
> w" V=1
>
> cd ${S}/examples/
> oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu
> -fuse-ld=bfd" \
> -EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> -I${STAGING_INCDIR}" \
> +EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
> CROSS="${TARGET_PREFIX}" O="${S}/examples/$@/"
>
> cd ${S}/test/
> oe_runmake EXTRA_LDFLAGS="-L${STAGING_LIBDIR} --hash-style=gnu
> -fuse-ld=bfd" \
> -EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> -I${STAGING_INCDIR}" \
> +EXTRA_CFLAGS="${HOST_CC_ARCH} ${TOOLCHAIN_OPTIONS}
> ${DPDK_EXTRA_CFLAGS} -I${STAGING_INCDIR}" \
> CROSS="${TARGET_PREFIX}" O="${S}/test/$@/"
> }
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-dpdk][PATCH] dpdk: mk: disable warning for packed member pointer
Thanks, I have included this for 18.11 as well and merged.
Thanks,
Anuj
On Tue, 2019-06-11 at 11:06 +0800, zhe...@windriver.com wrote:
> From: He Zhe
>
> Backport a patch from upstream to fix the following build failure.
>
> x86_64-native-linuxapp-gcc/include/rte_ether.h:178:2: error:
> converting a packed 'const struct ether_addr' pointer (alignment 1)
> to a 'unaligned_uint16_t' {aka 'const short
> unsigned int'} pointer (alignment 2) may result in an unaligned
> pointer value [-Werror=address-of-packed-member]
> > 178 | const unaligned_uint16_t *ea_words = (const
> > unaligned_uint16_t *)ea;
> > | ^
>
> Signed-off-by: He Zhe
> ---
> ...disable-warning-for-packed-member-pointer.patch | 48
> ++
> recipes-extended/dpdk/dpdk_17.11.3.bb | 1 +
> 2 files changed, 49 insertions(+)
> create mode 100644 recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-
> warning-for-packed-member-pointer.patch
>
> diff --git a/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-
> warning-for-packed-member-pointer.patch b/recipes-
> extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-packed-member-
> pointer.patch
> new file mode 100644
> index 000..70a8dec
> --- /dev/null
> +++ b/recipes-extended/dpdk/dpdk/dpdk-17.11-mk-disable-warning-for-
> packed-member-pointer.patch
> @@ -0,0 +1,48 @@
> +From a385972c3675dd2b4792ab5b3cf7a536e6f9846c Mon Sep 17 00:00:00
> 2001
> +From: Reshma Pattan
> +Date: Thu, 2 May 2019 10:33:34 +0100
> +Subject: [PATCH] mk: disable warning for packed member pointer
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +gcc 9 on Fedora 30 gives an error
> +"taking address of packed member may result in an
> +unaligned pointer value" warnings.
> +
> +For clang builds this warning is already disabled,
> +so disable "-Waddress-of-packed-member" for gcc builds
> +also.
> +
> +Snippet of build error:
> +lib/librte_eal/linux/eal/eal_memalloc.c: In function
> ‘alloc_seg_walk’:
> +lib/librte_eal/linux/eal/eal_memalloc.c:768:12: error:
> +taking address of packed member of ‘struct rte_mem_config’ may
> result
> +in an unaligned pointer value [-Werror=address-of-packed-member]
> + 768 | cur_msl = >memsegs[msl_idx];
> + |^~~
> +
> +Signed-off-by: Reshma Pattan
> +Tested-by: David Marchand
> +Upstream-Status: Backport
> +Signed-off-by: He Zhe
> +---
> + mk/toolchain/gcc/rte.vars.mk | 3 +++
> + 1 file changed, 3 insertions(+)
> +
> +diff --git a/mk/toolchain/gcc/rte.vars.mk
> b/mk/toolchain/gcc/rte.vars.mk
> +index d8b99fa..b852fcf 100644
> +--- a/mk/toolchain/gcc/rte.vars.mk
> b/mk/toolchain/gcc/rte.vars.mk
> +@@ -87,5 +87,8 @@ WERROR_FLAGS += -Wimplicit-fallthrough=2
> + WERROR_FLAGS += -Wno-format-truncation
> + endif
> +
> ++# disable packed member unalign warnings
> ++WERROR_FLAGS += -Wno-address-of-packed-member
> ++
> + export CC AS AR LD OBJCOPY OBJDUMP STRIP READELF
> + export TOOLCHAIN_CFLAGS TOOLCHAIN_LDFLAGS TOOLCHAIN_ASFLAGS
> +--
> +2.7.4
> +
> diff --git a/recipes-extended/dpdk/dpdk_17.11.3.bb b/recipes-
> extended/dpdk/dpdk_17.11.3.bb
> index 7fc89d2..af42ad8 100644
> --- a/recipes-extended/dpdk/dpdk_17.11.3.bb
> +++ b/recipes-extended/dpdk/dpdk_17.11.3.bb
> @@ -12,4 +12,5 @@ SRC_URI += "\
> file://dpdk-16.07-dpdk-fix-for-parellel-make-issue.patch \
> file://dpdk-17.02-dpdk-fix-installation-warning-and-
> issue.patch \
> file://dpdk-17.11-Fix-strncpy-error-for-GCC8.patch \
> +file://dpdk-17.11-mk-disable-warning-for-packed-member-
> pointer.patch \
> "
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Error in building new recipe for Jool network translator
On Thu, 2019-06-06 at 22:16 +0530, Gokul Raj wrote:
> Hi Ross,
>
> Thanks for the suggestion. I have tried with inheriting autotools-
> brokensep bbclass. Now bitbake got the path for compilation. But,
> bitbake compilation refering to native kernel src path for module
> compilation. For your information this package comes with both kernel
> module and userspace binary. Single makefile helps building both
> kernel module and userspace binary. Attached log for your reference.
>
> Any suggestion to compile this package.
Looking at the Makefile, I think adding this might help:
EXTRA_OEMAKE='KERNEL_DIR="${STAGING_KERNEL_BUILDDIR}"'
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [PATCH 1/2] netfilter/netfilter.cfg: remove CONFIG_NF_NAT_IPV4
Hi Bruce, Both these changes are only for master and are specific to v5.1. On Thu, 2019-05-16 at 10:26 +0800, Anuj Mittal wrote: > This has been removed starting v5.1 and nf_nat_ipv4,6 have been > merged > in nat core. > > https://github.com/torvalds/linux/commit/3bf195ae6037e310d693ff3313401cfaf1261b71 > > Signed-off-by: Anuj Mittal > --- > features/netfilter/netfilter.cfg | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/features/netfilter/netfilter.cfg > b/features/netfilter/netfilter.cfg > index 3d61881e..820c222e 100644 > --- a/features/netfilter/netfilter.cfg > +++ b/features/netfilter/netfilter.cfg > @@ -77,7 +77,6 @@ CONFIG_IP_NF_FILTER=m > CONFIG_IP_NF_TARGET_REJECT=m > CONFIG_NF_NAT=m > CONFIG_NF_NAT_NEEDED=y > -CONFIG_NF_NAT_IPV4=m > CONFIG_IP_NF_NAT=m > CONFIG_IP_NF_TARGET_SYNPROXY=m > CONFIG_IP_NF_TARGET_MASQUERADE=m > -- > 2.20.1 > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [Yocto-bsp] [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]
It's picking up the minimal image instead of full-cmdline? Can you try: runqemu tmp/deploy/images/qemux86/ or runqemu qemux86 core-image-full-cmdline Thanks, Anuj On Fri, 2019-05-10 at 06:46 +, AshishKumar Mishra wrote: > HI Members , > Good Afternoon. > > I am trying to recompile the kernel after changing kernel-config > option and then recompile the kernel using below mentioned steps > 1) bitbake -c menuconfig virtual/kernel > 2) bitbake -c diffconfig virtual/kernel ( copy the config- > fragment to ~/Desktop) > 3) bitbake -C deploy linux-yocto ( to recompile kernel ) > 4) runqemu qemux86 > > The timestamp of files in tmp/deploy/images/qemux86/* is updated > properly but the time shown by command "uname -a" always shows > older time & is not showing recently compiled times. > > I checked the kernel config options in image , i can see the changes > i did > from menuconfig , but not sure / confused as to why the time shown > by "uname -a" is not getting updated. > > Basically i am trying to change some kernel-config & check if the > compiled > kernel is getting updated or not. > > Attached along are the snapshot for the error. > > Can members please let me know what am i doing wrong here or missing, > > Thanks > Ashish. > > > > > > > -- ___ yocto-bsp mailing list yocto-bsp@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto-bsp
Re: [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]
It's picking up the minimal image instead of full-cmdline? Can you try: runqemu tmp/deploy/images/qemux86/ or runqemu qemux86 core-image-full-cmdline Thanks, Anuj On Fri, 2019-05-10 at 06:46 +, AshishKumar Mishra wrote: > HI Members , > Good Afternoon. > > I am trying to recompile the kernel after changing kernel-config > option and then recompile the kernel using below mentioned steps > 1) bitbake -c menuconfig virtual/kernel > 2) bitbake -c diffconfig virtual/kernel ( copy the config- > fragment to ~/Desktop) > 3) bitbake -C deploy linux-yocto ( to recompile kernel ) > 4) runqemu qemux86 > > The timestamp of files in tmp/deploy/images/qemux86/* is updated > properly but the time shown by command "uname -a" always shows > older time & is not showing recently compiled times. > > I checked the kernel config options in image , i can see the changes > i did > from menuconfig , but not sure / confused as to why the time shown > by "uname -a" is not getting updated. > > Basically i am trying to change some kernel-config & check if the > compiled > kernel is getting updated or not. > > Attached along are the snapshot for the error. > > Can members please let me know what am i doing wrong here or missing, > > Thanks > Ashish. > > > > > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [linux-yocto] [yocto] Timestamp error between zImage & uname-a [ Yocto-2.6.1 + Qemux86 ]
It's picking up the minimal image instead of full-cmdline? Can you try: runqemu tmp/deploy/images/qemux86/ or runqemu qemux86 core-image-full-cmdline Thanks, Anuj On Fri, 2019-05-10 at 06:46 +, AshishKumar Mishra wrote: > HI Members , > Good Afternoon. > > I am trying to recompile the kernel after changing kernel-config > option and then recompile the kernel using below mentioned steps > 1) bitbake -c menuconfig virtual/kernel > 2) bitbake -c diffconfig virtual/kernel ( copy the config- > fragment to ~/Desktop) > 3) bitbake -C deploy linux-yocto ( to recompile kernel ) > 4) runqemu qemux86 > > The timestamp of files in tmp/deploy/images/qemux86/* is updated > properly but the time shown by command "uname -a" always shows > older time & is not showing recently compiled times. > > I checked the kernel config options in image , i can see the changes > i did > from menuconfig , but not sure / confused as to why the time shown > by "uname -a" is not getting updated. > > Basically i am trying to change some kernel-config & check if the > compiled > kernel is getting updated or not. > > Attached along are the snapshot for the error. > > Can members please let me know what am i doing wrong here or missing, > > Thanks > Ashish. > > > > > > > -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [yocto] [meta-intel] fb: switching to inteldrmfb from efi vga
On Tue, 2018-11-13 at 12:30 +0300, Knoppix wrote: > yocto and meta-intel: 2.5.1/sumo > kernel=linux-yocto-4.15.18 > machine=intel-corei7-64 > distro=poky > > the problem is: > when I boot the system it comes to this message and frozees: " fb: > switching to amdgpudrmfb from efi vga" This error says amdgpu while the subject says intel driver ... Which one are you using and on which graphics card? Does it work if you use 4.14 kernel? > > I searched a lot, there is a workaround to solve problem (add > nomodeset to grub params) but when i set this splash screen doesn't > work. (also someone on stackoverflow says when you do nomodeset you > cannot use graphical acceleration.) > > There are a lot of old messages about this spesific problem which > they > say "it is solved in new version of kernel" or "a new intel drm-fix > will solve" but I came accros the problem now. > > Would you please advice me any tutorial to learn what's going on? > > (Excuse me for my english, I am not native) -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [patchtest-oe][PATCH] test_patch_cve.py: fix cve tag checking logic
On Wed, 2018-11-07 at 09:01 +, Richard Purdie wrote: > On Fri, 2018-11-02 at 14:03 +0800, Chen Qi wrote: > > The current logic for checking cve tag is not correct. It errors > > out if and only if the patch contains a line which begins with > > CVE-- and contains nothing else. > > > > It will not error out if the patch contains no CVE information, nor > > will it error out if the patch contains line like below. > > > > 'Fix CVE--' > > > > I can see that the cve tag checking logic tries to ensure the patch > > contains something like 'CVE: CVE--'. So fix to implement > > such > > logic. > > > > Signed-off-by: Chen Qi > > --- > > tests/test_patch_cve.py | 15 --- > > 1 file changed, 8 insertions(+), 7 deletions(-) > > Thanks, good find. > > I've merged this and I believe the instance should have it applied > now > too. > Not sure if this is related but it looks like the tests aren't running at all now ... https://patchwork.openembedded.org/project/oe-core/series/?ordering=-last_updated Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [poky] bug #8729 grub bootloader
Hi Dimitris On Tue, 2018-11-06 at 16:12 +0100, Dimitris Tassopoulos wrote: > > In this case the bootimg-efi.py script creates the extra partition, a > different grub.cfg and also > edits the /etc/fstab and mounts this partition over /boot and > therefore virtual/grub-bootconf > becomes unused. > > This raises the following questions: > - Why there are two different facilities to achieve the same thing? > - Why the second overrides the first one, instead of sharing the same > files? > - How to proceed from now on? > I think this needed --exclude-path in wks to be used to take effect. Please see: http://lists.openembedded.org/pipermail/openembedded-core/2018-February/147837.html and bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=10073 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] qemu and grub
On Tue, 2018-10-30 at 22:14 +0100, Dimitris Tassopoulos wrote: > Hi all. > > Usually I have a small x86_64 board that I test images. But for the > first > time I've tried to use yocto to do some development on grub. I've > used > qemu to do grub development before and I know that this works fine. I > just use grub-mkrescue to create images with my grub script and then > boot. > > Now I've tried to do the same with yocto after setting these to > local.conf > > MACHINE ??= "qemux86" > IMAGE_FSTYPES += " wic wic.vmdk" > WKS_FILE ?= "directdisk-multi-rootfs.wks" > IMAGE_INSTALL_append = " grub-efi" Can you check if MACHINE_FEATURES includes efi and include and try again if not? Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] meta-ti layer failed with Daisy
Hi Satya, > I am building the core-image-minimal for Daisy with meta-ti layer included in > bblayers.conf file after removing meta-yocto-bsp layer. I am getting the > error shown below, This is a very old version. Please update to one of the latest supported releases. > [Satya]~/Yocto-Daisy-Labs/poky/build > bitbake core-image-minimal > Loading cache: 100% > |#| > ETA: 00:00:00 > Loaded 1446 entries from dependency cache. > ERROR: No recipes available for: > /home/satya/Yocto-Daisy-Labs/poky/meta-ti/recipes-core/udev/eudev_%.bbappend > ERROR: Command execution failed: Exited with 1 This generally means that the bb file that this is an append for, wasn't found in any of the layers. Thanks, Anuj -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] conf/machine/ in my custom layer doesn't get parsed
Hi Issac, > I've created a custom meta layer over poky rocko and added it to > bblayer.conf. I've > also set the appropriate MACHINE value in > conf/local.conf: > > MACHINE = "colibri-imx6" > > There is a machine specific conf file in this meta layer, but it doesn't get > parsed. This > file is located at "conf/machine/colibri-imx6.conf" inside the meta layer. > > By checking the output of > > bitbake -e > > it seems that other machine-specific conf files like "meta-freescale- > 3rdparty/conf/machine/colibri-imx6.conf" are referenced and parsed. But there > is not > even a reference to my machine-specific conf file. Have you defined BBPATH in your layer.conf correctly? Thanks, Anuj > > Should I set some variables that hint the bitbake to parse machine specific > files in my > layer? > > Bests, > Isaac > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
