Re: [yocto] [meta-security][PATCH] openscap: fix buildpaths issue

2023-06-24 Thread Kai Kang

On 6/22/23 07:04, akuster808 wrote:

Hello Kai,

Can you rebase  this to the latest master. There was a layer reorg 
landed during the posting of this patch.


OK. v2 will be sent.

Kai



BR,
Armin

On 6/20/23 11:55 PM, Kai Kang wrote:

From: Kai Kang 

Variables PREFERRED_PYTHON_PATH and PYTHON3_PATH are set with
${PYTHON_EXECUTABLE}. For cross compile, ${PYTHON_EXECUTABLE} may point
to other path rather than standard dir such as /usr/bin. Then the
generated library file contains such path which should NOT. Update to
make variables PREFERRED_PYTHON_PATH and PYTHON3_PATH configurable to
fix buildpaths issue:

| WARNING: openscap-1.3.7-r0 do_package_qa: QA Issue: File
| /usr/lib/libopenscap.so.25.5.1 in package openscap contains reference
| to TMPDIR [buildpaths]

Signed-off-by: Kai Kang 
---
  ...ts.txt-make-2-variables-configurable.patch | 37 +++
  .../openscap/openscap_1.3.7.bb    |  8 +++-
  2 files changed, 44 insertions(+), 1 deletion(-)
  create mode 100644 
meta-security-compliance/recipes-openscap/openscap/files/0001-CMakeLists.txt-make-2-variables-configurable.patch


diff --git 
a/meta-security-compliance/recipes-openscap/openscap/files/0001-CMakeLists.txt-make-2-variables-configurable.patch 
b/meta-security-compliance/recipes-openscap/openscap/files/0001-CMakeLists.txt-make-2-variables-configurable.patch 


new file mode 100644
index 000..953b0d9
--- /dev/null
+++ 
b/meta-security-compliance/recipes-openscap/openscap/files/0001-CMakeLists.txt-make-2-variables-configurable.patch

