Date   

Re: Honister broken WiFi communication

Rudolf J Streif
 

Hi JH,

On Tue, Jan 18, 2022, 01:54 JH <jupiter.hce@...> wrote:
Hi,

Has anyone successfully built a Linux image by Honister to run WiFi
driver, connman and wpa_supplicant for WiFi interface?

Yes, I have, but with Network Manager instead of connman. WiFi works just fine.

I could build an image by Zeus to run WiFi driver, wpa_supplicant,
connman and dbus well, but after upgrading to Honister, the Linux
image building was fie, but the WiFi is now broken, the WiFi failed to
respond DHCP the WiFi could not connect to Internet, something is
broken between wpa_supplicant and connman which setting kernel WiFi
driver, WiFi interface and connection. I don't see any issues in
kernel WiFi driver, connman and wpa_supplicant, something missing in
the Linux image failing to set up the WiF network interface.

There are a lot of pieces in the chain and it is not obvious from your description where it is broken.

If you run ifconfig -a does your WiFi interface show up? If not there is an issue with the driver. Use dmesg and filter for the driver. Often a driver cannot load the firmware. What is your WiFi hardware?

Did you install the regulatory database?

What error messages are you seeing when attempting to connect to a WiFi network? Did you look at the connman logs?




Appreciate your comments.

Thank you.

Kind regards,

- jupiter




Re: gdb with a broken sdk

dacav
 

On Wed, Jan 12, 2022 at 02:15:38AM +0000, dacav wrote:
How can I include aarch64-foobar-gdb in the devshell's PATH?
Follow up on this thread: I've been kindly helped by kroon on #yocto.
The trick consists in adding a build-time dependency to gdb-cross-aarch64
in my recipe:

DEPEND = "gdb-cross-aarch64"

At this point I can just use `bitbake -c devshell $myrecipe` and the
debugger is available.

Bonus: the devshell turns out to be very useful as a replacement
for the SDK: the environment allows me to do the cross-compilation
with just a `make`, while earlier I needed to run `bitbake $myrecipe`
and wait several seconds.


- dacav


Re: Advertise lore.kernel.org archives on website?

Richard Purdie
 

On Tue, 2022-01-18 at 10:44 +0100, Michael Opdenacker wrote:
Greetings,

I see more and more people using links to the lore.kernel.org archives,
for example the ones for this list: https://lore.kernel.org/yocto/

These look more convenient to use than the ones on
https://lists.yoctoproject.org/.

So what about advertising such archives on
https://www.yoctoproject.org/community/mailing-lists/, at least for the
ones which have archives on lore.kernel.org? I was thinking about just
adding an "(archives)" or "(archives / public mailbox) link at the end
of the description for each list.

What do you think?
Sounds fine to me.

Cheers,

Richard


Honister broken WiFi communication

JH
 

Hi,

Has anyone successfully built a Linux image by Honister to run WiFi
driver, connman and wpa_supplicant for WiFi interface?

I could build an image by Zeus to run WiFi driver, wpa_supplicant,
connman and dbus well, but after upgrading to Honister, the Linux
image building was fie, but the WiFi is now broken, the WiFi failed to
respond DHCP the WiFi could not connect to Internet, something is
broken between wpa_supplicant and connman which setting kernel WiFi
driver, WiFi interface and connection. I don't see any issues in
kernel WiFi driver, connman and wpa_supplicant, something missing in
the Linux image failing to set up the WiF network interface.

Appreciate your comments.

Thank you.

Kind regards,

- jupiter


Advertise lore.kernel.org archives on website?

Michael Opdenacker
 

Greetings,

I see more and more people using links to the lore.kernel.org archives,
for example the ones for this list: https://lore.kernel.org/yocto/

These look more convenient to use than the ones on
https://lists.yoctoproject.org/.

So what about advertising such archives on
https://www.yoctoproject.org/community/mailing-lists/, at least for the
ones which have archives on lore.kernel.org? I was thinking about just
adding an "(archives)" or "(archives / public mailbox) link at the end
of the description for each list.

What do you think?
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Installing only python .pyc files onto the image #yocto

Sam
 

Was wondering if there was a way to edit the distitils3.bbclass or a similar file to only install the python .pyc files onto a yocto image?

I saw something about editing the distutils-common-base.bbclass online, however, it was only mentioned and not elaborated on.

I am currently working with a setup that installs .py files, then generates the .pyc files and removes the .py files. I am now looking for a method that will only install the .pyc files.

Any help would be appreciated.


Enhancements/Bugs closed WW03!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

3

michael.opdenacker@...

1

tim.orling@...

1

richard.purdie@...

1

alexandre.belloni@...

1

Grand Total

7

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Current high bug count owners for Yocto Project 3.5

Stephen Jolley
 

All,

Below is the list as of top 44 bug owners as of the end of WW03 of who have open medium or higher bugs and enhancements against YP 3.5.   There are 71 possible work days left until the final release candidates for YP 3.5 needs to be released.

Who

Count

ross@...

37

michael.opdenacker@...

36

randy.macleod@...

23

david.reyna@...

22

bruce.ashfield@...

16

tim.orling@...

14

trevor.gamblin@...

12

sakib.sajal@...

12

richard.purdie@...

9

kai.kang@...

7

mhalstead@...

7

bluelightning@...

6

saul.wold@...

6

JPEWhacker@...

5

hongxu.jia@...

4

chee.yang.lee@...

4

kiran.surendran@...

3

Qi.Chen@...

3

jon.mason@...

3

alexandre.belloni@...

2

raj.khem@...

2

pgowda.cve@...

2

pokylinux@...

2

mshah@...

2

alejandro@...

2

open.source@...

1

yf3yu@...

1

akuster808@...

1

yi.zhao@...

1

jay.shen.teoh@...

1

limon.anibal@...

1

jonathan.richardson@...

1

aehs29@...

1

kexin.hao@...

1

matthewzmd@...

1

thomas.perrot@...

1

mark.hatle@...

1

Martin.Jansa@...

1

mingli.yu@...

1

TicoTimo@...

1

shachar@...

1

nicolas.dechesne@...

1

john.kaldas.enpj@...

1

mostthingsweb@...

1

Grand Total

260

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 401 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now,  “3.5, “3.6”, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


Re: Building uImage with appended DTB

Ryan Govostes
 

A solution that seems to work is to create a new .bbclass inherited from my layer's linux .bbappend file that implements uboot_prep_kimage:append() to append the DTB to linux.bin. This code would run at the beginning of do_uboot_mkimage() before the uImage is created.

There are a couple of prerequisites such as setting KEEPUIMAGE = "yes" and KERNEL_DEVICETREE_BUNDLE = "0".

https://gist.github.com/rgov/0628785685ab858a99c5bfca626c1d8f

I would still be curious to know why KERNEL_DEVICETREE_BUNDLE doesn't work as expected if that is supposed to be the supported method of achieving this, but my solution at least lets me move on.


[psplash][PATCH] psplash: Fix double buffering initialization

Horn, Michal
 

Some fb drivers do not implement double buffering completely or correctly.
For example mxsfb driver does not set yres_virtual to double on
initialization, nor it allows its doubling by FBIOPUT_VSCREENINFO ioctl
call. In such case, the double buffering gets enabled, but psplash fails
to display every second frame with error 'psplash_fb_flip: FBIOPAN_DISPLAY failed: Invalid argument'.
 
Panning the display by FBIOPAN_DISPLAY ioctl is always checking carefully
that the resolution, virtual buffer resolutin and offsets are in
bounds at fb_pan_display - https://elixir.bootlin.com/linux/v4.9.275/source/drivers/video/fbdev/core/fbmem.c#L891.
 
Swapping the front and back buffers is done by switching the
yoffset between 0 and yres values. For double buffering, the whole buffer
must have yres_virtual buffer size double of yres.
 
But in case of the mxsfb driver, the yres_virtual is always equal to yres,
so drawing with the offset set to yres would overrun the buffer. So the
panning is stopped and error 'Invalid argument' is returned.
 
Psplash tries to double the yres_virtual on initialization by FBIOPUT_VSCREENINFO ioctl call,
that at some point calls the mxsfb_check_var - https://elixir.bootlin.com/linux/v4.9.275/source/drivers/video/fbdev/mxsfb.c#L269
function, which for some reason always sets the yres_virtual back to yres,
effectively canceling the doubling. But no error is returned in this case,
so it gets silently ignored.

So in general, checking for the ioctl call success is not enough as some
drivers may pass this test, but fail double buffering anyway.
So now we double check the yres_virtual on fb_new and disable double
buffering in case of doubling yres_virtual fails.
 
Signed-off-by: Michal Horn <michalhorn@...>
---
 psplash-fb.c | 14 ++++++++++++--
 1 file changed, 12 insertions(+), 2 deletions(-)
 
diff --git a/psplash-fb.c b/psplash-fb.c
index 2babb5f..1b73807 100644
--- a/psplash-fb.c
+++ b/psplash-fb.c
@@ -213,8 +213,18 @@ psplash_fb_new (int angle, int fbdev_id)
           perror(" Error getting the fixed framebuffer info");
           goto fail;
         } else {
-          DBG("Virtual resolution set to double");
-          fb->double_buffering = 1;
+          if (ioctl(fb->fd, FBIOPAN_DISPLAY, &fb_var) == -1) {
+            fprintf(stderr, "warning: FBIOPAN_DISPLAY failed, "
+                    "double buffering disabled\n");
+          } else {
+            if (fb_var.yres_virtual == fb_var.yres * 2) {
+              DBG("Virtual resolution set to double");
+              fb->double_buffering = 1;
+            } else {
+              fprintf(stderr, "warning: Doubling virtual "
+                      "resolution failed, double buffering disabled\n");
+            }
+          }
         }
       }
     }
-- 
2.25.1
 


Re: perf compilation fails

Cardenas Jose Antonio (JCARDENA)
 

Yes, that worked! Thank you very much!

-----Mensaje original-----
De: Khem Raj <raj.khem@...>
Enviado el: viernes, 14 de enero de 2022 20:54
Para: Michael Opdenacker <michael.opdenacker@...>
CC: Cardenas Jose Antonio (JCARDENA) <JoseAntonio.Cardenas@...>; yocto@...
Asunto: Re: [yocto] perf compilation fails

CAUTION: This email originated from outside the organization. Do not click on links or open attachments unless you recognize the sender and know the content is safe.

take a look at following link, it will help solve this hopefully

https://wiki.gentoo.org/wiki/Project:Toolchain/Binutils_2.34_porting_notes/undefined_reference_to_bfd_get_section_*

On Fri, Jan 14, 2022 at 2:02 AM Michael Opdenacker <michael.opdenacker@...> wrote:

Hi Jose Antonio

On 1/13/22 3:29 PM, Cardenas Jose Antonio (JCARDENA) wrote:

Hi guys



I’m no table to build correctly perf package.



It looks like some sources have no been compiled because I’m getting
an “undefined reference to” error.



This problem has appeared since we have upgraded the version of
yocto zeus.



I’m getting this error



arm-poky-linux-gnueabi-ld
--sysroot=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-
gnueabi/perf/1.0-r9/recipe-sysroot
-r -o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-bench.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-annotate.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-config.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-diff.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-evlist.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-ftrace.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-help.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-sched.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-buildid-list.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-buildid-cache.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-kallsyms.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-list.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-record.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-report.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-stat.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-timechart.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-top.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-script.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-kmem.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-lock.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-kvm.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-inject.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-mem.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-data.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-version.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-c2c.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/builtin-probe.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/bench/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/tests/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/perf.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/util/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/arch/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/ui/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/scripts/perf-in.o

arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon
-mfloat-abi=hard -fstack-protector-strong -D_FORTIFY_SOURCE=2
-Wformat -Wformat-security -Werror=format-security -Os -pipe -g
-feliminate-unused-debug-types
-fmacro-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-po
ky-linux-gnueabi/perf/1.0-r9=/usr/src/debug/perf/1.0-r9
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-po
ky-linux-gnueabi/perf/1.0-r9=/usr/src/debug/perf/1.0-r9
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-po
ky-linux-gnueabi/perf/1.0-r9/recipe-sysroot=
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-po
ky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native=
--sysroot=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-
gnueabi/perf/1.0-r9/recipe-sysroot
-ldw -Wbad-function-cast -Wdeclaration-after-statement
-Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-system-headers
-Wold-style-definition -Wpacked -Wredundant-decls
-Wstrict-prototypes -Wswitch-default -Wswitch-enum -Wundef
-Wwrite-strings -Wformat
-Wstrict-aliasing=3 -Wshadow -DHAVE_PERF_REGS_SUPPORT -O6
-fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall -Wextra
-std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/perf/util/include
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/include/uapi
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/include/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/arch/arm/include/uapi
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/arch/arm/include/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/arch/arm/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0//util
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/perf/util
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/perf
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/tools/lib/ -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT
-DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER
-DHAVE_EVENTFD -DHAVE_GET_CURRENT_DIR_NAME -DHAVE_GETTID
-DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT
-DHAVE_AIO_SUPPORT -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT
-DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_MMAP_SUPPORT
-DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_GELF_GETNOTE_SUPPORT
-DHAVE_ELF_GETSHDRSTRNDX_SUPPORT -DHAVE_LIBBPF_SUPPORT
-DHAVE_JITDUMP -DHAVE_DWARF_UNWIND_SUPPORT -DHAVE_LIBUNWIND_SUPPORT
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/recipe-sysroot/usr/include
-DHAVE_LIBCRYPTO_SUPPORT -DHAVE_SLANG_SUPPORT -DNO_LIBPERL
-DHAVE_TIMERFD_SUPPORT -DNO_LIBPYTHON -DHAVE_CPLUS_DEMANGLE_SUPPORT
-DHAVE_LIBBFD_SUPPORT -DHAVE_ZLIB_SUPPORT -DHAVE_LZMA_SUPPORT
-DHAVE_BACKTRACE_SUPPORT -DDISASM_FOUR_ARGS_SIGNATURE
-DHAVE_AUXTRACE_SUPPORT
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/perf-1.0/ -ldl -lutil -Wl,-z,noexecstack -lunwind
-lunwind-arm
-L/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/
perf/1.0-r9/recipe-sysroot/usr/lib
-Xlinker
--dynamic-list=/home/bob/develop/yocto/build/tmp/work/emperor-poky-l
inux-gnueabi/perf/1.0-r9/perf-1.0/libtraceevent-dynamic-list
\


/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/pmu-events/pmu-events-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/libperf-in.o
-Wl,--whole-archive
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/libapi.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/libtraceevent.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/libsubcmd.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/libbpf.a -Wl,--no-whole-archive -Wl,--start-group
-lpthread -lrt -lm -ldl -lelf -lunwind -lunwind-arm -lcrypto -lslang
-lbfd -lopcodes -liberty -lz -llzma -Wl,--end-group -o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/perf

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o:
in function `find_address_in_section':

/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:200:
undefined reference to `bfd_get_section_flags'

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:204:
undefined reference to `bfd_get_section_vma'

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:205:
undefined reference to `bfd_get_section_size'

collect2: error: ld returned 1 exit status

make[2]: *** [Makefile.perf:608:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/perf-1.0/perf]
Error 1

make[1]: *** [Makefile.perf:219: sub-make] Error 2

make: *** [Makefile:70: all] Error 2

make: Leaving directory
'/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf'

ERROR: oe_runmake failed

WARNING:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/pe
rf/1.0-r9/temp/run.do_compile.146045:1
exit 1 from 'exit 1'

ERROR: Execution of
'/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/temp/run.do_compile.146045'
failed with exit code 1
Weird, this doesn't happen building core-image-minimal *for x86_64* on
the latest Poky, with gcc 11.2.
This may not help much, but at least you could compare.
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com




Fetching svn projects with space in URI

dushara.jayasinghe@...
 

Hello,

 

I’m trying to create a recipe for one of our existing code bases which is under svn.

 

The URI of this project contains space characters and I’m struggling to properly set the SRC_URI field in the recipe.

 

I did try replacing space with %20 as below:

 

SRC_URI = "svn://server.local.net/project/My%20Application;module=trunk;rev=61238;user=uuuu;pswd=pppp;externals=allowed"

 

However, this results in the following error when I try to build the recipe:

 

WARNING: project-bin-0.1-r0 do_fetch: Failed to fetch URL svn://server.local.net/project/My%20Application;module=trunk;rev=61238;user=uuuu;pswd=pppp;externals=allowed, attempting MIRRORS if available

ERROR: project-bin-0.1-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1000/bus"; export SSH_AGENT_PID="867"; export SSH_AUTH_SOCK="/run/user/1000/keyring/ssh"; export PATH="/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/sysroots-uninative/x86_64-linux/usr/bin:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/layers/openembedded-core/scripts:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/project-bin/0.1-r0/recipe-sysroot-native/usr/bin/arm-ostl-linux-gnueabi:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/project-bin/0.1-r0/recipe-sysroot/usr/bin/crossscripts:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/project-bin/0.1-r0/recipe-sysroot-native/usr/sbin:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/project-bin/0.1-r0/recipe-sysroot-native/usr/bin:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/project-bin/0.1-r0/recipe-sysroot-native/sbin:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/project-bin/0.1-r0/recipe-sysroot-native/bin:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/layers/openembedded-core/bitbake/bin:/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/hosttools"; export HOME="/home/developer"; /usr/bin/env svn --non-interactive --trust-server-cert co --no-auth-cache --username uuuu --password pppp -r 61238 svn://server.local.net/project/My Application/trunk@61238 trunk failed with exit code 1, output:

svn: E160013: File not found: revision 61240, path '/project/My'

 

ERROR: project-bin-0.1-r0 do_fetch: Fetcher failure for URL: 'svn://server.local.net/project/My%20Application;module=trunk;rev=61238;user=uuuu;pswd=pppp;externals=allowed'. Unable to fetch URL from any source.

ERROR: Logfile of failure stored in: /home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/build-openstlinuxweston-stm32mp1/tmp-glibc/work/cortexa7t2hf-neon-vfpv4-ostl-linux-gnueabi/project-bin/0.1-r0/temp/log.do_fetch.247992

ERROR: Task (/home/developer/src/STM32MP15-Ecosystem-v3.1.0/Distribution-Package/openstlinux-5.10-dunfell-mp1-21-11-17/layers/meta-project/recipes-project/project-bin/project-bin_0.1.bb:do_fetch) failed with exit code '1'

 

How exactly should the space be handled?

 

Thank you.

 

Regards.

 

Dushara

 


Building uImage with appended DTB

Ryan Govostes
 

I'm a complete newcomer to Yocto, trying to translate a manual process of building software for an embedded device based on the PHYTEC phyCORE-LPC3250 SOM. I did not find an existing BSP layer for this board so I am trying to create my own.

When I build a kernel for this device manually, I use the CONFIG_APPENDED_DTB=y option, which instructs the kernel to find the device tree right after the kernel image itself. I build the zImage, then append my DTB and finally create the uImage file:

    cat arch/arm/boot/zImage ./arch/arm/boot/dts/lpc3250-phy3250.dtb > arch/arm/boot/zImage-dtb
    mkimage -A arm -O linux -C none -T kernel -a 0x80008000 -e 0x80008000 -n Linux -d arch/arm/boot/zImage-dtb arch/arm/boot/uImage-dtb

I'm trying to figure out how to properly replicate this process in Yocto.

I see that Poky's meta/classes/kernel-devicetree.bbclass uses the KERNEL_DEVICETREE_BUNDLE variable to do something similar. If I have KERNEL_IMAGETYPE set to "zImage", then it will create a zImage+DTB file.

However, it expects the zImage file to be called "zImage", and the one that gets built is called "zImage-5.14.6-yocto-standard". Since it cannot find "zImage", the build fails.

    cat: .../tmp/work/lpc3250-poky-linux-gnueabi/linux-yocto/5.14.6+gitAUTOINC+4f4ad2c808_7ae156be3b-r0/image/boot/zImage: No such file or directory


I also see that meta-ti has a bundle-devicetree.inc file that has a similar aim, but it deals with uImages instead.

https://git.yoctoproject.org/meta-ti/tree/recipes-kernel/linux/bundle-devicetree.inc

My concern with using this is that it appends the DTB directly to the uImage. However the uImage header structure includes a field for data size and another one for checksum. These fields are only computed correctly if the DTB is already appended before the uImage file is built.


I think if I can figure out how to make KERNEL_DEVICETREE_BUNDLE create the zImage+DTB file, then I can write a do_deploy:append() function that invokes mkimage to produce the uImage. But I'm not sure how to diagnose the problem.

Thanks,
Ryan


Re: wic create mkhybridiso core-image-minimal failure (honister)

bgctkd@...
 

Solution: I poked around and discovered the primary issue is that I was adding wic, but not cpio.gz to IMAGE_FSTYPES


Re: [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4

Jean-Philippe Lebel <jp@...>
 

Hello Marc,

I doubt this is a manipulation issue (at least in regards to burning the image). 

meta-raspberrypi master, yocto master -> works (core-image-base, stock, no modification beside RPI_USE_U_BOOT="1")

meta-raspberrypi hardknott, yocto hardknott -> doesn't work (core-image-base, stock, no modification beside RPI_USE_U_BOOT="1")

That being said, I've inspected both the working image and the non-working one and they look very similar (files and structure). I will take a closer look at the format.

Thanks
-------------
Jean-Philippe Lebel, ing. MBA
jp@...
http://www.lebel.pro
cell: 418-931-3800

AVIS IMPORTANT: Ce courriel est strictement réservé à l'usage de la (des) personne(s) à qui il est adressé et peut contenir de l'information privilégiée et confidentielle. Toute divulgation, distribution, copie, ou autre utilisation de ce courriel par une autre personne est strictement prohibée. Si vous avez reçu ce courriel par erreur, veuillez s'il vous plaît communiquer immédiatement avec l'expéditeur et détruire le courriel sans en faire de copie sous quelque forme.

WARNING: This e-mail contains confidential information intended only for the person(s) named above. If you are not the intended recipient you are hereby notified that any disclosure, copying, distribution, or any other use of this e-mail is strictly prohibited. If you have received this e-mail by mistake, please notify us immediately and destroy this e-mail without making any copy of any kind.


On Fri, Jan 14, 2022 at 3:40 PM Marc Ferland <marc.ferland@...> wrote:
On Fri, Jan 14, 2022 at 10:39 AM Jean-Philippe Lebel <jp@...> wrote:
>
> I finally received my UART cable, giving me more details about where the boot sequence fails.
>
> Just a quick summary of my tests
> - Enabling UART does indeed "fix" the issue when working from the meta-raspberrypi AND yocto master.
> - Enabling UART has no impact when working from the meta-raspberrypi and yocto hardknott branch (which I need to support) - image doesn't boot
> - Backporting the meta-raspberrypi master branch to hardknott does NOT fix the problem.
>
> Here is the uboot log (failing).
>
> U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)
>
> DRAM:  1.9 GiB
> RPI 4 Model B (0xb03114)
> MMC:   mmcnr@7e300000: 1, emmc2@7e340000: 0
> Loading Environment from FAT... ** No partition table - mmc 0 **
> In:    serial
> Out:   serial
> Err:   serial
> Net:   eth0: ethernet@7d580000
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> starting USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devices... 2 USB Device(s) found
>        scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> ** No partition table - mmc 0 **
> Card did not respond to voltage select! : -110
>
> Here is a normal uboot sequence
>
> U-Boot 2021.10 (Oct 04 2021 - 15:09:26 +0000)
>
> DRAM:  1.9 GiB
> RPI 4 Model B (0xb03114)
> MMC:   mmcnr@7e300000: 1, mmc@7e340000: 0
> Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In:    serial
> Out:   vidconsole
> Err:   vidconsole
> Net:   eth0: ethernet@7d580000
> PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
> starting USB...
> Bus xhci_pci: Register 5000420 NbrPorts 5
> Starting the controller
> USB XHCI 1.00
> scanning bus xhci_pci for devices... 2 USB Device(s) found
>        scanning usb for storage devices... 0 Storage Device(s) found
> Hit any key to stop autoboot:  0
> switch to partitions #0, OK
> mmc0 is current device
> Scanning mmc 0:1...
> Found U-Boot script /boot.scr
> 262 bytes read in 6 ms (42 KiB/s)
> ## Executing script at 02400000
> 23202304 bytes read in 997 ms (22.2 MiB/s)
> Saving Environment to FAT... OK
> Moving Image from 0x80000 to 0x200000, end=1960000
> ## Flattened Device Tree blob at 2eff3600
>    Booting using the fdt blob at 0x2eff3600
>    Using Device Tree in place at 000000002eff3600, end 000000002f002f13
>
> Starting kernel ...
>
> Basically, the failing Uboot can't find the partition table.
>

Well is there a partition table? Can you share what you are doing to
flash your uSD? Maybe it's just some manipulation error.

Marc


