[PATCH v11 1/2] board: riscv: add openpiton-riscv64 SoC support
This patch adds openpiton-riscv64 SOC support. In particular, this
board supports a standard bootflow through zsbl->u-boot SPL->
opensbi->u-boot proper->Linux. There are separate defconfigs for
building u-boot SPL and u-boot proper
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
Reviewed-by: Leo Yu-Chi Liang
---
arch/riscv/Kconfig | 4 +
arch/riscv/dts/Makefile | 1 +
arch/riscv/dts/openpiton-riscv64.dts| 153
board/openpiton/riscv64/Kconfig | 40 +++
board/openpiton/riscv64/MAINTAINERS | 8 +
board/openpiton/riscv64/Makefile| 5 +
board/openpiton/riscv64/openpiton-riscv64.c | 33 ++
configs/openpiton_riscv64_defconfig | 76
configs/openpiton_riscv64_spl_defconfig | 87 +
doc/board/index.rst | 1 +
doc/board/openpiton/index.rst | 9 +
doc/board/openpiton/riscv64.rst | 376
include/configs/openpiton-riscv64.h | 61
13 files changed, 854 insertions(+)
create mode 100644 arch/riscv/dts/openpiton-riscv64.dts
create mode 100644 board/openpiton/riscv64/Kconfig
create mode 100644 board/openpiton/riscv64/MAINTAINERS
create mode 100644 board/openpiton/riscv64/Makefile
create mode 100644 board/openpiton/riscv64/openpiton-riscv64.c
create mode 100644 configs/openpiton_riscv64_defconfig
create mode 100644 configs/openpiton_riscv64_spl_defconfig
create mode 100644 doc/board/openpiton/index.rst
create mode 100644 doc/board/openpiton/riscv64.rst
create mode 100644 include/configs/openpiton-riscv64.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index b3d7fd84ce..4b0c3dffa6 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -26,6 +26,9 @@ config TARGET_SIFIVE_UNMATCHED
config TARGET_SIPEED_MAIX
bool "Support Sipeed Maix Board"
+config TARGET_OPENPITON_RISCV64
+ bool "Support RISC-V cores on OpenPiton SoC"
+
endchoice
config SYS_ICACHE_OFF
@@ -60,6 +63,7 @@ source "board/emulation/qemu-riscv/Kconfig"
source "board/microchip/mpfs_icicle/Kconfig"
source "board/sifive/unleashed/Kconfig"
source "board/sifive/unmatched/Kconfig"
+source "board/openpiton/riscv64/Kconfig"
source "board/sipeed/maix/Kconfig"
# platform-specific options below
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 7778874831..b6e9166767 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -3,6 +3,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
diff --git a/arch/riscv/dts/openpiton-riscv64.dts
b/arch/riscv/dts/openpiton-riscv64.dts
new file mode 100644
index 00..45951e1236
--- /dev/null
+++ b/arch/riscv/dts/openpiton-riscv64.dts
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2021 Tianrui Wei */
+
+/*
+ * This dts is for a dual core instance of OpenPiton+Ariane built
+ * to run on a Digilent Genesys 2 FPGA at 66.67MHz. These files
+ * are automatically generated by the OpenPiton build system and
+ * this configuration may not be what you need if your configuration
+ * is different from the below.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "openpiton,riscv64";
+
+ chosen {
+ stdout-path = "uart0:115200";
+ };
+
+ aliases {
+ console =
+ serial0 =
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <520835>;
+
+ CPU0: cpu@0 {
+ clocks = <>;
+ u-boot,dm-spl;
+ device_type = "cpu";
+ reg = <0>;
+ compatible = "openhwgroup,cva6", "riscv";
+ riscv,isa = "rv64imafdc";
+ mmu-type = "riscv,sv39";
+ tlb-split;
+ // HLIC - hart local interrupt controller
+ CPU0_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ };
+ };
+
+ CPU1: cpu@1 {
+ clocks = <>;
+ device_type = "cpu";
+ reg = <1>;
+ compatible = "openhwgroup,cva6", "riscv";
+ riscv,isa = "rv64imafdc";
+
[PATCH v11 2/2] mmc: openpiton: add piton_mmc driver
This commit adds support to piton_mmc driver for OpenPiton-riscv64
This driver has many things set as preconfigured because the hardware
automatically configures most of the settings during startup.
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
Reviewed-by: Jaehoon Chung
---
drivers/mmc/Kconfig | 9 +++
drivers/mmc/Makefile| 1 +
drivers/mmc/piton_mmc.c | 161
3 files changed, 171 insertions(+)
create mode 100644 drivers/mmc/piton_mmc.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 0909f502a1..d0176175e8 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -727,6 +727,15 @@ config MMC_SUNXI_HAS_MODE_SWITCH
bool
depends on MMC_SUNXI
+config MMC_PITON
+ bool "MMC support for OpenPiton SoC"
+ depends on DM_MMC && BLK
+ help
+ This selects support for the SD host controller on OpenPiton SoC.
+ Note that this SD controller directly exposes the contents of the
+ SD card as memory mapped, so there is no manual configuration
+ required
+
config GENERIC_ATMEL_MCI
bool "Atmel Multimedia Card Interface support"
depends on DM_MMC && BLK && ARCH_AT91
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 89d6af3db3..d96ac90719 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_MMC_SDHCI_XENON) += xenon_sdhci.o
obj-$(CONFIG_MMC_SDHCI_ZYNQ) += zynq_sdhci.o
obj-$(CONFIG_MMC_SUNXI)+= sunxi_mmc.o
+obj-$(CONFIG_MMC_PITON)+= piton_mmc.o
obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o
obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o
obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o
diff --git a/drivers/mmc/piton_mmc.c b/drivers/mmc/piton_mmc.c
new file mode 100644
index 00..9f5da6d633
--- /dev/null
+++ b/drivers/mmc/piton_mmc.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2009 SAMSUNG Electronics
+ * Minkyu Kang
+ * Jaehoon Chung
+ * Portions Copyright 2011-2019 NVIDIA Corporation
+ * Portions Copyright 2021 Tianrui Wei
+ * This file is adapted from tegra_mmc.c
+ * Tianrui Wei
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define PITON_MMC_DUMMY_F_MAX 2000
+#define PITON_MMC_DUMMY_F_MIN 1000
+#define PITON_MMC_DUMMY_CAPACITY SZ_4G << 3
+#define PITON_MMC_DUMMY_B_MAX SZ_4G
+
+struct piton_mmc_plat {
+ struct mmc_config cfg;
+ struct mmc mmc;
+};
+
+struct piton_mmc_priv {
+ void __iomem *base_addr;
+};
+
+static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
+ if (!data)
+ return 0;
+
+ struct piton_mmc_priv *priv = dev_get_priv(dev);
+ u32 *buff, *start_addr, *write_src;
+ size_t byte_cnt, start_block;
+
+ buff = (u32 *)data->dest;
+ write_src = (u32 *)data->src;
+ start_block = cmd->cmdarg;
+ start_addr = priv->base_addr + start_block;
+
+ /* if there is a read */
+ for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
+byte_cnt -= sizeof(u32)) {
+ if (data->flags & MMC_DATA_READ) {
+ *buff++ = readl(start_addr++);
+ }
+ else if (data->flags & MMC_DATA_WRITE) {
+ writel(*write_src++,start_addr++);
+ }
+ }
+ return 0;
+}
+
+static int piton_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+ struct piton_mmc_priv *priv = dev_get_priv(dev);
+ struct piton_mmc_plat *plat = dev_get_plat(dev);
+ struct mmc_config *cfg;
+ struct mmc *mmc;
+ struct blk_desc *bdesc;
+
+ priv->base_addr = (void *)dev_read_addr(dev);
+ cfg = >cfg;
+ cfg->name = "PITON MMC";
+ cfg->host_caps = MMC_MODE_8BIT;
+ cfg->f_max = PITON_MMC_DUMMY_F_MAX;
+ cfg->f_min = PITON_MMC_DUMMY_F_MIN;
+ cfg->voltages = MMC_VDD_21_22;
+
+ mmc = >mmc;
+ mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
+ mmc->capacity_user = PITON_MMC_DUMMY_CAPACITY;
+ mmc->capacity_user *= mmc->read_bl_len;
+ mmc->capacity_boot = 0;
+ mmc->capacity_rpmb = 0;
+ for (int i = 0; i < 4; i++)
+ mmc->capacity_gp[i] = 0;
+ mmc->capacity = PITON_MMC_DUMMY_CAPACITY;
+ mmc->has_init = 1;
+
+ bdesc = mmc_get_blk_desc(mmc);
+ bdesc->lun = 0;
+ bdesc->hwpart = 0;
+ bdesc->type = 0;
+ bdesc->blksz = mmc->read_bl_len;
+ bdesc->log2blksz = LOG2(bdesc->blksz);
+ bdesc->lba = lldiv(mmc->capacity, mmc->read_bl_len);
+
+ return 0;
+}
+
+static int piton_mmc_getcd(struct udevice *dev)
+{
+
[PATCH v11 0/2] Add OpenPiton-riscv64 Board Support
This patch set is to add OpenPiton board support. Patches are split into several parts: - [PATCH 1/2] add OpenPiton support to mmc driver - [PATCH 2/2] add support for OpenPiton board Description - for mmc driver, it's settings are automatically configured at hardware level. We only need to expose the memory mapped interface through U-Boot driver model - For OpenPiton, as we need to embed the device tree blob into the bitstream, there is currently no itb support Tests checks - Able to boot Debian Linux from SD card on Digilent Genesys 2 - Checkpatch is performed, with some warnings ignored Changelogs - V2 . fix styles and typos in [1/2] and [2/2] . add board documentation in [2/2] - V3 . fix styles in [1/2] - V4 . fix checkpatch warnings in [1/2] except MAINTAINERS - V5 . major changes in device tree . changed to OF_SEPARATE . formatting update for mmc - V6 . eliminate debug outputs altogether . separate defconfigs between SPL and u-boot proper . style updates thanks to Sean - V7 . mmc dm fixes . mmc style updates, improving readibility . mmc add write support . OpenPiton RISC-V 64 board Kconfig fixes - V8 . mmc style updates - V9 . fix typo in board doc - V10, V11 . add reviewed-by tags Acknowledgements We'd like to thank all maintainers who have reviewed our code. But we'd like to thank Sean, Jaehoon and Leo in particular for taking much time and energy to help us write better code. Tianrui Wei (2): board: riscv: add openpiton-riscv64 SoC support mmc: openpiton: add piton_mmc driver arch/riscv/Kconfig | 4 + arch/riscv/dts/Makefile | 1 + arch/riscv/dts/openpiton-riscv64.dts| 153 board/openpiton/riscv64/Kconfig | 40 +++ board/openpiton/riscv64/MAINTAINERS | 8 + board/openpiton/riscv64/Makefile| 5 + board/openpiton/riscv64/openpiton-riscv64.c | 33 ++ configs/openpiton_riscv64_defconfig | 76 configs/openpiton_riscv64_spl_defconfig | 87 + doc/board/index.rst | 1 + doc/board/openpiton/index.rst | 9 + doc/board/openpiton/riscv64.rst | 376 drivers/mmc/Kconfig | 9 + drivers/mmc/Makefile| 1 + drivers/mmc/piton_mmc.c | 161 + include/configs/openpiton-riscv64.h | 61 16 files changed, 1025 insertions(+) create mode 100644 arch/riscv/dts/openpiton-riscv64.dts create mode 100644 board/openpiton/riscv64/Kconfig create mode 100644 board/openpiton/riscv64/MAINTAINERS create mode 100644 board/openpiton/riscv64/Makefile create mode 100644 board/openpiton/riscv64/openpiton-riscv64.c create mode 100644 configs/openpiton_riscv64_defconfig create mode 100644 configs/openpiton_riscv64_spl_defconfig create mode 100644 doc/board/openpiton/index.rst create mode 100644 doc/board/openpiton/riscv64.rst create mode 100644 drivers/mmc/piton_mmc.c create mode 100644 include/configs/openpiton-riscv64.h -- 2.32.0
[PATCH 4/4] NSA310S : Add DM SATA configs
Enable DM SATA, removed IDE driver, and add SATA MV driver. Signed-off-by: Tony Dinh --- include/configs/nsa310s.h | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/include/configs/nsa310s.h b/include/configs/nsa310s.h index e38c65a485..94f293de90 100644 --- a/include/configs/nsa310s.h +++ b/include/configs/nsa310s.h @@ -1,5 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* + * Copyright (C) 2021 Tony Dinh * Copyright (C) 2015 * Gerald Kerma * Tony Dinh @@ -46,10 +47,10 @@ #endif /* CONFIG_CMD_NET */ /* SATA driver configuration */ -#ifdef CONFIG_IDE -#define __io -#define CONFIG_SYS_ATA_IDE0_OFFSET MV_SATA_PORT0_OFFSET -#endif /* CONFIG_IDE */ +#ifdef CONFIG_SATA +#define CONFIG_SYS_SATA_MAX_DEVICE 1 +#define CONFIG_LBA48 +#endif /* CONFIG_SATA */ /* RTC driver configuration */ #ifdef CONFIG_CMD_DATE -- 2.20.1
[PATCH 3/4] NSA310S : Use Ethernet PHY name from device tree
In DM Ethernet, the old "egiga0" name is no longer valid, so replace it
with Ethernet PHY name from device tree.
Signed-off-by: Tony Dinh
---
board/zyxel/nsa310s/nsa310s.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/board/zyxel/nsa310s/nsa310s.c b/board/zyxel/nsa310s/nsa310s.c
index cd4a7723b1..29aded1910 100644
--- a/board/zyxel/nsa310s/nsa310s.c
+++ b/board/zyxel/nsa310s/nsa310s.c
@@ -1,5 +1,6 @@
// SPDX-License-Identifier: GPL-2.0+
/*
+ * Copyright (C) 2021 Tony Dinh
* Copyright (C) 2015
* Gerald Kerma
* Tony Dinh
@@ -81,22 +82,18 @@ int board_init(void)
return 0;
}
+#define PHY_ADR1
+
#ifdef CONFIG_RESET_PHY_R
void reset_phy(void)
{
u16 reg;
- u16 phyaddr;
- char *name = "egiga0";
+ u16 phyaddr = PHY_ADR;
+ char *name = "ethernet-controller@72000";
if (miiphy_set_current_dev(name))
return;
- /* read PHY dev address */
- if (miiphy_read(name, 0xee, 0xee, (u16 *) )) {
- printf("could not read PHY dev address\n");
- return;
- }
-
/* set RGMII delay */
miiphy_write(name, phyaddr, MV88E1318_PGADR_REG, MV88E1318_MAC_CTRL_PG);
miiphy_read(name, phyaddr, MV88E1318_MAC_CTRL_REG, );
@@ -131,5 +128,7 @@ void reset_phy(void)
/* downshift */
miiphy_write(name, phyaddr, 0x10, 0x3860);
miiphy_write(name, phyaddr, 0x0, 0x9140);
+
+ printf("MV88E1318 PHY initialized on %s\n", name);
}
#endif /* CONFIG_RESET_PHY_R */
--
2.20.1
[PATCH 2/4] NSA310S : Add DM USB, DM Ethernet, and DM SATA configs
Convert to Driver Model. - Add DM USB, DM Ethernet, and DM SATA configs to nsa310s_defconfig - Add CONFIG_DEFAULT_DEVICE_TREE to nsa310s_defconfig - Move CONFIG_ENV_SECT_SIZE from board file to nsa310s_defconfig - Add CONFIG_IDENT_STRING, and CONFIG_NET_RANDOM_ETHADDR to nsa310s_defconfig Signed-off-by: Tony Dinh --- configs/nsa310s_defconfig | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/configs/nsa310s_defconfig b/configs/nsa310s_defconfig index e4cf1c470e..fac0322e2b 100644 --- a/configs/nsa310s_defconfig +++ b/configs/nsa310s_defconfig @@ -7,14 +7,16 @@ CONFIG_NR_DRAM_BANKS=2 CONFIG_TARGET_NSA310S=y CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0xE +CONFIG_ENV_SECT_SIZE=0x2 +CONFIG_DEFAULT_DEVICE_TREE="kirkwood-nsa310s" CONFIG_BOOTDELAY=3 CONFIG_USE_PREBOOT=y # CONFIG_DISPLAY_BOARDINFO is not set CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="nsa310s => " +CONFIG_IDENT_STRING="\nZyXEL NSA310S/320S 1/2-Bay Power Media Server" CONFIG_CMD_BOOTZ=y # CONFIG_CMD_FLASH is not set -CONFIG_CMD_IDE=y CONFIG_CMD_NAND=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set @@ -44,3 +46,11 @@ CONFIG_USB_STORAGE=y CONFIG_LZMA=y CONFIG_BZIP2=y CONFIG_OF_LIBFDT=y +CONFIG_DM=y +CONFIG_BLK=y +CONFIG_OF_CONTROL=y +CONFIG_DM_USB=y +CONFIG_DM_ETH=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_CMD_SATA=y +CONFIG_SATA_MV=y -- 2.20.1
[PATCH 1/4] NSA310S : Add device tree DTS for Zyxel NSA310S board
Add device tree kirkwood-nsa310s.dts for Zyxel NSA310S board to
convert to Driver Model.
Signed-off-by: Tony Dinh
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/kirkwood-nsa310s.dts | 318 ++
2 files changed, 319 insertions(+)
create mode 100644 arch/arm/dts/kirkwood-nsa310s.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 096068261d..0ff77c8b3d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -56,6 +56,7 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += \
kirkwood-ns2lite.dtb \
kirkwood-ns2max.dtb \
kirkwood-ns2mini.dtb \
+ kirkwood-nsa310s.dtb \
kirkwood-openrd-base.dtb \
kirkwood-openrd-client.dtb \
kirkwood-openrd-ultimate.dtb \
diff --git a/arch/arm/dts/kirkwood-nsa310s.dts
b/arch/arm/dts/kirkwood-nsa310s.dts
new file mode 100644
index 00..e1c9c9080c
--- /dev/null
+++ b/arch/arm/dts/kirkwood-nsa310s.dts
@@ -0,0 +1,318 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device tree file for the Zyxel NSA 310S NAS box.
+ *
+ * Copyright (c) 2015-2021, Tony Dinh
+ *
+ * Based on
+ * Copyright (c) 2014, Adam Baker
+ * Based upon the board setup file created by Peter Schildmann
+ */
+/dts-v1/;
+
+#include "kirkwood.dtsi"
+#include "kirkwood-6281.dtsi"
+
+/ {
+ model = "Zyxel NSA310S";
+ compatible = "zyxel,nsa320s", "marvell,kirkwood-88f6702",
"marvell,kirkwood";
+
+ memory {
+ device_type = "memory";
+ reg = <0x 0x1000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ stdout-path =
+ };
+
+ ocp@f100 {
+ pinctrl: pin-controller@1 {
+ pinctrl-names = "default";
+
+ pmx_sata0: pmx-sata0 {
+ marvell,pins ;
+ marvell,function = "sata0";
+ };
+
+ pmx_sata1: pmx-sata1 {
+ marvell,pins ;
+ marvell,function = "sata1";
+ };
+
+ pmx_usb_power: pmx-usb-power {
+ marvell,pins = "mpp21";
+ marvell,function = "gpio";
+ };
+
+ pmx_pwr_off: pmx-pwr-off {
+ marvell,pins = "mpp27";
+ marvell,function = "gpio";
+ };
+
+ pmx_btn_reset: pmx-btn-reset {
+ marvell,pins = "mpp24";
+ marvell,function = "gpio";
+ };
+
+ pmx_btn_copy: pmx-btn-copy {
+ marvell,pins = "mpp25";
+ marvell,function = "gpio";
+ };
+
+ pmx_btn_power: pmx-btn-power {
+ marvell,pins = "mpp26";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd2_green: pmx-led-hdd2-green {
+ marvell,pins = "mpp34";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd2_red: pmx-led-hdd2-red {
+ marvell,pins = "mpp12";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_usb_green: pmx-led-usb-green {
+ marvell,pins = "mpp15";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_copy_green: pmx-led-copy-green {
+ marvell,pins = "mpp22";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_copy_red: pmx-led-copy-red {
+ marvell,pins = "mpp23";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_sys_green: pmx-led-sys-green {
+ marvell,pins = "mpp28";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_sys_orange: pmx-led-sys-orange {
+ marvell,pins = "mpp29";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd1_green: pmx-led-hdd1-green {
+ marvell,pins = "mpp16";
+ marvell,function = "gpio";
+ };
+
+ pmx_led_hdd1_red: pmx-led-hdd1-red {
+ marvell,pins = "mpp13";
+ marvell,function = "gpio";
+ };
[PATCH 0/4] Zyxel NSA310S NAS : convert to Driver Model.
- Add device tree kirkwood-nsa310s.dts - Add DM_USB, DM_ETH, DM_SATA and associated configs to nsa310s_defconfig - Move some miscellaneous configs from board file to nsa310s_defconfig - Replace old device name "egiga0" with Ethernet PHY name from device tree kirkwood.dtsi - Removed IDE, and add SATA configs in board file nsa310s.c Tony Dinh (4): NSA310S : Add device tree DTS for Zyxel NSA310S board NSA310S : Add DM USB, DM Ethernet, and DM SATA configs NSA310S : Use Ethernet PHY name from device tree NSA310S : Add DM SATA configs arch/arm/dts/Makefile | 1 + arch/arm/dts/kirkwood-nsa310s.dts | 318 ++ board/zyxel/nsa310s/nsa310s.c | 15 +- configs/nsa310s_defconfig | 12 +- include/configs/nsa310s.h | 9 +- 5 files changed, 342 insertions(+), 13 deletions(-) create mode 100644 arch/arm/dts/kirkwood-nsa310s.dts -- 2.20.1
Suggestion: When flash is uninitialized, *silently* fall back to default environment
Consider a boot ROM that looks for u-boot in several places (SPI
flash, eMMC flash, etc) and loads the first one it finds, and then
u-boot repeats the same search to find its own configuration. If
there is _nothing_ on the SPI flash and u-boot and all its
configuration is on the eMMC, this will work fine _except_ that you'll
get a scary-looking message from env_set_default
*** Warning: bad CRC, using default environment
because uninitialized flash memory reads as all-ones (FF FF FF FF ...)
and the crc32 of ENV_SIZE bytes of 0xFF will typically not be 0x.
I'd like to suggest that env_import() should, when the CRC fails, scan
the environment block, and if it's uniformly 0xFF or uniformly 0x00,
then it should call env_set_default(0,0) instead of
env_set_default("bad CRC", 0). If I'm reading the code right, the
only effect of this will be to suppress the warning message.
Thanks for your consideration,
zw
ps. Can we be sure that the crc32 of ENV_SIZE bytes of 0xFF will
_never_ be 0x and the crc32 of ENV_SIZE bytes of 0x00 will _never_
be 0x? If not, it might be wise to do the scans for blank
flash/disk sectors _first_, rather than relying on the CRC to detect
them.
Re: [PATCH v2 1/2] efi_loader: fix set_capsule_result()
On Thu, Jul 01, 2021 at 03:20:48AM +0200, Heinrich Schuchardt wrote:
> Am 1. Juli 2021 02:49:09 MESZ schrieb AKASHI Takahiro
> :
> >NAK.
For example,
> >On Wed, Jun 30, 2021 at 05:31:15PM +0200, Heinrich Schuchardt wrote:
> >> The log category must be LOG_CATEGORY LOGC_EFI.
This one above and
> >> efi_set_variable() should be called with EFI_CALL(). Use
> >> efi_set_variable_int() instead.
and this are mutually irrelevant.
> >> A log text "Updating ..." if SetVariable() fails does not make sense
> >for a
> >> variable that is not required to be preexisting.
This change is also irrelevant.
> >> CapsuleLast should always be immediately updated.
> >
> >As I said to your v1 in [1],
> >
> >You are trying to fix several irrelevant issues here.
>
> Why do you think the changes are irrelevant?
No question.
-Takahiro Akashi
> >Please split them into separate patches as you have always
> >asked me before.
>
> Splitting does not change relevance.
>
> Do you want to play tit for tat?
>
> Best regards
>
> Heinrich
>
> >
> >[1] https://lists.denx.de/pipermail/u-boot/2021-June/453148.html
> >
> >-Takahiro Akashi
> >
> >
> >
> >> Signed-off-by: Heinrich Schuchardt
> >> ---
> >> v2:
> >>don't update OsIndications in set_capsule_result()
> >>update CapsuleLast immediately
> >> ---
> >> lib/efi_loader/efi_capsule.c | 39
> >+++-
> >> 1 file changed, 21 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/lib/efi_loader/efi_capsule.c
> >b/lib/efi_loader/efi_capsule.c
> >> index 2c37a0d97b..f87ef2a514 100644
> >> --- a/lib/efi_loader/efi_capsule.c
> >> +++ b/lib/efi_loader/efi_capsule.c
> >> @@ -6,6 +6,8 @@
> >> *Author: AKASHI Takahiro
> >> */
> >>
> >> +#define LOG_CATEGORY LOGC_EFI
> >> +
> >> #include
> >> #include
> >> #include
> >> @@ -95,13 +97,25 @@ void set_capsule_result(int index, struct
> >efi_capsule_header *capsule,
> >>else
> >>memset(_processed, 0, sizeof(time));
> >>result.capsule_status = return_status;
> >> - ret = efi_set_variable(variable_name16, _guid_capsule_report,
> >> - EFI_VARIABLE_NON_VOLATILE |
> >> - EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >> - EFI_VARIABLE_RUNTIME_ACCESS,
> >> - sizeof(result), );
> >> - if (ret)
> >> - log_err("EFI: creating %ls failed\n", variable_name16);
> >> + ret = efi_set_variable_int(variable_name16,
> >_guid_capsule_report,
> >> + EFI_VARIABLE_NON_VOLATILE |
> >> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >> + EFI_VARIABLE_RUNTIME_ACCESS,
> >> + sizeof(result), , false);
> >> + if (ret != EFI_SUCCESS) {
> >> + log_err("Setting %ls failed\n", variable_name16);
> >> + return;
> >> + }
> >> +
> >> + /* Variable CapsuleLast must not include terminating 0x */
> >> + ret = efi_set_variable_int(L"CapsuleLast",
> >_guid_capsule_report,
> >> + EFI_VARIABLE_READ_ONLY |
> >> + EFI_VARIABLE_NON_VOLATILE |
> >> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >> + EFI_VARIABLE_RUNTIME_ACCESS,
> >> + 22, variable_name16, false);
> >> + if (ret != EFI_SUCCESS)
> >> + log_err("Setting %ls failed\n", L"CapsuleLast");
> >> }
> >>
> >> #ifdef CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT
> >> @@ -988,7 +1002,6 @@ efi_status_t efi_launch_capsules(void)
> >>struct efi_capsule_header *capsule = NULL;
> >>u16 **files;
> >>unsigned int nfiles, index, i;
> >> - u16 variable_name16[12];
> >>efi_status_t ret;
> >>
> >>if (!check_run_capsules())
> >> @@ -1045,16 +1058,6 @@ efi_status_t efi_launch_capsules(void)
> >>free(files[i]);
> >>free(files);
> >>
> >> - /* CapsuleLast */
> >> - efi_create_indexed_name(variable_name16, sizeof(variable_name16),
> >> - "Capsule", index - 1);
> >> - efi_set_variable_int(L"CapsuleLast", _guid_capsule_report,
> >> - EFI_VARIABLE_READ_ONLY |
> >> - EFI_VARIABLE_NON_VOLATILE |
> >> - EFI_VARIABLE_BOOTSERVICE_ACCESS |
> >> - EFI_VARIABLE_RUNTIME_ACCESS,
> >> - 22, variable_name16, false);
> >> -
> >>return ret;
> >> }
> >> #endif /* CONFIG_EFI_CAPSULE_ON_DISK */
> >> --
> >> 2.30.2
> >>
>
Re: [PATCH v2 1/2] efi_loader: fix set_capsule_result()
Am 1. Juli 2021 02:49:09 MESZ schrieb AKASHI Takahiro
:
>NAK.
>
>On Wed, Jun 30, 2021 at 05:31:15PM +0200, Heinrich Schuchardt wrote:
>> The log category must be LOG_CATEGORY LOGC_EFI.
>>
>> efi_set_variable() should be called with EFI_CALL(). Use
>> efi_set_variable_int() instead.
>>
>> A log text "Updating ..." if SetVariable() fails does not make sense
>for a
>> variable that is not required to be preexisting.
>>
>> CapsuleLast should always be immediately updated.
>
>As I said to your v1 in [1],
>
>You are trying to fix several irrelevant issues here.
Why do you think the changes are irrelevant?
>Please split them into separate patches as you have always
>asked me before.
Splitting does not change relevance.
Do you want to play tit for tat?
Best regards
Heinrich
>
>[1] https://lists.denx.de/pipermail/u-boot/2021-June/453148.html
>
>-Takahiro Akashi
>
>
>
>> Signed-off-by: Heinrich Schuchardt
>> ---
>> v2:
>> don't update OsIndications in set_capsule_result()
>> update CapsuleLast immediately
>> ---
>> lib/efi_loader/efi_capsule.c | 39
>+++-
>> 1 file changed, 21 insertions(+), 18 deletions(-)
>>
>> diff --git a/lib/efi_loader/efi_capsule.c
>b/lib/efi_loader/efi_capsule.c
>> index 2c37a0d97b..f87ef2a514 100644
>> --- a/lib/efi_loader/efi_capsule.c
>> +++ b/lib/efi_loader/efi_capsule.c
>> @@ -6,6 +6,8 @@
>> * Author: AKASHI Takahiro
>> */
>>
>> +#define LOG_CATEGORY LOGC_EFI
>> +
>> #include
>> #include
>> #include
>> @@ -95,13 +97,25 @@ void set_capsule_result(int index, struct
>efi_capsule_header *capsule,
>> else
>> memset(_processed, 0, sizeof(time));
>> result.capsule_status = return_status;
>> -ret = efi_set_variable(variable_name16, _guid_capsule_report,
>> - EFI_VARIABLE_NON_VOLATILE |
>> - EFI_VARIABLE_BOOTSERVICE_ACCESS |
>> - EFI_VARIABLE_RUNTIME_ACCESS,
>> - sizeof(result), );
>> -if (ret)
>> -log_err("EFI: creating %ls failed\n", variable_name16);
>> +ret = efi_set_variable_int(variable_name16,
>_guid_capsule_report,
>> + EFI_VARIABLE_NON_VOLATILE |
>> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
>> + EFI_VARIABLE_RUNTIME_ACCESS,
>> + sizeof(result), , false);
>> +if (ret != EFI_SUCCESS) {
>> +log_err("Setting %ls failed\n", variable_name16);
>> +return;
>> +}
>> +
>> +/* Variable CapsuleLast must not include terminating 0x */
>> +ret = efi_set_variable_int(L"CapsuleLast",
>_guid_capsule_report,
>> + EFI_VARIABLE_READ_ONLY |
>> + EFI_VARIABLE_NON_VOLATILE |
>> + EFI_VARIABLE_BOOTSERVICE_ACCESS |
>> + EFI_VARIABLE_RUNTIME_ACCESS,
>> + 22, variable_name16, false);
>> +if (ret != EFI_SUCCESS)
>> +log_err("Setting %ls failed\n", L"CapsuleLast");
>> }
>>
>> #ifdef CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT
>> @@ -988,7 +1002,6 @@ efi_status_t efi_launch_capsules(void)
>> struct efi_capsule_header *capsule = NULL;
>> u16 **files;
>> unsigned int nfiles, index, i;
>> -u16 variable_name16[12];
>> efi_status_t ret;
>>
>> if (!check_run_capsules())
>> @@ -1045,16 +1058,6 @@ efi_status_t efi_launch_capsules(void)
>> free(files[i]);
>> free(files);
>>
>> -/* CapsuleLast */
>> -efi_create_indexed_name(variable_name16, sizeof(variable_name16),
>> -"Capsule", index - 1);
>> -efi_set_variable_int(L"CapsuleLast", _guid_capsule_report,
>> - EFI_VARIABLE_READ_ONLY |
>> - EFI_VARIABLE_NON_VOLATILE |
>> - EFI_VARIABLE_BOOTSERVICE_ACCESS |
>> - EFI_VARIABLE_RUNTIME_ACCESS,
>> - 22, variable_name16, false);
>> -
>> return ret;
>> }
>> #endif /* CONFIG_EFI_CAPSULE_ON_DISK */
>> --
>> 2.30.2
>>
Re: [PATCH v2 1/2] efi_loader: fix set_capsule_result()
NAK.
On Wed, Jun 30, 2021 at 05:31:15PM +0200, Heinrich Schuchardt wrote:
> The log category must be LOG_CATEGORY LOGC_EFI.
>
> efi_set_variable() should be called with EFI_CALL(). Use
> efi_set_variable_int() instead.
>
> A log text "Updating ..." if SetVariable() fails does not make sense for a
> variable that is not required to be preexisting.
>
> CapsuleLast should always be immediately updated.
As I said to your v1 in [1],
You are trying to fix several irrelevant issues here.
Please split them into separate patches as you have always
asked me before.
[1] https://lists.denx.de/pipermail/u-boot/2021-June/453148.html
-Takahiro Akashi
> Signed-off-by: Heinrich Schuchardt
> ---
> v2:
> don't update OsIndications in set_capsule_result()
> update CapsuleLast immediately
> ---
> lib/efi_loader/efi_capsule.c | 39 +++-
> 1 file changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 2c37a0d97b..f87ef2a514 100644
> --- a/lib/efi_loader/efi_capsule.c
> +++ b/lib/efi_loader/efi_capsule.c
> @@ -6,6 +6,8 @@
> * Author: AKASHI Takahiro
> */
>
> +#define LOG_CATEGORY LOGC_EFI
> +
> #include
> #include
> #include
> @@ -95,13 +97,25 @@ void set_capsule_result(int index, struct
> efi_capsule_header *capsule,
> else
> memset(_processed, 0, sizeof(time));
> result.capsule_status = return_status;
> - ret = efi_set_variable(variable_name16, _guid_capsule_report,
> -EFI_VARIABLE_NON_VOLATILE |
> -EFI_VARIABLE_BOOTSERVICE_ACCESS |
> -EFI_VARIABLE_RUNTIME_ACCESS,
> -sizeof(result), );
> - if (ret)
> - log_err("EFI: creating %ls failed\n", variable_name16);
> + ret = efi_set_variable_int(variable_name16, _guid_capsule_report,
> +EFI_VARIABLE_NON_VOLATILE |
> +EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +EFI_VARIABLE_RUNTIME_ACCESS,
> +sizeof(result), , false);
> + if (ret != EFI_SUCCESS) {
> + log_err("Setting %ls failed\n", variable_name16);
> + return;
> + }
> +
> + /* Variable CapsuleLast must not include terminating 0x */
> + ret = efi_set_variable_int(L"CapsuleLast", _guid_capsule_report,
> +EFI_VARIABLE_READ_ONLY |
> +EFI_VARIABLE_NON_VOLATILE |
> +EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +EFI_VARIABLE_RUNTIME_ACCESS,
> +22, variable_name16, false);
> + if (ret != EFI_SUCCESS)
> + log_err("Setting %ls failed\n", L"CapsuleLast");
> }
>
> #ifdef CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT
> @@ -988,7 +1002,6 @@ efi_status_t efi_launch_capsules(void)
> struct efi_capsule_header *capsule = NULL;
> u16 **files;
> unsigned int nfiles, index, i;
> - u16 variable_name16[12];
> efi_status_t ret;
>
> if (!check_run_capsules())
> @@ -1045,16 +1058,6 @@ efi_status_t efi_launch_capsules(void)
> free(files[i]);
> free(files);
>
> - /* CapsuleLast */
> - efi_create_indexed_name(variable_name16, sizeof(variable_name16),
> - "Capsule", index - 1);
> - efi_set_variable_int(L"CapsuleLast", _guid_capsule_report,
> - EFI_VARIABLE_READ_ONLY |
> - EFI_VARIABLE_NON_VOLATILE |
> - EFI_VARIABLE_BOOTSERVICE_ACCESS |
> - EFI_VARIABLE_RUNTIME_ACCESS,
> - 22, variable_name16, false);
> -
> return ret;
> }
> #endif /* CONFIG_EFI_CAPSULE_ON_DISK */
> --
> 2.30.2
>
[PATCH 4/5] board: gateworks: venice: add ftd_file env vars on boot
The ftd_file* vars can be used by bootscripts to look for
appropriate dtb's
Signed-off-by: Tim Harvey
---
board/gateworks/venice/imx8mm_venice.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/board/gateworks/venice/imx8mm_venice.c
b/board/gateworks/venice/imx8mm_venice.c
index cb00f532bf..2657bd675f 100644
--- a/board/gateworks/venice/imx8mm_venice.c
+++ b/board/gateworks/venice/imx8mm_venice.c
@@ -105,13 +105,26 @@ int board_init(void)
int board_late_init(void)
{
- const char *ethmac;
+ const char *str;
char env[32];
int ret, i;
u8 enetaddr[6];
+ char fdt[64];
led_default_state();
+ /* Set fdt_file vars */
+ i = 0;
+ do {
+ str = gsc_get_dtb_name(i, fdt, sizeof(fdt));
+ if (str) {
+ sprintf(env, "fdt_file%d", i + 1);
+ strcat(fdt, ".dtb");
+ env_set(env, fdt);
+ }
+ i++;
+ } while (str);
+
/* Set mac addrs */
i = 0;
do {
@@ -119,8 +132,8 @@ int board_late_init(void)
sprintf(env, "eth%daddr", i);
else
sprintf(env, "ethaddr");
- ethmac = env_get(env);
- if (!ethmac) {
+ str = env_get(env);
+ if (!str) {
ret = gsc_getmac(i, enetaddr);
if (!ret)
eth_env_set_enetaddr(env, enetaddr);
--
2.17.1
[PATCH 5/5] board: gateworks: venice: remove forced enable of GSC thermal protection
The Gateworks System Controller thermal protection feature will disable
the board primary power supply if the on-board temperature sensor
reaches 86C. In many cases this could occur before the temperature
critical components such as CPU, DRAM, eMMC, and power supplies have
reached their max temperature.
Remove the forced re-enable of thermal protection so that users can
knowingly disable it.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/gsc.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/board/gateworks/venice/gsc.c b/board/gateworks/venice/gsc.c
index 9a6712ec88..c75bc6f855 100644
--- a/board/gateworks/venice/gsc.c
+++ b/board/gateworks/venice/gsc.c
@@ -221,9 +221,11 @@ static const char *gsc_get_rst_cause(struct udevice *dev)
/* thermal protection */
if (!dm_i2c_read(dev, GSC_SC_THERM_PROTECT, , 1)) {
- reg |= 1;
- dm_i2c_write(dev, GSC_SC_THERM_PROTECT, , 1);
- strcat(str, " Thermal Protection Enabled");
+ strcat(str, " Thermal Protection ");
+ if (reg & BIT(0))
+ strcat(str, "Enabled");
+ else
+ strcat(str, "Disabled");
}
return str;
--
2.17.1
[PATCH 2/5] board: gateworks: venice: gsc: fix voltage offset
The voltage offset property is in microvolts so must be scaled
accordingly.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/gsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/gateworks/venice/gsc.c b/board/gateworks/venice/gsc.c
index 23ad58094c..9a6712ec88 100644
--- a/board/gateworks/venice/gsc.c
+++ b/board/gateworks/venice/gsc.c
@@ -298,7 +298,7 @@ int gsc_hwmon(void)
}
/* adjust by offset */
- val += offset;
+ val += (offset / 1000);
printf("%-8s: %d.%03dV\n", label, val / 1000,
val % 1000);
break;
--
2.17.1
[PATCH 3/5] board: gateworks: venice: display DTB used
Display the DTB file used for U-Boot.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/imx8mm_venice.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/board/gateworks/venice/imx8mm_venice.c
b/board/gateworks/venice/imx8mm_venice.c
index 1d51b6ea9b..cb00f532bf 100644
--- a/board/gateworks/venice/imx8mm_venice.c
+++ b/board/gateworks/venice/imx8mm_venice.c
@@ -42,12 +42,16 @@ int board_fit_config_name_match(const char *name)
{
int i = 0;
const char *dtb;
+ static char init;
char buf[32];
do {
dtb = gsc_get_dtb_name(i++, buf, sizeof(buf));
- if (!strcmp(dtb, name))
+ if (!strcmp(dtb, name)) {
+ if (!init++)
+ printf("DTB : %s\n", name);
return 0;
+ }
} while (dtb);
return -1;
--
2.17.1
[PATCH 1/5] board: gateworks: venice: gsc: fix typo
Fix typo in error message.
Signed-off-by: Tim Harvey
---
board/gateworks/venice/gsc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/gateworks/venice/gsc.c b/board/gateworks/venice/gsc.c
index d2490e6063..23ad58094c 100644
--- a/board/gateworks/venice/gsc.c
+++ b/board/gateworks/venice/gsc.c
@@ -176,7 +176,7 @@ static int gsc_read_eeprom(int bus, int slave, int alen,
struct venice_board_inf
chksum += buf[i];
if ((info->chksum[0] != chksum >> 8) ||
(info->chksum[1] != (chksum & 0xff))) {
- printf("EEPROM: I2C%d@0x%02x: Invalid Model in EEPROM\n", bus,
slave);
+ printf("EEPROM: I2C%d@0x%02x: Invalid Checksum\n", bus, slave);
print_hex_dump_bytes("", DUMP_PREFIX_NONE, buf, sizeof(*info));
memset(info, 0, sizeof(*info));
return -EINVAL;
--
2.17.1
[PATCH 9/9] configs: imx8mm_venice_defconfig: add support for gbe switch
The imx8mm-venice-gw7901 board has an I2C connected KSZ9897S GbE switch with an IMX8MM FEC MAC master connected via RGMII_ID. Signed-off-by: Tim Harvey --- configs/imx8mm_venice_defconfig | 4 1 file changed, 4 insertions(+) diff --git a/configs/imx8mm_venice_defconfig b/configs/imx8mm_venice_defconfig index 3961db00cb..49affccec4 100644 --- a/configs/imx8mm_venice_defconfig +++ b/configs/imx8mm_venice_defconfig @@ -87,9 +87,13 @@ CONFIG_SPL_MMC_HS400_SUPPORT=y CONFIG_FSL_USDHC=y CONFIG_PHYLIB=y CONFIG_PHY_TI_DP83867=y +CONFIG_PHY_FIXED=y CONFIG_DM_ETH=y +CONFIG_DM_MDIO=y +CONFIG_DM_DSA=y CONFIG_PHY_GIGE=y CONFIG_FEC_MXC=y +CONFIG_KSZ9477=y CONFIG_MII=y CONFIG_PINCTRL=y CONFIG_SPL_PINCTRL=y -- 2.17.1
[PATCH 8/9] arm: dts: imx8mm-venice-gw7901.dts: fix dsa switch configuration
Fix the dsa switch config:
- remove the unnecessary phy-mode from the switch itself
- added the necessary fixed-link node to the non-cpu ports required
for U-Boot DSA
Signed-off-by: Tim Harvey
---
arch/arm/dts/imx8mm-venice-gw7901.dts | 37 ++-
1 file changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/arm/dts/imx8mm-venice-gw7901.dts
b/arch/arm/dts/imx8mm-venice-gw7901.dts
index 0216facb2a..124e1e4e70 100644
--- a/arch/arm/dts/imx8mm-venice-gw7901.dts
+++ b/arch/arm/dts/imx8mm-venice-gw7901.dts
@@ -577,7 +577,6 @@
pinctrl-0 = <_ksz>;
interrupt-parent = <>;
interrupts = <18 IRQ_TYPE_EDGE_FALLING>;
- phy-mode = "rgmii-id";
ports {
#address-cells = <1>;
@@ -587,24 +586,32 @@
reg = <0>;
label = "lan1";
local-mac-address = [00 00 00 00 00 00];
+ phy-handle = <_phy0>;
+ phy-mode = "internal";
};
lan2: port@1 {
reg = <1>;
label = "lan2";
local-mac-address = [00 00 00 00 00 00];
+ phy-handle = <_phy1>;
+ phy-mode = "internal";
};
lan3: port@2 {
reg = <2>;
label = "lan3";
local-mac-address = [00 00 00 00 00 00];
+ phy-handle = <_phy2>;
+ phy-mode = "internal";
};
lan4: port@3 {
reg = <3>;
label = "lan4";
local-mac-address = [00 00 00 00 00 00];
+ phy-handle = <_phy3>;
+ phy-mode = "internal";
};
port@5 {
@@ -619,6 +626,34 @@
};
};
};
+
+ mdios {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ reg = <0>;
+ compatible = "microchip,ksz-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ sw_phy0: ethernet-phy@0 {
+ reg = <0x0>;
+ };
+
+ sw_phy1: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+
+ sw_phy2: ethernet-phy@2 {
+ reg = <0x2>;
+ };
+
+ sw_phy3: ethernet-phy@3 {
+ reg = <0x3>;
+ };
+ };
+ };
};
crypto@60 {
--
2.17.1
[PATCH 7/9] net: add support for KSZ9477/KSZ9897/KSZ9567 GbE switch
The Microchip KSZ9477/KSZ9897/KSZ9567 7-Port Gigabit Ethernet Switches
support SGMII/RGMII/MII/RMII with register access via SPI, I2C, or MDIO.
This driver currently supports I2C register access but SPI or MDIO register
access can be easily added at a later time.
Tagging is not implemented and instead the active port is tracked to
avoid needing a tag to store port information.
This was tested with the imx8mm-venice-gw7901 board which has a
KSZ9897S switch with an IMX8MM FEC MAC master connected via RGMII_ID.
Signed-off-by: Tim Harvey
---
drivers/net/Kconfig | 7 +
drivers/net/Makefile | 1 +
drivers/net/ksz9477.c | 547 ++
3 files changed, 555 insertions(+)
create mode 100644 drivers/net/ksz9477.c
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 9fc28b149d..feeea960e2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -402,6 +402,13 @@ config KS8851_MLL_BASEADDR
endif #DM_ETH
endif #KS8851_MLL
+config KSZ9477
+ bool "Microchip KSZ9477 I2C controller driver"
+ depends on DM_DSA && DM_I2C
+ help
+ This driver implements a DSA switch driver for the KSZ9477 family
+ of GbE switches using the I2C interface.
+
config MVGBE
bool "Marvell Orion5x/Kirkwood network interface support"
depends on ARCH_KIRKWOOD || ARCH_ORION5X
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index d56baa65b2..03900ffa3a 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_FTMAC110) += ftmac110.o
obj-$(CONFIG_FTMAC100) += ftmac100.o
obj-$(CONFIG_GMAC_ROCKCHIP) += gmac_rockchip.o
obj-$(CONFIG_KS8851_MLL) += ks8851_mll.o
+obj-$(CONFIG_KSZ9477) += ksz9477.o
obj-$(CONFIG_LAN91C96) += lan91c96.o
obj-$(CONFIG_LPC32XX_ETH) += lpc32xx_eth.o
obj-$(CONFIG_MACB) += macb.o
diff --git a/drivers/net/ksz9477.c b/drivers/net/ksz9477.c
new file mode 100644
index 00..ab32f42127
--- /dev/null
+++ b/drivers/net/ksz9477.c
@@ -0,0 +1,547 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2020
+ * Tim Harvey, Gateworks Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+/* Global registers */
+
+/* Chip ID */
+#define REG_CHIP_ID0__10x
+
+/* Operation control */
+#define REG_SW_OPERATION 0x0300
+#define SW_RESET BIT(1)
+#define SW_START BIT(0)
+
+/* Port Specific Registers */
+#define PORT_CTRL_ADDR(port, addr) ((addr) | (((port) + 1) << 12))
+
+/* Port Control */
+#define REG_PORT_XMII_CTRL_1 0x0301
+#define PORT_MII_NOT_1GBIT BIT(6)
+#define PORT_MII_SEL_EDGE BIT(5)
+#define PORT_RGMII_ID_IG_ENABLEBIT(4)
+#define PORT_RGMII_ID_EG_ENABLEBIT(3)
+#define PORT_MII_MAC_MODE BIT(2)
+#define PORT_MII_SEL_M 0x3
+#define PORT_RGMII_SEL 0x0
+#define PORT_RMII_SEL 0x1
+#define PORT_GMII_SEL 0x2
+#define PORT_MII_SEL 0x3
+
+/* Port MSTP State Register */
+#define REG_PORT_MSTP_STATE0x0b04
+#define PORT_TX_ENABLE BIT(2)
+#define PORT_RX_ENABLE BIT(1)
+#define PORT_LEARN_DISABLE BIT(0)
+
+/* MMD */
+#define REG_PORT_PHY_MMD_SETUP 0x011A
+#define PORT_MMD_OP_MODE_M 0x3
+#define PORT_MMD_OP_MODE_S 14
+#define PORT_MMD_OP_INDEX 0
+#define PORT_MMD_OP_DATA_NO_INCR 1
+#define PORT_MMD_OP_DATA_INCR_RW 2
+#define PORT_MMD_OP_DATA_INCR_W3
+#define PORT_MMD_DEVICE_ID_M 0x1F
+#define MMD_SETUP(mode, dev) (((u16)(mode) << PORT_MMD_OP_MODE_S) |
(dev))
+#define REG_PORT_PHY_MMD_INDEX_DATA0x011C
+
+struct ksz_dsa_priv {
+ struct udevice *dev;
+ int active_port;
+};
+
+static inline int ksz_read8(struct udevice *dev, u32 reg, u8 *val)
+{
+ int ret = dm_i2c_read(dev, reg, val, 1);
+
+ dev_dbg(dev, "%s 0x%04x<<0x%02x\n", __func__, reg, *val);
+
+ return ret;
+}
+
+static inline int ksz_pread8(struct udevice *dev, int port, int reg, u8 *val)
+{
+ return ksz_read8(dev, PORT_CTRL_ADDR(port, reg), val);
+}
+
+static inline int ksz_write8(struct udevice *dev, u32 reg, u8 val)
+{
+ dev_dbg(dev, "%s 0x%04x>>0x%02x\n", __func__, reg, val);
+ return dm_i2c_write(dev, reg, , 1);
+}
+
+static inline int ksz_pwrite8(struct udevice *dev, int port, int reg, u8 val)
+{
+ return ksz_write8(dev, PORT_CTRL_ADDR(port, reg), val);
+}
+
+static inline int ksz_write16(struct udevice *dev, u32 reg, u16 val)
+{
+ u8 buf[2];
+
+ buf[1] = val & 0xff;
+ buf[0] = val >> 8;
+ dev_dbg(dev, "%s 0x%04x>>0x%04x\n", __func__, reg, val);
+
+ return dm_i2c_write(dev, reg, buf, 2);
+}
+
+static inline int ksz_pwrite16(struct udevice *dev, int port, int reg, u16
[PATCH 6/9] net: dsa: enable master promisc mode if available and needed
If ports have their own unique MAC addrs and master has a set_promisc
function, call it so that packets will be received for ports.
Signed-off-by: Tim Harvey
---
net/dsa-uclass.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 7ea1cb6949..694664d81b 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -277,8 +277,15 @@ static int dsa_port_probe(struct udevice *pdev)
* has a unique MAC address specified in the environment.
*/
eth_env_get_enetaddr_by_index("eth", dev_seq(pdev), env_enetaddr);
- if (!is_zero_ethaddr(env_enetaddr))
+ if (!is_zero_ethaddr(env_enetaddr)) {
+ /* individual port mac addrs require master to be promisc */
+ struct eth_ops *eth_ops = eth_get_ops(master);
+
+ if (eth_ops->set_promisc)
+ eth_ops->set_promisc(master, 1);
+
return 0;
+ }
master_pdata = dev_get_plat(master);
eth_pdata = dev_get_plat(pdev);
--
2.17.1
[PATCH 5/9] net: fec: add set_promisc function
Enabling promiscuous mode is necessary if FEC is the master of a DSA
switch driver where each port has their own MAC address.
Signed-off-by: Tim Harvey
---
drivers/net/fec_mxc.c | 13 +
drivers/net/fec_mxc.h | 1 +
2 files changed, 14 insertions(+)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 77680491d0..db2cdaf684 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -458,6 +458,9 @@ static void fec_reg_setup(struct fec_priv *fec)
else if (fec->xcv_type == RMII)
rcntrl |= FEC_RCNTRL_RMII;
+ if (fec->promisc)
+ rcntrl |= 0x8;
+
writel(rcntrl, >eth->r_cntrl);
}
@@ -1278,6 +1281,15 @@ static int fecmxc_read_rom_hwaddr(struct udevice *dev)
return fec_get_hwaddr(priv->dev_id, pdata->enetaddr);
}
+static int fecmxc_set_promisc(struct udevice *dev, bool enable)
+{
+ struct fec_priv *priv = dev_get_priv(dev);
+
+ priv->promisc = enable;
+
+ return 0;
+}
+
static int fecmxc_free_pkt(struct udevice *dev, uchar *packet, int length)
{
if (packet)
@@ -1294,6 +1306,7 @@ static const struct eth_ops fecmxc_ops = {
.stop = fecmxc_halt,
.write_hwaddr = fecmxc_set_hwaddr,
.read_rom_hwaddr= fecmxc_read_rom_hwaddr,
+ .set_promisc= fecmxc_set_promisc,
};
static int device_get_phy_addr(struct fec_priv *priv, struct udevice *dev)
diff --git a/drivers/net/fec_mxc.h b/drivers/net/fec_mxc.h
index 5ccde9193b..62b55ef395 100644
--- a/drivers/net/fec_mxc.h
+++ b/drivers/net/fec_mxc.h
@@ -272,6 +272,7 @@ struct fec_priv {
struct clk clk_ref;
struct clk clk_ptp;
u32 clk_rate;
+ char promisc;
};
/**
--
2.17.1
[PATCH 4/9] net: add set_promisc function to enable/disable Promiscuous mode
Enabling promiscuous mode can be useful for DSA switches where each port
has its own MAC address.
Signed-off-by: Tim Harvey
---
include/net.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net.h b/include/net.h
index b95d6a6f60..cec8c98618 100644
--- a/include/net.h
+++ b/include/net.h
@@ -158,6 +158,7 @@ enum eth_recv_flags {
* ROM on the board. This is how the driver should expose it
* to the network stack. This function should fill in the
* eth_pdata::enetaddr field - optional
+ * set_promisc: Enable or Disable promiscuous mode
*/
struct eth_ops {
int (*start)(struct udevice *dev);
@@ -168,6 +169,7 @@ struct eth_ops {
int (*mcast)(struct udevice *dev, const u8 *enetaddr, int join);
int (*write_hwaddr)(struct udevice *dev);
int (*read_rom_hwaddr)(struct udevice *dev);
+ int (*set_promisc)(struct udevice *dev, bool enable);
};
#define eth_get_ops(dev) ((struct eth_ops *)(dev)->driver->ops)
--
2.17.1
[PATCH 3/9] net: fec: set phy_of_node properly for fixed-link phy
If the FEC is connected to a fixed-link (upstream switch port for
example) the phy_of_node should be set to the fixed-link node
so that speed and other properties can be found properly.
In addition fix a typo in the debug string.
Signed-off-by: Tim Harvey
---
drivers/net/fec_mxc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3abf914833..77680491d0 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1304,7 +1304,11 @@ static int device_get_phy_addr(struct fec_priv *priv,
struct udevice *dev)
ret = dev_read_phandle_with_args(dev, "phy-handle", NULL, 0, 0,
_args);
if (ret) {
- debug("Failed to find phy-handle (err = %d\n)", ret);
+ priv->phy_of_node = ofnode_find_subnode(dev_ofnode(dev),
+ "fixed-link");
+ if (ofnode_valid(priv->phy_of_node))
+ return 0;
+ debug("Failed to find phy-handle (err = %d)\n", ret);
return ret;
}
--
2.17.1
[PATCH 2/9] net: fec: use device sequence vs index when fetching fec
When using uclass_get_device* to get the FEC device we need to use
device sequence instead of index into UCLASS_ETH. In systems where for
example a I2C based DSA switch exists it will probe before the FEC
master and its ports will be registered first and have the first
indexes yet the FEC's sequence comes from the device-tree alias.
Take for example the imx8mm-venice-gw7901 board which has an i2c based
DSA switch:
u-boot=> net list
eth1 : lan1 00:0d:8d:aa:00:2f
eth2 : lan2 00:0d:8d:aa:00:30
eth3 : lan3 00:0d:8d:aa:00:31
eth4 : lan4 00:0d:8d:aa:00:32
eth0 : ethernet@30be 00:0d:8d:aa:00:2e active
Thus in this case uclass_get_device(UCLASS_ETH, 0, ) returns lan1
which is wrong but uclass_get_device_seq(UCLASS_ETH, 0, ) returns
ethernet@30be000 which is correct.
Signed-off-by: Tim Harvey
---
drivers/net/fec_mxc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 4fd5c01b4a..3abf914833 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -146,7 +146,7 @@ static int fec_get_clk_rate(void *udev, int idx)
CONFIG_IS_ENABLED(CLK_CCF)) {
dev = udev;
if (!dev) {
- ret = uclass_get_device(UCLASS_ETH, idx, );
+ ret = uclass_get_device_by_seq(UCLASS_ETH, idx, );
if (ret < 0) {
debug("Can't get FEC udev: %d\n", ret);
return ret;
--
2.17.1
[PATCH 1/9] board: gateworks: venice: add imx8mm-gw7901 support
The Gateworks GW7901 is an ARM based single board computer (SBC)
featuring:
- i.MX8M Mini SoC
- LPDDR4 DRAM
- eMMC FLASH
- SPI FRAM
- Gateworks System Controller (GSC)
- Atmel ATECC Crypto Authentication
- USB 2.0
- Microchip GbE Switch
- Multiple multi-protocol RS232/RS485/RS422 Serial ports
- onboard 802.11ac WiFi / BT
- microSD socket
- miniPCIe socket with PCIe, USB 2.0 and dual SIM sockets
- Wide range DC power input
- 802.3at PoE
To add support for this board:
- add dts from Linux (accepted for v5.14)
- add SPL PMIC config
Signed-off-by: Tim Harvey
---
arch/arm/dts/Makefile |1 +
arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi | 118 ++
arch/arm/dts/imx8mm-venice-gw7901.dts | 1020 +
board/gateworks/venice/spl.c | 55 +-
configs/imx8mm_venice_defconfig |2 +-
5 files changed, 1194 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
create mode 100644 arch/arm/dts/imx8mm-venice-gw7901.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9fb38682e6..b390d6bf1a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -861,6 +861,7 @@ dtb-$(CONFIG_ARCH_IMX8M) += \
imx8mm-venice-gw71xx-0x.dtb \
imx8mm-venice-gw72xx-0x.dtb \
imx8mm-venice-gw73xx-0x.dtb \
+ imx8mm-venice-gw7901.dtb \
imx8mm-verdin.dtb \
phycore-imx8mm.dtb \
imx8mn-ddr4-evk.dtb \
diff --git a/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
b/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
new file mode 100644
index 00..3b24ca638a
--- /dev/null
+++ b/arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi
@@ -0,0 +1,118 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+&{/soc@0} {
+ u-boot,dm-pre-reloc;
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+ /delete-property/ assigned-clocks;
+ /delete-property/ assigned-clock-parents;
+ /delete-property/ assigned-clock-rates;
+};
+
+_24m {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-spl;
+ u-boot,dm-pre-reloc;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_uart2 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_usdhc2 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_usdhc3 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_i2c1 {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_i2c2 {
+ u-boot,dm-spl;
+};
+
+ {
+ phy-reset-gpios = < 19 GPIO_ACTIVE_LOW>;
+ phy-reset-duration = <1>;
+ phy-reset-post-delay = <1>;
+};
+
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b} {
+ u-boot,dm-spl;
+};
+
+&{/soc@0/bus@3080/i2c@30a3/pmic@4b/regulators} {
+ u-boot,dm-spl;
+};
+
+_pmic {
+ u-boot,dm-spl;
+};
+
diff --git a/arch/arm/dts/imx8mm-venice-gw7901.dts
b/arch/arm/dts/imx8mm-venice-gw7901.dts
new file mode 100644
index 00..0216facb2a
--- /dev/null
+++ b/arch/arm/dts/imx8mm-venice-gw7901.dts
@@ -0,0 +1,1020 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2020 Gateworks Corporation
+ */
+
+/dts-v1/;
+
+#include
+#include
+#include
+
+#include "imx8mm.dtsi"
+
+/ {
+ model = "Gateworks Venice GW7901 i.MX8MM board";
+ compatible = "gw,imx8mm-gw7901", "fsl,imx8mm";
+
+ aliases {
+ ethernet0 =
+ ethernet1 =
+ ethernet2 =
+ ethernet3 =
+ ethernet4 =
+ usb0 =
+ usb1 =
+ };
+
+ chosen {
+ stdout-path =
+ };
+
+ memory@4000 {
+ device_type = "memory";
+ reg = <0x0 0x4000 0 0x8000>;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ user-pb {
+ label = "user_pb";
+ gpios = < 2 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ user-pb1x {
+ label = "user_pb1x";
+ linux,code = ;
+ interrupt-parent = <>;
+ interrupts = <0>;
+ };
+
+ key-erased {
+ label = "key_erased";
+ linux,code = ;
+ interrupt-parent = <>;
+ interrupts = <1>;
+ };
+
+ eeprom-wp {
+ label = "eeprom_wp";
+ linux,code = ;
+ interrupt-parent = <>;
+
[PATCH 0/9] Add support for imx8mm-venice-gw7901 and DSA switch
The GW7901 is an IMX8M Mini based board with a KSZ9897 switch hanging off the IMX8M FEC. In order to support a fixed-link connection to a U-Boot DSA switch some changes need to be made to the FEC driver. Additionally, in order to support per-port unique MAC addrs for DSA we must introduce a mechanism to put the master device in promiscuous mode. All patches are here including adding the dts for the board as well as a dsa driver and necessary patches to fec/dsa so that it is clear how this fits together. Tim Harvey (9): board: gateworks: venice: add imx8mm-gw7901 support net: fec: use device sequence vs index when fetching fec net: fec: set phy_of_node properly for fixed-link phy net: add set_promisc function to enable/disable Promiscuous mode net: fec: add set_promisc function net: dsa: enable master promisc mode if available and needed net: add support for KSZ9477/KSZ9897/KSZ9567 GbE switch arm: dts: imx8mm-venice-gw7901.dts: fix dsa switch configuration configs: imx8mm_venice_defconfig: add support for gbe switch arch/arm/dts/Makefile |1 + arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi | 118 ++ arch/arm/dts/imx8mm-venice-gw7901.dts | 1055 + board/gateworks/venice/spl.c | 55 +- configs/imx8mm_venice_defconfig |6 +- drivers/net/Kconfig |7 + drivers/net/Makefile |1 + drivers/net/fec_mxc.c | 21 +- drivers/net/fec_mxc.h |1 + drivers/net/ksz9477.c | 547 + include/net.h |2 + net/dsa-uclass.c |9 +- 12 files changed, 1818 insertions(+), 5 deletions(-) create mode 100644 arch/arm/dts/imx8mm-venice-gw7901-u-boot.dtsi create mode 100644 arch/arm/dts/imx8mm-venice-gw7901.dts create mode 100644 drivers/net/ksz9477.c -- 2.17.1
Re: [PATCH 1/2] spl: mmc: Factor out eMMC boot partition selection code
Hi Marek,
On 7/1/21 8:08 AM, Marek Vasut wrote:
> Factor out eMMC boot partition selection code into
> default_spl_mmc_emmc_boot_partition() function and implement
> weak spl_mmc_emmc_boot_partition(), so that architecture or
> board code can override the eMMC boot partition selection.
>
> Signed-off-by: Marek Vasut
> Cc: Faiz Abbas
> Cc: Harald Seiler
> Cc: Lokesh Vutla
> Cc: Simon Glass
> Cc: Fabio Estevam
> Cc: Peng Fan
> Cc: Stefano Babic
> Cc: Ye Li
> ---
> common/spl/spl_mmc.c | 37 -
> include/spl.h| 25 +
> 2 files changed, 49 insertions(+), 13 deletions(-)
>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index add2785b4e3..2377d0937d1 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -324,6 +324,29 @@ unsigned long __weak spl_mmc_get_uboot_raw_sector(struct
> mmc *mmc,
> return raw_sect;
> }
>
> +int default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
> +{
> + int part;
> +#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
> + part = CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION;
> +#else
> + /*
> + * We need to check what the partition is configured to.
> + * 1 and 2 match up to boot0 / boot1 and 7 is user data
> + * which is the first physical partition (0).
> + */
> + part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
> + if (part == 7)
> + part = 0;
> +#endif
> + return part;
> +}
> +
> +int __weak spl_mmc_emmc_boot_partition(struct mmc *mmc)
> +{
> + return default_spl_mmc_emmc_boot_partition(mmc);
> +}
> +
> int spl_mmc_load(struct spl_image_info *spl_image,
>struct spl_boot_device *bootdev,
>const char *filename,
> @@ -355,19 +378,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
> err = -EINVAL;
> switch (boot_mode) {
> case MMCSD_MODE_EMMCBOOT:
> -#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
> - part = CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION;
> -#else
> - /*
> - * We need to check what the partition is configured to.
> - * 1 and 2 match up to boot0 / boot1 and 7 is user data
> - * which is the first physical partition (0).
> - */
> - part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
> -
> - if (part == 7)
> - part = 0;
> -#endif
> + part = spl_mmc_emmc_boot_partition(mmc);
>
> if (CONFIG_IS_ENABLED(MMC_TINY))
> err = mmc_switch_part(mmc, part);
> diff --git a/include/spl.h b/include/spl.h
> index cee9a42ddb5..b6698a686a7 100644
> --- a/include/spl.h
> +++ b/include/spl.h
> @@ -357,6 +357,31 @@ u32 spl_mmc_boot_mode(const u32 boot_device);
> * If not overridden, it is weakly defined in common/spl/spl_mmc.c.
> */
> int spl_mmc_boot_partition(const u32 boot_device);
> +
> +struct mmc;
> +/**
> + * default_spl_mmc_emmc_boot_partition() - eMMC boot partition to load
> U-Boot from.
> + * @boot_device: ID of the device which the MMC driver wants to load
> + * U-Boot from.
Is "@boot_device" right? Argument is mmc.
> + *
> + * This function should return the eMMC boot partition number which
> + * the SPL should load U-Boot from (on the given boot_device).
> + */
> +int default_spl_mmc_emmc_boot_partition(struct mmc *mmc);
> +
> +/**
> + * spl_mmc_emmc_boot_partition() - eMMC boot partition to load U-Boot from.
> + * @boot_device: ID of the device which the MMC driver wants to load
> + * U-Boot from.
Ditto.
Best Regards,
Jaehoon Chung
> + *
> + * This function should return the eMMC boot partition number which
> + * the SPL should load U-Boot from (on the given boot_device).
> + *
> + * If not overridden, it is weakly defined in common/spl/spl_mmc.c
> + * and calls default_spl_mmc_emmc_boot_partition();
> + */
> +int spl_mmc_emmc_boot_partition(struct mmc *mmc);
> +
> void spl_set_bd(void);
>
> /**
>
[PATCH 2/2] ARM: imx: Pick correct eMMC boot partition from ROM log
In case the iMX8M boot from eMMC boot partition and the primary image
is corrupted, the BootROM is capable of starting a secondary image in
the other eMMC boot partition as a fallback.
However, the BootROM leaves the eMMC BOOT_PARTITION_ENABLE setting as
it was, i.e. pointing to the boot partition containing the corrupted
image, and the BootROM does not provide any indication that this sort
of fallback occured.
According to AN12853 i.MX ROMs Log Events, Rev. 0, May 2020, it is
possible to determine whether fallback event occurred by parsing the
ROM event log. In case ROM event ID 0x51 is present, fallback event
did occur.
This patch implements ROM event log parsing and search for event ID
0x51 for all iMX8M SoCs, and based on that corrects the eMMC boot
partition selection. This way, the SPL loads the remaining boot
components from the same eMMC boot partition from which it was
started, even in case of the fallback.
Signed-off-by: Marek Vasut
Cc: Faiz Abbas
Cc: Harald Seiler
Cc: Lokesh Vutla
Cc: Simon Glass
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
Cc: Ye Li
---
arch/arm/mach-imx/imx8m/soc.c | 61 +++
1 file changed, 61 insertions(+)
diff --git a/arch/arm/mach-imx/imx8m/soc.c b/arch/arm/mach-imx/imx8m/soc.c
index 0c44022a6dc..92a71b6ba29 100644
--- a/arch/arm/mach-imx/imx8m/soc.c
+++ b/arch/arm/mach-imx/imx8m/soc.c
@@ -571,6 +571,67 @@ enum boot_device get_boot_device(void)
}
#endif
+#if defined(CONFIG_IMX8M)
+#include
+int spl_mmc_emmc_boot_partition(struct mmc *mmc)
+{
+ u32 *rom_log_addr = (u32 *)0x9e0;
+ u32 *rom_log;
+ u8 event_id;
+ int i, part;
+
+ part = default_spl_mmc_emmc_boot_partition(mmc);
+
+ /* If the ROM event log pointer is not valid. */
+ if (*rom_log_addr < 0x90 || *rom_log_addr >= 0xb0 ||
+ *rom_log_addr & 0x3)
+ return part;
+
+ /* Parse the ROM event ID version 2 log */
+ rom_log = (u32 *)(uintptr_t)(*rom_log_addr);
+ for (i = 0; i < 128; i++) {
+ event_id = rom_log[i] >> 24;
+ switch (event_id) {
+ case 0x00: /* End of list */
+ break;
+ /* Log entries with 1 parameter, skip 1 */
+ case 0x80: /* Start to perform the device initialization */
+ case 0x81: /* The boot device initialization completes */
+ case 0x8f: /* The boot device initialization fails */
+ case 0x90: /* Start to read data from boot device */
+ case 0x91: /* Reading data from boot device completes */
+ case 0x9f: /* Reading data from boot device fails */
+ i += 1;
+ continue;
+ /* Log entries with 2 parameters, skip 2 */
+ case 0xa0: /* Image authentication result */
+ case 0xc0: /* Jump to the boot image soon */
+ i += 2;
+ continue;
+ /* Boot from the secondary boot image */
+ case 0x51:
+ /*
+* Swap the eMMC boot partitions in case there was a
+* fallback event (i.e. primary image was corrupted
+* and that corruption was recognized by the BootROM),
+* so the SPL loads the rest of the U-Boot from the
+* correct eMMC boot partition, since the BootROM
+* leaves the boot partition set to the corrupted one.
+*/
+ if (part == 1)
+ part = 2;
+ else if (part == 2)
+ part = 1;
+ continue;
+ default:
+ continue;
+ }
+ }
+
+ return part;
+}
+#endif
+
bool is_usb_boot(void)
{
return get_boot_device() == USB_BOOT;
--
2.30.2
[PATCH 1/2] spl: mmc: Factor out eMMC boot partition selection code
Factor out eMMC boot partition selection code into
default_spl_mmc_emmc_boot_partition() function and implement
weak spl_mmc_emmc_boot_partition(), so that architecture or
board code can override the eMMC boot partition selection.
Signed-off-by: Marek Vasut
Cc: Faiz Abbas
Cc: Harald Seiler
Cc: Lokesh Vutla
Cc: Simon Glass
Cc: Fabio Estevam
Cc: Peng Fan
Cc: Stefano Babic
Cc: Ye Li
---
common/spl/spl_mmc.c | 37 -
include/spl.h| 25 +
2 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index add2785b4e3..2377d0937d1 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -324,6 +324,29 @@ unsigned long __weak spl_mmc_get_uboot_raw_sector(struct
mmc *mmc,
return raw_sect;
}
+int default_spl_mmc_emmc_boot_partition(struct mmc *mmc)
+{
+ int part;
+#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
+ part = CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION;
+#else
+ /*
+* We need to check what the partition is configured to.
+* 1 and 2 match up to boot0 / boot1 and 7 is user data
+* which is the first physical partition (0).
+*/
+ part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
+ if (part == 7)
+ part = 0;
+#endif
+ return part;
+}
+
+int __weak spl_mmc_emmc_boot_partition(struct mmc *mmc)
+{
+ return default_spl_mmc_emmc_boot_partition(mmc);
+}
+
int spl_mmc_load(struct spl_image_info *spl_image,
struct spl_boot_device *bootdev,
const char *filename,
@@ -355,19 +378,7 @@ int spl_mmc_load(struct spl_image_info *spl_image,
err = -EINVAL;
switch (boot_mode) {
case MMCSD_MODE_EMMCBOOT:
-#ifdef CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION
- part = CONFIG_SYS_MMCSD_RAW_MODE_EMMC_BOOT_PARTITION;
-#else
- /*
-* We need to check what the partition is configured to.
-* 1 and 2 match up to boot0 / boot1 and 7 is user data
-* which is the first physical partition (0).
-*/
- part = (mmc->part_config >> 3) & PART_ACCESS_MASK;
-
- if (part == 7)
- part = 0;
-#endif
+ part = spl_mmc_emmc_boot_partition(mmc);
if (CONFIG_IS_ENABLED(MMC_TINY))
err = mmc_switch_part(mmc, part);
diff --git a/include/spl.h b/include/spl.h
index cee9a42ddb5..b6698a686a7 100644
--- a/include/spl.h
+++ b/include/spl.h
@@ -357,6 +357,31 @@ u32 spl_mmc_boot_mode(const u32 boot_device);
* If not overridden, it is weakly defined in common/spl/spl_mmc.c.
*/
int spl_mmc_boot_partition(const u32 boot_device);
+
+struct mmc;
+/**
+ * default_spl_mmc_emmc_boot_partition() - eMMC boot partition to load U-Boot
from.
+ * @boot_device: ID of the device which the MMC driver wants to load
+ * U-Boot from.
+ *
+ * This function should return the eMMC boot partition number which
+ * the SPL should load U-Boot from (on the given boot_device).
+ */
+int default_spl_mmc_emmc_boot_partition(struct mmc *mmc);
+
+/**
+ * spl_mmc_emmc_boot_partition() - eMMC boot partition to load U-Boot from.
+ * @boot_device: ID of the device which the MMC driver wants to load
+ * U-Boot from.
+ *
+ * This function should return the eMMC boot partition number which
+ * the SPL should load U-Boot from (on the given boot_device).
+ *
+ * If not overridden, it is weakly defined in common/spl/spl_mmc.c
+ * and calls default_spl_mmc_emmc_boot_partition();
+ */
+int spl_mmc_emmc_boot_partition(struct mmc *mmc);
+
void spl_set_bd(void);
/**
--
2.30.2
Re: [PATCH] board: ti: j721e: README: Add documentation for eMMC boot
On Wed, Jun 30, 2021 at 11:34:29AM +0530, Aswath Govindraju wrote: > Add instructions for flashing eMMC with bootloader images from SD. > > Signed-off-by: Aswath Govindraju > --- > board/ti/j721e/README | 59 +++ > 1 file changed, 59 insertions(+) This really needs to be converted to rST and moved under doc/board/ti/ thanks! -- Tom signature.asc Description: PGP signature
[PATCH v3 3/3] test/py: rewrite sqfsls command test suite
Add more details to test cases by comparing each expected line with the
command's output. Add new test cases:
- sqfsls at an empty directory
- sqfsls at a sub-directory
Signed-off-by: Joao Marcos Costa
---
.../test_fs/test_squashfs/test_sqfs_ls.py | 140 +++---
1 file changed, 121 insertions(+), 19 deletions(-)
diff --git a/test/py/tests/test_fs/test_squashfs/test_sqfs_ls.py
b/test/py/tests/test_fs/test_squashfs/test_sqfs_ls.py
index a0dca2e2fc..9eb00d6888 100644
--- a/test/py/tests/test_fs/test_squashfs/test_sqfs_ls.py
+++ b/test/py/tests/test_fs/test_squashfs/test_sqfs_ls.py
@@ -4,7 +4,101 @@
import os
import pytest
-from sqfs_common import *
+
+from sqfs_common import STANDARD_TABLE
+from sqfs_common import generate_sqfs_src_dir, make_all_images
+from sqfs_common import clean_sqfs_src_dir, clean_all_images
+from sqfs_common import check_mksquashfs_version
+
+def sqfs_ls_at_root(u_boot_console):
+""" Runs sqfsls at image's root.
+
+This test checks if all the present files and directories were listed.
Also,
+it checks if passing the slash or not changes the output, which it
shouldn't.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+
+no_slash = u_boot_console.run_command('sqfsls host 0')
+slash = u_boot_console.run_command('sqfsls host 0 /')
+assert no_slash == slash
+
+expected_lines = ['empty-dir/', '1000 f1000', '4096 f4096', '5096
f5096',
+ 'subdir/', ' sym', '4 file(s), 2 dir(s)']
+
+output = u_boot_console.run_command('sqfsls host 0')
+for line in expected_lines:
+assert line in output
+
+def sqfs_ls_at_empty_dir(u_boot_console):
+""" Runs sqfsls at an empty directory.
+
+This tests checks if sqfsls will print anything other than the 'Empty
directory'
+message.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+assert u_boot_console.run_command('sqfsls host 0 empty-dir') == 'Empty
directory.'
+
+def sqfs_ls_at_subdir(u_boot_console):
+""" Runs sqfsls at the SquashFS image's subdir.
+
+This test checks if the path resolution works, since the directory is not
the
+root.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+expected_lines = ['100 subdir-file', '1 file(s), 0 dir(s)']
+output = u_boot_console.run_command('sqfsls host 0 subdir')
+for line in expected_lines:
+assert line in output
+
+def sqfs_ls_at_symlink(u_boot_console):
+""" Runs sqfsls at a SquashFS image's symbolic link.
+
+This test checks if the symbolic link's target resolution works.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+# since sym -> subdir, the following outputs must be equal
+output = u_boot_console.run_command('sqfsls host 0 sym')
+output_subdir = u_boot_console.run_command('sqfsls host 0 subdir')
+assert output == output_subdir
+
+expected_lines = ['100 subdir-file', '1 file(s), 0 dir(s)']
+for line in expected_lines:
+assert line in output
+
+def sqfs_ls_at_non_existent_dir(u_boot_console):
+""" Runs sqfsls at a file and at a non-existent directory.
+
+This test checks if the SquashFS support won't crash if it doesn't find the
+specified directory or if it takes a file as an input instead of an actual
+directory. In both cases, the output should be the same.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+out_non_existent = u_boot_console.run_command('sqfsls host 0 fff')
+out_not_dir = u_boot_console.run_command('sqfsls host 0 f1000')
+assert out_non_existent == out_not_dir
+assert '** Cannot find directory. **' in out_non_existent
+
+def sqfs_run_all_ls_tests(u_boot_console):
+""" Runs all the previously defined test cases.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+sqfs_ls_at_root(u_boot_console)
+sqfs_ls_at_empty_dir(u_boot_console)
+sqfs_ls_at_subdir(u_boot_console)
+sqfs_ls_at_symlink(u_boot_console)
+sqfs_ls_at_non_existent_dir(u_boot_console)
@pytest.mark.boardspec('sandbox')
@pytest.mark.buildconfigspec('cmd_fs_generic')
@@ -12,25 +106,33 @@ from sqfs_common import *
@pytest.mark.buildconfigspec('fs_squashfs')
@pytest.mark.requiredtool('mksquashfs')
def test_sqfs_ls(u_boot_console):
+""" Executes the sqfsls test suite.
+
+First, it generates the SquashFS images, then it runs the test cases and
+finally cleans the workspace. If an exception is raised, the workspace is
+cleaned before exiting.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
build_dir = u_boot_console.config.build_dir
-for opt in comp_opts:
-try:
-opt.gen_image(build_dir)
-
[PATCH v3 2/3] test/py: rewrite sqfsload command test suite
The previous strategy to know if a file was correctly loaded was to
check for how many bytes were read and compare it against the file's
original size. Since this is not a good solution, replace it by
comparing the checksum of the loaded bytes against the original file's
checksum. Add more test cases: files at a sub-directory and non-existent
file.
Signed-off-by: Joao Marcos Costa
---
.../test_fs/test_squashfs/test_sqfs_load.py | 168 ++
1 file changed, 138 insertions(+), 30 deletions(-)
diff --git a/test/py/tests/test_fs/test_squashfs/test_sqfs_load.py
b/test/py/tests/test_fs/test_squashfs/test_sqfs_load.py
index 9e90062384..6ec6ccec6c 100644
--- a/test/py/tests/test_fs/test_squashfs/test_sqfs_load.py
+++ b/test/py/tests/test_fs/test_squashfs/test_sqfs_load.py
@@ -3,8 +3,118 @@
# Author: Joao Marcos Costa
import os
+import subprocess
import pytest
-from sqfs_common import *
+
+from sqfs_common import SQFS_SRC_DIR, STANDARD_TABLE
+from sqfs_common import generate_sqfs_src_dir, make_all_images
+from sqfs_common import clean_sqfs_src_dir, clean_all_images
+from sqfs_common import check_mksquashfs_version
+
+@pytest.mark.requiredtool('md5sum')
+def original_md5sum(path):
+""" Runs md5sum command.
+
+Args:
+path: path to original file.
+Returns:
+The original file's checksum as a string.
+"""
+
+out = subprocess.run(['md5sum ' + path], shell=True, check=True,
+ capture_output=True, text=True)
+checksum = out.stdout.split()[0]
+
+return checksum
+
+def uboot_md5sum(u_boot_console, address, count):
+""" Runs U-Boot's md5sum command.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+address: address where the file was loaded (e.g.: $kernel_addr_r).
+count: file's size. It was named 'count' to match md5sum's respective
+argument name.
+Returns:
+The checksum of the file loaded with sqfsload as a string.
+"""
+
+out = u_boot_console.run_command('md5sum {} {}'.format(address, count))
+checksum = out.split()[-1]
+
+return checksum
+
+def sqfs_load_files(u_boot_console, files, sizes, address):
+""" Loads files and asserts their checksums.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+files: list of files to be loaded.
+sizes: the sizes of each file.
+address: the address where the files should be loaded.
+"""
+build_dir = u_boot_console.config.build_dir
+for (file, size) in zip(files, sizes):
+out = u_boot_console.run_command('sqfsload host 0 {}
{}'.format(address, file))
+
+# check if the right amount of bytes was read
+assert size in out
+
+# compare original file's checksum against u-boot's
+u_boot_checksum = uboot_md5sum(u_boot_console, address, hex(int(size)))
+original_file_path = os.path.join(build_dir, SQFS_SRC_DIR + '/' + file)
+original_checksum = original_md5sum(original_file_path)
+assert u_boot_checksum == original_checksum
+
+def sqfs_load_files_at_root(u_boot_console):
+""" Calls sqfs_load_files passing the files at the SquashFS image's root.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+
+files = ['f4096', 'f5096', 'f1000']
+sizes = ['4096', '5096', '1000']
+address = '$kernel_addr_r'
+sqfs_load_files(u_boot_console, files, sizes, address)
+
+def sqfs_load_files_at_subdir(u_boot_console):
+""" Calls sqfs_load_files passing the files at the SquashFS image's subdir.
+
+This test checks if the path resolution works, since the file is not at the
+root directory.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+files = ['subdir/subdir-file']
+sizes = ['100']
+address = '$kernel_addr_r'
+sqfs_load_files(u_boot_console, files, sizes, address)
+
+def sqfs_load_non_existent_file(u_boot_console):
+""" Calls sqfs_load_files passing an non-existent file to raise an error.
+
+This test checks if the SquashFS support won't crash if it doesn't find the
+specified file.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+address = '$kernel_addr_r'
+file = 'non-existent'
+out = u_boot_console.run_command('sqfsload host 0 {} {}'.format(address,
file))
+assert 'Failed to load' in out
+
+def sqfs_run_all_load_tests(u_boot_console):
+""" Runs all the previously defined test cases.
+
+Args:
+u_boot_console: provides the means to interact with U-Boot's console.
+"""
+sqfs_load_files_at_root(u_boot_console)
+sqfs_load_files_at_subdir(u_boot_console)
+sqfs_load_non_existent_file(u_boot_console)
@pytest.mark.boardspec('sandbox')
@pytest.mark.buildconfigspec('cmd_fs_generic')
@@ -12,35 +122,33 @@ from sqfs_common import
[PATCH v3 1/3] test/py: rewrite common tools for SquashFS tests
Remove the previous OOP approach, which was confusing and incomplete.
Add more test cases by making SquashFS images with various options,
concerning file fragmentation and its compression. Add comments to
properly document the code.
Signed-off-by: Joao Marcos Costa
---
.../test_fs/test_squashfs/sqfs_common.py | 257 +-
1 file changed, 193 insertions(+), 64 deletions(-)
diff --git a/test/py/tests/test_fs/test_squashfs/sqfs_common.py
b/test/py/tests/test_fs/test_squashfs/sqfs_common.py
index c96f92c1d8..267c4b57d1 100644
--- a/test/py/tests/test_fs/test_squashfs/sqfs_common.py
+++ b/test/py/tests/test_fs/test_squashfs/sqfs_common.py
@@ -3,74 +3,203 @@
# Author: Joao Marcos Costa
import os
-import random
-import string
+import shutil
import subprocess
-def sqfs_get_random_letters(size):
-letters = []
-for i in range(0, size):
-letters.append(random.choice(string.ascii_letters))
+""" standard test images table: Each table item is a key:value pair
+representing the output image name and its respective mksquashfs options.
+This table should be modified only when adding support for new compression
+algorithms. The 'default' case takes no options but the input and output
+names, so it must be assigned with an empty string.
+"""
+STANDARD_TABLE = {
+'default' : '',
+'lzo_comp_frag' : '',
+'lzo_frag' : '',
+'lzo_no_frag' : '',
+'zstd_comp_frag' : '',
+'zstd_frag' : '',
+'zstd_no_frag' : '',
+'gzip_comp_frag' : '',
+'gzip_frag' : '',
+'gzip_no_frag' : ''
+}
-return ''.join(letters)
+""" EXTRA_TABLE: Set this table's keys and values if you want to make squashfs
+images with your own customized options.
+"""
+EXTRA_TABLE = {}
-def sqfs_generate_file(path, size):
-content = sqfs_get_random_letters(size)
-file = open(path, "w")
+# path to source directory used to make squashfs test images
+SQFS_SRC_DIR = 'sqfs_src_dir'
+
+def get_opts_list():
+""" Combines fragmentation and compression options into a list of strings.
+
+opts_list's firts item is an empty string as STANDARD_TABLE's first item is
+the 'default' case.
+
+Returns:
+A list of strings whose items are formed by a compression and a
+fragmentation option joined by a whitespace.
+"""
+# supported compression options only
+comp_opts = ['-comp lzo', '-comp zstd', '-comp gzip']
+# file fragmentation options
+frag_opts = ['-always-use-fragments', '-always-use-fragments -noF',
'-no-fragments']
+
+opts_list = [' ']
+for comp_opt in comp_opts:
+for frag_opt in frag_opts:
+opts_list.append(' '.join([comp_opt, frag_opt]))
+
+return opts_list
+
+def init_standard_table():
+""" Initializes STANDARD_TABLE values.
+
+STANDARD_TABLE's keys are pre-defined, and init_standard_table() assigns
+the right value for each one of them.
+"""
+opts_list = get_opts_list()
+
+for key, value in zip(STANDARD_TABLE.keys(), opts_list):
+STANDARD_TABLE[key] = value
+
+def generate_file(file_name, file_size):
+""" Generates a file filled with 'x'.
+
+Args:
+file_name: the file's name.
+file_size: the content's length and therefore the file size.
+"""
+content = 'x' * file_size
+
+file = open(file_name, 'w')
file.write(content)
file.close()
-class Compression:
-def __init__(self, name, files, sizes, block_size = 4096):
-self.name = name
-self.files = files
-self.sizes = sizes
-self.mksquashfs_opts = " -b " + str(block_size) + " -comp " + self.name
-
-def add_opt(self, opt):
-self.mksquashfs_opts += " " + opt
-
-def gen_image(self, build_dir):
-src = os.path.join(build_dir, "sqfs_src/")
-os.mkdir(src)
-for (f, s) in zip(self.files, self.sizes):
-sqfs_generate_file(src + f, s)
-
-# the symbolic link always targets the first file
-os.symlink(self.files[0], src + "sym")
-
-sqfs_img = os.path.join(build_dir, "sqfs-" + self.name)
-i_o = src + " " + sqfs_img
-opts = self.mksquashfs_opts
-try:
-subprocess.run(["mksquashfs " + i_o + opts], shell = True, check =
True)
-except:
-print("mksquashfs error. Compression type: " + self.name)
-raise RuntimeError
-
-def clean_source(self, build_dir):
-src = os.path.join(build_dir, "sqfs_src/")
-for f in self.files:
-os.remove(src + f)
-os.remove(src + "sym")
-os.rmdir(src)
-
-def cleanup(self, build_dir):
-self.clean_source(build_dir)
-sqfs_img = os.path.join(build_dir, "sqfs-" + self.name)
-os.remove(sqfs_img)
-
-files = ["blks_only", "blks_frag", "frag_only"]
-sizes = [4096, 5100, 100]
-gzip = Compression("gzip", files, sizes)
-zstd = Compression("zstd", files, sizes)
-lzo = Compression("lzo", files,
[PATCH v3 0/3] test/py: Rewrite SquashFS commands test suite
Hello, This patch series fixes the following issues: - poor strategy to check if files were properly loaded - wrong quoting style for strings - tests failing at the second run because of a wrong clean-up strategy Finally, it improves: - code overall documentation level, with more comments and better naming for functions and variables - code readability by adding more helper functions - completeness: more test cases were added for both sqfsls and sqfsload commands The sqfsload new test suite may fail when testing images with fragmented files if the patch I previously sent (fs/squashfs: fix reading of fragmented files) is not applied, so this patch series depends on it. Changes since V2: - Add check_mksquashfs_version function to raise an exception if mksquashfs version is too old. I chose to set the required version as 4.4, since it seems to be the most recent one. Changes since V1: - Leave the copyright year as it was (2020) instead of changing it to 2021 - Remove spurious comments and print statements - Fix the style issues pointed by pylint3 Best regards, Joao Joao Marcos Costa (3): test/py: rewrite common tools for SquashFS tests test/py: rewrite sqfsload command test suite test/py: rewrite sqfsls command test suite .../test_fs/test_squashfs/sqfs_common.py | 257 +- .../test_fs/test_squashfs/test_sqfs_load.py | 168 ++-- .../test_fs/test_squashfs/test_sqfs_ls.py | 140 -- 3 files changed, 452 insertions(+), 113 deletions(-) -- 2.25.1
Re: Pull request: u-boot-spi/next for next
On Wed, Jun 30, 2021 at 05:35:03PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR for next. > > Summary: > - Cypress s25hl-t/s25hs-t support (Takahiro Kuwano) > > CI: > https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/7979 > > thanks, > Jagan. > > The following changes since commit f6adec1af4b2f5d3012480c6cdce7743b74a6156: > > mtd: spi-nor-core: Allow using Micron mt35xu512aba in Octal DTR mode > (2021-06-28 12:06:57 +0530) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-spi next > > for you to fetch changes up to 5b8ec59e2a219185127fcaa640c2f5d5aba3acd6: > > mtd: spi-nor-tiny: Add fixups for Cypress s25hl-t/s25hs-t (2021-06-29 > 19:16:54 +0530) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v10 2/2] mmc: openpiton: add piton_mmc driver
On 6/30/21 8:10 PM, Tianrui Wei wrote:
> This commit adds support to piton_mmc driver for OpenPiton-riscv64
> This driver has many things set as preconfigured because the hardware
> automatically configures most of the settings during startup.
>
> Signed-off-by: Tianrui Wei
> Signed-off-by: Jonathan Balkind
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> drivers/mmc/Kconfig | 9 +++
> drivers/mmc/Makefile| 1 +
> drivers/mmc/piton_mmc.c | 161
> 3 files changed, 171 insertions(+)
> create mode 100644 drivers/mmc/piton_mmc.c
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 0909f502a1..d0176175e8 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -727,6 +727,15 @@ config MMC_SUNXI_HAS_MODE_SWITCH
> bool
> depends on MMC_SUNXI
>
> +config MMC_PITON
> + bool "MMC support for OpenPiton SoC"
> + depends on DM_MMC && BLK
> + help
> + This selects support for the SD host controller on OpenPiton SoC.
> + Note that this SD controller directly exposes the contents of the
> + SD card as memory mapped, so there is no manual configuration
> + required
> +
> config GENERIC_ATMEL_MCI
> bool "Atmel Multimedia Card Interface support"
> depends on DM_MMC && BLK && ARCH_AT91
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 89d6af3db3..d96ac90719 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_MMC_SDHCI_XENON) += xenon_sdhci.o
> obj-$(CONFIG_MMC_SDHCI_ZYNQ) += zynq_sdhci.o
>
> obj-$(CONFIG_MMC_SUNXI) += sunxi_mmc.o
> +obj-$(CONFIG_MMC_PITON) += piton_mmc.o
> obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o
> obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o
> obj-$(CONFIG_MMC_BCM2835)+= bcm2835_sdhost.o
> diff --git a/drivers/mmc/piton_mmc.c b/drivers/mmc/piton_mmc.c
> new file mode 100644
> index 00..9f5da6d633
> --- /dev/null
> +++ b/drivers/mmc/piton_mmc.c
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2009 SAMSUNG Electronics
> + * Minkyu Kang
> + * Jaehoon Chung
> + * Portions Copyright 2011-2019 NVIDIA Corporation
> + * Portions Copyright 2021 Tianrui Wei
> + * This file is adapted from tegra_mmc.c
> + * Tianrui Wei
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +
> +#define PITON_MMC_DUMMY_F_MAX 2000
> +#define PITON_MMC_DUMMY_F_MIN 1000
> +#define PITON_MMC_DUMMY_CAPACITY SZ_4G << 3
> +#define PITON_MMC_DUMMY_B_MAX SZ_4G
> +
> +struct piton_mmc_plat {
> + struct mmc_config cfg;
> + struct mmc mmc;
> +};
> +
> +struct piton_mmc_priv {
> + void __iomem *base_addr;
> +};
> +
> +static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
> + struct mmc_data *data)
> +{
> + if (!data)
> + return 0;
> +
> + struct piton_mmc_priv *priv = dev_get_priv(dev);
> + u32 *buff, *start_addr, *write_src;
> + size_t byte_cnt, start_block;
> +
> + buff = (u32 *)data->dest;
> + write_src = (u32 *)data->src;
> + start_block = cmd->cmdarg;
> + start_addr = priv->base_addr + start_block;
> +
> + /* if there is a read */
> + for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
> + byte_cnt -= sizeof(u32)) {
> + if (data->flags & MMC_DATA_READ) {
> + *buff++ = readl(start_addr++);
> + }
> + else if (data->flags & MMC_DATA_WRITE) {
> + writel(*write_src++,start_addr++);
> + }
> + }
> + return 0;
> +}
> +
> +static int piton_mmc_ofdata_to_platdata(struct udevice *dev)
> +{
> + struct piton_mmc_priv *priv = dev_get_priv(dev);
> + struct piton_mmc_plat *plat = dev_get_plat(dev);
> + struct mmc_config *cfg;
> + struct mmc *mmc;
> + struct blk_desc *bdesc;
> +
> + priv->base_addr = (void *)dev_read_addr(dev);
> + cfg = >cfg;
> + cfg->name = "PITON MMC";
> + cfg->host_caps = MMC_MODE_8BIT;
> + cfg->f_max = PITON_MMC_DUMMY_F_MAX;
> + cfg->f_min = PITON_MMC_DUMMY_F_MIN;
> + cfg->voltages = MMC_VDD_21_22;
> +
> + mmc = >mmc;
> + mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
> + mmc->capacity_user = PITON_MMC_DUMMY_CAPACITY;
> + mmc->capacity_user *= mmc->read_bl_len;
> + mmc->capacity_boot = 0;
> + mmc->capacity_rpmb = 0;
> + for (int i = 0; i < 4; i++)
> + mmc->capacity_gp[i] = 0;
> + mmc->capacity = PITON_MMC_DUMMY_CAPACITY;
> + mmc->has_init = 1;
> +
> + bdesc = mmc_get_blk_desc(mmc);
> + bdesc->lun = 0;
> + bdesc->hwpart = 0;
> +
Building U-Boot for Compulab's imx8mm-cl-iot-gate board
Hi Paul,
I am trying to build U-Boot 2021.07-rc5 for the
imx8mm-cl-iot-gate_defconfig target and I am following the imx8mm-evk
readme: doc/board/freescale/imx8mm_evk.rst for the build instructions
and this is the output:
make[1]: Nothing to be done for 'SPL'.
BINMAN all
Image 'main-section' is missing external blobs and is non-functional: blob-ext
Some images are invalid
This happens because I did not provide the fip.bin binary.
Is it OK if I remove the fip.bin entry like this? Would the board still boot?
--- a/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
+++ b/arch/arm/dts/imx8mm-cl-iot-gate-u-boot.dtsi
@@ -217,18 +217,6 @@
};
};
- fip {
- description = "Trusted Firmware FIP";
- type = "firmware";
- arch = "arm64";
- compression = "none";
- load = <0x4031>;
-
- fip_blob: blob-ext{
- filename = "fip.bin";
- };
- };
-
fdt {
description = "NAME";
type = "flat_dt";
Could you please let me know the process for generating fip.bin?
It would be nice to have a doc/board/compulab/imx8mm-iot-gate.rst
README file with these details. I can help with that but need your
help to clarify the generation of fip.bin.
Also, is it OK if I use the ATF firmware and LPDDR binaries version as
specified in doc/board/freescale/imx8mm_evk.rst ?
Thanks,
Fabio Estevam
Re: [PATCH v2 2/2] efi_loader: clear OsIndications
Hi Heinrich, > if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK) && [...] > !IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY)) > ret = efi_launch_capsules(); > + if (ret != EFI_SUCCESS) > + goto out; > + I think OsIndications should be cleared reagrdless of the capsuleupdate result. There's a detailed explanation on your v1 Cheers Ilias > + ret = efi_clear_os_indications(); > out: > efi_obj_list_initialized = ret; > return ret; > -- > 2.30.2 >
Setting serverip from DHCP server
Hi all,
I am running U-Boot on an embedded device that is connected via Ethernet
to my workstation. The workstation is running dhcpd and U-Boot is able
to successfully obtain an IP address via DHCP from the server. However,
the `serverip` environment variable is not being set which prevents
U-Boot from continuing to boot over the network. I have to manually
enter `setenv serverip 10.0.10.1` each time.
How do I get the DHCP server to set the serverip variable? My dhcpd.conf
file is quite simple:
subnet 10.0.10.0 netmask 255.255.255.0 {
option routers 10.0.10.1;
range 10.0.10.2;
}
I would have thought the 'option routers' line would do the trick, but
apparently not. I've done a bit of searching online but haven't yet
found anything helpful.
Thanks,
Greg
[RFC PATCH v1] phy: rockchip: add basic rk3328 support to phy-rockchip-inno-usb2.c
The rk3328 uses a usb phy simulair to rk3399 with only
1 instead of 2 usb ports. Reuse existing U-boot driver and
add basic rk3328 support to phy-rockchip-inno-usb2.c
Signed-off-by: Johan Jonker
---
drivers/phy/rockchip/phy-rockchip-inno-usb2.c | 29 +++
1 file changed, 29 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
index 62b8ba3a4a..bfb531d3cd 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-usb2.c
@@ -243,6 +243,31 @@ static int rockchip_usb2phy_bind(struct udevice *dev)
return ret;
}
+static const struct rockchip_usb2phy_cfg rk3328_usb2phy_cfgs[] = {
+ {
+ .reg= 0x100,
+ .port_cfgs = {
+ [USB2PHY_PORT_OTG] = {
+ .phy_sus= { 0x0100, 8, 0, 0, 0x1d1 },
+ .bvalid_det_en = { 0x0110, 2, 2, 0, 1 },
+ .bvalid_det_st = { 0x0114, 2, 2, 0, 1 },
+ .bvalid_det_clr = { 0x0118, 2, 2, 0, 1 },
+ .utmi_avalid= { 0x0120, 10, 10, 0, 1 },
+ .utmi_bvalid= { 0x0120, 9, 9, 0, 1 },
+ },
+ [USB2PHY_PORT_HOST] = {
+ .phy_sus= { 0x104, 8, 0, 0, 0x1d1 },
+ .ls_det_en = { 0x110, 1, 1, 0, 1 },
+ .ls_det_st = { 0x114, 1, 1, 0, 1 },
+ .ls_det_clr = { 0x118, 1, 1, 0, 1 },
+ .utmi_ls= { 0x120, 17, 16, 0, 1 },
+ .utmi_hstdet= { 0x120, 19, 19, 0, 1 }
+ }
+ },
+ },
+ { /* sentinel */ }
+};
+
static const struct rockchip_usb2phy_cfg rk3399_usb2phy_cfgs[] = {
{
.reg= 0xe450,
@@ -291,6 +316,10 @@ static const struct rockchip_usb2phy_cfg
rk3399_usb2phy_cfgs[] = {
static const struct udevice_id rockchip_usb2phy_ids[] = {
{
+ .compatible = "rockchip,rk3328-usb2phy",
+ .data = (ulong)_usb2phy_cfgs
+ },
+ {
.compatible = "rockchip,rk3399-usb2phy",
.data = (ulong)_usb2phy_cfgs,
},
--
2.11.0
[RFC PATCH v1 3/6] arm: dts: rockchip: move mmc aliases to board files
In the Linux DT the recently introduced async probe on mmc devices
can shuffle block IDs. Pin them to fixed values to ease booting
in environments where UUIDs are not practical.
The newly added mmc aliases should be board specific,
so move them from the general dtsi to the individual boards.
Sort aliases on reg order when available and without number gap.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3328-evb.dts| 6 ++
arch/arm/dts/rk3328-nanopi-r2s.dts | 4
arch/arm/dts/rk3328-roc-cc.dts | 5 +
arch/arm/dts/rk3328-rock-pi-e.dts | 5 +
arch/arm/dts/rk3328-rock64.dts | 5 +
arch/arm/dts/rk3328-u-boot.dtsi| 2 --
6 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index ad072c..832773d0fd 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -10,6 +10,12 @@
model = "Rockchip RK3328 EVB";
compatible = "rockchip,rk3328-evb", "rockchip,rk3328";
+ aliases {
+ mmc0 =
+ mmc1 =
+ mmc2 =
+ };
+
chosen {
stdout-path = "serial2:150n8";
};
diff --git a/arch/arm/dts/rk3328-nanopi-r2s.dts
b/arch/arm/dts/rk3328-nanopi-r2s.dts
index b1e45c01a9..92bb282ed9 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts
+++ b/arch/arm/dts/rk3328-nanopi-r2s.dts
@@ -13,6 +13,10 @@
model = "FriendlyElec NanoPi R2S";
compatible = "friendlyarm,nanopi-r2s", "rockchip,rk3328";
+ aliases {
+ mmc0 =
+ };
+
chosen {
stdout-path = "serial2:150n8";
};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
index 8dc4c57fbb..401be93364 100644
--- a/arch/arm/dts/rk3328-roc-cc.dts
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -10,6 +10,11 @@
model = "Firefly roc-rk3328-cc";
compatible = "firefly,roc-rk3328-cc", "rockchip,rk3328";
+ aliases {
+ mmc0 =
+ mmc1 =
+ };
+
chosen {
stdout-path = "serial2:150n8";
};
diff --git a/arch/arm/dts/rk3328-rock-pi-e.dts
b/arch/arm/dts/rk3328-rock-pi-e.dts
index 57e36ec609..63e73781f1 100644
--- a/arch/arm/dts/rk3328-rock-pi-e.dts
+++ b/arch/arm/dts/rk3328-rock-pi-e.dts
@@ -10,6 +10,11 @@
model = "Radxa Rockpi E";
compatible = "radxa,rock-pi-e", "rockchip,rk3328";
+ aliases {
+ mmc0 =
+ mmc1 =
+ };
+
chosen {
stdout-path = "serial2:150n8";
};
diff --git a/arch/arm/dts/rk3328-rock64.dts b/arch/arm/dts/rk3328-rock64.dts
index 7a78255f52..57a796e220 100644
--- a/arch/arm/dts/rk3328-rock64.dts
+++ b/arch/arm/dts/rk3328-rock64.dts
@@ -10,6 +10,11 @@
model = "Pine64 Rock64";
compatible = "pine64,rock64", "rockchip,rk3328";
+ aliases {
+ mmc0 =
+ mmc1 =
+ };
+
chosen {
stdout-path = "serial2:150n8";
};
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index 1d7bf19192..e00e466d8d 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -5,8 +5,6 @@
/ {
aliases {
- mmc0 =
- mmc1 =
spi0 =
};
--
2.11.0
[RFC PATCH v1 5/6] rockchip: rk3318: add a95x-z2-rk3318_defconfig file
This commit adds the default configuration file and relevant description for A95X Z2 board Signed-off-by: Johan Jonker --- board/rockchip/evb_rk3328/MAINTAINERS | 6 ++ configs/a95x-z2-rk3318_defconfig | 102 ++ doc/board/rockchip/rockchip.rst | 2 + 3 files changed, 110 insertions(+) create mode 100644 configs/a95x-z2-rk3318_defconfig diff --git a/board/rockchip/evb_rk3328/MAINTAINERS b/board/rockchip/evb_rk3328/MAINTAINERS index 14fda46e8f..a4573c2ff9 100644 --- a/board/rockchip/evb_rk3328/MAINTAINERS +++ b/board/rockchip/evb_rk3328/MAINTAINERS @@ -1,3 +1,9 @@ +A95X-Z2-RK3318 +M: Johan Jonker +S: Maintained +F: configs/a95x-z2-rk3318_defconfig +F: arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi + EVB-RK3328 M: Kever Yang S: Maintained diff --git a/configs/a95x-z2-rk3318_defconfig b/configs/a95x-z2-rk3318_defconfig new file mode 100644 index 00..cba0f6c659 --- /dev/null +++ b/configs/a95x-z2-rk3318_defconfig @@ -0,0 +1,102 @@ +CONFIG_ARM=y +CONFIG_ARCH_ROCKCHIP=y +CONFIG_SYS_TEXT_BASE=0x0020 +CONFIG_SPL_GPIO_SUPPORT=y +CONFIG_NR_DRAM_BANKS=1 +CONFIG_ENV_OFFSET=0x3F8000 +CONFIG_ROCKCHIP_RK3328=y +CONFIG_TPL_ROCKCHIP_COMMON_BOARD=y +CONFIG_TPL_LIBCOMMON_SUPPORT=y +CONFIG_TPL_LIBGENERIC_SUPPORT=y +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y +CONFIG_SPL_STACK_R_ADDR=0x60 +CONFIG_DEBUG_UART_BASE=0xFF13 +CONFIG_DEBUG_UART_CLOCK=2400 +CONFIG_DEFAULT_DEVICE_TREE="rk3318-a95x-z2" +CONFIG_DEBUG_UART=y +CONFIG_TPL_SYS_MALLOC_F_LEN=0x800 +# CONFIG_ANDROID_BOOT_IMAGE is not set +CONFIG_FIT=y +CONFIG_FIT_VERBOSE=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3318-a95x-z2.dtb" +# CONFIG_DISPLAY_CPUINFO is not set +CONFIG_DISPLAY_BOARDINFO_LATE=y +CONFIG_MISC_INIT_R=y +# CONFIG_SPL_RAW_IMAGE_SUPPORT is not set +CONFIG_TPL_SYS_MALLOC_SIMPLE=y +CONFIG_SPL_STACK_R=y +CONFIG_SPL_I2C_SUPPORT=y +CONFIG_SPL_POWER_SUPPORT=y +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_CMD_BOOTZ=y +CONFIG_CMD_GPT=y +CONFIG_CMD_MMC=y +CONFIG_CMD_USB=y +# CONFIG_CMD_SETEXPR is not set +CONFIG_CMD_TIME=y +CONFIG_SPL_OF_CONTROL=y +CONFIG_TPL_OF_CONTROL=y +CONFIG_OF_SPL_REMOVE_PROPS="clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" +CONFIG_TPL_OF_PLATDATA=y +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set +CONFIG_TPL_DM=y +CONFIG_REGMAP=y +CONFIG_SPL_REGMAP=y +CONFIG_TPL_REGMAP=y +CONFIG_SYSCON=y +CONFIG_SPL_SYSCON=y +CONFIG_TPL_SYSCON=y +CONFIG_CLK=y +CONFIG_SPL_CLK=y +CONFIG_FASTBOOT_BUF_ADDR=0x800800 +CONFIG_FASTBOOT_MMC_BOOT_SUPPORT=y +CONFIG_FASTBOOT_MMC_USER_SUPPORT=y +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y +CONFIG_ROCKCHIP_GPIO=y +CONFIG_SYS_I2C_ROCKCHIP=y +CONFIG_MMC_DW=y +CONFIG_MMC_DW_ROCKCHIP=y +CONFIG_SF_DEFAULT_SPEED=2000 +CONFIG_DM_ETH=y +CONFIG_DM_ETH_PHY=y +CONFIG_PHY_ROCKCHIP_INNO_USB2=y +CONFIG_PINCTRL=y +CONFIG_SPL_PINCTRL=y +CONFIG_DM_PMIC=y +CONFIG_PMIC_RK8XX=y +CONFIG_SPL_DM_REGULATOR=y +CONFIG_REGULATOR_PWM=y +CONFIG_DM_REGULATOR_FIXED=y +CONFIG_SPL_DM_REGULATOR_FIXED=y +CONFIG_REGULATOR_RK8XX=y +CONFIG_PWM_ROCKCHIP=y +CONFIG_RAM=y +CONFIG_SPL_RAM=y +CONFIG_TPL_RAM=y +CONFIG_DM_RESET=y +CONFIG_BAUDRATE=150 +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYSINFO=y +CONFIG_SYSINFO_SMBIOS=y +CONFIG_SYSRESET=y +# CONFIG_TPL_SYSRESET is not set +CONFIG_USB=y +CONFIG_USB_XHCI_HCD=y +CONFIG_USB_XHCI_DWC3=y +CONFIG_USB_EHCI_HCD=y +CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_HCD=y +CONFIG_USB_OHCI_GENERIC=y +CONFIG_USB_DWC2=y +CONFIG_USB_DWC3=y +# CONFIG_USB_DWC3_GADGET is not set +CONFIG_USB_GADGET=y +CONFIG_USB_GADGET_DWC2_OTG=y +CONFIG_USB_FUNCTION_ROCKUSB=y +CONFIG_SPL_TINY_MEMSET=y +CONFIG_TPL_TINY_MEMSET=y +CONFIG_ERRNO_STR=y diff --git a/doc/board/rockchip/rockchip.rst b/doc/board/rockchip/rockchip.rst index fbb9983988..49a2dd2dd3 100644 --- a/doc/board/rockchip/rockchip.rst +++ b/doc/board/rockchip/rockchip.rst @@ -44,6 +44,8 @@ List of mainline supported rockchip boards: * rk3308 - Rockchip Evb-RK3308 (evb-rk3308) - Roc-cc-RK3308 (roc-cc-rk3308) +* rk3318 + - A95X Z2 (a95x-z2-rk3318) * rk3328 - Rockchip Evb-RK3328 (evb-rk3328) - Pine64 Rock64 (rock64-rk3328) -- 2.11.0
[RFC PATCH v1 6/6] arm: dts: rockchip: add rk3318 A95X Z2 board
The rk3318 A95X Z2 boards are sold as TV box.
No further documentation is given, but from the dts files
extracted it seems that the rk3318 processor is simulair
to the rk3328. This dts file contains only the basic nodes
that have support in the mainline kernel. Included extra
dtsi file for U-boot specific properties.
Features:
CPU: RK3318 Quad-Core Cortex-A53
GPU: Mali-450
RAM: 2/4GB DDR3
ROM: EMMC 16/32/64GB
HDMI: HDMI 2.0a for 4k@60Hz
Ethernet: 10/100M standard RJ-45
WiFi: 2.4G+5G WIFI, 802.11 b/g/n
Bluetooth: 4.0
1 x USB 3.0
1 x USB 2.0
1 x Micro SD card slot
1 x SPDIF
1 x AV
1 x DC IN
Signed-off-by: Johan Jonker
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi | 59 +
arch/arm/dts/rk3318-a95x-z2.dts | 384
3 files changed, 444 insertions(+)
create mode 100644 arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3318-a95x-z2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9918e46633..3e1e2209b7 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -107,6 +107,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3308) += \
rk3308-roc-cc.dtb
dtb-$(CONFIG_ROCKCHIP_RK3328) += \
+ rk3318-a95x-z2.dtb \
rk3328-evb.dtb \
rk3328-nanopi-r2s.dtb \
rk3328-roc-cc.dtb \
diff --git a/arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi
b/arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi
new file mode 100644
index 00..5010925e9a
--- /dev/null
+++ b/arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi
@@ -0,0 +1,59 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+#include "rk3328-u-boot.dtsi"
+#include "rk3328-sdram-ddr3-666.dtsi"
+
+/ {
+ chosen {
+ u-boot,spl-boot-order = "same-as-spl", ,
+ };
+
+ smbios {
+ compatible = "u-boot,sysinfo-smbios";
+
+ smbios {
+ system {
+ manufacturer = "zkmagic";
+ product = "a95x-z2_rk3318";
+ };
+
+ baseboard {
+ manufacturer = "zkmagic";
+ product = "a95x-z2_rk3318";
+ };
+
+ chassis {
+ manufacturer = "zkmagic";
+ product = "a95x-z2_rk3318";
+ };
+ };
+ };
+};
+
+ {
+ status = "broken";
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_pull_up_4ma {
+ u-boot,dm-spl;
+};
+
+ {
+ u-boot,dm-spl;
+};
+
+_pin {
+ u-boot,dm-spl;
+};
+
+_otg {
+ dr_mode = "otg";
+};
+
+_sd {
+ u-boot,dm-spl;
+};
diff --git a/arch/arm/dts/rk3318-a95x-z2.dts b/arch/arm/dts/rk3318-a95x-z2.dts
new file mode 100644
index 00..d41f786b2f
--- /dev/null
+++ b/arch/arm/dts/rk3318-a95x-z2.dts
@@ -0,0 +1,384 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+#include
+#include "rk3328.dtsi"
+
+/ {
+ model = "A95X Z2";
+ compatible = "zkmagic,a95x-z2", "rockchip,rk3318";
+
+ aliases {
+ mmc0 =
+ mmc1 =
+ mmc2 =
+ };
+
+ chosen {
+ stdout-path = "serial2:150n8";
+ };
+
+ adc-keys {
+ compatible = "adc-keys";
+ io-channels = < 0>;
+ io-channel-names = "buttons";
+ keyup-threshold-microvolt = <180>;
+ poll-interval = <100>;
+
+ recovery {
+ label = "recovery";
+ linux,code = ;
+ press-threshold-microvolt = <17000>;
+ };
+ };
+
+ ir-receiver {
+ compatible = "gpio-ir-receiver";
+ gpios = < RK_PA2 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <_int>;
+ pinctrl-names = "default";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-0 = <_led_pin>;
+ pinctrl-names = "default";
+
+ cyx_led: led-0 {
+ default-state = "on";
+ gpios = < RK_PC7 GPIO_ACTIVE_LOW>;
+ label = "CYX_LED";
+ };
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ pinctrl-0 = <_enable_h>;
+ pinctrl-names = "default";
+ reset-gpios = < RK_PC2 GPIO_ACTIVE_LOW>;
+ };
+
+ spdif-sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "SPDIF";
+
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <_out>;
+ };
+ };
+
+ spdif_out: spdif-out {
+ compatible = "linux,spdif-dit";
+ #sound-dai-cells = <0>;
+
[RFC PATCH v1 4/6] arm: dts: rockchip: move spi0 u-boot, dm-pre-reloc and alias to rk3328 board files
The spi0 node has a common u-boot,dm-pre-reloc property and
an alias in rk3328-u-boot.dtsi, so all boards contain this
as well in u-boot-tpl.dtb. Clean it up a bit and move it
to only boards that use it.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 6 ++
arch/arm/dts/rk3328-u-boot.dtsi| 8
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 37ecc6a753..dae79d6268 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -6,6 +6,10 @@
#include "rk3328-u-boot.dtsi"
#include "rk3328-sdram-lpddr3-1600.dtsi"
/ {
+ aliases {
+ spi0 =
+ };
+
chosen {
u-boot,spl-boot-order = "same-as-spl", ,
};
@@ -69,6 +73,8 @@
};
{
+ u-boot,dm-pre-reloc;
+
spi_flash: spiflash@0 {
u-boot,dm-pre-reloc;
};
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index e00e466d8d..03e5f18f1a 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -4,10 +4,6 @@
*/
/ {
- aliases {
- spi0 =
- };
-
chosen {
u-boot,spl-boot-order = ,
};
@@ -54,7 +50,3 @@
_otg {
hnp-srp-disable;
};
-
- {
- u-boot,dm-pre-reloc;
-};
--
2.11.0
[RFC PATCH v1 2/6] arm: dts: rockchip: remove usb_host0_xhci node from rk3328-u-boot.dtsi
The rk3328.dtsi file was updated with a usbdrd3 node.
Remove the usb_host0_xhci node from rk3328-u-boot.dtsi,
because it's deprecated now the driver is removed.
Add usbdrd3 as place holder in existing dtsi files.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3328-evb-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-roc-cc-u-boot.dtsi| 2 +-
arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-rock64-u-boot.dtsi| 2 +-
arch/arm/dts/rk3328-u-boot.dtsi | 11 ---
5 files changed, 4 insertions(+), 15 deletions(-)
diff --git a/arch/arm/dts/rk3328-evb-u-boot.dtsi
b/arch/arm/dts/rk3328-evb-u-boot.dtsi
index 4bfa0c2330..bab0187f01 100644
--- a/arch/arm/dts/rk3328-evb-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-evb-u-boot.dtsi
@@ -45,7 +45,7 @@
status = "broken";
};
-_host0_xhci {
+ {
vbus-supply = <_host_xhci>;
status = "okay";
};
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
index 20a62134a0..4d59e35788 100644
--- a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -48,7 +48,7 @@
u-boot,dm-spl;
};
-_host0_xhci {
+ {
vbus-supply = <_host1_5v>;
status = "okay";
};
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
index 0b1a42c49f..028919d9b3 100644
--- a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
@@ -45,7 +45,7 @@
u-boot,dm-spl;
};
-_host0_xhci {
+ {
vbus-supply = <_host_xhci>;
status = "okay";
};
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 3c3b1370e3..37ecc6a753 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -48,7 +48,7 @@
u-boot,dm-spl;
};
-_host0_xhci {
+ {
vbus-supply = <_host_5v>;
status = "okay";
};
diff --git a/arch/arm/dts/rk3328-u-boot.dtsi b/arch/arm/dts/rk3328-u-boot.dtsi
index 1633558264..1d7bf19192 100644
--- a/arch/arm/dts/rk3328-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-u-boot.dtsi
@@ -24,17 +24,6 @@
0x0 0xff72 0x0 0x1000
0x0 0xff798000 0x0 0x1000>;
};
-
- usb_host0_xhci: usb@ff60 {
- compatible = "rockchip,rk3328-xhci";
- reg = <0x0 0xff60 0x0 0x10>;
- interrupts = ;
- snps,dis-enblslpm-quirk;
- snps,phyif-utmi-bits = <16>;
- snps,dis-u2-freeclk-exists-quirk;
- snps,dis-u2-susphy-quirk;
- status = "disabled";
- };
};
{
--
2.11.0
[RFC PATCH v1 1/6] arm: dts: rockchip: update rk3328.dtsi
In the Linux DT the file rk3328.dtsi has recently had
some updates. Update this for U-boot as well.
The rk3328 usb3 port has now support in the Linux DT.
Rename node names ending on 'gpio' to 'pin' or 'pins'.
Signed-off-by: Johan Jonker
---
arch/arm/dts/rk3328-evb.dts| 2 +-
arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-nanopi-r2s.dts | 2 +-
arch/arm/dts/rk3328-roc-cc-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-roc-cc.dts | 2 +-
arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-rock-pi-e.dts | 2 +-
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-rock64.dts | 2 +-
arch/arm/dts/rk3328.dtsi | 109 +
10 files changed, 72 insertions(+), 55 deletions(-)
diff --git a/arch/arm/dts/rk3328-evb.dts b/arch/arm/dts/rk3328-evb.dts
index 6abc6f4a86..ad072c 100644
--- a/arch/arm/dts/rk3328-evb.dts
+++ b/arch/arm/dts/rk3328-evb.dts
@@ -41,7 +41,7 @@
compatible = "regulator-fixed";
gpio = < 30 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
- pinctrl-0 = <_gpio>;
+ pinctrl-0 = <_pin>;
regulator-name = "vcc_sd";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
diff --git a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
index 9e2ced1541..8db5e55af6 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi
@@ -20,7 +20,7 @@
u-boot,dm-spl;
};
-_gpio {
+_pin {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/rk3328-nanopi-r2s.dts
b/arch/arm/dts/rk3328-nanopi-r2s.dts
index 5445c5cb3d..b1e45c01a9 100644
--- a/arch/arm/dts/rk3328-nanopi-r2s.dts
+++ b/arch/arm/dts/rk3328-nanopi-r2s.dts
@@ -79,7 +79,7 @@
vcc_sd: sdmmc-regulator {
compatible = "regulator-fixed";
gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
- pinctrl-0 = <_gpio>;
+ pinctrl-0 = <_pin>;
pinctrl-names = "default";
regulator-name = "vcc_sd";
regulator-boot-on;
diff --git a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
index 08806dfc0f..20a62134a0 100644
--- a/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
@@ -40,7 +40,7 @@
u-boot,dm-spl;
};
-_gpio {
+_pin {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/rk3328-roc-cc.dts b/arch/arm/dts/rk3328-roc-cc.dts
index 8d553c9218..8dc4c57fbb 100644
--- a/arch/arm/dts/rk3328-roc-cc.dts
+++ b/arch/arm/dts/rk3328-roc-cc.dts
@@ -34,7 +34,7 @@
compatible = "regulator-fixed";
gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
- pinctrl-0 = <_gpio>;
+ pinctrl-0 = <_pin>;
regulator-boot-on;
regulator-name = "vcc_sd";
regulator-min-microvolt = <330>;
diff --git a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
index 4fc055eacb..0b1a42c49f 100644
--- a/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi
@@ -37,7 +37,7 @@
u-boot,dm-spl;
};
-_gpio {
+_pin {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/rk3328-rock-pi-e.dts
b/arch/arm/dts/rk3328-rock-pi-e.dts
index 4b9f9a8248..57e36ec609 100644
--- a/arch/arm/dts/rk3328-rock-pi-e.dts
+++ b/arch/arm/dts/rk3328-rock-pi-e.dts
@@ -25,7 +25,7 @@
compatible = "regulator-fixed";
gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
- pinctrl-0 = <_gpio>;
+ pinctrl-0 = <_pin>;
regulator-name = "vcc_sd";
regulator-always-on;
regulator-boot-on;
diff --git a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
index 2af32aea05..3c3b1370e3 100644
--- a/arch/arm/dts/rk3328-rock64-u-boot.dtsi
+++ b/arch/arm/dts/rk3328-rock64-u-boot.dtsi
@@ -40,7 +40,7 @@
u-boot,dm-spl;
};
-_gpio {
+_pin {
u-boot,dm-spl;
};
diff --git a/arch/arm/dts/rk3328-rock64.dts b/arch/arm/dts/rk3328-rock64.dts
index ebf3eb222e..7a78255f52 100644
--- a/arch/arm/dts/rk3328-rock64.dts
+++ b/arch/arm/dts/rk3328-rock64.dts
@@ -25,7 +25,7 @@
compatible = "regulator-fixed";
gpio = < RK_PD6 GPIO_ACTIVE_LOW>;
pinctrl-names = "default";
- pinctrl-0 = <_gpio>;
+ pinctrl-0 = <_pin>;
regulator-name = "vcc_sd";
regulator-min-microvolt = <330>;
regulator-max-microvolt = <330>;
diff --git a/arch/arm/dts/rk3328.dtsi b/arch/arm/dts/rk3328.dtsi
index 945387e579..95c7c70ca0 100644
--- a/arch/arm/dts/rk3328.dtsi
+++ b/arch/arm/dts/rk3328.dtsi
[RFC PATCH v1 0/6] add rk3318 A95X Z2 board
With a new board from a recent Linux DT the U-boot rk3328.dtsi
is in need for an update.
Please advise what to do with usb3 regulators, aliases and
other stuff that has to change.
Also some of the U-boot board files could use some
dtbs_check for bogus properties and restyling... ;)
rk3328 USB2 and USB3 only roughly tested.
===
Howto use:
Compile bl31.elf:
git clone --depth 1 https://github.com/ARM-software/arm-trusted-firmware.git
cd arm-trusted-firmware
make realclean
make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3328
export BL31=//arm-trusted-firmware/build/rk3328/release/bl31/bl31.elf
cd ..
Compile U-boot:
git clone --depth 1 https://github.com/u-boot/u-boot.git uboot
cd uboot
make CROSS_COMPILE=aarch64-linux-gnu- a95x-z2-rk3318_defconfig all
===
Use U-boot to create a GPT on a SD card,
because of partition GUID and sizes.
mmc dev 0
mmc info
gpt write mmc 0 $partitions
mmc part
===
Write to SD card:
export DISK=/dev/mmcblk0
sudo dd if=./idbloader.img of=${DISK} seek=64
sudo dd if=./u-boot.itb of=${DISK} seek=16384
sync
===
Format boot partition with fat16.
Add /Image and /rk3318-a95x-z2.dtb
Add extlinux dir with extlinux.conf
label kernel
kernel /Image
fdt /rk3318-a95x-z2.dtb
append root=/dev/mmcblk0p5 rw console=tty0 console=ttyS2,150n8
earlycon=uart8250,mmio32,0xff13,keep $
===
Use fastboot:
Hit any key to stop autoboot:
usb start
usb dev 1
fastboot usb 1
=
sudo fastboot devices -l
sudo fastboot erase loader1
sudo fastboot erase loader2
sudo fastboot flash loader1 idbloader.img
sudo fastboot flash loader2 u-boot.itb
=
ctrl-c
reset
===
Johan Jonker (6):
arm: dts: rockchip: update rk3328.dtsi
arm: dts: rockchip: remove usb_host0_xhci node from rk3328-u-boot.dtsi
arm: dts: rockchip: move mmc aliases to board files
arm: dts: rockchip: move spi0 u-boot,dm-pre-reloc and alias to rk3328
board files
rockchip: rk3318: add a95x-z2-rk3318_defconfig file
arm: dts: rockchip: add rk3318 A95X Z2 board
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi| 59 +
arch/arm/dts/rk3318-a95x-z2.dts| 384 +
arch/arm/dts/rk3328-evb-u-boot.dtsi| 2 +-
arch/arm/dts/rk3328-evb.dts| 8 +-
arch/arm/dts/rk3328-nanopi-r2s-u-boot.dtsi | 2 +-
arch/arm/dts/rk3328-nanopi-r2s.dts | 6 +-
arch/arm/dts/rk3328-roc-cc-u-boot.dtsi | 4 +-
arch/arm/dts/rk3328-roc-cc.dts | 7 +-
arch/arm/dts/rk3328-rock-pi-e-u-boot.dtsi | 4 +-
arch/arm/dts/rk3328-rock-pi-e.dts | 7 +-
arch/arm/dts/rk3328-rock64-u-boot.dtsi | 10 +-
arch/arm/dts/rk3328-rock64.dts | 7 +-
arch/arm/dts/rk3328-u-boot.dtsi| 21 --
arch/arm/dts/rk3328.dtsi | 109
board/rockchip/evb_rk3328/MAINTAINERS | 6 +
configs/a95x-z2-rk3318_defconfig | 102
doc/board/rockchip/rockchip.rst| 2 +
18 files changed, 661 insertions(+), 80 deletions(-)
create mode 100644 arch/arm/dts/rk3318-a95x-z2-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3318-a95x-z2.dts
create mode 100644 configs/a95x-z2-rk3318_defconfig
--
2.11.0
[PATCH v2] cmd:Elaborate 'blkcache' cmd HELP statement
From: Adarsh Babu Kalepalli HELP description is provided for ‘configure’ sub-command of ‘blkcache’. Signed-off-by: Adarsh Babu Kalepalli --- (no changes since v1) cmd/blkcache.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/cmd/blkcache.c b/cmd/blkcache.c index 25f252e455..47ea1ec0b9 100644 --- a/cmd/blkcache.c +++ b/cmd/blkcache.c @@ -83,5 +83,6 @@ U_BOOT_CMD( blkcache, 4, 0, do_blkcache, "block cache diagnostics and control", "show - show and reset statistics\n" - "blkcache configure blocks entries\n" + "blkcache configure " + "- set max blocks per entry and max cache entries\n" ); -- 2.17.1
Re: [PATCH 0/3] cmd: setexpr: add fmt format string operation
On Wed, 30 Jun 2021 12:17:47 -0400 Sean Anderson wrote: > On 6/29/21 11:13 AM, Wolfgang Denk wrote: > > Dear Sean, > > > > In message <19b6eeea-2aad-972b-aeeb-8959aab17...@gmail.com> you > > wrote: > >> > >> The issue with this is twofold. First, there is no portable way to > >> construct a va_list from C code. So the likely way to do this > >> would be to set an arbitrary limit, and then just pass the > >> arguments in. E.g. something like > > > > We already have an argument list: it's what's being passed to the > > "setexpr" command, minus the initial arguments. > > > >>snprintf(buf, sizeof(buf), argv[3], argc >= 4 ? argv[4] : > >> NULL, /* etc */); > > > > Why this test on argc? If it's less than 4, argv[4] should be NULL > > anyway. > > snprintf(buf, sizeof(buf), argv[3], argc >= 4 ? argv[4] : > NULL, argc >= 5 ? argv[5] : NULL, argc >= 6 ? argv[6] : NULL, /* etc > */); This is insane. The argv[]s are strings. What if I use "%08x" as format, and pass "123" as argument?? It would print pointer to the string. Clearly this needs its own implementation... Marek
Re: [PATCH V2] spi: Update speed/mode on change
On Thu, Jun 10, 2021 at 02:00:00PM +0200, Marek Vasut wrote: > The spi_get_bus_and_cs() may be called on the same bus and chipselect > with different frequency or mode. This is valid usecase, but the code > fails to notify the controller of such a configuration change. Call > spi_set_speed_mode() in case bus frequency or bus mode changed to let > the controller update the configuration. > > The problem can easily be triggered using the sspi command: > => sspi 0:0@1000 > => sspi 0:0@2000 > Without this patch, both transfers happen at 1000 Hz. With this patch, > the later transfer happens correctly at 2000 Hz. > > Signed-off-by: Marek Vasut > Cc: Jagan Teki > Cc: Patrick Delaunay Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v2] efi_loader: Improve the parameter check for QueryVariableInfo()
On 6/30/21 5:49 PM, Masami Hiramatsu wrote:
Improve efi_query_variable_info() to check the parameter settings and
return correct error code according to the UEFI Specification 2.9,
and the Self Certification Test (SCT) II Case Specification, June
2017, chapter 4.1.4 QueryVariableInfo().
Signed-off-by: Masami Hiramatsu
Reported-by: Kazuhiko Sakamoto
Reviewed-by: Heinrich Schuchardt
---
Changes in v2:
- Add a reference to SCT 2 spec.
- Fix checkpatch.pl warnings.
- Simplify the check according to Henrich's comments.
---
lib/efi_loader/efi_var_common.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index 83479dd142..3d92afe2eb 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -163,6 +163,19 @@ efi_status_t EFIAPI efi_query_variable_info(
EFI_ENTRY("%x %p %p %p", attributes, maximum_variable_storage_size,
remaining_variable_storage_size, maximum_variable_size);
+ if (!maximum_variable_storage_size ||
+ !remaining_variable_storage_size ||
+ !maximum_variable_size ||
+ !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS))
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+
+ if ((attributes & ~(u32)EFI_VARIABLE_MASK) ||
+ (attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) ||
+ (attributes & EFI_VARIABLE_HARDWARE_ERROR_RECORD) ||
+ (!IS_ENABLED(CONFIG_EFI_SECURE_BOOT) &&
+(attributes & EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)))
+ return EFI_EXIT(EFI_UNSUPPORTED);
+
ret = efi_query_variable_info_int(attributes,
maximum_variable_storage_size,
remaining_variable_storage_size,
Re: [PATCH 0/3] cmd: setexpr: add fmt format string operation
On 6/29/21 11:13 AM, Wolfgang Denk wrote: Dear Sean, In message <19b6eeea-2aad-972b-aeeb-8959aab17...@gmail.com> you wrote: The issue with this is twofold. First, there is no portable way to construct a va_list from C code. So the likely way to do this would be to set an arbitrary limit, and then just pass the arguments in. E.g. something like We already have an argument list: it's what's being passed to the "setexpr" command, minus the initial arguments. snprintf(buf, sizeof(buf), argv[3], argc >= 4 ? argv[4] : NULL, /* etc */); Why this test on argc? If it's less than 4, argv[4] should be NULL anyway. snprintf(buf, sizeof(buf), argv[3], argc >= 4 ? argv[4] : NULL, argc >= 5 ? argv[5] : NULL, argc >= 6 ? argv[6] : NULL, /* etc */); and you keep doing this until you get to whatever number of arguments you'd like. but of course there is no way to check that the format string matches the correct number of arguments. This is a pretty big footgun. You have this problem always when you have user provided format strings and arguments. We don't have to re-invent the wheel here. I repeat myself: maybe we should have a look at bash's implementation of the printf builtin command? there I get for example this: $ printf "%d %d %d\n" 3 3 0 0 $ printf "%d %d %d\n" foo bar -bash: printf: foo: invalid number -bash: printf: bar: invalid number 0 0 0 The other problem is that things like `%d` expect a number and not a string. So you would have to reimplement snprintf anyway so that it expects all of its arguments to be strings, and calls strtoul as appropriate. And considering that the *printf functions take 5k already, this reimplementation may add a significant amount of code. For this reason, I'd much prefer to just have `hex` and `dec` functions which do the appropriate conversions. Eventually the format checking can be kept out of the generic *printf() code; it could then be optional/configurable with the "fmt" option in the setexpr command. It's not a "checking" problem. The issue is that "123" cannot be passed directly to %d. So you have dig into the guts of snprintf anyway. --Sean
Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
Hi Tom, On Wed, 30 Jun 2021 at 09:49, Tom Rini wrote: > > On Wed, Jun 30, 2021 at 05:31:44PM +0300, Ivaylo Dimitrov wrote: > > Hi, > > > > On 30.06.21 г. 16:33 ч., Tom Rini wrote: > > > On Wed, Jun 30, 2021 at 10:30:20AM +0300, Ivaylo Dimitrov wrote: > > > > Hi, > > > > > > > > On 26.06.21 г. 17:58 ч., Tom Rini wrote: > > > > > On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote: > > > > > > Hi Tom, Marek, > > > > > > > > > > > > On 25/06/2021 23:59, Tom Rini wrote: > > > > > > > On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote: > > > > > > > > On Friday 25 June 2021 17:37:44 Tom Rini wrote: > > > > > > > > > One thing I want to say here as I think it maybe wasn't clear > > > > > > > > > in Marek's > > > > > > > > > suggestion. Why not have X-Loader boot SPL which loads > > > > > > > > > U-Boot from extN > > > > > > > > > on the eMMC? > > > > > > > > > > > > > > > > Hello Tom! I have already answered this in my previous email. > > > > > > > > > > > > > > I just re-read things and I don't see it. But perhaps I'm not > > > > > > > being > > > > > > > clear enough. Why can't you just have NOLO start SPL, not > > > > > > > re-initialize > > > > > > > things (which is a really common case now thanks to aarch64) and > > > > > > > just > > > > > > > use that to load full U-Boot from a not size restricted place? > > > > > > > > > > > > > > > > > > > I think there are a few problems. > > > > > > > > > > > > 1. One is a practical one, from Pali's email: > > > > > > > > > > > > > There is no easy access to eMMC until you start full U-Boot. So > > > > > > > even if all these problems are solved then "bootstrapping" or > > > > > > > flashing U-Boot into such location is not possible, plus there is > > > > > > > no recovery. Plus this loose existing and working operating > > > > > > > system, which is no-go. So this way is basically undebugable and > > > > > > > therefore perfectly hard to develop. > > > > > > > > > > > > Not being able to access the eMMC to write u-boot until u-boot is > > > > > > started does sound like it would make things a bit more tricky. > > > > > > > > > > I don't understand this. Either way it's drivers/mmc/omap_hsmmc.c. > > > > > > > > > > > 2. According to Pali, adding SPL support would not be a trivial > > > > > > task, > > > > > > and might end up with a lot more "#ifdef"s in SPL than the one in > > > > > > Ivaylo's patch. As I understand it, this hypothetical SPL would > > > > > > mostly > > > > > > not do any hardware initialisation on the N900, so that might be > > > > > > where > > > > > > instead hacks would need to be added to SPL. > > > > > > > > > > > > Pali also wrote: > > > > > > > > > > > > > U-Boot for N900 does not use SPL. There is no SPL code > > > > > > > implemented. > > > > > > > Nobody ever tried to implement it and neither tested. As you have > > > > > > > correctly pointed instead of SPL is used vendor X-Loader binary, > > > > > > > which > > > > > > > is signed by RSA key. > > > > > > And when I asked him today: > > > > > > > > > > > > > 12:11 < Pali> in past (10 years ago?) I was investigating the way > > > > > > > how we can boot u-boot and the only reasable way was the current > > > > > > > one, directly load main u-boot by x-loader/nolo > > > > > > > 12:12 < Pali> I have already spend some time with spl on n900 and > > > > > > > at that time I have rejected this idea, because it did not work > > > > > > > that > > > > > > > 12:13 < Pali> spl is also doing hw initialization which cannot be > > > > > > > called on n900 as this code basically crash / freeze n900 > > > > > > So perhaps it would make sense to get more clarity on that, since > > > > > > that > > > > > > seems to be where the argument gets stuck. > > > > > > > > > > This also doesn't make sense to me. CONFIG_SKIP_LOWLEVEL_INIT should > > > > > let you skip whatever initialization doesn't need to be done. If > > > > > there's some init that needs to be skipped but isn't, that's a bug. > > > > > > > > > > > Also, I'd like to point what Ivaylo wrote earlier: > > > > > > > > > > > > > > This sounds like a workaround though. Can you instead do the > > > > > > > > full conversion of the board? I am sure the board removal patch > > > > > > > > can be postponed if there is plan to convert it. > > > > > > > > > > > > > > Hard to say if migration to device-tree is even possible on N900 > > > > > > > ATM, enabling OF_CONTROL increases the size of the produced > > > > > > > binary with some 100k (.dtb not included), making the size of the > > > > > > > binary way above our budget of ~256k. Sure, board config does not > > > > > > > enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 > > > > > > > and noone can guarantee we're not going to see SIGILL faults if > > > > > > > we enable it. Which it seems we are forced to do even with DM_USB > > > > > > > migration only. > > > > > > > > > > > > > > Re workaround - I took examples of #ifdef's from
[PATCH v6 4/5] mtd: spi-nor-ids: Add XTX XT25F128B
From: Chris Morgan
Adds support for XT25F128B used on Odroid Go Advance. Unfortunately
this chip uses a continuation code which I cannot seem to parse, so
there are possibly going to be collisions with chips that use the same
manufacturer/ID.
Signed-off-by: Chris Morgan
Signed-off-by: Jon Lin
---
(no changes since v1)
drivers/mtd/spi/Kconfig | 6 ++
drivers/mtd/spi/spi-nor-ids.c | 8
2 files changed, 14 insertions(+)
diff --git a/drivers/mtd/spi/Kconfig b/drivers/mtd/spi/Kconfig
index f8db8e5213..8c797d1e03 100644
--- a/drivers/mtd/spi/Kconfig
+++ b/drivers/mtd/spi/Kconfig
@@ -162,6 +162,12 @@ config SPI_FLASH_XMC
Add support for various XMC (Wuhan Xinxin Semiconductor
Manufacturing Corp.) SPI flash chips (XM25xxx)
+config SPI_FLASH_XTX
+ bool "XTX SPI flash support"
+ help
+ Add support for various XTX (XTX Technology Limited)
+ SPI flash chips (XT25xxx).
+
endif
config SPI_FLASH_USE_4K_SECTORS
diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 2b57797954..bdecb3b837 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -336,6 +336,14 @@ const struct flash_info spi_nor_ids[] = {
/* XMC (Wuhan Xinxin Semiconductor Manufacturing Corp.) */
{ INFO("XM25QH64A", 0x207017, 0, 64 * 1024, 128, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("XM25QH128A", 0x207018, 0, 64 * 1024, 256, SECT_4K |
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
+#endif
+#ifdef CONFIG_SPI_FLASH_XTX
+ /* XTX Technology (Shenzhen) Limited */
+ {
+ INFO("xt25f128b", 0x0b4018, 0, 64 * 1024, 256,
+SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ |
+SPI_NOR_HAS_LOCK | SPI_NOR_HAS_TB)
+ },
#endif
{ },
};
--
2.17.1
[PATCH v6 5/5] rockchip: px30: add support for SFC for Odroid Go Advance
From: Chris Morgan
The Odroid Go Advance uses a Rockchip Serial Flash Controller with an
XT25F128B SPI NOR flash chip. This adds support for both. Note that
while both the controller and chip support quad mode, only two lines
are connected to the chip. Changing the pinctrl to bus2 and setting tx
and rx lines to 2 for this reason.
Signed-off-by: Chris Morgan
Signed-off-by: Jon Lin
---
(no changes since v1)
arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 17 +
arch/arm/dts/rk3326-odroid-go2.dts | 16
2 files changed, 33 insertions(+)
diff --git a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
index 00767d2abd..741e8dd935 100644
--- a/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
+++ b/arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi
@@ -7,6 +7,15 @@
chosen {
u-boot,spl-boot-order =
};
+
+ aliases {
+ i2c0 =
+ i2c1 =
+ mmc0 =
+ serial1 =
+ serial2 =
+ spi0 =
+ };
};
{
@@ -57,6 +66,14 @@
u-boot,spl-fifo-mode;
};
+ {
+ u-boot,dm-pre-reloc;
+};
+
+_flash {
+ u-boot,dm-pre-reloc;
+};
+
{
clock-frequency = <2400>;
u-boot,dm-pre-reloc;
diff --git a/arch/arm/dts/rk3326-odroid-go2.dts
b/arch/arm/dts/rk3326-odroid-go2.dts
index 8cd4688c49..6f91f5040b 100644
--- a/arch/arm/dts/rk3326-odroid-go2.dts
+++ b/arch/arm/dts/rk3326-odroid-go2.dts
@@ -617,6 +617,22 @@
status = "okay";
};
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_clk _cs _bus2>;
+ status = "okay";
+
+ spi_flash: xt25f128b@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <10800>;
+ spi-rx-bus-width = <2>;
+ spi-tx-bus-width = <2>;
+ };
+};
+
{
status = "okay";
};
--
2.17.1
[PATCH v6 3/5] rockchip: px30: add the serial flash controller
From: Chris Morgan
Add the serial flash controller to the devicetree for the PX30.
Signed-off-by: Chris Morgan
Signed-off-by: Jon Lin
---
(no changes since v5)
Changes in v5:
- px30 use "rockchip, sfc" as compatible id
arch/arm/dts/px30.dtsi | 38 ++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/dts/px30.dtsi b/arch/arm/dts/px30.dtsi
index b6c79e7ed3..aaa8ae2235 100644
--- a/arch/arm/dts/px30.dtsi
+++ b/arch/arm/dts/px30.dtsi
@@ -960,6 +960,18 @@
status = "disabled";
};
+ sfc: sfc@ff3a {
+ compatible = "rockchip,sfc";
+ reg = <0x0 0xff3a 0x0 0x4000>;
+ interrupts = ;
+ clocks = < SCLK_SFC>, < HCLK_SFC>;
+ clock-names = "clk_sfc", "hclk_sfc";
+ pinctrl-names = "default";
+ pinctrl-0 = <_clk _cs _bus4>;
+ power-domains = < PX30_PD_MMC_NAND>;
+ status = "disabled";
+ };
+
gpu: gpu@ff40 {
compatible = "rockchip,px30-mali", "arm,mali-bifrost";
reg = <0x0 0xff40 0x0 0x4000>;
@@ -1926,6 +1938,32 @@
};
};
+ serial_flash {
+ sfc_bus4: sfc-bus4 {
+ rockchip,pins =
+ <1 RK_PA0 3 _pull_none>,
+ <1 RK_PA1 3 _pull_none>,
+ <1 RK_PA2 3 _pull_none>,
+ <1 RK_PA3 3 _pull_none>;
+ };
+
+ sfc_bus2: sfc-bus2 {
+ rockchip,pins =
+ <1 RK_PA0 3 _pull_none>,
+ <1 RK_PA1 3 _pull_none>;
+ };
+
+ sfc_cs: sfc-cs {
+ rockchip,pins =
+ <1 RK_PA4 3 _pull_none>;
+ };
+
+ sfc_clk: sfc-clk {
+ rockchip,pins =
+ <1 RK_PB1 3 _pull_none>;
+ };
+ };
+
lcdc {
lcdc_rgb_dclk_pin: lcdc-rgb-dclk-pin {
rockchip,pins =
--
2.17.1
[PATCH v6 2/5] rockchip: px30: Add support for using SFC
From: Chris Morgan
This patch adds support for setting the correct pin configuration
for the Rockchip Serial Flash Controller found on the PX30.
Signed-off-by: Chris Morgan
Signed-off-by: Jon Lin
---
(no changes since v1)
arch/arm/mach-rockchip/px30/px30.c | 64 ++
1 file changed, 64 insertions(+)
diff --git a/arch/arm/mach-rockchip/px30/px30.c
b/arch/arm/mach-rockchip/px30/px30.c
index 6fcef63c1b..be70d30cc8 100644
--- a/arch/arm/mach-rockchip/px30/px30.c
+++ b/arch/arm/mach-rockchip/px30/px30.c
@@ -51,6 +51,57 @@ struct mm_region *mem_map = px30_mem_map;
#define QOS_PRIORITY_LEVEL(h, l) h) & 3) << 8) | ((l) & 3))
+/* GRF_GPIO1AL_IOMUX */
+enum {
+ GPIO1A3_SHIFT = 12,
+ GPIO1A3_MASK= 0xf << GPIO1A3_SHIFT,
+ GPIO1A3_GPIO= 0,
+ GPIO1A3_FLASH_D3,
+ GPIO1A3_EMMC_D3,
+ GPIO1A3_SFC_SIO3,
+
+ GPIO1A2_SHIFT = 8,
+ GPIO1A2_MASK= 0xf << GPIO1A2_SHIFT,
+ GPIO1A2_GPIO= 0,
+ GPIO1A2_FLASH_D2,
+ GPIO1A2_EMMC_D2,
+ GPIO1A2_SFC_SIO2,
+
+ GPIO1A1_SHIFT = 4,
+ GPIO1A1_MASK= 0xf << GPIO1A1_SHIFT,
+ GPIO1A1_GPIO= 0,
+ GPIO1A1_FLASH_D1,
+ GPIO1A1_EMMC_D1,
+ GPIO1A1_SFC_SIO1,
+
+ GPIO1A0_SHIFT = 0,
+ GPIO1A0_MASK= 0xf << GPIO1A0_SHIFT,
+ GPIO1A0_GPIO= 0,
+ GPIO1A0_FLASH_D0,
+ GPIO1A0_EMMC_D0,
+ GPIO1A0_SFC_SIO0,
+};
+
+/* GRF_GPIO1AH_IOMUX */
+enum {
+ GPIO1A4_SHIFT = 0,
+ GPIO1A4_MASK= 0xf << GPIO1A4_SHIFT,
+ GPIO1A4_GPIO= 0,
+ GPIO1A4_FLASH_D4,
+ GPIO1A4_EMMC_D4,
+ GPIO1A4_SFC_CSN0,
+};
+
+/* GRF_GPIO1BL_IOMUX */
+enum {
+ GPIO1B1_SHIFT = 4,
+ GPIO1B1_MASK= 0xf << GPIO1B1_SHIFT,
+ GPIO1B1_GPIO= 0,
+ GPIO1B1_FLASH_RDY,
+ GPIO1B1_EMMC_CLKOUT,
+ GPIO1B1_SFC_CLK,
+};
+
/* GRF_GPIO1BH_IOMUX */
enum {
GPIO1B7_SHIFT = 12,
@@ -193,6 +244,19 @@ int arch_cpu_init(void)
GPIO1D4_SDMMC_D2 << GPIO1D4_SHIFT);
#endif
+#ifdef CONFIG_ROCKCHIP_SFC
+ rk_clrsetreg(>gpio1al_iomux,
+GPIO1A3_MASK | GPIO1A2_MASK | GPIO1A1_MASK | GPIO1A0_MASK,
+GPIO1A3_SFC_SIO3 << GPIO1A3_SHIFT |
+GPIO1A2_SFC_SIO2 << GPIO1A2_SHIFT |
+GPIO1A1_SFC_SIO1 << GPIO1A1_SHIFT |
+GPIO1A0_SFC_SIO0 << GPIO1A0_SHIFT);
+ rk_clrsetreg(>gpio1ah_iomux, GPIO1A4_MASK,
+GPIO1A4_SFC_CSN0 << GPIO1A4_SHIFT);
+ rk_clrsetreg(>gpio1bl_iomux, GPIO1B1_MASK,
+GPIO1B1_SFC_CLK << GPIO1B1_SHIFT);
+#endif
+
#endif
/* Enable PD_VO (default disable at reset) */
--
2.17.1
[PATCH v6 1/5] spi: rockchip_sfc: add support for Rockchip SFC
From: Chris Morgan This patch adds support for the Rockchip serial flash controller found on the PX30 SoC. It should work for versions 3-5 of the SFC IP, however I am only able to test it on v3. This is adapted from the WIP SPI-MEM driver for the SFC on mainline Linux. Note that the main difference between this and earlier versions of the driver is that this one does not support DMA. In testing the performance difference (performing a dual mode read on a 128Mb chip) is negligible. DMA, if used, must also be disabled in SPL mode when using A-TF anyway. Signed-off-by: Chris Morgan Signed-off-by: Jon Lin --- Changes in v6: - Fix dma transfer logic - Fix the error of the way to wait for dma transfer finished status Changes in v5: - Support dma transfer - Add CONFIG_IS_ENABLED(CLK) limitation - Support spinand devices - Support SFC ver4 ver5 - Using "rockchip, sfc" as compatible id - Get clock from the index to compatible with those case which's clock-names is not parsed Changes in v4: - None Changes in v3: - Added "rockchip_sfc_adjust_op_work()" function from proposed Linux driver to fix potential issue on hardware. Note I never noticed this issue while testing, so I cannot test if it fixed any specific issue for me. - Updated of-compatible string back to "rockchip,sfc" to match what is currently proposed for upstream driver. The hardware itself has multiple versions but a register is present in the hardware that is read by the driver to set version specific functionality. - Updated px30.dtsi and rk3266-odroid-go2.dts device-trees so that sfc nodes match what is in upstream. Changes in v2: - Resending due to glitch with patch file truncating final two lines on patch 1/5 and incorrect patch version number on patch 5/5. Changes in v1: - Reworked code to utilize spi-mem framework, and based it closely off of work in progress code for mainline Linux. - Removed DMA, as it didn't offer much performance benefit for booting (in my test cases), added complexity to the code, and interfered with A-TF. - Updated the names of the bindings to match the work in progress Linux code. - Moved alias to u-boot specific device-tree for Odroid Go Advance. Alias is updated with the spi0 node pointing to the SFC to help the sf command as well as facilitate booting from the SFC. - Note 2 below no longer applies, as rebasing this off of upstream code should allow the device to work for NAND, and by utilizing the spi-mem framework it no longer has to extract the parameters drivers/spi/Kconfig| 8 + drivers/spi/Makefile | 1 + drivers/spi/rockchip_sfc.c | 643 + 3 files changed, 652 insertions(+) create mode 100644 drivers/spi/rockchip_sfc.c diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig index 1494c91763..bef36f2931 100644 --- a/drivers/spi/Kconfig +++ b/drivers/spi/Kconfig @@ -312,6 +312,14 @@ config RENESAS_RPC_SPI on Renesas RCar Gen3 SoCs. This uses driver model and requires a device tree binding to operate. +config ROCKCHIP_SFC + bool "Rockchip SFC Driver" + help + Enable the Rockchip SFC Driver for SPI NOR flash. This device is + a limited purpose SPI controller for driving NOR flash on certain + Rockchip SoCs. This uses driver model and requires a device tree + binding to operate. + config ROCKCHIP_SPI bool "Rockchip SPI driver" help diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile index cfe4fae1d4..f02e84b5f1 100644 --- a/drivers/spi/Makefile +++ b/drivers/spi/Makefile @@ -52,6 +52,7 @@ obj-$(CONFIG_PIC32_SPI) += pic32_spi.o obj-$(CONFIG_PL022_SPI) += pl022_spi.o obj-$(CONFIG_SPI_QUP) += spi-qup.o obj-$(CONFIG_RENESAS_RPC_SPI) += renesas_rpc_spi.o +obj-$(CONFIG_ROCKCHIP_SFC) += rockchip_sfc.o obj-$(CONFIG_ROCKCHIP_SPI) += rk_spi.o obj-$(CONFIG_SANDBOX_SPI) += sandbox_spi.o obj-$(CONFIG_SPI_SIFIVE) += spi-sifive.o diff --git a/drivers/spi/rockchip_sfc.c b/drivers/spi/rockchip_sfc.c new file mode 100644 index 00..2d86f136f2 --- /dev/null +++ b/drivers/spi/rockchip_sfc.c @@ -0,0 +1,643 @@ +// SPDX-License-Identifier: GPL-2.0-only +/* + * Rockchip Serial Flash Controller Driver + * + * Copyright (c) 2017-2021, Rockchip Inc. + * Author: Shawn Lin + *Chris Morgan + *Jon Lin + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +/* System control */ +#define SFC_CTRL 0x0 +#define SFC_CTRL_PHASE_SEL_NEGETIVE BIT(1) +#define SFC_CTRL_CMD_BITS_SHIFT 8 +#define SFC_CTRL_ADDR_BITS_SHIFT 10 +#define SFC_CTRL_DATA_BITS_SHIFT 12 + +/* Interrupt mask */ +#define SFC_IMR0x4 +#define SFC_IMR_RX_FULL BIT(0) +#define SFC_IMR_RX_UFLOW BIT(1) +#define SFC_IMR_TX_OFLOW BIT(2) +#define SFC_IMR_TX_EMPTY BIT(3) +#define
[PATCH v6 0/5] rockchip_sfc: add support for Rockchip SFC
Changes in v6: - Fix dma transfer logic - Fix the error of the way to wait for dma transfer finished status Changes in v5: - Support dma transfer - Add CONFIG_IS_ENABLED(CLK) limitation - Support spinand devices - Support SFC ver4 ver5 - Using "rockchip, sfc" as compatible id - Get clock from the index to compatible with those case which's clock-names is not parsed - px30 use "rockchip, sfc" as compatible id Changes in v4: - None Changes in v3: - Added "rockchip_sfc_adjust_op_work()" function from proposed Linux driver to fix potential issue on hardware. Note I never noticed this issue while testing, so I cannot test if it fixed any specific issue for me. - Updated of-compatible string back to "rockchip,sfc" to match what is currently proposed for upstream driver. The hardware itself has multiple versions but a register is present in the hardware that is read by the driver to set version specific functionality. - Updated px30.dtsi and rk3266-odroid-go2.dts device-trees so that sfc nodes match what is in upstream. Changes in v2: - Resending due to glitch with patch file truncating final two lines on patch 1/5 and incorrect patch version number on patch 5/5. Changes in v1: - Reworked code to utilize spi-mem framework, and based it closely off of work in progress code for mainline Linux. - Removed DMA, as it didn't offer much performance benefit for booting (in my test cases), added complexity to the code, and interfered with A-TF. - Updated the names of the bindings to match the work in progress Linux code. - Moved alias to u-boot specific device-tree for Odroid Go Advance. Alias is updated with the spi0 node pointing to the SFC to help the sf command as well as facilitate booting from the SFC. - Note 2 below no longer applies, as rebasing this off of upstream code should allow the device to work for NAND, and by utilizing the spi-mem framework it no longer has to extract the parameters Chris Morgan (5): spi: rockchip_sfc: add support for Rockchip SFC rockchip: px30: Add support for using SFC rockchip: px30: add the serial flash controller mtd: spi-nor-ids: Add XTX XT25F128B rockchip: px30: add support for SFC for Odroid Go Advance arch/arm/dts/px30.dtsi | 38 ++ arch/arm/dts/rk3326-odroid-go2-u-boot.dtsi | 17 + arch/arm/dts/rk3326-odroid-go2.dts | 16 + arch/arm/mach-rockchip/px30/px30.c | 64 ++ drivers/mtd/spi/Kconfig| 6 + drivers/mtd/spi/spi-nor-ids.c | 8 + drivers/spi/Kconfig| 8 + drivers/spi/Makefile | 1 + drivers/spi/rockchip_sfc.c | 643 + 9 files changed, 801 insertions(+) create mode 100644 drivers/spi/rockchip_sfc.c -- 2.17.1
[PATCH 5/6] riscv: dts: add dts for unmatched rev1
The difference between unmatched rev3 and rev1 is DDR timing, the rev3
uses 1866 MT/s for 16GiB, and rev1 uses 2133 MT/s for 8GiB.
Signed-off-by: Zong Li
---
arch/riscv/dts/Makefile |2 +-
.../fu740-hifive-unmatched-a00-ddr-rev1.dtsi | 1489 +
.../dts/hifive-unmatched-a00-rev1-u-boot.dtsi |7 +
arch/riscv/dts/hifive-unmatched-a00-rev1.dts |4 +
4 files changed, 1501 insertions(+), 1 deletion(-)
create mode 100644 arch/riscv/dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi
create mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1-u-boot.dtsi
create mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 7778874831..7faeeaf664 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -4,7 +4,7 @@ dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
-dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
+dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
hifive-unmatched-a00-rev1.dtb
dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
targets += $(dtb-y)
diff --git a/arch/riscv/dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi
b/arch/riscv/dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi
new file mode 100644
index 00..0c4dedd166
--- /dev/null
+++ b/arch/riscv/dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi
@@ -0,0 +1,1489 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * (C) Copyright 2020 SiFive, Inc
+ */
+
+ {
+ sifive,ddr-params = <
+ 0x0a00 /* DENALI_CTL_00_DATA */
+ 0x /* DENALI_CTL_01_DATA */
+ 0x /* DENALI_CTL_02_DATA */
+ 0x /* DENALI_CTL_03_DATA */
+ 0x /* DENALI_CTL_04_DATA */
+ 0x /* DENALI_CTL_05_DATA */
+ 0x000b /* DENALI_CTL_06_DATA */
+ 0x00033f1e /* DENALI_CTL_07_DATA */
+ 0x00081dcb /* DENALI_CTL_08_DATA */
+ 0x0b200300 /* DENALI_CTL_09_DATA */
+ 0x1c1c0400 /* DENALI_CTL_10_DATA */
+ 0x04049a0d /* DENALI_CTL_11_DATA */
+ 0x32060406 /* DENALI_CTL_12_DATA */
+ 0x100d0823 /* DENALI_CTL_13_DATA */
+ 0x080a0a17 /* DENALI_CTL_14_DATA */
+ 0x0123b818 /* DENALI_CTL_15_DATA */
+ 0x00180b06 /* DENALI_CTL_16_DATA */
+ 0x00a01510 /* DENALI_CTL_17_DATA */
+ 0x01000118 /* DENALI_CTL_18_DATA */
+ 0x10032501 /* DENALI_CTL_19_DATA */
+ 0x /* DENALI_CTL_20_DATA */
+ 0x0101 /* DENALI_CTL_21_DATA */
+ 0x /* DENALI_CTL_22_DATA */
+ 0x0a00 /* DENALI_CTL_23_DATA */
+ 0x /* DENALI_CTL_24_DATA */
+ 0x01750100 /* DENALI_CTL_25_DATA */
+ 0x2069 /* DENALI_CTL_26_DATA */
+ 0x0005 /* DENALI_CTL_27_DATA */
+ 0x001a0007 /* DENALI_CTL_28_DATA */
+ 0x017f0300 /* DENALI_CTL_29_DATA */
+ 0x0301 /* DENALI_CTL_30_DATA */
+ 0x000b0f00 /* DENALI_CTL_31_DATA */
+ 0x04030200 /* DENALI_CTL_32_DATA */
+ 0x031f /* DENALI_CTL_33_DATA */
+ 0x00070004 /* DENALI_CTL_34_DATA */
+ 0x /* DENALI_CTL_35_DATA */
+ 0x /* DENALI_CTL_36_DATA */
+ 0x /* DENALI_CTL_37_DATA */
+ 0x /* DENALI_CTL_38_DATA */
+ 0x /* DENALI_CTL_39_DATA */
+ 0x /* DENALI_CTL_40_DATA */
+ 0x /* DENALI_CTL_41_DATA */
+ 0x /* DENALI_CTL_42_DATA */
+ 0x /* DENALI_CTL_43_DATA */
+ 0x /* DENALI_CTL_44_DATA */
+ 0x /* DENALI_CTL_45_DATA */
+ 0x /* DENALI_CTL_46_DATA */
+ 0x /* DENALI_CTL_47_DATA */
+ 0x /* DENALI_CTL_48_DATA */
+ 0x /* DENALI_CTL_49_DATA */
+ 0x /* DENALI_CTL_50_DATA */
+ 0x /* DENALI_CTL_51_DATA */
+ 0x /* DENALI_CTL_52_DATA */
+ 0x /* DENALI_CTL_53_DATA */
+ 0x /* DENALI_CTL_54_DATA */
+ 0x /* DENALI_CTL_55_DATA */
+ 0x /* DENALI_CTL_56_DATA */
+
[PATCH 6/6] board: sifive: support spl multi-dtb on unmatched board
There are two revisions of unmatched board with different DDR timing,
we'd like to support multi-dtb mechanism in SPL, then it selects the
right DTB at runtime according to PCB revision in I2C EEPROM.
Signed-off-by: Zong Li
---
board/sifive/unmatched/spl.c | 28 ++--
configs/sifive_unmatched_defconfig | 4
2 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c
index 5e1333b09a..74134b03ee 100644
--- a/board/sifive/unmatched/spl.c
+++ b/board/sifive/unmatched/spl.c
@@ -10,11 +10,14 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
#include
#include
+#include
#define GEM_PHY_RESET SIFIVE_GENERIC_GPIO_NR(0, 12)
@@ -26,6 +29,16 @@ int spl_board_init_f(void)
{
int ret;
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_MULTI_DTB_FIT)
+ int rescan;
+
+ ret = fdtdec_resetup();
+ if (!ret && rescan) {
+ dm_uninit();
+ dm_init_and_scan(true);
+ }
+#endif
+
ret = spl_soc_init();
if (ret) {
debug("HiFive Unmatched FU740 SPL init failed: %d\n", ret);
@@ -79,7 +92,18 @@ u32 spl_boot_device(void)
#ifdef CONFIG_SPL_LOAD_FIT
int board_fit_config_name_match(const char *name)
{
- /* boot using first FIT config */
- return 0;
+ /*
+* Apply different DDR params on different board revision.
+* Use PCB revision which is byte 0x7 in I2C platform EEPROM
+* to distinguish that.
+*/
+ if (get_pcb_revision_from_eeprom() == PCB_REVISION_REV3 &&
+ !strcmp(name, "hifive-unmatched-a00"))
+ return 0;
+ else if (get_pcb_revision_from_eeprom() != PCB_REVISION_REV3 &&
+!strcmp(name, "hifive-unmatched-a00-rev1"))
+ return 0;
+
+ return -1;
}
#endif
diff --git a/configs/sifive_unmatched_defconfig
b/configs/sifive_unmatched_defconfig
index 4c26504867..74b59738cd 100644
--- a/configs/sifive_unmatched_defconfig
+++ b/configs/sifive_unmatched_defconfig
@@ -40,3 +40,7 @@ CONFIG_USB=y
CONFIG_DM_USB=y
CONFIG_USB_XHCI_HCD=y
CONFIG_USB_XHCI_PCI=y
+CONFIG_SPL_MULTI_DTB_FIT=y
+CONFIG_SPL_MULTI_DTB_FIT_NO_COMPRESSION=y
+CONFIG_SPL_OF_LIST="hifive-unmatched-a00 hifive-unmatched-a00-rev1"
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x10
--
2.31.1
[PATCH 4/6] board: sifive: Add an interface to get PCB revision
There are different DDR parameter settings for different board
revisions. Add a new interface to get the PCB revision to determine
which DT should be selected at runtime.
Signed-off-by: Zong Li
---
arch/riscv/include/asm/arch-fu740/eeprom.h| 15 +
.../unmatched/hifive-platform-i2c-eeprom.c| 32 +++
2 files changed, 47 insertions(+)
create mode 100644 arch/riscv/include/asm/arch-fu740/eeprom.h
diff --git a/arch/riscv/include/asm/arch-fu740/eeprom.h
b/arch/riscv/include/asm/arch-fu740/eeprom.h
new file mode 100644
index 00..0e1220e558
--- /dev/null
+++ b/arch/riscv/include/asm/arch-fu740/eeprom.h
@@ -0,0 +1,15 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2021 SiFive, Inc.
+ *
+ * Zong Li
+ */
+
+#ifndef _ASM_RISCV_EEPROM_H
+#define _ASM_RISCV_EEPROM_H
+
+#define PCB_REVISION_REV3 0x3
+
+u8 get_pcb_revision_from_eeprom(void);
+
+#endif /* _ASM_RISCV_EEPROM_H */
diff --git a/board/sifive/unmatched/hifive-platform-i2c-eeprom.c
b/board/sifive/unmatched/hifive-platform-i2c-eeprom.c
index 9a62d32453..a2151f15e0 100644
--- a/board/sifive/unmatched/hifive-platform-i2c-eeprom.c
+++ b/board/sifive/unmatched/hifive-platform-i2c-eeprom.c
@@ -540,3 +540,35 @@ int mac_read_from_eeprom(void)
return 0;
}
+
+/**
+ * get_pcb_revision_from_eeprom - get the PCB revision
+ *
+ * Read the EEPROM to determine the board revision.
+ *
+ * This function is called before relocation, so we need to read a private
+ * copy of the EEPROM into a local variable on the stack.
+ */
+u8 get_pcb_revision_from_eeprom(void)
+{
+ struct __attribute__ ((__packed__)) board_eeprom {
+ u8 magic[MAGIC_NUMBER_BYTES];
+ u8 format_ver;
+ u16 product_id;
+ u8 pcb_revision;
+ } be;
+
+ int ret;
+ struct udevice *dev;
+
+ ret = i2c_get_chip_for_busnum(CONFIG_SYS_EEPROM_BUS_NUM,
+ CONFIG_SYS_I2C_EEPROM_ADDR,
+ 1,
+ );
+
+ if (!ret)
+ dm_i2c_read(dev, 0, (void *),
+ sizeof(struct board_eeprom));
+
+ return be.pcb_revision;
+}
--
2.31.1
[PATCH 3/6] riscv: sifive: fu740: Support i2c in spl
Enable SPL_I2C_SUPPORT for fu740, and add 'u-boot,dm-spl' property in
i2c node.
Signed-off-by: Zong Li
---
arch/riscv/cpu/fu740/Kconfig | 1 +
arch/riscv/dts/fu740-c000-u-boot.dtsi | 4
2 files changed, 5 insertions(+)
diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig
index 1dc052ba31..8e54310b9c 100644
--- a/arch/riscv/cpu/fu740/Kconfig
+++ b/arch/riscv/cpu/fu740/Kconfig
@@ -37,3 +37,4 @@ config SIFIVE_FU740
imply PWM_SIFIVE
imply DM_I2C
imply SYS_I2C_OCORES
+ imply SPL_I2C_SUPPORT
diff --git a/arch/riscv/dts/fu740-c000-u-boot.dtsi
b/arch/riscv/dts/fu740-c000-u-boot.dtsi
index a5d0688b06..a6f7a0873e 100644
--- a/arch/riscv/dts/fu740-c000-u-boot.dtsi
+++ b/arch/riscv/dts/fu740-c000-u-boot.dtsi
@@ -95,6 +95,10 @@
u-boot,dm-spl;
};
+ {
+ u-boot,dm-spl;
+};
+
{
assigned-clocks = < PRCI_CLK_GEMGXLPLL>;
assigned-clock-rates = <125125000>;
--
2.31.1
[PATCH 1/6] board: sifive: unmatched: add initial support for a platform ID EEPROM
Add initial support for the PCB description EEPROM for SiFive HiFive
Unmatched boards.
This implementation is refactored based on Paul Walmsley's porting and
adopt the suggestions from David Abdurachmanov.
Signed-off-by: Paul Walmsley
Signed-off-by: David Abdurachmanov
Signed-off-by: Zong Li
---
board/sifive/unmatched/Makefile | 1 +
.../unmatched/hifive-platform-i2c-eeprom.c| 542 ++
include/configs/sifive-unmatched.h| 6 +
3 files changed, 549 insertions(+)
create mode 100644 board/sifive/unmatched/hifive-platform-i2c-eeprom.c
diff --git a/board/sifive/unmatched/Makefile b/board/sifive/unmatched/Makefile
index 6308c80d64..e00b330e8c 100644
--- a/board/sifive/unmatched/Makefile
+++ b/board/sifive/unmatched/Makefile
@@ -3,6 +3,7 @@
# Copyright (c) 2020-2021 SiFive, Inc
obj-y += unmatched.o
+obj-$(CONFIG_ID_EEPROM) += hifive-platform-i2c-eeprom.o
ifdef CONFIG_SPL_BUILD
obj-y += spl.o
diff --git a/board/sifive/unmatched/hifive-platform-i2c-eeprom.c
b/board/sifive/unmatched/hifive-platform-i2c-eeprom.c
new file mode 100644
index 00..9a62d32453
--- /dev/null
+++ b/board/sifive/unmatched/hifive-platform-i2c-eeprom.c
@@ -0,0 +1,542 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 SiFive, Inc.
+ *
+ * Based on board/freescale/common/sys_eeprom.c:
+ * Copyright 2006, 2008-2009, 2011 Freescale Semiconductor
+ * York Sun (york...@freescale.com)
+ * Haiying Wang (haiying.w...@freescale.com)
+ * Timur Tabi (ti...@freescale.com)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifndef CONFIG_SYS_EEPROM_BUS_NUM
+#error Requires CONFIG_SYS_EEPROM_BUS_NUM to be defined
+#endif
+
+#define FORMAT_VERSION 0x1
+
+/* Options for the manuf_test_status field */
+#define SIFIVE_MANUF_TEST_STATUS_UNKNOWN 0
+#define SIFIVE_MANUF_TEST_STATUS_PASS 1
+#define SIFIVE_MANUF_TEST_STATUS_FAIL 2
+
+/*
+ * BYTES_PER_EEPROM_PAGE: the AT24C02 datasheet says that data can
+ * only be written in page mode, which means 8 bytes at a time
+ */
+#define BYTES_PER_EEPROM_PAGE 8
+
+/*
+ * EEPROM_WRITE_DELAY_MS: the AT24C02 datasheet says it takes up to
+ * 5ms to complete a given write
+ */
+#define EEPROM_WRITE_DELAY_MS 5000
+
+/*
+ * MAGIC_NUMBER_BYTES: number of bytes used by the magic number
+ */
+#define MAGIC_NUMBER_BYTES 4
+
+/*
+ * SERIAL_NUMBER_BYTES: number of bytes used by the board serial
+ * number
+ */
+#define SERIAL_NUMBER_BYTES16
+
+/*
+ * MAC_ADDR_BYTES: number of bytes used by the Ethernet MAC address
+ */
+#define MAC_ADDR_BYTES 6
+
+/*
+ * MAC_ADDR_STRLEN: length of mac address string
+ */
+#define MAC_ADDR_STRLEN17
+
+/*
+ * SiFive OUI. Registration Date is 2018-02-15
+ */
+#define SIFIVE_OUI_PREFIX "70:B3:D5:92:F"
+
+/**
+ * static eeprom: EEPROM layout for the SiFive platform I2C format
+ */
+static struct __attribute__ ((__packed__)) sifive_eeprom {
+ u8 magic[MAGIC_NUMBER_BYTES];
+ u8 format_ver;
+ u16 product_id;
+ u8 pcb_revision;
+ u8 bom_revision;
+ u8 bom_variant;
+ u8 serial[SERIAL_NUMBER_BYTES];
+ u8 manuf_test_status;
+ u8 mac_addr[MAC_ADDR_BYTES];
+ u32 crc;
+} e;
+
+struct sifive_product {
+ u16 id;
+ const char *name;
+};
+
+/* Set to 1 if we've read EEPROM into memory */
+static int has_been_read;
+
+/* Magic number at the first four bytes of EEPROM */
+static const unsigned char magic[MAGIC_NUMBER_BYTES] = { 0xf1, 0x5e, 0x50,
0x45 };
+
+/* Does the magic number match that of a SiFive EEPROM? */
+static inline int is_match_magic(void)
+{
+ return (memcmp(, , MAGIC_NUMBER_BYTES) == 0);
+}
+
+/* Calculate the current CRC */
+static inline u32 calculate_crc32(void)
+{
+ return crc32(0, (void *), sizeof(struct sifive_eeprom) -
sizeof(e.crc));
+}
+
+/* This function should be called after each update to the EEPROM structure */
+static inline void update_crc(void)
+{
+ e.crc = calculate_crc32();
+}
+
+static struct sifive_product sifive_products[] = {
+ { 0, "Unknown"},
+ { 2, "HiFive Unmatched" },
+};
+
+/**
+ * dump_raw_eeprom - display the raw contents of the EEPROM
+ */
+static void dump_raw_eeprom(void)
+{
+ unsigned int i;
+
+ printf("EEPROM dump: (0x%lx bytes)\n", sizeof(e));
+ for (i = 0; i < sizeof(e); i++) {
+ if ((i % 16) == 0)
+ printf("%02X: ", i);
+ printf("%02X ", ((u8 *))[i]);
+ if (((i % 16) == 15) || (i == sizeof(e) - 1))
+ printf("\n");
+ }
+}
+
+/**
+ * show_eeprom - display the contents of the EEPROM
+ */
+static void show_eeprom(void)
+{
+ unsigned int i;
+ u32 crc;
+ const char *product_name = "Unknown";
+ char
[PATCH 2/6] riscv: sifive: fu740: kconfig: Enable support for Opencores I2C controller
Enable the Opencores I2C controller on FU740 Signed-off-by: Zong Li --- arch/riscv/cpu/fu740/Kconfig | 2 ++ board/sifive/unmatched/Kconfig | 1 + 2 files changed, 3 insertions(+) diff --git a/arch/riscv/cpu/fu740/Kconfig b/arch/riscv/cpu/fu740/Kconfig index 3a5f6e47f5..1dc052ba31 100644 --- a/arch/riscv/cpu/fu740/Kconfig +++ b/arch/riscv/cpu/fu740/Kconfig @@ -35,3 +35,5 @@ config SIFIVE_FU740 imply SIFIVE_OTP imply DM_PWM imply PWM_SIFIVE + imply DM_I2C + imply SYS_I2C_OCORES diff --git a/board/sifive/unmatched/Kconfig b/board/sifive/unmatched/Kconfig index 88b5883cae..fb2c1fbb58 100644 --- a/board/sifive/unmatched/Kconfig +++ b/board/sifive/unmatched/Kconfig @@ -47,5 +47,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy imply PHY_MSCC imply SYSRESET imply SYSRESET_GPIO + imply CMD_I2C endif -- 2.31.1
[PATCH 0/6] Support multi-dtb in SPL on Unmatched board
This patch set contains the support I2C platform EEPROM and multi-dtb mechanism on Unmatched board. There are two revisions of Unmatched with different DDR timing respectively, so we'd like to support multi-dtb in SPL, then it can select the right DTB at runtime according to PCB revision in I2C EEPROM to initialize the right DDR timing. The I2C EEPROM support is refactored based on Paul Welmsley's porting and adopt many suggestions from David Abdurachmanov. Zong Li (6): board: sifive: unmatched: add initial support for a platform ID EEPROM riscv: sifive: fu740: kconfig: Enable support for Opencores I2C controller riscv: sifive: fu740: Support i2c in spl board: sifive: Add an interface to get PCB revision riscv: dts: add dts for unmatched rev1 board: sifive: support spl multi-dtb on unmatched board arch/riscv/cpu/fu740/Kconfig |3 + arch/riscv/dts/Makefile |2 +- arch/riscv/dts/fu740-c000-u-boot.dtsi |4 + .../fu740-hifive-unmatched-a00-ddr-rev1.dtsi | 1489 + .../dts/hifive-unmatched-a00-rev1-u-boot.dtsi |7 + arch/riscv/dts/hifive-unmatched-a00-rev1.dts |4 + arch/riscv/include/asm/arch-fu740/eeprom.h| 15 + board/sifive/unmatched/Kconfig|1 + board/sifive/unmatched/Makefile |1 + .../unmatched/hifive-platform-i2c-eeprom.c| 574 +++ board/sifive/unmatched/spl.c | 28 +- configs/sifive_unmatched_defconfig|4 + include/configs/sifive-unmatched.h|6 + 13 files changed, 2135 insertions(+), 3 deletions(-) create mode 100644 arch/riscv/dts/fu740-hifive-unmatched-a00-ddr-rev1.dtsi create mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1-u-boot.dtsi create mode 100644 arch/riscv/dts/hifive-unmatched-a00-rev1.dts create mode 100644 arch/riscv/include/asm/arch-fu740/eeprom.h create mode 100644 board/sifive/unmatched/hifive-platform-i2c-eeprom.c -- 2.31.1
Re: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default value
On Wed, 2021-06-30 at 12:44 +, Wasim Khan (OSS) wrote:
>
>
> > -Original Message-
> > From: Bedel, Alban
> > Sent: Wednesday, June 30, 2021 6:03 PM
> > To: Priyanka Jain ; Varun Sethi <
> > v.se...@nxp.com>;
> > Wasim Khan ; Wasim Khan (OSS)
> >
> > Cc: u-boot@lists.denx.de
> > Subject: Re: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default
> > value
> >
> > On Wed, 2021-06-30 at 11:12 +, Priyanka Jain wrote:
> > >
> > > snip
>
> >
> > * After issuing `env default -a ; saveenv' the board didn't boot
> > anymore because `bootcmd` was then empty.
>
> This is not the case with latest u-boot code. 'env default -a' set
> bootcmd to default one (run distro_bootcmd).
> So, we are safe here.
>
>
> >
> > * If redundant env on eMMC was enabled `bootcmd` was then overwritten
> > at every boot, preventing me from using a custom `bootcmd` at all.
> >
>
> Priyanka, Alban
> Can you help me to understand what does enabling 'redundant env' on
> eMMC mean and how to enable it ?
See env/Kconfig:
config SYS_REDUNDAND_ENVIRONMENT
bool "Enable redundant environment support"
depends on ENV_IS_IN_EEPROM || ENV_IS_IN_FLASH || ENV_IS_IN_MMC || \
ENV_IS_IN_NAND || ENV_IS_IN_SPI_FLASH || ENV_IS_IN_UBI
help
Normally, the environemt is stored in a single location. By
selecting this option, you can then define where to hold a redundant
copy of the environment data, so that there is a valid backup copy in
case there is a power failure during a "saveenv" operation.
When this option is enabled the internals of the env change
significantly and the old code then always detected the env as being
the default, erasing any previously user set value at every boot.
But beside the fact that it didn't work properly with all
configurations, the old code didn't really detect if the env was the
default. When it worked, it detected the case where no valid env was
stored and u-boot was using its internal in-memory defaults. That's why
resetting the env to default would then break the boot.
In my patch I replaced this logic by looking if `bootcmd` has the
default value, which worked well as long as the default value was
"unset". But as we see this is not a viable solution in the long run.
My suggestion would be to have something like this:
if (env_get_yesno("fsl_bootcmd_set") <= 0) {
// Set the default bootcmd according to the boot device
...
env_set("fsl_bootcmd_set", "y");
}
That way it doesn't matter what the default value of `bootcmd` is and
boards also have the possibility to disable this code by setting
`fsl_bootcmd_set` to `y` in their default env.
I think it would also make sense to have some code that set the TF-A
boot device in the env, that might allow handling this in the boot
scripts directly instead of all this hard coded logic.
Alban
Re: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default value
On Wed, 2021-06-30 at 11:12 +, Priyanka Jain wrote: > > > > -Original Message- > > From: Wasim Khan > > Sent: Friday, June 25, 2021 2:40 PM > > To: Bedel, Alban ; Priyanka Jain > > ; Varun Sethi ; Wasim Khan > > (OSS) > > > > Cc: u-boot@lists.denx.de > > Subject: RE: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default > > value > > > > Hi Alban, > > > > > -Original Message- > > > From: Bedel, Alban > > > Sent: Wednesday, June 23, 2021 6:38 PM > > > To: Priyanka Jain ; Varun Sethi > > > ; Wasim Khan (OSS) > > > Cc: u-boot@lists.denx.de; Wasim Khan > > > Subject: Re: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd > > > default > > > value > > > > > > On Wed, 2021-06-16 at 14:19 +0200, Wasim Khan wrote: > > > > From: Wasim Khan > > > > > > > > NXP platforms expect bootcmd and mcinitcmd to be updated as per > > > > boot > > > > source. > > > > > > > > commit cbf77d201870f2d12227e2d95718a416b16ec98b breaks this > > behaviour. > > > > Revert commit cbf77d201870f2d12227e2d95718a416b16ec98b > > > > > > As I already explained in the prior exchanges we had, I'm fully > > > convinced that reverting this patch is not the solution to your > > > problem. Please see the log of my patch for a full explanation, > > > but > > > basically the old code not only rely on the a broken assumption, > > > it also fails to > > implement it correctly. > > > > > > The current code set `bootcmd` and `mcinicmd` only if they are > > > not set > > > which a simple and sane behaviour. > > > > > > As I have explained earlier that the bootcmd is always set with > > default value as " > > run distro_bootcmd". > > So fsl_setenv_bootcmd() never gets executed which is causing the > > issue. > > > > > > > When I submitted my patch these variables were not set in the > > > default > > > so I suspect that another patch now set these in the default env. > > > > I hard reset my tree to your commit and I still see the issue. > > Please refer to below logs. I don’t see any other patch causing > > this issue. Would > > let @Priyanka Jain to share her comments. > > > > > > U-Boot 2021.01-rc3-00115-gcbf77d2018 (Jun 25 2021 - 10:51:56 +0200) > > SoC: LX2160ACE Rev2.0 (0x87360020) > > ... > > ... > > MMC: FSL_SDHC: 0, FSL_SDHC: 1 > > Loading Environment from SPIFlash... SF: Detected mt35xu512aba with > > page size > > 256 Bytes, erase size 128 KiB, total 64 MiB > > *** Warning - bad CRC, using default environment > > > > EEPROM: NXID v1 > > ... > > ... > > => pri bootcmd > > bootcmd=run distro_bootcmd > > > > Regards, > > Wasim > > > > > > > > Alban > > > > Alban, Wasim, > > Lets try to fix both issues. One being faced by Alban and the one > faced by Wasim. > Alban , > Can you please provide summary of the issues faced by you. The issue I faced are well describe in my original patch, but I'll sum them up again here: * After issuing `env default -a ; saveenv' the board didn't boot anymore because `bootcmd` was then empty. * If redundant env on eMMC was enabled `bootcmd` was then overwritten at every boot, preventing me from using a custom `bootcmd` at all. A typical u-boot build is configured at build time for a specific boot device, but with TF-A there is a single build for all boot devices and u-boot then have configure the default boot device on the first boot. This is where the code we are discussing here come into play. Back when I submitted my patch the default env didn't define `bootcmd` in my build, so I took that as the way to detect that `bootcmd` need to be initialised. We could instead just use another env variable to mark if `bootcmd` has been initialised or not. Alban
[PATCH v2] efi_loader: Improve the parameter check for QueryVariableInfo()
Improve efi_query_variable_info() to check the parameter settings and
return correct error code according to the UEFI Specification 2.9,
and the Self Certification Test (SCT) II Case Specification, June
2017, chapter 4.1.4 QueryVariableInfo().
Signed-off-by: Masami Hiramatsu
Reported-by: Kazuhiko Sakamoto
---
Changes in v2:
- Add a reference to SCT 2 spec.
- Fix checkpatch.pl warnings.
- Simplify the check according to Henrich's comments.
---
lib/efi_loader/efi_var_common.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index 83479dd142..3d92afe2eb 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -163,6 +163,19 @@ efi_status_t EFIAPI efi_query_variable_info(
EFI_ENTRY("%x %p %p %p", attributes, maximum_variable_storage_size,
remaining_variable_storage_size, maximum_variable_size);
+ if (!maximum_variable_storage_size ||
+ !remaining_variable_storage_size ||
+ !maximum_variable_size ||
+ !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS))
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+
+ if ((attributes & ~(u32)EFI_VARIABLE_MASK) ||
+ (attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) ||
+ (attributes & EFI_VARIABLE_HARDWARE_ERROR_RECORD) ||
+ (!IS_ENABLED(CONFIG_EFI_SECURE_BOOT) &&
+(attributes & EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS)))
+ return EFI_EXIT(EFI_UNSUPPORTED);
+
ret = efi_query_variable_info_int(attributes,
maximum_variable_storage_size,
remaining_variable_storage_size,
Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
On Wed, Jun 30, 2021 at 05:31:44PM +0300, Ivaylo Dimitrov wrote: > Hi, > > On 30.06.21 г. 16:33 ч., Tom Rini wrote: > > On Wed, Jun 30, 2021 at 10:30:20AM +0300, Ivaylo Dimitrov wrote: > > > Hi, > > > > > > On 26.06.21 г. 17:58 ч., Tom Rini wrote: > > > > On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote: > > > > > Hi Tom, Marek, > > > > > > > > > > On 25/06/2021 23:59, Tom Rini wrote: > > > > > > On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote: > > > > > > > On Friday 25 June 2021 17:37:44 Tom Rini wrote: > > > > > > > > One thing I want to say here as I think it maybe wasn't clear > > > > > > > > in Marek's > > > > > > > > suggestion. Why not have X-Loader boot SPL which loads U-Boot > > > > > > > > from extN > > > > > > > > on the eMMC? > > > > > > > > > > > > > > Hello Tom! I have already answered this in my previous email. > > > > > > > > > > > > I just re-read things and I don't see it. But perhaps I'm not being > > > > > > clear enough. Why can't you just have NOLO start SPL, not > > > > > > re-initialize > > > > > > things (which is a really common case now thanks to aarch64) and > > > > > > just > > > > > > use that to load full U-Boot from a not size restricted place? > > > > > > > > > > > > > > > > I think there are a few problems. > > > > > > > > > > 1. One is a practical one, from Pali's email: > > > > > > > > > > > There is no easy access to eMMC until you start full U-Boot. So > > > > > > even if all these problems are solved then "bootstrapping" or > > > > > > flashing U-Boot into such location is not possible, plus there is > > > > > > no recovery. Plus this loose existing and working operating system, > > > > > > which is no-go. So this way is basically undebugable and therefore > > > > > > perfectly hard to develop. > > > > > > > > > > Not being able to access the eMMC to write u-boot until u-boot is > > > > > started does sound like it would make things a bit more tricky. > > > > > > > > I don't understand this. Either way it's drivers/mmc/omap_hsmmc.c. > > > > > > > > > 2. According to Pali, adding SPL support would not be a trivial task, > > > > > and might end up with a lot more "#ifdef"s in SPL than the one in > > > > > Ivaylo's patch. As I understand it, this hypothetical SPL would mostly > > > > > not do any hardware initialisation on the N900, so that might be where > > > > > instead hacks would need to be added to SPL. > > > > > > > > > > Pali also wrote: > > > > > > > > > > > U-Boot for N900 does not use SPL. There is no SPL code implemented. > > > > > > Nobody ever tried to implement it and neither tested. As you have > > > > > > correctly pointed instead of SPL is used vendor X-Loader binary, > > > > > > which > > > > > > is signed by RSA key. > > > > > And when I asked him today: > > > > > > > > > > > 12:11 < Pali> in past (10 years ago?) I was investigating the way > > > > > > how we can boot u-boot and the only reasable way was the current > > > > > > one, directly load main u-boot by x-loader/nolo > > > > > > 12:12 < Pali> I have already spend some time with spl on n900 and > > > > > > at that time I have rejected this idea, because it did not work that > > > > > > 12:13 < Pali> spl is also doing hw initialization which cannot be > > > > > > called on n900 as this code basically crash / freeze n900 > > > > > So perhaps it would make sense to get more clarity on that, since that > > > > > seems to be where the argument gets stuck. > > > > > > > > This also doesn't make sense to me. CONFIG_SKIP_LOWLEVEL_INIT should > > > > let you skip whatever initialization doesn't need to be done. If > > > > there's some init that needs to be skipped but isn't, that's a bug. > > > > > > > > > Also, I'd like to point what Ivaylo wrote earlier: > > > > > > > > > > > > This sounds like a workaround though. Can you instead do the full > > > > > > > conversion of the board? I am sure the board removal patch can be > > > > > > > postponed if there is plan to convert it. > > > > > > > > > > > > Hard to say if migration to device-tree is even possible on N900 > > > > > > ATM, enabling OF_CONTROL increases the size of the produced binary > > > > > > with some 100k (.dtb not included), making the size of the binary > > > > > > way above our budget of ~256k. Sure, board config does not enable > > > > > > -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and > > > > > > noone can guarantee we're not going to see SIGILL faults if we > > > > > > enable it. Which it seems we are forced to do even with DM_USB > > > > > > migration only. > > > > > > > > > > > > Re workaround - I took examples of #ifdef's from the current u-boot > > > > > > code (mmc, i2c, etc.) so workaround or not, it is no different to > > > > > > what the other drivers are doing. > > > > > > > > > > If the other drivers have the same logic, it seems a bit weird to me > > > > > that the change made in Ivaylo's patch would be rejected because of a > >
Re: [PATCH] efi_loader: Improve the parameter check for QueryVariableInfo()
2021年7月1日(木) 0:30 Heinrich Schuchardt :
>
> On 6/30/21 5:07 PM, Masami Hiramatsu wrote:
> > Hi Heinrich,
> >
> > 2021年6月30日(水) 23:55 Heinrich Schuchardt :
> >
> This does not catch attributes == EFI_VARIABLE_NON_VOLATILE where test
> case 5.2.1.4.5 requires EFI_INVALID_PARAMETER.
> >>>
> >>> Hmm, but this could pass the SCT runtime test.
> >>> So attributes == EFI_VARIABLES_NON_VOLATILE should fail?
> >>> Actually, I referred to the VariableServiceQueryVariableInfo()@EDK2
> >>> and UEFI spec,
> >>> and I couldn't see such conditions.
> >>
> >> The SCT specification requires in 5.2.1.4.5.:
> >>
> >> "1. Call QueryVariableInfoservice with the Attributes:
> >>
> >> * EFI_VARIABLE_NON_VOLATILE
> >> * EFI_VARIABLE_RUNTIME_ACCESS
> >> * EFI_VARIABLE_NON_VOLATILE|EFI_VARIABLE_RUNTIME_ACCESS
> >>
> >> The returned code must be EFI_INVALID_PARAMETER."
> >
> > Ah, I see. so either NON_VOLATILE and RUNTIME_ACCESS must be used with
> > BOOTSERVICE_ACCESS.
> >
> >>
> >> See patch
> >>
> >> [PATCH edk2-test 1/1] uefi-sct/SctPkg: uefi-sct:
> >> QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE)
> >> https://edk2.groups.io/g/devel/message/77367
> >>
> >>>
>
> Shouldn't we check
>
> !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)
>
> instead?
> >>>
> >>> Ah, right, because this function is only used for the bootservice.
> >>> (I found that runtime service uses another function)
> >>
> >> A variable without EFI_VARIABLE_BOOTSERVICE_ACCESS could neither be
> >> accessed before nor after ExitBootServices(). So this has to be invalid.
> >
> > OK, so BOOTSERVICE_ACCESS is required.
> > Hmm, but in that case, if we confirm BOOTSERVICE_ACCESS bit is set,
> > should we still need to check NON_VOLATILE and RUNTIME_ACCESS?
> >
> > I mean
> >
> > if (!(attr & BOOTSERVICE_ACCESS))
> > return INVALID_PARAM;
> > else if (...) /* at this point, attr must have the BOOTSERVICE_ACCESS */
> >
> > Thus, attributes shouldn't be equal to any of;
> >
> >> * EFI_VARIABLE_NON_VOLATILE
> >> * EFI_VARIABLE_RUNTIME_ACCESS
> >> * EFI_VARIABLE_NON_VOLATILE|EFI_VARIABLE_RUNTIME_ACCESS
> >
> > So, I think we only need
> > " !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)"
> > this check.
>
> That is why I proposed this line. It covers all three test cases.
Ah, thanks for the confirmation. OK, I'll fix with it.
Best regards,
>
> Best regards
>
> Heinrich
>
> >>
> >>>
>
> > + ret = EFI_INVALID_PARAMETER;
> > + } else if ((attributes & (EFI_VARIABLE_NON_VOLATILE |
> > EFI_VARIABLE_HARDWARE_ERROR_RECORD)) ==
> > EFI_VARIABLE_HARDWARE_ERROR_RECORD) {
> > + /* HW error occurs only on non-volatile variables */
>
> We don't support EFI_VARIABLE_HARDWARE_ERROR_RECORD at all. So shouldn't
> flag EFI_VARIABLE_HARDWARE_ERROR_RECORD result in EFI_UNSUPPORTED?
> >>>
> >>> OK, I'll do.
> >>>
> >>> BTW, from the UEFI spec, EFI_VARIABLE_APPEND_WRITE should be ignored
> >>> in the QueryVariableInfo because that flag is used for SetVariables
> >>> (as overwrite flag).
> >>> Thus, if attributes == EFI_VARIABLE_APPEND_WRITE, should we return
> >>> EFI_INVALID_PARAMETER?
> >>>
>
> > + ret = EFI_INVALID_PARAMETER;
> > + } else {
> > + ret = efi_query_variable_info_int(attributes,
> > maximum_variable_storage_size,
> >
> > remaining_variable_storage_size,
> > maximum_variable_size);
>
> CHECK: Alignment should match open parenthesis
> #44: FILE: lib/efi_loader/efi_var_common.c:184:
> + ret = efi_query_variable_info_int(attributes,
>
> maximum_variable_storage_size,
> >>>
> >>> OK, let me fix that.
> >>>
> >>> Thank you,
> >>>
>
> Best regards
>
> Heinrich
>
> > + }
> >
> > return EFI_EXIT(ret);
> > }
> >
>
> >>>
> >>>
> >>> --
> >>> Masami Hiramatsu
> >>>
> >>
> >
> >
>
--
Masami Hiramatsu
Re: buildman error
On 30/06/2021 14:07, Wasim Khan wrote: > I am using latest u-boot code and trying to run buildman with my local patch > for lx2160 platform on master branch. > Getting below error . > > u-boot$ ./tools/buildman/buildman --list-tool-chains > aarch64 : > /opt/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc > arm : > /opt/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc > > > u-boot$ ./tools/buildman/buildman -b master lx2160ardb -ve > Building 2 commits for 3 boards (3 threads, 3 jobs per thread) > 000 /6 -6 (starting)Thread exception: git checkout > (['git', '--git-dir', '../master/.bm-work/02/.git', '--work-tree', > '../master/.bm-work/02', 'checkout', '-f', > '3ef4572110a43acdd7d401b0cb184c6ebd6eaa17']): fatal: not a git repository: > u-boot/.git/worktrees/-2 > > Thread exception: git checkout (['git', '--git-dir', > '../master/.bm-work/00/.git', '--work-tree', '../master/.bm-work/00', > 'checkout', '-f', '3ef4572110a43acdd7d401b0cb184c6ebd6eaa17']): fatal: not a > git repository: u-boot/.git/worktrees/- > > Thread exception: git checkout (['git', '--git-dir', > '../master/.bm-work/01/.git', '--work-tree', '../master/.bm-work/01', > 'checkout', '-f', '3ef4572110a43acdd7d401b0cb184c6ebd6eaa17']): fatal: not a > git repository: -boot/.git/worktrees/-1 > I get the same error when I manually delete the u-boot/.git/worktrees/-* directories, but can't think of why those would be deleted during normal operation. If you delete the ../master/.bm-work/* directories it should start working again. > Completed: 6 total built > Failed: 3 thread exceptions > > Regards, > Wasim >
[PATCH v2 2/2] efi_loader: clear OsIndications
After each reboot we must clear flag
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in variable
OsIndications.
Signed-off-by: Heinrich Schuchardt
---
v2:
update OsIndications after handling all capsules
---
lib/efi_loader/efi_setup.c | 33 +
1 file changed, 33 insertions(+)
diff --git a/lib/efi_loader/efi_setup.c b/lib/efi_loader/efi_setup.c
index 3c5cf9a435..ca865c5a99 100644
--- a/lib/efi_loader/efi_setup.c
+++ b/lib/efi_loader/efi_setup.c
@@ -5,9 +5,12 @@
* Copyright (c) 2016-2018 Alexander Graf et al.
*/
+#define LOG_CATEGORY LOGC_EFI
+
#include
#include
#include
+#include
#define OBJ_LIST_NOT_INITIALIZED 1
@@ -171,6 +174,32 @@ static efi_status_t efi_init_os_indications(void)
_indications_supported, false);
}
+static efi_status_t efi_clear_os_indications(void)
+{
+ efi_uintn_t size;
+ u64 os_indications;
+ efi_status_t ret;
+
+ /* Clear EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED */
+ size = sizeof(os_indications);
+ ret = efi_get_variable_int(L"OsIndications", _global_variable_guid,
+ NULL, , _indications, NULL);
+ if (ret != EFI_SUCCESS)
+ os_indications = 0;
+ else
+ os_indications &=
+ ~EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED;
+ ret = efi_set_variable_int(L"OsIndications", _global_variable_guid,
+ EFI_VARIABLE_NON_VOLATILE |
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS,
+ sizeof(os_indications), _indications,
+ false);
+ if (ret != EFI_SUCCESS)
+ log_err("Setting %ls failed\n", L"OsIndications");
+ return EFI_SUCCESS;
+}
+
/**
* efi_init_obj_list() - Initialize and populate EFI object list
*
@@ -291,6 +320,10 @@ efi_status_t efi_init_obj_list(void)
if (IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK) &&
!IS_ENABLED(CONFIG_EFI_CAPSULE_ON_DISK_EARLY))
ret = efi_launch_capsules();
+ if (ret != EFI_SUCCESS)
+ goto out;
+
+ ret = efi_clear_os_indications();
out:
efi_obj_list_initialized = ret;
return ret;
--
2.30.2
[PATCH v2 1/2] efi_loader: fix set_capsule_result()
The log category must be LOG_CATEGORY LOGC_EFI.
efi_set_variable() should be called with EFI_CALL(). Use
efi_set_variable_int() instead.
A log text "Updating ..." if SetVariable() fails does not make sense for a
variable that is not required to be preexisting.
CapsuleLast should always be immediately updated.
Signed-off-by: Heinrich Schuchardt
---
v2:
don't update OsIndications in set_capsule_result()
update CapsuleLast immediately
---
lib/efi_loader/efi_capsule.c | 39 +++-
1 file changed, 21 insertions(+), 18 deletions(-)
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index 2c37a0d97b..f87ef2a514 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -6,6 +6,8 @@
* Author: AKASHI Takahiro
*/
+#define LOG_CATEGORY LOGC_EFI
+
#include
#include
#include
@@ -95,13 +97,25 @@ void set_capsule_result(int index, struct
efi_capsule_header *capsule,
else
memset(_processed, 0, sizeof(time));
result.capsule_status = return_status;
- ret = efi_set_variable(variable_name16, _guid_capsule_report,
- EFI_VARIABLE_NON_VOLATILE |
- EFI_VARIABLE_BOOTSERVICE_ACCESS |
- EFI_VARIABLE_RUNTIME_ACCESS,
- sizeof(result), );
- if (ret)
- log_err("EFI: creating %ls failed\n", variable_name16);
+ ret = efi_set_variable_int(variable_name16, _guid_capsule_report,
+ EFI_VARIABLE_NON_VOLATILE |
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS,
+ sizeof(result), , false);
+ if (ret != EFI_SUCCESS) {
+ log_err("Setting %ls failed\n", variable_name16);
+ return;
+ }
+
+ /* Variable CapsuleLast must not include terminating 0x */
+ ret = efi_set_variable_int(L"CapsuleLast", _guid_capsule_report,
+ EFI_VARIABLE_READ_ONLY |
+ EFI_VARIABLE_NON_VOLATILE |
+ EFI_VARIABLE_BOOTSERVICE_ACCESS |
+ EFI_VARIABLE_RUNTIME_ACCESS,
+ 22, variable_name16, false);
+ if (ret != EFI_SUCCESS)
+ log_err("Setting %ls failed\n", L"CapsuleLast");
}
#ifdef CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT
@@ -988,7 +1002,6 @@ efi_status_t efi_launch_capsules(void)
struct efi_capsule_header *capsule = NULL;
u16 **files;
unsigned int nfiles, index, i;
- u16 variable_name16[12];
efi_status_t ret;
if (!check_run_capsules())
@@ -1045,16 +1058,6 @@ efi_status_t efi_launch_capsules(void)
free(files[i]);
free(files);
- /* CapsuleLast */
- efi_create_indexed_name(variable_name16, sizeof(variable_name16),
- "Capsule", index - 1);
- efi_set_variable_int(L"CapsuleLast", _guid_capsule_report,
-EFI_VARIABLE_READ_ONLY |
-EFI_VARIABLE_NON_VOLATILE |
-EFI_VARIABLE_BOOTSERVICE_ACCESS |
-EFI_VARIABLE_RUNTIME_ACCESS,
-22, variable_name16, false);
-
return ret;
}
#endif /* CONFIG_EFI_CAPSULE_ON_DISK */
--
2.30.2
[PATCH v2 0/2] efi_loader: indicating capsule update results
When creating the Capsule variable we should immediately update CapsuleLast. After each reboot we must clear flag EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED in variable OsIndications. Heinrich Schuchardt (2): efi_loader: fix set_capsule_result() efi_loader: clear OsIndications lib/efi_loader/efi_capsule.c | 39 +++- lib/efi_loader/efi_setup.c | 33 ++ 2 files changed, 54 insertions(+), 18 deletions(-) -- 2.30.2
Re: [PATCH] efi_loader: Improve the parameter check for QueryVariableInfo()
On 6/30/21 5:07 PM, Masami Hiramatsu wrote:
Hi Heinrich,
2021年6月30日(水) 23:55 Heinrich Schuchardt :
This does not catch attributes == EFI_VARIABLE_NON_VOLATILE where test
case 5.2.1.4.5 requires EFI_INVALID_PARAMETER.
Hmm, but this could pass the SCT runtime test.
So attributes == EFI_VARIABLES_NON_VOLATILE should fail?
Actually, I referred to the VariableServiceQueryVariableInfo()@EDK2
and UEFI spec,
and I couldn't see such conditions.
The SCT specification requires in 5.2.1.4.5.:
"1. Call QueryVariableInfoservice with the Attributes:
* EFI_VARIABLE_NON_VOLATILE
* EFI_VARIABLE_RUNTIME_ACCESS
* EFI_VARIABLE_NON_VOLATILE|EFI_VARIABLE_RUNTIME_ACCESS
The returned code must be EFI_INVALID_PARAMETER."
Ah, I see. so either NON_VOLATILE and RUNTIME_ACCESS must be used with
BOOTSERVICE_ACCESS.
See patch
[PATCH edk2-test 1/1] uefi-sct/SctPkg: uefi-sct:
QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE)
https://edk2.groups.io/g/devel/message/77367
Shouldn't we check
!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)
instead?
Ah, right, because this function is only used for the bootservice.
(I found that runtime service uses another function)
A variable without EFI_VARIABLE_BOOTSERVICE_ACCESS could neither be
accessed before nor after ExitBootServices(). So this has to be invalid.
OK, so BOOTSERVICE_ACCESS is required.
Hmm, but in that case, if we confirm BOOTSERVICE_ACCESS bit is set,
should we still need to check NON_VOLATILE and RUNTIME_ACCESS?
I mean
if (!(attr & BOOTSERVICE_ACCESS))
return INVALID_PARAM;
else if (...) /* at this point, attr must have the BOOTSERVICE_ACCESS */
Thus, attributes shouldn't be equal to any of;
* EFI_VARIABLE_NON_VOLATILE
* EFI_VARIABLE_RUNTIME_ACCESS
* EFI_VARIABLE_NON_VOLATILE|EFI_VARIABLE_RUNTIME_ACCESS
So, I think we only need
" !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)"
this check.
That is why I proposed this line. It covers all three test cases.
Best regards
Heinrich
+ ret = EFI_INVALID_PARAMETER;
+ } else if ((attributes & (EFI_VARIABLE_NON_VOLATILE |
EFI_VARIABLE_HARDWARE_ERROR_RECORD)) == EFI_VARIABLE_HARDWARE_ERROR_RECORD) {
+ /* HW error occurs only on non-volatile variables */
We don't support EFI_VARIABLE_HARDWARE_ERROR_RECORD at all. So shouldn't
flag EFI_VARIABLE_HARDWARE_ERROR_RECORD result in EFI_UNSUPPORTED?
OK, I'll do.
BTW, from the UEFI spec, EFI_VARIABLE_APPEND_WRITE should be ignored
in the QueryVariableInfo because that flag is used for SetVariables
(as overwrite flag).
Thus, if attributes == EFI_VARIABLE_APPEND_WRITE, should we return
EFI_INVALID_PARAMETER?
+ ret = EFI_INVALID_PARAMETER;
+ } else {
+ ret = efi_query_variable_info_int(attributes,
maximum_variable_storage_size,
remaining_variable_storage_size,
maximum_variable_size);
CHECK: Alignment should match open parenthesis
#44: FILE: lib/efi_loader/efi_var_common.c:184:
+ ret = efi_query_variable_info_int(attributes,
maximum_variable_storage_size,
OK, let me fix that.
Thank you,
Best regards
Heinrich
+ }
return EFI_EXIT(ret);
}
--
Masami Hiramatsu
Re: [PATCH] efi_loader: Improve the parameter check for QueryVariableInfo()
Hi Heinrich,
2021年6月30日(水) 23:55 Heinrich Schuchardt :
> >> This does not catch attributes == EFI_VARIABLE_NON_VOLATILE where test
> >> case 5.2.1.4.5 requires EFI_INVALID_PARAMETER.
> >
> > Hmm, but this could pass the SCT runtime test.
> > So attributes == EFI_VARIABLES_NON_VOLATILE should fail?
> > Actually, I referred to the VariableServiceQueryVariableInfo()@EDK2
> > and UEFI spec,
> > and I couldn't see such conditions.
>
> The SCT specification requires in 5.2.1.4.5.:
>
> "1. Call QueryVariableInfoservice with the Attributes:
>
> * EFI_VARIABLE_NON_VOLATILE
> * EFI_VARIABLE_RUNTIME_ACCESS
> * EFI_VARIABLE_NON_VOLATILE|EFI_VARIABLE_RUNTIME_ACCESS
>
> The returned code must be EFI_INVALID_PARAMETER."
Ah, I see. so either NON_VOLATILE and RUNTIME_ACCESS must be used with
BOOTSERVICE_ACCESS.
>
> See patch
>
> [PATCH edk2-test 1/1] uefi-sct/SctPkg: uefi-sct:
> QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE)
> https://edk2.groups.io/g/devel/message/77367
>
> >
> >>
> >> Shouldn't we check
> >>
> >> !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)
> >>
> >> instead?
> >
> > Ah, right, because this function is only used for the bootservice.
> > (I found that runtime service uses another function)
>
> A variable without EFI_VARIABLE_BOOTSERVICE_ACCESS could neither be
> accessed before nor after ExitBootServices(). So this has to be invalid.
OK, so BOOTSERVICE_ACCESS is required.
Hmm, but in that case, if we confirm BOOTSERVICE_ACCESS bit is set,
should we still need to check NON_VOLATILE and RUNTIME_ACCESS?
I mean
if (!(attr & BOOTSERVICE_ACCESS))
return INVALID_PARAM;
else if (...) /* at this point, attr must have the BOOTSERVICE_ACCESS */
Thus, attributes shouldn't be equal to any of;
> * EFI_VARIABLE_NON_VOLATILE
> * EFI_VARIABLE_RUNTIME_ACCESS
> * EFI_VARIABLE_NON_VOLATILE|EFI_VARIABLE_RUNTIME_ACCESS
So, I think we only need
" !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS) "
this check.
Best regards,
>
> Best regards
>
> Heinrich
>
> >
> >>
> >>> + ret = EFI_INVALID_PARAMETER;
> >>> + } else if ((attributes & (EFI_VARIABLE_NON_VOLATILE |
> >>> EFI_VARIABLE_HARDWARE_ERROR_RECORD)) ==
> >>> EFI_VARIABLE_HARDWARE_ERROR_RECORD) {
> >>> + /* HW error occurs only on non-volatile variables */
> >>
> >> We don't support EFI_VARIABLE_HARDWARE_ERROR_RECORD at all. So shouldn't
> >> flag EFI_VARIABLE_HARDWARE_ERROR_RECORD result in EFI_UNSUPPORTED?
> >
> > OK, I'll do.
> >
> > BTW, from the UEFI spec, EFI_VARIABLE_APPEND_WRITE should be ignored
> > in the QueryVariableInfo because that flag is used for SetVariables
> > (as overwrite flag).
> > Thus, if attributes == EFI_VARIABLE_APPEND_WRITE, should we return
> > EFI_INVALID_PARAMETER?
> >
> >>
> >>> + ret = EFI_INVALID_PARAMETER;
> >>> + } else {
> >>> + ret = efi_query_variable_info_int(attributes,
> >>> maximum_variable_storage_size,
> >>> remaining_variable_storage_size,
> >>> maximum_variable_size);
> >>
> >> CHECK: Alignment should match open parenthesis
> >> #44: FILE: lib/efi_loader/efi_var_common.c:184:
> >> + ret = efi_query_variable_info_int(attributes,
> >> maximum_variable_storage_size,
> >
> > OK, let me fix that.
> >
> > Thank you,
> >
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>> + }
> >>>
> >>>return EFI_EXIT(ret);
> >>>}
> >>>
> >>
> >
> >
> > --
> > Masami Hiramatsu
> >
>
--
Masami Hiramatsu
Re: [PATCH] efi_loader: Improve the parameter check for QueryVariableInfo()
On 6/30/21 11:32 AM, Masami Hiramatsu wrote:
Hi Heinrich,
Thanks for the review!
2021年6月30日(水) 16:06 Heinrich Schuchardt :
On 6/30/21 7:51 AM, Masami Hiramatsu wrote:
Improve efi_query_variable_info() to check the parameter settings
and return correct error code according to the UEFI spec 2.9.
Detailed requirements can be found in the Self Certification Test (SCT)
II Case Specification, June 2017, chapter 4.1.4 QueryVariableInfo().
Yes, actually this was found by the SCT.
I would prefer to add that reference.
OK, I'll add it.
Signed-off-by: Masami Hiramatsu
Reported-by: Kazuhiko Sakamoto
---
lib/efi_loader/efi_var_common.c | 20 +++-
1 file changed, 19 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/efi_var_common.c b/lib/efi_loader/efi_var_common.c
index 83479dd142..62aa7f970c 100644
--- a/lib/efi_loader/efi_var_common.c
+++ b/lib/efi_loader/efi_var_common.c
@@ -163,10 +163,28 @@ efi_status_t EFIAPI efi_query_variable_info(
EFI_ENTRY("%x %p %p %p", attributes, maximum_variable_storage_size,
remaining_variable_storage_size, maximum_variable_size);
- ret = efi_query_variable_info_int(attributes,
+ if (attributes == 0 || maximum_variable_storage_size == NULL ||
+ remaining_variable_storage_size == NULL ||
+ maximum_variable_size == NULL)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
scripts/checkpatch.pl:
CHECK: Comparison to NULL could be written "!maximum_variable_storage_size"
#26: FILE: lib/efi_loader/efi_var_common.c:166:
+ if (attributes == 0 || maximum_variable_storage_size == NULL ||
Also use !attributes instead of attributes == 0.
OK.
CHECK: Comparison to NULL could be written
"!remaining_variable_storage_size"
#27: FILE: lib/efi_loader/efi_var_common.c:167:
+ remaining_variable_storage_size == NULL ||
CHECK: Comparison to NULL could be written "!maximum_variable_size"
#28: FILE: lib/efi_loader/efi_var_common.c:168:
+ maximum_variable_size == NULL)
+
+ if ((attributes & ~(u32)EFI_VARIABLE_MASK) ||
+ (attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) ||
+ (!IS_ENABLED(CONFIG_EFI_SECURE_BOOT) &&
+ (attributes & EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS))) {
+ ret = EFI_UNSUPPORTED;
+ } else if ((attributes & (EFI_VARIABLE_RUNTIME_ACCESS |
EFI_VARIABLE_BOOTSERVICE_ACCESS)) == EFI_VARIABLE_RUNTIME_ACCESS) {
+ /* Runtime accessible variable must also be accessible in
bootservices */
Please, stick to 80 characters per line.
OK.
This does not catch attributes == EFI_VARIABLE_NON_VOLATILE where test
case 5.2.1.4.5 requires EFI_INVALID_PARAMETER.
Hmm, but this could pass the SCT runtime test.
So attributes == EFI_VARIABLES_NON_VOLATILE should fail?
Actually, I referred to the VariableServiceQueryVariableInfo()@EDK2
and UEFI spec,
and I couldn't see such conditions.
The SCT specification requires in 5.2.1.4.5.:
"1. Call QueryVariableInfoservice with the Attributes:
* EFI_VARIABLE_NON_VOLATILE
* EFI_VARIABLE_RUNTIME_ACCESS
* EFI_VARIABLE_NON_VOLATILE|EFI_VARIABLE_RUNTIME_ACCESS
The returned code must be EFI_INVALID_PARAMETER."
See patch
[PATCH edk2-test 1/1] uefi-sct/SctPkg: uefi-sct:
QueryVariableInfo(EFI_VARIABLE_NON_VOLATILE)
https://edk2.groups.io/g/devel/message/77367
Shouldn't we check
!(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)
instead?
Ah, right, because this function is only used for the bootservice.
(I found that runtime service uses another function)
A variable without EFI_VARIABLE_BOOTSERVICE_ACCESS could neither be
accessed before nor after ExitBootServices(). So this has to be invalid.
Best regards
Heinrich
+ ret = EFI_INVALID_PARAMETER;
+ } else if ((attributes & (EFI_VARIABLE_NON_VOLATILE |
EFI_VARIABLE_HARDWARE_ERROR_RECORD)) == EFI_VARIABLE_HARDWARE_ERROR_RECORD) {
+ /* HW error occurs only on non-volatile variables */
We don't support EFI_VARIABLE_HARDWARE_ERROR_RECORD at all. So shouldn't
flag EFI_VARIABLE_HARDWARE_ERROR_RECORD result in EFI_UNSUPPORTED?
OK, I'll do.
BTW, from the UEFI spec, EFI_VARIABLE_APPEND_WRITE should be ignored
in the QueryVariableInfo because that flag is used for SetVariables
(as overwrite flag).
Thus, if attributes == EFI_VARIABLE_APPEND_WRITE, should we return
EFI_INVALID_PARAMETER?
+ ret = EFI_INVALID_PARAMETER;
+ } else {
+ ret = efi_query_variable_info_int(attributes,
maximum_variable_storage_size,
remaining_variable_storage_size,
maximum_variable_size);
CHECK: Alignment should match open parenthesis
#44: FILE: lib/efi_loader/efi_var_common.c:184:
+ ret = efi_query_variable_info_int(attributes,
maximum_variable_storage_size,
OK, let me fix that.
Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
Hi, On 30.06.21 г. 16:33 ч., Tom Rini wrote: On Wed, Jun 30, 2021 at 10:30:20AM +0300, Ivaylo Dimitrov wrote: Hi, On 26.06.21 г. 17:58 ч., Tom Rini wrote: On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote: Hi Tom, Marek, On 25/06/2021 23:59, Tom Rini wrote: On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote: On Friday 25 June 2021 17:37:44 Tom Rini wrote: One thing I want to say here as I think it maybe wasn't clear in Marek's suggestion. Why not have X-Loader boot SPL which loads U-Boot from extN on the eMMC? Hello Tom! I have already answered this in my previous email. I just re-read things and I don't see it. But perhaps I'm not being clear enough. Why can't you just have NOLO start SPL, not re-initialize things (which is a really common case now thanks to aarch64) and just use that to load full U-Boot from a not size restricted place? I think there are a few problems. 1. One is a practical one, from Pali's email: There is no easy access to eMMC until you start full U-Boot. So even if all these problems are solved then "bootstrapping" or flashing U-Boot into such location is not possible, plus there is no recovery. Plus this loose existing and working operating system, which is no-go. So this way is basically undebugable and therefore perfectly hard to develop. Not being able to access the eMMC to write u-boot until u-boot is started does sound like it would make things a bit more tricky. I don't understand this. Either way it's drivers/mmc/omap_hsmmc.c. 2. According to Pali, adding SPL support would not be a trivial task, and might end up with a lot more "#ifdef"s in SPL than the one in Ivaylo's patch. As I understand it, this hypothetical SPL would mostly not do any hardware initialisation on the N900, so that might be where instead hacks would need to be added to SPL. Pali also wrote: U-Boot for N900 does not use SPL. There is no SPL code implemented. Nobody ever tried to implement it and neither tested. As you have correctly pointed instead of SPL is used vendor X-Loader binary, which is signed by RSA key. And when I asked him today: 12:11 < Pali> in past (10 years ago?) I was investigating the way how we can boot u-boot and the only reasable way was the current one, directly load main u-boot by x-loader/nolo 12:12 < Pali> I have already spend some time with spl on n900 and at that time I have rejected this idea, because it did not work that 12:13 < Pali> spl is also doing hw initialization which cannot be called on n900 as this code basically crash / freeze n900 So perhaps it would make sense to get more clarity on that, since that seems to be where the argument gets stuck. This also doesn't make sense to me. CONFIG_SKIP_LOWLEVEL_INIT should let you skip whatever initialization doesn't need to be done. If there's some init that needs to be skipped but isn't, that's a bug. Also, I'd like to point what Ivaylo wrote earlier: This sounds like a workaround though. Can you instead do the full conversion of the board? I am sure the board removal patch can be postponed if there is plan to convert it. Hard to say if migration to device-tree is even possible on N900 ATM, enabling OF_CONTROL increases the size of the produced binary with some 100k (.dtb not included), making the size of the binary way above our budget of ~256k. Sure, board config does not enable -mthumb, but omap3 in rx-51 suffers from ARM errata 430973 and noone can guarantee we're not going to see SIGILL faults if we enable it. Which it seems we are forced to do even with DM_USB migration only. Re workaround - I took examples of #ifdef's from the current u-boot code (mmc, i2c, etc.) so workaround or not, it is no different to what the other drivers are doing. If the other drivers have the same logic, it seems a bit weird to me that the change made in Ivaylo's patch would be rejected because of a preference to port the board to DT. Unless maybe this was the first driver to be migrated to support only DT and the patch is in effect a reversal of some prior work? Yes, part of the problem here is that DM_USB is the first case that N900 has hit as part of DM conversion that written with using OF_CONTROL in mind, only. And he's not interested in taking workarounds to provide the required information via another mechanism (while i2c for example, is). But another one of the problems here is that N900 doesn't need USB host, only USB gadget, and you were disabling some of the host stuff that's being built but not used. A change to not include unused host mode code entirely would be another path, and you can address moving to DM_USB_GADGET (which doesn't have a deadline yet, but should be done...) and see if you have to re-visit the OF_CONTROL problem or not. Removing usb-uclass.c and usb_hub.c from the build allows me to enable DM_USB without OF_CONTROL. The resulting binary is 247312 bytes without -mthumb and runs just fine on a real HW. So I guess this
Re: [PATCH 0/6] Call phy_config at port probe time for the Felix DSA driver
Am 2021-06-29 19:08, schrieb Vladimir Oltean: From: Vladimir Oltean This series makes the Felix DSA driver initialize all its connected PHYs regardless of whether those will be used for networking or not. This is in order to satisfy the expectations of some software in later boot stages. To make this work, it is necessary to introduce a new method in struct dsa_ops: .port_probe(). There is some further refactoring/cleanup along the way. Tested-by: Michael Walle Seems like our PHYs are already in in-band signalling mode. I can't see any difference after applying this series. Neither by using the port in uboot, ie. "bootp; boot" nor booting directly into linux without using the network. Also, we have two different variants: - one where the switch is used in u-boot and in linux: arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dtb (DSA support still pending in u-boot) - one where we only use the switch in linux and u-boot doesn't touch the device at all: arch/arm/dts/fsl-ls1028a-kontron-sl28-var4.dtb Do I understand it correctly, that for the latter variant DPDK would be broken if the PHY hasn't in-band signalling enabled by default? Because u-boot doesn't know the device and it won't setup the PHY correctly. Oh and I noticed that for var2 "managed = in-band-status" is missing in the linux dtb; what a mess ;) I wonder how this ever worked.. -michael
Re: [PATCH 1/2] DM_USB: allow building without OF_CONTROL
On Wed, Jun 30, 2021 at 10:30:20AM +0300, Ivaylo Dimitrov wrote: > Hi, > > On 26.06.21 г. 17:58 ч., Tom Rini wrote: > > On Sat, Jun 26, 2021 at 12:59:21PM +0200, Merlijn Wajer wrote: > > > Hi Tom, Marek, > > > > > > On 25/06/2021 23:59, Tom Rini wrote: > > > > On Fri, Jun 25, 2021 at 11:51:51PM +0200, Pali Rohár wrote: > > > > > On Friday 25 June 2021 17:37:44 Tom Rini wrote: > > > > > > One thing I want to say here as I think it maybe wasn't clear in > > > > > > Marek's > > > > > > suggestion. Why not have X-Loader boot SPL which loads U-Boot from > > > > > > extN > > > > > > on the eMMC? > > > > > > > > > > Hello Tom! I have already answered this in my previous email. > > > > > > > > I just re-read things and I don't see it. But perhaps I'm not being > > > > clear enough. Why can't you just have NOLO start SPL, not re-initialize > > > > things (which is a really common case now thanks to aarch64) and just > > > > use that to load full U-Boot from a not size restricted place? > > > > > > > > > > I think there are a few problems. > > > > > > 1. One is a practical one, from Pali's email: > > > > > > > There is no easy access to eMMC until you start full U-Boot. So even if > > > > all these problems are solved then "bootstrapping" or flashing U-Boot > > > > into such location is not possible, plus there is no recovery. Plus > > > > this loose existing and working operating system, which is no-go. So > > > > this way is basically undebugable and therefore perfectly hard to > > > > develop. > > > > > > Not being able to access the eMMC to write u-boot until u-boot is > > > started does sound like it would make things a bit more tricky. > > > > I don't understand this. Either way it's drivers/mmc/omap_hsmmc.c. > > > > > 2. According to Pali, adding SPL support would not be a trivial task, > > > and might end up with a lot more "#ifdef"s in SPL than the one in > > > Ivaylo's patch. As I understand it, this hypothetical SPL would mostly > > > not do any hardware initialisation on the N900, so that might be where > > > instead hacks would need to be added to SPL. > > > > > > Pali also wrote: > > > > > > > U-Boot for N900 does not use SPL. There is no SPL code implemented. > > > > Nobody ever tried to implement it and neither tested. As you have > > > > correctly pointed instead of SPL is used vendor X-Loader binary, which > > > > is signed by RSA key. > > > And when I asked him today: > > > > > > > 12:11 < Pali> in past (10 years ago?) I was investigating the way how > > > > we can boot u-boot and the only reasable way was the current one, > > > > directly load main u-boot by x-loader/nolo > > > > 12:12 < Pali> I have already spend some time with spl on n900 and at > > > > that time I have rejected this idea, because it did not work that > > > > 12:13 < Pali> spl is also doing hw initialization which cannot be > > > > called on n900 as this code basically crash / freeze n900 > > > So perhaps it would make sense to get more clarity on that, since that > > > seems to be where the argument gets stuck. > > > > This also doesn't make sense to me. CONFIG_SKIP_LOWLEVEL_INIT should > > let you skip whatever initialization doesn't need to be done. If > > there's some init that needs to be skipped but isn't, that's a bug. > > > > > Also, I'd like to point what Ivaylo wrote earlier: > > > > > > > > This sounds like a workaround though. Can you instead do the full > > > > > conversion of the board? I am sure the board removal patch can be > > > > > postponed if there is plan to convert it. > > > > > > > > Hard to say if migration to device-tree is even possible on N900 ATM, > > > > enabling OF_CONTROL increases the size of the produced binary with some > > > > 100k (.dtb not included), making the size of the binary way above our > > > > budget of ~256k. Sure, board config does not enable -mthumb, but omap3 > > > > in rx-51 suffers from ARM errata 430973 and noone can guarantee we're > > > > not going to see SIGILL faults if we enable it. Which it seems we are > > > > forced to do even with DM_USB migration only. > > > > > > > > Re workaround - I took examples of #ifdef's from the current u-boot > > > > code (mmc, i2c, etc.) so workaround or not, it is no different to what > > > > the other drivers are doing. > > > > > > If the other drivers have the same logic, it seems a bit weird to me > > > that the change made in Ivaylo's patch would be rejected because of a > > > preference to port the board to DT. Unless maybe this was the first > > > driver to be migrated to support only DT and the patch is in effect a > > > reversal of some prior work? > > > > Yes, part of the problem here is that DM_USB is the first case that N900 > > has hit as part of DM conversion that written with using OF_CONTROL in > > mind, only. And he's not interested in taking workarounds to provide > > the required information via another mechanism (while i2c for example, > > is). > > > > But another one
RE: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default value
> -Original Message- > From: Bedel, Alban > Sent: Wednesday, June 30, 2021 6:03 PM > To: Priyanka Jain ; Varun Sethi ; > Wasim Khan ; Wasim Khan (OSS) > > Cc: u-boot@lists.denx.de > Subject: Re: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default value > > On Wed, 2021-06-30 at 11:12 +, Priyanka Jain wrote: > > >> snip > > * After issuing `env default -a ; saveenv' the board didn't boot > anymore because `bootcmd` was then empty. This is not the case with latest u-boot code. 'env default -a' set bootcmd to default one (run distro_bootcmd). So, we are safe here. > > * If redundant env on eMMC was enabled `bootcmd` was then overwritten > at every boot, preventing me from using a custom `bootcmd` at all. > Priyanka, Alban Can you help me to understand what does enabling 'redundant env' on eMMC mean and how to enable it ? > snip
Re: [PATCH V4] clk: clk_versaclock: Add support for versaclock driver
On Fri, Jun 4, 2021 at 12:27 PM Sean Anderson wrote: > > > > On 6/4/21 1:26 PM, Adam Ford wrote: > > The driver is based on the Versaclock driver from the Linux code, but > > due differences in the clock API between them, some pieces had to be > > changed. > > > > This driver creates a mux, pfd, pll, and a series of fod ouputs. > > Rate Usecnt Name > > -- > > 2500 0`-- x304-clock > > 2500 0`-- clock-control...@6a.mux > > 2500 0|-- clock-control...@6a.pfd > > 28 0| `-- clock-control...@6a.pll > > 0| |-- clock-controller@6a.fod0 > > 0| | `-- > > clock-controller@6a.out1 > > 0| |-- clock-controller@6a.fod1 > > 0| | `-- > > clock-controller@6a.out2 > > 5000 0| |-- clock-controller@6a.fod2 > > 5000 0| | `-- > > clock-controller@6a.out3 > > 125000| `-- clock-controller@6a.fod3 > > 125000| `-- > > clock-controller@6a.out4 > > 2500 0`-- > > clock-controller@6a.out0_sel_i2cb > > > > A translation function is added so the references to < X> get > > routed > > to the corresponding clock-control...@6a.outx. > > > > Signed-off-by: Adam Ford > > --- > > V4: Remove a few printf's that I missed when removing debug. > > > > V3: Streamline finding the out OUTx subnodes. > > Add error handling. > > Replace printf and pr_err with dev_dbg. > > Restore registers removed in V2. > > > > V2: Remove unused registers. > > Fix spacing in Makefile. > > Make the versaclock driver dependent on CCF. > > Move the versaclock_ids next to U_BOOT_DRIVER(versaclock) > > > > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig > > index 40a5a5dd88..2a7507ea18 100644 > > --- a/drivers/clk/Kconfig > > +++ b/drivers/clk/Kconfig > > @@ -197,4 +197,13 @@ config SANDBOX_CLK_CCF > > Enable this option if you want to test the Linux kernel's Common > > Clock Framework [CCF] code in U-Boot's Sandbox clock driver. > > > > +config CLK_VERSACLOCK > > + tristate "Enable VersaClock 5/6 devices" > > + depends on CLK > > + depends on CLK_CCF > > + depends on OF_CONTROL > > + help > > + This driver supports the IDT VersaClock 5 and VersaClock 6 > > + programmable clock generators. > > + > > endmenu > > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile > > index 645709b855..6f5ddafd64 100644 > > --- a/drivers/clk/Makefile > > +++ b/drivers/clk/Makefile > > @@ -51,3 +51,4 @@ obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o > > obj-$(CONFIG_STM32H7) += clk_stm32h7.o > > obj-$(CONFIG_CLK_VERSAL) += clk_versal.o > > obj-$(CONFIG_CLK_CDCE9XX) += clk-cdce9xx.o > > +obj-$(CONFIG_CLK_VERSACLOCK) += clk_versaclock.o > > diff --git a/drivers/clk/clk_versaclock.c b/drivers/clk/clk_versaclock.c > > new file mode 100644 > > index 00..578668bcf8 > > --- /dev/null > > +++ b/drivers/clk/clk_versaclock.c > > @@ -0,0 +1,1100 @@ > > +// SPDX-License-Identifier: GPL-2.0-or-later > > +/* > > + * Driver for IDT Versaclock 5/6 > > + * > > + * Derived from code Copyright (C) 2017 Marek Vasut > > + */ > > + > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > +#include > > + > > +#include > > + > > +/* VersaClock5 registers */ > > +#define VC5_OTP_CONTROL 0x00 > > + > > +/* Factory-reserved register block */ > > +#define VC5_RSVD_DEVICE_ID 0x01 > > +#define VC5_RSVD_ADC_GAIN_7_00x02 > > +#define VC5_RSVD_ADC_GAIN_15_8 0x03 > > +#define VC5_RSVD_ADC_OFFSET_7_0 0x04 > > +#define VC5_RSVD_ADC_OFFSET_15_8 0x05 > > +#define VC5_RSVD_TEMPY 0x06 > > +#define VC5_RSVD_OFFSET_TBIN 0x07 > > +#define VC5_RSVD_GAIN0x08 > > +#define VC5_RSVD_TEST_NP 0x09 > > +#define VC5_RSVD_UNUSED 0x0a > > +#define VC5_RSVD_BANDGAP_TRIM_UP 0x0b > > +#define VC5_RSVD_BANDGAP_TRIM_DN 0x0c > > +#define VC5_RSVD_CLK_R_12_CLK_AMP_4 0x0d > > +#define VC5_RSVD_CLK_R_34_CLK_AMP_4 0x0e > > +#define VC5_RSVD_CLK_AMP_123 0x0f > > + > > +/* Configuration register block */ > > +#define VC5_PRIM_SRC_SHDN0x10 > > +#define VC5_PRIM_SRC_SHDN_EN_XTALBIT(7) > > +#define VC5_PRIM_SRC_SHDN_EN_CLKIN BIT(6)
Re: Pull request for efi-2021-07-rc5-2
On Mon, Jun 28, 2021 at 09:47:53PM +0200, Heinrich Schuchardt wrote: > Dear Tom, > > I have removed the one patch for better EFI/DM integration that caused > sandbox test problems on my last pull request. This topic needs more > coordination with Simon. > > Gitlab CI showed no problems: > https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/7968 > > The following changes since commit 4d8c21da4170e7c1d38c0106898e0d8347b4f0ff: > > Merge tag 'u-boot-imx-20210625' of > https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2021-06-25 13:33:47 > -0400) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-efi.git > tags/efi-2021-07-rc5-2 > > for you to fetch changes up to 70e80666f26a516096f3787e884d42818d8b4087: > > smbios: Fix SMBIOS tables (2021-06-28 19:57:13 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Pull request: u-boot-spi/next for next
Hi Tom, Please pull this PR for next. Summary: - Cypress s25hl-t/s25hs-t support (Takahiro Kuwano) CI: https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/7979 thanks, Jagan. The following changes since commit f6adec1af4b2f5d3012480c6cdce7743b74a6156: mtd: spi-nor-core: Allow using Micron mt35xu512aba in Octal DTR mode (2021-06-28 12:06:57 +0530) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-spi next for you to fetch changes up to 5b8ec59e2a219185127fcaa640c2f5d5aba3acd6: mtd: spi-nor-tiny: Add fixups for Cypress s25hl-t/s25hs-t (2021-06-29 19:16:54 +0530) Takahiro Kuwano (9): mtd: spi-nor: Add Cypress manufacturer ID mtd: spi-nor-ids: Add Cypress s25hl-t/s25hs-t mtd: spi-nor-core: Add support for Read/Write Any Register mtd: spi-nor-core: Add support for volatile QE bit mtd: spi-nor-core: Add the ->ready() hook mtd: spi-nor-core: Read status by Read Any Register mtd: spi-nor-core: Add Cypress manufacturer ID in set_4byte mtd: spi-nor-core: Add fixups for Cypress s25hl-t/s25hs-t mtd: spi-nor-tiny: Add fixups for Cypress s25hl-t/s25hs-t drivers/mtd/spi/spi-nor-core.c | 266 - drivers/mtd/spi/spi-nor-ids.c | 16 +++ drivers/mtd/spi/spi-nor-tiny.c | 6 + include/linux/mtd/spi-nor.h| 11 ++ 4 files changed, 297 insertions(+), 2 deletions(-)
Re: [PATCH v9 1/9] mtd: spi-nor: Add Cypress manufacturer ID
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > This patch adds Cypress manufacturer ID (34h) definition. > > Signed-off-by: Takahiro Kuwano > Reviewed-by: Pratyush Yadav > --- Applied all to u-boot-spi/next
Re: [PATCH v2] board: sl28: add DSA support for variant 2
Am 2021-06-30 12:34, schrieb Vladimir Oltean:
On Wed, Jun 30, 2021 at 10:26:57AM +0200, Michael Walle wrote:
Can this please go through the net queue?
By chance, I've seen this patch:
https://patchwork.ozlabs.org/project/uboot/patch/20210629175317.2607470-5-vladimir.olt...@nxp.com/
Now I'm lucky that I have the following chunk, otherwise the patch
wouldn't
work.
+ {
+ status = "okay";
+};
Why "lucky"? I remember you were pushing this device tree style in the
first place.
Thats correct, but in u-boot this device was still defaulting to
status = "okay", thus it would have been superfluous to still enable
it in the board dts. And tbh, I don't exactly know why I enabled
it nonetheless. Normally I keep things small ;)
Its not about the change (which is good), but there seems to be
a disconnect between which patches goes through which queue and
you have to be lucky that a (newer) patch doesn't break your patch
which is sitting on another queue to be picked up while the newer
one is already pulled in.
--
-michael
RE: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default value
>-Original Message- >From: Wasim Khan >Sent: Friday, June 25, 2021 2:40 PM >To: Bedel, Alban ; Priyanka Jain >; Varun Sethi ; Wasim Khan (OSS) > >Cc: u-boot@lists.denx.de >Subject: RE: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default value > >Hi Alban, > >> -Original Message- >> From: Bedel, Alban >> Sent: Wednesday, June 23, 2021 6:38 PM >> To: Priyanka Jain ; Varun Sethi >> ; Wasim Khan (OSS) >> Cc: u-boot@lists.denx.de; Wasim Khan >> Subject: Re: [PATCH] armv8: fsl : fix bootcmd and mcinitcmd default >> value >> >> On Wed, 2021-06-16 at 14:19 +0200, Wasim Khan wrote: >> > From: Wasim Khan >> > >> > NXP platforms expect bootcmd and mcinitcmd to be updated as per boot >> > source. >> > >> > commit cbf77d201870f2d12227e2d95718a416b16ec98b breaks this >behaviour. >> > Revert commit cbf77d201870f2d12227e2d95718a416b16ec98b >> >> As I already explained in the prior exchanges we had, I'm fully >> convinced that reverting this patch is not the solution to your >> problem. Please see the log of my patch for a full explanation, but >> basically the old code not only rely on the a broken assumption, it also >> fails to >implement it correctly. >> >> The current code set `bootcmd` and `mcinicmd` only if they are not set >> which a simple and sane behaviour. > > >As I have explained earlier that the bootcmd is always set with default value >as " >run distro_bootcmd". >So fsl_setenv_bootcmd() never gets executed which is causing the issue. > > >> When I submitted my patch these variables were not set in the default >> so I suspect that another patch now set these in the default env. > >I hard reset my tree to your commit and I still see the issue. >Please refer to below logs. I don’t see any other patch causing this issue. >Would >let @Priyanka Jain to share her comments. > > >U-Boot 2021.01-rc3-00115-gcbf77d2018 (Jun 25 2021 - 10:51:56 +0200) >SoC: LX2160ACE Rev2.0 (0x87360020) >... >... >MMC: FSL_SDHC: 0, FSL_SDHC: 1 >Loading Environment from SPIFlash... SF: Detected mt35xu512aba with page size >256 Bytes, erase size 128 KiB, total 64 MiB >*** Warning - bad CRC, using default environment > >EEPROM: NXID v1 >... >... >=> pri bootcmd >bootcmd=run distro_bootcmd > >Regards, >Wasim > >> >> Alban > Alban, Wasim, Lets try to fix both issues. One being faced by Alban and the one faced by Wasim. Alban , Can you please provide summary of the issues faced by you. Regards Priyanka
[PATCH v10 1/2] board: riscv: add openpiton-riscv64 SoC support
This patch adds openpiton-riscv64 SOC support. In particular, this
board supports a standard bootflow through zsbl->u-boot SPL->
opensbi->u-boot proper->Linux. There are separate defconfigs for
building u-boot SPL and u-boot proper
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
Reviewed-by: Leo Yu-Chi Liang
---
arch/riscv/Kconfig | 4 +
arch/riscv/dts/Makefile | 1 +
arch/riscv/dts/openpiton-riscv64.dts| 153
board/openpiton/riscv64/Kconfig | 40 +++
board/openpiton/riscv64/MAINTAINERS | 8 +
board/openpiton/riscv64/Makefile| 5 +
board/openpiton/riscv64/openpiton-riscv64.c | 33 ++
configs/openpiton_riscv64_defconfig | 76
configs/openpiton_riscv64_spl_defconfig | 87 +
doc/board/index.rst | 1 +
doc/board/openpiton/index.rst | 9 +
doc/board/openpiton/riscv64.rst | 376
include/configs/openpiton-riscv64.h | 61
13 files changed, 854 insertions(+)
create mode 100644 arch/riscv/dts/openpiton-riscv64.dts
create mode 100644 board/openpiton/riscv64/Kconfig
create mode 100644 board/openpiton/riscv64/MAINTAINERS
create mode 100644 board/openpiton/riscv64/Makefile
create mode 100644 board/openpiton/riscv64/openpiton-riscv64.c
create mode 100644 configs/openpiton_riscv64_defconfig
create mode 100644 configs/openpiton_riscv64_spl_defconfig
create mode 100644 doc/board/openpiton/index.rst
create mode 100644 doc/board/openpiton/riscv64.rst
create mode 100644 include/configs/openpiton-riscv64.h
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index b3d7fd84ce..4b0c3dffa6 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -26,6 +26,9 @@ config TARGET_SIFIVE_UNMATCHED
config TARGET_SIPEED_MAIX
bool "Support Sipeed Maix Board"
+config TARGET_OPENPITON_RISCV64
+ bool "Support RISC-V cores on OpenPiton SoC"
+
endchoice
config SYS_ICACHE_OFF
@@ -60,6 +63,7 @@ source "board/emulation/qemu-riscv/Kconfig"
source "board/microchip/mpfs_icicle/Kconfig"
source "board/sifive/unleashed/Kconfig"
source "board/sifive/unmatched/Kconfig"
+source "board/openpiton/riscv64/Kconfig"
source "board/sipeed/maix/Kconfig"
# platform-specific options below
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index 7778874831..b6e9166767 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -3,6 +3,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
dtb-$(CONFIG_TARGET_SIPEED_MAIX) += k210-maix-bit.dtb
diff --git a/arch/riscv/dts/openpiton-riscv64.dts
b/arch/riscv/dts/openpiton-riscv64.dts
new file mode 100644
index 00..45951e1236
--- /dev/null
+++ b/arch/riscv/dts/openpiton-riscv64.dts
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/* Copyright (c) 2021 Tianrui Wei */
+
+/*
+ * This dts is for a dual core instance of OpenPiton+Ariane built
+ * to run on a Digilent Genesys 2 FPGA at 66.67MHz. These files
+ * are automatically generated by the OpenPiton build system and
+ * this configuration may not be what you need if your configuration
+ * is different from the below.
+ */
+
+/dts-v1/;
+
+/ {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ compatible = "openpiton,riscv64";
+
+ chosen {
+ stdout-path = "uart0:115200";
+ };
+
+ aliases {
+ console =
+ serial0 =
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <520835>;
+
+ CPU0: cpu@0 {
+ clocks = <>;
+ u-boot,dm-spl;
+ device_type = "cpu";
+ reg = <0>;
+ compatible = "openhwgroup,cva6", "riscv";
+ riscv,isa = "rv64imafdc";
+ mmu-type = "riscv,sv39";
+ tlb-split;
+ // HLIC - hart local interrupt controller
+ CPU0_intc: interrupt-controller {
+ #interrupt-cells = <1>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ };
+ };
+
+ CPU1: cpu@1 {
+ clocks = <>;
+ device_type = "cpu";
+ reg = <1>;
+ compatible = "openhwgroup,cva6", "riscv";
+ riscv,isa = "rv64imafdc";
+
[PATCH v10 2/2] mmc: openpiton: add piton_mmc driver
This commit adds support to piton_mmc driver for OpenPiton-riscv64
This driver has many things set as preconfigured because the hardware
automatically configures most of the settings during startup.
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
---
drivers/mmc/Kconfig | 9 +++
drivers/mmc/Makefile| 1 +
drivers/mmc/piton_mmc.c | 161
3 files changed, 171 insertions(+)
create mode 100644 drivers/mmc/piton_mmc.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 0909f502a1..d0176175e8 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -727,6 +727,15 @@ config MMC_SUNXI_HAS_MODE_SWITCH
bool
depends on MMC_SUNXI
+config MMC_PITON
+ bool "MMC support for OpenPiton SoC"
+ depends on DM_MMC && BLK
+ help
+ This selects support for the SD host controller on OpenPiton SoC.
+ Note that this SD controller directly exposes the contents of the
+ SD card as memory mapped, so there is no manual configuration
+ required
+
config GENERIC_ATMEL_MCI
bool "Atmel Multimedia Card Interface support"
depends on DM_MMC && BLK && ARCH_AT91
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 89d6af3db3..d96ac90719 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -72,6 +72,7 @@ obj-$(CONFIG_MMC_SDHCI_XENON) += xenon_sdhci.o
obj-$(CONFIG_MMC_SDHCI_ZYNQ) += zynq_sdhci.o
obj-$(CONFIG_MMC_SUNXI)+= sunxi_mmc.o
+obj-$(CONFIG_MMC_PITON)+= piton_mmc.o
obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o
obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o
obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o
diff --git a/drivers/mmc/piton_mmc.c b/drivers/mmc/piton_mmc.c
new file mode 100644
index 00..9f5da6d633
--- /dev/null
+++ b/drivers/mmc/piton_mmc.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2009 SAMSUNG Electronics
+ * Minkyu Kang
+ * Jaehoon Chung
+ * Portions Copyright 2011-2019 NVIDIA Corporation
+ * Portions Copyright 2021 Tianrui Wei
+ * This file is adapted from tegra_mmc.c
+ * Tianrui Wei
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define PITON_MMC_DUMMY_F_MAX 2000
+#define PITON_MMC_DUMMY_F_MIN 1000
+#define PITON_MMC_DUMMY_CAPACITY SZ_4G << 3
+#define PITON_MMC_DUMMY_B_MAX SZ_4G
+
+struct piton_mmc_plat {
+ struct mmc_config cfg;
+ struct mmc mmc;
+};
+
+struct piton_mmc_priv {
+ void __iomem *base_addr;
+};
+
+static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
+ if (!data)
+ return 0;
+
+ struct piton_mmc_priv *priv = dev_get_priv(dev);
+ u32 *buff, *start_addr, *write_src;
+ size_t byte_cnt, start_block;
+
+ buff = (u32 *)data->dest;
+ write_src = (u32 *)data->src;
+ start_block = cmd->cmdarg;
+ start_addr = priv->base_addr + start_block;
+
+ /* if there is a read */
+ for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
+byte_cnt -= sizeof(u32)) {
+ if (data->flags & MMC_DATA_READ) {
+ *buff++ = readl(start_addr++);
+ }
+ else if (data->flags & MMC_DATA_WRITE) {
+ writel(*write_src++,start_addr++);
+ }
+ }
+ return 0;
+}
+
+static int piton_mmc_ofdata_to_platdata(struct udevice *dev)
+{
+ struct piton_mmc_priv *priv = dev_get_priv(dev);
+ struct piton_mmc_plat *plat = dev_get_plat(dev);
+ struct mmc_config *cfg;
+ struct mmc *mmc;
+ struct blk_desc *bdesc;
+
+ priv->base_addr = (void *)dev_read_addr(dev);
+ cfg = >cfg;
+ cfg->name = "PITON MMC";
+ cfg->host_caps = MMC_MODE_8BIT;
+ cfg->f_max = PITON_MMC_DUMMY_F_MAX;
+ cfg->f_min = PITON_MMC_DUMMY_F_MIN;
+ cfg->voltages = MMC_VDD_21_22;
+
+ mmc = >mmc;
+ mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
+ mmc->capacity_user = PITON_MMC_DUMMY_CAPACITY;
+ mmc->capacity_user *= mmc->read_bl_len;
+ mmc->capacity_boot = 0;
+ mmc->capacity_rpmb = 0;
+ for (int i = 0; i < 4; i++)
+ mmc->capacity_gp[i] = 0;
+ mmc->capacity = PITON_MMC_DUMMY_CAPACITY;
+ mmc->has_init = 1;
+
+ bdesc = mmc_get_blk_desc(mmc);
+ bdesc->lun = 0;
+ bdesc->hwpart = 0;
+ bdesc->type = 0;
+ bdesc->blksz = mmc->read_bl_len;
+ bdesc->log2blksz = LOG2(bdesc->blksz);
+ bdesc->lba = lldiv(mmc->capacity, mmc->read_bl_len);
+
+ return 0;
+}
+
+static int piton_mmc_getcd(struct udevice *dev)
+{
+ return 1;
+}
+
+static const
[PATCH v10 0/2] Add OpenPiton-riscv64 Board Support
This patch set is to add OpenPiton board support. Patches are split into several parts: - [PATCH 1/2] add OpenPiton support to mmc driver - [PATCH 2/2] add support for OpenPiton board Description - for mmc driver, it's settings are automatically configured at hardware level. We only need to expose the memory mapped interface through U-Boot driver model - For OpenPiton, as we need to embed the device tree blob into the bitstream, there is currently no itb support Tests checks - Able to boot Debian Linux from SD card on Digilent Genesys 2 - Checkpatch is performed, with some warnings ignored Changelogs - V2 . fix styles and typos in [1/2] and [2/2] . add board documentation in [2/2] - V3 . fix styles in [1/2] - V4 . fix checkpatch warnings in [1/2] except MAINTAINERS - V5 . major changes in device tree . changed to OF_SEPARATE . formatting update for mmc - V6 . eliminate debug outputs altogether . separate defconfigs between SPL and u-boot proper . style updates thanks to Sean - V7 . mmc dm fixes . mmc style updates, improving readibility . mmc add write support . OpenPiton RISC-V 64 board Kconfig fixes - V8 . mmc style updates - V9 . fix typo in board doc Acknowledgements We'd like to thank all maintainers who have reviewed our code. But we'd like to thank Sean, Jaehoon and Leo in particular for taking much time and energy to help us write better code. Tianrui Wei (2): board: riscv: add openpiton-riscv64 SoC support mmc: openpiton: add piton_mmc driver arch/riscv/Kconfig | 4 + arch/riscv/dts/Makefile | 1 + arch/riscv/dts/openpiton-riscv64.dts| 153 board/openpiton/riscv64/Kconfig | 40 +++ board/openpiton/riscv64/MAINTAINERS | 8 + board/openpiton/riscv64/Makefile| 5 + board/openpiton/riscv64/openpiton-riscv64.c | 33 ++ configs/openpiton_riscv64_defconfig | 76 configs/openpiton_riscv64_spl_defconfig | 87 + doc/board/index.rst | 1 + doc/board/openpiton/index.rst | 9 + doc/board/openpiton/riscv64.rst | 376 drivers/mmc/Kconfig | 9 + drivers/mmc/Makefile| 1 + drivers/mmc/piton_mmc.c | 161 + include/configs/openpiton-riscv64.h | 61 16 files changed, 1025 insertions(+) create mode 100644 arch/riscv/dts/openpiton-riscv64.dts create mode 100644 board/openpiton/riscv64/Kconfig create mode 100644 board/openpiton/riscv64/MAINTAINERS create mode 100644 board/openpiton/riscv64/Makefile create mode 100644 board/openpiton/riscv64/openpiton-riscv64.c create mode 100644 configs/openpiton_riscv64_defconfig create mode 100644 configs/openpiton_riscv64_spl_defconfig create mode 100644 doc/board/openpiton/index.rst create mode 100644 doc/board/openpiton/riscv64.rst create mode 100644 drivers/mmc/piton_mmc.c create mode 100644 include/configs/openpiton-riscv64.h -- 2.32.0
buildman error
Hi, I am using latest u-boot code and trying to run buildman with my local patch for lx2160 platform on master branch. Getting below error . u-boot$ ./tools/buildman/buildman --list-tool-chains aarch64 : /opt/gcc-linaro-7.4.1-2019.02-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-gcc arm : /opt/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabi/bin/arm-linux-gnueabi-gcc u-boot$ ./tools/buildman/buildman -b master lx2160ardb -ve Building 2 commits for 3 boards (3 threads, 3 jobs per thread) 000 /6 -6 (starting)Thread exception: git checkout (['git', '--git-dir', '../master/.bm-work/02/.git', '--work-tree', '../master/.bm-work/02', 'checkout', '-f', '3ef4572110a43acdd7d401b0cb184c6ebd6eaa17']): fatal: not a git repository: u-boot/.git/worktrees/-2 Thread exception: git checkout (['git', '--git-dir', '../master/.bm-work/00/.git', '--work-tree', '../master/.bm-work/00', 'checkout', '-f', '3ef4572110a43acdd7d401b0cb184c6ebd6eaa17']): fatal: not a git repository: u-boot/.git/worktrees/- Thread exception: git checkout (['git', '--git-dir', '../master/.bm-work/01/.git', '--work-tree', '../master/.bm-work/01', 'checkout', '-f', '3ef4572110a43acdd7d401b0cb184c6ebd6eaa17']): fatal: not a git repository: -boot/.git/worktrees/-1 Completed: 6 total built Failed: 3 thread exceptions Regards, Wasim
Re: [PATCH v2] board: sl28: add DSA support for variant 2
On Wed, Jun 30, 2021 at 10:26:57AM +0200, Michael Walle wrote:
> Can this please go through the net queue?
>
> By chance, I've seen this patch:
> https://patchwork.ozlabs.org/project/uboot/patch/20210629175317.2607470-5-vladimir.olt...@nxp.com/
>
> Now I'm lucky that I have the following chunk, otherwise the patch wouldn't
> work.
>
> + {
> + status = "okay";
> +};
Why "lucky"? I remember you were pushing this device tree style in the
first place.
> In any case, I'd retest this patch today based on u-boot-net/master
> (together
> with Vladimirs new patch series which configures the autoneg at probe time).
I think it's best to just resend with Ramon in CC once you retest.
[PATCH] xilinx: zynqmp: Add support for 67dr silicon
From: T Karthik Reddy
Add zynqmp 67dr silicon to zynqmp device id table.
Signed-off-by: T Karthik Reddy
Signed-off-by: Michal Simek
---
board/xilinx/zynqmp/zynqmp.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 7177c5a5a89f..1748fec2e4d9 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -185,6 +185,11 @@ static const struct {
.device = 49,
.variants = ZYNQMP_VARIANT_DR,
},
+ {
+ .id = 0x046d0093,
+ .device = 67,
+ .variants = ZYNQMP_VARIANT_DR,
+ },
};
static const struct {
--
2.32.0
Re: [PATCH] efi_loader: Improve the parameter check for QueryVariableInfo()
Hi Heinrich,
Thanks for the review!
2021年6月30日(水) 16:06 Heinrich Schuchardt :
>
> On 6/30/21 7:51 AM, Masami Hiramatsu wrote:
> > Improve efi_query_variable_info() to check the parameter settings
> > and return correct error code according to the UEFI spec 2.9.
>
> Detailed requirements can be found in the Self Certification Test (SCT)
> II Case Specification, June 2017, chapter 4.1.4 QueryVariableInfo().
Yes, actually this was found by the SCT.
>
> I would prefer to add that reference.
OK, I'll add it.
>
> >
> > Signed-off-by: Masami Hiramatsu
> > Reported-by: Kazuhiko Sakamoto
> > ---
> > lib/efi_loader/efi_var_common.c | 20 +++-
> > 1 file changed, 19 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/efi_loader/efi_var_common.c
> > b/lib/efi_loader/efi_var_common.c
> > index 83479dd142..62aa7f970c 100644
> > --- a/lib/efi_loader/efi_var_common.c
> > +++ b/lib/efi_loader/efi_var_common.c
> > @@ -163,10 +163,28 @@ efi_status_t EFIAPI efi_query_variable_info(
> > EFI_ENTRY("%x %p %p %p", attributes, maximum_variable_storage_size,
> > remaining_variable_storage_size, maximum_variable_size);
> >
> > - ret = efi_query_variable_info_int(attributes,
> > + if (attributes == 0 || maximum_variable_storage_size == NULL ||
> > + remaining_variable_storage_size == NULL ||
> > + maximum_variable_size == NULL)
> > + return EFI_EXIT(EFI_INVALID_PARAMETER);
>
> scripts/checkpatch.pl:
>
> CHECK: Comparison to NULL could be written "!maximum_variable_storage_size"
> #26: FILE: lib/efi_loader/efi_var_common.c:166:
> + if (attributes == 0 || maximum_variable_storage_size == NULL ||
>
> Also use !attributes instead of attributes == 0.
OK.
>
> CHECK: Comparison to NULL could be written
> "!remaining_variable_storage_size"
> #27: FILE: lib/efi_loader/efi_var_common.c:167:
> + remaining_variable_storage_size == NULL ||
>
> CHECK: Comparison to NULL could be written "!maximum_variable_size"
> #28: FILE: lib/efi_loader/efi_var_common.c:168:
> + maximum_variable_size == NULL)
>
> > +
> > + if ((attributes & ~(u32)EFI_VARIABLE_MASK) ||
> > + (attributes & EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS) ||
> > + (!IS_ENABLED(CONFIG_EFI_SECURE_BOOT) &&
> > + (attributes &
> > EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS))) {
> > + ret = EFI_UNSUPPORTED;
> > + } else if ((attributes & (EFI_VARIABLE_RUNTIME_ACCESS |
> > EFI_VARIABLE_BOOTSERVICE_ACCESS)) == EFI_VARIABLE_RUNTIME_ACCESS) {
> > + /* Runtime accessible variable must also be accessible in
> > bootservices */
>
> Please, stick to 80 characters per line.
OK.
>
> This does not catch attributes == EFI_VARIABLE_NON_VOLATILE where test
> case 5.2.1.4.5 requires EFI_INVALID_PARAMETER.
Hmm, but this could pass the SCT runtime test.
So attributes == EFI_VARIABLES_NON_VOLATILE should fail?
Actually, I referred to the VariableServiceQueryVariableInfo()@EDK2
and UEFI spec,
and I couldn't see such conditions.
>
> Shouldn't we check
>
> !(attributes & EFI_VARIABLE_BOOTSERVICE_ACCESS)
>
> instead?
Ah, right, because this function is only used for the bootservice.
(I found that runtime service uses another function)
>
> > + ret = EFI_INVALID_PARAMETER;
> > + } else if ((attributes & (EFI_VARIABLE_NON_VOLATILE |
> > EFI_VARIABLE_HARDWARE_ERROR_RECORD)) == EFI_VARIABLE_HARDWARE_ERROR_RECORD)
> > {
> > + /* HW error occurs only on non-volatile variables */
>
> We don't support EFI_VARIABLE_HARDWARE_ERROR_RECORD at all. So shouldn't
> flag EFI_VARIABLE_HARDWARE_ERROR_RECORD result in EFI_UNSUPPORTED?
OK, I'll do.
BTW, from the UEFI spec, EFI_VARIABLE_APPEND_WRITE should be ignored
in the QueryVariableInfo because that flag is used for SetVariables
(as overwrite flag).
Thus, if attributes == EFI_VARIABLE_APPEND_WRITE, should we return
EFI_INVALID_PARAMETER?
>
> > + ret = EFI_INVALID_PARAMETER;
> > + } else {
> > + ret = efi_query_variable_info_int(attributes,
> > maximum_variable_storage_size,
> > remaining_variable_storage_size,
> > maximum_variable_size);
>
> CHECK: Alignment should match open parenthesis
> #44: FILE: lib/efi_loader/efi_var_common.c:184:
> + ret = efi_query_variable_info_int(attributes,
>maximum_variable_storage_size,
OK, let me fix that.
Thank you,
>
> Best regards
>
> Heinrich
>
> > + }
> >
> > return EFI_EXIT(ret);
> > }
> >
>
--
Masami Hiramatsu
Re: [PATCH 0/3] cmd: setexpr: add fmt format string operation
Hello Wolfgang On 29.06.21 10:40, Wolfgang Denk wrote: > > Dear Roland, > > In message you wrote: >> >>> These are two pretty unfortunate restrictions. I guess it should >>> not be too hard to avoid both of these. Can you please give it a >>> try? >> >> I think it is possible to allow more than one format parameter or more >> types. But it would make checking much more difficult. > > Maybe we need _less_ checking, not more - and maybe the needed > checking is already done in the *printf() code? The problem printf does not do much checking. For example in case the format string does not match the number of arguments or argument types in best case it just delivers a wrong result, but the program also can just crash. That is why I added the checks. In contrast Bash and Busybox are reporting error messages in the above cases. >> I think just passing the format string directly to sprintf should be >> avoided because it is unsafe. For example >> >> => setexpr foo fmt %s 0x >> >> would surely lead to access on memory location outside the variable >> where 0x is stored. > > Only if you make the wrong assumptions. I would expect this to > result in > > foo=0x > > in the same way as the bash builting gives > > $ printf '%s\n' 0x > 0x Yes, but that requires further checks and interpretation. To maintain the possibility to use pointers as arguments, the get_arg() function is necessary, but in the above example it would return a ulong which needs to be converted to a string before passing to printf, to get the above result. >>> => setexpr foo fmt "%0x08x-%s-%d-%s" $a $b $c $d >> >> I think the only way to support such expressions in a save way would >> be implementing an own format string parser for setexpr with > > Maybe it makes sense to have a look at the bash code? I looked at Bash code but it is quite confusing as they implement at least three format string parsers. I think the one relevant for us is the function printf_builtin() inside builtins/printf.dev. It has a length of about 450 lines. I also had a look at the busybox shell. They implemented their own format string parser too, which is also about 450 lines long. I don't see a leaner way for implementing a Bash like printf functionality with multiple arguments and all kinds of supported format types. When adding that format string capabilities in my opinion it should be a configuration option to keep code size low on systems not needing that functionality. Also I would tend to make the specific format string features configurable. For example in my application only decimal conversion is needed, also enabling floating point support would just increase code without bringing any benefits. Best regards, Roland Gaudig
Re: [PATCH v2] board: sl28: add DSA support for variant 2
Am 2021-06-23 13:56, schrieb Michael Walle:
Now that u-boot gained DSA support, and it is already enabled for the
kontron_sl28 board, add the last missing piece and enable the
corresponding devices it in the device tree.
Signed-off-by: Michael Walle
---
changes since v1:
- renamed ethernet alias stem, because it was changed in
commit 82a3c9ef20d43d97416589854b4bbcb4c2450c24 ("net: use the same
alias stem for ethernet as linux")
Now that the mentioned commit made it finally into u-boot. We can move
forward here. It would be nice if this would still make it into
2021.07,
given that this is only a device tree change for a this particular
board.
Can this please go through the net queue?
By chance, I've seen this patch:
https://patchwork.ozlabs.org/project/uboot/patch/20210629175317.2607470-5-vladimir.olt...@nxp.com/
Now I'm lucky that I have the following chunk, otherwise the patch
wouldn't
work.
+ {
+ status = "okay";
+};
In any case, I'd retest this patch today based on u-boot-net/master
(together
with Vladimirs new patch series which configures the autoneg at probe
time).
-michael
.../fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi | 7
.../arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 40 +++
2 files changed, 47 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
index 79b771e074..4e0ce3f77d 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi
@@ -1,2 +1,9 @@
// SPDX-License-Identifier: GPL-2.0+
#include "fsl-ls1028a-kontron-sl28-u-boot.dtsi"
+
+/ {
+ aliases {
+ ethernet0 = _felix_port0;
+ ethernet1 = _felix_port1;
+ };
+};
diff --git a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
index 1ea1265bcf..7a3aa21408 100644
--- a/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
+++ b/arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts
@@ -22,4 +22,44 @@
/delete-property/ phy-handle;
};
+ {
+ status = "okay";
+};
+
+_felix {
+ status = "okay";
+};
+
+_felix_port0 {
+ label = "gbe0";
+ phy-handle = <>;
+ phy-mode = "sgmii";
+ status = "okay";
+};
+
+_felix_port1 {
+ label = "gbe1";
+ phy-handle = <>;
+ phy-mode = "sgmii";
+ status = "okay";
+};
+
+_felix_port4 {
+ ethernet = <>;
+ status = "okay";
+};
+
/delete-node/
+ {
+ phy0: ethernet-phy@5 {
+ reg = <0x5>;
+ eee-broken-1000t;
+ eee-broken-100tx;
+ };
+
+ phy1: ethernet-phy@4 {
+ reg = <0x4>;
+ eee-broken-1000t;
+ eee-broken-100tx;
+ };
+};
--
-michael
Re: [PATCH v9 1/2] board: riscv: add openpiton-riscv64 SoC support
On Wed, Jun 30, 2021 at 03:43:07PM +0800, Tianrui Wei wrote: > This patch adds openpiton-riscv64 SOC support. In particular, this > board supports a standard bootflow through zsbl->u-boot SPL-> > opensbi->u-boot proper->Linux. There are separate defconfigs for > building u-boot SPL and u-boot proper > > Signed-off-by: Tianrui Wei > Signed-off-by: Jonathan Balkind > --- > arch/riscv/Kconfig | 4 + > arch/riscv/dts/Makefile | 1 + > arch/riscv/dts/openpiton-riscv64.dts| 153 > board/openpiton/riscv64/Kconfig | 40 +++ > board/openpiton/riscv64/MAINTAINERS | 8 + > board/openpiton/riscv64/Makefile| 5 + > board/openpiton/riscv64/openpiton-riscv64.c | 33 ++ > configs/openpiton_riscv64_defconfig | 76 > configs/openpiton_riscv64_spl_defconfig | 87 + > doc/board/index.rst | 1 + > doc/board/openpiton/index.rst | 9 + > doc/board/openpiton/riscv64.rst | 376 > include/configs/openpiton-riscv64.h | 61 > 13 files changed, 854 insertions(+) > create mode 100644 arch/riscv/dts/openpiton-riscv64.dts > create mode 100644 board/openpiton/riscv64/Kconfig > create mode 100644 board/openpiton/riscv64/MAINTAINERS > create mode 100644 board/openpiton/riscv64/Makefile > create mode 100644 board/openpiton/riscv64/openpiton-riscv64.c > create mode 100644 configs/openpiton_riscv64_defconfig > create mode 100644 configs/openpiton_riscv64_spl_defconfig > create mode 100644 doc/board/openpiton/index.rst > create mode 100644 doc/board/openpiton/riscv64.rst > create mode 100644 include/configs/openpiton-riscv64.h Reviewed-by: Leo Yu-Chi Liang
Re: [RFC PATCH v2 1/1] cmd: nvedit: Forbid key to be empty.
Hi.
Le mercredi 30 juin 2021, 09:38:16 CEST Wolfgang Denk a écrit :
> Dear Francis Laniel,
>
> In message <20210629161859.298630-2-francis.lan...@amarulasolutions.com> you
wrote:
> > Before this patch, it was possible to do the following using setenv:
> > setenv '' foo
> > Then, on next reboot, U-Boot will not be able to parse environment due to
> > it having:
> > =foo
> >
> > Now, if the above command is given, an error message is thrown and
> > environment is not modified.
> >
> > Signed-off-by: Francis Laniel
> > ---
> >
> > cmd/nvedit.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> > index d14ba10cef..6f99a85a9c 100644
> > --- a/cmd/nvedit.c
> > +++ b/cmd/nvedit.c
> > @@ -262,6 +262,11 @@ static int _do_env_set(int flag, int argc, char
> > *const argv[], int env_flag)>
> > return 1;
> >
> > }
> >
> > + if (*name == '\0') {
> > + printf("## Error: variable name must no be empty\n");
> > + return 1;
> > + }
> > +
> >
> > env_id++;
> >
> > /* Delete only ? */
>
> Reviewed-by: Wolfgang Denk
Thank you for the review!
>
> Best regards,
>
> Wolfgang Denk