@@ -0,0 +1,37 @@
+From f99c3f1f516a84d33794f8e3da59adea1a12ef54 Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Tue, 20 Jun 2023 22:42:51 +0800
+Subject: [PATCH] CMakeLists.txt: make 2 variables configurable
+
+Variables PREFERRED_PYTHON_PATH and PYTHON3_PATH are set with
+${PYTHON_EXECUTABLE}. For cross compile, ${PYTHON_EXECUTABLE} may point
+to other path rather than standard dir such as /usr/bin. Then the
+generated library file contains such path which should NOT. Update to
+make variables PREFERRED_PYTHON_PATH and PYTHON3_PATH configurable to
+avoid such issue.
+
+Upstream-Status: Submitted 
[https://github.com/OpenSCAP/openscap/pull/1990]

+
+Signed-off-by: Kai Kang 
+---
+ CMakeLists.txt | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 5db014e77..74628cdd4 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -125,8 +125,8 @@ endif()
+ find_package(PythonInterp 3)
+ find_package(PythonLibs 3)
+
+-set(PREFERRED_PYTHON_PATH "${PYTHON_EXECUTABLE}")
+-set(PYTHON3_PATH "${PYTHON_EXECUTABLE}")
++set(PREFERRED_PYTHON_PATH "${PYTHON_EXECUTABLE}" CACHE PATH "Path 
to preferred Python")

++set(PYTHON3_PATH "${PYTHON_EXECUTABLE}" CACHE PATH "Path to Python3")
+
+ find_package(RPM)
+ if(RPM_FOUND)
+--
+2.34.1
+
diff --git 
a/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.7.bb 
b/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.7.bb

index cfe93f0..5ad92d4 100644
--- 
a/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.7.bb
+++ 
b/meta-security-compliance/recipes-openscap/openscap/openscap_1.3.7.bb

@@ -7,7 +7,13 @@ require openscap.inc
  inherit systemd
    SRCREV = "55efbfda0f617e05862ab6ed4862e10dbee52b03"
-SRC_URI = 
"git://github.com/OpenSCAP/openscap.git;branch=maint-1.3;protocol=https"
+SRC_URI = 
"git://github.com/OpenSCAP/openscap.git;branch=maint-1.3;protocol=https 
\

+ file://0001-CMakeLists.txt-make-2-variables-configurable.patch \
+   "
+
+EXTRA_OECMAKE += "-DPREFERRED_PYTHON_PATH=${bindir}/python3 \
+  -DPYTHON3_PATH=${bindir}/python3 \
+  "
    SYSTEMD_PACKAGES = "${PN}"
  SYSTEMD_SERVICE:${PN} = "oscap-remediate.service"







--
Kai Kang
Wind River Linux


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60431): https://lists.yoctoproject.org/g/yocto/message/60431
Mute This Topic: https://lists.yoctoproject.org/mt/99670413/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] [meta-mingw][PATCH] libiconv: update license with SPDX name

2023-06-24 Thread Kai Kang
From: Kai Kang 

License 'LGPLv3' is obsolete

  WARNING: nativesdk-libiconv-1.15-r1 do_package_qa: QA Issue: Recipe
LICENSE includes obsolete licenses LGPLv3 [obsolete-license]

so replace it with the SPDX name 'LGPL-3.0-only'.

Signed-off-by: Kai Kang 
---
 recipes-support/libiconv/libiconv_1.15.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-support/libiconv/libiconv_1.15.bb 
b/recipes-support/libiconv/libiconv_1.15.bb
index 7b2252f..b58abb4 100644
--- a/recipes-support/libiconv/libiconv_1.15.bb
+++ b/recipes-support/libiconv/libiconv_1.15.bb
@@ -6,7 +6,7 @@ SECTION = "libs"
 NOTES = "Needs to be stripped down to: ascii iso8859-1 eucjp iso-2022jp gb 
utf8"
 PROVIDES = "virtual/libiconv"
 PR = "r1"
-LICENSE = "LGPLv3"
+LICENSE = "LGPL-3.0-only"
 LIC_FILES_CHKSUM = "file://COPYING.LIB;md5=9f604d8a4f8e74f4f5140845a21b6674 \
 
file://libcharset/COPYING.LIB;md5=9f604d8a4f8e74f4f5140845a21b6674"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60430): https://lists.yoctoproject.org/g/yocto/message/60430
Mute This Topic: https://lists.yoctoproject.org/mt/99764129/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-raspberrypi] vc4-fkms-v3d vs. vc4-kms-v3d

2023-06-24 Thread Markus Volk
On Sun, Jun 25 2023 at 12:01:29 AM +0200, Manuel Wagesreither 
 wrote:
The HDMI port is unused on my raspi. I'm using the official Raspberry 
Pi 7" Touchscreen connected via DSI.


Have you also added ?

dtoverlay=vc4-kms-dsi-7inch
dtoverlay=rpi-ft5406

I never dealt with the 7'' Display but i guess they are needed for kms

hdmi_force_hotplug=1

may also be needed


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60429): https://lists.yoctoproject.org/g/yocto/message/60429
Mute This Topic: https://lists.yoctoproject.org/mt/99727959/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-raspberrypi] vc4-fkms-v3d vs. vc4-kms-v3d

