February 2022 - U-Boot

[PATCH 1/5] bcm6753: add initial support
by Philippe Reynes 07 Mar '22

07 Mar '22

This add the initial support of the broadcom bcm6753 SoC family. Signed-off-by: Philippe Reynes <philippe.reynes(a)softathome.com> --- arch/arm/Kconfig | 7 ++ arch/arm/dts/bcm6753.dtsi | 201 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 208 insertions(+) create mode 100644 arch/arm/dts/bcm6753.dtsi diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 8053394389..07a1b713cb 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -617,6 +617,13 @@ config ARCH_BCM63158 select OF_CONTROL imply CMD_DM +config ARCH_BCM6753 + bool "Broadcom BCM6753 family" + select CPU_V7A + select DM + select OF_CONTROL + imply CMD_DM + config ARCH_BCM68360 bool "Broadcom BCM68360 family" select DM diff --git a/arch/arm/dts/bcm6753.dtsi b/arch/arm/dts/bcm6753.dtsi new file mode 100644 index 0000000000..bcbb8e17da --- /dev/null +++ b/arch/arm/dts/bcm6753.dtsi @@ -0,0 +1,201 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2022 Philippe Reynes <philippe.reynes(a)softathome.com> + */ + +#include "skeleton.dtsi" + +/ { + compatible = "brcm,bcm6753"; + #address-cells = <1>; + #size-cells = <1>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + u-boot,dm-pre-reloc; + + cpu0: cpu@0 { + compatible = "arm,cortex-a7"; + device_type = "cpu"; + reg = <0x0>; + next-level-cache = <&l2>; + u-boot,dm-pre-reloc; + }; + + cpu1: cpu@1 { + compatible = "arm,cortex-a7"; + device_type = "cpu"; + reg = <0x1>; + next-level-cache = <&l2>; + u-boot,dm-pre-reloc; + }; + + cpu2: cpu@2 { + compatible = "arm,cortex-a7"; + device_type = "cpu"; + reg = <0x2>; + next-level-cache = <&l2>; + u-boot,dm-pre-reloc; + }; + + l2: l2-cache0 { + compatible = "cache"; + u-boot,dm-pre-reloc; + }; + }; + + clocks { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + u-boot,dm-pre-reloc; + + periph_osc: periph-osc { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <200000000>; + u-boot,dm-pre-reloc; + }; + + hsspi_pll: hsspi-pll { + compatible = "fixed-factor-clock"; + #clock-cells = <0>; + clocks = <&periph_osc>; + clock-mult = <2>; + clock-div = <1>; + }; + + refclk50mhz: refclk50mhz { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <50000000>; + }; + }; + + ubus { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + u-boot,dm-pre-reloc; + + uart0: serial@ff812000 { + compatible = "arm,pl011", "arm,primecell"; + reg = <0xff812000 0x1000>; + clock = <50000000>; + + status = "disabled"; + }; + + wdt1: watchdog@ff800480 { + compatible = "brcm,bcm6345-wdt"; + reg = <0xff800480 0x14>; + clocks = <&refclk50mhz>; + }; + + wdt2: watchdog@ff8004c0 { + compatible = "brcm,bcm6345-wdt"; + reg = <0xff8004c0 0x14>; + clocks = <&refclk50mhz>; + }; + + wdt-reboot { + compatible = "wdt-reboot"; + wdt = <&wdt1>; + }; + + gpio0: gpio-controller@0xff800500 { + compatible = "brcm,bcm6345-gpio"; + reg = <0xff800500 0x4>, + <0xff800520 0x4>; + gpio-controller; + #gpio-cells = <2>; + + status = "disabled"; + }; + + gpio1: gpio-controller@0xff800504 { + compatible = "brcm,bcm6345-gpio"; + reg = <0xff800504 0x4>, + <0xff800524 0x4>; + gpio-controller; + #gpio-cells = <2>; + + status = "disabled"; + }; + + gpio2: gpio-controller@0xff800508 { + compatible = "brcm,bcm6345-gpio"; + reg = <0xff800508 0x4>, + <0xff800528 0x4>; + gpio-controller; + #gpio-cells = <2>; + + status = "disabled"; + }; + + gpio3: gpio-controller@0xff80050c { + compatible = "brcm,bcm6345-gpio"; + reg = <0xff80050c 0x4>, + <0xff80052c 0x4>; + gpio-controller; + #gpio-cells = <2>; + + status = "disabled"; + }; + + gpio4: gpio-controller@0xff800510 { + compatible = "brcm,bcm6345-gpio"; + reg = <0xff800510 0x4>, + <0xff800530 0x4>; + gpio-controller; + #gpio-cells = <2>; + + status = "disabled"; + }; + + gpio5: gpio-controller@0xff800514 { + compatible = "brcm,bcm6345-gpio"; + reg = <0xff800514 0x4>, + <0xff800534 0x4>; + gpio-controller; + #gpio-cells = <2>; + + status = "disabled"; + }; + + gpio6: gpio-controller@0xff800518 { + compatible = "brcm,bcm6345-gpio"; + reg = <0xff800518 0x4>, + <0xff800538 0x4>; + gpio-controller; + #gpio-cells = <2>; + + status = "disabled"; + }; + + gpio7: gpio-controller@0xff80051c { + compatible = "brcm,bcm6345-gpio"; + reg = <0xff80051c 0x4>, + <0xff80053c 0x4>; + gpio-controller; + #gpio-cells = <2>; + + status = "disabled"; + }; + + nand: nand-controller@ff801800 { + compatible = "brcm,nand-bcm6753", + "brcm,brcmnand-v5.0", + "brcm,brcmnand"; + reg-names = "nand", "nand-int-base", "nand-cache"; + reg = <0xff801800 0x180>, + <0xff802000 0x10>, + <0xff801c00 0x200>; + parameter-page-big-endian = <0>; + + status = "disabled"; + }; + }; +}; -- 2.17.1

