Re: [PATCH 33/40] drivers: spi: Remove duplicate newlines
On 7/20/24 14:40, Marek Vasut wrote:
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut
---
drivers/spi/atcspi200_spi.c | 1 -
drivers/spi/ath79_spi.c | 1 -
drivers/spi/davinci_spi.c| 1 -
drivers/spi/mxc_spi.c| 1 -
drivers/spi/spi-aspeed-smc.c | 1 -
drivers/spi/zynq_spi.c | 1 -
6 files changed, 6 deletions(-)
diff --git a/drivers/spi/atcspi200_spi.c b/drivers/spi/atcspi200_spi.c
index 929bf90458c..2178534baf0 100644
--- a/drivers/spi/atcspi200_spi.c
+++ b/drivers/spi/atcspi200_spi.c
@@ -186,7 +186,6 @@ static int __nspi_espi_rx(struct nds_spi_slave *ns, void
*din, unsigned int byte
return bytes;
}
-
static int __atcspi200_spi_xfer(struct nds_spi_slave *ns,
unsigned int bitlen, const void *data_out, void *data_in,
unsigned long flags)
diff --git a/drivers/spi/ath79_spi.c b/drivers/spi/ath79_spi.c
index faefac71260..fb2d77d7d4a 100644
--- a/drivers/spi/ath79_spi.c
+++ b/drivers/spi/ath79_spi.c
@@ -133,7 +133,6 @@ static int ath79_spi_xfer(struct udevice *dev, unsigned int
bitlen,
return 0;
}
-
static int ath79_spi_set_speed(struct udevice *bus, uint speed)
{
struct ath79_spi_priv *priv = dev_get_priv(bus);
diff --git a/drivers/spi/davinci_spi.c b/drivers/spi/davinci_spi.c
index 04c134be9ed..82049872d05 100644
--- a/drivers/spi/davinci_spi.c
+++ b/drivers/spi/davinci_spi.c
@@ -207,7 +207,6 @@ static int davinci_spi_read_write(struct davinci_spi_slave
*ds, unsigned
return 0;
}
-
static int __davinci_spi_claim_bus(struct davinci_spi_slave *ds, int cs)
{
unsigned int mode = 0, scalar;
diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index ff61a14f095..e7c393ae188 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -622,7 +622,6 @@ static int mxc_spi_xfer(struct udevice *dev, unsigned int
bitlen,
{
struct mxc_spi_slave *mxcs = dev_get_plat(dev->parent);
-
return mxc_spi_xfer_internal(mxcs, bitlen, dout, din, flags);
}
diff --git a/drivers/spi/spi-aspeed-smc.c b/drivers/spi/spi-aspeed-smc.c
index d91d58da459..12320367e97 100644
--- a/drivers/spi/spi-aspeed-smc.c
+++ b/drivers/spi/spi-aspeed-smc.c
@@ -960,7 +960,6 @@ static int aspeed_spi_ctrl_init(struct udevice *bus)
return 0;
}
-
ret = aspeed_spi_read_fixed_decoded_ranges(bus);
if (ret != 0)
return ret;
diff --git a/drivers/spi/zynq_spi.c b/drivers/spi/zynq_spi.c
index ebcb5b6cc88..d15d91a1d24 100644
--- a/drivers/spi/zynq_spi.c
+++ b/drivers/spi/zynq_spi.c
@@ -53,7 +53,6 @@ struct zynq_spi_regs {
u32 rxdr; /* 0x20 */
};
-
/* zynq spi platform data */
struct zynq_spi_plat {
struct zynq_spi_regs *regs;
Reviewed-by: Michal Simek
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
Re: [PATCH 12/40] drivers: fpga: Remove duplicate newlines
On 7/20/24 14:40, Marek Vasut wrote:
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut
---
drivers/fpga/ACEX1K.c | 1 -
drivers/fpga/fpga.c | 1 -
drivers/fpga/ivm_core.c | 1 -
drivers/fpga/lattice.c | 1 -
drivers/fpga/spartan2.c | 2 --
drivers/fpga/spartan3.c | 2 --
6 files changed, 8 deletions(-)
diff --git a/drivers/fpga/ACEX1K.c b/drivers/fpga/ACEX1K.c
index cb7877a8afe..3de9011ac06 100644
--- a/drivers/fpga/ACEX1K.c
+++ b/drivers/fpga/ACEX1K.c
@@ -79,7 +79,6 @@ int ACEX1K_info( Altera_desc *desc )
return FPGA_SUCCESS;
}
-
/* -
*/
/* ACEX1K Passive Serial Generic Implementation
*/
diff --git a/drivers/fpga/fpga.c b/drivers/fpga/fpga.c
index 38ba6c21ea2..1f6782537de 100644
--- a/drivers/fpga/fpga.c
+++ b/drivers/fpga/fpga.c
@@ -30,7 +30,6 @@ static void fpga_no_sup(char *fn, char *msg)
printf("No FPGA support!\n");
}
-
/* fpga_get_desc
*map a device number to a descriptor
*/
diff --git a/drivers/fpga/ivm_core.c b/drivers/fpga/ivm_core.c
index b9cecdd8720..3c9a01e5110 100644
--- a/drivers/fpga/ivm_core.c
+++ b/drivers/fpga/ivm_core.c
@@ -580,7 +580,6 @@ void ispVMFreeMem(void)
}
}
-
/*
*
* ispVMDataSize
diff --git a/drivers/fpga/lattice.c b/drivers/fpga/lattice.c
index 036580cad70..3f481e38565 100644
--- a/drivers/fpga/lattice.c
+++ b/drivers/fpga/lattice.c
@@ -35,7 +35,6 @@ extern unsigned short g_usIntelDataIndex;
extern unsigned short g_usIntelBufferSize;
extern char *const g_szSupportedVersions[];
-
/*
* ispVMDelay
*
diff --git a/drivers/fpga/spartan2.c b/drivers/fpga/spartan2.c
index 9cd6cb7f0fb..906649ea181 100644
--- a/drivers/fpga/spartan2.c
+++ b/drivers/fpga/spartan2.c
@@ -85,7 +85,6 @@ static int spartan2_info(xilinx_desc *desc)
return FPGA_SUCCESS;
}
-
/* -
*/
/* Spartan-II Slave Parallel Generic Implementation */
@@ -285,7 +284,6 @@ static int spartan2_sp_dump(xilinx_desc *desc, const void *buf, size_t bsize)
return ret_val;
}
-
/* -
*/
static int spartan2_ss_load(xilinx_desc *desc, const void *buf, size_t bsize)
diff --git a/drivers/fpga/spartan3.c b/drivers/fpga/spartan3.c
index b4d87d47d93..98405589134 100644
--- a/drivers/fpga/spartan3.c
+++ b/drivers/fpga/spartan3.c
@@ -91,7 +91,6 @@ static int spartan3_info(xilinx_desc *desc)
return FPGA_SUCCESS;
}
-
/* -
*/
/* Spartan-II Slave Parallel Generic Implementation */
@@ -293,7 +292,6 @@ static int spartan3_sp_dump(xilinx_desc *desc, const void *buf, size_t bsize)
return ret_val;
}
-
/* -
*/
static int spartan3_ss_load(xilinx_desc *desc, const void *buf, size_t bsize)
Reviewed-by: Michal Simek
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
Re: [PATCH 24/37] board: opalkelly: Remove duplicate newlines
On 7/19/24 12:49, Marek Vasut wrote:
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut
---
board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c
b/board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c
index 0cbfc08183c..1c63277d928 100644
--- a/board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c
+++ b/board/opalkelly/zynq/zynq-syzygy-hub/ps7_init_gpl.c
@@ -254,7 +254,6 @@ unsigned long ps7_reset_apu_3_0[] = {
EMIT_EXIT(),
};
-
int ps7_post_config(void)
{
return ps7_config(ps7_post_config_3_0);
Reviewed-by: Michal Simek
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
Re: [PATCH 37/37] board: xilinx: Remove duplicate newlines
On 7/19/24 12:49, Marek Vasut wrote:
Drop all duplicate newlines. No functional change.
Signed-off-by: Marek Vasut
---
board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c | 2 --
board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c| 2 --
board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c| 2 --
board/xilinx/zynq/zynq-zed/ps7_init_gpl.c | 2 --
board/xilinx/zynq/zynq-zybo/ps7_init_gpl.c | 3 ---
5 files changed, 11 deletions(-)
diff --git a/board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
index 602a789e775..e7f1d6ef5ec 100644
--- a/board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-microzed/ps7_init_gpl.c
@@ -4060,7 +4060,6 @@ unsigned long ps7_post_config_3_0[] = {
//
};
-
unsigned long ps7_pll_init_data_2_0[] = {
// START: top
// .. START: SLCR SETTINGS
@@ -8263,7 +8262,6 @@ unsigned long ps7_post_config_2_0[] = {
//
};
-
unsigned long ps7_pll_init_data_1_0[] = {
// START: top
// .. START: SLCR SETTINGS
diff --git a/board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
index 9343683f4d7..48001269cd7 100644
--- a/board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zc702/ps7_init_gpl.c
@@ -4167,7 +4167,6 @@ unsigned long ps7_post_config_3_0[] = {
//
};
-
unsigned long ps7_pll_init_data_2_0[] = {
// START: top
// .. START: SLCR SETTINGS
@@ -8483,7 +8482,6 @@ unsigned long ps7_post_config_2_0[] = {
//
};
-
unsigned long ps7_pll_init_data_1_0[] = {
// START: top
// .. START: SLCR SETTINGS
diff --git a/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
index 6b153aa3796..76ef5d9323e 100644
--- a/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zc706/ps7_init_gpl.c
@@ -4136,7 +4136,6 @@ unsigned long ps7_post_config_3_0[] = {
//
};
-
unsigned long ps7_pll_init_data_2_0[] = {
// START: top
// .. START: SLCR SETTINGS
@@ -8421,7 +8420,6 @@ unsigned long ps7_post_config_2_0[] = {
//
};
-
unsigned long ps7_pll_init_data_1_0[] = {
// START: top
// .. START: SLCR SETTINGS
diff --git a/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
index 6f2edf16c24..67642798b41 100644
--- a/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zed/ps7_init_gpl.c
@@ -4026,7 +4026,6 @@ unsigned long ps7_post_config_3_0[] = {
//
};
-
unsigned long ps7_pll_init_data_2_0[] = {
// START: top
// .. START: SLCR SETTINGS
@@ -8195,7 +8194,6 @@ unsigned long ps7_post_config_2_0[] = {
//
};
-
unsigned long ps7_pll_init_data_1_0[] = {
// START: top
// .. START: SLCR SETTINGS
diff --git a/board/xilinx/zynq/zynq-zybo/ps7_init_gpl.c
b/board/xilinx/zynq/zynq-zybo/ps7_init_gpl.c
index 04d2e5f1375..6a3236ce2d2 100644
--- a/board/xilinx/zynq/zynq-zybo/ps7_init_gpl.c
+++ b/board/xilinx/zynq/zynq-zybo/ps7_init_gpl.c
@@ -4082,7 +4082,6 @@ unsigned long ps7_post_config_3_0[] = {
/* */
};
-
unsigned long ps7_pll_init_data_2_0[] = {
/* START: top */
/* .. START: SLCR SETTINGS */
@@ -8313,7 +8312,6 @@ unsigned long ps7_post_config_2_0[] = {
/* */
};
-
unsigned long ps7_pll_init_data_1_0[] = {
/* START: top */
/* .. START: SLCR SETTINGS */
@@ -12477,7 +12475,6 @@ unsigned long ps7_post_config_1_0[] = {
/* */
};
-
#include "xil_io.h"
unsigned long *ps7_mio_init_data = ps7_mio_init_data_3_0;
Reviewed-by: Michal Simek
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
[PATCH] arm64: zynqmp: dts: Add rts delay property for rs485 mode on KD240
From: Manikanta Guntupalli Add "rs485-rts-delay" property to uartps node with delay_rts_before_send and delay_rts_after_send values as 10ms for rs485 mode on KD240. 10ms rts delay values have been chosen based on testing with rs485 temperature sensor (which is part of the kit) as safe minimum value for reliable operation at a baud rate of 9600. Signed-off-by: Manikanta Guntupalli Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp-sck-kd-g-revA.dtso | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso b/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso index 1727a1cc15c1..4de29d5d3ff6 100644 --- a/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso +++ b/arch/arm/dts/zynqmp-sck-kd-g-revA.dtso @@ -358,6 +358,7 @@ status = "okay"; rts-gpios = < 72 GPIO_ACTIVE_HIGH>; linux,rs485-enabled-at-boot-time; + rs485-rts-delay = <10 10>; pinctrl-names = "default"; pinctrl-0 = <_uart0_default>; assigned-clock-rates = <1>; -- 2.43.0
Re: [v2] zlib: Fix big performance regression
On 7/16/24 16:35, Tom Rini wrote:
From: Christophe Leroy
Commit 340fdf1303dc ("zlib: Port fix for CVE-2016-9841 to U-Boot")
brings a big performance regression in inflate_fast(), which leads
to watchdog timer reset on powerpc 8xx.
It looks like that commit does more than what it describe, it
especially removed an important optimisation that was doing copies
using halfwords instead of bytes. That unexpected change multiplied
by almost 4 the time spent in inflate_fast() and increased by 40%
the overall time needed to uncompress linux kernel image.
So partially revert that commit but keep post incrementation as it
is the initial purpose of said commit.
Fixes: 340fdf1303dc ("zlib: Port fix for CVE-2016-9841 to U-Boot")
[trini: Combine assorted patches in to this one, just restoring the
performance commit]
Signed-off-by: Tom Rini
Signed-off-by: Christophe Leroy
---
Given that in master we now have Michal's series un-reverted, I have
collapsed Christophe's series down to a patch that is just fixing the
performance issues, while not regressing other platforms.
Cc: Michal Simek
---
lib/zlib/inffast.c | 51 --
lib/zlib/zlib.h| 1 -
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/lib/zlib/inffast.c b/lib/zlib/inffast.c
index 5e2a65ad4d27..b5a0adcce69f 100644
--- a/lib/zlib/inffast.c
+++ b/lib/zlib/inffast.c
@@ -236,18 +236,47 @@ unsigned start; /* inflate()'s starting value for
strm->avail_out */
}
}
else {
+ unsigned short *sout;
+ unsigned long loops;
+
from = out - dist; /* copy direct from output */
-do {/* minimum length is three */
-*out++ = *from++;
-*out++ = *from++;
-*out++ = *from++;
-len -= 3;
-} while (len > 2);
-if (len) {
-*out++ = *from++;
-if (len > 1)
-*out++ = *from++;
-}
+/* minimum length is three */
+ /* Align out addr */
+ if (!((long)(out - 1) & 1)) {
+ *out++ = *from++;
+ len--;
+ }
+ sout = (unsigned short *)out;
+ if (dist > 2 ) {
+ unsigned short *sfrom;
+
+ sfrom = (unsigned short *)from;
+ loops = len >> 1;
+ do
+ *sout++ = get_unaligned(sfrom++);
+ while (--loops);
+ out = (unsigned char *)sout;
+ from = (unsigned char *)sfrom;
+ } else { /* dist == 1 or dist == 2 */
+ unsigned short pat16;
+
+ pat16 = *(sout - 1);
+ if (dist == 1)
+#if defined(__BIG_ENDIAN)
+ pat16 = (pat16 & 0xff) | ((pat16 & 0xff ) << 8);
+#elif defined(__LITTLE_ENDIAN)
+ pat16 = (pat16 & 0xff00) | ((pat16 & 0xff00 ) >> 8);
+#else
+#error __BIG_ENDIAN nor __LITTLE_ENDIAN is defined
+#endif
+ loops = len >> 1;
+ do
+ *sout++ = pat16;
+ while (--loops);
+ out = (unsigned char *)sout;
+ }
+ if (len & 1)
+ *out++ = *from++;
}
}
else if ((op & 64) == 0) { /* 2nd level distance code */
diff --git a/lib/zlib/zlib.h b/lib/zlib/zlib.h
index 560e7be97d3a..f9b2f69ac027 100644
--- a/lib/zlib/zlib.h
+++ b/lib/zlib/zlib.h
@@ -10,7 +10,6 @@
/* avoid conflicts */
#undef OFF
#undef ASMINF
-#undef POSTINC
#undef NO_GZIP
#define GUNZIP
#undef STDC
I am fine with whatever change which doesn't break functionality and address
CVE. I took that code from upstream zlib version but I forget details why I
removed this part of code.
Acked-by: Michal Simek
Thanks,
Michal
[PATCH] efi_loader: Fix typo in EFI_RT_VOLATILE_STORE description
Fix typo in EFI_RT_VOLATILE_STORE description.
Fixes: c28d32f946f0 ("efi_loader: conditionally enable SetvariableRT")
Signed-off-by: Michal Simek
---
lib/efi_loader/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index ee71f417147a..41bab4f1ad27 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -67,7 +67,7 @@ config EFI_RT_VOLATILE_STORE
depends on EFI_VARIABLE_FILE_STORE
help
When EFI variables are stored on file we don't allow SetVariableRT,
- since the OS doesn't know how to write that file. At he same time
+ since the OS doesn't know how to write that file. At the same time
we copy runtime variables in DRAM and support GetVariableRT
Enable this option to allow SetVariableRT on the RAM backend of
--
2.43.0
[PATCH] arm64: xilinx: Describe TPM reset for Kria CCs
Describe carrier card TPM reset behavior and show message about it on boot
console to let users know what to expect from it.
Signed-off-by: Michal Simek
---
board/xilinx/zynqmp/zynqmp_kria.env | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp_kria.env
b/board/xilinx/zynqmp/zynqmp_kria.env
index 69e333c53887..49ef3e7d7532 100644
--- a/board/xilinx/zynqmp/zynqmp_kria.env
+++ b/board/xilinx/zynqmp/zynqmp_kria.env
@@ -63,10 +63,13 @@ kr260_setup=i2c dev 1 && run usb_hub_init; i2c dev 2 && run
usb_hub_init;
kd240_setup=i2c dev 1 && run usb_hub_init;zynqmp pmufw node 33; zynqmp pmufw
node 47
tpm_setup=tpm autostart;
+tpm_reset=echo "!!! For TPM reset a full power cycle or pressing the POR_B
button is required !!!";
+tpm_kv260=if test ${card1_rev} = A -o ${card1_rev} = B -o ${card1_rev} = Y -o
${card1_rev} = Z -o ${card1_rev} = 1; then run tpm_reset; fi
+tpm_kd240=if test ${card1_rev} = A; then run tpm_reset; fi
board_setup=\
zynqmp mmio_write 0xFFCA0010 0xfff 0; \
-if test ${card1_name} = SCK-KV-G; then run kv260_setup; fi;\
-if test ${card1_name} = SCK-KR-G; then run kr260_setup; fi;\
-if test ${card1_name} = SCK-KD-G; then run kd240_setup; fi;\
+if test ${card1_name} = SCK-KV-G; then run kv260_setup; run tpm_kv260; fi;\
+if test ${card1_name} = SCK-KR-G; then run kr260_setup; run tpm_reset; fi;\
+if test ${card1_name} = SCK-KD-G; then run kd240_setup; run tpm_kd240; fi;\
run tpm_setup
--
2.43.0
Re: [PATCH 33/45] microblaze: Remove duplicate newlines
so 13. 7. 2024 v 15:26 odesílatel Marek Vasut
napsal:
>
> Drop all duplicate newlines. No functional change.
>
> Signed-off-by: Marek Vasut
> ---
> Cc: Francesco Dolcini
> Cc: Sean Anderson
> Cc: Simon Glass
> Cc: Tom Rini
> Cc: u-boot@lists.denx.de
> ---
> arch/microblaze/include/asm/bitops.h | 2 --
> arch/microblaze/include/asm/posix_types.h | 2 --
> arch/microblaze/include/asm/ptrace.h | 4
> arch/microblaze/include/asm/system.h | 1 -
> 4 files changed, 9 deletions(-)
>
> diff --git a/arch/microblaze/include/asm/bitops.h
> b/arch/microblaze/include/asm/bitops.h
> index 2cab2ac62b9..9ea217cd854 100644
> --- a/arch/microblaze/include/asm/bitops.h
> +++ b/arch/microblaze/include/asm/bitops.h
> @@ -32,7 +32,6 @@ static inline unsigned long ffz(unsigned long word)
> return result;
> }
>
> -
> static inline void set_bit(int nr, volatile void *addr)
> {
> int * a = (int *) addr;
> @@ -257,7 +256,6 @@ found_middle:
> #define hweight16(x) generic_hweight16(x)
> #define hweight8(x) generic_hweight8(x)
>
> -
> static inline int ext2_set_bit(int nr, volatile void *addr)
> {
> int mask, retval;
> diff --git a/arch/microblaze/include/asm/posix_types.h
> b/arch/microblaze/include/asm/posix_types.h
> index ccc6235c8d9..f4795f8d317 100644
> --- a/arch/microblaze/include/asm/posix_types.h
> +++ b/arch/microblaze/include/asm/posix_types.h
> @@ -47,7 +47,6 @@ typedef unsigned int __kernel_gid32_t;
> typedef unsigned short __kernel_old_uid_t;
> typedef unsigned short __kernel_old_gid_t;
>
> -
> typedef struct {
> #if defined(__KERNEL__) || defined(__USE_ALL)
> int val[2];
> @@ -56,7 +55,6 @@ typedef struct {
> #endif /* !defined(__KERNEL__) && !defined(__USE_ALL) */
> } __kernel_fsid_t;
>
> -
> #if defined(__KERNEL__) || !defined(__GLIBC__) || (__GLIBC__ < 2)
>
> #undef __FD_SET
> diff --git a/arch/microblaze/include/asm/ptrace.h
> b/arch/microblaze/include/asm/ptrace.h
> index b796d4faf6b..ff861d10bb4 100644
> --- a/arch/microblaze/include/asm/ptrace.h
> +++ b/arch/microblaze/include/asm/ptrace.h
> @@ -16,7 +16,6 @@
> #ifndef __MICROBLAZE_PTRACE_H__
> #define __MICROBLAZE_PTRACE_H__
>
> -
> /* Microblaze general purpose registers with special meanings. */
> #define GPR_ZERO 0 /* constant zero */
> #define GPR_ASM18 /* reserved for assembler */
> @@ -54,7 +53,6 @@
> #define SR_DIR 21
> #define SR_ASID23
>
> -
> #ifndef __ASSEMBLY__
>
> typedef unsigned long microblaze_reg_t;
> @@ -74,7 +72,6 @@ struct pt_regs
> microblaze_reg_t single_step; /* 1 if in single step mode */
> };
>
> -
> #define instruction_pointer(regs) ((regs)->pc)
> #define user_mode(regs)(!(regs)->kernel_mode)
>
> @@ -87,7 +84,6 @@ struct pt_regs
>
> #endif /* !__ASSEMBLY__ */
>
> -
> /* The number of bytes used to store each register. */
> #define _PT_REG_SIZE 4
>
> diff --git a/arch/microblaze/include/asm/system.h
> b/arch/microblaze/include/asm/system.h
> index 050a8b40763..4e31206436d 100644
> --- a/arch/microblaze/include/asm/system.h
> +++ b/arch/microblaze/include/asm/system.h
> @@ -40,7 +40,6 @@ extern void *switch_thread (struct thread_struct *last,
> } \
> } while (0)
>
> -
> /* Enable/disable interrupts. */
> #define __sti() \
> { \
> --
> 2.43.0
>
Reviewed-by: Michal Simek
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH] arm64: versal: Remove undocumented cadence,qspi compatible
Compatible string is not the part of dt-schema and also not used by U-Boot
or Linux that's why remove it completely.
Signed-off-by: Michal Simek
---
arch/arm/dts/versal-mini-ospi.dtsi | 2 +-
arch/arm/dts/versal-net-mini-ospi.dtsi | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/versal-mini-ospi.dtsi
b/arch/arm/dts/versal-mini-ospi.dtsi
index 1abe44f40426..8735292a1273 100644
--- a/arch/arm/dts/versal-mini-ospi.dtsi
+++ b/arch/arm/dts/versal-mini-ospi.dtsi
@@ -36,7 +36,7 @@
ranges;
ospi: spi@f101 {
- compatible = "cadence,qspi", "cdns,qspi-nor";
+ compatible = "cdns,qspi-nor";
status = "okay";
reg = <0 0xf101 0 0x1 0 0xc000 0
0x2000>;
clock-names = "ref_clk", "pclk";
diff --git a/arch/arm/dts/versal-net-mini-ospi.dtsi
b/arch/arm/dts/versal-net-mini-ospi.dtsi
index d511b823754b..a9bf7cc42484 100644
--- a/arch/arm/dts/versal-net-mini-ospi.dtsi
+++ b/arch/arm/dts/versal-net-mini-ospi.dtsi
@@ -50,7 +50,7 @@
ranges;
ospi: spi@f101 {
- compatible = "cadence,qspi", "cdns,qspi-nor";
+ compatible = "cdns,qspi-nor";
status = "okay";
reg = <0 0xf101 0 0x1>, <0 0xc000 0
0x2000>;
clock-names = "ref_clk", "pclk";
--
2.43.0
[PATCH] arm64: versal-net: Align node names with dt-schema
dt-schema is forcing some rules for node names that's why align them with
it. Labels are not changing that's why this change is not breaking any
other board specific DTSes.
Signed-off-by: Michal Simek
---
arch/arm/dts/versal-net-mini-emmc.dts | 4 ++--
arch/arm/dts/versal-net-mini-ospi.dtsi | 2 +-
arch/arm/dts/versal-net-mini-qspi.dtsi | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/versal-net-mini-emmc.dts
b/arch/arm/dts/versal-net-mini-emmc.dts
index 8a864ba3ed3f..e200fb694c6b 100644
--- a/arch/arm/dts/versal-net-mini-emmc.dts
+++ b/arch/arm/dts/versal-net-mini-emmc.dts
@@ -42,14 +42,14 @@
bootph-all;
};
- amba: amba {
+ amba: axi {
bootph-all;
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <2>;
ranges;
- sdhci1: sdhci@f105 {
+ sdhci1: mmc@f105 {
compatible = "xlnx,versal-net-emmc";
status = "okay";
non-removable;
diff --git a/arch/arm/dts/versal-net-mini-ospi.dtsi
b/arch/arm/dts/versal-net-mini-ospi.dtsi
index 5d188db62d92..d511b823754b 100644
--- a/arch/arm/dts/versal-net-mini-ospi.dtsi
+++ b/arch/arm/dts/versal-net-mini-ospi.dtsi
@@ -42,7 +42,7 @@
bootph-all;
};
- amba: amba {
+ amba: axi {
bootph-all;
compatible = "simple-bus";
#address-cells = <0x2>;
diff --git a/arch/arm/dts/versal-net-mini-qspi.dtsi
b/arch/arm/dts/versal-net-mini-qspi.dtsi
index 097b58c633b8..e29a3f36d6e4 100644
--- a/arch/arm/dts/versal-net-mini-qspi.dtsi
+++ b/arch/arm/dts/versal-net-mini-qspi.dtsi
@@ -42,7 +42,7 @@
bootph-all;
};
- amba: amba {
+ amba: axi {
bootph-all;
compatible = "simple-bus";
#address-cells = <2>;
--
2.43.0
[PATCH] arm64: zynqmp: Add resets property for UART nodes
From: Manikanta Guntupalli
Add resets property for UART0 and UART1 nodes
Signed-off-by: Manikanta Guntupalli
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 34f592c1a85f..6a29f6101534 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -1025,6 +1025,7 @@
reg = <0x0 0xff00 0x0 0x1000>;
clock-names = "uart_clk", "pclk";
power-domains = <_firmware PD_UART_0>;
+ resets = <_reset ZYNQMP_RESET_UART0>;
};
uart1: serial@ff01 {
@@ -1036,6 +1037,7 @@
reg = <0x0 0xff01 0x0 0x1000>;
clock-names = "uart_clk", "pclk";
power-domains = <_firmware PD_UART_1>;
+ resets = <_reset ZYNQMP_RESET_UART1>;
};
usb0: usb@ff9d {
--
2.43.0
Re: [PATCH 0/7] Add the USB5744 hub driver as per new DT binding
Hi Tom, Marek and Fabrice, st 5. 6. 2024 v 12:02 odesílatel Venkatesh Yadav Abbarapu napsal: > > Add the usb5744/usb2744 hub driver which does the reset gpio toggling > and the i2c initialization sequence. > > Tested the USB5744/USB2744 usb hub for usb0, usb1 with the > DT nodes on KR260 board. > > Venkatesh Yadav Abbarapu (7): > usb: onboard-hub: Add reset-gpio support > usb: onboard-hub: Fix the return values of regulator APIs > usb: onboard-hub: add support for Microchip USB5744 > usb: onboard-hub: Add i2c initialization for usb5744 hub > usb: onboard-hub: Bail out if peer hub is already probed > configs: zynqmp_kria: Enable the USB onboard hub > arm64: zynqmp: Update the usb5744 hub node as per binding > > arch/arm/dts/zynqmp-sck-kr-g-revA.dtso | 48 +++ > arch/arm/dts/zynqmp-sck-kr-g-revB.dtso | 48 +++ > arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 18 +++ > arch/arm/dts/zynqmp-sck-kv-g-revB.dtso | 25 +++- > common/usb_onboard_hub.c | 176 +++-- > configs/xilinx_zynqmp_kria_defconfig | 1 + > 6 files changed, 304 insertions(+), 12 deletions(-) > > -- > 2.17.1 > Can someone please take a look at this patchset? I am fine with 6/7 and 7/7. Acked-by: Michal Simek Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH v2] amd: Enable the NFS command for Versal Gen 2
On 7/11/24 18:57, Prasad Kummari wrote: Enabled the default utilization of the NFS command on Versal Gen 2 platform to facilitate booting images through the network using the NFS protocol Signed-off-by: Prasad Kummari --- Changes in v2: - corrected commit description. configs/amd_versal2_virt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/amd_versal2_virt_defconfig b/configs/amd_versal2_virt_defconfig index 2d611f84cd..bbe7db4fb3 100644 --- a/configs/amd_versal2_virt_defconfig +++ b/configs/amd_versal2_virt_defconfig @@ -46,6 +46,7 @@ CONFIG_CMD_USB=y CONFIG_BOOTP_MAY_FAIL=y CONFIG_BOOTP_BOOTFILESIZE=y CONFIG_CMD_TFTPPUT=y +CONFIG_CMD_NFS=y CONFIG_CMD_CACHE=y CONFIG_CMD_EFIDEBUG=y CONFIG_CMD_TIME=y Applied. M
Re: [PATCH] config: Enable the config CONFIG_MMC_SPEED_MODE_SET
On 7/8/24 11:17, Venkatesh Yadav Abbarapu wrote: Enable setting speed mode using mmc dev commands. The speed mode is provided as the last argument in these commands (ex: mmc dev 0 0 10) and is indicated using the index from enum bus_mode in include/mmc.h. A speed mode can be set if it is enabled from device tree or from capabilities register Signed-off-by: Venkatesh Yadav Abbarapu --- configs/amd_versal2_virt_defconfig | 1 + configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + configs/xilinx_zynq_virt_defconfig | 2 +- configs/xilinx_zynqmp_virt_defconfig | 1 + 5 files changed, 5 insertions(+), 1 deletion(-) diff --git a/configs/amd_versal2_virt_defconfig b/configs/amd_versal2_virt_defconfig index 2d611f84cd..f8df0b53e5 100644 --- a/configs/amd_versal2_virt_defconfig +++ b/configs/amd_versal2_virt_defconfig @@ -59,6 +59,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_SQUASHFS=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_UBI=y +CONFIG_MMC_SPEED_MODE_SET=y CONFIG_PARTITION_TYPE_GUID=y CONFIG_OF_BOARD=y CONFIG_DTB_RESELECT=y diff --git a/configs/xilinx_versal_net_virt_defconfig b/configs/xilinx_versal_net_virt_defconfig index 53ef81e64d..40a9b16b9c 100644 --- a/configs/xilinx_versal_net_virt_defconfig +++ b/configs/xilinx_versal_net_virt_defconfig @@ -58,6 +58,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_SQUASHFS=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_UBI=y +CONFIG_MMC_SPEED_MODE_SET=y CONFIG_PARTITION_TYPE_GUID=y CONFIG_OF_BOARD=y CONFIG_DTB_RESELECT=y diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index 915f0b993c..dc1754f6d1 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -59,6 +59,7 @@ CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_SQUASHFS=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_UBI=y +CONFIG_MMC_SPEED_MODE_SET=y CONFIG_PARTITION_TYPE_GUID=y CONFIG_OF_BOARD=y CONFIG_ENV_IS_NOWHERE=y diff --git a/configs/xilinx_zynq_virt_defconfig b/configs/xilinx_zynq_virt_defconfig index 9be904fd30..f8b6a3f1aa 100644 --- a/configs/xilinx_zynq_virt_defconfig +++ b/configs/xilinx_zynq_virt_defconfig @@ -81,6 +81,7 @@ CONFIG_CMD_MTDPARTS=y CONFIG_CMD_MTDPARTS_SPREAD=y CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y CONFIG_CMD_UBI=y +CONFIG_MMC_SPEED_MODE_SET=y CONFIG_OF_BOARD=y CONFIG_OF_LIST="zynq-zc702 zynq-zc706 zynq-zc770-xm010 zynq-zc770-xm011 zynq-zc770-xm011-x16 zynq-zc770-xm012 zynq-zc770-xm013 zynq-cc108 zynq-microzed zynq-minized zynq-picozed zynq-zed zynq-zturn zynq-zturn-v5 zynq-zybo zynq-zybo-z7 zynq-dlc20-rev1.0" CONFIG_ENV_IS_NOWHERE=y @@ -155,4 +156,3 @@ CONFIG_SYS_TIMER_COUNTS_DOWN=y CONFIG_SPL_GZIP=y CONFIG_EFI_RUNTIME_UPDATE_CAPSULE=y CONFIG_EFI_CAPSULE_FIRMWARE_RAW=y -CONFIG_TOOLS_MKEFICAPSULE=y diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index fa912ae3bb..1133134e3f 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -101,6 +101,7 @@ CONFIG_CMD_MTDPARTS=y CONFIG_CMD_MTDPARTS_SPREAD=y CONFIG_CMD_MTDPARTS_SHOW_NET_SIZES=y CONFIG_CMD_UBI=y +CONFIG_MMC_SPEED_MODE_SET=y CONFIG_PARTITION_TYPE_GUID=y CONFIG_SPL_OF_CONTROL=y CONFIG_OF_BOARD=y Applied. M
Re: [PATCH 0/4] Add mini configuration support for versal2
On 6/19/24 09:17, Venkatesh Yadav Abbarapu wrote: Adding the basic mini u-boot configuration changes for qspi, ospi and emmc. Branch:next Venkatesh Yadav Abbarapu (4): arm64: versal2: Add support for mini configuration arm64: Add versal2 mini qspi support arm64: Add versal2 mini ospi support arm64: config: Add versal2 mini emmc defconfig arch/arm/dts/amd-versal2-mini.dts | 11 configs/amd_versal2_mini_defconfig | 77 +++ configs/amd_versal2_mini_emmc_defconfig | 69 configs/amd_versal2_mini_ospi_defconfig | 84 + configs/amd_versal2_mini_qspi_defconfig | 79 +++ include/configs/amd_versal2_mini.h | 20 ++ 6 files changed, 340 insertions(+) create mode 100644 arch/arm/dts/amd-versal2-mini.dts create mode 100644 configs/amd_versal2_mini_defconfig create mode 100644 configs/amd_versal2_mini_emmc_defconfig create mode 100644 configs/amd_versal2_mini_ospi_defconfig create mode 100644 configs/amd_versal2_mini_qspi_defconfig create mode 100644 include/configs/amd_versal2_mini.h Applied. M
Re: [PATCH 0/2] env_spi: support overriding spi dev from board code
On 6/14/24 14:48, Venkatesh Yadav Abbarapu wrote: This enables boards to choose where to/from the environment should be saved/loaded either QSPI or OSPI based on the bootmode. Venkatesh Yadav Abbarapu (2): env_spi: support overriding spi dev from board code xilinx: versal-net: Handle spi seq number based on boot device board/xilinx/versal-net/board.c | 45 + drivers/mtd/spi/spi-nor-core.c | 9 +++ env/sf.c| 3 ++- include/spi.h | 2 ++ 4 files changed, 58 insertions(+), 1 deletion(-) Applied. M
Re: [PATCH] mtd: spi-nor: ids: Add IS25LP01GG flash support
On 6/17/24 06:18, Prasad Kummari wrote:
Add support for ISSI 128MB flash IS25LP01GG. This part
supports 4byte opcodes. It also supports dual and quad
read.
Signed-off-by: Prasad Kummari
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4e83b8c94c..8cad764237 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -242,6 +242,8 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
SPI_NOR_4B_OPCODES) },
{ INFO("is25lx512", 0x9d5a1a, 0, 64 * 1024, 1024,
SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES |
SPI_NOR_HAS_TB) },
+ { INFO("is25lp01gg", 0x9d6021, 0, 64 * 1024, 2048,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_TB) },
#endif
#ifdef CONFIG_SPI_FLASH_MACRONIX /* MACRONIX */
/* Macronix */
Applied.
M
Re: [PATCH] arm64: versal2: Remove UARTLITE from defconfig
On 6/18/24 15:20, Michal Simek wrote: UARTLITE can be used as console but none is testing it that's why removing it not to pop up there. Signed-off-by: Michal Simek --- configs/amd_versal2_virt_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/amd_versal2_virt_defconfig b/configs/amd_versal2_virt_defconfig index 2d611f84cd93..b071a480b517 100644 --- a/configs/amd_versal2_virt_defconfig +++ b/configs/amd_versal2_virt_defconfig @@ -119,7 +119,6 @@ CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_DEBUG_UART_SKIP_INIT=y CONFIG_ARM_DCC=y CONFIG_PL01X_SERIAL=y -CONFIG_XILINX_UARTLITE=y CONFIG_SOC_DEVICE=y CONFIG_SOC_AMD_VERSAL2=y CONFIG_SPI=y Applied. M
Re: [PATCH] clk: zynqmp: Add set_rate support for display clocks
On 7/11/24 10:29, Venkatesh Yadav Abbarapu wrote: If "assigned-clock-rates" property is included in the device tree, display driver probe is getting failed, as dp_video_ref till dp_stc_ref clocks are missing from set rate function, adding them to fix the probe failure. Signed-off-by: Venkatesh Yadav Abbarapu --- drivers/clk/clk_zynqmp.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/clk_zynqmp.c b/drivers/clk/clk_zynqmp.c index 526614..5635451821 100644 --- a/drivers/clk/clk_zynqmp.c +++ b/drivers/clk/clk_zynqmp.c @@ -727,6 +727,7 @@ static ulong zynqmp_clk_set_rate(struct clk *clk, ulong rate) case gem_tsu: case qspi_ref ... can1_ref: case usb0_bus_ref ... usb3_dual_ref: + case dp_video_ref ... dp_stc_ref: return zynqmp_clk_set_peripheral_rate(priv, id, rate, two_divs); default: Applied. M
Re: [PATCH] amd: Enable the NFS command for Versal2
please use official Versal Gen 2 On 7/9/24 13:51, Prasad Kummari wrote: Enabled the default utilization of the NFS command on Versal2 Versal Gen 2 Thanks, Michal
Re: [PATCH] xilinx: Enable the NFS command for zynqmp_kria
On 7/9/24 06:22, Prasad Kummari wrote: Enabled the default utilization of the NFS command on ZynqMP Kria platforms to facilitate booting images through the network using the NFS protocol. Signed-off-by: Prasad Kummari --- configs/xilinx_zynqmp_kria_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_zynqmp_kria_defconfig b/configs/xilinx_zynqmp_kria_defconfig index 58e88b25fd..4c66c536d0 100644 --- a/configs/xilinx_zynqmp_kria_defconfig +++ b/configs/xilinx_zynqmp_kria_defconfig @@ -81,6 +81,7 @@ CONFIG_CMD_USB_MASS_STORAGE=y CONFIG_BOOTP_MAY_FAIL=y CONFIG_BOOTP_BOOTFILESIZE=y CONFIG_CMD_TFTPPUT=y +CONFIG_CMD_NFS=y CONFIG_CMD_BMP=y CONFIG_CMD_CACHE=y CONFIG_CMD_EFIDEBUG=y please also add it to amd_versal2_virt_defconfig Thanks, Michal
Re: Warnings with xilinx_zynqmp_virt
Hi Simon,
On 7/2/24 17:51, Simon Glass wrote:
Hi Michal,
I am seeing errors when building xilinx_zynqmp_virt:
Can't set hash 'value' property for 'hash' node(FDT_ERR_NOSPACE)
Can't set hash value for 'hash' hash node in 'fdt_35' image node
Can't add verification data for node 'fdt_35' ()
The problem is visible in CI, e.g. [1]
A bisect points to this, but it might not be helpful:
46f04087712 (refs/bisect/bad) arm64: zynqmp: Add support for vck190
revB system controller
I am aware about this issue. I didn't have time to dig into it but actually
that error should be suppress.
It is based on your commit
commit a9468115699de562f08796bf2eabd832435bedec
Author: Simon Glass
AuthorDate: Mon Jun 2 22:04:53 2014 -0600
Commit: Tom Rini
CommitDate: Wed Jun 11 16:25:46 2014 -0400
mkimage: Automatically make space in FDT when full
When adding hashes or signatures, the target FDT may be full. Detect this
and automatically try again after making 1KB of space.
Signed-off-by: Simon Glass
that there is missing space in FDT. The first error should be reported from this
function
diff --git a/boot/image-fit.c b/boot/image-fit.c
index 9253f81fff54..3509ed3bd168 100644
--- a/boot/image-fit.c
+++ b/boot/image-fit.c
@@ -1218,7 +1218,7 @@ int fit_set_timestamp(void *fit, int noffset, time_t
timestamp)
ret = fdt_setprop(fit, noffset, FIT_TIMESTAMP_PROP, ,
sizeof(uint32_t));
if (ret) {
- debug("Can't set '%s' property for '%s' node (%s)\n",
+ fprintf(stderr, "Can't set '%s' property for '%s' node (%s)\n",
FIT_TIMESTAMP_PROP, fit_get_name(fit, noffset, NULL),
fdt_strerror(ret));
return ret == -FDT_ERR_NOSPACE ? -ENOSPC : -1;
but
commit 8df81e17f81ba0542f6dbb7636db64fa56c12d8a
Author: Simon Glass
AuthorDate: Sun May 1 13:55:37 2016 -0600
Commit: Tom Rini
CommitDate: Mon May 23 11:50:18 2016 -0400
image-fit: Don't display an error in fit_set_timestamp()
This function returns an error code and its caller may be able to fix the
error. For example fit_handle_file() expands the device tree to fit if there
is a lack of space.
In this case the caller does not want an error displayed. It is confusing,
since it suggests that something is wrong, when it fact everything is fine.
Drop the error.
Signed-off-by: Simon Glass
change it from printf to debug
I think the same chagne should be done for my error messages. Something like
this.
diff --git a/tools/image-host.c b/tools/image-host.c
index 49ce7436bb97..e9e5eebe8dc3 100644
--- a/tools/image-host.c
+++ b/tools/image-host.c
@@ -40,7 +40,7 @@ static int fit_set_hash_value(void *fit, int noffset, uint8_t
*value,
ret = fdt_setprop(fit, noffset, FIT_VALUE_PROP, value, value_len);
if (ret) {
- fprintf(stderr, "Can't set hash '%s' property for '%s'
node(%s)\n",
+ debug("Can't set hash '%s' property for '%s' node(%s)\n",
FIT_VALUE_PROP, fit_get_name(fit, noffset, NULL),
fdt_strerror(ret));
return ret == -FDT_ERR_NOSPACE ? -ENOSPC : -EIO;
Also the board seems to be the only one still using SPL_FIT_GENERATOR.
The migration message was added almost 3 years ago. Would it be
possible to move it to use Binman?
we have it on our todo list but Venkatesh didn't get to that yet.
Thanks,
Michal
Re: [PATCH] Revert "zlib: Port fix for CVE-2016-9841 to U-Boot"
On 6/27/24 17:49, Tom Rini wrote:
In commit 340fdf1303dc ("zlib: Port fix for CVE-2016-9841 to U-Boot")
Michal brings in (correctly) the upstream fix for CVE-2016-9841.
However, when upstream was fixing this issue they also removed a
necessary optimization for some CPU classes as part of simplifying the
code. This in turn leads to boot failures on the platforms as they now
take too long to decompress images and so the watchdog sees the system
as stuck.
The long term fix here is as Christophe has posted, which is to restore
the optimization. Given the nearness of the release, what I do here is
very similar, result wise, but less so, code wise. This is a revert of
Michal's commit _except_ we only allow for post-increment in the code,
thus keeping the CVE resolved. For the next release this commit shall be
reverted and then Christophe's patch applied.
Sorry I was out and sorry for problems. Good to see this patch.
I pretty much think that long term goal should be to use upstream zlib
and sync it up regularly.
Thanks,
Michal
Re: [PATCH v7 3/4] use fdt_kaslrseed function to de-duplicate code
On 6/18/24 23:06, Tim Harvey wrote:
Use the fdt_kaslrseed function to deduplicate code doing the same thing.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey
Reviewed-by: Simon Glass
Cc: Michal Simek
Cc: Andy Yan
Cc: Akash Gajjar
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Devarsh Thakkar
Cc: Heinrich Schuchardt
Cc: Hugo Villeneuve
Cc: Marek Vasut
Cc: Tom Rini
Cc: Chris Morgan
---
v6:
- collected tags
v5:
- fixed typo in commit message s/it's/its/
- use cmd_process_error per Michal's suggestion
v4:
- add missing /n to notice in kaslrseed cmd
- combine ints in declaration
- remove unused vars from board/xilinx/common/board.c ft_board_setup
v3:
- skip if CONFIG_MEASURED_BOOT
- fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- pass in rng index and bool to specify overwrite
- remove duplicate error strings printed outside of fdt_kaslrseed
- added note to commit log about how EFI STUB weeds out kalsr-seed
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it
elsewhere
---
board/xilinx/common/board.c | 40 --
boot/pxe_utils.c| 34 +
cmd/kaslrseed.c | 49 ++---
3 files changed, 8 insertions(+), 115 deletions(-)
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index b47d2d23f913..098738017bab 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -702,11 +702,6 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
total_size)
#define MAX_RAND_SIZE 8
int ft_board_setup(void *blob, struct bd_info *bd)
{
- size_t n = MAX_RAND_SIZE;
- struct udevice *dev;
- u8 buf[MAX_RAND_SIZE];
- int nodeoffset, ret;
-
static const struct node_info nodes[] = {
{ "arm,pl353-nand-r2p1", MTD_DEV_TYPE_NAND, },
};
@@ -714,41 +709,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
IS_ENABLED(CONFIG_NAND_ZYNQ))
fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- debug("No RNG device\n");
- return 0;
- }
-
- if (dm_rng_read(dev, buf, n)) {
- debug("Reading RNG failed\n");
- return 0;
- }
-
- if (!blob) {
- debug("No FDT memory address configured. Please configure\n"
- "the FDT address via \"fdt addr \" command.\n"
- "Aborting!\n");
- return 0;
- }
-
- ret = fdt_check_header(blob);
- if (ret < 0) {
- debug("fdt_chosen: %s\n", fdt_strerror(ret));
- return ret;
- }
-
- nodeoffset = fdt_find_or_add_subnode(blob, 0, "chosen");
- if (nodeoffset < 0) {
- debug("Reading chosen node failed\n");
- return nodeoffset;
- }
-
- ret = fdt_setprop(blob, nodeoffset, "kaslr-seed", buf, sizeof(buf));
- if (ret < 0) {
- debug("Unable to set kaslr-seed on chosen node: %s\n",
fdt_strerror(ret));
- return ret;
- }
-
return 0;
}
#endif
diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index 5c1c962ff4c1..38ca9b81a42d 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -324,10 +324,6 @@ static void label_boot_kaslrseed(void)
#if CONFIG_IS_ENABLED(DM_RNG)
ulong fdt_addr;
struct fdt_header *working_fdt;
- size_t n = 0x8;
- struct udevice *dev;
- u64 *buf;
- int nodeoffset;
int err;
/* Get the main fdt and map it */
@@ -343,35 +339,7 @@ static void label_boot_kaslrseed(void)
if (err <= 0)
return;
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- printf("No RNG device\n");
- return;
- }
-
- nodeoffset = fdt_find_or_add_subnode(working_fdt, 0, "chosen");
- if (nodeoffset < 0) {
- printf("Reading ch
Re: [PATCH 0/3] lib: smbios: Extend driver with using sysinfo driver
Hi, On 4/26/24 15:38, Michal Simek wrote: Hi, currently only DT way is supported and it is added directly to lib/smbios.c but I think DT and env is only one way how information can be found that's why this series is improving handling with using sysinfo driver which can be platform specific. At the end of day DT should be taken from smbios.c and put to sysinfo DT driver instead of implementing it directly in this generic file. Thanks, Michal Michal Simek (3): xilinx: Enable SMBIOS command lib: smbios: Let detect the system via sysinfo lib: smbios: Detect system properties via SYSINFO IDs configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + configs/xilinx_zynqmp_kria_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + include/sysinfo.h| 9 + lib/smbios.c | 42 +++- 6 files changed, 46 insertions(+), 9 deletions(-) Heinrich/Tom: Can you please take this series to your tree? Feel free to take also 1/3 which is my branch but can go with it too. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
Re: [PATCH] cmd: Make use of U_BOOT_LONGHELP when missing
> +++ b/cmd/arm/exception.c
> @@ -49,12 +49,11 @@ static struct cmd_tbl cmd_sub[] = {
> "", ""),
> };
>
> -static char exception_help_text[] =
> +U_BOOT_LONGHELP(exception,
> "\n"
> " The following exceptions are available:\n"
> " breakpoint - prefetch abort\n"
> " unaligned - data abort\n"
> - " undefined - undefined instruction\n"
> - ;
> + " undefined - undefined instruction\n");
>
> #include
> diff --git a/cmd/arm/exception64.c b/cmd/arm/exception64.c
> index 73d6c20ccace..4c5b953168cb 100644
> --- a/cmd/arm/exception64.c
> +++ b/cmd/arm/exception64.c
> @@ -77,12 +77,11 @@ static struct cmd_tbl cmd_sub[] = {
> "", ""),
> };
>
> -static char exception_help_text[] =
> +U_BOOT_LONGHELP(exception,
> "\n"
> " The following exceptions are available:\n"
> " breakpoint - breakpoint instruction exception\n"
> " unaligned - unaligned LDAR data abort\n"
> - " undefined - undefined instruction exception\n"
> - ;
> + " undefined - undefined instruction exception\n");
>
> #include
> diff --git a/cmd/blob.c b/cmd/blob.c
> index a3c1dc49224d..b1c72e3f4406 100644
> --- a/cmd/blob.c
> +++ b/cmd/blob.c
> @@ -99,7 +99,7 @@ static int do_blob(struct cmd_tbl *cmdtp, int flag, int
> argc,
> }
>
> /***/
> -static char blob_help_text[] =
> +U_BOOT_LONGHELP(blob,
> "enc src dst len km - Encapsulate and create blob of data\n"
> " $len bytes long at address $src and\n"
> " store the result at address $dst.\n"
> @@ -115,7 +115,7 @@ static char blob_help_text[] =
> " modifier is stored.\n"
> " The modifier is required for generation\n"
> " /use as key for cryptographic operation.\n"
> - " Key modifier should be 16 byte long.\n";
> + " Key modifier should be 16 byte long.\n");
>
> U_BOOT_CMD(
> blob, 6, 1, do_blob,
> diff --git a/cmd/riscv/exception.c b/cmd/riscv/exception.c
> index 14ad6c440a56..2b58b1c449c0 100644
> --- a/cmd/riscv/exception.c
> +++ b/cmd/riscv/exception.c
> @@ -68,14 +68,13 @@ static struct cmd_tbl cmd_sub[] = {
> "", ""),
> };
>
> -static char exception_help_text[] =
> +U_BOOT_LONGHELP(exception,
> "\n"
> " The following exceptions are available:\n"
> " compressed - compressed instruction\n"
> " ebreak - breakpoint\n"
> " ialign16 - 16 bit aligned instruction\n"
> " undefined - illegal instruction\n"
> - " unaligned - load address misaligned\n"
> - ;
> + " unaligned - load address misaligned\n");
>
> #include
> diff --git a/cmd/scmi.c b/cmd/scmi.c
> index 664062c4eff5..cfbca63e1644 100644
> --- a/cmd/scmi.c
> +++ b/cmd/scmi.c
> @@ -369,7 +369,7 @@ static int do_scmi(struct cmd_tbl *cmdtp, int flag,
> return cp->cmd(cmdtp, flag, argc, argv);
> }
>
> -static char scmi_help_text[] =
> +U_BOOT_LONGHELP(scmi,
> " - SCMI utility\n"
> " info - get the info of SCMI services\n"
> " perm_dev \n"
> @@ -377,8 +377,7 @@ static char scmi_help_text[] =
> " perm_protohex> \n"
> " - set protocol permission to device\n"
> " reset \n"
> - " - reset platform resource settings\n"
> - "";
> + " - reset platform resource settings\n");
>
> U_BOOT_CMD(scmi, CONFIG_SYS_MAXARGS, 0, do_scmi, "SCMI utility",
>scmi_help_text);
> diff --git a/cmd/x86/exception.c b/cmd/x86/exception.c
> index 14b6bd6f4932..02735494a3c6 100644
> --- a/cmd/x86/exception.c
> +++ b/cmd/x86/exception.c
> @@ -19,10 +19,9 @@ static struct cmd_tbl cmd_sub[] = {
> "", ""),
> };
>
> -static char exception_help_text[] =
> +U_BOOT_LONGHELP(exception,
> "\n"
> " The following exceptions are available:\n"
> - " undefined - undefined instruction\n"
> - ;
> + " undefined - undefined instruction\n");
>
> #include
> --
> 2.34.1
>
arch/arm/mach-imx/imx8/snvs_security_sc.c:781:static char
snvs_sec_status_help_text[] =
board/xilinx/versal-net/cmds.c:74:static char versalnet_help_text[] =
These two should also be part of this patch.
And this one is interesting.
cmd/cli.c:122:static char cli_help_text[] =
it is guarded by SYS_LONGHELP but I think it should be just removed
and macro should be used instead.
#if CONFIG_IS_ENABLED(SYS_LONGHELP)
static char cli_help_text[] =
"get - print current cli\n"
"set - set the current cli, possible value are: old, modern"
;
#endif
U_BOOT_CMD(cli, 3, 1, do_cli,
"cli",
#if CONFIG_IS_ENABLED(SYS_LONGHELP)
cli_help_text
#endif
);
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] amd: versal2: Use U_BOOT_LONGHELP macro
On 6/18/24 16:18, Tom Rini wrote: On Tue, Jun 18, 2024 at 03:16:38PM +0200, Michal Simek wrote: It is defined as __maybe_unused variable which fix issue when long help is disabled. Signed-off-by: Michal Simek --- board/amd/versal2/cmds.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/board/amd/versal2/cmds.c b/board/amd/versal2/cmds.c index fbd99918a7f4..56ae39bc6a1e 100644 --- a/board/amd/versal2/cmds.c +++ b/board/amd/versal2/cmds.c @@ -71,10 +71,9 @@ static int do_versal2_load_pdi(struct cmd_tbl *cmdtp, int flag, int argc, return cmd_process_error(cmdtp, ret); } -static char versal2_help_text[] = +U_BOOT_LONGHELP(versal2, "loadpdi addr len - Load pdi image\n" - "load pdi image at ddr address 'addr' with pdi image size 'len'\n" -; + "load pdi image at ddr address 'addr' with pdi image size 'len'\n"); U_BOOT_CMD_WITH_SUBCMDS(versal2, "Versal Gen 2 sub-system", versal2_help_text, U_BOOT_SUBCMD_MKENT(loadpdi, 3, 1, Reviewed-by: Tom Rini Ah, any chance you can work up something to checkpatch to catch that? I had gone through a while ago and fixed up the cases which should have been using that macro but I see a few more have slipped in, again. yes there are some more again and as I see even one ours. I will add that checkpatch part to our todo list but no promise. And will fix that others. Thanks, Michal
[PATCH] arm64: versal2: Remove UARTLITE from defconfig
UARTLITE can be used as console but none is testing it that's why removing it not to pop up there. Signed-off-by: Michal Simek --- configs/amd_versal2_virt_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/amd_versal2_virt_defconfig b/configs/amd_versal2_virt_defconfig index 2d611f84cd93..b071a480b517 100644 --- a/configs/amd_versal2_virt_defconfig +++ b/configs/amd_versal2_virt_defconfig @@ -119,7 +119,6 @@ CONFIG_DEBUG_UART_ANNOUNCE=y CONFIG_DEBUG_UART_SKIP_INIT=y CONFIG_ARM_DCC=y CONFIG_PL01X_SERIAL=y -CONFIG_XILINX_UARTLITE=y CONFIG_SOC_DEVICE=y CONFIG_SOC_AMD_VERSAL2=y CONFIG_SPI=y -- 2.43.0
[PATCH] amd: versal2: Use U_BOOT_LONGHELP macro
It is defined as __maybe_unused variable which fix issue when long help is disabled. Signed-off-by: Michal Simek --- board/amd/versal2/cmds.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/board/amd/versal2/cmds.c b/board/amd/versal2/cmds.c index fbd99918a7f4..56ae39bc6a1e 100644 --- a/board/amd/versal2/cmds.c +++ b/board/amd/versal2/cmds.c @@ -71,10 +71,9 @@ static int do_versal2_load_pdi(struct cmd_tbl *cmdtp, int flag, int argc, return cmd_process_error(cmdtp, ret); } -static char versal2_help_text[] = +U_BOOT_LONGHELP(versal2, "loadpdi addr len - Load pdi image\n" - "load pdi image at ddr address 'addr' with pdi image size 'len'\n" -; + "load pdi image at ddr address 'addr' with pdi image size 'len'\n"); U_BOOT_CMD_WITH_SUBCMDS(versal2, "Versal Gen 2 sub-system", versal2_help_text, U_BOOT_SUBCMD_MKENT(loadpdi, 3, 1, -- 2.43.0
[GIT PULL] xilinx patches for v2024.10-rc1
Hi Tom, please pull these patches to your tree. Gitlab CI is not showing any issue. There are some alignments and improvements but overall nothing significant. The biggest patchset is add support for new AMD Versal Gen 2 SoC. Thanks, Michal The following changes since commit 0786dd573d0793417852e009dee3148ebdd163f3: test/py: net_boot: Add test cases for net boot (2024-06-13 16:31:24 -0600) are available in the Git repository at: g...@source.denx.de:u-boot/custodians/u-boot-microblaze.git tags/xilinx-for-v2024.10-rc1 for you to fetch changes up to e4a11e984d11cf4bbe55385cbae03c08f27ecd02: xilinx: Enable FF-A for all our arm64 SoCs (2024-06-17 16:02:30 +0200) AMD/Xilinx changes for v2024.10-rc1 common: - spl: Introduce SoC specific init function xilinx: - Enable FF-A and NVMEM - Rename spl_board_init() to spl_soc_init() zynqmp: - DT alignments - Enable reset from SPL - Enable USB3 for KD240 - Align multiboot register on Kria for proper reboot - Allow multiboot environment write even in saved environment - Move zynqmp commands from board/ to arch/ - Clean up xilinx_zynqmp.h versal: - Do not prioritize boot device if driver is not enabled versal-net: - Setup location for redundant variables in SPI versal2: - Add support for new SOC mmc: - Fix tap delay for SD on Versal NET spi: - Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash part gpio: - Cover MODEPIN firmware dependency Charlie Johnston (1): board: zynqmp: Move zynqmp commands from board/ to arch/ Kory Maincent (1): xilinx: zynqmp: Allow multiboot environment write even in saved environment Lukas Funke (3): spl: Introduce SoC specific init function arm64: zynq(mp): Rename spl_board_init() to spl_soc_init() xilinx: zynqmp: Enable reset_cpu() in SPL Michal Simek (11): xilinx: zynqmp: Clean up xilinx_zynqmp.h xilinx: Enable NVMEM framework for all platforms arm64: zynqmp: Update rproc node arm64: versal2: Add support for AMD Versal Gen 2 soc: versal2: Add SoC driver for AMD Versal Gen 2 mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2 spi: versal2: Enable spi drivers for Versal Gen 2 arm64: zynqmp: Setup multiboot register to 0 arm64: zynqmp: Align #address/size-cells with node gpio: Add proper dependency on ZYNQMP_FIRMWARE xilinx: Enable FF-A for all our arm64 SoCs Neal Frager (1): arm64: zynqmp: Enable usb3 for k24 som Prasad Kummari (1): mtd: spi-nor: Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash part Simek, Michal (1): sdhci: zynq: Fix tap delay for SD on Versal NET Venkatesh Yadav Abbarapu (2): xilinx: versal: Do not prioritize boot device if driver is not enabled xilinx: versal-net: Add env redund offset arch/arm/Kconfig| 18 +- arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/amd-versal2-virt.dts | 11 + arch/arm/dts/zynqmp-mini-nand.dts | 4 +- arch/arm/dts/zynqmp.dtsi| 67 +++- arch/arm/mach-versal2/Kconfig | 55 arch/arm/mach-versal2/Makefile | 10 + arch/arm/mach-versal2/clk.c | 34 ++ arch/arm/mach-versal2/cpu.c | 93 ++ arch/arm/mach-versal2/include/mach/hardware.h | 97 ++ arch/arm/mach-versal2/include/mach/sys_proto.h | 9 + arch/arm/mach-zynq/spl.c| 4 +- arch/arm/mach-zynqmp/Kconfig| 13 +- arch/arm/mach-zynqmp/Makefile | 4 + arch/arm/mach-zynqmp/spl.c | 4 +- board/xilinx/zynqmp/cmds.c => arch/arm/mach-zynqmp/zynqmp.c | 0 board/amd/common| 1 + board/amd/versal2/Kconfig | 16 + board/amd/versal2/MAINTAINERS | 7 + board/amd/versal2/Makefile | 11 + board/amd/versal2/board.c | 343 board/amd/versal2/cmds.c| 81 + board/xilinx/Kconfig| 6 +- board/xilinx/versal/board.c | 15 + board/xilinx/zynqmp/Kconfig | 19 -- board/xilinx/zynqmp/Makefile| 4 - board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c | 23 +- board/xilinx/zynqmp/zynqmp.c| 20 +- board/xil
Re: [PATCH] xilinx: Enable NVMEM framework for all platforms
čt 11. 4. 2024 v 8:04 odesílatel Michal Simek napsal:
>
> Boards which have for example MAC address in eeprom but not in Xilinx
> format (legacy or FRU) could reference it via nvmem cells.
> For example:
>
> {
> nvmem-cells = <>;
> nvmem-cell-names = "mac-address";
> };
>
> {
> #address-cells = <1>;
> #size-cells = <1>;
> mac: mac-address@f0 {
> reg = <0xf0 6>;
> };
> };
>
> For getting it work above DT changes are required but also CONFIG_NVMEM
> should be enabled. That's why enable it by default in generic defconfigs
> to be able to use it directly by changing DT only.
>
> Signed-off-by: Michal Simek
> ---
>
> configs/xilinx_versal_net_virt_defconfig | 1 +
> configs/xilinx_versal_virt_defconfig | 1 +
> configs/xilinx_zynq_virt_defconfig | 1 +
> configs/xilinx_zynqmp_virt_defconfig | 1 +
> 4 files changed, 4 insertions(+)
>
> diff --git a/configs/xilinx_versal_net_virt_defconfig
> b/configs/xilinx_versal_net_virt_defconfig
> index 40c6a29a16e3..d9e2e050ceb6 100644
> --- a/configs/xilinx_versal_net_virt_defconfig
> +++ b/configs/xilinx_versal_net_virt_defconfig
> @@ -80,6 +80,7 @@ CONFIG_I2C_MUX_PCA954x=y
> CONFIG_DM_MAILBOX=y
> CONFIG_ZYNQMP_IPI=y
> CONFIG_MISC=y
> +CONFIG_NVMEM=y
> CONFIG_I2C_EEPROM=y
> CONFIG_SUPPORT_EMMC_BOOT=y
> CONFIG_MMC_IO_VOLTAGE=y
> diff --git a/configs/xilinx_versal_virt_defconfig
> b/configs/xilinx_versal_virt_defconfig
> index c9b8a6de0133..95a671db363e 100644
> --- a/configs/xilinx_versal_virt_defconfig
> +++ b/configs/xilinx_versal_virt_defconfig
> @@ -83,6 +83,7 @@ CONFIG_I2C_MUX_PCA954x=y
> CONFIG_DM_MAILBOX=y
> CONFIG_ZYNQMP_IPI=y
> CONFIG_MISC=y
> +CONFIG_NVMEM=y
> CONFIG_I2C_EEPROM=y
> CONFIG_SUPPORT_EMMC_BOOT=y
> CONFIG_MMC_IO_VOLTAGE=y
> diff --git a/configs/xilinx_zynq_virt_defconfig
> b/configs/xilinx_zynq_virt_defconfig
> index 708cfe96b63b..e025256dc561 100644
> --- a/configs/xilinx_zynq_virt_defconfig
> +++ b/configs/xilinx_zynq_virt_defconfig
> @@ -107,6 +107,7 @@ CONFIG_I2C_MUX_PCA954x=y
> CONFIG_LED=y
> CONFIG_LED_GPIO=y
> CONFIG_MISC=y
> +CONFIG_NVMEM=y
> CONFIG_I2C_EEPROM=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_ZYNQ=y
> diff --git a/configs/xilinx_zynqmp_virt_defconfig
> b/configs/xilinx_zynqmp_virt_defconfig
> index 18931cffbbd6..296adf066b10 100644
> --- a/configs/xilinx_zynqmp_virt_defconfig
> +++ b/configs/xilinx_zynqmp_virt_defconfig
> @@ -147,6 +147,7 @@ CONFIG_I2C_MUX_PCA954x=y
> CONFIG_LED=y
> CONFIG_LED_GPIO=y
> CONFIG_MISC=y
> +CONFIG_NVMEM=y
> CONFIG_I2C_EEPROM=y
> CONFIG_SUPPORT_EMMC_BOOT=y
> CONFIG_MMC_IO_VOLTAGE=y
> --
> 2.44.0
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] xilinx: Enable FF-A for all our arm64 SoCs
út 11. 6. 2024 v 13:07 odesílatel Michal Simek napsal: > > Enable FFA_TRANSPORT which also enable FFA command. > > Signed-off-by: Michal Simek > --- > > configs/amd_versal2_virt_defconfig | 1 + > configs/xilinx_versal_net_virt_defconfig | 1 + > configs/xilinx_versal_virt_defconfig | 1 + > configs/xilinx_zynqmp_kria_defconfig | 1 + > configs/xilinx_zynqmp_virt_defconfig | 1 + > 5 files changed, 5 insertions(+) > > diff --git a/configs/amd_versal2_virt_defconfig > b/configs/amd_versal2_virt_defconfig > index 6e4adddf2c02..2d611f84cd93 100644 > --- a/configs/amd_versal2_virt_defconfig > +++ b/configs/amd_versal2_virt_defconfig > @@ -73,6 +73,7 @@ CONFIG_TFTP_BLOCKSIZE=4096 > CONFIG_CLK_CCF=y > CONFIG_CLK_SCMI=y > CONFIG_DFU_RAM=y > +CONFIG_ARM_FFA_TRANSPORT=y > CONFIG_DM_I2C=y > CONFIG_SYS_I2C_CADENCE=y > CONFIG_I2C_MUX=y > diff --git a/configs/xilinx_versal_net_virt_defconfig > b/configs/xilinx_versal_net_virt_defconfig > index d9e2e050ceb6..c869450e119f 100644 > --- a/configs/xilinx_versal_net_virt_defconfig > +++ b/configs/xilinx_versal_net_virt_defconfig > @@ -72,6 +72,7 @@ CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y > CONFIG_TFTP_BLOCKSIZE=4096 > CONFIG_CLK_VERSAL=y > CONFIG_DFU_RAM=y > +CONFIG_ARM_FFA_TRANSPORT=y > CONFIG_ZYNQ_GPIO=y > CONFIG_DM_I2C=y > CONFIG_SYS_I2C_CADENCE=y > diff --git a/configs/xilinx_versal_virt_defconfig > b/configs/xilinx_versal_virt_defconfig > index 95a671db363e..5dd5fb1c5477 100644 > --- a/configs/xilinx_versal_virt_defconfig > +++ b/configs/xilinx_versal_virt_defconfig > @@ -74,6 +74,7 @@ CONFIG_CLK_VERSAL=y > CONFIG_DFU_TIMEOUT=y > CONFIG_DFU_RAM=y > CONFIG_SYS_DFU_DATA_BUF_SIZE=0x180 > +CONFIG_ARM_FFA_TRANSPORT=y > CONFIG_FPGA_XILINX=y > CONFIG_FPGA_VERSALPL=y > CONFIG_DM_I2C=y > diff --git a/configs/xilinx_zynqmp_kria_defconfig > b/configs/xilinx_zynqmp_kria_defconfig > index ba42f0c78485..69a5468f6fb0 100644 > --- a/configs/xilinx_zynqmp_kria_defconfig > +++ b/configs/xilinx_zynqmp_kria_defconfig > @@ -134,6 +134,7 @@ CONFIG_USB_FUNCTION_FASTBOOT=y > CONFIG_FASTBOOT_FLASH=y > CONFIG_FASTBOOT_FLASH_MMC_DEV=0 > CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > +CONFIG_ARM_FFA_TRANSPORT=y > CONFIG_FPGA_XILINX=y > CONFIG_FPGA_ZYNQMPPL=y > CONFIG_GPIO_HOG=y > diff --git a/configs/xilinx_zynqmp_virt_defconfig > b/configs/xilinx_zynqmp_virt_defconfig > index 9a71fce4c3c4..396bff927dd4 100644 > --- a/configs/xilinx_zynqmp_virt_defconfig > +++ b/configs/xilinx_zynqmp_virt_defconfig > @@ -134,6 +134,7 @@ CONFIG_USB_FUNCTION_FASTBOOT=y > CONFIG_FASTBOOT_FLASH=y > CONFIG_FASTBOOT_FLASH_MMC_DEV=0 > CONFIG_FASTBOOT_CMD_OEM_FORMAT=y > +CONFIG_ARM_FFA_TRANSPORT=y > CONFIG_FPGA_XILINX=y > CONFIG_FPGA_ZYNQMPPL=y > CONFIG_GPIO_HOG=y > -- > 2.40.1 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] mtd: spi-nor: ids: Add IS25LP01GG flash support
On 6/17/24 15:31, Dragan Simic wrote: Hello Michal, On 2024-06-17 15:26, Michal Simek wrote: On 6/17/24 08:28, Dhruva Gole wrote: On Jun 17, 2024 at 09:48:42 +0530, Prasad Kummari wrote: Add support for ISSI 128MB flash IS25LP01GG. This part Can we have the datasheet link for this part? I am assuming it's this? https://www.issi.com/WW/pdf/25LP-WP01GG.pdf Problem with links is that they will disappear when company decide to change infrastructure or is acquired by different one. You can prevent that by making sure that the link to the PDF file is archived on The Wayback Machine. [1] That way, even if the URL becomes invalid at some point in time, the contents won't be lost. [1] https://web.archive.org/ No idea about it. Up to Tom. Cheers, Michal
Re: [PATCH] xilinx: versal-net: Add env redund offset
On 6/14/24 14:51, Venkatesh Yadav Abbarapu wrote: ENV_OFFSET_REDUND config is by default set to 0 for flashes. Saving the env variables is overwriting data at 0 offset, which is wrong. So add default redund env offset ENV_OFFSET_REDUND at 0x7F0 for Versal NET platform. Signed-off-by: Venkatesh Yadav Abbarapu --- configs/xilinx_versal_net_virt_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/xilinx_versal_net_virt_defconfig b/configs/xilinx_versal_net_virt_defconfig index 40c6a29a16..289f27cdea 100644 --- a/configs/xilinx_versal_net_virt_defconfig +++ b/configs/xilinx_versal_net_virt_defconfig @@ -8,6 +8,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x10 CONFIG_DEFAULT_DEVICE_TREE="xilinx-versal-net-virt" CONFIG_OF_LIBFDT_OVERLAY=y CONFIG_DM_RESET=y +CONFIG_ENV_OFFSET_REDUND=0x7F0 CONFIG_CMD_FRU=y CONFIG_SYS_LOAD_ADDR=0x800 CONFIG_SYS_MEMTEST_START=0x Applied. M
Re: [PATCH] gpio: Add proper dependency on ZYNQMP_FIRMWARE
On 6/6/24 16:44, Michal Simek wrote: ZYNQMP_FIRMWARE can be disabled and driver depends on it that's why record this dependency via Kconfig. Signed-off-by: Michal Simek --- drivers/gpio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index b050585389bb..93c5125fed9b 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -639,7 +639,7 @@ config NOMADIK_GPIO config ZYNQMP_GPIO_MODEPIN bool "ZynqMP gpio modepin" - depends on DM_GPIO + depends on DM_GPIO && ZYNQMP_FIRMWARE help This config enables the ZynqMP gpio modepin driver. ZynqMP modepin driver will set and get the status of PS_MODE pins. These modepins applied. M
Re: [PATCH] arm64: zynqmp: Align #address/size-cells with node
On 6/6/24 16:35, Michal Simek wrote:
zynqmp-mini-nand wasn't aligned with dt binding that's why fix it.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-mini-nand.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-mini-nand.dts
b/arch/arm/dts/zynqmp-mini-nand.dts
index 5889d436edb8..e08a7840d8e1 100644
--- a/arch/arm/dts/zynqmp-mini-nand.dts
+++ b/arch/arm/dts/zynqmp-mini-nand.dts
@@ -46,8 +46,8 @@
status = "okay";
reg = <0x0 0xff10 0x1000>;
clock-names = "clk_sys", "clk_flash";
- #address-cells = <2>;
- #size-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
arasan,has-mdma;
num-cs = <2>;
nand@0 {
Applied.
M
Re: [PATCH] mtd: spi-nor: ids: Add IS25LP01GG flash support
On 6/17/24 08:28, Dhruva Gole wrote:
On Jun 17, 2024 at 09:48:42 +0530, Prasad Kummari wrote:
Add support for ISSI 128MB flash IS25LP01GG. This part
Can we have the datasheet link for this part?
I am assuming it's this?
https://www.issi.com/WW/pdf/25LP-WP01GG.pdf
Problem with links is that they will disappear when company decide to change
infrastructure or is acquired by different one.
Better to add it to the commit message.
Not sure what's U-Boot policy on this but placing it below --- should be enough
or what you have done as reply to this email that it can be found via b4.
Thanks,
Michal
supports 4byte opcodes. It also supports dual and quad
read.
Signed-off-by: Prasad Kummari
---
drivers/mtd/spi/spi-nor-ids.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4e83b8c94c..8cad764237 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -242,6 +242,8 @@ const struct flash_info spi_nor_ids[] = {
SECT_4K | USE_FSR | SPI_NOR_OCTAL_READ |
SPI_NOR_4B_OPCODES) },
{ INFO("is25lx512", 0x9d5a1a, 0, 64 * 1024, 1024,
SECT_4K | USE_FSR | SPI_NOR_4B_OPCODES |
SPI_NOR_HAS_TB) },
+ { INFO("is25lp01gg", 0x9d6021, 0, 64 * 1024, 2048,
+ SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
SPI_NOR_HAS_TB) },
Otherwise looks good to me,
Reviewed-by: Dhruva Gole
Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of
On 6/12/24 17:49, Vasileios Amoiridis wrote: On Wed, 2024-06-12 at 17:32 +0200, Michal Simek wrote: On 6/12/24 17:11, Vasileios Amoiridis wrote: On Wed, 2024-06-12 at 16:47 +0200, Michal Simek wrote: On 6/12/24 15:57, Vasileios Amoiridis wrote: On Wed, 2024-06-12 at 15:42 +0200, Michal Simek wrote: Hi Vasileios, út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis napsal: From: Vasileios Amoiridis Changes in v2: - Remove duplication of custom hardcoded env_locations[] code. - Add implementation with general arch_env_get_location(op, prio) v1: https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/ Vasileios Amoiridis (1): xilinx: Add option to load environment from outside of boot media board/xilinx/versal-net/board.c | 47 ++- - board/xilinx/versal/board.c | 47 ++- - board/xilinx/zynq/board.c | 49 +++ - - board/xilinx/zynqmp/zynqmp.c | 55 +-- - - 4 files changed, 101 insertions(+), 97 deletions(-) -- 2.34.1 I have to remove this patch from my queue because it is actually breaking current behavior. CI is reporting an issue with it and I did a closer look and what is happening is that if one location has no valid data it goes and looks at another location from the list. But that is the desired behavior, if the environment is not in one location to check to the others. That's how u-boot is written but if device doesn't exist or not accessible by u-boot it is clear that it shouldn't be used and then behavior is correct. Hmmm, how can a device be not-accessible by u-boot but u-boot still tries to use it? How could that happen? That Xilinx virtual defconfig are setup in a way that all drivers are enabled via Kconfig but they are not present on all boards. Ok, now I understand how that happens. If you look below in defconfig we are have that variables can be in NAND but there is no NAND device on zc702 but still u-boot tries to reach nand and read variables from it. So, the ideal scenario would be to U-Boot never try to access the device? Because from what I see, is that since the device is not there, U-Boot throws an error, and moves on. Also, I think that this is a problem of the user, no? If for example you have configure ENV_IS_IN_NAND but there is no NAND device, then with the patch you get a visible error that U-Boot tries to access NAND which is not there. For our platforms where you can burn boot.bin to any boot medium we had no choice that's why code was written like that that variables are saved all the time to boot medium. Also that I don't want to maintain other defconfigs for slightly different configurations. On products customers should look at our all in one defconfig and disable things which are not needed. And where variables are saved is definitely one of them. Well, that makes sense. If device exists and simple varibles are not yet saved there going to different device is IMHO problematic. Maybe I am still a bit confused, but I think that if you have defined ENV_IS_IN_QSPI and ENV_IS_IN_NAND but the environment is not there then the behavior that we see is actually correct. U-Boot tries: a) Get env from QSPI but fails because env is not there, b) Get env from NAND but fails because NAND is not there, c) Get env from nowhere. To me, this looks like the correct behavior. Isn't it? This sequence is correct but what it is not correct is when you reach nowhere and you run saveenv you can't really save variables even they can be saved to QSPI. They can't be saved to NAND because it is not present on the board. This can be solved by using the env_select command (cmd/nvedit.c) no? I looked at it and it is interesting option. We don't have it enabled by default (and maybe should be enabled). CI test is not handling it too. Love: can you please take a look at it? The issue is that none write initial variable to QSPI that's why there will be all the time bad CRC but location is correct. On Zynq it behaves like this. MMC: mmc@e010: 0 prio 0 Loading Environment from SPIFlash... SF: Detected n25q128a13 with page size 256 Bytes, erase size 64 KiB, total 16 MiB *** Warning - bad CRC, using default environment prio 1 Loading Environment from NAND... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment prio 2 Loading Environment from SPIFlash... *** Warning - bad CRC, using default environment prio 3 Loading Environment from nowhere... OK This is the message that we get as well when this patch is not added. It means you are booting out of QSPI but qspi is not accessible by u- boot. Correct? Well, we are booting from QSPI but environment is in eMMC. In our config, we have defined ENV_IS_IN_FAT and ENV_IS_NOWHERE but we have not defined ENV_IS_IN_QSPI. ok. prio is my print to show where
Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of
On 6/12/24 17:11, Vasileios Amoiridis wrote: On Wed, 2024-06-12 at 16:47 +0200, Michal Simek wrote: On 6/12/24 15:57, Vasileios Amoiridis wrote: On Wed, 2024-06-12 at 15:42 +0200, Michal Simek wrote: Hi Vasileios, út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis napsal: From: Vasileios Amoiridis Changes in v2: - Remove duplication of custom hardcoded env_locations[] code. - Add implementation with general arch_env_get_location(op, prio) v1: https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/ Vasileios Amoiridis (1): xilinx: Add option to load environment from outside of boot media board/xilinx/versal-net/board.c | 47 ++-- board/xilinx/versal/board.c | 47 ++-- board/xilinx/zynq/board.c | 49 +++- - board/xilinx/zynqmp/zynqmp.c | 55 +--- - 4 files changed, 101 insertions(+), 97 deletions(-) -- 2.34.1 I have to remove this patch from my queue because it is actually breaking current behavior. CI is reporting an issue with it and I did a closer look and what is happening is that if one location has no valid data it goes and looks at another location from the list. But that is the desired behavior, if the environment is not in one location to check to the others. That's how u-boot is written but if device doesn't exist or not accessible by u-boot it is clear that it shouldn't be used and then behavior is correct. Hmmm, how can a device be not-accessible by u-boot but u-boot still tries to use it? How could that happen? That Xilinx virtual defconfig are setup in a way that all drivers are enabled via Kconfig but they are not present on all boards. If you look below in defconfig we are have that variables can be in NAND but there is no NAND device on zc702 but still u-boot tries to reach nand and read variables from it. Also, I think that this is a problem of the user, no? If for example you have configure ENV_IS_IN_NAND but there is no NAND device, then with the patch you get a visible error that U-Boot tries to access NAND which is not there. For our platforms where you can burn boot.bin to any boot medium we had no choice that's why code was written like that that variables are saved all the time to boot medium. Also that I don't want to maintain other defconfigs for slightly different configurations. On products customers should look at our all in one defconfig and disable things which are not needed. And where variables are saved is definitely one of them. If device exists and simple varibles are not yet saved there going to different device is IMHO problematic. Maybe I am still a bit confused, but I think that if you have defined ENV_IS_IN_QSPI and ENV_IS_IN_NAND but the environment is not there then the behavior that we see is actually correct. U-Boot tries: a) Get env from QSPI but fails because env is not there, b) Get env from NAND but fails because NAND is not there, c) Get env from nowhere. To me, this looks like the correct behavior. Isn't it? This sequence is correct but what it is not correct is when you reach nowhere and you run saveenv you can't really save variables even they can be saved to QSPI. They can't be saved to NAND because it is not present on the board. The issue is that none write initial variable to QSPI that's why there will be all the time bad CRC but location is correct. On Zynq it behaves like this. MMC: mmc@e010: 0 prio 0 Loading Environment from SPIFlash... SF: Detected n25q128a13 with page size 256 Bytes, erase size 64 KiB, total 16 MiB *** Warning - bad CRC, using default environment prio 1 Loading Environment from NAND... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment prio 2 Loading Environment from SPIFlash... *** Warning - bad CRC, using default environment prio 3 Loading Environment from nowhere... OK This is the message that we get as well when this patch is not added. It means you are booting out of QSPI but qspi is not accessible by u- boot. Correct? Well, we are booting from QSPI but environment is in eMMC. In our config, we have defined ENV_IS_IN_FAT and ENV_IS_NOWHERE but we have not defined ENV_IS_IN_QSPI. ok. prio is my print to show where code is. Qemu boots out in QSPI boot mode and SPI is tried first and because this is xilinx_zynq_virt defconfig drivers/env locations for other devices are present too. That's why it goes over the list and it always ends in nowhere which never fails. If this runs on real HW then the same behavior is visible and I don't think it is right. I think this solution should be rethought. In product current behavior from our code is not the best and current U-Boot implementation is not allowing flexibility too. We are enabling redundant variables which can be only on the same device but not that you have one copy
Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of
On 6/12/24 15:57, Vasileios Amoiridis wrote:
On Wed, 2024-06-12 at 15:42 +0200, Michal Simek wrote:
Hi Vasileios,
út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis
napsal:
From: Vasileios Amoiridis
Changes in v2:
- Remove duplication of custom hardcoded env_locations[]
code.
- Add implementation with general arch_env_get_location(op,
prio)
v1:
https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/
Vasileios Amoiridis (1):
xilinx: Add option to load environment from outside of boot media
board/xilinx/versal-net/board.c | 47 ++--
board/xilinx/versal/board.c | 47 ++--
board/xilinx/zynq/board.c | 49 +++--
board/xilinx/zynqmp/zynqmp.c | 55 +
4 files changed, 101 insertions(+), 97 deletions(-)
--
2.34.1
I have to remove this patch from my queue because it is actually
breaking current behavior.
CI is reporting an issue with it and I did a closer look and what is
happening is that if one location has no valid
data it goes and looks at another location from the list.
But that is the desired behavior, if the environment is not in one
location to check to the others.
That's how u-boot is written but if device doesn't exist or not accessible by
u-boot it is clear that it shouldn't be used and then behavior is correct.
If device exists and simple varibles are not yet saved there going to different
device is IMHO problematic.
On Zynq it behaves like this.
MMC: mmc@e010: 0
prio 0
Loading Environment from SPIFlash... SF: Detected n25q128a13 with
page
size 256 Bytes, erase size 64 KiB, total 16 MiB
*** Warning - bad CRC, using default environment
prio 1
Loading Environment from NAND... *** Error - No Valid Environment
Area found
*** Warning - bad env area, using default environment
prio 2
Loading Environment from SPIFlash... *** Warning - bad CRC, using
default environment
prio 3
Loading Environment from nowhere... OK
This is the message that we get as well when this patch is not added.
It means you are booting out of QSPI but qspi is not accessible by u-boot.
Correct?
prio is my print to show where code is. Qemu boots out in QSPI boot
mode and SPI is tried first and because
this is xilinx_zynq_virt defconfig drivers/env locations for other
devices are present too. That's why it goes over the list
and it always ends in nowhere which never fails.
If this runs on real HW then the same behavior is visible and I don't
think it is right.
I think this solution should be rethought.
In product current behavior from our code is not the best and current
U-Boot implementation is not allowing
flexibility too. We are enabling redundant variables which can be
only
on the same device but not that you have
one copy in QSPI and second in EMMC.
That's why I think location should be pretty much read from DT.
There is options/u-boot node where location of variables should be
described and this should replace
env_get_location().
You mean that there should be some type of new U-Boot node that
describes where the environment should be located and go and
search in this device?
Not sure if node or just dt property which points where that variables are
stored.
It is a lot of work that's why I think second solution is more
reasonable for you which is simply create new Kconfig symbol
to disable board env_get_location() implementation.
Thanks,
Michal
You mean to basically disable the board env_get_location() that
exists in board/xilinx/zynqmp/zynqmp.c for example?
yes. Something like this.
config BOARD_ENV_LOCATION
bool "Use board defined ENV location"
default y
...
if defined (BOARD_ENV_SETUP/LOCATION)
enum env_location env_get_location(enum env_operation op, int prio)
{
...
}
endif
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP/Versal ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal/Versal NET SoCs
TF-A maintainer - Xilinx ZynqMP/Versal/Versal NET SoCs
Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of
Hi Vasileios, út 4. 6. 2024 v 15:21 odesílatel Vasileios Amoiridis napsal: > > From: Vasileios Amoiridis > > Changes in v2: > - Remove duplication of custom hardcoded env_locations[] code. > - Add implementation with general arch_env_get_location(op, prio) > > v1: > https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/ > > Vasileios Amoiridis (1): > xilinx: Add option to load environment from outside of boot media > > board/xilinx/versal-net/board.c | 47 ++-- > board/xilinx/versal/board.c | 47 ++-- > board/xilinx/zynq/board.c | 49 +++-- > board/xilinx/zynqmp/zynqmp.c| 55 + > 4 files changed, 101 insertions(+), 97 deletions(-) > > -- > 2.34.1 > I have to remove this patch from my queue because it is actually breaking current behavior. CI is reporting an issue with it and I did a closer look and what is happening is that if one location has no valid data it goes and looks at another location from the list. On Zynq it behaves like this. MMC: mmc@e010: 0 prio 0 Loading Environment from SPIFlash... SF: Detected n25q128a13 with page size 256 Bytes, erase size 64 KiB, total 16 MiB *** Warning - bad CRC, using default environment prio 1 Loading Environment from NAND... *** Error - No Valid Environment Area found *** Warning - bad env area, using default environment prio 2 Loading Environment from SPIFlash... *** Warning - bad CRC, using default environment prio 3 Loading Environment from nowhere... OK prio is my print to show where code is. Qemu boots out in QSPI boot mode and SPI is tried first and because this is xilinx_zynq_virt defconfig drivers/env locations for other devices are present too. That's why it goes over the list and it always ends in nowhere which never fails. If this runs on real HW then the same behavior is visible and I don't think it is right. I think this solution should be rethought. In product current behavior from our code is not the best and current U-Boot implementation is not allowing flexibility too. We are enabling redundant variables which can be only on the same device but not that you have one copy in QSPI and second in EMMC. That's why I think location should be pretty much read from DT. There is options/u-boot node where location of variables should be described and this should replace env_get_location(). It is a lot of work that's why I think second solution is more reasonable for you which is simply create new Kconfig symbol to disable board env_get_location() implementation. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 0/4] arm64: versal2: Add support for new AMD Versal Gen 2 SoC
On 5/29/24 16:47, Michal Simek wrote: Hi, I am sending patches for adding initial support for new AMD Versal Gen 2 SoC. If you want to find out more information please take a look at this page: https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal.html Thanks, Michal Michal Simek (4): arm64: versal2: Add support for AMD Versal Gen 2 soc: versal2: Add SoC driver for AMD Versal Gen 2 mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2 spi: versal2: Enable spi drivers for Versal Gen 2 arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/amd-versal2-virt.dts | 11 + arch/arm/mach-versal2/Kconfig | 55 +++ arch/arm/mach-versal2/Makefile| 10 + arch/arm/mach-versal2/clk.c | 34 ++ arch/arm/mach-versal2/cpu.c | 93 + arch/arm/mach-versal2/include/mach/hardware.h | 97 + .../arm/mach-versal2/include/mach/sys_proto.h | 9 + board/amd/common | 1 + board/amd/versal2/Kconfig | 16 + board/amd/versal2/MAINTAINERS | 7 + board/amd/versal2/Makefile| 11 + board/amd/versal2/board.c | 343 ++ board/amd/versal2/cmds.c | 81 + board/xilinx/Kconfig | 6 +- configs/amd_versal2_virt_defconfig| 150 drivers/gpio/Kconfig | 2 +- drivers/mailbox/Kconfig | 2 +- drivers/mmc/zynq_sdhci.c | 22 +- drivers/soc/Kconfig | 8 + drivers/soc/Makefile | 1 + drivers/soc/soc_amd_versal2.c | 77 drivers/spi/Kconfig | 2 +- drivers/spi/cadence_qspi.c| 3 +- drivers/spi/zynqmp_gqspi.c| 6 +- env/Kconfig | 6 +- include/configs/amd_versal2.h | 143 29 files changed, 1193 insertions(+), 20 deletions(-) create mode 100644 arch/arm/dts/amd-versal2-virt.dts create mode 100644 arch/arm/mach-versal2/Kconfig create mode 100644 arch/arm/mach-versal2/Makefile create mode 100644 arch/arm/mach-versal2/clk.c create mode 100644 arch/arm/mach-versal2/cpu.c create mode 100644 arch/arm/mach-versal2/include/mach/hardware.h create mode 100644 arch/arm/mach-versal2/include/mach/sys_proto.h create mode 12 board/amd/common create mode 100644 board/amd/versal2/Kconfig create mode 100644 board/amd/versal2/MAINTAINERS create mode 100644 board/amd/versal2/Makefile create mode 100644 board/amd/versal2/board.c create mode 100644 board/amd/versal2/cmds.c create mode 100644 configs/amd_versal2_virt_defconfig create mode 100644 drivers/soc/soc_amd_versal2.c create mode 100644 include/configs/amd_versal2.h Applied. M
[PATCH] xilinx: Enable FF-A for all our arm64 SoCs
Enable FFA_TRANSPORT which also enable FFA command. Signed-off-by: Michal Simek --- configs/amd_versal2_virt_defconfig | 1 + configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + configs/xilinx_zynqmp_kria_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + 5 files changed, 5 insertions(+) diff --git a/configs/amd_versal2_virt_defconfig b/configs/amd_versal2_virt_defconfig index 6e4adddf2c02..2d611f84cd93 100644 --- a/configs/amd_versal2_virt_defconfig +++ b/configs/amd_versal2_virt_defconfig @@ -73,6 +73,7 @@ CONFIG_TFTP_BLOCKSIZE=4096 CONFIG_CLK_CCF=y CONFIG_CLK_SCMI=y CONFIG_DFU_RAM=y +CONFIG_ARM_FFA_TRANSPORT=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_CADENCE=y CONFIG_I2C_MUX=y diff --git a/configs/xilinx_versal_net_virt_defconfig b/configs/xilinx_versal_net_virt_defconfig index d9e2e050ceb6..c869450e119f 100644 --- a/configs/xilinx_versal_net_virt_defconfig +++ b/configs/xilinx_versal_net_virt_defconfig @@ -72,6 +72,7 @@ CONFIG_SYS_FAULT_ECHO_LINK_DOWN=y CONFIG_TFTP_BLOCKSIZE=4096 CONFIG_CLK_VERSAL=y CONFIG_DFU_RAM=y +CONFIG_ARM_FFA_TRANSPORT=y CONFIG_ZYNQ_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_CADENCE=y diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index 95a671db363e..5dd5fb1c5477 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -74,6 +74,7 @@ CONFIG_CLK_VERSAL=y CONFIG_DFU_TIMEOUT=y CONFIG_DFU_RAM=y CONFIG_SYS_DFU_DATA_BUF_SIZE=0x180 +CONFIG_ARM_FFA_TRANSPORT=y CONFIG_FPGA_XILINX=y CONFIG_FPGA_VERSALPL=y CONFIG_DM_I2C=y diff --git a/configs/xilinx_zynqmp_kria_defconfig b/configs/xilinx_zynqmp_kria_defconfig index ba42f0c78485..69a5468f6fb0 100644 --- a/configs/xilinx_zynqmp_kria_defconfig +++ b/configs/xilinx_zynqmp_kria_defconfig @@ -134,6 +134,7 @@ CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=0 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_ARM_FFA_TRANSPORT=y CONFIG_FPGA_XILINX=y CONFIG_FPGA_ZYNQMPPL=y CONFIG_GPIO_HOG=y diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index 9a71fce4c3c4..396bff927dd4 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -134,6 +134,7 @@ CONFIG_USB_FUNCTION_FASTBOOT=y CONFIG_FASTBOOT_FLASH=y CONFIG_FASTBOOT_FLASH_MMC_DEV=0 CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_ARM_FFA_TRANSPORT=y CONFIG_FPGA_XILINX=y CONFIG_FPGA_ZYNQMPPL=y CONFIG_GPIO_HOG=y -- 2.40.1
Re: [PATCH v3 0/1] Enable reset_cpu() in SPL for ZynqMP
On 6/7/24 11:26, lukas.funke-...@weidmueller.com wrote: From: Lukas Funke This series enables the CPU reset in the SPL for ZynqMP based platforms. This only works if CONFIG_SYSRESET is disabled. This is usually the case since the the regular sysreset requires bl31 firmware to be loaded in order to hand the sysreset over to PMU firmware. In SPL we can talk to the PMU firmware directly and request a CPU reset. Changes in v3: - Use 'ZYNQMP_PM_RESET_SOFT' directly - Add comment on what happens if CONFIG_ZYNQMP_FIRMWARE is not enabled Changes in v2: - Drop 2/2 since reworking ZYNQMP_FIRMWARE dependency is out-of-scope Lukas Funke (1): xilinx: zynqmp: Enable reset_cpu() in SPL board/xilinx/zynqmp/zynqmp.c | 12 1 file changed, 12 insertions(+) Applied. M
Re: [PATCH v3 1/1] arm64: zynqmp: Enable usb3 for k24 som
On 6/4/24 10:38, Neal Frager wrote: This patch corrects the mio and pll configuration registers for using usb3 on the kd240 starter kit. Without this patch, the usb3 to sd card bridge does not initialize correctly and u-boot is unable to find the OS located on the kd240 starter kit sd card. In addition, this patch correctly configures mio76 and mio77 as gpio pins which are used as reset gpio pins on the kd240 starter kit. Signed-off-by: Neal Frager --- V1->V2: - rebased patch to latest u-boot master branch - improved git commit message V2->V3: - removed unnecessary serdes initialization from patch --- .../zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c | 23 --- 1 file changed, 10 insertions(+), 13 deletions(-) diff --git a/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c b/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c index 166e61431b..274203ffaa 100644 --- a/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c +++ b/board/xilinx/zynqmp/zynqmp-sm-k24-revA/psu_init_gpl.c @@ -528,8 +528,8 @@ static unsigned long psu_mio_init_data(void) psu_mask_write(0xFF180124, 0x00FEU, 0x0002U); psu_mask_write(0xFF180128, 0x00FEU, 0x0002U); psu_mask_write(0xFF18012C, 0x00FEU, 0x0002U); - psu_mask_write(0xFF180130, 0x00FEU, 0x00C0U); - psu_mask_write(0xFF180134, 0x00FEU, 0x00C0U); + psu_mask_write(0xFF180130, 0x00FEU, 0xU); + psu_mask_write(0xFF180134, 0x00FEU, 0xU); psu_mask_write(0xFF180204, 0xU, 0x5000U); psu_mask_write(0xFF180208, 0xU, 0x00B02020U); psu_mask_write(0xFF18020C, 0x3FFFU, 0x0FC0U); @@ -569,21 +569,16 @@ static unsigned long psu_peripherals_init_data(void) psu_mask_write(0xFD1A0100, 0x0001807CU, 0xU); psu_mask_write(0xFF5E0238, 0x001AU, 0xU); psu_mask_write(0xFF5E023C, 0x0093C018U, 0xU); - psu_mask_write(0xFF5E0230, 0x0008U, 0xU); + psu_mask_write(0xFF5E0230, 0x0002U, 0xU); psu_mask_write(0xFF5E0238, 0x0001U, 0xU); psu_mask_write(0xFF180390, 0x0004U, 0x0004U); psu_mask_write(0xFF5E023C, 0x0400U, 0xU); - psu_mask_write(0xFF5E0238, 0x0040U, 0xU); - psu_mask_write(0xFF180310, 0x8000U, 0xU); - psu_mask_write(0xFF180320, 0x3384U, 0x0284U); - psu_mask_write(0xFF18031C, 0x7FFEU, 0x6450U); - psu_mask_write(0xFF180358, 0x0008U, 0x0008U); - psu_mask_write(0xFF180324, 0x03C0U, 0xU); + psu_mask_write(0xFF5E0238, 0x0080U, 0xU); psu_mask_write(0xFF5E0238, 0x0400U, 0xU); psu_mask_write(0xFF5E0238, 0x8000U, 0xU); psu_mask_write(0xFF5E0238, 0x0010U, 0xU); psu_mask_write(0xFF5E0238, 0x7800U, 0xU); - psu_mask_write(0xFF5E0238, 0x0004U, 0xU); + psu_mask_write(0xFF5E0238, 0x0006U, 0xU); psu_mask_write(0xFF5E0238, 0x0004U, 0xU); psu_mask_write(0xFF4B0024, 0x00FFU, 0x00FFU); psu_mask_write(0xFFCA5000, 0x1FFFU, 0xU); @@ -591,13 +586,15 @@ static unsigned long psu_peripherals_init_data(void) psu_mask_write(0xFFA60040, 0x8000U, 0x8000U); psu_mask_write(0xFF260020, 0xU, 0x05F5DD18U); psu_mask_write(0xFF26, 0x0001U, 0x0001U); - psu_mask_write(0xFF5E0250, 0x0F0FU, 0x0202U); + psu_mask_write(0xFF0A0284, 0x03FFU, 0x0100U); + psu_mask_write(0xFF0A0288, 0x03FFU, 0x0100U); + psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FF0100U); mask_delay(1); - psu_mask_write(0xFF5E0250, 0x0F0FU, 0x0002U); + psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FFU); mask_delay(5); - psu_mask_write(0xFF5E0250, 0x0F0FU, 0x0202U); + psu_mask_write(0xFF0A0014, 0x03FF03FFU, 0x02FF0100U); return 1; } Applied. M
Re: [PATCH] arm64: zynqmp: Setup multiboot register to 0
On 6/3/24 15:09, Michal Simek wrote:
On Kria when board starts from Image A or Image B partition multiboot
register is already setup to that location. When reset command is called
board is issuing soft reset which start SW at already used location (offset
of multiboot * 32k).
But board should continue to run from multiboot offset 0 (start of QSPI)
and call early bootloader every reboot that's why clear multiboot register
to 0 by default to go that route all the time.
Signed-off-by: Michal Simek
---
board/xilinx/zynqmp/zynqmp_kria.env | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/xilinx/zynqmp/zynqmp_kria.env
b/board/xilinx/zynqmp/zynqmp_kria.env
index 846eceb0118d..69e333c53887 100644
--- a/board/xilinx/zynqmp/zynqmp_kria.env
+++ b/board/xilinx/zynqmp/zynqmp_kria.env
@@ -65,6 +65,7 @@ kd240_setup=i2c dev 1 && run usb_hub_init;zynqmp pmufw node
33; zynqmp pmufw nod
tpm_setup=tpm autostart;
board_setup=\
+zynqmp mmio_write 0xFFCA0010 0xfff 0; \
if test ${card1_name} = SCK-KV-G; then run kv260_setup; fi;\
if test ${card1_name} = SCK-KR-G; then run kr260_setup; fi;\
if test ${card1_name} = SCK-KD-G; then run kd240_setup; fi;\
Applied.
M
Re: [PATCH 0/3] lib: smbios: Extend driver with using sysinfo driver
On 5/24/24 12:07, Ilias Apalodimas wrote: Hi Michal On Fri, 24 May 2024 at 12:45, Michal Simek wrote: Hi Ilias, On 4/26/24 15:38, Michal Simek wrote: Hi, currently only DT way is supported and it is added directly to lib/smbios.c but I think DT and env is only one way how information can be found that's why this series is improving handling with using sysinfo driver which can be platform specific. At the end of day DT should be taken from smbios.c and put to sysinfo DT driver instead of implementing it directly in this generic file. Thanks, Michal Michal Simek (3): xilinx: Enable SMBIOS command lib: smbios: Let detect the system via sysinfo lib: smbios: Detect system properties via SYSINFO IDs configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + configs/xilinx_zynqmp_kria_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + include/sysinfo.h| 9 + lib/smbios.c | 42 +++- 6 files changed, 46 insertions(+), 9 deletions(-) Any comment on this series? It's mostly Simon that created that sysinfo stuff, so I was expecting him to have a look. I can put in on my bucket list, but that's going to take some time Simon: Any comment? Thanks, Michal
Re: [PATCH 1/3] xilinx: Enable SMBIOS command
On 4/26/24 15:38, Michal Simek wrote: It is good to be aware what information is shared via smbios interface that's why enable it by default. Signed-off-by: Michal Simek --- configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + configs/xilinx_zynqmp_kria_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + 4 files changed, 4 insertions(+) diff --git a/configs/xilinx_versal_net_virt_defconfig b/configs/xilinx_versal_net_virt_defconfig index d9e2e050ceb6..3c7e37d7c81d 100644 --- a/configs/xilinx_versal_net_virt_defconfig +++ b/configs/xilinx_versal_net_virt_defconfig @@ -26,6 +26,7 @@ CONFIG_BOARD_EARLY_INIT_F=y CONFIG_BOARD_EARLY_INIT_R=y CONFIG_CLOCKS=y CONFIG_SYS_PROMPT="Versal NET> " +CONFIG_CMD_SMBIOS=y CONFIG_CMD_BOOTMENU=y CONFIG_CMD_GREPENV=y CONFIG_CMD_NVEDIT_EFI=y diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig index 95a671db363e..b7c3a4f96416 100644 --- a/configs/xilinx_versal_virt_defconfig +++ b/configs/xilinx_versal_virt_defconfig @@ -28,6 +28,7 @@ CONFIG_SYS_PBSIZE=2073 CONFIG_BOARD_EARLY_INIT_R=y CONFIG_CLOCKS=y CONFIG_SYS_PROMPT="Versal> " +CONFIG_CMD_SMBIOS=y CONFIG_CMD_BOOTMENU=y CONFIG_CMD_GREPENV=y CONFIG_CMD_NVEDIT_EFI=y diff --git a/configs/xilinx_zynqmp_kria_defconfig b/configs/xilinx_zynqmp_kria_defconfig index 7af8b27be931..41798ace6bc9 100644 --- a/configs/xilinx_zynqmp_kria_defconfig +++ b/configs/xilinx_zynqmp_kria_defconfig @@ -54,6 +54,7 @@ CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 CONFIG_SPL_ATF=y CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_CMD_SMBIOS=y CONFIG_CMD_BOOTMENU=y CONFIG_CMD_GREPENV=y CONFIG_CMD_NVEDIT_EFI=y diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index 296adf066b10..772209dd6b1e 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -52,6 +52,7 @@ CONFIG_SPL_SPI_LOAD=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x10 CONFIG_SPL_ATF=y CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_CMD_SMBIOS=y CONFIG_CMD_BOOTMENU=y CONFIG_CMD_THOR_DOWNLOAD=y CONFIG_THOR_RESET_OFF=y This patch is independent of the series that's why I applied only this patch. Thanks, Michal
Re: [PATCH] arm64: zynqmp: Update rproc node
On 5/30/24 12:39, Michal Simek wrote:
remoteproc node should be updated to be aligned with the latest dt-schema.
Signed-off-by: Michal Simek
---
Once we push all dts to Linux we can change to OF_UPSTREAM but till that
time we need to keep DTSes in sync.
---
arch/arm/dts/zynqmp.dtsi | 67 +--
include/dt-bindings/power/xlnx-zynqmp-power.h | 17 ++---
2 files changed, 68 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 53a606c340a4..34f592c1a85f 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -314,19 +314,76 @@
ranges;
};
- remoteproc {
+ rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
+ xlnx,tcm-mode = <1>;
- r5f-0 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+ reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_0_fw_image>;
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_1_fw_image>;
+ };
+ };
+
+ rproc_split: remoteproc-split@ffe0 {
+ status = "disabled";
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+ xlnx,tcm-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+ r5f@0 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_0>;
+ reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
memory-region = <_0_fw_image>;
};
- r5f-1 {
+ r5f@1 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_1>;
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
memory-region = <_1_fw_image>;
};
};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h
b/include/dt-bindings/power/xlnx-zynqmp-power.h
index e7eb0960480a..618024cbb20d 100644
--- a/include/dt-bindings/power/xlnx-zynqmp-power.h
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -6,16 +6,12 @@
#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
#define _DT_BINDINGS_ZYNQMP_POWER_H
-#define PD_RPU_0 6
-#define
Re: [PATCH v2 1/1] xilinx: zynqmp: Enable reset_cpu() in SPL
On 6/4/24 15:59, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
Changes in v2:
- Drop 2/2 since reworking ZYNQMP_FIRMWARE dependency is out-of-scope
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f370fb7347a..a129b1dbbbc 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
Isn't it easier to use ZYNQMP_PM_RESET_SOFT directly?
Also you can remove that include above to dt binding.
The rest looks good. If you want to make nicer I would put there a comment that
in case of !CONFIG_ZYNQMP_FIRMWARE xilinx_pm_request is not present compiler
removes it because of return inside if. If defined in SPL case xilinx_pm_request
will send command over IPI.
Thanks,
Michal
[PATCH] gpio: Add proper dependency on ZYNQMP_FIRMWARE
ZYNQMP_FIRMWARE can be disabled and driver depends on it that's why record this dependency via Kconfig. Signed-off-by: Michal Simek --- drivers/gpio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index b050585389bb..93c5125fed9b 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -639,7 +639,7 @@ config NOMADIK_GPIO config ZYNQMP_GPIO_MODEPIN bool "ZynqMP gpio modepin" - depends on DM_GPIO + depends on DM_GPIO && ZYNQMP_FIRMWARE help This config enables the ZynqMP gpio modepin driver. ZynqMP modepin driver will set and get the status of PS_MODE pins. These modepins -- 2.40.1
[PATCH] arm64: zynqmp: Align #address/size-cells with node
zynqmp-mini-nand wasn't aligned with dt binding that's why fix it.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-mini-nand.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-mini-nand.dts
b/arch/arm/dts/zynqmp-mini-nand.dts
index 5889d436edb8..e08a7840d8e1 100644
--- a/arch/arm/dts/zynqmp-mini-nand.dts
+++ b/arch/arm/dts/zynqmp-mini-nand.dts
@@ -46,8 +46,8 @@
status = "okay";
reg = <0x0 0xff10 0x1000>;
clock-names = "clk_sys", "clk_flash";
- #address-cells = <2>;
- #size-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
arasan,has-mdma;
num-cs = <2>;
nand@0 {
--
2.40.1
Re: [PATCH v3 7/7] drivers: misc: Add driver to access ZynqMP efuses
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
Note: Accessing eFuses requires eFuse access to be enabled in the
underlying PMU firmware.
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by: Lukas Funke
---
Changes in v3:
- Align ZynqMP eFuse driver with Linux kernel
- Adapt versal, versal-net and zynqmp to use common chip-id function
- Enable CMD_FUSE and ZYNQMP_EFUSE for zynqmp_virt and zynqmp_kria defconfig
- Use 'dev_err' instead 'log_msg_ret' if possible
Changes in v2:
- Drop vendor specific fuse cmd, use existing fuse cmd
- Minor code refactoring (reverse x-mas tree)
drivers/misc/Kconfig| 8 +
drivers/misc/Makefile | 1 +
drivers/misc/zynqmp_efuse.c | 360
3 files changed, 369 insertions(+)
create mode 100644 drivers/misc/zynqmp_efuse.c
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
Security Monitor can be transitioned on any security failures,
like software violations or hardware security violations.
+config ZYNQMP_EFUSE
+ bool "Enable ZynqMP eFUSE Driver"
+ depends on ZYNQMP_FIRMWARE
+ help
+ Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU firmware
+ interface. ZnyqMP has 256 eFUSEs where some of them are security
related
+ and cannot be read back (i.e. AES key).
+
choice
prompt "Security monitor interaction endianess"
depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
obj-$(CONFIG_SL28CPLD) += sl28cpld.o
obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..d12de7494d2
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,360 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek
Not sure which version you used as source but please sync up with kernel version
you used. I expect there will be much newer dates because efuse were added
recently.
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK GENMASK(31, 16)
+#define P_USER_127_LOWER_4_BIT_MASK GENMASK(3, 0)
+#define WORD_INBYTES 4
+#define SOC_VER_SIZE 0x4
+#define EFUSE_MEMORY_SIZE 0x177
+#define UNUSED_SPACE 0x8
+#define ZYNQMP_NVMEM_SIZE (SOC_VER_SIZE + UNUSED_SPACE + \
+EFUSE_MEMORY_SIZE)
+#define SOC_VERSION_OFFSET 0x0
+#define EFUSE_START_OFFSET 0xC
+#define EFUSE_END_OFFSET 0xFC
+#define EFUSE_PUF_START_OFFSET 0x100
+#define EFUSE_PUF_MID_OFFSET 0x140
+#define EFUSE_PUF_END_OFFSET 0x17F
+#define EFUSE_NOT_ENABLED 29
+
+/*
+ * efuse access type
+ */
+enum efuse_access {
+ EFUSE_READ = 0,
+ EFUSE_WRITE
+};
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src: address of the buffer to store the data to be write/read
+ * @size: read/write word count
+ * @offset:read/write offset
+ * @flag: 0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for read/write
+ * 1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+ u64 src;
+ u32 size;
+ u32 offset;
+ enum efuse_access flag;
+ u32 pufuserfuse;
+};
+
+/**
+ * struct efuse_map_entry - offset and length of zynqmp fuses
+ * @offset:offset of efuse to be read/write
+ * @length:length of efuse
+ */
+struct efuse_map_entry {
+ u32 offset;
+ u32 length;
+};
+
+struct efuse_map_entry zynqmp_efuse_table[] = {
+ {0x000, 0x04}, /* soc revision */
+ {0x00c, 0x0c}, /* SoC DNA */
+ {0x020, 0x04}, /* efuse-usr0 */
+ {0x024, 0x04}, /* efuse-usr1 */
+ {0x028, 0x04}, /* efuse-usr2 */
+ {0x02c, 0x04}, /* efuse-usr3 */
+ {0x030, 0x04}, /* efuse-usr4 */
+ {0x034, 0x04}, /* efuse-usr5 */
+ {0x038, 0x04}, /* efuse-usr6 */
+ {0x03c, 0x04}, /* efuse-usr7 */
+ {0x040, 0x04}, /* efuse-miscusr */
+ {0x050, 0x04}, /* efuse-chash */
+ {0x054, 0x04}, /* efuse-pufmisc */
+ {0x058, 0x04}, /* efuse-s
Re: [PATCH v3 5/7] soc: xilinx: zynqmp: Use zynqmp_pm_get_chipid() to get chip revision
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_zynqmp.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/drivers/soc/soc_xilinx_zynqmp.c b/drivers/soc/soc_xilinx_zynqmp.c
index d8b4f172a39..8a65810b7d7 100644
--- a/drivers/soc/soc_xilinx_zynqmp.c
+++ b/drivers/soc/soc_xilinx_zynqmp.c
@@ -346,22 +346,21 @@ static const struct soc_ops soc_xilinx_zynqmp_ops = {
static int soc_xilinx_zynqmp_probe(struct udevice *dev)
{
struct soc_xilinx_zynqmp_priv *priv = dev_get_priv(dev);
- u32 ret_payload[PAYLOAD_ARG_CNT];
+ u32 idcode, version;
int ret;
priv->family = zynqmp_family;
- if (!IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE))
- ret = zynqmp_mmio_read(ZYNQMP_PS_VERSION, _payload[2]);
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE))
+ ret = zynqmp_mmio_read(ZYNQMP_PS_VERSION, );
else
- ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
- ret_payload);
+ ret = zynqmp_pm_get_chipid(, );
if (ret < 0)
return ret;
- priv->revision = ret_payload[2] & ZYNQMP_PS_VER_MASK;
+ priv->revision = version & ZYNQMP_PS_VER_MASK;
- if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
+ if (CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
/*
* Firmware returns:
* payload[0][31:0] = status of the operation
@@ -370,11 +369,9 @@ static int soc_xilinx_zynqmp_probe(struct udevice *dev)
* payload[2][28:20] = EXTENDED_IDCODE
* payload[2][29] = PL_INIT
*/
- u32 idcode = ret_payload[1];
- u32 idcode2 = ret_payload[2] >>
- ZYNQMP_CSU_VERSION_EMPTY_SHIFT;
- dev_dbg(dev, "IDCODE: 0x%0x, IDCODE2: 0x%0x\n", idcode,
- idcode2);
+ u32 idcode2 = version >> ZYNQMP_CSU_VERSION_EMPTY_SHIFT;
+
+ dev_dbg(dev, "IDCODE: 0x%0x, IDCODE2: 0x%0x\n", idcode,
idcode2);
ret = soc_xilinx_zynqmp_detect_machine(dev, idcode, idcode2);
if (ret)
Looks good.
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v3 4/7] soc: xilinx: versal-net: Use zynqmp_pm_get_chipid() to get chip revision
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_versal_net.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/soc_xilinx_versal_net.c
b/drivers/soc/soc_xilinx_versal_net.c
index 146d068bb4a..76467a3bbb5 100644
--- a/drivers/soc/soc_xilinx_versal_net.c
+++ b/drivers/soc/soc_xilinx_versal_net.c
@@ -47,23 +47,22 @@ static const struct soc_ops soc_xilinx_versal_net_ops = {
static int soc_xilinx_versal_net_probe(struct udevice *dev)
{
struct soc_xilinx_versal_net_priv *priv = dev_get_priv(dev);
- u32 ret_payload[PAYLOAD_ARG_CNT];
+ u32 idcode, version;
int ret;
priv->family = versal_family;
- if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
- ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
- ret_payload);
+ if (CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ ret = zynqmp_pm_get_chipid(, );
if (ret)
return ret;
} else {
- ret_payload[2] = readl(PMC_TAP_VERSION);
- if (!ret_payload[2])
+ version = readl(PMC_TAP_VERSION);
+ if (!version)
return -EINVAL;
}
- priv->revision = FIELD_GET(PS_VERSION_MASK, ret_payload[2]);
+ priv->revision = FIELD_GET(PS_VERSION_MASK, version);
return 0;
}
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v3 6/7] firmware: zynqmp: Add support to access efuses
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add functions to access efuses through PMU firmware
interface.
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/firmware/firmware-zynqmp.c | 31 ++
include/zynqmp_firmware.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index dfad798a2e7..8e9687693dd 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -211,6 +211,37 @@ int zynqmp_pm_feature(const u32 api_id)
return ret_payload[1] & FIRMWARE_VERSION_MASK;
}
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!idcode || !version)
+ return -EINVAL;
+
+ ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
+ *idcode = ret_payload[1];
+ *version = ret_payload[2];
+
+ return ret;
+}
+
+int zynqmp_pm_efuse_access(const u64 address, u32 *out)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!out)
+ return -EINVAL;
+
+ ret = xilinx_pm_request(PM_EFUSE_ACCESS, upper_32_bits(address),
+ lower_32_bits(address), 0, 0, ret_payload);
+
+ *out = ret_payload[1];
+
+ return ret;
+}
+
int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id)
{
int ret;
diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index 73198a6a6ea..7f18b4d59bf 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -453,6 +453,8 @@ int xilinx_pm_request(u32 api_id, u32 arg0, u32 arg1, u32
arg2,
int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32
value);
int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
u32 value);
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version);
+int zynqmp_pm_efuse_access(const u64 address, u32 *out);
int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id);
int zynqmp_mmio_read(const u32 address, u32 *value);
int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
Reviewed-by: Michal Simek
Thanks,
Michal
Re: [PATCH v3 3/7] soc: xilinx: versal: Use zynqmp_pm_get_chipid() to get chip revision
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Use common zynqmp_pm_get_chipid() function to get the chip revision
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/soc/soc_xilinx_versal.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/soc/soc_xilinx_versal.c b/drivers/soc/soc_xilinx_versal.c
index 3d8c25c19bb..3d949c4e612 100644
--- a/drivers/soc/soc_xilinx_versal.c
+++ b/drivers/soc/soc_xilinx_versal.c
@@ -45,23 +45,22 @@ static const struct soc_ops soc_xilinx_versal_ops = {
static int soc_xilinx_versal_probe(struct udevice *dev)
{
struct soc_xilinx_versal_priv *priv = dev_get_priv(dev);
- u32 ret_payload[PAYLOAD_ARG_CNT];
+ u32 idcode, version;
int ret;
priv->family = versal_family;
- if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
- ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
- ret_payload);
+ if (CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ ret = zynqmp_pm_get_chipid(, );
This function is defined in 6/7 that's why this will fail when it compiles which
end up in non bisectable tree.
if (ret)
return ret;
} else {
- ret_payload[2] = readl(VERSAL_PS_PMC_VERSION);
- if (!ret_payload[2])
+ version = readl(VERSAL_PS_PMC_VERSION);
+ if (!version)
return -EINVAL;
}
- priv->revision = ret_payload[2] >> VERSAL_PS_VER_SHIFT;
+ priv->revision = version >> VERSAL_PS_VER_SHIFT;
return 0;
}
But code is ok.
M
Re: [PATCH v3 2/7] configs: zynqmp_virt: Enable CMD_FUSE and ZYNQMP_EFUSE
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote: From: Lukas Funke Enable CMD_FUSE and ZYNQMP_EFUSE in order to be able to write ZyqnMP eFuses from within the bootloader. Signed-off-by: Lukas Funke --- (no changes since v1) configs/xilinx_zynqmp_kria_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/xilinx_zynqmp_kria_defconfig b/configs/xilinx_zynqmp_kria_defconfig index ba42f0c7848..ac91dccbe64 100644 --- a/configs/xilinx_zynqmp_kria_defconfig +++ b/configs/xilinx_zynqmp_kria_defconfig @@ -65,6 +65,7 @@ CONFIG_CMD_DFU=y CONFIG_CMD_FPGA_LOADBP=y CONFIG_CMD_FPGA_LOADP=y CONFIG_CMD_FPGA_LOAD_SECURE=y +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_PWM=y CONFIG_CMD_GPT=y @@ -147,6 +148,7 @@ CONFIG_I2C_MUX_PCA954x=y CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_MISC=y +CONFIG_ZYNQMP_EFUSE=y CONFIG_I2C_EEPROM=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_IO_VOLTAGE=y Feel free to merge it with Kria. No need for two patches. M
Re: [PATCH v3 1/7] configs: zynqmp_kria: Enable CMD_FUSE and ZYNQMP_EFUSE
On 6/4/24 16:27, lukas.funke-...@weidmueller.com wrote: From: Lukas Funke Enable CMD_FUSE and ZYNQMP_EFUSE in order to be able to write ZyqnMP eFuses from within the bootloader for Kria SoM. Signed-off-by: Lukas Funke --- (no changes since v1) configs/xilinx_zynqmp_virt_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/xilinx_zynqmp_virt_defconfig b/configs/xilinx_zynqmp_virt_defconfig index ee87beb19c6..1edd4ac77b1 100644 --- a/configs/xilinx_zynqmp_virt_defconfig +++ b/configs/xilinx_zynqmp_virt_defconfig @@ -65,6 +65,7 @@ CONFIG_CMD_DFU=y CONFIG_CMD_FPGA_LOADBP=y CONFIG_CMD_FPGA_LOADP=y CONFIG_CMD_FPGA_LOAD_SECURE=y +CONFIG_CMD_FUSE=y CONFIG_CMD_GPIO=y CONFIG_CMD_PWM=y CONFIG_CMD_GPT=y @@ -147,6 +148,7 @@ CONFIG_I2C_MUX_PCA954x=y CONFIG_LED=y CONFIG_LED_GPIO=y CONFIG_MISC=y +CONFIG_ZYNQMP_EFUSE=y CONFIG_I2C_EEPROM=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_MMC_IO_VOLTAGE=y The patch itself is fine but it should be after symbol is defined. It means Kconfig change first and then enable it. M
Re: [PATCH v2 0/1] xilinx: Add option to load environment from outside of
On 6/3/24 18:47, Vasileios Amoiridis wrote: From: Vasileios Amoiridis Changes in v2: - Remove duplication of custom hardcoded env_locations[] code. - Add implementation with general arch_env_get_location(op, prio) v1: https://lore.kernel.org/u-boot/20240522174738.73522-1-vassilisa...@gmail.com/ Vasileios Amoiridis (1): xilinx: Add option to load environment from outside of boot media board/xilinx/versal-net/board.c | 47 ++-- board/xilinx/versal/board.c | 47 ++-- board/xilinx/zynq/board.c | 49 +++-- board/xilinx/zynqmp/zynqmp.c| 55 + 4 files changed, 101 insertions(+), 97 deletions(-) Applied. M
Re: [PATCH 7/7] arm64: zynqmp: Update the usb5744 hub node as per binding
On 6/5/24 12:02, Venkatesh Yadav Abbarapu wrote:
Updating the usb5744 hub node as per the latest upstream DT binding
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
tree/Documentation/devicetree/bindings/usb/microchip,usb5744.yaml?h=v6.8.8
Signed-off-by: Venkatesh Yadav Abbarapu
---
arch/arm/dts/zynqmp-sck-kr-g-revA.dtso | 48 ++
arch/arm/dts/zynqmp-sck-kr-g-revB.dtso | 48 ++
arch/arm/dts/zynqmp-sck-kv-g-revA.dtso | 18 ++
arch/arm/dts/zynqmp-sck-kv-g-revB.dtso | 25 +-
4 files changed, 138 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
b/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
index ce7c5eb6d34..18e9d308de3 100644
--- a/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
+++ b/arch/arm/dts/zynqmp-sck-kr-g-revA.dtso
@@ -105,11 +105,19 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
+ hub_1: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
};
usbhub_i2c1: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+ hub_2: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
};
/* Bus 2/3 are not connected */
};
@@ -164,6 +172,26 @@
dr_mode = "host";
snps,usb3_lpm_capable;
maximum-speed = "super-speed";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb424,2744";
+ reg = <1>;
+ peer-hub = <_3_0>;
+ i2c-bus = <_1>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb424,5744";
+ reg = <2>;
+ peer-hub = <_2_0>;
+ i2c-bus = <_1>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
};
{ /* mio64 - mio75 */
@@ -188,6 +216,26 @@
dr_mode = "host";
snps,usb3_lpm_capable;
maximum-speed = "super-speed";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub1_2_0: hub@1 {
+ compatible = "usb424,2744";
+ reg = <1>;
+ peer-hub = <_3_0>;
+ i2c-bus = <_2>;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub1_3_0: hub@2 {
+ compatible = "usb424,5744";
+ reg = <2>;
+ peer-hub = <_2_0>;
+ i2c-bus = <_2>;
+ reset-gpios = < 4 GPIO_ACTIVE_LOW>;
+ };
};
{ /* mdio mio50/51 */
diff --git a/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
b/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
index 0a0cbd2b69a..5261e793c14 100644
--- a/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
+++ b/arch/arm/dts/zynqmp-sck-kr-g-revB.dtso
@@ -117,11 +117,19 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
+ hub_1: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
};
usbhub_i2c1: i2c@1 {
#address-cells = <1>;
#size-cells = <0>;
reg = <1>;
+ hub_2: usb-hub@2d {
+ compatible = "microchip,usb5744";
+ reg = <0x2d>;
+ };
};
/* Bus 2/3 are not connected */
};
@@ -184,6 +192,26 @@
dr_mode = "host";
snps,usb3_lpm_capable;
maximum-speed = "super-speed";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port 1 */
+ hub_2_0: hub@1 {
+ compatible = "usb424,2744";
+ reg = <1>;
+ peer-hub = <_3_0>;
+ i2c-bus = <_1>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
+
+ /* 3.0 hub on port 2 */
+ hub_3_0: hub@2 {
+ compatible = "usb424,5744";
+ reg = <2>;
+ peer-hub = <_2_0>;
+ i2c-bus = <_1>;
+ reset-gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
};
{ /* mio64 - mio75 */
@@ -209,6 +237,26 @@
dr_mode = "host";
snps,usb3_lpm_capable;
maximum-speed = "super-speed";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 2.0 hub on port
Re: [PATCH] cmd: fwu: Also print information about size
On 6/5/24 17:09, Ilias Apalodimas wrote:
On Wed, 5 Jun 2024 at 17:58, Michal Simek wrote:
It is useful when structure is also used for saving vendor data covered
by CRC32.
Signed-off-by: Michal Simek
---
cmd/fwu_mdata.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
index 3c8be576ac7a..9c048d69a131 100644
--- a/cmd/fwu_mdata.c
+++ b/cmd/fwu_mdata.c
@@ -22,6 +22,7 @@ static void print_mdata(struct fwu_data *data)
printf("\tFWU Metadata\n");
printf("crc32: %#x\n", data->crc32);
printf("version: %#x\n", data->version);
+ printf("size: %#x\n", data->metadata_size);
That's only available in v2
IS_ENABLED(CONFIG_FWU_MDATA_V1) etc?
This field should be present in v1 and v2 case because it is the part of
fwu_data (u-boot private structure) not fwu_mdata (which match the spec).
But I have sent v2 and only printing it in v2 case.
Thanks,
Michal
[PATCH v2] cmd: fwu: Also print information about size
It is useful when structure is also used for saving vendor data covered
by CRC32.
Signed-off-by: Michal Simek
---
Changes in v2:
- print it only in mdata v2 version
cmd/fwu_mdata.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
index 6d91935b9b54..56654ba1b93c 100644
--- a/cmd/fwu_mdata.c
+++ b/cmd/fwu_mdata.c
@@ -27,6 +27,7 @@ static void print_mdata(struct fwu_data *data)
printf("previous_active_index: %#x\n", data->previous_active_index);
if (data->version == 2) {
+ printf("size: %#x\n", data->metadata_size);
for (i = 0; i < 4; i++)
printf("bank_state[%d]: %#x\n",
i, data->bank_state[i]);
--
2.40.1
[PATCH] cmd: fwu: Also print information about size
It is useful when structure is also used for saving vendor data covered
by CRC32.
Signed-off-by: Michal Simek
---
cmd/fwu_mdata.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
index 3c8be576ac7a..9c048d69a131 100644
--- a/cmd/fwu_mdata.c
+++ b/cmd/fwu_mdata.c
@@ -22,6 +22,7 @@ static void print_mdata(struct fwu_data *data)
printf("\tFWU Metadata\n");
printf("crc32: %#x\n", data->crc32);
printf("version: %#x\n", data->version);
+ printf("size: %#x\n", data->metadata_size);
printf("active_index: %#x\n", data->active_index);
printf("previous_active_index: %#x\n", data->previous_active_index);
--
2.40.1
[RFC PATCH] cmd: fwu: Dump custom fields from mdata structure
The commit cb9ae40a16f0 ("tools: mkfwumdata: add logic to append vendor
data to the FWU metadata") added support for adding vendor data to mdata
structure but it is not visible anywhere that's why extend fwu command to
dump it.
Signed-off-by: Michal Simek
---
I am using this for some time to check various configurations that's why it
can be useful for others too.
Sughosh: Maybe there is better way how to dump it.
---
cmd/fwu_mdata.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/cmd/fwu_mdata.c b/cmd/fwu_mdata.c
index 9c048d69a131..ff6435505167 100644
--- a/cmd/fwu_mdata.c
+++ b/cmd/fwu_mdata.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -45,6 +46,30 @@ static void print_mdata(struct fwu_data *data)
img_info->accepted == 0x1 ? "yes" : "no");
}
}
+
+ if (data->version == 2) {
+ struct fwu_mdata *mdata = data->fwu_mdata;
+ struct fwu_fw_store_desc *desc;
+ void *end;
+ u32 diff;
+
+ /*
+* fwu_mdata defines only header that's why taking it as array
+* which exactly point to image description location
+*/
+ desc = (struct fwu_fw_store_desc *)[1];
+
+ /* Number of entries is taken from for loop - variable i */
+ end = >img_entry[i];
+ debug("mdata %p, desc %p, end %p\n", mdata, desc, end);
+
+ diff = data->metadata_size - ((void *)end - (void *)mdata);
+ if (diff) {
+ printf("Custom fields covered by CRC 0x%x\n", diff);
+ print_hex_dump_bytes("CUSTOM ", DUMP_PREFIX_OFFSET,
+end, diff);
+ }
+ }
}
int do_fwu_mdata_read(struct cmd_tbl *cmdtp, int flag,
--
2.40.1
Re: [PATCH 2/2] xilinx: zynqmp: Enable reset_cpu() in SPL
On 6/4/24 11:12, Lukas Funke wrote:
On 03.06.2024 17:08, Michal Simek wrote:
On 6/3/24 16:50, Lukas Funke wrote:
On 03.06.2024 16:32, Michal Simek wrote:
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 95a134b972d..99f5c178c1d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
+ PM_RESET_ACTION_ASSERT, 0, 0, NULL);
If you disable ZYNQMP_FIRMWARE xilinx_pm_request() should fail.
we should likely fix it in drivers/mmc/zynq_sdhci.c:114
That's an odd place for a default implementation. I'd like to move the
functions to a common location but I've no idea where. That's probably why
the last developer moved it here. Any suggestions?
static inline to include/zynqmp_firmware.h?
Sound like the right place.
Currently zynqmp is not buildable when disabling CONFIG_ZYNQMP_FIRMWARE. I'm not
sure if it even makes sense to disable it. Maybe this should be enforced!?
However, I'll drop the 1/2 patch and convert 'CONFIG_IS_ENABLED' to 'IS_ENABLED'
in v2 to get finish this series. Refactoring should be addressed in another series.
In past it was mandatory and then it was changed by this patch because mini
u-boot configurations don't need it.
commit 71efd45a5fc70e29e391e0b57c700de8708ae6d9
Author: Michal Simek
AuthorDate: Fri Jan 14 13:08:42 2022 +0100
Commit: Michal Simek
CommitDate: Wed Jan 19 11:36:11 2022 +0100
arm64: zynqmp: Change firmware dependency
In case of mini U-Boot configurations there is no need to enable firmware
driver which just consume space for nothing. That's why add an option to
disable it.
Signed-off-by: Michal Simek
Link:
https://lore.kernel.org/r/d439399160ff3374f2b39f54f7dd70fa8c8bfea0.1642162121.git.michal.si...@xilinx.com
Back to your question. Even if we skip mini u-boot cases there could be still
value not to use firmware interface but it is not tested or used at this stage.
But if you simply used fixed clocks it should be possible to use it.
That's why imply has been used not to force everybody to use it but also it is
necessary to say that I don't want to block others to do it.
Thanks,
Michal
Re: [PATCH 2/2] xilinx: zynqmp: Enable reset_cpu() in SPL
On 6/3/24 16:50, Lukas Funke wrote:
On 03.06.2024 16:32, Michal Simek wrote:
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 95a134b972d..99f5c178c1d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
+ PM_RESET_ACTION_ASSERT, 0, 0, NULL);
If you disable ZYNQMP_FIRMWARE xilinx_pm_request() should fail.
we should likely fix it in drivers/mmc/zynq_sdhci.c:114
That's an odd place for a default implementation. I'd like to move the functions
to a common location but I've no idea where. That's probably why the last
developer moved it here. Any suggestions?
static inline to include/zynqmp_firmware.h?
M
Re: [PATCH 2/2] xilinx: zynqmp: Enable reset_cpu() in SPL
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual
reset mechanism requires bl31 to be loaded which may not be the case in
SPL.
Signed-off-by: Lukas Funke
---
board/xilinx/zynqmp/zynqmp.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 95a134b972d..99f5c178c1d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -40,6 +40,7 @@
#include
#include
#include
+#include
#include "../common/board.h"
#include "pm_cfg_obj.h"
@@ -285,6 +286,14 @@ int dram_init(void)
#if !CONFIG_IS_ENABLED(SYSRESET)
void reset_cpu(void)
{
+ if (!CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)) {
+ log_warning("reset failed: ZYNQMP_FIRMWARE disabled");
+ return;
+ }
+
+ xilinx_pm_request(PM_RESET_ASSERT,
+ ZYNQMP_PM_RESET_START + ZYNQMP_RESET_SOFT,
+ PM_RESET_ACTION_ASSERT, 0, 0, NULL);
If you disable ZYNQMP_FIRMWARE xilinx_pm_request() should fail.
we should likely fix it in drivers/mmc/zynq_sdhci.c:114
Thanks,
Michal
Re: [PATCH 1/2] arm64: zynqmp: Add 'SPL_ZYNQMP_FIRMWARE' to Kconfig
On 6/3/24 15:34, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
In order to make CONFIG_IS_ENABLED() work with 'ZYNQMP_FIRMWARE'
introduce an additional Kconfig 'SPL_ZYNQMP_FIRMWARE' which is selected
if and only if ZYNQMP_FIRMWARE is enabled. Driver are adapted such
that they build with and without the config being set.
Signed-off-by: Lukas Funke
---
arch/arm/mach-zynqmp/Kconfig | 2 +-
arch/arm/mach-zynqmp/aes.c | 2 ++
arch/arm/mach-zynqmp/cpu.c | 4 ++--
board/xilinx/zynqmp/zynqmp.c | 4 ++--
drivers/firmware/Kconfig | 5 +
drivers/mmc/zynq_sdhci.c | 4 ++--
drivers/pinctrl/Kconfig | 2 +-
7 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-zynqmp/Kconfig b/arch/arm/mach-zynqmp/Kconfig
index 0d2238ace1e..304dce45439 100644
--- a/arch/arm/mach-zynqmp/Kconfig
+++ b/arch/arm/mach-zynqmp/Kconfig
@@ -36,7 +36,7 @@ config PMUFW_INIT_FILE
config ZYNQMP_SPL_PM_CFG_OBJ_FILE
string "PMU firmware configuration object to load at runtime by SPL"
- depends on SPL
+ depends on SPL && ZYNQMP_FIRMWARE
Isn't this SPL_ZYNQMP_FIRMWARE?
help
Path to a binary PMU firmware configuration object to be linked
into U-Boot SPL and loaded at runtime into the PMU firmware.
diff --git a/arch/arm/mach-zynqmp/aes.c b/arch/arm/mach-zynqmp/aes.c
index 8a2b7fdcbe9..100dde2f372 100644
--- a/arch/arm/mach-zynqmp/aes.c
+++ b/arch/arm/mach-zynqmp/aes.c
@@ -17,6 +17,7 @@
int zynqmp_aes_operation(struct zynqmp_aes *aes)
{
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
u32 ret_payload[PAYLOAD_ARG_CNT];
int ret;
@@ -54,6 +55,7 @@ int zynqmp_aes_operation(struct zynqmp_aes *aes)
ret, ret_payload[1]);
return -EIO;
}
+#endif
return 0;
Very likely you want to return error if functionality is not present.
}
diff --git a/arch/arm/mach-zynqmp/cpu.c b/arch/arm/mach-zynqmp/cpu.c
index 6ae27894ecd..3515be257a5 100644
--- a/arch/arm/mach-zynqmp/cpu.c
+++ b/arch/arm/mach-zynqmp/cpu.c
@@ -188,7 +188,7 @@ int zynqmp_mmio_write(const u32 address,
{
if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3)
return zynqmp_mmio_rawwrite(address, mask, value);
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
else
return xilinx_pm_request(PM_MMIO_WRITE, address, mask,
value, 0, NULL);
@@ -207,7 +207,7 @@ int zynqmp_mmio_read(const u32 address, u32 *value)
if (IS_ENABLED(CONFIG_SPL_BUILD) || current_el() == 3) {
ret = zynqmp_mmio_rawread(address, value);
}
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
else {
u32 ret_payload[PAYLOAD_ARG_CNT];
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f370fb7347a..95a134b972d 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -147,14 +147,14 @@ int board_init(void)
int ret;
#endif
-#if defined(CONFIG_SPL_BUILD)
+#if defined(CONFIG_SPL_BUILD) && CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
/* Check *at build time* if the filename is an non-empty string */
if (sizeof(CONFIG_ZYNQMP_SPL_PM_CFG_OBJ_FILE) > 1)
zynqmp_pmufw_load_config_object(zynqmp_pm_cfg_obj,
zynqmp_pm_cfg_obj_size);
#endif
-#if defined(CONFIG_ZYNQMP_FIRMWARE)
+#if CONFIG_IS_ENABLED(ZYNQMP_FIRMWARE)
struct udevice *dev;
uclass_get_device_by_name(UCLASS_FIRMWARE, "power-management", );
diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 8789b1ea141..ae785d55d54 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -30,6 +30,7 @@ config TI_SCI_PROTOCOL
config ZYNQMP_FIRMWARE
bool "ZynqMP Firmware interface"
select FIRMWARE
+ select SPL_ZYNQMP_FIRMWARE if SPL
I don't think this is correct. Why you should connect SPL symbol with non SPL
one?
I would just remove line above that I can enable/disable firmware in SPL or
U-Boot separately.
help
Firmware interface driver is used by different
drivers to communicate with the firmware for
@@ -37,6 +38,10 @@ config ZYNQMP_FIRMWARE
Say yes to enable ZynqMP firmware interface driver.
If in doubt, say N.
+config SPL_ZYNQMP_FIRMWARE
+ bool "Enable ZynqMP Firmware interface in SPL"
Can we remove "Enable" at the beginning? Or add Enable it to ZYNQMP_FIRMWARE.
+ depends on FIRMWARE && SPL
+
config ARM_SMCCC_FEATURES
bool "Arm SMCCC features discovery"
depends on ARM_PSCI_FW
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 935540d1719..3e4cae60c17 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -992,7 +992,7 @@ static const struct sdhci_ops arasan_ops = {
};
[PATCH] arm64: zynqmp: Setup multiboot register to 0
On Kria when board starts from Image A or Image B partition multiboot
register is already setup to that location. When reset command is called
board is issuing soft reset which start SW at already used location (offset
of multiboot * 32k).
But board should continue to run from multiboot offset 0 (start of QSPI)
and call early bootloader every reboot that's why clear multiboot register
to 0 by default to go that route all the time.
Signed-off-by: Michal Simek
---
board/xilinx/zynqmp/zynqmp_kria.env | 1 +
1 file changed, 1 insertion(+)
diff --git a/board/xilinx/zynqmp/zynqmp_kria.env
b/board/xilinx/zynqmp/zynqmp_kria.env
index 846eceb0118d..69e333c53887 100644
--- a/board/xilinx/zynqmp/zynqmp_kria.env
+++ b/board/xilinx/zynqmp/zynqmp_kria.env
@@ -65,6 +65,7 @@ kd240_setup=i2c dev 1 && run usb_hub_init;zynqmp pmufw node
33; zynqmp pmufw nod
tpm_setup=tpm autostart;
board_setup=\
+zynqmp mmio_write 0xFFCA0010 0xfff 0; \
if test ${card1_name} = SCK-KV-G; then run kv260_setup; fi;\
if test ${card1_name} = SCK-KR-G; then run kr260_setup; fi;\
if test ${card1_name} = SCK-KD-G; then run kd240_setup; fi;\
--
2.40.1
Re: [PATCH] xilinx: Add option to load environment from outside of boot media
On 5/31/24 12:09, Vasileios Amoiridis wrote: Currently, if the environment is not in the current boot media, the env_get_location() is returning ENVL_UNKNOWN or ENVL_NOWHERE which is not true (i.e booting from FLASH with environment in eMMC). This commit adds an extra check to find the environment in the other supported boot media, keeping the same priority as of now. Signed-off-by: Vasileios Amoiridis This is v2 right? Please label it like that with also change log. M
Re: [PATCH v3 05/25] md5: Remove md5 non-watchdog API
On 5/28/24 16:09, Raymond Mao wrote: We don't need an API specially for non-watchdog since md5_wd supports it by enabling CONFIG_HW_WATCHDOG or CONFIG_WATCHDOG. Set 0x1 as default chunk size for MD5. Signed-off-by: Raymond Mao --- Changes in v3 - Initial patch. board/friendlyarm/nanopi2/board.c | 3 ++- board/intel/edison/edison.c | 3 ++- board/xilinx/zynq/bootimg.c | 2 +- include/u-boot/md5.h | 7 +-- lib/md5.c | 15 --- 5 files changed, 6 insertions(+), 24 deletions(-) diff --git a/board/friendlyarm/nanopi2/board.c b/board/friendlyarm/nanopi2/board.c index 393c5a447d6..f203499f544 100644 --- a/board/friendlyarm/nanopi2/board.c +++ b/board/friendlyarm/nanopi2/board.c @@ -264,7 +264,8 @@ static void make_ether_addr(u8 *addr) hash[6] = readl(PHY_BASEADDR_ECID + 0x08); hash[7] = readl(PHY_BASEADDR_ECID + 0x0c); - md5((unsigned char *)[4], 64, (unsigned char *)hash); + md5_wd((unsigned char *)[4], 64, (unsigned char *)hash, + MD5_DEF_CHUNK_SZ); hash[0] ^= hash[2]; hash[1] ^= hash[3]; diff --git a/board/intel/edison/edison.c b/board/intel/edison/edison.c index 11e7f74e47c..1583d11c74d 100644 --- a/board/intel/edison/edison.c +++ b/board/intel/edison/edison.c @@ -33,7 +33,8 @@ static void assign_serial(void) if (!mmc) return; - md5((unsigned char *)mmc->cid, sizeof(mmc->cid), ssn); + md5_wd((unsigned char *)mmc->cid, sizeof(mmc->cid), ssn, + MD5_DEF_CHUNK_SZ); snprintf(usb0addr, sizeof(usb0addr), "02:00:86:%02x:%02x:%02x", ssn[13], ssn[14], ssn[15]); diff --git a/board/xilinx/zynq/bootimg.c b/board/xilinx/zynq/bootimg.c index 2f55078dd76..4b2245c0618 100644 --- a/board/xilinx/zynq/bootimg.c +++ b/board/xilinx/zynq/bootimg.c @@ -136,7 +136,7 @@ int zynq_validate_partition(u32 start_addr, u32 len, u32 chksum_off) memcpy([0], (u32 *)chksum_off, MD5_CHECKSUM_SIZE); - md5_wd((u8 *)start_addr, len, [0], 0x1); + md5_wd((u8 *)start_addr, len, [0], MD5_DEF_CHUNK_SZ); if (!memcmp(checksum, calchecksum, MD5_CHECKSUM_SIZE)) return 0; Reviewed-by: Michal Simek # zynq M
Re: [PATCH] arm64: zynqmp: Update rproc node
On 5/31/24 00:16, Tanmay Shah wrote:
On 5/30/24 5:39 AM, Michal Simek wrote:
remoteproc node should be updated to be aligned with the latest dt-schema.
Signed-off-by: Michal Simek
---
Once we push all dts to Linux we can change to OF_UPSTREAM but till that
time we need to keep DTSes in sync.
---
arch/arm/dts/zynqmp.dtsi | 67 +--
include/dt-bindings/power/xlnx-zynqmp-power.h | 17 ++---
2 files changed, 68 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 53a606c340a4..34f592c1a85f 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -314,19 +314,76 @@
ranges;
};
- remoteproc {
+ rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
+ xlnx,tcm-mode = <1>;
- r5f-0 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+ reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_0_fw_image>;
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_1_fw_image>;
+ };
+ };
+
+ rproc_split: remoteproc-split@ffe0 {
+ status = "disabled";
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+ xlnx,tcm-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+ r5f@0 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_0>;
+ reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
memory-region = <_0_fw_image>;
};
- r5f-1 {
+ r5f@1 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_1>;
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
memory-region = <_1_fw_image>;
};
};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h
b/include/dt-bindings/power/xlnx-zynqmp-power.h
index e7eb0960480a..618024cbb20d 100644
--- a/include/dt-bindings/power/xlnx-zynqmp-power.h
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -6,16 +6,12 @@
#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
#define _DT_BINDINGS_ZYNQMP_POWER
Re: [PATCH 0/4] arm64: versal2: Add support for new AMD Versal Gen 2 SoC
On 5/30/24 16:08, Tom Rini wrote:
On Thu, May 30, 2024 at 08:04:07AM +0200, Michal Simek wrote:
Hi Tom,
On 5/29/24 18:13, Tom Rini wrote:
On Wed, May 29, 2024 at 04:47:57PM +0200, Michal Simek wrote:
Hi,
I am sending patches for adding initial support for new AMD Versal Gen 2
SoC. If you want to find out more information please take a look at this
page:
https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal.html
Thanks,
Michal
Michal Simek (4):
arm64: versal2: Add support for AMD Versal Gen 2
soc: versal2: Add SoC driver for AMD Versal Gen 2
mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2
spi: versal2: Enable spi drivers for Versal Gen 2
My only concerns are name-related and not-blocking. First, should we
perhaps instead have arch/arm/mach-versal/{gen2,net}/ (and presumably
gen2-net down the line)?
There are completely 3 different SOCs only names are similar
Versal is 2 cores a72
Versal NET 16 cores a78
Versal Gen 2 8 cores a78
with different features.
That's good to know.
Creating subfolders under current mach-versal would be very confusing.
We can definitely try to make it as small as possible but still they are
separated families.
Again, I'm not nak'ing things based on the names but I'll point out that
arch/arm/mach-k3/{am*,j7*}/ contain a good number of A53 and A72
platforms of varying numbers of cores. But on the other hand, at some
level they're all part of the "Keystone 3" generation / family, which is
not how the Versal parts are handled.
For us it is completely new generation. There are some sub variants which can be
handled like that. https://docs.amd.com/v/u/en-US/versal-ai-edge-gen2-psg
AI Edge, AI Core, Prime, Premium, HBM but we trying to handle it via
common/shared target. If there is a difference we are trying to handle via DT
and enable all drivers via generic defconfig.
We can definitely take a look if make sense to create mach-xilinx or mach-amd.
It would be best if we can pretty much get rid of all these folders but I don't
think we get there anytime soon.
We tried to reuse existing platforms but it is hard to keep it in sync
that's why new platform is better way to go.
But as you know we are trying to reuse for example board/xilinx/common/
folder as much as possible that we don't have code duplication.
That's also good and reasonable.
Second, and I see I can't say we should follow
the Linux kernel since there's no versal dts files upstream, should we
still be "xilinx" and not "amd" ? I do see the kernel shoves all the
imx8 (as an example of a modern part) stuff under
arch/arm64/boot/dts/freescale/ and if nothing else we should be
consistent between projects whenever possible. Thanks.
I am not going to send DTSes to U-Boot and just push them to Linux kernel at
right time. And target is arch/arm64/boot/dts/amd which already exists for
old amd socs and elba (pensando). Versal Gen 2 should go there.
It means Versal and Versal NET will be branded under Xilinx and Versal Gen 2
will be branded under AMD. Also we are going to stop to use xlnx, dt
prefixes for new IPs and will start to use amd, prefix.
My real only concern here is that we're consistent with whatever Linux
Kernel people demand. It's bikeshedding I'm really not inclined to argue
myself. :)
What we looked in past was if we can put together platforms with gicv2 and gicv3
because there is low level GIC initialization when you run in EL3 but we didn't
finish it.
I think the first step would be to get rid of include/configs/ files and then we
can look at other parts.
Thanks,
Michal
Re: [PATCH 0/4] arm64: versal2: Add support for new AMD Versal Gen 2 SoC
Hi Tom,
On 5/29/24 18:13, Tom Rini wrote:
On Wed, May 29, 2024 at 04:47:57PM +0200, Michal Simek wrote:
Hi,
I am sending patches for adding initial support for new AMD Versal Gen 2
SoC. If you want to find out more information please take a look at this
page:
https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal.html
Thanks,
Michal
Michal Simek (4):
arm64: versal2: Add support for AMD Versal Gen 2
soc: versal2: Add SoC driver for AMD Versal Gen 2
mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2
spi: versal2: Enable spi drivers for Versal Gen 2
My only concerns are name-related and not-blocking. First, should we
perhaps instead have arch/arm/mach-versal/{gen2,net}/ (and presumably
gen2-net down the line)?
There are completely 3 different SOCs only names are similar
Versal is 2 cores a72
Versal NET 16 cores a78
Versal Gen 2 8 cores a78
with different features.
Creating subfolders under current mach-versal would be very confusing.
We can definitely try to make it as small as possible but still they are
separated families.
We tried to reuse existing platforms but it is hard to keep it in sync that's
why new platform is better way to go.
But as you know we are trying to reuse for example board/xilinx/common/ folder
as much as possible that we don't have code duplication.
Second, and I see I can't say we should follow
the Linux kernel since there's no versal dts files upstream, should we
still be "xilinx" and not "amd" ? I do see the kernel shoves all the
imx8 (as an example of a modern part) stuff under
arch/arm64/boot/dts/freescale/ and if nothing else we should be
consistent between projects whenever possible. Thanks.
I am not going to send DTSes to U-Boot and just push them to Linux kernel at
right time. And target is arch/arm64/boot/dts/amd which already exists for old
amd socs and elba (pensando). Versal Gen 2 should go there.
It means Versal and Versal NET will be branded under Xilinx and Versal Gen 2
will be branded under AMD. Also we are going to stop to use xlnx, dt prefixes
for new IPs and will start to use amd, prefix.
Thanks,
Michal
Re: [PATCH v3 0/2] Introduce spl_soc_init() for SoC specific initialization
Hi, pá 3. 5. 2024 v 8:10 odesílatel Lukas Funke napsal: > > Hi Michal, > > On 10.04.2024 09:06, Michal Simek wrote: > > Hi, > > > > On 4/8/24 14:59, Michal Simek wrote: > >> > >> > >> On 3/27/24 13:11, lukas.funke-...@weidmueller.com wrote: > >>> From: Lukas Funke > >>> > >>> > >>> Currently some vendors use spl_board_init() for their SoC > >>> specific initialization. This prohibits board developers from adding > >>> board init code using said function. This series introduces a new > >>> function in order to separate SoC init code from board init code. > >>> > >>> > >>> Changes in v3: > >>> - Rephrase Kconfig description and correct minor typo > >>> > >>> Changes in v2: > >>> - Change spl_arch_init() to spl_soc_init() > >>> > >>> Lukas Funke (2): > >>>spl: Introduce SoC specific init function > >>>arm64: zynq(mp): Rename spl_board_init() to spl_soc_init() > >>> > >>> arch/arm/Kconfig | 4 ++-- > >>> arch/arm/mach-zynq/spl.c | 4 ++-- > >>> arch/arm/mach-zynqmp/spl.c | 4 ++-- > >>> common/spl/Kconfig | 7 +++ > >>> common/spl/spl.c | 3 +++ > >>> include/spl.h | 8 > >>> 6 files changed, 24 insertions(+), 6 deletions(-) > >>> > >> > >> Applied. > > > > Actually I need to drop these two patches. > > I pushed it to CI and got this error. > > > > Building current source for 1 boards (1 thread, 32 jobs per thread) > > riscv64: + sifive_unleashed > > +In file included from board/sifive/unleashed/spl.c:17: > > +include/asm/arch/spl.h:12:5: error: conflicting types for > > 'spl_soc_init'; have 'int(void)' > > + 12 | int spl_soc_init(void); > > + | ^~~~ > > +In file included from board/sifive/unleashed/spl.c:10: > > +include/spl.h:825:6: note: previous declaration of 'spl_soc_init' with > > type 'void(void)' > > + 825 | void spl_soc_init(void); > > + | ^~~~ > > +make[3]: *** [scripts/Makefile.build:257: > > spl/board/sifive/unleashed/spl.o] Error 1 > > +make[2]: *** [scripts/Makefile.spl:533: spl/board/sifive/unleashed] > > Error 2 > > +make[1]: *** [Makefile:2055: spl/u-boot-spl] Error 2 > > +make: *** [Makefile:177: sub-make] Error 2 > > > > And it is valid because Risc-V guys are already using it. > > The issue should be fixed on master. The function name was changed from > spl_soc_init to spl_dram_init. The patch should apply now. Could you > give it another try? Looks good now. Applied. M --- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH] arm64: zynqmp: Update rproc node
remoteproc node should be updated to be aligned with the latest dt-schema.
Signed-off-by: Michal Simek
---
Once we push all dts to Linux we can change to OF_UPSTREAM but till that
time we need to keep DTSes in sync.
---
arch/arm/dts/zynqmp.dtsi | 67 +--
include/dt-bindings/power/xlnx-zynqmp-power.h | 17 ++---
2 files changed, 68 insertions(+), 16 deletions(-)
diff --git a/arch/arm/dts/zynqmp.dtsi b/arch/arm/dts/zynqmp.dtsi
index 53a606c340a4..34f592c1a85f 100644
--- a/arch/arm/dts/zynqmp.dtsi
+++ b/arch/arm/dts/zynqmp.dtsi
@@ -314,19 +314,76 @@
ranges;
};
- remoteproc {
+ rproc_lockstep: remoteproc@ffe0 {
compatible = "xlnx,zynqmp-r5fss";
xlnx,cluster-mode = <1>;
+ xlnx,tcm-mode = <1>;
- r5f-0 {
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x0 0x1 0x0 0xffe1 0x0 0x1>,
+<0x0 0x3 0x0 0xffe3 0x0 0x1>;
+
+ r5f@0 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x0 0x0 0x0 0x1>,
+ <0x0 0x2 0x0 0x1>,
+ <0x0 0x1 0x0 0x1>,
+ <0x0 0x3 0x0 0x1>;
+ reg-names = "atcm0", "btcm0", "atcm1", "btcm1";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_0_fw_image>;
+ };
+
+ r5f@1 {
+ compatible = "xlnx,zynqmp-r5f";
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
+ memory-region = <_1_fw_image>;
+ };
+ };
+
+ rproc_split: remoteproc-split@ffe0 {
+ status = "disabled";
+ compatible = "xlnx,zynqmp-r5fss";
+ xlnx,cluster-mode = <0>;
+ xlnx,tcm-mode = <0>;
+
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ ranges = <0x0 0x0 0x0 0xffe0 0x0 0x1>,
+<0x0 0x2 0x0 0xffe2 0x0 0x1>,
+<0x1 0x0 0x0 0xffe9 0x0 0x1>,
+<0x1 0x2 0x0 0xffeb 0x0 0x1>;
+
+ r5f@0 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_0>;
+ reg = <0x0 0x0 0x0 0x1>, <0x0 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_0>,
+ <_firmware PD_R5_0_ATCM>,
+ <_firmware PD_R5_0_BTCM>;
memory-region = <_0_fw_image>;
};
- r5f-1 {
+ r5f@1 {
compatible = "xlnx,zynqmp-r5f";
- power-domains = <_firmware PD_RPU_1>;
+ reg = <0x1 0x0 0x0 0x1>, <0x1 0x2 0x0 0x1>;
+ reg-names = "atcm0", "btcm0";
+ power-domains = <_firmware PD_RPU_1>,
+ <_firmware PD_R5_1_ATCM>,
+ <_firmware PD_R5_1_BTCM>;
memory-region = <_1_fw_image>;
};
};
diff --git a/include/dt-bindings/power/xlnx-zynqmp-power.h
b/include/dt-bindings/power/xlnx-zynqmp-power.h
index e7eb0960480a..618024cbb20d 100644
--- a/include/dt-bindings/power/xlnx-zynqmp-power.h
+++ b/include/dt-bindings/power/xlnx-zynqmp-power.h
@@ -6,16 +6,12 @@
#ifndef _DT_BINDINGS_ZYNQMP_POWER_H
#define _DT_BINDINGS_ZYNQMP_POWER_H
-#definePD_RPU_06
-#define
[PATCH] efi_loader: Fix capsule_esl.dtsi.in comment style
Comment is not kernel-doc format that's why don't label it like that and
also fix indentation to have proper multiline comment.
Signed-off-by: Michal Simek
---
lib/efi_loader/capsule_esl.dtsi.in | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/capsule_esl.dtsi.in
b/lib/efi_loader/capsule_esl.dtsi.in
index 61a9f2b25e9f..bc7db836faa8 100644
--- a/lib/efi_loader/capsule_esl.dtsi.in
+++ b/lib/efi_loader/capsule_esl.dtsi.in
@@ -1,9 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
-/**
+/*
* Devicetree file with the public key EFI Signature List(ESL)
* node. This file is used to generate the dtsi file to be
* included into the DTB.
-*/
+ */
/ {
signature {
capsule-key = /incbin/("ESL_BIN_FILE");
--
2.40.1
[PATCH 1/4] arm64: versal2: Add support for AMD Versal Gen 2
Add support for AMD Versal Gen 2. SoC is based on Cortex-a78ae 4 cluster/2
cpu core each. A lot of IPs are shared with previous families. There are
couple of new IP blocks where the most interesting from user point of view
is UFS.
Signed-off-by: Michal Simek
---
arch/arm/Kconfig | 14 +
arch/arm/Makefile | 1 +
arch/arm/dts/Makefile | 2 +
arch/arm/dts/amd-versal2-virt.dts | 11 +
arch/arm/mach-versal2/Kconfig | 55 +++
arch/arm/mach-versal2/Makefile| 10 +
arch/arm/mach-versal2/clk.c | 34 ++
arch/arm/mach-versal2/cpu.c | 93 +
arch/arm/mach-versal2/include/mach/hardware.h | 97 +
.../arm/mach-versal2/include/mach/sys_proto.h | 9 +
board/amd/common | 1 +
board/amd/versal2/Kconfig | 16 +
board/amd/versal2/MAINTAINERS | 7 +
board/amd/versal2/Makefile| 11 +
board/amd/versal2/board.c | 343 ++
board/amd/versal2/cmds.c | 81 +
board/xilinx/Kconfig | 6 +-
configs/amd_versal2_virt_defconfig| 145
drivers/gpio/Kconfig | 2 +-
drivers/mailbox/Kconfig | 2 +-
env/Kconfig | 6 +-
include/configs/amd_versal2.h | 143
22 files changed, 1081 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/dts/amd-versal2-virt.dts
create mode 100644 arch/arm/mach-versal2/Kconfig
create mode 100644 arch/arm/mach-versal2/Makefile
create mode 100644 arch/arm/mach-versal2/clk.c
create mode 100644 arch/arm/mach-versal2/cpu.c
create mode 100644 arch/arm/mach-versal2/include/mach/hardware.h
create mode 100644 arch/arm/mach-versal2/include/mach/sys_proto.h
create mode 12 board/amd/common
create mode 100644 board/amd/versal2/Kconfig
create mode 100644 board/amd/versal2/MAINTAINERS
create mode 100644 board/amd/versal2/Makefile
create mode 100644 board/amd/versal2/board.c
create mode 100644 board/amd/versal2/cmds.c
create mode 100644 configs/amd_versal2_virt_defconfig
create mode 100644 include/configs/amd_versal2.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6d9a4c993c34..db692b2d215a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1235,6 +1235,18 @@ config ARCH_VERSAL
imply BOARD_LATE_INIT
imply ENV_VARS_UBOOT_RUNTIME_CONFIG
+config ARCH_VERSAL2
+ bool "Support AMD Versal Gen 2 Platform"
+ select ARM64
+ select CLK
+ select DM
+ select DM_MMC if MMC
+ select DM_SERIAL
+ select OF_CONTROL
+ imply BOARD_LATE_INIT
+ imply ENV_VARS_UBOOT_RUNTIME_CONFIG
+ imply ZYNQMP_FIRMWARE
+
config ARCH_VERSAL_NET
bool "Support Xilinx Versal NET Platform"
select ARM64
@@ -2317,6 +2329,8 @@ source "arch/arm/mach-zynqmp/Kconfig"
source "arch/arm/mach-versal/Kconfig"
+source "arch/arm/mach-versal2/Kconfig"
+
source "arch/arm/mach-versal-net/Kconfig"
source "arch/arm/mach-zynqmp-r5/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 734c6d69926b..dbeedbe544bd 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -90,6 +90,7 @@ machine-$(CONFIG_ARCH_OCTEONTX) += octeontx
machine-$(CONFIG_ARCH_OCTEONTX2) += octeontx2
machine-$(CONFIG_ARCH_UNIPHIER)+= uniphier
machine-$(CONFIG_ARCH_VERSAL) += versal
+machine-$(CONFIG_ARCH_VERSAL2) += versal2
machine-$(CONFIG_ARCH_VERSAL_NET) += versal-net
machine-$(CONFIG_ARCH_ZYNQ)+= zynq
machine-$(CONFIG_ARCH_ZYNQMP) += zynqmp
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f7032f1e1755..45f866dd185b 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -345,6 +345,8 @@ dtb-$(CONFIG_ARCH_VERSAL) += \
versal-mini-qspi-x2-single.dtb \
versal-mini-qspi-x2-stacked.dtb \
xilinx-versal-virt.dtb
+dtb-$(CONFIG_ARCH_VERSAL2) += \
+ amd-versal2-virt.dtb
dtb-$(CONFIG_ARCH_VERSAL_NET) += \
versal-net-mini.dtb \
versal-net-mini-emmc.dtb \
diff --git a/arch/arm/dts/amd-versal2-virt.dts
b/arch/arm/dts/amd-versal2-virt.dts
new file mode 100644
index ..3b6cbbac5820
--- /dev/null
+++ b/arch/arm/dts/amd-versal2-virt.dts
@@ -0,0 +1,11 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Empty device tree for amd-versal2-virt board
+ *
+ * Copyright (C) 2024, Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/arch/arm/mach-versal2/Kconfig b/arch/arm/mach-versal2/Kconfig
new file mode 100644
index ..3f18e3351aa8
--- /dev/null
+++ b/arch/arm/mach-versal2/Kconfig
@@ -0,0 +1,55 @@
+# SPDX-License-Identifier: GPL-2.0
+
+if ARCH_V
[PATCH 0/4] arm64: versal2: Add support for new AMD Versal Gen 2 SoC
Hi, I am sending patches for adding initial support for new AMD Versal Gen 2 SoC. If you want to find out more information please take a look at this page: https://www.amd.com/en/products/adaptive-socs-and-fpgas/versal.html Thanks, Michal Michal Simek (4): arm64: versal2: Add support for AMD Versal Gen 2 soc: versal2: Add SoC driver for AMD Versal Gen 2 mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2 spi: versal2: Enable spi drivers for Versal Gen 2 arch/arm/Kconfig | 14 + arch/arm/Makefile | 1 + arch/arm/dts/Makefile | 2 + arch/arm/dts/amd-versal2-virt.dts | 11 + arch/arm/mach-versal2/Kconfig | 55 +++ arch/arm/mach-versal2/Makefile| 10 + arch/arm/mach-versal2/clk.c | 34 ++ arch/arm/mach-versal2/cpu.c | 93 + arch/arm/mach-versal2/include/mach/hardware.h | 97 + .../arm/mach-versal2/include/mach/sys_proto.h | 9 + board/amd/common | 1 + board/amd/versal2/Kconfig | 16 + board/amd/versal2/MAINTAINERS | 7 + board/amd/versal2/Makefile| 11 + board/amd/versal2/board.c | 343 ++ board/amd/versal2/cmds.c | 81 + board/xilinx/Kconfig | 6 +- configs/amd_versal2_virt_defconfig| 150 drivers/gpio/Kconfig | 2 +- drivers/mailbox/Kconfig | 2 +- drivers/mmc/zynq_sdhci.c | 22 +- drivers/soc/Kconfig | 8 + drivers/soc/Makefile | 1 + drivers/soc/soc_amd_versal2.c | 77 drivers/spi/Kconfig | 2 +- drivers/spi/cadence_qspi.c| 3 +- drivers/spi/zynqmp_gqspi.c| 6 +- env/Kconfig | 6 +- include/configs/amd_versal2.h | 143 29 files changed, 1193 insertions(+), 20 deletions(-) create mode 100644 arch/arm/dts/amd-versal2-virt.dts create mode 100644 arch/arm/mach-versal2/Kconfig create mode 100644 arch/arm/mach-versal2/Makefile create mode 100644 arch/arm/mach-versal2/clk.c create mode 100644 arch/arm/mach-versal2/cpu.c create mode 100644 arch/arm/mach-versal2/include/mach/hardware.h create mode 100644 arch/arm/mach-versal2/include/mach/sys_proto.h create mode 12 board/amd/common create mode 100644 board/amd/versal2/Kconfig create mode 100644 board/amd/versal2/MAINTAINERS create mode 100644 board/amd/versal2/Makefile create mode 100644 board/amd/versal2/board.c create mode 100644 board/amd/versal2/cmds.c create mode 100644 configs/amd_versal2_virt_defconfig create mode 100644 drivers/soc/soc_amd_versal2.c create mode 100644 include/configs/amd_versal2.h -- 2.40.1
Re: [RFC PATCH v1 1/1] mmc: zynq_sdhci: Only evaluate card-stable signal if card was detected
On 4/24/24 10:23, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
On ZynqMp there seems to be a dependency between the card-stable bit and
the card-detect bit. The card-stable bit is set *if and only if*
the card-detect bit was set before, indicating that the signal was
stable and reliable during card insertion.
If the card-detect bit is *not* evaluated the corresponding check leads
to a timeout indicating that the card-detect was not stable.
Signed-off-by: Lukas Funke
---
drivers/mmc/zynq_sdhci.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 935540d171..d0bccd41cc 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -1168,11 +1168,14 @@ static int arasan_sdhci_probe(struct udevice *dev)
*/
if (IS_ENABLED(CONFIG_ARCH_ZYNQMP) || IS_ENABLED(CONFIG_ARCH_VERSAL)) {
u32 timeout = 100;
+ u32 value;
- while (((sdhci_readl(host, SDHCI_PRESENT_STATE) &
-SDHCI_CARD_STATE_STABLE) == 0) && timeout) {
+ value = sdhci_readl(host, SDHCI_PRESENT_STATE);
+ while ((value & SDHCI_CARD_PRESENT) &&
+ ((value & SDHCI_CARD_STATE_STABLE) == 0) && timeout) {
udelay(1);
timeout--;
+ value = sdhci_readl(host, SDHCI_PRESENT_STATE);
}
if (!timeout) {
dev_err(dev, "Sdhci card detect state not stable\n");
Venkatesh: Can you please take a look at this?
Thanks,
Michal
[PATCH 4/4] spi: versal2: Enable spi drivers for Versal Gen 2
Enable and update OSPI/QSPI/GQSPI drivers to support Versal Gen 2 SoCs.
Signed-off-by: Michal Simek
---
configs/amd_versal2_virt_defconfig | 4 +++-
drivers/spi/Kconfig| 2 +-
drivers/spi/cadence_qspi.c | 3 ++-
drivers/spi/zynqmp_gqspi.c | 6 --
4 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/configs/amd_versal2_virt_defconfig
b/configs/amd_versal2_virt_defconfig
index b74e69be28c4..6e4adddf2c02 100644
--- a/configs/amd_versal2_virt_defconfig
+++ b/configs/amd_versal2_virt_defconfig
@@ -5,7 +5,6 @@ CONFIG_SYS_INIT_SP_BSS_OFFSET=1572864
CONFIG_ARCH_VERSAL2=y
CONFIG_TEXT_BASE=0x800
CONFIG_SYS_MALLOC_F_LEN=0x10
-CONFIG_DM_GPIO=y
CONFIG_DEFAULT_DEVICE_TREE="amd-versal2-virt"
CONFIG_OF_LIBFDT_OVERLAY=y
CONFIG_DM_RESET=y
@@ -124,7 +123,10 @@ CONFIG_SOC_DEVICE=y
CONFIG_SOC_AMD_VERSAL2=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
+CONFIG_CADENCE_QSPI=y
+CONFIG_CADENCE_OSPI_VERSAL=y
CONFIG_ZYNQ_SPI=y
+CONFIG_ZYNQMP_GQSPI=y
CONFIG_TPM2_TIS_SPI=y
CONFIG_USB=y
CONFIG_DM_USB_GADGET=y
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 35030ab35561..cd785aefd56e 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -156,7 +156,7 @@ config CQSPI_REF_CLK
config CADENCE_OSPI_VERSAL
bool "Configure Versal OSPI"
- depends on (ARCH_VERSAL || ARCH_VERSAL_NET) && CADENCE_QSPI
+ depends on (ARCH_VERSAL || ARCH_VERSAL_NET || ARCH_VERSAL2) &&
CADENCE_QSPI
imply DM_GPIO
help
This option is used to enable Versal OSPI DMA operations which
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 75e522320101..9c466f8695e2 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -253,7 +253,8 @@ static int cadence_spi_probe(struct udevice *bus)
/* Versal and Versal-NET use spi calibration to set read delay */
if (CONFIG_IS_ENABLED(ARCH_VERSAL) ||
- CONFIG_IS_ENABLED(ARCH_VERSAL_NET))
+ CONFIG_IS_ENABLED(ARCH_VERSAL_NET) ||
+ CONFIG_IS_ENABLED(ARCH_VERSAL2))
if (priv->read_delay >= 0)
priv->read_delay = -1;
diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
index 61349a4da53f..ae795e50b0a5 100644
--- a/drivers/spi/zynqmp_gqspi.c
+++ b/drivers/spi/zynqmp_gqspi.c
@@ -106,7 +106,8 @@
#define TAP_DLY_BYPASS_LQSPI_RX_SHIFT 2
#define GQSPI_DATA_DLY_ADJ_OFST0x01F8
#define IOU_TAPDLY_BYPASS_OFST !(IS_ENABLED(CONFIG_ARCH_VERSAL) || \
-IS_ENABLED(CONFIG_ARCH_VERSAL_NET)) ? \
+IS_ENABLED(CONFIG_ARCH_VERSAL_NET) || \
+IS_ENABLED(CONFIG_ARCH_VERSAL2)) ? \
0xFF180390 : 0xF103003C
#define GQSPI_LPBK_DLY_ADJ_LPBK_MASK 0x0020
#define GQSPI_FREQ_37_5MHZ 3750
@@ -316,7 +317,8 @@ static void zynqmp_qspi_set_tapdelay(struct udevice *bus,
u32 baudrateval)
__func__, clk_rate, baudrateval, reqhz);
if (!(IS_ENABLED(CONFIG_ARCH_VERSAL) ||
- IS_ENABLED(CONFIG_ARCH_VERSAL_NET))) {
+ IS_ENABLED(CONFIG_ARCH_VERSAL_NET) ||
+ IS_ENABLED(CONFIG_ARCH_VERSAL2))) {
if (reqhz <= GQSPI_FREQ_40MHZ) {
tapdlybypass = TAP_DLY_BYPASS_LQSPI_RX_VALUE <<
TAP_DLY_BYPASS_LQSPI_RX_SHIFT;
--
2.40.1
[PATCH 3/4] mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2
Enable tap delay programming for new SoC and also enable it via defconfig.
Signed-off-by: Michal Simek
---
configs/amd_versal2_virt_defconfig | 2 ++
drivers/mmc/zynq_sdhci.c | 22 ++
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/configs/amd_versal2_virt_defconfig
b/configs/amd_versal2_virt_defconfig
index 8ef86f1f3830..b74e69be28c4 100644
--- a/configs/amd_versal2_virt_defconfig
+++ b/configs/amd_versal2_virt_defconfig
@@ -87,6 +87,8 @@ CONFIG_MMC_IO_VOLTAGE=y
CONFIG_MMC_UHS_SUPPORT=y
CONFIG_MMC_HS400_SUPPORT=y
CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_ZYNQ=y
+CONFIG_ZYNQ_SDHCI_MIN_FREQ=10
CONFIG_MTD=y
CONFIG_DM_SPI_FLASH=y
CONFIG_SPI_FLASH_GIGADEVICE=y
diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 8a83adef4342..28d2b456fbf6 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -122,7 +122,8 @@ __weak int zynqmp_pm_is_function_supported(const u32
api_id, const u32 id)
return 1;
}
-#if defined(CONFIG_ARCH_ZYNQMP) || defined(CONFIG_ARCH_VERSAL) ||
defined(CONFIG_ARCH_VERSAL_NET)
+#if defined(CONFIG_ARCH_ZYNQMP) || defined(CONFIG_ARCH_VERSAL) || \
+defined(CONFIG_ARCH_VERSAL_NET) || defined(CONFIG_ARCH_VERSAL2)
/* Default settings for ZynqMP Clock Phases */
static const u32 zynqmp_iclk_phases[] = {0, 63, 63, 0, 63, 0,
0, 183, 54, 0, 0};
@@ -156,7 +157,7 @@ static const u8 mode2timing[] = {
[MMC_HS_400] = MMC_TIMING_MMC_HS400,
};
-#if defined(CONFIG_ARCH_VERSAL_NET)
+#if defined(CONFIG_ARCH_VERSAL_NET) || defined(CONFIG_ARCH_VERSAL2)
/**
* arasan_phy_set_delaychain - Set eMMC delay chain based Input/Output clock
*
@@ -866,7 +867,8 @@ static int arasan_sdhci_set_tapdelay(struct sdhci_host
*host)
if (ret)
return ret;
} else if ((IS_ENABLED(CONFIG_ARCH_VERSAL) ||
- IS_ENABLED(CONFIG_ARCH_VERSAL_NET)) &&
+ IS_ENABLED(CONFIG_ARCH_VERSAL_NET) ||
+ IS_ENABLED(CONFIG_ARCH_VERSAL2)) &&
device_is_compatible(dev, "xlnx,versal-8.9a")) {
ret = sdhci_versal_sampleclk_set_phase(host, iclk_phase);
if (ret)
@@ -875,7 +877,8 @@ static int arasan_sdhci_set_tapdelay(struct sdhci_host
*host)
ret = sdhci_versal_sdcardclk_set_phase(host, oclk_phase);
if (ret)
return ret;
- } else if (IS_ENABLED(CONFIG_ARCH_VERSAL_NET) &&
+ } else if ((IS_ENABLED(CONFIG_ARCH_VERSAL_NET) ||
+ IS_ENABLED(CONFIG_ARCH_VERSAL2)) &&
device_is_compatible(dev, "xlnx,versal-net-emmc")) {
if (mmc->clock >= MIN_PHY_CLK_HZ)
if (iclk_phase ==
VERSAL_NET_EMMC_ICLK_PHASE_DDR52_DLY_CHAIN)
@@ -943,7 +946,8 @@ static void arasan_dt_parse_clk_phases(struct udevice *dev)
}
if ((IS_ENABLED(CONFIG_ARCH_VERSAL) ||
-IS_ENABLED(CONFIG_ARCH_VERSAL_NET)) &&
+IS_ENABLED(CONFIG_ARCH_VERSAL_NET) ||
+IS_ENABLED(CONFIG_ARCH_VERSAL2)) &&
device_is_compatible(dev, "xlnx,versal-8.9a")) {
for (i = 0; i <= MMC_TIMING_MMC_HS400; i++) {
clk_data->clk_phase_in[i] = versal_iclk_phases[i];
@@ -951,7 +955,8 @@ static void arasan_dt_parse_clk_phases(struct udevice *dev)
}
}
- if (IS_ENABLED(CONFIG_ARCH_VERSAL_NET) &&
+ if ((IS_ENABLED(CONFIG_ARCH_VERSAL_NET) ||
+IS_ENABLED(CONFIG_ARCH_VERSAL2)) &&
device_is_compatible(dev, "xlnx,versal-net-emmc")) {
for (i = 0; i <= MMC_TIMING_MMC_HS400; i++) {
clk_data->clk_phase_in[i] =
versal_net_emmc_iclk_phases[i];
@@ -987,7 +992,7 @@ static const struct sdhci_ops arasan_ops = {
.platform_execute_tuning= _sdhci_execute_tuning,
.set_delay = _sdhci_set_tapdelay,
.set_control_reg = _set_control_reg,
-#if defined(CONFIG_ARCH_VERSAL_NET)
+#if defined(CONFIG_ARCH_VERSAL_NET) || defined(CONFIG_ARCH_VERSAL2)
.config_dll = _sdhci_config_dll,
#endif
};
@@ -1195,7 +1200,8 @@ static int arasan_sdhci_of_to_plat(struct udevice *dev)
priv->host->name = dev->name;
-#if defined(CONFIG_ARCH_ZYNQMP) || defined(CONFIG_ARCH_VERSAL) ||
defined(CONFIG_ARCH_VERSAL_NET)
+#if defined(CONFIG_ARCH_ZYNQMP) || defined(CONFIG_ARCH_VERSAL) ||
defined(CONFIG_ARCH_VERSAL_NET) || \
+defined(CONFIG_ARCH_VERSAL2)
priv->host->ops = _ops;
arasan_dt_parse_clk_phases(dev);
#endif
--
2.40.1
[PATCH 2/4] soc: versal2: Add SoC driver for AMD Versal Gen 2
Communication is happening via firmware interface (SMC) or via direct
register reading if firmware driver is not available.
Also enable it via defconfig.
Signed-off-by: Michal Simek
---
configs/amd_versal2_virt_defconfig | 1 +
drivers/soc/Kconfig| 8
drivers/soc/Makefile | 1 +
drivers/soc/soc_amd_versal2.c | 77 ++
4 files changed, 87 insertions(+)
create mode 100644 drivers/soc/soc_amd_versal2.c
diff --git a/configs/amd_versal2_virt_defconfig
b/configs/amd_versal2_virt_defconfig
index 5eea07f03f51..8ef86f1f3830 100644
--- a/configs/amd_versal2_virt_defconfig
+++ b/configs/amd_versal2_virt_defconfig
@@ -119,6 +119,7 @@ CONFIG_ARM_DCC=y
CONFIG_PL01X_SERIAL=y
CONFIG_XILINX_UARTLITE=y
CONFIG_SOC_DEVICE=y
+CONFIG_SOC_AMD_VERSAL2=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_ZYNQ_SPI=y
diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 03433bc0e6d2..cee506fe4747 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -9,6 +9,14 @@ config SOC_DEVICE
need different parameters or quirks enabled depending on the
specific device variant in use.
+config SOC_AMD_VERSAL2
+ bool "Enable SoC Device ID driver for AMD Versal Gen 2"
+ depends on SOC_DEVICE && ARCH_VERSAL2
+ help
+ Enable this option to select SoC device id driver for AMD Versal Gen
2.
+ This allows other drivers to verify the SoC familiy & revision using
+ matching SoC attributes.
+
config SOC_DEVICE_TI_K3
depends on SOC_DEVICE && ARCH_K3
bool "Enable SoC Device ID driver for TI K3 SoCs"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 610bf816d40a..5ec89a053165 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -2,6 +2,7 @@
#
# Makefile for the U-Boot SOC specific device drivers.
+obj-$(CONFIG_SOC_AMD_VERSAL2) += soc_amd_versal2.o
obj-$(CONFIG_SOC_SAMSUNG) += samsung/
obj-$(CONFIG_SOC_TI) += ti/
obj-$(CONFIG_SOC_DEVICE) += soc-uclass.o
diff --git a/drivers/soc/soc_amd_versal2.c b/drivers/soc/soc_amd_versal2.c
new file mode 100644
index ..66bcb22b4fa9
--- /dev/null
+++ b/drivers/soc/soc_amd_versal2.c
@@ -0,0 +1,77 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * AMD Versal Gen 2 SOC driver
+ *
+ * Copyright (C) 2022 - 2024, Advanced Micro Devices, Inc.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/*
+ * v1 -> 0x10 - ES1
+ * v2 -> 0x20 - Production
+ */
+static const char versal2_family[] = "Versal Gen 2";
+
+struct soc_amd_versal2_priv {
+ const char *family;
+ char revision;
+};
+
+static int soc_amd_versal2_get_family(struct udevice *dev, char *buf, int size)
+{
+ struct soc_amd_versal2_priv *priv = dev_get_priv(dev);
+
+ return snprintf(buf, size, "%s", priv->family);
+}
+
+static int soc_amd_versal2_get_revision(struct udevice *dev, char *buf, int
size)
+{
+ struct soc_amd_versal2_priv *priv = dev_get_priv(dev);
+
+ return snprintf(buf, size, "v%d", priv->revision);
+}
+
+static const struct soc_ops soc_amd_versal2_ops = {
+ .get_family = soc_amd_versal2_get_family,
+ .get_revision = soc_amd_versal2_get_revision,
+};
+
+static int soc_amd_versal2_probe(struct udevice *dev)
+{
+ struct soc_amd_versal2_priv *priv = dev_get_priv(dev);
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ priv->family = versal2_family;
+
+ if (IS_ENABLED(CONFIG_ZYNQMP_FIRMWARE)) {
+ ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
+ ret_payload);
+ if (ret)
+ return ret;
+ } else {
+ ret_payload[2] = readl(PMC_TAP_VERSION);
+ if (!ret_payload[2])
+ return -EINVAL;
+ }
+
+ priv->revision = FIELD_GET(PS_VERSION_MASK, ret_payload[2]);
+
+ return 0;
+}
+
+U_BOOT_DRIVER(soc_amd_versal2) = {
+ .name = "soc_amd_versal2",
+ .id = UCLASS_SOC,
+ .ops= _amd_versal2_ops,
+ .probe = soc_amd_versal2_probe,
+ .priv_auto = sizeof(struct soc_amd_versal2_priv),
+ .flags = DM_FLAG_PRE_RELOC,
+};
--
2.40.1
Re: [PATCH v2 2/2] drivers: misc: Add driver to access ZynqMP efuses
On 5/15/24 14:41, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add driver to access ZynqMP efuses. This is a u-boot port of [1].
[1]
https://lore.kernel.org/all/20240224114516.86365-8-srinivas.kandaga...@linaro.org/
Signed-off-by: Lukas Funke
---
Changes in v2:
- Drop vendor specific fuse cmd, use existing fuse cmd
- Minor code refactoring (reverse x-mas tree)
drivers/misc/Kconfig| 8 +
drivers/misc/Makefile | 1 +
drivers/misc/zynqmp_efuse.c | 324
3 files changed, 333 insertions(+)
create mode 100644 drivers/misc/zynqmp_efuse.c
would be good to get also 3/3 which enables
CONFIG_CMD_FUSE=y
CONFIG_ZYNQMP_EFUSE=y
in zynqmp defconfigs (virt and kria) to have it enabled.
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 6009d55f400..c07f50c9a76 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -298,6 +298,14 @@ config FSL_SEC_MON
Security Monitor can be transitioned on any security failures,
like software violations or hardware security violations.
+config ZYNQMP_EFUSE
+ bool "Enable ZynqMP eFUSE Driver"
+ depends on ZYNQMP_FIRMWARE
+ help
+ Enable access to Zynq UltraScale (ZynqMP) eFUSEs thought PMU firmware
+ interface. ZnyqMP has 256 eFUSEs where some of them are security
related
+ and cannot be read back (i.e. AES key).
+
choice
prompt "Security monitor interaction endianess"
depends on FSL_SEC_MON
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index e53d52c47b3..68ba5648eab 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -92,3 +92,4 @@ obj-$(CONFIG_ESM_K3) += k3_esm.o
obj-$(CONFIG_ESM_PMIC) += esm_pmic.o
obj-$(CONFIG_SL28CPLD) += sl28cpld.o
obj-$(CONFIG_SPL_SOCFPGA_DT_REG) += socfpga_dtreg.o
+obj-$(CONFIG_ZYNQMP_EFUSE) += zynqmp_efuse.o
diff --git a/drivers/misc/zynqmp_efuse.c b/drivers/misc/zynqmp_efuse.c
new file mode 100644
index 000..98a39c1ebdd
--- /dev/null
+++ b/drivers/misc/zynqmp_efuse.c
@@ -0,0 +1,324 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek
+ *
+ * (C) Copyright 2024 Weidmueller Interface GmbH
+ * Lukas Funke
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SILICON_REVISION_MASK 0xF
+#define P_USER_0_64_UPPER_MASK 0x5FFF
+#define P_USER_127_LOWER_4_BIT_MASK 0xF
+#define WORD_INBYTES (4)
+#define SOC_VER_SIZE (0x4)
+#define SOC_VERSION_OFFSET (0x0)
+#define EFUSE_START_OFFSET (0xC)
+#define EFUSE_END_OFFSET (0xFC)
+#define EFUSE_PUF_START_OFFSET (0x100)
+#define EFUSE_PUF_MID_OFFSET (0x140)
+#define EFUSE_PUF_END_OFFSET (0x17F)
+#define EFUSE_NOT_ENABLED (29)
+#define EFUSE_READ (0)
+#define EFUSE_WRITE(1)
I did compare it with the latest upstream version and there are some differences
which don't need to be there. Above macros for example
+
+/**
+ * struct efuse_map_entry - offset and length of zynqmp fuses
+ * @offset:offset of efuse to be read/write
+ * @length:length of efuse
+ */
+struct efuse_map_entry {
+ u32 offset;
+ u32 length;
+};
+
+struct efuse_map_entry zynqmp_efuse_table[] = {
+ {0x000, 0x04}, /* soc revision */
+ {0x00c, 0x0c}, /* SoC DNA */
+ {0x020, 0x04}, /* efuse-usr0 */
+ {0x024, 0x04}, /* efuse-usr1 */
+ {0x028, 0x04}, /* efuse-usr2 */
+ {0x02c, 0x04}, /* efuse-usr3 */
+ {0x030, 0x04}, /* efuse-usr4 */
+ {0x034, 0x04}, /* efuse-usr5 */
+ {0x038, 0x04}, /* efuse-usr6 */
+ {0x03c, 0x04}, /* efuse-usr7 */
+ {0x040, 0x04}, /* efuse-miscusr */
+ {0x050, 0x04}, /* efuse-chash */
+ {0x054, 0x04}, /* efuse-pufmisc */
+ {0x058, 0x04}, /* efuse-sec */
+ {0x05c, 0x04}, /* efuse-spkid */
+ {0x060, 0x30}, /* efuse-aeskey */
+ {0x0a0, 0x30}, /* ppk0-hash */
+ {0x0d0, 0x30}, /* ppk1-hash */
+ {0x100, 0x7f}, /* pufuser */
+};
+
+/**
+ * struct xilinx_efuse - the basic structure
+ * @src: address of the buffer to store the data to be write/read
+ * @size: no of words to be read/write
+ * @offset:offset to be read/write`
a little bit different description compare to upsream linux
+ * @flag: 0 - represents efuse read and 1- represents efuse write
+ * @pufuserfuse:0 - represents non-puf efuses, offset is used for read/write
+ * 1 - represents puf user fuse row number.
+ *
+ * this structure stores all the required details to
+ * read/write efuse memory.
+ */
+struct xilinx_efuse {
+ u64 src;
+ u32 size;
+ u32 offset;
+ u32 flag;
+ u32 pufuserfuse;
+};
+
+static int zynqmp_efuse_get_length(u32 offset, u32 *base_offset, u32 *len)
+{
+ struct efuse_map_entry *fuse;
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(z
Re: [PATCH v2 0/2] Add eFuse access for ZynqMP
On 5/15/24 14:41, lukas.funke-...@weidmueller.com wrote: From: Lukas Funke This series adds a driver to read and write ZynqMP eFuses [1]. The driver can be accessed by the 'fuse read' and 'fuse write' commands Example: => fuse read 0 0xc 3 Reading bank 0: Word 0x000c: 3cb16685 013af244 4000 Note: Accessing eFuses requires eFuse access to be enabled in the underlying PMU firmware. Can you please put this note to 2/2 commit msg? Thanks, Michal
Re: [PATCH v2 1/2] firmware: zynqmp: Add support to access efuses
On 5/15/24 14:41, lukas.funke-...@weidmueller.com wrote:
From: Lukas Funke
Add functions to access efuses through PMU firmware
interface.
Signed-off-by: Lukas Funke
---
(no changes since v1)
drivers/firmware/firmware-zynqmp.c | 31 ++
include/zynqmp_firmware.h | 2 ++
2 files changed, 33 insertions(+)
diff --git a/drivers/firmware/firmware-zynqmp.c
b/drivers/firmware/firmware-zynqmp.c
index f99507d86c6..d7fbe6a3efb 100644
--- a/drivers/firmware/firmware-zynqmp.c
+++ b/drivers/firmware/firmware-zynqmp.c
@@ -210,6 +210,37 @@ int zynqmp_pm_feature(const u32 api_id)
return ret_payload[1] & FIRMWARE_VERSION_MASK;
}
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!idcode || !version)
+ return -EINVAL;
+
+ ret = xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0, ret_payload);
+ *idcode = ret_payload[1];
+ *version = ret_payload[2];
+
+ return ret;
+}
+
+int zynqmp_pm_efuse_access(const u64 address, u32 *out)
+{
+ u32 ret_payload[PAYLOAD_ARG_CNT];
+ int ret;
+
+ if (!out)
+ return -EINVAL;
+
+ ret = xilinx_pm_request(PM_EFUSE_ACCESS, upper_32_bits(address),
+ lower_32_bits(address), 0, 0, ret_payload);
+
+ *out = ret_payload[1];
+
+ return ret;
+}
+
int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id)
{
int ret;
diff --git a/include/zynqmp_firmware.h b/include/zynqmp_firmware.h
index 73198a6a6ea..7f18b4d59bf 100644
--- a/include/zynqmp_firmware.h
+++ b/include/zynqmp_firmware.h
@@ -453,6 +453,8 @@ int xilinx_pm_request(u32 api_id, u32 arg0, u32 arg1, u32
arg2,
int zynqmp_pm_set_sd_config(u32 node, enum pm_sd_config_type config, u32
value);
int zynqmp_pm_set_gem_config(u32 node, enum pm_gem_config_type config,
u32 value);
+int zynqmp_pm_get_chipid(u32 *idcode, u32 *version);
+int zynqmp_pm_efuse_access(const u64 address, u32 *out);
int zynqmp_pm_is_function_supported(const u32 api_id, const u32 id);
int zynqmp_mmio_read(const u32 address, u32 *value);
int zynqmp_mmio_write(const u32 address, const u32 mask, const u32 value);
This looks good to me.
Will be good to convert soc driver to use zynqmp_pm_get_chipid() but can be done
on the top of this later.
drivers/soc/soc_xilinx_versal.c:53: ret =
xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
drivers/soc/soc_xilinx_versal_net.c:55: ret =
xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
drivers/soc/soc_xilinx_zynqmp.c:356:ret =
xilinx_pm_request(PM_GET_CHIPID, 0, 0, 0, 0,
Thanks,
Michal
Re: [PATCH] xilinx: versal: Do not prioritize boot device if driver is not enabled
On 5/10/24 08:22, Michal Simek wrote:
From: Venkatesh Yadav Abbarapu
SOC can boot out of the device which is not accessible from APU and running
this is detected as a warning, as the device is not accessible.For example
getting below warning when the boot mode is OSPI and OSPI is not enabled in
device tree.
Invalid bus 0 (err=-19)
Failed to initialize SPI flash at 0:0 (error -19)
Ignoring the prioritization of the boot device which driver is not enabled
and continue with the default boot_targets. Recommendation is to use custom
boot_targets via environment file as is done for example for Kria via
zynqmp_kria.env file.
Signed-off-by: Venkatesh Yadav Abbarapu
Signed-off-by: Michal Simek
---
board/xilinx/versal/board.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 4f6d56119db1..f00605da7825 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -151,14 +151,29 @@ static int boot_targets_setup(void)
break;
case QSPI_MODE_24BIT:
puts("QSPI_MODE_24\n");
+ if (uclass_get_device_by_name(UCLASS_SPI,
+ "spi@f103", )) {
+ debug("QSPI driver for QSPI device is not present\n");
+ break;
+ }
mode = "xspi0";
break;
case QSPI_MODE_32BIT:
puts("QSPI_MODE_32\n");
+ if (uclass_get_device_by_name(UCLASS_SPI,
+ "spi@f103", )) {
+ debug("QSPI driver for QSPI device is not present\n");
+ break;
+ }
mode = "xspi0";
break;
case OSPI_MODE:
puts("OSPI_MODE\n");
+ if (uclass_get_device_by_name(UCLASS_SPI,
+ "spi@f101", )) {
+ debug("OSPI driver for OSPI device is not present\n");
+ break;
+ }
mode = "xspi0";
break;
case EMMC_MODE:
Applied.
M
Re: [PATCH ] mtd: spi-nor: Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash part
On 5/8/24 07:27, Prasad Kummari wrote:
Added SPI_NOR_OCTAL_READ flag for Macronix mx66uw2g345gx0 2Gb(256MB)
NOR Flash memory has been added. Initial testing was conducted on the
I fixed this commit message.
Versal NET board using SDR mode, which included basic erase, write,
and read-back operations.
Signed-off-by: Prasad Kummari
---
drivers/mtd/spi/spi-nor-ids.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 4e83b8c94c..dacc26d7b3 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -275,7 +275,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("mx66l2g45g", 0xc2201c, 0, 64 * 1024, 4096, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mx25l1633e", 0xc22415, 0, 64 * 1024, 32, SPI_NOR_QUAD_READ |
SPI_NOR_4B_OPCODES | SECT_4K) },
{ INFO("mx25r6435f", 0xc22817, 0, 64 * 1024, 128, SECT_4K) },
- { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
+ { INFO("mx66uw2g345gx0", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K |
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES | SPI_NOR_OCTAL_READ) },
{ INFO("mx66lm1g45g",0xc2853b, 0, 64 * 1024, 2048, SECT_4K |
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mx25lm51245g", 0xc2853a, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
{ INFO("mx25lw51245g", 0xc2863a, 0, 64 * 1024, 1024, SECT_4K |
SPI_NOR_OCTAL_DTR_READ | SPI_NOR_4B_OPCODES) },
And applied.
M
Re: [PATCH v2] xilinx: zynqmp: Allow multiboot environment write even in saved environment
On 5/29/24 12:01, Kory Maincent wrote:
Once the environment was saved, the current multiboot image information
became unreachable. When dealing with firmware updates, this information
is necessary alongside the saved environment to know the booted image.
Move the multiboot environment set operation before the saved environment
check to ensure this information is always available.
Signed-off-by: Kory Maincent
---
Change in v2:
- Fix nit in the commit message
---
board/xilinx/zynqmp/zynqmp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f370fb7347a..16292ed1c7e 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -519,6 +519,10 @@ int board_late_init(void)
usb_ether_init();
#endif
+ multiboot = multi_boot();
+ if (multiboot >= 0)
+ env_set_hex("multiboot", multiboot);
+
if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
debug("Saved variables - Skipping\n");
return 0;
@@ -531,10 +535,6 @@ int board_late_init(void)
if (ret)
return ret;
- multiboot = multi_boot();
- if (multiboot >= 0)
- env_set_hex("multiboot", multiboot);
-
if (IS_ENABLED(CONFIG_DISTRO_DEFAULTS)) {
ret = boot_targets_setup();
if (ret)
Applied.
M
Re: [PATCH] xilinx: zynqmp: Allow multiboot environment write even in saved environment
On 5/28/24 17:11, Kory Maincent wrote: On Tue, 28 May 2024 16:53:42 +0200 Michal Simek wrote: On 5/28/24 16:36, Kory Maincent wrote: Once the environment was saved, we could not retrieve information about nit: use imperative mood. Ah indeed. the multiboot image used. When dealing with firmware updates, this information is necessary alongside the saved environment. what exactly are you trying to do? Retrieving the multiboot information to know which boot000x.bin image we have booted. This would allow to check the boot status of a firmware update. Move the multiboot environment set operation before the saved environment check to ensure this information is always available. that make sense. Signed-off-by: Kory Maincent --- board/xilinx/zynqmp/zynqmp.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index f370fb7347a..16292ed1c7e 100644 --- a/board/xilinx/zynqmp/zynqmp.c +++ b/board/xilinx/zynqmp/zynqmp.c @@ -519,6 +519,10 @@ int board_late_init(void) usb_ether_init(); #endif + multiboot = multi_boot(); + if (multiboot >= 0) likely make sense to remove this check to because you want to have even multiboot=0 too. I don't understand, this check is >= so it supports multiboot=0. Sorry my fault. You are right. It was there for catching the fault. Thanks, Michal
Re: [PATCH] xilinx: zynqmp: Allow multiboot environment write even in saved environment
On 5/28/24 16:36, Kory Maincent wrote:
Once the environment was saved, we could not retrieve information about
nit: use imperative mood.
the multiboot image used. When dealing with firmware updates, this
information is necessary alongside the saved environment.
what exactly are you trying to do?
Move the multiboot environment set operation before the saved environment
check to ensure this information is always available.
that make sense.
Signed-off-by: Kory Maincent
---
board/xilinx/zynqmp/zynqmp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index f370fb7347a..16292ed1c7e 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -519,6 +519,10 @@ int board_late_init(void)
usb_ether_init();
#endif
+ multiboot = multi_boot();
+ if (multiboot >= 0)
likely make sense to remove this check to because you want to have even
multiboot=0 too.
+ env_set_hex("multiboot", multiboot);
+
if (!(gd->flags & GD_FLG_ENV_DEFAULT)) {
debug("Saved variables - Skipping\n");
return 0;
@@ -531,10 +535,6 @@ int board_late_init(void)
if (ret)
return ret;
- multiboot = multi_boot();
- if (multiboot >= 0)
- env_set_hex("multiboot", multiboot);
-
if (IS_ENABLED(CONFIG_DISTRO_DEFAULTS)) {
ret = boot_targets_setup();
if (ret)
M
Re: [PATCH v4] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On 5/25/24 22:02, Tim Harvey wrote:
If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to
randomize the virtual address at which the kernel image is loaded, it
expects entropy to be provided by the bootloader by populating
/chosen/kaslr-seed with a 64-bit value from source of entropy at boot.
If we have DM_RNG enabled populate this value automatically when
fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT
is enabled as it's implementation uses a different source of entropy
that is not yet implemented as DM_RNG. We also skip this if
MEASURED_BOOT is enabled as in that case any modifications to the
dt will cause measured boot to fail (although there are many other
places the dt is altered).
As this fdt node is added elsewhere create a library function and
use it to deduplicate code. We will provide a parameter to specify the
index of the rng device as well as a boolean to overwrite if present.
For our automatic injection, we will use the first rng device and
not overwrite if already present with a non-zero value (which may
have been populated by an earlier boot stage). This way if a board
specific ft_board_setup() function wants to customize this behavior
it can call fdt_kaslrseed with a rng device index of its choosing and
set overwrite true.
Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now
but left in place in case boot scripts exist that rely on this command
existing and returning success. An informational message is printed to
alert users of this command that it is likely no longer needed.
Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for
randomization and completely ignores the kaslr-seed for its own
randomness needs (i.e the randomization of the physical placement of
the kernel). It gets weeded out from the DTB that gets handed over via
efi_install_fdt() as it would also mess up the measured boot DTB TPM
measurements as well.
Signed-off-by: Tim Harvey
Cc: Michal Simek
Cc: Andy Yan
Cc: Akash Gajjar
Cc: Ilias Apalodimas
Cc: Simon Glass
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Devarsh Thakkar
Cc: Heinrich Schuchardt
Cc: Hugo Villeneuve
Cc: Marek Vasut
Cc: Tom Rini
Cc: Chris Morgan
---
v4:
- add missing /n to notice in kaslrseed cmd
- combine ints in declaration
- remove unused vars from board/xilinx/common/board.c ft_board_setup
v3:
- skip if CONFIG_MEASURED_BOOT
- fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
- pass in rng index and bool to specify overwrite
- remove duplicate error strings printed outside of fdt_kaslrseed
- added note to commit log about how EFI STUB weeds out kalsr-seed
v2:
- fix typo in commit msg
- use stack for seed to avoid unecessary malloc/free
- move to a library function and deduplicate code by using it
elsewhere
---
board/xilinx/common/board.c | 40 --
boot/fdt_support.c | 6 +
boot/pxe_utils.c| 35 ++
cmd/kaslrseed.c | 45 +-
include/kaslrseed.h | 19 ++
lib/Makefile| 1 +
lib/kaslrseed.c | 49 +
7 files changed, 83 insertions(+), 112 deletions(-)
create mode 100644 include/kaslrseed.h
create mode 100644 lib/kaslrseed.c
diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c
index 30a81376ac41..0b43407b9e94 100644
--- a/board/xilinx/common/board.c
+++ b/board/xilinx/common/board.c
@@ -701,11 +701,6 @@ phys_addr_t board_get_usable_ram_top(phys_size_t
total_size)
#define MAX_RAND_SIZE 8
int ft_board_setup(void *blob, struct bd_info *bd)
{
- size_t n = MAX_RAND_SIZE;
- struct udevice *dev;
- u8 buf[MAX_RAND_SIZE];
- int nodeoffset, ret;
-
static const struct node_info nodes[] = {
{ "arm,pl353-nand-r2p1", MTD_DEV_TYPE_NAND, },
};
@@ -713,41 +708,6 @@ int ft_board_setup(void *blob, struct bd_info *bd)
if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) &&
IS_ENABLED(CONFIG_NAND_ZYNQ))
fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes));
- if (uclass_get_device(UCLASS_RNG, 0, ) || !dev) {
- debug("No RNG device\n");
- return 0;
- }
-
- if (dm_rng_read(dev, buf, n)) {
- debug("Reading RNG failed\n");
- return 0;
- }
-
- if (!blob) {
- debug("No FDT memory address configured. Please configure\n"
- "the FDT address via \"fdt addr \" command.\n"
- "Aborting!\n");
- return 0;
- }
-
- ret = fdt_check_header(blob);
- if (ret < 0) {
- debug("fdt_chosen: %s\n", fdt_strerror(ret));
- return ret;
- }
-
- nodeoffset = fdt_find_or_add_subnode(blob, 0, &
Re: [PATCH] xilinx: Add option to load environment from outside of boot media
On 5/22/24 19:47, Vasileios Amoiridis wrote:
From: Vasileios Amoiridis
Currently, if the environment is not in the current boot media, the
env_get_location() is returning ENVL_UNKNOWN or ENVL_NOWHERE which
is not true (i.e booting from FLASH with environment in eMMC). This
commit adds an extra check to find the environment in the other
supported boot media, keeping the same priority as of now.
Signed-off-by: Vasileios Amoiridis
---
board/xilinx/versal-net/board.c | 21 +++--
board/xilinx/versal/board.c | 23 ---
board/xilinx/zynq/board.c | 31 +++
board/xilinx/zynqmp/zynqmp.c| 31 +++
4 files changed, 93 insertions(+), 13 deletions(-)
diff --git a/board/xilinx/versal-net/board.c b/board/xilinx/versal-net/board.c
index da03024e16..5648d6685e 100644
--- a/board/xilinx/versal-net/board.c
+++ b/board/xilinx/versal-net/board.c
@@ -372,6 +372,21 @@ void reset_cpu(void)
{
}
+static enum env_location env_locations[] = {
+#ifdef CONFIG_ENV_IS_IN_FAT
+ ENVL_FAT,
+#endif
+#ifdef CONFIG_ENV_IS_IN_EXT4
+ ENVL_EXT4,
+#endif
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+ ENVL_SPI_FLASH,
+#endif
+#ifdef CONFIG_ENV_IS_NOWHERE
+ ENVL_NOWHERE,
+#endif
+};
+
#if defined(CONFIG_ENV_IS_NOWHERE)
enum env_location env_get_location(enum env_operation op, int prio)
{
@@ -389,17 +404,19 @@ enum env_location env_get_location(enum env_operation op,
int prio)
return ENVL_FAT;
if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
return ENVL_EXT4;
- return ENVL_NOWHERE;
+ break;
case OSPI_MODE:
case QSPI_MODE_24BIT:
case QSPI_MODE_32BIT:
if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
return ENVL_SPI_FLASH;
- return ENVL_NOWHERE;
+ break;
case JTAG_MODE:
case SELECTMAP_MODE:
default:
return ENVL_NOWHERE;
}
+
+ return env_locations[prio];
}
#endif
diff --git a/board/xilinx/versal/board.c b/board/xilinx/versal/board.c
index 4f6d56119d..8aed2e97df 100644
--- a/board/xilinx/versal/board.c
+++ b/board/xilinx/versal/board.c
@@ -291,12 +291,27 @@ void reset_cpu(void)
{
}
+static enum env_location env_locations[] = {
+#ifdef CONFIG_ENV_IS_IN_FAT
+ ENVL_FAT,
+#endif
+#ifdef CONFIG_ENV_IS_IN_EXT4
+ ENVL_EXT4,
+#endif
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+ ENVL_SPI_FLASH,
+#endif
+#ifdef CONFIG_ENV_IS_NOWHERE
+ ENVL_NOWHERE,
+#endif
+};
+
#if defined(CONFIG_ENV_IS_NOWHERE)
enum env_location env_get_location(enum env_operation op, int prio)
{
u32 bootmode = versal_get_bootmode();
- if (prio)
+ if (prio >= ARRAY_SIZE(env_locations))
return ENVL_UNKNOWN;
switch (bootmode) {
@@ -308,17 +323,19 @@ enum env_location env_get_location(enum env_operation op,
int prio)
return ENVL_FAT;
if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
return ENVL_EXT4;
- return ENVL_NOWHERE;
+ break;
case OSPI_MODE:
case QSPI_MODE_24BIT:
case QSPI_MODE_32BIT:
if (IS_ENABLED(CONFIG_ENV_IS_IN_SPI_FLASH))
return ENVL_SPI_FLASH;
- return ENVL_NOWHERE;
+ break;
case JTAG_MODE:
case SELECTMAP_MODE:
default:
return ENVL_NOWHERE;
}
+
+ return env_locations[prio];
}
#endif
diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 6c36591001..6fa5016cdd 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -134,11 +134,32 @@ int dram_init(void)
}
#endif
+static enum env_location env_locations[] = {
+#ifdef CONFIG_ENV_IS_IN_FAT
+ ENVL_FAT,
+#endif
+#ifdef CONFIG_ENV_IS_IN_EXT4
+ ENVL_EXT4,
+#endif
+#ifdef CONFIG_ENV_IS_IN_NAND
+ ENVL_NAND,
+#endif
+#ifdef CONFIG_ENV_IS_IN_UBI
+ ENVL_UBI,
+#endif
+#ifdef CONFIG_ENV_IS_IN_SPI_FLASH
+ ENVL_SPI_FLASH,
+#endif
+#ifdef CONFIG_ENV_IS_NOWHERE
+ ENVL_NOWHERE,
+#endif
+};
+
enum env_location env_get_location(enum env_operation op, int prio)
{
u32 bootmode = zynq_slcr_get_boot_mode() & ZYNQ_BM_MASK;
- if (prio)
+ if (prio >= ARRAY_SIZE(env_locations))
return ENVL_UNKNOWN;
switch (bootmode) {
@@ -147,22 +168,24 @@ enum env_location env_get_location(enum env_operation op,
int prio)
return ENVL_FAT;
if (IS_ENABLED(CONFIG_ENV_IS_IN_EXT4))
return ENVL_EXT4;
- return ENVL_NOWHERE;
+ break;
case ZYNQ_BM_NAND:
if (IS_ENABLED(CONFIG_ENV_IS_IN_NAND))
return ENVL_NAND;
if (IS_ENABLED(CONFIG_ENV_IS_IN_UBI))
Re: [PATCH v11 0/8] spi-nor: Add parallel and stacked memories support
On 5/7/24 17:48, Tom Rini wrote: On Tue, May 07, 2024 at 04:15:14AM +, Abbarapu, Venkatesh wrote: + Tom Rini Do you have any comments for this series? Seems likely fine. Jagan, do you have time to put this in a PR for -next? Thanks. No reaction for quite a long time. Can you take it directly to next branch? Or do you want me to send you pull request to get this to regression and see if this breaks someone else? Thanks, Michal
Re: [PATCH v3 00/20] FWU: Add support for FWU metadata version 2
Hi Sughosh, On 3/22/24 11:57, Sughosh Ganu wrote: The following patch series adds support for version 2 of the FWU metadata. The version 2 metadata structure is defined in the latest revision of the FWU specification [1]. The earlier versions of these patches were migrating to a version 2 only support in U-Boot, similar to TF-A. However, based on feedback from ST [2], this series has been updated to support both versions. A platform would still be needed to enable one of the two versions of metadata through a config symbol. TF-A has code which reads the FWU metadata and boots the platform from the active partition. TF-A has decided to migrate the FWU code to a version 2 only support. These changes have been merged in upstream TF-A. These changes have been tested on the ST DK2 board, which uses the GPT based partitioning scheme. Both V1 and V2 metadata versions have been tested on the DK2 board. These changes need to be tested on platforms with MTD partitioned storage devices. @Michal and @Kojima-san, please help in this testing. Note: The CI is breaking on some sandbox py tests, but the errors look unrelated. I will look into those issues, but the code review can proceed. [1] - https://developer.arm.com/documentation/den0118/latest/ [2] - https://lists.denx.de/pipermail/u-boot/2024-February/546277.html Changes since V2: * New patch which retains support for V1 of metadata * Earlier patch was catering to v2 only support. These changes support both versions of metadata. * Earlier patch was migrating to v2 only support. These changes support both versions. * Support both metadata versions instead of only v2. * Added documentation changes. * Make changes to have the test work with v1 metadata. * Make changes to have the test work with updated logic in fwu code. * Changes to indicate support for both v1 and v2 instead of only v2. * Add config symbol for selecting either of the two metadata versions. Sughosh Ganu (20): configs: fwu: remove FWU configs for metadata V2 support tools: mkfwumdata: fix the size parameter to the fwrite call drivers: fwu: add the size parameter to the metadata access API's drivers: fwu: mtd: allocate buffer for image info dynamically fwu: metadata: add support for version 2 of the structure fwu: metadata: add a version agnostic structure fwu: metadata: add functions for handling version specific metadata fields fwu: make changes to access version agnostic structure fields capsule: fwu: transition the platform state on a successful update fwu: add config symbols for enabling FWU metadata versions fwu: mtd: remove unused argument from function call fwu: mtd: get MTD partition specific info from driver fwu: mtd: obtain image information from version agnostic structure cmd: fwu: make changes for supporting FWU metadata version 2 tools: mkfwumdata: add support for metadata version 2 tools: mkfwumdata: add logic to append vendor data to the FWU metadata test: fwu: make changes to the FWU metadata access test doc: fwu: make changes to reflect support for FWU metadata v2 MAINTAINERS: add entry for FWU multi bank update feature configs: fwu: re-enable FWU configs MAINTAINERS | 8 + cmd/fwu_mdata.c | 39 ++-- configs/corstone1000_defconfig | 1 + configs/sandbox64_defconfig | 1 + configs/synquacer_developerbox_defconfig | 2 +- doc/board/socionext/developerbox.rst | 7 +- doc/develop/uefi/fwu_updates.rst | 20 +- doc/mkfwumdata.1 | 16 +- drivers/fwu-mdata/fwu-mdata-uclass.c | 10 +- drivers/fwu-mdata/gpt_blk.c | 23 +- drivers/fwu-mdata/raw_mtd.c | 78 --- include/fwu.h| 147 - include/fwu_mdata.h | 71 ++- lib/efi_loader/efi_capsule.c | 14 +- lib/fwu_updates/Kconfig | 14 ++ lib/fwu_updates/Makefile | 2 + lib/fwu_updates/fwu.c| 204 -- lib/fwu_updates/fwu_mtd.c| 34 +-- lib/fwu_updates/fwu_v1.c | 167 +++ lib/fwu_updates/fwu_v2.c | 260 +++ test/dm/fwu_mdata.c | 16 +- tools/mkfwumdata.c | 235 22 files changed, 1153 insertions(+), 216 deletions(-) create mode 100644 lib/fwu_updates/fwu_v1.c create mode 100644 lib/fwu_updates/fwu_v2.c I tested it on Kria and I can't see any issue that's why Tested-by: Michal Simek Thanks, Michal
Re: [PATCH 0/3] lib: smbios: Extend driver with using sysinfo driver
Hi Ilias, On 4/26/24 15:38, Michal Simek wrote: Hi, currently only DT way is supported and it is added directly to lib/smbios.c but I think DT and env is only one way how information can be found that's why this series is improving handling with using sysinfo driver which can be platform specific. At the end of day DT should be taken from smbios.c and put to sysinfo DT driver instead of implementing it directly in this generic file. Thanks, Michal Michal Simek (3): xilinx: Enable SMBIOS command lib: smbios: Let detect the system via sysinfo lib: smbios: Detect system properties via SYSINFO IDs configs/xilinx_versal_net_virt_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + configs/xilinx_zynqmp_kria_defconfig | 1 + configs/xilinx_zynqmp_virt_defconfig | 1 + include/sysinfo.h| 9 + lib/smbios.c | 42 +++- 6 files changed, 46 insertions(+), 9 deletions(-) Any comment on this series? Thanks, Michal
Re: [PATCH v3] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
st 22. 5. 2024 v 17:19 odesílatel Tim Harvey napsal: > > On Wed, May 22, 2024 at 12:47 AM Michal Simek wrote: > > > > > > > > On 5/21/24 22:59, Tim Harvey wrote: > > > If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to > > > randomize the virtual address at which the kernel image is loaded, it > > > expects entropy to be provided by the bootloader by populating > > > /chosen/kaslr-seed with a 64-bit value from source of entropy at boot. > > > > > > If we have DM_RNG enabled populate this value automatically when > > > fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT > > > is enabled as it's implementation uses a different source of entropy > > > that is not yet implemented as DM_RNG. We also skip this if > > > MEASURED_BOOT is enabled as in that case any modifications to the > > > dt will cause measured boot to fail (although there are many other > > > places the dt is altered). > > > > > > As this fdt node is added elsewhere create a library function and > > > use it to deduplicate code. We will provide a parameter to specify the > > > index of the rng device as well as a boolean to overwrite if present. > > > > > > For our automatic injection, we will use the first rng device and > > > not overwrite if already present with a non-zero value (which may > > > have been populated by an earlier boot stage). This way if a board > > > specific ft_board_setup() function wants to customize this behavior > > > it can call fdt_kaslrseed with a rng device index of its choosing and > > > set overwrite true. > > > > > > Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now > > > but left in place in case boot scripts exist that rely on this command > > > existing and returning success. An informational message is printed to > > > alert users of this command that it is likely no longer needed. > > > > > > Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for > > > randomization and completely ignores the kaslr-seed for its own > > > randomness needs (i.e the randomization of the physical placement of > > > the kernel). It gets weeded out from the DTB that gets handed over via > > > efi_install_fdt() as it would also mess up the measured boot DTB TPM > > > measurements as well. > > > > > > Signed-off-by: Tim Harvey > > > Cc: Michal Simek > > > Cc: Andy Yan > > > Cc: Akash Gajjar > > > Cc: Ilias Apalodimas > > > Cc: Simon Glass > > > Cc: Patrick Delaunay > > > Cc: Patrice Chotard > > > Cc: Devarsh Thakkar > > > Cc: Heinrich Schuchardt > > > Cc: Hugo Villeneuve > > > Cc: Marek Vasut > > > Cc: Tom Rini > > > Cc: Chris Morgan > > > --- > > > v3: > > > - skip if CONFIG_MEASURED_BOOT > > > - fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT > > > - pass in rng index and bool to specify overwrite > > > - remove duplicate error strings printed outside of fdt_kaslrseed > > > - added note to commit log about how EFI STUB weeds out kalsr-seed > > > > > > v2: > > > - fix typo in commit msg > > > - use stack for seed to avoid unecessary malloc/free > > > - move to a library function and deduplicate code by using it > > > elsewhere > > > --- > > > board/xilinx/common/board.c | 35 - > > > boot/fdt_support.c | 6 + > > > boot/pxe_utils.c| 35 ++--- > > > cmd/kaslrseed.c | 45 +--- > > > include/kaslrseed.h | 19 ++ > > > lib/Makefile| 1 + > > > lib/kaslrseed.c | 51 + > > > 7 files changed, 85 insertions(+), 107 deletions(-) > > > create mode 100644 include/kaslrseed.h > > > create mode 100644 lib/kaslrseed.c > > > > > > diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c > > > index 30a81376ac41..f741e8957818 100644 > > > --- a/board/xilinx/common/board.c > > > +++ b/board/xilinx/common/board.c > > > @@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd) > > > if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) && > > > IS_ENABLED(CONFIG_NAND_ZYNQ)) > > > fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes)); > &
Re: [PATCH v3] fdt: automatically add /chosen/kaslr-seed if DM_RNG is enabled
On 5/21/24 22:59, Tim Harvey wrote: If RANDOMIZE_BASE is enabled in the Linux kernel instructing it to randomize the virtual address at which the kernel image is loaded, it expects entropy to be provided by the bootloader by populating /chosen/kaslr-seed with a 64-bit value from source of entropy at boot. If we have DM_RNG enabled populate this value automatically when fdt_chosen is called. We skip this if ARMV8_SEC_FIRMWARE_SUPPORT is enabled as it's implementation uses a different source of entropy that is not yet implemented as DM_RNG. We also skip this if MEASURED_BOOT is enabled as in that case any modifications to the dt will cause measured boot to fail (although there are many other places the dt is altered). As this fdt node is added elsewhere create a library function and use it to deduplicate code. We will provide a parameter to specify the index of the rng device as well as a boolean to overwrite if present. For our automatic injection, we will use the first rng device and not overwrite if already present with a non-zero value (which may have been populated by an earlier boot stage). This way if a board specific ft_board_setup() function wants to customize this behavior it can call fdt_kaslrseed with a rng device index of its choosing and set overwrite true. Note that the kalsrseed command (CMD_KASLRSEED) is likely pointless now but left in place in case boot scripts exist that rely on this command existing and returning success. An informational message is printed to alert users of this command that it is likely no longer needed. Note that the Kernel's EFI STUB only relies on EFI_RNG_PROTOCOL for randomization and completely ignores the kaslr-seed for its own randomness needs (i.e the randomization of the physical placement of the kernel). It gets weeded out from the DTB that gets handed over via efi_install_fdt() as it would also mess up the measured boot DTB TPM measurements as well. Signed-off-by: Tim Harvey Cc: Michal Simek Cc: Andy Yan Cc: Akash Gajjar Cc: Ilias Apalodimas Cc: Simon Glass Cc: Patrick Delaunay Cc: Patrice Chotard Cc: Devarsh Thakkar Cc: Heinrich Schuchardt Cc: Hugo Villeneuve Cc: Marek Vasut Cc: Tom Rini Cc: Chris Morgan --- v3: - skip if CONFIG_MEASURED_BOOT - fix skip for CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT - pass in rng index and bool to specify overwrite - remove duplicate error strings printed outside of fdt_kaslrseed - added note to commit log about how EFI STUB weeds out kalsr-seed v2: - fix typo in commit msg - use stack for seed to avoid unecessary malloc/free - move to a library function and deduplicate code by using it elsewhere --- board/xilinx/common/board.c | 35 - boot/fdt_support.c | 6 + boot/pxe_utils.c| 35 ++--- cmd/kaslrseed.c | 45 +--- include/kaslrseed.h | 19 ++ lib/Makefile| 1 + lib/kaslrseed.c | 51 + 7 files changed, 85 insertions(+), 107 deletions(-) create mode 100644 include/kaslrseed.h create mode 100644 lib/kaslrseed.c diff --git a/board/xilinx/common/board.c b/board/xilinx/common/board.c index 30a81376ac41..f741e8957818 100644 --- a/board/xilinx/common/board.c +++ b/board/xilinx/common/board.c @@ -713,41 +713,6 @@ int ft_board_setup(void *blob, struct bd_info *bd) if (IS_ENABLED(CONFIG_FDT_FIXUP_PARTITIONS) && IS_ENABLED(CONFIG_NAND_ZYNQ)) fdt_fixup_mtdparts(blob, nodes, ARRAY_SIZE(nodes)); one more thing here. Please also removed unused variables. board/xilinx/common/board.c: In function 'ft_board_setup': board/xilinx/common/board.c:707:25: warning: unused variable 'ret' [-Wunused-variable] 707 | int nodeoffset, ret; | ^~~ board/xilinx/common/board.c:707:13: warning: unused variable 'nodeoffset' [-Wunused-variable] 707 | int nodeoffset, ret; | ^~ AS arch/arm/cpu/armv8/cache.o board/xilinx/common/board.c:706:12: warning: unused variable 'buf' [-Wunused-variable] 706 | u8 buf[MAX_RAND_SIZE]; |^~~ board/xilinx/common/board.c:705:25: warning: unused variable 'dev' [-Wunused-variable] 705 | struct udevice *dev; | ^~~ board/xilinx/common/board.c:704:16: warning: unused variable 'n' [-Wunused-variable] 704 | size_t n = MAX_RAND_SIZE; |^ Thanks, Michal
