|
Yocto Project Newcomer & Unassigned Bugs - Help Needed
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
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/0628785685ab858a99c5bfca626c1d8fI 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
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
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
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.incMy 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)
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
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.procell: 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 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
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
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=14690Thanks 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
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
|
|
|
Re: [meta-raspberrypi] Problem with RPI_USE_U_BOOT with RaspberryPi4
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.
Any idea why?
Thanks
-------------
Jean-Philippe Lebel, ing. MBA
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 Jan 12, 2022, at 3:37 PM, Jean-Philippe Lebel wrote:
> For a reason I can't quite understand, everything stated working when I added
> ENABLE_UART = "1"
>
> Does anyone understand the relation between ENABLE_UART = "1" and RPI_USE_U_BOOT
> = "1" ?
>
> Thanks
>
> -------------
> Jean-Philippe
The documentation mentions a relationship between enable_uart and
(lower) core frequency on some hardware variants - could there be a
side-effect (if yes, maybe gpu_freq/arm_freq could play a factor) ?
Jerome
|
|
|
Re: Question of Yocto dunfell LTS period
On Fri, 2022-01-14 at 07:14 +0000, Matthias Klein wrote: Hello together,
I would like to add a question to the topic:
Why was the LTS period for dunfell extended?
Can we expect the same for kirstone? The project members agreed to fun an extension to the lifetime of dunfell from 2 years to 4 years. There should have been some announcements about this but we lack people on the advocacy side of the project with time to make that happen. That saddens me a lot and I think it is a missed opportunity but there isn't much I can do about it beyond what I've already tried. Extending Dunfell is an experiment so we would base a decision on how well the dunfell extension is working out. Extending an LTS like this requires a financial commitment from the project. At this point in time the project cannot commit to extending kirkstone as we can't guarantee the finances. Cheers, Richard
|
|
|
Re: [OE-core] Question of Yocto dunfell LTS period
Zoltan Boszormenyi <zboszor@...>
Funny you mention PR.
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.
2022. 01. 14. 10:42 keltezéssel, Alexander Kanavin írta:
toggle quoted messageShow quoted text
Actually, I think this was some kind of missed PR opportunity. Regular distros, such as RHEL, Debian and everyone else, are constantly trotting out their support windows as the reason to hand them the job of making products, so we could counter that better perhaps.
Alex
On Fri, 14 Jan 2022 at 06:28, Michael Opdenacker <michael.opdenacker@... <mailto:michael.opdenacker@...>> wrote:
On 1/14/22 2:36 AM, Jate Sujjavanich wrote:
> I received the answer to this question in IRC on 10/29/2021.
>
> 16:06
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083490
<https://libera.irclog.whitequark.org/yocto/2021-10-29#31083490>> <jatedev>
> I saw a wiki edit that said dunfell's LTS period is now through April
> 2024, but I've seen no announcements. Any truth to this rumor?
> 16:20
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083555
<https://libera.irclog.whitequark.org/yocto/2021-10-29#31083555>> <smurray>
> jatedev: it was announced on one of the technical calls a few weeks
> back, so yes AFAIK
> 16:25
> <https://libera.irclog.whitequark.org/yocto/2021-10-29#31083577
<https://libera.irclog.whitequark.org/yocto/2021-10-29#31083577>> <RP>
> jatedev: definitely true. I wish we could sort out the project
> advocacy side of things :(
>
> Let this email serve as a little advocacy.
I believe this would also help if the website (releases page) and/or
official documentation carried such information.
Thanks for raising this concern!
Cheers
Michael.
--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com <https://bootlin.com>
|
|
|
Re: [meta-zephyr][PATCH v3] meta-zephyr-bsp: Add autogenerated machines.
On Thu, 13 Jan 2022 at 23:17, Jon Mason <jdmason@...> wrote:
On Wed, Jan 12, 2022 at 8:02 PM Eilís Ní Fhlannagáin <pidge@...> wrote:
From: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
This commit adds 382 autogenerated machines generated via
generate-zephyr-machines.bb. These machines have obviously not all been
tested due to hardware access, but should work out of box.
Signed-off-by: Eilís Ní Fhlannagáin <elizabeth.flanagan@...>
I'm still seeing errors:
TUNE_ARCH is unset. Please ensure your MACHINE configuration includes
a valid tune configuration file which will set this correctly.
Error, the PACKAGE_ARCHS variable (all any noarch
${PACKAGE_EXTRA_ARCHS:tune-${DEFAULTTUNE}} v2m_musca_s1) for
DEFAULTTUNE (None) does not contain TUNE_PKGARCH ().Toolchain tunings
invalid:
No tuning found for default multilib.
Yes. Some numbers on this after my poor laptop thrashed around on this for a bit. 395 boards in zephyr 2.7.1 391 boards autogenerated via this patch 299 (including the original 8 in meta-zephyr) that can build zephyr-helloworld. Compiling is taking forever, given the number of boards (and other
reasons). So, I can't give an exhaustively confirmed list, but a
lazy grep of files without "require" shows 70 of them. Yes. Not a surprise on some of these. This patch tries to find the needed tune and sometimes just can't for various reasons.
$ git grep -L require meta-zephyr-bsp/conf/machine/
meta-zephyr-bsp/conf/machine/adp-xc7k-ae350.conf
meta-zephyr-bsp/conf/machine/altera-max10.conf
meta-zephyr-bsp/conf/machine/beaglev-starlight-jh7100.conf
meta-zephyr-bsp/conf/machine/bl5340-dvk-cpunet.conf
meta-zephyr-bsp/conf/machine/em-starterkit-em11d.conf
meta-zephyr-bsp/conf/machine/em-starterkit-em7d-v22.conf
meta-zephyr-bsp/conf/machine/em-starterkit-em7d.conf
meta-zephyr-bsp/conf/machine/em-starterkit.conf
meta-zephyr-bsp/conf/machine/emsdp-em4.conf
meta-zephyr-bsp/conf/machine/emsdp-em5d.conf
meta-zephyr-bsp/conf/machine/emsdp-em6.conf
meta-zephyr-bsp/conf/machine/emsdp-em7d-esp.conf
meta-zephyr-bsp/conf/machine/emsdp-em7d.conf
meta-zephyr-bsp/conf/machine/emsdp-em9d.conf
meta-zephyr-bsp/conf/machine/emsdp.conf
meta-zephyr-bsp/conf/machine/esp32c3-devkitm.conf
meta-zephyr-bsp/conf/machine/generic-leon3.conf
meta-zephyr-bsp/conf/machine/gr716a-mini.conf
meta-zephyr-bsp/conf/machine/hifive-unleashed.conf
meta-zephyr-bsp/conf/machine/hifive-unmatched.conf
meta-zephyr-bsp/conf/machine/hifive1-revb.conf
meta-zephyr-bsp/conf/machine/hifive1.conf
meta-zephyr-bsp/conf/machine/hsdk-2cores.conf
meta-zephyr-bsp/conf/machine/hsdk.conf
meta-zephyr-bsp/conf/machine/include/tune-arc.inc
meta-zephyr-bsp/conf/machine/include/tune-iamcu.inc
meta-zephyr-bsp/conf/machine/include/tune-nios2.inc
meta-zephyr-bsp/conf/machine/intel-adsp-cavs15.conf
meta-zephyr-bsp/conf/machine/intel-adsp-cavs18.conf
<snips> meta-zephyr-bsp/conf/machine/v2m-musca-b1.conf
meta-zephyr-bsp/conf/machine/v2m-musca-s1-ns.conf
meta-zephyr-bsp/conf/machine/v2m-musca-s1.conf
meta-zephyr-bsp/conf/machine/xt-sim-intel-s1000.conf
meta-zephyr-bsp/conf/machine/xt-sim.conf
Arm does care about the v2m boards, and we have a version of them in
meta-arm-bsp. So, I'm not being difficult for no reason. :) No, please. Be difficult, Jon. This is a radical change and needs a bit of review. I think maybe one solution here is (outside of making the search for tunes a bit better which will never be perfect as from an OE context as layers with a specific tune may not exist): - Run this pointing MACHINE_TUNINGS at the meta-arm-bsp layer and a few different layers. Or alternately, remove configs that exist in other layers. - Run a build on each machine generated to see if it passes helloworld - Remove any broken machines that don't pass that smoke test. Again, I'm very open to suggestions here. Outside the additional machines however, the one thing this patch series does give us is getting rid of MACHINEOVERRIDES for ZEPHYR_MODULES and lets west just figure this out. -b
Thanks,
Jon
|
|
|
Re: [meta-tensorflow][PATCH 3/3] tensorflow-lite: add recipe
Hi Hongxu
Did you have a chance to take a look at it?
Best Julien
Thanks Stephan.
Hongxu, did you miss this?
../Randy
On 2021-12-21 3:42 a.m., Julien STEPHAN wrote:
> Adding 2.6.1 tensorflow-lite recipe.
> This recipe is directly based on the corresponding 2.6.1 tensorflow
> recipe.
>
> It has been build tested with latest honister and tested on
> several mediatek soc using benchmark_model and label_image (C++ and
> python)
>
> Signed-off-by: Julien STEPHAN <jstephan@...>
> ---
> .../tensorflow/tensorflow-lite_2.6.1.bb | 156 ++++++++++++++++++
> 1 file changed, 156 insertions(+)
> create mode 100644 recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
>
> diff --git a/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb b/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
> new file mode 100644
> index 0000000..104e5a3
> --- /dev/null
> +++ b/recipes-framework/tensorflow/tensorflow-lite_2.6.1.bb
> @@ -0,0 +1,156 @@
> +include tensorflow.inc
> +
> +SRC_URI += " \
> + file://0001-add-yocto-toolchain-to-support-cross-compiling.patch \
> + file://0001-fix-build-tensorflow-lite-examples-label_image-label.patch \
> + file://0001-label_image-tweak-default-model-location.patch \
> + file://0001-label_image.lite-tweak-default-model-location.patch \
> + file://0001-CheckFeatureOrDie-use-warning-to-avoid-die.patch \
> + file://0001-support-32-bit-x64-and-arm-for-yocto.patch \
> + file://0001-Revert-set-distinct_host_configuration-false-by-defa.patch \
> + file://0001-fix-default-Bazel-toolchain-not-work.patch \
> + file://0001-distutils-is-deprecated-in-Python-3.10-cross.patch \
> + file://BUILD.in \
> + file://BUILD.yocto_compiler \
> + file://cc_config.bzl.tpl \
> + file://yocto_compiler_configure.bzl \
> + "
> +
> +SRC_URI += "https://storage.googleapis.com/download.tensorflow.org/models/inception_v3_2016_08_28_frozen.pb.tar.gz;name=model-inv3"
> +SRC_URI[model-inv3.md5sum] = "a904ddf15593d03c7dd786d552e22d73"
> +SRC_URI[model-inv3.sha256sum] = "7045b72a954af4dce36346f478610acdccbf149168fa25c78e54e32f0c723d6d"
> +
> +SRC_URI += "https://storage.googleapis.com/download.tensorflow.org/models/tflite/mobilenet_v1_1.0_224_quant_and_labels.zip;name=model-mobv1"
> +SRC_URI[model-mobv1.md5sum] = "38ac0c626947875bd311ef96c8baab62"
> +SRC_URI[model-mobv1.sha256sum] = "2f8054076cf655e1a73778a49bd8fd0306d32b290b7e576dda9574f00f186c0f"
> +
> +RDEPENDS:${PN} += " \
> + python3 \
> + python3-core \
> + python3-numpy \
> +"
> +
> +export PYTHON_BIN_PATH="${PYTHON}"
> +export PYTHON_LIB_PATH="${STAGING_LIBDIR_NATIVE}/${PYTHON_DIR}/site-packages"
> +
> +export CROSSTOOL_PYTHON_INCLUDE_PATH="${STAGING_INCDIR}/python${PYTHON_BASEVERSION}${PYTHON_ABI}"
> +
> +do_configure:append () {
> + if [ ! -e ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-target.h ];then
> + mv ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig.h ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-target.h
> + fi
> +
> + install -m 644 ${STAGING_INCDIR_NATIVE}/python${PYTHON_BASEVERSION}${PYTHON_ABI}/pyconfig.h \
> + ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig-native.h
> +
> + cat > ${CROSSTOOL_PYTHON_INCLUDE_PATH}/pyconfig.h <<ENDOF
> +#if defined (_PYTHON_INCLUDE_TARGET)
> +#include "pyconfig-target.h"
> +#elif defined (_PYTHON_INCLUDE_NATIVE)
> +#include "pyconfig-native.h"
> +#else
> +#error "_PYTHON_INCLUDE_TARGET or _PYTHON_INCLUDE_NATIVE is not defined"
> +#endif // End of #if defined (_PYTHON_INCLUDE_TARGET)
> +
> +ENDOF
> +
> + mkdir -p ${S}/third_party/toolchains/yocto/
> + sed "s#%%CPU%%#${BAZEL_TARGET_CPU}#g" ${WORKDIR}/BUILD.in > ${S}/third_party/toolchains/yocto/BUILD
> + chmod 644 ${S}/third_party/toolchains/yocto/BUILD
> + install -m 644 ${WORKDIR}/cc_config.bzl.tpl ${S}/third_party/toolchains/yocto/
> + install -m 644 ${WORKDIR}/yocto_compiler_configure.bzl ${S}/third_party/toolchains/yocto/
> + install -m 644 ${WORKDIR}/BUILD.yocto_compiler ${S}
> +
> + CT_NAME=$(echo ${HOST_PREFIX} | rev | cut -c 2- | rev)
> + SED_COMMAND="s#%%CT_NAME%%#${CT_NAME}#g"
> + SED_COMMAND="${SED_COMMAND}; s#%%WORKDIR%%#${WORKDIR}#g"
> + SED_COMMAND="${SED_COMMAND}; s#%%YOCTO_COMPILER_PATH%%#${BAZEL_OUTPUTBASE_DIR}/external/yocto_compiler#g"
> +
> + sed -i "${SED_COMMAND}" ${S}/BUILD.yocto_compiler \
> + ${S}/WORKSPACE
> +
> + ${TF_CONFIG} \
> + ./configure
> +}
> +
> +TF_TARGET_EXTRA ??= ""
> +
> +export CUSTOM_BAZEL_FLAGS = " \
> + ${TF_ARGS_EXTRA} \
> + --jobs=auto \
> + -c opt \
> + --cpu=${BAZEL_TARGET_CPU} \
> + --crosstool_top=@local_config_yocto_compiler//:toolchain \
> + --host_crosstool_top=@bazel_tools//tools/cpp:toolchain \
> +"
> +
> +do_compile () {
> + export CT_NAME=$(echo ${HOST_PREFIX} | rev | cut -c 2- | rev)
> + unset CC
> +
> + ${BAZEL} build \
> + ${CUSTOM_BAZEL_FLAGS} \
> + --copt -DTF_LITE_DISABLE_X86_NEON --copt -DMESA_EGL_NO_X11_HEADERS \
> + tensorflow/lite:libtensorflowlite.so \
> + tensorflow/lite/tools/benchmark:benchmark_model \
> + //tensorflow/lite/examples/label_image:label_image \
> + ${TF_TARGET_EXTRA}
> +
> + # build pip package
> + ${S}/tensorflow/lite/tools/pip_package/build_pip_package_with_bazel.sh
> +
> +}
> +
> +do_install() {
> + install -d ${D}${libdir}
> + install -m 644 ${S}/bazel-bin/tensorflow/lite/libtensorflowlite.so \
> + ${D}${libdir}
> +
> + install -d ${D}${sbindir}
> + install -m 755 ${S}/bazel-bin/tensorflow/lite/tools/benchmark/benchmark_model \
> + ${D}${sbindir}
> +
> + install -m 755 ${S}/bazel-bin/tensorflow/lite/examples/label_image/label_image \
> + ${D}${sbindir}/label_image
> +
> + install -d ${D}${datadir}/label_image
> + install -m 644 ${WORKDIR}/imagenet_slim_labels.txt ${D}${datadir}/label_image
> + install -m 644 ${WORKDIR}/inception_v3_2016_08_28_frozen.pb \
> + ${D}${datadir}/label_image
> + install -m 644 ${S}/tensorflow/examples/label_image/data/grace_hopper.jpg \
> + ${D}${datadir}/label_image
> +
> + install -m 644 ${WORKDIR}/labels_mobilenet_quant_v1_224.txt ${D}${datadir}/label_image
> + install -m 644 ${WORKDIR}/mobilenet_v1_1.0_224_quant.tflite \
> + ${D}${datadir}/label_image
> + install -m 644 ${S}/tensorflow/lite/examples/label_image/testdata/grace_hopper.bmp \
> + ${D}${datadir}/label_image
> +
> +
> + #echo "Installing pip package"
> + install -d ${D}/${PYTHON_SITEPACKAGES_DIR}
> + ${STAGING_BINDIR_NATIVE}/pip3 install --disable-pip-version-check -v \
> + -t ${D}/${PYTHON_SITEPACKAGES_DIR} --no-cache-dir --no-deps \
> + ${S}/tensorflow/lite/tools/pip_package/gen/tflite_pip/python3/dist/tflite_runtime-${PV}-*.whl
> +
> +}
> +
> +FILES:${PN} += "${libdir} ${sbindir} ${datadir}/*"
> +INSANE_SKIP:${PN} += "dev-so \
> + already-stripped \
> + "
> +
> +SOLIBS = ".so"
> +FILES_SOLIBSDEV = ""
> +ALLOW_EMPTY:${PN} = "1"
> +
> +FILES:${PN} += "${libdir} /home/root/*"
> +
> +inherit siteinfo unsupportarch
> +python __anonymous() {
> + if d.getVar("SITEINFO_ENDIANNESS") == 'be':
> + msg = "\nIt failed to use pre-build model to do predict/inference on big-endian platform"
> + msg += "\n(such as qemumips), since upstream does not support big-endian very well."
> + msg += "\nDetails: https://github.com/tensorflow/tensorflow/issues/16364"
> + bb.warn(msg)
> +}
>
>
>
>
>
--
# Randy MacLeod
# Wind River Linux
|
|
|
Re: perf compilation fails
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: [OE-core] Question of Yocto dunfell LTS period
Actually, I think this was some kind of missed PR opportunity. Regular distros, such as RHEL, Debian and everyone else, are constantly trotting out their support windows as the reason to hand them the job of making products, so we could counter that better perhaps.
Alex
|
|
|
Re: Installing specific systemd service file according to selected distro
Konrad Weihmann <kweihmann@...>
Fairly easy, each distro creates an OVERRIDE by default, so you could do
A:poky = "foo.service"
A:yourdistro = "bar.service"
SYSTEMD_PACKAGES = "${A}"
do_install:append() {
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/${A} ${D}${systemd_system_unitdir}
}
you could also try to create distro-specific do_install appends like
do_install:append:<yourdistro> if you need to do further step besides installing
toggle quoted messageShow quoted text
On 14.01.22 06:54, davis roman wrote: Hello,
I have a recipe that contains two service files( A and B) and I build
for two distros where each include the foo recipe.
When I build for distro A, I need to use foo's service file A but when
I build distro B, I need to use foo's service file B.
I could add some logic in the foo recipe to detect the DISTRO and
install the proper service file but I have a feeling this isn't the
yocto way.
Is there a better way of handling this use case?
Thank you,
Davis
|
|
|
