[OE-core] [PATCH v2] meta: uboot-config: Fix broken menuconfig for "fitImage" kernel

[Mike Looijmans]

kernel-fitimage inherited uboot-config, which resulted in failure to
run "menuconfig" on a system that has both multiple u-boot configs and
wants a fitImage kernel.

Fix the issue by splitting up uboot-config into conf/uboot.conf that
only contains the "harmless" variable settings, and require that in a
new uboot-config class which contains the Python code to do the U-boot
specific settings. Require only conf/uboot.conf in kernel-fitimage so
that it has what it needs but doesn't break.

Fixes: f9e834e31788 "meta: introduce KCONFIG_CONFIG_ENABLE_MENUCONFIG"
Signed-off-by: Mike Looijmans 
---
 meta/classes-recipe/kernel-fitimage.bbclass |  3 +-
 meta/classes-recipe/uboot-config.bbclass| 80 +--
 meta/conf/uboot.conf| 88 +
 3 files changed, 91 insertions(+), 80 deletions(-)
 create mode 100644 meta/conf/uboot.conf

diff --git a/meta/classes-recipe/kernel-fitimage.bbclass 
b/meta/classes-recipe/kernel-fitimage.bbclass
index 4b74ddc201..b941609cc5 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -4,7 +4,8 @@
 # SPDX-License-Identifier: MIT
 #
 
-inherit kernel-uboot kernel-artifact-names uboot-config
+inherit kernel-uboot kernel-artifact-names
+require conf/uboot.conf
 
 def get_fit_replacement_type(d):
 kerneltypes = d.getVar('KERNEL_IMAGETYPES') or ""
diff --git a/meta/classes-recipe/uboot-config.bbclass 
b/meta/classes-recipe/uboot-config.bbclass
index e55fc38b7c..bfa9af7f49 100644
--- a/meta/classes-recipe/uboot-config.bbclass
+++ b/meta/classes-recipe/uboot-config.bbclass
@@ -13,85 +13,7 @@
 #
 # SPDX-License-Identifier: MIT
 
-
-def removesuffix(s, suffix):
-if suffix and s.endswith(suffix):
-return s[:-len(suffix)]
-return s
-
-UBOOT_ENTRYPOINT ?= "20008000"
-UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
-
-# Some versions of u-boot use .bin and others use .img.  By default use .bin
-# but enable individual recipes to change this value.
-UBOOT_SUFFIX ??= "bin"
-UBOOT_BINARY ?= "u-boot.${UBOOT_SUFFIX}"
-UBOOT_BINARYNAME ?= "${@os.path.splitext(d.getVar("UBOOT_BINARY"))[0]}"
-UBOOT_IMAGE ?= "${UBOOT_BINARYNAME}-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
-UBOOT_SYMLINK ?= "${UBOOT_BINARYNAME}-${MACHINE}.${UBOOT_SUFFIX}"
-UBOOT_MAKE_TARGET ?= "all"
-
-# Output the ELF generated. Some platforms can use the ELF file and directly
-# load it (JTAG booting, QEMU) additionally the ELF can be used for debugging
-# purposes.
-UBOOT_ELF ?= ""
-UBOOT_ELF_SUFFIX ?= "elf"
-UBOOT_ELF_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}"
-UBOOT_ELF_BINARY ?= "u-boot.${UBOOT_ELF_SUFFIX}"
-UBOOT_ELF_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_ELF_SUFFIX}"
-
-# Some versions of u-boot build an SPL (Second Program Loader) image that
-# should be packaged along with the u-boot binary as well as placed in the
-# deploy directory.  For those versions they can set the following variables
-# to allow packaging the SPL.
-SPL_SUFFIX ?= ""
-SPL_BINARY ?= ""
-SPL_DELIMITER  ?= "${@'.' if d.getVar("SPL_SUFFIX") else ''}"
-SPL_BINARYFILE ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}"
-SPL_BINARYNAME ?= "${@removesuffix(d.getVar("SPL_BINARYFILE"), "." + 
d.getVar("SPL_SUFFIX"))}"
-SPL_IMAGE ?= 
"${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX}"
-SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}${SPL_DELIMITER}${SPL_SUFFIX}"
-
-# Additional environment variables or a script can be installed alongside
-# u-boot to be used automatically on boot.  This file, typically 'uEnv.txt'
-# or 'boot.scr', should be packaged along with u-boot as well as placed in the
-# deploy directory.  Machine configurations needing one of these files should
-# include it in the SRC_URI and set the UBOOT_ENV parameter.
-UBOOT_ENV_SUFFIX ?= "txt"
-UBOOT_ENV ?= ""
-UBOOT_ENV_SRC_SUFFIX ?= "cmd"
-UBOOT_ENV_SRC ?= "${UBOOT_ENV}.${UBOOT_ENV_SRC_SUFFIX}"
-UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
-UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
-UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
-
-# U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf
-# to find EXTLINUX conf file.
-UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux"
-UBOOT_EXTLINUX_CONF_NAME ?= "extlinux.conf"
-UBOOT_EXTLINUX_SYMLINK ?= "${UBOOT_EXTLINUX_CONF_NAME}-${MACHINE}-${PR}"
-
-# Options for the device tree compiler passed to mkimage '-D' feature:
-UBOOT_MKIMAGE_DTCOPTS ??= ""
-SPL_MKIMAGE_DTCOPTS ??= ""
-
-# mkimage command
-UBOOT_MKIMAGE ?= "ubo

Re: [OE-core] [PATCH] meta: uboot-config: Fix broken menuconfig for "fitImage" kernel

[Mike Looijmans]

On 22-05-2024 07:39, Richard Purdie wrote:

On Wed, 2024-05-22 at 07:28 +0200, mike.looijm...@topic.nl wrote:

On 21-05-2024 16:51, Richard Purdie wrote:

On Tue, 2024-05-21 at 15:57 +0200, Mike Looijmans via
lists.openembedded.org wrote:

kernel-fitimage inherited uboot-config, which resulted in failure
to
run "menuconfig" on a system that has both multiple u-boot
configs and
wants a fitImage kernel.

Fix the issue by splitting up uboot-config into uboot-config-vars
that
only contains the "harmless" variable settings, and inherit that
in a
new uboot-config class which contains the Python code to do the
U-boot
specific settings. Inherit only uboot-config-vars in kernel-
fitimage
so that it has what it needs but doesn't break.

Fixes: f9e834e31788 "meta: introduce
KCONFIG_CONFIG_ENABLE_MENUCONFIG"
Signed-off-by: Mike Looijmans 
---
   meta/classes-recipe/kernel-fitimage.bbclass   |  2 +-
   meta/classes-recipe/uboot-config-vars.bbclass | 95
+++
   meta/classes-recipe/uboot-config.bbclass  | 80 +---

   3 files changed, 97 insertions(+), 80 deletions(-)
   create mode 100644 meta/classes-recipe/uboot-config-
vars.bbclass


This looks like it might be a good candidate to move to a file in
meta/conf rather than a new class file?


What does "this" refer to exactly?


The variable definitions you're placing into a separate class file. I'm
saying they look more suited to a shared conf file, which is a
direction I think the project needs to move in generally.


a "uboot.conf" then, okay.




Note that this patch just moves code, it doesn't introduce anything
new.


We could add any functions needed to lib/oe/ if they can be made
suitably generic.


What "functions" would that be?


removesuffix is the one I saw that was needed in the new class file and
wouldn't work in a conf file.


Interestingly, "removesuffix" is a built-in Python function since 3.8:

>>> 'hello.all'.removesuffix('.all')
'hello'

And 3.8 is the minimum required version for Yocto anyway.


--
Mike Looijmans



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

Re: [OE-core] [PATCH] meta: uboot-config: Fix broken menuconfig for "fitImage" kernel

[Mike Looijmans]

On 21-05-2024 16:51, Richard Purdie wrote:

On Tue, 2024-05-21 at 15:57 +0200, Mike Looijmans via lists.openembedded.org 
wrote:

kernel-fitimage inherited uboot-config, which resulted in failure to
run "menuconfig" on a system that has both multiple u-boot configs and
wants a fitImage kernel.

Fix the issue by splitting up uboot-config into uboot-config-vars that
only contains the "harmless" variable settings, and inherit that in a
new uboot-config class which contains the Python code to do the U-boot
specific settings. Inherit only uboot-config-vars in kernel-fitimage
so that it has what it needs but doesn't break.

Fixes: f9e834e31788 "meta: introduce KCONFIG_CONFIG_ENABLE_MENUCONFIG"
Signed-off-by: Mike Looijmans 
---
  meta/classes-recipe/kernel-fitimage.bbclass   |  2 +-
  meta/classes-recipe/uboot-config-vars.bbclass | 95 +++
  meta/classes-recipe/uboot-config.bbclass  | 80 +---
  3 files changed, 97 insertions(+), 80 deletions(-)
  create mode 100644 meta/classes-recipe/uboot-config-vars.bbclass


This looks like it might be a good candidate to move to a file in
meta/conf rather than a new class file?


What does "this" refer to exactly?

Note that this patch just moves code, it doesn't introduce anything new.


We could add any functions needed to lib/oe/ if they can be made
suitably generic.


What "functions" would that be?

M.


--
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl



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

[OE-core] [PATCH] meta: uboot-config: Fix broken menuconfig for "fitImage" kernel

[Mike Looijmans]

kernel-fitimage inherited uboot-config, which resulted in failure to
run "menuconfig" on a system that has both multiple u-boot configs and
wants a fitImage kernel.

Fix the issue by splitting up uboot-config into uboot-config-vars that
only contains the "harmless" variable settings, and inherit that in a
new uboot-config class which contains the Python code to do the U-boot
specific settings. Inherit only uboot-config-vars in kernel-fitimage
so that it has what it needs but doesn't break.

Fixes: f9e834e31788 "meta: introduce KCONFIG_CONFIG_ENABLE_MENUCONFIG"
Signed-off-by: Mike Looijmans 
---
 meta/classes-recipe/kernel-fitimage.bbclass   |  2 +-
 meta/classes-recipe/uboot-config-vars.bbclass | 95 +++
 meta/classes-recipe/uboot-config.bbclass  | 80 +---
 3 files changed, 97 insertions(+), 80 deletions(-)
 create mode 100644 meta/classes-recipe/uboot-config-vars.bbclass

diff --git a/meta/classes-recipe/kernel-fitimage.bbclass 
b/meta/classes-recipe/kernel-fitimage.bbclass
index 4b74ddc201..070a822b43 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -4,7 +4,7 @@
 # SPDX-License-Identifier: MIT
 #
 
-inherit kernel-uboot kernel-artifact-names uboot-config
+inherit kernel-uboot kernel-artifact-names uboot-config-vars
 
 def get_fit_replacement_type(d):
 kerneltypes = d.getVar('KERNEL_IMAGETYPES') or ""
diff --git a/meta/classes-recipe/uboot-config-vars.bbclass 
b/meta/classes-recipe/uboot-config-vars.bbclass
new file mode 100644
index 00..5714ace579
--- /dev/null
+++ b/meta/classes-recipe/uboot-config-vars.bbclass
@@ -0,0 +1,95 @@
+# Handle U-Boot config for a machine
+#
+# The format to specify it, in the machine, is:
+#
+# UBOOT_CONFIG ??= 
+# UBOOT_CONFIG[foo] = "config,images,binary"
+#
+# or
+#
+# UBOOT_MACHINE = "config"
+#
+# Copyright 2013, 2014 (C) O.S. Systems Software LTDA.
+#
+# SPDX-License-Identifier: MIT
+
+
+def removesuffix(s, suffix):
+if suffix and s.endswith(suffix):
+return s[:-len(suffix)]
+return s
+
+UBOOT_ENTRYPOINT ?= "20008000"
+UBOOT_LOADADDRESS ?= "${UBOOT_ENTRYPOINT}"
+
+# Some versions of u-boot use .bin and others use .img.  By default use .bin
+# but enable individual recipes to change this value.
+UBOOT_SUFFIX ??= "bin"
+UBOOT_BINARY ?= "u-boot.${UBOOT_SUFFIX}"
+UBOOT_BINARYNAME ?= "${@os.path.splitext(d.getVar("UBOOT_BINARY"))[0]}"
+UBOOT_IMAGE ?= "${UBOOT_BINARYNAME}-${MACHINE}-${PV}-${PR}.${UBOOT_SUFFIX}"
+UBOOT_SYMLINK ?= "${UBOOT_BINARYNAME}-${MACHINE}.${UBOOT_SUFFIX}"
+UBOOT_MAKE_TARGET ?= "all"
+
+# Output the ELF generated. Some platforms can use the ELF file and directly
+# load it (JTAG booting, QEMU) additionally the ELF can be used for debugging
+# purposes.
+UBOOT_ELF ?= ""
+UBOOT_ELF_SUFFIX ?= "elf"
+UBOOT_ELF_IMAGE ?= "u-boot-${MACHINE}-${PV}-${PR}.${UBOOT_ELF_SUFFIX}"
+UBOOT_ELF_BINARY ?= "u-boot.${UBOOT_ELF_SUFFIX}"
+UBOOT_ELF_SYMLINK ?= "u-boot-${MACHINE}.${UBOOT_ELF_SUFFIX}"
+
+# Some versions of u-boot build an SPL (Second Program Loader) image that
+# should be packaged along with the u-boot binary as well as placed in the
+# deploy directory.  For those versions they can set the following variables
+# to allow packaging the SPL.
+SPL_SUFFIX ?= ""
+SPL_BINARY ?= ""
+SPL_DELIMITER  ?= "${@'.' if d.getVar("SPL_SUFFIX") else ''}"
+SPL_BINARYFILE ?= "${@os.path.basename(d.getVar("SPL_BINARY"))}"
+SPL_BINARYNAME ?= "${@removesuffix(d.getVar("SPL_BINARYFILE"), "." + 
d.getVar("SPL_SUFFIX"))}"
+SPL_IMAGE ?= 
"${SPL_BINARYNAME}-${MACHINE}-${PV}-${PR}${SPL_DELIMITER}${SPL_SUFFIX}"
+SPL_SYMLINK ?= "${SPL_BINARYNAME}-${MACHINE}${SPL_DELIMITER}${SPL_SUFFIX}"
+
+# Additional environment variables or a script can be installed alongside
+# u-boot to be used automatically on boot.  This file, typically 'uEnv.txt'
+# or 'boot.scr', should be packaged along with u-boot as well as placed in the
+# deploy directory.  Machine configurations needing one of these files should
+# include it in the SRC_URI and set the UBOOT_ENV parameter.
+UBOOT_ENV_SUFFIX ?= "txt"
+UBOOT_ENV ?= ""
+UBOOT_ENV_SRC_SUFFIX ?= "cmd"
+UBOOT_ENV_SRC ?= "${UBOOT_ENV}.${UBOOT_ENV_SRC_SUFFIX}"
+UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
+UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
+UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
+
+# U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf
+# to find EXTLINUX conf file.
+UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux"
+UBOOT_EXTLINUX_CONF_NAME ?= "ext

Re: [OE-core] What does "do_menuconfig is disabled" really mean?

[Mike Looijmans]

On 16-05-2024 13:58, Mike Looijmans via lists.openembedded.org wrote:

On 16-05-2024 13:41, Mike Looijmans via lists.openembedded.org wrote:

On 16-05-2024 13:34, Ross Burton wrote:
On 16 May 2024, at 12:03, Mike Looijmans via lists.openembedded.org 
 wrote:


Using scartgap branch, trying to create a kernel recipe for a custom 
LS1028 machine.


The recipe in meta-freescale for the ls1028ardb is hopelessly outdated and 
produces a 5.10 kernel.


So for my custom board based on the ls1028 I want to create a recipe that 
builds a mainline kernel (I don't need GPU or fancy things that require 
firmware or special drivers, so mainline should be fine).


I started out trying to get linux-yocto to build for my board, so copied 
the "skeleton" recipe, adjusted a bit (add COMPATIBLE_MACHINE and a 
defconfig).


But when I then run "bitbake -c menuconfig virtual/kernel" I always get 
this message:


ERROR: linux-yocto-*-6.6+git-r0 do_menuconfig: do_menuconfig is disabled, 
please check KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.


I tried starting with a copy of recipes like linux-fscl, same error. Always.

