[PATCH 0/2] max313xx RTC driver
This series is based on the in-flight linux patch that is adding support for this family of RTCs to linux[1]. The u-boot driver is a bit different due to some of the differences between Linux and u-boot and I've dropped the support for hwmon and clock source functions. Where possible I've tried to keep things such that the U-Boot and Linux versions can be compared and kept in sync. [1] - https://lore.kernel.org/all/20221108122254.1185-2-ibrahim.ti...@analog.com/ Chris Packham (2): include: kernel.h: port find_closest() from Linux drivers: rtc: add max313xx series rtc driver drivers/rtc/Kconfig| 8 + drivers/rtc/Makefile | 1 + drivers/rtc/max313xx.c | 442 + include/linux/kernel.h | 24 +++ 4 files changed, 475 insertions(+) create mode 100644 drivers/rtc/max313xx.c -- 2.40.0
[PATCH 1/2] include: kernel.h: port find_closest() from Linux
The find_closest() macro can be used to find an element in a sorted
array that is closest to an input value.
Signed-off-by: Chris Packham
---
include/linux/kernel.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3e71d61074b6..5cd6c9dc8219 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -284,4 +284,28 @@
offsetof(struct structure, member) == (offset), \
"`struct " #structure "` offset for `" #member "` is not " #offset)
+#define __find_closest(x, a, as, op) \
+({ \
+ typeof(as) __fc_i, __fc_as = (as) - 1; \
+ typeof(x) __fc_x = (x); \
+ typeof(*a) const *__fc_a = (a); \
+ for (__fc_i = 0; __fc_i < __fc_as; __fc_i++) { \
+ if (__fc_x op DIV_ROUND_CLOSEST(__fc_a[__fc_i] +\
+ __fc_a[__fc_i + 1], 2)) \
+ break; \
+ } \
+ (__fc_i); \
+})
+
+/**
+ * find_closest - locate the closest element in a sorted array
+ * @x: The reference value.
+ * @a: The array in which to look for the closest element. Must be sorted
+ * in ascending order.
+ * @as: Size of 'a'.
+ *
+ * Returns the index of the element closest to 'x'.
+ */
+#define find_closest(x, a, as) __find_closest(x, a, as, <=)
+
#endif
--
2.40.0
[PATCH 2/2] drivers: rtc: add max313xx series rtc driver
Adding support for Analog Devices MAX313XX series RTCs.
This is ported from the Linux driver and adapted for use in u-boot.
Notable differences are
- handling of tm_year and tm_mon differ
- clock source support is omitted
- hwmon support for the MAX31328 and MAX31343 is omitted
- rtc_ops->reset is added
Signed-off-by: Chris Packham
---
drivers/rtc/Kconfig| 8 +
drivers/rtc/Makefile | 1 +
drivers/rtc/max313xx.c | 442 +
3 files changed, 451 insertions(+)
create mode 100644 drivers/rtc/max313xx.c
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 35b6ed4d7c72..49c260b5b190 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -134,6 +134,14 @@ config RTC_ISL1208
This driver supports reading and writing the RTC/calendar and detects
total power failures.
+config RTC_MAX313XX
+ bool "Analog Devices MAX313XX RTC driver"
+ depends on DM_RTC
+ depends on DM_I2C
+ help
+ If you say yes here you will get support for the
+ Analog Devices MAX313XX series RTC family.
+
config RTC_PCF8563
tristate "Philips PCF8563"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 447551e15aa2..adfa23f66702 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_RTC_HT1380) += ht1380.o
obj-$(CONFIG_SANDBOX) += i2c_rtc_emul.o
obj-$(CONFIG_RTC_ISL1208) += isl1208.o
obj-$(CONFIG_RTC_M41T62) += m41t62.o
+obj-$(CONFIG_RTC_MAX313XX) += max313xx.o
obj-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
obj-$(CONFIG_RTC_MC146818) += mc146818.o
obj-$(CONFIG_MCFRTC) += mcfrtc.o
diff --git a/drivers/rtc/max313xx.c b/drivers/rtc/max313xx.c
new file mode 100644
index ..1aa430d121ee
--- /dev/null
+++ b/drivers/rtc/max313xx.c
@@ -0,0 +1,442 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Analog Devices MAX313XX series I2C RTC driver
+ *
+ * Copyright 2022 Analog Devices Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* common registers */
+#define MAX313XX_INT_ALARM1BIT(0)
+#define MAX313XX_INT_ALARM2BIT(1)
+#define MAX313XX_HRS_F_12_24 BIT(6)
+#define MAX313XX_HRS_F_AM_PM BIT(5)
+#define MAX313XX_MONTH_CENTURY BIT(7)
+
+#define MAX313XX_TMR_CFG_ENABLEBIT(4)
+#define MAX313XX_TMR_CFG_FREQ_MASK GENMASK(1, 0)
+#define MAX313XX_TMR_CFG_FREQ_16HZ 0x03
+
+#define MAX313XX_REG_MINUTE0x01
+#define MAX313XX_REG_HOUR 0x02
+
+#define MAX313XX_TIME_SIZE 0x07
+
+/* device specific registers */
+#define MAX3134X_CFG2_REG 0x01
+#define MAX3134X_CFG2_SET_RTC BIT(1)
+
+#define MAX31341_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31341_TRICKLE_DIODE_EN BIT(2)
+#define MAX31341_TRICKLE_ENABLE_BITBIT(3)
+#define MAX31341_POWER_MGMT_REG0x56
+#define MAX31341_POWER_MGMT_TRICKLE_BITBIT(0)
+
+#define MAX3133X_TRICKLE_RES_MASK GENMASK(2, 1)
+#define MAX3133X_TRICKLE_DIODE_EN BIT(3)
+#define MAX3133X_TRICKLE_ENABLE_BITBIT(0)
+
+#define MAX31329_TRICKLE_ENABLE_BITBIT(7)
+#define MAX31343_TRICKLE_ENABLE_MASK GENMASK(7, 4)
+#define MAX31343_TRICKLE_ENABLE_CODE 5
+#define MAX31329_43_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31329_43_TRICKLE_DIODE_EN BIT(2)
+
+#define MAX31329_CONFIG2_REG 0x04
+#define MAX31329_CONFIG2_CLKIN_EN BIT(2)
+#define MAX31329_CONFIG2_CLKIN_FREQGENMASK(1, 0)
+
+#define MAX31341_42_CONFIG1_REG0x00
+#define MAX31341_42_CONFIG1_CLKIN_EN BIT(7)
+#define MAX31341_42_CONFIG1_CLKIN_FREQ GENMASK(5, 4)
+#define MAX31341_42_CONFIG1_OSC_DISABLEBIT(3)
+#define MAX31341_42_CONFIG1_SWRST BIT(0)
+
+enum max313xx_ids {
+ ID_MAX31328,
+ ID_MAX31329,
+ ID_MAX31331,
+ ID_MAX31334,
+ ID_MAX31341,
+ ID_MAX31342,
+ ID_MAX31343,
+ MAX313XX_ID_NR
+};
+
+struct chip_desc {
+ struct clkout_cfg *clkout;
+ const char *clkout_name;
+ u8 sec_reg;
+ u8 alarm1_sec_reg;
+
+ u8 int_en_reg;
+ u8 int_status_reg;
+
+ u8 ram_reg;
+ u8 ram_size;
+
+ u8 temp_reg;
+
+ u8 trickle_reg;
+
+ u8 rst_reg;
+ u8 rst_bit;
+};
+
+struct max313xx {
+ enum max313xx_ids id;
+ const struct chip_desc *chip;
+};
+
+static const struct chip_desc chip[MAX313XX_ID_NR] = {
+ [ID_MAX31328] = {
+ .int_en_reg = 0x0E,
+ .int_status_reg = 0x0F,
+ .sec_reg = 0x00,
+ .alarm1_sec_reg = 0x07,
+ },
+ [ID_MAX31329] = {
+ .int_en_reg = 0x01,
+ .int_status_reg = 0x00,
+ .sec_reg = 0x06,
+ .alarm1_sec_reg = 0x0D,
+ .ram_reg = 0x22,
+ .ram_size = 64,
+ .trickle_reg = 0x19,
+
[PATCH v2 0/2] max313xx RTC driver
This series is based on the in-flight linux patch that is adding support for this family of RTCs to linux[1]. The u-boot driver is a bit different due to some of the differences between Linux and u-boot and I've dropped the support for hwmon and clock source functions. Where possible I've tried to keep things such that the U-Boot and Linux versions can be compared and kept in sync. For reference the datasheets are all available at https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31328.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31329.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31331.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31334.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31341B-MAX31341C.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31342.pdf https://www.analog.com/media/en/technical-documentation/data-sheets/MAX31343.pdf [1] - https://lore.kernel.org/all/20221108122254.1185-2-ibrahim.ti...@analog.com/ Changes in v2: - Add note on which Linux version this came from - Collect review from Simon - Enable in sandbox for compile testing - Note feature omissions in Kconfig - Incorporate review comments from Simon - Collect r-by from Simon Chris Packham (2): include: kernel.h: port find_closest() from Linux drivers: rtc: add max313xx series rtc driver configs/sandbox_defconfig | 1 + drivers/rtc/Kconfig | 13 ++ drivers/rtc/Makefile | 1 + drivers/rtc/max313xx.c| 459 ++ include/linux/kernel.h| 24 ++ 5 files changed, 498 insertions(+) create mode 100644 drivers/rtc/max313xx.c -- 2.40.0
[PATCH v2 1/2] include: kernel.h: port find_closest() from Linux
The find_closest() macro can be used to find an element in a sorted
array that is closest to an input value. Bring in this macro from
Linux v6.3-rc1-2-g8ca09d5fa354.
Signed-off-by: Chris Packham
Reviewed-by: Simon Glass
---
Changes in v2:
- Add note on which Linux version this came from
- Collect review from Simon
include/linux/kernel.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 3e71d61074b6..5cd6c9dc8219 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -284,4 +284,28 @@
offsetof(struct structure, member) == (offset), \
"`struct " #structure "` offset for `" #member "` is not " #offset)
+#define __find_closest(x, a, as, op) \
+({ \
+ typeof(as) __fc_i, __fc_as = (as) - 1; \
+ typeof(x) __fc_x = (x); \
+ typeof(*a) const *__fc_a = (a); \
+ for (__fc_i = 0; __fc_i < __fc_as; __fc_i++) { \
+ if (__fc_x op DIV_ROUND_CLOSEST(__fc_a[__fc_i] +\
+ __fc_a[__fc_i + 1], 2)) \
+ break; \
+ } \
+ (__fc_i); \
+})
+
+/**
+ * find_closest - locate the closest element in a sorted array
+ * @x: The reference value.
+ * @a: The array in which to look for the closest element. Must be sorted
+ * in ascending order.
+ * @as: Size of 'a'.
+ *
+ * Returns the index of the element closest to 'x'.
+ */
+#define find_closest(x, a, as) __find_closest(x, a, as, <=)
+
#endif
--
2.40.0
[PATCH v2 2/2] drivers: rtc: add max313xx series rtc driver
Adding support for Analog Devices MAX313XX series RTCs.
This is ported from the Linux driver and adapted for use in u-boot.
Notable differences are
- handling of tm_year and tm_mon differ
- clock source support is omitted
- hwmon support for the MAX31328 and MAX31343 is omitted
- rtc_ops->reset is added
Signed-off-by: Chris Packham
Reviewed-by: Simon Glass
---
Changes in v2:
- Enable in sandbox for compile testing
- Note feature omissions in Kconfig
- Incorporate review comments from Simon
- Collect r-by from Simon
configs/sandbox_defconfig | 1 +
drivers/rtc/Kconfig | 13 ++
drivers/rtc/Makefile | 1 +
drivers/rtc/max313xx.c| 459 ++
4 files changed, 474 insertions(+)
create mode 100644 drivers/rtc/max313xx.c
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 77ade1f1d873..0c898df44672 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -267,6 +267,7 @@ CONFIG_SANDBOX_RESET=y
CONFIG_RESET_SYSCON=y
CONFIG_RESET_SCMI=y
CONFIG_DM_RTC=y
+CONFIG_RTC_MAX313XX=y
CONFIG_RTC_RV8803=y
CONFIG_RTC_HT1380=y
CONFIG_SCSI=y
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 35b6ed4d7c72..aae2ae61ba36 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -134,6 +134,19 @@ config RTC_ISL1208
This driver supports reading and writing the RTC/calendar and detects
total power failures.
+config RTC_MAX313XX
+ bool "Analog Devices MAX313XX RTC driver"
+ depends on DM_RTC
+ depends on DM_I2C
+ help
+ If you say yes here you will get support for the
+ Analog Devices MAX313XX series RTC family.
+
+ Chip features not currently supported:
+ - Timestamp registers as SRAM
+ - Temperature sensor
+ - CLKOUT generation
+
config RTC_PCF8563
tristate "Philips PCF8563"
help
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 447551e15aa2..adfa23f66702 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_RTC_HT1380) += ht1380.o
obj-$(CONFIG_SANDBOX) += i2c_rtc_emul.o
obj-$(CONFIG_RTC_ISL1208) += isl1208.o
obj-$(CONFIG_RTC_M41T62) += m41t62.o
+obj-$(CONFIG_RTC_MAX313XX) += max313xx.o
obj-$(CONFIG_RTC_MC13XXX) += mc13xxx-rtc.o
obj-$(CONFIG_RTC_MC146818) += mc146818.o
obj-$(CONFIG_MCFRTC) += mcfrtc.o
diff --git a/drivers/rtc/max313xx.c b/drivers/rtc/max313xx.c
new file mode 100644
index ..748f3c42c30e
--- /dev/null
+++ b/drivers/rtc/max313xx.c
@@ -0,0 +1,459 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Analog Devices MAX313XX series I2C RTC driver
+ *
+ * Copyright 2022 Analog Devices Inc.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* common registers */
+#define MAX313XX_INT_ALARM1BIT(0)
+#define MAX313XX_INT_ALARM2BIT(1)
+#define MAX313XX_HRS_F_12_24 BIT(6)
+#define MAX313XX_HRS_F_AM_PM BIT(5)
+#define MAX313XX_MONTH_CENTURY BIT(7)
+
+#define MAX313XX_TMR_CFG_ENABLEBIT(4)
+#define MAX313XX_TMR_CFG_FREQ_MASK GENMASK(1, 0)
+#define MAX313XX_TMR_CFG_FREQ_16HZ 0x03
+
+#define MAX313XX_REG_MINUTE0x01
+#define MAX313XX_REG_HOUR 0x02
+
+#define MAX313XX_TIME_SIZE 0x07
+
+/* device specific registers */
+#define MAX3134X_CFG2_REG 0x01
+#define MAX3134X_CFG2_SET_RTC BIT(1)
+
+#define MAX31341_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31341_TRICKLE_DIODE_EN BIT(2)
+#define MAX31341_TRICKLE_ENABLE_BITBIT(3)
+#define MAX31341_POWER_MGMT_REG0x56
+#define MAX31341_POWER_MGMT_TRICKLE_BITBIT(0)
+
+#define MAX3133X_TRICKLE_RES_MASK GENMASK(2, 1)
+#define MAX3133X_TRICKLE_DIODE_EN BIT(3)
+#define MAX3133X_TRICKLE_ENABLE_BITBIT(0)
+
+#define MAX31329_TRICKLE_ENABLE_BITBIT(7)
+#define MAX31343_TRICKLE_ENABLE_MASK GENMASK(7, 4)
+#define MAX31343_TRICKLE_ENABLE_CODE 5
+#define MAX31329_43_TRICKLE_RES_MASK GENMASK(1, 0)
+#define MAX31329_43_TRICKLE_DIODE_EN BIT(2)
+
+#define MAX31329_CONFIG2_REG 0x04
+#define MAX31329_CONFIG2_CLKIN_EN BIT(2)
+#define MAX31329_CONFIG2_CLKIN_FREQGENMASK(1, 0)
+
+#define MAX31341_42_CONFIG1_REG0x00
+#define MAX31341_42_CONFIG1_CLKIN_EN BIT(7)
+#define MAX31341_42_CONFIG1_CLKIN_FREQ GENMASK(5, 4)
+#define MAX31341_42_CONFIG1_OSC_DISABLEBIT(3)
+#define MAX31341_42_CONFIG1_SWRST BIT(0)
+
+enum max313xx_ids {
+ ID_MAX31328,
+ ID_MAX31329,
+ ID_MAX31331,
+ ID_MAX31334,
+ ID_MAX31341,
+ ID_MAX31342,
+ ID_MAX31343,
+ MAX313XX_ID_NR
+};
+
+/**
+ * struct chip_desc - descriptor for MAX313xx variants
+ * @sec_reg: Offset to seconds register. Used to denote the start of the
+ * current time registers.
+ * @alarm1_sec_reg: Offset to Alarm1 seconds regis
Current way of using pinctrl-mvebu
Hi, I'm looking to upstream support for a new board with the Marvell AC5X SoC and some NAND driver changes to support the SoC/board. I've got things working when chain loading vendor based u-boot -> upstream u-boot but when I boot directly the NAND controller reports "pxa3xx-nand nand-controller@805b: Ready timeout!!!". I think this is because the multi purpose pins are not in NAND/DEV mode. When chainloading the vendor u-boot has already done this so the driver works. I notice that pinctrl-mvebu.c just expects a single fixed pin-func property the covers all the functions required. How is the probe for this supposed to be configured? Thanks, Chris
Re: Current way of using pinctrl-mvebu
Answering my own question (I think) On Mon, Jul 3, 2023 at 12:10 PM Chris Packham wrote: > > Hi, > > I'm looking to upstream support for a new board with the Marvell AC5X > SoC and some NAND driver changes to support the SoC/board. I've got > things working when chain loading vendor based u-boot -> upstream > u-boot but when I boot directly the NAND controller reports > "pxa3xx-nand nand-controller@805b: Ready timeout!!!". > > I think this is because the multi purpose pins are not in NAND/DEV > mode. When chainloading the vendor u-boot has already done this so the > driver works. > > I notice that pinctrl-mvebu.c just expects a single fixed pin-func > property the covers all the functions required. How is the probe for > this supposed to be configured? If I define the proper pinconf subnodes and associate them with the device then the pinmux does get probed. I still need to define a pin-func property otherwise mvebu_pinctl_probe()/mvebu_pinctrl_set_state_all() will fail with -EINVAL. > > Thanks, > Chris
[PATCH 0/6] Support for AC5X NAND and AT-x240 board
This series adds support for the NAND flash controller on the AC5X SoC and adds support for the Allied Telesis x240 board. I've also included 2 unrelated changes. "arm: mvebu: Remove unused alias from RC AC5X dts" removes an unused alias from the dts. This was in the neighborhood of the x240 so I included it. "mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K" allows using the NFC and device bus at the same time. This is needed for another board (CN9130 based) that I'll hopefully get upstream in the near future. I figured I'd include it now since I was touching the NAND driver. Chris Packham (6): arm: mvebu: ac5: Add nand-controller node arm: mvebu: ac5: Define mvebu_get_nand_clock() mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K arm: mvebu: Add Allied Telesis x240 board arm: mvebu: Remove unused alias from RC AC5X dts arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 9 ++ arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 + arch/arm/dts/ac5-98dx35xx-rd.dts | 1 - arch/arm/mach-mvebu/Kconfig| 7 + arch/arm/mach-mvebu/alleycat5/soc.c| 6 + board/alliedtelesis/x240/MAINTAINERS | 7 + board/alliedtelesis/x240/Makefile | 6 + board/alliedtelesis/x240/x240.c| 13 ++ configs/x240_defconfig | 87 ++ drivers/mtd/nand/raw/pxa3xx_nand.c | 20 ++- include/configs/x240.h | 37 + 12 files changed, 402 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts create mode 100644 board/alliedtelesis/x240/MAINTAINERS create mode 100644 board/alliedtelesis/x240/Makefile create mode 100644 board/alliedtelesis/x240/x240.c create mode 100644 configs/x240_defconfig create mode 100644 include/configs/x240.h -- 2.41.0
[PATCH 2/6] arm: mvebu: ac5: Define mvebu_get_nand_clock()
The NF_CLK for the AC5 SoC runs at 400MHz. There's no strapping
or gating require so just add a mvebu_get_nand_clock() that
returns this value.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/soc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
b/arch/arm/mach-mvebu/alleycat5/soc.c
index dc69f46eedb2..734b0a87dd49 100644
--- a/arch/arm/mach-mvebu/alleycat5/soc.c
+++ b/arch/arm/mach-mvebu/alleycat5/soc.c
@@ -255,6 +255,12 @@ void soc_print_clock_info(void)
printf("\tMSS %4d MHz\n", 200);
}
+/* Return NAND clock in Hz */
+u32 mvebu_get_nand_clock(void)
+{
+ return 400 * 100;
+}
+
/*
* Override of __weak int mach_cpu_init(void) :
* SoC/machine dependent CPU setup
--
2.41.0
[PATCH 1/6] arm: mvebu: ac5: Add nand-controller node
The AC5/AC5X SoC has a NAND flash controller. Add this to the
SoC device tree.
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx25xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
index 3c68355f323a..f53b4781d7fd 100644
--- a/arch/arm/dts/ac5-98dx25xx.dtsi
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -251,6 +251,15 @@
status = "disabled";
};
+ nand: nand-controller@805b {
+ compatible = "marvell,mvebu-ac5-pxa3xx-nand";
+ reg = <0x0 0x805b 0x0 0x54>;
+ #address-cells = <0x0001>;
+ marvell,nand-enable-arbiter;
+ num-cs = <0x0001>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@8060 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
2.41.0
[PATCH 3/6] mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC
The NAND flash controller (NFC) on the AC5/AC5X SoC is the same as
the NFC used on other Marvell SoCs. It does have the additional
restriction of only supporting SDR timing modes up to 3.
Signed-off-by: Chris Packham
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index fcd1b9c63614..9dee580ab9c2 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -167,6 +167,7 @@ enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
PXA3XX_NAND_VARIANT_ARMADA_8K,
+ PXA3XX_NAND_VARIANT_AC5,
};
struct pxa3xx_nand_host {
@@ -391,6 +392,10 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,armada-8k-nand-controller",
.data = PXA3XX_NAND_VARIANT_ARMADA_8K,
},
+ {
+ .compatible = "marvell,mvebu-ac5-pxa3xx-nand",
+ .data = PXA3XX_NAND_VARIANT_AC5,
+ },
{}
};
@@ -505,6 +510,9 @@ static int pxa3xx_nand_init_timings(struct pxa3xx_nand_host
*host)
if (mode < 0)
mode = 0;
+ if (info->variant == PXA3XX_NAND_VARIANT_AC5)
+ mode = min(mode, 3);
+
timings = onfi_async_timing_mode_to_sdr_timings(mode);
if (IS_ERR(timings))
return PTR_ERR(timings);
@@ -730,7 +738,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -1579,7 +1588,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
/* Device detection must be done with ECC disabled */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDECCCTRL, 0x0);
if (nand_scan_ident(mtd, 1, NULL))
@@ -1630,7 +1640,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
*/
if (mtd->writesize > info->chunk_size) {
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5) {
chip->cmdfunc = nand_cmdfunc_extended;
} else {
dev_err(mtd->dev,
--
2.41.0
[PATCH 4/6] mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K
The CN9130 SoC (an ARMADA 8K type) has both a NAND Flash Controller and a generic local bus controller (Device Bus Controller) that share common pins. With a board design that incorporates both a NAND flash and uses the Device Bus (in our case for an SRAM) accessing the Device Bus device fails unless the NfArbiterEn bit is set. Setting the bit enables arbitration between the Device Bus and the NAND flash. Since there is no obvious downside in enabling this for designs that don't require arbitration, we always enable it. Signed-off-by: Chris Packham --- drivers/mtd/nand/raw/pxa3xx_nand.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c b/drivers/mtd/nand/raw/pxa3xx_nand.c index 9dee580ab9c2..d502e967f92c 100644 --- a/drivers/mtd/nand/raw/pxa3xx_nand.c +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c @@ -125,6 +125,7 @@ DECLARE_GLOBAL_DATA_PTR; /* System control register and bit to enable NAND on some SoCs */ #define GENCONF_SOC_DEVICE_MUX 0x208 #define GENCONF_SOC_DEVICE_MUX_NFC_EN BIT(0) +#define GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN BIT(27) /* * This should be large enough to read 'ONFI' and 'JEDEC'. @@ -1739,7 +1740,7 @@ static int alloc_nand_resource(struct udevice *dev, struct pxa3xx_nand_info *inf return PTR_ERR(sysctrl_base); regmap_read(sysctrl_base, GENCONF_SOC_DEVICE_MUX, ®); - reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN; + reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN | GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN; regmap_write(sysctrl_base, GENCONF_SOC_DEVICE_MUX, reg); } -- 2.41.0
[PATCH 5/6] arm: mvebu: Add Allied Telesis x240 board
The x240 and SE240 are a series of L2+ switches from Allied Telesis.
There are a number of them in the range but as far as U-Boot is
concerned all the CPU block components are the same so there's only one
board defined.
Signed-off-by: Chris Packham
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 +
arch/arm/mach-mvebu/Kconfig| 7 +
board/alliedtelesis/x240/MAINTAINERS | 7 +
board/alliedtelesis/x240/Makefile | 6 +
board/alliedtelesis/x240/x240.c| 13 ++
configs/x240_defconfig | 87 ++
include/configs/x240.h | 37 +
8 files changed, 371 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts
create mode 100644 board/alliedtelesis/x240/MAINTAINERS
create mode 100644 board/alliedtelesis/x240/Makefile
create mode 100644 board/alliedtelesis/x240/x240.c
create mode 100644 configs/x240_defconfig
create mode 100644 include/configs/x240.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..38d878a0f853 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -303,7 +303,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
cn9130-crb-B.dtb\
- ac5-98dx35xx-rd.dtb
+ ac5-98dx35xx-rd.dtb \
+ ac5-98dx35xx-atl-x240.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
new file mode 100644
index ..820ec18b4355
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Allied Telesis x240";
+ compatible = "alliedtelesis,x240", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 = &uart0;
+ spiflash0 = &spiflash0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ spi0 = &spi0;
+ i2c0 = &i2c0;
+ usb0 = &usb0;
+ pinctrl0 = &pinctrl0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ boot-board {
+ compatible = "atl,boot-board";
+ present-gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ override-gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ fault {
+ label = "fault:red";
+ gpios = <&system_gpio 11 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ };
+};
+
+&nand {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_pins>;
+
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ status = "okay";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@user {
+ reg = <0x 0x1000>;
+ label = "user";
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ mux@71 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ i2c-mux-idle-disconnect;
+ reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>; /*
MPP36 */
+ status = "okay";
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ hwmon@2e {
+ compatible = "adi,adt7476";
+ reg = <0x2e>;
+ };
+
+ rtc@68 {
+ compatible = "adi,max31331";
+ reg = <0x68>;
+ };
+
+ system_gpio: gpio@27 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells= <2>;
+ reg = <0x27>
[PATCH 6/6] arm: mvebu: Remove unused alias from RC AC5X dts
The sar-reg0 alias was left over from an earlier iteration of the
patches adding support for this board. Remove the unused alias.
Fixes: 6cc8b5db40 ("arm: mvebu: Add RD-AC5X board")
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx35xx-rd.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
index d9f217cd4a5f..1dc85bb7ef24 100644
--- a/arch/arm/dts/ac5-98dx35xx-rd.dts
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -31,7 +31,6 @@
usb0 = &usb0;
usb1 = &usb1;
pinctrl0 = &pinctrl0;
- sar-reg0 = "/config-space/sar-reg";
};
usb1phy: usb-phy {
--
2.41.0
Re: [PATCH 5/6] arm: mvebu: Add Allied Telesis x240 board
On Mon, Jul 3, 2023 at 3:39 PM Chris Packham wrote:
>
> The x240 and SE240 are a series of L2+ switches from Allied Telesis.
> There are a number of them in the range but as far as U-Boot is
> concerned all the CPU block components are the same so there's only one
> board defined.
>
> Signed-off-by: Chris Packham
> ---
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 +
> arch/arm/mach-mvebu/Kconfig| 7 +
> board/alliedtelesis/x240/MAINTAINERS | 7 +
> board/alliedtelesis/x240/Makefile | 6 +
> board/alliedtelesis/x240/x240.c| 13 ++
> configs/x240_defconfig | 87 ++
> include/configs/x240.h | 37 +
> 8 files changed, 371 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> create mode 100644 board/alliedtelesis/x240/MAINTAINERS
> create mode 100644 board/alliedtelesis/x240/Makefile
> create mode 100644 board/alliedtelesis/x240/x240.c
> create mode 100644 configs/x240_defconfig
> create mode 100644 include/configs/x240.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 480269fa6065..38d878a0f853 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -303,7 +303,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
> cn9132-db-B.dtb \
> cn9130-crb-A.dtb\
> cn9130-crb-B.dtb\
> - ac5-98dx35xx-rd.dtb
> + ac5-98dx35xx-rd.dtb \
> + ac5-98dx35xx-atl-x240.dtb
> endif
>
> dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
> diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> new file mode 100644
> index ..820ec18b4355
> --- /dev/null
> +++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> @@ -0,0 +1,212 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include
> +#include
> +#include "ac5-98dx35xx.dtsi"
> +
> +/ {
> + model = "Allied Telesis x240";
> + compatible = "alliedtelesis,x240", "marvell,ac5x", "marvell,ac5";
> +
> + aliases {
> + serial0 = &uart0;
> + spiflash0 = &spiflash0;
> + gpio0 = &gpio0;
> + gpio1 = &gpio1;
> + spi0 = &spi0;
> + i2c0 = &i2c0;
> + usb0 = &usb0;
> + pinctrl0 = &pinctrl0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + boot-board {
> + compatible = "atl,boot-board";
> + present-gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
> + override-gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>;
> + };
> +
> + gpio-leds {
> + compatible = "gpio-leds";
> +
> + fault {
> + label = "fault:red";
> + gpios = <&system_gpio 11 GPIO_ACTIVE_LOW>;
> + default-state = "on";
> + };
> + };
> +};
> +
> +&nand {
> + pinctrl-names = "default";
> + pinctrl-0 = <&nand_pins>;
> +
> + nand-ecc-strength = <4>;
> + nand-ecc-step-size = <512>;
> + status = "okay";
> +
> + partitions {
> + compatible = "fixed-partitions";
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + partition@user {
> + reg = <0x 0x1000>;
> + label = "user";
> + };
> + };
> +};
> +
> +&uart0 {
> + status = "okay";
> +};
> +
> +&usb0 {
> + status = "okay";
> +};
> +
> +&i2c0 {
> + status = "okay";
> +
> + mux@71 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "nxp,pca9546";
> + reg = <0x71>;
> + i2c-mux-idle-disconnect;
> + reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>; /*
> MPP36 */
> + status = "okay";
> +
> + i2c@1 {
> + #address-cells = <1>;
> +
[PATCH v2 0/6] Support for AC5X NAND and AT-x240 board
This series adds support for the NAND flash controller on the AC5X SoC and adds support for the Allied Telesis x240 board. I've also included 2 unrelated changes. "arm: mvebu: Remove unused alias from RC AC5X dts" removes an unused alias from the dts. This was in the neighborhood of the x240 so I included it. "mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K" allows using the NFC and device bus at the same time. This is needed for another board (CN9130 based) that I'll hopefully get upstream in the near future. I figured I'd include it now since I was touching the NAND driver. Chris Packham (6): arm: mvebu: ac5: Add nand-controller node arm: mvebu: ac5: Define mvebu_get_nand_clock() mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K arm: mvebu: Add Allied Telesis x240 board arm: mvebu: Remove unused alias from RC AC5X dts arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 9 ++ arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 + arch/arm/dts/ac5-98dx35xx-rd.dts | 1 - arch/arm/mach-mvebu/Kconfig| 7 + arch/arm/mach-mvebu/alleycat5/soc.c| 6 + board/alliedtelesis/x240/MAINTAINERS | 7 + board/alliedtelesis/x240/Makefile | 6 + board/alliedtelesis/x240/x240.c| 13 ++ configs/x240_defconfig | 86 ++ drivers/mtd/nand/raw/pxa3xx_nand.c | 20 ++- include/configs/x240.h | 37 + 12 files changed, 401 insertions(+), 6 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts create mode 100644 board/alliedtelesis/x240/MAINTAINERS create mode 100644 board/alliedtelesis/x240/Makefile create mode 100644 board/alliedtelesis/x240/x240.c create mode 100644 configs/x240_defconfig create mode 100644 include/configs/x240.h -- 2.41.0
[PATCH v2 1/6] arm: mvebu: ac5: Add nand-controller node
The AC5/AC5X SoC has a NAND flash controller. Add this to the
SoC device tree.
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx25xx.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
index 3c68355f323a..f53b4781d7fd 100644
--- a/arch/arm/dts/ac5-98dx25xx.dtsi
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -251,6 +251,15 @@
status = "disabled";
};
+ nand: nand-controller@805b {
+ compatible = "marvell,mvebu-ac5-pxa3xx-nand";
+ reg = <0x0 0x805b 0x0 0x54>;
+ #address-cells = <0x0001>;
+ marvell,nand-enable-arbiter;
+ num-cs = <0x0001>;
+ status = "disabled";
+ };
+
gic: interrupt-controller@8060 {
compatible = "arm,gic-v3";
#interrupt-cells = <3>;
--
2.41.0
[PATCH v2 2/6] arm: mvebu: ac5: Define mvebu_get_nand_clock()
The NF_CLK for the AC5 SoC runs at 400MHz. There's no strapping
or gating require so just add a mvebu_get_nand_clock() that
returns this value.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/soc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
b/arch/arm/mach-mvebu/alleycat5/soc.c
index dc69f46eedb2..734b0a87dd49 100644
--- a/arch/arm/mach-mvebu/alleycat5/soc.c
+++ b/arch/arm/mach-mvebu/alleycat5/soc.c
@@ -255,6 +255,12 @@ void soc_print_clock_info(void)
printf("\tMSS %4d MHz\n", 200);
}
+/* Return NAND clock in Hz */
+u32 mvebu_get_nand_clock(void)
+{
+ return 400 * 100;
+}
+
/*
* Override of __weak int mach_cpu_init(void) :
* SoC/machine dependent CPU setup
--
2.41.0
[PATCH v2 3/6] mtd: nand: pxa3xx: Add support for the Marvell AC5 SoC
The NAND flash controller (NFC) on the AC5/AC5X SoC is the same as
the NFC used on other Marvell SoCs. It does have the additional
restriction of only supporting SDR timing modes up to 3.
Signed-off-by: Chris Packham
---
drivers/mtd/nand/raw/pxa3xx_nand.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index fcd1b9c63614..9dee580ab9c2 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -167,6 +167,7 @@ enum pxa3xx_nand_variant {
PXA3XX_NAND_VARIANT_PXA,
PXA3XX_NAND_VARIANT_ARMADA370,
PXA3XX_NAND_VARIANT_ARMADA_8K,
+ PXA3XX_NAND_VARIANT_AC5,
};
struct pxa3xx_nand_host {
@@ -391,6 +392,10 @@ static const struct udevice_id pxa3xx_nand_dt_ids[] = {
.compatible = "marvell,armada-8k-nand-controller",
.data = PXA3XX_NAND_VARIANT_ARMADA_8K,
},
+ {
+ .compatible = "marvell,mvebu-ac5-pxa3xx-nand",
+ .data = PXA3XX_NAND_VARIANT_AC5,
+ },
{}
};
@@ -505,6 +510,9 @@ static int pxa3xx_nand_init_timings(struct pxa3xx_nand_host
*host)
if (mode < 0)
mode = 0;
+ if (info->variant == PXA3XX_NAND_VARIANT_AC5)
+ mode = min(mode, 3);
+
timings = onfi_async_timing_mode_to_sdr_timings(mode);
if (IS_ERR(timings))
return PTR_ERR(timings);
@@ -730,7 +738,8 @@ static irqreturn_t pxa3xx_nand_irq(struct pxa3xx_nand_info
*info)
/* NDCB3 register is available in NFCv2 (Armada 370/XP SoC) */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDCB0, info->ndcb3);
}
@@ -1579,7 +1588,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
/* Device detection must be done with ECC disabled */
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K)
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5)
nand_writel(info, NDECCCTRL, 0x0);
if (nand_scan_ident(mtd, 1, NULL))
@@ -1630,7 +1640,8 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
*/
if (mtd->writesize > info->chunk_size) {
if (info->variant == PXA3XX_NAND_VARIANT_ARMADA370 ||
- info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K) {
+ info->variant == PXA3XX_NAND_VARIANT_ARMADA_8K ||
+ info->variant == PXA3XX_NAND_VARIANT_AC5) {
chip->cmdfunc = nand_cmdfunc_extended;
} else {
dev_err(mtd->dev,
--
2.41.0
[PATCH v2 4/6] mtd: nand: pxa3xx: Enable devbus/nand arbiter on Armada 8K
The CN9130 SoC (an ARMADA 8K type) has both a NAND Flash Controller and a generic local bus controller (Device Bus Controller) that share common pins. With a board design that incorporates both a NAND flash and uses the Device Bus (in our case for an SRAM) accessing the Device Bus device fails unless the NfArbiterEn bit is set. Setting the bit enables arbitration between the Device Bus and the NAND flash. Since there is no obvious downside in enabling this for designs that don't require arbitration, we always enable it. Signed-off-by: Chris Packham --- drivers/mtd/nand/raw/pxa3xx_nand.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c b/drivers/mtd/nand/raw/pxa3xx_nand.c index 9dee580ab9c2..d502e967f92c 100644 --- a/drivers/mtd/nand/raw/pxa3xx_nand.c +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c @@ -125,6 +125,7 @@ DECLARE_GLOBAL_DATA_PTR; /* System control register and bit to enable NAND on some SoCs */ #define GENCONF_SOC_DEVICE_MUX 0x208 #define GENCONF_SOC_DEVICE_MUX_NFC_EN BIT(0) +#define GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN BIT(27) /* * This should be large enough to read 'ONFI' and 'JEDEC'. @@ -1739,7 +1740,7 @@ static int alloc_nand_resource(struct udevice *dev, struct pxa3xx_nand_info *inf return PTR_ERR(sysctrl_base); regmap_read(sysctrl_base, GENCONF_SOC_DEVICE_MUX, ®); - reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN; + reg |= GENCONF_SOC_DEVICE_MUX_NFC_EN | GENCONF_SOC_DEVICE_MUX_NFC_DEVBUS_ARB_EN; regmap_write(sysctrl_base, GENCONF_SOC_DEVICE_MUX, reg); } -- 2.41.0
[PATCH v2 5/6] arm: mvebu: Add Allied Telesis x240 board
The x240 and SE240 are a series of L2+ switches from Allied Telesis.
There are a number of them in the range but as far as U-Boot is
concerned all the CPU block components are the same so there's only one
board defined.
Signed-off-by: Chris Packham
---
Notes:
Changes in v2:
- drop CONFIG_DEBUG_UART
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 212 +
arch/arm/mach-mvebu/Kconfig| 7 +
board/alliedtelesis/x240/MAINTAINERS | 7 +
board/alliedtelesis/x240/Makefile | 6 +
board/alliedtelesis/x240/x240.c| 13 ++
configs/x240_defconfig | 86 ++
include/configs/x240.h | 37 +
8 files changed, 370 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-atl-x240.dts
create mode 100644 board/alliedtelesis/x240/MAINTAINERS
create mode 100644 board/alliedtelesis/x240/Makefile
create mode 100644 board/alliedtelesis/x240/x240.c
create mode 100644 configs/x240_defconfig
create mode 100644 include/configs/x240.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 480269fa6065..38d878a0f853 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -303,7 +303,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
cn9130-crb-B.dtb\
- ac5-98dx35xx-rd.dtb
+ ac5-98dx35xx-rd.dtb \
+ ac5-98dx35xx-atl-x240.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
new file mode 100644
index ..820ec18b4355
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -0,0 +1,212 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include
+#include
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Allied Telesis x240";
+ compatible = "alliedtelesis,x240", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 = &uart0;
+ spiflash0 = &spiflash0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ spi0 = &spi0;
+ i2c0 = &i2c0;
+ usb0 = &usb0;
+ pinctrl0 = &pinctrl0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ boot-board {
+ compatible = "atl,boot-board";
+ present-gpio = <&gpio1 6 GPIO_ACTIVE_HIGH>;
+ override-gpio = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+
+ fault {
+ label = "fault:red";
+ gpios = <&system_gpio 11 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+ };
+};
+
+&nand {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_pins>;
+
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ status = "okay";
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@user {
+ reg = <0x 0x1000>;
+ label = "user";
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&usb0 {
+ status = "okay";
+};
+
+&i2c0 {
+ status = "okay";
+
+ mux@71 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "nxp,pca9546";
+ reg = <0x71>;
+ i2c-mux-idle-disconnect;
+ reset-gpios = <&gpio1 4 GPIO_ACTIVE_LOW>; /*
MPP36 */
+ status = "okay";
+
+ i2c@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ hwmon@2e {
+ compatible = "adi,adt7476";
+ reg = <0x2e>;
+ };
+
+ rtc@68 {
+ compatible = "adi,max31331";
+ reg = <0x68>;
+ };
+
+ system_gpio: gpio@27 {
+ compatible = "nxp,pca9555";
+ gpio-controller;
+ #gpio-cells= &
[PATCH v2 6/6] arm: mvebu: Remove unused alias from RC AC5X dts
The sar-reg0 alias was left over from an earlier iteration of the
patches adding support for this board. Remove the unused alias.
Fixes: 6cc8b5db40 ("arm: mvebu: Add RD-AC5X board")
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx35xx-rd.dts | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
index d9f217cd4a5f..1dc85bb7ef24 100644
--- a/arch/arm/dts/ac5-98dx35xx-rd.dts
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -31,7 +31,6 @@
usb0 = &usb0;
usb1 = &usb1;
pinctrl0 = &pinctrl0;
- sar-reg0 = "/config-space/sar-reg";
};
usb1phy: usb-phy {
--
2.41.0
[PATCH] drivers: rtc: max313xx: provide read8/write8
In some designs the MAX313xx RTC may need calibration to cope with
oscillator inaccuracies. Provide read8/write8 ops so that the registers
can be accessed. Because the driver covers a range of MAX313xx variants
no attempt is made to ensure the register is valid.
Signed-off-by: Chris Packham
---
drivers/rtc/max313xx.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/rtc/max313xx.c b/drivers/rtc/max313xx.c
index 748f3c42c30e..60400235dd0f 100644
--- a/drivers/rtc/max313xx.c
+++ b/drivers/rtc/max313xx.c
@@ -326,10 +326,22 @@ static int max313xx_reset(struct udevice *dev)
return ret;
}
+static int max313xx_read8(struct udevice *dev, unsigned int reg)
+{
+ return dm_i2c_reg_read(dev, reg);
+}
+
+static int max313xx_write8(struct udevice *dev, unsigned int reg, int val)
+{
+ return dm_i2c_reg_write(dev, reg, val);
+}
+
static const struct rtc_ops max3133x_rtc_ops = {
.get= max313xx_read_time,
.set= max313xx_set_time,
.reset = max313xx_reset,
+ .read8 = max313xx_read8,
+ .write8 = max313xx_write8,
};
static int max313xx_init(struct udevice *dev)
--
2.41.0
[PATCH] i2c: i2c-gpio: Correctly handle new {sda,scl}-gpios bindings
gpio_request_list_by_name() returns the number of gpios requested.
Notably it swallows the underlying -ENOENT when the "gpios" property
does not exist.
Update the i2c-gpio driver to check for ret == 0 before trying the new
sda-gpios/scl-gpios properties.
Signed-off-by: Chris Packham
---
drivers/i2c/i2c-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-gpio.c b/drivers/i2c/i2c-gpio.c
index 4ed9e9e7cddd..c1fc290bd253 100644
--- a/drivers/i2c/i2c-gpio.c
+++ b/drivers/i2c/i2c-gpio.c
@@ -339,7 +339,7 @@ static int i2c_gpio_of_to_plat(struct udevice *dev)
/* "gpios" is deprecated and replaced by "sda-gpios" + "scl-gpios". */
ret = gpio_request_list_by_name(dev, "gpios", bus->gpios,
ARRAY_SIZE(bus->gpios), 0);
- if (ret == -ENOENT) {
+ if (ret == 0) {
ret = gpio_request_by_name(dev, "sda-gpios", 0,
&bus->gpios[PIN_SDA], 0);
if (ret < 0)
--
2.41.0
[PATCH] arm: mvebu: x240: Use i2c-gpio instead of built in controller
There is an Errata with the built-in I2C controller where various I2C
hardware errors cause a complete lockup of the CPU (which eventually
results in an watchdog reset).
Put the I2C MPP pins into GPIO mode and use the i2c-gpio driver instead.
This uses a bit-banged implementation of an I2C controller and avoids
triggering the Errata.
Signed-off-by: Chris Packham
---
This is dependent on a bug-fix for the i2c-gpio driver I just sent
out[1] (sorry I should have sent them as a series but I thought this
would take me longer to test than it did).
[1] -
https://lore.kernel.org/u-boot/20230720023107.1184147-1-judge.pack...@gmail.com/
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 ++
configs/x240_defconfig | 1 +
2 files changed, 27 insertions(+), 4 deletions(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
index 820ec18b4355..d47220520b9e 100644
--- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -71,8 +71,25 @@
};
&i2c0 {
- status = "okay";
+ status = "disabled";
+};
+&{/} {
+ i2cgpio: i2c-gpio-0 {
+ compatible = "i2c-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_gpio>;
+ scl-gpios = <&gpio0 26 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio0 27 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ status = "okay";
+};
+};
+
+&i2cgpio {
mux@71 {
#address-cells = <1>;
#size-cells = <0>;
@@ -177,8 +194,8 @@
* LED_OE_N [23]
* USB_PWR_FLT_N [24]
* SFP_INT_N [25]
-* I2C0_SCL [26]
-* I2C0_SDA [27]
+* I2C0_SCL [26] (GPIO)
+* I2C0_SDA [27] (GPIO)
* USB_EN[28]
* MONITOR_INT_N [29]
* XM1_MDC [30]
@@ -201,7 +218,7 @@
/* 0123456789 */
pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 11110xff 0xff 00
-0000001100
+0000000xff 0xff 00
1111000000
000111>;
@@ -209,4 +226,9 @@
marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
marvell,function = <2>;
};
+
+ i2c0_gpio: i2c0-gpio-pins {
+ marvell,pins = <26 27>;
+ marvell,function = <0>;
+ };
};
diff --git a/configs/x240_defconfig b/configs/x240_defconfig
index 6d25c5ae3fcf..e8589d636081 100644
--- a/configs/x240_defconfig
+++ b/configs/x240_defconfig
@@ -43,6 +43,7 @@ CONFIG_CLK_MVEBU=y
CONFIG_GPIO_HOG=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
+CONFIG_DM_I2C_GPIO=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
--
2.41.0
Re: [PATCH] arm: mvebu: x240: Use i2c-gpio instead of built in controller
Hi Me,
On Thu, Jul 20, 2023 at 3:03 PM Chris Packham wrote:
>
> There is an Errata with the built-in I2C controller where various I2C
> hardware errors cause a complete lockup of the CPU (which eventually
> results in an watchdog reset).
>
> Put the I2C MPP pins into GPIO mode and use the i2c-gpio driver instead.
> This uses a bit-banged implementation of an I2C controller and avoids
> triggering the Errata.
>
> Signed-off-by: Chris Packham
> ---
> This is dependent on a bug-fix for the i2c-gpio driver I just sent
> out[1] (sorry I should have sent them as a series but I thought this
> would take me longer to test than it did).
>
> [1] -
> https://lore.kernel.org/u-boot/20230720023107.1184147-1-judge.pack...@gmail.com/
>
> arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 ++
> configs/x240_defconfig | 1 +
> 2 files changed, 27 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> index 820ec18b4355..d47220520b9e 100644
> --- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> +++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
> @@ -71,8 +71,25 @@
> };
>
> &i2c0 {
> - status = "okay";
> + status = "disabled";
> +};
I'll remove this section completely. I did want to make it clear that
we're using the same pins just as GPIOs instead of the dedicated I2C
mode which has issues but that can be explained better in the commit
message.
>
> +&{/} {
I should probably move this part up to the root node rather than
addressing it here.
> + i2cgpio: i2c-gpio-0 {
> + compatible = "i2c-gpio";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c0_gpio>;
> + scl-gpios = <&gpio0 26 (GPIO_ACTIVE_HIGH |
> GPIO_OPEN_DRAIN)>;
> + sda-gpios = <&gpio0 27 (GPIO_ACTIVE_HIGH |
> GPIO_OPEN_DRAIN)>;
> + i2c-gpio,delay-us = <2>;
> + status = "okay";
> +};
> +};
> +
> +&i2cgpio {
> mux@71 {
> #address-cells = <1>;
> #size-cells = <0>;
> @@ -177,8 +194,8 @@
> * LED_OE_N [23]
> * USB_PWR_FLT_N [24]
> * SFP_INT_N [25]
> -* I2C0_SCL [26]
> -* I2C0_SDA [27]
> +* I2C0_SCL [26] (GPIO)
> +* I2C0_SDA [27] (GPIO)
> * USB_EN[28]
> * MONITOR_INT_N [29]
> * XM1_MDC [30]
> @@ -201,7 +218,7 @@
> /* 0123456789 */
> pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
> 0xff 0xff 11110xff 0xff 00
> -0000001100
> +0000000xff 0xff 00
> 1111000000
> 000111>;
>
> @@ -209,4 +226,9 @@
> marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
> marvell,function = <2>;
> };
> +
> + i2c0_gpio: i2c0-gpio-pins {
> + marvell,pins = <26 27>;
> + marvell,function = <0>;
> + };
> };
> diff --git a/configs/x240_defconfig b/configs/x240_defconfig
> index 6d25c5ae3fcf..e8589d636081 100644
> --- a/configs/x240_defconfig
> +++ b/configs/x240_defconfig
> @@ -43,6 +43,7 @@ CONFIG_CLK_MVEBU=y
> CONFIG_GPIO_HOG=y
> CONFIG_DM_PCA953X=y
> CONFIG_DM_I2C=y
> +CONFIG_DM_I2C_GPIO=y
> CONFIG_SYS_I2C_MVTWSI=y
> CONFIG_I2C_MUX=y
> CONFIG_I2C_MUX_PCA954x=y
> --
> 2.41.0
>
Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available
Hi Marc, Paul,
On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu)
wrote:
>
> From: Marc Zyngier
>
> Some recent arm64 cores have a facility that allows the page
> table walker to track the dirty state of a page. This makes it
> really efficient to perform CMOs by VA as we only need to look
> at dirty pages.
>
> Signed-off-by: Marc Zyngier
> [ Paul: pick from the Android tree. Rebase to the upstream ]
> Signed-off-by: Ying-Chun Liu (PaulLiu)
> Cc: Tom Rini
> Link:
> https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263
I think this may have caused a regression for the Marvell AC5X
board(s). I found that v2023.07 locked up at boot but v2023.01 was
fine. The lockup seemed to be in the 'Net:' init probably just as the
mvneta driver was being initialised.
A git bisect led me to this change although for this specific change
instead of the lockup I get a crash so maybe I'm actually hitting a
different issue.
Any thoughts as to why this may have caused problems?
> ---
> arch/arm/cpu/armv8/cache_v8.c | 16 +++-
> arch/arm/include/asm/armv8/mmu.h | 14 ++
> arch/arm/include/asm/global_data.h | 1 +
> 3 files changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
> index 697334086f..4760064ee1 100644
> --- a/arch/arm/cpu/armv8/cache_v8.c
> +++ b/arch/arm/cpu/armv8/cache_v8.c
> @@ -93,6 +93,8 @@ u64 get_tcr(u64 *pips, u64 *pva_bits)
>
> if (el == 1) {
> tcr = TCR_EL1_RSVD | (ips << 32) | TCR_EPD1_DISABLE;
> + if (gd->arch.has_hafdbs)
> + tcr |= TCR_HA | TCR_HD;
> } else if (el == 2) {
> tcr = TCR_EL2_RSVD | (ips << 16);
> } else {
> @@ -200,6 +202,9 @@ static void __cmo_on_leaves(void (*cmo_fn)(unsigned long,
> unsigned long),
> attrs != PTE_BLOCK_MEMTYPE(MT_NORMAL_NC))
> continue;
>
> + if (gd->arch.has_hafdbs && (pte & (PTE_RDONLY | PTE_DBM)) !=
> PTE_DBM)
> + continue;
> +
> end = va + BIT(level2shift(level)) - 1;
>
> /* No intersection with RAM? */
> @@ -348,6 +353,9 @@ static void add_map(struct mm_region *map)
> if (va_bits < 39)
> level = 1;
>
> + if (gd->arch.has_hafdbs)
> + attrs |= PTE_DBM | PTE_RDONLY;
> +
> map_range(map->virt, map->phys, map->size, level,
> (u64 *)gd->arch.tlb_addr, attrs);
> }
> @@ -399,7 +407,13 @@ static int count_ranges(void)
> __weak u64 get_page_table_size(void)
> {
> u64 one_pt = MAX_PTE_ENTRIES * sizeof(u64);
> - u64 size;
> + u64 size, mmfr1;
> +
> + asm volatile("mrs %0, id_aa64mmfr1_el1" : "=r" (mmfr1));
> + if ((mmfr1 & 0xf) == 2)
> + gd->arch.has_hafdbs = true;
> + else
> + gd->arch.has_hafdbs = false;
>
> /* Account for all page tables we would need to cover our memory map
> */
> size = one_pt * count_ranges();
> diff --git a/arch/arm/include/asm/armv8/mmu.h
> b/arch/arm/include/asm/armv8/mmu.h
> index 9f58cedb65..98a27db316 100644
> --- a/arch/arm/include/asm/armv8/mmu.h
> +++ b/arch/arm/include/asm/armv8/mmu.h
> @@ -49,10 +49,13 @@
> #define PTE_TYPE_BLOCK (1 << 0)
> #define PTE_TYPE_VALID (1 << 0)
>
> -#define PTE_TABLE_PXN (1UL << 59)
> -#define PTE_TABLE_XN (1UL << 60)
> -#define PTE_TABLE_AP (1UL << 61)
> -#define PTE_TABLE_NS (1UL << 63)
> +#define PTE_RDONLY BIT(7)
> +#define PTE_DBMBIT(51)
> +
> +#define PTE_TABLE_PXN BIT(59)
> +#define PTE_TABLE_XN BIT(60)
> +#define PTE_TABLE_AP BIT(61)
> +#define PTE_TABLE_NS BIT(63)
>
> /*
> * Block
> @@ -99,6 +102,9 @@
> #define TCR_TG0_16K(2 << 14)
> #define TCR_EPD1_DISABLE (1 << 23)
>
> +#define TCR_HA BIT(39)
> +#define TCR_HD BIT(40)
> +
> #define TCR_EL1_RSVD (1U << 31)
> #define TCR_EL2_RSVD (1U << 31 | 1 << 23)
> #define TCR_EL3_RSVD (1U << 31 | 1 << 23)
> diff --git a/arch/arm/include/asm/global_data.h
> b/arch/arm/include/asm/global_data.h
> index 9e746e380a..eda99b5b41 100644
> --- a/arch/arm/include/asm/global_data.h
> +++ b/arch/arm/include/asm/global_data.h
> @@ -52,6 +52,7 @@ struct arch_global_data {
> #if defined(CONFIG_ARM64)
> unsigned long tlb_fillptr;
> unsigned long tlb_emerg;
> + bool has_hafdbs;
> #endif
> #endif
> #ifdef CFG_SYS_MEM_RESERVE_SECURE
> --
> 2.39.2
>
[PATCH] arm: mvebu: AC5/AC5X: Disable SMBIOS
The RD-AC5X doesn't make use of EFI or SMBIOS. Recently we started seeing boot failures such as WARNING: SMBIOS table_address overflow 27f60f020 Failed to write SMBIOS table initcall failed at event 10/(unknown) (err=-22) ### ERROR ### Please RESET the board ### The error is because the physical address of the RAM on the AC5X SoC is above the 32GiB boundary. As we don't need SMBIOS or EFI this can be safely disabled. Signed-off-by: Chris Packham --- This probably should have been part of the series I sent as https://lore.kernel.org/u-boot/20231003035800.2626121-1-judge.pack...@gmail.com/ but I didn't have the RD-AC5X board at the time. There is another issue that's stopping the RD-AC5X board from booting with current master but with the suspect commit reverted you can see the same SMBIOS issue I was seeing on the x240. configs/mvebu_ac5_rd_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/mvebu_ac5_rd_defconfig b/configs/mvebu_ac5_rd_defconfig index dbf1e3136cdf..e8fa22b648be 100644 --- a/configs/mvebu_ac5_rd_defconfig +++ b/configs/mvebu_ac5_rd_defconfig @@ -85,3 +85,4 @@ CONFIG_USB_ETHER_ASIX88179=y CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y +# CONFIG_SMBIOS is not set -- 2.42.0
Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available
On Sat, 14 Oct 2023, 11:04 am Marc Zyngier, wrote: > On 2023-10-13 03:40, Chris Packham wrote: > > Hi Marc, Paul, > > > > On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu) > > wrote: > >> > >> From: Marc Zyngier > >> > >> Some recent arm64 cores have a facility that allows the page > >> table walker to track the dirty state of a page. This makes it > >> really efficient to perform CMOs by VA as we only need to look > >> at dirty pages. > >> > >> Signed-off-by: Marc Zyngier > >> [ Paul: pick from the Android tree. Rebase to the upstream ] > >> Signed-off-by: Ying-Chun Liu (PaulLiu) > >> Cc: Tom Rini > >> Link: > >> > https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263 > > > > I think this may have caused a regression for the Marvell AC5X > > board(s). I found that v2023.07 locked up at boot but v2023.01 was > > fine. The lockup seemed to be in the 'Net:' init probably just as the > > mvneta driver was being initialised. > > > > A git bisect led me to this change although for this specific change > > instead of the lockup I get a crash so maybe I'm actually hitting a > > different issue. > > > > Any thoughts as to why this may have caused problems? > > Not really. What CPUs does this platform have? What is the offending > driver doing to trigger the issue? Can you provide some level of > tracing? > The Marvell AC5X is a network switch ASIC with an integrated ARMv8 CPU (8.1 specifically I think). I think there is something that the mvneta driver is doing triggering the issue. I have another AC5X based board without an Ethernet port that boots just fine (this is also why I didn't notice earlier). I'll try and get some more debug out when I'm back in the office > M. > -- > Jazz is not dead. It just smells funny... >
Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available
On Sun, Oct 15, 2023 at 10:29 AM Chris Packham wrote: > > > > On Sat, 14 Oct 2023, 11:04 am Marc Zyngier, wrote: >> >> On 2023-10-13 03:40, Chris Packham wrote: >> > Hi Marc, Paul, >> > >> > On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu) >> > wrote: >> >> >> >> From: Marc Zyngier >> >> >> >> Some recent arm64 cores have a facility that allows the page >> >> table walker to track the dirty state of a page. This makes it >> >> really efficient to perform CMOs by VA as we only need to look >> >> at dirty pages. >> >> >> >> Signed-off-by: Marc Zyngier >> >> [ Paul: pick from the Android tree. Rebase to the upstream ] >> >> Signed-off-by: Ying-Chun Liu (PaulLiu) >> >> Cc: Tom Rini >> >> Link: >> >> https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263 >> > >> > I think this may have caused a regression for the Marvell AC5X >> > board(s). I found that v2023.07 locked up at boot but v2023.01 was >> > fine. The lockup seemed to be in the 'Net:' init probably just as the >> > mvneta driver was being initialised. >> > >> > A git bisect led me to this change although for this specific change >> > instead of the lockup I get a crash so maybe I'm actually hitting a >> > different issue. >> > >> > Any thoughts as to why this may have caused problems? >> >> Not really. What CPUs does this platform have? What is the offending >> driver doing to trigger the issue? Can you provide some level of >> tracing? > > > The Marvell AC5X is a network switch ASIC with an integrated ARMv8 CPU (8.1 > specifically I think). > > I think there is something that the mvneta driver is doing triggering the > issue. I have another AC5X based board without an Ethernet port that boots > just fine (this is also why I didn't notice earlier). > > I'll try and get some more debug out when I'm back in the office > The thing the mvneta driver does that upsets things appears to be mmu_set_region_dcache_behaviour((phys_addr_t)bd_space, BD_SPACE, DCACHE_OFF); I can comment that line out and everything works.
Re: [PATCH 1/3] arm64: Use FEAT_HAFDBS to track dirty pages when available
On Tue, Oct 17, 2023 at 12:21 AM Marc Zyngier wrote: > > On Mon, 16 Oct 2023 02:42:08 +0100, > Chris Packham wrote: > > > > On Sun, Oct 15, 2023 at 10:29 AM Chris Packham > > wrote: > > > > > > > > > > > > On Sat, 14 Oct 2023, 11:04 am Marc Zyngier, wrote: > > >> > > >> On 2023-10-13 03:40, Chris Packham wrote: > > >> > Hi Marc, Paul, > > >> > > > >> > On Sat, Mar 18, 2023 at 5:23 AM Ying-Chun Liu (PaulLiu) > > >> > wrote: > > >> >> > > >> >> From: Marc Zyngier > > >> >> > > >> >> Some recent arm64 cores have a facility that allows the page > > >> >> table walker to track the dirty state of a page. This makes it > > >> >> really efficient to perform CMOs by VA as we only need to look > > >> >> at dirty pages. > > >> >> > > >> >> Signed-off-by: Marc Zyngier > > >> >> [ Paul: pick from the Android tree. Rebase to the upstream ] > > >> >> Signed-off-by: Ying-Chun Liu (PaulLiu) > > >> >> Cc: Tom Rini > > >> >> Link: > > >> >> https://android.googlesource.com/platform/external/u-boot/+/3c433724e6f830a6b2edd5ec3d4a504794887263 > > >> > > > >> > I think this may have caused a regression for the Marvell AC5X > > >> > board(s). I found that v2023.07 locked up at boot but v2023.01 was > > >> > fine. The lockup seemed to be in the 'Net:' init probably just as the > > >> > mvneta driver was being initialised. > > >> > > > >> > A git bisect led me to this change although for this specific change > > >> > instead of the lockup I get a crash so maybe I'm actually hitting a > > >> > different issue. > > >> > > > >> > Any thoughts as to why this may have caused problems? > > >> > > >> Not really. What CPUs does this platform have? What is the offending > > >> driver doing to trigger the issue? Can you provide some level of > > >> tracing? > > > > > > > > > The Marvell AC5X is a network switch ASIC with an integrated ARMv8 CPU > > > (8.1 specifically I think). > > > > > > I think there is something that the mvneta driver is doing triggering the > > > issue. I have another AC5X based board without an Ethernet port that > > > boots just fine (this is also why I didn't notice earlier). > > > > > > I'll try and get some more debug out when I'm back in the office > > > > > > > The thing the mvneta driver does that upsets things appears to be > > > > mmu_set_region_dcache_behaviour((phys_addr_t)bd_space, BD_SPACE, > > DCACHE_OFF); > > > > I can comment that line out and everything works. > > This leads to two questions: > > - is the device cache coherent, in which case it doesn't need the > memory being non-cacheable? If everything is OK, then why the switch > to device memory? I'll be honest and say I understand less than 50% of that. The network transfer does seem to work without the call so perhaps the device is cache coherent but this seems to be a common thing in many drivers so I'd assume that on such platforms this should be innocuous. It's totally possible I haven't done a good job of setting up the CPU or informing the rest of the system about it. I did just take a lot of the code from the Marvell SDK and clean it up without really understanding what most of it did. > > - what goes wrong when these attributes are applied? do we have to > split a block mapping? > > Instrumenting the MMU code would certainly help understanding what > goes wrong here. I did do that a little bit. At first I thought there was a possible infinite loop in mmu_set_region_dcache_behaviour(). Squinting at things you could naively say that if set_one_region() failed to find an entry then it would loop forever but if that happened I'd have some debug saying that it failed. Things seem to go south after __asm_switch_ttbr(gd->arch.tlb_emerg) which did get me thinking that perhaps the emergency tables aren't setup (or at least aren't set up in a way that allows debug output). That's about as far as I got debugging wise, I'll try and spend some more time digging into the MMU code. > > Thanks, > > M. > > -- > Without deviation from the norm, progress is not possible.
[PATCH] arm: mvebu: AC5/AC5X: use fixed page table size
Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages
when available") the default get_page_table_size() sets some flags for
more efficient handling of dirty page table entries. This causes
problems on the AC5/AC5X SoC (specifically a lockup when calling
__asm_switch_ttbr() via mmu_set_region_dcache_behaviour()).
The reason for the lockup isn't at all clear but it can be avoided if we
provide our own get_page_table_size() which stops gd->arch.has_hafdbs
from being set to true effectively returning the AC5/AC5X to the older
behaviour. This also opts for a simple fixed page table size rather than
trying to duplicate the more complicated logic to optimise the table
size.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/cpu.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
b/arch/arm/mach-mvebu/alleycat5/cpu.c
index 8204d9627515..7ba57ae75e76 100644
--- a/arch/arm/mach-mvebu/alleycat5/cpu.c
+++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
@@ -63,6 +63,11 @@ static struct mm_region ac5_mem_map[] = {
struct mm_region *mem_map = ac5_mem_map;
+u64 get_page_table_size(void)
+{
+ return 0x8;
+}
+
void reset_cpu(void)
{
}
--
2.42.0
Re: [PATCH] arm: mvebu: AC5/AC5X: use fixed page table size
On Fri, 20 Oct 2023, 7:18 pm Stefan Roese, wrote:
> Hi Chris,
>
> On 10/18/23 22:53, Chris Packham wrote:
> > Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages
> > when available") the default get_page_table_size() sets some flags for
> > more efficient handling of dirty page table entries. This causes
> > problems on the AC5/AC5X SoC (specifically a lockup when calling
> > __asm_switch_ttbr() via mmu_set_region_dcache_behaviour()).
> >
> > The reason for the lockup isn't at all clear but it can be avoided if we
> > provide our own get_page_table_size() which stops gd->arch.has_hafdbs
> > from being set to true effectively returning the AC5/AC5X to the older
> > behaviour. This also opts for a simple fixed page table size rather than
> > trying to duplicate the more complicated logic to optimise the table
> > size.
> >
> > Signed-off-by: Chris Packham
>
> I'm not 100% happy with this approach / workaround - still it fixes an
> issue on your board, so:
>
> Reviewed-by: Stefan Roese
>
Yeah I'm not super happy about this either. But this is about the best I
could come up with.
> Perhaps you (or someone else) can look into this in more depth to get
> to the root of this issue at a later time.
>
I did spend a reasonable amount of time tracking down where things were
going wrong, even if I couldn't figure out why. The commit message
basically reflects what I found.
> Thanks,
> Stefan
>
> > ---
> >
> > arch/arm/mach-mvebu/alleycat5/cpu.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
> b/arch/arm/mach-mvebu/alleycat5/cpu.c
> > index 8204d9627515..7ba57ae75e76 100644
> > --- a/arch/arm/mach-mvebu/alleycat5/cpu.c
> > +++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
> > @@ -63,6 +63,11 @@ static struct mm_region ac5_mem_map[] = {
> >
> > struct mm_region *mem_map = ac5_mem_map;
> >
> > +u64 get_page_table_size(void)
> > +{
> > + return 0x8;
> > +}
> > +
> > void reset_cpu(void)
> > {
> > }
>
> Viele Grüße,
> Stefan Roese
>
> --
> DENX Software Engineering GmbH, Managing Director: Erika Unter
> 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] arm: mvebu: AC5/AC5X: use fixed page table size
On Sat, 21 Oct 2023, 2:04 am Marc Zyngier, wrote:
> On 2023-10-18 21:53, Chris Packham wrote:
> > Since commit 6cdf6b7a340d ("arm64: Use FEAT_HAFDBS to track dirty pages
> > when available") the default get_page_table_size() sets some flags for
> > more efficient handling of dirty page table entries. This causes
> > problems on the AC5/AC5X SoC (specifically a lockup when calling
> > __asm_switch_ttbr() via mmu_set_region_dcache_behaviour()).
> >
> > The reason for the lockup isn't at all clear but it can be avoided if
> > we
> > provide our own get_page_table_size() which stops gd->arch.has_hafdbs
> > from being set to true effectively returning the AC5/AC5X to the older
> > behaviour. This also opts for a simple fixed page table size rather
> > than
> > trying to duplicate the more complicated logic to optimise the table
> > size.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > arch/arm/mach-mvebu/alleycat5/cpu.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
> > b/arch/arm/mach-mvebu/alleycat5/cpu.c
> > index 8204d9627515..7ba57ae75e76 100644
> > --- a/arch/arm/mach-mvebu/alleycat5/cpu.c
> > +++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
> > @@ -63,6 +63,11 @@ static struct mm_region ac5_mem_map[] = {
> >
> > struct mm_region *mem_map = ac5_mem_map;
> >
> > +u64 get_page_table_size(void)
> > +{
> > + return 0x8;
> > +}
> > +
> > void reset_cpu(void)
> > {
> > }
>
> This looks terribly wrong. In all honesty, if the original
> patch creates problems and that people add this sort of stuff
> to paper over it, I'd rather your *revert* my patch altogether.
>
There are other platforms that define a get_page_table_size(). That may
mean that they are just inadvertently avoiding the issues I'm seeing.
I'm happy to prepare a series reverting the problematic changes. But I'm
sure that there's something about the AC5 that's the actual problem. I'm
just out of my depth in terms of my ability to progress it.
> M.
> --
> Jazz is not dead. It just smells funny...
>
[PATCH 0/3] Revert HAFDBS changes
As discussed this series reverts the HAFDBS changes that caused an issue on AC5/AC5X. I think there are some improvements that can be made to the initial memory map for the AC5/AC5X but so far nothing I've found makes it compatible with the HAFDBS changes. Chris Packham (3): Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present" Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present" Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available" arch/arm/cpu/armv8/cache_v8.c | 30 +++--- arch/arm/include/asm/armv8/mmu.h | 20 arch/arm/include/asm/global_data.h | 2 -- 3 files changed, 7 insertions(+), 45 deletions(-) -- 2.42.0
[PATCH 1/3] Revert "armv8: enable HAFDBS for other ELx when FEAT_HAFDBS is present"
This reverts commit c1da6fdb5c239b432440721772d993e63cfdeb20. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham
---
arch/arm/cpu/armv8/cache_v8.c| 6 +-
arch/arm/include/asm/armv8/mmu.h | 10 ++
2 files changed, 3 insertions(+), 13 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index cb1131a0480e..4c6a1b1d6c5e 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -94,15 +94,11 @@ u64 get_tcr(u64 *pips, u64 *pva_bits)
if (el == 1) {
tcr = TCR_EL1_RSVD | (ips << 32) | TCR_EPD1_DISABLE;
if (gd->arch.has_hafdbs)
- tcr |= TCR_EL1_HA | TCR_EL1_HD;
+ tcr |= TCR_HA | TCR_HD;
} else if (el == 2) {
tcr = TCR_EL2_RSVD | (ips << 16);
- if (gd->arch.has_hafdbs)
- tcr |= TCR_EL2_HA | TCR_EL2_HD;
} else {
tcr = TCR_EL3_RSVD | (ips << 16);
- if (gd->arch.has_hafdbs)
- tcr |= TCR_EL3_HA | TCR_EL3_HD;
}
/* PTWs cacheable, inner/outer WBWA and inner shareable */
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index 19a9e112a434..98a27db3166b 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -102,14 +102,8 @@
#define TCR_TG0_16K(2 << 14)
#define TCR_EPD1_DISABLE (1 << 23)
-#define TCR_EL1_HA BIT(39)
-#define TCR_EL1_HD BIT(40)
-
-#define TCR_EL2_HA BIT(21)
-#define TCR_EL2_HD BIT(22)
-
-#define TCR_EL3_HA BIT(21)
-#define TCR_EL3_HD BIT(22)
+#define TCR_HA BIT(39)
+#define TCR_HD BIT(40)
#define TCR_EL1_RSVD (1U << 31)
#define TCR_EL2_RSVD (1U << 31 | 1 << 23)
--
2.42.0
[PATCH 2/3] Revert "arm64: Use level-2 for largest block mappings when FEAT_HAFDBS is present"
This reverts commit 836b8d4b205d2175b57cb9ef271e638b0c116e89. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham
---
arch/arm/cpu/armv8/cache_v8.c | 14 --
arch/arm/include/asm/global_data.h | 1 -
2 files changed, 4 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 4c6a1b1d6c5e..4760064ee18f 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -314,7 +314,7 @@ static void map_range(u64 virt, u64 phys, u64 size, int
level,
for (i = idx; size; i++) {
u64 next_size, *next_table;
- if (level >= gd->arch.first_block_level &&
+ if (level >= 1 &&
size >= map_size && !(virt & (map_size - 1))) {
if (level == 3)
table[i] = phys | attrs | PTE_TYPE_PAGE;
@@ -353,9 +353,6 @@ static void add_map(struct mm_region *map)
if (va_bits < 39)
level = 1;
- if (!gd->arch.first_block_level)
- gd->arch.first_block_level = 1;
-
if (gd->arch.has_hafdbs)
attrs |= PTE_DBM | PTE_RDONLY;
@@ -372,7 +369,7 @@ static void count_range(u64 virt, u64 size, int level, int
*cntp)
for (i = idx; size; i++) {
u64 next_size;
- if (level >= gd->arch.first_block_level &&
+ if (level >= 1 &&
size >= map_size && !(virt & (map_size - 1))) {
virt += map_size;
size -= map_size;
@@ -413,13 +410,10 @@ __weak u64 get_page_table_size(void)
u64 size, mmfr1;
asm volatile("mrs %0, id_aa64mmfr1_el1" : "=r" (mmfr1));
- if ((mmfr1 & 0xf) == 2) {
+ if ((mmfr1 & 0xf) == 2)
gd->arch.has_hafdbs = true;
- gd->arch.first_block_level = 2;
- } else {
+ else
gd->arch.has_hafdbs = false;
- gd->arch.first_block_level = 1;
- }
/* Account for all page tables we would need to cover our memory map */
size = one_pt * count_ranges();
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index b385bae02669..1325b0644248 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -52,7 +52,6 @@ struct arch_global_data {
#if defined(CONFIG_ARM64)
unsigned long tlb_fillptr;
unsigned long tlb_emerg;
- unsigned int first_block_level;
bool has_hafdbs;
#endif
#endif
--
2.42.0
[PATCH 3/3] Revert "arm64: Use FEAT_HAFDBS to track dirty pages when available"
This reverts commit 6cdf6b7a340db4ddd008516181de7e08e3f8c213. This is
part of a series trying to make use of the arm64 hardware features for
tracking dirty pages. Unfortunately this series causes problems for the
AC5/AC5X SoCs. Having exhausted other options the consensus seems to be
reverting this series is the best course of action.
Signed-off-by: Chris Packham
---
arch/arm/cpu/armv8/cache_v8.c | 16 +---
arch/arm/include/asm/armv8/mmu.h | 14 --
arch/arm/include/asm/global_data.h | 1 -
3 files changed, 5 insertions(+), 26 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index 4760064ee18f..697334086fdc 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -93,8 +93,6 @@ u64 get_tcr(u64 *pips, u64 *pva_bits)
if (el == 1) {
tcr = TCR_EL1_RSVD | (ips << 32) | TCR_EPD1_DISABLE;
- if (gd->arch.has_hafdbs)
- tcr |= TCR_HA | TCR_HD;
} else if (el == 2) {
tcr = TCR_EL2_RSVD | (ips << 16);
} else {
@@ -202,9 +200,6 @@ static void __cmo_on_leaves(void (*cmo_fn)(unsigned long,
unsigned long),
attrs != PTE_BLOCK_MEMTYPE(MT_NORMAL_NC))
continue;
- if (gd->arch.has_hafdbs && (pte & (PTE_RDONLY | PTE_DBM)) !=
PTE_DBM)
- continue;
-
end = va + BIT(level2shift(level)) - 1;
/* No intersection with RAM? */
@@ -353,9 +348,6 @@ static void add_map(struct mm_region *map)
if (va_bits < 39)
level = 1;
- if (gd->arch.has_hafdbs)
- attrs |= PTE_DBM | PTE_RDONLY;
-
map_range(map->virt, map->phys, map->size, level,
(u64 *)gd->arch.tlb_addr, attrs);
}
@@ -407,13 +399,7 @@ static int count_ranges(void)
__weak u64 get_page_table_size(void)
{
u64 one_pt = MAX_PTE_ENTRIES * sizeof(u64);
- u64 size, mmfr1;
-
- asm volatile("mrs %0, id_aa64mmfr1_el1" : "=r" (mmfr1));
- if ((mmfr1 & 0xf) == 2)
- gd->arch.has_hafdbs = true;
- else
- gd->arch.has_hafdbs = false;
+ u64 size;
/* Account for all page tables we would need to cover our memory map */
size = one_pt * count_ranges();
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index 98a27db3166b..9f58cedb650c 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -49,13 +49,10 @@
#define PTE_TYPE_BLOCK (1 << 0)
#define PTE_TYPE_VALID (1 << 0)
-#define PTE_RDONLY BIT(7)
-#define PTE_DBMBIT(51)
-
-#define PTE_TABLE_PXN BIT(59)
-#define PTE_TABLE_XN BIT(60)
-#define PTE_TABLE_AP BIT(61)
-#define PTE_TABLE_NS BIT(63)
+#define PTE_TABLE_PXN (1UL << 59)
+#define PTE_TABLE_XN (1UL << 60)
+#define PTE_TABLE_AP (1UL << 61)
+#define PTE_TABLE_NS (1UL << 63)
/*
* Block
@@ -102,9 +99,6 @@
#define TCR_TG0_16K(2 << 14)
#define TCR_EPD1_DISABLE (1 << 23)
-#define TCR_HA BIT(39)
-#define TCR_HD BIT(40)
-
#define TCR_EL1_RSVD (1U << 31)
#define TCR_EL2_RSVD (1U << 31 | 1 << 23)
#define TCR_EL3_RSVD (1U << 31 | 1 << 23)
diff --git a/arch/arm/include/asm/global_data.h
b/arch/arm/include/asm/global_data.h
index 1325b0644248..75bd9d56f893 100644
--- a/arch/arm/include/asm/global_data.h
+++ b/arch/arm/include/asm/global_data.h
@@ -52,7 +52,6 @@ struct arch_global_data {
#if defined(CONFIG_ARM64)
unsigned long tlb_fillptr;
unsigned long tlb_emerg;
- bool has_hafdbs;
#endif
#endif
#ifdef CFG_SYS_MEM_RESERVE_SECURE
--
2.42.0
[PATCH] arm: mvebu: AC5: Use finer grained memory map
The ATF implementation for AC5/AC5X ends up with bl31 living in some
internal SRAM. This is in the middle of the large MMIO region that we
were using. Adjust this to be finer grained blocks based on the address
map from the AC5X Family Control and Management Subsystem Functional
Datasheet.
Signed-off-by: Chris Packham
---
arch/arm/mach-mvebu/alleycat5/cpu.c | 66 ++---
1 file changed, 51 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-mvebu/alleycat5/cpu.c
b/arch/arm/mach-mvebu/alleycat5/cpu.c
index 8204d9627515..0f72ae1709be 100644
--- a/arch/arm/mach-mvebu/alleycat5/cpu.c
+++ b/arch/arm/mach-mvebu/alleycat5/cpu.c
@@ -16,7 +16,10 @@
DECLARE_GLOBAL_DATA_PTR;
-#define RAM_SIZE SZ_1G
+#define AC5_PTE_BLOCK_DEVICE \
+ (PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) | \
+PTE_BLOCK_NON_SHARE | \
+PTE_BLOCK_PXN | PTE_BLOCK_UXN)
static struct mm_region ac5_mem_map[] = {
{
@@ -31,30 +34,63 @@ static struct mm_region ac5_mem_map[] = {
.phys = 0x,
.virt = 0xa000,
.size = 0x10,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
/* MMIO regions */
.phys = 0x10,
.virt = 0x10,
.size = 0x3ff0,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
- /* MMIO regions */
.phys = 0x7F00,
.virt = 0x7F00,
- .size = 0x2100,
-
- .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE |
-PTE_BLOCK_PXN | PTE_BLOCK_UXN
+ .size = SZ_8M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7F80,
+ .virt = 0x7F80,
+ .size = SZ_4M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FC0,
+ .virt = 0x7FC0,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FC8,
+ .virt = 0x7FC8,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FD0,
+ .virt = 0x7FD0,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ /* ATF region 0x7FE0-0x7FE2 not mapped */
+ {
+ .phys = 0x7FE8,
+ .virt = 0x7FE8,
+ .size = SZ_512K,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x7FFF,
+ .virt = 0x7FFF,
+ .size = SZ_1M,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
+ },
+ {
+ .phys = 0x8000,
+ .virt = 0x8000,
+ .size = SZ_2G,
+ .attrs = AC5_PTE_BLOCK_DEVICE,
},
{
0,
--
2.42.0
Re: [PATCH] arm: mvebu: AC5: Use finer grained memory map
Hi Tom, On Fri, 27 Oct 2023, 1:54 pm Tom Rini, wrote: > On Fri, Oct 27, 2023 at 01:44:11PM +1300, Chris Packham wrote: > > > The ATF implementation for AC5/AC5X ends up with bl31 living in some > > internal SRAM. This is in the middle of the large MMIO region that we > > were using. Adjust this to be finer grained blocks based on the address > > map from the AC5X Family Control and Management Subsystem Functional > > Datasheet. > > > > Signed-off-by: Chris Packham > > Does this mean we don't need to revert that other patch, or is this > unrelated? Thanks. > Unrelated. Just something I found along the way. I had hope it would fix the hang but with or without this change the HAFDBS support causes issues for me. >
[PATCH 1/2] ARM64: dts: marvell: cn9310: Use appropriate label for spi1 pins
The CN9130-DB uses the SPI1 interface but had the pinctrl node labelled
as "cp0_spi0_pins". Use the label "cp0_spi1_pins" and update the node
name to "cp0-spi-pins-1" to avoid confusion with the pinctrl options for
SPI0.
Signed-off-by: Chris Packham
---
arch/arm/dts/cn9130-db.dtsi | 2 +-
arch/arm/dts/cn9130.dtsi| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/dts/cn9130-db.dtsi b/arch/arm/dts/cn9130-db.dtsi
index 1b28732ee752..4b21ff46d507 100644
--- a/arch/arm/dts/cn9130-db.dtsi
+++ b/arch/arm/dts/cn9130-db.dtsi
@@ -183,7 +183,7 @@
/* U55 */
&cp0_spi1 {
pinctrl-names = "default";
- pinctrl-0 = <&cp0_spi0_pins>;
+ pinctrl-0 = <&cp0_spi1_pins>;
reg = <0x700680 0x50>, /* control */
<0x200 0x100>,/* CS0 */
<0 0x>, /* CS1 */
diff --git a/arch/arm/dts/cn9130.dtsi b/arch/arm/dts/cn9130.dtsi
index 68b767a70639..efcb2e906b91 100644
--- a/arch/arm/dts/cn9130.dtsi
+++ b/arch/arm/dts/cn9130.dtsi
@@ -66,7 +66,7 @@
marvell,pins = < 56 57 58 59 60 61 >;
marvell,function = <14>;
};
- cp0_spi0_pins: cp0-spi-pins-0 {
+ cp0_spi1_pins: cp0-spi-pins-1 {
marvell,pins = < 13 14 15 16 >;
marvell,function = <3>;
};
--
2.41.0
[PATCH 2/2] ARM64: dts: marvell: cn9310-crb: Remove duplicate pinctrl
The cn9130.dtsi defines a pinctrl node for SPI1 (until recently it was
mislabeled as spi0). Use this instead of having a duplicate definition
with a different label.
Signed-off-by: Chris Packham
---
arch/arm/dts/cn9130-crb.dtsi | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/arch/arm/dts/cn9130-crb.dtsi b/arch/arm/dts/cn9130-crb.dtsi
index b229725184a9..7dd36cae282b 100644
--- a/arch/arm/dts/cn9130-crb.dtsi
+++ b/arch/arm/dts/cn9130-crb.dtsi
@@ -125,11 +125,6 @@
marvell,function = <0>;
};
- cp0_spi1_pins_crb: cp0-spi-pins-crb {
- marvell,pins = < 13 14 15 16 >;
- marvell,function = <3>;
- };
-
cp0_smi_pins_crb: cp0-smi-pins-crb {
marvell,pins = < 40 41 >;
marvell,function = <8>;
@@ -170,7 +165,7 @@
&cp0_spi1 {
pinctrl-names = "default";
- pinctrl-0 = <&cp0_spi1_pins_crb>;
+ pinctrl-0 = <&cp0_spi1_pins>;
reg = <0x700680 0x50>, /* control */
<0x200 0x100>,/* CS0 */
<0 0x>, /* CS1 */
--
2.41.0
[PATCH 1/7] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
---
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 66 ++--
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..07919d6d35 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -513,10 +517,19 @@ static void mvneta_rxq_desc_num_update(struct mvneta_port
*pp,
static struct mvneta_rx_desc *
mvneta_rxq_next_desc_get(struct mvneta_rx_queue *rxq)
{
+ struct mvneta_rx_desc *curr;
int rx_desc = rxq->next_desc_to_proc;
+ /* validate RX descriptor */
+ curr = rxq->descs + rx_desc;
+ if (curr->data_size == 0) {
+ /* do it to read real descriptor next time */
+ DSB;
+ return NULL;
+ }
+
rxq->next_desc_to_proc = MVNETA_QUEUE_NEXT_DESC(rxq, rx_desc);
- return rxq->descs + rx_desc;
+ return curr;
}
/* Tx descriptors helper methods */
@@ -1343,6 +1356,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1508,11 +1544,15 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
*/
rx_desc = mvneta_rxq_next_desc_get(rxq);
+ if (!rx_desc)
+ return 0;
+
rx_status = rx_desc->status;
if (!mvneta_rxq_desc_is_first_last(rx_status) ||
(rx_status & MVNETA_RXD_ERR_SUMMARY)) {
mvneta_rx_error(pp, rx_desc);
- /* leave the descriptor untouched */
+ /* invalidate the descriptor */
+ rx_desc->data_size = 0;
return -EIO;
}
@@ -1525,13 +1565,15 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
* since only one was processed
*/
mvneta_rxq_desc_num_update(pp, rxq, 1, 1);
+ /* invalidate the descriptor */
+ rx_desc->data_size = 0;
}
return rx_bytes;
@@ -1544,6 +1586,11 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sfp_args;
#endif
[PATCH 2/7] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
---
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 57 +++--
2 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0f48f09a7..628078f495 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..7d859b9cce 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,15 +149,28 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
((uintptr_t)hccr + HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
debug("ehci-marvell: init hccr %lx and hcor %lx hc_length %ld\n",
- (uintptr_t)hccr, (uintptr_t)hcor,
- (uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+ (uintptr_t)hccr, (uintptr_t)hcor,
+ (uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+
[PATCH 3/7] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham --- drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.37.3
[PATCH 4/7] misc: mvebu: Add sample at reset driver
Add a new UCLASS_SAR, the generic SAR code and an Alleycat5 driver. This
has been adapted from the Marvell SDK but only the AC5 driver has been
brought through (other drivers exist for the ap806, ap807 and cp110 IP
blocks).
Signed-off-by: Chris Packham
---
drivers/misc/Kconfig| 6 ++
drivers/misc/Makefile | 1 +
drivers/misc/mvebu_sar/Makefile | 4 +
drivers/misc/mvebu_sar/ac5_sar.c| 119 +++
drivers/misc/mvebu_sar/sar-uclass.c | 146
include/dm/uclass-id.h | 1 +
include/fdtdec.h| 4 +
include/mvebu/mvebu_chip_sar.h | 73 ++
include/mvebu/sar.h | 57 +++
include/mvebu/var.h | 28 ++
include/sar-uclass.h| 23 +
lib/fdtdec.c| 6 +-
12 files changed, 467 insertions(+), 1 deletion(-)
create mode 100644 drivers/misc/mvebu_sar/Makefile
create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c
create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c
create mode 100644 include/mvebu/mvebu_chip_sar.h
create mode 100644 include/mvebu/sar.h
create mode 100644 include/mvebu/var.h
create mode 100644 include/sar-uclass.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a6da6e215d..4e99ef29d9 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -645,4 +645,10 @@ config SL28CPLD
the base driver which provides common access methods for the
sub-drivers.
+config MVEBU_SAR
+ bool "MVEBU SAR driver"
+ depends on ARCH_MVEBU
+ help
+ Support MVEBU SAR driver
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d494639cd9..3cf976edd8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_NUVOTON_NCT6102D) += nuvoton_nct6102d.o
obj-$(CONFIG_P2SB) += p2sb-uclass.o
obj-$(CONFIG_PCA9551_LED) += pca9551_led.o
obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o
+obj-$(CONFIG_MVEBU_SAR) += mvebu_sar/
ifdef CONFIG_QFW
obj-y += qfw.o
obj-$(CONFIG_QFW_PIO) += qfw_pio.o
diff --git a/drivers/misc/mvebu_sar/Makefile b/drivers/misc/mvebu_sar/Makefile
new file mode 100644
index 00..6f339fb7b4
--- /dev/null
+++ b/drivers/misc/mvebu_sar/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_MVEBU_SAR) += sar-uclass.o
+obj-$(CONFIG_ALLEYCAT_5) += ac5_sar.o
diff --git a/drivers/misc/mvebu_sar/ac5_sar.c b/drivers/misc/mvebu_sar/ac5_sar.c
new file mode 100644
index 00..67b2110bc8
--- /dev/null
+++ b/drivers/misc/mvebu_sar/ac5_sar.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Marvell International Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define MHz100
+
+#define BIT_VAL(b) ((1ULL << ((b) + 1)) - 1)
+#define BIT_RANGE(Bl, Bh) (BIT_VAL(Bh) - BIT_VAL((Bl) - 1))
+
+#define PLL_MAX_CHOICE 4
+
+#define CPU_TYPE_AC50
+#define CPU_TYPE_AC5x 1
+#define CPU_TYPE_LAST 2
+
+static const u32 pll_freq_tbl[CPU_TYPE_LAST][SAR_AP_FABRIC_FREQ +
1][PLL_MAX_CHOICE] = {
+ [CPU_TYPE_AC5] = {
+ [SAR_CPU_FREQ] = {
+ 800 * MHz, 1200 * MHz, 1400 * MHz, 1000 * MHz
+ },
+ [SAR_DDR_FREQ] = {
+ 1200 * MHz, 800 * MHz, 0, 0
+ },
+ [SAR_AP_FABRIC_FREQ] = {
+ 396 * MHz, 290 * MHz, 197 * MHz, 0
+ },
+ },
+ [CPU_TYPE_AC5x] = {
+ [SAR_CPU_FREQ] = {
+ 800 * MHz, 1200 * MHz, 1500 * MHz, 1600 * MHz
+ },
+ [SAR_DDR_FREQ] = {
+ 1200 * MHz, 800 * MHz, 0, 0
+ },
+ [SAR_AP_FABRIC_FREQ] = {
+ 0, 0, 0, 0
+ }
+ }
+};
+
+static const u32 soc_sar_masks_tbl[CPU_TYPE_LAST][SAR_AP_FABRIC_FREQ + 1] = {
+ [CPU_TYPE_AC5] = {
+ [SAR_CPU_FREQ] = BIT_RANGE(18, 20),
+ [SAR_DDR_FREQ] = BIT_RANGE(16, 17),
+ [SAR_AP_FABRIC_FREQ] = BIT_RANGE(22, 23),
+ },
+ [CPU_TYPE_AC5x] = {
+ [SAR_CPU_FREQ] = BIT_RANGE(8, 10),
+ [SAR_DDR_FREQ] = BIT_RANGE(6, 7),
+ [SAR_AP_FABRIC_FREQ] = 1,
+ },
+};
+
+static int ac5_sar_value_get(struct udevice *dev, enum mvebu_sar_opts sar_opt,
+struct sar_val *val)
+{
+ u32 *pSarBase = (u32 *)(((struct dm_sar_pdata
*)dev_get_priv(dev))->sar_base);
+ u32 sar_reg_val = readl(pSarBase);
+ u32 mask;
+ unsigned char choice;
+ int cpu_type = ((readl(0x7f90004c) & 0xFF000) >> 12) == 0x98 ?
CPU_TYPE_AC5x : CPU_TYPE_AC5;
+
+ if (sar_opt > SAR_AP_FABRIC_FREQ) {
+ pr_err("AC5-SAR: Unsupported SAR option %d.\n"
[PATCH 6/7] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and features
include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host port
(shared with PCIe)
Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ Port 48
(Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 155 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 35 +
configs/mvebu_ac5_rd_defconfig | 89
include/configs/mvebu_alleycat-5.h | 92
8 files changed, 390 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7330121dba..a334596ada 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..94eadd6f71
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,155 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 = &uart0;
+ spiflash0 = &spiflash0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ spi0 = &spi0;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ pinctrl0 = &pinctrl0;
+ sar-reg0 = "/config-space/sar-reg";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x2 0x 0x0 0x4000>;
+ };
+
+ usb1phy: usb-phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ config-space {
+ sar-reg {
+ reg = <0x944F8204 0x1>;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&mdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+ð0 {
+ status = "okay";
+ phy-handle = <&phy0>;
+};
+
+/* USB0 is a host USB */
+&usb0 {
+ status = "okay";
+};
+
+/* USB1 is a peripheral USB */
[PATCH 5/7] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx25xx.dtsi | 292 +++
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig | 5 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 9 +
arch/arm/mach-mvebu/alleycat5/clock.c| 49
arch/arm/mach-mvebu/alleycat5/cpu.c | 129 ++
arch/arm/mach-mvebu/alleycat5/soc.c | 229 ++
arch/arm/mach-mvebu/arm64-common.c | 15 ++
arch/arm/mach-mvebu/include/mach/clock.h | 11 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
arch/arm/mach-mvebu/include/mach/soc.h | 4 +
12 files changed, 765 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/include/mach/clock.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..c31d2f08cf
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ config-space {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ sar-reg {
+ compatible = "marvell,sample-at-reset-common";
+ sar-driver = "ac5_sar";
+ sar-name = "ac5_sar";
+ status = "okay";
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges = <0x0 0x0 0x7f00 0x100>;
+ dma-coherent;
+
+ uart0: serial@12000 {
+ compatible = "snps,dw-apb-uart";
+
[PATCH 7/7] tools: kwboot: Add knowledge of Marvell's TIM
Marvell's proprietary TIM (trusted image) is used on the Armada-3700 and
AlledCat5/5X (and possibly others). It has a whole host of features that
work to implement a version of secure boot.
Kwboot's interest in this format is simply to detect that the image is
one of these and not attempt to patch it (the images will work over UART
boot as-is). This is done by checking for a specific magic value
("TIMH") in the first 32bits of the image.
Signed-off-by: Chris Packham
---
It might be possible to make the check more robust by validating more of
the image. There is a checksum field that might be useful for this
purpose. I haven't done this as I couldn't figure out Marvell's
validation of this field.
tools/kwbimage.h | 29 +
tools/kwboot.c | 3 +++
2 files changed, 32 insertions(+)
diff --git a/tools/kwbimage.h b/tools/kwbimage.h
index 505522332b..8aab26952a 100644
--- a/tools/kwbimage.h
+++ b/tools/kwbimage.h
@@ -224,6 +224,28 @@ struct register_set_hdr_v1 {
#define OPT_HDR_V1_BINARY_TYPE 0x2
#define OPT_HDR_V1_REGISTER_TYPE 0x3
+/* TIM (trusted image), Armada 3700, AlleyCat5 */
+struct tim_block_hdr {
+ uint32_t signature_id;
+ uint16_t opcode;
+ uint16_t blocksize;
+} __packed;
+
+struct tim_hdr {
+ struct tim_block_hdr hdr;
+ uint32_t trusted;
+ uint32_t signed_tim_size;
+ uint32_t unsigned_tim_size;
+ uint32_t unique_id;
+ uint64_t loadaddr;
+ uint32_t flags;
+ uint32_t software_prot_version;
+ uint32_t num_blocks;
+ uint32_t checksum;
+} __packed;
+
+#define TIM_HDR_SIGNATURE 0x54494d48 /* "TIMH" */
+
/*
* Byte 8 of the image header contains the version number. In the v0
* header, byte 8 was reserved, and always set to 0. In the v1 header,
@@ -270,6 +292,13 @@ static inline size_t kwbheader_size_for_csum(const void
*header)
return kwbheader_size(header);
}
+static inline bool kwbimage_is_tim(void *img)
+{
+ const struct tim_hdr *hdr = img;
+
+ return le32_to_cpu(hdr->hdr.signature_id) == TIM_HDR_SIGNATURE;
+}
+
static inline struct ext_hdr_v0 *ext_hdr_v0_first(void *img)
{
struct main_hdr_v0 *mhdr;
diff --git a/tools/kwboot.c b/tools/kwboot.c
index da4fe32da2..a9b3d0fd04 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -1869,6 +1869,9 @@ kwboot_img_patch(void *img, size_t *size, int baudrate)
if (*size < sizeof(struct main_hdr_v1))
goto err;
+ if (kwbimage_is_tim(img))
+ return 0;
+
image_ver = kwbimage_version(img);
if (image_ver != 0 && image_ver != 1) {
fprintf(stderr, "Invalid image header version\n");
--
2.37.3
Re: [PATCH 7/7] tools: kwboot: Add knowledge of Marvell's TIM
On Fri, 16 Sep 2022, 8:12 PM Pali Rohár, wrote:
> Hello! I think it does not make sense to hack kwboot to skip validation
> of kwbimage format when ad-hoc TIM header is detected. kwboot has now
> lot of features which requires and expects valid kwbimage format and is
> now written to work specially with 32-bit mvebu ARM BootROMs.
>
> TIM and kwbimage are totally different formats and it really does not
> make sense to starting rewriting kwboot to support also other format.
> Instead it would be better to write other dedicated tool for it.
>
> For example, there is already tool mox-imager [1], which despite its
> name supports all A3720 BootROMS and mvebu64boot [2] which supports
> A70x0, A80x0 and CN9130 BootROMS.
>
> [1] - https://gitlab.nic.cz/turris/mox-imager
> [2] - https://github.com/pali/mvebu64boot
Yeah I tend to agree.
Mvebu64boot would fit better since this is a 64 bit Marveel SoC but again
I'd have to teach it about TIM. One reason I went with kwboot (aside from
not knowing anything else existed) was that the hand off between the uart
boot sequence and the xmodem was awkward with the "official" methods (2
different transfer with 2 different protocols).
I do wonder if the boot seqence and xmodem stuff could be abstracted out to
something that could be reused by other tools.
I the short term at least I'll drop this out of the series.
>
> On Friday 16 September 2022 16:54:23 Chris Packham wrote:
> > Marvell's proprietary TIM (trusted image) is used on the Armada-3700 and
> > AlledCat5/5X (and possibly others). It has a whole host of features that
> > work to implement a version of secure boot.
> >
> > Kwboot's interest in this format is simply to detect that the image is
> > one of these and not attempt to patch it (the images will work over UART
> > boot as-is). This is done by checking for a specific magic value
> > ("TIMH") in the first 32bits of the image.
> >
> > Signed-off-by: Chris Packham
> > ---
> > It might be possible to make the check more robust by validating more of
> > the image. There is a checksum field that might be useful for this
> > purpose. I haven't done this as I couldn't figure out Marvell's
> > validation of this field.
> >
> > tools/kwbimage.h | 29 +
> > tools/kwboot.c | 3 +++
> > 2 files changed, 32 insertions(+)
> >
> > diff --git a/tools/kwbimage.h b/tools/kwbimage.h
> > index 505522332b..8aab26952a 100644
> > --- a/tools/kwbimage.h
> > +++ b/tools/kwbimage.h
> > @@ -224,6 +224,28 @@ struct register_set_hdr_v1 {
> > #define OPT_HDR_V1_BINARY_TYPE 0x2
> > #define OPT_HDR_V1_REGISTER_TYPE 0x3
> >
> > +/* TIM (trusted image), Armada 3700, AlleyCat5 */
> > +struct tim_block_hdr {
> > + uint32_t signature_id;
> > + uint16_t opcode;
> > + uint16_t blocksize;
> > +} __packed;
> > +
> > +struct tim_hdr {
> > + struct tim_block_hdr hdr;
> > + uint32_t trusted;
> > + uint32_t signed_tim_size;
> > + uint32_t unsigned_tim_size;
> > + uint32_t unique_id;
> > + uint64_t loadaddr;
> > + uint32_t flags;
> > + uint32_t software_prot_version;
> > + uint32_t num_blocks;
> > + uint32_t checksum;
> > +} __packed;
> > +
> > +#define TIM_HDR_SIGNATURE0x54494d48 /* "TIMH" */
> > +
> > /*
> > * Byte 8 of the image header contains the version number. In the v0
> > * header, byte 8 was reserved, and always set to 0. In the v1 header,
> > @@ -270,6 +292,13 @@ static inline size_t kwbheader_size_for_csum(const
> void *header)
> > return kwbheader_size(header);
> > }
> >
> > +static inline bool kwbimage_is_tim(void *img)
> > +{
> > + const struct tim_hdr *hdr = img;
> > +
> > + return le32_to_cpu(hdr->hdr.signature_id) == TIM_HDR_SIGNATURE;
> > +}
> > +
> > static inline struct ext_hdr_v0 *ext_hdr_v0_first(void *img)
> > {
> > struct main_hdr_v0 *mhdr;
> > diff --git a/tools/kwboot.c b/tools/kwboot.c
> > index da4fe32da2..a9b3d0fd04 100644
> > --- a/tools/kwboot.c
> > +++ b/tools/kwboot.c
> > @@ -1869,6 +1869,9 @@ kwboot_img_patch(void *img, size_t *size, int
> baudrate)
> > if (*size < sizeof(struct main_hdr_v1))
> > goto err;
> >
> > + if (kwbimage_is_tim(img))
> > + return 0;
> > +
> > image_ver = kwbimage_version(img);
> > if (image_ver != 0 && image_ver != 1) {
> > fprintf(stderr, "Invalid image header version\n");
> > --
> > 2.37.3
> >
>
[PATCH 0/7] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X which was based on u-boot 2018.03. I've split that code into consumable chunks and dropped as much unnecessary stuff as I can. I've also tried to sync the device trees as much as possible with the support that will land in Linux 6.0 although there are still some differences Chris Packham (7): net: mvneta: Add support for AlleyCat5 usb: ehci: ehci-marvell: Support for marvell,ac5-ehci pinctrl: mvebu: Add AlleyCat5 support misc: mvebu: Add sample at reset driver arm: mvebu: Support for 98DX25xx/98DX35xx SoC arm: mvebu: Add RD-AC5X board tools: kwboot: Add knowledge of Marvell's TIM arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 292 + arch/arm/dts/ac5-98dx35xx-rd.dts | 155 +++ arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++ arch/arm/mach-mvebu/Kconfig| 14 +- arch/arm/mach-mvebu/Makefile | 1 + arch/arm/mach-mvebu/alleycat5/Makefile | 9 + arch/arm/mach-mvebu/alleycat5/clock.c | 49 arch/arm/mach-mvebu/alleycat5/cpu.c| 129 + arch/arm/mach-mvebu/alleycat5/soc.c| 229 arch/arm/mach-mvebu/arm64-common.c | 15 ++ arch/arm/mach-mvebu/include/mach/clock.h | 11 + arch/arm/mach-mvebu/include/mach/cpu.h | 4 + arch/arm/mach-mvebu/include/mach/soc.h | 4 + board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + board/Marvell/mvebu_alleycat-5/Makefile| 3 + board/Marvell/mvebu_alleycat-5/board.c | 35 +++ configs/mvebu_ac5_rd_defconfig | 89 +++ drivers/misc/Kconfig | 6 + drivers/misc/Makefile | 1 + drivers/misc/mvebu_sar/Makefile| 4 + drivers/misc/mvebu_sar/ac5_sar.c | 119 + drivers/misc/mvebu_sar/sar-uclass.c| 146 +++ drivers/net/Kconfig| 2 +- drivers/net/mvneta.c | 66 - drivers/pinctrl/mvebu/Kconfig | 2 +- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-marvell.c| 57 +++- include/configs/mvebu_alleycat-5.h | 92 +++ include/dm/uclass-id.h | 1 + include/fdtdec.h | 4 + include/mvebu/mvebu_chip_sar.h | 73 ++ include/mvebu/sar.h| 57 include/mvebu/var.h| 28 ++ include/sar-uclass.h | 23 ++ lib/fdtdec.c | 6 +- tools/kwbimage.h | 29 ++ tools/kwboot.c | 3 + 38 files changed, 1767 insertions(+), 18 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c create mode 100644 arch/arm/mach-mvebu/include/mach/clock.h create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile create mode 100644 board/Marvell/mvebu_alleycat-5/board.c create mode 100644 configs/mvebu_ac5_rd_defconfig create mode 100644 drivers/misc/mvebu_sar/Makefile create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c create mode 100644 include/configs/mvebu_alleycat-5.h create mode 100644 include/mvebu/mvebu_chip_sar.h create mode 100644 include/mvebu/sar.h create mode 100644 include/mvebu/var.h create mode 100644 include/sar-uclass.h -- 2.37.3
Re: [PATCH 6/7] arm: mvebu: Add RD-AC5X board
On Fri, 16 Sep 2022, 10:58 PM Pali Rohár, wrote:
> On Friday 16 September 2022 16:54:22 Chris Packham wrote:
> > +&spi0 {
> > + status = "okay";
> > +
> > + spiflash0: flash@0 {
> > + compatible = "jedec,spi-nor";
> > + spi-max-frequency = <5000>;
> > + spi-tx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */
> > + spi-rx-bus-width = <1>; /* 1-single, 2-dual, 4-quad */
> > + reg = <0>;
> > +
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > +
> > + partition@0 {
> > + label = "spi_flash_part0";
>
> I guess such label is useless. There is something stored, so it would be
> a wise idea to put there correct label. I do not know how it is on this
> platform, but on A3720 at offset 0 is "firmware", which consist of CM3
> part, A53 part and U-Boot. It is not even U-Boot itself.
>
These are the names from the Linux SDK for the board. The first part will
be the bootloader (mvddr+atf+u-boot). Somewhere in there is also the u-boot
environment. I'm tempted just to drop the partitions altogether, they don't
do anything useful for u-boot.
>
> > + reg = <0x0 0x80>;
> > + };
> > +
> > + parition@1 {
> > + label = "spi_flash_part1";
> > + reg = <0x80 0x70>;
> > + };
> > +
> > + parition@2 {
> > + label = "spi_flash_part2";
> > + reg = <0xF0 0x10>;
> > + };
> > + };
> > +};
>
> ...
>
> > +/* Default Env vars */
> > +#define CONFIG_IPADDR 0.0.0.0 /* In order to cause an error */
> > +#define CONFIG_SERVERIP 0.0.0.0 /* In order to cause an error */
> > +#define CONFIG_NETMASK 255.255.255.0
> > +#define CONFIG_GATEWAYIP0.0.0.0
> > +#define CONFIG_ETHPRIME "eth0"
> > +#define CONFIG_ROOTPATH "/srv/nfs/" /* Default Dir for
> NFS */
> > +#define CONFIG_ENV_OVERWRITE/* ethaddr can be reprogrammed */
> > +#define CONFIG_EXTRA_ENV_SETTINGS "bootcmd=run get_images; " \
> > + "run set_bootargs; " \
> > + "booti $kernel_addr_r " \
> > + "$ramdisk_addr_r " \
> > + "$fdt_addr_r\0" \
> > + "extra_params=pci=pcie_bus_safe\0" \
> > + "kernel_addr_r=0x20200\0" \
> > + "initrd_addr=0x20600\0"\
> > + "initrd_size=0x200\0" \
> > + "fdt_addr_r=0x20100\0"\
> > + "loadaddr=0x20200\0" \
> > + "hostname=marvell\0"\
> > + "ramdisk_addr_r=0x20600\0"\
> > + "ramfs_name=-\0"\
> > + "cpuidle=cpuidle.off=1\0" \
> > + "fdt_name=fdt.dtb\0"\
> > + "netdev=eth0\0" \
> > + "ethaddr=00:51:82:11:22:00\0" \
> > + "eth1addr=00:51:82:11:22:01\0" \
> > + "image_name=Image\0"\
> > + "get_ramfs=if test \"${ramfs_name}\"" \
> > + " != \"-\"; then setenv " \
> > + "ramdisk_addr_r 0x800; " \
> > + "tftpboot $ramdisk_addr_r " \
> > + "$ramfs_name; else setenv " \
> > + "ramdisk_addr_r -;fi\0" \
> > + "get_images=tftpboot $kernel_addr_r " \
> > + "$image_name; tftpboot " \
> > + "$fdt_addr_r $fdt_name; " \
> > + "run get_ramfs\0" \
> > + "console=" "console=ttyS0,115200 "\
> > + "earlycon=uart8250,mmio32,0xf0512000\0"\
> > + "root=root=/dev/nfs rw\0" \
> > + "set_bootargs=setenv bootargs $console"\
> > + " $root ip=$ipaddr:$serverip:" \
> > + "$gatewayip:$netmask:$hostname"\
> > + ":$netdev:none nfsroot="\
> > + "$serverip:$rootpath,tcp,v3 " \
> > + "$extra_params " \
> > + "$cpuidle"
>
> This is hard to read, where is the variable name, where there is its
> value, etc...
>
> And it would be better to use distroboot instead of manually written
> boot script.
>
Yep I'll try to clean that up. Again this is straight from the older SDK so
it'snot follow current best practice.
>
Re: [PATCH 7/7] tools: kwboot: Add knowledge of Marvell's TIM
Hi Pali, On Sat, Sep 17, 2022 at 12:37 AM Pali Rohár wrote: > > On Friday 16 September 2022 22:34:52 Chris Packham wrote: > > I do wonder if the boot seqence and xmodem stuff could be abstracted out to > > something that could be reused by other tools. > > In the past I was thinking about it... but I come to the conclusion that > it is easier to write specific tools which implements communication with > just one BootROM. Trying to write one universal thing just opens a lot > of issues and at the end it would do same thing like if you implement N > independent applications and then additional "launcher" application > which starts the correct one. > > It looks like that most Marvell SoCs use xmodem protocol. Except 3720 > which uses WTPTP. But as I figured out, every SoC use slightly modified > protocol based on xmodem. So well, in theory "sx" would work. But if you > want to have other features (like progress bar or bootrom output or > speed change) then all this is bootrom specific and has to be > implemented directly into xmodem state machine. So either you provide N > xmodem implementations or try to create something "hookable" and since > beginning I have feeling that "hooks" would just introduce new bugs and > make it harder to debug. > > > kwboot is currently in the state that it supports kwbimage v0 and > kwbimage v1 formats, which IIRC covers all 32-bit widely used SoCs from > kirkwood, dove, armada and switches which integrates those CPUs, and > probably also avanta. At lot of stages it expects valid kwbimage and > that is why there is validation at the beginning. It injects 32-bit ARM > binary code for changing UART speed and requires above SoC (as it > touches internal registers, which are same on all those mentioned). It > also contains workarounds for bugs in Armada 385 BootROMs. > > I really think that kwboot is now in state when it is not easily > possible to extend it for different platform without lot of energy and > extra testing that it does not break something existing. Having looked more into mox-imager (and WtpDownloader) I've realised that the AlleyCat5 uses something called "TIM" but it's different to the format used by Armada-3700. I suspect what I'm actually dealing with is a TIMv0 that pre-dates the version used by Armada-3700. All the more reason to do something new instead of trying to shoe-horn it into one of the existing places. I'll probably end up making a fork of your mvebu64boot and adapting it (mox-imager just does too much).
Re: [PATCH 7/7] tools: kwboot: Add knowledge of Marvell's TIM
On Mon, Sep 19, 2022 at 11:03 AM Pali Rohár wrote: > > On Monday 19 September 2022 10:57:10 Chris Packham wrote: > > Having looked more into mox-imager (and WtpDownloader) I've realised > > that the AlleyCat5 uses something called "TIM" but it's different to > > the format used by Armada-3700. I suspect what I'm actually dealing > > with is a TIMv0 that pre-dates the version used by Armada-3700. All > > the more reason to do something new instead of trying to shoe-horn it > > into one of the existing places. I'll probably end up making a fork of > > your mvebu64boot and adapting it (mox-imager just does too much). > > Hello! If that AC5 TIM format is different than A3720 TIM then it really > makes sense to create a new tool. Forking mvebu64boot into completely > new project seems like the easiest way how to achieve working tool > without being afraid to break existing support. > > Anyway, is not there any Marvell tool for this AC5 TIM format? Like > A3720 TBB or WtpDownloader? Nope the only official support is send the boot pattern using ascii/raw then send the image using xmodem. Which is what led to me looking for an alternative that can actually tell when the SoC has detected the pattern and hand off to the xmodem download. Supporting the signed images would be a bonus but not for my immediate need for recovering from bad bootloaders.
[PATCH v2 0/6] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X which was based on u-boot 2018.03. I've split that code into consumable chunks and dropped as much unnecessary stuff as I can. I've also tried to sync the device trees as much as possible with the support that will land in Linux 6.0 although there are still some differences Changes in v2: - Use distro boot by default - remove unnecessary SPI-NOR partitions Chris Packham (6): net: mvneta: Add support for AlleyCat5 usb: ehci: ehci-marvell: Support for marvell,ac5-ehci pinctrl: mvebu: Add AlleyCat5 support misc: mvebu: Add sample at reset driver arm: mvebu: Support for 98DX25xx/98DX35xx SoC arm: mvebu: Add RD-AC5X board arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 292 + arch/arm/dts/ac5-98dx35xx-rd.dts | 140 ++ arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++ arch/arm/mach-mvebu/Kconfig| 14 +- arch/arm/mach-mvebu/Makefile | 1 + arch/arm/mach-mvebu/alleycat5/Makefile | 9 + arch/arm/mach-mvebu/alleycat5/clock.c | 49 arch/arm/mach-mvebu/alleycat5/cpu.c| 129 + arch/arm/mach-mvebu/alleycat5/soc.c| 229 arch/arm/mach-mvebu/arm64-common.c | 15 ++ arch/arm/mach-mvebu/include/mach/clock.h | 11 + arch/arm/mach-mvebu/include/mach/cpu.h | 4 + arch/arm/mach-mvebu/include/mach/soc.h | 4 + board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + board/Marvell/mvebu_alleycat-5/Makefile| 3 + board/Marvell/mvebu_alleycat-5/board.c | 35 +++ configs/mvebu_ac5_rd_defconfig | 88 +++ drivers/misc/Kconfig | 6 + drivers/misc/Makefile | 1 + drivers/misc/mvebu_sar/Makefile| 4 + drivers/misc/mvebu_sar/ac5_sar.c | 119 + drivers/misc/mvebu_sar/sar-uclass.c| 146 +++ drivers/net/Kconfig| 2 +- drivers/net/mvneta.c | 66 - drivers/pinctrl/mvebu/Kconfig | 2 +- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-marvell.c| 57 +++- include/configs/mvebu_alleycat-5.h | 71 + include/dm/uclass-id.h | 1 + include/fdtdec.h | 4 + include/mvebu/mvebu_chip_sar.h | 73 ++ include/mvebu/sar.h| 57 include/mvebu/var.h| 28 ++ include/sar-uclass.h | 23 ++ lib/fdtdec.c | 6 +- 36 files changed, 1698 insertions(+), 18 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c create mode 100644 arch/arm/mach-mvebu/include/mach/clock.h create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile create mode 100644 board/Marvell/mvebu_alleycat-5/board.c create mode 100644 configs/mvebu_ac5_rd_defconfig create mode 100644 drivers/misc/mvebu_sar/Makefile create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c create mode 100644 include/configs/mvebu_alleycat-5.h create mode 100644 include/mvebu/mvebu_chip_sar.h create mode 100644 include/mvebu/sar.h create mode 100644 include/mvebu/var.h create mode 100644 include/sar-uclass.h -- 2.37.3
[PATCH v2 1/6] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
---
(no changes since v1)
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 66 ++--
2 files changed, 64 insertions(+), 4 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..07919d6d35 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -513,10 +517,19 @@ static void mvneta_rxq_desc_num_update(struct mvneta_port
*pp,
static struct mvneta_rx_desc *
mvneta_rxq_next_desc_get(struct mvneta_rx_queue *rxq)
{
+ struct mvneta_rx_desc *curr;
int rx_desc = rxq->next_desc_to_proc;
+ /* validate RX descriptor */
+ curr = rxq->descs + rx_desc;
+ if (curr->data_size == 0) {
+ /* do it to read real descriptor next time */
+ DSB;
+ return NULL;
+ }
+
rxq->next_desc_to_proc = MVNETA_QUEUE_NEXT_DESC(rxq, rx_desc);
- return rxq->descs + rx_desc;
+ return curr;
}
/* Tx descriptors helper methods */
@@ -1343,6 +1356,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1508,11 +1544,15 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
*/
rx_desc = mvneta_rxq_next_desc_get(rxq);
+ if (!rx_desc)
+ return 0;
+
rx_status = rx_desc->status;
if (!mvneta_rxq_desc_is_first_last(rx_status) ||
(rx_status & MVNETA_RXD_ERR_SUMMARY)) {
mvneta_rx_error(pp, rx_desc);
- /* leave the descriptor untouched */
+ /* invalidate the descriptor */
+ rx_desc->data_size = 0;
return -EIO;
}
@@ -1525,13 +1565,15 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
* since only one was processed
*/
mvneta_rxq_desc_num_update(pp, rxq, 1, 1);
+ /* invalidate the descriptor */
+ rx_desc->data_size = 0;
}
return rx_bytes;
@@ -1544,6 +1586,11 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sf
[PATCH v2 2/6] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
---
(no changes since v1)
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 57 +++--
2 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0f48f09a7..628078f495 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..7d859b9cce 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,15 +149,28 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
((uintptr_t)hccr + HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
debug("ehci-marvell: init hccr %lx and hcor %lx hc_length %ld\n",
- (uintptr_t)hccr, (uintptr_t)hcor,
- (uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+ (uintptr_t)hccr, (uintptr_t)hcor,
+ (uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci&q
[PATCH v2 3/6] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham --- (no changes since v1) drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.37.3
[PATCH v2 4/6] misc: mvebu: Add sample at reset driver
Add a new UCLASS_SAR, the generic SAR code and an Alleycat5 driver. This
has been adapted from the Marvell SDK but only the AC5 driver has been
brought through (other drivers exist for the ap806, ap807 and cp110 IP
blocks).
Signed-off-by: Chris Packham
---
(no changes since v1)
drivers/misc/Kconfig| 6 ++
drivers/misc/Makefile | 1 +
drivers/misc/mvebu_sar/Makefile | 4 +
drivers/misc/mvebu_sar/ac5_sar.c| 119 +++
drivers/misc/mvebu_sar/sar-uclass.c | 146
include/dm/uclass-id.h | 1 +
include/fdtdec.h| 4 +
include/mvebu/mvebu_chip_sar.h | 73 ++
include/mvebu/sar.h | 57 +++
include/mvebu/var.h | 28 ++
include/sar-uclass.h| 23 +
lib/fdtdec.c| 6 +-
12 files changed, 467 insertions(+), 1 deletion(-)
create mode 100644 drivers/misc/mvebu_sar/Makefile
create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c
create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c
create mode 100644 include/mvebu/mvebu_chip_sar.h
create mode 100644 include/mvebu/sar.h
create mode 100644 include/mvebu/var.h
create mode 100644 include/sar-uclass.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a6da6e215d..4e99ef29d9 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -645,4 +645,10 @@ config SL28CPLD
the base driver which provides common access methods for the
sub-drivers.
+config MVEBU_SAR
+ bool "MVEBU SAR driver"
+ depends on ARCH_MVEBU
+ help
+ Support MVEBU SAR driver
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d494639cd9..3cf976edd8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_NUVOTON_NCT6102D) += nuvoton_nct6102d.o
obj-$(CONFIG_P2SB) += p2sb-uclass.o
obj-$(CONFIG_PCA9551_LED) += pca9551_led.o
obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o
+obj-$(CONFIG_MVEBU_SAR) += mvebu_sar/
ifdef CONFIG_QFW
obj-y += qfw.o
obj-$(CONFIG_QFW_PIO) += qfw_pio.o
diff --git a/drivers/misc/mvebu_sar/Makefile b/drivers/misc/mvebu_sar/Makefile
new file mode 100644
index 00..6f339fb7b4
--- /dev/null
+++ b/drivers/misc/mvebu_sar/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_MVEBU_SAR) += sar-uclass.o
+obj-$(CONFIG_ALLEYCAT_5) += ac5_sar.o
diff --git a/drivers/misc/mvebu_sar/ac5_sar.c b/drivers/misc/mvebu_sar/ac5_sar.c
new file mode 100644
index 00..67b2110bc8
--- /dev/null
+++ b/drivers/misc/mvebu_sar/ac5_sar.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Marvell International Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define MHz100
+
+#define BIT_VAL(b) ((1ULL << ((b) + 1)) - 1)
+#define BIT_RANGE(Bl, Bh) (BIT_VAL(Bh) - BIT_VAL((Bl) - 1))
+
+#define PLL_MAX_CHOICE 4
+
+#define CPU_TYPE_AC50
+#define CPU_TYPE_AC5x 1
+#define CPU_TYPE_LAST 2
+
+static const u32 pll_freq_tbl[CPU_TYPE_LAST][SAR_AP_FABRIC_FREQ +
1][PLL_MAX_CHOICE] = {
+ [CPU_TYPE_AC5] = {
+ [SAR_CPU_FREQ] = {
+ 800 * MHz, 1200 * MHz, 1400 * MHz, 1000 * MHz
+ },
+ [SAR_DDR_FREQ] = {
+ 1200 * MHz, 800 * MHz, 0, 0
+ },
+ [SAR_AP_FABRIC_FREQ] = {
+ 396 * MHz, 290 * MHz, 197 * MHz, 0
+ },
+ },
+ [CPU_TYPE_AC5x] = {
+ [SAR_CPU_FREQ] = {
+ 800 * MHz, 1200 * MHz, 1500 * MHz, 1600 * MHz
+ },
+ [SAR_DDR_FREQ] = {
+ 1200 * MHz, 800 * MHz, 0, 0
+ },
+ [SAR_AP_FABRIC_FREQ] = {
+ 0, 0, 0, 0
+ }
+ }
+};
+
+static const u32 soc_sar_masks_tbl[CPU_TYPE_LAST][SAR_AP_FABRIC_FREQ + 1] = {
+ [CPU_TYPE_AC5] = {
+ [SAR_CPU_FREQ] = BIT_RANGE(18, 20),
+ [SAR_DDR_FREQ] = BIT_RANGE(16, 17),
+ [SAR_AP_FABRIC_FREQ] = BIT_RANGE(22, 23),
+ },
+ [CPU_TYPE_AC5x] = {
+ [SAR_CPU_FREQ] = BIT_RANGE(8, 10),
+ [SAR_DDR_FREQ] = BIT_RANGE(6, 7),
+ [SAR_AP_FABRIC_FREQ] = 1,
+ },
+};
+
+static int ac5_sar_value_get(struct udevice *dev, enum mvebu_sar_opts sar_opt,
+struct sar_val *val)
+{
+ u32 *pSarBase = (u32 *)(((struct dm_sar_pdata
*)dev_get_priv(dev))->sar_base);
+ u32 sar_reg_val = readl(pSarBase);
+ u32 mask;
+ unsigned char choice;
+ int cpu_type = ((readl(0x7f90004c) & 0xFF000) >> 12) == 0x98 ?
CPU_TYPE_AC5x : CPU_TYPE_AC5;
+
+ if (sar_opt > SAR_AP_FABRIC_FREQ) {
+ pr_err("AC5-SAR: Unsupported SAR option %d.
[PATCH v2 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
(no changes since v1)
arch/arm/dts/ac5-98dx25xx.dtsi | 292 +++
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig | 5 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 9 +
arch/arm/mach-mvebu/alleycat5/clock.c| 49
arch/arm/mach-mvebu/alleycat5/cpu.c | 129 ++
arch/arm/mach-mvebu/alleycat5/soc.c | 229 ++
arch/arm/mach-mvebu/arm64-common.c | 15 ++
arch/arm/mach-mvebu/include/mach/clock.h | 11 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
arch/arm/mach-mvebu/include/mach/soc.h | 4 +
12 files changed, 765 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/include/mach/clock.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..c31d2f08cf
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,292 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ config-space {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ sar-reg {
+ compatible = "marvell,sample-at-reset-common";
+ sar-driver = "ac5_sar";
+ sar-name = "ac5_sar";
+ status = "okay";
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges = <0x0 0x0 0x7f00 0x100>;
+ dma-coherent;
+
+ uart0: serial@12000 {
+ compatible = "snps,dw-apb-uart";
+
[PATCH v2 6/6] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and features
include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host port
(shared with PCIe)
Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ Port 48
(Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 140 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 35 ++
configs/mvebu_ac5_rd_defconfig | 88 +
include/configs/mvebu_alleycat-5.h | 71 +++
8 files changed, 353 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7330121dba..a334596ada 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..3b747e722e
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,140 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 = &uart0;
+ spiflash0 = &spiflash0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ spi0 = &spi0;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ pinctrl0 = &pinctrl0;
+ sar-reg0 = "/config-space/sar-reg";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x2 0x 0x0 0x4000>;
+ };
+
+ usb1phy: usb-phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ config-space {
+ sar-reg {
+ reg = <0x944F8204 0x1>;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&mdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
+};
+
+&i2c1 {
+ status = "okay";
+};
+
+ð0 {
+ status = "okay";
+ phy-handle = <&phy0>;
+};
+
+/* USB0 is a
Re: [PATCH v2 1/6] net: mvneta: Add support for AlleyCat5
On Tue, Sep 20, 2022 at 9:17 PM Stefan Roese wrote:
>
> On 20.09.22 10:31, Chris Packham wrote:
> > Add support for the AlleyCat5 SoC. This lacks the mbus from the other
> > users of the mvneta.c driver so a new compatible string is needed to
> > allow for a different window configuration.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > (no changes since v1)
> >
> > drivers/net/Kconfig | 2 +-
> > drivers/net/mvneta.c | 66 ++--
> > 2 files changed, 64 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> > index 6bbbadc5ee..8df3dce6df 100644
> > --- a/drivers/net/Kconfig
> > +++ b/drivers/net/Kconfig
> > @@ -448,7 +448,7 @@ config MVGBE
> >
> > config MVNETA
> > bool "Marvell Armada XP/385/3700 network interface support"
> > - depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
> > + depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
> > select PHYLIB
> > select DM_MDIO
> > help
> > diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
> > index d2c42c4396..07919d6d35 100644
> > --- a/drivers/net/mvneta.c
> > +++ b/drivers/net/mvneta.c
> > @@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
> > #define MVNETA_WIN_SIZE_MASK(0x)
> > #define MVNETA_BASE_ADDR_ENABLE 0x2290
> > #define MVNETA_BASE_ADDR_ENABLE_BIT0x1
> > +#define MVNETA_AC5_CNM_DDR_TARGET 0x2
> > +#define MVNETA_AC5_CNM_DDR_ATTR 0xb
> > #define MVNETA_PORT_ACCESS_PROTECT 0x2294
> > #define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW 0x3
> > #define MVNETA_PORT_CONFIG 0x2400
> > @@ -282,6 +284,8 @@ struct mvneta_port {
> > struct gpio_desc phy_reset_gpio;
> > struct gpio_desc sfp_tx_disable_gpio;
> > #endif
> > +
> > + uintptr_t dma_base; /* base address for DMA address decoding */
> > };
> >
> > /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> > @@ -513,10 +517,19 @@ static void mvneta_rxq_desc_num_update(struct
> > mvneta_port *pp,
> > static struct mvneta_rx_desc *
> > mvneta_rxq_next_desc_get(struct mvneta_rx_queue *rxq)
> > {
> > + struct mvneta_rx_desc *curr;
> > int rx_desc = rxq->next_desc_to_proc;
> >
> > + /* validate RX descriptor */
> > + curr = rxq->descs + rx_desc;
> > + if (curr->data_size == 0) {
> > + /* do it to read real descriptor next time */
> > + DSB;
> > + return NULL;
> > + }
> > +
> > rxq->next_desc_to_proc = MVNETA_QUEUE_NEXT_DESC(rxq, rx_desc);
> > - return rxq->descs + rx_desc;
> > + return curr;
> > }
> >
> > /* Tx descriptors helper methods */
> > @@ -1343,6 +1356,29 @@ static void mvneta_conf_mbus_windows(struct
> > mvneta_port *pp)
> > mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
> > }
> >
> > +static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
> > +{
> > + int i;
> > +
> > + /* Clear all windows */
> > + for (i = 0; i < 6; i++) {
> > + mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
> > + mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
> > +
> > + if (i < 4)
> > + mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
> > + }
> > +
> > + /*
> > + * Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
> > 0xb, size 4GB
> > + * AMB2 address decoder remaps 0x0 to DDR 64 bit base address
> > + */
> > + mvreg_write(pp, MVNETA_WIN_BASE(0),
> > + (MVNETA_AC5_CNM_DDR_ATTR << 8) |
> > MVNETA_AC5_CNM_DDR_TARGET);
> > + mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
> > + mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
> > +}
> > +
> > /* Power up the port */
> > static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
> > {
> > @@ -1508,11 +1544,15 @@ static int mvneta_recv(struct udevice *dev, int
> > flags, uchar **packetp)
> >*/
> > rx_desc = mvneta_rxq_next_desc_get(rxq);
> >
> > + if (!rx_desc)
> > + return 0;
> > +
> > rx_status = rx_desc->status;
> > if (!mvneta_rxq_
Re: [PATCH v2 1/6] net: mvneta: Add support for AlleyCat5
On Tue, Sep 20, 2022 at 10:48 PM Pali Rohár wrote:
>
> On Tuesday 20 September 2022 20:31:48 Chris Packham wrote:
> > diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
> > index d2c42c4396..07919d6d35 100644
> > --- a/drivers/net/mvneta.c
> > +++ b/drivers/net/mvneta.c
> > @@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
> > #define MVNETA_WIN_SIZE_MASK (0x)
> > #define MVNETA_BASE_ADDR_ENABLE 0x2290
> > #define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
> > +#define MVNETA_AC5_CNM_DDR_TARGET 0x2
> > +#define MVNETA_AC5_CNM_DDR_ATTR 0xb
> > #define MVNETA_PORT_ACCESS_PROTECT 0x2294
> > #define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW 0x3
> > #define MVNETA_PORT_CONFIG 0x2400
> > @@ -282,6 +284,8 @@ struct mvneta_port {
> > struct gpio_desc phy_reset_gpio;
> > struct gpio_desc sfp_tx_disable_gpio;
> > #endif
> > +
> > + uintptr_t dma_base; /* base address for DMA address decoding */
> > };
> >
> > /* The mvneta_tx_desc and mvneta_rx_desc structures describe the
> > @@ -513,10 +517,19 @@ static void mvneta_rxq_desc_num_update(struct
> > mvneta_port *pp,
> > static struct mvneta_rx_desc *
> > mvneta_rxq_next_desc_get(struct mvneta_rx_queue *rxq)
> > {
> > + struct mvneta_rx_desc *curr;
> > int rx_desc = rxq->next_desc_to_proc;
> >
> > + /* validate RX descriptor */
> > + curr = rxq->descs + rx_desc;
> > + if (curr->data_size == 0) {
> > + /* do it to read real descriptor next time */
> > + DSB;
> > + return NULL;
> > + }
> > +
> > rxq->next_desc_to_proc = MVNETA_QUEUE_NEXT_DESC(rxq, rx_desc);
> > - return rxq->descs + rx_desc;
> > + return curr;
> > }
>
> Hello! This change looks like some fix, and not related to AC5 support.
> So it should be in separate patch as it affects all mvneta platforms,
> not only AC5.
>
Yep. I'll see if I can get away without this change for the AC5X. So
I'll either move it to a new patch or remove it completely in the next
round.
> > @@ -1508,11 +1544,15 @@ static int mvneta_recv(struct udevice *dev, int
> > flags, uchar **packetp)
> >*/
> > rx_desc = mvneta_rxq_next_desc_get(rxq);
> >
> > + if (!rx_desc)
> > + return 0;
> > +
> > rx_status = rx_desc->status;
> > if (!mvneta_rxq_desc_is_first_last(rx_status) ||
> > (rx_status & MVNETA_RXD_ERR_SUMMARY)) {
> > mvneta_rx_error(pp, rx_desc);
> > - /* leave the descriptor untouched */
> > + /* invalidate the descriptor */
> > + rx_desc->data_size = 0;
> > return -EIO;
> > }
>
> ditto.
>
> > @@ -1525,13 +1565,15 @@ static int mvneta_recv(struct udevice *dev, int
> > flags, uchar **packetp)
> >* No cache invalidation needed here, since the rx_buffer's
> > are
> >* located in a uncached memory region
> >*/
> > - *packetp = data;
> > + *packetp = data + pp->dma_base;
> >
> > /*
> >* Only mark one descriptor as free
> >* since only one was processed
> >*/
> > mvneta_rxq_desc_num_update(pp, rxq, 1, 1);
> > + /* invalidate the descriptor */
> > + rx_desc->data_size = 0;
>
> ditto.
>
> > }
> >
> > return rx_bytes;
> > @@ -1544,6 +1586,11 @@ static int mvneta_probe(struct udevice *dev)
> > struct ofnode_phandle_args sfp_args;
> > #endif
> > void *bd_space;
> > + void *blob = (void *)gd->fdt_blob;
> > + int node = dev_of_offset(dev);
> > + const int *cell;
> > + int len;
> > +
> >
> > /*
> >* Allocate buffer area for descs and rx_buffers. This is only
> > @@ -1577,9 +1624,21 @@ static int mvneta_probe(struct udevice *dev)
> > /* Configure MBUS address windows */
> > if (device_is_compatible(dev, "marvell,armada-3700-neta"))
> > mvneta_bypass_mbus_windows(pp);
> > + else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
> > + mvneta_conf_ac5_cnm_xbar_window
Re: [PATCH v2 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
On Tue, Sep 20, 2022 at 9:22 PM Pali Rohár wrote:
>
> On Tuesday 20 September 2022 20:31:52 Chris Packham wrote:
> > Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
> > an integrated CPU (referred to as the CnM block in Marvell's
> > documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
> > has been ported from Marvell's SDK which is based on a much older
> > version of U-Boot.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > (no changes since v1)
> >
> > arch/arm/dts/ac5-98dx25xx.dtsi | 292 +++
> > arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
> > arch/arm/mach-mvebu/Kconfig | 5 +
> > arch/arm/mach-mvebu/Makefile | 1 +
> > arch/arm/mach-mvebu/alleycat5/Makefile | 9 +
> > arch/arm/mach-mvebu/alleycat5/clock.c| 49
> > arch/arm/mach-mvebu/alleycat5/cpu.c | 129 ++
> > arch/arm/mach-mvebu/alleycat5/soc.c | 229 ++
> > arch/arm/mach-mvebu/arm64-common.c | 15 ++
> > arch/arm/mach-mvebu/include/mach/clock.h | 11 +
> > arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
> > arch/arm/mach-mvebu/include/mach/soc.h | 4 +
> > 12 files changed, 765 insertions(+)
> > create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
> > create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
> > create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
> > create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c
> > create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
> > create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
> > create mode 100644 arch/arm/mach-mvebu/include/mach/clock.h
> >
> ...
> > diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> > index a81b8e2b0d..400a308985 100644
> > --- a/arch/arm/mach-mvebu/Kconfig
> > +++ b/arch/arm/mach-mvebu/Kconfig
> > @@ -49,6 +49,11 @@ config ARMADA_8K
> > bool
> > select ARM64
> >
> > +config ALLEYCAT_5
> > + bool
> > + select ARM64
> > + select HAVE_MVEBU_EFUSE
>
> Hello! You are not adding any efuse implementation for AC5 platform,
> so selecting this symbol seems to be wrong.
>
> Or are you reusing A3720 or A38x OTP implementation for AC5? This is not
> clear from the patch.
>
The original code did have some EFUSE stuff in it but I've dropped
most of it out. I think this can go.
> > +
> > # Armada PLL frequency (used for NAND clock generation)
> > config SYS_MVEBU_PLL_CLOCK
> > int
> ...
> > diff --git a/arch/arm/mach-mvebu/arm64-common.c
> > b/arch/arm/mach-mvebu/arm64-common.c
> > index 238edbe6ba..c9b6f16c63 100644
> > --- a/arch/arm/mach-mvebu/arm64-common.c
> > +++ b/arch/arm/mach-mvebu/arm64-common.c
> > @@ -53,6 +53,8 @@ __weak int dram_init_banksize(void)
> > return a8k_dram_init_banksize();
> > else if (CONFIG_IS_ENABLED(ARMADA_3700))
> > return a3700_dram_init_banksize();
> > + else if (CONFIG_IS_ENABLED(ALLEYCAT_5))
> > + return alleycat5_dram_init_banksize();
> > else
> > return fdtdec_setup_memory_banksize();
> > }
> > @@ -68,6 +70,9 @@ __weak int dram_init(void)
> > if (CONFIG_IS_ENABLED(ARMADA_3700))
> > return a3700_dram_init();
> >
> > + if (CONFIG_IS_ENABLED(ALLEYCAT_5))
> > + return alleycat5_dram_init();
> > +
> > if (fdtdec_setup_mem_size_base() != 0)
> > return -EINVAL;
> >
> > @@ -100,6 +105,16 @@ int arch_early_init_r(void)
> > break;
> > }
> >
> > + i = 0;
> > + while (1) {
> > + /* Call the pinctrl code via the PINCTRL uclass driver */
> > + ret = uclass_get_device(UCLASS_PINCTRL, i++, &dev);
> > +
> > + /* We're done, once no further CP110 device is found */
> > + if (ret)
> > + break;
> > + }
>
> This code is unconditionally called for all 64-bit mvebu platforms, not
> only for new AC5. So if this is some fix, it should be in separate
> commit. If not then it should be marked AC5 specific and explained why.
>
Yeah I can't see why it's needed. The pinctrl device still gets probed
without it so I suspect it's just old cruft left over from a time that
wasn't the case.
> > +
> > /* Cause the SATA device to do its early init */
> > uclass_first_device(UCLASS_AHCI,
[PATCH v3 0/6] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X which was based on u-boot 2018.03. I've split that code into consumable chunks and dropped as much unnecessary stuff as I can. I've also tried to sync the device trees as much as possible with the support that will land in Linux 6.0 although there are still some differences Changes in v3: - Remove unnecessary changes to RX descriptor handling - Use dev_get_dma_range() to parse dma-ranges property from parent device. - None. Note some changes related to this have been requested and will be looked into I just wanted to get v3 out so the other changes could be reviewed. - Remove unnecessary dma-ranges property from ethernet nodes (mvneta now correctly parses the property from the parent node). - Keep soc_print_clock_info and soc_print_device_info local to alleycat5. - Remove MMC and UBIFS distroboot options (MMC driver is not currently functional, NAND is not populated on the RD-AC5X board) - Remove unnecessary Ethernet configuration - Remove unnecessary NAND configuration - Remove memory node from dts so the value passed by the DDR FW will be used Changes in v2: - Use distro boot by default - remove unnecessary SPI-NOR partitions Chris Packham (6): net: mvneta: Add support for AlleyCat5 usb: ehci: ehci-marvell: Support for marvell,ac5-ehci pinctrl: mvebu: Add AlleyCat5 support misc: mvebu: Add sample at reset driver arm: mvebu: Support for 98DX25xx/98DX35xx SoC arm: mvebu: Add RD-AC5X board arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 290 + arch/arm/dts/ac5-98dx35xx-rd.dts | 135 ++ arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++ arch/arm/mach-mvebu/Kconfig| 13 +- arch/arm/mach-mvebu/Makefile | 1 + arch/arm/mach-mvebu/alleycat5/Makefile | 9 + arch/arm/mach-mvebu/alleycat5/clock.c | 49 arch/arm/mach-mvebu/alleycat5/clock.h | 11 + arch/arm/mach-mvebu/alleycat5/cpu.c| 129 + arch/arm/mach-mvebu/alleycat5/soc.c| 229 arch/arm/mach-mvebu/alleycat5/soc.h| 6 + arch/arm/mach-mvebu/arm64-common.c | 5 + arch/arm/mach-mvebu/include/mach/cpu.h | 4 + board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + board/Marvell/mvebu_alleycat-5/Makefile| 3 + board/Marvell/mvebu_alleycat-5/board.c | 35 +++ configs/mvebu_ac5_rd_defconfig | 88 +++ drivers/misc/Kconfig | 6 + drivers/misc/Makefile | 1 + drivers/misc/mvebu_sar/Makefile| 4 + drivers/misc/mvebu_sar/ac5_sar.c | 119 + drivers/misc/mvebu_sar/sar-uclass.c| 146 +++ drivers/net/Kconfig| 2 +- drivers/net/mvneta.c | 43 ++- drivers/pinctrl/mvebu/Kconfig | 2 +- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-marvell.c| 57 +++- include/configs/mvebu_alleycat-5.h | 57 include/dm/uclass-id.h | 1 + include/fdtdec.h | 4 + include/mvebu/mvebu_chip_sar.h | 73 ++ include/mvebu/sar.h| 57 include/mvebu/var.h| 28 ++ include/sar-uclass.h | 23 ++ lib/fdtdec.c | 6 +- 36 files changed, 1647 insertions(+), 16 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.h create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile create mode 100644 board/Marvell/mvebu_alleycat-5/board.c create mode 100644 configs/mvebu_ac5_rd_defconfig create mode 100644 drivers/misc/mvebu_sar/Makefile create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c create mode 100644 include/configs/mvebu_alleycat-5.h create mode 100644 include/mvebu/mvebu_chip_sar.h create mode 100644 include/mvebu/sar.h create mode 100644 include/mvebu/var.h create mode 100644 include/sar-uclass.h -- 2.37.3
[PATCH v3 1/6] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 43 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..0fbfad11d4 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -1343,6 +1347,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1525,7 +1552,7 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
@@ -1544,6 +1571,10 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sfp_args;
#endif
void *bd_space;
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 size;
+ int ret;
/*
* Allocate buffer area for descs and rx_buffers. This is only
@@ -1577,9 +1608,18 @@ static int mvneta_probe(struct udevice *dev)
/* Configure MBUS address windows */
if (device_is_compatible(dev, "marvell,armada-3700-neta"))
mvneta_bypass_mbus_windows(pp);
+ else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
+ mvneta_conf_ac5_cnm_xbar_windows(pp);
else
mvneta_conf_mbus_windows(pp);
+ /* fetch dma ranges property */
+ ret = dev_get_dma_range(dev, &cpu, &bus, &size);
+ if (!ret)
+ pp->dma_base = cpu;
+ else
+ pp->dma_base = 0;
+
#if CONFIG_IS_ENABLED(DM_GPIO)
if (!dev_read_phandle_with_args(dev, "sfp", NULL, 0, 0, &sfp_args) &&
ofnode_is_enabled(sfp_args.node))
@@ -1620,6 +1660,7 @@ static const struct eth_ops mvneta_ops = {
static const struct udevice_id mvneta_ids[] = {
{ .compatible = "marvell,armada-370-neta" },
+ { .compatible = "marvell,armada-ac5-neta" },
{ .compatible = "marvell,armada-xp-neta" },
{ .compatible = "marvell,armada-3700-neta" },
{ }
--
2.37.3
[PATCH v3 2/6] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
---
(no changes since v1)
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 57 +++--
2 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0f48f09a7..628078f495 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..7d859b9cce 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,15 +149,28 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
((uintptr_t)hccr + HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
debug("ehci-marvell: init hccr %lx and hcor %lx hc_length %ld\n",
- (uintptr_t)hccr, (uintptr_t)hcor,
- (uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+ (uintptr_t)hccr, (uintptr_t)hcor,
+ (uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci&q
[PATCH v3 3/6] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham --- (no changes since v1) drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.37.3
[PATCH v3 4/6] misc: mvebu: Add sample at reset driver
Add a new UCLASS_SAR, the generic SAR code and an Alleycat5 driver. This
has been adapted from the Marvell SDK but only the AC5 driver has been
brought through (other drivers exist for the ap806, ap807 and cp110 IP
blocks).
Signed-off-by: Chris Packham
---
Changes in v3:
- None. Note some changes related to this have been requested and will
be looked into I just wanted to get v3 out so the other changes could
be reviewed.
drivers/misc/Kconfig| 6 ++
drivers/misc/Makefile | 1 +
drivers/misc/mvebu_sar/Makefile | 4 +
drivers/misc/mvebu_sar/ac5_sar.c| 119 +++
drivers/misc/mvebu_sar/sar-uclass.c | 146
include/dm/uclass-id.h | 1 +
include/fdtdec.h| 4 +
include/mvebu/mvebu_chip_sar.h | 73 ++
include/mvebu/sar.h | 57 +++
include/mvebu/var.h | 28 ++
include/sar-uclass.h| 23 +
lib/fdtdec.c| 6 +-
12 files changed, 467 insertions(+), 1 deletion(-)
create mode 100644 drivers/misc/mvebu_sar/Makefile
create mode 100644 drivers/misc/mvebu_sar/ac5_sar.c
create mode 100644 drivers/misc/mvebu_sar/sar-uclass.c
create mode 100644 include/mvebu/mvebu_chip_sar.h
create mode 100644 include/mvebu/sar.h
create mode 100644 include/mvebu/var.h
create mode 100644 include/sar-uclass.h
diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index a6da6e215d..4e99ef29d9 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -645,4 +645,10 @@ config SL28CPLD
the base driver which provides common access methods for the
sub-drivers.
+config MVEBU_SAR
+ bool "MVEBU SAR driver"
+ depends on ARCH_MVEBU
+ help
+ Support MVEBU SAR driver
+
endmenu
diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
index d494639cd9..3cf976edd8 100644
--- a/drivers/misc/Makefile
+++ b/drivers/misc/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_NUVOTON_NCT6102D) += nuvoton_nct6102d.o
obj-$(CONFIG_P2SB) += p2sb-uclass.o
obj-$(CONFIG_PCA9551_LED) += pca9551_led.o
obj-$(CONFIG_$(SPL_)PWRSEQ) += pwrseq-uclass.o
+obj-$(CONFIG_MVEBU_SAR) += mvebu_sar/
ifdef CONFIG_QFW
obj-y += qfw.o
obj-$(CONFIG_QFW_PIO) += qfw_pio.o
diff --git a/drivers/misc/mvebu_sar/Makefile b/drivers/misc/mvebu_sar/Makefile
new file mode 100644
index 00..6f339fb7b4
--- /dev/null
+++ b/drivers/misc/mvebu_sar/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_MVEBU_SAR) += sar-uclass.o
+obj-$(CONFIG_ALLEYCAT_5) += ac5_sar.o
diff --git a/drivers/misc/mvebu_sar/ac5_sar.c b/drivers/misc/mvebu_sar/ac5_sar.c
new file mode 100644
index 00..67b2110bc8
--- /dev/null
+++ b/drivers/misc/mvebu_sar/ac5_sar.c
@@ -0,0 +1,119 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018 Marvell International Ltd.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#define MHz100
+
+#define BIT_VAL(b) ((1ULL << ((b) + 1)) - 1)
+#define BIT_RANGE(Bl, Bh) (BIT_VAL(Bh) - BIT_VAL((Bl) - 1))
+
+#define PLL_MAX_CHOICE 4
+
+#define CPU_TYPE_AC50
+#define CPU_TYPE_AC5x 1
+#define CPU_TYPE_LAST 2
+
+static const u32 pll_freq_tbl[CPU_TYPE_LAST][SAR_AP_FABRIC_FREQ +
1][PLL_MAX_CHOICE] = {
+ [CPU_TYPE_AC5] = {
+ [SAR_CPU_FREQ] = {
+ 800 * MHz, 1200 * MHz, 1400 * MHz, 1000 * MHz
+ },
+ [SAR_DDR_FREQ] = {
+ 1200 * MHz, 800 * MHz, 0, 0
+ },
+ [SAR_AP_FABRIC_FREQ] = {
+ 396 * MHz, 290 * MHz, 197 * MHz, 0
+ },
+ },
+ [CPU_TYPE_AC5x] = {
+ [SAR_CPU_FREQ] = {
+ 800 * MHz, 1200 * MHz, 1500 * MHz, 1600 * MHz
+ },
+ [SAR_DDR_FREQ] = {
+ 1200 * MHz, 800 * MHz, 0, 0
+ },
+ [SAR_AP_FABRIC_FREQ] = {
+ 0, 0, 0, 0
+ }
+ }
+};
+
+static const u32 soc_sar_masks_tbl[CPU_TYPE_LAST][SAR_AP_FABRIC_FREQ + 1] = {
+ [CPU_TYPE_AC5] = {
+ [SAR_CPU_FREQ] = BIT_RANGE(18, 20),
+ [SAR_DDR_FREQ] = BIT_RANGE(16, 17),
+ [SAR_AP_FABRIC_FREQ] = BIT_RANGE(22, 23),
+ },
+ [CPU_TYPE_AC5x] = {
+ [SAR_CPU_FREQ] = BIT_RANGE(8, 10),
+ [SAR_DDR_FREQ] = BIT_RANGE(6, 7),
+ [SAR_AP_FABRIC_FREQ] = 1,
+ },
+};
+
+static int ac5_sar_value_get(struct udevice *dev, enum mvebu_sar_opts sar_opt,
+struct sar_val *val)
+{
+ u32 *pSarBase = (u32 *)(((struct dm_sar_pdata
*)dev_get_priv(dev))->sar_base);
+ u32 sar_reg_val = readl(pSarBase);
+ u32 mask;
+ unsigned char choice;
+ int cpu_type = ((readl(0x7f90004c) & 0xFF000) >>
[PATCH v3 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
Changes in v3:
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
arch/arm/dts/ac5-98dx25xx.dtsi | 290 +
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 4 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 9 +
arch/arm/mach-mvebu/alleycat5/clock.c | 49 +
arch/arm/mach-mvebu/alleycat5/clock.h | 11 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 129 +++
arch/arm/mach-mvebu/alleycat5/soc.c| 229 +++
arch/arm/mach-mvebu/alleycat5/soc.h| 6 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
12 files changed, 754 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/clock.h
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..64516938e8
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,290 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ config-space {
+ #address-cells = <0x1>;
+ #size-cells = <0x1>;
+ compatible = "simple-bus";
+
+ sar-reg {
+ compatible = "marvell,sample-at-reset-common";
+ sar-driver = "ac5_sar";
+ sar-name = "ac5_sar";
+ status = "okay";
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges
[PATCH v3 6/6] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and features
include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host port
(shared with PCIe)
Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ Port 48
(Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v3:
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 135 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 35 ++
configs/mvebu_ac5_rd_defconfig | 88 ++
include/configs/mvebu_alleycat-5.h | 57 +
8 files changed, 334 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 965895bc2a..57a5272884 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..7f1c8a5e22
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,135 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 = &uart0;
+ spiflash0 = &spiflash0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ spi0 = &spi0;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ pinctrl0 = &pinctrl0;
+ sar-reg0 = "/config-space/sar-reg";
+ };
+
+ usb1phy: usb-phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0>;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ config-space {
+ sar-reg {
+ reg = <0x944F8204 0x1>;
+ };
+ };
+};
+
+&uart0 {
+ status = "okay";
+};
+
+&mdio {
+ phy0: ethernet-phy@0 {
+ reg = <0>;
+ };
+};
+
+&i2c0 {
+ status = "okay";
Re: [PATCH v3 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
On Wed, Sep 21, 2022 at 5:58 PM Stefan Roese wrote:
>
> On 21.09.22 06:59, Chris Packham wrote:
> > Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
> > an integrated CPU (referred to as the CnM block in Marvell's
> > documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
> > has been ported from Marvell's SDK which is based on a much older
> > version of U-Boot.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
> > b/arch/arm/mach-mvebu/alleycat5/soc.c
> > new file mode 100644
> > index 00..f388d4ee40
> > --- /dev/null
> > +++ b/arch/arm/mach-mvebu/alleycat5/soc.c
> > +/* Return NAND clock in Hz */
> > +u32 mvebu_get_nand_clock(void)
> > +{
> > + return 200 * 100;
> > +}
>
> Is this still needed?
>
It will be needed eventually. After I get this landed I'll start work
on getting our board upstreamed and that does make use of the NAND
interface. There are some NAND driver changes that go along with this
so I'll move this over into that patch series.
Re: [PATCH v3 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
On Wed, Sep 21, 2022 at 5:58 PM Stefan Roese wrote:
>
> On 21.09.22 06:59, Chris Packham wrote:
> > Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
> > an integrated CPU (referred to as the CnM block in Marvell's
> > documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
> > has been ported from Marvell's SDK which is based on a much older
> > version of U-Boot.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
> > b/arch/arm/mach-mvebu/alleycat5/soc.c
> > new file mode 100644
> > index 00..f388d4ee40
> > --- /dev/null
> > +++ b/arch/arm/mach-mvebu/alleycat5/soc.c
> > +int soc_early_init_f(void)
> > +{
> > +#ifdef CONFIG_MVEBU_SAR
> > +/* Sample at reset register init */
> > + mvebu_sar_init();
> > +#endif
>
> Won't CONFIG_MVEBU_SAR always be enabled? Remove the #ifdef in this
> case.
>
> > + return 0;
> > +}
Currently it is possible to turn it off. As I've said I think I do
need to look at the whole SAR business and see if it can be done
differently.
One useful thing it does do is tell me about how the hardware has been
strapped. U-Boot itself doesn't care about that specifically as the
separate mv_ddr blob that runs before ATF is the thing that actually
uses the SAR values. But U-
Boot is the first place that can give me some friendly output about
the board and knowing the CPU/DDR clock speed is useful at that level.
Re: [PATCH v3 5/6] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
On Thu, Sep 22, 2022 at 9:40 AM Pali Rohár wrote:
>
> On Thursday 22 September 2022 09:25:37 Chris Packham wrote:
> > On Wed, Sep 21, 2022 at 5:58 PM Stefan Roese wrote:
> > >
> > > On 21.09.22 06:59, Chris Packham wrote:
> > > > Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
> > > > an integrated CPU (referred to as the CnM block in Marvell's
> > > > documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
> > > > has been ported from Marvell's SDK which is based on a much older
> > > > version of U-Boot.
> > > >
> > > > Signed-off-by: Chris Packham
> > > > ---
> > > >
> >
> >
> >
> > > > diff --git a/arch/arm/mach-mvebu/alleycat5/soc.c
> > > > b/arch/arm/mach-mvebu/alleycat5/soc.c
> > > > new file mode 100644
> > > > index 00..f388d4ee40
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-mvebu/alleycat5/soc.c
> >
> >
> >
> > > > +int soc_early_init_f(void)
> > > > +{
> > > > +#ifdef CONFIG_MVEBU_SAR
> > > > +/* Sample at reset register init */
> > > > + mvebu_sar_init();
> > > > +#endif
> > >
> > > Won't CONFIG_MVEBU_SAR always be enabled? Remove the #ifdef in this
> > > case.
> > >
> > > > + return 0;
> > > > +}
> >
> > Currently it is possible to turn it off. As I've said I think I do
> > need to look at the whole SAR business and see if it can be done
> > differently.
> >
> > One useful thing it does do is tell me about how the hardware has been
> > strapped. U-Boot itself doesn't care about that specifically as the
> > separate mv_ddr blob that runs before ATF is the thing that actually
> > uses the SAR values. But U-
> > Boot is the first place that can give me some friendly output about
> > the board and knowing the CPU/DDR clock speed is useful at that level.
>
> I agree that the last thing - print information about CPU/DDR clock
> speed is useful [1]. But I do not see reason why to complicate it such
> much via new uclass OOP model for other things in DTS, which moreover
> use already deprecated structure and requires hack in fdtdec.c file.
>
Agreed. The fact that I can turn the driver off and (after fixing some
code that calls into it directly) everything still works (except for
the reporting of the clock speeds) it does indicate that I don't
really need this.
> I think that the whole SAR code can be simplified and written
> straightforward for AC5 to be easier for developer to read... but this
> step is not probably such simple as it is required to first understand
> what is this "complicated" code doing and it is probably boring job :-(
Not boring but it doesn't help that Marvell don't document the SAR
registers so I can only go by following their overly complicated code.
>
> For 32-bit Armada there is already very simple SAR register handling to
> check and detect TCLK speed. So I think AC5 is similar in this area, but
> more has more complicated code logic and "very simple 32-bit SAR" is not
> suitable to reuse.
>
I think I can come up with something that replaces the sar-uclass
business with code that just accesses the relevant register(s)
directly in the alleycat5/soc.c code.
>
> [1] - Btw, I added this print in A3720 secure firmware, because it is
> really useful and important (!) and secure firmware is who configures it
Re: [PATCH v3 6/6] arm: mvebu: Add RD-AC5X board
On Thu, Sep 22, 2022 at 9:55 AM Pali Rohár wrote:
>
> On Wednesday 21 September 2022 16:59:41 Chris Packham wrote:
> > diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts
> > b/arch/arm/dts/ac5-98dx35xx-rd.dts
> ...
> > +/ {
> > + model = "Marvell RD-AC5X Board";
> > + compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
> > +
> > + aliases {
> > + serial0 = &uart0;
> ...
> > + };
> ...
> > + chosen {
> > + stdout-path = "serial0:115200n8";
> > + };
> ...
> > diff --git a/include/configs/mvebu_alleycat-5.h
> > b/include/configs/mvebu_alleycat-5.h
> ...
> > +#define CONFIG_EXTRA_ENV_SETTINGS \
> ...
> > + "console=console=ttyS0,115200 earlycon=uart8250,mmio32,0xf0512000\0"\
>
> Hello! Is not this console=console= line suspicious?
>
> And also because default console device is selected by /chosen/stdout-path
> DT property and earlycon address is also parsed from DTS, I have feeling
> that specifying it on cmdline is just duplication of DTS.
>
> Try to boot your arm64 kernel with just "earlycon" string without
> specifying uart8250,mmio32... I think that it should work fine.
>
Yeah I think this is a relic. The original code had all kinds of magic
for manipulating bootargs that involved pulling in the console from
the environment. I think it can go as the default should come from the
DTS. Anything else is up to the user to configure bootargs
appropriately.
>
> I think that main issue here is that people just choose one board or
> config file, copy it and simple modify it and letting all those historic
> relict not needed in u-boot anymore. And due to this copy+paste stuff
> nobody knows what is needed, what not and nobody knows answer to
> important question "why it is there?".
>
> But I understand it. The best for developer is to take something which
> works and do just simple modification for specific board to achieve
> functionality. Doing more modification or trying to understand if there
> is not unnecessary code consume lot of time which people do not have...
>
> (nothing wrong; just I'm reading code and trying to understand it what
> it is doing or why it is there... and detect possible dead code patterns
> :-))
I think you're right to point it out. I encounter the same thing all
the time at $dayjob and try to push back against the blind
copy-pasting so I should really know better (there is an amount of
rebase fatigue from porting the old code).
[PATCH v4 0/5] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X which was based on u-boot 2018.03. I've split that code into consumable chunks and dropped as much unnecessary stuff as I can. I've also tried to sync the device trees as much as possible with the support that will land in Linux 6.0 although there are still some differences Changes in v4: - Collect r-by from Stefan - Remove unused mvebu_get_nand_clock() (will return in a later series) - Remove unnecessary #ifdefs - Misc style cleanups - Replace CONFIG_MVEBU_SAR with simpler code implemented directly in soc.c based around get_sar_freq which the 32-bit platforms already use. - Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to the defconfig. - Remove CONFIG_BAUDRATE as this is already set in the default config - Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with DM_USB - Remove CONFIG_PREBOOT as we don't have anything to run - Remove commented out CONFIG_BOARD_EARLY_INIT_R - Remove DEBUG_UART configuration - Remove unnecessary console environment variable - Remove CONFIG_MVEBU_SAR Changes in v3: - Remove unnecessary changes to RX descriptor handling - Use dev_get_dma_range() to parse dma-ranges property from parent device. - Remove unnecessary dma-ranges property from ethernet nodes (mvneta now correctly parses the property from the parent node). - Keep soc_print_clock_info and soc_print_device_info local to alleycat5. - Remove MMC and UBIFS distroboot options (MMC driver is not currently functional, NAND is not populated on the RD-AC5X board) - Remove unnecessary Ethernet configuration - Remove unnecessary NAND configuration - Remove memory node from dts so the value passed by the DDR FW will be used Changes in v2: - Use distro boot by default - remove unnecessary SPI-NOR partitions Chris Packham (5): net: mvneta: Add support for AlleyCat5 usb: ehci: ehci-marvell: Support for marvell,ac5-ehci pinctrl: mvebu: Add AlleyCat5 support arm: mvebu: Support for 98DX25xx/98DX35xx SoC arm: mvebu: Add RD-AC5X board arch/arm/dts/Makefile | 3 +- arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++ arch/arm/dts/ac5-98dx35xx-rd.dts | 129 + arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++ arch/arm/mach-mvebu/Kconfig| 13 +- arch/arm/mach-mvebu/Makefile | 1 + arch/arm/mach-mvebu/alleycat5/Makefile | 8 + arch/arm/mach-mvebu/alleycat5/cpu.c| 124 + arch/arm/mach-mvebu/alleycat5/soc.c| 298 + arch/arm/mach-mvebu/alleycat5/soc.h| 7 + arch/arm/mach-mvebu/arm64-common.c | 5 + arch/arm/mach-mvebu/include/mach/cpu.h | 4 + board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + board/Marvell/mvebu_alleycat-5/Makefile| 3 + board/Marvell/mvebu_alleycat-5/board.c | 28 ++ configs/mvebu_ac5_rd_defconfig | 84 ++ drivers/net/Kconfig| 2 +- drivers/net/mvneta.c | 43 ++- drivers/pinctrl/mvebu/Kconfig | 2 +- drivers/usb/host/Kconfig | 1 + drivers/usb/host/ehci-marvell.c| 57 +++- include/configs/mvebu_alleycat-5.h | 42 +++ 22 files changed, 1139 insertions(+), 15 deletions(-) create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile create mode 100644 board/Marvell/mvebu_alleycat-5/board.c create mode 100644 configs/mvebu_ac5_rd_defconfig create mode 100644 include/configs/mvebu_alleycat-5.h -- 2.37.3
[PATCH v4 1/5] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
(no changes since v3)
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 43 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..0fbfad11d4 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -1343,6 +1347,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1525,7 +1552,7 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
@@ -1544,6 +1571,10 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sfp_args;
#endif
void *bd_space;
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 size;
+ int ret;
/*
* Allocate buffer area for descs and rx_buffers. This is only
@@ -1577,9 +1608,18 @@ static int mvneta_probe(struct udevice *dev)
/* Configure MBUS address windows */
if (device_is_compatible(dev, "marvell,armada-3700-neta"))
mvneta_bypass_mbus_windows(pp);
+ else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
+ mvneta_conf_ac5_cnm_xbar_windows(pp);
else
mvneta_conf_mbus_windows(pp);
+ /* fetch dma ranges property */
+ ret = dev_get_dma_range(dev, &cpu, &bus, &size);
+ if (!ret)
+ pp->dma_base = cpu;
+ else
+ pp->dma_base = 0;
+
#if CONFIG_IS_ENABLED(DM_GPIO)
if (!dev_read_phandle_with_args(dev, "sfp", NULL, 0, 0, &sfp_args) &&
ofnode_is_enabled(sfp_args.node))
@@ -1620,6 +1660,7 @@ static const struct eth_ops mvneta_ops = {
static const struct udevice_id mvneta_ids[] = {
{ .compatible = "marvell,armada-370-neta" },
+ { .compatible = "marvell,armada-ac5-neta" },
{ .compatible = "marvell,armada-xp-neta" },
{ .compatible = "marvell,armada-3700-neta" },
{ }
--
2.37.3
[PATCH v4 2/5] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
---
(no changes since v1)
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 57 +++--
2 files changed, 48 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0f48f09a7..628078f495 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..7d859b9cce 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,15 +149,28 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
((uintptr_t)hccr + HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
debug("ehci-marvell: init hccr %lx and hcor %lx hc_length %ld\n",
- (uintptr_t)hccr, (uintptr_t)hcor,
- (uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+ (uintptr_t)hccr, (uintptr_t)hcor,
+ (uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci&q
[PATCH v4 3/5] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese --- Changes in v4: - Collect r-by from Stefan drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.37.3
[PATCH v4 4/5] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
Changes in v4:
- Remove unused mvebu_get_nand_clock() (will return in a later series)
- Remove unnecessary #ifdefs
- Misc style cleanups
- Replace CONFIG_MVEBU_SAR with simpler code implemented directly in
soc.c based around get_sar_freq which the 32-bit platforms already
use.
Changes in v3:
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 4 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 8 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 124 ++
arch/arm/mach-mvebu/alleycat5/soc.c| 298 +
arch/arm/mach-mvebu/alleycat5/soc.h| 7 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
10 files changed, 745 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..3c68355f32
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges = <0x0 0x0 0x7f00 0x100>;
+ dma-coherent;
+
+ uart0: serial@12000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12000 0x100>;
+ reg-shift = <2>;
+ interrupts = ;
+ reg-io-width = <
[PATCH v4 5/5] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and
features include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host
port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~
Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881
solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v4:
- Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to
the defconfig.
- Remove CONFIG_BAUDRATE as this is already set in the default config
- Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with
DM_USB
- Remove CONFIG_PREBOOT as we don't have anything to run
- Remove commented out CONFIG_BOARD_EARLY_INIT_R
- Remove DEBUG_UART configuration
- Remove unnecessary console environment variable
- Remove CONFIG_MVEBU_SAR
Changes in v3:
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 129 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 28 +
configs/mvebu_ac5_rd_defconfig | 84 ++
include/configs/mvebu_alleycat-5.h | 42 +++
8 files changed, 302 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 965895bc2a..57a5272884 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..d9f217cd4a
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 = &uart0;
+ spiflash0 = &spiflash0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ spi0 = &spi0;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ usb0 = &usb0;
+ usb1 = &usb1;
+ pinctrl0 = &pinctrl0;
+ sar-reg0 = "/config-space/sar-reg";
+ };
+
+ usb1phy: usb-phy {
+ compatible = "usb-nop-xceiv";
+ #phy-ce
Re: [PATCH v4 2/5] usb: ehci: ehci-marvell: Support for marvell, ac5-ehci
On Thu, Sep 22, 2022 at 5:18 PM Stefan Roese wrote:
>
> On 22.09.22 05:31, Chris Packham wrote:
> > Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
> > block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
> > the fact that the ac5 does not have the mbus infrastructure the 32-bit
> > SoCs have and ensure USB_EHCI_IS_TDI is selected.
> >
> > Signed-off-by: Chris Packham
> > ---
> >
> > (no changes since v1)
> >
> > drivers/usb/host/Kconfig| 1 +
> > drivers/usb/host/ehci-marvell.c | 57 +++--
> > 2 files changed, 48 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> > index a0f48f09a7..628078f495 100644
> > --- a/drivers/usb/host/Kconfig
> > +++ b/drivers/usb/host/Kconfig
> > @@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
> > depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
> > default y
> > select USB_EHCI_IS_TDI if !ARM64
> > + select USB_EHCI_IS_TDI if ALLEYCAT_5
> > ---help---
> > Enables support for the on-chip EHCI controller on MVEBU SoCs.
> >
> > diff --git a/drivers/usb/host/ehci-marvell.c
> > b/drivers/usb/host/ehci-marvell.c
> > index b7e60c690a..7d859b9cce 100644
> > --- a/drivers/usb/host/ehci-marvell.c
> > +++ b/drivers/usb/host/ehci-marvell.c
> > @@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
> > fdt_addr_t hcd_base;
> > };
> >
> > +#define USB_TO_DRAM_TARGET_ID 0x2
> > +#define USB_TO_DRAM_ATTR_ID 0x0
> > +#define USB_DRAM_BASE 0x
> > +#define USB_DRAM_SIZE 0xfff /* don't overrun u-boot source (was 0x) */
> > +
> > /*
> >* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
> >* to the common mvebu archticture including the mbus setup, this
> >* will be the only function needed to configure the access windows
> >*/
> > -static void usb_brg_adrdec_setup(void *base)
> > +static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
> > {
> > const struct mbus_dram_target_info *dram;
> > int i;
> > @@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
> > writel(0, base + USB_WINDOW_BASE(i));
> > }
> >
> > - for (i = 0; i < dram->num_cs; i++) {
> > - const struct mbus_dram_window *cs = dram->cs + i;
> > + if (device_is_compatible(dev, "marvell,ac5-ehci")) {
> > + /*
> > + * use decoding window to map dram address seen by usb to 0x0
> > + */
> >
> > /* Write size, attributes and target id to control register */
> > - writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
> > -(dram->mbus_dram_target_id << 4) | 1,
> > -base + USB_WINDOW_CTRL(i));
> > + writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
> > +(USB_TO_DRAM_TARGET_ID << 4) | 1,
> > +base + USB_WINDOW_CTRL(0));
>
> Nitpicking / coding-style comment: Not aligned with the '(' in the
> line above. I assume that checkpatch.pl will complain here.
>
Doesn't seem to complain about this (ran manually and via patman).
I'll fix it regardless.
> >
> > /* Write base address to base register */
> > - writel(cs->base, base + USB_WINDOW_BASE(i));
> > + writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
> > +
> > + debug("## AC5 decoding windows, ctrl[%p]=0x%x,
> > base[%p]=0x%x\n",
> > + base + USB_WINDOW_CTRL(0), readl(base +
> > USB_WINDOW_CTRL(0)),
> > + base + USB_WINDOW_BASE(0), readl(base +
> > USB_WINDOW_BASE(0)));
> > + } else {
> > + for (i = 0; i < dram->num_cs; i++) {
> > + const struct mbus_dram_window *cs = dram->cs + i;
> > +
> > + /* Write size, attributes and target id to control
> > register */
> > + writel(((cs->size - 1) & 0x) | (cs->mbus_attr
> > << 8) |
> > +(dram->mbus_dram_target_id << 4) | 1,
> > +base + USB_WINDOW_CTRL(i));
> > +
> > + /* Write base address to base register */
> > +
Re: [PATCH v4 5/5] arm: mvebu: Add RD-AC5X board
On Thu, Sep 22, 2022 at 5:10 PM Stefan Roese wrote: > > On 22.09.22 05:31, Chris Packham wrote: > > The RD-AC5X-32G16HVG6HLG-A0 development board main components and > > features include: > > * Main 12V/54V power supply > > * 270 Gbps throughput packet processor on the main board > > * DDR4: > >* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs) > >* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs) > >* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement > > * 16GB eMMC (Samsung KLMAG1JETD-B041006) > > * 16MB SPI NOR(GD25Q127C) > > * 32 x 1000 Base-T interfaces > > * 16 x 2500 Base-T interfaces > >* SR1: 88E2540*4 > >* SR2: 88E2580*1+88E2540*2 > > * Six (6) x 25G Base-R SFP28 interfaces > > * One (1) x RJ-45 console connector, interfacing to the on board UART > > * One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0) > > * One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1) > > * One (1) x RJ-45 1G Base-T Management port, interfacing to the host > >port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy > > * One (1) x Oculink port, interfacing to the PCIe port for external CPU > >connection > > * POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~ > >Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881 > >solution) > > * POE total power budget 780W > > * LED interfaces per network port/POE > > * LED interfaces (common) showing system status > > * PTP TC mode Supported (Reserved M.2 connector to support BC mode) > > > > Signed-off-by: Chris Packham > > --- > > > > Changes in v4: > > - Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to > >the defconfig. > > - Remove CONFIG_BAUDRATE as this is already set in the default config > > - Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with > >DM_USB > > - Remove CONFIG_PREBOOT as we don't have anything to run > > - Remove commented out CONFIG_BOARD_EARLY_INIT_R > > - Remove DEBUG_UART configuration > > - Remove unnecessary console environment variable > > - Remove CONFIG_MVEBU_SAR > > > > Changes in v3: > > - Remove MMC and UBIFS distroboot options (MMC driver is not currently > >functional, NAND is not populated on the RD-AC5X board) > > - Remove unnecessary Ethernet configuration > > - Remove unnecessary NAND configuration > > - Remove memory node from dts so the value passed by the DDR FW will be > >used > > > > Changes in v2: > > - Use distro boot by default > > - remove unnecessary SPI-NOR partitions > > > > arch/arm/dts/Makefile | 3 +- > > arch/arm/dts/ac5-98dx35xx-rd.dts | 129 + > > arch/arm/mach-mvebu/Kconfig| 9 +- > > board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 + > > board/Marvell/mvebu_alleycat-5/Makefile| 3 + > > board/Marvell/mvebu_alleycat-5/board.c | 28 + > > configs/mvebu_ac5_rd_defconfig | 84 ++ > > include/configs/mvebu_alleycat-5.h | 42 +++ > > 8 files changed, 302 insertions(+), 2 deletions(-) > > create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts > > create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS > > create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile > > create mode 100644 board/Marvell/mvebu_alleycat-5/board.c > > create mode 100644 configs/mvebu_ac5_rd_defconfig > > create mode 100644 include/configs/mvebu_alleycat-5.h > > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > index 965895bc2a..57a5272884 100644 > > --- a/arch/arm/dts/Makefile > > +++ b/arch/arm/dts/Makefile > > @@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \ > > cn9132-db-A.dtb \ > > cn9132-db-B.dtb \ > > cn9130-crb-A.dtb\ > > - cn9130-crb-B.dtb > > + cn9130-crb-B.dtb\ > > + ac5-98dx35xx-rd.dtb > > endif > > > > dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb > > diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts > > b/arch/arm/dts/ac5-98dx35xx-rd.dts > > new file mode 100644 > > index 00..d9f217cd4a > > --- /dev/null > > +++ b/arch/arm/dts/ac5-98dx35xx-rd.dts > > @@ -0,0 +1,129 @@ > > +// SPDX-License-Identifier: (GPL-2.0+ OR MIT) >
[PATCH v5 0/5] arm: mvebu: Support for 98DX25xx/98DX35xx (AlleyCat5)
These patches are based on Marvell's bootloader for the AlleyCat5/5X
which was based on u-boot 2018.03. I've split that code into consumable
chunks and dropped as much unnecessary stuff as I can. I've also tried
to sync the device trees as much as possible with the support that will
land in Linux 6.0 although there are still some differences
Changes in v5:
- Minor white space cleanups
- Collect review from Stefan
- Minor fixup for checkpatch.pl complaint
- Remove unused bpard_{early,late}_init{,_r,_f} functions
- Remove CONFIG_PCI and CONFIG_E1000 as the PCI interface is not
currently working (requires more vendor code)
- Use CONFIG_OF_SEPARATE instead of CONFIG_OF_EMBED
Changes in v4:
- Collect r-by from Stefan
- Remove unused mvebu_get_nand_clock() (will return in a later series)
- Remove unnecessary #ifdefs
- Misc style cleanups
- Replace CONFIG_MVEBU_SAR with simpler code implemented directly in
soc.c based around get_sar_freq which the 32-bit platforms already
use.
- Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to
the defconfig.
- Remove CONFIG_BAUDRATE as this is already set in the default config
- Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with
DM_USB
- Remove CONFIG_PREBOOT as we don't have anything to run
- Remove commented out CONFIG_BOARD_EARLY_INIT_R
- Remove DEBUG_UART configuration
- Remove unnecessary console environment variable
- Remove CONFIG_MVEBU_SAR
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
Chris Packham (5):
net: mvneta: Add support for AlleyCat5
usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
pinctrl: mvebu: Add AlleyCat5 support
arm: mvebu: Support for 98DX25xx/98DX35xx SoC
arm: mvebu: Add RD-AC5X board
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++
arch/arm/dts/ac5-98dx35xx-rd.dts | 129 +
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 13 +-
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 8 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 124 +
arch/arm/mach-mvebu/alleycat5/soc.c| 298 +
arch/arm/mach-mvebu/alleycat5/soc.h| 7 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 13 +
configs/mvebu_ac5_rd_defconfig | 80 ++
drivers/net/Kconfig| 2 +-
drivers/net/mvneta.c | 43 ++-
drivers/pinctrl/mvebu/Kconfig | 2 +-
drivers/usb/host/Kconfig | 1 +
drivers/usb/host/ehci-marvell.c| 53 +++-
include/configs/mvebu_alleycat-5.h | 42 +++
22 files changed, 1118 insertions(+), 13 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
--
2.37.3
[PATCH v5 1/5] net: mvneta: Add support for AlleyCat5
Add support for the AlleyCat5 SoC. This lacks the mbus from the other
users of the mvneta.c driver so a new compatible string is needed to
allow for a different window configuration.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
(no changes since v3)
Changes in v3:
- Remove unnecessary changes to RX descriptor handling
- Use dev_get_dma_range() to parse dma-ranges property from parent
device.
drivers/net/Kconfig | 2 +-
drivers/net/mvneta.c | 43 ++-
2 files changed, 43 insertions(+), 2 deletions(-)
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6bbbadc5ee..8df3dce6df 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -448,7 +448,7 @@ config MVGBE
config MVNETA
bool "Marvell Armada XP/385/3700 network interface support"
- depends on ARMADA_XP || ARMADA_38X || ARMADA_3700
+ depends on ARMADA_XP || ARMADA_38X || ARMADA_3700 || ALLEYCAT_5
select PHYLIB
select DM_MDIO
help
diff --git a/drivers/net/mvneta.c b/drivers/net/mvneta.c
index d2c42c4396..0fbfad11d4 100644
--- a/drivers/net/mvneta.c
+++ b/drivers/net/mvneta.c
@@ -91,6 +91,8 @@ DECLARE_GLOBAL_DATA_PTR;
#define MVNETA_WIN_SIZE_MASK (0x)
#define MVNETA_BASE_ADDR_ENABLE 0x2290
#define MVNETA_BASE_ADDR_ENABLE_BIT 0x1
+#define MVNETA_AC5_CNM_DDR_TARGET 0x2
+#define MVNETA_AC5_CNM_DDR_ATTR 0xb
#define MVNETA_PORT_ACCESS_PROTECT 0x2294
#define MVNETA_PORT_ACCESS_PROTECT_WIN0_RW0x3
#define MVNETA_PORT_CONFIG 0x2400
@@ -282,6 +284,8 @@ struct mvneta_port {
struct gpio_desc phy_reset_gpio;
struct gpio_desc sfp_tx_disable_gpio;
#endif
+
+ uintptr_t dma_base; /* base address for DMA address decoding */
};
/* The mvneta_tx_desc and mvneta_rx_desc structures describe the
@@ -1343,6 +1347,29 @@ static void mvneta_conf_mbus_windows(struct mvneta_port
*pp)
mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, win_enable);
}
+static void mvneta_conf_ac5_cnm_xbar_windows(struct mvneta_port *pp)
+{
+ int i;
+
+ /* Clear all windows */
+ for (i = 0; i < 6; i++) {
+ mvreg_write(pp, MVNETA_WIN_BASE(i), 0);
+ mvreg_write(pp, MVNETA_WIN_SIZE(i), 0);
+
+ if (i < 4)
+ mvreg_write(pp, MVNETA_WIN_REMAP(i), 0);
+ }
+
+ /*
+* Setup window #0 base 0x0 to target XBAR port 2 (AMB2), attribute
0xb, size 4GB
+* AMB2 address decoder remaps 0x0 to DDR 64 bit base address
+*/
+ mvreg_write(pp, MVNETA_WIN_BASE(0),
+ (MVNETA_AC5_CNM_DDR_ATTR << 8) | MVNETA_AC5_CNM_DDR_TARGET);
+ mvreg_write(pp, MVNETA_WIN_SIZE(0), 0x);
+ mvreg_write(pp, MVNETA_BASE_ADDR_ENABLE, 0x3e);
+}
+
/* Power up the port */
static int mvneta_port_power_up(struct mvneta_port *pp, int phy_mode)
{
@@ -1525,7 +1552,7 @@ static int mvneta_recv(struct udevice *dev, int flags,
uchar **packetp)
* No cache invalidation needed here, since the rx_buffer's are
* located in a uncached memory region
*/
- *packetp = data;
+ *packetp = data + pp->dma_base;
/*
* Only mark one descriptor as free
@@ -1544,6 +1571,10 @@ static int mvneta_probe(struct udevice *dev)
struct ofnode_phandle_args sfp_args;
#endif
void *bd_space;
+ phys_addr_t cpu;
+ dma_addr_t bus;
+ u64 size;
+ int ret;
/*
* Allocate buffer area for descs and rx_buffers. This is only
@@ -1577,9 +1608,18 @@ static int mvneta_probe(struct udevice *dev)
/* Configure MBUS address windows */
if (device_is_compatible(dev, "marvell,armada-3700-neta"))
mvneta_bypass_mbus_windows(pp);
+ else if (device_is_compatible(dev, "marvell,armada-ac5-neta"))
+ mvneta_conf_ac5_cnm_xbar_windows(pp);
else
mvneta_conf_mbus_windows(pp);
+ /* fetch dma ranges property */
+ ret = dev_get_dma_range(dev, &cpu, &bus, &size);
+ if (!ret)
+ pp->dma_base = cpu;
+ else
+ pp->dma_base = 0;
+
#if CONFIG_IS_ENABLED(DM_GPIO)
if (!dev_read_phandle_with_args(dev, "sfp", NULL, 0, 0, &sfp_args) &&
ofnode_is_enabled(sfp_args.node))
@@ -1620,6 +1660,7 @@ static const struct eth_ops mvneta_ops = {
static const struct udevice_id mvneta_ids[] = {
{ .compatible = "marvell,armada-370-neta" },
+ { .compatible = "marvell,armada-ac5-neta" },
{ .compatible = "marvell,armada-xp-neta" },
{ .compatible = "marvell,armada-3700-neta" },
{ }
--
2.37.3
[PATCH v5 2/5] usb: ehci: ehci-marvell: Support for marvell,ac5-ehci
Unlike the other 64-bit mvebu SoCs the AlleyCat5 uses the older ehci
block from the 32-bit SoCs. Adapt the ehci-marvell.c driver to cope with
the fact that the ac5 does not have the mbus infrastructure the 32-bit
SoCs have and ensure USB_EHCI_IS_TDI is selected.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
Changes in v5:
- Minor white space cleanups
- Collect review from Stefan
drivers/usb/host/Kconfig| 1 +
drivers/usb/host/ehci-marvell.c | 53 -
2 files changed, 46 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index a0f48f09a7..628078f495 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -178,6 +178,7 @@ config USB_EHCI_MARVELL
depends on ARCH_MVEBU || ARCH_KIRKWOOD || ARCH_ORION5X
default y
select USB_EHCI_IS_TDI if !ARM64
+ select USB_EHCI_IS_TDI if ALLEYCAT_5
---help---
Enables support for the on-chip EHCI controller on MVEBU SoCs.
diff --git a/drivers/usb/host/ehci-marvell.c b/drivers/usb/host/ehci-marvell.c
index b7e60c690a..6093c8fb0b 100644
--- a/drivers/usb/host/ehci-marvell.c
+++ b/drivers/usb/host/ehci-marvell.c
@@ -48,12 +48,17 @@ struct ehci_mvebu_priv {
fdt_addr_t hcd_base;
};
+#define USB_TO_DRAM_TARGET_ID 0x2
+#define USB_TO_DRAM_ATTR_ID 0x0
+#define USB_DRAM_BASE 0x
+#define USB_DRAM_SIZE 0xfff/* don't overrun u-boot source (was 0x) */
+
/*
* Once all the older Marvell SoC's (Orion, Kirkwood) are converted
* to the common mvebu archticture including the mbus setup, this
* will be the only function needed to configure the access windows
*/
-static void usb_brg_adrdec_setup(void *base)
+static void usb_brg_adrdec_setup(struct udevice *dev, void *base)
{
const struct mbus_dram_target_info *dram;
int i;
@@ -65,16 +70,34 @@ static void usb_brg_adrdec_setup(void *base)
writel(0, base + USB_WINDOW_BASE(i));
}
- for (i = 0; i < dram->num_cs; i++) {
- const struct mbus_dram_window *cs = dram->cs + i;
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ /*
+* use decoding window to map dram address seen by usb to 0x0
+*/
/* Write size, attributes and target id to control register */
- writel(((cs->size - 1) & 0x) | (cs->mbus_attr << 8) |
- (dram->mbus_dram_target_id << 4) | 1,
- base + USB_WINDOW_CTRL(i));
+ writel((USB_DRAM_SIZE << 16) | (USB_TO_DRAM_ATTR_ID << 8) |
+ (USB_TO_DRAM_TARGET_ID << 4) | 1,
+ base + USB_WINDOW_CTRL(0));
/* Write base address to base register */
- writel(cs->base, base + USB_WINDOW_BASE(i));
+ writel(USB_DRAM_BASE, base + USB_WINDOW_BASE(0));
+
+ debug("## AC5 decoding windows, ctrl[%p]=0x%x, base[%p]=0x%x\n",
+ base + USB_WINDOW_CTRL(0), readl(base +
USB_WINDOW_CTRL(0)),
+ base + USB_WINDOW_BASE(0), readl(base +
USB_WINDOW_BASE(0)));
+ } else {
+ for (i = 0; i < dram->num_cs; i++) {
+ const struct mbus_dram_window *cs = dram->cs + i;
+
+ /* Write size, attributes and target id to control
register */
+ writel(((cs->size - 1) & 0x) | (cs->mbus_attr
<< 8) |
+ (dram->mbus_dram_target_id << 4) | 1,
+ base + USB_WINDOW_CTRL(i));
+
+ /* Write base address to base register */
+ writel(cs->base, base + USB_WINDOW_BASE(i));
+ }
}
}
@@ -126,7 +149,7 @@ static int ehci_mvebu_probe(struct udevice *dev)
if (device_is_compatible(dev, "marvell,armada-3700-ehci"))
marvell_ehci_ops.powerup_fixup = marvell_ehci_powerup_fixup;
else
- usb_brg_adrdec_setup((void *)priv->hcd_base);
+ usb_brg_adrdec_setup(dev, (void *)priv->hcd_base);
hccr = (struct ehci_hccr *)(priv->hcd_base + 0x100);
hcor = (struct ehci_hcor *)
@@ -136,6 +159,19 @@ static int ehci_mvebu_probe(struct udevice *dev)
(uintptr_t)hccr, (uintptr_t)hcor,
(uintptr_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase)));
+#define PHY_CALIB_OFFSET 0x808
+ /*
+* Trigger calibration during each usb start/reset:
+* BIT 13 to 0, and then to 1
+*/
+ if (device_is_compatible(dev, "marvell,ac5-ehci")) {
+ void *phy_calib_reg = (void *)(priv->hcd_base +
PHY_CALIB_OFFSET);
+ u32 val = readl(phy_calib_reg) & (~BIT(13));
+
+
[PATCH v5 3/5] pinctrl: mvebu: Add AlleyCat5 support
This uses the same IP block as the Armada-8K SoCs. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese --- (no changes since v4) Changes in v4: - Collect r-by from Stefan drivers/pinctrl/mvebu/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/pinctrl/mvebu/Kconfig b/drivers/pinctrl/mvebu/Kconfig index 574fb4dfb0..7c51d138c8 100644 --- a/drivers/pinctrl/mvebu/Kconfig +++ b/drivers/pinctrl/mvebu/Kconfig @@ -15,7 +15,7 @@ config PINCTRL_ARMADA_37XX Marvell's Armada-37xx SoC. config PINCTRL_ARMADA_8K - depends on ARMADA_8K && PINCTRL_FULL + depends on (ARMADA_8K || ALLEYCAT_5) && PINCTRL_FULL bool "Armada 7k/8k pin control driver" help Support pin multiplexing and pin configuration control on -- 2.37.3
[PATCH v5 4/5] arm: mvebu: Support for 98DX25xx/98DX35xx SoC
Add support for the Allecat5/Alleycat5X SoC. These are L3 switches with
an integrated CPU (referred to as the CnM block in Marvell's
documentation). These have dual ARMv8.2 CPUs (Cortex-A55). This support
has been ported from Marvell's SDK which is based on a much older
version of U-Boot.
Signed-off-by: Chris Packham
---
Changes in v5:
- Minor fixup for checkpatch.pl complaint
Changes in v4:
- Remove unused mvebu_get_nand_clock() (will return in a later series)
- Remove unnecessary #ifdefs
- Misc style cleanups
- Replace CONFIG_MVEBU_SAR with simpler code implemented directly in
soc.c based around get_sar_freq which the 32-bit platforms already
use.
Changes in v3:
- Remove unnecessary dma-ranges property from ethernet nodes (mvneta now
correctly parses the property from the parent node).
- Keep soc_print_clock_info and soc_print_device_info local to
alleycat5.
arch/arm/dts/ac5-98dx25xx.dtsi | 277 +++
arch/arm/dts/ac5-98dx35xx.dtsi | 17 ++
arch/arm/mach-mvebu/Kconfig| 4 +
arch/arm/mach-mvebu/Makefile | 1 +
arch/arm/mach-mvebu/alleycat5/Makefile | 8 +
arch/arm/mach-mvebu/alleycat5/cpu.c| 124 ++
arch/arm/mach-mvebu/alleycat5/soc.c| 298 +
arch/arm/mach-mvebu/alleycat5/soc.h| 7 +
arch/arm/mach-mvebu/arm64-common.c | 5 +
arch/arm/mach-mvebu/include/mach/cpu.h | 4 +
10 files changed, 745 insertions(+)
create mode 100644 arch/arm/dts/ac5-98dx25xx.dtsi
create mode 100644 arch/arm/dts/ac5-98dx35xx.dtsi
create mode 100644 arch/arm/mach-mvebu/alleycat5/Makefile
create mode 100644 arch/arm/mach-mvebu/alleycat5/cpu.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.c
create mode 100644 arch/arm/mach-mvebu/alleycat5/soc.h
diff --git a/arch/arm/dts/ac5-98dx25xx.dtsi b/arch/arm/dts/ac5-98dx25xx.dtsi
new file mode 100644
index 00..3c68355f32
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx25xx.dtsi
@@ -0,0 +1,277 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For AC5.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+
+#include
+#include
+
+/ {
+ model = "Marvell AC5 SoC";
+ compatible = "marvell,ac5";
+ interrupt-parent = <&gic>;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ cpus {
+ #address-cells = <2>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x0>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ cpu1: cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a55";
+ reg = <0x0 0x100>;
+ enable-method = "psci";
+ next-level-cache = <&l2>;
+ };
+
+ l2: l2-cache {
+ compatible = "cache";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = ,
+,
+,
+;
+ };
+
+ pmu {
+ compatible = "arm,armv8-pmuv3";
+ interrupts = ;
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+ dma-ranges;
+
+ internal-regs@7f00 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ /* 16M internal register @ 0x7f00_ */
+ ranges = <0x0 0x0 0x7f00 0x100>;
+ dma-coherent;
+
+ uart0: serial@12000 {
+ compatible = "snps,dw-apb-uart";
+ reg = <0x12000 0x100>;
+ reg-shift = <2>;
+ interrupts
[PATCH v5 5/5] arm: mvebu: Add RD-AC5X board
The RD-AC5X-32G16HVG6HLG-A0 development board main components and
features include:
* Main 12V/54V power supply
* 270 Gbps throughput packet processor on the main board
* DDR4:
* SR1: 2GB DDR4 2400MT/S(1GB x 2 pcs ) with ECC(1GB x 1 pcs)
* SR2: 4GB DDR4 2400MT/S(2GB x 2 pcs ) with ECC(2GB x 1 pcs)
* PCB co-layout with 4GB device to support 8GB (Dual CS) requirement
* 16GB eMMC (Samsung KLMAG1JETD-B041006)
* 16MB SPI NOR(GD25Q127C)
* 32 x 1000 Base-T interfaces
* 16 x 2500 Base-T interfaces
* SR1: 88E2540*4
* SR2: 88E2580*1+88E2540*2
* Six (6) x 25G Base-R SFP28 interfaces
* One (1) x RJ-45 console connector, interfacing to the on board UART
* One (1) x USB Type-A connector, interfacing to the USB 2.0 port (0)
* One (1) x USB Type-mini B connector, interfacing to the USB 2.0 port (1)
* One (1) x RJ-45 1G Base-T Management port, interfacing to the host
port (shared with PCIe) Connected to 88E1512 Gigabit Ethernet Phy
* One (1) x Oculink port, interfacing to the PCIe port for external CPU
connection
* POE 802.3AT support on Port 1 ~ Port 32, 802.3BT support on Port 33 ~
Port 48 (Microsemi PD69208T4, PD69208M or TI TPS2388,TPS23881
solution)
* POE total power budget 780W
* LED interfaces per network port/POE
* LED interfaces (common) showing system status
* PTP TC mode Supported (Reserved M.2 connector to support BC mode)
Signed-off-by: Chris Packham
---
Changes in v5:
- Remove unused bpard_{early,late}_init{,_r,_f} functions
- Remove CONFIG_PCI and CONFIG_E1000 as the PCI interface is not
currently working (requires more vendor code)
- Use CONFIG_OF_SEPARATE instead of CONFIG_OF_EMBED
Changes in v4:
- Move CONFIG_DISPLAY_BOARDINFO_LATE and CONFIG_ENV_OVERWRITE to
the defconfig.
- Remove CONFIG_BAUDRATE as this is already set in the default config
- Remove CONFIG_USB_MAX_CONTROLLER_COUNT as this is not needed with
DM_USB
- Remove CONFIG_PREBOOT as we don't have anything to run
- Remove commented out CONFIG_BOARD_EARLY_INIT_R
- Remove DEBUG_UART configuration
- Remove unnecessary console environment variable
- Remove CONFIG_MVEBU_SAR
Changes in v3:
- Remove MMC and UBIFS distroboot options (MMC driver is not currently
functional, NAND is not populated on the RD-AC5X board)
- Remove unnecessary Ethernet configuration
- Remove unnecessary NAND configuration
- Remove memory node from dts so the value passed by the DDR FW will be
used
Changes in v2:
- Use distro boot by default
- remove unnecessary SPI-NOR partitions
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/ac5-98dx35xx-rd.dts | 129 +
arch/arm/mach-mvebu/Kconfig| 9 +-
board/Marvell/mvebu_alleycat-5/MAINTAINERS | 6 +
board/Marvell/mvebu_alleycat-5/Makefile| 3 +
board/Marvell/mvebu_alleycat-5/board.c | 13 +++
configs/mvebu_ac5_rd_defconfig | 80 +
include/configs/mvebu_alleycat-5.h | 42 +++
8 files changed, 283 insertions(+), 2 deletions(-)
create mode 100644 arch/arm/dts/ac5-98dx35xx-rd.dts
create mode 100644 board/Marvell/mvebu_alleycat-5/MAINTAINERS
create mode 100644 board/Marvell/mvebu_alleycat-5/Makefile
create mode 100644 board/Marvell/mvebu_alleycat-5/board.c
create mode 100644 configs/mvebu_ac5_rd_defconfig
create mode 100644 include/configs/mvebu_alleycat-5.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 965895bc2a..57a5272884 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -274,7 +274,8 @@ dtb-$(CONFIG_ARCH_MVEBU) += \
cn9132-db-A.dtb \
cn9132-db-B.dtb \
cn9130-crb-A.dtb\
- cn9130-crb-B.dtb
+ cn9130-crb-B.dtb\
+ ac5-98dx35xx-rd.dtb
endif
dtb-$(CONFIG_ARCH_SYNQUACER) += synquacer-sc2a11-developerbox.dtb
diff --git a/arch/arm/dts/ac5-98dx35xx-rd.dts b/arch/arm/dts/ac5-98dx35xx-rd.dts
new file mode 100644
index 00..d9f217cd4a
--- /dev/null
+++ b/arch/arm/dts/ac5-98dx35xx-rd.dts
@@ -0,0 +1,129 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device Tree For RD-AC5X.
+ *
+ * Copyright (C) 2021 Marvell
+ * Copyright (C) 2022 Allied Telesis Labs
+ */
+/*
+ * Device Tree file for Marvell Alleycat 5X development board
+ * This board file supports the B configuration of the board
+ */
+
+/dts-v1/;
+
+#include "ac5-98dx35xx.dtsi"
+
+/ {
+ model = "Marvell RD-AC5X Board";
+ compatible = "marvell,rd-ac5x", "marvell,ac5x", "marvell,ac5";
+
+ aliases {
+ serial0 = &uart0;
+ spiflash0 = &spiflash0;
+ gpio0 = &gpio0;
+ gpio1 = &gpio1;
+ ethernet0 = ð0;
+ ethernet1 = ð1;
+ spi0 = &spi0;
+ i2c0 = &i2c0;
+ i2c1 = &i2c1;
+ usb0 = &usb0;
+
Re: [PATCH] arm: mvebu: mbus: Fix mbus driver to work also after U-Boot relocation
Hi Pali,
On 11/08/22 00:46, Pali Rohár wrote:
> mbus driver is initialized from arch_cpu_init() callback which is called
> before relocation. This driver stores lot of functions and structure
> pointers into global variables, so it is data position dependent.
>
> Therefore after relocations all pointers are invalid and driver does not
> work anymore as all pointers referes to the old memory, which overlaps with
> CONFIG_SYS_LOAD_ADDR and ${loadaddr}.
>
> For example U-Boot fuse command crashes if loadaddr memory is cleared or
> rewritten by some image loaded by U-Boot load command.
>
>mw.w ${loadaddr} 0x0 1
>fuse read 0 1 2
>
> Fix this issue by removing of all mbus global variables in which are stored
> pointers to structures or functions which changes during relocation. And
> replace it by direct function calls (not via pointers). With this change
> fuse command finally works.
>
> Signed-off-by: Pali Rohár
Reviewed-by: Chris Packham
> ---
> arch/arm/mach-kirkwood/include/mach/cpu.h | 3 -
> arch/arm/mach-mvebu/include/mach/cpu.h| 3 -
> arch/arm/mach-mvebu/mbus.c| 167 +-
> board/alliedtelesis/x530/x530.c | 2 +-
> board/maxbcm/maxbcm.c | 8 +-
> board/theadorable/theadorable.c | 4 +-
> include/linux/mbus.h | 13 +-
> 7 files changed, 75 insertions(+), 125 deletions(-)
>
> diff --git a/arch/arm/mach-kirkwood/include/mach/cpu.h
> b/arch/arm/mach-kirkwood/include/mach/cpu.h
> index 71c546f9acf6..d8639c60352b 100644
> --- a/arch/arm/mach-kirkwood/include/mach/cpu.h
> +++ b/arch/arm/mach-kirkwood/include/mach/cpu.h
> @@ -144,9 +144,6 @@ struct kwgpio_registers {
> u32 irq_level;
> };
>
> -/* Needed for dynamic (board-specific) mbus configuration */
> -extern struct mvebu_mbus_state mbus_state;
> -
> /*
>* functions
>*/
> diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
> b/arch/arm/mach-mvebu/include/mach/cpu.h
> index 689c96bd4eac..d9fa1f32aa52 100644
> --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> @@ -122,9 +122,6 @@ struct sar_freq_modes {
> u32 d_clk;
> };
>
> -/* Needed for dynamic (board-specific) mbus configuration */
> -extern struct mvebu_mbus_state mbus_state;
> -
> /*
>* functions
>*/
> diff --git a/arch/arm/mach-mvebu/mbus.c b/arch/arm/mach-mvebu/mbus.c
> index 3b1b9f73ebf6..7092f6cc10c2 100644
> --- a/arch/arm/mach-mvebu/mbus.c
> +++ b/arch/arm/mach-mvebu/mbus.c
> @@ -88,31 +88,34 @@
>
> #define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
>
> -struct mvebu_mbus_state;
> -
> -struct mvebu_mbus_soc_data {
> - unsigned int num_wins;
> - unsigned int num_remappable_wins;
> - unsigned int (*win_cfg_offset)(const int win);
> - void (*setup_cpu_target)(struct mvebu_mbus_state *s);
> -};
> -
> -struct mvebu_mbus_state mbus_state
> - __section(".data");
> static struct mbus_dram_target_info mbus_dram_info
> __section(".data");
>
> +#if defined(CONFIG_ARCH_MVEBU)
> + #define MVEBU_MBUS_NUM_WINS 20
> + #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 8
> + #define MVEBU_MBUS_WIN_CFG_OFFSET(win)
> armada_370_xp_mbus_win_offset(win)
> +#elif defined(CONFIG_ARCH_KIRKWOOD)
> + #define MVEBU_MBUS_NUM_WINS 8
> + #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 4
> + #define MVEBU_MBUS_WIN_CFG_OFFSET(win) orion5x_mbus_win_offset(win)
> +#else
> + #error "No supported architecture"
> +#endif
> +
> +static unsigned int armada_370_xp_mbus_win_offset(int win);
> +static unsigned int orion5x_mbus_win_offset(int win);
> +
> /*
>* Functions to manipulate the address decoding windows
>*/
>
> -static void mvebu_mbus_read_window(struct mvebu_mbus_state *mbus,
> -int win, int *enabled, u64 *base,
> +static void mvebu_mbus_read_window(int win, int *enabled, u64 *base,
> u32 *size, u8 *target, u8 *attr,
> u64 *remap)
> {
> - void __iomem *addr = mbus->mbuswins_base +
> - mbus->soc->win_cfg_offset(win);
> + void __iomem *addr = (void __iomem *)MVEBU_CPU_WIN_BASE +
> + MVEBU_MBUS_WIN_CFG_OFFSET(win);
> u32 basereg = readl(addr + WIN_BASE_OFF);
> u32 ctrlreg = readl(addr + WIN_CTRL_OFF);
>
> @@ -133,7 +136,7 @@ static void mvebu_mbus_read_window(struct
> mvebu_mbus_state *mbus,
> *attr = (ctrlreg & WIN_CTRL_ATTR_MASK) >> WIN_CTRL_ATTR_SHIFT;
>
> if (remap) {
> -
Re: [PATCH] arm: mvebu: mbus: Fix mbus driver to work also after U-Boot relocation
Hi Pali,
On 23/08/22 11:00, Pali Rohár wrote:
> On Wednesday 17 August 2022 08:17:36 Stefan Roese wrote:
>> On 10.08.22 14:46, Pali Rohár wrote:
>>> mbus driver is initialized from arch_cpu_init() callback which is called
>>> before relocation. This driver stores lot of functions and structure
>>> pointers into global variables, so it is data position dependent.
>>>
>>> Therefore after relocations all pointers are invalid and driver does not
>>> work anymore as all pointers referes to the old memory, which overlaps with
>>> CONFIG_SYS_LOAD_ADDR and ${loadaddr}.
>>>
>>> For example U-Boot fuse command crashes if loadaddr memory is cleared or
>>> rewritten by some image loaded by U-Boot load command.
>>>
>>> mw.w ${loadaddr} 0x0 1
>>> fuse read 0 1 2
>>>
>>> Fix this issue by removing of all mbus global variables in which are stored
>>> pointers to structures or functions which changes during relocation. And
>>> replace it by direct function calls (not via pointers). With this change
>>> fuse command finally works.
>>>
>>> Signed-off-by: Pali Rohár
>> Reviewed-by: Stefan Roese
>>
>> Thanks,
>> Stefan
> Stefan, this is something which is needed to have fixed. Could you test
> this change on your boards and prepare for merging to master branch?
>
> Chris, could you also test this change for possible regressions?
>
> I have tested it on A385 Turris Omnia.
I see I'm a little late to the testing party but I've just checked what
was merged on an x530 and it's all good there.
>>> ---
>>>arch/arm/mach-kirkwood/include/mach/cpu.h | 3 -
>>>arch/arm/mach-mvebu/include/mach/cpu.h| 3 -
>>>arch/arm/mach-mvebu/mbus.c| 167 +-
>>>board/alliedtelesis/x530/x530.c | 2 +-
>>>board/maxbcm/maxbcm.c | 8 +-
>>>board/theadorable/theadorable.c | 4 +-
>>>include/linux/mbus.h | 13 +-
>>>7 files changed, 75 insertions(+), 125 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-kirkwood/include/mach/cpu.h
>>> b/arch/arm/mach-kirkwood/include/mach/cpu.h
>>> index 71c546f9acf6..d8639c60352b 100644
>>> --- a/arch/arm/mach-kirkwood/include/mach/cpu.h
>>> +++ b/arch/arm/mach-kirkwood/include/mach/cpu.h
>>> @@ -144,9 +144,6 @@ struct kwgpio_registers {
>>> u32 irq_level;
>>>};
>>> -/* Needed for dynamic (board-specific) mbus configuration */
>>> -extern struct mvebu_mbus_state mbus_state;
>>> -
>>>/*
>>> * functions
>>> */
>>> diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h
>>> b/arch/arm/mach-mvebu/include/mach/cpu.h
>>> index 689c96bd4eac..d9fa1f32aa52 100644
>>> --- a/arch/arm/mach-mvebu/include/mach/cpu.h
>>> +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
>>> @@ -122,9 +122,6 @@ struct sar_freq_modes {
>>> u32 d_clk;
>>>};
>>> -/* Needed for dynamic (board-specific) mbus configuration */
>>> -extern struct mvebu_mbus_state mbus_state;
>>> -
>>>/*
>>> * functions
>>> */
>>> diff --git a/arch/arm/mach-mvebu/mbus.c b/arch/arm/mach-mvebu/mbus.c
>>> index 3b1b9f73ebf6..7092f6cc10c2 100644
>>> --- a/arch/arm/mach-mvebu/mbus.c
>>> +++ b/arch/arm/mach-mvebu/mbus.c
>>> @@ -88,31 +88,34 @@
>>>#define DOVE_DDR_BASE_CS_OFF(n) ((n) << 4)
>>> -struct mvebu_mbus_state;
>>> -
>>> -struct mvebu_mbus_soc_data {
>>> - unsigned int num_wins;
>>> - unsigned int num_remappable_wins;
>>> - unsigned int (*win_cfg_offset)(const int win);
>>> - void (*setup_cpu_target)(struct mvebu_mbus_state *s);
>>> -};
>>> -
>>> -struct mvebu_mbus_state mbus_state
>>> - __section(".data");
>>>static struct mbus_dram_target_info mbus_dram_info
>>> __section(".data");
>>> +#if defined(CONFIG_ARCH_MVEBU)
>>> + #define MVEBU_MBUS_NUM_WINS 20
>>> + #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 8
>>> + #define MVEBU_MBUS_WIN_CFG_OFFSET(win)
>>> armada_370_xp_mbus_win_offset(win)
>>> +#elif defined(CONFIG_ARCH_KIRKWOOD)
>>> + #define MVEBU_MBUS_NUM_WINS 8
>>> + #define MVEBU_MBUS_NUM_REMAPPABLE_WINS 4
>>> + #define MVEBU_MBUS_WIN_CFG_OFFSET(win) orion5x_mbus_win_offset(win)
>>> +#else
>>> + #error "No supported architecture"
>>> +#endif
>>> +
>>> +static unsigned int armada_370_xp_mbus_win_offset(int win);
>>> +static unsigned int orion5x_mbus_win_offset(int win);
>>> +
>>>/*
>>> * Functions to manipulate the address decoding windows
>>> */
>>> -static void mvebu_mbus_read_window(struct mvebu_mbus_state *mbus,
>>> - int win, int *enabled, u64 *base,
>>> +static void mvebu_mbus_read_window(int win, int *enabled, u64 *base,
>>>u32 *size, u8 *target, u8 *attr,
>>>u64 *remap)
>>>{
>>> - void __iomem *addr = mbus->mbuswins_base +
>>> - mbus->soc->win_cfg_offset(win);
>>> + void __iomem *addr = (void __iomem *)MVEBU_CPU_WIN_BASE +
>>> + MVEBU_MBUS_WIN_CFG_OFFSET(win);
>>> u32 basereg = readl(addr + WIN_BASE_OFF);
>>> u32 ctrlr
[PATCH] mtd: nand: pxa3xx: simplify ECC hardware parameters
Replace the if/else chain in pxa_ecc_init() with a lookup table. This
makes the code more concise and hopefully easier to follow. Remove the
unused ecc_layout tables and replace it with a single dummy one (the
pxa3xx driver has never used this but the mtd subsystem expects it to be
provided).
Tested on an Allied Telesis x530 switch with Micron MT29F2G08ABAEAWP
NAND Flash.
Signed-off-by: Chris Packham
---
This code was taken from the Marvell SDK for the AC5/AC5X integrated
switch/CPU. There are other changes to support the SoC which I will
likely attempt to upstream soon but I think this stands on it's own
merit as a nice clean up.
Reports of testing on other combinations of hardware would be greatly
appreciated.
drivers/mtd/nand/raw/pxa3xx_nand.c | 247 -
1 file changed, 68 insertions(+), 179 deletions(-)
diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
b/drivers/mtd/nand/raw/pxa3xx_nand.c
index 9c29e8a6c214..fcd1b9c63614 100644
--- a/drivers/mtd/nand/raw/pxa3xx_nand.c
+++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
@@ -330,89 +330,44 @@ static struct nand_bbt_descr bbt_mirror_descr = {
};
#endif
-static struct nand_ecclayout ecc_layout_2KB_bch4bit = {
- .eccbytes = 32,
- .eccpos = {
- 32, 33, 34, 35, 36, 37, 38, 39,
- 40, 41, 42, 43, 44, 45, 46, 47,
- 48, 49, 50, 51, 52, 53, 54, 55,
- 56, 57, 58, 59, 60, 61, 62, 63},
- .oobfree = { {2, 30} }
+struct marvell_hw_ecc_layout {
+ int page_size;
+ int strength;
+ unsigned intecc_size;
+ unsigned intnfullchunks;
+ unsigned intchunk_size;
+ unsigned intspare_size;
+ unsigned intlast_chunk_size;
+ unsigned intlast_spare_size;
};
-static struct nand_ecclayout ecc_layout_2KB_bch8bit = {
- .eccbytes = 64,
- .eccpos = {
- 32, 33, 34, 35, 36, 37, 38, 39,
- 40, 41, 42, 43, 44, 45, 46, 47,
- 48, 49, 50, 51, 52, 53, 54, 55,
- 56, 57, 58, 59, 60, 61, 62, 63,
- 64, 65, 66, 67, 68, 69, 70, 71,
- 72, 73, 74, 75, 76, 77, 78, 79,
- 80, 81, 82, 83, 84, 85, 86, 87,
- 88, 89, 90, 91, 92, 93, 94, 95},
- .oobfree = { {1, 4}, {6, 26} }
+static const struct marvell_hw_ecc_layout nfc_layouts[] = {
+ /* page_size strength ecc_size nfullchunks chunk_size spare_size
last_chunk last_spare */
+ { 512, 1, 8, 1, 512,8,
0, 0 },
+ {2048, 1, 24, 1,2048, 40,
0, 0 },
+
+ {2048, 4, 32, 1,2048, 32,
0, 0 },
+ {2048, 8, 32, 1,1024,0,
1024,32 },
+ {2048, 12, 32, 2, 704,0,
640, 0 },
+ {2048, 16, 32, 4, 512,0,
0,32 },
+ {4096, 4, 32, 2,2048, 32,
0, 0 },
+ {4096, 8, 32, 4,1024,0,
0,64 },
+ {4096, 12, 32, 5, 704,0,
576,32 },
+ {4096, 16, 32, 8, 512,0,
0,32 },
+
+ {8192, 4, 32, 4,2048, 32,
0, 0 },
+ {8192, 8, 32, 8,1024,0,
0, 160 },
+ {8192, 12, 32,11, 704,0,
448,64 },
+ {8192, 16, 32,16, 512,0,
0,32 },
+ { },
};
-static struct nand_ecclayout ecc_layout_4KB_bch4bit = {
- .eccbytes = 64,
- .eccpos = {
- 32, 33, 34, 35, 36, 37, 38, 39,
- 40, 41, 42, 43, 44, 45, 46, 47,
- 48, 49, 50, 51, 52, 53, 54, 55,
- 56, 57, 58, 59, 60, 61, 62, 63,
- 96, 97, 98, 99, 100, 101, 102, 103,
- 104, 105, 106, 107, 108, 109, 110, 111,
- 112, 113, 114, 115, 116, 117, 118, 119,
- 120, 121, 122, 123, 124, 125, 126, 127},
- /* Bootrom looks in bytes 0 & 5 for bad blocks */
- .oobfree = { {6, 26}, { 64, 32} }
-};
-
-static struct nand_ecclayout ecc_layout_8KB_bch4bit = {
- .eccbytes = 128,
- .eccpos = {
- 32, 33, 34, 35, 36, 37, 38, 39,
- 40, 41, 42, 43, 44, 45, 46, 47,
- 48, 49, 50, 51, 52, 53, 54, 55,
- 56, 57, 58, 59, 60, 61, 62, 63,
-
- 96, 97, 98, 99,
[PATCH 1/2] arm: mvebu: x240: Disable SMBIOS
The x240 doesn't make use of EFI or SMBIOS. Recently we started seeing boot failures such as WARNING: SMBIOS table_address overflow 23f60c020 Failed to write SMBIOS table initcall failed at event 10/(unknown) (err=-22) ### ERROR ### Please RESET the board ### The error is because the physical address of the RAM on the AC5X SoC is above the 32GiB boundary. As we don't need SMBIOS or EFI this can be safely disabled. Signed-off-by: Chris Packham --- configs/x240_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/x240_defconfig b/configs/x240_defconfig index 7d2b8603e6f4..0d5a19df25aa 100644 --- a/configs/x240_defconfig +++ b/configs/x240_defconfig @@ -84,3 +84,4 @@ CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y # CONFIG_FAT_WRITE is not set +# CONFIG_SMBIOS is not set -- 2.42.0
[PATCH 2/2] Revert "arm: mvebu: x240: Use i2c-gpio instead of built in controller"
This reverts commit 5c1c6b7306f2b4c0fd50c7cb5d757e245b93606e. The reason
for switching to i2c-gpio was due to an issue we were seeing in the
Linux kernel where the CPU would lock up on certain adverse I2C bus
conditions. We were never able to reproduce the lockup in U-Boot but
assumed that was probably just luck.
Since then we have discovered that the lock up was due to the I2C
transaction offload engine in the I2C controller not coping with the
adverse bus conditions (basically it thinks there's another master and
waits for a STOP condition that never comes). U-Boot doesn't use the I2C
offload feature so is not susceptible to the lockup.
We can therefore safely return to using the built-in I2C controller.
Signed-off-by: Chris Packham
---
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 ++
configs/x240_defconfig | 1 -
2 files changed, 7 insertions(+), 24 deletions(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
index c19b25925ba2..820ec18b4355 100644
--- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -16,7 +16,7 @@
gpio0 = &gpio0;
gpio1 = &gpio1;
spi0 = &spi0;
- i2c0 = &i2cgpio;
+ i2c0 = &i2c0;
usb0 = &usb0;
pinctrl0 = &pinctrl0;
};
@@ -40,19 +40,6 @@
default-state = "on";
};
};
-
- i2cgpio: i2c-gpio-0 {
- compatible = "i2c-gpio";
- #address-cells = <1>;
- #size-cells = <0>;
-
- pinctrl-names = "default";
- pinctrl-0 = <&i2c0_gpio>;
- scl-gpios = <&gpio0 26 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
- sda-gpios = <&gpio0 27 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
- i2c-gpio,delay-us = <2>;
- status = "okay";
-};
};
&nand {
@@ -83,7 +70,9 @@
status = "okay";
};
-&i2cgpio {
+&i2c0 {
+ status = "okay";
+
mux@71 {
#address-cells = <1>;
#size-cells = <0>;
@@ -188,8 +177,8 @@
* LED_OE_N [23]
* USB_PWR_FLT_N [24]
* SFP_INT_N [25]
-* I2C0_SCL [26] (GPIO)
-* I2C0_SDA [27] (GPIO)
+* I2C0_SCL [26]
+* I2C0_SDA [27]
* USB_EN[28]
* MONITOR_INT_N [29]
* XM1_MDC [30]
@@ -212,7 +201,7 @@
/* 0123456789 */
pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 11110xff 0xff 00
-0000000xff 0xff 00
+0000001100
1111000000
000111>;
@@ -220,9 +209,4 @@
marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
marvell,function = <2>;
};
-
- i2c0_gpio: i2c0-gpio-pins {
- marvell,pins = <26 27>;
- marvell,function = <0>;
- };
};
diff --git a/configs/x240_defconfig b/configs/x240_defconfig
index 0d5a19df25aa..4b1a761a9086 100644
--- a/configs/x240_defconfig
+++ b/configs/x240_defconfig
@@ -42,7 +42,6 @@ CONFIG_CLK_MVEBU=y
CONFIG_GPIO_HOG=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
-CONFIG_DM_I2C_GPIO=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
--
2.42.0
[PATCH v2 1/2] i2c: i2c-gpio: Correctly handle new {sda, scl}-gpios bindings
gpio_request_list_by_name() returns the number of gpios requested.
Notably it swallows the underlying -ENOENT when the "gpios" property
does not exist.
Update the i2c-gpio driver to check for ret == 0 before trying the new
sda-gpios/scl-gpios properties.
Signed-off-by: Chris Packham
---
This was originally sent as a single patch[1]. I've rolled it into this
series as the board change is dependent on it.
[1] -
https://lore.kernel.org/u-boot/20230720023107.1184147-1-judge.pack...@gmail.com/
(no changes since v1)
drivers/i2c/i2c-gpio.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/i2c/i2c-gpio.c b/drivers/i2c/i2c-gpio.c
index 4ed9e9e7cddd..c1fc290bd253 100644
--- a/drivers/i2c/i2c-gpio.c
+++ b/drivers/i2c/i2c-gpio.c
@@ -339,7 +339,7 @@ static int i2c_gpio_of_to_plat(struct udevice *dev)
/* "gpios" is deprecated and replaced by "sda-gpios" + "scl-gpios". */
ret = gpio_request_list_by_name(dev, "gpios", bus->gpios,
ARRAY_SIZE(bus->gpios), 0);
- if (ret == -ENOENT) {
+ if (ret == 0) {
ret = gpio_request_by_name(dev, "sda-gpios", 0,
&bus->gpios[PIN_SDA], 0);
if (ret < 0)
--
2.41.0
[PATCH v2 2/2] arm: mvebu: x240: Use i2c-gpio instead of built in controller
There is an Errata with the built-in I2C controller where various I2C
hardware errors cause a complete lockup of the CPU (which eventually
results in an watchdog reset).
Put the I2C MPP pins into GPIO mode and use the i2c-gpio driver instead.
This uses a bit-banged implementation of an I2C controller and avoids
triggering the Errata.
Signed-off-by: Chris Packham
Reviewed-by: Stefan Roese
---
Changes in v2:
- Update i2c0 alias
- Move i2c-gpio definition to root of device tree
- Remove &i2c0 instead of just disabling it
- Add r-by from Stefan
arch/arm/dts/ac5-98dx35xx-atl-x240.dts | 30 --
configs/x240_defconfig | 1 +
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
index 820ec18b4355..c19b25925ba2 100644
--- a/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
+++ b/arch/arm/dts/ac5-98dx35xx-atl-x240.dts
@@ -16,7 +16,7 @@
gpio0 = &gpio0;
gpio1 = &gpio1;
spi0 = &spi0;
- i2c0 = &i2c0;
+ i2c0 = &i2cgpio;
usb0 = &usb0;
pinctrl0 = &pinctrl0;
};
@@ -40,6 +40,19 @@
default-state = "on";
};
};
+
+ i2cgpio: i2c-gpio-0 {
+ compatible = "i2c-gpio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_gpio>;
+ scl-gpios = <&gpio0 26 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio0 27 (GPIO_ACTIVE_HIGH |
GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ status = "okay";
+};
};
&nand {
@@ -70,9 +83,7 @@
status = "okay";
};
-&i2c0 {
- status = "okay";
-
+&i2cgpio {
mux@71 {
#address-cells = <1>;
#size-cells = <0>;
@@ -177,8 +188,8 @@
* LED_OE_N [23]
* USB_PWR_FLT_N [24]
* SFP_INT_N [25]
-* I2C0_SCL [26]
-* I2C0_SDA [27]
+* I2C0_SCL [26] (GPIO)
+* I2C0_SDA [27] (GPIO)
* USB_EN[28]
* MONITOR_INT_N [29]
* XM1_MDC [30]
@@ -201,7 +212,7 @@
/* 0123456789 */
pin-func = < 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff 0xff
0xff 0xff 11110xff 0xff 00
-0000001100
+0000000xff 0xff 00
1111000000
000111>;
@@ -209,4 +220,9 @@
marvell,pins = <0 1 2 3 4 5 6 7 8 9 10 11 16 17>;
marvell,function = <2>;
};
+
+ i2c0_gpio: i2c0-gpio-pins {
+ marvell,pins = <26 27>;
+ marvell,function = <0>;
+ };
};
diff --git a/configs/x240_defconfig b/configs/x240_defconfig
index a78cb3ce6cbf..7d2b8603e6f4 100644
--- a/configs/x240_defconfig
+++ b/configs/x240_defconfig
@@ -42,6 +42,7 @@ CONFIG_CLK_MVEBU=y
CONFIG_GPIO_HOG=y
CONFIG_DM_PCA953X=y
CONFIG_DM_I2C=y
+CONFIG_DM_I2C_GPIO=y
CONFIG_SYS_I2C_MVTWSI=y
CONFIG_I2C_MUX=y
CONFIG_I2C_MUX_PCA954x=y
--
2.41.0
Re: [PATCH] mtd: nand: pxa3xx: Fix buffer overflow during raw reads
Hi Pierre,
On Sun, Jul 30, 2023 at 6:08 AM Pierre Bourdon wrote:
>
> Chunked raw reads get accumulated to the data buffer, but in some
> ECC configurations they can end up being larger than the originally
> computed size (write page size + OOB size). For example:
>
> 4K page size, ECC strength 8:
> - Normal reads: writesize (4096B) + oobsize (128B) = 4224 bytes.
> - Chunked raw reads: 4 chunks of 1024B + 1 final spare area of 64B + 5
> ECC areas of 32B = 4320B.
I'm not a NAND expert and I haven't sat down and fully grasped the
math but I was curious to see what the Linux kernel did. It looks like
it uses the same mtd->writesize + mtd->oobsize calculation (see
nand_scan_tail() in nand_base.c). So either Linux has the same bug or
maybe there's something off in u-boot's nfc_layouts[]. I'll see if I
can get one of my boards to trigger a KASAN report (I'm not sure if
any of the NAND chips we use will hit the cases you're pointing out).
>
> Fixes: 6293b0361d9 ("mtd: nand: pxa3xx: add raw read support")
> Signed-off-by: Pierre Bourdon
> ---
>
> drivers/mtd/nand/raw/pxa3xx_nand.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/nand/raw/pxa3xx_nand.c
> b/drivers/mtd/nand/raw/pxa3xx_nand.c
> index d502e967f9..2894ababbe 100644
> --- a/drivers/mtd/nand/raw/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/raw/pxa3xx_nand.c
> @@ -1471,6 +1471,19 @@ static void pxa3xx_nand_detect_config(struct
> pxa3xx_nand_info *info)
>
> static int pxa3xx_nand_init_buff(struct pxa3xx_nand_info *info)
> {
> + unsigned int chunk_size;
> + unsigned int last_chunk_size;
> +
> + /*
> +* The data buffer needs to not only be large enough for normal + OOB
> +* reads, but also for raw reads. The raw reads can end up taking more
> +* space due to the chunking scheme.
> +*/
> + chunk_size = info->chunk_size + info->spare_size + info->ecc_size;
> + last_chunk_size =
> + info->last_chunk_size + info->last_spare_size +
> info->ecc_size;
> + info->buf_size = info->nfullchunks * chunk_size + last_chunk_size;
> +
> info->data_buff = kmalloc(info->buf_size, GFP_KERNEL);
> if (info->data_buff == NULL)
> return -ENOMEM;
> @@ -1661,7 +1674,6 @@ static int pxa3xx_nand_scan(struct mtd_info *mtd)
> kfree(info->data_buff);
>
> /* allocate the real data + oob buffer */
> - info->buf_size = mtd->writesize + mtd->oobsize;
> ret = pxa3xx_nand_init_buff(info);
> if (ret)
> return ret;
> --
> 2.41.0
>
Re: [PATCH] mtd: nand: pxa3xx: Fix buffer overflow during raw reads
On Mon, 31 Jul 2023, 9:29 am Pierre Bourdon, wrote: > On Sun, Jul 30, 2023 at 11:21 PM Chris Packham > wrote: > > On Sun, Jul 30, 2023 at 6:08 AM Pierre Bourdon > wrote: > > > > > > Chunked raw reads get accumulated to the data buffer, but in some > > > ECC configurations they can end up being larger than the originally > > > computed size (write page size + OOB size). For example: > > > > > > 4K page size, ECC strength 8: > > > - Normal reads: writesize (4096B) + oobsize (128B) = 4224 bytes. > > > - Chunked raw reads: 4 chunks of 1024B + 1 final spare area of 64B + 5 > > > ECC areas of 32B = 4320B. > > > > I'm not a NAND expert and I haven't sat down and fully grasped the > > math but I was curious to see what the Linux kernel did. It looks like > > it uses the same mtd->writesize + mtd->oobsize calculation (see > > nand_scan_tail() in nand_base.c). So either Linux has the same bug or > > maybe there's something off in u-boot's nfc_layouts[]. I'll see if I > > can get one of my boards to trigger a KASAN report (I'm not sure if > > any of the NAND chips we use will hit the cases you're pointing out). > > Sure, please let me know. I'm not 100% convinced that this is the > correct fix - I know very little about this driver or NANDs in > general. On the board I'm playing with (Marvell AC3-based) this patch > prevents the driver from corrupting dlmalloc's data structures and > causing u-boot to hang. But it could be that this is just papering > over another root cause. > > The NAND chip is a Micron MT29F4G08ABBEAH4, so nothing too unusual. > Hmm. Both boards I tried had sufficient space in writesize+oobsize. I'll see if I can find others with different nand chips. > Thanks! > Best, > > -- > Pierre Bourdon > Software Engineer @ Zürich, Switzerland > https://delroth.net/ >
Re: [PATCH] mtd: nand: pxa3xx: Fix buffer overflow during raw reads
On Mon, Jul 31, 2023 at 9:29 AM Pierre Bourdon wrote: > > On Sun, Jul 30, 2023 at 11:21 PM Chris Packham > wrote: > > On Sun, Jul 30, 2023 at 6:08 AM Pierre Bourdon wrote: > > > > > > Chunked raw reads get accumulated to the data buffer, but in some > > > ECC configurations they can end up being larger than the originally > > > computed size (write page size + OOB size). For example: > > > > > > 4K page size, ECC strength 8: > > > - Normal reads: writesize (4096B) + oobsize (128B) = 4224 bytes. > > > - Chunked raw reads: 4 chunks of 1024B + 1 final spare area of 64B + 5 > > > ECC areas of 32B = 4320B. > > > > I'm not a NAND expert and I haven't sat down and fully grasped the > > math but I was curious to see what the Linux kernel did. It looks like > > it uses the same mtd->writesize + mtd->oobsize calculation (see > > nand_scan_tail() in nand_base.c). So either Linux has the same bug or > > maybe there's something off in u-boot's nfc_layouts[]. I'll see if I > > can get one of my boards to trigger a KASAN report (I'm not sure if > > any of the NAND chips we use will hit the cases you're pointing out). > > Sure, please let me know. I'm not 100% convinced that this is the > correct fix - I know very little about this driver or NANDs in > general. On the board I'm playing with (Marvell AC3-based) this patch > prevents the driver from corrupting dlmalloc's data structures and > causing u-boot to hang. But it could be that this is just papering > over another root cause. > > The NAND chip is a Micron MT29F4G08ABBEAH4, so nothing too unusual. At least according to the datasheet I can find MT29F4G08ABBEAH4 has a page size of 4320 bytes (4096 + 224 bytes). Perhaps the problem is actually related to the fact that somehow you've ended up with an oobsize of 128. > > Thanks! > Best, > > -- > Pierre Bourdon > Software Engineer @ Zürich, Switzerland > https://delroth.net/
