Re: [PATCH v2 4/6] power: pmic: sunxi: add AXP717 SPL support

[Ryan Walklin]

On Mon, 15 Jul 2024, at 11:38 AM, Andre Przywara wrote:
> On Sun, 14 Jul 2024 20:20:44 +1200
> "Ryan Walklin"  wrote:
>
> Hi Ryan,
>
> I consider the fact that the AXP209 and the AXP717 use the same I2C
> address a sheer coincidence, so would like to keep the code readable
> and maintainable. This "IS_ENABLED(AXPyyy) return AXPyyy_I2C_ADDR"
> patterns seems to be easy to understand and copy, IMHO. If you are
> concerned about generated code size: this whole function is optimised
> away, and is replaced with a single "mov w0, #0x34" assembly
> instruction, just before the respective i2c function calls. This is due
> to the fact that those "if" statements have compile-time constant
> input, so the compiler knows the final result already, and just
> replaces the function call with this constant load. That's a neat
> feature of IS_ENABLED(), and a pattern we are exercising in U-Boot for
> years, to keep the code both readable, but also minimal.

I did wonder if the compiler might optimise this down to a single instruction, 
makes perfect sense in that case and agree regarding code clarity.

In that case, and having also checked the DCDC voltage defaults are reasonable 
for known AXP717-integrating devices in the updated Kconfig:

Reviewed-by: Ryan Walklin 

Regards,

Ryan

Re: [PATCH v2 4/6] power: pmic: sunxi: add AXP717 SPL support

[Ryan Walklin]

Hi Andre,

On Sat, 13 Jul 2024, at 4:53 AM, Andre Przywara wrote:

>  #define AXP209_I2C_ADDR  0x34
> +#define AXP717_I2C_ADDR  0x34
> 
>  #define AXP305_I2C_ADDR  0x36
>  #define AXP313_I2C_ADDR  0x36
> @@ -36,6 +37,8 @@ static int pmic_i2c_address(void)
>   return AXP305_I2C_ADDR;
>   if (IS_ENABLED(CONFIG_AXP313_POWER))
>   return AXP313_I2C_ADDR;
> + if (IS_ENABLED(CONFIG_AXP717_POWER))
> + return AXP717_I2C_ADDR;
> 
>   /* Other AXP2xx and AXP8xx variants */
>   return AXP209_I2C_ADDR;

Small point, but is this check strictly necessary, given that the AXP717 uses 
the same I2C address as the AXP209? If CONFIG_AXP717_POWER is not checked here, 
this logic will still fall through to the default AXP209 address, which will 
also be correct for the 717.

> diff --git a/board/sunxi/board.c b/board/sunxi/board.c
> index ed86f1df5dc..9928069c0eb 100644
> --- a/board/sunxi/board.c
> +++ b/board/sunxi/board.c
> @@ -562,7 +562,7 @@ void sunxi_board_init(void)
>  #if defined CONFIG_AXP152_POWER || defined CONFIG_AXP209_POWER || \
>   defined CONFIG_AXP221_POWER || defined CONFIG_AXP305_POWER || \
>   defined CONFIG_AXP809_POWER || defined CONFIG_AXP818_POWER || \
> - defined CONFIG_AXP313_POWER
> + defined CONFIG_AXP313_POWER || defined CONFIG_AXP717_POWER
>   power_failed = axp_init();
> 
>   if (IS_ENABLED(CONFIG_AXP_DISABLE_BOOT_ON_POWERON) && !power_failed) {
> diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
> index 33b8bc1214d..5556a22cf69 100644
> --- a/drivers/power/Kconfig
> +++ b/drivers/power/Kconfig
> @@ -109,6 +109,13 @@ config AXP313_POWER
>   Select this to enable support for the AXP313 PMIC found on some
>   H616 boards.
> 
> +config AXP717_POWER
> + bool "axp717 pmic support"
> + select AXP_PMIC_BUS
> + select CMD_POWEROFF
> + ---help---
> + Select this to enable support for the AXP717 PMIC found on some boards.
> +
>  config AXP809_POWER
>   bool "axp809 pmic support"
>   depends on MACH_SUN9I
> @@ -151,10 +158,11 @@ config AXP_DCDC1_VOLT
> 
>  config AXP_DCDC2_VOLT
>   int "axp pmic dcdc2 voltage"
> - depends on AXP152_POWER || AXP209_POWER || AXP221_POWER || 
> AXP809_POWER || AXP818_POWER || AXP313_POWER
> + depends on AXP152_POWER || AXP209_POWER || AXP221_POWER || 
> AXP809_POWER || AXP818_POWER || AXP313_POWER || AXP717_POWER
>   default 900 if AXP818_POWER
>   default 1400 if AXP152_POWER || AXP209_POWER
>   default 1000 if AXP313_POWER
> + default 1000 if AXP717_POWER
>   default 1200 if MACH_SUN6I
>   default 1100 if MACH_SUN8I
>   default 0 if MACH_SUN9I
> @@ -167,11 +175,11 @@ config AXP_DCDC2_VOLT
>   On A80 boards dcdc2 powers the GPU and can be left off.
>   On A83T boards dcdc2 is used for VDD-CPUA(cluster 0) and should be 
> 0.9V.
>   On R40 boards dcdc2 is VDD-CPU and should be 1.1V
> - On boards using the AXP313 it's often VDD-CPU.
> + On boards using the AXP313 or AXP717 it's often VDD-CPU.
> 
>  config AXP_DCDC3_VOLT
>   int "axp pmic dcdc3 voltage"
> - depends on AXP152_POWER || AXP209_POWER || AXP221_POWER || 
> AXP809_POWER || AXP818_POWER || AXP313_POWER
> + depends on AXP152_POWER || AXP209_POWER || AXP221_POWER || 
> AXP809_POWER || AXP818_POWER || AXP313_POWER || AXP717_POWER
>   default 900 if AXP809_POWER || AXP818_POWER
>   default 1500 if AXP152_POWER
>   default 1250 if AXP209_POWER
> @@ -188,7 +196,8 @@ config AXP_DCDC3_VOLT
>   On A80 boards dcdc3 is used for VDD-CPUA(cluster 0) and should be 
> 0.9V.
>   On A83T boards dcdc3 is used for VDD-CPUB(cluster 1) and should be 
> 0.9V.
>   On R40 boards dcdc3 is VDD-SYS and VDD-GPU and should be 1.1V.
> - On boards using the AXP313 it's often VDD-DRAM and should be 1.1V for 
> LPDDR4.
> + On boards using the AXP313 or AXP717 it's often VDD-DRAM and should
> + be 1.1V for LPDDR4.
> 
>  config AXP_DCDC4_VOLT
>   int "axp pmic dcdc4 voltage"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index 0f39459dec4..6df23a81c29 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_AXP209_POWER)  += axp209.o
>  obj-$(CONFIG_AXP221_POWER)   += axp221.o
>  obj-$(CONFIG_AXP305_POWER)   += axp305.o
>  obj-$(CONFIG_AXP313_POWER)   += axp313.o
> +obj-$(CONFIG_AXP717_POWER)   += axp_spl.o
>  obj-$(CONFIG_AXP809_POWER)   += axp809.o
>  obj-$(CONFIG_AXP818_POWER)   += axp818.o
>  endif
> -- 
> 2.25.1

Tested with RG35XX-H and RG35XX-Plus boards (Allwinner H700 with AXP717). 
Confirmed both DCDC2 and DCDC3 are set correctly in SPL, allowing successful 
DRAM init and boot.

Tested-by: Ryan Walklin 

Regards,

Ryan

Re: [PATCH] sunxi: spl: h616: fix booting from high MMC offset

[Ryan Walklin]

On Fri, 10 May 2024, at 11:13 AM, Andre Przywara wrote:

> Extend the existing offset calculation code to consider the different
> sector offset when running on an H616 SoC. This allows to load U-Boot
> on any H616 device when the SPL is not located at 8KB.

Thanks Andre,

Confirmed with an H700-based board and u-boot at the 512-sector/256KB offset.

Tested-by: Ryan Walklin 

Regards,

Ryan

Re: [PATCH 2/2] power: regulator: add AXP717 support

[Ryan Walklin]

On Fri, 10 May 2024, at 11:43 AM, Andre Przywara wrote:
> The X-Powers AXP717 is a PMIC with four buck converters and a number
> of LDOs, one of which is actually fixed (so not modelled here).
>
> Add the compatible string and the respective regulator ranges to allow
> drivers to adjust voltages.
>
> Signed-off-by: Andre Przywara 
> ---
>  drivers/power/pmic/axp.c|  1 +
>  drivers/power/regulator/axp_regulator.c | 28 +
>  include/axp_pmic.h  |  1 +
>  3 files changed, 30 insertions(+)
>
> diff --git a/drivers/power/pmic/axp.c b/drivers/power/pmic/axp.c
> index fdf9ff66c29..c300fd2bbc2 100644
> --- a/drivers/power/pmic/axp.c
> +++ b/drivers/power/pmic/axp.c
> @@ -89,6 +89,7 @@ static const struct udevice_id axp_pmic_ids[] = {
>   { .compatible = "x-powers,axp221", .data = AXP221_ID },
>   { .compatible = "x-powers,axp223", .data = AXP223_ID },
>   { .compatible = "x-powers,axp313a", .data = AXP313_ID },
> + { .compatible = "x-powers,axp717", .data = AXP717_ID },
>   { .compatible = "x-powers,axp803", .data = AXP803_ID },
>   { .compatible = "x-powers,axp806", .data = AXP806_ID },
>   { .compatible = "x-powers,axp809", .data = AXP809_ID },
> diff --git a/drivers/power/regulator/axp_regulator.c 
> b/drivers/power/regulator/axp_regulator.c
> index d27e09538e0..75cdbca30f6 100644
> --- a/drivers/power/regulator/axp_regulator.c
> +++ b/drivers/power/regulator/axp_regulator.c
> @@ -189,6 +189,33 @@ static const struct axp_regulator_plat 
> axp313_regulators[] = {
>   { }
>  };
> 
> +/*
> + * The "dcdc2" regulator has another range, beyond 1.54V up to 3.4V, in
> + * steps of 100mV. We cannot model this easily, but also don't need 
> that,
> + * since it's typically only used for lower voltages anyway, so just 
> ignore it.
> + */
> +static const struct axp_regulator_plat axp717_regulators[] = {
> + { "dcdc1", 0x80, BIT(0), 0x83, 0x7f,  500, 1540,  10, 70 },
> + { "dcdc2", 0x80, BIT(1), 0x84, 0x7f,  500, 1540,  10, 70 },
> + { "dcdc3", 0x80, BIT(2), 0x85, 0x7f,  500, 1840,  10, 70 },
> + { "dcdc4", 0x80, BIT(3), 0x86, 0x7f, 1000, 3700, 100, NA },
> + { "aldo1", 0x90, BIT(0), 0x93, 0x1f,  500, 3500, 100, NA },
> + { "aldo2", 0x90, BIT(1), 0x94, 0x1f,  500, 3500, 100, NA },
> + { "aldo3", 0x90, BIT(2), 0x95, 0x1f,  500, 3500, 100, NA },
> + { "aldo4", 0x90, BIT(3), 0x96, 0x1f,  500, 3500, 100, NA },
> + { "bldo1", 0x90, BIT(4), 0x97, 0x1f,  500, 3500, 100, NA },
> + { "bldo2", 0x90, BIT(5), 0x98, 0x1f,  500, 3500, 100, NA },
> + { "bldo3", 0x90, BIT(6), 0x99, 0x1f,  500, 3500, 100, NA },
> + { "bldo4", 0x90, BIT(7), 0x9a, 0x1f,  500, 3500, 100, NA },
> + { "cldo1", 0x91, BIT(0), 0x9b, 0x1f,  500, 3500, 100, NA },
> + { "cldo2", 0x91, BIT(1), 0x9c, 0x1f,  500, 3500, 100, NA },
> + { "cldo3", 0x91, BIT(2), 0x9d, 0x1f,  500, 3500, 100, NA },
> + { "cldo4", 0x91, BIT(3), 0x9e, 0x1f,  500, 3500, 100, NA },
> + {"cpusldo",0x91, BIT(4), 0x9f, 0x1f,  500, 1400,  50, NA },
> + {" boost", 0x19, BIT(4), 0x1e, 0xf0, 4550, 5510,  64, NA },
> + { }
> +};
> +
>  static const struct axp_regulator_plat axp803_regulators[] = {
>   { "dcdc1", 0x10, BIT(0), 0x20, 0x1f, 1600, 3400, 100, NA },
>   { "dcdc2", 0x10, BIT(1), 0x21, 0x7f,  500, 1300,  10, 70 },
> @@ -291,6 +318,7 @@ static const struct axp_regulator_plat *const 
> axp_regulators[] = {
>   [AXP221_ID] = axp22x_regulators,
>   [AXP223_ID] = axp22x_regulators,
>   [AXP313_ID] = axp313_regulators,
> + [AXP717_ID] = axp717_regulators,
>   [AXP803_ID] = axp803_regulators,
>   [AXP806_ID] = axp806_regulators,
>   [AXP809_ID] = axp809_regulators,
> diff --git a/include/axp_pmic.h b/include/axp_pmic.h
> index aabafc8501b..ae62ef0d76d 100644
> --- a/include/axp_pmic.h
> +++ b/include/axp_pmic.h
> @@ -33,6 +33,7 @@ enum {
>   AXP221_ID,
>   AXP223_ID,
>   AXP313_ID,
> + AXP717_ID,
>   AXP803_ID,
>   AXP806_ID,
>   AXP809_ID,
> -- 
> 2.35.8


Confirmed working on H700 board with AXP717 PMIC and LPDDR4 DRAM controller 
(Anbernic RG35XX-H). Registers and voltage ranges confirmed from datasheet.

Reviewed-by: Ryan Walklin 

Regards,

Ryan

Re: [PATCH 1/2] power: pmic: sunxi: add AXP717 SPL driver

[Ryan Walklin]

DRAM and should be 1.1V for 
> LPDDR4.
> + On boards using the AXP313 or AXP717 it's often VDD-DRAM and should
> + be 1.1V for LPDDR4.
> 
>  config AXP_DCDC4_VOLT
>   int "axp pmic dcdc4 voltage"
> diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> index c7ee4595fc8..41ebb494fff 100644
> --- a/drivers/power/Makefile
> +++ b/drivers/power/Makefile
> @@ -13,6 +13,7 @@ obj-$(CONFIG_AXP209_POWER)  += axp209.o
>  obj-$(CONFIG_AXP221_POWER)   += axp221.o
>  obj-$(CONFIG_AXP305_POWER)   += axp305.o
>  obj-$(CONFIG_AXP313_POWER)   += axp313.o
> +obj-$(CONFIG_AXP717_POWER)   += axp717.o
>  obj-$(CONFIG_AXP809_POWER)   += axp809.o
>  obj-$(CONFIG_AXP818_POWER)   += axp818.o
>  obj-$(CONFIG_EXYNOS_TMU) += exynos-tmu.o
> diff --git a/drivers/power/axp717.c b/drivers/power/axp717.c
> new file mode 100644
> index 000..7c77c09ea8f
> --- /dev/null
> +++ b/drivers/power/axp717.c
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * AXP717 SPL driver
> + * (C) Copyright 2024 Arm Ltd.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +enum axp717_reg {
> + AXP717_CHIP_VERSION = 0x3,
> + AXP717_SHUTDOWN = 0x27,
> + AXP717_OUTPUT_CTRL1 = 0x80,
> + AXP717_DCDC1_VOLTAGE = 0x83,
> +};
> +
> +#define AXP717_CHIP_VERSION_MASK 0xc8
> +#define AXP717_DCDC_1220MV_OFFSET71
> +#define AXP717_POWEROFF  (1U << 0)
> +#define DCDC_DVM_ENABLE  (1U << 7)
> +
> +static u8 axp_mvolt_to_cfg(int mvolt, int min, int max, int div)
> +{
> + if (mvolt < min)
> + mvolt = min;
> + else if (mvolt > max)
> + mvolt = max;
> +
> + return (mvolt - min) / div;
> +}
> +
> +static int axp_set_dcdc(int dcdc_num, unsigned int mvolt)
> +{
> + int ret;
> + u8 cfg = DCDC_DVM_ENABLE;
> +
> + if (dcdc_num < 1 || dcdc_num > 3)
> + return -EINVAL;
> +
> + if (mvolt >= 1220)
> + cfg |= AXP717_DCDC_1220MV_OFFSET +
> + axp_mvolt_to_cfg(mvolt, 1220,
> +  dcdc_num == 3 ? 1840 : 1540, 20);
> + else
> + cfg |= axp_mvolt_to_cfg(mvolt, 500, 1200, 10);
> +
> + if (mvolt == 0)
> + return pmic_bus_clrbits(AXP717_OUTPUT_CTRL1,
> + 1U << (dcdc_num -1));
> +
> + ret = pmic_bus_write(AXP717_DCDC1_VOLTAGE + dcdc_num - 1, cfg);
> + if (ret)
> + return ret;
> +
> + return pmic_bus_setbits(AXP717_OUTPUT_CTRL1, 1U << (dcdc_num - 1));
> +}
> +
> +int axp_set_dcdc1(unsigned int mvolt)
> +{
> + return axp_set_dcdc(1, mvolt);
> +}
> +
> +int axp_set_dcdc2(unsigned int mvolt)
> +{
> + return axp_set_dcdc(2, mvolt);
> +}
> +
> +int axp_set_dcdc3(unsigned int mvolt)
> +{
> + return axp_set_dcdc(3, mvolt);
> +}
> +
> +int axp_init(void)
> +{
> + return pmic_bus_init();
> +}
> +
> +#if !CONFIG_IS_ENABLED(ARM_PSCI_FW) && 
> !IS_ENABLED(CONFIG_SYSRESET_CMD_POWEROFF)
> +int do_poweroff(struct cmd_tbl *cmdtp, int flag, int argc, char *const 
> argv[])
> +{
> + pmic_bus_setbits(AXP717_SHUTDOWN, AXP717_POWEROFF);
> +
> + /* infinite loop during shutdown */
> + while (1) {}
> +
> + /* not reached */
> + return 0;
> +}
> +#endif
> -- 
> 2.35.8

Confirmed working on H700 board with AXP717 PMIC and LPDDR4 DRAM controller 
(Anbernic RG35XX-H) and verified I2C address and registers from datasheet.

Reviewed-by: Ryan Walklin 

Regards,

Ryan

[PATCH] net: phy: Add missing RGMII internal delay cases to vsc8541_config

[Shimizu, Ryan]

Currently, vsc8541_config does not account for cases where RGMII
mode with internal delays on TX, RX or both are selected, even though
the device supports that functionality. Instead, it returns an
error when "rgmii-id", "rgmii-txid" or "rgmii-rxid" is selected
in its corresponding DT node.

Fix by adding missing RGMII internal delay modes to list of
fall-through cases so that when configured with modes "rgmii-id",
"rgmii-txid" or "rgmii-rxid", the internal delay registers get
updated correctly in vsc8531_vsc8541_clk_skew_config().

Signed-off-by: Ryan Shimizu 
---

 drivers/net/phy/mscc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/phy/mscc.c b/drivers/net/phy/mscc.c
index bd9cd95297..7263887b9c 100644
--- a/drivers/net/phy/mscc.c
+++ b/drivers/net/phy/mscc.c
@@ -1371,6 +1371,9 @@ static int vsc8541_config(struct phy_device *phydev)
case PHY_INTERFACE_MODE_GMII:
case PHY_INTERFACE_MODE_RMII:
case PHY_INTERFACE_MODE_RGMII:
+   case PHY_INTERFACE_MODE_RGMII_TXID:
+   case PHY_INTERFACE_MODE_RGMII_RXID:
+   case PHY_INTERFACE_MODE_RGMII_ID:
retval = vsc8531_vsc8541_mac_config(phydev);
if (retval != 0)
return retval;
--
2.34.1

Re: [PATCH v2 2/2] tools: binman: ti_board_cfg: Check for linting problems

[Ryan Eatmon]

config_phony.yaml
new file mode 100644
index 00..d76fcb3b82
--- /dev/null
+++ b/tools/binman/test/yaml/config_phony.yaml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# Test config
+#
+---
+
+main-branch :
+  obj :
+a : 0x0
+b: 0
+  arr: [0, 0, 0, 0]
+  another-arr:
+-  # 1
+  c: 0
+  d: 0
+-  # 2
+  c: 0
+  d: 0
diff --git a/tools/buildman/requirements.txt b/tools/buildman/requirements.txt
index a1efcb9d4b..4a31e69e4c 100644
--- a/tools/buildman/requirements.txt
+++ b/tools/buildman/requirements.txt
@@ -1,2 +1,3 @@
  jsonschema==4.17.3
  pyyaml==6.0
+yamllint==1.26.3
--
2.34.1



--
Ryan Eatmonreat...@ti.com
-
Texas Instruments, Inc.  -  LCPD  -  MGTS

RE: [PATCH] net: ftgmac100: Add reset control

[Ryan Chen]

> -Original Message-
> From: Dylan Hung 
> Sent: Thursday, July 27, 2023 9:58 AM
> To: Ryan Chen ; ChiaWei Wang
> ; BMC-SW ;
> j...@jms.id.au; joe.hershber...@ni.com; rfried@gmail.com;
> u-boot@lists.denx.de
> Cc: kobedy...@gmail.com; Dylan Hung 
> Subject: [PATCH] net: ftgmac100: Add reset control
> 
> Add optional reset control, especially for the Aspeed SOC. For the hardware
> without a reset line, the reset assertion/deassertion will be skipped.
> 
> Signed-off-by: Dylan Hung 

Reviewed-by: Ryan Chen 

> ---
>  drivers/net/ftgmac100.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/drivers/net/ftgmac100.c b/drivers/net/ftgmac100.c index
> a50cde338a..886b97119d 100644
> --- a/drivers/net/ftgmac100.c
> +++ b/drivers/net/ftgmac100.c
> @@ -13,6 +13,7 @@
> 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -90,6 +91,7 @@ struct ftgmac100_data {
>   u32 max_speed;
> 
>   struct clk_bulk clks;
> + struct reset_ctl *reset_ctl;
> 
>   /* End of RX/TX ring buffer bits. Depend on model */
>   u32 rxdes0_edorr_mask;
> @@ -568,6 +570,8 @@ static int ftgmac100_of_to_plat(struct udevice *dev)
>   priv->txdes0_edotr_mask = BIT(15);
>   }
> 
> + priv->reset_ctl = devm_reset_control_get_optional(dev, NULL);
> +
>   return clk_get_bulk(dev, >clks);  }
> 
> @@ -593,6 +597,12 @@ static int ftgmac100_probe(struct udevice *dev)
>   if (ret)
>   goto out;
> 
> + if (priv->reset_ctl) {
> + ret = reset_deassert(priv->reset_ctl);
> + if (ret)
> + goto out;
> + }
> +
>   /*
>* If DM MDIO is enabled, the MDIO bus will be initialized later in
>* dm_eth_phy_connect
> @@ -628,6 +638,8 @@ static int ftgmac100_remove(struct udevice *dev)
>   free(priv->phydev);
>   mdio_unregister(priv->bus);
>   mdio_free(priv->bus);
> + if (priv->reset_ctl)
> + reset_assert(priv->reset_ctl);
>   clk_release_bulk(>clks);
> 
>   return 0;
> --
> 2.25.1

Re: [PATCH] boot/pxe-utils: populate initrd_filesize for extlinux boot

[Ryan Lahfa]

On Sat, Sep 16, 2023 at 03:14:58PM +0200, Ryan Lahfa wrote:
> Currently, it seems like the `initrd_filesize` was uninitialized for a
> while.
> 
> This is particularly problematic when attempting to `zboot` with a
> initrd with a size coming from `label->initrd`, because it will provide
> you with a 0-long initrd at boot time, making the kernel fail to
> continue the boot.
> 
> This fixes the issue and I confirmed it enable me booting a U-Boot on
> QEMU x86_64 q35 with NixOS kernel and initrds.

The original message was lost because I do not use `git send-email` that
often but, this issue appears to be introduced in
085cbdafca9c3d7bc2f27523a343f61db82f2ccb ("pxe: simplify label_boot()").

Kind regards,
-- 
Ryan Lahfa

[PATCH] boot/pxe-utils: populate initrd_filesize for extlinux boot

[Ryan Lahfa]

Currently, it seems like the `initrd_filesize` was uninitialized for a
while.

This is particularly problematic when attempting to `zboot` with a
initrd with a size coming from `label->initrd`, because it will provide
you with a 0-long initrd at boot time, making the kernel fail to
continue the boot.

This fixes the issue and I confirmed it enable me booting a U-Boot on
QEMU x86_64 q35 with NixOS kernel and initrds.

Signed-off-by: Ryan Lahfa 
Cc: Tom Rini 
Cc: Simon Glass 
Cc: Bin Meng 
Cc: Zhaofeng Li 
Cc: Heinrich Schuchardt 
Cc: Ramon Fried 
Cc: Artem Lapkin 
---
 boot/pxe_utils.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index d13c47dd94..fa5e88ab95 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -556,6 +556,8 @@ static int label_boot(struct pxe_context *ctx, struct 
pxe_label *label)
}
 
initrd_addr_str = env_get("ramdisk_addr_r");
+   /* Copy the actual initrd size inside the initrd_filesize */
+   snprintf(initrd_filesize, sizeof(initrd_filesize), "%lx", size);
size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx",
initrd_addr_str, size);
if (size >= sizeof(initrd_str))
-- 
2.42.0

zboot: [PATCH] boot/pxe-utils: populate initrd_filesize for extlinux boot

[Ryan Lahfa]

The reason for this is that initrd_filesize is constantly equal to zero
or more specifically, potentially uninitialized memory.

I believe this was introduced in
085cbdafca9c3d7bc2f27523a343f61db82f2ccb ("pxe: simplify label_boot()"),
diff here:

diff --git a/boot/pxe_utils.c b/boot/pxe_utils.c
index b08aee9896..defbe465e4 100644
--- a/boot/pxe_utils.c
+++ b/boot/pxe_utils.c
@@ -532,11 +532,10 @@ static int label_boot(struct pxe_context *ctx, struct 
pxe_label *label)
}
 
initrd_addr_str = env_get("ramdisk_addr_r");
-   strcpy(initrd_filesize, simple_xtoa(size));
-
-   strncpy(initrd_str, initrd_addr_str, 18);
-   strcat(initrd_str, ":");
-   strncat(initrd_str, initrd_filesize, 9);
+   size = snprintf(initrd_str, sizeof(initrd_str), "%s:%lx",
+   initrd_addr_str, size);
+   if (size >= sizeof(initrd_str))
+   return 1;
}
 
