|
Recipe Grep'ing
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
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:
|
||||||||||
|
|
||||||||||
|
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 requiredERROR: 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 fromdef 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 eb51e4ec321c723587cec03bb9b33b94ee43e0b0939eb43b52824e3d5cfebec2ERROR: 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
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@...>
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:
|
||||||||||
|
|
||||||||||
|
[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:
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,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,
toggle quoted message
Show quoted text
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! |
||||||||||
|
|
||||||||||
|
Re: #yocto cmake configurations
#yocto
Monsees, Steven C (US)
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
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@...>
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:
|
||||||||||
|
|
||||||||||
|
Re: #yocto cmake configurations
#yocto
Monsees, Steven C (US)
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
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:
|
||||||||||
|
|
||||||||||
|
Re: what OE/YP layers should be considered "supported"?
Robert P. J. Day
On Tue, 4 May 2021, akuster808 wrote:
Helllo Robert, I don't have an context in the email you are referring to. Can yougranted, that Q was a bit vague ... based on a suggestion of richard's, i was going to do an "audit" of OE/YP layers to see the effect of doing a particular minor cleanup, but it's not clear the requirement for wide-sweepingness that would represent a sufficient audit. would that necessarily cover every single layer identified at layers.openembedded.org? that seems a bit onerous. so is there some moderately vague definition of what constitutes a minimally representative collection of layers? rday |
||||||||||
|
|
||||||||||
|
Re: Hardknott - pseudo excluded from intercept_scripts
The following code is an effective workaround. It must be added after the core-image is inherited. 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:
-- "Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire |
||||||||||
|
|
||||||||||
|
Hardknott - pseudo excluded from intercept_scripts
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: I continued down the rabbit hole until I got here: 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? ..Ch:W.. "Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire |
||||||||||
|
|
||||||||||
|
Re: what OE/YP layers should be considered "supported"?
Helllo Robert,
On 5/4/21 2:03 PM, Robert P. J. Day wrote: related to something that richard purdie mentioned on the OE list,I don't have an context in the email you are referring to. Can you include it please? Supported will mean different things to different people. -Armin no-brainers would, of course, include: |
||||||||||
|
|
||||||||||
|
Re: #yocto cmake configurations
#yocto
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:
|
||||||||||
|
|