(note: I've run "menuconfig" a million times by now, for dozens of boards, 
so it's not the system).


I tried adding
KCONFIG_CONFIG_ENABLE_MENUCONFIG="true"
to my recipe, but that also had no effect.

The log file also contains no information whatsoever.

What's the real issue?


cml1.bbclass has this:

KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= “true"
…
 if not bb.utils.to_boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG")):
 bb.fatal("do_menuconfig is disabled, please check 
KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.”)


So if you’re seeing that message then _something_ is assigning that 
variable to false. Use bitbake-getvar to identify what that is.




Interesting, that points to "uboot-config.bbclass:147" which sets it to 
false. I'm not building u-boot here, I'm building the kernel?



$ bitbake-getvar -r linux-fslc KCONFIG_CONFIG_ENABLE_MENUCONFIG
#
# $KCONFIG_CONFIG_ENABLE_MENUCONFIG [3 operations]
#   set /.../oe-core/meta/classes-recipe/cml1.bbclass:35
# [_defaultval] "true"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
# pre-expansion value:
#   "false"
KCONFIG_CONFIG_ENABLE_MENUCONFIG="false"




This is because of using "fitImage":

meta/classes-recipe/kernel-fitimage.bbclass:inherit kernel-uboot 
kernel-artifact-names uboot-config



I can specify this in the kernel recipe to make this error go away:
UBOOT_CONFIG = "tfa"

But then the menuconfig command just exits silently and does nothing whatsoever.


So the issue turns out to be that setting KERNEL_IMAGETYPES = "fitImage" 
breaks menuconfig for the kernel in the scartgap branch.


Only way I've been able to run menuconfig is to temporarily change 
KERNEL_IMAGETYPES to something else, then do the kernel configuration and when 
done change it back again.


M.



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

Re: [OE-core] What does "do_menuconfig is disabled" really mean?

[Mike Looijmans]

On 16-05-2024 13:41, Mike Looijmans via lists.openembedded.org wrote:


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl

Please consider the environment before printing this e-mail
On 16-05-2024 13:34, Ross Burton wrote:
On 16 May 2024, at 12:03, Mike Looijmans via lists.openembedded.org 
 wrote:


Using scartgap branch, trying to create a kernel recipe for a custom LS1028 
machine.


The recipe in meta-freescale for the ls1028ardb is hopelessly outdated and 
produces a 5.10 kernel.


So for my custom board based on the ls1028 I want to create a recipe that 
builds a mainline kernel (I don't need GPU or fancy things that require 
firmware or special drivers, so mainline should be fine).


I started out trying to get linux-yocto to build for my board, so copied 
the "skeleton" recipe, adjusted a bit (add COMPATIBLE_MACHINE and a 
defconfig).


But when I then run "bitbake -c menuconfig virtual/kernel" I always get 
this message:


ERROR: linux-yocto-*-6.6+git-r0 do_menuconfig: do_menuconfig is disabled, 
please check KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.


I tried starting with a copy of recipes like linux-fscl, same error. Always.

(note: I've run "menuconfig" a million times by now, for dozens of boards, 
so it's not the system).


I tried adding
KCONFIG_CONFIG_ENABLE_MENUCONFIG="true"
to my recipe, but that also had no effect.

The log file also contains no information whatsoever.

What's the real issue?


cml1.bbclass has this:

KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= “true"
…
 if not bb.utils.to_boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG")):
 bb.fatal("do_menuconfig is disabled, please check 
KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.”)


So if you’re seeing that message then _something_ is assigning that variable 
to false. Use bitbake-getvar to identify what that is.




Interesting, that points to "uboot-config.bbclass:147" which sets it to false. 
I'm not building u-boot here, I'm building the kernel?



$ bitbake-getvar -r linux-fslc KCONFIG_CONFIG_ENABLE_MENUCONFIG
#
# $KCONFIG_CONFIG_ENABLE_MENUCONFIG [3 operations]
#   set /.../oe-core/meta/classes-recipe/cml1.bbclass:35
# [_defaultval] "true"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
# pre-expansion value:
#   "false"
KCONFIG_CONFIG_ENABLE_MENUCONFIG="false"




This is because of using "fitImage":

meta/classes-recipe/kernel-fitimage.bbclass:inherit kernel-uboot 
kernel-artifact-names uboot-config



I can specify this in the kernel recipe to make this error go away:
UBOOT_CONFIG = "tfa"

But then the menuconfig command just exits silently and does nothing whatsoever.













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

Re: [OE-core] What does "do_menuconfig is disabled" really mean?

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl

Please consider the environment before printing this e-mail
On 16-05-2024 13:34, Ross Burton wrote:

On 16 May 2024, at 12:03, Mike Looijmans via lists.openembedded.org 
 wrote:


Using scartgap branch, trying to create a kernel recipe for a custom LS1028 
machine.

The recipe in meta-freescale for the ls1028ardb is hopelessly outdated and 
produces a 5.10 kernel.

So for my custom board based on the ls1028 I want to create a recipe that 
builds a mainline kernel (I don't need GPU or fancy things that require 
firmware or special drivers, so mainline should be fine).

I started out trying to get linux-yocto to build for my board, so copied the 
"skeleton" recipe, adjusted a bit (add COMPATIBLE_MACHINE and a defconfig).

But when I then run "bitbake -c menuconfig virtual/kernel" I always get this 
message:

ERROR: linux-yocto-*-6.6+git-r0 do_menuconfig: do_menuconfig is disabled, 
please check KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.

I tried starting with a copy of recipes like linux-fscl, same error. Always.

(note: I've run "menuconfig" a million times by now, for dozens of boards, so 
it's not the system).

I tried adding
KCONFIG_CONFIG_ENABLE_MENUCONFIG="true"
to my recipe, but that also had no effect.

The log file also contains no information whatsoever.

What's the real issue?


cml1.bbclass has this:

KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= “true"
…
 if not bb.utils.to_boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG")):
 bb.fatal("do_menuconfig is disabled, please check 
KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.”)

So if you’re seeing that message then _something_ is assigning that variable to 
false. Use bitbake-getvar to identify what that is.



Interesting, that points to "uboot-config.bbclass:147" which sets it to false. 
I'm not building u-boot here, I'm building the kernel?



$ bitbake-getvar -r linux-fslc KCONFIG_CONFIG_ENABLE_MENUCONFIG
#
# $KCONFIG_CONFIG_ENABLE_MENUCONFIG [3 operations]
#   set /.../oe-core/meta/classes-recipe/cml1.bbclass:35
# [_defaultval] "true"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
# pre-expansion value:
#   "false"
KCONFIG_CONFIG_ENABLE_MENUCONFIG="false"




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

[OE-core] What does "do_menuconfig is disabled" really mean?

[Mike Looijmans]

Using scartgap branch, trying to create a kernel recipe for a custom LS1028 
machine.


The recipe in meta-freescale for the ls1028ardb is hopelessly outdated and 
produces a 5.10 kernel.


So for my custom board based on the ls1028 I want to create a recipe that 
builds a mainline kernel (I don't need GPU or fancy things that require 
firmware or special drivers, so mainline should be fine).


I started out trying to get linux-yocto to build for my board, so copied the 
"skeleton" recipe, adjusted a bit (add COMPATIBLE_MACHINE and a defconfig).


But when I then run "bitbake -c menuconfig virtual/kernel" I always get this 
message:


ERROR: linux-yocto-*-6.6+git-r0 do_menuconfig: do_menuconfig is disabled, 
please check KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.


I tried starting with a copy of recipes like linux-fscl, same error. Always.

(note: I've run "menuconfig" a million times by now, for dozens of boards, so 
it's not the system).


I tried adding
KCONFIG_CONFIG_ENABLE_MENUCONFIG="true"
to my recipe, but that also had no effect.

The log file also contains no information whatsoever.

What's the real issue?


--
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl


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

Re: [OE-core] [scarthgap] psplash no longer working

[Mike Looijmans]

Ah found it, something symlinks it later on.
Setting "outsuffix=default" in the URI fixed it. For some reason the old 
outsuffix didn't get installed.



On 08-05-2024 12:07, Mike Looijmans via lists.openembedded.org wrote:

I'm puzzled.

Migrating from kirkstone to scarthgap, and psplash somehow broke.

Systemd doesn't start is because "/usr/bin/psplash" is missing.

Interestingly, the line that appears to be responsible for that is in 
the do_install:append


  rm -f ${D}${bindir}/psplash

If I copy that file from ${B} to the board, psplash works again.

But what really baffles me is that kirkstone already had that line in 
do_install:append but somehow /usr/bin/psplash still got created. And 
I cannot find the magic that puts it there...



--
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl




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

[OE-core] [scarthgap] psplash no longer working

[Mike Looijmans]

I'm puzzled.

Migrating from kirkstone to scarthgap, and psplash somehow broke.

Systemd doesn't start is because "/usr/bin/psplash" is missing.

Interestingly, the line that appears to be responsible for that is in 
the do_install:append


  rm -f ${D}${bindir}/psplash

If I copy that file from ${B} to the board, psplash works again.

But what really baffles me is that kirkstone already had that line in 
do_install:append but somehow /usr/bin/psplash still got created. And I 
cannot find the magic that puts it there...


--
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl




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

[OE-core] Removing debug-tweaks removes /etc/shadow

[Mike Looijmans]

I have an unsolved mystery here.

If I build an image with "debug-tweaks" in [EXTRA_]IMAGE_FEATURES, I get a 
normal image, where logging in as root works as expected.


If i replace "debug-tweaks" with other options, for example one of these:
EXTRA_IMAGE_FEATURES = "empty-root-password allow-empty-password 
allow-root-login post-install-logging"

EXTRA_IMAGE_FEATURES = "empty-root-password allow-root-login"


That first variant should be equal to "debug-tweaks" according to the 
descriptions in core-image.bbclass and rootfs-postcommands.bbclass.



However, the end result is that the image ends up without /etc/shadow and 
though one can log in as root, the system doesn't actually seem to know who 
you are, so "root" does not appear in the prompt, "~" does not match 
"/homw/root", and UID 0 does not match "root".


It's a total mystery to me how "debug-tweaks" has any effect on that.

I'm currently using langdale branch and initscripts.


Any thoughts?


--
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl


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

Re: [OE-core] Git and pseudo

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 25-04-2022 14:51, Richard Purdie wrote:

On Mon, 2022-04-25 at 09:40 +0200, Mike Looijmans wrote:

Recently GIT got updated with a security fix:

https://github.blog/2022-04-12-git-security-vulnerability-announced/


The problem is that this causes all "git" tasks that run within pseudo
(most noticably, image recipes) to fail. In many repositories, we use:
git rev-parse --verify HEAD > /etc/revision

Or something similar to that. After the GIT update, this now fails with
an error like:

'''
fatal: unsafe repository ('/home/mike/repository/path' is owned by
someone else)
To add an exception for this directory, call:

      git config --global --add safe.directory /home/mike/repository/path
'''

Apart from doing as it says, or even "git config --global --add
safe.directory '*'" anyone have a better idea, especially one that
prevents the system thinking I'm someone else (root in the case of pseudo).

https://git.yoctoproject.org/poky/commit/?id=21559199516a31c7635c5f2d874eaa4a92fff0e5

However this isn't quite enough as some things encode the path to git into build
files so the PATH change at do_install isn't enough. igt-gpu-tools via meson in
OE-Core is an example.

Cheers,

Richard


Nice, also for general usefulness.


For our particular case, I came up with this (works in old OE versions 
as well), just inserting a task since both do_image and do_rootfs run 
under fakeroot:


 # We require access to the git repository here, so we must run outside 
fakeroot

do_swumetadata() {
   # Hardware revision for SWUpdate
   echo "${SWU_BOARD_HWREVISION}" > ${IMAGE_ROOTFS}${sysconfdir}/hwrevision
   v=`git rev-parse --verify HEAD`
   echo $v > ${IMAGE_ROOTFS}${sysconfdir}/swrevision
   echo $v > ${DEPLOY_DIR_IMAGE}/${IMAGE_BASENAME}.swrevision
}
addtask do_swumetadata before do_image after do_rootfs



--
Mike Looijmans


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

[OE-core] Git and pseudo

[Mike Looijmans]

Recently GIT got updated with a security fix:

https://github.blog/2022-04-12-git-security-vulnerability-announced/


The problem is that this causes all "git" tasks that run within pseudo 
(most noticably, image recipes) to fail. In many repositories, we use:

git rev-parse --verify HEAD > /etc/revision

Or something similar to that. After the GIT update, this now fails with 
an error like:


'''
fatal: unsafe repository ('/home/mike/repository/path' is owned by 
someone else)

To add an exception for this directory, call:

    git config --global --add safe.directory /home/mike/repository/path
'''

Apart from doing as it says, or even "git config --global --add 
safe.directory '*'" anyone have a better idea, especially one that 
prevents the system thinking I'm someone else (root in the case of pseudo).


--
Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail

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

Re: [OE-core] [PATCH] "bitbake-prserv-tool: Added quotes to variables to prevent splitting and gobbling"

[Mike Looijmans]

See comment below (our mail server injects signatures, sorry for that)


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 13-04-2022 11:35, Abongwa Amahnui Bonalais via lists.openembedded.org wrote:

Signed-off-by: Abongwa Bonalais Amahnui 
---
  scripts/bitbake-prserv-tool | 22 +++---
  1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/scripts/bitbake-prserv-tool b/scripts/bitbake-prserv-tool
index e55d98c72e..68caa9fb66 100755
--- a/scripts/bitbake-prserv-tool
+++ b/scripts/bitbake-prserv-tool
@@ -5,7 +5,7 @@
  
  help ()

  {
-base=`basename $0`
+base=`basename "$0"`
  echo -e "Usage: $base command"
  echo "Avaliable commands:"
  echo -e "\texport : export and lock down the AUTOPR values from the 
PR service into a file for release."
@@ -16,7 +16,7 @@ clean_cache()
  {
  s=`bitbake -e | grep ^CACHE= | cut -f2 -d\"`
  if [ "x${s}" != "x" ]; then
-rm -rf ${s}
+rm -rf "${s}"
  fi
  }
  
@@ -24,14 +24,14 @@ do_export ()

  {
  file=$1


You'd want to quote this one too I think.


  [ "x${file}" == "x" ] && help && exit 1
-rm -f ${file}
+rm -f "${file}"
  
  clean_cache

  bitbake -R conf/prexport.conf -p
  s=`bitbake -R conf/prexport.conf -e | grep ^PRSERV_DUMPFILE= | cut -f2 
-d\"`
  if [ "x${s}" != "x" ];
  then
-   [ -e $s ] && mv -f $s $file && echo "Exporting to file $file succeeded!"
+   [ -e "$s" ] && mv -f "$s" "$file" && echo "Exporting to file $file 
succeeded!"
 return 0
  fi
  echo "Exporting to file $file failed!"
@@ -44,7 +44,7 @@ do_import ()
  [ "x${file}" == "x" ] && help && exit 1
  
  clean_cache

-bitbake -R conf/primport.conf -R $file -p
+bitbake -R conf/primport.conf -R "$file" -p
  ret=$?
  [ $ret -eq 0 ] && echo "Importing from file $file succeeded!" || echo 
"Importing from file $file failed!"
  return $ret
@@ -60,13 +60,13 @@ do_migrate_localcount ()
  return 1
  fi
  
-rm -rf $df

+rm -rf "$df"
  clean_cache
  echo "Exporting LOCALCOUNT to AUTOINCs..."
  bitbake -R conf/migrate_localcount.conf -p
  [ ! $? -eq 0 ] && echo "Exporting to file $df failed!" && exit 1
  
-if [ -e $df ];

+if [ -e "$df" ];
  then
  echo "Exporting to file $df succeeded!"
  else
@@ -75,7 +75,7 @@ do_migrate_localcount ()
  fi
  
  echo "Importing generated AUTOINC entries..."

-[ -e $df ] && do_import $df
+[ -e "$df" ] && do_import "$df"
  
  if [ ! $? -eq 0 ]

  then
@@ -93,17 +93,17 @@ case $2 in
  *.conf|*.inc)
  ;;
  *)
-echo ERROR: $2 must end with .conf or .inc!
+echo ERROR: "$2" must end with .conf or .inc!
  exit 1
  ;;
  esac
  
  case $1 in

  export)
-do_export $2
+do_export "$2"
  ;;
  import)
-do_import $2
+do_import "$2"
  ;;
  migrate_localcount)
  do_migrate_localcount








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

Re: [OE-core] [PATCH 1/2] bitbake.conf: Ensure XZ_THREADS doesn't change sstate checksums

[Mike Looijmans]

Wouldn't "0" be a better default? Setting threads to "0" will make xz use the 
CPU count anyway, so it'd be honest too.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 11-09-2021 12:04, Richard Purdie via lists.openembedded.org wrote:

rpm output packages currently depend on the value of XZ_THREADS which
is ok if left to the default value but problematic if system limits
are set such as on the autobuilder.

Force the value to a specific one in the hashes for better sstate reuse
and consistent rpm task checksums.

Signed-off-by: Richard Purdie 
---
  meta/conf/bitbake.conf | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 2140d498f7c..e25d632dc1c 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -811,6 +811,7 @@ PARALLEL_MAKE ?= "-j ${@oe.utils.cpu_count()}"
  # Default parallelism and resource usage for xz
  XZ_MEMLIMIT ?= "50%"
  XZ_THREADS ?= "${@oe.utils.cpu_count(at_least=2)}"
+XZ_THREADS[vardepvalue] = "1"
  XZ_DEFAULTS ?= "--memlimit=${XZ_MEMLIMIT} --threads=${XZ_THREADS}"
  XZ_DEFAULTS[vardepsexclude] += "XZ_MEMLIMIT XZ_THREADS"
  









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

Re: [OE-core] GCC crashes on aarch64 since gatesgarth

[Mike Looijmans]

Ancient thread, but might be of interest to others.

A while ago the power supply died. After replacing the PSU, the error 
below hasn't occurred any more.


I'm not 100% certain, but it's very likely the issue was caused by that 
PSU on the brink of failing completely. Not the first thing to come to 
mind...


Apparently gatesgarth is more power demanding than hardknott :)

Kind regards,
Mike


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 27-01-2021 16:10, Mike Looijmans via lists.openembedded.org wrote:
When doing large builds, the GCC compiler tends to crash on random 
spots in the code. There are a few common denominators though.


It only happens when compiling for aarch64 (cortex-A53), not for 
32-bit arm (cortex-A9)


It's random and usually happens on "big" sets like kernel, openssl, 
boost, u-boot etc.


It always reports "during GIMPLE pass: ealias" in the error, for example:

| during GIMPLE pass: ealias
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c: In function 'do_x509_check':
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c:1239:1: internal compiler 
error: Illegal instruction

| 1239 | }

Compiling the same thing again usually goes fine.

I've never experienced this with the zeus and older branches of OE.


I've already tried upgrading to the latest gatesgarth status, and 
cleaning out everything and start from scratch. I've also run "mprime" 
test on my machine (over one hour) just to be confident that the 
system itself is really okay.



Ideas to diagnose, fix or reliably reprodruce are more than welcome.






--
Mike Looijmans


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

[OE-core] Using RDEPENDS or RRECOMMENDS inside a kernel module recipe

[Mike Looijmans]

Simple question: How can I make an external kernel module depend on its 
firmware?


Suppose I have a recipe "kernel-module-something.bb"

Now this module needs firmware to work so the recipe basically contains 
this:


inherit module

SRC_URI = "..."

RRECOMMENDS_${PN} += "something-firmware"


What I would expect is that if I add "kernel-module-something" to the 
image, that "something-firmware" also gets installed. This however does 
not happen.


The "something-firmware" package is being built, but not installed, even 
though "kernel-module-something" is present.


I think the reason is that there are two packages created, one meta 
packages called "kernel-module-something" that indeed contains the 
dependency on the "something-firmware" but does not contain the actual 
kernel module.


There's a second package named "kernel-module-something-5.4.0-blabla"  
(where 5.4.0-blabla appears to be the kernel version) that contains the 
actual kernel module, but there's no recommendation in this package at all.



How do I properly make it so that installing "kernel-module-something" 
will also install "something-firmware"?



--
Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail

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

Re: [OE-core] any *compelling* reasons to whitelist env vars for an OE build?

[Mike Looijmans]

I for one use a whitelist env vars daily, both hobby and work.

We tend to build for multiple machines, so in general we'd have something like 
this running on the build server:


for machine in mach1 mach2 mach3 mach4 ... mach40
do
   MACHINE=$machine bitbake image1 image2 image3
done

Being able to pass the MACHINE through the environment is a big win. We could 
alter a config file in the shell script, but that would change a file that 
we'd want under version control, and I really don't like it when builds change 
files under version control.


(The "40" machines is not exaggerated, I'm really involved in projects that 
build for that many targets)


Come to think of it, MACHINE is the one and only environment we ever pass to 
bitbake.


For release/test/production/debug/... etcetera I tend to use a different 
image, so you'd see:


MACHINE=mach1 bitbake interesting-image interesting-image-dev

So "interesting-image" would be the product, while the "dev" version would 
apply debug tweaks that make the rootfs writeable and enable the serial 
console for login and things like that.





Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 25-03-2021 15:08, Robert P. J. Day via lists.openembedded.org wrote:


   kind of a philosophical question, but i'm having a discussion with
some new colleagues about how to customize an OE (actually, wind river
linux) build, and these colleagues have, until now, used (whitelisted)
environment variables to pass info to the build, that info being used
to specify things like a development versus manufacturing build, and
so on.

   i suggested that i didn't think there was any really persuasive
reasons to use environment variables this way, as there are more than
enough configuration files to customize a build. i mentioned things
like:

   * machine config files
   * distro config files
   * defining packagegroup files
   * defining image files

and on and on and on.

   my point was that there are more than enough ways to support all the
customization you might need, that taking advantage of shell
environment variables strikes me as unnecessarily messy and, for that
matter, dangerous if you forget so set the environment.

   thoughts? am i out of line in advising them to use what OE offers
them, and not extract stuff from the environment?

rday








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

Re: [OE-core] [poky][PATCH] package_manager: install versioned postinst scripts

[Mike Looijmans]

So it's something exclusively for OpenBMC.

As for running the scripts, you cannot simply conclude that a script 
doesn't need to run if its contents did not change. It may very well 
call the executable from its package to do the actual work and that may 
have changed as well.



Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 17:54, Anton Kachalov wrote:

Hi, Mike.

That is how OpenBMC is designed. Most of the targets are read-only 
rootfs (squashfs) and overlayfs for RW.
It is not expected to overwrite binaries through overlayfs and there 
are plans to scope RW areas (e.g. /etc).


Those files with 64-chars suffix are mostly hidden from regular users: 
the files are removed during the first startup. No one will notice them :)


Anyway, alternatively within the openbmc update script it's possible 
to force clean the deleted files on overlayfs upperdir. However, it 
will mean that all the scripts regardless if they are updated or not, 
will be re-executed after rootfs update.


On Mon, 22 Mar 2021 at 17:08, Mike Looijmans <mailto:mike.looijm...@topic.nl>> wrote:


Two remarks below...
On 22-03-2021 16:45, Anton Kachalov via lists.openembedded.org
<http://lists.openembedded.org> wrote:
> From: "Anton D. Kachalov" mailto:gmo...@google.com>>
>
> When running on read-only rootfs backed with overlayfs, the
processed scripts
> are being marked as deleted on upperdir of overlayfs. When it
comes to
> upgrade the main read-only image, it might contain new postinst
scripts that
> are different from the already processed. Introduced suffix
(sha256 of
> the content) allows to distinct updated scripts of the same package.

So your usecase is that you have a read-only rootfs with an
overlay on
top, and then just replace the rootfs. And then expect things to
still
work?

That doesn't sound valid to me - normally I'd wipe the overlay clean
when updating the underlying read-only part. I'd be very
interested in
what you're actually trying to accomplish here?

And further, I don't think appending 64 characters to filenames is
going
to make anyone happy.

In your case, I'd opt for a script that just resets the postinst
scripts
(and maybe more?) in the overlay. Or have 3 overlays. Whenever the
package manager runs, activate the second layer. The "user" stuff
in the
third layer is normally active. Then when you upgrade the system,
wipe
the second layer, to get rid of obsolete packages. Or something like
that. Again, tell us what you're really building...


