[yocto] [meta-cgl][PATCH] layer.conf: add hardknott to LAYERSERIES_COMPAT

2021-06-30 Thread Chen Qi 
Signed-off-by: Chen Qi 
---
 meta-cgl-common/conf/layer.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-cgl-common/conf/layer.conf b/meta-cgl-common/conf/layer.conf
index 8100e23..56ddbb9 100644
--- a/meta-cgl-common/conf/layer.conf
+++ b/meta-cgl-common/conf/layer.conf
@@ -11,6 +11,6 @@ BBFILE_PRIORITY_cgl-common = "7"
 
 LAYERDEPENDS_cgl-common = "core openembedded-layer networking-layer perl-layer 
filesystems-layer security selinux"
 
-LAYERSERIES_COMPAT_cgl-common = "warrior zeus dunfell gatesgarth"
+LAYERSERIES_COMPAT_cgl-common = "warrior zeus dunfell gatesgarth hardknott"
 
 require conf/distro/include/cgl_common_security_flags.inc
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54029): https://lists.yoctoproject.org/g/yocto/message/54029
Mute This Topic: https://lists.yoctoproject.org/mt/83909939/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto] [yocto-kernel-cache][master only] xilinx-zynqmp: add kernel options support for xilinx-zynqmp

2021-06-30 Thread quanyang.wang 
From: Quanyang Wang 

Add kernel options to enable features in xilinx-zynqmp.

Signed-off-by: Quanyang Wang 
---
 bsp/xilinx-zynqmp/xilinx-zynqmp.cfg | 8 
 1 file changed, 8 insertions(+)

diff --git a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg 
b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
index 1d22e8bcb..737cc3952 100644
--- a/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
+++ b/bsp/xilinx-zynqmp/xilinx-zynqmp.cfg
@@ -68,6 +68,8 @@ CONFIG_SPI_CADENCE=y
 CONFIG_SPI_XILINX=y
 CONFIG_SPI_ZYNQMP_GQSPI=y
 
+CONFIG_PINCTRL=y
+
 CONFIG_GPIOLIB=y
 CONFIG_OF_GPIO=y
 CONFIG_GPIO_CDEV=y
@@ -241,3 +243,9 @@ CONFIG_OF_CONFIGFS=y
 CONFIG_FPGA_MGR_DEBUG_FS=y
 
 CONFIG_ARM_PSCI_CPUIDLE=y
+
+CONFIG_ZYNQMP_FIRMWARE_DEBUG=y
+
+CONFIG_CRYPTO_DEV_ZYNQMP_SHA3=y
+CONFIG_CRYPTO_DEV_XILINX_RSA=y
+CONFIG_CRYPTO_DEV_ZYNQMP_AES=y
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10025): 
https://lists.yoctoproject.org/g/linux-yocto/message/10025
Mute This Topic: https://lists.yoctoproject.org/mt/83907552/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.10] [RT] kernel code for marvell cn96xx and marvell cn106xx

2021-06-30 Thread Bruce Ashfield 
In message: [linux-yocto][linux-yocto v5.10] [RT] kernel code for marvell 
cn96xx and marvell cn106xx
on 30/06/2021 Ruiqiang Hao wrote:

> Hi Bruce,
> 
> Please help to create branch and merge code into our linux-yocto repo.
> 
> repo:
>   linux-yocto
> branch:
>   v5.10/standard/preempt-rt/cn-sdkv5.4/octeon

merged!

Bruce

> 
> Thanks,
> Ruiqiang
> 
> The following changes since commit 4a59bc57b2be77da9394b10eb37067da7d63b7a4:
> 
>   Merge branch 'v5.10/standard/base' into v5.10/standard/preempt-rt/base 
> (2021-06-25 20:05:35 -0400)
> 
> are available in the Git repository at:
> 
>   https://github.com/cythe/linux.git 
> v5.10/standard/preempt-rt/cn-sdkv5.4/octeon.v3
> 
> for you to fetch changes up to dab9728677cd3a1a1763bfce2edc7919ff4d7e00:
> 
>   spi: spi-octeontx2: fix erase sector error by limit spi buswidth 
> (2021-06-30 17:54:53 +0800)
> 
> 
> Aaron Williams (4):
>   mmc: octeontx2: Add tuning support for HS400 mode
>   mmc: octeontx2: Use flags for hardware differences
>   mmc: octeontx2: fix handling calibration glitch
>   Marvell: CN10K: Display version information for flash components
> 
> Aleksey Makarov (1):
>   octeontx2-pf: Add support for PTP clock
> 
> Alex Belits (2):
>   kernel/exit.c: Add task cleanup callbacks
>   arm64: Add support for ASID locking
> 
> Andrew Pinski (1):
>   arm64: Add workaround for Cavium erratum 36890
> 
> Angela Czubak (2):
>   octeontx2-af: fix rvu_sso_ggrp_taq_flush
>   octeontx2-af: fix cgx_lmac_rx_tx_enable
> 
> Anil Kumar Reddy (1):
>   hwrng: cn10k: Add random number generator health check
> 
> Baha Mesleh (1):
>   octeontx2-bphy-netdev: fix cleanup sequence in char device release
> 
> Ben Peled (1):
>   cpufreq: armada: enable ap807-cpu-clk.
> 
> Bharat Bhushan (5):
>   soc/octeontx2 : Add driver support for NMI GTI watchdog
>   octeontx2: gti: Fix task stack pointer corruption
>   perf/marvell: CN10k DDR performance monitor support
>   perf/marvell: cn10k DDR perfmon event overflow handling
>   perf/marvell: Set DDR perf event ownership
> 
> Bhaskara Budiredla (5):
>   arm64: Add workaround for Marvell erratum 38545
>   octeontx2: marvell: Add driver support for LLC lock and unlock
>   drivers: mmc: Adds pstore driver to store kernel crash dumps to MMC
>   drivers: mmc: enables mmc polling for pstore path
>   drivers: perf: Add LLC-TAD perf counter support
> 
> Burla, Satananda (1):
>   octeontx2-dpi: Fix DPI engine blks allocation
> 
> Chandrakala Chavva (15):
>   net: thunderx: Fix RXAUI link status
>   driver: net: thunder: Print 1000Base-X or SGMII based on mode.
>   mmc: cavium: Use proper register to clear interrupts
>   mmc: octeontx2: Fix tuning for T96 C0
>   mmc: octeontx2: Configure flags for T96 pass B0
>   octeontx2-serdes: Update PRBS APIs to start/stop per QLM lane
>   octeontx2-serdes: Fix parameter passed to start_prbs().
>   octeontx2-serdes: Fix prbs error reporting
>   driver: serdes_debugfs: Allow user to clear prbs errors.
>   octeontx2-serdes: Fix prbs per lane configuration
>   driver: serdes_debugfs: Add new smc call to tune serdes
>   driver: serdes_debugfs: Add new smc call for serdes loopback
>   driver: serdes_debugfs: Add inject optional parameter to prbs command
>   driver: soc: marvell: Don't enable mvmdio driver by default
>   drivers: soc: marvell: Add config option for serdes diagnostics
> 
> Christina Jacob (16):
>   net:thunderx: fix memory leak in nicvf driver.
>   net: thunderx: Do a PCS reset upon SGMII link toggle
>   octeontx2-pf: Adding ethtool support for link status information.
>   octeontx2-af: Support to get link info like current speed, fec etc
>   octeontx2-pf: Ethtool support for fec configuration
>   octeontx2-af: Move to rvu_fwdata version 1.
>   octeontx2-pf: Add ethtool -m option support.
>   octeontx2-af: Update fwadata structure with few more reserved fields.
>   octeontx2-af: Fetch FEC stats of the physical link
>   octeontx2-pf: Support to display fec counters also in ethtool stats.
>   octeontx2-pf: Support to display current settings of a vf network 
> interface via ethtool
>   octeontx2-af: Introduce SET_LINK_MODE command to change various 
> configurations of a network interface.
>   octeontx2-pf: support to change link speed and autoneg
>   octeontx2-pf: remove redundant changes from speed change suppcrt.
>   octeontx-af: Interface mode change feature via ethtool
>   octeontx2-pf: Interface Mode change using ethtool.
> 
> Damian Eppel (3):
>   soc: marvell: MDIO uio driver
>   drivers: soc: marvell: PHY diagnostics debugfs driver
>   drivers: soc: marvell: PHY diagnostics driver update
> 
> Dana Vardi (1):
>   net: mvpp2: prs: ipv4 different ihl support
> 
> Felix

Re: [linux-yocto][linux-yocto v5.10] kernel code for marvell cn96xx and marvell cn106xx

2021-06-30 Thread Bruce Ashfield 
In message: [linux-yocto][linux-yocto v5.10] kernel code for marvell cn96xx and 
marvell cn106xx
on 30/06/2021 Ruiqiang Hao wrote:

> Hi Bruce,
> 
> Please help to create branch and merge code into our linux-yocto repo.
> 
> repo:
>   linux-yocto
> branch:
>   v5.10/standard/cn-sdkv5.4/octeon

The branch has been created and the BSP merged.

Bruce

