Date   

Re: [OE-core] Let me tell you how I really feel. Zero filter. If you need meta-python2, you need to become a maintainer. Immediately. Period.

Khem Raj
 



On Mon, Feb 1, 2021 at 6:40 AM Martin Jansa <Martin.Jansa@...> wrote:
On Thu, Oct 22, 2020 at 11:37 PM Martin Jansa via lists.yoctoproject.org <Martin.Jansa=gmail.com@...> wrote:
There were only a few changes needed between dunfell and gatesgarth to keep it building and I feel guilty for sending half of them - and pinging you on FB :).

I don't have interest in python2, but it's still used by quite a few components included in other layers are care about (e.g. qtwebengine in meta-qt5, chromium in meta-browser - https://bugs.chromium.org/p/chromium/issues/detail?id=942720 is still quite far from finished) and at LGE we maintain meta-ros https://github.com/ros/meta-ros which contains support for ROS 1 Melodic which is usually used with python2 and support ends May 2023 (together with Ubuntu Bionic it's usually used with: http://wiki.ros.org/Distributions - just today I've separated meta-ros-python2 layer with python2 recipes which disappeared from oe-core in warrior and were never re-introduced in meta-python2 (like nose and numpy).

If you're looking for someone just keeping it buildable, then you can sign me up. If it gets more annoying to maintain in future we can also split it for pythonnative.bbclass and python recipe itself - to keep just the bare minimum of recipes which are actively being used without all the other junk.

Cheers,

Hi,

can I get the write access to meta-python2 as mentioned above?

+1 





[ANNOUNCEMENT]Milestone 2 for Yocto Project 3.3 (yocto-3.3_M2) now available

Vineela
 

Hello,

We are pleased to announce the second milestone release for Yocto Project 3.3 (yocto-3.3_M2) is now available for download.

Download:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.3_M2

bitbake: 01e901c44ab0f496606b1d45c8953dc54970204c
meta-arm: a8f32f990a0d9dc1db310892c70d5a994c698b32
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: b4e5d33affeaa223459c0935a853485137b4591d
meta-kernel: 8349870943ba44bbd688656897372e881f32c741
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: 79821d5a185e25384f5b6b5158b238bbee17c79e
poky: b5e634644b69a968a93aad0dd0502cf479d3973a

Full Test Report:

http://downloads.yoctoproject.org/releases/yocto/milestones/yocto-3.3_M2/testreport.txt

Thank you.

Vineela Tummalapalli,
Yocto Project Build and Release
vineela.tummalapalli@intel.com


Re: [OE-core] Let me tell you how I really feel. Zero filter. If you need meta-python2, you need to become a maintainer. Immediately. Period.

Martin Jansa
 

On Thu, Oct 22, 2020 at 11:37 PM Martin Jansa via lists.yoctoproject.org <Martin.Jansa=gmail.com@...> wrote:
There were only a few changes needed between dunfell and gatesgarth to keep it building and I feel guilty for sending half of them - and pinging you on FB :).