if (get_relfile_envaddr(ctx, label->kernel, "kernel_addr_r",

The initrd_filesize completely disappears.

We re-copy the size information inside initrd_filesize, maybe, too
naively, something may have to be done to reduce the overflow potential
if it exist at all.

pxe_utils.c |2 ++
 1 file changed, 2 insertions(+)

[PATCH] include: configs: Change dtb names in fitImage to match oe-core

[Ryan Eatmon]

The oe-core class for assembling the fitImage includes the vendor
sub-directory (with the / changed to _) in the config sections of
the fitImage.  Our env var settings for chosing which section to
boot from needs to be updated to agree with the fitImage.

Signed-off-by: Ryan Eatmon 
---
 include/configs/am64x_evm.h  | 4 ++--
 include/configs/am65x_evm.h  | 2 +-
 include/configs/j721e_evm.h  | 6 +++---
 include/configs/j721s2_evm.h | 6 +++---
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 26a7f2521e..456a44730c 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -26,9 +26,9 @@
 #define EXTRA_ENV_AM642_BOARD_SETTINGS \
"findfdt="  \
"if test $board_name = am64x_gpevm; then " \
-   "setenv fdtfile k3-am642-evm.dtb; fi; " \
+   "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \
"if test $board_name = am64x_skevm; then " \
-   "setenv fdtfile k3-am642-sk.dtb; fi;" \
+   "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \
"if test $fdtfile = undefined; then " \
"echo WARNING: Could not determine device tree to use; 
fi; \0" \
"name_kern=Image\0" \
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 33dd6cfdfa..60a7eb1453 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -24,7 +24,7 @@
 /* U-Boot general configuration */
 #define EXTRA_ENV_AM65X_BOARD_SETTINGS \
"findfdt="  \
-   "setenv name_fdt k3-am654-base-board.dtb;"  \
+   "setenv name_fdt ti_k3-am654-base-board.dtb;"   \
"setenv fdtfile ${name_fdt}\0"  \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"  \
diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index 48b1cea6e3..eac5cd5b76 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -34,11 +34,11 @@
 #define EXTRA_ENV_J721E_BOARD_SETTINGS \
"default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0"  \
"findfdt="  \
-   "setenv name_fdt ${default_device_tree};"   \
+   "setenv name_fdt ti_${default_device_tree};"\
"if test $board_name = j721e; then "\
-   "setenv name_fdt k3-j721e-common-proc-board.dtb; fi;" \
+   "setenv name_fdt ti_k3-j721e-common-proc-board.dtb; 
fi;" \
"if test $board_name = j721e-eaik || test $board_name = 
j721e-sk; then "\
-   "setenv name_fdt k3-j721e-sk.dtb; fi;"  \
+   "setenv name_fdt ti_k3-j721e-sk.dtb; fi;"   \
"setenv fdtfile ${name_fdt}\0"  \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"  \
diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h
index bfada9eebc..b30a4a8da4 100644
--- a/include/configs/j721s2_evm.h
+++ b/include/configs/j721s2_evm.h
@@ -31,11 +31,11 @@
 #define EXTRA_ENV_J721S2_BOARD_SETTINGS
\
"default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0"  \
"findfdt="  \
-   "setenv name_fdt ${default_device_tree};"   \
+   "setenv name_fdt ti_${default_device_tree};"\
"if test $board_name = j721s2; then "   \
-   "setenv name_fdt k3-j721s2-common-proc-board.dtb; fi;" \
+   "setenv name_fdt ti_k3-j721s2-common-proc-board.dtb; 
fi;" \
"if test $board_name = am68-sk; then "  \
-   "setenv name_fdt k3-am68-sk-base-board.dtb; fi;"\
+   "setenv name_fdt ti_k3-am68-sk-base-board.dtb; fi;"\
"setenv fdtfile ${name_fdt}\0"  \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"  \
-- 
2.17.1

[PATCH] include: configs: Change dtb names in fitImage to match oe-core

[Ryan Eatmon]

The oe-core class for assembling the fitImage includes the vendor
sub-directory (with the / changed to _) in the config sections of
the fitImage.  Our env var settings for chosing which section to
boot from needs to be updated to agree with the fitImage.

Signed-off-by: Ryan Eatmon 
---
 include/configs/am64x_evm.h  | 4 ++--
 include/configs/am65x_evm.h  | 2 +-
 include/configs/j721e_evm.h  | 6 +++---
 include/configs/j721s2_evm.h | 6 +++---
 4 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/include/configs/am64x_evm.h b/include/configs/am64x_evm.h
index 26a7f2521e..456a44730c 100644
--- a/include/configs/am64x_evm.h
+++ b/include/configs/am64x_evm.h
@@ -26,9 +26,9 @@
 #define EXTRA_ENV_AM642_BOARD_SETTINGS \
"findfdt="  \
"if test $board_name = am64x_gpevm; then " \
-   "setenv fdtfile k3-am642-evm.dtb; fi; " \
+   "setenv fdtfile ti_k3-am642-evm.dtb; fi; " \
"if test $board_name = am64x_skevm; then " \
-   "setenv fdtfile k3-am642-sk.dtb; fi;" \
+   "setenv fdtfile ti_k3-am642-sk.dtb; fi;" \
"if test $fdtfile = undefined; then " \
"echo WARNING: Could not determine device tree to use; 
fi; \0" \
"name_kern=Image\0" \
diff --git a/include/configs/am65x_evm.h b/include/configs/am65x_evm.h
index 33dd6cfdfa..60a7eb1453 100644
--- a/include/configs/am65x_evm.h
+++ b/include/configs/am65x_evm.h
@@ -24,7 +24,7 @@
 /* U-Boot general configuration */
 #define EXTRA_ENV_AM65X_BOARD_SETTINGS \
"findfdt="  \
-   "setenv name_fdt k3-am654-base-board.dtb;"  \
+   "setenv name_fdt ti_k3-am654-base-board.dtb;"   \
"setenv fdtfile ${name_fdt}\0"  \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"  \
diff --git a/include/configs/j721e_evm.h b/include/configs/j721e_evm.h
index 48b1cea6e3..eac5cd5b76 100644
--- a/include/configs/j721e_evm.h
+++ b/include/configs/j721e_evm.h
@@ -34,11 +34,11 @@
 #define EXTRA_ENV_J721E_BOARD_SETTINGS \
"default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0"  \
"findfdt="  \
-   "setenv name_fdt ${default_device_tree};"   \
+   "setenv name_fdt ti_${default_device_tree};"\
"if test $board_name = j721e; then "\
-   "setenv name_fdt k3-j721e-common-proc-board.dtb; fi;" \
+   "setenv name_fdt ti_k3-j721e-common-proc-board.dtb; 
fi;" \
"if test $board_name = j721e-eaik || test $board_name = 
j721e-sk; then "\
-   "setenv name_fdt k3-j721e-sk.dtb; fi;"  \
+   "setenv name_fdt ti_k3-j721e-sk.dtb; fi;"   \
"setenv fdtfile ${name_fdt}\0"  \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"  \
diff --git a/include/configs/j721s2_evm.h b/include/configs/j721s2_evm.h
index bfada9eebc..b30a4a8da4 100644
--- a/include/configs/j721s2_evm.h
+++ b/include/configs/j721s2_evm.h
@@ -31,11 +31,11 @@
 #define EXTRA_ENV_J721S2_BOARD_SETTINGS
\
"default_device_tree=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0"  \
"findfdt="  \
-   "setenv name_fdt ${default_device_tree};"   \
+   "setenv name_fdt ti_${default_device_tree};"\
"if test $board_name = j721s2; then "   \
-   "setenv name_fdt k3-j721s2-common-proc-board.dtb; fi;" \
+   "setenv name_fdt ti_k3-j721s2-common-proc-board.dtb; 
fi;" \
"if test $board_name = am68-sk; then "  \
-   "setenv name_fdt k3-am68-sk-base-board.dtb; fi;"\
+   "setenv name_fdt ti_k3-am68-sk-base-board.dtb; fi;"\
"setenv fdtfile ${name_fdt}\0"  \
"name_kern=Image\0" \
"console=ttyS2,115200n8\0"  \
-- 
2.17.1

[PATCH] configs: evb-ast2600: Enable configs to store env in SPI

[Ryan Chen]

Enable defconfigs relevant for storing env on SPI flash.

Signed-off-by: Ryan Chen 
---
 configs/evb-ast2600_defconfig | 4 
 1 file changed, 4 insertions(+)

diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
index 3440062156..7c09e846ac 100644
--- a/configs/evb-ast2600_defconfig
+++ b/configs/evb-ast2600_defconfig
@@ -13,6 +13,8 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y
 CONFIG_NR_DRAM_BANKS=1
 CONFIG_SPL_LDSCRIPT="arch/arm/mach-aspeed/ast2600/u-boot-spl.lds"
 CONFIG_ENV_SIZE=0x1
+CONFIG_ENV_OFFSET=0xe
+CONFIG_ENV_SECT_SIZE=0x1
 CONFIG_DM_GPIO=y
 CONFIG_DEFAULT_DEVICE_TREE="ast2600-evb"
 CONFIG_SPL_SERIAL=y
@@ -74,6 +76,8 @@ CONFIG_EFI_PARTITION=y
 # CONFIG_SPL_EFI_PARTITION is not set
 CONFIG_SPL_OF_CONTROL=y
 CONFIG_ENV_OVERWRITE=y
+CONFIG_ENV_IS_IN_SPI_FLASH=y
+CONFIG_ENV_SECT_SIZE_AUTO=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
-- 
2.34.1

RE: [PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new register mode driver

[Ryan Chen]

> -Original Message-
> From: Simon Glass 
> Sent: Tuesday, January 24, 2023 2:44 AM
> To: Ryan Chen 
> Cc: Heiko Schocher ; BMC-SW ;
> u-boot@lists.denx.de
> Subject: Re: [PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new register mode
> driver
> 
> Hi Ryan,
> 
> On Fri, 20 Jan 2023 at 17:10, Ryan Chen  wrote:
> >
> > > -Original Message-
> > > From: Simon Glass 
> > > Sent: Saturday, January 21, 2023 5:58 AM
> > > To: Ryan Chen 
> > > Cc: Heiko Schocher ; BMC-SW
> ;
> > > u-boot@lists.denx.de
> > > Subject: Re: [PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new
> > > register mode driver
> > >
> > > Hi Ryan,
> > >
> > > On Thu, 19 Jan 2023 at 20:12, Ryan Chen 
> > > wrote:
> > > >
> > > > Hello Simon,
> > > > Sorry, do you have time to check v2 patch?
> > >
> > > I did not see a change log on it, so was not sure anything was needed?
> > > Were there changes from the previous version?
> >
> > There have cover latter [PATCH v2 0/1]
> > https://www.mail-archive.com/u-boot@lists.denx.de/msg460560.html
> 
> You can use patman to produce a change list on each patch, then collate the
> change lists into the cover letter. That way it is easier to put it on the 
> patch,
> which is where I would expect it, while still having the cover letter show all
> changes.
> 
> It looks OK to me..but re this one:
> 
> ret = uclass_get_device_by_driver(UCLASS_MISC,
> +
> DM_DRIVER_GET(aspeed_i2c_global),
> + _dev);
> 
> Can you not use the parent device?
Hello Simon,
Thanks your advice. I modify it use function ofnode_get_parent to get 
parent node address.
And send the PATCHv3
https://www.mail-archive.com/u-boot@lists.denx.de/msg462840.html

> 
> Regards,
> Simon

[PATCH v3 1/2] i2c:aspeed:support ast2600 i2c new register mode driver

[Ryan Chen]

Add i2c new register mode driver to support AST2600 i2c
new register mode. AST2600 i2c controller have legacy and
new register mode. The new register mode have global register
support 4 base clock for scl clock selection, and new clock
divider mode.

Signed-off-by: Ryan Chen 
---
 MAINTAINERS   |   6 +
 drivers/i2c/Kconfig   |  10 ++
 drivers/i2c/Makefile  |   1 +
 drivers/i2c/ast2600_i2c.c | 367 ++
 drivers/i2c/ast2600_i2c.h | 120 +
 5 files changed, 504 insertions(+)
 create mode 100644 drivers/i2c/ast2600_i2c.c
 create mode 100644 drivers/i2c/ast2600_i2c.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 3fc4cd0f12..1cf54f0b4e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -769,6 +769,12 @@ S: Maintained
 F: drivers/pci/pcie_phytium.c
 F: arch/arm/dts/phytium-durian.dts
 
+ASPEED AST2600 I2C DRIVER
+M: Ryan Chen 
+R: Aspeed BMC SW team 
+S: Maintained
+F: drivers/i2c/ast2600_i2c.c
+
 ASPEED FMC SPI DRIVER
 M: Chin-Ting Kuo 
 M: Cédric Le Goater 
diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig
index 08b6c7bdcc..77e2a1c4c0 100644
--- a/drivers/i2c/Kconfig
+++ b/drivers/i2c/Kconfig
@@ -221,6 +221,16 @@ config SYS_I2C_DW
  controller is used in various SoCs, e.g. the ST SPEAr, Altera
  SoCFPGA, Synopsys ARC700 and some Intel x86 SoCs.
 
+config SYS_I2C_AST2600
+bool "AST2600 I2C Controller"
+depends on DM_I2C && ARCH_ASPEED
+help
+  Say yes here to select AST2600 I2C Host Controller. The driver
+  support AST2600 I2C new mode register. This I2C controller supports:
+  _Standard-mode (up to 100 kHz)
+  _Fast-mode (up to 400 kHz)
+  _Fast-mode Plus (up to 1 MHz)
+
 config SYS_I2C_ASPEED
bool "Aspeed I2C Controller"
depends on DM_I2C && ARCH_ASPEED
diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index 920aafb91c..89db2d8e37 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) += cros_ec_ldo.o
 
 obj-$(CONFIG_$(SPL_)SYS_I2C_LEGACY) += i2c_core.o
 obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
+obj-$(CONFIG_SYS_I2C_AST2600) += ast2600_i2c.o
 obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
 obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
 obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o
diff --git a/drivers/i2c/ast2600_i2c.c b/drivers/i2c/ast2600_i2c.c
new file mode 100644
index 00..f9d9ff09b3
--- /dev/null
+++ b/drivers/i2c/ast2600_i2c.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright ASPEED Technology Inc.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "ast2600_i2c.h"
+
+/* Device private data */
+struct ast2600_i2c_priv {
+   struct clk clk;
+   struct ast2600_i2c_regs *regs;
+   void __iomem *global;
+};
+
+static int ast2600_i2c_read_data(struct ast2600_i2c_priv *priv, u8 chip_addr,
+u8 *buffer, size_t len, bool send_stop)
+{
+   int rx_cnt, ret = 0;
+   u32 cmd, isr;
+
+   for (rx_cnt = 0; rx_cnt < len; rx_cnt++, buffer++) {
+   cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
+ I2CM_RX_CMD;
+   if (!rx_cnt)
+   cmd |= I2CM_START_CMD;
+
+   if ((len - 1) == rx_cnt)
+   cmd |= I2CM_RX_CMD_LAST;
+
+   if (send_stop && ((len - 1) == rx_cnt))
+   cmd |= I2CM_STOP_CMD;
+
+   writel(cmd, >regs->cmd_sts);
+
+   ret = readl_poll_timeout(>regs->isr, isr,
+isr & I2CM_PKT_DONE,
+I2C_TIMEOUT_US);
+   if (ret)
+   return -ETIMEDOUT;
+
+   *buffer =
+   I2CC_GET_RX_BUFF(readl(>regs->trx_buff));
+
+   writel(I2CM_PKT_DONE, >regs->isr);
+
+   if (isr & I2CM_TX_NAK)
+   return -EREMOTEIO;
+   }
+
+   return 0;
+}
+
+static int ast2600_i2c_write_data(struct ast2600_i2c_priv *priv, u8 chip_addr,
+ u8 *buffer, size_t len, bool send_stop)
+{
+   int tx_cnt, ret = 0;
+   u32 cmd, isr;
+
+   if (!len) {
+   cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
+ I2CM_START_CMD;
+   writel(cmd, >regs->cmd_sts);
+   ret = readl_poll_timeout(>regs->isr, isr,
+isr & I2CM_PKT_DONE,
+I2C_TIMEOUT_US);
+   if (ret)
+   return -ETIMEDOUT;
+
+   writel(I2CM_PKT_DONE, >regs->isr);
+
+   if (isr & I2CM_TX_NAK)
+   return -EREMOTEIO;
+   }
+
+

[PATCH v3 2/2] arm: aspeed: dtsi: add reg for i2c

[Ryan Chen]

The i2c driver have global register that i2c bus use
ofnode_get_parent to get parent register address.

Signed-off-by: Ryan Chen 
---
 arch/arm/dts/ast2600.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
index 8d91eedc17..beabcf14f8 100644
--- a/arch/arm/dts/ast2600.dtsi
+++ b/arch/arm/dts/ast2600.dtsi
@@ -681,6 +681,7 @@
 
i2c: bus@1e78a000 {
compatible = "simple-bus";
+   reg = <0x1e78a000 0x1000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x1e78a000 0x1000>;
-- 
2.34.1

[PATCH v3 0/2] Add ASPEED AST2600 I2C new controller driver

[Ryan Chen]

This series add AST2600 i2c new register set driver. The i2c new
register set have new clock divider option for more flexiable generation.

Changes in v3:
-modify uclass_get_device_by_driver to ofnode_get_parent.
-Add i2c reg address in dtsi node.
-fix up git config name from ryan_chen to Ryan Chen.

Changes in v2:
-add speed support desciption in Kconfig.
-modify include header ordering.
-separate include register define header.
-modify wording reserver to reserved.
-remove defined string AST2600.
-modify signle-line comment style.
-remove extra ().
-modify local regs for register ctrl.

Ryan Chen (2):
  i2c:aspeed:support ast2600 i2c new register mode driver
  arm: aspeed: dtsi: add reg for i2c

 MAINTAINERS   |   6 +
 arch/arm/dts/ast2600.dtsi |   1 +
 drivers/i2c/Kconfig   |  10 ++
 drivers/i2c/Makefile  |   1 +
 drivers/i2c/ast2600_i2c.c | 367 ++
 drivers/i2c/ast2600_i2c.h | 120 +
 6 files changed, 505 insertions(+)
 create mode 100644 drivers/i2c/ast2600_i2c.c
 create mode 100644 drivers/i2c/ast2600_i2c.h

-- 
2.34.1

RE: [PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new register mode driver

[Ryan Chen]

> -Original Message-
> From: Simon Glass 
> Sent: Saturday, January 21, 2023 5:58 AM
> To: Ryan Chen 
> Cc: Heiko Schocher ; BMC-SW ;
> u-boot@lists.denx.de
> Subject: Re: [PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new register mode
> driver
> 
> Hi Ryan,
> 
> On Thu, 19 Jan 2023 at 20:12, Ryan Chen 
> wrote:
> >
> > Hello Simon,
> > Sorry, do you have time to check v2 patch?
> 
> I did not see a change log on it, so was not sure anything was needed?
> Were there changes from the previous version?

There have cover latter [PATCH v2 0/1]
https://www.mail-archive.com/u-boot@lists.denx.de/msg460560.html

Ryan Chen

RE: [PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new register mode driver

[Ryan Chen]

Hello Simon,
Sorry, do you have time to check v2 patch?

Ryan Chen

> -Original Message-
> From: Ryan Chen 
> Sent: Wednesday, January 11, 2023 2:53 PM
> To: Heiko Schocher ; Ryan Chen ;
> BMC-SW ; u-boot@lists.denx.de
> Subject: [PATCH v2 1/1] i2c:aspeed:support ast2600 i2c new register mode
> driver
> 
> Add i2c new register mode driver to support AST2600 i2c new register mode.
> AST2600 i2c controller have legacy and new register mode. The new register
> mode have global register support 4 base clock for scl clock selection, and 
> new
> clock divider mode.
> 
> Signed-off-by: ryan_chen 
> ---
>  MAINTAINERS   |   6 +
>  drivers/i2c/Kconfig   |  10 +
>  drivers/i2c/Makefile  |   1 +
>  drivers/i2c/ast2600_i2c.c | 375
> ++
>  drivers/i2c/ast2600_i2c.h | 120 
>  5 files changed, 512 insertions(+)
>  create mode 100644 drivers/i2c/ast2600_i2c.c  create mode 100644
> drivers/i2c/ast2600_i2c.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3fc4cd0f12..1cf54f0b4e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -769,6 +769,12 @@ S:   Maintained
>  F:   drivers/pci/pcie_phytium.c
>  F:   arch/arm/dts/phytium-durian.dts
> 
> +ASPEED AST2600 I2C DRIVER
> +M:   Ryan Chen 
> +R:   Aspeed BMC SW team 
> +S:   Maintained
> +F:   drivers/i2c/ast2600_i2c.c
> +
>  ASPEED FMC SPI DRIVER
>  M:   Chin-Ting Kuo 
>  M:   Cédric Le Goater 
> diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index
> 08b6c7bdcc..77e2a1c4c0 100644
> --- a/drivers/i2c/Kconfig
> +++ b/drivers/i2c/Kconfig
> @@ -221,6 +221,16 @@ config SYS_I2C_DW
> controller is used in various SoCs, e.g. the ST SPEAr, Altera
> SoCFPGA, Synopsys ARC700 and some Intel x86 SoCs.
> 
> +config SYS_I2C_AST2600
> +bool "AST2600 I2C Controller"
> +depends on DM_I2C && ARCH_ASPEED
> +help
> +  Say yes here to select AST2600 I2C Host Controller. The driver
> +  support AST2600 I2C new mode register. This I2C controller supports:
> +  _Standard-mode (up to 100 kHz)
> +  _Fast-mode (up to 400 kHz)
> +  _Fast-mode Plus (up to 1 MHz)
> +
>  config SYS_I2C_ASPEED
>   bool "Aspeed I2C Controller"
>   depends on DM_I2C && ARCH_ASPEED
> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile index
> 920aafb91c..89db2d8e37 100644
> --- a/drivers/i2c/Makefile
> +++ b/drivers/i2c/Makefile
> @@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) +=
> cros_ec_ldo.o
> 
>  obj-$(CONFIG_$(SPL_)SYS_I2C_LEGACY) += i2c_core.o
>  obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
> +obj-$(CONFIG_SYS_I2C_AST2600) += ast2600_i2c.o
>  obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
>  obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
>  obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o diff --git
> a/drivers/i2c/ast2600_i2c.c b/drivers/i2c/ast2600_i2c.c new file mode 100644
> index 00..0fad30b5a2
> --- /dev/null
> +++ b/drivers/i2c/ast2600_i2c.c
> @@ -0,0 +1,375 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright ASPEED Technology Inc.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "ast2600_i2c.h"
> +
> +/* Device private data */
> +struct ast2600_i2c_priv {
> + struct clk clk;
> + struct ast2600_i2c_regs *regs;
> + void __iomem *global;
> +};
> +
> +static int ast2600_i2c_read_data(struct ast2600_i2c_priv *priv, u8 chip_addr,
> +  u8 *buffer, size_t len, bool send_stop) {
> + int rx_cnt, ret = 0;
> + u32 cmd, isr;
> +
> + for (rx_cnt = 0; rx_cnt < len; rx_cnt++, buffer++) {
> + cmd = I2CM_PKT_EN | I2CM_PKT_ADDR(chip_addr) |
> +   I2CM_RX_CMD;
> + if (!rx_cnt)
> + cmd |= I2CM_START_CMD;
> +
> + if ((len - 1) == rx_cnt)
> + cmd |= I2CM_RX_CMD_LAST;
> +
> + if (send_stop && ((len - 1) == rx_cnt))
> + cmd |= I2CM_STOP_CMD;
> +
> + writel(cmd, >regs->cmd_sts);
> +
> + ret = readl_poll_timeout(>regs->isr, isr,
> +  isr & I2CM_PKT_DONE,
> +  I2C_TIMEOUT_US);
> + if (ret)
> + return -ETIMEDOUT;
> +
> + *buffer =
> + I2CC_GET_RX_BUFF(readl(>regs->trx_buff));
> +
> + writel(I2CM_PKT_DONE, >regs->isr);
> +
> +   

RE: [PATCH 1/1] i2c:aspeed:support ast2600 i2c new register mode driver

[Ryan Chen]

Hello,
I resend the v2 version here
https://www.mail-archive.com/u-boot@lists.denx.de/msg460560.html


Ryan Chen

> -Original Message-
> From: Simon Glass 
> Sent: Thursday, January 12, 2023 5:08 AM
> To: Ryan Chen 
> Cc: Heiko Schocher ; BMC-SW ;
> u-boot@lists.denx.de
> Subject: Re: [PATCH 1/1] i2c:aspeed:support ast2600 i2c new register mode
> driver
> 
> Hi Ryan,
> 
> On Tue, 10 Jan 2023 at 23:48, ryan_chen 
> wrote:
> >
> > Add i2c new register mode driver to support AST2600 i2c new register
> > mode. AST2600 i2c controller have legacy and new register mode. The
> > new register mode have global register support 4 base clock for scl
> > clock selection, and new clock divider mode.
> >
> > Signed-off-by: ryan_chen 
> > ---
> >  MAINTAINERS   |   6 +
> >  drivers/i2c/Kconfig   |  10 +
> >  drivers/i2c/Makefile  |   1 +
> >  drivers/i2c/ast2600_i2c.c | 375
> > ++
> >  drivers/i2c/ast2600_i2c.h | 120 
> >  5 files changed, 512 insertions(+)
> >  create mode 100644 drivers/i2c/ast2600_i2c.c  create mode 100644
> > drivers/i2c/ast2600_i2c.h
> 
> Is this a new version?
> 
> Regards,
> Simon

RE: [PATCH 1/1] i2c:aspeed:support ast2600 i2c new register mode driver

[Ryan Chen]

Hello Simon,
Thank your feedback.

> -Original Message-
> From: Simon Glass 
> Sent: Tuesday, January 10, 2023 3:47 AM
> To: Ryan Chen 
> Cc: Heiko Schocher ; BMC-SW ;
> u-boot@lists.denx.de
> Subject: Re: [PATCH 1/1] i2c:aspeed:support ast2600 i2c new register mode
> driver
> 
>   Hi Ryan_chen,
> 
> On Mon, 9 Jan 2023 at 01:30, ryan_chen 
> wrote:
> >
> > Add i2c new register mode driver to support AST2600 i2c new register
> > mode. AST2600 i2c controller have legacy and new register mode. The
> > new register mode have global register support 4 base clock for scl
> > clock selection, and new clock divider mode.
> >
> > Signed-off-by: ryan_chen 
> > ---
> >  MAINTAINERS   |   6 +
> >  drivers/i2c/Kconfig   |   7 +
> >  drivers/i2c/Makefile  |   1 +
> >  drivers/i2c/ast2600_i2c.c | 480
> > ++
> >  4 files changed, 494 insertions(+)
> >  create mode 100644 drivers/i2c/ast2600_i2c.c
> 
> This generally looks OK, but I have quite a few minor comments, and one
> major one: could/should this driver be an update to the existing one, instead?
> That is the short of thing that really should be in your commit message.
> 

This driver is now driver not be an update to the exiting one.

> >
> > diff --git a/MAINTAINERS b/MAINTAINERS index 3fc4cd0f12..1cf54f0b4e
> > 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -769,6 +769,12 @@ S: Maintained
> >  F: drivers/pci/pcie_phytium.c
> >  F: arch/arm/dts/phytium-durian.dts
> >
> > +ASPEED AST2600 I2C DRIVER
> > +M: Ryan Chen 
> > +R: Aspeed BMC SW team 
> > +S: Maintained
> > +F: drivers/i2c/ast2600_i2c.c
> > +
> >  ASPEED FMC SPI DRIVER
> >  M: Chin-Ting Kuo 
> >  M: Cédric Le Goater 
> > diff --git a/drivers/i2c/Kconfig b/drivers/i2c/Kconfig index
> > 08b6c7bdcc..34f507fb3b 100644
> > --- a/drivers/i2c/Kconfig
> > +++ b/drivers/i2c/Kconfig
> > @@ -221,6 +221,13 @@ config SYS_I2C_DW
> >   controller is used in various SoCs, e.g. the ST SPEAr, Altera
> >   SoCFPGA, Synopsys ARC700 and some Intel x86 SoCs.
> >
> > +config SYS_I2C_AST2600
> > +bool "AST2600 I2C Controller"
> > +depends on DM_I2C && ARCH_ASPEED
> > +help
> > +  Say yes here to select AST2600 I2C Host Controller. The driver
> > +  support AST2600 I2C new mode register.
> 
> What speeds does it support? 

Will modify by following.
+config SYS_I2C_AST2600
+bool "AST2600 I2C Controller"
+depends on DM_I2C && ARCH_ASPEED
+help
+  Say yes here to select AST2600 I2C Host Controller. The driver
+  support AST2600 I2C new mode register. This I2C controller supports:
+  -Standard-mode (up to 100 kHz)
+  -Fast-mode (up to 400 kHz)
+  -Fast-mode Plus (up to 1 MHz)

>Please add at least 3 lines of info.
Sorry, what do you mean about 3 lines of info?
The i2c have two lines, SDA/SCL only.

> 
> A link to the datasheet would help too, either here or in doc/
> 
> > +
> >  config SYS_I2C_ASPEED
> > bool "Aspeed I2C Controller"
> > depends on DM_I2C && ARCH_ASPEED diff --git
> > a/drivers/i2c/Makefile b/drivers/i2c/Makefile index
> > 920aafb91c..89db2d8e37 100644
> > --- a/drivers/i2c/Makefile
> > +++ b/drivers/i2c/Makefile
> > @@ -12,6 +12,7 @@ obj-$(CONFIG_$(SPL_)I2C_CROS_EC_LDO) +=
> > cros_ec_ldo.o
> >
> >  obj-$(CONFIG_$(SPL_)SYS_I2C_LEGACY) += i2c_core.o
> >  obj-$(CONFIG_SYS_I2C_ASPEED) += ast_i2c.o
> > +obj-$(CONFIG_SYS_I2C_AST2600) += ast2600_i2c.o
> >  obj-$(CONFIG_SYS_I2C_AT91) += at91_i2c.o
> >  obj-$(CONFIG_SYS_I2C_CADENCE) += i2c-cdns.o
> >  obj-$(CONFIG_SYS_I2C_CA) += i2c-cortina.o diff --git
> > a/drivers/i2c/ast2600_i2c.c b/drivers/i2c/ast2600_i2c.c new file mode
> > 100644 index 00..52aea460ac
> > --- /dev/null
> > +++ b/drivers/i2c/ast2600_i2c.c
> > @@ -0,0 +1,480 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright ASPEED Technology Inc.
> > + */
> > +#include 
> 
> The ordering is off here. Please see
> 
> https://u-boot.readthedocs.io/en/latest/develop/codingstyle.html#include-files

Will update

> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +struct ast2600_i2c_regs {
> > +   u32 fun_ctrl;
> > +   u32 ac_timin

RE: [PATCH 3/3] ram: ast2600: Align the RL and WL setting

[Ryan Chen]

> -Original Message-
> From: Dylan Hung 
> Sent: Friday, November 11, 2022 3:30 PM
> To: Ryan Chen ; ChiaWei Wang
> ; j...@jms.id.au; Dylan Hung
> ; u-boot@lists.denx.de
> Cc: BMC-SW 
> Subject: [PATCH 3/3] ram: ast2600: Align the RL and WL setting
> 
> Use macro to represent the RL and WL setting to ensure the PHY and controller
> setting are aligned.
> 
> Signed-off-by: Dylan Hung 

Review-by: Ryan Chen 
> ---
>  arch/arm/include/asm/arch-aspeed/sdram_ast2600.h | 4 
>  drivers/ram/aspeed/sdram_ast2600.c   | 9 +
>  2 files changed, 13 insertions(+)
> 
> diff --git a/arch/arm/include/asm/arch-aspeed/sdram_ast2600.h
> b/arch/arm/include/asm/arch-aspeed/sdram_ast2600.h
> index d2408c0020f8..b0a91ae40d44 100644
> --- a/arch/arm/include/asm/arch-aspeed/sdram_ast2600.h
> +++ b/arch/arm/include/asm/arch-aspeed/sdram_ast2600.h
> @@ -104,6 +104,10 @@
>  #define SDRAM_FORCE_PRECHARGE_EN BIT(4)
>  #define SDRAM_REFRESH_EN BIT(0)
> 
> +/* MCR14 */
> +#define SDRAM_WL_SETTING GENMASK(23, 20)
> +#define SDRAM_CL_SETTING GENMASK(19, 16)
> +
>  #define SDRAM_TEST_LEN_SHIFT 4
>  #define SDRAM_TEST_LEN_MASK  0xf
>  #define SDRAM_TEST_START_ADDR_SHIFT  24
> diff --git a/drivers/ram/aspeed/sdram_ast2600.c
> b/drivers/ram/aspeed/sdram_ast2600.c
> index bda02d062900..5d426088be3e 100644
> --- a/drivers/ram/aspeed/sdram_ast2600.c
> +++ b/drivers/ram/aspeed/sdram_ast2600.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
> 
>  #define DDR_PHY_TBL_CHG_ADDR0xaeeddeea
> @@ -935,6 +936,7 @@ static void ast2600_sdrammc_lock(struct dram_info
> *info)  static void ast2600_sdrammc_common_init(struct
> ast2600_sdrammc_regs *regs)  {
>   int i;
> + u32 reg;
> 
>   writel(MCR34_MREQI_DIS | MCR34_RESETN_DIS, >power_ctrl);
>   writel(SDRAM_VIDEO_UNLOCK_KEY, >gm_protection_key); @@
> -969,6 +971,13 @@ static void ast2600_sdrammc_common_init(struct
> ast2600_sdrammc_regs *regs)
>   for (i = 0; i < ARRAY_SIZE(ddr4_ac_timing); ++i)
>   writel(ddr4_ac_timing[i], >ac_timing[i]);
> 
> + /* update CL and WL */
> + reg = readl(>ac_timing[1]);
> + reg &= ~(SDRAM_WL_SETTING | SDRAM_CL_SETTING);
> + reg |= FIELD_PREP(SDRAM_WL_SETTING, CONFIG_WL - 5) |
> +FIELD_PREP(SDRAM_CL_SETTING, CONFIG_RL - 5);
> + writel(reg, >ac_timing[1]);
> +
>   writel(DDR4_MR01_MODE, >mr01_mode_setting);
>   writel(DDR4_MR23_MODE, >mr23_mode_setting);
>   writel(DDR4_MR45_MODE, >mr45_mode_setting);
> --
> 2.25.1

RE: [PATCH 2/3] ram: ast2600: Improve ddr4 timing and signal quality

[Ryan Chen]

> -Original Message-
> From: Dylan Hung 
> Sent: Friday, November 11, 2022 3:30 PM
> To: Ryan Chen ; ChiaWei Wang
> ; j...@jms.id.au; Dylan Hung
> ; u-boot@lists.denx.de
> Cc: BMC-SW 
> Subject: [PATCH 2/3] ram: ast2600: Improve ddr4 timing and signal quality
> 
> Adjust the following settings to get better timing and signal quality.
> 
> 1. write DQS/DQ delay
> - 1e6e2304[0]
> - 1e6e2304[15:8]
> 
> 2. read DQS/DQ delay
> - 0x1e6e0298[0]
> - 0x1e6e0298[15:8]
> 
> 3. CLK/CA timing
> - 0x1e6e01a8[31]
> 
> 4. Read and write termination
> - change RTT_ROM from 40 ohm to 48 ohm (MR1[10:8])
> - change RTT_PARK from disable to 48 ohm (MR5[8:6])
> - change RTT_WR from 120 ohm to disable (MR2[11:9])
> - change PHY ODT from 40 ohm to 80 ohm (0x1e6e0130[10:8])
> 
> Note1: Both DDR-PHY and DDR controller have their own registers for DDR4
> Mode Registers (MR0~MR6).  This patch introduces macros to synchronize the
> MR value on both sides.
> 
> Note2: the waveform meansurement can be found in item #21 of Aspeed
> AST26x0 Application note (AP note).
> 
> Signed-off-by: Dylan Hung 

Review-by: Ryan Chen 
> ---
>  drivers/ram/aspeed/sdram_ast2600.c | 163 -
>  1 file changed, 138 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/ram/aspeed/sdram_ast2600.c
> b/drivers/ram/aspeed/sdram_ast2600.c
> index b09232a30413..bda02d062900 100644
> --- a/drivers/ram/aspeed/sdram_ast2600.c
> +++ b/drivers/ram/aspeed/sdram_ast2600.c
> @@ -20,6 +20,119 @@
>  #define DDR_PHY_TBL_CHG_ADDR0xaeeddeea
>  #define DDR_PHY_TBL_END 0xaeededed
> 
> +/**
> + * phyr030[18:16] - Ron PU (PHY side)
> + * phyr030[14:12] - Ron PD (PHY side)
> + *   b'000 : disable
> + *   b'001 : 240 ohm
> + *   b'010 : 120 ohm
> + *   b'011 : 80 ohm
> + *   b'100 : 60 ohm
> + *   b'101 : 48 ohm
> + *   b'110 : 40 ohm
> + *   b'111 : 34 ohm (default)
> + */
> +#define PHY_RON  ((0x7 << 16) | (0x7 << 12))
> +
> +/**
> + * phyr030[10:8] - ODT configuration (PHY side)
> + *   b'000 : ODT disabled
> + *   b'001 : 240 ohm
> + *   b'010 : 120 ohm
> + *   b'011 : 80 ohm (default)
> + *   b'100 : 60 ohm
> + *   b'101 : 48 ohm
> + *   b'110 : 40 ohm
> + *   b'111 : 34 ohm
> + */
> +#define PHY_ODT  (0x3 << 8)
> +
> +/**
> + * MR1[2:1] output driver impedance
> + *   b'00 : 34 ohm (default)
> + *   b'01 : 48 ohm
> + */
> +#define DRAM_RON (0x0 << 1)
> +
> +/**
> + * DRAM ODT - synchronous ODT mode
> + *   RTT_WR: disable
> + *   RTT_NOM = RTT_PARK
> + *
> + * MR1[10:8] RTT_NOM
> + *   b'000 : RTT_NOM disable
> + *   b'001 : 60 ohm
> + *   b'010 : 120 ohm
> + *   b'011 : 40 ohm
> + *   b'100 : 240 ohm
> + *   b'101 : 48 ohm  (default)
> + *   b'110 : 80 ohm
> + *   b'111 : 34 ohm
> + *
> + * MR5[8:6] RTT_PARK
> + *   b'000 : RTT_PARK disable
> + *   b'001 : 60 ohm
> + *   b'010 : 120 ohm
> + *   b'011 : 40 ohm
> + *   b'100 : 240 ohm
> + *   b'101 : 48 ohm  (default)
> + *   b'110 : 80 ohm
> + *   b'111 : 34 ohm
> + *
> + * MR2[11:9] RTT_WR
> + *   b'000 : Dynamic ODT off  (default)
> + *   b'001 : 120 ohm
> + *   b'010 : 240 ohm
> + *   b'011 : Hi-Z
> + *   b'100 : 80 ohm
> + */
> +#define RTT_WR   (0x0 << 9)
> +#define RTT_NOM  (0x5 << 8)
> +#define RTT_PARK (0x5 << 6)
> +
> +/**
> + * MR6[6] VrefDQ training range
> + *   b'0 : range 1
> + *   b'1 : range 2 (default)
> + */
> +#define VREFDQ_RANGE_2   BIT(6)
> +
> +/**
> + * Latency setting:
> + * AL = PL = 0 (hardware fixed setting)
> + * -> WL = AL + CWL + PL = CWL
> + * -> RL = AL + CL + PL = CL
> + */
> +#define CONFIG_WL9
> +#define CONFIG_RL12
> +#define T_RDDATA_EN  ((CONFIG_RL - 2) << 8)
> +#define T_PHY_WRLAT  (CONFIG_WL - 2)
> +
> +/* MR0 */
> +#define MR0_CL_12(BIT(4) | BIT(2))
> +#define MR0_WR12_RTP6BIT(9)
> +#define MR0_DLL_RESETBIT(8)
> +#define MR0_VAL  (MR0_CL_12 | MR0_WR12_RTP6 |
> MR0_DLL_RESET)
> +
> +/* MR1 */
> +#define MR1_VAL  (0x0001 | RTT_NOM | DRAM_RON)
> +
> +/* MR2 */
> +#define MR2_CWL_90
> +#define MR2_VAL  (0x | RTT_WR | MR2_CWL_9)
> +
> +/* MR3 ~ MR6 */
> +#define MR3_VAL  0x

RE: [PATCH 1/3] ram: ast2600: Fix incorrect statement of the register polling

[Ryan Chen]

> -Original Message-
> From: Dylan Hung 
> Sent: Friday, November 11, 2022 3:30 PM
> To: Ryan Chen ; ChiaWei Wang
> ; j...@jms.id.au; Dylan Hung
> ; u-boot@lists.denx.de
> Cc: BMC-SW 
> Subject: [PATCH 1/3] ram: ast2600: Fix incorrect statement of the register
> polling
> 
> The condition "~data" in the if-statement is a typo.  The original intention 
> is
> to poll if SDRAM_PHYCTRL0_INIT bit equals to 0. So use "data == 0" for
> instead.
> 
> Besides, the bit[1] of "phy_status" register is hardwired to
> SDRAM_PHYCTRL0_INIT (with inverse logic). Since SDRAM_PHYCTRL0_INIT has
> already done, remove the unnecessary checking of phy_status[1].
> 
> Fixes: fde93143469f ("ram: aspeed: Add AST2600 DRAM control support")
> 
> Signed-off-by: Dylan Hung 
Review-by: Ryan Chen 
> ---
>  drivers/ram/aspeed/sdram_ast2600.c | 7 +--
>  1 file changed, 1 insertion(+), 6 deletions(-)
> 
> diff --git a/drivers/ram/aspeed/sdram_ast2600.c
> b/drivers/ram/aspeed/sdram_ast2600.c
> index 9ad398d24155..b09232a30413 100644
> --- a/drivers/ram/aspeed/sdram_ast2600.c
> +++ b/drivers/ram/aspeed/sdram_ast2600.c
> @@ -449,7 +449,7 @@ static void ast2600_sdramphy_kick_training(struct
> dram_info *info)
> 
>   while (1) {
>   data = readl(>phy_ctrl[0]) & SDRAM_PHYCTRL0_INIT;
> - if (~data)
> + if (data == 0)
>   break;
>   }
>  }
> @@ -984,11 +984,6 @@ static int ast2600_sdrammc_probe(struct udevice
> *dev)
>  L_ast2600_sdramphy_train:
>   ast2600_sdrammc_init_ddr4(priv);
> 
> - /* make sure DDR-PHY is ready before access */
> - do {
> - reg = readl(priv->phy_status) & BIT(1);
> - } while (reg == 0);
> -
>   if (ast2600_sdramphy_check_status(priv) != 0) {
>   printf("DDR4 PHY training fail, retrain\n");
>   goto L_ast2600_sdramphy_train;
> --
> 2.25.1

RE: [PATCH 08/10] i2c/aspeed: Add AST2600 compatible

[Ryan Chen]

> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 08/10] i2c/aspeed: Add AST2600 compatible
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  drivers/i2c/ast_i2c.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/i2c/ast_i2c.c b/drivers/i2c/ast_i2c.c index
> 0a93d7c82911..c9ffe2d62820 100644
> --- a/drivers/i2c/ast_i2c.c
> +++ b/drivers/i2c/ast_i2c.c
> @@ -351,6 +351,7 @@ static const struct dm_i2c_ops ast_i2c_ops = {  static
> const struct udevice_id ast_i2c_ids[] = {
>   { .compatible = "aspeed,ast2400-i2c-bus" },
>   { .compatible = "aspeed,ast2500-i2c-bus" },
> + { .compatible = "aspeed,ast2600-i2c-bus" },
>   { },
>  };
> 
> --
> 2.35.1

RE: [PATCH 07/10] i2c/aspeed: Fix reset control

[Ryan Chen]

> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 07/10] i2c/aspeed: Fix reset control
> 
> The reset control was written for the ast2500 and directly programs the
> clocking register.
> 
> So we can share the code with other SoC generations use the reset device to
> deassert the I2C reset line.
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  drivers/i2c/ast_i2c.c | 22 +++---
>  1 file changed, 15 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/i2c/ast_i2c.c b/drivers/i2c/ast_i2c.c index
> 2d3fecaa14ea..0a93d7c82911 100644
> --- a/drivers/i2c/ast_i2c.c
> +++ b/drivers/i2c/ast_i2c.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #include "ast_i2c.h"
> 
> @@ -108,19 +109,26 @@ static int ast_i2c_of_to_plat(struct udevice *dev)
> 
>  static int ast_i2c_probe(struct udevice *dev)  {
> - struct ast2500_scu *scu;
> + struct reset_ctl reset_ctl;
> + int rc;
> 
>   debug("Enabling I2C%u\n", dev_seq(dev));
> 
>   /*
>* Get all I2C devices out of Reset.
> -  * Only needs to be done once, but doing it for every
> -  * device does not hurt.
> +  *
> +  * Only needs to be done once so test before performing reset.
>*/
> - scu = ast_get_scu();
> - ast_scu_unlock(scu);
> - clrbits_le32(>sysreset_ctrl1, SCU_SYSRESET_I2C);
> - ast_scu_lock(scu);
> + rc = reset_get_by_index(dev, 0, _ctl);
> + if (rc) {
> + printf("%s: Failed to get reset signal\n", __func__);
> + return rc;
> + }
> +
> + if (reset_status(_ctl) > 0) {
> + reset_assert(_ctl);
> + reset_deassert(_ctl);
> + }
> 
>   ast_i2c_init_bus(dev);
> 
> --
> 2.35.1

RE: [PATCH 06/10] reset/aspeed: Implement status callback

[Ryan Chen]

> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 06/10] reset/aspeed: Implement status callback
> 
> The I2C driver shares a reset line between buses, so allow it to test the 
> state of
> the reset line before resetting it.
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  drivers/reset/reset-ast2500.c | 19 +++
> drivers/reset/reset-ast2600.c | 17 +
>  2 files changed, 36 insertions(+)
> 
> diff --git a/drivers/reset/reset-ast2500.c b/drivers/reset/reset-ast2500.c 
> index
> 0a1dd236aff3..d9cecf3a72e8 100644
> --- a/drivers/reset/reset-ast2500.c
> +++ b/drivers/reset/reset-ast2500.c
> @@ -48,6 +48,24 @@ static int ast2500_reset_deassert(struct reset_ctl
> *reset_ctl)
>   return 0;
>  }
> 
> +static int ast2500_reset_status(struct reset_ctl *reset_ctl) {
> + struct ast2500_reset_priv *priv = dev_get_priv(reset_ctl->dev);
> + struct ast2500_scu *scu = priv->scu;
> + int status;
> +
> + debug("%s: reset_ctl->id: %lu\n", __func__, reset_ctl->id);
> +
> + if (reset_ctl->id < 32)
> + status = BIT(reset_ctl->id) & readl(>sysreset_ctrl1);
> + else
> + status = BIT(reset_ctl->id - 32) & readl(>sysreset_ctrl2);
> +
> + return !!status;
> +}
> +
> +
> +
>  static int ast2500_reset_probe(struct udevice *dev)  {
>   int rc;
> @@ -79,6 +97,7 @@ static const struct udevice_id ast2500_reset_ids[] =
> {  struct reset_ops ast2500_reset_ops = {
>   .rst_assert = ast2500_reset_assert,
>   .rst_deassert = ast2500_reset_deassert,
> + .rst_status = ast2500_reset_status,
>  };
> 
>  U_BOOT_DRIVER(ast2500_reset) = {
> diff --git a/drivers/reset/reset-ast2600.c b/drivers/reset/reset-ast2600.c 
> index
> 985235a3ac46..1732a450efc0 100644
> --- a/drivers/reset/reset-ast2600.c
> +++ b/drivers/reset/reset-ast2600.c
> @@ -47,6 +47,22 @@ static int ast2600_reset_deassert(struct reset_ctl
> *reset_ctl)
>   return 0;
>  }
> 
> +static int ast2600_reset_status(struct reset_ctl *reset_ctl) {
> + struct ast2600_reset_priv *priv = dev_get_priv(reset_ctl->dev);
> + struct ast2600_scu *scu = priv->scu;
> + int status;
> +
> + debug("%s: reset_ctl->id: %lu\n", __func__, reset_ctl->id);
> +
> + if (reset_ctl->id < 32)
> + status = BIT(reset_ctl->id) & readl(>modrst_ctrl1);
> + else
> + status = BIT(reset_ctl->id - 32) & readl(>modrst_ctrl2);
> +
> + return !!status;
> +}
> +
>  static int ast2600_reset_probe(struct udevice *dev)  {
>   int rc;
> @@ -78,6 +94,7 @@ static const struct udevice_id ast2600_reset_ids[] =
> {  struct reset_ops ast2600_reset_ops = {
>   .rst_assert = ast2600_reset_assert,
>   .rst_deassert = ast2600_reset_deassert,
> + .rst_status = ast2600_reset_status,
>  };
> 
>  U_BOOT_DRIVER(ast2600_reset) = {
> --
> 2.35.1

RE: [PATCH 05/10] ARM: dts: ast2600-evb: Add I2C devices

[Ryan Chen]

> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 05/10] ARM: dts: ast2600-evb: Add I2C devices
> 
> The EVB has an EEPROM on bus 7 and a LM75 temp sensor on bus 8. Enable
> those busses we can test the I2C driver.
> 
Hello,

https://github.com/AspeedTech-BMC/linux/blob/aspeed-master-v5.15/arch/arm/boot/dts/aspeed-ast2600-evb.dts#L662-L687
The eeprom is under the same bus with bus#7. Please add in bus#7.
Bus#8 have LM75. Not have eeprom.

> Signed-off-by: Joel Stanley 
> ---
>  arch/arm/dts/ast2600-evb.dts | 11 +++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/arch/arm/dts/ast2600-evb.dts b/arch/arm/dts/ast2600-evb.dts
> index 0d650543134a..cee787ecc0eb 100644
> --- a/arch/arm/dts/ast2600-evb.dts
> +++ b/arch/arm/dts/ast2600-evb.dts
> @@ -174,6 +174,11 @@
> 
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c8_default>;
> +
> + temp@2e {
> + compatible = "adi,adt7490";
> + reg = <0x2e>;
> + };
>  };
> 
>   {
> @@ -181,6 +186,12 @@
> 
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c9_default>;
> +
> + eeprom@50 {
> + compatible = "atmel,24c08";
> + reg = <0x50>;
> + pagesize = <16>;
> + };
>  };
> 
>   {
> --
> 2.35.1

RE: [PATCH 04/10] ARM: dts: ast2500-evb: Add I2C devices

[Ryan Chen]

> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 04/10] ARM: dts: ast2500-evb: Add I2C devices
> 
> The EVB has an EEPROM on bus 3 and a LM75 temp sensor on bus 7. Enable
> those busses we can test the I2C driver.
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  arch/arm/dts/ast2500-evb.dts | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/arch/arm/dts/ast2500-evb.dts b/arch/arm/dts/ast2500-evb.dts
> index 4796ed445f57..874e042bc4cb 100644
> --- a/arch/arm/dts/ast2500-evb.dts
> +++ b/arch/arm/dts/ast2500-evb.dts
> @@ -73,3 +73,22 @@
>   pinctrl-names = "default";
>   pinctrl-0 = <_sd2_default>;
>  };
> +
> + {
> +status = "okay";
> +
> +eeprom@50 {
> +compatible = "atmel,24c08";
> +reg = <0x50>;
> +pagesize = <16>;
> +};
> +};
> +
> + {
> + status = "okay";
> +
> +lm75@4d {
> +compatible = "national,lm75";
> +reg = <0x4d>;
> +};
> +};
> --
> 2.35.1

RE: [PATCH 03/10] ARM: dts: ast2600: Dsiable I2C nodes by default

[Ryan Chen]

> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 03/10] ARM: dts: ast2600: Dsiable I2C nodes by default
> 
> Allow boards to enable the buses they use.
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  arch/arm/dts/ast2600.dtsi | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi index
> 4b23d25ede0a..a37d062bcad7 100644
> --- a/arch/arm/dts/ast2600.dtsi
> +++ b/arch/arm/dts/ast2600.dtsi
> @@ -868,6 +868,7 @@
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c3_default>;
> + status = "disabled";
>   };
> 
>   i2c3: i2c@200 {
> @@ -883,6 +884,7 @@
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c4_default>;
> + status = "disabled";
>   };
> 
>   i2c4: i2c@280 {
> @@ -898,6 +900,7 @@
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c5_default>;
> + status = "disabled";
>   };
> 
>   i2c5: i2c@300 {
> @@ -913,6 +916,7 @@
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c6_default>;
> + status = "disabled";
>   };
> 
>   i2c6: i2c@380 {
> @@ -928,6 +932,7 @@
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c7_default>;
> + status = "disabled";
>   };
> 
>   i2c7: i2c@400 {
> @@ -943,6 +948,7 @@
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c8_default>;
> + status = "disabled";
>   };
> 
>   i2c8: i2c@480 {
> @@ -958,6 +964,7 @@
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c9_default>;
> + status = "disabled";
>   };
> 
>   i2c9: i2c@500 {
> --
> 2.35.1

RE: [PATCH 02/10] ARM: dts: ast2600: Add I2C reset properties

[Ryan Chen]

> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: u-boot@lists.denx.de; Cédric Le Goater 
> Subject: [PATCH 02/10] ARM: dts: ast2600: Add I2C reset properties
> 
> The same as the upstream Linux device tree, each i2c bus has a property
> specifying the reset line.
> 
> Signed-off-by: Joel Stanley 
Reviewed-by: Ryan Chen 
> ---
>  arch/arm/dts/ast2600.dtsi | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi index
> ef5b131ac0af..4b23d25ede0a 100644
> --- a/arch/arm/dts/ast2600.dtsi
> +++ b/arch/arm/dts/ast2600.dtsi
> @@ -832,6 +832,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c1_default>;
> @@ -847,6 +848,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c2_default>;
> @@ -862,6 +864,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c3_default>;
> @@ -876,6 +879,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c4_default>;
> @@ -890,6 +894,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c5_default>;
> @@ -904,6 +909,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c6_default>;
> @@ -918,6 +924,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c7_default>;
> @@ -932,6 +939,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c8_default>;
> @@ -946,6 +954,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c9_default>;
> @@ -960,6 +969,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>   clocks = < ASPEED_CLK_APB2>;
>   pinctrl-names = "default";
>   pinctrl-0 = <_i2c10_default>; @@ -975,6 +985,7 @@
>   compatible = "aspeed,ast2600-i2c-bus";
>   bus-frequency = <10>;
>   interrupts = ;
> + resets = < ASPEED_RESET_I2C>;
>

RE: [PATCH 01/10] ARM: dts: ast2600: Add I2C pinctrl

[Ryan Chen]

> -Original Message-
> From: joel.s...@gmail.com  On Behalf Of Joel Stanley
> Sent: Monday, June 20, 2022 3:25 PM
> To: Ryan Chen ; BMC-SW
> ; Heiko Schocher 
> Cc: Eddie James ; u-boot@lists.denx.de; Cédric Le
> Goater 
> Subject: [PATCH 01/10] ARM: dts: ast2600: Add I2C pinctrl
> 
> From: Eddie James 
> 
> Set the pinctrl groups for each I2C bus. These are essential to I2C operating
> correctly.
> 
> Signed-off-by: Eddie James 
> Signed-off-by: Joel Stanley 

Review-by: Ryan Chen 
> ---
>  arch/arm/dts/ast2600.dtsi | 33 +
>  1 file changed, 33 insertions(+)
> 
> diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi index
> 64074309b7b2..ef5b131ac0af 100644
> --- a/arch/arm/dts/ast2600.dtsi
> +++ b/arch/arm/dts/ast2600.dtsi
> @@ -833,6 +833,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c1_default>;
>   status = "disabled";
>   };
> 
> @@ -846,6 +848,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c2_default>;
>   status = "disabled";
>   };
> 
> @@ -859,6 +863,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c3_default>;
>   };
> 
>   i2c3: i2c@200 {
> @@ -871,6 +877,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c4_default>;
>   };
> 
>   i2c4: i2c@280 {
> @@ -883,6 +891,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c5_default>;
>   };
> 
>   i2c5: i2c@300 {
> @@ -895,6 +905,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c6_default>;
>   };
> 
>   i2c6: i2c@380 {
> @@ -907,6 +919,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c7_default>;
>   };
> 
>   i2c7: i2c@400 {
> @@ -919,6 +933,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c8_default>;
>   };
> 
>   i2c8: i2c@480 {
> @@ -931,6 +947,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c9_default>;
>   };
> 
>   i2c9: i2c@500 {
> @@ -943,6 +961,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c10_default>;
>   status = "disabled";
>   };
> 
> @@ -956,6 +976,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c11_default>;
>   status = "disabled";
>   };
> 
> @@ -969,6 +991,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK_APB2>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_i2c12_default>;
>   status = "disabled";
>   };
> 
> @@ -982,6 +1006,8 @@
>   bus-frequency = <10>;
>   interrupts = ;
>   clocks = < ASPEED_CLK

RE: [PATCH] arm: dts: ast2600: Add I2C pinctrl

[Ryan Chen]

> -Original Message-
> From: Joel Stanley 
> Sent: Thursday, June 2, 2022 11:40 AM
> To: Eddie James 
> Cc: U-Boot Mailing List ; Dylan Hung
> ; Billy Tsai ;
> ChiaWei Wang ; Simon Glass
> 
> Subject: Re: [PATCH] arm: dts: ast2600: Add I2C pinctrl
> 
> On Wed, 1 Jun 2022 at 16:10, Eddie James  wrote:
> >
> > Set the pinctrl groups for each I2C bus. These are essential to I2C
> > operating correctly.
> >
> > Signed-off-by: Eddie James 
> 
> Reviewed-by: Joel Stanley 
> 
Reviewed-by: Ryan Chen 
> > ---
> >  arch/arm/dts/ast2600.dtsi | 33 +
> >  1 file changed, 33 insertions(+)
> >
> > diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi
> > index 64074309b7..ef5b131ac0 100644
> > --- a/arch/arm/dts/ast2600.dtsi
> > +++ b/arch/arm/dts/ast2600.dtsi
> > @@ -833,6 +833,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c1_default>;
> > status = "disabled";
> > };
> >
> > @@ -846,6 +848,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c2_default>;
> > status = "disabled";
> > };
> >
> > @@ -859,6 +863,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c3_default>;
> > };
> >
> > i2c3: i2c@200 {
> > @@ -871,6 +877,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c4_default>;
> > };
> >
> > i2c4: i2c@280 {
> > @@ -883,6 +891,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c5_default>;
> > };
> >
> > i2c5: i2c@300 {
> > @@ -895,6 +905,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c6_default>;
> > };
> >
> > i2c6: i2c@380 {
> > @@ -907,6 +919,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c7_default>;
> > };
> >
> > i2c7: i2c@400 {
> > @@ -919,6 +933,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c8_default>;
> > };
> >
> > i2c8: i2c@480 {
> > @@ -931,6 +947,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c9_default>;
> > };
> >
> > i2c9: i2c@500 {
> > @@ -943,6 +961,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <_i2c10_default>;
> > status = "disabled";
> > };
> >
> > @@ -956,6 +976,8 @@
> > bus-frequency = <10>;
> > interrupts = ;
> > clocks = < ASPEED_CLK_APB2>;
> 

RE: [PATCH] i2c: ast_i2c: Remove SCL direct drive mode

[Ryan Chen]

> -Original Message-
> From: Joel Stanley 
> Sent: Thursday, May 19, 2022 8:28 AM
> To: Eddie James ; Ryan Chen
> ; BMC-SW 
> Cc: U-Boot Mailing List ; h...@denx.de
> Subject: Re: [PATCH] i2c: ast_i2c: Remove SCL direct drive mode
> 
> On Wed, 11 May 2022 at 20:52, Eddie James 
> wrote:
> >
> > SCL direct drive mode prevents communication with devices that do
> > clock stretching, so disable. The Linux driver doesn't use this mode,
> > and the engine can handle clock stretching.
> >
> > Signed-off-by: Eddie James 
> 
> Reviewed-by: Joel Stanley 
> 
Reviewed-by: ryan_chen 

> I have added the aspeed team to cc for their review.
> 
> Ryan, we discovered this fix when testing the tpm i2c driver on the ast2600.
> 
Yes, it should remove. Thank for inform.
> > ---
> >  drivers/i2c/ast_i2c.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/i2c/ast_i2c.c b/drivers/i2c/ast_i2c.c index
> > 2d3fecaa14..8b24a260c0 100644
> > --- a/drivers/i2c/ast_i2c.c
> > +++ b/drivers/i2c/ast_i2c.c
> > @@ -76,7 +76,7 @@ static void ast_i2c_init_bus(struct udevice *dev)
> > /* Enable Master Mode. Assuming single-master */
> > writel(I2CD_MASTER_EN
> >| I2CD_M_SDA_LOCK_EN
> > -  | I2CD_MULTI_MASTER_DIS | I2CD_M_SCL_DRIVE_EN,
> > +  | I2CD_MULTI_MASTER_DIS,
> >>regs->fcr);
> > /* Enable Interrupts */
> > writel(I2CD_INTR_TX_ACK
> > --
> > 2.27.0
> >

RE: [PATCH] gpio: aspeed: Fix incorrect offset of read back register.

[Ryan Chen]

> -Original Message-
> From: Billy Tsai 
> Sent: Wednesday, April 13, 2022 1:35 PM
> To: Ryan Chen ; ChiaWei Wang
> ; BMC-SW ;
> and...@aj.id.au; Billy Tsai ;
> u-boot@lists.denx.de
> Subject: [PATCH] gpio: aspeed: Fix incorrect offset of read back register.
> 
> The offset of the current read back register is the value of the gpio pin, 
> not the
> value written for the gpio output.
> This patch fix it to avoid the other gpio output value controlled by the same
> register being set incorrectly.
> 
> Fixes: 7ad889b0f37a ("gpio: Add Aspeed GPIO driver")
> Signed-off-by: Billy Tsai 

Review-by: ryan_chen 

> ---
>  drivers/gpio/gpio-aspeed.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpio/gpio-aspeed.c b/drivers/gpio/gpio-aspeed.c index
> a8a2afcb5c..2c5415c671 100644
> --- a/drivers/gpio/gpio-aspeed.c
> +++ b/drivers/gpio/gpio-aspeed.c
> @@ -211,7 +211,7 @@ static int aspeed_gpio_direction_output(struct udevice
> *dev, unsigned int offset
>   struct aspeed_gpio_priv *priv = dev_get_priv(dev);
>   const struct aspeed_gpio_bank *bank = to_bank(offset);
>   u32 dir = readl(bank_reg(priv, bank, reg_dir));
> - u32 output = readl(bank_reg(priv, bank, reg_val));
> + u32 output = readl(bank_reg(priv, bank, reg_rdata));
> 
>   dir |= GPIO_BIT(offset);
>   writel(dir, bank_reg(priv, bank, reg_dir)); @@ -239,7 +239,7 @@
> aspeed_gpio_set_value(struct udevice *dev, unsigned int offset, int value)  {
>   struct aspeed_gpio_priv *priv = dev_get_priv(dev);
>   const struct aspeed_gpio_bank *bank = to_bank(offset);
> - u32 data = readl(bank_reg(priv, bank, reg_val));
> + u32 data = readl(bank_reg(priv, bank, reg_rdata));
> 
>   if (value)
>   data |= GPIO_BIT(offset);
> --
> 2.25.1

RE: [PATCH 0/3] gpio: Add AST2[456]00 GPIO driver

[Ryan Chen]

Hello Andrew,
This patch series are ok, Please help add Reviewed-by: Ryan Chen 


> -Original Message-
> From: Andrew Jeffery 
> Sent: Wednesday, February 16, 2022 7:57 AM
> To: u-boot@lists.denx.de
> Cc: max...@google.com; ChiaWei Wang ;
> Ryan Chen ; Troy Lee
> ; BMC-SW ;
> j...@jms.id.au; eaja...@linux.ibm.com
> Subject: [PATCH 0/3] gpio: Add AST2[456]00 GPIO driver
> 
> Hello,
> 
> This series adds support for the GPIO controller found in Aspeed's AST2400,
> AST2500 and AST2600 BMC SoCs.
> 
> By and large I've just extracted the work from Aspeed's SDK and submitted it.
> However, the driver as found in the SDK was in-turn extracted from Linux, cut
> down and adapted to u-boot. I've adjusted the copyright to reflect this (as
> found in Linux) after discussion with Troy and Ryan.
> 
> From there I've polished the patch in accordance with checkpatch and done
> some tweaks to improve consistency with the kernel driver (mainly the file
> name).
> 
> I've lightly tested the driver as-presented under qemu. That said, as the code
> has been lifted from Aspeed's SDK (and in-turn from Linux) the implementation
> has seen much wider testing.
> 
> Please review!
> 
> Andrew
> 
> Andrew Jeffery (3):
>   gpio: Add Aspeed GPIO driver
>   ARM: dts: ast2500: Add ngpios property to GPIO node
>   configs: evb-ast2[56]00: Enable GPIO control
> 
>  arch/arm/dts/ast2500.dtsi |   1 +
>  configs/evb-ast2500_defconfig |   3 +
>  configs/evb-ast2600_defconfig |   3 +
>  drivers/gpio/Kconfig  |   7 +
>  drivers/gpio/Makefile |   1 +
>  drivers/gpio/gpio-aspeed.c| 299
> ++
>  6 files changed, 314 insertions(+)
>  create mode 100644 drivers/gpio/gpio-aspeed.c
> 
> --
> 2.32.0

Re: [PATCH V2 1/7] tools: imx8mimage: not abort when mmap fail

[Ryan]

RE: [PATCH] drivers: net: add Aspeed MDIO driver

[Ryan Chen]

> -Original Message-
> From: Dylan Hung 
> Sent: Tuesday, November 2, 2021 1:42 PM
> To: u-boot@lists.denx.de; joe.hershber...@ni.com; rfried@gmail.com;
> Ryan Chen ; ChiaWei Wang
> 
> Cc: BMC-SW 
> Subject: [PATCH] drivers: net: add Aspeed MDIO driver
> 
> Add a driver for the MDIO interface for Aspeed AST2600 SOC.  The driver
> only supports clause 22 for now.
> 
> Signed-off-by: Dylan Hung 
Reviewed-by: Ryan Chen 

> ---
>  drivers/net/Kconfig   |   7 +++
>  drivers/net/Makefile  |   1 +
>  drivers/net/aspeed_mdio.c | 128
> ++
>  3 files changed, 136 insertions(+)
>  create mode 100644 drivers/net/aspeed_mdio.c
> 
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index
> 6c12959f37..4638180b74 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -826,6 +826,13 @@ config FSL_LS_MDIO
> This driver supports the MDIO bus found on the Fman 10G Ethernet
> MACs and
> on the mEMAC (which supports both Clauses 22 and 45).
> 
> +config ASPEED_MDIO
> + bool "Aspeed MDIO interface support"
> + depends on DM_MDIO
> + help
> +   This driver supports the MDIO bus of Aspeed AST2600 SOC.  The
> driver
> +   currently supports Clause 22.
> +
>  config MDIO_MUX_MMIOREG
>   bool "MDIO MUX accessed as a MMIO register access"
>   depends on DM_MDIO_MUX
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile index
> e4078d15a9..fe6c00fa48 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -101,3 +101,4 @@ obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
>  obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
>  obj-$(CONFIG_FSL_ENETC) += fsl_enetc.o fsl_enetc_mdio.o
>  obj-$(CONFIG_FSL_LS_MDIO) += fsl_ls_mdio.o
> +obj-$(CONFIG_ASPEED_MDIO) += aspeed_mdio.o
> diff --git a/drivers/net/aspeed_mdio.c b/drivers/net/aspeed_mdio.c new file
> mode 100644 index 00..a99715a728
> --- /dev/null
> +++ b/drivers/net/aspeed_mdio.c
> @@ -0,0 +1,128 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Aspeed MDIO driver
> + *
> + * (C) Copyright 2021 Aspeed Technology Inc.
> + *
> + * This file is inspired from the Linux kernel driver
> +drivers/net/phy/mdio-aspeed.c  */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define ASPEED_MDIO_CTRL 0x0
> +#define   ASPEED_MDIO_CTRL_FIRE  BIT(31)
> +#define   ASPEED_MDIO_CTRL_STBIT(28)
> +#define ASPEED_MDIO_CTRL_ST_C45  0
> +#define ASPEED_MDIO_CTRL_ST_C22  1
> +#define   ASPEED_MDIO_CTRL_OPGENMASK(27, 26)
> +#define MDIO_C22_OP_WRITE0b01
> +#define MDIO_C22_OP_READ 0b10
> +#define   ASPEED_MDIO_CTRL_PHYAD GENMASK(25, 21)
> +#define   ASPEED_MDIO_CTRL_REGAD GENMASK(20, 16)
> +#define   ASPEED_MDIO_CTRL_MIIWDATA  GENMASK(15, 0)
> +
> +#define ASPEED_MDIO_DATA 0x4
> +#define   ASPEED_MDIO_DATA_MDC_THRES GENMASK(31, 24)
> +#define   ASPEED_MDIO_DATA_MDIO_EDGE BIT(23)
> +#define   ASPEED_MDIO_DATA_MDIO_LATCHGENMASK(22, 20)
> +#define   ASPEED_MDIO_DATA_IDLE  BIT(16)
> +#define   ASPEED_MDIO_DATA_MIIRDATA  GENMASK(15, 0)
> +
> +#define ASPEED_MDIO_TIMEOUT_US   1000
> +
> +struct aspeed_mdio_priv {
> + void *base;
> +};
> +
> +static int aspeed_mdio_read(struct udevice *mdio_dev, int addr, int
> +devad, int reg) {
> + struct aspeed_mdio_priv *priv = dev_get_priv(mdio_dev);
> + u32 ctrl;
> + u32 data;
> + int rc;
> +
> + if (devad != MDIO_DEVAD_NONE)
> + return -EOPNOTSUPP;
> +
> + ctrl = ASPEED_MDIO_CTRL_FIRE
> + | FIELD_PREP(ASPEED_MDIO_CTRL_ST,
> ASPEED_MDIO_CTRL_ST_C22)
> + | FIELD_PREP(ASPEED_MDIO_CTRL_OP, MDIO_C22_OP_READ)
> + | FIELD_PREP(ASPEED_MDIO_CTRL_PHYAD, addr)
> + | FIELD_PREP(ASPEED_MDIO_CTRL_REGAD, reg);
> +
> + writel(ctrl, priv->base + ASPEED_MDIO_CTRL);
> +
> + rc = readl_poll_timeout(priv->base + ASPEED_MDIO_DATA, data,
> + data & ASPEED_MDIO_DATA_IDLE,
> + ASPEED_MDIO_TIMEOUT_US);
> +
> + if (rc < 0)
> + return rc;
> +
> + return FIELD_GET(ASPEED_MDIO_DATA_MIIRDATA, data); }
> +
> +static int aspeed_mdio_write(struct udevice *mdio_dev, int addr, int
> +devad, int reg, u16 val) {
> + struct aspeed_mdio_priv *priv = dev_get_priv(mdio_dev);
> + u32 ctrl;
> +
> + if (devad != MDIO_DEVAD_NONE)
&g

RE: [PATCH] ARM: dts: ast2600: Make WDT by default disabled

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Thursday, September 16, 2021 2:10 PM
> To: u-boot@lists.denx.de
> Cc: Ryan Chen 
> Subject: [PATCH] ARM: dts: ast2600: Make WDT by default disabled
> 
> The WDT devices described in the general .dtsi file should be marked as
> "disabled" by default.
> 
> A WDT should be then enabled in the board specific .dts file on demands.
> 
> Signed-off-by: Chia-Wei Wang 
Reviewed-by: Ryan Chen 
> ---
>  arch/arm/dts/ast2600.dtsi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/dts/ast2600.dtsi b/arch/arm/dts/ast2600.dtsi index
> ac0f08b7ea..f121f547e6 100644
> --- a/arch/arm/dts/ast2600.dtsi
> +++ b/arch/arm/dts/ast2600.dtsi
> @@ -474,21 +474,25 @@
>   wdt1: watchdog@1e785000 {
>   compatible = "aspeed,ast2600-wdt";
>   reg = <0x1e785000 0x40>;
> + status = "disabled";
>   };
> 
>   wdt2: watchdog@1e785040 {
>   compatible = "aspeed,ast2600-wdt";
>   reg = <0x1e785040 0x40>;
> + status = "disabled";
>   };
> 
>   wdt3: watchdog@1e785080 {
>   compatible = "aspeed,ast2600-wdt";
>   reg = <0x1e785080 0x40>;
> + status = "disabled";
>   };
> 
>   wdt4: watchdog@1e7850C0 {
>   compatible = "aspeed,ast2600-wdt";
>   reg = <0x1e7850C0 0x40>;
> + status = "disabled";
>   };
> 
>   lpc: lpc@1e789000 {
> --
> 2.17.1

U-Boot ECDSA Software Implementation Status

[Pabis, Ryan]

I see that Tim was working to add a non-platform specific implementation of the 
ECDSA algorithm to u-boot back in February.  I would like to use this feature 
as well and was wondering if this work has been completed and where I can find 
the patch.

Thanks,
Ryan

RE: [PATCH 7/7] configs: aspeed: Add defconfig for AST2600 EVB

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Monday, December 14, 2020 1:54 PM
> To: tr...@konsulko.com; u-boot@lists.denx.de; Ryan Chen
> 
> Cc: BMC-SW 
> Subject: [PATCH 7/7] configs: aspeed: Add defconfig for AST2600 EVB
> 
> Add the default configuration for the AST2600 EVB.
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 

> ---
>  configs/evb-ast2600_defconfig | 69
> +++
>  1 file changed, 69 insertions(+)
>  create mode 100644 configs/evb-ast2600_defconfig
> 
> diff --git a/configs/evb-ast2600_defconfig b/configs/evb-ast2600_defconfig
> new file mode 100644 index 00..003fedd02a
> --- /dev/null
> +++ b/configs/evb-ast2600_defconfig
> @@ -0,0 +1,69 @@
> +CONFIG_ARM=y
> +CONFIG_SYS_DCACHE_OFF=y
> +CONFIG_ARCH_ASPEED=y
> +CONFIG_SYS_TEXT_BASE=0x1
> +CONFIG_ASPEED_AST2600=y
> +CONFIG_TARGET_EVB_AST2600=y
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x800
> +CONFIG_NR_DRAM_BANKS=1
> +CONFIG_ENV_SIZE=0x1
> +CONFIG_SPL_SERIAL_SUPPORT=y
> +CONFIG_SPL_SIZE_LIMIT=0x1
> +CONFIG_SPL=y
> +# CONFIG_ARMV7_NONSEC is not set
> +CONFIG_DEFAULT_DEVICE_TREE="ast2600-evb"
> +# CONFIG_SYS_MALLOC_CLEAR_ON_INIT is not set CONFIG_FIT=y #
> +CONFIG_LEGACY_IMAGE_FORMAT is not set CONFIG_USE_BOOTARGS=y
> +CONFIG_BOOTARGS="console=ttyS4,115200n8 root=/dev/ram rw"
> +CONFIG_USE_BOOTCOMMAND=y
> +CONFIG_BOOTCOMMAND="bootm 2010"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_GD=y
> +CONFIG_SPL_SIZE_LIMIT_SUBTRACT_MALLOC=y
> +# CONFIG_SPL_LEGACY_IMAGE_SUPPORT is not set
> +CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_DM_RESET=y
> +CONFIG_SPL_RAM_SUPPORT=y CONFIG_SPL_RAM_DEVICE=y
> CONFIG_HUSH_PARSER=y
> +CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_DHCP=y
> CONFIG_CMD_MII=y
> +CONFIG_CMD_PING=y CONFIG_SPL_OF_CONTROL=y
> CONFIG_ENV_OVERWRITE=y
> +CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_SPL_DM=y CONFIG_SPL_DM_SEQ_ALIAS=y CONFIG_REGMAP=y
> +CONFIG_SPL_OF_TRANSLATE=y CONFIG_CLK=y CONFIG_SPL_CLK=y
> CONFIG_DM_I2C=y
> +CONFIG_MISC=y CONFIG_SPL_MISC=y CONFIG_DM_MMC=y
> CONFIG_MMC_SDHCI=y
> +CONFIG_MMC_SDHCI_ASPEED=y CONFIG_PHY_REALTEK=y
> CONFIG_DM_ETH=y
> +CONFIG_FTGMAC100=y CONFIG_PHY=y CONFIG_PINCTRL=y CONFIG_RAM=y
> +CONFIG_SPL_RAM=y CONFIG_DM_RESET=y CONFIG_DM_SERIAL=y
> +CONFIG_SYS_NS16550=y CONFIG_SYSRESET=y CONFIG_SPL_SYSRESET=y
> +CONFIG_WDT=y CONFIG_HEXDUMP=y # CONFIG_SPL_HEXDUMP is not set #
> +CONFIG_EFI_LOADER is not set
> --
> 2.17.1

RE: [PATCH 6/7] aspeed: Add AST2600 platform support

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Monday, December 14, 2020 1:54 PM
> To: tr...@konsulko.com; u-boot@lists.denx.de; Ryan Chen
> 
> Cc: BMC-SW 
> Subject: [PATCH 6/7] aspeed: Add AST2600 platform support
> 
> Add low level platform initialization for the AST2600 SoC.
> The 2-stage booting with U-Boot SPL are leveraged to support different booting
> mode.
> 
> However, currently the patch supports only the booting from memory-mapped
> SPI flash.
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 

> ---
>  arch/arm/include/asm/arch-aspeed/boot0.h |  23 ++
>  arch/arm/include/asm/arch-aspeed/platform.h  |   5 +
>  arch/arm/mach-aspeed/Kconfig |  20 ++
>  arch/arm/mach-aspeed/Makefile|   1 +
>  arch/arm/mach-aspeed/ast2600/Kconfig |  17 ++
>  arch/arm/mach-aspeed/ast2600/Makefile|   2 +
>  arch/arm/mach-aspeed/ast2600/board_common.c  | 105 +
> arch/arm/mach-aspeed/ast2600/lowlevel_init.S | 233 +++
>  arch/arm/mach-aspeed/ast2600/spl.c   |  55 +
>  board/aspeed/evb_ast2600/Kconfig |  12 +
>  board/aspeed/evb_ast2600/Makefile|   1 +
>  board/aspeed/evb_ast2600/evb_ast2600.c   |   5 +
>  drivers/sysreset/sysreset_ast.c  |   5 +
>  include/configs/evb_ast2600.h|  16 ++
>  14 files changed, 500 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-aspeed/boot0.h
>  create mode 100644 arch/arm/mach-aspeed/ast2600/Kconfig
>  create mode 100644 arch/arm/mach-aspeed/ast2600/Makefile
>  create mode 100644 arch/arm/mach-aspeed/ast2600/board_common.c
>  create mode 100644 arch/arm/mach-aspeed/ast2600/lowlevel_init.S
>  create mode 100644 arch/arm/mach-aspeed/ast2600/spl.c
>  create mode 100644 board/aspeed/evb_ast2600/Kconfig  create mode
> 100644 board/aspeed/evb_ast2600/Makefile  create mode 100644
> board/aspeed/evb_ast2600/evb_ast2600.c
>  create mode 100644 include/configs/evb_ast2600.h
> 
> diff --git a/arch/arm/include/asm/arch-aspeed/boot0.h
> b/arch/arm/include/asm/arch-aspeed/boot0.h
> new file mode 100644
> index 00..368becc87a
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-aspeed/boot0.h
> @@ -0,0 +1,23 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) Aspeed Technology Inc.
> + */
> +
> +#ifndef _ASM_ARCH_BOOT0_H
> +#define _ASM_ARCH_BOOT0_H
> +
> +_start:
> + ARM_VECTORS
> +
> + .word   0x0 /* key location */
> + .word   0x0 /* start address of image */
> + .word   0xfc00  /* maximum image size: 63KB */
> + .word   0x0 /* signature address */
> + .word   0x0 /* header revision ID low */
> + .word   0x0 /* header revision ID high */
> + .word   0x0 /* reserved */
> + .word   0x0 /* checksum */
> + .word   0x0 /* BL2 secure header */
> + .word   0x0 /* public key or digest offset for BL2 */
> +
> +#endif
> diff --git a/arch/arm/include/asm/arch-aspeed/platform.h
> b/arch/arm/include/asm/arch-aspeed/platform.h
> index 6cee036f54..d50ec5f8a9 100644
> --- a/arch/arm/include/asm/arch-aspeed/platform.h
> +++ b/arch/arm/include/asm/arch-aspeed/platform.h
> @@ -13,6 +13,11 @@
>  #define ASPEED_DRAM_BASE 0x8000
>  #define ASPEED_SRAM_BASE 0x1e72
>  #define ASPEED_SRAM_SIZE 0x9000
> +#elif defined(CONFIG_ASPEED_AST2600)
> +#define ASPEED_MAC_COUNT 4
> +#define ASPEED_DRAM_BASE 0x8000
> +#define ASPEED_SRAM_BASE 0x1000
> +#define ASPEED_SRAM_SIZE 0x1
>  #else
>  #err "Unrecognized Aspeed platform."
>  #endif
> diff --git a/arch/arm/mach-aspeed/Kconfig b/arch/arm/mach-aspeed/Kconfig
> index 4f021baa06..9a725f195a 100644
> --- a/arch/arm/mach-aspeed/Kconfig
> +++ b/arch/arm/mach-aspeed/Kconfig
> @@ -9,6 +9,11 @@ config SYS_SOC
>  config SYS_TEXT_BASE
>   default 0x
> 
> +choice
> + prompt "Aspeed SoC select"
> + depends on ARCH_ASPEED
> + default ASPEED_AST2500
> +
>  config ASPEED_AST2500
>   bool "Support Aspeed AST2500 SoC"
>   depends on DM_RESET
> @@ -18,6 +23,21 @@ config ASPEED_AST2500
> It is used as Board Management Controller on many server boards,
> which is enabled by support of LPC and eSPI peripherals.
> 
> +config ASPEED_AST2600
> + bool "Support Aspeed AST2600 SoC"
> + select CPU_V7A
> + select CPU_V7_HAS_NONSEC
> + select SYS_ARCH_TIMER
> + select SUPPORT_SPL
> + select ENABLE_ARM_SOC_BOOT0_HOOK
> + help
> +   The Aspeed AST2600 is a ARM-based SoC with Cortex-A7 CPU.
> +   It is used as B

RE: [PATCH 5/7] ARM: dts: aspeed: Add AST2600 SoC support

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Monday, December 14, 2020 1:54 PM
> To: tr...@konsulko.com; u-boot@lists.denx.de; Ryan Chen
> 
> Cc: BMC-SW 
> Subject: [PATCH 5/7] ARM: dts: aspeed: Add AST2600 SoC support
> 
> AST2600 is the 7th generation of Aspeed SoC designated for Interated Remote
> Management Processor.
> 
> AST2600 has significant performance improvement by integrating 1.2GHz
> dual-core ARM Cortex A7 (r0p5) CPU with FPU. Most of the controllers are also
> improved with more features and better performance than preceding
> AST24xx/AST25xx.
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 

> ---
>  arch/arm/dts/Makefile|1 +
>  arch/arm/dts/ast2600-evb.dts |  179 +++
>  arch/arm/dts/ast2600-u-boot.dtsi |   44 +
>  arch/arm/dts/ast2600.dtsi| 1946
> ++
>  4 files changed, 2170 insertions(+)
>  create mode 100644 arch/arm/dts/ast2600-evb.dts  create mode 100644
> arch/arm/dts/ast2600-u-boot.dtsi  create mode 100644
> arch/arm/dts/ast2600.dtsi
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> 02d04f5a8c..3e501b0f35 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -947,6 +947,7 @@ dtb-$(CONFIG_ARCH_BCM6858) += \
>  dtb-$(CONFIG_TARGET_BCMNS3) += ns3-board.dtb
> 
>  dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
> +dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
> 
>  dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
> 
> diff --git a/arch/arm/dts/ast2600-evb.dts b/arch/arm/dts/ast2600-evb.dts new
> file mode 100644 index 00..2abd31341c
> --- /dev/null
> +++ b/arch/arm/dts/ast2600-evb.dts
> @@ -0,0 +1,179 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +
> +/dts-v1/;
> +
> +#include "ast2600-u-boot.dtsi"
> +
> +/ {
> + memory {
> + device_type = "memory";
> + reg = <0x8000 0x4000>;
> + };
> +
> + chosen {
> + stdout-path = 
> + };
> +
> + aliases {
> + mmc0 = _slot0;
> + mmc1 = _slot0;
> + mmc2 = _slot1;
> + spi0 = 
> + spi1 = 
> + spi2 = 
> + ethernet0 = 
> + ethernet1 = 
> + ethernet2 = 
> + ethernet3 = 
> + };
> +
> + cpus {
> + cpu@0 {
> + clock-frequency = <8>;
> + };
> + cpu@1 {
> + clock-frequency = <8>;
> + };
> + };
> +};
> +
> + {
> + u-boot,dm-pre-reloc;
> + status = "okay";
> +};
> +
> + {
> + clock-frequency = <4>;
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_fmcquad_default>;
> +
> + flash@0 {
> + compatible = "spi-flash", "sst,w25q256";
> + status = "okay";
> + spi-max-frequency = <5000>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> +
> + flash@1 {
> + compatible = "spi-flash", "sst,w25q256";
> + status = "okay";
> + spi-max-frequency = <5000>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> +
> + flash@2 {
> + compatible = "spi-flash", "sst,w25q256";
> + status = "okay";
> + spi-max-frequency = <5000>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi1_default _spi1abr_default
> + _spi1cs1_default _spi1wp_default
> + _spi1wp_default _spi1quad_default>;
> +
> + flash@0 {
> + compatible = "spi-flash", "sst,w25q256";
> + status = "okay";
> + spi-max-frequency = <5000>;
> + spi-tx-bus-width = <4>;
> + spi-rx-bus-width = <4>;
> + };
> +};
> +
> + {
> + status = "okay";
> +
> + pinctrl-names = "default";
> + pinctrl-0 = <_spi2_default _spi2cs1_default
> + _spi2cs2_default _s

RE: [PATCH 4/7] reset: aspeed: Add AST2600 reset support

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Monday, December 14, 2020 1:54 PM
> To: tr...@konsulko.com; u-boot@lists.denx.de; Ryan Chen
> 
> Cc: BMC-SW 
> Subject: [PATCH 4/7] reset: aspeed: Add AST2600 reset support
> 
> Add controller reset support through the System Control Unit (SCU) of AST2600
> SoC.
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 

> ---
>  drivers/reset/Kconfig |   9 ++
>  drivers/reset/Makefile|   1 +
>  drivers/reset/reset-ast2600.c | 108
> ++
>  include/dt-bindings/reset/ast2600-reset.h |  70 ++
>  4 files changed, 188 insertions(+)
>  create mode 100644 drivers/reset/reset-ast2600.c  create mode 100644
> include/dt-bindings/reset/ast2600-reset.h
> 
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> 33c2736554..f5b3f8826f 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -81,6 +81,15 @@ config RESET_AST2500
> Say Y if you want to control reset signals of different peripherals
> through System Control Unit (SCU).
> 
> +config RESET_AST2600
> + bool "Reset controller driver for AST2600 SoCs"
> + depends on DM_RESET
> + default y if ASPEED_AST2600
> + help
> +   Support for reset controller on AST2600 SoC.
> +   Say Y if you want to control reset signals of different peripherals
> +   through System Control Unit (SCU).
> +
>  config RESET_ROCKCHIP
>   bool "Reset controller driver for Rockchip SoCs"
>   depends on DM_RESET && ARCH_ROCKCHIP && CLK diff --git
> a/drivers/reset/Makefile b/drivers/reset/Makefile index
> fa52aa3329..8a0f528076 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -15,6 +15,7 @@ obj-$(CONFIG_RESET_HSDK) += reset-hsdk.o
>  obj-$(CONFIG_RESET_BCM6345) += reset-bcm6345.o
>  obj-$(CONFIG_RESET_UNIPHIER) += reset-uniphier.o
>  obj-$(CONFIG_RESET_AST2500) += reset-ast2500.o
> +obj-$(CONFIG_RESET_AST2600) += reset-ast2600.o
>  obj-$(CONFIG_RESET_ROCKCHIP) += reset-rockchip.o
>  obj-$(CONFIG_RESET_MESON) += reset-meson.o
>  obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o diff --git
> a/drivers/reset/reset-ast2600.c b/drivers/reset/reset-ast2600.c new file mode
> 100644 index 00..c402968fa8
> --- /dev/null
> +++ b/drivers/reset/reset-ast2600.c
> @@ -0,0 +1,108 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright 2020 ASPEED Technology Inc.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct ast2600_reset_priv {
> + struct ast2600_scu *scu;
> +};
> +
> +static int ast2600_reset_request(struct reset_ctl *reset_ctl) {
> + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
> +   reset_ctl->dev, reset_ctl->id);
> +
> + return 0;
> +}
> +
> +static int ast2600_reset_free(struct reset_ctl *reset_ctl) {
> + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
> +   reset_ctl->dev, reset_ctl->id);
> +
> + return 0;
> +}
> +
> +static int ast2600_reset_assert(struct reset_ctl *reset_ctl) {
> + struct ast2600_reset_priv *priv = dev_get_priv(reset_ctl->dev);
> + struct ast2600_scu *scu = priv->scu;
> +
> + debug("%s: reset_ctl->id: %lu\n", __func__, reset_ctl->id);
> +
> + if (reset_ctl->id < 32)
> + writel(BIT(reset_ctl->id), scu->modrst_ctrl1);
> + else
> + writel(BIT(reset_ctl->id - 32), scu->modrst_ctrl2);
> +
> + return 0;
> +}
> +
> +static int ast2600_reset_deassert(struct reset_ctl *reset_ctl) {
> + struct ast2600_reset_priv *priv = dev_get_priv(reset_ctl->dev);
> + struct ast2600_scu *scu = priv->scu;
> +
> + debug("%s: reset_ctl->id: %lu\n", __func__, reset_ctl->id);
> +
> + if (reset_ctl->id < 32)
> + writel(BIT(reset_ctl->id), scu->modrst_clr1);
> + else
> + writel(BIT(reset_ctl->id - 32), scu->modrst_clr2);
> +
> + return 0;
> +}
> +
> +static int ast2600_reset_probe(struct udevice *dev) {
> + int rc;
> + struct ast2600_reset_priv *priv = dev_get_priv(dev);
> + struct udevice *scu_dev;
> +
> + /* get SCU base from clock device */
> + rc = uclass_get_device_by_driver(UCLASS_CLK,
> +  DM_GET_DRIVER(aspeed_ast2600_scu), 
> _dev);
> + if (rc) {
> + debug("%s: clock device n

RE: [PATCH 3/7] wdt: aspeed: Add AST2600 watchdog support

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Monday, December 14, 2020 1:54 PM
> To: tr...@konsulko.com; u-boot@lists.denx.de; Ryan Chen
> 
> Cc: BMC-SW 
> Subject: [PATCH 3/7] wdt: aspeed: Add AST2600 watchdog support
> 
> AST2600 has 8 watchdog timers including 8 sets of 32-bit decrement counters,
> based on 1MHz clock.
> 
> A 64-bit reset mask is also supported to specify which controllers should be
> reset by the WDT reset.
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 

> ---
>  .../arm/include/asm/arch-aspeed/wdt_ast2600.h | 129 ++
>  drivers/watchdog/Kconfig  |   9 ++
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/ast2600_wdt.c| 110 +++
>  4 files changed, 249 insertions(+)
>  create mode 100644 arch/arm/include/asm/arch-aspeed/wdt_ast2600.h
>  create mode 100644 drivers/watchdog/ast2600_wdt.c
> 
> diff --git a/arch/arm/include/asm/arch-aspeed/wdt_ast2600.h
> b/arch/arm/include/asm/arch-aspeed/wdt_ast2600.h
> new file mode 100644
> index 00..96e8ca07e3
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-aspeed/wdt_ast2600.h
> @@ -0,0 +1,129 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) 2020 Aspeed Technology Inc.
> + */
> +
> +#ifndef _ASM_ARCH_WDT_AST2600_H
> +#define _ASM_ARCH_WDT_AST2600_H
> +
> +#define WDT_BASE 0x1e785000
> +
> +/*
> + * Special value that needs to be written to counter_restart register
> +to
> + * (re)start the timer
> + */
> +#define WDT_COUNTER_RESTART_VAL  0x4755
> +
> +/* reset mode */
> +#define WDT_RESET_MODE_SOC   0
> +#define WDT_RESET_MODE_CHIP  1
> +#define WDT_RESET_MODE_CPU   2
> +
> +/* bit-fields of WDT control register */
> +#define WDT_CTRL_2ND_BOOTBIT(7)
> +#define WDT_CTRL_RESET_MODE_MASK GENMASK(6, 5)
> +#define WDT_CTRL_RESET_MODE_SHIFT5
> +#define WDT_CTRL_CLK1MHZ BIT(4)
> +#define WDT_CTRL_RESET   BIT(1)
> +#define WDT_CTRL_EN  BIT(0)
> +
> +/* bit-fields of WDT reset mask1 register */
> +#define WDT_RESET_MASK1_RVAS BIT(25)
> +#define WDT_RESET_MASK1_GPIO1BIT(24)
> +#define WDT_RESET_MASK1_XDMA2BIT(23)
> +#define WDT_RESET_MASK1_XDMA1BIT(22)
> +#define WDT_RESET_MASK1_MCTP2BIT(21)
> +#define WDT_RESET_MASK1_MCTP1BIT(20)
> +#define WDT_RESET_MASK1_JTAG1BIT(19)
> +#define WDT_RESET_MASK1_SD_SDIO1 BIT(18)
> +#define WDT_RESET_MASK1_MAC2 BIT(17)
> +#define WDT_RESET_MASK1_MAC1 BIT(16)
> +#define WDT_RESET_MASK1_GPMCUBIT(15)
> +#define WDT_RESET_MASK1_DPMCUBIT(14)
> +#define WDT_RESET_MASK1_DP   BIT(13)
> +#define WDT_RESET_MASK1_HAC  BIT(12)
> +#define WDT_RESET_MASK1_VIDEOBIT(11)
> +#define WDT_RESET_MASK1_CRT  BIT(10)
> +#define WDT_RESET_MASK1_GCRT BIT(9)
> +#define WDT_RESET_MASK1_USB11_UHCI   BIT(8)
> +#define WDT_RESET_MASK1_USB_PORTABIT(7)
> +#define WDT_RESET_MASK1_USB_PORTBBIT(6)
> +#define WDT_RESET_MASK1_COPROC   BIT(5)
> +#define WDT_RESET_MASK1_SOC  BIT(4)
> +#define WDT_RESET_MASK1_SLI  BIT(3)
> +#define WDT_RESET_MASK1_AHB  BIT(2)
> +#define WDT_RESET_MASK1_SDRAMBIT(1)
> +#define WDT_RESET_MASK1_ARM  BIT(0)
> +
> +/* bit-fields of WDT reset mask2 register */
> +#define WDT_RESET_MASK2_ESPI BIT(26)
> +#define WDT_RESET_MASK2_I3C_BUS8 BIT(25)
> +#define WDT_RESET_MASK2_I3C_BUS7 BIT(24)
> +#define WDT_RESET_MASK2_I3C_BUS6 BIT(23)
> +#define WDT_RESET_MASK2_I3C_BUS5 BIT(22)
> +#define WDT_RESET_MASK2_I3C_BUS4 BIT(21)
> +#define WDT_RESET_MASK2_I3C_BUS3 BIT(20)
> +#define WDT_RESET_MASK2_I3C_BUS2 BIT(19)
> +#define WDT_RESET_MASK2_I3C_BUS1 BIT(18)
> +#define WDT_RESET_MASK2_I3C_GLOBAL   BIT(17)
> +#define WDT_RESET_MASK2_I2C  BIT(16)
> +#define WDT_RESET_MASK2_FSI  BIT(15)
> +#define WDT_RESET_MASK2_ADC  BIT(14)
> +#define WDT_RESET_MASK2_PWM  BIT(13)
> +#define WDT_RESET_MASK2_PECI BIT(12)
> +#define WDT_RESET_MASK2_LPC  BIT(11)
> +#define WDT_RESET_MASK2_MDC_MDIO BIT(10)
> +#define WDT_RESET_MASK2_GPIO2BIT(9)
> +#define WDT_RESET_MASK2_JTAG2BIT(8)
> +#define WDT_RESET_MASK2_SD_SDIO2 BIT(7)
> +#define WDT_RESET_MASK2_MAC4 BIT(6)
> +#define WDT_RESET_MASK2_MAC3 BIT(5)
> +#define WDT_RESET_MASK2_SOC

RE: [PATCH 2/7] ram: aspeed: Add AST2600 DRAM control support

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Monday, December 14, 2020 1:54 PM
> To: tr...@konsulko.com; u-boot@lists.denx.de; Ryan Chen
> 
> Cc: BMC-SW ; Dylan Hung
> 
> Subject: [PATCH 2/7] ram: aspeed: Add AST2600 DRAM control support
> 
> From: Dylan Hung 
> 
> AST2600 supports DDR4 SDRAM with maximum speed DDR4-1600.
> The DDR4 DRAM types including 128MbX16 (2Gb), 256MbX16 (4Gb),
> 512MbX16 (8Gb), 1GbX16 (16Gb), and 1GbX8 TwinDie (16Gb) are supported.
> 
> Signed-off-by: Dylan Hung 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 

> ---
>  .../include/asm/arch-aspeed/sdram_ast2600.h   |  163 +++
>  drivers/ram/aspeed/Kconfig|   61 +-
>  drivers/ram/aspeed/Makefile   |3 +-
>  drivers/ram/aspeed/sdram_ast2600.c| 1061
> +
>  4 files changed, 1286 insertions(+), 2 deletions(-)  create mode 100644
> arch/arm/include/asm/arch-aspeed/sdram_ast2600.h
>  create mode 100644 drivers/ram/aspeed/sdram_ast2600.c
> 
> diff --git a/arch/arm/include/asm/arch-aspeed/sdram_ast2600.h
> b/arch/arm/include/asm/arch-aspeed/sdram_ast2600.h
> new file mode 100644
> index 00..d2408c0020
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-aspeed/sdram_ast2600.h
> @@ -0,0 +1,163 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (c) Aspeed Technology Inc.
> + */
> +#ifndef _ASM_ARCH_SDRAM_AST2600_H
> +#define _ASM_ARCH_SDRAM_AST2600_H
> +
> +/* keys for unlocking HW */
> +#define SDRAM_UNLOCK_KEY 0xFC600309
> +#define SDRAM_VIDEO_UNLOCK_KEY   0x00440003
> +
> +/* Fixed priority DRAM Requests mask */
> +#define REQ_PRI_VGA_HW_CURSOR_R 0
> +#define REQ_PRI_VGA_CRT_R   1
> +#define REQ_PRI_SOC_DISPLAY_CTRL_R  2
> +#define REQ_PRI_PCIE_BUS1_RW3
> +#define REQ_PRI_VIDEO_HIGH_PRI_W4
> +#define REQ_PRI_CPU_RW  5
> +#define REQ_PRI_SLI_RW  6
> +#define REQ_PRI_PCIE_BUS2_RW7
> +#define REQ_PRI_USB2_0_HUB_EHCI1_DMA_RW 8 #define
> +REQ_PRI_USB2_0_DEV_EHCI2_DMA_RW 9
> +#define REQ_PRI_USB1_1_UHCI_HOST_RW 10
> +#define REQ_PRI_AHB_BUS_RW  11
> +#define REQ_PRI_CM3_DATA_RW 12
> +#define REQ_PRI_CM3_INST_R  13
> +#define REQ_PRI_MAC0_DMA_RW 14
> +#define REQ_PRI_MAC1_DMA_RW 15
> +#define REQ_PRI_SDIO_DMA_RW 16
> +#define REQ_PRI_PILOT_ENGINE_RW 17
> +#define REQ_PRI_XDMA1_RW18
> +#define REQ_PRI_MCTP1_RW19
> +#define REQ_PRI_VIDEO_FLAG_RW   20
> +#define REQ_PRI_VIDEO_LOW_PRI_W 21
> +#define REQ_PRI_2D_ENGINE_DATA_RW   22
> +#define REQ_PRI_ENC_ENGINE_RW   23
> +#define REQ_PRI_MCTP2_RW24
> +#define REQ_PRI_XDMA2_RW25
> +#define REQ_PRI_ECC_RSA_RW  26
> +
> +#define MCR30_RESET_DLL_DELAY_EN BIT(4)
> +#define MCR30_MODE_REG_SEL_SHIFT 1
> +#define MCR30_MODE_REG_SEL_MASK  GENMASK(3, 1)
> +#define MCR30_SET_MODE_REG   BIT(0)
> +
> +#define MCR30_SET_MR(mr) ((mr << MCR30_MODE_REG_SEL_SHIFT) |
> +MCR30_SET_MODE_REG)
> +
> +#define MCR34_SELF_REFRESH_STATUS_MASK   GENMASK(30, 28)
> +
> +#define MCR34_ODT_DELAY_SHIFT12
> +#define MCR34_ODT_DELAY_MASK GENMASK(15, 12)
> +#define MCR34_ODT_EXT_SHIFT  10
> +#define MCR34_ODT_EXT_MASK   GENMASK(11, 10)
> +#define MCR34_ODT_AUTO_ONBIT(9)
> +#define MCR34_ODT_EN BIT(8)
> +#define MCR34_RESETN_DIS BIT(7)
> +#define MCR34_MREQI_DIS  BIT(6)
> +#define MCR34_MREQ_BYPASS_DISBIT(5)
> +#define MCR34_RGAP_CTRL_EN   BIT(4)
> +#define MCR34_CKE_OUT_IN_SELF_REF_DISBIT(3)
> +#define MCR34_FOURCE_SELF_REF_EN BIT(2)
> +#define MCR34_AUTOPWRDN_EN   BIT(1)
> +#define MCR34_CKE_EN BIT(0)
> +
> +#define MCR38_RW_MAX_GRANT_CNT_RQ_SHIFT  16
> +#define MCR38_RW_MAX_GRANT_CNT_RQ_MASK   GENMASK(20, 16)
> +
> +/* default request queued limitation mask (0xFFBBFFF4) */
> +#define MCR3C_DEFAULT_MASK
> \
> + ~(REQ_PRI_VGA_HW_CURSOR_R | REQ_PRI_VGA_CRT_R |
> REQ_PRI_PCIE_BUS1_RW | \
> +   REQ_PRI_XDMA1_RW | REQ_PRI_2D_ENGINE_DATA_RW)
> +
> +#define MCR50_RESET_ALL_INTR BIT(31)
> +#define SDRAM_CONF_ECC_AUTO_SCRUBBINGBIT(9)
> +#define SDRAM_CONF_SCRAMBLE  BIT(8)
> +#define SDRAM_CONF_ECC_ENBIT(7)
> +#define SDRAM_CONF_DUALX8BIT(5)
> +#define SDRAM_CONF_DDR4  BIT(4)
> +#define SDRAM_CONF_VGA_SIZE_SHIFT2

RE: [v2 2/2] cosmetic: reset: ast2500: Rename driver and configs

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Monday, October 12, 2020 10:36 AM
> To: tr...@konsulko.com; u-boot@lists.denx.de; max...@google.com
> Cc: Ryan Chen ; BMC-SW
> 
> Subject: [v2 2/2] cosmetic: reset: ast2500: Rename driver and configs
> 
> 1. Rename AST2500 reset driver from ast2500-reset.c
>to reset-ast2500.c
> 2. Rename AST2500 reset kconfig option from AST2500_RESET
>to RESET_AST2500
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 
> ---
>  drivers/reset/Kconfig  | 2 +-
>  drivers/reset/{ast2500-reset.c => reset-ast2500.c} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)  rename
> drivers/reset/{ast2500-reset.c => reset-ast2500.c} (100%)
> 
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> 8b243fdcc6..33c2736554 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -72,7 +72,7 @@ config RESET_UNIPHIER
> Say Y if you want to control reset signals provided by System Control
> block, Media I/O block, Peripheral Block.
> 
> -config AST2500_RESET
> +config RESET_AST2500
>   bool "Reset controller driver for AST2500 SoCs"
>   depends on DM_RESET
>   default y if ASPEED_AST2500
> diff --git a/drivers/reset/ast2500-reset.c b/drivers/reset/reset-ast2500.c
> similarity index 100% rename from drivers/reset/ast2500-reset.c rename to
> drivers/reset/reset-ast2500.c
> --
> 2.17.1

RE: [v2 1/2] reset: ast2500: Use SCU for reset control

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Monday, October 12, 2020 10:36 AM
> To: tr...@konsulko.com; u-boot@lists.denx.de; max...@google.com
> Cc: Ryan Chen ; BMC-SW
> 
> Subject: [v2 1/2] reset: ast2500: Use SCU for reset control
> 
> The System Control Unit (SCU) controller of Aspeed SoCs provides the reset
> control for each peripheral.
> 
> This patch refactors the reset method to leverage the SCU reset control. Thus
> the driver dependency on watchdog including dedicated WDT API and reset
> flag encoding can be eliminated.
> 
> The Kconfig description is also updated accordingly.
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 
> ---
>  arch/arm/dts/ast2500-u-boot.dtsi  |  7 +-
>  drivers/reset/Kconfig |  9 +--
>  drivers/reset/ast2500-reset.c | 97 ---
>  include/dt-bindings/reset/ast2500-reset.h | 73 +
>  4 files changed, 97 insertions(+), 89 deletions(-)
> 
> diff --git a/arch/arm/dts/ast2500-u-boot.dtsi
> b/arch/arm/dts/ast2500-u-boot.dtsi
> index 51a5244766..ea60e4c8db 100644
> --- a/arch/arm/dts/ast2500-u-boot.dtsi
> +++ b/arch/arm/dts/ast2500-u-boot.dtsi
> @@ -16,7 +16,6 @@
>   rst: reset-controller {
>   u-boot,dm-pre-reloc;
>   compatible = "aspeed,ast2500-reset";
> - aspeed,wdt = <>;
>   #reset-cells = <1>;
>   };
> 
> @@ -27,7 +26,7 @@
>   0x1e6e0200 0x1d4 >;
>   #reset-cells = <1>;
>   clocks = < ASPEED_CLK_MPLL>;
> - resets = < AST_RESET_SDRAM>;
> + resets = < ASPEED_RESET_SDRAM>;
>   };
> 
>   ahb {
> @@ -41,7 +40,7 @@
>   reg = <0x1e740100>;
>   #reset-cells = <1>;
>   clocks = < ASPEED_CLK_SDIO>;
> - resets = < AST_RESET_SDIO>;
> + resets = < ASPEED_RESET_SDIO>;
>   };
> 
>   sdhci1: sdhci@1e740200 {
> @@ -49,7 +48,7 @@
>   reg = <0x1e740200>;
>   #reset-cells = <1>;
>   clocks = < ASPEED_CLK_SDIO>;
> - resets = < AST_RESET_SDIO>;
> + resets = < ASPEED_RESET_SDIO>;
>   };
>   };
> 
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> b60e11f98b..8b243fdcc6 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -74,13 +74,12 @@ config RESET_UNIPHIER
> 
>  config AST2500_RESET
>   bool "Reset controller driver for AST2500 SoCs"
> - depends on DM_RESET && WDT_ASPEED
> + depends on DM_RESET
>   default y if ASPEED_AST2500
>   help
> -   Support for reset controller on AST2500 SoC. This controller uses
> -   watchdog to reset different peripherals and thus only supports
> -   resets that are supported by watchdog. The main limitation though
> -   is that some reset signals, like I2C or MISC reset multiple devices.
> +   Support for reset controller on AST2500 SoC.
> +   Say Y if you want to control reset signals of different peripherals
> +   through System Control Unit (SCU).
> 
>  config RESET_ROCKCHIP
>   bool "Reset controller driver for Rockchip SoCs"
> diff --git a/drivers/reset/ast2500-reset.c b/drivers/reset/ast2500-reset.c 
> index
> beb5cd8fa8..e7b5c7deca 100644
> --- a/drivers/reset/ast2500-reset.c
> +++ b/drivers/reset/ast2500-reset.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright 2017 Google, Inc
> + * Copyright 2020 ASPEED Technology Inc.
>   */
> 
>  #include 
> @@ -9,28 +10,26 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
> -#include 
> 
>  struct ast2500_reset_priv {
> - /* WDT used to perform resets. */
> - struct udevice *wdt;
>   struct ast2500_scu *scu;
>  };
> 
> -static int ast2500_ofdata_to_platdata(struct udevice *dev)
> +static int ast2500_reset_request(struct reset_ctl *reset_ctl)
>  {
> - struct ast2500_reset_priv *priv = dev_get_priv(dev);
> - int ret;
> + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
> +   reset_ctl->dev, reset_ctl->id);
> 
> - ret = uclass_get_device_by_phandle(UCLASS_WDT, dev, "aspeed,wdt",
> -   

RE: [PATCH 1/2] reset: ast2500: Use SCU for reset control

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Tuesday, September 8, 2020 3:21 PM
> To: Ryan Chen ; max...@google.com;
> u-boot@lists.denx.de
> Cc: BMC-SW 
> Subject: [PATCH 1/2] reset: ast2500: Use SCU for reset control
> 
> The System Control Unit (SCU) controller of Aspeed SoCs provides the reset
> control for each peripheral.
> 
> This patch refactors the reset method to leverage the SCU reset control. Thus
> the driver dependency on watchdog including dedicated WDT API and reset
> flag encoding can be eliminated.
> 
> The Kconfig description is also updated accordingly.
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 
> ---
>  arch/arm/dts/ast2500-u-boot.dtsi  |  7 +-
>  drivers/reset/Kconfig |  9 +--
>  drivers/reset/ast2500-reset.c | 97 ---
>  include/dt-bindings/reset/ast2500-reset.h | 73 +
>  4 files changed, 97 insertions(+), 89 deletions(-)
> 
> diff --git a/arch/arm/dts/ast2500-u-boot.dtsi
> b/arch/arm/dts/ast2500-u-boot.dtsi
> index 8ac4215745..ca4aac2159 100644
> --- a/arch/arm/dts/ast2500-u-boot.dtsi
> +++ b/arch/arm/dts/ast2500-u-boot.dtsi
> @@ -15,7 +15,6 @@
>   rst: reset-controller {
>   u-boot,dm-pre-reloc;
>   compatible = "aspeed,ast2500-reset";
> - aspeed,wdt = <>;
>   #reset-cells = <1>;
>   };
> 
> @@ -26,7 +25,7 @@
>   0x1e6e0200 0x1d4 >;
>   #reset-cells = <1>;
>   clocks = < PLL_MPLL>;
> - resets = < AST_RESET_SDRAM>;
> + resets = < ASPEED_RESET_SDRAM>;
>   };
> 
>   ahb {
> @@ -40,7 +39,7 @@
>   reg = <0x1e740100>;
>   #reset-cells = <1>;
>   clocks = < BCLK_SDCLK>;
> - resets = < AST_RESET_SDIO>;
> + resets = < ASPEED_RESET_SDIO>;
>   };
> 
>   sdhci1: sdhci@1e740200 {
> @@ -48,7 +47,7 @@
>   reg = <0x1e740200>;
>   #reset-cells = <1>;
>   clocks = < BCLK_SDCLK>;
> - resets = < AST_RESET_SDIO>;
> + resets = < ASPEED_RESET_SDIO>;
>   };
>   };
> 
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> 253902ff57..796aa267c5 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -74,13 +74,12 @@ config RESET_UNIPHIER
> 
>  config AST2500_RESET
>   bool "Reset controller driver for AST2500 SoCs"
> - depends on DM_RESET && WDT_ASPEED
> + depends on DM_RESET
>   default y if ASPEED_AST2500
>   help
> -   Support for reset controller on AST2500 SoC. This controller uses
> -   watchdog to reset different peripherals and thus only supports
> -   resets that are supported by watchdog. The main limitation though
> -   is that some reset signals, like I2C or MISC reset multiple devices.
> +   Support for reset controller on AST2500 SoC.
> +   Say Y if you want to control reset signals of different peripherals
> +   through System Control Unit (SCU).
> 
>  config RESET_ROCKCHIP
>   bool "Reset controller driver for Rockchip SoCs"
> diff --git a/drivers/reset/ast2500-reset.c b/drivers/reset/ast2500-reset.c 
> index
> beb5cd8fa8..e7b5c7deca 100644
> --- a/drivers/reset/ast2500-reset.c
> +++ b/drivers/reset/ast2500-reset.c
> @@ -1,6 +1,7 @@
>  // SPDX-License-Identifier: GPL-2.0
>  /*
>   * Copyright 2017 Google, Inc
> + * Copyright 2020 ASPEED Technology Inc.
>   */
> 
>  #include 
> @@ -9,28 +10,26 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
> -#include 
> 
>  struct ast2500_reset_priv {
> - /* WDT used to perform resets. */
> - struct udevice *wdt;
>   struct ast2500_scu *scu;
>  };
> 
> -static int ast2500_ofdata_to_platdata(struct udevice *dev)
> +static int ast2500_reset_request(struct reset_ctl *reset_ctl)
>  {
> - struct ast2500_reset_priv *priv = dev_get_priv(dev);
> - int ret;
> + debug("%s(reset_ctl=%p) (dev=%p, id=%lu)\n", __func__, reset_ctl,
> +   reset_ctl->dev, reset_ctl->id);
> 
> - ret = uclass_get_device_by_phandle(UCLASS_WDT, dev, "aspeed,wdt",
> -  

RE: [PATCH 2/2] cosmetic: reset: ast2500: Rename driver and configs

[Ryan Chen]

> -Original Message-
> From: ChiaWei Wang 
> Sent: Tuesday, September 8, 2020 3:21 PM
> To: Ryan Chen ; max...@google.com;
> u-boot@lists.denx.de
> Cc: BMC-SW 
> Subject: [PATCH 2/2] cosmetic: reset: ast2500: Rename driver and configs
> 
> 1. Rename AST2500 reset driver from ast2500-reset.c
>to reset-ast2500.c
> 2. Rename AST2500 reset kconfig option from AST2500_RESET
>to RESET_AST2500
> 
> Signed-off-by: Chia-Wei, Wang 

Reviewed-by: Ryan Chen 
> ---
>  drivers/reset/Kconfig  | 2 +-
>  drivers/reset/{ast2500-reset.c => reset-ast2500.c} | 0
>  2 files changed, 1 insertion(+), 1 deletion(-)  rename
> drivers/reset/{ast2500-reset.c => reset-ast2500.c} (100%)
> 
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig index
> 796aa267c5..381d222524 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -72,7 +72,7 @@ config RESET_UNIPHIER
> Say Y if you want to control reset signals provided by System Control
> block, Media I/O block, Peripheral Block.
> 
> -config AST2500_RESET
> +config RESET_AST2500
>   bool "Reset controller driver for AST2500 SoCs"
>   depends on DM_RESET
>   default y if ASPEED_AST2500
> diff --git a/drivers/reset/ast2500-reset.c b/drivers/reset/reset-ast2500.c
> similarity index 100% rename from drivers/reset/ast2500-reset.c rename to
> drivers/reset/reset-ast2500.c
> --
> 2.17.1

RE: [PATCH 2/2] ram: add ddr4 dual x8 configuration

[Ryan Chen]

> -Original Message-
> From: Dylan Hung 
> Sent: Monday, September 7, 2020 4:25 PM
> To: Ryan Chen ; u-boot@lists.denx.de
> Cc: BMC-SW 
> Subject: [PATCH 2/2] ram: add ddr4 dual x8 configuration
> 
> the aspeed ddr sdram controller needs to know if the memory chip mounted
> on the board is dual x8 die or not. Or it may get the wrong size of the memory
> space.
> 
> Signed-off-by: Dylan Hung 

Reviewed-by: Ryan Chen 

> ---
>  drivers/ram/Kconfig|  1 +
>  drivers/ram/aspeed/Kconfig | 10 ++
>  drivers/ram/aspeed/sdram_ast2500.c |  2 +-
>  3 files changed, 12 insertions(+), 1 deletion(-)  create mode 100644
> drivers/ram/aspeed/Kconfig
> 
> diff --git a/drivers/ram/Kconfig b/drivers/ram/Kconfig index
> 7e6e981897..d277237288 100644
> --- a/drivers/ram/Kconfig
> +++ b/drivers/ram/Kconfig
> @@ -76,3 +76,4 @@ config IMXRT_SDRAM
>  source "drivers/ram/rockchip/Kconfig"
>  source "drivers/ram/sifive/Kconfig"
>  source "drivers/ram/stm32mp1/Kconfig"
> +source "drivers/ram/aspeed/Kconfig"
> diff --git a/drivers/ram/aspeed/Kconfig b/drivers/ram/aspeed/Kconfig new file
> mode 100644 index 00..020c913188
> --- /dev/null
> +++ b/drivers/ram/aspeed/Kconfig
> @@ -0,0 +1,10 @@
> +if RAM || SPL_RAM
> +config ASPEED_DDR4_DUALX8
> + bool "Enable Dual X8 DDR4 die"
> + depends on DM && OF_CONTROL && ARCH_ASPEED
> + default n
> + help
> + Say Y if dual X8 DDR4 die is used on the board.  The aspeed ddr
> sdram
> + controller needs to know if the memory chip mounted on the board
> is dual
> +  x8 die or not.  Or it may get the wrong size of the memory 
> space.
> +endif
> diff --git a/drivers/ram/aspeed/sdram_ast2500.c
> b/drivers/ram/aspeed/sdram_ast2500.c
> index a3adaa8a99..8bfbf562c3 100644
> --- a/drivers/ram/aspeed/sdram_ast2500.c
> +++ b/drivers/ram/aspeed/sdram_ast2500.c
> @@ -247,7 +247,7 @@ static int ast2500_sdrammc_init_ddr4(struct
> dram_info *info)
>   | SDRAM_PCR_RESETN_DIS
>   | SDRAM_PCR_RGAP_CTRL_EN | SDRAM_PCR_ODT_EN |
> SDRAM_PCR_ODT_EXT_EN;
>   const u32 conf = (SDRAM_CONF_CAP_1024M <<
> SDRAM_CONF_CAP_SHIFT) -#ifdef CONFIG_DUALX8_RAM
> +#ifdef CONFIG_ASPEED_DDR4_DUALX8
>   | SDRAM_CONF_DUALX8
>  #endif
>   | SDRAM_CONF_SCRAMBLE | SDRAM_CONF_SCRAMBLE_PAT2 |
> SDRAM_CONF_DDR4;
> --
> 2.17.1

RE: [PATCH 1/2] ram: move aspeed ram driver into drivers/ directory

[Ryan Chen]

> -Original Message-
> From: Dylan Hung 
> Sent: Monday, September 7, 2020 4:25 PM
> To: Ryan Chen ; u-boot@lists.denx.de
> Cc: BMC-SW 
> Subject: [PATCH 1/2] ram: move aspeed ram driver into drivers/ directory
> 
> to improve the maintainability.  It is more easier to modify and add
> configurations of the driver in the centralized ram driver directory.
> 
> Signed-off-by: Dylan Hung 

Reviewed-by: Ryan Chen 

> ---
>  arch/arm/mach-aspeed/ast2500/Makefile  | 2
> +-
>  drivers/ram/Makefile   | 1
> +
>  drivers/ram/aspeed/Makefile| 3
> +++
>  .../mach-aspeed/ast2500 => drivers/ram/aspeed}/sdram_ast2500.c | 0
>  4 files changed, 5 insertions(+), 1 deletion(-)  create mode 100644
> drivers/ram/aspeed/Makefile  rename {arch/arm/mach-aspeed/ast2500 =>
> drivers/ram/aspeed}/sdram_ast2500.c (100%)
> 
> diff --git a/arch/arm/mach-aspeed/ast2500/Makefile
> b/arch/arm/mach-aspeed/ast2500/Makefile
> index 4c27c8fc46..db70432ad0 100644
> --- a/arch/arm/mach-aspeed/ast2500/Makefile
> +++ b/arch/arm/mach-aspeed/ast2500/Makefile
> @@ -1,3 +1,3 @@
>  obj-y += lowlevel_init.o
>  obj-y += board_common.o
> -obj-y += clk_ast2500.o sdram_ast2500.o
> +obj-y += clk_ast2500.o
> diff --git a/drivers/ram/Makefile b/drivers/ram/Makefile index
> 769c9d6218..a57d506752 100644
> --- a/drivers/ram/Makefile
> +++ b/drivers/ram/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_ARCH_ROCKCHIP) += rockchip/
> 
>  obj-$(CONFIG_K3_AM654_DDRSS) += k3-am654-ddrss.o
>  obj-$(CONFIG_ARCH_MEDIATEK) += mediatek/
> +obj-$(CONFIG_ARCH_ASPEED) += aspeed/
>  obj-$(CONFIG_K3_J721E_DDRSS) += k3-j721e/
> 
>  obj-$(CONFIG_IMXRT_SDRAM) += imxrt_sdram.o diff --git
> a/drivers/ram/aspeed/Makefile b/drivers/ram/aspeed/Makefile new file mode
> 100644 index 00..af604f8a4b
> --- /dev/null
> +++ b/drivers/ram/aspeed/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +obj-$(CONFIG_ASPEED_AST2500) += sdram_ast2500.o
> \ No newline at end of file
> diff --git a/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
> b/drivers/ram/aspeed/sdram_ast2500.c
> similarity index 100%
> rename from arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
> rename to drivers/ram/aspeed/sdram_ast2500.c
> --
> 2.17.1

RE: [PATCH v2] arm: dts: fix ast2500-evb inclusion for the correct soc family

[Ryan Chen]

> -Original Message-
> From: Thirupathaiah Annapureddy 
> Sent: Wednesday, September 2, 2020 4:43 AM
> To: u-boot@lists.denx.de
> Cc: Maxim Sloyko ; Marek Vasut ;
> thir...@microsoft.com; thir...@linux.microsoft.com; Tom Rini
> ; ChiaWei Wang ;
> Ryan Chen 
> Subject: [PATCH v2] arm: dts: fix ast2500-evb inclusion for the correct soc
> family
> 
> Include ast2500-evb.dtb for CONFIG_ASPEED_AST2500 instead of for all
> aspeed targets.
> 
> ast2400 is based on ARM926EJ-S processor (ARMv5-architecture).
> ast2500 is based on ARM1176JZS processor (ARMv6-architecture).
> ast2600 is based on Cortex A7 processor (ARMv7-A architecture).
> Each of the above SOC is using a different ARM CPU(s) with different ARM
> architecture revision. It is not possible to support all 3 of these families 
> in a
> single binary. So there is no need to build ast2500-evb.dtb for other SOC
> families.
> 
> Signed-off-by: Thirupathaiah Annapureddy 
> ---
> 
> Changes in v2:
> - Incorporated the feedback from Tom Rini and Ryan Chen.
> 
>  arch/arm/dts/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> 7e29b9096b..33d40a05f9 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -938,7 +938,7 @@ dtb-$(CONFIG_ARCH_BCM6858) += \
> 
>  dtb-$(CONFIG_TARGET_BCMNS3) += ns3-board.dtb
> 
> -dtb-$(CONFIG_ARCH_ASPEED) += ast2500-evb.dtb
> +dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
> 
I prefer keep the Makefile logic clear use one CONFIG_ARCH_ASPEED to make all 
ASPEED SoC dtb.
And also align with kernel tree " 
https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/Makefile;.
Another point of view, For example, There also have AST2520 SoC which share the 
same CPU architecture with AST2500,
And that will need another CONFIG_ASPEED_AST2520, That will cause more 
complicated dts Makefile.
 
>  dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
> 
> --
> 2.25.2

[PATCH v2 0/3] Rename ASPEED SoC clock name

[Ryan Chen]

This patch series refactor the exiting ASPEED clock name define sync with Linux 
kernel. And also add SPDX-License

V2 : modify patch 2/3 title form "aspeed:clock:" -> "clock:aspeed:" description

Ryan Chen (3):
  cosmetic: aspeed: ast2500: Rename clock header
  clock:aspeed: Sync with Linux kernel clock header define
  cosmetic: aspeed: Modify for SPDX-License

 arch/arm/dts/ast2500-u-boot.dtsi | 23 ++-
 arch/arm/mach-aspeed/ast2500/sdram_ast2500.c |  2 +-
 drivers/clk/aspeed/clk_ast2500.c | 40 +--
 include/dt-bindings/clock/aspeed-clock.h | 42 
 include/dt-bindings/clock/ast2500-scu.h  | 30 --
 5 files changed, 74 insertions(+), 63 deletions(-)
 create mode 100644 include/dt-bindings/clock/aspeed-clock.h
 delete mode 100644 include/dt-bindings/clock/ast2500-scu.h

-- 
2.17.1

[PATCH v2 3/3] cosmetic: aspeed: Modify for SPDX-License

[Ryan Chen]

Modify SPDX-License for furture patch warning

Signed-off-by: Ryan Chen 
---
 arch/arm/dts/ast2500-u-boot.dtsi | 1 +
 include/dt-bindings/clock/aspeed-clock.h | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/ast2500-u-boot.dtsi b/arch/arm/dts/ast2500-u-boot.dtsi
index 29b08f16ac..51a5244766 100644
--- a/arch/arm/dts/ast2500-u-boot.dtsi
+++ b/arch/arm/dts/ast2500-u-boot.dtsi
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
 
diff --git a/include/dt-bindings/clock/aspeed-clock.h 
b/include/dt-bindings/clock/aspeed-clock.h
index e6599deeb9..a1aa8c07ce 100644
--- a/include/dt-bindings/clock/aspeed-clock.h
+++ b/include/dt-bindings/clock/aspeed-clock.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+// SPDX-License-Identifier: GPL-2.0
 
 #define ASPEED_CLK_GATE_ECLK   0
 #define ASPEED_CLK_GATE_GCLK   1
-- 
2.17.1

[PATCH v2 1/3] cosmetic: aspeed: ast2500: Rename clock header

[Ryan Chen]

Rename the ast2500-scu.h to aspeed-clock.h.

Signed-off-by: Ryan Chen 
---
 arch/arm/dts/ast2500-u-boot.dtsi| 2 +-
 arch/arm/mach-aspeed/ast2500/sdram_ast2500.c| 2 +-
 drivers/clk/aspeed/clk_ast2500.c| 2 +-
 include/dt-bindings/clock/{ast2500-scu.h => aspeed-clock.h} | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename include/dt-bindings/clock/{ast2500-scu.h => aspeed-clock.h} (100%)

diff --git a/arch/arm/dts/ast2500-u-boot.dtsi b/arch/arm/dts/ast2500-u-boot.dtsi
index 8ac4215745..3b119e4ace 100644
--- a/arch/arm/dts/ast2500-u-boot.dtsi
+++ b/arch/arm/dts/ast2500-u-boot.dtsi
@@ -1,4 +1,4 @@
-#include 
+#include 
 #include 
 
 #include "ast2500.dtsi"
diff --git a/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c 
b/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
index a3adaa8a99..8536a70a19 100644
--- a/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
+++ b/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /* These configuration parameters are taken from Aspeed SDK */
 #define DDR4_MR46_MODE 0x0800
diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index d1940f1884..392fe76b27 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/include/dt-bindings/clock/ast2500-scu.h 
b/include/dt-bindings/clock/aspeed-clock.h
similarity index 100%
rename from include/dt-bindings/clock/ast2500-scu.h
rename to include/dt-bindings/clock/aspeed-clock.h
-- 
2.17.1

[PATCH v2 2/3] clock:aspeed: Sync with Linux kernel clock header define

[Ryan Chen]

v2: modify title description aspeed:clock -> clock:aspeed

Use kernel include/dt-bindings/clock/aspeed-clock.h define
for clock driver.

Signed-off-by: Ryan Chen 
---
 arch/arm/dts/ast2500-u-boot.dtsi | 20 +++
 drivers/clk/aspeed/clk_ast2500.c | 38 +++--
 include/dt-bindings/clock/aspeed-clock.h | 68 ++--
 3 files changed, 68 insertions(+), 58 deletions(-)

diff --git a/arch/arm/dts/ast2500-u-boot.dtsi b/arch/arm/dts/ast2500-u-boot.dtsi
index 3b119e4ace..29b08f16ac 100644
--- a/arch/arm/dts/ast2500-u-boot.dtsi
+++ b/arch/arm/dts/ast2500-u-boot.dtsi
@@ -25,7 +25,7 @@
reg = <0x1e6e 0x174
0x1e6e0200 0x1d4 >;
#reset-cells = <1>;
-   clocks = < PLL_MPLL>;
+   clocks = < ASPEED_CLK_MPLL>;
resets = < AST_RESET_SDRAM>;
};
 
@@ -39,7 +39,7 @@
compatible = "aspeed,ast2500-sdhci";
reg = <0x1e740100>;
#reset-cells = <1>;
-   clocks = < BCLK_SDCLK>;
+   clocks = < ASPEED_CLK_SDIO>;
resets = < AST_RESET_SDIO>;
};
 
@@ -47,7 +47,7 @@
compatible = "aspeed,ast2500-sdhci";
reg = <0x1e740200>;
#reset-cells = <1>;
-   clocks = < BCLK_SDCLK>;
+   clocks = < ASPEED_CLK_SDIO>;
resets = < AST_RESET_SDIO>;
};
};
@@ -56,23 +56,23 @@
 };
 
  {
-   clocks = < PCLK_UART1>;
+   clocks = < ASPEED_CLK_GATE_UART1CLK>;
 };
 
  {
-   clocks = < PCLK_UART2>;
+   clocks = < ASPEED_CLK_GATE_UART2CLK>;
 };
 
  {
-   clocks = < PCLK_UART3>;
+   clocks = < ASPEED_CLK_GATE_UART3CLK>;
 };
 
  {
-   clocks = < PCLK_UART4>;
+   clocks = < ASPEED_CLK_GATE_UART4CLK>;
 };
 
  {
-   clocks = < PCLK_UART5>;
+   clocks = < ASPEED_CLK_GATE_UART5CLK>;
 };
 
  {
@@ -80,9 +80,9 @@
 };
 
  {
-   clocks = < PCLK_MAC1>, < PLL_D2PLL>;
+   clocks = < ASPEED_CLK_GATE_MAC1CLK>, < ASPEED_CLK_D2PLL>;
 };
 
  {
-   clocks = < PCLK_MAC2>, < PLL_D2PLL>;
+   clocks = < ASPEED_CLK_GATE_MAC1CLK>, < ASPEED_CLK_D2PLL>;
 };
diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index 392fe76b27..aab7d14deb 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -122,8 +122,7 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
ulong rate;
 
switch (clk->id) {
-   case PLL_HPLL:
-   case ARMCLK:
+   case ASPEED_CLK_HPLL:
/*
 * This ignores dynamic/static slowdown of ARMCLK and may
 * be inaccurate.
@@ -131,11 +130,11 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
rate = ast2500_get_hpll_rate(clkin,
 readl(>scu->h_pll_param));
break;
-   case MCLK_DDR:
+   case ASPEED_CLK_MPLL:
rate = ast2500_get_mpll_rate(clkin,
 readl(>scu->m_pll_param));
break;
-   case BCLK_PCLK:
+   case ASPEED_CLK_APB:
{
ulong apb_div = 4 + 4 * ((readl(>scu->clk_sel1)
  & SCU_PCLK_DIV_MASK)
@@ -146,7 +145,7 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
rate = rate / apb_div;
}
break;
-   case BCLK_SDCLK:
+   case ASPEED_CLK_SDIO:
{
ulong apb_div = 4 + 4 * ((readl(>scu->clk_sel1)
  & SCU_SDCLK_DIV_MASK)
@@ -157,19 +156,19 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
rate = rate / apb_div;
}
break;
-   case PCLK_UART1:
+   case ASPEED_CLK_GATE_UART1CLK:
rate = ast2500_get_uart_clk_rate(priv->scu, 1);
break;
-   case PCLK_UART2:
+   case ASPEED_CLK_GATE_UART2CLK:
rate = ast2500_get_uart_clk_rate(priv->scu, 2);
break;
-   case PCLK_UART3:
+   case ASPEED_CLK_GATE_UART3CLK:
rate = ast2500_get_uart_clk_rate(priv->scu, 3);
break;
-   case PCLK_UART4:
+   case ASPEED_CLK_GATE_UART4CLK:
rate = ast2500_get_uart_clk_rate(priv->scu, 4);
break;
-   ca

RE: [PATCH 0/3] Rename ASPEED SoC clock name

[Ryan Chen]

> -Original Message-
> From: Cédric Le Goater 
> Sent: Saturday, August 29, 2020 4:46 PM
> To: Ryan Chen ; ChiaWei Wang
> ; BMC-SW ;
> lu...@denx.de; eaja...@linux.ibm.com; s...@chromium.org;
> u-boot@lists.denx.de; Joel Stanley 
> Subject: Re: [PATCH 0/3] Rename ASPEED SoC clock name
> 
> Hello Ryan,
> 
> On 8/28/20 9:32 AM, Ryan Chen wrote:
> > This patch series refactor the exiting ASPEED clock name define sync
> > with Linux kernel. And also add SPDX-License
> 
> All the patchset seems correct but the patch numbering is a bit confusing. I
> have received :
> 
>  [1/3] cosmetic: aspeed: ast2500: Rename clock header  [1/1] Remove not
> used export function header.
>  [2/3] aspeed:clock: Sync with Linux kernel clock header define  [3/3]
> cosmetic: aspeed: Modify for SPDX-License
> 
> Could you please merge the first two together maybe and resend ?
> 
> Thanks,
> 
> C.
> 
Thanks the review. I will resend it for v2. 

> > Ryan Chen (3):
> >   cosmetic: aspeed: ast2500: Rename clock header
> >   aspeed:clock: Sync with Linux kernel clock header define
> >   cosmetic: aspeed: Modify for SPDX-License
> >
> >  arch/arm/dts/ast2500-u-boot.dtsi | 23 ++-
> >  arch/arm/mach-aspeed/ast2500/sdram_ast2500.c |  2 +-
> >  drivers/clk/aspeed/clk_ast2500.c | 40 +--
> >  include/dt-bindings/clock/aspeed-clock.h | 42
> 
> >  include/dt-bindings/clock/ast2500-scu.h  | 30 --
> >  5 files changed, 74 insertions(+), 63 deletions(-)  create mode
> > 100644 include/dt-bindings/clock/aspeed-clock.h
> >  delete mode 100644 include/dt-bindings/clock/ast2500-scu.h
> >

[PATCH 2/3] aspeed:clock: Sync with Linux kernel clock header define

[Ryan Chen]

Use kernel include/dt-bindings/clock/aspeed-clock.h define
for clock driver.

Signed-off-by: Ryan Chen 
---
 arch/arm/dts/ast2500-u-boot.dtsi | 20 +++
 drivers/clk/aspeed/clk_ast2500.c | 38 +++--
 include/dt-bindings/clock/aspeed-clock.h | 68 ++--
 3 files changed, 68 insertions(+), 58 deletions(-)

diff --git a/arch/arm/dts/ast2500-u-boot.dtsi b/arch/arm/dts/ast2500-u-boot.dtsi
index 3b119e4ace..29b08f16ac 100644
--- a/arch/arm/dts/ast2500-u-boot.dtsi
+++ b/arch/arm/dts/ast2500-u-boot.dtsi
@@ -25,7 +25,7 @@
reg = <0x1e6e 0x174
0x1e6e0200 0x1d4 >;
#reset-cells = <1>;
-   clocks = < PLL_MPLL>;
+   clocks = < ASPEED_CLK_MPLL>;
resets = < AST_RESET_SDRAM>;
};
 
@@ -39,7 +39,7 @@
compatible = "aspeed,ast2500-sdhci";
reg = <0x1e740100>;
#reset-cells = <1>;
-   clocks = < BCLK_SDCLK>;
+   clocks = < ASPEED_CLK_SDIO>;
resets = < AST_RESET_SDIO>;
};
 
@@ -47,7 +47,7 @@
compatible = "aspeed,ast2500-sdhci";
reg = <0x1e740200>;
#reset-cells = <1>;
-   clocks = < BCLK_SDCLK>;
+   clocks = < ASPEED_CLK_SDIO>;
resets = < AST_RESET_SDIO>;
};
};
@@ -56,23 +56,23 @@
 };
 
  {
-   clocks = < PCLK_UART1>;
+   clocks = < ASPEED_CLK_GATE_UART1CLK>;
 };
 
  {
-   clocks = < PCLK_UART2>;
+   clocks = < ASPEED_CLK_GATE_UART2CLK>;
 };
 
  {
-   clocks = < PCLK_UART3>;
+   clocks = < ASPEED_CLK_GATE_UART3CLK>;
 };
 
  {
-   clocks = < PCLK_UART4>;
+   clocks = < ASPEED_CLK_GATE_UART4CLK>;
 };
 
  {
-   clocks = < PCLK_UART5>;
+   clocks = < ASPEED_CLK_GATE_UART5CLK>;
 };
 
  {
@@ -80,9 +80,9 @@
 };
 
  {
-   clocks = < PCLK_MAC1>, < PLL_D2PLL>;
+   clocks = < ASPEED_CLK_GATE_MAC1CLK>, < ASPEED_CLK_D2PLL>;
 };
 
  {
-   clocks = < PCLK_MAC2>, < PLL_D2PLL>;
+   clocks = < ASPEED_CLK_GATE_MAC1CLK>, < ASPEED_CLK_D2PLL>;
 };
diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index 392fe76b27..aab7d14deb 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -122,8 +122,7 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
ulong rate;
 
switch (clk->id) {
-   case PLL_HPLL:
-   case ARMCLK:
+   case ASPEED_CLK_HPLL:
/*
 * This ignores dynamic/static slowdown of ARMCLK and may
 * be inaccurate.
@@ -131,11 +130,11 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
rate = ast2500_get_hpll_rate(clkin,
 readl(>scu->h_pll_param));
break;
-   case MCLK_DDR:
+   case ASPEED_CLK_MPLL:
rate = ast2500_get_mpll_rate(clkin,
 readl(>scu->m_pll_param));
break;
-   case BCLK_PCLK:
+   case ASPEED_CLK_APB:
{
ulong apb_div = 4 + 4 * ((readl(>scu->clk_sel1)
  & SCU_PCLK_DIV_MASK)
@@ -146,7 +145,7 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
rate = rate / apb_div;
}
break;
-   case BCLK_SDCLK:
+   case ASPEED_CLK_SDIO:
{
ulong apb_div = 4 + 4 * ((readl(>scu->clk_sel1)
  & SCU_SDCLK_DIV_MASK)
@@ -157,19 +156,19 @@ static ulong ast2500_clk_get_rate(struct clk *clk)
rate = rate / apb_div;
}
break;
-   case PCLK_UART1:
+   case ASPEED_CLK_GATE_UART1CLK:
rate = ast2500_get_uart_clk_rate(priv->scu, 1);
break;
-   case PCLK_UART2:
+   case ASPEED_CLK_GATE_UART2CLK:
rate = ast2500_get_uart_clk_rate(priv->scu, 2);
break;
-   case PCLK_UART3:
+   case ASPEED_CLK_GATE_UART3CLK:
rate = ast2500_get_uart_clk_rate(priv->scu, 3);
break;
-   case PCLK_UART4:
+   case ASPEED_CLK_GATE_UART4CLK:
rate = ast2500_get_uart_clk_rate(priv->scu, 4);
break;
-   case PCLK_UART5:
+   case ASPEED_CLK_GATE_UART5CLK:

[PATCH 3/3] cosmetic: aspeed: Modify for SPDX-License

[Ryan Chen]

Modify SPDX-License for furture patch warning

Signed-off-by: Ryan Chen 
---
 arch/arm/dts/ast2500-u-boot.dtsi | 1 +
 include/dt-bindings/clock/aspeed-clock.h | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/ast2500-u-boot.dtsi b/arch/arm/dts/ast2500-u-boot.dtsi
index 29b08f16ac..51a5244766 100644
--- a/arch/arm/dts/ast2500-u-boot.dtsi
+++ b/arch/arm/dts/ast2500-u-boot.dtsi
@@ -1,3 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
 #include 
 #include 
 
diff --git a/include/dt-bindings/clock/aspeed-clock.h 
b/include/dt-bindings/clock/aspeed-clock.h
index e6599deeb9..a1aa8c07ce 100644
--- a/include/dt-bindings/clock/aspeed-clock.h
+++ b/include/dt-bindings/clock/aspeed-clock.h
@@ -1,4 +1,4 @@
-/* SPDX-License-Identifier: GPL-2.0+ */
+// SPDX-License-Identifier: GPL-2.0
 
 #define ASPEED_CLK_GATE_ECLK   0
 #define ASPEED_CLK_GATE_GCLK   1
-- 
2.17.1

[PATCH 1/3] cosmetic: aspeed: ast2500: Rename clock header

[Ryan Chen]

Rename the ast2500-scu.h to aspeed-clock.h.

Signed-off-by: Ryan Chen 
---
 arch/arm/dts/ast2500-u-boot.dtsi| 2 +-
 arch/arm/mach-aspeed/ast2500/sdram_ast2500.c| 2 +-
 drivers/clk/aspeed/clk_ast2500.c| 2 +-
 include/dt-bindings/clock/{ast2500-scu.h => aspeed-clock.h} | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename include/dt-bindings/clock/{ast2500-scu.h => aspeed-clock.h} (100%)

diff --git a/arch/arm/dts/ast2500-u-boot.dtsi b/arch/arm/dts/ast2500-u-boot.dtsi
index 8ac4215745..3b119e4ace 100644
--- a/arch/arm/dts/ast2500-u-boot.dtsi
+++ b/arch/arm/dts/ast2500-u-boot.dtsi
@@ -1,4 +1,4 @@
-#include 
+#include 
 #include 
 
 #include "ast2500.dtsi"
diff --git a/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c 
b/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
index a3adaa8a99..8536a70a19 100644
--- a/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
+++ b/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /* These configuration parameters are taken from Aspeed SDK */
 #define DDR4_MR46_MODE 0x0800
diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index d1940f1884..392fe76b27 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/include/dt-bindings/clock/ast2500-scu.h 
b/include/dt-bindings/clock/aspeed-clock.h
similarity index 100%
rename from include/dt-bindings/clock/ast2500-scu.h
rename to include/dt-bindings/clock/aspeed-clock.h
-- 
2.17.1

[PATCH 0/3] Rename ASPEED SoC clock name

[Ryan Chen]

This patch series refactor the exiting ASPEED clock name define sync
with Linux kernel. And also add SPDX-License

Ryan Chen (3):
  cosmetic: aspeed: ast2500: Rename clock header
  aspeed:clock: Sync with Linux kernel clock header define
  cosmetic: aspeed: Modify for SPDX-License

 arch/arm/dts/ast2500-u-boot.dtsi | 23 ++-
 arch/arm/mach-aspeed/ast2500/sdram_ast2500.c |  2 +-
 drivers/clk/aspeed/clk_ast2500.c | 40 +--
 include/dt-bindings/clock/aspeed-clock.h | 42 
 include/dt-bindings/clock/ast2500-scu.h  | 30 --
 5 files changed, 74 insertions(+), 63 deletions(-)
 create mode 100644 include/dt-bindings/clock/aspeed-clock.h
 delete mode 100644 include/dt-bindings/clock/ast2500-scu.h

-- 
2.17.1

[PATCH 1/1] Remove not used export function header.

[Ryan Chen]

All driver is use clk dm model, will not use this function call.

Signed-off-by: Ryan Chen 
---
 arch/arm/dts/ast2500-u-boot.dtsi| 2 +-
 arch/arm/mach-aspeed/ast2500/sdram_ast2500.c| 2 +-
 drivers/clk/aspeed/clk_ast2500.c| 2 +-
 include/dt-bindings/clock/{ast2500-scu.h => aspeed-clock.h} | 0
 4 files changed, 3 insertions(+), 3 deletions(-)
 rename include/dt-bindings/clock/{ast2500-scu.h => aspeed-clock.h} (100%)

diff --git a/arch/arm/dts/ast2500-u-boot.dtsi b/arch/arm/dts/ast2500-u-boot.dtsi
index 8ac4215745..3b119e4ace 100644
--- a/arch/arm/dts/ast2500-u-boot.dtsi
+++ b/arch/arm/dts/ast2500-u-boot.dtsi
@@ -1,4 +1,4 @@
-#include 
+#include 
 #include 
 
 #include "ast2500.dtsi"
diff --git a/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c 
b/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
index a3adaa8a99..8536a70a19 100644
--- a/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
+++ b/arch/arm/mach-aspeed/ast2500/sdram_ast2500.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 /* These configuration parameters are taken from Aspeed SDK */
 #define DDR4_MR46_MODE 0x0800
diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index d1940f1884..392fe76b27 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -10,7 +10,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 
diff --git a/include/dt-bindings/clock/ast2500-scu.h 
b/include/dt-bindings/clock/aspeed-clock.h
similarity index 100%
rename from include/dt-bindings/clock/ast2500-scu.h
rename to include/dt-bindings/clock/aspeed-clock.h
-- 
2.17.1

RE: [PATCH] arm: dts: fix ast2500-evb inclusion for correct target

[Ryan Chen]

Hi
> -Original Message-
> From: Thirupathaiah Annapureddy [mailto:thir...@linux.microsoft.com]
> Sent: Thursday, August 20, 2020 8:16 AM
> To: u-boot@lists.denx.de
> Cc: Maxim Sloyko ; Marek Vasut ;
> ChiaWei Wang ; Ryan Chen
> 
> Subject: Re: [PATCH] arm: dts: fix ast2500-evb inclusion for correct target
> 
> Adding Ryan and Chiawei to the list.
> 
> On 8/17/2020 5:53 PM, Thirupathaiah Annapureddy wrote:
> > Include ast2500-evb.dtb for CONFIG_TARGET_EVB_AST2500 instead of for
> > all aspeed targets.

There should not have to many Kconfig for ASPEED platform. 
I prefer use following to build all all ASPEED platform. Like following. 
dtb-$(CONFIG_ARCH_ASPEED) += \
ast2400-evb.dtb \
ast2500-evb.dtb \
ast2600a0-evb.dtb \
ast2600a0-ncsi.dtb \
ast2600a1-evb.dtb \
ast2600a1-ncsi.dtb \
ast2600-fpga.dtb \
ast2600-rainier.dtb \
ast2600-slt.dtb \
ast2600-tacoma.dtb
 
> >
> > Signed-off-by: Thirupathaiah Annapureddy  > ---
> >  arch/arm/dts/Makefile | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> > 7e29b9096b..d019f26983 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -938,7 +938,7 @@ dtb-$(CONFIG_ARCH_BCM6858) += \
> >
> >  dtb-$(CONFIG_TARGET_BCMNS3) += ns3-board.dtb
> >
> > -dtb-$(CONFIG_ARCH_ASPEED) += ast2500-evb.dtb
> > +dtb-$(CONFIG_TARGET_EVB_AST2500) += ast2500-evb.dtb
> >
> >  dtb-$(CONFIG_ARCH_STI) += stih410-b2260.dtb
> >
> >

Re: [PATCH] fvp: Add support for loading Android boot images via semihosting

[Ryan Harkin]

On Mon, 6 Apr 2020 at 19:25, Peter Collingbourne  wrote:

> On Mon, Apr 6, 2020 at 10:40 AM Ryan Harkin 
> wrote:
>
>> Hi Peter,
>>
>> This looks good to me, but I have a quick question below.
>>
>> On Sat, 4 Apr 2020 at 03:58, Peter Collingbourne  wrote:
>>
>>> FVP now loads an Android boot image named boot.img if available,
>>> otherwise it falls back to the existing code path.
>>>
>>> Signed-off-by: Peter Collingbourne 
>>> ---
>>>  configs/vexpress_aemv8a_semi_defconfig |  2 ++
>>>  include/configs/vexpress_aemv8a.h  | 30 +-
>>>  2 files changed, 22 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/configs/vexpress_aemv8a_semi_defconfig
>>> b/configs/vexpress_aemv8a_semi_defconfig
>>> index f31baab197..b52c761dee 100644
>>> --- a/configs/vexpress_aemv8a_semi_defconfig
>>> +++ b/configs/vexpress_aemv8a_semi_defconfig
>>> @@ -14,6 +14,8 @@ CONFIG_BOOTARGS="console=ttyAMA0
>>> earlycon=pl011,0x1c09 debug user_debug=31 l
>>>  # CONFIG_DISPLAY_CPUINFO is not set
>>>  # CONFIG_DISPLAY_BOARDINFO is not set
>>>  CONFIG_SYS_PROMPT="VExpress64# "
>>> +CONFIG_ANDROID_BOOT_IMAGE=y
>>> +CONFIG_CMD_ABOOTIMG=y
>>>  # CONFIG_CMD_CONSOLE is not set
>>>  # CONFIG_CMD_XIMG is not set
>>>  # CONFIG_CMD_EDITENV is not set
>>> diff --git a/include/configs/vexpress_aemv8a.h
>>> b/include/configs/vexpress_aemv8a.h
>>> index 9a9cec414c..4f3a792f49 100644
>>> --- a/include/configs/vexpress_aemv8a.h
>>> +++ b/include/configs/vexpress_aemv8a.h
>>> @@ -177,16 +177,26 @@
>>> "initrd_addr=0x8800\0"  \
>>> "fdtfile=devtree.dtb\0" \
>>> "fdt_addr=0x8300\0" \
>>> -   "fdt_high=0x\0" \
>>> -   "initrd_high=0x\0"
>>>
>>
>> Why did you move these two inside the 'if' statement below? Is it because
>> you explicitly don't want them set when booting Android?
>>
>
> Yes. We can't have these set when loading an Android boot image because
> they instruct the bootloader to use the device tree/initrd in place instead
> of copying them to another location, and since we're already using the
> kernel in place this may result in the kernel overwriting the device tree
> or initrd when it initializes its own BSS since they appear right after the
> kernel in the boot image format.
>

Ok, thanks for the clarification. That's fine by me.

Reviewed-by: Ryan Harkin 


>
> Peter
>
>>
>>
>>
>>> -
>>> -#define CONFIG_BOOTCOMMAND "smhload ${kernel_name} ${kernel_addr};
>>> " \
>>> -   "smhload ${fdtfile} ${fdt_addr}; " \
>>> -   "smhload ${initrd_name} ${initrd_addr} "\
>>> -   "initrd_end; " \
>>> -   "fdt addr ${fdt_addr}; fdt resize; " \
>>> -   "fdt chosen ${initrd_addr}
>>> ${initrd_end}; " \
>>> -   "booti $kernel_addr - $fdt_addr"
>>> +   "boot_name=boot.img\0"  \
>>> +   "boot_addr=0x8007f800\0"
>>> +
>>> +#define CONFIG_BOOTCOMMAND "if smhload ${boot_name} ${boot_addr};
>>> then " \
>>> +   "  set bootargs; " \
>>> +   "  abootimg addr ${boot_addr}; " \
>>> +   "  abootimg get dtb --index=0 fdt_addr;
>>> " \
>>> +   "  bootm ${boot_addr} ${boot_addr} " \
>>> +   "  ${fdt_addr}; " \
>>> +   "else; " \
>>> +   "  set fdt_high 0x; " \
>>> +   "  set initrd_high 0x; "
>>> \
>>> +   "  smhload ${kernel_name}
>>> ${kernel_addr}; " \
>>> +   "  smhload ${fdtfile} ${fdt_addr}; " \
>>> +   "  smhload ${initrd_name} ${initrd_addr}
>>> "\
>>> +   "  initrd_end; " \
>>> +   "  fdt addr ${fdt_addr}; fdt resize; " \
>>> +   "  fdt chosen ${initrd_addr}
>>> ${initrd_end}; " \
>>> +   "  booti $kernel_addr - $fdt_addr; " \
>>> +   "fi"
>>>
>>>
>>>  #endif
>>> --
>>> 2.26.0.292.g33ef6b2f38-goog
>>>
>>>

[U-Boot] Error when replacing SPI NOR Flash IC

[RUSSELL Ryan]

Hello All,

We are currently having issues with a product after we replaced an obsolete SPI 
Flash IC with what we thought was a drop-in replacement part. Unfortunately we 
had this product designed by a third part company so I don't have all of the 
important details but I will try to get any additional information needed.

Our current circuit uses a ADSP-BF609BBCZ-5 Blackfin. We are using a NOR SPI 
Flash to boot the Blackfin. Initially in our design we used a N25Q128A13ESE40 
flash from Micron but when it became obsolete we switched to S25FL127SABMFI101 
from Cypress. The Cypress part appeared to be functional but after 6 weeks in 
the field we are seeing a high level of failures due to this part. As far as we 
can tell there are no environmental differences between products that have each 
part but products that contain the Cypress part are failing. When we take off 
the 'broken' part and replace it the board becomes functional again.

Is there something different about these parts that require a slightly 
different u-boot configuration that could cause the Flash to function initially 
but later become corrupt?

Best Regards,
Ryan J. Russell
Hardware Designer
Alstom Signaling



CONFIDENTIALITY : This e-mail and any attachments are confidential and may be 
privileged. If you are not a named recipient, please notify the sender 
immediately and do not disclose the contents to another person, use it for any 
purpose or store or copy the information in any medium.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Revert "vexpress64: fvp dram: add DRAM configuration"

[Ryan Harkin]

This reverts commit fc04b923541d984b1544056fd3bfa8129d4e5aac where the
FVP DRAM configuration was added.

Signed-off-by: Ryan Harkin 
---
 arch/arm/Kconfig   | 10 ---
 board/armltd/vexpress64/Kconfig|  2 +-
 board/armltd/vexpress64/MAINTAINERS|  5 
 configs/vexpress_aemv8a_dram_defconfig | 39 --
 include/configs/vexpress_aemv8a.h  | 17 ++-
 5 files changed, 3 insertions(+), 70 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index cbb2a2a158..12d5d0fef6 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1066,16 +1066,6 @@ config TARGET_VEXPRESS64_BASE_FVP
select PL01X_SERIAL
select SEMIHOSTING
 
-config TARGET_VEXPRESS64_BASE_FVP_DRAM
-   bool "Support Versatile Express ARMv8a FVP BASE model booting from DRAM"
-   select ARM64
-   select PL01X_SERIAL
-   help
- This target is derived from TARGET_VEXPRESS64_BASE_FVP and over-rides
- the default config to allow the user to load the images directly into
- DRAM using model parameters rather than by using semi-hosting to load
- the files from the host filesystem.
-
 config TARGET_VEXPRESS64_JUNO
bool "Support Versatile Express Juno Development Platform"
select ARM64
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig
index e05f353b80..9014418433 100644
--- a/board/armltd/vexpress64/Kconfig
+++ b/board/armltd/vexpress64/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || 
TARGET_VEXPRESS64_BASE_FVP_DRAM
+if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO
 
 config SYS_BOARD
default "vexpress64"
diff --git a/board/armltd/vexpress64/MAINTAINERS 
b/board/armltd/vexpress64/MAINTAINERS
index 15b0a08646..0ba044d7ff 100644
--- a/board/armltd/vexpress64/MAINTAINERS
+++ b/board/armltd/vexpress64/MAINTAINERS
@@ -10,11 +10,6 @@ M:   Linus Walleij 
 S: Maintained
 F: configs/vexpress_aemv8a_semi_defconfig
 
-VEXPRESS_AEMV8A_DRAM BOARD
-M: Ryan Harkin 
-S: Maintained
-F: configs/vexpress_aemv8a_dram_defconfig
-
 JUNO DEVELOPMENT PLATFORM BOARD
 M: Linus Walleij 
 S: Maintained
diff --git a/configs/vexpress_aemv8a_dram_defconfig 
b/configs/vexpress_aemv8a_dram_defconfig
deleted file mode 100644
index 51860da387..00
--- a/configs/vexpress_aemv8a_dram_defconfig
+++ /dev/null
@@ -1,39 +0,0 @@
-CONFIG_ARM=y
-CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM=y
-CONFIG_SYS_TEXT_BASE=0x8800
-CONFIG_SYS_MALLOC_F_LEN=0x2000
-CONFIG_NR_DRAM_BANKS=1
-CONFIG_IDENT_STRING=" vexpress_aemv8a"
-CONFIG_DISTRO_DEFAULTS=y
-CONFIG_BOOTDELAY=1
-CONFIG_USE_BOOTARGS=y
-CONFIG_BOOTARGS="console=ttyAMA0 earlycon=pl011,0x1c09 debug user_debug=31 
androidboot.hardware=fvpbase root=/dev/vda2 rw rootwait loglevel=9"
-# CONFIG_USE_BOOTCOMMAND is not set
-# CONFIG_DISPLAY_CPUINFO is not set
-# CONFIG_DISPLAY_BOARDINFO is not set
-CONFIG_SYS_PROMPT="VExpress64# "
-# CONFIG_CMD_CONSOLE is not set
-# CONFIG_CMD_XIMG is not set
-# CONFIG_CMD_EDITENV is not set
-CONFIG_CMD_MEMTEST=y
-CONFIG_CMD_ARMFLASH=y
-# CONFIG_CMD_LOADS is not set
-# CONFIG_CMD_ITEST is not set
-# CONFIG_CMD_SETEXPR is not set
-# CONFIG_CMD_NFS is not set
-CONFIG_CMD_CACHE=y
-# CONFIG_CMD_MISC is not set
-CONFIG_CMD_UBI=y
-# CONFIG_ISO_PARTITION is not set
-# CONFIG_EFI_PARTITION is not set
-CONFIG_ENV_IS_IN_FLASH=y
-CONFIG_DM=y
-# CONFIG_MMC is not set
-CONFIG_MTD_NOR_FLASH=y
-CONFIG_MTD_DEVICE=y
-CONFIG_FLASH_CFI_DRIVER=y
-CONFIG_SYS_FLASH_USE_BUFFER_WRITE=y
-CONFIG_SYS_FLASH_PROTECTION=y
-CONFIG_SYS_FLASH_CFI=y
-CONFIG_DM_SERIAL=y
-CONFIG_OF_LIBFDT=y
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index 9746470552..b2c14f9e10 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -16,8 +16,7 @@
 #define CONFIG_REMAKE_ELF
 
 /* Link Definitions */
-#if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) || \
-   defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM)
+#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
 /* ATF loads u-boot here for BASE_FVP model */
 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f0)
 #elif CONFIG_TARGET_VEXPRESS64_JUNO