>
> Signed-off-by: Anton D. Kachalov mailto:gmo...@google.com>>
> ---
>   meta/lib/oe/package_manager/deb/rootfs.py   | 11 ++-
>   meta/lib/oe/package_manager/ipk/rootfs.py   | 11 ++-
>   meta/lib/oe/package_manager/rpm/__init__.py |  4 +++-
>   3 files changed, 23 insertions(+), 3 deletions(-)
>
> diff --git a/meta/lib/oe/package_manager/deb/rootfs.py
b/meta/lib/oe/package_manager/deb/rootfs.py
> index 8fbaca11d6..704d213626 100644
> --- a/meta/lib/oe/package_manager/deb/rootfs.py
> +++ b/meta/lib/oe/package_manager/deb/rootfs.py
> @@ -4,6 +4,7 @@
>
>   import re
>   import shutil
> +from hashlib import sha256
>   from oe.rootfs import Rootfs
>   from oe.manifest import Manifest
>   from oe.utils import execute_pre_post_process
> @@ -115,8 +116,16 @@ class DpkgOpkgRootfs(Rootfs):
>               bb.utils.mkdirhier(dst_postinst_dir)
>
>               if os.path.exists(os.path.join(src_postinst_dir, p
+ ".postinst")):
> +                csum = sha256()
> +                with open(src_postinst_dir, p + ".postinst",
"rb") as f:
> +                    while True:
> +                        data = f.read(65536)
> +                        if not data:
> +                            break
> +                        csum.update(data)
> +
>  shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
> - os.path.join(dst_postinst_dir, "%03d-%s" % (num, p)))
> + os.path.join(dst_postinst_dir, "%03d-%s.%s" % (num, p,
csum.hexdigest(
>
>               num += 1
>
> diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py
b/meta/lib/oe/package_manager/ipk/rootfs.py
> index 26dbee6f6a..6ead6ddef3 100644
> --- a/meta/lib/oe/package_manager/ipk/rootfs.py

Re: [OE-core] [poky][PATCH] package_manager: install versioned postinst scripts

[Mike Looijmans]

Two remarks below...


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 16:45, Anton Kachalov via lists.openembedded.org wrote:

From: "Anton D. Kachalov" 

When running on read-only rootfs backed with overlayfs, the processed scripts
are being marked as deleted on upperdir of overlayfs. When it comes to
upgrade the main read-only image, it might contain new postinst scripts that
are different from the already processed. Introduced suffix (sha256 of
the content) allows to distinct updated scripts of the same package.


So your usecase is that you have a read-only rootfs with an overlay on 
top, and then just replace the rootfs. And then expect things to still 
work?


That doesn't sound valid to me - normally I'd wipe the overlay clean 
when updating the underlying read-only part. I'd be very interested in 
what you're actually trying to accomplish here?


And further, I don't think appending 64 characters to filenames is going 
to make anyone happy.


In your case, I'd opt for a script that just resets the postinst scripts 
(and maybe more?) in the overlay. Or have 3 overlays. Whenever the 
package manager runs, activate the second layer. The "user" stuff in the 
third layer is normally active. Then when you upgrade the system, wipe 
the second layer, to get rid of obsolete packages. Or something like 
that. Again, tell us what you're really building...





Signed-off-by: Anton D. Kachalov 
---
  meta/lib/oe/package_manager/deb/rootfs.py   | 11 ++-
  meta/lib/oe/package_manager/ipk/rootfs.py   | 11 ++-
  meta/lib/oe/package_manager/rpm/__init__.py |  4 +++-
  3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oe/package_manager/deb/rootfs.py 
b/meta/lib/oe/package_manager/deb/rootfs.py
index 8fbaca11d6..704d213626 100644
--- a/meta/lib/oe/package_manager/deb/rootfs.py
+++ b/meta/lib/oe/package_manager/deb/rootfs.py
@@ -4,6 +4,7 @@
  
  import re

  import shutil
+from hashlib import sha256
  from oe.rootfs import Rootfs
  from oe.manifest import Manifest
  from oe.utils import execute_pre_post_process
@@ -115,8 +116,16 @@ class DpkgOpkgRootfs(Rootfs):
  bb.utils.mkdirhier(dst_postinst_dir)
  
  if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):

+csum = sha256()
+with open(src_postinst_dir, p + ".postinst", "rb") as f:
+while True:
+data = f.read(65536)
+if not data:
+break
+csum.update(data)
+
  shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
-os.path.join(dst_postinst_dir, "%03d-%s" % (num, 
p)))
+os.path.join(dst_postinst_dir, "%03d-%s.%s" % 
(num, p, csum.hexdigest(
  
  num += 1
  
diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py b/meta/lib/oe/package_manager/ipk/rootfs.py

index 26dbee6f6a..6ead6ddef3 100644
--- a/meta/lib/oe/package_manager/ipk/rootfs.py
+++ b/meta/lib/oe/package_manager/ipk/rootfs.py
@@ -5,6 +5,7 @@
  import re
  import filecmp
  import shutil
+from hashlib import sha256
  from oe.rootfs import Rootfs
  from oe.manifest import Manifest
  from oe.utils import execute_pre_post_process
@@ -116,8 +117,16 @@ class DpkgOpkgRootfs(Rootfs):
  bb.utils.mkdirhier(dst_postinst_dir)
  
  if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):

+csum = sha256()
+with open(src_postinst_dir, p + ".postinst", "rb") as f:
+while True:
+data = f.read(65536)
+if not data:
+break
+csum.update(data)
+
  shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
-os.path.join(dst_postinst_dir, "%03d-%s" % (num, 
p)))
+os.path.join(dst_postinst_dir, "%03d-%s.%s" % 
(num, p, csum.hexdigest(
  
  num += 1
  
diff --git a/meta/lib/oe/package_manager/rpm/__init__.py b/meta/lib/oe/package_manager/rpm/__init__.py

index 6df0092281..4746e96ce8 100644
--- a/meta/lib/oe/package_manager/rpm/__init__.py
+++ b/meta/lib/oe/package_manager/rpm/__init__.py
@@ -4,6 +4,7 @@
  
  import shutil

  import subprocess
+from hashlib import sha256
  from oe.package_manager import *
  
  class RpmIndexer(Indexer):

@@ -359,7 +360,8 @@ class RpmPM(PackageManager):
  target_path = oe.path.join(self.target_rootfs, 

Re: [OE-core] Build the "boot" partition image (just like the rootfs)

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 15-03-2021 16:17, Mike Looijmans via lists.openembedded.org wrote:


If I create a WIC image, the boot partition is in there with the proper 
files (from IMAGE_BOOT_FILES) so I would really like to re-use that code. 
I could create the wic image and then cut out the part I want, but that 
doesn't seem particularly nice.


You can add vfat support for IMAGE_FSTYPES, and then you can build an 
image (you can just take the files you have in IMAGE_BOOT_FILES).


But that's *exactly* my problem: How do I get these IMAGE_BOOT_FILES into 
an image of sorts? Just setting IMAGE_FSTYPE="vfat" will put the rootfs 
contents in there, not the bootfiles I'm after.


rpi-bootfiles inherit nopackage, so you should write a recipe that instead 
of simply deploying the files as this recipe does, install them. You should 
then install it into /, as this is where they are put on the VFAT partition. 
If they are in the package, you can write an image recipe to install it via 
IMAGE_INSTALL, and via post process command you drop what is not necessary 
(/etc,...).


Anyway, as far as I know, an IMAGE_FSTYPES += "vfat" is not supported, you 
have also to add support for it.


rpi-bootfiles provides only part of the file set. The issue is that 
IMAGE_BOOT_FILES, which lists much more than what rpi-bootfiles provides, can 
be modified in the image recipe itself. It contains the kernel, devicetrees 
and configuration files as well.


What I did for now was just insert a task before swuimage that depends on the 
wic image, and just extracts the FAT partition using "dd". I'm not 
particularly proud of that, but it works/

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

Re: [OE-core] Build the "boot" partition image (just like the rootfs)

[Mike Looijmans]

Hi Stefano,


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 15-03-2021 15:58, Stefano Babic wrote:

Hi Mike,

On 15.03.21 15:46, Mike Looijmans wrote:


On 15-03-2021 14:47, Stefano Babic wrote:

Hi Mike,

On 15.03.21 14:13, Mike Looijmans wrote:
For software updates, I want to have what would have gone into the 
boot partition of the WIC image as a separate file.


If I want to have the contents of the rootfs as an ext4 image, I 
can just specify IMAGE_TYPES="ext4" in my image recipe.

 > This image I can feed to SWUdate and write to the rootfs storage.

But I also want to be able to update the boot partition (for 
example, the raspberrypi has the annoying property that devicetree 
and kernel reside here).


This is very annoying, but you could also get rid of it. You can 
install kernel and device tree in your rootfs (then they are located 
in /boot as usual), and you switch to U-Boot ( RPI_USE_U_BOOT = 
"1"). The proprietary bootloader will start U-Boot instead of 
kernel, and in u-boot you can load kernel and device tree from your 
rootfs.


That's what I did on other boards, but for the RPi that's not enough. 
There's also firmware there, which interacts with the kernel, and the 
firmware is altering the devicetree too. It's pretty likely that the 
firmware needs an update too when the kernel gets a big update.







If I create a WIC image, the boot partition is in there with the 
proper files (from IMAGE_BOOT_FILES) so I would really like to 
re-use that code. I could create the wic image and then cut out the 
part I want, but that doesn't seem particularly nice.


You can add vfat support for IMAGE_FSTYPES, and then you can build 
an image (you can just take the files you have in IMAGE_BOOT_FILES).


But that's *exactly* my problem: How do I get these IMAGE_BOOT_FILES 
into an image of sorts? Just setting IMAGE_FSTYPE="vfat" will put the 
rootfs contents in there, not the bootfiles I'm after.


rpi-bootfiles inherit nopackage, so you should write a recipe that 
instead of simply deploying the files as this recipe does, install 
them. You should then install it into /, as this is where they are put 
on the VFAT partition. If they are in the package, you can write an 
image recipe to install it via IMAGE_INSTALL, and via post process 
command you drop what is not necessary (/etc,...).


Anyway, as far as I know, an IMAGE_FSTYPES += "vfat" is not supported, 
you have also to add support for it.


rpi-bootfiles provides only part of the file set. The issue is that 
IMAGE_BOOT_FILES, which lists much more than what rpi-bootfiles 
provides, can be modified in the image recipe itself. It contains the 
kernel, devicetrees and configuration files as well.










What I want to do at update time is to write the new boot partition 
to another location on disk, and then adjust the partition table to 
make the first partition entry point to the new copy. That way, in 
case of unexpected failure (power loss for example), the device 
remains bootable.


This does not seem to be atomic. It remains the risk that partition 
table gets corrupted and then even the first bootloader cannot run. 
If you want to have a power-cut safe way to update is not enough.


It's not perfect but it's close enough. The partition table resides 
in a single sector, so chances of power-out at exactly this moment 
are small enough that I'm willing to take my chances here.


My experience is that there's more chance of the SD card completely 
dying because of power-out during some internal mumbojumbo than 
corrupting that partition table.


True, that is. So simply the hardware does not allow a safe update, 
point. Fully agree. Or use a very expensive industrial grade SD, but 
any board with eMMC is then cheaper.


I actually tried a few industrial grade SDs (usually SLC type). I had 
issues with those on other boards and the Pi is no exception. If I put 
one of those expensive SLC cards into the SD slot of the RPi4, there's 
about 30% chance that the board won't boot at all.





Against that SD failure there's nothing I can do...


Absolutely true.


Amen.

I'm going to let this thing rest for a while, maybe I'll come up with 
something completely different or maybe someone in this group has some 
brilliant idea...



--
Mike Looijmans


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

Re: [OE-core] Build the "boot" partition image (just like the rootfs)

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 15-03-2021 14:47, Stefano Babic wrote:

Hi Mike,

On 15.03.21 14:13, Mike Looijmans wrote:
For software updates, I want to have what would have gone into the 
boot partition of the WIC image as a separate file.


If I want to have the contents of the rootfs as an ext4 image, I can 
just specify IMAGE_TYPES="ext4" in my image recipe.

 > This image I can feed to SWUdate and write to the rootfs storage.

But I also want to be able to update the boot partition (for example, 
the raspberrypi has the annoying property that devicetree and kernel 
reside here).


This is very annoying, but you could also get rid of it. You can 
install kernel and device tree in your rootfs (then they are located 
in /boot as usual), and you switch to U-Boot ( RPI_USE_U_BOOT = "1"). 
The proprietary bootloader will start U-Boot instead of kernel, and in 
u-boot you can load kernel and device tree from your rootfs.


That's what I did on other boards, but for the RPi that's not enough. 
There's also firmware there, which interacts with the kernel, and the 
firmware is altering the devicetree too. It's pretty likely that the 
firmware needs an update too when the kernel gets a big update.







If I create a WIC image, the boot partition is in there with the 
proper files (from IMAGE_BOOT_FILES) so I would really like to re-use 
that code. I could create the wic image and then cut out the part I 
want, but that doesn't seem particularly nice.


You can add vfat support for IMAGE_FSTYPES, and then you can build an 
image (you can just take the files you have in IMAGE_BOOT_FILES).


But that's *exactly* my problem: How do I get these IMAGE_BOOT_FILES 
into an image of sorts? Just setting IMAGE_FSTYPE="vfat" will put the 
rootfs contents in there, not the bootfiles I'm after.






What I want to do at update time is to write the new boot partition 
to another location on disk, and then adjust the partition table to 
make the first partition entry point to the new copy. That way, in 
case of unexpected failure (power loss for example), the device 
remains bootable.


This does not seem to be atomic. It remains the risk that partition 
table gets corrupted and then even the first bootloader cannot run. If 
you want to have a power-cut safe way to update is not enough.


It's not perfect but it's close enough. The partition table resides in a 
single sector, so chances of power-out at exactly this moment are small 
enough that I'm willing to take my chances here.


My experience is that there's more chance of the SD card completely 
dying because of power-out during some internal mumbojumbo than 
corrupting that partition table. Against that SD failure there's nothing 
I can do...



--
Mike Looijmans


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

[OE-core] Build the "boot" partition image (just like the rootfs)

[Mike Looijmans]

For software updates, I want to have what would have gone into the boot 
partition of the WIC image as a separate file.


If I want to have the contents of the rootfs as an ext4 image, I can 
just specify IMAGE_TYPES="ext4" in my image recipe.


This image I can feed to SWUdate and write to the rootfs storage.

But I also want to be able to update the boot partition (for example, 
the raspberrypi has the annoying property that devicetree and kernel 
reside here).


If I create a WIC image, the boot partition is in there with the proper 
files (from IMAGE_BOOT_FILES) so I would really like to re-use that 
code. I could create the wic image and then cut out the part I want, but 
that doesn't seem particularly nice.


What I want to do at update time is to write the new boot partition to 
another location on disk, and then adjust the partition table to make 
the first partition entry point to the new copy. That way, in case of 
unexpected failure (power loss for example), the device remains bootable.



--
Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail

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

Re: [OE-core] GCC crashes on aarch64 since gatesgarth

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 12-03-2021 08:37, Mike Looijmans via lists.openembedded.org wrote:

On 12-03-2021 08:33, Khem Raj wrote:
On Thu, Mar 11, 2021 at 11:22 PM Mike Looijmans 
 wrote:


On 05-03-2021 00:32, Randy MacLeod wrote:

On 2021-02-05 2:49 a.m., Mike Looijmans wrote:

I've been doing quite some tests and things last week, my conclusion
so far is that the latest gcc seems to trigger a bug particular to
this CPU. Maybe even this particular batch.

Hours of testing found no issues with RAM.

I've also done huge amounts of builds with zeus, no problems.

Then googling for "illegal instruction gcc ryzen 1700" reveals quite
a few threads on something that sounds suspiciously similar. Though
it makes me wonder why I never encountered it before, since these are
all many years old. I did try a bunch of the suggestions done there,
but so far no luck.



Any update on this bug Mike?
Have you opened a YP bug? If not please do.
I'd like to see if the problem still happens on master.

Interesting.

I just built the 64-kernel using OE master and no crashes, everything
went fine. With the gatesgarth branch, it'd crash at least two times
during kernel compilation.

So something has been fixed since then?

can you try by disabling uninative ?


Probably, if only I knew what you mean by that?

What do I have to configure where?

As far as I can determine I think i'm not using unitative since I didn't 
explicitly enable it anywhere...


--
Mike Looijmans


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

Re: [OE-core] GCC crashes on aarch64 since gatesgarth

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 12-03-2021 08:33, Khem Raj wrote:

On Thu, Mar 11, 2021 at 11:22 PM Mike Looijmans  wrote:


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 05-03-2021 00:32, Randy MacLeod wrote:

On 2021-02-05 2:49 a.m., Mike Looijmans wrote:

I've been doing quite some tests and things last week, my conclusion
so far is that the latest gcc seems to trigger a bug particular to
this CPU. Maybe even this particular batch.

Hours of testing found no issues with RAM.

I've also done huge amounts of builds with zeus, no problems.

Then googling for "illegal instruction gcc ryzen 1700" reveals quite
a few threads on something that sounds suspiciously similar. Though
it makes me wonder why I never encountered it before, since these are
all many years old. I did try a bunch of the suggestions done there,
but so far no luck.



Any update on this bug Mike?
Have you opened a YP bug? If not please do.
I'd like to see if the problem still happens on master.

Interesting.

I just built the 64-kernel using OE master and no crashes, everything
went fine. With the gatesgarth branch, it'd crash at least two times
during kernel compilation.

So something has been fixed since then?

can you try by disabling uninative ?


Probably, if only I knew what you mean by that?

What do I have to configure where?



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

Re: [OE-core] GCC crashes on aarch64 since gatesgarth

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 05-03-2021 00:32, Randy MacLeod wrote:

On 2021-02-05 2:49 a.m., Mike Looijmans wrote:
I've been doing quite some tests and things last week, my conclusion 
so far is that the latest gcc seems to trigger a bug particular to 
this CPU. Maybe even this particular batch.


Hours of testing found no issues with RAM.

I've also done huge amounts of builds with zeus, no problems.

Then googling for "illegal instruction gcc ryzen 1700" reveals quite 
a few threads on something that sounds suspiciously similar. Though 
it makes me wonder why I never encountered it before, since these are 
all many years old. I did try a bunch of the suggestions done there, 
but so far no luck.





Any update on this bug Mike?
Have you opened a YP bug? If not please do.
I'd like to see if the problem still happens on master. 


Interesting.

I just built the 64-kernel using OE master and no crashes, everything 
went fine. With the gatesgarth branch, it'd crash at least two times 
during kernel compilation.


So something has been fixed since then?


--
Mike Looijmans


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

Re: [OE-core] GCC crashes on aarch64 since gatesgarth

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 05-03-2021 00:32, Randy MacLeod wrote:

On 2021-02-05 2:49 a.m., Mike Looijmans wrote:
I've been doing quite some tests and things last week, my conclusion so far 
is that the latest gcc seems to trigger a bug particular to this CPU. Maybe 
even this particular batch.


Hours of testing found no issues with RAM.

I've also done huge amounts of builds with zeus, no problems.

Then googling for "illegal instruction gcc ryzen 1700" reveals quite a few 
threads on something that sounds suspiciously similar. Though it makes me 
wonder why I never encountered it before, since these are all many years 
old. I did try a bunch of the suggestions done there, but so far no luck.





Any update on this bug Mike?
Have you opened a YP bug? If not please do.
I'd like to see if the problem still happens on master.


So far I've discovered that this only happens when compiling for an aarch64. 
When targetting 32-bit ARM the compiler crash does not occur.


I've contacted AMD for an RMA for my CPU, but it's out of warranty now. I plan 
to borrow a compatible CPU to see if that makes the problem go away. If it 
does I'll just buy a new CPU...


As an example, if I take the current gatesgarth branch and meta-raspberrypi, 
then building for "raspberrypi4" runs without a hitch. If I chose 
"raspberrypi4-64" as MACHINE, the build will crash multiple times, typically 
on large components like the linux kernel, qt and boost. It happens on both 
plain C (kernel, u-boot) and on C++ code (boost, Qt). The same applies to e.g. 
the Xilinx Zynq, building for the 7-series (cortex A9) is fine but building 
for the MPSoC (cortex A53) will crash.


A silly workaround is to run "while ! bitbake ... ; do echo again; done" which 
will retry until it succeeds.


I'd be very interested if there's anyone with Ryzen setup who can reproduce 
this, or fail to, which is also interesting to know.


I also tried building in tmpfs and on a different SSD to rule out the NVME as 
a cause.


I'll try the master branch too, and report back on that (tomorrow probably).




../Randy




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 27-01-2021 16:10, Mike Looijmans via lists.openembedded.org wrote:
When doing large builds, the GCC compiler tends to crash on random spots in 
the code. There are a few common denominators though.


It only happens when compiling for aarch64 (cortex-A53), not for 32-bit arm 
(cortex-A9)


It's random and usually happens on "big" sets like kernel, openssl, boost, 
u-boot etc.


It always reports "during GIMPLE pass: ealias" in the error, for example:

| during GIMPLE pass: ealias
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c: In function 'do_x509_check':
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c:1239:1: internal compiler error: 
Illegal instruction

| 1239 | }

Compiling the same thing again usually goes fine.

I've never experienced this with the zeus and older branches of OE.


I've already tried upgrading to the latest gatesgarth status, and cleaning 
out everything and start from scratch. I've also run "mprime" test on my 
machine (over one hour) just to be confident that the system itself is 
really okay.



Ideas to diagnose, fix or reliably reprodruce are more than welcome. 












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

Re: [OE-core] [gatesgarth][PATCH] license_image.bbclass: Don't attempt to symlink to the same file

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 05-02-2021 15:51, Mike Looijmans via lists.openembedded.org wrote:

On 05-02-2021 15:44, Mittal, Anuj wrote:

On Fri, 2021-02-05 at 15:24 +0100, Mike Looijmans wrote:

Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
   Exception: FileExistsError: [Errno 17] File exists: '/.../tmp-
glibc/deploy/licenses/my-image-tdkz15' -> '/.../tmp-
glibc/deploy/licenses/my-image-tdkz15'

First check to see if this is the case before attempting to create
the link.

Is this not required in master branch? I can't see this change there.


Probably yes, too.

And half the commit message got lost somewhere. I'll try a resend...


Oh weird... Apparently the company mailserver that did that. The version 
on the list is okay, the one in my mailbox lacks the first half of the 
commit text. Same with the v2 mail.



--
Mike Looijmans


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

[OE-core] [PATCH v2] license_image.bbclass: Don't attempt to symlink to the same file

[Mike Looijmans]

Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
  Exception: FileExistsError: [Errno 17] File exists: 
'/.../tmp-glibc/deploy/licenses/my-image-tdkz15' -> 
'/.../tmp-glibc/deploy/licenses/my-image-tdkz15'

First check to see if this is the case before attempting to create
the link.

Signed-off-by: Mike Looijmans 
---
v2: Resent, applies to master and gatesgarth

 meta/classes/license_image.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index 119c8dfc86..6f478ce22c 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -210,7 +210,8 @@ def license_deployed_manifest(d):
 os.unlink(lic_manifest_symlink_dir)
 
 # create the image dir symlink
-os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
+if lic_manifest_dir != lic_manifest_symlink_dir:
+os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
 
 def get_deployed_dependencies(d):
 """
-- 
2.17.1


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

Re: [OE-core] [gatesgarth][PATCH] license_image.bbclass: Don't attempt to symlink to the same file

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 05-02-2021 15:44, Mittal, Anuj wrote:

On Fri, 2021-02-05 at 15:24 +0100, Mike Looijmans wrote:

Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
   Exception: FileExistsError: [Errno 17] File exists: '/.../tmp-
glibc/deploy/licenses/my-image-tdkz15' -> '/.../tmp-
glibc/deploy/licenses/my-image-tdkz15'

First check to see if this is the case before attempting to create
the link.

Is this not required in master branch? I can't see this change there.


Probably yes, too.

And half the commit message got lost somewhere. I'll try a resend...


--
Mike Looijmans


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

[OE-core] [gatesgarth][PATCH] license_image.bbclass: Don't attempt to symlink to the same file

[Mike Looijmans]

Sometimes (that is, in all my builds) the lic_manifest_dir and
lic_manifest_symlink_dir end up pointing to the same file, resulting
in an error like this:
  Exception: FileExistsError: [Errno 17] File exists: 
'/.../tmp-glibc/deploy/licenses/my-image-tdkz15' -> 
'/.../tmp-glibc/deploy/licenses/my-image-tdkz15'

First check to see if this is the case before attempting to create
the link.

Signed-off-by: Mike Looijmans 
---
 meta/classes/license_image.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/license_image.bbclass 
b/meta/classes/license_image.bbclass
index 119c8dfc86..6f478ce22c 100644
--- a/meta/classes/license_image.bbclass
+++ b/meta/classes/license_image.bbclass
@@ -210,7 +210,8 @@ def license_deployed_manifest(d):
 os.unlink(lic_manifest_symlink_dir)
 
 # create the image dir symlink
-os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
+if lic_manifest_dir != lic_manifest_symlink_dir:
+os.symlink(lic_manifest_dir, lic_manifest_symlink_dir)
 
 def get_deployed_dependencies(d):
 """
-- 
2.17.1


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

Re: [OE-core] GCC crashes on aarch64 since gatesgarth

[Mike Looijmans]

I've been doing quite some tests and things last week, my conclusion so 
far is that the latest gcc seems to trigger a bug particular to this 
CPU. Maybe even this particular batch.


Hours of testing found no issues with RAM.

I've also done huge amounts of builds with zeus, no problems.

Then googling for "illegal instruction gcc ryzen 1700" reveals quite a 
few threads on something that sounds suspiciously similar. Though it 
makes me wonder why I never encountered it before, since these are all 
many years old. I did try a bunch of the suggestions done there, but so 
far no luck.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 27-01-2021 16:10, Mike Looijmans via lists.openembedded.org wrote:
When doing large builds, the GCC compiler tends to crash on random 
spots in the code. There are a few common denominators though.


It only happens when compiling for aarch64 (cortex-A53), not for 
32-bit arm (cortex-A9)


It's random and usually happens on "big" sets like kernel, openssl, 
boost, u-boot etc.


It always reports "during GIMPLE pass: ealias" in the error, for example:

| during GIMPLE pass: ealias
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c: In function 'do_x509_check':
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c:1239:1: internal compiler 
error: Illegal instruction

| 1239 | }

Compiling the same thing again usually goes fine.

I've never experienced this with the zeus and older branches of OE.


I've already tried upgrading to the latest gatesgarth status, and 
cleaning out everything and start from scratch. I've also run "mprime" 
test on my machine (over one hour) just to be confident that the 
system itself is really okay.



Ideas to diagnose, fix or reliably reprodruce are more than welcome. 


--
Mike Looijmans


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

Re: [OE-core] GCC crashes on aarch64 since gatesgarth

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 27-01-2021 16:43, Leon Woestenberg wrote:


Hello Mike,

At first sight, this does sound like memory corruption in one specific 
memory area (DIMM?) to me.


On itself, yes, that was my first thought too - hence running memory and 
system tests.
But it only happens with the gatesgarth branch. I've put loads of 
pressure on this machine's memory before, never got errors like that. I 
sometimes have multiple OE branches building at the same time too.



Check dmesg for tripping temperatures etc.
I would reduce both the amount of bitbake tasks and Makefile 
parallelism to 1 on a fresh run to reduce memory pressure.


Reducing somewhat, e.g. 8 each, did not make a difference. Didn't want 
to go to "1", it'll take days to rebuild then...


Not seen anything similar yet (MACHINE=zcu102, build host i7-10700K w/ 
128MB memory.)



Guess that's GB not MB :)

Mine is a Ryzen 7 1700 w/ 32GB.

CPU Temp doesn't rise above 70 degrees while building (during mprime 
testing it got up to 90, still within spec)



I would assume aarch64 is widely run by the community.


I would, too


Let me know if I must replicate a specific set of commits.


Don't know what you mean by that, can you explain?





Regards,

Leon.

On Wed, Jan 27, 2021 at 4:10 PM Mike Looijmans 
mailto:mike.looijm...@topic.nl>> wrote:


When doing large builds, the GCC compiler tends to crash on random
spots
in the code. There are a few common denominators though.

It only happens when compiling for aarch64 (cortex-A53), not for
32-bit
arm (cortex-A9)

It's random and usually happens on "big" sets like kernel, openssl,
boost, u-boot etc.

It always reports "during GIMPLE pass: ealias" in the error, for
example:

| during GIMPLE pass: ealias
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c: In function
'do_x509_check':
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c:1239:1: internal compiler
error: Illegal instruction
| 1239 | }

Compiling the same thing again usually goes fine.

I've never experienced this with the zeus and older branches of OE.


I've already tried upgrading to the latest gatesgarth status, and
cleaning out everything and start from scratch. I've also run
"mprime"
test on my machine (over one hour) just to be confident that the
system
itself is really okay.


Ideas to diagnose, fix or reliably reprodruce are more than welcome.

-- 
Mike Looijmans



    Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
<mailto:mike.looijm...@topicproducts.com>
W: www.topicproducts.com <http://www.topicproducts.com>

Please consider the environment before printing this e-mail





--
Mike Looijmans


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

[OE-core] GCC crashes on aarch64 since gatesgarth

[Mike Looijmans]

When doing large builds, the GCC compiler tends to crash on random spots 
in the code. There are a few common denominators though.


It only happens when compiling for aarch64 (cortex-A53), not for 32-bit 
arm (cortex-A9)


It's random and usually happens on "big" sets like kernel, openssl, 
boost, u-boot etc.


It always reports "during GIMPLE pass: ealias" in the error, for example:

| during GIMPLE pass: ealias
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c: In function 'do_x509_check':
| ../openssl-1.1.1i/crypto/x509v3/v3_utl.c:1239:1: internal compiler 
error: Illegal instruction

| 1239 | }

Compiling the same thing again usually goes fine.

I've never experienced this with the zeus and older branches of OE.


I've already tried upgrading to the latest gatesgarth status, and 
cleaning out everything and start from scratch. I've also run "mprime" 
test on my machine (over one hour) just to be confident that the system 
itself is really okay.



Ideas to diagnose, fix or reliably reprodruce are more than welcome.

--
Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail

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

Re: [OE-core] [PATCH 1/2] dropbear/openssh: Lower priority of key generation

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 18-09-2020 19:55, Richard Purdie via lists.openembedded.org wrote:

On Fri, 2020-09-18 at 10:45 -0700, Khem Raj wrote:

On 9/17/20 11:00 PM, Richard Purdie wrote:

Where we have images with PAM+systemd, serial login can be
extremely
slow. The load generated by key generation does slow down the rest
of the boot process.


this is a good find. So I wonder if its because we have entropy
starvation. I see that we do enable virtio-rng while launching qemu
so something to look in this area perhaps.

I did check and the virtio rng is alive and well in the image. Its the
CPU usage of the key generation that partly causes the issue.


Another solution is to just have it create smaller keys. The computation 
time seems to grow exponential with the bit count, a 2048 size key can 
take 10 times longer than a 1024 bit key to generate, and a 4096 may 
take 10x that again.


There's been a move to 4096 sizes keys lately, pushing the CPU use even 
further. Unless you're controlling a nuclear power plant or so, that's a 
bit excessive.


--
Mike Looijmans


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

Re: [OE-core] systemd-getty-generator present but undesired

[Mike Looijmans]

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
On 30-07-2020 07:12, Khem Raj wrote:



On 7/28/20 6:33 AM, Mike Looijmans wrote:
I had a hard time getting a serial attached bluetooth device to work, 
untilI discovered that systemd is running a "getty" on that port 
(which happens tobe "ttyS0").


The cause is that "systemd-getty-generator" detects that the port 
comes online (runtime, it's inside an FGPA) and then dynamically adds 
a service for it and starts a getty on it.


So when I went to solve that, I found that OE already attempted to 
solve that. There's a "systemd-getty-generator" PACKAGECONFIG that 
suggests that it should not be installed by default, but it gets 
installed anyway, even though this config is not set.


Is this something that needs fixing in OE?

Any better pointers at preventing systemd starting a getty on ttyS0?



you need to add serial-getty-generator to systemd PACKAGECONFIG to 
ignore the oe provided serial getty recipe.


I think it also has to do with SERIAL_CONSOLES setting for machine, 
perhaps it contains ttyS0 in your case.



Yes, SERIAL_CONSOLES is the problem.

It interacts with SERIAL_CONSOLE in strange ways, and the only way to 
solve it was to set them both and never calculate them:


SERIAL_CONSOLE = "115200 ttyPS0"
SERIAL_CONSOLES = "115200;ttyPS0"


One would be tempted to code something like:

SERIAL_CONSOLES = "${@d.getVar('SERIAL_CONSOLE').replace(' ', ';')}"

(In fact this is what bitbake.conf does, only very weakly.)

This does not work, and results in "ttyS0" still ending up in 
SERIAL_CONSOLES. Probably an interesting mix of calculating one from the 
other.



oe-core/meta/recipes-core/systemd/systemd-serialgetty.bb contains a line:

SERIAL_CONSOLES ?= "115200;ttyS0"

This is also broken I think, it overrides the more correct default that 
bitbake.conf already assigned. Removing this line didn't solve the issue 
either.




Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail





--
Mike Looijmans

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141371): 
https://lists.openembedded.org/g/openembedded-core/message/141371
Mute This Topic: https://lists.openembedded.org/mt/75843935/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] systemd-getty-generator present but undesired

[Mike Looijmans]

I had a hard time getting a serial attached bluetooth device to work, untilI 
discovered that systemd is running a "getty" on that port (which happens tobe 
"ttyS0").


The cause is that "systemd-getty-generator" detects that the port comes online 
(runtime, it's inside an FGPA) and then dynamically adds a service for it and 
starts a getty on it.


So when I went to solve that, I found that OE already attempted to solve that. 
There's a "systemd-getty-generator" PACKAGECONFIG that suggests that it should 
not be installed by default, but it gets installed anyway, even though this 
config is not set.


Is this something that needs fixing in OE?

Any better pointers at preventing systemd starting a getty on ttyS0?

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail

Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topicproducts.com

Please consider the environment before printing this e-mail
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#141062): 
https://lists.openembedded.org/g/openembedded-core/message/141062
Mute This Topic: https://lists.openembedded.org/mt/75843935/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] populate_sdk and conflicting "dev" packages

[Mike Looijmans]

I have a recurring issue with populate_sdk and alternatives. If I 
install dropbear-ssh-server and openssh-sftp-server on an image, that 
works just fine. But when creating the SDK, I get the warning below.


Issue #1 is that this is a "warning" but should have been an error. The 
SDK just continues missing a few hundred packages and end up being unusable.


Issue #2 is that I cannot figure out a way to get rid of this error. I 
can't find a way to remove openssh-dev from the package list that the 
SDK wants to install.


Using the "zeus" branch by the way.


Collected errors:
 * Solver encountered 1 problem(s):
 * Problem 1/1:
 *   - package openssh-dev-8.0p1-r0.aarch64 requires openssh = 
8.0p1-r0, but none of the providers can be installed

 *
 * Solution 1:
 *   - allow deinstallation of packagegroup-core-ssh-dropbear-1.0-r1.all

 *   - do not ask to install a package providing dropbear-dev

 *   - do not ask to install a package providing 
packagegroup-core-ssh-dropbear-dev


 * Solution 2:
 *   - do not ask to install a package providing openssh-dev

--
Mike Looijmans

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#137401): 
https://lists.openembedded.org/g/openembedded-core/message/137401
Mute This Topic: https://lists.openembedded.org/mt/73213646/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] classes/populate_sdk_base: Implement xz compression options

[Mike Looijmans]

On 19-03-2020 12:37, Adrian Bunk wrote:

On Wed, Mar 18, 2020 at 01:21:56PM +0100, Mike Looijmans wrote:

Building an SDK on a machine with 8GB RAM resulted in excessive swapping
due to the xz compressor using ~20GB of memory. This is because xz is
being called with "-T 0 -9".

To allow tuning the compression versus memory usage, introduce a variable
named SDK_XZ_OPTIONS that defaults to a more sane default:
SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"
Thus, inherit any XZ tuning already done, and allow users to specify
overrides for this task in their config by supplying SDK_XZ_OPTIONS.
Since XZ_COMPRESSION_LEVEL defaults to -9 this does not change the standard
behavior.
...
+SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"


A problem is that XZ_COMPRESSION_LEVEL compression would now be used for
unrelated usecases, and lowering the compression for being able to boot
on low-end targets (<= 64 MB RAM) shouldn't impact the SDK.


Clear. I wasn't aware that this was for the targets...




...
-   d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar 
${SDKTAROPTS} -cf - . | xz -T 0 -9 > 
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
+   d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar 
${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > 
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
...


Replacing "-T 0" with ${XZ_DEFAULTS} should solve your problem.
This already takes both cpus and memory into account.


I'd still want to have control over that -9 though.

It's not worth it to spend 15 minutes compressing just a few megabytes 
better in a development environment.



--
Mike Looijmans
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH v2] classes/populate_sdk_base: Implement xz compression options

[Mike Looijmans]

Building an SDK on a machine with 8GB RAM resulted in excessive swapping
due to the xz compressor using ~20GB of memory. This is because xz is
being called with "-T 0 -9".

To allow tuning the compression versus memory usage, introduce a variable
named SDK_XZ_OPTIONS that defaults to a more sane default:
SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${SDK_XZ_COMPRESSION_LEVEL}"
The use of XZ_DEFAULTS fixes the excessive memory usage.
The SDK_XZ_COMPRESSION_LEVEL variable allows overriding the speed vs
compression. In an office or development environment the extra time
spent on compressing a few percent more is just not worth it.

Signed-off-by: Mike Looijmans 
---
 meta/classes/populate_sdk_base.bbclass | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index d03465b6fc..179ed93979 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -48,6 +48,8 @@ TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
 
 # Default archived SDK's suffix
 SDK_ARCHIVE_TYPE ?= "tar.xz"
+SDK_XZ_COMPRESSION_LEVEL ?= "-9"
+SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${SDK_XZ_COMPRESSION_LEVEL}"
 
 # To support different sdk type according to SDK_ARCHIVE_TYPE, now support zip 
and tar.xz
 python () {
@@ -58,7 +60,7 @@ python () {
d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip -r 
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
 else:
d.setVar('SDK_ARCHIVE_DEPENDS', 'xz-native')
-   d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar 
${SDKTAROPTS} -cf - . | xz -T 0 -9 > 
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
+   d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar 
${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > 
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
 }
 
 SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] classes/populate_sdk_base: Implement xz compression options

[Mike Looijmans]

Building an SDK on a machine with 8GB RAM resulted in excessive swapping
due to the xz compressor using ~20GB of memory. This is because xz is
being called with "-T 0 -9".

To allow tuning the compression versus memory usage, introduce a variable
named SDK_XZ_OPTIONS that defaults to a more sane default:
SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"
Thus, inherit any XZ tuning already done, and allow users to specify
overrides for this task in their config by supplying SDK_XZ_OPTIONS.
Since XZ_COMPRESSION_LEVEL defaults to -9 this does not change the standard
behavior.

Signed-off-by: Mike Looijmans 
---
 meta/classes/populate_sdk_base.bbclass | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index d03465b6fc..13247e42e5 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -48,6 +48,7 @@ TOOLCHAIN_OUTPUTNAME ?= "${SDK_NAME}-toolchain-${SDK_VERSION}"
 
 # Default archived SDK's suffix
 SDK_ARCHIVE_TYPE ?= "tar.xz"
+SDK_XZ_OPTIONS ?= "${XZ_DEFAULTS} ${XZ_COMPRESSION_LEVEL}"
 
 # To support different sdk type according to SDK_ARCHIVE_TYPE, now support zip 
and tar.xz
 python () {
@@ -58,7 +59,7 @@ python () {
d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; zip -r 
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE} .')
 else:
d.setVar('SDK_ARCHIVE_DEPENDS', 'xz-native')
-   d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar 
${SDKTAROPTS} -cf - . | xz -T 0 -9 > 
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
+   d.setVar('SDK_ARCHIVE_CMD', 'cd ${SDK_OUTPUT}/${SDKPATH}; tar 
${SDKTAROPTS} -cf - . | xz ${SDK_XZ_OPTIONS} > 
${SDKDEPLOYDIR}/${TOOLCHAIN_OUTPUTNAME}.${SDK_ARCHIVE_TYPE}')
 }
 
 SDK_RDEPENDS = "${TOOLCHAIN_TARGET_TASK} ${TOOLCHAIN_HOST_TASK}"
-- 
2.17.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Getting "File name too long" errors in warrior for sstate-cache names

[Mike Looijmans]

Starting with warrior build, I'm getting build fails due to "File name too 
long" in sstate-cache filenames. This is probably related to having long names 
for machines, but this did not happen in previous releases. For example:

OSError: [Errno 36] File name too long: 
'/mnt/.../sstate-cache/52/sigtask.9u_r4yv2' -> 
'/mnt/.../sstate-cache/52/sstate:u-boot-xlnx:topic_miamilite_florida_test_xc7z010-oe-linux-gnueabi:v2019.01-xilinx-v2019.1+gitAUTOINC+d895ac5e94:r0:topic_miamilite_florida_test_xc7z010:3:52cb29cef3922da53a752f38e9bbfdef878af51813dc095d9c1451d572844f93_prepare_recipe_sysroot.tgz.siginfo'


What can I do about this? There's no hint in the error message and searching 
for the message text doesn't show much except issues with crypto filesystems, 
which doesn't apply. The filesystem is just plain ext4.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] SDK does not contain pkg-config files

[Mike Looijmans]

On 31-07-19 15:29, Ross Burton wrote:
> On 31/07/2019 14:22, Mike Looijmans wrote:
>> Well, that's at least good to know.
>>
>> I'm on the "thud" branch currently, so I hope this isn't something that got
>> fixed only recently.
>>
>> I'll try some simple images first. I gather there's no particular magic
>> incantation I need to put into my image recipe to get the pkg-config files
>> into the SDK sysroot?
> 
> Right, they're just in the -dev packages.  I'd try building a 
> core-image-minimal SDK to verify that works, as I suspect you've done 
> something in your image to break the SDK.

I think I found it.

The image installs the dropbear SSH server, and the openssh-sftp-server. These 
seem to cause a conflict, and then ALL the "-dev" packages get skipped.

The warning looks like this (I removed some sensitive information and a list 
of a few hundred package names):


WARNING: prolira-delirium-image-1.0-r0 do_populate_sdk: Unable to install 
packages. Command '.../..-image/1.0-r0/recipe-sysroot-native/usr/bin/opkg 
--volatile-cache -f ... --force_postinstall --prefer-arch-to-version   install 
... binutils-dev liblzo2-dev ... libaio-dev' returned 1:
Collected errors:
  * Solver encountered 1 problem(s):
  * Problem 1/1:
  *   - package openssh-dev-7.8p1+git-r0.cortexa9t2hf-neon requires openssh = 
7.8p1+git-r0, but none of the providers can be installed
  *
  * Solution 1:
  *   - allow deinstallation of packagegroup-core-ssh-dropbear-1.0-r1.all

  *   - do not ask to install a package providing dropbear-dev

  *   - do not ask to install a package providing 
packagegroup-core-ssh-dropbear-dev

  * Solution 2:
  *   - do not ask to install a package providing openssh-dev



If I remove "openssh-sftp-server" from the packages, the warning (which should 
have been an error?) disappears and the resulting SDK properly contains all 
the pkg-config files again.

I wonder if there's a proper fix to prevent this, i.e. break the link between 
openssh-sftp-server and openssh-dev.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] SDK does not contain pkg-config files

[Mike Looijmans]

On 31-07-19 14:37, Ross Burton wrote:
> On 31/07/2019 06:47, Mike Looijmans wrote:
>> I'm trying to get the SDK to work, but no success because the SDK apparently
>> does not install any pkg-config file, resulting in autotools and cmake not
>> being able to find any library.
>>
>> Built the SDK using "bitbake -c populate_sdk image"
>>
>> Install the resulting SDK, and source the shell script.
>>
>> Building "helloworld" works. Building something slightly more advanced fails,
>> because pkg-config isn't working: "pkg-config --list-all" is empty.
>>
>> The cause is that the pkgconfig files simply aren't in the sysroot:
>>
>> $ echo $PKG_CONFIG_PATH
>> /home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/pkgconfig:/home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/share/pkgconfig
>>  
>>
>> $ ls 
>> /home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/pkgconfig
>> ls: cannot access
>> '/home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/pkgconfig':
>> No such file or directory
>> $ ls 
>> /home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/share/pkgconfig
>> ls: cannot access
>> '/home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/share/pkgconfig':
>> No such file or directory
> 
> Looks like something went wrong.
> 
> My host has minimal -dev packages installed:
> 
> $ dpkg -l \*-dev|grep ii
> ii  dpkg-dev  1.19.7    all  Debian package 
> development tools
> ii  libc6-dev:amd64   2.28-10   amd64    GNU C Library: 
> Development Libraries and Header Files
> ii  libgcc-8-dev:amd64    8.3.0-6   amd64    GCC support 
> library (development files)
> ii  libstdc++-8-dev:amd64 8.3.0-6   amd64    GNU Standard C++ 
> Library v3 (development files)
> ii  linux-libc-dev:amd64  4.19.37-5+deb10u1 amd64    Linux support 
> headers for userspace development
> ii  manpages-dev  4.16-2    all  Manual pages 
> about using GNU/Linux for development
> 
> But inside a core-image-minimal SDK:
> 
> $ ls sysroots/corei7-64-poky-linux/usr/lib/pkgconfig/ | head
> blkid.pc
> check.pc
> com_err.pc
> dbus-1.pc
> dbus-glib-1.pc
> e2p.pc
> expat.pc
> ext2fs.pc
> fdisk.pc
> form.pc
> 
> $ pkg-config  --list-all | head
> zlib  zlib - zlib compression library
> gio-unix-2.0  GIO unix specific APIs - unix specific headers for glib 
> I/O library
> libdw libdw - elfutils library for DWARF data and ELF file or 
> process inspection
> libkmod   libkmod - Library to deal with kernel modules
> applewmproto  AppleWMProto - AppleWM extension headers
> gio-2.0   GIO - glib I/O library
> dbus-glib-1   dbus-glib - GLib integration for the free desktop 
> message bus
> xf86dgaproto  XF86DGAProto - XF86DGA extension headers
> rpm   RPM - RPM Package Manager
> xcb-composite XCB Composite - XCB Composite Extension
> 
> So, works for me?

Well, that's at least good to know.

I'm on the "thud" branch currently, so I hope this isn't something that got 
fixed only recently.

I'll try some simple images first. I gather there's no particular magic 
incantation I need to put into my image recipe to get the pkg-config files 
into the SDK sysroot?

--
M.
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] SDK does not contain pkg-config files

[Mike Looijmans]

I'm trying to get the SDK to work, but no success because the SDK apparently 
does not install any pkg-config file, resulting in autotools and cmake not 
being able to find any library.

Built the SDK using "bitbake -c populate_sdk image"

Install the resulting SDK, and source the shell script.

Building "helloworld" works. Building something slightly more advanced fails, 
because pkg-config isn't working: "pkg-config --list-all" is empty.

The cause is that the pkgconfig files simply aren't in the sysroot:

$ echo $PKG_CONFIG_PATH
/home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/pkgconfig:/home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/share/pkgconfig
$ ls /home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/pkgconfig
ls: cannot access 
'/home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/lib/pkgconfig': 
No such file or directory
$ ls 
/home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/share/pkgconfig
ls: cannot access 
'/home/mike/p/sysroots/cortexa9t2hf-neon-oe-linux-gnueabi/usr/share/pkgconfig': 
No such file or directory

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Cannot get bitbake multiconfig to work

[Mike Looijmans]

I think I've done everything, but cannot figure out what step I missed.

I am using yesterday's "thud" branches:

BB_VERSION   = "1.40.0"
BUILD_SYS= "x86_64-linux"
meta = "HEAD:fbb688ab3eeca1bbfbffd8c81fd8052bcc68"
meta-oe
meta-multimedia
meta-networking
meta-python  = "HEAD:6ef9657068492d4644079c88f2adee9c3cac9543"


I created a conf/multiconf directory with a "pmu.conf" file (and others)

$ cat conf/multiconfig/pmu.conf
MACHINE="zynqmp-pmu"
DISTRO="xilinx-standalone"
GCCVERSION="7.%"
TMPDIR="${TOPDIR}/pmutmp"

I added to my local.conf (and removed the MACHINE setting there):

BBMULTICONFIG = "pmu ..."

Now when I invoke bitbake with the multiconfig syntax, it completely ignores 
that:

$ bitbake multiconfig:pmu:pmu-firmware
ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
 Either fix the cause of this error or at your own risk disable the 
checker (see sanity.conf).
 Following is the list of potential problems / advisories:

 Please set a MACHINE in your local.conf or environment


Apparently, bitbake doesn't even care about the "multiconfig:" syntax, I get 
the same response when I type:
$ bitbake multiconfig:blah:pmu-firmware
$ bitbake multiconfig:blah:blah
$ bitbake blah:blah:blah

I can add a "MACHINE?=" to local.conf, which results in a build for that 
machine and nothing from the pmu.conf gets ever used at all.

So what step did I miss?

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] wic creates ext4 images that read really slow in u-boot

[Mike Looijmans]

On 19-02-19 21:45, Leon Woestenberg wrote:
> Hello all,
> 
> On Tue, Feb 19, 2019 at 8:28 PM Andre McCurdy  wrote:
>> On Tue, Feb 19, 2019 at 9:13 AM Leon Woestenberg  wrote:
>>>
>>> Hello Mike,
>>>
>>> sounds familiar.
>>>
>>> On Tue, 19 Feb 2019 at 17:55, Mike Looijmans  
>>> wrote:
>>>>
>>>> Took me a while to figure out why my board took 90 seconds to boot 
>>>> suddenly.
>>>> The issue turned out to be the ext4 partition created by wic.
>>>
>>> I suspect it's not WIC's fault.
>>>>
>>>> ZynqMP> load mmc 0:2 0x10 /lib/firmware/fpga.bin
>>>> 19311092 bytes read in 85529 ms (219.7 KiB/s)
>>>>
>>>> Now if I boot the board rename and copy that file onto itself, then it's
>>>> suddenly normal again when I reboot the board:
>>>>
>>>> ZynqMP> load mmc 0:2 0x1
>>>> I'm not knowledgeable on ext4, so any ideas what's being passed onto the 
>>>> image
>>>> creation tool that causes this?
>>>
>>> I suspect your version of U-Boot does not handle files spread across 
>>> multiple filesystems (allocation) extends efficiently.
>>>
>>> Copying the file makes the copy being layed out in one extend probably.
>>
>>
>> If WIC is generating filesystem images from scratch there's no excuse for 
>> files to be unnecessarily fragmented.
>>
>> Even if some of all of the boot time can be recovered by a patch to u-boot 
>> that won't help systems which have already been deployed and don't have a 
>> way to update the bootloader.
>>
> I am not sure if "fragmented" is the right term in terms of filesystem
> details. Filesystem allocation extents (not "extends" as I mistyped
> earlier) are different from heavy file fragmentation. However, I agree
> things can be made more optimal.
> 
> So, with adding the above, there are *two* issues at play here:
> 1) Most/older versions of U-Boot not able to efficiently load files
> from ext4 filesystems, that cross multiple extents. I am aware of two
> fixes, see below.
> 2) WIC uses mkext4fs in such a way that files can cross multiple
> (allocation) extents. This is sub-optimal and know to cause issues
> with many U-Boot versions (deployed on existing systems in the field).
> The problems shows "randomly" with large files being deployed to the
> ext4 filesystem. We (OE/Yocto) may want to fix this.

