Date   

Re: Hardknott - pseudo excluded from intercept_scripts

Richard Purdie
 

On Wed, 2021-05-05 at 00:56 -0700, Chuck Wolber wrote:
The following code is an effective workaround. It must be added after the core-image is inherited.

python () {
     pseudo_ignore_paths = d.getVar('PSEUDO_IGNORE_PATHS')
     result = ','.join([x for x in pseudo_ignore_paths.split(',') if "intercept_scripts" not in x])
     d.setVar('PSEUDO_IGNORE_PATHS', result)
}

..Ch:W..

On Tue, May 4, 2021 at 8:53 PM Chuck Wolber via lists.yoctoproject.org <
chuckwolber=gmail.com@...> wrote:

I was attempting an image build with Yocto Hardknott, and I ran into a chown problem during do_rootfs(). I
traced it down to ${WORKDIR}/intercept_scripts showing up in the PSEUDO_IGNORE_PATHS environment variable.

This commit made the change:
https://git.openembedded.org/openembedded-core/commit/meta/classes/image.bbclass?id=9463be2292b942a1072eea88881b9644e55aadb9

I continued down the rabbit hole until I got here:
https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n173

Line 192 specifically is the smoking gun. The files are being copied from poky/scripts/postinst-intercepts
into the ${WORKDIR}/intercept_scripts directory and immediately failing when the copyFile utility attempts
to do a chown.

Is there any logical explanation for this? Is this a bug or am I doing something wrong? Is there a
workaround?
This should be fixed in master, the issue was triggered by a checkout 
owned by root/root:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=eff192abe2ee43ebf981bafbb7fca8602ebdcf0c

Steve/Anuj: We'll likely want to backport that one.

Cheers,

Richard


Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase

Thomas Hill
 

Hi Martin!

On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
 
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?

Thanks!
Tom


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Adding BB_ORIGENV to do_compile[vardepsexclude] solved the issue. Thanks for your help!


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Hi Richard,

Unfortunately, that doesn't make the error messages go away. I agree that it's not great that go-mod fetches during do_compile but that's the way it currently is.

For completeness sake, here is the complete minimal example that _does_ compile. However, error messages à la

ERROR: When reparsing [...]/golang-test/golang-test.bb:do_compile, the basehash value changed from be5e3ca0e52fd3e3a0315fb32a2845f097bb6925940a8141b6f4d99fa2423e20 to fc952756231a898ae7d3fd611607066b349042f5313b8363d11eef18ed317ed2. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake golang-test -cdo_compile -Snone
ERROR: Then:
ERROR: $ bitbake golang-test -cdo_compile -Sprintdiff

are spewed out. Here's the recipe:

LICENSE = "CLOSED"
GO_IMPORT = "bitbucket.org/sven_schwermer/golang-a"
SRC_URI = "git://git@${GO_IMPORT};protocol=ssh;branch=master"
SRCREV = "f7d820d09a5b2332737a8105b3efd9c1e8e51d32"
inherit go-mod
do_compile() {
export SSH_AUTH_SOCK="${@d.getVar('BB_ORIGENV', False).getVar('SSH_AUTH_SOCK', False)}"
go_do_compile
}

bitbucket.org/sven_schwermer/golang-a pulls in a secondary dependency (bitbucket.org/sven_schwermer/golang-b) which is not publicly available. This is golang-a's go.mod:

module bitbucket.org/sven_schwermer/golang-a
go 1.16
require bitbucket.org/sven_schwermer/golang-b v0.0.0-20210505180831-90ba3cd6391e

I have tested this also on latest poky@master (5a0679cb75) with identical results.


Re: Recipe Grep'ing

Khem Raj
 

On Wed, May 5, 2021 at 7:13 PM Bruce Ashfield <bruce.ashfield@...> wrote:

On Wed, May 5, 2021 at 8:42 PM Chuck Wolber <chuckwolber@...> wrote:

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.

I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
item2 \
"

After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
The other issue with large formatting patches, is that they make a
history "wall". So when we are debugging and trying to figure why a
change was made, you always have to jump over the wall (or dig under
it) to get the real information.
right, that's what if we want to do this then it has to be persisted
with otherwise it will end up being one time exercise with all these
losses you described.

As such, I'm not a fan of changes like this, unless they are coupled
to some sort of functional change. So I'd be hesitant to take them
into recipes that I end up holding the bag when things break.

Cheers,

Bruce


So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?

..Ch:W..