2 9

phy_connect_dev calling phy_reset???
by Tim Harvey 07 Mar '22

07 Mar '22

Greetings, I'm wondering if it is proper in U-Boot for phy_connect_dev() to always call phy_reset() which generates a soft reset via BMCR_RESET. For some (or most?) PHY's this resets specific PHY config such as RGMII delays and LED configuration that may have been configured by firmware running prior to U-Boot (SPL/TPL). I believe there was some discussion and thrash about this in the Linux kernel in the past and while I can't find the discussion or patches I see that for the current kernel BMCR_RESET is in genphy_soft_reset which() is not called in the generic phy_connect() but instead only called by a handful of phy drivers which I would expect is ok as those phy drivers would also be re-configuring the PHY. Specifically I have an issue with this with a board that has custom firmware code that runs prior to U-Boot and the BMCR reset is undoing specific PHY config that I've done in this firmware causing me to look at implementing PHY drivers in U-Boot that otherwise would not be needed. Best Regards, Tim

2 3

[PATCH v2 0/4] Add ESM driver support for AM64x R5 SPL/U-boot
by Hari Nagalla 07 Mar '22

07 Mar '22

AM64x devices have a main ESM and a MCU ESM. The ESM driver enables routing of the error events from various sources to different processors or to reset hardware logic. Only the MCU ESM's high output can trigger reset logic. The main RTI0 WWDT output can be routed to the MCU highoutput to trigger reset through the main ESM. For this reset to occur CTRLMMR_MCU_RST_CTRL:MCU_ESM_ERROR_RESET_EN_Z is set to '0'. AM64x Technical Reference Manual - https://www.ti.com/lit/pdf/spruim2 Hari Nagalla (4): misc: k3_esm: Add functionality to set and route error events within K3SoC arm: dts: k3-am64: Add support for ESM device nodes arch: arm: mach-k3: am642_init: Probe ESM nodes configs: am64x_evm_r5_defconfig: Add support for ESM arch/arm/dts/k3-am64.dtsi | 1 + arch/arm/dts/k3-am642-r5-evm.dts | 19 ++++++++++++ arch/arm/dts/k3-am642-r5-sk.dts | 19 ++++++++++++ arch/arm/mach-k3/am642_init.c | 29 ++++++++++++++--- configs/am64x_evm_r5_defconfig | 1 + drivers/misc/k3_esm.c | 53 ++++++++++++++++++++++++++++++-- 6 files changed, 115 insertions(+), 7 deletions(-) -- 2.17.1