> 
> Thanks,
> Ruiqiang
> 
> The following changes since commit 139fe7d68413054f850e206ab749f97a968867a8:
> 
>   rcu: Fix stall-warning deadlock due to non-release of rcu_node ->lock 
> (2021-06-25 20:05:02 -0400)
> 
> are available in the Git repository at:
> 
>   https://github.com/cythe/linux.git v5.10/standard/cn-sdkv5.4/octeon.v3
> 
> for you to fetch changes up to 3db5ffbecee7b769aa762a1a9cd82aee7cc18fe0:
> 
>   spi: spi-octeontx2: fix erase sector error by limit spi buswidth 
> (2021-06-30 15:37:11 +0800)
> 
> 
> Aaron Williams (4):
>   mmc: octeontx2: Add tuning support for HS400 mode
>   mmc: octeontx2: Use flags for hardware differences
>   mmc: octeontx2: fix handling calibration glitch
>   Marvell: CN10K: Display version information for flash components
> 
> Aleksey Makarov (1):
>   octeontx2-pf: Add support for PTP clock
> 
> Alex Belits (2):
>   kernel/exit.c: Add task cleanup callbacks
>   arm64: Add support for ASID locking
> 
> Andrew Pinski (1):
>   arm64: Add workaround for Cavium erratum 36890
> 
> Angela Czubak (2):
>   octeontx2-af: fix rvu_sso_ggrp_taq_flush
>   octeontx2-af: fix cgx_lmac_rx_tx_enable
> 
> Anil Kumar Reddy (1):
>   hwrng: cn10k: Add random number generator health check
> 
> Baha Mesleh (1):
>   octeontx2-bphy-netdev: fix cleanup sequence in char device release
> 
> Ben Peled (1):
>   cpufreq: armada: enable ap807-cpu-clk.
> 
> Bharat Bhushan (5):
>   soc/octeontx2 : Add driver support for NMI GTI watchdog
>   octeontx2: gti: Fix task stack pointer corruption
>   perf/marvell: CN10k DDR performance monitor support
>   perf/marvell: cn10k DDR perfmon event overflow handling
>   perf/marvell: Set DDR perf event ownership
> 
> Bhaskara Budiredla (5):
>   arm64: Add workaround for Marvell erratum 38545
>   octeontx2: marvell: Add driver support for LLC lock and unlock
>   drivers: mmc: Adds pstore driver to store kernel crash dumps to MMC
>   drivers: mmc: enables mmc polling for pstore path
>   drivers: perf: Add LLC-TAD perf counter support
> 
> Burla, Satananda (1):
>   octeontx2-dpi: Fix DPI engine blks allocation
> 
> Chandrakala Chavva (15):
>   net: thunderx: Fix RXAUI link status
>   driver: net: thunder: Print 1000Base-X or SGMII based on mode.
>   mmc: cavium: Use proper register to clear interrupts
>   mmc: octeontx2: Fix tuning for T96 C0
>   mmc: octeontx2: Configure flags for T96 pass B0
>   octeontx2-serdes: Update PRBS APIs to start/stop per QLM lane
>   octeontx2-serdes: Fix parameter passed to start_prbs().
>   octeontx2-serdes: Fix prbs error reporting
>   driver: serdes_debugfs: Allow user to clear prbs errors.
>   octeontx2-serdes: Fix prbs per lane configuration
>   driver: serdes_debugfs: Add new smc call to tune serdes
>   driver: serdes_debugfs: Add new smc call for serdes loopback
>   driver: serdes_debugfs: Add inject optional parameter to prbs command
>   driver: soc: marvell: Don't enable mvmdio driver by default
>   drivers: soc: marvell: Add config option for serdes diagnostics
> 
> Christina Jacob (16):
>   net:thunderx: fix memory leak in nicvf driver.
>   net: thunderx: Do a PCS reset upon SGMII link toggle
>   octeontx2-pf: Adding ethtool support for link status information.
>   octeontx2-af: Support to get link info like current speed, fec etc
>   octeontx2-pf: Ethtool support for fec configuration
>   octeontx2-af: Move to rvu_fwdata version 1.
>   octeontx2-pf: Add ethtool -m option support.
>   octeontx2-af: Update fwadata structure with few more reserved fields.
>   octeontx2-af: Fetch FEC stats of the physical link
>   octeontx2-pf: Support to display fec counters also in ethtool stats.
>   octeontx2-pf: Support to display current settings of a vf network 
> interface via ethtool
>   octeontx2-af: Introduce SET_LINK_MODE command to change various 
> configurations of a network interface.
>   octeontx2-pf: support to change link speed and autoneg
>   octeontx2-pf: remove redundant changes from speed change suppcrt.
>   octeontx-af: Interface mode change feature via ethtool
>   octeontx2-pf: Interface Mode change using ethtool.
> 
> Damian Eppel (3):
>   soc: marvell: MDIO uio driver
>   drivers: soc: marvell: PHY diagnostics debugfs driver
>   drivers: soc: marvell: PHY diagnostics driver update
> 
> Dana Vardi (1):
>   net: mvpp2: prs: ipv4 different ihl support
>

Re: [linux-yocto] [linux-yocto v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx]: update kernel with NXP pre-released SDK bsp30 v5.10 patches

2021-06-30 Thread Bruce Ashfield 
In message: [linux-yocto] [linux-yocto 
v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx]: update kernel with NXP pre-released 
SDK bsp30 v5.10 patches
on 30/06/2021 Zhantao Tang wrote:

> 
> Hi Bruce,
> 
> 
> There are 828 patches from NXP pre-released SDK bsp30 v5.10 kernel tree, and 
> for this update,
> a new branch v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx based on 
> v5.10/standard/base shoule be created,
> and all the patches are applied to the new branch, the patches infos as 
> following:
> 
> The following changes since commit 
> 139fe7d68413054f850e206ab749f97a968867a8:
> 
>   rcu: Fix stall-warning deadlock due to non-release of rcu_node 
> ->lock (2021-06-25 20:05:02 -0400)
> 
> are available in the Git repository at:
> 
>   https://github.com/zhantaotang/linux-yocto-std 
> v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx
> 
> for you to fetch changes up to 
> 4c7e068410164425fc262dc97646767a9487212a:
> 
>   doc: s32gen1: mc_rgm: Add fsl,s32gen1-mc_rgm.yaml documentation 
> file (2021-06-29 14:01:40 +0800)
> 
> 
> 
> Would you please help to create the new branch
> 
>   v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx based on v5.10/standard/base
> 
> and merge the patches into the above new created branch 
> v5.10/standard/nxp-sdk-5.10/nxp-s32g2xx?

Branch created and the merge has been completed.

Thanks for the BSP support, it is most appreciated!

Bruce

> 
> 
> Thanks,
> Zhantao
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10022): 
https://lists.yoctoproject.org/g/linux-yocto/message/10022
Mute This Topic: https://lists.yoctoproject.org/mt/83883374/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto] [yocto-kernel-cache][yocto-5.4][PATCH] NFS: fix general protection fault in nfs_mount

2021-06-30 Thread Bruce Ashfield 
In message: [yocto-kernel-cache][yocto-5.4][PATCH] NFS: fix general protection 
fault in nfs_mount
on 28/06/2021 Ovidiu Panait wrote:

> While fuzzing the kernel with syzkaller, the following issue was triggered:
> 
> Call Trace:
>  strlen usr/src/kernel/include/linux/string.h:306 [inline]
>  nfs_mount+0x316/0x740 usr/src/kernel/fs/nfs/mount_clnt.c:174
>  ? __kernel_text_address+0x12/0x40 usr/src/kernel/kernel/extable.c:95
>  ? mnt_xdr_dec_mountres+0x3a0/0x3a0 usr/src/kernel/fs/nfs/mount_clnt.c:371
>  ? arch_stack_walk+0xa2/0xf0 usr/src/kernel/arch/x86/kernel/stacktrace.c:26
>  ? mark_usage usr/src/kernel/kernel/locking/lockdep.c:3426 [inline]
>  ? __lock_acquire+0x557/0x5ed0 usr/src/kernel/kernel/locking/lockdep.c:3752
>  nfs_request_mount.constprop.0+0x42e/0x680 usr/src/kernel/fs/nfs/super.c:1817
>  ? nfs_fs_mount+0x2870/0x2870 usr/src/kernel/fs/nfs/super.c:2080
>  ? lockdep_hardirqs_on+0x580/0x580 
> usr/src/kernel/kernel/locking/lockdep.c:3264
>  ? lockdep_hardirqs_on+0x580/0x580 
> usr/src/kernel/kernel/locking/lockdep.c:3264
>  nfs_try_mount_request usr/src/kernel/fs/nfs/super.c:1839 [inline]
>  nfs_try_mount+0x25b/0x93a usr/src/kernel/fs/nfs/super.c:1907
>  ? lock_downgrade+0x770/0x770 usr/src/kernel/kernel/locking/lockdep.c:4043
>  ? nfs_request_mount.constprop.0+0x680/0x680 
> usr/src/kernel/fs/nfs/super.c:1800
>  ? lock_downgrade+0x770/0x770 usr/src/kernel/kernel/locking/lockdep.c:4043
>  ? rwlock_bug.part.0+0x90/0x90 usr/src/kernel/include/linux/sched.h:1250
>  ? kasan_check_read+0x11/0x20 usr/src/kernel/mm/kasan/common.c:94
>  ? atomic_read usr/src/kernel/include/asm-generic/atomic-instrumented.h:26 
> [inline]
>  ? queued_spin_is_locked usr/src/kernel/include/asm-generic/qspinlock.h:26 
> [inline]
>  ? debug_spin_unlock usr/src/kernel/kernel/locking/spinlock_debug.c:98 
> [inline]
>  ? do_raw_spin_unlock+0x59/0x260 
> usr/src/kernel/kernel/locking/spinlock_debug.c:138
>  ? __raw_spin_unlock usr/src/kernel/include/linux/spinlock_api_smp.h:152 
> [inline]
>  ? _raw_spin_unlock+0x32/0x50 usr/src/kernel/kernel/locking/spinlock.c:183
>  ? find_nfs_version+0xe6/0x110 usr/src/kernel/include/linux/err.h:26
>  nfs_fs_mount+0xe83/0x2870 usr/src/kernel/fs/nfs/super.c:2750
>  ? nfs_remount+0x19e0/0x19e0 usr/src/kernel/include/net/ipv6.h:517
>  ? trace_kfree usr/src/kernel/include/trace/events/kmem.h:137 [inline]
>  ? kfree+0x194/0x2c0 usr/src/kernel/mm/slub.c:3983
>  ? nfs_clone_super+0x420/0x420 usr/src/kernel/fs/nfs/super.c:2421
>  ? nfs_parse_mount_options+0x2400/0x2400 usr/src/kernel/fs/nfs/super.c:1396
>  ? vfs_parse_fs_string+0x11b/0x170 usr/src/kernel/fs/fs_context.c:190
>  ? vfs_parse_fs_param+0x540/0x540 usr/src/kernel/fs/fs_context.c:163
>  ? nfs_remount+0x19e0/0x19e0 usr/src/kernel/include/net/ipv6.h:517
>  legacy_get_tree+0x10f/0x220 usr/src/kernel/fs/fs_context.c:659
>  ? legacy_parse_monolithic+0x124/0x180 usr/src/kernel/fs/fs_context.c:643
>  vfs_get_tree+0x98/0x3a0 usr/src/kernel/fs/super.c:1478
>  do_new_mount usr/src/kernel/fs/namespace.c:2801 [inline]
>  do_mount+0x1381/0x1c20 usr/src/kernel/fs/namespace.c:3121
>  ? copy_mount_string+0x40/0x40 usr/src/kernel/fs/namespace.c:3024
>  ? kasan_kmalloc+0x9/0x10 usr/src/kernel/mm/kasan/common.c:509
>  ? kmem_cache_alloc_trace+0x147/0x310 usr/src/kernel/mm/slub.c:2810
>  ? __sanitizer_cov_trace_const_cmp4+0x16/0x20 usr/src/kernel/kernel/kcov.c:189
>  ? memset usr/src/kernel/include/linux/string.h:369 [inline]
>  ? copy_mount_options+0x2d9/0x3d0 usr/src/kernel/fs/namespace.c:3017
>  ksys_mount+0xd8/0x130 usr/src/kernel/fs/namespace.c:3330
>  __do_sys_mount usr/src/kernel/fs/namespace.c:3344 [inline]
>  __se_sys_mount usr/src/kernel/fs/namespace.c:3341 [inline]
>  __x64_sys_mount+0xc3/0x150 usr/src/kernel/fs/namespace.c:3341
>  do_syscall_64+0xc7/0x600 usr/src/kernel/arch/x86/entry/common.c:295
>  entry_SYSCALL_64_after_hwframe+0x49/0xbe
> 
> It can be reproduced using the following simplified program:
>  #include 
>  #include 
> 
>  int main()
>  {
>mount(NULL, "./file0", "nfs", 0x400, "\x07\000\000\000");
> 
>return 0;
>  }
> 
> It was introduced by the follwing yocto-specific commit:
> commit ad818f6b28a610b53814d8b1d0da2fadfd83a3ad
> Author: Jason Wessel 
> Date:   Wed Jan 7 00:59:33 2009 -0500
> 
> NFS: allow nfs root mount to use alternate rpc ports
> 
> Allow an nfs root mount to use alternate RPC ports for mountd and nfsd.
> 
> Signed-off-by: Jason Wessel 
> [forward port to 2.6.33+]
> Signed-off-by: Bruce Ashfield 
> 
> Since hardknott, "NFS: allow nfs root mount to use alternate rpc ports" patch 
> is
> no longer applied by yocto-kernel-cache (a4283cc6be0c65 ("kver: update
> -dev to v5.6-rc5")) due to a merge conflict. Also, in later kernels (since 
> v5.6
> commit f2aedb713c284 ("NFS: Add fs_context support")), the nfs parser has been
> refactored to use generic fs_context, so it is not clear how easy would be to
> reproduce this issue.
> 
> The null pointer dereference takes place only when

Re: [linux-yocto] [yocto-kernel-cache]: bcm-2xxx-rpi: update kernel config for raspberrypi 4B platform

2021-06-30 Thread Bruce Ashfield 

In message: [yocto-kernel-cache]: bcm-2xxx-rpi: update kernel config for 
raspberrypi 4B platform
on 28/06/2021 meng...@windriver.com wrote:

> From: Limeng 
> 
> Hi Bruce,
> 
> Could you please help to merge this patch into yocto-kernel-cache, branch is 
> only master?

merged.

I also have official 5.13 branches (same kernel version as master).
If we bring the BSP to those branches, make sure to get me to cherry
pick the config patch as well.

Bruce

> 
> diffstat info ad below:
> 
>  bcm-2xxx-rpi.cfg |3 +++
>  1 file changed, 3 insertions(+)
> 
> 
> thanks,
> Limeng

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10020): 
https://lists.yoctoproject.org/g/linux-yocto/message/10020
Mute This Topic: https://lists.yoctoproject.org/mt/83840973/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][v5.10/standard/base][PATCH 1/1] iwlwifi: select MAC80211_LEDS conditionally

2021-06-30 Thread Bruce Ashfield 
merged to 5.10 (and the new 5.13 branches).

Bruce

In message: [linux-yocto][v5.10/standard/base][PATCH 1/1] iwlwifi: select 
MAC80211_LEDS conditionally
on 28/06/2021 Liwei Song wrote:

> MAC80211_LEDS depends on LEDS_CLASS=y or LEDS_CLASS=MAC80211,
> add condition to enable it in iwlwifi/Kconfig to avoid below
> compile warning when LEDS_CLASS was set to m:
> 
> WARNING: unmet direct dependencies detected for MAC80211_LEDS
>   Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] && (LEDS_CLASS 
> [=m]=y || LEDS_CLASS [=m]=MAC80211 [=y])
>   Selected by [m]:
>   - IWLWIFI_LEDS [=y] && NETDEVICES [=y] && WLAN [=y] && WLAN_VENDOR_INTEL 
> [=y] && IWLWIFI [=m] && (LEDS_CLASS [=m]=y || LEDS_CLASS [=m]=IWLWIFI [=m]) 
> && (IWLMVM [=m] || IWLDVM [=m])
> 
> Signed-off-by: Liwei Song 
> ---
>  drivers/net/wireless/intel/iwlwifi/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/intel/iwlwifi/Kconfig 
> b/drivers/net/wireless/intel/iwlwifi/Kconfig
> index 1085afbefba8..0e1de69c259f 100644
> --- a/drivers/net/wireless/intel/iwlwifi/Kconfig
> +++ b/drivers/net/wireless/intel/iwlwifi/Kconfig
> @@ -50,7 +50,7 @@ config IWLWIFI_LEDS
>   depends on LEDS_CLASS=y || LEDS_CLASS=IWLWIFI
>   depends on IWLMVM || IWLDVM
>   select LEDS_TRIGGERS
> - select MAC80211_LEDS
> + select MAC80211_LEDS if (LEDS_CLASS=y || LEDS_CLASS=MAC80211)
>   default y
>  
>  config IWLDVM
> -- 
> 2.17.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10019): 
https://lists.yoctoproject.org/g/linux-yocto/message/10019
Mute This Topic: https://lists.yoctoproject.org/mt/83840752/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.10][PATCH] eventfd: Enlarge recursion limit to allow vhost to work

2021-06-30 Thread Bruce Ashfield 

In message: [linux-yocto][linux-yocto v5.10][PATCH] eventfd: Enlarge recursion 
limit to allow vhost to work
on 28/06/2021 qiang.zh...@windriver.com wrote:

> From: Zqiang 
> 
> 1/1 [
> Author: He Zhe
> Email: zhe...@windriver.com
> Subject: eventfd: Enlarge recursion limit to allow vhost to work
> Date: Fri, 5 Jun 2020 16:32:18 +0800
> 
> commit 85f0a97f3aac6bb2c9549af607843644dd2ef5c7 upstream [linux-yocto]
> 
> Upstream link: 
> https://lore.kernel.org/lkml/20200410114720.24838-1-zhe...@windriver.com/

I was reading the thread on lore, and it isn't clear to me what is
the latest status.

Does this problem show more easily under preempt-rt, but is not a
preempt-rt only fix ? I'm just trying to confirm that you are
targeting this at v5.10/standard/base.

You first submitted this a year ago, and it still isn't applied
upstream. And Juri was seeing the same warning. There was a
recent series posted that had a similar change to your v1, but
you've resent this patch (v2?) as part of that effort .. but still
no answer on the change.

Also note, I just pushed 5.13 as the start of the new release
kernel, since this is in mainline still, I assume I can apply this
to those branches as well.

Bruce

> 
> commit b5e683d5cab8 ("eventfd: track eventfd_signal() recursion depth")
> introduces a percpu counter that tracks the percpu recursion depth and
> warn if it greater than zero, to avoid potential deadlock and stack
> overflow.
> 
> However sometimes different eventfds may be used in parallel. Specifically,
> when heavy network load goes through kvm and vhost, working as below, it
> would trigger the following call trace.
> 
> -  100.00%
>- 66.51%
> ret_from_fork
> kthread
>   - vhost_worker
>  - 33.47% handle_tx_kick
>   handle_tx
>   handle_tx_copy
>   vhost_tx_batch.isra.0
>   vhost_add_used_and_signal_n
>   eventfd_signal
>  - 33.05% handle_rx_net
>   handle_rx
>   vhost_add_used_and_signal_n
>   eventfd_signal
>- 33.49%
> ioctl
> entry_SYSCALL_64_after_hwframe
> do_syscall_64
> __x64_sys_ioctl
> ksys_ioctl
> do_vfs_ioctl
> kvm_vcpu_ioctl
> kvm_arch_vcpu_ioctl_run
> vmx_handle_exit
> handle_ept_misconfig
> kvm_io_bus_write
> __kvm_io_bus_write
> eventfd_signal
> 001: WARNING: CPU: 1 PID: 1503 at fs/eventfd.c:73 eventfd_signal+0x85/0xa0
>  snip 
> 001: Call Trace:
> 001:  vhost_signal+0x15e/0x1b0 [vhost]
> 001:  vhost_add_used_and_signal_n+0x2b/0x40 [vhost]
> 001:  handle_rx+0xb9/0x900 [vhost_net]
> 001:  handle_rx_net+0x15/0x20 [vhost_net]
> 001:  vhost_worker+0xbe/0x120 [vhost]
> 001:  kthread+0x106/0x140
> 001:  ? log_used.part.0+0x20/0x20 [vhost]
> 001:  ? kthread_park+0x90/0x90
> 001:  ret_from_fork+0x35/0x40
> 001: ---[ end trace 0003 ]---
> 
> This patch enlarges the limit to 1 which is the maximum recursion depth we
> have found so far.
> 
> Signed-off-by: He Zhe 
> Signed-off-by: Bruce Ashfield 
> [CE: backport of 85f0a97f3aac from v5.4 branch of linux-yocto]
> Signed-off-by: Catalin Enache 
> ]
> 
> Signed-off-by: Zqiang 
> ---
>  fs/eventfd.c| 2 +-
>  include/linux/eventfd.h | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/eventfd.c b/fs/eventfd.c
> index df466ef81ddd..7a5cbec9e843 100644
> --- a/fs/eventfd.c
> +++ b/fs/eventfd.c
> @@ -71,7 +71,7 @@ __u64 eventfd_signal(struct eventfd_ctx *ctx, __u64 n)
>* it returns true, the eventfd_signal() call should be deferred to a
>* safe context.
>*/
> - if (WARN_ON_ONCE(this_cpu_read(eventfd_wake_count)))
> + if (WARN_ON_ONCE(this_cpu_read(eventfd_wake_count) > 
> EFD_WAKE_COUNT_MAX))
>   return 0;
>  
>   spin_lock_irqsave(>wqh.lock, flags);
> diff --git a/include/linux/eventfd.h b/include/linux/eventfd.h
> index dc4fd8a6644d..db050fb99e0b 100644
> --- a/include/linux/eventfd.h
> +++ b/include/linux/eventfd.h
> @@ -29,6 +29,8 @@
>  #define EFD_SHARED_FCNTL_FLAGS (O_CLOEXEC | O_NONBLOCK)
>  #define EFD_FLAGS_SET (EFD_SHARED_FCNTL_FLAGS | EFD_SEMAPHORE)
>  
> +/* This is the maximum recursion depth we find so far */
> +#define EFD_WAKE_COUNT_MAX  1
>  struct eventfd_ctx;
>  struct file;
>  
> -- 
> 2.29.2
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10018): 
https://lists.yoctoproject.org/g/linux-yocto/message/10018
Mute This Topic: https://lists.yoctoproject.org/mt/83840069/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [linux-yocto][linux-yocto v5.10/standard/sdkv5.4/xlnx-soc] usb: dwc3: debugfs: delete redandunt dwc3_debugfs_create_endpoint_dirs

2021-06-30 Thread Bruce Ashfield 
merged.

Bruce

In message: [linux-yocto][linux-yocto v5.10/standard/sdkv5.4/xlnx-soc] usb: 
dwc3: debugfs: delete redandunt dwc3_debugfs_create_endpoint_dirs
on 28/06/2021 quanyang.w...@windriver.com wrote:

> From: Quanyang Wang 
> 
> Since mainline commit 8d396bb0a5b6 ("usb: dwc3: debugfs: Add and remove
> endpoint dirs dynamically") drops dwc3_debugfs_create_endpoint_dirs(),
> let's delete it in dwc3_debugfs_init either.
> 
> Signed-off-by: Quanyang Wang 
> ---
>  drivers/usb/dwc3/debugfs.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/usb/dwc3/debugfs.c b/drivers/usb/dwc3/debugfs.c
> index e9f9494368862..5d1b4fa1e98b8 100644
> --- a/drivers/usb/dwc3/debugfs.c
> +++ b/drivers/usb/dwc3/debugfs.c
> @@ -983,8 +983,6 @@ void dwc3_debugfs_init(struct dwc3 *dwc)
>   _link_state_fops);
>   debugfs_create_file("hiber_enable", S_IRUGO | S_IWUSR, root,
>   dwc, _hiber_enable_fops);
> -
> - dwc3_debugfs_create_endpoint_dirs(dwc, root);
>   }
>  }
>  
> -- 
> 2.25.1
> 

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10017): 
https://lists.yoctoproject.org/g/linux-yocto/message/10017
Mute This Topic: https://lists.yoctoproject.org/mt/83838758/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto-announce] [ANNOUNCEMENT] Yocto Project 3.1.9 (dunfell-23.0.9) is Released

2021-06-30 Thread Vineela 
Hello,

We are pleased to announce the Yocto Project 3.1.9 (dunfell-23.0.9) Release is 
now available for download.

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/RELEASENOTES

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/testreport.txt

Thank you for everyone's contributions to this release.


Vineela Tummalapalli

Yocto Project Build and Release

vineela.tummalapa...@intel.com

- --
yocto-3.1.9 Release Notes
- --

- --
Repositories/Downloads
- --

Repository Name: poky
Repository Location: https://git.yoctoproject.org/git/poky
Branch: dunfell
Tag: yocto-3.1.9
Git Revision: 43060f59ba60a0257864f1f7b25b51fac3f2d2cf
Release Artefact: poky-dunfell-23.0.9
sha: d2a7acbaca384408594b72f25883f10b454215af97e31914e8a11035a0334424
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

Repository Name: openembedded-core
Repository Location: https://git.openembedded.org/openembedded-core
Branch: dunfell
Tag: 2020-04.9-dunfell
Git Revision: ac8181d9b9ad8360f7dba03aba8b00f008c6ebb4
Release Artefact: oecore-dunfell-23.0.9
sha: d4fc5e5333bc6b2dee464d1845554920e3d504ab16a47e6d335d5c8a185e0dcd
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/oecore-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/oecore-dunfell-23.0.9.tar.bz2

Repository Name: meta-mingw
Repository Location: https://git.yoctoproject.org/git/meta-mingw
Branch: dunfell
Tag: yocto-3.1.9
Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7
Release Artefact: meta-mingw-dunfell-23.0.9
sha: e5f8e6777003d329fe7ff9e69c9e9f46edf5a272198a194cbc79b866c7b9dab6
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/meta-mingw-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/meta-mingw-dunfell-23.0.9.tar.bz2

Repository Name: meta-gplv2
Repository Location: https://git.yoctoproject.org/git/meta-gplv2
Branch: dunfell
Tag: yocto-3.1.9
Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
Release Artefact: meta-gplv2-dunfell-23.0.9
sha: 39bffee0bc5a93e224073036e6a544d83c40f5bccc4c8faeb3995cef323969e1
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/meta-gplv2-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/meta-gplv2-dunfell-23.0.9.tar.bz2

Repository Name: bitbake
Repository Location: https://git.openembedded.org/bitbake
Branch: 1.46
Tag: 2020-04.9-dunfell
Git Revision: 0e0af15b84e07e6763300dcd092b980086b9b9c4
Release Artefact: bitbake-dunfell-23.0.9
sha: 9a3da4317d9e43ef9b0e66ed0d8070d373fc41fa34648e2a6b04c591d12b97d0
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/bitbake-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/bitbake-dunfell-23.0.9.tar.bz2

Repository Name: yocto-docs
Repository Location: https://git.yoctoproject.org/git/yocto-docs
Branch: dunfell
Tag: yocto-3.1.9
Git Revision:0fadb292429b4147408798ed4c806ba6d9dd81b8

- -
Contributors
- -
akash hadke
Andrea Adami
Bruce Ashfield
Changqing Li
Daniel McGregor
Guillaume Champagne
Jain Sangeeta
Kai Kang
Klaus Heinrich Kiwi
Lee Chee Yang
Michael Halstead
Ming Liu
Ovidiu Panait
Richard Purdie
Ross Burton
Sana Kazi
Stephen Jolley
Steve Sakoman
Tony Tascioglu
Vineela Tummalapalli
Volker Vogelhuber
Yi Zhao

- ---
Known Issues
- ---
N/A


- ---
Security Fixes
- ---
Revert "python3: fix CVE-2021-23336"
python3: fix CVE-2021-23336
gstreamer-plugins-good: fix CVE-2021-3497 CVE-2021-3498
gnutls: fix CVE-2021-20231 CVE-2021-20232
libxml: fix CVE-2021-3517 CVE-2021-3537
grub: Exclude CVE-2019-14865 from cve-check
cve-extra-exclusions.inc: add exclusion list for intractable CVE's
expat: set CVE_PRODUCT
openssh: Add fixes for CVEs reported for openssh
tiff: Add fix for CVE-2020-35521 and CVE-2020-35522
cups: whitelist CVE-2021-25317