--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II



Re: Recipe Grep'ing

Bruce Ashfield
 

On Wed, May 5, 2021 at 8:42 PM Chuck Wolber <chuckwolber@...> wrote:

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.

I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
item2 \
"

After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
The other issue with large formatting patches, is that they make a
history "wall". So when we are debugging and trying to figure why a
change was made, you always have to jump over the wall (or dig under
it) to get the real information.

As such, I'm not a fan of changes like this, unless they are coupled
to some sort of functional change. So I'd be hesitant to take them
into recipes that I end up holding the bag when things break.

Cheers,

Bruce


So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?

..Ch:W..


--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II


Re: Recipe Grep'ing

Khem Raj
 

On 5/5/21 5:41 PM, Chuck Wolber wrote:
I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.
I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:
FOO += "item1"
FOO += "item2"
Whereas this pattern gives us the "what", but not the "why":
FOO = "item1 \
             item2 \
            "
After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?
I think it is a good idea, however, to make it persistent it would be nice to have a linter, which can do such checks and perhaps we can enable this in autobuilders so we can keep such cleansups maintained

..Ch:W..
--
*"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire*


Recipe Grep'ing

Chuck Wolber
 

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.

I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
             item2 \
            "

After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.

So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?

..Ch:W..


--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire


Re: #yocto cmake configurations #yocto

Khem Raj
 

usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missing or present after the faulting .a in linker cmd

On Wed, May 5, 2021 at 12:53 PM Monsees, Steven C (US) <steven.monsees@...> wrote:

 

I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)…

 

The link command is attached as “tmp.txt”.

 

There are a lot of these being generated, this is but a subset…

Note:

(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?

                (2) the code with the undefined reference does appear to be missing the proper header file reference

 

 

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::Release()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520: undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788: undefined reference to `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819: undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::Module::getTopLevelModuleName() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468: undefined reference to `clang::Module::getTopLevelModule() const'

 

 

From: Monsees, Steven C (US) <steven.monsees@...>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) <steven.monsees@...>; Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto cmake configurations

 

 

All the libraries are under the SDK here:

 

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

 

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue…

 

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

Khem:

 

I only have the following libraries present for these:

 

libclang.so  

libclang.so.9

libdrm_intel.so

libdrm_intel.so.1

libdrm_intel.so.1.0.0

libdrm.so

libdrm.so.2

libdrm.so.2.4.0   

 

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

 

Steve

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

 

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Yes, LLVM & Clang…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

I see its using -rdynamic -static

so next question is that do you have .a files in your sdk ?

 

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Attached…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

can you post full linker cmd which is failing ?

 

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

My standard zeus SDK appears to have an issue linking in my applications dynamic libs…

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang

collect2: error: ld returned 1 exit status

The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

 

My CMake build app does not appear to have an issue finding the files:

 

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so

DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

 

It appears to be an issue specifically with the ld…

 

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

 

It does not appear to be making use of –L’s…

 

Is there something I might look at/configure (i.e. add paths to search paths) ?

Is there a simple test to validate tool ?

 

Thanks,

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@...
Subject: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I am using zeus, standard SDK, cmake…

 

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

 

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and

I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

 

I am working on third party package unaware of my SDK setup.

 

Thanks,

Steve

 

 

 


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Richard Purdie
 

On Mon, 2021-05-03 at 11:25 -0700, Sven via lists.yoctoproject.org wrote:
Hi,

I have put together a recipe inheriting from go-mod. This project depends on 
out-of-repo modules that sit in private repos. As long as the SSH key required 
to pull the requirements is present as a file (under $HOME/.ssh), everything 
works fine. However, as soon as the SSH credentials are only available via 
agent and $SSH_AUTH_SOCK, the do_compile step fails. I have traced this down 
to the fact that the $SSH_AUTH_SOCK environment variable is not available to
do_compile which is when the requirements are pulled. This is the sort of error 
message I get:
ERROR: mypackage-git-r0 do_compile: Execution of '[...]/mypackage/git-r0/temp/run.do_compile.20076' 
failed with exit code 1:
# cd .; git ls-remote https://bitbucket.org/myorg/some-requirement
Permission denied (publickey).
fatal: Could not read from remote repository.

Note, that the do_fetch step succeeds in pulling the actual repo. I tried fixing 
the problem by wrapping the do_compile function and providing $SSH_AUTH_SOCK from
the original environment:
def origenv(d, var):
    return d.getVar("BB_ORIGENV", False).getVar(var, False)

