|
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 messageShow 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:
|
||||||||||
|
|
||||||||||
|
Re: [OE-core] [yocto] Yocto Project Status WW18`21
Richard Purdie
On Tue, 2021-05-04 at 18:38 +0200, Alexander Kanavin wrote:
On Tue, 4 May 2021 at 16:46, Stephen Jolley <sjolley.yp.pm@...> wrote:We have discussed extending it but we currently only have the funding for theWe are pleased to announce that our April 2022 release (potentially 3.5) willWhat will happen to the current LTS at that point? Will support be cut off, originally planned 2 years. Discussions are continuing but since we do all agree that the next LTS will start then, we decided to at least let people plan against that. Unless funding/support is secured, dunfell would move to community support if anyone were willing to step up, or become EOL and replaced by the new LTS. There would likely be some period of overlap of a few months to transition. There is also concern about pressuring wider community layers for longer support cycles which is something we need to think about. Cheers, Richard
|
||||||||||
|
|
||||||||||
|
Re: #yocto cmake configurations
#yocto
Monsees, Steven C (US)
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
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:
|
||||||||||
|
|
||||||||||
|
Re: [meta-rockchip][PATCH v4 3/3] linux-yocto: add an initial NanoPi-M4 BSP
Yann Dirson
(sorry, previous answer _is_ empty, wrong button)
Le mar. 4 mai 2021 à 23:03, Trevor Woerner <twoerner@...> a écrit : Hm, good catch, I ended up not activating the AP6356S in this first patch, since it would be non-functional without the proper firmware, and that one needs separate work. It makes sense not to include those options at all here. I will double-check before rerolling, IIRC it is a common block useddiff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.sccOops, is enabling this RK3288 setting an oversight? Or is it needed for HDMI by the 3399, whose legacy naming is just confusing. + -- Yann Dirson <yann@...> Blade / Shadow -- http://shadow.tech
|
||||||||||
|
|
||||||||||
|
Re: [meta-rockchip][PATCH v4 3/3] linux-yocto: add an initial NanoPi-M4 BSP
Yann Dirson
Le mar. 4 mai 2021 à 23:03, Trevor Woerner <twoerner@...> a écrit :
-- Yann Dirson <yann@...> Blade / Shadow -- http://shadow.tech
|
||||||||||
|
|
||||||||||
|
Re: #yocto cmake configurations
#yocto
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:
|
||||||||||
|
|
||||||||||
|
Re: [meta-zephyr][PATCH] CI: add Gitlab CI support
Jon Mason
Please disregard, sloppy scripting bit me
On Tue, May 4, 2021 at 4:53 PM Jon Mason via lists.yoctoproject.org <jdmason=kudzu.us@...> wrote:
|
||||||||||
|
|
||||||||||
|
[meta-zephyr][PATCH] CI: add Gitlab CI support
Jon Mason
Signed-off-by: Jon Mason <jon.mason@...>
--- .gitlab-ci.yml | 174 ++++++++++++++++++ ci/96b-avenger96.yml | 9 + ci/96b-nitrogen.yml | 6 + ci/acrn.yml | 6 + ci/base.yml | 35 ++++ ci/check-machine-coverage | 26 +++ ci/check-warnings | 18 ++ ci/jobs-to-kas | 19 ++ ci/logging.yml | 13 ++ ci/meta-oe.yml | 8 + ci/meta-python.yml | 10 + ci/qemu-cortex-m3.yml | 6 + ci/qemu-nios2.yml | 6 + ci/qemu-x86.yml | 6 + ci/testimage.yml | 5 + ci/update-repos | 40 ++++ .../zephyr-kernel/zephyr-kernel-test.inc | 3 + 17 files changed, 390 insertions(+) create mode 100644 .gitlab-ci.yml create mode 100644 ci/96b-avenger96.yml create mode 100644 ci/96b-nitrogen.yml create mode 100644 ci/acrn.yml create mode 100644 ci/base.yml create mode 100755 ci/check-machine-coverage create mode 100755 ci/check-warnings create mode 100755 ci/jobs-to-kas create mode 100644 ci/logging.yml create mode 100644 ci/meta-oe.yml create mode 100644 ci/meta-python.yml create mode 100644 ci/qemu-cortex-m3.yml create mode 100644 ci/qemu-nios2.yml create mode 100644 ci/qemu-x86.yml create mode 100644 ci/testimage.yml create mode 100755 ci/update-repos diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml new file mode 100644 index 000000000000..26bd1b7a5c62 --- /dev/null +++ b/.gitlab-ci.yml @@ -0,0 +1,174 @@ +image: ghcr.io/siemens/kas/kas-isar + + # First do a common bootstrap, and then build all the targets +stages: + - prep + - bootstrap + - build + - test + +# Common job fragment to get a worker ready +.setup: + stage: build + variables: + KAS_WORK_DIR: $CI_PROJECT_DIR/work + KAS_REPO_REF_DIR: $CI_BUILDS_DIR/persist/repos + SSTATE_DIR: $CI_BUILDS_DIR/persist/sstate + DL_DIR: $CI_BUILDS_DIR/persist/downloads + BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml + before_script: + - echo KAS_WORK_DIR = $KAS_WORK_DIR + - echo SSTATE_DIR = $SSTATE_DIR + - echo DL_DIR = $DL_DIR + - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR + +# Generalised fragment to do a Kas build +.build: + extends: .setup + script: + - KASFILES=$(./ci/jobs-to-kas $CI_JOB_NAME) + - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf' + - kas build $KASFILES + - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log + +# KAS testing +.test: + extends: .setup + stage: test + script: + - sudo chown -R builder $KAS_WORK_DIR + - sudo chgrp -R builder $KAS_WORK_DIR + - KASFILES=$(./ci/jobs-to-kas $CI_JOB_NAME) + - kas build $KASFILES -c testimage + + +# +# Prep stage, update repositories once +# +update-repos: + extends: .setup + stage: prep + script: + - flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos + + +# +# Bootstrap stage, machine coverage +# + +# What percentage of machines in the layer do we build +machine-coverage: + stage: bootstrap + script: + - ./ci/check-machine-coverage + coverage: '/Coverage: \d+/' + + +# +# Build stage, the actual build jobs +# + +96b-avenger96: + extends: .build + +96b-nitrogen: + extends: .build + +acrn: + extends: .build + +qemu-cortex-m3: + extends: .build + artifacts: + paths: + - work/build/tmp-newlib/deploy/images/qemu-cortex-m3/* + expire_in: 1 day + +qemu-nios2: + extends: .build + artifacts: + paths: + - work/build/tmp-newlib/deploy/images/qemu-nios2/* + expire_in: 1 day + allow_failure: true + +qemu-x86: + extends: .build + artifacts: + paths: + - work/build/tmp-newlib/deploy/images/qemu-x86/* + expire_in: 1 day + + +# +# Third phase, the test jobs +# + +# QEMU based machines can use testimage, others will need something else (i.e., LAVA) + +qemu-cortex-m3/testimage: + extends: .test + needs: + - job: qemu-cortex-m3 + +qemu-nios2/testimage: + extends: .test + needs: + - job: qemu-nios2 + allow_failure: true + +qemu-x86/testimage: + extends: .test + needs: + - job: qemu-x86 + + +# +# Utility tasks, not executed automatically +# + +# Make the persistant files modifiable by all runners +chmod-presistent: + extends: .setup + stage: prep + when: manual + script: + - chmod -R 755 $CI_BUILDS_DIR/persist/* + +delete-dl-dir: + extends: .setup + stage: prep + when: manual + script: + - rm -rf $DL_DIR/* + +delete-repo-dir: + extends: .setup + stage: prep + when: manual + script: + - rm -rf $KAS_REPO_REF_DIR/* + +# Delete all sstate +delete-sstate: + extends: .setup + stage: prep + when: manual + script: + - rm -rf $SSTATE_DIR/* + +# Wipe out old sstate +prune-sstate: + extends: .setup + stage: prep + when: manual + script: + - find $SSTATE_DIR -type f -atime +30 -delete + +# Report on disk usage +usage: + extends: .setup + stage: prep + when: manual + script: + - du -h -s $DL_DIR $SSTATE_DIR $KAS_REPO_REF_DIR diff --git a/ci/96b-avenger96.yml b/ci/96b-avenger96.yml new file mode 100644 index 000000000000..9ab58aa83ffa --- /dev/null +++ b/ci/96b-avenger96.yml @@ -0,0 +1,9 @@ +header: + version: 9 + includes: + - base.yml + +machine: 96b-avenger96 + +target: + - zephyr-philosophers diff --git a/ci/96b-nitrogen.yml b/ci/96b-nitrogen.yml new file mode 100644 index 000000000000..ecd96fb67136 --- /dev/null +++ b/ci/96b-nitrogen.yml @@ -0,0 +1,6 @@ +header: + version: 9 + includes: + - base.yml + +machine: 96b-nitrogen diff --git a/ci/acrn.yml b/ci/acrn.yml new file mode 100644 index 000000000000..53748defebec --- /dev/null +++ b/ci/acrn.yml @@ -0,0 +1,6 @@ +header: + version: 9 + includes: + - base.yml + +machine: acrn diff --git a/ci/base.yml b/ci/base.yml new file mode 100644 index 000000000000..1e25e6655165 --- /dev/null +++ b/ci/base.yml @@ -0,0 +1,35 @@ +header: + version: 9 + includes: + - meta-python.yml + +distro: zephyr + +defaults: + repos: + refspec: hardknott + +repos: + meta-zephyr: + + poky: + url: https://git.yoctoproject.org/git/poky + layers: + meta: + meta-poky: + +env: + BB_LOGCONFIG: "" + +local_conf_header: + base: | + CONF_VERSION = "1" + INHERIT += "rm_work" + ERROR_QA = "${WARN_QA}" + testimage: | + IMAGE_CLASSES += "testimage" + +machine: unset + +target: + - zephyr-kernel-test-all diff --git a/ci/check-machine-coverage b/ci/check-machine-coverage new file mode 100755 index 000000000000..726714d8b0fe --- /dev/null +++ b/ci/check-machine-coverage @@ -0,0 +1,26 @@ +#! /usr/bin/env python3 + +from pathlib import Path +import sys + +metazephyr = Path.cwd() + +if metazephyr.name != "meta-zephyr": + print("Not running inside meta-zephyr") + sys.exit(1) + +# All machine configurations +machines = metazephyr.glob("conf/machine/*.conf") +machines = set(p.stem for p in machines) + +# All kas files +kas = metazephyr.glob("ci/*.yml") +kas = set(p.stem for p in kas) + +missing = machines - kas +print(f"The following machines are missing: {', '.join(sorted(missing))}.") + +covered = len(machines) - len(missing) +total = len(machines) +percent = int(covered / total * 100) +print(f"Coverage: {percent}%") diff --git a/ci/check-warnings b/ci/check-warnings new file mode 100755 index 000000000000..cc396423d8bf --- /dev/null +++ b/ci/check-warnings @@ -0,0 +1,18 @@ +#! /bin/bash + +# Expects the path to a log file as $1, and if this file has any content +# then display the contents and exit with an error code. + +set -e -u + +LOGFILE=$1 + +if test -s $LOGFILE; then + echo ============================== + echo The build had warnings/errors: + echo ============================== + cat $LOGFILE + exit 1 +fi + +exit 0 diff --git a/ci/jobs-to-kas b/ci/jobs-to-kas new file mode 100755 index 000000000000..70579703bc07 --- /dev/null +++ b/ci/jobs-to-kas @@ -0,0 +1,19 @@ +#! /bin/bash + +# Read a GitLab CI job name on $1 and transform it to a +# list of Kas yaml files + +set -e -u + +# Read Job namne from $1 and split on / +IFS=/ read -r -a PARTS<<<$1 + +# Prefix each part with ci/ +PARTS=("${PARTS[@]/#/ci/}") + +# Suffix each part with .yml +PARTS=("${PARTS[@]/%/.yml}") + +# Print colon-separated +IFS=":" +echo "${PARTS[*]}" diff --git a/ci/logging.yml b/ci/logging.yml new file mode 100644 index 000000000000..3af10295f8f3 --- /dev/null +++ b/ci/logging.yml @@ -0,0 +1,13 @@ +# Python logging configuration to write all warnings to a separate file +version: 1 + +handlers: + warnings: + class: logging.FileHandler + level: WARNING + filename: warnings.log + formatter: BitBake.logfileFormatter + +loggers: + BitBake: + handlers: [warnings] diff --git a/ci/meta-oe.yml b/ci/meta-oe.yml new file mode 100644 index 000000000000..ccd34f3a3ffa --- /dev/null +++ b/ci/meta-oe.yml @@ -0,0 +1,8 @@ +header: + version: 9 + +repos: + meta-openembedded: + url: https://git.openembedded.org/meta-openembedded + layers: + meta-oe: diff --git a/ci/meta-python.yml b/ci/meta-python.yml new file mode 100644 index 000000000000..3f76118ccd09 --- /dev/null +++ b/ci/meta-python.yml @@ -0,0 +1,10 @@ +header: + version: 9 + includes: + - meta-oe.yml + +repos: + meta-openembedded: + url: https://git.openembedded.org/meta-openembedded + layers: + meta-python: diff --git a/ci/qemu-cortex-m3.yml b/ci/qemu-cortex-m3.yml new file mode 100644 index 000000000000..73b46039abed --- /dev/null +++ b/ci/qemu-cortex-m3.yml @@ -0,0 +1,6 @@ +header: + version: 9 + includes: + - base.yml + +machine: qemu-cortex-m3 diff --git a/ci/qemu-nios2.yml b/ci/qemu-nios2.yml new file mode 100644 index 000000000000..75166054c265 --- /dev/null +++ b/ci/qemu-nios2.yml @@ -0,0 +1,6 @@ +header: + version: 9 + includes: + - base.yml + +machine: qemu-nios2 diff --git a/ci/qemu-x86.yml b/ci/qemu-x86.yml new file mode 100644 index 000000000000..c5d23f471bf8 --- /dev/null +++ b/ci/qemu-x86.yml @@ -0,0 +1,6 @@ +header: + version: 9 + includes: + - base.yml + +machine: qemu-x86 diff --git a/ci/testimage.yml b/ci/testimage.yml new file mode 100644 index 000000000000..e97e8970ec5e --- /dev/null +++ b/ci/testimage.yml @@ -0,0 +1,5 @@ +header: + version: 9 + +target: + - zephyr-kernel-test-all diff --git a/ci/update-repos b/ci/update-repos new file mode 100755 index 000000000000..fa638aad2efb --- /dev/null +++ b/ci/update-repos @@ -0,0 +1,40 @@ +#! /usr/bin/env python3 + +# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches + +import sys +import os +import subprocess +import pathlib + +def repo_shortname(url): + # Taken from Kas (Repo.__getattr__) to ensure the logic is right + from urllib.parse import urlparse + url = urlparse(url) + return ('{url.netloc}{url.path}' + .format(url=url) + .replace('@', '.') + .replace(':', '.') + .replace('/', '.') + .replace('*', '.')) + +repositories = ( + "https://git.yoctoproject.org/git/poky", + "https://git.openembedded.org/meta-openembedded", +) + +if __name__ == "__main__": + if "KAS_REPO_REF_DIR" not in os.environ: + print("KAS_REPO_REF_DIR needs to be set") + sys.exit(1) + + base_repodir = pathlib.Path(os.environ["KAS_REPO_REF_DIR"]) + + for repo in repositories: + repodir = base_repodir / repo_shortname(repo) + if repodir.exists(): + print("Updating %s..." % repo) + subprocess.run(["git", "-C", repodir, "fetch"], check=True) + else: + print("Cloning %s..." % repo) + subprocess.run(["git", "clone", "--bare", repo, repodir], check=True) diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc index b6b4766692a7..f5b1f0f035a8 100644 --- a/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc +++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-test.inc @@ -5,6 +5,9 @@ ZEPHYRTESTS_remove = "fifo fpu_sharing lifo mbox mem_heap mem_pool \ # Exclude tests which does not build for various reasons ZEPHYRTESTS_remove = "gen_isr_table spinlock smp mp" +# Exclude tests that are no longer passing +ZEPHYRTESTS_remove += "common pending sleep context" + # test_context will fail because QEMU for ARM does not emulate CortexM3 BASEPRI register #ZEPHYRTESTS_remove_arm += "" -- 2.20.1
|
||||||||||
|
|
||||||||||
|
Re: [meta-rockchip][PATCH v4 3/3] linux-yocto: add an initial NanoPi-M4 BSP
Trevor Woerner
On Mon 2021-04-26 @ 04:58:10 PM, yann.dirson@... wrote:
From: Yann Dirson <yann@...>It looks to me as though the BRCMFMAC kernel config option needs to be enabled to support the AP6256S? I don't see that being enabled, does it end up being pulled in by default or as a result of the above two settings? diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.sccOops, is enabling this RK3288 setting an oversight? Or is it needed for HDMI on the RK3399? +
|
||||||||||
|
|