2023-06-24 Thread Manuel Wagesreither
Am Sa, 24. Jun 2023, um 19:12, schrieb Markus Volk:
> Two pitfalls come to mind here
> 
> It used to be necessary to use vc4-kms-v3d-pi4 dtbo. At some point this was 
> changed so that even for the rpi4 only vc4-kms-v3d overlay had to be loaded 
> and vc4-kms-v3d-pi4 was automatically reloaded. If your software version is 
> old enough, using vc4-kms-v3d-pi4 dtoverlay might be necessary.
> 
> kms relies completely on edid. fkms is more tolerant and often displays an 
> image without a valid edid. I would therefore most likely guess a problem 
> reading the edit information. Things I would try first are using  a different 
> HDMI cable or switching the hdmi port.
> 
> On Sat, Jun 24 2023 at 06:02:52 PM +0200, Manuel Wagesreither 
>  wrote:
>> Am Sa, 24. Jun 2023, um 17:25, schrieb Khem Raj:
>>> On Sat, Jun 24, 2023 at 7:47 AM Manuel Wagesreither  
>>> wrote:
 Am Sa, 24. Jun 2023, um 00:04, schrieb Khem Raj:
 > On Fri, Jun 23, 2023 at 2:39 PM Manuel Wagesreither  
 > wrote:
 >>
 >> Hi users of meta-raspberrypi,
 >>
 >> I'd like to ask around if for you people vc4-kms-v3d (opposed to 
 >> vc4-fkms-v3d) *really* is the working way to get vc4 support on a 
 >> Raspberry Pi 4 Model B.
 >>
 >> Both on master and kirkstone, vc4-kms-v3d is the default. It's defined 
 >> in /conf/machine/raspberrypi4-64.conf:
 >>
 >> VC4DTBO ?= "vc4-kms-v3d"
 >>
 >> I was mildly surprised to find this, because on my system (running 
 >> Kirkstone) I can get the screen to work only if I specify vc4-fkms-v3d.
 >>
 >> Commit a6fa6b3aec36b92c3750852dd6788af9d2ce08f6 [1] broke my build. The 
 >> commit message further suggests that vc4-Fkms-v3d is broken, while 
 >> vc4-kms-v3d is not. So I'm wondering:hy is it exactly the other way 
 >> round on my machine?
 >>
 >> raspberrypi4: Use full kms (vc4-kms-v3d) DT overlay
 >>
 >> With latest 5.10 kernel fkms version fails to bring up VC4 and we 
 >> do not
 >> get dri device initialized ( /dev/dri ) is empty, which means we 
 >> can not
 >> launch wayland componsitors.
 >>
 >
 > We have moved away from 5.10 kernel to 5.15 and then 6.1, so its
 > possible that fkms is working fine again.
 > If you test it with both vc4graphics and userland graphics do both work ?
 
 The meta-raspberrypi commit I'm on 
 (a6fa6b3aec36b92c3750852dd6788af9d2ce08f6) has recipes for Linux 5.10.110 
 and 5.15.34 and on both of them vc4-fkms-v3d works while vc4-kms-v3d does 
 not.
 
 * When using vc4-kms-v3d, the screen goes dark very early in the boot 
 process.
 * When using vc4-kms-v3d, kmscube and weston-wayland both work.
>>> 
>>> Which release branch are you using for
>>> Your project 
>> 
>> I'm two commits behind kirkstone, on meta-raspberrypi.


The HDMI port is unused on my raspi. I'm using the official Raspberry Pi 7" 
Touchscreen connected via DSI.

Specifiying...

dtoverlay=vc4-kms-v3d
dtoverlay=vc4-kms-v3d-pi4

in config.txt doesn't change anything.

This is  what both Linux 5.10.110 and 5.15.34 prints on the serial line: 
(Screen is not working then.)

[1.400937] fb0: switching to vc4drmfb from simple
[1.402332] Console: switching to colour dummy device 80x25
[1.440694] vc4-drm gpu: bound fe40.hvs (ops vc4_hvs_ops)


When specifying

dtoverlay=vc4-fkms-v3d

both Linux versions emit:

[1.387428] fb0: switching to vc4drmfb from simple
[1.388812] Console: switching to colour dummy device 80x25
[1.390196] vc4-drm gpu: bound fe60.firmwarekms (ops vc4_fkms_ops)
[1.391001] [drm] Initialized vc4 0.0.0 20140616 for gpu on minor 0
[1.417292] Console: switching to colour frame buffer device 100x30
[1.433224] vc4-drm gpu: [drm] fb0: vc4drmfb frame buffer device

and provide a working screen.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60428): https://lists.yoctoproject.org/g/yocto/message/60428
Mute This Topic: https://lists.yoctoproject.org/mt/99727959/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[yocto] Canceled: OpenEmbedded Happy Hour June 28

