Re: [PATCH 1/4] phy-sun4i-usb: Fix sun8i_r40_cfg
在 2021/6/21 8:33, Andre Przywara 写道:
On Wed, 16 Jun 2021 10:33:23 +0800
qianfangui...@163.com (qianfangui...@163.com) wrote:
Hi,
first many thanks for sending this! Indeed OTG support was
broken/missing on the R40, also in Linux.
So it seems you have the found the problem: the missing PHY multiplex.
Many thanks for that! This indeed enables OTG functionality for me
(although with some changes). That means that actually a similar patch
needs to go through Linux.
Do you plan on enabling support in Linux as well?
sure.
From: qianfan Zhao
The address of sun8i_r40's phyctrl is 0x01c13404,
But this isn't quite right, is it? See below.
Yes, the right address of R40 is 0x01c13410. I had checked the bsp code
of allwinner: #if defined (CONFIG_ARCH_SUN50I) || defined
(CONFIG_ARCH_SUN8IW10) || defined (CONFIG_ARCH_SUN8IW11)#define
USBPHYC_REG_o_PHYCTL 0x0410#else#define
USBPHYC_REG_o_PHYCTL 0x0404#endif
But I had no idea why the addres 0x01c13404 can work fine, maybe I load u-boot
by using
sunxi-tools, that the usb otg is already init by IBR.
enable_pmu and dual_route.
Ah, of course! The R40 is closer to the A33/A23 here, with not having
separate EHCI0/OHCI0 controllers, instead relying on the MUSB host IP.
So indeed we don't have the PHY multiplex for PHY0.
I think this is the root cause of the non-working OTG support so far!
Signed-off-by: qianfan Zhao
---
drivers/phy/allwinner/phy-sun4i-usb.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/phy/allwinner/phy-sun4i-usb.c
b/drivers/phy/allwinner/phy-sun4i-usb.c
index 5723c98032..608ba46242 100644
--- a/drivers/phy/allwinner/phy-sun4i-usb.c
+++ b/drivers/phy/allwinner/phy-sun4i-usb.c
@@ -587,10 +587,10 @@ static const struct sun4i_usb_phy_cfg sun8i_r40_cfg = {
.num_phys = 3,
.type = sun8i_r40_phy,
.disc_thresh = 3,
- .phyctl_offset = REG_PHYCTL_A33,
+ .phyctl_offset = REG_PHYCTL_A10,
So this doesn't work for me, no device appearing on the host. Also
writing anything to this register (+0x04) reads back as 0, so it's not
implemented, as in the H3. The register at +0x10 however works, and if I
keep the A33 line, OTG indeed works for me. Same in Linux, btw.
.dedicated_clocks = true,
- .enable_pmu_unk1 = true,
- .phy0_dual_route = true,
+ .enable_pmu_unk1 = false,
+ .phy0_dual_route = false,
If they are false, you don't need to list them, the default of 0 will
take care of this.
Thanks for yours guide, I will make a change later.
Cheers,
Andre
};
static const struct sun4i_usb_phy_cfg sun8i_v3s_cfg = {
[PATCH] board: ti: j721e: README: Add documentation for eMMC boot
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(+)
diff --git a/board/ti/j721e/README b/board/ti/j721e/README
index c33afa496e7d..edb26c38ae01 100644
--- a/board/ti/j721e/README
+++ b/board/ti/j721e/README
@@ -226,6 +226,65 @@ Image formats:
| +---+ |
+---+
+eMMC:
+-
+ROM supports booting from eMMC from boot0 partition offset 0x0
+
+Flashing images to eMMC:
+
+The following commands can be used to download tiboot3.bin, tispl.bin,
+u-boot.img, and sysfw.itb from an SD card and write them to the eMMC boot0
+partition at respective addresses.
+
+=> mmc dev 0 1
+=> fatload mmc 1 ${loadaddr} tiboot3.bin
+=> mmc write ${loadaddr} 0x0 0x400
+=> fatload mmc 1 ${loadaddr} tispl.bin
+=> mmc write ${loadaddr} 0x400 0x1000
+=> fatload mmc 1 ${loadaddr} u-boot.img
+=> mmc write ${loadaddr} 0x1400 0x2000
+=> fatload mmc 1 ${loadaddr} sysfw.itb
+=> mmc write ${loadaddr} 0x3600 0x800
+
+To give the ROM access to the boot partition, the following command must be
+used for the first time:
+
+=> mmc partconf 0 1 1 1
+
+To set bus width, reset bus width and data rate during boot, the following
+command must be used for the first time:
+
+=> mmc bootbus 0 2 0 0
+
+To create a software partition for the rootfs, the following command can be
+used:
+
+=> gpt write mmc 0 ${partitions}
+
+eMMC layout:
+
+ boot0 partition (8 MB)user partition
+ 0x0+--+ 0x0+-+
+ | tiboot3.bin (512 KB) | | |
+ 0x400+--+ | |
+ | tispl.bin (2 MB) | | |
+0x1400+--+ |rootfs |
+ | u-boot.img (4 MB) | | |
+0x3400+--+ | |
+ | environment (128 KB)| | |
+0x3500+--+ | |
+ | backup environment (128 KB)| | |
+0x3600+--+ | |
+ | sysfw (1 MB)| | |
+0x3E00+--+ +-+
+
+Kernel image and DT are expected to be present in the /boot folder of rootfs.
+To boot kernel from eMMC, use the following commands:
+
+=> setenv mmcdev 0
+=> setenv bootpart 0
+=> boot
+
OSPI:
-
ROM supports booting from OSPI from offset 0x0.
--
2.17.1
[PATCH] 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 spec 2.9.
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);
+
+ 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 */
+ 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 */
+ ret = EFI_INVALID_PARAMETER;
+ } else {
+ ret = efi_query_variable_info_int(attributes,
maximum_variable_storage_size,
remaining_variable_storage_size,
maximum_variable_size);
+ }
return EFI_EXIT(ret);
}
[PATCH V1] arm: add initial support for the Phytium Pomelo Board
From: weichangzheng
This adds platform code and the device tree for the Phytium Pomelo Board.
The initial support comprises the UART and the PCIE.
Signed-off-by: weichangzheng
Changes since v1:
- updated to DT
---
arch/arm/Kconfig | 8 ++
arch/arm/dts/Makefile| 1 +
arch/arm/dts/phytium-pomelo.dts | 113 +
board/phytium/pomelo/Kconfig | 12 +++
board/phytium/pomelo/MAINTAINERS | 8 ++
board/phytium/pomelo/Makefile| 14 +++
board/phytium/pomelo/cpu.h | 73 ++
board/phytium/pomelo/ddr.c | 164 +++
board/phytium/pomelo/pcie.c | 61
board/phytium/pomelo/pll.c | 75 ++
board/phytium/pomelo/pomelo.c| 120 ++
board/phytium/pomelo/sec.c | 40
configs/pomelo_defconfig | 36 +++
include/configs/pomelo.h | 45 +
14 files changed, 770 insertions(+)
create mode 100644 arch/arm/dts/phytium-pomelo.dts
create mode 100644 board/phytium/pomelo/Kconfig
create mode 100644 board/phytium/pomelo/MAINTAINERS
create mode 100644 board/phytium/pomelo/Makefile
create mode 100644 board/phytium/pomelo/cpu.h
create mode 100644 board/phytium/pomelo/ddr.c
create mode 100644 board/phytium/pomelo/pcie.c
create mode 100644 board/phytium/pomelo/pll.c
create mode 100644 board/phytium/pomelo/pomelo.c
create mode 100644 board/phytium/pomelo/sec.c
create mode 100644 configs/pomelo_defconfig
create mode 100644 include/configs/pomelo.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0448787b8b..0afbb86640 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1818,6 +1818,13 @@ config TARGET_DURIAN
Support for durian platform.
It has 2GB Sdram, uart and pcie.
+config TARGET_POMELO
+ bool "Support Phytium Pomelo Platform"
+ select ARM64
+ help
+ Support for pomelo platform.
+ It has 2GB Sdram, uart and pcie.
+
config TARGET_PRESIDIO_ASIC
bool "Support Cortina Presidio ASIC Platform"
select ARM64
@@ -2038,6 +2045,7 @@ source "board/toradex/colibri_pxa270/Kconfig"
source "board/variscite/dart_6ul/Kconfig"
source "board/vscom/baltos/Kconfig"
source "board/phytium/durian/Kconfig"
+source "board/phytium/pomelo/Kconfig"
source "board/xen/xenguest_arm64/Kconfig"
source "board/keymile/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 9fb38682e6..45d0340bd3 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1107,6 +1107,7 @@ dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
dtb-$(CONFIG_TARGET_DURIAN) += phytium-durian.dtb
+dtb-$(CONFIG_TARGET_POMELO) += phytium-pomelo.dtb
dtb-$(CONFIG_TARGET_PRESIDIO_ASIC) += ca-presidio-engboard.dtb
diff --git a/arch/arm/dts/phytium-pomelo.dts b/arch/arm/dts/phytium-pomelo.dts
new file mode 100644
index 00..3869475902
--- /dev/null
+++ b/arch/arm/dts/phytium-pomelo.dts
@@ -0,0 +1,113 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * dts file for Phytium Pomelo board
+ * Copyright (C) 2021, Phytium Ltd.
+ * lixinde
+ * weichangzheng
+ */
+/dts-v1/;
+
+/ {
+ model = "Phytium Pomelo";
+ compatible = "phytium,pomelo";
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ cpus {
+ #address-cells = <0x2>;
+ #size-cells = <0x0>;
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ numa-node-id = <0>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x1>;
+ enable-method = "psci";
+ numa-node-id = <0>;
+ };
+
+ cpu2: cpu@4 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ numa-node-id = <0>;
+ };
+
+ cpu3: cpu@5 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x101>;
+ enable-method = "psci";
+ numa-node-id = <0>;
+ };
+
+ cpu4: cpu@8 {
+ device_type = "cpu";
+ compatible = "arm,armv8";
+ reg = <0x0 0x200>;
+ enable-method = "psci";
+ numa-node-id = <0>;
+ };
+
+ cpu5: cpu@9 {
+
[PATCH v8 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
- V6
. separate defconfigs for u-boot and SPL
. eliminate debug console output
. style updates
- V7
. update Kconfig for OpenPiton board
. SPL defconfig updates
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
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 = &uart0;
+ serial0 = &uart0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <520835>;
+
+ CPU0: cpu@0 {
+ clocks = <&clk0>;
+ 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 = <&clk0>;
+ device_type = "cpu";
+
[PATCH v8 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.
- V6
. change type of address
. move declarations ahead
. loop style update
- V7
. dm updates
. fix indentations
. style fixes to improve readability
. add write support for mmc cards
- V8
. update variable namings and comments for clarity
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 8901456967..4948e194e7 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 = &plat->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 = &plat->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
[PATCH v8 0/2] [RESEND PATCH v7 0/2]
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 . Update comments and variable namings in piton_mmc.c Acknowledgements We'd like to thank all maintainers who have reviewed our code. But we'd like to thank Sean and Jaehoon 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
Re: [PATCH v2 1/3] mmc: rockchip_sdhci: add phy and clock config for rk3399
On 2021/6/28 17:19, Yifeng Zhao wrote:
Add clock, phy and other configuration, it is convenient to support
new controller. Here a short summary of the changes:
- Add mmc_of_parse to parse dts config.
- Remove OF_PLATDATA related code.
- Reorder header inclusion.
- Add phy ops.
One more generic question,
could phy part be moved to a phy driver?
Regards,
Peng.
- add ops set_ios_post to modify the parameters of phy when the
clock changes.
- Add execute tuning api for hs200 tuning
Signed-off-by: Yifeng Zhao
---
Changes in v2:
- Add mmc_of_parse to parse dts config.
- Used read_poll_timeout api to check dll lock status
- Add execute tuning api for hs200 tuning
drivers/mmc/rockchip_sdhci.c | 310 +++
1 file changed, 274 insertions(+), 36 deletions(-)
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index d95f8b2a15..2973911446 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -6,90 +6,319 @@
*/
#include
+#include
#include
+#include
#include
+#include
#include
#include
+#include
#include
#include
+#include "mmc_private.h"
#include
-#include
+#include
+#include
+#include
/* 400KHz is max freq for card ID etc. Use that as min */
#define EMMC_MIN_FREQ 40
+#define KHz(1000)
+#define MHz(1000 * KHz)
+#define SDHCI_TUNING_LOOP_COUNT40
+
+#define PHYCTRL_CALDONE_MASK 0x1
+#define PHYCTRL_CALDONE_SHIFT 0x6
+#define PHYCTRL_CALDONE_DONE 0x1
+#define PHYCTRL_DLLRDY_MASK0x1
+#define PHYCTRL_DLLRDY_SHIFT 0x5
+#define PHYCTRL_DLLRDY_DONE0x1
+#define PHYCTRL_FREQSEL_200M 0x0
+#define PHYCTRL_FREQSEL_50M0x1
+#define PHYCTRL_FREQSEL_100M 0x2
+#define PHYCTRL_FREQSEL_150M 0x3
+#define PHYCTRL_DLL_LOCK_WO_TMOUT(x) \
+ x) >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK) ==\
+ PHYCTRL_DLLRDY_DONE)
struct rockchip_sdhc_plat {
-#if CONFIG_IS_ENABLED(OF_PLATDATA)
- struct dtd_rockchip_rk3399_sdhci_5_1 dtplat;
-#endif
struct mmc_config cfg;
struct mmc mmc;
};
+struct rockchip_emmc_phy {
+ u32 emmcphy_con[7];
+ u32 reserved;
+ u32 emmcphy_status;
+};
+
struct rockchip_sdhc {
struct sdhci_host host;
+ struct udevice *dev;
void *base;
+ struct rockchip_emmc_phy *phy;
+ struct clk emmc_clk;
+};
+
+struct sdhci_data {
+ int (*emmc_set_clock)(struct sdhci_host *host, unsigned int clock);
+ int (*emmc_phy_init)(struct udevice *dev);
+ int (*get_phy)(struct udevice *dev);
+};
+
+static int rk3399_emmc_phy_init(struct udevice *dev)
+{
+ return 0;
+}
+
+static void rk3399_emmc_phy_power_on(struct rockchip_emmc_phy *phy, u32 clock)
+{
+ u32 caldone, dllrdy, freqsel;
+
+ writel(RK_CLRSETBITS(7 << 4, 0), &phy->emmcphy_con[6]);
+ writel(RK_CLRSETBITS(1 << 11, 1 << 11), &phy->emmcphy_con[0]);
+ writel(RK_CLRSETBITS(0xf << 7, 6 << 7), &phy->emmcphy_con[0]);
+
+ /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+* value, so we may need a little margin here
+*/
+ udelay(3);
+ writel(RK_CLRSETBITS(1, 1), &phy->emmcphy_con[6]);
+
+ /*
+* According to the user manual, it asks driver to
+* wait 5us for calpad busy trimming. But it seems that
+* 5us of caldone isn't enough for all cases.
+*/
+ udelay(500);
+ caldone = readl(&phy->emmcphy_status);
+ caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
+ if (caldone != PHYCTRL_CALDONE_DONE) {
+ printf("%s: caldone timeout.\n", __func__);
+ return;
+ }
+
+ /* Set the frequency of the DLL operation */
+ if (clock < 75 * MHz)
+ freqsel = PHYCTRL_FREQSEL_50M;
+ else if (clock < 125 * MHz)
+ freqsel = PHYCTRL_FREQSEL_100M;
+ else if (clock < 175 * MHz)
+ freqsel = PHYCTRL_FREQSEL_150M;
+ else
+ freqsel = PHYCTRL_FREQSEL_200M;
+
+ /* Set the frequency of the DLL operation */
+ writel(RK_CLRSETBITS(3 << 12, freqsel << 12), &phy->emmcphy_con[0]);
+ writel(RK_CLRSETBITS(1 << 1, 1 << 1), &phy->emmcphy_con[6]);
+
+ read_poll_timeout(readl, &phy->emmcphy_status, dllrdy,
+ PHYCTRL_DLL_LOCK_WO_TMOUT(dllrdy), 1, 5000);
+}
+
+static void rk3399_emmc_phy_power_off(struct rockchip_emmc_phy *phy)
+{
+ writel(RK_CLRSETBITS(1, 0), &phy->emmcphy_con[6]);
+ writel(RK_CLRSETBITS(1 << 1, 0), &phy->emmcphy_con[6]);
+}
+
+static int rk3399_emmc_get_phy(struct udevice *dev)
+{
+ struct rockchip_sdhc *priv = dev_get_priv(dev);
+
+ ofnode phy_node;
+ void *grf_base;
+ u32 grf_phy_offset, phandle;
+
+ phandle = de
Re: [PATCH v2 1/3] mmc: rockchip_sdhci: add phy and clock config for rk3399
On 2021/6/28 17:19, Yifeng Zhao wrote:
Add clock, phy and other configuration, it is convenient to support
new controller. Here a short summary of the changes:
- Add mmc_of_parse to parse dts config.
- Remove OF_PLATDATA related code.
- Reorder header inclusion.
- Add phy ops.
- add ops set_ios_post to modify the parameters of phy when the
clock changes.
- Add execute tuning api for hs200 tuning
Signed-off-by: Yifeng Zhao
---
Changes in v2:
- Add mmc_of_parse to parse dts config.
- Used read_poll_timeout api to check dll lock status
- Add execute tuning api for hs200 tuning
drivers/mmc/rockchip_sdhci.c | 310 +++
1 file changed, 274 insertions(+), 36 deletions(-)
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index d95f8b2a15..2973911446 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -6,90 +6,319 @@
*/
#include
+#include
#include
+#include
#include
+#include
#include
#include
+#include
#include
#include
+#include "mmc_private.h"
#include
-#include
+#include
+#include
+#include
/* 400KHz is max freq for card ID etc. Use that as min */
#define EMMC_MIN_FREQ 40
+#define KHz(1000)
+#define MHz(1000 * KHz)
+#define SDHCI_TUNING_LOOP_COUNT40
+
+#define PHYCTRL_CALDONE_MASK 0x1
+#define PHYCTRL_CALDONE_SHIFT 0x6
+#define PHYCTRL_CALDONE_DONE 0x1
+#define PHYCTRL_DLLRDY_MASK0x1
+#define PHYCTRL_DLLRDY_SHIFT 0x5
+#define PHYCTRL_DLLRDY_DONE0x1
+#define PHYCTRL_FREQSEL_200M 0x0
+#define PHYCTRL_FREQSEL_50M0x1
+#define PHYCTRL_FREQSEL_100M 0x2
+#define PHYCTRL_FREQSEL_150M 0x3
+#define PHYCTRL_DLL_LOCK_WO_TMOUT(x) \
+ x) >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK) ==\
+ PHYCTRL_DLLRDY_DONE)
struct rockchip_sdhc_plat {
-#if CONFIG_IS_ENABLED(OF_PLATDATA)
- struct dtd_rockchip_rk3399_sdhci_5_1 dtplat;
-#endif
Please explain why remove this?
struct mmc_config cfg;
struct mmc mmc;
};
+struct rockchip_emmc_phy {
+ u32 emmcphy_con[7];
+ u32 reserved;
+ u32 emmcphy_status;
+};
+
struct rockchip_sdhc {
struct sdhci_host host;
+ struct udevice *dev;
void *base;
+ struct rockchip_emmc_phy *phy;
+ struct clk emmc_clk;
+};
+
+struct sdhci_data {
+ int (*emmc_set_clock)(struct sdhci_host *host, unsigned int clock);
+ int (*emmc_phy_init)(struct udevice *dev);
+ int (*get_phy)(struct udevice *dev);
+};
+
+static int rk3399_emmc_phy_init(struct udevice *dev)
+{
+ return 0;
+}
+
+static void rk3399_emmc_phy_power_on(struct rockchip_emmc_phy *phy, u32 clock)
+{
+ u32 caldone, dllrdy, freqsel;
+
+ writel(RK_CLRSETBITS(7 << 4, 0), &phy->emmcphy_con[6]);
+ writel(RK_CLRSETBITS(1 << 11, 1 << 11), &phy->emmcphy_con[0]);
+ writel(RK_CLRSETBITS(0xf << 7, 6 << 7), &phy->emmcphy_con[0]);
Would clrsetbits_le32 work?
+
+ /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+* value, so we may need a little margin here
+*/
+ udelay(3);
+ writel(RK_CLRSETBITS(1, 1), &phy->emmcphy_con[6]);
Ditto.
Regards,
Peng.
+
+ /*
+* According to the user manual, it asks driver to
+* wait 5us for calpad busy trimming. But it seems that
+* 5us of caldone isn't enough for all cases.
+*/
+ udelay(500);
+ caldone = readl(&phy->emmcphy_status);
+ caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
+ if (caldone != PHYCTRL_CALDONE_DONE) {
+ printf("%s: caldone timeout.\n", __func__);
+ return;
+ }
+
+ /* Set the frequency of the DLL operation */
+ if (clock < 75 * MHz)
+ freqsel = PHYCTRL_FREQSEL_50M;
+ else if (clock < 125 * MHz)
+ freqsel = PHYCTRL_FREQSEL_100M;
+ else if (clock < 175 * MHz)
+ freqsel = PHYCTRL_FREQSEL_150M;
+ else
+ freqsel = PHYCTRL_FREQSEL_200M;
+
+ /* Set the frequency of the DLL operation */
+ writel(RK_CLRSETBITS(3 << 12, freqsel << 12), &phy->emmcphy_con[0]);
+ writel(RK_CLRSETBITS(1 << 1, 1 << 1), &phy->emmcphy_con[6]);
Ditto.
+
+ read_poll_timeout(readl, &phy->emmcphy_status, dllrdy,
+ PHYCTRL_DLL_LOCK_WO_TMOUT(dllrdy), 1, 5000);
+}
+
+static void rk3399_emmc_phy_power_off(struct rockchip_emmc_phy *phy)
+{
+ writel(RK_CLRSETBITS(1, 0), &phy->emmcphy_con[6]);
+ writel(RK_CLRSETBITS(1 << 1, 0), &phy->emmcphy_con[6]);
+}
+
+static int rk3399_emmc_get_phy(struct udevice *dev)
+{
+ struct rockchip_sdhc *priv = dev_get_priv(dev);
+
+ ofnode phy_node;
+ void *grf_base;
+ u32 grf_phy_offset, phandle;
+
+
Re: [PATCH] arm: Add (back) VExpress boards support
On Wed, Jun 30, 2021 at 01:12:44AM +0100, Andre Przywara wrote: > On Tue, 29 Jun 2021 14:03:23 -0400 > Tom Rini wrote: > > Hi Tom, > > > On Tue, Jun 29, 2021 at 05:52:10PM +0100, Andre Przywara wrote: > > > On Tue, 29 Jun 2021 15:15:52 +0100 > > > Andre Przywara wrote: > > > > > > Hi, > > > > > > > On Tue, 29 Jun 2021 08:11:22 -0400 > > > > Tom Rini wrote: > > > > > > > > > On Tue, Jun 29, 2021 at 12:45:55PM +0100, Andre Przywara wrote: > > > > > > > > > > > The v2021.07 merge window saw the removal of the Arm Ltd. Versatile > > > > > > Express platform, along with their CA5, CA9 and TC2 boards. The > > > > > > trigger > > > > > > was the missing conversion of the MMC driver. > > > > > > > > > > > > Some folks complained about that internally, so bring those boards > > > > > > back, > > > > > > but better than ever: > > > > > > - Use DM and OF_CONTROL for all the boards. Use the .dts files from > > > > > > the > > > > > > latest Linux kernel (5.13) for that. > > > > > > - Move the board selection choice into the platform's Kconfig. > > > > > > - Clean up some shared config and common definitions. > > > > > > - Drop obsolete features like ATAGs support. > > > > > > - Switch to the DM_ETH version of the SMC911X Ethernet driver. > > > > > > - Drop MMC support. > > > > > > > > > > > > The PL180 MMC driver actually supports DM_MMC, but that requires a > > > > > > DM_GPIO driver for the card detect GPIO, which we don't have. This > > > > > > specific GPIO is actually handled via the "sysregs" device, so we > > > > > > would > > > > > > need a driver for that. QEMU does not emulate this part, also the DT > > > > > > description is somewhat "special", so this is left for later. > > > > > > > > > > > > This version compiles without any warning for all three boards now. > > > > > > Tested on QEMU. > > > > > > > > > > > > Signed-off-by: Andre Przywara > > > > > > --- > > > > > > Hi, > > > > > > > > > > > > this relies on the SMC911x driver DT changes, as posted here: > > > > > > https://lists.denx.de/pipermail/u-boot/2021-June/452989.html > > > > > > I put a version with the changes broken down here: > > > > > > https://github.com/Andre-ARM/u-boot/commits/tc2-history > > > > > > > > > > > > This was tested on QEMU, for vexpress_ca15_tc2_defconfig with: > > > > > > $ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G > > > > > > -smp 1 \ > > > > > > -drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \ > > > > > > -device loader,file=u-boot.bin,addr=0x8080 -nographic > > > > > > > > > > > > Where tramp-tc2.bin is a trampoline replacing the board's firmware: > > > > > > 00 00 a0 e3 80 00 48 e3 10 ff 2f e1 > > > > > > (mov r0, #0; movt r0, #0x8080; bx r0) > > > > > > > > > > > > The vexpress_ca9x4_defconfig uses a different memory map, so the > > > > > > runes are: > > > > > > $ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \ > > > > > > -drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \ > > > > > > -device loader,file=u-boot.bin,addr=0x6080 -nographic > > > > > > > > > > > > tramp-ca9.bin: > > > > > > 00 00 a0 e3 80 00 46 e3 10 ff 2f e1 > > > > > > (mov r0, #0; movt r0, #0x6080; bx r0) > > > > > > > > > > My big question is how do we run this in CI? Or does it not _need_ > > > > > that > > > > > firmware file to really exist? Or is there a pending change to > > > > > https://gitlab.denx.de/u-boot/u-boot-test-hooks.git to generate / just > > > > > have exist those magic empty bins? Thanks! > > > > > > > > So from digging into this I see that this loads U-Boot's ELF build, via > > > > QEMU's -kernel parameter. Which is fine, but not really what is > > > > happening on real hardware. > > > > I checked and the v2021.04 version worked with this approach, but my > > > > build does not. > > > > I will have a look into this now. > > > > > > The new build uses OF_CONTROL and OF_SEPARATE, so the DTB gets appended > > > to the U-Boot *image*. The ELF file is not treated this way, so the > > > code reads only 0s after the end of the U-Boot code - which makes it > > > die silently. Manually loading the DTB into DRAM would be fragile at > > > best, but is also rejected by QEMU, because the LOAD program header > > > extend for a few dozen bytes beyond U-Boot's "end" symbol, so it > > > overlaps. > > > > Can't we pass the device tree to qemu (and in turn through to U-Boot) in > > a clean and out of the box way? I thought there was a way to do that.. > > QEMU has a -dtb command, to take a DTB file, and puts that at the > beginning of DRAM (if possible). Also we could load the DTB from the > (emulated) NOR flash, like we do for the Juno board. > But I think this is not the point: we don't really want this U-Boot > port for the *QEMU* vexpress machine, but for the real hardware: and > there is no DTB by default, not on the NOR flash, and certainly > not in DRAM. The previous U-Boot port didn't need any D
Re: [PATCH] arm: Add (back) VExpress boards support
On Tue, 29 Jun 2021 14:03:23 -0400 Tom Rini wrote: Hi Tom, > On Tue, Jun 29, 2021 at 05:52:10PM +0100, Andre Przywara wrote: > > On Tue, 29 Jun 2021 15:15:52 +0100 > > Andre Przywara wrote: > > > > Hi, > > > > > On Tue, 29 Jun 2021 08:11:22 -0400 > > > Tom Rini wrote: > > > > > > > On Tue, Jun 29, 2021 at 12:45:55PM +0100, Andre Przywara wrote: > > > > > > > > > The v2021.07 merge window saw the removal of the Arm Ltd. Versatile > > > > > Express platform, along with their CA5, CA9 and TC2 boards. The > > > > > trigger > > > > > was the missing conversion of the MMC driver. > > > > > > > > > > Some folks complained about that internally, so bring those boards > > > > > back, > > > > > but better than ever: > > > > > - Use DM and OF_CONTROL for all the boards. Use the .dts files from > > > > > the > > > > > latest Linux kernel (5.13) for that. > > > > > - Move the board selection choice into the platform's Kconfig. > > > > > - Clean up some shared config and common definitions. > > > > > - Drop obsolete features like ATAGs support. > > > > > - Switch to the DM_ETH version of the SMC911X Ethernet driver. > > > > > - Drop MMC support. > > > > > > > > > > The PL180 MMC driver actually supports DM_MMC, but that requires a > > > > > DM_GPIO driver for the card detect GPIO, which we don't have. This > > > > > specific GPIO is actually handled via the "sysregs" device, so we > > > > > would > > > > > need a driver for that. QEMU does not emulate this part, also the DT > > > > > description is somewhat "special", so this is left for later. > > > > > > > > > > This version compiles without any warning for all three boards now. > > > > > Tested on QEMU. > > > > > > > > > > Signed-off-by: Andre Przywara > > > > > --- > > > > > Hi, > > > > > > > > > > this relies on the SMC911x driver DT changes, as posted here: > > > > > https://lists.denx.de/pipermail/u-boot/2021-June/452989.html > > > > > I put a version with the changes broken down here: > > > > > https://github.com/Andre-ARM/u-boot/commits/tc2-history > > > > > > > > > > This was tested on QEMU, for vexpress_ca15_tc2_defconfig with: > > > > > $ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G > > > > > -smp 1 \ > > > > > -drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \ > > > > > -device loader,file=u-boot.bin,addr=0x8080 -nographic > > > > > > > > > > Where tramp-tc2.bin is a trampoline replacing the board's firmware: > > > > > 00 00 a0 e3 80 00 48 e3 10 ff 2f e1 > > > > > (mov r0, #0; movt r0, #0x8080; bx r0) > > > > > > > > > > The vexpress_ca9x4_defconfig uses a different memory map, so the > > > > > runes are: > > > > > $ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \ > > > > > -drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \ > > > > > -device loader,file=u-boot.bin,addr=0x6080 -nographic > > > > > > > > > > tramp-ca9.bin: > > > > > 00 00 a0 e3 80 00 46 e3 10 ff 2f e1 > > > > > (mov r0, #0; movt r0, #0x6080; bx r0) > > > > > > > > My big question is how do we run this in CI? Or does it not _need_ that > > > > firmware file to really exist? Or is there a pending change to > > > > https://gitlab.denx.de/u-boot/u-boot-test-hooks.git to generate / just > > > > have exist those magic empty bins? Thanks! > > > > > > So from digging into this I see that this loads U-Boot's ELF build, via > > > QEMU's -kernel parameter. Which is fine, but not really what is > > > happening on real hardware. > > > I checked and the v2021.04 version worked with this approach, but my > > > build does not. > > > I will have a look into this now. > > > > The new build uses OF_CONTROL and OF_SEPARATE, so the DTB gets appended > > to the U-Boot *image*. The ELF file is not treated this way, so the > > code reads only 0s after the end of the U-Boot code - which makes it > > die silently. Manually loading the DTB into DRAM would be fragile at > > best, but is also rejected by QEMU, because the LOAD program header > > extend for a few dozen bytes beyond U-Boot's "end" symbol, so it > > overlaps. > > Can't we pass the device tree to qemu (and in turn through to U-Boot) in > a clean and out of the box way? I thought there was a way to do that.. QEMU has a -dtb command, to take a DTB file, and puts that at the beginning of DRAM (if possible). Also we could load the DTB from the (emulated) NOR flash, like we do for the Juno board. But I think this is not the point: we don't really want this U-Boot port for the *QEMU* vexpress machine, but for the real hardware: and there is no DTB by default, not on the NOR flash, and certainly not in DRAM. The previous U-Boot port didn't need any DTBs at all, so we can't and shouldn't rely on any extra firmware provision. I think appending the DTBs to the U-Boot image is the right solution, so we get a self-contained U-Boot binary, acting as a drop-in replacement for the older port. Running under QEMU should just be a som
[PATCH] arm: armv8: Fix warning about redeclaring global functions as weak
As seen with clang-12: warning: __asm_invalidate_l3_dcache changed binding to STB_WEAK As we indeed use ENTRY and then declare the function weak manually. Use the WEAK declarative from instead. Signed-off-by: Tom Rini --- arch/arm/cpu/armv8/cache.S | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/armv8/cache.S b/arch/arm/cpu/armv8/cache.S index 443d94c262a0..e04907dd8c0b 100644 --- a/arch/arm/cpu/armv8/cache.S +++ b/arch/arm/cpu/armv8/cache.S @@ -188,27 +188,24 @@ ENDPROC(__asm_invalidate_icache_all) .popsection .pushsection .text.__asm_invalidate_l3_dcache, "ax" -ENTRY(__asm_invalidate_l3_dcache) +WEAK(__asm_invalidate_l3_dcache) mov x0, #0 /* return status as success */ ret ENDPROC(__asm_invalidate_l3_dcache) - .weak __asm_invalidate_l3_dcache .popsection .pushsection .text.__asm_flush_l3_dcache, "ax" -ENTRY(__asm_flush_l3_dcache) +WEAK(__asm_flush_l3_dcache) mov x0, #0 /* return status as success */ ret ENDPROC(__asm_flush_l3_dcache) - .weak __asm_flush_l3_dcache .popsection .pushsection .text.__asm_invalidate_l3_icache, "ax" -ENTRY(__asm_invalidate_l3_icache) +WEAK(__asm_invalidate_l3_icache) mov x0, #0 /* return status as success */ ret ENDPROC(__asm_invalidate_l3_icache) - .weak __asm_invalidate_l3_icache .popsection /* -- 2.17.1
Re: [PATCH v3 5/7] net: enetc: require a PHY device when probing
On Tue, Jun 29, 2021 at 8:55 PM Vladimir Oltean wrote:
>
> Given that even a fixed-link has an associated phy_device, there is no
> reason to operate in a mode when dm_eth_phy_connect fails.
>
> Remove the driver checks for a NULL priv->phy and just return -ENODEV
> when that happens.
>
> Copyright updated according to corporate requirements.
>
> Signed-off-by: Vladimir Oltean
> Reviewed-by: Ramon Fried
> ---
> v2->v3: update copyright
> v1->v2: none
>
> drivers/net/fsl_enetc.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
> index f6fc7801b95b..9c198a1039d2 100644
> --- a/drivers/net/fsl_enetc.c
> +++ b/drivers/net/fsl_enetc.c
> @@ -1,7 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> * ENETC ethernet controller driver
> - * Copyright 2017-2019 NXP
> + * Copyright 2017-2021 NXP
> */
>
> #include
> @@ -281,21 +281,20 @@ static void enetc_start_pcs(struct udevice *dev)
> }
>
> /* Configure the actual/external ethernet PHY, if one is found */
> -static void enetc_config_phy(struct udevice *dev)
> +static int enetc_config_phy(struct udevice *dev)
> {
> struct enetc_priv *priv = dev_get_priv(dev);
> int supported;
>
> priv->phy = dm_eth_phy_connect(dev);
> -
> if (!priv->phy)
> - return;
> + return -ENODEV;
>
> supported = PHY_GBIT_FEATURES | SUPPORTED_2500baseX_Full;
> priv->phy->supported &= supported;
> priv->phy->advertising &= supported;
>
> - phy_config(priv->phy);
> + return phy_config(priv->phy);
> }
>
> /*
> @@ -335,9 +334,8 @@ static int enetc_probe(struct udevice *dev)
> dm_pci_clrset_config16(dev, PCI_COMMAND, 0, PCI_COMMAND_MEMORY);
>
> enetc_start_pcs(dev);
> - enetc_config_phy(dev);
>
> - return 0;
> + return enetc_config_phy(dev);
> }
>
> /*
> @@ -550,8 +548,7 @@ static int enetc_start(struct udevice *dev)
>
> enetc_setup_mac_iface(dev);
>
> - if (priv->phy)
> - phy_startup(priv->phy);
> + phy_startup(priv->phy);
>
> return 0;
> }
> --
> 2.25.1
>
Applied to u-boot-net/master, Thanks !
Ramon
Re: [PATCH v3 6/7] net: enetc: force the RGMII MAC speed/duplex instead of using in-band signaling
On Tue, Jun 29, 2021 at 8:55 PM Vladimir Oltean wrote:
>
> The RGMII spec supports optional in-band status reporting for the speed
> and duplex negotiated on the copper side, and the ENETC driver enables
> this feature by default.
>
> However, this does not work when the PHY does not implement the in-band
> reporting, or when there is a MAC-to-MAC connection described using a
> fixed-link. In that case, it would be better to disable the feature in
> the ENETC MAC and always force the speed and duplex to the values that
> were negotiated and retrieved over MDIO once the autoneg is finished.
> Since this works always, we just do it unconditionally and drop the
> in-band code.
>
> Note that because we need to wait for the autoneg to complete, we need
> to move enetc_setup_mac_iface() after phy_startup() returns, and then
> pass the phydev pointer all the way to enetc_init_rgmii().
>
> The same considerations have led to a similar Linux driver patch as well:
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c76a97218dcbb2cb7cec1404ace43ef96c87d874
>
> Copyright updated according to corporate requirements.
>
> Signed-off-by: Vladimir Oltean
> ---
> v2->v3: update copyright
> v1->v2: none
>
> drivers/net/fsl_enetc.c | 44 ++---
> drivers/net/fsl_enetc.h | 7 ++-
> 2 files changed, 39 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
> index 9c198a1039d2..6a5a38c1ffe2 100644
> --- a/drivers/net/fsl_enetc.c
> +++ b/drivers/net/fsl_enetc.c
> @@ -178,21 +178,43 @@ static int enetc_init_sgmii(struct udevice *dev)
> }
>
> /* set up MAC for RGMII */
> -static int enetc_init_rgmii(struct udevice *dev)
> +static void enetc_init_rgmii(struct udevice *dev, struct phy_device *phydev)
> {
> struct enetc_priv *priv = dev_get_priv(dev);
> - u32 if_mode;
> + u32 old_val, val;
>
> - /* enable RGMII AN */
> - if_mode = enetc_read_port(priv, ENETC_PM_IF_MODE);
> - if_mode |= ENETC_PM_IF_MODE_AN_ENA;
> - enetc_write_port(priv, ENETC_PM_IF_MODE, if_mode);
> + old_val = val = enetc_read_port(priv, ENETC_PM_IF_MODE);
>
> - return 0;
> + /* disable unreliable RGMII in-band signaling and force the MAC into
> +* the speed negotiated by the PHY.
> +*/
> + val &= ~ENETC_PM_IF_MODE_AN_ENA;
> +
> + if (phydev->speed == SPEED_1000) {
> + val &= ~ENETC_PM_IFM_SSP_MASK;
> + val |= ENETC_PM_IFM_SSP_1000;
> + } else if (phydev->speed == SPEED_100) {
> + val &= ~ENETC_PM_IFM_SSP_MASK;
> + val |= ENETC_PM_IFM_SSP_100;
> + } else if (phydev->speed == SPEED_10) {
> + val &= ~ENETC_PM_IFM_SSP_MASK;
> + val |= ENETC_PM_IFM_SSP_10;
> + }
> +
> + if (phydev->duplex == DUPLEX_FULL)
> + val |= ENETC_PM_IFM_FULL_DPX;
> + else
> + val &= ~ENETC_PM_IFM_FULL_DPX;
> +
> + if (val == old_val)
> + return;
> +
> + enetc_write_port(priv, ENETC_PM_IF_MODE, val);
> }
>
> /* set up MAC configuration for the given interface type */
> -static void enetc_setup_mac_iface(struct udevice *dev)
> +static void enetc_setup_mac_iface(struct udevice *dev,
> + struct phy_device *phydev)
> {
> struct enetc_priv *priv = dev_get_priv(dev);
> u32 if_mode;
> @@ -202,7 +224,7 @@ static void enetc_setup_mac_iface(struct udevice *dev)
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RGMII_RXID:
> case PHY_INTERFACE_MODE_RGMII_TXID:
> - enetc_init_rgmii(dev);
> + enetc_init_rgmii(dev, phydev);
> break;
> case PHY_INTERFACE_MODE_XGMII:
> case PHY_INTERFACE_MODE_USXGMII:
> @@ -546,10 +568,10 @@ static int enetc_start(struct udevice *dev)
> enetc_setup_tx_bdr(dev);
> enetc_setup_rx_bdr(dev);
>
> - enetc_setup_mac_iface(dev);
> -
> phy_startup(priv->phy);
>
> + enetc_setup_mac_iface(dev, priv->phy);
> +
> return 0;
> }
>
> diff --git a/drivers/net/fsl_enetc.h b/drivers/net/fsl_enetc.h
> index 110c1d78fbc6..69f2f4aaff1e 100644
> --- a/drivers/net/fsl_enetc.h
> +++ b/drivers/net/fsl_enetc.h
> @@ -1,7 +1,7 @@
> /* SPDX-License-Identifier: GPL-2.0+ */
> /*
> * ENETC ethernet controller driver
> - * Copyright 2017-2019 NXP
> + * Copyright 2017-2021 NXP
> */
>
> #ifndef _ENETC_H
> @@ -77,6 +77,11 @@ enum enetc_bdr_type {TX, RX};
> #define ENETC_PM_IF_MODE 0x8300
> #define ENETC_PM_IF_MODE_RG BIT(2)
> #define ENETC_PM_IF_MODE_AN_ENA BIT(15)
> +#define ENETC_PM_IFM_SSP_MASK GENMASK(14, 13)
> +#define ENETC_PM_IFM_SSP_1000 (2 << 13)
> +#define ENETC_PM_IFM_SSP_100 (0 << 13)
> +#define ENETC_PM_IFM_SSP_10 (1 << 13)
> +#define ENETC_PM_IFM_FULL_DPX
Re: [PATCH v3 4/7] arm: dts: ls1028a: disable enetc-2 by default
On Tue, Jun 29, 2021 at 8:55 PM Vladimir Oltean wrote:
>
> The enetc-2 port is used as DSA master (connected back-to-back to
> mscc_felix_port4). Since the convention is to not enable ports in the
> common SoC dtsi unless they are used on the board, then enable enetc-2
> only when mscc_felix_port4 itself is enabled.
>
> All existing device trees appear to adhere to this rule, so disable
> enetc-2 in the SoC dtsi.
>
> Signed-off-by: Vladimir Oltean
> ---
> v2->v3: none
> v1->v2: none
>
> arch/arm/dts/fsl-ls1028a.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index 21f4ef78a059..50f9b527cde1 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -142,7 +142,7 @@
> };
> enetc2: pci@0,2 {
> reg = <0x000200 0 0 0 0>;
> - status = "okay";
> + status = "disabled";
> phy-mode = "internal";
>
> fixed-link {
> --
> 2.25.1
>
Applied to u-boot-net/master, Thanks !
Ramon
Re: [PATCH v3 7/7] net: enetc: propagate the return code from phy_startup() to eth_ops::start
On Tue, Jun 29, 2021 at 8:55 PM Vladimir Oltean wrote: > > Make sure that errors in the PHY driver .startup() method, such as no > link, are propagated and not ignored. > > Signed-off-by: Vladimir Oltean > --- > v2->v3: patch is new > > drivers/net/fsl_enetc.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c > index 6a5a38c1ffe2..566cdc7e546a 100644 > --- a/drivers/net/fsl_enetc.c > +++ b/drivers/net/fsl_enetc.c > @@ -568,11 +568,9 @@ static int enetc_start(struct udevice *dev) > enetc_setup_tx_bdr(dev); > enetc_setup_rx_bdr(dev); > > - phy_startup(priv->phy); > - > enetc_setup_mac_iface(dev, priv->phy); > > - return 0; > + return phy_startup(priv->phy); > } > > /* > -- > 2.25.1 > Applied to u-boot-net/master, Thanks ! Ramon
Re: [PATCH v3 3/7] arm: dts: ls1028a: declare the fixed-link speeds for the internal ENETC ports
On Tue, Jun 29, 2021 at 8:55 PM Vladimir Oltean wrote:
>
> To comply with the device tree bindings expectations for an Ethernet
> controller, as well as to simplify the driver code, declare fixed-link
> nodes for the internal ENETC ports (attached to the mscc_felix switch).
>
> Signed-off-by: Vladimir Oltean
> ---
> v2->v3: none
> v1->v2: none
>
> arch/arm/dts/fsl-ls1028a.dtsi | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
> index c7c725a4fc84..21f4ef78a059 100644
> --- a/arch/arm/dts/fsl-ls1028a.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a.dtsi
> @@ -144,12 +144,22 @@
> reg = <0x000200 0 0 0 0>;
> status = "okay";
> phy-mode = "internal";
> +
> + fixed-link {
> + speed = <2500>;
> + full-duplex;
> + };
> };
> mdio0: pci@0,3 {
> #address-cells=<0>;
> #size-cells=<1>;
> reg = <0x000300 0 0 0 0>;
> status = "disabled";
> +
> + fixed-link {
> + speed = <1000>;
> + full-duplex;
> + };
> };
>
> mscc_felix: pci@0,5 {
> --
> 2.25.1
>
Applied to u-boot-net/master, Thanks !
Ramon
Re: [PATCH v2 6/6] drivers: net: fsl_enetc: force the RGMII MAC speed/duplex instead of using in-band signaling
On Tue, Jun 22, 2021 at 12:20 PM Vladimir Oltean wrote: > > On Fri, Jun 18, 2021 at 11:19:11AM +0300, Ramon Fried wrote: > > Reviewed-by: Ramon Fried > > Ramon, could you please take these patches through your tree? Thanks. Done.
Re: [PATCH v3 2/7] arm: dts: ls1028a: enable internal RGMII delays for the LS1028A-QDS AR8035 PHY
On Tue, Jun 29, 2021 at 8:55 PM Vladimir Oltean wrote:
>
> There are no PCB trace delays on this board, so the PHY needs to enable
> its internal ones in order to have a proper electrical connection to the
> enetc MAC.
>
> Fixes: b32e9a757837 ("arm: dts: ls1028a updates for network interfaces")
> Signed-off-by: Vladimir Oltean
> ---
> v2->v3: none
> v1->v2: none
>
> arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/dts/fsl-ls1028a-qds.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds.dtsi
> index da89ff96e98c..69632fa796b5 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds.dtsi
> @@ -251,7 +251,7 @@
>
> &enetc1 {
> status = "okay";
> - phy-mode = "rgmii";
> + phy-mode = "rgmii-id";
> phy-handle = <&qds_phy0>;
> };
>
> --
> 2.25.1
>
Applied to u-boot-net/master, Thanks !
Ramon
Re: [PATCH v3 1/7] arm: dts: ls1028a: enable the switch CPU port for the LS1028A-QDS
On Tue, Jun 29, 2021 at 8:55 PM Vladimir Oltean wrote:
>
> Due to an upstream change, the ls1028a.dtsi bindings for the mscc_felix
> switch got accepted with all ports disabled by default and with no link
> to the DSA master - this needs to be done on a per board basis.
>
> Note that enetc-2 is not currently disabled in the ls1028a.dtsi, but
> presumably at some point it might become. Explicitly enable it in the
> QDS device trees anyway, to proactively avoid issues when that happens.
>
> Fixes: a7fdac7e2a2a ("arm: dts: ls1028a: define QDS networking protocol
> combinations")
> Signed-off-by: Vladimir Oltean
> ---
> v2->v3: none
> v1->v2: none
>
> arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 9 +
> 8 files changed, 72 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> index fb1836a8aef3..5a0f060c16e5 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> @@ -20,6 +20,10 @@
> #include "fsl-sch-30841.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -47,3 +51,8 @@
> phy-mode = "sgmii-2500";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
> index 1d02a3e11def..39a83e10c4ce 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
> @@ -9,6 +9,10 @@
> #include "fsl-sch-30841.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -24,3 +28,8 @@
> phy-mode = "sgmii-2500";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
> index c92dd1bd2e95..021fe3fbc67a 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
> @@ -34,6 +34,10 @@
> #include "fsl-sch-24801.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -61,3 +65,8 @@
> phy-mode = "sgmii";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
> index 941f7472eb09..b6704d8089a8 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
> @@ -19,6 +19,10 @@
> #include "fsl-sch-24801.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -46,3 +50,8 @@
> phy-mode = "sgmii";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
> index 7e483e656e28..8c10897e565c 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
> @@ -19,6 +19,10 @@
> #include "fsl-sch-30841.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -46,3 +50,8 @@
> phy-mode = "usxgmii";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@03}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
> index 49fffdb9cb2a..1d800dacef89 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
> @@ -13,6 +13,10 @@
> #include "fsl-sch-28021.dtsi"
> };
>
Re: [PATCH v2 1/6] arm: dts: ls1028a: enable the switch CPU port for the LS1028A-QDS
On Fri, Jun 18, 2021 at 1:26 AM Vladimir Oltean wrote:
>
> Due to an upstream change, the ls1028a.dtsi bindings for the mscc_felix
> switch got accepted with all ports disabled by default and with no link
> to the DSA master - this needs to be done on a per board basis.
>
> Note that enetc-2 is not currently disabled in the ls1028a.dtsi, but
> presumably at some point it might become. Explicitly enable it in the
> QDS device trees anyway, to proactively avoid issues when that happens.
>
> Fixes: a7fdac7e2a2a ("arm: dts: ls1028a: define QDS networking protocol
> combinations")
> Signed-off-by: Vladimir Oltean
> ---
> v1->v2: none
>
> arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 9 +
> arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 9 +
> 8 files changed, 72 insertions(+)
>
> diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> index fb1836a8aef3..5a0f060c16e5 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
> @@ -20,6 +20,10 @@
> #include "fsl-sch-30841.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -47,3 +51,8 @@
> phy-mode = "sgmii-2500";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
> index 1d02a3e11def..39a83e10c4ce 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
> @@ -9,6 +9,10 @@
> #include "fsl-sch-30841.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -24,3 +28,8 @@
> phy-mode = "sgmii-2500";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
> index c92dd1bd2e95..021fe3fbc67a 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
> @@ -34,6 +34,10 @@
> #include "fsl-sch-24801.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -61,3 +65,8 @@
> phy-mode = "sgmii";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
> index 941f7472eb09..b6704d8089a8 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
> @@ -19,6 +19,10 @@
> #include "fsl-sch-24801.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -46,3 +50,8 @@
> phy-mode = "sgmii";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
> index 7e483e656e28..8c10897e565c 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
> @@ -19,6 +19,10 @@
> #include "fsl-sch-30841.dtsi"
> };
>
> +&enetc2 {
> + status = "okay";
> +};
> +
> &mscc_felix {
> status = "okay";
> };
> @@ -46,3 +50,8 @@
> phy-mode = "usxgmii";
> phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@03}>;
> };
> +
> +&mscc_felix_port4 {
> + ethernet = <&enetc2>;
> + status = "okay";
> +};
> diff --git a/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
> b/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
> index 49fffdb9cb2a..1d800dacef89 100644
> --- a/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
> +++ b/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
> @@ -13,6 +13,10 @@
> #include "fsl-sch-28021.dtsi"
> };
>
> +&enetc2 {
>
Re: [PATCH v3 0/7] Fixes for the NXP LS1028A-QDS boards
On Tue, Jun 29, 2021 at 8:55 PM Vladimir Oltean wrote: > > This series fixes through patches 1, 2 and 6 networking issues seen on > the LS1028A-QDS boards: > - Traffic through the RGMII port enetc-1 does not work > - The switch ports are not probed > - RGMII fixed-link connections do not work > > Patches 3 and 4 are dependencies for patch 6, as follows: > - Forcing the MAC speed to equal the RGMII PHY requires having a PHY > unconditionally in the enetc driver > - Having a PHY unconditionally requires updating the device tree to > declare fixed PHYs for the internal enetc ports > > Finally, patches 5 and 7 are cleanup changes, which disables the DSA > master port enetc-2 on LS1028A-QDS boards where the switch is not > enabled, and propagate an error code. > > Changes in v2: > Reword commit message of patch 6. > > Changes in v3: > Update driver copyright as part of corporate requirements. > Add patch 7. > > Vladimir Oltean (7): > arm: dts: ls1028a: enable the switch CPU port for the LS1028A-QDS > arm: dts: ls1028a: enable internal RGMII delays for the LS1028A-QDS > AR8035 PHY > arm: dts: ls1028a: declare the fixed-link speeds for the internal > ENETC ports > arm: dts: ls1028a: disable enetc-2 by default > net: enetc: require a PHY device when probing > net: enetc: force the RGMII MAC speed/duplex instead of using in-band > signaling > net: enetc: propagate the return code from phy_startup() to > eth_ops::start > > .../dts/fsl-ls1028a-qds--sch-30841.dtsi | 9 +++ > .../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 9 +++ > .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 9 +++ > .../dts/fsl-ls1028a-qds--sch-24801.dtsi | 9 +++ > .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 9 +++ > .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 9 +++ > .../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 9 +++ > .../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 9 +++ > arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +- > arch/arm/dts/fsl-ls1028a.dtsi | 12 +++- > drivers/net/fsl_enetc.c | 59 --- > drivers/net/fsl_enetc.h | 7 ++- > 12 files changed, 128 insertions(+), 24 deletions(-) > > -- > 2.25.1 > Priyanka Jain, I'm picking this series to my net-tree.
Re: [PATCH 6/6] net: dsa: felix: propagate the error code from phy_startup()
On Tue, Jun 29, 2021 at 8:09 PM Vladimir Oltean wrote: > > From: Vladimir Oltean > > Make sure that the link status returned by phy_startup() is propagated > to the .start() method of struct eth_ops. > > Signed-off-by: Vladimir Oltean > --- > drivers/net/mscc_eswitch/felix_switch.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/drivers/net/mscc_eswitch/felix_switch.c > b/drivers/net/mscc_eswitch/felix_switch.c > index c8ecf4f19442..6aa79784460d 100644 > --- a/drivers/net/mscc_eswitch/felix_switch.c > +++ b/drivers/net/mscc_eswitch/felix_switch.c > @@ -352,9 +352,7 @@ static int felix_port_enable(struct udevice *dev, int > port, > FELIX_QSYS_SYSTEM_SW_PORT_LOSSY | > FELIX_QSYS_SYSTEM_SW_PORT_SCH(1)); > > - phy_startup(phy); > - > - return 0; > + return phy_startup(phy); > } > > static void felix_port_disable(struct udevice *dev, int pidx, > -- > 2.25.1 > Reviewed-by: Ramon Fried
Re: [PATCH 5/6] net: dsa: felix: call phy_config at .port_probe() time
On Tue, Jun 29, 2021 at 8:09 PM Vladimir Oltean wrote:
>
> From: Vladimir Oltean
>
> It is an unfortunate reality that some PHY settings done by U-Boot
> persist even after the PHY is reset and taken over by Linux, and even
> more unfortunate that Linux has come to depend on things being set in a
> certain way.
>
> For example, on the NXP LS1028A-RDB, the felix switch ports are
> connected to a VSC8514 QSGMII PHY. Between the switch port PCS and the
> PHY, the U-Boot drivers enable in-band auto-negotiation which makes the
> copper-side negotiated speed and duplex be transmitted from the PHY to
> the MAC automatically.
>
> The PHY driver portion that does this is in vsc8514_config():
>
> /* Enable Serdes Auto-negotiation */
> phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
> PHY_EXT_PAGE_ACCESS_EXTENDED3);
> val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON);
> val = val | MIIM_VSC8574_MAC_SERDES_ANEG;
> phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON, val);
>
> The point is that in-band autoneg should be turned on in both the PHY
> and the MAC, or off in both the PHY and the MAC, otherwise the QSGMII
> link will be broken.
>
> And because phy_config() is currently called at .port_enable() time, the
> result is that ports on which traffic has been sent in U-Boot will have
> in-band autoneg enabled, and the rest won't.
>
> It can be argued that the Linux kernel should not assume one way or
> another and just reinitialize everything according to what it expects,
> and that is completely fair. In fact, I've already started an attempt to
> remove this dependency, although admittedly I am making slow progress at
> it:
> https://patchwork.kernel.org/project/netdevbpf/cover/20210212172341.3489046-1-olte...@gmail.com/
>
> Nonetheless, the sad reality is that NXP also has, apart from kernel
> drivers, some user space networking (DPDK), and for some reason, the
> expectation there is that somebody else initializes the PHYs. The kernel
> can't do it because the device ownership doesn't belong to the kernel,
> so what remains is for the bootloader to do it (especially since other
> drivers generally call phy_config() at probe time). This is a really
> weak guarantee that might break at any time, but apparently that is
> enough for some.
>
> Since initializing the ports and PHYs at probe time does not break
> anything, we can just do that.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/net/mscc_eswitch/felix_switch.c | 22 +++---
> 1 file changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/mscc_eswitch/felix_switch.c
> b/drivers/net/mscc_eswitch/felix_switch.c
> index 75073880cf87..c8ecf4f19442 100644
> --- a/drivers/net/mscc_eswitch/felix_switch.c
> +++ b/drivers/net/mscc_eswitch/felix_switch.c
> @@ -317,10 +317,23 @@ static int felix_probe(struct udevice *dev)
> return 0;
> }
>
> +static int felix_port_probe(struct udevice *dev, int port,
> + struct phy_device *phy)
> +{
> + int supported = PHY_GBIT_FEATURES | SUPPORTED_2500baseX_Full;
> + struct felix_priv *priv = dev_get_priv(dev);
> +
> + phy->supported &= supported;
> + phy->advertising &= supported;
> +
> + felix_start_pcs(dev, port, phy, &priv->imdio);
> +
> + return phy_config(phy);
> +}
> +
> static int felix_port_enable(struct udevice *dev, int port,
> struct phy_device *phy)
> {
> - int supported = PHY_GBIT_FEATURES | SUPPORTED_2500baseX_Full;
> struct felix_priv *priv = dev_get_priv(dev);
> void *base = priv->regs_base;
>
> @@ -339,12 +352,6 @@ static int felix_port_enable(struct udevice *dev, int
> port,
> FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
> FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
>
> - felix_start_pcs(dev, port, phy, &priv->imdio);
> -
> - phy->supported &= supported;
> - phy->advertising &= supported;
> - phy_config(phy);
> -
> phy_startup(phy);
>
> return 0;
> @@ -392,6 +399,7 @@ static int felix_rcv(struct udevice *dev, int *pidx, void
> *packet, int length)
> }
>
> static const struct dsa_ops felix_dsa_ops = {
> + .port_probe = felix_port_probe,
> .port_enable= felix_port_enable,
> .port_disable = felix_port_disable,
> .xmit = felix_xmit,
> --
> 2.25.1
>
Interesting, My two cents is that device drivers by definition
shouldn't assume anything regarding the state of the HW.
Reviewed-by: Ramon Fried
Re: [PATCH 4/6] net: dsa: introduce a .port_probe() method in struct dsa_ops
On Tue, Jun 29, 2021 at 8:09 PM Vladimir Oltean wrote:
>
> From: Vladimir Oltean
>
> Some drivers might want to execute code for each port at probe time, as
> opposed to executing code just-in-time for the port selected for
> networking.
>
> To cater to that use case, introduce a .port_probe() callback method
> into the DSA switch operations which is called for each available port,
> at the end of dsa_port_probe().
>
> Signed-off-by: Vladimir Oltean
> ---
> include/net/dsa.h | 5 -
> net/dsa-uclass.c | 7 +++
> 2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/include/net/dsa.h b/include/net/dsa.h
> index 0f31a908c9d1..ab2a9dfbea2d 100644
> --- a/include/net/dsa.h
> +++ b/include/net/dsa.h
> @@ -57,7 +57,8 @@
> /**
> * struct dsa_ops - DSA operations
> *
> - * @port_enable: Initialize a switch port for I/O.
> + * @port_probe: Initialize a switch port.
> + * @port_enable: Enable I/O for a port.
> * @port_disable: Disable I/O for a port.
> * @xmit: Insert the DSA tag for transmission.
> *DSA drivers receive a copy of the packet with headroom and
> @@ -69,6 +70,8 @@
> *master including any additional headers.
> */
> struct dsa_ops {
> + int (*port_probe)(struct udevice *dev, int port,
> + struct phy_device *phy);
> int (*port_enable)(struct udevice *dev, int port,
>struct phy_device *phy);
> void (*port_disable)(struct udevice *dev, int port,
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index e23da2ed0e95..1db723573e6c 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -263,6 +263,7 @@ static void dsa_port_set_hwaddr(struct udevice *pdev,
> struct udevice *master)
> static int dsa_port_probe(struct udevice *pdev)
> {
> struct udevice *dev = dev_get_parent(pdev);
> + struct dsa_ops *ops = dsa_get_ops(dev);
> struct dsa_port_pdata *port_pdata;
> struct dsa_priv *dsa_priv;
> struct udevice *master;
> @@ -292,6 +293,12 @@ static int dsa_port_probe(struct udevice *pdev)
>
> dsa_port_set_hwaddr(pdev, master);
>
> + if (ops->port_probe) {
> + err = ops->port_probe(dev, port_pdata->index,
> + port_pdata->phy);
> + if (err)
> + return err;
> + }
>
> return 0;
> }
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 3/6] net: dsa: refactor the code to set the port MAC address into a dedicated function
On Tue, Jun 29, 2021 at 8:09 PM Vladimir Oltean wrote:
>
> From: Vladimir Oltean
>
> This snippet of code has a bothering "if (...) return 0" in it which
> assumes it is the last piece of code running in dsa_port_probe().
>
> This makes it difficult to add further code at the end of dsa_port_probe()
> which does not depend on MAC address stuff.
>
> So move the code to a dedicated function which returns void and let the
> code flow through.
>
> Signed-off-by: Vladimir Oltean
> ---
> net/dsa-uclass.c | 35 +--
> 1 file changed, 21 insertions(+), 14 deletions(-)
>
> diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
> index 17b33834f585..e23da2ed0e95 100644
> --- a/net/dsa-uclass.c
> +++ b/net/dsa-uclass.c
> @@ -240,11 +240,29 @@ static const struct eth_ops dsa_port_ops = {
> .free_pkt = dsa_port_free_pkt,
> };
>
> -static int dsa_port_probe(struct udevice *pdev)
> +/*
> + * Inherit port's hwaddr from the DSA master, unless the port already has a
> + * unique MAC address specified in the environment.
> + */
> +static void dsa_port_set_hwaddr(struct udevice *pdev, struct udevice *master)
> {
> - struct udevice *dev = dev_get_parent(pdev);
> struct eth_pdata *eth_pdata, *master_pdata;
> unsigned char env_enetaddr[ARP_HLEN];
> +
> + eth_env_get_enetaddr_by_index("eth", dev_seq(pdev), env_enetaddr);
> + if (!is_zero_ethaddr(env_enetaddr))
> + return;
> +
> + master_pdata = dev_get_plat(master);
> + eth_pdata = dev_get_plat(pdev);
> + memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
> + eth_env_set_enetaddr_by_index("eth", dev_seq(pdev),
> + master_pdata->enetaddr);
> +}
> +
> +static int dsa_port_probe(struct udevice *pdev)
> +{
> + struct udevice *dev = dev_get_parent(pdev);
> struct dsa_port_pdata *port_pdata;
> struct dsa_priv *dsa_priv;
> struct udevice *master;
> @@ -272,19 +290,8 @@ static int dsa_port_probe(struct udevice *pdev)
> if (err)
> return err;
>
> - /*
> -* Inherit port's hwaddr from the DSA master, unless the port already
> -* 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))
> - return 0;
> + dsa_port_set_hwaddr(pdev, master);
>
> - master_pdata = dev_get_plat(master);
> - eth_pdata = dev_get_plat(pdev);
> - memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
> - eth_env_set_enetaddr_by_index("eth", dev_seq(pdev),
> - master_pdata->enetaddr);
>
> return 0;
> }
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 2/6] net: dsa: use "err" instead of "ret" in dsa_port_probe
On Tue, Jun 29, 2021 at 8:09 PM Vladimir Oltean wrote: > > From: Vladimir Oltean > > DM DSA uses "err" for error code values, so use this consistently. > > Signed-off-by: Vladimir Oltean > --- > net/dsa-uclass.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c > index 7ea1cb6949c0..17b33834f585 100644 > --- a/net/dsa-uclass.c > +++ b/net/dsa-uclass.c > @@ -248,7 +248,7 @@ static int dsa_port_probe(struct udevice *pdev) > struct dsa_port_pdata *port_pdata; > struct dsa_priv *dsa_priv; > struct udevice *master; > - int ret; > + int err; > > port_pdata = dev_get_parent_plat(pdev); > dsa_priv = dev_get_uclass_priv(dev); > @@ -268,9 +268,9 @@ static int dsa_port_probe(struct udevice *pdev) > * TODO: we assume the master device is always there and doesn't get > * removed during runtime. > */ > - ret = device_probe(master); > - if (ret) > - return ret; > + err = device_probe(master); > + if (err) > + return err; > > /* > * Inherit port's hwaddr from the DSA master, unless the port already > -- > 2.25.1 > Reviewed-by: Ramon Fried
Re: [PATCH 1/6] net: dsa: felix: felix_init() can be static
On Tue, Jun 29, 2021 at 8:09 PM Vladimir Oltean wrote:
>
> From: Vladimir Oltean
>
> No one is calling this function from outside felix_switch.c.
>
> Signed-off-by: Vladimir Oltean
> ---
> drivers/net/mscc_eswitch/felix_switch.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/mscc_eswitch/felix_switch.c
> b/drivers/net/mscc_eswitch/felix_switch.c
> index f20e84e0f10c..75073880cf87 100644
> --- a/drivers/net/mscc_eswitch/felix_switch.c
> +++ b/drivers/net/mscc_eswitch/felix_switch.c
> @@ -233,7 +233,7 @@ static void felix_start_pcs(struct udevice *dev, int port,
> }
> }
>
> -void felix_init(struct udevice *dev)
> +static void felix_init(struct udevice *dev)
> {
> struct dsa_pdata *pdata = dev_get_uclass_plat(dev);
> struct felix_priv *priv = dev_get_priv(dev);
> --
> 2.25.1
>
Reviewed-by: Ramon Fried
Re: [PATCH 2/2] net: smc911x: Determine bus width at runtime
On Tue, Jun 29, 2021 at 2:18 PM Ramon Fried wrote:
>
> On Mon, Jun 28, 2021 at 4:31 PM Andre Przywara wrote:
> >
> > The SMC911x Ethernet MACs can be integrated using a 16 or 32-bit bus.
> > The driver needs to know about this choice, which is the reason for us
> > having a Kconfig symbol for that.
> >
> > Now this bus width is already described using a devicetree property, and
> > since the driver is DM compliant and is using the DT now, we should query
> > this at runtime. We leave the Kconfig choice around, in case the DT is
> > missing this property.
> >
> > Signed-off-by: Andre Przywara
> > ---
> > drivers/net/smc911x.c | 33 -
> > 1 file changed, 20 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> > index d596d96f4b3..3afebee4402 100644
> > --- a/drivers/net/smc911x.c
> > +++ b/drivers/net/smc911x.c
> > @@ -28,6 +28,7 @@ struct smc911x_priv {
> > phys_addr_t iobase;
> > const struct chip_id*chipid;
> > unsigned char enetaddr[6];
> > + booluse_32_bit_io;
> > };
> >
> > static const struct chip_id chip_ids[] = {
> > @@ -48,28 +49,24 @@ static const struct chip_id chip_ids[] = {
> >
> > #define DRIVERNAME "smc911x"
> >
> > -#if defined (CONFIG_SMC911X_32_BIT)
> > static u32 smc911x_reg_read(struct smc911x_priv *priv, u32 offset)
> > {
> > - return readl(priv->iobase + offset);
> > -}
> > + if (priv->use_32_bit_io)
> > + return readl(priv->iobase + offset);
> >
> > -static void smc911x_reg_write(struct smc911x_priv *priv, u32 offset, u32
> > val)
> > -{
> > - writel(val, priv->iobase + offset);
> > -}
> > -#else
> > -static u32 smc911x_reg_read(struct smc911x_priv *priv, u32 offset)
> > -{
> > return (readw(priv->iobase + offset) & 0x) |
> >(readw(priv->iobase + offset + 2) << 16);
> > }
> > +
> > static void smc911x_reg_write(struct smc911x_priv *priv, u32 offset, u32
> > val)
> > {
> > - writew(val & 0x, priv->iobase + offset);
> > - writew(val >> 16, priv->iobase + offset + 2);
> > + if (priv->use_32_bit_io) {
> > + writel(val, priv->iobase + offset);
> > + } else {
> > + writew(val & 0x, priv->iobase + offset);
> > + writew(val >> 16, priv->iobase + offset + 2);
> > + }
> > }
> > -#endif /* CONFIG_SMC911X_32_BIT */
> >
> > static u32 smc911x_get_mac_csr(struct smc911x_priv *priv, u8 reg)
> > {
> > @@ -493,6 +490,8 @@ int smc911x_initialize(u8 dev_num, int base_addr)
> > priv->iobase = base_addr;
> > priv->dev.iobase = base_addr;
> >
> > + priv->use_32_bit_io = CONFIG_IS_ENABLED(SMC911X_32_BIT);
> > +
> > /* Try to detect chip. Will fail if not present. */
> > ret = smc911x_detect_chip(priv);
> > if (ret) {
> > @@ -603,10 +602,18 @@ static int smc911x_of_to_plat(struct udevice *dev)
> > {
> > struct smc911x_priv *priv = dev_get_priv(dev);
> > struct eth_pdata *pdata = dev_get_plat(dev);
> > + u32 io_width;
> > + int ret;
> >
> > pdata->iobase = dev_read_addr(dev);
> > priv->iobase = pdata->iobase;
> >
> > + ret = dev_read_u32(dev, "reg-io-width", &io_width);
> > + if (!ret)
> > + priv->use_32_bit_io = (io_width == 4);
> > + else
> > + priv->use_32_bit_io = CONFIG_IS_ENABLED(SMC911X_32_BIT);
> > +
> > return 0;
> > }
> >
> > --
> > 2.17.5
> >
> Reviewed-by: Ramon Fried
Applied to u-boot-net/master, Thanks !
Ramon
Re: [PATCH 1/2] net: smc911x: Drop redundant CONFIG_SMC911X_16_BIT Kconfig symbol
On Tue, Jun 29, 2021 at 2:18 PM Ramon Fried wrote:
>
> On Mon, Jun 28, 2021 at 4:31 PM Andre Przywara wrote:
> >
> > The SMC911x Ethernet driver needs to know which accessor functions it
> > can use to access the MMIO registers. For that reason we have a Kconfig
> > choice between 16 and 32-bit bus width.
> >
> > Since it's only those two options that we (and the Linux kernel)
> > support, and there does not seem to be any evidence of another bus
> > width anywhere, limit the Kconfig construct to a simple symbol.
> >
> > This simplifies the code and allows a later rework to be much easier.
> >
> > Signed-off-by: Andre Przywara
> > ---
> > drivers/net/Kconfig | 17 +
> > drivers/net/smc911x.c | 12 ++--
> > 2 files changed, 7 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index 9fc28b149d0..2a7c8f9a7ff 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -548,21 +548,14 @@ config SMC911X_BASE
> > of the device (I/O space)
> > endif #DM_ETH
> >
> > -choice
> > - prompt "SMC911X bus width"
> > - default SMC911X_16_BIT
> > -
> > config SMC911X_32_BIT
> > - bool "Enable 32-bit interface"
> > -
> > -config SMC911X_16_BIT
> > - bool "Enable 16-bit interface"
> > + bool "Enable SMC911X 32-bit interface"
> > + default n
> > help
> > - Define this if data bus is 16 bits. If your processor
> > - automatically converts one 32 bit word to two 16 bit
> > - words you may also try CONFIG_SMC911X_32_BIT.
> > + Define this if data bus is 32 bits. If your processor use a
> > + narrower 16 bit bus or cannot convert one 32 bit word to two 16
> > bit
> > + words, leave this to "n".
> >
> > -endchoice
> > endif #SMC911X
> >
> > config SUN7I_GMAC
> > diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> > index 7b79831c281..d596d96f4b3 100644
> > --- a/drivers/net/smc911x.c
> > +++ b/drivers/net/smc911x.c
> > @@ -48,12 +48,6 @@ static const struct chip_id chip_ids[] = {
> >
> > #define DRIVERNAME "smc911x"
> >
> > -#if defined (CONFIG_SMC911X_32_BIT) && \
> > - defined (CONFIG_SMC911X_16_BIT)
> > -#error "SMC911X: Only one of CONFIG_SMC911X_32_BIT and \
> > - CONFIG_SMC911X_16_BIT shall be set"
> > -#endif
> > -
> > #if defined (CONFIG_SMC911X_32_BIT)
> > static u32 smc911x_reg_read(struct smc911x_priv *priv, u32 offset)
> > {
> > @@ -64,7 +58,7 @@ static void smc911x_reg_write(struct smc911x_priv *priv,
> > u32 offset, u32 val)
> > {
> > writel(val, priv->iobase + offset);
> > }
> > -#elif defined (CONFIG_SMC911X_16_BIT)
> > +#else
> > static u32 smc911x_reg_read(struct smc911x_priv *priv, u32 offset)
> > {
> > return (readw(priv->iobase + offset) & 0x) |
> > @@ -75,9 +69,7 @@ static void smc911x_reg_write(struct smc911x_priv *priv,
> > u32 offset, u32 val)
> > writew(val & 0x, priv->iobase + offset);
> > writew(val >> 16, priv->iobase + offset + 2);
> > }
> > -#else
> > -#error "SMC911X: undefined bus width"
> > -#endif /* CONFIG_SMC911X_16_BIT */
> > +#endif /* CONFIG_SMC911X_32_BIT */
> >
> > static u32 smc911x_get_mac_csr(struct smc911x_priv *priv, u8 reg)
> > {
> > --
> > 2.17.5
> >
> Reviewed-by: Ramon Fried
Applied to u-boot-net/master, Thanks !
Ramon
Re: [PATCH v3] cmd: net: add a 'net list' command to list network devs
On Sat, Jun 19, 2021 at 1:26 AM Tim Harvey wrote:
>
> In a system with multiple network controllers it can be difficult
> to know the names of the various devices available. This is especially
> true for USB ether devices as they do not display device names upon
> detection.
>
> This is being added as a net sub-system in case other commands may
> want to be added or moved here.
>
> Note that this is only enabled for DM_ETH
>
> Example:
> U-Boot > net
> net - NET sub-system
>
> Usage:
> net list - list available devices
>
> U-Boot > net list
> eth0 : ethernet@2188000 00:d0:12:98:f5:47 active
> eth1 : e1000#0 00:d0:12:98:f5:48
> eth2 : asix_eth 8c:ae:4c:f5:84:9d
> eth3 : asix_eth 8c:ae:4c:f9:41:e3
>
> Signed-off-by: Tim Harvey
> Reviewed-by: Stefan Roese
> Reviewed-by: Ramon Fried
>
> ---
> v3: fix compile issue by enabling only for DM_ETH
> v2: added Reviewed-by tags
> ---
> cmd/net.c | 46 ++
> 1 file changed, 46 insertions(+)
>
> diff --git a/cmd/net.c b/cmd/net.c
> index beb2877dfd..76c7e75125 100644
> --- a/cmd/net.c
> +++ b/cmd/net.c
> @@ -10,6 +10,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -480,3 +481,48 @@ U_BOOT_CMD(
> );
>
> #endif /* CONFIG_CMD_LINK_LOCAL */
> +
> +#ifdef CONFIG_DM_ETH
> +static int do_net_list(struct cmd_tbl *cmdtp, int flag, int argc, char
> *const argv[])
> +{
> + const struct udevice *current = eth_get_dev();
> + unsigned char env_enetaddr[ARP_HLEN];
> + const struct udevice *dev;
> + struct uclass *uc;
> +
> + uclass_id_foreach_dev(UCLASS_ETH, dev, uc) {
> + eth_env_get_enetaddr_by_index("eth", dev_seq(dev),
> env_enetaddr);
> + printf("eth%d : %s %pM %s\n", dev_seq(dev), dev->name,
> env_enetaddr,
> + current == dev ? "active" : "");
> + }
> + return CMD_RET_SUCCESS;
> +}
> +
> +static struct cmd_tbl cmd_net[] = {
> + U_BOOT_CMD_MKENT(list, 1, 0, do_net_list, "", ""),
> +};
> +
> +static int do_net(struct cmd_tbl *cmdtp, int flag, int argc, char *const
> argv[])
> +{
> + struct cmd_tbl *cp;
> +
> + cp = find_cmd_tbl(argv[1], cmd_net, ARRAY_SIZE(cmd_net));
> +
> + /* Drop the net command */
> + argc--;
> + argv++;
> +
> + if (!cp || argc > cp->maxargs)
> + return CMD_RET_USAGE;
> + if (flag == CMD_FLAG_REPEAT && !cmd_is_repeatable(cp))
> + return CMD_RET_SUCCESS;
> +
> + return cp->cmd(cmdtp, flag, argc, argv);
> +}
> +
> +U_BOOT_CMD(
> + net, 2, 1, do_net,
> + "NET sub-system",
> + "list - list available devices\n"
> +);
> +#endif // CONFIG_DM_ETH
> --
> 2.17.1
>
Applied to u-boot-net/master, Thanks !
Ramon
Re: [RESEND PATCH v7 2/2] mmc: openpiton: add piton_mmc driver
On 6/30/21 3:01 AM, 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.
>
> - V6
> . change type of address
> . move declarations ahead
> . loop style update
> - V7
> . dm updates
> . fix indentations
> . style fixes to improve readability
> . add write support for mmc cards
>
> Signed-off-by: Tianrui Wei
> Signed-off-by: Jonathan Balkind
> ---
> drivers/mmc/Kconfig | 9 ++
> drivers/mmc/Makefile| 1 +
> drivers/mmc/piton_mmc.c | 181
> 3 files changed, 191 insertions(+)
> create mode 100644 drivers/mmc/piton_mmc.c
>
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 8901456967..4948e194e7 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..8517ec8410
> --- /dev/null
> +++ b/drivers/mmc/piton_mmc.c
> @@ -0,0 +1,181 @@
> +// 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 *piton_mmc_base_addr; /* peripheral id */
It's for piton. It can be used to base_addr from piton_mmc_base_addr.
> +};
> +
> +/*
> + * see mmc_read_blocks to see how it is used.
> + * start block is hidden at cmd->arg
> + * also, initialize the block size at init
> + */
It seems that not need to describe this comment.
> +static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
> + struct mmc_data *data)
> +{
> + /* check first if this is a pure command */
> + 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->piton_mmc_base_addr + start_block;
> +
> + /* if there is a read */
> + if (data->flags & MMC_DATA_READ) {
> + for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
> + byte_cnt -= sizeof(u32)) {
> + *buff++ = readl(start_addr++);
> + }
> + } else {
> + for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
> + byte_cnt -= sizeof(u32)) {
> + writel(*write_src++,start_addr++);
> + }
Can be reduced code.
for (byte_cnt = data->blocks * data->blocksize; byte_cnt; byte_cnt -=
sizeof((u32)) {
if (data->flags & MMC_DATA_READ)
...
else
...
}
> +
> + }
> +
> + 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;
> +
Re: [PULL] u-boot-network/network_master
On Wed, Jun 30, 2021 at 12:56 AM Tom Rini wrote: > > On Wed, Jun 30, 2021 at 12:52:59AM +0300, Ramon Fried wrote: > > On Fri, Jun 18, 2021 at 8:17 PM Tom Rini wrote: > > > > > > On Fri, Jun 18, 2021 at 02:42:50PM +0300, Ramon Fried wrote: > > > > > > > Hi Tom, > > > > > > > > Please pull the latest patches in u-boot-net tree. > > > > > > > > The following changes since commit > > > > a298d4fbcdba1b38e48ea2af0fc5386cab2070da: > > > > > > > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq > > > > (2021-06-17 08:44:56 -0400) > > > > > > > > are available in the Git repository at: > > > > > > > > g...@source.denx.de:u-boot/custodians/u-boot-net.git network_master > > > > > > Please note that a tag with a short summary of the changes is preferred, > > > but not required. Also, if you have something like this: > > > [remote "network"] > > > fetch = +refs/heads/*:refs/remotes/origin/* > > > url = https://source.denx.de/u-boot/custodians/u-boot-net.git > > > pushurl = g...@source.denx.de:u-boot/custodians/u-boot-net.git > > > > > > in your .git/config when you use git request-pull it should give the > > > non-ssh URI. > > > > > > > for you to fetch changes up to 54c321f9deeba309989f0828e4d0427cbfbefcd3: > > > > > > > > net: octeontx: smi: use dt live tree API (2021-06-18 11:29:17 +0300) > > > > > > > > > > Applied to u-boot/master, thanks! > > > > > > -- > > > Tom > > Hi. > > Out of curiosity, why do you prepare non-ssh URI ? > > I like for the git history to contain public URIs just in case folks are > tracking along or otherwise using the information for some reason. > > -- > Tom Got it.
Re: [PATCH] phy: add nxp tja1103 phy driver
On Mon, Jun 28, 2021 at 2:01 AM Ramon Fried wrote:
>
> On Fri, Jun 18, 2021 at 9:58 PM Radu Pirea (NXP OSS)
> wrote:
> >
> > Add nxp tja1103 phy driver.
> >
> > Signed-off-by: Radu Pirea (NXP OSS)
> > ---
> > MAINTAINERS | 5 +
> > drivers/net/phy/Kconfig | 6 +
> > drivers/net/phy/Makefile | 1 +
> > drivers/net/phy/nxp-c45-tja11xx.c | 348 ++
> > drivers/net/phy/phy.c | 3 +
> > include/phy.h | 5 +
> > 6 files changed, 368 insertions(+)
> > create mode 100644 drivers/net/phy/nxp-c45-tja11xx.c
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 20092cb367..737ba3b162 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -910,6 +910,11 @@ S: Maintained
> > T: git https://source.denx.de/u-boot/custodians/u-boot-nios.git
> > F: arch/nios2/
> >
> > +NXP C45 TJA11XX PHY DRIVER
> > +M: Radu Pirea
> > +S: Maintained
> > +F: drivers/net/phy/nxp-c45-tja11xx.c
> > +
> > ONENAND
> > #M:Lukasz Majewski
> > S: Orphaned (Since 2017-01)
> > diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
> > index 070ffa82cb..405bf76753 100644
> > --- a/drivers/net/phy/Kconfig
> > +++ b/drivers/net/phy/Kconfig
> > @@ -197,6 +197,12 @@ config PHY_MSCC
> > config PHY_NATSEMI
> > bool "National Semiconductor Ethernet PHYs support"
> >
> > +config PHY_NXP_C45_TJA11XX
> > + tristate "NXP C45 TJA11XX PHYs"
> > + help
> > + Enable support for NXP C45 TJA11XX PHYs.
> > + Currently supports only the TJA1103 PHY.
> > +
> > config PHY_REALTEK
> > bool "Realtek Ethernet PHYs support"
> >
> > diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
> > index e967f82201..218b8c7669 100644
> > --- a/drivers/net/phy/Makefile
> > +++ b/drivers/net/phy/Makefile
> > @@ -23,6 +23,7 @@ obj-$(CONFIG_PHY_MICREL_KSZ8XXX) += micrel_ksz8xxx.o
> > obj-$(CONFIG_PHY_MICREL_KSZ90X1) += micrel_ksz90x1.o
> > obj-$(CONFIG_PHY_MESON_GXL) += meson-gxl.o
> > obj-$(CONFIG_PHY_NATSEMI) += natsemi.o
> > +obj-$(CONFIG_PHY_NXP_C45_TJA11XX) += nxp-c45-tja11xx.o
> > obj-$(CONFIG_PHY_REALTEK) += realtek.o
> > obj-$(CONFIG_PHY_SMSC) += smsc.o
> > obj-$(CONFIG_PHY_TERANETICS) += teranetics.o
> > diff --git a/drivers/net/phy/nxp-c45-tja11xx.c
> > b/drivers/net/phy/nxp-c45-tja11xx.c
> > new file mode 100644
> > index 00..f86e31f0d9
> > --- /dev/null
> > +++ b/drivers/net/phy/nxp-c45-tja11xx.c
> > @@ -0,0 +1,348 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * NXP C45 PHY driver
> > + *
> > + * Copyright 2021 NXP
> > + * Author: Radu Pirea
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define PHY_ID_TJA_11030x001BB010
> > +
> > +#define VEND1_DEVICE_CONTROL 0x0040
> > +#define DEVICE_CONTROL_RESET BIT(15)
> > +#define DEVICE_CONTROL_CONFIG_GLOBAL_ENBIT(14)
> > +#define DEVICE_CONTROL_CONFIG_ALL_EN BIT(13)
> > +
> > +#define VEND1_PORT_CONTROL 0x8040
> > +#define PORT_CONTROL_ENBIT(14)
> > +
> > +#define VEND1_PHY_CONTROL 0x8100
> > +#define PHY_CONFIG_EN BIT(14)
> > +#define PHY_START_OP BIT(0)
> > +
> > +#define VEND1_PHY_CONFIG 0x8108
> > +#define PHY_CONFIG_AUTOBIT(0)
> > +
> > +#define VEND1_PORT_INFRA_CONTROL 0xAC00
> > +#define PORT_INFRA_CONTROL_EN BIT(14)
> > +
> > +#define VEND1_RXID 0xAFCC
> > +#define VEND1_TXID 0xAFCD
> > +#define ID_ENABLE BIT(15)
> > +
> > +#define VEND1_ABILITIES0xAFC4
> > +#define RGMII_ID_ABILITY BIT(15)
> > +#define RGMII_ABILITY BIT(14)
> > +#define RMII_ABILITY BIT(10)
> > +#define REVMII_ABILITY BIT(9)
> > +#define MII_ABILITYBIT(8)
> > +#define SGMII_ABILITY BIT(0)
> > +
> > +#define VEND1_MII_BASIC_CONFIG 0xAFC6
> > +#define MII_BASIC_CONFIG_REV BIT(8)
> > +#define MII_BASIC_CONFIG_SGMII 0x9
> > +#define MII_BASIC_CONFIG_RGMII 0x7
> > +#define MII_BASIC_CONFIG_RMII 0x5
> > +#define MII_BASIC_CONFIG_MII 0x4
> > +
> > +#define RGMII_PERIOD_PS8000U
> > +#define PS_PER_DEGREE div_u64(RGMII_PERIOD_PS, 360)
> > +#define MIN_ID_PS 1644U
> > +#define MAX_ID_PS 2260U
> > +#define DEFAULT_ID_PS 2000U
> > +
> > +#define RESET_DELAY_MS 25
> > +#define CONF_EN_DELAY_US 450
> > +
> > +struct nxp_c45_phy {
> > + u32 tx_delay;
> > + u32 rx_delay;
> > +};
> > +
> > +static int nxp_c45_soft_reset(struct phy_device *phydev)
> > +{
> > + int tries = 10, ret;
> > +
>
Re: [PULL] u-boot-network/network_master
On Wed, Jun 30, 2021 at 12:52:59AM +0300, Ramon Fried wrote: > On Fri, Jun 18, 2021 at 8:17 PM Tom Rini wrote: > > > > On Fri, Jun 18, 2021 at 02:42:50PM +0300, Ramon Fried wrote: > > > > > Hi Tom, > > > > > > Please pull the latest patches in u-boot-net tree. > > > > > > The following changes since commit > > > a298d4fbcdba1b38e48ea2af0fc5386cab2070da: > > > > > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq > > > (2021-06-17 08:44:56 -0400) > > > > > > are available in the Git repository at: > > > > > > g...@source.denx.de:u-boot/custodians/u-boot-net.git network_master > > > > Please note that a tag with a short summary of the changes is preferred, > > but not required. Also, if you have something like this: > > [remote "network"] > > fetch = +refs/heads/*:refs/remotes/origin/* > > url = https://source.denx.de/u-boot/custodians/u-boot-net.git > > pushurl = g...@source.denx.de:u-boot/custodians/u-boot-net.git > > > > in your .git/config when you use git request-pull it should give the > > non-ssh URI. > > > > > for you to fetch changes up to 54c321f9deeba309989f0828e4d0427cbfbefcd3: > > > > > > net: octeontx: smi: use dt live tree API (2021-06-18 11:29:17 +0300) > > > > > > > Applied to u-boot/master, thanks! > > > > -- > > Tom > Hi. > Out of curiosity, why do you prepare non-ssh URI ? I like for the git history to contain public URIs just in case folks are tracking along or otherwise using the information for some reason. -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-network/network_master
On Fri, Jun 18, 2021 at 8:17 PM Tom Rini wrote: > > On Fri, Jun 18, 2021 at 02:42:50PM +0300, Ramon Fried wrote: > > > Hi Tom, > > > > Please pull the latest patches in u-boot-net tree. > > > > The following changes since commit a298d4fbcdba1b38e48ea2af0fc5386cab2070da: > > > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq > > (2021-06-17 08:44:56 -0400) > > > > are available in the Git repository at: > > > > g...@source.denx.de:u-boot/custodians/u-boot-net.git network_master > > Please note that a tag with a short summary of the changes is preferred, > but not required. Also, if you have something like this: > [remote "network"] > fetch = +refs/heads/*:refs/remotes/origin/* > url = https://source.denx.de/u-boot/custodians/u-boot-net.git > pushurl = g...@source.denx.de:u-boot/custodians/u-boot-net.git > > in your .git/config when you use git request-pull it should give the > non-ssh URI. > > > for you to fetch changes up to 54c321f9deeba309989f0828e4d0427cbfbefcd3: > > > > net: octeontx: smi: use dt live tree API (2021-06-18 11:29:17 +0300) > > > > Applied to u-boot/master, thanks! > > -- > Tom Hi. Out of curiosity, why do you prepare non-ssh URI ? Thanks, Ramon
Re: [PATCH v3 2/3] mmc: rockchip_sdhci: Add support for RK3568
On 6/29/21 5:24 PM, Yifeng Zhao wrote:
> This patch adds support for the RK3568 platform to this driver.
>
> Signed-off-by: Yifeng Zhao
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> Changes in v3:
> - Config the interface clock by clk_set_rate directly
>
> Changes in v2:
> - Used sdhci_set_clock api to set clock.
> - Used read_poll_timeout api to check dll status.
>
> drivers/mmc/rockchip_sdhci.c | 109 +++
> 1 file changed, 109 insertions(+)
>
> diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
> index eff134c8f5..1ac00587d4 100644
> --- a/drivers/mmc/rockchip_sdhci.c
> +++ b/drivers/mmc/rockchip_sdhci.c
> @@ -42,6 +42,34 @@
> x) >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK) ==\
> PHYCTRL_DLLRDY_DONE)
>
> +/* Rockchip specific Registers */
> +#define DWCMSHC_EMMC_DLL_CTRL0x800
> +#define DWCMSHC_EMMC_DLL_CTRL_RESET BIT(1)
> +#define DWCMSHC_EMMC_DLL_RXCLK 0x804
> +#define DWCMSHC_EMMC_DLL_TXCLK 0x808
> +#define DWCMSHC_EMMC_DLL_STRBIN 0x80c
> +#define DWCMSHC_EMMC_DLL_STATUS0 0x840
> +#define DWCMSHC_EMMC_DLL_STATUS1 0x844
> +#define DWCMSHC_EMMC_DLL_START BIT(0)
> +#define DWCMSHC_EMMC_DLL_RXCLK_SRCSEL29
> +#define DWCMSHC_EMMC_DLL_START_POINT 16
> +#define DWCMSHC_EMMC_DLL_START_DEFAULT 5
> +#define DWCMSHC_EMMC_DLL_INC_VALUE 2
> +#define DWCMSHC_EMMC_DLL_INC 8
> +#define DWCMSHC_EMMC_DLL_DLYENA BIT(27)
> +#define DLL_TXCLK_TAPNUM_DEFAULT 0x10
> +#define DLL_STRBIN_TAPNUM_DEFAULT0x3
> +#define DLL_TXCLK_TAPNUM_FROM_SW BIT(24)
> +#define DWCMSHC_EMMC_DLL_LOCKED BIT(8)
> +#define DWCMSHC_EMMC_DLL_TIMEOUT BIT(9)
> +#define DLL_RXCLK_NO_INVERTER1
> +#define DLL_RXCLK_INVERTER 0
> +#define DWCMSHC_ENHANCED_STROBE BIT(8)
> +#define DLL_LOCK_WO_TMOUT(x) \
> + x) & DWCMSHC_EMMC_DLL_LOCKED) == DWCMSHC_EMMC_DLL_LOCKED) && \
> + (((x) & DWCMSHC_EMMC_DLL_TIMEOUT) == 0))
> +#define ROCKCHIP_MAX_CLKS3
> +
> struct rockchip_sdhc_plat {
> struct mmc_config cfg;
> struct mmc mmc;
> @@ -167,6 +195,77 @@ static int rk3399_sdhci_emmc_set_clock(struct sdhci_host
> *host, unsigned int clo
> return 0;
> }
>
> +static int rk3568_emmc_phy_init(struct udevice *dev)
> +{
> + struct rockchip_sdhc *prv = dev_get_priv(dev);
> + struct sdhci_host *host = &prv->host;
> + u32 extra;
> +
> + extra = DLL_RXCLK_NO_INVERTER << DWCMSHC_EMMC_DLL_RXCLK_SRCSEL;
> + sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_RXCLK);
> +
> + return 0;
> +}
> +
> +static int rk3568_sdhci_emmc_set_clock(struct sdhci_host *host, unsigned int
> clock)
> +{
> + struct rockchip_sdhc *priv = container_of(host, struct rockchip_sdhc,
> host);
> + int val, ret;
> + u32 extra;
> +
> + if (clock > host->max_clk)
> + clock = host->max_clk;
> + if (clock)
> + clk_set_rate(&priv->emmc_clk, clock);
> +
> + sdhci_set_clock(host->mmc, clock);
> +
> + if (clock >= 100 * MHz) {
> + /* reset DLL */
> + sdhci_writel(host, DWCMSHC_EMMC_DLL_CTRL_RESET,
> DWCMSHC_EMMC_DLL_CTRL);
> + udelay(1);
> + sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_CTRL);
> +
> + /* Init DLL settings */
> + extra = DWCMSHC_EMMC_DLL_START_DEFAULT <<
> DWCMSHC_EMMC_DLL_START_POINT |
> + DWCMSHC_EMMC_DLL_INC_VALUE << DWCMSHC_EMMC_DLL_INC |
> + DWCMSHC_EMMC_DLL_START;
> + sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_CTRL);
> +
> + ret = read_poll_timeout(readl, host->ioaddr +
> DWCMSHC_EMMC_DLL_STATUS0,
> + val, DLL_LOCK_WO_TMOUT(val), 1, 500);
> + if (ret)
> + return ret;
> +
> + extra = DWCMSHC_EMMC_DLL_DLYENA |
> + DLL_RXCLK_NO_INVERTER << DWCMSHC_EMMC_DLL_RXCLK_SRCSEL;
> + sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_RXCLK);
> +
> + extra = DWCMSHC_EMMC_DLL_DLYENA |
> + DLL_TXCLK_TAPNUM_DEFAULT |
> + DLL_TXCLK_TAPNUM_FROM_SW;
> + sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_TXCLK);
> +
> + extra = DWCMSHC_EMMC_DLL_DLYENA |
> + DLL_STRBIN_TAPNUM_DEFAULT;
> + sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_STRBIN);
> + } else {
> + /* reset the clock phase when the frequency is lower than
> 100MHz */
> + sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_CTRL);
> + extra = DLL_RXCLK_NO_INVERTER << DWCMSHC_EMMC_DLL_RXCLK_SRCSEL;
> + sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_RXCLK);
> + sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_TXCLK);
> + sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_STRBIN);
> + }
> +
> +
Re: [PATCH v3 1/3] mmc: rockchip_sdhci: add phy and clock config for rk3399
On 6/29/21 5:24 PM, Yifeng Zhao wrote:
> Add clock, phy and other configuration, it is convenient to support
> new controller. Here a short summary of the changes:
> - Add mmc_of_parse to parse dts config.
> - Remove OF_PLATDATA related code.
> - Reorder header inclusion.
> - Add phy ops.
> - add ops set_ios_post to modify the parameters of phy when the
> clock changes.
> - Add execute tuning api for hs200 tuning.
>
> Signed-off-by: Yifeng Zhao
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
>
> Changes in v3:
> - Optimize hs200 tuning function.
> - Add check for callback function.
> - Add return value for tuning function.
> - Fixed source clock rate with host->max_clk, the interface clock is divided
> from the source clock.
>
> Changes in v2:
> - Add mmc_of_parse to parse dts config.
> - Used read_poll_timeout api to check dll lock status
> - Add execute tuning api for hs200 tuning
>
> drivers/mmc/rockchip_sdhci.c | 313 +++
> 1 file changed, 277 insertions(+), 36 deletions(-)
>
> diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
> index d95f8b2a15..eff134c8f5 100644
> --- a/drivers/mmc/rockchip_sdhci.c
> +++ b/drivers/mmc/rockchip_sdhci.c
> @@ -6,90 +6,322 @@
> */
>
> #include
> +#include
> #include
> +#include
> #include
> +#include
> #include
> #include
> +#include
> #include
> #include
> +#include "mmc_private.h"
> #include
> -#include
> +#include
> +#include
> +#include
>
> /* 400KHz is max freq for card ID etc. Use that as min */
> #define EMMC_MIN_FREQ40
> +#define KHz (1000)
> +#define MHz (1000 * KHz)
> +#define SDHCI_TUNING_LOOP_COUNT 40
> +
> +#define PHYCTRL_CALDONE_MASK 0x1
> +#define PHYCTRL_CALDONE_SHIFT0x6
> +#define PHYCTRL_CALDONE_DONE 0x1
> +#define PHYCTRL_DLLRDY_MASK 0x1
> +#define PHYCTRL_DLLRDY_SHIFT 0x5
> +#define PHYCTRL_DLLRDY_DONE 0x1
> +#define PHYCTRL_FREQSEL_200M 0x0
> +#define PHYCTRL_FREQSEL_50M 0x1
> +#define PHYCTRL_FREQSEL_100M 0x2
> +#define PHYCTRL_FREQSEL_150M 0x3
> +#define PHYCTRL_DLL_LOCK_WO_TMOUT(x) \
> + x) >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK) ==\
> + PHYCTRL_DLLRDY_DONE)
>
> struct rockchip_sdhc_plat {
> -#if CONFIG_IS_ENABLED(OF_PLATDATA)
> - struct dtd_rockchip_rk3399_sdhci_5_1 dtplat;
> -#endif
> struct mmc_config cfg;
> struct mmc mmc;
> };
>
> +struct rockchip_emmc_phy {
> + u32 emmcphy_con[7];
> + u32 reserved;
> + u32 emmcphy_status;
> +};
> +
> struct rockchip_sdhc {
> struct sdhci_host host;
> + struct udevice *dev;
> void *base;
> + struct rockchip_emmc_phy *phy;
> + struct clk emmc_clk;
> +};
> +
> +struct sdhci_data {
> + int (*emmc_set_clock)(struct sdhci_host *host, unsigned int clock);
> + int (*emmc_phy_init)(struct udevice *dev);
> + int (*get_phy)(struct udevice *dev);
> +};
> +
> +static int rk3399_emmc_phy_init(struct udevice *dev)
> +{
> + return 0;
> +}
> +
> +static void rk3399_emmc_phy_power_on(struct rockchip_emmc_phy *phy, u32
> clock)
> +{
> + u32 caldone, dllrdy, freqsel;
> +
> + writel(RK_CLRSETBITS(7 << 4, 0), &phy->emmcphy_con[6]);
> + writel(RK_CLRSETBITS(1 << 11, 1 << 11), &phy->emmcphy_con[0]);
> + writel(RK_CLRSETBITS(0xf << 7, 6 << 7), &phy->emmcphy_con[0]);
> +
> + /*
> + * According to the user manual, calpad calibration
> + * cycle takes more than 2us without the minimal recommended
> + * value, so we may need a little margin here
> + */
> + udelay(3);
> + writel(RK_CLRSETBITS(1, 1), &phy->emmcphy_con[6]);
> +
> + /*
> + * According to the user manual, it asks driver to
> + * wait 5us for calpad busy trimming. But it seems that
> + * 5us of caldone isn't enough for all cases.
> + */
> + udelay(500);
> + caldone = readl(&phy->emmcphy_status);
> + caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
> + if (caldone != PHYCTRL_CALDONE_DONE) {
> + printf("%s: caldone timeout.\n", __func__);
> + return;
> + }
> +
> + /* Set the frequency of the DLL operation */
> + if (clock < 75 * MHz)
> + freqsel = PHYCTRL_FREQSEL_50M;
> + else if (clock < 125 * MHz)
> + freqsel = PHYCTRL_FREQSEL_100M;
> + else if (clock < 175 * MHz)
> + freqsel = PHYCTRL_FREQSEL_150M;
> + else
> + freqsel = PHYCTRL_FREQSEL_200M;
> +
> + /* Set the frequency of the DLL operation */
> + writel(RK_CLRSETBITS(3 << 12, freqsel << 12), &phy->emmcphy_con[0]);
> + writel(RK_CLRSETBITS(1 << 1, 1 << 1), &phy->emmcphy_con[6]);
> +
> + read_poll_timeout(readl, &phy->emmcphy_status, dllrdy,
> + PHYCTRL_DLL_LOCK_WO_TMOUT(dllrdy), 1, 5000);
> +}
> +
> +static void rk3399_emmc_phy_power_off(struct rockchip_emmc_phy
Re: [PATCH] arm: Add (back) VExpress boards support
On Tue, Jun 29, 2021 at 05:52:10PM +0100, Andre Przywara wrote: > On Tue, 29 Jun 2021 15:15:52 +0100 > Andre Przywara wrote: > > Hi, > > > On Tue, 29 Jun 2021 08:11:22 -0400 > > Tom Rini wrote: > > > > > On Tue, Jun 29, 2021 at 12:45:55PM +0100, Andre Przywara wrote: > > > > > > > The v2021.07 merge window saw the removal of the Arm Ltd. Versatile > > > > Express platform, along with their CA5, CA9 and TC2 boards. The trigger > > > > was the missing conversion of the MMC driver. > > > > > > > > Some folks complained about that internally, so bring those boards back, > > > > but better than ever: > > > > - Use DM and OF_CONTROL for all the boards. Use the .dts files from the > > > > latest Linux kernel (5.13) for that. > > > > - Move the board selection choice into the platform's Kconfig. > > > > - Clean up some shared config and common definitions. > > > > - Drop obsolete features like ATAGs support. > > > > - Switch to the DM_ETH version of the SMC911X Ethernet driver. > > > > - Drop MMC support. > > > > > > > > The PL180 MMC driver actually supports DM_MMC, but that requires a > > > > DM_GPIO driver for the card detect GPIO, which we don't have. This > > > > specific GPIO is actually handled via the "sysregs" device, so we would > > > > need a driver for that. QEMU does not emulate this part, also the DT > > > > description is somewhat "special", so this is left for later. > > > > > > > > This version compiles without any warning for all three boards now. > > > > Tested on QEMU. > > > > > > > > Signed-off-by: Andre Przywara > > > > --- > > > > Hi, > > > > > > > > this relies on the SMC911x driver DT changes, as posted here: > > > > https://lists.denx.de/pipermail/u-boot/2021-June/452989.html > > > > I put a version with the changes broken down here: > > > > https://github.com/Andre-ARM/u-boot/commits/tc2-history > > > > > > > > This was tested on QEMU, for vexpress_ca15_tc2_defconfig with: > > > > $ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G -smp > > > > 1 \ > > > > -drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \ > > > > -device loader,file=u-boot.bin,addr=0x8080 -nographic > > > > > > > > Where tramp-tc2.bin is a trampoline replacing the board's firmware: > > > > 00 00 a0 e3 80 00 48 e3 10 ff 2f e1 > > > > (mov r0, #0; movt r0, #0x8080; bx r0) > > > > > > > > The vexpress_ca9x4_defconfig uses a different memory map, so the runes > > > > are: > > > > $ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \ > > > > -drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \ > > > > -device loader,file=u-boot.bin,addr=0x6080 -nographic > > > > > > > > tramp-ca9.bin: > > > > 00 00 a0 e3 80 00 46 e3 10 ff 2f e1 > > > > (mov r0, #0; movt r0, #0x6080; bx r0) > > > > > > My big question is how do we run this in CI? Or does it not _need_ that > > > firmware file to really exist? Or is there a pending change to > > > https://gitlab.denx.de/u-boot/u-boot-test-hooks.git to generate / just > > > have exist those magic empty bins? Thanks! > > > > So from digging into this I see that this loads U-Boot's ELF build, via > > QEMU's -kernel parameter. Which is fine, but not really what is > > happening on real hardware. > > I checked and the v2021.04 version worked with this approach, but my > > build does not. > > I will have a look into this now. > > The new build uses OF_CONTROL and OF_SEPARATE, so the DTB gets appended > to the U-Boot *image*. The ELF file is not treated this way, so the > code reads only 0s after the end of the U-Boot code - which makes it > die silently. Manually loading the DTB into DRAM would be fragile at > best, but is also rejected by QEMU, because the LOAD program header > extend for a few dozen bytes beyond U-Boot's "end" symbol, so it > overlaps. Can't we pass the device tree to qemu (and in turn through to U-Boot) in a clean and out of the box way? I thought there was a way to do that.. > IIRC we don't have position independent code for ARM, so we can't load > U-Boot into flash directly (which also would require some code changes > first). Do you mean generate a file to use as the system flash and have U-Boot be in the correct spot within that file? If so bin/travis-ci/conf.qemu_mips_na in the test hooks repo might give you some hints. > Anyway I don't think we should change any code to cope with that (by > using another method to find the DTB), so adjusting the QEMU recipe > sounds like a better idea. > > Is there a way to add those 12 byte trampoline files to the CI repo? Or > shall they be created on the fly somehow? If we need to include the trampoline files, however it's easiest is fine. -- Tom signature.asc Description: PGP signature
[RESEND PATCH v7 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.
- V6
. change type of address
. move declarations ahead
. loop style update
- V7
. dm updates
. fix indentations
. style fixes to improve readability
. add write support for mmc cards
Signed-off-by: Tianrui Wei
Signed-off-by: Jonathan Balkind
---
drivers/mmc/Kconfig | 9 ++
drivers/mmc/Makefile| 1 +
drivers/mmc/piton_mmc.c | 181
3 files changed, 191 insertions(+)
create mode 100644 drivers/mmc/piton_mmc.c
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 8901456967..4948e194e7 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..8517ec8410
--- /dev/null
+++ b/drivers/mmc/piton_mmc.c
@@ -0,0 +1,181 @@
+// 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 *piton_mmc_base_addr; /* peripheral id */
+};
+
+/*
+ * see mmc_read_blocks to see how it is used.
+ * start block is hidden at cmd->arg
+ * also, initialize the block size at init
+ */
+static int piton_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
+ /* check first if this is a pure command */
+ 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->piton_mmc_base_addr + start_block;
+
+ /* if there is a read */
+ if (data->flags & MMC_DATA_READ) {
+ for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
+byte_cnt -= sizeof(u32)) {
+ *buff++ = readl(start_addr++);
+ }
+ } else {
+ for (byte_cnt = data->blocks * data->blocksize; byte_cnt;
+byte_cnt -= sizeof(u32)) {
+ 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;
+ /* fill in device description */
+ struct blk_desc *bdesc;
+
+ priv->piton_mmc_base_addr = (void *)dev_read_addr(dev);
+ cfg = &plat->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 = &plat->mmc;
+ mmc->read_bl_len = MMC_MAX_BLOCK_LEN;
+ mmc->capacity_user = PITON_MMC_DUMMY_CAPACITY;
+ mmc->capacity_user *= mmc->read_bl_len;
+ m
[RESEND PATCH v7 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
- V6
. separate defconfigs for u-boot and SPL
. eliminate debug console output
. style updates
- V7
. update Kconfig for OpenPiton board
. SPL defconfig updates
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
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 = &uart0;
+ serial0 = &uart0;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ timebase-frequency = <520835>;
+
+ CPU0: cpu@0 {
+ clocks = <&clk0>;
+ 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 = <&clk0>;
+ device_type = "cpu";
+
[RESEND PATCH v7 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 Acknowledgements We'd like to thank all maintainers who have reviewed our code. But we'd like to thank Sean and Jaehoon 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 | 181 ++ include/configs/openpiton-riscv64.h | 61 16 files changed, 1045 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 v3 7/7] net: enetc: propagate the return code from phy_startup() to eth_ops::start
Make sure that errors in the PHY driver .startup() method, such as no link, are propagated and not ignored. Signed-off-by: Vladimir Oltean --- v2->v3: patch is new drivers/net/fsl_enetc.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c index 6a5a38c1ffe2..566cdc7e546a 100644 --- a/drivers/net/fsl_enetc.c +++ b/drivers/net/fsl_enetc.c @@ -568,11 +568,9 @@ static int enetc_start(struct udevice *dev) enetc_setup_tx_bdr(dev); enetc_setup_rx_bdr(dev); - phy_startup(priv->phy); - enetc_setup_mac_iface(dev, priv->phy); - return 0; + return phy_startup(priv->phy); } /* -- 2.25.1
[PATCH v3 6/7] net: enetc: force the RGMII MAC speed/duplex instead of using in-band signaling
The RGMII spec supports optional in-band status reporting for the speed
and duplex negotiated on the copper side, and the ENETC driver enables
this feature by default.
However, this does not work when the PHY does not implement the in-band
reporting, or when there is a MAC-to-MAC connection described using a
fixed-link. In that case, it would be better to disable the feature in
the ENETC MAC and always force the speed and duplex to the values that
were negotiated and retrieved over MDIO once the autoneg is finished.
Since this works always, we just do it unconditionally and drop the
in-band code.
Note that because we need to wait for the autoneg to complete, we need
to move enetc_setup_mac_iface() after phy_startup() returns, and then
pass the phydev pointer all the way to enetc_init_rgmii().
The same considerations have led to a similar Linux driver patch as well:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=c76a97218dcbb2cb7cec1404ace43ef96c87d874
Copyright updated according to corporate requirements.
Signed-off-by: Vladimir Oltean
---
v2->v3: update copyright
v1->v2: none
drivers/net/fsl_enetc.c | 44 ++---
drivers/net/fsl_enetc.h | 7 ++-
2 files changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index 9c198a1039d2..6a5a38c1ffe2 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -178,21 +178,43 @@ static int enetc_init_sgmii(struct udevice *dev)
}
/* set up MAC for RGMII */
-static int enetc_init_rgmii(struct udevice *dev)
+static void enetc_init_rgmii(struct udevice *dev, struct phy_device *phydev)
{
struct enetc_priv *priv = dev_get_priv(dev);
- u32 if_mode;
+ u32 old_val, val;
- /* enable RGMII AN */
- if_mode = enetc_read_port(priv, ENETC_PM_IF_MODE);
- if_mode |= ENETC_PM_IF_MODE_AN_ENA;
- enetc_write_port(priv, ENETC_PM_IF_MODE, if_mode);
+ old_val = val = enetc_read_port(priv, ENETC_PM_IF_MODE);
- return 0;
+ /* disable unreliable RGMII in-band signaling and force the MAC into
+* the speed negotiated by the PHY.
+*/
+ val &= ~ENETC_PM_IF_MODE_AN_ENA;
+
+ if (phydev->speed == SPEED_1000) {
+ val &= ~ENETC_PM_IFM_SSP_MASK;
+ val |= ENETC_PM_IFM_SSP_1000;
+ } else if (phydev->speed == SPEED_100) {
+ val &= ~ENETC_PM_IFM_SSP_MASK;
+ val |= ENETC_PM_IFM_SSP_100;
+ } else if (phydev->speed == SPEED_10) {
+ val &= ~ENETC_PM_IFM_SSP_MASK;
+ val |= ENETC_PM_IFM_SSP_10;
+ }
+
+ if (phydev->duplex == DUPLEX_FULL)
+ val |= ENETC_PM_IFM_FULL_DPX;
+ else
+ val &= ~ENETC_PM_IFM_FULL_DPX;
+
+ if (val == old_val)
+ return;
+
+ enetc_write_port(priv, ENETC_PM_IF_MODE, val);
}
/* set up MAC configuration for the given interface type */
-static void enetc_setup_mac_iface(struct udevice *dev)
+static void enetc_setup_mac_iface(struct udevice *dev,
+ struct phy_device *phydev)
{
struct enetc_priv *priv = dev_get_priv(dev);
u32 if_mode;
@@ -202,7 +224,7 @@ static void enetc_setup_mac_iface(struct udevice *dev)
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_TXID:
- enetc_init_rgmii(dev);
+ enetc_init_rgmii(dev, phydev);
break;
case PHY_INTERFACE_MODE_XGMII:
case PHY_INTERFACE_MODE_USXGMII:
@@ -546,10 +568,10 @@ static int enetc_start(struct udevice *dev)
enetc_setup_tx_bdr(dev);
enetc_setup_rx_bdr(dev);
- enetc_setup_mac_iface(dev);
-
phy_startup(priv->phy);
+ enetc_setup_mac_iface(dev, priv->phy);
+
return 0;
}
diff --git a/drivers/net/fsl_enetc.h b/drivers/net/fsl_enetc.h
index 110c1d78fbc6..69f2f4aaff1e 100644
--- a/drivers/net/fsl_enetc.h
+++ b/drivers/net/fsl_enetc.h
@@ -1,7 +1,7 @@
/* SPDX-License-Identifier: GPL-2.0+ */
/*
* ENETC ethernet controller driver
- * Copyright 2017-2019 NXP
+ * Copyright 2017-2021 NXP
*/
#ifndef _ENETC_H
@@ -77,6 +77,11 @@ enum enetc_bdr_type {TX, RX};
#define ENETC_PM_IF_MODE 0x8300
#define ENETC_PM_IF_MODE_RG BIT(2)
#define ENETC_PM_IF_MODE_AN_ENA BIT(15)
+#define ENETC_PM_IFM_SSP_MASK GENMASK(14, 13)
+#define ENETC_PM_IFM_SSP_1000 (2 << 13)
+#define ENETC_PM_IFM_SSP_100 (0 << 13)
+#define ENETC_PM_IFM_SSP_10 (1 << 13)
+#define ENETC_PM_IFM_FULL_DPX BIT(12)
#define ENETC_PM_IF_IFMODE_MASK GENMASK(1, 0)
/* buffer descriptors count must be multiple of 8 and aligned to 128 bytes */
--
2.25.1
[PATCH v3 5/7] net: enetc: require a PHY device when probing
Given that even a fixed-link has an associated phy_device, there is no
reason to operate in a mode when dm_eth_phy_connect fails.
Remove the driver checks for a NULL priv->phy and just return -ENODEV
when that happens.
Copyright updated according to corporate requirements.
Signed-off-by: Vladimir Oltean
Reviewed-by: Ramon Fried
---
v2->v3: update copyright
v1->v2: none
drivers/net/fsl_enetc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/net/fsl_enetc.c b/drivers/net/fsl_enetc.c
index f6fc7801b95b..9c198a1039d2 100644
--- a/drivers/net/fsl_enetc.c
+++ b/drivers/net/fsl_enetc.c
@@ -1,7 +1,7 @@
// SPDX-License-Identifier: GPL-2.0+
/*
* ENETC ethernet controller driver
- * Copyright 2017-2019 NXP
+ * Copyright 2017-2021 NXP
*/
#include
@@ -281,21 +281,20 @@ static void enetc_start_pcs(struct udevice *dev)
}
/* Configure the actual/external ethernet PHY, if one is found */
-static void enetc_config_phy(struct udevice *dev)
+static int enetc_config_phy(struct udevice *dev)
{
struct enetc_priv *priv = dev_get_priv(dev);
int supported;
priv->phy = dm_eth_phy_connect(dev);
-
if (!priv->phy)
- return;
+ return -ENODEV;
supported = PHY_GBIT_FEATURES | SUPPORTED_2500baseX_Full;
priv->phy->supported &= supported;
priv->phy->advertising &= supported;
- phy_config(priv->phy);
+ return phy_config(priv->phy);
}
/*
@@ -335,9 +334,8 @@ static int enetc_probe(struct udevice *dev)
dm_pci_clrset_config16(dev, PCI_COMMAND, 0, PCI_COMMAND_MEMORY);
enetc_start_pcs(dev);
- enetc_config_phy(dev);
- return 0;
+ return enetc_config_phy(dev);
}
/*
@@ -550,8 +548,7 @@ static int enetc_start(struct udevice *dev)
enetc_setup_mac_iface(dev);
- if (priv->phy)
- phy_startup(priv->phy);
+ phy_startup(priv->phy);
return 0;
}
--
2.25.1
[PATCH v3 4/7] arm: dts: ls1028a: disable enetc-2 by default
The enetc-2 port is used as DSA master (connected back-to-back to
mscc_felix_port4). Since the convention is to not enable ports in the
common SoC dtsi unless they are used on the board, then enable enetc-2
only when mscc_felix_port4 itself is enabled.
All existing device trees appear to adhere to this rule, so disable
enetc-2 in the SoC dtsi.
Signed-off-by: Vladimir Oltean
---
v2->v3: none
v1->v2: none
arch/arm/dts/fsl-ls1028a.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index 21f4ef78a059..50f9b527cde1 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -142,7 +142,7 @@
};
enetc2: pci@0,2 {
reg = <0x000200 0 0 0 0>;
- status = "okay";
+ status = "disabled";
phy-mode = "internal";
fixed-link {
--
2.25.1
[PATCH v3 3/7] arm: dts: ls1028a: declare the fixed-link speeds for the internal ENETC ports
To comply with the device tree bindings expectations for an Ethernet
controller, as well as to simplify the driver code, declare fixed-link
nodes for the internal ENETC ports (attached to the mscc_felix switch).
Signed-off-by: Vladimir Oltean
---
v2->v3: none
v1->v2: none
arch/arm/dts/fsl-ls1028a.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a.dtsi b/arch/arm/dts/fsl-ls1028a.dtsi
index c7c725a4fc84..21f4ef78a059 100644
--- a/arch/arm/dts/fsl-ls1028a.dtsi
+++ b/arch/arm/dts/fsl-ls1028a.dtsi
@@ -144,12 +144,22 @@
reg = <0x000200 0 0 0 0>;
status = "okay";
phy-mode = "internal";
+
+ fixed-link {
+ speed = <2500>;
+ full-duplex;
+ };
};
mdio0: pci@0,3 {
#address-cells=<0>;
#size-cells=<1>;
reg = <0x000300 0 0 0 0>;
status = "disabled";
+
+ fixed-link {
+ speed = <1000>;
+ full-duplex;
+ };
};
mscc_felix: pci@0,5 {
--
2.25.1
[PATCH v3 2/7] arm: dts: ls1028a: enable internal RGMII delays for the LS1028A-QDS AR8035 PHY
There are no PCB trace delays on this board, so the PHY needs to enable
its internal ones in order to have a proper electrical connection to the
enetc MAC.
Fixes: b32e9a757837 ("arm: dts: ls1028a updates for network interfaces")
Signed-off-by: Vladimir Oltean
---
v2->v3: none
v1->v2: none
arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1028a-qds.dtsi
b/arch/arm/dts/fsl-ls1028a-qds.dtsi
index da89ff96e98c..69632fa796b5 100644
--- a/arch/arm/dts/fsl-ls1028a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds.dtsi
@@ -251,7 +251,7 @@
&enetc1 {
status = "okay";
- phy-mode = "rgmii";
+ phy-mode = "rgmii-id";
phy-handle = <&qds_phy0>;
};
--
2.25.1
[PATCH v3 1/7] arm: dts: ls1028a: enable the switch CPU port for the LS1028A-QDS
Due to an upstream change, the ls1028a.dtsi bindings for the mscc_felix
switch got accepted with all ports disabled by default and with no link
to the DSA master - this needs to be done on a per board basis.
Note that enetc-2 is not currently disabled in the ls1028a.dtsi, but
presumably at some point it might become. Explicitly enable it in the
QDS device trees anyway, to proactively avoid issues when that happens.
Fixes: a7fdac7e2a2a ("arm: dts: ls1028a: define QDS networking protocol
combinations")
Signed-off-by: Vladimir Oltean
---
v2->v3: none
v1->v2: none
arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi | 9 +
arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 9 +
arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 9 +
arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi | 9 +
arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 9 +
arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 9 +
arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 9 +
arch/arm/dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 9 +
8 files changed, 72 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
index fb1836a8aef3..5a0f060c16e5 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-30841.dtsi
@@ -20,6 +20,10 @@
#include "fsl-sch-30841.dtsi"
};
+&enetc2 {
+ status = "okay";
+};
+
&mscc_felix {
status = "okay";
};
@@ -47,3 +51,8 @@
phy-mode = "sgmii-2500";
phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
};
+
+&mscc_felix_port4 {
+ ethernet = <&enetc2>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
index 1d02a3e11def..39a83e10c4ce 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi
@@ -9,6 +9,10 @@
#include "fsl-sch-30841.dtsi"
};
+&enetc2 {
+ status = "okay";
+};
+
&mscc_felix {
status = "okay";
};
@@ -24,3 +28,8 @@
phy-mode = "sgmii-2500";
phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@03}>;
};
+
+&mscc_felix_port4 {
+ ethernet = <&enetc2>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
index c92dd1bd2e95..021fe3fbc67a 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
@@ -34,6 +34,10 @@
#include "fsl-sch-24801.dtsi"
};
+&enetc2 {
+ status = "okay";
+};
+
&mscc_felix {
status = "okay";
};
@@ -61,3 +65,8 @@
phy-mode = "sgmii";
phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
};
+
+&mscc_felix_port4 {
+ ethernet = <&enetc2>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
index 941f7472eb09..b6704d8089a8 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
@@ -19,6 +19,10 @@
#include "fsl-sch-24801.dtsi"
};
+&enetc2 {
+ status = "okay";
+};
+
&mscc_felix {
status = "okay";
};
@@ -46,3 +50,8 @@
phy-mode = "sgmii";
phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
};
+
+&mscc_felix_port4 {
+ ethernet = <&enetc2>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
index 7e483e656e28..8c10897e565c 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
@@ -19,6 +19,10 @@
#include "fsl-sch-30841.dtsi"
};
+&enetc2 {
+ status = "okay";
+};
+
&mscc_felix {
status = "okay";
};
@@ -46,3 +50,8 @@
phy-mode = "usxgmii";
phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@03}>;
};
+
+&mscc_felix_port4 {
+ ethernet = <&enetc2>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
index 49fffdb9cb2a..1d800dacef89 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi
@@ -13,6 +13,10 @@
#include "fsl-sch-28021.dtsi"
};
+&enetc2 {
+ status = "okay";
+};
+
&mscc_felix {
status = "okay";
};
@@ -40,3 +44,8 @@
phy-mode = "qsgmii";
phy-handle = <&{/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@0b}>;
};
+
+&mscc_felix_port4 {
+ ethernet = <&enetc2>;
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi
b/
[PATCH v3 0/7] Fixes for the NXP LS1028A-QDS boards
This series fixes through patches 1, 2 and 6 networking issues seen on the LS1028A-QDS boards: - Traffic through the RGMII port enetc-1 does not work - The switch ports are not probed - RGMII fixed-link connections do not work Patches 3 and 4 are dependencies for patch 6, as follows: - Forcing the MAC speed to equal the RGMII PHY requires having a PHY unconditionally in the enetc driver - Having a PHY unconditionally requires updating the device tree to declare fixed PHYs for the internal enetc ports Finally, patches 5 and 7 are cleanup changes, which disables the DSA master port enetc-2 on LS1028A-QDS boards where the switch is not enabled, and propagate an error code. Changes in v2: Reword commit message of patch 6. Changes in v3: Update driver copyright as part of corporate requirements. Add patch 7. Vladimir Oltean (7): arm: dts: ls1028a: enable the switch CPU port for the LS1028A-QDS arm: dts: ls1028a: enable internal RGMII delays for the LS1028A-QDS AR8035 PHY arm: dts: ls1028a: declare the fixed-link speeds for the internal ENETC ports arm: dts: ls1028a: disable enetc-2 by default net: enetc: require a PHY device when probing net: enetc: force the RGMII MAC speed/duplex instead of using in-band signaling net: enetc: propagate the return code from phy_startup() to eth_ops::start .../dts/fsl-ls1028a-qds--sch-30841.dtsi | 9 +++ .../dts/fsl-ls1028a-qds-7xx7-sch-30841R.dtsi | 9 +++ .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 9 +++ .../dts/fsl-ls1028a-qds--sch-24801.dtsi | 9 +++ .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 9 +++ .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 9 +++ .../dts/fsl-ls1028a-qds-x7xx-sch-30842.dtsi | 9 +++ .../dts/fsl-ls1028a-qds-xx7x-sch-30842.dtsi | 9 +++ arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1028a.dtsi | 12 +++- drivers/net/fsl_enetc.c | 59 --- drivers/net/fsl_enetc.h | 7 ++- 12 files changed, 128 insertions(+), 24 deletions(-) -- 2.25.1
[PATCH 6/6] net: dsa: felix: propagate the error code from phy_startup()
From: Vladimir Oltean Make sure that the link status returned by phy_startup() is propagated to the .start() method of struct eth_ops. Signed-off-by: Vladimir Oltean --- drivers/net/mscc_eswitch/felix_switch.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/net/mscc_eswitch/felix_switch.c b/drivers/net/mscc_eswitch/felix_switch.c index c8ecf4f19442..6aa79784460d 100644 --- a/drivers/net/mscc_eswitch/felix_switch.c +++ b/drivers/net/mscc_eswitch/felix_switch.c @@ -352,9 +352,7 @@ static int felix_port_enable(struct udevice *dev, int port, FELIX_QSYS_SYSTEM_SW_PORT_LOSSY | FELIX_QSYS_SYSTEM_SW_PORT_SCH(1)); - phy_startup(phy); - - return 0; + return phy_startup(phy); } static void felix_port_disable(struct udevice *dev, int pidx, -- 2.25.1
[PATCH 5/6] net: dsa: felix: call phy_config at .port_probe() time
From: Vladimir Oltean
It is an unfortunate reality that some PHY settings done by U-Boot
persist even after the PHY is reset and taken over by Linux, and even
more unfortunate that Linux has come to depend on things being set in a
certain way.
For example, on the NXP LS1028A-RDB, the felix switch ports are
connected to a VSC8514 QSGMII PHY. Between the switch port PCS and the
PHY, the U-Boot drivers enable in-band auto-negotiation which makes the
copper-side negotiated speed and duplex be transmitted from the PHY to
the MAC automatically.
The PHY driver portion that does this is in vsc8514_config():
/* Enable Serdes Auto-negotiation */
phy_write(phydev, MDIO_DEVAD_NONE, PHY_EXT_PAGE_ACCESS,
PHY_EXT_PAGE_ACCESS_EXTENDED3);
val = phy_read(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON);
val = val | MIIM_VSC8574_MAC_SERDES_ANEG;
phy_write(phydev, MDIO_DEVAD_NONE, MIIM_VSC8514_MAC_SERDES_CON, val);
The point is that in-band autoneg should be turned on in both the PHY
and the MAC, or off in both the PHY and the MAC, otherwise the QSGMII
link will be broken.
And because phy_config() is currently called at .port_enable() time, the
result is that ports on which traffic has been sent in U-Boot will have
in-band autoneg enabled, and the rest won't.
It can be argued that the Linux kernel should not assume one way or
another and just reinitialize everything according to what it expects,
and that is completely fair. In fact, I've already started an attempt to
remove this dependency, although admittedly I am making slow progress at
it:
https://patchwork.kernel.org/project/netdevbpf/cover/20210212172341.3489046-1-olte...@gmail.com/
Nonetheless, the sad reality is that NXP also has, apart from kernel
drivers, some user space networking (DPDK), and for some reason, the
expectation there is that somebody else initializes the PHYs. The kernel
can't do it because the device ownership doesn't belong to the kernel,
so what remains is for the bootloader to do it (especially since other
drivers generally call phy_config() at probe time). This is a really
weak guarantee that might break at any time, but apparently that is
enough for some.
Since initializing the ports and PHYs at probe time does not break
anything, we can just do that.
Signed-off-by: Vladimir Oltean
---
drivers/net/mscc_eswitch/felix_switch.c | 22 +++---
1 file changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/net/mscc_eswitch/felix_switch.c
b/drivers/net/mscc_eswitch/felix_switch.c
index 75073880cf87..c8ecf4f19442 100644
--- a/drivers/net/mscc_eswitch/felix_switch.c
+++ b/drivers/net/mscc_eswitch/felix_switch.c
@@ -317,10 +317,23 @@ static int felix_probe(struct udevice *dev)
return 0;
}
+static int felix_port_probe(struct udevice *dev, int port,
+ struct phy_device *phy)
+{
+ int supported = PHY_GBIT_FEATURES | SUPPORTED_2500baseX_Full;
+ struct felix_priv *priv = dev_get_priv(dev);
+
+ phy->supported &= supported;
+ phy->advertising &= supported;
+
+ felix_start_pcs(dev, port, phy, &priv->imdio);
+
+ return phy_config(phy);
+}
+
static int felix_port_enable(struct udevice *dev, int port,
struct phy_device *phy)
{
- int supported = PHY_GBIT_FEATURES | SUPPORTED_2500baseX_Full;
struct felix_priv *priv = dev_get_priv(dev);
void *base = priv->regs_base;
@@ -339,12 +352,6 @@ static int felix_port_enable(struct udevice *dev, int port,
FELIX_QSYS_SYSTEM_SW_PORT_LOSSY |
FELIX_QSYS_SYSTEM_SW_PORT_SCH(1));
- felix_start_pcs(dev, port, phy, &priv->imdio);
-
- phy->supported &= supported;
- phy->advertising &= supported;
- phy_config(phy);
-
phy_startup(phy);
return 0;
@@ -392,6 +399,7 @@ static int felix_rcv(struct udevice *dev, int *pidx, void
*packet, int length)
}
static const struct dsa_ops felix_dsa_ops = {
+ .port_probe = felix_port_probe,
.port_enable= felix_port_enable,
.port_disable = felix_port_disable,
.xmit = felix_xmit,
--
2.25.1
[PATCH 4/6] net: dsa: introduce a .port_probe() method in struct dsa_ops
From: Vladimir Oltean
Some drivers might want to execute code for each port at probe time, as
opposed to executing code just-in-time for the port selected for
networking.
To cater to that use case, introduce a .port_probe() callback method
into the DSA switch operations which is called for each available port,
at the end of dsa_port_probe().
Signed-off-by: Vladimir Oltean
---
include/net/dsa.h | 5 -
net/dsa-uclass.c | 7 +++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/include/net/dsa.h b/include/net/dsa.h
index 0f31a908c9d1..ab2a9dfbea2d 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -57,7 +57,8 @@
/**
* struct dsa_ops - DSA operations
*
- * @port_enable: Initialize a switch port for I/O.
+ * @port_probe: Initialize a switch port.
+ * @port_enable: Enable I/O for a port.
* @port_disable: Disable I/O for a port.
* @xmit: Insert the DSA tag for transmission.
*DSA drivers receive a copy of the packet with headroom and
@@ -69,6 +70,8 @@
*master including any additional headers.
*/
struct dsa_ops {
+ int (*port_probe)(struct udevice *dev, int port,
+ struct phy_device *phy);
int (*port_enable)(struct udevice *dev, int port,
struct phy_device *phy);
void (*port_disable)(struct udevice *dev, int port,
diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index e23da2ed0e95..1db723573e6c 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -263,6 +263,7 @@ static void dsa_port_set_hwaddr(struct udevice *pdev,
struct udevice *master)
static int dsa_port_probe(struct udevice *pdev)
{
struct udevice *dev = dev_get_parent(pdev);
+ struct dsa_ops *ops = dsa_get_ops(dev);
struct dsa_port_pdata *port_pdata;
struct dsa_priv *dsa_priv;
struct udevice *master;
@@ -292,6 +293,12 @@ static int dsa_port_probe(struct udevice *pdev)
dsa_port_set_hwaddr(pdev, master);
+ if (ops->port_probe) {
+ err = ops->port_probe(dev, port_pdata->index,
+ port_pdata->phy);
+ if (err)
+ return err;
+ }
return 0;
}
--
2.25.1
[PATCH 3/6] net: dsa: refactor the code to set the port MAC address into a dedicated function
From: Vladimir Oltean
This snippet of code has a bothering "if (...) return 0" in it which
assumes it is the last piece of code running in dsa_port_probe().
This makes it difficult to add further code at the end of dsa_port_probe()
which does not depend on MAC address stuff.
So move the code to a dedicated function which returns void and let the
code flow through.
Signed-off-by: Vladimir Oltean
---
net/dsa-uclass.c | 35 +--
1 file changed, 21 insertions(+), 14 deletions(-)
diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 17b33834f585..e23da2ed0e95 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -240,11 +240,29 @@ static const struct eth_ops dsa_port_ops = {
.free_pkt = dsa_port_free_pkt,
};
-static int dsa_port_probe(struct udevice *pdev)
+/*
+ * Inherit port's hwaddr from the DSA master, unless the port already has a
+ * unique MAC address specified in the environment.
+ */
+static void dsa_port_set_hwaddr(struct udevice *pdev, struct udevice *master)
{
- struct udevice *dev = dev_get_parent(pdev);
struct eth_pdata *eth_pdata, *master_pdata;
unsigned char env_enetaddr[ARP_HLEN];
+
+ eth_env_get_enetaddr_by_index("eth", dev_seq(pdev), env_enetaddr);
+ if (!is_zero_ethaddr(env_enetaddr))
+ return;
+
+ master_pdata = dev_get_plat(master);
+ eth_pdata = dev_get_plat(pdev);
+ memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
+ eth_env_set_enetaddr_by_index("eth", dev_seq(pdev),
+ master_pdata->enetaddr);
+}
+
+static int dsa_port_probe(struct udevice *pdev)
+{
+ struct udevice *dev = dev_get_parent(pdev);
struct dsa_port_pdata *port_pdata;
struct dsa_priv *dsa_priv;
struct udevice *master;
@@ -272,19 +290,8 @@ static int dsa_port_probe(struct udevice *pdev)
if (err)
return err;
- /*
-* Inherit port's hwaddr from the DSA master, unless the port already
-* 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))
- return 0;
+ dsa_port_set_hwaddr(pdev, master);
- master_pdata = dev_get_plat(master);
- eth_pdata = dev_get_plat(pdev);
- memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
- eth_env_set_enetaddr_by_index("eth", dev_seq(pdev),
- master_pdata->enetaddr);
return 0;
}
--
2.25.1
[PATCH 2/6] net: dsa: use "err" instead of "ret" in dsa_port_probe
From: Vladimir Oltean DM DSA uses "err" for error code values, so use this consistently. Signed-off-by: Vladimir Oltean --- net/dsa-uclass.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c index 7ea1cb6949c0..17b33834f585 100644 --- a/net/dsa-uclass.c +++ b/net/dsa-uclass.c @@ -248,7 +248,7 @@ static int dsa_port_probe(struct udevice *pdev) struct dsa_port_pdata *port_pdata; struct dsa_priv *dsa_priv; struct udevice *master; - int ret; + int err; port_pdata = dev_get_parent_plat(pdev); dsa_priv = dev_get_uclass_priv(dev); @@ -268,9 +268,9 @@ static int dsa_port_probe(struct udevice *pdev) * TODO: we assume the master device is always there and doesn't get * removed during runtime. */ - ret = device_probe(master); - if (ret) - return ret; + err = device_probe(master); + if (err) + return err; /* * Inherit port's hwaddr from the DSA master, unless the port already -- 2.25.1
[PATCH 1/6] net: dsa: felix: felix_init() can be static
From: Vladimir Oltean
No one is calling this function from outside felix_switch.c.
Signed-off-by: Vladimir Oltean
---
drivers/net/mscc_eswitch/felix_switch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/mscc_eswitch/felix_switch.c
b/drivers/net/mscc_eswitch/felix_switch.c
index f20e84e0f10c..75073880cf87 100644
--- a/drivers/net/mscc_eswitch/felix_switch.c
+++ b/drivers/net/mscc_eswitch/felix_switch.c
@@ -233,7 +233,7 @@ static void felix_start_pcs(struct udevice *dev, int port,
}
}
-void felix_init(struct udevice *dev)
+static void felix_init(struct udevice *dev)
{
struct dsa_pdata *pdata = dev_get_uclass_plat(dev);
struct felix_priv *priv = dev_get_priv(dev);
--
2.25.1
[PATCH 0/6] Call phy_config at port probe time for the Felix DSA driver
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. Vladimir Oltean (6): net: dsa: felix: felix_init() can be static net: dsa: use "err" instead of "ret" in dsa_port_probe net: dsa: refactor the code to set the port MAC address into a dedicated function net: dsa: introduce a .port_probe() method in struct dsa_ops net: dsa: felix: call phy_config at .port_probe() time net: dsa: felix: propagate the error code from phy_startup() drivers/net/mscc_eswitch/felix_switch.c | 28 -- include/net/dsa.h | 5 ++- net/dsa-uclass.c| 50 - 3 files changed, 53 insertions(+), 30 deletions(-) -- 2.25.1
Re: [PATCH] arm: Add (back) VExpress boards support
On Tue, 29 Jun 2021 15:15:52 +0100 Andre Przywara wrote: Hi, > On Tue, 29 Jun 2021 08:11:22 -0400 > Tom Rini wrote: > > > On Tue, Jun 29, 2021 at 12:45:55PM +0100, Andre Przywara wrote: > > > > > The v2021.07 merge window saw the removal of the Arm Ltd. Versatile > > > Express platform, along with their CA5, CA9 and TC2 boards. The trigger > > > was the missing conversion of the MMC driver. > > > > > > Some folks complained about that internally, so bring those boards back, > > > but better than ever: > > > - Use DM and OF_CONTROL for all the boards. Use the .dts files from the > > > latest Linux kernel (5.13) for that. > > > - Move the board selection choice into the platform's Kconfig. > > > - Clean up some shared config and common definitions. > > > - Drop obsolete features like ATAGs support. > > > - Switch to the DM_ETH version of the SMC911X Ethernet driver. > > > - Drop MMC support. > > > > > > The PL180 MMC driver actually supports DM_MMC, but that requires a > > > DM_GPIO driver for the card detect GPIO, which we don't have. This > > > specific GPIO is actually handled via the "sysregs" device, so we would > > > need a driver for that. QEMU does not emulate this part, also the DT > > > description is somewhat "special", so this is left for later. > > > > > > This version compiles without any warning for all three boards now. > > > Tested on QEMU. > > > > > > Signed-off-by: Andre Przywara > > > --- > > > Hi, > > > > > > this relies on the SMC911x driver DT changes, as posted here: > > > https://lists.denx.de/pipermail/u-boot/2021-June/452989.html > > > I put a version with the changes broken down here: > > > https://github.com/Andre-ARM/u-boot/commits/tc2-history > > > > > > This was tested on QEMU, for vexpress_ca15_tc2_defconfig with: > > > $ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G -smp 1 \ > > > -drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \ > > > -device loader,file=u-boot.bin,addr=0x8080 -nographic > > > > > > Where tramp-tc2.bin is a trampoline replacing the board's firmware: > > > 00 00 a0 e3 80 00 48 e3 10 ff 2f e1 > > > (mov r0, #0; movt r0, #0x8080; bx r0) > > > > > > The vexpress_ca9x4_defconfig uses a different memory map, so the runes > > > are: > > > $ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \ > > > -drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \ > > > -device loader,file=u-boot.bin,addr=0x6080 -nographic > > > > > > tramp-ca9.bin: > > > 00 00 a0 e3 80 00 46 e3 10 ff 2f e1 > > > (mov r0, #0; movt r0, #0x6080; bx r0) > > > > My big question is how do we run this in CI? Or does it not _need_ that > > firmware file to really exist? Or is there a pending change to > > https://gitlab.denx.de/u-boot/u-boot-test-hooks.git to generate / just > > have exist those magic empty bins? Thanks! > > So from digging into this I see that this loads U-Boot's ELF build, via > QEMU's -kernel parameter. Which is fine, but not really what is > happening on real hardware. > I checked and the v2021.04 version worked with this approach, but my > build does not. > I will have a look into this now. The new build uses OF_CONTROL and OF_SEPARATE, so the DTB gets appended to the U-Boot *image*. The ELF file is not treated this way, so the code reads only 0s after the end of the U-Boot code - which makes it die silently. Manually loading the DTB into DRAM would be fragile at best, but is also rejected by QEMU, because the LOAD program header extend for a few dozen bytes beyond U-Boot's "end" symbol, so it overlaps. IIRC we don't have position independent code for ARM, so we can't load U-Boot into flash directly (which also would require some code changes first). Anyway I don't think we should change any code to cope with that (by using another method to find the DTB), so adjusting the QEMU recipe sounds like a better idea. Is there a way to add those 12 byte trampoline files to the CI repo? Or shall they be created on the fly somehow? Or can you think of another way to get those builds tested? Cheers, Andre
[RFC PATCH v2 1/1] cmd: nvedit: Forbid key to be empty.
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 ? */
--
2.25.1
[RFC PATCH v2 0/1] cmd: nvedit: Forbid environment key to be empty.
Hi. First of all, I hope you are fine and the same for your relatives. In this patch, I modified the setenv command to decline empty variable name. Indeed, it was strangely possible to give the following to this command: setenv '' foo Which results in the following belonging to environment: =foo And which in turns leads to problem while rebooting: Loading Environment from Flash... Cannot import environment: errno = 22 *** Warning - import failed, using default environment This error message is due to varname being empty and was added in [1]. With this patch, executing the above command will lead to the following being printed: ## Error: variable name cannot be empty And the environment will not be changed. Here is the diffstat for this patch: Francis Laniel (1): cmd: nvedit: Forbid key to be empty. cmd/nvedit.c | 5 + 1 file changed, 5 insertions(+) Change since: v1: * Replace call to strlen by test if variable name is '\0'. * Modify error message printed. If you see any way to improve the patch, feel free to share it. Best regards. --- [1] https://u-boot.denx.narkive.com/P4aKxVFu/patch-env-don-t-add-an-empty-key-to-the-env-hashtable -- 2.25.1
Re: [RFC PATCH 1/1] cmd: nvedit: Forbid key to be empty.
Hi.
On Tue, Jun 29, 2021 at 10:29 AM Wolfgang Denk wrote:
> Dear Francis,
>
> In message <20210628193145.796999-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..64b7aef78d 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 (!strlen(name)) {
>
> Instead of calling a library function here you could use the same
> shortcut as in the patch you referenced:
>
> if (*name == 0) {
>
> > + printf("## Error: variable name cannot be empty\n");
>
> s/cannot/must not/ ??
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> "The fundamental principle of science, the definition almost, is
> this: the sole test of the validity of any idea is experiment."
> - Richard P. Feynman
>
Thank you for the review, I updated my patch and will push soon the v2.
Best regards.
[PATCH] cmd: nand biterr - Add support for nand biterr command
The command shall be used to induce bit errors in the nand page
manually. The code flips a bit in the specified offset without
changing the ECC. This helps to see how the software handles the
error.
The patch is ported from
https://patchwork.ozlabs.org/project/uboot/patch/\
1325691123-19565-1-git-send-email-holger.bru...@keymile.com
The implementation is inspired from
'mtd-utils/nand-utils/nandflipbits.c'
Signed-off-by: Balamanikandan Gunasundar
---
cmd/nand.c | 127 +++--
1 file changed, 124 insertions(+), 3 deletions(-)
diff --git a/cmd/nand.c b/cmd/nand.c
index 5bda69e819..ea1b0f9434 100644
--- a/cmd/nand.c
+++ b/cmd/nand.c
@@ -17,6 +17,10 @@
* and/or modified under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of the
* License, or (at your option) any later version.
+ *
+ * The function nand_biterror() in this file is inspired from
+ * mtd-utils/nand-utils/nandflipbits.c which was released under GPLv2
+ * only
*/
#include
@@ -40,6 +44,116 @@ int find_dev_and_part(const char *id, struct mtd_device
**dev,
u8 *part_num, struct part_info **part);
#endif
+#define MAX_NUM_PAGES 64
+
+static int nand_biterror(struct mtd_info *mtd, ulong off, int bit)
+{
+ int ret = 0;
+ int page = 0;
+ ulong block_off;
+ u_char *datbuf[MAX_NUM_PAGES]; /* Data and OOB */
+ u_char data;
+ int pages_per_blk = mtd->erasesize / mtd->writesize;
+ struct erase_info einfo;
+
+ if (pages_per_blk > MAX_NUM_PAGES) {
+ printf("Too many pages in one erase block\n");
+ return 1;
+ }
+
+ if (bit < 0 || bit > 7) {
+ printf("bit position 0 to 7 is allowed\n");
+ return 1;
+ }
+
+ /* Allocate memory */
+ memset(datbuf, 0, sizeof(datbuf));
+ for (page = 0; page < pages_per_blk ; page++) {
+ datbuf[page] = malloc(mtd->writesize + mtd->oobsize);
+ if (!datbuf[page]) {
+ printf("No memory for page buffer\n");
+ ret = -ENOMEM;
+ goto free_memory;
+ }
+ }
+
+ /* Align to erase block boundary */
+ block_off = off & (~(mtd->erasesize - 1));
+
+ /* Read out memory as first step */
+ for (page = 0; page < pages_per_blk ; page++) {
+ struct mtd_oob_ops ops;
+ loff_t addr = (loff_t)block_off;
+
+ memset(&ops, 0, sizeof(ops));
+ ops.datbuf = datbuf[page];
+ ops.oobbuf = datbuf[page] + mtd->writesize;
+ ops.len = mtd->writesize;
+ ops.ooblen = mtd->oobsize;
+ ops.mode = MTD_OPS_RAW;
+ ret = mtd_read_oob(mtd, addr, &ops);
+ if (ret < 0) {
+ printf("Error (%d) reading page %08lx\n",
+ ret, block_off);
+ ret = 1;
+ goto free_memory;
+ }
+ block_off += mtd->writesize;
+ }
+
+ /* Erase the block */
+ memset(&einfo, 0, sizeof(einfo));
+ einfo.mtd = mtd;
+ /* Align to erase block boundary */
+ einfo.addr = (loff_t)(off & (~(mtd->erasesize - 1)));
+ einfo.len = mtd->erasesize;
+ ret = mtd_erase(mtd, &einfo);
+ if (ret < 0) {
+ printf("Error (%d) nand_erase_nand page %08llx\n",
+ ret, einfo.addr);
+ ret = 1;
+ goto free_memory;
+ }
+
+ /* Twist a bit in data part */
+ block_off = off & (mtd->erasesize - 1);
+ data = datbuf[block_off / mtd->writesize][block_off % mtd->writesize];
+ data ^= (1 << bit);
+ datbuf[block_off / mtd->writesize][block_off % mtd->writesize] = data;
+
+ printf("Flip data at 0x%lx with xor 0x%02x (bit=%d) to value=0x%02x\n",
+ off, (1 << bit), bit, data);
+
+ /* Write back twisted data and unmodified OOB */
+ /* Align to erase block boundary */
+ block_off = off & (~(mtd->erasesize - 1));
+ for (page = 0; page < pages_per_blk; page++) {
+ struct mtd_oob_ops ops;
+ loff_t addr = (loff_t)block_off;
+
+ memset(&ops, 0, sizeof(ops));
+ ops.datbuf = datbuf[page];
+ ops.oobbuf = datbuf[page] + mtd->writesize;
+ ops.len = mtd->writesize;
+ ops.ooblen = mtd->oobsize;
+ ops.mode = MTD_OPS_RAW;
+ ret = mtd_write_oob(mtd, addr, &ops);
+ if (ret < 0) {
+ printf("Error (%d) write page %08lx\n", ret, block_off);
+ ret = 1;
+ goto free_memory;
+ }
+ block_off += mtd->writesize;
+ }
+
+free_memory:
+ for (page = 0; page < pages_per_blk ; page
Re: [PATCH 0/3] cmd: setexpr: add fmt format string operation
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. > 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. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Every program has at least one bug and can be shortened by at least one instruction -- from which, by induction, one can deduce that every program can be reduced to one instruction which doesn't work.
Re: [PATCH] arm: Add (back) VExpress boards support
On Tue, 29 Jun 2021 08:11:22 -0400 Tom Rini wrote: > On Tue, Jun 29, 2021 at 12:45:55PM +0100, Andre Przywara wrote: > > > The v2021.07 merge window saw the removal of the Arm Ltd. Versatile > > Express platform, along with their CA5, CA9 and TC2 boards. The trigger > > was the missing conversion of the MMC driver. > > > > Some folks complained about that internally, so bring those boards back, > > but better than ever: > > - Use DM and OF_CONTROL for all the boards. Use the .dts files from the > > latest Linux kernel (5.13) for that. > > - Move the board selection choice into the platform's Kconfig. > > - Clean up some shared config and common definitions. > > - Drop obsolete features like ATAGs support. > > - Switch to the DM_ETH version of the SMC911X Ethernet driver. > > - Drop MMC support. > > > > The PL180 MMC driver actually supports DM_MMC, but that requires a > > DM_GPIO driver for the card detect GPIO, which we don't have. This > > specific GPIO is actually handled via the "sysregs" device, so we would > > need a driver for that. QEMU does not emulate this part, also the DT > > description is somewhat "special", so this is left for later. > > > > This version compiles without any warning for all three boards now. > > Tested on QEMU. > > > > Signed-off-by: Andre Przywara > > --- > > Hi, > > > > this relies on the SMC911x driver DT changes, as posted here: > > https://lists.denx.de/pipermail/u-boot/2021-June/452989.html > > I put a version with the changes broken down here: > > https://github.com/Andre-ARM/u-boot/commits/tc2-history > > > > This was tested on QEMU, for vexpress_ca15_tc2_defconfig with: > > $ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G -smp 1 \ > > -drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \ > > -device loader,file=u-boot.bin,addr=0x8080 -nographic > > > > Where tramp-tc2.bin is a trampoline replacing the board's firmware: > > 00 00 a0 e3 80 00 48 e3 10 ff 2f e1 > > (mov r0, #0; movt r0, #0x8080; bx r0) > > > > The vexpress_ca9x4_defconfig uses a different memory map, so the runes are: > > $ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \ > > -drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \ > > -device loader,file=u-boot.bin,addr=0x6080 -nographic > > > > tramp-ca9.bin: > > 00 00 a0 e3 80 00 46 e3 10 ff 2f e1 > > (mov r0, #0; movt r0, #0x6080; bx r0) > > My big question is how do we run this in CI? Or does it not _need_ that > firmware file to really exist? Or is there a pending change to > https://gitlab.denx.de/u-boot/u-boot-test-hooks.git to generate / just > have exist those magic empty bins? Thanks! So from digging into this I see that this loads U-Boot's ELF build, via QEMU's -kernel parameter. Which is fine, but not really what is happening on real hardware. I checked and the v2021.04 version worked with this approach, but my build does not. I will have a look into this now. Thanks! Andre
Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
On Tue, Jun 29, 2021 at 04:01:38PM +0200, Heinrich Schuchardt wrote: > On 6/29/21 2:56 PM, AKASHI Takahiro wrote: > > On Mon, Jun 28, 2021 at 12:08:27PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 28 Jun 2021 at 11:27, Tom Rini wrote: > > > > > > > > On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote: > > > > > Hi Heinrich, > > > > > > > > > > On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt > > > > > wrote: > > > > > > > > > > > > On 6/28/21 4:18 PM, Simon Glass wrote: > > > > > > > Hi Tom, Mark, > > > > > > > > > > > > > > On Mon, 28 Jun 2021 at 07:37, Tom Rini wrote: > > > > > > > > > > > > > > > > On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: > > > > > > > > > > From: Simon Glass > > > > > > > > > > Date: Sun, 27 Jun 2021 19:48:34 -0600 > > > > > > > > > > > > > > > > > > > > It has come to light that EFI_LOADER adds an extraordinary > > > > > > > > > > amount of > > > > > > > > > > code to U-Boot. For example, with nokia_rx51 the size delta > > > > > > > > > > is about > > > > > > > > > > 90KB. About 170 boards explicitly disable the option, but > > > > > > > > > > is is clear > > > > > > > > > > that many more could, thus saving image size and boot time. > > > > > > > > > > > > > > > > > > EFI_LOADER used to be a lot smaller. It is great to see that > > > > > > > > > over the > > > > > > > > > years UEFI support has become more complete, but a lot of > > > > > > > > > that new > > > > > > > > > code implements features that are not at all essential for > > > > > > > > > just > > > > > > > > > booting an OS from storage. If that growth leads to the > > > > > > > > > suggestion to > > > > > > > > > disable EFI_LOADER completely by default, we're putting the > > > > > > > > > cart > > > > > > > > > before the horse. > > > > > > > > > > > > > > > > Well, I see I forgot to prefix my patch with RFC, but I hadn't > > > > > > > > found > > > > > > > > EFI_LOADER being used in the wild on armv7, but wasn't sure > > > > > > > > about the > > > > > > > > BSD families. I did see that Debian doesn't use it, and that > > > > > > > > Armbian > > > > > > > > doesn't even use it on aarch64. > > > > > > > > > > > > > > > > > > The current situation is affecting U-Boot's image as a > > > > > > > > > > svelt bootloader. > > > > > > > > > > > > > > > > > > Really? I know UEFI has a bad reputation in the Open Source > > > > > > > > > world, > > > > > > > > > and some of its Microsoft-isms are really annoying (yay > > > > > > > > > UCS-2). But > > > > > > > > > it works, it provides a standardized approach across several > > > > > > > > > platforms > > > > > > > > > (ARMv7, AMRv8, RISC-V) and the industry seems to like it. > > > > > > > > > Personally > > > > > > > > > I'd wish the industry had standardized on Open Firmware > > > > > > > > > instead, but > > > > > > > > > that ship sailed a long time ago... > > > > > > > > > > > > > > > > > > I find it hard to imagine that 90k is a serious amount of > > > > > > > > > storage for > > > > > > > > > something that is going to include a multi-MB Linux kernel. > > > > > > > > > This > > > > > > > > > isn't code that lives in SPL or TPL where severe size > > > > > > > > > restrictions > > > > > > > > > apply. > > > > > > > > > > > > > > > > In one of those cases where I need to pop back in to the other > > > > > > > > (Nokia > > > > > > > > N900 specific) thread and see if the big size reduction really > > > > > > > > was just > > > > > > > > disabling EFI_LOADER, it's perhaps just one of those "fun" > > > > > > > > things about > > > > > > > > Kconfig and anything other than "make oldconfig" for spotting > > > > > > > > new config > > > > > > > > options that default to enabled. > > > > > > > > > > > > > > Yes it will be interesting to see what you find there. My results > > > > > > > on > > > > > > > nokia_rx51 were something like this: > > > > > > > > > > > > > > default > > > > > > > arm: (for 1/1 boards) all +129370.0 bss +1136.0 data > > > > > > > +7399.0 > > > > > > > rodata +10989.0 text +109846.0 > > > > > > > > > > > > > > without ebbr > > > > > > > arm: (for 1/1 boards) all +38460.0 bss +1040.0 data > > > > > > > +2375.0 > > > > > > > rodata +5333.0 text +29712.0 > > > > > > > > > > > > > > with various other things: > > > > > > > CONFIG_OF_LIBFDT_ASSUME_MASK=7 > > > > > > > # CONFIG_OF_TRANSLATE is not set > > > > > > > # CONFIG_SIMPLE_BUS is not set > > > > > > > # CONFIG_TI_SYSC is not set > > > > > > > # CONFIG_CMD_FDT is not set > > > > > > > > > > > > > > arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 > > > > > > > rodata > > > > > > > +3274.0 text +15552.0 > > > > > > > > > > > > > > (Mark, in the same email:) > > > > > > > > > FIT simply isn't fit for purpose (pun intended). It only > > > > > > > > > really works > > > > > > > > > for booting Linux, and forces people to combine u-boot, > > > > > > > > > kernel, > > > > > >
Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
On 6/29/21 2:56 PM, AKASHI Takahiro wrote: On Mon, Jun 28, 2021 at 12:08:27PM -0600, Simon Glass wrote: Hi Tom, On Mon, 28 Jun 2021 at 11:27, Tom Rini wrote: On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote: Hi Heinrich, On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt wrote: On 6/28/21 4:18 PM, Simon Glass wrote: Hi Tom, Mark, On Mon, 28 Jun 2021 at 07:37, Tom Rini wrote: On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: From: Simon Glass Date: Sun, 27 Jun 2021 19:48:34 -0600 It has come to light that EFI_LOADER adds an extraordinary amount of code to U-Boot. For example, with nokia_rx51 the size delta is about 90KB. About 170 boards explicitly disable the option, but is is clear that many more could, thus saving image size and boot time. EFI_LOADER used to be a lot smaller. It is great to see that over the years UEFI support has become more complete, but a lot of that new code implements features that are not at all essential for just booting an OS from storage. If that growth leads to the suggestion to disable EFI_LOADER completely by default, we're putting the cart before the horse. Well, I see I forgot to prefix my patch with RFC, but I hadn't found EFI_LOADER being used in the wild on armv7, but wasn't sure about the BSD families. I did see that Debian doesn't use it, and that Armbian doesn't even use it on aarch64. The current situation is affecting U-Boot's image as a svelt bootloader. Really? I know UEFI has a bad reputation in the Open Source world, and some of its Microsoft-isms are really annoying (yay UCS-2). But it works, it provides a standardized approach across several platforms (ARMv7, AMRv8, RISC-V) and the industry seems to like it. Personally I'd wish the industry had standardized on Open Firmware instead, but that ship sailed a long time ago... I find it hard to imagine that 90k is a serious amount of storage for something that is going to include a multi-MB Linux kernel. This isn't code that lives in SPL or TPL where severe size restrictions apply. In one of those cases where I need to pop back in to the other (Nokia N900 specific) thread and see if the big size reduction really was just disabling EFI_LOADER, it's perhaps just one of those "fun" things about Kconfig and anything other than "make oldconfig" for spotting new config options that default to enabled. Yes it will be interesting to see what you find there. My results on nokia_rx51 were something like this: default arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 rodata +10989.0 text +109846.0 without ebbr arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 rodata +5333.0 text +29712.0 with various other things: CONFIG_OF_LIBFDT_ASSUME_MASK=7 # CONFIG_OF_TRANSLATE is not set # CONFIG_SIMPLE_BUS is not set # CONFIG_TI_SYSC is not set # CONFIG_CMD_FDT is not set arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata +3274.0 text +15552.0 (Mark, in the same email:) FIT simply isn't fit for purpose (pun intended). It only really works for booting Linux, and forces people to combine u-boot, kernel, initial ramdisk and other firmware components into a single image. That is really undesirable as: - This makes it sigificantly harder to update individual components of such an image. Making it hard to update a kernel is obviously a serious security risk. - This makes it impossible to build an OS install image that works om multiple boards/SoCs. I would really like to understand this better. The whole thing is a complete mystery to me. Firstly I have sometimes fiddled with booting other OSes using FIT. It seemed OK. I can't see why it only works with Linux. Secondly, I don't expect that U-Boot itself would be in the FIT. Thirdly, do you really want the kernel and initrd to be separate? At least in the systems I have used, they are built together, even having the same name, e.g.: initrd.img-5.10.40-1rodete1-amd64 System.map-5.10.40-1rodete1-amd64 vmlinuz-5.10.28-1rodete2-amd64 I have not hit any distro that builds FIT images. All install vmlinux and initrd as separate files. Why would you want to change that? Well there is no point in having two files if one will do. Also it allows for a hash / signature check. The question of "how great would it be and how many problems would it have solved if FIT images had become popular" is one for another time. It will always have its use cases and users but never the broad adoption many of us felt it should have. Bringing it up in this context won't change that. I see Peter's reply below so will make time to dig into this and understand the problems with FIT better. I feel that EFI comes with all sorts of problems so I'm far from convinced, at this point. Sorry. It seems to me that we are discussing three different things: - the code size increase by enabling UEFI interfaces - how the UEFI interface be implemented on U-Boot - The primary (or def
Re: [PATCH 0/3] cmd: setexpr: add fmt format string operation
On 6/29/21 4:37 AM, Wolfgang Denk wrote: Dear Roland, In message <20210628151750.572837-1-roland.gaudig-...@weidmueller.com> you wrote: U-Boot uses almost everywhere hexadecimal numbers. But some bootargs passed to Linux are expecting decimal numbers. As long as the values are in the range 0 to 9 it is sufficient to just strip 0x from the number. But for greater values a method for converting numbers to decimal is needed. This patch adds C like format string capabilities to the setexpr command. Here are some examples: Thanks! In contrast to the original C format strings the number of parameters is limited to one. As the get_arg() function returns unsigned long type, the format string commands are limited to those which are operating on unsigned long type. 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 reasonable to assume (and specify) that, when the "fmt" option is used, _all_ following arguments will be passed (unchanged) to the sprintf() function. This was actually one of my intentions when making this suggestion - to be able to construct any kind of data from pieces; say, for example: => setexpr foo fmt "%0x08x-%s-%d-%s" $a $b $c $d Best regards, Wolfgang Denk 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 snprintf(buf, sizeof(buf), argv[3], argc >= 4 ? argv[4] : NULL, /* etc */); 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. 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. --Sean
Re: [PATCH] sf: Querying write-protect status before operating the flash
On Tue, Jun 22, 2021 at 10:51 AM chao zeng wrote: > > From: Chao Zeng > > When operating the write-protection flash,spi_flash_std_write() and > spi_flash_std_erase() would return wrong result.The flash is protected, > but write or erase the flash would show "OK". > > Check the flash write protection state if the write-protection has enbale > before operating the flash. > > Signed-off-by: Chao Zeng > --- Does it broken on master? if yes can you check in u-boot-spi/next? Jagan.
Re: [PATCH v9 9/9] mtd: spi-nor-tiny: Add fixups for Cypress s25hl-t/s25hs-t
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > Fixes mode clocks for SPINOR_OP_READ_FAST_4B in tiny. > > Signed-off-by: Takahiro Kuwano > --- Reviewed-by: Jagan Teki
Re: [PATCH v9 8/9] mtd: spi-nor-core: Add fixups for Cypress s25hl-t/s25hs-t
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > The nor->ready() and spansion_sr_ready() introduced earlier in this > series are used for multi-die package parts. > > The nor->quad_enable() sets the volatile QE bit on each die. > > The nor->erase() is hooked if the device is not configured to uniform > sectors, assuming it has 32 x 4KB sectors overlaid on bottom address. > Other configurations, top and split, are not supported at this point. > Will submit additional patches to support it as needed. > > The post_bfpt/sfdp() fixes the params wrongly advertised in SFDP. > > Signed-off-by: Takahiro Kuwano > --- Reviewed-by: Jagan Teki
Re: [PATCH v9 7/9] mtd: spi-nor-core: Add Cypress manufacturer ID in set_4byte
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > Cypress chips support SPINOR_OP_EN4B(B7h) to enable 4-byte addressing mode. > > Cypress chips support B8h to disable 4-byte addressing mode instead of > SPINOR_OP_EX4B(E9h). > > This patch defines new opcode and updates set_4byte() to support > enable/disable 4-byte addressing mode for Cypress chips. > > Signed-off-by: Takahiro Kuwano > --- Reviewed-by: Jagan Teki
Re: [PATCH v9 6/9] mtd: spi-nor-core: Read status by Read Any Register
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > The spansion_sr_ready() reads status register 1 by Read Any Register > commnad. This function is called from Flash specific hook with die address > and dummy cycles to support multi-die package parts from Spansion/Cypress. > > Signed-off-by: Takahiro Kuwano > Reviewed-by: Pratyush Yadav > --- Reviewed-by: Jagan Teki
Re: [PATCH v9 5/9] mtd: spi-nor-core: Add the ->ready() hook
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > For dual/quad die package devices from Spansion/Cypress, the device's > status needs to be checked by reading status registers in all dies, by > using Read Any Register command. To support this, a Flash specific hook > that can overwrite the legacy status check is needed. > > Signed-off-by: Takahiro Kuwano > Reviewed-by: Pratyush Yadav > --- Reviewed-by: Jagan Teki
Re: [PATCH] efi_loader: Allow capsule update on-disk without checking OsIndications
On Tue, 29 Jun 2021 at 16:04, AKASHI Takahiro
wrote:
>
> On Tue, Jun 29, 2021 at 03:45:29PM +0300, Ilias Apalodimas wrote:
> > > > >
> > [...]
> > > > > +config EFI_IGNORE_OSINDICATIONS
> > > > > + bool "Ignore OsIndications for CapsuleUpdate on-disk"
> > > > > + depends on EFI_CAPSULE_ON_DISK
> > > > > + default n
> > > > > + help
> > > > > + There are boards were we can't support SetVariable at
> > > > > runtime.
> > > > > + Select this option if you want to use capsule-on-disk
> > > > > feature,
> > > > > + without setting the OsIndications bit.
> > >
> > > Obviously, this option breaks the conformance to UEFI specification
> > > and must be turned on carefully in the limited use cases.
> > > You should describe that here explicitly.
> >
> > Fair enough, I'll send a v2
> >
> > >
> > > Additionally, you may add
> > >depends on !EFI_MM_COMM_TEE (or better config?)
> >
> > That's not the case (yet). I do have a kernel branch were SetVariable at
> > runtime is supported, but that's not merged yet. So until this gets
> > accepted
> > *all* the boards that want to perform a capsuleupdate on-disk without
> > setting
> > the variable need this.
>
> If so, I would suggest that another Kconfig option be added
> for the availability of SetVariable at runtime.
>
> This will allow us to keep "depends on" unchanged even if
> yet another implementation of SetVariable is introduced in the future.
Let's not fill in so many Kconfig options for now. We might need to
do that in the future, but on the other hand, I would much prefer
checking the RTPROP which has that info.
>
> -Takahiro Akashi
>
>
> > Cheers
> > /Ilias
> > >
> > > -Takahiro Akashi
> > >
> > >
> > > > > config EFI_CAPSULE_ON_DISK_EARLY
> > > > > bool "Initiate capsule-on-disk at U-Boot boottime"
> > > > > depends on EFI_CAPSULE_ON_DISK
> > > > > diff --git a/lib/efi_loader/efi_capsule.c
> > > > > b/lib/efi_loader/efi_capsule.c
> > > > > index d7136035d8f9..50bed32bfb3b 100644
> > > > > --- a/lib/efi_loader/efi_capsule.c
> > > > > +++ b/lib/efi_loader/efi_capsule.c
> > > > > @@ -948,6 +948,33 @@ efi_status_t __weak
> > > > > efi_load_capsule_drivers(void)
> > > > > return ret;
> > > > > }
> > > > >
> > > > > +/**
> > > > > + * check_run_capsules - Check whether capsule update should run
> > > > > + *
> > > > > + * The spec says OsIndications must be set in order to run the
> > > > > capsule update
> > > > > + * on-disk. Since U-Boot doesn't support runtime SetVariable, allow
> > > > > capsules to
> > > > > + * run explicitly if CONFIG_EFI_IGNORE_OSINDICATIONS is selected
> > > > > + */
> > > > > +static bool check_run_capsules(void)
> > > > > +{
> > > > > + u64 os_indications;
> > > > > + efi_uintn_t size;
> > > > > + efi_status_t ret;
> > > > > +
> > > > > + if (IS_ENABLED(CONFIG_EFI_IGNORE_OSINDICATIONS))
> > > > > + return true;
> > > > > +
> > > > > + size = sizeof(os_indications);
> > > > > + ret = efi_get_variable_int(L"OsIndications",
> > > > > &efi_global_variable_guid,
> > > > > + NULL, &size, &os_indications,
> > > > > NULL);
> > > > > + if (ret == EFI_SUCCESS &&
> > > > > + (os_indications
> > > > > + & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
> > > >
> > > > The bit EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED must be
> > > > cleared in OsIndications after successfully applying the capsule. See
> > > > related patch
> > > >
> > > > [PATCH 1/1] efi_loader: fix set_capsule_result()
> > > > https://lists.denx.de/pipermail/u-boot/2021-June/453111.html
> > > >
> > > > Reviewed-by: Heinrich Schuchardt
> > > >
> > > > > + return true;
> > > > > +
> > > > > + return false;
> > > > > +}
> > > > > +
> > > > > /**
> > > > >* efi_launch_capsule - launch capsules
> > > > >*
> > > > > @@ -958,20 +985,13 @@ efi_status_t __weak
> > > > > efi_load_capsule_drivers(void)
> > > > >*/
> > > > > efi_status_t efi_launch_capsules(void)
> > > > > {
> > > > > - u64 os_indications;
> > > > > - efi_uintn_t size;
> > > > > struct efi_capsule_header *capsule = NULL;
> > > > > u16 **files;
> > > > > unsigned int nfiles, index, i;
> > > > > u16 variable_name16[12];
> > > > > efi_status_t ret;
> > > > >
> > > > > - size = sizeof(os_indications);
> > > > > - ret = efi_get_variable_int(L"OsIndications",
> > > > > &efi_global_variable_guid,
> > > > > - NULL, &size, &os_indications,
> > > > > NULL);
> > > > > - if (ret != EFI_SUCCESS ||
> > > > > - !(os_indications
> > > > > - & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
> > > > > + if (!check_run_capsules())
> > > > > return EFI_SUCCESS;
> > > > >
> > > > > index = get_last_capsule();
> > > > >
> > > >
Re: [PATCH v9 4/9] mtd: spi-nor-core: Add support for volatile QE bit
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > Some of Spansion/Cypress chips support volatile version of configuration > registers and it is recommended to update volatile registers in the field > application due to a risk of the non-volatile registers corruption by > power interrupt. This patch adds a function to set Quad Enable bit in CFR1 > volatile. > > Signed-off-by: Takahiro Kuwano > --- Reviewed-by: Jagan Teki
Re: [PATCH v9 3/9] mtd: spi-nor-core: Add support for Read/Write Any Register
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > Some of Spansion/Cypress chips support Read/Write Any Register commands. > These commands are mainly used to write volatile registers and access to > the registers in second and subsequent die for multi-die package parts. > > The Read Any Register instruction (65h) is followed by register address > and dummy cycles, then the selected register byte is returned. > > The Write Any Register instruction (71h) is followed by register address > and register byte to write. > > Signed-off-by: Takahiro Kuwano > Reviewed-by: Pratyush Yadav > --- Reviewed-by: Jagan Teki
Re: [PATCH v9 2/9] mtd: spi-nor-ids: Add Cypress s25hl-t/s25hs-t
On Tue, Jun 29, 2021 at 11:31 AM wrote: > > From: Takahiro Kuwano > > The S25HL-T/S25HS-T family is the Cypress Semper Flash with Quad SPI. > > https://www.cypress.com/file/424146/download (256Mb/512Mb/1Gb, single die) > https://www.cypress.com/file/499246/download (2Gb/4Gb, dual/quad die) > > The full version can be found in the following links (registration > required). > https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-Semper-Flash-with-Quad-SPI/ta-p/260789?attachment-id=19522 > https://community.cypress.com/t5/Semper-Flash-Access-Program/Datasheet-2Gb-MCP-Semper-Flash-with-Quad-SPI/ta-p/260823?attachment-id=29503 > > S25HL/HS-T (Semper Flash with Quad SPI) Family has user-configurable > sector architecture. By default, the 512Mb and 1Gb, single-die package > parts are configured to non-uniform that 4KB sectors overlaid on bottom > address. To support this, an erase hook makes overlaid sectors appear as > uniform sectors. The 2Gb, dual-die package parts are configured to uniform > by default. > > Tested on Xilinx Zynq-7000 FPGA board. > > Signed-off-by: Takahiro Kuwano > Reviewed-by: Pratyush Yadav > --- Reviewed-by: Jagan Teki
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 > --- Reviewed-by: Jagan Teki
Re: [PATCH] patman: Handle PAGER containing arguments
On Sat, 26 Jun 2021 12:31:41 -0600 Simon Glass wrote: > Hi Paul, > > On Tue, 15 Jun 2021 at 04:26, Paul Barker > wrote: > > > > When printing full help output from patman, we should be able to > > handle a PAGER variable which includes arguments, e.g. PAGER='less > > -F'. > > > > Signed-off-by: Paul Barker > > --- > > > > tools/patman/main.py | 9 + > > 1 file changed, 5 insertions(+), 4 deletions(-) > > > > Can you please add a function to print full help to test_util.py > instead? Then we can use it in the other tools too. Thanks for the feedback, I'll take a look at this next week and send an updated patch. -- Paul Barker Principal Software Engineer SanCloud Ltd pgp2_cUTgkYHu.pgp Description: OpenPGP digital signature
Re: [PATCH] efi_loader: Allow capsule update on-disk without checking OsIndications
On Tue, Jun 29, 2021 at 03:45:29PM +0300, Ilias Apalodimas wrote:
> > > >
> [...]
> > > > +config EFI_IGNORE_OSINDICATIONS
> > > > + bool "Ignore OsIndications for CapsuleUpdate on-disk"
> > > > + depends on EFI_CAPSULE_ON_DISK
> > > > + default n
> > > > + help
> > > > + There are boards were we can't support SetVariable at runtime.
> > > > + Select this option if you want to use capsule-on-disk feature,
> > > > + without setting the OsIndications bit.
> >
> > Obviously, this option breaks the conformance to UEFI specification
> > and must be turned on carefully in the limited use cases.
> > You should describe that here explicitly.
>
> Fair enough, I'll send a v2
>
> >
> > Additionally, you may add
> >depends on !EFI_MM_COMM_TEE (or better config?)
>
> That's not the case (yet). I do have a kernel branch were SetVariable at
> runtime is supported, but that's not merged yet. So until this gets accepted
> *all* the boards that want to perform a capsuleupdate on-disk without setting
> the variable need this.
If so, I would suggest that another Kconfig option be added
for the availability of SetVariable at runtime.
This will allow us to keep "depends on" unchanged even if
yet another implementation of SetVariable is introduced in the future.
-Takahiro Akashi
> Cheers
> /Ilias
> >
> > -Takahiro Akashi
> >
> >
> > > > config EFI_CAPSULE_ON_DISK_EARLY
> > > > bool "Initiate capsule-on-disk at U-Boot boottime"
> > > > depends on EFI_CAPSULE_ON_DISK
> > > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > > > index d7136035d8f9..50bed32bfb3b 100644
> > > > --- a/lib/efi_loader/efi_capsule.c
> > > > +++ b/lib/efi_loader/efi_capsule.c
> > > > @@ -948,6 +948,33 @@ efi_status_t __weak efi_load_capsule_drivers(void)
> > > > return ret;
> > > > }
> > > >
> > > > +/**
> > > > + * check_run_capsules - Check whether capsule update should run
> > > > + *
> > > > + * The spec says OsIndications must be set in order to run the capsule
> > > > update
> > > > + * on-disk. Since U-Boot doesn't support runtime SetVariable, allow
> > > > capsules to
> > > > + * run explicitly if CONFIG_EFI_IGNORE_OSINDICATIONS is selected
> > > > + */
> > > > +static bool check_run_capsules(void)
> > > > +{
> > > > + u64 os_indications;
> > > > + efi_uintn_t size;
> > > > + efi_status_t ret;
> > > > +
> > > > + if (IS_ENABLED(CONFIG_EFI_IGNORE_OSINDICATIONS))
> > > > + return true;
> > > > +
> > > > + size = sizeof(os_indications);
> > > > + ret = efi_get_variable_int(L"OsIndications",
> > > > &efi_global_variable_guid,
> > > > + NULL, &size, &os_indications, NULL);
> > > > + if (ret == EFI_SUCCESS &&
> > > > + (os_indications
> > > > + & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
> > >
> > > The bit EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED must be
> > > cleared in OsIndications after successfully applying the capsule. See
> > > related patch
> > >
> > > [PATCH 1/1] efi_loader: fix set_capsule_result()
> > > https://lists.denx.de/pipermail/u-boot/2021-June/453111.html
> > >
> > > Reviewed-by: Heinrich Schuchardt
> > >
> > > > + return true;
> > > > +
> > > > + return false;
> > > > +}
> > > > +
> > > > /**
> > > >* efi_launch_capsule - launch capsules
> > > >*
> > > > @@ -958,20 +985,13 @@ efi_status_t __weak efi_load_capsule_drivers(void)
> > > >*/
> > > > efi_status_t efi_launch_capsules(void)
> > > > {
> > > > - u64 os_indications;
> > > > - efi_uintn_t size;
> > > > struct efi_capsule_header *capsule = NULL;
> > > > u16 **files;
> > > > unsigned int nfiles, index, i;
> > > > u16 variable_name16[12];
> > > > efi_status_t ret;
> > > >
> > > > - size = sizeof(os_indications);
> > > > - ret = efi_get_variable_int(L"OsIndications",
> > > > &efi_global_variable_guid,
> > > > - NULL, &size, &os_indications, NULL);
> > > > - if (ret != EFI_SUCCESS ||
> > > > - !(os_indications
> > > > - & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
> > > > + if (!check_run_capsules())
> > > > return EFI_SUCCESS;
> > > >
> > > > index = get_last_capsule();
> > > >
> > >
Re: [PATCH 0/7] efi: Various tidy-ups and drop the default
On Mon, Jun 28, 2021 at 12:08:27PM -0600, Simon Glass wrote: > Hi Tom, > > On Mon, 28 Jun 2021 at 11:27, Tom Rini wrote: > > > > On Mon, Jun 28, 2021 at 10:26:35AM -0600, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Mon, 28 Jun 2021 at 09:20, Heinrich Schuchardt > > > wrote: > > > > > > > > On 6/28/21 4:18 PM, Simon Glass wrote: > > > > > Hi Tom, Mark, > > > > > > > > > > On Mon, 28 Jun 2021 at 07:37, Tom Rini wrote: > > > > >> > > > > >> On Mon, Jun 28, 2021 at 10:38:50AM +0200, Mark Kettenis wrote: > > > > From: Simon Glass > > > > Date: Sun, 27 Jun 2021 19:48:34 -0600 > > > > > > > > It has come to light that EFI_LOADER adds an extraordinary amount > > > > of > > > > code to U-Boot. For example, with nokia_rx51 the size delta is > > > > about > > > > 90KB. About 170 boards explicitly disable the option, but is is > > > > clear > > > > that many more could, thus saving image size and boot time. > > > > >>> > > > > >>> EFI_LOADER used to be a lot smaller. It is great to see that over > > > > >>> the > > > > >>> years UEFI support has become more complete, but a lot of that new > > > > >>> code implements features that are not at all essential for just > > > > >>> booting an OS from storage. If that growth leads to the suggestion > > > > >>> to > > > > >>> disable EFI_LOADER completely by default, we're putting the cart > > > > >>> before the horse. > > > > >> > > > > >> Well, I see I forgot to prefix my patch with RFC, but I hadn't found > > > > >> EFI_LOADER being used in the wild on armv7, but wasn't sure about the > > > > >> BSD families. I did see that Debian doesn't use it, and that Armbian > > > > >> doesn't even use it on aarch64. > > > > >> > > > > The current situation is affecting U-Boot's image as a svelt > > > > bootloader. > > > > >>> > > > > >>> Really? I know UEFI has a bad reputation in the Open Source world, > > > > >>> and some of its Microsoft-isms are really annoying (yay UCS-2). But > > > > >>> it works, it provides a standardized approach across several > > > > >>> platforms > > > > >>> (ARMv7, AMRv8, RISC-V) and the industry seems to like it. > > > > >>> Personally > > > > >>> I'd wish the industry had standardized on Open Firmware instead, but > > > > >>> that ship sailed a long time ago... > > > > >>> > > > > >>> I find it hard to imagine that 90k is a serious amount of storage > > > > >>> for > > > > >>> something that is going to include a multi-MB Linux kernel. This > > > > >>> isn't code that lives in SPL or TPL where severe size restrictions > > > > >>> apply. > > > > >> > > > > >> In one of those cases where I need to pop back in to the other (Nokia > > > > >> N900 specific) thread and see if the big size reduction really was > > > > >> just > > > > >> disabling EFI_LOADER, it's perhaps just one of those "fun" things > > > > >> about > > > > >> Kconfig and anything other than "make oldconfig" for spotting new > > > > >> config > > > > >> options that default to enabled. > > > > > > > > > > Yes it will be interesting to see what you find there. My results on > > > > > nokia_rx51 were something like this: > > > > > > > > > > default > > > > > arm: (for 1/1 boards) all +129370.0 bss +1136.0 data +7399.0 > > > > > rodata +10989.0 text +109846.0 > > > > > > > > > > without ebbr > > > > >arm: (for 1/1 boards) all +38460.0 bss +1040.0 data +2375.0 > > > > > rodata +5333.0 text +29712.0 > > > > > > > > > > with various other things: > > > > > CONFIG_OF_LIBFDT_ASSUME_MASK=7 > > > > > # CONFIG_OF_TRANSLATE is not set > > > > > # CONFIG_SIMPLE_BUS is not set > > > > > # CONFIG_TI_SYSC is not set > > > > > # CONFIG_CMD_FDT is not set > > > > > > > > > >arm: (for 1/1 boards) all +19170.0 bss -16.0 data +360.0 rodata > > > > > +3274.0 text +15552.0 > > > > > > > > > > (Mark, in the same email:) > > > > >>> FIT simply isn't fit for purpose (pun intended). It only really > > > > >>> works > > > > >>> for booting Linux, and forces people to combine u-boot, kernel, > > > > >>> initial ramdisk and other firmware components into a single image. > > > > >>> That is really undesirable as: > > > > >>> - This makes it sigificantly harder to update individual components > > > > >>> of > > > > >>> such an image. Making it hard to update a kernel is obviously a > > > > >>> serious security risk. > > > > >>> - This makes it impossible to build an OS install image that works > > > > >>> om > > > > >>> multiple boards/SoCs. > > > > > > > > > > > > > > > I would really like to understand this better. The whole thing is a > > > > > complete mystery to me. > > > > > > > > > > Firstly I have sometimes fiddled with booting other OSes using FIT. It > > > > > seemed OK. I can't see why it only works with Linux. > > > > > > > > > > Secondly, I don't expect that U-Boot itself would be in the FIT. > > > > > > > > > > Thirdly, do you really want the kernel and initrd to be separate? At > >
[PATCH v2] efi_loader: Allow capsule update on-disk without checking OsIndications
Although U-Boot supports capsule update on-disk, it's lack of support for
SetVariable at runtime prevents applications like fwupd from using it.
In order to perform the capsule update on-disk the spec says that the OS
must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
the OsIndications variable. The firmware then checks for the
EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
variable, which is set by submitter to trigger processing of the capsule
on next reboot.
Let's add a config option which ignores the bit checking in OsIndications
and just rely on the capsule being present (which breaks the EFI spec).
Since U-Boot deletes the capsule while processing it, we won't end up
running it multiple times.
Note that this is allowed for all capsules. In the future once,
authenticated capsules is fully supported, we can limit the functionality
to those only.
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Ilias Apalodimas
---
changes since v1:
- explicitly state in the Kconfig that this breaks the EFI spec.
lib/efi_loader/Kconfig | 10 ++
lib/efi_loader/efi_capsule.c | 36
2 files changed, 38 insertions(+), 8 deletions(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 684adfb62379..9c4d4b41e450 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -137,6 +137,16 @@ config EFI_CAPSULE_ON_DISK
under a specific directory on UEFI system partition instead of
via UpdateCapsule API.
+config EFI_IGNORE_OSINDICATIONS
+ bool "Ignore OsIndications for CapsuleUpdate on-disk"
+ depends on EFI_CAPSULE_ON_DISK
+ default n
+ help
+ There are boards were we can't support SetVariable at runtime.
+ Select this option if you want to use capsule-on-disk feature,
+ without setting the OsIndications bit. Note that enabling this
+ breaks conformance to the EFI spec and CapsuleUpdate on-disk.
+
config EFI_CAPSULE_ON_DISK_EARLY
bool "Initiate capsule-on-disk at U-Boot boottime"
depends on EFI_CAPSULE_ON_DISK
diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
index d7136035d8f9..50bed32bfb3b 100644
--- a/lib/efi_loader/efi_capsule.c
+++ b/lib/efi_loader/efi_capsule.c
@@ -948,6 +948,33 @@ efi_status_t __weak efi_load_capsule_drivers(void)
return ret;
}
+/**
+ * check_run_capsules - Check whether capsule update should run
+ *
+ * The spec says OsIndications must be set in order to run the capsule update
+ * on-disk. Since U-Boot doesn't support runtime SetVariable, allow capsules
to
+ * run explicitly if CONFIG_EFI_IGNORE_OSINDICATIONS is selected
+ */
+static bool check_run_capsules(void)
+{
+ u64 os_indications;
+ efi_uintn_t size;
+ efi_status_t ret;
+
+ if (IS_ENABLED(CONFIG_EFI_IGNORE_OSINDICATIONS))
+ return true;
+
+ size = sizeof(os_indications);
+ ret = efi_get_variable_int(L"OsIndications", &efi_global_variable_guid,
+ NULL, &size, &os_indications, NULL);
+ if (ret == EFI_SUCCESS &&
+ (os_indications
+ & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
+ return true;
+
+ return false;
+}
+
/**
* efi_launch_capsule - launch capsules
*
@@ -958,20 +985,13 @@ efi_status_t __weak efi_load_capsule_drivers(void)
*/
efi_status_t efi_launch_capsules(void)
{
- u64 os_indications;
- efi_uintn_t size;
struct efi_capsule_header *capsule = NULL;
u16 **files;
unsigned int nfiles, index, i;
u16 variable_name16[12];
efi_status_t ret;
- size = sizeof(os_indications);
- ret = efi_get_variable_int(L"OsIndications", &efi_global_variable_guid,
- NULL, &size, &os_indications, NULL);
- if (ret != EFI_SUCCESS ||
- !(os_indications
- & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
+ if (!check_run_capsules())
return EFI_SUCCESS;
index = get_last_capsule();
--
2.32.0.rc0
Re: [PATCH] efi_loader: Allow capsule update on-disk without checking OsIndications
> > >
[...]
> > > +config EFI_IGNORE_OSINDICATIONS
> > > + bool "Ignore OsIndications for CapsuleUpdate on-disk"
> > > + depends on EFI_CAPSULE_ON_DISK
> > > + default n
> > > + help
> > > + There are boards were we can't support SetVariable at runtime.
> > > + Select this option if you want to use capsule-on-disk feature,
> > > + without setting the OsIndications bit.
>
> Obviously, this option breaks the conformance to UEFI specification
> and must be turned on carefully in the limited use cases.
> You should describe that here explicitly.
Fair enough, I'll send a v2
>
> Additionally, you may add
>depends on !EFI_MM_COMM_TEE (or better config?)
That's not the case (yet). I do have a kernel branch were SetVariable at
runtime is supported, but that's not merged yet. So until this gets accepted
*all* the boards that want to perform a capsuleupdate on-disk without setting
the variable need this.
Cheers
/Ilias
>
> -Takahiro Akashi
>
>
> > > config EFI_CAPSULE_ON_DISK_EARLY
> > > bool "Initiate capsule-on-disk at U-Boot boottime"
> > > depends on EFI_CAPSULE_ON_DISK
> > > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > > index d7136035d8f9..50bed32bfb3b 100644
> > > --- a/lib/efi_loader/efi_capsule.c
> > > +++ b/lib/efi_loader/efi_capsule.c
> > > @@ -948,6 +948,33 @@ efi_status_t __weak efi_load_capsule_drivers(void)
> > > return ret;
> > > }
> > >
> > > +/**
> > > + * check_run_capsules - Check whether capsule update should run
> > > + *
> > > + * The spec says OsIndications must be set in order to run the capsule
> > > update
> > > + * on-disk. Since U-Boot doesn't support runtime SetVariable, allow
> > > capsules to
> > > + * run explicitly if CONFIG_EFI_IGNORE_OSINDICATIONS is selected
> > > + */
> > > +static bool check_run_capsules(void)
> > > +{
> > > + u64 os_indications;
> > > + efi_uintn_t size;
> > > + efi_status_t ret;
> > > +
> > > + if (IS_ENABLED(CONFIG_EFI_IGNORE_OSINDICATIONS))
> > > + return true;
> > > +
> > > + size = sizeof(os_indications);
> > > + ret = efi_get_variable_int(L"OsIndications", &efi_global_variable_guid,
> > > +NULL, &size, &os_indications, NULL);
> > > + if (ret == EFI_SUCCESS &&
> > > + (os_indications
> > > + & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
> >
> > The bit EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED must be
> > cleared in OsIndications after successfully applying the capsule. See
> > related patch
> >
> > [PATCH 1/1] efi_loader: fix set_capsule_result()
> > https://lists.denx.de/pipermail/u-boot/2021-June/453111.html
> >
> > Reviewed-by: Heinrich Schuchardt
> >
> > > + return true;
> > > +
> > > + return false;
> > > +}
> > > +
> > > /**
> > >* efi_launch_capsule - launch capsules
> > >*
> > > @@ -958,20 +985,13 @@ efi_status_t __weak efi_load_capsule_drivers(void)
> > >*/
> > > efi_status_t efi_launch_capsules(void)
> > > {
> > > - u64 os_indications;
> > > - efi_uintn_t size;
> > > struct efi_capsule_header *capsule = NULL;
> > > u16 **files;
> > > unsigned int nfiles, index, i;
> > > u16 variable_name16[12];
> > > efi_status_t ret;
> > >
> > > - size = sizeof(os_indications);
> > > - ret = efi_get_variable_int(L"OsIndications", &efi_global_variable_guid,
> > > -NULL, &size, &os_indications, NULL);
> > > - if (ret != EFI_SUCCESS ||
> > > - !(os_indications
> > > - & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
> > > + if (!check_run_capsules())
> > > return EFI_SUCCESS;
> > >
> > > index = get_last_capsule();
> > >
> >
Re: [PATCH] efi_loader: Allow capsule update on-disk without checking OsIndications
On Tue, Jun 29, 2021 at 09:43:40AM +0200, Heinrich Schuchardt wrote:
> On 6/29/21 6:55 AM, Ilias Apalodimas wrote:
> > From: apalos
> >
> > Although U-Boot supports capsule update on-disk, it's lack of support for
> > SetVariable at runtime prevents applications like fwupd from using it.
> >
> > In order to perform the capsule update on-disk the spec says that the OS
> > must copy the capsule to the \EFI\UpdateCapsule directory and set a bit in
> > the OsIndications variable. The firmware then checks for the
> > EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED bit in OsIndications
> > variable, which is set by submitter to trigger processing of the capsule
> > on next reboot.
> >
> > Let's add a config option which ignores the bit checking in OsIndications
> > and just rely on the capsule being present. Since U-Boot deletes the
> > capsule while processing it, we won't end up running it multiple times.
> >
> > Note that this is allowed for all capsules. In the future once,
> > authenticated capsules is fully supported, we can limit the functionality
> > to those only.
> >
> > Signed-off-by: apalos
> > ---
> > lib/efi_loader/Kconfig | 9 +
> > lib/efi_loader/efi_capsule.c | 36
> > 2 files changed, 37 insertions(+), 8 deletions(-)
> >
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 684adfb62379..5a3820e76122 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -137,6 +137,15 @@ config EFI_CAPSULE_ON_DISK
> > under a specific directory on UEFI system partition instead of
> > via UpdateCapsule API.
> >
> > +config EFI_IGNORE_OSINDICATIONS
> > + bool "Ignore OsIndications for CapsuleUpdate on-disk"
> > + depends on EFI_CAPSULE_ON_DISK
> > + default n
> > + help
> > + There are boards were we can't support SetVariable at runtime.
> > + Select this option if you want to use capsule-on-disk feature,
> > + without setting the OsIndications bit.
Obviously, this option breaks the conformance to UEFI specification
and must be turned on carefully in the limited use cases.
You should describe that here explicitly.
Additionally, you may add
depends on !EFI_MM_COMM_TEE (or better config?)
-Takahiro Akashi
> > config EFI_CAPSULE_ON_DISK_EARLY
> > bool "Initiate capsule-on-disk at U-Boot boottime"
> > depends on EFI_CAPSULE_ON_DISK
> > diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> > index d7136035d8f9..50bed32bfb3b 100644
> > --- a/lib/efi_loader/efi_capsule.c
> > +++ b/lib/efi_loader/efi_capsule.c
> > @@ -948,6 +948,33 @@ efi_status_t __weak efi_load_capsule_drivers(void)
> > return ret;
> > }
> >
> > +/**
> > + * check_run_capsules - Check whether capsule update should run
> > + *
> > + * The spec says OsIndications must be set in order to run the capsule
> > update
> > + * on-disk. Since U-Boot doesn't support runtime SetVariable, allow
> > capsules to
> > + * run explicitly if CONFIG_EFI_IGNORE_OSINDICATIONS is selected
> > + */
> > +static bool check_run_capsules(void)
> > +{
> > + u64 os_indications;
> > + efi_uintn_t size;
> > + efi_status_t ret;
> > +
> > + if (IS_ENABLED(CONFIG_EFI_IGNORE_OSINDICATIONS))
> > + return true;
> > +
> > + size = sizeof(os_indications);
> > + ret = efi_get_variable_int(L"OsIndications", &efi_global_variable_guid,
> > + NULL, &size, &os_indications, NULL);
> > + if (ret == EFI_SUCCESS &&
> > + (os_indications
> > + & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
>
> The bit EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED must be
> cleared in OsIndications after successfully applying the capsule. See
> related patch
>
> [PATCH 1/1] efi_loader: fix set_capsule_result()
> https://lists.denx.de/pipermail/u-boot/2021-June/453111.html
>
> Reviewed-by: Heinrich Schuchardt
>
> > + return true;
> > +
> > + return false;
> > +}
> > +
> > /**
> >* efi_launch_capsule - launch capsules
> >*
> > @@ -958,20 +985,13 @@ efi_status_t __weak efi_load_capsule_drivers(void)
> >*/
> > efi_status_t efi_launch_capsules(void)
> > {
> > - u64 os_indications;
> > - efi_uintn_t size;
> > struct efi_capsule_header *capsule = NULL;
> > u16 **files;
> > unsigned int nfiles, index, i;
> > u16 variable_name16[12];
> > efi_status_t ret;
> >
> > - size = sizeof(os_indications);
> > - ret = efi_get_variable_int(L"OsIndications", &efi_global_variable_guid,
> > - NULL, &size, &os_indications, NULL);
> > - if (ret != EFI_SUCCESS ||
> > - !(os_indications
> > - & EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED))
> > + if (!check_run_capsules())
> > return EFI_SUCCESS;
> >
> > index = get_last_capsule();
> >
>
Re: [PULL] u-boot-sh/next
On Fri, Jun 25, 2021 at 03:14:51AM +0200, Marek Vasut wrote: > V3U Falcon board support, for next release. > > The following changes since commit fcf3981161140d265b873a5b609b8867328dc9dc: > > Merge https://source.denx.de/u-boot/custodians/u-boot-x86 (2021-06-23 > 08:46:26 -0400) > > are available in the Git repository at: > > git://source.denx.de/u-boot-sh.git next > > for you to fetch changes up to 0beaae223dd55b3f727f07f38b799a1c58612b1b: > > ARM: rmobile: Add basic PSCI support for R8A779A0 V3U Falcon (2021-06-24 > 20:22:18 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: Pull request: u-boot-spi/next for next
On Mon, Jun 28, 2021 at 09:21:55PM +0530, Jagan Teki wrote: > Hi Tom, > > Please pull this PR for next. > > Summary: > - xSPI Octal DTR support (Pratyush Yadav) > - MXIC SPI driver (Zhengxun) > > CI: > https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/7959 > > thanks, > Jagan. > > The following changes since commit 67edf2553f15e5148efca213af3f41cef3410680: > > Merge branch 'master' of > https://source.denx.de/u-boot/custodians/u-boot-spi into next (2021-06-24 > 11:11:13 -0400) > > 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 f6adec1af4b2f5d3012480c6cdce7743b74a6156: > > mtd: spi-nor-core: Allow using Micron mt35xu512aba in Octal DTR mode > (2021-06-28 12:06:57 +0530) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] arm64: Fix relocation of env_addr if POSITION_INDEPENDENT=y
On Tue, Jun 15, 2021 at 03:33:02PM +0900, Kunihiko Hayashi wrote:
> If both POSITION_INDEPENDENT and SYS_RELOC_GD_ENV_ADDR are enabled,
> wherever original env is placed anywhere, it should be relocated to
> the right address.
>
> Relocation offset gd->reloc_off is calculated with SYS_TEXT_BASE in
> setup_reloc() and env address gd->env_addr is relocated by the offset in
> initr_reloc_global_data().
>
> gd->env_addr
> = (orig env) + gd->reloc_off
> = (orig env) + (gd->relocaddr - SYS_TEXT_BASE)
>
> However, SYS_TEXT_BASE isn't always runtime base address when
> POSITION_INDEPENDENT is enabled. So the relocated env_addr might point to
> wrong address. For example, if SYS_TEXT_BASE is zero, gd->env_addr is
> out of memory location and memory exception will occur.
>
> There is a difference between linked address such as SYS_TEXT_BASE and
> runtime base address. In _main, the difference is calculated as
> "run-vs-link" offset. The env_addr should also be added to the offset
> to fix the address.
>
> gd->env_addr
> = (orig env) + ("run-vs-link" offset) + gd->reloc_off
> = (orig env) + (SYS_TEXT_BASE - _start) + (gd->relocaddr - SYS_TEXT_BASE)
> = (orig env) + (gd->relocaddr - _start)
>
> Cc: Marek Vasut
> Signed-off-by: Kunihiko Hayashi
> Acked-by: Marek Vasut
> Tested-by: Marek Vasut
Applied to u-boot/master, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 1/1] efi_loader: fix set_capsule_result()
On Tue, Jun 29, 2021 at 09:40:21AM +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.
>
> Flag EFI_OS_INDICATIONS_FILE_CAPSULE_DELIVERY_SUPPORTED must be reset in
> variable OsIndications.
You are trying to fix several irrelevant issues here.
Please split them into separate patches as you have always
asked me before.
-Takahiro Akashi
> Signed-off-by: Heinrich Schuchardt
> ---
> lib/efi_loader/efi_capsule.c | 38 +---
> 1 file changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/lib/efi_loader/efi_capsule.c b/lib/efi_loader/efi_capsule.c
> index 60309d4a07..f7c0c5725f 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
> @@ -84,6 +86,8 @@ void set_capsule_result(int index, struct
> efi_capsule_header *capsule,
> struct efi_capsule_result_variable_header result;
> struct efi_time time;
> efi_status_t ret;
> + efi_uintn_t size;
> + u64 os_indications;
>
> efi_create_indexed_name(variable_name16, sizeof(variable_name16),
> "Capsule", index);
> @@ -95,13 +99,33 @@ void set_capsule_result(int index, struct
> efi_capsule_header *capsule,
> else
> memset(&result.capsule_processed, 0, sizeof(time));
> result.capsule_status = return_status;
> - ret = efi_set_variable(variable_name16, &efi_guid_capsule_report,
> -EFI_VARIABLE_NON_VOLATILE |
> -EFI_VARIABLE_BOOTSERVICE_ACCESS |
> -EFI_VARIABLE_RUNTIME_ACCESS,
> -sizeof(result), &result);
> - if (ret)
> - log_err("EFI: creating %ls failed\n", variable_name16);
> + ret = efi_set_variable_int(variable_name16, &efi_guid_capsule_report,
> +EFI_VARIABLE_NON_VOLATILE |
> +EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +EFI_VARIABLE_RUNTIME_ACCESS,
> +sizeof(result), &result, false);
> + if (ret != EFI_SUCCESS)
> + log_err("Setting %ls failed\n", variable_name16);
> +
> + if (return_status != EFI_SUCCESS)
> + return;
> +
> + size = sizeof(os_indications);
> + ret = efi_get_variable_int(L"OsIndications", &efi_global_variable_guid,
> +NULL, &size, &os_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", &efi_global_variable_guid,
> +EFI_VARIABLE_NON_VOLATILE |
> +EFI_VARIABLE_BOOTSERVICE_ACCESS |
> +EFI_VARIABLE_RUNTIME_ACCESS,
> +sizeof(os_indications), &os_indications,
> +false);
> + if (ret != EFI_SUCCESS)
> + log_err("Setting %ls failed\n", L"OsIndications");
> }
>
> #ifdef CONFIG_EFI_CAPSULE_FIRMWARE_MANAGEMENT
> --
> 2.30.2
>
Re: [PATCH] arm: Add (back) VExpress boards support
On Tue, Jun 29, 2021 at 12:45:55PM +0100, Andre Przywara wrote: > The v2021.07 merge window saw the removal of the Arm Ltd. Versatile > Express platform, along with their CA5, CA9 and TC2 boards. The trigger > was the missing conversion of the MMC driver. > > Some folks complained about that internally, so bring those boards back, > but better than ever: > - Use DM and OF_CONTROL for all the boards. Use the .dts files from the > latest Linux kernel (5.13) for that. > - Move the board selection choice into the platform's Kconfig. > - Clean up some shared config and common definitions. > - Drop obsolete features like ATAGs support. > - Switch to the DM_ETH version of the SMC911X Ethernet driver. > - Drop MMC support. > > The PL180 MMC driver actually supports DM_MMC, but that requires a > DM_GPIO driver for the card detect GPIO, which we don't have. This > specific GPIO is actually handled via the "sysregs" device, so we would > need a driver for that. QEMU does not emulate this part, also the DT > description is somewhat "special", so this is left for later. > > This version compiles without any warning for all three boards now. > Tested on QEMU. > > Signed-off-by: Andre Przywara > --- > Hi, > > this relies on the SMC911x driver DT changes, as posted here: > https://lists.denx.de/pipermail/u-boot/2021-June/452989.html > I put a version with the changes broken down here: > https://github.com/Andre-ARM/u-boot/commits/tc2-history > > This was tested on QEMU, for vexpress_ca15_tc2_defconfig with: > $ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G -smp 1 \ > -drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \ > -device loader,file=u-boot.bin,addr=0x8080 -nographic > > Where tramp-tc2.bin is a trampoline replacing the board's firmware: > 00 00 a0 e3 80 00 48 e3 10 ff 2f e1 > (mov r0, #0; movt r0, #0x8080; bx r0) > > The vexpress_ca9x4_defconfig uses a different memory map, so the runes are: > $ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \ > -drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \ > -device loader,file=u-boot.bin,addr=0x6080 -nographic > > tramp-ca9.bin: > 00 00 a0 e3 80 00 46 e3 10 ff 2f e1 > (mov r0, #0; movt r0, #0x6080; bx r0) My big question is how do we run this in CI? Or does it not _need_ that firmware file to really exist? Or is there a pending change to https://gitlab.denx.de/u-boot/u-boot-test-hooks.git to generate / just have exist those magic empty bins? Thanks! -- Tom signature.asc Description: PGP signature
[PATCH] arm: Add (back) VExpress boards support
The v2021.07 merge window saw the removal of the Arm Ltd. Versatile
Express platform, along with their CA5, CA9 and TC2 boards. The trigger
was the missing conversion of the MMC driver.
Some folks complained about that internally, so bring those boards back,
but better than ever:
- Use DM and OF_CONTROL for all the boards. Use the .dts files from the
latest Linux kernel (5.13) for that.
- Move the board selection choice into the platform's Kconfig.
- Clean up some shared config and common definitions.
- Drop obsolete features like ATAGs support.
- Switch to the DM_ETH version of the SMC911X Ethernet driver.
- Drop MMC support.
The PL180 MMC driver actually supports DM_MMC, but that requires a
DM_GPIO driver for the card detect GPIO, which we don't have. This
specific GPIO is actually handled via the "sysregs" device, so we would
need a driver for that. QEMU does not emulate this part, also the DT
description is somewhat "special", so this is left for later.
This version compiles without any warning for all three boards now.
Tested on QEMU.
Signed-off-by: Andre Przywara
---
Hi,
this relies on the SMC911x driver DT changes, as posted here:
https://lists.denx.de/pipermail/u-boot/2021-June/452989.html
I put a version with the changes broken down here:
https://github.com/Andre-ARM/u-boot/commits/tc2-history
This was tested on QEMU, for vexpress_ca15_tc2_defconfig with:
$ qemu-system-arm -M vexpress-a15,secure=on -cpu cortex-a15 -m 1G -smp 1 \
-drive file=tramp-tc2.bin,if=pflash,format=raw,read-only \
-device loader,file=u-boot.bin,addr=0x8080 -nographic
Where tramp-tc2.bin is a trampoline replacing the board's firmware:
00 00 a0 e3 80 00 48 e3 10 ff 2f e1
(mov r0, #0; movt r0, #0x8080; bx r0)
The vexpress_ca9x4_defconfig uses a different memory map, so the runes are:
$ qemu-system-arm -M vexpress-a9 -cpu cortex-a9 -m 1G -smp 1 \
-drive file=tramp-ca9.bin,if=pflash,format=raw,read-only \
-device loader,file=u-boot.bin,addr=0x6080 -nographic
tramp-ca9.bin:
00 00 a0 e3 80 00 46 e3 10 ff 2f e1
(mov r0, #0; movt r0, #0x6080; bx r0)
Cheers,
Andre
.azure-pipelines.yml | 6 +
.gitlab-ci.yml| 12 +
Kconfig | 2 +-
arch/arm/Kconfig | 16 +
arch/arm/dts/Makefile | 5 +
arch/arm/dts/vexpress-v2m-rs1.dtsi| 441 +++
arch/arm/dts/vexpress-v2m.dtsi| 454
arch/arm/dts/vexpress-v2p-ca15_a7.dts | 691 ++
arch/arm/dts/vexpress-v2p-ca5s.dts| 280 +++
arch/arm/dts/vexpress-v2p-ca9.dts | 368 ++
board/armltd/vexpress/Kconfig | 39 +
board/armltd/vexpress/MAINTAINERS | 8 +
board/armltd/vexpress/Makefile| 7 +
board/armltd/vexpress/vexpress_common.c | 196 +
board/armltd/vexpress/vexpress_tc2.c | 82 +++
configs/vexpress_ca15_tc2_defconfig | 16 +
configs/vexpress_ca5x2_defconfig | 15 +
configs/vexpress_ca9x4_defconfig | 15 +
drivers/i2c/Kconfig | 2 +-
env/Kconfig | 5 +-
.../configs/{vexpress_common.h => vexpress.h} | 99 +--
scripts/config_whitelist.txt | 1 -
22 files changed, 2671 insertions(+), 89 deletions(-)
create mode 100644 arch/arm/dts/vexpress-v2m-rs1.dtsi
create mode 100644 arch/arm/dts/vexpress-v2m.dtsi
create mode 100644 arch/arm/dts/vexpress-v2p-ca15_a7.dts
create mode 100644 arch/arm/dts/vexpress-v2p-ca5s.dts
create mode 100644 arch/arm/dts/vexpress-v2p-ca9.dts
create mode 100644 board/armltd/vexpress/Kconfig
create mode 100644 board/armltd/vexpress/MAINTAINERS
create mode 100644 board/armltd/vexpress/Makefile
create mode 100644 board/armltd/vexpress/vexpress_common.c
create mode 100644 board/armltd/vexpress/vexpress_tc2.c
create mode 100644 configs/vexpress_ca15_tc2_defconfig
create mode 100644 configs/vexpress_ca5x2_defconfig
create mode 100644 configs/vexpress_ca9x4_defconfig
rename include/configs/{vexpress_common.h => vexpress.h} (62%)
diff --git a/.azure-pipelines.yml b/.azure-pipelines.yml
index 221e6008062..ddfbd606530 100644
--- a/.azure-pipelines.yml
+++ b/.azure-pipelines.yml
@@ -195,6 +195,12 @@ jobs:
evb_ast2500:
TEST_PY_BD: "evb-ast2500"
TEST_PY_ID: "--id qemu"
+vexpress_ca15_tc2:
+ TEST_PY_BD: "vexpress_ca15_tc2"
+ TEST_PY_ID: "--id qemu"
+vexpress_ca9x4:
+ TEST_PY_BD: "vexpress_ca9x4"
+ TEST_PY_ID: "--id qemu"
integratorcp_cm926ejs:
TEST_PY_BD: "integratorcp_cm926ejs"
TEST_PY_ID: "--id qemu"
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index d072e833a3d..c6498e3b4fd 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -205,6 +205,18 @@ sandbox_flattree test.py:
TEST_PY
[PATCH v5 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 = &sdmmc;
};
+
+ aliases {
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ mmc0 = &sdmmc;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ spi0 = &sfc;
+ };
};
&cru {
@@ -57,6 +66,14 @@
u-boot,spl-fifo-mode;
};
+&sfc {
+ u-boot,dm-pre-reloc;
+};
+
+&spi_flash {
+ u-boot,dm-pre-reloc;
+};
+
&uart1 {
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";
};
+&sfc {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sfc_clk &sfc_cs &sfc_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>;
+ };
+};
+
&tsadc {
status = "okay";
};
--
2.17.1
[PATCH v5 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 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 | 642 + 3 files changed, 651 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..918abb431d --- /dev/null +++ b/drivers/spi/rockchip_sfc.c @@ -0,0 +1,642 @@ +// 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 SFC_IMR_TRAN_FINISH BIT(4) +#define SFC_IMR_BUS_ERR BIT(5) +#define SFC_IMR_NSPI_ERR BIT(
[PATCH v5 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 v5 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(&grf->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(&grf->gpio1ah_iomux, GPIO1A4_MASK,
+GPIO1A4_SFC_CSN0 << GPIO1A4_SHIFT);
+ rk_clrsetreg(&grf->gpio1bl_iomux, GPIO1B1_MASK,
+GPIO1B1_SFC_CLK << GPIO1B1_SHIFT);
+#endif
+
#endif
/* Enable PD_VO (default disable at reset) */
--
2.17.1
[PATCH v5 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
---
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 = <&cru SCLK_SFC>, <&cru HCLK_SFC>;
+ clock-names = "clk_sfc", "hclk_sfc";
+ pinctrl-names = "default";
+ pinctrl-0 = <&sfc_clk &sfc_cs &sfc_bus4>;
+ power-domains = <&power 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 &pcfg_pull_none>,
+ <1 RK_PA1 3 &pcfg_pull_none>,
+ <1 RK_PA2 3 &pcfg_pull_none>,
+ <1 RK_PA3 3 &pcfg_pull_none>;
+ };
+
+ sfc_bus2: sfc-bus2 {
+ rockchip,pins =
+ <1 RK_PA0 3 &pcfg_pull_none>,
+ <1 RK_PA1 3 &pcfg_pull_none>;
+ };
+
+ sfc_cs: sfc-cs {
+ rockchip,pins =
+ <1 RK_PA4 3 &pcfg_pull_none>;
+ };
+
+ sfc_clk: sfc-clk {
+ rockchip,pins =
+ <1 RK_PB1 3 &pcfg_pull_none>;
+ };
+ };
+
lcdc {
lcdc_rgb_dclk_pin: lcdc-rgb-dclk-pin {
rockchip,pins =
--
2.17.1
[PATCH v5 0/5] rockchip_sfc: add support for Rockchip SFC
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 | 642 + 9 files changed, 800 insertions(+) create mode 100644 drivers/spi/rockchip_sfc.c -- 2.17.1
[PATCH v3 1/3] mmc: rockchip_sdhci: add phy and clock config for rk3399
Add clock, phy and other configuration, it is convenient to support
new controller. Here a short summary of the changes:
- Add mmc_of_parse to parse dts config.
- Remove OF_PLATDATA related code.
- Reorder header inclusion.
- Add phy ops.
- add ops set_ios_post to modify the parameters of phy when the
clock changes.
- Add execute tuning api for hs200 tuning.
Signed-off-by: Yifeng Zhao
---
Changes in v3:
- Optimize hs200 tuning function.
- Add check for callback function.
- Add return value for tuning function.
- Fixed source clock rate with host->max_clk, the interface clock is divided
from the source clock.
Changes in v2:
- Add mmc_of_parse to parse dts config.
- Used read_poll_timeout api to check dll lock status
- Add execute tuning api for hs200 tuning
drivers/mmc/rockchip_sdhci.c | 313 +++
1 file changed, 277 insertions(+), 36 deletions(-)
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index d95f8b2a15..eff134c8f5 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -6,90 +6,322 @@
*/
#include
+#include
#include
+#include
#include
+#include
#include
#include
+#include
#include
#include
+#include "mmc_private.h"
#include
-#include
+#include
+#include
+#include
/* 400KHz is max freq for card ID etc. Use that as min */
#define EMMC_MIN_FREQ 40
+#define KHz(1000)
+#define MHz(1000 * KHz)
+#define SDHCI_TUNING_LOOP_COUNT40
+
+#define PHYCTRL_CALDONE_MASK 0x1
+#define PHYCTRL_CALDONE_SHIFT 0x6
+#define PHYCTRL_CALDONE_DONE 0x1
+#define PHYCTRL_DLLRDY_MASK0x1
+#define PHYCTRL_DLLRDY_SHIFT 0x5
+#define PHYCTRL_DLLRDY_DONE0x1
+#define PHYCTRL_FREQSEL_200M 0x0
+#define PHYCTRL_FREQSEL_50M0x1
+#define PHYCTRL_FREQSEL_100M 0x2
+#define PHYCTRL_FREQSEL_150M 0x3
+#define PHYCTRL_DLL_LOCK_WO_TMOUT(x) \
+ x) >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK) ==\
+ PHYCTRL_DLLRDY_DONE)
struct rockchip_sdhc_plat {
-#if CONFIG_IS_ENABLED(OF_PLATDATA)
- struct dtd_rockchip_rk3399_sdhci_5_1 dtplat;
-#endif
struct mmc_config cfg;
struct mmc mmc;
};
+struct rockchip_emmc_phy {
+ u32 emmcphy_con[7];
+ u32 reserved;
+ u32 emmcphy_status;
+};
+
struct rockchip_sdhc {
struct sdhci_host host;
+ struct udevice *dev;
void *base;
+ struct rockchip_emmc_phy *phy;
+ struct clk emmc_clk;
+};
+
+struct sdhci_data {
+ int (*emmc_set_clock)(struct sdhci_host *host, unsigned int clock);
+ int (*emmc_phy_init)(struct udevice *dev);
+ int (*get_phy)(struct udevice *dev);
+};
+
+static int rk3399_emmc_phy_init(struct udevice *dev)
+{
+ return 0;
+}
+
+static void rk3399_emmc_phy_power_on(struct rockchip_emmc_phy *phy, u32 clock)
+{
+ u32 caldone, dllrdy, freqsel;
+
+ writel(RK_CLRSETBITS(7 << 4, 0), &phy->emmcphy_con[6]);
+ writel(RK_CLRSETBITS(1 << 11, 1 << 11), &phy->emmcphy_con[0]);
+ writel(RK_CLRSETBITS(0xf << 7, 6 << 7), &phy->emmcphy_con[0]);
+
+ /*
+* According to the user manual, calpad calibration
+* cycle takes more than 2us without the minimal recommended
+* value, so we may need a little margin here
+*/
+ udelay(3);
+ writel(RK_CLRSETBITS(1, 1), &phy->emmcphy_con[6]);
+
+ /*
+* According to the user manual, it asks driver to
+* wait 5us for calpad busy trimming. But it seems that
+* 5us of caldone isn't enough for all cases.
+*/
+ udelay(500);
+ caldone = readl(&phy->emmcphy_status);
+ caldone = (caldone >> PHYCTRL_CALDONE_SHIFT) & PHYCTRL_CALDONE_MASK;
+ if (caldone != PHYCTRL_CALDONE_DONE) {
+ printf("%s: caldone timeout.\n", __func__);
+ return;
+ }
+
+ /* Set the frequency of the DLL operation */
+ if (clock < 75 * MHz)
+ freqsel = PHYCTRL_FREQSEL_50M;
+ else if (clock < 125 * MHz)
+ freqsel = PHYCTRL_FREQSEL_100M;
+ else if (clock < 175 * MHz)
+ freqsel = PHYCTRL_FREQSEL_150M;
+ else
+ freqsel = PHYCTRL_FREQSEL_200M;
+
+ /* Set the frequency of the DLL operation */
+ writel(RK_CLRSETBITS(3 << 12, freqsel << 12), &phy->emmcphy_con[0]);
+ writel(RK_CLRSETBITS(1 << 1, 1 << 1), &phy->emmcphy_con[6]);
+
+ read_poll_timeout(readl, &phy->emmcphy_status, dllrdy,
+ PHYCTRL_DLL_LOCK_WO_TMOUT(dllrdy), 1, 5000);
+}
+
+static void rk3399_emmc_phy_power_off(struct rockchip_emmc_phy *phy)
+{
+ writel(RK_CLRSETBITS(1, 0), &phy->emmcphy_con[6]);
+ writel(RK_CLRSETBITS(1 << 1, 0), &phy->emmcphy_con[6]);
+}
+
+static int rk3399_emmc_get_phy(struct udevice *dev)
+{
+ struct rockchip_sdhc *priv = dev_get_priv(dev);
+ ofnode phy_node;
+ void
[PATCH v3 2/3] mmc: rockchip_sdhci: Add support for RK3568
This patch adds support for the RK3568 platform to this driver.
Signed-off-by: Yifeng Zhao
---
Changes in v3:
- Config the interface clock by clk_set_rate directly
Changes in v2:
- Used sdhci_set_clock api to set clock.
- Used read_poll_timeout api to check dll status.
drivers/mmc/rockchip_sdhci.c | 109 +++
1 file changed, 109 insertions(+)
diff --git a/drivers/mmc/rockchip_sdhci.c b/drivers/mmc/rockchip_sdhci.c
index eff134c8f5..1ac00587d4 100644
--- a/drivers/mmc/rockchip_sdhci.c
+++ b/drivers/mmc/rockchip_sdhci.c
@@ -42,6 +42,34 @@
x) >> PHYCTRL_DLLRDY_SHIFT) & PHYCTRL_DLLRDY_MASK) ==\
PHYCTRL_DLLRDY_DONE)
+/* Rockchip specific Registers */
+#define DWCMSHC_EMMC_DLL_CTRL 0x800
+#define DWCMSHC_EMMC_DLL_CTRL_RESETBIT(1)
+#define DWCMSHC_EMMC_DLL_RXCLK 0x804
+#define DWCMSHC_EMMC_DLL_TXCLK 0x808
+#define DWCMSHC_EMMC_DLL_STRBIN0x80c
+#define DWCMSHC_EMMC_DLL_STATUS0 0x840
+#define DWCMSHC_EMMC_DLL_STATUS1 0x844
+#define DWCMSHC_EMMC_DLL_START BIT(0)
+#define DWCMSHC_EMMC_DLL_RXCLK_SRCSEL 29
+#define DWCMSHC_EMMC_DLL_START_POINT 16
+#define DWCMSHC_EMMC_DLL_START_DEFAULT 5
+#define DWCMSHC_EMMC_DLL_INC_VALUE 2
+#define DWCMSHC_EMMC_DLL_INC 8
+#define DWCMSHC_EMMC_DLL_DLYENABIT(27)
+#define DLL_TXCLK_TAPNUM_DEFAULT 0x10
+#define DLL_STRBIN_TAPNUM_DEFAULT 0x3
+#define DLL_TXCLK_TAPNUM_FROM_SW BIT(24)
+#define DWCMSHC_EMMC_DLL_LOCKEDBIT(8)
+#define DWCMSHC_EMMC_DLL_TIMEOUT BIT(9)
+#define DLL_RXCLK_NO_INVERTER 1
+#define DLL_RXCLK_INVERTER 0
+#define DWCMSHC_ENHANCED_STROBEBIT(8)
+#define DLL_LOCK_WO_TMOUT(x) \
+ x) & DWCMSHC_EMMC_DLL_LOCKED) == DWCMSHC_EMMC_DLL_LOCKED) && \
+ (((x) & DWCMSHC_EMMC_DLL_TIMEOUT) == 0))
+#define ROCKCHIP_MAX_CLKS 3
+
struct rockchip_sdhc_plat {
struct mmc_config cfg;
struct mmc mmc;
@@ -167,6 +195,77 @@ static int rk3399_sdhci_emmc_set_clock(struct sdhci_host
*host, unsigned int clo
return 0;
}
+static int rk3568_emmc_phy_init(struct udevice *dev)
+{
+ struct rockchip_sdhc *prv = dev_get_priv(dev);
+ struct sdhci_host *host = &prv->host;
+ u32 extra;
+
+ extra = DLL_RXCLK_NO_INVERTER << DWCMSHC_EMMC_DLL_RXCLK_SRCSEL;
+ sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_RXCLK);
+
+ return 0;
+}
+
+static int rk3568_sdhci_emmc_set_clock(struct sdhci_host *host, unsigned int
clock)
+{
+ struct rockchip_sdhc *priv = container_of(host, struct rockchip_sdhc,
host);
+ int val, ret;
+ u32 extra;
+
+ if (clock > host->max_clk)
+ clock = host->max_clk;
+ if (clock)
+ clk_set_rate(&priv->emmc_clk, clock);
+
+ sdhci_set_clock(host->mmc, clock);
+
+ if (clock >= 100 * MHz) {
+ /* reset DLL */
+ sdhci_writel(host, DWCMSHC_EMMC_DLL_CTRL_RESET,
DWCMSHC_EMMC_DLL_CTRL);
+ udelay(1);
+ sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_CTRL);
+
+ /* Init DLL settings */
+ extra = DWCMSHC_EMMC_DLL_START_DEFAULT <<
DWCMSHC_EMMC_DLL_START_POINT |
+ DWCMSHC_EMMC_DLL_INC_VALUE << DWCMSHC_EMMC_DLL_INC |
+ DWCMSHC_EMMC_DLL_START;
+ sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_CTRL);
+
+ ret = read_poll_timeout(readl, host->ioaddr +
DWCMSHC_EMMC_DLL_STATUS0,
+ val, DLL_LOCK_WO_TMOUT(val), 1, 500);
+ if (ret)
+ return ret;
+
+ extra = DWCMSHC_EMMC_DLL_DLYENA |
+ DLL_RXCLK_NO_INVERTER << DWCMSHC_EMMC_DLL_RXCLK_SRCSEL;
+ sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_RXCLK);
+
+ extra = DWCMSHC_EMMC_DLL_DLYENA |
+ DLL_TXCLK_TAPNUM_DEFAULT |
+ DLL_TXCLK_TAPNUM_FROM_SW;
+ sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_TXCLK);
+
+ extra = DWCMSHC_EMMC_DLL_DLYENA |
+ DLL_STRBIN_TAPNUM_DEFAULT;
+ sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_STRBIN);
+ } else {
+ /* reset the clock phase when the frequency is lower than
100MHz */
+ sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_CTRL);
+ extra = DLL_RXCLK_NO_INVERTER << DWCMSHC_EMMC_DLL_RXCLK_SRCSEL;
+ sdhci_writel(host, extra, DWCMSHC_EMMC_DLL_RXCLK);
+ sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_TXCLK);
+ sdhci_writel(host, 0, DWCMSHC_EMMC_DLL_STRBIN);
+ }
+
+ return 0;
+}
+
+static int rk3568_emmc_get_phy(struct udevice *dev)
+{
+ return 0;
+}
+
static int rockchip_sdhci_set_ios_post(struct sdhci_host *host)
{
struct rockchip_sdhc *priv = container_of(host, struct rockchip_sdhc,
host);
@@ -339,11
[PATCH v3 0/3] Add hs400 support for rk3399 and rk3568
RK3399 and RK3568 are use different sdhci controllers. The drivers need to be updated to support these two platforms and it's easy to support new platforms. Changes in v3: - Optimize hs200 tuning function. - Add check for callback function. - Add return value for tuning function. - Fixed source clock rate with host->max_clk, the interface clock is divided from the source clock. - Config the interface clock by clk_set_rate directly - Enable SDMA. Changes in v2: - Add mmc_of_parse to parse dts config. - Used read_poll_timeout api to check dll lock status - Add execute tuning api for hs200 tuning - Used sdhci_set_clock api to set clock. - Used read_poll_timeout api to check dll status. Yifeng Zhao (3): mmc: rockchip_sdhci: add phy and clock config for rk3399 mmc: rockchip_sdhci: Add support for RK3568 rockchip: config: evb-rk3399: add hs400 and SDMA support configs/evb-rk3399_defconfig | 2 + drivers/mmc/rockchip_sdhci.c | 422 --- 2 files changed, 388 insertions(+), 36 deletions(-) -- 2.17.1
[PATCH v3 3/3] rockchip: config: evb-rk3399: add hs400 and SDMA support
This enable hs400 and SDMA support for emmc on evb-rk3399. Signed-off-by: Yifeng Zhao --- Changes in v3: - Enable SDMA. configs/evb-rk3399_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig index 21477719dc..d5eba1d903 100644 --- a/configs/evb-rk3399_defconfig +++ b/configs/evb-rk3399_defconfig @@ -29,9 +29,11 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_ROCKCHIP_GPIO=y CONFIG_SYS_I2C_ROCKCHIP=y CONFIG_MISC=y +CONFIG_MMC_HS400_SUPPORT=y CONFIG_MMC_DW=y CONFIG_MMC_DW_ROCKCHIP=y CONFIG_MMC_SDHCI=y +CONFIG_MMC_SDHCI_SDMA=y CONFIG_MMC_SDHCI_ROCKCHIP=y CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_DM_ETH=y -- 2.17.1