That'd be best. One would expect that creating a filesystem "offline" would 
yield something optimal in terms of the way files are allocated, since 
everything about all files is already known when it's written.

My current workaround is to just mount the device and unpack the rootfs tar 
onto that, which yields a filesystem that u-boot can read at normal speed.


>>> I am aware of two fixes for U-Boot. I will look them up, and reply again to 
>>> this thread.
> 
> Google for these two commits. I cherry-picked the first one for my
> project and can confirm it brings back the desired performance. (Still
> assuming this is the identical cause as for TO/Mike.)
> 
> commit 855b8e4f9f255415a7753819e392e4b5d984f35c
> Author: Matt Madison 
> Date:   Sat Aug 19 08:46:46 2017 -0700
> 
>  ext4: cache extent blocks during file reads
> 
>  A simpler and less-efficient approach to solving
>  the problem with extent index blocks than what
>  was in fc0fc50f38a4d7d0554558076a79dfe8b0d78cd5,
>  but one that does not break write operations.
> 
>  Signed-off-by: Matt Madison 

I'll give it a try...

You mentioned "two" commits?
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] wic creates ext4 images that read really slow in u-boot

[Mike Looijmans]

>>> I am aware of two fixes for U-Boot. I will look them up, and reply again to 
>>> this thread.

