BBB example:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041696.html

The line:
DISTRO_FEATURES_append = " ram"

Should be:
DISTRO_FEATURES_append = " nfs"

BSP Traces for BBB (YOCTO Warrior):
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-releases/bbb-warrior/target-bbb-platform-traces.txt

And the ash script in the U-Boot supporting above written:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/u-boot.ash#L3

Line 3 to 10.

Please, pay attention to line 1 as well!

Zee
_______

On Thu, Mar 11, 2021 at 12:32 AM p32 via lists.yoctoproject.org
<p32=tuta.io@...> wrote:

Hello everyone,

I am currently using this Yocto-based build setup provided by NXP to create a custom Linux distribution for one of the i.MX boards. My custom image is based on the core-image-minimal recipe and works fine, i.e., runs on the platform as expected. However, I have to following two issues:

Although core-image-minimal is documented as "A small image just capable of allowing a device to boot", I can tell from the running system that it contains a huge number of components that I think are not be strictly necessary to boot the device. For instance, the boot log contains entries about an FPGA manager framework, Bluetooth, Ethernet, KVM, USB, and a lot of i.MX-specific modules such as for DMA or power management. For evaluation purposes, I want to get rid of all of these and end up with a truly minimal Linux system that is able to boot, schedule its tasks, and to communicate via UART. How can I achieve this without losing the i.MX support, i.e., the generation of a bootloader and suitable device tree files?

Furthermore, I would like the minimal system to run entirely from RAM. More specifically: After being started from the SD card, U-Boot should start the Linux distribution via initramfs. I am able to generate some kind of initramfs binary using the following changes:
# local.conf
INITRAMFS_IMAGE = "recipe-name"
INITRAMFS_IMAGE_BUNDLE = "1"
# recipe-name.bb
IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"
PACKAGE_INSTALL = "${IMAGE_INSTALL}"

However, this does not affect the generated U-Boot, which means that U-Boot still tries to boot from an SD card partition. What is the "right way" to make use of the Image-initramfs-board.bin or the image-board.cpio.gz files that Yocto creates in this case?

Any help yould be greatly appreciated.

Kind regards!

From: Kai Kang <kai.kang@...>

It fails to comile samhain for powerpc(qemuppc):

| x_sh_dbIO.c: In function 'swap_short':
| x_sh_dbIO.c:229:36: error: initializer element is not constant
| 229 | static unsigned short ooop = *iptr;
| | ^

Fix it by not use local static variable.

Signed-off-by: Kai Kang <kai.kang@...>
---
...-initializer-element-is-not-constant.patch | 32 +++++++++++++++++++
recipes-ids/samhain/samhain.inc | 1 +
2 files changed, 33 insertions(+)
create mode 100644 recipes-ids/samhain/files/samhain-fix-initializer-element-is-not-constant.patch

diff --git a/recipes-ids/samhain/files/samhain-fix-initializer-element-is-not-constant.patch b/recipes-ids/samhain/files/samhain-fix-initializer-element-is-not-constant.patch
new file mode 100644
index 0000000..846e132
--- /dev/null
+++ b/recipes-ids/samhain/files/samhain-fix-initializer-element-is-not-constant.patch
@@ -0,0 +1,32 @@
+Fix error when compile for powerpc:
+
+| x_sh_dbIO.c: In function 'swap_short':
+| x_sh_dbIO.c:229:36: error: initializer element is not constant
+| 229 | static unsigned short ooop = *iptr;
+| | ^
+
+Upstream-Status: Pending
+
+Signed-off-by: Kai Kang <kai.kang@...>
+---
+ src/sh_dbIO.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/sh_dbIO.c b/src/sh_dbIO.c
+index b547ac5..7516463 100644
+--- a/src/sh_dbIO.c
++++ b/src/sh_dbIO.c
+@@ -226,11 +226,11 @@ static unsigned short * swap_short (unsigned short * iptr)
+ else
+ {
+ /* alignment problem */
+- static unsigned short ooop = *iptr;
++ unsigned short ooop = *iptr;
+ unsigned short hi = (ooop & 0xff00);
+ unsigned short lo = (ooop & 0xff);
+ ooop = (lo << 8) | (hi >> 8);
+- return &ooop;
++ *iptr = ooop;
+ }
+ return iptr;
+ #else
diff --git a/recipes-ids/samhain/samhain.inc b/recipes-ids/samhain/samhain.inc
index 6a2eb08..0148e46 100644
--- a/recipes-ids/samhain/samhain.inc
+++ b/recipes-ids/samhain/samhain.inc
@@ -18,6 +18,7 @@ SRC_URI = "https://la-samhna.de/archive/samhain_signed-${PV}.tar.gz \
file://samhain-avoid-searching-host-for-postgresql.patch \
file://samhain-add-LDFLAGS-variable-for-samhain_setpwd.patch \
file://fix-build-with-new-version-attr.patch \
+ file://samhain-fix-initializer-element-is-not-constant.patch \
"