do_compile() {
    if [ -n "${@origenv(d, 'SSH_AUTH_SOCK') or ''}" ]; then
        export SSH_AUTH_SOCK="${@origenv(d, 'SSH_AUTH_SOCK')}"
    fi
    go_do_compile
}

This allows the do_compile step (and all subsequent steps) to finish successfully. 
However, that way, I get a bunch of errors like this (cleansstate does not help):
ERROR: When reparsing [...]/mypackage_git.bb:do_compile, the basehash value 
changed from eb51e4ec321c723587cec03bb9b33b94ee43e0b0939eb43b52824e3d5cfebec2 
to 2bb034f43856917d6454a56b32946b1c68cf7f286b20fd7a7eaf1bfd2a92d34f. The metadata 
is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake mypackage -cdo_compile -Snone
ERROR: Then:
ERROR: $ bitbake mypackage -cdo_compile -Sprintdiff

Neither command helps to fix this. What can I do? I'm on poky yocto-3.1.5-18-gbb7747497a.

You can probably 'fix' that with:

do_compile[vardepsexclude] += "SSH_AUTH_SOCK"

however you really shouldn't be accessing the network in a compile task.
That is a wider go issue :(.

Cheers,

Richard


Re: #yocto cmake configurations #yocto

Monsees, Steven C (US)
 

 

I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)…

 

The link command is attached as “tmp.txt”.

 

There are a lot of these being generated, this is but a subset…

Note:

(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?

                (2) the code with the undefined reference does appear to be missing the proper header file reference

 

 

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::Release()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520: undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788: undefined reference to `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819: undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::Module::getTopLevelModuleName() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468: undefined reference to `clang::Module::getTopLevelModule() const'

 

 

From: Monsees, Steven C (US) <steven.monsees@...>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) <steven.monsees@...>; Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto cmake configurations

 

 

All the libraries are under the SDK here:

 

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

 

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue…

 

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

Khem:

 

I only have the following libraries present for these:

 

libclang.so  

libclang.so.9

libdrm_intel.so

libdrm_intel.so.1

libdrm_intel.so.1.0.0

libdrm.so

libdrm.so.2

libdrm.so.2.4.0   

 

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

 

Steve

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

 

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Yes, LLVM & Clang…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

I see its using -rdynamic -static

so next question is that do you have .a files in your sdk ?

 

On Tue, May 4, 2021 at 12:57 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Attached…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

can you post full linker cmd which is failing ?

 

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

My standard zeus SDK appears to have an issue linking in my applications dynamic libs…

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang

collect2: error: ld returned 1 exit status

The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

 

My CMake build app does not appear to have an issue finding the files:

 

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so

DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

 

It appears to be an issue specifically with the ld…

 

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

 

It does not appear to be making use of –L’s…

 

Is there something I might look at/configure (i.e. add paths to search paths) ?

Is there a simple test to validate tool ?

 

Thanks,

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@...
Subject: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I am using zeus, standard SDK, cmake…

 

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

 

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and

I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

 

I am working on third party package unaware of my SDK setup.

 

Thanks,

Steve

 

 

 


[PATCH yocto-autobuilder-helper] config.json: do not add separate gdk-pixbuf jpg/png modules to images

Alexander Kanavin
 

JPG/PNG have become builtin in gdk-pixbuf 2.42.x
(other formats are still external).

