Date   

[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





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

 

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: #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

 

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: what OE/YP layers should be considered "supported"?

Robert P. J. Day
 

On Tue, 4 May 2021, akuster808 wrote:

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,
if one wanted to do a YP-wide "cleanup" of some indeterminate form,
what are the layers that would be considered mandatory to cover in
such a cleanup?
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
granted, 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

Chuck Wolber
 

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:

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





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


Hardknott - pseudo excluded from intercept_scripts

Chuck Wolber
 


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"?

Armin Kuster
 

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,
if one wanted to do a YP-wide "cleanup" of some indeterminate form,
what are the layers that would be considered mandatory to cover in
such a cleanup?
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:

* oe-core
* meta-openembedded

beyond that, what else? i would think:

* meta-virtualization
* meta-java
* meta-security
* ... more? ...

and there are the vendor layers:

* meta-intel
* meta-freescale
* meta-qcom
* meta-boundary

where can one stop?

rday



Re: #yocto cmake configurations #yocto

Khem Raj
 

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: [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 are pleased to announce that our April 2022 release (potentially 3.5) will 
be the next LTS as per our original two year schedule. If there are features 
desired in the next LTS, now is the time to get them submitted and stabilized
ready.
What will happen to the current LTS at that point? Will support be cut off, 
will there be a transition window, or is it currently undefined?
We have discussed extending it but we currently only have the funding for the
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

 

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: [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 :

On Mon 2021-04-26 @ 04:58:10 PM, yann.dirson@... wrote:
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 and
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 = "linux-yocto-tiny"
KERNEL_FEATURES_append = "\
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 = ""

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 | 15 ++++
.../linux/files/bsp/rockchip/nanopi-m4.scc | 5 ++
.../linux/files/bsp/rockchip/rk3399.cfg | 71 +++++++++++++++++++
.../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, 172 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.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.scc 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/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
new file mode 100644
index 0000000..7802ab3
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
@@ -0,0 +1,15 @@
+CONFIG_MFD_RK808=y
+CONFIG_COMMON_CLK_RK808=y
+
+CONFIG_REGULATOR_RK808=y
+CONFIG_REGULATOR_FAN53555=y
+
+CONFIG_MMC_BLOCK=y
+CONFIG_PWRSEQ_SIMPLE=y
+
+# RTL8211E
+CONFIG_REALTEK_PHY=m
+
+# AP6356S
+CONFIG_BT_BCM=m
+CONFIG_BT_HCIUART_BCM=y
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?
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.


diff --git a/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.scc b/recipes-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..f5f2909
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
@@ -0,0 +1,71 @@
+# A72 errata, all past revisions
+CONFIG_ARM64_ERRATUM_1319367=y
+# A53 errata, all patched on boot when needed
+CONFIG_ARM64_ERRATUM_826319=y
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_819472=y
+
+# cru
+CONFIG_CLK_RK3399=y
+
+CONFIG_PL330_DMA=y
+CONFIG_I2C_RK3X=y
+CONFIG_SERIAL_8250_DW=y
+
+# usb
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_TYPEC=y
+
+# ethernet
+CONFIG_NET_VENDOR_STMICRO=y
+CONFIG_STMMAC_ETH=m
+CONFIG_STMMAC_PLATFORM=m
+CONFIG_DWMAC_ROCKCHIP=m
+CONFIG_PHYLIB=m
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=y
+CONFIG_ROCKCHIP_DW_MIPI_DSI=y
+CONFIG_ROCKCHIP_ANALOGIX_DP=y
+CONFIG_ROCKCHIP_CDN_DP=y
+CONFIG_PHY_ROCKCHIP_DP=y
+CONFIG_DRM_DW_HDMI=m
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=m
+CONFIG_DRM_DW_HDMI_CEC=m
+CONFIG_DRM_DW_MIPI_DSI=m
+CONFIG_DRM_PANFROST=m
+
+# HDMI audio
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
+CONFIG_SND_SOC_RK3288_HDMI_ANALOG=m
Oops, is enabling this RK3288 setting an oversight? Or is it needed for HDMI
on the RK3399?
I will double-check before rerolling, IIRC it is a common block used
by the 3399,
whose legacy naming is just confusing.


+
+CONFIG_VIDEO_DEV=m
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_ROCKCHIP_RGA=m
+
+CONFIG_V4L2_H264=m
+CONFIG_MEDIA_CONTROLLER_REQUEST_API=y
+CONFIG_VIDEO_HANTRO=m
+CONFIG_VIDEO_HANTRO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_VDEC=m
+
+# usb
+CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_DUAL_ROLE=y
+
+# sd/mmc
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI_OF_ARASAN=y
+
+# temperature sensors
+CONFIG_THERMAL=y
+CONFIG_THERMAL_OF=y
+CONFIG_ROCKCHIP_THERMAL=m
+CONFIG_IIO=y
+CONFIG_ROCKCHIP_SARADC=m
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/recipes-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=y
+CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
+CONFIG_HZ_250=y
+CONFIG_CPU_IDLE=y
+CONFIG_ARM_CPUIDLE=y
+
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_COMMON_CLK_ROCKCHIP=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_I2C=y
+CONFIG_FW_LOADER=y
+CONFIG_PHY_ROCKCHIP_EMMC=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_ROCKCHIP=y
+CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+
+CONFIG_SPI=y
+CONFIG_SPI_ROCKCHIP=m
+
+CONFIG_PWM=y
+CONFIG_PWM_ROCKCHIP=y
+
+CONFIG_DRM_KMS_HELPER=m
+CONFIG_DRM_FBDEV_EMULATION=y
+CONFIG_ROCKCHIP_IOMMU=y
+CONFIG_DRM_ROCKCHIP=m
+CONFIG_DRM_BRIDGE=y
+
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_HDA_CODEC_HDMI=m
+CONFIG_SND_SOC_ROCKCHIP=m
+CONFIG_SND_SOC_ROCKCHIP_I2S=m
+CONFIG_SND_SOC_ROCKCHIP_SPDIF=m
+
+CONFIG_NVMEM=y
+CONFIG_ROCKCHIP_EFUSE=m
+
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_THERMAL=y
+CONFIG_HWMON=y
+CONFIG_THERMAL_HWMON=y
+
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_DEV_ROCKCHIP=m
+
+CONFIG_MMC_BLOCK_MINORS=32
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc b/recipes-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 := "${THISDIR}/files:"
+
+SRC_URI_append = "\
+ file://bsp;type=kmeta;subdir=kernel-meta \
+"
+
COMPATIBLE_MACHINE_marsboard-rk3066 = "marsboard-rk3066"
COMPATIBLE_MACHINE_rock2-square = "rock2-square"
COMPATIBLE_MACHINE_radxarock = "radxarock"
--
2.30.2


--
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 :

On Mon 2021-04-26 @ 04:58:10 PM, yann.dirson@... wrote:
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 and
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 = "linux-yocto-tiny"
KERNEL_FEATURES_append = "\
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 = ""

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 | 15 ++++
.../linux/files/bsp/rockchip/nanopi-m4.scc | 5 ++
.../linux/files/bsp/rockchip/rk3399.cfg | 71 +++++++++++++++++++
.../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, 172 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.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.scc 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/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
new file mode 100644
index 0000000..7802ab3
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
@@ -0,0 +1,15 @@
+CONFIG_MFD_RK808=y
+CONFIG_COMMON_CLK_RK808=y
+
+CONFIG_REGULATOR_RK808=y
+CONFIG_REGULATOR_FAN53555=y
+
+CONFIG_MMC_BLOCK=y
+CONFIG_PWRSEQ_SIMPLE=y
+
+# RTL8211E
+CONFIG_REALTEK_PHY=m
+
+# AP6356S
+CONFIG_BT_BCM=m
+CONFIG_BT_HCIUART_BCM=y
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.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..f5f2909
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
@@ -0,0 +1,71 @@
+# A72 errata, all past revisions
+CONFIG_ARM64_ERRATUM_1319367=y
+# A53 errata, all patched on boot when needed
+CONFIG_ARM64_ERRATUM_826319=y
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_819472=y
+
+# cru
+CONFIG_CLK_RK3399=y
+
+CONFIG_PL330_DMA=y
+CONFIG_I2C_RK3X=y
+CONFIG_SERIAL_8250_DW=y
+
+# usb
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_TYPEC=y
+
+# ethernet
+CONFIG_NET_VENDOR_STMICRO=y
+CONFIG_STMMAC_ETH=m
+CONFIG_STMMAC_PLATFORM=m
+CONFIG_DWMAC_ROCKCHIP=m
+CONFIG_PHYLIB=m
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=y
+CONFIG_ROCKCHIP_DW_MIPI_DSI=y
+CONFIG_ROCKCHIP_ANALOGIX_DP=y
+CONFIG_ROCKCHIP_CDN_DP=y
+CONFIG_PHY_ROCKCHIP_DP=y
+CONFIG_DRM_DW_HDMI=m
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=m
+CONFIG_DRM_DW_HDMI_CEC=m
+CONFIG_DRM_DW_MIPI_DSI=m
+CONFIG_DRM_PANFROST=m
+
+# HDMI audio
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
+CONFIG_SND_SOC_RK3288_HDMI_ANALOG=m
Oops, is enabling this RK3288 setting an oversight? Or is it needed for HDMI
on the RK3399?

+
+CONFIG_VIDEO_DEV=m
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_ROCKCHIP_RGA=m
+
+CONFIG_V4L2_H264=m
+CONFIG_MEDIA_CONTROLLER_REQUEST_API=y
+CONFIG_VIDEO_HANTRO=m
+CONFIG_VIDEO_HANTRO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_VDEC=m
+
+# usb
+CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_DUAL_ROLE=y
+
+# sd/mmc
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI_OF_ARASAN=y
+
+# temperature sensors
+CONFIG_THERMAL=y
+CONFIG_THERMAL_OF=y
+CONFIG_ROCKCHIP_THERMAL=m
+CONFIG_IIO=y
+CONFIG_ROCKCHIP_SARADC=m
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/recipes-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=y
+CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
+CONFIG_HZ_250=y
+CONFIG_CPU_IDLE=y
+CONFIG_ARM_CPUIDLE=y
+
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_COMMON_CLK_ROCKCHIP=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_I2C=y
+CONFIG_FW_LOADER=y
+CONFIG_PHY_ROCKCHIP_EMMC=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_ROCKCHIP=y
+CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+
+CONFIG_SPI=y
+CONFIG_SPI_ROCKCHIP=m
+
+CONFIG_PWM=y
+CONFIG_PWM_ROCKCHIP=y
+
+CONFIG_DRM_KMS_HELPER=m
+CONFIG_DRM_FBDEV_EMULATION=y
+CONFIG_ROCKCHIP_IOMMU=y
+CONFIG_DRM_ROCKCHIP=m
+CONFIG_DRM_BRIDGE=y
+
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_HDA_CODEC_HDMI=m
+CONFIG_SND_SOC_ROCKCHIP=m
+CONFIG_SND_SOC_ROCKCHIP_I2S=m
+CONFIG_SND_SOC_ROCKCHIP_SPDIF=m
+
+CONFIG_NVMEM=y
+CONFIG_ROCKCHIP_EFUSE=m
+
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_THERMAL=y
+CONFIG_HWMON=y
+CONFIG_THERMAL_HWMON=y
+
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_DEV_ROCKCHIP=m
+
+CONFIG_MMC_BLOCK_MINORS=32
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc b/recipes-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 := "${THISDIR}/files:"
+
+SRC_URI_append = "\
+ file://bsp;type=kmeta;subdir=kernel-meta \
+"
+
COMPATIBLE_MACHINE_marsboard-rk3066 = "marsboard-rk3066"
COMPATIBLE_MACHINE_rock2-square = "rock2-square"
COMPATIBLE_MACHINE_radxarock = "radxarock"
--
2.30.2


--
Yann Dirson <yann@...>
Blade / Shadow -- http://shadow.tech


Re: #yocto cmake configurations #yocto

Khem Raj
 

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: [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:

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




[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@...>

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 and
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 = "linux-yocto-tiny"
KERNEL_FEATURES_append = "\
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 = ""

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 | 15 ++++
.../linux/files/bsp/rockchip/nanopi-m4.scc | 5 ++
.../linux/files/bsp/rockchip/rk3399.cfg | 71 +++++++++++++++++++
.../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, 172 insertions(+)
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-standard.scc
create mode 100644 recipes-kernel/linux/files/bsp/rockchip/nanopi-m4-tiny.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.scc 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/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
new file mode 100644
index 0000000..7802ab3
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/nanopi-m4.cfg
@@ -0,0 +1,15 @@
+CONFIG_MFD_RK808=y
+CONFIG_COMMON_CLK_RK808=y
+
+CONFIG_REGULATOR_RK808=y
+CONFIG_REGULATOR_FAN53555=y
+
+CONFIG_MMC_BLOCK=y
+CONFIG_PWRSEQ_SIMPLE=y
+
+# RTL8211E
+CONFIG_REALTEK_PHY=m
+
+# AP6356S
+CONFIG_BT_BCM=m
+CONFIG_BT_HCIUART_BCM=y
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.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..f5f2909
--- /dev/null
+++ b/recipes-kernel/linux/files/bsp/rockchip/rk3399.cfg
@@ -0,0 +1,71 @@
+# A72 errata, all past revisions
+CONFIG_ARM64_ERRATUM_1319367=y
+# A53 errata, all patched on boot when needed
+CONFIG_ARM64_ERRATUM_826319=y
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_819472=y
+
+# cru
+CONFIG_CLK_RK3399=y
+
+CONFIG_PL330_DMA=y
+CONFIG_I2C_RK3X=y
+CONFIG_SERIAL_8250_DW=y
+
+# usb
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_TYPEC=y
+
+# ethernet
+CONFIG_NET_VENDOR_STMICRO=y
+CONFIG_STMMAC_ETH=m
+CONFIG_STMMAC_PLATFORM=m
+CONFIG_DWMAC_ROCKCHIP=m
+CONFIG_PHYLIB=m
+
+# display
+CONFIG_ROCKCHIP_DW_HDMI=y
+CONFIG_ROCKCHIP_DW_MIPI_DSI=y
+CONFIG_ROCKCHIP_ANALOGIX_DP=y
+CONFIG_ROCKCHIP_CDN_DP=y
+CONFIG_PHY_ROCKCHIP_DP=y
+CONFIG_DRM_DW_HDMI=m
+CONFIG_DRM_DW_HDMI_I2S_AUDIO=m
+CONFIG_DRM_DW_HDMI_CEC=m
+CONFIG_DRM_DW_MIPI_DSI=m
+CONFIG_DRM_PANFROST=m
+
+# HDMI audio
+CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
+CONFIG_SND_SOC_RK3288_HDMI_ANALOG=m
Oops, is enabling this RK3288 setting an oversight? Or is it needed for HDMI
on the RK3399?

+
+CONFIG_VIDEO_DEV=m
+CONFIG_V4L_MEM2MEM_DRIVERS=y
+CONFIG_VIDEO_ROCKCHIP_RGA=m
+
+CONFIG_V4L2_H264=m
+CONFIG_MEDIA_CONTROLLER_REQUEST_API=y
+CONFIG_VIDEO_HANTRO=m
+CONFIG_VIDEO_HANTRO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_VDEC=m
+
+# usb
+CONFIG_USB_DWC2=y
+CONFIG_USB_DWC3=y
+CONFIG_USB_DWC3_DUAL_ROLE=y
+
+# sd/mmc
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI_OF_ARASAN=y
+
+# temperature sensors
+CONFIG_THERMAL=y
+CONFIG_THERMAL_OF=y
+CONFIG_ROCKCHIP_THERMAL=m
+CONFIG_IIO=y
+CONFIG_ROCKCHIP_SARADC=m
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/recipes-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=y
+CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
+CONFIG_HZ_250=y
+CONFIG_CPU_IDLE=y
+CONFIG_ARM_CPUIDLE=y
+
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_COMMON_CLK_ROCKCHIP=y
+CONFIG_REGULATOR=y
+CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_PWM=y
+CONFIG_I2C=y
+CONFIG_FW_LOADER=y
+CONFIG_PHY_ROCKCHIP_EMMC=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_ROCKCHIP=y
+CONFIG_ROCKCHIP_IODOMAIN=y
+CONFIG_ROCKCHIP_PM_DOMAINS=y
+
+CONFIG_SPI=y
+CONFIG_SPI_ROCKCHIP=m
+
+CONFIG_PWM=y
+CONFIG_PWM_ROCKCHIP=y
+
+CONFIG_DRM_KMS_HELPER=m
+CONFIG_DRM_FBDEV_EMULATION=y
+CONFIG_ROCKCHIP_IOMMU=y
+CONFIG_DRM_ROCKCHIP=m
+CONFIG_DRM_BRIDGE=y
+
+CONFIG_SND=y
+CONFIG_SND_SOC=y
+CONFIG_SND_HDA_CODEC_HDMI=m
+CONFIG_SND_SOC_ROCKCHIP=m
+CONFIG_SND_SOC_ROCKCHIP_I2S=m
+CONFIG_SND_SOC_ROCKCHIP_SPDIF=m
+
+CONFIG_NVMEM=y
+CONFIG_ROCKCHIP_EFUSE=m
+
+CONFIG_CPU_FREQ=y
+CONFIG_CPU_FREQ_THERMAL=y
+CONFIG_HWMON=y
+CONFIG_THERMAL_HWMON=y
+
+CONFIG_CRYPTO_HW=y
+CONFIG_CRYPTO_DEV_ROCKCHIP=m
+
+CONFIG_MMC_BLOCK_MINORS=32
diff --git a/recipes-kernel/linux/files/bsp/rockchip/rockchip.scc b/recipes-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 := "${THISDIR}/files:"
+
+SRC_URI_append = "\
+ file://bsp;type=kmeta;subdir=kernel-meta \
+"
+
COMPATIBLE_MACHINE_marsboard-rk3066 = "marsboard-rk3066"
COMPATIBLE_MACHINE_rock2-square = "rock2-square"
COMPATIBLE_MACHINE_radxarock = "radxarock"
--
2.30.2


what OE/YP layers should be considered "supported"?

Robert P. J. Day
 

related to something that richard purdie mentioned on the OE list,
if one wanted to do a YP-wide "cleanup" of some indeterminate form,
what are the layers that would be considered mandatory to cover in
such a cleanup?

no-brainers would, of course, include:

* oe-core
* meta-openembedded

beyond that, what else? i would think:

* meta-virtualization
* meta-java
* meta-security
* ... more? ...

and there are the vendor layers:

* meta-intel
* meta-freescale
* meta-qcom
* meta-boundary

where can one stop?

rday


Re: [meta-rockchip][PATCH v4 2/3] NanoPi-M4: declare "usbhost" and "serial" in MACHINE_FEATURES

Trevor Woerner
 

On Mon 2021-04-26 @ 04:58:09 PM, yann.dirson@... wrote:
From: Yann Dirson <yann@...>

Signed-off-by: Yann Dirson <yann@...>
applied to master, thanks!

5281 - 5300 of 58636