I don't have interest in python2, but it's still used by quite a few components included in other layers are care about (e.g. qtwebengine in meta-qt5, chromium in meta-browser - https://bugs.chromium.org/p/chromium/issues/detail?id=942720 is still quite far from finished) and at LGE we maintain meta-ros https://github.com/ros/meta-ros which contains support for ROS 1 Melodic which is usually used with python2 and support ends May 2023 (together with Ubuntu Bionic it's usually used with: http://wiki.ros.org/Distributions - just today I've separated meta-ros-python2 layer with python2 recipes which disappeared from oe-core in warrior and were never re-introduced in meta-python2 (like nose and numpy).

If you're looking for someone just keeping it buildable, then you can sign me up. If it gets more annoying to maintain in future we can also split it for pythonnative.bbclass and python recipe itself - to keep just the bare minimum of recipes which are actively being used without all the other junk.

Cheers,

Hi,

can I get the write access to meta-python2 as mentioned above?

I have 2 fixes to make it parse able with latest oe-core:

to fix issues discussed in:

Cheers,


Re: oddity: file_5.37 printing unexpected "octet-stream" mime type for ISO

Ross Burton
 

You might have better luck talking to the file maintainers.

Ross

On Sat, 30 Jan 2021 at 11:27, Robert P. J. Day <rpjday@crashcourse.ca> wrote:


(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/1763570

that 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: #yocto #zeus #sdk populate_sdk_ext build failing #yocto #zeus #sdk

Monsees, Steven C (US)
 

 

Any ideas on how to resolve this extended SDK build issue ?

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Friday, January 29, 2021 6:04 PM
To: yocto@...
Subject: [yocto] #yocto #zeus #sdk populate_sdk_ext build failing

 

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

 

 

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: Writing a BSP from downstream kernel sources

Herman van Hazendonk (Herrie)
 

Hi,

We've been using 3.18 (Android) kernels on our LuneOS project with Yocto, so we carry the various patches to get it to build with newer GCC's.

See: https://github.com/shr-distribution/linux/commits/tissot/3.18/halium-7.1 for some inspiration :)

For older 3.4 kernels you would need more patches obviously:

https://github.com/shr-distribution/linux/commits/hammerhead/3.4/halium-5.1


Best regards,
Herman

On 2021-02-01 08:04, Diego Santa Cruz via lists.yoctoproject.org wrote:

From: Jonas Vautherin <jonas.vautherin@...>
Sent: 31 January 2021 22:23
To: Aaron Cohen <aaron@...>
Cc: Diego Santa Cruz <Diego.SantaCruz@...>; Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] 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...

[Diego Santa Cruz] It may be easier to build the SDK with a dummy kernel (i.e. no kernel, setting PREFERRED_PROVIDER_virtual/kernel ?= "linux-dummy" in conf/local.conf) and use that SDK to get the kernel building outside of Yocto. If you run the make with V=1 you will see the full compiler command and you can re-run it manually. The use the -S (and eventually -E) line and you can inspect the faulty assembly file or source and track the original location. At least that is the route I took and worked well for me.

I think you are using kernel 3.18.31, in that version it is the __put_user_check macro you need to fix, https://elixir.bootlin.com/linux/v3.18.31/source/arch/arm/include/asm/uaccess.h#L219

 

A hand written patch (not tested at all!) that should solve your problem is

--- arch/arm/include/asm/uaccess.h

+++ arch/arm/include/asm/uaccess.h

#define __put_user_check(x,p)                                                                                                            \

          ({                                                                                                                             \

                          unsigned long __limit = current_thread_info()->addr_limit - 1; \

                          const typeof(*(p)) __user *__tmp_p = (p);                            \

-                          register const typeof(*(p)) __r2 asm("r2") = (x); \

+                         register typeof(*(p)) __r2 asm("r2") = (x);             \

                          register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \

                          register unsigned long __l asm("r1") = __limit;                    \

                          register int __e asm("r0");                                                           \

                             switch (sizeof(*(__p))) {                                                \

 

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).

 

 

On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org <aaron=assonance.org@...> wrote:

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

 

 

On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin <jonas.vautherin@...> wrote:

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

 

I pasted the full output here, if that can help: https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the log2 warning are:

 

```

extern __attribute__((const, noreturn))

int ____ilog2_NaN(void);

 ```

 

So there is a const there, but well... not sure what to do with it :-).

 

Best,

 

On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz <Diego.SantaCruz@...> wrote:

From: yocto@... <yocto@...> On Behalf Of Jonas Vautherin via lists.yoctoproject.org
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@...>
Cc: Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Writing a BSP from downstream kernel sources

 

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.

 

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org <jonas.vautherin=gmail.com@...> wrote:

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)

 

 

Best,

 

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




--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com

 

 






Re: Writing a BSP from downstream kernel sources

Diego Santa Cruz
 

From: Jonas Vautherin <jonas.vautherin@...>
Sent: 31 January 2021 22:23
To: Aaron Cohen <aaron@...>
Cc: Diego Santa Cruz <Diego.SantaCruz@...>; Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] 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...

[Diego Santa Cruz] It may be easier to build the SDK with a dummy kernel (i.e. no kernel, setting PREFERRED_PROVIDER_virtual/kernel ?= "linux-dummy" in conf/local.conf) and use that SDK to get the kernel building outside of Yocto. If you run the make with V=1 you will see the full compiler command and you can re-run it manually. The use the -S (and eventually -E) line and you can inspect the faulty assembly file or source and track the original location. At least that is the route I took and worked well for me.

I think you are using kernel 3.18.31, in that version it is the __put_user_check macro you need to fix, https://elixir.bootlin.com/linux/v3.18.31/source/arch/arm/include/asm/uaccess.h#L219

 

A hand written patch (not tested at all!) that should solve your problem is

--- arch/arm/include/asm/uaccess.h

+++ arch/arm/include/asm/uaccess.h

#define __put_user_check(x,p)                                                                                                            \

          ({                                                                                                                             \

                          unsigned long __limit = current_thread_info()->addr_limit - 1; \

                          const typeof(*(p)) __user *__tmp_p = (p);                            \

-                          register const typeof(*(p)) __r2 asm("r2") = (x); \

+                         register typeof(*(p)) __r2 asm("r2") = (x);             \

                          register const typeof(*(p)) __user *__p asm("r0") = __tmp_p; \

                          register unsigned long __l asm("r1") = __limit;                    \

                          register int __e asm("r0");                                                           \

                             switch (sizeof(*(__p))) {                                                \

 

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).

 

 

On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org <aaron=assonance.org@...> wrote:

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

 

 

On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin <jonas.vautherin@...> wrote:

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

 

I pasted the full output here, if that can help: https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the log2 warning are:

 

```

extern __attribute__((const, noreturn))

int ____ilog2_NaN(void);

 ```

 

So there is a const there, but well... not sure what to do with it :-).

 

Best,

 

On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz <Diego.SantaCruz@...> wrote:

From: yocto@... <yocto@...> On Behalf Of Jonas Vautherin via lists.yoctoproject.org
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@...>
Cc: Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Writing a BSP from downstream kernel sources

 

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.

 

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org <jonas.vautherin=gmail.com@...> wrote:

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)

 

 

Best,

 

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




--
Diego Santa Cruz, PhD
Technology Architect
spinetix.com

 

 


Re: [error-report-web][PATCH] report-error.bbclass: Add layer and bitbake version info to error report

Milan Shah
 

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

Jonas Vautherin
 

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).


On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org <aaron=assonance.org@...> wrote:
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


On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin <jonas.vautherin@...> wrote:
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

I pasted the full output here, if that can help: https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the log2 warning are:

```
extern __attribute__((const, noreturn))
int ____ilog2_NaN(void);
 ```

So there is a const there, but well... not sure what to do with it :-).

Best,

On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz <Diego.SantaCruz@...> wrote:

From: yocto@... <yocto@...> On Behalf Of Jonas Vautherin via lists.yoctoproject.org
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@...>
Cc: Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Writing a BSP from downstream kernel sources

 

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.

 

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org <jonas.vautherin=gmail.com@...> wrote:

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)

 

 

Best,

 

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)

Richard Purdie
 

On Wed, 2021-01-27 at 09:45 +0000, Jose Quaresma wrote:
Hi All,
gstreamer1.0: fix failing ptest
https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?id=7b90027aac9fa41b3dc98765151d761df8dabb97

Is this commit present yocto-3.3_M2.rc1 ?
Just to confirm, it wasn't so this should be fixed for M3, thanks!

Cheers,

Richard


Regarding YOCTO

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

Robert P. J. Day
 

(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/1763570

that 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

Joel A Cohen
 

Actually, I found the upstream patch I backported, which you're probably better off using (same diff though).


On Sat, Jan 30, 2021 at 2:26 AM Joel A Cohen via lists.yoctoproject.org <aaron=assonance.org@...> wrote:
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


On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin <jonas.vautherin@...> wrote:
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

I pasted the full output here, if that can help: https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the log2 warning are:

```
extern __attribute__((const, noreturn))
int ____ilog2_NaN(void);
 ```

So there is a const there, but well... not sure what to do with it :-).

Best,

On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz <Diego.SantaCruz@...> wrote:

From: yocto@... <yocto@...> On Behalf Of Jonas Vautherin via lists.yoctoproject.org
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@...>
Cc: Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Writing a BSP from downstream kernel sources

 

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.

 

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org <jonas.vautherin=gmail.com@...> wrote:

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)

 

 

Best,

 

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

Joel A Cohen
 

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


On Fri, Jan 29, 2021 at 9:51 PM Jonas Vautherin <jonas.vautherin@...> wrote:
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

I pasted the full output here, if that can help: https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the log2 warning are:

```
extern __attribute__((const, noreturn))
int ____ilog2_NaN(void);
 ```

So there is a const there, but well... not sure what to do with it :-).

Best,

On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz <Diego.SantaCruz@...> wrote:

From: yocto@... <yocto@...> On Behalf Of Jonas Vautherin via lists.yoctoproject.org
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@...>
Cc: Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Writing a BSP from downstream kernel sources

 

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.

 

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org <jonas.vautherin=gmail.com@...> wrote:

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)

 

 

Best,

 

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

Trevor Woerner
 

Applied, thanks!


Re: Writing a BSP from downstream kernel sources

Jonas Vautherin
 

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

I pasted the full output here, if that can help: https://paste.ubuntu.com/p/KqN8nVWmvv/. The lines that seem to get the log2 warning are:

```
extern __attribute__((const, noreturn))
int ____ilog2_NaN(void);
 ```

So there is a const there, but well... not sure what to do with it :-).

Best,

On Mon, Jan 25, 2021 at 9:00 AM Diego Santa Cruz <Diego.SantaCruz@...> wrote:

From: yocto@... <yocto@...> On Behalf Of Jonas Vautherin via lists.yoctoproject.org
Sent: 24 January 2021 14:30
To: Jonas Vautherin <jonas.vautherin@...>
Cc: Paul Barker <pbarker@...>; Yocto-mailing-list <yocto@...>
Subject: Re: [yocto] Writing a BSP from downstream kernel sources

 

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.

 

On Sat, Jan 23, 2021 at 2:07 PM Jonas Vautherin via lists.yoctoproject.org <jonas.vautherin=gmail.com@...> wrote:

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)

 

 

Best,

 

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


#yocto #zeus #sdk populate_sdk_ext build failing #yocto #zeus #sdk

Monsees, Steven C (US)
 

 

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

Ayoub Zaki
 

thanks for the hint :-)

it did it however I run in other problems:

My goal is to cross-compile executable scripts into binaries using shc tool:  https://github.com/neurobin/shc

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, Jan 28, 2021 at 10:26 PM Richard Purdie <richard.purdie@...> wrote:
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?

Richard Purdie
 

On Fri, 2021-01-29 at 13:48 -0600, Andrew Geissler wrote:

On Jan 29, 2021, at 10:54 AM, Richard Purdie <richard.purdie@linuxfoundation.org> 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@burtonini.com>
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
 

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

On 29.01.21 21:41, ddbabich@bootseeds.com 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

2901 - 2920 of 55050