Browsing through u-boot commits, I found this gem that's disabled by default:

CONFIG_BLOCK_CACHE=y

The commit is this one:

commit e40cf34a29f1b248643731a11fb1c6f0520d016c
Author: Eric Nelson 
Date:   Mon Mar 28 10:05:44 2016 -0700

 drivers: block: add block device cache

 Add a block device cache to speed up repeated reads of block devices by
 various filesystems.

 This small amount of cache can dramatically speed up filesystem
 operations by skipping repeated reads of common areas of a block
 device (typically directory structures).

 This has shown to have some benefit on FAT filesystem operations of
 loading a kernel and RAM disk, but more dramatic benefits on ext4
 filesystems when the kernel and/or RAM disk are spread across
 multiple extent header structures as described in commit fc0fc50.
...

I'll be giving that a test drive soon...
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] wic creates ext4 images that read really slow in u-boot

[Mike Looijmans]

Took me a while to figure out why my board took 90 seconds to boot suddenly.

The issue turned out to be the ext4 partition created by wic.

On a "wic" created ext4 disk, this is what u-boot does:

ZynqMP> load mmc 0:2 0x10 /lib/firmware/fpga.bin
19311092 bytes read in 85529 ms (219.7 KiB/s)


Now if I boot the board rename and copy that file onto itself, then it's 
suddenly normal again when I reboot the board:

ZynqMP> load mmc 0:2 0x10 /lib/firmware/fpga.bin
19311092 bytes read in 1426 ms (12.9 MiB/s)


I checked with other files, and it turns out that ANY big file written by wic 
will read very slow (at 200k/s) but if I make a copy from a running system, it 
suddenly reads fast.

I'm not knowledgeable on ext4, so any ideas what's being passed onto the image 
creation tool that causes this?

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH v2] initscripts: populate-volatiles: Speed up processing

[Mike Looijmans]

On 12-10-18 18:24, Joshua Watt wrote:
> Checking the requirements for each volatiles file in the
> populate-volatiles script can be very slow when there are a large number
> of volatiles files, easily consuming over 80% of the processing time.
> These checks don't usually uncover any problems so concatenate all the
> volatiles files together and process them as one large file for a "fast
> path" option. This ensures that the penalty for checking the
> requirements is only incurred once. In the event that checking the
> requirements for the unified file fails, fall back to the slow process
> of checking each one individually so that the offending one can be
> skipped.
> 
> The core file is handled separately because it is responsible for
> creating the temp directory used by check_requirements and thus must
> always run first and without having its requirements checked.
> 
> [YOCTO #12949]
> 
> Signed-off-by: Joshua Watt 
> ---
>   .../initscripts-1.0/populate-volatile.sh  | 37 +--
>   1 file changed, 33 insertions(+), 4 deletions(-)
> 
> diff --git 
> a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh 
> b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> index 35316ec2baa..824f8f3a6ba 100755
> --- a/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> +++ b/meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh
> @@ -112,7 +112,6 @@ check_requirements() {
>   }
>   
>   CFGFILE="$1"
> - [ `basename "${CFGFILE}"` = "${COREDEF}" ] && return 0
>   
>   TMP_INTERMED="${TMPROOT}/tmp.$$"
>   TMP_DEFINED="${TMPROOT}/tmpdefined.$$"
> @@ -154,8 +153,11 @@ check_requirements() {
>   
>   apply_cfgfile() {
>   CFGFILE="$1"
> + SKIP_REQUIREMENTS="$2"
>   
> - check_requirements "${CFGFILE}" || {
> + [ "${VERBOSE}" != "no" ] && echo "Applying ${CFGFILE}"
> +
> + [ "${SKIP_REQUIREMENTS}" == "yes" ] || check_requirements "${CFGFILE}" 
> || {
>   echo "Skipping ${CFGFILE}"
>   return 1
>   }
> @@ -231,10 +233,37 @@ then
>   sh ${ROOT_DIR}/etc/volatile.cache
>   else
>   rm -f ${ROOT_DIR}/etc/volatile.cache 
> ${ROOT_DIR}/etc/volatile.cache.build
> - for file in `ls -1 "${CFGDIR}" | sort`; do
> - apply_cfgfile "${CFGDIR}/${file}"
> +
> + # Apply the core file with out checking requirements. ${TMPROOT} is
> + # needed by check_requirements but is setup by this file, so it must be
> + # processed first and without being checked.
> + [ -e "${CFGDIR}/${COREDEF}" ] && apply_cfgfile "${CFGDIR}/${COREDEF}" 
> "yes"
> +
> + # Fast path: check_requirements is slow and most of the time doesn't
> + # find any problems. If there are a lot of config files, it is much
> + # faster to to concatenate them all together and process them once to
> + # avoid the overhead of calling check_requirements repeatedly
> + TMP_FILE="${TMPROOT}/tmp_volatile.$$"
> + rm -f "$TMP_FILE"
> +
> + CFGFILES="`ls -1 "${CFGDIR}" | grep -v "^${COREDEF}\$" | sort`"
> + for file in ${CFGFILES}; do
> + cat "${CFGDIR}/${file}" >> "$TMP_FILE"
>   done

You can replace that loop with this:

cat `ls -1 "${CFGDIR}" | grep -v "^${COREDEF}\$" | sort` > "$TMP_FILE"

(And the ">" instead of ">>" makes that you can remove the "rm" command as 
well.)

>   
> + if check_requirements "$TMP_FILE"
> + then
> + apply_cfgfile "$TMP_FILE" "yes"
> + else
> + # Slow path: One or more config files failed requirements.
> + # Process each one individually so the offending one can be
> + # skipped
> + for file in ${CFGFILES}; do
> + apply_cfgfile "${CFGDIR}/${file}"
> + done
> + fi
> + rm "$TMP_FILE"
> +
>   [ -e ${ROOT_DIR}/etc/volatile.cache.build ] && sync && mv 
> ${ROOT_DIR}/etc/volatile.cache.build ${ROOT_DIR}/etc/volatile.cache
>   fi
>   
> 

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC 3/3] linux-firmware: MACHINEOVERRIDES for BCM43430 NVRAM

[Mike Looijmans]

I think this should be solved in the driver actually. It probably "knows" 
which variant is there (or could be taught using devicetree or so).


On 24-08-18 11:04, Martin Jansa wrote:

One way to keep it allarch would be to package
${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt
${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt
in 2 separate packages and handle
${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
symlink with update-alternatives

most MACHINEs won't install either of these packages and those which need it 
will pull the right one (e.g. through MACHINE_EXTRA_RRECOMMENDS).


In worst case someone will try to install both packages and based on u-a 
priority one of them will win (use higher priority for the more common version).


Cheers,

On Fri, Aug 24, 2018 at 4:53 AM Andre McCurdy > wrote:


On Thu, Aug 23, 2018 at 1:15 AM, Ryan Harkin mailto:ryan.har...@linaro.org>> wrote:
 >
 > So now the ln issue is resolved, I'm not convinced my MACHINEOVERRIDES is
 > the correct approach. Does anyone have any feedback on how I can improve
 > that?

If you want to make a configurable symlink then perhaps the more usual
approach would be to just use a variable in the linux-firmware recipe
to weakly define a default target for the symlink. Machine config
files could then either do nothing (ie use the default) or provide
their own value. For example, in the linux-firmware recipe:

   BCM43430_NVRAM_SYMLINK ?= "brcmfmac43430-sdio.AP6212.txt"

   FILES_${PN}-bcm43430-nvram = " \
     ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt \
     ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.AP6212.txt \
     ${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.MUR1DX.txt \
   "

   do_install() {
     ...
     ln -sf ${BCM43430_NVRAM_SYMLINK}
${D}${nonarch_base_libdir}/firmware/brcm/brcmfmac43430-sdio.txt
   }

And then in the machine config files of machines which need the MUR1DX
firmware instead of the default, add:

   BCM43430_NVRAM_SYMLINK = "brcmfmac43430-sdio.MUR1DX.txt"

However... note that currently the linux-firmware recipe is
architecture independent (ie it won't be rebuilt if the target is
changed). Adding a machine specific symlink is going to cause problems
with that, so the above is still not a full solution.





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] busybox/mdev-mount.sh: Fix partition detect and cleanup mountpoint on fail

[Mike Looijmans]

This fixes issues mainly seen when mounting eMMC devices:

The wildcard /sys/block/${DEVBASE}/${DEVBASE}*1 matches both "mmcblk0p1"
and "mmcblk0boot1" for example, and this results in syntax errors. Fix this
by searching for a "partition" file instead, which only exists for real
partitions and not 'fakes' like the eMMC extra's.

When mount fails, the mountpoint file is left behind, causing later attempts
at auto-mounting it to fail. If mount fails, remove the mountpoint, leaving
the system in the state as it was before the mount attempt.

Signed-off-by: Mike Looijmans 
---
 meta/recipes-core/busybox/files/mdev-mount.sh | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/busybox/files/mdev-mount.sh 
b/meta/recipes-core/busybox/files/mdev-mount.sh
index b4385a1..130e947 100644
--- a/meta/recipes-core/busybox/files/mdev-mount.sh
+++ b/meta/recipes-core/busybox/files/mdev-mount.sh
@@ -25,7 +25,7 @@ case "$ACTION" in
fi
# check for full-disk partition
if [ "${DEVBASE}" = "${MDEV}" ] ; then
-   if [ -d /sys/block/${DEVBASE}/${DEVBASE}*1 ] ; then
+   if [ -f /sys/block/${DEVBASE}/${DEVBASE}*1/partition ] 
; then
# Partition detected, just quit
exit 0
fi
@@ -43,7 +43,7 @@ case "$ACTION" in
then
MOUNTPOINT="${MDEV_AUTOMOUNT_ROOT}/$MDEV"
mkdir -p "$MOUNTPOINT"
-   mount -t auto /dev/$MDEV "$MOUNTPOINT"
+   mount -t auto /dev/$MDEV "$MOUNTPOINT" || rmdir 
"$MOUNTPOINT"
fi
;;
remove)
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] openssh: Add dependency on ssh for sftp

[Mike Looijmans]

On 02-07-18 23:13, Richard Purdie wrote:

On Mon, 2018-07-02 at 18:44 +0100, Alex Kiernan wrote:

On Mon, Jul 2, 2018 at 4:06 PM Alex Kiernan 
wrote:


On Mon, Jul 2, 2018 at 3:55 PM Mike Looijmans  wrote:


The sftp-server runs fine using dropbear as SSH backend, I'd
expect the same
to be true for the client. Isn't that the case, and will the sftp
client only
work with openssh's ssh?



Interesting question... I hadn't realised dropbear didn't have an
sftp
client, but it's clearly a supported combination:

https://github.com/mkj/dropbear/blob/1656db9e58e7e8188e4ca27ae4892b
14949c56a5/dbclient.1#L159

I'll amend the patch so it depends on ssh not ${PN}-ssh since both
dropbear and openssh provide that.



Hmm... only that gets you this warning:

NOTE: Multiple providers are available for runtime ssh (dropbear,
openssh)
Consider defining a PREFERRED_RPROVIDER entry to match ssh

If you've not set it, which feels like a pretty poor upgrade
experience; I'm not sure how best to deal with that.


This is not an easy problem to solve. This is why we have the horrible
VIRTUAL-RUNTIME_* variables, I wish there were a better way...

Basically, bitbake has to have some idea which one to build, letting
the package manager decide at do_rootfs time isn't really good enough
for deterministic builds.


The dropbear/ssh choice seems to be one that is being postponed until image 
creation time. There's an IMAGE_FEATURE that appears to make the choice:

IMAGE_FEATURES += "ssh-server-dropbear"

Since you're building openssh already, there's no need to instruct bitbake to 
build more at package compile time.


Using RDEPENDS and PREFERRED_RPROVIDER or VIRTUAL-RUNTIME will 'break' a lot 
of existing setups by installing the wrong ssh client without the engineer 
knowing about it. And it will also make it impossible to build two images with 
different choices. I can imaging you'd want to have a small size "recover" 
image with dropbear and a large size "full" image with openssh in the same 
build for the same machine and distro.


M.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [OE-Core][PATCH] openssh: Add dependency on ssh for sftp

[Mike Looijmans]

The sftp-server runs fine using dropbear as SSH backend, I'd expect the same 
to be true for the client. Isn't that the case, and will the sftp client only 
work with openssh's ssh?


On 01-07-18 12:33, Alex Kiernan wrote:

Add missing dependency on the ssh binary for the sftp client to avoid
failure at runtime if it's not been installed through another dependency
chain.

Signed-off-by: Alex Kiernan 
---

  meta/recipes-connectivity/openssh/openssh_7.7p1.bb | 1 +
  1 file changed, 1 insertion(+)

diff --git a/meta/recipes-connectivity/openssh/openssh_7.7p1.bb 
b/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
index b3da5f6..d147f43 100644
--- a/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_7.7p1.bb
@@ -146,6 +146,7 @@ FILES_${PN}-keygen = "${bindir}/ssh-keygen"
  
  RDEPENDS_${PN} += "${PN}-scp ${PN}-ssh ${PN}-sshd ${PN}-keygen"

  RDEPENDS_${PN}-sshd += "${PN}-keygen ${@bb.utils.contains('DISTRO_FEATURES', 
'pam', 'pam-plugin-keyinit pam-plugin-loginuid', '', d)}"
+RDEPENDS_${PN}-sftp += "${PN}-ssh"
  RDEPENDS_${PN}-ptest += "${PN}-sftp ${PN}-misc ${PN}-sftp-server make"
  
  RPROVIDES_${PN}-ssh = "ssh"






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Weird license_create_manifest failures in sumo

[Mike Looijmans]

I'm migrating to "sumo" from rocko, and when building for multiple machines on 
the build server, I get failures like the one below.


I'm suspecting this is a resurrection of the MACHINE/allarch problems that 
i've seen in the past, but this time I cannot work around them since they 
concern "base" packages.


I did not see this in the rocko branch with the same configuration.

I already tried cleaning out the "tmp" folder and restarting.




Build Configuration:
BB_VERSION   = "1.38.0"
BUILD_SYS= "x86_64-linux"
NATIVELSBSTRING  = "ubuntu-14.04"
TARGET_SYS   = "arm-oe-linux-gnueabi"
MACHINE  = "topic-miami-florida-gen-xc7z015"
DISTRO   = "tiny"
DISTRO_VERSION   = "nodistro.0"
TUNE_FEATURES= "arm armv7a vfp thumb neon callconvention-hard cortexa9"
TARGET_FPU   = "hard"
meta = "HEAD:dceca6d34071b4cbef9e28bbf19dc12f5d925525"
meta-oe
meta-multimedia
meta-python  = "HEAD:a19aa29f7fa336cd075b72c496fe1102e6e5422b"
meta-qt4 = "HEAD:8e791c40140460825956430ba86b6266fdec0a93"
meta-xilinx-bsp  = "HEAD:b2f74cc7fe5c4881589d5e440a17cb51fc66a7ab"
meta-topic   = "HEAD:6a3e86cb565c782dd4c3467ca820f08dde5f8472"
meta-dyplo   = "HEAD:0e8d4d9dedb7f2b12fd9a1822ecfa4635ff72227"
meta-topic-internal  = "HEAD:0d4f93fda7c2d2022cb6a535b9a96010be0ff0c7"

...

The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:license_create_manifest(d)
 0003:
File: '/.../oe-core/meta/classes/license.bbclass', lineno: 48, function: 
license_create_manifest

 0044:pkg_dic = {}
 0045:for pkg in sorted(image_list_installed_packages(d)):
 0046:pkg_info = os.path.join(d.getVar('PKGDATA_DIR'),
 0047:'runtime-reverse', pkg)
 *** 0048:pkg_name = os.path.basename(os.readlink(pkg_info))
 0049:
 0050:pkg_dic[pkg_name] = oe.packagedata.read_pkgdatafile(pkg_info)
 0051:if not "LICENSE" in pkg_dic[pkg_name].keys():
 0052:pkg_lic_name = "LICENSE_" + pkg_name
Exception: FileNotFoundError: [Errno 2] No such file or directory: 
'/.../build/tmp-glibc/pkgdata/topic-miami-florida-gen-xc7z030/runtime-reverse/base-passwd'






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] systemd: Add util-linux-umount to RDEPENDS

[Mike Looijmans]

Definitely, once the RDEPENDS is there, people will forget about it and it 
will still be there long after we've forgotten why it was put there...


On 18-05-18 15:20, Burton, Ross wrote:

Fixing busybox is a better solution. yes.

Ross

On 18 May 2018 at 13:24, Fabio Berton  wrote:

Yes, I tested this patch seems to work.

But bug report has:

"Yeah, this appears to be a limitation of busybox, and needs to be fixed in
busybox. We focus on util-linux proper, which has supported this option
since generations"

So, I add umount from util-linux because systemd focus on util-linux and
systemd recipe already has util-linux-mount.

If add patch to busybox is a better solution I can do this and send to list.

Fabio

On Thu, May 17, 2018 at 4:53 PM, Andre McCurdy  wrote:


On Thu, May 17, 2018 at 12:15 PM, Fabio Berton
 wrote:

Images with systemd fails on reboot with error:

[FAILED] Failed unmounting Temporary Directory (/tmp).

This happens because busybox umount command doesn't has -c
option. Add util-linux-umount that has this option to fix
this issue.

See details: https://github.com/systemd/systemd/issues/7786


That bug report mentions a fix to busybox. Since the fix is available
in upstream busybox, maybe better to just backport the patch to our
version of buysbox:


https://git.busybox.net/busybox/commit/?id=426134128112738c97a665170b21153ef0764b7d


Signed-off-by: Fabio Berton 
---
  meta/recipes-core/systemd/systemd_237.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_237.bb
b/meta/recipes-core/systemd/systemd_237.bb
index b7c2113255f..3b0f4580d49 100644
--- a/meta/recipes-core/systemd/systemd_237.bb
+++ b/meta/recipes-core/systemd/systemd_237.bb
@@ -478,7 +478,7 @@ FILES_${PN} = " ${base_bindir}/* \

  FILES_${PN}-dev += "${base_libdir}/security/*.la
${datadir}/dbus-1/interfaces/ ${sysconfdir}/rpm/macros.systemd"

-RDEPENDS_${PN} += "kmod dbus util-linux-mount udev (= ${EXTENDPKGV})
util-linux-agetty"
+RDEPENDS_${PN} += "kmod dbus util-linux-mount util-linux-umount udev (=
${EXTENDPKGV}) util-linux-agetty"
  RDEPENDS_${PN} += "${@bb.utils.contains('PACKAGECONFIG',
'serial-getty-generator', '', 'systemd-serialgetty', d)}"
  RDEPENDS_${PN} += "volatile-binds update-rc.d"

--
2.14.2

--



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



___

Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core




--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] busybox: mdev: make mdev auto load modules at boot

[Mike Looijmans]

On 05-03-18 09:22, Quentin Schulz wrote:

Thanks to the MODALIAS line at the beginning of mdev.conf, mdev supports
module auto probing on hotplug.

However, this does not work for cold plugged modules (i.e. modules for
devices that were probed before mdev is added as hotplug handler).
Running mdev -s to replay hotplug events does not work in that case.


I'd rather have this in a seperate bootscript, like this (which performs the 
same but applies a filter):

https://github.com/topic-embedded-products/meta-topic/tree/master/recipes-core/module-init-tools

This gives users a choice as to whether or not they want this to happen.

Another note: Since this runs at each and every boot, it'd be wise to optimize 
this for performance. That "sort -u" might be bad for performance, and 
modprobe doesn't mind if modules were already probed.





Let's manually modprobe all modules in the rootfs.

Taken from:
  - 
https://github.com/buildroot/buildroot/commit/07f46c2b6daec44a6176039c90be67e66c4c2e42
  - 
https://github.com/buildroot/buildroot/commit/b4fc5a180c81689a982d5c595844331684c14f51

We need xargs to support zero termination of args so let's enable this
configuration in the fragment for mdev.

Signed-off-by: Quentin Schulz <quentin.sch...@bootlin.com>
---
  meta/recipes-core/busybox/busybox/mdev.cfg | 2 ++
  meta/recipes-core/busybox/files/mdev   | 1 +
  2 files changed, 3 insertions(+)

diff --git a/meta/recipes-core/busybox/busybox/mdev.cfg 
b/meta/recipes-core/busybox/busybox/mdev.cfg
index 6aefe90e43..0d60fc9560 100644
--- a/meta/recipes-core/busybox/busybox/mdev.cfg
+++ b/meta/recipes-core/busybox/busybox/mdev.cfg
@@ -9,3 +9,5 @@ CONFIG_SETSID=y
  CONFIG_CTTYHACK=y
  
  CONFIG_FEATURE_SHADOWPASSWDS=y

+
+CONFIG_FEATURE_XARGS_SUPPORT_ZERO_TERM=y
diff --git a/meta/recipes-core/busybox/files/mdev 
b/meta/recipes-core/busybox/files/mdev
index 8c9c06e96c..165b275256 100755
--- a/meta/recipes-core/busybox/files/mdev
+++ b/meta/recipes-core/busybox/files/mdev
@@ -9,6 +9,7 @@ touch /dev/mdev.seq
  #sysctl -w kernel.hotplug=/sbin/mdev
  echo "/sbin/mdev" > /proc/sys/kernel/hotplug
  mdev -s
+find /sys/ -name modalias -print0 | xargs -0 sort -u -z | xargs -0 modprobe 
-abq
  
  #

  # We might have mounted something over /dev, see if /dev/initctl is there.





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] packagefeed-stability.bbclass problems

[Mike Looijmans]

As advised a few weeks ago, I tried out "packagefeed-stability" to 
reduct the load on feed servers.


However, I ran into several problems with that:
- Some recipes cause the class to crash.
- On a second (and third) run, it spends over 15 minutes of running 
"do_package_compare_ipk" tasks.


So for now my conclusion has to be that it's useless in its current 
form, it will just add more load on the build servers and it apparently 
is rather sensitive to things we did in the past for some recipes.