2023-06-24 Thread Denys Dmytriyenko
All,

Due to the coinciding Embedded Open Source Summit (EOSS) in Prague, the OE 
Board has decided to cancel our regular Happy Hour on June 28. The next Happy 
Hour is scheduled for July 26 - see you all then. Thank you.

-- 
Regards,
Denys Dmytriyenko 
PGP: 0x420902729A92C964 - https://denix.org/0x420902729A92C964
Fingerprint: 25FC E4A5 8A72 2F69 1186  6D76 4209 0272 9A92 C964

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60427): https://lists.yoctoproject.org/g/yocto/message/60427
Mute This Topic: https://lists.yoctoproject.org/mt/99759471/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-raspberrypi] vc4-fkms-v3d vs. vc4-kms-v3d

2023-06-24 Thread Markus Volk

Two pitfalls come to mind here

It used to be necessary to use vc4-kms-v3d-pi4 dtbo. At some point this 
was changed so that even for the rpi4 only vc4-kms-v3d overlay had to 
be loaded and vc4-kms-v3d-pi4 was automatically reloaded. If your 
software version is old enough, using vc4-kms-v3d-pi4 dtoverlay might 
be necessary.


kms relies completely on edid. fkms is more tolerant and often displays 
an image without a valid edid. I would therefore most likely guess a 
problem reading the edit information. Things I would try first are 
using  a different HDMI cable or switching the hdmi port.


On Sat, Jun 24 2023 at 06:02:52 PM +0200, Manuel Wagesreither 
 wrote:

Am Sa, 24. Jun 2023, um 17:25, schrieb Khem Raj:
On Sat, Jun 24, 2023 at 7:47 AM Manuel Wagesreither 
mailto:man...@fastmail.fm>> wrote:

Am Sa, 24. Jun 2023, um 00:04, schrieb Khem Raj:
> On Fri, Jun 23, 2023 at 2:39 PM Manuel Wagesreither 
mailto:man...@fastmail.fm>> wrote:

>>
>> Hi users of meta-raspberrypi,
>>
>> I'd like to ask around if for you people vc4-kms-v3d (opposed to 
vc4-fkms-v3d) *really* is the working way to get vc4 support on a 
Raspberry Pi 4 Model B.

>>
>> Both on master and kirkstone, vc4-kms-v3d is the default. It's 
defined in /conf/machine/raspberrypi4-64.conf:

>>
>> VC4DTBO ?= "vc4-kms-v3d"
>>
>> I was mildly surprised to find this, because on my system 
(running Kirkstone) I can get the screen to work only if I specify 
vc4-fkms-v3d.

>>
>> Commit a6fa6b3aec36b92c3750852dd6788af9d2ce08f6 [1] broke my 
build. The commit message further suggests that vc4-Fkms-v3d is 
broken, while vc4-kms-v3d is not. So I'm wondering:hy is it exactly 
the other way round on my machine?

>>
>> raspberrypi4: Use full kms (vc4-kms-v3d) DT overlay
>>
>> With latest 5.10 kernel fkms version fails to bring up VC4 
and we do not
>> get dri device initialized ( /dev/dri ) is empty, which 
means we can not

>> launch wayland componsitors.
>>
>
> We have moved away from 5.10 kernel to 5.15 and then 6.1, so its
> possible that fkms is working fine again.
> If you test it with both vc4graphics and userland graphics do 
both work ?


The meta-raspberrypi commit I'm on 
(a6fa6b3aec36b92c3750852dd6788af9d2ce08f6) has recipes for Linux 
5.10.110 and 5.15.34 and on both of them vc4-fkms-v3d works while 
vc4-kms-v3d does not.


* When using vc4-kms-v3d, the screen goes dark very early in the 
boot process.

* When using vc4-kms-v3d, kmscube and weston-wayland both work.


Which release branch are you using for
Your project


I'm two commits behind kirkstone, on meta-raspberrypi.



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60426): https://lists.yoctoproject.org/g/yocto/message/60426
Mute This Topic: https://lists.yoctoproject.org/mt/99727959/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-raspberrypi] vc4-fkms-v3d vs. vc4-kms-v3d

2023-06-24 Thread Manuel Wagesreither
Am Sa, 24. Jun 2023, um 17:25, schrieb Khem Raj:
> On Sat, Jun 24, 2023 at 7:47 AM Manuel Wagesreither  
> wrote:
>> Am Sa, 24. Jun 2023, um 00:04, schrieb Khem Raj:
>> > On Fri, Jun 23, 2023 at 2:39 PM Manuel Wagesreither  
>> > wrote:
>> >>
>> >> Hi users of meta-raspberrypi,
>> >>
>> >> I'd like to ask around if for you people vc4-kms-v3d (opposed to 
>> >> vc4-fkms-v3d) *really* is the working way to get vc4 support on a 
>> >> Raspberry Pi 4 Model B.
>> >>
>> >> Both on master and kirkstone, vc4-kms-v3d is the default. It's defined in 
>> >> /conf/machine/raspberrypi4-64.conf:
>> >>
>> >> VC4DTBO ?= "vc4-kms-v3d"
>> >>
>> >> I was mildly surprised to find this, because on my system (running 
>> >> Kirkstone) I can get the screen to work only if I specify vc4-fkms-v3d.
>> >>
>> >> Commit a6fa6b3aec36b92c3750852dd6788af9d2ce08f6 [1] broke my build. The 
>> >> commit message further suggests that vc4-Fkms-v3d is broken, while 
>> >> vc4-kms-v3d is not. So I'm wondering:hy is it exactly the other way round 
>> >> on my machine?
>> >>
>> >> raspberrypi4: Use full kms (vc4-kms-v3d) DT overlay
>> >>
>> >> With latest 5.10 kernel fkms version fails to bring up VC4 and we do 
>> >> not
>> >> get dri device initialized ( /dev/dri ) is empty, which means we can 
>> >> not
>> >> launch wayland componsitors.
>> >>
>> >
>> > We have moved away from 5.10 kernel to 5.15 and then 6.1, so its
>> > possible that fkms is working fine again.
>> > If you test it with both vc4graphics and userland graphics do both work ?
>> 
>> The meta-raspberrypi commit I'm on 
>> (a6fa6b3aec36b92c3750852dd6788af9d2ce08f6) has recipes for Linux 5.10.110 
>> and 5.15.34 and on both of them vc4-fkms-v3d works while vc4-kms-v3d does 
>> not.
>> 
>> * When using vc4-kms-v3d, the screen goes dark very early in the boot 
>> process.
>> * When using vc4-kms-v3d, kmscube and weston-wayland both work.
> 
> Which release branch are you using for
> Your project 

I'm two commits behind kirkstone, on meta-raspberrypi.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60425): https://lists.yoctoproject.org/g/yocto/message/60425
Mute This Topic: https://lists.yoctoproject.org/mt/99727959/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-raspberrypi] vc4-fkms-v3d vs. vc4-kms-v3d

2023-06-24 Thread Khem Raj
On Sat, Jun 24, 2023 at 7:47 AM Manuel Wagesreither 
wrote:

