|
Re: [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report
Hi All,
A gentle reminder to review this patch.
-----------------------
Thanks & Regards,Milan Shah MontaVista Software, Bangalore, India
On Mon, Jan 11, 2021 at 6:45 PM Milan Shah < mshah@...> wrote: Hi All,
This is a Gentle Reminder to review this Patch.
-----------------------
Thanks & Regards,Milan Shah MontaVista Software, Bangalore, India
On Wed, Jan 6, 2021 at 7:09 PM Milan Shah < mshah@...> wrote: Instead of just providing local.conf info, add layer names and their
revisions with bitbake version information into error report
makes it easier to understand and reproduce failed build.
[YOCTO #9700]
Signed-off-by: Milan Shah <mshah@...>
---
meta/classes/report-error.bbclass | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/meta/classes/report-error.bbclass b/meta/classes/report-error.bbclass
index 1a12db1..9cb6b0b 100644
--- a/meta/classes/report-error.bbclass
+++ b/meta/classes/report-error.bbclass
@@ -6,6 +6,8 @@
#
# Licensed under the MIT license, see COPYING.MIT for details
+inherit base
+
ERR_REPORT_DIR ?= "${LOG_DIR}/error-report"
def errorreport_getdata(e):
@@ -64,6 +66,8 @@ python errorreport_handler () {
data['failures'] = []
data['component'] = " ".join(e.getPkgs())
data['branch_commit'] = str(base_detect_branch(e.data)) + ": " + str(base_detect_revision(e.data))
+ data['bitbake_version'] = e.data.getVar("BB_VERSION")
+ data['layer_version'] = get_layers_branch_rev(e.data)
data['local_conf'] = get_conf_data(e, 'local.conf')
data['auto_conf'] = get_conf_data(e, 'auto.conf')
lock = bb.utils.lockfile(datafile + '.lock')
--
2.7.4
|
|
|
Re: Writing a BSP from downstream kernel sources
Thanks Aaron!
That seems to remove the log2 warnings, but it seems like they were not related to those "Assembler" errors, e.g.:
``` | /tmp/ccbtfgo7.s: Assembler messages:
| /tmp/ccbtfgo7.s:2011: Error: .err encountered
```
I think I need to fix them like Diego was suggesting, but I have trouble relating the error to a source file...
On Sat, Jan 30, 2021 at 8:29 AM Aaron Cohen < aaron@...> wrote: Actually, I found the upstream patch I backported, which you're probably better off using (same diff though).
I'm not sure if this is your issue, but I had a similar issue ilog2 and the disassembler and fixed it by backporting this patch.
No guarantees, but perhaps it will help.
--Aaron
Thanks a lot for the advice! However, I can't seem to find a `const` that I can simply remove. To give more context, here is the log output around such an error (it seems like it is often surrounded by this log2.h warning, by the way):
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/ftrace.h:10,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/kernel/extable.c:18:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| CC fs/fat/dir.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/list.h:8,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/module.h:9,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/fs/fat/dir.c:16:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| CC block/deadline-iosched.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/block/deadline-iosched.c:6:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| /tmp/cc52vFrQ.s: Assembler messages:
| /tmp/cc52vFrQ.s:2683: Error: .err encountered
| /tmp/cc52vFrQ.s:2927: Error: .err encountered
| LD sound/sparc/built-in.o
| LD sound/spi/built-in.o
| make[3]: *** [/home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/scripts/Makefile.build:257: block/scsi_ioctl.o] Error 1
``` extern __attribute__((const, noreturn)) int ____ilog2_NaN(void); ```
So there is a const there, but well... not sure what to do with it :-).
Best,
Just to close this: it seems like the gcc-cross-arm used by yocto gatesgarth is too new for that specific downstream kernel (3.18.31).
The goal was to get a proper BSP package for this device for a modern yocto, so I don't think I will try with an older version of Yocto. If I compile an old gcc as part of a custom Yocto layer (on gatesgarth), I am guessing that I will
have issues creating a distro that runs both on RPi and on that older device (because RPi will have a newer kernel and gcc, and the skycontroller will use older ones). I also guess that the downstream dts won't work with a modern kernel, and I would not know
how to write one myself for that apq8009 chip.
Hence, I'm giving up. Thanks a lot for the help :-).
[Diego Santa Cruz] Wait! You may be able to get it working, see below.
Thanks a lot for the answer!
It seems like using `KCONFIG_MODE = "--alldefconfig"` with `KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of errors as when I use the defconfig from the downstream kernel [1], i.e.:
[Diego Santa Cruz] I happen to be doing a similar kind of work, getting an even older (2.6.37+) downstream kernel for an ARM machine to compile with recent GCC in Yocto, in my case GCC 9.3 from dunfell. There are a few fixes and backports
necessary to make it happen and boot. I’m not done with the work yet, so I do not know how stable it is, but I have it booting.
| /tmp/ccz8jKgm.s: Assembler messages:
| /tmp/ccz8jKgm.s:985: Error: .err encountered
```
[Diego Santa Cruz] The fix here is rather simple once you understand what’s going on, the problem is abusive use of const for register variables, see
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Local-Register-Variables.html so when put_user() is used for a literal constant value it gets assigned the wrong register, so just remove the const qualifier from the put_user() register variable assignment for
the value argument. For my older kernel the patch is like this.
--- arch/arm/include/asm/uaccess.h
+++ arch/arm/include/asm/uaccess.h
@@ -145,7 +145,7 @@
#define put_user(x,p) \
({ \
- register const typeof(*(p)) __r2 asm("r2") = (x); \
+ register typeof(*(p)) __r2 asm("r2") = (x); \
register const typeof(*(p)) __user *__p asm("r0") = (p);\
register int __e asm("r0"); \
switch (sizeof(*(__p))) { \
Could it be related to the tuning, e.g. I'm somehow defining a wrong toolchain in my machine configuration [2] and it fails to build? I was thinking about the tune-cortexa7.inc include, though it seems to me that the apq8009 is a cortexa7
[3]:
[Diego Santa Cruz] Other commits from post 3.18 that you may need to backport are the following (start from bottom of list)
474c90156c8dcc2fa815e6716cc9394d7930cb9c give up on gcc ilog2() constant optimizations
cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the various compiler-gcc[345].h files
f6d133f877c8bb0a0934dc8c521c758ee771e901 compiler-gcc.h: neatening
7829fb09a2b4268b30dd9bc782fa5ebee278b137 lib: make memzero_explicit more robust against dead store elimination
cb4188ac8e5779f66b9f55888ac2c75b391cde44 compiler: introduce __alias(symbol) shortcut
0b053c9518292705736329a8fe20ef4686ffc8e9 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR
ee91ef6173e81819f5ff610c2485802081635657 bufferhead: force inlining of buffer head flag operations
cc7fce80229067890365c1ee196be5d304d36dea mtd: blkdevs: fix switch-bool compilation warning
> The Qualcomm Snapdragon 212 APQ8009 is an entry level SoC for Android based tablets and smartphones. It contains four ARM Cortex-A7 CPU cores (quad core)
On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <pbarker@...> wrote:
On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> wrote:
>
> As a learning experience, I am trying to create a BSP for a device I own and whose downstream kernel is published. The device in question is the Parrot Skycontroller3, and the sources are available here.
>
> Let me start by sharing my issue. When I build the kernel with `bitbake virtual/kernel`, it fails with errors like:
>
> ```
> | AS arch/arm/lib/backtrace.o
> | AS arch/arm/lib/bswapsdi2.o
> | AS arch/arm/lib/call_with_stack.o
> | /tmp/ccz8jKgm.s: Assembler messages:
> | /tmp/ccz8jKgm.s:985: Error: .err encountered
> | /tmp/ccz8jKgm.s:1033: Error: .err encountered
> | /tmp/ccz8jKgm.s:6812: Error: .err encountered
> ```
>
> My layer is available here.
>
> I created it getting inspiration from meta-raspberrypi and meta-qti-bsp, which seems to have the same CPU: apq8009. According to the Parrot sources, my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, I use as a defconfig file the linux.config that
is available in the Parrot sources (I copied it in my kernel recipe under `files/defconfig` and added it to SRC_URI).
>
> The Parrot sources also refer to `LINUX_DEFAULT_CONFIG_TARGET := msm8909_defconfig`, so I tried to set `KBUILD_DEFCONFIG = "msm8909_defconfig"`, but that is failing with different errors, such as:
>
> ```
> error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function); did you mean 'DMA_ATTR_NON_CONSISTENT'?
> ```
>
> or
>
> ```
> error: 'L_PTE_YOUNG' undeclared
> ```
>
> As a side note, their `drivers/Kconfig` seemed invalid, so I patched it.
>
> I am a bit lost now, not completely sure where my issues come from. I realize that changing the defconfig has quite some impact (I get different errors), and also that my machine configuration may be completely wrong (I am essentially guessing from the fact
that it is an apq8009/msm8909, but for instance the tuning I just copied from meta-qti-bsp, which may be invalid).
>
> I would be glad if I could get hints about debugging this. Again, it is really a learning project: I would like to learn how to create a BSP from a downstream kernel.
I think setting `KBUILD_DEFCONFIG = "msm8909_defconfig"` is likely the
correct approach here. What you may be missing though is the correct
value for KCONFIG_MODE. By default, the supplied defconfig file is
copied to .config but dependencies between config options aren't
resolved. You need to set `KCONFIG_MODE = "--alldefconfig"` to get the
equivalent of `make msm8909_defconfig` to occur. See
https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L19
for an idea of how this is done for Raspberry Pi.
Thanks,
--
Paul Barker
Konsulko Group
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com
|
|
|
Re: [OE-core] [yocto] QA notification for completed autobuilder build (yocto-3.3_M2.rc1)
|
|
|
U RAVI KUMAR <uppadaravi2511@...>
Hello folks,
I want to build a qtweb browser using the QT creator, And embed the browser in the core-image-sato.Can anyone pls suggest to me is it possible to do that. If yes pls guide me.
Thanks, RAVI_UPPADA
|
|
|
oddity: file_5.37 printing unexpected "octet-stream" mime type for ISO
(i asked about this on the OE list a couple days ago, but i have more info and wanted to get a bit wider coverage as i really, really want to de-mystify this issue.) on current project, upgrading from wind river WRL9 to LTS19 (effectively morty to zeus) involves going from file_5.28 to file_5.37 recipe, which is used by various install and upgrade scripts to validate something is an actual ISO image by checking its mime type (not the way i would have done it, but it's done). in WRL9, the mime type of an ISO image as printed by "file -i" included the string "application/x-iso9660-image", and that's what these scripts use to "verify" ISOness. so far, so good. suddenly, in LTS19, the very same "file -i" invocation instead prints "application/octet-stream" -- this very same weirdness was noticed elsewhere, like here in ubuntu launchpad: https://bugs.launchpad.net/ubuntu/+source/file/+bug/1763570that bug report describes *precisely* the behaviour we're seeing. it's hard to believe the "file" command could have been that broken so i looked around for another explanation, and noticed that any single file could match multiple mime types, and that the file command had a "--keep-going" option, so my colleague tried that and, sure enough: # file -i --keep-going /var/tmp/ptx.iso /var/tmp/ptx.iso: application/x-iso9660-imageapplication/x-dosexec\012- application/octet-stream; charset=binary so now we see both mime types being displayed, but it's not feasible to change all the scripts to add the "--keep-going" option so i'm baffled as to why the newer file command suddenly decides to print "octet-stream" as the mime type rather than the more precise "x-iso9669-image". more puzzlingly, the man page for the command states: -k, --keep-going Don't stop at the first match, keep going. Subsequent matches will be have the string ‘\012- ’ prepended. (If you want a newline, see the -r option.) The magic pat‐ tern with the highest strength (see the -l option) comes first. hang on ... if the pattern with the highest strength is allegedly printed first, in the above, that is "x-iso9660-iamge", so why would that not be the single mime type displayed by a normal invocation? has anyone else seen this? can it be reproduced? i'll try the latest version of file later this weekend, but i'm open to assistance since this weirdness is currently breaking all sorts of install and upgrade procedures. rday
|
|
|
Re: Writing a BSP from downstream kernel sources
Actually, I found the upstream patch I backported, which you're probably better off using (same diff though).
I'm not sure if this is your issue, but I had a similar issue ilog2 and the disassembler and fixed it by backporting this patch.
No guarantees, but perhaps it will help.
--Aaron
Thanks a lot for the advice! However, I can't seem to find a `const` that I can simply remove. To give more context, here is the log output around such an error (it seems like it is often surrounded by this log2.h warning, by the way):
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/ftrace.h:10,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/kernel/extable.c:18:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| CC fs/fat/dir.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/list.h:8,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/module.h:9,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/fs/fat/dir.c:16:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| CC block/deadline-iosched.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/block/deadline-iosched.c:6:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| /tmp/cc52vFrQ.s: Assembler messages:
| /tmp/cc52vFrQ.s:2683: Error: .err encountered
| /tmp/cc52vFrQ.s:2927: Error: .err encountered
| LD sound/sparc/built-in.o
| LD sound/spi/built-in.o
| make[3]: *** [/home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/scripts/Makefile.build:257: block/scsi_ioctl.o] Error 1
``` extern __attribute__((const, noreturn)) int ____ilog2_NaN(void); ```
So there is a const there, but well... not sure what to do with it :-).
Best,
Just to close this: it seems like the gcc-cross-arm used by yocto gatesgarth is too new for that specific downstream kernel (3.18.31).
The goal was to get a proper BSP package for this device for a modern yocto, so I don't think I will try with an older version of Yocto. If I compile an old gcc as part of a custom Yocto layer (on gatesgarth), I am guessing that I will
have issues creating a distro that runs both on RPi and on that older device (because RPi will have a newer kernel and gcc, and the skycontroller will use older ones). I also guess that the downstream dts won't work with a modern kernel, and I would not know
how to write one myself for that apq8009 chip.
Hence, I'm giving up. Thanks a lot for the help :-).
[Diego Santa Cruz] Wait! You may be able to get it working, see below.
Thanks a lot for the answer!
It seems like using `KCONFIG_MODE = "--alldefconfig"` with `KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of errors as when I use the defconfig from the downstream kernel [1], i.e.:
[Diego Santa Cruz] I happen to be doing a similar kind of work, getting an even older (2.6.37+) downstream kernel for an ARM machine to compile with recent GCC in Yocto, in my case GCC 9.3 from dunfell. There are a few fixes and backports
necessary to make it happen and boot. I’m not done with the work yet, so I do not know how stable it is, but I have it booting.
| /tmp/ccz8jKgm.s: Assembler messages:
| /tmp/ccz8jKgm.s:985: Error: .err encountered
```
[Diego Santa Cruz] The fix here is rather simple once you understand what’s going on, the problem is abusive use of const for register variables, see
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Local-Register-Variables.html so when put_user() is used for a literal constant value it gets assigned the wrong register, so just remove the const qualifier from the put_user() register variable assignment for
the value argument. For my older kernel the patch is like this.
--- arch/arm/include/asm/uaccess.h
+++ arch/arm/include/asm/uaccess.h
@@ -145,7 +145,7 @@
#define put_user(x,p) \
({ \
- register const typeof(*(p)) __r2 asm("r2") = (x); \
+ register typeof(*(p)) __r2 asm("r2") = (x); \
register const typeof(*(p)) __user *__p asm("r0") = (p);\
register int __e asm("r0"); \
switch (sizeof(*(__p))) { \
Could it be related to the tuning, e.g. I'm somehow defining a wrong toolchain in my machine configuration [2] and it fails to build? I was thinking about the tune-cortexa7.inc include, though it seems to me that the apq8009 is a cortexa7
[3]:
[Diego Santa Cruz] Other commits from post 3.18 that you may need to backport are the following (start from bottom of list)
474c90156c8dcc2fa815e6716cc9394d7930cb9c give up on gcc ilog2() constant optimizations
cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the various compiler-gcc[345].h files
f6d133f877c8bb0a0934dc8c521c758ee771e901 compiler-gcc.h: neatening
7829fb09a2b4268b30dd9bc782fa5ebee278b137 lib: make memzero_explicit more robust against dead store elimination
cb4188ac8e5779f66b9f55888ac2c75b391cde44 compiler: introduce __alias(symbol) shortcut
0b053c9518292705736329a8fe20ef4686ffc8e9 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR
ee91ef6173e81819f5ff610c2485802081635657 bufferhead: force inlining of buffer head flag operations
cc7fce80229067890365c1ee196be5d304d36dea mtd: blkdevs: fix switch-bool compilation warning
> The Qualcomm Snapdragon 212 APQ8009 is an entry level SoC for Android based tablets and smartphones. It contains four ARM Cortex-A7 CPU cores (quad core)
On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <pbarker@...> wrote:
On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> wrote:
>
> As a learning experience, I am trying to create a BSP for a device I own and whose downstream kernel is published. The device in question is the Parrot Skycontroller3, and the sources are available here.
>
> Let me start by sharing my issue. When I build the kernel with `bitbake virtual/kernel`, it fails with errors like:
>
> ```
> | AS arch/arm/lib/backtrace.o
> | AS arch/arm/lib/bswapsdi2.o
> | AS arch/arm/lib/call_with_stack.o
> | /tmp/ccz8jKgm.s: Assembler messages:
> | /tmp/ccz8jKgm.s:985: Error: .err encountered
> | /tmp/ccz8jKgm.s:1033: Error: .err encountered
> | /tmp/ccz8jKgm.s:6812: Error: .err encountered
> ```
>
> My layer is available here.
>
> I created it getting inspiration from meta-raspberrypi and meta-qti-bsp, which seems to have the same CPU: apq8009. According to the Parrot sources, my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, I use as a defconfig file the linux.config that
is available in the Parrot sources (I copied it in my kernel recipe under `files/defconfig` and added it to SRC_URI).
>
> The Parrot sources also refer to `LINUX_DEFAULT_CONFIG_TARGET := msm8909_defconfig`, so I tried to set `KBUILD_DEFCONFIG = "msm8909_defconfig"`, but that is failing with different errors, such as:
>
> ```
> error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function); did you mean 'DMA_ATTR_NON_CONSISTENT'?
> ```
>
> or
>
> ```
> error: 'L_PTE_YOUNG' undeclared
> ```
>
> As a side note, their `drivers/Kconfig` seemed invalid, so I patched it.
>
> I am a bit lost now, not completely sure where my issues come from. I realize that changing the defconfig has quite some impact (I get different errors), and also that my machine configuration may be completely wrong (I am essentially guessing from the fact
that it is an apq8009/msm8909, but for instance the tuning I just copied from meta-qti-bsp, which may be invalid).
>
> I would be glad if I could get hints about debugging this. Again, it is really a learning project: I would like to learn how to create a BSP from a downstream kernel.
I think setting `KBUILD_DEFCONFIG = "msm8909_defconfig"` is likely the
correct approach here. What you may be missing though is the correct
value for KCONFIG_MODE. By default, the supplied defconfig file is
copied to .config but dependencies between config options aren't
resolved. You need to set `KCONFIG_MODE = "--alldefconfig"` to get the
equivalent of `make msm8909_defconfig` to occur. See
https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L19
for an idea of how this is done for Raspberry Pi.
Thanks,
--
Paul Barker
Konsulko Group
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com
|
|
|
Re: Writing a BSP from downstream kernel sources
I'm not sure if this is your issue, but I had a similar issue ilog2 and the disassembler and fixed it by backporting this patch.
No guarantees, but perhaps it will help.
--Aaron
Thanks a lot for the advice! However, I can't seem to find a `const` that I can simply remove. To give more context, here is the log output around such an error (it seems like it is often surrounded by this log2.h warning, by the way):
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/ftrace.h:10,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/kernel/extable.c:18:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| CC fs/fat/dir.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/list.h:8,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/module.h:9,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/fs/fat/dir.c:16:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| CC block/deadline-iosched.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/block/deadline-iosched.c:6:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| /tmp/cc52vFrQ.s: Assembler messages:
| /tmp/cc52vFrQ.s:2683: Error: .err encountered
| /tmp/cc52vFrQ.s:2927: Error: .err encountered
| LD sound/sparc/built-in.o
| LD sound/spi/built-in.o
| make[3]: *** [/home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/scripts/Makefile.build:257: block/scsi_ioctl.o] Error 1
``` extern __attribute__((const, noreturn)) int ____ilog2_NaN(void); ```
So there is a const there, but well... not sure what to do with it :-).
Best,
Just to close this: it seems like the gcc-cross-arm used by yocto gatesgarth is too new for that specific downstream kernel (3.18.31).
The goal was to get a proper BSP package for this device for a modern yocto, so I don't think I will try with an older version of Yocto. If I compile an old gcc as part of a custom Yocto layer (on gatesgarth), I am guessing that I will
have issues creating a distro that runs both on RPi and on that older device (because RPi will have a newer kernel and gcc, and the skycontroller will use older ones). I also guess that the downstream dts won't work with a modern kernel, and I would not know
how to write one myself for that apq8009 chip.
Hence, I'm giving up. Thanks a lot for the help :-).
[Diego Santa Cruz] Wait! You may be able to get it working, see below.
Thanks a lot for the answer!
It seems like using `KCONFIG_MODE = "--alldefconfig"` with `KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of errors as when I use the defconfig from the downstream kernel [1], i.e.:
[Diego Santa Cruz] I happen to be doing a similar kind of work, getting an even older (2.6.37+) downstream kernel for an ARM machine to compile with recent GCC in Yocto, in my case GCC 9.3 from dunfell. There are a few fixes and backports
necessary to make it happen and boot. I’m not done with the work yet, so I do not know how stable it is, but I have it booting.
| /tmp/ccz8jKgm.s: Assembler messages:
| /tmp/ccz8jKgm.s:985: Error: .err encountered
```
[Diego Santa Cruz] The fix here is rather simple once you understand what’s going on, the problem is abusive use of const for register variables, see
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Local-Register-Variables.html so when put_user() is used for a literal constant value it gets assigned the wrong register, so just remove the const qualifier from the put_user() register variable assignment for
the value argument. For my older kernel the patch is like this.
--- arch/arm/include/asm/uaccess.h
+++ arch/arm/include/asm/uaccess.h
@@ -145,7 +145,7 @@
#define put_user(x,p) \
({ \
- register const typeof(*(p)) __r2 asm("r2") = (x); \
+ register typeof(*(p)) __r2 asm("r2") = (x); \
register const typeof(*(p)) __user *__p asm("r0") = (p);\
register int __e asm("r0"); \
switch (sizeof(*(__p))) { \
Could it be related to the tuning, e.g. I'm somehow defining a wrong toolchain in my machine configuration [2] and it fails to build? I was thinking about the tune-cortexa7.inc include, though it seems to me that the apq8009 is a cortexa7
[3]:
[Diego Santa Cruz] Other commits from post 3.18 that you may need to backport are the following (start from bottom of list)
474c90156c8dcc2fa815e6716cc9394d7930cb9c give up on gcc ilog2() constant optimizations
cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the various compiler-gcc[345].h files
f6d133f877c8bb0a0934dc8c521c758ee771e901 compiler-gcc.h: neatening
7829fb09a2b4268b30dd9bc782fa5ebee278b137 lib: make memzero_explicit more robust against dead store elimination
cb4188ac8e5779f66b9f55888ac2c75b391cde44 compiler: introduce __alias(symbol) shortcut
0b053c9518292705736329a8fe20ef4686ffc8e9 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR
ee91ef6173e81819f5ff610c2485802081635657 bufferhead: force inlining of buffer head flag operations
cc7fce80229067890365c1ee196be5d304d36dea mtd: blkdevs: fix switch-bool compilation warning
> The Qualcomm Snapdragon 212 APQ8009 is an entry level SoC for Android based tablets and smartphones. It contains four ARM Cortex-A7 CPU cores (quad core)
On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <pbarker@...> wrote:
On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> wrote:
>
> As a learning experience, I am trying to create a BSP for a device I own and whose downstream kernel is published. The device in question is the Parrot Skycontroller3, and the sources are available here.
>
> Let me start by sharing my issue. When I build the kernel with `bitbake virtual/kernel`, it fails with errors like:
>
> ```
> | AS arch/arm/lib/backtrace.o
> | AS arch/arm/lib/bswapsdi2.o
> | AS arch/arm/lib/call_with_stack.o
> | /tmp/ccz8jKgm.s: Assembler messages:
> | /tmp/ccz8jKgm.s:985: Error: .err encountered
> | /tmp/ccz8jKgm.s:1033: Error: .err encountered
> | /tmp/ccz8jKgm.s:6812: Error: .err encountered
> ```
>
> My layer is available here.
>
> I created it getting inspiration from meta-raspberrypi and meta-qti-bsp, which seems to have the same CPU: apq8009. According to the Parrot sources, my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, I use as a defconfig file the linux.config that
is available in the Parrot sources (I copied it in my kernel recipe under `files/defconfig` and added it to SRC_URI).
>
> The Parrot sources also refer to `LINUX_DEFAULT_CONFIG_TARGET := msm8909_defconfig`, so I tried to set `KBUILD_DEFCONFIG = "msm8909_defconfig"`, but that is failing with different errors, such as:
>
> ```
> error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function); did you mean 'DMA_ATTR_NON_CONSISTENT'?
> ```
>
> or
>
> ```
> error: 'L_PTE_YOUNG' undeclared
> ```
>
> As a side note, their `drivers/Kconfig` seemed invalid, so I patched it.
>
> I am a bit lost now, not completely sure where my issues come from. I realize that changing the defconfig has quite some impact (I get different errors), and also that my machine configuration may be completely wrong (I am essentially guessing from the fact
that it is an apq8009/msm8909, but for instance the tuning I just copied from meta-qti-bsp, which may be invalid).
>
> I would be glad if I could get hints about debugging this. Again, it is really a learning project: I would like to learn how to create a BSP from a downstream kernel.
I think setting `KBUILD_DEFCONFIG = "msm8909_defconfig"` is likely the
correct approach here. What you may be missing though is the correct
value for KCONFIG_MODE. By default, the supplied defconfig file is
copied to .config but dependencies between config options aren't
resolved. You need to set `KCONFIG_MODE = "--alldefconfig"` to get the
equivalent of `make msm8909_defconfig` to occur. See
https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L19
for an idea of how this is done for Raspberry Pi.
Thanks,
--
Paul Barker
Konsulko Group
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com
|
|
|
Re: [meta-rockchip][PATCH v2] rock-pi-4: Split our variant machines
|
|
|
Re: Writing a BSP from downstream kernel sources
Thanks a lot for the advice! However, I can't seem to find a `const` that I can simply remove. To give more context, here is the log output around such an error (it seems like it is often surrounded by this log2.h warning, by the way):
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kallsyms.h:9,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/ftrace.h:10,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/kernel/extable.c:18:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| CC fs/fat/dir.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/list.h:8,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/module.h:9,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/fs/fat/dir.c:16:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| CC block/deadline-iosched.o
| In file included from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/kernel.h:11,
| from /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/block/deadline-iosched.c:6:
| /home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/include/linux/log2.h:22:1: warning: ignoring attribute 'noreturn' because it conflicts with attribute 'const' [-Wattributes]
| 22 | int ____ilog2_NaN(void);
| | ^~~
| /tmp/cc52vFrQ.s: Assembler messages:
| /tmp/cc52vFrQ.s:2683: Error: .err encountered
| /tmp/cc52vFrQ.s:2927: Error: .err encountered
| LD sound/sparc/built-in.o
| LD sound/spi/built-in.o
| make[3]: *** [/home/jones/Documents/yocto/poky/build/tmp/work-shared/skycontroller3/kernel-source/scripts/Makefile.build:257: block/scsi_ioctl.o] Error 1
``` extern __attribute__((const, noreturn)) int ____ilog2_NaN(void); ```
So there is a const there, but well... not sure what to do with it :-).
Best,
Just to close this: it seems like the gcc-cross-arm used by yocto gatesgarth is too new for that specific downstream kernel (3.18.31).
The goal was to get a proper BSP package for this device for a modern yocto, so I don't think I will try with an older version of Yocto. If I compile an old gcc as part of a custom Yocto layer (on gatesgarth), I am guessing that I will
have issues creating a distro that runs both on RPi and on that older device (because RPi will have a newer kernel and gcc, and the skycontroller will use older ones). I also guess that the downstream dts won't work with a modern kernel, and I would not know
how to write one myself for that apq8009 chip.
Hence, I'm giving up. Thanks a lot for the help :-).
[Diego Santa Cruz] Wait! You may be able to get it working, see below.
Thanks a lot for the answer!
It seems like using `KCONFIG_MODE = "--alldefconfig"` with `KBUILD_DEFCONFIG = "msm8909_defconfig"` now ends up with the same kind of errors as when I use the defconfig from the downstream kernel [1], i.e.:
[Diego Santa Cruz] I happen to be doing a similar kind of work, getting an even older (2.6.37+) downstream kernel for an ARM machine to compile with recent GCC in Yocto, in my case GCC 9.3 from dunfell. There are a few fixes and backports
necessary to make it happen and boot. I’m not done with the work yet, so I do not know how stable it is, but I have it booting.
| /tmp/ccz8jKgm.s: Assembler messages:
| /tmp/ccz8jKgm.s:985: Error: .err encountered
```
[Diego Santa Cruz] The fix here is rather simple once you understand what’s going on, the problem is abusive use of const for register variables, see
https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Local-Register-Variables.html so when put_user() is used for a literal constant value it gets assigned the wrong register, so just remove the const qualifier from the put_user() register variable assignment for
the value argument. For my older kernel the patch is like this.
--- arch/arm/include/asm/uaccess.h
+++ arch/arm/include/asm/uaccess.h
@@ -145,7 +145,7 @@
#define put_user(x,p) \
({ \
- register const typeof(*(p)) __r2 asm("r2") = (x); \
+ register typeof(*(p)) __r2 asm("r2") = (x); \
register const typeof(*(p)) __user *__p asm("r0") = (p);\
register int __e asm("r0"); \
switch (sizeof(*(__p))) { \
Could it be related to the tuning, e.g. I'm somehow defining a wrong toolchain in my machine configuration [2] and it fails to build? I was thinking about the tune-cortexa7.inc include, though it seems to me that the apq8009 is a cortexa7
[3]:
[Diego Santa Cruz] Other commits from post 3.18 that you may need to backport are the following (start from bottom of list)
474c90156c8dcc2fa815e6716cc9394d7930cb9c give up on gcc ilog2() constant optimizations
cb984d101b30eb7478d32df56a0023e4603cba7f compiler-gcc: integrate the various compiler-gcc[345].h files
f6d133f877c8bb0a0934dc8c521c758ee771e901 compiler-gcc.h: neatening
7829fb09a2b4268b30dd9bc782fa5ebee278b137 lib: make memzero_explicit more robust against dead store elimination
cb4188ac8e5779f66b9f55888ac2c75b391cde44 compiler: introduce __alias(symbol) shortcut
0b053c9518292705736329a8fe20ef4686ffc8e9 lib: memzero_explicit: use barrier instead of OPTIMIZER_HIDE_VAR
ee91ef6173e81819f5ff610c2485802081635657 bufferhead: force inlining of buffer head flag operations
cc7fce80229067890365c1ee196be5d304d36dea mtd: blkdevs: fix switch-bool compilation warning
> The Qualcomm Snapdragon 212 APQ8009 is an entry level SoC for Android based tablets and smartphones. It contains four ARM Cortex-A7 CPU cores (quad core)
On Sat, Jan 23, 2021 at 11:06 AM Paul Barker <pbarker@...> wrote:
On Sat, 23 Jan 2021 at 02:29, Jonas Vautherin <jonas.vautherin@...> wrote:
>
> As a learning experience, I am trying to create a BSP for a device I own and whose downstream kernel is published. The device in question is the Parrot Skycontroller3, and the sources are available here.
>
> Let me start by sharing my issue. When I build the kernel with `bitbake virtual/kernel`, it fails with errors like:
>
> ```
> | AS arch/arm/lib/backtrace.o
> | AS arch/arm/lib/bswapsdi2.o
> | AS arch/arm/lib/call_with_stack.o
> | /tmp/ccz8jKgm.s: Assembler messages:
> | /tmp/ccz8jKgm.s:985: Error: .err encountered
> | /tmp/ccz8jKgm.s:1033: Error: .err encountered
> | /tmp/ccz8jKgm.s:6812: Error: .err encountered
> ```
>
> My layer is available here.
>
> I created it getting inspiration from meta-raspberrypi and meta-qti-bsp, which seems to have the same CPU: apq8009. According to the Parrot sources, my device runs a Qualcomm apq8009/msm89090 cpu. In my repo, I use as a defconfig file the linux.config that
is available in the Parrot sources (I copied it in my kernel recipe under `files/defconfig` and added it to SRC_URI).
>
> The Parrot sources also refer to `LINUX_DEFAULT_CONFIG_TARGET := msm8909_defconfig`, so I tried to set `KBUILD_DEFCONFIG = "msm8909_defconfig"`, but that is failing with different errors, such as:
>
> ```
> error: 'VM_ARM_DMA_CONSISTENT' undeclared (first use in this function); did you mean 'DMA_ATTR_NON_CONSISTENT'?
> ```
>
> or
>
> ```
> error: 'L_PTE_YOUNG' undeclared
> ```
>
> As a side note, their `drivers/Kconfig` seemed invalid, so I patched it.
>
> I am a bit lost now, not completely sure where my issues come from. I realize that changing the defconfig has quite some impact (I get different errors), and also that my machine configuration may be completely wrong (I am essentially guessing from the fact
that it is an apq8009/msm8909, but for instance the tuning I just copied from meta-qti-bsp, which may be invalid).
>
> I would be glad if I could get hints about debugging this. Again, it is really a learning project: I would like to learn how to create a BSP from a downstream kernel.
I think setting `KBUILD_DEFCONFIG = "msm8909_defconfig"` is likely the
correct approach here. What you may be missing though is the correct
value for KCONFIG_MODE. By default, the supplied defconfig file is
copied to .config but dependencies between config options aren't
resolved. You need to set `KCONFIG_MODE = "--alldefconfig"` to get the
equivalent of `make msm8909_defconfig` to occur. See
https://github.com/agherzan/meta-raspberrypi/blob/master/recipes-kernel/linux/linux-raspberrypi.inc#L19
for an idea of how this is done for Raspberry Pi.
Thanks,
--
Paul Barker
Konsulko Group
--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com
|
|
|
I need some help in understanding why the SDK EXT is failing to build under zeus…
Can someone explain why the extended sdk build fails and how I might resolve ?
sbcb-defaultfs kernel builds and boots correctly…
SDK builds under zeus for sbcb-defaultfs :
bitbake sbcb-defaultfs-full -c populate_sdk -WORKING CORRECTLY
bitbake sbcb-defaultfs-full -c populate_sdk_ext -Fails build with the following Errors:
17:13 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default> bitbake sbcb-defaultfs-full -c populate_sdk_ext
Loading cache: 100% |###########################################################| Time: 0:00:00
Loaded 3645 entries from dependency cache.
NOTE: Resolving any missing task queue dependencies
Build Configuration:
BB_VERSION = "1.44.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "rhel-7.9"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "sbcb-default"
DISTRO = "limws"
DISTRO_VERSION = "3.0.4"
TUNE_FEATURES = "m64 corei7"
TARGET_FPU = ""
meta
meta-poky = "my_yocto_3.0.4:f2eb22a8783f1eecf99bd4042695bab920eed00e"
meta-perl
meta-python
meta-filesystems
meta-networking
meta-initramfs
meta-oe = "zeus:2b5dd1eb81cd08bc065bc76125f2856e9383e98b"
meta = "master:a32ddd2b2a51b26c011fa50e441df39304651503"
meta-intel = "zeus:d9942d4c3a710406b051852de7232db03c297f4e"
meta-intel
workspace = "v2019.02:f635a364c55f1fb12519aff54924a0a5b947091e"
Initialising tasks: 100% |######################################################| Time: 0:00:04
Checking sstate mirror object availability: 100% |##############################| Time: 0:00:00
Sstate summary: Wanted 503 Found 298 Missed 205 Current 1936 (59% match, 91% complete)
NOTE: Executing Tasks
NOTE: Setscene tasks completed
WARNING: rpcsvc-proto-native-1.4+gitAUTOINC+9bc3b5b785-r0 do_fetch: Failed to fetch URL git://github.com/thkukuk/rpcsvc-proto, attempting MIRRORS if available
WARNING: nativesdk-libnss-nis-3.1+gitAUTOINC+062f31999b-r0 do_fetch: Failed to fetch URL git://github.com/thkukuk/libnss_nis, attempting MIRRORS if available
NOTE: Excluding local workspace layer /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/workspace from extensible SDK
ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Failed to generate filtered task list for extensible SDK:
/bin/bash: line 0: .: .: is a directory
ERROR: bitbake failed:
/bin/sh: bitbake: command not found
ERROR: sbcb-defaultfs-full-1.0-r0 do_populate_sdk_ext: Error executing a python function in exec_python_func() autogenerated:
The stack trace of python calls that resulted in this exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
0001:
*** 0002:copy_buildsystem(d)
0003:
File: '/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass', lineno: 444, function: copy_buildsystem
0440: sdk_ext_type = d.getVar('SDK_EXT_TYPE')
0441: if (sdk_ext_type != 'minimal' or sdk_include_toolchain or derivative) and not sdk_include_nativesdk:
0442: # Create the filtered task list used to generate the sstate cache shipped with the SDK
0443: tasklistfn = d.getVar('WORKDIR') + '/tasklist.txt'
*** 0444: create_filtered_tasklist(d, baseoutpath, tasklistfn, conf_initpath)
0445: else:
0446: tasklistfn = None
0447:
0448: if os.path.exists(builddir + '/cache/bb_unihashes.dat'):
File: '/disk0/scratch/smonsees/yocto/workspace_3/poky/meta/classes/populate_sdk_ext.bbclass', lineno: 180, function: create_filtered_tasklist
0176: # Clean out residue of running bitbake, which check_sstate_task_list()
0177: # will effectively do
0178: clean_esdk_builddir(d, sdkbasepath)
0179: finally:
*** 0180: os.replace(sdkbasepath + '/conf/local.conf.bak', sdkbasepath + '/conf/local.conf')
0181:
0182:python copy_buildsystem () {
0183: import re
0184: import shutil
Exception: FileNotFoundError: [Errno 2] No such file or directory: '/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/sdk-ext/image//opt/limws/3.0.4/conf/local.conf.bak'
-> '/disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/sdk-ext/image//opt/limws/3.0.4/conf/local.conf'
ERROR: Logfile of failure stored in: /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default/tmp/work/sbcb_default-poky-linux/sbcb-defaultfs-full/1.0-r0/temp/log.do_populate_sdk_ext.14130
ERROR: Task (/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_populate_sdk_ext) failed with exit code '1'
NOTE: Tasks Summary: Attempted 6770 tasks of which 6274 didn't need to be rerun and 1 failed.
Summary: 1 task failed:
/disk0/scratch/smonsees/yocto/workspace_3/poky/../meta-bae/meta-limws/meta-intel/recipes-core/images/sbcb-defaultfs-full.bb:do_populate_sdk_ext
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
17:49 smonsees@yix490016 /disk0/scratch/smonsees/yocto/workspace_3/meta-bae/meta-limws/builds/sbcb-default>
|
|
|
Re: Task only for target recipe
thanks for the hint :-)
it did it however I run in other problems:
the SHC tool converts the scripts into C files, inherits the CC, CFLAGS and LDFLAGS from environment and compiles them using ${CC}.
This works fine for recipes that cross-compile since CC, CFLAGS and LDFLAGS are defined but stuck when dealing with allarch recipes (They are Not defined).
Is there a way to overcome this?
Cheers
On Thu, 2021-01-28 at 18:53 +0100, Ayoub Zaki via
lists.yoctoproject.org wrote:
> Hello I created a new task that I want to run for every recipe of my
> image but only for target recipes and skip all native, sdk,...
> mytask.bbclass:
>
> addtask do_mytask after do_install
>
> do_mytask() {
> :
> }
>
> do_mytask_class-target() {
>
> bbwarn "mytask"
> :
> }
>
> I added to local.conf :
>
> INHERIT += "mytask"
>
> I don't see it running! what is the proper way to achieve this?
How are you running it? You've said you want it to run after do_install
but not what should trigger it.
Adding "before do_build" to the addtask line for example might trigger
it (do_build is the default task).
Cheers,
Richard
|
|
|
Re: SDKMACHINE and ppc64le issue with latest head?
On Fri, 2021-01-29 at 13:48 -0600, Andrew Geissler wrote:
On Jan 29, 2021, at 10:54 AM, Richard Purdie <richard.purdie@...> wrote:
On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
What was SDKMACHINE set to before? Hey Richard, thanks for the quick response.
We did not have it set. It looks like this recent commit is what
changed things on us:
commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton <ross@...>
Date: Tue Dec 22 17:23:14 2020 +0000
bitbake.conf: default SDKMACHINE to the build host architecture
Looks like I need to submit a patch to y'all to add a ppc64le.conf to
conf/machine-sdk/?
That would likely avoid the failures you're seeing, yes.
I really wish we had better support for ppc64le both for hosts and
targets and had people actively involved/maintaining the ppc support,
its in need of massive modernisation particularly on the target side. Darn, I tried just adding this:
cat meta/conf/machine-sdk/ppc64le.conf
SDK_ARCH = "ppc64le"
ABIEXTENSION_class-nativesdk = ""
I get further but then hit a bunch of fails like this:
ERROR: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb: Unable to determine endianness for architecture '${SDK_ARCH}'
ERROR: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb: Please add your architecture to siteinfo.bbclass
ERROR: Failed to parse recipe: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb
ERROR: /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb: Unable to determine endianness for architecture '${SDK_ARCH}'
ERROR: /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb: Please add your architecture to siteinfo.bbclass
…
I’m did some grepping around but don’t see anything obvious. Why is it not
finding the SDK_ARCH I’ve set in the new conf file?
Wondering if I should just go with my first workaround and set SDKMACHINE=x86_64.
Apparently using that default in the past hasn’t affected our use cases.
SDKMACHINE is the machine to run any SDK that is built on. If you're not building an SDK or eSDK, it won't matter to your use case. BUILD_ARCH is the machine you're building upon which is already being set correctly and unchanged. Cheers, Richard
|
|
|
Re: pypi setuptools based recipe fails ModuleNotFoundError: No module named 'pkg_resources'
#python
Konrad Weihmann <kweihmann@...>
The issue here is that you are overwriting the DEPENDS after the inherit.
Two ways to solve this problem
Either use
DEPENDS = "python3-astropy-helpers"
PYPI_PACKAGE = "astropy"
inherit pypi
or
PYPI_PACKAGE = "astropy"
inherit pypi
DEPENDS += "python3-astropy-helpers"
python3-setuptools doesn't need to be added at all manually as this is done implicitly by setuptools3 class
toggle quoted messageShow quoted text
On 29.01.21 21:41, ddbabich@... wrote: I'm attempting to make a simple bitbake recipe for python3-astropy that inherits from pypi and setuptools3. The very simple recipe is attached.
When I build I'm getting this error:
| import pkg_resources
| ModuleNotFoundError: No module named 'pkg_resources'
| WARNING: exit code 1 from a shell command.
I don't understand this error because I'm using setuptools3 which I believe contains pkg_resources. In desperation I added a "DEPENDS = "python3-setuptools" but that did not help either. I'd appreciate any advice on this.
Thanks
|
|
|
pypi setuptools based recipe fails ModuleNotFoundError: No module named 'pkg_resources'
#python
I'm attempting to make a simple bitbake recipe for python3-astropy that inherits from pypi and setuptools3. The very simple recipe is attached.
When I build I'm getting this error:
| import pkg_resources
| ModuleNotFoundError: No module named 'pkg_resources'
| WARNING: exit code 1 from a shell command.
I don't understand this error because I'm using setuptools3 which I believe contains pkg_resources. In desperation I added a "DEPENDS = "python3-setuptools" but that did not help either. I'd appreciate any advice on this. Thanks
|
|
|
Randy MacLeod
On 2021-01-29 3:11 p.m., Randy MacLeod wrote: Did you figure this out? Oops, I see that Khem has replied to a later email. -- # Randy MacLeod # Wind River Linux
|
|
|
Randy MacLeod
On 2021-01-04 3:43 a.m., safouane maaloul wrote: Bonjour, j'essaye d'ajouter le aom plugin au niveau de la gstreamer1.0-plugins-bad. J'ai basculé sur gatesgarth version. Je commence à faire lebuild. J'avais un problème de lisence. Je l'ai résolu. Et maintenant j'ai un problème "no such file or directory automake-native yocto" et j'arrive pas à la résoudre ? Est-ce que vous pouvez m'aider ? y a t il quelqu'un qui a essayé d'ajouter av1 codec (aom plugins/gstreamer1.0-plugins-bad).
Cordialement,
Safouane.Maaloul Bonjour Safouane.Maaloul, Did you figure this out? The Yocto email list is >99.99% English so please consider translating before posting: Google translate says: Hello, I'm trying to add the aom plugin to the level of the
gstreamer1.0-plugins-bad. I switched to gatesgarth version. I start to
do a build. I had a license problem. I solved it. And now I have a "no
such file or directory automake-native yocto" problem and I can't
solve it? Can you help me ? has anyone tried adding av1 codec (aom
plugins / gstreamer1.0-plugins-bad). I don't use gstreamer but if you answer the following questions, you may get an answer: What version of oe-core/poky are you using? What's the top level commit id? What image are you using and what changes have you made to your local.conf file? If you are only using oe-core or poky and have a reproducible problem and no one helps, you can open a defect as decribed here: http://docs.yoctoproject.org/dev-manual/common-tasks.html#submitting-a-defect-against-the-yocto-project../Randy -- # Randy MacLeod # Wind River Linux
|
|
|
Re: SDKMACHINE and ppc64le issue with latest head?
On Jan 29, 2021, at 10:54 AM, Richard Purdie <richard.purdie@...> wrote:
On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote:
What was SDKMACHINE set to before? Hey Richard, thanks for the quick response.
We did not have it set. It looks like this recent commit is what
changed things on us:
commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton <ross@...>
Date: Tue Dec 22 17:23:14 2020 +0000
bitbake.conf: default SDKMACHINE to the build host architecture
Looks like I need to submit a patch to y'all to add a ppc64le.conf to
conf/machine-sdk/?
That would likely avoid the failures you're seeing, yes.
I really wish we had better support for ppc64le both for hosts and
targets and had people actively involved/maintaining the ppc support,
its in need of massive modernisation particularly on the target side. Darn, I tried just adding this: cat meta/conf/machine-sdk/ppc64le.conf SDK_ARCH = "ppc64le" ABIEXTENSION_class-nativesdk = "" I get further but then hit a bunch of fails like this: ERROR: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb: Unable to determine endianness for architecture '${SDK_ARCH}' ERROR: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb: Please add your architecture to siteinfo.bbclass ERROR: Failed to parse recipe: /home/andrewg/Code/openbmc/meta/recipes-devtools/meson/nativesdk-meson_0.56.0.bb ERROR: /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb: Unable to determine endianness for architecture '${SDK_ARCH}' ERROR: /home/andrewg/Code/openbmc/meta/recipes-graphics/xorg-lib/libxext_1.3.4.bb: Please add your architecture to siteinfo.bbclass … I’m did some grepping around but don’t see anything obvious. Why is it not finding the SDK_ARCH I’ve set in the new conf file? Wondering if I should just go with my first workaround and set SDKMACHINE=x86_64. Apparently using that default in the past hasn’t affected our use cases. Cheers,
Richard
|
|
|
Re: SDKMACHINE and ppc64le issue with latest head?
On Fri, 2021-01-29 at 08:40 -0800, Andrew Geissler wrote: What was SDKMACHINE set to before? Hey Richard, thanks for the quick response.
We did not have it set. It looks like this recent commit is what
changed things on us:
commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton <ross@...>
Date: Tue Dec 22 17:23:14 2020 +0000
bitbake.conf: default SDKMACHINE to the build host architecture
Looks like I need to submit a patch to y'all to add a ppc64le.conf to
conf/machine-sdk/?
That would likely avoid the failures you're seeing, yes. I really wish we had better support for ppc64le both for hosts and targets and had people actively involved/maintaining the ppc support, its in need of massive modernisation particularly on the target side. Cheers, Richard
|
|
|
Re: SDKMACHINE and ppc64le issue with latest head?
> What was SDKMACHINE set to before?
Hey Richard, thanks for the quick response.
We did not have it set. It looks like this recent commit is what changed things on us:
commit c74ec1dd7393b9dc7bec1a3ca2ed0a56fb18d8fb
Author: Ross Burton <ross@...>
Date: Tue Dec 22 17:23:14 2020 +0000
bitbake.conf: default SDKMACHINE to the build host architecture
Looks like I need to submit a patch to y'all to add a ppc64le.conf to conf/machine-sdk/?
|
|
|
Re: SDKMACHINE and ppc64le issue with latest head?
On Fri, 2021-01-29 at 06:38 -0800, Andrew Geissler wrote: Over in OpenBMC, we utilize a mix of x86 and ppc64le machines for our
CI.
Our latest rebase of poky master
(https://gerrit.openbmc-project.xyz/c/openbmc/openbmc/+/39533/) has
started failing to compile on our ppc64le machines with the below
error.
I can workaround it by setting "SDKMACHINE=x86_64" but that seems a
bit weird on a ppc64le machine?
+ bitbake obmc-phosphor-image obmc-phosphor-debug-tarball
ERROR: OE-core's config sanity checker detected a potential
misconfiguration.
Either fix the cause of this error or at your own risk disable
the checker (see sanity.conf).
Following is the list of potential problems / advisories:
Specified SDKMACHINE value is not valid What was SDKMACHINE set to before? Cheers, Richard
|
|
|