Re: [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4

Marc Ferland
 

On Fri, Jan 14, 2022 at 10:39 AM Jean-Philippe Lebel <jp@...> wrote:

I finally received my UART cable, giving me more details about where the boot sequence fails.

Just a quick summary of my tests
- Enabling UART does indeed "fix" the issue when working from the meta-raspberrypi AND yocto master.
- Enabling UART has no impact when working from the meta-raspberrypi and yocto hardknott branch (which I need to support) - image doesn't boot
- Backporting the meta-raspberrypi master branch to hardknott does NOT fix the problem.

Here is the uboot log (failing).

U-Boot 2021.01 (Jan 11 2021 - 18:11:43 +0000)

DRAM: 1.9 GiB
RPI 4 Model B (0xb03114)
MMC: mmcnr@7e300000: 1, emmc2@7e340000: 0
Loading Environment from FAT... ** No partition table - mmc 0 **
In: serial
Out: serial
Err: serial
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
** No partition table - mmc 0 **
Card did not respond to voltage select! : -110

Here is a normal uboot sequence

U-Boot 2021.10 (Oct 04 2021 - 15:09:26 +0000)

DRAM: 1.9 GiB
RPI 4 Model B (0xb03114)
MMC: mmcnr@7e300000: 1, mmc@7e340000: 0
Loading Environment from FAT... Unable to read "uboot.env" from mmc0:1... In: serial
Out: vidconsole
Err: vidconsole
Net: eth0: ethernet@7d580000
PCIe BRCM: link up, 5.0 Gbps x1 (SSC)
starting USB...
Bus xhci_pci: Register 5000420 NbrPorts 5
Starting the controller
USB XHCI 1.00
scanning bus xhci_pci for devices... 2 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
262 bytes read in 6 ms (42 KiB/s)
## Executing script at 02400000
23202304 bytes read in 997 ms (22.2 MiB/s)
Saving Environment to FAT... OK
Moving Image from 0x80000 to 0x200000, end=1960000
## Flattened Device Tree blob at 2eff3600
Booting using the fdt blob at 0x2eff3600
Using Device Tree in place at 000000002eff3600, end 000000002f002f13

Starting kernel ...

Basically, the failing Uboot can't find the partition table.
Well is there a partition table? Can you share what you are doing to
flash your uSD? Maybe it's just some manipulation error.

Marc


Re: perf compilation fails

Khem Raj
 

take a look at following link, it will help solve this hopefully

https://wiki.gentoo.org/wiki/Project:Toolchain/Binutils_2.34_porting_notes/undefined_reference_to_bfd_get_section_*

On Fri, Jan 14, 2022 at 2:02 AM Michael Opdenacker
<michael.opdenacker@...> wrote:

Hi Jose Antonio

On 1/13/22 3:29 PM, Cardenas Jose Antonio (JCARDENA) wrote:

Hi guys



I’m no table to build correctly perf package.



It looks like some sources have no been compiled because I’m getting
an “undefined reference to” error.



This problem has appeared since we have upgraded the version of yocto
zeus.



I’m getting this error



arm-poky-linux-gnueabi-ld
--sysroot=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot
-r -o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-bench.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-annotate.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-config.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-diff.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-evlist.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-ftrace.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-help.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-sched.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-buildid-list.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-buildid-cache.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kallsyms.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-list.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-record.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-report.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-stat.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-timechart.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-top.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-script.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kmem.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-lock.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-kvm.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-inject.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-mem.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-data.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-version.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-c2c.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/builtin-probe.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/bench/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tests/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/util/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/arch/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/ui/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/scripts/perf-in.o

arm-poky-linux-gnueabi-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard
-fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat
-Wformat-security -Werror=format-security -Os -pipe -g
-feliminate-unused-debug-types
-fmacro-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9=/usr/src/debug/perf/1.0-r9
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9=/usr/src/debug/perf/1.0-r9
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot=
-fdebug-prefix-map=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native=
--sysroot=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot
-ldw -Wbad-function-cast -Wdeclaration-after-statement
-Wformat-security -Wformat-y2k -Winit-self -Wmissing-declarations
-Wmissing-prototypes -Wnested-externs -Wno-system-headers
-Wold-style-definition -Wpacked -Wredundant-decls -Wstrict-prototypes
-Wswitch-default -Wswitch-enum -Wundef -Wwrite-strings -Wformat
-Wstrict-aliasing=3 -Wshadow -DHAVE_PERF_REGS_SUPPORT -O6
-fno-omit-frame-pointer -ggdb3 -funwind-tables -Wall -Wextra
-std=gnu99 -fstack-protector-all -D_FORTIFY_SOURCE=2
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/util/include
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/arch/arm/include
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/include/uapi
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/include/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/include/uapi
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/include/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/arch/arm/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0//util
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf/util
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/lib/
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE
-DHAVE_SYNC_COMPARE_AND_SWAP_SUPPORT
-DHAVE_PTHREAD_ATTR_SETAFFINITY_NP -DHAVE_PTHREAD_BARRIER
-DHAVE_EVENTFD -DHAVE_GET_CURRENT_DIR_NAME -DHAVE_GETTID
-DHAVE_DWARF_GETLOCATIONS_SUPPORT -DHAVE_GLIBC_SUPPORT
-DHAVE_AIO_SUPPORT -DHAVE_SCHED_GETCPU_SUPPORT -DHAVE_SETNS_SUPPORT
-DHAVE_LIBELF_SUPPORT -DHAVE_LIBELF_MMAP_SUPPORT
-DHAVE_ELF_GETPHDRNUM_SUPPORT -DHAVE_GELF_GETNOTE_SUPPORT
-DHAVE_ELF_GETSHDRSTRNDX_SUPPORT -DHAVE_LIBBPF_SUPPORT -DHAVE_JITDUMP
-DHAVE_DWARF_UNWIND_SUPPORT -DHAVE_LIBUNWIND_SUPPORT
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot/usr/include
-DHAVE_LIBCRYPTO_SUPPORT -DHAVE_SLANG_SUPPORT -DNO_LIBPERL
-DHAVE_TIMERFD_SUPPORT -DNO_LIBPYTHON -DHAVE_CPLUS_DEMANGLE_SUPPORT
-DHAVE_LIBBFD_SUPPORT -DHAVE_ZLIB_SUPPORT -DHAVE_LZMA_SUPPORT
-DHAVE_BACKTRACE_SUPPORT -DDISASM_FOUR_ARGS_SIGNATURE
-DHAVE_AUXTRACE_SUPPORT
-I/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/
-ldl -lutil -Wl,-z,noexecstack -lunwind -lunwind-arm
-L/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot/usr/lib
-Xlinker
--dynamic-list=/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libtraceevent-dynamic-list
\


/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/pmu-events/pmu-events-in.o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libperf-in.o
-Wl,--whole-archive
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libapi.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libtraceevent.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libsubcmd.a
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/libbpf.a
-Wl,--no-whole-archive -Wl,--start-group -lpthread -lrt -lm -ldl -lelf
-lunwind -lunwind-arm -lcrypto -lslang -lbfd -lopcodes -liberty -lz
-llzma -Wl,--end-group -o
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf-in.o:
in function `find_address_in_section':

/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:200:
undefined reference to `bfd_get_section_flags'

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:204:
undefined reference to `bfd_get_section_vma'

/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/recipe-sysroot-native/usr/bin/arm-poky-linux-gnueabi/../../libexec/arm-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/9.3.0/ld:
/usr/src/debug/perf/1.0-r9/perf-1.0/tools/perf/util/srcline.c:205:
undefined reference to `bfd_get_section_size'

collect2: error: ld returned 1 exit status

make[2]: *** [Makefile.perf:608:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/perf]
Error 1

make[1]: *** [Makefile.perf:219: sub-make] Error 2

make: *** [Makefile:70: all] Error 2

make: Leaving directory
'/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/perf-1.0/tools/perf'

ERROR: oe_runmake failed

WARNING:
/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/temp/run.do_compile.146045:1
exit 1 from 'exit 1'

ERROR: Execution of
'/home/bob/develop/yocto/build/tmp/work/emperor-poky-linux-gnueabi/perf/1.0-r9/temp/run.do_compile.146045'
failed with exit code 1
Weird, this doesn't happen building core-image-minimal *for x86_64* on
the latest Poky, with gcc 11.2.
This may not help much, but at least you could compare.
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com




Re: Red alert but apparently harmless setscene errors

Michael Opdenacker
 

On 1/13/22 10:53 PM, Richard Purdie wrote:
On Thu, 2022-01-13 at 19:37 +0100, Michael Opdenacker wrote:
Hi Jose,

Thanks for your advice!

On 1/13/22 6:37 PM, Jose Quaresma wrote:
Hi,

I've seen the same for some time now when building core-image-minimal
with yocto state mirror and hashequiv servers.

After some investigation I think the root cause is some
bandwidth/connection limitation on the http yocto mirror.

Reducing the BB_NUMBER_THREADS="1" to a single core solves many of the
fetch issues for me,
my config is the default one with:

  BB_NUMBER_THREADS="1"
  SSTATE_MIRRORS = "file://.*
http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH
<http://sstate.yoctoproject.org/dev/PATH;downloadfilename=PATH>"
  BB_HASHSERVE_UPSTREAM = "typhoon.yocto.io:8687
<http://typhoon.yocto.io:8687>"
Oops, it seems you're right. I have the same SSTATE_MIRRORS and
BB_HASHSERVE_UPSTREAM settings as you do, and adding
BB_NUMBER_THREADS="1" makes the errors disappear.

It seems I should file a bug about that. The error messages just mention
local paths, not remote ones, so it sounds like a local issue while it's
apparently not.
That is useful to debug it but suggests there is an issue with concurrent
connections to the YP server.

I think we should have an open bug and get Michael Halstead's input on this.

Done: https://bugzilla.yoctoproject.org/show_bug.cgi?id=14690
Thanks for your advice.
Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [OE-core] Question of Yocto dunfell LTS period

Ross Burton <ross@...>
 

On Fri, 14 Jan 2022 at 12:41, Zoltan Boszormenyi via
lists.yoctoproject.org <zboszor=pr.hu@...> wrote:
It would also help if recipes staying on the same version
but adding patches for e.g. CVE fixes should increase their
PR value so their rebuilt versions can be put into a package repo.

Throwing away the buildroot (as suggested any time some obscure
build error happens) and restarting a complete image build
resets the autopr value so the repo would contain packages with
the same r0.0 release string and the package manager doesn't know
that the package is newer.
If you want persistent PRs between builds after deleting the build
tree, simply archive the PR database.

We're not going back to manually updating the PR on changes.

Ross