[yocto] find: unrecognized: -printf
Greetings ! I am trying to add "etckeeper" to yocto . I have written a recipe and added it in my Rootfs . But when I try to commit , I am getting the below error log: - root@imx6ulevk:~# etckeeper commit "First commit of my /etc directory" find: unrecognized: -printf BusyBox v1.31.0 (2023-10-18 07:46:50 UTC) multi-call binary. Usage: find [-HL] [PATH]... [OPTIONS] [ACTIONS] - I tried enabling the -printf for find in busybox but I could not able to see in busybox menuconfig . Requesting your suggestions to resolve this issue. Thanks in advance -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61426): https://lists.yoctoproject.org/g/yocto/message/61426 Mute This Topic: https://lists.yoctoproject.org/mt/102076007/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 10/10] drivers: mmc: host: sdhci_am654: fix start loop index
From: Nitin Yadav
commit 527095165281cbc60a1b42995c1e55e6756cbe93 from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
ti,otap-del-sel-legacy/ti,itap-del-sel-legacy passed
from DT are currently ignored for all SD/MMC and eMMC
modes.
Fix this by making start loop index to MMC_TIMING_LEGACY.
Fixes: 8ee5fc0e0b3be ("mmc: sdhci_am654: Update OTAPDLY writes")
Signed-off-by: Nitin Yadav
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Xulin Sun
---
drivers/mmc/host/sdhci_am654.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci_am654.c b/drivers/mmc/host/sdhci_am654.c
index b5bd34804d81..6d7681956b19 100644
--- a/drivers/mmc/host/sdhci_am654.c
+++ b/drivers/mmc/host/sdhci_am654.c
@@ -623,7 +623,7 @@ static int sdhci_am654_get_otap_delay(struct sdhci_host
*host,
return 0;
}
- for (i = MMC_TIMING_MMC_HS; i <= MMC_TIMING_MMC_HS400; i++) {
+ for (i = MMC_TIMING_LEGACY; i <= MMC_TIMING_MMC_HS400; i++) {
ret = device_property_read_u32(dev, td[i].otap_binding,
_am654->otap_del_sel[i]);
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13214):
https://lists.yoctoproject.org/g/linux-yocto/message/13214
Mute This Topic: https://lists.yoctoproject.org/mt/102074939/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 09/10] arm64: dts: ti: k3-j784s4-evm: Correct Pin mux offset for ADC
From: Udit Kumar
commit fa3fc9dd2eae576a047cefa1bed9b8568143a0a8 from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
Commit 8be3ac2d8bd77bb9cb9ddbb7a545decf9f5e4181 Upstream.
After splitting wkup_pmx pin mux for J784S4 into four regions.
Pin mux offset for ADC nodes were not updated to align with new
regions, due to this while probing ADC driver out of range
error was seen.
Pin mux offsets for ADC nodes are corrected in this patch.
Fixes: 14462bd0b247 ("arm64: dts: ti: k3-j784s4: Fix wakeup pinmux range and
pinctrl node offsets")
Signed-off-by: Udit Kumar
Reviewed-by: Vaishnav Achath
Link: https://lore.kernel.org/r/20230809050108.751164-1-u-kum...@ti.com
Signed-off-by: Nishanth Menon
Reviewed-by: Bhavya Kapoor
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Xulin Sun
---
arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 32
1 file changed, 16 insertions(+), 16 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
index c029005f3ac6..b2970e9eb1ff 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
@@ -420,27 +420,27 @@ J784S4_WKUP_IOPAD(0x030, PIN_INPUT, 0) /* (B35)
MCU_MDIO0_MDIO */
mcu_adc0_pins_default: mcu-adc0-pins-default {
pinctrl-single,pins = <
- J784S4_WKUP_IOPAD(0x134, PIN_INPUT, 0) /* (P36)
MCU_ADC0_AIN0 */
- J784S4_WKUP_IOPAD(0x138, PIN_INPUT, 0) /* (V36)
MCU_ADC0_AIN1 */
- J784S4_WKUP_IOPAD(0x13c, PIN_INPUT, 0) /* (T34)
MCU_ADC0_AIN2 */
- J784S4_WKUP_IOPAD(0x140, PIN_INPUT, 0) /* (T36)
MCU_ADC0_AIN3 */
- J784S4_WKUP_IOPAD(0x144, PIN_INPUT, 0) /* (P34)
MCU_ADC0_AIN4 */
- J784S4_WKUP_IOPAD(0x148, PIN_INPUT, 0) /* (R37)
MCU_ADC0_AIN5 */
- J784S4_WKUP_IOPAD(0x14c, PIN_INPUT, 0) /* (R33)
MCU_ADC0_AIN6 */
- J784S4_WKUP_IOPAD(0x150, PIN_INPUT, 0) /* (V38)
MCU_ADC0_AIN7 */
+ J784S4_WKUP_IOPAD(0x0cc, PIN_INPUT, 0) /* (P36)
MCU_ADC0_AIN0 */
+ J784S4_WKUP_IOPAD(0x0d0, PIN_INPUT, 0) /* (V36)
MCU_ADC0_AIN1 */
+ J784S4_WKUP_IOPAD(0x0d4, PIN_INPUT, 0) /* (T34)
MCU_ADC0_AIN2 */
+ J784S4_WKUP_IOPAD(0x0d8, PIN_INPUT, 0) /* (T36)
MCU_ADC0_AIN3 */
+ J784S4_WKUP_IOPAD(0x0dc, PIN_INPUT, 0) /* (P34)
MCU_ADC0_AIN4 */
+ J784S4_WKUP_IOPAD(0x0e0, PIN_INPUT, 0) /* (R37)
MCU_ADC0_AIN5 */
+ J784S4_WKUP_IOPAD(0x0e4, PIN_INPUT, 0) /* (R33)
MCU_ADC0_AIN6 */
+ J784S4_WKUP_IOPAD(0x0e8, PIN_INPUT, 0) /* (V38)
MCU_ADC0_AIN7 */
>;
};
mcu_adc1_pins_default: mcu-adc1-pins-default {
pinctrl-single,pins = <
- J784S4_WKUP_IOPAD(0x154, PIN_INPUT, 0) /* (Y38)
MCU_ADC1_AIN0 */
- J784S4_WKUP_IOPAD(0x158, PIN_INPUT, 0) /* (Y34)
MCU_ADC1_AIN1 */
- J784S4_WKUP_IOPAD(0x15c, PIN_INPUT, 0) /* (V34)
MCU_ADC1_AIN2 */
- J784S4_WKUP_IOPAD(0x160, PIN_INPUT, 0) /* (W37)
MCU_ADC1_AIN3 */
- J784S4_WKUP_IOPAD(0x164, PIN_INPUT, 0) /* (AA37)
MCU_ADC1_AIN4 */
- J784S4_WKUP_IOPAD(0x168, PIN_INPUT, 0) /* (W33)
MCU_ADC1_AIN5 */
- J784S4_WKUP_IOPAD(0x16c, PIN_INPUT, 0) /* (U33)
MCU_ADC1_AIN6 */
- J784S4_WKUP_IOPAD(0x170, PIN_INPUT, 0) /* (Y36)
MCU_ADC1_AIN7 */
+ J784S4_WKUP_IOPAD(0x0ec, PIN_INPUT, 0) /* (Y38)
MCU_ADC1_AIN0 */
+ J784S4_WKUP_IOPAD(0x0f0, PIN_INPUT, 0) /* (Y34)
MCU_ADC1_AIN1 */
+ J784S4_WKUP_IOPAD(0x0f4, PIN_INPUT, 0) /* (V34)
MCU_ADC1_AIN2 */
+ J784S4_WKUP_IOPAD(0x0f8, PIN_INPUT, 0) /* (W37)
MCU_ADC1_AIN3 */
+ J784S4_WKUP_IOPAD(0x0fc, PIN_INPUT, 0) /* (AA37)
MCU_ADC1_AIN4 */
+ J784S4_WKUP_IOPAD(0x100, PIN_INPUT, 0) /* (W33)
MCU_ADC1_AIN5 */
+ J784S4_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (U33)
MCU_ADC1_AIN6 */
+ J784S4_WKUP_IOPAD(0x108, PIN_INPUT, 0) /* (Y36)
MCU_ADC1_AIN7 */
>;
};
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13213):
https://lists.yoctoproject.org/g/linux-yocto/message/13213
Mute This Topic: https://lists.yoctoproject.org/mt/102074937/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 08/10] HACK: arm64: dts: ti: k3-j784s4-evm: Remove HS400 mode support for eMMC
From: Udit Kumar
commit ca6a775097f0c879eaa7a2ddfe79c09fd08dffb6 from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
The eMMC fails to enumerate intermittently on HS400 mode. Also
observing multiple CQE recovery warnings.
Update the sdhci0 node to disable HS400.
Cc: Vignesh Raghavendra
Cc: Bhavya Kapoor
Cc: Siddharth Vadapalli
Signed-off-by: Udit Kumar
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Xulin Sun
---
arch/arm64/boot/dts/ti/k3-j784s4-evm.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
index 33285ab845f6..c029005f3ac6 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-evm.dts
@@ -871,6 +871,7 @@ _sdhci0 {
non-removable;
ti,driver-strength-ohm = <50>;
disable-wp;
+ no-mmc-hs400;
};
_sdhci1 {
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13212):
https://lists.yoctoproject.org/g/linux-yocto/message/13212
Mute This Topic: https://lists.yoctoproject.org/mt/102074936/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 06/10] arm64: dts: k3-j721s2: Fix pin mux for ospi i2c and pmic node
From: Udit Kumar
commit 696d9e2d712fb42014a420942f9c787339f4a568 from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
After splitting the wkup_pmx into four region.
I2C and PMIC pin muxes was falling outside the assigned region.
Also removed unused pin from OSPI pin mux.
Fixes: c33b294d75dd ("arm64: dts: ti: k3-j721s2: Fix wkup pinmux range")
Cc: Esteban Blanc
Cc: Vaishnav Achath
Cc: Apurva Nandan
Cc: Sinthu Raja
Cc: Vignesh Raghavendra
Signed-off-by: Udit Kumar
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Xulin Sun
---
.../dts/ti/k3-j721s2-common-proc-board.dts| 1 -
arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi | 25 +--
2 files changed, 12 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts
b/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts
index 9027bf34..74cae2ead63d 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts
@@ -273,7 +273,6 @@ mcu_fss0_ospi1_pins_default: mcu-fss0-ospi1-pins-default {
pinctrl-single,pins = <
J721S2_WKUP_IOPAD(0x008, PIN_OUTPUT, 0) /* (A19)
MCU_OSPI1_CLK */
J721S2_WKUP_IOPAD(0x024, PIN_OUTPUT, 0) /* (D20)
MCU_OSPI1_CSn0 */
- J721S2_WKUP_IOPAD(0x028, PIN_OUTPUT, 0) /* (C21)
MCU_OSPI1_CSn1 */
J721S2_WKUP_IOPAD(0x014, PIN_INPUT, 0) /* (D21)
MCU_OSPI1_D0 */
J721S2_WKUP_IOPAD(0x018, PIN_INPUT, 0) /* (G20)
MCU_OSPI1_D1 */
J721S2_WKUP_IOPAD(0x01c, PIN_INPUT, 0) /* (C20)
MCU_OSPI1_D2 */
diff --git a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
index d44605773dc0..0c7132206b3d 100644
--- a/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi
@@ -190,9 +190,6 @@ mcu_fss0_ospi0_pins_default: mcu-fss0-ospi0-pins-default {
pinctrl-single,pins = <
J721S2_WKUP_IOPAD(0x000, PIN_OUTPUT, 0) /* (D19)
MCU_OSPI0_CLK */
J721S2_WKUP_IOPAD(0x02c, PIN_OUTPUT, 0) /* (F15)
MCU_OSPI0_CSn0 */
- J721S2_WKUP_IOPAD(0x030, PIN_OUTPUT, 0) /* (G17)
MCU_OSPI0_CSn1 */
- J721S2_WKUP_IOPAD(0x038, PIN_OUTPUT, 0) /* (F14)
MCU_OSPI0_CSn2 */
- J721S2_WKUP_IOPAD(0x03c, PIN_OUTPUT, 0) /* (F17)
MCU_OSPI0_CSn3 */
J721S2_WKUP_IOPAD(0x00c, PIN_INPUT, 0) /* (C19)
MCU_OSPI0_D0 */
J721S2_WKUP_IOPAD(0x010, PIN_INPUT, 0) /* (F16)
MCU_OSPI0_D1 */
J721S2_WKUP_IOPAD(0x014, PIN_INPUT, 0) /* (G15)
MCU_OSPI0_D2 */
@@ -207,6 +204,15 @@ J721S2_WKUP_IOPAD(0x004, PIN_INPUT, 0) /* (E20)
MCU_OSPI0_LBCLKO */
};
};
+_pmx1 {
+ pmic_irq_pins_default: pmic-irq-pins-default {
+ pinctrl-single,pins = <
+ /* (C21) MCU_OSPI1_CSn1.WKUP_GPIO0_39 */
+ J721S2_WKUP_IOPAD(0x028, PIN_INPUT, 7)
+ >;
+ };
+};
+
_pmx0 {
main_i2c0_pins_default: main-i2c0-pins-default {
pinctrl-single,pins = <
@@ -248,18 +254,11 @@ _mcan16 {
phys = <>;
};
-_pmx0 {
- pmic_irq_pins_default: pmic-irq-pins-default {
- pinctrl-single,pins = <
- /* (C21) MCU_OSPI1_CSn1.WKUP_GPIO0_39 */
- J721S2_WKUP_IOPAD(0x060, PIN_INPUT, 7)
- >;
- };
-
+_pmx2 {
wkup_i2c0_pins_default: wkup_i2c0_pins_default {
pinctrl-single,pins = <
- J721S2_WKUP_IOPAD(0x100, PIN_INPUT, 0) /* (H24)
WKUP_I2C0_SCL */
- J721S2_WKUP_IOPAD(0x104, PIN_INPUT, 0) /* (H27)
WKUP_I2C0_SDA */
+ J721S2_WKUP_IOPAD(0x98, PIN_INPUT, 0) /* (H24)
WKUP_I2C0_SCL */
+ J721S2_WKUP_IOPAD(0x9c, PIN_INPUT, 0) /* (H27)
WKUP_I2C0_SDA */
>;
};
};
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13210):
https://lists.yoctoproject.org/g/linux-yocto/message/13210
Mute This Topic: https://lists.yoctoproject.org/mt/102074934/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 07/10] arm64: dts: k3-am68-sk: Fix pin mux csi for OV5640 overlay
From: Udit Kumar
commit 7e7d44cc4b3b9694558f7e81bb1fdebb63007090 from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
After splitting the wkup_pmx into four region.
CSI pin mux was falling outside the assigned region.
Fixes: c33b294d75dd ("arm64: dts: ti: k3-j721s2: Fix wkup pinmux range")
Cc: Vaishnav Achath
Cc: Sinthu Raja
Cc: Vignesh Raghavendra
Signed-off-by: Udit Kumar
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Xulin Sun
---
arch/arm64/boot/dts/ti/k3-am68-sk-bb-csi2-ov5640.dtso | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/ti/k3-am68-sk-bb-csi2-ov5640.dtso
b/arch/arm64/boot/dts/ti/k3-am68-sk-bb-csi2-ov5640.dtso
index 379ad095aa09..d77605ac48b8 100644
--- a/arch/arm64/boot/dts/ti/k3-am68-sk-bb-csi2-ov5640.dtso
+++ b/arch/arm64/boot/dts/ti/k3-am68-sk-bb-csi2-ov5640.dtso
@@ -11,10 +11,10 @@
#include
#include "k3-pinctrl.h"
-_pmx0 {
+_pmx2 {
csi2_exp_refclk_pins_default: csi2-exp-refclk-pins-default {
pinctrl-single,pins = <
- J721S2_IOPAD(0x0ec, PIN_OUTPUT, 6) /* (F25)
WKUP_GPIO0_11.MCU_CLKOUT0 */
+ J721S2_IOPAD(0x084, PIN_OUTPUT, 6) /* (F25)
WKUP_GPIO0_11.MCU_CLKOUT0 */
>;
};
};
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13211):
https://lists.yoctoproject.org/g/linux-yocto/message/13211
Mute This Topic: https://lists.yoctoproject.org/mt/102074935/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 05/10] dt-bindings: thermal: k3-j72xx: conditionally require efuse reg range
From: Bryan Brattlof commit c3bb4011ec46d9ac09ad127c749df13d2e7fb806 from git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git commit c4026d3e2578291016703cd75f3a6f786f60cd80 upstream Only some of TI's J721E SoCs will need a eFuse register range mapped to determine if they're affected by TI's i2128 erratum. All other SoC will not need this eFuse range to function properly Update the bindings for the k3_j72xx_bandgap thermal driver so other devices will only need two register ranges Signed-off-by: Bryan Brattlof Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20221031232702.10339-7...@ti.com Signed-off-by: Daniel Lezcano Signed-off-by: Keerthy Signed-off-by: Vignesh Raghavendra Signed-off-by: Xulin Sun --- .../bindings/thermal/ti,j72xx-thermal.yaml | 16 1 file changed, 16 insertions(+) diff --git a/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml b/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml index 3bb870a26872..0509c9cec224 100644 --- a/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml @@ -37,6 +37,7 @@ properties: devices to function properly. This eFuse region provides the information needed for these SoCs to report temperatures accurately. +minItems: 2 power-domains: maxItems: 1 @@ -44,6 +45,21 @@ properties: "#thermal-sensor-cells": const: 1 +allOf: + - if: + properties: +compatible: + contains: +const: ti,j721e-vtm +then: + properties: +reg: + minItems: 3 +else: + properties: +reg: + maxItems: 2 + required: - compatible - reg -- 2.35.5 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13209): https://lists.yoctoproject.org/g/linux-yocto/message/13209 Mute This Topic: https://lists.yoctoproject.org/mt/102074933/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 03/10] thermal/drivers/k3_j72xx_bandgap: Map fuse_base only for erratum workaround
From: Bryan Brattlof
commit a7119d957b2a8a7df21dc4f5ca87759728531a53 from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
commit 366444ebe7e2e1c987c6a07551f06db4b5b7c0ad upstream
Some of TI's J721E SoCs require a software trimming procedure for the
temperature monitors to function properly. To determine if a particular
J721E is not affected by this erratum, both bits in the WKUP_SPARE_FUSE0
region must be set. Other SoCs, not affected by this erratum, will not
need this region.
Map the 'fuse_base' region only when the erratum fix is needed.
Signed-off-by: Bryan Brattlof
Link: https://lore.kernel.org/r/20221031232702.10339-5...@ti.com
Signed-off-by: Daniel Lezcano
Signed-off-by: Keerthy
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Xulin Sun
---
drivers/thermal/k3_j72xx_bandgap.c | 34 +++---
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/drivers/thermal/k3_j72xx_bandgap.c
b/drivers/thermal/k3_j72xx_bandgap.c
index ca2747c6c907..bdccf35deebc 100644
--- a/drivers/thermal/k3_j72xx_bandgap.c
+++ b/drivers/thermal/k3_j72xx_bandgap.c
@@ -497,15 +497,32 @@ static int k3_j72xx_bandgap_probe(struct platform_device
*pdev)
if (IS_ERR(bgp->cfg2_base))
return PTR_ERR(bgp->cfg2_base);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- fuse_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(fuse_base))
- return PTR_ERR(fuse_base);
-
driver_data = of_device_get_match_data(dev);
if (driver_data)
workaround_needed = driver_data->has_errata_i2128;
+ /*
+* Some of TI's J721E SoCs require a software trimming procedure
+* for the temperature monitors to function properly. To determine
+* if this particular SoC is NOT affected, both bits in the
+* WKUP_SPARE_FUSE0[31:30] will be set (0xC000) indicating
+* when software trimming should NOT be applied.
+*
+* https://www.ti.com/lit/er/sprz455c/sprz455c.pdf
+*/
+ if (workaround_needed) {
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
+ fuse_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(fuse_base))
+ return PTR_ERR(fuse_base);
+
+ if ((readl(fuse_base) & 0xc000) == 0xc000)
+ workaround_needed = false;
+ }
+
+ dev_dbg(bgp->dev, "Work around %sneeded\n",
+ workaround_needed ? "" : "not ");
+
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
if (ret < 0) {
@@ -538,13 +555,6 @@ static int k3_j72xx_bandgap_probe(struct platform_device
*pdev)
goto err_free_ref_table;
}
- /* Workaround not needed if bit30/bit31 is set even for J721e */
- if (workaround_needed && (readl(fuse_base + 0x0) & 0xc000) ==
0xc000)
- workaround_needed = false;
-
- dev_dbg(bgp->dev, "Work around %sneeded\n",
- workaround_needed ? "" : "not ");
-
if (!workaround_needed)
init_table(5, ref_table, golden_factors);
else
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13208):
https://lists.yoctoproject.org/g/linux-yocto/message/13208
Mute This Topic: https://lists.yoctoproject.org/mt/102074932/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 04/10] dt-bindings: thermal: k3-j72xx: elaborate on binding description
From: Bryan Brattlof commit 0d9ecfae1ec9e1556b8a943dbd9deea94e8d4870 from git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git commit effe8db0a421480fc4dad0c7bf380b8e245cbb8c upstream Elaborate on the function of this device node as well as some of the properties this node uses. Signed-off-by: Bryan Brattlof Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20221031232702.10339-6...@ti.com Signed-off-by: Daniel Lezcano Signed-off-by: Keerthy Signed-off-by: Vignesh Raghavendra Signed-off-by: Xulin Sun --- .../bindings/thermal/ti,j72xx-thermal.yaml| 19 ++- 1 file changed, 18 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml b/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml index c74f124ebfc0..3bb870a26872 100644 --- a/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml +++ b/Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml @@ -9,6 +9,19 @@ title: Texas Instruments J72XX VTM (DTS) binding maintainers: - Keerthy +description: | + The TI K3 family of SoCs typically have a Voltage & Thermal + Management (VTM) device to control up to 8 temperature diode + sensors to measure silicon junction temperatures from different + hotspots of the chip as well as provide temperature, interrupt + and alerting information. + + The following polynomial equation can then be used to convert + value returned by this device into a temperature in Celsius + + Temp(C) = (-9.2627e-12) * x^4 + (6.0373e-08) * x^3 + \ +(-1.7058e-04) * x^2 + (3.2512e-01) * x + (-4.9003e+01) + properties: compatible: enum: @@ -19,7 +32,11 @@ properties: items: - description: VTM cfg1 register space - description: VTM cfg2 register space - - description: VTM efuse register space + - description: | + A software trimming method must be applied to some Jacinto + devices to function properly. This eFuse region provides + the information needed for these SoCs to report + temperatures accurately. power-domains: maxItems: 1 -- 2.35.5 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13207): https://lists.yoctoproject.org/g/linux-yocto/message/13207 Mute This Topic: https://lists.yoctoproject.org/mt/102074931/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 02/10] thermal/drivers/k3_j72xx_bandgap: Remove fuse_base from structure
From: Bryan Brattlof
commit d1bd8644407db9b730391bd39315ad9fb0916faf from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
commit 156f0e2fda420c4a4a7b244a909df04086039bd6 upstream
'fuse_base' is only needed during the initial probe function to provide
data for a software trimming method for some of TI's devices affected by
the i2128 erratum. The devices not affected will not use this region
Remove fuse_base from the main k3_j72xx_bandgap structure
Signed-off-by: Bryan Brattlof
Link: https://lore.kernel.org/r/20221031232702.10339-4...@ti.com
Signed-off-by: Daniel Lezcano
Signed-off-by: Keerthy
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Xulin Sun
---
drivers/thermal/k3_j72xx_bandgap.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/thermal/k3_j72xx_bandgap.c
b/drivers/thermal/k3_j72xx_bandgap.c
index 851bb8fc69ad..ca2747c6c907 100644
--- a/drivers/thermal/k3_j72xx_bandgap.c
+++ b/drivers/thermal/k3_j72xx_bandgap.c
@@ -180,7 +180,6 @@ struct k3_j72xx_bandgap {
struct device *dev;
void __iomem *base;
void __iomem *cfg2_base;
- void __iomem *fuse_base;
struct k3_thermal_data *ts_data[K3_VTM_MAX_NUM_TS];
};
@@ -330,7 +329,7 @@ static int k3_j72xx_bandgap_temp_to_adc_code(int temp)
}
static void get_efuse_values(int id, struct k3_thermal_data *data, int *err,
-struct k3_j72xx_bandgap *bgp)
+void __iomem *fuse_base)
{
int i, tmp, pow;
int ct_offsets[5][K3_VTM_CORRECTION_TEMP_CNT] = {
@@ -352,16 +351,16 @@ static void get_efuse_values(int id, struct
k3_thermal_data *data, int *err,
/* Extract the offset value using bit-mask */
if (ct_offsets[id][i] == -1 && i == 1) {
/* 25C offset Case of Sensor 2 split between 2 regs */
- tmp = (readl(bgp->fuse_base + 0x8) & 0xE000) >>
(29);
- tmp |= ((readl(bgp->fuse_base + 0xC) & 0x1F) << 3);
+ tmp = (readl(fuse_base + 0x8) & 0xE000) >> (29);
+ tmp |= ((readl(fuse_base + 0xC) & 0x1F) << 3);
pow = tmp & 0x80;
} else if (ct_offsets[id][i] == -1 && i == 2) {
/* 125C Case of Sensor 3 split between 2 regs */
- tmp = (readl(bgp->fuse_base + 0x4) & 0xF800) >>
(27);
- tmp |= ((readl(bgp->fuse_base + 0x8) & 0xF) << 5);
+ tmp = (readl(fuse_base + 0x4) & 0xF800) >> (27);
+ tmp |= ((readl(fuse_base + 0x8) & 0xF) << 5);
pow = tmp & 0x100;
} else {
- tmp = readl(bgp->fuse_base + ct_offsets[id][i]);
+ tmp = readl(fuse_base + ct_offsets[id][i]);
tmp &= ct_bm[id][i];
tmp = tmp >> __ffs(ct_bm[id][i]);
@@ -467,6 +466,7 @@ static int k3_j72xx_bandgap_probe(struct platform_device
*pdev)
struct thermal_zone_device *ti_thermal;
int *ref_table;
struct err_values err_vals;
+ void __iomem *fuse_base;
const s64 golden_factors[] = {
-4900199936,
@@ -498,9 +498,9 @@ static int k3_j72xx_bandgap_probe(struct platform_device
*pdev)
return PTR_ERR(bgp->cfg2_base);
res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- bgp->fuse_base = devm_ioremap_resource(dev, res);
- if (IS_ERR(bgp->fuse_base))
- return PTR_ERR(bgp->fuse_base);
+ fuse_base = devm_ioremap_resource(dev, res);
+ if (IS_ERR(fuse_base))
+ return PTR_ERR(fuse_base);
driver_data = of_device_get_match_data(dev);
if (driver_data)
@@ -539,7 +539,7 @@ static int k3_j72xx_bandgap_probe(struct platform_device
*pdev)
}
/* Workaround not needed if bit30/bit31 is set even for J721e */
- if (workaround_needed && (readl(bgp->fuse_base + 0x0) & 0xc000) ==
0xc000)
+ if (workaround_needed && (readl(fuse_base + 0x0) & 0xc000) ==
0xc000)
workaround_needed = false;
dev_dbg(bgp->dev, "Work around %sneeded\n",
@@ -564,7 +564,7 @@ static int k3_j72xx_bandgap_probe(struct platform_device
*pdev)
err_vals.refs[1] = PLUS30CREF;
err_vals.refs[2] = PLUS125CREF;
err_vals.refs[3] = PLUS150CREF;
- get_efuse_values(id, [id], err_vals.errs, bgp);
+ get_efuse_values(id, [id], err_vals.errs,
fuse_base);
}
if (id == 0 && workaround_needed)
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13206):
https://lists.yoctoproject.org/g/linux-yocto/message/13206
Mute This Topic:
[linux-yocto][linux-yocto v6.1][PATCH 0/10]:Pick several patches from the TI SDK 9.0.1.2 to make the Thermal feature work
Hi Bruce, This patch series is to pick several patches from the TI SDK 9.0.1.2 to make the Thermal feature work. Please help me merge these into the following two branches: v6.1/standard/ti-sdk-6.1/ti-j7xxx v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx Documentation/devicetree/bindings/thermal/ti,j72xx-thermal.yaml | 35 ++- arch/arm64/boot/dts/ti/k3-am68-sk-bb-csi2-ov5640.dtso | 4 ++-- arch/arm64/boot/dts/ti/k3-j721s2-common-proc-board.dts | 1 - arch/arm64/boot/dts/ti/k3-j721s2-som-p0.dtsi| 25 - arch/arm64/boot/dts/ti/k3-j784s4-evm.dts| 33 + drivers/mmc/host/sdhci_am654.c | 2 +- drivers/thermal/k3_j72xx_bandgap.c | 58 ++ 7 files changed, 100 insertions(+), 58 deletions(-) -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13204): https://lists.yoctoproject.org/g/linux-yocto/message/13204 Mute This Topic: https://lists.yoctoproject.org/mt/102074928/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto][linux-yocto v6.1][PATCH 01/10] thermal/drivers/k3_j72xx_bandgap: Use bool for i2128 erratum flag
From: Bryan Brattlof
commit 83b6b872cda56104a2050124b95b91500810d782 from
git://git.ti.com/ti-linux-kernel/ti-linux-kernel.git
commit 311f328ffc7572219bee65db77645e5fedd4e8e6 upstream
Some of TI's J721E SoCs require a software trimming method to report
temperatures accurately. Currently we are using a few different data
types to indicate when we should apply the erratum.
Change the 'workaround_needed' variable's data type to a bool to align
with how we are using this variable currently.
Signed-off-by: Bryan Brattlof
Link: https://lore.kernel.org/r/20221031232702.10339-3...@ti.com
Signed-off-by: Daniel Lezcano
Signed-off-by: Keerthy
Signed-off-by: Vignesh Raghavendra
Signed-off-by: Xulin Sun
---
drivers/thermal/k3_j72xx_bandgap.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/thermal/k3_j72xx_bandgap.c
b/drivers/thermal/k3_j72xx_bandgap.c
index f5bd3484cabf..851bb8fc69ad 100644
--- a/drivers/thermal/k3_j72xx_bandgap.c
+++ b/drivers/thermal/k3_j72xx_bandgap.c
@@ -394,7 +394,7 @@ static void print_look_up_table(struct device *dev, int
*ref_table)
}
struct k3_j72xx_bandgap_data {
- unsigned int has_errata_i2128;
+ const bool has_errata_i2128;
};
int k3_thermal_register_cpu_cooling(struct k3_j72xx_bandgap *bgp, int id)
@@ -462,7 +462,7 @@ static int k3_j72xx_bandgap_probe(struct platform_device
*pdev)
struct device *dev = >dev;
struct k3_j72xx_bandgap *bgp;
struct k3_thermal_data *data;
- int workaround_needed = 0;
+ bool workaround_needed = false;
const struct k3_j72xx_bandgap_data *driver_data;
struct thermal_zone_device *ti_thermal;
int *ref_table;
@@ -640,11 +640,11 @@ static int k3_j72xx_bandgap_remove(struct platform_device
*pdev)
}
static const struct k3_j72xx_bandgap_data k3_j72xx_bandgap_j721e_data = {
- .has_errata_i2128 = 1,
+ .has_errata_i2128 = true,
};
static const struct k3_j72xx_bandgap_data k3_j72xx_bandgap_j7200_data = {
- .has_errata_i2128 = 0,
+ .has_errata_i2128 = false,
};
static const struct of_device_id of_k3_j72xx_bandgap_match[] = {
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13205):
https://lists.yoctoproject.org/g/linux-yocto/message/13205
Mute This Topic: https://lists.yoctoproject.org/mt/102074929/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [meta-anaconda][PATCH] anaconda_oe.py: correct image name
On 10/18/23 10:06, Changqing Li wrote:
From: Changqing Li
Since oe-core commit 26d97acc713 [image-artifact-names: include
${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and
${IMAGE_LINK_NAME}], image name has changed to
core-image-minimal-qemux86.rootfs.ext4, change accordingly to fix error:
INSTALLER_TARGET_BUILD does not exist
Merged. Thanks.
Kai
Signed-off-by: Changqing Li
---
README | 2 +-
lib/oeqa/selftest/cases/anaconda_oe.py | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 07b63fe..76e9665 100644
--- a/README
+++ b/README
@@ -162,7 +162,7 @@ Building the target installer
Edit conf/local.conf to use:
$ echo 'PACKAGE_CLASSES = "package_rpm"' >> conf/local.conf
$ echo 'DISTRO = "anaconda"' >> conf/local.conf
- $ echo 'INSTALLER_TARGET_BUILD =
"/tmp-glibc/deploy/images/qemux86/core-image-minimal-qemux86.ext4"'
>> conf/local.conf
+ $ echo 'INSTALLER_TARGET_BUILD =
"/tmp-glibc/deploy/images/qemux86/core-image-minimal-qemux86.rootfs.ext4"'
>> conf/local.conf
Edit conf/bblayers.conf to include other layers
BBLAYERS ?= " \
diff --git a/lib/oeqa/selftest/cases/anaconda_oe.py
b/lib/oeqa/selftest/cases/anaconda_oe.py
index bf55308..20b8d5b 100644
--- a/lib/oeqa/selftest/cases/anaconda_oe.py
+++ b/lib/oeqa/selftest/cases/anaconda_oe.py
@@ -146,7 +146,7 @@ class TestAnacondaOE(OESelftestTestCase):
ks_file = os.path.join(self.layer_path, 'example/ks-imagecopy.cfg')
features = 'TMPDIR .= "_host"\n'
features += 'DISTRO = "%s"\n' % self.anaconda_distro
-features += 'INSTALLER_TARGET_BUILD = "%s/%s-%s.ext4"\n' %
(self.target_deploy_dir_image, self.target_recipe, self.machine)
+features += 'INSTALLER_TARGET_BUILD = "%s/%s-%s.rootfs.ext4"\n' %
(self.target_deploy_dir_image, self.target_recipe, self.machine)
features += 'KICKSTART_FILE = "%s"\n' % ks_file
features += 'SYSLINUX_TIMEOUT = "10"\n'
features += 'APPEND:append = " textinst"\n'
@@ -164,7 +164,7 @@ class TestAnacondaOE(OESelftestTestCase):
def test_testanaconda_imagecopy_install(self):
features = 'TMPDIR .= "_host"\n'
features += 'DISTRO = "%s"\n' % self.anaconda_distro
-features += 'INSTALLER_TARGET_BUILD = "%s/%s-%s.ext4"\n' %
(self.target_deploy_dir_image, self.target_recipe, self.machine)
+features += 'INSTALLER_TARGET_BUILD = "%s/%s-%s.rootfs.ext4"\n' %
(self.target_deploy_dir_image, self.target_recipe, self.machine)
self.logger.info('extra local.conf:\n%s' % features)
self.append_config(features)
--
Kai Kang
Wind River Linux
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61425): https://lists.yoctoproject.org/g/yocto/message/61425
Mute This Topic: https://lists.yoctoproject.org/mt/102032096/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [PATCH] driver: llce-core: correct the value of CORES_TS_OFFSET
The default value of CORES_TS_OFFSET will cause the following known issue:
# cat /sys/kernel/debug/llce_core/core1_ts
Unable to handle kernel paging request at virtual address ffc00ced0870
Mem abort info:
ESR = 0x9607
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
FSC = 0x07: level 3 translation fault
Data abort info:
ISV = 0, ISS = 0x0007
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp=8b84f000
[ffc00ced0870] pgd=1008d003, p4d=1008d003,
pud=1008d003, pmd=100889aeb003, pte=
Internal error: Oops: 9607 1 PREEMPT SMP
Modules linked in: 8021q llce_mailbox llce_core llce_can pfeng(O) sch_fq_codel
openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4
[last unloaded: llce_core]
CPU: 1 PID: 781 Comm: cat Tainted: G O 5.15.135-yocto-standard #1
Hardware name: NXP S32G399A-RDB3 (DT)
pstate: 6005 (nZCv daif PAN -UAO -TCO -DIT -SSBS BTYPE=-)
pc : debugfs_readl_get+0xc/0x30 [llce_core]
lr : simple_attr_read+0x7c/0x130
sp : ffc00d23bcd0
x29: ffc00d23bce0 x28: ff88142e0040 x27:
x26: x25: x24: 007fb45bf000
x23: 0002 x22: ff8820da7150 x21:
x20: ffc00d23bda0 x19: ff8820da7100 x18:
x17: x16: x15:
x14: x13: x12:
x11: 0001 x10: 0101010101010101 x9 : ffc00836968c
x8 : ffc009fb6c18 x7 : x6 : 0001
x5 : ffc009d31000 x4 : ffc009d31808 x3 :
x2 : ffc00117 x1 : ffc00d23bcd0 x0 : ffc00ced0870
Call trace:
debugfs_readl_get+0xc/0x30 [llce_core]
debugfs_attr_read+0x54/0x9c
vfs_read+0xb4/0x1ec
ksys_read+0x74/0x104
__arm64_sys_read+0x24/0x30
invoke_syscall+0x5c/0x130
el0_svc_common.constprop.0+0x68/0x124
do_el0_svc+0x4c/0xb0
el0_svc+0x54/0x110
el0t_64_sync_handler+0xa4/0x130
el0t_64_sync+0x1a0/0x1a4
Code: bad PC value
--[ end trace feb346f6b33a6527 ]--
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x8,2001,2842
Memory Limit: none
--[ end Kernel panic - not syncing: Oops: Fatal exception ]--
This patch changing the CORES_TS_OFFSET to 0x13730, which is from the
"Release Note" of BSP38 and given as a workaround, will fix the above issue.
The value of CORES_TS_OFFSET may be changed in future BSP versions, and we
will update it accordingly.
Signed-off-by: Zhantao Tang
---
drivers/mfd/llce-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mfd/llce-core.c b/drivers/mfd/llce-core.c
index 212bf99283dc1..e7a798324f9f8 100644
--- a/drivers/mfd/llce-core.c
+++ b/drivers/mfd/llce-core.c
@@ -36,7 +36,7 @@
#define LLCE_MGR_TX_BOOT_END (0x0F00U)
#define LLCE_MGR_FRPE_BOOT_END (0xF000U)
#define LLCE_MGR_BOOT_END_ALL_CORES_MASK (0xU)
-#define CORES_TS_OFFSET(0x13FD0)
+#define CORES_TS_OFFSET(0x13730)
struct sram_node {
const char *name;
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#13203):
https://lists.yoctoproject.org/g/linux-yocto/message/13203
Mute This Topic: https://lists.yoctoproject.org/mt/102074006/21656
Group Owner: linux-yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] [linux-yocto std/preempt-rt kernel v5.15]: driver: llce-core: correct the value of CORES_TS_OFFSET
Hi Bruce, There is one patch to correct the value of CORES_TS_OFFSET. Would you please help to merge it into v5.15/standard/nxp-sdk-5.15/nxp-s32g v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g branches? Thanks, Zhantao -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13202): https://lists.yoctoproject.org/g/linux-yocto/message/13202 Mute This Topic: https://lists.yoctoproject.org/mt/102074003/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[linux-yocto] Trial merge of v5.15.136 v6.1.58 v6.1.59 for linux-yocto
Hi Bruce, This is a trial merge of the stable kernel v5.15.136 v6.1.58 v6.1.59 for the following branches in the linux-yocto. 876d7300fe9e v5.15/standard/sdkv5.10/axxia 13fe5a251783 v5.15/standard/preempt-rt/sdkv5.10/axxia 2a9cd206a46f v5.15/standard/base b3bbc5cb8dad v5.15/standard/preempt-rt/base e17899c835c8 v5.15/standard/cn-sdkv5.4/octeon #Have textual conflicts 2ce7be4d0b9c v5.15/standard/preempt-rt/cn-sdkv5.4/octeon #Have textual conflicts e73e17908f83 v5.15/standard/cn-sdkv5.15/octeon #Have textual conflicts fa752f26d7d6 v5.15/standard/preempt-rt/cn-sdkv5.15/octeon #Have textual conflicts 6f79e767f22d v5.15/standard/ti-sdk-5.10/ti-j72xx 6c5107f3818e v5.15/standard/preempt-rt/ti-sdk-5.10/ti-j72xx b71b0fb34b19 v5.15/standard/nxp-sdk-5.15/nxp-soc 3a7974fdc956 v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-soc 979ab01bc996 v5.15/standard/bcm-2xxx-rpi 4990d6e5509a v5.15/standard/preempt-rt/bcm-2xxx-rpi 113c99116e75 v5.15/standard/nxp-sdk-5.15/nxp-s32g 61244d30e75f v5.15/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g 2deeb8bec8f0 v5.15/standard/intel-sdk-5.15/intel-socfpga 5e719e5ec752 v5.15/standard/preempt-rt/intel-sdk-5.15/intel-socfpga 0ee9eb4752a0 v5.15/standard/x86 5208de4eab14 v5.15/standard/preempt-rt/x86 b42548ad0e07 v5.15/standard/sdkv5.15/xlnx-soc #Have textual conflicts 034467f43763 v5.15/standard/preempt-rt/sdkv5.15/xlnx-soc #Have textual conflicts f30a924e947b v6.1/standard/base cb3dd85b0dbc v6.1/standard/preempt-rt/base 28da30a3567f v6.1/standard/ti-sdk-6.1/ti-j7xxx e2110b7664ba v6.1/standard/preempt-rt/ti-sdk-6.1/ti-j7xxx ca498326386a v6.1/standard/nxp-sdk-6.1/nxp-soc #Have textual conflicts 0d5061a1e57a v6.1/standard/preempt-rt/nxp-sdk-6.1/nxp-soc #Have textual conflicts 7a25611c657a v6.1/standard/cn-sdkv5.15/octeon e9b2d66510b1 v6.1/standard/preempt-rt/cn-sdkv5.15/octeon 5fa6f43a894e v6.1/standard/bcm-2xxx-rpi #Have textual conflicts 93b2f3943a0c v6.1/standard/preempt-rt/bcm-2xxx-rpi #Have textual conflicts 400c39f8498a v6.1/standard/nxp-sdk-5.15/nxp-s32g 95032458e170 v6.1/standard/preempt-rt/nxp-sdk-5.15/nxp-s32g c66df128dae9 v6.1/standard/intel-sdk-6.1/intel-socfpga c12fc49c6f0d v6.1/standard/preempt-rt/intel-sdk-6.1/intel-socfpga f534ba8e22e6 v6.1/standard/x86 9a3b4442f53d v6.1/standard/preempt-rt/x86 c0ee5f2b8db7 v6.1/standard/sdkv6.1/xlnx-soc #Have textual conflicts 65a5155b96d7 v6.1/standard/preempt-rt/sdkv6.1/xlnx-soc #Have textual conflicts There are quite a few minor merge conflicts in the nxp and xilinx branches, but they are all easy to resolve. All the branches have passed my build test. I have pushed all these branches to: https://github.com/haokexin/linux You can use this as a reference for the linux-yocto stable kernel bump. Thanks, Kevin -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13201): https://lists.yoctoproject.org/g/linux-yocto/message/13201 Mute This Topic: https://lists.yoctoproject.org/mt/102073399/21656 Group Owner: linux-yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/linux-yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [layerindex-web][PATCH] bootstrap: fix typo in minified file name
Fixes dropdown menus so they are functional again.
Signed-off-by: Tim Orling
---
.../static/js/{boostrap-3.4.1.min.js => bootstrap-3.4.1.min.js} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename layerindex/static/js/{boostrap-3.4.1.min.js => bootstrap-3.4.1.min.js}
(100%)
diff --git a/layerindex/static/js/boostrap-3.4.1.min.js
b/layerindex/static/js/bootstrap-3.4.1.min.js
similarity index 100%
rename from layerindex/static/js/boostrap-3.4.1.min.js
rename to layerindex/static/js/bootstrap-3.4.1.min.js
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61423): https://lists.yoctoproject.org/g/yocto/message/61423
Mute This Topic: https://lists.yoctoproject.org/mt/102069305/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.3.rc1)
On Thu, 2023-10-19 at 14:06 +, Jing Hui Tham wrote: > Hi all, > > Intel and WR YP QA is planning for QA execution for YP build yocto-4.3.rc1. > We are planning to execute following tests for this cycle: > > OEQA-manual tests for following module: > 1. OE-Core > 2. BSP-hw > > Runtime auto test for following platforms: > 1. MinnowBoard Turbot - 32bit > 2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors) > 3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors) > 4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors) > 5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors) > 6. Beaglebone > > > ETA for completion next Tuesday, October 24. We've realised there is a nasty bug in rc1 related to patchtest deleting local changes. Given the build failure in the rc1 build and other security issues we're thinking we should make an rc2 build and abandon rc1. Sorry for the churn. The new build should be ready soon with any luck. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61422): https://lists.yoctoproject.org/g/yocto/message/61422 Mute This Topic: https://lists.yoctoproject.org/mt/102060627/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] Run generated executable in cmake recipe #cmake #kirkstone #make #native #yocto
Hi Darek Making the recipe compiling for cross and native and adding a DEPENDS from cross to native seems to be the cleanest and most Yocto-ish way to me. Alternatively this patch would allow to run cross compiled executables with Qemu in the cmake project https://git.yoctoproject.org/poky-contrib/commit/?h=adrianf/devtool-ide=6c63df973d9530ecabc9480f8ba2aba3ff93952f. But that's not the most common approach. It's also possible to hack a cmake script which allows to pass a native tool-chain file for B. But this approach needs some hacks because cmake is designed to work with one tool-chain file only. I did that for a special use case, but I'm not aware of a public example. Regards, Adrian Darek Konopka schrieb am Do., 19. Okt. 2023, 17:21: > Hello all, > > So I have a cmake project that uses an executable generated from a cmake > subproject. > My architecture is as such > ├── ProjectA > ├── projecta_1.0.bb > ├── files >├── ProjectA > ├── CMakeLists.txt > ├── ProjectB > ├── CMakeLists.txt > My recipe is a standard recipe that inherits pkgconfig cmake > The issue that occurs is that when manually building ProjectA natively it > builds as expected, but when building it with yocto, during the do_compile > for ProjectA, it says it is missing the executable generated by ProjectB > located in /usr/bin/ProjBEXE (this executable is needed in order to compile > ProjectA). > > What did work is creating a projectb-native recipe that runs cmake-native, > and then have projecta depend on it, but I was wondering, is there a way to > have projecta_1.0.bb build the executable and use it within its own > cmake? Perhaps making projectB a package to have projectA use it? > NOTE: I am using yocto kirkstone > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61421): https://lists.yoctoproject.org/g/yocto/message/61421 Mute This Topic: https://lists.yoctoproject.org/mt/102062177/21656 Mute #native:https://lists.yoctoproject.org/g/yocto/mutehashtag/native Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Mute #cmake:https://lists.yoctoproject.org/g/yocto/mutehashtag/cmake Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone Mute #make:https://lists.yoctoproject.org/g/yocto/mutehashtag/make Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-security] SRTool usage for CVE management at YP
On Wed, 2023-10-18 at 07:43 +0200, Marta Rybczynska wrote: > Hello all, > There' a discussion pending on the usage of SRTool and CVE management > for the Yocto project in general. It is related to the need of having > a list of CVEs the project is affected by, those fixed and those that > we know we are not affected. > > In the previous episode, we have had a demo of SRTool by David Reyna. > This weekend he has updated the code base. The next call is tomorrow > (Thursday, 19th October, half an hour after the end of the Bug Triage > meeting) to discuss conclusions of first tests and the next steps. If > you are interested to join, let us know! I'd be happy to listen in. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61420): https://lists.yoctoproject.org/g/yocto/message/61420 Mute This Topic: https://lists.yoctoproject.org/mt/102062524/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] Run generated executable in cmake recipe #cmake #kirkstone #make #native #yocto
Hello all, So I have a cmake project that uses an executable generated from a cmake subproject. My architecture is as such ├── ProjectA ├── projecta_1.0.bb ( http://projecta_1.0.bb/ ) ├── files ├── ProjectA ├── CMakeLists.txt ├── ProjectB ├── CMakeLists.txt My recipe is a standard recipe that inherits pkgconfig cmake The issue that occurs is that when manually building ProjectA natively it builds as expected, but when building it with yocto, during the do_compile for ProjectA, it says it is missing the executable generated by ProjectB located in /usr/bin/ProjBEXE (this executable is needed in order to compile ProjectA). What did work is creating a projectb-native recipe that runs cmake-native, and then have projecta depend on it, but I was wondering, is there a way to have projecta_1.0.bb ( http://projecta_1.0.bb/ ) build the executable and use it within its own cmake? Perhaps making projectB a package to have projectA use it? NOTE: I am using yocto kirkstone -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61419): https://lists.yoctoproject.org/g/yocto/message/61419 Mute This Topic: https://lists.yoctoproject.org/mt/102062177/21656 Mute #native:https://lists.yoctoproject.org/g/yocto/mutehashtag/native Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto Mute #cmake:https://lists.yoctoproject.org/g/yocto/mutehashtag/cmake Mute #kirkstone:https://lists.yoctoproject.org/g/yocto/mutehashtag/kirkstone Mute #make:https://lists.yoctoproject.org/g/yocto/mutehashtag/make Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH yocto-autobuilder-helper] config.json: use '-S lockedsigs' to generate the locked signatures file
This is now done with a dedicated switch, where previously the file was always
written
out, creating often unneeded clutter.
Signed-off-by: Alexander Kanavin
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.json b/config.json
index 94c86e1..ea6885d 100644
--- a/config.json
+++ b/config.json
@@ -1298,7 +1298,7 @@
},
"step5" : {
"shortname" : "Prep #2 locked-sigs test",
-"BBTARGETS" : "core-image-sato -S none",
+"BBTARGETS" : "core-image-sato -S lockedsigs",
"EXTRACMDS" : ["${SCRIPTSDIR}/../janitor/clobberdir
${BUILDDIR}/../build/tmp"]
},
"step6" : {
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61418): https://lists.yoctoproject.org/g/yocto/message/61418
Mute This Topic: https://lists.yoctoproject.org/mt/102061292/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.3.rc1)
Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-4.3.rc1. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowBoard Turbot - 32bit 2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors) 3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors) 4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors) 5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors) 6. Beaglebone ETA for completion next Tuesday, October 24. Best regards, Jing Hui > -Original Message- > From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User > Sent: Wednesday, October 18, 2023 2:16 PM > To: yocto@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [qa-build-notification] QA notification for completed autobuilder > build (yocto-4.3.rc1) > > > A build flagged for QA (yocto-4.3.rc1) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-4.3.rc1 > > > Build URL: > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6062 > > Build hash information: > > bitbake: 5419a8473d6d4cd1d01537de68ad8d72cf5be0b2 > meta-agl: 4063b4f9a712e32337c1d9678b2f2481dde2a346 > meta-arm: 3ed13d25a065f29bd46ee725c708d12ebc3f175a > meta-aws: a30a2b66f1447dc5abdbca6c5de743e39c08b99b > meta-intel: 1bca60610c597571769edc4a057a04bfdbd2f994 > meta-mingw: 65ef95a74f6ae815f63f636ed53e140a26a014ce > meta-openembedded: 35bcd8c6ddfb6bc8729d0006dab887afcc772ec9 > meta-virtualization: 827092c2ec925ea3a024dcda9ccfd738e351e6ba > oecore: 4f84537670020a8d902248479efa9f062089c0d3 > poky: f65f100bc5379c3153ee00b2aa62ea5c9a66ec79 > > > > This is an automated message from the Yocto Project Autobuilder > Git: git://git.yoctoproject.org/yocto-autobuilder2 > Email: richard.pur...@linuxfoundation.org > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61417): https://lists.yoctoproject.org/g/yocto/message/61417 Mute This Topic: https://lists.yoctoproject.org/mt/102060627/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder-helper][PATCH v2] meta-oe-mirror: Use a 2 step job to fetch and verify meta-openembedded mirror.
On Thu, 2023-10-19 at 12:52 +0100, Richard Purdie via lists.yoctoproject.org wrote: > On Thu, 2023-10-19 at 11:58 +0100, Richard Purdie via > lists.yoctoproject.org wrote: > > On Wed, 2023-10-18 at 15:46 +0200, David Pierret wrote: > > > Inspired from trigger-build and trigger-build-post-trigger > > > The branch must be selected on build configuration. > > > > > > Signed-off-by: David Pierret > > > Reviewed-by: Yoann Congal > > > --- > > > config.json | 30 ++ > > > 1 file changed, 30 insertions(+) > > > > I fixed a json parsing issue and merged. I also added the autobuilder2 > > config to support it. A test build is now running here: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/1 > > That failed with a single fetch failure which isn't related to this > patch. > > I've therefore pulled the patch into the dunfell, kirkstone and > mickledore branches. > > Autobuilder enabling is here: > > https://git.yoctoproject.org/yocto-autobuilder2/commit/?id=93c034d436cbe631db2354a945850c3e97dd46bd > > with scheduling for the all branches here: > > https://git.yoctoproject.org/yocto-autobuilder2/commit/?id=94f2878f64f11993e8de8295bb1b46202b741019 Master reran and succeeded this time but is showing a lot of warnings: https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/2/steps/12/logs/warnings Kirkstone has an issue with grubby-git and a missing SRCREV: https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/3/steps/13/logs/stdio (plus warnings) Mickledore has an issue with uutils-coreutils: https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/5 (plus warnings) Dunfell broke with space issues so I reran it here: https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/6 So we're making progress but the meta-oe layer maintainers may need some tweaks on the same branches or we need to see some missing files into the mirror for those branches. We also need to find a way to address the warnings. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61416): https://lists.yoctoproject.org/g/yocto/message/61416 Mute This Topic: https://lists.yoctoproject.org/mt/102039136/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-4.3.rc1)
On Thu, 2023-10-19 at 14:28 +0200, Alexis Lothoré wrote: > Hi Ross, > On 10/19/23 13:04, Ross Burton wrote: > > > On 19 Oct 2023, at 09:36, Alexis Lothoré via lists.yoctoproject.org > > > wrote: > > I just skimmed your report and have some feedback to hopefully make it > > easier to read in the future. > > > > I’d suggest sorting the output in order of importance. For example, this > > is a section that I really don’t care about: > > > > Match: sdk_core-image-sato_x86_64_fvp-base_20230910083055 > > sdk_core-image-sato_x86_64_fvp-base_20231017222150 > > > > Put those at the bottom, or even better collate them into a single section > > where there have been no changes. > > > > Similarly: > > > > Match: runtime_core-image-sato_qemux86_20230911011430 > > runtime_core-image-sato_qemux86_20231017223736 > > Additionally, 1 new test(s) is/are present > > > > I guess marginally more important than identical results, but “there are > > new tests that passed” isn’t very interesting. > > Indeed, not so useful and hiding the real content at the bottom > > > Regression: oeselftest_ubuntu-22.04_qemux86-64_20230911011940 > > oeselftest_almalinux-9.2_qemux86-64_20231017221342 > > > > Should they have matched? The host distro doesn’t match and this matters > > for some of the tests, as some distros don’t support some of the selftests. > > In this case specifically, there are seven regressions and six of them are > > specific to the host changing, which has the side-effect of hiding the one > > actual regression. > > Yeah, that's a point I have been struggling with when starting to update those > tools. The initial assumption I have started working with, after discussing > the > matter with Richard (see [1]), is the following: > 1. MACHINE _must_ match between base and target > 2. Different HOSTS _can_ be cross-checked > > But the issue you are pointing tends to show it does not work well in some > cases. I will have to do some tests to see if dropping 2. reduce this noise > without loosing valuable data, or if we need to find something smarter What the autobuilder does is either runs one selftest on a random host for q-quick, or for a-full it will run five selftests, one for "centos", one for "arm", one for "ubuntu", one for "fedora" and one for "debian". Ideally we'd therefore compare debian to debian if we have any choice. It is a question of finding the closest matches. That is hard in code though whilst keeping it generic. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61415): https://lists.yoctoproject.org/g/yocto/message/61415 Mute This Topic: https://lists.yoctoproject.org/mt/102034502/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-4.3.rc1)
Hi Ross,
On 10/19/23 13:04, Ross Burton wrote:
>> On 19 Oct 2023, at 09:36, Alexis Lothoré via lists.yoctoproject.org
>> wrote:
> I just skimmed your report and have some feedback to hopefully make it easier
> to read in the future.
>
> I’d suggest sorting the output in order of importance. For example, this is
> a section that I really don’t care about:
>
> Match: sdk_core-image-sato_x86_64_fvp-base_20230910083055
> sdk_core-image-sato_x86_64_fvp-base_20231017222150
>
> Put those at the bottom, or even better collate them into a single section
> where there have been no changes.
>
> Similarly:
>
> Match: runtime_core-image-sato_qemux86_20230911011430
> runtime_core-image-sato_qemux86_20231017223736
> Additionally, 1 new test(s) is/are present
>
> I guess marginally more important than identical results, but “there are new
> tests that passed” isn’t very interesting.
Indeed, not so useful and hiding the real content at the bottom
> Regression: oeselftest_ubuntu-22.04_qemux86-64_20230911011940
> oeselftest_almalinux-9.2_qemux86-64_20231017221342
>
> Should they have matched? The host distro doesn’t match and this matters for
> some of the tests, as some distros don’t support some of the selftests. In
> this case specifically, there are seven regressions and six of them are
> specific to the host changing, which has the side-effect of hiding the one
> actual regression.
Yeah, that's a point I have been struggling with when starting to update those
tools. The initial assumption I have started working with, after discussing the
matter with Richard (see [1]), is the following:
1. MACHINE _must_ match between base and target
2. Different HOSTS _can_ be cross-checked
But the issue you are pointing tends to show it does not work well in some
cases. I will have to do some tests to see if dropping 2. reduce this noise
without loosing valuable data, or if we need to find something smarter
>
> The report then lists the first however many regressions before announcing
> the summary:
>
> (In total, 7134 regressions/status changes detected)
> Additionally, 7 previously failing test(s) is/are now passing
> Additionally, 4622 new test(s) is/are present
>
> The headline figure of 7134 regressions should be first, as that’s the most
> important data point in a skim of the report. List the summary first, and
> then the breakdown.
ACK
> Grouping the results would be interesting, because the list got truncated I
> can’t see easily if all 7134 regressions were in ptestresult.gcc-g++-user.*
> or if that was just the first 100 and the rest were other components.
> Breaking the ptest results up by the second level component would be
> interesting, if it said something like this then we’d be able to get a feel
> for what components have broken from the report.
>
> 7134 regressions detected.
>
> ptestresult.gcc-libstdc++-v3-user.30_threads/thread/native_handle/cancel.cc
> execution test: PASS -> FAIL
> [ say 10 results per component ]
> And 6123 more in ptestresult.gcc-libstdc++v3
> ptestresult.gcc-libgomp.libgomp.c++/ctor-10.C: UNSUPPORTED -> UNRESOLVED
Makes sense. I have posted this morning the series introducing the display limit
([2]), I can work on a v2 implementing the ptest specific display limit
> This one also caught my eye:
> Regression: runtime_core-image-sato_qemuppc_20230910082140
> runtime_core-image-sato_qemuppc_20231017222112
> systemd.SystemdJournalTests.test_systemd_boot_time: PASSED -> SKIPPED
> Additionally, 1 new test(s) is/are present
>
> Is that comparing a systemd test run with a sysvinit test run?
I think the comparison is relevant, both are bout systemd system (many systemd
tests are present and OK in runtime_core-image-sato_qemuppc_20231017222112
results). However I do not get why it is marked as skipped and not failed:
"systemd.SystemdJournalTests.test_systemd_boot_time": {
"duration": 2.3783957958221436,
"log": "Error when parsing time from boot string",
"status": "SKIPPED"
}
Maybe an issue in the corresponding runner ?
> Thanks for the work on the tool so far, this is a lot easier to read than the
> full reports!
>
> Ross
Thank you for having taken time to give some feedback !
[1] https://lists.yoctoproject.org/g/automated-testing/message/1216
[2]
https://lore.kernel.org/openembedded-core/20231019095352.25923-1-alexis.loth...@bootlin.com/
--
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61414): https://lists.yoctoproject.org/g/yocto/message/61414
Mute This Topic: https://lists.yoctoproject.org/mt/102034502/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
Re: [yocto] QA notification for completed autobuilder build (yocto-4.3.rc1)
On Thu, 2023-10-19 at 10:36 +0200, Alexis Lothoré wrote: > Hello, > > On 10/18/23 08:16, Pokybuild User wrote: > > > > A build flagged for QA (yocto-4.3.rc1) was completed on the autobuilder > > and is available at: > > > > > > https://autobuilder.yocto.io/pub/releases/yocto-4.3.rc1 > > The regression report looks worryingly empty. It has been generated with > yocto-4.2 as comparison base. When taking a look at yocto-testresults content > for it, I only find a few test results (11, while it should be something > around > 300). I am not sure yet if we did some mistakes while re-uploading manually > missing tests results during the 4.2 cycle, or if tests results are indeed > suffering some issues for release builds (this is repeatable on different > 4.2.x > releases). I'd noticed that too, not sure what happened but it wasn't what I'd expected. It would be good to understand what went wrong. > So in the mean time, here is a manual regression report between 4.3_M3 and > yocto-4.3.rc1: > > https://pastebin.com/6QbfGstR > > The report has a "rate limit" applied for noisy regression (patch incoming) I was thinking about ideas like printing the regressions first, then the matches. I think Ross has some good feedback about how we can improve things. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61413): https://lists.yoctoproject.org/g/yocto/message/61413 Mute This Topic: https://lists.yoctoproject.org/mt/102034502/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder-helper][PATCH v2] meta-oe-mirror: Use a 2 step job to fetch and verify meta-openembedded mirror.
On Thu, 2023-10-19 at 11:58 +0100, Richard Purdie via lists.yoctoproject.org wrote: > On Wed, 2023-10-18 at 15:46 +0200, David Pierret wrote: > > Inspired from trigger-build and trigger-build-post-trigger > > The branch must be selected on build configuration. > > > > Signed-off-by: David Pierret > > Reviewed-by: Yoann Congal > > --- > > config.json | 30 ++ > > 1 file changed, 30 insertions(+) > > I fixed a json parsing issue and merged. I also added the autobuilder2 > config to support it. A test build is now running here: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/1 That failed with a single fetch failure which isn't related to this patch. I've therefore pulled the patch into the dunfell, kirkstone and mickledore branches. Autobuilder enabling is here: https://git.yoctoproject.org/yocto-autobuilder2/commit/?id=93c034d436cbe631db2354a945850c3e97dd46bd with scheduling for the all branches here: https://git.yoctoproject.org/yocto-autobuilder2/commit/?id=94f2878f64f11993e8de8295bb1b46202b741019 Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61412): https://lists.yoctoproject.org/g/yocto/message/61412 Mute This Topic: https://lists.yoctoproject.org/mt/102039136/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-4.3.rc1)
Hi Alexis, > On 19 Oct 2023, at 09:36, Alexis Lothoré via lists.yoctoproject.org > wrote: > The regression report looks worryingly empty. It has been generated with > yocto-4.2 as comparison base. When taking a look at yocto-testresults content > for it, I only find a few test results (11, while it should be something > around > 300). I am not sure yet if we did some mistakes while re-uploading manually > missing tests results during the 4.2 cycle, or if tests results are indeed > suffering some issues for release builds (this is repeatable on different > 4.2.x > releases). > > So in the mean time, here is a manual regression report between 4.3_M3 and > yocto-4.3.rc1: > > https://pastebin.com/6QbfGstR > > The report has a "rate limit" applied for noisy regression (patch incoming) Thanks for that, much appreciated. I just skimmed your report and have some feedback to hopefully make it easier to read in the future. I’d suggest sorting the output in order of importance. For example, this is a section that I really don’t care about: Match: sdk_core-image-sato_x86_64_fvp-base_20230910083055 sdk_core-image-sato_x86_64_fvp-base_20231017222150 Put those at the bottom, or even better collate them into a single section where there have been no changes. Similarly: Match: runtime_core-image-sato_qemux86_20230911011430 runtime_core-image-sato_qemux86_20231017223736 Additionally, 1 new test(s) is/are present I guess marginally more important than identical results, but “there are new tests that passed” isn’t very interesting. Now on to the regressions. Regression: oeselftest_ubuntu-22.04_qemux86-64_20230911011940 oeselftest_almalinux-9.2_qemux86-64_20231017221342 Should they have matched? The host distro doesn’t match and this matters for some of the tests, as some distros don’t support some of the selftests. In this case specifically, there are seven regressions and six of them are specific to the host changing, which has the side-effect of hiding the one actual regression. The report then lists the first however many regressions before announcing the summary: (In total, 7134 regressions/status changes detected) Additionally, 7 previously failing test(s) is/are now passing Additionally, 4622 new test(s) is/are present The headline figure of 7134 regressions should be first, as that’s the most important data point in a skim of the report. List the summary first, and then the breakdown. Grouping the results would be interesting, because the list got truncated I can’t see easily if all 7134 regressions were in ptestresult.gcc-g++-user.* or if that was just the first 100 and the rest were other components. Breaking the ptest results up by the second level component would be interesting, if it said something like this then we’d be able to get a feel for what components have broken from the report. 7134 regressions detected. ptestresult.gcc-libstdc++-v3-user.30_threads/thread/native_handle/cancel.cc execution test: PASS -> FAIL [ say 10 results per component ] And 6123 more in ptestresult.gcc-libstdc++v3 ptestresult.gcc-libgomp.libgomp.c++/ctor-10.C: UNSUPPORTED -> UNRESOLVED This one also caught my eye: Regression: runtime_core-image-sato_qemuppc_20230910082140 runtime_core-image-sato_qemuppc_20231017222112 systemd.SystemdJournalTests.test_systemd_boot_time: PASSED -> SKIPPED Additionally, 1 new test(s) is/are present Is that comparing a systemd test run with a sysvinit test run? Thanks for the work on the tool so far, this is a lot easier to read than the full reports! Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61411): https://lists.yoctoproject.org/g/yocto/message/61411 Mute This Topic: https://lists.yoctoproject.org/mt/102034502/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder-helper][PATCH v2] meta-oe-mirror: Use a 2 step job to fetch and verify meta-openembedded mirror.
On Wed, 2023-10-18 at 15:46 +0200, David Pierret wrote: > Inspired from trigger-build and trigger-build-post-trigger > The branch must be selected on build configuration. > > Signed-off-by: David Pierret > Reviewed-by: Yoann Congal > --- > config.json | 30 ++ > 1 file changed, 30 insertions(+) I fixed a json parsing issue and merged. I also added the autobuilder2 config to support it. A test build is now running here: https://autobuilder.yoctoproject.org/typhoon/#/builders/156/builds/1 Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61410): https://lists.yoctoproject.org/g/yocto/message/61410 Mute This Topic: https://lists.yoctoproject.org/mt/102039136/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/leave/6691583/21656/737036229/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[yocto] [PATCH yocto-autobuilder-helper] config.json: use yocto-mirrors tag to exclude/include yocto source mirror test
This way explicitly listing the test can be avoided, especially when more tests
of the same kind will be added (such as te CDN sstate cache mirror test).
Signed-off-by: Alexander Kanavin
---
config.json | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/config.json b/config.json
index 28a3a6d..94c86e1 100644
--- a/config.json
+++ b/config.json
@@ -230,7 +230,7 @@
"extravars" : [
"RPM_GPG_SIGN_CHUNK = '1'"
],
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest
-a --skip-tests distrodata.Distrodata.test_checkpkg
buildoptions.SourceMirroring.test_yocto_source_mirror -T machine -T
toolchain-user -T toolchain-system -j 15"],
+"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest
-a --skip-tests distrodata.Distrodata.test_checkpkg -T yocto-mirrors -T machine
-T toolchain-user -T toolchain-system -j 15"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
}
},
@@ -266,7 +266,7 @@
},
"step2" : {
"shortname" : "OE Selftest",
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1
oe-selftest -a --skip-tests distrodata.Distrodata.test_checkpkg
buildoptions.SourceMirroring.test_yocto_source_mirror reproducible -T machine
-T toolchain-user -T toolchain-system -j 15"],
+"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1
oe-selftest -a --skip-tests distrodata.Distrodata.test_checkpkg reproducible -T
yocto-mirrors -T machine -T toolchain-user -T toolchain-system -j 15"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
},
"step3" : {
@@ -466,7 +466,7 @@
"MACHINE" : "qemux86-64",
"step1" : {
"shortname" : "Source Mirror Selftest",
-"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest
-r buildoptions.SourceMirroring.test_yocto_source_mirror"],
+"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; DISPLAY=:1 oe-selftest
-a -t yocto-mirrors -j 15"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]
}
}
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#61409): https://lists.yoctoproject.org/g/yocto/message/61409
Mute This Topic: https://lists.yoctoproject.org/mt/102056973/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] QA notification for completed autobuilder build (yocto-4.3.rc1)
Hello, On 10/18/23 08:16, Pokybuild User wrote: > > A build flagged for QA (yocto-4.3.rc1) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-4.3.rc1 The regression report looks worryingly empty. It has been generated with yocto-4.2 as comparison base. When taking a look at yocto-testresults content for it, I only find a few test results (11, while it should be something around 300). I am not sure yet if we did some mistakes while re-uploading manually missing tests results during the 4.2 cycle, or if tests results are indeed suffering some issues for release builds (this is repeatable on different 4.2.x releases). So in the mean time, here is a manual regression report between 4.3_M3 and yocto-4.3.rc1: https://pastebin.com/6QbfGstR The report has a "rate limit" applied for noisy regression (patch incoming) Kind regards, Alexis -- Alexis Lothoré, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#61408): https://lists.yoctoproject.org/g/yocto/message/61408 Mute This Topic: https://lists.yoctoproject.org/mt/102034502/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [yocto] [yocto-autobuilder-helper][PATCH] config.json: add a workaround for the "autobuilderlog.json" error
Le jeu. 19 oct. 2023 à 01:22, Jose Quaresma a écrit :
> Hi Yoann,
Hi!
> I have found the same for BBLAYERS that was fixed [1] expanding any relative
> path that could exist.
> Maybe it would be better to also expand BB_LOGCONFIG when the newbuilddir
> argument is present.
>
> [1]
> https://git.yoctoproject.org/poky/commit/id=f5f465ff5777eb99941db3dda84e65d4699d97f7
OOOooohh That is interesting, Thanks!
For reference, I've had to fix the URL:
https://git.yoctoproject.org/poky/commit/?id=f5f465ff5777eb99941db3dda84e65d4699d97f7
And thank you for updating the bug :)
> Jose
>
> Yoann Congal escreveu no dia quarta, 18/10/2023 à(s)
> 23:28:
>>
>> For the reproducible-meta-oe builder, workaround the bug #15241 [1], by
>> passing BB_LOGCONFIG through "readlink -f" to avoid relative reference
>> to the main build dir.
>>
>> Also, switch from BBPATH to BUILDDIR to reference the main build dir.
>>
>> [1]: https://bugzilla.yoctoproject.org/show_bug.cgi?id=15241
>>
>> Signed-off-by: Yoann Congal
>> ---
>> config.json | 20 ++--
>> 1 file changed, 10 insertions(+), 10 deletions(-)
>>
>> diff --git a/config.json b/config.json
>> index c01a453..84da67b 100644
>> --- a/config.json
>> +++ b/config.json
>> @@ -303,7 +303,7 @@
>> ],
>> "step1" : {
>> "shortname" : "Repro meta-oe/meta-filesystems",
>> -"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-filesystems/
>> DISPLAY=:1 oe-selftest --newbuilddir $BBPATH/build-st-meta-filesystems -r
>> reproducible"],
>> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-filesystems/
>> DISPLAY=:1 BB_LOGCONFIG=$(readlink -f $BB_LOGCONFIG) oe-selftest
>> --newbuilddir $BUILDDIR/build-st-meta-filesystems -r reproducible"],
>> "ADDLAYER" : [
>> "${BUILDDIR}/../meta-openembedded/meta-oe",
>> "${BUILDDIR}/../meta-openembedded/meta-python",
>> @@ -323,7 +323,7 @@
>> },
>> "step2" : {
>> "shortname" : "Repro meta-oe/meta-gnome",
>> -"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-gnome/
>> DISPLAY=:1 oe-selftest --newbuilddir $BBPATH/build-st-meta-gnome -r
>> reproducible"],
>> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-gnome/
>> DISPLAY=:1 BB_LOGCONFIG=$(readlink -f $BB_LOGCONFIG) oe-selftest
>> --newbuilddir $BUILDDIR/build-st-meta-gnome -r reproducible"],
>> "ADDLAYER" : [
>> "${BUILDDIR}/../meta-openembedded/meta-oe",
>> "${BUILDDIR}/../meta-openembedded/meta-python",
>> @@ -343,14 +343,14 @@
>> },
>> "step3" : {
>> "shortname" : "Repro meta-oe/meta-initramfs",
>> -"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-initramfs/
>> DISPLAY=:1 oe-selftest --newbuilddir $BBPATH/build-st-meta-initramfs -r
>> reproducible"],
>> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-initramfs/
>> DISPLAY=:1 BB_LOGCONFIG=$(readlink -f $BB_LOGCONFIG) oe-selftest
>> --newbuilddir $BUILDDIR/build-st-meta-initramfs -r reproducible"],
>> "ADDLAYER" : [
>> "${BUILDDIR}/../meta-openembedded/meta-initramfs"
>> ]
>> },
>> "step4" : {
>> "shortname" : "Repro meta-oe/meta-multimedia",
>> -"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-multimedia/
>> DISPLAY=:1 oe-selftest --newbuilddir $BBPATH/build-st-meta-multimedia -r
>> reproducible"],
>> +"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-multimedia/
>> DISPLAY=:1 BB_LOGCONFIG=$(readlink -f $BB_LOGCONFIG) oe-selftest
>> --newbuilddir $BUILDDIR/build-st-meta-multimedia -r reproducible"],
>> "ADDLAYER" : [
>> "${BUILDDIR}/../meta-openembedded/meta-oe",
>> "${BUILDDIR}/../meta-openembedded/meta-python",
>> @@ -367,7 +367,7 @@
>> },
>> "step5" : {
>> "shortname" : "Repro meta-oe/meta-networking",
>> -"EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc;
>> OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail-openembedded/meta-networking/
>> DISPLAY=:1 oe-selftest --newbuilddir $BBPATH/build-st-meta-networking -r
>> reproducible"],
>> +