> Am Sa, 24. Jun 2023, um 00:04, schrieb Khem Raj:
> > On Fri, Jun 23, 2023 at 2:39 PM Manuel Wagesreither 
> wrote:
> >>
> >> Hi users of meta-raspberrypi,
> >>
> >> I'd like to ask around if for you people vc4-kms-v3d (opposed to
> vc4-fkms-v3d) *really* is the working way to get vc4 support on a Raspberry
> Pi 4 Model B.
> >>
> >> Both on master and kirkstone, vc4-kms-v3d is the default. It's defined
> in /conf/machine/raspberrypi4-64.conf:
> >>
> >> VC4DTBO ?= "vc4-kms-v3d"
> >>
> >> I was mildly surprised to find this, because on my system (running
> Kirkstone) I can get the screen to work only if I specify vc4-fkms-v3d.
> >>
> >> Commit a6fa6b3aec36b92c3750852dd6788af9d2ce08f6 [1] broke my build. The
> commit message further suggests that vc4-Fkms-v3d is broken, while
> vc4-kms-v3d is not. So I'm wondering:hy is it exactly the other way round
> on my machine?
> >>
> >> raspberrypi4: Use full kms (vc4-kms-v3d) DT overlay
> >>
> >> With latest 5.10 kernel fkms version fails to bring up VC4 and we
> do not
> >> get dri device initialized ( /dev/dri ) is empty, which means we
> can not
> >> launch wayland componsitors.
> >>
> >
> > We have moved away from 5.10 kernel to 5.15 and then 6.1, so its
> > possible that fkms is working fine again.
> > If you test it with both vc4graphics and userland graphics do both work ?
>
> The meta-raspberrypi commit I'm on
> (a6fa6b3aec36b92c3750852dd6788af9d2ce08f6) has recipes for Linux 5.10.110
> and 5.15.34 and on both of them vc4-fkms-v3d works while vc4-kms-v3d does
> not.
>
> * When using vc4-kms-v3d, the screen goes dark very early in the boot
> process.
> * When using vc4-kms-v3d, kmscube and weston-wayland both work.


Which release branch are you using for
Your project

>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60424): https://lists.yoctoproject.org/g/yocto/message/60424
Mute This Topic: https://lists.yoctoproject.org/mt/99727959/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [meta-raspberrypi] vc4-fkms-v3d vs. vc4-kms-v3d

2023-06-24 Thread Manuel Wagesreither
Am Sa, 24. Jun 2023, um 00:04, schrieb Khem Raj:
> On Fri, Jun 23, 2023 at 2:39 PM Manuel Wagesreither  
> wrote:
>>
>> Hi users of meta-raspberrypi,
>>
>> I'd like to ask around if for you people vc4-kms-v3d (opposed to 
>> vc4-fkms-v3d) *really* is the working way to get vc4 support on a Raspberry 
>> Pi 4 Model B.
>>
>> Both on master and kirkstone, vc4-kms-v3d is the default. It's defined in 
>> /conf/machine/raspberrypi4-64.conf:
>>
>> VC4DTBO ?= "vc4-kms-v3d"
>>
>> I was mildly surprised to find this, because on my system (running 
>> Kirkstone) I can get the screen to work only if I specify vc4-fkms-v3d.
>>
>> Commit a6fa6b3aec36b92c3750852dd6788af9d2ce08f6 [1] broke my build. The 
>> commit message further suggests that vc4-Fkms-v3d is broken, while 
>> vc4-kms-v3d is not. So I'm wondering:hy is it exactly the other way round on 
>> my machine?
>>
>> raspberrypi4: Use full kms (vc4-kms-v3d) DT overlay
>>
>> With latest 5.10 kernel fkms version fails to bring up VC4 and we do not
>> get dri device initialized ( /dev/dri ) is empty, which means we can not
>> launch wayland componsitors.
>>
>
> We have moved away from 5.10 kernel to 5.15 and then 6.1, so its
> possible that fkms is working fine again.
> If you test it with both vc4graphics and userland graphics do both work ?

The meta-raspberrypi commit I'm on (a6fa6b3aec36b92c3750852dd6788af9d2ce08f6) 
has recipes for Linux 5.10.110 and 5.15.34 and on both of them vc4-fkms-v3d 
works while vc4-kms-v3d does not.

* When using vc4-kms-v3d, the screen goes dark very early in the boot process.
* When using vc4-kms-v3d, kmscube and weston-wayland both work.


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60423): https://lists.yoctoproject.org/g/yocto/message/60423
Mute This Topic: https://lists.yoctoproject.org/mt/99727959/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [PATCH 2/2] dts: evb: add sja1105 delay params