Below an example crash traceback:
(recipe: 
https://github.com/OpenPLi/openpli-oe-core/blob/develop/meta-openpli/recipes-openpli/enigma2-skins/enigma2-plugin-skins-magic.bb)



ERROR: enigma2-plugin-skins-magic-1.2+gitAUTOINC+8b5fb84750-r0 
do_package_compare_ipk: Error executing a python function in 
exec_python_func() autogenerated:


The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_package_compare_ipk(d)
 0003:
File: 
'/home/.../openembedded-core/meta/classes/packagefeed-stability.bbclass', 
lineno: 76, function: do_package_compare_ipk

 0072:# anonymous python code above
 0073:fakeroot python do_package_compare () {
 0074:currenttask = d.getVar('BB_CURRENTTASK', True)
 0075:pkgtype = currenttask.rsplit('_', 1)[1]
 *** 0076:package_compare_impl(pkgtype, d)
 0077:}
 0078:
 0079:def package_compare_impl(pkgtype, d):
 0080:import errno
File: 
'/home/.../openembedded-core/meta/classes/packagefeed-stability.bbclass', 
lineno: 163, function: package_compare_impl

 0159:if pkgbasename.startswith(rpkg):
 0160:pkgr = pkgrvalues[pkg]
 0161:destpathspec = 
destpath.replace(pkgr, '*')

 0162:if pvprefix:
 *** 0163:pkgv = pkgvvalues[pkg]
 0164:if pkgv.startswith(pvprefix):
 0165:pkgvsuffix = 
pkgv[len(pvprefix):]

 0166:if '+' in pkgvsuffix:
 0167:newpkgv = pvprefix + 
'*+' + pkgvsuffix.split('+', 1)[1]

Exception: KeyError: 'font-valis-enigma'

ERROR: enigma2-plugin-skins-magic-1.2+gitAUTOINC+8b5fb84750-r0 
do_package_compare_ipk: Function failed: do_package_compare_ipk
ERROR: Logfile of failure stored in: 
/home/.../build/tmp/work/all-oe-linux/enigma2-plugin-skins-magic/1.2+gitAUTOINC+8b5fb84750-r0/temp/log.do_package_compare_ipk.22333
ERROR: Task 
(/home/.../meta-openpli/recipes-openpli/enigma2-skins/enigma2-plugin-skins-magic.bb:do_package_compare_ipk) 
failed with exit code '1'



--
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Recipe versions and layer confusion

[Mike Looijmans]

On 06-10-17 00:10, Andre McCurdy wrote:

On Thu, Oct 5, 2017 at 2:44 PM, Leonardo Sandoval
<leonardo.sandoval.gonza...@linux.intel.com> wrote:

On Thu, 5 Oct 2017 10:19:18 -0500
Leonardo Sandoval <leonardo.sandoval.gonza...@linux.intel.com> wrote:


On Thu, 5 Oct 2017 16:49:28 +0200
Mike Looijmans <mike.looijm...@topic.nl> wrote:


I'm confused.

Layer "meta-xilinx" defines:

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb

This recipe is too old for my liking, so I made a newer one in "meta-topic"

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb


Much to my surprise, when I build, OE picks the 2017.1 version and not the
2017.3 version.

bitbake-layers show-layers reveils:
..
meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
meta-topic/home/mike/projects/zynq-platform/meta-topic  6
..

so that means that my meta-topic should win even if my PV were lower, right?


Yes. The comments in bitbake/lib/bb/providers.py -> findBestProvider()
explain the process pretty well:

   If there is a PREFERRED_VERSION, find the highest-priority bbfile
   providing that version.  If not, find the latest version provided by
   an bbfile in the highest-priority set.

The only caveat is that if PREFERRED_VERSION contains a wildcard (%)
and matches more than one available version then all bets are off and
results may be unpredictable. It's up to the user to ensure that
doesn't happen.

Note that looking at the meta-xilinx recipe it seems that PV is set
manually and doesn't follow the recipe name, so depending on how you
set PV in your new recipe, it may not be completely obvious which
recipe is actually being used?

   
https://github.com/Xilinx/meta-xilinx/blob/master/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb



Yeah, that turned out to be the problem. The recipe is versioned as 
"2017.1" but that is not the version it will actually build.


"bitbake-layers show-recipes arm-trusted-firmware" reveiled the true 
versions, as Paul suggested, and that explained the strange choices.


--
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Recipe versions and layer confusion

[Mike Looijmans]

On 05-10-17 16:59, Mark Hatle wrote:

On 10/5/17 9:49 AM, Mike Looijmans wrote:

I'm confused.

Layer "meta-xilinx" defines:

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb

This recipe is too old for my liking, so I made a newer one in "meta-topic"

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb


Much to my surprise, when I build, OE picks the 2017.1 version and not the
2017.3 version.


Typically the version is selected by whichever PV is 'higher'.  However there
are many ways to change this behavior.

The primary way is for a configuration file (often the machine configuration) to
defined a preferred version.  I.e.

   PREFERRED_VERSION_arm-trusted-firmware = "2017.1"

Most likely there is a line like that someone in meta-xilinx.


Nope, no such line.



Additional ways would be to have a recipe define itself as never the default
version.


bitbake-layers show-layers reveils:
..
meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
meta-topic/home/mike/projects/zynq-platform/meta-topic  6
..


The layer priority does not directly affect recipe selection.  It may if you
have two layers of the -same- version.

--Mark


so that means that my meta-topic should win even if my PV were lower, right?


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)







Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Recipe versions and layer confusion

[Mike Looijmans]

I'm confused.

Layer "meta-xilinx" defines:

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.1.bb

This recipe is too old for my liking, so I made a newer one in "meta-topic"

recipes-bsp/arm-trusted-firmware/arm-trusted-firmware_2017.3.bb


Much to my surprise, when I build, OE picks the 2017.1 version and not the 
2017.3 version.


bitbake-layers show-layers reveils:
..
meta-xilinx   /home/mike/projects/zynq-platform/meta-xilinx  5
meta-topic/home/mike/projects/zynq-platform/meta-topic  6
..

so that means that my meta-topic should win even if my PV were lower, right?


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)

[Mike Looijmans]

On 18-09-17 18:25, Trevor Woerner wrote:

Hi Mike,

On Mon, Sep 18, 2017 at 8:45 AM, Mike Looijmans <mike.looijm...@topic.nl> wrote:

I can probably bring some work (e.g. Zynq MPSoC board) and fun (settop box)
hardware along to demonstrate what I'm using OE for.


Any chance you could set something up that could be on display at the
Yocto booth during the conference?


Depends on what I'll be able tug along in my luggage on the airplane, but 
whatever I can bring is probably suited for public display. A few circuit 
boards will certainly fit, so if the stand could provide a HDMI monitor (or 
TV) to connect them to that'd be awesome.


M.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail


Visit us at the Space Tech Expo Europe (Stand E-71)
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base-files: profile: Get rid of "resize"

[Mike Looijmans]

On 19-09-17 01:07, Trevor Woerner wrote:

I use resize quasi-regularly. Ever end up in the situation where
you've run vim and now the command-line has no idea how large the
console is, so everything wraps or scrolls at the wrong times/places?
resize fixes that:

# . resize

Please don't remove it.



We're not removing the "resize" command itself. It's about removing something 
that started as a simple one-liner in /etc/profile to call "resize" (that did 
not fix the problem) and grew out to be a monster over time.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base-files: profile: Get rid of "resize"

[Mike Looijmans]

On 18-09-17 21:19, Burton, Ross wrote:
On 18 September 2017 at 20:01, Andre McCurdy <armccu...@gmail.com 
<mailto:armccu...@gmail.com>> wrote:


 > The question is does it do something useful *now*?

I don't have a board with a serial console to test at the moment.
Busybox hasn't changed in recent memory though, so as long as the
resize command does actually get run I presume it's still going to
work.


Re-read the code.  There's a call to ioctl with TIOCSWINSZ which I'm 
*guessing* is set window size.  Google is not useful for this!  It does all 
this on stderr.




Google on TIOCSWINSZ yields:
https://linux.die.net/man/4/tty_ioctl

TIOCSWINSZ
const struct winsize *argp
Set window size.

Of course, there is no explanation on what a "set window size" is supposed to 
accomplish on the terminal device.




So yes it *should* work, but not if you redirect stderr to /dev/null.


Yep.


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] base-files: profile: Get rid of "resize"

[Mike Looijmans]

On 18-09-17 20:43, Burton, Ross wrote:
On 18 September 2017 at 19:41, Andre McCurdy <armccu...@gmail.com 
<mailto:armccu...@gmail.com>> wrote:


On Mon, Sep 18, 2017 at 8:17 AM, Burton, Ross <ross.bur...@intel.com
<mailto:ross.bur...@intel.com>> wrote:
 > On 18 September 2017 at 16:07, Peter Kjellerstedt
 > <peter.kjellerst...@axis.com <mailto:peter.kjellerst...@axis.com>> wrote:
 >>
 >> > 


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



-Original Message-

 >> > From: openembedded-core-boun...@lists.openembedded.org
<mailto:openembedded-core-boun...@lists.openembedded.org>
 >> > [mailto:openembedded-core-boun...@lists.openembedded.org
<mailto:openembedded-core-boun...@lists.openembedded.org>] On Behalf Of
 >> > Mike Looijmans
 >> > Sent: den 18 september 2017 16:07
 >> > To: openembedded-core@lists.openembedded.org
<mailto:openembedded-core@lists.openembedded.org>
 >> > Cc: Mike Looijmans <mike.looijm...@topic.nl
<mailto:mike.looijm...@topic.nl>>; Peter Kjellerstedt
 >> > <peter.kjellerst...@axis.com <mailto:peter.kjellerst...@axis.com>>
 >> > Subject: [OE-core] [PATCH] base-files: profile: Get rid of "resize"
 >> >
 >> > The "resize" command actually outputs shell commands to be executed, 
for
 >> > example:
 >> >
 >> > $ resize
 >> > COLUMNS=102;
 >> > LINES=27;
 >> > export COLUMNS LINES;
 >> >
 >> > The output of "resize" is being discarded to /dev/null so the call has
     >> > no
 >> > effect whatsoever, and does not change the environment (it cannot 
change
 >> > the
 >> > environment of its parent). Remove the call and hence solve the 
messages
 >> > about shells missing "command" or "tty" or "resize".
 >> >
 >> > Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl
<mailto:mike.looijm...@topic.nl>>
 >> > ---
 >> >  meta/recipes-core/base-files/base-files/profile | 9 -
 >> >  1 file changed, 9 deletions(-)
 >> >
 >> > diff --git a/meta/recipes-core/base-files/base-files/profile
 >> > b/meta/recipes-core/base-files/base-files/profile
 >> > index a062028..cfd0d69 100644
 >> > --- a/meta/recipes-core/base-files/base-files/profile
 >> > +++ b/meta/recipes-core/base-files/base-files/profile
 >> > @@ -20,15 +20,6 @@ if [ -d /etc/profile.d ]; then
 >> >   unset i
 >> >  fi
 >> >
 >> > -if command -v resize >/dev/null && command -v tty >/dev/null; then
 >> > - # Make sure we are on a serial console (i.e. the device used
 >> > starts with
 >> > - # /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher
 >> > which
 >> > - # tries do use ssh
 >> > - case $(tty) in
 >> > - /dev/tty[A-z]*) resize >/dev/null;;
 >> > - esac
 >> > -fi
 >> > -
 >> >  export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM
 >> >
 >> >  umask 022
 >> > --
 >> > 1.9.1
 >>
 >> Hold on. Looking at busybox' source code for resize, it seems that
 >> it actually does something besides outputting the shell code to
 >> set the variables (which is actually enabled by a separate feature
 >> called ENABLE_FEATURE_RESIZE_PRINT). It also calls
 >> ioctl(STDERR_FILENO, TIOCSWINSZ, ) where w contains the
 >> calculated sizes.
 >
 > My knowledge of ANSI escapes is incredibly sketchy, but isn't that the 
code
 > to *get* the size of the screen?  Put the cursor at 999,999, then ask 
where
 > it is?

The behaviour may have got broken with the various /etc/profile
rewrites but it certainly did do something useful originally - it
greatly improves usability for shells run on serial consoles. Please
don't just remove it.


The question is does it do something useful *now*?


My experience is that it does not, and never has. I run serial consoles all 
the time, and if they're not sized to 80x25 weird stuff happens.


Start vi on a serial terminal and it only uses the top 80x25. If a command 
exceed the 80 char mark, the cursor goes all weird.
Running "eval `resize`" fixes that (until you resize the window). Running just 
"resize" does not have any effect on that at all.


Cannot we determine the presence of "tty" and "resize" commands at compile 
time? something like:


if has_command("tty") and has_command("resize"):
install -m 755 ${S}/resize.sh ${D}${sysconfdir}/profile.d/

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] init-ifupdown: RDEPENDS on procps

[Mike Looijmans]

Busybox can also provide sysctl so there's no hard dependency on procps.


On 18-09-17 14:43, liu.min...@gmail.com wrote:

From: Ming Liu <liu.min...@gmail.com>

sysctl is being called in /etc/init.d/networking, so it needs RDEPENDS
on procps.

Signed-off-by: Ming Liu <liu.min...@gmail.com>
---
  meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb 
b/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
index 733ae41..8774386 100644
--- a/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
+++ b/meta/recipes-core/init-ifupdown/init-ifupdown_1.0.bb
@@ -35,7 +35,7 @@ do_install_append_qemuall () {
  }
  
  PACKAGE_ARCH_qemuall = "${MACHINE_ARCH}"

-RDEPENDS_${PN} = "netbase"
+RDEPENDS_${PN} = "netbase procps"
  RCONFLICTS_${PN} = "netbase (< 1:5.0)"
  
  CONFFILES_${PN} = "${sysconfdir}/network/interfaces"






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] base-files: profile: Get rid of "resize"

[Mike Looijmans]

The "resize" command actually outputs shell commands to be executed, for
example:

$ resize
COLUMNS=102;
LINES=27;
export COLUMNS LINES;

The output of "resize" is being discarded to /dev/null so the call has no
effect whatsoever, and does not change the environment (it cannot change the
environment of its parent). Remove the call and hence solve the messages
about shells missing "command" or "tty" or "resize".

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta/recipes-core/base-files/base-files/profile | 9 -
 1 file changed, 9 deletions(-)

diff --git a/meta/recipes-core/base-files/base-files/profile 
b/meta/recipes-core/base-files/base-files/profile
index a062028..cfd0d69 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -20,15 +20,6 @@ if [ -d /etc/profile.d ]; then
unset i
 fi
 
-if command -v resize >/dev/null && command -v tty >/dev/null; then
-   # Make sure we are on a serial console (i.e. the device used starts with
-   # /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which
-   # tries do use ssh
-   case $(tty) in
-   /dev/tty[A-z]*) resize >/dev/null;;
-   esac
-fi
-
 export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM
 
 umask 022
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] base-files: profile: Do not assume that the 'command' command exists

[Mike Looijmans]

On 18-09-17 15:24, Mike Looijmans wrote:

On 18-09-17 15:08, Burton, Ross wrote:
On 18 September 2017 at 12:31, Mike Looijmans <mike.looijm...@topic.nl 
<mailto:mike.looijm...@topic.nl>> wrote:


This is basically the same change as I first sent a patch for in
April, and
last pinged this Friday... The only real difference is that this one
misses
passing error output from resize to /dev/null (which it should do to
handle
the case where tty exists, but resize does not).


Yeah, indeed.


Apologies for missing that patch!

Other problem is that "resize" outputs shell script on stdout to be
executed, so the proper "total" invokation would be:

   /dev/tty[A-z]*) eval `resize 2>/dev/null` ;;

The "eval" part is missing in your version...


Who is going to submit the One True patch with all the fixes in?  I promise 
to merge it.


I'll send the one ring, eh, patch, in a few minutes. I'll merge the two into a 
single as well.


On second thought, just use Peter's patch "as is".

I've been experimenting with the "eval" part and it doesn't behave well. Tends 
to confuse minicom, create garbage, and in particular when run from "profile", 
it seems to result in counterproductive COLUMNS=0 and LINES=0.


I'm actually wondering why the call to "resize" is being done at all. Just 
calling "resize" has no effect, since it outputs the results on stdout as 
shell script, and that is being discarded. Looking at the commit that 
introduced it:


cc6360f4c4d9 (base-files: set dynamic COLUMNS via resize command)

that already has no effect whatsoever. See the man page for resize:
https://linux.die.net/man/1/resize

I also would consider running some program's output as shell script a bit 
spooky, it looks like a security hole waiting to be exploited.




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] base-files: profile: Do not assume that the 'command' command exists

[Mike Looijmans]

On 18-09-17 15:08, Burton, Ross wrote:
On 18 September 2017 at 12:31, Mike Looijmans <mike.looijm...@topic.nl 
<mailto:mike.looijm...@topic.nl>> wrote:


This is basically the same change as I first sent a patch for in
April, and
last pinged this Friday... The only real difference is that this one
misses
passing error output from resize to /dev/null (which it should do to
handle
the case where tty exists, but resize does not).


Yeah, indeed.


Apologies for missing that patch!

Other problem is that "resize" outputs shell script on stdout to be
executed, so the proper "total" invokation would be:

   /dev/tty[A-z]*) eval `resize 2>/dev/null` ;;

The "eval" part is missing in your version...


Who is going to submit the One True patch with all the fixes in?  I promise to 
merge it.


I'll send the one ring, eh, patch, in a few minutes. I'll merge the two into a 
single as well.




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] OpenEmbedded Developer Meeting Oct 22, 2017 in Prague (before ELCE)

[Mike Looijmans]

> On Thu, Aug 24, 2017 at 9:37 PM, Philip Balister <phi...@balister.org> wrote:

Once again we will have a developer meeting in Prague the Sunday before
ELCE.

Please go to https://www.openembedded.org/wiki/OEDEM_2017 and add
yourself if you are attending and ideas for topics.

Although it is called a developer meeting, we invite members of the
larger community to attend. The core developers are always interested in
hearing how OpenEmbedded is used, and what we can do to make it better
for building the embedded devices of the future.


I'm planning to attend, but so far haven't made it though the wiki 
registration process yet...


I can probably bring some work (e.g. Zynq MPSoC board) and fun (settop box) 
hardware along to demonstrate what I'm using OE for.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH 1/2] base-files: profile: Do not assume that the 'command' command exists

[Mike Looijmans]

On 18-09-17 10:49, Peter Kjellerstedt wrote:




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



-Original Message-

From: openembedded-core-boun...@lists.openembedded.org
[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
Mike Looijmans
Sent: den 18 september 2017 10:39
To: openembedded-core@lists.openembedded.org
Cc: Mike Looijmans <mike.looijm...@topic.nl>
Subject: [OE-core] [PATCH 1/2] base-files: profile: Do not assume that
the 'command' command exists

The "command" shell command appears to be a bashism, the standard
busybox shell doesn't implement it.

This avoids the following error when logging in to a host that does
not have the 'command' command:

 -sh: command: not found

It also simplifies the code and reduces the number of forks.

Fixes: e77cdb761169e404556487ac650dc562000da406
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
  meta/recipes-core/base-files/base-files/profile | 14 ++
  1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-core/base-files/base-files/profile 
b/meta/recipes-core/base-files/base-files/profile
index ceaf15f..b5b533c 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -22,14 +22,12 @@ if [ -d /etc/profile.d ]; then
unset i
  fi

-if command -v resize >/dev/null && command -v tty >/dev/null; then
-   # Make sure we are on a serial console (i.e. the device used starts with
-   # /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which
-   # tries do use ssh
-   case $(tty) in
-   /dev/tty[A-z]*) resize >/dev/null;;
-   esac
-fi
+# Make sure we are on a serial console (i.e. the device used starts with
+# /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which
+# tries do use ssh
+case $(tty 2>/dev/null) in
+   /dev/tty[A-z]*) resize >/dev/null;;
+esac

  export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM

--
1.9.1


This is basically the same change as I first sent a patch for in April, and
last pinged this Friday... The only real difference is that this one misses
passing error output from resize to /dev/null (which it should do to handle
the case where tty exists, but resize does not).


Yeah, indeed.

Other problem is that "resize" outputs shell script on stdout to be executed, 
so the proper "total" invokation would be:


  /dev/tty[A-z]*) eval `resize 2>/dev/null` ;;

The "eval" part is missing in your version...
--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 1/2] base-files: profile: Do not assume that the 'command' command exists

[Mike Looijmans]

The "command" shell command appears to be a bashism, the standard
busybox shell doesn't implement it.

This avoids the following error when logging in to a host that does
not have the 'command' command:

-sh: command: not found

It also simplifies the code and reduces the number of forks.

Fixes: e77cdb761169e404556487ac650dc562000da406
Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta/recipes-core/base-files/base-files/profile | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/meta/recipes-core/base-files/base-files/profile 
b/meta/recipes-core/base-files/base-files/profile
index ceaf15f..b5b533c 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -22,14 +22,12 @@ if [ -d /etc/profile.d ]; then
unset i
 fi
 
-if command -v resize >/dev/null && command -v tty >/dev/null; then
-   # Make sure we are on a serial console (i.e. the device used starts with
-   # /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which
-   # tries do use ssh
-   case $(tty) in
-   /dev/tty[A-z]*) resize >/dev/null;;
-   esac
-fi
+# Make sure we are on a serial console (i.e. the device used starts with
+# /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which
+# tries do use ssh
+case $(tty 2>/dev/null) in
+   /dev/tty[A-z]*) resize >/dev/null;;
+esac
 
 export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH 2/2] base-files: profile: Make the "resize" command have the intended effect

[Mike Looijmans]

The "resize" command outputs shell script to be evaluated. The proper way
to use it is to do:
  eval `resize`
This sets the related environment variables COLUMNS and ROWS so that a vi
invokation uses the proper dimensions. Without the "eval" part, running
vi still gives a garbled screen when the dimensions aren't 80x25.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta/recipes-core/base-files/base-files/profile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/base-files/base-files/profile 
b/meta/recipes-core/base-files/base-files/profile
index b5b533c..36bd35f 100644
--- a/meta/recipes-core/base-files/base-files/profile
+++ b/meta/recipes-core/base-files/base-files/profile
@@ -26,7 +26,7 @@ fi
 # /dev/tty[A-z]), otherwise we confuse e.g. the eclipse launcher which
 # tries do use ssh
 case $(tty 2>/dev/null) in
-   /dev/tty[A-z]*) resize >/dev/null;;
+   /dev/tty[A-z]*) eval `resize` ;;
 esac
 
 export PATH PS1 OPIEDIR QPEDIR QTDIR EDITOR TERM
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] psplash: Initialize psplash only if a framebuffer exists

[Mike Looijmans]

Isn't this a weird situation?

If you installed psplash but don't have a framebuffer, then something must be 
broken. I'd rather see that error than this being silently ignored and then 
wondering where the splash went.


There's the corner case (most of my boards and for example settop boxes behave 
like this) that the framebuffer initializes some time later in the boot 
process (e.g. after loading FPGA logic, or loading some closed-source binary 
video driver blob). For these systems, the psplash should be initialized by 
the hotplug manager (mdev, udev, systemd) as soon as the device appears.



On 05-09-17 04:10, Mark Hatle wrote:

psplash-init exits if there is no framebuffer device detected.
This is done to avoid the following error message from
occurring when booting up:

"Error opening /dev/fb0: No such file or directory"

Signed-off-by: Aws Ismail <aws.ism...@windriver.com>
Signed-off-by: Mark Hatle <mark.ha...@windriver.com>
---
  meta/recipes-core/psplash/files/psplash-init | 6 ++
  1 file changed, 6 insertions(+)

diff --git a/meta/recipes-core/psplash/files/psplash-init 
b/meta/recipes-core/psplash/files/psplash-init
index 66c85e9..0bce1de 100755
--- a/meta/recipes-core/psplash/files/psplash-init
+++ b/meta/recipes-core/psplash/files/psplash-init
@@ -7,6 +7,12 @@
  # Default-Stop:
  ### END INIT INFO
  
+if [ ! -e /dev/fb0 ]; then

+echo "Framebuffer /dev/fb0 not detected"
+echo "Boot splashscreen disabled"
+exit 0;
+fi
+
  read CMDLINE < /proc/cmdline
  for x in $CMDLINE; do
  case $x in





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Running wic on target?

