Date   

Re: using SYSTEMD_SERVICE to disable a systemd service?

Mikko Rapeli
 

Hi,

On Tue, Feb 02, 2021 at 03:38:34AM -0500, Robert P. J. Day wrote:

while the "standard" way to disable a systemd service from
auto-booting is SYSTEMD_AUTO_ENABLE, i just ran across a number of
examples in an existing project that do this:

SYSTEMD_SERVICE_${PN} = ""

ouch. that's a new one on me and, while i'm prepared to believe it
works, it seems like grotesque overkill and mis-application of that
variable.

am i within my rights to suggest that that's not really the way to
do it? or is that considered an acceptable (albeit weird) alternative?
We do SYSTEMD_SERVICE_${PN} = "" a lot but reasons are a lot more complex.

To properly tune target system boot, one really needs to fork most systemd service
files. This is needed to set cgroups, permissons, to change service and/or
target dependencies e.g. additional or intermediate boot targets.

Thus one ends up forking most of the service files. For some subset, it's enough
to patch them, but for most it's easier to just fork even the ones that come from systemd.
Additionally a lot of testing and logging infra needs to be added to make sure boot is
clean and happens the way developers designed and meets the KPIs like boot time.

These are tricky to maintain and so company/industry/product/version specific that
it's tricky to upstream the changes.

Cheers,

-Mikko


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.

Richard Purdie
 

On Mon, 2021-02-01 at 15:40 +0100, Martin Jansa wrote:
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:
https://lists.openembedded.org/g/openembedded-devel/message/89201
https://lists.openembedded.org/g/openembedded-devel/message/89200

to fix issues discussed in:
https://github.com/openembedded/openembedded-core/commit/fd6a007efa7cb45101a66f294af81d9d33bb3fab#commitcomment-46565284
https://lists.openembedded.org/g/openembedded-core/message/147477
https://lists.openembedded.org/g/openembedded-core/message/147514
This sounds like a good idea to me and I have admin right so I've given
you access :)

Cheers,

Richard


using SYSTEMD_SERVICE to disable a systemd service?

Robert P. J. Day
 

while the "standard" way to disable a systemd service from
auto-booting is SYSTEMD_AUTO_ENABLE, i just ran across a number of
examples in an existing project that do this:

SYSTEMD_SERVICE_${PN} = ""

ouch. that's a new one on me and, while i'm prepared to believe it
works, it seems like grotesque overkill and mis-application of that
variable.

am i within my rights to suggest that that's not really the way to
do it? or is that considered an acceptable (albeit weird) alternative?

rday


M+ & H bugs with Milestone Movements WW05

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW05 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

5876

Add a test for the kernel -c menuconfig option

randy.macleod@...

unassigned@...

3.4

3.4 M1

 

12723

mysql requires unicode and char length filtering

david.reyna@...

david.reyna@...

3.3 M2

3.3 M3

 

13103

[Bug][QA 2.7 M1 rc1][Toaster] "Recipes" tableá and á"machines" table are not getting populated after clickingáon imported layer as well as after clicking Machines Tab on project page

david.reyna@...

david.reyna@...

3.3 M2

3.3 M3

 

13669

Move Toaster testsuite-2 away from Testopia

david.reyna@...

david.reyna@...

3.3 M2

3.3 M3

 

13933

Devtool does not work with multiconfig

randy.macleod@...

bluelightning@...

3.3 M3

Future

 

14020

environment-setup script in multilib eSDK doesn't work for multilib variant

liezhi.yang@...

liezhi.yang@...

3.3 M2

3.3 M3

 

14085

Toaster UI should know when bitbake crashed

david.reyna@...

david.reyna@...

3.3 M2

3.3 M3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW05!

Stephen Jolley
 

All,

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

Who

Count

randy.macleod@...

3

dorindabassey@...

2

richard.purdie@...

2

yifan.yu@...

2

denis@...

1

mhalstead@...

1

akuster808@...

1

matt.hoosier@...

1

sangeeta.jain@...

1

Grand Total

14

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.3

Stephen Jolley
 

All,

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

Who

Count

richard.purdie@...

35

ross@...

25

david.reyna@...

20

bluelightning@...

16

mark.morton@...

11

timothy.t.orling@...

11

bruce.ashfield@...

11

sakib.sajal@...

10

JPEWhacker@...

10

kai.kang@...

9

trevor.gamblin@...

9

akuster808@...

7

raj.khem@...

5

Qi.Chen@...

5

yi.zhao@...

4

randy.macleod@...

4

chee.yang.lee@...

4

stacygaikovaia@...

4

idadelm@...

4

alejandro@...

3

hongxu.jia@...

3

mostthingsweb@...

3

mingli.yu@...

3

anuj.mittal@...

2

jeanmarie.lemetayer@...

2

pokylinux@...

2

jaewon@...

2

matthewzmd@...

2

saul.wold@...

2

ydirson@...

2

nicolas.dechesne@...

2

jon.mason@...

2

sangeeta.jain@...

2

dorindabassey@...

1

aehs29@...

1

mister_rs@...

1

yoctoproject@...

1

liezhi.yang@...

1

akuster@...

1

shachar@...

1

pbarker@...

1

Martin.Jansa@...

1

dl9pf@...

1

joe.slater@...

1

twoerner@...

1

mark.hatle@...

1

kergoth@...

1

mhalstead@...

1

kexin.hao@...

1

kamensky@...

1

mshah@...

1

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

All,

 

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

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

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Reminder: Yocto Project Technical Team Meeting @ Monthly from 8am on the first Tuesday (PDT)

Stephen Jolley
 

All,

 

Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (2/2) 

 

Yocto Project Technical Team Meeting: We encourage people attending the meeting to logon and announce themselves on the Yocto Project IRC chancel during the meeting (optional):

Yocto IRC: http://webchat.freenode.net/?channels=#yocto

 

Wiki: https://www.yoctoproject.org/public-virtual-meetings/

 

When            Monthly from 8am to 9am on the first Tuesday Pacific Time

Where           Zoom Meeting: https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09

 

We are tracking the minutes at: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit?pli=1 Please request access if you want to assist in editing them.  The world should have view access.

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


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

3301 - 3320 of 55458