[PATCH] arm64: rk3399: Add support NanoPi R4s
From: Xiaobo Tian
NanoPi R4s is SBC base on Rockchip RK3399 hexa-core processor with
dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD card
support,
including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2 USB 3.0
port.
port.It also has two GPIO headers which allows further peripherals to be used.
The devicetree file is taken of the rk3399 nanopi4 Linux kernel [1].
[1]
https://github.com/torvalds/linux/commit/e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
Signed-off-by: xiaobo
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi | 17 +++
arch/arm/dts/rk3399-nanopi-r4s.dts | 138 +
board/rockchip/evb_rk3399/MAINTAINERS | 6 +
configs/nanopi-r4s-rk3399_defconfig| 62 +
5 files changed, 224 insertions(+)
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
create mode 100644 configs/nanopi-r4s-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 858b79ac97..528dfe069e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-evb.dtb \
rk3288-firefly.dtb \
rk3288-miqi.dtb \
+ rk3399-nanopi-r4s.dtb \
rk3288-phycore-rdk.dtb \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
new file mode 100644
index 00..3f97867cc5
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RK3399-based FriendlyElec boards device tree source
+ *
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ * Copyright (C) 2020 Xiaobo
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
+#include "rk3399-sdram-ddr3-1866.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
b/arch/arm/dts/rk3399-nanopi-r4s.dts
new file mode 100644
index 00..6f2cf17bf1
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ * Copyright (C) 2020 Xiaobo
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R4S";
+ compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+ aliases {
+ ethernet1 = &r8169;
+ };
+
+ vdd_5v: vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 12 18 255>;
+ #cooling-cells = <2>;
+ fan-supply = <&vdd_5v>;
+ pwms = <&pwm1 0 5 0>;
+ };
+};
+
+&cpu_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <&cpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <&cpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&emmc_phy {
+ status = "disabled";
+};
+
+&fusb0 {
+ status = "disabled";
+};
+
+&leds {
+ lan_led: led-1 {
+ gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:lan";
+ };
+
+ wan_led: led-2 {
+ gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:wan";
+ };
+};
+
+&leds_gpio {
+ rockchip,pins =
+ <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>,
+ <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>,
+ <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+};
+
+&pcie0 {
+ max-link-speed = <1>;
+ num-lanes = <1>;
+ vpcie3v3-supply = <&vcc3v3_sys>;
+
+ pcie@0 {
+ reg = <0x 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+
[PATCH] arm64: rk3399: Add support NanoPi R4s
From: Xiaobo Tian
NanoPi R4s is SBC base on Rockchip RK3399 hexa-core processor with
dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD card
support,
including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2 USB 3.0
port.
port.It also has two GPIO headers which allows further peripherals to be used.
The devicetree file is taken of the rk3399 nanopi4 Linux kernel [1].
[1]
https://github.com/torvalds/linux/commit/e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
Signed-off-by: xiaobo
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi | 17 +++
arch/arm/dts/rk3399-nanopi-r4s.dts | 138 +
board/rockchip/evb_rk3399/MAINTAINERS | 6 +
configs/nanopi-r4s-rk3399_defconfig| 62 +
5 files changed, 224 insertions(+)
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
create mode 100644 configs/nanopi-r4s-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 858b79ac97..528dfe069e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-evb.dtb \
rk3288-firefly.dtb \
rk3288-miqi.dtb \
+ rk3399-nanopi-r4s.dtb \
rk3288-phycore-rdk.dtb \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
new file mode 100644
index 00..3f97867cc5
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RK3399-based FriendlyElec boards device tree source
+ *
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ * Copyright (C) 2020 Xiaobo
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
+#include "rk3399-sdram-ddr3-1866.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
b/arch/arm/dts/rk3399-nanopi-r4s.dts
new file mode 100644
index 00..6f2cf17bf1
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ * Copyright (C) 2020 Xiaobo
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R4S";
+ compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+ aliases {
+ ethernet1 = &r8169;
+ };
+
+ vdd_5v: vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 12 18 255>;
+ #cooling-cells = <2>;
+ fan-supply = <&vdd_5v>;
+ pwms = <&pwm1 0 5 0>;
+ };
+};
+
+&cpu_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <&cpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <&cpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&emmc_phy {
+ status = "disabled";
+};
+
+&fusb0 {
+ status = "disabled";
+};
+
+&leds {
+ lan_led: led-1 {
+ gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:lan";
+ };
+
+ wan_led: led-2 {
+ gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:wan";
+ };
+};
+
+&leds_gpio {
+ rockchip,pins =
+ <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>,
+ <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>,
+ <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+};
+
+&pcie0 {
+ max-link-speed = <1>;
+ num-lanes = <1>;
+ vpcie3v3-supply = <&vcc3v3_sys>;
+
+ pcie@0 {
+ reg = <0x 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+
Re: arm64: rk3399: Add support nanopi r4s
Will do, thanks! Chen-Yu Tsai 于2021年2月8日周一 下午2:50写道： > Hi, > > On Mon, Feb 8, 2021 at 9:46 AM alex tian wrote: > > > > From 01598339be9dbeec6ba41c470b29af1c53e29c40 Mon Sep 17 00:00:00 2001 > > From: Xiaobo Tian > > Date: Mon, 8 Feb 2021 09:40:03 +0800 > > Subject: [PATCH] arm64: rk3399: Add support NanoPi R4s > > Please tag patches with versions or "resent" if no changes were made. > > Also, your patch is pretty messed up, especially on patchwork. For example, > the indents are all wrong. On patchwork, parts of the diff even end up > out of order or in the header. > > Please do not copy-paste your patch from a terminal window or editor into > your mail client. Instead, use `git send-email` to send patches. > > ChenYu > -- -- Tian Xiaobo )\._.,--,'``. /, _.. \ _\ ;`._ ,. `._.-(,_..'--(,_..'`-.;.' WeChat: Yesloveme QQ: 56775982 Best Regards !
[PATCH] arm64: rk3399: Add support NanoPi R4s
From: Xiaobo Tian
NanoPi R4s is SBC base on Rockchip RK3399 hexa-core processor with
dual-Core Cortex-A72 and Mali-T864 GPU with 4GiB(LPDDR4) of RAM, SD card
support,
including 2 gigabit ethernet(RTL8211E 1Gbps - RTL8111H 1Gbps) and 2 USB 3.0
port.
port.It also has two GPIO headers which allows further peripherals to be used.
The devicetree file is taken of the rk3399 nanopi4 Linux kernel [1].
[1]
https://github.com/torvalds/linux/commit/e7a095908227fb3ccc86d001d9e13c9ae2bef8e6
Signed-off-by: xiaobo
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi | 17 +++
arch/arm/dts/rk3399-nanopi-r4s.dts | 138 +
board/rockchip/evb_rk3399/MAINTAINERS | 6 +
configs/nanopi-r4s-rk3399_defconfig| 62 +
5 files changed, 224 insertions(+)
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
create mode 100644 arch/arm/dts/rk3399-nanopi-r4s.dts
create mode 100644 configs/nanopi-r4s-rk3399_defconfig
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 858b79ac97..528dfe069e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -92,6 +92,7 @@ dtb-$(CONFIG_ROCKCHIP_RK3288) += \
rk3288-evb.dtb \
rk3288-firefly.dtb \
rk3288-miqi.dtb \
+ rk3399-nanopi-r4s.dtb \
rk3288-phycore-rdk.dtb \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
diff --git a/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
new file mode 100644
index 00..3f97867cc5
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s-u-boot.dtsi
@@ -0,0 +1,17 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * RK3399-based FriendlyElec boards device tree source
+ *
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ * Copyright (C) 2020 Xiaobo
+ */
+
+#include "rk3399-nanopi4-u-boot.dtsi"
+#include "rk3399-sdram-lpddr4-100.dtsi"
+#include "rk3399-sdram-ddr3-1866.dtsi"
diff --git a/arch/arm/dts/rk3399-nanopi-r4s.dts
b/arch/arm/dts/rk3399-nanopi-r4s.dts
new file mode 100644
index 00..6f2cf17bf1
--- /dev/null
+++ b/arch/arm/dts/rk3399-nanopi-r4s.dts
@@ -0,0 +1,138 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright (c) 2016 Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * Copyright (c) 2018 FriendlyElec Computer Tech. Co., Ltd.
+ * (http://www.friendlyarm.com)
+ *
+ * Copyright (c) 2018 Collabora Ltd.
+ * Copyright (c) 2019 Arm Ltd.
+ * Copyright (C) 2020 Xiaobo
+ */
+
+/dts-v1/;
+#include "rk3399-nanopi4.dtsi"
+
+/ {
+ model = "FriendlyElec NanoPi R4S";
+ compatible = "friendlyarm,nanopi-r4s", "rockchip,rk3399";
+
+ aliases {
+ ethernet1 = &r8169;
+ };
+
+ vdd_5v: vdd-5v {
+ compatible = "regulator-fixed";
+ regulator-name = "vdd_5v";
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ cooling-levels = <0 12 18 255>;
+ #cooling-cells = <2>;
+ fan-supply = <&vdd_5v>;
+ pwms = <&pwm1 0 5 0>;
+ };
+};
+
+&cpu_thermal {
+ trips {
+ cpu_warm: cpu_warm {
+ temperature = <55000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+
+ cpu_hot: cpu_hot {
+ temperature = <65000>;
+ hysteresis = <2000>;
+ type = "active";
+ };
+ };
+
+ cooling-maps {
+ map2 {
+ trip = <&cpu_warm>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map3 {
+ trip = <&cpu_hot>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+&emmc_phy {
+ status = "disabled";
+};
+
+&fusb0 {
+ status = "disabled";
+};
+
+&leds {
+ lan_led: led-1 {
+ gpios = <&gpio1 RK_PA1 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:lan";
+ };
+
+ wan_led: led-2 {
+ gpios = <&gpio1 RK_PA0 GPIO_ACTIVE_HIGH>;
+ label = "nanopi-r4s:green:wan";
+ };
+};
+
+&leds_gpio {
+ rockchip,pins =
+ <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>,
+ <1 RK_PA0 RK_FUNC_GPIO &pcfg_pull_none>,
+ <1 RK_PA1 RK_FUNC_GPIO &pcfg_pull_none>;
+};
+
+&pcie0 {
+ max-link-speed = <1>;
+ num-lanes = <1>;
+ vpcie3v3-supply = <&vcc3v3_sys>;
+
+ pcie@0 {
+ reg = <0x 0 0 0 0>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+
+
Re: [PATCH v4 10/16] dm: gpio: Add a way to update flags
On Thu, 4 Feb 2021 21:22:03 -0700 Simon Glass wrote: > It is convenient to be able to adjust some of the flags for a GPIO while > leaving others alone. Add a function for this. > > Update dm_gpio_set_dir_flags() to make use of this. > > Also update dm_gpio_set_value() to use this also, since this allows the > open-drain / open-source features to be implemented directly in the > driver, rather than using the uclass workaround. > > Update the sandbox tests accordingly. This involves a lot of changes to > dm_test_gpio_opendrain_opensource() since we no-longer have the direciion > being reported differently depending on the open drain/open source flags. > > Also update the STM32 drivers to let the uclass handle the active low/high > logic. > > Drop the GPIOD_FLAGS_OUTPUT() macro which is no-longer used. > > Signed-off-by: Simon Glass > --- > > Changes in v4: > - Update dm_gpio_set_dir_flags() to clear direction flags first > > Changes in v3: > - Incorporate GPIOD_FLAGS_OUTPUT() changes from Patrick Delaunay > > drivers/gpio/gpio-uclass.c | 75 ++ > drivers/gpio/stm32_gpio.c | 3 +- > drivers/pinctrl/pinctrl-stmfx.c | 5 +- > include/asm-generic/gpio.h | 31 ++-- > test/dm/gpio.c | 132 > 5 files changed, 203 insertions(+), 43 deletions(-) > Tested-by: Kory Maincent
[PATCH v5] arm: fsl: common: Improve NXP VID driver PMBus support
From: Stephen Carlson
This patch adds support for more PMBus compatible devices to the NXP
drivers for its QorIQ family devices. At runtime, the voltage regulator is
queried over I2C, and the required voltage multiplier determined. This
change supports the DIRECT and LINEAR PMBus voltage reporting modes.
Previously, the driver only supported a few specific devices such as the
IR36021 and LTC3882, so this change allows the QorIQ series to be used
with a much larger variety of core voltage regulator devices.
checkpatch warning "Use if (IS_DEFINED (...))" was ignored to maintain
consistency with the existing code.
Signed-off-by: Stephen Carlson
Signed-off-by: Wasim Khan
Tested-by: Wasim Khan
---
Changes in v5:
- fix compilation issues on ls2080a_emu and ls2080a_simu
- fix compilation issues on powerpc platforms
Changes in v4:
- Included upstream commit ada19fd2
- compilation fix for platforms using IR36021
- read_voltage() fix for devices using INA220
- compilation fix for ls1088
- removed soc_get_fuse_vid() support for ls1028
board/freescale/common/Kconfig | 27 +-
board/freescale/common/vid.c| 820 ++--
board/freescale/common/vid.h| 11 +-
board/freescale/ls1088a/ls1088a.c | 40 ++
board/freescale/ls2080ardb/ls2080ardb.c | 42 ++
board/freescale/lx2160a/lx2160a.c | 42 ++
include/configs/ls1088aqds.h| 6 -
include/configs/ls1088ardb.h| 8 +-
8 files changed, 477 insertions(+), 519 deletions(-)
diff --git a/board/freescale/common/Kconfig b/board/freescale/common/Kconfig
index 1b1fd69cb2..17db755951 100644
--- a/board/freescale/common/Kconfig
+++ b/board/freescale/common/Kconfig
@@ -21,18 +21,37 @@ config CMD_ESBC_VALIDATE
esbc_validate - validate signature using RSA verification
esbc_halt - put the core in spin loop (Secure Boot Only)
+config VID
+ depends on DM_I2C
+ bool "Enable Freescale VID"
+ help
+This option enables setting core voltage based on individual
+values saved in SoC fuses.
+
config VOL_MONITOR_LTC3882_READ
depends on VID
bool "Enable the LTC3882 voltage monitor read"
- default n
help
This option enables LTC3882 voltage monitor read
-functionality. It is used by common VID driver.
+functionality. It is used by the common VID driver.
config VOL_MONITOR_LTC3882_SET
depends on VID
bool "Enable the LTC3882 voltage monitor set"
- default n
help
This option enables LTC3882 voltage monitor set
-functionality. It is used by common VID driver.
+functionality. It is used by the common VID driver.
+
+config VOL_MONITOR_ISL68233_READ
+ depends on VID
+ bool "Enable the ISL68233 voltage monitor read"
+ help
+This option enables ISL68233 voltage monitor read
+functionality. It is used by the common VID driver.
+
+config VOL_MONITOR_ISL68233_SET
+ depends on VID
+ bool "Enable the ISL68233 voltage monitor set"
+ help
+This option enables ISL68233 voltage monitor set
+functionality. It is used by the common VID driver.
diff --git a/board/freescale/common/vid.c b/board/freescale/common/vid.c
index 2617f61520..845d5f6a89 100644
--- a/board/freescale/common/vid.c
+++ b/board/freescale/common/vid.c
@@ -2,6 +2,7 @@
/*
* Copyright 2014 Freescale Semiconductor, Inc.
* Copyright 2020 NXP
+ * Copyright 2020 Stephen Carlson
*/
#include
@@ -21,14 +22,22 @@
#include
#include "vid.h"
+/* Voltages are generally handled in mV to keep them as integers */
+#define MV_PER_V 1000
+
+/*
+ * Select the channel on the I2C mux (on some NXP boards) that contains
+ * the voltage regulator to use for VID. Return 0 for success or nonzero
+ * for failure.
+ */
int __weak i2c_multiplexer_select_vid_channel(u8 channel)
{
return 0;
}
/*
- * Compensate for a board specific voltage drop between regulator and SoC
- * return a value in mV
+ * Compensate for a board specific voltage drop between regulator and SoC.
+ * Returns the voltage offset in mV.
*/
int __weak board_vdd_drop_compensation(void)
{
@@ -36,13 +45,94 @@ int __weak board_vdd_drop_compensation(void)
}
/*
- * Board specific settings for specific voltage value
+ * Performs any board specific adjustments after the VID voltage has been
+ * set. Return 0 for success or nonzero for failure.
*/
int __weak board_adjust_vdd(int vdd)
{
return 0;
}
+/*
+ * Processor specific method of converting the fuse value read from VID
+ * registers into the core voltage to supply. Return the voltage in mV.
+ */
+u16 __weak soc_get_fuse_vid(int vid_index)
+{
+ /* Default VDD for Layerscape Chassis 1 devices */
+ static const u16 vdd[32] = {
+ 0, /* unused */
+ 9875, /* 0.9875V */
+ 9750,
+ 9625,
+ 9500,
+
pull request of u-boot-fsl-qoriq for v2021.04
Dear Tom, Please find my pull-request for u-boot-fsl-qoriq/master https://github.com/u-boot/u-boot/pull/52/checks Summary Layerscape: Enable gpio Bug fixes & updates related to dspi, qspi, pciep, SVR mask, stream-id, env variables, mdio for LAyerscape Platforms Add SATA, network variant 1, 2 support on sl28 powerpc: T1042: drop CONFIG_VIDEO, Add kmcent2 board supporrt, keymile Bug fixes and updates for keymile, Kontron Thanks Priyanka --- The following changes since commit 3936fd998668846f77468d8f6a662e906920969c: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2021-02-06 09:45:58 -0500) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git HEAD for you to fetch changes up to 5e7a207ebf8501b4ab1c6a081b7b806698ce0f6d: configs: lx2160aqds: enable CMD_GPIO (2021-02-08 14:22:39 +0530) Aleksandar Gerasimovski (4): board: keymile: common: fix qrio compilation for arm keymile: common: qrio: print QRIO id and revision number board/km/common: fix pnvramaddr and varaddr board/km: move km i2c deblock declarations to a km/common.h Biwen Li (34): configs: ls1088aqds: add COMMON_ENV to fix distroboot gpio: mpc8xxx_gpio: Fix for litte endian arm: dts: ls1021a: add gpio node arm64: dts: ls1012a: add gpio node arm64: dts: ls1028a: add gpio node arm64: dts: ls1043a: add gpio node arm64: dts: ls1046a: add gpio node arm64: dts: ls1088a: add gpio node arm64: dts: ls208xa: add gpio node configs: ls1012a: enable CONFIG_MPC8XXX_GPIO configs: ls1043a: enable CONFIG_MPC8XXX_GPIO configs: ls1028a: enable CONFIG_MPC8XXX_GPIO configs: ls1088a: enable CONFIG_MPC8XXX_GPIO configs: ls208xa: enable CONFIG_MPC8XXX_GPIO configs: lx2160a: enable CONFIG_MPC8XXX_GPIO configs: ls1046a: enable MPC8XXX_GPIO configs: ls1021atwr: enable CONFIG_MPC8XXX_GPIO configs: ls1021aqds: enable CONFIG_MPC8XXX_GPIO configs: ls1012afrwy: enable CMD_GPIO configs: ls1012ardb: enable CMD_GPIO configs: ls1021aqds: enable CMD_GPIO configs: ls1021atwr: enable CMD_GPIO configs: ls1028aqds: enable CMD_GPIO configs: ls1028ardb: enable CMD_GPIO configs: ls1043aqds: enable CMD_GPIO configs: ls1043ardb: enable CMD_GPIO configs: ls1046ardb: enable CMD_GPIO configs: ls1046aqds: enable CMD_GPIO configs: ls2088ardb: enable DM_GPIO and CMD_GPIO configs: ls2088aqds: enable CMD_GPIO configs: ls1088aqds: enable DM_GPIO and CMD_GPIO configs: ls1088ardb: enable DM_GPIO and CMD_GPIO configs: lx2160ardb: enable CMD_GPIO configs: lx2160aqds: enable CMD_GPIO Hou Zhiqiang (4): pci: layerscape: Remove the shadow SVR definitions pci: kconfig: layerscape: Change LX2162A PCIe node compatible string armv7: ls102xa: Enable I-Cache to speed up the boot time configs: T1042: Drop the CONFIG_VIDEO Ioana Ciornei (1): net: memac_phy: add a timeout to MDIO operations Mathew McBride (3): mem: spi-mem: add declaration for spi_mem_default_supports_op spi: fsl_qspi: Ensure width is respected in spi-mem operations spi: fsl_qspi: apply the same settings for LS1088 as LS208x Michael Walle (6): mtd: spi-nor: add unlock all config option board: kontron: disable flash unlock all board: sl28: move ethernet aliases to variant specific dtsi board: sl28: add network variant 1 support board: sl28: add network variant 2 support board: sl28: add SATA support Niel Fourie (3): PowerPC: dts: Pulled in kmcent2 dts files from Linux 5.10 keymile: common: update to set_env_hex(), fix "pram" radix PowerPC: keymile: Add support for kmcent2 board Nipun Gupta (1): armv8: ls1028a: fix stream id allocation Priyanka Jain (1): mpc8xxx: fsl_pamu: Update data type in config_pamu Wasim Khan (2): armv8: lx2162aqds: disable non existing pcie controllers armv8: lx2: SVR_SOC_VER: Mask CAN_FD and security bit Ye Li (1): net: eqos: Reduce the MDIO wait time Zhao Qiang (1): armv8: dts: fsl-lx2162a: add dspi node into qds dts arch/arm/cpu/armv7/ls102xa/cpu.c | 2 + arch/arm/dts/Makefile | 2 + arch/arm/dts/fsl-ls1012a.dtsi | 20 + arch/arm/dts/fsl-ls1028a-kontron-sl28-u-boot.dtsi | 62 +- .../dts/fsl-ls1028a-kontron-sl28-var1-u-boot.dtsi | 8 + arch/arm/dts/fsl-ls1028a-kontron-sl28-var1.dts | 57 ++ .../dts/fsl-ls1028a-kontron-sl28-var2-u-boot.dtsi | 2 + arch/arm/dts/fsl-ls1028a-kontron-sl28-var2.dts | 25 + .../dts/fsl-ls1028a-kontron-sl28-var3-u-boot.dtsi | 6 + .../dts/fsl-ls1028a-kontron-sl28-var4-u-boot.dtsi | 7 + arch/arm/dts/fsl-ls1028a-kontron-sl28.dts | 4 + arch/arm/dts/fsl-ls1028a.dtsi
Re: [PATCH 0/3] arm: mvebu: Espressobin: Set default env values at runtime
On 23.12.20 12:21, Pali Rohár wrote: This patch series set default env values of $fdtfile and $ethNaddr for Espressobin board at runtime. It fixes two main issues on Espressobin board that 'env default -a' completely erases permanent board MAC addresses and also erase $fdtfile variable which is needed for booting Linux kernel via distro boot. Lot of people were complaining about erasing permanent MAC addresses by U-boot on this board and due to this issue some linux distributions started using static hardcoded MAC addresses for all Espressobin boards to workaround this issue. Apparently erase of MAC addresses or usage of static hardcoded value caused more issues on network (e.g. inability to connect two of these boards to the same network). Pali Rohár (3): env: Allow to set default_environment[] from board code via compile option DEFAULT_ENV_IS_RW arm: mvebu: Espressobin: Set default value for $fdtfile env variable arm: mvebu: Espressobin: Set default value for $ethNaddr env variable board/Marvell/mvebu_armada-37xx/board.c | 41 - include/configs/mvebu_armada-37xx.h | 17 +- include/env_default.h | 2 ++ include/env_internal.h | 4 +++ 4 files changed, 56 insertions(+), 8 deletions(-) Applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH v1] test: Allow simple glob pattern in the test name
On Sun, Feb 07, 2021 at 07:37:55AM -0700, Simon Glass wrote: > On Fri, 5 Feb 2021 at 13:46, Andy Shevchenko > wrote: > > On Fri, Feb 05, 2021 at 09:17:27PM +0200, Andy Shevchenko wrote: > > > On Fri, Feb 05, 2021 at 08:15:25PM +0200, Andy Shevchenko wrote: > > > > On Fri, Feb 05, 2021 at 07:34:49PM +0200, Andy Shevchenko wrote: > > > > > On Thu, Feb 04, 2021 at 08:17:24PM -0700, Simon Glass wrote: > > > > > > > > ... > > > > > > > > > Btw, you have an issue there, i.e. if test case failed, all > > > > > percentage after it > > > > > goes red, which is wrong. > > > > > > > > One more thing, is it known bug that either in the original code, or in > > > > your > > > > new branch the following test case is 100% failed? > > > > > > > > /* Non-existent in DTB */ > > > > ut_asserteq(FDT_ADDR_T_NONE, dev_read_addr(dev)); > > > > > > > > Can you fix this sooner than later, please? > > > > > > Actually it seems this very patch makes the issue visible (I suppose > > > something > > > with test case names). > > > > Okay, actually there *is* a problem with the test suite, i.e. you may not > > run > > some test cases twice during the same session. > > If this is related to the squashfs tests? I have disabled them for now > in my local tree. I don't think it's related to the certain test case, it's a test suite design issue and how some of the test cases have been written. So, if you run u-boot application and manually run `ut dm` in there, - first time: Failures: 0 - second time: Failures: 9 - third and next time: Failures: 12 Means that 12 test cases are written badly. -- With Best Regards, Andy Shevchenko
Re: [PATCH] pci: pci_mvebu: Disable config access to PCI host bridge ports
On 25.01.21 15:25, Stefan Roese wrote: This patch changes the PCI config routines in the Armada XP / 38x driver to not allow access to the PCIe root ports. While updating the Armada XP based theadorable to the latest mainline and testing it with the DM PCI driver I noticed, that the PCI root bridge was being configured incorrectly. Resulting in the PCIe Intel WiFi was not working correctly in Linux. With this patch applied, all PCIe devices work without any issues in Linux again. Signed-off-by: Stefan Roese Cc: Marek Behún Cc: Phil Sutter Cc: Mario Six Applied to u-boot-marvell/master Thanks, Stefan
[PATCH v4] fastboot: add UUU command UCmd and ACmd support
add support for the UUU commands ACmd and UCmd.
Enable them through the Kconfig option
CONFIG_FASTBOOT_UUU_SUPPORT
base was commit in NXP kernel
9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support")
and ported it to current mainline. Tested this patch
on imx6ul based board.
Signed-off-by: Heiko Schocher
---
azure build was fine:
https://dev.azure.com/hs0298/hs/_build/results?buildId=59&view=results
Changes in v4:
- fixed missing parts from Sean Anderson patches
lost while rebased to tree from lukasz
Changes in v3:
- rebased to https://github.com/lmajewski/u-boot-dfu/commits/testing
as Lukasz mentioned.
Changes in v2:
- remove unused FSL_FASTBOOT option
- add comment from Roman:
do not enable this option per default
add Kconfig comment that enabling this option may
introduce a security issue.
doc/android/fastboot-protocol.rst | 5 +++
doc/android/fastboot.rst | 2 +
drivers/fastboot/Kconfig | 9 +
drivers/fastboot/fb_command.c | 62 +++
drivers/usb/gadget/f_fastboot.c | 17 +
include/fastboot.h| 7
6 files changed, 102 insertions(+)
diff --git a/doc/android/fastboot-protocol.rst
b/doc/android/fastboot-protocol.rst
index e723659e49c..e8cbd7f24ea 100644
--- a/doc/android/fastboot-protocol.rst
+++ b/doc/android/fastboot-protocol.rst
@@ -144,6 +144,11 @@ Command Reference
"powerdown" Power off the device.
+ "ucmd" execute any bootloader command and wait until it
+ finishs.
+
+ "acmd" execute any bootloader command, do not wait.
+
Client Variables
diff --git a/doc/android/fastboot.rst b/doc/android/fastboot.rst
index ce513a2a0f2..7611f07038e 100644
--- a/doc/android/fastboot.rst
+++ b/doc/android/fastboot.rst
@@ -19,6 +19,8 @@ The current implementation supports the following standard
commands:
- ``reboot``
- ``reboot-bootloader``
- ``set_active`` (only a stub implementation which always succeeds)
+- ``ucmd`` (if enabled)
+- ``acmd`` (if enabled)
The following OEM commands are supported (if enabled):
diff --git a/drivers/fastboot/Kconfig b/drivers/fastboot/Kconfig
index a17e488714d..2d1836a80e0 100644
--- a/drivers/fastboot/Kconfig
+++ b/drivers/fastboot/Kconfig
@@ -72,6 +72,15 @@ config FASTBOOT_FLASH
the downloaded image to a non-volatile storage device. Define
this to enable the "fastboot flash" command.
+config FASTBOOT_UUU_SUPPORT
+ bool "Enable FASTBOOT i.MX UUU special command"
+ default n
+ help
+ The fastboot protocol includes "UCmd" and "ACmd" command.
+ Be aware that you provide full access to any U-Boot command,
+ including working with memory and may open a huge backdoor,
+ when enabling this option.
+
choice
prompt "Flash provider for FASTBOOT"
depends on FASTBOOT_FLASH
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 41fc8d7904d..960e73089e0 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
@@ -49,6 +49,11 @@ static void oem_partconf(char *, char *);
static void oem_bootbus(char *, char *);
#endif
+#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
+static void run_ucmd(char *, char *);
+static void run_acmd(char *, char *);
+#endif
+
static const struct {
const char *command;
void (*dispatch)(char *cmd_parameter, char *response);
@@ -117,6 +122,16 @@ static const struct {
.dispatch = oem_bootbus,
},
#endif
+#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
+ [FASTBOOT_COMMAND_UCMD] = {
+ .command = "UCmd",
+ .dispatch = run_ucmd,
+ },
+ [FASTBOOT_COMMAND_ACMD] = {
+ .command = "ACmd",
+ .dispatch = run_acmd,
+ },
+#endif
};
/**
@@ -327,6 +342,53 @@ static void erase(char *cmd_parameter, char *response)
}
#endif
+#if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT)
+/**
+ * run_ucmd() - Execute the UCmd command
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void run_ucmd(char *cmd_parameter, char *response)
+{
+ if (!cmd_parameter) {
+ pr_err("missing slot suffix\n");
+ fastboot_fail("missing command", response);
+ return;
+ }
+
+ if (run_command(cmd_parameter, 0))
+ fastboot_fail("", response);
+ else
+ fastboot_okay(NULL, response);
+}
+
+static char g_a_cmd_buff[64];
+
+void fastboot_acmd_complete(void)
+{
+ run_command(g_a_cmd_buff, 0);
+}
+
+/**
+ * run_acmd() - Execute the ACmd command
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void run_acmd(char *cmd_parameter, char *response)
+{
+ if (!cmd_parameter) {
+ pr_err("missing slot suffix\n");
+
Re: [PATCH 1/2] arm: mvebu: theadorable: Enhance "pcie" test cmd to check link width/speed
On 25.01.21 15:27, Stefan Roese wrote: This patch changes the board specific "pcie" U-Boot command to not only check for PCIe device existance but also for the correct link speed and width that has been established. This cmd can be used by U-Boot scripts for automated testing, if the PCIe setup is correct. Meaning, that all PCIe devices are correctly detected and the link speed and width is corrent. Signed-off-by: Stefan Roese Applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH 2/2] arm: mvebu: theadorable: Set deephasis bit in PCIe configs very early
On 25.01.21 15:27, Stefan Roese wrote: Testing has shown, that the quality of the PCIe signals and also the stability of correct link establishment on the 2 PCIe ports is better, when the deemphasis bit is set in the PCIe config register. This needs to be done very early, even before the SERDES setup code is run. This way, the first link will already be established with this setup. Signed-off-by: Stefan Roese Applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH] cmd: mvebu/bubt: Fix default options in help
On 27.01.21 11:56, Pali Rohár wrote: Default options depends on compile time defines. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH] arm: mvebu: Espressobin: Set the maximum slave SPI speed to 40MHz
On 27.01.21 17:12, Pali Rohár wrote: From: Konstantin Porotchkin While the SPI controller speed is defined by DTS, the maximum slave speed (connected devices) is limited by the pre-defined configuration value CONFIG_SF_DEFAULT_SPEED to 1MHz This patch increases this maximum SPI slave device speed to 40MHz Change-Id: I0d1239bd8a2061c66725c2c227c1e1f49c92c29e Signed-off-by: Konstantin Porotchkin Reviewed-on: http://vgitil04.il.marvell.com:8080/59516 Tested-by: iSoC Platform CI Reviewed-by: Igal Liberman [pali: Set CONFIG_SF_DEFAULT_SPEED via defconfig] Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan
Re: [PATCH u-boot-marvell] mmc: mv_sdhci: call mmc_of_parse()
On 04.02.21 17:38, Marek Behún wrote: On Thu, 4 Feb 2021 07:18:23 +0900 Jaehoon Chung wrote: Commit da18c62b6e6a causes the regression. The Fixes tag, as I understand, should link to commit with which the regression first occured, so that if someone wanted to backport my patch to previous version of U-Boot, they would know that they only have to do it if their repository contains that commit. Well, i don't think so. This patch is not a bug fix patch about commit da18c62b6e6a. Just mv_sdhci driver didn't use mmc_of_parse() before. (If someone set to MMC_NON_REMOVABLE capabilities in host->cap, it should be working.) Not need to add *Fixes*. Its commit is a generic callback function. And mmc_of_parse() is also generic function to use Driver-model. Lets apply Baruch's version. I don't really care if the Fixes tag is there or not... I'll pull in Baruch's patch now. Thanks, Stefan
Re: [PATCH] mmc: mv_sdhci: parse device-tree entry
On 02.02.21 07:43, Baruch Siach wrote: Call mmc_of_parse() so that generic DT properties like 'non-removable' are taken into account. This fixes boot on Clearfog with eMMC on SOM that requires the non-removable property. Reported-by: Thorsten Spille Signed-off-by: Baruch Siach Applied to u-boot-marvell/master Thanks, Stefan
Please pull u-boot-marvell/master
Hi Tom, please pull the 2nd batch of Marvell MVEBU related patches. Here the summary log: - Espressobin: Set default env values at runtime (Pali) - Espressobin: Set the maximum slave SPI speed to 40MHz (Pali) - theadorable: PCIe test code enhancement and early deemphasis enabling (Stefan) - pci_mvebu: Disable config access to PCI host bridge ports (Stefan) - mv_sdhci: parse device-tree entry (Baruch) Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=69&view=results Thanks, Stefan The following changes since commit 3936fd998668846f77468d8f6a662e906920969c: Merge https://gitlab.denx.de/u-boot/custodians/u-boot-x86 (2021-02-06 09:45:58 -0500) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 24a0f8cfe5c85aef5a20baf34ee7b77004b07b04: mmc: mv_sdhci: parse device-tree entry (2021-02-08 08:53:14 +0100) Baruch Siach (1): mmc: mv_sdhci: parse device-tree entry Konstantin Porotchkin (1): arm: mvebu: Espressobin: Set the maximum slave SPI speed to 40MHz Pali Rohár (4): env: Allow to set default_environment[] from board code via compile option DEFAULT_ENV_IS_RW arm: mvebu: Espressobin: Set default value for $fdtfile env variable arm: mvebu: Espressobin: Set default value for $ethNaddr env variable cmd: mvebu/bubt: Fix default options in help Stefan Roese (3): pci: pci_mvebu: Disable config access to PCI host bridge ports arm: mvebu: theadorable: Enhance "pcie" test cmd to check link width/speed arm: mvebu: theadorable: Set deephasis bit in PCIe configs very early board/Marvell/mvebu_armada-37xx/board.c | 38 +++- board/theadorable/theadorable.c | 132 +++- cmd/mvebu/bubt.c| 6 +- configs/mvebu_espressobin-88f3720_defconfig | 1 + drivers/mmc/mv_sdhci.c | 4 + drivers/pci/pci_mvebu.c | 66 ++ include/configs/mvebu_armada-37xx.h | 17 +++- include/env_default.h | 2 + include/env_internal.h | 4 + 9 files changed, 202 insertions(+), 68 deletions(-)
Re: [PATCH 4/6] usb: xhci-pci: Move reset logic out of XHCI core
On 2/8/21 6:57 AM, Samuel Holland wrote: Resetting an XHCI controller inside xhci_register undoes any register setup performed by the platform driver. And at least on the Allwinner H6, resetting the XHCI controller also resets the PHY, which prevents the controller from working. That means the controller must be taken out of reset before initializing the PHY, which must be done before calling xhci_register. The logic in the XHCI core was added to support the Raspberry Pi 4 (although this was not mentioned in the commit log!), which uses the xhci-pci platform driver. Move the reset logic to the platform driver, where it belongs, and where it cannot interfere with other platform drivers. Are there any other XHCI drivers using the XHCI core code which might stop resetting correctly due to this patch ?
Re: [PATCH] usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()
Hi Marek,
Hi Bin,
On 15.01.21 08:52, Stefan Roese wrote:
Testing with v2021.01 on MIPS Octeon has shown, that the latest patch
for the "short packet event trb handling" did introduce a bug on
platforms with virtual address != physical address. This patch fixes
this issue by using the correct address types in the compare (both
physical in this case).
Signed-off-by: Stefan Roese
Cc: Aaron Williams
Cc: Chandrakala Chavva
Cc: Ran Wang
Cc: Nicolas Saenz Julienne
Cc: Marek Vasut
Cc: Bin Meng
If you see no issues with this patch, can you please pull this in
soon'ish?
Thanks,
Stefan
---
drivers/usb/host/xhci-ring.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c
index d708fc928b..d6c47d579b 100644
--- a/drivers/usb/host/xhci-ring.c
+++ b/drivers/usb/host/xhci-ring.c
@@ -723,8 +723,8 @@ again:
return -ETIMEDOUT;
}
- if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer))
- != (uintptr_t)last_transfer_trb_addr) {
+ if ((uintptr_t)(le64_to_cpu(event->trans_event.buffer)) !=
+ (uintptr_t)virt_to_phys(last_transfer_trb_addr)) {
available_length -=
(int)EVENT_TRB_LEN(le32_to_cpu(event->trans_event.transfer_len));
xhci_acknowledge_event(ctrl);
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
Re: [PATCH] usb: xhci: Fix compare to use physical addresses in xhci_bulk_tx()
On 2/8/21 1:39 PM, Stefan Roese wrote: Hi Marek, Hi Bin, On 15.01.21 08:52, Stefan Roese wrote: Testing with v2021.01 on MIPS Octeon has shown, that the latest patch for the "short packet event trb handling" did introduce a bug on platforms with virtual address != physical address. This patch fixes this issue by using the correct address types in the compare (both physical in this case). Applied to usb/next (that's still in the pipeline for this release), thanks.
[PATCH 0/2] 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 platfrom. The test executes from the u-boot shell with "ut lib". Note: I've removed the RFC tag that was previously used to post this patch. 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 cration unit test cmd/efidebug.c| 4 + include/efi_api.h | 21 ++ include/efi_loader.h | 19 ++ lib/efi_loader/Kconfig| 7 + lib/efi_loader/Makefile | 1 + lib/efi_loader/efi_boottime.c | 2 - lib/efi_loader/efi_capsule.c | 7 + lib/efi_loader/efi_esrt.c | 439 ++ lib/efi_loader/efi_setup.c| 6 + test/lib/Makefile | 1 + test/lib/efi_esrt.c | 188 +++ 11 files changed, 693 insertions(+), 2 deletions(-) create mode 100644 lib/efi_loader/efi_esrt.c create mode 100644 test/lib/efi_esrt.c -- 2.17.1
[PATCH 1/2] efi: Add ESRT to the EFI system table
The ESRT is initialised during efi_init_objlist after
efi_initialize_system_table().
The ESRT is initially created with size for 50 FW image entries.
The ESRT is resized when it runs out of space. Every resize adds 50
additional entries.
The ESRT is populated from information provided by FMP instances only.
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 | 19 ++
lib/efi_loader/Kconfig| 7 +
lib/efi_loader/Makefile | 1 +
lib/efi_loader/efi_boottime.c | 2 -
lib/efi_loader/efi_capsule.c | 7 +
lib/efi_loader/efi_esrt.c | 439 ++
lib/efi_loader/efi_setup.c| 6 +
9 files changed, 504 insertions(+), 2 deletions(-)
create mode 100644 lib/efi_loader/efi_esrt.c
diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 83bc2196a5..4160dde1cf 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -458,6 +458,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..7eb15bd44c 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;
+ uint32_t fw_type;
+ uint32_t fw_version;
+ uint32_t lowest_supported_fw_version;
+ uint32_t capsule_flags;
+ uint32_t last_attempt_version;
+ uint32_t last_attempt_status;
+} __packed;
+
+struct efi_system_resource_table {
+ uint32_t fw_resource_count;
+ uint32_t fw_resource_count_max;
+ uint64_t 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..c85c540041 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -884,4 +884,23 @@ 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_add_from_fmp() - Populates a sequence of ESRT entries from the FW
+ * images in the FMP.
+ *
+ * @fmp:the fmp from which fw images are added to the ESRT
+ *
+ * Return:
+ * - EFI_SUCCESS if all the FW images in the FMP are added to the ESRT
+ * - Error status otherwise
+ */
+efi_status_t efi_esrt_add_from_fmp(struct efi_firmware_management_protocol
*fmp);
+
#endif /* _EFI_LOADER_H */
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index e729f727df..12b29180a0 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_LOADER
+ 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..dec791b310 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) += efi_var_seed.o
endif
obj-y += efi_watchdog.o
+obj-y += efi_esrt.o
obj-$(CONFIG_LCD) += efi_gop.o
obj-$(CONFIG_DM_VIDEO) += efi_gop.o
obj-$(CONFIG_PARTITIONS) += efi_disk.o
diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
index ce658a8e73..9b0b15571a 100644
--- a/lib/efi_loader/efi_boottime.c
+++ b/lib/efi_loader/efi_boottime.c
@@ -1148,8 +1148,6 @@ efi_status_t efi_add_protocol(const efi_handle_t handle,
}
}
- if (!guidcmp(&efi_guid_device_path, protocol))
- EFI_PRINT("installed device path '%pD'\n", protocol_interface);
return EF
[PATCH 2/2] efi: ESRT cration unit test
This commit exercises the ESRT creation -- introduced in the previous
commit.
A fake FMP, controlling TEST_ESRT_NUM_ENTRIES, is installed in the system
leading to the corresponding ESRT entries being populated.
The ESRT entries are checked against the FMP initialization input
datastructure.
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
---
test/lib/Makefile | 1 +
test/lib/efi_esrt.c | 188
2 files changed, 189 insertions(+)
create mode 100644 test/lib/efi_esrt.c
diff --git a/test/lib/Makefile b/test/lib/Makefile
index 97c11e35a8..687e791db0 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -15,3 +15,4 @@ obj-$(CONFIG_UT_LIB_ASN1) += asn1.o
obj-$(CONFIG_UT_LIB_RSA) += rsa.o
obj-$(CONFIG_AES) += test_aes.o
obj-$(CONFIG_GETOPT) += getopt.o
+obj-y += efi_esrt.o
diff --git a/test/lib/efi_esrt.c b/test/lib/efi_esrt.c
new file mode 100644
index 00..3c9d1de731
--- /dev/null
+++ b/test/lib/efi_esrt.c
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Test ESRT tables support
+ *
+ * Copyright (C) 2021 Arm Ltd.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define TEST_ESRT_NUM_ENTRIES 255
+
+#if 0x100 < TEST_ESRT_NUM_ENTRIES
+#error TEST_ESRT_NUM_ENTRIES must be lower or equal to 255.
+#endif
+
+static
+struct efi_firmware_image_descriptor static_img_info[TEST_ESRT_NUM_ENTRIES];
+static const efi_guid_t esrt_guid = EFI_SYSTEM_RESOURCE_TABLE_GUID;
+
+static void efi_test_esrt_init_info(void)
+{
+ for (int idx = 0; idx < TEST_ESRT_NUM_ENTRIES; idx++) {
+ static_img_info[idx].image_index = 1;
+
+ // Note: the 16 byte value present in
+ // static_img_info[idx].image_type_id is not strictly a GUID.
+ // The value is used for the sake of code testing.
+ static_img_info[idx].image_type_id.b[0] = idx;
+
+ static_img_info[idx].image_id = 0;
+ static_img_info[idx].image_id_name = NULL;
+ static_img_info[idx].version = 0;
+ static_img_info[idx].version_name = NULL;
+ static_img_info[idx].size = 0;
+ static_img_info[idx].lowest_supported_image_version = 1;
+ static_img_info[idx].last_attempt_version = 2;
+ static_img_info[idx].last_attempt_status = 3;
+ static_img_info[idx].hardware_instance = 1;
+ }
+}
+
+static efi_status_t
+EFIAPI efi_test_fmp_get_image_info(struct efi_firmware_management_protocol
*this,
+ efi_uintn_t *image_info_size,
+ struct efi_firmware_image_descriptor
*image_info,
+ u32 *descriptor_version,
+ u8 *descriptor_count,
+ efi_uintn_t *descriptor_size,
+ u32 *package_version,
+ u16 **package_version_name)
+{
+ efi_status_t ret = EFI_SUCCESS;
+
+ EFI_ENTRY("%p %p %p %p %p %p %p %p\n", this,
+ image_info_size, image_info,
+ descriptor_version, descriptor_count, descriptor_size,
+ package_version, package_version_name);
+
+ if (!image_info_size)
+ return EFI_EXIT(EFI_INVALID_PARAMETER);
+
+ if (descriptor_version)
+ *descriptor_version = EFI_FIRMWARE_IMAGE_DESCRIPTOR_VERSION;
+ if (descriptor_count)
+ *descriptor_count = TEST_ESRT_NUM_ENTRIES;
+ if (descriptor_size)
+ *descriptor_size = sizeof(*image_info);
+ if (package_version)
+ *package_version = 0x;
+ if (package_version_name)
+ *package_version_name = NULL;
+
+ if (*image_info_size < sizeof(*image_info)) {
+ *image_info_size = *descriptor_size * *descriptor_count;
+ return EFI_EXIT(EFI_BUFFER_TOO_SMALL);
+ }
+
+ for (int idx = 0; idx < TEST_ESRT_NUM_ENTRIES; idx++)
+ image_info[idx] = static_img_info[idx];
+
+ return EFI_EXIT(ret);
+}
+
+struct efi_firmware_management_protocol efi_test_fmp = {
+ .get_image_info = efi_test_fmp_get_image_info,
+ .get_image = NULL,
+ .set_image = NULL,
+ .check_image = NULL,
+ .get_package_info = NULL,
+ .set_package_info = NULL,
+};
+
+static void *lib_test_get_esrt(void)
+{
+ for (int idx = 0; idx < systab.nr_tables; idx++)
+ if (!guidcmp(&esrt_guid, &systab.tables[idx].guid))
+ return systab.tables[idx].table;
+
+ return NULL;
+}
+
+static bool lib_test_check_uuid_entry(struct efi_system_resource_table *esrt,
+ struct efi_firmware_image_descriptor
+
[PATCH] lib: optee: migration optee_copy_fdt_nodes for OF_LIVE support
The optee_copy_fdt_nodes is only used to copy op-tee nodes
of U-Boot device tree (from gd->fdt_blob when OF_LIVE is not activated)
to external device tree but it is not compatible with OF_LIVE.
This patch migrates all used function fdt_ functions to read node on
old_blob to ofnode functions, compatible with OF_LIVE and remove this
parameter "old_blob".
The generated "device tree" is checked on stm32mp platform with OF_LIVE
activated.
Signed-off-by: Patrick Delaunay
---
common/image-fdt.c | 2 +-
include/tee/optee.h | 4 ++--
lib/optee/optee.c | 45 ++---
3 files changed, 21 insertions(+), 30 deletions(-)
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 707b44a69d..bf5fbbf6e9 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -561,7 +561,7 @@ int image_setup_libfdt(bootm_headers_t *images, void *blob,
goto err;
}
- fdt_ret = optee_copy_fdt_nodes(gd->fdt_blob, blob);
+ fdt_ret = optee_copy_fdt_nodes(blob);
if (fdt_ret) {
printf("ERROR: transfer of optee nodes to new fdt failed: %s\n",
fdt_strerror(fdt_ret));
diff --git a/include/tee/optee.h b/include/tee/optee.h
index affa937da0..ebdfe5e98d 100644
--- a/include/tee/optee.h
+++ b/include/tee/optee.h
@@ -71,9 +71,9 @@ static inline int optee_verify_bootm_image(unsigned long
image_addr,
#endif
#if defined(CONFIG_OPTEE) && defined(CONFIG_OF_LIBFDT)
-int optee_copy_fdt_nodes(const void *old_blob, void *new_blob);
+int optee_copy_fdt_nodes(void *new_blob);
#else
-static inline int optee_copy_fdt_nodes(const void *old_blob, void *new_blob)
+static inline int optee_copy_fdt_nodes(void *new_blob)
{
return 0;
}
diff --git a/lib/optee/optee.c b/lib/optee/optee.c
index 9e6606568f..a097fec28b 100644
--- a/lib/optee/optee.c
+++ b/lib/optee/optee.c
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include
#include
@@ -69,17 +71,11 @@ error:
}
#if defined(CONFIG_OF_LIBFDT)
-static int optee_copy_firmware_node(const void *old_blob, void *fdt_blob)
+static int optee_copy_firmware_node(ofnode node, void *fdt_blob)
{
- int old_offs, offs, ret, len;
+ int offs, ret, len;
const void *prop;
- old_offs = fdt_path_offset(old_blob, "/firmware/optee");
- if (old_offs < 0) {
- debug("Original OP-TEE Device Tree node not found");
- return old_offs;
- }
-
offs = fdt_path_offset(fdt_blob, "/firmware");
if (offs < 0) {
offs = fdt_path_offset(fdt_blob, "/");
@@ -96,7 +92,7 @@ static int optee_copy_firmware_node(const void *old_blob,
void *fdt_blob)
return offs;
/* copy the compatible property */
- prop = fdt_getprop(old_blob, old_offs, "compatible", &len);
+ prop = ofnode_get_property(node, "compatible", &len);
if (!prop) {
debug("missing OP-TEE compatible property");
return -EINVAL;
@@ -107,7 +103,7 @@ static int optee_copy_firmware_node(const void *old_blob,
void *fdt_blob)
return ret;
/* copy the method property */
- prop = fdt_getprop(old_blob, old_offs, "method", &len);
+ prop = ofnode_get_property(node, "method", &len);
if (!prop) {
debug("missing OP-TEE method property");
return -EINVAL;
@@ -120,19 +116,18 @@ static int optee_copy_firmware_node(const void *old_blob,
void *fdt_blob)
return 0;
}
-int optee_copy_fdt_nodes(const void *old_blob, void *new_blob)
+int optee_copy_fdt_nodes(void *new_blob)
{
- int nodeoffset, subnode, ret;
- struct fdt_resource res;
-
- if (fdt_check_header(old_blob))
- return -EINVAL;
+ ofnode node, subnode;
+ int ret;
+ struct resource res;
if (fdt_check_header(new_blob))
return -EINVAL;
/* only proceed if there is an /firmware/optee node */
- if (fdt_path_offset(old_blob, "/firmware/optee") < 0) {
+ node = ofnode_path("/firmware/optee");
+ if (!ofnode_valid(node)) {
debug("No OP-TEE firmware node in old fdt, nothing to do");
return 0;
}
@@ -147,20 +142,17 @@ int optee_copy_fdt_nodes(const void *old_blob, void
*new_blob)
return 0;
}
- ret = optee_copy_firmware_node(old_blob, new_blob);
+ ret = optee_copy_firmware_node(node, new_blob);
if (ret < 0) {
printf("Failed to add OP-TEE firmware node\n");
return ret;
}
/* optee inserts its memory regions as reserved-memory nodes */
- nodeoffset = fdt_subnode_offset(old_blob, 0, "reserved-memory");
- if (nodeoffset >= 0) {
- for (subnode = fdt_first_subnode(old_blob, nodeoffset);
-subnode >= 0;
-subnode = fdt_next_subnode(old_blob, subnode)) {
-
Re: [RFC PATCH v1 1/2] dm: i2c: allow disabling driver model in SPL
Hello Igor, On 05.02.21 16:10, Igor Opaniuk wrote: > From: Igor Opaniuk > > At present if U-Boot proper uses driver model for I2C, then SPL has to > also. While this is desirable, it places a significant barrier to moving > to driver model in some cases. For example, with a space-constrained SPL > it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves > adjusting some drivers. > > This patch introduces a separate Kconfig symbols for enabling DM_I2C and > DM_I2C_GPIO support in SPL. > > This will also help to get away from dirty workarounds to > achieve non-DM I2C support for SPL, which is currently used in some > board header files like: > > ifdef CONFIG_SPL_BUILD > undef CONFIG_DM_I2C > endif > > Signed-off-by: Igor Opaniuk > --- > > drivers/i2c/Kconfig | 21 + > drivers/i2c/Makefile | 4 ++-- > drivers/misc/Makefile | 2 +- > 3 files changed, 24 insertions(+), 3 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
[PATCH 0/4] timer: imx-gpt: Add timer support for i.MX SoCs family
Add basic driver support for the IMX General Purpose Timer (GPT) available on almost all i.MX SoCs family. Giulio Benetti (3): timer: imx-gpt: Add timer support for i.MX SoCs family dt-bindings: clock: imxrt1050: add PIT GPT clock imxrt1050 dtsi gpt1 node Jesse Taube (1): timer: imx-gpt: Add basic timer support for i.MX SoCs family -- 2.30.0
How to flash Odroid Go2 u-boot
Hello, I'm trying to build an u-boot image that I can flash into my SD card in order to boot from Odroid Go Super. I'm currently trying to use the odroid-go2_defconfig which should be fairly similar to the hardware present in the Go3. I've managed to build it from 2021.01, but I'm not sure how I should proceed to flash the result into the SD card. The 'fuser' script from the Hardkernel u-boot forked repository has: dd if=idbloader.img of=/dev/foo conv=fsync bs=512 seek=64 dd if=uboot.img of=/dev/foo conv=fsync bs=512 seek=16384 dd if=trust.img of=/dev/foo conv=fsync bs=512 seek=24576 I see idbloader.img and u-boot.img as outputs from the build process, but I have no idea how to get trust.img, as that doesn't seem to be part of the build output AFAICT. Is it something I need to get from another repository? Could docs/README.odroid be expanded to include information about how to build and install u-boot for the odroid-go2 target? Or maybe create a different file if that's more convenient. Thanks, Roger.
[PATCH] mx8mp - clock for SPI and EQOS
My first patch so be not too hard ...
Patch to give imx8mp the chance to operate SPI and EQOS.
--- a/drivers/clk/imx/clk-imx8mp.c
+++ b/drivers/clk/imx/clk-imx8mp.c
@@ -116,6 +116,29 @@ static const char *imx8mp_i2c6_sels[] = {"clock-osc-24m",
"sys_pll1_160m", "sys_
"sys_pll3_out", "audio_pll1_out",
"video_pll1_out",
"audio_pll2_out", "sys_pll1_133m", };
+#if CONFIG_IS_ENABLED(DM_SPI)
+static const char *imx8mp_ecspi1_sels[] = {"osc_24m", "sys_pll2_200m",
"sys_pll1_40m",
+ "sys_pll1_160m", "sys_pll1_800m",
"sys_pll3_out",
+ "sys_pll2_250m", "audio_pll2_out", };
+
+static const char *imx8mp_ecspi2_sels[] = {"osc_24m", "sys_pll2_200m",
"sys_pll1_40m",
+ "sys_pll1_160m", "sys_pll1_800m",
"sys_pll3_out",
+ "sys_pll2_250m", "audio_pll2_out", };
+
+static const char *imx8mp_ecspi3_sels[] = {"osc_24m", "sys_pll2_200m",
"sys_pll1_40m",
+ "sys_pll1_160m", "sys_pll1_800m",
"sys_pll3_out",
+ "sys_pll2_250m", "audio_pll2_out", };
+#endif
+
+static const char *imx8mp_enet_qos_sels[] = {"osc_24m", "sys_pll2_125m",
"sys_pll2_50m",
+"sys_pll2_100m", "sys_pll1_160m",
"audio_pll1_out",
+"video_pll1_out", "clk_ext4", };
+
+static const char *imx8mp_enet_qos_timer_sels[] = {"osc_24m", "sys_pll2_100m",
"audio_pll1_out",
+ "clk_ext1", "clk_ext2",
"clk_ext3",
+ "clk_ext4",
"video_pll1_out", };
+
+
static const char *imx8mp_usdhc1_sels[] = {"clock-osc-24m", "sys_pll1_400m",
"sys_pll1_800m",
"sys_pll2_500m", "sys_pll3_out",
"sys_pll1_266m",
"audio_pll2_out", "sys_pll1_100m", };
@@ -397,6 +420,27 @@ static int imx8mp_clk_probe(struct udevice *dev)
clk_dm(IMX8MP_CLK_USDHC3_ROOT, imx_clk_gate4("usdhc3_root_clk",
"usdhc3", base + 0x45e0, 0));
+#if CONFIG_IS_ENABLED(DM_SPI)
+ clk_dm(IMX8MP_CLK_ECSPI1,
+ imx8m_clk_composite("ecspi1", imx8mp_ecspi1_sels, base +
0xb280));
+ clk_dm(IMX8MP_CLK_ECSPI2,
+ imx8m_clk_composite("ecspi2", imx8mp_ecspi2_sels, base +
0xb300));
+ clk_dm(IMX8MP_CLK_ECSPI3,
+ imx8m_clk_composite("ecspi3", imx8mp_ecspi3_sels, base +
0xc180));
+ clk_dm(IMX8MP_CLK_ECSPI1_ROOT,
+ imx_clk_gate4("ecspi1_root_clk", "ecspi1", base + 0x4070, 0));
+ clk_dm(IMX8MP_CLK_ECSPI2_ROOT,
+ imx_clk_gate4("ecspi2_root_clk", "ecspi2", base + 0x4080, 0));
+ clk_dm(IMX8MP_CLK_ECSPI3_ROOT,
+ imx_clk_gate4("ecspi3_root_clk", "ecspi3", base + 0x4090, 0));
+#endif
+
+ clk_dm(IMX8MP_CLK_ENET_QOS,
+ imx8m_clk_composite("enet_qos", imx8mp_enet_qos_sels,
base + 0xa880));
+ clk_dm(IMX8MP_CLK_ENET_QOS_TIMER,
+ imx8m_clk_composite("enet_qos_timer",
imx8mp_enet_qos_timer_sels, base + 0xa900));
+
+
return 0;
}
Re: [RFC PATCH v1 2/2] dm: i2c: use CONFIG_IS_ENABLED macro for DM_I2C and DM_I2C_GPIO
Hello Igor,
On 05.02.21 16:10, Igor Opaniuk wrote:
> From: Igor Opaniuk
>
> Use CONFIG_IS_ENABLED() macro, which provides more convenient
> way to check $(SPL)DM_I2C/$(SPL)DM_I2C_GPIO configs
> for both SPL and U-Boot proper.
>
> CONFIG_IS_ENABLED(DM_I2C) expands to:
> - 1 if CONFIG_SPL_BUILD is undefined and CONFIG_DM_I2C is set to 'y',
> - 1 if CONFIG_SPL_BUILD is defined and CONFIG_SPL_DM_I2C is set to 'y',
> - 0 otherwise.
>
> All occurences were replaced automatically using these bash cmds:
> $ find . -type f -exec sed -i
> 's/ifndef CONFIG_DM_I2C/if !CONFIG_IS_ENABLED(DM_I2C)/g' {} +
> $ find . -type f -exec sed -i
> 's/ifdef CONFIG_DM_I2C/if CONFIG_IS_ENABLED(DM_I2C)/g' {} +
> $ find . -type f -exec sed -i
> 's/defined(CONFIG_DM_I2C)/CONFIG_IS_ENABLED(DM_I2C)/g' {} +
> $ find . -type f -exec sed -i
> 's/ifndef CONFIG_DM_I2C_GPIO/if !CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
> $ find . -type f -exec sed -i
> 's/ifdef CONFIG_DM_I2C_GPIO/if CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
> $ find . -type f -exec sed -i
> 's/defined(CONFIG_DM_I2C_GPIO)/CONFIG_IS_ENABLED(DM_I2C_GPIO)/g' {} +
>
> Signed-off-by: Igor Opaniuk
>
> ---
>
> .../include/asm/arch-fsl-layerscape/config.h | 2 +-
> arch/arm/include/asm/arch-lpc32xx/i2c.h | 2 +-
> arch/arm/include/asm/mach-imx/mxc_i2c.h | 2 +-
> arch/arm/include/asm/omap_i2c.h | 2 +-
> arch/arm/mach-imx/i2c-mxv7.c | 2 +-
> arch/arm/mach-keystone/ddr3_spd.c | 2 +-
> arch/arm/mach-kirkwood/include/mach/config.h | 2 +-
> arch/arm/mach-omap2/am33xx/board.c| 2 +-
> arch/arm/mach-omap2/am33xx/clk_synthesizer.c | 6 +-
> arch/arm/mach-omap2/boot-common.c | 2 +-
> arch/arm/mach-omap2/clocks-common.c | 2 +-
> arch/arm/mach-sunxi/board.c | 2 +-
> arch/powerpc/include/asm/fsl_i2c.h| 2 +-
> board/freescale/common/dcu_sii9022a.c | 2 +-
> board/freescale/common/diu_ch7301.c | 2 +-
> board/freescale/common/emc2305.c | 4 +-
> board/freescale/common/qixis.c| 4 +-
> board/freescale/common/sys_eeprom.c | 20 ++--
> board/freescale/common/vid.c | 24 ++---
> board/freescale/common/vsc3316_3308.c | 10 +-
> board/freescale/ls1012aqds/ls1012aqds.c | 2 +-
> board/freescale/ls1012ardb/eth.c | 2 +-
> board/freescale/ls1012ardb/ls1012ardb.c | 12 +--
> board/freescale/ls1021aqds/dcu.c | 6 +-
> board/freescale/ls1021aqds/ls1021aqds.c | 2 +-
> board/freescale/ls1021atwr/ls1021atwr.c | 2 +-
> board/freescale/ls1028a/ls1028a.c | 2 +-
> board/freescale/ls1043aqds/ls1043aqds.c | 4 +-
> board/freescale/ls1046afrwy/ls1046afrwy.c | 2 +-
> board/freescale/ls1046aqds/ls1046aqds.c | 2 +-
> board/freescale/ls1088a/eth_ls1088aqds.c | 16 +--
> board/freescale/ls1088a/ls1088a.c | 60 ++--
> board/freescale/ls2080aqds/eth.c | 14 +--
> board/freescale/ls2080aqds/ls2080aqds.c | 4 +-
> board/freescale/ls2080ardb/ls2080ardb.c | 2 +-
> board/freescale/lx2160a/lx2160a.c | 2 +-
> board/freescale/p1010rdb/p1010rdb.c | 8 +-
> board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c | 2 +-
> board/freescale/t102xrdb/t102xrdb.c | 2 +-
> board/freescale/t208xqds/t208xqds.c | 2 +-
> board/friendlyarm/nanopi2/onewire.c | 6 +-
> board/keymile/common/ivm.c| 2 +-
> board/samsung/common/misc.c | 2 +-
> board/samsung/trats/trats.c | 10 +-
> board/samsung/trats2/trats2.c | 10 +-
> board/sunxi/board.c | 2 +-
> board/ti/am335x/board.c | 8 +-
> board/ti/am335x/mux.c | 2 +-
> board/ti/am43xx/board.c | 12 +--
> board/ti/common/board_detect.c| 4 +-
> board/ti/ks2_evm/board_k2g.c | 2 +-
> board/wandboard/wandboard.c | 4 +-
> cmd/eeprom.c | 6 +-
> cmd/i2c.c | 98 +--
> doc/driver-model/i2c-howto.rst| 2 +-
> drivers/ddr/fsl/main.c| 8 +-
> drivers/i2c/davinci_i2c.c | 4 +-
> drivers/i2c/designware_i2c.c | 4 +-
> drivers/i2c/fsl_i2c.c | 6 +-
> drivers/i2c/ihs_i2c.c | 42
> drivers/i2c/lpc32xx_i2c.c | 4 +-
> drivers/i2c/mv_i2c.c | 2 +-
> drivers/i2c/mvtwsi.c | 16 +--
> drivers/i2c/mxc_i2c.c | 4 +-
> drivers/i2c/omap24xx_i2c.c| 2 +-
> drivers/power/palmas.c| 2 +-
> drivers/power/pm
[PATCH v2 1/7] lmb: Add support of flags for no-map properties
Add "flags" in lmb_property to save the "no-map" property of
reserved region and a new function lmb_reserve_flags() to check
this flag.
The default allocation use flags = LMB_NONE.
The adjacent reserved memory region are merged only when they have
the same flags value.
This patch is partially based on flags support done in Linux kernel
mm/memblock .c (previously lmb.c); it is why LMB_NOMAP = 0x4, it is
aligned with MEMBLOCK_NOMAP value.
Signed-off-by: Patrick Delaunay
Signed-off-by: Patrick Delaunay
---
Changes in v2:
- remove unnecessary comments in lmb.h
- rebase on latest lmb patches
include/lmb.h | 20
lib/lmb.c | 52 ++-
2 files changed, 63 insertions(+), 9 deletions(-)
diff --git a/include/lmb.h b/include/lmb.h
index 97be24ed66..4987e61bf3 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -12,6 +12,16 @@
* Copyright (C) 2001 Peter Bergner, IBM Corp.
*/
+/**
+ * enum lmb_flags - definition of memory region attributes
+ * @LMB_NONE: no special request
+ * @LMB_NOMAP: don't add to mmu configuration
+ */
+enum lmb_flags {
+ LMB_NONE= 0x0,
+ LMB_NOMAP = 0x4,
+};
+
/**
* struct lmb_property - Description of one region.
*
@@ -21,6 +31,7 @@
struct lmb_property {
phys_addr_t base;
phys_size_t size;
+ enum lmb_flags flags;
};
/**
@@ -63,6 +74,8 @@ extern void lmb_init_and_reserve_range(struct lmb *lmb,
phys_addr_t base,
phys_size_t size, void *fdt_blob);
extern long lmb_add(struct lmb *lmb, phys_addr_t base, phys_size_t size);
extern long lmb_reserve(struct lmb *lmb, phys_addr_t base, phys_size_t size);
+extern long lmb_reserve_flags(struct lmb *lmb, phys_addr_t base,
+ phys_size_t size, enum lmb_flags flags);
extern phys_addr_t lmb_alloc(struct lmb *lmb, phys_size_t size, ulong align);
extern phys_addr_t lmb_alloc_base(struct lmb *lmb, phys_size_t size, ulong
align,
phys_addr_t max_addr);
@@ -86,6 +99,13 @@ lmb_size_bytes(struct lmb_region *type, unsigned long
region_nr)
void board_lmb_reserve(struct lmb *lmb);
void arch_lmb_reserve(struct lmb *lmb);
+/* Low level functions */
+
+static inline bool lmb_is_nomap(struct lmb_property *m)
+{
+ return !!(m->flags & LMB_NOMAP);
+}
+
#endif /* __KERNEL__ */
#endif /* _LINUX_LMB_H */
diff --git a/lib/lmb.c b/lib/lmb.c
index c97be0a064..5975f6b6e1 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -25,6 +25,8 @@ void lmb_dump_all_force(struct lmb *lmb)
(unsigned long long)lmb->memory.region[i].base);
printf(" .size = 0x%llx\n",
(unsigned long long)lmb->memory.region[i].size);
+ printf(" .flags = 0x%x\n",
+ lmb->memory.region[i].flags);
}
printf("\nreserved.cnt = 0x%lx\n", lmb->reserved.cnt);
@@ -33,6 +35,8 @@ void lmb_dump_all_force(struct lmb *lmb)
(unsigned long long)lmb->reserved.region[i].base);
printf(" .size = 0x%llx\n",
(unsigned long long)lmb->reserved.region[i].size);
+ printf(" .flags = 0x%x\n",
+ lmb->reserved.region[i].flags);
}
}
@@ -81,6 +85,7 @@ static void lmb_remove_region(struct lmb_region *rgn,
unsigned long r)
for (i = r; i < rgn->cnt - 1; i++) {
rgn->region[i].base = rgn->region[i + 1].base;
rgn->region[i].size = rgn->region[i + 1].size;
+ rgn->region[i].flags = rgn->region[i + 1].flags;
}
rgn->cnt--;
}
@@ -141,7 +146,8 @@ void lmb_init_and_reserve_range(struct lmb *lmb,
phys_addr_t base,
}
/* This routine called with relocation disabled. */
-static long lmb_add_region(struct lmb_region *rgn, phys_addr_t base,
phys_size_t size)
+static long lmb_add_region_flags(struct lmb_region *rgn, phys_addr_t base,
+phys_size_t size, enum lmb_flags flags)
{
unsigned long coalesced = 0;
long adjacent, i;
@@ -149,6 +155,7 @@ static long lmb_add_region(struct lmb_region *rgn,
phys_addr_t base, phys_size_t
if (rgn->cnt == 0) {
rgn->region[0].base = base;
rgn->region[0].size = size;
+ rgn->region[0].flags = flags;
rgn->cnt = 1;
return 0;
}
@@ -157,18 +164,27 @@ static long lmb_add_region(struct lmb_region *rgn,
phys_addr_t base, phys_size_t
for (i = 0; i < rgn->cnt; i++) {
phys_addr_t rgnbase = rgn->region[i].base;
phys_size_t rgnsize = rgn->region[i].size;
+ phys_size_t rgnflags = rgn->region[i].flags;
- if ((rgnbase == base) && (rgnsize == size))
- /* Already have this region, so
[PATCH v2 4/7] test: lmb: add test for lmb_reserve_flags
Add a test to check the management of reserved region with flags.
Signed-off-by: Patrick Delaunay
Signed-off-by: Patrick Delaunay
---
(no changes since v1)
test/lib/lmb.c | 89 ++
1 file changed, 89 insertions(+)
diff --git a/test/lib/lmb.c b/test/lib/lmb.c
index 644ee78758..d7bd826190 100644
--- a/test/lib/lmb.c
+++ b/test/lib/lmb.c
@@ -659,3 +659,92 @@ static int lib_test_lmb_get_free_size(struct
unit_test_state *uts)
DM_TEST(lib_test_lmb_get_free_size,
UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
+
+static int lib_test_lmb_flags(struct unit_test_state *uts)
+{
+ const phys_addr_t ram = 0x4000;
+ const phys_size_t ram_size = 0x2000;
+ struct lmb lmb;
+ long ret;
+
+ lmb_init(&lmb);
+
+ ret = lmb_add(&lmb, ram, ram_size);
+ ut_asserteq(ret, 0);
+
+ /* reserve, same flag */
+ ret = lmb_reserve_flags(&lmb, 0x4001, 0x1, LMB_NOMAP);
+ ut_asserteq(ret, 0);
+ ASSERT_LMB(&lmb, ram, ram_size, 1, 0x4001, 0x1,
+ 0, 0, 0, 0);
+
+ /* reserve again, same flag */
+ ret = lmb_reserve_flags(&lmb, 0x4001, 0x1, LMB_NOMAP);
+ ut_asserteq(ret, 0);
+ ASSERT_LMB(&lmb, ram, ram_size, 1, 0x4001, 0x1,
+ 0, 0, 0, 0);
+
+ /* reserve again, new flag */
+ ret = lmb_reserve_flags(&lmb, 0x4001, 0x1, LMB_NONE);
+ ut_asserteq(ret, -1);
+ ASSERT_LMB(&lmb, ram, ram_size, 1, 0x4001, 0x1,
+ 0, 0, 0, 0);
+
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[0]), 1);
+
+ /* merge after */
+ ret = lmb_reserve_flags(&lmb, 0x4002, 0x1, LMB_NOMAP);
+ ut_asserteq(ret, 1);
+ ASSERT_LMB(&lmb, ram, ram_size, 1, 0x4001, 0x2,
+ 0, 0, 0, 0);
+
+ /* merge before */
+ ret = lmb_reserve_flags(&lmb, 0x4000, 0x1, LMB_NOMAP);
+ ut_asserteq(ret, 1);
+ ASSERT_LMB(&lmb, ram, ram_size, 1, 0x4000, 0x3,
+ 0, 0, 0, 0);
+
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[0]), 1);
+
+ ret = lmb_reserve_flags(&lmb, 0x4003, 0x1, LMB_NONE);
+ ut_asserteq(ret, 0);
+ ASSERT_LMB(&lmb, ram, ram_size, 2, 0x4000, 0x3,
+ 0x4003, 0x1, 0, 0);
+
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[0]), 1);
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[1]), 0);
+
+ /* test that old API use LMB_NONE */
+ ret = lmb_reserve(&lmb, 0x4004, 0x1);
+ ut_asserteq(ret, 1);
+ ASSERT_LMB(&lmb, ram, ram_size, 2, 0x4000, 0x3,
+ 0x4003, 0x2, 0, 0);
+
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[0]), 1);
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[1]), 0);
+
+ ret = lmb_reserve_flags(&lmb, 0x4007, 0x1, LMB_NOMAP);
+ ut_asserteq(ret, 0);
+ ASSERT_LMB(&lmb, ram, ram_size, 3, 0x4000, 0x3,
+ 0x4003, 0x2, 0x4007, 0x1);
+
+ ret = lmb_reserve_flags(&lmb, 0x4005, 0x1, LMB_NOMAP);
+ ut_asserteq(ret, 0);
+ ASSERT_LMB(&lmb, ram, ram_size, 4, 0x4000, 0x3,
+ 0x4003, 0x2, 0x4005, 0x1);
+
+ /* merge with 2 adjacent regions */
+ ret = lmb_reserve_flags(&lmb, 0x4006, 0x1, LMB_NOMAP);
+ ut_asserteq(ret, 2);
+ ASSERT_LMB(&lmb, ram, ram_size, 3, 0x4000, 0x3,
+ 0x4003, 0x2, 0x4005, 0x3);
+
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[0]), 1);
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[1]), 0);
+ ut_asserteq(lmb_is_nomap(&lmb.reserved.region[2]), 1);
+
+ return 0;
+}
+
+DM_TEST(lib_test_lmb_flags,
+ UT_TESTF_SCAN_PDATA | UT_TESTF_SCAN_FDT);
--
2.17.1
[PATCH v2 2/7] lmb: add lmb_is_reserved_flags
Add a new function lmb_is_reserved_flags to check is a
address is reserved with a specific flags.
This function can be used to check if an address had be
reserved with no-map flags with:
lmb_is_reserved_flags(lmb, addr, LMB_NOMAP);
Signed-off-by: Patrick Delaunay
Signed-off-by: Patrick Delaunay
---
(no changes since v1)
include/lmb.h | 1 +
lib/lmb.c | 10 --
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/include/lmb.h b/include/lmb.h
index 4987e61bf3..59db94501d 100644
--- a/include/lmb.h
+++ b/include/lmb.h
@@ -85,6 +85,7 @@ extern phys_addr_t lmb_alloc_addr(struct lmb *lmb,
phys_addr_t base,
phys_size_t size);
extern phys_size_t lmb_get_free_size(struct lmb *lmb, phys_addr_t addr);
extern int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr);
+extern int lmb_is_reserved_flags(struct lmb *lmb, phys_addr_t addr, int flags);
extern long lmb_free(struct lmb *lmb, phys_addr_t base, phys_size_t size);
extern void lmb_dump_all(struct lmb *lmb);
diff --git a/lib/lmb.c b/lib/lmb.c
index 5975f6b6e1..af398c5144 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -440,7 +440,7 @@ phys_size_t lmb_get_free_size(struct lmb *lmb, phys_addr_t
addr)
return 0;
}
-int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
+int lmb_is_reserved_flags(struct lmb *lmb, phys_addr_t addr, int flags)
{
int i;
@@ -448,11 +448,17 @@ int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
phys_addr_t upper = lmb->reserved.region[i].base +
lmb->reserved.region[i].size - 1;
if ((addr >= lmb->reserved.region[i].base) && (addr <= upper))
- return 1;
+ return !!((lmb->reserved.region[i].flags & flags)
+ == flags);
}
return 0;
}
+int lmb_is_reserved(struct lmb *lmb, phys_addr_t addr)
+{
+ return lmb_is_reserved_flags(lmb, addr, LMB_NONE);
+}
+
__weak void board_lmb_reserve(struct lmb *lmb)
{
/* please define platform specific board_lmb_reserve() */
--
2.17.1
[PATCH v2 6/7] stm32mp: don't map the reserved region with no-map property
No more map the reserved region with "no-map" property by marking
the corresponding TLB entries with invalid entry (=0) to avoid
speculative access.
This patch fixes an issue where predictive read access on secure DDR
OP-TEE reserved area are caught by firewall.
Signed-off-by: Patrick Delaunay
---
Changes in v2:
- NEW: update in stm32mp specific MMU setup functions
arch/arm/mach-stm32mp/cpu.c | 16 ++--
1 file changed, 14 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
index 030066dc7c..2e0d709fed 100644
--- a/arch/arm/mach-stm32mp/cpu.c
+++ b/arch/arm/mach-stm32mp/cpu.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -220,6 +221,9 @@ void dram_bank_mmu_setup(int bank)
int i;
phys_addr_t start;
phys_size_t size;
+ struct lmb lmb;
+ bool use_lmb = false;
+ enum dcache_option option;
if (IS_ENABLED(CONFIG_SPL_BUILD)) {
start = ALIGN_DOWN(STM32_SYSRAM_BASE, MMU_SECTION_SIZE);
@@ -228,6 +232,10 @@ void dram_bank_mmu_setup(int bank)
/* bd->bi_dram is available only after relocation */
start = bd->bi_dram[bank].start;
size = bd->bi_dram[bank].size;
+ if (IS_ENABLED(CONFIG_LMB)) {
+ use_lmb = true;
+ lmb_init_and_reserve(&lmb, bd, (void *)gd->fdt_blob);
+ }
} else {
/* mark cacheable and executable the beggining of the DDR */
start = STM32_DDR_BASE;
@@ -236,8 +244,12 @@ void dram_bank_mmu_setup(int bank)
for (i = start >> MMU_SECTION_SHIFT;
i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT);
-i++)
- set_section_dcache(i, DCACHE_DEFAULT_OPTION);
+i++) {
+ option = DCACHE_DEFAULT_OPTION;
+ if (use_lmb && lmb_is_reserved_flags(&lmb, i <<
MMU_SECTION_SHIFT, LMB_NOMAP))
+ option = INVALID_ENTRY;
+ set_section_dcache(i, option);
+ }
}
/*
* initialize the MMU and activate cache in SPL or in U-Boot pre-reloc stage
--
2.17.1
[PATCH v2 0/7] arm: cache: cp15: don't map reserved region with no-map property
Hi,
It it the v2 serie of [1].
This v2 serie is build/can be applied on top of 2 previous series
- [2] for stm32mp parts and added dram_bank_mmu_setup
- [3] for LMB impacts
After V1 remarks, I propose this separate serie [2] for DACR support.
On STM32MP15x platform we can use OP-TEE, loaded in DDR in a region
protected by a firewall. This region is reserved in device with "no-map"
property.
Sometime the platform boot failed in U-boot on a Cortex A7 access to
this region (depending of the binary and the issue can change with compiler
version or with code alignment), then the firewall raise an error,
for example:
E/TC:0 tzc_it_handler:19 TZC permission failure
E/TC:0 dump_fail_filter:420 Permission violation on filter 0
E/TC:0 dump_fail_filter:425 Violation @0xde5c6bf0, non-secure privileged read,
AXI ID 5c0
E/TC:0 Panic
After investigation, the forbidden access is a speculative request performed
by the Cortex A7 because all the DDR is mapped as MEMORY with CACHEABLE
property.
The issue is solved only when the region reserved by OP-TEE is no more
mapped in U-Boot as it is already done in Linux kernel.
Tested on DK2 board with OP-TEE 3.12 / TF-A 2.4:
With hard-coded address for OP-TEE reserved memory,
the error doesn't occur.
void dram_bank_mmu_setup(int bank)
{
for (i = start >> MMU_SECTION_SHIFT;
i < (start >> MMU_SECTION_SHIFT) + (size >> MMU_SECTION_SHIFT);
i++) {
option = DCACHE_DEFAULT_OPTION;
if (i >= 0xde0)
option = INVALID_ENTRY;
set_section_dcache(i, option);
}
}
Just by modifying the test on 0xde0 to 0xdf0, the OP-TEE memory protected
by firewall is mapped cacheable and the error occurs.
I think that can be a general issue for ARM architecture: the no-map tag
in device should be respected by U-boot, so I propose a generic solution
in arm/lib/cache-cp15.c:dram_bank_mmu_setup().
This v2 serie is composed by 7 patches
- 1..3/7: preliminary steps to support flags in library in lmb
(as it is done in memblock.c in Linux)
- 4/7: unitary test on the added feature in lmb lib
- 5/7: save the no-map flags in lmb when the device tree is parsed
- 6/7: update the stm32mp mmu support
- 7/7: update the generic behavior for "no-map" region in
arm/lib/cache-cp15.c::dram_bank_mmu_setup()
I can drop this last patch if this feature is not required by other
ARM architectures; the weak function is updated in patch 6
in STM32MP architecture (in arch/arm/mach-stm32mp/cpu.c)
to correct the initial problem.
See also [4] which handle same speculative access on armv8 for area
with Executable attribute.
[1] http://patchwork.ozlabs.org/project/uboot/list/?series=206296&state=*
[2] http://patchwork.ozlabs.org/project/uboot/list/?series=228202&state=*
[3] http://patchwork.ozlabs.org/project/uboot/list/?series=227570&state=*
[4]
http://patchwork.ozlabs.org/project/uboot/patch/20200903000106.5016-1-marek.bykow...@gmail.com/
Regards
Patrick
Changes in v2:
- remove unnecessary comments in lmb.h
- rebase on latest lmb patches
- NEW: update in stm32mp specific MMU setup functions
Patrick Delaunay (7):
lmb: Add support of flags for no-map properties
lmb: add lmb_is_reserved_flags
lmb: add lmb_dump_region() function
test: lmb: add test for lmb_reserve_flags
image-fdt: save no-map parameter of reserve-memory
stm32mp: don't map the reserved region with no-map property
arm: cache: cp15: don't map the reserved region with no-map property
arch/arm/include/asm/system.h | 3 ++
arch/arm/lib/cache-cp15.c | 19 ++-
arch/arm/mach-stm32mp/cpu.c | 16 +-
common/image-fdt.c| 23 ++---
include/lmb.h | 21
lib/lmb.c | 94 +--
test/lib/lmb.c| 89 +
7 files changed, 226 insertions(+), 39 deletions(-)
--
2.17.1
[PATCH v2 7/7] arm: cache: cp15: don't map the reserved region with no-map property
No more map the reserved region with "no-map" property by marking
the corresponding TLB entries with invalid entry (=0) to avoid
speculative access.
This patch fixes potential issue when predictive access is done by ARM
core.
Signed-off-by: Patrick Delaunay
Signed-off-by: Patrick Delaunay
---
(no changes since v1)
arch/arm/include/asm/system.h | 3 +++
arch/arm/lib/cache-cp15.c | 19 +--
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 11fceec4d2..c63ed07f2c 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -444,6 +444,7 @@ static inline void set_cr(unsigned int val)
/* options available for data cache on each page */
enum dcache_option {
+ INVALID_ENTRY = 0,
DCACHE_OFF = TTB_SECT | TTB_SECT_MAIR(0) | TTB_SECT_XN_MASK,
DCACHE_WRITETHROUGH = TTB_SECT | TTB_SECT_MAIR(1),
DCACHE_WRITEBACK = TTB_SECT | TTB_SECT_MAIR(2),
@@ -474,6 +475,7 @@ enum dcache_option {
* 11 1 Outer/Inner Write-Back, Read-Allocate Write-Allocate
*/
enum dcache_option {
+ INVALID_ENTRY = 0,
DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK | TTB_SECT,
DCACHE_WRITETHROUGH = TTB_SECT_DOMAIN(0) | TTB_SECT | TTB_SECT_C_MASK,
DCACHE_WRITEBACK = DCACHE_WRITETHROUGH | TTB_SECT_B_MASK,
@@ -483,6 +485,7 @@ enum dcache_option {
#define TTB_SECT_AP(3 << 10)
/* options available for data cache on each page */
enum dcache_option {
+ INVALID_ENTRY = 0,
DCACHE_OFF = 0x12,
DCACHE_WRITETHROUGH = 0x1a,
DCACHE_WRITEBACK = 0x1e,
diff --git a/arch/arm/lib/cache-cp15.c b/arch/arm/lib/cache-cp15.c
index 8a49e5217c..8a354d364d 100644
--- a/arch/arm/lib/cache-cp15.c
+++ b/arch/arm/lib/cache-cp15.c
@@ -6,6 +6,7 @@
#include
#include
+#include
#include
#include
#include
@@ -101,18 +102,32 @@ void mmu_set_region_dcache_behaviour(phys_addr_t start,
size_t size,
__weak void dram_bank_mmu_setup(int bank)
{
struct bd_info *bd = gd->bd;
+ struct lmb lmb;
int i;
/* bd->bi_dram is available only after relocation */
if ((gd->flags & GD_FLG_RELOC) == 0)
return;
+ /*
+* don't allow cache on reserved memory tagged 'no-map' in DT
+* => avoid speculative access to "secure" data
+*/
+ if (IS_ENABLED(CONFIG_LMB))
+ lmb_init_and_reserve(&lmb, bd, (void *)gd->fdt_blob);
+
debug("%s: bank: %d\n", __func__, bank);
for (i = bd->bi_dram[bank].start >> MMU_SECTION_SHIFT;
i < (bd->bi_dram[bank].start >> MMU_SECTION_SHIFT) +
(bd->bi_dram[bank].size >> MMU_SECTION_SHIFT);
-i++)
- set_section_dcache(i, DCACHE_DEFAULT_OPTION);
+i++) {
+ if (IS_ENABLED(CONFIG_LMB) &&
+ lmb_is_reserved_flags(&lmb, i << MMU_SECTION_SHIFT,
+ LMB_NOMAP))
+ set_section_dcache(i, INVALID_ENTRY);
+ else
+ set_section_dcache(i, DCACHE_DEFAULT_OPTION);
+ }
}
/* to activate the MMU we need to set up virtual memory: use 1M areas */
--
2.17.1
[PATCH v2 3/7] lmb: add lmb_dump_region() function
Add lmb_dump_region() function, to simplify lmb_dump_all_force().
This patch is based on Linux memblock dump function.
An example of bdinfo output is:
.
fdt_size= 0x000146a0
FB base = 0xfdd0
lmb_dump_all:
memory.cnt = 0x1
memory[0] [0xc000-0x], 0x4000 bytes flags: 0
reserved.cnt = 0x6
reserved[0][0x1000-0x10045fff], 0x00046000 bytes flags: 4
reserved[1][0x3000-0x3003], 0x0004 bytes flags: 4
reserved[2][0x3800-0x3800], 0x0001 bytes flags: 4
reserved[3][0xe800-0xefff], 0x0800 bytes flags: 4
reserved[4][0xfbaea344-0xfdff], 0x02515cbc bytes flags: 0
reserved[5][0xfe00-0x], 0x0200 bytes flags: 4
arch_number = 0x
TLB addr= 0xfdff
Signed-off-by: Patrick Delaunay
Signed-off-by: Patrick Delaunay
---
(no changes since v1)
lib/lmb.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/lib/lmb.c b/lib/lmb.c
index af398c5144..b24eda89fb 100644
--- a/lib/lmb.c
+++ b/lib/lmb.c
@@ -14,32 +14,32 @@
#define LMB_ALLOC_ANYWHERE 0
-void lmb_dump_all_force(struct lmb *lmb)
+static void lmb_dump_region(struct lmb_region *rgn, char *name)
{
- unsigned long i;
+ unsigned long long base, size, end;
+ enum lmb_flags flags;
+ int i;
- printf("lmb_dump_all:\n");
- printf("memory.cnt = 0x%lx\n", lmb->memory.cnt);
- for (i = 0; i < lmb->memory.cnt; i++) {
- printf("memory.reg[0x%lx].base = 0x%llx\n", i,
- (unsigned long long)lmb->memory.region[i].base);
- printf(" .size = 0x%llx\n",
- (unsigned long long)lmb->memory.region[i].size);
- printf(" .flags = 0x%x\n",
- lmb->memory.region[i].flags);
- }
+ printf(" %s.cnt = 0x%lx\n", name, rgn->cnt);
- printf("\nreserved.cnt = 0x%lx\n", lmb->reserved.cnt);
- for (i = 0; i < lmb->reserved.cnt; i++) {
- printf("reserved.reg[0x%lx].base = 0x%llx\n", i,
- (unsigned long long)lmb->reserved.region[i].base);
- printf(" .size = 0x%llx\n",
- (unsigned long long)lmb->reserved.region[i].size);
- printf(" .flags = 0x%x\n",
- lmb->reserved.region[i].flags);
+ for (i = 0; i < rgn->cnt; i++) {
+ base = rgn->region[i].base;
+ size = rgn->region[i].size;
+ end = base + size - 1;
+ flags = rgn->region[i].flags;
+
+ printf(" %s[%d]\t[0x%llx-0x%llx], 0x%08llx bytes flags: %x\n",
+ name, i, base, end, size, flags);
}
}
+void lmb_dump_all_force(struct lmb *lmb)
+{
+ printf("lmb_dump_all:\n");
+ lmb_dump_region(&lmb->memory, "memory");
+ lmb_dump_region(&lmb->reserved, "reserved");
+}
+
void lmb_dump_all(struct lmb *lmb)
{
#ifdef DEBUG
--
2.17.1
[PATCH v2 5/7] image-fdt: save no-map parameter of reserve-memory
Save the no-map information present in 'reserved-memory' node to allow
correct handling when the MMU is configured in board to avoid
speculative access.
Signed-off-by: Patrick Delaunay
Signed-off-by: Patrick Delaunay
---
(no changes since v1)
common/image-fdt.c | 23 +++
1 file changed, 15 insertions(+), 8 deletions(-)
diff --git a/common/image-fdt.c b/common/image-fdt.c
index 707b44a69d..efd29fdb7b 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -74,18 +74,20 @@ static const image_header_t *image_get_fdt(ulong fdt_addr)
#endif
static void boot_fdt_reserve_region(struct lmb *lmb, uint64_t addr,
- uint64_t size)
+ uint64_t size, enum lmb_flags flags)
{
long ret;
- ret = lmb_reserve(lmb, addr, size);
+ ret = lmb_reserve_flags(lmb, addr, size, flags);
if (ret >= 0) {
- debug(" reserving fdt memory region: addr=%llx size=%llx\n",
- (unsigned long long)addr, (unsigned long long)size);
+ debug(" reserving fdt memory region: addr=%llx size=%llx
flags=%x\n",
+ (unsigned long long)addr,
+ (unsigned long long)size, flags);
} else {
puts("ERROR: reserving fdt memory region failed ");
- printf("(addr=%llx size=%llx)\n",
- (unsigned long long)addr, (unsigned long long)size);
+ printf("(addr=%llx size=%llx flags=%x)\n",
+ (unsigned long long)addr,
+ (unsigned long long)size, flags);
}
}
@@ -105,6 +107,7 @@ void boot_fdt_add_mem_rsv_regions(struct lmb *lmb, void
*fdt_blob)
int i, total, ret;
int nodeoffset, subnode;
struct fdt_resource res;
+ enum lmb_flags flags;
if (fdt_check_header(fdt_blob) != 0)
return;
@@ -114,7 +117,7 @@ void boot_fdt_add_mem_rsv_regions(struct lmb *lmb, void
*fdt_blob)
for (i = 0; i < total; i++) {
if (fdt_get_mem_rsv(fdt_blob, i, &addr, &size) != 0)
continue;
- boot_fdt_reserve_region(lmb, addr, size);
+ boot_fdt_reserve_region(lmb, addr, size, LMB_NONE);
}
/* process reserved-memory */
@@ -126,9 +129,13 @@ void boot_fdt_add_mem_rsv_regions(struct lmb *lmb, void
*fdt_blob)
ret = fdt_get_resource(fdt_blob, subnode, "reg", 0,
&res);
if (!ret && fdtdec_get_is_enabled(fdt_blob, subnode)) {
+ flags = LMB_NONE;
+ if (fdtdec_get_bool(fdt_blob, subnode,
+ "no-map"))
+ flags = LMB_NOMAP;
addr = res.start;
size = res.end - res.start + 1;
- boot_fdt_reserve_region(lmb, addr, size);
+ boot_fdt_reserve_region(lmb, addr, size, flags);
}
subnode = fdt_next_subnode(fdt_blob, subnode);
--
2.17.1
[RFC PATCH] nvme: Always invalidate whole cqes[] array
At the moment nvme_read_completion_status() tries to invidate a single
member of the cqes[] array, which is shady as just a single entry is
not cache line aligned.
The structure is dictated by hardware, and with 16 bytes is smaller than
any cache line we usually deal with. Also multiple entries need to be
consecutive in memory, so we can't pad them to cover a whole cache line.
As a consequence we can only always invalidate all of them - U-Boot just
uses two of them anyway. This is fine, as they are only ever read by the
CPU (apart from the initial zeroing), so they can't become dirty.
Make this obvious by always invalidating the whole array, regardless of
the entry number we are about to read.
Also blow up the allocation size to cover whole cache lines, to avoid
other heap allocations to sneak in.
Signed-off-by: Andre Przywara
---
Hi,
this is just compile tested, and should fix the only questionable
cache invalidate call in this driver.
Please verify if this fixes any issues!
Cheers,
Andre
drivers/nvme/nvme.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c
index 5d6331ad346..c9efeff4bc9 100644
--- a/drivers/nvme/nvme.c
+++ b/drivers/nvme/nvme.c
@@ -22,6 +22,8 @@
#define NVME_AQ_DEPTH 2
#define NVME_SQ_SIZE(depth)(depth * sizeof(struct nvme_command))
#define NVME_CQ_SIZE(depth)(depth * sizeof(struct nvme_completion))
+#define NVME_CQ_ALLOCATION ALIGN(NVME_CQ_SIZE(NVME_Q_DEPTH), \
+ ARCH_DMA_MINALIGN)
#define ADMIN_TIMEOUT 60
#define IO_TIMEOUT 30
#define MAX_PRP_POOL 512
@@ -144,8 +146,14 @@ static __le16 nvme_get_cmd_id(void)
static u16 nvme_read_completion_status(struct nvme_queue *nvmeq, u16 index)
{
- u64 start = (ulong)&nvmeq->cqes[index];
- u64 stop = start + sizeof(struct nvme_completion);
+ /*
+* Single CQ entries are always smaller than a cache line, so we
+* can't invalidate them individually. However CQ entries are
+* read only by the CPU, so it's safe to always invalidate all of them,
+* as the cache line should never become dirty.
+*/
+ ulong start = (ulong)&nvmeq->cqes[0];
+ ulong stop = start + NVME_CQ_ALLOCATION;
invalidate_dcache_range(start, stop);
@@ -241,7 +249,7 @@ static struct nvme_queue *nvme_alloc_queue(struct nvme_dev
*dev,
return NULL;
memset(nvmeq, 0, sizeof(*nvmeq));
- nvmeq->cqes = (void *)memalign(4096, NVME_CQ_SIZE(depth));
+ nvmeq->cqes = (void *)memalign(4096, NVME_CQ_ALLOCATION);
if (!nvmeq->cqes)
goto free_nvmeq;
memset((void *)nvmeq->cqes, 0, NVME_CQ_SIZE(depth));
@@ -339,7 +347,7 @@ static void nvme_init_queue(struct nvme_queue *nvmeq, u16
qid)
nvmeq->q_db = &dev->dbs[qid * 2 * dev->db_stride];
memset((void *)nvmeq->cqes, 0, NVME_CQ_SIZE(nvmeq->q_depth));
flush_dcache_range((ulong)nvmeq->cqes,
- (ulong)nvmeq->cqes + NVME_CQ_SIZE(nvmeq->q_depth));
+ (ulong)nvmeq->cqes + NVME_CQ_ALLOCATION);
dev->online_queues++;
}
--
2.17.5
Re: [PATCH] nvme: Fix cache alignment
On Sun, 7 Feb 2021 14:13:37 -0500
Tom Rini wrote:
Hi Tom, Marek,
> On Sun, Feb 07, 2021 at 07:20:14PM +0100, Marek Vasut wrote:
> > On 2/4/21 5:57 PM, Tom Rini wrote:
> > [...]
> >
> > > > > > > > > > +static void nvme_flush_dcache_range(void *start, unsigned
> > > > > > > > > > long size)
> > > > > > > > > > +{
> > > > > > > > > > + unsigned long s, e;
> > > > > > > > > > + nvme_align_dcache_range(start, size, &s, &e);
> > > > > > > > > > + flush_dcache_range(s, e);
> > > > > > > >
> > > > > > > > There is no good reason for alignment restrictions when it
> > > > > > > > comes to
> > > > > > > > clean (& invalidate), so there is no need for this wrapper.
> > > > > > >
> > > > > > > Is that on ARM64-specific or is that applicable in general ? The
> > > > > > > driver
> > > > > > > is expected to work on any CPU.
> > > > > >
> > > > > > Cache clean (actually: cache clean&invalidate) is what happens on
> > > > > > evictions
> > > > > > all of the time, at the cache controller's discretion. So there is
> > > > > > no
> > > > > > real harm in that operation per se. When an eviction happens on a
> > > > > > *clean* cache line, this is basically just an invalidate, which is
> > > > > > also not
> > > > > > harmful.
> > > > > >
> > > > > > There are harmful cases when buffers sharing a cache line are both
> > > > > > "just invalidated"
> > > > > > and "cleaned" at different points in time.
> > > > >
> > > > > Is that on ARM64-specific or is that applicable in general ? (the
> > > > > above
> > > > > does not answer that question)
> > > >
> > > > I would say that's a property of *every* write-back cache
> > > > implementation:
> > > > https://en.wikipedia.org/wiki/Cache_(computing)#/media/File:Write-back_with_write-allocation.svg
> > > >
> > >
> > > I've been reading and digesting the thread as it goes, and the only
> > > thing I do want to chime in on here right now is that yes, U-Boot
> > > does and will continue to support every CPU that someone wants to run it
> > > on, and one of the takeaways I see from this thread is we need some
> > > better documented abstractions around cache, as it's very tricky to get
> > > right all the time.
> >
> > Documenting the u-boot cache function behavior precisely is fine by me, but
> > that is somewhat separate topic from this bugfix.
> >
> > So I will ask a simple question -- is there anything blocking this bugfix
> > from being applied ?
>
> While I can fix the typo, I'm waiting for an Ack/Reviewed-by from Bin
> (as he's spent the most time on this driver of late) and I'd really like
> one from Andre, or at least him agreeing this patch is a step in the
> right direction.
As I said: I don't see how this patch changes anything on arm64, which
the commit messages claims to be the reason for this post.
If someone please can confirm, but invalidate_dcache_range() always
works on arm64, in fact does the very rounding already that this patch
introduces here. So what is the actual fix here?
Plus, I consider this blanket rounding more harmful than helpful, since
it actually just silences the check_cache_range() check.
If we include armv7 here, which in fact would ignore(!) an unaligned
invalidate, this is my analysis (just for invalidate):
nvme_read_completion_status(): NEEDS ALIGNMENT
size smaller than cache line, cqes[1] base address unaligned.
fix needed, rounding *could* be a temporary fix with comments
as of why this is legitimate in this case.
Better alternative sketched in a previous email.
nvme_identify():OK
struct nvme_id_ctrl is 4K, if I counted correctly, so is fine.
buffer comes the callers, the in-file users pass an aligned
address, the only external user I see is in nvme_show.c, which
also explicitly aligns the buffer.
nvme_blk_rw(): OK
total_len seems to be a multiple of block size, so is hopefully
already cache line aligned.
buffer comes from the upper layers, I guess it's page
aligned already (at least 512b sector aligned)?
I turned my sketch for the cqes[] fix into a proper patch and will send
this in a minute.
Cheers,
Andre
Re: [PATCH 01/10] README: Add doumentation for version information
Hi Simon on tipo in title: s/doumentation/documentation/ On 1/7/21 5:21 AM, Simon Glass wrote: There are quite a few available version options in U-Boot. Add a list of the available Makefile variables and #defines, along with examples. Signed-off-by: Simon Glass --- README | 84 ++ 1 file changed, 84 insertions(+) Just one remark, this information could be integrated in generated U-Boot documentation for example => develop/version.rst (under "Implementation") Reviewed-by: Patrick Delaunay Thanks Patrick
Re: How to flash Odroid Go2 u-boot
On Mon, Feb 8, 2021 at 1:27 PM Roger Pau Monné wrote: > > Hello, > > I'm trying to build an u-boot image that I can flash into my SD card > in order to boot from Odroid Go Super. I'm currently trying to use the > odroid-go2_defconfig which should be fairly similar to the hardware > present in the Go3. > > I've managed to build it from 2021.01, but I'm not sure how I should > proceed to flash the result into the SD card. The 'fuser' script from > the Hardkernel u-boot forked repository has: > > dd if=idbloader.img of=/dev/foo conv=fsync bs=512 seek=64 > dd if=uboot.img of=/dev/foo conv=fsync bs=512 seek=16384 > dd if=trust.img of=/dev/foo conv=fsync bs=512 seek=24576 > > I see idbloader.img and u-boot.img as outputs from the build process, > but I have no idea how to get trust.img, as that doesn't seem to be > part of the build output AFAICT. Is it something I need to get from > another repository? So U-Boot build, assuming you're putting an ATF bl31.bin in place bundles 2 and 3 together into an u-boot.itb file which you can replace line 2 with so you should be able to do: dd if=idbloader.img of=/dev/foo conv=fsync bs=512 seek=64 dd if=u-boot.itb of=/dev/foo conv=fsync bs=512 seek=16384 > Could docs/README.odroid be expanded to include information about how > to build and install u-boot for the odroid-go2 target? Or maybe create > a different file if that's more convenient. > > Thanks, Roger.
Re: [PATCH 02/10] Makefile: Provide numeric versions
Hi Simon, On 1/7/21 5:21 AM, Simon Glass wrote: For SMBIOS we want to store the numeric version numbers in the tables. It does not make sense to parse the strings. Instead, add new #defines with the version and patchlevel. Signed-off-by: Simon Glass --- Makefile | 4 README | 8 2 files changed, 12 insertions(+) Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH] pci: pci_mvebu: Disable config access to PCI host bridge ports
On Mon, 25 Jan 2021 15:25:31 +0100 Stefan Roese wrote: > This patch changes the PCI config routines in the Armada XP / 38x driver > to not allow access to the PCIe root ports. > > While updating the Armada XP based theadorable to the latest mainline > and testing it with the DM PCI driver I noticed, that the PCI root > bridge was being configured incorrectly. Resulting in the PCIe Intel > WiFi was not working correctly in Linux. With this patch applied, all > PCIe devices work without any issues in Linux again. > Hi Stefan, I overlooked this patch and coincidentally also discovered this bug last week. Your patches solves this issue, but - previously, when pci-mvebu did not use DM, it was solved differently: pci_skip_dev returned 1 for (b,d,f) = (*,0,0). - on this address (*,0,0) there seems to be a Memory Controller - without applying your patch the pci command lists => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x11ab 0x6820 Memory controller 0x80 00.01.00 0x168c 0x003c Network controller 0x80 with your patch => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.01.00 0x168c 0x003c Network controller 0x80 I would like to know why this memory controller is there and whether it should be configured. The pci-mvebu driver in kernel currently ignores this Memory Controller. That is the reason why your Intel WiFi card and my ath10k wifi card are not working: U-Boot configures some addresses in PCIe registers of this Memory Controller, but kernel does not reconfigure it. So all in all: - your patch solves the issue, but I wonder whether it shouldn't be solved in another way, for example by adding pci,no-autoconfig device tree property in DTS files in u-boot for these Memory Controllers - I wonder whether kernel should stop ignoring this device and configure it somehow Marek
Re: [PATCH 03/26] common: fdt_support: Support special case of PCI address in fdt_read_prop()
Hi Bin,
On Sun, 7 Feb 2021 at 22:17, Bin Meng wrote:
>
> Hi Simon,
>
> On Mon, Feb 8, 2021 at 12:21 PM Simon Glass wrote:
> >
> > Hi Bin,
> >
> > On Sun, 7 Feb 2021 at 08:11, Bin Meng wrote:
> > >
> > > At present fdt_read_prop() can only handle 1 or 2 cells. It is
> > > called by fdt_read_range() which may be used to read PCI address
> > > from for a PCI bus node where the number of PCI address
> > > cell is 3.
> > >
> > > This adds the special handling of such case.
> > >
> > > Signed-off-by: Bin Meng
> > > ---
> > >
> > > common/fdt_support.c | 15 ---
> > > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > I think this is missing why it is needed. Also needs an update to
> > function to the comment in the header file.
> >
>
> I will try to add more details in v2.
>
> The reason why this is needed is because in fdt_read_range() may be
> used to read PCI address from .
> The property is an array of { address> }.
>
> When trying to read from a PCI bus node using
> fdt_read_prop(), as the codes below:
>
> /* Read */
> if (child_addr) {
> r = fdt_read_prop(ranges, ranges_len, cell, child_addr,
> acells);
> if (r)
> return r;
> }
>
> it will fail, because the PCI child address is made up of 3 cells but
> fdt_read_prop() cannot handle it.
> We advance the cell offset by 1 so that the can be
> correctly read.
OK, that could go in the commit message and a function comment
somewhere about the case.
There is similar code in decode_regions(), so we have two places that
read ranges.
Regards,
Simon
Re: [PATCH 13/26] cmd: Add a command to display the address map
Hi Bin,
On Sun, 7 Feb 2021 at 22:12, Bin Meng wrote:
>
> Hi Simon,
>
> On Mon, Feb 8, 2021 at 12:20 PM Simon Glass wrote:
> >
> > On Sun, 7 Feb 2021 at 08:12, Bin Meng wrote:
> > >
> > > This adds a new command 'addrmap' to display the address map for
> > > non-identity virtual-physical memory mappings.
> > >
> > > Signed-off-by: Bin Meng
> > > ---
> > >
> > > cmd/Kconfig | 7 +++
> > > cmd/Makefile | 1 +
> > > cmd/addrmap.c | 35 +++
> > > 3 files changed, 43 insertions(+)
> > > create mode 100644 cmd/addrmap.c
> >
> > This should have a test (e.g. see mem_search.c) and doc/usage file.
>
> I am not sure how that is useful to add a test for this command,
> because this command only prints some value from an array.
Right but then it will only be a short test:
console_record_reset();
ut_assertok(run_command("...", 0));
ut_assert_nextline()
..
ut_assert_console_end();
Then if someone expands it later they will feel obligated to add to the test.
I feel that a lot of things look too trivial to test when started, but
it is often that first trivial test that determines whether we have
tests ever. That is why we have the patman check about adding tests
for new commands.
Regards,
Simon
Re: [PATCH] pci: pci_mvebu: Disable config access to PCI host bridge ports
Hi Marek, On 08.02.21 15:00, Marek Behun wrote: On Mon, 25 Jan 2021 15:25:31 +0100 Stefan Roese wrote: This patch changes the PCI config routines in the Armada XP / 38x driver to not allow access to the PCIe root ports. While updating the Armada XP based theadorable to the latest mainline and testing it with the DM PCI driver I noticed, that the PCI root bridge was being configured incorrectly. Resulting in the PCIe Intel WiFi was not working correctly in Linux. With this patch applied, all PCIe devices work without any issues in Linux again. Hi Stefan, I overlooked this patch and coincidentally also discovered this bug last week. Your patches solves this issue, Good... but - previously, when pci-mvebu did not use DM, it was solved differently: pci_skip_dev returned 1 for (b,d,f) = (*,0,0). - on this address (*,0,0) there seems to be a Memory Controller - without applying your patch the pci command lists => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x11ab 0x6820 Memory controller 0x80 00.01.00 0x168c 0x003c Network controller 0x80 with your patch => pci Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.01.00 0x168c 0x003c Network controller 0x80 Yes. I would like to know why this memory controller is there and whether it should be configured. The pci-mvebu driver in kernel currently ignores this Memory Controller. That is the reason why your Intel WiFi card and my ath10k wifi card are not working: U-Boot configures some addresses in PCIe registers of this Memory Controller, but kernel does not reconfigure it. AFAIR, the U-Boot PCIe host driver configured this "memory controller" incorrectly resulting in these problems with the attached PCIe devices (WiFi controller). My presumption is, that the "memory controller" is the host bridge root port and it's BAR's need to intepreted / configured differently. The easy solution was to not configure this host bridge at all, as it solves these issues (for me and for you) and no further issues are introduced. At least not that I know of. If there are issues, we of course need to fix them. So all in all: - your patch solves the issue, but I wonder whether it shouldn't be solved in another way, for example by adding pci,no-autoconfig device tree property in DTS files in u-boot for these Memory Controllers Hmmm. If my findings above are correct, then we should fix this incorrect BAR configuration for all boards using this driver globally and not introduce a DT property than needs to be added to all boards. Perhaps it's possible to correctly interpret the "memory controller" and correctly configure it's BARs. Frankly, I was not able to come up with such a solution quickly and did choose the solution provided in this patch instead. - I wonder whether kernel should stop ignoring this device and configure it somehow Why should the kernel do this? Is some functionality missing from your point of view? Thanks, Stefan
Re: [PATCH] pci: pci_mvebu: Disable config access to PCI host bridge ports
Hello Stefan! On Monday 08 February 2021 15:19:20 Stefan Roese wrote: > On 08.02.21 15:00, Marek Behun wrote: > >I would like to know why this memory controller is there and whether > >it should be configured. The pci-mvebu driver in kernel currently > >ignores this Memory Controller. That is the reason why your Intel > >WiFi card and my ath10k wifi card are not working: U-Boot configures > >some addresses in PCIe registers of this Memory Controller, but > >kernel does not reconfigure it. > > AFAIR, the U-Boot PCIe host driver configured this "memory controller" > incorrectly resulting in these problems with the attached PCIe devices > (WiFi controller). My presumption is, that the "memory controller" is > the host bridge root port and it's BAR's need to intepreted / configured > differently. I'm not sure if this can be a host bridge. Because mvebu has separate address space for host bridge registers and kernel is creating a virtual bridge device for accessing host bridge registers. I think first somebody needs to answer the question what is this device doing and why kernel has "hacks" which completely hides it from lspci output. > The easy solution was to not configure this host bridge at all, as it > solves these issues (for me and for you) and no further issues are > introduced. At least not that I know of. If there are issues, we of > course need to fix them. > > > So all in all: > > - your patch solves the issue, but I wonder whether it shouldn't be > >solved in another way, for example by adding pci,no-autoconfig device > >tree property in DTS files in u-boot for these Memory Controllers > > Hmmm. If my findings above are correct, then we should fix this > incorrect BAR configuration for all boards using this driver globally > and not introduce a DT property than needs to be added to all boards. > > Perhaps it's possible to correctly interpret the "memory controller" > and correctly configure it's BARs. Frankly, I was not able to come up > with such a solution quickly and did choose the solution provided in > this patch instead. > > > - I wonder whether kernel should stop ignoring this device and > >configure it somehow > > Why should the kernel do this? Is some functionality missing from your > point of view? Kernel is not only ignoring this device, but it also hides it from PCI bus. It is not visible in lspci output. And I do not think that kernel should hide devices. AFAIK lspci show all devices present on bus, even those which do not have loaded kernel driver... > > Thanks, > Stefan
Re: [PATCH] pci: pci_mvebu: Disable config access to PCI host bridge ports
Maybe we should ask kernel people. It seems that Thomas Petazzoni may be able to answer, since he is author of the following kernel patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4ac99011e542d06ea2bda10063502583c6d7991
Re: [RFC PATCH v2 1/2] optee: obtain emmc rpmb info from dt
Hi Igor,
On 1/24/21 10:39 AM, Igor Opaniuk wrote:
From: Igor Opaniuk
Add support for rpmb-dev property in optee node.
Prioritize that provided eMMC info from DT for RPMB operations over
the one provided by OP-TEE OS core in RPC calls.
Signed-off-by: Igor Opaniuk
---
Changes in v2:
- Return NULL instead of ERR_PTR(-ENXIO) in get_rpmb_dev in case there
is no rpmb-dev property or somemithing went wrong
drivers/tee/optee/core.c | 33 +
drivers/tee/optee/optee_private.h | 2 +-
drivers/tee/optee/rpmb.c | 60 ++-
3 files changed, 70 insertions(+), 25 deletions(-)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/core.c
index b898c32edc..828ab9b00a 100644
--- a/drivers/tee/optee/core.c
+++ b/drivers/tee/optee/core.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "optee_smc.h"
#include "optee_msg.h"
@@ -607,14 +608,46 @@ static optee_invoke_fn *get_invoke_func(struct udevice
*dev)
return ERR_PTR(-EINVAL);
}
+static struct mmc *get_rpmb_dev(struct udevice *dev)
+{
+ struct udevice *mmc_dev;
+ const fdt32_t *phandle_p;
+ u32 phandle;
+ int ret = 0;
+
+ debug("optee: looking for rpmb device in DT.\n");
+
+ phandle_p = ofnode_get_property(dev_ofnode(dev),
+"rpmb-dev", NULL);
+ if (!phandle_p) {
+ debug("optee: missing \"rpmb-dev\" property\n");
+ return NULL;
+ }
+
+ phandle = fdt32_to_cpu(*phandle_p);
+
+ ret = uclass_get_device_by_phandle_id(UCLASS_MMC, phandle, &mmc_dev);
+ if (ret) {
+ printf("optee: invalid phandle value in \"rpmb-dev\".\n");
+ return NULL;
+ }
+
+ debug("optee: using phandle %d from \"rpmd-dev\" property.\n",
+ phandle);
+ return mmc_get_mmc_dev(mmc_dev);
+}
+
static int optee_of_to_plat(struct udevice *dev)
{
struct optee_pdata *pdata = dev_get_plat(dev);
+ struct optee_private *priv = dev_get_priv(dev);
pdata->invoke_fn = get_invoke_func(dev);
if (IS_ERR(pdata->invoke_fn))
return PTR_ERR(pdata->invoke_fn);
Normally optee_of_to_plat should initialized only the platdata and not the
private date
(initialized during probe or driver execution)
And no need to initialize rpmb_mmcif CONFIG_CMD_OPTEE_RPMBI is not activated,
I proposed:
struct optee_pdata {
optee_invoke_fn *invoke_fn;
struct mmc *rpmb_mmc;
};
+ if (IS_ENABLED(CONFIG_CMD_OPTEE_RPMBI))
+ pdata->rpmb_mmc = get_rpmb_dev(dev);
+ priv->rpmb_mmc = get_rpmb_dev(dev);
+
return 0;
}
diff --git a/drivers/tee/optee/optee_private.h b/drivers/tee/optee/optee_private.h
index 1f07a27ee4..8e5a280622 100644
--- a/drivers/tee/optee/optee_private.h
+++ b/drivers/tee/optee/optee_private.h
@@ -19,8 +19,8 @@
*/
struct optee_private {
struct mmc *rpmb_mmc;
- int rpmb_dev_id;
int rpmb_original_part;
+ bool rpmb_inited;
};
struct optee_msg_arg;
diff --git a/drivers/tee/optee/rpmb.c b/drivers/tee/optee/rpmb.c
index 0804fc963c..0137c44be1 100644
--- a/drivers/tee/optee/rpmb.c
+++ b/drivers/tee/optee/rpmb.c
@@ -45,55 +45,67 @@ static void release_mmc(struct optee_private *priv)
{
int rc;
- if (!priv->rpmb_mmc)
+ if (!priv->rpmb_mmc || !priv->rpmb_inited)
return;
- rc = blk_select_hwpart_devnum(IF_TYPE_MMC, priv->rpmb_dev_id,
- priv->rpmb_original_part);
+ rc = mmc_switch_part(priv->rpmb_mmc, priv->rpmb_original_part);
if (rc)
debug("%s: blk_select_hwpart_devnum() failed: %d\n",
__func__, rc);
- priv->rpmb_mmc = NULL;
+ priv->rpmb_inited = false;
+}
+
+static int check_mmc(struct mmc *mmc)
+{
+ if (!mmc) {
+ debug("Cannot find RPMB device\n");
+ return -ENODEV;
+ }
+ if (!(mmc->version & MMC_VERSION_MMC)) {
+ debug("Device id is not an eMMC device\n");
+ return -ENODEV;
+ }
+ if (mmc->version < MMC_VERSION_4_41) {
+ debug("RPMB is not supported before version 4.41\n");
+ return -ENODEV;
+ }
+
+ return 0;
}
static struct mmc *get_mmc(struct optee_private *priv, int dev_id)
{
- struct mmc *mmc;
int rc;
- if (priv->rpmb_mmc && priv->rpmb_dev_id == dev_id)
+ if (priv->rpmb_mmc && priv->rpmb_inited)
return priv->rpmb_mmc;
release_mmc(priv);
really need to release mmc here (it is not initialized) as the first test of
the called function is:
if (!priv->rpmb_mmc || !priv->rpmb_inited)
- mmc = find_mmc_device(dev_id);
- if (!mmc) {
- debug("Cannot find RPMB device\n");
- return NULL;
- }
- if (!(mmc->version & MMC_VERSION_MMC)) {
-
Re: [PATCH] nvme: Fix cache alignment
Hi Andre,
On Mon, Feb 8, 2021 at 9:33 PM Andre Przywara wrote:
>
> On Sun, 7 Feb 2021 14:13:37 -0500
> Tom Rini wrote:
>
> Hi Tom, Marek,
>
> > On Sun, Feb 07, 2021 at 07:20:14PM +0100, Marek Vasut wrote:
> > > On 2/4/21 5:57 PM, Tom Rini wrote:
> > > [...]
> > >
> > > > > > > > > > > +static void nvme_flush_dcache_range(void *start,
> > > > > > > > > > > unsigned long size)
> > > > > > > > > > > +{
> > > > > > > > > > > + unsigned long s, e;
> > > > > > > > > > > + nvme_align_dcache_range(start, size, &s, &e);
> > > > > > > > > > > + flush_dcache_range(s, e);
> > > > > > > > >
> > > > > > > > > There is no good reason for alignment restrictions when it
> > > > > > > > > comes to
> > > > > > > > > clean (& invalidate), so there is no need for this wrapper.
> > > > > > > >
> > > > > > > > Is that on ARM64-specific or is that applicable in general ?
> > > > > > > > The driver
> > > > > > > > is expected to work on any CPU.
> > > > > > >
> > > > > > > Cache clean (actually: cache clean&invalidate) is what happens on
> > > > > > > evictions
> > > > > > > all of the time, at the cache controller's discretion. So there
> > > > > > > is no
> > > > > > > real harm in that operation per se. When an eviction happens on a
> > > > > > > *clean* cache line, this is basically just an invalidate, which
> > > > > > > is also not
> > > > > > > harmful.
> > > > > > >
> > > > > > > There are harmful cases when buffers sharing a cache line are
> > > > > > > both "just invalidated"
> > > > > > > and "cleaned" at different points in time.
> > > > > >
> > > > > > Is that on ARM64-specific or is that applicable in general ? (the
> > > > > > above
> > > > > > does not answer that question)
> > > > >
> > > > > I would say that's a property of *every* write-back cache
> > > > > implementation:
> > > > > https://en.wikipedia.org/wiki/Cache_(computing)#/media/File:Write-back_with_write-allocation.svg
> > > >
> > > > I've been reading and digesting the thread as it goes, and the only
> > > > thing I do want to chime in on here right now is that yes, U-Boot
> > > > does and will continue to support every CPU that someone wants to run it
> > > > on, and one of the takeaways I see from this thread is we need some
> > > > better documented abstractions around cache, as it's very tricky to get
> > > > right all the time.
> > >
> > > Documenting the u-boot cache function behavior precisely is fine by me,
> > > but
> > > that is somewhat separate topic from this bugfix.
> > >
> > > So I will ask a simple question -- is there anything blocking this bugfix
> > > from being applied ?
> >
> > While I can fix the typo, I'm waiting for an Ack/Reviewed-by from Bin
> > (as he's spent the most time on this driver of late) and I'd really like
> > one from Andre, or at least him agreeing this patch is a step in the
> > right direction.
>
> As I said: I don't see how this patch changes anything on arm64, which
> the commit messages claims to be the reason for this post.
> If someone please can confirm, but invalidate_dcache_range() always
> works on arm64, in fact does the very rounding already that this patch
> introduces here. So what is the actual fix here?
>
> Plus, I consider this blanket rounding more harmful than helpful, since
> it actually just silences the check_cache_range() check.
>
> If we include armv7 here, which in fact would ignore(!) an unaligned
> invalidate, this is my analysis (just for invalidate):
> nvme_read_completion_status(): NEEDS ALIGNMENT
> size smaller than cache line, cqes[1] base address unaligned.
> fix needed, rounding *could* be a temporary fix with comments
> as of why this is legitimate in this case.
> Better alternative sketched in a previous email.
This is exactly what I mentioned before [1]. The only problematic
routine is the nvme_read_completion_status() but I didn't have time to
experiment with a fix.
> nvme_identify():OK
> struct nvme_id_ctrl is 4K, if I counted correctly, so is fine.
> buffer comes the callers, the in-file users pass an aligned
> address, the only external user I see is in nvme_show.c, which
> also explicitly aligns the buffer.
> nvme_blk_rw(): OK
> total_len seems to be a multiple of block size, so is hopefully
> already cache line aligned.
> buffer comes from the upper layers, I guess it's page
> aligned already (at least 512b sector aligned)?
>
> I turned my sketch for the cqes[] fix into a proper patch and will send
> this in a minute.
Thanks for looking into this.
[1] https://lists.denx.de/pipermail/u-boot/2021-February/439580.html
Regards,
Bin
Re: [PATCH] nvme: Fix cache alignment
On 2/8/21 2:32 PM, Andre Przywara wrote:
[...]
+static void nvme_flush_dcache_range(void *start, unsigned long size)
+{
+ unsigned long s, e;
+ nvme_align_dcache_range(start, size, &s, &e);
+ flush_dcache_range(s, e);
There is no good reason for alignment restrictions when it comes to
clean (& invalidate), so there is no need for this wrapper.
Is that on ARM64-specific or is that applicable in general ? The driver
is expected to work on any CPU.
Cache clean (actually: cache clean&invalidate) is what happens on evictions
all of the time, at the cache controller's discretion. So there is no
real harm in that operation per se. When an eviction happens on a
*clean* cache line, this is basically just an invalidate, which is also not
harmful.
There are harmful cases when buffers sharing a cache line are both "just
invalidated"
and "cleaned" at different points in time.
Is that on ARM64-specific or is that applicable in general ? (the above
does not answer that question)
I would say that's a property of *every* write-back cache
implementation:
https://en.wikipedia.org/wiki/Cache_(computing)#/media/File:Write-back_with_write-allocation.svg
I've been reading and digesting the thread as it goes, and the only
thing I do want to chime in on here right now is that yes, U-Boot
does and will continue to support every CPU that someone wants to run it
on, and one of the takeaways I see from this thread is we need some
better documented abstractions around cache, as it's very tricky to get
right all the time.
Documenting the u-boot cache function behavior precisely is fine by me, but
that is somewhat separate topic from this bugfix.
So I will ask a simple question -- is there anything blocking this bugfix
from being applied ?
While I can fix the typo, I'm waiting for an Ack/Reviewed-by from Bin
(as he's spent the most time on this driver of late) and I'd really like
one from Andre, or at least him agreeing this patch is a step in the
right direction.
As I said: I don't see how this patch changes anything on arm64, which
the commit messages claims to be the reason for this post.
If someone please can confirm, but invalidate_dcache_range() always
works on arm64, in fact does the very rounding already that this patch
introduces here. So what is the actual fix here?
You can NOT depend on the behavior of cache functions on specific
architecture, U-Boot is universal and this must work on every single
architecture, not just aarch64.
The entire point of this patch is to call flush/invalidate only with
cacheline-aligned addresses, which is what they expect, otherwise these
functions do no operation at all.
Plus, I consider this blanket rounding more harmful than helpful, since
it actually just silences the check_cache_range() check.
Can you back this claim with something ? Because I spent my fair share
of time analyzing the driver and the rounding is exactly sufficient to
make the cache ops work correctly.
If we include armv7 here, which in fact would ignore(!) an unaligned
invalidate
Yes, on armv7 and older, the cache ops behave as they were designed to
behave.
, this is my analysis (just for invalidate):
nvme_read_completion_status(): NEEDS ALIGNMENT
size smaller than cache line, cqes[1] base address unaligned.
fix needed, rounding *could* be a temporary fix with comments
as of why this is legitimate in this case.
Better alternative sketched in a previous email.
nvme_identify():OK
struct nvme_id_ctrl is 4K, if I counted correctly, so is fine.
buffer comes the callers, the in-file users pass an aligned
address, the only external user I see is in nvme_show.c, which
also explicitly aligns the buffer.
nvme_blk_rw(): OK
total_len seems to be a multiple of block size, so is hopefully
already cache line aligned.
buffer comes from the upper layers, I guess it's page
aligned already (at least 512b sector aligned)?
I turned my sketch for the cqes[] fix into a proper patch and will send
this in a minute
Please add check_cache_range() to armv8 cache ops and test whether there
are no warnings from it, thanks.
Re: [PATCH] nvme: Fix cache alignment
On 2/8/21 4:11 PM, Bin Meng wrote: [...] As I said: I don't see how this patch changes anything on arm64, which the commit messages claims to be the reason for this post. If someone please can confirm, but invalidate_dcache_range() always works on arm64, in fact does the very rounding already that this patch introduces here. So what is the actual fix here? Plus, I consider this blanket rounding more harmful than helpful, since it actually just silences the check_cache_range() check. If we include armv7 here, which in fact would ignore(!) an unaligned invalidate, this is my analysis (just for invalidate): nvme_read_completion_status(): NEEDS ALIGNMENT size smaller than cache line, cqes[1] base address unaligned. fix needed, rounding *could* be a temporary fix with comments as of why this is legitimate in this case. Better alternative sketched in a previous email. This is exactly what I mentioned before [1]. The only problematic routine is the nvme_read_completion_status() but I didn't have time to experiment with a fix. I believe it is better to have one single function to handle all the cache alignment and operations in the driver instead of having copy of the same alignment thing all over the driver. [...]
Re: How to flash Odroid Go2 u-boot
On Mon, Feb 08, 2021 at 01:55:26PM +, Peter Robinson wrote:
> On Mon, Feb 8, 2021 at 1:27 PM Roger Pau Monné wrote:
> >
> > Hello,
> >
> > I'm trying to build an u-boot image that I can flash into my SD card
> > in order to boot from Odroid Go Super. I'm currently trying to use the
> > odroid-go2_defconfig which should be fairly similar to the hardware
> > present in the Go3.
> >
> > I've managed to build it from 2021.01, but I'm not sure how I should
> > proceed to flash the result into the SD card. The 'fuser' script from
> > the Hardkernel u-boot forked repository has:
> >
> > dd if=idbloader.img of=/dev/foo conv=fsync bs=512 seek=64
> > dd if=uboot.img of=/dev/foo conv=fsync bs=512 seek=16384
> > dd if=trust.img of=/dev/foo conv=fsync bs=512 seek=24576
> >
> > I see idbloader.img and u-boot.img as outputs from the build process,
> > but I have no idea how to get trust.img, as that doesn't seem to be
> > part of the build output AFAICT. Is it something I need to get from
> > another repository?
>
> So U-Boot build, assuming you're putting an ATF bl31.bin in place
Sorry, I'm not familiar with the Arm stuff, so some questions might
seem obvious.
I've picked rk3326_bl31_v1.21.elf from:
https://github.com/rockchip-linux/rkbin/blob/master/bin/rk33/rk3326_bl31_v1.21.elf
I note there's also a rk3326_bl32_v1.15.bin in that folder, some
miniloader .bin files and a ddr .bin, but that's not needed?
I think I must get the bl31 from the above repository, as there's no
support for building it from ARM-software/arm-trusted-firmware
repository:
https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/rockchip
> bundles 2 and 3 together into an u-boot.itb file which you can replace
> line 2 with so you should be able to do:
> dd if=idbloader.img of=/dev/foo conv=fsync bs=512 seek=64
> dd if=u-boot.itb of=/dev/foo conv=fsync bs=512 seek=16384
Thanks for the snippets. So I wiped the mbr of an SD card and used the
above commands to flash the newly built U-Boot images, and this is the
output I'm getting on the serial port:
U-Boot 201709 (Jan 01 2021 - 01:14:44 +)
Model: Rockchip RK3326 ODROID-GO Advanced
PreSerial: 2
DRAM: 992 MiB
Sysmem: init
Relocation Offset is: 3dabd000
Using default environment
adc0 (hw rev) 82
no mmc device at slot 1
RKPARM: Invalid parameter part table
Found IDB in SDcard
dwmmc@ff37: 1 (SD)
Bootdev(atags): mmc 1
MMC1: Legacy, 50Mhz
RKPARM: Invalid parameter part table
## Unknown partition table type 0
PartType:
RKPARM: Invalid parameter part table
init_resource_list: failed to get resource part, ret=-1
** Unrecognized filesystem type **
dtb in resource read fail, try dtb in spi flash
sfc nor id: b 40 18
Device 1: GUID Partition Table Header signature is wrong: 0x !=
0x5452415020494645
Repair the backup gpt table OK!
Vendor: 0x0308 Rev: V100 Prod: rkflash-SpiNor
Type: Hard Disk
Capacity: 160 MB = 00 GB (32768 x 512)
is now current device
spinor read: device 1 block # 12392, count 200 200 blocks read: OK
I2c speed: 40Hz
PMIC: RK8170 (on=0x80, off=0x08)
vdd_logic 110 uV
vdd_arm 110 uV
*** Warning - bad CRC, using default environment
In:serial
Out: serial
Err: serial
Model: ODROID-GO3 for linux based on Rockchip rk3326
download key pressed entering recovery mode!
boot mode: recovery (key)
CLK: (sync kernel arm: enter 60 KHz, init 60 KHz, kernel 60 KHz)
apll 60 KHz
dpll 664000 KHz
cpll 24000 KHz
npll 1188000 KHz
gpll 120 KHz
aclk_bus 20 KHz
hclk_bus 15 KHz
pclk_bus 10 KHz
aclk_peri 20 KHz
hclk_peri 15 KHz
pclk_pmu 10 KHz
** Unrecognized filesystem type **
Rockchip UBOOT DRM driver version: v101
Using display timing dts
Detailed mode clock 27500 kHz, flags[a]
H: 0480 0490 0500 0505
V: 0854 0866 0868 0928
bus_format: 100e
final DSI-Link bandwidth: 366 Mbps x 2
** No partition table - mmc 1 **
logobmp file not found! filesize = 0
spinor read: device 1 block # 12592, count 400 400 blocks read: OK
Uncompressed size: 1229814 = 0x12C3F6
switch to partitions #0, OK
mmc1 is current device
** No partition table - mmc 1 **
Net: Net Initialization Skipped
No ethernet found
Hit key to stop autoboot('CTRL+C'): 0
switch to partitions #0, OK
mmc1 is current device
Failed to mount ext2 filesystem
** Unrecognized filesystem type **
Failed to mount ext2 filesystem
** Unrecognized filesystem type **
cfgload - read 'bootini' from FAT partiton
Usage:
cfgload
- read bootini from the first partiton treated as FAT partiton
** No partition table - mmc 1 **
** No partition table - mmc 1 **
Bad Linux ARM64 Image magic!
spinor read: device 1 block # 13792, count 400 400 blocks read: OK
Uncompressed size: 1229814 = 0x12C3F6
Wait power key
Hit ctrl+c key to enter uboot console
power key long pressed
Apart from the fact that the SD has no partition table now I'm not
sure if the hardware is correctly picking up the new u-boot from the
SD, as the o
[PATCH u-boot-marvell] ARM: mvebu: a38x: sync ddr training code with mv_ddr-armada-14.0.0
This syncs drivers/ddr/marvell/a38x/ with the mv-ddr-devel branch
of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git.
Specifically this syncs with commit fae3f6c98230 ("Bump mv_ddr to
release 14.0.0").
There is a new version numbering system, where after 18.12.0 came
1.0.0, 2.0.0, and so on until 14.0.0. So 14.0.0 is newer than 18.12.0.
There are some commits regarding DDR3 on top of version 14.0.0 in the
mv-ddr-marvell repository (from Chris Packham), but these changes
already are in U-Boot.
The complete log of changes is best obtained from the mv-ddr-marvell.git
repository but some relevant highlights are:
ddr3: allow board specific ODT configuration
mv_ddr: add 16Gbit memory devices support
mv_ddr: add support for twin-die combined memory device
mv_ddr: a38x: disable WL phase correction stage in case of bus_width=16bit
mv_ddr: a38x : fix memory cs size function
The default value for new option twin_die_combined is set to
NOT_COMBINED for all boards, as this was default behaviour prior this
change.
Signed-off-by: Marek Behún
Cc: Chris Packham
Cc: Chris Packham
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Pavol Rohár
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 2 ++
board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 1 +
board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 1 +
board/alliedtelesis/x530/x530.c | 1 +
board/gdsys/a38x/controlcenterdc.c| 1 +
board/kobol/helios4/helios4.c | 1 +
board/solidrun/clearfog/clearfog.c| 1 +
drivers/ddr/marvell/a38x/ddr3_init.c | 5
drivers/ddr/marvell/a38x/ddr3_init.h | 2 +-
drivers/ddr/marvell/a38x/ddr3_training.c | 5 +++-
drivers/ddr/marvell/a38x/ddr3_training_db.c | 3 +++
.../ddr/marvell/a38x/ddr3_training_ip_def.h | 2 ++
.../marvell/a38x/ddr3_training_ip_engine.c| 5 +++-
drivers/ddr/marvell/a38x/ddr_topology_def.h | 23 ++-
.../ddr/marvell/a38x/mv_ddr_build_message.c | 2 +-
drivers/ddr/marvell/a38x/mv_ddr_plat.c| 9 ++--
drivers/ddr/marvell/a38x/mv_ddr_topology.c| 14 ---
drivers/ddr/marvell/a38x/mv_ddr_topology.h| 2 ++
drivers/ddr/marvell/a38x/xor.c| 6 ++---
19 files changed, 73 insertions(+), 13 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 2da878d364..78b125edfe 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -285,6 +285,7 @@ static struct mv_ddr_topology_map board_topology_map_1g = {
MV_DDR_TIM_2T} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
@@ -307,6 +308,7 @@ static struct mv_ddr_topology_map board_topology_map_2g = {
MV_DDR_TIM_2T} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
index 9cd9ea2c06..acc8a5ec6d 100644
--- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
+++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
@@ -72,6 +72,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_DEFAULT} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
index 2bdd55329d..a1d0104526 100644
--- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
+++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
@@ -93,6 +93,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_DEFAULT} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
index c7438aeaf1..6caba24196 100644
--- a/board/alliedtelesi
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
Hi Simon,
On 06.02.2021 17:21, Simon Glass wrote:
> On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski
> wrote:
>> ...
>> Could you give me a bit more hints or point where to start? I've tried
>> to build sandbox, but it fails for v2021.01 release (I've did make
>> sandbox_defconfig && make all). I assume I would need to add adc and
>> adc-keys devices to some sandbox dts and some code triggering and
>> checking the key values, but that's all I know now.
> Well you do need to be able to build sandbox or you will get
> nowhere...what error did you get? Once we understand what went wrong
> we can update the docs. Maybe it is missing a dependency.
$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ git checkout v2021.01
$ make sandbox_defconfig
#
# configuration written to .config
#
$ make
scripts/kconfig/conf --syncconfig Kconfig
CFG u-boot.cfg
GEN include/autoconf.mk
GEN include/autoconf.mk.dep
CFGCHK u-boot.cfg
UPD include/generated/timestamp_autogenerated.h
HOSTCC tools/mkenvimage.o
HOSTLD tools/mkenvimage
HOSTCC tools/fit_image.o
HOSTCC tools/image-host.o
HOSTCC tools/dumpimage.o
HOSTLD tools/dumpimage
HOSTCC tools/mkimage.o
HOSTLD tools/mkimage
HOSTLD tools/fit_info
HOSTLD tools/fit_check_sign
...
CC arch/sandbox/cpu/cpu.o
In file included from include/common.h:26:0,
from arch/sandbox/cpu/cpu.c:6:
include/asm/global_data.h:112:58: warning: call-clobbered register used
for global register variable
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9")
^
include/dm/of.h:86:1: note: in expansion of macro ‘DECLARE_GLOBAL_DATA_PTR’
DECLARE_GLOBAL_DATA_PTR;
^~~
In file included from arch/sandbox/cpu/cpu.c:18:0:
./arch/sandbox/include/asm/state.h:98:30: error:
‘CONFIG_SANDBOX_SPI_MAX_BUS’ undeclared here (not in a function); did
you mean ‘CONFIG_SANDBOX_SPI’?
struct sandbox_spi_info spi[CONFIG_SANDBOX_SPI_MAX_BUS]
^~
CONFIG_SANDBOX_SPI
./arch/sandbox/include/asm/state.h:99:7: error:
‘CONFIG_SANDBOX_SPI_MAX_CS’ undeclared here (not in a function); did you
mean ‘CONFIG_SANDBOX_SPI_MAX_BUS’?
[CONFIG_SANDBOX_SPI_MAX_CS];
^
CONFIG_SANDBOX_SPI_MAX_BUS
arch/sandbox/cpu/cpu.c: In function ‘is_in_sandbox_mem’:
arch/sandbox/cpu/cpu.c:83:41: error: ‘volatile struct arch_global_data’
has no member named ‘ram_buf’
return (const uint8_t *)ptr >= gd->arch.ram_buf &&
^
arch/sandbox/cpu/cpu.c:84:34: error: ‘volatile struct arch_global_data’
has no member named ‘ram_buf’
(const uint8_t *)ptr < gd->arch.ram_buf + gd->ram_size;
^
arch/sandbox/cpu/cpu.c: At top level:
arch/sandbox/cpu/cpu.c:97:7: error: redefinition of ‘phys_to_virt’
void *phys_to_virt(phys_addr_t paddr)
^~~~
In file included from include/asm/io.h:495:0,
from arch/sandbox/cpu/cpu.c:15:
include/asm-generic/io.h:30:21: note: previous definition of
‘phys_to_virt’ was here
static inline void *phys_to_virt(phys_addr_t paddr)
^~~~
arch/sandbox/cpu/cpu.c: In function ‘phys_to_virt’:
arch/sandbox/cpu/cpu.c:104:27: error: ‘volatile struct arch_global_data’
has no member named ‘ram_buf’
return (void *)(gd->arch.ram_buf + paddr);
^
In file included from include/linux/posix_types.h:4:0,
from include/linux/types.h:4,
from include/time.h:7,
from include/common.h:18,
from arch/sandbox/cpu/cpu.c:6:
include/linux/stddef.h:17:33: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
^
include/linux/kernel.h:274:29: note: in expansion of macro ‘offsetof’
(type *)( (char *)__mptr - offsetof(type,member) );})
^~~~
include/linux/list.h:327:2: note: in expansion of macro ‘container_of’
container_of(ptr, type, member)
^~~~
include/linux/list.h:424:13: note: in expansion of macro ‘list_entry’
for (pos = list_entry((head)->next, typeof(*pos), member); \
^~
arch/sandbox/cpu/cpu.c:111:2: note: in expansion of macro
‘list_for_each_entry’
list_for_each_entry(mentry, &state->mapmem_head, sibling_node) {
^~~
include/linux/stddef.h:17:33: warning: cast from pointer to integer of
different size [-Wpointer-to-int-cast]
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER
Re: [PATCH u-boot-marvell] ARM: mvebu: a38x: sync ddr training code with mv_ddr-armada-14.0.0
Hi Marek,
On 08.02.21 17:04, Marek Behún wrote:
This syncs drivers/ddr/marvell/a38x/ with the mv-ddr-devel branch
of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git.
Specifically this syncs with commit fae3f6c98230 ("Bump mv_ddr to
release 14.0.0").
There is a new version numbering system, where after 18.12.0 came
1.0.0, 2.0.0, and so on until 14.0.0. So 14.0.0 is newer than 18.12.0.
There are some commits regarding DDR3 on top of version 14.0.0 in the
mv-ddr-marvell repository (from Chris Packham), but these changes
already are in U-Boot.
The complete log of changes is best obtained from the mv-ddr-marvell.git
repository but some relevant highlights are:
ddr3: allow board specific ODT configuration
mv_ddr: add 16Gbit memory devices support
mv_ddr: add support for twin-die combined memory device
mv_ddr: a38x: disable WL phase correction stage in case of bus_width=16bit
mv_ddr: a38x : fix memory cs size function
Great, thanks for working on this. But can't you instead of sending this
one big patch not send a list of separate patches (list above etc)? This
would make it easier to see and review the changes and also would
preserve the authorship of the patches.
Thanks,
Stefan
The default value for new option twin_die_combined is set to
NOT_COMBINED for all boards, as this was default behaviour prior this
change.
Signed-off-by: Marek Behún
Cc: Chris Packham
Cc: Chris Packham
Cc: Stefan Roese
Cc: Baruch Siach
Cc: Pavol Rohár
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 2 ++
board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 1 +
board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 1 +
board/alliedtelesis/x530/x530.c | 1 +
board/gdsys/a38x/controlcenterdc.c| 1 +
board/kobol/helios4/helios4.c | 1 +
board/solidrun/clearfog/clearfog.c| 1 +
drivers/ddr/marvell/a38x/ddr3_init.c | 5
drivers/ddr/marvell/a38x/ddr3_init.h | 2 +-
drivers/ddr/marvell/a38x/ddr3_training.c | 5 +++-
drivers/ddr/marvell/a38x/ddr3_training_db.c | 3 +++
.../ddr/marvell/a38x/ddr3_training_ip_def.h | 2 ++
.../marvell/a38x/ddr3_training_ip_engine.c| 5 +++-
drivers/ddr/marvell/a38x/ddr_topology_def.h | 23 ++-
.../ddr/marvell/a38x/mv_ddr_build_message.c | 2 +-
drivers/ddr/marvell/a38x/mv_ddr_plat.c| 9 ++--
drivers/ddr/marvell/a38x/mv_ddr_topology.c| 14 ---
drivers/ddr/marvell/a38x/mv_ddr_topology.h| 2 ++
drivers/ddr/marvell/a38x/xor.c| 6 ++---
19 files changed, 73 insertions(+), 13 deletions(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 2da878d364..78b125edfe 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -285,6 +285,7 @@ static struct mv_ddr_topology_map board_topology_map_1g = {
MV_DDR_TIM_2T} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
@@ -307,6 +308,7 @@ static struct mv_ddr_topology_map board_topology_map_2g = {
MV_DDR_TIM_2T} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
index 9cd9ea2c06..acc8a5ec6d 100644
--- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
+++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
@@ -72,6 +72,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_DEFAULT} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
index 2bdd55329d..a1d0104526 100644
--- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
+++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
@@ -93,6 +93,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_DEFAULT} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration
Re: [PATCH u-boot-marvell] ARM: mvebu: a38x: sync ddr training code with mv_ddr-armada-14.0.0
On Mon, 8 Feb 2021 17:24:16 +0100
Stefan Roese wrote:
> Hi Marek,
>
> On 08.02.21 17:04, Marek Behún wrote:
> > This syncs drivers/ddr/marvell/a38x/ with the mv-ddr-devel branch
> > of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git.
> > Specifically this syncs with commit fae3f6c98230 ("Bump mv_ddr to
> > release 14.0.0").
> >
> > There is a new version numbering system, where after 18.12.0 came
> > 1.0.0, 2.0.0, and so on until 14.0.0. So 14.0.0 is newer than 18.12.0.
> >
> > There are some commits regarding DDR3 on top of version 14.0.0 in the
> > mv-ddr-marvell repository (from Chris Packham), but these changes
> > already are in U-Boot.
> >
> > The complete log of changes is best obtained from the mv-ddr-marvell.git
> > repository but some relevant highlights are:
> >
> >ddr3: allow board specific ODT configuration
> >mv_ddr: add 16Gbit memory devices support
> >mv_ddr: add support for twin-die combined memory device
> >mv_ddr: a38x: disable WL phase correction stage in case of
> > bus_width=16bit
> >mv_ddr: a38x : fix memory cs size function
>
> Great, thanks for working on this. But can't you instead of sending this
> one big patch not send a list of separate patches (list above etc)? This
> would make it easier to see and review the changes and also would
> preserve the authorship of the patches.
Very well, I shall try to do it that way. BTW I forgot to change the
author (original author is Pali, I just updated the patch a little and
rewrote the commit message).
Re: [PATCH] nvme: Fix cache alignment
On Mon, 8 Feb 2021 16:49:58 +0100
Marek Vasut wrote:
Hi,
> On 2/8/21 2:32 PM, Andre Przywara wrote:
> [...]
> >>> +static void nvme_flush_dcache_range(void *start, unsigned long
> >>> size)
> >>> +{
> >>> + unsigned long s, e;
> >>> + nvme_align_dcache_range(start, size, &s, &e);
> >>> + flush_dcache_range(s, e);
> >
> > There is no good reason for alignment restrictions when it comes to
> > clean (& invalidate), so there is no need for this wrapper.
>
> Is that on ARM64-specific or is that applicable in general ? The
> driver
> is expected to work on any CPU.
> >>>
> >>> Cache clean (actually: cache clean&invalidate) is what happens on
> >>> evictions
> >>> all of the time, at the cache controller's discretion. So there is no
> >>> real harm in that operation per se. When an eviction happens on a
> >>> *clean* cache line, this is basically just an invalidate, which is
> >>> also not
> >>> harmful.
> >>>
> >>> There are harmful cases when buffers sharing a cache line are both
> >>> "just invalidated"
> >>> and "cleaned" at different points in time.
> >>
> >> Is that on ARM64-specific or is that applicable in general ? (the above
> >> does not answer that question)
> >
> > I would say that's a property of *every* write-back cache
> > implementation:
> > https://en.wikipedia.org/wiki/Cache_(computing)#/media/File:Write-back_with_write-allocation.svg
> >
>
> I've been reading and digesting the thread as it goes, and the only
> thing I do want to chime in on here right now is that yes, U-Boot
> does and will continue to support every CPU that someone wants to run it
> on, and one of the takeaways I see from this thread is we need some
> better documented abstractions around cache, as it's very tricky to get
> right all the time.
> >>>
> >>> Documenting the u-boot cache function behavior precisely is fine by me,
> >>> but
> >>> that is somewhat separate topic from this bugfix.
> >>>
> >>> So I will ask a simple question -- is there anything blocking this bugfix
> >>> from being applied ?
> >>
> >> While I can fix the typo, I'm waiting for an Ack/Reviewed-by from Bin
> >> (as he's spent the most time on this driver of late) and I'd really like
> >> one from Andre, or at least him agreeing this patch is a step in the
> >> right direction.
> >
> > As I said: I don't see how this patch changes anything on arm64, which
> > the commit messages claims to be the reason for this post.
> > If someone please can confirm, but invalidate_dcache_range() always
> > works on arm64, in fact does the very rounding already that this patch
> > introduces here. So what is the actual fix here?
>
> You can NOT depend on the behavior of cache functions on specific
> architecture, U-Boot is universal and this must work on every single
> architecture, not just aarch64.
I totally understand and support that! See my patch to address the
problem.
What I am wondering is how your patch fixes anything on *arm64*, when
there is no actual change in the argument to the "dc ivac" instruction?
> The entire point of this patch is to call flush/invalidate only with
> cacheline-aligned addresses, which is what they expect, otherwise
> these functions do no operation at all.
First, "doing no operation at all" is some debatable behaviour, I'd
rather see it panic or at least always print an error.
Secondly: this is not the case in this particular case (arm64) that you
mention in the commit message: The invalidate goes through anyway.
> > Plus, I consider this blanket rounding more harmful than helpful, since
> > it actually just silences the check_cache_range() check.
>
> Can you back this claim with something ? Because I spent my fair share
> of time analyzing the driver and the rounding is exactly sufficient to
> make the cache ops work correctly.
So here is my point (again): When we want to invalidate a buffer, it
must be cache line aligned to work correctly - not (only) because of
U-Boot's check, but because you run into problems with invalidating
*other* (potentially dirty) data sharing the same cache line otherwise.
That is the whole point of check_cache_range() in the first place.
And I think we agree on this.
Now: How do you prevent this problem by just rounding the *addresses*
you pass to the cache maintenance instruction?
If a buffer address is not aligned, you want to know about it! Normally
all buffer addresses should be *always* aligned, the driver needs to be
designed this way. So there is no need for rounding.
When now an unaligned address sneaks in - either due to a bug or an
inherent driver design problem - I actually want to see fireworks! At
least the check_cache_range() check should trigger. With blanket
rounding you deliberately disable this check,
Re: [PATCH 13/13] arm: stm32: Disable ATAGs support
Hi Tom,
On 2/4/21 3:24 AM, Tom Rini wrote:
These platforms never had to support an ATAGs-based Linux Kernel, so
remove the options.
Cc: Kamil Lulko
Cc: Patrick Delaunay
Cc: Patrice Chotard
Cc: Vikas Manocha
Cc: Marek Vasut
Signed-off-by: Tom Rini
---
I'm assuming, please correct me if I'm wrong.
---
include/configs/stm32f429-discovery.h | 5 -
include/configs/stm32f429-evaluation.h | 5 -
include/configs/stm32f469-discovery.h | 5 -
include/configs/stm32f746-disco.h | 5 -
include/configs/stm32h743-disco.h | 5 -
include/configs/stm32h743-eval.h | 5 -
include/configs/stm32mp1.h | 5 -
7 files changed, 35 deletions(-)
Yes you are right.
It is inherited of the first U-boot porting (before full DM and FDT
support).
Reviewed-by: Patrick Delaunay
For information the initialization parts can be removed in boards
support (as no more used):
gd->bd->bi_boot_params = gd->bd->bi_dram[0].start + 0x100;
in ./board/st/
- stm32f429-evaluation/stm32f429-evaluation.c:54:
- stm32h743-disco/stm32h743-disco.c:55:
- stm32f429-discovery/stm32f429-discovery.c:60:
- stm32mp1/stm32mp1.c:644:
- stm32f746-disco/stm32f746-disco.c:129:
- stm32f469-discovery/stm32f469-discovery.c:54:
- stm32h743-eval/stm32h743-eval.c:55:
But I will push a separate patch for this point.
Just one question for other part of generic code which can be removed
bi_boot_params should be under compilation BOOTM_ENABLE_TAGS flags ?
In include/asm-generic/u-boot.h:70
struct bd_info {
ulong bi_boot_params; /* where this board expects
params */
...
};
and also params global variables, only used in setup_XXX functions ?
arch/arm/lib/bootm.c:44:
static struct tag *params;
Regards
Thanks
Patrick
Re: [PATCH v4] fastboot: add UUU command UCmd and ACmd support
Hi Heiko,
On 2/8/21 12:38 PM, Heiko Schocher wrote:
add support for the UUU commands ACmd and UCmd.
Enable them through the Kconfig option
CONFIG_FASTBOOT_UUU_SUPPORT
base was commit in NXP kernel
9b149c2a2882: ("MLK-18591-3 android: Add FSL android fastboot support")
and ported it to current mainline. Tested this patch
on imx6ul based board.
Signed-off-by: Heiko Schocher
---
azure build was fine:
https://dev.azure.com/hs0298/hs/_build/results?buildId=59&view=results
Changes in v4:
- fixed missing parts from Sean Anderson patches
lost while rebased to tree from lukasz
Changes in v3:
- rebased to https://github.com/lmajewski/u-boot-dfu/commits/testing
as Lukasz mentioned.
Changes in v2:
- remove unused FSL_FASTBOOT option
- add comment from Roman:
do not enable this option per default
add Kconfig comment that enabling this option may
introduce a security issue.
doc/android/fastboot-protocol.rst | 5 +++
doc/android/fastboot.rst | 2 +
drivers/fastboot/Kconfig | 9 +
drivers/fastboot/fb_command.c | 62 +++
drivers/usb/gadget/f_fastboot.c | 17 +
include/fastboot.h| 7
6 files changed, 102 insertions(+)
(...)
diff --git a/drivers/fastboot/fb_command.c b/drivers/fastboot/fb_command.c
index 41fc8d7904d..960e73089e0 100644
--- a/drivers/fastboot/fb_command.c
+++ b/drivers/fastboot/fb_command.c
(...)
+
+static char g_a_cmd_buff[64];
+
+void fastboot_acmd_complete(void)
+{
+ run_command(g_a_cmd_buff, 0);
+}
+
+/**
+ * run_acmd() - Execute the ACmd command
+ *
+ * @cmd_parameter: Pointer to command parameter
+ * @response: Pointer to fastboot response buffer
+ */
+static void run_acmd(char *cmd_parameter, char *response)
+{
+ if (!cmd_parameter) {
+ pr_err("missing slot suffix\n");
+ fastboot_fail("missing command", response);
+ return;
+ }
+
+ strcpy(g_a_cmd_buff, cmd_parameter);
to avoid overflow:
+ strncpy (g_a_cmd_buff, cmd_parameter, sizeof(g_a_cmd_buff));
or check strlen(cmd_parameter) ?
+ if (check strlen(cmd_parameter) > sizeof(g_a_cmd_buff)) {
+ pr_err("too long command\n");
+ fastboot_fail("too long command", response);
+ return;
+ }
+ fastboot_okay(NULL, response);
+}
+#endif
+
/**
* reboot_bootloader() - Sets reboot bootloader flag.
*
diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c
index 950cc119495..8ba55aab9f8 100644
--- a/drivers/usb/gadget/f_fastboot.c
+++ b/drivers/usb/gadget/f_fastboot.c
@@ -494,6 +494,18 @@ static void do_bootm_on_complete(struct usb_ep *ep, struct
usb_request *req)
do_exit_on_complete(ep, req);
}
(...)
Anyway, except this remark.
Acked-by: Patrick Delaunay
Regards
Patrick
Wrong check for last block in lib/efi_loader/efi_disk.c?
Hi I was not able to read the last block of my sd card (the gpt backup block) without the following diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c index d0aad0252a..ea9d763072 100644 --- a/lib/efi_loader/efi_disk.c +++ b/lib/efi_loader/efi_disk.c @@ -147,7 +147,7 @@ static efi_status_t EFIAPI efi_disk_read_blocks(struct efi_block_io *this, (uintptr_t)buffer & (this->media->io_align - 1)) return EFI_INVALID_PARAMETER; if (lba * this->media->block_size + buffer_size > - this->media->last_block * this->media->block_size) + this->media->last_block * this->media->block_size + this->media->block_size) return EFI_INVALID_PARAMETER; Is my math wrong or is my patch correct? With the patch the my efiloader can read the gpt backup block correctly, Thanks /Jesper
Re: [PATCH v1] test: Allow simple glob pattern in the test name
Hi Andy, On Mon, 8 Feb 2021 at 04:34, Andy Shevchenko wrote: > > On Sun, Feb 07, 2021 at 07:37:55AM -0700, Simon Glass wrote: > > On Fri, 5 Feb 2021 at 13:46, Andy Shevchenko > > wrote: > > > On Fri, Feb 05, 2021 at 09:17:27PM +0200, Andy Shevchenko wrote: > > > > On Fri, Feb 05, 2021 at 08:15:25PM +0200, Andy Shevchenko wrote: > > > > > On Fri, Feb 05, 2021 at 07:34:49PM +0200, Andy Shevchenko wrote: > > > > > > On Thu, Feb 04, 2021 at 08:17:24PM -0700, Simon Glass wrote: > > > > > > > > > > ... > > > > > > > > > > > Btw, you have an issue there, i.e. if test case failed, all > > > > > > percentage after it > > > > > > goes red, which is wrong. > > > > > > > > > > One more thing, is it known bug that either in the original code, or > > > > > in your > > > > > new branch the following test case is 100% failed? > > > > > > > > > > /* Non-existent in DTB */ > > > > > ut_asserteq(FDT_ADDR_T_NONE, dev_read_addr(dev)); > > > > > > > > > > Can you fix this sooner than later, please? > > > > > > > > Actually it seems this very patch makes the issue visible (I suppose > > > > something > > > > with test case names). > > > > > > Okay, actually there *is* a problem with the test suite, i.e. you may not > > > run > > > some test cases twice during the same session. > > > > If this is related to the squashfs tests? I have disabled them for now > > in my local tree. > > I don't think it's related to the certain test case, it's a test suite design > issue and how some of the test cases have been written. So, if you run u-boot > application and manually run `ut dm` in there, > - first time: Failures: 0 > - second time: Failures: 9 > - third and next time: Failures: 12 > > Means that 12 test cases are written badly. OK I see. It did not use to be possible to pass all tests without running through pytest, which does some setup. You still need to create a 'spi.bin' file for the SPI tests to pass. I'm not sure what prevents multiple runs without quitting U-Boot, but I suspect it is just some state hanging around, as we don't reset everything. For example, sandbox provides control of what happens when a sysreset is performed, and perhaps that is not reset to initial values correct by state_reset_for_test().. Regards, Simon
Re: [PATCH 01/10] README: Add doumentation for version information
Hi Patrick, On Mon, 8 Feb 2021 at 06:52, Patrick DELAUNAY wrote: > > Hi Simon > > on tipo in title: > > s/doumentation/documentation/ > > On 1/7/21 5:21 AM, Simon Glass wrote: > > There are quite a few available version options in U-Boot. Add a list of > > the available Makefile variables and #defines, along with examples. > > > > Signed-off-by: Simon Glass > > --- > > > > README | 84 ++ > > 1 file changed, 84 insertions(+) > > > Just one remark, this information could be integrated in generated > U-Boot documentation > > for example => develop/version.rst (under "Implementation") > > Reviewed-by: Patrick Delaunay Actually yes Heinrich had the same suggestion and I sent a new version. Regards, Simon
Re: [PATCH 0/3] test: Try to deal with some co-dependent tests
Hi Heinrich, On Mon, 8 Feb 2021 at 00:25, Heinrich Schuchardt wrote: > > On 2/8/21 5:05 AM, Simon Glass wrote: > > Tests are supposed to be independent. With driver model tests, the > > environment is reset before each test, which ensures that. > > > > With Python tests there is no reset of the board between tests, since we > > want to run all the tests as quickly as possible and without needing the > > external scripts running constantly. > > > > In principle the Python tests can be independent if they each put the > > world back the way they found it, but it turns out that some are not. > > This means that some tests cannot be run unless another test is run > > first. It also means that tests cannot be run in parallel, e.g. on > > sandbox. > > > > This series fixes some of them. Those that remain: > > > > test_gpt_swap_partitions - not sure? > > test_pinmux_status - not sure? > > test_sqfs_load - cannot be run more than once! > > test_bind_unbind_with_uclass - relies on previous test > > > > The last one would be much better done as a C test, so it doesn't have > > to deal with the changing driver tree. There isn't a lot of value in > > running the test on a real board, since sandbox should find any bugs > > in driver model or the 'bind' command. > > > > If the above can be resolved we can enable parallel tests. On my test > > machine (32 threads) it reduces the time from 38 seconds to 7.5s > > > > To use this feature: > > pip3 install pytest-xdist > > > > test/py/test.py -B sandbox --build-dir /tmp/xx -q -k 'not slow' -n32 > > Thanks for looking into parallelization. > > What I am missing in this series is a patch for > doc/develop/py_testing.rst describing how parallelization of Python > tests is controlled. I don't think we can mention that yet, as it doesn't actually work. > > I have seen that test/py/tests/test_fs/test_basic.py test_fs1() is > always failing on my machine because the test file 2.5GB.file is > truncated. It is not truncated if I add some waiting time. > > Could this be caused by parallelization? Not at present since we don't use it. I seldom run those tests. I wonder whether they work once and then not again, i.e. something needs to be reset at the start of that test? Also I have not even tried to parallelise those tests. For me they use too much memory. > > Package 'python3-pytest-xdist' is not installed on my system. OK. Then the -n flag is not available. Regards, Simon
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
HI Marek,
On Mon, 8 Feb 2021 at 09:10, Marek Szyprowski wrote:
>
> Hi Simon,
>
> On 06.02.2021 17:21, Simon Glass wrote:
> > On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski
> > wrote:
> >> ...
> >> Could you give me a bit more hints or point where to start? I've tried
> >> to build sandbox, but it fails for v2021.01 release (I've did make
> >> sandbox_defconfig && make all). I assume I would need to add adc and
> >> adc-keys devices to some sandbox dts and some code triggering and
> >> checking the key values, but that's all I know now.
> > Well you do need to be able to build sandbox or you will get
> > nowhere...what error did you get? Once we understand what went wrong
> > we can update the docs. Maybe it is missing a dependency.
>
> $ gcc --version
> gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions. There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> $ git checkout v2021.01
>
> $ make sandbox_defconfig
> #
> # configuration written to .config
> #
>
> $ make
> scripts/kconfig/conf --syncconfig Kconfig
>CFG u-boot.cfg
>GEN include/autoconf.mk
>GEN include/autoconf.mk.dep
>CFGCHK u-boot.cfg
>UPD include/generated/timestamp_autogenerated.h
>HOSTCC tools/mkenvimage.o
>HOSTLD tools/mkenvimage
>HOSTCC tools/fit_image.o
>HOSTCC tools/image-host.o
>HOSTCC tools/dumpimage.o
>HOSTLD tools/dumpimage
>HOSTCC tools/mkimage.o
>HOSTLD tools/mkimage
>HOSTLD tools/fit_info
>HOSTLD tools/fit_check_sign
>
> ...
>
>CC arch/sandbox/cpu/cpu.o
> In file included from include/common.h:26:0,
> from arch/sandbox/cpu/cpu.c:6:
> include/asm/global_data.h:112:58: warning: call-clobbered register used
> for global register variable
> #define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9")
>^
> include/dm/of.h:86:1: note: in expansion of macro ‘DECLARE_GLOBAL_DATA_PTR’
> DECLARE_GLOBAL_DATA_PTR;
This is pretty mysterious. Are you sure you are using an x86_64 machine?
Regards,
Simon
Re: [PATCH 1/2] sunxi: binman: Respect the default FIT configuration
On Sun, 7 Feb 2021 at 23:03, Samuel Holland wrote: > > binman can fill in the default FIT configuration index as selected by > the "default-dt" argument, which is set to CONFIG_DEFAULT_DEVICE_TREE. > Let's respect the user's configuration by taking advantage of this > feature, instead of always defaulting to the first device tree in > CONFIG_OF_LIST. > > Signed-off-by: Samuel Holland > --- > arch/arm/dts/sunxi-u-boot.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 2/3] cmd: SCP03: enable and provision command
Hi Jorge, On Sun, 7 Feb 2021 at 11:11, Jorge Ramirez-Ortiz, Foundries wrote: > > On 07/02/21, Simon Glass wrote: > > Hi Jorge, > > > > On Sat, 6 Feb 2021 at 16:05, Jorge Ramirez-Ortiz wrote: > > > > > > Enable and provision the SCP03 keys on a TEE controlled secured elemt > > > from the U-Boot shell. > > > > > > Signed-off-by: Jorge Ramirez-Ortiz > > > --- > > > cmd/Kconfig | 9 > > > cmd/Makefile | 3 +++ > > > cmd/scp03.c | 64 > > > 3 files changed, 76 insertions(+) > > > create mode 100644 cmd/scp03.c > > > > Can we have a test for this please? See mem_search.c for an example. > > you mean other than what I posted already (the sandbox test using the > TEE emulator)? > > I am not really sure what else can it do: this command sends a request > to a TEE and waits to a response (and both are emulated on the sandbox). It should just be a few lines of code to test the basics. E.g.: https://github.com/u-boot/u-boot/blob/3936fd998668846f77468d8f6a662e906920969c/test/cmd/test_echo.c#L42 Regards, Simon
Re: [PATCH 2/2] sunxi: binman: Do not hardcode U-Boot load address
On Sun, 7 Feb 2021 at 23:03, Samuel Holland wrote: > > The FIT description has access to the configuration variables. Use the > appropriate variable instead of hardcoding the address. > > Signed-off-by: Samuel Holland > --- > arch/arm/dts/sunxi-u-boot.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass
Re: [PATCH 01/13] arm: nanopi2: Remove unused code
Hi,
thanks for the info, I'll have a look at this.
Regards
Stefan
On 04.02.21 03:24, Tom Rini wrote:
This platform did not ever enable CONFIG_REVISION_TAG, so the code to
set the board_rev environment variable was never enabled. This
particular symbol is also only for use with the REVISION ATAG and this
platform is new enough to have never supported an ATAG-based Linux
Kernel.
Cc: Stefan Bosch
Signed-off-by: Tom Rini
---
I'd be happy to see this patch replaced by one that enables what I think
you meant to be doing and by default. Thanks!
---
board/friendlyarm/nanopi2/board.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/board/friendlyarm/nanopi2/board.c
b/board/friendlyarm/nanopi2/board.c
index 68980536abe9..6e546853b863 100644
--- a/board/friendlyarm/nanopi2/board.c
+++ b/board/friendlyarm/nanopi2/board.c
@@ -294,16 +294,6 @@ static void set_ether_addr(void)
env_set("ethaddr", ethaddr);
}
-#ifdef CONFIG_REVISION_TAG
-static void set_board_rev(void)
-{
- char info[64] = {0, };
-
- snprintf(info, ARRAY_SIZE(info), "%02x", get_board_rev());
- env_set("board_rev", info);
-}
-#endif
-
static void set_dtb_name(void)
{
char info[64] = {0, };
@@ -435,9 +425,6 @@ int board_late_init(void)
{
bd_update_env();
-#ifdef CONFIG_REVISION_TAG
- set_board_rev();
-#endif
set_dtb_name();
set_ether_addr();
Re: [PATCH v4 10/16] dm: gpio: Add a way to update flags
Hi Simon,
2 minor remarks,
On 2/5/21 5:22 AM, Simon Glass wrote:
It is convenient to be able to adjust some of the flags for a GPIO while
leaving others alone. Add a function for this.
Update dm_gpio_set_dir_flags() to make use of this.
Also update dm_gpio_set_value() to use this also, since this allows the
open-drain / open-source features to be implemented directly in the
driver, rather than using the uclass workaround.
Update the sandbox tests accordingly. This involves a lot of changes to
dm_test_gpio_opendrain_opensource() since we no-longer have the direciion
being reported differently depending on the open drain/open source flags.
Also update the STM32 drivers to let the uclass handle the active low/high
logic.
Drop the GPIOD_FLAGS_OUTPUT() macro which is no-longer used.
Signed-off-by: Simon Glass
---
Changes in v4:
- Update dm_gpio_set_dir_flags() to clear direction flags first
Changes in v3:
- Incorporate GPIOD_FLAGS_OUTPUT() changes from Patrick Delaunay
drivers/gpio/gpio-uclass.c | 75 ++
drivers/gpio/stm32_gpio.c | 3 +-
drivers/pinctrl/pinctrl-stmfx.c | 5 +-
include/asm-generic/gpio.h | 31 ++--
test/dm/gpio.c | 132
5 files changed, 203 insertions(+), 43 deletions(-)
(...)
diff --git a/drivers/gpio/stm32_gpio.c b/drivers/gpio/stm32_gpio.c
index c2d7046c0dd..125c237551c 100644
--- a/drivers/gpio/stm32_gpio.c
+++ b/drivers/gpio/stm32_gpio.c
@@ -203,12 +203,13 @@ static int stm32_gpio_set_flags(struct udevice *dev,
unsigned int offset,
return idx;
if (flags & GPIOD_IS_OUT) {
- int value = GPIOD_FLAGS_OUTPUT(flags);
+ bool value = flags & GPIOD_IS_OUT_ACTIVE;
here the bool variable valeu can be 0 or GPIOD_IS_OUT_ACTIVE = BIT(4),
so it should have
+ bool value = !!(flags & GPIOD_IS_OUT_ACTIVE);
or
+ int value = flags & GPIOD_IS_OUT_ACTIVE;
PS: not functional impact as
#define BSRR_BIT(gpio_pin, value) BIT((gpio_pin) + (value ? 0 : 16))
if (flags & GPIOD_OPEN_DRAIN)
stm32_gpio_set_otype(regs, idx, STM32_GPIO_OTYPE_OD);
else
stm32_gpio_set_otype(regs, idx, STM32_GPIO_OTYPE_PP);
+
stm32_gpio_set_moder(regs, idx, STM32_GPIO_MODE_OUT);
writel(BSRR_BIT(idx, value), ®s->bsrr);
diff --git a/drivers/pinctrl/pinctrl-stmfx.c b/drivers/pinctrl/pinctrl-stmfx.c
index 8ddbc3dc281..711b1a5d8c4 100644
--- a/drivers/pinctrl/pinctrl-stmfx.c
+++ b/drivers/pinctrl/pinctrl-stmfx.c
@@ -169,6 +169,8 @@ static int stmfx_gpio_set_flags(struct udevice *dev,
unsigned int offset,
int ret = -ENOTSUPP;
if (flags & GPIOD_IS_OUT) {
+ bool value = flags & GPIOD_IS_OUT_ACTIVE;
+
same here
+ int value = flags & GPIOD_IS_OUT_ACTIVE;
or
+ bool value = !!(flags & GPIOD_IS_OUT_ACTIVE);
But no impact
if (flags & GPIOD_OPEN_SOURCE)
return -ENOTSUPP;
if (flags & GPIOD_OPEN_DRAIN)
@@ -177,8 +179,7 @@ static int stmfx_gpio_set_flags(struct udevice *dev,
unsigned int offset,
ret = stmfx_conf_set_type(dev, offset, 1);
if (ret)
return ret;
- ret = stmfx_gpio_direction_output(dev, offset,
- GPIOD_FLAGS_OUTPUT(flags));
+ ret = stmfx_gpio_direction_output(dev, offset, value);
} else if (flags & GPIOD_IS_IN) {
ret = stmfx_gpio_direction_input(dev, offset);
if (ret)
(...)
With the 2 remarks
Reviewed-by: Patrick Delaunay
Tested-by: Patrick Delaunay
Regards,
Patrick
Re: [PATCH v1] test: Allow simple glob pattern in the test name
On Mon, Feb 08, 2021 at 10:07:55AM -0700, Simon Glass wrote: > On Mon, 8 Feb 2021 at 04:34, Andy Shevchenko > wrote: > > On Sun, Feb 07, 2021 at 07:37:55AM -0700, Simon Glass wrote: > > > On Fri, 5 Feb 2021 at 13:46, Andy Shevchenko > > > wrote: > > > > On Fri, Feb 05, 2021 at 09:17:27PM +0200, Andy Shevchenko wrote: > > > > > On Fri, Feb 05, 2021 at 08:15:25PM +0200, Andy Shevchenko wrote: > > > > > > On Fri, Feb 05, 2021 at 07:34:49PM +0200, Andy Shevchenko wrote: > > > > > > > On Thu, Feb 04, 2021 at 08:17:24PM -0700, Simon Glass wrote: > > > > > > > > > > > > ... > > > > > > > > > > > > > Btw, you have an issue there, i.e. if test case failed, all > > > > > > > percentage after it > > > > > > > goes red, which is wrong. > > > > > > > > > > > > One more thing, is it known bug that either in the original code, > > > > > > or in your > > > > > > new branch the following test case is 100% failed? > > > > > > > > > > > > /* Non-existent in DTB */ > > > > > > ut_asserteq(FDT_ADDR_T_NONE, dev_read_addr(dev)); > > > > > > > > > > > > Can you fix this sooner than later, please? > > > > > > > > > > Actually it seems this very patch makes the issue visible (I suppose > > > > > something > > > > > with test case names). > > > > > > > > Okay, actually there *is* a problem with the test suite, i.e. you may > > > > not run > > > > some test cases twice during the same session. > > > > > > If this is related to the squashfs tests? I have disabled them for now > > > in my local tree. > > > > I don't think it's related to the certain test case, it's a test suite > > design issue and how some of the test cases have been written. So, if you > > run u-boot application and manually run `ut dm` in there, > > - first time: Failures: 0 > > - second time: Failures: 9 > > - third and next time: Failures: 12 > > > > Means that 12 test cases are written badly. > > OK I see. It did not use to be possible to pass all tests without > running through pytest, which does some setup. You still need to > create a 'spi.bin' file for the SPI tests to pass. I run it _after_ the official pytest passed. So, every file is prepared. > I'm not sure what prevents multiple runs without quitting U-Boot, but > I suspect it is just some state hanging around, as we don't reset > everything. For example, sandbox provides control of what happens when > a sysreset is performed, and perhaps that is not reset to initial > values correct by state_reset_for_test().. I believe this is the case in most of the cases. -- With Best Regards, Andy Shevchenko
Re: [PATCH v5 2/4] button: add a simple Analog to Digital Converter device based button driver
On 2/8/21 6:08 PM, Simon Glass wrote:
HI Marek,
On Mon, 8 Feb 2021 at 09:10, Marek Szyprowski wrote:
Hi Simon,
On 06.02.2021 17:21, Simon Glass wrote:
On Thu, 4 Feb 2021 at 03:36, Marek Szyprowski wrote:
...
Could you give me a bit more hints or point where to start? I've tried
to build sandbox, but it fails for v2021.01 release (I've did make
sandbox_defconfig && make all). I assume I would need to add adc and
adc-keys devices to some sandbox dts and some code triggering and
checking the key values, but that's all I know now.
Well you do need to be able to build sandbox or you will get
nowhere...what error did you get? Once we understand what went wrong
we can update the docs. Maybe it is missing a dependency.
$ gcc --version
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ git checkout v2021.01
$ make sandbox_defconfig
#
# configuration written to .config
#
$ make
scripts/kconfig/conf --syncconfig Kconfig
CFG u-boot.cfg
GEN include/autoconf.mk
GEN include/autoconf.mk.dep
CFGCHK u-boot.cfg
UPD include/generated/timestamp_autogenerated.h
HOSTCC tools/mkenvimage.o
HOSTLD tools/mkenvimage
HOSTCC tools/fit_image.o
HOSTCC tools/image-host.o
HOSTCC tools/dumpimage.o
HOSTLD tools/dumpimage
HOSTCC tools/mkimage.o
HOSTLD tools/mkimage
HOSTLD tools/fit_info
HOSTLD tools/fit_check_sign
...
CC arch/sandbox/cpu/cpu.o
In file included from include/common.h:26:0,
from arch/sandbox/cpu/cpu.c:6:
include/asm/global_data.h:112:58: warning: call-clobbered register used
for global register variable
#define DECLARE_GLOBAL_DATA_PTR register volatile gd_t *gd asm ("r9")
^
include/dm/of.h:86:1: note: in expansion of macro ‘DECLARE_GLOBAL_DATA_PTR’
DECLARE_GLOBAL_DATA_PTR;
This is pretty mysterious. Are you sure you are using an x86_64 machine?
r9 relates to ARMv7.
You have to unset CROSS_COMPILE when you build the sandbox.
The sandbox runs fine on aarch64.
There are a bunch of errors currently when building on 32bit
architectures. Simon has a lot of patches pending.
Best regards
Heinrich
Re: [PATCH v4 16/16] gpio: Add a way to read 3-way strapping pins
Hi Simon,
On 2/5/21 5:22 AM, Simon Glass wrote:
Using the internal vs. external pull resistors it is possible to get
27 different combinations from 3 strapping pins. Add an implementation
of this.
This involves updating the sandbox GPIO driver to model external and
(weaker) internal pull resistors. The get_value() method now takes account
of what is driving a pin:
sandbox: GPIOD_EXT_DRIVEN - in which case GPIO_EXT_HIGH provides the
value
outside source - in which case GPIO_EXT_PULL_UP/DOWN indicates the
external state and we work the final state using those flags and
the internal GPIOD_PULL_UP/DOWN flags
Of course the outside source does not really exist in sandbox. We are just
modelling it for test purpose.
Signed-off-by: Simon Glass
---
(no changes since v3)
Changes in v3:
- Use bits 28, 29 for the new flags
- Assert that count parameter is within range
- Redo digit logic to be easier to understand
- Update function comment to explain the meaning of the digits
- Fix 'compare' typo
arch/sandbox/include/asm/gpio.h | 5 +-
drivers/gpio/gpio-uclass.c | 81 +++
drivers/gpio/sandbox.c | 13 +++--
include/asm-generic/gpio.h | 40 ++
test/dm/gpio.c | 98 +
5 files changed, 232 insertions(+), 5 deletions(-)
(...)
diff --git a/drivers/gpio/sandbox.c b/drivers/gpio/sandbox.c
index 700098446b5..d008fdd2224 100644
--- a/drivers/gpio/sandbox.c
+++ b/drivers/gpio/sandbox.c
@@ -19,7 +19,6 @@
#include
#include
-
struct gpio_state {
const char *label; /* label given by requester */
ulong flags;/* flags (GPIOD_...) */
@@ -81,10 +80,16 @@ int sandbox_gpio_get_value(struct udevice *dev, unsigned
offset)
if (get_gpio_flag(dev, offset, GPIOD_IS_OUT))
debug("sandbox_gpio: get_value on output gpio %u\n", offset);
- if (state->flags & GPIOD_EXT_DRIVEN)
+ if (state->flags & GPIOD_EXT_DRIVEN) {
val = state->flags & GPIOD_EXT_HIGH;
bool here, not int
+ val = !!(state->flags & GPIOD_EXT_HIGH);
- else
- val = false;
+ } else {
+ if (state->flags & GPIOD_EXT_PULL_UP)
+ val = true;
+ else if (state->flags & GPIOD_EXT_PULL_DOWN)
+ val = false;
+ else
+ val = state->flags & GPIOD_PULL_UP;
bool also
+ val = !!(state->flags & GPIOD_PULL_UP );
+ }
return val;
}
(...)
Just to be sure that the sandbox gpio value is 0 or 1
with the current code, sandbox_gpio_get_value can return GPIOD_EXT_HIGH
or GPIOD_PULL_UP, and it is strange (even if result in int).
with these 2 changes, you can add my Reviewed-by
Regards
Patrick
[PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
This syncs drivers/ddr/marvell/a38x/ with the mv-ddr-devel branch of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git. There are some commits regarding DDR3 on top of version 14.0.0 in the mv-ddr-marvell repository (from Chris Packham), but these changes already are in U-Boot. Marek Marek Behún (18): ddr: marvell: a38x: fix write leveling suplementary algo ddr: marvell: a38x: import header change from upstream ddr: marvell: a38x: add ddr32 support ddr: marvell: a38x: add ddr 32bit ECC support ddr: marvell: a38x: import header change from upstream ddr: marvell: a38x: fix 32bit ddr: marvell: a38x: fix memory size calculation using 32bit bus width ddr: marvell: a38x: import header change from upstream ddr: marvell: a38x: allow board specific ODT configuration ddr: marvell: a38x: add 16Gbit memory devices support ddr: marvell: a38x: add support for twin-die combined memory device ddr: marvell: a38x: disable WL phase correction stage in case of bus_width=16bit ddr: marvell: a38x: import header change from upstream ddr: marvell: a38x: fix memory cs size function ddr: marvell: a38x: import code change from upstream ddr: marvell: a38x: enum mv_ddr_twin_die: change order ddr: marvell: a38x: bump version to 14.0.0 ddr: marvell: a38x: fix comment in conditional macro board/CZ.NIC/turris_omnia/turris_omnia.c | 2 ++ board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 1 + board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 1 + board/alliedtelesis/x530/x530.c | 1 + board/gdsys/a38x/controlcenterdc.c| 1 + board/kobol/helios4/helios4.c | 1 + board/solidrun/clearfog/clearfog.c| 1 + drivers/ddr/marvell/a38x/ddr3_init.c | 5 drivers/ddr/marvell/a38x/ddr3_training.c | 5 +++- drivers/ddr/marvell/a38x/ddr3_training_db.c | 3 +++ .../ddr/marvell/a38x/ddr3_training_ip_def.h | 2 ++ .../marvell/a38x/ddr3_training_ip_engine.c| 5 +++- drivers/ddr/marvell/a38x/ddr_topology_def.h | 23 ++- .../ddr/marvell/a38x/mv_ddr_build_message.c | 2 +- drivers/ddr/marvell/a38x/mv_ddr_plat.c| 9 ++-- drivers/ddr/marvell/a38x/mv_ddr_topology.c| 14 --- drivers/ddr/marvell/a38x/mv_ddr_topology.h| 2 ++ drivers/ddr/marvell/a38x/xor.c| 6 ++--- 18 files changed, 72 insertions(+), 12 deletions(-) -- 2.26.2
[PATCH u-boot-marvell 01/18] ddr: marvell: a38x: fix write leveling suplementary algo
commit ce62bef8fac559e27245259882e45f19cdc293ad upstream.
- fix JIRA A7K8K-5056
- remove TEST_PATTERN write at the load patern stage earlier to WL SUP stage
- the WL SUP stage already writes this pattern to the memory, if the pattern
exist at the memory
then the algorithm will fail, since it think that there are no phase to
correct
Signed-off-by: motib
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
index 979f3530b7..5fd9a052fa 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
@@ -864,8 +864,11 @@ int ddr3_tip_load_all_pattern_to_mem(u32 dev_num)
DUAL_DUNIT_CFG_REG, (1 << 3), (1 << 3)));
}
- for (pattern = 0; pattern < PATTERN_LAST; pattern++)
+ for (pattern = 0; pattern < PATTERN_LAST; pattern++) {
+ if (pattern == PATTERN_TEST)
+ continue;
ddr3_tip_load_pattern_to_mem(dev_num, pattern);
+ }
return MV_OK;
}
--
2.26.2
[PATCH u-boot-marvell 03/18] ddr: marvell: a38x: add ddr32 support
commit 32800667b375ebd1f82120da0f3479b1cf52d96d upstream.
Required changes made for 32bit ddr support.
An update is made to the topology map, according to
bus_act_mask, set in the dram_port.c
Signed-off-by: Alex Leibovich
Reviewed-by: Nadav Haklai
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/mv_ddr_topology.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index 09840b1e70..f2cd7c0ef3 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -144,6 +144,9 @@ unsigned short mv_ddr_bus_bit_mask_get(void)
unsigned int octets_per_if_num = ddr3_tip_dev_attr_get(0,
MV_ATTR_OCTET_PER_INTERFACE);
if (tm->cfg_src == MV_DDR_CFG_SPD) {
+ if (tm->bus_act_mask == BUS_MASK_32BIT)
+ tm->spd_data.byte_fields.byte_13.all_bits =
MV_DDR_PRI_BUS_WIDTH_32;
+
enum mv_ddr_pri_bus_width pri_bus_width =
mv_ddr_spd_pri_bus_width_get(&tm->spd_data);
enum mv_ddr_bus_width_ext bus_width_ext =
mv_ddr_spd_bus_width_ext_get(&tm->spd_data);
@@ -151,7 +154,7 @@ unsigned short mv_ddr_bus_bit_mask_get(void)
case MV_DDR_PRI_BUS_WIDTH_16:
pri_and_ext_bus_width = BUS_MASK_16BIT;
break;
- case MV_DDR_PRI_BUS_WIDTH_32:
+ case MV_DDR_PRI_BUS_WIDTH_32: /*each bit represents byte, so
0xf-is means 4 bytes-32 bit*/
pri_and_ext_bus_width = BUS_MASK_32BIT;
break;
case MV_DDR_PRI_BUS_WIDTH_64:
--
2.26.2
[PATCH u-boot-marvell 02/18] ddr: marvell: a38x: import header change from upstream
commit a165037ec26f301be75e1fabc263643683e85255 upstream.
The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes header ddr_topology_def.h.
Import this header change to remain consistent with upstream.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr_topology_def.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index 34196b1662..c55e3b57e4 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -148,7 +148,8 @@ enum mv_ddr_validation {
MV_DDR_VAL_DIS,
MV_DDR_VAL_RX,
MV_DDR_VAL_TX,
- MV_DDR_VAL_RX_TX
+ MV_DDR_VAL_RX_TX,
+ MV_DDR_MEMORY_CHECK
};
struct mv_ddr_iface {
--
2.26.2
[PATCH u-boot-marvell 05/18] ddr: marvell: a38x: import header change from upstream
commit 6c705ebc0d70f67ed7cae83ad1978c3305ef25be upstream.
The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes header mv_ddr_topology.h.
Import this header change to remain consistent with upstream.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/mv_ddr_topology.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.h
b/drivers/ddr/marvell/a38x/mv_ddr_topology.h
index 4fca47689f..1cb69ad085 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.h
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.h
@@ -179,7 +179,9 @@ enum mv_ddr_dic_evalue {
/* phy electrical configuration values */
enum mv_ddr_ohm_evalue {
+ MV_DDR_OHM_20 = 20,/*relevant for Synopsys C/A Drive strength only*/
MV_DDR_OHM_30 = 30,
+ MV_DDR_OHM_40 = 40,/*relevant for Synopsys C/A Drive strength only*/
MV_DDR_OHM_48 = 48,
MV_DDR_OHM_60 = 60,
MV_DDR_OHM_80 = 80,
--
2.26.2
[PATCH u-boot-marvell 04/18] ddr: marvell: a38x: add ddr 32bit ECC support
commit 61a8910998d7b553e80f600ebe8147a8b98f0945 upstream.
Required changes made for 32bit ddr support.
An update is made to the topology map, according to
bus_act_mask, set in the dram_port.c
Signed-off-by: Alex Leibovich
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/mv_ddr_spd.c | 5 +
drivers/ddr/marvell/a38x/mv_ddr_spd.h | 1 +
drivers/ddr/marvell/a38x/mv_ddr_topology.c | 6 +-
3 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.c
b/drivers/ddr/marvell/a38x/mv_ddr_spd.c
index 04dbfe94d6..cb90d30a6a 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_spd.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.c
@@ -217,6 +217,11 @@ enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union
mv_ddr_spd_data *spd_
return ret_val;
}
+void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum
mv_ddr_die_capacity capacity)
+{
+ spd_data->byte_fields.byte_4.bit_fields.die_capacity = capacity;
+}
+
unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data)
{
unsigned char mem_mirror =
spd_data->byte_fields.byte_131.bit_fields.rank_1_mapping;
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.h
b/drivers/ddr/marvell/a38x/mv_ddr_spd.h
index b4bfef3103..ee35377af5 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_spd.h
+++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.h
@@ -277,6 +277,7 @@ union mv_ddr_spd_data {
int mv_ddr_spd_timing_calc(union mv_ddr_spd_data *spd_data, unsigned int
timing_data[]);
enum mv_ddr_dev_width mv_ddr_spd_dev_width_get(union mv_ddr_spd_data
*spd_data);
enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union mv_ddr_spd_data
*spd_data);
+void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum
mv_ddr_die_capacity capacity);
unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data);
unsigned char mv_ddr_spd_cs_bit_mask_get(union mv_ddr_spd_data *spd_data);
unsigned char mv_ddr_spd_dev_type_get(union mv_ddr_spd_data *spd_data);
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index f2cd7c0ef3..0cbe8d3d1e 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -74,6 +74,10 @@ int mv_ddr_topology_map_update(void)
/* update device width in topology map */
iface_params->bus_width =
mv_ddr_spd_dev_width_get(&tm->spd_data);
+ /* overwrite SPD configuration, with what the user set */
+ if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK)
+ mv_ddr_spd_die_capacity_user_get(&tm->spd_data,
tm->interface_params[0].memory_size);
+
/* update die capacity in topology map */
iface_params->memory_size =
mv_ddr_spd_die_capacity_get(&tm->spd_data);
@@ -144,7 +148,7 @@ unsigned short mv_ddr_bus_bit_mask_get(void)
unsigned int octets_per_if_num = ddr3_tip_dev_attr_get(0,
MV_ATTR_OCTET_PER_INTERFACE);
if (tm->cfg_src == MV_DDR_CFG_SPD) {
- if (tm->bus_act_mask == BUS_MASK_32BIT)
+ if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK)
tm->spd_data.byte_fields.byte_13.all_bits =
MV_DDR_PRI_BUS_WIDTH_32;
enum mv_ddr_pri_bus_width pri_bus_width =
mv_ddr_spd_pri_bus_width_get(&tm->spd_data);
--
2.26.2
[PATCH u-boot-marvell 06/18] ddr: marvell: a38x: fix 32bit
commit 0b5adedd4ced9b8f528faad1957d4d69e95759ef upstream.
Signed-off-by: motib
Reviewed-by: Alex Leibovich
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/mv_ddr_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index 0cbe8d3d1e..3feb65ea46 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -149,7 +149,7 @@ unsigned short mv_ddr_bus_bit_mask_get(void)
if (tm->cfg_src == MV_DDR_CFG_SPD) {
if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK)
- tm->spd_data.byte_fields.byte_13.all_bits =
MV_DDR_PRI_BUS_WIDTH_32;
+
tm->spd_data.byte_fields.byte_13.bit_fields.primary_bus_width =
MV_DDR_PRI_BUS_WIDTH_32;
enum mv_ddr_pri_bus_width pri_bus_width =
mv_ddr_spd_pri_bus_width_get(&tm->spd_data);
enum mv_ddr_bus_width_ext bus_width_ext =
mv_ddr_spd_bus_width_ext_get(&tm->spd_data);
--
2.26.2
[PATCH u-boot-marvell 09/18] ddr: marvell: a38x: allow board specific ODT configuration
commit 2d3b9437cf38c06c4330e0de07f29476197f5e04 upstream.
The ODT enable heuristic based on active chip-selects is not always
correct. Some board might use two chip-selects, but have only one ODT
line connected. Allow board specific mv_ddr_topology_map to directly set
the ODT configuration register value.
Signed-off-by: Baruch Siach
Reviewed-by: Moti Buskila
Reviewed-by: Nadav Haklai
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr3_init.c| 5 +
drivers/ddr/marvell/a38x/ddr_topology_def.h | 3 +++
2 files changed, 8 insertions(+)
diff --git a/drivers/ddr/marvell/a38x/ddr3_init.c
b/drivers/ddr/marvell/a38x/ddr3_init.c
index a971cc155a..7488770268 100644
--- a/drivers/ddr/marvell/a38x/ddr3_init.c
+++ b/drivers/ddr/marvell/a38x/ddr3_init.c
@@ -104,6 +104,7 @@ int ddr3_init(void)
static int mv_ddr_training_params_set(u8 dev_num)
{
struct tune_train_params params;
+ struct mv_ddr_topology_map *tm = mv_ddr_topology_map_get();
int status;
u32 cs_num;
int ck_delay;
@@ -136,6 +137,10 @@ static int mv_ddr_training_params_set(u8 dev_num)
if (ck_delay > 0)
params.ck_delay = ck_delay;
+ /* Use platform specific override ODT value */
+ if (tm->odt_config)
+ params.g_odt_config = tm->odt_config;
+
status = ddr3_tip_tune_training_params(dev_num, ¶ms);
if (MV_OK != status) {
printf("%s Training Sequence - FAILED\n", ddr_type);
diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index 342c2cf451..3991fec272 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -125,6 +125,9 @@ struct mv_ddr_topology_map {
/* electrical parameters */
unsigned int electrical_data[MV_DDR_EDATA_LAST];
+ /* ODT configuration */
+ u32 odt_config;
+
/* Clock enable mask */
u32 clk_enable;
--
2.26.2
[PATCH u-boot-marvell 08/18] ddr: marvell: a38x: import header change from upstream
commit 3908e20c6c520339e9bddb566823ae5e065d5218 upstream.
The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes header ddr_topology_def.h.
Import this header change to remain consistent with upstream.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr_topology_def.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index c55e3b57e4..342c2cf451 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -152,6 +152,11 @@ enum mv_ddr_validation {
MV_DDR_MEMORY_CHECK
};
+enum mv_ddr_sscg {
+ SSCG_EN,
+ SSCG_DIS,
+};
+
struct mv_ddr_iface {
/* base addr of ap ddr interface belongs to */
unsigned int ap_base;
@@ -180,6 +185,9 @@ struct mv_ddr_iface {
/* ddr interface validation mode */
enum mv_ddr_validation validation;
+ /* ddr interface validation mode */
+ enum mv_ddr_sscg sscg;
+
/* ddr interface topology map */
struct mv_ddr_topology_map tm;
};
--
2.26.2
[PATCH u-boot-marvell 07/18] ddr: marvell: a38x: fix memory size calculation using 32bit bus width
commit ab9240402a70cc02496683971779e75eff410ab4 upstream.
- function mv_ddr_spd_die_capacity_user_get() has a bug,
since it insert a user memory enum to it,
instead of SPD memory enum (which are different)
- fix: remove mv_ddr_spd_die_capacity_user_get() function.
- memory size with 64 and 32 bit already calculated correctly
at mv_ddr_mem_sz_per_cs_get() function
Signed-off-by: motib
Reviewed-by: Stefan Chulski
Reviewed-by: Alex Leibovich
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/mv_ddr_spd.c | 5 -
drivers/ddr/marvell/a38x/mv_ddr_spd.h | 1 -
drivers/ddr/marvell/a38x/mv_ddr_topology.c | 4
3 files changed, 10 deletions(-)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.c
b/drivers/ddr/marvell/a38x/mv_ddr_spd.c
index cb90d30a6a..04dbfe94d6 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_spd.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.c
@@ -217,11 +217,6 @@ enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union
mv_ddr_spd_data *spd_
return ret_val;
}
-void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum
mv_ddr_die_capacity capacity)
-{
- spd_data->byte_fields.byte_4.bit_fields.die_capacity = capacity;
-}
-
unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data)
{
unsigned char mem_mirror =
spd_data->byte_fields.byte_131.bit_fields.rank_1_mapping;
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_spd.h
b/drivers/ddr/marvell/a38x/mv_ddr_spd.h
index ee35377af5..b4bfef3103 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_spd.h
+++ b/drivers/ddr/marvell/a38x/mv_ddr_spd.h
@@ -277,7 +277,6 @@ union mv_ddr_spd_data {
int mv_ddr_spd_timing_calc(union mv_ddr_spd_data *spd_data, unsigned int
timing_data[]);
enum mv_ddr_dev_width mv_ddr_spd_dev_width_get(union mv_ddr_spd_data
*spd_data);
enum mv_ddr_die_capacity mv_ddr_spd_die_capacity_get(union mv_ddr_spd_data
*spd_data);
-void mv_ddr_spd_die_capacity_user_get(union mv_ddr_spd_data *spd_data, enum
mv_ddr_die_capacity capacity);
unsigned char mv_ddr_spd_mem_mirror_get(union mv_ddr_spd_data *spd_data);
unsigned char mv_ddr_spd_cs_bit_mask_get(union mv_ddr_spd_data *spd_data);
unsigned char mv_ddr_spd_dev_type_get(union mv_ddr_spd_data *spd_data);
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index 3feb65ea46..31711fdd49 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -74,10 +74,6 @@ int mv_ddr_topology_map_update(void)
/* update device width in topology map */
iface_params->bus_width =
mv_ddr_spd_dev_width_get(&tm->spd_data);
- /* overwrite SPD configuration, with what the user set */
- if (tm->bus_act_mask == MV_DDR_32BIT_ECC_PUP8_BUS_MASK)
- mv_ddr_spd_die_capacity_user_get(&tm->spd_data,
tm->interface_params[0].memory_size);
-
/* update die capacity in topology map */
iface_params->memory_size =
mv_ddr_spd_die_capacity_get(&tm->spd_data);
--
2.26.2
[PATCH u-boot-marvell 10/18] ddr: marvell: a38x: add 16Gbit memory devices support
commit 994509eb4fe6771d92cd06314c37895098ac48fa upstream.
Signed-off-by: Moti Buskila
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr3_training_ip_def.h | 2 ++
drivers/ddr/marvell/a38x/mv_ddr_topology.c | 3 ++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h
b/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h
index 2a68669f36..8765df7cfb 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h
+++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_def.h
@@ -80,6 +80,8 @@
#define ADDR_SIZE_2GB 0x1000
#define ADDR_SIZE_4GB 0x2000
#define ADDR_SIZE_8GB 0x4000
+#define ADDR_SIZE_16GB 0x8000
+
enum hws_edge_compare {
EDGE_PF,
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
index 31711fdd49..c4c3ab72b2 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_topology.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_topology.c
@@ -248,7 +248,8 @@ static unsigned int mem_size[] = {
ADDR_SIZE_1GB,
ADDR_SIZE_2GB,
ADDR_SIZE_4GB,
- ADDR_SIZE_8GB
+ ADDR_SIZE_8GB,
+ ADDR_SIZE_16GB
/* TODO: add capacity up to 256GB */
};
--
2.26.2
[PATCH u-boot-marvell 13/18] ddr: marvell: a38x: import header change from upstream
commit d653b305d0b3da9727c49124683f1a6d95d5c9a5 upstream.
The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes header ddr_topology_def.h.
Import this header change to remain consistent with upstream.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr_topology_def.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index 461f091472..2cca5676a0 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -52,9 +52,6 @@ struct if_params {
/* The DDR frequency for each interfaces */
enum mv_ddr_freq memory_freq;
-/* ddr twin-die */
- enum mv_ddr_twin_die twin_die_combined;
-
/*
* delay CAS Write Latency
* - 0 for using default value (jedec suggested)
--
2.26.2
[PATCH u-boot-marvell 12/18] ddr: marvell: a38x: disable WL phase correction stage in case of bus_width=16bit
commit 20c89a28548cdab11f88d2ec8936344af0686a1e upstream.
WL phase correcion stage is failing while using bus_width of 16bit, not
to be fix this stage is un-necessary when working with bus_width of 16
bit.
Signed-off-by: Moti Buskila
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr3_training_db.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/ddr/marvell/a38x/ddr3_training_db.c
b/drivers/ddr/marvell/a38x/ddr3_training_db.c
index b2f11a8399..6aa7b6069e 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_db.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_db.c
@@ -833,6 +833,9 @@ u32 pattern_table_get_word(u32 dev_num, enum hws_pattern
type, u8 index)
pattern = pattern_table_get_isi_word16(index);
break;
default:
+ if (((int)type == 29) || ((int)type == 30))
+ break;
+
printf("error: %s: unsupported pattern type [%d]
found\n",
__func__, (int)type);
pattern = 0;
--
2.26.2
[PATCH u-boot-marvell 11/18] ddr: marvell: a38x: add support for twin-die combined memory device
commit 6285efb8a118940877522c4c07bd7c64569b4f5f upstream.
the twin-die combined memory device should be treatened as X8
device and not as X16 one
Signed-off-by: Moti Buskila
Reviewed-by: Kostya Porotchkin
The default value for twin_die_combined is set to NOT_COMBINED for all
boards, as this was default behaviour prior this change.
Signed-off-by: Marek Behún
---
board/CZ.NIC/turris_omnia/turris_omnia.c | 2 ++
board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 1 +
board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 1 +
board/alliedtelesis/x530/x530.c | 1 +
board/gdsys/a38x/controlcenterdc.c| 1 +
board/kobol/helios4/helios4.c | 1 +
board/solidrun/clearfog/clearfog.c| 1 +
drivers/ddr/marvell/a38x/ddr_topology_def.h | 12
drivers/ddr/marvell/a38x/mv_ddr_topology.c| 6 +-
9 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/board/CZ.NIC/turris_omnia/turris_omnia.c
b/board/CZ.NIC/turris_omnia/turris_omnia.c
index 2da878d364..78b125edfe 100644
--- a/board/CZ.NIC/turris_omnia/turris_omnia.c
+++ b/board/CZ.NIC/turris_omnia/turris_omnia.c
@@ -285,6 +285,7 @@ static struct mv_ddr_topology_map board_topology_map_1g = {
MV_DDR_TIM_2T} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
@@ -307,6 +308,7 @@ static struct mv_ddr_topology_map board_topology_map_2g = {
MV_DDR_TIM_2T} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
diff --git a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
index 9cd9ea2c06..acc8a5ec6d 100644
--- a/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
+++ b/board/Marvell/db-88f6820-amc/db-88f6820-amc.c
@@ -72,6 +72,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_DEFAULT} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
diff --git a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
index 2bdd55329d..a1d0104526 100644
--- a/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
+++ b/board/Marvell/db-88f6820-gp/db-88f6820-gp.c
@@ -93,6 +93,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_DEFAULT} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
};
diff --git a/board/alliedtelesis/x530/x530.c b/board/alliedtelesis/x530/x530.c
index c7438aeaf1..6caba24196 100644
--- a/board/alliedtelesis/x530/x530.c
+++ b/board/alliedtelesis/x530/x530.c
@@ -67,6 +67,7 @@ static struct mv_ddr_topology_map board_topology_map = {
MV_DDR_TIM_2T} }, /* timing */
BUS_MASK_32BIT_ECC, /* subphys mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0},/* timing parameters */
{ {0} },/* electrical configuration */
diff --git a/board/gdsys/a38x/controlcenterdc.c
b/board/gdsys/a38x/controlcenterdc.c
index a2287f9deb..66a0d769ce 100644
--- a/board/gdsys/a38x/controlcenterdc.c
+++ b/board/gdsys/a38x/controlcenterdc.c
@@ -70,6 +70,7 @@ static struct mv_ddr_topology_map ddr_topology_map = {
MV_DDR_TIM_DEFAULT} }, /* timing */
BUS_MASK_32BIT, /* Busses mask */
MV_DDR_CFG_DEFAULT, /* ddr configuration data source */
+ NOT_COMBINED, /* ddr twin-die combined */
{ {0} },/* raw spd data */
{0} /* timing parameters */
diff --git a/board/kobol/helios4/helios4.c b/board/kobol/helios4/helios4.c
index 17d2489415..5007194a52 100644
--- a/board/kobol/helios4/helios4.c
[PATCH u-boot-marvell 14/18] ddr: marvell: a38x: fix memory cs size function
commit c8b301463d508c807a33f7b7eaea98bbda4aa35e upstream.
The funtion returnd cs size in byte instead of MB, that cause
calculation error since the caller was expected to get u32 and when he
got above 4G it refers it as 0.
The fix was to get the cs memory size from function as in MB and then
multiply it by 1MB.
Signed-off-by: Moti Buskila
Reviewed-by: Kostya Porotchkin
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/mv_ddr_plat.c | 9 +++--
drivers/ddr/marvell/a38x/xor.c | 6 +++---
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
index 72f0df..0d1df189e8 100644
--- a/drivers/ddr/marvell/a38x/mv_ddr_plat.c
+++ b/drivers/ddr/marvell/a38x/mv_ddr_plat.c
@@ -4,6 +4,7 @@
*/
#include "ddr3_init.h"
+#include "mv_ddr_common.h"
#include "mv_ddr_training_db.h"
#include "mv_ddr_regs.h"
#include "mv_ddr_sys_env_lib.h"
@@ -1016,7 +1017,7 @@ int ddr3_calc_mem_cs_size(u32 cs, uint64_t *cs_size)
return MV_BAD_VALUE;
}
- *cs_size = cs_mem_size << 20; /* write cs size in bytes */
+ *cs_size = cs_mem_size;
return MV_OK;
}
@@ -1025,9 +1026,11 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32
cs_ena)
{
u32 reg, cs;
uint64_t mem_total_size = 0;
+ uint64_t cs_mem_size_mb = 0;
uint64_t cs_mem_size = 0;
uint64_t mem_total_size_c, cs_mem_size_c;
+
#ifdef DEVICE_MAX_DRAM_ADDRESS_SIZE
u32 physical_mem_size;
u32 max_mem_size = DEVICE_MAX_DRAM_ADDRESS_SIZE;
@@ -1038,8 +1041,9 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32
cs_ena)
for (cs = 0; cs < MAX_CS_NUM; cs++) {
if (cs_ena & (1 << cs)) {
/* get CS size */
- if (ddr3_calc_mem_cs_size(cs, &cs_mem_size) != MV_OK)
+ if (ddr3_calc_mem_cs_size(cs, &cs_mem_size_mb) != MV_OK)
return MV_FAIL;
+ cs_mem_size = cs_mem_size_mb * _1M;
#ifdef DEVICE_MAX_DRAM_ADDRESS_SIZE
/*
@@ -1088,6 +1092,7 @@ static int ddr3_fast_path_dynamic_cs_size_config(u32
cs_ena)
*/
mem_total_size_c = (mem_total_size >> 16) &
0x;
cs_mem_size_c = (cs_mem_size >> 16) & 0x;
+
/* if the sum less than 2 G - calculate the value */
if (mem_total_size_c + cs_mem_size_c < 0x1)
mem_total_size += cs_mem_size;
diff --git a/drivers/ddr/marvell/a38x/xor.c b/drivers/ddr/marvell/a38x/xor.c
index 5fb9e216d3..98fb39eaf0 100644
--- a/drivers/ddr/marvell/a38x/xor.c
+++ b/drivers/ddr/marvell/a38x/xor.c
@@ -340,7 +340,7 @@ void ddr3_new_tip_ecc_scrub(void)
{
u32 cs_c, max_cs;
u32 cs_ena = 0;
- uint64_t total_mem_size, cs_mem_size = 0;
+ uint64_t total_mem_size, cs_mem_size_mb = 0, cs_mem_size = 0;
printf("DDR Training Sequence - Start scrubbing\n");
max_cs = mv_ddr_cs_num_get();
@@ -349,9 +349,9 @@ void ddr3_new_tip_ecc_scrub(void)
#if defined(CONFIG_ARMADA_38X) || defined(CONFIG_ARMADA_39X)
/* all chip-selects are of same size */
- ddr3_calc_mem_cs_size(0, &cs_mem_size);
+ ddr3_calc_mem_cs_size(0, &cs_mem_size_mb);
#endif
-
+ cs_mem_size = cs_mem_size_mb * _1M;
mv_sys_xor_init(max_cs, cs_ena, cs_mem_size, 0);
total_mem_size = max_cs * cs_mem_size;
mv_xor_mem_init(0, 0, total_mem_size, 0xdeadbeef, 0xdeadbeef);
--
2.26.2
[PATCH u-boot-marvell 15/18] ddr: marvell: a38x: import code change from upstream
commit 2bdd12dd68b1f8e27a03a3443ae49a09a14c18e4 upstream.
The commit mentioned above changes non-DDR3 stuff in upstream, but it
also changes code in ddr3_training.c.
Import this change to remain consistent with upstream.
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr3_training.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/ddr/marvell/a38x/ddr3_training.c
b/drivers/ddr/marvell/a38x/ddr3_training.c
index 34cc170910..0358f6287a 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training.c
@@ -143,6 +143,7 @@ static struct reg_data odpg_default_value[] = {
{0x15a4, 0x0, MASK_ALL_BITS},
{0x15a8, 0x0, MASK_ALL_BITS},
{0x15ac, 0x0, MASK_ALL_BITS},
+ {0x1600, 0x0, MASK_ALL_BITS},
{0x1604, 0x0, MASK_ALL_BITS},
{0x1608, 0x0, MASK_ALL_BITS},
{0x160c, 0x0, MASK_ALL_BITS},
@@ -1569,6 +1570,8 @@ int ddr3_tip_freq_set(u32 dev_num, enum hws_access_type
access_type,
val = ((cl_mask_table[cl_value] & 0x1) << 2) |
((cl_mask_table[cl_value] & 0xe) << 3);
+ cs_mask[0] = 0xc;
+
CHECK_STATUS(ddr3_tip_write_mrs_cmd(dev_num, cs_mask, MR_CMD0,
val, (0x7 << 4) | (0x1 << 2)));
--
2.26.2
[PATCH u-boot-marvell 18/18] ddr: marvell: a38x: fix comment in conditional macro
The code was processed with unifdef utility to omit portions not relevant to A38x and DDR3. This removes usage of many macros, including A70X0, A80X0 and A3900. It seems that the unifdef utility did not remove the macros from #else comment. Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/ddr3_training.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ddr/marvell/a38x/ddr3_training.c b/drivers/ddr/marvell/a38x/ddr3_training.c index 0358f6287a..2b3af23202 100644 --- a/drivers/ddr/marvell/a38x/ddr3_training.c +++ b/drivers/ddr/marvell/a38x/ddr3_training.c @@ -219,7 +219,7 @@ static int ddr3_tip_pad_inv(void) DDR_PHY_CONTROL, PHY_CTRL_PHY_REG, data, data); -#else /* !CONFIG_ARMADA_38X && !CONFIG_ARMADA_39X && !A70X0 && !A80X0 && !A3900 */ +#else /* !CONFIG_ARMADA_38X && !CONFIG_ARMADA_39X */ #pragma message "unknown platform to configure ddr clock swap" #endif } -- 2.26.2
[PATCH u-boot-marvell 17/18] ddr: marvell: a38x: bump version to 14.0.0
Bump version of a38x DDR3 trianing to version 14.0.0 to reflect the version in the mv-ddr-devel branch of upstream repository https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git. There is a new version numbering system, where after 18.12.0 came 1.0.0, 2.0.0, and so on until 14.0.0. So 14.0.0 is newer than 18.12.0. Signed-off-by: Marek Behún --- drivers/ddr/marvell/a38x/mv_ddr_build_message.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/ddr/marvell/a38x/mv_ddr_build_message.c b/drivers/ddr/marvell/a38x/mv_ddr_build_message.c index cc6234fd40..a2bb8a96a6 100644 --- a/drivers/ddr/marvell/a38x/mv_ddr_build_message.c +++ b/drivers/ddr/marvell/a38x/mv_ddr_build_message.c @@ -1,3 +1,3 @@ // SPDX-License-Identifier: GPL-2.0 const char mv_ddr_build_message[] = ""; -const char mv_ddr_version_string[] = "mv_ddr: mv_ddr-armada-18.09.2"; +const char mv_ddr_version_string[] = "mv_ddr: 14.0.0"; -- 2.26.2
[PATCH u-boot-marvell 16/18] ddr: marvell: a38x: enum mv_ddr_twin_die: change order
commit 56db5d1464b44df10a02b99e615ebd6f6a35c428 upstream.
@pali suggested this change
In commit 6285efb ("mv_ddr: add support for twin-die combined memory
device") was added support for twin-die combined memory device and
default value for explicitly uninitialized structure members is zero, s
also twin_die_combined is initialized to zero. Which means COMBINED
value.
As prior this commit there was no support for twin-die combined memory
device, default value for twin_die_combined should be NOT_COMBINED. This
change change order of enum mv_ddr_twin_die to ensure that NOT_COMBINED
has value zero.
Signed-off-by: heaterC
Signed-off-by: Marek Behún
---
drivers/ddr/marvell/a38x/ddr_topology_def.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/ddr/marvell/a38x/ddr_topology_def.h
b/drivers/ddr/marvell/a38x/ddr_topology_def.h
index 2cca5676a0..7f2317edfa 100644
--- a/drivers/ddr/marvell/a38x/ddr_topology_def.h
+++ b/drivers/ddr/marvell/a38x/ddr_topology_def.h
@@ -15,8 +15,8 @@
#define MV_DDR_MAX_IFACE_NUM 1
enum mv_ddr_twin_die {
- COMBINED,
NOT_COMBINED,
+ COMBINED,
};
struct bus_params {
--
2.26.2
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
btw tested on Turris Omnia
[PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
From: motib
In each pattern cycle the bus state can be changed.
In order to avoid it, we need to switch back to the same bus state on
each pattern cycle.
Signed-off-by: motib
Fixed code style, removed commented code, switched to use DEBUG macros
instead of printf.
Signed-off-by: Marek Behún
---
.../a38x/ddr3_training_centralization.c | 25 +++
.../marvell/a38x/ddr3_training_ip_engine.c| 8 --
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
index 648b37ef6f..a92760681e 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_centralization.c
@@ -24,6 +24,8 @@ u8
bus_start_window[NUM_OF_CENTRAL_TYPES][MAX_INTERFACE_NUM][MAX_BUS_NUM];
u8 centralization_state[MAX_INTERFACE_NUM][MAX_BUS_NUM];
static u8 ddr3_tip_special_rx_run_once_flag;
+extern u8 byte_status[MAX_INTERFACE_NUM][MAX_BUS_NUM];
+
static int ddr3_tip_centralization(u32 dev_num, u32 mode);
/*
@@ -110,6 +112,7 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode)
(max_win_size - 1) + cons_tap;
bus_start_window[mode][if_id][bus_id] = 0;
centralization_result[if_id][bus_id] = 0;
+ byte_status[if_id][bus_id] = BYTE_NOT_DEFINED;
}
}
@@ -166,6 +169,12 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode)
result[search_dir_id][7]));
}
+ DEBUG_CENTRALIZATION_ENGINE
+ (DEBUG_LEVEL_TRACE,
+("byte_status[%d][%d] = 0x%x\n",
+if_id,
+bus_id,
+byte_status[if_id][bus_id]));
for (bit_id = 0; bit_id < BUS_WIDTH_IN_BITS;
bit_id++) {
/* check if this code is valid for 2
edge, probably not :( */
@@ -174,11 +183,27 @@ static int ddr3_tip_centralization(u32 dev_num, u32 mode)
[HWS_LOW2HIGH]
[bit_id],
EDGE_1);
+ if ((byte_status[if_id][bus_id] &
BYTE_SPLIT_OUT_MIX) ||
+ (byte_status[if_id][bus_id] &
BYTE_HOMOGENEOUS_SPLIT_OUT)) {
+ if (cur_start_win[bit_id] >= 64)
+ cur_start_win[bit_id]
-= 64;
+ else
+ cur_start_win[bit_id] =
0;
+ DEBUG_CENTRALIZATION_ENGINE
+ (DEBUG_LEVEL_TRACE,
+
("--\n"));
+ }
cur_end_win[bit_id] =
GET_TAP_RESULT(result
[HWS_HIGH2LOW]
[bit_id],
EDGE_1);
+ if (cur_end_win[bit_id] >= 64 &&
(byte_status[if_id][bus_id] & BYTE_SPLIT_OUT_MIX)) {
+ cur_end_win[bit_id] -= 64;
+ DEBUG_CENTRALIZATION_ENGINE
+ (DEBUG_LEVEL_TRACE,
+
("++\n"));
+ }
/* window length */
current_window[bit_id] =
cur_end_win[bit_id] -
diff --git a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
index 5fd9a052fa..3d1fa1e74e 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_ip_engine.c
@@ -1174,7 +1174,6 @@ int ddr3_tip_ip_training_wrapper(u32 dev_num, enum
hws_access_type access_type,
/* zero the data base */
bit_bit_mask[sybphy_id] = 0;
- byte_status[if_id][sybphy_id] = BYTE_NOT_DEFINED;
for (bit_id = 0; bit_id < bit_en
Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
This patch is needed on some Turris Omnia boards with Samsung DDR chips, otherwise DDR training fails in ~60% of cases. Marvell send us this patch for testing, I have updated it a little. Please test this on other A38x boards. If it doesn't break anything on other boards, we can apply it and send it to mv-ddr-marvell upstream. Marek
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
Hi Marek, On 9/02/21 7:34 am, Marek Behún wrote: > This syncs drivers/ddr/marvell/a38x/ with the mv-ddr-devel branch > of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git. > > There are some commits regarding DDR3 on top of version 14.0.0 in the > mv-ddr-marvell repository (from Chris Packham), but these changes > already are in U-Boot. Do you have this in a repo I can pull from? I've got a couple of boards I can give this a spin on. > Marek > > Marek Behún (18): >ddr: marvell: a38x: fix write leveling suplementary algo >ddr: marvell: a38x: import header change from upstream >ddr: marvell: a38x: add ddr32 support >ddr: marvell: a38x: add ddr 32bit ECC support >ddr: marvell: a38x: import header change from upstream >ddr: marvell: a38x: fix 32bit >ddr: marvell: a38x: fix memory size calculation using 32bit bus width >ddr: marvell: a38x: import header change from upstream >ddr: marvell: a38x: allow board specific ODT configuration >ddr: marvell: a38x: add 16Gbit memory devices support >ddr: marvell: a38x: add support for twin-die combined memory device >ddr: marvell: a38x: disable WL phase correction stage in case of > bus_width=16bit >ddr: marvell: a38x: import header change from upstream >ddr: marvell: a38x: fix memory cs size function >ddr: marvell: a38x: import code change from upstream >ddr: marvell: a38x: enum mv_ddr_twin_die: change order >ddr: marvell: a38x: bump version to 14.0.0 >ddr: marvell: a38x: fix comment in conditional macro > > board/CZ.NIC/turris_omnia/turris_omnia.c | 2 ++ > board/Marvell/db-88f6820-amc/db-88f6820-amc.c | 1 + > board/Marvell/db-88f6820-gp/db-88f6820-gp.c | 1 + > board/alliedtelesis/x530/x530.c | 1 + > board/gdsys/a38x/controlcenterdc.c| 1 + > board/kobol/helios4/helios4.c | 1 + > board/solidrun/clearfog/clearfog.c| 1 + > drivers/ddr/marvell/a38x/ddr3_init.c | 5 > drivers/ddr/marvell/a38x/ddr3_training.c | 5 +++- > drivers/ddr/marvell/a38x/ddr3_training_db.c | 3 +++ > .../ddr/marvell/a38x/ddr3_training_ip_def.h | 2 ++ > .../marvell/a38x/ddr3_training_ip_engine.c| 5 +++- > drivers/ddr/marvell/a38x/ddr_topology_def.h | 23 ++- > .../ddr/marvell/a38x/mv_ddr_build_message.c | 2 +- > drivers/ddr/marvell/a38x/mv_ddr_plat.c| 9 ++-- > drivers/ddr/marvell/a38x/mv_ddr_topology.c| 14 --- > drivers/ddr/marvell/a38x/mv_ddr_topology.h| 2 ++ > drivers/ddr/marvell/a38x/xor.c| 6 ++--- > 18 files changed, 72 insertions(+), 12 deletions(-) >
Re: [PATCH u-boot-marvell] PLEASE TEST ddr: marvell: a38x: fix SPLIT_OUT_MIX state decision
On 9/02/21 8:15 am, Marek Behun wrote: > This patch is needed on some Turris Omnia boards with Samsung DDR chips, > otherwise DDR training fails in ~60% of cases. > > Marvell send us this patch for testing, I have updated it a little. > > Please test this on other A38x boards. > > If it doesn't break anything on other boards, we can apply it and send > it to mv-ddr-marvell upstream. They gave us the same patch. I was hoping their SoC team would get it into mv-ddr-marvell (or even their vendor USP) but obviously they're still sitting on it. I know it improved matters for some of our boards but it didn't totally fix them we still had yield problems when we ramped up production.
Re: [PATCH u-boot-marvell 00/18] Upgrade A38x DDR3 training to version 14.0.0
On Mon, 8 Feb 2021 20:11:06 + Chris Packham wrote: > Hi Marek, > > Do you have this in a repo I can pull from? I've got a couple of boards > I can give this a spin on. https://gitlab.nic.cz/turris/turris-omnia-uboot/ branch v2021.04-rc-mv-ddr-14.0.0 also please test branch v2021.04-rc-mv-ddr-14.0.0-samsung-ddr-fix, that one contains one more commit that is needed for Omnia with Samsung DDR chips. Marek
Re: [PATCH 2/3] cmd: SCP03: enable and provision command
On 08/02/21, Simon Glass wrote: > Hi Jorge, > > On Sun, 7 Feb 2021 at 11:11, Jorge Ramirez-Ortiz, Foundries > wrote: > > > > On 07/02/21, Simon Glass wrote: > > > Hi Jorge, > > > > > > On Sat, 6 Feb 2021 at 16:05, Jorge Ramirez-Ortiz > > > wrote: > > > > > > > > Enable and provision the SCP03 keys on a TEE controlled secured elemt > > > > from the U-Boot shell. > > > > > > > > Signed-off-by: Jorge Ramirez-Ortiz > > > > --- > > > > cmd/Kconfig | 9 > > > > cmd/Makefile | 3 +++ > > > > cmd/scp03.c | 64 > > > > 3 files changed, 76 insertions(+) > > > > create mode 100644 cmd/scp03.c > > > > > > Can we have a test for this please? See mem_search.c for an example. > > > > you mean other than what I posted already (the sandbox test using the > > TEE emulator)? > > > > I am not really sure what else can it do: this command sends a request > > to a TEE and waits to a response (and both are emulated on the sandbox). > > It should just be a few lines of code to test the basics. E.g.: > > https://github.com/u-boot/u-boot/blob/3936fd998668846f77468d8f6a662e906920969c/test/cmd/test_echo.c#L42 ah ok I see what you mean. I'll have a look > > Regards, > Simon
