Date   

Re: ERROR: could not relocate installing toolchain SDK

Randy MacLeod
 


Add Denis since he may have missed Sundeep's email.

On 2022-02-04 01:52, Sundeep KOKKONDA wrote:
Hello,

I am also facing the same issue with path size. Can you share the workaround what you are using for this issue?

In the scripts/relocate_sdk.py the file name comparison is like below:
if (len(new_dl_path) >= p_filesz):
                print("ERROR: could not relocate %s, interp size = %i and %i is needed." \
                    % (elf_file_name, p_memsz, len(new_dl_path) + 1))
                break
            dl_path = new_dl_path + b("\0") * (p_filesz - len(new_dl_path))
And, to fix the issue I made changes like below.
if (len(new_dl_path) >= 4096):
                print("ERROR: could not relocate %s, interp size = %i and %i is needed." \
                    % (elf_file_name, p_memsz, len(new_dl_path) + 1))
                break
            dl_path = new_dl_path + b("\0") * (4096 - len(new_dl_path))
and commented below code.
#if old_size != os.path.getsize(e):
        #print("New file size for %s is different. Looks like a relocation error!", e)
        #sys.exit(-1)
Do you have any clue regarding,
- Why the installation path is depending of elf headers i.e., Why installation error when the len(new_dl_path) is greater than p_filesz?
- Changing this comparison (len(new_dl_path) >= 4096) will impact the installed SDK?

The 4096 comes from PATH_MAX:

linux/limits.h.
#define PATH_MAX 4096 /* # chars in a path name including nul */

but that does seem a tad on the long side. I'd prefer a more reasonable
limit that we have actually tested, say PATH_MAX/4 (??) and a comment in the
commit log documenting the choice.

Finally, we do have a test that extracts the sdk in:

   meta/lib/oeqa/sdk/testsdk.py

Can you review that code and use a long but fixed length path by
default so that we catch regressions? The path is set in:
        sdk_dir = d.expand("${WORKDIR}/testimage-sdk/")