@@ -83,8 +82,7 @@
 #define GICR_BASE  (0x2f10)
 #else
 
-#if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) || \
-   defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM)
+#ifdef CONFIG_TARGET_VEXPRESS64_BASE_FVP
 #define GICD_BASE  (0x2f00)
 #define GICC_BASE  (0x2c00)
 #elif CONFIG_TARGET_VEXPRESS64_JUNO
@@ -191,17 +189,6 @@
"booti $kernel_addr - $fdt_addr"
 
 
-#elif CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM
-#define CONFIG_EXTRA_ENV_SETTINGS  \
-   "kernel_addr=0x8008\0"  \
-   "in

Re: [U-Boot] [PATCH] ARM: vexpress_*_defconfig: replace earlyprintk with earlycon

[Ryan Harkin]

On Thu, 22 Aug 2019 at 13:10, Sudeep Holla  wrote:

> On Thu, Aug 22, 2019 at 12:38:31PM +0100, Ryan Harkin wrote:
> > On Thu, 22 Aug 2019 at 02:25, Peng Fan  wrote:
> >
> > > > Subject: [U-Boot] [PATCH] ARM: vexpress_*_defconfig: replace
> earlyprintk
> > > > with earlycon
> > > >
> > > > earlyprintk no longer works on arm64 platforms. Replace it with
> earlycon
> > > > which works fine.
> > > >
> > > > Cc: Ryan Harkin 
> > > > Cc: Liviu Dudau 
> > > > Cc: Linus Walleij 
> > > > Signed-off-by: Sudeep Holla 
> > > > ---
> > > >  configs/vexpress_aemv8a_dram_defconfig | 2 +-
> > > > configs/vexpress_aemv8a_juno_defconfig | 2 +-
> > > > configs/vexpress_aemv8a_semi_defconfig | 2 +-
> > > >  3 files changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/configs/vexpress_aemv8a_dram_defconfig
> > > > b/configs/vexpress_aemv8a_dram_defconfig
> > > > index 2ff9e4b9f291..51860da387da 100644
> > > > --- a/configs/vexpress_aemv8a_dram_defconfig
> > > > +++ b/configs/vexpress_aemv8a_dram_defconfig
> > > > @@ -7,7 +7,7 @@ CONFIG_IDENT_STRING=" vexpress_aemv8a"
> > > >  CONFIG_DISTRO_DEFAULTS=y
> > > >  CONFIG_BOOTDELAY=1
> > > >  CONFIG_USE_BOOTARGS=y
> > > > -CONFIG_BOOTARGS="console=ttyAMA0 earlyprintk=pl011,0x1c09
> > > > debug user_debug=31 androidboot.hardware=fvpbase root=/dev/vda2 rw
> > > > rootwait loglevel=9"
> > > > +CONFIG_BOOTARGS="console=ttyAMA0 earlycon=pl011,0x1c09 debug
> > > > user_debug=31 androidboot.hardware=fvpbase root=/dev/vda2 rw rootwait
> > > > loglevel=9"
> > > >  # CONFIG_USE_BOOTCOMMAND is not set
> > > >  # CONFIG_DISPLAY_CPUINFO is not set
> > > >  # CONFIG_DISPLAY_BOARDINFO is not set
> > > > diff --git a/configs/vexpress_aemv8a_juno_defconfig
> > > > b/configs/vexpress_aemv8a_juno_defconfig
> > > > index fd306f9f6bf0..0823d17c1158 100644
> > > > --- a/configs/vexpress_aemv8a_juno_defconfig
> > > > +++ b/configs/vexpress_aemv8a_juno_defconfig
> > > > @@ -7,7 +7,7 @@ CONFIG_IDENT_STRING=" vexpress_aemv8a"
> > > >  CONFIG_DISTRO_DEFAULTS=y
> > > >  CONFIG_BOOTDELAY=1
> > > >  CONFIG_USE_BOOTARGS=y
> > > > -CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/sda2 rw
> > > > rootwait earlyprintk=pl011,0x7ff8 debug user_debug=31
> > > > androidboot.hardware=juno loglevel=9"
> > > > +CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/sda2 rw
> > > > rootwait earlycon=pl011,0x7ff8 debug user_debug=31
> > > > androidboot.hardware=juno loglevel=9"
> > > >  # CONFIG_USE_BOOTCOMMAND is not set
> > > >  # CONFIG_DISPLAY_CPUINFO is not set
> > > >  # CONFIG_DISPLAY_BOARDINFO is not set
> > > > diff --git a/configs/vexpress_aemv8a_semi_defconfig
> > > > b/configs/vexpress_aemv8a_semi_defconfig
> > > > index bff52f703836..db5ad3dfa5a4 100644
> > > > --- a/configs/vexpress_aemv8a_semi_defconfig
> > > > +++ b/configs/vexpress_aemv8a_semi_defconfig
> > > > @@ -7,7 +7,7 @@ CONFIG_IDENT_STRING=" vexpress_aemv8a"
> > > >  CONFIG_DISTRO_DEFAULTS=y
> > > >  CONFIG_BOOTDELAY=1
> > > >  CONFIG_USE_BOOTARGS=y
> > > > -CONFIG_BOOTARGS="console=ttyAMA0 earlyprintk=pl011,0x1c09
> > > > debug user_debug=31 loglevel=9"
> > > > +CONFIG_BOOTARGS="console=ttyAMA0 earlycon=pl011,0x1c09 debug
> > > > user_debug=31 loglevel=9"
> > > >  # CONFIG_USE_BOOTCOMMAND is not set
> > > >  # CONFIG_DISPLAY_CPUINFO is not set
> > > >  # CONFIG_DISPLAY_BOARDINFO is not set
> > >
> > > Reviewed-by: Peng Fan 
> > >
> > Reviewed-by: Ryan Harkin 
> >
> > >
> > > Nitpick: this will be no early print when booting older version kernel.
> > >
> >
> > Note also that the -dram platform is no longer used or tested. I'll send
> a
> > patch to remove it.
> >
>
> Ah OK, I was about to try that on FVP but then saw -semihosting one.
> Thanks for the review. I assume you will post on top of my patch or do
> you need me to drop changes in -dram defconfig and post v2 ?
>