Signed-off-by: Alexander Kanavin <alex.kanavin@...>
---
config.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config.json b/config.json
index 52f39ef..3e12d3f 100644
--- a/config.json
+++ b/config.json
@@ -559,7 +559,7 @@
"MULTILIBS = 'multilib:lib32'",
"DEFAULTTUNE_virtclass-multilib-lib32 = 'x86'",
"RPM_PREFER_ELF_ARCH = '1'",
- "IMAGE_INSTALL_append = ' lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png lib32-gdk-pixbuf-loader-png pango-module-basic-fc lib32-pango-module-basic-fc'"
+ "IMAGE_INSTALL_append = ' lib32-connman-gnome pango-module-basic-fc lib32-pango-module-basic-fc'"
]
},
"step4" : {
@@ -574,7 +574,7 @@
"MULTILIBS = 'multilib:lib32'",
"DEFAULTTUNE_virtclass-multilib-lib32 = 'x86'",
"RPM_PREFER_ELF_ARCH = '1'",
- "IMAGE_INSTALL_append = ' lib32-connman-gnome gdk-pixbuf-loader-jpeg lib32-gdk-pixbuf-loader-jpeg gdk-pixbuf-loader-png lib32-gdk-pixbuf-loader-png pango-module-basic-fc lib32-pango-module-basic-fc'"
+ "IMAGE_INSTALL_append = ' lib32-connman-gnome pango-module-basic-fc lib32-pango-module-basic-fc'"
]
},
"step5" : {
--
2.31.1


Re: [meta-raspberrypi] Booting a Raspberry Pi 4 using PXE

Manuel Wagesreither
 

Hello Anton,

Am Mi, 5. Mai 2021, um 15:34, schrieb Anton Antonov:
I don't know what exactly you mean by "whenever the Raspi is booting over the network".
When a machine boots from network (i,e. using DHCP/BOOTP) then usually DHCP server points to, for example, a TFTP server where the kernel and initramfs should be obtained from and kernel parameters. So, you need to check your DHCP/TFTP/etc servers configuration for kernel parameters.

The boot files (kernel, kernel parameters, device tree overlays, ...) served by TFTP are bit-identical to the ones present at `/boot` of the usb stick.

When I boot over PXE/BOOTP/DHCP/TFTP/etc, something seems to replace all occurences of `8250.nr_uarts=1` with `8250.nr_uarts=0`. When I boot using usb drive using the exact same files, this doesn't happen and uart is active.


Regards,
Manuel


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Quentin Schulz
 

Hi Sven,

On Wed, May 05, 2021 at 06:37:41AM -0700, Sven via lists.yoctoproject.org wrote:
Hi Quentin,

Thanks for your reply. Did you have success with this technique when compiling a go-mod recipe where some of the go dependencies sit in private repos? The standard git fetcher works for me with private repos, that is not the problem.
No, I do not use any custom go-based recipe.

BR,
Quentin


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Hi Quentin,

Thanks for your reply. Did you have success with this technique when compiling a go-mod recipe where some of the go dependencies sit in private repos? The standard git fetcher works for me with private repos, that is not the problem.

Best regards,
Sven


Re: [meta-raspberrypi] Booting a Raspberry Pi 4 using PXE

Anton Antonov
 

I don't know what exactly you mean by "whenever the Raspi is booting over the network".
When a machine boots from network (i,e. using DHCP/BOOTP) then usually DHCP server points to, for example, a TFTP server where the kernel and initramfs should be obtained from and kernel parameters. So, you need to check your DHCP/TFTP/etc servers configuration for kernel parameters.


[meta-rockchip][PATCH v5 2/2] WIP linux-yocto: add workaround to disable VOPL usage on HDMI

Yann Dirson
 

From: Yann Dirson <yann@...>

There is a known issue in mainline kernel making the machine unusable
once a HDMI screen is plugged. This patch lets VOPB be alone to use
the HDMI port and avoids the issue while providing wupport for the larges=
t
set of video modes, at the expense of double-screen support.

FIXME: patch does not get applied, unless the scc is also added to
KERNEL_FEATURES ?
---
.../files/bsp/rockchip/hdmi-no-vopl.patch | 65 +++++++++++++++++++
.../linux/files/bsp/rockchip/rockchip.scc | 2 +
2 files changed, 67 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.=
patch

diff --git a/recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.patch b=
/recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.patch
new file mode 100644
index 0000000..72ed753
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.patch
@@ -0,0 +1,65 @@
+From 92d9cf4e6c2767c8c5aa8d97e684f2f77d950e7d Mon Sep 17 00:00:00 2001
+From: Jonas Karlman <jonas@...>
+Date: Sun, 19 Jul 2020 16:35:11 +0000
+Subject: [PATCH] HACK: dts: rockchip: do not use vopl for hdmi
+Upstream-Status: Inappropriate [other]
+
+---
+ arch/arm/boot/dts/rk3288.dtsi | 9 ---------
+ arch/arm64/boot/dts/rockchip/rk3399.dtsi | 9 ---------
+ 2 files changed, 18 deletions(-)
+
+diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dt=
si
+index 03e86d012edd..746acfac1e92 100644
+--- a/arch/arm/boot/dts/rk3288.dtsi
++++ b/arch/arm/boot/dts/rk3288.dtsi
+@@ -1104,11 +1104,6 @@ vopl_out: port {
+ #address-cells =3D <1>;
+ #size-cells =3D <0>;
+=20
+- vopl_out_hdmi: endpoint@0 {
+- reg =3D <0>;
+- remote-endpoint =3D <&hdmi_in_vopl>;
+- };
+-
+ vopl_out_edp: endpoint@1 {
+ reg =3D <1>;
+ remote-endpoint =3D <&edp_in_vopl>;
+@@ -1249,10 +1244,6 @@ hdmi_in_vopb: endpoint@0 {
+ reg =3D <0>;
+ remote-endpoint =3D <&vopb_out_hdmi>;
+ };
+- hdmi_in_vopl: endpoint@1 {
+- reg =3D <1>;
+- remote-endpoint =3D <&vopl_out_hdmi>;
+- };
+ };
+ };
+ };
+diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/=
dts/rockchip/rk3399.dtsi
+index a855805649ef..418d16b0b648 100644
+--- a/arch/arm64/boot/dts/rockchip/rk3399.dtsi
++++ b/arch/arm64/boot/dts/rockchip/rk3399.dtsi
+@@ -1640,11 +1640,6 @@ vopl_out_edp: endpoint@1 {
+ remote-endpoint =3D <&edp_in_vopl>;
+ };
+=20
+- vopl_out_hdmi: endpoint@2 {
+- reg =3D <2>;
+- remote-endpoint =3D <&hdmi_in_vopl>;
+- };
+-
+ vopl_out_mipi1: endpoint@3 {
+ reg =3D <3>;
+ remote-endpoint =3D <&mipi1_in_vopl>;
+@@ -1816,10 +1811,6 @@ hdmi_in_vopb: endpoint@0 {
+ reg =3D <0>;
+ remote-endpoint =3D <&vopb_out_hdmi>;
+ };
+- hdmi_in_vopl: endpoint@1 {
+- reg =3D <1>;
+- remote-endpoint =3D <&vopl_out_hdmi>;
+- };
+ };
+ };
+ };
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc b/recip=
es-kernel/linux/files/bsp/rockchip/rockchip.scc
index 800f105..4d61509 100644
--- a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc
+++ b/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc
@@ -4,3 +4,5 @@ kconf hardware rockchip.cfg
=20
include cfg/dmaengine.scc
include features/mmc/mmc-block.cfg
+
+patch hdmi-no-vopl.patch
--=20
2.30.2