SRC_URI[sha256sum] = "3e57574036d5055e9557ec5095818b419ea6c4365370fc2ccce1e9f87f9fad08"
--
2.17.1

Create the file /etc/systemd/network/eth0.conf:

[Match]
Name=eth0
[Network]
Address=<ip>
Gateway=<ip>
DNS=<ip>

That didn't work BUT editing /lib/systemd/network/80-wired.network

[Match]
Name=en* eth*
KernelCommandLine=!nfsroot

[Match]
Name=eth0
[Network]
Address=192.168.0.101/24
#Gateway=<ip>
#DNS=<ip>

[Network]
DHCP=no

[DHCP]
#RouteMetric=10
#ClientIdentifier=mac

... did work, after:

root@arria10:~# systemctl restart systemd-networkd

Preferred method for local configuration is using /etc/systemd/network. However, the probable reason why it did not work is that the file should be eth0.network. The name of the file(s) do not matter that much. The extension does though.

-- 
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

Hello everyone,

I am currently using this Yocto-based build setup provided by NXP to create a custom Linux distribution for one of the i.MX boards. My custom image is based on the core-image-minimal recipe and works fine, i.e., runs on the platform as expected. However, I have to following two issues:

Although core-image-minimal is documented as "A small image just capable of allowing a device to boot", I can tell from the running system that it contains a huge number of components that I think are not be strictly necessary to boot the device. For instance, the boot log contains entries about an FPGA manager framework, Bluetooth, Ethernet, KVM, USB, and a lot of i.MX-specific modules such as for DMA or power management. For evaluation purposes, I want to get rid of all of these and end up with a truly minimal Linux system that is able to boot, schedule its tasks, and to communicate via UART. How can I achieve this without losing the i.MX support, i.e., the generation of a bootloader and suitable device tree files?

Furthermore, I would like the minimal system to run entirely from RAM. More specifically: After being started from the SD card, U-Boot should start the Linux distribution via initramfs. I am able to generate some kind of initramfs binary using the following changes:
However, this does not affect the generated U-Boot, which means that U-Boot still tries to boot from an SD card partition. What is the "right way" to make use of the Image-initramfs-board.bin or the image-board.cpio.gz files that Yocto creates in this case?

Any help yould be greatly appreciated.

Kind regards!

Create the file /etc/systemd/network/eth0.conf:

[Match]
Name=eth0
[Network]
Address=<ip>
Gateway=<ip>
DNS=<ip>

Restart systemd-networkd

# systemctl restart systemd-networkd

or reboot.

:rjs

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

What is your startup manager? systemd or SysVInit?

systemd

- Without the patch fscryptctl is installed in
/usr/bin/usr/local/bin instead of /usr/bin.
---
recipes-security/fscryptctl/fscryptctl_1.0.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-security/fscryptctl/fscryptctl_1.0.0.bb b/recipes-security/fscryptctl/fscryptctl_1.0.0.bb
index 440b4e3..df76a3d 100644
--- a/recipes-security/fscryptctl/fscryptctl_1.0.0.bb
+++ b/recipes-security/fscryptctl/fscryptctl_1.0.0.bb
@@ -15,7 +15,7 @@ SRC_URI = "git://github.com/google/fscryptctl.git"
S = "${WORKDIR}/git"

do_install() {
- oe_runmake DESTDIR=${D}${bindir} install
+ oe_runmake DESTDIR=${D} PREFIX=/usr install
}

RRECOMMENDS_${PN} += "\
--
2.17.1

On 3/9/21 11:34 PM, jchludzinski wrote:

To start, do you have the driver required for your network interface?

Yes, the network/Ethernet device is recognized by Linux and the appropriate driver is loaded. If I use:

$ ip add add 192.168.9.101/24 dev eth0

I’m up and running. But I want the IP assignment to happen during boot time.

What is your startup manager? systemd or SysVInit?

--
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700

On 3/10/21 2:31 AM, Ming Liu wrote:

Hi, akuster808:

I saw this patch set has been merged to gatesgarth, may I ask, any
plan for dunfell? I am asking because dunfell is a LTS branch and many
users are building their products based on it. Thanks!

that are being built current. I can on build on branch at a time and it
takes time to do each.  Things are looking good so I suspect they
changes will land in the next day or so.

-armin

the best,
thank you

series in build testing

-armin

On 3/2/21 6:57 AM, liu.ming50@...
<mailto:liu.ming50@...> wrote:
> From: Ming Liu <ming.liu@... <mailto:ming.liu@...>>
>
> Cherry pick some IMA/EVM fixes to LTS dunfell branch, with these
> patches applied, I could run a ima enabled image with
sysvinit/systemd
> on qemuarm/qemuarm64 and some NXP machines.
>
> Ming Liu (9):
>   ima-evm-utils: set native REQUIRED_DISTRO_FEATURES to empty
>   initramfs-framework-ima: fix a wrong path
>   ima-evm-keys: add recipe
>   initramfs-framework-ima: RDEPENDS on ima-evm-keys
>   meta: refactor IMA/EVM sign rootfs
>   README.md: update according to the refactoring in
>     ima-evm-rootfs.bbclass
>   initramfs-framework-ima: let ima_enabled return 0
>   ima-evm-rootfs.bbclass: avoid generating /etc/fstab for wic
>   ima-policy-hashed: add CGROUP2_SUPER_MAGIC fsmagic
>
>  meta-integrity/README.md                      |  4 ++-
>  meta-integrity/classes/ima-evm-rootfs.bbclass | 33
+++++++++----------
>  .../initrdscripts/initramfs-framework-ima.bb
<http://initramfs-framework-ima.bb>  |  2 +-
>  .../initrdscripts/initramfs-framework-ima/ima |  3 +-
>  .../ima-evm-keys/ima-evm-keys_1.0.bb
<http://ima-evm-keys_1.0.bb>          | 16 +++++++++
>  .../ima-evm-utils/ima-evm-utils_git.bb
<http://ima-evm-utils_git.bb>        |  1 +
>  .../ima_policy_hashed/files/ima_policy_hashed |  3 ++
>  7 files changed, 41 insertions(+), 21 deletions(-)
>  create mode 100644
meta-integrity/recipes-security/ima-evm-keys/ima-evm-keys_1.0.bb
<http://ima-evm-keys_1.0.bb>
>

Hi Robert,

On Wed, Mar 10, 2021 at 06:16:44AM -0500, Robert P. J. Day wrote:

On Tue, 9 Mar 2021, Quentin Schulz wrote:

Hi Robert,

On Tue, Mar 09, 2021 at 09:39:14AM -0500, Robert P. J. Day wrote:

bitbake manual, chapter 3, examples of conditional syntax:

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples

correctly distinguishes between A_foo_append and A_append_foo, but how
often would one use that first form, anyway?

most uses of conditional appending are either just straight
appending:

VAR_append = "fubar"

or used with an override thusly:

VAR_append_x86 = "snafu"

is there an actual practical usage of, say:

VAR_x86_append = "huh"

i can't remember the last time i saw something of that form and,
while it might be worth explaining, it seems that the reader might be
warned that that form is almost certainly *not* what they want.

Yes, in 99% of the cases, you want VAR_append_foo and not VAR_foo_append.

VAR_foo_append makes sense when you want to append to VAR_foo which
is a way to override completely VAR for builds matching the foo
override. This happens in kernel-yocto recipes where branches and
defconfigs are different per machine for example.

can you point at an actual example of that? i took a look and all
the yocto kernel recipes i see use the first form. am i just looking
in the wrong place?

https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-yocto_5.10.bb#n12
for example.

This is an example of a "valid" use case (not that there are invalid
ones) for VAR_foo.

Would probably a better example:
https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-yocto_5.10.bb#n50

So, you might decide that a machine is so much different than others
that KERNEL_FEATURES should be overridden for said machine.

Then in a bbappend, one might want to add another feature for this
machine, they'll therefore need to use KERNEL_FEATURES_foo_append.

I do not have examples at hand of VAR_foo_append except the ones Leon
sent in another mail. Which should show how rare it is :)

Cheers,
Quentin

On Tue, 9 Mar 2021, Quentin Schulz wrote:

Hi Robert,

On Tue, Mar 09, 2021 at 09:39:14AM -0500, Robert P. J. Day wrote:

bitbake manual, chapter 3, examples of conditional syntax:

https://docs.yoctoproject.org/bitbake/bitbake-user-manual/bitbake-user-manual-metadata.html#examples

correctly distinguishes between A_foo_append and A_append_foo, but how
often would one use that first form, anyway?

most uses of conditional appending are either just straight
appending:

VAR_append = "fubar"

or used with an override thusly:

VAR_append_x86 = "snafu"

is there an actual practical usage of, say:

VAR_x86_append = "huh"

i can't remember the last time i saw something of that form and,
while it might be worth explaining, it seems that the reader might be
warned that that form is almost certainly *not* what they want.

Yes, in 99% of the cases, you want VAR_append_foo and not VAR_foo_append.

VAR_foo_append makes sense when you want to append to VAR_foo which
is a way to override completely VAR for builds matching the foo
override. This happens in kernel-yocto recipes where branches and
defconfigs are different per machine for example.

can you point at an actual example of that? i took a look and all
the yocto kernel recipes i see use the first form. am i just looking
in the wrong place?

rday

Hi,

On 3/9/21 11:32 PM, Joe MacDonald wrote:

[Re: [yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 14:53) Anatol Belski wrote:

Hi Joe,

thanks for the quick check. The patch applies fine to dunfell and
gatesgarth, master has the changed recipe version in the bb name. I was
about to rebase to master but pulling shows already did it. I was too slow
:) thanks for the quick fix.

No problem!  I assumed you were working on a just-slightly-out-of-date
master branch and my work tree already had your patch half applied when
the 'git am' failed, so I just finished that part up.

Hi Joe,


This patch doesn't need to be merged into master because I have fixed it in commit fb15056ff44318d7886fd0f68e2f6dba716e9be4.

either way, a backport to dunfell and gatesgarth would be great to have then.

Thanks!

Anatol

//Yi

I'll get to the other branches in a bit.

-Joe.

Regards

Anatol

On 3/9/2021 2:00 PM, Joe MacDonald wrote:

Hi Anatol,

I will confirm this against the other branches (dunfell and gatesgarth)
but your patch doesn't appear to be against the current master branch (and
it's unlikely one patch will apply to all branches).  Can you send out
specific patches against the head of tree for each branch you care about,
please?  Then I can get them merged for you.

Thanks,
-Joe.

[[yocto] [meta-selinux][dunfell][gatesgarth][master][PATCH] libselinux-python: Fix build error due to missing target config] On 21.03.09 (Tue 11:55) Anatol Belski wrote:

This fixes the error below:

gcc: error: unrecognized command line option
‘-fmacro-prefix-map=/path/to/build/libselinux-python/3.0-r0=/usr/src/debug/libselinux-python/3.0-r0’

Without inheriting the config, supposedly a wrong compiler is used.

Signed-off-by: Anatol Belski <anbelski@...>
---
   recipes-security/selinux/libselinux-python_3.0.bb | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/recipes-security/selinux/libselinux-python_3.0.bb b/recipes-security/selinux/libselinux-python_3.0.bb
index 2b5438d..3c03df1 100644
--- a/recipes-security/selinux/libselinux-python_3.0.bb
+++ b/recipes-security/selinux/libselinux-python_3.0.bb
@@ -4,6 +4,8 @@ SRC_URI = "https://github.com/SELinuxProject/selinux/releases/download/${SELINUX
   require ${BPN}.inc
+inherit python3targetconfig
+
   LIC_FILES_CHKSUM = "file://LICENSE;md5=84b4d2c6ef954a2d4081e775a270d0d0"
   SRC_URI[md5sum] = "b387a66f087b6d97713570e85ec89d89"
-- 
2.17.1

inspired by my earlier plaintive mewling of "gosh, i wish YP had
better ruby support," konrad weihmann put in a ridiculous amount of
work and came up with:

https://github.com/priv-kweihmann/meta-rubygems

while i am listed as a contributor, konrad has done 98% of the work,
and i really plan on diving back into that soon, but that layer is
effectively all his, and he invited me to let people know about it, if
anyone else wanted to play along.

rday

Hello,

Maybe you can stop in the U-Boot monitor, and check your environment?
=>
=> print serverip
=> print ipaddr
=> print gatewayip
=> print gw_ip

And see what and how your bootcmd and similar env variables look like?

And if you do not have defined above, to add them (according to ash
script) and try booting again?

Zee
_______


On Tue, Mar 9, 2021 at 10:28 PM jchludzinski via
lists.yoctoproject.org
<jchludzinski=vivaldi.net@...> wrote:

i suspect i know the answer, just want to confirm ... friend tells
me yesterday he's working with LTS20, i said, "uh, that's not even out
yet," he assures he his company has an early release, but he couldn't
tell me what version of YP it corresponded to.

based on regularity of releases on both sides, i would *guess* it's
equivalent to gatesgarth, is that a good guess?

rday

To start, do you have the driver required for your network interface?

Yes, the network/Ethernet device is recognized by Linux and the appropriate driver is loaded. If I use:

$ ip add add 192.168.9.101/24 dev eth0

I’m up and running. But I want the IP assignment to happen during boot time.