Date   

Re: [meta-java] icedtea7 fetching error

Alexander Kanavin
 

I have reconfigured our build system to use an internal server via bbappend:


placed all the tarballs there according to expected locations, and it works just fine.

Alex


On Fri, 11 Jun 2021 at 12:44, <stefano.fiore84@...> wrote:

I have also the tarball but the build will fail later in the configure phase stating:
icedtea7 "Invalid OpenJDK source zip specified".

Is there something more I can try ?





Re: QEMU Size Increase from Yocto Thud to Zeus

Ross Burton <ross@...>
 

Are you installing qemu into your image though?

Qemu did get larger as it is built with more architectures enabled,
but unless you're installing it in your image it won't make a
difference.

Ross

On Fri, 11 Jun 2021 at 11:40, Aashik Aswin <thisisaash9698@...> wrote:

Hi Experts,

I am upgrading my Linux from Yocto Thud to Zeus (5.4 Kernel) . After building I could see a significant increase in the size of the image.
On checking with buildhistory enabled, I could see that qemu has nearly doubled in size.

Thud (4.19) - 223084 KiB qemu
Zeus (5.4) - 474757 KiB qemu

Is this size increase expected or are there some additional configs that might have been added as a part of the upgrade ?

Appreciate your help.

TIA,
Aashik



Re: [meta-java] icedtea7 fetching error

stefano.fiore84@...
 

I have also the tarball but the build will fail later in the configure phase stating:
icedtea7 "Invalid OpenJDK source zip specified".

Is there something more I can try ?


QEMU Size Increase from Yocto Thud to Zeus

Aashik Aswin
 

Hi Experts,

I am upgrading my Linux from Yocto Thud to Zeus (5.4 Kernel) . After building I could see a significant increase in the size of the image.
On checking with buildhistory enabled, I could see that qemu has nearly doubled in size.

Thud (4.19) - 223084  KiB     qemu
Zeus (5.4) - 474757  KiB     qemu

Is this size increase expected or are there some additional configs that might have been added as a part of the upgrade ?

Appreciate your help.

TIA,
Aashik


[meta-zephyr][PATCH 3/3] zephyr-flash-bossac.bbclass: Enable board flashing via bossac

Wojciech Zmuda
 

From: Nagesh Shamnur <nagesh.shamnur@...>

Currently only dfu and pyocd flashing are supported. Some boards
such as Arduino Nano 33 BLE can be flashed via bossac which is
released by Arduino repo. Find the installed Arudino version of
bossac and flash using that tool.

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
---
classes/zephyr-flash-bossac.bbclass | 50 +++++++++++++++++++++++++++
conf/machine/arduino-nano-33-ble.conf | 1 +
2 files changed, 51 insertions(+)
create mode 100644 classes/zephyr-flash-bossac.bbclass

diff --git a/classes/zephyr-flash-bossac.bbclass b/classes/zephyr-flash-bossac.bbclass
new file mode 100644
index 0000000..50222d5
--- /dev/null
+++ b/classes/zephyr-flash-bossac.bbclass
@@ -0,0 +1,50 @@
+#@DESCRIPTION: class file to flash boards like Arduino Nano BLE which depends on bossac for flashing
+
+python do_flash_usb() {
+ import shutil
+ import subprocess
+ import serial.tools.list_ports
+
+ # Note: make sure the installed bossac is set to PATH before running flash_usb()
+ # Check if bossac is avaiable for flashing
+ origbbenv = d.getVar("BB_ORIGENV", False)
+ bossac_path = shutil.which("bossac", path=origbbenv.getVar('PATH'))
+
+ if not bossac_path:
+ bb.fatal("ERROR: bossac not found, please install first and add to PATH")
+
+ board = d.getVar('BOARD')
+
+ if board == 'arduino_nano_33_ble':
+ # find the serial port to which board is connected to
+ for port in serial.tools.list_ports.comports():
+ if 'Arduino Nano 33 BLE' in port.description:
+ serial_port = port.device
+ break
+ else:
+ bb.fatal("ERROR: board not connected for flashing. Connect via USB and enable permission to connected port")
+
+ image = "%s/%s.bin" % (d.getVar('DEPLOY_DIR_IMAGE'), d.getVar('PN'))
+
+ command = [bossac_path, '-p', serial_port , '-R', '-e', '-w', '-v', '-b', image]
+ else:
+ bb.fatal("ERROR: Unsupported board %s" % board)
+
+ bb.note("command: %s" % command)
+ bb.plain("Attempting to flash board: %s" % board)
+
+ # Random failure are a possibility here, retry till there is a success for finite times
+ for _ in range(10, 0, -1):
+ try:
+ subprocess.check_call(command)
+ bb.plain("Bossac Flashing board: %s Success " % board)
+ break
+ except subprocess.CalledProcessError as e:
+ bb.warn("Failed to flash %s (error code: %s). Retrying after 1 second..." % (board, e.returncode))
+ time.sleep(1)
+}
+
+addtask do_flash_usb after do_deploy
+
+do_flash_usb[nostamp] = "1"
+do_flash_usb[vardepsexclude] = "BB_ORIGENV"
diff --git a/conf/machine/arduino-nano-33-ble.conf b/conf/machine/arduino-nano-33-ble.conf
index e45cfc2..18ba056 100644
--- a/conf/machine/arduino-nano-33-ble.conf
+++ b/conf/machine/arduino-nano-33-ble.conf
@@ -4,5 +4,6 @@
#@DESCRIPTION: Machine configuration for Arudino nano 33 ble and Arduino nano 33 ble sense

require conf/machine/include/nrf52.inc
+ZEPHYR_INHERIT_CLASSES += "zephyr-flash-bossac"
ARCH_arduino-nano-33-ble = "arm"

--
2.25.1


[meta-zephyr][PATCH 2/3] arduino-nano-33-ble.conf: Add Arduino Nano 33 BLE and BLE Sense support

Wojciech Zmuda
 

From: Nagesh Shamnur <nagesh.shamnur@...>

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
---
conf/machine/arduino-nano-33-ble.conf | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 conf/machine/arduino-nano-33-ble.conf

diff --git a/conf/machine/arduino-nano-33-ble.conf b/conf/machine/arduino-nano-33-ble.conf
new file mode 100644
index 0000000..e45cfc2
--- /dev/null
+++ b/conf/machine/arduino-nano-33-ble.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: arduino-nano-33-ble
+
+#@DESCRIPTION: Machine configuration for Arudino nano 33 ble and Arduino nano 33 ble sense
+
+require conf/machine/include/nrf52.inc
+ARCH_arduino-nano-33-ble = "arm"
+
--
2.25.1


[meta-zephyr][PATCH 1/3] zephyr-kernel: install .bin image if available

Wojciech Zmuda
 

From: Nagesh Shamnur <nagesh.shamnur@...>

Some boards (e.g. Arduino Nano 33 BLE) require image in bin format
for flashing with `-c flash_usb`. Provide that image along with ELF
image on do_deploy step.

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
Signed-off-by: Stefan Schmidt <stefan.schmidt@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-sample.inc | 4 ++++
2 files changed, 5 insertions(+)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 330fe59..46f19e2 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -12,6 +12,7 @@ ZEPHYR_GCC_VARIANT="yocto"
ZEPHYR_SYSROOT="${STAGING_DIR_TARGET}"

ZEPHYR_MAKE_OUTPUT = "zephyr.elf"
+ZEPHYR_MAKE_BIN_OUTPUT = "zephyr.bin"

EXTRA_OECMAKE = "\
-DZEPHYR_BASE=${S} \
diff --git a/recipes-kernel/zephyr-kernel/zephyr-sample.inc b/recipes-kernel/zephyr-kernel/zephyr-sample.inc
index f7621d1..7b49611 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-sample.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-sample.inc
@@ -9,5 +9,9 @@ do_install[noexec] = "1"

do_deploy () {
install -D ${B}/zephyr/${ZEPHYR_MAKE_OUTPUT} ${DEPLOYDIR}/${PN}.elf
+ if [ -f ${B}/zephyr/${ZEPHYR_MAKE_BIN_OUTPUT} ]
+ then
+ install -D ${B}/zephyr/${ZEPHYR_MAKE_BIN_OUTPUT} ${DEPLOYDIR}/${PN}.bin
+ fi
}
addtask deploy after do_compile
--
2.25.1


[meta-zephyr][PATCH 0/3] Add Arduino Nano 33 BLE and BLE Sense support

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@...>

This patch set adds support for nRF52-based Arduino boards - Nano 33 BLE and BLE Sense - to
both build and flash Zephyr applications.

The board support itself is a trivial MACHINE config. Flashing is done with a new bbclass, that
is a wrapper around `bossac` flashing tool. One general kernel recipe fix was necessary to produce
and copy over the .bin file, as the flasher requires input in that format. This does not affect
scenarios where .elf file is required.

Tested on an actual Arduino Nano 33 BLE dev board.

Nagesh Shamnur (3):
zephyr-kernel: install .bin image if available
arduino-nano-33-ble.conf: Add Arduino Nano 33 BLE and BLE Sense
support
zephyr-flash-bossac.bbclass: Enable board flashing via bossac

classes/zephyr-flash-bossac.bbclass | 50 +++++++++++++++++++
conf/machine/arduino-nano-33-ble.conf | 9 ++++
.../zephyr-kernel/zephyr-kernel-common.inc | 1 +
.../zephyr-kernel/zephyr-sample.inc | 4 ++
4 files changed, 64 insertions(+)
create mode 100644 classes/zephyr-flash-bossac.bbclass
create mode 100644 conf/machine/arduino-nano-33-ble.conf

--
2.25.1


[meta-zephyr][PATCH 1/1] zephyr-kernel-test: fix Cortex-M tests failure with 2.6.0 kernel

Wojciech Zmuda
 

From: Nagesh shamnur <nagesh.shamnur@...>

Edit the test recipe removing obj_tracing tests that have
been removed from Zephyr 2.6.0 release.

Signed-off-by: Nagesh Shamnur <nagesh.shamnur@...>
Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc | 1 -
1 file changed, 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
index b6b4766..78747f9 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc
@@ -36,7 +36,6 @@ ZEPHYRTESTS = " \
mp \
msgq \
mutex \
- obj_tracing \
pending \
pipe \
poll \
--
2.25.1


[meta-zephyr][PATCH 0/1] Partially fix tests failure with 2.6.0 kernel

Wojciech Zmuda
 

From: Wojciech Zmuda <wojciech.zmuda@...>

Transition to Zephyr 2.6.0 broke meta-zephyr test suite. This patch fixes
QEMU Cortex-M3 test suite (MACHINE=qemu-cortex-m3 bitbake zephyr-kernel-test-all -c testimage).

The reason of failure is that the `obj_tracing` test suite has been removed from
Zephyr sources, but it still is referenced in zephyr-kernel-test.inc.

Unfortunately, there are other problems in this area not solved in this path. We'd
like to take the opportunity to report it anyway. The QEMU x86 test suite build
fails because of unimplemented instructions:

| /build/work/i586-yocto-elf/interrupt/2.6.0+gitAUTOINC+79a6c07536_c3bd2094f9-r0/git/tests/kernel/interrupt/src/direct_isr.c: In function 'direct_isr1':
| /build/work/i586-yocto-elf/interrupt/2.6.0+gitAUTOINC+79a6c07536_c3bd2094f9-r0/git/tests/kernel/interrupt/src/direct_isr.c:47:1: sorry, unimplemented: 80387 instructions aren't allowed in an interrupt service routine
| 47 | ISR_DIRECT_DECLARE(direct_isr1)
| | ^~~~~~~~~~~~~~~~~~
| /build/work/i586-yocto-elf/interrupt/2.6.0+gitAUTOINC+79a6c07536_c3bd2094f9-r0/git/tests/kernel/interrupt/src/direct_isr.c: In function 'direct_isr2':
| /build/work/i586-yocto-elf/interrupt/2.6.0+gitAUTOINC+79a6c07536_c3bd2094f9-r0/git/tests/kernel/interrupt/src/direct_isr.c:54:1: sorry, unimplemented: 80387 instructions aren't allowed in an interrupt service routine
| 54 | ISR_DIRECT_DECLARE(direct_isr2)
| | ^~~~~~~~~~~~~~~~~~

The problem above does not occur in case of Cortex-M3 QEMU tests - `interrupt` builds and passes
just fine. We have not investigated this one further.

Nagesh shamnur (1):
zephyr-kernel-test: fix Cortex-M tests failure with 2.6.0 kernel

recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc | 1 -
1 file changed, 1 deletion(-)

--
2.25.1


[meta-zephyr][PATCH] zephyr-blinky: add sample app recipe

Wojciech Zmuda
 

From: Davide Ricci <davide.ricci@...>

Blinky is the most referenced sample in Zephyr's documentation and
recall Arduino's first sketch example. This .bb file allows to build
such example.

Signed-off-by: Davide Ricci <davide.ricci@...>
---
recipes-kernel/zephyr-kernel/zephyr-blinky.bb | 3 +++
1 file changed, 3 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-blinky.bb

diff --git a/recipes-kernel/zephyr-kernel/zephyr-blinky.bb b/recipes-kernel/zephyr-kernel/zephyr-blinky.bb
new file mode 100644
index 0000000..bd5ce4f
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-blinky.bb
@@ -0,0 +1,3 @@
+include zephyr-sample.inc
+
+ZEPHYR_SRC_DIR = "${S}/samples/basic/blinky"
--
2.25.1


Re: [meta-zephyr][PATCH v2 1/2] zephyr-kernel: Add OpenThread add module to build

Naveen Saini
 

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Stefan Schmidt
Sent: Thursday, June 10, 2021 4:28 PM
To: yocto@...
Cc: Stefan Schmidt <stefan@...>; Stefan Schmidt
<stefan.schmidt@...>
Subject: [yocto] [meta-zephyr][PATCH v2 1/2] zephyr-kernel: Add
OpenThread add module to build

From: Stefan Schmidt <stefan.schmidt@...>

OpenThread support in Zephyr is realised as an external module. Make sure
we pull it in and have it available for applications to use it.

Signed-off-by: Stefan Schmidt <stefan.schmidt@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 1 +
recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.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 330fe59..35c4106 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -29,6 +29,7 @@ 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_openamp = "\;${S}/modules/lib/open-
amp\;${S}/modules/hal/libmetal"
+ZEPHYR_MODULES_append_openthread =
"\;${S}/modules/lib/openthread"
This is not required. It already listed in required sample recipe. Please remove it.


EXTRA_OECMAKE_append = " -DZEPHYR_MODULES=${ZEPHYR_MODULES}"

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
index 8475b5b..4910db2 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc
@@ -4,6 +4,7 @@ SRCREV_cmsis =
"c3bd2094f92d574377f7af2aec147ae181aa5f8e"
SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
+SRCREV_openthread = "385e19da1ae15f27872c2543b97276a42f102ead"
SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-
kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5e43583..4937a77 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -15,6 +15,7 @@ SRC_URI = "\
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;destsuffix=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/openthread.git;protocol=https;bran
+ ch=zephyr;destsuffix=git/modules/lib/openthread;name=openthread \
git://github.com/zephyrproject-

It would cause build failure with v2.5.0. So add SRCREV_openthread in zephyr-kernel-src-2.5.0.inc too.


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 \
file://0001-cmake-add-yocto-toolchain.patch \
--
2.31.1


Re: [External] [yocto] Bitbake failure

Randy MacLeod
 

On 2021-06-10 6:33 a.m., Cris Scott wrote:

It is still a problem and I have tried everything you suggested.  I am building with Ubuntu 20.4 and that seems to be the issue.

Lots of people use 20.04 so it seems odd that you'd have a problem specific to that host.


 

I have moved on from this, so will no longer require any information.  The problem has been turned over to someone new.


Okay, please encourage them to reply on this thread.

We may not always respond right away but there is usually
someone reading things and in my case, I'll respond eventually.

Thanks,

../Randy


 

From: Randy MacLeod <randy.macleod@...>
Sent: Tuesday, June 8, 2021 8:27 PM
To: Cris Scott <cscott@...>; yocto@...
Subject: Re: [External] [yocto] Bitbake failure

 

On 2021-05-31 6:12 p.m., Cris Scott wrote:

Not sure who to ask about this.

Using https://push.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-extended/lighttpd/lighttpd_1.4.59.bb to build lighttpd, bitbake fails, and I receive tons of messages that look like:

 

ERROR: lighttpd-1.4.59-r0 do_package_qa: QA Issue: /usr/lib/mod_staticfile.so contained in package lighttpd-module-staticfile requires libc.so.6(GLIBC_2.4), but no providers found in RDEPENDS_lighttpd-module-staticfile? [file-rdeps]

 

 

Can someone point me in the right direction to resolve this?

Hi Cris,

It's been a while is this still a problem for you?
If not, how did you fix it?

 

Can you reproduce the error with poky? git://git.yoctoproject.org/poky

What release/commit are you using?

Does it happen when you just run: bitbake lighttpd ?

Does it happen if you mv your sstate-cache (tmp*) directories aside
and do a rebuild?

What's in your local.conf?

For completeness, what is your build host distro (I doubt it matters here.).

 

I built poky from:
7f3c996d30 (HEAD -> master, origin/master, origin/HEAD) lttng-tools: upgrade 2.12.3 -> 2.12.4

on an Ubu-18.04.3 builder, and both:
$ bitbake lighttpd and
$ bitbake core-image-minimal

worked fine with:

grep -v "^$" conf/local.conf  | grep -v "^#"
MACHINE ??= "qemux86-64"
DISTRO ?= "poky"
PACKAGE_CLASSES ?= "package_rpm"
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"
USER_CLASSES ?= "buildstats image-prelink"
PATCHRESOLVE = "noop"
BB_DISKMON_DIRS ??= "\
    STOPTASKS,${TMPDIR},1G,100K \
    STOPTASKS,${DL_DIR},1G,100K \
    STOPTASKS,${SSTATE_DIR},1G,100K \
    STOPTASKS,/tmp,100M,100K \
    ABORT,${TMPDIR},100M,1K \
    ABORT,${DL_DIR},100M,1K \
    ABORT,${SSTATE_DIR},100M,1K \
    ABORT,/tmp,10M,1K"
PACKAGECONFIG_append_pn-qemu-system-native = " sdl"
CONF_VERSION = "1"
IMAGE_INSTALL_append = "lighttpd"

../Randy

 

-Bill

 



 

          
 

 

-- 
# Randy MacLeod
# Wind River Linux

 


This email has been scanned for spam and viruses by Proofpoint Essentials. Click here to report this email as spam.


-- 
# Randy MacLeod
# Wind River Linux


Re: bitbake controlling memory use

Ferry Toth
 

Hi,

Op 10-06-2021 om 21:06 schreef Trevor Gamblin:


On 2021-06-10 5:22 a.m., Ferry Toth wrote:

**[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Trevor,

Gmane is really messing things up here, sorry about that. I need to create a new thread I'm afraid.

I'd like to your reworked patch.

But note, I reworked it too (but maybe wrongly). I builds like 90% of my image, but fails building cmake-native. Or more accurately it fails do_configure while trying to build a small test program.
Hi,

I've pushed the patch onto my fork of the poky repo at https://github.com/threexc/poky

Let me know how your testing turns out - I am still running tests as well, but it would be good to know how others' attempts turn out, and more changes could still end up being necessary.
Your patch didn't apply clean on Gatesgarth, but fix seemd trivial. With this it builds cmake-native fine, thanks!

You can find it here: https://github.com/htot/meta-intel-edison/commit/8abce2f6f752407c7b2831dabf37cc358ce55bc7

I will check if any other build errors occurs, and if not will try to time image build with and without the patch to compare performance and see if it worth the effort.

- Trevor


Ferry


Re: bitbake controlling memory use

Trevor Gamblin
 


On 2021-06-10 5:22 a.m., Ferry Toth wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

Hi Trevor,

Gmane is really messing things up here, sorry about that. I need to create a new thread I'm afraid.

I'd like to your reworked patch.

But note, I reworked it too (but maybe wrongly). I builds like 90% of my image, but fails building cmake-native. Or more accurately it fails do_configure while trying to build a small test program.

Hi,

I've pushed the patch onto my fork of the poky repo at https://github.com/threexc/poky

Let me know how your testing turns out - I am still running tests as well, but it would be good to know how others' attempts turn out, and more changes could still end up being necessary.

- Trevor


Ferry




Re: Building a different GCC version in SDK vs GCC used to build the rootfs/image

greghwang@...
 

I think this will be hard to support unless your applications are self contained and will bring its own runtime as well in that case you can build a SDK from newer releases which matches compiler you need and let them use it, if you want to mix and match then it will require a bit of extra work e.g. check if runtime from newer compiler will still work with older libs/binaries or find a way to package two versions seprately and ensure that existing packages on image can keep using older libs
So our application might be able to be self contained and bring in all of it's own libs and runtime that it needs.  If that case I wouldn't have to supply the sysroot that comes as part of the SDK; I'd just provide the compiled toolchain/compiler with the updated gcc 8.2, right?


Exporting custom kernel header file to SDK #kernel #sdk

Lukasz Domowy
 

Hello,
 
I wrote a kernel driver which exposes some header to userspace application. Application engineers use generated SDK, so I'd like to export that header file as part of SDK.
I added my header to <kernel>/include/uapi/linux/ and thought it would be enouogh - as during SDK generation it would be copied to SDK. 
 
I use Yocto 3.2.2 and custom recipe for kernel 5.10.
 
I generated SDK and installed it, but to my surprise:
- my header is missing at <SDK install path>/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/include/linux/
- <SDK install path>/sysroots/cortexa9hf-neon-poky-linux-gnueabi/usr/include/linux/version.h contains:
        #define LINUX_VERSION_CODE 329728
which means kernel version 5.8 (why not 5.10?)

It looks like SDK takes default Yocto gatesgarth kernel version (5.8) to SDK, not my kernel version. PREFERRED_PROVIDER_virtual/kernel is properly set and right kernel version is built (at tmp/deploy/images)
What am I doing wrong?

I would appreciate any hints. Thank you in advance.

Best regards,
Lukasz


Re: Building a different GCC version in SDK vs GCC used to build the rootfs/image

Khem Raj
 

On 6/10/21 7:57 AM, greghwang@... wrote:
The backstory is I'm supporting a legacy system built with the Jethro branch and gcc 5.x.  I'm wondering instead of upgrading the underlying yocto layers to a more recent branch like Thud which supports gcc 8.2, is there a way to leave the image built with gcc 5, but build a new cross compiler toolchain use gcc 8.2.  The application team I'm supporting really wants to use C++17 features, and is unable to with gcc 5.x as their crosscompiler.  I would try to put the 2.28 glibc and 8.2 gcc-runtime libraries on the image and rely on forward compatibility of the libs to ensure compatibility with gcc 5.  Otherwise, the image would still be using gcc-5 as the compiler for all the recipes.
I did some experiments on Thud poky and was able to get a different version of gcc in the toolchain by modifying PREFERRED_VERSION_gcc_corss-canadian-${TRANSLATED_TARGET_ARCH}, however I quickly ran into problem trying compile hello-world with g++.  It looked like the compiler was trying to find its header files in
sysroots/aarch64-oe-linux/usr/include/c++/<gcc version>
but now I have a mismatched gcc version from what is on the sysroot and the cross compiler can't find it's headers.
I'm wondering if forcing a different version of gcc in the SDK is even feasible, or maybe I should be looking at external toolchains or some other solution to support my application team's need for an upgraded version of gcc.
I think this will be hard to support unless your applications are self contained and will bring its own runtime as well in that case you can build a SDK from newer releases which matches compiler you need and let them use it, if you want to mix and match then it will require a bit of extra work e.g. check if runtime from newer compiler will still work with older libs/binaries or find a way to package two versions seprately and ensure that existing packages on image can keep using older libs

So usually upgrading to relevant yocto release would be cleanest way to move forward and would be most reliable of all options but if thats not an option then
Perhaps upgrading compiler across the board might be better approach


Building a different GCC version in SDK vs GCC used to build the rootfs/image

greghwang@...
 

The backstory is I'm supporting a legacy system built with the Jethro branch and gcc 5.x.  I'm wondering instead of upgrading the underlying yocto layers to a more recent branch like Thud which supports gcc 8.2, is there a way to leave the image built with gcc 5, but build a new cross compiler toolchain use gcc 8.2.  The application team I'm supporting really wants to use C++17 features, and is unable to with gcc 5.x as their crosscompiler.  I would try to put the 2.28 glibc and 8.2 gcc-runtime libraries on the image and rely on forward compatibility of the libs to ensure compatibility with gcc 5.  Otherwise, the image would still be using gcc-5 as the compiler for all the recipes.

I did some experiments on Thud poky and was able to get a different version of gcc in the toolchain by modifying PREFERRED_VERSION_gcc_corss-canadian-${TRANSLATED_TARGET_ARCH}, however I quickly ran into problem trying compile hello-world with g++.  It looked like the compiler was trying to find its header files in

sysroots/aarch64-oe-linux/usr/include/c++/<gcc version>

but now I have a mismatched gcc version from what is on the sysroot and the cross compiler can't find it's headers.

I'm wondering if forcing a different version of gcc in the SDK is even feasible, or maybe I should be looking at external toolchains or some other solution to support my application team's need for an upgraded version of gcc.


How to create swap partition ?

Bel Hadj Salem Talel <bhstalel@...>
 

Hi All,

When I run : (bitbake -e | grep ^WKS_FILE=) I get: 
WKS_FILE="imx-imx-boot-bootpart.wks.in"

Here is the content:

part u-boot --source rawcopy --sourceparams="file=imx-boot" --ondisk mmcblk --no-table --align ${IMX_BOOT_SEEK}
part /boot --source bootimg-partition --ondisk mmcblk --fstype=vfat --label boot --active --align 8192 --size 64
part / --source rootfs --ondisk mmcblk --fstype=ext4 --label root --align 8192
 
bootloader --ptable msdos
What to add here in order to create a swap partition with size 2G.

Thanks for the help.
Talel


3601 - 3620 of 57408