[meta-rockchip][PATCH v5 1/2] linux-yocto: add an initial NanoPi-M4 BSP

Yann Dirson
 

From: Yann Dirson <yann@...>

This patch provides "standard" and "tiny" BSP.

There is still much work to be done in dispatching feature to individual
scc files - the more boards we can support the better it will get.
Not all SoC/board features are covered yet either (esp. Wifi/Bluetooth an=
d
audio jack), and properly-woking HDMI still needs patches.

Tiny is not fully testable by itself, it can be minimally booted with
serial console (though still missing CONFIG_MULTIUSER for serial getty,
and CONFIG_INOTIFY_USER for proper udev operation) using:

PREFERRED_PROVIDER_virtual/kernel =3D "linux-yocto-tiny"
KERNEL_FEATURES_append =3D "\
ktypes/base/base.scc \
features/debug/printk.scc \
cfg/fs/ext4.scc \
cfg/8250.scc \
"

Such a tiny build is still using mainline defconfig with lots of hardware
features, and the kernel can be slimmed down even more by using:

KBUILD_DEFCONFIG =3D ""

Kernel weight using default configurations:
- standard 11MB
- tiny 5MB
- tiny with no defconfig 2.5MB

Signed-off-by: Yann Dirson <yann@...>
---
.../files/bsp/rockchip/nanopi-m4-standard.scc | 7 ++
.../files/bsp/rockchip/nanopi-m4-tiny.scc | 7 ++
.../linux/files/bsp/rockchip/nanopi-m4.cfg | 11 +++
.../linux/files/bsp/rockchip/nanopi-m4.scc | 5 ++
.../linux/files/bsp/rockchip/rk3399.cfg | 70 +++++++++++++++++++
.../linux/files/bsp/rockchip/rk3399.scc | 5 ++
.../linux/files/bsp/rockchip/rockchip.cfg | 50 +++++++++++++
.../linux/files/bsp/rockchip/rockchip.scc | 6 ++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++
9 files changed, 167 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-sta=
ndard.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tin=
y.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.scc

diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.s=
cc b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.scc
new file mode 100644
index 0000000..5c74d6b
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.scc
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE standard
+define KARCH arm
+
+include ktypes/standard/standard.scc
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.scc b=
/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.scc
new file mode 100644
index 0000000..6e94d6a
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.scc
@@ -0,0 +1,7 @@
+# SPDX-License-Identifier: MIT
+define KMACHINE nanopi-m4
+define KTYPE tiny
+define KARCH arm
+
+include ktypes/tiny/tiny.scc
+include nanopi-m4.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg b/reci=
pes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
new file mode 100644
index 0000000..f3a2abf
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
@@ -0,0 +1,11 @@
+CONFIG_MFD_RK808=3Dy
+CONFIG_COMMON_CLK_RK808=3Dy
+
+CONFIG_REGULATOR_RK808=3Dy
+CONFIG_REGULATOR_FAN53555=3Dy
+
+CONFIG_MMC_BLOCK=3Dy
+CONFIG_PWRSEQ_SIMPLE=3Dy
+
+# RTL8211E
+CONFIG_REALTEK_PHY=3Dm
diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc b/reci=
pes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
new file mode 100644
index 0000000..f4267aa
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware nanopi-m4.cfg
+
+include rk3399.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg b/recipes=
-kernel/linux/files/bsp/rockchip/rk3399.cfg
new file mode 100644
index 0000000..42adfd1
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
@@ -0,0 +1,70 @@
+# A72 errata, all past revisions
+CONFIG_ARM64_ERRATUM_1319367=3Dy
+# A53 errata, all patched on boot when needed
+CONFIG_ARM64_ERRATUM_826319=3Dy
+CONFIG_ARM64_ERRATUM_827319=3Dy
+CONFIG_ARM64_ERRATUM_824069=3Dy
+CONFIG_ARM64_ERRATUM_819472=3Dy
+
+# cru
+CONFIG_CLK_RK3399=3Dy
+
+CONFIG_PL330_DMA=3Dy
+CONFIG_I2C_RK3X=3Dy
+CONFIG_SERIAL_8250_DW=3Dy
+
+# usb
+CONFIG_PHY_ROCKCHIP_INNO_USB2=3Dy
+CONFIG_PHY_ROCKCHIP_TYPEC=3Dy
+
+# ethernet
+CONFIG_NET_VENDOR_STMICRO=3Dy
+CONFIG_STMMAC_ETH=3Dm
+CONFIG_STMMAC_PLATFORM=3Dm
+CONFIG_DWMAC_ROCKCHIP=3Dm
+CONFIG_PHYLIB=3Dm
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=3Dy
+CONFIG_ROCKCHIP_DW_MIPI_DSI=3Dy
+CONFIG_ROCKCHIP_ANALOGIX_DP=3Dy
+CONFIG_ROCKCHIP_CDN_DP=3Dy
+CONFIG_PHY_ROCKCHIP_DP=3Dy
+CONFIG_DRM_DW_HDMI=3Dm
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=3Dm
+CONFIG_DRM_DW_HDMI_CEC=3Dm
+CONFIG_DRM_DW_MIPI_DSI=3Dm
+CONFIG_DRM_PANFROST=3Dm
+
+# HDMI audio
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=3Dm
+
+CONFIG_VIDEO_DEV=3Dm
+CONFIG_V4L_MEM2MEM_DRIVERS=3Dy
+CONFIG_VIDEO_ROCKCHIP_RGA=3Dm
+
+CONFIG_V4L2_H264=3Dm
+CONFIG_MEDIA_CONTROLLER_REQUEST_API=3Dy
+CONFIG_VIDEO_HANTRO=3Dm
+CONFIG_VIDEO_HANTRO_ROCKCHIP=3Dy
+CONFIG_VIDEO_ROCKCHIP_VDEC=3Dm
+
+# usb
+CONFIG_USB_DWC2=3Dy
+CONFIG_USB_DWC3=3Dy
+CONFIG_USB_DWC3_DUAL_ROLE=3Dy
+
+# sd/mmc
+CONFIG_MMC=3Dy
+CONFIG_MMC_SDHCI=3Dy
+CONFIG_MMC_SDHCI_PLTFM=3Dy
+CONFIG_MMC_DW=3Dy
+CONFIG_MMC_DW_ROCKCHIP=3Dy
+CONFIG_MMC_SDHCI_OF_ARASAN=3Dy
+
+# temperature sensors
+CONFIG_THERMAL=3Dy
+CONFIG_THERMAL_OF=3Dy
+CONFIG_ROCKCHIP_THERMAL=3Dm
+CONFIG_IIO=3Dy
+CONFIG_ROCKCHIP_SARADC=3Dm
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rk3399.scc b/recipes=
-kernel/linux/files/bsp/rockchip/rk3399.scc
new file mode 100644
index 0000000..9b1a88e
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.scc
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rk3399.cfg
+
+include rockchip.scc
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg b/recip=
es-kernel/linux/files/bsp/rockchip/rockchip.cfg
new file mode 100644
index 0000000..05a397d
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg
@@ -0,0 +1,50 @@
+CONFIG_CPU_ISOLATION=3Dy
+CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=3Dy
+CONFIG_HZ_250=3Dy
+CONFIG_CPU_IDLE=3Dy
+CONFIG_ARM_CPUIDLE=3Dy
+
+CONFIG_ARCH_ROCKCHIP=3Dy
+CONFIG_COMMON_CLK_ROCKCHIP=3Dy
+CONFIG_REGULATOR=3Dy
+CONFIG_REGULATOR_FIXED_VOLTAGE=3Dy
+CONFIG_REGULATOR_PWM=3Dy
+CONFIG_I2C=3Dy
+CONFIG_FW_LOADER=3Dy
+CONFIG_PHY_ROCKCHIP_EMMC=3Dy
+CONFIG_PINCTRL=3Dy
+CONFIG_PINCTRL_ROCKCHIP=3Dy
+CONFIG_ROCKCHIP_IODOMAIN=3Dy
+CONFIG_ROCKCHIP_PM_DOMAINS=3Dy
+
+CONFIG_SPI=3Dy
+CONFIG_SPI_ROCKCHIP=3Dm
+
+CONFIG_PWM=3Dy
+CONFIG_PWM_ROCKCHIP=3Dy
+
+CONFIG_DRM_KMS_HELPER=3Dm
+CONFIG_DRM_FBDEV_EMULATION=3Dy
+CONFIG_ROCKCHIP_IOMMU=3Dy
+CONFIG_DRM_ROCKCHIP=3Dm
+CONFIG_DRM_BRIDGE=3Dy
+
+CONFIG_SND=3Dy
+CONFIG_SND_SOC=3Dy
+CONFIG_SND_HDA_CODEC_HDMI=3Dm
+CONFIG_SND_SOC_ROCKCHIP=3Dm
+CONFIG_SND_SOC_ROCKCHIP_I2S=3Dm
+CONFIG_SND_SOC_ROCKCHIP_SPDIF=3Dm
+
+CONFIG_NVMEM=3Dy
+CONFIG_ROCKCHIP_EFUSE=3Dm
+
+CONFIG_CPU_FREQ=3Dy
+CONFIG_CPU_FREQ_THERMAL=3Dy
+CONFIG_HWMON=3Dy
+CONFIG_THERMAL_HWMON=3Dy
+
+CONFIG_CRYPTO_HW=3Dy
+CONFIG_CRYPTO_DEV_ROCKCHIP=3Dm
+
+CONFIG_MMC_BLOCK_MINORS=3D32
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc b/recip=
es-kernel/linux/files/bsp/rockchip/rockchip.scc
new file mode 100644
index 0000000..800f105
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: MIT
+
+kconf hardware rockchip.cfg
+
+include cfg/dmaengine.scc
+include features/mmc/mmc-block.cfg
diff --git a/recipes-kernel/linux/linux-yocto%.bbappend b/recipes-kernel/=
linux/linux-yocto%.bbappend
index 7702e3f..9658681 100644
--- a/recipes-kernel/linux/linux-yocto%.bbappend
+++ b/recipes-kernel/linux/linux-yocto%.bbappend
@@ -1,3 +1,9 @@
+FILESEXTRAPATHS_prepend :=3D "${THISDIR}/files:"
+
+SRC_URI_append =3D "\
+ file://bsp;type=3Dkmeta;subdir=3Dkernel-meta \
+"
+
COMPATIBLE_MACHINE_marsboard-rk3066 =3D "marsboard-rk3066"
COMPATIBLE_MACHINE_rock2-square =3D "rock2-square"
COMPATIBLE_MACHINE_radxarock =3D "radxarock"
--=20
2.30.2