since len(${WORKDIR} may vary, I'd like to see code that corrects
for that and results in a fix length of PATH_MAX/4 assuming that
things work with such a long path.

Denis? Does that make sense and what is your work-around?

../Randy


 



-- 
# Randy MacLeod
# Wind River Linux


patching files under "dynamic-layers"

Monsees, Steven C (US)
 

 

I am building with zeus 3.0.4, Intel based…

 

I trying to learn how to introduce a patch to files brought in by packages under “dynamic –layers”… my bbappend appears not to be applying my test patch (even though no errors/warnings thrown)…

 

This is the package I am trying to manipulate:

 

/disk0/scratch/smonsees/yocto/workspace_3/meta-intel/dynamic-layers/clang-layer/recipes-opencl/igc

It contains:

files  intel-graphics-compiler_1.0.11.bb

 

This is my recipe to apply patch:

 

/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/meta-intel/dynamic-layers/clang-layer/recipes-opencl/igc

It contains:

files  intel-graphics-compiler_1.0.11.bbappend

 

files - contains the file I am attempting to patch (FILE_TO_PATCH.patch)

intel-graphics-compiler_1.0.11.bbappend is setup like so, where

 

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

 

SRC_URI += "\

    file://FILE_TO_PATCH.patch \

"

 

I attempted to male use of BBFILES_DYNAMIC but even though I get no error, patch is not applied.

 

conf/layer.conf:

BBFILES_DYNAMIC += " \

    clang-layer:$(LAYERDIR)/dynamic-layers/clang-layer/recipes-opencl/igc/*.bbappend \

"

 

Can you explain to me the proper way to patch files under these circumstances and where I went wrong ?

 

Thanks,

Steve

 


Re: gpsd autostart with systemd?

Matthias Klein
 

Hello Jose,

You need to add the systemd service, the socket service is already there.
SYSTEMD_SERVICE:${PN} += "${BPN}.service"
Thank you very much for your help!

Best regards,
Matthias


Re: gpsd autostart with systemd?

Jose Quaresma
 

Hi Matthias,

You need to add the systemd service, the socket service is already there.

SYSTEMD_SERVICE:${PN} += "${BPN}.service"

Matthias Klein <matthias.klein@...> escreveu no dia segunda, 7/02/2022 à(s) 08:19:

Hello,

what needs to be in a bbapped so that gpsd is started automatically at boot time, and not only when the first accesses the gpsd socket?

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-navigation/gpsd/gpsd_3.23.1.bb

Best regards,
Matthias






--
Best regards,

José Quaresma


gpsd autostart with systemd?

Matthias Klein
 

Hello,

what needs to be in a bbapped so that gpsd is started automatically at boot time, and not only when the first accesses the gpsd socket?

http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-navigation/gpsd/gpsd_3.23.1.bb

Best regards,
Matthias


Re: readonly rootfs - storing data in separate partition

tomzy
 

Hi

Not long ago we use it in couple of projects. Main repo can be found
here, https://github.com/cmhe/meta-readonly-rootfs-overlay

You can also find our fork with couple of changes (on of them is for example
adjustions for honister release.

--
Tomasz Żyjewski
Embedded Systems Engineer
GPG: 5C495EA3EBEECA59
https://3mdeb.com | @3mdeb_com


Re: readonly rootfs - storing data in separate partition

Marco Cavallini
 

rootfs-overlay  is the perfect solution for your case.

--
Marco Cavallini | KOAN sas
Bergamo - Italia
embedded software engineering
https://KoanSoftware.com


Re: readonly-rootfs-overlay

Matthias Klein
 

Hello Howard,

 

i use parts of it (without a writeable partition, just a tmpfs) in a separate layer: https://github.com/matthiasklein/meta-distro-coffee/blob/master/recipes-core/readonly-rootfs-overlay/readonly-rootfs-overlay_1.0.bb

Best regards,
Matthias

Von: yocto@... <yocto@...> Im Auftrag von Howard via lists.yoctoproject.org
Gesendet: Sonntag, 6. Februar 2022 22:14
An: yocto@...
Betreff: [yocto] readonly-rootfs-overlay

 

Hi:

I was wondering if anybody is using meta-readonly-rootfs-overlay?

Thanks
Howard


Re: readonly rootfs - storing data in separate partition

Howard
 

Hi:

I was wondering if anybody is using meta-readonly-rootfs-overlay?

Thanks
Howard


Re: Resistive touchscreen calibration for libinput

Steve Sakoman
 

On Sat, Feb 5, 2022 at 4:05 AM Electronic Consult
<electronicconsult1@...> wrote:

Hello all,

Apologies if this is the incorrect group to post to, I haven't posted previously.

I'm working with an Atmel/ Microchip SAMA5D4 Xplained board & a resistive touchscreen. I'm using a GUI framework that has issues dealing with evdev & tslib so looks like I need to find a screen calibration method for libinput, which the GUI framework favours.
Since you are using tslib, the ts_calibrate utility would be the
obvious choice. Include the tslib_calibrate package in your image. You
might also find the tslib_tests package useful.

Steve


Can anyone please suggest a solution for this? I've taken a look at a recipe for xinput-calibrator & it seems like a possible solution. However my build isn't running a desktop GUI so not sure if this is a proper fit.

I'd appreciate if anyone could point me in the right direction.

Many thanks,

Owen



[meta-selinux][PATCH] prelink: drop bbappend

Tim Orling
 

prelink has been dropped from oe-core [1], so the bbappend can no longer be
applied.

[1] https://git.openembedded.org/openembedded-core/commit/?id=23c0be78106f1d1e2bb9c724174a1bb8c56c2469

Signed-off-by: Tim Orling <tim.orling@...>
---
recipes-devtools/prelink/prelink_git.bbappend | 1 -
1 file changed, 1 deletion(-)
delete mode 100644 recipes-devtools/prelink/prelink_git.bbappend

diff --git a/recipes-devtools/prelink/prelink_git.bbappend b/recipes-devtools/prelink/prelink_git.bbappend
deleted file mode 100644
index 74e22b3..0000000
--- a/recipes-devtools/prelink/prelink_git.bbappend
+++ /dev/null
@@ -1 +0,0 @@
-inherit ${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'enable-selinux', '', d)}
--
2.25.1


Resistive touchscreen calibration for libinput

Electronic Consult <electronicconsult1@...>
 

Hello all,

Apologies if this is the incorrect group to post to, I haven't posted previously.

I'm working with an Atmel/ Microchip SAMA5D4 Xplained board & a resistive touchscreen. I'm using a GUI framework that has issues dealing with evdev & tslib so looks like I need to find a screen calibration method for libinput, which the GUI framework favours.

Can anyone please suggest a solution for this? I've taken a look at a recipe for xinput-calibrator & it seems like a possible solution. However my build isn't running a desktop GUI so not sure if this is a proper fit.

I'd appreciate if anyone could point me in the right direction.

Many thanks,

Owen


Re: ERROR: could not relocate installing toolchain SDK

Sundeep KOKKONDA
 

Hello,

I am also facing the same issue with path size. Can you share the workaround what you are using for this issue?

In the scripts/relocate_sdk.py the file name comparison is like below:
if (len(new_dl_path) >= p_filesz):
                print("ERROR: could not relocate %s, interp size = %i and %i is needed." \
                    % (elf_file_name, p_memsz, len(new_dl_path) + 1))
                break
            dl_path = new_dl_path + b("\0") * (p_filesz - len(new_dl_path))
And, to fix the issue I made changes like below.
if (len(new_dl_path) >= 4096):
                print("ERROR: could not relocate %s, interp size = %i and %i is needed." \
                    % (elf_file_name, p_memsz, len(new_dl_path) + 1))
                break
            dl_path = new_dl_path + b("\0") * (4096 - len(new_dl_path))
and commented below code.
#if old_size != os.path.getsize(e):
        #print("New file size for %s is different. Looks like a relocation error!", e)
        #sys.exit(-1)
Do you have any clue regarding,
- Why the installation path is depending of elf headers i.e., Why installation error when the len(new_dl_path) is greater than p_filesz?
- Changing this comparison (len(new_dl_path) >= 4096) will impact the installed SDK?
 


Re: is there a viable YP-friendly risc-v dev kit?

Robert P. J. Day
 

Quoting Leon Woestenberg <leon@...>:

Hello Robert, Alexander,

On Fri, 4 Feb 2022 at 23:04, Robert P. J. Day <rpjday@...> wrote:


Quoting Alexander Kanavin <alex.kanavin@...>:

I think the best option at this point is qemu. Why does the 'friend' need
physical hardware? :)
he's a hacker and just likes the feel of circuit boards, but
qemu does look like the only feasible option at the moment.
No. There is a sweet middle ground called FPGAs. You buy a board, with an
IC on it, that is expensive as hell, empty like air, but fully
re-configurable with almost any RISC-V SoC you can think of.

For example the Rocket 64 bit RISC-V.
hmmm ... not even that expensive a board:

https://www.luffca.com/2021/09/linux-litex-rocket-arty/
https://www.xilinx.com/products/boards-and-kits/1-elhaap.html

rday


Re: is there a viable YP-friendly risc-v dev kit?

Leon Woestenberg
 

Hello Robert, Alexander,

On Fri, 4 Feb 2022 at 23:04, Robert P. J. Day <rpjday@...> wrote:

Quoting Alexander Kanavin <alex.kanavin@...>:

> I think the best option at this point is qemu. Why does the 'friend' need
> physical hardware? :)

   he's a hacker and just likes the feel of circuit boards, but
qemu does look like the only feasible option at the moment.

No. There is a sweet middle ground called FPGAs. You buy a board, with an IC on it, that is expensive as hell, empty like air, but fully re-configurable with almost any RISC-V SoC you can think of.

For example the Rocket 64 bit RISC-V.

Regards, Leon

rday




--
-- 
Leon Woestenberg
leon@...
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com


Re: is there a viable YP-friendly risc-v dev kit?

Robert P. J. Day
 

Quoting Alexander Kanavin <alex.kanavin@...>:

I think the best option at this point is qemu. Why does the 'friend' need
physical hardware? :)
he's a hacker and just likes the feel of circuit boards, but
qemu does look like the only feasible option at the moment.

rday


Re: is there a viable YP-friendly risc-v dev kit?

Alexander Kanavin
 

I think the best option at this point is qemu. Why does the 'friend' need physical hardware? :)

Alex


On Fri, 4 Feb 2022 at 22:48, Robert P. J. Day <rpjday@...> wrote:
friend asked me about the options for a risc-v dev kit that worked
with YP, and i'm aware of the meta-riscv layer, but wherever i looked,
it seems like risc-v dev kits have a very short life span, being either
put on hold or outright cancelled (beaglev, hifive unmatched, etc.)

are there, in fact, any reasonable risc-v dev boards out there?

rday





is there a viable YP-friendly risc-v dev kit?

Robert P. J. Day
 

friend asked me about the options for a risc-v dev kit that worked
with YP, and i'm aware of the meta-riscv layer, but wherever i looked,
it seems like risc-v dev kits have a very short life span, being either
put on hold or outright cancelled (beaglev, hifive unmatched, etc.)

are there, in fact, any reasonable risc-v dev boards out there?

rday


[meta-security][PATCH] suricata: update to 6.0.4

Armin Kuster
 

bump lexical-core to 0.6.8

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-ids/suricata/{libhtp_0.5.38.bb => libhtp_0.5.39.bb} | 2 +-
recipes-ids/suricata/{suricata_6.0.3.bb => suricata_6.0.4.bb} | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename recipes-ids/suricata/{libhtp_0.5.38.bb => libhtp_0.5.39.bb} (91%)
rename recipes-ids/suricata/{suricata_6.0.3.bb => suricata_6.0.4.bb} (98%)

diff --git a/recipes-ids/suricata/libhtp_0.5.38.bb b/recipes-ids/suricata/libhtp_0.5.39.bb
similarity index 91%
rename from recipes-ids/suricata/libhtp_0.5.38.bb
rename to recipes-ids/suricata/libhtp_0.5.39.bb
index 2a0c93c..80c9014 100644
--- a/recipes-ids/suricata/libhtp_0.5.38.bb
+++ b/recipes-ids/suricata/libhtp_0.5.39.bb
@@ -5,7 +5,7 @@ require suricata.inc
LIC_FILES_CHKSUM = "file://LICENSE;beginline=1;endline=2;md5=596ab7963a1a0e5198e5a1c4aa621843"

SRC_URI = "git://github.com/OISF/libhtp.git;protocol=https;branch=0.5.x"
-SRCREV = "fca44158911a1642880ea5c774151a33ad33d906"
+SRCREV = "6b70803c45894da7a591b2305498335e6df4f9a3"

DEPENDS = "zlib"

diff --git a/recipes-ids/suricata/suricata_6.0.3.bb b/recipes-ids/suricata/suricata_6.0.4.bb
similarity index 98%
rename from recipes-ids/suricata/suricata_6.0.3.bb
rename to recipes-ids/suricata/suricata_6.0.4.bb
index ca9e03e..31244f3 100644
--- a/recipes-ids/suricata/suricata_6.0.3.bb
+++ b/recipes-ids/suricata/suricata_6.0.4.bb
@@ -5,7 +5,7 @@ require suricata.inc
LIC_FILES_CHKSUM = "file://LICENSE;beginline=1;endline=2;md5=c70d8d3310941dcdfcd1e02800a1f548"

SRC_URI = "http://www.openinfosecfoundation.org/download/suricata-${PV}.tar.gz"
-SRC_URI[sha256sum] = "daf134bb2d7c980035e9ae60f7aaf313323a809340009f26e48110ccde81f602"
+SRC_URI[sha256sum] = "a8f197e33d1678689ebbf7bc1abe84934c465d22c504c47c2c7e9b74aa042d0d"

DEPENDS = "lz4 libhtp"

@@ -58,7 +58,7 @@ SRC_URI += " \
crate://crates.io/crc/1.8.1 \
crate://crates.io/rustc_version/0.2.3 \
crate://crates.io/phf/0.8.0 \
- crate://crates.io/lexical-core/0.6.7 \
+ crate://crates.io/lexical-core/0.6.8 \
crate://crates.io/time/0.1.44 \
crate://crates.io/quote/0.6.13 \
crate://crates.io/rand_core/0.5.1 \
--
2.25.1


Isafw.bbclass needs to sync up with

Darcy Watkins
 

Hi team,

 

I get this error…

 

ERROR: Task do_build in /home/dwatkins/workspace/mgos/apollo17/upstream/yocto/poky/meta/recipes-core/images/core-image-minimal.bb depends upon non-existent task do_populate_cve_db in /home/dwatkins/workspace/mgos/apollo17/upstream/yocto/poky/meta/recipes-core/meta/cve-update-db-native.bb

ERROR: Command execution failed: 1

 

This commit below is reference from ‘dunfell’ branch but I see the same issue in ‘master’ branch so I think it was back ported.

 

commit ee62d4540e6a2ad5d071209b7bef26b367719b42

Author: Ross Burton <ross@...>

Date:   Thu Sep 10 22:04:13 2020 +0100

 

    cve-update-db-native: use fetch task

    

    Instead of inventing a new task to fetch the CVE data, use the existing

    fetch task.

    

    (From OE-Core rev: 1ed53d5cfc2be40b2d57b5392ec4d30313209934)

    

    Signed-off-by: Ross Burton <ross.burton@...>

    Signed-off-by: Richard Purdie <richard.purdie@...>

    (cherry picked from commit f5f97d33a1703d75b9fd9760f2c7767081538e00)

    Signed-off-by: Steve Sakoman <steve@...>

    Signed-off-by: Richard Purdie <richard.purdie@...>

 

Below is from isafw.bbclass (approx. line #108 in ‘dunfell’) in meta-security

 

do_build[depends] += "cve-update-db-native:do_populate_cve_db ca-certificates-native:do_populate_sysroot"

 

I think it needs to be …

 

do_build[depends] += "cve-update-db-native:do_fetch ca-certificates-native:do_populate_sysroot"

 

I think this is as widespread in terms of backported branches, etc. as the original change went.  I am guessing that this doesn’t impact users that are NOT using the meta-security layer.

 

I have to admit I was a bit surprised by this, but on the other hand, it’s nice went I can suggest the fix rather than just belly ache over the issue.  😉

 

 

 

Regards,

 

Darcy

 

Darcy Watkins ::  Senior Staff Engineer, Firmware

 

SIERRA WIRELESS

Direct  +1 604 233 7989   ::  Fax  +1 604 231 1109  ::  Main  +1 604 231 1100

13811 Wireless Way  :: Richmond, BC Canada V6V 3A4

[M4]

dwatkins@... :: www.sierrawireless.com

1741 - 1760 of 57790