[Mike Looijmans]

I noticed that the "wic" recipes appear to focus on the host only.

Would it be possible to run "wic" on target?

For example, it would be really convenient to be able to program the eMMC 
using wic and auto-expanding the root or data partition to cover the whole device.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] Request for pyro: rootfs-postcommands.bbclass: Prevent linking testdata to itself

[Mike Looijmans]

I noticed this patch made it to master. Could it be applied to "pyro" branch 
please? It's really causing headaches there and there's no "bbclassappend" to 
workaround the issue.




commit b516394f9e7858062aa7b042aa4a1bdef9d3a941
Author: Mike Looijmans <mike.looijm...@topic.nl>
Date:   Thu Aug 17 12:49:49 2017 +0200

rootfs-postcommands.bbclass: Prevent linking testdata to itself

testdata and testdata_link may point to the same file, in particular
when IMAGE_LINK_NAME and IMAGE_NAME are equal.

Check if this is the case before creating a symlink that points to
itself and makes the next build fail.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] qemuboot.bbclass: Prevent creating a link loop

[Mike Looijmans]

When IMAGE_NAME and IMAGE_LINK_NAME are equal, do_write_qemuboot_conf will
create a symlink that links to itself.

Check if this is the case before creating the link.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta/classes/qemuboot.bbclass | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes/qemuboot.bbclass b/meta/classes/qemuboot.bbclass
index 86b3060..0e21fc9 100644
--- a/meta/classes/qemuboot.bbclass
+++ b/meta/classes/qemuboot.bbclass
@@ -114,7 +114,8 @@ python do_write_qemuboot_conf() {
 with open(qemuboot, 'w') as f:
 cf.write(f)
 
-if os.path.lexists(qemuboot_link):
-   os.remove(qemuboot_link)
-os.symlink(os.path.basename(qemuboot), qemuboot_link)
+if qemuboot_link != qemuboot:
+if os.path.lexists(qemuboot_link):
+   os.remove(qemuboot_link)
+os.symlink(os.path.basename(qemuboot), qemuboot_link)
 }
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] rootfs-postcommands.bbclass: Prevent linking testdata to itself

[Mike Looijmans]

testdata and testdata_link may point to the same file, in particular
when IMAGE_LINK_NAME and IMAGE_NAME are equal.

Check if this is the case before creating a symlink that points to
itself and makes the next build fail.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta/classes/rootfs-postcommands.bbclass | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/meta/classes/rootfs-postcommands.bbclass 
b/meta/classes/rootfs-postcommands.bbclass
index 78f7c55..c92df7b 100644
--- a/meta/classes/rootfs-postcommands.bbclass
+++ b/meta/classes/rootfs-postcommands.bbclass
@@ -300,7 +300,8 @@ python write_image_test_data() {
 searchString = "%s/"%(d.getVar("TOPDIR")).replace("//","/")
 export2json(d, testdata,searchString=searchString,replaceString="")
 
-if os.path.lexists(testdata_link):
-   os.remove(testdata_link)
-os.symlink(os.path.basename(testdata), testdata_link)
+if testdata_link != testdata:
+if os.path.lexists(testdata_link):
+   os.remove(testdata_link)
+os.symlink(os.path.basename(testdata), testdata_link)
 }
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] What's the "proper" way to start WiFi networking?

[Mike Looijmans]

On 24-05-17 14:58, Mike Looijmans wrote:

For boards that offer WiFi, I'd want them to connect more or less automatically.

I was wondering if there were better ways than handcrafting shell scripts to 
do this on a headless embedded board?




If I put wpa-conf into /etc/network/interfaces it works, but blocks booting 
for a long time if the wifi isn't there.



I've been using ifplugd combined with wired ethernet, and this also works fine 
with wireless. Once wpa-supplicant connects to an access point, the link 
reports up and DCHP can start.



Starting wpa_supplicant from the commandline runs fine:

/usr/sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -c 
/etc/wpa_topic.conf -D


However, putting this line into a startup script (/etc/rc5.d/...) hangs. It 
doesn't matter whether I start early or late, the wpa_supplicant just hangs 
and waits and doesn't fork into daemon mode like it should. Tried setting PATH 
and redirecting input, invoking through start-stop-daemon, but that didn't help.


Found this issue, apparently the interface is down and wpa_supplicant waits 
for it.


Adding "ifconfig wlan0 up" prior to wpa_supplicant prevents that hangup.



Appending an ampersand to the command makes the boot continue, but 
wpa_supplicant doesn't work, it won't connect to the access point.




This problem remains however. Starting interactively works fine, starting from 
any form of shell script at boot makes it start up fine but it doesn't 
connect. Starting up "wpa_cli" interactively to diagnose what's going on, but 
not actually typing any command, usually makes it connect all of a sudden.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] What's the "proper" way to start WiFi networking?

[Mike Looijmans]

On 24-05-17 15:12, Nicolas Dechesne wrote:

On Wed, May 24, 2017 at 2:58 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:


I was wondering if there were better ways than handcrafting shell scripts to
do this on a headless embedded board?



If I put wpa-conf into /etc/network/interfaces it works, but blocks booting
for a long time if the wifi isn't there.


I've been using ifplugd combined with wired ethernet, and this also works
fine with wireless. Once wpa-supplicant connects to an access point, the
link reports up and DCHP can start.


Starting wpa_supplicant from the commandline runs fine:

/usr/sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -c
/etc/wpa_topic.conf -D

However, putting this line into a startup script (/etc/rc5.d/...) hangs. It
doesn't matter whether I start early or late, the wpa_supplicant just hangs
and waits and doesn't fork into daemon mode like it should. Tried setting
PATH and redirecting input, invoking through start-stop-daemon, but that
didn't help.

Appending an ampersand to the command makes the boot continue, but
wpa_supplicant doesn't work, it won't connect to the access point.


my 2 cents..

after going back and forth for some time, I am now always using
network-manager.. it has very handy command line utilities (nmcli and
nmtui) and is well integrated with systemd. that happens to work well
for me.



Does it work without systemd? Because usually I use mdev for hotplug to save 
(drastically) on boot time and flash usage.



i want to believe that connman can do the same thing, but i have never
tried it much..


Same question there...



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] What's the "proper" way to start WiFi networking?

[Mike Looijmans]

On 24-05-17 15:12, Nicolas Dechesne wrote:

On Wed, May 24, 2017 at 2:58 PM, Mike Looijmans <mike.looijm...@topic.nl> wrote:


I was wondering if there were better ways than handcrafting shell scripts to
do this on a headless embedded board?



If I put wpa-conf into /etc/network/interfaces it works, but blocks booting
for a long time if the wifi isn't there.


I've been using ifplugd combined with wired ethernet, and this also works
fine with wireless. Once wpa-supplicant connects to an access point, the
link reports up and DCHP can start.


Starting wpa_supplicant from the commandline runs fine:

/usr/sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -c
/etc/wpa_topic.conf -D

However, putting this line into a startup script (/etc/rc5.d/...) hangs. It
doesn't matter whether I start early or late, the wpa_supplicant just hangs
and waits and doesn't fork into daemon mode like it should. Tried setting
PATH and redirecting input, invoking through start-stop-daemon, but that
didn't help.

Appending an ampersand to the command makes the boot continue, but
wpa_supplicant doesn't work, it won't connect to the access point.


my 2 cents..

after going back and forth for some time, I am now always using
network-manager.. it has very handy command line utilities (nmcli and
nmtui) and is well integrated with systemd. that happens to work well
for me.


Apparently not for headless systems, networkmanager requires X11:

ERROR: Nothing PROVIDES 'consolekit' (but 
.../meta-oe/meta-oe/recipes-connectivity/networkmanager/networkmanager_1.0.12.bb 
DEPENDS on or otherwise requires it)
ERROR: consolekit was skipped: missing required distro feature 'x11' (not in 
DISTRO_FEATURES)




i want to believe that connman can do the same thing, but i have never
tried it much..


I'll try that next...



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] What's the "proper" way to start WiFi networking?

[Mike Looijmans]

For boards that offer WiFi, I'd want them to connect more or less 
automatically.

I was wondering if there were better ways than handcrafting shell scripts to 
do this on a headless embedded board?




If I put wpa-conf into /etc/network/interfaces it works, but blocks booting 
for a long time if the wifi isn't there.



I've been using ifplugd combined with wired ethernet, and this also works fine 
with wireless. Once wpa-supplicant connects to an access point, the link 
reports up and DCHP can start.



Starting wpa_supplicant from the commandline runs fine:

/usr/sbin/wpa_supplicant -B -P /var/run/wpa_supplicant.wlan0.pid -i wlan0 -c 
/etc/wpa_topic.conf -D


However, putting this line into a startup script (/etc/rc5.d/...) hangs. It 
doesn't matter whether I start early or late, the wpa_supplicant just hangs 
and waits and doesn't fork into daemon mode like it should. Tried setting PATH 
and redirecting input, invoking through start-stop-daemon, but that didn't help.


Appending an ampersand to the command makes the boot continue, but 
wpa_supplicant doesn't work, it won't connect to the access point.





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [RFC][PATCH 0/6] development vs. production builds

[Mike Looijmans]

This seems to assume that every project is similar and that develop vs 
production is something well defined. Well, it's not.


I for one would welcome the demise of debug-tweaks. It's an option that 
enforces one of two policies that may both be wrong.


For example, if the target is a settop box where users tend to port-forward 
the SSH port to the internet, and which is open so that they're expected to 
log in and make changes, the policy we want is that there is initially no root 
password, and that SSH access requires a valid password. This makes the system 
secure against outside attacks. Setting debug-tweaks will allow blank SSH 
passwords, while not setting it would invalidate the root login. Neither is 
acceptable for this project, so one has to resort to overriding the image 
class methods zap_root_password and ssh_allow_empty_password to do nothing.


Instead of some obscure switch with implications hidden somewhere in various 
recipes, classes, distros and local configs, can't we just define options that 
actually do what they say, like for example a boolean option 
"ssh_allow_empty_password"?


While the "development/production" switch may be great for some projects, 
it'll make things only more complicated for others while gaining nothing above 
what we have now.




On 15-05-17 15:26, Patrick Ohly wrote:

At OEDAM [1] I took the AR to flesh out some of my ideas for
introducing global and per-image settings for switching between
development and production builds. The goal is partly to establish
common configure options that then can be used by different layers,
partly to have some actual useful functionality attached to them
already in OE-core.

"development" builds are what a developer does when trying out a
distro or working on his own personal device. "production" is what
device manufacturer put onto the actual end-user hardware.

At OEDAM we already concluded that per-image settings are more
useful. However, sometimes a component also has compile-time choices
that cannot be changed later on in an image, and indeed I found one
example for that (kmod) in OE-core.

Therefore I have included "debug-build" DISTRO_FEATURES support. It's a
bit similar to manpages.bbclass, but in contrast to that (currently)
is meant to be inherited globally - that's partly due to
misunderstanding how manpages.bbclass was meant to be used. This can
be changed, for now I just want to demonstrate that such a distro
feature is not entirely useless, and what effect it could have already
in OE-core.

In refkit, we also switch globally between development and production
builds via .inc files. However, I am in the process of replacing that
with the more flexible per-image IMAGE_MODE check. So from my
perspective, the IMAGE_MODE is more important and useful than the
"debug-build" DISTRO_FEATURE.

From a design perspective, the approach taken here is to let a
developer or image define what mode it wants, and default features can
be configured accordingly. That alternative would be to continue defining
features as before and use the mode to configure QA warnings or errors.

But I find that less flexible, and I suspect it would be harder to
keep track of what is meant to be usable in which mode. Developers
also would have a harder time overriding the defaults.

[1] https://www.openembedded.org/wiki/OEDAM_2017

Patrick Ohly (6):
  build-mode.bbclass: distro-wide debug-build mode
  basefiles: warn about non-production DISTRO_FEATURES in motd
  defaultsetup.conf: enable special "debug-build" DISTRO_FEATURES support
  image-mode.bbclass: per-image production/development/debug mode
  image.bbclass: include IMAGE_MODE support
  local.conf.sample: make debug-tweaks depend on IMAGE_MODE

 meta/classes/build-mode.bbclass   | 16 -
 meta/classes/image-mode.bbclass   | 62 -
 meta/classes/image.bbclass|  3 +-
 meta/conf/distro/defaultsetup.conf|  2 +-
 meta/conf/local.conf.sample   |  5 +-
 meta/recipes-core/base-files/base-files_3.0.14.bb | 11 +++-
 6 files changed, 96 insertions(+), 3 deletions(-)
 create mode 100644 meta/classes/build-mode.bbclass
 create mode 100644 meta/classes/image-mode.bbclass

base-commit: 9f9ebf2e1ba6eda48fb5e3f20d4ca5bbabe3dad4





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail



Join our presentation at Electronics & Applications 2017:
FPGA for real-time data processing, subject “Hardware platform for industrial 
ultrasound steel plate Inspection” Topic Embedded Systems - Herman Kuster, 1st 
June 10 AM

Visit http://eabeurs.nl/author/612884/ for more information

--
__

Re: [OE-core] GUI based images

[Mike Looijmans]

On 09-05-17 10:44, Alex J Lennon wrote:



On 09/05/17 09:05, Alexander Kanavin wrote:

On 05/09/2017 01:15 AM, Paul Eggleton wrote:

LXDE in particular is Gtk2 based, it's no longer being developed, and
has been superseded by LXQt. So it's a non-starter (and so is LXQt,
which should be clear from its name :).


FWIW I think this is a little short-sighted. Why are we ruling out Qt exactly?


We would first have to agree that Qt5 belongs in oe-core with appropriate
level of maintenance and QA, and that it's okay to add half an hour or more
to the building time of a standard GUI image.

From the screenshots of LxQT, it looks like yet another Win95 clone meant
strictly for desktop use that would certainly scale poorly to small
resolution screens. Who would be the target audience for it in the embedded
space? For the purposes of 'engineering UI', Sato is fine, and we don't need
something else.

Alex


fwiw. I would love to be able to develop devices like those pictured below,
which I believe are based on Qt for Device Creation.

https://d33sqmjvzgs8hq.cloudfront.net/wp-content/uploads/2014/08/devices.png


Things like that can be cooked up in OE using just meta-qt4 (or 5, but haven't 
tried yet) and a main application recipe (just a QT project that you develop 
on your desktop) that inherits qt4e.


Qt doesn't need X11, saving big on build and boot time.

A Zynq demo running QT on a plain framebuffer boots in about 7 seconds (from 
NOR flash) into the fully functional GUI, on a 10" touch panel, and all of it 
fits in about 20MB flash storage.




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] tainting other recipe's specific task

[Mike Looijmans]

On 04-04-17 15:54, André Draszik wrote:

Hi,

Is it possible to invalidate one recipe's hash for a specific task from
another recipe?


I hope not...



More specifically, I have an initramfs image recipe and a main image recipe
where do_rootfs of the main image [depends] on do_deploy of initramfs.

If do_rootfs of the main image needs to be re-run, I need to make sure that
do_rootfs of the initramfs image is re-run (and of course do_deploy) before.
Basically I want to add a timestamp to both images, and the timestamp should
be the same.

Using my current dependencies, do_rootfs of the main image is re-run if the
initramfs is re-deployed:

--- snip main_image.bb: ---
do_rootfs[depends] += "initramfs:do_deploy"
--- snap ---

but I need this both ways. Just adding the equivalent to the initramfs
recipe results in bitbake complaining about a recursive dependency loop.


Can this be achieved? Even some pointers would be helpful...


Or some other approach where I can add the same timestamp to both images if
either of the images needed to be rebuilt due to some change?


What I did was have two image recipes, let's say "big-image" and 
"small-image". The big-image included a package called "big-project". To the 
"big-project.bb" recipe I added:


DEPENDS += "small-image"
do_install[depends] += "small-image:do_image_complete"

And in the do_install I copy the stuff from small-image into whereever I 
wanted it to be insided the small image.


Maybe this covers your use case?


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] native.bbclass: clear MACHINE_FEATURES

[Mike Looijmans]

On 22-03-17 23:47, Andre McCurdy wrote:

Try to avoid native recipes accidentally being dependent on
MACHINE_FEATURES. This simple change doesn't prevent MACHINE_FEATURES
set via MACHINE_FEATURES_BACKFILL sneaking through, but it's better
than nothing.


Maybe this would work:

MACHINE_FEATURES_BACKFILL_CONSIDERED = "${MACHINE_FEATURES_BACKFILL}"



Signed-off-by: Andre McCurdy <armccu...@gmail.com>
---
 meta/classes/native.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 6becf82..1919fbc 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -112,6 +112,7 @@ PKG_CONFIG_SYSTEM_INCLUDE_PATH[unexport] = "1"
 LIBCOVERRIDE = ""
 CLASSOVERRIDE = "class-native"
 MACHINEOVERRIDES = ""
+MACHINE_FEATURES = ""

 PATH_prepend = "${COREBASE}/scripts/native-intercept:"






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] initscripts/sysfs.sh: mount configfs if present

[Mike Looijmans]

configfs is another kernel virtual file system that should be mounted
if configured, so if it's configured into the kernel, mount it. It is
used to configure e.g. USB gadget mode and devicetree overlays.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh 
b/meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh
index 0a52c90..f5b5b99 100644
--- a/meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh
+++ b/meta/recipes-core/initscripts/initscripts-1.0/sysfs.sh
@@ -22,6 +22,10 @@ if [ -e /sys/kernel/debug ] && grep -q debugfs 
/proc/filesystems; then
   mount -t debugfs debugfs /sys/kernel/debug
 fi
 
+if [ -e /sys/kernel/config ] && grep -q configfs /proc/filesystems; then
+  mount -t configfs configfs /sys/kernel/config
+fi
+
 if ! [ -e /dev/zero ] && [ -e /dev ] && grep -q devtmpfs /proc/filesystems; 
then
   mount -n -t devtmpfs devtmpfs /dev
 fi
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [bitbake][PATCH] lib/bb/build.py: Raise proper KeyError if function does not exist

[Mike Looijmans]

If one adds the following line to an image recipe without defining
the function:
ROOTFS_POSTPROCESS_COMMAND += "rootfs_funky_stuff;"
bitbake will terminate with a cryptic error message:
AttributeError: 'NoneType' object has no attribute 'get'

To inform the user of what bitbake wasn't able to find, raise a KeyError
exception denoting the function name before that happens. This changes the
message to the much more useful:
KeyError: 'rootfs_funky_stuff'

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 lib/bb/build.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/lib/bb/build.py b/lib/bb/build.py
index c4c8aeb..5bc18c1 100644
--- a/lib/bb/build.py
+++ b/lib/bb/build.py
@@ -194,6 +194,8 @@ def exec_func(func, d, dirs = None, pythonexception=False):
 oldcwd = None
 
 flags = d.getVarFlags(func)
+if flags is None:
+raise KeyError(func)
 cleandirs = flags.get('cleandirs')
 if cleandirs:
 for cdir in d.expand(cleandirs).split():
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] (morty) Python exception during rootfs

[Mike Looijmans]

Found it. A rootfs post-process function was misspelled, and that caused it.

I'll make a patch to improve the error message here, to make it just say that 
it cannot find "func".



On 07-02-17 15:21, Mike Looijmans wrote:

I get this stacktrace from bitbake. No idea what's wrong. Apparently,
d.getVarFlags(func) returns None and the code cannot handle that. Is this a
bug in bitbake, or should 'flags' never evaluate to None?



The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_rootfs(d)
 0003:
File: '/home/mike/projects/zynq-platform/oe-core/meta/classes/image.bbclass',
lineno: 249, function: do_rootfs
 0245:
 0246:progress_reporter.next_stage()
 0247:
 0248:# generate rootfs
 *** 0249:create_rootfs(d, progress_reporter=progress_reporter)
 0250:
 0251:progress_reporter.finish()
 0252:}
 0253:do_rootfs[dirs] = "${TOPDIR}"
File: '/home/mike/projects/zynq-platform/oe-core/meta/lib/oe/rootfs.py',
lineno: 1006, function: create_rootfs
 1002:img_type = d.getVar('IMAGE_PKGTYPE', True)
 1003:if img_type == "rpm":
 1004:RpmRootfs(d, manifest_dir, progress_reporter).create()
 1005:elif img_type == "ipk":
 *** 1006:OpkgRootfs(d, manifest_dir, progress_reporter).create()
 1007:elif img_type == "deb":
 1008:DpkgRootfs(d, manifest_dir, progress_reporter).create()
 1009:
 1010:os.environ.clear()
File: '/home/mike/projects/zynq-platform/oe-core/meta/lib/oe/rootfs.py',
lineno: 210, function: create
 0206:execute_pre_post_process(self.d, rootfs_post_install_cmds)
 0207:
 0208:self._run_intercepts()
 0209:
 *** 0210:execute_pre_post_process(self.d, post_process_cmds)
 0211:
 0212:if self.progress_reporter:
 0213:self.progress_reporter.next_stage()
 0214:
File: '/home/mike/projects/zynq-platform/oe-core/meta/lib/oe/utils.py',
lineno: 176, function: execute_pre_post_process
 0172:for cmd in cmds.strip().split(';'):
 0173:cmd = cmd.strip()
 0174:if cmd != '':
 0175:bb.note("Executing %s ..." % cmd)
 *** 0176:bb.build.exec_func(cmd, d)
 0177:
 0178:def multiprocess_exec(commands, function):
 0179:import signal
 0180:import multiprocessing
File: '/home/mike/projects/zynq-platform/bitbake/lib/bb/build.py', lineno:
197, function: exec_func
 0193:except:
 0194:oldcwd = None
 0195:
 0196:flags = d.getVarFlags(func)
 *** 0197:cleandirs = flags.get('cleandirs')
 0198:if cleandirs:
 0199:for cdir in d.expand(cleandirs).split():
 0200:bb.utils.remove(cdir, True)
 0201:bb.utils.mkdirhier(cdir)
Exception: AttributeError: 'NoneType' object has no attribute 'get'

ERROR: pr-demo-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in:
/home/mike/projects/zynq-platform/build/tmp-glibc/work/topic_miami_florida_gen-oe-linux-gnueabi/pr-demo-image/1.0-r0/temp/log.do_rootfs.28716

ERROR: Task
(/home/mike/projects/zynq-platform/meta-topic-internal/recipes-topic/embedded-world/pr-demo-image.bb:do_rootfs)
failed with exit code '1'





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail









Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] (morty) Python exception during rootfs

[Mike Looijmans]

I get this stacktrace from bitbake. No idea what's wrong. Apparently, 
d.getVarFlags(func) returns None and the code cannot handle that. Is this a 
bug in bitbake, or should 'flags' never evaluate to None?




The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:do_rootfs(d)
 0003:
File: '/home/mike/projects/zynq-platform/oe-core/meta/classes/image.bbclass', 
lineno: 249, function: do_rootfs

 0245:
 0246:progress_reporter.next_stage()
 0247:
 0248:# generate rootfs
 *** 0249:create_rootfs(d, progress_reporter=progress_reporter)
 0250:
 0251:progress_reporter.finish()
 0252:}
 0253:do_rootfs[dirs] = "${TOPDIR}"