[meta-rockchip][PATCH v5 0/2] kmeta BSP for nanopi-m4

Yann Dirson
 

From: Yann Dirson <yann@...>

The Wifi/BT support requires firmware, to be properly packaged; BT
support itself is still buggy in mainline; audio jack requires a
couple of patches.

Changes in v5:
- removed AP6356S-related config options, will come later with proper
wifi/bt support
- removed CONFIG_SND_SOC_RK3288_HDMI_ANALOG which turns out not to be
needed for HDMI audio
- new patch to get HDMI to work

Changes in v4:
- install our bsp files in bsp/rockchip/ rather than directly in bsp/
- also add "serial" to MACHINE_FEATURES

Changes in v3:
- relocate the bsp files into files/ so we don't have to add linux-yocto/
to FILESEXTRAPATHS for all other kernels
- removed the "don't force KCONFIG_MODE to alldefconfig" (not needed fina=
lly,
and causing interferences in default setup)
- add "usbhost" to MACHINE_FEATURES to enable lsusb and friends
- better hardware coverage (though still no wifi/bt/audio, and buggy hdmi=
)

Yann Dirson (2):
linux-yocto: add an initial NanoPi-M4 BSP
WIP linux-yocto: add workaround to disable VOPL usage on HDMI

.../files/bsp/rockchip/hdmi-no-vopl.patch | 65 +++++++++++++++++
.../files/bsp/rockchip/nanopi-m4-standard.scc | 7 ++
.../files/bsp/rockchip/nanopi-m4-tiny.scc | 7 ++
.../linux/files/bsp/rockchip/nanopi-m4.cfg | 11 +++
.../linux/files/bsp/rockchip/nanopi-m4.scc | 5 ++
.../linux/files/bsp/rockchip/rk3399.cfg | 70 +++++++++++++++++++
.../linux/files/bsp/rockchip/rk3399.scc | 5 ++
.../linux/files/bsp/rockchip/rockchip.cfg | 50 +++++++++++++
.../linux/files/bsp/rockchip/rockchip.scc | 8 +++
recipes-kernel/linux/linux-yocto%.bbappend | 6 ++
10 files changed, 234 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/hdmi-no-vopl.=
patch
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-sta=
ndard.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tin=
y.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rk3399.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.cfg
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/rockchip.scc

