[PATCH v4 5/5] qemu: add documentation to qfw.h
Also rename a "length" to "size" for consistency with the rest of qfw.
Signed-off-by: Asherah Connor
---
(no changes since v1)
drivers/misc/qfw.c | 6 ++--
include/qfw.h | 86 +++---
2 files changed, 84 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
index b0c82e2098..3e8c1a9cda 100644
--- a/drivers/misc/qfw.c
+++ b/drivers/misc/qfw.c
@@ -283,14 +283,14 @@ static void qfw_read_entry_dma(struct qfw_dev *qdev, u16
entry, u32 size,
ops->read_entry_dma(qdev->dev, );
}
-void qfw_read_entry(struct udevice *dev, u16 entry, u32 length, void *address)
+void qfw_read_entry(struct udevice *dev, u16 entry, u32 size, void *address)
{
struct qfw_dev *qdev = dev_get_uclass_priv(dev);
if (qdev->dma_present)
- qfw_read_entry_dma(qdev, entry, length, address);
+ qfw_read_entry_dma(qdev, entry, size, address);
else
- qfw_read_entry_io(qdev, entry, length, address);
+ qfw_read_entry_io(qdev, entry, size, address);
}
int qfw_register(struct udevice *dev)
diff --git a/include/qfw.h b/include/qfw.h
index 41d4db08d6..d59c71a5dd 100644
--- a/include/qfw.h
+++ b/include/qfw.h
@@ -8,6 +8,11 @@
#include
+/*
+ * List of firmware configuration item selectors. The official source of truth
+ * for these is the QEMU source itself; see
+ * https://github.com/qemu/qemu/blob/master/hw/nvram/fw_cfg.c
+ */
enum {
FW_CFG_SIGNATURE= 0x00,
FW_CFG_ID = 0x01,
@@ -66,8 +71,10 @@ enum {
#define FW_CFG_DMA_SKIP(1 << 2)
#define FW_CFG_DMA_SELECT (1 << 3)
+/* Bit set in FW_CFG_ID response to indicate DMA interface availability. */
#define FW_CFG_DMA_ENABLED (1 << 1)
+/* Structs read from FW_CFG_FILE_DIR. */
struct fw_cfg_file {
__be32 size;
__be16 select;
@@ -134,27 +141,56 @@ struct bios_linker_entry {
};
} __packed;
+/* DMA transfer control data between UCLASS_QFW and QEMU. */
struct qfw_dma {
__be32 control;
__be32 length;
__be64 address;
};
+/* uclass per-device configuration information */
struct qfw_dev {
- struct udevice *dev;
- bool dma_present;
- struct list_head fw_list;
+ struct udevice *dev;/* Transport device */
+ bool dma_present; /* DMA interface usable? */
+ struct list_head fw_list; /* Cached firmware file list */
};
+/* Ops used internally between UCLASS_QFW and its driver implementations. */
struct dm_qfw_ops {
+ /**
+* read_entry_io() - Read a firmware config entry using the regular
+* IO interface for the platform (either PIO or MMIO)
+*
+* Supply FW_CFG_INVALID as the entry to continue a previous read. In
+* this case, no selector will be issued before reading.
+*
+* @dev: Device to use
+* @entry: Firmware config entry number (e.g. FW_CFG_SIGNATURE)
+* @size: Number of bytes to read
+* @address: Target location for read
+*/
void (*read_entry_io)(struct udevice *dev, u16 entry, u32 size,
void *address);
+
+ /**
+* read_entry_dma() - Read a firmware config entry using the DMA
+* interface
+*
+* Supply FW_CFG_INVALID as the entry to continue a previous read. In
+* this case, no selector will be issued before reading.
+*
+* This method assumes DMA availability has already been confirmed.
+*
+* @dev: Device to use
+* @dma: DMA transfer control struct
+*/
void (*read_entry_dma)(struct udevice *dev, struct qfw_dma *dma);
};
#define dm_qfw_get_ops(dev) \
((struct dm_qfw_ops *)(dev)->driver->ops)
+/* Used internally by driver implementations on successful probe. */
int qfw_register(struct udevice *dev);
struct udevice;
@@ -168,8 +204,37 @@ struct udevice;
*/
int qfw_get_dev(struct udevice **devp);
-void qfw_read_entry(struct udevice *dev, u16 entry, u32 length, void *address);
+/**
+ * Read a QEMU firmware config entry
+ *
+ * The appropriate transport and interface will be selected automatically.
+ *
+ * @dev: Device to use
+ * @entry: Firmware config entry number (e.g. FW_CFG_SIGNATURE)
+ * @size: Number of bytes to read
+ * @address: Target location for read
+ */
+void qfw_read_entry(struct udevice *dev, u16 entry, u32 size, void *address);
+
+/**
+ * Reads the QEMU firmware config file list, for later use with qfw_find_file.
+ *
+ * If the list has already been read, returns 0 (success).
+ *
+ * @dev: Device to use
+ *
+ * @return 0 on success, -ENOMEM if unable to allocate.
+ */
int qfw_read_firmware_list(struct udevice *dev);
+
+/**
+ * Finds a file by name in the QEMU firmware config file list.
+ *
+ * @dev: Device to use
+ * @name: Name of file to locate (e.g. "etc/table-loader")
+ *
+ *
[PATCH v4 1/5] arm: x86: qemu: move qfw to DM uclass, add Arm support
Updates the QFW driver to use the driver model, splitting the driver
into qfw_pio and qfw_mmio (for non-x86) in their own uclass.
Signed-off-by: Asherah Connor
---
Changes in v4:
- PIO definitions are now #defines
- qfw_*_plat structs are no longer in header files
- Remove yield/pause in DMA wait loop
- Change struct udevice *qfw_get_dev(void) to int qfw_get_dev(struct
udevice **)
arch/arm/Kconfig | 1 +
arch/x86/cpu/qemu/cpu.c | 9 +-
arch/x86/cpu/qemu/qemu.c | 47 +---
arch/x86/cpu/qfw_cpu.c | 11 +-
cmd/qfw.c| 52 -
common/Makefile | 2 +
common/qfw.c | 105 +
drivers/misc/Makefile| 6 +-
drivers/misc/qfw.c | 238 ++-
drivers/misc/qfw_mmio.c | 119
drivers/misc/qfw_pio.c | 69
include/dm/uclass-id.h | 1 +
include/qfw.h| 61 ++
13 files changed, 466 insertions(+), 255 deletions(-)
create mode 100644 common/qfw.c
create mode 100644 drivers/misc/qfw_mmio.c
create mode 100644 drivers/misc/qfw_pio.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d51abbeaf0..cd01dc458a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -937,6 +937,7 @@ config ARCH_QEMU
imply DM_RNG
imply DM_RTC
imply RTC_PL031
+ imply CMD_QFW
config ARCH_RMOBILE
bool "Renesas ARM SoCs"
diff --git a/arch/x86/cpu/qemu/cpu.c b/arch/x86/cpu/qemu/cpu.c
index 9ce86b379c..c78e374644 100644
--- a/arch/x86/cpu/qemu/cpu.c
+++ b/arch/x86/cpu/qemu/cpu.c
@@ -22,7 +22,14 @@ int cpu_qemu_get_desc(const struct udevice *dev, char *buf,
int size)
static int cpu_qemu_get_count(const struct udevice *dev)
{
- return qemu_fwcfg_online_cpus();
+ int ret;
+ struct udevice *qfw_dev;
+
+ ret = qfw_get_dev(_dev);
+ if (ret)
+ return ret;
+
+ return qemu_fwcfg_online_cpus(qfw_dev);
}
static const struct cpu_ops cpu_qemu_ops = {
diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
index 044a429c13..605f51e1b8 100644
--- a/arch/x86/cpu/qemu/qemu.c
+++ b/arch/x86/cpu/qemu/qemu.c
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -18,46 +19,10 @@ static bool i440fx;
#ifdef CONFIG_QFW
-/* on x86, the qfw registers are all IO ports */
-#define FW_CONTROL_PORT0x510
-#define FW_DATA_PORT 0x511
-#define FW_DMA_PORT_LOW0x514
-#define FW_DMA_PORT_HIGH 0x518
-
-static void qemu_x86_fwcfg_read_entry_pio(uint16_t entry,
- uint32_t size, void *address)
-{
- uint32_t i = 0;
- uint8_t *data = address;
-
- /*
-* writting FW_CFG_INVALID will cause read operation to resume at
-* last offset, otherwise read will start at offset 0
-*
-* Note: on platform where the control register is IO port, the
-* endianness is little endian.
-*/
- if (entry != FW_CFG_INVALID)
- outw(cpu_to_le16(entry), FW_CONTROL_PORT);
-
- /* the endianness of data register is string-preserving */
- while (size--)
- data[i++] = inb(FW_DATA_PORT);
-}
-
-static void qemu_x86_fwcfg_read_entry_dma(struct fw_cfg_dma_access *dma)
-{
- /* the DMA address register is big endian */
- outl(cpu_to_be32((uintptr_t)dma), FW_DMA_PORT_HIGH);
-
- while (be32_to_cpu(dma->control) & ~FW_CFG_DMA_ERROR)
- __asm__ __volatile__ ("pause");
-}
-
-static struct fw_cfg_arch_ops fwcfg_x86_ops = {
- .arch_read_pio = qemu_x86_fwcfg_read_entry_pio,
- .arch_read_dma = qemu_x86_fwcfg_read_entry_dma
+U_BOOT_DRVINFO(x86_qfw_pio) = {
+ .name = "qfw_pio",
};
+
#endif
static void enable_pm_piix(void)
@@ -132,10 +97,6 @@ static void qemu_chipset_init(void)
enable_pm_ich9();
}
-
-#ifdef CONFIG_QFW
- qemu_fwcfg_init(_x86_ops);
-#endif
}
#if !CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
diff --git a/arch/x86/cpu/qfw_cpu.c b/arch/x86/cpu/qfw_cpu.c
index b959eaddde..9700908064 100644
--- a/arch/x86/cpu/qfw_cpu.c
+++ b/arch/x86/cpu/qfw_cpu.c
@@ -18,7 +18,7 @@ int qemu_cpu_fixup(void)
int cpu_num;
int cpu_online;
struct uclass *uc;
- struct udevice *dev, *pdev;
+ struct udevice *dev, *pdev, *qfwdev;
struct cpu_plat *plat;
char *cpu;
@@ -39,6 +39,13 @@ int qemu_cpu_fixup(void)
return -ENODEV;
}
+ /* get qfw dev */
+ ret = qfw_get_dev();
+ if (ret) {
+ printf("unable to find qfw device\n");
+ return ret;
+ }
+
/* calculate cpus that are already bound */
cpu_num = 0;
for (uclass_find_first_device(UCLASS_CPU, );
@@ -48,7 +55,7 @@ int qemu_cpu_fixup(void)
}
/* get actual cpu number */
- cpu_online = qemu_fwcfg_online_cpus();
+ cpu_online = qemu_fwcfg_online_cpus(qfwdev);
[PATCH v4 3/5] qemu: add sandbox driver and tests
We minimally exercise the sandbox driver.
Signed-off-by: Asherah Connor
---
(no changes since v1)
arch/sandbox/dts/sandbox.dtsi | 4 ++
arch/sandbox/dts/test.dts | 4 ++
drivers/misc/Makefile | 1 +
drivers/misc/qfw_sandbox.c| 129 ++
test/dm/Makefile | 1 +
test/dm/qfw.c | 42 +++
6 files changed, 181 insertions(+)
create mode 100644 drivers/misc/qfw_sandbox.c
create mode 100644 test/dm/qfw.c
diff --git a/arch/sandbox/dts/sandbox.dtsi b/arch/sandbox/dts/sandbox.dtsi
index dc933f3bfc..7ce05b9662 100644
--- a/arch/sandbox/dts/sandbox.dtsi
+++ b/arch/sandbox/dts/sandbox.dtsi
@@ -390,6 +390,10 @@
sandbox_tee {
compatible = "sandbox,tee";
};
+
+ qfw {
+ compatible = "sandbox,qemu-fw-cfg-mmio";
+ };
};
_ec {
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index d4195b45bb..4b3f8831d5 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -112,6 +112,10 @@
compatible = "sandbox,dsi-host";
};
+ qfw {
+ compatible = "sandbox,qemu-fw-cfg-mmio";
+ };
+
a-test {
reg = <0 1>;
compatible = "denx,u-boot-fdt-test";
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index 2988289ea3..c48f61b797 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -59,6 +59,7 @@ ifdef CONFIG_QFW
obj-y += qfw.o
obj-$(CONFIG_X86) += qfw_pio.o
obj-$(CONFIG_ARM) += qfw_mmio.o
+obj-$(CONFIG_SANDBOX) += qfw_sandbox.o
endif
obj-$(CONFIG_ROCKCHIP_EFUSE) += rockchip-efuse.o
obj-$(CONFIG_ROCKCHIP_OTP) += rockchip-otp.o
diff --git a/drivers/misc/qfw_sandbox.c b/drivers/misc/qfw_sandbox.c
new file mode 100644
index 00..fc7006ae19
--- /dev/null
+++ b/drivers/misc/qfw_sandbox.c
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Sandbox interface for QFW
+ *
+ * (C) Copyright 2015 Miao Yan
+ * (C) Copyright 2021 Asherah Connor
+ */
+
+#define LOG_CATEGORY UCLASS_QFW
+
+#include
+#include
+#include
+#include
+#include
+
+struct qfw_sandbox_plat {
+ u8 file_dir_offset;
+};
+
+static void qfw_sandbox_read_entry_io(struct udevice *dev, u16 entry, u32 size,
+ void *address)
+{
+ debug("%s: entry 0x%x size %u address %p\n", __func__, entry, size,
+ address);
+
+ switch (entry) {
+ case FW_CFG_SIGNATURE:
+ if (size == 4)
+ *((u32 *)address) = cpu_to_be32(QEMU_FW_CFG_SIGNATURE);
+ break;
+ case FW_CFG_ID:
+ /* Advertise DMA support */
+ if (size == 1)
+ *((u8 *)address) = FW_CFG_DMA_ENABLED;
+ break;
+ default:
+ debug("%s got unsupported entry 0x%x\n", __func__, entry);
+ /*
+* Sandbox driver doesn't support other entries here, assume we use DMA
+* to read them -- the uclass driver will exclusively use it when
+* advertised.
+*/
+ }
+}
+
+static void qfw_sandbox_read_entry_dma(struct udevice *dev, struct qfw_dma
*dma)
+{
+ u16 entry;
+ u32 control = be32_to_cpu(dma->control);
+ void *address = (void *)be64_to_cpu(dma->address);
+ u32 length = be32_to_cpu(dma->length);
+ struct qfw_sandbox_plat *plat = dev_get_plat(dev);
+ struct fw_cfg_file *file;
+
+ debug("%s\n", __func__);
+
+ if (!(control & FW_CFG_DMA_READ))
+ return;
+
+ if (control & FW_CFG_DMA_SELECT) {
+ /* Start new read. */
+ entry = control >> 16;
+
+ /* Arbitrary values to be used by tests. */
+ switch (entry) {
+ case FW_CFG_NB_CPUS:
+ if (length == 2)
+ *((u16 *)address) = cpu_to_le16(5);
+ break;
+ case FW_CFG_FILE_DIR:
+ if (length == 4) {
+ *((u32 *)address) = cpu_to_be32(2);
+ plat->file_dir_offset = 1;
+ }
+ break;
+ default:
+ debug("%s got unsupported entry 0x%x\n", __func__,
+ entry);
+ }
+ } else if (plat->file_dir_offset && length == 64) {
+ file = address;
+ switch (plat->file_dir_offset) {
+ case 1:
+ file->size = cpu_to_be32(8);
+ file->select = cpu_to_be16(FW_CFG_FILE_FIRST);
+ strcpy(file->name, "test-one");
+ plat->file_dir_offset++;
+ break;
+ case 2:
+ file->size = cpu_to_be32(8);
+ file->select = cpu_to_be16(FW_CFG_FILE_FIRST + 1);
+
[PATCH v4 4/5] test: qemu: add simple test for cmd_qfw
Signed-off-by: Asherah Connor
---
(no changes since v1)
test/py/tests/test_qfw.py | 21 +
1 file changed, 21 insertions(+)
create mode 100644 test/py/tests/test_qfw.py
diff --git a/test/py/tests/test_qfw.py b/test/py/tests/test_qfw.py
new file mode 100644
index 00..a2631a0fa6
--- /dev/null
+++ b/test/py/tests/test_qfw.py
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0+
+# Copyright (c) 2021, Asherah Connor
+
+# Test qfw command implementation
+
+import pytest
+
+@pytest.mark.buildconfigspec('cmd_qfw')
+def test_qfw_cpus(u_boot_console):
+"Test QEMU firmware config reports the CPU count correctly."
+
+output = u_boot_console.run_command('qfw cpus')
+assert '1 cpu(s) online' in output
+
+@pytest.mark.buildconfigspec('cmd_qfw')
+def test_qfw_list(u_boot_console):
+"Test QEMU firmware config lists devices."
+
+output = u_boot_console.run_command('qfw list')
+assert 'bootorder' in output
+assert 'etc/table-loader' in output
--
2.20.1
[PATCH v4 2/5] arm: x86: qemu: unify qfw driver functions as qfw_
There's a mixture of "qemu_fwcfg_"-prefixed functions and
"qfw_"-prefixed ones. Now that the qfw name is applied in multiple
places (i.e. the uclass itself, and each of its drivers), let's
consistently use the prefix "qfw_" for anything relating to the
drivers.
Signed-off-by: Asherah Connor
---
(no changes since v1)
arch/x86/cpu/qemu/cpu.c | 2 +-
arch/x86/cpu/qfw_cpu.c | 2 +-
cmd/qfw.c | 10 +-
common/qfw.c| 14 +++---
drivers/misc/qfw.c | 20 ++--
include/qfw.h | 16
6 files changed, 32 insertions(+), 32 deletions(-)
diff --git a/arch/x86/cpu/qemu/cpu.c b/arch/x86/cpu/qemu/cpu.c
index c78e374644..735b656084 100644
--- a/arch/x86/cpu/qemu/cpu.c
+++ b/arch/x86/cpu/qemu/cpu.c
@@ -29,7 +29,7 @@ static int cpu_qemu_get_count(const struct udevice *dev)
if (ret)
return ret;
- return qemu_fwcfg_online_cpus(qfw_dev);
+ return qfw_online_cpus(qfw_dev);
}
static const struct cpu_ops cpu_qemu_ops = {
diff --git a/arch/x86/cpu/qfw_cpu.c b/arch/x86/cpu/qfw_cpu.c
index 9700908064..ee00b8fe73 100644
--- a/arch/x86/cpu/qfw_cpu.c
+++ b/arch/x86/cpu/qfw_cpu.c
@@ -55,7 +55,7 @@ int qemu_cpu_fixup(void)
}
/* get actual cpu number */
- cpu_online = qemu_fwcfg_online_cpus(qfwdev);
+ cpu_online = qfw_online_cpus(qfwdev);
if (cpu_online < 0) {
printf("unable to get online cpu number: %d\n", cpu_online);
return cpu_online;
diff --git a/cmd/qfw.c b/cmd/qfw.c
index 87af408a8d..e6a9fdb2af 100644
--- a/cmd/qfw.c
+++ b/cmd/qfw.c
@@ -82,13 +82,13 @@ static int qemu_fwcfg_cmd_list_firmware(void)
struct fw_file *file;
/* make sure fw_list is loaded */
- ret = qemu_fwcfg_read_firmware_list(qfw_dev);
+ ret = qfw_read_firmware_list(qfw_dev);
if (ret)
return ret;
- for (file = qemu_fwcfg_file_iter_init(qfw_dev, );
-!qemu_fwcfg_file_iter_end();
-file = qemu_fwcfg_file_iter_next()) {
+ for (file = qfw_file_iter_init(qfw_dev, );
+!qfw_file_iter_end();
+file = qfw_file_iter_next()) {
printf("%-56s\n", file->cfg.name);
}
@@ -107,7 +107,7 @@ static int qemu_fwcfg_do_list(struct cmd_tbl *cmdtp, int
flag,
static int qemu_fwcfg_do_cpus(struct cmd_tbl *cmdtp, int flag,
int argc, char *const argv[])
{
- printf("%d cpu(s) online\n", qemu_fwcfg_online_cpus(qfw_dev));
+ printf("%d cpu(s) online\n", qfw_online_cpus(qfw_dev));
return 0;
}
diff --git a/common/qfw.c b/common/qfw.c
index c0ffa20b74..561b0dd9c0 100644
--- a/common/qfw.c
+++ b/common/qfw.c
@@ -14,7 +14,7 @@ int qfw_get_dev(struct udevice **devp)
return uclass_first_device(UCLASS_QFW, devp);
}
-int qemu_fwcfg_online_cpus(struct udevice *dev)
+int qfw_online_cpus(struct udevice *dev)
{
u16 nb_cpus;
@@ -23,7 +23,7 @@ int qemu_fwcfg_online_cpus(struct udevice *dev)
return le16_to_cpu(nb_cpus);
}
-int qemu_fwcfg_read_firmware_list(struct udevice *dev)
+int qfw_read_firmware_list(struct udevice *dev)
{
int i;
u32 count;
@@ -64,7 +64,7 @@ err:
return -ENOMEM;
}
-struct fw_file *qemu_fwcfg_find_file(struct udevice *dev, const char *name)
+struct fw_file *qfw_find_file(struct udevice *dev, const char *name)
{
struct list_head *entry;
struct fw_file *file;
@@ -80,8 +80,8 @@ struct fw_file *qemu_fwcfg_find_file(struct udevice *dev,
const char *name)
return NULL;
}
-struct fw_file *qemu_fwcfg_file_iter_init(struct udevice *dev,
- struct fw_cfg_file_iter *iter)
+struct fw_file *qfw_file_iter_init(struct udevice *dev,
+ struct fw_cfg_file_iter *iter)
{
struct qfw_dev *qdev = dev_get_uclass_priv(dev);
@@ -91,14 +91,14 @@ struct fw_file *qemu_fwcfg_file_iter_init(struct udevice
*dev,
struct fw_file, list);
}
-struct fw_file *qemu_fwcfg_file_iter_next(struct fw_cfg_file_iter *iter)
+struct fw_file *qfw_file_iter_next(struct fw_cfg_file_iter *iter)
{
iter->entry = ((struct list_head *)iter->entry)->next;
return list_entry((struct list_head *)iter->entry,
struct fw_file, list);
}
-bool qemu_fwcfg_file_iter_end(struct fw_cfg_file_iter *iter)
+bool qfw_file_iter_end(struct fw_cfg_file_iter *iter)
{
return iter->entry == iter->end;
}
diff --git a/drivers/misc/qfw.c b/drivers/misc/qfw.c
index 7ad8f0979b..b0c82e2098 100644
--- a/drivers/misc/qfw.c
+++ b/drivers/misc/qfw.c
@@ -43,7 +43,7 @@ static int bios_linker_allocate(struct udevice *dev,
return -EINVAL;
}
- file = qemu_fwcfg_find_file(dev, entry->alloc.file);
+ file = qfw_find_file(dev, entry->alloc.file);
if (!file) {
printf("error: can't find
[PATCH v4 0/5] Move qfw to DM, add Arm support
This series moves the QFW driver into a uclass, UCLASS_QFW, and splits the driver into qfw_pio and qfw_mmio. A sandbox driver is also added, and a DM unit test against that driver. On x86 a U_BOOT_DRVINFO is used to configure the qfw_pio (with compiled- in constants used for PIO ports), otherwise we configure qfw_mmio from device tree if present. Version 4 of this series adds a test for the qfw command, exercising it on QEMU in test/py/tests/test_qfw.py. The introductory "move QFW to DM" commit has been rolled into the uclass split one. Documentation is added. To view the changes online, see: https://git.src.kameliya.ee/~kameliya/u-boot/log/qfw-priv Asherah Connor (5): arm: x86: qemu: move qfw to DM uclass, add Arm support arm: x86: qemu: unify qfw driver functions as qfw_ qemu: add sandbox driver and tests test: qemu: add simple test for cmd_qfw qemu: add documentation to qfw.h arch/arm/Kconfig | 1 + arch/sandbox/dts/sandbox.dtsi | 4 + arch/sandbox/dts/test.dts | 4 + arch/x86/cpu/qemu/cpu.c | 9 +- arch/x86/cpu/qemu/qemu.c | 47 +-- arch/x86/cpu/qfw_cpu.c| 11 +- cmd/qfw.c | 56 common/Makefile | 2 + common/qfw.c | 105 +++ drivers/misc/Makefile | 7 +- drivers/misc/qfw.c| 242 -- drivers/misc/qfw_mmio.c | 119 + drivers/misc/qfw_pio.c| 69 ++ drivers/misc/qfw_sandbox.c| 129 ++ include/dm/uclass-id.h| 1 + include/qfw.h | 145 test/dm/Makefile | 1 + test/dm/qfw.c | 42 ++ test/py/tests/test_qfw.py | 21 +++ 19 files changed, 752 insertions(+), 263 deletions(-) create mode 100644 common/qfw.c create mode 100644 drivers/misc/qfw_mmio.c create mode 100644 drivers/misc/qfw_pio.c create mode 100644 drivers/misc/qfw_sandbox.c create mode 100644 test/dm/qfw.c create mode 100644 test/py/tests/test_qfw.py -- 2.20.1
RE: [PATCH] Makefile: Add target to generate hex output for combined spl and dtb
Hi Tom,
> -Original Message-
> From: Tom Rini
> Sent: Wednesday, February 24, 2021 12:29 AM
> To: Lim, Elly Siew Chin
> Cc: u-boot@lists.denx.de; Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ; Simon
> Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan, Yau
> Wai
> Subject: Re: [PATCH] Makefile: Add target to generate hex output for combined
> spl and dtb
>
> On Tue, Feb 23, 2021 at 07:00:47AM +, Lim, Elly Siew Chin wrote:
> > Hi Tom,
> >
> > > -Original Message-
> > > From: Tom Rini
> > > Sent: Saturday, February 20, 2021 5:02 AM
> > > To: Lim, Elly Siew Chin
> > > Cc: u-boot@lists.denx.de; Marek Vasut ; Tan, Ley Foon
> > > ; See, Chin Liang
> > > ; Simon Goldschmidt
> > > ; Chee, Tien Fong
> > > ; Westergreen, Dalon
> > > ; Simon Glass ; Gan,
> > > Yau Wai
> > > Subject: Re: [PATCH] Makefile: Add target to generate hex output for
> > > combined spl and dtb
> > >
> > > On Fri, Feb 19, 2021 at 01:55:44PM +0800, Siew Chin Lim wrote:
> > >
> > > > From: Dalon Westergreen
> > > >
> > > > Some architectures, Stratix10/Agilex, require a hex formatted spl
> > > > that combines the spl image and dtb. This adds a target to create
> > > > said hex file with and offset of SPL_TEXT_BASE.
> > > >
> > > > Signed-off-by: Dalon Westergreen
> > > > Signed-off-by: Siew Chin Lim
> > > > ---
> > > > Makefile | 11 ++-
> > > > include/configs/socfpga_soc64_common.h | 2 +-
> > > > scripts/Makefile.spl | 8
> > > > 3 files changed, 15 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/Makefile b/Makefile
> > > > index 4da46dea39..f1adc9aa23 100644
> > > > --- a/Makefile
> > > > +++ b/Makefile
> > > > @@ -1263,11 +1263,6 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary
> \
> > > > $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec)
> > > > \
> > > > $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -
> > > R .resetvec)
> > > >
> > > > -OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-boot.hex)
> > > > -
> > > > -spl/u-boot-spl.hex: spl/u-boot-spl FORCE
> > > > - $(call if_changed,objcopy)
> > > > -
> > > > binary_size_check: u-boot-nodtb.bin FORCE
> > > > @file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}')
> > > > ; \
> > > > map_size=$(shell cat u-boot.map | \ @@ -1935,6 +1930,12 @@
> > > > spl/u-boot-spl.bin: spl/u-boot-spl
> > > > @:
> > > > $(SPL_SIZE_CHECK)
> > > >
> > > > +spl/u-boot-spl-dtb.bin: spl/u-boot-spl
> > > > + @:
> > > > +
> > > > +spl/u-boot-spl-dtb.hex: spl/u-boot-spl
> > > > + @:
> > > > +
> > > > spl/u-boot-spl: tools prepare \
> > > > $(if
> > >
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA
> > > ),dts/dt.dtb) \
> > > > $(if
> > > >
> > >
> $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA
> > > ),dts/d
> > > > t.dtb) diff --git a/include/configs/socfpga_soc64_common.h
> > > > b/include/configs/socfpga_soc64_common.h
> > > > index fdcd7d3e9a..1af359466c 100644
> > > > --- a/include/configs/socfpga_soc64_common.h
> > > > +++ b/include/configs/socfpga_soc64_common.h
> > > > @@ -200,7 +200,7 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
> > > > * 0x8000_ .. End of SDRAM_1 (assume 2GB)
> > > > *
> > > > */
> > > > -#define CONFIG_SPL_TARGET "spl/u-boot-spl.hex"
> > > > +#define CONFIG_SPL_TARGET "spl/u-boot-spl-dtb.hex"
> > > > #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE
> > > > #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
> > > > #define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1
> MB */
> > > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index
> > > > ea4e045769..625e06d0d9 100644
> > > > --- a/scripts/Makefile.spl
> > > > +++ b/scripts/Makefile.spl
> > > > @@ -229,6 +229,9 @@ ifneq
> > >
> ($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),)
> > > > INPUTS-y += $(obj)/$(SPL_BIN).sfp
> > > > endif
> > > >
> > > > +INPUTS-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/u-
> boot-spl-
> > > dtb.hex
> > > > +INPUTS-$(CONFIG_TARGET_SOCFPGA_AGILEX) += $(obj)/u-
> > > boot-spl-dtb.hex
> > > > +
> > > > ifdef CONFIG_ARCH_SUNXI
> > > > INPUTS-y += $(obj)/sunxi-spl.bin
> > > >
> > > > @@ -389,6 +392,11 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin
> > > > FORCE MKIMAGEFLAGS_sunxi-spl.bin = -T sunxi_egon \
> > > > -n $(CONFIG_DEFAULT_DEVICE_TREE)
> > > >
> > > > +OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex
> > > > +--change-address=$(CONFIG_SPL_TEXT_BASE)
> > > > +
> > > > +$(obj)/u-boot-spl-dtb.hex: $(obj)/u-boot-spl-dtb.bin FORCE
> > > > + $(call if_changed,objcopy)
> > > > +
> > > > $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
> > > > $(call if_changed,mkimage)
> > >
> > > The commit message / subject doesn't make it clear that
Re: [GIT PULL] xilinx patches for v2021.04-rc3
On Tue, Feb 23, 2021 at 04:31:16PM +0100, Michal Simek wrote: > Hi Tom, > > please pull these changes to your tree. The major part were clock issues > we found for ZynqMP and Versal in some PM cases where u-boot didn't ask > for enabling clocks. And that's why drivers are shared we also had to > add clock enable function for Zynq to pass. > There are some other fixes especially ZynqMP one for DTB selection. > > I can't see any issue from gitlab CI. > > Thanks, > Michal > > > The following changes since commit fdcb93e1709ab1a2ebb562455621617c29e2099c: > > Merge branch '2021-02-01-assorted-fixes' (2021-02-02 09:24:10 -0500) > > are available in the Git repository at: > > g...@gitlab.denx.de:u-boot/custodians/u-boot-microblaze.git > tags/xilinx-for-v2021.04-rc3 > > for you to fetch changes up to d9aa19efa8a6c20d51b7884de0a7f8dae3f835d2: > > spi: zynqmp_gqspi: fix set_speed bug on multiple runs (2021-02-23 > 14:56:59 +0100) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[v2] Makefile: socfpga: Add target to generate hex output for combined spl and dtb
From: Dalon Westergreen
Add target to Makefile to generate "u-boot-spl-dtb.hex" for Intel SOCFPGA
SOC64 devices (Stratix 10 and Agilex). "u-boot-spl-dtb.hex" is hex formatted
spl with and offset of CONFIG_SPL_TEXT_BASE. It combines the spl image and dtb.
"u-boot-spl-dtb.hex" is needed to generate the final configuration bitstream
for Intel SOCFPGA SOC64 devices.
Signed-off-by: Dalon Westergreen
Signed-off-by: Siew Chin Lim
---
v2: Update commit message
---
---
Makefile | 11 ++-
include/configs/socfpga_soc64_common.h | 2 +-
scripts/Makefile.spl | 8
3 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/Makefile b/Makefile
index 4da46dea39..f1adc9aa23 100644
--- a/Makefile
+++ b/Makefile
@@ -1263,11 +1263,6 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
$(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
$(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -R
.resetvec)
-OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-boot.hex)
-
-spl/u-boot-spl.hex: spl/u-boot-spl FORCE
- $(call if_changed,objcopy)
-
binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
map_size=$(shell cat u-boot.map | \
@@ -1935,6 +1930,12 @@ spl/u-boot-spl.bin: spl/u-boot-spl
@:
$(SPL_SIZE_CHECK)
+spl/u-boot-spl-dtb.bin: spl/u-boot-spl
+ @:
+
+spl/u-boot-spl-dtb.hex: spl/u-boot-spl
+ @:
+
spl/u-boot-spl: tools prepare \
$(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb) \
$(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
diff --git a/include/configs/socfpga_soc64_common.h
b/include/configs/socfpga_soc64_common.h
index fdcd7d3e9a..1af359466c 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -200,7 +200,7 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
* 0x8000_ .. End of SDRAM_1 (assume 2GB)
*
*/
-#define CONFIG_SPL_TARGET "spl/u-boot-spl.hex"
+#define CONFIG_SPL_TARGET "spl/u-boot-spl-dtb.hex"
#define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE
#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
#define CONFIG_SPL_BSS_MAX_SIZE0x10/* 1 MB */
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ea4e045769..625e06d0d9 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -229,6 +229,9 @@ ifneq
($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),)
INPUTS-y += $(obj)/$(SPL_BIN).sfp
endif
+INPUTS-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/u-boot-spl-dtb.hex
+INPUTS-$(CONFIG_TARGET_SOCFPGA_AGILEX) += $(obj)/u-boot-spl-dtb.hex
+
ifdef CONFIG_ARCH_SUNXI
INPUTS-y += $(obj)/sunxi-spl.bin
@@ -389,6 +392,11 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
MKIMAGEFLAGS_sunxi-spl.bin = -T sunxi_egon \
-n $(CONFIG_DEFAULT_DEVICE_TREE)
+OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex
--change-address=$(CONFIG_SPL_TEXT_BASE)
+
+$(obj)/u-boot-spl-dtb.hex: $(obj)/u-boot-spl-dtb.bin FORCE
+ $(call if_changed,objcopy)
+
$(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mkimage)
--
2.13.0
Re: rk3399-gru-kevin: issues on bringup
On Tue, Feb 23, 2021 at 10:10:11AM -0500, Simon Glass wrote: > Hi Marty, > > On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak > wrote: > > > > Hi Simon, Marty, > > > > I'm interested in getting U-Boot to work with Kevin as well, but don't > > have a Servo (or the willingness to open up the case yet), so I've been > > trying to boot from depthcharge as in README.chromium-chainload. > > > > I don't have a way to see serial output and I see no other signs of > > life. Can you give me a tested configuration that immediately powers-off > > or reboots a Kevin so I can confirm what I'm doing works on the > > chainloading side? I mean I can boot Linux, but trying the same with > > U-Boot just gives me a blank screen even after accounting for a lot of > > things. > > > > Meanwhile, I've wrote some code to automate making depthcharge partition > > images, and to enable the display on Kevin (and perhaps Bob). Since I > > don't know if chainloading works, I don't know if these are broken or > > not either. I'm unsure about sending untested patches to the list, so I > > put them up here if you want to take a look (and maybe test/fix them?): > > > > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip > > > > They're not really things that'd make a non-booting Kevin boot, though. > > I hope at least some of it can be useful in some way. > > I am just replying here as you asked for some details on IRC. What > details do you need? > Well, if its possible to actually do openocd/etc on the AP using a servo, I'd like to know how. All the documentation I could find is about using openocd to flash the EC, not debug the AP. > I was intending to try out a kevin if I have one. I will add that to my list. > > Regards, > Simon
[PATCH] Nokia RX-51: Enable CONFIG_CMD_BOOTD
CONFIG_CMD_BOOTD provides 'boot' command which is required in more scripts. Signed-off-by: Pali Rohár --- This patch applies cleanly on top of the patch "Nokia RX-51: Enable usbtty serial console by default" [1] and CI testing passed without any issues [2] [3]. Please include it into U-Boot 2021.04 release. [1] - https://patchwork.ozlabs.org/project/uboot/patch/20210220105015.26210-1-p...@kernel.org/ [2] - https://github.com/u-boot/u-boot/pull/53/checks?check_run_id=1932112532 [3] - https://dev.azure.com/u-boot/a1096300-2999-4ec4-a21a-4c22075e3771/_build/results?buildId=1816=logs=9a06d2a9-1498-5de0-2a01-be581d48ba67 --- configs/nokia_rx51_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/nokia_rx51_defconfig b/configs/nokia_rx51_defconfig index 0df11b98585b..312ca3a1a991 100644 --- a/configs/nokia_rx51_defconfig +++ b/configs/nokia_rx51_defconfig @@ -17,7 +17,6 @@ CONFIG_CONSOLE_MUX=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="Nokia RX-51 # " # CONFIG_CMD_BDI is not set -# CONFIG_CMD_BOOTD is not set # CONFIG_BOOTM_NETBSD is not set # CONFIG_BOOTM_PLAN9 is not set # CONFIG_BOOTM_RTEMS is not set -- 2.20.1
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On 21/02/23 01:02:p, Heinrich Schuchardt wrote: > On 23.02.21 12:43, Asherah Connor wrote: > For which architectures does the fw_cfg device exist? > > It it is only ARM and X86, than I am missing such a dependency on > CONFIG_CMD_QFW. Right now we have: arch/arm/Kconfig: ... config ARCH_QEMU ... imply CMD_QFW I think we also want this: arch/x86/cpu/qemu/Kconfig config QEMU ... imply CMD_QFW This is my first time using Kconfig and I'll admit I'm not too certain where things go. > If these numbers are constants, why should they be copied to platform > data? This only increases code size. > > I think there is nothing wrong with using constants here. Okay, excellent. I'll fold those into drivers/misc/qfw_pio.c and get rid of the qfw_pio_plat struct entirely. > ARM yield is meant to be used on multi-threaded systems to indicate that > the thread can be swapped. Why would we need it in U-Boot which is > single-threaded? > > Can't we simply use > > while (be32_to_cpu(dma.control) & ~FW_CFG_DMA_ERROR); > > with no command in the loop for all architectures? Good question. This code originated here, where the original (x86-only) driver used pause: https://gitlab.denx.de/u-boot/u-boot/-/commit/f60df20aa966c3de850afafe3cce70a51d0b261c#41c93c056084377352da52f1d88fc49288a4846f_0_59 When porting to Arm I used the equivalent. While U-Boot is single-threaded, the architecture that executes this instruction is always QEMU, and -- at a guess -- it might be that pause/yield here lets QEMU finish its part of the DMA faster. I've run the QEMU tests on arm(64)/x86(_64) without the yield or pause and they still pass. It might be simply unnecessary, so I'll remove for now in favour of simplicity and less arch-specific code. Best, Asherah
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On 21/02/23 06:02:p, Tom Rini wrote: > Ah well, so my experiment would likely have not worked back then anyhow > (but I don't recall seeing an error at the time). Anyhow, for now in > U-Boot as there's not a generic QEMU symbol, this side of things should > depend on ARM||X86 for now and let future enhancements add it elsewhere. > Thanks! I think this is a fine way to do it. If users come forward wanting to use it on other archs we can rethink it, but as long as there are only two it seems not yet worth making fully generic. Best, Asherah
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On Tue, Feb 23, 2021 at 11:54:01PM +, Asherah Connor wrote: > On 21/02/23 11:02:p, Tom Rini wrote: > > On Tue, Feb 23, 2021 at 05:15:49PM +0100, Heinrich Schuchardt wrote: > > > On 2/23/21 5:03 PM, Tom Rini wrote: > > > > On Tue, Feb 23, 2021 at 04:54:45PM +0100, Heinrich Schuchardt wrote: > > > > > qemu-system-riscv64 does not allow me to specify a file for the qfw > > > > > interface. > > > > > > > > Really? It's listed under the help (taken from out docker images): > > > > $ /opt/qemu/bin/qemu-system-riscv64 --help > > > > ... > > > > Debug/Expert options: > > > > -fw_cfg [name=],file= > > > > add named fw_cfg entry with contents from file > > > > -fw_cfg [name=],string= > > > > add named fw_cfg entry with contents from string > > > > > > > > > > The man-page is shared by all qemu-system-*. It is not architecture > > > specific. That is why it shows items like: "PS/2 mouse and keyboard". > > > > > > qemu-system-riscv64 (v5.0.0) has no fw_cfg device: > > > > > > $ qemu-system-riscv64 -machine virt -m 1G -nographic -bios u-boot > > > -fw_cfg opt/foo,file=foo > > > qemu-system-riscv64: -fw_cfg opt/foo,file=foo: fw_cfg device not available > > > > > > qemu-system-aarch64 does not complain: > > > > > > $ qemu-system-aarch64 -machine virt -m 1G -nographic -bios u-boot > > > -fw_cfg opt/foo,file=foo > > > > So all that's missing is someone hooking that up inside qemu itself. > > I'm pretty sure it works on PowerPC, from when I was trying to figure > > out how to pass something in to qemu-ppce500 a while ago. > > qemu-system-mips/sh4 don't complain. > > A review of the various FW_CFG_ Kconfig options in QEMU itself suggests > there is support on at least i386, arm, ppc, and mips (their arch > terms). Looking further, it appears sparc(64) and hppa (HP PA-RISC) are > also supported in the source base. > > But actually trying it, it looks like a freshly built QEMU 5.2.0 does > not support qfw on ppce500: > > $ qemu-system-ppc -M ppce500 -nographic -bios \ > build-qemu-ppce500/u-boot -fw_cfg xyz,string=hello > qemu-system-ppc: -fw_cfg xyz,string=hello: fw_cfg device not available > > Same for mips(64)(el). Maybe I missed a configuration option somewhere. > The sparc systems work fine. Ah well, so my experiment would likely have not worked back then anyhow (but I don't recall seeing an error at the time). Anyhow, for now in U-Boot as there's not a generic QEMU symbol, this side of things should depend on ARM||X86 for now and let future enhancements add it elsewhere. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On 21/02/23 11:02:p, Tom Rini wrote: > On Tue, Feb 23, 2021 at 05:15:49PM +0100, Heinrich Schuchardt wrote: > > On 2/23/21 5:03 PM, Tom Rini wrote: > > > On Tue, Feb 23, 2021 at 04:54:45PM +0100, Heinrich Schuchardt wrote: > > > > qemu-system-riscv64 does not allow me to specify a file for the qfw > > > > interface. > > > > > > Really? It's listed under the help (taken from out docker images): > > > $ /opt/qemu/bin/qemu-system-riscv64 --help > > > ... > > > Debug/Expert options: > > > -fw_cfg [name=],file= > > > add named fw_cfg entry with contents from file > > > -fw_cfg [name=],string= > > > add named fw_cfg entry with contents from string > > > > > > > The man-page is shared by all qemu-system-*. It is not architecture > > specific. That is why it shows items like: "PS/2 mouse and keyboard". > > > > qemu-system-riscv64 (v5.0.0) has no fw_cfg device: > > > > $ qemu-system-riscv64 -machine virt -m 1G -nographic -bios u-boot > > -fw_cfg opt/foo,file=foo > > qemu-system-riscv64: -fw_cfg opt/foo,file=foo: fw_cfg device not available > > > > qemu-system-aarch64 does not complain: > > > > $ qemu-system-aarch64 -machine virt -m 1G -nographic -bios u-boot > > -fw_cfg opt/foo,file=foo > > So all that's missing is someone hooking that up inside qemu itself. > I'm pretty sure it works on PowerPC, from when I was trying to figure > out how to pass something in to qemu-ppce500 a while ago. > qemu-system-mips/sh4 don't complain. A review of the various FW_CFG_ Kconfig options in QEMU itself suggests there is support on at least i386, arm, ppc, and mips (their arch terms). Looking further, it appears sparc(64) and hppa (HP PA-RISC) are also supported in the source base. But actually trying it, it looks like a freshly built QEMU 5.2.0 does not support qfw on ppce500: $ qemu-system-ppc -M ppce500 -nographic -bios \ build-qemu-ppce500/u-boot -fw_cfg xyz,string=hello qemu-system-ppc: -fw_cfg xyz,string=hello: fw_cfg device not available Same for mips(64)(el). Maybe I missed a configuration option somewhere. The sparc systems work fine. Best, Asherah
Re: Broken build on OpenBSD
On 2/23/21 3:18 PM, Simon Glass wrote: Hi Alex, On Tue, 23 Feb 2021 at 14:48, Alex G. wrote: On 2/23/21 1:07 PM, Mark Kettenis wrote: Hi Simon, Commit c5819701a3de61e2ba2ef7ad0b616565b32305e5 broke the build on OpenBSD and probably other non-Linux systems. ENODATA, which is now used in fit_check_format(), isn't defined. It isn't part of POSIX[1] and generally not available on BSD-derived systems. Could you pick another error code for this case? Hi Mark, I looked at the commit you mentioned, and I think it's fundamentally broken. The errors represent -EINVAL, and trying to assign different error codes doesn't make sense. "Wrong FIT format: no images parent node": -ENOENT "No such file or directory". This just doesn't make sense. We obviously have the file data at this point, and we know the data is wrong. This should be -EINVAL. "Wrong FIT format: no description": -ENOMSG "No message of desired type". Again, this doesn't make sense. We're not dealing with messaging APIs or send()/recv(). I think this should be -EINVAL. "Wrong FIT format: not a flattened device tree": -ENOEXEC "Exec format error" This one is amusing, as it's comparing a flattened devicetree to an executable. An FDT might have executable code, which is in the wrong format, but this is not why we're failing here. Simon, I'd suggest using the correct error code, which, for each case is -EINVAL, as the log messages also confirm: "Wrong [input value] format". We might have issues with the "configurations", an "@" in a signature name, and so forth. There just aren't enough error codes to cover the set of possible failures. And in any case, there likely can't be a reasonable 1:1 mapping to _distinct_ errno codes. Does any user even check the error code beyond "less than zero"? Take different decisions based on what the negative code indicates? If information as to what is wrong with the input value (FIT) is needed, then I'd suggest using a separate enum, and stick to -EINVAL. Actually I make an effort to use different codes where possible, so there is some indication what went wrong. Of course devs can whip out the JTAG debugger or start filling the code with printf()s but normal users cannot, so having an idea what is wrong is helpful. We don't have to cover every case, but years ago U-Boot used to return -1 for lots of failures and it was certainly frustrating to debug things. I agree with most of these arguments. And I agree with using errno codes to represent errno codes. However, when we deviate from the agreed upon convention, can we still apply the said convention? Each function acquires its own set of rules. And when each function has its own set of rules, the source code is needed to derive the meaning. You make the argument that these codes give normal users an idea of what is wrong. I assume that normal users respond better to human-readable strings than to negative integers -- for which they would have to go to he source code anyway to decipher the meaning. Because, in order to be useful, error codes require the, they cannot be useful for normal users. I believe this rebukes your central point around the unconventional use of errno codes. So then the question is how to cover error cases without returning '-1', and without making things a nightmare to debug. If you need to tell the user that there are "no images parent node", then tell the user -ENOFDTIMAGESNODE, or FIT_ERROR_NO_IMAGES_NODE. How can someone know that -ENOENT really comes from fit_check_format() instead of the FAT code, and really means "FIT has no images node" instead of "there is no FIT file"? I guess we could bust out the old JTAG to check. BTW -EINVAL is mostly reserved for of_to_plat() failure in U-Boot. It indicates something is wrong with your devicetree data for a device. Reserving -EINVAL for a special class of input value errors, but not others is breaking convention, so all my arguments above apply. Alex
Re: Broken build on OpenBSD
On Tue, Feb 23, 2021 at 04:19:35PM -0500, Simon Glass wrote: > +Tom Rini > > Hi Mark, > > On Tue, 23 Feb 2021 at 14:07, Mark Kettenis wrote: > > > > Hi Simon, > > > > Commit c5819701a3de61e2ba2ef7ad0b616565b32305e5 broke the build on > > OpenBSD and probably other non-Linux systems. ENODATA, which is now > > used in fit_check_format(), isn't defined. It isn't part of POSIX[1] > > and generally not available on BSD-derived systems. Could you pick > > another error code for this case? > > OK. I think this was reported already, but will take a look. Yeah, I think the suggestion was to use EBADMSG instead? I was hoping for a patch. > Are we able to get this into the CI system so there is a test for it? I think it wasn't easy, or at least wasn't free, to enable a BSD host system in Azure. But if someone wants to donate a BSD host that we can plug in to GitLab for running a subset of builds on (I was thinking sandbox+pytest and host-tools perhaps) it would be greatly appreciated. -- Tom signature.asc Description: PGP signature
Re: Broken build on OpenBSD
+Tom Rini Hi Mark, On Tue, 23 Feb 2021 at 14:07, Mark Kettenis wrote: > > Hi Simon, > > Commit c5819701a3de61e2ba2ef7ad0b616565b32305e5 broke the build on > OpenBSD and probably other non-Linux systems. ENODATA, which is now > used in fit_check_format(), isn't defined. It isn't part of POSIX[1] > and generally not available on BSD-derived systems. Could you pick > another error code for this case? OK. I think this was reported already, but will take a look. Are we able to get this into the CI system so there is a test for it? Regards, Simon
Re: Broken build on OpenBSD
Hi Alex, On Tue, 23 Feb 2021 at 14:48, Alex G. wrote: > > On 2/23/21 1:07 PM, Mark Kettenis wrote: > > Hi Simon, > > > > Commit c5819701a3de61e2ba2ef7ad0b616565b32305e5 broke the build on > > OpenBSD and probably other non-Linux systems. ENODATA, which is now > > used in fit_check_format(), isn't defined. It isn't part of POSIX[1] > > and generally not available on BSD-derived systems. Could you pick > > another error code for this case? > > Hi Mark, > > I looked at the commit you mentioned, and I think it's fundamentally > broken. The errors represent -EINVAL, and trying to assign different > error codes doesn't make sense. > > "Wrong FIT format: no images parent node": > -ENOENT "No such file or directory". > This just doesn't make sense. We obviously have the file data at this > point, and we know the data is wrong. This should be -EINVAL. > > "Wrong FIT format: no description": > -ENOMSG "No message of desired type". > Again, this doesn't make sense. We're not dealing with messaging APIs or > send()/recv(). I think this should be -EINVAL. > > "Wrong FIT format: not a flattened device tree": > -ENOEXEC "Exec format error" > This one is amusing, as it's comparing a flattened devicetree to an > executable. An FDT might have executable code, which is in the wrong > format, but this is not why we're failing here. > > Simon, > I'd suggest using the correct error code, which, for each case is > -EINVAL, as the log messages also confirm: "Wrong [input value] format". > We might have issues with the "configurations", an "@" in a signature > name, and so forth. There just aren't enough error codes to cover the > set of possible failures. And in any case, there likely can't be a > reasonable 1:1 mapping to _distinct_ errno codes. > > Does any user even check the error code beyond "less than zero"? Take > different decisions based on what the negative code indicates? If > information as to what is wrong with the input value (FIT) is needed, > then I'd suggest using a separate enum, and stick to -EINVAL. Actually I make an effort to use different codes where possible, so there is some indication what went wrong. Of course devs can whip out the JTAG debugger or start filling the code with printf()s but normal users cannot, so having an idea what is wrong is helpful. We don't have to cover every case, but years ago U-Boot used to return -1 for lots of failures and it was certainly frustrating to debug things. BTW -EINVAL is mostly reserved for of_to_plat() failure in U-Boot. It indicates something is wrong with your devicetree data for a device. Regards, Simon
[PATCH 19/19] video: sunxi: de2: switch clock setup to DM model
Now that proper DM clock and reset driver exists for Display Engine 2
and 3, remove all clock and reset related code and use appropriate
framework instead.
Signed-off-by: Jernej Skrabec
---
arch/arm/mach-sunxi/Kconfig | 1 +
drivers/video/sunxi/sunxi_de2.c | 67 +++--
2 files changed, 23 insertions(+), 45 deletions(-)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 9149196b223e..34ef1f4b030f 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -970,6 +970,7 @@ config SUNXI_DE2
config VIDEO_DE2
bool "Display Engine 2 video driver"
depends on SUNXI_DE2
+ select CLK_SUN8I_DE2
select DM_VIDEO
select DISPLAY
select VIDEO_DW_HDMI
diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index f6c8ca075aba..cee9b46b1259 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -6,6 +6,7 @@
*/
#include
+#include
#include
#include
#include
@@ -14,10 +15,10 @@
#include
#include
#include
+#include
#include
#include
#include
-#include
#include
#include
#include "simplefb_common.h"
@@ -36,40 +37,10 @@ struct sunxi_de2_data {
const char *disp_drv_name;
};
-static void sunxi_de2_composer_init(void)
-{
- struct sunxi_ccm_reg * const ccm =
- (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-
-#ifdef CONFIG_MACH_SUN50I
- u32 reg_value;
-
- /* set SRAM for video use (A64 only) */
- reg_value = readl(SUNXI_SRAMC_BASE + 0x04);
- reg_value &= ~(0x01 << 24);
- writel(reg_value, SUNXI_SRAMC_BASE + 0x04);
-#endif
-
- clock_set_pll10(43200);
-
- /* Set DE parent to pll10 */
- clrsetbits_le32(>de_clk_cfg, CCM_DE2_CTRL_PLL_MASK,
- CCM_DE2_CTRL_PLL10);
-
- /* Set ahb gating to pass */
- setbits_le32(>ahb_reset1_cfg, 1 << AHB_RESET_OFFSET_DE);
- setbits_le32(>ahb_gate1, 1 << AHB_GATE_OFFSET_DE);
-
- /* Clock on */
- setbits_le32(>de_clk_cfg, CCM_DE2_CTRL_GATE);
-}
-
-static void sunxi_de2_mode_set(ulong de_mux_base, int mux,
+static void sunxi_de2_mode_set(ulong de_mux_base,
const struct display_timing *mode,
int bpp, ulong address, bool is_composite)
{
- struct de_clk * const de_clk_regs =
- (struct de_clk *)(SUNXI_DE2_BASE);
struct de_glb * const de_glb_regs =
(struct de_glb *)(de_mux_base +
SUNXI_DE2_MUX_GLB_REGS);
@@ -87,17 +58,6 @@ static void sunxi_de2_mode_set(ulong de_mux_base, int mux,
int channel;
u32 format;
- /* enable clock */
-#ifdef CONFIG_MACH_SUN8I_H3
- setbits_le32(_clk_regs->rst_cfg, (mux == 0) ? 1 : 4);
-#else
- setbits_le32(_clk_regs->rst_cfg, BIT(mux));
-#endif
- setbits_le32(_clk_regs->gate_cfg, BIT(mux));
- setbits_le32(_clk_regs->bus_cfg, BIT(mux));
-
- clrbits_le32(_clk_regs->sel_cfg, 1);
-
writel(SUNXI_DE2_MUX_GLB_CTL_EN, _glb_regs->ctl);
writel(0, _glb_regs->status);
writel(1, _glb_regs->dbuff);
@@ -189,6 +149,8 @@ static int sunxi_de2_init(struct udevice *dev, ulong fbbase,
struct video_priv *uc_priv = dev_get_uclass_priv(dev);
struct display_timing timing;
struct display_plat *disp_uc_plat;
+ struct reset_ctl_bulk resets;
+ struct clk_bulk clocks;
int ret;
disp_uc_plat = dev_get_uclass_plat(disp);
@@ -206,8 +168,23 @@ static int sunxi_de2_init(struct udevice *dev, ulong
fbbase,
return ret;
}
- sunxi_de2_composer_init();
- sunxi_de2_mode_set((ulong)dev_read_addr(dev), mux, ,
+ ret = reset_get_bulk(dev, );
+ if (ret)
+ return ret;
+
+ ret = clk_get_bulk(dev, );
+ if (ret)
+ return ret;
+
+ ret = clk_enable_bulk();
+ if (ret)
+ return ret;
+
+ ret = reset_deassert_bulk();
+ if (ret)
+ return ret;
+
+ sunxi_de2_mode_set((ulong)dev_read_addr(dev), ,
1 << l2bpp, fbbase, is_composite);
ret = display_enable(disp, 1 << l2bpp, );
--
2.30.1
[PATCH 18/19] clk: sunxi: add DE2 clock driver
Video driver currently manages clocks and resets by directly writing to
registers. This is already a bit messy because each SoC has some
specifics. It's much better to implement proper clock and reset driver
which takes information from device tree file.
Note that this driver is not perfect yet. It still sets PLL and parent
by hand. Sunxi clock framework still doesn't know how to set parents or
rates. However, this is already big step in right direction.
Cc: Lukasz Majewski
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi/Kconfig | 5 +++
drivers/clk/sunxi/Makefile | 1 +
drivers/clk/sunxi/clk_de2.c | 85 +
3 files changed, 91 insertions(+)
create mode 100644 drivers/clk/sunxi/clk_de2.c
diff --git a/drivers/clk/sunxi/Kconfig b/drivers/clk/sunxi/Kconfig
index bf084fa7a84a..6c96affb1f87 100644
--- a/drivers/clk/sunxi/Kconfig
+++ b/drivers/clk/sunxi/Kconfig
@@ -44,6 +44,11 @@ config CLK_SUN8I_A83T
This enables common clock driver support for platforms based
on Allwinner A83T SoC.
+config CLK_SUN8I_DE2
+ bool "Clock driver for Allwinner Display Engine 2 and 3"
+ help
+ This enables common clock driver support for Display Engine 2 and 3.
+
config CLK_SUN8I_R40
bool "Clock driver for Allwinner R40"
default MACH_SUN8I_R40
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 0dfc0593fb1c..620ff96ac6f5 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_CLK_SUN5I_A10S) += clk_a10s.o
obj-$(CONFIG_CLK_SUN6I_A31) += clk_a31.o
obj-$(CONFIG_CLK_SUN8I_A23) += clk_a23.o
obj-$(CONFIG_CLK_SUN8I_A83T) += clk_a83t.o
+obj-$(CONFIG_CLK_SUN8I_DE2) += clk_de2.o
obj-$(CONFIG_CLK_SUN8I_R40) += clk_r40.o
obj-$(CONFIG_CLK_SUN8I_V3S) += clk_v3s.o
obj-$(CONFIG_CLK_SUN9I_A80) += clk_a80.o
diff --git a/drivers/clk/sunxi/clk_de2.c b/drivers/clk/sunxi/clk_de2.c
new file mode 100644
index ..b8c45404c1b6
--- /dev/null
+++ b/drivers/clk/sunxi/clk_de2.c
@@ -0,0 +1,85 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (C) 2021 Jernej Skrabec
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static struct ccu_clk_gate de2_gates[] = {
+ [CLK_MIXER0]= GATE(0x00, BIT(0)),
+ [CLK_MIXER1]= GATE(0x00, BIT(1)),
+ [CLK_WB]= GATE(0x00, BIT(2)),
+
+ [CLK_BUS_MIXER0]= GATE(0x04, BIT(0)),
+ [CLK_BUS_MIXER1]= GATE(0x04, BIT(1)),
+ [CLK_BUS_WB]= GATE(0x04, BIT(2)),
+};
+
+static struct ccu_reset de2_resets[] = {
+ [RST_MIXER0]= RESET(0x08, BIT(0)),
+ [RST_MIXER1]= RESET(0x08, BIT(1)),
+ [RST_WB]= RESET(0x08, BIT(2)),
+};
+
+static const struct ccu_desc de2_ccu_desc = {
+ .gates = de2_gates,
+ .resets = de2_resets,
+};
+
+static int de2_clk_probe(struct udevice *dev)
+{
+ struct sunxi_ccm_reg * const ccm =
+ (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+ u32 val;
+
+ if (device_is_compatible(dev_get_parent(dev),
+"allwinner,sun50i-a64-de2")) {
+ /* set SRAM for video use */
+ val = readl(SUNXI_SRAMC_BASE + 0x04);
+ val &= ~(0x01 << 24);
+ writel(val, SUNXI_SRAMC_BASE + 0x04);
+ }
+
+ /* clock driver doesn't know how to set rate or parent yet */
+ clock_set_pll10(43200);
+
+ /* Set DE parent to pll10 */
+ clrsetbits_le32(>de_clk_cfg, CCM_DE2_CTRL_PLL_MASK,
+ CCM_DE2_CTRL_PLL10);
+
+ return sunxi_clk_probe(dev);
+}
+
+static int de2_clk_bind(struct udevice *dev)
+{
+ return sunxi_reset_bind(dev, ARRAY_SIZE(de2_resets));
+}
+
+static const struct udevice_id de2_ccu_ids[] = {
+ { .compatible = "allwinner,sun8i-h3-de2-clk",
+ .data = (ulong)_ccu_desc },
+ { .compatible = "allwinner,sun50i-a64-de2-clk",
+ .data = (ulong)_ccu_desc },
+ { .compatible = "allwinner,sun50i-h5-de2-clk",
+ .data = (ulong)_ccu_desc },
+ { }
+};
+
+U_BOOT_DRIVER(clk_sun8i_de2) = {
+ .name = "sun8i_de2_ccu",
+ .id = UCLASS_CLK,
+ .of_match = de2_ccu_ids,
+ .priv_auto = sizeof(struct ccu_priv),
+ .ops= _clk_ops,
+ .probe = de2_clk_probe,
+ .bind = de2_clk_bind,
+};
--
2.30.1
[PATCH 14/19] video: sunxi: dw-hdmi: rework PHY initialization
Now that bit meanings are somewhat known, rework PHY initialization. This is modelled after Linux driver. Signed-off-by: Jernej Skrabec --- drivers/video/sunxi/sunxi_dw_hdmi.c | 411 +++- 1 file changed, 279 insertions(+), 132 deletions(-) diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c b/drivers/video/sunxi/sunxi_dw_hdmi.c index 4cc175d714ea..c4cded569bfb 100644 --- a/drivers/video/sunxi/sunxi_dw_hdmi.c +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c @@ -18,100 +18,200 @@ #include #include +#define SUN8I_HDMI_PHY_DBG_CTRL_PX_LOCKBIT(0) +#define SUN8I_HDMI_PHY_DBG_CTRL_POL_MASK GENMASK(15, 8) +#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NHSYNC BIT(8) +#define SUN8I_HDMI_PHY_DBG_CTRL_POL_NVSYNC BIT(9) +#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR_MASK GENMASK(23, 16) +#define SUN8I_HDMI_PHY_DBG_CTRL_ADDR(addr) (addr << 16) + +#define SUN8I_HDMI_PHY_REXT_CTRL_REXT_EN BIT(31) + +#define SUN8I_HDMI_PHY_READ_EN_MAGIC 0x54524545 + +#define SUN8I_HDMI_PHY_UNSCRAMBLE_MAGIC0x42494E47 + +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SWIBIT(31) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_PWEND BIT(30) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_PWENC BIT(29) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_CALSW BIT(28) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SVRCAL(x) ((x) << 26) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SVBH(x)((x) << 24) +#define SUN8I_HDMI_PHY_ANA_CFG1_AMP_OPTBIT(23) +#define SUN8I_HDMI_PHY_ANA_CFG1_EMP_OPTBIT(22) +#define SUN8I_HDMI_PHY_ANA_CFG1_AMPCK_OPT BIT(21) +#define SUN8I_HDMI_PHY_ANA_CFG1_EMPCK_OPT BIT(20) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENRCAL BIT(19) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENCALOGBIT(18) +#define SUN8I_HDMI_PHY_ANA_CFG1_REG_SCKTMDSBIT(17) +#define SUN8I_HDMI_PHY_ANA_CFG1_TMDSCLK_EN BIT(16) +#define SUN8I_HDMI_PHY_ANA_CFG1_TXEN_MASK GENMASK(15, 12) +#define SUN8I_HDMI_PHY_ANA_CFG1_TXEN_ALL (0xf << 12) +#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDSCLK BIT(11) +#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS2 BIT(10) +#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS1 BIT(9) +#define SUN8I_HDMI_PHY_ANA_CFG1_BIASEN_TMDS0 BIT(8) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDSCLK BIT(7) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS2BIT(6) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS1BIT(5) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENP2S_TMDS0BIT(4) +#define SUN8I_HDMI_PHY_ANA_CFG1_CKEN BIT(3) +#define SUN8I_HDMI_PHY_ANA_CFG1_LDOEN BIT(2) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENVBS BIT(1) +#define SUN8I_HDMI_PHY_ANA_CFG1_ENBI BIT(0) + +#define SUN8I_HDMI_PHY_ANA_CFG2_M_EN BIT(31) +#define SUN8I_HDMI_PHY_ANA_CFG2_PLLDBENBIT(30) +#define SUN8I_HDMI_PHY_ANA_CFG2_SENBIT(29) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_HPDPD BIT(28) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_HPDEN BIT(27) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_PLRCK BIT(26) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_PLR(x) ((x) << 23) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_DENCK BIT(22) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_DENBIT(21) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CD(x) ((x) << 19) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CKSS(x)((x) << 17) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BIGSWCKBIT(16) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BIGSW BIT(15) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_CSMPS(x) ((x) << 13) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_SLV(x) ((x) << 10) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BOOSTCK(x) ((x) << 8) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_BOOST(x) ((x) << 6) +#define SUN8I_HDMI_PHY_ANA_CFG2_REG_RESDI(x) ((x) << 0) + +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_SLOWCK(x) ((x) << 30) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_SLOW(x)((x) << 28) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_WIRE(x)((x) << 18) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_AMPCK(x) ((x) << 14) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_EMPCK(x) ((x) << 11) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_AMP(x) ((x) << 7) +#define SUN8I_HDMI_PHY_ANA_CFG3_REG_EMP(x) ((x) << 4) +#define SUN8I_HDMI_PHY_ANA_CFG3_SDAPD BIT(3) +#define SUN8I_HDMI_PHY_ANA_CFG3_SDAEN BIT(2) +#define SUN8I_HDMI_PHY_ANA_CFG3_SCLPD BIT(1) +#define SUN8I_HDMI_PHY_ANA_CFG3_SCLEN BIT(0) + +#define SUN8I_HDMI_PHY_PLL_CFG1_REG_OD1BIT(31) +#define SUN8I_HDMI_PHY_PLL_CFG1_REG_OD BIT(30) +#define SUN8I_HDMI_PHY_PLL_CFG1_LDO2_ENBIT(29) +#define SUN8I_HDMI_PHY_PLL_CFG1_LDO1_ENBIT(28) +#define SUN8I_HDMI_PHY_PLL_CFG1_HV_IS_33 BIT(27) +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_MSK BIT(26) +#define SUN8I_HDMI_PHY_PLL_CFG1_CKIN_SEL_SHIFT 26 +#define SUN8I_HDMI_PHY_PLL_CFG1_PLLEN BIT(25) +#define SUN8I_HDMI_PHY_PLL_CFG1_LDO_VSET(x)((x) << 22) +#define SUN8I_HDMI_PHY_PLL_CFG1_UNKNOWN(x) ((x) << 20) +#define
[PATCH 17/19] clk: sunxi: Add DE2 clocks to H3 and A64
With the next commit another clock and reset driver will be implemented
which requires DE2 related clocks and resets. Add them.
Cc: Lukasz Majewski
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi/clk_a64.c | 6 ++
drivers/clk/sunxi/clk_h3.c | 6 ++
2 files changed, 12 insertions(+)
diff --git a/drivers/clk/sunxi/clk_a64.c b/drivers/clk/sunxi/clk_a64.c
index 0553ffa4399a..c7cf88ce3436 100644
--- a/drivers/clk/sunxi/clk_a64.c
+++ b/drivers/clk/sunxi/clk_a64.c
@@ -26,6 +26,8 @@ static const struct ccu_clk_gate a64_gates[] = {
[CLK_BUS_OHCI0] = GATE(0x060, BIT(28)),
[CLK_BUS_OHCI1] = GATE(0x060, BIT(29)),
+ [CLK_BUS_DE]= GATE(0x064, BIT(12)),
+
[CLK_BUS_UART0] = GATE(0x06c, BIT(16)),
[CLK_BUS_UART1] = GATE(0x06c, BIT(17)),
[CLK_BUS_UART2] = GATE(0x06c, BIT(18)),
@@ -41,6 +43,8 @@ static const struct ccu_clk_gate a64_gates[] = {
[CLK_USB_HSIC_12M] = GATE(0x0cc, BIT(11)),
[CLK_USB_OHCI0] = GATE(0x0cc, BIT(16)),
[CLK_USB_OHCI1] = GATE(0x0cc, BIT(17)),
+
+ [CLK_DE]= GATE(0x104, BIT(31)),
};
static const struct ccu_reset a64_resets[] = {
@@ -60,6 +64,8 @@ static const struct ccu_reset a64_resets[] = {
[RST_BUS_OHCI0] = RESET(0x2c0, BIT(28)),
[RST_BUS_OHCI1] = RESET(0x2c0, BIT(29)),
+ [RST_BUS_DE]= RESET(0x2c4, BIT(12)),
+
[RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
[RST_BUS_UART1] = RESET(0x2d8, BIT(17)),
[RST_BUS_UART2] = RESET(0x2d8, BIT(18)),
diff --git a/drivers/clk/sunxi/clk_h3.c b/drivers/clk/sunxi/clk_h3.c
index f81633b92d5a..bf8d963d18b6 100644
--- a/drivers/clk/sunxi/clk_h3.c
+++ b/drivers/clk/sunxi/clk_h3.c
@@ -30,6 +30,8 @@ static struct ccu_clk_gate h3_gates[] = {
[CLK_BUS_OHCI2] = GATE(0x060, BIT(30)),
[CLK_BUS_OHCI3] = GATE(0x060, BIT(31)),
+ [CLK_BUS_DE]= GATE(0x064, BIT(12)),
+
[CLK_BUS_UART0] = GATE(0x06c, BIT(16)),
[CLK_BUS_UART1] = GATE(0x06c, BIT(17)),
[CLK_BUS_UART2] = GATE(0x06c, BIT(18)),
@@ -48,6 +50,8 @@ static struct ccu_clk_gate h3_gates[] = {
[CLK_USB_OHCI1] = GATE(0x0cc, BIT(17)),
[CLK_USB_OHCI2] = GATE(0x0cc, BIT(18)),
[CLK_USB_OHCI3] = GATE(0x0cc, BIT(19)),
+
+ [CLK_DE]= GATE(0x104, BIT(31)),
};
static struct ccu_reset h3_resets[] = {
@@ -72,6 +76,8 @@ static struct ccu_reset h3_resets[] = {
[RST_BUS_OHCI2] = RESET(0x2c0, BIT(30)),
[RST_BUS_OHCI3] = RESET(0x2c0, BIT(31)),
+ [RST_BUS_DE]= RESET(0x2c4, BIT(12)),
+
[RST_BUS_EPHY] = RESET(0x2c8, BIT(2)),
[RST_BUS_UART0] = RESET(0x2d8, BIT(16)),
--
2.30.1
[PATCH 16/19] video: sunxi: de2: read address from DT node
Currently DE2 uses hardcoded address based on SoC for which U-Boot is
built. Read it from DT instead so there is no need to specify it when
support for new SoC is added.
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_de2.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index 81576e45e9ef..f6c8ca075aba 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -64,11 +64,10 @@ static void sunxi_de2_composer_init(void)
setbits_le32(>de_clk_cfg, CCM_DE2_CTRL_GATE);
}
-static void sunxi_de2_mode_set(int mux, const struct display_timing *mode,
+static void sunxi_de2_mode_set(ulong de_mux_base, int mux,
+ const struct display_timing *mode,
int bpp, ulong address, bool is_composite)
{
- ulong de_mux_base = (mux == 0) ?
- SUNXI_DE2_MUX0_BASE : SUNXI_DE2_MUX1_BASE;
struct de_clk * const de_clk_regs =
(struct de_clk *)(SUNXI_DE2_BASE);
struct de_glb * const de_glb_regs =
@@ -208,7 +207,8 @@ static int sunxi_de2_init(struct udevice *dev, ulong fbbase,
}
sunxi_de2_composer_init();
- sunxi_de2_mode_set(mux, , 1 << l2bpp, fbbase, is_composite);
+ sunxi_de2_mode_set((ulong)dev_read_addr(dev), mux, ,
+ 1 << l2bpp, fbbase, is_composite);
ret = display_enable(disp, 1 << l2bpp, );
if (ret) {
--
2.30.1
[PATCH 15/19] video: sunxi: de2: switch to DT probing
Currently DE2 driver is probed via driver info. Switch probing to device
tree compatible string method.
Display is now searched via driver name which has same limitation as
previous method. This can be improved only when all drivers in chain are
probed via device tree compatible strings.
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_de2.c | 88 +++--
1 file changed, 52 insertions(+), 36 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index e02d359cd259..81576e45e9ef 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -31,6 +31,11 @@ enum {
LCD_MAX_LOG2_BPP= VIDEO_BPP32,
};
+struct sunxi_de2_data {
+ int id;
+ const char *disp_drv_name;
+};
+
static void sunxi_de2_composer_init(void)
{
struct sunxi_ccm_reg * const ccm =
@@ -228,51 +233,34 @@ static int sunxi_de2_init(struct udevice *dev, ulong
fbbase,
static int sunxi_de2_probe(struct udevice *dev)
{
+ const struct sunxi_de2_data *data =
+ (const struct sunxi_de2_data *)dev_get_driver_data(dev);
struct video_uc_plat *plat = dev_get_uclass_plat(dev);
struct udevice *disp;
- int ret;
+ int ret, index = 0;
/* Before relocation we don't need to do anything */
if (!(gd->flags & GD_FLG_RELOC))
return 0;
- ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
- DM_DRIVER_GET(sunxi_lcd), );
- if (!ret) {
- int mux;
+ while (!(ret = uclass_get_device(UCLASS_DISPLAY, index++, ))) {
+ if (strcmp(disp->driver->name, data->disp_drv_name))
+ continue;
- mux = 0;
+ ret = sunxi_de2_init(dev, plat->base, VIDEO_BPP32, disp,
+data->id, false);
+ if (ret)
+ return ret;
- ret = sunxi_de2_init(dev, plat->base, VIDEO_BPP32, disp, mux,
-false);
- if (!ret) {
- video_set_flush_dcache(dev, 1);
- return 0;
- }
- }
-
- debug("%s: lcd display not found (ret=%d)\n", __func__, ret);
-
- ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
- DM_DRIVER_GET(sunxi_dw_hdmi), );
- if (!ret) {
- int mux;
- if (IS_ENABLED(CONFIG_MACH_SUNXI_H3_H5))
- mux = 0;
- else
- mux = 1;
+ video_set_flush_dcache(dev, 1);
- ret = sunxi_de2_init(dev, plat->base, VIDEO_BPP32, disp, mux,
-false);
- if (!ret) {
- video_set_flush_dcache(dev, 1);
- return 0;
- }
+ return 0;
}
- debug("%s: hdmi display not found (ret=%d)\n", __func__, ret);
+ debug("%s: %s not found (ret=%d)\n", __func__,
+ data->disp_drv_name, ret);
- return -ENODEV;
+ return ret;
}
static int sunxi_de2_bind(struct udevice *dev)
@@ -285,22 +273,50 @@ static int sunxi_de2_bind(struct udevice *dev)
return 0;
}
+const struct sunxi_de2_data h3_mixer_0 = {
+ .id = 0,
+ .disp_drv_name = "sunxi_dw_hdmi",
+};
+
+const struct sunxi_de2_data a64_mixer_0 = {
+ .id = 0,
+ .disp_drv_name = "sunxi_lcd",
+};
+
+const struct sunxi_de2_data a64_mixer_1 = {
+ .id = 1,
+ .disp_drv_name = "sunxi_dw_hdmi",
+};
+
+static const struct udevice_id sunxi_de2_ids[] = {
+ {
+ .compatible = "allwinner,sun8i-h3-de2-mixer-0",
+ .data = (ulong)_mixer_0,
+ },
+ {
+ .compatible = "allwinner,sun50i-a64-de2-mixer-0",
+ .data = (ulong)_mixer_0,
+ },
+ {
+ .compatible = "allwinner,sun50i-a64-de2-mixer-1",
+ .data = (ulong)_mixer_1,
+ },
+ { }
+};
+
static const struct video_ops sunxi_de2_ops = {
};
U_BOOT_DRIVER(sunxi_de2) = {
.name = "sunxi_de2",
.id = UCLASS_VIDEO,
+ .of_match = sunxi_de2_ids,
.ops= _de2_ops,
.bind = sunxi_de2_bind,
.probe = sunxi_de2_probe,
.flags = DM_FLAG_PRE_RELOC,
};
-U_BOOT_DRVINFO(sunxi_de2) = {
- .name = "sunxi_de2"
-};
-
/*
* Simplefb support.
*/
--
2.30.1
[PATCH 09/19] video: sunxi: de2: switch to public uclass functions
Currently DE2 driver uses functions which are defined in -internal
header. They are not meant to be used outside of uclass framework.
Switch DE2 driver to public ones. This has additional benefit that
device_probe doesn't need to be called manually.
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_de2.c | 29 ++---
1 file changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index 6b836a011944..e02d359cd259 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -19,8 +19,6 @@
#include
#include
#include
-#include
-#include
#include
#include "simplefb_common.h"
@@ -198,13 +196,6 @@ static int sunxi_de2_init(struct udevice *dev, ulong
fbbase,
disp_uc_plat->source_id = mux;
- ret = device_probe(disp);
- if (ret) {
- debug("%s: device '%s' display won't probe (ret=%d)\n",
- __func__, dev->name, ret);
- return ret;
- }
-
ret = display_read_timing(disp, );
if (ret) {
debug("%s: Failed to read timings\n", __func__);
@@ -245,8 +236,8 @@ static int sunxi_de2_probe(struct udevice *dev)
if (!(gd->flags & GD_FLG_RELOC))
return 0;
- ret = uclass_find_device_by_name(UCLASS_DISPLAY,
-"sunxi_lcd", );
+ ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
+ DM_DRIVER_GET(sunxi_lcd), );
if (!ret) {
int mux;
@@ -262,8 +253,8 @@ static int sunxi_de2_probe(struct udevice *dev)
debug("%s: lcd display not found (ret=%d)\n", __func__, ret);
- ret = uclass_find_device_by_name(UCLASS_DISPLAY,
-"sunxi_dw_hdmi", );
+ ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
+ DM_DRIVER_GET(sunxi_dw_hdmi), );
if (!ret) {
int mux;
if (IS_ENABLED(CONFIG_MACH_SUNXI_H3_H5))
@@ -332,8 +323,8 @@ int sunxi_simplefb_setup(void *blob)
mux = 1;
/* Skip simplefb setting if DE2 / HDMI is not present */
- ret = uclass_find_device_by_name(UCLASS_VIDEO,
-"sunxi_de2", );
+ ret = uclass_get_device_by_driver(UCLASS_VIDEO,
+ DM_DRIVER_GET(sunxi_de2), );
if (ret) {
debug("DE2 not present\n");
return 0;
@@ -342,8 +333,8 @@ int sunxi_simplefb_setup(void *blob)
return 0;
}
- ret = uclass_find_device_by_name(UCLASS_DISPLAY,
-"sunxi_dw_hdmi", );
+ ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
+ DM_DRIVER_GET(sunxi_dw_hdmi), );
if (ret) {
debug("HDMI not present\n");
} else if (device_active(hdmi)) {
@@ -355,8 +346,8 @@ int sunxi_simplefb_setup(void *blob)
debug("HDMI present but not probed\n");
}
- ret = uclass_find_device_by_name(UCLASS_DISPLAY,
-"sunxi_lcd", );
+ ret = uclass_get_device_by_driver(UCLASS_DISPLAY,
+ DM_DRIVER_GET(sunxi_lcd), );
if (ret)
debug("LCD not present\n");
else if (device_active(lcd))
--
2.30.1
[PATCH 13/19] video: sunxi: dw-hdmi: move PHY config to appropriate place
Currently sunxi_dw_hdmi_enable() configures PHY timing related
parameters. However, sunxi_dw_hdmi_phy_cfg() is better suited place for
that. Move the code there. This also allows to easier driver expansion
when controller uses different PHY than currently supported (like that
in H6).
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_dw_hdmi.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
b/drivers/video/sunxi/sunxi_dw_hdmi.c
index 483d57293155..4cc175d714ea 100644
--- a/drivers/video/sunxi/sunxi_dw_hdmi.c
+++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
@@ -114,11 +114,13 @@ static void sunxi_dw_hdmi_phy_init(struct dw_hdmi *hdmi)
writel(0x42494E47, >unscramble);
}
-static void sunxi_dw_hdmi_phy_set(struct dw_hdmi *hdmi, uint clock, int
phy_div)
+static void sunxi_dw_hdmi_phy_set(struct dw_hdmi *hdmi,
+ const struct display_timing *edid,
+ int phy_div)
{
struct sunxi_hdmi_phy * const phy =
(struct sunxi_hdmi_phy *)(hdmi->ioaddr + HDMI_PHY_OFFS);
- int div = sunxi_dw_hdmi_get_divider(clock);
+ int div = sunxi_dw_hdmi_get_divider(edid->pixelclock.typ);
u32 tmp;
/*
@@ -187,6 +189,14 @@ static void sunxi_dw_hdmi_phy_set(struct dw_hdmi *hdmi,
uint clock, int phy_div)
writel(0x0F81C405, >unk2);
break;
}
+
+ if (edid->flags & DISPLAY_FLAGS_VSYNC_LOW)
+ setbits_le32(>pol, 0x200);
+
+ if (edid->flags & DISPLAY_FLAGS_HSYNC_LOW)
+ setbits_le32(>pol, 0x100);
+
+ setbits_le32(>ctrl, 0xf << 12);
}
static void sunxi_dw_hdmi_pll_set(uint clk_khz, int *phy_div)
@@ -272,7 +282,7 @@ static int sunxi_dw_hdmi_phy_cfg(struct dw_hdmi *hdmi,
int phy_div;
sunxi_dw_hdmi_pll_set(edid->pixelclock.typ / 1000, _div);
- sunxi_dw_hdmi_phy_set(hdmi, edid->pixelclock.typ, phy_div);
+ sunxi_dw_hdmi_phy_set(hdmi, edid, phy_div);
return 0;
}
@@ -304,14 +314,6 @@ static int sunxi_dw_hdmi_enable(struct udevice *dev, int
panel_bpp,
sunxi_dw_hdmi_lcdc_init(priv->mux, edid, panel_bpp);
- if (edid->flags & DISPLAY_FLAGS_VSYNC_LOW)
- setbits_le32(>pol, 0x200);
-
- if (edid->flags & DISPLAY_FLAGS_HSYNC_LOW)
- setbits_le32(>pol, 0x100);
-
- setbits_le32(>ctrl, 0xf << 12);
-
/*
* This is last hdmi access before boot, so scramble addresses
* again or othwerwise BSP driver won't work. Dummy read is
--
2.30.1
[PATCH 11/19] video: sunxi: dw-hdmi: read address from DT node
Currently HDMI controller MMIO address is hardcoded. Change that so
address is read from DT node. That will make adding support for new
variants a bit easier.
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_dw_hdmi.c | 38 ++---
1 file changed, 24 insertions(+), 14 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
b/drivers/video/sunxi/sunxi_dw_hdmi.c
index 6f77b2a43b40..0744954fa15f 100644
--- a/drivers/video/sunxi/sunxi_dw_hdmi.c
+++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
@@ -57,10 +57,10 @@ static int sunxi_dw_hdmi_get_divider(uint clock)
return 1;
}
-static void sunxi_dw_hdmi_phy_init(void)
+static void sunxi_dw_hdmi_phy_init(struct dw_hdmi *hdmi)
{
struct sunxi_hdmi_phy * const phy =
- (struct sunxi_hdmi_phy *)(SUNXI_HDMI_BASE + HDMI_PHY_OFFS);
+ (struct sunxi_hdmi_phy *)(hdmi->ioaddr + HDMI_PHY_OFFS);
unsigned long tmo;
u32 tmp;
@@ -114,10 +114,10 @@ static void sunxi_dw_hdmi_phy_init(void)
writel(0x42494E47, >unscramble);
}
-static void sunxi_dw_hdmi_phy_set(uint clock, int phy_div)
+static void sunxi_dw_hdmi_phy_set(struct dw_hdmi *hdmi, uint clock, int
phy_div)
{
struct sunxi_hdmi_phy * const phy =
- (struct sunxi_hdmi_phy *)(SUNXI_HDMI_BASE + HDMI_PHY_OFFS);
+ (struct sunxi_hdmi_phy *)(hdmi->ioaddr + HDMI_PHY_OFFS);
int div = sunxi_dw_hdmi_get_divider(clock);
u32 tmp;
@@ -271,7 +271,7 @@ static int sunxi_dw_hdmi_phy_cfg(struct dw_hdmi *hdmi, uint
mpixelclock)
int phy_div;
sunxi_dw_hdmi_pll_set(mpixelclock / 1000, _div);
- sunxi_dw_hdmi_phy_set(mpixelclock, phy_div);
+ sunxi_dw_hdmi_phy_set(hdmi, mpixelclock, phy_div);
return 0;
}
@@ -292,9 +292,9 @@ static bool sunxi_dw_hdmi_mode_valid(struct udevice *dev,
static int sunxi_dw_hdmi_enable(struct udevice *dev, int panel_bpp,
const struct display_timing *edid)
{
- struct sunxi_hdmi_phy * const phy =
- (struct sunxi_hdmi_phy *)(SUNXI_HDMI_BASE + HDMI_PHY_OFFS);
struct sunxi_dw_hdmi_priv *priv = dev_get_priv(dev);
+ struct sunxi_hdmi_phy * const phy =
+ (struct sunxi_hdmi_phy *)(priv->hdmi.ioaddr + HDMI_PHY_OFFS);
int ret;
ret = dw_hdmi_enable(>hdmi, edid);
@@ -316,12 +316,26 @@ static int sunxi_dw_hdmi_enable(struct udevice *dev, int
panel_bpp,
* again or othwerwise BSP driver won't work. Dummy read is
* needed or otherwise last write doesn't get written correctly.
*/
- (void)readb(SUNXI_HDMI_BASE);
+ (void)readb(priv->hdmi.ioaddr);
writel(0, >unscramble);
return 0;
}
+static int sunxi_dw_hdmi_of_to_plat(struct udevice *dev)
+{
+ struct sunxi_dw_hdmi_priv *priv = dev_get_priv(dev);
+ struct dw_hdmi *hdmi = >hdmi;
+
+ hdmi->ioaddr = (ulong)dev_read_addr(dev);
+ hdmi->i2c_clk_high = 0xd8;
+ hdmi->i2c_clk_low = 0xfe;
+ hdmi->reg_io_width = 1;
+ hdmi->phy_set = sunxi_dw_hdmi_phy_cfg;
+
+ return 0;
+}
+
static int sunxi_dw_hdmi_probe(struct udevice *dev)
{
struct display_plat *uc_plat = dev_get_uclass_plat(dev);
@@ -346,13 +360,8 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
/* Clock on */
setbits_le32(>hdmi_clk_cfg, CCM_HDMI_CTRL_GATE);
- sunxi_dw_hdmi_phy_init();
+ sunxi_dw_hdmi_phy_init(>hdmi);
- priv->hdmi.ioaddr = SUNXI_HDMI_BASE;
- priv->hdmi.i2c_clk_high = 0xd8;
- priv->hdmi.i2c_clk_low = 0xfe;
- priv->hdmi.reg_io_width = 1;
- priv->hdmi.phy_set = sunxi_dw_hdmi_phy_cfg;
priv->mux = uc_plat->source_id;
ret = dw_hdmi_phy_wait_for_hpd(>hdmi);
@@ -382,6 +391,7 @@ U_BOOT_DRIVER(sunxi_dw_hdmi) = {
.id = UCLASS_DISPLAY,
.of_match = sunxi_dw_hdmi_ids,
.ops= _dw_hdmi_ops,
+ .of_to_plat = sunxi_dw_hdmi_of_to_plat,
.probe = sunxi_dw_hdmi_probe,
.priv_auto = sizeof(struct sunxi_dw_hdmi_priv),
};
--
2.30.1
[PATCH 10/19] video: sunxi: dw-hdmi: probe driver by compatible
Currently sunxi dw-hdmi driver is probed unconditionally, even if there
is no such device.
Switch driver to probing via compatible string. This brings many
benefits - driver can read DT node and allows driver to be always
enabled.
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_dw_hdmi.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
b/drivers/video/sunxi/sunxi_dw_hdmi.c
index 6d2bc206fc2c..6f77b2a43b40 100644
--- a/drivers/video/sunxi/sunxi_dw_hdmi.c
+++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
@@ -372,14 +372,16 @@ static const struct dm_display_ops sunxi_dw_hdmi_ops = {
.mode_valid = sunxi_dw_hdmi_mode_valid,
};
+static const struct udevice_id sunxi_dw_hdmi_ids[] = {
+ { .compatible = "allwinner,sun8i-a83t-dw-hdmi" },
+ { }
+};
+
U_BOOT_DRIVER(sunxi_dw_hdmi) = {
.name = "sunxi_dw_hdmi",
.id = UCLASS_DISPLAY,
+ .of_match = sunxi_dw_hdmi_ids,
.ops= _dw_hdmi_ops,
.probe = sunxi_dw_hdmi_probe,
.priv_auto = sizeof(struct sunxi_dw_hdmi_priv),
};
-
-U_BOOT_DRVINFO(sunxi_dw_hdmi) = {
- .name = "sunxi_dw_hdmi"
-};
--
2.30.1
[PATCH 12/19] video: dw-hdmi: modify phy init callback to include full timings
Currently PHY init callback has only pixel clock as a parameter, but
other timing parameters may be needed for custom PHYs. Modify callback
signature to include full timings.
Cc: Neil Armstrong
Signed-off-by: Jernej Skrabec
---
drivers/video/dw_hdmi.c | 6 +++---
drivers/video/meson/meson_dw_hdmi.c | 5 +++--
drivers/video/sunxi/sunxi_dw_hdmi.c | 7 ---
include/dw_hdmi.h | 4 ++--
4 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/video/dw_hdmi.c b/drivers/video/dw_hdmi.c
index c4fbb1829446..8d71f713f99f 100644
--- a/drivers/video/dw_hdmi.c
+++ b/drivers/video/dw_hdmi.c
@@ -901,7 +901,7 @@ static const u8 pre_buf[] = {
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xe9,
};
-int dw_hdmi_phy_cfg(struct dw_hdmi *hdmi, uint mpixelclock)
+int dw_hdmi_phy_cfg(struct dw_hdmi *hdmi, const struct display_timing *edid)
{
int i, ret;
@@ -912,7 +912,7 @@ int dw_hdmi_phy_cfg(struct dw_hdmi *hdmi, uint mpixelclock)
hdmi_phy_enable_tmds(hdmi, 0);
hdmi_phy_enable_power(hdmi, 0);
- ret = hdmi_phy_configure(hdmi, mpixelclock);
+ ret = hdmi_phy_configure(hdmi, edid->pixelclock.typ);
if (ret) {
debug("hdmi phy config failure %d\n", ret);
return ret;
@@ -988,7 +988,7 @@ int dw_hdmi_enable(struct dw_hdmi *hdmi, const struct
display_timing *edid)
hdmi_av_composer(hdmi, edid);
- ret = hdmi->phy_set(hdmi, edid->pixelclock.typ);
+ ret = hdmi->phy_set(hdmi, edid);
if (ret)
return ret;
diff --git a/drivers/video/meson/meson_dw_hdmi.c
b/drivers/video/meson/meson_dw_hdmi.c
index e5f281320534..7558814b3491 100644
--- a/drivers/video/meson/meson_dw_hdmi.c
+++ b/drivers/video/meson/meson_dw_hdmi.c
@@ -292,7 +292,8 @@ static void meson_dw_hdmi_phy_setup_mode(struct
meson_dw_hdmi *priv,
}
}
-static int meson_dw_hdmi_phy_init(struct dw_hdmi *hdmi, uint pixel_clock)
+static int meson_dw_hdmi_phy_init(struct dw_hdmi *hdmi,
+ const struct display_timing *edid)
{
struct meson_dw_hdmi *priv = container_of(hdmi, struct meson_dw_hdmi,
hdmi);
@@ -322,7 +323,7 @@ static int meson_dw_hdmi_phy_init(struct dw_hdmi *hdmi,
uint pixel_clock)
dw_hdmi_top_write(hdmi, HDMITX_TOP_TMDS_CLK_PTTN_CNTL, 0x2);
/* Setup PHY parameters */
- meson_dw_hdmi_phy_setup_mode(priv, pixel_clock);
+ meson_dw_hdmi_phy_setup_mode(priv, edid->pixelclock.typ);
/* Setup PHY */
dw_hdmi_hhi_update_bits(priv, HHI_HDMI_PHY_CNTL1,
diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
b/drivers/video/sunxi/sunxi_dw_hdmi.c
index 0744954fa15f..483d57293155 100644
--- a/drivers/video/sunxi/sunxi_dw_hdmi.c
+++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
@@ -266,12 +266,13 @@ static void sunxi_dw_hdmi_lcdc_init(int mux, const struct
display_timing *edid,
lcdc_enable(lcdc, bpp);
}
-static int sunxi_dw_hdmi_phy_cfg(struct dw_hdmi *hdmi, uint mpixelclock)
+static int sunxi_dw_hdmi_phy_cfg(struct dw_hdmi *hdmi,
+const struct display_timing *edid)
{
int phy_div;
- sunxi_dw_hdmi_pll_set(mpixelclock / 1000, _div);
- sunxi_dw_hdmi_phy_set(hdmi, mpixelclock, phy_div);
+ sunxi_dw_hdmi_pll_set(edid->pixelclock.typ / 1000, _div);
+ sunxi_dw_hdmi_phy_set(hdmi, edid->pixelclock.typ, phy_div);
return 0;
}
diff --git a/include/dw_hdmi.h b/include/dw_hdmi.h
index 8acae3839fb3..46b87916b8bb 100644
--- a/include/dw_hdmi.h
+++ b/include/dw_hdmi.h
@@ -544,12 +544,12 @@ struct dw_hdmi {
struct hdmi_data_info hdmi_data;
struct udevice *ddc_bus;
- int (*phy_set)(struct dw_hdmi *hdmi, uint mpixelclock);
+ int (*phy_set)(struct dw_hdmi *hdmi, const struct display_timing *edid);
void (*write_reg)(struct dw_hdmi *hdmi, u8 val, int offset);
u8 (*read_reg)(struct dw_hdmi *hdmi, int offset);
};
-int dw_hdmi_phy_cfg(struct dw_hdmi *hdmi, uint mpixelclock);
+int dw_hdmi_phy_cfg(struct dw_hdmi *hdmi, const struct display_timing *edid);
int dw_hdmi_phy_wait_for_hpd(struct dw_hdmi *hdmi);
void dw_hdmi_phy_init(struct dw_hdmi *hdmi);
--
2.30.1
[PATCH 08/19] video: sunxi: Remove TV probe from DE2
TV driver was never fully implemented. Remove search for it from DE2
driver.
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_de2.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_de2.c b/drivers/video/sunxi/sunxi_de2.c
index a3e21aa5f13e..6b836a011944 100644
--- a/drivers/video/sunxi/sunxi_de2.c
+++ b/drivers/video/sunxi/sunxi_de2.c
@@ -281,20 +281,7 @@ static int sunxi_de2_probe(struct udevice *dev)
debug("%s: hdmi display not found (ret=%d)\n", __func__, ret);
- ret = uclass_find_device_by_name(UCLASS_DISPLAY,
- "sunxi_tve", );
- if (ret) {
- debug("%s: tv not found (ret=%d)\n", __func__, ret);
- return ret;
- }
-
- ret = sunxi_de2_init(dev, plat->base, VIDEO_BPP32, disp, 1, true);
- if (ret)
- return ret;
-
- video_set_flush_dcache(dev, 1);
-
- return 0;
+ return -ENODEV;
}
static int sunxi_de2_bind(struct udevice *dev)
--
2.30.1
[PATCH 06/19] video: sunxi: Use DW-HDMI hpd function
It turns out that even though A64, H3 and H5 have custom PHY, standard
hot plug detection for DW-HDMI works just fine.
Remove custom hpd method to reduce amount of custom code.
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_dw_hdmi.c | 34 +
1 file changed, 6 insertions(+), 28 deletions(-)
diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
b/drivers/video/sunxi/sunxi_dw_hdmi.c
index e3811a2ec15f..37e78ff24111 100644
--- a/drivers/video/sunxi/sunxi_dw_hdmi.c
+++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
@@ -114,28 +114,6 @@ static void sunxi_dw_hdmi_phy_init(void)
writel(0x42494E47, >unscramble);
}
-static int sunxi_dw_hdmi_get_plug_in_status(void)
-{
- struct sunxi_hdmi_phy * const phy =
- (struct sunxi_hdmi_phy *)(SUNXI_HDMI_BASE + HDMI_PHY_OFFS);
-
- return !!(readl(>status) & (1 << 19));
-}
-
-static int sunxi_dw_hdmi_wait_for_hpd(void)
-{
- ulong start;
-
- start = get_timer(0);
- do {
- if (sunxi_dw_hdmi_get_plug_in_status())
- return 0;
- udelay(100);
- } while (get_timer(start) < 300);
-
- return -1;
-}
-
static void sunxi_dw_hdmi_phy_set(uint clock, int phy_div)
{
struct sunxi_hdmi_phy * const phy =
@@ -370,12 +348,6 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
sunxi_dw_hdmi_phy_init();
- ret = sunxi_dw_hdmi_wait_for_hpd();
- if (ret < 0) {
- debug("hdmi can not get hpd signal\n");
- return -1;
- }
-
priv->hdmi.ioaddr = SUNXI_HDMI_BASE;
priv->hdmi.i2c_clk_high = 0xd8;
priv->hdmi.i2c_clk_low = 0xfe;
@@ -383,6 +355,12 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
priv->hdmi.phy_set = sunxi_dw_hdmi_phy_cfg;
priv->mux = uc_plat->source_id;
+ ret = dw_hdmi_phy_wait_for_hpd(>hdmi);
+ if (ret < 0) {
+ debug("hdmi can not get hpd signal\n");
+ return -1;
+ }
+
uclass_get_device_by_phandle(UCLASS_I2C, dev, "ddc-i2c-bus",
>hdmi.ddc_bus);
--
2.30.1
[PATCH 05/19] common: edid: Search for valid timing in extension block
One of my monitors have only 4k@60 timing in base EDID block which is
out of range for devices with HDMI 1.4. It turns out that it has
additional detailed timings in CTA-861 Extension Block and two of them
are appropriate for HDMI 1.4.
Add additional search for valid detailed timing in extension block.
Signed-off-by: Jernej Skrabec
---
common/edid.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/common/edid.c b/common/edid.c
index a6c875d9c8e8..14d8836c360e 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -220,6 +220,24 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
/* Look for detailed timing in base EDID */
found = edid_find_valid_timing(edid->monitor_details.descriptor, 4,
timing, mode_valid, mode_valid_priv);
+
+ /* Look for detailed timing in CTA-861 Extension Block */
+ if (!found && edid->extension_flag && buf_size >= EDID_EXT_SIZE) {
+ struct edid_cea861_info *info =
+ (struct edid_cea861_info *)(buf + sizeof(*edid));
+
+ if (info->extension_tag == EDID_CEA861_EXTENSION_TAG) {
+ int count = EDID_CEA861_DTD_COUNT(*info);
+ int offset = info->dtd_offset;
+ int size = count * sizeof(struct edid_detailed_timing);
+
+ if (offset >= 4 && offset + size < EDID_SIZE)
+ found = edid_find_valid_timing(
+ (u8*)info + offset, count, timing,
+ mode_valid, mode_valid_priv);
+ }
+ }
+
if (!found)
return -EINVAL;
--
2.30.1
[PATCH 07/19] video: sunxi: Remove check for ddc-i2c-bus property
No Allwinner boards with DW-HDMI controller use separate I2C bus for EDID read. Remove that check. Signed-off-by: Jernej Skrabec --- drivers/video/sunxi/sunxi_dw_hdmi.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c b/drivers/video/sunxi/sunxi_dw_hdmi.c index 37e78ff24111..6d2bc206fc2c 100644 --- a/drivers/video/sunxi/sunxi_dw_hdmi.c +++ b/drivers/video/sunxi/sunxi_dw_hdmi.c @@ -361,9 +361,6 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev) return -1; } - uclass_get_device_by_phandle(UCLASS_I2C, dev, "ddc-i2c-bus", ->hdmi.ddc_bus); - dw_hdmi_init(>hdmi); return 0; -- 2.30.1
[PATCH 04/19] common: edid: extract code for detailed timing search
Code which searches for valid detailed timing entry will be used in more
places. Extract it.
Signed-off-by: Jernej Skrabec
---
common/edid.c | 49 -
1 file changed, 28 insertions(+), 21 deletions(-)
diff --git a/common/edid.c b/common/edid.c
index 1cb7177742e8..a6c875d9c8e8 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -169,6 +169,29 @@ static bool cea_is_hdmi_vsdb_present(struct
edid_cea861_info *info)
return false;
}
+static bool edid_find_valid_timing(void *buf, int count,
+ struct display_timing *timing,
+ bool (*mode_valid)(void *priv,
+ const struct display_timing *timing),
+ void *mode_valid_priv)
+{
+ struct edid_detailed_timing *t = buf;
+ bool found = false;
+ int i;
+
+ for (i = 0; i < count && !found; i++, t++)
+ if (EDID_DETAILED_TIMING_PIXEL_CLOCK(*t) != 0) {
+ decode_timing((u8 *)t, timing);
+ if (mode_valid)
+ found = mode_valid(mode_valid_priv,
+ timing);
+ else
+ found = true;
+ }
+
+ return found;
+}
+
int edid_get_timing_validate(u8 *buf, int buf_size,
struct display_timing *timing,
int *panel_bits_per_colourp,
@@ -177,8 +200,7 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
void *mode_valid_priv)
{
struct edid1_info *edid = (struct edid1_info *)buf;
- bool timing_done;
- int i;
+ bool found;
if (buf_size < sizeof(*edid) || edid_check_info(edid)) {
debug("%s: Invalid buffer\n", __func__);
@@ -195,25 +217,10 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
return -ENOENT;
}
- /* Look for detailed timing */
- timing_done = false;
- for (i = 0; i < 4; i++) {
- struct edid_monitor_descriptor *desc;
-
- desc = >monitor_details.descriptor[i];
- if (desc->zero_flag_1 != 0) {
- decode_timing((u8 *)desc, timing);
- if (mode_valid)
- timing_done = mode_valid(mode_valid_priv,
-timing);
- else
- timing_done = true;
-
- if (timing_done)
- break;
- }
- }
- if (!timing_done)
+ /* Look for detailed timing in base EDID */
+ found = edid_find_valid_timing(edid->monitor_details.descriptor, 4,
+ timing, mode_valid, mode_valid_priv);
+ if (!found)
return -EINVAL;
if (edid->version != 1 || edid->revision < 4) {
--
2.30.1
[PATCH 03/19] common: edid: check for digital display earlier
When searching for detailed timing in EDID, check for digital display
earlier. There is no point parsing other parameters if this flag is not
present.
Signed-off-by: Jernej Skrabec
---
common/edid.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/common/edid.c b/common/edid.c
index 553ab8fd01a1..1cb7177742e8 100644
--- a/common/edid.c
+++ b/common/edid.c
@@ -185,6 +185,11 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
return -EINVAL;
}
+ if (!EDID1_INFO_VIDEO_INPUT_DIGITAL(*edid)) {
+ debug("%s: Not a digital display\n", __func__);
+ return -ENOSYS;
+ }
+
if (!EDID1_INFO_FEATURE_PREFERRED_TIMING_MODE(*edid)) {
debug("%s: No preferred timing\n", __func__);
return -ENOENT;
@@ -211,10 +216,6 @@ int edid_get_timing_validate(u8 *buf, int buf_size,
if (!timing_done)
return -EINVAL;
- if (!EDID1_INFO_VIDEO_INPUT_DIGITAL(*edid)) {
- debug("%s: Not a digital display\n", __func__);
- return -ENOSYS;
- }
if (edid->version != 1 || edid->revision < 4) {
debug("%s: EDID version %d.%d does not have required info\n",
__func__, edid->version, edid->revision);
--
2.30.1
[PATCH 02/19] video: sunxi: Add mode_valid callback to sunxi_dw_hdmi
Currently driver accepts all resolution which won't work on 4k screens.
Add validation callback which limits acceptable resolutions to 297 MHz.
Signed-off-by: Jernej Skrabec
---
drivers/video/sunxi/sunxi_dw_hdmi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/video/sunxi/sunxi_dw_hdmi.c
b/drivers/video/sunxi/sunxi_dw_hdmi.c
index 0b8cefc311ef..e3811a2ec15f 100644
--- a/drivers/video/sunxi/sunxi_dw_hdmi.c
+++ b/drivers/video/sunxi/sunxi_dw_hdmi.c
@@ -305,6 +305,12 @@ static int sunxi_dw_hdmi_read_edid(struct udevice *dev, u8
*buf, int buf_size)
return dw_hdmi_read_edid(>hdmi, buf, buf_size);
}
+static bool sunxi_dw_hdmi_mode_valid(struct udevice *dev,
+const struct display_timing *timing)
+{
+ return timing->pixelclock.typ <= 29700;
+}
+
static int sunxi_dw_hdmi_enable(struct udevice *dev, int panel_bpp,
const struct display_timing *edid)
{
@@ -388,6 +394,7 @@ static int sunxi_dw_hdmi_probe(struct udevice *dev)
static const struct dm_display_ops sunxi_dw_hdmi_ops = {
.read_edid = sunxi_dw_hdmi_read_edid,
.enable = sunxi_dw_hdmi_enable,
+ .mode_valid = sunxi_dw_hdmi_mode_valid,
};
U_BOOT_DRIVER(sunxi_dw_hdmi) = {
--
2.30.1
[PATCH 01/19] sunxi: video: select dw-hdmi in Kconfig, not Makefile
Currently sunxi Makefile manually specifies full path to dw-hdmi common code. However, that is not needed because it can be selected in Kconfig instead. Select proper symbol in Kconfig and drop path from Makefile. Signed-off-by: Jernej Skrabec --- arch/arm/mach-sunxi/Kconfig | 1 + drivers/video/sunxi/Makefile | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig index 0135575ca1eb..9149196b223e 100644 --- a/arch/arm/mach-sunxi/Kconfig +++ b/arch/arm/mach-sunxi/Kconfig @@ -972,6 +972,7 @@ config VIDEO_DE2 depends on SUNXI_DE2 select DM_VIDEO select DISPLAY + select VIDEO_DW_HDMI imply VIDEO_DT_SIMPLEFB default y ---help--- diff --git a/drivers/video/sunxi/Makefile b/drivers/video/sunxi/Makefile index 147e18799229..4321673312bf 100644 --- a/drivers/video/sunxi/Makefile +++ b/drivers/video/sunxi/Makefile @@ -4,4 +4,4 @@ # Wolfgang Denk, DENX Software Engineering, w...@denx.de. obj-$(CONFIG_VIDEO_SUNXI) += sunxi_display.o simplefb_common.o lcdc.o tve_common.o ../videomodes.o -obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o simplefb_common.o lcdc.o ../dw_hdmi.o sunxi_lcd.o +obj-$(CONFIG_VIDEO_DE2) += sunxi_de2.o sunxi_dw_hdmi.o simplefb_common.o lcdc.o sunxi_lcd.o -- 2.30.1
[PATCH 00/19] video: sunxi: Rework DE2 driver
This series greatly reworks DE2 mixer and accompanying DW-HDMI platform driver. Main goal was to use as many information from device tree as possible and thus removing SoC speficic ifdefs from the code. This was largely accomplished for mixer driver and mostly for HDMI driver. Most of these changes are not user visible. Only improvements relevant to the user are filtering HDMI modes based on pixel clock and searching for additional detailed timings in EDID extension block. This change allows me to use 4k monitor that I have - base EDID block on this monitor holds only 4k@60 detailed timing. Other detailed timings, which are appropriate for HDMI 1.4 controller, are contained in extension block. There is plenty of work to do. TCON handling should go to dedicated driver and clock related code in TCON and DW-HDMI code should be moved to clock drivers. Testing was done only on H3. Best regards, Jernej Jernej Skrabec (19): sunxi: video: select dw-hdmi in Kconfig, not Makefile video: sunxi: Add mode_valid callback to sunxi_dw_hdmi common: edid: check for digital display earlier common: edid: extract code for detailed timing search common: edid: Search for valid timing in extension block video: sunxi: Use DW-HDMI hpd function video: sunxi: Remove check for ddc-i2c-bus property video: sunxi: Remove TV probe from DE2 video: sunxi: de2: switch to public uclass functions video: sunxi: dw-hdmi: probe driver by compatible video: sunxi: dw-hdmi: read address from DT node video: dw-hdmi: modify phy init callback to include full timings video: sunxi: dw-hdmi: move PHY config to appropriate place video: sunxi: dw-hdmi: rework PHY initialization video: sunxi: de2: switch to DT probing video: sunxi: de2: read address from DT node clk: sunxi: Add DE2 clocks to H3 and A64 clk: sunxi: add DE2 clock driver video: sunxi: de2: switch clock setup to DM model arch/arm/mach-sunxi/Kconfig | 2 + common/edid.c | 82 +++-- drivers/clk/sunxi/Kconfig | 5 + drivers/clk/sunxi/Makefile | 1 + drivers/clk/sunxi/clk_a64.c | 6 + drivers/clk/sunxi/clk_de2.c | 85 + drivers/clk/sunxi/clk_h3.c | 6 + drivers/video/dw_hdmi.c | 6 +- drivers/video/meson/meson_dw_hdmi.c | 5 +- drivers/video/sunxi/Makefile| 2 +- drivers/video/sunxi/sunxi_de2.c | 191 +-- drivers/video/sunxi/sunxi_dw_hdmi.c | 498 ++-- include/dw_hdmi.h | 4 +- 13 files changed, 570 insertions(+), 323 deletions(-) create mode 100644 drivers/clk/sunxi/clk_de2.c -- 2.30.1
Re: [PATCH 0/2] Fix MIPS/Malta target and its IDE work
On 2/23/21 7:06 PM, Daniel Schwierzeck wrote:
Am Dienstag, den 23.02.2021, 15:19 +0100 schrieb Reinoud Zandijk:
Hi Daniel,
On Tue, Feb 23, 2021 at 01:03:05AM +0100, Daniel Schwierzeck wrote:
Am Montag, den 22.02.2021, 20:56 +0100 schrieb Reinoud Zandijk:
If I remove it, the machine just spins in Qemu, no output,
nothing.
If I add
it, it works fine again. I found out by bisecting. I have no idea
why
the
tests aren't picking this up. Could it be a qemu/gcc/binutils
combination
issue? A symbol not set as expected?
qemu 5.1.0
gcc 8.3.0
binutils 2.32
which board config did you try exactly? malta or maltael?
Both malta and maltael have the same behaviour. And yeah, for maltael
i needed
the u-boot-swap.bin indeed! That was not that obvious at first but
trial and
error showed it.
How are the tests performed? Are the actual u-boot images passed as
compiled
with `-bios' to qemu and that alone? Or are the tests also sneaking
in the FDT
to qemu? By f.e. appending them?
we use the images as built by the default configs. We don't use "-bios"
but "-drive if=pflash,file=${U_BOOT_BUILD_DIR}/flash.img,format=raw" to
emulate NOR flash and to be closer to hardware.
flash.img is created with that script:
https://gitlab.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/flash.qemu_gen_padded_image
Hello Daniel,
thanks for pointing out how the Gitlab CI test is run.
This looks a bit different to doc/board/emulation/qemu-mips.rst where
'-pflash flash' is used as argument.
Do you want to update the man-page to use -drive instead of -pflash?
Best regards
Heinrich
[PATCH 1/1] efi_loader: limit output length for VenHw, VenMedia
VenHw and VenMedia device path nodes may carry vendor defined data of
arbitrary length. When converting a device path node to text ensure that we
do not overrun our internal buffer.
In our implementation of
EFI_DEVICE_PATH_TO_TEXT_PROTOCOL.ConvertDevicePathToText() we could first
determine the output length and then allocate buffers but that would nearly
double the code size. Therefore keep the preallocated buffers and truncate
excessive device paths instead.
Signed-off-by: Heinrich Schuchardt
---
lib/efi_loader/efi_device_path_to_text.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/lib/efi_loader/efi_device_path_to_text.c
b/lib/efi_loader/efi_device_path_to_text.c
index 81b8ac23ba..ba1ad33459 100644
--- a/lib/efi_loader/efi_device_path_to_text.c
+++ b/lib/efi_loader/efi_device_path_to_text.c
@@ -67,7 +67,8 @@ static char *dp_hardware(char *s, struct efi_device_path *dp)
s += sprintf(s, "VenHw(%pUl", >guid);
n = (int)vdp->dp.length - sizeof(struct efi_device_path_vendor);
- if (n > 0) {
+ /* Node must fit into MAX_NODE_LEN) */
+ if (n > 0 && n < MAX_NODE_LEN / 2 - 22) {
s += sprintf(s, ",");
for (i = 0; i < n; ++i)
s += sprintf(s, "%02x", vdp->vendor_data[i]);
@@ -251,7 +252,8 @@ static char *dp_media(char *s, struct efi_device_path *dp)
s += sprintf(s, "VenMedia(%pUl", >guid);
n = (int)vdp->dp.length - sizeof(struct efi_device_path_vendor);
- if (n > 0) {
+ /* Node must fit into MAX_NODE_LEN) */
+ if (n > 0 && n < MAX_NODE_LEN / 2 - 24) {
s += sprintf(s, ",");
for (i = 0; i < n; ++i)
s += sprintf(s, "%02x", vdp->vendor_data[i]);
--
2.30.0
Re: [RFC PATCH 1/2] net: dsa: return early if there is no master
I think you can also be more aggressive and remove the checks: if (!master) return -EINVAL; from dsa_port_send and dsa_port_recv. At least it sounds broken to me that this could ever happen. The following comment got me curious: /* * stop master only if it's active, don't probe it otherwise. * Under normal usage it would be active because we're using it, but * during tear-down it may have been removed ahead of us. */ if (master && device_active(master)) eth_get_ops(master)->stop(master); Do we actually care about device removal? I don't think it will work right now. If you do "unbind eth 0" and then using a DSA port you'll get a panic. The check for master doesn't really help here because it will return "priv->master_dev" which is just set in .pre_probe(). Thus in the error case, it will contain a dangling pointer. -michael
Re: [RFC PATCH 2/2] net: dsa: probe master device
Am 2021-02-23 17:19, schrieb Michael Walle:
DSA needs to have the master device probed first for MAC inheritance.
Until now, it only works by chance because the only user (LS1028A SoC)
will probe the master device first. The probe order is given by the PCI
device ordering, thus it works because the master device has a
"smaller"
BDF then the switch device.
Explicitly probe the master device in dsa_port_probe().
Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
Signed-off-by: Michael Walle
---
net/dsa-uclass.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 88a8ea9352..242e2be035 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -284,6 +284,14 @@ static int dsa_port_probe(struct udevice *pdev)
if (!master)
return -ENODEV;
+ /*
+* Probe the master device. We depend on the master device for proper
+* operation and we also need it for MAC inheritance below.
+*/
+ ret = device_probe(master);
btw, there is a "int ret" missing above. Will be fixed in the non-RFC
version.
+ if (ret)
+ return ret;
+
/*
* Inherit port's hwaddr from the DSA master, unless the port already
* has a unique MAC address specified in the environment.
--
-michael
Re: Broken build on OpenBSD
On 2/23/21 1:07 PM, Mark Kettenis wrote: Hi Simon, Commit c5819701a3de61e2ba2ef7ad0b616565b32305e5 broke the build on OpenBSD and probably other non-Linux systems. ENODATA, which is now used in fit_check_format(), isn't defined. It isn't part of POSIX[1] and generally not available on BSD-derived systems. Could you pick another error code for this case? Hi Mark, I looked at the commit you mentioned, and I think it's fundamentally broken. The errors represent -EINVAL, and trying to assign different error codes doesn't make sense. "Wrong FIT format: no images parent node": -ENOENT "No such file or directory". This just doesn't make sense. We obviously have the file data at this point, and we know the data is wrong. This should be -EINVAL. "Wrong FIT format: no description": -ENOMSG "No message of desired type". Again, this doesn't make sense. We're not dealing with messaging APIs or send()/recv(). I think this should be -EINVAL. "Wrong FIT format: not a flattened device tree": -ENOEXEC "Exec format error" This one is amusing, as it's comparing a flattened devicetree to an executable. An FDT might have executable code, which is in the wrong format, but this is not why we're failing here. Simon, I'd suggest using the correct error code, which, for each case is -EINVAL, as the log messages also confirm: "Wrong [input value] format". We might have issues with the "configurations", an "@" in a signature name, and so forth. There just aren't enough error codes to cover the set of possible failures. And in any case, there likely can't be a reasonable 1:1 mapping to _distinct_ errno codes. Does any user even check the error code beyond "less than zero"? Take different decisions based on what the negative code indicates? If information as to what is wrong with the input value (FIT) is needed, then I'd suggest using a separate enum, and stick to -EINVAL. Alex
Broken build on OpenBSD
Hi Simon, Commit c5819701a3de61e2ba2ef7ad0b616565b32305e5 broke the build on OpenBSD and probably other non-Linux systems. ENODATA, which is now used in fit_check_format(), isn't defined. It isn't part of POSIX[1] and generally not available on BSD-derived systems. Could you pick another error code for this case? Thanks, Mark [1] It is mentioned in the Open Group Base Specification, however it is part of the obsolete XSI STREAMS extension which was never part of POSIX proper.
Re: [PATCH] button: adc: fix treshold typo
On 23.02.2021 16:10, Neil Armstrong wrote:
> Fix the treshold typo in code by threshold.
>
> Fixes: c0165c85c3 ("button: add a simple Analog to Digital Converter device
> based button driver")
> Suggested-by: Tom Rini
> Signed-off-by: Neil Armstrong
Acked-by: Marek Szyprowski
> ---
> drivers/button/button-adc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
> index eed86564fb..fd896c76f9 100644
> --- a/drivers/button/button-adc.c
> +++ b/drivers/button/button-adc.c
> @@ -55,7 +55,7 @@ static int button_adc_of_to_plat(struct udevice *dev)
> struct button_uc_plat *uc_plat = dev_get_uclass_plat(dev);
> struct button_adc_priv *priv = dev_get_priv(dev);
> struct ofnode_phandle_args args;
> - u32 treshold, up_treshold, t;
> + u32 threshold, up_threshold, t;
> ofnode node;
> int ret;
>
> @@ -73,12 +73,12 @@ static int button_adc_of_to_plat(struct udevice *dev)
> return ret;
>
> ret = ofnode_read_u32(dev_ofnode(dev->parent),
> - "keyup-threshold-microvolt", _treshold);
> + "keyup-threshold-microvolt", _threshold);
> if (ret)
> return ret;
>
> ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
> - );
> + );
> if (ret)
> return ret;
>
> @@ -87,13 +87,13 @@ static int button_adc_of_to_plat(struct udevice *dev)
> if (ret)
> return ret;
>
> - if (t > treshold)
> - up_treshold = t;
> + if (t > threshold)
> + up_threshold = t;
> }
>
> priv->channel = args.args[0];
> - priv->min = treshold;
> - priv->max = up_treshold;
> + priv->min = threshold;
> + priv->max = up_threshold;
>
> return ret;
> }
Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland
Re: [PATCH 0/2] Fix MIPS/Malta target and its IDE work
Am Dienstag, den 23.02.2021, 15:19 +0100 schrieb Reinoud Zandijk:
> Hi Daniel,
>
> On Tue, Feb 23, 2021 at 01:03:05AM +0100, Daniel Schwierzeck wrote:
> > Am Montag, den 22.02.2021, 20:56 +0100 schrieb Reinoud Zandijk:
> > > If I remove it, the machine just spins in Qemu, no output,
> > > nothing.
> > > If I add
> > > it, it works fine again. I found out by bisecting. I have no idea
> > > why
> > > the
> > > tests aren't picking this up. Could it be a qemu/gcc/binutils
> > > combination
> > > issue? A symbol not set as expected?
> > >
> > > qemu 5.1.0
> > > gcc 8.3.0
> > > binutils 2.32
> > >
> >
> > which board config did you try exactly? malta or maltael?
>
> Both malta and maltael have the same behaviour. And yeah, for maltael
> i needed
> the u-boot-swap.bin indeed! That was not that obvious at first but
> trial and
> error showed it.
>
> How are the tests performed? Are the actual u-boot images passed as
> compiled
> with `-bios' to qemu and that alone? Or are the tests also sneaking
> in the FDT
> to qemu? By f.e. appending them?
we use the images as built by the default configs. We don't use "-bios"
but "-drive if=pflash,file=${U_BOOT_BUILD_DIR}/flash.img,format=raw" to
emulate NOR flash and to be closer to hardware.
flash.img is created with that script:
https://gitlab.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/flash.qemu_gen_padded_image
--
- Daniel
Re: [PATCH 16/25] arm: Remove gwventana boards
On Mon, Feb 22, 2021 at 9:40 AM Tom Rini wrote:
>
> On Mon, Feb 22, 2021 at 09:24:22AM -0800, Tim Harvey wrote:
> > On Wed, Feb 17, 2021 at 10:35 AM Tom Rini wrote:
> > >
> > > On Wed, Feb 17, 2021 at 10:26:20AM -0800, Tim Harvey wrote:
> > > > On Wed, Feb 10, 2021 at 9:31 AM Tom Rini wrote:
> > > > >
> > > > > On Wed, Feb 10, 2021 at 09:29:44AM -0800, Tim Harvey wrote:
> > > > > > On Tue, Feb 9, 2021 at 5:03 AM Tom Rini wrote:
> > > > > > >
> > > > > > > These boards have not been converted to CONFIG_DM_MMC by the
> > > > > > > deadline of
> > > > > > > v2019.04, which is almost two years ago. In addition there are
> > > > > > > other DM
> > > > > > > migrations it is also missing. Remove them.
> > > > > > >
> > > > > > > Cc: Tim Harvey
> > > > > > > Signed-off-by: Tom Rini
> > > > > > > ---
> > > > > > > arch/arm/mach-imx/mx6/Kconfig |1 -
> > > > > > > board/gateworks/gw_ventana/Kconfig | 28 -
> > > > > > > board/gateworks/gw_ventana/MAINTAINERS |8 -
> > > > > > > board/gateworks/gw_ventana/Makefile | 11 -
> > > > > > > board/gateworks/gw_ventana/README | 320
> > > > > > > board/gateworks/gw_ventana/common.c | 1760
> > > > > > > ---
> > > > > > > board/gateworks/gw_ventana/common.h | 99 --
> > > > > > > board/gateworks/gw_ventana/eeprom.c | 266 ---
> > > > > > > board/gateworks/gw_ventana/gsc.c| 283 ---
> > > > > > > board/gateworks/gw_ventana/gsc.h| 71 -
> > > > > > > board/gateworks/gw_ventana/gw_ventana.c | 1381
> > > > > > > ---
> > > > > > > board/gateworks/gw_ventana/gw_ventana_spl.c | 779
> > > > > > > board/gateworks/gw_ventana/ventana_eeprom.h | 140 --
> > > > > > > configs/gwventana_emmc_defconfig| 111 --
> > > > > > > configs/gwventana_gw5904_defconfig | 115 --
> > > > > > > configs/gwventana_nand_defconfig| 115 --
> > > > > > > include/configs/gw_ventana.h| 298
> > > > > > > 17 files changed, 5786 deletions(-)
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/Kconfig
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/MAINTAINERS
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/Makefile
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/README
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/common.c
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/common.h
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/eeprom.c
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/gsc.c
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/gsc.h
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/gw_ventana.c
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/gw_ventana_spl.c
> > > > > > > delete mode 100644 board/gateworks/gw_ventana/ventana_eeprom.h
> > > > > > > delete mode 100644 configs/gwventana_emmc_defconfig
> > > > > > > delete mode 100644 configs/gwventana_gw5904_defconfig
> > > > > > > delete mode 100644 configs/gwventana_nand_defconfig
> > > > > > > delete mode 100644 include/configs/gw_ventana.h
> > > > > > >
> > > > > >
> > > > > > Tom,
> > > > > >
> > > > > > I will submit a patchset to convert the gw_ventana IMX6 based boards
> > > > > > to DM. I started this effort over a year ago and got stuck at some
> > > > > > point but I think I know how to get through that now.
> > > > > >
> > > > > > I hope to be able to submit something by the end of next week.
> > > > >
> > > > > Thanks! Their conversion will help unblock a few of the older
> > > > > migrations.
> > > >
> > > > Tom / Stefano,
> > > >
> > > > Looking at this again I realize where I got stuck previously trying to
> > > > migrate the Gateworks Ventana support to driver-model.
> > >
> > > Thanks for digging in and summarizing.
> > >
> > > > 1. I need MULTI_DTB_FIT for raw NAND and the following issues are
> > > > blocking me:
> > > > a. spl_nand_fit_read() requires the reads to be page-aligned to the
> > > > writesize of the NAND device. I have to work through trying to give
> > > > the common nand spl code knowledge of the mtd device to get around
> > > > this.
> > > > b. spl_nand_fit_read() since 9f6a14c47ff9 ("spl: fit: nand: fix fit
> > > > loading in case of bad blocks") which introduces bad block handling
> > > > now requires a lot of static defines describing the NAND chip such as
> > > > CONFIG_SYS_NAND_BLOCK_SIZE CONFIG_SYS_NAND_BAD_BLOCK_POS and a few
> > > > more that I need to get from mtd as well as we support multiple flash
> > > > devices that have different geometries. I can wrap that code around an
> > > > 'ifdef CONFIG_SYS_NAND_BLOCK_SIZE' to opt out of that feature.
> > >
> > > Which is all SPL related, right? It seems so, but to be clear...
> > >
> >
> > Yes, both issues above are with regards to imx SPL+FIT+NAND.
> > Ironically if I could use
[PATCH 1/2 v4] efi: Add ESRT to the EFI system table
The ESRT is initialised during efi_init_objlist after
efi_initialize_system_table().
The ESRT is recreated from scratch at the following events:
- successful UpdateCapsule;
- FMP instance install.
The code ensures that every ESRT entry has a unique fw_class value.
Limitations:
- The ESRT is not updated when an FMP instance is uninstalled;
- the fields image_type and flags are currently set to UNKNOWN and 0
respectively. The mapping between fw_class and the image_type/flags
fields is platform specific. A mapping function is lacking from the
current implementation but should be added in the future.
Signed-off-by: Jose Marinho
CC: Heinrich Schuchardt
CC: Sughosh Ganu
CC: AKASHI Takahiro
CC: Ilias Apalodimas
CC: Andre Przywara
CC: Alexander Graf
CC: n...@arm.com
---
cmd/efidebug.c | 4 +
include/efi_api.h| 21 ++
include/efi_loader.h | 20 ++
lib/efi_loader/Kconfig | 7 +
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_capsule.c | 8 +
lib/efi_loader/efi_esrt.c| 518 +++
lib/efi_loader/efi_setup.c | 6 +
8 files changed, 585 insertions(+)
create mode 100644 lib/efi_loader/efi_esrt.c
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index bbbcb0a546..a7dace2f80 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -459,6 +459,10 @@ static const struct {
"Block IO",
EFI_BLOCK_IO_PROTOCOL_GUID,
},
+ {
+ "EFI System Resource Table",
+ EFI_SYSTEM_RESOURCE_TABLE_GUID,
+ },
{
"Simple File System",
EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID,
diff --git a/include/efi_api.h b/include/efi_api.h
index 48e48a6263..fb53637419 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -1722,6 +1722,23 @@ struct efi_load_file_protocol {
void *buffer);
};
+struct efi_system_resource_entry {
+ efi_guid_t fw_class;
+ u32 fw_type;
+ u32 fw_version;
+ u32 lowest_supported_fw_version;
+ u32 capsule_flags;
+ u32 last_attempt_version;
+ u32 last_attempt_status;
+} __packed;
+
+struct efi_system_resource_table {
+ u32 fw_resource_count;
+ u32 fw_resource_count_max;
+ u64 fw_resource_version;
+ struct efi_system_resource_entry entries[];
+} __packed;
+
/* Boot manager load options */
#define LOAD_OPTION_ACTIVE 0x0001
#define LOAD_OPTION_FORCE_RECONNECT0x0002
@@ -1740,6 +1757,10 @@ struct efi_load_file_protocol {
#define ESRT_FW_TYPE_DEVICEFIRMWARE0x0002
#define ESRT_FW_TYPE_UEFIDRIVER0x0003
+#define EFI_SYSTEM_RESOURCE_TABLE_GUID\
+ EFI_GUID(0xb122a263, 0x3661, 0x4f68,\
+ 0x99, 0x29, 0x78, 0xf8, 0xb0, 0xd6, 0x21, 0x80)
+
/* Last Attempt Status Values */
#define LAST_ATTEMPT_STATUS_SUCCESS0x
#define LAST_ATTEMPT_STATUS_ERROR_UNSUCCESSFUL 0x0001
diff --git a/include/efi_loader.h b/include/efi_loader.h
index f470bbd636..c2720f2823 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -214,6 +214,8 @@ extern const efi_guid_t efi_guid_rng_protocol;
extern const efi_guid_t efi_guid_capsule_report;
/* GUID of firmware management protocol */
extern const efi_guid_t efi_guid_firmware_management_protocol;
+/* GUID for the ESRT */
+extern const efi_guid_t efi_esrt_guid;
extern unsigned int __efi_runtime_start, __efi_runtime_stop;
extern unsigned int __efi_runtime_rel_start, __efi_runtime_rel_stop;
@@ -884,4 +886,22 @@ static inline efi_status_t efi_launch_capsules(void)
#endif /* CONFIG_IS_ENABLED(EFI_LOADER) */
+/**
+ * Install the ESRT system table.
+ *
+ * @return status code
+ */
+efi_status_t efi_esrt_register(void);
+
+/**
+ * efi_esrt_populate() - Populates the ESRT entries from the FMP instances
+ * present in the system.
+ * If an ESRT already exists, the old ESRT is replaced in the system table.
+ * The memory of the old ESRT is deallocated.
+ *
+ * Return:
+ * - EFI_SUCCESS if the ESRT is correctly created
+ * - error code otherwise.
+ */
+efi_status_t efi_esrt_populate(void);
#endif /* _EFI_LOADER_H */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index e729f727df..a96014ce18 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -347,4 +347,11 @@ config EFI_SECURE_BOOT
it is signed with a trusted key. To do that, you need to install,
at least, PK, KEK and db.
+config EFI_ESRT
+ bool "Enable the UEFI ESRT generation"
+ depends on EFI_CAPSULE_FIRMWARE_MANAGEMENT
+ default y
+ help
+ Enabling this option creates the ESRT UEFI system table.
+
endif
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index 10b42e8847..9a8127846f 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -52,6 +52,7 @@ obj-y += efi_variable.o
obj-$(CONFIG_EFI_VARIABLES_PRESEED) +=
[PATCH 2/2 v4] efi: ESRT creation tests
This commmit exercises the ESRT creation -- introduced in the previous
commit -- in two tests.
test 1:
A fake FMP, with TEST_ESRT_NUM_ENTRIES FW images, is installed in the
system leading to the corresponding ESRT entries being populated.
The ESRT entries are checked against the datastructure used to
initialize the FMP.
test 1 invocation:
make sandbox_capsule_defconfig all
./u-boot -d arch/sandbox/dts/test.dtb
ut lib
test 2:
The test is part of test_efi_capsule_fw3.
In order to run the test the following must be added to
sandbox_defconfig:
+CONFIG_CMD_SF=y
+CONFIG_CMD_MEMORY=y
+CONFIG_CMD_FAT=y
+CONFIG_DFU=y
The ESRT is printed in the u-boot shell by calling efidebug esrt.
The test ensures that, after the capsule is installed, the ESRT
contains entries with the GUIDs:
- EFI_FIRMWARE_IMAGE_TYPE_UBOOT_FIT_GUID;
- EFI_FIRMWARE_IMAGE_TYPE_UBOOT_RAW_GUID;
test 2 invocation:
sudo ./test/py/test.py --bd sandbox -k capsule_fw3 -l --build
Signed-off-by: Jose Marinho
CC: Heinrich Schuchardt
CC: Sughosh Ganu
CC: AKASHI Takahiro
CC: Ilias Apalodimas
CC: Andre Przywara
CC: Alexander Graf
CC: n...@arm.com
---
cmd/efidebug.c| 64 ++
test/lib/Makefile | 1 +
test/lib/efi_esrt.c | 191 ++
.../test_efi_capsule/test_capsule_firmware.py | 4 +
4 files changed, 260 insertions(+)
create mode 100644 test/lib/efi_esrt.c
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index a7dace2f80..5a9ff2bd9a 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -129,6 +129,61 @@ static int do_efi_capsule_show(struct cmd_tbl *cmdtp, int
flag,
return CMD_RET_SUCCESS;
}
+#ifdef CONFIG_EFI_ESRT
+/**
+ * do_efi_capsule_esrt() - manage UEFI capsules
+ *
+ * @cmdtp: Command table
+ * @flag: Command flag
+ * @argc: Number of arguments
+ * @argv: Argument array
+ * Return: CMD_RET_SUCCESS on success,
+ * CMD_RET_USAGE or CMD_RET_RET_FAILURE on failure
+ *
+ * Implement efidebug "capsule esrt" sub-command.
+ * The prints the current ESRT table.
+ *
+ * efidebug capsule esrt
+ */
+static int do_efi_capsule_esrt(struct cmd_tbl *cmdtp, int flag,
+ int argc, char * const argv[])
+{
+ struct efi_system_resource_table *esrt = NULL;
+
+ if (argc != 1)
+ return CMD_RET_USAGE;
+
+ for (int idx = 0; idx < systab.nr_tables; idx++)
+ if (!guidcmp(_esrt_guid, [idx].guid))
+ esrt = (struct efi_system_resource_table
*)systab.tables[idx].table;
+
+ if (!esrt)
+ return CMD_RET_FAILURE;
+
+ printf("\n");
+ printf("ESRT: fw_resource_count=%d\n", esrt->fw_resource_count);
+ printf("ESRT: fw_resource_count_max=%d\n", esrt->fw_resource_count_max);
+ printf("ESRT: fw_resource_version=%lld\n", esrt->fw_resource_version);
+
+ for (int idx = 0; idx < esrt->fw_resource_count; idx++) {
+ printf("[entry %d]==\n", idx);
+ printf("ESRT: fw_class=%pUL\n", >entries[idx].fw_class);
+ printf("ESRT: fw_type=%d\n", esrt->entries[idx].fw_type);
+ printf("ESRT: fw_version=%d\n", esrt->entries[idx].fw_version);
+ printf("ESRT: lowest_supported_fw_version=%d\n",
+ esrt->entries[idx].lowest_supported_fw_version);
+ printf("ESRT: capsule_flags=%d\n",
+ esrt->entries[idx].capsule_flags);
+ printf("ESRT: last_attempt_version=%d\n",
+ esrt->entries[idx].last_attempt_version);
+ printf("ESRT: last_attempt_status=%d\n",
+ esrt->entries[idx].last_attempt_status);
+ }
+ printf("\n");
+
+ return CMD_RET_SUCCESS;
+}
+#endif /* CONFIG_EFI_ESRT */
/**
* do_efi_capsule_res() - show a capsule update result
*
@@ -221,6 +276,10 @@ static struct cmd_tbl cmd_efidebug_capsule_sub[] = {
"", ""),
U_BOOT_CMD_MKENT(show, CONFIG_SYS_MAXARGS, 1, do_efi_capsule_show,
"", ""),
+#ifdef CONFIG_EFI_ESRT
+ U_BOOT_CMD_MKENT(esrt, CONFIG_SYS_MAXARGS, 1, do_efi_capsule_esrt,
+"", ""),
+#endif
U_BOOT_CMD_MKENT(disk-update, 0, 0, do_efi_capsule_on_disk_update,
"", ""),
U_BOOT_CMD_MKENT(result, CONFIG_SYS_MAXARGS, 1, do_efi_capsule_res,
@@ -256,6 +315,7 @@ static int do_efi_capsule(struct cmd_tbl *cmdtp, int flag,
return cp->cmd(cmdtp, flag, argc, argv);
}
+
#endif /* CONFIG_EFI_HAVE_CAPSULE_SUPPORT */
/**
@@ -1580,6 +1640,10 @@ static char efidebug_help_text[] =
" - show capsule information\n"
"efidebug capsule result []\n"
" - show a capsule update result\n"
+#ifdef CONFIG_EFI_ESRT
+
[PATCH 0/2 v4] Add ESRT and test ESRT creation
The following 2 commits add the ESRT and provide a test of the functionality. The first commit adds the ESRT as defined in the UEFI 2.8 specification. An empty ESRT is created during the execution of the efi_init_obj_list(). The ESRT is updated when: 1) a FMP protocol is installed in the system: this will add the corresponding entries to the ESRT. 2) a capsule is installed via UpdateCapsule: this should update entries already present in the ESRT. This implementation of the ESRT creation takes input from FMP only. It is assumed that the FMP will maintain the following values across reboot: - LastAttemptVersion. - LastAttemptStatus. The second commit enables testing the ESRT creation in the sandbox platform. That commit is composed of 2 tests. - Test 1 executes from the u-boot shell with "ut lib". - Test 2 executes in the pytest environment. Patch v4: - update stale [Patch 1/2 v3] commit message. Patch v3: - Address v2 comments. Patch v2: - The ESRT is now regenerated from scratch at every FMP EVT_NOTIFY_SIGNAL and whenever a capsule is updated. - Extended TestEfiCapsuleFirmwareFit::test_efi_capsule_fw3 to verify that the ESRT is correctly populated after an UpdateCapsule. - Addressed v1 comments. Patch v1: - reworked the ESRT creation code, allowing table to resize as FMPs are installed. - registered a callback for the FMP protocol install. - Created a unit test running on the sandbox platform. rfc: initial patch submission CC: Heinrich Schuchardt CC: Sughosh Ganu CC: AKASHI Takahiro CC: Ilias Apalodimas CC: Andre Przywara CC: Alexander Graf CC: n...@arm.com Jose Marinho (2): efi: Add ESRT to the EFI system table efi: ESRT creation tests cmd/efidebug.c| 68 +++ include/efi_api.h | 21 + include/efi_loader.h | 20 + lib/efi_loader/Kconfig| 7 + lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_capsule.c | 8 + lib/efi_loader/efi_esrt.c | 518 ++ lib/efi_loader/efi_setup.c| 6 + test/lib/Makefile | 1 + test/lib/efi_esrt.c | 191 +++ .../test_efi_capsule/test_capsule_firmware.py | 4 + 11 files changed, 845 insertions(+) create mode 100644 lib/efi_loader/efi_esrt.c create mode 100644 test/lib/efi_esrt.c -- 2.17.1
Re: [RFC PATCH 1/2] net: dsa: return early if there is no master
Am 2021-02-23 17:32, schrieb Vladimir Oltean:
On Tue, Feb 23, 2021 at 05:19:05PM +0100, Michael Walle wrote:
It doesn't make sense to have DSA without a master port. Error out
early
if there is no master port.
Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
Signed-off-by: Michael Walle
---
Reviewed-by: Vladimir Oltean
I think you can also be more aggressive and remove the checks:
if (!master)
return -EINVAL;
from dsa_port_send and dsa_port_recv. At least it sounds broken to me
that this could ever happen.
Yep, I've seen these, too. I'll send a non-RFC version and remove these.
-michael
Re: [RFC PATCH 2/2] net: dsa: probe master device
On Tue, Feb 23, 2021 at 05:19:06PM +0100, Michael Walle wrote:
> DSA needs to have the master device probed first for MAC inheritance.
> Until now, it only works by chance because the only user (LS1028A SoC)
> will probe the master device first. The probe order is given by the PCI
> device ordering, thus it works because the master device has a "smaller"
> BDF then the switch device.
>
> Explicitly probe the master device in dsa_port_probe().
>
> Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
> Signed-off-by: Michael Walle
> ---
Reviewed-by: Vladimir Oltean
By the way we had this in the old driver that marinated too much and
never got merged, I am not sure why we removed it during the second
submission process:
https://github.com/openil/u-boot/commit/2544ed8051d3dce55b12e13b6c2b476733d19c05
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On Tue, Feb 23, 2021 at 05:15:49PM +0100, Heinrich Schuchardt wrote: > On 2/23/21 5:03 PM, Tom Rini wrote: > > On Tue, Feb 23, 2021 at 04:54:45PM +0100, Heinrich Schuchardt wrote: > > > Am 23. Februar 2021 15:53:38 MEZ schrieb Tom Rini : > > > > On Tue, Feb 23, 2021 at 01:59:52PM +0100, Heinrich Schuchardt wrote: > > > > > On 23.02.21 12:43, Asherah Connor wrote: > > > > > > Updates the QFW driver to use the driver model, and adds support > > > > for QFW > > > > > > on Arm platforms by configuring from the device tree and using MMIO > > > > > > accordingly. A sandbox driver for QFW is also included, and a > > > > simple DM > > > > > > unit test for it. > > > > > > > > > > For which architectures does the fw_cfg device exist? > > > > > > > > > > It it is only ARM and X86, than I am missing such a dependency on > > > > > CONFIG_CMD_QFW. > > > > > > > > The qemu 'qfw' interface is I believe a generic QEMU thing and a > > > > generic > > > > U-Boot cleanup would be to have a common QEMU symbol for everyone to > > > > select. > > > > > > qemu-system-riscv64 does not allow me to specify a file for the qfw > > > interface. > > > > Really? It's listed under the help (taken from out docker images): > > $ /opt/qemu/bin/qemu-system-riscv64 --help > > ... > > Debug/Expert options: > > -fw_cfg [name=],file= > > add named fw_cfg entry with contents from file > > -fw_cfg [name=],string= > > add named fw_cfg entry with contents from string > > > > The man-page is shared by all qemu-system-*. It is not architecture > specific. That is why it shows items like: "PS/2 mouse and keyboard". > > qemu-system-riscv64 (v5.0.0) has no fw_cfg device: > > $ qemu-system-riscv64 -machine virt -m 1G -nographic -bios u-boot > -fw_cfg opt/foo,file=foo > qemu-system-riscv64: -fw_cfg opt/foo,file=foo: fw_cfg device not available > > qemu-system-aarch64 does not complain: > > $ qemu-system-aarch64 -machine virt -m 1G -nographic -bios u-boot > -fw_cfg opt/foo,file=foo So all that's missing is someone hooking that up inside qemu itself. I'm pretty sure it works on PowerPC, from when I was trying to figure out how to pass something in to qemu-ppce500 a while ago. qemu-system-mips/sh4 don't complain. -- Tom signature.asc Description: PGP signature
Re: [RFC PATCH 1/2] net: dsa: return early if there is no master
On Tue, Feb 23, 2021 at 05:19:05PM +0100, Michael Walle wrote:
> It doesn't make sense to have DSA without a master port. Error out early
> if there is no master port.
>
> Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
> Signed-off-by: Michael Walle
> ---
Reviewed-by: Vladimir Oltean
I think you can also be more aggressive and remove the checks:
if (!master)
return -EINVAL;
from dsa_port_send and dsa_port_recv. At least it sounds broken to me
that this could ever happen.
Re: [PATCH] Makefile: Add target to generate hex output for combined spl and dtb
On Tue, Feb 23, 2021 at 07:00:47AM +, Lim, Elly Siew Chin wrote:
> Hi Tom,
>
> > -Original Message-
> > From: Tom Rini
> > Sent: Saturday, February 20, 2021 5:02 AM
> > To: Lim, Elly Siew Chin
> > Cc: u-boot@lists.denx.de; Marek Vasut ; Tan, Ley Foon
> > ; See, Chin Liang ; Simon
> > Goldschmidt ; Chee, Tien Fong
> > ; Westergreen, Dalon
> > ; Simon Glass ; Gan, Yau
> > Wai
> > Subject: Re: [PATCH] Makefile: Add target to generate hex output for
> > combined
> > spl and dtb
> >
> > On Fri, Feb 19, 2021 at 01:55:44PM +0800, Siew Chin Lim wrote:
> >
> > > From: Dalon Westergreen
> > >
> > > Some architectures, Stratix10/Agilex, require a hex formatted spl that
> > > combines the spl image and dtb. This adds a target to create said hex
> > > file with and offset of SPL_TEXT_BASE.
> > >
> > > Signed-off-by: Dalon Westergreen
> > > Signed-off-by: Siew Chin Lim
> > > ---
> > > Makefile | 11 ++-
> > > include/configs/socfpga_soc64_common.h | 2 +-
> > > scripts/Makefile.spl | 8
> > > 3 files changed, 15 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/Makefile b/Makefile
> > > index 4da46dea39..f1adc9aa23 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1263,11 +1263,6 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
> > > $(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
> > > $(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -
> > R .resetvec)
> > >
> > > -OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-boot.hex)
> > > -
> > > -spl/u-boot-spl.hex: spl/u-boot-spl FORCE
> > > - $(call if_changed,objcopy)
> > > -
> > > binary_size_check: u-boot-nodtb.bin FORCE
> > > @file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
> > > map_size=$(shell cat u-boot.map | \
> > > @@ -1935,6 +1930,12 @@ spl/u-boot-spl.bin: spl/u-boot-spl
> > > @:
> > > $(SPL_SIZE_CHECK)
> > >
> > > +spl/u-boot-spl-dtb.bin: spl/u-boot-spl
> > > + @:
> > > +
> > > +spl/u-boot-spl-dtb.hex: spl/u-boot-spl
> > > + @:
> > > +
> > > spl/u-boot-spl: tools prepare \
> > > $(if
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA
> > ),dts/dt.dtb) \
> > > $(if
> > >
> > $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA
> > ),dts/d
> > > t.dtb) diff --git a/include/configs/socfpga_soc64_common.h
> > > b/include/configs/socfpga_soc64_common.h
> > > index fdcd7d3e9a..1af359466c 100644
> > > --- a/include/configs/socfpga_soc64_common.h
> > > +++ b/include/configs/socfpga_soc64_common.h
> > > @@ -200,7 +200,7 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
> > > * 0x8000_ .. End of SDRAM_1 (assume 2GB)
> > > *
> > > */
> > > -#define CONFIG_SPL_TARGET"spl/u-boot-spl.hex"
> > > +#define CONFIG_SPL_TARGET"spl/u-boot-spl-dtb.hex"
> > > #define CONFIG_SPL_MAX_SIZE CONFIG_SYS_INIT_RAM_SIZE
> > > #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
> > > #define CONFIG_SPL_BSS_MAX_SIZE 0x10/* 1 MB */
> > > diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl index
> > > ea4e045769..625e06d0d9 100644
> > > --- a/scripts/Makefile.spl
> > > +++ b/scripts/Makefile.spl
> > > @@ -229,6 +229,9 @@ ifneq
> > ($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),)
> > > INPUTS-y += $(obj)/$(SPL_BIN).sfp
> > > endif
> > >
> > > +INPUTS-$(CONFIG_TARGET_SOCFPGA_STRATIX10)+= $(obj)/u-boot-spl-
> > dtb.hex
> > > +INPUTS-$(CONFIG_TARGET_SOCFPGA_AGILEX) += $(obj)/u-
> > boot-spl-dtb.hex
> > > +
> > > ifdef CONFIG_ARCH_SUNXI
> > > INPUTS-y += $(obj)/sunxi-spl.bin
> > >
> > > @@ -389,6 +392,11 @@ $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin
> > > FORCE MKIMAGEFLAGS_sunxi-spl.bin = -T sunxi_egon \
> > > -n $(CONFIG_DEFAULT_DEVICE_TREE)
> > >
> > > +OBJCOPYFLAGS_u-boot-spl-dtb.hex := -I binary -O ihex
> > > +--change-address=$(CONFIG_SPL_TEXT_BASE)
> > > +
> > > +$(obj)/u-boot-spl-dtb.hex: $(obj)/u-boot-spl-dtb.bin FORCE
> > > + $(call if_changed,objcopy)
> > > +
> > > $(obj)/sunxi-spl.bin: $(obj)/$(SPL_BIN).bin FORCE
> > > $(call if_changed,mkimage)
> >
> > The commit message / subject doesn't make it clear that you're doing
> > something for SoCFPGA here, and I seem to recall this change being proposed
> > a
> > while ago and it wasn't clear that this is really the best default path
> > forward I
> > thought?
> >
>
> Noted. I will resend the patch and enhance the message / subject .
>
> I have checked again with the team about this, we still would like to
> generate the 'u-boot-spl-dtb.hex' for socfpga soc64 devices by default during
> u-boot compilation which is always needed by customer to generate the final
> configuration bitstream.
> Can you please advise if this is not the right way for the implementation?
I think the changes are fine then, please just update the commit
message, thanks!
--
Tom
signature.asc
Description: PGP
[RFC PATCH 2/2] net: dsa: probe master device
DSA needs to have the master device probed first for MAC inheritance.
Until now, it only works by chance because the only user (LS1028A SoC)
will probe the master device first. The probe order is given by the PCI
device ordering, thus it works because the master device has a "smaller"
BDF then the switch device.
Explicitly probe the master device in dsa_port_probe().
Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
Signed-off-by: Michael Walle
---
net/dsa-uclass.c | 8
1 file changed, 8 insertions(+)
diff --git a/net/dsa-uclass.c b/net/dsa-uclass.c
index 88a8ea9352..242e2be035 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -284,6 +284,14 @@ static int dsa_port_probe(struct udevice *pdev)
if (!master)
return -ENODEV;
+ /*
+* Probe the master device. We depend on the master device for proper
+* operation and we also need it for MAC inheritance below.
+*/
+ ret = device_probe(master);
+ if (ret)
+ return ret;
+
/*
* Inherit port's hwaddr from the DSA master, unless the port already
* has a unique MAC address specified in the environment.
--
2.20.1
[RFC PATCH 0/2] net: dsa: various fixes
Before a DSA port is probed, the master port needs to be probed first. For
now this worked, because the probing order was correct. But it already
falls short if you use the enetc6 port on the LS1028A SoC:
Device tree snippet:
{
status = "okay";
};
_felix_port5 {
ethernet = <>;
status = "okay";
};
NB. keep enetc2 enabled, otherwise you will trigger an access violation.
Michael Walle (2):
net: dsa: return early if there is no master
net: dsa: probe master device
net/dsa-uclass.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
--
2.20.1
[RFC PATCH 1/2] net: dsa: return early if there is no master
It doesn't make sense to have DSA without a master port. Error out early
if there is no master port.
Fixes: fc054d563bfb ("net: Introduce DSA class for Ethernet switches")
Signed-off-by: Michael Walle
---
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 2ce9ddb90d..88a8ea9352 100644
--- a/net/dsa-uclass.c
+++ b/net/dsa-uclass.c
@@ -280,6 +280,10 @@ static int dsa_port_probe(struct udevice *pdev)
if (!port_pdata->phy)
return -ENODEV;
+ master = dsa_get_master(dev);
+ if (!master)
+ return -ENODEV;
+
/*
* Inherit port's hwaddr from the DSA master, unless the port already
* has a unique MAC address specified in the environment.
@@ -288,10 +292,6 @@ static int dsa_port_probe(struct udevice *pdev)
if (!is_zero_ethaddr(env_enetaddr))
return 0;
- master = dsa_get_master(dev);
- if (!master)
- return 0;
-
master_pdata = dev_get_plat(master);
eth_pdata = dev_get_plat(pdev);
memcpy(eth_pdata->enetaddr, master_pdata->enetaddr, ARP_HLEN);
--
2.20.1
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On 2/23/21 5:03 PM, Tom Rini wrote: On Tue, Feb 23, 2021 at 04:54:45PM +0100, Heinrich Schuchardt wrote: Am 23. Februar 2021 15:53:38 MEZ schrieb Tom Rini : On Tue, Feb 23, 2021 at 01:59:52PM +0100, Heinrich Schuchardt wrote: On 23.02.21 12:43, Asherah Connor wrote: Updates the QFW driver to use the driver model, and adds support for QFW on Arm platforms by configuring from the device tree and using MMIO accordingly. A sandbox driver for QFW is also included, and a simple DM unit test for it. For which architectures does the fw_cfg device exist? It it is only ARM and X86, than I am missing such a dependency on CONFIG_CMD_QFW. The qemu 'qfw' interface is I believe a generic QEMU thing and a generic U-Boot cleanup would be to have a common QEMU symbol for everyone to select. qemu-system-riscv64 does not allow me to specify a file for the qfw interface. Really? It's listed under the help (taken from out docker images): $ /opt/qemu/bin/qemu-system-riscv64 --help ... Debug/Expert options: -fw_cfg [name=],file= add named fw_cfg entry with contents from file -fw_cfg [name=],string= add named fw_cfg entry with contents from string The man-page is shared by all qemu-system-*. It is not architecture specific. That is why it shows items like: "PS/2 mouse and keyboard". qemu-system-riscv64 (v5.0.0) has no fw_cfg device: $ qemu-system-riscv64 -machine virt -m 1G -nographic -bios u-boot -fw_cfg opt/foo,file=foo qemu-system-riscv64: -fw_cfg opt/foo,file=foo: fw_cfg device not available qemu-system-aarch64 does not complain: $ qemu-system-aarch64 -machine virt -m 1G -nographic -bios u-boot -fw_cfg opt/foo,file=foo Best regards Heinrich
[scan-ad...@coverity.com: New Defects reported by Coverity Scan for Das U-Boot]
- Forwarded message from scan-ad...@coverity.com -
Date: Mon, 22 Feb 2021 16:03:35 + (UTC)
From: scan-ad...@coverity.com
To: tom.r...@gmail.com
Subject: New Defects reported by Coverity Scan for Das U-Boot
Hi,
Please find the latest report on new defect(s) introduced to Das U-Boot found
with Coverity Scan.
3 new defect(s) introduced to Das U-Boot found with Coverity Scan.
1 defect(s), reported by Coverity Scan earlier, were marked fixed in the recent
build analyzed by Coverity Scan.
New defect(s) Reported-by: Coverity Scan
Showing 3 of 3 defect(s)
** CID 320541:(UNREACHABLE)
/common/fdt_support.c: 1403 in fdt_get_dma_range()
/common/fdt_support.c: 1394 in fdt_get_dma_range()
*** CID 320541:(UNREACHABLE)
/common/fdt_support.c: 1403 in fdt_get_dma_range()
1397bus_node = of_match_bus(blob, parent);
1398bus_node->count_cells(blob, parent, , );
1399if (!OF_CHECK_COUNTS(pna, pns)) {
1400printf("%s: Bad cell count for %s\n", __FUNCTION__,
1401 fdt_get_name(blob, parent, NULL));
1402return -EINVAL;
>>> CID 320541:(UNREACHABLE)
>>> This code cannot be reached: "goto out;".
1403goto out;
1404}
1405
1406*bus = fdt_read_number(ranges, na);
1407*cpu = fdt_translate_dma_address(blob, node, ranges + na);
1408*size = fdt_read_number(ranges + na + pna, ns);
/common/fdt_support.c: 1394 in fdt_get_dma_range()
1388bus_node = of_match_bus(blob, node);
1389bus_node->count_cells(blob, node, , );
1390if (!OF_CHECK_COUNTS(na, ns)) {
1391printf("%s: Bad cell count for %s\n", __FUNCTION__,
1392 fdt_get_name(blob, node, NULL));
1393return -EINVAL;
>>> CID 320541:(UNREACHABLE)
>>> This code cannot be reached: "goto out;".
1394goto out;
1395}
1396
1397bus_node = of_match_bus(blob, parent);
1398bus_node->count_cells(blob, parent, , );
1399if (!OF_CHECK_COUNTS(pna, pns)) {
** CID 320540: Null pointer dereferences (REVERSE_INULL)
/lib/efi_loader/efi_device_path_to_text.c: 372 in
efi_convert_device_path_to_text()
*** CID 320540: Null pointer dereferences (REVERSE_INULL)
/lib/efi_loader/efi_device_path_to_text.c: 372 in
efi_convert_device_path_to_text()
366 char *str = buffer;
367
368 EFI_ENTRY("%p, %d, %d", device_path, display_only,
allow_shortcuts);
369
370 if (!device_path)
371 goto out;
>>> CID 320540: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "device_path" suggests that it may be null, but it has
>>> already been dereferenced on all paths leading to the check.
372 while (device_path && str + MAX_NODE_LEN < buffer +
MAX_PATH_LEN) {
373 if (device_path->type == DEVICE_PATH_TYPE_END) {
374 if (device_path->sub_type !=
375 DEVICE_PATH_SUB_TYPE_INSTANCE_END)
376 break;
377 *str++ = ',';
** CID 320539:(UNREACHABLE)
/drivers/core/of_addr.c: 376 in of_get_dma_range()
/drivers/core/of_addr.c: 384 in of_get_dma_range()
*** CID 320539:(UNREACHABLE)
/drivers/core/of_addr.c: 376 in of_get_dma_range()
370 /* Get the address sizes both for the bus and its parent */
371 bus_node = of_match_bus((struct device_node*)dev);
372 bus_node->count_cells(dev, , );
373 if (!OF_CHECK_COUNTS(na, ns)) {
374 printf("Bad cell count for %s\n",
of_node_full_name(dev));
375 return -EINVAL;
>>> CID 320539:(UNREACHABLE)
>>> This code cannot be reached: "goto out_parent;".
376 goto out_parent;
377 }
378
379 bus_node = of_match_bus(parent);
380 bus_node->count_cells(parent, , );
381 if (!OF_CHECK_COUNTS(pna, pns)) {
/drivers/core/of_addr.c: 384 in of_get_dma_range()
378
379 bus_node = of_match_bus(parent);
380 bus_node->count_cells(parent, , );
381 if (!OF_CHECK_COUNTS(pna, pns)) {
382 printf("Bad cell count for %s\n",
of_node_full_name(parent));
383 return -EINVAL;
>>> CID 320539:(UNREACHABLE)
>>> This code cannot be reached: "goto out_parent;".
384 goto out_parent;
385 }
386
387 *bus
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On Tue, Feb 23, 2021 at 04:54:45PM +0100, Heinrich Schuchardt wrote: > Am 23. Februar 2021 15:53:38 MEZ schrieb Tom Rini : > >On Tue, Feb 23, 2021 at 01:59:52PM +0100, Heinrich Schuchardt wrote: > >> On 23.02.21 12:43, Asherah Connor wrote: > >> > Updates the QFW driver to use the driver model, and adds support > >for QFW > >> > on Arm platforms by configuring from the device tree and using MMIO > >> > accordingly. A sandbox driver for QFW is also included, and a > >simple DM > >> > unit test for it. > >> > >> For which architectures does the fw_cfg device exist? > >> > >> It it is only ARM and X86, than I am missing such a dependency on > >> CONFIG_CMD_QFW. > > > >The qemu 'qfw' interface is I believe a generic QEMU thing and a > >generic > >U-Boot cleanup would be to have a common QEMU symbol for everyone to > >select. > > qemu-system-riscv64 does not allow me to specify a file for the qfw interface. Really? It's listed under the help (taken from out docker images): $ /opt/qemu/bin/qemu-system-riscv64 --help ... Debug/Expert options: -fw_cfg [name=],file= add named fw_cfg entry with contents from file -fw_cfg [name=],string= add named fw_cfg entry with contents from string -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 4/4] qemu: add sandbox driver and tests
On Tue, 23 Feb 2021 at 06:44, Asherah Connor wrote: > > We minimally exercise the sandbox driver. > > Signed-off-by: Asherah Connor > --- > > (no changes since v1) > > arch/sandbox/dts/sandbox.dtsi | 4 ++ > arch/sandbox/dts/test.dts | 4 ++ > drivers/misc/Makefile | 11 ++- > drivers/misc/qfw_sandbox.c| 129 ++ > test/dm/Makefile | 1 + > test/dm/qfw.c | 42 +++ > 6 files changed, 185 insertions(+), 6 deletions(-) > create mode 100644 drivers/misc/qfw_sandbox.c > create mode 100644 test/dm/qfw.c Reviewed-by: Simon Glass
Re: [PATCH v3 2/4] arm: x86: qemu: add UCLASS_QFW, split driver into _pio and _mmio
Hi Asherah,
On Tue, 23 Feb 2021 at 06:44, Asherah Connor wrote:
>
> Split the qfw driver into qfw_pio and qfw_mmio, under their own uclass.
> Each driver does arch/platform-specific I/O.
>
> Signed-off-by: Asherah Connor
> ---
>
> Changes in v3:
> - Add new UCLASS_QFW, split qfw driver into PIO and MMIO variants.
> - QFW no longer depends on or selects MISC.
>
> arch/x86/cpu/qemu/cpu.c | 2 +-
> arch/x86/cpu/qemu/qemu.c | 18 ++-
> arch/x86/cpu/qfw_cpu.c | 2 +-
> cmd/qfw.c| 26 ++--
> common/Makefile | 2 +
> common/qfw.c | 111
> drivers/misc/Kconfig | 1 -
> drivers/misc/Makefile| 6 +
> drivers/misc/qfw.c | 270 ++-
> drivers/misc/qfw_mmio.c | 101 +++
> drivers/misc/qfw_pio.c | 66 ++
> include/dm/uclass-id.h | 1 +
> include/qfw.h| 45 +--
> 13 files changed, 382 insertions(+), 269 deletions(-)
> create mode 100644 common/qfw.c
> create mode 100644 drivers/misc/qfw_mmio.c
> create mode 100644 drivers/misc/qfw_pio.c
>
[..]
> diff --git a/include/qfw.h b/include/qfw.h
> index f9c6828841..d7e16651a2 100644
> --- a/include/qfw.h
> +++ b/include/qfw.h
> @@ -149,28 +149,49 @@ struct qfw_mmio {
> u64 dma;
> };
>
> -struct qfw_plat {
> - /* MMIO used on Arm. */
> +struct qfw_pio_plat {
> + u16 control_port;
> + u16 data_port;
> + u16 dma_port_low;
> + u16 dma_port_high;
> +};
> +
> +struct qfw_mmio_plat {
> volatile struct qfw_mmio *mmio;
> - /* IO used on x86. */
> - struct {
> - u16 control_port;
> - u16 data_port;
> - u16 dma_port_low;
> - u16 dma_port_high;
> - } io;
> };
>
> +struct qfw_dma {
> + __be32 control;
> + __be32 length;
> + __be64 address;
> +};
> +
> +struct qfw_dev {
> + struct udevice *dev;
> + bool dma_present;
> + struct list_head fw_list;
> +};
> +
> +struct dm_qfw_ops {
comment struct and methods. See other uclasses for how this is done.
> + void (*read_entry_io)(struct udevice *dev, u16 entry, u32 size,
> + void *address);
> + void (*read_entry_dma)(struct udevice *dev, struct qfw_dma *dma);
> +};
> +
> +#define dm_qfw_get_ops(dev) \
> + ((struct dm_qfw_ops *)(dev)->driver->ops)
> +
> +int qfw_register(struct udevice *dev);
> +
> struct udevice;
> /**
> * Get QEMU firmware config device
> *
> * @return struct udevice * if present, NULL otherwise
> */
> -struct udevice *qemu_fwcfg_dev(void);
> +struct udevice *qfw_get_dev(void);
The problem with this function is that you drop the error number. Can
you instead do something like:
int qfw_get_dev(struct udevice **devp)
>
> -void qemu_fwcfg_read_entry(struct udevice *dev, u16 entry, u32 length,
> - void *address);
> +void qfw_read_entry(struct udevice *dev, u16 entry, u32 length, void
> *address);
Could you please add full function/struct comments to the things you
modify in the header file? That way people can read the API in one
place.
I'm not sure if it is easy to split up your patches a bit more. It is
often tricky with a DM conversion.
Regards,
Simon
Re: [PATCH] common: Add "ifndef __ASSEMBLY__" in asm/global_data.h
On Tue, 23 Feb 2021 at 01:34, Siew Chin Lim wrote: > > Commit "common: Drop asm/global_data.h from common header" added > asm/global_data.h into secure.h. However, secure.h will be included > by psci.S. Adding asm/global_data.h has caused compilation failure in > pcsi.S. Add "ifndef __ASSEMBLY__" in asm/global_data.h. > > Signed-off-by: Siew Chin Lim > --- > arch/arm/include/asm/global_data.h | 4 > 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass
Re: [PATCH v2 1/2] Re-embed the FDTs for the Malta targets.
Hi Reinoud, On Tue, 23 Feb 2021 at 09:37, Reinoud Zandijk wrote: > > On Mon, Feb 22, 2021 at 06:04:03PM -0500, Tom Rini wrote: > > On Mon, Feb 22, 2021 at 10:20:12PM +0100, Reinoud Zandijk wrote: > > > > > Re-enable FDT inclusion into the Malta u-boot binary to make them boot > > > again. This could indicate an unwanted toolchain version dependency. > > > > > > Signed-off-by: Reinoud Zandijk > > > > It would probably help to see how you're invoking qemu without this > > change such that it fails. Thanks! > > My bad! I must have issued it wrong or picked the wrong u-boot.bin. Removing > the patch and invoking it as > > qemu-system-mips -snapshot -M malta -m 256M -s -S -bios > /usr/sources/u-boot/u-boot.bin -serial > mon:telnet:127.0.0.1:2223,server,wait -nographic -hda > work/disk-mips64-malta.fs -net nic -net tap,ifname=tap0,script=no > > works OK! this was a red herring; i'll retract it. I must have used the wrong > u-boot result image without the fdt all this time :-/ DOH! OK great! It sounds like there might be some missing docs here, to prevent others hitting this problem. > > Thanks for pointing it out. > Reinoud > Regards, Simon
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
Am 23. Februar 2021 15:53:38 MEZ schrieb Tom Rini : >On Tue, Feb 23, 2021 at 01:59:52PM +0100, Heinrich Schuchardt wrote: >> On 23.02.21 12:43, Asherah Connor wrote: >> > Updates the QFW driver to use the driver model, and adds support >for QFW >> > on Arm platforms by configuring from the device tree and using MMIO >> > accordingly. A sandbox driver for QFW is also included, and a >simple DM >> > unit test for it. >> >> For which architectures does the fw_cfg device exist? >> >> It it is only ARM and X86, than I am missing such a dependency on >> CONFIG_CMD_QFW. > >The qemu 'qfw' interface is I believe a generic QEMU thing and a >generic >U-Boot cleanup would be to have a common QEMU symbol for everyone to >select. qemu-system-riscv64 does not allow me to specify a file for the qfw interface. Best regards Heinrich
[GIT PULL] xilinx patches for v2021.04-rc3
Hi Tom,
please pull these changes to your tree. The major part were clock issues
we found for ZynqMP and Versal in some PM cases where u-boot didn't ask
for enabling clocks. And that's why drivers are shared we also had to
add clock enable function for Zynq to pass.
There are some other fixes especially ZynqMP one for DTB selection.
I can't see any issue from gitlab CI.
Thanks,
Michal
The following changes since commit fdcb93e1709ab1a2ebb562455621617c29e2099c:
Merge branch '2021-02-01-assorted-fixes' (2021-02-02 09:24:10 -0500)
are available in the Git repository at:
g...@gitlab.denx.de:u-boot/custodians/u-boot-microblaze.git
tags/xilinx-for-v2021.04-rc3
for you to fetch changes up to d9aa19efa8a6c20d51b7884de0a7f8dae3f835d2:
spi: zynqmp_gqspi: fix set_speed bug on multiple runs (2021-02-23
14:56:59 +0100)
Xilinx changes for v2021.04-rc3
qspi:
- Support for dual/quad mode
- Fix speed handling
clk:
- Add clock enable function for zynq/zynqmp/versal
gem:
- Enable clock for Versal
- Fix error path
- Fix mdio deregistration path
fpga:
- Fix buffer alignment for ZynqMP
xilinx:
- Fix reset reason clearing in ZynqMP
- Show silicon version in SPL for Zynq/ZynqMP
- Fix DTB selection for ZynqMP
- Rename zc1275 to zcu1275 to match DT name
Brandon Maier (2):
spi: zynqmp_gqspi: support dual and quad mode
spi: zynqmp_gqspi: fix set_speed bug on multiple runs
Michael Walle (2):
net: gem: unregister mdio bus if probe fails
fpga: zynqpl: fix buffer alignment
Michal Simek (6):
xilinx: common: Fix CONFIG_XILINX_OF_BOARD_DTB_ADDR handling for
ZynqMP
xilinx: Show silicon version in SPL
arm64: zynqmp: Do not clear reset reason
clk: zynq: Add dummy clock enable function
net: gem: Fix error path in zynq_gem_probe
arm64: zynqmp: Rename zc1275/zcu1275 to be aligned with DT name
T Karthik Reddy (4):
clk: zynqmp: Add support to enable clocks
clk: versal: Add support to enable clocks
i2c: i2c_cdns: Enable i2c clock
net: gem: Enable ethernet rx clock for versal
arch/arm/mach-zynqmp/include/mach/hardware.h
| 4 +--
board/xilinx/common/board.c
| 2 +-
board/xilinx/zynq/board.c
| 3 ++
board/xilinx/zynqmp/{zynqmp-zc1275-revA => zynqmp-zcu1275-revA}
| 0
board/xilinx/zynqmp/{zynqmp-zc1275-revB =>
zynqmp-zcu1275-revB}/psu_init_gpl.c | 0
board/xilinx/zynqmp/zynqmp.c
| 7 ++---
drivers/clk/clk_versal.c
| 11
drivers/clk/clk_zynq.c
| 10 +++
drivers/clk/clk_zynqmp.c
| 49
drivers/fpga/zynqpl.c
| 2 +-
drivers/i2c/i2c-cdns.c
| 7 +
drivers/mmc/zynq_sdhci.c
| 2 +-
drivers/net/zynq_gem.c
| 47 +++
drivers/serial/serial_zynq.c
| 2 +-
drivers/spi/zynq_qspi.c
| 2 +-
drivers/spi/zynq_spi.c
| 2 +-
drivers/spi/zynqmp_gqspi.c
| 189
++--
drivers/watchdog/xilinx_wwdt.c
| 3 +-
18 files changed, 208 insertions(+), 134 deletions(-)
rename board/xilinx/zynqmp/{zynqmp-zc1275-revA => zynqmp-zcu1275-revA}
(100%)
rename board/xilinx/zynqmp/{zynqmp-zc1275-revB =>
zynqmp-zcu1275-revB}/psu_init_gpl.c (100%)
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [EXT] USB3 XHCI crashing with USB 3 hub on Octeon
On 23.02.21 14:57, Aaron Williams wrote: I am using the latest pull and it's still crashing. Now that I have a (free) USB 3 hub I can reproduce this issue. With latest TOT I get this: => usb start starting USB... Bus xhci@16800: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus xhci@16900: Register 2000140 NbrPorts 2 Starting the controller USB XHCI 1.00 scanning bus xhci@16800 for devices... Warning: asix_eth MAC addresses don't match: Address in ROM is 00:0e:c6:b2:7e:cb Address in environment is 02:3f:73:97:d1:00 2 USB Device(s) found scanning bus xhci@16900 for devices... Device not responding to set address. USB device not accepting new address (error=8000) WARN halted endpoint, queueing URB anyway. Unexpected XHCI event TRB, skipping... (0eebc260 1300 01008401) BUG at drivers/usb/host/xhci-ring.c:503/abort_td()! BUG! resetting ... As Aaron already mentioned, this only happens when an USB 3 hub is present in the setup. I'll try to dig into this tomorrow but perhaps someone else has some quick ideas? Thanks, Stefan -Aaron On Tuesday, February 23, 2021 2:39:41 AM PST Stefan Roese wrote: On 23.02.21 11:36, Mark Kettenis wrote: From: Nicolas Saenz Julienne Date: Tue, 23 Feb 2021 10:23:04 +0100 On Tue, 2021-02-23 at 09:15 +0100, Stefan Roese wrote: Hi Bin, Hi Aaron, I've added Nicolas to Cc, as he also recently did some work on the physical vs virtual addresses in the xHCI driver. On 23.02.21 09:07, Bin Meng wrote: Hi Aaron, On Tue, Feb 23, 2021 at 3:31 PM Aaron Williams wrote: I have a follow-up. USB is working on our OcteonTX boards running 2020.10. It may be something specific to the Octeon port. Note that I did see a problem where the scratchpad memory is using direct pointers instead of physical addresses (which will not work on MIPS). As far as I know, however, the Octeon XHCI controller does not use the scratchpad memory. Do you plan to send a patch to convert the scratchpad pointer to physical address? Nicolas, did your patch also address the scratchpad area (sorry for not looking myself). Yes, my patch took care of that :). Ah cool. I missed that patch. Looks like this is exactly what I need to cater for the translation done by the IOMMU on the Apple M1. Won't be sending that patch then ;) Nice. Aaron, it might be that you missed this patch series with your latest mainline xHCI tests a few days ago. Could you please try again with current mainline and report back, if this changes the behavior on Octeon MIPS with USB3 hubs? Thanks, Stefan Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH] button: adc: fix treshold typo
Fix the treshold typo in code by threshold.
Fixes: c0165c85c3 ("button: add a simple Analog to Digital Converter device
based button driver")
Suggested-by: Tom Rini
Signed-off-by: Neil Armstrong
---
drivers/button/button-adc.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/button/button-adc.c b/drivers/button/button-adc.c
index eed86564fb..fd896c76f9 100644
--- a/drivers/button/button-adc.c
+++ b/drivers/button/button-adc.c
@@ -55,7 +55,7 @@ static int button_adc_of_to_plat(struct udevice *dev)
struct button_uc_plat *uc_plat = dev_get_uclass_plat(dev);
struct button_adc_priv *priv = dev_get_priv(dev);
struct ofnode_phandle_args args;
- u32 treshold, up_treshold, t;
+ u32 threshold, up_threshold, t;
ofnode node;
int ret;
@@ -73,12 +73,12 @@ static int button_adc_of_to_plat(struct udevice *dev)
return ret;
ret = ofnode_read_u32(dev_ofnode(dev->parent),
- "keyup-threshold-microvolt", _treshold);
+ "keyup-threshold-microvolt", _threshold);
if (ret)
return ret;
ret = ofnode_read_u32(dev_ofnode(dev), "press-threshold-microvolt",
- );
+ );
if (ret)
return ret;
@@ -87,13 +87,13 @@ static int button_adc_of_to_plat(struct udevice *dev)
if (ret)
return ret;
- if (t > treshold)
- up_treshold = t;
+ if (t > threshold)
+ up_threshold = t;
}
priv->channel = args.args[0];
- priv->min = treshold;
- priv->max = up_treshold;
+ priv->min = threshold;
+ priv->max = up_threshold;
return ret;
}
--
2.25.1
Re: rk3399-gru-kevin: issues on bringup
Hi Marty, On Thu, 13 Aug 2020 at 13:35, Alper Nebi Yasak wrote: > > Hi Simon, Marty, > > I'm interested in getting U-Boot to work with Kevin as well, but don't > have a Servo (or the willingness to open up the case yet), so I've been > trying to boot from depthcharge as in README.chromium-chainload. > > I don't have a way to see serial output and I see no other signs of > life. Can you give me a tested configuration that immediately powers-off > or reboots a Kevin so I can confirm what I'm doing works on the > chainloading side? I mean I can boot Linux, but trying the same with > U-Boot just gives me a blank screen even after accounting for a lot of > things. > > Meanwhile, I've wrote some code to automate making depthcharge partition > images, and to enable the display on Kevin (and perhaps Bob). Since I > don't know if chainloading works, I don't know if these are broken or > not either. I'm unsure about sending untested patches to the list, so I > put them up here if you want to take a look (and maybe test/fix them?): > > https://github.com/alpernebbi/u-boot/tree/rk3399-gru-kevin/wip > > They're not really things that'd make a non-booting Kevin boot, though. > I hope at least some of it can be useful in some way. I am just replying here as you asked for some details on IRC. What details do you need? I was intending to try out a kevin if I have one. I will add that to my list. Regards, Simon
Re: [PATCH 2/2] pinctrl: at91-pio4: add support for slew-rate
Hi Eugen,
On 23.02.2021 11:41, Eugen Hristev - M18282 wrote:
> On 27.01.2021 15:00, Claudiu Beznea wrote:
>> SAMA7G5 supports slew rate configuration. Adapt the driver for this.
>> For switching frequencies lower than 50MHz the slew rate needs to
>> be enabled. Since most of the pins on SAMA7G5 fall into this category
>> enabled the slew rate by default.
>>
>> Signed-off-by: Claudiu Beznea
>> ---
>> arch/arm/mach-at91/include/mach/atmel_pio4.h | 1 +
>> drivers/pinctrl/pinctrl-at91-pio4.c | 26
>> +++---
>> 2 files changed, 24 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm/mach-at91/include/mach/atmel_pio4.h
>> b/arch/arm/mach-at91/include/mach/atmel_pio4.h
>> index 35ac7b2d40e1..c3bd9140dfef 100644
>> --- a/arch/arm/mach-at91/include/mach/atmel_pio4.h
>> +++ b/arch/arm/mach-at91/include/mach/atmel_pio4.h
>> @@ -44,6 +44,7 @@ struct atmel_pio4_port {
>> #define ATMEL_PIO_DIR_MASK BIT(8)
>> #define ATMEL_PIO_PUEN_MASKBIT(9)
>> #define ATMEL_PIO_PDEN_MASKBIT(10)
>> +#define ATMEL_PIO_SRBIT(11)
>> #define ATMEL_PIO_IFEN_MASKBIT(12)
>> #define ATMEL_PIO_IFSCEN_MASK BIT(13)
>> #define ATMEL_PIO_OPD_MASK BIT(14)
>> diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c
>> b/drivers/pinctrl/pinctrl-at91-pio4.c
>> index 3a5143adc381..5c6ece745ab0 100644
>> --- a/drivers/pinctrl/pinctrl-at91-pio4.c
>> +++ b/drivers/pinctrl/pinctrl-at91-pio4.c
>> @@ -24,6 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>
>> struct atmel_pio4_plat {
>> struct atmel_pio4_port *reg_base;
>> +unsigned int slew_rate_support;
>> };
>>
>> static const struct pinconf_param conf_params[] = {
>> @@ -35,9 +36,11 @@ static const struct pinconf_param conf_params[] = {
>> { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
>> { "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
>> { "atmel,drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 0 },
>> +{ "slew-rate", PIN_CONFIG_SLEW_RATE, 0},
> Hi Claudiu,
>
> If slew rate is enabled by default, we should have here 0 or 1 ?
It doesn't matter the value here since the driver is used with versions of
this IP that either support or not this feature. What matters is the value
of priv->slew_rate_support that is set based on the IP version. At the
moment this feature is available only on SAMA7G5. If we would rely on the
value on conf_params we could end-up setting the SR bit for versions of
this IP that doesn't support the SR feature. Please share if you see it
implemented otherwise.
>
>> };
>>
>> -static u32 atmel_pinctrl_get_pinconf(struct udevice *config)
>> +static u32 atmel_pinctrl_get_pinconf(struct udevice *config,
>> + struct atmel_pio4_plat *plat)
>> {
>> const struct pinconf_param *params;
>> u32 param, arg, conf = 0;
>> @@ -52,6 +55,10 @@ static u32 atmel_pinctrl_get_pinconf(struct udevice
>> *config)
>> param = params->param;
>> arg = params->default_value;
>>
>> +/* Keep slew rate enabled by default. */
>> +if (plat->slew_rate_support)
>> +conf |= ATMEL_PIO_SR;
>> +
>> switch (param) {
>> case PIN_CONFIG_BIAS_DISABLE:
>> conf &= (~ATMEL_PIO_PUEN_MASK);
>> @@ -90,6 +97,15 @@ static u32 atmel_pinctrl_get_pinconf(struct udevice
>> *config)
>> conf |= (val << ATMEL_PIO_DRVSTR_OFFSET)
>> & ATMEL_PIO_DRVSTR_MASK;
>> break;
>> +case PIN_CONFIG_SLEW_RATE:
>> +if (!plat->slew_rate_support)
>> +break;
>> +
>> +dev_read_u32(config, params->property, );
>> +/* And disable it if requested. */
>> +if (val == 0)
>> +conf &= ~ATMEL_PIO_SR;
>> +break;
>> default:
>> printf("%s: Unsupported configuration parameter: %u\n",
>> __func__, param);
>> @@ -115,6 +131,7 @@ static inline struct atmel_pio4_port
>> *atmel_pio4_bank_base(struct udevice *dev,
>>
>> static int atmel_pinctrl_set_state(struct udevice *dev, struct udevice
>> *config)
>> {
>> +struct atmel_pio4_plat *plat = dev_get_plat(dev);
>> struct atmel_pio4_port *bank_base;
>> const void *blob = gd->fdt_blob;
>> int node = dev_of_offset(config);
>> @@ -123,7 +140,7 @@ static int atmel_pinctrl_set_state(struct udevice *dev,
>> struct udevice *config)
>> u32 i, conf;
>> int count;
>>
>> -conf = atmel_pinctrl_get_pinconf(config);
>> +conf = atmel_pinctrl_get_pinconf(config, plat);
>>
>> count = fdtdec_get_int_array_count(blob, node, "pinmux",
>> cells, ARRAY_SIZE(cells));
>> @@ -163,6 +180,7 @@ const struct
Re: [PATCH v2 2/2] Fix IDE commands issued, fix endian issues, fix non MMIO
On Mon, Feb 22, 2021 at 10:48:42PM +0100, Heinrich Schuchardt wrote: > On 2/22/21 10:20 PM, Reinoud Zandijk wrote: > > 2) direct pointer access was used to read and write the registers instead > > of the inb/inw/outb/outw functions/macros. Registers don't have to be > > memory mapped and ATA_CURR_BASE() does not have to return an offset from > > address zero. ... > > --- > > drivers/block/ide.c | 149 +--- > > include/ata.h | 2 +- > > 2 files changed, 44 insertions(+), 107 deletions(-) > > > > diff --git a/drivers/block/ide.c b/drivers/block/ide.c > > index 43a0776099..0d1ad33125 100644 > > --- a/drivers/block/ide.c > > +++ b/drivers/block/ide.c > > @@ -130,56 +130,40 @@ OUT: > >* ATAPI Support > >*/ > > > > -#if defined(CONFIG_IDE_SWAP_IO) > > edminiv2_defconfig does not build with this change. Now thats odd! The inw() and outw() macro's seem to have different definitions depending on what architecture you're compiling for! For at least MIPS and m68k , inw() is defined as inw(long unsigned int) but for ARM its defined as inw(short *) ! Now what should it be? Also I could use in_le16() and out_le16() but will they be defined for all architectures? Or should not supporting it be considered a bug on their side? Using uintptr_t seems to satisfy both as its guaranteed to be representing a ptr and an int and GCC isn't even complaining anymore on either platforms. I'll use this one in my next patch version Thanks for the feedback, Reinoud
Re: [PULL u-boot] Please pull u-boot-amlogic-20210223
On 23/02/2021 16:04, Tom Rini wrote: > On Tue, Feb 23, 2021 at 03:58:25PM +0100, Neil Armstrong wrote: > >> Hi Tom, >> >> These changes adds support for reading the ADC key on the Khadas VIM3 & >> VIM3L, in the same >> time it adds plumbing for ADC keys and a test for sandbox. >> This time with s/treshold/threshold/. >> >> The CI job is at >> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/6480 >> >> Thanks, >> Neil >> >> The following changes since commit 496f49464d90b564da5f1a2f4eecb5553e01edf9: >> >> Merge branch '2021-02-16-assorted-improvements' (2021-02-16 15:14:34 -0500) >> >> are available in the Git repository at: >> >> https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git >> tags/u-boot-amlogic-20210223 >> >> for you to fetch changes up to ceeb50b3bf074960ddfa541b7be3732b38e15c99: >> >> button: add udevice forward declaration (2021-02-23 15:55:53 +0100) >> >> >> - adds adc-keys button driver >> - fix meson-saradc driver to get reference voltage >> - add adc-keys test for sandbox >> - enable adc-keys for VIM3 & VIM3L boards >> - fix button.h build > > I applied the PR yesterday, so just an incremental change to fix the > "treshold" thing please, thanks! > oops I misread, pushing asap Neil signature.asc Description: OpenPGP digital signature
Re: [PULL u-boot] Please pull u-boot-amlogic-20210223
On Tue, Feb 23, 2021 at 03:58:25PM +0100, Neil Armstrong wrote: > Hi Tom, > > These changes adds support for reading the ADC key on the Khadas VIM3 & > VIM3L, in the same > time it adds plumbing for ADC keys and a test for sandbox. > This time with s/treshold/threshold/. > > The CI job is at > https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/6480 > > Thanks, > Neil > > The following changes since commit 496f49464d90b564da5f1a2f4eecb5553e01edf9: > > Merge branch '2021-02-16-assorted-improvements' (2021-02-16 15:14:34 -0500) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git > tags/u-boot-amlogic-20210223 > > for you to fetch changes up to ceeb50b3bf074960ddfa541b7be3732b38e15c99: > > button: add udevice forward declaration (2021-02-23 15:55:53 +0100) > > > - adds adc-keys button driver > - fix meson-saradc driver to get reference voltage > - add adc-keys test for sandbox > - enable adc-keys for VIM3 & VIM3L boards > - fix button.h build I applied the PR yesterday, so just an incremental change to fix the "treshold" thing please, thanks! -- Tom signature.asc Description: PGP signature
[PULL u-boot] Please pull u-boot-amlogic-20210223
Hi Tom, These changes adds support for reading the ADC key on the Khadas VIM3 & VIM3L, in the same time it adds plumbing for ADC keys and a test for sandbox. This time with s/treshold/threshold/. The CI job is at https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic/pipelines/6480 Thanks, Neil The following changes since commit 496f49464d90b564da5f1a2f4eecb5553e01edf9: Merge branch '2021-02-16-assorted-improvements' (2021-02-16 15:14:34 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-amlogic.git tags/u-boot-amlogic-20210223 for you to fetch changes up to ceeb50b3bf074960ddfa541b7be3732b38e15c99: button: add udevice forward declaration (2021-02-23 15:55:53 +0100) - adds adc-keys button driver - fix meson-saradc driver to get reference voltage - add adc-keys test for sandbox - enable adc-keys for VIM3 & VIM3L boards - fix button.h build Marek Szyprowski (5): dt-bindings: input: adc-keys bindings documentation button: add a simple Analog to Digital Converter device based button driver adc: meson-saradc: add support for getting reference voltage value configs: khadas-vim3(l): enable Function button support test: add a simple test for the adc-keys button driver Neil Armstrong (1): button: add udevice forward declaration arch/sandbox/dts/test.dts | 28 +- configs/khadas-vim3_defconfig | 2 + configs/khadas-vim3l_defconfig | 2 + configs/sandbox_defconfig | 1 + doc/device-tree-bindings/input/adc-keys.txt | 67 + drivers/adc/meson-saradc.c | 21 drivers/button/Kconfig | 8 ++ drivers/button/Makefile | 1 + drivers/button/button-adc.c | 146 include/button.h| 2 + test/dm/button.c| 50 +- 11 files changed, 325 insertions(+), 3 deletions(-) create mode 100644 doc/device-tree-bindings/input/adc-keys.txt create mode 100644 drivers/button/button-adc.c
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On Tue, Feb 23, 2021 at 01:59:52PM +0100, Heinrich Schuchardt wrote: > On 23.02.21 12:43, Asherah Connor wrote: > > Updates the QFW driver to use the driver model, and adds support for QFW > > on Arm platforms by configuring from the device tree and using MMIO > > accordingly. A sandbox driver for QFW is also included, and a simple DM > > unit test for it. > > For which architectures does the fw_cfg device exist? > > It it is only ARM and X86, than I am missing such a dependency on > CONFIG_CMD_QFW. The qemu 'qfw' interface is I believe a generic QEMU thing and a generic U-Boot cleanup would be to have a common QEMU symbol for everyone to select. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 1/2] Re-embed the FDTs for the Malta targets.
On Mon, Feb 22, 2021 at 06:04:03PM -0500, Tom Rini wrote: > On Mon, Feb 22, 2021 at 10:20:12PM +0100, Reinoud Zandijk wrote: > > > Re-enable FDT inclusion into the Malta u-boot binary to make them boot > > again. This could indicate an unwanted toolchain version dependency. > > > > Signed-off-by: Reinoud Zandijk > > It would probably help to see how you're invoking qemu without this > change such that it fails. Thanks! My bad! I must have issued it wrong or picked the wrong u-boot.bin. Removing the patch and invoking it as qemu-system-mips -snapshot -M malta -m 256M -s -S -bios /usr/sources/u-boot/u-boot.bin -serial mon:telnet:127.0.0.1:2223,server,wait -nographic -hda work/disk-mips64-malta.fs -net nic -net tap,ifname=tap0,script=no works OK! this was a red herring; i'll retract it. I must have used the wrong u-boot result image without the fdt all this time :-/ DOH! Thanks for pointing it out. Reinoud
Re: [PATCH 0/2] Fix MIPS/Malta target and its IDE work
On Tue, Feb 23, 2021 at 09:26:56AM -0500, Tom Rini wrote: > On Tue, Feb 23, 2021 at 03:19:06PM +0100, Reinoud Zandijk wrote: > > Hi Daniel, > > > > On Tue, Feb 23, 2021 at 01:03:05AM +0100, Daniel Schwierzeck wrote: > > > Am Montag, den 22.02.2021, 20:56 +0100 schrieb Reinoud Zandijk: > > > > If I remove it, the machine just spins in Qemu, no output, nothing. > > > > If I add > > > > it, it works fine again. I found out by bisecting. I have no idea why > > > > the > > > > tests aren't picking this up. Could it be a qemu/gcc/binutils > > > > combination > > > > issue? A symbol not set as expected? > > > > > > > > qemu 5.1.0 > > > > gcc 8.3.0 > > > > binutils 2.32 > > > > > > > > > > which board config did you try exactly? malta or maltael? > > > > Both malta and maltael have the same behaviour. And yeah, for maltael i > > needed > > the u-boot-swap.bin indeed! That was not that obvious at first but trial and > > error showed it. > > > > How are the tests performed? Are the actual u-boot images passed as compiled > > with `-bios' to qemu and that alone? Or are the tests also sneaking in the > > FDT > > to qemu? By f.e. appending them? Could the CONFIG_SYS_MALLOC_CLEAR_ON_INIT > > warning/error prevented a good build? I also get that with > > edminib2_defconfig > > so I assumed some work is still in progress on that. > > > > > [1] > > > https://gitlab.denx.de/u-boot/u-boot-test-hooks/-blob/master/bin/travis-ci/conf.maltael_qemu > > > > This is behind a login? > > Unintentionally so, yes. Fixing this now. Ah! A typo that gets fixed up automatically if logged in, but not otherwise: https://gitlab.denx.de/u-boot/u-boot-test-hooks/-/blob/master/bin/travis-ci/conf.maltael_qemu is right (note the '/' after '-' before 'blob'). -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/2] Fix MIPS/Malta target and its IDE work
On Tue, Feb 23, 2021 at 03:19:06PM +0100, Reinoud Zandijk wrote: > Hi Daniel, > > On Tue, Feb 23, 2021 at 01:03:05AM +0100, Daniel Schwierzeck wrote: > > Am Montag, den 22.02.2021, 20:56 +0100 schrieb Reinoud Zandijk: > > > If I remove it, the machine just spins in Qemu, no output, nothing. > > > If I add > > > it, it works fine again. I found out by bisecting. I have no idea why > > > the > > > tests aren't picking this up. Could it be a qemu/gcc/binutils > > > combination > > > issue? A symbol not set as expected? > > > > > > qemu 5.1.0 > > > gcc 8.3.0 > > > binutils 2.32 > > > > > > > which board config did you try exactly? malta or maltael? > > Both malta and maltael have the same behaviour. And yeah, for maltael i needed > the u-boot-swap.bin indeed! That was not that obvious at first but trial and > error showed it. > > How are the tests performed? Are the actual u-boot images passed as compiled > with `-bios' to qemu and that alone? Or are the tests also sneaking in the FDT > to qemu? By f.e. appending them? Could the CONFIG_SYS_MALLOC_CLEAR_ON_INIT > warning/error prevented a good build? I also get that with edminib2_defconfig > so I assumed some work is still in progress on that. > > > [1] > > https://gitlab.denx.de/u-boot/u-boot-test-hooks/-blob/master/bin/travis-ci/conf.maltael_qemu > > This is behind a login? Unintentionally so, yes. Fixing this now. -- Tom signature.asc Description: PGP signature
Re: [PATCH 0/2] Fix MIPS/Malta target and its IDE work
Hi Daniel, On Tue, Feb 23, 2021 at 01:03:05AM +0100, Daniel Schwierzeck wrote: > Am Montag, den 22.02.2021, 20:56 +0100 schrieb Reinoud Zandijk: > > If I remove it, the machine just spins in Qemu, no output, nothing. > > If I add > > it, it works fine again. I found out by bisecting. I have no idea why > > the > > tests aren't picking this up. Could it be a qemu/gcc/binutils > > combination > > issue? A symbol not set as expected? > > > > qemu 5.1.0 > > gcc 8.3.0 > > binutils 2.32 > > > > which board config did you try exactly? malta or maltael? Both malta and maltael have the same behaviour. And yeah, for maltael i needed the u-boot-swap.bin indeed! That was not that obvious at first but trial and error showed it. How are the tests performed? Are the actual u-boot images passed as compiled with `-bios' to qemu and that alone? Or are the tests also sneaking in the FDT to qemu? By f.e. appending them? Could the CONFIG_SYS_MALLOC_CLEAR_ON_INIT warning/error prevented a good build? I also get that with edminib2_defconfig so I assumed some work is still in progress on that. > [1] > https://gitlab.denx.de/u-boot/u-boot-test-hooks/-blob/master/bin/travis-ci/conf.maltael_qemu This is behind a login? Reinoud
Re: [PATCH 08/10] sun5i: add support for DIP detection to CHIP board
Hello Andre,
On Tue, 23 Feb 2021 13:30:38 +
Andre Przywara wrote:
y extension_board_scan board specific function, would you prefer if I
> > move to callback like below instead of Kconfig?
> >
> > if (of_machine_is_compatible("nextthing,chip"))
> > extension_board_register_callback(chip_extension_board_scan);
>
> Well, the CHIP Pro uses a different compatible string, so you would
> need to check for that too.
> I am not fully decided if checking for the machine compatible is the
> right approach. The more traditional U-Boot way would be to define a
> config symbol (as Tom already pointed out), that would also keep the
> code out of other board builds.
> We do this already with CONFIG_PINE64_DT_SELECTION and
> CONFIG_PINEPHONE_DT_SELECTION.
Okay, I will move on to the traditional config symbol.
Thanks.
Köry
Re: [EXT] USB3 XHCI crashing with USB 3 hub on Octeon
I am using the latest pull and it's still crashing. -Aaron On Tuesday, February 23, 2021 2:39:41 AM PST Stefan Roese wrote: > On 23.02.21 11:36, Mark Kettenis wrote: > >> From: Nicolas Saenz Julienne > >> Date: Tue, 23 Feb 2021 10:23:04 +0100 > >> > >> On Tue, 2021-02-23 at 09:15 +0100, Stefan Roese wrote: > >>> Hi Bin, > >>> Hi Aaron, > >>> > >>> I've added Nicolas to Cc, as he also recently did some work on the > >>> physical vs virtual addresses in the xHCI driver. > >>> > >>> On 23.02.21 09:07, Bin Meng wrote: > Hi Aaron, > > On Tue, Feb 23, 2021 at 3:31 PM Aaron Williams wrote: > > I have a follow-up. USB is working on our OcteonTX boards running > > 2020.10. It may be something specific to the Octeon port. Note that I > > did see a problem where the scratchpad memory is using direct > > pointers instead of physical addresses (which will not work on MIPS). > > As far as I know, however, the Octeon XHCI controller does not use > > the scratchpad memory. > > Do you plan to send a patch to convert the scratchpad pointer to > physical address? > >>> > >>> Nicolas, did your patch also address the scratchpad area (sorry for not > >>> looking myself). > >> > >> Yes, my patch took care of that :). > > > > Ah cool. I missed that patch. Looks like this is exactly what I need > > to cater for the translation done by the IOMMU on the Apple M1. > > > > Won't be sending that patch then ;) > > Nice. > > Aaron, it might be that you missed this patch series with your latest > mainline xHCI tests a few days ago. Could you please try again with > current mainline and report back, if this changes the behavior on > Octeon MIPS with USB3 hubs? > > Thanks, > Stefan
Re: [PATCH] spi: zynqmp_gqspi: fix set_speed bug on multiple runs
st 20. 1. 2021 v 21:29 odesílatel Brandon Maier
napsal:
>
> If zynqmp_qspi_set_speed() is called multiple times with the same speed,
> then on the second call it will skip recalculating the baud_rate_val as
> it assumes the speed is already configured correctly. But it will still
> write the baud_rate_val to the configuration register and call
> zynqmp_gqspi_set_tapdelay(). Because it skipped recalculating the
> baud_rate_val, it will use the initial value of 0 . This causes the
> driver to run at maximum speed which for many spi flashes is too fast and
> causes data corruption.
>
> Instead only write out a new baud_rate_val if we have calculated the
> correct baud_rate_val.
>
> This opens up another issue with the "if (speed == 0)", we don't save
> off the new plat->speed_hz value when setting the baud rate on the
> speed=0 path. Instead mimic what the Linux zynqmp gqspi driver does, and
> have speed==0 just use the same calculation as a normal speed. That will
> cause the baud_rate_val to use the slowest speed possible, which is the
> safest option.
>
> Signed-off-by: Brandon Maier
> CC: ja...@amarulasolutions.com
> CC: michal.si...@xilinx.com
> CC: Ashok Reddy Soma
> ---
> drivers/spi/zynqmp_gqspi.c | 23 +++
> 1 file changed, 11 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/spi/zynqmp_gqspi.c b/drivers/spi/zynqmp_gqspi.c
> index c7db43a09a..6641c2e9d5 100644
> --- a/drivers/spi/zynqmp_gqspi.c
> +++ b/drivers/spi/zynqmp_gqspi.c
> @@ -320,12 +320,9 @@ static int zynqmp_qspi_set_speed(struct udevice *bus,
> uint speed)
> if (speed > plat->frequency)
> speed = plat->frequency;
>
> - /* Set the clock frequency */
> - confr = readl(>confr);
> - if (speed == 0) {
> - /* Set baudrate x8, if the freq is 0 */
> - baud_rate_val = GQSPI_DFLT_BAUD_RATE_VAL;
> - } else if (plat->speed_hz != speed) {
> + if (plat->speed_hz != speed) {
> + /* Set the clock frequency */
> + /* If speed == 0, default to lowest speed */
> while ((baud_rate_val < 8) &&
>((plat->frequency /
>(2 << baud_rate_val)) > speed))
> @@ -335,13 +332,15 @@ static int zynqmp_qspi_set_speed(struct udevice *bus,
> uint speed)
> baud_rate_val = GQSPI_DFLT_BAUD_RATE_VAL;
>
> plat->speed_hz = plat->frequency / (2 << baud_rate_val);
> - }
> - confr &= ~GQSPI_BAUD_DIV_MASK;
> - confr |= (baud_rate_val << 3);
> - writel(confr, >confr);
>
> - zynqmp_qspi_set_tapdelay(bus, baud_rate_val);
> - debug("regs=%p, speed=%d\n", priv->regs, plat->speed_hz);
> + confr = readl(>confr);
> + confr &= ~GQSPI_BAUD_DIV_MASK;
> + confr |= (baud_rate_val << 3);
> + writel(confr, >confr);
> + zynqmp_qspi_set_tapdelay(bus, baud_rate_val);
> +
> + debug("regs=%p, speed=%d\n", priv->regs, plat->speed_hz);
> + }
>
> return 0;
> }
> --
> 2.29.1
>
Applied.
Ashok: Please fix it on the top of this one if there is something wrong.
Thanks,
Michal
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
[PATCH] arm64: zynqmp: Update device tree properties for nand flash
From: Amit Kumar Mahapatra
Update the following device tree properties for nand flash
- Set software ecc mode.
- Set bch as ecc algo.
- Set read block to 0.
Signed-off-by: Amit Kumar Mahapatra
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
b/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
index 92d938d665d2..3204456e6451 100644
--- a/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
+++ b/arch/arm/dts/zynqmp-zc1751-xm016-dc2.dts
@@ -124,6 +124,10 @@
reg = <0x0>;
#address-cells = <0x2>;
#size-cells = <0x1>;
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "bch";
+ nand-rb = <0>;
+ label = "main-storage-0";
partition@0 { /* for testing purpose */
label = "nand-fsbl-uboot";
@@ -154,6 +158,10 @@
reg = <0x1>;
#address-cells = <0x2>;
#size-cells = <0x1>;
+ nand-ecc-mode = "soft";
+ nand-ecc-algo = "bch";
+ nand-rb = <0>;
+ label = "main-storage-1";
partition@0 { /* for testing purpose */
label = "nand1-fsbl-uboot";
--
2.30.0
[PATCH] arm64: zynqmp: Update psu_init for zcu1275
Update clock/pll setup, ddr, MIOs based on 2020.2 hw design.
Signed-off-by: Michal Simek
---
.../zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c | 230 +++---
1 file changed, 148 insertions(+), 82 deletions(-)
diff --git a/board/xilinx/zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c
b/board/xilinx/zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c
index d3eb713e9eeb..2d93b2005bcc 100644
--- a/board/xilinx/zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c
+++ b/board/xilinx/zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c
@@ -8,77 +8,88 @@
static unsigned long psu_pll_init_data(void)
{
- psu_mask_write(0xFF5E0034, 0xFE7FEDEFU, 0x7E4E2C62U);
- psu_mask_write(0xFF5E0030, 0x00717F00U, 0x00013C00U);
+ psu_mask_write(0xFF5E0034, 0xFE7FEDEFU, 0x7E4B0C62U);
+ psu_mask_write(0xFF5E0030, 0x00717F00U, 0x00014600U);
psu_mask_write(0xFF5E0030, 0x0008U, 0x0008U);
psu_mask_write(0xFF5E0030, 0x0001U, 0x0001U);
psu_mask_write(0xFF5E0030, 0x0001U, 0xU);
mask_poll(0xFF5E0040, 0x0002U);
psu_mask_write(0xFF5E0030, 0x0008U, 0xU);
- psu_mask_write(0xFF5E0048, 0x3F00U, 0x0200U);
- psu_mask_write(0xFF5E0024, 0xFE7FEDEFU, 0x7E4B0C82U);
- psu_mask_write(0xFF5E0020, 0x00717F00U, 0x00015A00U);
+ psu_mask_write(0xFF5E0048, 0x3F00U, 0x0300U);
+ psu_mask_write(0xFF5E0038, 0x8000U, 0xU);
+ psu_mask_write(0xFF5E0108, 0x013F3F07U, 0x01012300U);
+ psu_mask_write(0xFF5E0024, 0xFE7FEDEFU, 0x7E672C6CU);
+ psu_mask_write(0xFF5E0020, 0x00717F00U, 0x2D00U);
psu_mask_write(0xFF5E0020, 0x0008U, 0x0008U);
psu_mask_write(0xFF5E0020, 0x0001U, 0x0001U);
psu_mask_write(0xFF5E0020, 0x0001U, 0xU);
mask_poll(0xFF5E0040, 0x0001U);
psu_mask_write(0xFF5E0020, 0x0008U, 0xU);
psu_mask_write(0xFF5E0044, 0x3F00U, 0x0300U);
+ psu_mask_write(0xFF5E0028, 0x8000U, 0xU);
psu_mask_write(0xFD1A0024, 0xFE7FEDEFU, 0x7E4B0C62U);
- psu_mask_write(0xFD1A0020, 0x00717F00U, 0x00014200U);
+ psu_mask_write(0xFD1A0020, 0x00717F00U, 0x00014800U);
psu_mask_write(0xFD1A0020, 0x0008U, 0x0008U);
psu_mask_write(0xFD1A0020, 0x0001U, 0x0001U);
psu_mask_write(0xFD1A0020, 0x0001U, 0xU);
mask_poll(0xFD1A0044, 0x0001U);
psu_mask_write(0xFD1A0020, 0x0008U, 0xU);
psu_mask_write(0xFD1A0048, 0x3F00U, 0x0300U);
+ psu_mask_write(0xFD1A0028, 0x8000U, 0xU);
psu_mask_write(0xFD1A0030, 0xFE7FEDEFU, 0x7E4B0C62U);
- psu_mask_write(0xFD1A002C, 0x00717F00U, 0x00014800U);
+ psu_mask_write(0xFD1A002C, 0x00717F00U, 0x00014000U);
psu_mask_write(0xFD1A002C, 0x0008U, 0x0008U);
psu_mask_write(0xFD1A002C, 0x0001U, 0x0001U);
psu_mask_write(0xFD1A002C, 0x0001U, 0xU);
mask_poll(0xFD1A0044, 0x0002U);
psu_mask_write(0xFD1A002C, 0x0008U, 0xU);
psu_mask_write(0xFD1A004C, 0x3F00U, 0x0300U);
+ psu_mask_write(0xFD1A0034, 0x8000U, 0xU);
psu_mask_write(0xFD1A003C, 0xFE7FEDEFU, 0x7E4B0C62U);
- psu_mask_write(0xFD1A0038, 0x00717F00U, 0x00014000U);
+ psu_mask_write(0xFD1A0038, 0x00717F00U, 0x00014700U);
psu_mask_write(0xFD1A0038, 0x0008U, 0x0008U);
psu_mask_write(0xFD1A0038, 0x0001U, 0x0001U);
psu_mask_write(0xFD1A0038, 0x0001U, 0xU);
mask_poll(0xFD1A0044, 0x0004U);
psu_mask_write(0xFD1A0038, 0x0008U, 0xU);
- psu_mask_write(0xFD1A0050, 0x3F00U, 0x0200U);
+ psu_mask_write(0xFD1A0050, 0x3F00U, 0x0300U);
+ psu_mask_write(0xFD1A0040, 0x8000U, 0xU);
return 1;
}
static unsigned long psu_clock_init_data(void)
{
+ psu_mask_write(0xFF5E0054, 0x063F3F07U, 0x06010C00U);
+ psu_mask_write(0xFF180308, 0x0060U, 0x0060U);
+ psu_mask_write(0xFF5E0100, 0x013F3F07U, 0x01010600U);
+ psu_mask_write(0xFF5E0060, 0x023F3F07U, 0x02010600U);
+ psu_mask_write(0xFF5E004C, 0x023F3F07U, 0x020F0500U);
psu_mask_write(0xFF5E0068, 0x013F3F07U, 0x01010C00U);
- psu_mask_write(0xFF5E0070, 0x013F3F07U, 0x01010502U);
+ psu_mask_write(0xFF5E0070, 0x013F3F07U, 0x01010800U);
psu_mask_write(0xFF18030C, 0x0002U, 0xU);
psu_mask_write(0xFF5E0074, 0x013F3F07U, 0x01010F00U);
psu_mask_write(0xFF5E0120, 0x013F3F07U, 0x01010F00U);
psu_mask_write(0xFF5E0090, 0x01003F07U, 0x01000302U);
- psu_mask_write(0xFF5E009C, 0x01003F07U, 0x01000400U);
- psu_mask_write(0xFF5E00A4, 0x01003F07U, 0x01000900U);
+ psu_mask_write(0xFF5E009C, 0x01003F07U, 0x01000602U);
+ psu_mask_write(0xFF5E00A4, 0x01003F07U, 0x01000800U);
[PATCH] arm64: zynqmp: Add missing psu inits for zcu208/216
Add missing configurations file for zcu208 and zcu216.
Signed-off-by: Michal Simek
---
.../zynqmp/zynqmp-zcu208-revA/psu_init_gpl.c | 1880
.../zynqmp/zynqmp-zcu216-revA/psu_init_gpl.c | 1882 +
2 files changed, 3762 insertions(+)
create mode 100644 board/xilinx/zynqmp/zynqmp-zcu208-revA/psu_init_gpl.c
create mode 100644 board/xilinx/zynqmp/zynqmp-zcu216-revA/psu_init_gpl.c
diff --git a/board/xilinx/zynqmp/zynqmp-zcu208-revA/psu_init_gpl.c
b/board/xilinx/zynqmp/zynqmp-zcu208-revA/psu_init_gpl.c
new file mode 100644
index ..f07e60abb860
--- /dev/null
+++ b/board/xilinx/zynqmp/zynqmp-zcu208-revA/psu_init_gpl.c
@@ -0,0 +1,1880 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (c) Copyright 2015 Xilinx, Inc. All rights reserved.
+ */
+
+#include
+#include
+
+static int serdes_illcalib(u32 lane3_protocol, u32 lane3_rate,
+ u32 lane2_protocol, u32 lane2_rate,
+ u32 lane1_protocol, u32 lane1_rate,
+ u32 lane0_protocol, u32 lane0_rate);
+
+static unsigned long psu_pll_init_data(void)
+{
+ psu_mask_write(0xFF5E0034, 0xFE7FEDEFU, 0x7E4B0C82U);
+ psu_mask_write(0xFF5E0030, 0x00717F00U, 0x00015A00U);
+ psu_mask_write(0xFF5E0030, 0x0008U, 0x0008U);
+ psu_mask_write(0xFF5E0030, 0x0001U, 0x0001U);
+ psu_mask_write(0xFF5E0030, 0x0001U, 0xU);
+ mask_poll(0xFF5E0040, 0x0002U);
+ psu_mask_write(0xFF5E0030, 0x0008U, 0xU);
+ psu_mask_write(0xFF5E0048, 0x3F00U, 0x0300U);
+ psu_mask_write(0xFF5E0108, 0x013F3F07U, 0x01012300U);
+ psu_mask_write(0xFF5E0024, 0xFE7FEDEFU, 0x7E4B0C82U);
+ psu_mask_write(0xFF5E0020, 0x00717F00U, 0x00015A00U);
+ psu_mask_write(0xFF5E0020, 0x0008U, 0x0008U);
+ psu_mask_write(0xFF5E0020, 0x0001U, 0x0001U);
+ psu_mask_write(0xFF5E0020, 0x0001U, 0xU);
+ mask_poll(0xFF5E0040, 0x0001U);
+ psu_mask_write(0xFF5E0020, 0x0008U, 0xU);
+ psu_mask_write(0xFF5E0044, 0x3F00U, 0x0300U);
+ psu_mask_write(0xFD1A0024, 0xFE7FEDEFU, 0x7E4B0C62U);
+ psu_mask_write(0xFD1A0020, 0x00717F00U, 0x00014800U);
+ psu_mask_write(0xFD1A0020, 0x0008U, 0x0008U);
+ psu_mask_write(0xFD1A0020, 0x0001U, 0x0001U);
+ psu_mask_write(0xFD1A0020, 0x0001U, 0xU);
+ mask_poll(0xFD1A0044, 0x0001U);
+ psu_mask_write(0xFD1A0020, 0x0008U, 0xU);
+ psu_mask_write(0xFD1A0048, 0x3F00U, 0x0300U);
+ psu_mask_write(0xFD1A0030, 0xFE7FEDEFU, 0x7E4B0C62U);
+ psu_mask_write(0xFD1A002C, 0x00717F00U, 0x00013F00U);
+ psu_mask_write(0xFD1A002C, 0x0008U, 0x0008U);
+ psu_mask_write(0xFD1A002C, 0x0001U, 0x0001U);
+ psu_mask_write(0xFD1A002C, 0x0001U, 0xU);
+ mask_poll(0xFD1A0044, 0x0002U);
+ psu_mask_write(0xFD1A002C, 0x0008U, 0xU);
+ psu_mask_write(0xFD1A004C, 0x3F00U, 0x0200U);
+ psu_mask_write(0xFD1A003C, 0xFE7FEDEFU, 0x7E4B0C82U);
+ psu_mask_write(0xFD1A0038, 0x00717F00U, 0x00015A00U);
+ psu_mask_write(0xFD1A0038, 0x0008U, 0x0008U);
+ psu_mask_write(0xFD1A0038, 0x0001U, 0x0001U);
+ psu_mask_write(0xFD1A0038, 0x0001U, 0xU);
+ mask_poll(0xFD1A0044, 0x0004U);
+ psu_mask_write(0xFD1A0038, 0x0008U, 0xU);
+ psu_mask_write(0xFD1A0050, 0x3F00U, 0x0300U);
+
+ return 1;
+}
+
+static unsigned long psu_clock_init_data(void)
+{
+ psu_mask_write(0xFF5E005C, 0x063F3F07U, 0x06010C00U);
+ psu_mask_write(0xFF5E0100, 0x013F3F07U, 0x01010600U);
+ psu_mask_write(0xFF5E0060, 0x023F3F07U, 0x02010600U);
+ psu_mask_write(0xFF5E004C, 0x023F3F07U, 0x02031900U);
+ psu_mask_write(0xFF5E0068, 0x013F3F07U, 0x01010C00U);
+ psu_mask_write(0xFF5E0070, 0x013F3F07U, 0x01010800U);
+ psu_mask_write(0xFF18030C, 0x0002U, 0xU);
+ psu_mask_write(0xFF5E0074, 0x013F3F07U, 0x01010F00U);
+ psu_mask_write(0xFF5E0120, 0x013F3F07U, 0x01010F00U);
+ psu_mask_write(0xFF5E0124, 0x013F3F07U, 0x01010F00U);
+ psu_mask_write(0xFF5E0090, 0x01003F07U, 0x01000302U);
+ psu_mask_write(0xFF5E009C, 0x01003F07U, 0x01000602U);
+ psu_mask_write(0xFF5E00A4, 0x01003F07U, 0x01000800U);
+ psu_mask_write(0xFF5E00A8, 0x01003F07U, 0x01000302U);
+ psu_mask_write(0xFF5E00AC, 0x01003F07U, 0x01000F02U);
+ psu_mask_write(0xFF5E00B0, 0x01003F07U, 0x01000602U);
+ psu_mask_write(0xFF5E00B8, 0x01003F07U, 0x01000302U);
+ psu_mask_write(0xFF5E00C0, 0x013F3F07U, 0x01010F00U);
+ psu_mask_write(0xFF5E0108, 0x013F3F07U, 0x01011E02U);
+ psu_mask_write(0xFF5E0104, 0x0007U, 0xU);
+ psu_mask_write(0xFF5E0128, 0x01003F07U, 0x01000F00U);
+ psu_mask_write(0xFD1A00A0,
[PATCH] arm64: zynqmp: Add idt 8a34001 chip to zcu208/zcu216
There is Linux driver for these chips that's why add it to device tree.
Signed-off-by: Michal Simek
---
arch/arm/dts/zynqmp-zcu208-revA.dts | 5 -
arch/arm/dts/zynqmp-zcu216-revA.dts | 5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/zynqmp-zcu208-revA.dts
b/arch/arm/dts/zynqmp-zcu208-revA.dts
index 124219314b89..268e368b7657 100644
--- a/arch/arm/dts/zynqmp-zcu208-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu208-revA.dts
@@ -441,7 +441,10 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
- /* U409B - 8a34001 */
+ idt_8a34001: phc@5b {
+ compatible = "idt,8a34001"; /* u409B */
+ reg = <0x5b>;
+ };
};
i2c_clk104: i2c@5 {
#address-cells = <1>;
diff --git a/arch/arm/dts/zynqmp-zcu216-revA.dts
b/arch/arm/dts/zynqmp-zcu216-revA.dts
index 511727fa955d..847e689c155f 100644
--- a/arch/arm/dts/zynqmp-zcu216-revA.dts
+++ b/arch/arm/dts/zynqmp-zcu216-revA.dts
@@ -445,7 +445,10 @@
#address-cells = <1>;
#size-cells = <0>;
reg = <4>;
- /* U409B - 8a34001 */
+ idt_8a34001: phc@5b {
+ compatible = "idt,8a34001"; /* u409B */
+ reg = <0x5b>;
+ };
};
i2c_clk104: i2c@5 {
#address-cells = <1>;
--
2.30.0
[PATCH] arm64: zynqmp: Add emmc specific parameters
From: Ashok Reddy Soma EMMC will have bus-width 8 and it is non-removable in general. These are missing from dt node. Add bus-width and non-removable parameters to emmc node. Signed-off-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- arch/arm/dts/zynqmp-mini-emmc0.dts | 2 ++ arch/arm/dts/zynqmp-mini-emmc1.dts | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm/dts/zynqmp-mini-emmc0.dts b/arch/arm/dts/zynqmp-mini-emmc0.dts index 2213bb2fdf6c..8467dd8e1cc7 100644 --- a/arch/arm/dts/zynqmp-mini-emmc0.dts +++ b/arch/arm/dts/zynqmp-mini-emmc0.dts @@ -51,6 +51,8 @@ u-boot,dm-pre-reloc; compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a"; status = "disabled"; + non-removable; + bus-width = <8>; reg = <0x0 0xff16 0x0 0x1000>; clock-names = "clk_xin", "clk_ahb"; clocks = <_xin _xin>; diff --git a/arch/arm/dts/zynqmp-mini-emmc1.dts b/arch/arm/dts/zynqmp-mini-emmc1.dts index 0538da468b3e..2afcc7751b9f 100644 --- a/arch/arm/dts/zynqmp-mini-emmc1.dts +++ b/arch/arm/dts/zynqmp-mini-emmc1.dts @@ -51,6 +51,8 @@ u-boot,dm-pre-reloc; compatible = "xlnx,zynqmp-8.9a", "arasan,sdhci-8.9a"; status = "disabled"; + non-removable; + bus-width = <8>; reg = <0x0 0xff17 0x0 0x1000>; clock-names = "clk_xin", "clk_ahb"; clocks = <_xin _xin>; -- 2.30.0
[PATCH] arm64: zynqmp: Increase size of malloc pool
From: Ashok Reddy Soma size of malloc() pool for use before relocation is not sufficient for ZynqMP mini u-boot with emmc configuration. Increase it to 4K. Signed-off-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- configs/xilinx_zynqmp_mini_emmc0_defconfig | 2 ++ configs/xilinx_zynqmp_mini_emmc1_defconfig | 2 ++ 2 files changed, 4 insertions(+) diff --git a/configs/xilinx_zynqmp_mini_emmc0_defconfig b/configs/xilinx_zynqmp_mini_emmc0_defconfig index 35eb5f1fe805..4594f8096d39 100644 --- a/configs/xilinx_zynqmp_mini_emmc0_defconfig +++ b/configs/xilinx_zynqmp_mini_emmc0_defconfig @@ -3,8 +3,10 @@ CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini_emmc" CONFIG_SYS_ICACHE_OFF=y CONFIG_ARCH_ZYNQMP=y CONFIG_SYS_TEXT_BASE=0x1 +CONFIG_SYS_MALLOC_F_LEN=0x1000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x80 +CONFIG_SPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL=y # CONFIG_CMD_ZYNQMP is not set CONFIG_DEFAULT_DEVICE_TREE="zynqmp-mini-emmc0" diff --git a/configs/xilinx_zynqmp_mini_emmc1_defconfig b/configs/xilinx_zynqmp_mini_emmc1_defconfig index eaec137adaf8..d7c64b9da535 100644 --- a/configs/xilinx_zynqmp_mini_emmc1_defconfig +++ b/configs/xilinx_zynqmp_mini_emmc1_defconfig @@ -3,8 +3,10 @@ CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_mini_emmc" CONFIG_SYS_ICACHE_OFF=y CONFIG_ARCH_ZYNQMP=y CONFIG_SYS_TEXT_BASE=0x1 +CONFIG_SYS_MALLOC_F_LEN=0x1000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_SIZE=0x80 +CONFIG_SPL_SYS_MALLOC_F_LEN=0x600 CONFIG_SPL=y # CONFIG_CMD_ZYNQMP is not set CONFIG_DEFAULT_DEVICE_TREE="zynqmp-mini-emmc1" -- 2.30.0
[PATCH] xilinx: zynq: Enable time and timer commands
From: Ashok Reddy Soma Enable time command to get the elapsed time and timer commands. Signed-off-by: Ashok Reddy Soma Signed-off-by: Michal Simek --- configs/xilinx_zynq_virt_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/xilinx_zynq_virt_defconfig b/configs/xilinx_zynq_virt_defconfig index 552f1b4dfb94..2fe53182caa8 100644 --- a/configs/xilinx_zynq_virt_defconfig +++ b/configs/xilinx_zynq_virt_defconfig @@ -47,6 +47,8 @@ CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TFTPPUT=y CONFIG_CMD_CACHE=y +CONFIG_CMD_TIME=y +CONFIG_CMD_TIMER=y CONFIG_CMD_EXT4_WRITE=y CONFIG_CMD_MTDPARTS=y CONFIG_CMD_MTDPARTS_SPREAD=y -- 2.30.0
Re: [PATCH] arm64: zynqmp: Rename zc1275/zcu1275 to be aligned with DT name
st 17. 2. 2021 v 9:10 odesílatel Michal Simek napsal:
>
> Folder names corresponds to DT name. These boards have been renamed from
> zc1275 to zcu1275 by commit shown below and this should be the part of that
> commit.
>
> Fixes: 420d44678119 ("arm64: zynqmp: Rename zc1275 to zcu1275")
> Signed-off-by: Michal Simek
> ---
>
> board/xilinx/zynqmp/{zynqmp-zc1275-revA => zynqmp-zcu1275-revA} | 0
> .../{zynqmp-zc1275-revB => zynqmp-zcu1275-revB}/psu_init_gpl.c| 0
> 2 files changed, 0 insertions(+), 0 deletions(-)
> rename board/xilinx/zynqmp/{zynqmp-zc1275-revA => zynqmp-zcu1275-revA} (100%)
> rename board/xilinx/zynqmp/{zynqmp-zc1275-revB =>
> zynqmp-zcu1275-revB}/psu_init_gpl.c (100%)
>
> diff --git a/board/xilinx/zynqmp/zynqmp-zc1275-revA
> b/board/xilinx/zynqmp/zynqmp-zcu1275-revA
> similarity index 100%
> rename from board/xilinx/zynqmp/zynqmp-zc1275-revA
> rename to board/xilinx/zynqmp/zynqmp-zcu1275-revA
> diff --git a/board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c
> b/board/xilinx/zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c
> similarity index 100%
> rename from board/xilinx/zynqmp/zynqmp-zc1275-revB/psu_init_gpl.c
> rename to board/xilinx/zynqmp/zynqmp-zcu1275-revB/psu_init_gpl.c
> --
> 2.30.0
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] net: gem: Fix error path in zynq_gem_probe
čt 11. 2. 2021 v 19:06 odesílatel Michal Simek napsal:
>
> Clean up error path in connection where priv->rxbuffers and priv->tx_bd are
> allocated.
>
> Signed-off-by: Michal Simek
> ---
>
> Based on
> https://lists.denx.de/pipermail/u-boot/2021-February/440943.html
> https://lists.denx.de/pipermail/u-boot/2021-February/441021.html
> ---
> drivers/net/zynq_gem.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/zynq_gem.c b/drivers/net/zynq_gem.c
> index 9ed013ee5124..baf06a2ad897 100644
> --- a/drivers/net/zynq_gem.c
> +++ b/drivers/net/zynq_gem.c
> @@ -708,14 +708,14 @@ static int zynq_gem_probe(struct udevice *dev)
> ret = clk_get_by_name(dev, "tx_clk", >tx_clk);
> if (ret < 0) {
> dev_err(dev, "failed to get tx_clock\n");
> - goto err1;
> + goto err2;
> }
>
> if (priv->clk_en_info & RXCLK_EN) {
> ret = clk_get_by_name(dev, "rx_clk", >rx_clk);
> if (ret < 0) {
> dev_err(dev, "failed to get rx_clock\n");
> - goto err1;
> + goto err2;
> }
> }
>
> @@ -737,9 +737,9 @@ static int zynq_gem_probe(struct udevice *dev)
> err3:
> mdio_unregister(priv->bus);
> err2:
> - free(priv->rxbuffers);
> -err1:
> free(priv->tx_bd);
> +err1:
> + free(priv->rxbuffers);
> return ret;
> }
>
> --
> 2.30.0
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 2/2] pinctrl: at91-pio4: add support for slew-rate
On 27.01.2021 15:00, Claudiu Beznea wrote:
> SAMA7G5 supports slew rate configuration. Adapt the driver for this.
> For switching frequencies lower than 50MHz the slew rate needs to
> be enabled. Since most of the pins on SAMA7G5 fall into this category
> enabled the slew rate by default.
>
> Signed-off-by: Claudiu Beznea
> ---
> arch/arm/mach-at91/include/mach/atmel_pio4.h | 1 +
> drivers/pinctrl/pinctrl-at91-pio4.c | 26 +++---
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-at91/include/mach/atmel_pio4.h
> b/arch/arm/mach-at91/include/mach/atmel_pio4.h
> index 35ac7b2d40e1..c3bd9140dfef 100644
> --- a/arch/arm/mach-at91/include/mach/atmel_pio4.h
> +++ b/arch/arm/mach-at91/include/mach/atmel_pio4.h
> @@ -44,6 +44,7 @@ struct atmel_pio4_port {
> #define ATMEL_PIO_DIR_MASK BIT(8)
> #define ATMEL_PIO_PUEN_MASK BIT(9)
> #define ATMEL_PIO_PDEN_MASK BIT(10)
> +#define ATMEL_PIO_SR BIT(11)
> #define ATMEL_PIO_IFEN_MASK BIT(12)
> #define ATMEL_PIO_IFSCEN_MASK BIT(13)
> #define ATMEL_PIO_OPD_MASK BIT(14)
> diff --git a/drivers/pinctrl/pinctrl-at91-pio4.c
> b/drivers/pinctrl/pinctrl-at91-pio4.c
> index 3a5143adc381..5c6ece745ab0 100644
> --- a/drivers/pinctrl/pinctrl-at91-pio4.c
> +++ b/drivers/pinctrl/pinctrl-at91-pio4.c
> @@ -24,6 +24,7 @@ DECLARE_GLOBAL_DATA_PTR;
>
> struct atmel_pio4_plat {
> struct atmel_pio4_port *reg_base;
> + unsigned int slew_rate_support;
> };
>
> static const struct pinconf_param conf_params[] = {
> @@ -35,9 +36,11 @@ static const struct pinconf_param conf_params[] = {
> { "input-schmitt-enable", PIN_CONFIG_INPUT_SCHMITT_ENABLE, 1 },
> { "input-debounce", PIN_CONFIG_INPUT_DEBOUNCE, 0 },
> { "atmel,drive-strength", PIN_CONFIG_DRIVE_STRENGTH, 0 },
> + { "slew-rate", PIN_CONFIG_SLEW_RATE, 0},
Hi Claudiu,
If slew rate is enabled by default, we should have here 0 or 1 ?
> };
>
> -static u32 atmel_pinctrl_get_pinconf(struct udevice *config)
> +static u32 atmel_pinctrl_get_pinconf(struct udevice *config,
> + struct atmel_pio4_plat *plat)
> {
> const struct pinconf_param *params;
> u32 param, arg, conf = 0;
> @@ -52,6 +55,10 @@ static u32 atmel_pinctrl_get_pinconf(struct udevice
> *config)
> param = params->param;
> arg = params->default_value;
>
> + /* Keep slew rate enabled by default. */
> + if (plat->slew_rate_support)
> + conf |= ATMEL_PIO_SR;
> +
> switch (param) {
> case PIN_CONFIG_BIAS_DISABLE:
> conf &= (~ATMEL_PIO_PUEN_MASK);
> @@ -90,6 +97,15 @@ static u32 atmel_pinctrl_get_pinconf(struct udevice
> *config)
> conf |= (val << ATMEL_PIO_DRVSTR_OFFSET)
> & ATMEL_PIO_DRVSTR_MASK;
> break;
> + case PIN_CONFIG_SLEW_RATE:
> + if (!plat->slew_rate_support)
> + break;
> +
> + dev_read_u32(config, params->property, );
> + /* And disable it if requested. */
> + if (val == 0)
> + conf &= ~ATMEL_PIO_SR;
> + break;
> default:
> printf("%s: Unsupported configuration parameter: %u\n",
> __func__, param);
> @@ -115,6 +131,7 @@ static inline struct atmel_pio4_port
> *atmel_pio4_bank_base(struct udevice *dev,
>
> static int atmel_pinctrl_set_state(struct udevice *dev, struct udevice
> *config)
> {
> + struct atmel_pio4_plat *plat = dev_get_plat(dev);
> struct atmel_pio4_port *bank_base;
> const void *blob = gd->fdt_blob;
> int node = dev_of_offset(config);
> @@ -123,7 +140,7 @@ static int atmel_pinctrl_set_state(struct udevice *dev,
> struct udevice *config)
> u32 i, conf;
> int count;
>
> - conf = atmel_pinctrl_get_pinconf(config);
> + conf = atmel_pinctrl_get_pinconf(config, plat);
>
> count = fdtdec_get_int_array_count(blob, node, "pinmux",
> cells, ARRAY_SIZE(cells));
> @@ -163,6 +180,7 @@ const struct pinctrl_ops atmel_pinctrl_ops = {
> static int atmel_pinctrl_probe(struct udevice *dev)
> {
> struct atmel_pio4_plat *plat = dev_get_plat(dev);
> + ulong priv = dev_get_driver_data(dev);
> fdt_addr_t addr_base;
>
> dev = dev_get_parent(dev);
> @@ -171,13 +189,15 @@ static int atmel_pinctrl_probe(struct udevice *dev)
> return -EINVAL;
>
> plat->reg_base = (struct atmel_pio4_port *)addr_base;
> + plat->slew_rate_support = priv;
>
> return 0;
> }
>
> static const struct udevice_id atmel_pinctrl_match[] = {
> { .compatible =
Re: [PATCH v3 0/5] clk: Add support to enable clocks
po 15. 2. 2021 v 10:56 odesílatel Michal Simek napsal: > > Hi, > > Add support to enable clocks using clock subsystem ops for > zynqmp & versal platforms. Enable rx clock in ethernet driver > for versal platform. Add clock enable feature in i2c-cdns > driver. > > Thanks, > Karthik, Michal > > Changes in v3: > - Enable it for SPL too. > - Fix Ramon's tag > > Changes in v2: > - New patch is series > - change patch possition > - Use compatible data instead of CONFIG_ > > Michal Simek (1): > clk: zynq: Add dummy clock enable function > > T Karthik Reddy (4): > clk: zynqmp: Add support to enable clocks > clk: versal: Add support to enable clocks > i2c: i2c_cdns: Enable i2c clock > net: gem: Enable ethernet rx clock for versal > > drivers/clk/clk_versal.c | 11 > drivers/clk/clk_zynq.c | 10 +++ > drivers/clk/clk_zynqmp.c | 49 ++ > drivers/i2c/i2c-cdns.c | 7 + > drivers/mmc/zynq_sdhci.c | 2 +- > drivers/net/zynq_gem.c | 37 +++-- > drivers/serial/serial_zynq.c | 2 +- > drivers/spi/zynq_qspi.c| 2 +- > drivers/spi/zynq_spi.c | 2 +- > drivers/spi/zynqmp_gqspi.c | 2 +- > drivers/watchdog/xilinx_wwdt.c | 3 +-- > 11 files changed, 112 insertions(+), 15 deletions(-) > > -- > 2.30.0 > Applied. M -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH] arm64: zynqmp: Do not clear reset reason
út 9. 2. 2021 v 8:52 odesílatel Michal Simek napsal:
>
> There is no need to clear reset reason register because it is protected by
> PMUFW already which is reported when verbose log is enabled as:
> pm_core.c@733 APU> No write permission to 0xFF5E0220
>
> Signed-off-by: Michal Simek
> ---
>
> board/xilinx/zynqmp/zynqmp.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> index a216eeb35f15..6babc0ebce3e 100644
> --- a/board/xilinx/zynqmp/zynqmp.c
> +++ b/board/xilinx/zynqmp/zynqmp.c
> @@ -496,11 +496,7 @@ static int reset_reason(void)
>
> env_set("reset_reason", reason);
>
> - ret = zynqmp_mmio_write((ulong)_base->reset_reason, ~0, ~0);
> - if (ret)
> - return -EINVAL;
> -
> - return ret;
> + return 0;
> }
>
> static int set_fdtfile(void)
> --
> 2.30.0
>
Applied.
M
--
Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel - Xilinx Microblaze
Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs
U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: [PATCH 08/10] sun5i: add support for DIP detection to CHIP board
On Mon, 22 Feb 2021 15:23:08 +0100
Köry Maincent wrote:
Hi Köry,
> Thanks for your reviews.
>
> On Fri, 19 Feb 2021 17:29:26 +
> Andre Przywara wrote:
>
> > >
> > > And then based on my comment in the previous patch, similar to
> > > PINEPHONE_DT_SELECTION and other board-specific options, add a
> > > CHIP_DIP_SCAN option or similar.
> >
> > Yes, indeed, thanks Tom.
> >
> > The idea of making this extension scheme generic is great, it's just
> > that sunxi is using a different approach to board specific code here.
> > Normally we expect U-Boot-proper board specific code to be DT driven,
> > and where this does not really work, use those symbols that Tom pointed
> > to.
>
> For my extension_board_scan board specific function, would you prefer if I
> move
> to callback like below instead of Kconfig?
>
> if (of_machine_is_compatible("nextthing,chip"))
> extension_board_register_callback(chip_extension_board_scan);
Well, the CHIP Pro uses a different compatible string, so you would
need to check for that too.
I am not fully decided if checking for the machine compatible is the
right approach. The more traditional U-Boot way would be to define a
config symbol (as Tom already pointed out), that would also keep the
code out of other board builds.
We do this already with CONFIG_PINE64_DT_SELECTION and
CONFIG_PINEPHONE_DT_SELECTION.
Cheers,
Andre
Re: [PATCH v3 1/4] arm: x86: qemu: move qfw to DM, include Arm support
On 23.02.21 12:43, Asherah Connor wrote:
> Updates the QFW driver to use the driver model, and adds support for QFW
> on Arm platforms by configuring from the device tree and using MMIO
> accordingly. A sandbox driver for QFW is also included, and a simple DM
> unit test for it.
For which architectures does the fw_cfg device exist?
It it is only ARM and X86, than I am missing such a dependency on
CONFIG_CMD_QFW.
>
> Signed-off-by: Asherah Connor
> ---
>
> Changes in v3:
> - ARCH_QEMU now implies CMD_QFW, not QFW
> - rename qemu_fwcfg_read_entry_pio to ..._io
>
> arch/arm/Kconfig | 1 +
> arch/x86/cpu/qemu/cpu.c | 7 +-
> arch/x86/cpu/qemu/qemu.c | 54 ++--
> arch/x86/cpu/qfw_cpu.c | 11 +-
> cmd/qfw.c| 44 +++---
> drivers/misc/Kconfig | 1 +
> drivers/misc/qfw.c | 289 +++
> include/qfw.h| 63 +
> 8 files changed, 292 insertions(+), 178 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d51abbeaf0..cd01dc458a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -937,6 +937,7 @@ config ARCH_QEMU
> imply DM_RNG
> imply DM_RTC
> imply RTC_PL031
> + imply CMD_QFW
>
> config ARCH_RMOBILE
> bool "Renesas ARM SoCs"
> diff --git a/arch/x86/cpu/qemu/cpu.c b/arch/x86/cpu/qemu/cpu.c
> index 9ce86b379c..ab1b797f9a 100644
> --- a/arch/x86/cpu/qemu/cpu.c
> +++ b/arch/x86/cpu/qemu/cpu.c
> @@ -22,7 +22,12 @@ int cpu_qemu_get_desc(const struct udevice *dev, char
> *buf, int size)
>
> static int cpu_qemu_get_count(const struct udevice *dev)
> {
> - return qemu_fwcfg_online_cpus();
> + struct udevice *qfw_dev = qemu_fwcfg_dev();
> +
> + if (!qfw_dev)
> + return -ENODEV;
> +
> + return qemu_fwcfg_online_cpus(qfw_dev);
> }
>
> static const struct cpu_ops cpu_qemu_ops = {
> diff --git a/arch/x86/cpu/qemu/qemu.c b/arch/x86/cpu/qemu/qemu.c
> index 044a429c13..e255af9a4a 100644
> --- a/arch/x86/cpu/qemu/qemu.c
> +++ b/arch/x86/cpu/qemu/qemu.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -19,45 +20,20 @@ static bool i440fx;
> #ifdef CONFIG_QFW
>
> /* on x86, the qfw registers are all IO ports */
> -#define FW_CONTROL_PORT 0x510
> -#define FW_DATA_PORT 0x511
> -#define FW_DMA_PORT_LOW 0x514
> -#define FW_DMA_PORT_HIGH 0x518
> -
> -static void qemu_x86_fwcfg_read_entry_pio(uint16_t entry,
> - uint32_t size, void *address)
> -{
> - uint32_t i = 0;
> - uint8_t *data = address;
> -
> - /*
> - * writting FW_CFG_INVALID will cause read operation to resume at
> - * last offset, otherwise read will start at offset 0
> - *
> - * Note: on platform where the control register is IO port, the
> - * endianness is little endian.
> - */
> - if (entry != FW_CFG_INVALID)
> - outw(cpu_to_le16(entry), FW_CONTROL_PORT);
> -
> - /* the endianness of data register is string-preserving */
> - while (size--)
> - data[i++] = inb(FW_DATA_PORT);
> -}
> -
> -static void qemu_x86_fwcfg_read_entry_dma(struct fw_cfg_dma_access *dma)
> -{
> - /* the DMA address register is big endian */
> - outl(cpu_to_be32((uintptr_t)dma), FW_DMA_PORT_HIGH);
> -
> - while (be32_to_cpu(dma->control) & ~FW_CFG_DMA_ERROR)
> - __asm__ __volatile__ ("pause");
> -}
> +static const struct qfw_plat x86_qfw_plat = {
> + .io = {
> + .control_port = 0x510,
> + .data_port = 0x511,
> + .dma_port_low = 0x514,
> + .dma_port_high = 0x518,
> + },
> +};
If these numbers are constants, why should they be copied to platform
data? This only increases code size.
I think there is nothing wrong with using constants here.
>
> -static struct fw_cfg_arch_ops fwcfg_x86_ops = {
> - .arch_read_pio = qemu_x86_fwcfg_read_entry_pio,
> - .arch_read_dma = qemu_x86_fwcfg_read_entry_dma
> +U_BOOT_DRVINFO(x86_qfw) = {
> + .name = "qfw",
> + .plat = _qfw_plat,
> };
> +
> #endif
>
> static void enable_pm_piix(void)
> @@ -132,10 +108,6 @@ static void qemu_chipset_init(void)
>
> enable_pm_ich9();
> }
> -
> -#ifdef CONFIG_QFW
> - qemu_fwcfg_init(_x86_ops);
> -#endif
> }
>
> #if !CONFIG_IS_ENABLED(SPL_X86_32BIT_INIT)
> diff --git a/arch/x86/cpu/qfw_cpu.c b/arch/x86/cpu/qfw_cpu.c
> index b959eaddde..c8fb918494 100644
> --- a/arch/x86/cpu/qfw_cpu.c
> +++ b/arch/x86/cpu/qfw_cpu.c
> @@ -18,7 +18,7 @@ int qemu_cpu_fixup(void)
> int cpu_num;
> int cpu_online;
> struct uclass *uc;
> - struct udevice *dev, *pdev;
> + struct udevice *dev, *pdev, *qfwdev;
> struct cpu_plat *plat;
> char *cpu;
>
> @@ -39,6 +39,13 @@ int qemu_cpu_fixup(void)
> return -ENODEV;
> }
>
> + /* get qfw dev */
> + qfwdev = qemu_fwcfg_dev();
> + if (!qfwdev) {
> +
Re: [PATCH 1/2] spi: nxp_fspi: Fix error reporting
On Tue, Jan 19, 2021 at 6:12 AM Pratyush Yadav wrote:
>
> On 18/01/21 03:32PM, Adam Ford wrote:
> > On the i.MX8M Mini, ret = clk_set_rate() sets ret to the value of the
> > rate the clock was able to set. When checking for errors, it only
> > checks that it is not NULL. Since positive numbers are not errors,
> > only check for negative numbers when handling errors.
> >
> > Fixes: 383fded70c4f ("spi: nxp_fspi: new driver for the FlexSPI controller")
> > Signed-off-by: Adam Ford
>
> Reviewed-by: Pratyush Yadav
>
Jagan,
Is this something you can take, or do I need to add someone to the CC
list? It's been nearly a month, and it's holding up the ability for a
QSPI driver on two boards.
thanks,
adam
> --
> Regards,
> Pratyush Yadav
> Texas Instruments India
Re: [PATCH 42/57] ppc: Remove T1040RDB boards
On Tue, Feb 23, 2021 at 10:38:17AM +, Priyanka Jain (OSS) wrote: > >-Original Message- > >From: U-Boot On Behalf Of Tom Rini > >Sent: Monday, February 22, 2021 6:43 PM > >To: Y.b. Lu > >Cc: Priyanka Jain ; u-boot@lists.denx.de; Jiafei Pan > >; Xiaobo Xie ; Poonam Aggrwal > > > >Subject: Re: [PATCH 42/57] ppc: Remove T1040RDB boards > > > >On Mon, Feb 22, 2021 at 08:54:25AM +, Y.b. Lu wrote: > >> Hi Tom, > >> > >> > -Original Message- > >> > From: U-Boot On Behalf Of Priyanka > >> > Jain > >> > Sent: Monday, February 22, 2021 2:17 PM > >> > To: Tom Rini ; u-boot@lists.denx.de > >> > Cc: Jiafei Pan ; Xiaobo Xie > >> > ; Poonam Aggrwal > >> > Subject: RE: [PATCH 42/57] ppc: Remove T1040RDB boards > >> > > >> > >-Original Message- > >> > >From: Tom Rini > >> > >Sent: Sunday, February 21, 2021 6:36 AM > >> > >To: u-boot@lists.denx.de > >> > >Cc: Priyanka Jain ; Ruchika Gupta > >> > >; Sumit Garg > >> > >Subject: [PATCH 42/57] ppc: Remove T1040RDB boards > >> > > > >> > >These boards have not been converted to CONFIG_DM_MMC by the > >> > >deadline. > >> > >Remove them. > >> > > > >> > >Cc: Priyanka Jain > >> > >Cc: Ruchika Gupta > >> > >Cc: Sumit Garg > >> > >Signed-off-by: Tom Rini > >> > >--- > >> > > arch/powerpc/cpu/mpc85xx/Kconfig | 19 - > >> > > arch/powerpc/include/asm/fsl_secure_boot.h| 2 - > >> > > board/freescale/t104xrdb/Kconfig | 16 - > >> > > board/freescale/t104xrdb/MAINTAINERS | 38 - > >> > > board/freescale/t104xrdb/Makefile | 16 - > >> > > board/freescale/t104xrdb/README | 386 - > >> > > board/freescale/t104xrdb/cpld.c | 115 --- > >> > > board/freescale/t104xrdb/cpld.h | 46 - > >> > > board/freescale/t104xrdb/ddr.c| 146 > >> > > board/freescale/t104xrdb/ddr.h| 56 -- > >> > > board/freescale/t104xrdb/diu.c| 84 -- > >> > > board/freescale/t104xrdb/eth.c| 157 > >> > > board/freescale/t104xrdb/law.c| 31 - > >> > > board/freescale/t104xrdb/pci.c| 25 - > >> > > board/freescale/t104xrdb/spl.c| 141 --- > >> > > board/freescale/t104xrdb/t1040_nand_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1040_sd_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1040_spi_rcw.cfg| 7 - > >> > > board/freescale/t104xrdb/t1040d4_nand_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1040d4_sd_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1040d4_spi_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1042_nand_rcw.cfg | 7 - > >> > > .../freescale/t104xrdb/t1042_pi_nand_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1042_pi_sd_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1042_pi_spi_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1042_sd_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1042_spi_rcw.cfg| 7 - > >> > > board/freescale/t104xrdb/t1042d4_nand_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1042d4_sd_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t1042d4_spi_rcw.cfg | 7 - > >> > > board/freescale/t104xrdb/t104x_pbi.cfg| 36 - > >> > > board/freescale/t104xrdb/t104x_pbi_sb.cfg | 38 - > >> > > board/freescale/t104xrdb/t104xrdb.c | 164 > >> > > board/freescale/t104xrdb/t104xrdb.h | 12 - > >> > > board/freescale/t104xrdb/tlb.c| 131 --- > >> > > configs/T1040D4RDB_NAND_defconfig | 78 -- > >> > > configs/T1040D4RDB_SDCARD_defconfig | 75 -- > >> > > configs/T1040D4RDB_SECURE_BOOT_defconfig | 64 -- > >> > > configs/T1040D4RDB_SPIFLASH_defconfig | 77 -- > >> > > configs/T1040D4RDB_defconfig | 62 -- > >> > > configs/T1040RDB_NAND_defconfig | 79 -- > >> > > configs/T1040RDB_SDCARD_defconfig | 76 -- > >> > > configs/T1040RDB_SECURE_BOOT_defconfig| 65 -- > >> > > configs/T1040RDB_SPIFLASH_defconfig | 78 -- > >> > > configs/T1040RDB_defconfig| 63 -- > >> > > configs/T1042D4RDB_NAND_defconfig | 86 -- > >> > > configs/T1042D4RDB_SDCARD_defconfig | 83 -- > >> > > configs/T1042D4RDB_SECURE_BOOT_defconfig | 63 -- > >> > > configs/T1042D4RDB_SPIFLASH_defconfig | 85 -- > >> > > configs/T1042D4RDB_defconfig | 71 -- > >> > >> DM_MMC had already been in use for T1042D4RDB. The board is still in > >maintaining. > >> Can we keep it? > > > >So, this patch was a bit overzealous in removing stuff (the script, > >tools/rmboard.py relies on the MAINTAINERS file). That said, > >T1042D4RDB_SECURE_BOOT is not converted and all of the rest have: > >=== WARNING == This board does > >not use CONFIG_DM_VIDEO Please update the board to use CONFIG_DM_VIDEO > >before the v2019.07 release. > >Failure to update by the deadline may result in board