It's OK, go ahead with your patch and I'll send mine after it's merged.


>
> --
> Regards,
> Sudeep
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: vexpress_*_defconfig: replace earlyprintk with earlycon

[Ryan Harkin]

On Thu, 22 Aug 2019 at 02:25, Peng Fan  wrote:

> > Subject: [U-Boot] [PATCH] ARM: vexpress_*_defconfig: replace earlyprintk
> > with earlycon
> >
> > earlyprintk no longer works on arm64 platforms. Replace it with earlycon
> > which works fine.
> >
> > Cc: Ryan Harkin 
> > Cc: Liviu Dudau 
> > Cc: Linus Walleij 
> > Signed-off-by: Sudeep Holla 
> > ---
> >  configs/vexpress_aemv8a_dram_defconfig | 2 +-
> > configs/vexpress_aemv8a_juno_defconfig | 2 +-
> > configs/vexpress_aemv8a_semi_defconfig | 2 +-
> >  3 files changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/configs/vexpress_aemv8a_dram_defconfig
> > b/configs/vexpress_aemv8a_dram_defconfig
> > index 2ff9e4b9f291..51860da387da 100644
> > --- a/configs/vexpress_aemv8a_dram_defconfig
> > +++ b/configs/vexpress_aemv8a_dram_defconfig
> > @@ -7,7 +7,7 @@ CONFIG_IDENT_STRING=" vexpress_aemv8a"
> >  CONFIG_DISTRO_DEFAULTS=y
> >  CONFIG_BOOTDELAY=1
> >  CONFIG_USE_BOOTARGS=y
> > -CONFIG_BOOTARGS="console=ttyAMA0 earlyprintk=pl011,0x1c09
> > debug user_debug=31 androidboot.hardware=fvpbase root=/dev/vda2 rw
> > rootwait loglevel=9"
> > +CONFIG_BOOTARGS="console=ttyAMA0 earlycon=pl011,0x1c09 debug
> > user_debug=31 androidboot.hardware=fvpbase root=/dev/vda2 rw rootwait
> > loglevel=9"
> >  # CONFIG_USE_BOOTCOMMAND is not set
> >  # CONFIG_DISPLAY_CPUINFO is not set
> >  # CONFIG_DISPLAY_BOARDINFO is not set
> > diff --git a/configs/vexpress_aemv8a_juno_defconfig
> > b/configs/vexpress_aemv8a_juno_defconfig
> > index fd306f9f6bf0..0823d17c1158 100644
> > --- a/configs/vexpress_aemv8a_juno_defconfig
> > +++ b/configs/vexpress_aemv8a_juno_defconfig
> > @@ -7,7 +7,7 @@ CONFIG_IDENT_STRING=" vexpress_aemv8a"
> >  CONFIG_DISTRO_DEFAULTS=y
> >  CONFIG_BOOTDELAY=1
> >  CONFIG_USE_BOOTARGS=y
> > -CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/sda2 rw
> > rootwait earlyprintk=pl011,0x7ff8 debug user_debug=31
> > androidboot.hardware=juno loglevel=9"
> > +CONFIG_BOOTARGS="console=ttyAMA0,115200n8 root=/dev/sda2 rw
> > rootwait earlycon=pl011,0x7ff8 debug user_debug=31
> > androidboot.hardware=juno loglevel=9"
> >  # CONFIG_USE_BOOTCOMMAND is not set
> >  # CONFIG_DISPLAY_CPUINFO is not set
> >  # CONFIG_DISPLAY_BOARDINFO is not set
> > diff --git a/configs/vexpress_aemv8a_semi_defconfig
> > b/configs/vexpress_aemv8a_semi_defconfig
> > index bff52f703836..db5ad3dfa5a4 100644
> > --- a/configs/vexpress_aemv8a_semi_defconfig
> > +++ b/configs/vexpress_aemv8a_semi_defconfig
> > @@ -7,7 +7,7 @@ CONFIG_IDENT_STRING=" vexpress_aemv8a"
> >  CONFIG_DISTRO_DEFAULTS=y
> >  CONFIG_BOOTDELAY=1
> >  CONFIG_USE_BOOTARGS=y
> > -CONFIG_BOOTARGS="console=ttyAMA0 earlyprintk=pl011,0x1c09
> > debug user_debug=31 loglevel=9"
> > +CONFIG_BOOTARGS="console=ttyAMA0 earlycon=pl011,0x1c09 debug
> > user_debug=31 loglevel=9"
> >  # CONFIG_USE_BOOTCOMMAND is not set
> >  # CONFIG_DISPLAY_CPUINFO is not set
> >  # CONFIG_DISPLAY_BOARDINFO is not set
>
> Reviewed-by: Peng Fan 
>
Reviewed-by: Ryan Harkin 


