Re: [linux-yocto] [kernel-cache master]: ti-am335x

[Jun Miao]

On 8/7/19 10:45 AM, Bruce Ashfield wrote:

On Tue, Aug 6, 2019 at 6:20 AM Jun Miao  wrote:


Hi Bruce,

 I am working ti boards(AM335x evm/sk/BBB) with am335x soc.

 1.This patch add scc/cfg to yocto-kernel-cache master branch.


#1 shouldn't be a problem.

 2.Could you help me build a new branch "ti-am335x" in

linux-yocto-dev?



but #2 raises a question.  I try and limit the number of BSP specific
branches. What type of patches are you expecting to put on that branch, and
do you expect that they won't be safe for other boards ?

Bruce


hi Bruce ,

This branch is prepared for ti-am335x CI/CD development,and there will 
be some TI SDK patches into.


i am afraid that those patches for ti-am335x(evm/sk/bbb) boards will 
influence other boards.



Thanks
Jun




Thanks



Jun Miao (1):
   ti-am335x: add the basic scc/cfg enablement

  bsp/ti-am335x/ti-am335x-standard.scc |   8 +
  bsp/ti-am335x/ti-am335x.cfg  | 242 +++
  bsp/ti-am335x/ti-am335x.scc  |   7 +
  3 files changed, 257 insertions(+)
  create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
  create mode 100644 bsp/ti-am335x/ti-am335x.cfg
  create mode 100644 bsp/ti-am335x/ti-am335x.scc

--
2.22.0



--
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 1/1] ti-am335x: add the basic scc/cfg enablement

[Jun Miao]

On 8/7/19 10:47 AM, Bruce Ashfield wrote:

On Tue, Aug 6, 2019 at 6:20 AM Jun Miao  wrote:


Add scc/cfg kernel fragment to build and boot EVM/SK and BeagleBone Black
boards all with am335x soc

Signed-off-by: Jun Miao 
---
  bsp/ti-am335x/ti-am335x-standard.scc |   8 +
  bsp/ti-am335x/ti-am335x.cfg  | 242 +++
  bsp/ti-am335x/ti-am335x.scc  |   7 +
  3 files changed, 257 insertions(+)
  create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
  create mode 100644 bsp/ti-am335x/ti-am335x.cfg
  create mode 100644 bsp/ti-am335x/ti-am335x.scc

diff --git a/bsp/ti-am335x/ti-am335x-standard.scc
b/bsp/ti-am335x/ti-am335x-standard.scc
new file mode 100644
index ..d357a729
--- /dev/null
+++ b/bsp/ti-am335x/ti-am335x-standard.scc
@@ -0,0 +1,8 @@
+define KMACHINE ti-am335x
+define KTYPE standard
+define KARCH arm64
+
+include ktypes/standard/standard.scc
+branch ti-am335x
+
+include ti-am335x.scc
diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg
new file mode 100644
index ..bb5b6653
--- /dev/null
+++ b/bsp/ti-am335x/ti-am335x.cfg
@@ -0,0 +1,242 @@
+#.
+#WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the final configuration (e.g. platform
+# configuration, feature configuration, and board specific hardware
+# configuration).  For more information on kernel configuration, please
+# consult the product documentation.
+#
+#.
+
+CONFIG_ARM=y
+CONFIG_ARCH_OMAP=y
+CONFIG_OMAP_DM_TIMER=y
+CONFIG_SOC_AM33XX=y
+CONFIG_ARCH_OMAP2PLUS=y
+
+
+#
+# At least one emulation must be selected
+#
+CONFIG_VFP=y
+CONFIG_VFPv3=y
+CONFIG_NEON=y
+
+#
+# Power management options
+#
+
+CONFIG_PM=y
+CONFIG_REGMAP_IRQ=y
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_OMAP_OCP2SCP=y
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_NAND_ECC=y
+CONFIG_MTD_RAW_NAND=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_OMAP2=y
+CONFIG_MTD_NAND_OMAP_BCH=y
+CONFIG_MTD_NAND_OMAP_BCH_BUILD=y
+
+# Misc devices
+CONFIG_EEPROM_AT24=y
+CONFIG_SENSORS_LIS3_I2C=y
+CONFIG_BLK_DEV_SD=y
+
+CONFIG_ETHERNET=y
+CONFIG_NET_VENDOR_TI=y
+CONFIG_TI_DAVINCI_MDIO=y
+CONFIG_TI_DAVINCI_CPDMA=y
+CONFIG_TI_CPSW_PHY_SEL=y
+CONFIG_TI_CPSW_ALE=y
+CONFIG_TI_CPSW=y
+CONFIG_TI_CPTS=y
+CONFIG_PHYLIB=y
+
+CONFIG_SMSC_PHY=y
+CONFIG_FIXED_PHY=y
+
+#
+# Input Device Drivers
+#
+
+CONFIG_INPUT=y
+CONFIG_INPUT_MOUSEDEV=y
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_KEYBOARD=y
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_MATRIX=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_TPS65218_PWRBUTTON=m
+CONFIG_SERIAL_EARLYCON=y
+
+#
+# 8250 serial port support
+#
+
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_8250_OMAP=y
+CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
+
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_OMAP=y
+
+# I2C support
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_OMAP=y
+CONFIG_SENSORS_TSL2550=y
+CONFIG_GPIO_TWL4030=y
+CONFIG_PTP_1588_CLOCK=y
+CONFIG_GPIO_PCF857X=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
+
+CONFIG_GPIOLIB=y
+CONFIG_OF_GPIO=y
+CONFIG_GPIOLIB_IRQCHIP=y
+CONFIG_GPIO_SYSFS=y
+
+CONFIG_GPIO_OMAP=y
+CONFIG_GPIO_PCA953X=m
+CONFIG_GPIO_TPS65910=y
+
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_OMAP_WATCHDOG=m
+
+CONFIG_MFD_SYSCON=y
+CONFIG_MFD_TI_AM335X_TSCADC=y
+CONFIG_MFD_OMAP_USB_HOST=y
+CONFIG_MFD_TPS65217=y
+CONFIG_MFD_TPS65218=y
+CONFIG_MFD_TPS65910=y
+CONFIG_TWL6040_CORE=y
+
+#
+# LCD
+#
+CONFIG_DRM=y
+CONFIG_DRM_OMAP=y
+CONFIG_OMAP2_DSS_DPI=y
+CONFIG_DRM_TILCDC=y
+CONFIG_DRM_OMAP_PANEL_DPI=y
+CONFIG_DRM_I2C_NXP_TDA998X=y
+
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_GENERIC=y
+CONFIG_PWM=y
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_BACKLIGHT_GPIO=y
+
+
+CONFIG_SOUND=m
+CONFIG_SND=m
+CONFIG_SND_SOC=m
+CONFIG_SND_DAVINCI_SOC_MCASP=m
+CONFIG_SND_SIMPLE_CARD=m
+
+
+#CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+#CONFIG_USB_MON=m
+
+#
+# USB Host Controller Drivers
+#
+CONFIG_USB=y
+CONFIG_USB_SUPPORT=y
+
+CONFIG_USB_EHCI_HCD=m
+CONFIG_USB_EHCI_TT_NEWSCHED=y
+CONFIG_USB_EHCI_HCD_OMAP=m
+CONFIG_USB_MUSB_HDRC=m
+
+#
+# USB Physical Layer drivers Peripheral Controller
+#
+CONFIG_USB_PHY=y
+CONFIG_NOP_USB_XCEIV=m
+CONFIG_AM335X_CONTROL_USB=m
+CONFIG_AM335X_PHY_USB=m
+
+# Platform Glue Layer
+CONFIG_USB_MUSB_DSPS=m
+CONFIG_USB_MUSB_AM335X_CHILD=m
+
+# MUSB DMA mode
+CONFIG_USB_TI_CPPI41_DMA=y
+
+
+#
+# MMC/SD/SDIO Card Drivers
+#
+CONFIG_MMC=y

Re: [linux-yocto] [kernel-tools][PATCH] Add SPDX license headers to source files

[Bruce Ashfield]

Looks fine to me.

I'm traveling right now, so it will be a few days until I get this merged
and can send SRCREV updates to oe-core.

Bruce

On Tue, Aug 6, 2019 at 3:06 PM William Bourque  wrote:

> Kconfiglib/* were under ISC license before they were imported
> here from https://github.com/ulfalizer/Kconfiglib
> Adjusting SPDX header to reflect that fact.
>
> tools/* all have some sort of GPLv2 headers; adding SPDX header
> to make it obvious.
>
> This address bug #13334 :
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=13334
>
> Change-Id: I243f2dd266a398f982798b771e74a67be70ecb52
> Signed-off-by: William Bourque 
> ---
>  Kconfiglib/examples/allnoconfig_walk.py| 2 ++
>  Kconfiglib/examples/defconfig.py   | 2 ++
>  Kconfiglib/examples/defconfig_oldconfig.py | 2 ++
>  Kconfiglib/examples/eval_expr.py   | 2 ++
>  Kconfiglib/examples/find_symbol.py | 2 ++
>  Kconfiglib/examples/help_grep.py   | 2 ++
>  Kconfiglib/examples/list_undefined.py  | 2 ++
>  Kconfiglib/examples/menuconfig_example.py  | 2 ++
>  Kconfiglib/examples/merge_config.py| 2 ++
>  Kconfiglib/examples/print_config_tree.py   | 2 ++
>  Kconfiglib/examples/print_sym_info.py  | 2 ++
>  Kconfiglib/examples/print_tree.py  | 2 ++
>  Kconfiglib/setup.py| 4 
>  Kconfiglib/tests/reltest   | 1 +
>  tools/buildall | 1 +
>  tools/get_defconfig| 1 +
>  tools/kconf_check  | 1 +
>  tools/kgit | 1 +
>  tools/kgit-checkpoint  | 1 +
>  tools/kgit-clean   | 1 +
>  tools/kgit-config-cleaner  | 1 +
>  tools/kgit-feature | 1 +
>  tools/kgit-init| 1 +
>  tools/kgit-meta| 1 +
>  tools/kgit-publish | 1 +
>  tools/kgit-s2q | 1 +
>  tools/kgit-scc | 1 +
>  tools/scc  | 1 +
>  tools/spp  | 1 +
>  tools/symbol_why.py| 2 ++
>  30 files changed, 46 insertions(+)
>
> diff --git a/Kconfiglib/examples/allnoconfig_walk.py
> b/Kconfiglib/examples/allnoconfig_walk.py
> index b94a169..05ec7b5 100644
> --- a/Kconfiglib/examples/allnoconfig_walk.py
> +++ b/Kconfiglib/examples/allnoconfig_walk.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # This is tree-walking version of allnoconfig.py, for demonstration
> purposes.
>  # Verified by the test suite to generate identical output to 'make
> allnoconfig'
>  # for all ARCHes.
> diff --git a/Kconfiglib/examples/defconfig.py
> b/Kconfiglib/examples/defconfig.py
> index cc3f12d..6797890 100644
> --- a/Kconfiglib/examples/defconfig.py
> +++ b/Kconfiglib/examples/defconfig.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Works like entering "make menuconfig" and immediately saving and exiting
>  #
>  # Usage:
> diff --git a/Kconfiglib/examples/defconfig_oldconfig.py
> b/Kconfiglib/examples/defconfig_oldconfig.py
> index 3735ee1..bf34e94 100644
> --- a/Kconfiglib/examples/defconfig_oldconfig.py
> +++ b/Kconfiglib/examples/defconfig_oldconfig.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Produces exactly the same output as the following script:
>  #
>  # make defconfig
> diff --git a/Kconfiglib/examples/eval_expr.py
> b/Kconfiglib/examples/eval_expr.py
> index 6d8695e..3eb49fb 100644
> --- a/Kconfiglib/examples/eval_expr.py
> +++ b/Kconfiglib/examples/eval_expr.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Evaluates an expression (e.g. "X86_64 || (X86_32 && X86_LOCAL_APIC)")
> in the
>  # context of a configuration. Note that this always yields a tristate
> value (n,
>  # m, or y).
> diff --git a/Kconfiglib/examples/find_symbol.py
> b/Kconfiglib/examples/find_symbol.py
> index 0d3c968..2e22fd7 100644
> --- a/Kconfiglib/examples/find_symbol.py
> +++ b/Kconfiglib/examples/find_symbol.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Prints all menu nodes that reference a given symbol any of their
> properties
>  # or property conditions, along with their parent menu nodes.
>  #
> diff --git a/Kconfiglib/examples/help_grep.py
> b/Kconfiglib/examples/help_grep.py
> index 20a4911..0e60512 100644
> --- a/Kconfiglib/examples/help_grep.py
> +++ b/Kconfiglib/examples/help_grep.py
> @@ -1,3 +1,5 @@
> +# SPDX-License-Identifier: ISC
> +#
>  # Does a case-insensitive search for a regular expression in the help
> texts of
>  # symbols and choices and the prompts of menus and comments. Prints the
>  # matching items together with their locations and the matching text.
> diff --git a/Kconfiglib/examples/list_undefined.py
> b/Kconfiglib/examples/list_undefined.py
> index 0207975..f531777 100644
> --- a/Kconfiglib/examples/list_undefined.py
> +++ 

Re: [linux-yocto] [PATCH] nfsd4: Fix kernel crash when reading proc file reply_cache_stats

[Bruce Ashfield]

On Tue, Aug 6, 2019 at 6:49 AM  wrote:

> From: He Zhe 
>
> reply_cache_stats uses wrong parameter as seq file private structure and
> thus causes the following kernel crash when users read
> /proc/fs/nfsd/reply_cache_stats
>
> BUG: kernel NULL pointer dereference, address: 01f9
> PGD 0 P4D 0
> Oops:  [#3] SMP PTI
> CPU: 6 PID: 1502 Comm: cat Tainted: G  D   5.3.0-rc3+ #1
> Hardware name: Intel Corporation Broadwell Client platform/Basking Ridge,
> BIOS BDW-E2R1.86C.0118.R01.1503110618 03/11/2015
> RIP: 0010:nfsd_reply_cache_stats_show+0x3b/0x2d0
> Code: 41 54 49 89 f4 48 89 fe 48 c7 c7 b3 10 33 88 53 bb e8 03 00 00 e8 88
> 82 d1 ff bf 58 89 41 00 e8 eb c5 85 00 48 83 eb 01 75 f0 <41> 8b 94 24 f8
> 01 00 00 48 c7 c6 be 10 33 88 4c 89 ef bb e8 03 00
> RSP: 0018:aa520106fe08 EFLAGS: 00010246
> RAX: 00cfe1a77123 RBX:  RCX: 00291b46
> RDX: 00cf RSI: 0006 RDI: 00291b28
> RBP: aa520106fe20 R08: 0006 R09: 00cfe17e55dd
> R10: a424e47c R11: 030b R12: 0001
> R13: a424e5697000 R14: 0001 R15: a424e5697000
> FS:  7f805735f580() GS:a424f8f8()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 01f9 CR3: 655ce005 CR4: 003606e0
> Call Trace:
>  seq_read+0x194/0x3e0
>  __vfs_read+0x1b/0x40
>  vfs_read+0x95/0x140
>  ksys_read+0x61/0xe0
>  __x64_sys_read+0x1a/0x20
>  do_syscall_64+0x4d/0x120
>  entry_SYSCALL_64_after_hwframe+0x44/0xa9
> RIP: 0033:0x7f805728b861
> Code: fe ff ff 50 48 8d 3d 86 b4 09 00 e8 79 e0 01 00 66 0f 1f 84 00 00 00
> 00 00 48 8d 05 d9 19 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff
> ff 77 57 c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
> RSP: 002b:7ffea1ce3c38 EFLAGS: 0246 ORIG_RAX: 
> RAX: ffda RBX: 0002 RCX: 7f805728b861
> RDX: 0002 RSI: 7f8057183000 RDI: 0003
> RBP: 7f8057183000 R08: 7f8057182010 R09: 
> R10: 0022 R11: 0246 R12: 559a60e8ff10
> R13: 0003 R14: 0002 R15: 0002
> Modules linked in:
> CR2: 01f9
> ---[ end trace 01613595153f0cba ]---
> RIP: 0010:nfsd_reply_cache_stats_show+0x3b/0x2d0
> Code: 41 54 49 89 f4 48 89 fe 48 c7 c7 b3 10 33 88 53 bb e8 03 00 00 e8 88
> 82 d1 ff bf 58 89 41 00 e8 eb c5 85 00 48 83 eb 01 75 f0 <41> 8b 94 24 f8
> 01 00 00 48 c7 c6 be 10 33 88 4c 89 ef bb e8 03 00
> RSP: 0018:aa52004b3e08 EFLAGS: 00010246
> RAX: 002bab45a7c6 RBX:  RCX: 00291b4c
> RDX: 002b RSI: 0004 RDI: 00291b28
> RBP: aa52004b3e20 R08: 0004 R09: 002bab1c8c7a
> R10: a424e550 R11: 02a9 R12: 0001
> R13: a424e4475000 R14: 0001 R15: a424e4475000
> FS:  7f805735f580() GS:a424f8f8()
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 01f9 CR3: 655ce005 CR4: 003606e0
> Killed
>
> Fixes: 3ba75830ce17 ("nfsd4: drc containerization")
> Signed-off-by: He Zhe 
> ---
> This is for all branches and has also been sent to mainline.
> Please consider if it's worth merging in linux-yocto-dev for this moment.
> Thanks.
>

Looks fine to me.

For patches like this, it is helpful if you also put a patch to the
upstream submission. So on my next updates to the kernel, I'll be able to
easily drop (or carry) it.

This is now merged.

Bruce



>
>  fs/nfsd/nfscache.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c
> index 26ad75a..96352ab 100644
> --- a/fs/nfsd/nfscache.c
> +++ b/fs/nfsd/nfscache.c
> @@ -571,7 +571,7 @@ nfsd_cache_append(struct svc_rqst *rqstp, struct kvec
> *data)
>   */
>  static int nfsd_reply_cache_stats_show(struct seq_file *m, void *v)
>  {
> -   struct nfsd_net *nn = v;
> +   struct nfsd_net *nn = m->private;
>
> seq_printf(m, "max entries:   %u\n", nn->max_drc_entries);
> seq_printf(m, "num entries:   %u\n",
> --
> 2.7.4
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [PATCH 1/1] ti-am335x: add the basic scc/cfg enablement

[Bruce Ashfield]

On Tue, Aug 6, 2019 at 6:20 AM Jun Miao  wrote:

> Add scc/cfg kernel fragment to build and boot EVM/SK and BeagleBone Black
> boards all with am335x soc
>
> Signed-off-by: Jun Miao 
> ---
>  bsp/ti-am335x/ti-am335x-standard.scc |   8 +
>  bsp/ti-am335x/ti-am335x.cfg  | 242 +++
>  bsp/ti-am335x/ti-am335x.scc  |   7 +
>  3 files changed, 257 insertions(+)
>  create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
>  create mode 100644 bsp/ti-am335x/ti-am335x.cfg
>  create mode 100644 bsp/ti-am335x/ti-am335x.scc
>
> diff --git a/bsp/ti-am335x/ti-am335x-standard.scc
> b/bsp/ti-am335x/ti-am335x-standard.scc
> new file mode 100644
> index ..d357a729
> --- /dev/null
> +++ b/bsp/ti-am335x/ti-am335x-standard.scc
> @@ -0,0 +1,8 @@
> +define KMACHINE ti-am335x
> +define KTYPE standard
> +define KARCH arm64
> +
> +include ktypes/standard/standard.scc
> +branch ti-am335x
> +
> +include ti-am335x.scc
> diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg
> new file mode 100644
> index ..bb5b6653
> --- /dev/null
> +++ b/bsp/ti-am335x/ti-am335x.cfg
> @@ -0,0 +1,242 @@
> +#.
> +#WARNING
> +#
> +# This file is a kernel configuration fragment, and not a full kernel
> +# configuration file.  The final kernel configuration is made up of
> +# an assembly of processed fragments, each of which is designed to
> +# capture a specific part of the final configuration (e.g. platform
> +# configuration, feature configuration, and board specific hardware
> +# configuration).  For more information on kernel configuration, please
> +# consult the product documentation.
> +#
> +#.
> +
> +CONFIG_ARM=y
> +CONFIG_ARCH_OMAP=y
> +CONFIG_OMAP_DM_TIMER=y
> +CONFIG_SOC_AM33XX=y
> +CONFIG_ARCH_OMAP2PLUS=y
> +
> +
> +#
> +# At least one emulation must be selected
> +#
> +CONFIG_VFP=y
> +CONFIG_VFPv3=y
> +CONFIG_NEON=y
> +
> +#
> +# Power management options
> +#
> +
> +CONFIG_PM=y
> +CONFIG_REGMAP_IRQ=y
> +
> +#
> +# RAM/ROM/Flash chip drivers
> +#
> +CONFIG_OMAP_OCP2SCP=y
> +CONFIG_MTD=y
> +CONFIG_MTD_CMDLINE_PARTS=y
> +CONFIG_MTD_BLKDEVS=y
> +CONFIG_MTD_BLOCK=y
> +CONFIG_MTD_NAND_ECC=y
> +CONFIG_MTD_RAW_NAND=y
> +CONFIG_MTD_CFI=y
> +CONFIG_MTD_CFI_INTELEXT=y
> +
> +CONFIG_MTD_NAND=y
> +CONFIG_MTD_NAND_OMAP2=y
> +CONFIG_MTD_NAND_OMAP_BCH=y
> +CONFIG_MTD_NAND_OMAP_BCH_BUILD=y
> +
> +# Misc devices
> +CONFIG_EEPROM_AT24=y
> +CONFIG_SENSORS_LIS3_I2C=y
> +CONFIG_BLK_DEV_SD=y
> +
> +CONFIG_ETHERNET=y
> +CONFIG_NET_VENDOR_TI=y
> +CONFIG_TI_DAVINCI_MDIO=y
> +CONFIG_TI_DAVINCI_CPDMA=y
> +CONFIG_TI_CPSW_PHY_SEL=y
> +CONFIG_TI_CPSW_ALE=y
> +CONFIG_TI_CPSW=y
> +CONFIG_TI_CPTS=y
> +CONFIG_PHYLIB=y
> +
> +CONFIG_SMSC_PHY=y
> +CONFIG_FIXED_PHY=y
> +
> +#
> +# Input Device Drivers
> +#
> +
> +CONFIG_INPUT=y
> +CONFIG_INPUT_MOUSEDEV=y
> +CONFIG_INPUT_EVDEV=y
> +CONFIG_INPUT_KEYBOARD=y
> +CONFIG_KEYBOARD_GPIO=y
> +CONFIG_KEYBOARD_MATRIX=y
> +CONFIG_INPUT_TOUCHSCREEN=y
> +CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y
> +CONFIG_INPUT_MISC=y
> +CONFIG_INPUT_TPS65218_PWRBUTTON=m
> +CONFIG_SERIAL_EARLYCON=y
> +
> +#
> +# 8250 serial port support
> +#
> +
> +CONFIG_SERIAL_8250=y
> +CONFIG_SERIAL_8250_CONSOLE=y
> +CONFIG_SERIAL_OF_PLATFORM=y
> +CONFIG_SERIAL_8250_OMAP=y
> +CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
> +
> +CONFIG_SERIAL_CORE=y
> +CONFIG_SERIAL_CORE_CONSOLE=y
> +
> +CONFIG_HW_RANDOM=y
> +CONFIG_HW_RANDOM_OMAP=y
> +
> +# I2C support
> +CONFIG_I2C=y
> +CONFIG_I2C_CHARDEV=y
> +CONFIG_I2C_OMAP=y
> +CONFIG_SENSORS_TSL2550=y
> +CONFIG_GPIO_TWL4030=y
> +CONFIG_PTP_1588_CLOCK=y
> +CONFIG_GPIO_PCF857X=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_SINGLE=y
> +
> +CONFIG_GPIOLIB=y
> +CONFIG_OF_GPIO=y
> +CONFIG_GPIOLIB_IRQCHIP=y
> +CONFIG_GPIO_SYSFS=y
> +
> +CONFIG_GPIO_OMAP=y
> +CONFIG_GPIO_PCA953X=m
> +CONFIG_GPIO_TPS65910=y
> +
> +CONFIG_WATCHDOG=y
> +CONFIG_WATCHDOG_CORE=y
> +CONFIG_OMAP_WATCHDOG=m
> +
> +CONFIG_MFD_SYSCON=y
> +CONFIG_MFD_TI_AM335X_TSCADC=y
> +CONFIG_MFD_OMAP_USB_HOST=y
> +CONFIG_MFD_TPS65217=y
> +CONFIG_MFD_TPS65218=y
> +CONFIG_MFD_TPS65910=y
> +CONFIG_TWL6040_CORE=y
> +
> +#
> +# LCD
> +#
> +CONFIG_DRM=y
> +CONFIG_DRM_OMAP=y
> +CONFIG_OMAP2_DSS_DPI=y
> +CONFIG_DRM_TILCDC=y
> +CONFIG_DRM_OMAP_PANEL_DPI=y
> +CONFIG_DRM_I2C_NXP_TDA998X=y
> +
> +CONFIG_BACKLIGHT_LCD_SUPPORT=y
> +CONFIG_LCD_CLASS_DEVICE=y
> +CONFIG_LCD_PLATFORM=y
> +CONFIG_BACKLIGHT_CLASS_DEVICE=y
> +CONFIG_BACKLIGHT_GENERIC=y
> +CONFIG_PWM=y
> +CONFIG_BACKLIGHT_PWM=y
> +CONFIG_BACKLIGHT_GPIO=y
> +
> +
> +CONFIG_SOUND=m
> +CONFIG_SND=m
> +CONFIG_SND_SOC=m
> +CONFIG_SND_DAVINCI_SOC_MCASP=m
> +CONFIG_SND_SIMPLE_CARD=m
> +
> +
> +#CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
> +#CONFIG_USB_MON=m
> +
> +#
> +# USB Host Controller Drivers
> +#
> +CONFIG_USB=y
> +CONFIG_USB_SUPPORT=y
> +
> +CONFIG_USB_EHCI_HCD=m
> +CONFIG_USB_EHCI_TT_NEWSCHED=y
> +CONFIG_USB_EHCI_HCD_OMAP=m
> 

Re: [linux-yocto] [kernel-cache master]: ti-am335x

[Bruce Ashfield]

On Tue, Aug 6, 2019 at 6:20 AM Jun Miao  wrote:

> Hi Bruce,
>
> I am working ti boards(AM335x evm/sk/BBB) with am335x soc.
>
> 1.This patch add scc/cfg to yocto-kernel-cache master branch.
>

#1 shouldn't be a problem.

2.Could you help me build a new branch "ti-am335x" in
> linux-yocto-dev?
>
>
but #2 raises a question.  I try and limit the number of BSP specific
branches. What type of patches are you expecting to put on that branch, and
do you expect that they won't be safe for other boards ?

Bruce



> Thanks
>
>
>
> Jun Miao (1):
>   ti-am335x: add the basic scc/cfg enablement
>
>  bsp/ti-am335x/ti-am335x-standard.scc |   8 +
>  bsp/ti-am335x/ti-am335x.cfg  | 242 +++
>  bsp/ti-am335x/ti-am335x.scc  |   7 +
>  3 files changed, 257 insertions(+)
>  create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
>  create mode 100644 bsp/ti-am335x/ti-am335x.cfg
>  create mode 100644 bsp/ti-am335x/ti-am335x.scc
>
> --
> 2.22.0
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [linux-yocto] [kernel-cache] Question about profiling.scc

[Bruce Ashfield]

On Mon, Aug 5, 2019 at 11:44 PM Hongzhi, Song 
wrote:

> Hi Bruce,
>
> I see profiling.scc is included by kernel-cache/bsp/*, such as
> bsp/intel-x86 bsp/common-pc/ ... .
>
>
> My question is that is it necessary to open profiling.cfg defaultly?
>

We left profiling as a per-BSP decision, since production machine
configurations don't want the overhead that it brings.

Not all BSPs follow the split between developer and production, but see how
it is used in:

bsp/common-pc-64/common-pc-64-developer.scc:include
features/profiling/profiling.scc
bsp/common-pc-64/common-pc-64-preempt-rt.scc:include
features/profiling/profiling.scc

If it was enabled by default, it really should be in the developer ktype
and then BSPs could have the split between production and developer/debug
in their definitions .. with the developer ones getting profiling by
default.

Bruce



>
>
> --Hongzhi
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[yocto] [yocto-announce] [ANNOUNCEMENT] Milestone 2 for Yocto Project 2.8 (yocto-2.8_M2) now available

[Tummalapalli, Vineela]

Hello All,

We are pleased to announce the second milestone release for Yocto Project 2.8 
(yocto-2.8_M2) is now available for download.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.8_M2

bitbake: f5ea06fc2b6713c9f8e85ecf7cb981ae9a84d896
meta-gplv2: 1e2480e50f34e55bdfd5e06f98441e03a3752d5a
meta-intel: 3227874941bb8f9b706d6057b1de3997881bdffd
meta-mingw: 3fa43aa92f1a1c90304f6f4f49270915d1392cce
oecore: e0c3436241afca93f107e325d1b9ffcdebf706cd
poky: 835f7eac0610325e906591cd81890bebe8627580

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.8_M2/testreport.txt

Thank you.

Vineela Tummalapalli
vineela.tummalapa...@intel.com
Yocto Project Build and Release
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto-announce] [ANNOUNCEMENT] Milestone 2 for Yocto Project 2.8 (yocto-2.8_M2) now available

[Tummalapalli, Vineela]

Hello All,

We are pleased to announce the second milestone release for Yocto Project 2.8 
(yocto-2.8_M2) is now available for download.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.8_M2

bitbake: f5ea06fc2b6713c9f8e85ecf7cb981ae9a84d896
meta-gplv2: 1e2480e50f34e55bdfd5e06f98441e03a3752d5a
meta-intel: 3227874941bb8f9b706d6057b1de3997881bdffd
meta-mingw: 3fa43aa92f1a1c90304f6f4f49270915d1392cce
oecore: e0c3436241afca93f107e325d1b9ffcdebf706cd
poky: 835f7eac0610325e906591cd81890bebe8627580

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-2.8_M2/testreport.txt

Thank you.

Vineela Tummalapalli
vineela.tummalapa...@intel.com
Yocto Project Build and Release
-- 
___
yocto-announce mailing list
yocto-announce@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto-announce

Re: [yocto] -staticdev packages not in sdk

[Richard Purdie]

On Tue, 2019-08-06 at 14:04 +, Koeller, Thomas wrote:
> browsing the list archives I came across an older thread that exactly
> describes the problem I am currently struggling with:
> 
> https://lists.yoctoproject.org/pipermail/yocto/2018-February/039950.html
> 
> In short, I have a recipe that produces only a couple of header files
> and a single static library, nothing to be installed on the target.
> So the base package is empty, which is why I have 'ALLOW_EMPTY_${PN}
> = "1"' in its recipe. In my image definition I have
> 'SDKIMAGE_FEATURES_append = " staticdev-pkgs"', so I expect the
> -staticdev package to be included when generating the SDK. This is,
> however, not the case. While a large number of -staticdev packages
> from different recipes is now included in the SDK, only the -dev
> package is included for my recipe, not the -staticdev (though the
> corresponding rpm is actually built and contains the library as
> expected, it just is not installed).
> 
> The archived mail thread referenced above suggests adding the base
> package ${PN} to IMAGE_INSTALL, which indeed does work for me.
> However, I do not understand why this is necessary at all, as my
> package is already referenced from another recipe by being listed in
> that recipe's DEPENDS variable, shouldn't that be enough?

DEPENDS means its a *build* time dependency. Since nothing links to it
there is no runtime dependency generated and this empty package you've
created is never installed into the image.

If its not installed into the image, the SDK for that image won't have
the corresponding -dev package.

If you add an RDEPENDS on the empty package to something in the image,
you'll probably find the -dev package then is installed.

>  Also, the -dev package gets installed into the SDK even without such
> cruft. As far as I can see, identical logic is applied to both -dev
> and -staticdev packages, so what is the difference?
> 
> I also found a different workaround for the problem: listing the
> -staticdev package in TOOLCHAIN_TARGET_TASK. Needless to say, this
> workaround is just as undesirable as the former one.

Cheers,

Richard

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] U-boot enable not working for Raspberry Pi3

[Greg Wilson-Lindberg]

Hi Marek,

> -Original Message-
> From: Belisko Marek [mailto:marek.beli...@gmail.com]
> Sent: Tuesday, August 06, 2019 11:40 AM
> To: Greg Wilson-Lindberg 
> Cc: Yocto list discussion 
> Subject: Re: [yocto] U-boot enable not working for Raspberry Pi3
> 
> Hi Greg,
> 
> On Tue, Aug 6, 2019 at 8:29 PM Greg Wilson-Lindberg 
> wrote:
> >
> > Hi Marek,
> >
> > Thanks for the suggestion, that seems to be the case. What image are you
> building so I can try that to see what I get?
> Please don't top post ;). I'm building basic image. I worked few months ago 
> with
> bootqt and sometimes it was bit tricky ;). Are you sure you have this 
> variable set in
> local.conf?

Here is an excerpt from my local.conf file:

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is 
used to
# track the version of this file when it was generated. This can safely be 
ignored if
# this doesn't mean anything to you.
CONF_VERSION = "1"


#
# Custom additions
#

# Additional dtbo's
KERNEL_DEVICETREE_remove = " overlays/mcp2515-can0.dtbo 
overlays/mcp2515-can1.dtbo"

# Fixes for inclusion of mysql
PACKAGECONFIG_append_pn-qtbase += " sql-mysql"
QT_CONFIG_FLAGS_append_pn-qtbase += " -I /usr/include/mysql"
QT_CONFIG_FLAGS_append_pn-qtbase += " -I 
${STAGING_DIR_TARGET}/usr/include/mysql"

RPI_USE_U_BOOT = "1"

# End Custom additions
#

#INHERIT += "rm_work"
INHERIT += "image-buildinfo"
INHERIT += "internal-build"

I copied the line from the meta-raspberrypi documentation so I think it should 
be formatted correctly. I know the mysql stuff is working correctly.

I tried bitbake -e core-image-minmal and I don't get it being set then either.

> >
> > BR,
> > Greg
> >
> > > -Original Message-
> > > From: Belisko Marek [mailto:marek.beli...@gmail.com]
> > > Sent: Tuesday, August 06, 2019 11:12 AM
> > > To: Greg Wilson-Lindberg 
> > > Cc: Yocto list discussion 
> > > Subject: Re: [yocto] U-boot enable not working for Raspberry Pi3
> > >
> > > Hi Greg,
> > >
> > > On Tue, Aug 6, 2019 at 7:12 PM Greg Wilson-Lindberg
> > > 
> > > wrote:
> > > >
> > > > I'm working with a Yocto Sumo build provided with Qt's boot2qt
> > > > system. I'm trying
> > > to enable using Das U-boot to load Linux as a first step in trying
> > > to enable OSTree updates.
> > > >
> > > > In the meta-raspberrypi documentation is says to set:
> > > >
> > > > RPI_USE_U_BOOT = "1"
> > > Could be tha tboot2qt somehow drop your config. Please try tin run
> > > bitbake -e  | grep ^RPI_USE_U_BOOT to be sure that
> > > variable exists. I used it many times and it works perfectly fine.
> > > >
> > > > to enable u-boot for the raspberrypi. I have set that variable in
> > > > the top level
> > > local.conf file but I don't seem to be getting any changes in the
> > > build. Nothing in the cooker log shows building u-boot, and the
> > > start up screen doesn't show any u-boot messages.
> > > >
> > > > It appears that I'm missing necessary to turn u-boot on, can
> > > > anybody shed some
> > > light on what is going on?
> > > >
> > > > Regards,
> > > >
> > > > Greg Wilson-Lindberg
> > > > www.sakuraus.com
> > > > --
> > > > ___
> > > > yocto mailing list
> > > > yocto@yoctoproject.org
> > > > https://lists.yoctoproject.org/listinfo/yocto
> > >
> > > BR,
> > >
> > > marek
> > >
> > > --
> > > as simple and primitive as possible
> > > -
> > > Marek Belisko - OPEN-NANDRA
> > > Freelance Developer
> > >
> > > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > > Tel: +421 915 052 184
> > > skype: marekwhite
> > > twitter: #opennandra
> > > web: http://open-nandra.com
> 
> BR,
> 
> marek

BR,
Greg
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] U-boot enable not working for Raspberry Pi3

[Belisko Marek]

Hi Greg,

On Tue, Aug 6, 2019 at 8:29 PM Greg Wilson-Lindberg
 wrote:
>
> Hi Marek,
>
> Thanks for the suggestion, that seems to be the case. What image are you 
> building so I can try that to see what I get?
Please don't top post ;). I'm building basic image. I worked few
months ago with bootqt and sometimes it was bit tricky ;). Are you
sure you have this variable set in local.conf?
>
> BR,
> Greg
>
> > -Original Message-
> > From: Belisko Marek [mailto:marek.beli...@gmail.com]
> > Sent: Tuesday, August 06, 2019 11:12 AM
> > To: Greg Wilson-Lindberg 
> > Cc: Yocto list discussion 
> > Subject: Re: [yocto] U-boot enable not working for Raspberry Pi3
> >
> > Hi Greg,
> >
> > On Tue, Aug 6, 2019 at 7:12 PM Greg Wilson-Lindberg 
> > wrote:
> > >
> > > I'm working with a Yocto Sumo build provided with Qt's boot2qt system. 
> > > I'm trying
> > to enable using Das U-boot to load Linux as a first step in trying to 
> > enable OSTree
> > updates.
> > >
> > > In the meta-raspberrypi documentation is says to set:
> > >
> > > RPI_USE_U_BOOT = "1"
> > Could be tha tboot2qt somehow drop your config. Please try tin run bitbake 
> > -e
> >  | grep ^RPI_USE_U_BOOT to be sure that variable exists. I
> > used it many times and it works perfectly fine.
> > >
> > > to enable u-boot for the raspberrypi. I have set that variable in the top 
> > > level
> > local.conf file but I don't seem to be getting any changes in the build. 
> > Nothing in the
> > cooker log shows building u-boot, and the start up screen doesn't show any 
> > u-boot
> > messages.
> > >
> > > It appears that I'm missing necessary to turn u-boot on, can anybody shed 
> > > some
> > light on what is going on?
> > >
> > > Regards,
> > >
> > > Greg Wilson-Lindberg
> > > www.sakuraus.com
> > > --
> > > ___
> > > yocto mailing list
> > > yocto@yoctoproject.org
> > > https://lists.yoctoproject.org/listinfo/yocto
> >
> > BR,
> >
> > marek
> >
> > --
> > as simple and primitive as possible
> > -
> > Marek Belisko - OPEN-NANDRA
> > Freelance Developer
> >
> > Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> > Tel: +421 915 052 184
> > skype: marekwhite
> > twitter: #opennandra
> > web: http://open-nandra.com

BR,

marek
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] U-boot enable not working for Raspberry Pi3

[Greg Wilson-Lindberg]

Hi Marek,

Thanks for the suggestion, that seems to be the case. What image are you 
building so I can try that to see what I get?

BR,
Greg 

> -Original Message-
> From: Belisko Marek [mailto:marek.beli...@gmail.com]
> Sent: Tuesday, August 06, 2019 11:12 AM
> To: Greg Wilson-Lindberg 
> Cc: Yocto list discussion 
> Subject: Re: [yocto] U-boot enable not working for Raspberry Pi3
> 
> Hi Greg,
> 
> On Tue, Aug 6, 2019 at 7:12 PM Greg Wilson-Lindberg 
> wrote:
> >
> > I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm 
> > trying
> to enable using Das U-boot to load Linux as a first step in trying to enable 
> OSTree
> updates.
> >
> > In the meta-raspberrypi documentation is says to set:
> >
> > RPI_USE_U_BOOT = "1"
> Could be tha tboot2qt somehow drop your config. Please try tin run bitbake -e
>  | grep ^RPI_USE_U_BOOT to be sure that variable exists. I
> used it many times and it works perfectly fine.
> >
> > to enable u-boot for the raspberrypi. I have set that variable in the top 
> > level
> local.conf file but I don't seem to be getting any changes in the build. 
> Nothing in the
> cooker log shows building u-boot, and the start up screen doesn't show any 
> u-boot
> messages.
> >
> > It appears that I'm missing necessary to turn u-boot on, can anybody shed 
> > some
> light on what is going on?
> >
> > Regards,
> >
> > Greg Wilson-Lindberg
> > www.sakuraus.com
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
> 
> BR,
> 
> marek
> 
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
> 
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] U-boot enable not working for Raspberry Pi3

[Belisko Marek]

Hi Greg,

On Tue, Aug 6, 2019 at 7:12 PM Greg Wilson-Lindberg
 wrote:
>
> I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm 
> trying to enable using Das U-boot to load Linux as a first step in trying to 
> enable OSTree updates.
>
> In the meta-raspberrypi documentation is says to set:
>
> RPI_USE_U_BOOT = "1"
Could be tha tboot2qt somehow drop your config. Please try tin run
bitbake -e  | grep ^RPI_USE_U_BOOT to be sure that
variable exists. I used it many times and it works perfectly fine.
>
> to enable u-boot for the raspberrypi. I have set that variable in the top 
> level local.conf file but I don't seem to be getting any changes in the 
> build. Nothing in the cooker log shows building u-boot, and the start up 
> screen doesn't show any u-boot messages.
>
> It appears that I'm missing necessary to turn u-boot on, can anybody shed 
> some light on what is going on?
>
> Regards,
>
> Greg Wilson-Lindberg
> www.sakuraus.com
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto

BR,

marek

-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [kernel-tools][PATCH] Add SPDX license headers to source files

[William Bourque]

Kconfiglib/* were under ISC license before they were imported
here from https://github.com/ulfalizer/Kconfiglib
Adjusting SPDX header to reflect that fact.

tools/* all have some sort of GPLv2 headers; adding SPDX header
to make it obvious.

This address bug #13334 :
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13334

Change-Id: I243f2dd266a398f982798b771e74a67be70ecb52
Signed-off-by: William Bourque 
---
 Kconfiglib/examples/allnoconfig_walk.py| 2 ++
 Kconfiglib/examples/defconfig.py   | 2 ++
 Kconfiglib/examples/defconfig_oldconfig.py | 2 ++
 Kconfiglib/examples/eval_expr.py   | 2 ++
 Kconfiglib/examples/find_symbol.py | 2 ++
 Kconfiglib/examples/help_grep.py   | 2 ++
 Kconfiglib/examples/list_undefined.py  | 2 ++
 Kconfiglib/examples/menuconfig_example.py  | 2 ++
 Kconfiglib/examples/merge_config.py| 2 ++
 Kconfiglib/examples/print_config_tree.py   | 2 ++
 Kconfiglib/examples/print_sym_info.py  | 2 ++
 Kconfiglib/examples/print_tree.py  | 2 ++
 Kconfiglib/setup.py| 4 
 Kconfiglib/tests/reltest   | 1 +
 tools/buildall | 1 +
 tools/get_defconfig| 1 +
 tools/kconf_check  | 1 +
 tools/kgit | 1 +
 tools/kgit-checkpoint  | 1 +
 tools/kgit-clean   | 1 +
 tools/kgit-config-cleaner  | 1 +
 tools/kgit-feature | 1 +
 tools/kgit-init| 1 +
 tools/kgit-meta| 1 +
 tools/kgit-publish | 1 +
 tools/kgit-s2q | 1 +
 tools/kgit-scc | 1 +
 tools/scc  | 1 +
 tools/spp  | 1 +
 tools/symbol_why.py| 2 ++
 30 files changed, 46 insertions(+)

diff --git a/Kconfiglib/examples/allnoconfig_walk.py 
b/Kconfiglib/examples/allnoconfig_walk.py
index b94a169..05ec7b5 100644
--- a/Kconfiglib/examples/allnoconfig_walk.py
+++ b/Kconfiglib/examples/allnoconfig_walk.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: ISC
+#
 # This is tree-walking version of allnoconfig.py, for demonstration purposes.
 # Verified by the test suite to generate identical output to 'make allnoconfig'
 # for all ARCHes.
diff --git a/Kconfiglib/examples/defconfig.py b/Kconfiglib/examples/defconfig.py
index cc3f12d..6797890 100644
--- a/Kconfiglib/examples/defconfig.py
+++ b/Kconfiglib/examples/defconfig.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: ISC
+#
 # Works like entering "make menuconfig" and immediately saving and exiting
 #
 # Usage:
diff --git a/Kconfiglib/examples/defconfig_oldconfig.py 
b/Kconfiglib/examples/defconfig_oldconfig.py
index 3735ee1..bf34e94 100644
--- a/Kconfiglib/examples/defconfig_oldconfig.py
+++ b/Kconfiglib/examples/defconfig_oldconfig.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: ISC
+#
 # Produces exactly the same output as the following script:
 #
 # make defconfig
diff --git a/Kconfiglib/examples/eval_expr.py b/Kconfiglib/examples/eval_expr.py
index 6d8695e..3eb49fb 100644
--- a/Kconfiglib/examples/eval_expr.py
+++ b/Kconfiglib/examples/eval_expr.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: ISC
+#
 # Evaluates an expression (e.g. "X86_64 || (X86_32 && X86_LOCAL_APIC)") in the
 # context of a configuration. Note that this always yields a tristate value (n,
 # m, or y).
diff --git a/Kconfiglib/examples/find_symbol.py 
b/Kconfiglib/examples/find_symbol.py
index 0d3c968..2e22fd7 100644
--- a/Kconfiglib/examples/find_symbol.py
+++ b/Kconfiglib/examples/find_symbol.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: ISC
+#
 # Prints all menu nodes that reference a given symbol any of their properties
 # or property conditions, along with their parent menu nodes.
 #
diff --git a/Kconfiglib/examples/help_grep.py b/Kconfiglib/examples/help_grep.py
index 20a4911..0e60512 100644
--- a/Kconfiglib/examples/help_grep.py
+++ b/Kconfiglib/examples/help_grep.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: ISC
+#
 # Does a case-insensitive search for a regular expression in the help texts of
 # symbols and choices and the prompts of menus and comments. Prints the
 # matching items together with their locations and the matching text.
diff --git a/Kconfiglib/examples/list_undefined.py 
b/Kconfiglib/examples/list_undefined.py
index 0207975..f531777 100644
--- a/Kconfiglib/examples/list_undefined.py
+++ b/Kconfiglib/examples/list_undefined.py
@@ -1,3 +1,5 @@
+# SPDX-License-Identifier: ISC
+#
 # Prints a list of symbols that are referenced in the Kconfig files of some
 # architecture but not defined by the Kconfig files of any architecture.
 #
diff --git a/Kconfiglib/examples/menuconfig_example.py 
b/Kconfiglib/examples/menuconfig_example.py
index f026e74..b3763ba 100644
--- a/Kconfiglib/examples/menuconfig_example.py
+++ 

Re: [yocto] U-boot enable not working for Raspberry Pi3

[Maciej Pijanowski]

On 06.08.2019 18:55, Greg Wilson-Lindberg wrote:

I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm 
trying to enable using Das U-boot to load Linux as a first step in trying to 
enable OSTree updates.

In the meta-raspberrypi documentation is says to set:

RPI_USE_U_BOOT = "1"
Hi. I'm working with the U-Boot and RPI3 at the moment as well. I'm 
using warrior revision and not using the
Qt at all though. In my case setting the above variable was enough to 
build the U-Boot and include it in

the final image.

In my case the platform boots into the Linux. I'm having issues with 
weird artifacts and resolution on the HDMI
display, though. I believe this may be related to the U-Boot patching 
DTB to add the
simplefb: 
https://github.com/u-boot/u-boot/blob/master/board/raspberrypi/rpi/rpi.c#L490
while I want to keep using  the brcm fb with userland etc. (proprietary 
stuff).




to enable u-boot for the raspberrypi. I have set that variable in the top level 
local.conf file but I don't seem to be getting any changes in the build. 
Nothing in the cooker log shows building u-boot, and the start up screen 
doesn't show any u-boot messages.

It appears that I'm missing necessary to turn u-boot on, can anybody shed some 
light on what is going on?

Regards,

Greg Wilson-Lindberg
www.sakuraus.com


--
Maciej Pijanowski
Embedded Systems Engineer
https://3mdeb.com | @3mdeb_com

--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Minutes: Yocto Project Technical Team Meeting, 8/6/2019

[Reyna, David]

Minutes: Yocto Project Technical Team Meeting
When: Tuesday, August 09, 2019 8:00 AM-9:00 AM 1.
Attending: Richard, Armin, Michael, David, TrevorW, Tim, Vineela, Stephen, 
Randy, Joshua, Alex Kanavin, Jan-Simon, TrevorG, Ross, Alejandro, Tracy

* Stephen: General notes
  - M2 in final review
  - M3 making good progress
  - 2.6.3 QA, release next day
  - The 2.8 will become 3.0



* Richard: General notes

  - Hash Equivalency/runqueue merged this morning. The UI progress output a 
little different, may be confusing. Joshua: is this on autobuilder? Richard: 
not yet.

  - Spent a lot of time on runqueue. Trying to keep up with pseudo changes.

  - There is still a locale issue, not fixed. Probably easy once we figure it 
out.



* David: will Hash Equivalency/runqueue affect the documentation? Richard: no, 
it should be all be in the background. However, the UI progress output was 
setscene with a normal progress progression and then the real tasks would 
start. Now, as hash equivalencies are discovered, "setscene done" messages 
appear, which can happen several times over the processing. The progress bars 
are thus not as linear as before, but Richard want to leave it verbose so that 
any issues can be debugged before tuning the messages down.


* Armin: back from vacation, back on stable releases. Richard handled the 
stable releases in the meantime.

* Richard: 3 defects from QA from M2. Marked as blocking for M3.

* Question: plan for Rust? Randy: there has been interest over time, he will 
make and share a plan (probably in August).

* Xilinx: how to manage "meta-jupyter"? Richard: best as separate repo/layer 
rather than trying to merge it into core. Notes that some people complain about 
too many layers, but this is more a tools issue, and separate layers in general 
allow more focused maintainer-ship and growth.

* Xilinx: What about npm, devtool support? Richard: no good solution yet, no 
tests in autobuilder. Current bitbake model is one recipe per package, but npm 
is organized to have 1000+ 'packages' which is impractical for each to have a 
recipe. There was some devtool support, but may not be current.

Randy: automation can help with npm package management, but does not want npm 
manager on target.

Richard: difficult to give up control to outside manager like npm. Alejandro: 
npm starts to download its own toolchain, and we lose reproducibility. Npm for 
YP did have changes to reduce that outside behavior, not sure current state,  
concerned that Rust will have similar problem (Tim: as does Go).

Tim: Node is in core, but not tests. Issus around npm dependencies.

Alejandro: Python update cadence per release, but node changes much faster. 
Richard: use the snapshot model, where we capture logical and stable package 
sets, especially for Python and here npm. Joshua: image containers for node.js? 
Richard: that just moves the goal post, the snapshot captures "our part".

FYI: See "node.js" presentation with devtool from DevDay 2017: 
https://wiki.yoctoproject.org/wiki/File:Ypdd-2017.02-ELC-Portland.pdf

* Question: Twitch stream? Richard: conflicts with this meeting. Presentations 
are captured to YouTube, where they are getting additional views. These 
presentations focus more on new developers.

* Vineela: will release number change (3.0) affect the Poky release number? 
Richard: no, and he is not sure what uses that number anymore.

* Richard: thanks to David for supporting the meeting minutes in Stephen's 
absence.

- David

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [yocto-autobuilder-helper][PATCH]] checkvnc, run-config, config.json: DISPLAY=:1

[Thomas Goodwin]

The original check of /proc/net/tcp did not work on
a headless Ubuntu 18.04.02 server.  This new check-
-and-reset routine should be equivalent if the script
is executed.  The assumption of DISPLAY=:1 was also
troublesome in an environment where multiple VNC
servers are running.

Changes:

If the user sources this script, it will perform the
new check-and-reset function as well as set DISPLAY to
the instance found.  This means EXTRACMD on certain
builds can now be, e.g.:

   source ${SCRIPTSDIR}/checkvnc; oe-selftest ...

This change has been added to run-config and config.json.

Signed-off-by: Thomas Goodwin 
---
 config.json|  8 
 scripts/checkvnc   | 35 +--
 scripts/run-config |  2 +-
 3 files changed, 34 insertions(+), 11 deletions(-)

diff --git a/config.json b/config.json
index 2252b83..3d13720 100644
--- a/config.json
+++ b/config.json
@@ -67,7 +67,7 @@
 },
 "step3" : {
 "BUILDHISTORY" : false,
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest 
-r runqemu meta_ide -j 15"],
+"EXTRACMDS" : ["source ${SCRIPTSDIR}/checkvnc; oe-selftest -r 
runqemu meta_ide -j 15"],
 "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
 }
 },
@@ -149,7 +149,7 @@
 "EXTRACMDS" : ["bitbake-selftest"]
 },
 "step2" : {
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest 
--skip-tests distrodata.Distrodata.test_checkpkg 
buildoptions.SourceMirroring.test_yocto_source_mirror -j 15"],
+"EXTRACMDS" : ["source ${SCRIPTSDIR}/checkvnc; oe-selftest 
--skip-tests distrodata.Distrodata.test_checkpkg 
buildoptions.SourceMirroring.test_yocto_source_mirror -j 15"],
 "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
 },
 "step3" : {
@@ -166,7 +166,7 @@
 ]
 },
 "step2" : {
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest 
-r buildoptions.SourceMirroring.test_yocto_source_mirror"],
+"EXTRACMDS" : ["source ${SCRIPTSDIR}/checkvnc; oe-selftest -r 
buildoptions.SourceMirroring.test_yocto_source_mirror"],
 "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
 }
 }
@@ -280,7 +280,7 @@
 "extravars" : [
 "RPM_GPG_SIGN_CHUNK = '1'"
 ],
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest 
--skip-tests distrodata.Distrodata.test_checkpkg 
buildoptions.SourceMirroring.test_yocto_source_mirror -j 15"],
+"EXTRACMDS" : ["source ${SCRIPTSDIR}/checkvnc; oe-selftest 
--skip-tests distrodata.Distrodata.test_checkpkg 
buildoptions.SourceMirroring.test_yocto_source_mirror -j 15"],
 "ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
 }
 },
diff --git a/scripts/checkvnc b/scripts/checkvnc
index 11e03bb..3935213 100755
--- a/scripts/checkvnc
+++ b/scripts/checkvnc
@@ -1,10 +1,33 @@
 #!/bin/sh
 #
-# check if vnc server is running, and if not, cleanup and restart
+# Description: checks if vnc server is running, and if not, cleanup and restart
+# 
+# Source this file if you want DISPLAY set to the result
+# Execute this file if you only want the "check and restart" behavior.
 #
-grep ':170D' /proc/net/tcp > /dev/null
-if [ $? != 0 ]; then
-echo "Xvnc not running, attempting restart"
-vncserver -kill :1
+unset DISPLAY
+
+checkvnc() {
+for pid_file in ~/.vnc/*.pid; do
+[ -f "$pid_file" ] || break
+vnc_display=$(echo $(basename "$pid_file") | cut -f 1 -d '.')
+
+# Test if running
+kill -0 $(cat "$pid_file") > /dev/null
+if [ $? == 0 ]; then
+echo "Found running Xvnc server at $vnc_display"
+DISPLAY=":$(echo $vnc_display | cut -d ':' -f 2)"
+break
+else
+echo "Cleaning up display: $vnc_display"
+vncserver -kill "$vnc_display"
+fi
+done
+}
+
+checkvnc
+if [ -z "$DISPLAY" ]; then
+echo "Starting Xvnc"
 vncserver
-fi
+checkvnc
+fi
\ No newline at end of file
diff --git a/scripts/run-config b/scripts/run-config
index fe89163..2b39822 100755
--- a/scripts/run-config
+++ b/scripts/run-config
@@ -168,7 +168,7 @@ for stepnum in range(1, maxsteps + 1):
 sanitytargets = utils.getconfigvar("SANITYTARGETS", ourconfig, 
args.target, stepnum)
 if sanitytargets:
 hp.printheader("Step %s/%s: Running bitbake %s" % (stepnum, maxsteps, 
sanitytargets))
-bitbakecmd(args.builddir, "%s/checkvnc; DISPLAY=:1 bitbake %s -k" % 
(scriptsdir, sanitytargets), report, stepnum, 'c')
+bitbakecmd(args.builddir, "source %s/checkvnc; bitbake %s -k" % 
(scriptsdir, sanitytargets), report, stepnum, 'c')
 
 # Run any extra commands specified
 cmds = utils.getconfiglist("EXTRACMDS", ourconfig, args.target, 

[yocto] U-boot enable not working for Raspberry Pi3

[Greg Wilson-Lindberg]

I'm working with a Yocto Sumo build provided with Qt's boot2qt system. I'm 
trying to enable using Das U-boot to load Linux as a first step in trying to 
enable OSTree updates.

In the meta-raspberrypi documentation is says to set:

RPI_USE_U_BOOT = "1"

to enable u-boot for the raspberrypi. I have set that variable in the top level 
local.conf file but I don't seem to be getting any changes in the build. 
Nothing in the cooker log shows building u-boot, and the start up screen 
doesn't show any u-boot messages.

It appears that I'm missing necessary to turn u-boot on, can anybody shed some 
light on what is going on?

Regards,

Greg Wilson-Lindberg  
www.sakuraus.com
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto Project Status WW32'19

[sjolley.yp.pm]

Current Dev Position: YP 2.8 M3

Next Deadline: YP 2.8 Milestone M3 Cutoff (Feature Freeze) Aug 25, 2019

 

SWAT Team Rotation:

*   SWAT lead is currently: Ross
*   SWAT team rotation: Ross -> Amanda on Aug. 9, 2019
*   SWAT team rotation: Amanda -> Chen on Aug. 16, 2019
*
https://wiki.yoctoproject.org/wiki/Yocto_Build_Failure_Swat_Team

 

Next Team Meetings:

*   Bug Triage meeting Thursday August 8th at 7:30am PDT (
 https://zoom.us/j/454367603)
*   Monthly Project Meeting Tuesday August 6th at 8am PDT (
 https://zoom.us/j/990892712) 
*   Twitch - Next event is Tuesday August 6th at 8am PDT (
 https://www.twitch.tv/yocto_project)

 

Key Status/Updates:

*   YP 2.8 M2 is due for release this week
*   YP 2.6.3 is in QA
*   We have a new "newcomer" bug category which are bugs suited to
someone new to the project. These can be seen here:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs
*   This release which was 2.8 will now become 3.0
*   The project is working on some mentor and mentee opportunities.
Please see the separate email from Nicolas on the yocto list about this.
*   Patches to bitbake to enable the task scheduler to react to
"equivalent" build output have merged. There is more information about this
major change in a separate email:

 

http://lists.openembedded.org/pipermail/openembedded-core/2019-August/285300
.html

It is hoped this change should improve productivity and reduce rebuilds.

*   In making some of these changes, there were some API changes in
bitbake, notably the removal of the bb.build.FuncFailed exception, the
signature generator task representation changed and there were some siggen
function API changes.
*   libx11-diet was removed as its not really appropriate on a modern
locale aware system.

 

Planned Releases for YP 3.0 {2.8}:

*   M2 is out of QA and being reviewed.
*   M2 Release 26th July
*   M3 Cutoff (Feature Freeze) 25th Aug
*   M3 Release 6th Sept
*   M4 Cutoff 30th Sept - this will be YP 3.0.
*   YP 3.0 {2.8 (M4)} Final Release 25th Oct

 

Planned upcoming dot releases:

*   YP 2.7.2 (Warrior) is planned for after 2.8 M2 release.
*   YP 2.6.3 (Thud) is iin QA.

 

Tracking Metrics:

*   WDD 2481 (last week 2466) (

https://wiki.yoctoproject.org/charts/combo.html)
*   Poky Patch Metrics  

*   Total patches found: 1496 (last week 1498)
*   Patches in the Pending State: 615 (41%) [last week 619 (41%)]

 

Key Status Links for YP:

 
https://wiki.yoctoproject.org/wiki/Yocto_Project_v2.8_Status

 
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Schedule

 
https://wiki.yoctoproject.org/wiki/Yocto_2.8_Features

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Project Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [OE-core] Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am to 8:30am on the first Tuesday (PST)

[Alexander Kanavin]

On Tue, 6 Aug 2019 at 03:53,  wrote:

> Wiki: https://www.yoctoproject.org/public-virtual-meetings/
>

That page links a Google calendar, and the calendar is in many ways
mismatching what is listed on the page. Can you please re-create the
calendar?

Alex
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] [meta-security][v2][PATCH] kernel-modsign.bbclass: add support for kernel modules signing

[Armin Kuster]

From: Dmitry Eremin-Solenikov 

Add bbclass responsible for handling signing of kernel modules.

Signed-off-by: Dmitry Eremin-Solenikov 

fixup class to avoid including in every configure task

Signed-off-by: Armin Kuster 
---
 meta-integrity/classes/kernel-modsign.bbclass  | 29 ++
 meta-integrity/data/debug-keys/privkey_modsign.pem | 28 +
 meta-integrity/data/debug-keys/x509_modsign.crt| 22 
 3 files changed, 79 insertions(+)
 create mode 100644 meta-integrity/classes/kernel-modsign.bbclass
 create mode 100644 meta-integrity/data/debug-keys/privkey_modsign.pem
 create mode 100644 meta-integrity/data/debug-keys/x509_modsign.crt

diff --git a/meta-integrity/classes/kernel-modsign.bbclass 
b/meta-integrity/classes/kernel-modsign.bbclass
new file mode 100644
index 000..09025ba
--- /dev/null
+++ b/meta-integrity/classes/kernel-modsign.bbclass
@@ -0,0 +1,29 @@
+# No default! Either this or MODSIGN_PRIVKEY/MODSIGN_X509 have to be
+# set explicitly in a local.conf before activating kernel-modsign.
+# To use the insecure (because public) example keys, use
+# MODSIGN_KEY_DIR = "${INTEGRITY_BASE}/data/debug-keys"
+MODSIGN_KEY_DIR ?= "MODSIGN_KEY_DIR_NOT_SET"
+
+# Private key for modules signing. The default is okay when
+# using the example key directory.
+MODSIGN_PRIVKEY ?= "${MODSIGN_KEY_DIR}/privkey_modsign.pem"
+
+# Public part of certificates used for modules signing.
+# The default is okay when using the example key directory.
+MODSIGN_X509 ?= "${MODSIGN_KEY_DIR}/x509_modsign.crt"
+
+# If this class is enabled, disable stripping signatures from modules
+INHIBIT_PACKAGE_STRIP = "1"
+
+kernel_do_configure_prepend() {
+if [ -f "${MODSIGN_PRIVKEY}" -a -f "${MODSIGN_X509}" ]; then
+cat "${MODSIGN_PRIVKEY}" "${MODSIGN_X509}" \
+> "${B}/modsign_key.pem"
+else
+bberror "Either modsign key or certificate are invalid"
+fi
+}
+
+do_shared_workdir_append() {
+cp modsign_key.pem $kerneldir/
+}
diff --git a/meta-integrity/data/debug-keys/privkey_modsign.pem 
b/meta-integrity/data/debug-keys/privkey_modsign.pem
new file mode 100644
index 000..4cac00a
--- /dev/null
+++ b/meta-integrity/data/debug-keys/privkey_modsign.pem
@@ -0,0 +1,28 @@
+-BEGIN PRIVATE KEY-
+MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDEWsJjB2pA5Ih6
+EelXvVjwWY1ix1azMciNRNPPQN1AMXF0K/VUkfOYbaPajg1cQYEf9gk3q7OZ5Axk
+UY/e5piZORaPcsmj0lV0L+NSlRYydR5M/QxtEz26585FgqRGdAe6umStPmVKdqa2
+d68O4PgQgJJtVuz6ndm+0uNEUDCVLwhkGQSwNB3qBbZAUX9escZ/a8eUiBfMYKaO
+k8JRyM+2br9dgpTFg4UfBYexgNSQo8g5TIBGc8KgQiKCuFj1fQEhV5z4RusHthjc
+NYXa3RHmdclxyrGeYr5ZRc47HqE1gd5NDR0WeHn4C4YKcfK1rZZz/2+6hfsIRfGx
+6cQKk23hAgMBAAECggEAJ0ULiWirPG04SkmYxF5vEiqm1zGMymvTc0VnoxSS60q4
+KQa9mvtRn5OV6JjuXRwQqga30zV4xvdP7yRMxMSTkllThL7tSuE/C+yj5xlABjlc
+JQOa35mwh9fibg5xslF0Vkj+55MKCPlv4CBRl4Uwt4QvRMTUwk6dhMeCgmATR1J1
+2/7AipjtfFYreDx7sLbRVvSzUhmZS0iCbNOhtTWPLNW+9YKHTOffKa04HzNtnAXq
+OjJ0IRZD/C6LfkBUsnHg2eEiA97QXh/Srsl9nc8DaUK1IXRywEdmYIoNMWMav2Hm
+RO8kkU30BqKW+/EO2ZbH2GmkxvwWd0ocBnLC3FRWEQKBgQDu4T8CB3YsOcVjqem4
+iBlaSht/b46YQc7A1SOqZCimehmmXNSxQOkapIG3wlIr5edtXQA+xv09+WrproUB
+SjAnqaH6pYeCvbNlY5k344gtYs+Kco2rq5GYa+LumAeX2Sam8F7u4LxvEogCecX7
+e4rnG3lt3AVuuRE7zpCQtaWcJQKBgQDSbUvea9pcYli9pssTl+ijQKkgG9DdaYbA
+I5w5bY1TPYZ/Ocysljefv/ssaHFh4DPxE1MQ5JHwZgZRo1EICxxYzGsLjyR/fmjz
+1c/NJlTtalCNtLvWaf7b02ag/abnP8neiSpLL5xqHvGo5ikWwgYQD+9HVKGvL3S1
+kI7x/ziADQKBgQCqFbkuMa/jh3LTJp0iZc1fa1qu3vhx0pFq3Zeab9w9xLxUps5O
+MwCGltFBzNuDJBwm00wkZrzTjq6gGkHbjD5DT1XkyE13OqjsLQFgOOKyJiPN2Qik
+TfHJzC91YMwvQ09xF78QaPXiRBiRYrEkAXACY56PKVS45I6vvcFTN/Ll/QKBgA9m
+KDMyuVwhZlUaq6nXaBLqXHYZEwPhARd2g6xANCNvUTRmSnAm3hM2vW7WhdWfzq1J
+uL53u6ZYEQZQaVGpXn2xF/RUmVsrKQsPDpH4yCZHrXVxUH20bA4yPkRxy5EIvgEn
+EI1IAq5RbWXq0f70W/U49U3HB74GPwg6d/uFreDRAoGAN+v9gMQA6A1vM7LvbYR8
+5CwwyqS/CfI9zKPLn53QstguXC/ObafIYQzVRqGb9lCQgtlmmKw4jMY0B/lDzpcH
+zS8rqoyvDj/m7i17NYkqXErJKLRQ0ptXKdLXHlG0u185e7Y5p4O3Z5dk8bACkpHi
+hp764y+BtU4qIcVaPsPK4uU=
+-END PRIVATE KEY-
diff --git a/meta-integrity/data/debug-keys/x509_modsign.crt 
b/meta-integrity/data/debug-keys/x509_modsign.crt
new file mode 100644
index 000..5fa2a90
--- /dev/null
+++ b/meta-integrity/data/debug-keys/x509_modsign.crt
@@ -0,0 +1,22 @@
+-BEGIN CERTIFICATE-
+MIIDnjCCAoagAwIBAgIUUqmBj5Q8edHMMTXsoGVGEEKdwV4wDQYJKoZIhvcNAQEL
+BQAwZzEqMCgGA1UEAxMhbWV0YS1zZWN1cml0eSBtb2R1bGVzIHNpZ25pbmcga2V5
+MRQwEgYDVQQKEwtleGFtcGxlLmNvbTEjMCEGCSqGSIb3DQEJARYUam9obi5kb2VA
+ZXhhbXBsZS5jb20wIBcNMTkwNzI3MjIzOTA3WhgPMjExOTA3MjcyMjM5MTVaMGcx
+KjAoBgNVBAMTIW1ldGEtc2VjdXJpdHkgbW9kdWxlcyBzaWduaW5nIGtleTEUMBIG
+A1UEChMLZXhhbXBsZS5jb20xIzAhBgkqhkiG9w0BCQEWFGpvaG4uZG9lQGV4YW1w
+bGUuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxFrCYwdqQOSI
+ehHpV71Y8FmNYsdWszHIjUTTz0DdQDFxdCv1VJHzmG2j2o4NXEGBH/YJN6uzmeQM
+ZFGP3uaYmTkWj3LJo9JVdC/jUpUWMnUeTP0MbRM9uufORYKkRnQHurpkrT5lSnam
+tnevDuD4EICSbVbs+p3ZvtLjRFAwlS8IZBkEsDQd6gW2QFF/XrHGf2vHlIgXzGCm

[yocto] -staticdev packages not in sdk

[Koeller, Thomas]

Hi,

browsing the list archives I came across an older thread that exactly describes 
the problem I am currently struggling with:

https://lists.yoctoproject.org/pipermail/yocto/2018-February/039950.html

In short, I have a recipe that produces only a couple of header files and a 
single static library, nothing to be installed on the target. So the base 
package is empty, which is why I have 'ALLOW_EMPTY_${PN} = "1"' in its recipe. 
In my image definition I have 'SDKIMAGE_FEATURES_append = " staticdev-pkgs"', 
so I expect the -staticdev package to be included when generating the SDK. This 
is, however, not the case. While a large number of -staticdev packages from 
different recipes is now included in the SDK, only the -dev package is included 
for my recipe, not the -staticdev (though the corresponding rpm is actually 
built and contains the library as expected, it just is not installed).

The archived mail thread referenced above suggests adding the base package 
${PN} to IMAGE_INSTALL, which indeed does work for me. However, I do not 
understand why this is necessary at all, as my package is already referenced 
from another recipe by being listed in that recipe's DEPENDS variable, 
shouldn't that be enough? Also, the -dev package gets installed into the SDK 
even without such cruft. As far as I can see, identical logic is applied to 
both -dev and -staticdev packages, so what is the difference?

I also found a different workaround for the problem: listing the -staticdev 
package in TOOLCHAIN_TARGET_TASK. Needless to say, this workaround is just as 
undesirable as the former one.

I am using the sumo branch.

Thomas


Thomas Koeller
Senior Software Developer


Basler AG
An der Strusbek 60-62
22926 Ahrensburg
Germany

Tel. +49 4102 463 390
Fax +49 4102 463 46 390


thomas.koel...@baslerweb.com
www.baslerweb.com

Management board: Dr.-Ing. Dietmar Ley (CEO) · John P. Jennings · Arndt Bake · 
Hardy Mehl
Chairman of the supervisory board: Norbert Basler
Basler AG · Amtsgericht Lübeck HRB 4090 · Ust-IdNr.: DE 135 098 121 · 
Steuer-Nr.: 30 292 04497 · WEEE-Reg.-Nr. DE 83888045
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Replace busybox by bash

[Ross Burton]

On 06/08/2019 13:34, JH wrote:

The busybox is too simple, my application heavy based on shell
scripts, I have been thinking to dig out the busybox and replace it by
bash, has anyone remove the busybox to use bash as default shell? How
large size will be increased and what will be any side effect?


Removing busybox is not trivial, but you can just install 
bash/coreutils/etc as required.


Yes it's bigger, but you want the full tools.  No side effects.

Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-integrity] layer.conf: switch to keyutils from meta-oe

[akuster808]

On 8/6/19 6:54 AM, Dmitry Eremin-Solenikov wrote:
> пн, 29 июл. 2019 г. в 13:45, :
>> From: Dmitry Eremin-Solenikov 
>>
>> As pointer by Martin Jansa, keyutils package is now a part of meta-oe,
>> so switch to using keyutils from that layer.
>>
>> Signed-off-by: Dmitry Eremin-Solenikov 
> This patch is still necessary.

ah, forgot that one. thanks.

- armin
>

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [meta-integrity] layer.conf: switch to keyutils from meta-oe

[Dmitry Eremin-Solenikov]

пн, 29 июл. 2019 г. в 13:45, :
>
> From: Dmitry Eremin-Solenikov 
>
> As pointer by Martin Jansa, keyutils package is now a part of meta-oe,
> so switch to using keyutils from that layer.
>
> Signed-off-by: Dmitry Eremin-Solenikov 

This patch is still necessary.

-- 
With best wishes
Dmitry
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[Alexander Kanavin]

The right way out of this is to fix the issue: your main package depends on
the -dev package, and so will always pull it into the target image. I am
not telling you how to disable the check, as you're merely hiding a bug
that way :)

If you provide ls -lR of ${D}, we might be able to understand what happens.

Alex

On Tue, 6 Aug 2019 at 14:45, JH  wrote:

> Thanks Alex, here is the error in my application build, it used working
> well:
>
> ERROR: app_library-1.0.0-0 do_package_qa: QA Issue: app_library
> rdepends on app_library-dev [dev-deps]
> ERROR: app_library-1.0.0-0 do_package_qa: QA run found fatal errors.
> Please consider fixing them.
> ERROR: app_library-1.0.0-0 do_package_qa: Function failed: do_package_qa
> ERROR: Logfile of failure stored in:
>
> /home/build/tmp-glibc/work/cortexa7t2hf-neon-oe-linux-gnueabi/app_library/1.0.0-0/temp/log.do_package_qa.6626
> ERROR: Task
> (/home/build/oe-core/../meta-app/recipes-core/app_library/app_library_git.bb:
> do_package_qa)
> failed with exit code '1'
>
> There is no do_package_qa in my app_library_git.bb, where is that
> do_package_qa from? how can I disable it? It sounds every easy in the
> document to disable it, but it did not give any clues -:(.
>
> Thank you.
>
> Kind regards,
>
> - jh
> On 8/6/19, Alexander Kanavin  wrote:
> > It may help if you copy-paste the exact error you are getting, and the
> > content of the directory where it happens.
> >
> > Alex
> >
> > On Tue, 6 Aug 2019 at 13:09, JH  wrote:
> >
> >> On 8/6/19, Alexander Kanavin  wrote:
> >> > You don't; package_qa is reporting real issues with your packaging, so
> >> you
> >> > need to address them.
> >>
> >> Well, my first issue is I need to build it, the document said it can
> >> be disabled, but did not say how, appreciate anyone helps how to
> >> disable it.
> >>
> >> Thank you
> >>
> >>
> >> > Alex
> >> >
> >> > On Tue, 6 Aug 2019 at 10:40, JH  wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> According to the latest document:
> >> >>
> >> >> "Package QA checks are now performed during a new do_package_qa task
> >> >> rather than being part of the do_package task. This allows more
> >> >> parallel execution. This change is unlikely to be an issue except for
> >> >> highly customized recipes that disable packaging tasks themselves by
> >> >> marking them as noexec. For those packages, you will need to disable
> >> >> the do_package_qa task as well."
> >> >>
> >> >> How can I disable the do_package_qa task?
> >> >>
> >> >> Thank you.
> >> >>
> >> >> Kind regards,
> >> >>
> >> >> - jh
> >> >>
> >> >> On 8/4/19, JH  wrote:
> >> >> > Hi,
> >> >> >
> >> >> > I was running my Yocto build fine until I had a minor change to
> move
> >> >> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so
> >> >> > to
> >> >> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
> >> >> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
> >> >> > errors, please consider fixing them.
> >> >> >
> >> >> > Even I reverse the changes back the, it still complained the same
> >> >> > error.
> >> >> >
> >> >> > I don't have do_package_qa in my bb file, where is it from? What is
> >> >> > that error about? How to fix it?
> >> >> >
> >> >> > Thank you.
> >> >> >
> >> >> > Kind regards,
> >> >> >
> >> >> > - jh
> >> >> >
> >> >> --
> >> >> ___
> >> >> yocto mailing list
> >> >> yocto@yoctoproject.org
> >> >> https://lists.yoctoproject.org/listinfo/yocto
> >> >>
> >> >
> >>
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Loading a Yocto kernel on Hyper-V hangs

[Yair Itzhaki]

Great tip!
Found this list to work for me (though I'm not sure it's all needed):

CONFIG_HYPERVISOR_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_SPINLOCKS=y
CONFIG_CONNECTOR=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_HYPERV=y
CONFIG_HYPERV_UTILS=y
CONFIG_HYPERV_BALLOON=y
CONFIG_HYPERV_STORAGE=y
CONFIG_HYPERV_NET=y
CONFIG_HYPERV_KEYBOARD=y
CONFIG_FB_HYPERV=y
CONFIG_HID_HYPERV_MOUSE=y
CONFIG_PCI_HYPERV=y
CONFIG_VSOCKETS=y
CONFIG_HYPERV_VSOCKETS=y


Thanks!
Yair


From: Ang, Chin Huat 
Sent: Tuesday, August 6, 2019 12:07
To: Yair Itzhaki ; yocto@yoctoproject.org
Subject: RE: Loading a Yocto kernel on Hyper-V hangs

On master, using genericx86-64 machine with linux-yocto kernel I also see grub 
booted into a blank screen when none of the Hyper-V kernel configs are enabled.

I couldn’t find any Hyper-V kernel config fragments in yocto-kernel-cache or 
meta-virtualization, so I googled for “hyper-v kernel config” and used a trick 
[1] to apply the necessary kernel configs to get both core-image-minimal and 
core-image-sato boot up properly.

[1] https://wiki.yoctoproject.org/wiki/TipsAndTricks/QuickAndDirtyKernelConfig

--Chin Huat

From: yocto-boun...@yoctoproject.org 
mailto:yocto-boun...@yoctoproject.org>> On 
Behalf Of Yair Itzhaki
Sent: Monday, August 5, 2019 11:41 PM
To: yocto@yoctoproject.org
Subject: [yocto] Loading a Yocto kernel on Hyper-V hangs

Hi ,
I'm using Poky (Warrior).
Built a Plain Vanilla system for bare-metal x64, and put it on a hard-drive.
The system boots well on an Intel MB.

Then, added a WIC image target, and converted the disk iamge (using qemu-img) 
into a VMDK.
The image boots well (Grub prompt, followed by kernel loading) on a Windows 
VmWare (though I had to add some kernel features to make the root FS available).

Next, I converted the same image to VHDX using qemu-img.
Configured a HyperV Gen2 machine (to use UEFI). Security is turned off.
Grub2 loads well:
I get a Grub prompt, select the kernel – but once selected - the system hangs.
Tried on different Windows machine (Win10, Server 2016)

When replacing the kernel with a stock Ubuntu kernel – the kernel loads well.
Tried other (pre-built) kernels from 
http://downloads.yoctoproject.org/releases/yocto/yocto-x.y/ – same odd 
behavior: Grub loads, kernel does not load.
Tried a different compression (other than gzip) – same.

Any idea?

Thanks,
Yair


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[JH]

Thanks Alex, here is the error in my application build, it used working well:

ERROR: app_library-1.0.0-0 do_package_qa: QA Issue: app_library
rdepends on app_library-dev [dev-deps]
ERROR: app_library-1.0.0-0 do_package_qa: QA run found fatal errors.
Please consider fixing them.
ERROR: app_library-1.0.0-0 do_package_qa: Function failed: do_package_qa
ERROR: Logfile of failure stored in:
/home/build/tmp-glibc/work/cortexa7t2hf-neon-oe-linux-gnueabi/app_library/1.0.0-0/temp/log.do_package_qa.6626
ERROR: Task 
(/home/build/oe-core/../meta-app/recipes-core/app_library/app_library_git.bb:do_package_qa)
failed with exit code '1'

There is no do_package_qa in my app_library_git.bb, where is that
do_package_qa from? how can I disable it? It sounds every easy in the
document to disable it, but it did not give any clues -:(.

Thank you.

Kind regards,

- jh
On 8/6/19, Alexander Kanavin  wrote:
> It may help if you copy-paste the exact error you are getting, and the
> content of the directory where it happens.
>
> Alex
>
> On Tue, 6 Aug 2019 at 13:09, JH  wrote:
>
>> On 8/6/19, Alexander Kanavin  wrote:
>> > You don't; package_qa is reporting real issues with your packaging, so
>> you
>> > need to address them.
>>
>> Well, my first issue is I need to build it, the document said it can
>> be disabled, but did not say how, appreciate anyone helps how to
>> disable it.
>>
>> Thank you
>>
>>
>> > Alex
>> >
>> > On Tue, 6 Aug 2019 at 10:40, JH  wrote:
>> >
>> >> Hi,
>> >>
>> >> According to the latest document:
>> >>
>> >> "Package QA checks are now performed during a new do_package_qa task
>> >> rather than being part of the do_package task. This allows more
>> >> parallel execution. This change is unlikely to be an issue except for
>> >> highly customized recipes that disable packaging tasks themselves by
>> >> marking them as noexec. For those packages, you will need to disable
>> >> the do_package_qa task as well."
>> >>
>> >> How can I disable the do_package_qa task?
>> >>
>> >> Thank you.
>> >>
>> >> Kind regards,
>> >>
>> >> - jh
>> >>
>> >> On 8/4/19, JH  wrote:
>> >> > Hi,
>> >> >
>> >> > I was running my Yocto build fine until I had a minor change to move
>> >> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so
>> >> > to
>> >> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
>> >> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
>> >> > errors, please consider fixing them.
>> >> >
>> >> > Even I reverse the changes back the, it still complained the same
>> >> > error.
>> >> >
>> >> > I don't have do_package_qa in my bb file, where is it from? What is
>> >> > that error about? How to fix it?
>> >> >
>> >> > Thank you.
>> >> >
>> >> > Kind regards,
>> >> >
>> >> > - jh
>> >> >
>> >> --
>> >> ___
>> >> yocto mailing list
>> >> yocto@yoctoproject.org
>> >> https://lists.yoctoproject.org/listinfo/yocto
>> >>
>> >
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Replace busybox by bash

[JH]

Hi,

The busybox is too simple, my application heavy based on shell
scripts, I have been thinking to dig out the busybox and replace it by
bash, has anyone remove the busybox to use bash as default shell? How
large size will be increased and what will be any side effect?

Thank you.

Kind regards,

- jh
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[Alexander Kanavin]

It may help if you copy-paste the exact error you are getting, and the
content of the directory where it happens.

Alex

On Tue, 6 Aug 2019 at 13:09, JH  wrote:

> On 8/6/19, Alexander Kanavin  wrote:
> > You don't; package_qa is reporting real issues with your packaging, so
> you
> > need to address them.
>
> Well, my first issue is I need to build it, the document said it can
> be disabled, but did not say how, appreciate anyone helps how to
> disable it.
>
> Thank you
>
>
> > Alex
> >
> > On Tue, 6 Aug 2019 at 10:40, JH  wrote:
> >
> >> Hi,
> >>
> >> According to the latest document:
> >>
> >> "Package QA checks are now performed during a new do_package_qa task
> >> rather than being part of the do_package task. This allows more
> >> parallel execution. This change is unlikely to be an issue except for
> >> highly customized recipes that disable packaging tasks themselves by
> >> marking them as noexec. For those packages, you will need to disable
> >> the do_package_qa task as well."
> >>
> >> How can I disable the do_package_qa task?
> >>
> >> Thank you.
> >>
> >> Kind regards,
> >>
> >> - jh
> >>
> >> On 8/4/19, JH  wrote:
> >> > Hi,
> >> >
> >> > I was running my Yocto build fine until I had a minor change to move
> >> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so to
> >> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
> >> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
> >> > errors, please consider fixing them.
> >> >
> >> > Even I reverse the changes back the, it still complained the same
> >> > error.
> >> >
> >> > I don't have do_package_qa in my bb file, where is it from? What is
> >> > that error about? How to fix it?
> >> >
> >> > Thank you.
> >> >
> >> > Kind regards,
> >> >
> >> > - jh
> >> >
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[JH]

On 8/6/19, Alexander Kanavin  wrote:
> You don't; package_qa is reporting real issues with your packaging, so you
> need to address them.

Well, my first issue is I need to build it, the document said it can
be disabled, but did not say how, appreciate anyone helps how to
disable it.

Thank you


> Alex
>
> On Tue, 6 Aug 2019 at 10:40, JH  wrote:
>
>> Hi,
>>
>> According to the latest document:
>>
>> "Package QA checks are now performed during a new do_package_qa task
>> rather than being part of the do_package task. This allows more
>> parallel execution. This change is unlikely to be an issue except for
>> highly customized recipes that disable packaging tasks themselves by
>> marking them as noexec. For those packages, you will need to disable
>> the do_package_qa task as well."
>>
>> How can I disable the do_package_qa task?
>>
>> Thank you.
>>
>> Kind regards,
>>
>> - jh
>>
>> On 8/4/19, JH  wrote:
>> > Hi,
>> >
>> > I was running my Yocto build fine until I had a minor change to move
>> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so to
>> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
>> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
>> > errors, please consider fixing them.
>> >
>> > Even I reverse the changes back the, it still complained the same
>> > error.
>> >
>> > I don't have do_package_qa in my bb file, where is it from? What is
>> > that error about? How to fix it?
>> >
>> > Thank you.
>> >
>> > Kind regards,
>> >
>> > - jh
>> >
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[Alexander Kanavin]

You don't; package_qa is reporting real issues with your packaging, so you
need to address them.

Alex

On Tue, 6 Aug 2019 at 10:40, JH  wrote:

> Hi,
>
> According to the latest document:
>
> "Package QA checks are now performed during a new do_package_qa task
> rather than being part of the do_package task. This allows more
> parallel execution. This change is unlikely to be an issue except for
> highly customized recipes that disable packaging tasks themselves by
> marking them as noexec. For those packages, you will need to disable
> the do_package_qa task as well."
>
> How can I disable the do_package_qa task?
>
> Thank you.
>
> Kind regards,
>
> - jh
>
> On 8/4/19, JH  wrote:
> > Hi,
> >
> > I was running my Yocto build fine until I had a minor change to move
> > libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so to
> > a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
> > issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
> > errors, please consider fixing them.
> >
> > Even I reverse the changes back the, it still complained the same error.
> >
> > I don't have do_package_qa in my bb file, where is it from? What is
> > that error about? How to fix it?
> >
> > Thank you.
> >
> > Kind regards,
> >
> > - jh
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[linux-yocto] [PATCH] nfsd4: Fix kernel crash when reading proc file reply_cache_stats

[zhe.he]

From: He Zhe 

reply_cache_stats uses wrong parameter as seq file private structure and
thus causes the following kernel crash when users read
/proc/fs/nfsd/reply_cache_stats

BUG: kernel NULL pointer dereference, address: 01f9
PGD 0 P4D 0
Oops:  [#3] SMP PTI
CPU: 6 PID: 1502 Comm: cat Tainted: G  D   5.3.0-rc3+ #1
Hardware name: Intel Corporation Broadwell Client platform/Basking Ridge, BIOS 
BDW-E2R1.86C.0118.R01.1503110618 03/11/2015
RIP: 0010:nfsd_reply_cache_stats_show+0x3b/0x2d0
Code: 41 54 49 89 f4 48 89 fe 48 c7 c7 b3 10 33 88 53 bb e8 03 00 00 e8 88 82 
d1 ff bf 58 89 41 00 e8 eb c5 85 00 48 83 eb 01 75 f0 <41> 8b 94 24 f8 01 00 00 
48 c7 c6 be 10 33 88 4c 89 ef bb e8 03 00
RSP: 0018:aa520106fe08 EFLAGS: 00010246
RAX: 00cfe1a77123 RBX:  RCX: 00291b46
RDX: 00cf RSI: 0006 RDI: 00291b28
RBP: aa520106fe20 R08: 0006 R09: 00cfe17e55dd
R10: a424e47c R11: 030b R12: 0001
R13: a424e5697000 R14: 0001 R15: a424e5697000
FS:  7f805735f580() GS:a424f8f8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 01f9 CR3: 655ce005 CR4: 003606e0
Call Trace:
 seq_read+0x194/0x3e0
 __vfs_read+0x1b/0x40
 vfs_read+0x95/0x140
 ksys_read+0x61/0xe0
 __x64_sys_read+0x1a/0x20
 do_syscall_64+0x4d/0x120
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x7f805728b861
Code: fe ff ff 50 48 8d 3d 86 b4 09 00 e8 79 e0 01 00 66 0f 1f 84 00 00 00 00 
00 48 8d 05 d9 19 0d 00 8b 00 85 c0 75 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 57 
c3 66 0f 1f 44 00 00 48 83 ec 28 48 89 54
RSP: 002b:7ffea1ce3c38 EFLAGS: 0246 ORIG_RAX: 
RAX: ffda RBX: 0002 RCX: 7f805728b861
RDX: 0002 RSI: 7f8057183000 RDI: 0003
RBP: 7f8057183000 R08: 7f8057182010 R09: 
R10: 0022 R11: 0246 R12: 559a60e8ff10
R13: 0003 R14: 0002 R15: 0002
Modules linked in:
CR2: 01f9
---[ end trace 01613595153f0cba ]---
RIP: 0010:nfsd_reply_cache_stats_show+0x3b/0x2d0
Code: 41 54 49 89 f4 48 89 fe 48 c7 c7 b3 10 33 88 53 bb e8 03 00 00 e8 88 82 
d1 ff bf 58 89 41 00 e8 eb c5 85 00 48 83 eb 01 75 f0 <41> 8b 94 24 f8 01 00 00 
48 c7 c6 be 10 33 88 4c 89 ef bb e8 03 00
RSP: 0018:aa52004b3e08 EFLAGS: 00010246
RAX: 002bab45a7c6 RBX:  RCX: 00291b4c
RDX: 002b RSI: 0004 RDI: 00291b28
RBP: aa52004b3e20 R08: 0004 R09: 002bab1c8c7a
R10: a424e550 R11: 02a9 R12: 0001
R13: a424e4475000 R14: 0001 R15: a424e4475000
FS:  7f805735f580() GS:a424f8f8() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 01f9 CR3: 655ce005 CR4: 003606e0
Killed

Fixes: 3ba75830ce17 ("nfsd4: drc containerization")
Signed-off-by: He Zhe 
---
This is for all branches and has also been sent to mainline.
Please consider if it's worth merging in linux-yocto-dev for this moment.
Thanks.

 fs/nfsd/nfscache.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/nfsd/nfscache.c b/fs/nfsd/nfscache.c
index 26ad75a..96352ab 100644
--- a/fs/nfsd/nfscache.c
+++ b/fs/nfsd/nfscache.c
@@ -571,7 +571,7 @@ nfsd_cache_append(struct svc_rqst *rqstp, struct kvec *data)
  */
 static int nfsd_reply_cache_stats_show(struct seq_file *m, void *v)
 {
-   struct nfsd_net *nn = v;
+   struct nfsd_net *nn = m->private;
 
seq_printf(m, "max entries:   %u\n", nn->max_drc_entries);
seq_printf(m, "num entries:   %u\n",
-- 
2.7.4

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PATCH 1/1] ti-am335x: add the basic scc/cfg enablement

[Jun Miao]

Add scc/cfg kernel fragment to build and boot EVM/SK and BeagleBone Black
boards all with am335x soc

Signed-off-by: Jun Miao 
---
 bsp/ti-am335x/ti-am335x-standard.scc |   8 +
 bsp/ti-am335x/ti-am335x.cfg  | 242 +++
 bsp/ti-am335x/ti-am335x.scc  |   7 +
 3 files changed, 257 insertions(+)
 create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
 create mode 100644 bsp/ti-am335x/ti-am335x.cfg
 create mode 100644 bsp/ti-am335x/ti-am335x.scc

diff --git a/bsp/ti-am335x/ti-am335x-standard.scc 
b/bsp/ti-am335x/ti-am335x-standard.scc
new file mode 100644
index ..d357a729
--- /dev/null
+++ b/bsp/ti-am335x/ti-am335x-standard.scc
@@ -0,0 +1,8 @@
+define KMACHINE ti-am335x
+define KTYPE standard
+define KARCH arm64
+
+include ktypes/standard/standard.scc
+branch ti-am335x
+
+include ti-am335x.scc
diff --git a/bsp/ti-am335x/ti-am335x.cfg b/bsp/ti-am335x/ti-am335x.cfg
new file mode 100644
index ..bb5b6653
--- /dev/null
+++ b/bsp/ti-am335x/ti-am335x.cfg
@@ -0,0 +1,242 @@
+#.
+#WARNING
+#
+# This file is a kernel configuration fragment, and not a full kernel
+# configuration file.  The final kernel configuration is made up of
+# an assembly of processed fragments, each of which is designed to
+# capture a specific part of the final configuration (e.g. platform
+# configuration, feature configuration, and board specific hardware
+# configuration).  For more information on kernel configuration, please
+# consult the product documentation.
+#
+#.
+
+CONFIG_ARM=y
+CONFIG_ARCH_OMAP=y
+CONFIG_OMAP_DM_TIMER=y
+CONFIG_SOC_AM33XX=y
+CONFIG_ARCH_OMAP2PLUS=y
+
+
+#
+# At least one emulation must be selected
+#
+CONFIG_VFP=y
+CONFIG_VFPv3=y
+CONFIG_NEON=y
+
+#
+# Power management options
+#
+
+CONFIG_PM=y
+CONFIG_REGMAP_IRQ=y
+
+#
+# RAM/ROM/Flash chip drivers
+#
+CONFIG_OMAP_OCP2SCP=y
+CONFIG_MTD=y
+CONFIG_MTD_CMDLINE_PARTS=y
+CONFIG_MTD_BLKDEVS=y
+CONFIG_MTD_BLOCK=y
+CONFIG_MTD_NAND_ECC=y
+CONFIG_MTD_RAW_NAND=y
+CONFIG_MTD_CFI=y
+CONFIG_MTD_CFI_INTELEXT=y
+
+CONFIG_MTD_NAND=y
+CONFIG_MTD_NAND_OMAP2=y
+CONFIG_MTD_NAND_OMAP_BCH=y
+CONFIG_MTD_NAND_OMAP_BCH_BUILD=y
+
+# Misc devices
+CONFIG_EEPROM_AT24=y
+CONFIG_SENSORS_LIS3_I2C=y
+CONFIG_BLK_DEV_SD=y
+
+CONFIG_ETHERNET=y
+CONFIG_NET_VENDOR_TI=y
+CONFIG_TI_DAVINCI_MDIO=y
+CONFIG_TI_DAVINCI_CPDMA=y
+CONFIG_TI_CPSW_PHY_SEL=y
+CONFIG_TI_CPSW_ALE=y
+CONFIG_TI_CPSW=y
+CONFIG_TI_CPTS=y
+CONFIG_PHYLIB=y
+
+CONFIG_SMSC_PHY=y
+CONFIG_FIXED_PHY=y
+
+#
+# Input Device Drivers
+#
+
+CONFIG_INPUT=y
+CONFIG_INPUT_MOUSEDEV=y
+CONFIG_INPUT_EVDEV=y
+CONFIG_INPUT_KEYBOARD=y
+CONFIG_KEYBOARD_GPIO=y
+CONFIG_KEYBOARD_MATRIX=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_TOUCHSCREEN_TI_AM335X_TSC=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_TPS65218_PWRBUTTON=m
+CONFIG_SERIAL_EARLYCON=y
+
+#
+# 8250 serial port support
+#
+
+CONFIG_SERIAL_8250=y
+CONFIG_SERIAL_8250_CONSOLE=y
+CONFIG_SERIAL_OF_PLATFORM=y
+CONFIG_SERIAL_8250_OMAP=y
+CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y
+
+CONFIG_SERIAL_CORE=y
+CONFIG_SERIAL_CORE_CONSOLE=y
+
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_OMAP=y
+
+# I2C support
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_I2C_OMAP=y
+CONFIG_SENSORS_TSL2550=y
+CONFIG_GPIO_TWL4030=y
+CONFIG_PTP_1588_CLOCK=y
+CONFIG_GPIO_PCF857X=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_SINGLE=y
+
+CONFIG_GPIOLIB=y
+CONFIG_OF_GPIO=y
+CONFIG_GPIOLIB_IRQCHIP=y
+CONFIG_GPIO_SYSFS=y
+
+CONFIG_GPIO_OMAP=y
+CONFIG_GPIO_PCA953X=m
+CONFIG_GPIO_TPS65910=y
+
+CONFIG_WATCHDOG=y
+CONFIG_WATCHDOG_CORE=y
+CONFIG_OMAP_WATCHDOG=m
+
+CONFIG_MFD_SYSCON=y
+CONFIG_MFD_TI_AM335X_TSCADC=y
+CONFIG_MFD_OMAP_USB_HOST=y
+CONFIG_MFD_TPS65217=y
+CONFIG_MFD_TPS65218=y
+CONFIG_MFD_TPS65910=y
+CONFIG_TWL6040_CORE=y
+
+#
+# LCD
+#
+CONFIG_DRM=y
+CONFIG_DRM_OMAP=y
+CONFIG_OMAP2_DSS_DPI=y
+CONFIG_DRM_TILCDC=y
+CONFIG_DRM_OMAP_PANEL_DPI=y
+CONFIG_DRM_I2C_NXP_TDA998X=y
+
+CONFIG_BACKLIGHT_LCD_SUPPORT=y
+CONFIG_LCD_CLASS_DEVICE=y
+CONFIG_LCD_PLATFORM=y
+CONFIG_BACKLIGHT_CLASS_DEVICE=y
+CONFIG_BACKLIGHT_GENERIC=y
+CONFIG_PWM=y
+CONFIG_BACKLIGHT_PWM=y
+CONFIG_BACKLIGHT_GPIO=y
+
+
+CONFIG_SOUND=m
+CONFIG_SND=m
+CONFIG_SND_SOC=m
+CONFIG_SND_DAVINCI_SOC_MCASP=m
+CONFIG_SND_SIMPLE_CARD=m
+
+
+#CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+#CONFIG_USB_MON=m
+
+#
+# USB Host Controller Drivers
+#
+CONFIG_USB=y
+CONFIG_USB_SUPPORT=y
+
+CONFIG_USB_EHCI_HCD=m
+CONFIG_USB_EHCI_TT_NEWSCHED=y
+CONFIG_USB_EHCI_HCD_OMAP=m
+CONFIG_USB_MUSB_HDRC=m
+
+#
+# USB Physical Layer drivers Peripheral Controller
+#
+CONFIG_USB_PHY=y
+CONFIG_NOP_USB_XCEIV=m
+CONFIG_AM335X_CONTROL_USB=m
+CONFIG_AM335X_PHY_USB=m
+
+# Platform Glue Layer
+CONFIG_USB_MUSB_DSPS=m
+CONFIG_USB_MUSB_AM335X_CHILD=m
+
+# MUSB DMA mode
+CONFIG_USB_TI_CPPI41_DMA=y
+
+
+#
+# MMC/SD/SDIO Card Drivers
+#
+CONFIG_MMC=y
+CONFIG_MMC_UNSAFE_RESUME=y
+CONFIG_MMC_BLOCK=y
+CONFIG_MMC_BLOCK_MINORS=8
+CONFIG_MMC_BLOCK_BOUNCE=y
+

[linux-yocto] [kernel-cache master]: ti-am335x

[Jun Miao]

Hi Bruce,
 
I am working ti boards(AM335x evm/sk/BBB) with am335x soc.

1.This patch add scc/cfg to yocto-kernel-cache master branch.
2.Could you help me build a new branch "ti-am335x" in linux-yocto-dev?

Thanks 



Jun Miao (1):
  ti-am335x: add the basic scc/cfg enablement

 bsp/ti-am335x/ti-am335x-standard.scc |   8 +
 bsp/ti-am335x/ti-am335x.cfg  | 242 +++
 bsp/ti-am335x/ti-am335x.scc  |   7 +
 3 files changed, 257 insertions(+)
 create mode 100644 bsp/ti-am335x/ti-am335x-standard.scc
 create mode 100644 bsp/ti-am335x/ti-am335x.cfg
 create mode 100644 bsp/ti-am335x/ti-am335x.scc

-- 
2.22.0

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

Re: [yocto] Loading a Yocto kernel on Hyper-V hangs

[Ang, Chin Huat]

On master, using genericx86-64 machine with linux-yocto kernel I also see grub 
booted into a blank screen when none of the Hyper-V kernel configs are enabled.

I couldn’t find any Hyper-V kernel config fragments in yocto-kernel-cache or 
meta-virtualization, so I googled for “hyper-v kernel config” and used a trick 
[1] to apply the necessary kernel configs to get both core-image-minimal and 
core-image-sato boot up properly.

[1] https://wiki.yoctoproject.org/wiki/TipsAndTricks/QuickAndDirtyKernelConfig

--Chin Huat

From: yocto-boun...@yoctoproject.org  On Behalf 
Of Yair Itzhaki
Sent: Monday, August 5, 2019 11:41 PM
To: yocto@yoctoproject.org
Subject: [yocto] Loading a Yocto kernel on Hyper-V hangs

Hi ,
I'm using Poky (Warrior).
Built a Plain Vanilla system for bare-metal x64, and put it on a hard-drive.
The system boots well on an Intel MB.

Then, added a WIC image target, and converted the disk iamge (using qemu-img) 
into a VMDK.
The image boots well (Grub prompt, followed by kernel loading) on a Windows 
VmWare (though I had to add some kernel features to make the root FS available).

Next, I converted the same image to VHDX using qemu-img.
Configured a HyperV Gen2 machine (to use UEFI). Security is turned off.
Grub2 loads well:
I get a Grub prompt, select the kernel – but once selected - the system hangs.
Tried on different Windows machine (Win10, Server 2016)

When replacing the kernel with a stock Ubuntu kernel – the kernel loads well.
Tried other (pre-built) kernels from 
http://downloads.yoctoproject.org/releases/yocto/yocto-x.y/ – same odd 
behavior: Grub loads, kernel does not load.
Tried a different compression (other than gzip) – same.

Any idea?

Thanks,
Yair


-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] QA issue applibrary rdepends on app-dev [dev-deps], where is the do_package_qa?

[JH]

Hi,

According to the latest document:

"Package QA checks are now performed during a new do_package_qa task
rather than being part of the do_package task. This allows more
parallel execution. This change is unlikely to be an issue except for
highly customized recipes that disable packaging tasks themselves by
marking them as noexec. For those packages, you will need to disable
the do_package_qa task as well."

How can I disable the do_package_qa task?

Thank you.

Kind regards,

- jh

On 8/4/19, JH  wrote:
> Hi,
>
> I was running my Yocto build fine until I had a minor change to move
> libapplibrary.so to libapplibrry.so.${PN} and made libapplibrary.so to
> a symbolic link of libapplibrry.so.${PN}. Now it got an error of QA
> issue applibrary rdepends on app-dev [dev-deps], QA run found fatal
> errors, please consider fixing them.
>
> Even I reverse the changes back the, it still complained the same error.
>
> I don't have do_package_qa in my bb file, where is it from? What is
> that error about? How to fix it?
>
> Thank you.
>
> Kind regards,
>
> - jh
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Yocto Pyro, bitbake, git pull for my recipe (Why not?)

[Jussi Kukkonen]

>From the AUTOREV documentation:

   If you use the previous statement to retrieve the latest version of
software, you need to be sure PV contains ${SRCPV}.

Typically this looks something like:
PV = "1.2+git${SRCPV}"

HTH,
  Jussi

On Mon, 5 Aug 2019 at 11:47, Mauro Ziliani  wrote:
>
> Hi all.
>
> It seems that bitbake doesn't check the remote git repository of my
> application (terminal is the name of the recipe) every time I do
>
>
> bitbake  terminal
>
>
> The recipe is this
>
> #  the recipe -
>
> SRCREV="${AUTOREV}"
>
> SRC_URI = " \
>
>  git://git@server/terminal.git;protocol=ssh;branch=master \
>
> "
>
>
> S := "${WORKDIR}/git"
>
> inherit qmake5
>
> #  the end of recipe -
>
>
> Any idea to force git pull?
>
>
> Best regards,
>
>MZ
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Integration of Conan Package Manager into the Yocto Project

[Dani Manzaneque]

We know that this approach is a bit different from the Yocto way of
building all from sources and we acknowledge the benefits of doing so
when building for specific hardware requirements. However, this
integration has been requested by Conan users already managing their
packages with Conan for other platforms that wanted to be able to
deploy their libraries or applications into a Linux image generated
with Yocto.

This is the first step towards that integration and we have proved it
works, but there is still room for improvement and we are fully open
to any suggestions. We will take a look at the fetcher approach that
looks quite smooth and a bit easier for users too.
Thanks a lot!

El vie., 26 jul. 2019 a las 14:47, Alexander Kanavin
() escribió:
>
> Pulling down things from the network in do_install() is not the best option. 
> Is reproducibility and integrity of such downloads guaranteed? What about the 
> component licensing, where is that checked (against upstream changes)? Also, 
> yocto's download caching and mirroring facility is side-stepped entirely.
>
> The typical 'Yocto way' would be to write a specific conan fetcher for 
> bitbake, so that you can specify SRC_URI = "conan://..." in recipes:
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2?h=master-next
>
> Generally, if someone is doing system integration with Yocto and has access 
> to the source code, they might just write actual component recipes for 
> building from source, as the presented workflow with building via SDK and 
> artifactory binary uploads is awkward, and all benefits that happen when 
> yocto is able to build directly from source code are lost.
>
> Regards,
> Alex
>
>
> On Fri, 26 Jul 2019 at 14:39, Dani Manzaneque  
> wrote:
>>
>> Hi!
>>
>> We have developed an integration with Yocto for the open-source Conan
>> C/C++ package manager.
>> This integration includes the ability to cross-build packages with a
>> Yocto SDK Toolchain and later deploy them in the Yocto build.
>>
>> We have created a blog post with a brief introduction to the Yocto
>> Project and the announcement of the integration:
>> https://blog.conan.io/2019/07/26/Conan-Yocto-integration.html
>>
>> And a detailed section in our documentation with the configuration for
>> the meta-conan layer and the Bitbake recipes for the packages:
>> https://docs.conan.io/en/latest/integrations/cross_platform/yocto.html
>>
>> Feedback is welcomed. Thanks a lot!
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto