[PATCH] board: rzg2l: Update MAINTAINERS file to match dts/upstream paths

[Paul Barker]

We are now using the dts/upstream subtree for the RZ/G2L SoC family, so
update the board MAINTAINERS file to match rz-smarc dtsi files in this
subtree.

Signed-off-by: Paul Barker 
---
 board/renesas/rzg2l/MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/renesas/rzg2l/MAINTAINERS b/board/renesas/rzg2l/MAINTAINERS
index 0a51391c1fc9..0e656e2ef4f0 100644
--- a/board/renesas/rzg2l/MAINTAINERS
+++ b/board/renesas/rzg2l/MAINTAINERS
@@ -1,6 +1,6 @@
 RENESAS RZG2L BOARD FAMILY
 M: Paul Barker 
 S: Supported
-F: arch/arm/dts/rz-smarc-common.dtsi
+N: rz-smarc
 N: rzg2l
 N: r9a07g044
-- 
2.43.0

Re: [PATCH v2 2/2] rockchip: add support for Radxa ROCK 5A with SPI NOR flash module

[Quentin Schulz]

Hi Naoki,

On 10/30/24 4:09 AM, FUKAUMI Naoki wrote:

Hi,

could you review this patch, anyone?

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

On 8/25/24 07:33, FUKAUMI Naoki wrote:

on Radxa ROCK 5A, sdhci(eMMC) and fspim0(SPI NOR flash) share pins
(i.e. eMMC and SPI NOR flash are exclusive), new defconfig and dts
specifically for SPI NOR flash is required.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v2
- fix subject
---
  arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi | 24 ++
  arch/arm/dts/rk3588s-rock-5a-spi.dts |  4 +
  board/radxa/rock5a-rk3588s/MAINTAINERS   |  5 +-
  configs/rock5a-spi-rk3588s_defconfig | 83 
  4 files changed, 113 insertions(+), 3 deletions(-)
  create mode 100644 arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3588s-rock-5a-spi.dts
  create mode 100644 configs/rock5a-spi-rk3588s_defconfig

diff --git a/arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi b/arch/arm/ 
dts/rk3588s-rock-5a-spi-u-boot.dtsi

new file mode 100644
index 000..5cd131d3cb1
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Collabora Ltd.
+ */
+
+#include "rk3588s-u-boot.dtsi"
+
+&fspim0_pins {
+    bootph-pre-ram;
+    bootph-some-ram;
+};
+
+&sdhci {
+    status = "disabled";
+};
+
+&sfc {
+    status = "okay";
+
+    flash@0 {
+    bootph-pre-ram;
+    bootph-some-ram;
+    };
+};


I assume the board can only be fitted with an SPI NOR or an eMMC and not 
both at the same time? If that's the case, then the status = disabled 
and status = okay should be in the dts. I assume we want this to be in 
the Linux kernel first too, either as a separate DTS or with a DTSO (not 
sure what they will want).


diff --git a/arch/arm/dts/rk3588s-rock-5a-spi.dts b/arch/arm/dts/ 
rk3588s-rock-5a-spi.dts

new file mode 100644
index 000..780e90d041b
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-spi.dts
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include "rk3588s-rock-5a.dts"
diff --git a/board/radxa/rock5a-rk3588s/MAINTAINERS b/board/radxa/ 
rock5a-rk3588s/MAINTAINERS

index a569efa74e3..06ebc9829f4 100644
--- a/board/radxa/rock5a-rk3588s/MAINTAINERS
+++ b/board/radxa/rock5a-rk3588s/MAINTAINERS
@@ -4,6 +4,5 @@ R:    Jonas Karlman 
  S:    Maintained
  F:    board/radxa/rock5a-rk3588s
  F:    include/configs/rock5a-rk3588s.h
-F:    configs/rock5a-rk3588s_defconfig
-F:    arch/arm/dts/rk3588s-rock-5a.dts
-F:    arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
+F:    configs/rock5a*
+F:    arch/arm/dts/rk3588s-rock-5a*
diff --git a/configs/rock5a-spi-rk3588s_defconfig b/configs/rock5a- 
spi-rk3588s_defconfig

new file mode 100644
index 000..297278c7a06
--- /dev/null
+++ b/configs/rock5a-spi-rk3588s_defconfig


If Radxa starts having many such options, maybe it won't make a lot of 
sense to duplicate configs but rather have config fragments to change 
the default DT and add a few symbols that differ from the base (I assume 
we may have something similar needed for rock 5b+ compared to rock5b for 
example?


Keeping all configs in sync for essentially same board with small 
differences may be difficult, maybe using config fragments will help?



@@ -0,0 +1,83 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a-spi"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
+CONFIG_SPL_SERIAL=y
+CONFIG_TARGET_ROCK5A_RK3588=y
+CONFIG_DEBUG_UART_BASE=0xFEB5
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588s-rock-5a.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
+CONFIG_SPL_ATF=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+# CONFIG_OF_UPSTREAM is not set
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned- 
clocks assigned-clock-rates assigned-clock-parents"

+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_MISC=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y


I assume out of the MMC_DW_ROCKCHIP and MMC_

[PATCH 1/2] ARM: dts: Drop unused RZ/G2L devicetrees

[Paul Barker]

We are now using the dts/upstream subtree for the RZ/G2L SoC family.

Signed-off-by: Paul Barker 
---
 arch/arm/dts/Makefile |3 -
 arch/arm/dts/r9a07g044.dtsi   | 1273 -
 arch/arm/dts/r9a07g044l2-smarc.dts|   39 -
 arch/arm/dts/r9a07g044l2.dtsi |   13 -
 arch/arm/dts/rz-smarc-common.dtsi |  183 ---
 arch/arm/dts/rzg2l-smarc-pinfunction.dtsi |  157 ---
 arch/arm/dts/rzg2l-smarc-som.dtsi |  371 --
 arch/arm/dts/rzg2l-smarc.dtsi |  181 ---
 8 files changed, 2220 deletions(-)
 delete mode 100644 arch/arm/dts/r9a07g044.dtsi
 delete mode 100644 arch/arm/dts/r9a07g044l2-smarc.dts
 delete mode 100644 arch/arm/dts/r9a07g044l2.dtsi
 delete mode 100644 arch/arm/dts/rz-smarc-common.dtsi
 delete mode 100644 arch/arm/dts/rzg2l-smarc-pinfunction.dtsi
 delete mode 100644 arch/arm/dts/rzg2l-smarc-som.dtsi
 delete mode 100644 arch/arm/dts/rzg2l-smarc.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index aeccfa93fc53..e0cc9937acb4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -979,9 +979,6 @@ dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
imxrt1020-evk.dtb \
imxrt1170-evk.dtb \
 
-dtb-$(CONFIG_TARGET_RZG2L) += \
-   r9a07g044l2-smarc.dts
-
 ifdef CONFIG_RCAR_64
 DTC_FLAGS += -R 4 -p 0x1000
 endif
diff --git a/arch/arm/dts/r9a07g044.dtsi b/arch/arm/dts/r9a07g044.dtsi
deleted file mode 100644
index 66f68fc2b241..
--- a/arch/arm/dts/r9a07g044.dtsi
+++ /dev/null
@@ -1,1273 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-/*
- * Device Tree Source for the RZ/G2L and RZ/G2LC common SoC parts
- *
- * Copyright (C) 2021 Renesas Electronics Corp.
- */
-
-#include 
-#include 
-
-/ {
-   compatible = "renesas,r9a07g044";
-   #address-cells = <2>;
-   #size-cells = <2>;
-
-   audio_clk1: audio1-clk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   /* This value must be overridden by boards that provide it */
-   clock-frequency = <0>;
-   };
-
-   audio_clk2: audio2-clk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   /* This value must be overridden by boards that provide it */
-   clock-frequency = <0>;
-   };
-
-   /* External CAN clock - to be overridden by boards that provide it */
-   can_clk: can-clk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
-   /* clock can be either from exclk or crystal oscillator (XIN/XOUT) */
-   extal_clk: extal-clk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   /* This value must be overridden by the board */
-   clock-frequency = <0>;
-   };
-
-   cluster0_opp: opp-table-0 {
-   compatible = "operating-points-v2";
-   opp-shared;
-
-   opp-15000 {
-   opp-hz = /bits/ 64 <15000>;
-   opp-microvolt = <110>;
-   clock-latency-ns = <30>;
-   };
-   opp-3 {
-   opp-hz = /bits/ 64 <3>;
-   opp-microvolt = <110>;
-   clock-latency-ns = <30>;
-   };
-   opp-6 {
-   opp-hz = /bits/ 64 <6>;
-   opp-microvolt = <110>;
-   clock-latency-ns = <30>;
-   };
-   opp-12 {
-   opp-hz = /bits/ 64 <12>;
-   opp-microvolt = <110>;
-   clock-latency-ns = <30>;
-   opp-suspend;
-   };
-   };
-
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu-map {
-   cluster0 {
-   core0 {
-   cpu = <&cpu0>;
-   };
-   core1 {
-   cpu = <&cpu1>;
-   };
-   };
-   };
-
-   cpu0: cpu@0 {
-   compatible = "arm,cortex-a55";
-   reg = <0>;
-   device_type = "cpu";
-   #cooling-cells = <2>;
-   next-level-cache = <&L3_CA55>;
-   enable-method = "psci";
-   clocks = <&cpg CPG_CORE R9A07G044_CLK_I>;
-   operating-points-v2 = <&cluster0_opp>;
-   };
-
-   cpu1: cpu@100 {
-   compatible = "arm,cortex-a55";
-   reg = <0x100>;
-   dev

[PATCH 2/2] dt-bindings: Drop unused RZ/G2L devicetree bindings

[Paul Barker]

We are now using the dts/upstream subtree for the RZ/G2L SoC family.

Signed-off-by: Paul Barker 
---
 include/dt-bindings/clock/r9a07g044-cpg.h | 220 --
 .../interrupt-controller/irqc-rzg2l.h |  25 --
 include/dt-bindings/pinctrl/rzg2l-pinctrl.h   |  23 --
 3 files changed, 268 deletions(-)
 delete mode 100644 include/dt-bindings/clock/r9a07g044-cpg.h
 delete mode 100644 include/dt-bindings/interrupt-controller/irqc-rzg2l.h
 delete mode 100644 include/dt-bindings/pinctrl/rzg2l-pinctrl.h

diff --git a/include/dt-bindings/clock/r9a07g044-cpg.h 
b/include/dt-bindings/clock/r9a07g044-cpg.h
deleted file mode 100644
index 0bb17ff1a01a..
--- a/include/dt-bindings/clock/r9a07g044-cpg.h
+++ /dev/null
@@ -1,220 +0,0 @@
-/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
- *
- * Copyright (C) 2021 Renesas Electronics Corp.
- */
-#ifndef __DT_BINDINGS_CLOCK_R9A07G044_CPG_H__
-#define __DT_BINDINGS_CLOCK_R9A07G044_CPG_H__
-
-#include 
-
-/* R9A07G044 CPG Core Clocks */
-#define R9A07G044_CLK_I0
-#define R9A07G044_CLK_I2   1
-#define R9A07G044_CLK_G2
-#define R9A07G044_CLK_S0   3
-#define R9A07G044_CLK_S1   4
-#define R9A07G044_CLK_SPI0 5
-#define R9A07G044_CLK_SPI1 6
-#define R9A07G044_CLK_SD0  7
-#define R9A07G044_CLK_SD1  8
-#define R9A07G044_CLK_M0   9
-#define R9A07G044_CLK_M1   10
-#define R9A07G044_CLK_M2   11
-#define R9A07G044_CLK_M3   12
-#define R9A07G044_CLK_M4   13
-#define R9A07G044_CLK_HP   14
-#define R9A07G044_CLK_TSU  15
-#define R9A07G044_CLK_ZT   16
-#define R9A07G044_CLK_P0   17
-#define R9A07G044_CLK_P1   18
-#define R9A07G044_CLK_P2   19
-#define R9A07G044_CLK_AT   20
-#define R9A07G044_OSCCLK   21
-#define R9A07G044_CLK_P0_DIV2  22
-
-/* R9A07G044 Module Clocks */
-#define R9A07G044_CA55_SCLK0
-#define R9A07G044_CA55_PCLK1
-#define R9A07G044_CA55_ATCLK   2
-#define R9A07G044_CA55_GICCLK  3
-#define R9A07G044_CA55_PERICLK 4
-#define R9A07G044_CA55_ACLK5
-#define R9A07G044_CA55_TSCLK   6
-#define R9A07G044_GIC600_GICCLK7
-#define R9A07G044_IA55_CLK 8
-#define R9A07G044_IA55_PCLK9
-#define R9A07G044_MHU_PCLK 10
-#define R9A07G044_SYC_CNT_CLK  11
-#define R9A07G044_DMAC_ACLK12
-#define R9A07G044_DMAC_PCLK13
-#define R9A07G044_OSTM0_PCLK   14
-#define R9A07G044_OSTM1_PCLK   15
-#define R9A07G044_OSTM2_PCLK   16
-#define R9A07G044_MTU_X_MCK_MTU3   17
-#define R9A07G044_POE3_CLKM_POE18
-#define R9A07G044_GPT_PCLK 19
-#define R9A07G044_POEG_A_CLKP  20
-#define R9A07G044_POEG_B_CLKP  21
-#define R9A07G044_POEG_C_CLKP  22
-#define R9A07G044_POEG_D_CLKP  23
-#define R9A07G044_WDT0_PCLK24
-#define R9A07G044_WDT0_CLK 25
-#define R9A07G044_WDT1_PCLK26
-#define R9A07G044_WDT1_CLK 27
-#define R9A07G044_WDT2_PCLK28
-#define R9A07G044_WDT2_CLK 29
-#define R9A07G044_SPI_CLK2 30
-#define R9A07G044_SPI_CLK  31
-#define R9A07G044_SDHI0_IMCLK  32
-#define R9A07G044_SDHI0_IMCLK2 33
-#define R9A07G044_SDHI0_CLK_HS 34
-#define R9A07G044_SDHI0_ACLK   35
-#define R9A07G044_SDHI1_IMCLK  36
-#define R9A07G044_SDHI1_IMCLK2 37
-#define R9A07G044_SDHI1_CLK_HS 38
-#define R9A07G044_SDHI1_ACLK   39
-#define R9A07G044_GPU_CLK  40
-#define R9A07G044_GPU_AXI_CLK  41
-#define R9A07G044_GPU_ACE_CLK  42
-#define R9A07G044_ISU_ACLK 43
-#define R9A07G044_ISU_PCLK 44
-#define R9A07G044_H264_CLK_A   45
-#define R9A07G044_H264_CLK_P   46
-#define R9A07G044_CRU_SYSCLK   47
-#define R9A07G044_CRU_VCLK 48
-#define R9A07G044_CRU_PCLK 49
-#define R9A07G044_CRU_ACLK 50
-#define R9A07G044_MIPI_DSI_PLLCLK  51
-#define R9A07G044_MIPI_DSI_SYSCLK  52
-#define R9A07G044_MIPI_DSI_ACLK53
-#define R9A07G044_MIPI_DSI_PCLK54
-#define R9A07G044_MIPI_DSI_VCLK55
-#define R9A07G044_MIPI_DSI_LPCLK   56
-#define R9A07G044_LCDC_CLK_A   57
-#define R9A07G044_LCDC_CLK_P   58
-#define R9A07G044_LCDC_CLK_D   59
-#define R9A07G044_SSI0_PCLK2   60
-#define R9A07G044_SSI0_PCLK_SFR61
-#define R9A07G044_SSI1_PCLK2   62
-#define R9A07G044_SSI1_PCLK_SFR63
-#define R9A07G044_SSI2_PCLK2   64
-#define R9A07G044_SSI2_PCLK_SFR65
-#define R9A07G044_SSI3_PCLK2   66
-#define R9A07G0

Re: [PATCH v1] acpi_table: Fix coverity defect in acpi_write_spcr

[Patrick Rudolph]

Hi Tom,
On Tue, Oct 29, 2024 at 3:53 AM Tom Rini  wrote:
>
> On Mon, Oct 28, 2024 at 05:27:14PM -0600, Tom Rini wrote:
> > On Mon, 28 Oct 2024 09:08:35 +0100, Patrick Rudolph wrote:
> >
> > > Fix "Integer handling issues  (SIGN_EXTENSION)" in newly added code:
> > > Cast serial_info.reg_offset to u64 to prevent an integer overflow when
> > > shifted too many bits to the left. Currently this never happens as the
> > > shift is supposed to be less than 4.
> >
> > Applied to u-boot/master, thanks!
>
> "I'll just bend my rules and apply this before release, it'll be fine" I
> said to myself. But:
>sandbox:  +   sandbox
> +(sandbox) In file included from include/linux/printk.h:4,
> +(sandbox)  from include/linux/kernel.h:5,
> +(sandbox)  from include/linux/libfdt_env.h:13,
> +(sandbox)  from include/linux/libfdt.h:6,
> +(sandbox)  from include/fdtdec.h:17,
> +(sandbox)  from include/dm/ofnode.h:11,
> +(sandbox)  from include/dm/device.h:13,
> +(sandbox)  from include/dm.h:13,
> +(sandbox)  from lib/acpi/acpi_table.c:10:
> +(sandbox) lib/acpi/acpi_table.c: In function ‘acpi_write_spcr’:
> +(sandbox) lib/acpi/acpi_table.c:498:15: error: format ‘%lx’ expects argument 
> of type ‘long unsigned int’, but argument 8 has type ‘u64’ {aka ‘long long 
> unsigned int’} [-Werror=format=]
> +(sandbox)   498 | debug("UART type %u @ %lx\n", 
> spcr->interface_type, serial_address);
> +(sandbox)   |   ^~
> +(sandbox) include/log.h:159:21: note: in definition of macro ‘pr_fmt’
> +(sandbox)   159 | #define pr_fmt(fmt) fmt
> +(sandbox)   | ^~~
> +(sandbox) include/log.h:260:17: note: in expansion of macro ‘log’
> +(sandbox)   260 | log(LOG_CATEGORY,  
>  \
> +(sandbox)   | ^~~
> +(sandbox) include/log.h:282:9: note: in expansion of macro ‘debug_cond’
> +(sandbox)   282 | debug_cond(_DEBUG, fmt, ##args)
> +(sandbox)   | ^~
> +(sandbox) lib/acpi/acpi_table.c:498:9: note: in expansion of macro ‘debug’
> +(sandbox)   | ^
> +(sandbox) lib/acpi/acpi_table.c:498:33: note: format string is defined here
> +(sandbox)   |   ~~^
> +(sandbox)   | |
> +(sandbox)   | long unsigned int
> +(sandbox)   |   %llx
> +(sandbox) cc1: all warnings being treated as errors
> +(sandbox) make[3]: *** [scripts/Makefile.build:256: lib/acpi/acpi_table.o] 
> Error 1
> +(sandbox) make[2]: *** [scripts/Makefile.build:398: lib/acpi] Error 2
> +(sandbox) make[1]: *** [Makefile:1914: lib] Error 2
> +(sandbox) make: *** [Makefile:177: sub-make] Error 2
>
Appologies, I only build tested it on a single board.
Will send an updated version.

> And most other platforms too. I'm reverting this for now, and if someone
> is packaging v2025.01-rc1 too, just do that too. Sorry.
>
> --
> Tom

Re: [PATCH v2 4/5] arm: mach-k3: j721e-init.c: J7200: Add support for CONFIG_K3_OPP_LOW

[Manorit Chawdhry]

Hi Neha, Aniket,

On 13:31-20241030, Manorit Chawdhry wrote:
> Hi Aniket,
> 
> On 15:40-20241029, Manorit Chawdhry wrote:
> > Hi Aniket,
> > 
> > On 18:27-20241023, Aniket Limaye wrote:
> > > From: Reid Tonking 
> > > 
> > > The default j7200 devicetree and k3_avs driver set 2GHz/1GHz frequency
> > > for A72/MSMC clks and the OPP_NOM voltage.
> > > 
> > > J7200 SOCs may support OPP_LOW Operating Performance Point:
> > > 1GHz/500MHz clks for A72/MSMC and OPP_LOW AVS voltage read from efuse.
> > > 
> > > Hence, add a config check to select OPP_LOW specs:
> > > - Check if OPP_LOW AVS voltage read from efuse is valid.
> > > - Update the clock frequencies in devicetree.
> > > - Program the OPP_LOW AVS voltage for VDD_CPU.
> > > 
> > > Signed-off-by: Reid Tonking 
> > > Signed-off-by: Aniket Limaye 
> > > 
> > > ---
[...]
> > >  
> > > +int fix_freq(const void *fdt)
> 
> I think this can be static as well btw, maybe rename it to something
> more descriptive as well. fdt_fixup_a72_clock_frequency?

Do you think ft_system_setup is a good place for doing this fixup btw?
Was wondering that it would be good to know what all DT fixups are being
done at some common place instead of multiple scattered places but not
sure when does ft_system_setup kick in, would it be before we startup
a72?

Regards,
Manorit

Re: [PATCH v9 02/11] efi_loader: Add a test app

[Simon Glass]

Hi Tom,

On Tue, 29 Oct 2024 at 21:13, Tom Rini  wrote:
>
> On Tue, Oct 29, 2024 at 08:22:10PM +0100, Simon Glass wrote:
>
> > Add a simple app to use for testing. This is intended to do whatever it
> > needs to for testing purposes. For now it just prints a message and
> > exits boot services.
> >
> > There was a considerable amount of discussion about whether it is OK to
> > call exit-boot-services and then return to U-Boot. This is not normally
> > done in a real application, since exit-boot-services is used to
> > completely disconnect from U-Boot. However, since this is a test, we
> > need to check the results of running the app, so returning is necessary.
> > It works correctly and it provides a nice model of how to test the EFI
> > code in a simple way.
> >
> > Signed-off-by: Simon Glass 
>
> This approach has been specifically rejected with an explained
> rationale: It breaks how UEFI applications work and you cannot run
> further UEFI tests in sandbox without resetting.
>
> Since as you note, you can't reset in a C-based test, rework this to be
> a python test where we can safely reset the system and verify that. I
> believe Heinrich even noted that a test which checks ExitBootServices()
> working as expected would be helpful as we only have a watchdog test
> currently.

Unfortunately I believe this is the wrong direction, as we are unable
to check the state of anything once a reset has happened. Thus I
cannot build on this test, e.g. to see what happened to the devices
and whether they are still bound. It becomes just a 'black box' test.
None of the other bootflow tests work this way, BTW.

Regards,
Simon

Re: [PATCH 1/2] rockchip: rk356x: Implement checkboard() to print SoC variant

[Simon Glass]

Hi Jonas,

On Sun, 20 Oct 2024 at 00:24, Jonas Karlman  wrote:
>
> Hi Simon,
>
> On 2024-10-19 04:00, Simon Glass wrote:
> > Hi Jonas,
> >
> > On Fri, 18 Oct 2024 at 10:34, Jonas Karlman  wrote:
> >>
> >> Implement checkboard() to print current SoC model, e.g. one of:
> >>
> >>   SoC:   RK3566 v1
> >>   SoC:   RK3566 v2
> >>   SoC:   RK3566T v2
> >>   SoC:   RK3568 v2
> >>   SoC:   RK3568B2 v2
> >>   SoC:   RK3568J v2
> >>
> >> when U-Boot proper is started.
> >>
> >> Information about what SoC model, variant and version is read from OTP.
> >>
> >> Signed-off-by: Jonas Karlman 
> >> ---
> >>  arch/arm/dts/rk356x-u-boot.dtsi|  4 ++
> >>  arch/arm/mach-rockchip/rk3568/rk3568.c | 65 ++
> >>  configs/generic-rk3568_defconfig   |  2 +-
> >>  3 files changed, 70 insertions(+), 1 deletion(-)
> >>
> >
> > Instead of this, can you use add a CPU driver? Then it should happen
> > automatically - see print_cpuinfo().
>
> Unfortunately the CPU driver seem to be more related to the /cpus nodes,
> e.g. the arm cores included in these SoCs and not really related to the
> overall SoC used by the board.
>
> This instead depend on the DISPLAY_BOARDINFO and its checkboard() as the
> type of SoC seem more related to the board soc target.

OK.

Can we get plumb it into try_sysinfo()  somehow? Perhaps add a sysinfo
driver which returns a new SYSINFO_ID_SOC option?

I'm just trying to handle things using driver model, etc. rather than
weak functions.

>
> Regards,
> Jonas
>

[PATCH v4 1/2] arm64: dts: rockchip: Add support for rk3588 based Cool Pi CM5 GenBook

[Andy Yan]

Cool Pi CM5 GenBook works as a carrier board connect with CM5 [0].

Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080

This patch add basic support to bringup eMMC/USB HOST/WiFi/TouchPad/
Battery/PCIE NVME, and can also drive a HDMI output with out of tree
hdmi patches.

[0] 
https://www.crowdsupply.com/shenzhen-tianmao-technology-co-ltd/genbook-rk3588

Signed-off-by: Andy Yan 
Link: https://lore.kernel.org/r/20240730102433.540260-3-andys...@163.com
Signed-off-by: Heiko Stuebner 

[ upstream commit: 4a8c1161b843c366776fc872a6fe45b743b2983e ]

(cherry picked from commit dc6316da23734d9321e09f8c8a7669f4b4cb9f75)

---

(no changes since v2)

Changes in v2:
- Cherry pick it from 
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git

 .../rockchip/rk3588-coolpi-cm5-genbook.dts| 349 ++
 1 file changed, 349 insertions(+)
 create mode 100644 
dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5-genbook.dts

diff --git a/dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5-genbook.dts 
b/dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5-genbook.dts
new file mode 100644
index 000..6418286efe4
--- /dev/null
+++ b/dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5-genbook.dts
@@ -0,0 +1,349 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Rockchip Electronics Co., Ltd.
+ *
+ */
+
+/dts-v1/;
+
+#include 
+#include "rk3588-coolpi-cm5.dtsi"
+
+/ {
+   model = "CoolPi CM5 GenBook";
+   compatible = "coolpi,pi-cm5-genbook", "coolpi,pi-cm5", 
"rockchip,rk3588";
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   enable-gpios = <&gpio4 RK_PA3 GPIO_ACTIVE_HIGH>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&bl_en>;
+   power-supply = <&vcc12v_dcin>;
+   pwms = <&pwm6 0 25000 0>;
+   };
+
+   battery: battery {
+   compatible = "simple-battery";
+   charge-full-design-microamp-hours = <980>;
+   voltage-max-design-microvolt = <435>;
+   voltage-min-design-microvolt = <300>;
+   };
+
+   charger: dc-charger {
+   compatible = "gpio-charger";
+   charger-type = "mains";
+   gpios = <&gpio1 RK_PC0 GPIO_ACTIVE_LOW>;
+   };
+
+   leds: leds {
+   compatible = "gpio-leds";
+
+   heartbeat_led: led-0 {
+   color = ;
+   function = LED_FUNCTION_STATUS;
+   gpios = <&gpio1 RK_PB0 GPIO_ACTIVE_HIGH>;
+   linux,default-trigger = "heartbeat";
+   };
+
+   wlan_led: led-1 {
+   color = ;
+   function = LED_FUNCTION_WLAN;
+   gpios = <&gpio0 RK_PC5 GPIO_ACTIVE_HIGH>;
+   };
+
+   charging_red: led-2 {
+   function = LED_FUNCTION_CHARGING;
+   color = ;
+   gpios = <&gpio3 RK_PD2 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   vcc12v_dcin: vcc12v-dcin-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc12v_dcin";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   };
+
+   vcc_sys: vcc-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <700>;
+   regulator-max-microvolt = <700>;
+   vin-supply = <&vcc12v_dcin>;
+   };
+
+   vcc5v0_sys: vcc5v0-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc5v0_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <700>;
+   regulator-max-microvolt = <700>;
+   vin-supply = <&vcc_sys>;
+   };
+
+   vcc3v3_sys: vcc3v3-sys-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_sys";
+   regulator-always-on;
+   regulator-boot-on;
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <&vcc5v0_sys>;
+   };
+
+   vcc3v3_lcd: vcc3v3-lcd-regulator {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3_lcd";
+   enable-active-high;
+   gpio = <&gpio1 RK_PC4 GPIO_ACTIVE_HIGH>;
+  

[PATCH v4 2/2] board: rockchip: Add support for rk3588 GenBook

[Andy Yan]

Add support for Cool Pi GenBook, it works as a carrier board
connect with CM5 SOM.

Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080

Tested by Armbian boot on USB disk.

Signed-off-by: Andy Yan 

---

Changes in v4:
- Fix a underline too short error in rst doc

Changes in v3:
- Remove upstreamed dt in genbook-u-boot.dtsi
- Remove MMC releated config as there is no SD-card on this machine
- Enable LED config
- Enable rk8xx pmic
- rename defconfig to coolpi-cm5-genbook-rk3588_defconfig
- redefine BOOT_TARGETS

Changes in v2:
- split the dts to a separate commit
- rename to genbook_cm5_rk3588
- move readme to doc/board, and write as reStructuredText format
- alphabetically reorder
- update doc/board/rockchip

 .../dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi |  20 
 arch/arm/mach-rockchip/rk3588/Kconfig |  19 
 board/coolpi/genbook_cm5_rk3588/Kconfig   |  12 +++
 board/coolpi/genbook_cm5_rk3588/MAINTAINERS   |   7 ++
 configs/coolpi-cm5-genbook-rk3588_defconfig   | 101 ++
 doc/board/coolpi/genbook_cm5_rk3588.rst   |  68 
 doc/board/coolpi/index.rst|   9 ++
 doc/board/rockchip/rockchip.rst   |   1 +
 include/configs/genbook-cm5-rk3588.h  |  31 ++
 9 files changed, 268 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi
 create mode 100644 board/coolpi/genbook_cm5_rk3588/Kconfig
 create mode 100644 board/coolpi/genbook_cm5_rk3588/MAINTAINERS
 create mode 100644 configs/coolpi-cm5-genbook-rk3588_defconfig
 create mode 100644 doc/board/coolpi/genbook_cm5_rk3588.rst
 create mode 100644 doc/board/coolpi/index.rst
 create mode 100644 include/configs/genbook-cm5-rk3588.h

diff --git a/arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi 
b/arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi
new file mode 100644
index 000..5a3073d6e7f
--- /dev/null
+++ b/arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588-u-boot.dtsi"
+
+&fspim2_pins {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
+
+&sfc {
+   flash@0 {
+   bootph-pre-ram;
+   bootph-some-ram;
+   };
+};
+
+/* USB A out */
+&usb_host1_xhci {
+   snps,dis_u3_susphy_quirk;
+};
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
index a76a470cc98..c53f6bb926e 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -29,6 +29,24 @@ config TARGET_CM3588_NAS_RK3588
  - 3.5mm Headphone out, 2.0mm PH-2A Mic in
  - 5V Fan connector, PWM beeper, IR receiver, RTC battery connector
 
+config TARGET_GENBOOK_CM5_RK3588
+   bool "Cool Pi CM5 GenBook"
+   select BOARD_LATE_INIT
+   help
+ GeenBook is a notebook based on Rockchip RK3588, and works as a 
carrier
+ board connect with CM5 SOM.
+
+ Specification:
+ - Rockchip RK3588
+ - LPDDR5X 8/32 GB
+ - eMMC 64 GB
+ - HDMI Type A out x 1
+ - USB 3.0 Host x 1
+ - USB-C 3.0 with DisplayPort AltMode
+ - PCIE M.2 E Key for RTL8852BE Wireless connection
+ - PCIE M.2 M Key for NVME connection
+ - eDP panel with 1920x1080
+
 config TARGET_JAGUAR_RK3588
bool "Theobroma Systems SBC-RK3588-AMR (Jaguar)"
select BOARD_LATE_INIT
@@ -361,6 +379,7 @@ config TEXT_BASE
default 0x00a0
 
 source "board/armsom/sige7-rk3588/Kconfig"
+source "board/coolpi/genbook_cm5_rk3588/Kconfig"
 source "board/edgeble/neural-compute-module-6/Kconfig"
 source "board/friendlyelec/cm3588-nas-rk3588/Kconfig"
 source "board/friendlyelec/nanopc-t6-rk3588/Kconfig"
diff --git a/board/coolpi/genbook_cm5_rk3588/Kconfig 
b/board/coolpi/genbook_cm5_rk3588/Kconfig
new file mode 100644
index 000..67086ea6297
--- /dev/null
+++ b/board/coolpi/genbook_cm5_rk3588/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_GENBOOK_CM5_RK3588
+
+config SYS_BOARD
+   default "genbook_cm5_rk3588"
+
+config SYS_VENDOR
+   default "coolpi"
+
+config SYS_CONFIG_NAME
+   default "genbook-cm5-rk3588"
+
+endif
diff --git a/board/coolpi/genbook_cm5_rk3588/MAINTAINERS 
b/board/coolpi/genbook_cm5_rk3588/MAINTAINERS
new file mode 100644
index 000..0496cc93b59
--- /dev/null
+++ b/board/coolpi/genbook_cm5_rk3588/MAINTAINERS
@@ -0,0 +1,7 @@
+GENBOOK-CM5-RK3588
+M: Andy Yan 
+S: Maintained
+F: board/coolpi/genbook-cm5-rk3588
+F: include/configs/genbook-cm5-rk3588.h
+F: configs/coolpi-cm5-genbook-rk3588_defconfig
+F: arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi
diff --git a/configs/coolpi-cm5-genbook-rk3588_defconfig 
b/configs/coolpi-cm5-genbook-rk3588_defconfig
new file mode 100644
in

Re: [PATCH v2 4/5] arm: mach-k3: j721e-init.c: J7200: Add support for CONFIG_K3_OPP_LOW

[Aniket Limaye]

On 30/10/24 13:58, Manorit Chawdhry wrote:

Hi Neha, Aniket,

On 13:31-20241030, Manorit Chawdhry wrote:

Hi Aniket,

On 15:40-20241029, Manorit Chawdhry wrote:

Hi Aniket,

On 18:27-20241023, Aniket Limaye wrote:

From: Reid Tonking 

The default j7200 devicetree and k3_avs driver set 2GHz/1GHz frequency
for A72/MSMC clks and the OPP_NOM voltage.

J7200 SOCs may support OPP_LOW Operating Performance Point:
1GHz/500MHz clks for A72/MSMC and OPP_LOW AVS voltage read from efuse.

Hence, add a config check to select OPP_LOW specs:
- Check if OPP_LOW AVS voltage read from efuse is valid.
- Update the clock frequencies in devicetree.
- Program the OPP_LOW AVS voltage for VDD_CPU.

Signed-off-by: Reid Tonking 
Signed-off-by: Aniket Limaye 

---

[...]
  
+int fix_freq(const void *fdt)


I think this can be static as well btw, maybe rename it to something
more descriptive as well. fdt_fixup_a72_clock_frequency?


Do you think ft_system_setup is a good place for doing this fixup btw?
Was wondering that it would be good to know what all DT fixups are being
done at some common place instead of multiple scattered places but not
sure when does ft_system_setup kick in, would it be before we startup
a72?



So it looks like ft_system_setup is being called only before booting 
into linux Kernel.


As discussed offline, another place to handle fdt_fixups cleanly could 
be spl_perform_fixups() in board/ti/j721e/evm.c


I would agree that this dt fixup would be better placed there instead of 
in board_init_f() directly. Will try doing that.


Thanks,
Aniket



Regards,
Manorit

[PATCH v2] acpi_table: Fix coverity defect in acpi_write_spcr

[Patrick Rudolph]

Fix "Integer handling issues  (SIGN_EXTENSION)" in newly added code:
Cast serial_info.reg_offset to u64 to prevent an integer overflow when
shifted too many bits to the left. Currently this never happens as the
shift is supposed to be less than 4.

Signed-off-by: Patrick Rudolph 
---
 lib/acpi/acpi_table.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/lib/acpi/acpi_table.c b/lib/acpi/acpi_table.c
index 6473d95c10..150f75027a 100644
--- a/lib/acpi/acpi_table.c
+++ b/lib/acpi/acpi_table.c
@@ -420,7 +420,7 @@ int acpi_write_dbg2_pci_uart(struct acpi_ctx *ctx, struct 
udevice *dev,
 static int acpi_write_spcr(struct acpi_ctx *ctx, const struct acpi_writer 
*entry)
 {
struct serial_device_info serial_info = {0};
-   ulong serial_address, serial_offset;
+   u64 serial_address, serial_offset;
struct acpi_table_header *header;
struct acpi_spcr *spcr;
struct udevice *dev;
@@ -473,7 +473,7 @@ static int acpi_write_spcr(struct acpi_ctx *ctx, const 
struct acpi_writer *entry
}
 
serial_width = serial_info.reg_width * 8;
-   serial_offset = serial_info.reg_offset << serial_info.reg_shift;
+   serial_offset = ((u64)serial_info.reg_offset) << serial_info.reg_shift;
serial_address = serial_info.addr + serial_offset;
 
/* Encode register access size */
@@ -495,7 +495,7 @@ static int acpi_write_spcr(struct acpi_ctx *ctx, const 
struct acpi_writer *entry
break;
}
 
-   debug("UART type %u @ %lx\n", spcr->interface_type, serial_address);
+   debug("UART type %u @ %llx\n", spcr->interface_type, serial_address);
 
/* Fill GAS */
spcr->serial_port.space_id = space_id;
-- 
2.46.2

Re: [PATCH v1 1/1] drivers: bootcount: Add ZynqMP specific bootcount support

[Michal Simek]

On 10/29/24 19:58, Vasileios Amoiridis wrote:

From: Vasileios Amoiridis 

Add native support of the bootcount mechanism in the ZynqMP by utilising 
internal
PMU registers. The Persistent Global Storage Registers of the Platform 
Management
Unit can keep their value during reboot cycles unless there is a POR reset, 
making
them appropriate for the bootcount mechanism.

Signed-off-by: Vasileios Amoiridis 
---
  drivers/bootcount/Kconfig|  4 
  drivers/bootcount/Makefile   |  1 +
  drivers/bootcount/bootcount_zynqmp.c | 28 
  3 files changed, 33 insertions(+)
  create mode 100644 drivers/bootcount/bootcount_zynqmp.c

diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index fa6d8e7128..95b6a9541a 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -82,6 +82,10 @@ config BOOTCOUNT_AT91
bool "Boot counter for Atmel AT91SAM9XE"
depends on AT91SAM9XE
  
+config BOOTCOUNT_ZYNQMP

+   bool "Boot counter for Zynq UltraScale+ MPSoC"
+   depends on ARCH_ZYNQMP



help would help to also described where that count is stored.

And why not to have it under DM/U_BOOT_DRIVER?
You don't need to create compatible string for it just instantiate it.

Look at:

U_BOOT_DRVINFO(soc_xilinx_zynqmp) = {
 .name = "soc_xilinx_zynqmp",
};



+
  config DM_BOOTCOUNT
  bool "Boot counter in a device-model device"
help
diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
index 245f879633..487adc1212 100644
--- a/drivers/bootcount/Makefile
+++ b/drivers/bootcount/Makefile
@@ -3,6 +3,7 @@
  obj-$(CONFIG_BOOTCOUNT_GENERIC)   += bootcount.o
  obj-$(CONFIG_BOOTCOUNT_MEM)   += bootcount.o
  obj-$(CONFIG_BOOTCOUNT_AT91)  += bootcount_at91.o
+obj-$(CONFIG_BOOTCOUNT_ZYNQMP)  += bootcount_zynqmp.o


please put it to the end of CONFIG_BOOTCOUNT to have it at least in correct 
location


  obj-$(CONFIG_BOOTCOUNT_AM33XX)+= bootcount_davinci.o
  obj-$(CONFIG_BOOTCOUNT_RAM)   += bootcount_ram.o
  obj-$(CONFIG_BOOTCOUNT_ENV)   += bootcount_env.o
diff --git a/drivers/bootcount/bootcount_zynqmp.c 
b/drivers/bootcount/bootcount_zynqmp.c
new file mode 100644
index 00..9bb801e188
--- /dev/null
+++ b/drivers/bootcount/bootcount_zynqmp.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// SPDX-FileCopyrightText: 2024 CERN (home.cern)
+
+#include 
+#include 
+#include 
+
+#define PMU_PERS_GLOB_GEN_STORAGE0 0x00FFD80050


In arch/arm/mach-zynqmp/include/mach/hardware.h
there is already structure defined and gen_storage0 is there too.
Please use it.

Regarding this location. Exception in PMUFW is using this reg.
It means at the end of day it is up to you if you want to use it or not.


+
+void bootcount_store(ulong a)
+{
+   int ret;
+
+   ret = zynqmp_mmio_write(PMU_PERS_GLOB_GEN_STORAGE0, 0xFF, a);
+   if (ret)
+   printf("Failed: mmio write\n");
+}
+
+ulong bootcount_load(void)
+{
+   int ret;
+   u32 val;


as was said val should be initialized here too.


+
+   ret = zynqmp_mmio_read(PMU_PERS_GLOB_GEN_STORAGE0, &val);
+   if (ret)
+   printf("Failed: mmio read\n");
+   return val;
+}


Anyway I expect this driver to be under DM that v2 will change.

Thanks,
Michal

[PATCH] drivers/video/vesa: use MTRRs only on x86

[Yuri Zaporozhets]

MTRR functionality is available only on x86, so this driver cannot be compiled
on other architectures. Fix this with preprocessor directives.

Signed-off-by: Yuri Zaporozhets 
---
 drivers/video/vesa.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/video/vesa.c b/drivers/video/vesa.c
index ab756ac8ea..e96f6747a6 100644
--- a/drivers/video/vesa.c
+++ b/drivers/video/vesa.c
@@ -8,21 +8,26 @@
 #include 
 #include 
 #include 
+#if defined(CONFIG_X86)
 #include 
+#endif
 
 static int vesa_video_probe(struct udevice *dev)
 {
-   struct video_uc_plat *plat = dev_get_uclass_plat(dev);
-   ulong fbbase;
int ret;
 
ret = vesa_setup_video(dev, NULL);
if (ret)
return log_ret(ret);
 
+#if defined(CONFIG_X86)
+   struct video_uc_plat *plat = dev_get_uclass_plat(dev);
+   ulong fbbase;
+
/* Use write-combining for the graphics memory, 256MB */
fbbase = IS_ENABLED(CONFIG_VIDEO_COPY) ? plat->copy_base : plat->base;
mtrr_set_next_var(MTRR_TYPE_WRCOMB, fbbase, 256 << 20);
+#endif
 
return 0;
 }
-- 
2.39.5

Re: [PATCH 1/9] mtd: spi-nor: Remove recently added nor->addr_width == 3 test

[Tudor Ambarus]

On 10/30/24 10:33 AM, Jagan Teki wrote:
> Hi Marek,
> 
> On Sun, Oct 27, 2024 at 1:48 AM Marek Vasut
>  wrote:
>>
>> Remove undocumented nor->addr_width == 3 test. This was added in commit
>> 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
>> without any explanation in the commit message. Remove it.
>>
>> This also has a bad side-effect which breaks READ operation of every SPI NOR
>> which does not use addr_width == 3, e.g. s25fs512s does not work at all. This
>> is because if addr_width != 3, rem_bank_len is always 0, and if rem_bank_len
>> is 0, then read_len is 0 and if read_len is 0, then the spi_nor_read() 
>> returns
>> -EIO.
>>
>> Basic reproducer is as follows:
>> "
>> => sf probe ; sf read 0x5000 0 0x1
>> SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB, total 
>> 64 MiB
>> device 0 offset 0x0, size 0x1
>> SF: 65536 bytes @ 0x0 Read: ERROR -5
>> "
>>
>> Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories 
>> support")
>> Signed-off-by: Marek Vasut 
>> ---
>> Cc: Andre Przywara 
>> Cc: Ashok Reddy Soma 
>> Cc: Jagan Teki 
>> Cc: Michael Walle 
>> Cc: Michal Simek 
>> Cc: Patrice Chotard 
>> Cc: Patrick Delaunay 
>> Cc: Pratyush Yadav 
>> Cc: Quentin Schulz 
>> Cc: Sean Anderson 
>> Cc: Simon Glass 
>> Cc: Takahiro Kuwano 
>> Cc: Tom Rini 
>> Cc: Tudor Ambarus 
>> Cc: Venkatesh Yadav Abbarapu 
>> Cc: u-boot@lists.denx.de
>> Cc: uboot-st...@st-md-mailman.stormreply.com
>> ---
> 
> Is this patch-set next version for 'previous' reverted series?
> 

my 2c: I think I lean towards reverting the stacked/parallel support.
The only one that benefits of is AMD, while affecting the core code
quality. It also slows down further contributions and I assume it
hardens maintainer's job.

Even if I (we?) haven't made my mind on how to best implement this, it's
clear that it shall be above SPI NOR without affecting current devices.

Not sure if it's fine to revert everything, haven't followed u-boot
lately, your choice to make.

Cheers,
ta

[PATCH] MAINTAINERS: add tambarus as reviewer for SPI NOR

[Tudor Ambarus]

I'd like to get Cc'ed to u-boot's SPI NOR patches to help review them.
The ultimate goal is to have an aligned approach in u-boot and linux.

Signed-off-by: Tudor Ambarus 
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 38c714cf46..df046192ea 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1604,6 +1604,7 @@ F:drivers/mtd/nand/spi/
 SPI-NOR
 M: Jagan Teki 
 M: Vignesh R 
+R: Tudor Ambarus 
 S: Maintained
 F: drivers/mtd/spi/
 F: include/spi_flash.h
-- 
2.47.0.199.ga7371fff76-goog

Re: [PATCH] MAINTAINERS: add tambarus as reviewer for SPI NOR

[Fabio Estevam]

Hi Tudor,

On Wed, Oct 30, 2024 at 10:18 AM Tudor Ambarus  wrote:
>
> I'd like to get Cc'ed to u-boot's SPI NOR patches to help review them.
> The ultimate goal is to have an aligned approach in u-boot and linux.
>
> Signed-off-by: Tudor Ambarus 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 38c714cf46..df046192ea 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1604,6 +1604,7 @@ F:drivers/mtd/nand/spi/
>  SPI-NOR
>  M: Jagan Teki 
>  M: Vignesh R 
> +R: Tudor Ambarus 

Your help is appreciated, thanks:

Reviewed-by: Fabio Estevam 

Re: [PATCH 1/9] mtd: spi-nor: Remove recently added nor->addr_width == 3 test

[Marek Vasut]

On 10/30/24 11:33 AM, Jagan Teki wrote:

Hi Marek,


Hi,


On Sun, Oct 27, 2024 at 1:48 AM Marek Vasut
 wrote:


Remove undocumented nor->addr_width == 3 test. This was added in commit
5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
without any explanation in the commit message. Remove it.

This also has a bad side-effect which breaks READ operation of every SPI NOR
which does not use addr_width == 3, e.g. s25fs512s does not work at all. This
is because if addr_width != 3, rem_bank_len is always 0, and if rem_bank_len
is 0, then read_len is 0 and if read_len is 0, then the spi_nor_read() returns
-EIO.

Basic reproducer is as follows:
"
=> sf probe ; sf read 0x5000 0 0x1
SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB, total 64 
MiB
device 0 offset 0x0, size 0x1
SF: 65536 bytes @ 0x0 Read: ERROR -5
"

Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut 
---
Cc: Andre Przywara 
Cc: Ashok Reddy Soma 
Cc: Jagan Teki 
Cc: Michael Walle 
Cc: Michal Simek 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Pratyush Yadav 
Cc: Quentin Schulz 
Cc: Sean Anderson 
Cc: Simon Glass 
Cc: Takahiro Kuwano 
Cc: Tom Rini 
Cc: Tudor Ambarus 
Cc: Venkatesh Yadav Abbarapu 
Cc: u-boot@lists.denx.de
Cc: uboot-st...@st-md-mailman.stormreply.com
---


Is this patch-set next version for 'previous' reverted series?
Yes, this is trying to fix the issues introduced by the stacked/parallel 
stuff in a less blunt manner than full revert.


Input from Tudor is probably more useful, since they do work on the 
kernel SPI NOR stuff and have better idea where that is going /wrt the 
stacked/parallel stuff too.

Re: [PATCH] MAINTAINERS: add tambarus as reviewer for SPI NOR

[Marek Vasut]

On 10/30/24 12:02 PM, Tudor Ambarus wrote:

I'd like to get Cc'ed to u-boot's SPI NOR patches to help review them.
The ultimate goal is to have an aligned approach in u-boot and linux.

Signed-off-by: Tudor Ambarus 

Acked-by: Marek Vasut 

Thanks !

Re: [PATCH v9 02/11] efi_loader: Add a test app

[Tom Rini]

On Wed, Oct 30, 2024 at 08:44:04AM +0100, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 29 Oct 2024 at 21:13, Tom Rini  wrote:
> >
> > On Tue, Oct 29, 2024 at 08:22:10PM +0100, Simon Glass wrote:
> >
> > > Add a simple app to use for testing. This is intended to do whatever it
> > > needs to for testing purposes. For now it just prints a message and
> > > exits boot services.
> > >
> > > There was a considerable amount of discussion about whether it is OK to
> > > call exit-boot-services and then return to U-Boot. This is not normally
> > > done in a real application, since exit-boot-services is used to
> > > completely disconnect from U-Boot. However, since this is a test, we
> > > need to check the results of running the app, so returning is necessary.
> > > It works correctly and it provides a nice model of how to test the EFI
> > > code in a simple way.
> > >
> > > Signed-off-by: Simon Glass 
> >
> > This approach has been specifically rejected with an explained
> > rationale: It breaks how UEFI applications work and you cannot run
> > further UEFI tests in sandbox without resetting.
> >
> > Since as you note, you can't reset in a C-based test, rework this to be
> > a python test where we can safely reset the system and verify that. I
> > believe Heinrich even noted that a test which checks ExitBootServices()
> > working as expected would be helpful as we only have a watchdog test
> > currently.
> 
> Unfortunately I believe this is the wrong direction, as we are unable
> to check the state of anything once a reset has happened. Thus I
> cannot build on this test, e.g. to see what happened to the devices
> and whether they are still bound. It becomes just a 'black box' test.
> None of the other bootflow tests work this way, BTW.

That's unfortunate in a number of ways then really. It's good when we
can test the state machine is still where we expect it. It's better when
we can test that the functionality works for real. It would probably be
generically useful to have some verification functions that can dump the
state of DM before we finish ourselves up and hand things over to the
OS. We could even make use of this in test/py/tests/test_net_boot.py
when we're booting Linux to make sure it's working as expected.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH] lib: efi_loader: Fix efi_dp_from_mem() call

[Ilias Apalodimas]

Hi Moritz

Thanks for the patch

On Wed, 30 Oct 2024 at 22:16, Moritz Fischer  wrote:
>
> The function expects an end address but is being called with
> an size instead.
>
> Fixes: 6422820ac3 ("efi_loader: split unrelated code from efi_bootmgr.c")
> Signed-off-by: Moritz Fischer 
> ---
>  lib/efi_loader/efi_bootbin.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
> index a87006b3c0..798bcd6eee 100644
> --- a/lib/efi_loader/efi_bootbin.c
> +++ b/lib/efi_loader/efi_bootbin.c
> @@ -137,7 +137,8 @@ efi_status_t efi_run_image(void *source_buffer, 
> efi_uintn_t source_size)
>  */
> file_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
> (uintptr_t)source_buffer,
> -   source_size);
> +   (uintptr_t)source_buffer +
> +   (size_t)source_size);

Yes, the change is correct, but we don't need the cast.

With that changed
Reviewed-by: Ilias Apalodimas 


> /*
>  * Make sure that device for device_path exist
>  * in load_image(). Otherwise, shell and grub will fail.
> --
> 2.47.0.163.g1226f6d8fa-goog
>

Re: [PATCH] lib: efi_loader: Fix efi_dp_from_mem() call

[Heinrich Schuchardt]

On 10/30/24 21:16, Moritz Fischer wrote:

The function expects an end address but is being called with
an size instead.

Fixes: 6422820ac3 ("efi_loader: split unrelated code from efi_bootmgr.c")
Signed-off-by: Moritz Fischer 
---
  lib/efi_loader/efi_bootbin.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
index a87006b3c0..798bcd6eee 100644
--- a/lib/efi_loader/efi_bootbin.c
+++ b/lib/efi_loader/efi_bootbin.c
@@ -137,7 +137,8 @@ efi_status_t efi_run_image(void *source_buffer, efi_uintn_t 
source_size)
 */
file_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
(uintptr_t)source_buffer,
-   source_size);
+   (uintptr_t)source_buffer +
+   (size_t)source_size);
/*
 * Make sure that device for device_path exist
 * in load_image(). Otherwise, shell and grub will fail.



The  efi_dp_from_mem() invocation in  efi_dp_from_name() seems also to
be affected.

Reviewed-by: Heinrich Schuchardt 

Re: [PATCH v9 02/11] efi_loader: Add a test app

[Heinrich Schuchardt]

On 10/29/24 20:22, Simon Glass wrote:

Add a simple app to use for testing. This is intended to do whatever it
needs to for testing purposes. For now it just prints a message and
exits boot services.

There was a considerable amount of discussion about whether it is OK to
call exit-boot-services and then return to U-Boot. This is not normally
done in a real application, since exit-boot-services is used to
completely disconnect from U-Boot. However, since this is a test, we
need to check the results of running the app, so returning is necessary.
It works correctly and it provides a nice model of how to test the EFI
code in a simple way.

Signed-off-by: Simon Glass 
---

Changes in v9:
- Update license
- Fix 'sevices' typo

Changes in v7:
- Update commit message

  lib/efi_loader/Kconfig   | 10 ++
  lib/efi_loader/Makefile  |  1 +
  lib/efi_loader/testapp.c | 68 
  3 files changed, 79 insertions(+)
  create mode 100644 lib/efi_loader/testapp.c

diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 37572c82f54..44319729bda 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -584,6 +584,16 @@ config BOOTEFI_HELLO_COMPILE
  No additional space will be required in the resulting U-Boot binary
  when this option is enabled.

+config BOOTEFI_TESTAPP_COMPILE
+   bool "Compile an EFI test app for testing"
+   default y
+   help
+ This compiles an app designed for testing. It is packed into an image
+ by the test.py testing frame in the setup_efi_image() function.
+
+ No additional space will be required in the resulting U-Boot binary
+ when this option is enabled.
+
  endif

  source "lib/efi/Kconfig"
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 8ec240cb864..7c8b2dd1ad6 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -20,6 +20,7 @@ apps-$(CONFIG_EFI_LOAD_FILE2_INITRD) += initrddump
  ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
  apps-y += dtbdump
  endif
+apps-$(CONFIG_BOOTEFI_TESTAPP_COMPILE) += testapp

  obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
  obj-$(CONFIG_EFI_BOOTMGR) += efi_bootmgr.o
diff --git a/lib/efi_loader/testapp.c b/lib/efi_loader/testapp.c
new file mode 100644
index 000..a28fc17ce5b
--- /dev/null
+++ b/lib/efi_loader/testapp.c
@@ -0,0 +1,68 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hello world EFI application
+ *
+ * Copyright 2024 Google LLC
+ * Written by Simon Glass 
+ *
+ * This test program is used to test the invocation of an EFI application.
+ * It writes a few messages to the console and then exits boot services
+ */
+
+#include 
+
+static const efi_guid_t loaded_image_guid = EFI_LOADED_IMAGE_PROTOCOL_GUID;
+
+static struct efi_system_table *systable;
+static struct efi_boot_services *boottime;
+static struct efi_simple_text_output_protocol *con_out;
+
+/**
+ * efi_main() - entry point of the EFI application.
+ *
+ * @handle:handle of the loaded image
+ * @systab:system table
+ * Return: status code
+ */
+efi_status_t EFIAPI efi_main(efi_handle_t handle,
+struct efi_system_table *systab)
+{
+   struct efi_loaded_image *loaded_image;
+   efi_status_t ret;
+   efi_uintn_t map_size;
+   efi_uintn_t map_key;
+   efi_uintn_t desc_size;
+   u32 desc_version;
+
+   systable = systab;
+   boottime = systable->boottime;
+   con_out = systable->con_out;
+
+   /* Get the loaded image protocol */
+   ret = boottime->open_protocol(handle, &loaded_image_guid,
+ (void **)&loaded_image, NULL, NULL,
+ EFI_OPEN_PROTOCOL_GET_PROTOCOL);
+   if (ret != EFI_SUCCESS) {
+   con_out->output_string
+   (con_out, u"Cannot open loaded image protocol\r\n");
+   goto out;
+   }
+
+   /* UEFI requires CR LF */
+   con_out->output_string(con_out, u"U-Boot test app for EFI_LOADER\r\n");
+
+out:
+   map_size = 0;
+   ret = boottime->get_memory_map(&map_size, NULL, &map_key, &desc_size,
+  &desc_version);
+   con_out->output_string(con_out, u"Exiting boot services\n");
+
+   /* exit boot services so that this part of U-Boot can be tested */
+   boottime->exit_boot_services(handle, map_key);


Hello Simon,

I am not NAKing this patch. But maybe you could rethink if this call
tells us anything new about the correct function of ExitBootServices().

We already have a test of ExitBootServices() in lib/efi_selftest/ and
maybe we should extend that test to check more.

By removing ExitBootServices() we could keep U-Boot in a well defined
state which will allow us to run any number of bootmeth tests in
sequence and keep the EFI sub-system in a consistent state.

Best regards

Heinrich



+
+   /* now exit for real */
+   ret = boottime->exit(handle, ret, 0,

Re: [PATCH v1 1/1] drivers: bootcount: Add ZynqMP specific bootcount support

[Vasileios Amoiridis]

On Wed, Oct 30, 2024 at 02:13:43PM +0100, Michal Simek wrote:
> 
> 
> On 10/29/24 19:58, Vasileios Amoiridis wrote:
> > From: Vasileios Amoiridis 
> > 
> > Add native support of the bootcount mechanism in the ZynqMP by utilising 
> > internal
> > PMU registers. The Persistent Global Storage Registers of the Platform 
> > Management
> > Unit can keep their value during reboot cycles unless there is a POR reset, 
> > making
> > them appropriate for the bootcount mechanism.
> > 
> > Signed-off-by: Vasileios Amoiridis 
> > ---
> >   drivers/bootcount/Kconfig|  4 
> >   drivers/bootcount/Makefile   |  1 +
> >   drivers/bootcount/bootcount_zynqmp.c | 28 
> >   3 files changed, 33 insertions(+)
> >   create mode 100644 drivers/bootcount/bootcount_zynqmp.c
> > 
> > diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
> > index fa6d8e7128..95b6a9541a 100644
> > --- a/drivers/bootcount/Kconfig
> > +++ b/drivers/bootcount/Kconfig
> > @@ -82,6 +82,10 @@ config BOOTCOUNT_AT91
> > bool "Boot counter for Atmel AT91SAM9XE"
> > depends on AT91SAM9XE
> > +config BOOTCOUNT_ZYNQMP
> > +   bool "Boot counter for Zynq UltraScale+ MPSoC"
> > +   depends on ARCH_ZYNQMP
> 
>
> help would help to also described where that count is stored.
> 

Hi Michal,

thanks for the review. Indeed I could add it.

> And why not to have it under DM/U_BOOT_DRIVER?
> You don't need to create compatible string for it just instantiate it.
> 
> Look at:
> 
> U_BOOT_DRVINFO(soc_xilinx_zynqmp) = {
>  .name = "soc_xilinx_zynqmp",
> };
> 

I was not fully aware of this, I could try it. Just out of curiosity, is
this the new/prefered way of adding new drivers?

> 
> > +
> >   config DM_BOOTCOUNT
> >   bool "Boot counter in a device-model device"
> > help
> > diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
> > index 245f879633..487adc1212 100644
> > --- a/drivers/bootcount/Makefile
> > +++ b/drivers/bootcount/Makefile
> > @@ -3,6 +3,7 @@
> >   obj-$(CONFIG_BOOTCOUNT_GENERIC)   += bootcount.o
> >   obj-$(CONFIG_BOOTCOUNT_MEM)   += bootcount.o
> >   obj-$(CONFIG_BOOTCOUNT_AT91)  += bootcount_at91.o
> > +obj-$(CONFIG_BOOTCOUNT_ZYNQMP)  += bootcount_zynqmp.o
> 
> please put it to the end of CONFIG_BOOTCOUNT to have it at least in correct 
> location
> 
> >   obj-$(CONFIG_BOOTCOUNT_AM33XX)+= bootcount_davinci.o
> >   obj-$(CONFIG_BOOTCOUNT_RAM)   += bootcount_ram.o
> >   obj-$(CONFIG_BOOTCOUNT_ENV)   += bootcount_env.o
> > diff --git a/drivers/bootcount/bootcount_zynqmp.c 
> > b/drivers/bootcount/bootcount_zynqmp.c
> > new file mode 100644
> > index 00..9bb801e188
> > --- /dev/null
> > +++ b/drivers/bootcount/bootcount_zynqmp.c
> > @@ -0,0 +1,28 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +// SPDX-FileCopyrightText: 2024 CERN (home.cern)
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define PMU_PERS_GLOB_GEN_STORAGE0 0x00FFD80050
> 
> In arch/arm/mach-zynqmp/include/mach/hardware.h
> there is already structure defined and gen_storage0 is there too.
> Please use it.
> 
> Regarding this location. Exception in PMUFW is using this reg.
> It means at the end of day it is up to you if you want to use it or not.
> 

In master branch (commit 5cca0e3f6e0ff17db92476235ea1bb9cd8cbc9eb) there
is no gen_storage0 in the structure pmu_regs, only gen_storage4 and
gen_storage6. 

But in any case though, I don't use gen_storage0 which is the
Global General Storage 0 but the Persistent Global General Storage 0
which is in the in the offset 0x50 and is defined in [1]. According to
this document, only registers {4:7} are used by FSBL and other Xilinx
software products so from what I understand registers {0:3} are free to
use. If that's not the case, which one of them is free for use?

[1]: 
https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/PERS_GLOB_GEN_STORAGE0-PMU_GLOBAL-Register

> > +
> > +void bootcount_store(ulong a)
> > +{
> > +   int ret;
> > +
> > +   ret = zynqmp_mmio_write(PMU_PERS_GLOB_GEN_STORAGE0, 0xFF, a);
> > +   if (ret)
> > +   printf("Failed: mmio write\n");
> > +}
> > +
> > +ulong bootcount_load(void)
> > +{
> > +   int ret;
> > +   u32 val;
> 
> as was said val should be initialized here too.
> 

Yes indeed.

> > +
> > +   ret = zynqmp_mmio_read(PMU_PERS_GLOB_GEN_STORAGE0, &val);
> > +   if (ret)
> > +   printf("Failed: mmio read\n");
> > +   return val;
> > +}
> 
> Anyway I expect this driver to be under DM that v2 will change.
> 
> Thanks,
> Michal
> 
> 
> 

Yes, I will try and come back to you in case I don't get something.
Thanks again for the review.

Cheers,
Vasilis

Re: [PATCH] scripts/dtc/pylibfdt/libfdt.i_shipped: Use SWIG_AppendOutput

[Tom Rini]

On Wed, Oct 30, 2024 at 06:07:16AM +0100, Markus Volk wrote:

> Swig has changed language specific AppendOutput functions. The helper
> macro SWIG_AppendOutput remains unchanged. Use that instead
> of SWIG_Python_AppendOutput, which would require an extra parameter
> since swig 4.3.0.
> 
> /home/flk/poky/build-test/tmp/work/qemux86_64-poky-linux/u-boot/2024.10/git/arch/x86/cpu/u-boot-64.lds
> | scripts/dtc/pylibfdt/libfdt_wrap.c: In function ‘_wrap_fdt_next_node’:
> | scripts/dtc/pylibfdt/libfdt_wrap.c:5581:17: error: too few arguments to 
> function ‘SWIG_Python_AppendOutput’
> |  5581 | resultobj = SWIG_Python_AppendOutput(resultobj, val);
> |   | ^~~~
> 
> Signed-off-by: Markus Volk 

Ah, I see this has been merged upstream now as well. Rudi posted the
same patch to U-Boot a bit sooner, but since you have the change merged
upstream I'll apply yours shortly and give Rudi a Reported-by tag on the
commit as well, to try and be fair. Thanks!

So that patchwork/b4/etc pick it up:
Reported-by: Rudi Heitbaum 
Link: https://github.com/dgibson/dtc/pull/154

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v8 5/8] sandbox: Report host default-filename in native mode

[Tom Rini]

On Wed, Oct 30, 2024 at 08:44:30AM +0100, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 29 Oct 2024 at 17:40, Tom Rini  wrote:
> >
> > On Tue, Oct 29, 2024 at 04:45:54PM +0100, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Mon, 28 Oct 2024 at 20:16, Heinrich Schuchardt  
> > > wrote:
> > > >
> > > > On 10/25/24 11:56, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > >
> > > > > On Tue, 22 Oct 2024 at 15:00, Simon Glass  wrote:
> > > > >>
> > > > >> When the --native flag is given, pretend to be running the host
> > > > >> architecture rather than sandbox.
> > > > >>
> > > > >> Add an 'efidebug filename' command to report it.
> > > > >
> > > > > Heinrich does this allow you to continue your testing in native archs?
> > > > >
> > > > >>
> > > > >> Signed-off-by: Simon Glass 
> > > > >> ---
> > > > >>
> > > > >> Changes in v8:
> > > > >> - Add new patch to report host default-filename in native mode
> > > > >>
> > > > >>   boot/bootmeth_efi.c | 25 ++--
> > > > >>   boot/efi_fname.c| 57 
> > > > >> +
> > > > >>   cmd/efidebug.c  | 25 
> > > > >>   include/efi.h   | 25 
> > > > >>   4 files changed, 94 insertions(+), 38 deletions(-)
> > > > >>
> > > > >> diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
> > > > >> index 371b36d550b..f836aa655f5 100644
> > > > >> --- a/boot/bootmeth_efi.c
> > > > >> +++ b/boot/bootmeth_efi.c
> > > > >> @@ -25,32 +25,11 @@
> > > > >>
> > > > >>   #define EFI_DIRNAME"/EFI/BOOT/"
> > > > >>
> > > > >> -static int get_efi_pxe_arch(void)
> > > > >> -{
> > > > >> -   /* 
> > > > >> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml
> > > > >>  */
> > > > >> -   if (IS_ENABLED(CONFIG_ARM64))
> > > > >> -   return 0xb;
> > > > >> -   else if (IS_ENABLED(CONFIG_ARM))
> > > > >> -   return 0xa;
> > > > >> -   else if (IS_ENABLED(CONFIG_X86_64))
> > > > >> -   return 0x6;
> > > > >> -   else if (IS_ENABLED(CONFIG_X86))
> > > > >> -   return 0x7;
> > > > >> -   else if (IS_ENABLED(CONFIG_ARCH_RV32I))
> > > > >> -   return 0x19;
> > > > >> -   else if (IS_ENABLED(CONFIG_ARCH_RV64I))
> > > > >> -   return 0x1b;
> > > > >> -   else if (IS_ENABLED(CONFIG_SANDBOX))
> > > > >> -   return 0;   /* not used */
> > > > >> -
> > > > >> -   return -EINVAL;
> > > > >> -}
> > > > >> -
> > > > >>   static int get_efi_pxe_vci(char *str, int max_len)
> > > > >>   {
> > > > >>  int ret;
> > > > >>
> > > > >> -   ret = get_efi_pxe_arch();
> > > > >> +   ret = efi_get_pxe_arch();
> > > > >>  if (ret < 0)
> > > > >>  return ret;
> > > > >>
> > > > >> @@ -239,7 +218,7 @@ static int distro_efi_read_bootflow_net(struct 
> > > > >> bootflow *bflow)
> > > > >>  ret = get_efi_pxe_vci(str, sizeof(str));
> > > > >>  if (ret)
> > > > >>  return log_msg_ret("vci", ret);
> > > > >> -   ret = get_efi_pxe_arch();
> > > > >> +   ret = efi_get_pxe_arch();
> > > > >>  if (ret < 0)
> > > > >>  return log_msg_ret("arc", ret);
> > > > >>  arch = ret;
> > > > >> diff --git a/boot/efi_fname.c b/boot/efi_fname.c
> > > > >> index a6b11383bba..790f9e2fa36 100644
> > > > >> --- a/boot/efi_fname.c
> > > > >> +++ b/boot/efi_fname.c
> > > > >> @@ -9,29 +9,34 @@
> > > > >>*/
> > > > >>
> > > > >>   #include 
> > > > >> +#include 
> > > > >>   #include 
> > > > >>
> > > > >> -#ifdef CONFIG_SANDBOX
> > > > >> -
> > > > >>   #if HOST_ARCH == HOST_ARCH_X86_64
> > > > >> -#define BOOTEFI_NAME "BOOTX64.EFI"
> > > > >> +#define HOST_BOOTEFI_NAME "BOOTX64.EFI"
> > > > >> +#define HOST_PXE_ARCH 0x6
> > > > >>   #elif HOST_ARCH == HOST_ARCH_X86
> > > > >> -#define BOOTEFI_NAME "BOOTIA32.EFI"
> > > > >> +#define HOST_BOOTEFI_NAME "BOOTIA32.EFI"
> > > > >> +#define HOST_PXE_ARCH 0x7
> > > > >>   #elif HOST_ARCH == HOST_ARCH_AARCH64
> > > > >> -#define BOOTEFI_NAME "BOOTAA64.EFI"
> > > > >> +#define HOST_BOOTEFI_NAME "BOOTAA64.EFI"
> > > > >> +#define HOST_PXE_ARCH 0xb
> > > > >>   #elif HOST_ARCH == HOST_ARCH_ARM
> > > > >> -#define BOOTEFI_NAME "BOOTARM.EFI"
> > > > >> +#define HOST_BOOTEFI_NAME "BOOTARM.EFI"
> > > > >> +#define HOST_PXE_ARCH 0xa
> > > > >>   #elif HOST_ARCH == HOST_ARCH_RISCV32
> > > > >> -#define BOOTEFI_NAME "BOOTRISCV32.EFI"
> > > > >> +#define HOST_BOOTEFI_NAME "BOOTRISCV32.EFI"
> > > > >> +#define HOST_PXE_ARCH 0x19
> > > > >>   #elif HOST_ARCH == HOST_ARCH_RISCV64
> > > > >> -#define BOOTEFI_NAME "BOOTRISCV64.EFI"
> > > > >> +#define HOST_BOOTEFI_NAME "BOOTRISCV64.EFI"
> > > > >> +#define HOST_PXE_ARCH 0x1b
> > > > >>   #else
> > > > >> -#error Unsupported UEFI architecture
> > > > >> +#error Unsupported Host architecture
> > > > >>   #endif
> > > > >>
> > > > >> -#else
> > > > >> -
> > > > >> -#if defined(CONFIG_ARM64)
> > > > >> +#if 

Re: [PATCH 1/9] mtd: spi-nor: Remove recently added nor->addr_width == 3 test

[Jagan Teki]

Hi Marek,

On Sun, Oct 27, 2024 at 1:48 AM Marek Vasut
 wrote:
>
> Remove undocumented nor->addr_width == 3 test. This was added in commit
> 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
> without any explanation in the commit message. Remove it.
>
> This also has a bad side-effect which breaks READ operation of every SPI NOR
> which does not use addr_width == 3, e.g. s25fs512s does not work at all. This
> is because if addr_width != 3, rem_bank_len is always 0, and if rem_bank_len
> is 0, then read_len is 0 and if read_len is 0, then the spi_nor_read() returns
> -EIO.
>
> Basic reproducer is as follows:
> "
> => sf probe ; sf read 0x5000 0 0x1
> SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB, total 64 
> MiB
> device 0 offset 0x0, size 0x1
> SF: 65536 bytes @ 0x0 Read: ERROR -5
> "
>
> Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories 
> support")
> Signed-off-by: Marek Vasut 
> ---
> Cc: Andre Przywara 
> Cc: Ashok Reddy Soma 
> Cc: Jagan Teki 
> Cc: Michael Walle 
> Cc: Michal Simek 
> Cc: Patrice Chotard 
> Cc: Patrick Delaunay 
> Cc: Pratyush Yadav 
> Cc: Quentin Schulz 
> Cc: Sean Anderson 
> Cc: Simon Glass 
> Cc: Takahiro Kuwano 
> Cc: Tom Rini 
> Cc: Tudor Ambarus 
> Cc: Venkatesh Yadav Abbarapu 
> Cc: u-boot@lists.denx.de
> Cc: uboot-st...@st-md-mailman.stormreply.com
> ---

Is this patch-set next version for 'previous' reverted series?

Jagan.

Re: [PATCH 1/9] mtd: spi-nor: Remove recently added nor->addr_width == 3 test

[Tom Rini]

On Wed, Oct 30, 2024 at 04:20:32PM +0100, Michal Simek wrote:
> 
> 
> On 10/30/24 15:49, Tudor Ambarus wrote:
> > 
> > 
> > On 10/30/24 2:17 PM, Jagan Teki wrote:
> > > On Wed, Oct 30, 2024 at 4:15 PM Tudor Ambarus  
> > > wrote:
> > > > 
> > > > 
> > > > 
> > > > On 10/30/24 10:33 AM, Jagan Teki wrote:
> > > > > Hi Marek,
> > > > > 
> > > > > On Sun, Oct 27, 2024 at 1:48 AM Marek Vasut
> > > > >  wrote:
> > > > > > 
> > > > > > Remove undocumented nor->addr_width == 3 test. This was added in 
> > > > > > commit
> > > > > > 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories 
> > > > > > support")
> > > > > > without any explanation in the commit message. Remove it.
> > > > > > 
> > > > > > This also has a bad side-effect which breaks READ operation of 
> > > > > > every SPI NOR
> > > > > > which does not use addr_width == 3, e.g. s25fs512s does not work at 
> > > > > > all. This
> > > > > > is because if addr_width != 3, rem_bank_len is always 0, and if 
> > > > > > rem_bank_len
> > > > > > is 0, then read_len is 0 and if read_len is 0, then the 
> > > > > > spi_nor_read() returns
> > > > > > -EIO.
> > > > > > 
> > > > > > Basic reproducer is as follows:
> > > > > > "
> > > > > > => sf probe ; sf read 0x5000 0 0x1
> > > > > > SF: Detected s25fs512s with page size 256 Bytes, erase size 256 
> > > > > > KiB, total 64 MiB
> > > > > > device 0 offset 0x0, size 0x1
> > > > > > SF: 65536 bytes @ 0x0 Read: ERROR -5
> > > > > > "
> > > > > > 
> > > > > > Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked 
> > > > > > memories support")
> > > > > > Signed-off-by: Marek Vasut 
> > > > > > ---
> > > > > > Cc: Andre Przywara 
> > > > > > Cc: Ashok Reddy Soma 
> > > > > > Cc: Jagan Teki 
> > > > > > Cc: Michael Walle 
> > > > > > Cc: Michal Simek 
> > > > > > Cc: Patrice Chotard 
> > > > > > Cc: Patrick Delaunay 
> > > > > > Cc: Pratyush Yadav 
> > > > > > Cc: Quentin Schulz 
> > > > > > Cc: Sean Anderson 
> > > > > > Cc: Simon Glass 
> > > > > > Cc: Takahiro Kuwano 
> > > > > > Cc: Tom Rini 
> > > > > > Cc: Tudor Ambarus 
> > > > > > Cc: Venkatesh Yadav Abbarapu 
> > > > > > Cc: u-boot@lists.denx.de
> > > > > > Cc: uboot-st...@st-md-mailman.stormreply.com
> > > > > > ---
> > > > > 
> > > > > Is this patch-set next version for 'previous' reverted series?
> > > > > 
> > > > 
> > > > my 2c: I think I lean towards reverting the stacked/parallel support.
> > > > The only one that benefits of is AMD, while affecting the core code
> > > > quality. It also slows down further contributions and I assume it
> > > > hardens maintainer's job.
> > > 
> > > I did try this before and it is hard to separate from the core. and at
> > > the same time it is hard to maintain the core too.
> > > 
> > > > 
> > > > Even if I (we?) haven't made my mind on how to best implement this, it's
> > > > clear that it shall be above SPI NOR without affecting current devices.
> > > > 
> > > > Not sure if it's fine to revert everything, haven't followed u-boot
> > > > lately, your choice to make.
> > > 
> > > If we find a way (not sure if it's possible) separate like a wrapper
> > > or fix the things without revert - these are two points I can see as
> > > of now.
> > > 
> > 
> > Then this set shall help move in this direction. Some involvement from
> > the stacked/parallel authors would be nice here, and some commitment
> > that the current status in just a temporary situation.
> 
> I hope that by authors you mean SW owners not really HW authors of this 
> wiring.
> Jagan is aware that we are using this configuration for quite a long time
> and we are still here and not leaving.
> As you know Amit is trying to find a solution in Linux but nothing has been
> agreed yet. If there is agreement to separate it to own driver or so we will
> be definitely working with u-boot to get it to the same state.
> 
> This patchset is using the latest approved DT binding created by Miquel and
> if new binding is accepted we will be working to align to it.
> Also intention is to bring this functionality to customers and not break
> others. That's why these patches are pulled into rc1 to get better test
> coverage.
> 
> And to be fair to say version which has been merged was v14 and anybody
> could comment it before and we are definitely here to help to resolve issues
> on other boards caused by this patchset. But we need to have help from
> others because obviously we don't have other boards and they are likely also
> not wired in CI.

To be clear, we need to resolve the problems that have shown up now on
all of the hardware that was working in v2024.10. My current inclination
is to merge
https://patchwork.ozlabs.org/project/uboot/list/?series=429932&state=*
(aka this series in question) ASAP.

-- 
Tom


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] dt-bindings: Drop unused RZ/G2L devicetree bindings

[Marek Vasut]

On 10/30/24 3:51 PM, Paul Barker wrote:

We are now using the dts/upstream subtree for the RZ/G2L SoC family so
we can drop unused dt-bindings headers.

Signed-off-by: Paul Barker 

Reviewed-by: Marek Vasut 

Re: [PATCH v2 1/2] ARM: dts: Drop unused RZ/G2L devicetrees

[Marek Vasut]

On 10/30/24 3:51 PM, Paul Barker wrote:

We are now using the dts/upstream subtree for the RZ/G2L SoC family so
we can drop unused devicetree files from arch/arm/dts.

Signed-off-by: Paul Barker 

Reviewed-by: Marek Vasut 

Re: [PATCH 1/2] rockchip: rk356x: Implement checkboard() to print SoC variant

[Jonas Karlman]

Hi Kever,

On 2024-10-30 07:40, Kever Yang wrote:
> Hi Jonas,
> 
> 
> On 2024/10/19 00:34, Jonas Karlman wrote:
>> Implement checkboard() to print current SoC model, e.g. one of:
>>
>>SoC:   RK3566 v1
>>SoC:   RK3566 v2
>>SoC:   RK3566T v2
>>SoC:   RK3568 v2
>>SoC:   RK3568B2 v2
>>SoC:   RK3568J v2
> 
> Did you get these types from different board, or is  there a document 
> for this?

These are the unique prints running the checkboard() on different rk356x
boards I have.

> 
> I didn't see this kind of document :(

I did not find this information in any document, this was mostly based
on patterns in observed OTP values sampled from different boards.

Information for cpu-code (3566 or 3568) and cpu-version (0, 1 or 2) was
picked from vendor 4.19/5.10/6.1 DTs from the OTP nvmem cells.

The cpu-version also seem to correspond to the second letter of the lot
number, e.g. 0x0 = xAxx yyww, 0x1 = xBxx yyww etc.

Information about the B, J and S variant seem to be consistent for both
rk356x and rk3588. Vendor 5.10/6.1 kernel driver for cpufreq/gpu/opp use
specification_serial_number nvmem cell to detect rk3588 M (0xd) and
J (0xa) variants.

The value seemed to correspond to 0x1 = A, 0x2 = B, ..., 0xa = J,
0xd = M, 0x13 = S, i.e. '@' +  = variant char in ascii table.

Information about the B2 or S2 revision seemed to correspond to the
package_serial_number nvmem cells on rk3588. Similar bits also seemed to
exist for rk356x even if there was no ref to package_serial_number in
any vendor DT for rk356x. E.g. on boards with B2 or S2 soc variants had
package_serial_number = 0x2, rest of my boards had a value of 0x1.

The T-variant of rk3566 did not seem to follow above pattern and it
instead use specification_serial_number = 0x1. A commit "arm64: dts:
rockchip: rk3568: adjust opp-table for rk356x-t" [1] instead pointed to
a performance nvmem cell.

For all my RK3566T boards that performance byte in OTP was 0x51, and if
I play with that value: 0x51 >> 2 = 0x14 => 'T'-variant ;-)

If you have any details and/or can confirm if some of my assumptions
above are correct or not correct that would be nice :-)

[1] 
https://github.com/radxa/kernel/commit/2dfd51da472e7ebb5ef0d3db78f902454af826b8

> 
> 
>>
>> when U-Boot proper is started.
>>
>> Information about what SoC model, variant and version is read from OTP.
>>
>> Signed-off-by: Jonas Karlman 
>> ---
>>   arch/arm/dts/rk356x-u-boot.dtsi|  4 ++
>>   arch/arm/mach-rockchip/rk3568/rk3568.c | 65 ++
>>   configs/generic-rk3568_defconfig   |  2 +-
> 
> Please split the driver change and config/dts change in different patch.

I will split in a v2 and look into reworking this as a sysinfo driver.

Regards,
Jonas

> 
> 
> Thanks,
> - Kever
>>   3 files changed, 70 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/dts/rk356x-u-boot.dtsi 
>> b/arch/arm/dts/rk356x-u-boot.dtsi
>> index 0a0943b462a9..24a976cf7e21 100644
>> --- a/arch/arm/dts/rk356x-u-boot.dtsi
>> +++ b/arch/arm/dts/rk356x-u-boot.dtsi
>> @@ -87,6 +87,10 @@
>>  bootph-all;
>>   };
>>   
>> +&otp {
>> +bootph-some-ram;
>> +};
>> +
>>   &pcfg_pull_none {
>>  bootph-all;
>>   };
>> diff --git a/arch/arm/mach-rockchip/rk3568/rk3568.c 
>> b/arch/arm/mach-rockchip/rk3568/rk3568.c
>> index 768a37393290..fc4c140ab970 100644
>> --- a/arch/arm/mach-rockchip/rk3568/rk3568.c
>> +++ b/arch/arm/mach-rockchip/rk3568/rk3568.c
>> @@ -4,6 +4,7 @@
>>*/
>>   
>>   #include 
>> +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -133,3 +134,67 @@ int arch_cpu_init(void)
>>   #endif
>>  return 0;
>>   }
>> +
>> +#define RK3568_OTP_CPU_CODE_OFFSET  0x02
>> +#define RK3568_OTP_SPECIFICATION_OFFSET 0x07
>> +#define RK3568_OTP_CPU_VERSION_OFFSET   0x08
>> +#define RK3568_OTP_PERFORMANCE_OFFSET   0x22
>> +
>> +int checkboard(void)
>> +{
>> +u8 cpu_code[2], specification, package, cpu_version, performance;
>> +struct udevice *dev;
>> +char suffix[3];
>> +int ret;
>> +
>> +ret = uclass_get_device_by_driver(UCLASS_MISC,
>> +  DM_DRIVER_GET(rockchip_otp), &dev);
>> +if (ret) {
>> +debug("%s: could not find otp device, ret=%d\n", __func__, ret);
>> +return 0;
>> +}
>> +
>> +/* cpu-code: SoC model, 0x35 0x66 or 0x35 0x68 */
>> +ret = misc_read(dev, RK3568_OTP_CPU_CODE_OFFSET, cpu_code, 2);
>> +if (ret < 0) {
>> +debug("%s: could not read cpu-code, ret=%d\n", __func__, ret);
>> +return 0;
>> +}
>> +
>> +/* specification: SoC variant, 0x2 for RK3568B2 and 0xA for RK3568J */
>> +ret = misc_read(dev, RK3568_OTP_SPECIFICATION_OFFSET, &specification, 
>> 1);
>> +if (ret < 0) {
>> +debug("%s: could not read specification, ret=%d\n", __func__, 
>> ret);
>> +return 0;
>> +}
>> +/* package: likely SoC variant revision, 0x2 for RK3568B2 */
>> +p

Re: [PATCH] MAINTAINERS: add tambarus as reviewer for SPI NOR

[Tom Rini]

On Wed, Oct 30, 2024 at 11:02:21AM +, Tudor Ambarus wrote:

> I'd like to get Cc'ed to u-boot's SPI NOR patches to help review them.
> The ultimate goal is to have an aligned approach in u-boot and linux.
> 
> Signed-off-by: Tudor Ambarus 

Many thanks for volunteering here!

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature

[PATCH 4/6] arm: dts: k3-am625-phycore-som-binman: Add SoM overlays

[Wadim Egorov]

Include SoM dt-overlays that handle variants of our SoMs into
u-boot's FIT image.

Signed-off-by: Wadim Egorov 
---
 arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 54 ++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k3-am625-phycore-som-binman.dtsi 
b/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
index 0961ca66f28..63f2eed7ccb 100644
--- a/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
+++ b/arch/arm/dts/k3-am625-phycore-som-binman.dtsi
@@ -301,6 +301,54 @@
description = "U-Boot for 
phyCORE-AM62x";
};
 
+   som-no-rtc {
+   description = 
"k3-am6xx-phycore-disable-rtc";
+   type = "flat_dt";
+   compression = "none";
+   load = <0x8F00>;
+   arch = "arm";
+
+   blob-ext {
+   filename = 
"dts/upstream/src/arm64/ti/k3-am6xx-phycore-disable-rtc.dtbo";
+   };
+   };
+
+   som-no-spi {
+   description = 
"k3-am6xx-phycore-disable-spi-nor";
+   type = "flat_dt";
+   compression = "none";
+   load = <0x8F001000>;
+   arch = "arm";
+
+   blob-ext {
+   filename = 
"dts/upstream/src/arm64/ti/k3-am6xx-phycore-disable-spi-nor.dtbo";
+   };
+   };
+
+   som-no-eth {
+   description = 
"k3-am6xx-phycore-disable-eth-phy";
+   type = "flat_dt";
+   compression = "none";
+   load = <0x8F002000>;
+   arch = "arm";
+
+   blob-ext {
+   filename = 
"dts/upstream/src/arm64/ti/k3-am6xx-phycore-disable-eth-phy.dtbo";
+   };
+   };
+
+   som-qspi {
+   description = 
"k3-am6xx-phycore-qspi-nor";
+   type = "flat_dt";
+   compression = "none";
+   load = <0x8F003000>;
+   arch = "arm";
+
+   blob-ext {
+   filename = 
"dts/upstream/src/arm64/ti/k3-am6xx-phycore-qspi-nor.dtbo";
+   };
+   };
+
fdt-0 {
description = 
"k3-am625-phyboard-lyra-rdk";
type = "flat_dt";
@@ -325,7 +373,11 @@
conf-0 {
description = 
"k3-am625-phyboard-lyra-rdk";
firmware = "uboot";
-   loadables = "uboot";
+   loadables = "uboot",
+   "som-no-rtc",
+   "som-no-spi",
+   "som-no-eth",
+   "som-qspi";
fdt = "fdt-0";
};
};
-- 
2.34.1

[PATCH 2/6] configs: phycore_am64x_a53_defconfig: Add SoM overlays to OF_OVERLAY_LIST

[Wadim Egorov]

Include SoM dt-overlays for DT control so we can include them
into our u-boot FIT image.
While at it also resync after savedefconfig.

Signed-off-by: Wadim Egorov 
---
 configs/phycore_am64x_a53_defconfig | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configs/phycore_am64x_a53_defconfig 
b/configs/phycore_am64x_a53_defconfig
index 662fc708d0d..3db18d88c85 100644
--- a/configs/phycore_am64x_a53_defconfig
+++ b/configs/phycore_am64x_a53_defconfig
@@ -17,13 +17,13 @@ CONFIG_ENV_OFFSET=0x68
 CONFIG_DM_GPIO=y
 CONFIG_SPL_DM_SPI=y
 CONFIG_DEFAULT_DEVICE_TREE="ti/k3-am642-phyboard-electra-rdk"
-CONFIG_SPL_TEXT_BASE=0x8008
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_DM_RESET=y
 CONFIG_SPL_MMC=y
 CONFIG_SPL_SERIAL=y
 CONFIG_SPL_DRIVERS_MISC=y
 CONFIG_SPL_STACK_R_ADDR=0x8200
+CONFIG_SPL_TEXT_BASE=0x8008
 CONFIG_SPL_HAS_BSS_LINKER_SECTION=y
 CONFIG_SPL_BSS_START_ADDR=0x80a0
 CONFIG_SPL_BSS_MAX_SIZE=0x8
@@ -77,6 +77,7 @@ CONFIG_CMD_TIME=y
 CONFIG_CMD_SMC=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_OVERLAY_LIST="ti/k3-am6xx-phycore-disable-spi-nor 
ti/k3-am6xx-phycore-disable-rtc ti/k3-am6xx-phycore-disable-eth-phy 
ti/k3-am6xx-phycore-qspi-nor"
 CONFIG_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
-- 
2.34.1

Re: [PATCH] gpio: qcom_pmic: add again the quirk to skip GPIO configuration on PM8550

[Neil Armstrong]

Hi Caleb,

On 16/10/2024 11:16, Neil Armstrong wrote:

The qcom_pmic code is broken for new PMICs and should be fixed,
without the QUIRK the code is broken and the GPIOs don't work
anymore on SM8550 and SM8650 platforms.

Partially revert the revert and only add the quirk on the PM8550
PMIC, making the buttons and MMC detect gpio work again.

Signed-off-by: Neil Armstrong 
---
  drivers/gpio/qcom_pmic_gpio.c | 21 +++--
  1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/qcom_pmic_gpio.c b/drivers/gpio/qcom_pmic_gpio.c
index f2ef4e5ce14..cd9f3926ac4 100644
--- a/drivers/gpio/qcom_pmic_gpio.c
+++ b/drivers/gpio/qcom_pmic_gpio.c
@@ -69,6 +69,17 @@
  #define REG_EN_CTL 0x46
  #define REG_EN_CTL_ENABLE  (1 << 7)
  
+/**

+ * pmic_gpio_match_data - platform specific configuration
+ *
+ * @PMIC_MATCH_READONLY: treat all GPIOs as readonly, don't attempt to 
configure them.
+ * This is a workaround for an unknown bug on some platforms where trying to 
write the
+ * GPIO configuration registers causes the board to hang.
+ */
+enum pmic_gpio_quirks {
+   QCOM_PMIC_QUIRK_READONLY = (1 << 0),
+};
+
  struct qcom_pmic_gpio_data {
uint32_t pid; /* Peripheral ID on SPMI bus */
bool lv_mv_type; /* If subtype is GPIO_LV(0x10) or GPIO_MV(0x11) */
@@ -117,8 +128,13 @@ static int qcom_gpio_set_direction(struct udevice *dev, 
unsigned int offset,
  {
struct qcom_pmic_gpio_data *plat = dev_get_plat(dev);
uint32_t gpio_base = plat->pid + REG_OFFSET(offset);
+   ulong quirks = dev_get_driver_data(dev);
int ret = 0;
  
+	/* Some PMICs don't like their GPIOs being configured */

+   if (quirks & QCOM_PMIC_QUIRK_READONLY)
+   return 0;
+
/* Disable the GPIO */
ret = pmic_clrsetbits(dev->parent, gpio_base + REG_EN_CTL,
  REG_EN_CTL_ENABLE, 0);
@@ -262,6 +278,7 @@ static int qcom_gpio_bind(struct udevice *dev)
  {


Gentle ping, without this PMICs gpio are unusable...

Neil
  
  	struct qcom_pmic_gpio_data *plat = dev_get_plat(dev);

+   ulong quirks = dev_get_driver_data(dev);
struct udevice *child;
struct driver *drv;
int ret;
@@ -275,7 +292,7 @@ static int qcom_gpio_bind(struct udevice *dev)
/* Bind the GPIO driver as a child of the PMIC. */
ret = device_bind_with_driver_data(dev, drv,
   dev->name,
-  0, dev_ofnode(dev), &child);
+  quirks, dev_ofnode(dev), &child);
if (ret)
return log_msg_ret("bind", ret);
  
@@ -348,7 +365,7 @@ static const struct udevice_id qcom_gpio_ids[] = {

{ .compatible = "qcom,pms405-gpio" },
{ .compatible = "qcom,pm6125-gpio" },
{ .compatible = "qcom,pm8150-gpio" },
-   { .compatible = "qcom,pm8550-gpio" },
+   { .compatible = "qcom,pm8550-gpio", .data = QCOM_PMIC_QUIRK_READONLY },
{ }
  };
  


---
base-commit: d5cab0d6adc26ec1bbd45c2fed101184d04454ae
change-id: 20241016-topic-sm8x50-qcom-pmic-re-add-quirk-75b24dd86849

Best regards,

[PATCH 3/6] configs: phycore_am64x_a53_defconfig: Enable PHYTEC_SOM_DETECTION

[Wadim Egorov]

Enable CONFIG_PHYTEC_SOM_DETECTION to apply SoM overlays
based on EEPROM configuration.

Signed-off-by: Wadim Egorov 
---
 configs/phycore_am64x_a53_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/phycore_am64x_a53_defconfig 
b/configs/phycore_am64x_a53_defconfig
index 3db18d88c85..ac9731d9674 100644
--- a/configs/phycore_am64x_a53_defconfig
+++ b/configs/phycore_am64x_a53_defconfig
@@ -10,6 +10,7 @@ CONFIG_NR_DRAM_BANKS=2
 CONFIG_SOC_K3_AM642=y
 CONFIG_K3_ATF_LOAD_ADDR=0x701c
 CONFIG_TARGET_PHYCORE_AM64X_A53=y
+CONFIG_PHYTEC_SOM_DETECTION=y
 CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
 CONFIG_CUSTOM_SYS_INIT_SP_ADDR=0x8048
 CONFIG_ENV_SIZE=0x2
-- 
2.34.1

Re: [PATCH v1 1/1] drivers: bootcount: Add ZynqMP specific bootcount support

[Michal Simek]

On 10/30/24 15:38, Vasileios Amoiridis wrote:

On Wed, Oct 30, 2024 at 02:13:43PM +0100, Michal Simek wrote:



On 10/29/24 19:58, Vasileios Amoiridis wrote:

From: Vasileios Amoiridis 

Add native support of the bootcount mechanism in the ZynqMP by utilising 
internal
PMU registers. The Persistent Global Storage Registers of the Platform 
Management
Unit can keep their value during reboot cycles unless there is a POR reset, 
making
them appropriate for the bootcount mechanism.

Signed-off-by: Vasileios Amoiridis 
---
   drivers/bootcount/Kconfig|  4 
   drivers/bootcount/Makefile   |  1 +
   drivers/bootcount/bootcount_zynqmp.c | 28 
   3 files changed, 33 insertions(+)
   create mode 100644 drivers/bootcount/bootcount_zynqmp.c

diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
index fa6d8e7128..95b6a9541a 100644
--- a/drivers/bootcount/Kconfig
+++ b/drivers/bootcount/Kconfig
@@ -82,6 +82,10 @@ config BOOTCOUNT_AT91
bool "Boot counter for Atmel AT91SAM9XE"
depends on AT91SAM9XE
+config BOOTCOUNT_ZYNQMP
+   bool "Boot counter for Zynq UltraScale+ MPSoC"
+   depends on ARCH_ZYNQMP



help would help to also described where that count is stored.



Hi Michal,

thanks for the review. Indeed I could add it.


And why not to have it under DM/U_BOOT_DRIVER?
You don't need to create compatible string for it just instantiate it.

Look at:

U_BOOT_DRVINFO(soc_xilinx_zynqmp) = {
  .name = "soc_xilinx_zynqmp",
};



I was not fully aware of this, I could try it. Just out of curiosity, is
this the new/prefered way of adding new drivers?




+
   config DM_BOOTCOUNT
   bool "Boot counter in a device-model device"
help
diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
index 245f879633..487adc1212 100644
--- a/drivers/bootcount/Makefile
+++ b/drivers/bootcount/Makefile
@@ -3,6 +3,7 @@
   obj-$(CONFIG_BOOTCOUNT_GENERIC)  += bootcount.o
   obj-$(CONFIG_BOOTCOUNT_MEM)  += bootcount.o
   obj-$(CONFIG_BOOTCOUNT_AT91) += bootcount_at91.o
+obj-$(CONFIG_BOOTCOUNT_ZYNQMP)  += bootcount_zynqmp.o


please put it to the end of CONFIG_BOOTCOUNT to have it at least in correct 
location


   obj-$(CONFIG_BOOTCOUNT_AM33XX)   += bootcount_davinci.o
   obj-$(CONFIG_BOOTCOUNT_RAM)  += bootcount_ram.o
   obj-$(CONFIG_BOOTCOUNT_ENV)  += bootcount_env.o
diff --git a/drivers/bootcount/bootcount_zynqmp.c 
b/drivers/bootcount/bootcount_zynqmp.c
new file mode 100644
index 00..9bb801e188
--- /dev/null
+++ b/drivers/bootcount/bootcount_zynqmp.c
@@ -0,0 +1,28 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+// SPDX-FileCopyrightText: 2024 CERN (home.cern)
+
+#include 
+#include 
+#include 
+
+#define PMU_PERS_GLOB_GEN_STORAGE0 0x00FFD80050


In arch/arm/mach-zynqmp/include/mach/hardware.h
there is already structure defined and gen_storage0 is there too.
Please use it.

Regarding this location. Exception in PMUFW is using this reg.
It means at the end of day it is up to you if you want to use it or not.



In master branch (commit 5cca0e3f6e0ff17db92476235ea1bb9cd8cbc9eb) there
is no gen_storage0 in the structure pmu_regs, only gen_storage4 and
gen_storage6.


you are right but easy to extend that structure to have it there.



But in any case though, I don't use gen_storage0 which is the
Global General Storage 0 but the Persistent Global General Storage 0
which is in the in the offset 0x50 and is defined in [1]. According to
this document, only registers {4:7} are used by FSBL and other Xilinx
software products so from what I understand registers {0:3} are free to
use. If that's not the case, which one of them is free for use?

[1]: 
https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/PERS_GLOB_GEN_STORAGE0-PMU_GLOBAL-Register


in embedded sw you can find this
lib/sw_apps/zynqmp_pmufw/src/xpfw_start.S:77:   addik   r3, r0, 
0xffd80050
lib/sw_apps/zynqmp_pmufw/src/xpfw_start.S:81:   addik   r3, r0, 
0xffd80054


And there are 2 pages which describe their usage

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841724/PMU+Firmware#PMUFirmware-RegistersreservedforPMUFirmware

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842019/Zynq+UltraScale+FSBL#ZynqUltraScale+FSBL-WhatarethememoryregionsandregistersreservedforFSBL?

But as I said I am fine if you choose one and you will use it for bootcount.

Thanks
M

[PATCH] bios_emulator: define the comment symbol for RISC-V assembler too

[Yuri Zaporozhets]

The bios_emulator driver cannot be compiled for RISC-V because the x86emu.h
header file doesn't define the comment symbol ("#") for the assembler.
With this patch, use the same symbol as for e.g. x86.

Signed-off-by: Yuri Zaporozhets 
---
 drivers/bios_emulator/include/x86emu.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bios_emulator/include/x86emu.h 
b/drivers/bios_emulator/include/x86emu.h
index d2650a8d16..cfdcd7b3e1 100644
--- a/drivers/bios_emulator/include/x86emu.h
+++ b/drivers/bios_emulator/include/x86emu.h
@@ -54,7 +54,7 @@ typedef u16 X86EMU_pioAddr;
 
 #if defined(CONFIG_ARM)
 #define GAS_LINE_COMMENT   "@"
-#elif defined(CONFIG_MIPS) || defined(CONFIG_PPC) || defined(CONFIG_X86)
+#elif defined(CONFIG_MIPS) || defined(CONFIG_PPC) || defined(CONFIG_X86) || 
defined(CONFIG_RISCV)
 #define GAS_LINE_COMMENT   "#"
 #elif defined (CONFIG_SH)
 #define GAS_LINE_COMMENT   "!"
-- 
2.39.5

Re: [PATCH 1/9] mtd: spi-nor: Remove recently added nor->addr_width == 3 test

[Michal Simek]

On 10/30/24 15:49, Tudor Ambarus wrote:



On 10/30/24 2:17 PM, Jagan Teki wrote:

On Wed, Oct 30, 2024 at 4:15 PM Tudor Ambarus  wrote:




On 10/30/24 10:33 AM, Jagan Teki wrote:

Hi Marek,

On Sun, Oct 27, 2024 at 1:48 AM Marek Vasut
 wrote:


Remove undocumented nor->addr_width == 3 test. This was added in commit
5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
without any explanation in the commit message. Remove it.

This also has a bad side-effect which breaks READ operation of every SPI NOR
which does not use addr_width == 3, e.g. s25fs512s does not work at all. This
is because if addr_width != 3, rem_bank_len is always 0, and if rem_bank_len
is 0, then read_len is 0 and if read_len is 0, then the spi_nor_read() returns
-EIO.

Basic reproducer is as follows:
"
=> sf probe ; sf read 0x5000 0 0x1
SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB, total 64 
MiB
device 0 offset 0x0, size 0x1
SF: 65536 bytes @ 0x0 Read: ERROR -5
"

Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
Signed-off-by: Marek Vasut 
---
Cc: Andre Przywara 
Cc: Ashok Reddy Soma 
Cc: Jagan Teki 
Cc: Michael Walle 
Cc: Michal Simek 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
Cc: Pratyush Yadav 
Cc: Quentin Schulz 
Cc: Sean Anderson 
Cc: Simon Glass 
Cc: Takahiro Kuwano 
Cc: Tom Rini 
Cc: Tudor Ambarus 
Cc: Venkatesh Yadav Abbarapu 
Cc: u-boot@lists.denx.de
Cc: uboot-st...@st-md-mailman.stormreply.com
---


Is this patch-set next version for 'previous' reverted series?



my 2c: I think I lean towards reverting the stacked/parallel support.
The only one that benefits of is AMD, while affecting the core code
quality. It also slows down further contributions and I assume it
hardens maintainer's job.


I did try this before and it is hard to separate from the core. and at
the same time it is hard to maintain the core too.



Even if I (we?) haven't made my mind on how to best implement this, it's
clear that it shall be above SPI NOR without affecting current devices.

Not sure if it's fine to revert everything, haven't followed u-boot
lately, your choice to make.


If we find a way (not sure if it's possible) separate like a wrapper
or fix the things without revert - these are two points I can see as
of now.



Then this set shall help move in this direction. Some involvement from
the stacked/parallel authors would be nice here, and some commitment
that the current status in just a temporary situation.


I hope that by authors you mean SW owners not really HW authors of this wiring.
Jagan is aware that we are using this configuration for quite a long time and we 
are still here and not leaving.
As you know Amit is trying to find a solution in Linux but nothing has been 
agreed yet. If there is agreement to separate it to own driver or so we will be 
definitely working with u-boot to get it to the same state.


This patchset is using the latest approved DT binding created by Miquel and if 
new binding is accepted we will be working to align to it.
Also intention is to bring this functionality to customers and not break others. 
That's why these patches are pulled into rc1 to get better test coverage.


And to be fair to say version which has been merged was v14 and anybody could 
comment it before and we are definitely here to help to resolve issues on other 
boards caused by this patchset. But we need to have help from others because 
obviously we don't have other boards and they are likely also not wired in CI.


Thanks,
Michal

[PATCH 6/6] board: phytec: common: k3: Apply SoM-specific overlays to OS device tree

[Wadim Egorov]

Our SoMs are available in multiple configurations, managed via device
tree overlays. To determine the specific variant in use, we read the
EEPROM and apply the appropriate overlays during boot to the device tree
used by the OS.

Signed-off-by: Wadim Egorov 
---
 board/phytec/common/k3/board.c | 73 ++
 1 file changed, 73 insertions(+)

diff --git a/board/phytec/common/k3/board.c b/board/phytec/common/k3/board.c
index 3d7e090ccaa..346b2b6491a 100644
--- a/board/phytec/common/k3/board.c
+++ b/board/phytec/common/k3/board.c
@@ -6,7 +6,9 @@
 
 #include 
 #include 
+#include 
 #include 
+#include 
 #include 
 
 #include "../am6_som_detection.h"
@@ -97,8 +99,79 @@ int board_late_init(void)
 #endif
 
 #if IS_ENABLED(CONFIG_OF_LIBFDT) && IS_ENABLED(CONFIG_OF_BOARD_SETUP)
+static int fdt_apply_overlay_from_fit(const char *overlay_path, void *fdt)
+{
+   u64 loadaddr;
+   ofnode node;
+   int ret;
+
+   node = ofnode_path(overlay_path);
+   if (!ofnode_valid(node))
+   return -FDT_ERR_NOTFOUND;
+
+   ret = ofnode_read_u64(node, "load", &loadaddr);
+   if (ret)
+   return ret;
+
+   return fdt_overlay_apply_verbose(fdt, (void *)loadaddr);
+}
+
+static void fdt_apply_som_overlays(void *blob)
+{
+   void *fdt_copy;
+   u32 fdt_size;
+   struct phytec_eeprom_data data;
+   int err;
+
+   fdt_size = fdt_totalsize(blob);
+   fdt_copy = malloc(fdt_size);
+   if (!fdt_copy)
+   goto fixup_error;
+
+   memcpy(fdt_copy, blob, fdt_size);
+
+   err = phytec_eeprom_data_setup(&data, 0, EEPROM_ADDR);
+   if (err)
+   goto fixup_error;
+
+   if (phytec_get_am6_rtc(&data) == 0) {
+   err = fdt_apply_overlay_from_fit("/fit-images/som-no-rtc", 
fdt_copy);
+   if (err)
+   goto fixup_error;
+   }
+
+   if (phytec_get_am6_spi(&data) == PHYTEC_EEPROM_VALUE_X) {
+   err = fdt_apply_overlay_from_fit("/fit-images/som-no-spi", 
fdt_copy);
+   if (err)
+   goto fixup_error;
+   }
+
+   if (phytec_get_am6_eth(&data) == 0) {
+   err = fdt_apply_overlay_from_fit("/fit-images/som-no-eth", 
fdt_copy);
+   if (err)
+   goto fixup_error;
+   }
+
+   if (phytec_am6_is_qspi(&data)) {
+   err = fdt_apply_overlay_from_fit("/fit-images/som-qspi-nor", 
fdt_copy);
+   if (err)
+   goto fixup_error;
+   }
+
+   memcpy(blob, fdt_copy, fdt_size);
+
+cleanup:
+   free(fdt_copy);
+   return;
+
+fixup_error:
+   pr_err("Failed to apply SoM overlays\n");
+   goto cleanup;
+}
+
 int ft_board_setup(void *blob, struct bd_info *bd)
 {
+   fdt_apply_som_overlays(blob);
fdt_copy_fixed_partitions(blob);
 
return 0;
-- 
2.34.1

[PATCH 5/6] arm: dts: k3-am642-phycore-som-binman: Add SoM overlays

[Wadim Egorov]

Include SoM dt-overlays that handle variants of our SoMs into
u-boot's FIT image.

Signed-off-by: Wadim Egorov 
---
 arch/arm/dts/k3-am642-phycore-som-binman.dtsi | 54 ++-
 1 file changed, 53 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/k3-am642-phycore-som-binman.dtsi 
b/arch/arm/dts/k3-am642-phycore-som-binman.dtsi
index dd0967079b6..88d6c40e95c 100644
--- a/arch/arm/dts/k3-am642-phycore-som-binman.dtsi
+++ b/arch/arm/dts/k3-am642-phycore-som-binman.dtsi
@@ -344,6 +344,54 @@
description = "U-Boot for AM64 board";
};
 
+   som-no-rtc {
+   description = 
"k3-am6xx-phycore-disable-rtc";
+   type = "flat_dt";
+   compression = "none";
+   load = <0x8F00>;
+   arch = "arm";
+
+   blob-ext {
+   filename = 
"dts/upstream/src/arm64/ti/k3-am6xx-phycore-disable-rtc.dtbo";
+   };
+   };
+
+   som-no-spi {
+   description = 
"k3-am6xx-phycore-disable-spi-nor";
+   type = "flat_dt";
+   compression = "none";
+   load = <0x8F001000>;
+   arch = "arm";
+
+   blob-ext {
+   filename = 
"dts/upstream/src/arm64/ti/k3-am6xx-phycore-disable-spi-nor.dtbo";
+   };
+   };
+
+   som-no-eth {
+   description = 
"k3-am6xx-phycore-disable-eth-phy";
+   type = "flat_dt";
+   compression = "none";
+   load = <0x8F002000>;
+   arch = "arm";
+
+   blob-ext {
+   filename = 
"dts/upstream/src/arm64/ti/k3-am6xx-phycore-disable-eth-phy.dtbo";
+   };
+   };
+
+   som-qspi {
+   description = 
"k3-am6xx-phycore-qspi-nor";
+   type = "flat_dt";
+   compression = "none";
+   load = <0x8F003000>;
+   arch = "arm";
+
+   blob-ext {
+   filename = 
"dts/upstream/src/arm64/ti/k3-am6xx-phycore-qspi-nor.dtbo";
+   };
+   };
+
fdt-0 {
description = 
"k3-am642-phyboard-electra-rdk";
type = "flat_dt";
@@ -368,7 +416,11 @@
conf-0 {
description = 
"k3-am642-phyboard-electra-rdk";
firmware = "uboot";
-   loadables = "uboot";
+   loadables = "uboot",
+   "som-no-rtc",
+   "som-no-spi",
+   "som-no-eth",
+   "som-qspi";
fdt = "fdt-0";
};
};
-- 
2.34.1

[PATCH 0/6] Apply SoM overlays on phyCORE-AM6xx SoMs

[Wadim Egorov]

Our SoMs are available in multiple configurations, managed via device
tree overlays. To determine the specific variant in use, we read the
EEPROM and apply the appropriate overlays during boot to the device tree
used by the OS.

Apply overlays for phyCORE-AM62x and phyCORE-AM64x SoMs.
Future K3 SoMs will be able to reuse this logic and overlays.

Wadim Egorov (6):
  configs: phycore_am62x_a53_defconfig: Add SoM overlays to
OF_OVERLAY_LIST
  configs: phycore_am64x_a53_defconfig: Add SoM overlays to
OF_OVERLAY_LIST
  configs: phycore_am64x_a53_defconfig: Enable PHYTEC_SOM_DETECTION
  arm: dts: k3-am625-phycore-som-binman: Add SoM overlays
  arm: dts: k3-am642-phycore-som-binman: Add SoM overlays
  board: phytec: common: k3: Apply SoM-specific overlays to OS device
tree

 arch/arm/dts/k3-am625-phycore-som-binman.dtsi | 54 +-
 arch/arm/dts/k3-am642-phycore-som-binman.dtsi | 54 +-
 board/phytec/common/k3/board.c| 73 +++
 configs/phycore_am62x_a53_defconfig   |  1 +
 configs/phycore_am64x_a53_defconfig   |  4 +-
 5 files changed, 183 insertions(+), 3 deletions(-)

-- 
2.34.1

Re: [PATCH 1/9] mtd: spi-nor: Remove recently added nor->addr_width == 3 test

[Tudor Ambarus]

On 10/30/24 2:17 PM, Jagan Teki wrote:
> On Wed, Oct 30, 2024 at 4:15 PM Tudor Ambarus  
> wrote:
>>
>>
>>
>> On 10/30/24 10:33 AM, Jagan Teki wrote:
>>> Hi Marek,
>>>
>>> On Sun, Oct 27, 2024 at 1:48 AM Marek Vasut
>>>  wrote:

 Remove undocumented nor->addr_width == 3 test. This was added in commit
 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
 without any explanation in the commit message. Remove it.

 This also has a bad side-effect which breaks READ operation of every SPI 
 NOR
 which does not use addr_width == 3, e.g. s25fs512s does not work at all. 
 This
 is because if addr_width != 3, rem_bank_len is always 0, and if 
 rem_bank_len
 is 0, then read_len is 0 and if read_len is 0, then the spi_nor_read() 
 returns
 -EIO.

 Basic reproducer is as follows:
 "
 => sf probe ; sf read 0x5000 0 0x1
 SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB, total 
 64 MiB
 device 0 offset 0x0, size 0x1
 SF: 65536 bytes @ 0x0 Read: ERROR -5
 "

 Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories 
 support")
 Signed-off-by: Marek Vasut 
 ---
 Cc: Andre Przywara 
 Cc: Ashok Reddy Soma 
 Cc: Jagan Teki 
 Cc: Michael Walle 
 Cc: Michal Simek 
 Cc: Patrice Chotard 
 Cc: Patrick Delaunay 
 Cc: Pratyush Yadav 
 Cc: Quentin Schulz 
 Cc: Sean Anderson 
 Cc: Simon Glass 
 Cc: Takahiro Kuwano 
 Cc: Tom Rini 
 Cc: Tudor Ambarus 
 Cc: Venkatesh Yadav Abbarapu 
 Cc: u-boot@lists.denx.de
 Cc: uboot-st...@st-md-mailman.stormreply.com
 ---
>>>
>>> Is this patch-set next version for 'previous' reverted series?
>>>
>>
>> my 2c: I think I lean towards reverting the stacked/parallel support.
>> The only one that benefits of is AMD, while affecting the core code
>> quality. It also slows down further contributions and I assume it
>> hardens maintainer's job.
> 
> I did try this before and it is hard to separate from the core. and at
> the same time it is hard to maintain the core too.
> 
>>
>> Even if I (we?) haven't made my mind on how to best implement this, it's
>> clear that it shall be above SPI NOR without affecting current devices.
>>
>> Not sure if it's fine to revert everything, haven't followed u-boot
>> lately, your choice to make.
> 
> If we find a way (not sure if it's possible) separate like a wrapper
> or fix the things without revert - these are two points I can see as
> of now.
> 

Then this set shall help move in this direction. Some involvement from
the stacked/parallel authors would be nice here, and some commitment
that the current status in just a temporary situation.

All the stacked/parallel code shall be pulled out from SPI NOR
eventually. The design is treating 2 independent flashes as one.
Whatever ties them shall be above SPI NOR. In the meantime we all suffer
until that is achieved. I guess if things become unbearable we can't
remove everything later on, can we? Or maybe this ship has sailed
already, I don't know.

It's really your decision to make because you maintain this code. If
full revert is chosen, I can agree and ACK that. If we keep it and try
to sweeten everything a bit, then be it.

Cheers,
ta

Re: [PATCH v1 1/1] drivers: bootcount: Add ZynqMP specific bootcount support

[Vasileios Amoiridis]

On Wed, Oct 30, 2024 at 06:26:08AM +0100, Heiko Schocher wrote:
> Hello Vasileios,
> 
> On 29.10.24 19:58, Vasileios Amoiridis wrote:
> > From: Vasileios Amoiridis 
> > 
> > Add native support of the bootcount mechanism in the ZynqMP by utilising 
> > internal
> > PMU registers. The Persistent Global Storage Registers of the Platform 
> > Management
> > Unit can keep their value during reboot cycles unless there is a POR reset, 
> > making
> > them appropriate for the bootcount mechanism.
> > 
> > Signed-off-by: Vasileios Amoiridis 
> > ---
> >   drivers/bootcount/Kconfig|  4 
> >   drivers/bootcount/Makefile   |  1 +
> >   drivers/bootcount/bootcount_zynqmp.c | 28 
> >   3 files changed, 33 insertions(+)
> >   create mode 100644 drivers/bootcount/bootcount_zynqmp.c
> > 
> > diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
> > index fa6d8e7128..95b6a9541a 100644
> > --- a/drivers/bootcount/Kconfig
> > +++ b/drivers/bootcount/Kconfig
> > @@ -82,6 +82,10 @@ config BOOTCOUNT_AT91
> > bool "Boot counter for Atmel AT91SAM9XE"
> > depends on AT91SAM9XE
> > +config BOOTCOUNT_ZYNQMP
> > +   bool "Boot counter for Zynq UltraScale+ MPSoC"
> > +   depends on ARCH_ZYNQMP
> > +
> >   config DM_BOOTCOUNT
> >   bool "Boot counter in a device-model device"
> > help
> > diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
> > index 245f879633..487adc1212 100644
> > --- a/drivers/bootcount/Makefile
> > +++ b/drivers/bootcount/Makefile
> > @@ -3,6 +3,7 @@
> >   obj-$(CONFIG_BOOTCOUNT_GENERIC)   += bootcount.o
> >   obj-$(CONFIG_BOOTCOUNT_MEM)   += bootcount.o
> >   obj-$(CONFIG_BOOTCOUNT_AT91)  += bootcount_at91.o
> > +obj-$(CONFIG_BOOTCOUNT_ZYNQMP)  += bootcount_zynqmp.o
> >   obj-$(CONFIG_BOOTCOUNT_AM33XX)+= bootcount_davinci.o
> >   obj-$(CONFIG_BOOTCOUNT_RAM)   += bootcount_ram.o
> >   obj-$(CONFIG_BOOTCOUNT_ENV)   += bootcount_env.o
> > diff --git a/drivers/bootcount/bootcount_zynqmp.c 
> > b/drivers/bootcount/bootcount_zynqmp.c
> > new file mode 100644
> > index 00..9bb801e188
> > --- /dev/null
> > +++ b/drivers/bootcount/bootcount_zynqmp.c
> > @@ -0,0 +1,28 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +// SPDX-FileCopyrightText: 2024 CERN (home.cern)
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define PMU_PERS_GLOB_GEN_STORAGE0 0x00FFD80050
> > +
> > +void bootcount_store(ulong a)
> > +{
> > +   int ret;
> > +
> > +   ret = zynqmp_mmio_write(PMU_PERS_GLOB_GEN_STORAGE0, 0xFF, a);
> > +   if (ret)
> > +   printf("Failed: mmio write\n");
> > +}
> > +
> > +ulong bootcount_load(void)
> > +{
> > +   int ret;
> > +   u32 val;
> > +
> > +   ret = zynqmp_mmio_read(PMU_PERS_GLOB_GEN_STORAGE0, &val);
> > +   if (ret)
> > +   printf("Failed: mmio read\n");
> > +   return val;
> 
> Makes it sense to return val, when ret != 0 ? Maybe val is uninitialzed
> in this case... at least please return ret.

Hi Heiko,

I see your point. Initializing wouldn't hurt, and indeed I could return
the error value no problem!
> 
> 
> just Nitpick: Also may at least add the function name to the printf,
> that you have a chance to see on console output, that bootcount read
> gone wrong... may the zynqmp_mmio_write/read functions have already an
> error message on error?

Just by checking other usages of this function, indeed it would be
helpful to use function name and line number and then propagate the
error value all the way up.

Cheers,
Vasilis
> 
> Thanks!
> 
> bye,
> Heiko
> -- 
> DENX Software Engineering GmbH,  Managing Director: Erika Unter
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-52   Fax: +49-8142-66989-80   Email: h...@denx.de

env: ENV_WRITEABLE_LIST with ".flags" variable

[Zixun LI]

Hello,

I read the code about environment variable protection and an old
discussion: https://lists.denx.de/pipermail/u-boot/2021-April/446247.html
but I still have a question.

In env_flags_init() we have:
  if (first_call) {
#ifdef CONFIG_ENV_WRITEABLE_LIST
  flags_list = ENV_FLAGS_LIST_STATIC;
#else
  flags_list = env_get(ENV_FLAGS_VAR);
#endif
first_call = 0;
  }

When ENV_WRITEABLE_LIST is enabled, why do we have to initialize the list
with ENV_FLAGS_LIST_STATIC instead of ".flags" ? Doing so makes ".flags"
being ignored.

In env_flags_lookup() there is already a fallback when a flag is not
found, the static list will be checked.

Since default env is firstly loaded in env_load(), external ".flags" are
rejected and don't affect the security:
  change_ok() rejected setting variable .flags, skipping it!

Advantage of using .flags is being able to use a .env file to
group all variables together without modifying the included header.

Best regards,
Zixun

Re: [PATCH 1/9] mtd: spi-nor: Remove recently added nor->addr_width == 3 test

[Jagan Teki]

On Wed, Oct 30, 2024 at 4:15 PM Tudor Ambarus  wrote:
>
>
>
> On 10/30/24 10:33 AM, Jagan Teki wrote:
> > Hi Marek,
> >
> > On Sun, Oct 27, 2024 at 1:48 AM Marek Vasut
> >  wrote:
> >>
> >> Remove undocumented nor->addr_width == 3 test. This was added in commit
> >> 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories support")
> >> without any explanation in the commit message. Remove it.
> >>
> >> This also has a bad side-effect which breaks READ operation of every SPI 
> >> NOR
> >> which does not use addr_width == 3, e.g. s25fs512s does not work at all. 
> >> This
> >> is because if addr_width != 3, rem_bank_len is always 0, and if 
> >> rem_bank_len
> >> is 0, then read_len is 0 and if read_len is 0, then the spi_nor_read() 
> >> returns
> >> -EIO.
> >>
> >> Basic reproducer is as follows:
> >> "
> >> => sf probe ; sf read 0x5000 0 0x1
> >> SF: Detected s25fs512s with page size 256 Bytes, erase size 256 KiB, total 
> >> 64 MiB
> >> device 0 offset 0x0, size 0x1
> >> SF: 65536 bytes @ 0x0 Read: ERROR -5
> >> "
> >>
> >> Fixes: 5d40b3d384dc ("mtd: spi-nor: Add parallel and stacked memories 
> >> support")
> >> Signed-off-by: Marek Vasut 
> >> ---
> >> Cc: Andre Przywara 
> >> Cc: Ashok Reddy Soma 
> >> Cc: Jagan Teki 
> >> Cc: Michael Walle 
> >> Cc: Michal Simek 
> >> Cc: Patrice Chotard 
> >> Cc: Patrick Delaunay 
> >> Cc: Pratyush Yadav 
> >> Cc: Quentin Schulz 
> >> Cc: Sean Anderson 
> >> Cc: Simon Glass 
> >> Cc: Takahiro Kuwano 
> >> Cc: Tom Rini 
> >> Cc: Tudor Ambarus 
> >> Cc: Venkatesh Yadav Abbarapu 
> >> Cc: u-boot@lists.denx.de
> >> Cc: uboot-st...@st-md-mailman.stormreply.com
> >> ---
> >
> > Is this patch-set next version for 'previous' reverted series?
> >
>
> my 2c: I think I lean towards reverting the stacked/parallel support.
> The only one that benefits of is AMD, while affecting the core code
> quality. It also slows down further contributions and I assume it
> hardens maintainer's job.

I did try this before and it is hard to separate from the core. and at
the same time it is hard to maintain the core too.

>
> Even if I (we?) haven't made my mind on how to best implement this, it's
> clear that it shall be above SPI NOR without affecting current devices.
>
> Not sure if it's fine to revert everything, haven't followed u-boot
> lately, your choice to make.

If we find a way (not sure if it's possible) separate like a wrapper
or fix the things without revert - these are two points I can see as
of now.

Jagan.

Re: [PATCH v1 0/1] bootcount: zynqmp: Add bootcount API

[Vasileios Amoiridis]

On Tue, Oct 29, 2024 at 01:12:30PM -0600, Tom Rini wrote:
> On Tue, Oct 29, 2024 at 07:58:13PM +0100, Vasileios Amoiridis wrote:
> > From: Vasileios Amoiridis 
> > 
> > Add support for the bootcount API by utilizing the internal Persistent
> > Global General Registers of the PMU. These registers get reset whenever
> > there is a Power-On-Reset so it makes them suitable for the API.
> > 
> > Questions towards reviewers:
> > 
> > 1) Is the licensing of the file ok?
> 
> Yes.
> 
> > 2) How am I supposed to add a maintainer for this file?
> 
> This should be caught already under the zynqmp regex in the top-level
> MAINTAINERS file.
> 
> The code itself looks fine, but I'll leave it to Michal to further
> review.
> 
> -- 
> Tom

Hi Tom,

Thank you very much for the reply.

Cheers,
Vasilis

[PATCH 1/6] configs: phycore_am62x_a53_defconfig: Add SoM overlays to OF_OVERLAY_LIST

[Wadim Egorov]

Include SoM dt-overlays for DT control so we can include them
into our u-boot FIT image.

Signed-off-by: Wadim Egorov 
---
 configs/phycore_am62x_a53_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/phycore_am62x_a53_defconfig 
b/configs/phycore_am62x_a53_defconfig
index dfff58670a0..d4b5191af7d 100644
--- a/configs/phycore_am62x_a53_defconfig
+++ b/configs/phycore_am62x_a53_defconfig
@@ -72,6 +72,7 @@ CONFIG_CMD_SMC=y
 CONFIG_OF_CONTROL=y
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_MULTI_DTB_FIT=y
+CONFIG_OF_OVERLAY_LIST="ti/k3-am6xx-phycore-disable-spi-nor 
ti/k3-am6xx-phycore-disable-rtc ti/k3-am6xx-phycore-disable-eth-phy 
ti/k3-am6xx-phycore-qspi-nor"
 CONFIG_SPL_MULTI_DTB_FIT=y
 CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
 CONFIG_ENV_OVERWRITE=y
-- 
2.34.1

Re: [PATCH v9 02/11] efi_loader: Add a test app

[Ilias Apalodimas]

Hi Heinrich



On Wed, 30 Oct 2024 at 18:55, Heinrich Schuchardt  wrote:
>
> On 10/29/24 20:22, Simon Glass wrote:
> > Add a simple app to use for testing. This is intended to do whatever it
> > needs to for testing purposes. For now it just prints a message and
> > exits boot services.
> >
> > There was a considerable amount of discussion about whether it is OK to
> > call exit-boot-services and then return to U-Boot. This is not normally
> > done in a real application, since exit-boot-services is used to
> > completely disconnect from U-Boot. However, since this is a test, we
> > need to check the results of running the app, so returning is necessary.
> > It works correctly and it provides a nice model of how to test the EFI
> > code in a simple way.
> >
> > Signed-off-by: Simon Glass 
> > ---
> >
> > Changes in v9:
> > - Update license
> > - Fix 'sevices' typo
> >
> > Changes in v7:
> > - Update commit message
> >
> >   lib/efi_loader/Kconfig   | 10 ++
> >   lib/efi_loader/Makefile  |  1 +
> >   lib/efi_loader/testapp.c | 68 
> >   3 files changed, 79 insertions(+)
> >   create mode 100644 lib/efi_loader/testapp.c
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 37572c82f54..44319729bda 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -584,6 +584,16 @@ config BOOTEFI_HELLO_COMPILE
> > No additional space will be required in the resulting U-Boot binary
> > when this option is enabled.
> >
> > +config BOOTEFI_TESTAPP_COMPILE
> > + bool "Compile an EFI test app for testing"
> > + default y
> > + help
> > +   This compiles an app designed for testing. It is packed into an 
> > image
> > +   by the test.py testing frame in the setup_efi_image() function.
> > +
> > +   No additional space will be required in the resulting U-Boot binary
> > +   when this option is enabled.
> > +
> >   endif
> >
> >   source "lib/efi/Kconfig"
> > diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> > index 8ec240cb864..7c8b2dd1ad6 100644
> > --- a/lib/efi_loader/Makefile
> > +++ b/lib/efi_loader/Makefile
> > @@ -20,6 +20,7 @@ apps-$(CONFIG_EFI_LOAD_FILE2_INITRD) += initrddump
> >   ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
> >   apps-y += dtbdump
> >   endif
> > +apps-$(CONFIG_BOOTEFI_TESTAPP_COMPILE) += testapp
> >
> >   obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
> >   obj-$(CONFIG_EFI_BOOTMGR) += efi_bootmgr.o
> > diff --git a/lib/efi_loader/testapp.c b/lib/efi_loader/testapp.c
> > new file mode 100644
> > index 000..a28fc17ce5b
> > --- /dev/null
> > +++ b/lib/efi_loader/testapp.c
> > @@ -0,0 +1,68 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Hello world EFI application
> > + *
> > + * Copyright 2024 Google LLC
> > + * Written by Simon Glass 
> > + *
> > + * This test program is used to test the invocation of an EFI application.
> > + * It writes a few messages to the console and then exits boot services
> > + */
> > +
> > +#include 
> > +
> > +static const efi_guid_t loaded_image_guid = EFI_LOADED_IMAGE_PROTOCOL_GUID;
> > +
> > +static struct efi_system_table *systable;
> > +static struct efi_boot_services *boottime;
> > +static struct efi_simple_text_output_protocol *con_out;
> > +
> > +/**
> > + * efi_main() - entry point of the EFI application.
> > + *
> > + * @handle:  handle of the loaded image
> > + * @systab:  system table
> > + * Return:   status code
> > + */
> > +efi_status_t EFIAPI efi_main(efi_handle_t handle,
> > +  struct efi_system_table *systab)
> > +{
> > + struct efi_loaded_image *loaded_image;
> > + efi_status_t ret;
> > + efi_uintn_t map_size;
> > + efi_uintn_t map_key;
> > + efi_uintn_t desc_size;
> > + u32 desc_version;
> > +
> > + systable = systab;
> > + boottime = systable->boottime;
> > + con_out = systable->con_out;
> > +
> > + /* Get the loaded image protocol */
> > + ret = boottime->open_protocol(handle, &loaded_image_guid,
> > +   (void **)&loaded_image, NULL, NULL,
> > +   EFI_OPEN_PROTOCOL_GET_PROTOCOL);
> > + if (ret != EFI_SUCCESS) {
> > + con_out->output_string
> > + (con_out, u"Cannot open loaded image protocol\r\n");
> > + goto out;
> > + }
> > +
> > + /* UEFI requires CR LF */
> > + con_out->output_string(con_out, u"U-Boot test app for 
> > EFI_LOADER\r\n");
> > +
> > +out:
> > + map_size = 0;
> > + ret = boottime->get_memory_map(&map_size, NULL, &map_key, &desc_size,
> > +&desc_version);
> > + con_out->output_string(con_out, u"Exiting boot services\n");
> > +
> > + /* exit boot services so that this part of U-Boot can be tested */
> > + boottime->exit_boot_services(handle, map_key);
>
> Hello Simon,
>
> I am not NAKing this patch. But maybe you coul

Re: [PATCH v1 1/1] drivers: bootcount: Add ZynqMP specific bootcount support

[Vasileios Amoiridis]

On Wed, Oct 30, 2024 at 04:49:10PM +0100, Michal Simek wrote:
> 
> 
> On 10/30/24 15:38, Vasileios Amoiridis wrote:
> > On Wed, Oct 30, 2024 at 02:13:43PM +0100, Michal Simek wrote:
> > > 
> > > 
> > > On 10/29/24 19:58, Vasileios Amoiridis wrote:
> > > > From: Vasileios Amoiridis 
> > > > 
> > > > Add native support of the bootcount mechanism in the ZynqMP by 
> > > > utilising internal
> > > > PMU registers. The Persistent Global Storage Registers of the Platform 
> > > > Management
> > > > Unit can keep their value during reboot cycles unless there is a POR 
> > > > reset, making
> > > > them appropriate for the bootcount mechanism.
> > > > 
> > > > Signed-off-by: Vasileios Amoiridis 
> > > > ---
> > > >drivers/bootcount/Kconfig|  4 
> > > >drivers/bootcount/Makefile   |  1 +
> > > >drivers/bootcount/bootcount_zynqmp.c | 28 
> > > > 
> > > >3 files changed, 33 insertions(+)
> > > >create mode 100644 drivers/bootcount/bootcount_zynqmp.c
> > > > 
> > > > diff --git a/drivers/bootcount/Kconfig b/drivers/bootcount/Kconfig
> > > > index fa6d8e7128..95b6a9541a 100644
> > > > --- a/drivers/bootcount/Kconfig
> > > > +++ b/drivers/bootcount/Kconfig
> > > > @@ -82,6 +82,10 @@ config BOOTCOUNT_AT91
> > > > bool "Boot counter for Atmel AT91SAM9XE"
> > > > depends on AT91SAM9XE
> > > > +config BOOTCOUNT_ZYNQMP
> > > > +   bool "Boot counter for Zynq UltraScale+ MPSoC"
> > > > +   depends on ARCH_ZYNQMP
> > > 
> > > 
> > > help would help to also described where that count is stored.
> > > 
> > 
> > Hi Michal,
> > 
> > thanks for the review. Indeed I could add it.
> > 
> > > And why not to have it under DM/U_BOOT_DRIVER?
> > > You don't need to create compatible string for it just instantiate it.
> > > 
> > > Look at:
> > > 
> > > U_BOOT_DRVINFO(soc_xilinx_zynqmp) = {
> > >   .name = "soc_xilinx_zynqmp",
> > > };
> > > 
> > 
> > I was not fully aware of this, I could try it. Just out of curiosity, is
> > this the new/prefered way of adding new drivers?
> > 
> > > 
> > > > +
> > > >config DM_BOOTCOUNT
> > > >bool "Boot counter in a device-model device"
> > > > help
> > > > diff --git a/drivers/bootcount/Makefile b/drivers/bootcount/Makefile
> > > > index 245f879633..487adc1212 100644
> > > > --- a/drivers/bootcount/Makefile
> > > > +++ b/drivers/bootcount/Makefile
> > > > @@ -3,6 +3,7 @@
> > > >obj-$(CONFIG_BOOTCOUNT_GENERIC)  += bootcount.o
> > > >obj-$(CONFIG_BOOTCOUNT_MEM)  += bootcount.o
> > > >obj-$(CONFIG_BOOTCOUNT_AT91) += bootcount_at91.o
> > > > +obj-$(CONFIG_BOOTCOUNT_ZYNQMP)  += bootcount_zynqmp.o
> > > 
> > > please put it to the end of CONFIG_BOOTCOUNT to have it at least in 
> > > correct location
> > > 
> > > >obj-$(CONFIG_BOOTCOUNT_AM33XX)   += bootcount_davinci.o
> > > >obj-$(CONFIG_BOOTCOUNT_RAM)  += bootcount_ram.o
> > > >obj-$(CONFIG_BOOTCOUNT_ENV)  += bootcount_env.o
> > > > diff --git a/drivers/bootcount/bootcount_zynqmp.c 
> > > > b/drivers/bootcount/bootcount_zynqmp.c
> > > > new file mode 100644
> > > > index 00..9bb801e188
> > > > --- /dev/null
> > > > +++ b/drivers/bootcount/bootcount_zynqmp.c
> > > > @@ -0,0 +1,28 @@
> > > > +// SPDX-License-Identifier: GPL-2.0-or-later
> > > > +// SPDX-FileCopyrightText: 2024 CERN (home.cern)
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +#define PMU_PERS_GLOB_GEN_STORAGE0 0x00FFD80050
> > > 
> > > In arch/arm/mach-zynqmp/include/mach/hardware.h
> > > there is already structure defined and gen_storage0 is there too.
> > > Please use it.
> > > 
> > > Regarding this location. Exception in PMUFW is using this reg.
> > > It means at the end of day it is up to you if you want to use it or not.
> > > 
> > 
> > In master branch (commit 5cca0e3f6e0ff17db92476235ea1bb9cd8cbc9eb) there
> > is no gen_storage0 in the structure pmu_regs, only gen_storage4 and
> > gen_storage6.
> 
> you are right but easy to extend that structure to have it there.
> 
> > 
> > But in any case though, I don't use gen_storage0 which is the
> > Global General Storage 0 but the Persistent Global General Storage 0
> > which is in the in the offset 0x50 and is defined in [1]. According to
> > this document, only registers {4:7} are used by FSBL and other Xilinx
> > software products so from what I understand registers {0:3} are free to
> > use. If that's not the case, which one of them is free for use?
> > 
> > [1]: 
> > https://docs.amd.com/r/en-US/ug1087-zynq-ultrascale-registers/PERS_GLOB_GEN_STORAGE0-PMU_GLOBAL-Register
> 
> in embedded sw you can find this
> lib/sw_apps/zynqmp_pmufw/src/xpfw_start.S:77:   addik   r3, r0,
> 0xffd80050
> lib/sw_apps/zynqmp_pmufw/src/xpfw_start.S:81:   addik   r3, r0,
> 0xffd80054
> 
> And there are 2 pages which describe their usage
> 
> https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841724/PMU+Firmware#PMUFirmware-Regist

[PATCH] efi_loader: Make tcg2_uninit() static

[Ilias Apalodimas]

This function is only used locally, so make it static and quiesce
the W=1 warning

Signed-off-by: Ilias Apalodimas 
---
 lib/efi_loader/efi_tcg2.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 45f451ef6b6d..866a529857ef 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -789,7 +789,7 @@ static const struct efi_tcg2_protocol efi_tcg2_protocol = {
 /**
  * tcg2_uninit - remove the final event table and free efi memory on failures
  */
-void tcg2_uninit(void)
+static void tcg2_uninit(void)
 {
efi_status_t ret;
 
-- 
2.45.2

[PATCH] lib: efi_loader: Fix efi_dp_from_mem() call

[Moritz Fischer]

The function expects an end address but is being called with
an size instead.

Fixes: 6422820ac3 ("efi_loader: split unrelated code from efi_bootmgr.c")
Signed-off-by: Moritz Fischer 
---
 lib/efi_loader/efi_bootbin.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
index a87006b3c0..798bcd6eee 100644
--- a/lib/efi_loader/efi_bootbin.c
+++ b/lib/efi_loader/efi_bootbin.c
@@ -137,7 +137,8 @@ efi_status_t efi_run_image(void *source_buffer, efi_uintn_t 
source_size)
 */
file_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
(uintptr_t)source_buffer,
-   source_size);
+   (uintptr_t)source_buffer +
+   (size_t)source_size);
/*
 * Make sure that device for device_path exist
 * in load_image(). Otherwise, shell and grub will fail.
-- 
2.47.0.163.g1226f6d8fa-goog

Re: [PATCH] lmb: Correctly unmap memory after notifications

[Heinrich Schuchardt]

On 10/29/24 09:48, Ilias Apalodimas wrote:

Hi Heinrich

On Tue, 29 Oct 2024 at 10:00, Ilias Apalodimas
 wrote:


Hi Heinrich

On Mon, 28 Oct 2024 at 08:37, Heinrich Schuchardt  wrote:


On 10/24/24 12:46, Ilias Apalodimas wrote:

We never unmap the memory used to update the EFI memory map after
notifications

Fixes: commit 2f6191526a13 ("lmb: notify of any changes to the LMB memory map")
Signed-off-by: Ilias Apalodimas 
---
   lib/lmb.c | 1 +
   1 file changed, 1 insertion(+)

diff --git a/lib/lmb.c b/lib/lmb.c
index 890e2cbfdf6b..38c6e1d5ba8d 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -65,6 +65,7 @@ static int __maybe_unused lmb_map_update_notify(phys_addr_t 
addr,
   status & ~EFI_ERROR_MASK);
   return -1;
   }
+ unmap_sysmem((void *)(uintptr_t)efi_addr);


If PCI memory was ever mapped via pci_map_physmem(), I don't think that
we want to unmap it here.


Ok, so looking at it again, not calling unmap_sysmem() here won't
break anything, so I guess we can drop this patch.


Looking at it again, for special sandbox tags, we need to correctly
decrease the refcnt. So why do you think this isnt needed here?

Thanks
/Ilias



Reviewed-by: Heinrich Schuchardt 





Why do we map the memory in this notification function first hand?


Because the memory was added as such in efi_allocate_pages(). So for
sandbox we need to find the correct virtual memory that was added.


Can't
we use len = 0 when calling map_sysmem()?


We are using len = 0. But I am not following up on how could this
help. All you will get is a warning for sanbox if a pci device mapped
more that 0.

Thanks
/Ilias



I guess we have to critically review all map_sysmem() calls.

Best regards

Heinrich



   return 0;
   }

[PATCH] arm: dts: e850-96: Remove TRNG node from appended dts

[Sam Protsenko]

Commit 136b7b6d2e98 ("Subtree merge tag 'v6.11-dts' of dts repo [1] into
dts/upstream") updates the upstream dts for E850-96 board, bringing
upstream TRNG node. There is no need to keep TRNG node in appended dts
anymore, so remove it.

Tested on E850-96 board by running 'rng' command in U-Boot shell.

Signed-off-by: Sam Protsenko 
---
 arch/arm/dts/exynos850-e850-96-u-boot.dtsi | 11 ---
 1 file changed, 11 deletions(-)

diff --git a/arch/arm/dts/exynos850-e850-96-u-boot.dtsi 
b/arch/arm/dts/exynos850-e850-96-u-boot.dtsi
index 3aa5d8bb10d0..6d7148f7264a 100644
--- a/arch/arm/dts/exynos850-e850-96-u-boot.dtsi
+++ b/arch/arm/dts/exynos850-e850-96-u-boot.dtsi
@@ -3,17 +3,6 @@
  * Copyright (c) 2023 Linaro Ltd.
  */
 
-&soc {
-   /* TODO: Remove this node once it appears in upstream dts */
-   trng: rng@12081400 {
-   compatible = "samsung,exynos850-trng";
-   reg = <0x12081400 0x100>;
-   clocks = <&cmu_core CLK_GOUT_SSS_ACLK>,
-<&cmu_core CLK_GOUT_SSS_PCLK>;
-   clock-names = "secss", "pclk";
-   };
-};
-
 &pmu_system_controller {
bootph-all;
samsung,uart-debug-1;
-- 
2.39.5

Re: [PATCH v4 2/2] binman: expand test coverage to nxp_imx8mcst

[Fabio Estevam]

Hi Brian,

On Wed, Oct 30, 2024 at 5:08 AM Brian Ruley
 wrote:
>
> Add coverage for IMX8M code siging. Create PKI tree and other assets
> required by `cst' using `hab4_pki_tree.sh' script and `srktool' in
> `cst_3.4.1' [1].
>
> [1] https://www.nxp.com/webapp/Download?colCode=IMX_CST_TOOL_NEW
>
> Signed-off-by: Brian Ruley 
> ---
> Changes for v4:
> - Rebased on master:
> 340_nxp_imx8mcst.dts -> 343_nxp_imx8mcst.dts
> 341_nxp_imx8mcst_fast_auth.dts -> 344_nxp_imx8mcst_fast_auth.dts

Here is the result when I tried applying and testing this:

$ git am 
~/Downloads/v4-1-2-binman-nxp_imx8mcst-read-certificates-from-input-path.patch
Applying: binman: nxp_imx8mcst: read certificates from input path
Applying: binman: expand test coverage to nxp_imx8mcst
.git/rebase-apply/patch:206: trailing whitespace.
X509v3 Basic Constraints:
.git/rebase-apply/patch:208: trailing whitespace.
Netscape Comment:
.git/rebase-apply/patch:210: trailing whitespace.
X509v3 Subject Key Identifier:
.git/rebase-apply/patch:212: trailing whitespace.
X509v3 Authority Key Identifier:
.git/rebase-apply/patch:333: trailing whitespace.
X509v3 Basic Constraints:
warning: squelched 7 whitespace errors
warning: 12 lines add whitespace errors.


$ ./tools/binman/binman test testNxpImx8mCstFastAuth
 Running binman tests 
E
==
ERROR: testNxpImx8mCstFastAuth (binman.ftest.TestFunctional)
Test that binman can sign an iMX8M image using fast authentication
--
ValueError: Error -11 running 'cst -i
/tmp/binman.tf697xr9/nxp.csf-config-txt.nxp-imx8mcst -o
/tmp/binman.tf697xr9/nxp.csf-output-blob.nxp-imx8mcst':

--
Ran 1 test in 1.318s

FAILED (errors=1)

Any ideas?

[PATCH v4 0/2] Add support for Cool Pi GenBook

[Andy Yan]

Support for Cool Pi GenBook is landing Linux 6.12-rc1, so also
add the support for u-boot here.

Changes in v4:
- Fix a underline too short error in rst doc

Changes in v3:
- Remove upstreamed dt in genbook-u-boot.dtsi
- Remove MMC releated config as there is no SD-card on this machine
- Enable LED config
- Enable rk8xx pmic
- rename defconfig to coolpi-cm5-genbook-rk3588_defconfig
- redefine BOOT_TARGETS

Changes in v2:
- Cherry pick it from 
https://git.kernel.org/pub/scm/linux/kernel/git/devicetree/devicetree-rebasing.git
- split the dts to a separate commit
- rename to genbook_cm5_rk3588
- move readme to doc/board, and write as reStructuredText format
- alphabetically reorder
- update doc/board/rockchip

Andy Yan (2):
  arm64: dts: rockchip: Add support for rk3588 based Cool Pi CM5 GenBook
  board: rockchip: Add support for rk3588 GenBook

 .../dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi |  20 +
 arch/arm/mach-rockchip/rk3588/Kconfig |  19 +
 board/coolpi/genbook_cm5_rk3588/Kconfig   |  12 +
 board/coolpi/genbook_cm5_rk3588/MAINTAINERS   |   7 +
 configs/coolpi-cm5-genbook-rk3588_defconfig   | 101 +
 doc/board/coolpi/genbook_cm5_rk3588.rst   |  68 
 doc/board/coolpi/index.rst|   9 +
 doc/board/rockchip/rockchip.rst   |   1 +
 .../rockchip/rk3588-coolpi-cm5-genbook.dts| 349 ++
 include/configs/genbook-cm5-rk3588.h  |  31 ++
 10 files changed, 617 insertions(+)
 create mode 100644 arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi
 create mode 100644 board/coolpi/genbook_cm5_rk3588/Kconfig
 create mode 100644 board/coolpi/genbook_cm5_rk3588/MAINTAINERS
 create mode 100644 configs/coolpi-cm5-genbook-rk3588_defconfig
 create mode 100644 doc/board/coolpi/genbook_cm5_rk3588.rst
 create mode 100644 doc/board/coolpi/index.rst
 create mode 100644 
dts/upstream/src/arm64/rockchip/rk3588-coolpi-cm5-genbook.dts
 create mode 100644 include/configs/genbook-cm5-rk3588.h

-- 
2.34.1

Re: [PATCH v4 1/2] binman: nxp_imx8mcst: read certificates from input path

[Rasmus Villemoes]

On Wed, Oct 30 2024, Brian Ruley  wrote:

> Right now, it is unclear where the certificates (and private keys) are
> read from if environment variables are unset, and providing complete
> paths in the device tree is not ideal. Naturally, it makes sense
> to be able to decide where binman should look for the files, regardless
> whether the keys are specified in the device tree or not.
>
> Therefore, expand the etype to look for the necessary files from the
> input path. Introduce a new variable to provide users the ability to
> specify a custom path.
>
> As a consequence of this change, the environment variables used to
> specify the keys, e.g., `IMG_KEY', will be searched *relative* to the
> input directories.

Hopefully not if those env variables contain an absolute path?

Rasmus

Re: [PATCH v2 4/5] arm: mach-k3: j721e-init.c: J7200: Add support for CONFIG_K3_OPP_LOW

[Aniket Limaye]

Hi Manorit,

On 30/10/24 13:31, Manorit Chawdhry wrote:

Hi Aniket,

On 15:40-20241029, Manorit Chawdhry wrote:

Hi Aniket,

On 18:27-20241023, Aniket Limaye wrote:

From: Reid Tonking 

The default j7200 devicetree and k3_avs driver set 2GHz/1GHz frequency
for A72/MSMC clks and the OPP_NOM voltage.

J7200 SOCs may support OPP_LOW Operating Performance Point:
1GHz/500MHz clks for A72/MSMC and OPP_LOW AVS voltage read from efuse.

Hence, add a config check to select OPP_LOW specs:
- Check if OPP_LOW AVS voltage read from efuse is valid.
- Update the clock frequencies in devicetree.
- Program the OPP_LOW AVS voltage for VDD_CPU.

Signed-off-by: Reid Tonking 
Signed-off-by: Aniket Limaye 

---
v2:
- Fix indentation in fix_freq()
- Remove the efuse data check addition from this commit, as it's not
   related to adding support for CONFIG_K3_OPP_LOW. The same addition
   was moved to the previous patch in this series.
- Link to v1: 
https://lore.kernel.org/u-boot/20241017062911.2241167-5-a-lim...@ti.com/
---
  arch/arm/mach-k3/j721e/j721e_init.c | 45 -
  1 file changed, 44 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-k3/j721e/j721e_init.c 
b/arch/arm/mach-k3/j721e/j721e_init.c
index e9ed8cb267c..de10517bb27 100644
--- a/arch/arm/mach-k3/j721e/j721e_init.c
+++ b/arch/arm/mach-k3/j721e/j721e_init.c
@@ -19,6 +19,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "../sysfw-loader.h"

  #include "../common.h"
@@ -147,6 +148,32 @@ static void setup_navss_nb(void)
writel(NB_THREADMAP_BIT1, (uintptr_t)NAVSS0_NBSS_NB1_CFG_NB_THREADMAP);
  }
  
+int fix_freq(const void *fdt)


I think this can be static as well btw, maybe rename it to something
more descriptive as well. fdt_fixup_a72_clock_frequency?



Yeah this can be made static. Will do.
Rename also makes sense... Since it's updating A72SS0_CORE0_0_ARM_CLK & 
A72SS0_CORE0_MSMC_CLK, what do you think about:


static int fdt_fixup_a72ss_clock_frequency(const void *fdt) ?


+{
+   int node, ret;
+   u32 opp_low_freq[3];
+
+   node = fdt_node_offset_by_compatible(fdt, -1, "ti,am654-rproc");
+   if (node < 0) {
+   printf("%s: A72 not found\n", __func__);
+   return node;
+   }
+
+   /* j7200 opp low values according to data sheet */
+   opp_low_freq[0] = cpu_to_fdt32(10); /* 202-2 -> 
A72SS0_CORE0_0_ARM_CLK */
+   opp_low_freq[1] = cpu_to_fdt32(2); /* 61-1 -> GTC0_GTC_CLK */
+   opp_low_freq[2] = cpu_to_fdt32(5); /* 4-1 -> 
A72SS0_CORE0_MSMC_CLK */
+
+   ret = fdt_setprop((void *)fdt, node, "assigned-clock-rates",
+ opp_low_freq, sizeof(opp_low_freq));
+   if (ret) {
+   printf("%s: Can not set value\n", __func__);
+   return ret;
+   }
+
+   return 0;
+}
+
  /*
   * This uninitialized global variable would normal end up in the .bss section,
   * but the .bss is cleared between writing and reading this variable, so move
@@ -301,8 +328,24 @@ void board_init_f(ulong dummy)
  #if defined(CONFIG_CPU_V7R) && defined(CONFIG_K3_AVS0)
ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(k3_avs),
  &dev);
-   if (ret)
+   if (!ret) {
+   if (IS_ENABLED(CONFIG_K3_OPP_LOW)) {


These ifs can be combined into one ig.


+   ret = k3_check_opp(dev, J721E_VDD_MPU, AM6_OPP_LOW);
+   if (!ret) {
+   ret = fix_freq(gd->fdt_blob);
+   if (ret)
+   printf("Failed to set OPP_LOW 
frequency\n");
+
+   ret = k3_avs_set_opp(dev, J721E_VDD_MPU, 
AM6_OPP_LOW);


Even if fix_freq fails, do we want to cascade and still run
k3_avs_set_opp? Not sure what the best way to handle this is but seeing
a lot of nesting so wondering if there is any better way to handle this
control flow..


For this I think it might be a good idea to take this chunk out into
another function like setup_opp_low as well and keep it there, might be
more readable that way IMHO.



Hmm okay, I re-evaluated what we are trying to do here.
Below is the logical path that should be taken:

board_init_f():
-> if CONFIG_K3_OPP_LOW
-> if valid efuse for OPP_LOW
-> fix_freq() # Update freq to OPP_LOW spec
clk-k3: ti_clk_set_rate()
-> k3_avs_notify_freq()
-> if freq matches OPP_LOW spec
-> k3_avs_set_voltage()  # Update volt to OPP_LOW spec


For that, I propose the following code instead:

ret = uclass_get_device_by_driver(...)
if(ret){
print("AVS init failed: %d\n", ret);
} else if IS_ENABLED(CONFIG_K3_OPP_LOW) {
ret = k3_check_opp(dev, J721E_VDD_MPU, AM6_OPP_LOW);
if (ret) {
printf("OPP_LOW: k3_check_opp failed: %d\n", ret);
} else {
ret = fix_freq(gd->fdt_blob);
if (ret)

[PATCH v9 3/7] usb: onboard-hub: add support for Microchip USB5744

[Venkatesh Yadav Abbarapu]

Add support for the Microchip USB5744 USB3.0 and USB2.0 Hub.
The usb5744 driver trigger hub reset signal after soft reset.
The usb5744 hub need to reset after the phy initialization,
which toggles the gpio.

Signed-off-by: Venkatesh Yadav Abbarapu 
Reviewed-by: Marek Vasut 
---
 common/usb_onboard_hub.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/common/usb_onboard_hub.c b/common/usb_onboard_hub.c
index 6ef9c87fc9..fc7953e8bd 100644
--- a/common/usb_onboard_hub.c
+++ b/common/usb_onboard_hub.c
@@ -89,10 +89,21 @@ static int usb_onboard_hub_remove(struct udevice *dev)
return ret;
 }
 
+static const struct onboard_hub_data usb5744_data = {
+   .power_on_delay_us = 1,
+   .reset_us = 1,
+};
+
 static const struct udevice_id usb_onboard_hub_ids[] = {
/* Use generic usbVID,PID dt-bindings (usb-device.yaml) */
-   { .compatible = "usb424,2514" }, /* USB2514B USB 2.0 */
-   { }
+   {   .compatible = "usb424,2514" /* USB2514B USB 2.0 */
+   }, {
+   .compatible = "usb424,2744", /* USB2744 USB 2.0 */
+   .data = (ulong)&usb5744_data,
+   }, {
+   .compatible = "usb424,5744", /* USB5744 USB 3.0 */
+   .data = (ulong)&usb5744_data,
+   }
 };
 
 U_BOOT_DRIVER(usb_onboard_hub) = {
-- 
2.17.1

[PATCH] configs: visionfive2: re-enable SPL_SYS_MMCSD_RAW_MODE

[Andreas Schwab]

To restore MMC boot, enable SPL_SYS_MMCSD_RAW_MODE and recover
SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION and
SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION.

Fixes: 2a00d73d081 ("spl: mmc: Try to clean up raw-mode options")
---
 configs/starfive_visionfive2_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/starfive_visionfive2_defconfig 
b/configs/starfive_visionfive2_defconfig
index c3508926d6c..11e1332f875 100644
--- a/configs/starfive_visionfive2_defconfig
+++ b/configs/starfive_visionfive2_defconfig
@@ -55,6 +55,9 @@ CONFIG_SPL_PAD_TO=0x0
 CONFIG_SPL_SYS_MALLOC=y
 CONFIG_SPL_HAS_CUSTOM_MALLOC_START=y
 CONFIG_SPL_CUSTOM_SYS_MALLOC_ADDR=0x8000
+CONFIG_SPL_SYS_MMCSD_RAW_MODE=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_PARTITION=y
+CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_PARTITION=0x2
 CONFIG_SPL_SYS_MALLOC_SIZE=0x40
 CONFIG_SPL_I2C=y
 CONFIG_SPL_DM_SPI_FLASH=y
-- 
2.47.0


-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: [PATCH 2/2] dt-bindings: Drop unused RZ/G2L devicetree bindings

[Marek Vasut]

On 10/30/24 11:32 AM, Paul Barker wrote:

We are now using the dts/upstream subtree for the RZ/G2L SoC family.


That's great news, but ... what does this commit do ?

It would be good to at least include "Drop unused headers" in the commit 
message.

Re: [PATCH] board: rzg2l: Update MAINTAINERS file to match dts/upstream paths

[Marek Vasut]

On 10/30/24 11:35 AM, Paul Barker wrote:

We are now using the dts/upstream subtree for the RZ/G2L SoC family, so
update the board MAINTAINERS file to match rz-smarc dtsi files in this
subtree.

Signed-off-by: Paul Barker 

Reviewed-by: Marek Vasut 

Re: [PATCH v3] rockchip: add support for Radxa ROCK 5A with SPI NOR flash module

[Eugen Hristev]

On 10/30/24 08:30, Kever Yang wrote:

Hi Naoki,

On 2024/10/30 14:07, FUKAUMI Naoki wrote:

on Radxa ROCK 5A, sdhci(eMMC) and fspim0(SPI NOR flash) share pins
(i.e. eMMC and SPI NOR flash are exclusive), new defconfig and dts
specifically for SPI NOR flash is required.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v3
- drop first patch
- fix copyright
- run savedefconfig
- sync with changes for LED for Radxa boards
- add more SPI NOR flash chips
Changes in v2
- fix subject
---
  arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi | 32 +++
  arch/arm/dts/rk3588s-rock-5a-spi.dts |  4 +
  board/radxa/rock5a-rk3588s/MAINTAINERS   |  5 +-
  configs/rock5a-spi-rk3588s_defconfig | 87 
  4 files changed, 125 insertions(+), 3 deletions(-)
  create mode 100644 arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3588s-rock-5a-spi.dts
  create mode 100644 configs/rock5a-spi-rk3588s_defconfig

diff --git a/arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi b/arch/arm/ 
dts/rk3588s-rock-5a-spi-u-boot.dtsi

new file mode 100644
index 000..7723931d869
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Radxa Computer (Shenzhen) Co., Ltd.
+ */
+
+#include "rk3588s-u-boot.dtsi"
+
+/ {
+    leds {
+    io-led {
+    default-state = "on";
+    };
+    };
+};
+
+&fspim0_pins {
+    bootph-pre-ram;
+    bootph-some-ram;
+};
+
+&sdhci {
+    status = "disabled";
+};
+
+&sfc {
+    status = "okay";
+
+    flash@0 {
+    bootph-pre-ram;
+    bootph-some-ram;
+    };
+};
diff --git a/arch/arm/dts/rk3588s-rock-5a-spi.dts b/arch/arm/dts/ 
rk3588s-rock-5a-spi.dts

new file mode 100644
index 000..780e90d041b
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-spi.dts
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include "rk3588s-rock-5a.dts"
diff --git a/board/radxa/rock5a-rk3588s/MAINTAINERS b/board/radxa/ 
rock5a-rk3588s/MAINTAINERS

index a569efa74e3..06ebc9829f4 100644
--- a/board/radxa/rock5a-rk3588s/MAINTAINERS
+++ b/board/radxa/rock5a-rk3588s/MAINTAINERS
@@ -4,6 +4,5 @@ R:    Jonas Karlman 
  S:    Maintained
  F:    board/radxa/rock5a-rk3588s
  F:    include/configs/rock5a-rk3588s.h
-F:    configs/rock5a-rk3588s_defconfig
-F:    arch/arm/dts/rk3588s-rock-5a.dts
-F:    arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
+F:    configs/rock5a*
+F:    arch/arm/dts/rk3588s-rock-5a*
diff --git a/configs/rock5a-spi-rk3588s_defconfig b/configs/rock5a- 
spi-rk3588s_defconfig

new file mode 100644
index 000..d6409a12a56
--- /dev/null
+++ b/configs/rock5a-spi-rk3588s_defconfig
@@ -0,0 +1,87 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a-spi"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
+CONFIG_SPL_SERIAL=y
+CONFIG_TARGET_ROCK5A_RK3588=y
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_SF_DEFAULT_BUS=5
+CONFIG_DEBUG_UART_BASE=0xFEB5
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588s-rock-5a.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
+CONFIG_SPL_ATF=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y

MMC should removed


The eMMC is disabled, but this board has an SD-Card right ?


+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+# CONFIG_OF_UPSTREAM is not set
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned- 
clocks assigned-clock-rates assigned-clock-parents"

+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_MISC=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y


MMC relate driver should removed


Thanks,
- Kever

+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_XTX=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DWC_ETH_QOS=y
+CONFIG_DWC_ETH_QOS_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
+CONFIG_PHY_ROCKCHIP_USBDP=y
+CONFIG_SPL_PINCTRL=y
+CONFIG_PWM_ROCKCHIP=y
+CONFIG_SPL_RAM=y
+CONFIG_BAUDRATE=150
+CONFIG_DEBUG_UART_SHIFT=2
+CONFIG_SYS_NS16550_MEM32=y

[PATCH v2 1/2] ARM: dts: Drop unused RZ/G2L devicetrees

[Paul Barker]

We are now using the dts/upstream subtree for the RZ/G2L SoC family so
we can drop unused devicetree files from arch/arm/dts.

Signed-off-by: Paul Barker 
---
Changes v1->v2:
  - Improve commit message

 arch/arm/dts/Makefile |3 -
 arch/arm/dts/r9a07g044.dtsi   | 1273 -
 arch/arm/dts/r9a07g044l2-smarc.dts|   39 -
 arch/arm/dts/r9a07g044l2.dtsi |   13 -
 arch/arm/dts/rz-smarc-common.dtsi |  183 ---
 arch/arm/dts/rzg2l-smarc-pinfunction.dtsi |  157 ---
 arch/arm/dts/rzg2l-smarc-som.dtsi |  371 --
 arch/arm/dts/rzg2l-smarc.dtsi |  181 ---
 8 files changed, 2220 deletions(-)
 delete mode 100644 arch/arm/dts/r9a07g044.dtsi
 delete mode 100644 arch/arm/dts/r9a07g044l2-smarc.dts
 delete mode 100644 arch/arm/dts/r9a07g044l2.dtsi
 delete mode 100644 arch/arm/dts/rz-smarc-common.dtsi
 delete mode 100644 arch/arm/dts/rzg2l-smarc-pinfunction.dtsi
 delete mode 100644 arch/arm/dts/rzg2l-smarc-som.dtsi
 delete mode 100644 arch/arm/dts/rzg2l-smarc.dtsi

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index aeccfa93fc53..e0cc9937acb4 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -979,9 +979,6 @@ dtb-$(CONFIG_ARCH_IMXRT) += imxrt1050-evk.dtb \
imxrt1020-evk.dtb \
imxrt1170-evk.dtb \
 
-dtb-$(CONFIG_TARGET_RZG2L) += \
-   r9a07g044l2-smarc.dts
-
 ifdef CONFIG_RCAR_64
 DTC_FLAGS += -R 4 -p 0x1000
 endif
diff --git a/arch/arm/dts/r9a07g044.dtsi b/arch/arm/dts/r9a07g044.dtsi
deleted file mode 100644
index 66f68fc2b241..
--- a/arch/arm/dts/r9a07g044.dtsi
+++ /dev/null
@@ -1,1273 +0,0 @@
-// SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
-/*
- * Device Tree Source for the RZ/G2L and RZ/G2LC common SoC parts
- *
- * Copyright (C) 2021 Renesas Electronics Corp.
- */
-
-#include 
-#include 
-
-/ {
-   compatible = "renesas,r9a07g044";
-   #address-cells = <2>;
-   #size-cells = <2>;
-
-   audio_clk1: audio1-clk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   /* This value must be overridden by boards that provide it */
-   clock-frequency = <0>;
-   };
-
-   audio_clk2: audio2-clk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   /* This value must be overridden by boards that provide it */
-   clock-frequency = <0>;
-   };
-
-   /* External CAN clock - to be overridden by boards that provide it */
-   can_clk: can-clk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <0>;
-   };
-
-   /* clock can be either from exclk or crystal oscillator (XIN/XOUT) */
-   extal_clk: extal-clk {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   /* This value must be overridden by the board */
-   clock-frequency = <0>;
-   };
-
-   cluster0_opp: opp-table-0 {
-   compatible = "operating-points-v2";
-   opp-shared;
-
-   opp-15000 {
-   opp-hz = /bits/ 64 <15000>;
-   opp-microvolt = <110>;
-   clock-latency-ns = <30>;
-   };
-   opp-3 {
-   opp-hz = /bits/ 64 <3>;
-   opp-microvolt = <110>;
-   clock-latency-ns = <30>;
-   };
-   opp-6 {
-   opp-hz = /bits/ 64 <6>;
-   opp-microvolt = <110>;
-   clock-latency-ns = <30>;
-   };
-   opp-12 {
-   opp-hz = /bits/ 64 <12>;
-   opp-microvolt = <110>;
-   clock-latency-ns = <30>;
-   opp-suspend;
-   };
-   };
-
-   cpus {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   cpu-map {
-   cluster0 {
-   core0 {
-   cpu = <&cpu0>;
-   };
-   core1 {
-   cpu = <&cpu1>;
-   };
-   };
-   };
-
-   cpu0: cpu@0 {
-   compatible = "arm,cortex-a55";
-   reg = <0>;
-   device_type = "cpu";
-   #cooling-cells = <2>;
-   next-level-cache = <&L3_CA55>;
-   enable-method = "psci";
-   clocks = <&cpg CPG_CORE R9A07G044_CLK_I>;
-   operating-points-v2 = <&cluster0_opp>;
-   };
-
-   cpu1: cpu@100 {
-   

[PATCH v2 2/2] dt-bindings: Drop unused RZ/G2L devicetree bindings

[Paul Barker]

We are now using the dts/upstream subtree for the RZ/G2L SoC family so
we can drop unused dt-bindings headers.

Signed-off-by: Paul Barker 
---
Changes v1->v2:
  - Improve commit message

 include/dt-bindings/clock/r9a07g044-cpg.h | 220 --
 .../interrupt-controller/irqc-rzg2l.h |  25 --
 include/dt-bindings/pinctrl/rzg2l-pinctrl.h   |  23 --
 3 files changed, 268 deletions(-)
 delete mode 100644 include/dt-bindings/clock/r9a07g044-cpg.h
 delete mode 100644 include/dt-bindings/interrupt-controller/irqc-rzg2l.h
 delete mode 100644 include/dt-bindings/pinctrl/rzg2l-pinctrl.h

diff --git a/include/dt-bindings/clock/r9a07g044-cpg.h 
b/include/dt-bindings/clock/r9a07g044-cpg.h
deleted file mode 100644
index 0bb17ff1a01a..
--- a/include/dt-bindings/clock/r9a07g044-cpg.h
+++ /dev/null
@@ -1,220 +0,0 @@
-/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
- *
- * Copyright (C) 2021 Renesas Electronics Corp.
- */
-#ifndef __DT_BINDINGS_CLOCK_R9A07G044_CPG_H__
-#define __DT_BINDINGS_CLOCK_R9A07G044_CPG_H__
-
-#include 
-
-/* R9A07G044 CPG Core Clocks */
-#define R9A07G044_CLK_I0
-#define R9A07G044_CLK_I2   1
-#define R9A07G044_CLK_G2
-#define R9A07G044_CLK_S0   3
-#define R9A07G044_CLK_S1   4
-#define R9A07G044_CLK_SPI0 5
-#define R9A07G044_CLK_SPI1 6
-#define R9A07G044_CLK_SD0  7
-#define R9A07G044_CLK_SD1  8
-#define R9A07G044_CLK_M0   9
-#define R9A07G044_CLK_M1   10
-#define R9A07G044_CLK_M2   11
-#define R9A07G044_CLK_M3   12
-#define R9A07G044_CLK_M4   13
-#define R9A07G044_CLK_HP   14
-#define R9A07G044_CLK_TSU  15
-#define R9A07G044_CLK_ZT   16
-#define R9A07G044_CLK_P0   17
-#define R9A07G044_CLK_P1   18
-#define R9A07G044_CLK_P2   19
-#define R9A07G044_CLK_AT   20
-#define R9A07G044_OSCCLK   21
-#define R9A07G044_CLK_P0_DIV2  22
-
-/* R9A07G044 Module Clocks */
-#define R9A07G044_CA55_SCLK0
-#define R9A07G044_CA55_PCLK1
-#define R9A07G044_CA55_ATCLK   2
-#define R9A07G044_CA55_GICCLK  3
-#define R9A07G044_CA55_PERICLK 4
-#define R9A07G044_CA55_ACLK5
-#define R9A07G044_CA55_TSCLK   6
-#define R9A07G044_GIC600_GICCLK7
-#define R9A07G044_IA55_CLK 8
-#define R9A07G044_IA55_PCLK9
-#define R9A07G044_MHU_PCLK 10
-#define R9A07G044_SYC_CNT_CLK  11
-#define R9A07G044_DMAC_ACLK12
-#define R9A07G044_DMAC_PCLK13
-#define R9A07G044_OSTM0_PCLK   14
-#define R9A07G044_OSTM1_PCLK   15
-#define R9A07G044_OSTM2_PCLK   16
-#define R9A07G044_MTU_X_MCK_MTU3   17
-#define R9A07G044_POE3_CLKM_POE18
-#define R9A07G044_GPT_PCLK 19
-#define R9A07G044_POEG_A_CLKP  20
-#define R9A07G044_POEG_B_CLKP  21
-#define R9A07G044_POEG_C_CLKP  22
-#define R9A07G044_POEG_D_CLKP  23
-#define R9A07G044_WDT0_PCLK24
-#define R9A07G044_WDT0_CLK 25
-#define R9A07G044_WDT1_PCLK26
-#define R9A07G044_WDT1_CLK 27
-#define R9A07G044_WDT2_PCLK28
-#define R9A07G044_WDT2_CLK 29
-#define R9A07G044_SPI_CLK2 30
-#define R9A07G044_SPI_CLK  31
-#define R9A07G044_SDHI0_IMCLK  32
-#define R9A07G044_SDHI0_IMCLK2 33
-#define R9A07G044_SDHI0_CLK_HS 34
-#define R9A07G044_SDHI0_ACLK   35
-#define R9A07G044_SDHI1_IMCLK  36
-#define R9A07G044_SDHI1_IMCLK2 37
-#define R9A07G044_SDHI1_CLK_HS 38
-#define R9A07G044_SDHI1_ACLK   39
-#define R9A07G044_GPU_CLK  40
-#define R9A07G044_GPU_AXI_CLK  41
-#define R9A07G044_GPU_ACE_CLK  42
-#define R9A07G044_ISU_ACLK 43
-#define R9A07G044_ISU_PCLK 44
-#define R9A07G044_H264_CLK_A   45
-#define R9A07G044_H264_CLK_P   46
-#define R9A07G044_CRU_SYSCLK   47
-#define R9A07G044_CRU_VCLK 48
-#define R9A07G044_CRU_PCLK 49
-#define R9A07G044_CRU_ACLK 50
-#define R9A07G044_MIPI_DSI_PLLCLK  51
-#define R9A07G044_MIPI_DSI_SYSCLK  52
-#define R9A07G044_MIPI_DSI_ACLK53
-#define R9A07G044_MIPI_DSI_PCLK54
-#define R9A07G044_MIPI_DSI_VCLK55
-#define R9A07G044_MIPI_DSI_LPCLK   56
-#define R9A07G044_LCDC_CLK_A   57
-#define R9A07G044_LCDC_CLK_P   58
-#define R9A07G044_LCDC_CLK_D   59
-#define R9A07G044_SSI0_PCLK2   60
-#define R9A07G044_SSI0_PCLK_SFR61
-#define R9A07G044_SSI1_PCLK2   62
-#define R9A07G044_SSI1_PCLK_SFR63
-#define R9A07G044_SSI2_PCLK2   64
-#define R9A07G044_SSI2_

Re: [PATCH v8 2/8] efi_loader: Add a test app

[Tom Rini]

On Wed, Oct 30, 2024 at 08:41:27AM +0100, Simon Glass wrote:
> Hi Tom,
> 
> On Tue, 29 Oct 2024 at 17:46, Tom Rini  wrote:
> >
> > On Tue, Oct 29, 2024 at 04:46:16PM +0100, Simon Glass wrote:
> > > Hi Heinrich,
> > >
> > > On Mon, 28 Oct 2024 at 19:43, Heinrich Schuchardt  
> > > wrote:
> > > >
> > > > On 10/28/24 18:00, Simon Glass wrote:
> > > > > Hi Heinrich,
> > > > >
> > > > > On Mon, 28 Oct 2024 at 07:11, Heinrich Schuchardt  > > > > > wrote:
> > > > >  >
> > > > >  > On 10/22/24 14:00, Simon Glass wrote:
> > > > >  > > Add a simple app to use for testing. This is intended to do 
> > > > > whatever it
> > > > >  > > needs to for testing purposes. For now it just prints a message 
> > > > > and
> > > > >  > > exits boot services.
> > > > >  > >
> > > > >  > > There was a considerable amount of discussion about whether it 
> > > > > is OK to
> > > > >  > > call exit-boot-services and then return to U-Boot. This is not 
> > > > > normally
> > > > >  > > done in a real application, since exit-boot-services is used to
> > > > >  > > completely disconnect from U-Boot. However, since this is a 
> > > > > test, we
> > > > >  > > need to check the results of running the app, so returning is
> > > > > necessary.
> > > > >  > > It works correctly and it provides a nice model of how to test 
> > > > > the EFI
> > > > >  > > code in a simple way.
> > > > >  > >
> > > > >  > > Signed-off-by: Simon Glass  > > > > >
> > > > >  > > ---
> > > > >  > >
> > > > >  > > (no changes since v7)
> > > > >  > >
> > > > >  > > Changes in v7:
> > > > >  > > - Update commit message
> > > > >  > >
> > > > >  > >   lib/efi_loader/Kconfig   | 10 ++
> > > > >  > >   lib/efi_loader/Makefile  |  1 +
> > > > >  > >   lib/efi_loader/testapp.c | 68 
> > > > > +++
> > > > > +
> > > > >  > >   3 files changed, 79 insertions(+)
> > > > >  > >   create mode 100644 lib/efi_loader/testapp.c
> > > > >  > >
> > > > >  > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > > >  > > index 69b2c9360d8..6ced29da719 100644
> > > > >  > > --- a/lib/efi_loader/Kconfig
> > > > >  > > +++ b/lib/efi_loader/Kconfig
> > > > >  > > @@ -565,6 +565,16 @@ config BOOTEFI_HELLO_COMPILE
> > > > >  > > No additional space will be required in the resulting U-
> > > > > Boot binary
> > > > >  > > when this option is enabled.
> > > > >  > >
> > > > >  > > +config BOOTEFI_TESTAPP_COMPILE
> > > > >  > > + bool "Compile an EFI test app for testing"
> > > > >  > > + default y
> > > > >  > > + help
> > > > >  > > +   This compiles an app designed for testing. It is packed
> > > > > into an image
> > > > >  > > +   by the test.py testing frame in the setup_efi_image() 
> > > > > function.
> > > > >  > > +
> > > > >  > > +   No additional space will be required in the resulting U-
> > > > > Boot binary
> > > > >  > > +   when this option is enabled.
> > > > >  > > +
> > > > >  > >   endif
> > > > >  > >
> > > > >  > >   source "lib/efi/Kconfig"
> > > > >  > > diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> > > > >  > > index 00d18966f9e..87131ab911d 100644
> > > > >  > > --- a/lib/efi_loader/Makefile
> > > > >  > > +++ b/lib/efi_loader/Makefile
> > > > >  > > @@ -20,6 +20,7 @@ apps-$(CONFIG_EFI_LOAD_FILE2_INITRD) += 
> > > > > initrddump
> > > > >  > >   ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
> > > > >  > >   apps-y += dtbdump
> > > > >  > >   endif
> > > > >  > > +apps-$(CONFIG_BOOTEFI_TESTAPP_COMPILE) += testapp
> > > > >  > >
> > > > >  > >   obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
> > > > >  > >   obj-$(CONFIG_EFI_BOOTMGR) += efi_bootmgr.o
> > > > >  > > diff --git a/lib/efi_loader/testapp.c b/lib/efi_loader/testapp.c
> > > > >  > > new file mode 100644
> > > > >  > > index 000..feb444c92e9
> > > > >  > > --- /dev/null
> > > > >  > > +++ b/lib/efi_loader/testapp.c
> > > > >  > > @@ -0,0 +1,68 @@
> > > > >  > > +// SPDX-License-Identifier: GPL-2.0+
> > > > >  >
> > > > >  > This is not a valid SPDX identifier. Please, use GPL-2.0-or-later.
> > > > >  >
> > > > >  > > +/*
> > > > >  > > + * Hello world EFI application
> > > > >  > > + *
> > > > >  > > + * Copyright 2024 Google LLC
> > > > >  > > + * Written by Simon Glass  > > > > >
> > > > >  > > + *
> > > > >  > > + * This test program is used to test the invocation of an EFI
> > > > > application.
> > > > >  > > + * It writes a few messages to the console and then exits boot
> > > > > services
> > > > >  > > + */
> > > > >  > > +
> > > > >  > > +#include 
> > > > >  > > +
> > > > >  > > +static const efi_guid_t loaded_image_guid =
> > > > > EFI_LOADED_IMAGE_PROTOCOL_GUID;
> > > > >  > > +
> > > > >  > > +static struct efi_system_table *systable;
> > > > >  > > +static struct efi_boot_services *boottime;
> > > > >  > > +static struct efi_simple_text_output_protocol *con_out;
> > > > >  > > +
> > > > >  > > +/**

[PATCH 1/3] cmd/nvedit.c: teach 'env default' to optionally keep runtime variables

[Rasmus Villemoes]

It can be useful to set all variables defined in the default
environment to the value they have there, but without removing
variables that are only defined at runtime. This can sort-of be done
today, by using the "env default var1 var2 ..." variant, but that
requires listing all variables defined in the default
environment. It's much more convenient to be able to say

  env default -k -a

The -k flag is also meaningful in the other case: If var1 is not
defined in the default environment, but var2 is,

  env default var1 var2

would emit a warning about var1 not being in the default env and thus
being deleted. With -k, there's no warning, and var1 is kept as-is.

Signed-off-by: Rasmus Villemoes 
---
 cmd/nvedit.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 392f90f8698..1f259801293 100644
--- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -523,6 +523,9 @@ static int do_env_default(struct cmd_tbl *cmdtp, int flag,
case 'f':   /* force */
env_flag |= H_FORCE;
break;
+   case 'k':
+   env_flag |= H_NOCLEAR;
+   break;
default:
return cmd_usage(cmdtp);
}
@@ -1133,8 +1136,9 @@ U_BOOT_LONGHELP(env,
 #if defined(CONFIG_CMD_ENV_CALLBACK)
"callbacks - print callbacks and their associated variables\nenv "
 #endif
-   "default [-f] -a - [forcibly] reset default environment\n"
-   "env default [-f] var [...] - [forcibly] reset variable(s) to their 
default values\n"
+   "default [-k] [-f] -a - [forcibly] reset default environment\n"
+   "env default [-k] [-f] var [...] - [forcibly] reset variable(s) to 
their default values\n"
+   "  \"-k\": keep variables not defined in default environment\n"
"env delete [-f] var [...] - [forcibly] delete variable(s)\n"
 #if defined(CONFIG_CMD_EDITENV)
"env edit name - edit environment variable\n"
-- 
2.47.0

[PATCH] arm: mach-k3: am62a7: Provide a way to obtain boot device for non SPLs

[Garrett Giordano]

Introduce get_boot_device() to obtain the booting device. Make it also
available for non SPL builds so u-boot can also know the device it
is booting from.

Signed-off-by: Garrett Giordano 
---
 arch/arm/mach-k3/Makefile |   1 +
 arch/arm/mach-k3/am62ax/Makefile  |   1 +
 arch/arm/mach-k3/am62ax/am62a7_init.c |  97 +--
 arch/arm/mach-k3/am62ax/boot.c| 106 ++
 4 files changed, 109 insertions(+), 96 deletions(-)
 create mode 100644 arch/arm/mach-k3/am62ax/boot.c

diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
index 8c4f6786a5b..ce09a30e58f 100644
--- a/arch/arm/mach-k3/Makefile
+++ b/arch/arm/mach-k3/Makefile
@@ -10,6 +10,7 @@ obj-y += common.o security.o
 obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
 obj-$(CONFIG_SOC_K3_AM62P5) += am62px/
 obj-$(CONFIG_SOC_K3_AM625) += am62x/
+obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
 obj-$(CONFIG_SOC_K3_AM642) += am64x/
 obj-$(CONFIG_SOC_K3_AM654) += am65x/
 obj-$(CONFIG_SOC_K3_J721E) += j721e/
diff --git a/arch/arm/mach-k3/am62ax/Makefile b/arch/arm/mach-k3/am62ax/Makefile
index e2ef88196f8..4e35e0c844d 100644
--- a/arch/arm/mach-k3/am62ax/Makefile
+++ b/arch/arm/mach-k3/am62ax/Makefile
@@ -5,3 +5,4 @@
 
 obj-$(CONFIG_OF_SYSTEM_SETUP) += am62a7_fdt.o
 obj-$(CONFIG_XPL_BUILD) += am62a7_init.o
+obj-y += boot.o
diff --git a/arch/arm/mach-k3/am62ax/am62a7_init.c 
b/arch/arm/mach-k3/am62ax/am62a7_init.c
index 0f62f39075b..5c0d3ee6869 100644
--- a/arch/arm/mach-k3/am62ax/am62a7_init.c
+++ b/arch/arm/mach-k3/am62ax/am62a7_init.c
@@ -171,102 +171,7 @@ void board_init_f(ulong dummy)
debug("am62a_init: %s done\n", __func__);
 }
 
-static u32 __get_backup_bootmedia(u32 devstat)
-{
-   u32 bkup_bootmode = (devstat & MAIN_DEVSTAT_BACKUP_BOOTMODE_MASK) >>
-   MAIN_DEVSTAT_BACKUP_BOOTMODE_SHIFT;
-   u32 bkup_bootmode_cfg =
-   (devstat & MAIN_DEVSTAT_BACKUP_BOOTMODE_CFG_MASK) >>
-   MAIN_DEVSTAT_BACKUP_BOOTMODE_CFG_SHIFT;
-
-   switch (bkup_bootmode) {
-   case BACKUP_BOOT_DEVICE_UART:
-   return BOOT_DEVICE_UART;
-
-   case BACKUP_BOOT_DEVICE_USB:
-   return BOOT_DEVICE_USB;
-
-   case BACKUP_BOOT_DEVICE_ETHERNET:
-   return BOOT_DEVICE_ETHERNET;
-
-   case BACKUP_BOOT_DEVICE_MMC:
-   if (bkup_bootmode_cfg)
-   return BOOT_DEVICE_MMC2;
-   return BOOT_DEVICE_MMC1;
-
-   case BACKUP_BOOT_DEVICE_SPI:
-   return BOOT_DEVICE_SPI;
-
-   case BACKUP_BOOT_DEVICE_I2C:
-   return BOOT_DEVICE_I2C;
-
-   case BACKUP_BOOT_DEVICE_DFU:
-   if (bkup_bootmode_cfg & MAIN_DEVSTAT_BACKUP_USB_MODE_MASK)
-   return BOOT_DEVICE_USB;
-   return BOOT_DEVICE_DFU;
-   };
-
-   return BOOT_DEVICE_RAM;
-}
-
-static u32 __get_primary_bootmedia(u32 devstat)
-{
-   u32 bootmode = (devstat & MAIN_DEVSTAT_PRIMARY_BOOTMODE_MASK) >>
-   MAIN_DEVSTAT_PRIMARY_BOOTMODE_SHIFT;
-   u32 bootmode_cfg = (devstat & MAIN_DEVSTAT_PRIMARY_BOOTMODE_CFG_MASK) >>
-   MAIN_DEVSTAT_PRIMARY_BOOTMODE_CFG_SHIFT;
-
-   switch (bootmode) {
-   case BOOT_DEVICE_OSPI:
-   fallthrough;
-   case BOOT_DEVICE_QSPI:
-   fallthrough;
-   case BOOT_DEVICE_XSPI:
-   fallthrough;
-   case BOOT_DEVICE_SPI:
-   return BOOT_DEVICE_SPI;
-
-   case BOOT_DEVICE_ETHERNET_RGMII:
-   fallthrough;
-   case BOOT_DEVICE_ETHERNET_RMII:
-   return BOOT_DEVICE_ETHERNET;
-
-   case BOOT_DEVICE_EMMC:
-   return BOOT_DEVICE_MMC1;
-
-   case BOOT_DEVICE_SPI_NAND:
-   return BOOT_DEVICE_SPINAND;
-
-   case BOOT_DEVICE_MMC:
-   if ((bootmode_cfg & MAIN_DEVSTAT_PRIMARY_MMC_PORT_MASK) >>
-   MAIN_DEVSTAT_PRIMARY_MMC_PORT_SHIFT)
-   return BOOT_DEVICE_MMC2;
-   return BOOT_DEVICE_MMC1;
-
-   case BOOT_DEVICE_DFU:
-   if ((bootmode_cfg & MAIN_DEVSTAT_PRIMARY_USB_MODE_MASK) >>
-   MAIN_DEVSTAT_PRIMARY_USB_MODE_SHIFT)
-   return BOOT_DEVICE_USB;
-   return BOOT_DEVICE_DFU;
-
-   case BOOT_DEVICE_NOBOOT:
-   return BOOT_DEVICE_RAM;
-   }
-
-   return bootmode;
-}
-
 u32 spl_boot_device(void)
 {
-   u32 devstat = readl(CTRLMMR_MAIN_DEVSTAT);
-   u32 bootmedia;
-
-   if (bootindex == K3_PRIMARY_BOOTMODE)
-   bootmedia = __get_primary_bootmedia(devstat);
-   else
-   bootmedia = __get_backup_bootmedia(devstat);
-
-   debug("am62a_init: %s: devstat = 0x%x bootmedia = 0x%x bootindex = 
%d\n",
-  __func__, devstat, bootmedia, bootindex);
-   return bootmedia;
+   return get_boot_device();
 }
diff --git a/arch/arm/mach

Re: [PATCH v3] rockchip: add support for Radxa ROCK 5A with SPI NOR flash module

[FUKAUMI Naoki]

Hi,

On 10/30/24 23:24, Eugen Hristev wrote:



On 10/30/24 08:30, Kever Yang wrote:

Hi Naoki,

On 2024/10/30 14:07, FUKAUMI Naoki wrote:

on Radxa ROCK 5A, sdhci(eMMC) and fspim0(SPI NOR flash) share pins
(i.e. eMMC and SPI NOR flash are exclusive), new defconfig and dts
specifically for SPI NOR flash is required.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v3
- drop first patch
- fix copyright
- run savedefconfig
- sync with changes for LED for Radxa boards
- add more SPI NOR flash chips
Changes in v2
- fix subject
---
  arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi | 32 +++
  arch/arm/dts/rk3588s-rock-5a-spi.dts |  4 +
  board/radxa/rock5a-rk3588s/MAINTAINERS   |  5 +-
  configs/rock5a-spi-rk3588s_defconfig | 87 
  4 files changed, 125 insertions(+), 3 deletions(-)
  create mode 100644 arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3588s-rock-5a-spi.dts
  create mode 100644 configs/rock5a-spi-rk3588s_defconfig

diff --git a/arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi b/arch/arm/ 
dts/rk3588s-rock-5a-spi-u-boot.dtsi

new file mode 100644
index 000..7723931d869
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi
@@ -0,0 +1,32 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2024 Radxa Computer (Shenzhen) Co., Ltd.
+ */
+
+#include "rk3588s-u-boot.dtsi"
+
+/ {
+    leds {
+    io-led {
+    default-state = "on";
+    };
+    };
+};
+
+&fspim0_pins {
+    bootph-pre-ram;
+    bootph-some-ram;
+};
+
+&sdhci {
+    status = "disabled";
+};
+
+&sfc {
+    status = "okay";
+
+    flash@0 {
+    bootph-pre-ram;
+    bootph-some-ram;
+    };
+};
diff --git a/arch/arm/dts/rk3588s-rock-5a-spi.dts b/arch/arm/dts/ 
rk3588s-rock-5a-spi.dts

new file mode 100644
index 000..780e90d041b
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-spi.dts
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include "rk3588s-rock-5a.dts"
diff --git a/board/radxa/rock5a-rk3588s/MAINTAINERS b/board/radxa/ 
rock5a-rk3588s/MAINTAINERS

index a569efa74e3..06ebc9829f4 100644
--- a/board/radxa/rock5a-rk3588s/MAINTAINERS
+++ b/board/radxa/rock5a-rk3588s/MAINTAINERS
@@ -4,6 +4,5 @@ R:    Jonas Karlman 
  S:    Maintained
  F:    board/radxa/rock5a-rk3588s
  F:    include/configs/rock5a-rk3588s.h
-F:    configs/rock5a-rk3588s_defconfig
-F:    arch/arm/dts/rk3588s-rock-5a.dts
-F:    arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
+F:    configs/rock5a*
+F:    arch/arm/dts/rk3588s-rock-5a*
diff --git a/configs/rock5a-spi-rk3588s_defconfig b/configs/rock5a- 
spi-rk3588s_defconfig

new file mode 100644
index 000..d6409a12a56
--- /dev/null
+++ b/configs/rock5a-spi-rk3588s_defconfig
@@ -0,0 +1,87 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a-spi"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
+CONFIG_SPL_SERIAL=y
+CONFIG_TARGET_ROCK5A_RK3588=y
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_SF_DEFAULT_BUS=5
+CONFIG_DEBUG_UART_BASE=0xFEB5
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588s-rock-5a.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
+CONFIG_SPL_ATF=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y

MMC should removed


The eMMC is disabled, but this board has an SD-Card right ?


yes, it has microSD slot. I'll remove eMMC things.

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.


+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+# CONFIG_OF_UPSTREAM is not set
+CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned- 
clocks assigned-clock-rates assigned-clock-parents"

+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_REGMAP=y
+CONFIG_SPL_SYSCON=y
+CONFIG_SPL_CLK=y
+CONFIG_ROCKCHIP_GPIO=y
+CONFIG_SYS_I2C_ROCKCHIP=y
+CONFIG_LED=y
+CONFIG_LED_GPIO=y
+CONFIG_MISC=y
+CONFIG_SUPPORT_EMMC_RPMB=y
+CONFIG_MMC_DW=y
+CONFIG_MMC_DW_ROCKCHIP=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_SDMA=y
+CONFIG_MMC_SDHCI_ROCKCHIP=y


MMC relate driver should removed


Thanks,
- Kever

+CONFIG_SPI_FLASH_SFDP_SUPPORT=y
+CONFIG_SPI_FLASH_GIGADEVICE=y
+CONFIG_SPI_FLASH_MACRONIX=y
+CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_SPI_FLASH_XTX=y
+CONFIG_PHY_REALTEK=y
+CONFIG_DWC_ETH_QOS=y
+CONFIG_DWC_ETH_QOS_ROCKCHIP=y
+CONFIG_PHY_ROCKCHIP_INNO_USB2=y
+CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
+CONF

Re: [PATCH 1/1] efi_loader: pass end address to efi_dp_from_mem in efi_dp_from_name

[Moritz Fischer]

On Wed, Oct 30, 2024 at 2:02 PM Heinrich Schuchardt
 wrote:
>
> efi_dp_from_mem() expects the last parameter to be the end address and not
> the size.
>
> Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Moritz Fischer 

> ---
>  lib/efi_loader/efi_device_path.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_device_path.c 
> b/lib/efi_loader/efi_device_path.c
> index 9de3b95d073..d7444588aa0 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -1073,7 +1073,8 @@ efi_status_t efi_dp_from_name(const char *dev, const 
> char *devnr,
> efi_get_image_parameters(&image_addr, &image_size);
>
> dp = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
> -(uintptr_t)image_addr, image_size);
> +(uintptr_t)image_addr,
> +(uintptr_t)image_addr + image_size);
> } else if (IS_ENABLED(CONFIG_NETDEVICES) && !strcmp(dev, "Net")) {
> dp = efi_dp_from_eth();
> } else if (!strcmp(dev, "Uart")) {
> --
> 2.45.2
>

[PATCH 2/3] test: env: check that non-mentioned variables to "env default" are preserved

[Rasmus Villemoes]

Instead of testing the same expected behaviour for both
non_default_varX, test that when var1 is not in the default env but is
mentioned in the "env default" cmdline, it is removed, while var2 is
untouched.

Signed-off-by: Rasmus Villemoes 
---
 test/env/cmd_ut_env.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/test/env/cmd_ut_env.c b/test/env/cmd_ut_env.c
index 4af05764fb8..e1dd1a14cb0 100644
--- a/test/env/cmd_ut_env.c
+++ b/test/env/cmd_ut_env.c
@@ -14,22 +14,21 @@ static int env_test_env_cmd(struct unit_test_state *uts)
ut_assertok(run_command("setenv non_default_var1 1", 0));
ut_assert_console_end();
 
-   ut_assertok(run_command("setenv non_default_var2 1", 0));
+   ut_assertok(run_command("setenv non_default_var2 2", 0));
ut_assert_console_end();
 
ut_assertok(run_command("env print non_default_var1", 0));
ut_assert_nextline("non_default_var1=1");
ut_assert_console_end();
 
-   ut_assertok(run_command("env default non_default_var1 
non_default_var2", 0));
+   ut_assertok(run_command("env default non_default_var1", 0));
ut_assert_nextline("WARNING: 'non_default_var1' not in imported env, 
deleting it!");
-   ut_assert_nextline("WARNING: 'non_default_var2' not in imported env, 
deleting it!");
ut_assert_console_end();
 
ut_asserteq(1, run_command("env exists non_default_var1", 0));
ut_assert_console_end();
 
-   ut_asserteq(1, run_command("env exists non_default_var2", 0));
+   ut_asserteq(0, run_command("env exists non_default_var2", 0));
ut_assert_console_end();
 
return 0;
-- 
2.47.0

Re: [PATCH] arm: mach-k3: am62a7: Provide a way to obtain boot device for non SPLs

[Bryan Brattlof]

Hi Garrett!

On October 30, 2024 thus sayeth Garrett Giordano:
> Introduce get_boot_device() to obtain the booting device. Make it also
> available for non SPL builds so u-boot can also know the device it
> is booting from.
> 

All looks good but I'm trying to understand the scenario. Are we using a 
bare-metal boot loader in tiboot3 then packaging U-Boot proper with TF-A 
and OP-TEE in next phase after DRAM is up?

> Signed-off-by: Garrett Giordano 
> ---
>  arch/arm/mach-k3/Makefile |   1 +
>  arch/arm/mach-k3/am62ax/Makefile  |   1 +
>  arch/arm/mach-k3/am62ax/am62a7_init.c |  97 +--
>  arch/arm/mach-k3/am62ax/boot.c| 106 ++
>  4 files changed, 109 insertions(+), 96 deletions(-)
>  create mode 100644 arch/arm/mach-k3/am62ax/boot.c
> 
> diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> index 8c4f6786a5b..ce09a30e58f 100644
> --- a/arch/arm/mach-k3/Makefile
> +++ b/arch/arm/mach-k3/Makefile
> @@ -10,6 +10,7 @@ obj-y += common.o security.o
>  obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/
>  obj-$(CONFIG_SOC_K3_AM62P5) += am62px/
>  obj-$(CONFIG_SOC_K3_AM625) += am62x/
> +obj-$(CONFIG_SOC_K3_AM62A7) += am62ax/

Yeah I don't know how we treat 'x' here when alphabetizing things. Do we 
treat it like a literal 'x' or is that just a regex alias for .+ IDK.

Anywho, it looks like we created a second entry accidentally. But the 
substance of the patch is sound.

Reviewed-by: Bryan Brattlof 

~Bryan

Re: [PATCH v2] lib: efi_loader: Fix efi_dp_from_mem() calls

[Patrick Wildt]

On Wed, Oct 30, 2024 at 10:18 PM Moritz Fischer  wrote:

> The function expects an end address but is being called with
> an size instead.
>
> Fixes: 6422820ac3 ("efi_loader: split unrelated code from efi_bootmgr.c")
> Reviewed-by: Heinrich Schuchardt 
> Reviewed-by: Ilias Apalodimas 
> Signed-off-by: Moritz Fischer 
> ---
>
> Changes from v1:
> - Fixed second callsite
> - Remove superfluous cast
>
> ---
>  lib/efi_loader/efi_bootbin.c | 1 +
>  lib/efi_loader/efi_device_path.c | 3 ++-
>  2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
> index a87006b3c0..bf38392fac 100644
> --- a/lib/efi_loader/efi_bootbin.c
> +++ b/lib/efi_loader/efi_bootbin.c
> @@ -137,6 +137,7 @@ efi_status_t efi_run_image(void *source_buffer,
> efi_uintn_t source_size)
>  */
> file_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
> (uintptr_t)source_buffer,
> +   (uintptr_t)source_buffer +
> source_size);
> /*
>  * Make sure that device for device_path exist
> diff --git a/lib/efi_loader/efi_device_path.c
> b/lib/efi_loader/efi_device_path.c
> index 9de3b95d07..d7444588aa 100644
> --- a/lib/efi_loader/efi_device_path.c
> +++ b/lib/efi_loader/efi_device_path.c
> @@ -1073,7 +1073,8 @@ efi_status_t efi_dp_from_name(const char *dev, const
> char *devnr,
> efi_get_image_parameters(&image_addr, &image_size);
>
> dp = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
> -(uintptr_t)image_addr, image_size);
> +(uintptr_t)image_addr,
> +(uintptr_t)image_addr + image_size);
> } else if (IS_ENABLED(CONFIG_NETDEVICES) && !strcmp(dev, "Net")) {
> dp = efi_dp_from_eth();
> } else if (!strcmp(dev, "Uart")) {
> --
> 2.47.0.163.g1226f6d8fa-goog
>
>
Looks good to me, thanks!

Reviewed-by: Patrick Wildt 

[PATCH 1/1] efi_loader: pass end address to efi_dp_from_mem in efi_dp_from_name

[Heinrich Schuchardt]

efi_dp_from_mem() expects the last parameter to be the end address and not
the size.

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_device_path.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 9de3b95d073..d7444588aa0 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -1073,7 +1073,8 @@ efi_status_t efi_dp_from_name(const char *dev, const char 
*devnr,
efi_get_image_parameters(&image_addr, &image_size);
 
dp = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
-(uintptr_t)image_addr, image_size);
+(uintptr_t)image_addr,
+(uintptr_t)image_addr + image_size);
} else if (IS_ENABLED(CONFIG_NETDEVICES) && !strcmp(dev, "Net")) {
dp = efi_dp_from_eth();
} else if (!strcmp(dev, "Uart")) {
-- 
2.45.2

[PATCH 3/3] test: env: add some test cases for new "env default -k" flag

[Rasmus Villemoes]

Check that the new -k flag works as expected.

This also adds a test of the -a flag, which was previously missing,
and as the comment says, perhaps for a good reason. At least now we
have a test for it in combination with -k (and -f, because the ethaddr
variables otherwise cause complaining).

Signed-off-by: Rasmus Villemoes 
---
 test/env/cmd_ut_env.c | 40 
 1 file changed, 40 insertions(+)

diff --git a/test/env/cmd_ut_env.c b/test/env/cmd_ut_env.c
index e1dd1a14cb0..9f16a978f2a 100644
--- a/test/env/cmd_ut_env.c
+++ b/test/env/cmd_ut_env.c
@@ -31,6 +31,46 @@ static int env_test_env_cmd(struct unit_test_state *uts)
ut_asserteq(0, run_command("env exists non_default_var2", 0));
ut_assert_console_end();
 
+   ut_assertok(run_command("setenv non_default_var1 3", 0));
+   ut_assert_console_end();
+
+   ut_assertok(run_command("env default -k non_default_var1", 0));
+   ut_assert_console_end();
+
+   ut_asserteq(0, run_command("env exists non_default_var1", 0));
+   ut_assert_console_end();
+
+   ut_asserteq(0, run_command("env exists non_default_var2", 0));
+   ut_assert_console_end();
+
+   ut_assertok(run_command("env default -k -a -f", 0));
+   ut_assert_nextline("## Resetting to default environment");
+   ut_assert_console_end();
+
+   ut_asserteq(0, run_command("env exists non_default_var1", 0));
+   ut_assert_console_end();
+
+   ut_asserteq(0, run_command("env exists non_default_var2", 0));
+   ut_assert_console_end();
+
+   /*
+* While the following test of "env default -a" by itself
+* works, it unfortunately causes an unrelated test case,
+* env_test_fdt_import(), to fail, because the "from_fdt"
+* variable would be removed.
+*/
+#if 0
+   ut_assertok(run_command("env default -a", 0));
+   ut_assert_nextline("## Resetting to default environment");
+   ut_assert_console_end();
+
+   ut_asserteq(1, run_command("env exists non_default_var1", 0));
+   ut_assert_console_end();
+
+   ut_asserteq(1, run_command("env exists non_default_var2", 0));
+   ut_assert_console_end();
+#endif
+
return 0;
 }
 ENV_TEST(env_test_env_cmd, UTF_CONSOLE);
-- 
2.47.0

[PATCH 0/3] teach 'env default' to optionally keep runtime variables

[Rasmus Villemoes]

Doing bringup of a board, part of my bootstrap logic is in U-Boot. So
when tweaking that logic, I was bitten by a previous completed
bootstrap having left a copy of the environment on the device, which
was imported and thus overrided the new logic.

So I thought, "ok, I'll just make sure to put 'env default -a' as the
first part of the bootstrap logic so I'm not bitten again". Alas, my
logic also relies on certain variables that are set by C code
(e.g. for detecting board variant), and doing 'env default -a' also
eliminates those.

Looking around, the hashtab code already supports a flag that does
exactly what I need, and exposing that is (morally) a one-liner.

Rasmus Villemoes (3):
  cmd/nvedit.c: teach 'env default' to optionally keep runtime variables
  test: env: check that non-mentioned variables to "env default" are
preserved
  test: env: add some test cases for new "env default -k" flag

 cmd/nvedit.c  |  8 ++--
 test/env/cmd_ut_env.c | 45 ---
 2 files changed, 48 insertions(+), 5 deletions(-)

-- 
2.47.0

Re: [PATCH v2 2/2] rockchip: add support for Radxa ROCK 5A with SPI NOR flash module

[FUKAUMI Naoki]

Hi,

On 10/30/24 19:39, Quentin Schulz wrote:

Hi Naoki,

On 10/30/24 4:09 AM, FUKAUMI Naoki wrote:

Hi,

could you review this patch, anyone?

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.

On 8/25/24 07:33, FUKAUMI Naoki wrote:

on Radxa ROCK 5A, sdhci(eMMC) and fspim0(SPI NOR flash) share pins
(i.e. eMMC and SPI NOR flash are exclusive), new defconfig and dts
specifically for SPI NOR flash is required.

Signed-off-by: FUKAUMI Naoki 
---
Changes in v2
- fix subject
---
  arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi | 24 ++
  arch/arm/dts/rk3588s-rock-5a-spi.dts |  4 +
  board/radxa/rock5a-rk3588s/MAINTAINERS   |  5 +-
  configs/rock5a-spi-rk3588s_defconfig | 83 
  4 files changed, 113 insertions(+), 3 deletions(-)
  create mode 100644 arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi
  create mode 100644 arch/arm/dts/rk3588s-rock-5a-spi.dts
  create mode 100644 configs/rock5a-spi-rk3588s_defconfig

diff --git a/arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi b/arch/arm/ 
dts/rk3588s-rock-5a-spi-u-boot.dtsi

new file mode 100644
index 000..5cd131d3cb1
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-spi-u-boot.dtsi
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2023 Collabora Ltd.
+ */
+
+#include "rk3588s-u-boot.dtsi"
+
+&fspim0_pins {
+    bootph-pre-ram;
+    bootph-some-ram;
+};
+
+&sdhci {
+    status = "disabled";
+};
+
+&sfc {
+    status = "okay";
+
+    flash@0 {
+    bootph-pre-ram;
+    bootph-some-ram;
+    };
+};


I assume the board can only be fitted with an SPI NOR or an eMMC and not 
both at the same time? If that's the case, then the status = disabled 
and status = okay should be in the dts. I assume we want this to be in 
the Linux kernel first too, either as a separate DTS or with a DTSO (not 
sure what they will want).


maybe it's time to update this patch.

https://patchwork.kernel.org/project/linux-rockchip/patch/20230913064505.77393-2-na...@radxa.com/

rock-5a-base.dtsi (common part)
rock-5a.dts (same as current one)
rock-5a-spi-dts

diff --git a/arch/arm/dts/rk3588s-rock-5a-spi.dts b/arch/arm/dts/ 
rk3588s-rock-5a-spi.dts

new file mode 100644
index 000..780e90d041b
--- /dev/null
+++ b/arch/arm/dts/rk3588s-rock-5a-spi.dts
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include "rk3588s-rock-5a.dts"
diff --git a/board/radxa/rock5a-rk3588s/MAINTAINERS b/board/radxa/ 
rock5a-rk3588s/MAINTAINERS

index a569efa74e3..06ebc9829f4 100644
--- a/board/radxa/rock5a-rk3588s/MAINTAINERS
+++ b/board/radxa/rock5a-rk3588s/MAINTAINERS
@@ -4,6 +4,5 @@ R:    Jonas Karlman 
  S:    Maintained
  F:    board/radxa/rock5a-rk3588s
  F:    include/configs/rock5a-rk3588s.h
-F:    configs/rock5a-rk3588s_defconfig
-F:    arch/arm/dts/rk3588s-rock-5a.dts
-F:    arch/arm/dts/rk3588s-rock-5a-u-boot.dtsi
+F:    configs/rock5a*
+F:    arch/arm/dts/rk3588s-rock-5a*
diff --git a/configs/rock5a-spi-rk3588s_defconfig b/configs/rock5a- 
spi-rk3588s_defconfig

new file mode 100644
index 000..297278c7a06
--- /dev/null
+++ b/configs/rock5a-spi-rk3588s_defconfig


If Radxa starts having many such options, maybe it won't make a lot of 
sense to duplicate configs but rather have config fragments to change 
the default DT and add a few symbols that differ from the base (I assume 
we may have something similar needed for rock 5b+ compared to rock5b for 
example?


I'm thinking doing same for ROCK 5C...

https://github.com/RadxaNaoki/u-boot/commits/rock-5c/

Keeping all configs in sync for essentially same board with small 
differences may be difficult, maybe using config fragments will help?


any "config fragments" doc/example?

Best regards,

--
FUKAUMI Naoki
Radxa Computer (Shenzhen) Co., Ltd.


@@ -0,0 +1,83 @@
+CONFIG_ARM=y
+CONFIG_SKIP_LOWLEVEL_INIT=y
+CONFIG_COUNTER_FREQUENCY=2400
+CONFIG_ARCH_ROCKCHIP=y
+CONFIG_SF_DEFAULT_SPEED=2400
+CONFIG_SF_DEFAULT_MODE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="rk3588s-rock-5a-spi"
+CONFIG_ROCKCHIP_RK3588=y
+CONFIG_ROCKCHIP_SPI_IMAGE=y
+CONFIG_SPL_SERIAL=y
+CONFIG_TARGET_ROCK5A_RK3588=y
+CONFIG_DEBUG_UART_BASE=0xFEB5
+CONFIG_DEBUG_UART_CLOCK=2400
+CONFIG_SPL_SPI_FLASH_SUPPORT=y
+CONFIG_SPL_SPI=y
+CONFIG_SYS_LOAD_ADDR=0xc00800
+CONFIG_DEBUG_UART=y
+CONFIG_FIT=y
+CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_FIT_SIGNATURE=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_LEGACY_IMAGE_FORMAT=y
+CONFIG_DEFAULT_FDT_FILE="rockchip/rk3588s-rock-5a.dtb"
+# CONFIG_DISPLAY_CPUINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
+CONFIG_SPL_MAX_SIZE=0x4
+CONFIG_SPL_PAD_TO=0x7f8000
+# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set
+CONFIG_SPL_SPI_LOAD=y
+CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
+CONFIG_SPL_ATF=y
+CONFIG_CMD_GPIO=y
+CONFIG_CMD_GPT=y
+CONFIG_CMD_I2C=y
+CONFIG_CMD_MMC=y
+CONFIG_CMD_USB=y
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_REGULATOR=y
+# CONFIG_SPL_DOS_PARTITION is not set
+CONFIG_SPL_OF_CONTROL=y
+CONFIG_OF_LIVE=y
+# CONFIG_OF_UPSTREAM is not s

[PATCH v2] lib: efi_loader: Fix efi_dp_from_mem() calls

[Moritz Fischer]

The function expects an end address but is being called with
an size instead.

Fixes: 6422820ac3 ("efi_loader: split unrelated code from efi_bootmgr.c")
Reviewed-by: Heinrich Schuchardt 
Reviewed-by: Ilias Apalodimas 
Signed-off-by: Moritz Fischer 
---

Changes from v1:
- Fixed second callsite
- Remove superfluous cast

---
 lib/efi_loader/efi_bootbin.c | 1 +
 lib/efi_loader/efi_device_path.c | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
index a87006b3c0..bf38392fac 100644
--- a/lib/efi_loader/efi_bootbin.c
+++ b/lib/efi_loader/efi_bootbin.c
@@ -137,6 +137,7 @@ efi_status_t efi_run_image(void *source_buffer, efi_uintn_t 
source_size)
 */
file_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
(uintptr_t)source_buffer,
+   (uintptr_t)source_buffer +
source_size);
/*
 * Make sure that device for device_path exist
diff --git a/lib/efi_loader/efi_device_path.c b/lib/efi_loader/efi_device_path.c
index 9de3b95d07..d7444588aa 100644
--- a/lib/efi_loader/efi_device_path.c
+++ b/lib/efi_loader/efi_device_path.c
@@ -1073,7 +1073,8 @@ efi_status_t efi_dp_from_name(const char *dev, const char 
*devnr,
efi_get_image_parameters(&image_addr, &image_size);
 
dp = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
-(uintptr_t)image_addr, image_size);
+(uintptr_t)image_addr,
+(uintptr_t)image_addr + image_size);
} else if (IS_ENABLED(CONFIG_NETDEVICES) && !strcmp(dev, "Net")) {
dp = efi_dp_from_eth();
} else if (!strcmp(dev, "Uart")) {
-- 
2.47.0.163.g1226f6d8fa-goog

[PATCH 1/3] configs: rockchip: enable RK806 SPI PMIC for Radxa ROCK 5A

[FUKAUMI Naoki]

enable RK806 SPI PMIC driver and related cmd/configs for Radxa ROCK 5A.

Signed-off-by: FUKAUMI Naoki 
---
 configs/rock5a-rk3588s_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/rock5a-rk3588s_defconfig b/configs/rock5a-rk3588s_defconfig
index 9618d590009..d2770198ef2 100644
--- a/configs/rock5a-rk3588s_defconfig
+++ b/configs/rock5a-rk3588s_defconfig
@@ -28,6 +28,7 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 # CONFIG_SPL_DOS_PARTITION is not set
 CONFIG_SPL_OF_CONTROL=y
@@ -55,11 +56,16 @@ CONFIG_PHY_ROCKCHIP_INNO_USB2=y
 CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
 CONFIG_PHY_ROCKCHIP_USBDP=y
 CONFIG_SPL_PINCTRL=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_SPL_PMIC_RK8XX=y
+CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_SPL_RAM=y
 CONFIG_BAUDRATE=150
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550_MEM32=y
+CONFIG_ROCKCHIP_SPI=y
 CONFIG_SYSRESET=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
-- 
2.43.0

[PATCH 3/3] configs: rockchip: enable RK806 SPI PMIC for Radxa ROCK 5B

[FUKAUMI Naoki]

enable RK806 SPI PMIC driver and related cmd/configs for Radxa ROCK 5B.

Signed-off-by: FUKAUMI Naoki 
---
 configs/rock5b-rk3588_defconfig | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index 47ee2109f8e..cf10965cf0f 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -44,6 +44,7 @@ CONFIG_CMD_USB=y
 CONFIG_CMD_ROCKUSB=y
 CONFIG_CMD_USB_MASS_STORAGE=y
 # CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_PMIC=y
 CONFIG_CMD_REGULATOR=y
 # CONFIG_SPL_DOS_PARTITION is not set
 CONFIG_SPL_OF_CONTROL=y
@@ -78,6 +79,10 @@ CONFIG_PHY_ROCKCHIP_INNO_USB2=y
 CONFIG_PHY_ROCKCHIP_NANENG_COMBOPHY=y
 CONFIG_PHY_ROCKCHIP_USBDP=y
 CONFIG_SPL_PINCTRL=y
+CONFIG_DM_PMIC=y
+CONFIG_PMIC_RK8XX=y
+CONFIG_SPL_PMIC_RK8XX=y
+CONFIG_REGULATOR_RK8XX=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_SPL_RAM=y
 CONFIG_SCSI=y
@@ -85,6 +90,7 @@ CONFIG_BAUDRATE=150
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550_MEM32=y
 CONFIG_ROCKCHIP_SFC=y
+CONFIG_ROCKCHIP_SPI=y
 CONFIG_SYSRESET=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
-- 
2.43.0

[PATCH 2/3] configs: rockchip: run savedefconfig for TCPM related configs for Radxa ROCK 5B

[FUKAUMI Naoki]

run savedefconfig for next patch for Radxa ROCK 5B.

Signed-off-by: FUKAUMI Naoki 
---
 configs/rock5b-rk3588_defconfig | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/configs/rock5b-rk3588_defconfig b/configs/rock5b-rk3588_defconfig
index c54e13e8732..47ee2109f8e 100644
--- a/configs/rock5b-rk3588_defconfig
+++ b/configs/rock5b-rk3588_defconfig
@@ -34,6 +34,7 @@ CONFIG_SPL_PAD_TO=0x7f8000
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x6
 CONFIG_SPL_ATF=y
+CONFIG_CMD_TCPM=y
 CONFIG_CMD_GPIO=y
 CONFIG_CMD_GPT=y
 CONFIG_CMD_I2C=y
@@ -94,6 +95,8 @@ CONFIG_USB_OHCI_GENERIC=y
 CONFIG_USB_DWC3=y
 CONFIG_USB_DWC3_GENERIC=y
 CONFIG_SPL_USB_DWC3_GENERIC=y
+CONFIG_TYPEC_TCPM=y
+CONFIG_TYPEC_FUSB302=y
 CONFIG_USB_HOST_ETHER=y
 CONFIG_USB_ETHER_ASIX=y
 CONFIG_USB_ETHER_ASIX88179=y
@@ -106,6 +109,3 @@ CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_USB_FUNCTION_ROCKUSB=y
 CONFIG_ERRNO_STR=y
-CONFIG_TYPEC_TCPM=y
-CONFIG_TYPEC_FUSB302=y
-CONFIG_CMD_TCPM=y
-- 
2.43.0

Re: [PATCH] lib: efi_loader: Fix efi_dp_from_mem() call

[Moritz Fischer]

On Wed, Oct 30, 2024 at 10:28:40PM GMT, Ilias Apalodimas wrote:

Hi Moritz



Thanks for the patch



On Wed, 30 Oct 2024 at 22:16, Moritz Fischer  wrote:
>
> The function expects an end address but is being called with
> an size instead.
>
> Fixes: 6422820ac3 ("efi_loader: split unrelated code from  
efi_bootmgr.c")

> Signed-off-by: Moritz Fischer 
> ---
>  lib/efi_loader/efi_bootbin.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_bootbin.c b/lib/efi_loader/efi_bootbin.c
> index a87006b3c0..798bcd6eee 100644
> --- a/lib/efi_loader/efi_bootbin.c
> +++ b/lib/efi_loader/efi_bootbin.c
> @@ -137,7 +137,8 @@ efi_status_t efi_run_image(void *source_buffer,  
efi_uintn_t source_size)

>  */
> file_path = efi_dp_from_mem(EFI_RESERVED_MEMORY_TYPE,
> (uintptr_t)source_buffer,
> -   source_size);
> +   (uintptr_t)source_buffer +
> +   (size_t)source_size);



Yes, the change is correct, but we don't need the cast.



With that changed
Reviewed-by: Ilias Apalodimas 


Ack. Will send a v2.



> /*
>  * Make sure that device for device_path exist
>  * in load_image(). Otherwise, shell and grub will fail.
> --
> 2.47.0.163.g1226f6d8fa-goog
>


Thanks,
Moritz

[PATCH] bios_emulator: fix first argument of pci_{read,write}_config_* function calls

[Yuri Zaporozhets]

When compiling for riscv64, a bunch of warning is produced for the file
drivers/bios_emulator/besys.c. This patch fixes a portion of those warnings,
caused by incorrect first argument to pci_{read,write}_config_* functions.

Signed-off-by: Yuri Zaporozhets 
---
 drivers/bios_emulator/besys.c | 20 
 1 file changed, 8 insertions(+), 12 deletions(-)

diff --git a/drivers/bios_emulator/besys.c b/drivers/bios_emulator/besys.c
index 2fd794f76c..c6c5b7ed44 100644
--- a/drivers/bios_emulator/besys.c
+++ b/drivers/bios_emulator/besys.c
@@ -49,6 +49,7 @@
 
 #define __io
 #include 
+#include 
 #include "biosemui.h"
 
 /*- Global Variables --*/
@@ -434,32 +435,27 @@ static u32 BE_accessReg(int regOffset, u32 value, int 
func)
if ((function == _BE_env.vgaInfo.function) &&
(device == _BE_env.vgaInfo.device) &&
(bus == _BE_env.vgaInfo.bus)) {
+pci_dev_t bdf = PCI_BDF(bus, device, function);
switch (func) {
case REG_READ_BYTE:
-   pci_read_config_byte(_BE_env.vgaInfo.pcidev, regOffset,
-&val8);
+   pci_read_config_byte(bdf, regOffset, &val8);
return val8;
case REG_READ_WORD:
-   pci_read_config_word(_BE_env.vgaInfo.pcidev, regOffset,
-&val16);
+   pci_read_config_word(bdf, regOffset, &val16);
return val16;
case REG_READ_DWORD:
-   pci_read_config_dword(_BE_env.vgaInfo.pcidev, regOffset,
- &val32);
+   pci_read_config_dword(bdf, regOffset, &val32);
return val32;
case REG_WRITE_BYTE:
-   pci_write_config_byte(_BE_env.vgaInfo.pcidev, regOffset,
- value);
+   pci_write_config_byte(bdf, regOffset, value);
 
return 0;
case REG_WRITE_WORD:
-   pci_write_config_word(_BE_env.vgaInfo.pcidev, regOffset,
- value);
+   pci_write_config_word(bdf, regOffset, value);
 
return 0;
case REG_WRITE_DWORD:
-   pci_write_config_dword(_BE_env.vgaInfo.pcidev,
-  regOffset, value);
+   pci_write_config_dword(bdf, regOffset, value);
 
return 0;
}
-- 
2.39.5

Re: [PATCH] lmb: Correctly unmap memory after notifications

[Tom Rini]

On Thu, 24 Oct 2024 13:46:25 +0300, Ilias Apalodimas wrote:

> We never unmap the memory used to update the EFI memory map after
> notifications
> 
> 

Applied to u-boot/master, thanks!

-- 
Tom

Re: [PATCH] MAINTAINERS: add tambarus as reviewer for SPI NOR

[Tom Rini]

On Wed, 30 Oct 2024 11:02:21 +, Tudor Ambarus wrote:

> I'd like to get Cc'ed to u-boot's SPI NOR patches to help review them.
> The ultimate goal is to have an aligned approach in u-boot and linux.
> 
> 

Applied to u-boot/master, thanks!

-- 
Tom

Re: [PATCH] boot/Kconfig: correct fdt_fixup_memory_banks name typo

[Tom Rini]

On Mon, 28 Oct 2024 18:44:35 +0200, Baruch Siach wrote:

> 


Applied to u-boot/master, thanks!

-- 
Tom

Re: [PATCH] arch: arm: dts: k3-j784s4-r5: Introduce k3-j784s4-r5.dtsi

[Tom Rini]

On Thu, 24 Oct 2024 15:30:04 +0530, Manorit Chawdhry wrote:

> Create an SoC R5 dtsi file that could be used at board level R5 files. This
> would help in keeping the SoC level changes in sync across board files.
> 
> 

Applied to u-boot/master, thanks!

-- 
Tom

Re: [PATCH] scripts/dtc/pylibfdt/libfdt.i_shipped: Use SWIG_AppendOutput

[Tom Rini]

On Wed, 30 Oct 2024 06:07:16 +0100, Markus Volk wrote:

> Swig has changed language specific AppendOutput functions. The helper
> macro SWIG_AppendOutput remains unchanged. Use that instead
> of SWIG_Python_AppendOutput, which would require an extra parameter
> since swig 4.3.0.
> 
> /home/flk/poky/build-test/tmp/work/qemux86_64-poky-linux/u-boot/2024.10/git/arch/x86/cpu/u-boot-64.lds
> | scripts/dtc/pylibfdt/libfdt_wrap.c: In function ‘_wrap_fdt_next_node’:
> | scripts/dtc/pylibfdt/libfdt_wrap.c:5581:17: error: too few arguments to 
> function ‘SWIG_Python_AppendOutput’
> |  5581 | resultobj = SWIG_Python_AppendOutput(resultobj, val);
> |   | ^~~~
> 
> [...]

Applied to u-boot/master, thanks!

-- 
Tom

Re: [PATCH v8 2/8] efi_loader: Add a test app

[Simon Glass]

Hi Tom,

On Tue, 29 Oct 2024 at 17:46, Tom Rini  wrote:
>
> On Tue, Oct 29, 2024 at 04:46:16PM +0100, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 28 Oct 2024 at 19:43, Heinrich Schuchardt  
> > wrote:
> > >
> > > On 10/28/24 18:00, Simon Glass wrote:
> > > > Hi Heinrich,
> > > >
> > > > On Mon, 28 Oct 2024 at 07:11, Heinrich Schuchardt  > > > > wrote:
> > > >  >
> > > >  > On 10/22/24 14:00, Simon Glass wrote:
> > > >  > > Add a simple app to use for testing. This is intended to do 
> > > > whatever it
> > > >  > > needs to for testing purposes. For now it just prints a message and
> > > >  > > exits boot services.
> > > >  > >
> > > >  > > There was a considerable amount of discussion about whether it is 
> > > > OK to
> > > >  > > call exit-boot-services and then return to U-Boot. This is not 
> > > > normally
> > > >  > > done in a real application, since exit-boot-services is used to
> > > >  > > completely disconnect from U-Boot. However, since this is a test, 
> > > > we
> > > >  > > need to check the results of running the app, so returning is
> > > > necessary.
> > > >  > > It works correctly and it provides a nice model of how to test the 
> > > > EFI
> > > >  > > code in a simple way.
> > > >  > >
> > > >  > > Signed-off-by: Simon Glass  > > > >
> > > >  > > ---
> > > >  > >
> > > >  > > (no changes since v7)
> > > >  > >
> > > >  > > Changes in v7:
> > > >  > > - Update commit message
> > > >  > >
> > > >  > >   lib/efi_loader/Kconfig   | 10 ++
> > > >  > >   lib/efi_loader/Makefile  |  1 +
> > > >  > >   lib/efi_loader/testapp.c | 68 +++
> > > > +
> > > >  > >   3 files changed, 79 insertions(+)
> > > >  > >   create mode 100644 lib/efi_loader/testapp.c
> > > >  > >
> > > >  > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > > >  > > index 69b2c9360d8..6ced29da719 100644
> > > >  > > --- a/lib/efi_loader/Kconfig
> > > >  > > +++ b/lib/efi_loader/Kconfig
> > > >  > > @@ -565,6 +565,16 @@ config BOOTEFI_HELLO_COMPILE
> > > >  > > No additional space will be required in the resulting U-
> > > > Boot binary
> > > >  > > when this option is enabled.
> > > >  > >
> > > >  > > +config BOOTEFI_TESTAPP_COMPILE
> > > >  > > + bool "Compile an EFI test app for testing"
> > > >  > > + default y
> > > >  > > + help
> > > >  > > +   This compiles an app designed for testing. It is packed
> > > > into an image
> > > >  > > +   by the test.py testing frame in the setup_efi_image() 
> > > > function.
> > > >  > > +
> > > >  > > +   No additional space will be required in the resulting U-
> > > > Boot binary
> > > >  > > +   when this option is enabled.
> > > >  > > +
> > > >  > >   endif
> > > >  > >
> > > >  > >   source "lib/efi/Kconfig"
> > > >  > > diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
> > > >  > > index 00d18966f9e..87131ab911d 100644
> > > >  > > --- a/lib/efi_loader/Makefile
> > > >  > > +++ b/lib/efi_loader/Makefile
> > > >  > > @@ -20,6 +20,7 @@ apps-$(CONFIG_EFI_LOAD_FILE2_INITRD) += 
> > > > initrddump
> > > >  > >   ifeq ($(CONFIG_GENERATE_ACPI_TABLE),)
> > > >  > >   apps-y += dtbdump
> > > >  > >   endif
> > > >  > > +apps-$(CONFIG_BOOTEFI_TESTAPP_COMPILE) += testapp
> > > >  > >
> > > >  > >   obj-$(CONFIG_CMD_BOOTEFI_HELLO) += helloworld_efi.o
> > > >  > >   obj-$(CONFIG_EFI_BOOTMGR) += efi_bootmgr.o
> > > >  > > diff --git a/lib/efi_loader/testapp.c b/lib/efi_loader/testapp.c
> > > >  > > new file mode 100644
> > > >  > > index 000..feb444c92e9
> > > >  > > --- /dev/null
> > > >  > > +++ b/lib/efi_loader/testapp.c
> > > >  > > @@ -0,0 +1,68 @@
> > > >  > > +// SPDX-License-Identifier: GPL-2.0+
> > > >  >
> > > >  > This is not a valid SPDX identifier. Please, use GPL-2.0-or-later.
> > > >  >
> > > >  > > +/*
> > > >  > > + * Hello world EFI application
> > > >  > > + *
> > > >  > > + * Copyright 2024 Google LLC
> > > >  > > + * Written by Simon Glass  > > > >
> > > >  > > + *
> > > >  > > + * This test program is used to test the invocation of an EFI
> > > > application.
> > > >  > > + * It writes a few messages to the console and then exits boot
> > > > services
> > > >  > > + */
> > > >  > > +
> > > >  > > +#include 
> > > >  > > +
> > > >  > > +static const efi_guid_t loaded_image_guid =
> > > > EFI_LOADED_IMAGE_PROTOCOL_GUID;
> > > >  > > +
> > > >  > > +static struct efi_system_table *systable;
> > > >  > > +static struct efi_boot_services *boottime;
> > > >  > > +static struct efi_simple_text_output_protocol *con_out;
> > > >  > > +
> > > >  > > +/**
> > > >  > > + * efi_main() - entry point of the EFI application.
> > > >  > > + *
> > > >  > > + * @handle:  handle of the loaded image
> > > >  > > + * @systab:  system table
> > > >  > > + * Return:   status code
> > > >  > > + */
> > > >  > > +efi_status_t EFIAPI efi_main(efi_handle_t handle,
> > > >  > > +  

Re: [PATCH v8 5/8] sandbox: Report host default-filename in native mode

[Simon Glass]

Hi Tom,

On Tue, 29 Oct 2024 at 17:40, Tom Rini  wrote:
>
> On Tue, Oct 29, 2024 at 04:45:54PM +0100, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Mon, 28 Oct 2024 at 20:16, Heinrich Schuchardt  
> > wrote:
> > >
> > > On 10/25/24 11:56, Ilias Apalodimas wrote:
> > > > Hi Simon,
> > > >
> > > >
> > > > On Tue, 22 Oct 2024 at 15:00, Simon Glass  wrote:
> > > >>
> > > >> When the --native flag is given, pretend to be running the host
> > > >> architecture rather than sandbox.
> > > >>
> > > >> Add an 'efidebug filename' command to report it.
> > > >
> > > > Heinrich does this allow you to continue your testing in native archs?
> > > >
> > > >>
> > > >> Signed-off-by: Simon Glass 
> > > >> ---
> > > >>
> > > >> Changes in v8:
> > > >> - Add new patch to report host default-filename in native mode
> > > >>
> > > >>   boot/bootmeth_efi.c | 25 ++--
> > > >>   boot/efi_fname.c| 57 
> > > >> +
> > > >>   cmd/efidebug.c  | 25 
> > > >>   include/efi.h   | 25 
> > > >>   4 files changed, 94 insertions(+), 38 deletions(-)
> > > >>
> > > >> diff --git a/boot/bootmeth_efi.c b/boot/bootmeth_efi.c
> > > >> index 371b36d550b..f836aa655f5 100644
> > > >> --- a/boot/bootmeth_efi.c
> > > >> +++ b/boot/bootmeth_efi.c
> > > >> @@ -25,32 +25,11 @@
> > > >>
> > > >>   #define EFI_DIRNAME"/EFI/BOOT/"
> > > >>
> > > >> -static int get_efi_pxe_arch(void)
> > > >> -{
> > > >> -   /* 
> > > >> http://www.iana.org/assignments/dhcpv6-parameters/dhcpv6-parameters.xml
> > > >>  */
> > > >> -   if (IS_ENABLED(CONFIG_ARM64))
> > > >> -   return 0xb;
> > > >> -   else if (IS_ENABLED(CONFIG_ARM))
> > > >> -   return 0xa;
> > > >> -   else if (IS_ENABLED(CONFIG_X86_64))
> > > >> -   return 0x6;
> > > >> -   else if (IS_ENABLED(CONFIG_X86))
> > > >> -   return 0x7;
> > > >> -   else if (IS_ENABLED(CONFIG_ARCH_RV32I))
> > > >> -   return 0x19;
> > > >> -   else if (IS_ENABLED(CONFIG_ARCH_RV64I))
> > > >> -   return 0x1b;
> > > >> -   else if (IS_ENABLED(CONFIG_SANDBOX))
> > > >> -   return 0;   /* not used */
> > > >> -
> > > >> -   return -EINVAL;
> > > >> -}
> > > >> -
> > > >>   static int get_efi_pxe_vci(char *str, int max_len)
> > > >>   {
> > > >>  int ret;
> > > >>
> > > >> -   ret = get_efi_pxe_arch();
> > > >> +   ret = efi_get_pxe_arch();
> > > >>  if (ret < 0)
> > > >>  return ret;
> > > >>
> > > >> @@ -239,7 +218,7 @@ static int distro_efi_read_bootflow_net(struct 
> > > >> bootflow *bflow)
> > > >>  ret = get_efi_pxe_vci(str, sizeof(str));
> > > >>  if (ret)
> > > >>  return log_msg_ret("vci", ret);
> > > >> -   ret = get_efi_pxe_arch();
> > > >> +   ret = efi_get_pxe_arch();
> > > >>  if (ret < 0)
> > > >>  return log_msg_ret("arc", ret);
> > > >>  arch = ret;
> > > >> diff --git a/boot/efi_fname.c b/boot/efi_fname.c
> > > >> index a6b11383bba..790f9e2fa36 100644
> > > >> --- a/boot/efi_fname.c
> > > >> +++ b/boot/efi_fname.c
> > > >> @@ -9,29 +9,34 @@
> > > >>*/
> > > >>
> > > >>   #include 
> > > >> +#include 
> > > >>   #include 
> > > >>
> > > >> -#ifdef CONFIG_SANDBOX
> > > >> -
> > > >>   #if HOST_ARCH == HOST_ARCH_X86_64
> > > >> -#define BOOTEFI_NAME "BOOTX64.EFI"
> > > >> +#define HOST_BOOTEFI_NAME "BOOTX64.EFI"
> > > >> +#define HOST_PXE_ARCH 0x6
> > > >>   #elif HOST_ARCH == HOST_ARCH_X86
> > > >> -#define BOOTEFI_NAME "BOOTIA32.EFI"
> > > >> +#define HOST_BOOTEFI_NAME "BOOTIA32.EFI"
> > > >> +#define HOST_PXE_ARCH 0x7
> > > >>   #elif HOST_ARCH == HOST_ARCH_AARCH64
> > > >> -#define BOOTEFI_NAME "BOOTAA64.EFI"
> > > >> +#define HOST_BOOTEFI_NAME "BOOTAA64.EFI"
> > > >> +#define HOST_PXE_ARCH 0xb
> > > >>   #elif HOST_ARCH == HOST_ARCH_ARM
> > > >> -#define BOOTEFI_NAME "BOOTARM.EFI"
> > > >> +#define HOST_BOOTEFI_NAME "BOOTARM.EFI"
> > > >> +#define HOST_PXE_ARCH 0xa
> > > >>   #elif HOST_ARCH == HOST_ARCH_RISCV32
> > > >> -#define BOOTEFI_NAME "BOOTRISCV32.EFI"
> > > >> +#define HOST_BOOTEFI_NAME "BOOTRISCV32.EFI"
> > > >> +#define HOST_PXE_ARCH 0x19
> > > >>   #elif HOST_ARCH == HOST_ARCH_RISCV64
> > > >> -#define BOOTEFI_NAME "BOOTRISCV64.EFI"
> > > >> +#define HOST_BOOTEFI_NAME "BOOTRISCV64.EFI"
> > > >> +#define HOST_PXE_ARCH 0x1b
> > > >>   #else
> > > >> -#error Unsupported UEFI architecture
> > > >> +#error Unsupported Host architecture
> > > >>   #endif
> > > >>
> > > >> -#else
> > > >> -
> > > >> -#if defined(CONFIG_ARM64)
> > > >> +#if defined(CONFIG_SANDBOX)
> > > >> +#define BOOTEFI_NAME "BOOTSBOX.EFI"
> > > >> +#elif defined(CONFIG_ARM64)
> > > >>   #define BOOTEFI_NAME "BOOTAA64.EFI"
> > > >>   #elif defined(CONFIG_ARM)
> > > >>   #define BOOTEFI_NAME "BOOTARM.EFI"
> > > >> @@ -47,9 +52,31 @@
> > > >>   #error Unsupported UEFI architecture
> > >  >>   #

Re: [PATCH v2 4/5] arm: mach-k3: j721e-init.c: J7200: Add support for CONFIG_K3_OPP_LOW

[Manorit Chawdhry]

Hi Aniket,

On 15:40-20241029, Manorit Chawdhry wrote:
> Hi Aniket,
> 
> On 18:27-20241023, Aniket Limaye wrote:
> > From: Reid Tonking 
> > 
> > The default j7200 devicetree and k3_avs driver set 2GHz/1GHz frequency
> > for A72/MSMC clks and the OPP_NOM voltage.
> > 
> > J7200 SOCs may support OPP_LOW Operating Performance Point:
> > 1GHz/500MHz clks for A72/MSMC and OPP_LOW AVS voltage read from efuse.
> > 
> > Hence, add a config check to select OPP_LOW specs:
> > - Check if OPP_LOW AVS voltage read from efuse is valid.
> > - Update the clock frequencies in devicetree.
> > - Program the OPP_LOW AVS voltage for VDD_CPU.
> > 
> > Signed-off-by: Reid Tonking 
> > Signed-off-by: Aniket Limaye 
> > 
> > ---
> > v2:
> > - Fix indentation in fix_freq()
> > - Remove the efuse data check addition from this commit, as it's not
> >   related to adding support for CONFIG_K3_OPP_LOW. The same addition
> >   was moved to the previous patch in this series.
> > - Link to v1: 
> > https://lore.kernel.org/u-boot/20241017062911.2241167-5-a-lim...@ti.com/
> > ---
> >  arch/arm/mach-k3/j721e/j721e_init.c | 45 -
> >  1 file changed, 44 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/arm/mach-k3/j721e/j721e_init.c 
> > b/arch/arm/mach-k3/j721e/j721e_init.c
> > index e9ed8cb267c..de10517bb27 100644
> > --- a/arch/arm/mach-k3/j721e/j721e_init.c
> > +++ b/arch/arm/mach-k3/j721e/j721e_init.c
> > @@ -19,6 +19,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include "../sysfw-loader.h"
> >  #include "../common.h"
> > @@ -147,6 +148,32 @@ static void setup_navss_nb(void)
> > writel(NB_THREADMAP_BIT1, (uintptr_t)NAVSS0_NBSS_NB1_CFG_NB_THREADMAP);
> >  }
> >  
> > +int fix_freq(const void *fdt)

I think this can be static as well btw, maybe rename it to something
more descriptive as well. fdt_fixup_a72_clock_frequency?

> > +{
> > +   int node, ret;
> > +   u32 opp_low_freq[3];
> > +
> > +   node = fdt_node_offset_by_compatible(fdt, -1, "ti,am654-rproc");
> > +   if (node < 0) {
> > +   printf("%s: A72 not found\n", __func__);
> > +   return node;
> > +   }
> > +
> > +   /* j7200 opp low values according to data sheet */
> > +   opp_low_freq[0] = cpu_to_fdt32(10); /* 202-2 -> 
> > A72SS0_CORE0_0_ARM_CLK */
> > +   opp_low_freq[1] = cpu_to_fdt32(2); /* 61-1 -> GTC0_GTC_CLK */
> > +   opp_low_freq[2] = cpu_to_fdt32(5); /* 4-1 -> 
> > A72SS0_CORE0_MSMC_CLK */
> > +
> > +   ret = fdt_setprop((void *)fdt, node, "assigned-clock-rates",
> > + opp_low_freq, sizeof(opp_low_freq));
> > +   if (ret) {
> > +   printf("%s: Can not set value\n", __func__);
> > +   return ret;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> >  /*
> >   * This uninitialized global variable would normal end up in the .bss 
> > section,
> >   * but the .bss is cleared between writing and reading this variable, so 
> > move
> > @@ -301,8 +328,24 @@ void board_init_f(ulong dummy)
> >  #if defined(CONFIG_CPU_V7R) && defined(CONFIG_K3_AVS0)
> > ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(k3_avs),
> >   &dev);
> > -   if (ret)
> > +   if (!ret) {
> > +   if (IS_ENABLED(CONFIG_K3_OPP_LOW)) {
> 
> These ifs can be combined into one ig. 
> 
> > +   ret = k3_check_opp(dev, J721E_VDD_MPU, AM6_OPP_LOW);
> > +   if (!ret) {
> > +   ret = fix_freq(gd->fdt_blob);
> > +   if (ret)
> > +   printf("Failed to set OPP_LOW 
> > frequency\n");
> > +
> > +   ret = k3_avs_set_opp(dev, J721E_VDD_MPU, 
> > AM6_OPP_LOW);
> 
> Even if fix_freq fails, do we want to cascade and still run
> k3_avs_set_opp? Not sure what the best way to handle this is but seeing
> a lot of nesting so wondering if there is any better way to handle this
> control flow..

For this I think it might be a good idea to take this chunk out into
another function like setup_opp_low as well and keep it there, might be
more readable that way IMHO.

Regards,
Manorit

> 
> Also, better to print ret as well in these cases btw.
> 
> Regards,
> Manorit
> 
> > +   if (ret)
> > +   printf("Failed to set OPP_LOW 
> > voltage\n");
> > +   } else {
> > +   printf("Failed to enable K3_OPP_LOW\n");
> > +   }
> > +   }
> > +   } else {
> > printf("AVS init failed: %d\n", ret);
> > +   }
> >  #endif
> >  
> >  #if defined(CONFIG_K3_J721E_DDRSS)
> > -- 
> > 2.34.1
> > 

[PATCH] driver: sifive ccache: enable TRUNKCLOCKGATE and REGIONCLOCKGATE

[Nick Hu]

Enable the clock gating bit of ccache when the platform has the ccache0.

Signed-off-by: Nick Hu 
---
 drivers/cache/cache-sifive-ccache.c | 33 ++---
 1 file changed, 30 insertions(+), 3 deletions(-)

diff --git a/drivers/cache/cache-sifive-ccache.c 
b/drivers/cache/cache-sifive-ccache.c
index cc00b80f60b..2ff5ca701d6 100644
--- a/drivers/cache/cache-sifive-ccache.c
+++ b/drivers/cache/cache-sifive-ccache.c
@@ -14,8 +14,17 @@
 
 #define SIFIVE_CCACHE_WAY_ENABLE   0x008
 
+#define SIFIVE_CCACHE_TRUNKCLOCKGATE   0x1000
+#define SIFIVE_CCACHE_TRUNKCLOCKGATE_DISABLE   BIT(0)
+#define SIFIVE_CCACHE_REGIONCLOCKGATE_DISABLE  BIT(1)
+
 struct sifive_ccache {
void __iomem *base;
+   bool has_cg;
+};
+
+struct sifive_ccache_quirks {
+   bool has_cg;
 };
 
 static int sifive_ccache_enable(struct udevice *dev)
@@ -30,6 +39,14 @@ static int sifive_ccache_enable(struct udevice *dev)
 
writel(ways - 1, priv->base + SIFIVE_CCACHE_WAY_ENABLE);
 
+   if (priv->has_cg) {
+   /* enable clock gating bits */
+   config = readl(priv->base + SIFIVE_CCACHE_TRUNKCLOCKGATE);
+   config &= ~(SIFIVE_CCACHE_TRUNKCLOCKGATE_DISABLE |
+   SIFIVE_CCACHE_REGIONCLOCKGATE_DISABLE);
+   writel(config, priv->base + SIFIVE_CCACHE_TRUNKCLOCKGATE);
+   }
+
return 0;
 }
 
@@ -50,7 +67,9 @@ static const struct cache_ops sifive_ccache_ops = {
 static int sifive_ccache_probe(struct udevice *dev)
 {
struct sifive_ccache *priv = dev_get_priv(dev);
+   const struct sifive_ccache_quirks *quirk = (void 
*)dev_get_driver_data(dev);
 
+   priv->has_cg = quirk->has_cg;
priv->base = dev_read_addr_ptr(dev);
if (!priv->base)
return -EINVAL;
@@ -58,10 +77,18 @@ static int sifive_ccache_probe(struct udevice *dev)
return 0;
 }
 
+static const struct sifive_ccache_quirks fu540_ccache = {
+   .has_cg = false,
+};
+
+static const struct sifive_ccache_quirks ccache0 = {
+   .has_cg = true,
+};
+
 static const struct udevice_id sifive_ccache_ids[] = {
-   { .compatible = "sifive,fu540-c000-ccache" },
-   { .compatible = "sifive,fu740-c000-ccache" },
-   { .compatible = "sifive,ccache0" },
+   { .compatible = "sifive,fu540-c000-ccache", .data = 
(ulong)&fu540_ccache },
+   { .compatible = "sifive,fu740-c000-ccache", .data = 
(ulong)&fu540_ccache },
+   { .compatible = "sifive,ccache0", .data = (ulong)&ccache0 },
{}
 };
 
-- 
2.34.1

[PATCH] scripts/dtc/pylibfdt/libfdt.i_shipped: Use SWIG_AppendOutput

[Markus Volk]

Swig has changed language specific AppendOutput functions. The helper
macro SWIG_AppendOutput remains unchanged. Use that instead
of SWIG_Python_AppendOutput, which would require an extra parameter
since swig 4.3.0.

/home/flk/poky/build-test/tmp/work/qemux86_64-poky-linux/u-boot/2024.10/git/arch/x86/cpu/u-boot-64.lds
| scripts/dtc/pylibfdt/libfdt_wrap.c: In function ‘_wrap_fdt_next_node’:
| scripts/dtc/pylibfdt/libfdt_wrap.c:5581:17: error: too few arguments to 
function ‘SWIG_Python_AppendOutput’
|  5581 | resultobj = SWIG_Python_AppendOutput(resultobj, val);
|   | ^~~~

Signed-off-by: Markus Volk 
---
 scripts/dtc/pylibfdt/libfdt.i_shipped | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/dtc/pylibfdt/libfdt.i_shipped 
b/scripts/dtc/pylibfdt/libfdt.i_shipped
index 56cc5d48f4..e4659489a9 100644
--- a/scripts/dtc/pylibfdt/libfdt.i_shipped
+++ b/scripts/dtc/pylibfdt/libfdt.i_shipped
@@ -1037,7 +1037,7 @@ typedef uint32_t fdt32_t;
fdt_string(fdt1, fdt32_to_cpu($1->nameoff)));
buff = PyByteArray_FromStringAndSize(
(const char *)($1 + 1), fdt32_to_cpu($1->len));
-   resultobj = SWIG_Python_AppendOutput(resultobj, buff);
+   resultobj = SWIG_AppendOutput(resultobj, buff);
}
 }
 
@@ -1076,7 +1076,7 @@ typedef uint32_t fdt32_t;
 
 %typemap(argout) int *depth {
 PyObject *val = Py_BuildValue("i", *arg$argnum);
-resultobj = SWIG_Python_AppendOutput(resultobj, val);
+resultobj = SWIG_AppendOutput(resultobj, val);
 }
 
 %apply int *depth { int *depth };
@@ -1092,7 +1092,7 @@ typedef uint32_t fdt32_t;
if (PyTuple_GET_SIZE(resultobj) == 0)
   resultobj = val;
else
-  resultobj = SWIG_Python_AppendOutput(resultobj, val);
+  resultobj = SWIG_AppendOutput(resultobj, val);
 }
 }
 
-- 
2.47.0

Re: [RFC PATCH 2/2] apple: dart: use driver specific instance of LMB

[Janne Grunau]

On Tue, Oct 29, 2024 at 02:22:53PM +0530, Sughosh Ganu wrote:
> On Tue, 29 Oct 2024 at 14:02, Janne Grunau  wrote:
> >
> > On Tue, Oct 29, 2024 at 12:48:46PM +0530, Sughosh Ganu wrote:
> > > The LMB module is typically used for managing the platform's RAM
> > > memory. RAM memory gets added to the module's memory map, and
> > > subsequently allocated through various LMB API's.
> > >
> > > The IOMMU driver for the apple platforms also uses the LMB API's for
> > > allocating device virtual addresses(VA). These addresses are different
> > > from the RAM addresses, and cannot be added to the RAM memory map. Add
> > > a separate instance of LMB memory map for the device VA's, which gets
> > > managed by the IOMMU driver. Use lmb_push() and lmb_pop() functions to
> > > set-up the relevant lmb instance.
> >
> > thanks, this fixes the initial brokenness when setting up dma mappings
> > but I still see SError due to translation fault. I don't have time right
> > now to look into it so it could be unrelated to the iommu.
> 
> Good to know. Thanks for testing the changes.

It's SError-ing on `dc zva` of an invalid address which somehow got into
the main lmb. I don't see how but it went away with my minimal io_lmb
implemenmtation exposing lmb_setup, lmb_add, lmb_alloc, lmb_free.

I'm not too happy about this approach since it's a little fragile with
respect to the global struct lmb. to be somewhat safe we would need to
reorder lmb.c to avoid `static struct lmb lmb;` is visible in "shared"
code to avoid using it by surprise in the middle of functions like in
_lmb_alloc_base().

I'll post patches later today.

Janne

[PATCH v4 2/2] binman: expand test coverage to nxp_imx8mcst

[Brian Ruley]

Add coverage for IMX8M code siging. Create PKI tree and other assets
required by `cst' using `hab4_pki_tree.sh' script and `srktool' in
`cst_3.4.1' [1].

[1] https://www.nxp.com/webapp/Download?colCode=IMX_CST_TOOL_NEW

Signed-off-by: Brian Ruley 
---
Changes for v4:
- Rebased on master:
340_nxp_imx8mcst.dts -> 343_nxp_imx8mcst.dts
341_nxp_imx8mcst_fast_auth.dts -> 344_nxp_imx8mcst_fast_auth.dts

 tools/binman/ftest.py |  11 ++
 tools/binman/test/343_nxp_imx8mcst.dts|  58 +
 .../test/344_nxp_imx8mcst_fast_auth.dts   |  18 +++
 .../CSF1_1_sha256_4096_65537_v3_usr_crt.pem   | 121 ++
 .../IMG1_1_sha256_4096_65537_v3_usr_crt.pem   | 121 ++
 .../SRK1_sha256_4096_65537_v3_usr_crt.pem | 121 ++
 tools/binman/test/cst/crts/SRK_table.bin  | Bin 0 -> 531 bytes
 .../test/cst/crts/SRK_table_fast_auth.bin | Bin 0 -> 531 bytes
 .../CSF1_1_sha256_4096_65537_v3_usr_key.pem   |  54 
 .../IMG1_1_sha256_4096_65537_v3_usr_key.pem   |  54 
 .../SRK1_sha256_4096_65537_v3_usr_key.pem |  54 
 tools/binman/test/cst/keys/key_pass.txt   |   2 +
 12 files changed, 614 insertions(+)
 create mode 100644 tools/binman/test/343_nxp_imx8mcst.dts
 create mode 100644 tools/binman/test/344_nxp_imx8mcst_fast_auth.dts
 create mode 100644 
tools/binman/test/cst/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem
 create mode 100644 
tools/binman/test/cst/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem
 create mode 100644 
tools/binman/test/cst/crts/SRK1_sha256_4096_65537_v3_usr_crt.pem
 create mode 100644 tools/binman/test/cst/crts/SRK_table.bin
 create mode 100644 tools/binman/test/cst/crts/SRK_table_fast_auth.bin
 create mode 100644 
tools/binman/test/cst/keys/CSF1_1_sha256_4096_65537_v3_usr_key.pem
 create mode 100644 
tools/binman/test/cst/keys/IMG1_1_sha256_4096_65537_v3_usr_key.pem
 create mode 100644 
tools/binman/test/cst/keys/SRK1_sha256_4096_65537_v3_usr_key.pem
 create mode 100644 tools/binman/test/cst/keys/key_pass.txt

diff --git a/tools/binman/ftest.py b/tools/binman/ftest.py
index 156567ace7..73486d206d 100644
--- a/tools/binman/ftest.py
+++ b/tools/binman/ftest.py
@@ -219,6 +219,10 @@ class TestFunctional(unittest.TestCase):
 shutil.copytree(cls.TestFile('yaml'),
 os.path.join(cls._indir, 'yaml'))
 
+# NXP Code Signing tool
+shutil.copytree(cls.TestFile('cst'),
+os.path.join(cls._indir, 'cst'))
+
 TestFunctional._MakeInputFile('compress', COMPRESS_DATA)
 TestFunctional._MakeInputFile('compress_big', COMPRESS_DATA_BIG)
 TestFunctional._MakeInputFile('bl31.bin', ATF_BL31_DATA)
@@ -7899,6 +7903,13 @@ fdt fdtmapExtract the devicetree 
blob from the fdtmap
 entry_args=entry_args,
 extra_indirs=[test_subdir])[0]
 
+def testNxpImx8mCst(self):
+"""Test that binman can sign an iMX8M image"""
+self._DoTestFile('343_nxp_imx8mcst.dts')
+
+def testNxpImx8mCstFastAuth(self):
+"""Test that binman can sign an iMX8M image using fast 
authentication"""
+self._DoTestFile('344_nxp_imx8mcst_fast_auth.dts')
 
 if __name__ == "__main__":
 unittest.main()
diff --git a/tools/binman/test/343_nxp_imx8mcst.dts 
b/tools/binman/test/343_nxp_imx8mcst.dts
new file mode 100644
index 00..4c49c2a7bd
--- /dev/null
+++ b/tools/binman/test/343_nxp_imx8mcst.dts
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   binman {
+   nxp-imx8mcst {
+   args;   /* Needed by mkimage etype superclass */
+   filename = "test-fit.signed.bin";
+   nxp,loader-address = <0x10>;
+   nxp,srk-table = "cst/crts/SRK_table.bin";
+   nxp,img-crt = 
"cst/crts/IMG1_1_sha256_4096_65537_v3_usr_crt.pem";
+   nxp,csf-crt = 
"cst/crts/CSF1_1_sha256_4096_65537_v3_usr_crt.pem";
+
+   fit {
+   description = "test desc";
+   filename = "test-fit.itb";
+   #address-cells = <1>;
+
+   images {
+   u-boot {
+   description = "test u-boot";
+   type = "standalone";
+   arch = "arm64";
+   os = "u-boot";
+   compression = "none";
+   load = <>;
+   entry = <>;
+
+   u-boot-nodtb {
+   };
+

[PATCH v4 1/2] binman: nxp_imx8mcst: read certificates from input path

[Brian Ruley]

Right now, it is unclear where the certificates (and private keys) are
read from if environment variables are unset, and providing complete
paths in the device tree is not ideal. Naturally, it makes sense
to be able to decide where binman should look for the files, regardless
whether the keys are specified in the device tree or not.

Therefore, expand the etype to look for the necessary files from the
input path. Introduce a new variable to provide users the ability to
specify a custom path.

As a consequence of this change, the environment variables used to
specify the keys, e.g., `IMG_KEY', will be searched *relative* to the
input directories.

Signed-off-by: Brian Ruley 
---
Changes for v2:
- Added missing *.pem files
- Rebased on top of "[PATCH v4 2/2] binman: add fast authentication
  method for i.MX8M signing"
- Included a test for fast authentication
Changes for v3:
- Fixed relative path for SRK table and *.pem files in
  340_nxp_imx8mcst.dts
Changes for v4:
- Rebased on master

 tools/binman/etype/nxp_imx8mcst.py | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/tools/binman/etype/nxp_imx8mcst.py 
b/tools/binman/etype/nxp_imx8mcst.py
index a7d8db4eec..ff84b751b7 100644
--- a/tools/binman/etype/nxp_imx8mcst.py
+++ b/tools/binman/etype/nxp_imx8mcst.py
@@ -70,23 +70,26 @@ class Entry_nxp_imx8mcst(Entry_mkimage):
 def __init__(self, section, etype, node):
 super().__init__(section, etype, node)
 self.required_props = ['nxp,loader-address']
+self._cst_key_path = os.getenv('CST_KEY_PATH', None)
+if self._cst_key_path:
+tools.set_input_dirs([self._cst_key_path] + tools.indir)
 
 def ReadNode(self):
 super().ReadNode()
 self.loader_address = fdt_util.GetInt(self._node, 'nxp,loader-address')
-self.srk_table = os.getenv(
+self._srk_table = os.getenv(
 'SRK_TABLE', fdt_util.GetString(self._node, 'nxp,srk-table',
 'SRK_1_2_3_4_table.bin'))
 self.fast_auth = fdt_util.GetBool(self._node, 'nxp,fast-auth')
 if not self.fast_auth:
-self.csf_crt = os.getenv(
+self._csf_crt = os.getenv(
 'CSF_KEY', fdt_util.GetString(self._node, 'nxp,csf-crt',
   f'CSF1_1_{KEY_NAME}.pem'))
-self.img_crt = os.getenv(
+self._img_crt = os.getenv(
 'IMG_KEY', fdt_util.GetString(self._node, 'nxp,img-crt',
   f'IMG1_1_{KEY_NAME}.pem'))
 else:
-self.srk_crt = os.getenv(
+self._srk_crt = os.getenv(
 'SRK_KEY', fdt_util.GetString(self._node, 'nxp,srk-crt',
   f'SRK1_{KEY_NAME}.pem'))
 
@@ -142,15 +145,19 @@ class Entry_nxp_imx8mcst(Entry_mkimage):
 config.optionxform = str
 # Load configuration template and modify keys of interest
 config.read_string(CSF_CONFIG_TEMPLATE)
-config['Install SRK']['File']  = f'"{self.srk_table}"'
+srk_table = tools.get_input_filename(self._srk_table)
+config['Install SRK']['File']  = f'"{srk_table}"'
 if not self.fast_auth:
+csf_crt = tools.get_input_filename(self._csf_crt)
+img_crt = tools.get_input_filename(self._img_crt)
 config.remove_section('Install NOCAK')
-config['Install CSFK']['File'] = f'"{self.csf_crt}"'
-config['Install Key']['File']  = f'"{self.img_crt}"'
+config['Install CSFK']['File'] = f'"{csf_crt}"'
+config['Install Key']['File']  = f'"{img_crt}"'
 else:
+srk_crt = tools.get_input_filename(self._srk_crt)
 config.remove_section('Install CSFK')
 config.remove_section('Install Key')
-config['Install NOCAK']['File'] = f'"{self.srk_crt}"'
+config['Install NOCAK']['File'] = f'"{srk_crt}"'
 config['Authenticate Data']['Verification index'] = '0'
 
 config['Authenticate Data']['Blocks'] = \
-- 
2.39.5

Re: [PATCH v3 2/2] board: rockchip: Add support for rk3588 GenBook

[Kever Yang]

Hi Andy,

On 2024/10/26 17:34, Andy Yan wrote:

Add support for Cool Pi GenBook, it works as a carrier board
connect with CM5 SOM.

Specification:
- Rockchip RK3588
- LPDDR5X 8/32 GB
- eMMC 64 GB
- HDMI Type A out x 1
- USB 3.0 Host x 1
- USB-C 3.0 with DisplayPort AltMode
- PCIE M.2 E Key for RTL8852BE Wireless connection
- PCIE M.2 M Key for NVME connection
- eDP panel with 1920x1080

Tested by Armbian boot on USB disk.

Signed-off-by: Andy Yan 

---

Changes in v3:
- Remove upstreamed dt in genbook-u-boot.dtsi
- Remove MMC releated config as there is no SD-card on this machine
- Enable LED config
- Enable rk8xx pmic
- rename defconfig to coolpi-cm5-genbook-rk3588_defconfig
- redefine BOOT_TARGETS

Changes in v2:
- split the dts to a separate commit
- rename to genbook_cm5_rk3588
- move readme to doc/board, and write as reStructuredText format
- alphabetically reorder
- update doc/board/rockchip

  .../dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi |  20 
  arch/arm/mach-rockchip/rk3588/Kconfig |  19 
  board/coolpi/genbook_cm5_rk3588/Kconfig   |  12 +++
  board/coolpi/genbook_cm5_rk3588/MAINTAINERS   |   7 ++
  configs/coolpi-cm5-genbook-rk3588_defconfig   | 101 ++
  doc/board/coolpi/genbook_cm5_rk3588.rst   |  68 


Error report from ci:

https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/jobs/936455

Warning, treated as error:
/builds/u-boot/custodians/u-boot-rockchip/doc/board/coolpi/genbook_cm5_rk3588.rst:36:Title 
underline too short.

Write u-boot to eMMC or SPI Nor from a Linux system on the laptop
---
make[1]: *** [doc/Makefile:70: htmldocs] Error 2
make: *** [Makefile:2445: htmldocs] Error 2


Thanks,

- Kever


  doc/board/coolpi/index.rst|   9 ++
  doc/board/rockchip/rockchip.rst   |   1 +
  include/configs/genbook-cm5-rk3588.h  |  31 ++
  9 files changed, 268 insertions(+)
  create mode 100644 arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi
  create mode 100644 board/coolpi/genbook_cm5_rk3588/Kconfig
  create mode 100644 board/coolpi/genbook_cm5_rk3588/MAINTAINERS
  create mode 100644 configs/coolpi-cm5-genbook-rk3588_defconfig
  create mode 100644 doc/board/coolpi/genbook_cm5_rk3588.rst
  create mode 100644 doc/board/coolpi/index.rst
  create mode 100644 include/configs/genbook-cm5-rk3588.h

diff --git a/arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi 
b/arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi
new file mode 100644
index 000..5a3073d6e7f
--- /dev/null
+++ b/arch/arm/dts/rk3588-coolpi-cm5-genbook-u-boot.dtsi
@@ -0,0 +1,20 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+#include "rk3588-u-boot.dtsi"
+
+&fspim2_pins {
+   bootph-pre-ram;
+   bootph-some-ram;
+};
+
+&sfc {
+   flash@0 {
+   bootph-pre-ram;
+   bootph-some-ram;
+   };
+};
+
+/* USB A out */
+&usb_host1_xhci {
+   snps,dis_u3_susphy_quirk;
+};
diff --git a/arch/arm/mach-rockchip/rk3588/Kconfig 
b/arch/arm/mach-rockchip/rk3588/Kconfig
index a76a470cc98..c53f6bb926e 100644
--- a/arch/arm/mach-rockchip/rk3588/Kconfig
+++ b/arch/arm/mach-rockchip/rk3588/Kconfig
@@ -29,6 +29,24 @@ config TARGET_CM3588_NAS_RK3588
  - 3.5mm Headphone out, 2.0mm PH-2A Mic in
  - 5V Fan connector, PWM beeper, IR receiver, RTC battery connector
  
+config TARGET_GENBOOK_CM5_RK3588

+   bool "Cool Pi CM5 GenBook"
+   select BOARD_LATE_INIT
+   help
+ GeenBook is a notebook based on Rockchip RK3588, and works as a 
carrier
+ board connect with CM5 SOM.
+
+ Specification:
+ - Rockchip RK3588
+ - LPDDR5X 8/32 GB
+ - eMMC 64 GB
+ - HDMI Type A out x 1
+ - USB 3.0 Host x 1
+ - USB-C 3.0 with DisplayPort AltMode
+ - PCIE M.2 E Key for RTL8852BE Wireless connection
+ - PCIE M.2 M Key for NVME connection
+ - eDP panel with 1920x1080
+
  config TARGET_JAGUAR_RK3588
bool "Theobroma Systems SBC-RK3588-AMR (Jaguar)"
select BOARD_LATE_INIT
@@ -361,6 +379,7 @@ config TEXT_BASE
default 0x00a0
  
  source "board/armsom/sige7-rk3588/Kconfig"

+source "board/coolpi/genbook_cm5_rk3588/Kconfig"
  source "board/edgeble/neural-compute-module-6/Kconfig"
  source "board/friendlyelec/cm3588-nas-rk3588/Kconfig"
  source "board/friendlyelec/nanopc-t6-rk3588/Kconfig"
diff --git a/board/coolpi/genbook_cm5_rk3588/Kconfig 
b/board/coolpi/genbook_cm5_rk3588/Kconfig
new file mode 100644
index 000..67086ea6297
--- /dev/null
+++ b/board/coolpi/genbook_cm5_rk3588/Kconfig
@@ -0,0 +1,12 @@
+if TARGET_GENBOOK_CM5_RK3588
+
+config SYS_BOARD
+   default "genbook_cm5_rk3588"
+
+config SYS_VENDOR
+   default "coolpi"
+
+config SYS_CONFIG_NAME
+   default "genbook-cm5-rk3588"
+
+endif
diff --git a/board/coolpi/genbook_cm5_rk3588/MAINTAINERS 
b/board/coolpi/genbook_cm5_rk3588/MAINTAINERS
new file mode 100644
index 000..0496cc93b59
--- /dev/nul