--=20
2.30.2


Re: [meta-raspberrypi] Booting a Raspberry Pi 4 using PXE

Manuel Wagesreither
 

Hello all,

to be able to diagnose my problem, I worked on enabling uart console access to my Raspberry Pi 4B.

It seems the Raspberry Pi puts `8250.nr_uarts=0` in the linux kernel cmdline whenever the Raspi is booting over the network. This is preventing me from getting console access. When I provide the exact same set of files on a USB drive, 8250.nr_uarts is `1`.

Here's my `cmdline.txt`:
`dwc_otg.lpm_enable=0 console=tty1 console=serial0,115200 root=/dev/sda2 rootfstype=ext4 rootwait 8250.nr_uarts=1`

When I boot over network, `/proc/cmdline` is:
```
coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 smsc95xx.macaddr=DC:A6:32:B8:04:5C vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 dwc_otg.lpm_enable=0 console=tty1 console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4 rootwait 8250.nr_uarts=0
```
Note that both occurences of 8250.nr_uarts got set to 0. Even the one which I deliberatedly set to 1.

When I boot using usb disk:
```
coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 smsc95xx.macaddr=DC:A6:32:B8:04:5C vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 dwc_otg.lpm_enable=0 console=tty1 console=ttyS0,115200 root=/dev/sda2 rootfstype=ext4 rootwait 8250.nr_uarts=1
```

Has anyone any background info on that? I provide the exact same set of device tree overlays in both cases.

Thank you,
Regards,
Manuel


Am So, 2. Mai 2021, um 13:59, schrieb Manuel Wagesreither:

Hello all!

Since a certain eeprom version, the Raspberry Pi 4 can directly boot from network. Has anyone experience on this?

I already managed to to have the Raspi to load the kernel and all the device tree stuff over network. I then exported `build/tmp/work/raspberrypi4_64-poky-linux/bora-image/1.0-r0/rootfs/` as via nfs and changed the linux kernel commandline so it would use this share as nfsroot. At boot many failing services get reported and and the boot progress stops somewhere along the way. It tells me the system is in emergency mode and asks me for the root password for maintenance. I have an empty root password. When I press Control-D to continue, the same prompt reappears. Same when I simply press enter.

Has onyone any input for me? I guess I'll need to monitor what gets written to the serial port.

Regards,
Manuel




4441 - 4460 of 57813