>
> Nitpick: this will be no early print when booting older version kernel.
>

Note also that the -dram platform is no longer used or tested. I'll send a
patch to remove it.


> > --
> > 2.17.1
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> >
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.d
> > enx.de%2Flistinfo%2Fu-bootdata=02%7C01%7CPeng.Fan%40nxp.com
> > %7C527db1f88898493ad3a708d7265d2df8%7C686ea1d3bc2b4c6fa92cd99c5
> > c301635%7C0%7C0%7C637020053985296717sdata=eTWujuzFpTwWil
> > xc%2F7W7I7t8UQirTZ%2BE8MWkFGsdzrk%3Dreserved=0
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Booting Linux kernel on x86_64

[Ryan Wilkins]

> On Aug 12, 2019, at 9:05 PM, Bin Meng  wrote:
> 
> Did you enable CONFIG_FB_VESA in the kernel?
> 


I added that in today and it worked.  I had EFI FB support compiled in but I 
didn’t have FB VESA so this was preventing me to seeing any output on the 
screen which led me to believe that u-boot wasn’t booting my kernel.

Thank you very much, Bin and Andy, for your assistance with this.  I appreciate 
it.

Best,
Ryan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Booting Linux kernel on x86_64

[Ryan Wilkins]

> On Aug 10, 2019, at 8:42 AM, Andy Shevchenko  
> wrote:
> 
> You may try to enable 'earlyprintk=efi' (newer kernels have different
> approach, i.e. 'earlycon=efifb') and also add 'keep_bootcon' to see if
> the problem is at the beginning or ending stages of boot process.
> 
> 
> 
> -- 
> With Best Regards,
> Andy Shevchenko


Andy,

This worked for me and I was able to see that the kernel was booting but was 
unable to mount the rootfs.  It also told me that my framebuffer isn’t being 
initialized properly so I wasn’t seeing screen output.

Thanks much for the suggestions!

Ryan Wilkins
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Booting Linux kernel on x86_64

[Ryan Wilkins]

> On Aug 9, 2019, at 12:00 PM, Bin Meng  wrote:
> 
> +Simon, Andy,
> 
> Hi Ryan,
> 
>> On Fri, Aug 9, 2019 at 11:52 PM Ryan Wilkins  
>> wrote:
>> 
>> Hello,
>> 
>> I’m trying to get u-boot 2019.04 to execute the Linux 4.19.55 kernel from 
>> u-boot on a generic Core i5 with 8 GB RAM and having issues.  The kernel 
>> that I’m trying to boot will boot fine from GRUB so I know it works but 
>> starting from u-boot just shows “Starting kernel” and the system appears to 
>> freeze.
> 
> Which specific Core i5 processor are you using? And what's the U-Boot
> target for that board? Is that U-Boot as EFI payload or something? Did
> you set up U-Boot environment variable "bootargs" with Linux kernel's
> command line, e.g.: I think you need at least specify console=tty0 or
> ttyS0?

I’m using a Core i5-6500 on a Supermicro X11SSV-Q mainboard.
U-boot is compiled as an EFI 64-bit payload which came from the 
efi-x86_payload64_defconfig.  I disabled xHCI USB support because it was 
freezing on this board and preventing u-boot from doing anything else.
I was setting bootargs to “console=tty0” during a few of the boot tests but it 
didn’t seem to make any difference.



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Booting Linux kernel on x86_64

[Ryan Wilkins]

Hello,

I’m trying to get u-boot 2019.04 to execute the Linux 4.19.55 kernel from 
u-boot on a generic Core i5 with 8 GB RAM and having issues.  The kernel that 
I’m trying to boot will boot fine from GRUB so I know it works but starting 
from u-boot just shows “Starting kernel” and the system appears to freeze.

my bootcmd is
  scsi reset; ext2load scsi 0:5 0x0400 bzImage; ext2load scsi 0:5 
0x0800 rootfs.cpio.uboot; zboot 0400 0 0800 ${filesize}

The kernel bzip2 compressed file size is around 6 MB and the rootfs is about 
125 MB.
The kernel and rootfs are loaded in OK and running zboot finds the kernel OK.  
The rootfs is a gzip compressed cpio with uboot wrapper.  I’m using buildroot 
2019.02 to create the system and rootfs.

You might be asking why not just go with GRUB instead and the reason is the 
company I’m working for has a lot of ARM-based devices out that all utilize 
u-boot of which I’m quite familiar with, but this particular project is based 
on the Intel Core i5.  It was decided to keep the system as similar as possible 
to the ARM-based boards to keep support differences as minimal as possible.  A 
number of utilities that we have already written are meant to interact with the 
u-boot environment and depend on it.

I realize this is rather sparse with information, but rather than make an 
unnecessarily long email does anyone have any ideas of what to check or try or 
requests for more information?

Thanks in advance for any assistance.

Ryan Wilkins
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] Fix CAAM for TrustZone enable for warp7

[Ryan Harkin]

On 23 January 2018 at 21:10, Bryan O'Donoghue <bryan.odonog...@linaro.org>
wrote:

> This series is the u-boot fix to a problem we encountered when enabling
> OPTEE/TrustZone on the WaRP7. The symptom is once TrustZone is activated
> the first page of CAAM registers becomes read-only, read-zero from the
> perspective of Linux and other non TrustZone contexts.
>
> Offlining the problem with Peng Fan[1] we eventually came to realise the
> problem could be worked around by
>
> 1. Making Linux skip RNG initialisation - a set of patches should be
>hitting LKML to do just that.
>
> 2. Initialising the RNG either from u-boot or OPTEE. In this case u-boot is
>the right place to-do that because there's upstream code in u-boot that
>just works. Patch #2 does that for the WaRP7.
>
> 3. Ensuring the job-ring registers are assigned to the non TrustZone mode.
>On the i.MX7 after the BootROM runs the job-ring registers are assigned
>to TrustZone. Patch #1 does that for all CAAM hardware.
>
> On point #3 this ordinarily isn't a problem because unless TrustZone is
> activated the restrictions on the job-ring registers don't kick in, its
> only after enabling TrustZone that Linux will loose access to the job-ring
> registers.
>
> Finally should OPTEE or another TEE want to do things with the job-ring
> registers it will have sufficient privilege to assign whichever job-ring
> registers it wants to OPTEE/TEE but will naturally then have to arbitrate
> with Linux to inform the Kernel CAAM driver which job-ring registers it can
> and cannot access.
>
> That arbitration process is for a future putative OPTEE/TEE CAAM driver to
> solve and is out of scope of this patchset.
>
> [1] Thanks for all of your help BTW - Peng, there's no way this would be
> working without you giving direction on how.
>
> Bryan O'Donoghue (2):
>   drivers/crypto/fsl: assign job-rings to non-TrustZone
>   warp7 : run sec_init for CAAM RNG
>

This series:

Tested-by: Ryan Harkin <ryan.har...@linaro.org>


>
>  board/warp7/warp7.c | 6 +-
>  drivers/crypto/fsl/jr.c | 9 +
>  drivers/crypto/fsl/jr.h | 1 +
>  3 files changed, 15 insertions(+), 1 deletion(-)
>
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] serial: mxc: support DTE mode

[Ryan Harkin]

Hi Simon,

On 22 January 2018 at 00:29, Simon Glass <s...@chromium.org> wrote:

> Hi Ryan,
>
> On 19 January 2018 at 06:21, Ryan Harkin <ryan.har...@linaro.org> wrote:
> > Hi Stefan,
> >
> > Thanks for looking so quickly.
> >
> > On 19 January 2018 at 12:23, Stefan Agner <stefan.ag...@toradex.com>
> wrote:
> >>
> >> Hi Ryan,
> >>
> >>
> >> On 19.01.2018 10:53, Ryan Harkin wrote:
> >> > Add DTE mode support via Kconfig on the MXC uart.
> >>
> >> Make use of the driver model, there DTE is supported already today:
> >> https://lists.denx.de/pipermail/u-boot/2016-July/259573.html
> >
> >
> > My change would be useful for other non-DM users of serial_mxc.c, of
> course.
> > Not just WaRP7.
> >
> > I don't have any objection to WaRP7 moving to DM, although that isn't my
> > call, but moving using the driver model is not a straight-forward
> change, is
> > it? WaRP7 today doesn't use it.
>
> We are planning to require that board use CONFIG_BLK fairly soon, and
> that likely means conversion to device tree I don't think it makes
> sense to accept patches like this. If the board can be converted, then
> let's do it!
>

I'm not the maintainer of this board. I'm only making this patch so I can
put it into our test farm. But I'm interested in giving it a go. In fact, I
started already after Stefan's email. And bricked my board :-)


> >
> > Do you have an example of a board using this driver that switched using
> the
> > driver model? I'd like to see the scale of the changes needed.
>
> It probably requires:
>
> - Adding a DT (with u-boot,dm-pre-reloc as needed)
>

I take it we add the DT from the upstream linux kernel? The upstream DT
doesn't define UART6, the one I want to use. I have a patch for the kernel
that I have not attempted to send upstream yet.

What approach should I take?
- upstream my patch to the kernel first
- use the DT from upstream kernel as-is and add a separate patch in the
u-boot tree
- use the DT from upstream kernel as-is and squash in my patch

Or something else?

Updating the DT from upstream will possibly mean updating the DTs for all
other iMX7 boards [1], because the include/dt-bindings stuff has changed
slightly, as well as the imx7s.dtsi file. I have no way of testing the
other boards, but I guess their maintainers can help there.


- Checking that stdio-path is correct
>

That's probably what bricked my board...

Cheers,
Ryan.

[1] There only appear to be two iMX7 board in u-boot already:
arch/arm/dts/imx7d.dtsi:44:#include "imx7s.dtsi"
arch/arm/dts/imx7-colibri.dts:9:#include "imx7d.dtsi"
arch/arm/dts/imx7d-sdb.dts:9:#include "imx7d.dtsi"



> Regards,
> Simon
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] serial: mxc: support DTE mode

[Ryan Harkin]

Hi Stefan,

Thanks for looking so quickly.

On 19 January 2018 at 12:23, Stefan Agner <stefan.ag...@toradex.com> wrote:

> Hi Ryan,
>
>
> On 19.01.2018 10:53, Ryan Harkin wrote:
> > Add DTE mode support via Kconfig on the MXC uart.
>
> Make use of the driver model, there DTE is supported already today:
> https://lists.denx.de/pipermail/u-boot/2016-July/259573.html


My change would be useful for other non-DM users of serial_mxc.c, of
course. Not just WaRP7.

I don't have any objection to WaRP7 moving to DM, although that isn't my
call, but moving using the driver model is not a straight-forward change,
is it? WaRP7 today doesn't use it.

Do you have an example of a board using this driver that switched using the
driver model? I'd like to see the scale of the changes needed.

Regards,
Ryan.



>
> --
> Stefan
>
> >
> > Signed-off-by: Ryan Harkin <ryan.har...@linaro.org>
> > Reviewed-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
> > ---
> >  drivers/serial/Kconfig  |  7 +++
> >  drivers/serial/serial_mxc.c | 10 --
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
> > index 122b8e7..0df57c0 100644
> > --- a/drivers/serial/Kconfig
> > +++ b/drivers/serial/Kconfig
> > @@ -597,4 +597,11 @@ config SYS_SDMR
> >   depends on MPC8XX_CONS
> >   default 0
> >
> > +config SERIAL_MXC_DTE_MODE
> > + bool "Use DTE mode for the MXC UART"
> > + default n
> > + help
> > +   This is used to set DTE mode on the serial console controlled by
> > +   serial_mxc.c.
> > +
> >  endmenu
> > diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
> > index cce80a8..e7ea30c 100644
> > --- a/drivers/serial/serial_mxc.c
> > +++ b/drivers/serial/serial_mxc.c
> > @@ -111,6 +111,12 @@
> >  #define TXTL 2  /* reset default */
> >  #define RXTL 1  /* reset default */
> >
> > +#ifdef CONFIG_SERIAL_MXC_DTE_MODE
> > +#define MXC_DTE_MODE true
> > +#else
> > +#define MXC_DTE_MODE false
> > +#endif
> > +
> >  DECLARE_GLOBAL_DATA_PTR;
> >
> >  struct mxc_uart {
> > @@ -189,7 +195,7 @@ static void mxc_serial_setbrg(void)
> >   if (!gd->baudrate)
> >   gd->baudrate = CONFIG_BAUDRATE;
> >
> > - _mxc_serial_setbrg(mxc_base, clk, gd->baudrate, false);
> > + _mxc_serial_setbrg(mxc_base, clk, gd->baudrate, MXC_DTE_MODE);
> >  }
> >
> >  static int mxc_serial_getc(void)
> > @@ -367,7 +373,7 @@ static inline void _debug_uart_init(void)
> >
> >   _mxc_serial_init(base);
> >   _mxc_serial_setbrg(base, CONFIG_DEBUG_UART_CLOCK,
> > -CONFIG_BAUDRATE, false);
> > +CONFIG_BAUDRATE, MXC_DTE_MODE);
> >  }
> >
> >  static inline void _debug_uart_putc(int ch)
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] warp7: add support for console on UART6 and mikroBus

[Ryan Harkin]

Add support to route the serial console on the NXP WaRP7 board
to UART6 and the mikroBus.

To use UART6 on the WaRP7 board, I add the following lines to
configs/warp7_defconfig:

+CONFIG_MXC_CONSOLE_NUM=6
+CONFIG_SERIAL_MXC_DTE_MODE=y

Signed-off-by: Ryan Harkin <ryan.har...@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
---
 board/warp7/Kconfig | 9 +
 board/warp7/warp7.c | 6 ++
 include/configs/warp7.h | 8 +++-
 3 files changed, 22 insertions(+), 1 deletion(-)

diff --git a/board/warp7/Kconfig b/board/warp7/Kconfig
index 61c33fb..5fb4824 100644
--- a/board/warp7/Kconfig
+++ b/board/warp7/Kconfig
@@ -6,4 +6,13 @@ config SYS_BOARD
 config SYS_CONFIG_NAME
default "warp7"
 
+config MXC_CONSOLE_NUM
+   int "UART used for the console"
+   default 1
+   help
+ The UART used for the console, expressed as a 1-based integer.
+ This is also used to set the console variable passed to the kernel.
+ Currently, only UART1 and UART6 are supported. Specifying a value
+ other than 6 will result in using UART1.
+
 endif
diff --git a/board/warp7/warp7.c b/board/warp7/warp7.c
index d422d63..d345b0e 100644
--- a/board/warp7/warp7.c
+++ b/board/warp7/warp7.c
@@ -67,6 +67,11 @@ static iomux_v3_cfg_t const uart1_pads[] = {
MX7D_PAD_UART1_RX_DATA__UART1_DCE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
 };
 
+static iomux_v3_cfg_t const uart6_pads[] = {
+   MX7D_PAD_ECSPI1_MOSI__UART6_DTE_RX | MUX_PAD_CTRL(UART_PAD_CTRL),
+   MX7D_PAD_ECSPI1_SCLK__UART6_DTE_TX | MUX_PAD_CTRL(UART_PAD_CTRL),
+};
+
 static iomux_v3_cfg_t const usdhc3_pads[] = {
MX7D_PAD_SD3_CLK__SD3_CLK | MUX_PAD_CTRL(USDHC_PAD_CTRL),
MX7D_PAD_SD3_CMD__SD3_CMD | MUX_PAD_CTRL(USDHC_PAD_CTRL),
@@ -84,6 +89,7 @@ static iomux_v3_cfg_t const usdhc3_pads[] = {
 static void setup_iomux_uart(void)
 {
imx_iomux_v3_setup_multiple_pads(uart1_pads, ARRAY_SIZE(uart1_pads));
+   imx_iomux_v3_setup_multiple_pads(uart6_pads, ARRAY_SIZE(uart6_pads));
 };
 
 static struct fsl_esdhc_cfg usdhc_cfg[1] = {
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 11f1bc3..271667d 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -13,7 +13,13 @@
 
 #define PHYS_SDRAM_SIZESZ_512M
 
+#if (CONFIG_MXC_CONSOLE_NUM == 6)
+#define CONFIG_MXC_UART_BASE   UART6_IPS_BASE_ADDR
+#define CONSOLE"ttymxc5"
+#else
 #define CONFIG_MXC_UART_BASE   UART1_IPS_BASE_ADDR
+#define CONSOLE"ttymxc0"
+#endif
 
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN  (35 * SZ_1M)
@@ -31,7 +37,7 @@
CONFIG_DFU_ENV_SETTINGS \
"script=boot.scr\0" \
"image=zImage\0" \
-   "console=ttymxc0\0" \
+   "console=" CONSOLE "\0" \
"ethact=usb_ether\0" \
"fdt_high=0x\0" \
"initrd_high=0x\0" \
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/2] serial: mxc: support DTE mode

[Ryan Harkin]

Add DTE mode support via Kconfig on the MXC uart.

Signed-off-by: Ryan Harkin <ryan.har...@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonog...@linaro.org>
---
 drivers/serial/Kconfig  |  7 +++
 drivers/serial/serial_mxc.c | 10 --
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
index 122b8e7..0df57c0 100644
--- a/drivers/serial/Kconfig
+++ b/drivers/serial/Kconfig
@@ -597,4 +597,11 @@ config SYS_SDMR
depends on MPC8XX_CONS
default 0
 
+config SERIAL_MXC_DTE_MODE
+   bool "Use DTE mode for the MXC UART"
+   default n
+   help
+ This is used to set DTE mode on the serial console controlled by
+ serial_mxc.c.
+
 endmenu
diff --git a/drivers/serial/serial_mxc.c b/drivers/serial/serial_mxc.c
index cce80a8..e7ea30c 100644
--- a/drivers/serial/serial_mxc.c
+++ b/drivers/serial/serial_mxc.c
@@ -111,6 +111,12 @@
 #define TXTL   2  /* reset default */
 #define RXTL   1  /* reset default */
 
+#ifdef CONFIG_SERIAL_MXC_DTE_MODE
+#define MXC_DTE_MODE   true
+#else
+#define MXC_DTE_MODE   false
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;
 
 struct mxc_uart {
@@ -189,7 +195,7 @@ static void mxc_serial_setbrg(void)
if (!gd->baudrate)
gd->baudrate = CONFIG_BAUDRATE;
 
-   _mxc_serial_setbrg(mxc_base, clk, gd->baudrate, false);
+   _mxc_serial_setbrg(mxc_base, clk, gd->baudrate, MXC_DTE_MODE);
 }
 
 static int mxc_serial_getc(void)
@@ -367,7 +373,7 @@ static inline void _debug_uart_init(void)
 
_mxc_serial_init(base);
_mxc_serial_setbrg(base, CONFIG_DEBUG_UART_CLOCK,
-  CONFIG_BAUDRATE, false);
+  CONFIG_BAUDRATE, MXC_DTE_MODE);
 }
 
 static inline void _debug_uart_putc(int ch)
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 0/2] warp7: add UART6 support

[Ryan Harkin]

This small series adds support for using the console on UART6 on
the WaRP7 board.

The board retains current functionality: UART6 is not used by
default and needs it needs to be enabled in defconfig.

[PATCH 1/2] serial: mxc: support DTE mode
[PATCH 2/2] warp7: add support for console on UART6 and mikroBus

 board/warp7/Kconfig |  9 +
 board/warp7/warp7.c |  6 ++
 drivers/serial/Kconfig  |  7 +++
 drivers/serial/serial_mxc.c | 10 --
 include/configs/warp7.h |  8 +++-
 5 files changed, 37 insertions(+), 3 deletions(-)

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] am33xx ddr tests

[Ryan]

Hello,

I have 2 chips which are 512mb each connected to the AM33xx processor.

I want to check if the base address is configured for each chip in
u-boot or kernel.

If it is configured in u-boot can anyone point me to where it is configured.

The problem i am facing is i dont if i need to do a
mtest 0x840 0xC00
.
or

mtest 0x840 0xA00.
mtest 0xC00 0xE00

Also, is 64MB sufficient for u-boot to function. What is the least
starting address i can give for mtest.

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] do_smhload: fix return code

[Ryan Harkin]

do_smhload was using a ulong to store the return value from
smh_load_file. That returns an int, where -1 indicates an error. As a
ulong will never be negative, smh_load_file errors were not detected and
so_smhload always returned zero.

Also, when errors were spotted, do_smhload was returning 1, rather than
the enumeration CMD_RET_FAILURE (which is also 1).

Signed-off-by: Ryan Harkin <ryan.har...@linaro.org>
---
 arch/arm/lib/semihosting.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/semihosting.c b/arch/arm/lib/semihosting.c