2023-06-24 Thread Zhantao Tang via lists.yoctoproject.org
This patch is to add delay params for S32G EVB boards, or else, there will
be following warning messages:

 sja1105 spi5.0: Probed switch chip: SJA1105Q
 sja1105 spi5.0: Port 0 interpreting RGMII delay settings based on "phy-mode" 
property, please update device tree to specify "rx-internal-delay-ps" and 
"tx-internal-delay-ps"
---
 arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi 
b/arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi
index d6c2463bc424..75486d696b99 100644
--- a/arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi
+++ b/arch/arm64/boot/dts/freescale/s32gxxxa-evb.dtsi
@@ -1097,6 +1097,8 @@ ports {
port@0 {
label = "sw0-p0";
phy-mode = "rgmii-id";
+   rx-internal-delay-ps = <2000>;
+   tx-internal-delay-ps = <2000>;
ethernet = <_netif2>;
reg = <0>;
 
@@ -1123,6 +1125,8 @@ enet_p2@2 {
enet_p3@3 {
label = "enet_p3";
phy-mode = "rgmii-id";
+   rx-internal-delay-ps = <2000>;
+   tx-internal-delay-ps = <2000>;
phy-handle = <_mdio_a_phy2>;
reg = <3>;
};
@@ -1130,6 +1134,8 @@ enet_p3@3 {
enet_p4@4 {
label = "enet_p4";
phy-mode = "rgmii-id";
+   rx-internal-delay-ps = <2000>;
+   tx-internal-delay-ps = <2000>;
phy-handle = <_mdio_a_phy3>;
reg = <4>;
};
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12790): 
https://lists.yoctoproject.org/g/linux-yocto/message/12790
Mute This Topic: https://lists.yoctoproject.org/mt/99749565/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [PATCH 1/2] mtd: spi-nor: add late_init callback for mx25uw51245g

2023-06-24 Thread Zhantao Tang via lists.yoctoproject.org
In commit 5273cc6df984 ("mtd: spi-nor: core: Call spi_nor_post_sfdp_fixups()
only when SFDP is defined"), the spi_nor_post_sfdp_fixups() is moved into
spi_nor_parse_sfdp() function, and will be called after the SFDP header
getted. But for S32G EVB boards, there is no valid SFDP header, then the
post_sfdp() callback can not be called to set the correct command extension
type. So we need late_init() callback setting to resolve this situation, and
for current issue, we just set the late_init to mx25uw51245g_post_sfdp_fixup
to ensure same settings as SDK for the flash chip.

Signed-off-by: Zhantao Tang 
---
 drivers/mtd/spi-nor/macronix.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi-nor/macronix.c b/drivers/mtd/spi-nor/macronix.c
index 39e5fa95714b..ffcaaf89ed36 100644
--- a/drivers/mtd/spi-nor/macronix.c
+++ b/drivers/mtd/spi-nor/macronix.c
@@ -131,6 +131,7 @@ static struct spi_nor_fixups mx25uw51245g_fixups = {
.default_init = mx25uw51245g_default_init,
.post_bfpt = mx25uw51245g_post_bfpt_fixup,
.post_sfdp = mx25uw51245g_post_sfdp_fixup,
+   .late_init = mx25uw51245g_post_sfdp_fixup,
 };
 
 static const struct flash_info macronix_nor_parts[] = {
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12788): 
https://lists.yoctoproject.org/g/linux-yocto/message/12788
Mute This Topic: https://lists.yoctoproject.org/mt/99749562/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[linux-yocto] [std/rt kernel v6.1]: nxp-s32g: fix spi-nor flash and sja1105 issues

2023-06-24 Thread Zhantao Tang via lists.yoctoproject.org
Hi Bruce,

The following two patches are to fix spi-nor flash and sja1105 issues.
Would you please help to merge them into the following:
v6.1/standard/nxp-sdk-5.15/nxp-s32g
v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g
branches?


Thanks,
Zhantao


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12789): 
https://lists.yoctoproject.org/g/linux-yocto/message/12789
Mute This Topic: https://lists.yoctoproject.org/mt/99749563/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-