File: '/home/mike/projects/zynq-platform/oe-core/meta/lib/oe/rootfs.py', 
lineno: 1006, function: create_rootfs

 1002:img_type = d.getVar('IMAGE_PKGTYPE', True)
 1003:if img_type == "rpm":
 1004:RpmRootfs(d, manifest_dir, progress_reporter).create()
 1005:elif img_type == "ipk":
 *** 1006:OpkgRootfs(d, manifest_dir, progress_reporter).create()
 1007:elif img_type == "deb":
 1008:DpkgRootfs(d, manifest_dir, progress_reporter).create()
 1009:
 1010:os.environ.clear()
File: '/home/mike/projects/zynq-platform/oe-core/meta/lib/oe/rootfs.py', 
lineno: 210, function: create

 0206:execute_pre_post_process(self.d, rootfs_post_install_cmds)
 0207:
 0208:self._run_intercepts()
 0209:
 *** 0210:execute_pre_post_process(self.d, post_process_cmds)
 0211:
 0212:if self.progress_reporter:
 0213:self.progress_reporter.next_stage()
 0214:
File: '/home/mike/projects/zynq-platform/oe-core/meta/lib/oe/utils.py', 
lineno: 176, function: execute_pre_post_process

 0172:for cmd in cmds.strip().split(';'):
 0173:cmd = cmd.strip()
 0174:if cmd != '':
 0175:bb.note("Executing %s ..." % cmd)
 *** 0176:bb.build.exec_func(cmd, d)
 0177:
 0178:def multiprocess_exec(commands, function):
 0179:import signal
 0180:import multiprocessing
File: '/home/mike/projects/zynq-platform/bitbake/lib/bb/build.py', lineno: 
197, function: exec_func

 0193:except:
 0194:oldcwd = None
 0195:
 0196:flags = d.getVarFlags(func)
 *** 0197:cleandirs = flags.get('cleandirs')
 0198:if cleandirs:
 0199:for cdir in d.expand(cleandirs).split():
 0200:bb.utils.remove(cdir, True)
 0201:bb.utils.mkdirhier(cdir)
Exception: AttributeError: 'NoneType' object has no attribute 'get'

ERROR: pr-demo-image-1.0-r0 do_rootfs: Function failed: do_rootfs
ERROR: Logfile of failure stored in: 
/home/mike/projects/zynq-platform/build/tmp-glibc/work/topic_miami_florida_gen-oe-linux-gnueabi/pr-demo-image/1.0-r0/temp/log.do_rootfs.28716
ERROR: Task 
(/home/mike/projects/zynq-platform/meta-topic-internal/recipes-topic/embedded-world/pr-demo-image.bb:do_rootfs) 
failed with exit code '1'






Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [morty] Python cyclic dependencies

[Mike Looijmans]

In the do_rootfs log, I found these messages:

Breaking circular dependency on python-core for libz1.
Breaking circular dependency on python-core for python-lang.
Breaking circular dependency on python-core for libz1.
Breaking circular dependency on python-core for python-lang.
Breaking circular dependency on python-core for python-re.
Breaking circular dependency on python-core for python-re.

Looking at the Python recipes, the package information for Python seems 
wrong indeed, in python-2.7-manifest.inc:


RDEPENDS_${PN}-re="${PN}-core"
RDEPENDS_${PN}-lang="${PN}-core"
RDEPENDS_${PN}-core="${PN}-lang ${PN}-re"

And this is what creates that cycle. Either core depends on lang, or 
vice versa, but not both (or they should simply be one and the same package)


I'd be happy to provide a patch either way...


--
Mike Looijmans


Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][Morty] binutils-2.27.inc: Fix alignment frags for aarch64

[Mike Looijmans]

On 24-01-17 16:45, akuster808 wrote:



On 01/23/2017 10:48 PM, Mike Looijmans wrote:

On 18-01-17 17:09, akuster808 wrote:



On 01/18/2017 04:08 AM, Nathan Rossi wrote:

On 18 January 2017 at 19:37, Mike Looijmans <mike.looijm...@topic.nl> wrote:

Could someone at least please say "yes" or "no"?

I now have three projects waiting for this patch to be included in morty. If
it's not going to happen, I'll have to add a bbappend to these layers to fix
it.

On 16-01-17 18:49, Manjukumar Harthikote Matha wrote:

Ping, this has been applied to master

Armin, you mentioned on IRC ~1 week ago that you had merged it to your
staging branch? Any updates?
Also I had a look and could not find the change in
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akuster/morty-next?


Maybe I am looking in the wrong place though for your staging tree?

I forgot to press go. Its there now.


Much appreciated.

Who's next in line to press "go" now? I still have three projects waiting.

Richard or one of his minions.



Ping... please?



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] How to use WIC to generate raw flash images

[Mike Looijmans]

On 23-01-17 11:34, Ed Bartosh wrote:
...

- How do I set padding to be 0xFF instead of 0x00?

The same thing here. Currently wic images are sparse files created by
os.ftruncate, but it's not a big deal to fill them with 0xFF


Correct me if I'm wrong here...
- All flash media (NOR, NAND) prefers padding with 0xFF because that's equal 
to an erased sector.

- Other media (magnetic disks) don't care about what they're padded with.

So I'd say it makes sense to make 0xFF the default padding for exerything?



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][Morty] binutils-2.27.inc: Fix alignment frags for aarch64

[Mike Looijmans]

On 18-01-17 17:09, akuster808 wrote:



On 01/18/2017 04:08 AM, Nathan Rossi wrote:

On 18 January 2017 at 19:37, Mike Looijmans <mike.looijm...@topic.nl> wrote:

Could someone at least please say "yes" or "no"?

I now have three projects waiting for this patch to be included in morty. If
it's not going to happen, I'll have to add a bbappend to these layers to fix
it.

On 16-01-17 18:49, Manjukumar Harthikote Matha wrote:

Ping, this has been applied to master

Armin, you mentioned on IRC ~1 week ago that you had merged it to your
staging branch? Any updates?
Also I had a look and could not find the change in
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akuster/morty-next?

Maybe I am looking in the wrong place though for your staging tree?

I forgot to press go. Its there now.


Much appreciated.

Who's next in line to press "go" now? I still have three projects waiting.

Apparently the ARM64 isn't very popular, no one seems to care about its build 
failures...




Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] still fighting to get an OE recipe for "libfilesys-smbclient-perl"

[Mike Looijmans]

On 19-01-17 21:58, Robert P. J. Day wrote:


  following up on the whining i did a while back to finish off a few
perl recipes for OE, i have just a few left to resolve, and this is
one of them. i managed to get several dozen perl recipes to work
simply by throwing together recipes based on very little understanding
of perl cpan mechanics and just mindlessly cribbing boilerplate from
other recipes. if it worked, yee ha, move on.

  here's my current recipe for this module (again, slapped together
without really understanding what's going on under the hood):

/ start /

DESCRIPTION = "Filesys::SmbClient"

SECTION = "libs"
LICENSE = "Artisticv1 | GPLv1+"
PR = "r0"

MAINTAINER= "rday"
HOMEPAGE=   "https://metacpan.org/pod/Filesys::SmbClient;

LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/Artistic-1.0;md5=cda03bbdc3c1951996392b872397b798 
\
file://${COMMON_LICENSE_DIR}/GPL-1.0;md5=e9e36a9de734199567a4d769498f743d"

DEPENDS += "samba"

SRC_URI = 
"https://cpan.metacpan.org/authors/id/A/AL/ALIAN/Filesys-SmbClient-3.2.tar.gz;

SRC_URI[md5sum] = "8a4205fe748aac7f43fb2a0e8ef502b2"
SRC_URI[sha256sum] = 
"a9f2f3d4675de76f9dcae2be40bda93495cd5fafb1bb6326d71833cea451bc6e"

S = "${WORKDIR}/Filesys-SmbClient-${PV}"

inherit cpan

EXTRA_CPANFLAGS = "INC='-I${STAGING_INCDIR}/samba-4.0' 
LIBS='-L${STAGING_LIBDIR}'"

BBCLASSEXTEND = "native"

/ end /

and the error i get when i try to build makes it *clear* that the
configuration is failing to set up properly for cross-compiling for my
powerpc target:

$ bitbake libfilesys-smbclient-perl
... snip ...
| Where can I find libsmbclient.h ? []
*
| ** WHAT 
| ** I Can't find /libsmbclient.h : No such file or directory.
| *
... snip ...
| Where can I find libsmbclient.so ? []
*
| ** WHAT 
| ** I Can't find libsmbclient.so : No such file or directory.
... snip ...
| checking for C compiler default output... a.out
| checking whether the C compiler works... configure: error: cannot
run C compiled programs.
| If you meant to cross compile, use `--host'.
| See `config.log' for more details.


  and sure enough, the config.log for this build contains:

Target: powerpc-poky-linux
Configured with:
../../../../../../work-shared/gcc-6.3.0-r0/gcc-6.3.0/configure
--build=x86_64-linux --host=x86_64-linux --target=powerpc-poky-linux
...


Quick observation: I think host and target are wrong. The "host" is where the 
software will run. The line above builds something that runs on x86_64 and 
that compiles for a powerpc target (target only makes sense if you're 
compiling a compiler). You probably wanted --host=powerpc-poky-linux and no 
"--target" at all.





  beyond this, i'm not sure how to use an OE patch to adjust this
source the right way, given that dozens and dozens of other modules
cross-compiled just fine.

  thoughts? i am in now way a perl expert so i really have no idea
where to go from here.

rday





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH][Morty] binutils-2.27.inc: Fix alignment frags for aarch64

[Mike Looijmans]

Could someone at least please say "yes" or "no"?

I now have three projects waiting for this patch to be included in morty. If 
it's not going to happen, I'll have to add a bbappend to these layers to fix it.


On 16-01-17 18:49, Manjukumar Harthikote Matha wrote:

Ping, this has been applied to master

Thanks
Manju





Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





-Original Message-

From: Khem Raj [mailto:raj.k...@gmail.com]
Sent: Tuesday, November 22, 2016 2:03 PM
To: Manjukumar Harthikote Matha
Cc: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [PATCH][Morty] binutils-2.27.inc: Fix alignment frags for
aarch64

This is ok for master


On Nov 22, 2016 1:31 PM, "Manjukumar Matha" mailto:manjukumar.harthikote-ma...@xilinx.com> > wrote:


  There was bug with alignment frags for aarch64 in binutils. This is
  fixed in master of binutils. This patch backports the fix to binutils
  2.27 version.

  Signed-off-by: Manjukumar Matha mailto:manjukumar.harthikote-ma...@xilinx.com> >
  Signed-off-by: Nathan Rossi <nat...@nathanrossi.com
<mailto:nat...@nathanrossi.com> >
  ---
   meta/recipes-devtools/binutils/binutils-2.27.inc   |   1 +
   ...eration-of-alignment-frags-in-code-sectio.patch | 139
+
   2 files changed, 140 insertions(+)
   create mode 100644 meta/recipes-devtools/binutils/binutils/0017-Fix-the-
generation-of-alignment-frags-in-code-sectio.patch

  diff --git a/meta/recipes-devtools/binutils/binutils-2.27.inc 
b/meta/recipes-
devtools/binutils/binutils-2.27.inc
  index fc81721..90518bf 100644
  --- a/meta/recipes-devtools/binutils/binutils-2.27.inc
  +++ b/meta/recipes-devtools/binutils/binutils-2.27.inc
  @@ -37,6 +37,7 @@ SRC_URI = "\
file://0015-binutils-mips-gas-pic-relax-linkonce.diff \

file://0015-Refine-.cfi_sections-check-to-only-consider-compact-.patch
\

file://0016-Fix-seg-fault-in-ARM-linker-when-trying-to-parse-a-b.patch \
  + 
file://0017-Fix-the-generation-of-alignment-frags-in-code-sectio.patch
\
   "
   S  = "${WORKDIR}/git"

  diff --git 
a/meta/recipes-devtools/binutils/binutils/0017-Fix-the-generation-
of-alignment-frags-in-code-sectio.patch b/meta/recipes-
devtools/binutils/binutils/0017-Fix-the-generation-of-alignment-frags-in-code-
sectio.patch
  new file mode 100644
  index 000..f8b46be
  --- /dev/null
  +++ b/meta/recipes-devtools/binutils/binutils/0017-Fix-the-generation-of-
alignment-frags-in-code-sectio.patch
  @@ -0,0 +1,139 @@
  +From 4a4286465b5d6c28968bc2b29ae08daca7f219a3 Mon Sep 17
00:00:00 2001
  +From: Nick Clifton <ni...@redhat.com <mailto:ni...@redhat.com> >
  +Date: Fri, 18 Nov 2016 11:42:48 -0800
  +Subject: [PATCH] Fix the generation of alignment frags in code sections 
for
AArch64.
  +
  +PR gas/20364
  +* config/tc-aarch64.c (s_ltorg): Change the mapping state after
  +aligning the frag.
  +(aarch64_init): Treat rs_align frags in code sections as
  +containing code, not data.
  +* testsuite/gas/aarch64/pr20364.s: New test.
  +* testsuite/gas/aarch64/pr20364.d: New test driver.
  +
  +Backporting the patch from binutils mainline
  +https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=7ea12e5c3ad54da440c08f32da09534e63e515ca
<https://sourceware.org/git/gitweb.cgi?p=binutils-
gdb.git;h=7ea12e5c3ad54da440c08f32da09534e63e515ca>
  +
  +Upstream-Status: Backport
  +
  +Signed-off-by: Manjukumar Matha mailto:manjukumar.harthikote-ma...@xilinx.com> >
  +---
  + gas/ChangeLog   | 10 ++
  + gas/config/tc-aarch64.c | 10 +++---
  + gas/testsuite/gas/aarch64/pr20364.d | 13 +
  + gas/testsuite/gas/aarch64/pr20364.s | 28

  + 4 files changed, 58 insertions(+), 3 deletions(-)
  + create mode 100644 gas/testsuite/gas/aarch64/pr20364.d
  + create mode 100644 gas/testsuite/gas/aarch64/pr20364.s
  +
  +diff --git a/gas/ChangeLog b/gas/ChangeLog
  +index a39895a..fad06dc 100644
  +--- a/gas/ChangeLog
   b/gas/ChangeLog
  +@@ -1,3 +1,13 @@
  ++2016-08-05  Nick Clifton  <ni...@redhat.com
<mailto:ni...@redhat.com> >
  ++
  ++  PR gas/20364
  ++  * config/tc-aarch64.c (s_ltorg): Change the mapping state after
  ++  aligning the frag.
  ++  (aarch64_init): Treat rs_align frags in code sections as
  ++  containing code, not data.
  ++  * testsuite/gas/aarch64/pr20

[OE-core] [morty] Please include the binutils-2.27 alignment frags for aarch64

[Mike Looijmans]

Could this oe-core master commit be included in the "morty" branch please:
f6f87019073d4f3caa7766aca89faa6781690fba "binutils-2.27.inc: Fix alignment 
frags for aarch64"


Without this patch, arm-trusted-firmware (apparently a requirement to get 
arm64 machines to boot these days) fails to build in the morty branch.



Kind regards,

Mike Looijmans
System Expert

TOPIC Products
Materiaalweg 4, NL-5681 RJ Best
Postbus 440, NL-5680 AK Best
Telefoon: +31 (0) 499 33 69 79
E-mail: mike.looijm...@topicproducts.com
Website: www.topicproducts.com

Please consider the environment before printing this e-mail





--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] [PATCH] linux-firmware: Split out Realtek chipsets rtl8188 rtl8723 rtl8821

[Mike Looijmans]

Add rtl8188 rtl8712 rtl8723 rtl8821 packages to install only firmware for the
corresponding chipset. Uses a rather blunt approach by simply adding all 
firmware
files with matching prefix, to keep the package count down a bit.

Signed-off-by: Mike Looijmans <mike.looijm...@topic.nl>
---
 .../recipes-kernel/linux-firmware/linux-firmware_git.bb | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
index 8e68ae8..1d881d7 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_git.bb
@@ -224,7 +224,7 @@ PACKAGES =+ "${PN}-ralink-license ${PN}-ralink \
  ${PN}-marvell-license ${PN}-sd8686 ${PN}-sd8688 ${PN}-sd8787 
${PN}-sd8797 \
  ${PN}-ti-connectivity-license ${PN}-wl12xx ${PN}-wl18xx \
  ${PN}-vt6656-license ${PN}-vt6656 \
- ${PN}-rtl-license ${PN}-rtl8192cu ${PN}-rtl8192ce ${PN}-rtl8192su 
\
+ ${PN}-rtl-license ${PN}-rtl8188 ${PN}-rtl8192cu ${PN}-rtl8192ce 
${PN}-rtl8192su ${PN}-rtl8723 ${PN}-rtl8821 \
  ${PN}-broadcom-license ${PN}-bcm4329 ${PN}-bcm4330 ${PN}-bcm4334 
${PN}-bcm43340 ${PN}-bcm4339 ${PN}-bcm43430 ${PN}-bcm4354 \
  ${PN}-atheros-license ${PN}-ar9170 ${PN}-carl9170 ${PN}-ath6k 
${PN}-ath9k \
  ${PN}-ar3k-license  ${PN}-ar3k  ${PN}-ath10k-license  
${PN}-ath10k  \
@@ -344,14 +344,20 @@ RDEPENDS_${PN}-sd8787 += "${PN}-marvell-license"
 RDEPENDS_${PN}-sd8797 += "${PN}-marvell-license"
 
 # For rtl
+LICENSE_${PN}-rtl8188 = "Firmware-rtlwifi_firmware"
 LICENSE_${PN}-rtl8192cu = "Firmware-rtlwifi_firmware"
 LICENSE_${PN}-rtl8192ce = "Firmware-rtlwifi_firmware"
 LICENSE_${PN}-rtl8192su = "Firmware-rtlwifi_firmware"
+LICENSE_${PN}-rtl8723 = "Firmware-rtlwifi_firmware"
+LICENSE_${PN}-rtl8821 = "Firmware-rtlwifi_firmware"
 LICENSE_${PN}-rtl-license = "Firmware-rtlwifi_firmware"
 
 FILES_${PN}-rtl-license = " \
   /lib/firmware/LICENCE.rtlwifi_firmware.txt \
 "
+FILES_${PN}-rtl8188 = " \
+  /lib/firmware/rtlwifi/rtl8188*.bin \
+"
 FILES_${PN}-rtl8192cu = " \
   /lib/firmware/rtlwifi/rtl8192cufw*.bin \
 "
@@ -361,10 +367,19 @@ FILES_${PN}-rtl8192ce = " \
 FILES_${PN}-rtl8192su = " \
   /lib/firmware/rtlwifi/rtl8712u.bin \
 "
+FILES_${PN}-rtl8723 = " \
+  /lib/firmware/rtlwifi/rtl8723*.bin \
+"
+FILES_${PN}-rtl8821 = " \
+  /lib/firmware/rtlwifi/rtl8821*.bin \
+"
 
+RDEPENDS_${PN}-rtl8188 += "${PN}-rtl-license"
 RDEPENDS_${PN}-rtl8192ce += "${PN}-rtl-license"
 RDEPENDS_${PN}-rtl8192cu += "${PN}-rtl-license"
 RDEPENDS_${PN}-rtl8192su = "${PN}-rtl-license"
+RDEPENDS_${PN}-rtl8723 += "${PN}-rtl-license"
+RDEPENDS_${PN}-rtl8821 += "${PN}-rtl-license"
 
 # For ti-connectivity
 LICENSE_${PN}-wl12xx = "Firmware-ti-connectivity"
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Kernel: Builds use old version of defconfig

[Mike Looijmans]

On 29-11-16 03:03, Khem Raj wrote:



On Nov 24, 2016, at 5:55 AM, Bruce Ashfield <bruce.ashfi...@gmail.com
<mailto:bruce.ashfi...@gmail.com>> wrote:



On Thu, Nov 24, 2016 at 5:32 AM, Mike Looijmans <mike.looijm...@topic.nl
<mailto:mike.looijm...@topic.nl>> wrote:

    On 24-11-16 11:10, Mike Looijmans wrote:

I'm currently experiencing a problem with "defconfig" files and the
kernel.

In short, when I make a change to the "defconfig" file, the kernel
is rebuilt
(which is correct), but the resulting kernel has been built using
the old
defconfig from a previous build, instead of the new one.

The kernel recipe just contains "file://defconfig" in its SRC_URI. The
defconfig file is in the project's overlay.

For example, I have a kernel with "CONFIG_DEVMEM" disabled:

# gunzip < /proc/config.gz | grep DEVMEM
# CONFIG_DEVMEM is not set

Now, I change the defconfig to contain CONFIG_DEVMEM=y and build the
image.
The result:

# gunzip < /proc/config.gz | grep DEVMEM
# CONFIG_DEVMEM is not set

So the change did not make it into the actual kernel, even though
the kernel
was rebuild as a result of the change.

I run "bitbake -c cleansstate virtual/kernel" and build the image again:

# gunzip < /proc/config.gz | grep DEVMEM
CONFIG_DEVMEM=y

After cleaning, the result is correct and the new defconfig is active.

I'm trying to figure out how this can happen, any help is welcome...


What seems to be the problem is this code in kernel.bbclass:

# Copy defconfig to .config if .config does not exist. This allows
# recipes to manage the .config themselves in
do_configure_prepend().
if [ -f "${WORKDIR}/defconfig" ] && [ ! -f "${B}/.config" ]; then
cp "${WORKDIR}/defconfig" "${B}/.config"
fi

This keeps any existing ".config" file if it happens to still be in the
$B path, which is the case if you're rebuilding a kernel.

I see two possible ways to fix this.

1) During "cleanup" also remove the .config file in the build dir.
However, the build dir is probably kept alive for a reason? I also can't
figure out how that "cleanup" is being done.


2) Remove the second part of the "if" statement, so it becomes:

# Copy defconfig to .config if "defconfig" exists. This allows
# recipes to manage the .config themselves in
do_configure_prepend().
if [ -f "${WORKDIR}/defconfig" ]; then
cp "${WORKDIR}/defconfig" "${B}/.config"
fi

I've tested that, and it solves my problem. However, it will probably
break other people's config mangling?


Yep, in particular all the fragment processing which has the capability of
starting
with a defconfig and then apply fragments from any number of other places. When
that task completes, a full .config is in ${B}.  If that statement comes
along and
clobbers the .config …


so you either assume that .config is valid once generated or you dont. When a
configure task
is triggered it should recreate .config everytime.


The problem seems to be that the class "do_configure" does things that should 
happen before and after things that the recipe would want to change.


Copying defconfig or whatever means to create a .config should be first.

Next, the specific kernel recipe would want to mangle that configuration to 
suit its needs, like applying fragments and such.


Then the makeoldconfig (or whatever) task should run.


The current system assumes that the kernel recipe creates a 
do_configure_prepend to do the mangling, which is rather counterintuitive, one 
would expect to "append" extra actions.


A structured approach would be to split the do_configure into two parts that 
should run in sequence, and then kernel recipes can inject their actions by 
appending to them as they see fit. The first task would create the .config 
file by (forcibly) copying any defconfig or starting point. The second task 
would call the kernel's make script to futher process it.


But this too would break existing recipes.





I'm actually working in the 2.3 release cycle to make the fragment processing
be available to all kernels, which will likely solve this problem .. but we
can't
wait for that.

So I'm hoping that there's a way to make the behaviour cover both use cases.

Maybe someone with more bitbake knowledge can point out a way that can
detect if the task is being run due to a change in the task signature.

Since if you've modified the defconfig, the task is being re-run for that change
and at that point w