index e32ad90..415ac89 100644
--- a/arch/arm/lib/semihosting.c
+++ b/arch/arm/lib/semihosting.c
@@ -186,7 +186,7 @@ static int do_smhload(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
if (argc == 3 || argc == 4) {
ulong load_addr;
ulong end_addr = 0;
-   ulong ret;
+   int ret;
char end_str[64];
 
load_addr = simple_strtoul(argv[2], NULL, 16);
@@ -195,7 +195,7 @@ static int do_smhload(cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
 
ret = smh_load_file(argv[1], load_addr, _addr);
if (ret < 0)
-   return 1;
+   return CMD_RET_FAILURE;
 
/* Optionally save returned end to the environment */
if (argc == 4) {
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/listinfo/u-boot

[U-Boot] mlo and u-boot

[Ryan]

Hello,

I am using AM43XX based board. The bootloader is divided into spl
u-boot (MLO) and u-boot.bin

I wanted to check what variables are shared between them. How does MLO
a seperate binary
share the boot mode and mmcdev to u-boot so that it can use the
appropriate mmcdev to find the
kernel.

thanks,
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] cmd: move CONFIG_CMD_UNZIP and CONFIG_CMD_ZIP to Kconfig

[Ryan Harkin]

On 5 February 2017 at 01:42, Masahiro Yamada
<yamada.masah...@socionext.com> wrote:
> CONFIG_CMD_ZIP is not defined by any board.  I am moving
> CONFIG_CMD_UNZIP to defconfig files except UniPhier SoC family.
>
> I am the maintainer of UniPhier platform, so I know "select CMD_UNZIP"
> is better for this platform.
>
> Signed-off-by: Masahiro Yamada <yamada.masah...@socionext.com>
> Acked-by: Michal Simek <michal.si...@xilinx.com>
> Acked-by: Stefan Roese <s...@denx.de>
Acked-by: Ryan Harkin <ryan.har...@linaro.org>
Tested-by: Ryan Harkin <ryan.har...@linaro.org>

Tested on TC2, FVP Foundation and AEMv8 models and Juno R0, R1 and R2.


> ---
>
> Changes in v3:
>   - Fix a typo in Kconfig help: Compresses -> Compress
>
> Changes in v2:
>   - Fix a typo in git-log:  CMD_ZIP -> CMD_UNZIP
>
>  README   |  6 --
>  arch/arm/mach-uniphier/Kconfig   |  1 +
>  cmd/Kconfig  | 10 ++
>  configs/brxre1_defconfig |  1 +
>  configs/dragonboard410c_defconfig|  1 +
>  configs/ethernut5_defconfig  |  1 +
>  configs/hikey_defconfig  |  1 +
>  configs/icnova-a20-swac_defconfig|  3 ++-
>  configs/vexpress_aemv8a_dram_defconfig   |  1 +
>  configs/vexpress_aemv8a_juno_defconfig   |  1 +
>  configs/vexpress_aemv8a_semi_defconfig   |  1 +
>  configs/xilinx_zynqmp_ep_defconfig   |  1 +
>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  1 +
>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  1 +
>  configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig |  1 +
>  configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  1 +
>  configs/xilinx_zynqmp_zcu102_defconfig   |  1 +
>  configs/xilinx_zynqmp_zcu102_revB_defconfig  |  1 +
>  include/config_cmd_all.h |  1 -
>  include/configs/brxre1.h |  1 -
>  include/configs/dragonboard410c.h|  1 -
>  include/configs/ethernut5.h  |  1 -
>  include/configs/hikey.h  |  1 -
>  include/configs/uniphier.h   |  4 
>  include/configs/vexpress_aemv8a.h|  1 -
>  include/configs/xilinx_zynqmp.h  |  2 --
>  26 files changed, 27 insertions(+), 19 deletions(-)
>
> diff --git a/README b/README
> index 9c992c1..89c12b0 100644
> --- a/README
> +++ b/README
> @@ -1765,12 +1765,6 @@ The following options need to be configured:
> can be displayed via the splashscreen support or the
> bmp command.
>
> -- Do compressing for memory range:
> -   CONFIG_CMD_ZIP
> -
> -   If this option is set, it would use zlib deflate method
> -   to compress the specified memory at its best effort.
> -
>  - Compression support:
> CONFIG_GZIP
>
> diff --git a/arch/arm/mach-uniphier/Kconfig b/arch/arm/mach-uniphier/Kconfig
> index cd9ba6b..5739325 100644
> --- a/arch/arm/mach-uniphier/Kconfig
> +++ b/arch/arm/mach-uniphier/Kconfig
> @@ -13,6 +13,7 @@ config ARCH_UNIPHIER_32BIT
>  config ARCH_UNIPHIER_64BIT
> bool
> select ARM64
> +   select CMD_UNZIP
> select SPL_SEPARATE_BSS if SPL
> select ARMV8_MULTIENTRY if SPL
> select ARMV8_SPIN_TABLE if SPL
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 4a0d489..d618a51 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -346,6 +346,16 @@ config CMD_MEMINFO
> help
>   Display memory information.
>
> +config CMD_UNZIP
> +   bool "unzip"
> +   help
> + Uncompress a zip-compressed memory region.
> +
> +config CMD_ZIP
> +   bool "zip"
> +   help
> + Compress a memory region with zlib deflate method.
> +
>  endmenu
>
>  menu "Device access commands"
> diff --git a/configs/brxre1_defconfig b/configs/brxre1_defconfig
> index 0b7b082..dfa8712 100644
> --- a/configs/brxre1_defconfig
> +++ b/configs/brxre1_defconfig
> @@ -31,6 +31,7 @@ CONFIG_CMD_BOOTZ=y
>  # CONFIG_CMD_XIMG is not set
>  # CONFIG_CMD_EDITENV is not set
>  # CONFIG_CMD_CRC32 is not set
> +CONFIG_CMD_UNZIP=y
>  # CONFIG_CMD_LOADB is not set
>  # CONFIG_CMD_LOADS is not set
>  # CONFIG_CMD_FLASH is not set
> diff --git a/configs/dragonboard410c_defconfig 
> b/configs/dragonboard410c_defconfig
> index 8f206e2..e94f7b3 100644
> --- a/configs/dragonboard410c_defconfig
> +++ b/configs/dragonboard410c_defconfig
> @@ -9,6 +9,7 @@ CONFIG_SYS_PROMPT="

Re: [U-Boot] [PATCH v2] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

[Ryan Harkin]

On 16 January 2017 at 08:34, Alexander Graf <ag...@suse.de> wrote:
>
>
> On 16/01/2017 07:16, Alison Wang wrote:
>>
>> For 64-bit kernel, there is a warning about x1-x3 nonzero in violation
>> of boot protocol. To fix this issue, input argument 4 is added for
>> armv8_switch_to_el2 and armv8_switch_to_el1. The input argument 4 will
>> be set to the right value, such as zero.
>>
>> Signed-off-by: Alison Wang <alison.w...@nxp.com>

Thanks Alison, this removes the warning for me now and still boots
fine. I tested with Juno R0/1/2 and FVP Foundation and AEMv8 models.

Tested-by: Ryan Harkin <ryan.har...@linaro.org>


>> ---
>> Changes in v2:
>> - Add another input argument 4 for armv8_switch_to_el2 and
>> armv8_switch_to_el1.
>> - Give up the previous way to adjust the parameters to transfer and make
>> sure x3 is zero.
>>
>>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 28
>> ++--
>>  arch/arm/cpu/armv8/sec_firmware_asm.S|  5 +++--
>>  arch/arm/cpu/armv8/start.S   |  8 
>>  arch/arm/cpu/armv8/transition.S  | 22 +++---
>>  arch/arm/include/asm/system.h|  8 +---
>>  arch/arm/lib/bootm.c | 10 +-
>>  arch/arm/mach-rmobile/lowlevel_init_gen3.S   |  8 
>>  cmd/bootefi.c|  2 +-
>>  8 files changed, 47 insertions(+), 44 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
>> b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
>> index 72f2c11..63215f0 100644
>> --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
>> @@ -378,29 +378,29 @@ cpu_is_le:
>> b.eq1f
>>
>>  #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
>> -   adr x3, secondary_switch_to_el1
>> -   ldr x4, =ES_TO_AARCH64
>> +   adr x4, secondary_switch_to_el1
>> +   ldr x5, =ES_TO_AARCH64
>>  #else
>> -   ldr x3, [x11]
>> -   ldr x4, =ES_TO_AARCH32
>> +   ldr x4, [x11]
>> +   ldr x5, =ES_TO_AARCH32
>>  #endif
>> bl  secondary_switch_to_el2
>>
>>  1:
>>  #ifdef CONFIG_ARMV8_SWITCH_TO_EL1
>> -   adr x3, secondary_switch_to_el1
>> +   adr x4, secondary_switch_to_el1
>>  #else
>> -   ldr x3, [x11]
>> +   ldr x4, [x11]
>>  #endif
>> -   ldr x4, =ES_TO_AARCH64
>> +   ldr x5, =ES_TO_AARCH64
>> bl  secondary_switch_to_el2
>>
>>  ENDPROC(secondary_boot_func)
>>
>>  ENTRY(secondary_switch_to_el2)
>> -   switch_el x5, 1f, 0f, 0f
>> +   switch_el x6, 1f, 0f, 0f
>>  0: ret
>> -1: armv8_switch_to_el2_m x3, x4, x5
>> +1: armv8_switch_to_el2_m x4, x5, x6
>>  ENDPROC(secondary_switch_to_el2)
>>
>>  ENTRY(secondary_switch_to_el1)
>> @@ -414,22 +414,22 @@ ENTRY(secondary_switch_to_el1)
>> /* physical address of this cpus spin table element */
>> add x11, x1, x0
>>
>> -   ldr x3, [x11]
>> +   ldr x4, [x11]
>>
>> ldr x5, [x11, #24]
>> ldr x6, =IH_ARCH_DEFAULT
>> cmp x6, x5
>> b.eq2f
>>
>> -   ldr x4, =ES_TO_AARCH32
>> +   ldr x5, =ES_TO_AARCH32
>> bl  switch_to_el1
>>
>> -2: ldr x4, =ES_TO_AARCH64
>> +2: ldr x5, =ES_TO_AARCH64
>>
>>  switch_to_el1:
>> -   switch_el x5, 0f, 1f, 0f
>> +   switch_el x6, 0f, 1f, 0f
>>  0: ret
>> -1: armv8_switch_to_el1_m x3, x4, x5
>> +1: armv8_switch_to_el1_m x4, x5, x6
>>  ENDPROC(secondary_switch_to_el1)
>>
>> /* Ensure that the literals used by the secondary boot code are
>> diff --git a/arch/arm/cpu/armv8/sec_firmware_asm.S
>> b/arch/arm/cpu/armv8/sec_firmware_asm.S
>> index 903195d..747b53f 100644
>> --- a/arch/arm/cpu/armv8/sec_firmware_asm.S
>> +++ b/arch/arm/cpu/armv8/sec_firmware_asm.S
>> @@ -57,7 +57,8 @@ ENDPROC(_sec_firmware_support_psci_version)
>>   * x0: argument, zero
>>   * x1: machine nr
>>   * x2: fdt address
>> - * x3: kernel entry point
>> + * x3: input argument
>> + * x4: kernel entry point
>>   * @param outputs for secure firmware:
>>   * x0: function id
>>   * x1: kernel entry point
>> @@ -65,7 +66,7 @@ ENDPROC(_sec_firmware_support_psci_version)
>>   * x3: fdt address
>>  */
>>  ENTRY(armv8_el2_to_aarch32)
>> -   mov x0, x3
>> +   mov x0, x4
>
>
> You no longer need x0 as scratch register. Just write ...
>
>> mov x3, x2
>> mov x2, x1
>> mov x1, x0
>
>
> ... x4 directly into x1 here.
>
>
> Otherwise looks good to me. So with the change above you can add my
>
>   Reviewed-by: Alexander Graf <ag...@suse.de>
>
> tag in the next version.
>
>
> Alex
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

On 13 January 2017 at 14:19, Mark Rutland <mark.rutl...@arm.com> wrote:
> On Thu, Jan 12, 2017 at 01:47:32PM +0000, Ryan Harkin wrote:
>> On 12 January 2017 at 12:25, Mark Rutland <mark.rutl...@arm.com> wrote:
>> > On Tue, Jan 10, 2017 at 06:50:19PM +, Jon Medhurst (Tixy) wrote:
>> >> On Tue, 2017-01-10 at 18:34 +, Mark Rutland wrote:
>> >> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
>> >> > simply adding new descriptions, so a DTB from a year ago should work
>> >> > just fine with mainline (modulo the Juno PCI window issue, which was a
>> >> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
>> >> > equivalent functionality.
>
>> > The key point is that it is possible to provide a baseline DTB that is
>> > good enough for most users, and will work with future kernels.
>> >
>> > We're unlikely to get to a state where DTBs are perfect and complete
>> > from day one. We can have something that remains usable.
>>
>> I hope it stays that way. Most of my users are either on 3.18 or 4.4.
>> And they are incompatible with each other w.r.t. DTBs to the point
>> where one won't even post a banner message with the other's DTB.
>
> Interesting. Just to check, do you mean v3.19? There was no upstream
> Juno DT in v3.18.
>
> Unfortunately, I can't spot any DT changes between v3.19 and v4.4 that
> would obviously break compatibility such that serial wouldn't work.
>
> If you have those kernels && DTBs to hand, are you able to take a look
> if passing "earlycon=pl011,0x7ff8"?
>
> I know that the ARM Software linux repo shipped a broken DT, along with
> some kernel modifications which bodge around that (specifically, they
> exposed a broken MMIO timer as functional). IIRC, Poking that would
> bring down the kernel, before the serial wa up.
>
> Is your v3.18 DT the old ARM Software repo's Juno DT?
>

I don't have any of the data points any more, but it wasn't due to the
ARMLT tree, which tends to be stable/reliable. It was mostly debian vs
upstream.


> Thanks,
> Mark.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] armv8: aarch64: Fix the warning about x1-x3 nonzero issue

[Ryan Harkin]

Hi Alison,

I'll wait for a new version based on Alex's feedback before I test.

The change looks like it should work, so I'm happy to wait, unless you feel
thjere is a need to test it sooner.

Thanks for the quick response.

Regards,
Ryan.


On 13 Jan 2017 08:16, "Alison Wang" <alison.w...@nxp.com> wrote:

Hi, Ryan,

This patch is to fix the issue about a warning for ARMv8 64-bit
kernel you reported before. I have tested on my LayerScape boards. Please
review and try on your boards too.

Thanks.


Best Regards,
Alison Wang

> -Original Message-
> From: Alison Wang [mailto:b18...@freescale.com]
> Sent: Friday, January 13, 2017 3:50 PM
> To: york sun <york@nxp.com>; ryan.har...@linaro.org; ag...@suse.de;
> Scott Wood <scott.w...@nxp.com>; Stuart Yoder <stuart.yo...@nxp.com>;
> Leo Li <leoyang...@nxp.com>; feng...@phytium.com.cn;
> linus.wall...@linaro.org; u-boot@lists.denx.de
> Cc: Jason Jin <jason@nxp.com>; Alison Wang <alison.w...@nxp.com>
> Subject: [PATCH] armv8: aarch64: Fix the warning about x1-x3 nonzero
> issue
>
> For 64-bit kernel, there is a warning about x1-x3 nonzero in violation
> of boot protocol. x3 should be reset to zero before jumping to the
> kernel.
>
> This patch will adjust the parameters to transfer and make sure x3 is
> zero.
>
> Signed-off-by: Alison Wang <alison.w...@nxp.com>
> ---
>  arch/arm/cpu/armv8/transition.S | 44
> +
>  1 file changed, 40 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/cpu/armv8/transition.S
> b/arch/arm/cpu/armv8/transition.S index adb9f35..06b6664 100644
> --- a/arch/arm/cpu/armv8/transition.S
> +++ b/arch/arm/cpu/armv8/transition.S
> @@ -26,9 +26,27 @@ ENTRY(armv8_switch_to_el2)
>* if CONFIG_ARMV8_SWITCH_TO_EL1 is defined.
>   * When running in EL2 now, jump to the
>* address saved in x3.
> +  *
> +  * For 64-bit kernel, there is a warning about
> +  * x1-x3 nonzero in violation of boot protocol.
> +  * x3 should be reset to zero before jumping to
> +  * the kernel. Use x4 instead of x3 as parameter.
>*/
> - br x3
> -1:   armv8_switch_to_el2_m x3, x4, x5
> + mov x4, x3
> + mov x3, #0
> + br x4
> +1:
> + /*
> +  * For 64-bit kernel, there is a warning about
> +  * x1-x3 nonzero in violation of boot protocol.
> +  * x3 should be reset to zero before jumping to
> +  * the kernel. Use x4, x5, x6 instead of x3, x4,
> +  * x5 as parameters.
> +  */
> + mov x5, x4
> + mov x4, x3
> + mov x3, #0
> + armv8_switch_to_el2_m x4, x5, x6
>  ENDPROC(armv8_switch_to_el2)
>
>  ENTRY(armv8_switch_to_el1)
> @@ -36,9 +54,27 @@ ENTRY(armv8_switch_to_el1)
>  0:
>   /* x3 is kernel entry point. When running in EL1
>* now, jump to the address saved in x3.
> +  *
> +  * For 64-bit kernel, there is a warning about
> +  * x1-x3 nonzero in violation of boot protocol.
> +  * x3 should be reset to zero before jumping to
> +  * the kernel. Use x4 instead of x3 as parameter.
> +  */
> + mov x4, x3
> + mov x3, #0
> + br x4
> +1:
> + /*
> +  * For 64-bit kernel, there is a warning about
> +  * x1-x3 nonzero in violation of boot protocol.
> +  * x3 should be reset to zero before jumping to
> +  * the kernel. Use x4, x5, x6 instead of x3, x4,
> +  * x5 as parameters.
>*/
> - br x3
> -1:   armv8_switch_to_el1_m x3, x4, x5
> + mov x5, x4
> + mov x4, x3
> + mov x3, #0
> + armv8_switch_to_el1_m x4, x5, x6
>  ENDPROC(armv8_switch_to_el1)
>
>  WEAK(armv8_el2_to_aarch32)
> --
> 2.1.0.27.g96db324
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

On 12 January 2017 at 12:25, Mark Rutland  wrote:
> On Tue, Jan 10, 2017 at 06:50:19PM +, Jon Medhurst (Tixy) wrote:
>> On Tue, 2017-01-10 at 18:34 +, Mark Rutland wrote:
>> > Looking at the git log for arch/arm64/boot/dts/arm, most updates are
>> > simply adding new descriptions, so a DTB from a year ago should work
>> > just fine with mainline (modulo the Juno PCI window issue, which was a
>> > DTB bug). Upgrading kernel shouldn't require a DTB upgrade to see
>> > equivalent functionality.
>>
>> But if you want the new functionality in the kernel, why should you be
>> forced to wait for the bootloader to catch up (or do that work yourself)
>> then upgrade to that new bootloader version? And what about the poor
>> devs working on that new functionality, they're going to need to use not
>> upstream device-trees. Then there's all the firmware and system
>> configuration stuff that's in device-tree.
>
> Developers working on low-level stuff will always need to be able to
> override/upgrade/etc. I am certainly not arguing to remove those
> capabilities.
>
> The key point is that it is possible to provide a baseline DTB that is
> good enough for most users, and will work with future kernels.
>
> We're unlikely to get to a state where DTBs are perfect and complete
> from day one. We can have something that remains usable.
>

I hope it stays that way. Most of my users are either on 3.18 or 4.4.
And they are incompatible with each other w.r.t. DTBs to the point
where one won't even post a banner message with the other's DTB.

> Thanks,
> Mark.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v8 1/3] armv8: Support loading 32-bit OS in AArch32 execution state

[Ryan Harkin]

Hi Alison,

I wasn't sure where about in this thread to reply to this patch, so I
thought here was as good as any...

I know I tested this commit and it works for me. However, my colleague
Tixy has spotted a recent warning on the kernel dmesg output that only
arrived with an update to u-boot:

[0.00] WARNING: x1-x3 nonzero in violation of boot protocol:
[0.00] x1: 
[0.00] x2: 
[0.00] x3: 8008
[0.00] This indicates a broken bootloader or old kernel

This happens on our ARM64 kernels, both the 4.4 based kernel and the
4.9.0 based kernel. They boot, it's with the extra warning.

I bisected it down to the change in this email thread, upstream as
commit ec6617c39741adc6c54952564579e32c3c09c66f in the master repo.

And I can see below in many places that the code is using x3 for the
first time. I'm not sure which one is causing the warning in the
kernel, but I guess we need to reset x3 to zero before jumping to the
kernel?

I'm happy to test any fixes if you wish to send them to me.

Thanks,
Ryan.



On 10 November 2016 at 02:49, Alison Wang <b18...@freescale.com> wrote:
> To support loading a 32-bit OS, the execution state will change from
> AArch64 to AArch32 when jumping to kernel.
>
> The architecture information will be got through checking FIT image,
> then U-Boot will load 32-bit OS or 64-bit OS automatically.
>
> Signed-off-by: Ebony Zhu <ebony@nxp.com>
> Signed-off-by: Alison Wang <alison.w...@nxp.com>
> Signed-off-by: Chenhui Zhao <chenhui.z...@nxp.com>
> ---
> Changes in v8:
> - Fix the issue when U-Boot is running in EL2 or EL1.
>
> Changes in v7:
> - Move the call for armv8_switch_to_el2_m into this patch.
>
> Changes in v6:
> - Modified armv8_switch_to_el1(). It will always jump to ep when switching to 
> AArch64 or AArch32 modes.
> - Make other platforms compatible with the new armv8_switch_to_el2() and 
> armv8_switch_to_el1().
>
> Changes in v5:
> - Modified armv8_switch_to_el2(). It will always jump to ep when switching to 
> AArch64 or AArch32 modes.
>
> Changes in v4:
> - Correct config ARM64_SUPPORT_AARCH32.
> - Omit arch and ftaddr arguments.
> - Rename "xreg5" to "tmp".
> - Use xxx_RES1 to combine all RES1 fields in xxx register.
> - Use an immediate cmp directly.
> - Use #ifdef for CONFIG_ARM64_SUPPORT_AARCH32.
>
> Changes in v3:
> - Comments the functions and the arguments.
> - Rename the real parameters.
> - Use the macros instead of the magic values.
> - Remove the redundant codes.
> - Clean up all of the mess in boot_jump_linux().
> - Add CONFIG_ARM64_SUPPORT_AARCH32 to detect for some ARM64 system doesn't 
> support AArch32 state.
>
> Changes in v2:
> - armv8_switch_to_el2_aarch32() is removed. armv8_switch_to_el2_m is used
>   to switch to AArch64 EL2 or AArch32 Hyp.
> - armv8_switch_to_el1_aarch32() is removed. armv8_switch_to_el1_m is used
>   to switch to AArch64 EL1 or AArch32 SVC.
>
>  arch/arm/Kconfig  |   6 +
>  arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S  |  61 +++--
>  arch/arm/cpu/armv8/start.S|   8 ++
>  arch/arm/cpu/armv8/transition.S   |  23 +++-
>  arch/arm/include/asm/arch-fsl-layerscape/mp.h |   4 +
>  arch/arm/include/asm/macro.h  | 176 
> +++---
>  arch/arm/include/asm/system.h | 119 -
>  arch/arm/lib/bootm.c  |  39 +-
>  arch/arm/mach-rmobile/lowlevel_init_gen3.S|   9 +-
>  common/image-fit.c|  19 ++-
>  10 files changed, 396 insertions(+), 68 deletions(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index d7a9b11..18c23c0 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -126,6 +126,12 @@ config ENABLE_ARM_SOC_BOOT0_HOOK
>   ARM_SOC_BOOT0_HOOK which contains the required assembler
>   preprocessor code.
>
> +config ARM64_SUPPORT_AARCH32
> +   bool "ARM64 system support AArch32 execution state"
> +   default y if ARM64 && !TARGET_THUNDERX_88XX
> +   help
> + This ARM64 system supports AArch32 execution state.
> +
>  choice
> prompt "Target select"
> default TARGET_HIKEY
> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
> b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> index 5700b1f..8e6ad4b 100644
> --- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> +++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
> @@ -13,6 +13,7 @@
>  #ifdef CONFIG_MP
>  #include 
>  #endif
> +#include 
>
>  ENTRY(lowlevel_init)
> mov x29, lr /* Save

Re: [U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

On 10 January 2017 at 16:58, Alexander Graf <ag...@suse.de> wrote:
> On 01/10/2017 05:47 PM, Ryan Harkin wrote:
>>
>> On 10 January 2017 at 16:35, Alexander Graf <ag...@suse.de> wrote:
>>>
>>> On 01/10/2017 05:31 PM, york sun wrote:
>>>>
>>>> On 01/10/2017 05:02 AM, Alexander Graf wrote:
>>>>>
>>>>> On 01/10/2017 01:58 PM, Michal Simek wrote:
>>>>>>
>>>>>> U-Boot configured via DTB can use the same DTB for booting the kernel.
>>>>>> When OF_CONTROL is used fdtcontroladdr is setup and can be use for
>>>>>> boot.
>>>>>>
>>>>>> Signed-off-by: Michal Simek <michal.si...@xilinx.com>
>>>>>> ---
>>>>>>
>>>>>> Didn't check if there is any side effect or not but it looks weird
>>>>>> when
>>>>>> you have DT driver u-boot that you have to load dtb again.
>>>>>
>>>>> I agree, and I think it's very reasonable to try and use the same
>>>>> device
>>>>> tree for U-Boot and Linux.
>>>>>
>> Would this prevent the user loading a DTB into ram and using bootm to
>> over-ride the built-in DTB?
>>
>> I have a background task to refactor u-boot support for ARM Ltd
>> boards. One of many options I was considering was to have a minimal
>> DTB to configure the platform with only the nodes needed for u-boot.
>> The ARM Ltd device trees fluctuate so much, I wouldn't be able to
>> commit to one DTB that will work forever...
>
>
> No, it's only meant as a fallback when no manual device tree is provided.

Thanks for confirmation.


> In
> an ideal world however, device trees are static and complete, so you could
> just put a final dt into U-Boot and have it propagated all the way through.
>

I look forward to living in this ideal world the EDK2 and kernel
communities promised me several years ago ;-)

> Alex
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] arm: bootm: Boot kernel with U-Boot's FDT blob

[Ryan Harkin]

On 10 January 2017 at 16:35, Alexander Graf  wrote:
> On 01/10/2017 05:31 PM, york sun wrote:
>>
>> On 01/10/2017 05:02 AM, Alexander Graf wrote:
>>>
>>> On 01/10/2017 01:58 PM, Michal Simek wrote:

 U-Boot configured via DTB can use the same DTB for booting the kernel.
 When OF_CONTROL is used fdtcontroladdr is setup and can be use for boot.

 Signed-off-by: Michal Simek 
 ---

 Didn't check if there is any side effect or not but it looks weird when
 you have DT driver u-boot that you have to load dtb again.
>>>
>>> I agree, and I think it's very reasonable to try and use the same device
>>> tree for U-Boot and Linux.
>>>

Would this prevent the user loading a DTB into ram and using bootm to
over-ride the built-in DTB?

I have a background task to refactor u-boot support for ARM Ltd
boards. One of many options I was considering was to have a minimal
DTB to configure the platform with only the nodes needed for u-boot.
The ARM Ltd device trees fluctuate so much, I wouldn't be able to
commit to one DTB that will work forever...


>> Size is a concern. U-Boot only uses a small portion of the device tree.
>> If the complete device tree is embedded into U-Boot, the size increases
>> quite a bit.
>
>
> Is size really a concern? At the end of the day we only care about the full
> dt for non-SPL U-Boot which is reasonably big anyway. And if it's a real
> problem, we can always compress.
>
>
> Alex
>
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PACH v2 1/1] Add vexpress_aemv8a_aarch32 variant

[Ryan Harkin]

Hi Tom,

On 5 December 2016 at 17:13, Tom Rini <tr...@konsulko.com> wrote:
> On Mon, Dec 05, 2016 at 04:11:45PM +0000, Ryan Harkin wrote:
>
>> The ARM AEMv8 FVP model can be run in Aarch64 or Aarch32 mode. Aarch32
>> support is enable per-CPU when launching the model, eg:
>>
>> -C cluster0.cpu0.CONFIG64=0
>>
>> This patch adds a new defconfig and some variant specific selections in
>> vexpress_armv8a.h.
>>
>> This patch is co-authored with Soby Mathew <soby.mat...@arm.com>.
>>
>> Signed-off-by: Ryan Harkin <ryan.har...@linaro.org>
> [snip]
>> ---
>>
>> Changes since v1:
>> This single patch replaces my earlier RFC series of two patches, where
>> the first modified generic code and the other added a new variant.
>>
>> After Tom's suggestion that I review the Raspberry PI code, my original
>> [RFC PATCH 1/2] has been dropped completely.
>>
>> To address the generic problems from the first patch:
>> - move CONFIG_REMAKE_ELF to CONFIG_ARM64 only builds in vexpress_aemv8a.h
>> - define CONFIG_SKIP_LOWLEVEL_INIT for non-ARM64 builds (ie. for CPU_V7)
>> - the ARMv8 MMU code in vexpress64.h becomes conditiononal on CONFIG_ARM64
>>
>> I'm not sure if the last change is the correct approach, but it works. I
>> suspect that at the very least, a rework of the vexpress code would split
>> this MMU code into an ARM64 specific .c file.
>
> Assuming your plan is to follow this up with a series to unify and
> correct board/armltd/vexpress*

Yes, I would like to refactor it.  I am trying to work out how far I
can go based on the rpi example.  Currently, I'm thinking that I only
need a board/armlt/vexpress and that the vexpress64 stuff can be
carried across somehow.  Failing that, there is some genuinely common
code between vexpress and vexpress64 that can be shared.

Having an upstream 32-bit version would be moderately useful for me,
but I'm happy to carry this patch in my own fork until I can sort it
out in a more useful way.


> then yes, I think this is a logical step
> forward.  And some level of these CONFIG options should be moved to
> Kconfig as part of that unification.

Yes, taking them out of vexpress_aemv8.h would be a good idea and mean
there is less special case logic in there.


>
> [snip]
>> +config TARGET_VEXPRESS_AEMV8_AARCH32
>> + bool "Support Versatile Express ARMv8a 32-bit FVP BASE model booting 
>> from DRAM"
>> + select CPU_V7
>> + help
>> +   This target is derived from TARGET_VEXPRESS64_BASE_FVP and over-rides
>> +   the default config to allow the user to load the images directly into
>> +   DRAM using model parameters rather than by using semi-hosting to load
>> +   the files from the host filesystem.
>> +
>>  config TARGET_VEXPRESS64_BASE_FVP_DRAM
>>   bool "Support Versatile Express ARMv8a FVP BASE model booting from 
>> DRAM"
>
> I know neither are "nice" names but why not
> TARGET_VEXPRESS64_AEMV8_AARCH32_FVP_DRAM ?

I also considered just appending AARCH32 onto the end of the DRAM
config it was based on, but...

>  Or is this just something
> else that I shouldn't worry about until we're unifying the various
> options here?
>
Yes, don't worry about it.  I'll look at renaming all the
combinations... if I can come up with a scheme that makes sense.

At the moment, the BASE_FVP_DRAM version is a clone of the BASE_FVP
code, just with a different bootcmd.  Now the AARCH32 is another clone
with CPU_V7 and bootz instead of booti.

I'd be interested to know if there is a better way to handle those
small variations.  A better structured header than vexpress_aemv8a.h
would be a good start, of course.

Cheers,
Ryan.
> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PACH v2 1/1] Add vexpress_aemv8a_aarch32 variant

[Ryan Harkin]

The ARM AEMv8 FVP model can be run in Aarch64 or Aarch32 mode. Aarch32
support is enable per-CPU when launching the model, eg:

-C cluster0.cpu0.CONFIG64=0

This patch adds a new defconfig and some variant specific selections in
vexpress_armv8a.h.

This patch is co-authored with Soby Mathew <soby.mat...@arm.com>.

Signed-off-by: Ryan Harkin <ryan.har...@linaro.org>
---

Changes since v1:
This single patch replaces my earlier RFC series of two patches, where
the first modified generic code and the other added a new variant.

After Tom's suggestion that I review the Raspberry PI code, my original
[RFC PATCH 1/2] has been dropped completely.

To address the generic problems from the first patch:
- move CONFIG_REMAKE_ELF to CONFIG_ARM64 only builds in vexpress_aemv8a.h
- define CONFIG_SKIP_LOWLEVEL_INIT for non-ARM64 builds (ie. for CPU_V7)
- the ARMv8 MMU code in vexpress64.h becomes conditiononal on CONFIG_ARM64

I'm not sure if the last change is the correct approach, but it works. I
suspect that at the very least, a rework of the vexpress code would split
this MMU code into an ARM64 specific .c file.

 arch/arm/Kconfig  |  9 +
 board/armltd/vexpress64/Kconfig   |  2 +-
 board/armltd/vexpress64/vexpress64.c  |  4 
 configs/vexpress_aemv8a_aarch32_defconfig | 31 ++
 include/configs/vexpress_aemv8a.h | 32 ---
 5 files changed, 74 insertions(+), 4 deletions(-)
 create mode 100644 configs/vexpress_aemv8a_aarch32_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3d00948..729c31d 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -642,6 +642,15 @@ config TARGET_VEXPRESS64_BASE_FVP
select ARM64
select SEMIHOSTING
 
+config TARGET_VEXPRESS_AEMV8_AARCH32
+   bool "Support Versatile Express ARMv8a 32-bit FVP BASE model booting 
from DRAM"
+   select CPU_V7
+   help
+ This target is derived from TARGET_VEXPRESS64_BASE_FVP and over-rides
+ the default config to allow the user to load the images directly into
+ DRAM using model parameters rather than by using semi-hosting to load
+ the files from the host filesystem.
+
 config TARGET_VEXPRESS64_BASE_FVP_DRAM
bool "Support Versatile Express ARMv8a FVP BASE model booting from DRAM"
select ARM64
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig
index e05f353..06c1ce1 100644
--- a/board/armltd/vexpress64/Kconfig
+++ b/board/armltd/vexpress64/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || 
TARGET_VEXPRESS64_BASE_FVP_DRAM
+if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || 
TARGET_VEXPRESS64_BASE_FVP_DRAM || TARGET_VEXPRESS_AEMV8_AARCH32
 
 config SYS_BOARD
default "vexpress64"
diff --git a/board/armltd/vexpress64/vexpress64.c 
b/board/armltd/vexpress64/vexpress64.c
index 4ddbff9..c1d608d 100644
--- a/board/armltd/vexpress64/vexpress64.c
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -14,7 +14,9 @@
 #include 
 #include 
 #include "pcie.h"
+#ifdef CONFIG_ARM64
 #include 
+#endif
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -29,6 +31,7 @@ U_BOOT_DEVICE(vexpress_serials) = {
.platdata = _platdata,
 };
 
+#ifdef CONFIG_ARM64
 static struct mm_region vexpress64_mem_map[] = {
{
.virt = 0x0UL,
@@ -50,6 +53,7 @@ static struct mm_region vexpress64_mem_map[] = {
 };
 
 struct mm_region *mem_map = vexpress64_mem_map;
+#endif
 
 /* This function gets replaced by platforms supporting PCIe.
  * The replacement function, eg. on Juno, initialises the PCIe bus.
diff --git a/configs/vexpress_aemv8a_aarch32_defconfig 
b/configs/vexpress_aemv8a_aarch32_defconfig
new file mode 100644
index 000..8eb3c77
--- /dev/null
+++ b/configs/vexpress_aemv8a_aarch32_defconfig
@@ -0,0 +1,31 @@
+CONFIG_ARM=y
+CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_IDENT_STRING=" vexpress_aemv8a"
+CONFIG_BOOTDELAY=1
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="VExpress32# "
+CONFIG_CMD_BOOTZ=y
+# CONFIG_CMD_CONSOLE is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_ARMFLASH=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+# CONFIG_CMD_MISC is not set
+CONFIG_CMD_FAT=y
+CONFIG_DM=y
+CONFIG_DM_SERIAL=y
+CONFIG_OF_LIBFDT=y
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index c9841cd..0c69e2e 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -15,13 +15,19 @@

Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Ryan Harkin]

On 5 December 2016 at 15:14, Andre Przywara <andre.przyw...@arm.com> wrote:
> Hi,
>
> On 02/12/16 19:20, Tom Rini wrote:
>> On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote:
>>> On 2 December 2016 at 15:41, Tom Rini <tr...@konsulko.com> wrote:
>>>> On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote:
>>>>
>>>>> I've been working with Soby Mathew to get U-Boot booting on ARM's
>>>>> AEMv8 FVP model in Aarch32 mode.
>>>>>
>>>>> Soby worked out what needed to be changed and I'm refining the changes
>>>>> into patches that can be built for both Aarch64 and Aarch32 mode.
>>>>>
>>>>> There are two patches for discussion:
>>>>>
>>>>> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
>>>>> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
>>>>>
>>>>> I expect the first patch to be controversial.  I also don't expect it to
>>>>> be accepted, but to demonstrate what changes we needed to make to get an
>>>>> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
>>>>> ARM64 as the CPU type.  This in itself may be the wrong approach.
>>>>>
>>>>> It adds an ARMV8_AARCH32 config option and some checks in generic code
>>>>> for that option to allow the code to differentiate between the two
>>>>> modes.
>>>>>
>>>>> The second patch should be less controversial.  It adds support for a
>>>>> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
>>>>> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
>>>>> change based on feedback from patch 1/2.
>>>>>
>>>>> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but
>>>>> takes an extra per-core model launch parameter to switch the cores into
>>>>> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
>>>>
>>>> So my first and slightly ignorant question is, why isn't this just a new
>>>> regular ARMv7 board being added rather than a special cased ARMv8?
>>>>
>>>
>>> That's a valid question.
>>>
>>> I guess it could be either.  At the moment, it's a bit of both.
>>> arch/arm/Kconfig says it's an ARMv7, but then it's added to
>>> board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h.
>>>
>>> But there's no reason it couldn't be added to
>>> board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that
>>> isn't special cased at all.  That approach seems more copy/paste-y
>>> than what I've done in this series, though.
>>>
>>> I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is
>>> confused.  Really, all of these armlt boards are the same with minor
>>> variations, even if the minor variation could be ARMv7 vs ARMv8.
>>
>> Maybe this gets to the heart of the problem then, and we should
>> re-structure and fix this.  If you look in board/raspberrypi/rpi/ we
>> support rpi1 2 and 3, and that includes rpi3 in 64bit mode.
>
> You might also want to take a look at my latest Allwinner A64 series[1].

Thanks, the more ideas the better.

> There I provide two defconfigs: one for "armv8" (aka. AArch64) and one
> for "armv7" (aka AArch32).

I've just reworked my patch based on Tom's feedback and I'm doing
something like this now.  I'll post it for reference as a new RFC.


> The series contains a lot of fixes, but when the code is eventually in
> the correct place, it's merely a matter of "select CPU_V7" vs.
> "select ARM64" to switch between the two architectures [2].
> I think this is mostly due to earlier work from Alex, who moved common
> board support code into arch-agnostic directories[3].
>
> The reason for this exercise in my case is just the SPL, but it actually
> works for the whole of U-Boot: By just changing between the two symbols
> you'll get a complete AArch32 or a complete AArch64 build, which runs on
> the very same board.
>
>> So if we
>> want to re-work board/armlt/vexpress/ to support the various ways the
>> base hardware can be (/ has been over the years), lets.  Does that sound
>> like a plan?
>
> +1, I am very much for cleaning up this slightly convoluted vexpress64 code.
>
> Cheers,
> Andre.
>
> [1] http://lists.denx.de/pipermail/u-boot/2016-December/275288.html
> [2] http://lists.denx.de/pipermail/u-boot/2016-December/275308.html
> [3]
> http://git.denx.de/?p=u-boot.git;a=commitdiff;h=e6e505b93cb3fd264227c65ae1bfc9e4681555d8
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Ryan Harkin]

On 2 Dec 2016 19:20, "Tom Rini" <tr...@konsulko.com> wrote:
>
> On Fri, Dec 02, 2016 at 04:25:37PM +, Ryan Harkin wrote:
> > On 2 December 2016 at 15:41, Tom Rini <tr...@konsulko.com> wrote:
> > > On Fri, Dec 02, 2016 at 11:51:07AM +, Ryan Harkin wrote:
> > >
> > >> I've been working with Soby Mathew to get U-Boot booting on ARM's
> > >> AEMv8 FVP model in Aarch32 mode.
> > >>
> > >> Soby worked out what needed to be changed and I'm refining the
changes
> > >> into patches that can be built for both Aarch64 and Aarch32 mode.
> > >>
> > >> There are two patches for discussion:
> > >>
> > >> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
> > >> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
> > >>
> > >> I expect the first patch to be controversial.  I also don't expect
it to
> > >> be accepted, but to demonstrate what changes we needed to make to
get an
> > >> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead
of
> > >> ARM64 as the CPU type.  This in itself may be the wrong approach.
> > >>
> > >> It adds an ARMV8_AARCH32 config option and some checks in generic
code
> > >> for that option to allow the code to differentiate between the two
> > >> modes.
> > >>
> > >> The second patch should be less controversial.  It adds support for a
> > >> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
> > >> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
> > >> change based on feedback from patch 1/2.
> > >>
> > >> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code,
but
> > >> takes an extra per-core model launch parameter to switch the cores
into
> > >> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
> > >
> > > So my first and slightly ignorant question is, why isn't this just a
new
> > > regular ARMv7 board being added rather than a special cased ARMv8?
> > >
> >
> > That's a valid question.
> >
> > I guess it could be either.  At the moment, it's a bit of both.
> > arch/arm/Kconfig says it's an ARMv7, but then it's added to
> > board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h.
> >
> > But there's no reason it couldn't be added to
> > board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that
> > isn't special cased at all.  That approach seems more copy/paste-y
> > than what I've done in this series, though.
> >
> > I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is
> > confused.  Really, all of these armlt boards are the same with minor
> > variations, even if the minor variation could be ARMv7 vs ARMv8.
>
> Maybe this gets to the heart of the problem then, and we should
> re-structure and fix this.  If you look in board/raspberrypi/rpi/ we
> support rpi1 2 and 3, and that includes rpi3 in 64bit mode.  So if we
> want to re-work board/armlt/vexpress/ to support the various ways the
> base hardware can be (/ has been over the years), lets.  Does that sound
> like a plan?
>

Thanks, yes, it sounds like a great idea.  I haven't looked at the rpi
stuff yes, but I'll check it out next week.

I believe that would only resolve the issues in my 2nd patch, though.
Wouldn't the generic part of using an ARMv8 CPU with the ARMv7 code still
need addressing?  I guess reviewing the rpi3 code will tell me more.

> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Ryan Harkin]

On 2 December 2016 at 15:41, Tom Rini <tr...@konsulko.com> wrote:
> On Fri, Dec 02, 2016 at 11:51:07AM +0000, Ryan Harkin wrote:
>
>> I've been working with Soby Mathew to get U-Boot booting on ARM's
>> AEMv8 FVP model in Aarch32 mode.
>>
>> Soby worked out what needed to be changed and I'm refining the changes
>> into patches that can be built for both Aarch64 and Aarch32 mode.
>>
>> There are two patches for discussion:
>>
>> [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
>> [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant
>>
>> I expect the first patch to be controversial.  I also don't expect it to
>> be accepted, but to demonstrate what changes we needed to make to get an
>> ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
>> ARM64 as the CPU type.  This in itself may be the wrong approach.
>>
>> It adds an ARMV8_AARCH32 config option and some checks in generic code
>> for that option to allow the code to differentiate between the two
>> modes.
>>
>> The second patch should be less controversial.  It adds support for a
>> new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
>> that it defines itself not as ARM64, but as CPU_V7.  I expect this to
>> change based on feedback from patch 1/2.
>>
>> The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but
>> takes an extra per-core model launch parameter to switch the cores into
>> Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
>
> So my first and slightly ignorant question is, why isn't this just a new
> regular ARMv7 board being added rather than a special cased ARMv8?
>

That's a valid question.

I guess it could be either.  At the moment, it's a bit of both.
arch/arm/Kconfig says it's an ARMv7, but then it's added to
board/armltd/vexpress64/Kconfig to re-use vexpress_aemv8a.h.

But there's no reason it couldn't be added to
board/armlt/vexpress/Kconfig and have a copy of vexpress_aemv8a.h that
isn't special cased at all.  That approach seems more copy/paste-y
than what I've done in this series, though.

I think the whole setup for vexpress/vexpress64 and AEMv8/Juno is
confused.  Really, all of these armlt boards are the same with minor
variations, even if the minor variation could be ARMv7 vs ARMv8.

I'd quite like to address that, but I'm unsure how to approach the
problem in the most flexible way.


> --
> Tom
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs

[Ryan Harkin]

This patch hacks some generic code used to allow the ARMv8 platform to
specify if it is booting in Aarch32 mode.

Some ARMv8 CPUs can be run in Aarch32 mode as well as Aarch64.  A good
example of this is ARM's AEMv8 FVP model which models the ARMv8
architecture rather than a specific CPU core.

This patch is co-authored with Soby Mathew <soby.mat...@arm.com>.

Signed-off-by: Ryan Harkin <ryan.har...@linaro.org>
---
 Makefile  | 5 +
 arch/arm/Kconfig  | 6 ++
 arch/arm/cpu/armv7/virt-v7.c  | 2 ++
 arch/arm/cpu/armv8/u-boot-spl.lds | 5 +
 arch/arm/cpu/armv8/u-boot.lds | 5 +
 arch/arm/include/asm/armv8/mmu.h  | 5 +
 6 files changed, 28 insertions(+)

diff --git a/Makefile b/Makefile
index 37cbcb2..b923ef7 100644
--- a/Makefile
+++ b/Makefile
@@ -1182,8 +1182,13 @@ u-boot-img-spl-at-end.bin: u-boot.img spl/u-boot-spl.bin 
FORCE
 # relocation).
 # FIXME refactor dts/Makefile to share target/arch detection
 u-boot.elf: u-boot.bin
+ifeq ($(CONFIG_ARMV8_AARCH32),y)
+   @$(OBJCOPY)  -B arm -I binary -O elf32-littlearm \
+   $< u-boot-elf.o
+else
@$(OBJCOPY)  -B aarch64 -I binary -O elf64-littleaarch64 \
$< u-boot-elf.o
+endif
@$(LD) u-boot-elf.o -o $@ \
--defsym=_start=$(CONFIG_SYS_TEXT_BASE) \
-Ttext=$(CONFIG_SYS_TEXT_BASE)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d7a9b11..6475a21 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -44,6 +44,12 @@ config CPU_ARM1176
select HAS_VBAR
select SYS_CACHE_SHIFT_5
 
+
+config ARMV8_AARCH32
+   bool "some help"
+   help
+ some better help
+
 config CPU_V7
bool
select HAS_VBAR
diff --git a/arch/arm/cpu/armv7/virt-v7.c b/arch/arm/cpu/armv7/virt-v7.c
index d33e5c6..b0f54e3 100644
--- a/arch/arm/cpu/armv7/virt-v7.c
+++ b/arch/arm/cpu/armv7/virt-v7.c
@@ -131,12 +131,14 @@ int armv7_init_nonsec(void)
 * ram, so need to relocate secure section before enabling other
 * cores.
 */
+#ifndef CONFIG_ARMV8_AARCH32
relocate_secure_section();
 
 #ifndef CONFIG_ARMV7_PSCI
smp_set_core_boot_addr((unsigned long)secure_ram_addr(_smp_pen), -1);
smp_kick_all_cpus();
 #endif
+#endif
 
/* call the non-sec switching code on this CPU also */
secure_ram_addr(_nonsec_init)();
diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
b/arch/arm/cpu/armv8/u-boot-spl.lds
index cc427c3..bddfbe6 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -17,8 +17,13 @@ MEMORY { .sram : ORIGIN = CONFIG_SPL_TEXT_BASE,
 MEMORY { .sdram : ORIGIN = CONFIG_SPL_BSS_START_ADDR,
LENGTH = CONFIG_SPL_BSS_MAX_SIZE }
 
+#ifdef CONFIG_ARMV8_AARCH32
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+#else
 OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", 
"elf64-littleaarch64")
 OUTPUT_ARCH(aarch64)
+#endif
 ENTRY(_start)
 SECTIONS
 {
diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds
index fd15ad5..0543458 100644
--- a/arch/arm/cpu/armv8/u-boot.lds
+++ b/arch/arm/cpu/armv8/u-boot.lds
@@ -8,8 +8,13 @@
  * SPDX-License-Identifier:GPL-2.0+
  */
 
+#ifdef CONFIG_ARMV8_AARCH32
+OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
+OUTPUT_ARCH(arm)
+#else
 OUTPUT_FORMAT("elf64-littleaarch64", "elf64-littleaarch64", 
"elf64-littleaarch64")
 OUTPUT_ARCH(aarch64)
+#endif
 ENTRY(_start)
 SECTIONS
 {
diff --git a/arch/arm/include/asm/armv8/mmu.h b/arch/arm/include/asm/armv8/mmu.h
index aa0f3c4..755c517 100644
--- a/arch/arm/include/asm/armv8/mmu.h
+++ b/arch/arm/include/asm/armv8/mmu.h
@@ -77,8 +77,13 @@
 #define PTE_BLOCK_INNER_SHARE  (3 << 8)
 #define PTE_BLOCK_AF   (1 << 10)
 #define PTE_BLOCK_NG   (1 << 11)
+#ifdef CONFIG_ARMV8_AARCH32
+#define PTE_BLOCK_PXN  ((1ULL) << 53)
+#define PTE_BLOCK_UXN  ((1ULL) << 54)
+#else
 #define PTE_BLOCK_PXN  (UL(1) << 53)
 #define PTE_BLOCK_UXN  (UL(1) << 54)
+#endif
 
 /*
  * AttrIndx[2:0]
-- 
1.9.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant

[Ryan Harkin]

The ARM AEMv8 FVP model can be run in Aarch64 or Aarch32 mode. Aarch32
support is enable per-CPU when launching the model, eg:

-C cluster0.cpu0.CONFIG64=0

This patch adds a new defconfig and some variant specific selections in
vexpress_armv8a.h.

This patch is co-authored with Soby Mathew <soby.mat...@arm.com>.

Signed-off-by: Ryan Harkin <ryan.har...@linaro.org>
---
 arch/arm/Kconfig  | 10 ++
 board/armltd/vexpress64/Kconfig   |  2 +-
 configs/vexpress_aemv8a_aarch32_defconfig | 30 ++
 include/configs/vexpress_aemv8a.h | 28 ++--
 4 files changed, 67 insertions(+), 3 deletions(-)
 create mode 100644 configs/vexpress_aemv8a_aarch32_defconfig

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6475a21..59e22aa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -647,6 +647,16 @@ config TARGET_VEXPRESS64_BASE_FVP
select ARM64
select SEMIHOSTING
 
+config TARGET_VEXPRESS_AEMV8_AARCH32
+   bool "Support Versatile Express ARMv8a 32-bit FVP BASE model booting 
from DRAM"
+   select CPU_V7
+   select ARMV8_AARCH32
+   help
+ This target is derived from TARGET_VEXPRESS64_BASE_FVP and over-rides
+ the default config to allow the user to load the images directly into
+ DRAM using model parameters rather than by using semi-hosting to load
+ the files from the host filesystem.
+
 config TARGET_VEXPRESS64_BASE_FVP_DRAM
bool "Support Versatile Express ARMv8a FVP BASE model booting from DRAM"
select ARM64
diff --git a/board/armltd/vexpress64/Kconfig b/board/armltd/vexpress64/Kconfig
index e05f353..06c1ce1 100644
--- a/board/armltd/vexpress64/Kconfig
+++ b/board/armltd/vexpress64/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || 
TARGET_VEXPRESS64_BASE_FVP_DRAM
+if TARGET_VEXPRESS64_BASE_FVP || TARGET_VEXPRESS64_JUNO || 
TARGET_VEXPRESS64_BASE_FVP_DRAM || TARGET_VEXPRESS_AEMV8_AARCH32
 
 config SYS_BOARD
default "vexpress64"
diff --git a/configs/vexpress_aemv8a_aarch32_defconfig 
b/configs/vexpress_aemv8a_aarch32_defconfig
new file mode 100644
index 000..109bae5
--- /dev/null
+++ b/configs/vexpress_aemv8a_aarch32_defconfig
@@ -0,0 +1,30 @@
+CONFIG_ARM=y
+CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_IDENT_STRING=" vexpress_aemv8a"
+CONFIG_BOOTDELAY=1
+# CONFIG_DISPLAY_CPUINFO is not set
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_HUSH_PARSER=y
+CONFIG_SYS_PROMPT="VExpress32# "
+# CONFIG_CMD_CONSOLE is not set
+# CONFIG_CMD_IMLS is not set
+# CONFIG_CMD_XIMG is not set
+# CONFIG_CMD_EDITENV is not set
+# CONFIG_CMD_ENV_EXISTS is not set
+CONFIG_CMD_MEMTEST=y
+# CONFIG_CMD_LOADS is not set
+CONFIG_CMD_ARMFLASH=y
+# CONFIG_CMD_FPGA is not set
+# CONFIG_CMD_ITEST is not set
+# CONFIG_CMD_SETEXPR is not set
+CONFIG_CMD_DHCP=y
+# CONFIG_CMD_NFS is not set
+CONFIG_CMD_MII=y
+CONFIG_CMD_PING=y
+CONFIG_CMD_CACHE=y
+# CONFIG_CMD_MISC is not set
+CONFIG_CMD_FAT=y
+CONFIG_DM=y
+CONFIG_DM_SERIAL=y
+CONFIG_OF_LIBFDT=y
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index c9841cd..5cab39a 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -16,12 +16,17 @@
 #endif
 
 #define CONFIG_REMAKE_ELF
-
 #define CONFIG_SUPPORT_RAW_INITRD
+#ifdef CONFIG_ARMV8_AARCH32
+#define CONFIG_SYS_HZ_CLOCK2400
+#define CONFIG_SYS_ARCH_TIMER
+#define CONFIG_SKIP_LOWLEVEL_INIT
+#endif
 
 /* Link Definitions */
 #if defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP) || \
-   defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM)
+   defined(CONFIG_TARGET_VEXPRESS64_BASE_FVP_DRAM) || \
+   defined(CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32)
 /* ATF loads u-boot here for BASE_FVP model */
 #define CONFIG_SYS_TEXT_BASE   0x8800
 #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x03f0)
@@ -259,6 +264,25 @@
 #define CONFIG_BOOTCOMMAND "booti $kernel_addr $initrd_addr $fdt_addr"
 
 
+#elif CONFIG_TARGET_VEXPRESS_AEMV8_AARCH32
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   "kernel_addr=0x8008\0"  \
+   "initrd_addr=0x8400\0"  \
+   "fdt_addr=0x8200\0" \
+   "fdt_high=0x\0" \
+   "initrd_high=0x\0"
+
+#define CONFIG_BOOTARGS"console=ttyAMA0 earlycon=pl011,"\
+   "0x1c09 debug user_debug=31 "\
+   "systemd.log_target=null "\
+   "androidboot.hardware=fvpbase "\
+   "root=/dev/vda2 rw "\
+

[U-Boot] [RFC PATCH 0/2] ARMv8 Aarch32 support

[Ryan Harkin]

I've been working with Soby Mathew to get U-Boot booting on ARM's
AEMv8 FVP model in Aarch32 mode.

Soby worked out what needed to be changed and I'm refining the changes
into patches that can be built for both Aarch64 and Aarch32 mode.

There are two patches for discussion:

[RFC PATCH 1/2] Add Aarch32 option for ARMv8 CPUs
[RFC PATCH 2/2] Add vexpress_aemv8a_aarch32 variant

I expect the first patch to be controversial.  I also don't expect it to 
be accepted, but to demonstrate what changes we needed to make to get an 
ARMv8 platform to boot in Aarch32 mode when selecting CPU_V7 instead of
ARM64 as the CPU type.  This in itself may be the wrong approach.

It adds an ARMV8_AARCH32 config option and some checks in generic code 
for that option to allow the code to differentiate between the two
modes.

The second patch should be less controversial.  It adds support for a
new AEMv8 variant that runs in 32-bit mode.  The most awkward part is
that it defines itself not as ARM64, but as CPU_V7.  I expect this to
change based on feedback from patch 1/2.

The Aarch32 code runs on the same AEMv8 model as the Aarch64 code, but 
takes an extra per-core model launch parameter to switch the cores into
Aarch32 mode, eg. "-C cluster0.cpu0.CONFIG64=0".
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] vexpress64: Juno: Change PCI buss addresses for IO to start from zero.

[Ryan Harkin]

On 22 November 2016 at 15:08, Tom Rini  wrote:
> On Tue, Nov 22, 2016 at 12:08:49PM +, Liviu Dudau wrote:
>> On Tue, Nov 22, 2016 at 11:29:20AM +, Sudeep Holla wrote:
>> > Hi Liviu,
>> >
>> > On Tue, Nov 22, 2016 at 11:19 AM, Liviu Dudau  
>> > wrote:
>> > > Juno uses a 1:1 mapping between CPU and PCI addresses for IO. First,
>> > > that will trip devices that cannot use more than 16 bits of addresses
>> > > for IO, second it is un-necessary as the system can handle zero-based
>> > > PCI addresses just fine.
>> > >
>> > > Change the mapping to start IO bus addresses from zero.
>> > >
>> >
>> > I assume this require corresponding DT change, shout if that's not true.
>> > If that's true, then does this patch not require patching of DT so
>> > that systems not
>> > running Uboot with this patch continue to work and we retain the
>> > mainline DT as is ?
>>
>> Yes, it does require DT changes, Jeremy Linton has a patch
>
> So to be clear, what level of coordination do we need between the two
> parts being merged?  It would not be ideal to have combinations of
> U-Boot and Linux not work.  Thanks!
>

I was wondering that too.

However, I just tested the patch in my setup and everything still
seems to work for me.  I'll admit though that I only use the PCIe
network port, I don't have any extra PCIe devices and don't use SATA
drives in my setup.


> --
> Tom
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot