Date   

#Tesla T4 Support #tesla

Abdelrahman El-Gammal <a.elgammal2019@...>
 

I am building a custom image for 

ASUS ROG STRIX Z390-I, with Tesla T4

I will build on meta-intel. But the problem is that I am also using Tesla T4 GPU, which requires CUDA toolkit to install. And CUDA requires a supported linux distribution. So, how to setup and use the T4 drivers?


#yocto ASUS ROG STRIX Z390-I #yocto

a.elgammal2019@...
 

Hello,

I have a ROG STRIX Z390-I motherboard with an Intel® Z390 chipset. And I want to create a custom BSP Layer for it. Where should I start? I did not find any yocto community for ASUS. So, Any guides would be helpful.
Thank you


Re: [poky][master][PATCH} VirGL: depends on virtual/gbm

Joel Winarske
 

It looks like a Mesa dependency is looming for NVIDIA:  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9902

Thanks

On Fri, May 28, 2021 at 1:30 PM Alexander Kanavin <alex.kanavin@...> wrote:
Thanks, it took me a moment to understand that this still does not mean that nvidia supports gbm somehow, somewhere, but rather that virgl needs to be explicit about needing gbm.

The patch should be going to the oe-core list.

Alex

On Fri, 28 May 2021 at 21:16, Joel Winarske <joel.winarske@...> wrote:

This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2






Re: [poky][master][PATCH} VirGL: depends on virtual/gbm

Alexander Kanavin
 

Thanks, it took me a moment to understand that this still does not mean that nvidia supports gbm somehow, somewhere, but rather that virgl needs to be explicit about needing gbm.

The patch should be going to the oe-core list.

Alex


On Fri, 28 May 2021 at 21:16, Joel Winarske <joel.winarske@...> wrote:

This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2






[poky][master][PATCH} VirGL: depends on virtual/gbm

Joel Winarske
 


This addresses cases where the platform doesn't depend on Mesa.  Tegra is one example.

From 427d6248379bf37f5522d4bb1013b8c0b7a26b5b Mon Sep 17 00:00:00 2001
From: Joel Winarske <joel.winarske@...>
Date: Fri, 28 May 2021 12:10:46 -0700
Subject: [PATCH] VirGL depends on gbm.h

Signed-off-by: Joel Winarske <joel.winarske@...>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
--
2.30.2



Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Swapna Nannapaneni
 

Typo. No leading space  INIT_MANAGER = "sysvinit".

Thanks,
Priya.


On Fri, May 28, 2021 at 8:55 AM Zoran Stojsavljevic <zoran.stojsavljevic@...> wrote:
> you don't want the leading space.

I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@...> wrote:
>
> On Fri, 28 May 2021, Zoran wrote:
>
> > > Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf
> >
> > Is it INIT_MANAGER  = " sysvinit" , or INIT_MANAGER  = "sysvinit" (no
> > blank at the beginning)?
> >
> > Thank you,
> > Zee
>
>   you don't want the leading space.
>
> rday


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

you don't want the leading space.
I got the idea from reading
https://docs.yoctoproject.org/ref-manual/migration-3.0.html?highlight=init_manager#init-system-selection

But this is exactly why we need some explicit examples. :-)

Zee
_______

On Fri, May 28, 2021 at 2:45 PM Robert P. J. Day <rpjday@crashcourse.ca> wrote:

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
you don't want the leading space.

rday


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Robert P. J. Day
 

On Fri, 28 May 2021, Zoran wrote:

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
you don't want the leading space.

rday


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf
Is it INIT_MANAGER = " sysvinit" , or INIT_MANAGER = "sysvinit" (no
blank at the beginning)?

Thank you,
Zee
_______

On Fri, May 28, 2021 at 1:47 PM Swapna Nannapaneni
<sayinswapna@gmail.com> wrote:

Thanks Robert and Raj!!

I am using Yocto 3.1 Dunfell release.

You are right about the .bbappend file. Changed the name in the overlay to new-ver.bbappend and no longer see the warning.

Tried setting INIT_MANAGER = " sysvinit" in build/conf/local.conf but looks like generated rootfs has init file pointing to init -> ../lib/systemd/systemd

Priya.

On Thu, May 27, 2021 at 7:28 PM Khem Raj <raj.khem@gmail.com> wrote:



On 5/27/21 3:04 PM, sayinswapna@gmail.com wrote:
Hello Yocto team:

I just started with yocto and would like to know the process for
switching the init manager from systemd to sysvinit.

I tried this options in config file
VIRTUAL-RUNTIME_init_manager = "busybox"
PREFERRED_PROVIDER_udev = "sysvinit"
PREFERRED_PROVIDER_udev-utils = "sysvinit"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
DEFAULT_DISTRO_FEATURES += " sysvinit"

I see a warning when building my machine:

No recipe for target:
/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
Please find out which layer is adding this bbappend you could use

bitbake-layers show-appends sysvinit

It seems recipe version is newer perhaps and the bbappend is still made
for older recipe, these things happen when you mix release branches for
different layers.


When I run this build on my target it still shows me systemd init manager...

Not sure if I am missing any options.
Could you please let me know if there are any pointers I can refer to?

Thanks,
Priya








Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Swapna Nannapaneni
 

Thanks Robert and Raj!!

I am using Yocto 3.1 Dunfell release.

You are right about the .bbappend file. Changed the name in the overlay to new-ver.bbappend  and no longer see the warning. 

Tried setting  INIT_MANAGER  = " sysvinit" in build/conf/local.conf but looks like generated rootfs has init file pointing to init -> ../lib/systemd/systemd

Priya.

On Thu, May 27, 2021 at 7:28 PM Khem Raj <raj.khem@...> wrote:


On 5/27/21 3:04 PM, sayinswapna@... wrote:
> Hello Yocto team:
>
> I just started with yocto and would like to know the process for
> switching the init manager from systemd to sysvinit.
>
> I tried this options in config file
> VIRTUAL-RUNTIME_init_manager = "busybox"
> PREFERRED_PROVIDER_udev = "sysvinit"
> PREFERRED_PROVIDER_udev-utils = "sysvinit"
> DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
> DEFAULT_DISTRO_FEATURES += " sysvinit"
>
> I see a warning when building my machine:
>
> No recipe for target:
> /recipes-core/sysvinit/sysvinit_2.88dsf.bbappend

Please find out which layer is adding this bbappend you could use

bitbake-layers show-appends sysvinit

It seems recipe version is newer perhaps and the bbappend is still made
for older recipe, these things happen when you mix release branches for
different layers.

>
> When I run this build on my target it still shows me systemd init manager...
>
> Not sure if I am missing any options.
> Could you please let me know if there are any pointers I can refer to?
>
> Thanks,
> Priya
>
>
>
>
>
>


Re: How to switch yocto INIT_MANAGER from systemd to sysvinit #dunfell

Zoran
 

Why do I (always) point out the obvious?

And I do need... Geniuses are not meant to fix The World to understand them!?

Geniuses should understand The World (and act properly)!

Extras to geniality, do you, YOCTO primes, think?
_______

Robert... If I am correct, i'm I?

Should you include in docs some examples??? Yes, U should!
As for an example fix:
poky/meta/conf/distro/include/init-manager-*.con, NOT
conf/distro/include/init-manager-*.conf

(full path is more explicit, isn't it?)

And some local.conf examples/snippets (since all descriptions are here
and there very dry):

## Add systemd service
INIT_MANAGER = "systemd"
## DISTRO_FEATURES_append = " systemd"
## DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit"
## VIRTUAL-RUNTIME_init_manager = "systemd"
## VIRTUAL-RUNTIME_dev_manager = "systemd"
## VIRTUAL-RUNTIME_initscripts = ""

Where INIT_MANAGER = "systemd" replaces all commented commands below....

My two cent advice,
Zee
_______

On Fri, May 28, 2021 at 1:28 AM Khem Raj <raj.khem@gmail.com> wrote:



On 5/27/21 3:04 PM, sayinswapna@gmail.com wrote:
Hello Yocto team:

I just started with yocto and would like to know the process for
switching the init manager from systemd to sysvinit.

I tried this options in config file
VIRTUAL-RUNTIME_init_manager = "busybox"
PREFERRED_PROVIDER_udev = "sysvinit"
PREFERRED_PROVIDER_udev-utils = "sysvinit"
DISTRO_FEATURES_BACKFILL_CONSIDERED = "sysvinit"
DEFAULT_DISTRO_FEATURES += " sysvinit"

I see a warning when building my machine:

No recipe for target:
/recipes-core/sysvinit/sysvinit_2.88dsf.bbappend
Please find out which layer is adding this bbappend you could use

bitbake-layers show-appends sysvinit

It seems recipe version is newer perhaps and the bbappend is still made
for older recipe, these things happen when you mix release branches for
different layers.


When I run this build on my target it still shows me systemd init manager...

Not sure if I am missing any options.
Could you please let me know if there are any pointers I can refer to?

Thanks,
Priya







Re: Where to define username/password when fetching sstate via http with basic authentication?

Manuel Wagesreither
 

Hi Quentin,

obviously I didn't read that page carefully enough. Sorry for the noise and thanks for the hint.

Cheers, Manuel


Am Fr, 28. Mai 2021, um 11:35, schrieb Quentin Schulz:

Hi Manuel,

On Fri, May 28, 2021 at 11:26:26AM +0200, Manuel Wagesreither wrote:
> Hello all,

> to speed up builds, we would like to make the CI generated sstate-cache available via internet. Due to IP concerns, we don't want to make it publically available but for authenticated hosts only.

> [1] indicates it is possible to serve the sstate-cache over http with basic authentication [2].

> How does one set the username & password? By putting it into the URL like in the following example, or are other ways available?
> ```
> SSTATE_MIRRORS ?= "\
> ```


There is an example in the commit you sent, so I would say:
SSTATE_MIRRORS ?= " \
?

Cheers,
Quentin







Re: Where to define username/password when fetching sstate via http with basic authentication?

Quentin Schulz
 

Hi Manuel,

On Fri, May 28, 2021 at 11:26:26AM +0200, Manuel Wagesreither wrote:
Hello all,

to speed up builds, we would like to make the CI generated sstate-cache available via internet. Due to IP concerns, we don't want to make it publically available but for authenticated hosts only.

[1] indicates it is possible to serve the sstate-cache over http with basic authentication [2].

How does one set the username & password? By putting it into the URL like in the following example, or are other ways available?
```
SSTATE_MIRRORS ?= "\
file://.* http://username:password@someserver.tld/share/sstate/PATH"
```
There is an example in the commit you sent, so I would say:
SSTATE_MIRRORS ?= " \
file://.* http://someserver.tld/share/sstate/PATH;user=username:password;downloadfilename=PATH \n"
?

Cheers,
Quentin


Where to define username/password when fetching sstate via http with basic authentication?

Manuel Wagesreither
 

Hello all,

to speed up builds, we would like to make the CI generated sstate-cache available via internet. Due to IP concerns, we don't want to make it publically available but for authenticated hosts only.

[1] indicates it is possible to serve the sstate-cache over http with basic authentication [2].

How does one set the username & password? By putting it into the URL like in the following example, or are other ways available?
```
SSTATE_MIRRORS ?= "\
file://.* http://username:password@someserver.tld/share/sstate/PATH"
```

Thank you!

[1] https://patchwork.openembedded.org/patch/130333/
[2] https://en.wikipedia.org/wiki/Basic_access_authentication


[meta-zephyr][hardknott][PATCH 4/4] acrn.conf: drop acrn machine configuration

Naveen Saini
 

zephyr can be build for 'acrn' with following configuration:

MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/acrn.conf | 9 ---------
1 file changed, 9 deletions(-)
delete mode 100644 conf/machine/acrn.conf

diff --git a/conf/machine/acrn.conf b/conf/machine/acrn.conf
deleted file mode 100644
index c044933..0000000
--- a/conf/machine/acrn.conf
+++ /dev/null
@@ -1,9 +0,0 @@
-#@TYPE: Machine
-#@NAME: acrn
-#@DESCRIPTION: Machine for Zephyr BOARD acrn
-
-require conf/machine/include/qemu.inc
-require conf/machine/include/tune-corei7-common.inc
-ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"
-
-ARCH_acrn = "x86"
--
2.17.1


[meta-zephyr][hardknott][PATCH 3/4] intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS

Naveen Saini
 

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "minnowboard"

By default it set to MinnowBoard Max 'minnowboard'

Currently 32-bit supported boards:
* up_squared_32
* minnowboard

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/include/tune-core2-common.inc | 6 ++++++
conf/machine/intel-x86-32.conf | 12 ++++++++++++
2 files changed, 18 insertions(+)
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf

diff --git a/conf/machine/include/tune-core2-common.inc b/conf/machine/include/tune-core2-common.inc
new file mode 100644
index 0000000..012f078
--- /dev/null
+++ b/conf/machine/include/tune-core2-common.inc
@@ -0,0 +1,6 @@
+DEFAULTTUNE ?= "core2-32"
+require conf/machine/include/tune-core2.inc
+require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDES
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-32.conf b/conf/machine/intel-x86-32.conf
new file mode 100644
index 0000000..06f6da5
--- /dev/null
+++ b/conf/machine/intel-x86-32.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: intel-x86-32
+#@DESCRIPTION: common MACHINE for 32-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'minnowboard' board.
+
+require conf/machine/include/tune-core2-common.inc
+
+ARCH_intel-x86-32 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "minnowboard"
+# ZEPHYR_BOARD ?= "up_squared_32"
+ZEPHYR_BOARD ?= "minnowboard"
--
2.17.1


[meta-zephyr][hardknott][PATCH 1/4] zephyr-kernel-src: fix efi generation failure for x86 boards

Naveen Saini
 

With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit mode).

To achieve this, an python tool[1] has been added to convert zephyr ELF file
into an EFI appliable. But currently this does not work with Yocto
cross-compilation env.
This patch fix this issue and allow to build zephyr.efi

Ref:
[1]https://github.com/zephyrproject-rtos/zephyr/commit/928d31125f0b4eb28fe1cf3f3ad02b0ae071d7fd

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
3 files changed, 87 insertions(+), 4 deletions(-)
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

diff --git a/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
new file mode 100644
index 0000000..fd6fc6b
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
@@ -0,0 +1,80 @@
+From cfde3b1018c3151b6cc1fbe3e9e163d0aaf16954 Mon Sep 17 00:00:00 2001
+From: Naveen Saini <naveen.kumar.saini@intel.com>
+Date: Tue, 11 May 2021 13:46:39 +0800
+Subject: [PATCH] x86: fix efi binary generation issue in cross compilation env
+
+Set root directory for headers.
+
+Upstream-Status: Inappropriate [Cross-compilation specific]
+
+Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
+---
+ arch/x86/zefi/zefi.py | 6 +++++-
+ boards/x86/ehl_crb/CMakeLists.txt | 1 +
+ boards/x86/qemu_x86/CMakeLists.txt | 1 +
+ boards/x86/up_squared/CMakeLists.txt | 1 +
+ 4 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/zefi/zefi.py b/arch/x86/zefi/zefi.py
+index d3514391a8..b9eccbfa10 100755
+--- a/arch/x86/zefi/zefi.py
++++ b/arch/x86/zefi/zefi.py
+@@ -106,7 +106,10 @@ def build_elf(elf_file):
+ # + We need pic to enforce that the linker adds no relocations
+ # + UEFI can take interrupts on our stack, so no red zone
+ # + UEFI API assumes 16-bit wchar_t
+- cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.",
++
++ # Pass --sysroot path for cross compilation
++ sysrootarg = "--sysroot=" + args.sysroot
++ cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.", sysrootarg,
+ "-fno-stack-protector", "-fpic", "-mno-red-zone", "-fshort-wchar",
+ "-Wl,-nostdlib", "-T", ldscript, "-o", "zefi.elf", cfile]
+ verbose(" ".join(cmd))
+@@ -145,6 +148,7 @@ def parse_args():
+ parser.add_argument("-o", "--objcopy", required=True, help="objcopy to be used")
+ parser.add_argument("-f", "--elf-file", required=True, help="Input file")
+ parser.add_argument("-v", "--verbose", action="store_true", help="Verbose output")
++ parser.add_argument("-s", "--sysroot", required=True, help="Cross compilation --sysroot=path")
+
+ return parser.parse_args()
+
+diff --git a/boards/x86/ehl_crb/CMakeLists.txt b/boards/x86/ehl_crb/CMakeLists.txt
+index 0d572eff30..6a228107dc 100644
+--- a/boards/x86/ehl_crb/CMakeLists.txt
++++ b/boards/x86/ehl_crb/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/qemu_x86/CMakeLists.txt b/boards/x86/qemu_x86/CMakeLists.txt
+index 1131a5c7ce..489f17192b 100644
+--- a/boards/x86/qemu_x86/CMakeLists.txt
++++ b/boards/x86/qemu_x86/CMakeLists.txt
+@@ -4,6 +4,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/up_squared/CMakeLists.txt b/boards/x86/up_squared/CMakeLists.txt
+index 0eaa9753fc..2e8ce7cfbc 100644
+--- a/boards/x86/up_squared/CMakeLists.txt
++++ b/boards/x86/up_squared/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+--
+2.17.1
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
index 6350d86..5d66f0f 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
@@ -8,3 +8,6 @@ SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

PV = "2.5.0+git${SRCPV}"
+
+SRC_URI_append = " file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+ "
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5ee40d4..b3b9565 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -1,10 +1,6 @@
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

-# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
-include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
-
inherit cmake

# This file might be included from other places (like other layers) and not
@@ -23,3 +19,7 @@ SRC_URI = "\
file://0001-cmake-add-yocto-toolchain.patch \
"
S = "${WORKDIR}/git"
+
+# Default to a stable version
+PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
+include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
--
2.17.1


[meta-zephyr][hardknott][PATCH 2/4] intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS

Naveen Saini
 

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "ehl_crb"

By default it set to Elkhart Lake CRB 'ehl_crb'

Currently 64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb
* acrn
* acrn_ehl_crb

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@intel.com>
---
conf/machine/include/tune-corei7-common.inc | 3 +++
conf/machine/intel-x86-64.conf | 14 ++++++++++++++
2 files changed, 17 insertions(+)
create mode 100644 conf/machine/intel-x86-64.conf

diff --git a/conf/machine/include/tune-corei7-common.inc b/conf/machine/include/tune-corei7-common.inc
index 7ad9516..509d190 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,3 +1,6 @@
DEFAULTTUNE ?= "corei7-64"
require conf/machine/include/tune-corei7.inc
require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDE
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-64.conf b/conf/machine/intel-x86-64.conf
new file mode 100644
index 0000000..2935cff
--- /dev/null
+++ b/conf/machine/intel-x86-64.conf
@@ -0,0 +1,14 @@
+#@TYPE: Machine
+#@NAME: intel-x86-64
+#@DESCRIPTION: common MACHINE for 64-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'ech_crb' board.
+
+require conf/machine/include/tune-corei7-common.inc
+
+ARCH_intel-x86-64 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "acrn"
+# ZEPHYR_BOARD ?= "acrn_ehl_crb"
+# ZEPHYR_BOARD ?= "up_squared"
+# ZEPHYR_BOARD ?= "ehl_crb_sbl"
+ZEPHYR_BOARD ?= "ehl_crb"
--
2.17.1


Re: [meta-zephyr][PATCH 1/5] zephyr-kernel: Clone mbedtls

Naveen Saini
 

V2.6.0-rc1 patch is not merged as it is pre-release. Lets wait for stable release.
Could you please rebase these patches for v2.5.0 latest master ?

Regards,
Naveen

-----Original Message-----
From: amit.kucheria@verdurent.com <amit.kucheria@verdurent.com>
Sent: Wednesday, May 26, 2021 11:36 PM
To: yocto@lists.yoctoproject.org; wojciech.zmuda@huawei.com;
andrei.gherzan@huawei.com; Saini, Naveen Kumar
<naveen.kumar.saini@intel.com>; zbigniew.bodek@huawei.com
Cc: Amit Kucheria <amit.kucheria.ext@huawei.com>
Subject: [meta-zephyr][PATCH 1/5] zephyr-kernel: Clone mbedtls

From: Amit Kucheria <amit.kucheria.ext@huawei.com>

MBed TLS is a library that implements cryptographic primitives and SSL/TLS
and DTLS protocols that are needed in secure network communications.

Add it to the kernel include files to build and link against applications that
need mbedtls.

Signed-off-by: Amit Kucheria <amit.kucheria.ext@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 1 +
3 files changed, 3 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 330fe59aebe5..c9acbbbc3645 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -28,6 +28,7 @@ ZEPHYR_MODULES = ""
ZEPHYR_MODULES_append_arm = "\;${S}/modules/cmsis"
ZEPHYR_MODULES_append_nordic = "\;${S}/modules/hal/nordic"
ZEPHYR_MODULES_append_stm32 = "\;${S}/modules/hal/stm32"
+ZEPHYR_MODULES_append_mbedtls = "\;${S}/modules/lib/mbedtls"
ZEPHYR_MODULES_append_openamp = "\;${S}/modules/lib/open-
amp\;${S}/modules/hal/libmetal"

EXTRA_OECMAKE_append = " -DZEPHYR_MODULES=${ZEPHYR_MODULES}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
index 6ea15931607d..a0e358ecd4f4 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
@@ -6,5 +6,6 @@ SRCREV_stm32 =
"f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"

PV = "2.6.0-rc1+git${SRCPV}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-
kernel/zephyr-kernel/zephyr-kernel-src.inc
index 9fc08baaf210..8dcfec6f1f88 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -17,6 +17,7 @@ SRC_URI = "\
git://github.com/zephyrproject-
rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
git://github.com/zephyrproject-
rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=
nordic \
git://github.com/zephyrproject-
rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=
stm32 \
+
+ git://github.com/zephyrproject-rtos/mbedtls.git;protocol=https;destsuf
+ fix=git/modules/lib/mbedtls;name=mbedtls \
git://github.com/zephyrproject-rtos/open-
amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-
amp \
git://github.com/zephyrproject-
rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=l
ibmetal \
git://github.com/zephyrproject-
rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;na
me=tinycrypt \
--
2.25.1


hardknott: open-embedded: kernel-fitimage.bblass, fiitmage_emit_section_boot_script bad

richard allen
 

Been trying added a uboot script to my fitImage ( in hardknott)

Looks like the routine fiitmage_emit_section_boot_scrip Has not updated it syntax for node name or hash node

Still using’@’ instead of ‘-‘ 

Is this being looked at?

Thanks

Richard Allen

 

 

 

3481 - 3500 of 57144