|
Re: Using bitbake with external SDK
#sdk
#zeus
#toolchain
Hello Enrico,
an eSDK would be enough to do everything, however I would demand the entire development system if I were to start a project, but that is my opinion. I don't know well Node-RED but using devtool add you should be able to create or manage a recipe for any Node application. Happy hacking! -- Marco Cavallini | KOAN sas Bergamo - Italia embedded software engineering https://KoanSoftware.com
|
|
|
|
Re: Using bitbake with external SDK
#sdk
#zeus
#toolchain
enrico.buffoli1994@...
Hello Marco,
In your opinion isn't enough to ask for eSDK? for instance if i want to add Node-RED, it would be difficult to build with devtool? because i've seen that it doesn't resolve dependencies automatically. Thanks.
|
|
|
|
Re: Using bitbake with external SDK
#sdk
#zeus
#toolchain
enrico.buffoli1994@...
With the eSDK i've to use devtool right?
|
|
|
|
Re: Using bitbake with external SDK
#sdk
#zeus
#toolchain
Hello Enrico,
usually nowadays every honest hardware manufacturer provides all the sources of the BSP and the development system to their customers. Try asking your supplier for them. -- Marco Cavallini | KOAN sas Bergamo - Italia embedded software engineering https://KoanSoftware.com
|
|
|
|
[meta-zephyr][PATCH 1/2] zephyr-qemuboot: fix parse build failure
Naveen Saini
As OE-core explicitly have added depends for qemu-helper addto_recipe_sysroot task, which
breaks zephyr-qemuboot implementation of adding build dependencies http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=282d596b8cc81d650b6d20c6131fdc236bad2c20 ERROR: Error for meta-zephyr/recipes-kernel/zephyr-kernel/zephyr-helloworld.bb: do_bootconf_write[depends], dependency qemu-helper-native:do_addto_recipe_sysroot:do_addto_recipe_sysroot in ' qemu-helper-native:do_addto_recipe_sysroot:do_addto_recipe_sysroot qemu-helper-native:do_addto_recipe_sysroot:do_populate_sysroot' does not contain exactly one ':' character. Task 'depends' should be specified in the form 'packagename:task' ERROR: Command execution failed: Exited with 1 Signed-off-by: Naveen Saini <naveen.kumar.saini@...> --- classes/zephyr-qemuboot.bbclass | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass index c268e9e..b45e6f6 100644 --- a/classes/zephyr-qemuboot.bbclass +++ b/classes/zephyr-qemuboot.bbclass @@ -48,7 +48,7 @@ python () { for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split(): # Make sure we only add it for qemu if 'qemu-helper-native' in dep: - deps += " %s:%s" % (dep, task) + deps += " qemu-helper-native:%s" % (task) return deps d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot')) d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_populate_sysroot')) -- 2.17.1
|
|
|
|
[meta-zephyr][PATCH 2/2] zephyr-kernel: upgrade 2.6.0 -> 2.6.1
Naveen Saini
It has GCC-11 fixes.
https://github.com/zephyrproject-rtos/zephyr/issues/35707 Commits included: 2d6322d74a demand_paging: eviction/nru: fix incorrect dirty bit return val 25771e6928 drivers: clock_control: stm32: enable PWR clock unconditionally 92e36185e8 [Backport v2.6-branch] Microchip: XEC GPIO driver interrupt enable part 2 68d33e3834 libc/minimal: locate the memory pool for malloc() to .bss 7f3abab9bf net: tcp: accept [FIN, PSH, ACK] in TCP_FIN_WAIT_2 state 533dcaf374 lib/os/cbprintf_nano.c: avoid sign extension on unsigned formats ea55ebfa74 tests: schedule_api: use stack array extern macro 95bb8841b8 tests: mem_protect: fix warning on uninitialized variable 1f8c53dfaf tests: kernel/common: avoid using compiler builtin popcount 7bb7454a00 kernel: use proper macro to declare extern interrupt stacks 25fd176014 kernel: add macros to allow declaring extern stack arrays e1cde092ac kernel: move Z_KERNEL_STACK_LEN higher in thread_stack.h 244049bd71 x86: type cast to uint8_t* for bit ops 5dae0c1bf0 kernel: ignore array bound warnings for generated syscall funcs 5666e4d525 cmake: force GCC to emit DWARF version 4 91a78866ca Bluetooth: Controller: Fix advertising after connections from same peer 0afddb2341 x86/cache: fix issues in arch dcache flush function 9bcf9b6a53 json: fix parsing first array-array element 2595cce714 cmake: oneApi: add oneApi support on windows. 18d314e750 cmake: oneApi: add oneApi support on windows c8755e0b46 (tag: v2.6.1-rc1) tests/benchmarks: add dynamic memory allocation measurement a4d35f0a3e doc: 2.6.1 release notes 7094aaee55 release: Bump release to 2.6.1-rc1 585c03a0b6 drivers/clock_control: stm32: Fix macro to get HCLK freq cacb0a4e59 Bluetooth: L2CAP: Fix missing net_buf_unref() 78ab750540 timer: hpet: convert register access to functions d9df404d47 timer: hpet: don't force TIMER_READS_ITS_FREQUENCY_AT_RUNTIME 8e80955511 timer: hpet: allow overriding MIN_DELAY 99dc33faaf timer: hpet: extract Counter Clock Period into a macro 02fbe652a5 logging: fs: fix leak of opened directories in check_log_file_exist() 80b406d784 x86: acpi: limit search on where EBDA can be Signed-off-by: Naveen Saini <naveen.kumar.saini@...> --- ...ephyr-kernel-src-2.6.0.inc => zephyr-kernel-src-2.6.1.inc} | 4 ++-- recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) rename recipes-kernel/zephyr-kernel/{zephyr-kernel-src-2.6.0.inc => zephyr-kernel-src-2.6.1.inc} (90%) diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc similarity index 90% rename from recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc rename to recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc index 63665bf..109242e 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.1.inc @@ -1,5 +1,5 @@ SRCREV_FORMAT = "default_cmsis" -SRCREV_default = "837ab4a915f7802a6fb02a27e4b024e287ac93c2" +SRCREV_default = "2d6322d74aaac838ead46bfcba0db619cff4b534" SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e" SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681" SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df" @@ -10,7 +10,7 @@ SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0" SRCREV_mbedtls = "5765cb7f75a9973ae9232d438e361a9d7bbc49e7" ZEPHYR_BRANCH = "v2.6-branch" -PV = "2.6.0+git${SRCPV}" +PV = "2.6.1+git${SRCPV}" SRC_URI:append = " file://0001-cmake-add-yocto-toolchain.patch \ file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \ diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc index abe755d..458ff1e 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc @@ -22,5 +22,5 @@ SRC_URI = "\ S = "${WORKDIR}/git" # Default to a stable version -PREFERRED_VERSION_zephyr-kernel ??= "2.6.0" +PREFERRED_VERSION_zephyr-kernel ??= "2.6.1" include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc -- 2.17.1
|
|
|
|
Re: "stack smashing detected" when building aarch64 kernel
its hard to say what might be going on. Perhaps enable builds with V=1
toggle quoted messageShow quoted text
so you can see if its always failing to compile at same file. or atleast you can get one file where it fails then you can use preprocessed file to build it in a loop and see if you can get it to fail more. On Thu, Sep 23, 2021 at 8:16 AM Rasmus Villemoes via lists.yoctoproject.org <rasmus.villemoes=prevas.dk@...> wrote:
|
|
|
|
Re: gcov support for target in Yocto
On Thu, Sep 23, 2021 at 9:53 AM Lijun Chen <lijchen@...> wrote:
IMAGE_INSTALL += "gcov gcov-symlinks"
|
|
|
|
Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device
are you both using systemd or sysvinit
toggle quoted messageShow quoted text
On Thu, Sep 23, 2021 at 3:26 PM Markus Volk <f_l_k@...> wrote:
|
|
|
|
Re: googletest shared library
Federico Pellegrin
Hi, Regarding the INSANE_SKIP: as that files get packed in the "-dev" package, you should probably then accordingly have: INSANE_SKIP_${PN}-dev += "dev-elf" Cheers, Federico
Il giorno gio 23 set 2021 alle ore 16:46 Lijun Chen <lijchen@...> ha scritto:
|
|
|
|
Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device
Markus Volk
I'm surprised mount doesn't complain about those first 5 lines! Those are not properly-formed fstab(5) entries. No, it doesn't. Those entries are ignored except /boot. One interesting thing: i always had that bunch of malformed fstab entries. Before the change from static to uuid it looked like this in fstab: /dev/mmcblk1p1 loader1 vfat defaults 0 0 /dev/mmcblk1p2 reserved1 vfat defaults 0 0 /dev/mmcblk1p3 reserved2 vfat defaults 0 0 /dev/mmcblk1p4 loader2 vfat defaults 0 0 /dev/mmcblk1p5 atf vfat defaults 0 0 /dev/mmcblk1p6 /boot vfat defaults 0 0 Now it looks like wic fails in getting the correct value and uses sda as a best bet you're proposing (a bunch of malformed fstab(5) entries) should be considered correct. I guess i just got used to it because it has always been like this since i build for the rock-pi
In the mean time I'd like to apply your patch 2/2, if you could please add your SoB line? Have sent new patches. Just delete the first one if you dont need it
|
|
|
|
[meta-rockchip][PATCH v2 2/2] rockchip-wic.inc: dont let wic edit fstab by default
Markus Volk
Signed-off-by: MarkusVolk <f_l_k@...>
--- conf/machine/include/rockchip-wic.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/conf/machine/include/rockchip-wic.inc b/conf/machine/include= /rockchip-wic.inc index 15010a0..30b0d57 100644 --- a/conf/machine/include/rockchip-wic.inc +++ b/conf/machine/include/rockchip-wic.inc @@ -26,3 +26,6 @@ WICVARS:append =3D " \ SPL_BINARY \ UBOOT_SUFFIX \ " + +# Do not update fstab file while creating wic images +WIC_CREATE_EXTRA_ARGS ?=3D "--no-fstab-update" --=20 2.25.1
|
|
|
|
[meta-rockchip][PATCH v2 1/2] rockchip.wks: use uuid for all partitions
Markus Volk
My rock pi 4 refused to boot with the latest changes because there are fa=
lse entries written to fstab. Fix this by using uuid for all partitions Signed-off-by: MarkusVolk <f_l_k@...> --- wic/rockchip.wks | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/wic/rockchip.wks b/wic/rockchip.wks index 5ee276b..90bdb27 100644 --- a/wic/rockchip.wks +++ b/wic/rockchip.wks @@ -15,12 +15,12 @@ # boot 32768 229376 # root 262144 - (suggested) =20 -part loader1 --offset 32 --fixed-size 4000K --source r= awcopy --sourceparams=3D"= file=3D${SPL_BINARY}" -part reserved1 --offset 4032 --fixed-size 64K -part reserved2 --offset 4096 --fixed-size 4096K -part loader2 --offset 8192 --fixed-size 4096K --source r= awcopy --sourceparams=3D"= file=3Du-boot.${UBOOT_SUFFIX}" -part atf --offset 12288 --fixed-size 4096K -part /boot --offset 16384 --size 114688K --active --source b= ootimg-partition --fstype=3Dvfat --label boot --sourceparams=3D= "loader=3Du-boot" -part / --source r= ootfs --fstype=3Dext4 --label root --use-uuid +part loader1 --offset 32 --fixed-size 4000K --source rawcopy --sourcepar= ams=3D"file=3D${SPL_BINARY}" --use-uuid +part reserved1 --offset 4032 --fixed-size 64K --use-uuid +part reserved2 --offset 4096 --fixed-size 4096K --use-uuid +part loader2 --offset 8192 --fixed-size 4096K --source rawcopy --sourcep= arams=3D"file=3Du-boot.${UBOOT_SUFFIX}" --use-uuid +part atf --offset 12288 --fixed-size 4096K --use-uuid +part /boot --offset 16384 --size 114688K --active --source bootimg-parti= tion --fstype=3Dvfat --label boot --sourceparams=3D"loader=3Du-boot" --us= e-uuid +part / --source rootfs --fstype=3Dext4 --label root --use-uuid =20 -bootloader --ptable gpt --append=3D"console=3Dtty1 console=3D${RK_CONSOL= E_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=3Dext4 init=3D/sbin/init" +bootloader --ptable gpt --append=3D"console=3Dtty1 console=3D${RK_CONSOL= E_DEVICE},${RK_CONSOLE_BAUD}n8 rw rootfstype=3Dext4 init=3D/sbin/init" --=20 2.25.1
|
|
|
|
Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device
Trevor Woerner
On Thu 2021-09-23 @ 09:45:06 PM, Markus Volk wrote:
Thanks for testing. It's also strange that my fstab also has those entries, but they're apparently ignored in my setup since, commented in or commented out, they don't seem to affect my board's ability to boot. I'm surprised mount doesn't complain about those first 5 lines! Those are notI wonder if just applying your 2nd patch would be enough (i.e. the one thatApplying only the second patch should be enough to hide the problem, but as soon as properly-formed fstab(5) entries. I wouldn't call only applying your second patch a form of "hiding the problem". Neither what we had before (a bunch of /dev/sda entries) and what you're proposing (a bunch of malformed fstab(5) entries) should be considered correct. If a user messes with BSP-level variables, then they should expect what they get (?). We can add the --use-uuid line to the /boot entry if you really think it should be mounted on boot, but we shouldn't use it on the others and cause wic to generate a bad fstab. There are examples of other boards that don't mount /boot by default (raspi for sure, and I think bbb too). I'll try to look deeper to figure out what's generating those /dev/sda entries. Maybe there's a way to disable them without resorting to WIC_CREATE_EXTRA_ARGS? In the mean time I'd like to apply your patch 2/2, if you could please add your SoB line? u-boot is able to find its partitons even if '--use-uuid' is set. As you mentioned u-boot doesn'tSorry, I wasn't clear. u-boot doesn't use those labels to find u-boot, my guess is that the SoC's ROM firmware blindly looks at fixed offsets for the "what to boot" (and therefore isn't using UUIDs either). Either the ROM loads the atf, which then loads u-boot's spl, or the ROM loads the atf and then loads u-boot's spl from fixed locations. Perhaps u-boot's spl uses labels to find u-boot proper, but that's irrelevant. My guess is that Khem probably likes building with a long list of layers asAre you using poky or a distro other than "nodistro"? Perhaps otherThats not unlikely. I have a long layer-list in bblayers.conf to build my image: well ;-) I'll try using poky to see if that changes anything. Using oecore, bitbake, meta-arm, and meta-rockchip I can't reproduce what you and Khem are seeing. One of these days I'll have to check to make sure meta-rockchip is behaving like it should when mixed with other layers.
|
|
|
|
scikit-learn
#gatesgarth
#yocto
abhi <abhishek.kumar@...>
hi guys,
i am trying to build scikit-learn on yocto but i am getting error of setup.py ,it is showing failed i build all dependencies but it is giving error please try to give some i dea ERROR: python3-sklearn-1.0-r0 do_compile: 'python3 setup.py build ' execution failed. ERROR: python3-sklearn-1.0-r0 do_compile: Execution of '/home/abhishek//sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/temp/run.do_compile.17835' failed with exit code 1: /home/abhishek//sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3: can't open file '/home/abhishek/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/scikit-learn-1.0/setup.py': [Errno 2] No such file or directory WARNING: exit code 1 from a shell command. ERROR: Logfile of failure stored in: /home/abhishek/exaleap/sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/temp/log.do_compile.17835 Log data follows: | DEBUG: Executing shell function do_compile | /home/abhishek//sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3: can't open file '/home/abhishek//sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/scikit-learn-1.0/setup.py': [Errno 2] No such file or directory | ERROR: 'python3 setup.py build ' execution failed. | WARNING: exit code 1 from a shell command. | ERROR: Execution of '/home/abhishek//sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/temp/run.do_compile.17835' failed with exit code 1: | /home/abhishek//sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/recipe-sysroot-native/usr/bin/python3-native/python3: can't open file '/home/abhishek//sources/fu540-build/tmp-glibc/work/riscv64-oe-linux/python3-sklearn/1.0-r0/scikit-learn-1.0/setup.py': [Errno 2] No such file or directory | WARNING: exit code 1 from a shell command.
|
|
|
|
Re: [meta-rockchip][PATCH] use uuid instead of hard-coding root device
Markus Volk
Am 23.09.21 um 13:59 schrieb Trevor
Woerner:
Curious. I boot tested my patch on multiple boards and I've built and booted numerous images on my rock-pi-4b and rock64 boards in the last day or so since I applied the patch. I'll try some "clean" builds and see if that makes a difference. I don't doubt your report (especially since Khem confirmed it), I'd just like to know for myself what's different. That is really strange. As soon as there are those /dev/sda* entries in my fstab my rock-pi-4c doesn't boot up anymore. As soon as i comment them out or delete them, everything is working again. I wonder if just applying your 2nd patch would be enough (i.e. the one that removes the /dev/sda* lines from /etc/fstab)? It's odd that the first 6 entries in the wic file would need UUIDs since it's the SoC's ROM firmware that uses them, and I'm pretty sure the Rockchip firmware isn't using UUIDs (my guess is it's just blindly grabbing whatever it finds at specific offsets). The things stored in those partitions are u-boot related bits (atf, spl, the u-boot binary itself) so by the time Linux starts, those things are already "behind" us. I can't see how adding UUIDs to the partitions holding u-boot would affect how the kernel finds the root partition (?). Applying only the second patch should be enough to hide the problem, but as soon as one decides to disable WIC_CREATE_EXTRA_ARGS for example because he/she wants /boot to be mounted automatically, those non working /dev/sda* entries will be written into fstab again. With the first patch they are included like this and are mountable via fstab: UUID=0C48-9342 loader1 vfat defaults 0 0 UUID=C4D3-D17A reserved1 vfat defaults 0 0 UUID=8FBE-2551 reserved2 vfat defaults 0 0 UUID=35FA-8BBB loader2 vfat defaults 0 0 UUID=CFF3-5D80 atf vfat defaults 0 0 UUID=832C-48C4 /boot vfat defaults 0 0 u-boot is able to find its partitons even if '--use-uuid' is set. As you mentioned u-boot doesn't know about uuid but it seems to be able to find its partitions nevertheless. But if '--use-uuid' is not set, wic writes /dev/sda* instead of the correct UUID values to fstab. So its not u-boot that needs uuid to be set but fstab. Of course it would be nice, if wic didn't try to add the u-boot partitions to fstab at all. I guess nobody ever needs to have them mounted into userspace ( except possibly /boot). Are you using poky or a distro other than "nodistro"? Perhaps other layers/distros are affecting the build? Thats not unlikely. I have a long layer-list in bblayers.conf to build my image: /home/flk/build/poky/meta \ /home/flk/build/poky/meta-poky \ /home/flk/build/poky/meta-yocto-bsp \ /home/flk/build/poky/meta-rockchip \ /home/flk/build/poky/meta-rockchip-extras \ /home/flk/build/poky/meta-wayland \ /home/flk/build/poky/meta-retro \ /home/flk/build/poky/meta-retro-wayland \ /home/flk/build/poky/meta-rauc \ /home/flk/build/poky/meta-openembedded/meta-oe \ /home/flk/build/poky/meta-openembedded/meta-multimedia \ /home/flk/build/poky/meta-openembedded/meta-networking \ /home/flk/build/poky/meta-openembedded/meta-xfce \ /home/flk/build/poky/meta-openembedded/meta-gnome \ /home/flk/build/poky/meta-openembedded/meta-python \ /home/flk/build/poky/meta-openembedded/meta-filesystems \ /home/flk/build/poky/meta-arm/meta-arm \ /home/flk/build/poky/meta-arm/meta-arm-toolchain \ /home/flk/build/poky/meta-kodi \ /home/flk/build/poky/meta-browser/meta-chromium \ /home/flk/build/poky/meta-browser/meta-firefox \ /home/flk/build/poky/meta-clang \ best regards, Markus
|
|
|
|
Re: Minutes: Yocto Project Weekly Triage Meeting 9/23/2021
Steve Sakoman
On Thu, Sep 23, 2021 at 5:40 AM Trevor Gamblin
<trevor.gamblin@...> wrote: I was looking at two issues prior to the meeting. Sadly, due to inadequate caffeine blood levels and the early hour I confused the two. So this explains why I couldn't find the logs during the meeting. So nothing to post :-( Steve
|
|
|
|
Re: Using bitbake with external SDK
#sdk
#zeus
#toolchain
On Thu, Sep 23, 2021 at 6:46 AM <enrico.buffoli1994@...> wrote:
if its eSDK then you can, with standard application SDK not so much. Best regards
|
|
|
|
Re: googletest shared library
look into package-split/ directory inside googletest build area and
toggle quoted messageShow quoted text
see how things changes when you use SOLIBS option. I wonder why its ignoring .h files
On Thu, Sep 23, 2021 at 6:36 AM Lijun Chen <lijchen@...> wrote:
|
|
|
|
Re: Minutes: Yocto Project Weekly Triage Meeting 9/23/2021
Richard Purdie
On Thu, 2021-09-23 at 11:40 -0400, Trevor Gamblin wrote:
I did look at it. It was using a modified oe-selftest with threading instead of multiprocess. We're not using that so I closed it. Cheers, Richard
|
|
|