2 10

[PATCH V2] dt-bindings: nvmem: add U-Boot environment variables binding
by Rafał Miłecki 07 Mar '22

07 Mar '22

From: Rafał Miłecki <rafal(a)milecki.pl> U-Boot uses environment variables for storing device setup data. It usually needs to be accessed by a bootloader, kernel and often user-space. This binding allows describing environment data located in a raw flash partition. It's treated as NVMEM device and can be reused later for other storage devices. Using DT should be cleaner than hardcoding & duplicating such info in multiple places. Bootloader & kernel can share DTS and user-space can try reading it too or just have correct data exposed by a kernel. A custom "compatible" string allows system to automatically load relevant NVMEM driver but phandle can be also used for reading raw location. Signed-off-by: Rafał Miłecki <rafal(a)milecki.pl> --- V2: Update descriptions to don't make this binding MTD (flash partition) specific. Mention multiple possible storage ways. --- .../devicetree/bindings/nvmem/u-boot,env.yaml | 66 +++++++++++++++++++ MAINTAINERS | 5 ++ 2 files changed, 71 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvmem/u-boot,env.yaml diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml new file mode 100644 index 000000000000..a53e34152c97 --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot environment variables + +description: | + U-Boot uses environment variables to store device parameters and + configuration. They may be used for booting process, setup or keeping end user + info. + + Data is stored using U-Boot specific formats (variant specific header and NUL + separated key-value pairs). + + Environment data can be stored on various storage entities, e.g.: + 1. Raw flash partition + 2. UBI volume + + This binding allows marking storage device (as containing env data) and + specifying used format. + + Right now only flash partition case is covered but it may be extended to e.g. + UBI volumes in the future. + +maintainers: + - Rafał Miłecki <rafal(a)milecki.pl> + +allOf: + - $ref: nvmem.yaml# + +properties: + compatible: + oneOf: + - description: A standalone env data block + const: u-boot,env + - description: Two redundant blocks with active one flagged + const: u-boot,env-redundant-bool + - description: Two redundant blocks with active having higher counter + const: u-boot,env-redundant-count + + reg: + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + reg = <0x0 0x40000>; + label = "u-boot"; + read-only; + }; + + env: partition@40000 { + compatible = "u-boot,env"; + reg = <0x40000 0x10000>; + label = "u-boot-env"; + }; + }; diff --git a/MAINTAINERS b/MAINTAINERS index 66aa3a589f6a..55c56ce82856 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -19905,6 +19905,11 @@ W: http://linuxtv.org T: git git://linuxtv.org/media_tree.git F: drivers/media/pci/tw686x/ +U-BOOT ENVIRONMENT VARIABLES +M: Rafał Miłecki <rafal(a)milecki.pl> +S: Maintained +F: Documentation/devicetree/bindings/nvmem/u-boot,env.yaml + UACCE ACCELERATOR FRAMEWORK M: Zhangfei Gao <zhangfei.gao(a)linaro.org> M: Zhou Wang <wangzhou1(a)hisilicon.com> -- 2.34.1

3 4

[PATCH 0/6] arm64: zynqmp: Update SOM boards
by Michal Simek 07 Mar '22

07 Mar '22