- ---
Fixes
- ---
bitbake: cooker: Avoid parser deadlocks
bitbake: cooker: Ensure parser is cleaned up
bitbake: cooker: Explictly shut down the sync thread
bitbake: cooker: Ensure parse_quit thread is closed down
kernel.bbclass: fix do_sizecheck() comparison
valgrind: fix a typo
ruby: 2.7.1 -> 2.7.3
bind: 9.11.22 -> 9.11.32
poky.conf: Bump version for 3.1.9 release
poky.conf: Add openSUSE Leap 15.2 as a supported distro
documentation: prepare for 3.1.9 release
ref-system-requirements.rst: Add openSUSE Leap 15.2 to list of supported distros

[yocto] [ANNOUNCEMENT] Yocto Project 3.1.9 (dunfell-23.0.9) is Released

2021-06-30 Thread Vineela 
Hello,

We are pleased to announce the Yocto Project 3.1.9 (dunfell-23.0.9) Release is 
now available for download.

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

A gpg signed version of these release notes is available at:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/RELEASENOTES

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/testreport.txt

Thank you for everyone's contributions to this release.


Vineela Tummalapalli

Yocto Project Build and Release

vineela.tummalapa...@intel.com

- --
yocto-3.1.9 Release Notes
- --

- --
Repositories/Downloads
- --

Repository Name: poky
Repository Location: https://git.yoctoproject.org/git/poky
Branch: dunfell
Tag: yocto-3.1.9
Git Revision: 43060f59ba60a0257864f1f7b25b51fac3f2d2cf
Release Artefact: poky-dunfell-23.0.9
sha: d2a7acbaca384408594b72f25883f10b454215af97e31914e8a11035a0334424
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

Repository Name: openembedded-core
Repository Location: https://git.openembedded.org/openembedded-core
Branch: dunfell
Tag: 2020-04.9-dunfell
Git Revision: ac8181d9b9ad8360f7dba03aba8b00f008c6ebb4
Release Artefact: oecore-dunfell-23.0.9
sha: d4fc5e5333bc6b2dee464d1845554920e3d504ab16a47e6d335d5c8a185e0dcd
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/oecore-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/oecore-dunfell-23.0.9.tar.bz2

Repository Name: meta-mingw
Repository Location: https://git.yoctoproject.org/git/meta-mingw
Branch: dunfell
Tag: yocto-3.1.9
Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7
Release Artefact: meta-mingw-dunfell-23.0.9
sha: e5f8e6777003d329fe7ff9e69c9e9f46edf5a272198a194cbc79b866c7b9dab6
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/meta-mingw-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/meta-mingw-dunfell-23.0.9.tar.bz2

Repository Name: meta-gplv2
Repository Location: https://git.yoctoproject.org/git/meta-gplv2
Branch: dunfell
Tag: yocto-3.1.9
Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
Release Artefact: meta-gplv2-dunfell-23.0.9
sha: 39bffee0bc5a93e224073036e6a544d83c40f5bccc4c8faeb3995cef323969e1
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/meta-gplv2-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/meta-gplv2-dunfell-23.0.9.tar.bz2

Repository Name: bitbake
Repository Location: https://git.openembedded.org/bitbake
Branch: 1.46
Tag: 2020-04.9-dunfell
Git Revision: 0e0af15b84e07e6763300dcd092b980086b9b9c4
Release Artefact: bitbake-dunfell-23.0.9
sha: 9a3da4317d9e43ef9b0e66ed0d8070d373fc41fa34648e2a6b04c591d12b97d0
Download Locations:
http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/bitbake-dunfell-23.0.9.tar.bz2
http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/bitbake-dunfell-23.0.9.tar.bz2

Repository Name: yocto-docs
Repository Location: https://git.yoctoproject.org/git/yocto-docs
Branch: dunfell
Tag: yocto-3.1.9
Git Revision:0fadb292429b4147408798ed4c806ba6d9dd81b8

- -
Contributors
- -
akash hadke
Andrea Adami
Bruce Ashfield
Changqing Li
Daniel McGregor
Guillaume Champagne
Jain Sangeeta
Kai Kang
Klaus Heinrich Kiwi
Lee Chee Yang
Michael Halstead
Ming Liu
Ovidiu Panait
Richard Purdie
Ross Burton
Sana Kazi
Stephen Jolley
Steve Sakoman
Tony Tascioglu
Vineela Tummalapalli
Volker Vogelhuber
Yi Zhao

- ---
Known Issues
- ---
N/A


- ---
Security Fixes
- ---
Revert "python3: fix CVE-2021-23336"
python3: fix CVE-2021-23336
gstreamer-plugins-good: fix CVE-2021-3497 CVE-2021-3498
gnutls: fix CVE-2021-20231 CVE-2021-20232
libxml: fix CVE-2021-3517 CVE-2021-3537
grub: Exclude CVE-2019-14865 from cve-check
cve-extra-exclusions.inc: add exclusion list for intractable CVE's
expat: set CVE_PRODUCT
openssh: Add fixes for CVEs reported for openssh
tiff: Add fix for CVE-2020-35521 and CVE-2020-35522
cups: whitelist CVE-2021-25317


- ---
Fixes
- ---
bitbake: cooker: Avoid parser deadlocks
bitbake: cooker: Ensure parser is cleaned up
bitbake: cooker: Explictly shut down the sync thread
bitbake: cooker: Ensure parse_quit thread is closed down
kernel.bbclass: fix do_sizecheck() comparison
valgrind: fix a typo
ruby: 2.7.1 -> 2.7.3
bind: 9.11.22 -> 9.11.32
poky.conf: Bump version for 3.1.9 release
poky.conf: Add openSUSE Leap 15.2 as a supported distro
documentation: prepare for 3.1.9 release
ref-system-requirements.rst: Add openSUSE Leap 15.2 to list of supported distros

Re: [yocto] Would COMPATIBLE_IMAGE make sense?

2021-06-30 Thread Jonas Vautherin 
Thanks a lot for the answers, that's really helpful!

Seems like I should have a closer look at the distros.
I'll need some time to test it, I'll update here when that is done!

On Tue, Jun 29, 2021 at 1:52 PM Bruce Ashfield 
wrote:

> On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr
>  wrote:
> >
> > Howdy!
> >
> > Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:
> > > I was thinking about my issue described here [1], and discovered the
> > > variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
> > > use to stop recipes from being built for machines (/hosts) with which
> > > the recipes are not compatible". And so I wondered if it would make
> > > sense to add COMPATIBLE_IMAGE, for a similar purpose.
> > >
> > > Let me explain my issue: I define different images in different layers
> > > (say `first-project-image` and `second-project-image`), and in each of
> > > those layers I create `.bbappends` to configure some packages.
> Typically
> > > `hostapd` is used by both images, but with a different config file.
> > >
> > > The thing is that when I run `bitbake first-project-image`, because
> > > `second-project-image` is part of my bblayers.conf, then the
> > > hostapd_%.bbappend from `second-project-image` is used and may have an
> > > impact on `first-project-image`, which I don't want. I really want this
> > > bbappend to only affect the image `second-project-image`.
> > >
> > > One way I can see to deal with that is to realize that
> > > `first-project-image` and `second-project-image` are two different
> > > projects, and build them from two different BUILDDIRs. The thing I
> don't
> > > like here is that all the packages are therefore downloaded and built
> > > twice, which seems like a loss of time and space.
> > >
> > > That's where I thought about COMPATIBLE_IMAGE. In the
> hostapd_%.bbappend
> > > of `first-project-image`, I would set "COMPATIBLE_IMAGE =
> > > 'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
> > > 'second-project-image'". So that I could still share a BUILDDIR between
> > > different projects.
> >
> > Yocto chant #1 applies: "Recipe data is local, configuration data is
> > global." Means: the recipe does not see at all which image it is being
> > built for. So it also can't react to it - you can't check a variable
> > against something you do not even see.
> >
> > > How bad of an idea is that?
> >
> > It just doesn't work. If that counts as "bad" is left for you to decide
> :)
> >
> > What you actually might use is using different DISTROs for the images,
> > because that actually what they mean to do: you change the ABI/API of
> > the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
> > derivatives, so its all there already. It just cannot be triggered from
> > the image, because, well.. see first pragraph of the answer.
>
> I was also going to suggest distros.
>
> And also, if the concern really is about builds reusing downloads,
> etc, then by all means configure those different distro builds to
> share download and sstate directories.
>
> Bruce
>
> >
> > Greetz
> >
> > > Thanks in advance,
> > > Jonas
> > >
> > > [1]:
> https://stackoverflow.com/questions/68167244/image-specific-layers
> > > 
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54027): https://lists.yoctoproject.org/g/yocto/message/54027
Mute This Topic: https://lists.yoctoproject.org/mt/83858212/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 3/3] wic/wks cleanup

2021-06-30 Thread Trevor Woerner 
On Mon 2021-06-28 @ 11:15:41 AM, Trevor Woerner wrote:
> By exporting a couple more variables the wks file for every rockchip device
> can be built from one template instead of having separate wks files for each
> board and platform.
> 
> The following BSP variables were checked before and after this change to make
> sure they remained valid/sensible:
> - WKS_FILE
> - UBOOT_SUFFIX
> - SPL_BINARY
> - IMAGE_FSTYPES
> 
> Built-tested for every MACHINE in this BSP.
> 
> Run-tested on the following devices to ensure they continue to boot correctly
> to a cmdline (core-image-base):
> - tinker-board
> - rock-pi-e
> - rock-pi-4b
> - rock64
> - nanopi-m4-2gb
> 
> Signed-off-by: Trevor Woerner 
> ---
>  conf/machine/firefly-rk3288.conf  |  2 --
>  conf/machine/include/nanopi-m4.inc|  1 -
>  conf/machine/include/rk3288.inc   |  3 +--
>  conf/machine/include/rk3328.inc   |  1 -
>  conf/machine/include/rk3399.inc   |  2 --
>  conf/machine/include/rock-pi-4.inc|  1 -
>  conf/machine/include/rockchip-wic.inc |  5 +
>  conf/machine/include/tinker.inc   |  2 --
>  conf/machine/rock-pi-e.conf   |  2 --
>  conf/machine/rock64.conf  |  2 --
>  conf/machine/vyasa-rk3288.conf|  1 -
>  wic/firefly-rk3288.wks|  7 ---
>  wic/rk3288-boot.wks   | 24 
>  wic/rk3399-boot.wks   | 24 
>  wic/rock-pi-4.wks |  7 ---
>  wic/rock-pi-e.wks |  4 
>  wic/{rk3328-boot.wks => rockchip.wks} |  9 ++---
>  wic/tinker-board.wks  |  8 
>  wic/vyasa-rk3288.wks  |  8 
>  19 files changed, 12 insertions(+), 101 deletions(-)
>  delete mode 100644 wic/firefly-rk3288.wks
>  delete mode 100644 wic/rk3288-boot.wks
>  delete mode 100644 wic/rk3399-boot.wks
>  delete mode 100644 wic/rock-pi-4.wks
>  delete mode 100644 wic/rock-pi-e.wks
>  rename wic/{rk3328-boot.wks => rockchip.wks} (64%)
>  delete mode 100644 wic/tinker-board.wks
>  delete mode 100644 wic/vyasa-rk3288.wks
> 
> diff --git a/conf/machine/firefly-rk3288.conf 
> b/conf/machine/firefly-rk3288.conf
> index 138e840..3270bb9 100644

Applied to meta-rockchip master.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54026): https://lists.yoctoproject.org/g/yocto/message/54026
Mute This Topic: https://lists.yoctoproject.org/mt/83847095/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 2/3] IMAGE_FSTYPES: remove ext4

2021-06-30 Thread Trevor Woerner 
On Mon 2021-06-28 @ 11:15:40 AM, Trevor Woerner wrote:
> The ext4 IMAGE_FSTYPES does not need to be mentioned explicitly. It will be
> automatically generated in cases where it is needed.
> 
> Signed-off-by: Trevor Woerner 
> ---
>  conf/machine/include/rockchip-defaults.inc | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/conf/machine/include/rockchip-defaults.inc 
> b/conf/machine/include/rockchip-defaults.inc
> index b41c523..0666119 100644

Applied to meta-rockchip master.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54025): https://lists.yoctoproject.org/g/yocto/message/54025
Mute This Topic: https://lists.yoctoproject.org/mt/83847094/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-rockchip][PATCH 1/3] conf/machine/include/nanopi-m4.inc: add full include path

2021-06-30 Thread Trevor Woerner 
On Mon 2021-06-28 @ 11:15:39 AM, Trevor Woerner wrote:
> Specify the full include path to the rk3399.inc file.
> 
> Signed-off-by: Trevor Woerner 
> ---
>  conf/machine/include/nanopi-m4.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/conf/machine/include/nanopi-m4.inc 
> b/conf/machine/include/nanopi-m4.inc
> index 7ca91db..b5251a1 100644

Applied to meta-rockchip master.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54024): https://lists.yoctoproject.org/g/yocto/message/54024
Mute This Topic: https://lists.yoctoproject.org/mt/83847093/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Python2 in Gatesgarth

2021-06-30 Thread Marek Belisko 
Hi Aashik,

On Wed, Jun 30, 2021 at 4:25 PM Aashik Aswin  wrote:
>
> Hello Developers,
>
> We are migrating our platforms from Zeus to Gatesgarth, We could see that the 
> native Python2 bb file and core modules have been removed.
>
>  As much of our platform code is in Python2, I was wondering if there is some 
> way we can re-enable python2 support in our yocto environment to compile/run 
> python2 scripts ?
You can use meta-python2 [0] layer
>
> Thanks in Advance,
>
> Thanks & Regards
> Aashik
>
> 
>

[0] - https://git.openembedded.org/meta-python2

marek

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54023): https://lists.yoctoproject.org/g/yocto/message/54023
Mute This Topic: https://lists.yoctoproject.org/mt/83893547/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Python2 in Gatesgarth

2021-06-30 Thread Aashik Aswin 
Hello Developers,

We are migrating our platforms from Zeus to Gatesgarth, We could see that
the native Python2 bb file and core modules have been removed.

 As much of our platform code is in Python2, I was wondering if there is
some way we can re-enable python2 support in our yocto environment to
compile/run python2 scripts ?

Thanks in Advance,

Thanks & Regards
Aashik

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54022): https://lists.yoctoproject.org/g/yocto/message/54022
Mute This Topic: https://lists.yoctoproject.org/mt/83893547/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] #yocto #zeus

2021-06-30 Thread Monsees, Steven C (US) via lists.yoctoproject.org 

I am running with zeus 3.0.4 and appear to have an issue with the mount command 
supporting NFS... ?

Can someone explain the following and how I can get "mount" to support NFS ?

Trying to mount the UDM from the AIO
mount.nfs: Operation not permitted
Failed to mount the UDM from the AIO!
Trying tNFS: bad mount option value specified: minorversion=1

Thanks,
Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54021): https://lists.yoctoproject.org/g/yocto/message/54021
Mute This Topic: https://lists.yoctoproject.org/mt/83893426/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #zeus:https://lists.yoctoproject.org/g/yocto/mutehashtag/zeus
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Question regarding custom device tree update

2021-06-30 Thread Sohil Shah 
Hello,

I am kinda a noob at this so please bear with me.

I am using the sama5d27-wlsom1-ek board for my demo and I am trying to make
changes to the device tree.

So far I have compiled core-image-minimal and find my dtb files are
generated in
/tmp/work/sama5d27_wlsom1_ek_sd-poky-linux-gnueabi/linux-at91/5.4+gitAUTOINC+3dba8c9991-r0/build/arch/arm/boot/dts
folder.

Also I find many different dts files in
build/tmp/work-shared/sama5d27-wlsom1-ek-sd/kernel-source/arch/arm/boot/dts

But where does my machine get device tree files if they are generated
inside the build folder and if so where do I place my custom files so that
they get called during bitbake.

I want to build the image using my custom dts file where I enable certain
peripherals and disable the ones not required. (A test to update dtb's in
future).

I tried different methods found here
https://stackoverflow.com/questions/38917745/quick-rebuild-of-device-tree-only-with-yocto-bitbake

But, I seem to run into some errors when I try to build the image.

Please help and let me know if I missed any required information from my
side.

Thank you and Regards,
Sohil

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54020): https://lists.yoctoproject.org/g/yocto/message/54020
Mute This Topic: https://lists.yoctoproject.org/mt/83892570/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [poky][PATCH] devtool: deploy-target: Fix preserving attributes when using --strip

2021-06-30 Thread Florian Amstutz 
Commit a2db4fa127a3347fc6df31f895fb0b552669119e added ${WORKDIR}/deploy-* to
PSEUDO_IGNORE_PATHS. This breaks the --strip mode since ${D} is copied to
deploy-target-stripped. Use the directory devtool-deploy-target-stripped
instead.

[YOCTO #14451]

Signed-off-by: Florian Amstutz 
---
scripts/lib/devtool/deploy.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index e5af2c95ae..833322571f 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -168,7 +168,7 @@ def deploy(args, config, basepath, workspace):
if args.strip and not args.dry_run:
# Fakeroot copy to new destination
srcdir = recipe_outdir
-            recipe_outdir = os.path.join(rd.getVar('WORKDIR'), 
'deploy-target-stripped')
+            recipe_outdir = os.path.join(rd.getVar('WORKDIR'), 
'devtool-deploy-target-stripped')
if os.path.isdir(recipe_outdir):
bb.utils.remove(recipe_outdir, True)
exec_fakeroot(rd, "cp -af %s %s" % (os.path.join(srcdir, '.'), recipe_outdir), 
shell=True)
--
2.17.1

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54019): https://lists.yoctoproject.org/g/yocto/message/54019
Mute This Topic: https://lists.yoctoproject.org/mt/83890410/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Yocto] Launching script at the very end of the image process

2021-06-30 Thread Richard Purdie 
On Wed, 2021-06-30 at 10:41 +, Cardaillac, Yann wrote:
> Hi Richard,
> 
> Many thanks for the fast answer.
> 
> > > I’m switching from buildroot to yocto and trying to figure out how to 
> > > do the equivalent of a POST_BUILD_SCRIPT.
> > > 
> > > Indeed I want to format the images built in a specific format for latter 
> > > use and CI needs.
> > 
> > In OE, the equivalent for that is probably the image types code.
> > See 
> > http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass
> > 
> > You can define your own custom image types to extend the system. Some of 
> > our defaults are quite simple (tar), some are quite complex (wic has its 
> > own bbclass).
> 
> I said image, but it was probably not the best word, I just want to make a 
> tarball 
> of the generated image + adding some file in it.
> 
> Here's the complete file with the job :
> 
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> 
> SRC_URI += "file://nallino-custom-params.txt"
> SRC_URI += "file://configuration_instruction_to_do_on_GUF.txt"
> 
> do_release_ycn() {
> 
> rm -rf ${DEPLOY_DIR_IMAGE}/ycn_release
> mkdir -p ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
> cp ${DEPLOY_DIR_IMAGE}/fng-install.sh ${DEPLOY_DIR_IMAGE}/ycn_release
> cp ${DEPLOY_DIR_IMAGE}/ycn-image-imx6ullguf.tar.gz 
> ${DEPLOY_DIR_IMAGE}/ycn_release/guf-image-imx6ullguf.tar.gz
> cp ${DEPLOY_DIR_IMAGE}/*.dtbo ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
> cp ${WORKDIR}/nallino-custom-params.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
> cp ${WORKDIR}/configuration_instruction_to_do_on_GUF.txt 
> ${DEPLOY_DIR_IMAGE}/ycn_release/
> tar -czf ${DEPLOY_DIR_IMAGE}/ycn_release.tar.gz 
> ${DEPLOY_DIR_IMAGE}/ycn_release
> 
> }
> addtask release_ycn after do_image_complete after do_deploy_kernelmodules
> 

You're used to poking around things in buildroot, OE doesn't quite like you
doing that so much :)

You shouldn't really be poking around DEPLOY_DIR without letting the build
system know what you're doing. Intermediate files like the intermediate 
directory
you're using to create the tarball above should really be in WORKDIR.
That is itself won't break, it just not good practise. Ideally you'd write
a separate recipe to do this final piece with a do_deploy task, using the
deploy bbclass which would them take care of removing obsolete versions 
when you rebuild and so on.

> > > I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success 
> > > since it wasn’t running at the proper moment.
> 
> > When is "the right moment"? :)
> 
> The right moment, is at the very end of bitbake, indeed I want the job 
> to be the overall last job!

You're not really helping us help you find a solution since you've not described
what you'd expect to be happening that isn't happening. How is what you have
failing?

I'm going to take a leap and guess that some of the files you expect there
aren't? Maybe the dtbo files from some other do_deploy tasks? If that is true
you're missing dependencies for your task. You can do things like:

do_release_ycn[depends] += "virtual/kernel:do_deploy"

I'd caution against "last" as it is a fine concept until two things want to 
be "last". It is usually better to describe the dependencies properly.

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54018): https://lists.yoctoproject.org/g/yocto/message/54018
Mute This Topic: https://lists.yoctoproject.org/mt/83888533/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Yocto] Launching script at the very end of the image process

2021-06-30 Thread Cardaillac, Yann 
Hi Richard,

Many thanks for the fast answer.

> > I’m switching from buildroot to yocto and trying to figure out how to 
> > do the equivalent of a POST_BUILD_SCRIPT.
> >
> > Indeed I want to format the images built in a specific format for latter 
> > use and CI needs.
>
> In OE, the equivalent for that is probably the image types code.
> See 
> http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass
>
> You can define your own custom image types to extend the system. Some of our 
> defaults are quite simple (tar), some are quite complex (wic has its own 
> bbclass).

I said image, but it was probably not the best word, I just want to make a 
tarball of the generated image + adding some file in it.

Here's the complete file with the job :

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "file://nallino-custom-params.txt"
SRC_URI += "file://configuration_instruction_to_do_on_GUF.txt"

do_release_ycn() {

rm -rf ${DEPLOY_DIR_IMAGE}/ycn_release
mkdir -p ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
cp ${DEPLOY_DIR_IMAGE}/fng-install.sh ${DEPLOY_DIR_IMAGE}/ycn_release
cp ${DEPLOY_DIR_IMAGE}/ycn-image-imx6ullguf.tar.gz 
${DEPLOY_DIR_IMAGE}/ycn_release/guf-image-imx6ullguf.tar.gz
cp ${DEPLOY_DIR_IMAGE}/*.dtbo ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
cp ${WORKDIR}/nallino-custom-params.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
cp ${WORKDIR}/configuration_instruction_to_do_on_GUF.txt 
${DEPLOY_DIR_IMAGE}/ycn_release/
tar -czf ${DEPLOY_DIR_IMAGE}/ycn_release.tar.gz 
${DEPLOY_DIR_IMAGE}/ycn_release

}
addtask release_ycn after do_image_complete after do_deploy_kernelmodules

>
> > I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success 
> > since it wasn’t running at the proper moment.

> When is "the right moment"? :)

The right moment, is at the very end of bitbake, indeed I want the job to be 
the overall last job!

Thanks again, 

Yann

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54017): https://lists.yoctoproject.org/g/yocto/message/54017
Mute This Topic: https://lists.yoctoproject.org/mt/83888533/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [Yocto] Launching script at the very end of the image process

2021-06-30 Thread Richard Purdie 
On Wed, 2021-06-30 at 09:33 +, Cardaillac, Yann wrote:
> I’m switching from buildroot to yocto and trying to figure out how to do the 
> equivalent of a
> POST_BUILD_SCRIPT.
>  
> Indeed I want to format the images built in a specific format for latter use 
> and CI needs.

In OE, the equivalent for that is probably the image types code.
See 
http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass

You can define your own custom image types to extend the system. Some of our 
defaults
are quite simple (tar), some are quite complex (wic has its own bbclass).

> I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success since 
> it 
> wasn’t running at the proper moment.

When is "the right moment"? :)

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54016): https://lists.yoctoproject.org/g/yocto/message/54016
Mute This Topic: https://lists.yoctoproject.org/mt/83888533/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] man package issue

2021-06-30 Thread sateesh m 
Hi Guys,

I am building core-image-sato image. i am facing issue rootfs creation. can 
anybody know give suggition how we can solve this issue.

ERROR: core-image-sato-1.0-r0 do_rootfs: Postinstall scriptlets of 
['man-pages'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.

--
Thanks & Regards,
Sateesh

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54015): https://lists.yoctoproject.org/g/yocto/message/54015
Mute This Topic: https://lists.yoctoproject.org/mt/83889069/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] [meta-mingw] [PATCH] libidn2: package all files

2021-06-30 Thread Samuli Piippo 
Include .def files to the -dev package to fix QA Issue: nativesdk-libidn2:
Files/directories were installed but not shipped in any package.

Signed-off-by: Samuli Piippo 
---
 recipes-extended/libidn/libidn2_%.bbappend | 1 +
 1 file changed, 1 insertion(+)
 create mode 100644 recipes-extended/libidn/libidn2_%.bbappend

diff --git a/recipes-extended/libidn/libidn2_%.bbappend 
b/recipes-extended/libidn/libidn2_%.bbappend
new file mode 100644
index 000..275886d
--- /dev/null
+++ b/recipes-extended/libidn/libidn2_%.bbappend
@@ -0,0 +1 @@
+FILES_${PN}-dev_append_mingw32 = " ${libdir}/*.def"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54014): https://lists.yoctoproject.org/g/yocto/message/54014
Mute This Topic: https://lists.yoctoproject.org/mt/83889055/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[linux-yocto][linux-yocto v5.10] kernel code for marvell cn96xx and marvell cn106xx

2021-06-30 Thread Ruiqiang Hao 
Hi Bruce,

Please help to create branch and merge code into our linux-yocto repo.

repo:
linux-yocto
branch:
v5.10/standard/cn-sdkv5.4/octeon

Thanks,
Ruiqiang

The following changes since commit 139fe7d68413054f850e206ab749f97a968867a8:

  rcu: Fix stall-warning deadlock due to non-release of rcu_node ->lock 
(2021-06-25 20:05:02 -0400)

are available in the Git repository at:

  https://github.com/cythe/linux.git v5.10/standard/cn-sdkv5.4/octeon.v3

for you to fetch changes up to 3db5ffbecee7b769aa762a1a9cd82aee7cc18fe0:

  spi: spi-octeontx2: fix erase sector error by limit spi buswidth (2021-06-30 
15:37:11 +0800)


Aaron Williams (4):
  mmc: octeontx2: Add tuning support for HS400 mode
  mmc: octeontx2: Use flags for hardware differences
  mmc: octeontx2: fix handling calibration glitch
  Marvell: CN10K: Display version information for flash components

Aleksey Makarov (1):
  octeontx2-pf: Add support for PTP clock

Alex Belits (2):
  kernel/exit.c: Add task cleanup callbacks
  arm64: Add support for ASID locking

Andrew Pinski (1):
  arm64: Add workaround for Cavium erratum 36890

Angela Czubak (2):
  octeontx2-af: fix rvu_sso_ggrp_taq_flush
  octeontx2-af: fix cgx_lmac_rx_tx_enable

Anil Kumar Reddy (1):
  hwrng: cn10k: Add random number generator health check

Baha Mesleh (1):
  octeontx2-bphy-netdev: fix cleanup sequence in char device release

Ben Peled (1):
  cpufreq: armada: enable ap807-cpu-clk.

Bharat Bhushan (5):
  soc/octeontx2 : Add driver support for NMI GTI watchdog
  octeontx2: gti: Fix task stack pointer corruption
  perf/marvell: CN10k DDR performance monitor support
  perf/marvell: cn10k DDR perfmon event overflow handling
  perf/marvell: Set DDR perf event ownership

Bhaskara Budiredla (5):
  arm64: Add workaround for Marvell erratum 38545
  octeontx2: marvell: Add driver support for LLC lock and unlock
  drivers: mmc: Adds pstore driver to store kernel crash dumps to MMC
  drivers: mmc: enables mmc polling for pstore path
  drivers: perf: Add LLC-TAD perf counter support

Burla, Satananda (1):
  octeontx2-dpi: Fix DPI engine blks allocation

Chandrakala Chavva (15):
  net: thunderx: Fix RXAUI link status
  driver: net: thunder: Print 1000Base-X or SGMII based on mode.
  mmc: cavium: Use proper register to clear interrupts
  mmc: octeontx2: Fix tuning for T96 C0
  mmc: octeontx2: Configure flags for T96 pass B0
  octeontx2-serdes: Update PRBS APIs to start/stop per QLM lane
  octeontx2-serdes: Fix parameter passed to start_prbs().
  octeontx2-serdes: Fix prbs error reporting
  driver: serdes_debugfs: Allow user to clear prbs errors.
  octeontx2-serdes: Fix prbs per lane configuration
  driver: serdes_debugfs: Add new smc call to tune serdes
  driver: serdes_debugfs: Add new smc call for serdes loopback
  driver: serdes_debugfs: Add inject optional parameter to prbs command
  driver: soc: marvell: Don't enable mvmdio driver by default
  drivers: soc: marvell: Add config option for serdes diagnostics

Christina Jacob (16):
  net:thunderx: fix memory leak in nicvf driver.
  net: thunderx: Do a PCS reset upon SGMII link toggle
  octeontx2-pf: Adding ethtool support for link status information.
  octeontx2-af: Support to get link info like current speed, fec etc
  octeontx2-pf: Ethtool support for fec configuration
  octeontx2-af: Move to rvu_fwdata version 1.
  octeontx2-pf: Add ethtool -m option support.
  octeontx2-af: Update fwadata structure with few more reserved fields.
  octeontx2-af: Fetch FEC stats of the physical link
  octeontx2-pf: Support to display fec counters also in ethtool stats.
  octeontx2-pf: Support to display current settings of a vf network 
interface via ethtool
  octeontx2-af: Introduce SET_LINK_MODE command to change various 
configurations of a network interface.
  octeontx2-pf: support to change link speed and autoneg
  octeontx2-pf: remove redundant changes from speed change suppcrt.
  octeontx-af: Interface mode change feature via ethtool
  octeontx2-pf: Interface Mode change using ethtool.

Damian Eppel (3):
  soc: marvell: MDIO uio driver
  drivers: soc: marvell: PHY diagnostics debugfs driver
  drivers: soc: marvell: PHY diagnostics driver update

Dana Vardi (1):
  net: mvpp2: prs: ipv4 different ihl support

Felix Manlunas (4):
  octeontx2-af: Add new CGX_CMDs to set and get PHY modulation type
  octeontx2-pf: Add ethtool priv flag to control PAM4 on/off
  octeontx2-pf: Fix wrong info in ethtool's list of supported link modes
  octeontx2-af: Add new CGX_CMD to get PHY FEC statistics

Geetha sowjanya (34):
  octeontx2-af: Check SQ counters to detect the deadlock
  octeontx2-af: Update hardware

[linux-yocto][linux-yocto v5.10] [RT] kernel code for marvell cn96xx and marvell cn106xx

2021-06-30 Thread Ruiqiang Hao 
Hi Bruce,

Please help to create branch and merge code into our linux-yocto repo.

repo:
linux-yocto
branch:
v5.10/standard/preempt-rt/cn-sdkv5.4/octeon

Thanks,
Ruiqiang

The following changes since commit 4a59bc57b2be77da9394b10eb37067da7d63b7a4:

  Merge branch 'v5.10/standard/base' into v5.10/standard/preempt-rt/base 
(2021-06-25 20:05:35 -0400)

are available in the Git repository at:

  https://github.com/cythe/linux.git 
v5.10/standard/preempt-rt/cn-sdkv5.4/octeon.v3

for you to fetch changes up to dab9728677cd3a1a1763bfce2edc7919ff4d7e00:

  spi: spi-octeontx2: fix erase sector error by limit spi buswidth (2021-06-30 
17:54:53 +0800)


Aaron Williams (4):
  mmc: octeontx2: Add tuning support for HS400 mode
  mmc: octeontx2: Use flags for hardware differences
  mmc: octeontx2: fix handling calibration glitch
  Marvell: CN10K: Display version information for flash components

Aleksey Makarov (1):
  octeontx2-pf: Add support for PTP clock

Alex Belits (2):
  kernel/exit.c: Add task cleanup callbacks
  arm64: Add support for ASID locking

Andrew Pinski (1):
  arm64: Add workaround for Cavium erratum 36890

Angela Czubak (2):
  octeontx2-af: fix rvu_sso_ggrp_taq_flush
  octeontx2-af: fix cgx_lmac_rx_tx_enable

Anil Kumar Reddy (1):
  hwrng: cn10k: Add random number generator health check

Baha Mesleh (1):
  octeontx2-bphy-netdev: fix cleanup sequence in char device release

Ben Peled (1):
  cpufreq: armada: enable ap807-cpu-clk.

Bharat Bhushan (5):
  soc/octeontx2 : Add driver support for NMI GTI watchdog
  octeontx2: gti: Fix task stack pointer corruption
  perf/marvell: CN10k DDR performance monitor support
  perf/marvell: cn10k DDR perfmon event overflow handling
  perf/marvell: Set DDR perf event ownership

Bhaskara Budiredla (5):
  arm64: Add workaround for Marvell erratum 38545
  octeontx2: marvell: Add driver support for LLC lock and unlock
  drivers: mmc: Adds pstore driver to store kernel crash dumps to MMC
  drivers: mmc: enables mmc polling for pstore path
  drivers: perf: Add LLC-TAD perf counter support

Burla, Satananda (1):
  octeontx2-dpi: Fix DPI engine blks allocation

Chandrakala Chavva (15):
  net: thunderx: Fix RXAUI link status
  driver: net: thunder: Print 1000Base-X or SGMII based on mode.
  mmc: cavium: Use proper register to clear interrupts
  mmc: octeontx2: Fix tuning for T96 C0
  mmc: octeontx2: Configure flags for T96 pass B0
  octeontx2-serdes: Update PRBS APIs to start/stop per QLM lane
  octeontx2-serdes: Fix parameter passed to start_prbs().
  octeontx2-serdes: Fix prbs error reporting
  driver: serdes_debugfs: Allow user to clear prbs errors.
  octeontx2-serdes: Fix prbs per lane configuration
  driver: serdes_debugfs: Add new smc call to tune serdes
  driver: serdes_debugfs: Add new smc call for serdes loopback
  driver: serdes_debugfs: Add inject optional parameter to prbs command
  driver: soc: marvell: Don't enable mvmdio driver by default
  drivers: soc: marvell: Add config option for serdes diagnostics

Christina Jacob (16):
  net:thunderx: fix memory leak in nicvf driver.
  net: thunderx: Do a PCS reset upon SGMII link toggle
  octeontx2-pf: Adding ethtool support for link status information.
  octeontx2-af: Support to get link info like current speed, fec etc
  octeontx2-pf: Ethtool support for fec configuration
  octeontx2-af: Move to rvu_fwdata version 1.
  octeontx2-pf: Add ethtool -m option support.
  octeontx2-af: Update fwadata structure with few more reserved fields.
  octeontx2-af: Fetch FEC stats of the physical link
  octeontx2-pf: Support to display fec counters also in ethtool stats.
  octeontx2-pf: Support to display current settings of a vf network 
interface via ethtool
  octeontx2-af: Introduce SET_LINK_MODE command to change various 
configurations of a network interface.
  octeontx2-pf: support to change link speed and autoneg
  octeontx2-pf: remove redundant changes from speed change suppcrt.
  octeontx-af: Interface mode change feature via ethtool
  octeontx2-pf: Interface Mode change using ethtool.

Damian Eppel (3):
  soc: marvell: MDIO uio driver
  drivers: soc: marvell: PHY diagnostics debugfs driver
  drivers: soc: marvell: PHY diagnostics driver update

Dana Vardi (1):
  net: mvpp2: prs: ipv4 different ihl support

Felix Manlunas (4):
  octeontx2-af: Add new CGX_CMDs to set and get PHY modulation type
  octeontx2-pf: Add ethtool priv flag to control PAM4 on/off
  octeontx2-pf: Fix wrong info in ethtool's list of supported link modes
  octeontx2-af: Add new CGX_CMD to get PHY FEC statistics

Geetha sowjanya (34):
  octeontx2-af: Check SQ counters to detect the deadlock

[Yocto] Launching script at the very end of the image process

2021-06-30 Thread Cardaillac, Yann 
Hi yall,

I'm switching from buildroot to yocto and trying to figure out how to do the 
equivalent of a POST_BUILD_SCRIPT.

Indeed I want to format the images built in a specific format for latter use 
and CI needs.

I've made a recipe (.inc) that I'm able to access directly doing so:

bitbake ycn-image -c release_ycn

To give a bit more context here's how I've made it :

File ycn-image.bb:

SUMMARY = "Ycn image"
...

require recipes-core/images/core-image-base.bb
...
inherit package-list

require ycn-release.inc
...

File ycn-release.inc:

do_release_ycn() {
...
}
addtask release_ycn after do_image_complete after do_deploy_kernelmodules

I've also tried to use IMAGE_POSTPROCESS_COMMAND without much success since it 
wasn't running at the proper moment.

If you happen to have any leads on the subject please don't hesitate to share!

Best regards,

Yann

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54013): https://lists.yoctoproject.org/g/yocto/message/54013
Mute This Topic: https://lists.yoctoproject.org/mt/83888533/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-