Hi, kv-g boards have been moved to new model where u-boot configures a lot of things at run time which requires updates in DTs especially in connection to enabling clocks for these platforms. There are also small adjustment to match the latest state. Thanks, Michal Michal Simek (6): arm64: zynqmp: Move usb hub from i2c to usb node arm64: zynqmp: Setup clock for DP and DPDMA arm64: zynqmp: Use assigned-clock-rates for setting up clock in SOM arm64: zynqmp: Switch to ethernet-phy-id in kv260 arm64: zynqmp: Enable DP driver for SOMs arm64: zynqmp: Fix level of gpio reset for usb on kv260 boards arch/arm/dts/zynqmp-clk-ccf.dtsi | 8 ++++++++ arch/arm/dts/zynqmp-sck-kv-g-revA.dts | 12 +++++++++--- arch/arm/dts/zynqmp-sck-kv-g-revB.dts | 26 ++++++++++++++++++-------- arch/arm/dts/zynqmp-sm-k26-revA.dts | 5 +++++ 4 files changed, 40 insertions(+), 11 deletions(-) -- 2.35.1

2 7

[PATCH] gpio: slg7xl45106: Add support for slg7xl45106 i2c gpo expander
by Michal Simek 07 Mar '22

07 Mar '22

From: T Karthik Reddy <t.karthik.reddy(a)xilinx.com> slg7xl45106 is i2c based 8-bit gpo expander, gpo pins are set and get by writing and reading corresponding gpo bit value into its data register. Signed-off-by: T Karthik Reddy <t.karthik.reddy(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- MAINTAINERS | 1 + drivers/gpio/Kconfig | 8 +++ drivers/gpio/Makefile | 1 + drivers/gpio/gpio_slg7xl45106.c | 115 ++++++++++++++++++++++++++++++++ 4 files changed, 125 insertions(+) create mode 100644 drivers/gpio/gpio_slg7xl45106.c diff --git a/MAINTAINERS b/MAINTAINERS index a75f429cb972..055d7ec2043c 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -638,6 +638,7 @@ F: arch/arm/mach-zynqmp/ F: drivers/clk/clk_zynqmp.c F: driver/firmware/firmware-zynqmp.c F: drivers/fpga/zynqpl.c +F: drivers/gpio/gpio_slg7xl45106.c F: drivers/gpio/zynq_gpio.c F: drivers/gpio/zynqmp_gpio_modepin.c F: drivers/i2c/i2c-cdns.c diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig index 8d0e47c67d9e..a9b3bb854f09 100644 --- a/drivers/gpio/Kconfig +++ b/drivers/gpio/Kconfig @@ -544,4 +544,12 @@ config ZYNQMP_GPIO_MODEPIN are accessed using xilinx firmware. In modepin register, [3:0] bits set direction, [7:4] bits read IO, [11:8] bits set/clear IO. +config SLG7XL45106_I2C_GPO + bool "slg7xl45106 i2c gpo expander" + depends on DM_GPIO + help + Support for slg7xl45106 i2c gpo expander. It is an i2c based + 8-bit gpo expander, all gpo lines are controlled by writing + value into data register. + endif diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile index 63e9be6034f2..dd288c497a70 100644 --- a/drivers/gpio/Makefile +++ b/drivers/gpio/Makefile @@ -71,3 +71,4 @@ obj-$(CONFIG_SIFIVE_GPIO) += sifive-gpio.o obj-$(CONFIG_NOMADIK_GPIO) += nmk_gpio.o obj-$(CONFIG_MAX7320_GPIO) += max7320_gpio.o obj-$(CONFIG_ZYNQMP_GPIO_MODEPIN) += zynqmp_gpio_modepin.o +obj-$(CONFIG_SLG7XL45106_I2C_GPO) += gpio_slg7xl45106.o diff --git a/drivers/gpio/gpio_slg7xl45106.c b/drivers/gpio/gpio_slg7xl45106.c new file mode 100644 index 000000000000..2cbf7488ad62 --- /dev/null +++ b/drivers/gpio/gpio_slg7xl45106.c @@ -0,0 +1,115 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * slg7xl45106_i2c_gpo driver + * + * Copyright (C) 2021 Xilinx, Inc. + */ + +#include <common.h> +#include <errno.h> +#include <asm/io.h> +#include <asm/gpio.h> +#include <dm.h> +#include <i2c.h> +#include <asm/arch/hardware.h> + +#define SLG7XL45106_REG 0xdb + +static int slg7xl45106_i2c_gpo_direction_input(struct udevice *dev, + unsigned int offset) +{ + return 0; +} + +static int slg7xl45106_i2c_gpo_xlate(struct udevice *dev, + struct gpio_desc *desc, + struct ofnode_phandle_args *args) +{ + desc->offset = (unsigned int)args->args[0]; + + return 0; +} + +static int slg7xl45106_i2c_gpo_set_value(struct udevice *dev, + unsigned int offset, int value) +{ + int ret; + u8 val; + + ret = dm_i2c_read(dev, SLG7XL45106_REG, &val, 1); + if (ret) + return ret; + + if (value) + val |= BIT(offset); + else + val &= ~BIT(offset); + + return dm_i2c_write(dev, SLG7XL45106_REG, &val, 1); +} + +static int slg7xl45106_i2c_gpo_direction_output(struct udevice *dev, + unsigned int offset, int value) +{ + return slg7xl45106_i2c_gpo_set_value(dev, offset, value); +} + +static int slg7xl45106_i2c_gpo_get_value(struct udevice *dev, + unsigned int offset) +{ + int ret; + u8 val; + + ret = dm_i2c_read(dev, SLG7XL45106_REG, &val, 1); + if (ret) + return ret; + + return !!(val & BIT(offset)); +} + +static int slg7xl45106_i2c_gpo_get_function(struct udevice *dev, + unsigned int offset) +{ + return GPIOF_OUTPUT; +} + +static const struct dm_gpio_ops slg7xl45106_i2c_gpo_ops = { + .direction_input = slg7xl45106_i2c_gpo_direction_input, + .direction_output = slg7xl45106_i2c_gpo_direction_output, + .get_value = slg7xl45106_i2c_gpo_get_value, + .set_value = slg7xl45106_i2c_gpo_set_value, + .get_function = slg7xl45106_i2c_gpo_get_function, + .xlate = slg7xl45106_i2c_gpo_xlate, +}; + +static int slg7xl45106_i2c_gpo_probe(struct udevice *dev) +{ + struct gpio_dev_priv *uc_priv = dev_get_uclass_priv(dev); + const void *label_ptr; + + label_ptr = dev_read_prop(dev, "label", NULL); + if (label_ptr) { + uc_priv->bank_name = strdup(label_ptr); + if (!uc_priv->bank_name) + return -ENOMEM; + } else { + uc_priv->bank_name = dev->name; + } + + uc_priv->gpio_count = 8; + + return 0; +} + +static const struct udevice_id slg7xl45106_i2c_gpo_ids[] = { + { .compatible = "dlg,slg7xl45106",}, + { } +}; + +U_BOOT_DRIVER(slg7xl45106_i2c_gpo) = { + .name = "slg7xl45106_i2c_gpo", + .id = UCLASS_GPIO, + .ops = &slg7xl45106_i2c_gpo_ops, + .of_match = slg7xl45106_i2c_gpo_ids, + .probe = slg7xl45106_i2c_gpo_probe, +}; -- 2.35.1

4 5

[PATCH 1/2] pinctrl: Increase length of pinmux status buffer
by Michal Simek 07 Mar '22

07 Mar '22

From: Ashok Reddy Soma <ashok.reddy.soma(a)xilinx.com> Xilinx ZynqMP SOC can set 6 parameters for its pins. pinmux status command will print the status of these parameters for each pin. But current print buffer length is only 40 characters long, increase it to 80 to print all the parameters. Signed-off-by: Ashok Reddy Soma <ashok.reddy.soma(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- include/dm/pinctrl.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/dm/pinctrl.h b/include/dm/pinctrl.h index 0c461e56bb48..a09b242fd990 100644 --- a/include/dm/pinctrl.h +++ b/include/dm/pinctrl.h @@ -7,7 +7,7 @@ #define __PINCTRL_H #define PINNAME_SIZE 10 -#define PINMUX_SIZE 40 +#define PINMUX_SIZE 80 /** * struct pinconf_param - pin config parameters -- 2.35.1

2 3

[PATCH 0/3] mmc: zynqmp_sdhci: Driver fixes
by Michal Simek 07 Mar '22

07 Mar '22

Hi, we found 3 issues recently with this driver which needs to be fixed. Thanks, Michal Ashok Reddy Soma (3): mmc: zynq_sdhci: Fix timeout issue mmc: zynq_sdhci: Change granularity of timeout to 1us mmc: zynq_sdhci: Enable card detect workaround for ZynqMP drivers/mmc/zynq_sdhci.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) -- 2.35.1

2 4

[PATCH 0/4] xilinx: Fru tool update
by Michal Simek 07 Mar '22

07 Mar '22

Hi, the first 3 patches are fixes in current fru implementation to make sure that code is not working with incorrect data or not waste time. The last patch adds decoder for xilinx multirecord which stores MAC addresses for DUT. Thanks, Michal Ashok Reddy Soma (4): fru: ops: Clear fru table before storing data fru: ops: Return error from checksum if data is all zero's xilinx: common: Optimise updating ethaddr from eeprom fru: ops: Add support to read mac addresses from multirecord board/xilinx/common/board.c | 11 +++++++- board/xilinx/common/fru.h | 21 +++++++++++++++ board/xilinx/common/fru_ops.c | 49 ++++++++++++++++++++++++++++++++++- 3 files changed, 79 insertions(+), 2 deletions(-) -- 2.35.1

2 5

[PATCH] Revert "board: zynqmp: Fix for wrong AMS setting by ROM"
by Michal Simek 07 Mar '22

07 Mar '22

From: T Karthik Reddy <t.karthik.reddy(a)xilinx.com> This reverts commit dfbe492edef421de09617dc26805fc428440924e. Analog bus control register should be programmed in SPL only. This commit 3414712ba8a ("arm64: zynqmp: Writing correct value to ANALOG_BUS") is programming the same. So revert this commit. Signed-off-by: T Karthik Reddy <t.karthik.reddy(a)xilinx.com> Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- board/xilinx/zynqmp/zynqmp.c | 6 ------ 1 file changed, 6 deletions(-) diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c index 70b3c81f1284..bc2090941d90 100644 --- a/board/xilinx/zynqmp/zynqmp.c +++ b/board/xilinx/zynqmp/zynqmp.c @@ -399,9 +399,6 @@ static void print_secure_boot(void) status & ZYNQMP_CSU_STATUS_ENCRYPTED ? "" : "not "); } -#define PS_SYSMON_ANALOG_BUS_VAL 0x3210 -#define PS_SYSMON_ANALOG_BUS_REG 0xFFA50914 - int board_init(void) { #if defined(CONFIG_ZYNQMP_FIRMWARE) @@ -429,9 +426,6 @@ int board_init(void) printf("EL Level:\tEL%d\n", current_el()); - /* Bug in ROM sets wrong value in this register */ - writel(PS_SYSMON_ANALOG_BUS_VAL, PS_SYSMON_ANALOG_BUS_REG); - #if CONFIG_IS_ENABLED(FPGA) && defined(CONFIG_FPGA_ZYNQMPPL) zynqmppl.name = zynqmp_get_silicon_idcode_name(); printf("Chip ID:\t%s\n", zynqmppl.name); -- 2.35.1

2 1