Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
Hi Simon, Andy, On Thu, Apr 2, 2020 at 1:55 AM Simon Glass wrote: > > Hi Andy, > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko > wrote: > > > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote: > > > Hi Andy, > > > > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko > > > wrote: > > > > > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng wrote: > > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko > > > > > wrote: > > > > > > > > > > > > The commit breaks serial console on the Intel Edison. > > > > > > > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > > > > > > > > > > > Signed-off-by: Andy Shevchenko > > > > > > --- > > > > > > drivers/serial/ns16550.c | 40 > > > > > > > > > > > > 1 file changed, 12 insertions(+), 28 deletions(-) > > > > > > > > > > > > > > > > Could you please spend some time to investigate why this breaks Intel > > > > > Edison? > > > > > > > > > > Reverting this patch would mean we break other boards too as > > > > > Wolfgang's patch wanted to fix the breakage in the first place. Much > > > > > appreciated! > > > > > > > > I guess I'm wrong person here. The DM code is a complete black box to > > > > me. > > > > Nevertheless, I may test any provided fix / debug / etc patch by > > > > request. > > > > > > > > And I think it's fair to investigate by the one who made a regression > > > > in the first place. > > > > > > Given that we have conflicting breakages, we need to debug Edison. > > > > I would glad to test any suggested change or debug patch! > > > > > Does it enable the debug UART? > > > > If I am not mistaken, it does not. > > Looks like you are right. If you know the address you could do that - > see minnowmax for an example. Please suggest what's the best approach to proceed. Regards, Bin
[PATCH v1 1/1] phy: add support for stingray PAXB PHY controller
From: Srinath Mannam
Add support for stingray PAXB PHY controller driver.
This driver supports maximum 8 PAXB phys using pipemux data.
Signed-off-by: Srinath Mannam
Signed-off-by: Rayagonda Kokatanur
---
drivers/phy/Kconfig | 7 ++
drivers/phy/Makefile | 1 +
drivers/phy/phy-bcm-sr-pcie.c | 180 ++
3 files changed, 188 insertions(+)
create mode 100644 drivers/phy/phy-bcm-sr-pcie.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index a72f34f0d4..f7003807fc 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -84,6 +84,13 @@ config BCM6368_USBH_PHY
help
Support for the Broadcom MIPS BCM6368 USBH PHY.
+config BCM_SR_PCIE_PHY
+ bool "Broadcom Stingray PCIe PHY driver"
+ depends on PHY
+ help
+ Enable this to support the Broadcom Stingray PCIe PHY
+ If unsure, say N.
+
config PHY_DA8XX_USB
tristate "TI DA8xx USB PHY Driver"
depends on PHY && ARCH_DAVINCI
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 43ce62e08c..3958f7899c 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_BCM6318_USBH_PHY) += bcm6318-usbh-phy.o
obj-$(CONFIG_BCM6348_USBH_PHY) += bcm6348-usbh-phy.o
obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
obj-$(CONFIG_BCM6368_USBH_PHY) += bcm6368-usbh-phy.o
+obj-$(CONFIG_BCM_SR_PCIE_PHY) += phy-bcm-sr-pcie.o
obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o
obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o
obj-$(CONFIG_AM654_PHY) += phy-ti-am654.o
diff --git a/drivers/phy/phy-bcm-sr-pcie.c b/drivers/phy/phy-bcm-sr-pcie.c
new file mode 100644
index 00..6c932f6478
--- /dev/null
+++ b/drivers/phy/phy-bcm-sr-pcie.c
@@ -0,0 +1,180 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Broadcom
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* we have up to 8 PAXB based RC. The 9th one is always PAXC */
+#define SR_NR_PCIE_PHYS 8
+
+#define PCIE_PIPEMUX_CFG_OFFSET 0x10c
+#define PCIE_PIPEMUX_SELECT_STRAP 0xf
+
+#define CDRU_STRAP_DATA_LSW_OFFSET0x5c
+#define PCIE_PIPEMUX_SHIFT19
+#define PCIE_PIPEMUX_MASK 0xf
+
+struct sr_pcie_phy_core;
+
+/**
+ * struct sr_pcie_phy_core - Stingray PCIe PHY core control
+ *
+ * @dev: pointer to device
+ * @base: base register of PCIe SS
+ * @cdru: CDRU base address
+ * @pipemux: pipemuex strap
+ */
+struct sr_pcie_phy_core {
+ struct udevice *dev;
+ void __iomem *base;
+ void __iomem *cdru;
+ u32 pipemux;
+};
+
+/*
+ * PCIe PIPEMUX lookup table
+ *
+ * Each array index represents a PIPEMUX strap setting
+ * The array element represents a bitmap where a set bit means the PCIe
+ * core and associated serdes has been enabled as RC and is available for use
+ */
+static const u8 pipemux_table[] = {
+ /* PIPEMUX = 0, EP 1x16 */
+ 0x00,
+ /* PIPEMUX = 1, EP 1x8 + RC 1x8, core 7 */
+ 0x80,
+ /* PIPEMUX = 2, EP 4x4 */
+ 0x00,
+ /* PIPEMUX = 3, RC 2x8, cores 0, 7 */
+ 0x81,
+ /* PIPEMUX = 4, RC 4x4, cores 0, 1, 6, 7 */
+ 0xc3,
+ /* PIPEMUX = 5, RC 8x2, all 8 cores */
+ 0xff,
+ /* PIPEMUX = 6, RC 3x4 + 2x2, cores 0, 2, 3, 6, 7 */
+ 0xcd,
+ /* PIPEMUX = 7, RC 1x4 + 6x2, cores 0, 2, 3, 4, 5, 6, 7 */
+ 0xfd,
+ /* PIPEMUX = 8, EP 1x8 + RC 4x2, cores 4, 5, 6, 7 */
+ 0xf0,
+ /* PIPEMUX = 9, EP 1x8 + RC 2x4, cores 6, 7 */
+ 0xc0,
+ /* PIPEMUX = 10, EP 2x4 + RC 2x4, cores 1, 6 */
+ 0x42,
+ /* PIPEMUX = 11, EP 2x4 + RC 4x2, cores 2, 3, 4, 5 */
+ 0x3c,
+ /* PIPEMUX = 12, EP 1x4 + RC 6x2, cores 2, 3, 4, 5, 6, 7 */
+ 0xfc,
+ /* PIPEMUX = 13, RC 2x4 + RC 1x4 + 2x2, cores 2, 3, 6 */
+ 0x4c,
+};
+
+/*
+ * Return true if the strap setting is valid
+ */
+static bool pipemux_strap_is_valid(u32 pipemux)
+{
+ return !!(pipemux < ARRAY_SIZE(pipemux_table));
+}
+
+/*
+ * Read the PCIe PIPEMUX from strap
+ */
+static u32 pipemux_strap_read(struct sr_pcie_phy_core *core)
+{
+ u32 pipemux;
+
+ /*
+* Read PIPEMUX configuration register to determine the pipemux setting
+*
+* In the case when the value indicates using HW strap, fall back to
+* use HW strap
+*/
+ pipemux = readl(core->base + PCIE_PIPEMUX_CFG_OFFSET);
+ pipemux &= PCIE_PIPEMUX_MASK;
+ if (pipemux == PCIE_PIPEMUX_SELECT_STRAP) {
+ pipemux = readl(core->cdru + CDRU_STRAP_DATA_LSW_OFFSET);
+ pipemux >>= PCIE_PIPEMUX_SHIFT;
+ pipemux &= PCIE_PIPEMUX_MASK;
+ }
+
+ return pipemux;
+}
+
+static int sr_pcie_phy_init(struct phy *phy)
+{
+ struct sr_pcie_phy_core *core = dev_get_priv(phy->dev);
+ unsigned int core_idx = phy->id;
+
+ debug("%s %lx\n", __func__, phy->id);
+ /*
+* Check whether this PHY is for root complex
RE: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function
> On 4/2/20 4:34 AM, Simon Glass wrote: > > Hi, > > > > On Tue, 31 Mar 2020 at 20:33, Ang, Chee Hong > wrote: > >> > >>> Hi Marek, > >>> > >>> On Wed, 11 Mar 2020 at 05:55, Marek Vasut wrote: > > On 3/11/20 12:50 PM, Simon Glass wrote: > > Hi, > > Hi, > > > On Mon, 9 Mar 2020 at 02:22, wrote: > >> > >> From: Chee Hong Ang > >> > >> This commit (82de42fa14682d408da935adfb0f935354c5008f) calls > >> child's > >> ofdata_to_platdata() method before the parent is probed in dm core. > >> This has caused the driver no longer able to get the correct > >> parent clock's register base in the ofdata_to_platdata() method > >> because the parent clocks will only be probed after the child's > ofdata_to_platdata(). > >> To resolve this, the clock parent's register base will only be > >> retrieved by the child in probe() method instead of > >> ofdata_to_platdata(). > > > > I think one thing that is going on here is that DM allows ofdata > > to be read for a device before its parent devices have been read, > > but it requires that parent devices be probed before their children. > > This seems wrong. The clock driver should be able to instantiate > devices and read their ofdata without probing them. That is one of > the core design principles of the DM. > >>> > >>> That's a different question. Yes you can read ofdata without probing a > device. > >>> That's why we have two methods. > >>> > >>> The point I am making is that at present there is no requirement > >>> that a parent's ofdata be read before a child's ofdata is read. But > >>> there is a requirement that a parent be probed before a child is probed. > >>> > > > The idea is that it should be possible to read the ofdata for a > > node without needing to have done so for parents. But perhaps this > > assumption is too brave? > > Why is it brave ? That's how it always was, the DT is already > there, so why wouldn't you be able to read it. > >>> > >>> That was my thinking too. But we are finding in a few situations > >>> that the child's ofdata depends on the parent's. For example, the > >>> parent may have a base address, or a range mapping, or something > >>> else that is needed for the child to correctly get its base address, etc. > >>> > > > I suspect we could change this, so that > > device_ofdata_to_platdata() first calls itself on its parent. > > > > I can think of various reasons why this change might be desirable. > > I think this is how it worked before already. > >>> > >>> Well effectively, yes, because ofdata and probe were joined together. > > > >> Simon, do you have plan to fix this DM core issue ? > > > > I'm not sure it definitely should be changed. But I'll do a patch and > > see how it looks. > > Do I understand it correctly that the patch > 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks > SoCFPGA ? Then I would say this is a release blocker ? Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.
Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function
On 4/2/20 4:34 AM, Simon Glass wrote: > Hi, > > On Tue, 31 Mar 2020 at 20:33, Ang, Chee Hong wrote: >> >>> Hi Marek, >>> >>> On Wed, 11 Mar 2020 at 05:55, Marek Vasut wrote: On 3/11/20 12:50 PM, Simon Glass wrote: > Hi, Hi, > On Mon, 9 Mar 2020 at 02:22, wrote: >> >> From: Chee Hong Ang >> >> This commit (82de42fa14682d408da935adfb0f935354c5008f) calls >> child's >> ofdata_to_platdata() method before the parent is probed in dm core. >> This has caused the driver no longer able to get the correct parent >> clock's register base in the ofdata_to_platdata() method because >> the parent clocks will only be probed after the child's >> ofdata_to_platdata(). >> To resolve this, the clock parent's register base will only be >> retrieved by the child in probe() method instead of ofdata_to_platdata(). > > I think one thing that is going on here is that DM allows ofdata to > be read for a device before its parent devices have been read, but > it requires that parent devices be probed before their children. This seems wrong. The clock driver should be able to instantiate devices and read their ofdata without probing them. That is one of the core design principles of the DM. >>> >>> That's a different question. Yes you can read ofdata without probing a >>> device. >>> That's why we have two methods. >>> >>> The point I am making is that at present there is no requirement that a >>> parent's >>> ofdata be read before a child's ofdata is read. But there is a requirement >>> that a >>> parent be probed before a child is probed. >>> > The idea is that it should be possible to read the ofdata for a node > without needing to have done so for parents. But perhaps this > assumption is too brave? Why is it brave ? That's how it always was, the DT is already there, so why wouldn't you be able to read it. >>> >>> That was my thinking too. But we are finding in a few situations that the >>> child's >>> ofdata depends on the parent's. For example, the parent may have a base >>> address, or a range mapping, or something else that is needed for the child >>> to >>> correctly get its base address, etc. >>> > I suspect we could change this, so that device_ofdata_to_platdata() > first calls itself on its parent. > > I can think of various reasons why this change might be desirable. I think this is how it worked before already. >>> >>> Well effectively, yes, because ofdata and probe were joined together. > >> Simon, do you have plan to fix this DM core issue ? > > I'm not sure it definitely should be changed. But I'll do a patch and > see how it looks. Do I understand it correctly that the patch 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks SoCFPGA ? Then I would say this is a release blocker ?
Re: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function
Hi, On Tue, 31 Mar 2020 at 20:33, Ang, Chee Hong wrote: > > > Hi Marek, > > > > On Wed, 11 Mar 2020 at 05:55, Marek Vasut wrote: > > > > > > On 3/11/20 12:50 PM, Simon Glass wrote: > > > > Hi, > > > > > > Hi, > > > > > > > On Mon, 9 Mar 2020 at 02:22, wrote: > > > >> > > > >> From: Chee Hong Ang > > > >> > > > >> This commit (82de42fa14682d408da935adfb0f935354c5008f) calls > > > >> child's > > > >> ofdata_to_platdata() method before the parent is probed in dm core. > > > >> This has caused the driver no longer able to get the correct parent > > > >> clock's register base in the ofdata_to_platdata() method because > > > >> the parent clocks will only be probed after the child's > > > >> ofdata_to_platdata(). > > > >> To resolve this, the clock parent's register base will only be > > > >> retrieved by the child in probe() method instead of > > > >> ofdata_to_platdata(). > > > > > > > > I think one thing that is going on here is that DM allows ofdata to > > > > be read for a device before its parent devices have been read, but > > > > it requires that parent devices be probed before their children. > > > > > > This seems wrong. The clock driver should be able to instantiate > > > devices and read their ofdata without probing them. That is one of the > > > core design principles of the DM. > > > > That's a different question. Yes you can read ofdata without probing a > > device. > > That's why we have two methods. > > > > The point I am making is that at present there is no requirement that a > > parent's > > ofdata be read before a child's ofdata is read. But there is a requirement > > that a > > parent be probed before a child is probed. > > > > > > > > > The idea is that it should be possible to read the ofdata for a node > > > > without needing to have done so for parents. But perhaps this > > > > assumption is too brave? > > > > > > Why is it brave ? That's how it always was, the DT is already there, > > > so why wouldn't you be able to read it. > > > > That was my thinking too. But we are finding in a few situations that the > > child's > > ofdata depends on the parent's. For example, the parent may have a base > > address, or a range mapping, or something else that is needed for the child > > to > > correctly get its base address, etc. > > > > > > > > > I suspect we could change this, so that device_ofdata_to_platdata() > > > > first calls itself on its parent. > > > > > > > > I can think of various reasons why this change might be desirable. > > > > > > I think this is how it worked before already. > > > > Well effectively, yes, because ofdata and probe were joined together. > Simon, do you have plan to fix this DM core issue ? I'm not sure it definitely should be changed. But I'll do a patch and see how it looks. Regards, Simon
Re: [PATCH] fdtdec: support multiple phandles in memory carveout
Hi, On Tue, 31 Mar 2020 at 07:16, Laurentiu Tudor wrote: > > fdtdec_set_carveout() is limited to only one phandle. Fix this > limitation by adding support for multiple phandles. > > Signed-off-by: Laurentiu Tudor > --- > lib/fdtdec.c | 36 ++-- > 1 file changed, 26 insertions(+), 10 deletions(-) > Please can you add a test for this function? You could put it in test/dm/fdtdec.c - see ofnode.c for an example. Regards, Simon
Re: [PATCH 2/2] mmc: t210: Fix 'bad' SD-card clock when doing 400KHz card detect
On 3/27/20 7:30 AM, tomcwarren3...@gmail.com wrote:
> From: Tom Warren
>
> According to the HW team, for some reason the normal clock select code
> picks what appears to be a perfectly valid 375KHz SD card clock, based
> on the CAR clock source and SDMMC1 controller register settings (CAR =
> 408MHz PLLP0 divided by 68 for 6MHz, then a SD Clock Control register
> divisor of 16 = 375KHz). But the resulting SD card clock, as measured by
> the HW team, is 700KHz, which is out-of-spec. So the WAR is to use the
> values given in the TRM PLLP table to generate a 400KHz SD-clock (CAR
> clock of 24.7MHz, SD Clock Control divisor of 62) only for SDMMC1 on
> T210 when the requested clock is <= 400KHz. Note that as far as I can
> tell, the other requests for clocks in the Tegra MMC driver result in
> valid SD clocks.
>
> Signed-off-by: Tom Warren
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Changes for v2:
> - None
>
> arch/arm/include/asm/arch-tegra/tegra_mmc.h | 2 +-
> drivers/mmc/tegra_mmc.c | 18 ++
> 2 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
> b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
> index a8bfa46..70dcf4a 100644
> --- a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
> +++ b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
> @@ -130,9 +130,9 @@ struct tegra_mmc {
> /* SDMMC1/3 settings from SDMMCx Initialization Sequence of TRM */
> #define MEMCOMP_PADCTRL_VREF 7
> #define AUTO_CAL_ENABLE (1 << 29)
> -#if defined(CONFIG_TEGRA210)
> #define AUTO_CAL_ACTIVE (1 << 31)
> #define AUTO_CAL_START (1 << 31)
> +#if defined(CONFIG_TEGRA210)
> #define AUTO_CAL_PD_OFFSET (0x7D << 8)
> #define AUTO_CAL_PU_OFFSET (0 << 0)
> #define IO_TRIM_BYPASS_MASK (1 << 2)
> diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
> index 73ac58c..03110ba 100644
> --- a/drivers/mmc/tegra_mmc.c
> +++ b/drivers/mmc/tegra_mmc.c
> @@ -376,6 +376,24 @@ static void tegra_mmc_change_clock(struct tegra_mmc_priv
> *priv, uint clock)
>
> rate = clk_set_rate(>clk, clock);
> div = (rate + clock - 1) / clock;
> +
> +#if defined(CONFIG_TEGRA210)
> + if (priv->mmc_id == PERIPH_ID_SDMMC1 && clock <= 40) {
> + /* clock_adjust_periph_pll_div() chooses a 'bad' clock
> + * on SDMMC1 T210, so skip it here and force a clock
> + * that's been spec'd in the table in the TRM for
> + * card-detect (400KHz).
> + */
> + uint effective_rate = clock_adjust_periph_pll_div(priv->mmc_id,
> + CLOCK_ID_PERIPH, 24727273, NULL);
> + div = 62;
> +
> + debug("%s: WAR: Using SDMMC1 clock of %u, div %d to achieve
> %dHz card clock ...\n",
> + __func__, effective_rate, div, clock);
> + } else
> + clock_adjust_periph_pll_div(priv->mmc_id, CLOCK_ID_PERIPH,
> clock,
> + );
> +#endif
> debug("div = %d\n", div);
>
> writew(0, >reg->clkcon);
>
Re: [PATCH 1/2] mmc: t210: Add autocal and tap/trim updates for SDMMC1/3
Hi Tom,
On 3/27/20 7:30 AM, tomcwarren3...@gmail.com wrote:
> From: Tom Warren
>
> As per the T210 TRM, when running at 3.3v, the SDMMC1 tap/trim and
> autocal values need to be set to condition the signals correctly before
> talking to the SD-card. This is the same as what's being done in CBoot,
> but it gets reset when the SDMMC1 HW is soft-reset during SD driver
> init, so needs to be repeated here. Also set autocal and tap/trim for
> SDMMC3, although no T210 boards use it for SD-card at this time.
>
> Signed-off-by: Tom Warren
Reviewed-by: Jaehoon Chung
Best Regards,
Jaehoon Chung
> ---
> Changes for v2:
> - Added clocks.h include for TEGRA30 to fix T30 32-bit builds
>
> arch/arm/include/asm/arch-tegra/tegra_mmc.h | 20 +--
> drivers/mmc/tegra_mmc.c | 84
> ++---
> 2 files changed, 92 insertions(+), 12 deletions(-)
>
> diff --git a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
> b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
> index a2b6f63..a8bfa46 100644
> --- a/arch/arm/include/asm/arch-tegra/tegra_mmc.h
> +++ b/arch/arm/include/asm/arch-tegra/tegra_mmc.h
> @@ -2,7 +2,7 @@
> /*
> * (C) Copyright 2009 SAMSUNG Electronics
> * Minkyu Kang
> - * Portions Copyright (C) 2011-2012 NVIDIA Corporation
> + * Portions Copyright (C) 2011-2012,2019 NVIDIA Corporation
> */
>
> #ifndef __TEGRA_MMC_H_
> @@ -52,7 +52,7 @@ struct tegra_mmc {
> unsigned char admaerr;/* offset 54h */
> unsigned char res4[3];/* RESERVED, offset 55h-57h */
> unsigned long admaaddr; /* offset 58h-5Fh */
> - unsigned char res5[0xa0]; /* RESERVED, offset 60h-FBh */
> + unsigned char res5[0x9c]; /* RESERVED, offset 60h-FBh */
> unsigned short slotintstatus; /* offset FCh */
> unsigned short hcver; /* HOST Version */
> unsigned intvenclkctl; /* _VENDOR_CLOCK_CNTRL_0,100h */
> @@ -127,11 +127,23 @@ struct tegra_mmc {
>
> #define TEGRA_MMC_NORINTSIGEN_XFER_COMPLETE (1 << 1)
>
> -/* SDMMC1/3 settings from section 24.6 of T30 TRM */
> +/* SDMMC1/3 settings from SDMMCx Initialization Sequence of TRM */
> #define MEMCOMP_PADCTRL_VREF 7
> -#define AUTO_CAL_ENABLED (1 << 29)
> +#define AUTO_CAL_ENABLE (1 << 29)
> +#if defined(CONFIG_TEGRA210)
> +#define AUTO_CAL_ACTIVE (1 << 31)
> +#define AUTO_CAL_START (1 << 31)
> +#define AUTO_CAL_PD_OFFSET (0x7D << 8)
> +#define AUTO_CAL_PU_OFFSET (0 << 0)
> +#define IO_TRIM_BYPASS_MASK (1 << 2)
> +#define TRIM_VAL_SHIFT 24
> +#define TRIM_VAL_MASK(0x1F << TRIM_VAL_SHIFT)
> +#define TAP_VAL_SHIFT16
> +#define TAP_VAL_MASK (0xFF << TAP_VAL_SHIFT)
> +#else
> #define AUTO_CAL_PD_OFFSET (0x70 << 8)
> #define AUTO_CAL_PU_OFFSET (0x62 << 0)
> +#endif
>
> #endif /* __ASSEMBLY__ */
> #endif /* __TEGRA_MMC_H_ */
> diff --git a/drivers/mmc/tegra_mmc.c b/drivers/mmc/tegra_mmc.c
> index f022e93..73ac58c 100644
> --- a/drivers/mmc/tegra_mmc.c
> +++ b/drivers/mmc/tegra_mmc.c
> @@ -3,7 +3,7 @@
> * (C) Copyright 2009 SAMSUNG Electronics
> * Minkyu Kang
> * Jaehoon Chung
> - * Portions Copyright 2011-2016 NVIDIA Corporation
> + * Portions Copyright 2011-2019 NVIDIA Corporation
> */
>
> #include
> @@ -15,6 +15,9 @@
> #include
> #include
> #include
> +#if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA210)
> +#include
> +#endif
>
> struct tegra_mmc_plat {
> struct mmc_config cfg;
> @@ -30,6 +33,7 @@ struct tegra_mmc_priv {
> struct gpio_desc wp_gpio; /* Write Protect GPIO */
> unsigned int version; /* SDHCI spec. version */
> unsigned int clock; /* Current clock (MHz) */
> + int mmc_id; /* peripheral id */
> };
>
> static void tegra_mmc_set_power(struct tegra_mmc_priv *priv,
> @@ -446,16 +450,19 @@ static int tegra_mmc_set_ios(struct udevice *dev)
>
> static void tegra_mmc_pad_init(struct tegra_mmc_priv *priv)
> {
> -#if defined(CONFIG_TEGRA30)
> +#if defined(CONFIG_TEGRA30) || defined(CONFIG_TEGRA210)
> u32 val;
> + u16 clk_con;
> + int timeout;
> + int id = priv->mmc_id;
>
> - debug("%s: sdmmc address = %08x\n", __func__, (unsigned int)priv->reg);
> + debug("%s: sdmmc address = %p, id = %d\n", __func__,
> + priv->reg, id);
>
> /* Set the pad drive strength for SDMMC1 or 3 only */
> - if (priv->reg != (void *)0x7800 &&
> - priv->reg != (void *)0x78000400) {
> + if (id != PERIPH_ID_SDMMC1 && id != PERIPH_ID_SDMMC3) {
> debug("%s: settings are only valid for SDMMC1/SDMMC3!\n",
> - __func__);
> + __func__);
> return;
> }
>
> @@ -464,11 +471,65 @@ static void tegra_mmc_pad_init(struct tegra_mmc_priv
> *priv)
> val |= MEMCOMP_PADCTRL_VREF;
> writel(val, >reg->sdmemcmppadctl);
Re: [PATCH 09/16] efi_loader: imply FAT, FAT_WRITE
Hi Mark, On Wed, Apr 01, 2020 at 07:56:31PM +0200, Mark Kettenis wrote: > > Date: Wed, 1 Apr 2020 09:31:03 +0900 > > From: AKASHI Takahiro > > > > On Tue, Mar 31, 2020 at 10:20:17AM +0200, Mark Kettenis wrote: > > > > Date: Tue, 31 Mar 2020 16:44:34 +0900 > > > > From: AKASHI Takahiro > > > > > > > > On Tue, Mar 31, 2020 at 08:44:02AM +0200, Heinrich Schuchardt wrote: > > > > > On March 31, 2020, 5:28 a.m. UTC Takahiro Akashi wrote: > > > > > > On Fri, Mar 27, 2020 at 06:27:53AM +0100, Heinrich Schuchardt wrote: > > > > > > > The UEFI spec requires support for the FAT file system. > > > > > > > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > > > > --- > > > > > > > lib/efi_loader/Kconfig | 2 ++ > > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > > index 9890144d41..e10ca05549 100644 > > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > > @@ -15,6 +15,8 @@ config EFI_LOADER > > > > > > > select HAVE_BLOCK_DEVICE > > > > > > > select REGEX > > > > > > > imply CFB_CONSOLE_ANSI > > > > > > > + imply FAT > > > > > > > + imply FAT_WRITE > > > > > > > > > > > > Obviously, this *imply* doesn't enforce enabling FAT. > > > > > > If it is absolutely necessary, another measure should be taken. > > > > > > > > > > If somebody wants to minimize the U-Boot size it might be necessary to > > > > > do without FAT_WRITE or FAT support. > > > > > > > > If so, Get/SetVariable won't be supported even in boot time > > > > with your patch applied. It is not practical for almost all users. > > > > > > I *strongly* disagree with that statement. Most users don't care > > > about U-Boot providing a full EFI implementation. They just want to > > > boot their OS. The basic EFI support in U-Boot is good enough for > > > that and for OpenBSD and some Linux distros on arm/arm64 this is the > > > only bootpath that works. If adding more code leads to board > > > maintainers disabling EFI support this isn't helpful. > > > > Okay, so can you please describe the minimum set of functionality > > for you? Without that, the discussion will not be fair. > > For OpenBSD/arm and OpenBSD/amr64 we adopted the UEFI interfaces in > u-boot early on, even before most Linux distros did. As a result our > requirements are very minimal: Thank you for your quick feedback. As I'm not familiar with OpenBSD things, this information gives me much better view/understandings. Just from my curiosity, let me ask some questions. > Our bootloader uses the folowing boot services: You don't reply on any features from "EFI Boot Manager," including Boot variables, do you? > - HandleProtocol() > - AllocatePages() > - FreePages() > - LocateHandle() > - LocateHandleBuffer() > - LocateProtocol() > - CreateEvent() > - SetTimer() > - WaitForEvent() > - CloseEvent() > - GetMemoryMap() > - SetWatchdogTimer() > - Exit() > > runtime services: + load_image/start_image, obviously? > - ResetSystem() > > and protocols: > > - EFI_LOADED_IMAGE_PROTOCOL > - EFI_DEVICE_PATH_PROTOCOL > - EFI_BLOCK_IO_PROTOCOL > - EFI_GRAPHICS_OUTPUT_PROTOCOL > - EFI_RNG_PROTOCOL > - EFI_SIMPLE_NETWORK_PROTOCOL > - EFI_PXE_BASE_CODE_PROTOCOL What about EFI_FILE_PROTOCOL and/or EFI_FILE_LOAD_PROTOCOL? Don't you have the assumption that there must be any EFI system partition (and file system) on your boards? -Takahiro Akashi > Obviously the last four are only used if there is actual hardware to > support these protocols. But I'd consider them non-optional if such > hardware exists. > > Our kernel only uses a couple if runtime services: > > - SetVirtualAddressMap() > - GetTime() (optional) > - SetTime() (optional) As you might know, I'm working on UEFI secure boot for U-Boot. Does OpenBSD support any kind of secure boot? If so, is it based on UEFI feature (in that case, UEFI variables are mandatory) or do you have your own solution? Thanks, -Takahiro Akashi > Cheers, > > Mark
RE: iMX8MM USB support?
Hi Igor, I’m sorry, now I don’t do the jobs about USB any more. Maybe Peng know who can help you. Best regards Sherry Sun From: Igor Opaniuk Sent: 2020年4月2日 5:35 To: Sherry Sun Cc: u-boot ; Fabio Estevam ; Peng Fan ; thar...@gateworks.com Subject: Re: iMX8MM USB support? + Sherry, as he was working on iMX8* USB support On Wed, Apr 1, 2020, 20:55 Tim Harvey mailto:thar...@gateworks.com>> wrote: Peng, It looks like IMX8MM USB support hasn't made it upstream yet. Is this something your working on? I'm interested in booting an IMX8MM via SDP. Best Regards, Tim
Re: Please pull u-boot-dm
On Wed, Apr 01, 2020 at 09:03:53AM -0600, Simon Glass wrote: > Hi Tom, > > I ran a check yesterday but have started a new one after rebasing today: > > https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2598 > > > The following changes since commit 7dbafe06348ebf28044ef9769bf24866a3deedea: > > Merge tag 'arc-last-minute-fixes-for-2020.04' of > https://gitlab.denx.de/u-boot/custodians/u-boot-arc (2020-03-31 > 15:10:54 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-dm.git tags/dm-pull-1apr20 > > for you to fetch changes up to 0e29648f8e7e0aa60c0f7efe9d2efed98f8c0c6e: > > test: vboot: Reduce fake kernel size to 500 bytes (2020-04-01 07:45:09 > -0600) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
[PATCH 2/2] arm: tegra: add options for BOOTENV_EFI_SET_FDTFILE_FALLBACK for tegra186
Upstream linux DT naming doesn't align with the U-Boot DT, which may
not always be the case so this allows using BOOTENV_EFI_SET_FDTFILE_FALLBACK
where it might be appropriate for some boards.
Signed-off-by: Peter Robinson
---
This is a bit of a hack for the Jetson TX2 because the U-Boot config
using a different naming for the DT naming to upstream Linux, I'm not
sure what naming L4T uses, and whether the 000/500 variants are widely
enough available or whether they use differnet DTs in L4T.
Welcome to suggestions of a better way to fix this one but it works
for booting the TX2 on Fedora using UEFI..
include/config_distro_bootcmd.h | 2 ++
include/configs/tegra186-common.h | 7 ++-
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h
index fc0935fa21..fd1c5f5afa 100644
--- a/include/config_distro_bootcmd.h
+++ b/include/config_distro_bootcmd.h
@@ -118,8 +118,10 @@
"setenv efi_fdtfile ${soc}-${board}${boardver}.dtb; " \
"fi; "
#else
+#ifndef BOOTENV_EFI_SET_FDTFILE_FALLBACK
#define BOOTENV_EFI_SET_FDTFILE_FALLBACK
#endif
+#endif
#define BOOTENV_SHARED_EFI\
diff --git a/include/configs/tegra186-common.h
b/include/configs/tegra186-common.h
index 5c3ad35c76..d5f21e0907 100644
--- a/include/configs/tegra186-common.h
+++ b/include/configs/tegra186-common.h
@@ -20,6 +20,12 @@
/* Generic Interrupt Controller */
#define CONFIG_GICV2
+#undef FDTFILE
+#define BOOTENV_EFI_SET_FDTFILE_FALLBACK \
+"if test -z \"${fdtfile}\" -a -n \"${soc}\"; then " \
+ "setenv efi_fdtfile ${vendor}/${soc}-${board}${boardver}.dtb; "
\
+"fi; "
+
/*
* Memory layout for where various images get loaded by boot scripts:
*
@@ -49,7 +55,6 @@
"scriptaddr=0x9000\0" \
"pxefile_addr_r=0x9010\0" \
"kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \
- "fdtfile=" FDTFILE "\0" \
"fdt_addr_r=0x8200\0" \
"ramdisk_addr_r=0x8210\0"
--
2.26.0
[PATCH 1/2] arm: tegra: define fdtfile option for distro boot
For booting via UEFI we need to define the fdtfile option so bootefi has the option to load a fdtfile from disk. For arm64 the kernel dtb is located in a vendor directory so we define that as nvidia for that architecture. Signed-off-by: Peter Robinson --- Without this the aarch64 tegra devices don't find the kernel device tree when booting using UEFI so fall back to the firmware DT in U-Boot which alone isn't enough to boot the Linux kernel and you end up with a boot failure in very early boot due to being unable to find the architecture timer. This fixes the issue when booting Fedora using UEFI for me. include/configs/tegra-common.h| 6 ++ include/configs/tegra114-common.h | 1 + include/configs/tegra124-common.h | 1 + include/configs/tegra186-common.h | 1 + include/configs/tegra20-common.h | 1 + include/configs/tegra210-common.h | 1 + include/configs/tegra30-common.h | 1 + 7 files changed, 12 insertions(+) diff --git a/include/configs/tegra-common.h b/include/configs/tegra-common.h index f2cdd9c019..997b50394b 100644 --- a/include/configs/tegra-common.h +++ b/include/configs/tegra-common.h @@ -55,6 +55,12 @@ #define CONFIG_SYS_MEMTEST_START (NV_PA_SDRC_CS0 + 0x60) #define CONFIG_SYS_MEMTEST_END (CONFIG_SYS_MEMTEST_START + 0x10) +#ifdef CONFIG_ARM64 +#define FDTFILE "nvidia/" CONFIG_DEFAULT_DEVICE_TREE ".dtb" +#else +#define FDTFILE CONFIG_DEFAULT_DEVICE_TREE ".dtb" +#endif + /*--- * Physical Memory Map */ diff --git a/include/configs/tegra114-common.h b/include/configs/tegra114-common.h index d3a7045697..9d751b6740 100644 --- a/include/configs/tegra114-common.h +++ b/include/configs/tegra114-common.h @@ -50,6 +50,7 @@ "scriptaddr=0x9000\0" \ "pxefile_addr_r=0x9010\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x8300\0" \ "ramdisk_addr_r=0x8310\0" diff --git a/include/configs/tegra124-common.h b/include/configs/tegra124-common.h index 522993b958..0eb8f92809 100644 --- a/include/configs/tegra124-common.h +++ b/include/configs/tegra124-common.h @@ -52,6 +52,7 @@ "scriptaddr=0x9000\0" \ "pxefile_addr_r=0x9010\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x8300\0" \ "ramdisk_addr_r=0x8310\0" diff --git a/include/configs/tegra186-common.h b/include/configs/tegra186-common.h index b4936cc731..5c3ad35c76 100644 --- a/include/configs/tegra186-common.h +++ b/include/configs/tegra186-common.h @@ -49,6 +49,7 @@ "scriptaddr=0x9000\0" \ "pxefile_addr_r=0x9010\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x8200\0" \ "ramdisk_addr_r=0x8210\0" diff --git a/include/configs/tegra20-common.h b/include/configs/tegra20-common.h index 1e31d82574..fdd8996955 100644 --- a/include/configs/tegra20-common.h +++ b/include/configs/tegra20-common.h @@ -51,6 +51,7 @@ "scriptaddr=0x1000\0" \ "pxefile_addr_r=0x1010\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x0300\0" \ "ramdisk_addr_r=0x0310\0" diff --git a/include/configs/tegra210-common.h b/include/configs/tegra210-common.h index 1b8e94b60c..2226effe16 100644 --- a/include/configs/tegra210-common.h +++ b/include/configs/tegra210-common.h @@ -46,6 +46,7 @@ "scriptaddr=0x9000\0" \ "pxefile_addr_r=0x9010\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x8300\0" \ "ramdisk_addr_r=0x8320\0" diff --git a/include/configs/tegra30-common.h b/include/configs/tegra30-common.h index 54bc6756ab..6c5dc24b26 100644 --- a/include/configs/tegra30-common.h +++ b/include/configs/tegra30-common.h @@ -47,6 +47,7 @@ "scriptaddr=0x9000\0" \ "pxefile_addr_r=0x9010\0" \ "kernel_addr_r=" __stringify(CONFIG_LOADADDR) "\0" \ + "fdtfile=" FDTFILE "\0" \ "fdt_addr_r=0x8300\0" \ "ramdisk_addr_r=0x8310\0" -- 2.26.0
Re: [PATCH] ARM: tegra: Add NVIDIA Jetson Nano Developer Kit support
On 4/1/20 4:57 PM, Tom Warren wrote: > Peter Robinson wrote at Wednesday, April 1, 2020 3:31 PM: >> diff --git a/configs/p3450-_defconfig b/configs/p3450-_defconfig > Should it also have the following that was added for the other > tegra210 Jetson that you sent through with one of hte other t210 patch series? > CONFIG_POSITION_INDEPENDENT=y > [Tom] Good catch. Nano went in after Vishruth's PIE change, so it doesn't > have it in downstream, either. I'll add it before I merge the Nano patch. > Thanks. (Trimming is useful...) Note that config option is only really required for Jetson TX2i, although it doesn't harm any other system, so it's fine to enable. IIRC the earlier bootloader stages for all other boards always load U-Boot at a specific fixed address; only on Jetson TX2i where there may be ECC page blacklisting may need to relocate the U-Boot binary.
RE: [PATCH] ARM: tegra: Add NVIDIA Jetson Nano Developer Kit support
-Original Message-
From: Peter Robinson
Sent: Wednesday, April 1, 2020 3:31 PM
To: tomcwarren3...@gmail.com
Cc: u-boot@lists.denx.de; Stephen Warren ; Thierry Reding
; Jonathan Hunter ; Tom Warren
Subject: Re: [PATCH] ARM: tegra: Add NVIDIA Jetson Nano Developer Kit support
External email: Use caution opening links or attachments
On Wed, Mar 25, 2020 at 6:22 PM wrote:
>
> From: Tom Warren
>
> The Jetson Nano Developer Kit is a Tegra X1-based development board.
> It is similar to Jetson TX1 but it is not pin compatible. It features
> 4GB of LPDDR4, a SPI NOR flash for early boot firmware and an SD card
> slot used for storage.
>
> HDMI 2.0 or DP 1.2 are available for display, four USB ports (3 USB
> 2.0 and 1 USB 3.0) can be used to attach a variety of peripherals and
> a PCI Ethernet controller provides onboard network connectivity. NVMe
> support has also been added. Env save is at the end of QSPI (4MB-8K).
>
> A 40-pin header on the board can be used to extend the capabilities
> and exposed interfaces of the Jetson Nano.
>
> Signed-off-by: Thierry Reding
> Signed-off-by: Tom Warren
Tested-by: Peter Robinson
Tested with L4T R32.3.1 and Fedora 32. A query below.
> ---
> retry send-email to see if it shows up in Patchwork
>
> arch/arm/dts/Makefile| 3 +-
> arch/arm/dts/tegra210-p3450-.dts | 147 +
> arch/arm/mach-tegra/board2.c | 25 +
> arch/arm/mach-tegra/tegra210/Kconfig | 7 ++
> board/nvidia/p3450-/Kconfig | 12 +++
> board/nvidia/p3450-/MAINTAINERS | 6 ++
> board/nvidia/p3450-/Makefile | 8 ++
> board/nvidia/p3450-/p3450-.c | 178
> +++
> configs/p3450-_defconfig | 64 +
> include/configs/p3450-.h | 46 +
> 10 files changed, 495 insertions(+), 1 deletion(-) create mode
> 100644 arch/arm/dts/tegra210-p3450-.dts
> create mode 100644 board/nvidia/p3450-/Kconfig create mode
> 100644 board/nvidia/p3450-/MAINTAINERS
> create mode 100644 board/nvidia/p3450-/Makefile create mode
> 100644 board/nvidia/p3450-/p3450-.c
> create mode 100644 configs/p3450-_defconfig create mode 100644
> include/configs/p3450-.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile index
> 9c593b2..820ee97 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -180,7 +180,8 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
> tegra210-e2220-1170.dtb \
> tegra210-p2371-.dtb \
> tegra210-p2371-2180.dtb \
> - tegra210-p2571.dtb
> + tegra210-p2571.dtb \
> + tegra210-p3450-.dtb
>
> dtb-$(CONFIG_ARCH_MVEBU) +=\
> armada-3720-db.dtb \
> diff --git a/arch/arm/dts/tegra210-p3450-.dts
> b/arch/arm/dts/tegra210-p3450-.dts
> new file mode 100644
> index 000..9ef744a
> --- /dev/null
> +++ b/arch/arm/dts/tegra210-p3450-.dts
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019-2020 NVIDIA Corporation */
> +/dts-v1/;
> +
> +#include "tegra210.dtsi"
> +
> +/ {
> + model = "NVIDIA Jetson Nano Developer Kit";
> + compatible = "nvidia,p3450-", "nvidia,tegra210";
> +
> + chosen {
> + stdout-path =
> + };
> +
> + aliases {
> + ethernet = "/pcie@1003000/pci@2,0/ethernet@0,0";
> + i2c0 = "/i2c@7000d000";
> + i2c2 = "/i2c@7000c400";
> + i2c3 = "/i2c@7000c500";
> + i2c4 = "/i2c@7000c700";
> + mmc0 = "/sdhci@700b0600";
> + mmc1 = "/sdhci@700b";
> + spi0 = "/spi@7041";
> + usb0 = "/usb@7d00";
> + };
> +
> + memory {
> + reg = <0x0 0x8000 0x0 0xc000>;
> + };
> +
> + pcie@1003000 {
> + status = "okay";
> +
> + pci@1,0 {
> + status = "okay";
> + };
> +
> + pci@2,0 {
> + status = "okay";
> +
> + ethernet@0,0 {
> + reg = <0x00 0 0 0 0>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + };
> + };
> + };
> +
> + serial@70006000 {
> + status = "okay";
> + };
> +
> + padctl@7009f000 {
> + pinctrl-0 = <_default>;
> + pinctrl-names = "default";
> +
> + padctl_default: pinmux {
> + xusb {
> + nvidia,lanes = "otg-1", "otg-2";
> + nvidia,function = "xusb";
> + nvidia,iddq = <0>;
> + };
> +
> + usb3 {
> + nvidia,lanes = "pcie-5",
Re: [PATCH] ARM: tegra: Add NVIDIA Jetson Nano Developer Kit support
On Wed, Mar 25, 2020 at 6:22 PM wrote:
>
> From: Tom Warren
>
> The Jetson Nano Developer Kit is a Tegra X1-based development board. It
> is similar to Jetson TX1 but it is not pin compatible. It features 4GB
> of LPDDR4, a SPI NOR flash for early boot firmware and an SD card slot
> used for storage.
>
> HDMI 2.0 or DP 1.2 are available for display, four USB ports (3 USB 2.0
> and 1 USB 3.0) can be used to attach a variety of peripherals and a PCI
> Ethernet controller provides onboard network connectivity. NVMe support
> has also been added. Env save is at the end of QSPI (4MB-8K).
>
> A 40-pin header on the board can be used to extend the capabilities and
> exposed interfaces of the Jetson Nano.
>
> Signed-off-by: Thierry Reding
> Signed-off-by: Tom Warren
Tested-by: Peter Robinson
Tested with L4T R32.3.1 and Fedora 32. A query below.
> ---
> retry send-email to see if it shows up in Patchwork
>
> arch/arm/dts/Makefile| 3 +-
> arch/arm/dts/tegra210-p3450-.dts | 147 +
> arch/arm/mach-tegra/board2.c | 25 +
> arch/arm/mach-tegra/tegra210/Kconfig | 7 ++
> board/nvidia/p3450-/Kconfig | 12 +++
> board/nvidia/p3450-/MAINTAINERS | 6 ++
> board/nvidia/p3450-/Makefile | 8 ++
> board/nvidia/p3450-/p3450-.c | 178
> +++
> configs/p3450-_defconfig | 64 +
> include/configs/p3450-.h | 46 +
> 10 files changed, 495 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/tegra210-p3450-.dts
> create mode 100644 board/nvidia/p3450-/Kconfig
> create mode 100644 board/nvidia/p3450-/MAINTAINERS
> create mode 100644 board/nvidia/p3450-/Makefile
> create mode 100644 board/nvidia/p3450-/p3450-.c
> create mode 100644 configs/p3450-_defconfig
> create mode 100644 include/configs/p3450-.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 9c593b2..820ee97 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -180,7 +180,8 @@ dtb-$(CONFIG_TEGRA) += tegra20-harmony.dtb \
> tegra210-e2220-1170.dtb \
> tegra210-p2371-.dtb \
> tegra210-p2371-2180.dtb \
> - tegra210-p2571.dtb
> + tegra210-p2571.dtb \
> + tegra210-p3450-.dtb
>
> dtb-$(CONFIG_ARCH_MVEBU) +=\
> armada-3720-db.dtb \
> diff --git a/arch/arm/dts/tegra210-p3450-.dts
> b/arch/arm/dts/tegra210-p3450-.dts
> new file mode 100644
> index 000..9ef744a
> --- /dev/null
> +++ b/arch/arm/dts/tegra210-p3450-.dts
> @@ -0,0 +1,147 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019-2020 NVIDIA Corporation
> + */
> +/dts-v1/;
> +
> +#include "tegra210.dtsi"
> +
> +/ {
> + model = "NVIDIA Jetson Nano Developer Kit";
> + compatible = "nvidia,p3450-", "nvidia,tegra210";
> +
> + chosen {
> + stdout-path =
> + };
> +
> + aliases {
> + ethernet = "/pcie@1003000/pci@2,0/ethernet@0,0";
> + i2c0 = "/i2c@7000d000";
> + i2c2 = "/i2c@7000c400";
> + i2c3 = "/i2c@7000c500";
> + i2c4 = "/i2c@7000c700";
> + mmc0 = "/sdhci@700b0600";
> + mmc1 = "/sdhci@700b";
> + spi0 = "/spi@7041";
> + usb0 = "/usb@7d00";
> + };
> +
> + memory {
> + reg = <0x0 0x8000 0x0 0xc000>;
> + };
> +
> + pcie@1003000 {
> + status = "okay";
> +
> + pci@1,0 {
> + status = "okay";
> + };
> +
> + pci@2,0 {
> + status = "okay";
> +
> + ethernet@0,0 {
> + reg = <0x00 0 0 0 0>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + };
> + };
> + };
> +
> + serial@70006000 {
> + status = "okay";
> + };
> +
> + padctl@7009f000 {
> + pinctrl-0 = <_default>;
> + pinctrl-names = "default";
> +
> + padctl_default: pinmux {
> + xusb {
> + nvidia,lanes = "otg-1", "otg-2";
> + nvidia,function = "xusb";
> + nvidia,iddq = <0>;
> + };
> +
> + usb3 {
> + nvidia,lanes = "pcie-5", "pcie-6";
> + nvidia,function = "usb3";
> + nvidia,iddq = <0>;
> + };
> +
> + pcie-x1 {
> + nvidia,lanes = "pcie-0";
> + nvidia,function = "pcie-x1";
> + nvidia,iddq =
Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board
On Wed, 2020-04-01 at 18:09 +0800, Chen-Yu Tsai wrote:
> On Tue, Mar 31, 2020 at 8:37 PM Jagan Teki wrote:
> >
> >
> > On Tue, Mar 31, 2020 at 5:16 PM Chen-Yu Tsai wrote:
> > >
> > >
> > > On Tue, Mar 31, 2020 at 6:57 PM Jagan Teki
> > > wrote:
> > > >
> > > >
> > > > On Mon, Mar 30, 2020 at 11:54 PM Chen-Yu Tsai wrote:
> > > > >
> > > > >
> > > > > On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > Hi Chen-Yu,
> > > > > >
> > > > > > On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai
> > > > > > wrote:
> > > > > > >
> > > > > > >
> > > > > > > From: Chen-Yu Tsai
> > > > > > >
> > > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a
> > > > > > > credit
> > > > > > > card size development board based on the Rockchip RK3328 SoC,
> > > > > > > with:
> > > > > > >
> > > > > > > - 1/2/4 GB DDR4 DRAM
> > > > > > > - eMMC connector for optional module
> > > > > > > - micro SD card slot
> > > > > > > - 1 x USB 3.0 host port
> > > > > > > - 2 x USB 2.0 host port
> > > > > > > - 1 x USB 2.0 OTG port
> > > > > > > - HDMI video output
> > > > > > > - TRRS connector with audio and composite video output
> > > > > > > - gigabit Ethernet
> > > > > > > - consumer IR receiver
> > > > > > > - debug UART pins
> > > > > > >
> > > > > > > The ROC-RK3328-CC has the enable pin of the SD card power switch
> > > > > > > tied
> > > > > > > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which
> > > > > > > is
> > > > > > > muxed by default. SDMMC0_PWREN is an active high signal
> > > > > > > controlled by
> > > > > > > the MMC controller, however the switch enable is active low, and
> > > > > > > pulled low (enabled) by default to make things work on boot.
> > > > > > >
> > > > > > > As such, we need to mux away from SDMMC0_PWREN and use GPIO to
> > > > > > > enable
> > > > > > > power to the card. The default GPIO state for the pin is
> > > > > > > pull-down and
> > > > > > > input, which doesn't require extra configuration when paired with
> > > > > > > the
> > > > > > > external pull-down and active low switch.
> > > > > > >
> > > > > > > Thus we make a custom target for this board and do the muxing in
> > > > > > > its
> > > > > > > spl_board_init() function.
> > > > > > >
> > > > > > > The device tree file is synced from the Linux kernel
> > > > > > > next-20200324.
> > > > > > >
> > > > > > > Signed-off-by: Chen-Yu Tsai
> > > > > > > ---
> > > > > > [snip]
> > > > > >
> > > > > > >
> > > > > > > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > > new file mode 100644
> > > > > > > index ..f2318e71ac33
> > > > > > > --- /dev/null
> > > > > > > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > > @@ -0,0 +1,7 @@
> > > > > > > +ROC-RK3328-CC
> > > > > > > +M: Loic Devulder
> > > > > > > +M: Chen-Yu Tsai
> > > > > > > +S: Maintained
> > > > > > > +F: board/firefly/roc-cc-rk3328/
> > > > > > > +F: configs/roc-rk3328-cc_defconfig
> > > > > > > +F: arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > > > > > > diff --git a/board/firefly/roc-cc-rk3328/Makefile
> > > > > > > b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > > new file mode 100644
> > > > > > > index ..1550b5f5f16e
> > > > > > > --- /dev/null
> > > > > > > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > > @@ -0,0 +1 @@
> > > > > > > +obj-y := board.o
> > > > > > > diff --git a/board/firefly/roc-cc-rk3328/board.c
> > > > > > > b/board/firefly/roc-cc-rk3328/board.c
> > > > > > > new file mode 100644
> > > > > > > index ..eca58c86b53e
> > > > > > > --- /dev/null
> > > > > > > +++ b/board/firefly/roc-cc-rk3328/board.c
> > > > > > > @@ -0,0 +1,38 @@
> > > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > > > +/*
> > > > > > > + * (C) Copyright 2020 Chen-Yu Tsai
> > > > > > > + */
> > > > > > > +#include
> > > > > > > +
> > > > > > > +#include
> > > > > > > +#include
> > > > > > > +
> > > > > > > +#if defined(CONFIG_SPL_BUILD)
> > > > > > > +
> > > > > > > +#define GRF_BASE 0xFF10
> > > > > > > +
> > > > > > > +enum {
> > > > > > > + GPIO_0_D6_GPIO = 0 << 12,
> > > > > > > + GPIO_0_D6_MASK = 0x3 << 12
> > > > > > > +};
> > > > > > > +
> > > > > > > +/*
> > > > > > > + * The ROC-RK3328-CC has the enable pin of the SD card power
> > > > > > > switch tied
> > > > > > > + * to GPIO_0_D6. This pin also has the function SDMMC0_PWREN,
> > > > > > > which is
> > > > > > > + * muxed by default. SDMMC0_PWREN is an active high signal
> > > > > > > controlled by
> > > > > > > + * the MMC controller, however the switch enable is active low,
> > > > > > > and
> > > > > > > + * pulled low (enabled) by default to make things work on boot.
> > > > > > > + *
> > > > > > > + * As such, we need to mux away from SDMMC0_PWREN and use GPIO
> > > > > > > to enable
> > > > > > > +
RE: [PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96
Hi Marek and Patrick
> From: Marek Vasut
> Sent: mercredi 1 avril 2020 13:09
>
> On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> > Hi Gerald and Manivannan,
>
> Hi,
>
> >> From: Marek Vasut
> >> Sent: mardi 31 mars 2020 19:52
> >>
> >> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
> >> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
> >> can not easily divide the clock down to e.g. 50 MHz for high speed SD
> >> and eMMC devices, so those devices end up running at 30 MHz as that is
> 120 MHz / 4.
> >> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
> >> MHz instead, which is easy to divide to 50MHz for optimal operation
> >> of both SD and eMMC, SPDIF clock are not that much slower and FDCAN is
> also unaffected.
As far as I see, SPDIF is not supported on Avenger board so we don't care for
this one.
FDCAN can be supported via the expansion connector, so better to keep it high
(and < 100 MHz).
Be careful because the LTDC pixel clock also comes from the PLL4Q and it is
used for the HDMI on Avenger.
The pixel clock is very constraint and I am surprised by the initial 40 MHz
configuration (that becomes 50 MHz with your patch).
I would recommend to align the Avenger configuration to ST boards one, that is
the best compromise found so far (99 MHz for SDMMC and 74.250 MHz for HDMI):
https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
/* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
pll4: st,pll@3 {
cfg = < 3 98 5 7 7 PQR(1,1,1) >;
u-boot,dm-pre-reloc;
};
> >> Reviewed-by: Patrice Chotard
> >> Reviewed-by: Patrick Delaunay
> >> Signed-off-by: Marek Vasut
> >> Cc: Manivannan Sadhasivam
> >> Cc: Patrick Delaunay
> >> Cc: Patrice Chotard
> >> ---
> >> V2: Move this patch before the split of AV96 into SoM and carrier
> >> V3: No change
> >> ---
> >
> > This patch update the PLL4 frequency used on AV96 board, with
> > different of reference clock tree used on ST board, this new setting
> > allow to optimize the SDMMC frequency (50MHz vs 30Mz).
> >
> > I don't know why the previous PLL4 frequency was chosen as a
> > compromise on reference clock-tree (PLL4 is used by mostly all the
> > peripheral, with display and audio requirements).
> >
> > Can you cross check the proposed clock tree and ack this patch if
> > these ST requirements are not applicable on AV96 board.
> >
> > Anyway the code is correct.
>
> Likely because these PLL settings are being copied from reference platform
> to other platforms etc.
As far as I remember, we never had this configuration for PLL4 on ST boards, so
the copy certainly comes from somewhere else.
> But I did notice one odd thing, which is when running the SD1 in SDR104, the
> read data transfers can be unstable, which I suspect is because the bus runs
> at actual 100 MHz instead of some 60 MHz. I need to look at that with a
> scope, so that's to be checked. For now I turned the SDR104 off.
Re: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
On Wed, Apr 01, 2020 at 10:35:23PM +0200, Tom Warren wrote:
> -Original Message-
> From: Thierry Reding
> Sent: Wednesday, April 1, 2020 8:20 AM
> To: Tom Warren
> Cc: Peter Robinson ; tomcwarren3...@gmail.com;
> u-boot@lists.denx.de; Stephen Warren ; Jonathan Hunter
> ; Vishruth Jain
> Subject: Re: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
>
> On Wed, Apr 01, 2020 at 02:03:09AM +0200, Tom Warren wrote:
> > -Original Message-
> > From: Peter Robinson
> > Sent: Tuesday, March 31, 2020 3:54 AM
> > To: tomcwarren3...@gmail.com
> > Cc: u-boot@lists.denx.de; Stephen Warren ; Thierry
> > Reding ; Jonathan Hunter ;
> > Tom Warren ; Vishruth Jain
> > Subject: Re: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
> >
> > External email: Use caution opening links or attachments
> >
> >
> > > From: Stephen Warren
> > >
> > > This adds to the DT the I2C controllers that connect to the board ID
> > > EEPROM, camera board EEPROM, etc. With this change, you can now
> > > probe all I2C devices on a TX1 board.
> > >
> > > Signed-off-by: Tom Warren
> > > ---
> > > arch/arm/dts/tegra210-p2371-2180.dts | 18 ++
> > > 1 file changed, 18 insertions(+)
> > >
> > > diff --git a/arch/arm/dts/tegra210-p2371-2180.dts
> > > b/arch/arm/dts/tegra210-p2371-2180.dts
> > > index c2f497c..d982b5f 100644
> > > --- a/arch/arm/dts/tegra210-p2371-2180.dts
> > > +++ b/arch/arm/dts/tegra210-p2371-2180.dts
> > > @@ -12,6 +12,9 @@
> > >
> > > aliases {
> > > i2c0 = "/i2c@7000d000";
> > > + i2c2 = "/i2c@7000c400";
> > > + i2c3 = "/i2c@7000c500";
> > > + i2c5 = "/i2c@546c0c00";
> >
> > I don't think this is correct, it doesn't show up in U-Boot with the
> > "i2c bus" command where the others do, looking in the tegra210.dtsi it
> > looks like it should be i2c@546c?
> > [Tom] That I2C address is working in downstream (L4T) TX1 U-Boot. The
> > VI_I2C controller is a little weird, it's normal I2C registers are
> > offset from base by 0xC00. A different driver is needed, but I
> > haven't posted it yet upstream. I should probably drop if from the
> > DTS for now until I post the VI_I2C driver.
>
> I think the problem here is that the upstream U-Boot device tree
> doesn't contain an i2c@546c0c00 node. Instead it has i2c@546c,
> which we also have in the upstream kernel. My recollection is that
> that's also the address listed in the Tegra210 system address map of
> the TRM and there are some registers before the regular I2C interface
> at offset 0xc00.
>
> I've been carrying a patch against the upstream Linux I2C controller
> driver to special-case the VI/I2C to always add that 0xc00 offset when
> accessing registers, which allows us to reuse the existing driver and
> at the same time keeps all registers mapped so we can also access the
> VI/I2C specific registers.
>
> My recollection is that the U-Boot driver is fairly similar to the
> Linux driver, so I suspect something similar could be done.
>
> Thierry
> [Tom] Thanks, Thierry. That's my recollection, too, about the VI_I2C
> 0xC00 offset. I'll take a look at what we have in L4T U-Boot for T210
> and address it in a set of patches for upstream soon. That I2C
> controller isn't used for anything on any Jetson board except on TX1,
> I believe, where it allows U-Boot to talk to the camera add-in board
> to read the board ID. But we've moved all that out to CBoot (board ID
> EEPROM reading), so there isn't a pressing need for it in U-Boot
> anymore, IIRC.
We've had internal discussions about potentially using the ID EEPROMs to
dynamically modify the kernel DTB at runtime (possibly from U-Boot) in
order to support things like different add-in boards.
For example, we currently enable the DSI output in Linux for Jetson TX1.
However, the Jetson TX1 developer kits don't actually ship with that DSI
display (I don't think they even come with the display add-in card), so
this can lead to confusion. The idea was to have U-Boot probe ID EEPROMs
from several sources to determine what to add to the device tree, so
that the kernel DT *source* would only contain the standard developer
kit hardware, but U-Boot (or something else perhaps) could add in extra
nodes for a display module, or camera add-in board, etc.
Note that this is just a vague idea at this time and nothing concrete
has been done to implement this, yet.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH 3/5] rockchip: rng: Add a driver for random number generator(rng) device
> Add a driver for the rng device found on rockchip platforms.
> Support rng module of crypto v1 and crypto v2.
>
> Signed-off-by: Lin Jinhan
Tested-by: Peter Robinson
Tested with UEFI RNG providing a seed for KASLR.
> ---
> drivers/rng/Kconfig| 8 ++
> drivers/rng/Makefile | 1 +
> drivers/rng/rockchip_rng.c | 224 +
> 3 files changed, 233 insertions(+)
> create mode 100644 drivers/rng/rockchip_rng.c
>
> diff --git a/drivers/rng/Kconfig b/drivers/rng/Kconfig
> index edb6152bb9..e4b22d79eb 100644
> --- a/drivers/rng/Kconfig
> +++ b/drivers/rng/Kconfig
> @@ -31,4 +31,12 @@ config RNG_STM32MP1
> help
> Enable STM32MP1 rng driver.
>
> +config RNG_ROCKCHIP
> + bool "Enable random number generator for rockchip crypto rng"
> + depends on ARCH_ROCKCHIP && DM_RNG
> + default n
> + help
> + Enable random number generator for rockchip.This driver is
> + support rng module of crypto v1 and crypto v2.
> +
> endif
> diff --git a/drivers/rng/Makefile b/drivers/rng/Makefile
> index 6a8a66779b..44a0003917 100644
> --- a/drivers/rng/Makefile
> +++ b/drivers/rng/Makefile
> @@ -7,3 +7,4 @@ obj-$(CONFIG_DM_RNG) += rng-uclass.o
> obj-$(CONFIG_RNG_MESON) += meson-rng.o
> obj-$(CONFIG_RNG_SANDBOX) += sandbox_rng.o
> obj-$(CONFIG_RNG_STM32MP1) += stm32mp1_rng.o
> +obj-$(CONFIG_RNG_ROCKCHIP) += rockchip_rng.o
> diff --git a/drivers/rng/rockchip_rng.c b/drivers/rng/rockchip_rng.c
> new file mode 100644
> index 00..47fb140077
> --- /dev/null
> +++ b/drivers/rng/rockchip_rng.c
> @@ -0,0 +1,224 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (c) 2020 Fuzhou Rockchip Electronics Co., Ltd
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define RK_HW_RNG_MAX 32
> +
> +#define _SBF(s, v) ((v) << (s))
> +
> +/* start of CRYPTO V1 register define */
> +#define CRYPTO_V1_CTRL 0x0008
> +#define CRYPTO_V1_RNG_STARTBIT(8)
> +#define CRYPTO_V1_RNG_FLUSHBIT(9)
> +
> +#define CRYPTO_V1_TRNG_CTRL0x0200
> +#define CRYPTO_V1_OSC_ENABLE BIT(16)
> +#define CRYPTO_V1_TRNG_SAMPLE_PERIOD(x)(x)
> +
> +#define CRYPTO_V1_TRNG_DOUT_0 0x0204
> +/* end of CRYPTO V1 register define */
> +
> +/* start of CRYPTO V2 register define */
> +#define CRYPTO_V2_RNG_CTL 0x0400
> +#define CRYPTO_V2_RNG_64_BIT_LEN _SBF(4, 0x00)
> +#define CRYPTO_V2_RNG_128_BIT_LEN _SBF(4, 0x01)
> +#define CRYPTO_V2_RNG_192_BIT_LEN _SBF(4, 0x02)
> +#define CRYPTO_V2_RNG_256_BIT_LEN _SBF(4, 0x03)
> +#define CRYPTO_V2_RNG_FATESY_SOC_RING _SBF(2, 0x00)
> +#define CRYPTO_V2_RNG_SLOWER_SOC_RING_0_SBF(2, 0x01)
> +#define CRYPTO_V2_RNG_SLOWER_SOC_RING_1_SBF(2, 0x02)
> +#define CRYPTO_V2_RNG_SLOWEST_SOC_RING _SBF(2, 0x03)
> +#define CRYPTO_V2_RNG_ENABLE BIT(1)
> +#define CRYPTO_V2_RNG_STARTBIT(0)
> +#define CRYPTO_V2_RNG_SAMPLE_CNT 0x0404
> +#define CRYPTO_V2_RNG_DOUT_0 0x0410
> +/* end of CRYPTO V2 register define */
> +
> +#define RK_RNG_TIME_OUT5 /* max 50ms */
> +
> +struct rk_rng_soc_data {
> + int (*rk_rng_read)(struct udevice *dev, void *data, size_t len);
> +};
> +
> +struct rk_rng_platdata {
> + fdt_addr_t base;
> + struct rk_rng_soc_data *soc_data;
> +};
> +
> +static int rk_rng_read_regs(fdt_addr_t addr, void *buf, size_t size)
> +{
> + u32 count = RK_HW_RNG_MAX / sizeof(u32);
> + u32 reg, tmp_len;
> +
> + if (size > RK_HW_RNG_MAX)
> + return -EINVAL;
> +
> + while (size && count) {
> + reg = readl(addr);
> + tmp_len = min(size, sizeof(u32));
> + memcpy(buf, , tmp_len);
> + addr += sizeof(u32);
> + buf += tmp_len;
> + size -= tmp_len;
> + count--;
> + }
> +
> + return 0;
> +}
> +
> +static int rk_v1_rng_read(struct udevice *dev, void *data, size_t len)
> +{
> + struct rk_rng_platdata *pdata = dev_get_priv(dev);
> + u32 reg = 0;
> + int retval;
> +
> + if (len > RK_HW_RNG_MAX)
> + return -EINVAL;
> +
> + /* enable osc_ring to get entropy, sample period is set as 100 */
> + writel(CRYPTO_V1_OSC_ENABLE | CRYPTO_V1_TRNG_SAMPLE_PERIOD(100),
> + pdata->base + CRYPTO_V1_TRNG_CTRL);
> +
> + rk_clrsetreg(pdata->base + CRYPTO_V1_CTRL, CRYPTO_V1_RNG_START,
> +CRYPTO_V1_RNG_START);
> +
> + retval = readl_poll_timeout(pdata->base + CRYPTO_V1_CTRL, reg,
> + !(reg & CRYPTO_V1_RNG_START),
> + RK_RNG_TIME_OUT);
> + if (retval)
> +
Re: [PATCH 1/5] arm: dts: rockchip: rk3399: add and enable rng node
On Tue, Mar 31, 2020 at 12:35 PM Lin Jinhan wrote:
>
> Add rng node in rk3399-u-boot.dtsi and enable it in
> rk3399-evb-u-boot.dtsi.
>
> Signed-off-by: Lin Jinhan
Tested-by: Peter Robinson
Tested with UEFI RNG providing a seed for KASLR.
> ---
> arch/arm/dts/rk3399-evb-u-boot.dtsi | 5 +
> arch/arm/dts/rk3399-u-boot.dtsi | 6 ++
> 2 files changed, 11 insertions(+)
>
> diff --git a/arch/arm/dts/rk3399-evb-u-boot.dtsi
> b/arch/arm/dts/rk3399-evb-u-boot.dtsi
> index ccb33d34d1..5b50c5ba30 100644
> --- a/arch/arm/dts/rk3399-evb-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-evb-u-boot.dtsi
> @@ -11,3 +11,8 @@
> u-boot,spl-boot-order = ,
> };
> };
> +
> + {
> + status = "okay";
> +};
> +
> diff --git a/arch/arm/dts/rk3399-u-boot.dtsi b/arch/arm/dts/rk3399-u-boot.dtsi
> index 8b857ccfc7..757b8c10a2 100644
> --- a/arch/arm/dts/rk3399-u-boot.dtsi
> +++ b/arch/arm/dts/rk3399-u-boot.dtsi
> @@ -25,6 +25,12 @@
> clock-names = "pclk_ddr_mon";
> };
>
> + rng: rng@ff8b8000 {
> + compatible = "rockchip,cryptov1-rng";
> + reg = <0x0 0xff8b8000 0x0 0x1000>;
> + status = "disabled";
> + };
> +
> dmc: dmc {
> u-boot,dm-pre-reloc;
> compatible = "rockchip,rk3399-dmc";
> --
> 2.17.1
>
>
>
Re: [PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96
On 4/1/20 6:49 PM, Gerald BAEZA wrote:
> Hi Marek and Patrick
Hi,
>> From: Marek Vasut
>> Sent: mercredi 1 avril 2020 13:09
>>
>> On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
>>> Hi Gerald and Manivannan,
>>
>> Hi,
>>
From: Marek Vasut
Sent: mardi 31 mars 2020 19:52
The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
can not easily divide the clock down to e.g. 50 MHz for high speed SD
and eMMC devices, so those devices end up running at 30 MHz as that is
>> 120 MHz / 4.
Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
MHz instead, which is easy to divide to 50MHz for optimal operation
of both SD and eMMC, SPDIF clock are not that much slower and FDCAN is
>> also unaffected.
>
> As far as I see, SPDIF is not supported on Avenger board so we don't care for
> this one.
> FDCAN can be supported via the expansion connector, so better to keep it high
> (and < 100 MHz).
Why < 100 MHz and not <= 100 MHz ?
> Be careful because the LTDC pixel clock also comes from the PLL4Q and it is
> used for the HDMI on Avenger.
> The pixel clock is very constraint and I am surprised by the initial 40 MHz
> configuration (that becomes 50 MHz with your patch).
Is that a problem that the LTDC pixel clock are 50 MHz ? The kernel will
reconfigure them anyway, so the 50 MHz is not the final value.
> I would recommend to align the Avenger configuration to ST boards one, that
> is the best compromise found so far (99 MHz for SDMMC and 74.250 MHz for
> HDMI):
Why is this better than 100/50/100 ?
> https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
> /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> pll4: st,pll@3 {
> cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> u-boot,dm-pre-reloc;
> };
[...]
Re: iMX8MM USB support?
+ Sherry, as he was working on iMX8* USB support On Wed, Apr 1, 2020, 20:55 Tim Harvey wrote: > Peng, > > It looks like IMX8MM USB support hasn't made it upstream yet. Is this > something your working on? > > I'm interested in booting an IMX8MM via SDP. > > Best Regards, > > Tim >
Re: XHCI bringup on the Raspberry Pi 4
On 4/1/20 10:47 PM, Nicolas Saenz Julienne wrote: > On Wed, 2020-04-01 at 22:14 +0200, Marek Vasut wrote: >> On 4/1/20 10:13 PM, Nicolas Saenz Julienne wrote: >>> On Wed, 2020-04-01 at 20:50 +0200, Marek Vasut wrote: On 4/1/20 7:30 PM, Nicolas Saenz Julienne wrote: > Hi All, Hi, > I'm working on enabling the VIA805 XCHI controller found on the new > Raspberry > Pi 4. The controller sits behind a PCIe bus, which I've already > implemented[1] > and will submit once the XCHI issues are resolved, as it's worthless > otherwise. > > The XHCI initialization gets stuck after issuing the fist 'enable slot' > command. I've been reviewing the whole init process and comparing it to > Linux's > for days without finding anything fishy. DMA constraints, which are > important > on the RPi are mantained, and on top of that, I can confirm DMA trough > PCIe > works fine as I see two 'port status change' events available in the > ring > before completly stalling. Also note that, unsurprisingly, the CRR bit > in > the > CRCR register (which marks the running state of the Command Ring state > machine) > is never set after ringing the relevant doorbell. > > I'm clueless at this point, I figure the VIA805 is sensitive to the > ordering > of > some of the operations we perform in u-boot, or worse, the timing. For > example, > I tried replicanting Linux's behaviour with regard to 'port status > change' > events, processing them before calling the 'enable slot' command. I also > tried > to mimic Linux by enabling port-0's power (the USB3 port) before > starting > the > HC. Again, no luck. > > I attached the usb/xhci debug output, any ideas on where to look will be > apreciated. Try disabling caches (dcache off ; icache off) and see if it magically starts working. That comes to mind. >>> >>> Same outcome :( >> >> Hmmm, no idea then, maybe others have some. >> >> I presume PCIe works correctly , right? > > I was also responsible for the Linux version of the PCIe driver so I know it > fairly well. I also double-checked all pcie-brcmstb's registers have the > expected values. > > From the USB perspective, I'm both able to map XHCI's registers into memory > and > get some output out of the event ring, which implies XHCI accessed memory > trough the bus. On top of that if something went wrong with PCI there is a > register that should point it out, Host System Error (HSE), which so far has > been silent. > > Overall I'm confident PCIe is fine. OK, then I hope Bin can help here, he's the xHCI expert.
Re: XHCI bringup on the Raspberry Pi 4
On Wed, 2020-04-01 at 22:14 +0200, Marek Vasut wrote: > On 4/1/20 10:13 PM, Nicolas Saenz Julienne wrote: > > On Wed, 2020-04-01 at 20:50 +0200, Marek Vasut wrote: > > > On 4/1/20 7:30 PM, Nicolas Saenz Julienne wrote: > > > > Hi All, > > > > > > Hi, > > > > > > > I'm working on enabling the VIA805 XCHI controller found on the new > > > > Raspberry > > > > Pi 4. The controller sits behind a PCIe bus, which I've already > > > > implemented[1] > > > > and will submit once the XCHI issues are resolved, as it's worthless > > > > otherwise. > > > > > > > > The XHCI initialization gets stuck after issuing the fist 'enable slot' > > > > command. I've been reviewing the whole init process and comparing it to > > > > Linux's > > > > for days without finding anything fishy. DMA constraints, which are > > > > important > > > > on the RPi are mantained, and on top of that, I can confirm DMA trough > > > > PCIe > > > > works fine as I see two 'port status change' events available in the > > > > ring > > > > before completly stalling. Also note that, unsurprisingly, the CRR bit > > > > in > > > > the > > > > CRCR register (which marks the running state of the Command Ring state > > > > machine) > > > > is never set after ringing the relevant doorbell. > > > > > > > > I'm clueless at this point, I figure the VIA805 is sensitive to the > > > > ordering > > > > of > > > > some of the operations we perform in u-boot, or worse, the timing. For > > > > example, > > > > I tried replicanting Linux's behaviour with regard to 'port status > > > > change' > > > > events, processing them before calling the 'enable slot' command. I also > > > > tried > > > > to mimic Linux by enabling port-0's power (the USB3 port) before > > > > starting > > > > the > > > > HC. Again, no luck. > > > > > > > > I attached the usb/xhci debug output, any ideas on where to look will be > > > > apreciated. > > > > > > Try disabling caches (dcache off ; icache off) and see if it magically > > > starts working. That comes to mind. > > > > Same outcome :( > > Hmmm, no idea then, maybe others have some. > > I presume PCIe works correctly , right? I was also responsible for the Linux version of the PCIe driver so I know it fairly well. I also double-checked all pcie-brcmstb's registers have the expected values. From the USB perspective, I'm both able to map XHCI's registers into memory and get some output out of the event ring, which implies XHCI accessed memory trough the bus. On top of that if something went wrong with PCI there is a register that should point it out, Host System Error (HSE), which so far has been silent. Overall I'm confident PCIe is fine. Regards, Nicolas signature.asc Description: This is a digitally signed message part
RE: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
-Original Message-
From: Thierry Reding
Sent: Wednesday, April 1, 2020 8:20 AM
To: Tom Warren
Cc: Peter Robinson ; tomcwarren3...@gmail.com;
u-boot@lists.denx.de; Stephen Warren ; Jonathan Hunter
; Vishruth Jain
Subject: Re: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
On Wed, Apr 01, 2020 at 02:03:09AM +0200, Tom Warren wrote:
> -Original Message-
> From: Peter Robinson
> Sent: Tuesday, March 31, 2020 3:54 AM
> To: tomcwarren3...@gmail.com
> Cc: u-boot@lists.denx.de; Stephen Warren ; Thierry
> Reding ; Jonathan Hunter ;
> Tom Warren ; Vishruth Jain
> Subject: Re: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
>
> External email: Use caution opening links or attachments
>
>
> > From: Stephen Warren
> >
> > This adds to the DT the I2C controllers that connect to the board ID
> > EEPROM, camera board EEPROM, etc. With this change, you can now
> > probe all I2C devices on a TX1 board.
> >
> > Signed-off-by: Tom Warren
> > ---
> > arch/arm/dts/tegra210-p2371-2180.dts | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/arm/dts/tegra210-p2371-2180.dts
> > b/arch/arm/dts/tegra210-p2371-2180.dts
> > index c2f497c..d982b5f 100644
> > --- a/arch/arm/dts/tegra210-p2371-2180.dts
> > +++ b/arch/arm/dts/tegra210-p2371-2180.dts
> > @@ -12,6 +12,9 @@
> >
> > aliases {
> > i2c0 = "/i2c@7000d000";
> > + i2c2 = "/i2c@7000c400";
> > + i2c3 = "/i2c@7000c500";
> > + i2c5 = "/i2c@546c0c00";
>
> I don't think this is correct, it doesn't show up in U-Boot with the
> "i2c bus" command where the others do, looking in the tegra210.dtsi it
> looks like it should be i2c@546c?
> [Tom] That I2C address is working in downstream (L4T) TX1 U-Boot. The
> VI_I2C controller is a little weird, it's normal I2C registers are
> offset from base by 0xC00. A different driver is needed, but I
> haven't posted it yet upstream. I should probably drop if from the
> DTS for now until I post the VI_I2C driver.
I think the problem here is that the upstream U-Boot device tree doesn't
contain an i2c@546c0c00 node. Instead it has i2c@546c, which we also have
in the upstream kernel. My recollection is that that's also the address listed
in the Tegra210 system address map of the TRM and there are some registers
before the regular I2C interface at offset 0xc00.
I've been carrying a patch against the upstream Linux I2C controller driver to
special-case the VI/I2C to always add that 0xc00 offset when accessing
registers, which allows us to reuse the existing driver and at the same time
keeps all registers mapped so we can also access the VI/I2C specific registers.
My recollection is that the U-Boot driver is fairly similar to the Linux
driver, so I suspect something similar could be done.
Thierry
[Tom] Thanks, Thierry. That's my recollection, too, about the VI_I2C 0xC00
offset. I'll take a look at what we have in L4T U-Boot for T210 and address it
in a set of patches for upstream soon. That I2C controller isn't used for
anything on any Jetson board except on TX1, I believe, where it allows U-Boot
to talk to the camera add-in board to read the board ID. But we've moved all
that out to CBoot (board ID EEPROM reading), so there isn't a pressing need for
it in U-Boot anymore, IIRC.
--nvpublic
Re: XHCI bringup on the Raspberry Pi 4
On 4/1/20 10:13 PM, Nicolas Saenz Julienne wrote: > On Wed, 2020-04-01 at 20:50 +0200, Marek Vasut wrote: >> On 4/1/20 7:30 PM, Nicolas Saenz Julienne wrote: >>> Hi All, >> >> Hi, >> >>> I'm working on enabling the VIA805 XCHI controller found on the new >>> Raspberry >>> Pi 4. The controller sits behind a PCIe bus, which I've already >>> implemented[1] >>> and will submit once the XCHI issues are resolved, as it's worthless >>> otherwise. >>> >>> The XHCI initialization gets stuck after issuing the fist 'enable slot' >>> command. I've been reviewing the whole init process and comparing it to >>> Linux's >>> for days without finding anything fishy. DMA constraints, which are >>> important >>> on the RPi are mantained, and on top of that, I can confirm DMA trough PCIe >>> works fine as I see two 'port status change' events available in the ring >>> before completly stalling. Also note that, unsurprisingly, the CRR bit in >>> the >>> CRCR register (which marks the running state of the Command Ring state >>> machine) >>> is never set after ringing the relevant doorbell. >>> >>> I'm clueless at this point, I figure the VIA805 is sensitive to the ordering >>> of >>> some of the operations we perform in u-boot, or worse, the timing. For >>> example, >>> I tried replicanting Linux's behaviour with regard to 'port status change' >>> events, processing them before calling the 'enable slot' command. I also >>> tried >>> to mimic Linux by enabling port-0's power (the USB3 port) before starting >>> the >>> HC. Again, no luck. >>> >>> I attached the usb/xhci debug output, any ideas on where to look will be >>> apreciated. >> >> Try disabling caches (dcache off ; icache off) and see if it magically >> starts working. That comes to mind. > > Same outcome :( Hmmm, no idea then, maybe others have some. I presume PCIe works correctly , right?
Re: XHCI bringup on the Raspberry Pi 4
On Wed, 2020-04-01 at 20:50 +0200, Marek Vasut wrote: > On 4/1/20 7:30 PM, Nicolas Saenz Julienne wrote: > > Hi All, > > Hi, > > > I'm working on enabling the VIA805 XCHI controller found on the new > > Raspberry > > Pi 4. The controller sits behind a PCIe bus, which I've already > > implemented[1] > > and will submit once the XCHI issues are resolved, as it's worthless > > otherwise. > > > > The XHCI initialization gets stuck after issuing the fist 'enable slot' > > command. I've been reviewing the whole init process and comparing it to > > Linux's > > for days without finding anything fishy. DMA constraints, which are > > important > > on the RPi are mantained, and on top of that, I can confirm DMA trough PCIe > > works fine as I see two 'port status change' events available in the ring > > before completly stalling. Also note that, unsurprisingly, the CRR bit in > > the > > CRCR register (which marks the running state of the Command Ring state > > machine) > > is never set after ringing the relevant doorbell. > > > > I'm clueless at this point, I figure the VIA805 is sensitive to the ordering > > of > > some of the operations we perform in u-boot, or worse, the timing. For > > example, > > I tried replicanting Linux's behaviour with regard to 'port status change' > > events, processing them before calling the 'enable slot' command. I also > > tried > > to mimic Linux by enabling port-0's power (the USB3 port) before starting > > the > > HC. Again, no luck. > > > > I attached the usb/xhci debug output, any ideas on where to look will be > > apreciated. > > Try disabling caches (dcache off ; icache off) and see if it magically > starts working. That comes to mind. Same outcome :( signature.asc Description: This is a digitally signed message part
Re: [PATCH 2/3] dm: core: support reading a single indexed u32 value
Do you think it would make sense to add indexed access also for the s32, u32u and u64 types or at least some of those ? Thanks and regards Dario Binacchi > Il 31 marzo 2020 alle 1.57 Simon Glass ha scritto: > > > On Sun, 29 Mar 2020 at 10:05, Dario Binacchi wrote: > > > > The patch adds helper functions to allow reading a single indexed u32 > > value from a device-tree property containing multiple u32 values, that > > is an array of integers. > > > > Signed-off-by: Dario Binacchi > > --- > > > > arch/sandbox/dts/test.dts | 1 + > > drivers/core/of_access.c | 22 + > > drivers/core/ofnode.c | 40 +++ > > drivers/core/read.c | 13 + > > include/dm/of_access.h| 19 +++ > > include/dm/ofnode.h | 25 > > include/dm/read.h | 40 +++ > > test/dm/test-fdt.c| 29 > > 8 files changed, 189 insertions(+) > > > > Reviewed-by: Simon Glass > > Very nice
Re: [PATCH 3/3] dm: core: refactor functions reading an u32 from dt
> Il 31 marzo 2020 alle 1.57 Simon Glass ha scritto: > > > On Sun, 29 Mar 2020 at 10:05, Dario Binacchi wrote: > > > > Now reading a 32 bit value from a device-tree property can be expressed > > as reading the first element of an array with a single value. > > > > Signed-off-by: Dario Binacchi > > > > --- > > > > drivers/core/of_access.c | 16 +--- > > drivers/core/ofnode.c| 23 ++- > > 2 files changed, 3 insertions(+), 36 deletions(-) > > Reviewed-by: Simon Glass > > Can you please check the code-size delta in SPL on a suitable board? I have a black beaglebone available (am335x_evm_defconfig). u-boot-spl.map generated without applying the refactoring patch .text.ofnode_read_u32 0x 0x2e drivers/built-in.o .text.ofnode_read_u32_index 0x 0x38 drivers/built-in.o .text.ofnode_read_u32_default 0x 0x12 drivers/built-in.o u-boot-spl.map genarated with the refactoring patch applied .text.ofnode_read_u32_index 0x 0x38 drivers/built-in.o .text.ofnode_read_u32 0x0x8 drivers/built-in.o .text.ofnode_read_u32_default 0x 0x14 drivers/built-in.o I hope I have correctly answered what you asked me. Otherwise I am available to perform the right checks on your indications. Thanks and regards, Dario Binacchi
Re: XHCI bringup on the Raspberry Pi 4
On 4/1/20 7:30 PM, Nicolas Saenz Julienne wrote: > Hi All, Hi, > I'm working on enabling the VIA805 XCHI controller found on the new Raspberry > Pi 4. The controller sits behind a PCIe bus, which I've already implemented[1] > and will submit once the XCHI issues are resolved, as it's worthless > otherwise. > > The XHCI initialization gets stuck after issuing the fist 'enable slot' > command. I've been reviewing the whole init process and comparing it to > Linux's > for days without finding anything fishy. DMA constraints, which are important > on the RPi are mantained, and on top of that, I can confirm DMA trough PCIe > works fine as I see two 'port status change' events available in the ring > before completly stalling. Also note that, unsurprisingly, the CRR bit in the > CRCR register (which marks the running state of the Command Ring state > machine) > is never set after ringing the relevant doorbell. > > I'm clueless at this point, I figure the VIA805 is sensitive to the ordering > of > some of the operations we perform in u-boot, or worse, the timing. For > example, > I tried replicanting Linux's behaviour with regard to 'port status change' > events, processing them before calling the 'enable slot' command. I also tried > to mimic Linux by enabling port-0's power (the USB3 port) before starting the > HC. Again, no luck. > > I attached the usb/xhci debug output, any ideas on where to look will be > apreciated. Try disabling caches (dcache off ; icache off) and see if it magically starts working. That comes to mind.
Re: [PULL] Pull request: u-boot-stm/master =u-boot-stm32-20200401
On Wed, Apr 01, 2020 at 12:43:44PM +, Patrick DELAUNAY wrote: > Hi Tom, > > Please pull the latest STM32 master bugfix for v2020.04 = > u-boot-stm32-20200401 > > With the following changes: > - Fix device tree of Avenger96 board from Arrow Electronics and add > compatibility with stm32mp15_dhcom_basic_defconfig > > CI status: Failed for vexpress_ca9x4 test.py > https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/2592 > > But local compilation is OK with buildman on stm32 targets. > I think it is enough as the Marek's patches only update the dh board code and > the AV96 device tree. > > Thanks, > Patrick > > The following changes since commit af827140e5965e5bb2bcad1c53ca8419b428ff6d: > > vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader. > (2020-03-23 16:11:46 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git > tags/u-boot-stm32-20200401 > > for you to fetch changes up to 2f3c4b8a0f303edbea9fc112a49e546cf03776b0: > > ARM: dts: stm32: Repair PMIC configuration on AV96 (2020-04-01 11:58:00 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: u-boot DT configuration node
> From: Michal Simek > Date: Wed, 1 Apr 2020 11:23:13 +0200 > > Hi Rob and others, > > for couple of years already u-boot is using config node in root DT for > u-boot configuration. > > Here is one example in u-boot source code. > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 > > And here is dt binding description > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt > > I was checking dt binding specification and there no such a thing > described there. It means I expect this is more adhoc u-boot solution. > We have reached the point where could be beneficial to put some u-boot > specific configurations to DT. > > Actually I have done similar thing some time ago too by using chosen > node and add xilinx specific property there to point to eeprom. > https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 > > I think it is a time to discuss it and do it properly. > > First of all my question is where we could list SW prefixes to make sure > that they are listed and everybody is aware about it. We have > vendor-prefixes and we should have a way to record also prefixes for sw > projects. U-Boot is using u-boot. Xen has file in the kernel with using > xen prefix. At least these two should be listed. OpenBSD is using "openbsd," as a prefix. I've always thought it would be good to have it listed in the list of vendor prefixes there. In an open source world it shouldn't matter whether an entity sells something or not. And in fact "inux," is already there. And so is "qemu,". > Next my question is what is the recommended way to pass sw specific > parameters via DT? I think using chosen node is more appropriate then > adhoc config node. Or is there a better way how this should be done? On OpenBSD we do indeed use the the chosen node to pass information between the bootloader and the kernel. Cheers, Mark
Re: [PATCH 09/16] efi_loader: imply FAT, FAT_WRITE
> Date: Wed, 1 Apr 2020 09:31:03 +0900 > From: AKASHI Takahiro > > On Tue, Mar 31, 2020 at 10:20:17AM +0200, Mark Kettenis wrote: > > > Date: Tue, 31 Mar 2020 16:44:34 +0900 > > > From: AKASHI Takahiro > > > > > > On Tue, Mar 31, 2020 at 08:44:02AM +0200, Heinrich Schuchardt wrote: > > > > On March 31, 2020, 5:28 a.m. UTC Takahiro Akashi wrote: > > > > > On Fri, Mar 27, 2020 at 06:27:53AM +0100, Heinrich Schuchardt wrote: > > > > > > The UEFI spec requires support for the FAT file system. > > > > > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > > > --- > > > > > > lib/efi_loader/Kconfig | 2 ++ > > > > > > 1 file changed, 2 insertions(+) > > > > > > > > > > > > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig > > > > > > index 9890144d41..e10ca05549 100644 > > > > > > --- a/lib/efi_loader/Kconfig > > > > > > +++ b/lib/efi_loader/Kconfig > > > > > > @@ -15,6 +15,8 @@ config EFI_LOADER > > > > > > select HAVE_BLOCK_DEVICE > > > > > > select REGEX > > > > > > imply CFB_CONSOLE_ANSI > > > > > > + imply FAT > > > > > > + imply FAT_WRITE > > > > > > > > > > Obviously, this *imply* doesn't enforce enabling FAT. > > > > > If it is absolutely necessary, another measure should be taken. > > > > > > > > If somebody wants to minimize the U-Boot size it might be necessary to > > > > do without FAT_WRITE or FAT support. > > > > > > If so, Get/SetVariable won't be supported even in boot time > > > with your patch applied. It is not practical for almost all users. > > > > I *strongly* disagree with that statement. Most users don't care > > about U-Boot providing a full EFI implementation. They just want to > > boot their OS. The basic EFI support in U-Boot is good enough for > > that and for OpenBSD and some Linux distros on arm/arm64 this is the > > only bootpath that works. If adding more code leads to board > > maintainers disabling EFI support this isn't helpful. > > Okay, so can you please describe the minimum set of functionality > for you? Without that, the discussion will not be fair. For OpenBSD/arm and OpenBSD/amr64 we adopted the UEFI interfaces in u-boot early on, even before most Linux distros did. As a result our requirements are very minimal: Our bootloader uses the folowing boot services: - HandleProtocol() - AllocatePages() - FreePages() - LocateHandle() - LocateHandleBuffer() - LocateProtocol() - CreateEvent() - SetTimer() - WaitForEvent() - CloseEvent() - GetMemoryMap() - SetWatchdogTimer() - Exit() runtime services: - ResetSystem() and protocols: - EFI_LOADED_IMAGE_PROTOCOL - EFI_DEVICE_PATH_PROTOCOL - EFI_BLOCK_IO_PROTOCOL - EFI_GRAPHICS_OUTPUT_PROTOCOL - EFI_RNG_PROTOCOL - EFI_SIMPLE_NETWORK_PROTOCOL - EFI_PXE_BASE_CODE_PROTOCOL Obviously the last four are only used if there is actual hardware to support these protocols. But I'd consider them non-optional if such hardware exists. Our kernel only uses a couple if runtime services: - SetVirtualAddressMap() - GetTime() (optional) - SetTime() (optional) Cheers, Mark
iMX8MM USB support?
Peng, It looks like IMX8MM USB support hasn't made it upstream yet. Is this something your working on? I'm interested in booting an IMX8MM via SDP. Best Regards, Tim
Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
Hi Andy, On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko wrote: > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote: > > Hi Andy, > > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko > > wrote: > > > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng wrote: > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko > > > > wrote: > > > > > > > > > > The commit breaks serial console on the Intel Edison. > > > > > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > > > > > > > > > Signed-off-by: Andy Shevchenko > > > > > --- > > > > > drivers/serial/ns16550.c | 40 > > > > > > > > > > 1 file changed, 12 insertions(+), 28 deletions(-) > > > > > > > > > > > > > Could you please spend some time to investigate why this breaks Intel > > > > Edison? > > > > > > > > Reverting this patch would mean we break other boards too as > > > > Wolfgang's patch wanted to fix the breakage in the first place. Much > > > > appreciated! > > > > > > I guess I'm wrong person here. The DM code is a complete black box to me. > > > Nevertheless, I may test any provided fix / debug / etc patch by request. > > > > > > And I think it's fair to investigate by the one who made a regression > > > in the first place. > > > > Given that we have conflicting breakages, we need to debug Edison. > > I would glad to test any suggested change or debug patch! > > > Does it enable the debug UART? > > If I am not mistaken, it does not. Looks like you are right. If you know the address you could do that - see minnowmax for an example. - Simon
Re: [PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96
Hi,
On Wed, Apr 01, 2020 at 04:49:45PM +, Gerald BAEZA wrote:
> Hi Marek and Patrick
>
> > From: Marek Vasut
> > Sent: mercredi 1 avril 2020 13:09
> >
> > On 4/1/20 12:24 PM, Patrick DELAUNAY wrote:
> > > Hi Gerald and Manivannan,
> >
> > Hi,
> >
> > >> From: Marek Vasut
> > >> Sent: mardi 31 mars 2020 19:52
> > >>
> > >> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and
> > >> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which
> > >> can not easily divide the clock down to e.g. 50 MHz for high speed SD
> > >> and eMMC devices, so those devices end up running at 30 MHz as that is
> > 120 MHz / 4.
> > >> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100
> > >> MHz instead, which is easy to divide to 50MHz for optimal operation
> > >> of both SD and eMMC, SPDIF clock are not that much slower and FDCAN is
> > also unaffected.
>
> As far as I see, SPDIF is not supported on Avenger board so we don't care for
> this one.
> FDCAN can be supported via the expansion connector, so better to keep it high
> (and < 100 MHz).
> Be careful because the LTDC pixel clock also comes from the PLL4Q and it is
> used for the HDMI on Avenger.
> The pixel clock is very constraint and I am surprised by the initial 40 MHz
> configuration (that becomes 50 MHz with your patch).
> I would recommend to align the Avenger configuration to ST boards one, that
> is the best compromise found so far (99 MHz for SDMMC and 74.250 MHz for
> HDMI):
> https://wiki.st.com/stm32mpu/wiki/STM32MP15_clock_tree
> /* VCO = 594.0 MHz => P = 99, Q = 74, R = 74 */
> pll4: st,pll@3 {
> cfg = < 3 98 5 7 7 PQR(1,1,1) >;
> u-boot,dm-pre-reloc;
> };
>
This looks good to me.
> > >> Reviewed-by: Patrice Chotard
> > >> Reviewed-by: Patrick Delaunay
> > >> Signed-off-by: Marek Vasut
> > >> Cc: Manivannan Sadhasivam
> > >> Cc: Patrick Delaunay
> > >> Cc: Patrice Chotard
> > >> ---
> > >> V2: Move this patch before the split of AV96 into SoM and carrier
> > >> V3: No change
> > >> ---
> > >
> > > This patch update the PLL4 frequency used on AV96 board, with
> > > different of reference clock tree used on ST board, this new setting
> > > allow to optimize the SDMMC frequency (50MHz vs 30Mz).
> > >
> > > I don't know why the previous PLL4 frequency was chosen as a
> > > compromise on reference clock-tree (PLL4 is used by mostly all the
> > > peripheral, with display and audio requirements).
> > >
> > > Can you cross check the proposed clock tree and ack this patch if
> > > these ST requirements are not applicable on AV96 board.
> > >
> > > Anyway the code is correct.
> >
> > Likely because these PLL settings are being copied from reference platform
> > to other platforms etc.
>
> As far as I remember, we never had this configuration for PLL4 on ST boards,
> so the copy certainly comes from somewhere else.
>
I took the PLL settings from Downstream code done by Arrow at that time. Since
I never had access to PMIC info, I just used them blindly since that worked for
initial upstream bringup on old board. We had several discussions about PMIC
at that time but never touched PLL4.
So feel free to modify it as Gerald suggested.
Thanks,
Mani
> > But I did notice one odd thing, which is when running the SD1 in SDR104, the
> > read data transfers can be unstable, which I suspect is because the bus runs
> > at actual 100 MHz instead of some 60 MHz. I need to look at that with a
> > scope, so that's to be checked. For now I turned the SDR104 off.
>
Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote: > Hi Andy, > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko > wrote: > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng wrote: > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko > > > wrote: > > > > > > > > The commit breaks serial console on the Intel Edison. > > > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > > > > > > > Signed-off-by: Andy Shevchenko > > > > --- > > > > drivers/serial/ns16550.c | 40 > > > > 1 file changed, 12 insertions(+), 28 deletions(-) > > > > > > > > > > Could you please spend some time to investigate why this breaks Intel > > > Edison? > > > > > > Reverting this patch would mean we break other boards too as > > > Wolfgang's patch wanted to fix the breakage in the first place. Much > > > appreciated! > > > > I guess I'm wrong person here. The DM code is a complete black box to me. > > Nevertheless, I may test any provided fix / debug / etc patch by request. > > > > And I think it's fair to investigate by the one who made a regression > > in the first place. > > Given that we have conflicting breakages, we need to debug Edison. I would glad to test any suggested change or debug patch! > Does it enable the debug UART? If I am not mistaken, it does not. -- With Best Regards, Andy Shevchenko
XHCI bringup on the Raspberry Pi 4
Hi All, I'm working on enabling the VIA805 XCHI controller found on the new Raspberry Pi 4. The controller sits behind a PCIe bus, which I've already implemented[1] and will submit once the XCHI issues are resolved, as it's worthless otherwise. The XHCI initialization gets stuck after issuing the fist 'enable slot' command. I've been reviewing the whole init process and comparing it to Linux's for days without finding anything fishy. DMA constraints, which are important on the RPi are mantained, and on top of that, I can confirm DMA trough PCIe works fine as I see two 'port status change' events available in the ring before completly stalling. Also note that, unsurprisingly, the CRR bit in the CRCR register (which marks the running state of the Command Ring state machine) is never set after ringing the relevant doorbell. I'm clueless at this point, I figure the VIA805 is sensitive to the ordering of some of the operations we perform in u-boot, or worse, the timing. For example, I tried replicanting Linux's behaviour with regard to 'port status change' events, processing them before calling the 'enable slot' command. I also tried to mimic Linux by enabling port-0's power (the USB3 port) before starting the HC. Again, no luck. I attached the usb/xhci debug output, any ideas on where to look will be apreciated. Regards, Nicolas [1] https://github.com/vianpl/u-boot/commits/brcm-pcie U-Boot 2020.04-rc4-00037-gfcf9b64659-dirty (Apr 01 2020 - 18:49:34 +0200) DRAM: 3.9 GiB RPI 4 Model B (0xc03111) MMC: mmcnr@7e30: 1, emmc2@7e34: 0 Loading Environment from FAT... *** Warning - bad CRC, using default environment In:serial Out: vidconsole Err: vidconsole Net: eth0: ethernet@7d58 starting USB... No working controllers found Hit any key to stop autoboot: 0 U-Boot> pci start Scanning PCI devices on bus 0 BusDevFun VendorId DeviceId Device Class Sub-Class _ 00.00.00 0x14e4 0x2711 Bridge device 0x04 U-Boot> usb start starting USB... Bus xhci_pci: XHCI-PCI init hccr 0006 and hcor 00060020 hc_length 32 xhci_register: dev='xhci_pci', ctrl=3db41600, hccr=0006, hcor=00060020 // Halt the HC: 00060020 // Reset the HC Register 5000420 NbrPorts 5 Starting the controller USB XHCI 1.00 scanning bus xhci_pci for devices... xhci_alloc_device: dev='xhci_pci', udev=3db230c0 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 xhci_submit_control_msg: dev='xhci_pci', udev=3db230c0, udev->dev='xhci_pci', portnr=0 USB_REQ_SET_ADDRESS scrlen = 0 req->length = 0 Len is 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 xhci_submit_control_msg: dev='xhci_pci', udev=3db230c0, udev->dev='xhci_pci', portnr=0 USB_DT_DEVICE request scrlen = 18 req->length = 18 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 xhci_submit_control_msg: dev='xhci_pci', udev=3db230c0, udev->dev='xhci_pci', portnr=0 USB_DT_CONFIG config scrlen = 25 req->length = 9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x1F xhci_submit_control_msg: dev='xhci_pci', udev=3db230c0, udev->dev='xhci_pci', portnr=0 USB_DT_CONFIG config scrlen = 25 req->length = 31 get_conf_no 0 Result 25, wLength 31 if 0, ep 0 ##EP epmaxpacketin[1] = 8 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 xhci_submit_control_msg: dev='xhci_pci', udev=3db230c0, udev->dev='xhci_pci', portnr=0 scrlen = 0 req->length = 0 Len is 0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF xhci_submit_control_msg: dev='xhci_pci', udev=3db230c0, udev->dev='xhci_pci', portnr=0 USB_DT_STRING config scrlen = 4 req->length = 255 USB device number 1 default language ID 0x409 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x409 length 0xFF xhci_submit_control_msg: dev='xhci_pci', udev=3db230c0, udev->dev='xhci_pci', portnr=0 USB_DT_STRING config scrlen = 14 req->length = 255 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x409 length 0xFF xhci_submit_control_msg: dev='xhci_pci', udev=3db230c0, udev->dev='xhci_pci', portnr=0 USB_DT_STRING config scrlen = 42 req->length = 255 Manufacturer U-Boot Product XHCI Host Controller SerialNumber usb_hub_post_probe usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0x4 xhci_submit_control_msg: dev='xhci_pci', udev=3db43300, udev->dev='usb_hub', portnr=0 USB_DT_HUB config scrlen = 8 req->length = 4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2A00 index 0x0 length 0xC xhci_submit_control_msg: dev='xhci_pci', udev=3db43300, udev->dev='usb_hub', portnr=0
Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
Hi Andy, On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko wrote: > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng wrote: > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko > > wrote: > > > > > > The commit breaks serial console on the Intel Edison. > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > > > > > Signed-off-by: Andy Shevchenko > > > --- > > > drivers/serial/ns16550.c | 40 > > > 1 file changed, 12 insertions(+), 28 deletions(-) > > > > > > > Could you please spend some time to investigate why this breaks Intel > > Edison? > > > > Reverting this patch would mean we break other boards too as > > Wolfgang's patch wanted to fix the breakage in the first place. Much > > appreciated! > > I guess I'm wrong person here. The DM code is a complete black box to me. > Nevertheless, I may test any provided fix / debug / etc patch by request. > > And I think it's fair to investigate by the one who made a regression > in the first place. Given that we have conflicting breakages, we need to debug Edison. Does it enable the debug UART? I have one but have not powered it on for a while, nor added it to my lab. Regards, Simon
Re: [PULL] Pull request: u-boot-stm/master =u-boot-stm32-20200401
On 4/1/20 3:47 PM, Tom Rini wrote: > On Wed, Apr 01, 2020 at 12:43:44PM +, Patrick DELAUNAY wrote: >> Hi Tom, >> >> Please pull the latest STM32 master bugfix for v2020.04 = >> u-boot-stm32-20200401 >> >> With the following changes: >> - Fix device tree of Avenger96 board from Arrow Electronics and add >> compatibility with stm32mp15_dhcom_basic_defconfig >> >> CI status: Failed for vexpress_ca9x4 test.py >> https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/2592 > > So, this failed because we tried, again, to run a test that we're > supposed to be skipping. I both want to know _why_ this keeps happening > but also think we really need to update the vexpress config such that > EFI tests are not skipped and we have the device tree available (via > fdt_addr or fdtcontroladdr environment variable). Thanks! > Hello Tom, this repository contains Kristian Amlie's problematic vexpress_ca9x4 patch but has not been rebased upon current origin/master. This is why the patch for skipping the test is missing. We get all those warnings below. On the other hand I think the only virtue of all the vexpress configurations is testing that our legacy non-DM code is running. = WARNING == This board does not use CONFIG_DM. CONFIG_DM will be compulsory starting with the v2020.01 release. Failure to update may result in board removal. See doc/driver-model/migration.rst for more info. = WARNING == This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. = WARNING == This board does not use CONFIG_DM_ETH (Driver Model for Ethernet drivers). Please update the board to use CONFIG_DM_ETH before the v2020.07 release. Failure to update by the deadline may result in board removal. See doc/driver-model/migration.rst for more info. Best regards Heinrich
Re: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
On Wed, Apr 01, 2020 at 02:03:09AM +0200, Tom Warren wrote:
> -Original Message-
> From: Peter Robinson
> Sent: Tuesday, March 31, 2020 3:54 AM
> To: tomcwarren3...@gmail.com
> Cc: u-boot@lists.denx.de; Stephen Warren ; Thierry Reding
> ; Jonathan Hunter ; Tom Warren
> ; Vishruth Jain
> Subject: Re: [PATCH 3/3] ARM: tegra: p2371-2180: add I2C nodes to DT
>
> External email: Use caution opening links or attachments
>
>
> > From: Stephen Warren
> >
> > This adds to the DT the I2C controllers that connect to the board ID
> > EEPROM, camera board EEPROM, etc. With this change, you can now probe
> > all I2C devices on a TX1 board.
> >
> > Signed-off-by: Tom Warren
> > ---
> > arch/arm/dts/tegra210-p2371-2180.dts | 18 ++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/arch/arm/dts/tegra210-p2371-2180.dts
> > b/arch/arm/dts/tegra210-p2371-2180.dts
> > index c2f497c..d982b5f 100644
> > --- a/arch/arm/dts/tegra210-p2371-2180.dts
> > +++ b/arch/arm/dts/tegra210-p2371-2180.dts
> > @@ -12,6 +12,9 @@
> >
> > aliases {
> > i2c0 = "/i2c@7000d000";
> > + i2c2 = "/i2c@7000c400";
> > + i2c3 = "/i2c@7000c500";
> > + i2c5 = "/i2c@546c0c00";
>
> I don't think this is correct, it doesn't show up in U-Boot with the
> "i2c bus" command where the others do, looking in the tegra210.dtsi it
> looks like it should be i2c@546c?
> [Tom] That I2C address is working in downstream (L4T) TX1 U-Boot. The
> VI_I2C controller is a little weird, it's normal I2C registers are
> offset from base by 0xC00. A different driver is needed, but I
> haven't posted it yet upstream. I should probably drop if from the
> DTS for now until I post the VI_I2C driver.
I think the problem here is that the upstream U-Boot device tree doesn't
contain an i2c@546c0c00 node. Instead it has i2c@546c, which we also
have in the upstream kernel. My recollection is that that's also the
address listed in the Tegra210 system address map of the TRM and there
are some registers before the regular I2C interface at offset 0xc00.
I've been carrying a patch against the upstream Linux I2C controller
driver to special-case the VI/I2C to always add that 0xc00 offset when
accessing registers, which allows us to reuse the existing driver and at
the same time keeps all registers mapped so we can also access the
VI/I2C specific registers.
My recollection is that the U-Boot driver is fairly similar to the Linux
driver, so I suspect something similar could be done.
Thierry
signature.asc
Description: PGP signature
[PATCH] ARM: stm32: Enable bootd, iminfo, imxtract on DHCOM
Enable these standard U-Boot commands for image manipulation and for starting the default boot command using 'boot' command in U-Boot shell. Signed-off-by: Marek Vasut Cc: Patrick Delaunay Cc: Patrice Chotard --- configs/stm32mp15_dhcom_basic_defconfig | 3 --- 1 file changed, 3 deletions(-) diff --git a/configs/stm32mp15_dhcom_basic_defconfig b/configs/stm32mp15_dhcom_basic_defconfig index 683f15e7d5..f830feb306 100644 --- a/configs/stm32mp15_dhcom_basic_defconfig +++ b/configs/stm32mp15_dhcom_basic_defconfig @@ -19,10 +19,7 @@ CONFIG_SPL_MTD_SUPPORT=y CONFIG_SPL_POWER_SUPPORT=y CONFIG_SYS_SPI_U_BOOT_OFFS=0x8 CONFIG_SYS_PROMPT="STM32MP> " -# CONFIG_CMD_BOOTD is not set # CONFIG_CMD_ELF is not set -# CONFIG_CMD_IMI is not set -# CONFIG_CMD_XIMG is not set # CONFIG_CMD_EXPORTENV is not set CONFIG_CMD_EEPROM=y CONFIG_CMD_MEMINFO=y -- 2.25.1
Please pull u-boot-dm
Hi Tom, I ran a check yesterday but have started a new one after rebasing today: https://gitlab.denx.de/u-boot/custodians/u-boot-dm/pipelines/2598 The following changes since commit 7dbafe06348ebf28044ef9769bf24866a3deedea: Merge tag 'arc-last-minute-fixes-for-2020.04' of https://gitlab.denx.de/u-boot/custodians/u-boot-arc (2020-03-31 15:10:54 -0400) are available in the Git repository at: git://git.denx.de/u-boot-dm.git tags/dm-pull-1apr20 for you to fetch changes up to 0e29648f8e7e0aa60c0f7efe9d2efed98f8c0c6e: test: vboot: Reduce fake kernel size to 500 bytes (2020-04-01 07:45:09 -0600) Vboot vulnerability fix Simon Glass (14): image: Correct comment for fit_conf_get_node() image: Be a little more verbose when checking signatures image: Return an error message from fit_config_verify_sig() test: vboot: Drop unnecessary parameter for fit_check_sign test: vboot: Add a test for a forged configuration test: vboot: Parameterise the test image: Check hash-nodes when checking configurations image: Load the correct configuration in fit_check_sign fit_check_sign: Allow selecting the configuration to verify test: vboot: Tidy up the code a little test: vboot: Fix pylint errors image: Use constants for 'required' and 'key-name-hint' test: vboot: Move key creation into a function test: vboot: Reduce fake kernel size to 500 bytes common/bootm.c | 6 +- common/image-cipher.c| 2 +- common/image-fit.c | 26 +-- common/image-sig.c | 49 - include/image.h | 24 ++- lib/rsa/rsa-sign.c | 6 +- test/py/tests/test_vboot.py | 155 test/py/tests/vboot_forge.py | 423 +++ tools/fdt_host.h | 3 +- tools/fit_check_sign.c | 8 +- tools/image-host.c | 17 +- 11 files changed, 601 insertions(+), 118 deletions(-) create mode 100644 test/py/tests/vboot_forge.py Regards, Simon
Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
On Wed, Apr 1, 2020 at 5:32 PM Bin Meng wrote: > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko > wrote: > > > > The commit breaks serial console on the Intel Edison. > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > > > Signed-off-by: Andy Shevchenko > > --- > > drivers/serial/ns16550.c | 40 > > 1 file changed, 12 insertions(+), 28 deletions(-) > > > > Could you please spend some time to investigate why this breaks Intel Edison? > > Reverting this patch would mean we break other boards too as > Wolfgang's patch wanted to fix the breakage in the first place. Much > appreciated! I guess I'm wrong person here. The DM code is a complete black box to me. Nevertheless, I may test any provided fix / debug / etc patch by request. And I think it's fair to investigate by the one who made a regression in the first place. -- With Best Regards, Andy Shevchenko
[PATCH v2] Revert "common: spl_fit: Default to IH_OS_U_BOOT if FIT_IMAGE_TINY enabled"
Commit cf8dcc5d02c3 ("common: spl_fit: Default to IH_OS_U_BOOT if
FIT_IMAGE_TINY enabled") is not correct, it will append fdt to each loadable
image. Actually when using TINY FIT, the first loadable image is thought as
u-boot and already have fdt appended.
Signed-off-by: Ye Li
Tested-by: Fabio Estevam
---
Changes in v2:
- Update the revert commit log to use kernel style
common/spl/spl_fit.c | 4
1 file changed, 4 deletions(-)
diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index aef1dbd..69dabd2 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -646,10 +646,6 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
if (!spl_fit_image_get_os(fit, node, _type))
debug("Loadable is %s\n", genimg_get_os_name(os_type));
-#if CONFIG_IS_ENABLED(FIT_IMAGE_TINY)
- else
- os_type = IH_OS_U_BOOT;
-#endif
if (os_type == IH_OS_U_BOOT) {
spl_fit_append_fdt(_info, info, sector,
--
2.7.4
Re: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
Hi Andy, On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko wrote: > > The commit breaks serial console on the Intel Edison. > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > Signed-off-by: Andy Shevchenko > --- > drivers/serial/ns16550.c | 40 > 1 file changed, 12 insertions(+), 28 deletions(-) > Could you please spend some time to investigate why this breaks Intel Edison? Reverting this patch would mean we break other boards too as Wolfgang's patch wanted to fix the breakage in the first place. Much appreciated! Regards, Bin
[PATCH v2 2/2] dm: core: Partial revert of "Allocate parent data separate from probing parent"
This reverts commit 82de42fa1468
("dm: core: Allocate parent data separate from probing parent")
as a being a culprit for Apollo Lake breakage.
Suggested-by: Wolfgang Wallner
Signed-off-by: Andy Shevchenko
---
drivers/core/device.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 89ea820d48..400767d9bd 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -392,10 +392,6 @@ int device_probe(struct udevice *dev)
drv = dev->driver;
assert(drv);
- ret = device_ofdata_to_platdata(dev);
- if (ret)
- goto fail;
-
/* Ensure all parents are probed */
if (dev->parent) {
ret = device_probe(dev->parent);
@@ -412,6 +408,10 @@ int device_probe(struct udevice *dev)
return 0;
}
+ ret = device_ofdata_to_platdata(dev);
+ if (ret)
+ goto fail;
+
seq = uclass_resolve_seq(dev);
if (seq < 0) {
ret = seq;
--
2.25.1
[PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
The commit breaks serial console on the Intel Edison.
This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
Signed-off-by: Andy Shevchenko
---
drivers/serial/ns16550.c | 40
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index c1b303ffcb..1fcbc35015 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -479,40 +479,12 @@ static int ns16550_serial_getinfo(struct udevice *dev,
return 0;
}
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
-static int ns1655_serial_set_base_addr(struct udevice *dev)
-{
- fdt_addr_t addr;
- struct ns16550_platdata *plat;
-
- plat = dev_get_platdata(dev);
-
- addr = dev_read_addr_pci(dev);
- if (addr == FDT_ADDR_T_NONE)
- return -EINVAL;
-
-#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
- plat->base = addr;
-#else
- plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE);
-#endif
-
- return 0;
-}
-#endif
-
int ns16550_serial_probe(struct udevice *dev)
{
struct NS16550 *const com_port = dev_get_priv(dev);
struct reset_ctl_bulk reset_bulk;
int ret;
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
- ret = ns1655_serial_set_base_addr(dev);
- if (ret)
- return ret;
-#endif
-
ret = reset_get_bulk(dev, _bulk);
if (!ret)
reset_deassert_bulk(_bulk);
@@ -535,9 +507,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
{
struct ns16550_platdata *plat = dev->platdata;
const u32 port_type = dev_get_driver_data(dev);
+ fdt_addr_t addr;
struct clk clk;
int err;
+ /* try Processor Local Bus device first */
+ addr = dev_read_addr_pci(dev);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+ plat->base = addr;
+#else
+ plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE);
+#endif
+
plat->reg_offset = dev_read_u32_default(dev, "reg-offset", 0);
plat->reg_shift = dev_read_u32_default(dev, "reg-shift", 0);
plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1);
--
2.25.1
Re: Re: [ANN] U-Boot v2020.04-rc4 released
On Wed, Apr 1, 2020 at 3:45 PM Wolfgang Wallner
wrote:
> > On Wed, Apr 1, 2020 at 2:54 PM Andy Shevchenko
> > wrote:
> > >
> > > On Tue, Mar 31, 2020 at 2:31 AM Tom Rini wrote:
> > > >
> > > > Hey all,
> > > >
> > > > So, I've gotten out of the habit of tagging rcs on cycle. This month I
> > > > have been taking in changes sparingly and I'm not concerned that things
> > > > have gone in that wouldn't have, if I had tagged -rc4/rc5 on schedule.
> > > >
> > > > Things have been going to the -next branch as expected, and I think
> > > > that will work out when things open up for v2020.07
> > > >
> > > > So here now is -rc4 and I plan to make the final release on April 6th,
> > > > as scheduled. Thanks all and stay safe out there!
> > >
> > > It becomes a tradition. Intel Edison is broken again (now serial driver).
> > > This is show stopper.
> > >
> > > I'll become later with the culprit commit out of these three:
> > >This reverts commit 1c16606aac8f03be80d9c38ada00fd03123e0dbe.
> > >This reverts commit 62cbde4c4e462e5147d07cf1424492bb39e7bf94.
> > >This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> >
> > And the winner is...
> >
> > 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> >
> > Wolfgang, please, fix ASAP, or revert ASAP!
>
> What exactly does "broken" mean in this case?
> What happens on Intel Edison?
>
> I don't think just reversing commit 720f9e1fdb0c [1] is a good idea, as this
> commit is itself a bug fix for commit 82de42fa1468 [2]. Commit 82de42fa1468
> did break the serial driver on Intel Apollo Lake, see the description of
> commit 720f9e1fdb0c for details on what happened on that platform.
It actually means either your fix is not good enough or dm core is
broken without taking care of the individual drivers.
In any case your patch is a culprit for me.
> regards, Wolfgang
>
> [1] commit 720f9e1fdb0c ("serial: ns16550: Move PCI access from
> ofdata_to_platdata() to probe()")
> [2] commit 82de42fa1468 ("dm: core: Allocate parent data separate from
> probing parent")
--
With Best Regards,
Andy Shevchenko
Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96
On 4/1/20 3:52 PM, Patrick DELAUNAY wrote:
> Hi,
>
>> From: Marek Vasut
>> Sent: mercredi 1 avril 2020 14:53
>> To: Patrice CHOTARD ; Patrick DELAUNAY
>> ; u-boot@lists.denx.de; Pascal PAILLET-LME
>>
>> Cc: Manivannan Sadhasivam ; Alexandre
>> TORGUE
>> Subject: Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on
>> AV96
>> Importance: High
>>
>> On 4/1/20 2:45 PM, Patrice CHOTARD wrote:
>>>
>>> On 4/1/20 1:06 PM, Marek Vasut wrote:
On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
> Hi Marek and Pascal,
Hi,
[...]
> [...]
>> vdd: buck3 {
>> regulator-name = "vdd";
>> -regulator-min-microvolt = <330>;
>> -regulator-max-microvolt = <330>;
>> +regulator-min-microvolt = <290>;
>> +regulator-max-microvolt = <290>;
>> regulator-always-on;
>> st,mask_reset;
>> regulator-initial-mode = <0>;
>> @@ -268,6 +279,7 @@
>> regulator-name = "vbus_otg";
>> interrupts = ;
>> interrupt-parent = <>;
>> +regulator-active-discharge = <1>;
> It seems this setting introduced other-consumption, it should not be used.
Other-consumption ? What does that mean ?
>>>
>>> It's a typo, Patrick means over-consumption.
>>
>> Ah. Do you have any details on that ?
>
> Sorry for typo.
>
> No details on my side, it was a Pascal Paillet's direct feedback
> (Maintainer of STPMIC1 driver in Linux).
>
> Anyway he will review your patch for Linux, with more details,
> and I merge this patch without modification for U-Boot.
OK
RE: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96
Hi,
> From: Marek Vasut
> Sent: mercredi 1 avril 2020 14:53
> To: Patrice CHOTARD ; Patrick DELAUNAY
> ; u-boot@lists.denx.de; Pascal PAILLET-LME
>
> Cc: Manivannan Sadhasivam ; Alexandre
> TORGUE
> Subject: Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on
> AV96
> Importance: High
>
> On 4/1/20 2:45 PM, Patrice CHOTARD wrote:
> >
> > On 4/1/20 1:06 PM, Marek Vasut wrote:
> >> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
> >>> Hi Marek and Pascal,
> >> Hi,
> >>
> >> [...]
[...]
> vdd: buck3 {
> regulator-name = "vdd";
> -regulator-min-microvolt = <330>;
> -regulator-max-microvolt = <330>;
> +regulator-min-microvolt = <290>;
> +regulator-max-microvolt = <290>;
> regulator-always-on;
> st,mask_reset;
> regulator-initial-mode = <0>;
> @@ -268,6 +279,7 @@
> regulator-name = "vbus_otg";
> interrupts = ;
> interrupt-parent = <>;
> +regulator-active-discharge = <1>;
> >>> It seems this setting introduced other-consumption, it should not be used.
> >> Other-consumption ? What does that mean ?
> >
> > It's a typo, Patrick means over-consumption.
>
> Ah. Do you have any details on that ?
Sorry for typo.
No details on my side, it was a Pascal Paillet's direct feedback
(Maintainer of STPMIC1 driver in Linux).
Anyway he will review your patch for Linux, with more details,
and I merge this patch without modification for U-Boot.
Patrick
Re: [PULL] Pull request: u-boot-stm/master =u-boot-stm32-20200401
On Wed, Apr 01, 2020 at 12:43:44PM +, Patrick DELAUNAY wrote: > Hi Tom, > > Please pull the latest STM32 master bugfix for v2020.04 = > u-boot-stm32-20200401 > > With the following changes: > - Fix device tree of Avenger96 board from Arrow Electronics and add > compatibility with stm32mp15_dhcom_basic_defconfig > > CI status: Failed for vexpress_ca9x4 test.py > https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/2592 So, this failed because we tried, again, to run a test that we're supposed to be skipping. I both want to know _why_ this keeps happening but also think we really need to update the vexpress config such that EFI tests are not skipped and we have the device tree available (via fdt_addr or fdtcontroladdr environment variable). Thanks! -- Tom signature.asc Description: PGP signature
RE: [PATCH] ARM: dts: stm32: Define FMC2 base address
Hi Marek, > From: Marek Vasut > Sent: jeudi 26 mars 2020 16:57 > > Define FMC2 base address, for use in board files, until there is an actual > FMC2 > bus driver. > > Signed-off-by: Marek Vasut > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > arch/arm/mach-stm32mp/include/mach/stm32.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm/mach-stm32mp/include/mach/stm32.h b/arch/arm/mach- > stm32mp/include/mach/stm32.h > index f0636005e5..62d95d7f88 100644 > --- a/arch/arm/mach-stm32mp/include/mach/stm32.h > +++ b/arch/arm/mach-stm32mp/include/mach/stm32.h > @@ -13,6 +13,7 @@ > #define STM32_RCC_BASE 0x5000 > #define STM32_PWR_BASE 0x50001000 > #define STM32_DBGMCU_BASE0x50081000 > +#define STM32_FMC2_BASE 0x58002000 For me, the address should be defined in this file only for the few addresses used before device tree avaibility: I want to avoid to have all the device defined here. But normally it is not the case for FMC2, even if I understand the current need, without FMC2 bus driver I will take this patch only it is not possible to get FMC2 address from device tree. > #define STM32_TZC_BASE 0x5C006000 > #define STM32_ETZPC_BASE 0x5C007000 > #define STM32_STGEN_BASE 0x5C008000 > -- > 2.25.1 Regards Patrick
Re: [PULL] u-boot-usb/next
On Mon, Mar 30, 2020 at 11:32:39AM +0200, Marek Vasut wrote: > A couple of fixed/cleans, this is for next: > > The following changes since commit 350c44dfb99017e9147ee07d37a40626bde62250: > > Merge branch '2020-03-27-master-imports' (2020-03-27 17:54:38 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-usb.git next > > for you to fetch changes up to ac28e59a574dd231a4787752d923f618587e3d10: > > usb: Migrate to support live DT for some driver (2020-03-30 03:48:53 > +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] Pull request: u-boot-stm/master =u-boot-stm32-20200401
On 4/1/20 2:43 PM, Patrick DELAUNAY wrote: > Hi Tom, Hi, > Please pull the latest STM32 master bugfix for v2020.04 = > u-boot-stm32-20200401 > > With the following changes: > - Fix device tree of Avenger96 board from Arrow Electronics and add > compatibility with stm32mp15_dhcom_basic_defconfig > > CI status: Failed for vexpress_ca9x4 test.py > https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/2592 > > But local compilation is OK with buildman on stm32 targets. > I think it is enough as the Marek's patches only update the dh board code and > the AV96 device tree. Works well on my AV96, thanks.
Re: Re: [ANN] U-Boot v2020.04-rc4 released
On Wed, Apr 1, 2020 at 3:45 PM Wolfgang Wallner
wrote:
> > On Wed, Apr 1, 2020 at 2:54 PM Andy Shevchenko
> > wrote:
> > > On Tue, Mar 31, 2020 at 2:31 AM Tom Rini wrote:
...
> > > It becomes a tradition. Intel Edison is broken again (now serial driver).
> > > This is show stopper.
> > >
> > > I'll become later with the culprit commit out of these three:
> > >This reverts commit 1c16606aac8f03be80d9c38ada00fd03123e0dbe.
> > >This reverts commit 62cbde4c4e462e5147d07cf1424492bb39e7bf94.
> > >This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> >
> > And the winner is...
> >
> > 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
> >
> > Wolfgang, please, fix ASAP, or revert ASAP!
>
> What exactly does "broken" mean in this case?
> What happens on Intel Edison?
No serial output at all. Kernel boots, but this makes a little sense, really.
> I don't think just reversing commit 720f9e1fdb0c [1] is a good idea,
Okay, then reverting both. I'll send new version of revert soon.
> as this
> commit is itself a bug fix for commit 82de42fa1468 [2]. Commit 82de42fa1468
> did break the serial driver on Intel Apollo Lake, see the description of
> commit 720f9e1fdb0c for details on what happened on that platform.
>
> regards, Wolfgang
>
> [1] commit 720f9e1fdb0c ("serial: ns16550: Move PCI access from
> ofdata_to_platdata() to probe()")
> [2] commit 82de42fa1468 ("dm: core: Allocate parent data separate from
> probing parent")
--
With Best Regards,
Andy Shevchenko
RE: [PATCH V3] ARM: dts: stm32: Add KS8851-16MLL ethernet on FMC2
Hi Marek,
> From: Marek Vasut
> Sent: jeudi 26 mars 2020 16:58
>
> Add DT entries, Kconfig entries and board-specific entries to configure
> FMC2 bus and make KS8851-16MLL on that bus accessible to U-Boot.
>
> Signed-off-by: Marek Vasut
> Cc: Patrick Delaunay
> Cc: Patrice Chotard
> ---
> V2: Configure FMC2 nCS4 for SRAM as well
> V3: Adjust the register macros
> ---
> arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi | 68 ++
> board/dhelectronics/dh_stm32mp1/board.c| 28 +
> configs/stm32mp15_dhcom_basic_defconfig| 1 +
> 3 files changed, 97 insertions(+)
>
> diff --git a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> index 6c952a57ee..eba3588540 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcom-u-boot.dtsi
> @@ -37,6 +37,12 @@
> default-state = "on";
> };
> };
> +
> + /* This is actually on FMC2, but we do not have bus driver for that */
> + ksz8851: ks8851mll@6400 {
> + compatible = "micrel,ks8851-mll";
> + reg = <0x6400 0x2>;
> + };
> };
>
> {
> @@ -50,6 +56,68 @@
> };
> };
>
> + {
> + /* These should bound to FMC2 bus driver, but we do not have one */
As temporarily solution (waiting final solution and real FMC2 bus driver)
can you define a NO_OP in board device associated to existing compatible
= "st,stm32mp15-fmc2"
> + pinctrl-0 = <_pins_b>;
> + pinctrl-1 = <_sleep_pins_b>;
> + pinctrl-names = "default", "sleep";
> +
> + fmc_pins_b: fmc-0 {
> + pins1 {
[...]
> + };
> + };
> +
> + fmc_sleep_pins_b: fmc-sleep-0 {
> + pins {
[...]
> + };
> + };
> +};
> +
> {
> u-boot,dm-pre-reloc;
> };
For example
{
pinctrl-names = "default", "sleep";
pinctrl-0 = <& fmc_pins_b>;
pinctrl-1 = <& fmc_sleep_pins_b>;
status = "okay";
#address-cells = <1>;
#size-cells = <0>;
};
static const struct udevice_id stm32_fmc2_bus_ids[] = {
{.compatible = "st,stm32mp15-fmc2},
{ }
};
U_BOOT_DRIVER(stm32_fmc2_bus) = {
.name = "stm32mp15-fmc2-ids",
.id = UCLASS_NOP,
.of_match = stm32_fmc2_bus_ids,
.bind = stm32_fmc2_bus,
};
> diff --git a/board/dhelectronics/dh_stm32mp1/board.c
> b/board/dhelectronics/dh_stm32mp1/board.c
> index b663696983..be55242799 100644
> --- a/board/dhelectronics/dh_stm32mp1/board.c
> +++ b/board/dhelectronics/dh_stm32mp1/board.c
> @@ -376,6 +376,32 @@ static void sysconf_init(void) #endif }
>
> +static void board_init_fmc2(void)
> +{
Can you use device-tree information (to avoid hardcoded address
STM32_FMC2_BASE).
For me, the address should be used only when the information are
not available in device tree or before the device tree availability (in
pre-reloc phasis)
ofnode = ofnode_by_compatible(ofnode_null(), "st,stm32mp15-fmc2");
fmc2_addr = ofnode_get_addr(node);
or use NOP device as proposed previously.
PS: it is a preliminary step/temporarily solution, waiting FMC2 the bus driver
availability.
> +#define STM32_FMC2_BCR1 0x0
> +#define STM32_FMC2_BTR1 0x4
> +#define STM32_FMC2_BWTR1 0x104
> +#define STM32_FMC2_BCR(x)((x) * 0x8 + STM32_FMC2_BCR1)
> +#define STM32_FMC2_BTR(x)((x) * 0x8 + STM32_FMC2_BTR1)
> +#define STM32_FMC2_BWTR(x) ((x) * 0x8 + STM32_FMC2_BWTR1)
> +
> +#define RCC_MP_AHB6RSTCLRR 0x218
> +#define RCC_MP_AHB6ENSETR0x19c
> +
> + /* Set up FMC2 bus for KS8851-16MLL and X11 SRAM */
> + writel(BIT(12), STM32_RCC_BASE + RCC_MP_AHB6RSTCLRR);
> + writel(BIT(12), STM32_RCC_BASE + RCC_MP_AHB6ENSETR);
Use clk and reset driver model and DT, for example:
struct clk clk;
struct reset_ctl reset;
clk_get_by_index_nodev(ofnode, 0, ;
clk_get_by_index_nodev(ofnode, 0, );
> + /* KS8851-16MLL */
> + writel(0x10db, STM32_FMC2_BASE + STM32_FMC2_BCR(1));
> + writel(0xc002, STM32_FMC2_BASE + STM32_FMC2_BTR(1));
> + /* AS7C34098 SRAM on X11 */
> + writel(0x10db, STM32_FMC2_BASE + STM32_FMC2_BCR(3));
> + writel(0xc002, STM32_FMC2_BASE + STM32_FMC2_BTR(3));
> +
> + setbits_le32(STM32_FMC2_BASE + STM32_FMC2_BCR1, BIT(31)); }
> +
> /* board dependent setup after realloc */ int board_init(void) { @@ -399,6
> +425,8
> @@ int board_init(void)
>
> sysconf_init();
>
> + board_init_fmc2();
> +
> if (CONFIG_IS_ENABLED(CONFIG_LED))
> led_default_state();
>
> diff --git a/configs/stm32mp15_dhcom_basic_defconfig
> b/configs/stm32mp15_dhcom_basic_defconfig
> index 921dea242a..683f15e7d5 100644
> --- a/configs/stm32mp15_dhcom_basic_defconfig
> +++ b/configs/stm32mp15_dhcom_basic_defconfig
> @@ -93,6 +93,7 @@ CONFIG_SPI_FLASH_MTD=y
> CONFIG_SPL_SPI_FLASH_MTD=y CONFIG_DM_ETH=y
> CONFIG_DWC_ETH_QOS=y
> +CONFIG_KS8851_MLL=y
Re: [PATCH V3 08/14] ARM: dts: stm32: Add configuration EEPROM on AV96
On 4/1/20 12:02 PM, Patrick DELAUNAY wrote: > Hi, Hi, >> From: Marek Vasut >> Sent: mardi 31 mars 2020 19:52 >> >> The board has an EEPROM on the same I2C bus as PMIC, at address 0x53. >> The EEPROM contains the board MAC address. >> >> Reviewed-by: Patrice Chotard >> Reviewed-by: Patrick Delaunay >> Signed-off-by: Marek Vasut >> Cc: Manivannan Sadhasivam >> Cc: Patrick Delaunay >> Cc: Patrice Chotard >> --- > > Applied to u-boot-stm/master, with one minor modification > > I also add the alias eeprom0 = (with eeprom0: eeprom@53) to be > compatible > with previous patch "ARM: dts: stm32: Use DT alias for the configuration > EEPROM" Thanks, this was in 14/14, but got omitted here.
Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96
On 4/1/20 2:45 PM, Patrice CHOTARD wrote:
>
> On 4/1/20 1:06 PM, Marek Vasut wrote:
>> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
>>> Hi Marek and Pascal,
>> Hi,
>>
>> [...]
>>
@@ -167,7 +178,7 @@
vddcore: buck1 {
regulator-name = "vddcore";
- regulator-min-microvolt = <120>;
+ regulator-min-microvolt = <80>;
>>> I don't understood this modification, If I correctly remember, on
>>> STM32MP15x
>>> On ST boards, we set this value to 120 to protect VDDCORE on
>>> SOC (it is not allowed to be reduce lower than 1,2V.
>>>
>>> 0.8V is the minimal supported voltage by STPMIC but not the minal expected
>>> VDDCORE.
>> Then we should likely drop this part.
>>
>> That said, is the core voltage supposed to be 1V2 even in sleep states ?
>>
@@ -185,8 +196,8 @@
vdd: buck3 {
regulator-name = "vdd";
- regulator-min-microvolt = <330>;
- regulator-max-microvolt = <330>;
+ regulator-min-microvolt = <290>;
+ regulator-max-microvolt = <290>;
regulator-always-on;
st,mask_reset;
regulator-initial-mode = <0>;
@@ -268,6 +279,7 @@
regulator-name = "vbus_otg";
interrupts = ;
interrupt-parent = <>;
+ regulator-active-discharge = <1>;
>>> It seems this setting introduced other-consumption, it should not be used.
>> Other-consumption ? What does that mean ?
>
> It's a typo, Patrick means over-consumption.
Ah. Do you have any details on that ?
Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96
On 4/1/20 1:06 PM, Marek Vasut wrote:
> On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
>> Hi Marek and Pascal,
> Hi,
>
> [...]
>
>>> @@ -167,7 +178,7 @@
>>>
>>> vddcore: buck1 {
>>> regulator-name = "vddcore";
>>> - regulator-min-microvolt = <120>;
>>> + regulator-min-microvolt = <80>;
>> I don't understood this modification, If I correctly remember, on STM32MP15x
>> On ST boards, we set this value to 120 to protect VDDCORE on
>> SOC (it is not allowed to be reduce lower than 1,2V.
>>
>> 0.8V is the minimal supported voltage by STPMIC but not the minal expected
>> VDDCORE.
> Then we should likely drop this part.
>
> That said, is the core voltage supposed to be 1V2 even in sleep states ?
>
>>> @@ -185,8 +196,8 @@
>>>
>>> vdd: buck3 {
>>> regulator-name = "vdd";
>>> - regulator-min-microvolt = <330>;
>>> - regulator-max-microvolt = <330>;
>>> + regulator-min-microvolt = <290>;
>>> + regulator-max-microvolt = <290>;
>>> regulator-always-on;
>>> st,mask_reset;
>>> regulator-initial-mode = <0>;
>>> @@ -268,6 +279,7 @@
>>> regulator-name = "vbus_otg";
>>> interrupts = ;
>>> interrupt-parent = <>;
>>> + regulator-active-discharge = <1>;
>> It seems this setting introduced other-consumption, it should not be used.
> Other-consumption ? What does that mean ?
It's a typo, Patrick means over-consumption.
Patrice
Antwort: Re: [ANN] U-Boot v2020.04-rc4 released
Hi Andy,
> On Wed, Apr 1, 2020 at 2:54 PM Andy Shevchenko
> wrote:
> >
> > On Tue, Mar 31, 2020 at 2:31 AM Tom Rini wrote:
> > >
> > > Hey all,
> > >
> > > So, I've gotten out of the habit of tagging rcs on cycle. This month I
> > > have been taking in changes sparingly and I'm not concerned that things
> > > have gone in that wouldn't have, if I had tagged -rc4/rc5 on schedule.
> > >
> > > Things have been going to the -next branch as expected, and I think
> > > that will work out when things open up for v2020.07
> > >
> > > So here now is -rc4 and I plan to make the final release on April 6th,
> > > as scheduled. Thanks all and stay safe out there!
> >
> > It becomes a tradition. Intel Edison is broken again (now serial driver).
> > This is show stopper.
> >
> > I'll become later with the culprit commit out of these three:
> >This reverts commit 1c16606aac8f03be80d9c38ada00fd03123e0dbe.
> >This reverts commit 62cbde4c4e462e5147d07cf1424492bb39e7bf94.
> >This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
>
> And the winner is...
>
> 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
>
> Wolfgang, please, fix ASAP, or revert ASAP!
What exactly does "broken" mean in this case?
What happens on Intel Edison?
I don't think just reversing commit 720f9e1fdb0c [1] is a good idea, as this
commit is itself a bug fix for commit 82de42fa1468 [2]. Commit 82de42fa1468
did break the serial driver on Intel Apollo Lake, see the description of
commit 720f9e1fdb0c for details on what happened on that platform.
regards, Wolfgang
[1] commit 720f9e1fdb0c ("serial: ns16550: Move PCI access from
ofdata_to_platdata() to probe()")
[2] commit 82de42fa1468 ("dm: core: Allocate parent data separate from
probing parent")
[PULL] Pull request: u-boot-stm/master =u-boot-stm32-20200401
Hi Tom, Please pull the latest STM32 master bugfix for v2020.04 = u-boot-stm32-20200401 With the following changes: - Fix device tree of Avenger96 board from Arrow Electronics and add compatibility with stm32mp15_dhcom_basic_defconfig CI status: Failed for vexpress_ca9x4 test.py https://gitlab.denx.de/u-boot/custodians/u-boot-stm/pipelines/2592 But local compilation is OK with buildman on stm32 targets. I think it is enough as the Marek's patches only update the dh board code and the AV96 device tree. Thanks, Patrick The following changes since commit af827140e5965e5bb2bcad1c53ca8419b428ff6d: vexpress_ca9x4: Enable use of correct DTB file and restore EFI loader. (2020-03-23 16:11:46 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-stm.git tags/u-boot-stm32-20200401 for you to fetch changes up to 2f3c4b8a0f303edbea9fc112a49e546cf03776b0: ARM: dts: stm32: Repair PMIC configuration on AV96 (2020-04-01 11:58:00 +0200) - Fix device tree of Avenger96 board from Arrow Electronics and add compatibility with stm32mp15_dhcom_basic_defconfig Marek Vasut (12): ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96 ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins ARM: dts: stm32: Repair SDMMC1 operation on AV96 ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7 ARM: dts: stm32: Repair SDMMC2 operation ARM: dts: stm32: Add QSPI NOR on AV96 ARM: dts: stm32: Use DT alias for the configuration EEPROM ARM: dts: stm32: Add configuration EEPROM on AV96 ARM: dts: stm32: Add alternate pinmux for ethernet RGMII ARM: dts: stm32: Repair ethernet operation on AV96 ARM: dts: stm32: Add missing ethernet PHY reset on AV96 ARM: dts: stm32: Repair PMIC configuration on AV96 arch/arm/dts/stm32mp157-pinctrl.dtsi | 96 + arch/arm/dts/stm32mp157a-avenger96-u-boot.dtsi | 9 ++-- arch/arm/dts/stm32mp157a-avenger96.dts | 79 - arch/arm/dts/stm32mp15xx-dhcom.dtsi| 6 ++- board/dhelectronics/dh_stm32mp1/board.c| 15 +++ 5 files changed, 182 insertions(+), 23 deletions(-)
[PATCH v2 1/1] driver: watchdog: get platform clock from dt file
From: Bharat Kumar Reddy Gooty
Get the watchdog platform clock from the DTS file
and use the same for calculating ticks in msec.
Signed-off-by: Bharat Kumar Reddy Gooty
Signed-off-by: Rayagonda Kokatanur
---
Changes from v1:
-Address review comments from Stefan Roese,
Remove default timeout reading in probe() as it is read in include/wdt.h.
Add paranthesis on multi-line statements.
drivers/watchdog/sp805_wdt.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
index ca3ccbe76c..b9e4aee7a5 100644
--- a/drivers/watchdog/sp805_wdt.c
+++ b/drivers/watchdog/sp805_wdt.c
@@ -34,6 +34,7 @@ DECLARE_GLOBAL_DATA_PTR;
struct sp805_wdt_priv {
void __iomem *reg;
+ u32 clk_mhz;
};
static int sp805_wdt_reset(struct udevice *dev)
@@ -63,8 +64,13 @@ static int sp805_wdt_start(struct udevice *dev, u64 timeout,
ulong flags)
* set 120s, the gd->bus_clk is less than 1145MHz, the load_value will
* not overflow.
*/
- load_value = (gd->bus_clk) /
- (2 * 1000 * SYS_FSL_WDT_CLK_DIV) * load_time;
+ if (gd->bus_clk) {
+ load_value = (gd->bus_clk) /
+ (2 * 1000 * SYS_FSL_WDT_CLK_DIV) * load_time;
+ } else {
+ /* platform provide clk */
+ load_value = (timeout / 2) * (priv->clk_mhz / 1000);
+ }
writel(UNLOCK, priv->reg + WDTLOCK);
writel(load_value, priv->reg + WDTLOAD);
@@ -110,6 +116,9 @@ static int sp805_wdt_ofdata_to_platdata(struct udevice *dev)
if (IS_ERR(priv->reg))
return PTR_ERR(priv->reg);
+ if (dev_read_u32(dev, "clk-mhz", >clk_mhz))
+ return -ENODATA;
+
return 0;
}
--
2.17.1
Re: [PATCH v1 1/1] driver: watchdog: get timeout and clock from dt file
On Tue, Mar 31, 2020 at 12:44 PM Stefan Roese wrote:
>
> On 31.03.20 08:08, Rayagonda Kokatanur wrote:
> > From: Bharat Kumar Reddy Gooty
> >
> > Get the watchdog default timeout value and clock from the DTS file
>
> The default timeout is already read from the DT. Please see below...
Thank you, will fix this.
>
> > Signed-off-by: Bharat Kumar Reddy Gooty
> > Signed-off-by: Rayagonda Kokatanur
> > ---
> > drivers/watchdog/sp805_wdt.c | 36 ++--
> > 1 file changed, 34 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/watchdog/sp805_wdt.c b/drivers/watchdog/sp805_wdt.c
> > index ca3ccbe76c..e8f54d6804 100644
> > --- a/drivers/watchdog/sp805_wdt.c
> > +++ b/drivers/watchdog/sp805_wdt.c
> > @@ -34,8 +34,31 @@ DECLARE_GLOBAL_DATA_PTR;
> >
> > struct sp805_wdt_priv {
> > void __iomem *reg;
> > + u32 timeout_msec;
> > + u32 clk_mhz;
> > };
> >
> > +static u32 msec_to_ticks(struct udevice *dev)
> > +{
> > + u32 timeout_msec;
> > + u32 msec;
> > + struct sp805_wdt_priv *priv = dev_get_priv(dev);
> > +
> > + timeout_msec = env_get_ulong("wdt_timeout_msec", 10, 0);
> > + if (timeout_msec) {
> > + dev_dbg(dev, "Overriding timeout :%u\n", timeout_msec);
> > + msec = timeout_msec;
> > + } else {
> > + msec = priv->timeout_msec;
> > + }
>
> Why is this overriding via environment needed? BTW: You should mention
> such a change in the commit text as well.
This code will be removed as default timeout is already read in include/wdt.h
>
> > +
> > + timeout_msec = (msec / 2) * (priv->clk_mhz / 1000);
> > +
> > + dev_dbg(dev, "ticks :%u\n", timeout_msec);
> > +
> > + return timeout_msec;
> > +}
> > +
> > static int sp805_wdt_reset(struct udevice *dev)
> > {
> > struct sp805_wdt_priv *priv = dev_get_priv(dev);
> > @@ -63,8 +86,11 @@ static int sp805_wdt_start(struct udevice *dev, u64
> > timeout, ulong flags)
> >* set 120s, the gd->bus_clk is less than 1145MHz, the load_value will
> >* not overflow.
> >*/
> > - load_value = (gd->bus_clk) /
> > - (2 * 1000 * SYS_FSL_WDT_CLK_DIV) * load_time;
> > + if (gd->bus_clk)
> > + load_value = (gd->bus_clk) /
> > + (2 * 1000 * SYS_FSL_WDT_CLK_DIV) * load_time;
> > + else /* platform provide clk */
> > + load_value = msec_to_ticks(dev);
>
> Nitpicking: Please use paranthesis on multi-line statements.
Thank you fix this.
>
> > writel(UNLOCK, priv->reg + WDTLOCK);
> > writel(load_value, priv->reg + WDTLOAD);
> > @@ -110,6 +136,12 @@ static int sp805_wdt_ofdata_to_platdata(struct udevice
> > *dev)
> > if (IS_ERR(priv->reg))
> > return PTR_ERR(priv->reg);
> >
> > + if (dev_read_u32(dev, "timeout-msec", >timeout_msec))
> > + return -ENODATA;
>
> This does not seem to be an official DT binding. At least I was unable
> to find it in the latest Linux tree.
>
> You are aware that the WDT core code already reads the WDT timeout from
> the DT using the official "timeout-sec" property? Do you need a higher
> graned timeout value (ms vs s)?
Thank you for pointing this, will update my dt file.
>
> Thanks,
> Stefan
[PATCH v1] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
The commit breaks serial console on the Intel Edison.
This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
Signed-off-by: Andy Shevchenko
---
drivers/serial/ns16550.c | 40
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index c1b303ffcb..1fcbc35015 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -479,40 +479,12 @@ static int ns16550_serial_getinfo(struct udevice *dev,
return 0;
}
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
-static int ns1655_serial_set_base_addr(struct udevice *dev)
-{
- fdt_addr_t addr;
- struct ns16550_platdata *plat;
-
- plat = dev_get_platdata(dev);
-
- addr = dev_read_addr_pci(dev);
- if (addr == FDT_ADDR_T_NONE)
- return -EINVAL;
-
-#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
- plat->base = addr;
-#else
- plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE);
-#endif
-
- return 0;
-}
-#endif
-
int ns16550_serial_probe(struct udevice *dev)
{
struct NS16550 *const com_port = dev_get_priv(dev);
struct reset_ctl_bulk reset_bulk;
int ret;
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
- ret = ns1655_serial_set_base_addr(dev);
- if (ret)
- return ret;
-#endif
-
ret = reset_get_bulk(dev, _bulk);
if (!ret)
reset_deassert_bulk(_bulk);
@@ -535,9 +507,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
{
struct ns16550_platdata *plat = dev->platdata;
const u32 port_type = dev_get_driver_data(dev);
+ fdt_addr_t addr;
struct clk clk;
int err;
+ /* try Processor Local Bus device first */
+ addr = dev_read_addr_pci(dev);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+ plat->base = addr;
+#else
+ plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE);
+#endif
+
plat->reg_offset = dev_read_u32_default(dev, "reg-offset", 0);
plat->reg_shift = dev_read_u32_default(dev, "reg-shift", 0);
plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1);
--
2.25.1
[PATCH v1] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
The commit breaks serial console on the Intel Edison.
This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
Signed-off-by: Andy Shevchenko
---
drivers/serial/ns16550.c | 40
1 file changed, 12 insertions(+), 28 deletions(-)
diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 3088ab47ae..386b5e04c8 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -480,40 +480,12 @@ static int ns16550_serial_getinfo(struct udevice *dev,
return 0;
}
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
-static int ns1655_serial_set_base_addr(struct udevice *dev)
-{
- fdt_addr_t addr;
- struct ns16550_platdata *plat;
-
- plat = dev_get_platdata(dev);
-
- addr = dev_read_addr_pci(dev);
- if (addr == FDT_ADDR_T_NONE)
- return -EINVAL;
-
-#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
- plat->base = addr;
-#else
- plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE);
-#endif
-
- return 0;
-}
-#endif
-
int ns16550_serial_probe(struct udevice *dev)
{
struct NS16550 *const com_port = dev_get_priv(dev);
struct reset_ctl_bulk reset_bulk;
int ret;
-#if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
- ret = ns1655_serial_set_base_addr(dev);
- if (ret)
- return ret;
-#endif
-
ret = reset_get_bulk(dev, _bulk);
if (!ret)
reset_deassert_bulk(_bulk);
@@ -536,9 +508,21 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
{
struct ns16550_platdata *plat = dev->platdata;
const u32 port_type = dev_get_driver_data(dev);
+ fdt_addr_t addr;
struct clk clk;
int err;
+ /* try Processor Local Bus device first */
+ addr = dev_read_addr_pci(dev);
+ if (addr == FDT_ADDR_T_NONE)
+ return -EINVAL;
+
+#ifdef CONFIG_SYS_NS16550_PORT_MAPPED
+ plat->base = addr;
+#else
+ plat->base = (unsigned long)map_physmem(addr, 0, MAP_NOCACHE);
+#endif
+
plat->reg_offset = dev_read_u32_default(dev, "reg-offset", 0);
plat->reg_shift = dev_read_u32_default(dev, "reg-shift", 0);
plat->reg_width = dev_read_u32_default(dev, "reg-io-width", 1);
--
2.25.1
Re: [ANN] U-Boot v2020.04-rc4 released
On Wed, Apr 1, 2020 at 2:54 PM Andy Shevchenko wrote: > > On Tue, Mar 31, 2020 at 2:31 AM Tom Rini wrote: > > > > Hey all, > > > > So, I've gotten out of the habit of tagging rcs on cycle. This month I > > have been taking in changes sparingly and I'm not concerned that things > > have gone in that wouldn't have, if I had tagged -rc4/rc5 on schedule. > > > > Things have been going to the -next branch as expected, and I think > > that will work out when things open up for v2020.07 > > > > So here now is -rc4 and I plan to make the final release on April 6th, > > as scheduled. Thanks all and stay safe out there! > > It becomes a tradition. Intel Edison is broken again (now serial driver). > This is show stopper. > > I'll become later with the culprit commit out of these three: >This reverts commit 1c16606aac8f03be80d9c38ada00fd03123e0dbe. >This reverts commit 62cbde4c4e462e5147d07cf1424492bb39e7bf94. >This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. And the winner is... 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. Wolfgang, please, fix ASAP, or revert ASAP! -- With Best Regards, Andy Shevchenko
Re: [ANN] U-Boot v2020.04-rc4 released
On Tue, Mar 31, 2020 at 2:31 AM Tom Rini wrote: > > Hey all, > > So, I've gotten out of the habit of tagging rcs on cycle. This month I > have been taking in changes sparingly and I'm not concerned that things > have gone in that wouldn't have, if I had tagged -rc4/rc5 on schedule. > > Things have been going to the -next branch as expected, and I think > that will work out when things open up for v2020.07 > > So here now is -rc4 and I plan to make the final release on April 6th, > as scheduled. Thanks all and stay safe out there! It becomes a tradition. Intel Edison is broken again (now serial driver). This is show stopper. I'll become later with the culprit commit out of these three: This reverts commit 1c16606aac8f03be80d9c38ada00fd03123e0dbe. This reverts commit 62cbde4c4e462e5147d07cf1424492bb39e7bf94. This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. -- With Best Regards, Andy Shevchenko
Re: [PATCH 08/16] board: stm32mp1: update management of boot-led
Hi Patrick,
On Tue, 31 Mar 2020 18:04:25 +0200
Patrick Delaunay patrick.delau...@st.com wrote:
...
> @@ -648,8 +652,10 @@ int board_init(void)
>
> sysconf_init();
>
> - if (CONFIG_IS_ENABLED(CONFIG_LED))
> + if (CONFIG_IS_ENABLED(CONFIG_LED)) {
> led_default_state();
Did you verify that this works like expected? We either use
if (CONFIG_IS_ENABLED(LED))
or
if (IS_ENABLED(CONFIG_LED))
Please check.
--
Anatolij
Re: [PATCH 11/16] board: stm32mp1: check env_get result in board_late_init
Dear Patrick Delaunay,
In message
<20200331180330.11.Ic051e25812481db408f2431c7962da1db1f198fb@changeid> you
wrote:
> This patch avoids crash in strcmp when the boot_device is not
> present in environment (this case should be never occur)
>
> Signed-off-by: Patrick Delaunay
> ---
>
> board/st/stm32mp1/stm32mp1.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/board/st/stm32mp1/stm32mp1.c b/board/st/stm32mp1/stm32mp1.c
> index 89a088cd28..fff4cef2c2 100644
> --- a/board/st/stm32mp1/stm32mp1.c
> +++ b/board/st/stm32mp1/stm32mp1.c
> @@ -753,7 +753,8 @@ int board_late_init(void)
>
> /* Check the boot-source to disable bootdelay */
> boot_device = env_get("boot_device");
> - if (!strcmp(boot_device, "serial") || !strcmp(boot_device, "usb"))
> + if (boot_device &&
> + (!strcmp(boot_device, "serial") || !strcmp(boot_device, "usb")))
> env_set("bootdelay", "0");
I think this is generally a bad idea. You should have more respect
to the intentions of your users. If a user defines a specific
bootdelay setting in his environment, this must be respected.
I really hate vendors who believe they know better than me what I
want or what is good to me. Please get rid of such stuff.
"bootdelay" is an environment variable that is intentionally user
definable. You must never mess with those.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"Everything should be made as simple as possible, but not simpler."
- Albert Einstein
Re: [PATCH 09/16] board: stm32mp1: gt9147 IRQ before reset on EV1
Dear Patrick Delaunay,
In message
<20200331180330.9.I5d296f8fd82b60a592b51029e7e420672d0e855b@changeid> you wrote:
> Software workaround for I2C issue on EV1 board,
> configure the IRQ line for touchscreen before LCD reset
> to fix the used I2C address.
...
> + ret = uclass_get_device_by_driver(UCLASS_NOP, DM_GET_DRIVER(goodix),
> + );
> + if (ret)
> + debug("goodix init failed: %d\n", ret);
If this is an error condition, you should use printf(), and not
paper over it with a debug().
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Don't have a battle of wits with an unarmed opponent.
Re: [PATCH 08/16] board: stm32mp1: update management of boot-led
Dear Patrick Delaunay,
In message
<20200331180330.8.I15cb0a6245fb4cd5d23371683c2697f794adf306@changeid> you wrote:
> Force boot-led ON and no more rely on default-state.
> This patch avoid device-tree modification for U-Boot.
...
> +#ifdef CONFIG_LED
> struct udevice *dev;
> int ret;
>
> @@ -292,8 +294,10 @@ static int setup_led(enum led_state_t cmd)
>
> ret = led_set_state(dev, cmd);
> return ret;
> -}
> +#else
> + return 0;
> #endif
> +}
>
> static void __maybe_unused led_error_blink(u32 nb_blink)
> {
> @@ -648,8 +652,10 @@ int board_init(void)
>
> sysconf_init();
>
> - if (CONFIG_IS_ENABLED(CONFIG_LED))
> + if (CONFIG_IS_ENABLED(CONFIG_LED)) {
> led_default_state();
> + setup_led(LEDST_ON);
> + }
This is inconsistent, please use CONFIG_IS_ENABLED() everywhere
instead of #ifdef's.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Q: Do you know what the death rate around here is?
A: One per person.
Re: [PATCH 06/16] arm: stm32mp: spl: display error in board_init_f
Dear Patrick Delaunay,
In message
<20200331180330.6.I41a641a07fd12da45b392920fc3407e608926396@changeid> you wrote:
> Update board_init_f and try to display error message
> when console is available.
>
> This patch adds trace to debug a spl boot issue when DEBUG
> and DEBUG_UART is not activated, after uart probe.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/mach-stm32mp/spl.c | 33 -
> 1 file changed, 16 insertions(+), 17 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/spl.c b/arch/arm/mach-stm32mp/spl.c
> index ca4231cd0d..dfdb5bb7e9 100644
> --- a/arch/arm/mach-stm32mp/spl.c
> +++ b/arch/arm/mach-stm32mp/spl.c
> @@ -79,37 +79,36 @@ void spl_display_print(void)
> void board_init_f(ulong dummy)
> {
> struct udevice *dev;
> - int ret;
> + int ret, clk, reset, pinctrl;
>
> arch_cpu_init();
>
> ret = spl_early_init();
> if (ret) {
> - debug("spl_early_init() failed: %d\n", ret);
> + debug("%s: spl_early_init() failed: %d\n", __func__, ret);
> hang();
> }
>
> - ret = uclass_get_device(UCLASS_CLK, 0, );
> - if (ret) {
> - debug("Clock init failed: %d\n", ret);
> - return;
> - }
> + clk = uclass_get_device(UCLASS_CLK, 0, );
> + if (clk)
> + debug("%s: Clock init failed: %d\n", __func__, clk);
>
> - ret = uclass_get_device(UCLASS_RESET, 0, );
> - if (ret) {
> - debug("Reset init failed: %d\n", ret);
> - return;
> - }
> + reset = uclass_get_device(UCLASS_RESET, 0, );
> + if (reset)
> + debug("%s: Reset init failed: %d\n", __func__, reset);
>
> - ret = uclass_get_device(UCLASS_PINCTRL, 0, );
> - if (ret) {
> - debug("%s: Cannot find pinctrl device\n", __func__);
> - return;
> - }
> + pinctrl = uclass_get_device(UCLASS_PINCTRL, 0, );
> + if (pinctrl)
> + debug("%s: Cannot find pinctrl device: %d\n",
> + __func__, pinctrl);
>
> /* enable console uart printing */
> preloader_console_init();
>
> + if (clk || reset || pinctrl)
> + printf("%s: probe failed clk=%d reset=%d pinctrl=%d\n",
> +__func__, clk, reset, pinctrl);
> +
This change makes little sense to me/ If you want error messages,
then just turn above debug() into printf(), and be done with it.
As an additional benefit so see at once which step failed.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A Chairman was as necessary to a Board planet as the zero was in
mathematics, but being a zero had big disadvantages...
- Terry Pratchett, _The Dark Side of the Sun_
Re: [PATCH 04/16] arm: stm32mp: detect U-Boot version used to save environment
Dear Patrick Delaunay, In message <20200331160456.26254-1-patrick.delau...@st.com> you wrote: > Imply CONFIG_VERSION_VARIABLE for stm32mp1 target > and test U-Boot version ($env_ver) when the environment was > saved for the last time and to display warning trace. What is env_ver? Are you by chance reinventing the wheel? The U-Boot version is stored in the environment variable "ver"; there should be no need for something similar. Also. where is $env_ver coming from? It does not exist in mainline, nor in any of the 3 patches that preceed this patch # 4/16 ? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Computers are not intelligent. They only think they are.
Re: [PATCH 05/16] arm: stm32mp: spl: add bsec driver in SPL
Dear Patrick Delaunay,
In message
<20200331180330.5.I7a042a9ffbb5c2668034eddf5ace91271bb53c5f@changeid> you wrote:
> Add the bsec driver in SPL, as it is needed by SOC part number detection.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/dts/stm32mp15-u-boot.dtsi | 2 +-
> arch/arm/mach-stm32mp/Makefile | 2 +-
> arch/arm/mach-stm32mp/bsec.c | 4 ++--
> 3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/arch/arm/dts/stm32mp15-u-boot.dtsi
> b/arch/arm/dts/stm32mp15-u-boot.dtsi
> index 8f9535a4db..e0b1223de8 100644
> --- a/arch/arm/dts/stm32mp15-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15-u-boot.dtsi
> @@ -40,7 +40,7 @@
> };
>
> {
> - u-boot,dm-pre-proper;
> + u-boot,dm-pre-reloc;
> };
This seems to be an unrelated change? You should at least explain
why this is needed, and if it's unrelated, spilt into a separate
commit.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Good manners are the settled medium of social, as specie is of
commercial, life; returns are equally expected for both.
- Lord Chesterfield _Letters to his Son_, 25 December 1753
Re: [PATCH 03/16] arm: stm32mp: reset to default environment when serial# change
Dear Patrick,
In message
<20200331180330.3.I8f6df6d28ce5b4b601ced711af3699d95e1576fb@changeid> you wrote:
> Serial number is first checked and, in case of mismatch, all
> environment variables are reset to their default value.
>
> This patch allows to detect that environment is saved in a removable
> device, as a SD card, and reused on a other board, potentially with
> incompatible variables.
>
> Signed-off-by: Patrick Delaunay
> ---
>
> arch/arm/mach-stm32mp/cpu.c | 20 +++-
> 1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c
> index 9aa5794334..365c2aa4f7 100644
> --- a/arch/arm/mach-stm32mp/cpu.c
> +++ b/arch/arm/mach-stm32mp/cpu.c
> @@ -511,8 +511,9 @@ __weak int setup_mac_address(void)
> return -EINVAL;
> }
> pr_debug("OTP MAC address = %pM\n", enetaddr);
> - ret = !eth_env_set_enetaddr("ethaddr", enetaddr);
> - if (!ret)
> +
> + ret = eth_env_set_enetaddr("ethaddr", enetaddr);
> + if (ret)
> pr_err("Failed to set mac address %pM from OTP: %d\n",
> enetaddr, ret);
This is an unrelated and totally undocumented change. Please split
into separate commit.
> +
> + if (serial_env) {
> + if (!strcmp(serial_string, serial_env))
> + return 0;
> + /* For invalid enviromnent (serial# change), reset to default */
> + env_set_default("serial number mismatch", 0);
> + }
Resetting the enviropnment to the defaults means you drop all
setting sa user may have made. This is a very bad move - as a user
I find such things completely unacceptable. If I make any changes,
they must never ever be killed without my explicit confirmation.
I strongly advice against such a method. Please drop that.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"You ain't experienced..." "Well, nor are you." "That's true. But the
point is ... the point is ... the point is we've been not experienced
for a lot longer than you. We've got a lot of experience of not
having any experience." - Terry Pratchett, _Witches Abroad_
Re: [PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96
On 4/1/20 12:24 PM, Patrick DELAUNAY wrote: > Hi Gerald and Manivannan, Hi, >> From: Marek Vasut >> Sent: mardi 31 mars 2020 19:52 >> >> The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and >> FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which can not >> easily divide the clock down to e.g. 50 MHz for high speed SD and eMMC >> devices, so those devices end up running at 30 MHz as that is 120 MHz / 4. >> Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100 MHz >> instead, which is easy to divide to 50MHz for optimal operation of both SD >> and >> eMMC, SPDIF clock are not that much slower and FDCAN is also unaffected. >> >> Reviewed-by: Patrice Chotard >> Reviewed-by: Patrick Delaunay >> Signed-off-by: Marek Vasut >> Cc: Manivannan Sadhasivam >> Cc: Patrick Delaunay >> Cc: Patrice Chotard >> --- >> V2: Move this patch before the split of AV96 into SoM and carrier >> V3: No change >> --- > > This patch update the PLL4 frequency used on AV96 board, > with different of reference clock tree used on ST board, > this new setting allow to optimize the SDMMC frequency (50MHz vs 30Mz). > > I don't know why the previous PLL4 frequency was chosen as a compromise > on reference clock-tree (PLL4 is used by mostly all the peripheral, > with display and audio requirements). > > Can you cross check the proposed clock tree and ack this patch > if these ST requirements are not applicable on AV96 board. > > Anyway the code is correct. Likely because these PLL settings are being copied from reference platform to other platforms etc. But I did notice one odd thing, which is when running the SD1 in SDR104, the read data transfers can be unstable, which I suspect is because the bus runs at actual 100 MHz instead of some 60 MHz. I need to look at that with a scope, so that's to be checked. For now I turned the SDR104 off.
Re: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96
On 4/1/20 9:34 AM, Patrick DELAUNAY wrote:
> Hi Marek and Pascal,
Hi,
[...]
>> @@ -167,7 +178,7 @@
>>
>> vddcore: buck1 {
>> regulator-name = "vddcore";
>> -regulator-min-microvolt = <120>;
>> +regulator-min-microvolt = <80>;
>
> I don't understood this modification, If I correctly remember, on STM32MP15x
> On ST boards, we set this value to 120 to protect VDDCORE on
> SOC (it is not allowed to be reduce lower than 1,2V.
>
> 0.8V is the minimal supported voltage by STPMIC but not the minal expected
> VDDCORE.
Then we should likely drop this part.
That said, is the core voltage supposed to be 1V2 even in sleep states ?
>> @@ -185,8 +196,8 @@
>>
>> vdd: buck3 {
>> regulator-name = "vdd";
>> -regulator-min-microvolt = <330>;
>> -regulator-max-microvolt = <330>;
>> +regulator-min-microvolt = <290>;
>> +regulator-max-microvolt = <290>;
>> regulator-always-on;
>> st,mask_reset;
>> regulator-initial-mode = <0>;
>> @@ -268,6 +279,7 @@
>> regulator-name = "vbus_otg";
>> interrupts = ;
>> interrupt-parent = <>;
>> +regulator-active-discharge = <1>;
>
> It seems this setting introduced other-consumption, it should not be used.
Other-consumption ? What does that mean ?
Re: [PATCH V2 14/14] ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board
On 4/1/20 10:37 AM, Patrick DELAUNAY wrote: > Hi, [...] >>> When this file will be removed ? why kept this file. >>> I propose to completely remove this file (no device tree for same >>> board) >> >> Backward compatibility, I'd keep it in for a release or two. >> But if removing it is fine, then so be it. > > Yes I prefer. > Except if maintainers of this file have a other opinion. OK +/* This is kept for backward compatibility and will be removed */ +#include "stm32mp15xx-dhcor-avenger96.dts" >>> >>> Missing u-boot file to avoid issue.. >>> >>> +#include " stm32mp15xx-dhcor-avenger96-u-boot.dtsi" >> >> That's actually included via the avenger96.dts, so should be OK. >> Although I am not real happy with that. > > Ok, I miss that. > I agree, it is unexpected. It's a bit weird, I think this should be added to the list of things to improve in the next cycle. -- Best regards, Marek Vasut
Re: [PATCH V2 00/14] ARM: stm32: Fix Avenger96
On 4/1/20 11:15 AM, Patrick DELAUNAY wrote: > Hi Marek, Hi, >> From: Marek Vasut >> Sent: mardi 31 mars 2020 18:59 >> >> On 3/31/20 5:22 PM, Patrick DELAUNAY wrote: >>> Hi Marek, >> >> Hi, >> From: Marek Vasut Sent: mardi 31 mars 2020 02:49 This series fixes the Avenger96 board. Since there are way too many patches floating around on the ML and because I found various other details that needed fixing, I decided to bundle the whole set of fixes into this >> series. This should go into current release, otherwise the board doesn't even boot. This V2 is also roughly synchronized with the Linux V2 series fixing very much the same issues. >>> >>> Do you expect all these paches in v2020.04 ? so in 5 days. >> >> Yes, the timing is bad, but this is fixing real bugs and is isolated to one >> (two) >> boards. > > Ok, I will prepare pull request asap. Thank you. Let me know if you have a tree so I can check it. [...] ARM: dts: stm32: Add missing ethernet PHY reset on AV96 ARM: dts: stm32: Repair PMIC configuration on AV96 >> >> This fixes PMIC settings, so you do want this, otherwise the board is >> unstable. > > I will take even if I have remark on buck1 min voltage and buck2 > configuration (regulator-active-discharge) I will double-check those and possibly send a subsequent patch. ARM: dts: stm32: Adjust PLL4 settings on AV96 >> >> This one can probably wait, although it would make sense to put it in. > > Not yet review by AV96 upstreamer... I prefer wait. Fine by me. ARM: dts: stm32: Split AV96 into DHCOR SoM and AV96 board >> >> This one can wait for next. >> >> [...] > > I am preparing the branch stm/master and the pull request. Thanks ! -- Best regards, Marek Vasut
Re: [PATCH V2 11/14] ARM: dts: stm32: Add missing ethernet PHY reset on AV96
On 4/1/20 10:57 AM, Patrick DELAUNAY wrote: > Hi, Hi, >> From: Marek Vasut >> Sent: mardi 31 mars 2020 19:07 >> >> On 3/31/20 4:06 PM, Patrick DELAUNAY wrote: >>> Hi Marek, >>> From: Marek Vasut Sent: mardi 31 mars 2020 02:49 Add PHY reset GPIO on AV96 ethernet PHY. Signed-off-by: Marek Vasut Cc: Patrick Delaunay Cc: Patrice Chotard --- V2: No change --- arch/arm/dts/stm32mp157a-avenger96.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/stm32mp157a-avenger96.dts b/arch/arm/dts/stm32mp157a-avenger96.dts index fb8f0021b3..7a4b6e6a2c 100644 --- a/arch/arm/dts/stm32mp157a-avenger96.dts +++ b/arch/arm/dts/stm32mp157a-avenger96.dts @@ -101,6 +101,7 @@ phy-mode = "rgmii"; max-speed = <1000>; phy-handle = <>; + phy-reset-gpios = < 2 GPIO_ACTIVE_LOW>; >>> >>> This obsolete binding is (and won't be) supported for STM32MP15x variant of >> dwc_eth_qos driver. >>> >>> I am currenty upstream the support in U-boot of the support of the >>> final binding aligned with Kernel one. >>> >>> "net: dwc_eth_qos: implement reset-gpios for stm32" >>> http://patchwork.ozlabs.org/patch/1257377/ >> >> That's probably gonna go in the next cycle, right? So you likely want to >> grab this >> for this cycle to fix the ethernet here and then in next cycle rework the >> bindings. > > Yes in the next cycle probably. > > But the ethernet can't be not fixed with this patch, at least in U-boot > as the reset by gpio is not executed in driver: it is not supported. > > Only present in eqos_probe_resources_tegra186 > but not in eqos_probe_resources_stm32. > > Or you have perhaps a local patch on dwc_eth_qos.c Oh doh, I don't. > I think I can drop this unneeded patch for the release... > Or merge it, as is no effect. > > And after binding rework, the AV96 board DT should be updated > (in kernel also, I think, as the old binding should be refused). Agreed. Drop it then. >> btw you also want to look at this series: >> [PATCH 1/6] net: dwc_eth_qos: Fully rewrite RX descriptor field 3 > > Yes I see the serie > > I want to review and test it since 2 weeks. > > And particularly check if I can remove the CONFIG_SYS_NONCACHED_MEMORY > in stm32mp1.h with this serie. We should consider that, yes, it looks somewhat crappy. Basically, your problem is that the descriptor is shorter than your cacheline, that means you cannot write into the descriptor right away after the MAC indicates the descriptor is complete, because you would evict the entire cache line and likely corrupt the neighboring descriptors too. What you would have to do is - invalidate the cacheline which contains the currently finished desc - read the desc status - IFF and only IFF this is the last desc in the cacheline, flag all the descriptors as ready for the DMA engine to use again, and only then flush the entire cacheline And you probably also want to make sure that the DWMAC4 "last usable descriptor" pointer does not point at these currently updated descriptors, so that the DWMAC DMA engine won't access them while you are flushing the cache line. This is certainly doable, one just has to be careful about the cache intricacies. > I am not happy with this configuration (it is more a workaround > for cache management issue in this driver that a real solution). > > But I am at home since 3 weeks with COVID-19, and my test > capacity is reduced. Get better soon! -- Best regards, Marek Vasut
RE: [PATCH V3 13/14] ARM: dts: stm32: Adjust PLL4 settings on AV96
Hi Gerald and Manivannan, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:52 > > The PLL4 is supplying SDMMC12, SDMMC3 and SPDIF with 120 MHz and > FDCAN with 96 MHz. This isn't good for the SDMMC interfaces, which can not > easily divide the clock down to e.g. 50 MHz for high speed SD and eMMC > devices, so those devices end up running at 30 MHz as that is 120 MHz / 4. > Adjust the PLL4 settings such that both PLL4P and PLL4R run at 100 MHz > instead, which is easy to divide to 50MHz for optimal operation of both SD and > eMMC, SPDIF clock are not that much slower and FDCAN is also unaffected. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > V2: Move this patch before the split of AV96 into SoM and carrier > V3: No change > --- This patch update the PLL4 frequency used on AV96 board, with different of reference clock tree used on ST board, this new setting allow to optimize the SDMMC frequency (50MHz vs 30Mz). I don't know why the previous PLL4 frequency was chosen as a compromise on reference clock-tree (PLL4 is used by mostly all the peripheral, with display and audio requirements). Can you cross check the proposed clock tree and ack this patch if these ST requirements are not applicable on AV96 board. Anyway the code is correct. Reviewed-by: Patrick Delaunay Thanks Patrick
Re: [PATCH] mach-snapdragon: Fix overwriting last digit of serial number
Hello Tom, the buffer has to hold 8 hex digits and a trailing \0, therefore 9 bytes should be enough. The problem was, that snprintf was told sn were only 8 characters long, making snprintf to only write 7 digits followed by the trailing \0. Jan-Christoph Am Fr., 20. März 2020 um 18:31 Uhr schrieb Tom Rini : > > On Mon, Mar 16, 2020 at 05:51:51PM +0100, Jan-Christoph Tebbe wrote: > > > When generating the MAC address based on the boards serial number > > the last digit was overwritten with the null termination. That way > > boards with serial numbers close to each other would use the same > > MAC address. > > > > Signed-off-by: Jan-Christoph Tebbe > > --- > > arch/arm/mach-snapdragon/misc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/arch/arm/mach-snapdragon/misc.c > > b/arch/arm/mach-snapdragon/misc.c > > index f6c87866c0..aaa561c2c6 100644 > > --- a/arch/arm/mach-snapdragon/misc.c > > +++ b/arch/arm/mach-snapdragon/misc.c > > @@ -41,7 +41,7 @@ void msm_generate_mac_addr(u8 *mac) > > int i; > > char sn[9]; > > > > - snprintf(sn, 8, "%08x", msm_board_serial()); > > + snprintf(sn, 9, "%08x", msm_board_serial()); > > > > /* fill in the mac with serialno, use locally adminstrated pool */ > > mac[0] = 0x02; > > OK, so sn is size 9 and now you're filling the whole thing. Why don't > we need to increase sn to size 10? Am I missing something? Thanks! > > -- > Tom
[PATCH] efi_loader: enable RNG if DM_RNG is enabled
Enable EFI_RNG_PROTOCOL by default if DM_RNG is set. Signed-off-by: Peter Robinson --- I think it makes sense to enable EFI_RNG_PROTOCOL by default if a config has enabled both DM_RNG and UEFI. lib/efi_loader/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index 9890144d41..b9a770281e 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -125,6 +125,7 @@ config EFI_GRUB_ARM32_WORKAROUND config EFI_RNG_PROTOCOL bool "EFI_RNG_PROTOCOL support" + default y if DM_RNG depends on DM_RNG help Provide a EFI_RNG_PROTOCOL implementation using the hardware random -- 2.26.0
Re: [PATCH 6/6] rockchip: rk3328: Add support for ROC-RK3328-CC board
On Tue, Mar 31, 2020 at 8:37 PM Jagan Teki wrote:
>
> On Tue, Mar 31, 2020 at 5:16 PM Chen-Yu Tsai wrote:
> >
> > On Tue, Mar 31, 2020 at 6:57 PM Jagan Teki
> > wrote:
> > >
> > > On Mon, Mar 30, 2020 at 11:54 PM Chen-Yu Tsai wrote:
> > > >
> > > > On Tue, Mar 31, 2020 at 1:44 AM Jagan Teki
> > > > wrote:
> > > > >
> > > > > Hi Chen-Yu,
> > > > >
> > > > > On Fri, Mar 27, 2020 at 10:12 AM Chen-Yu Tsai wrote:
> > > > > >
> > > > > > From: Chen-Yu Tsai
> > > > > >
> > > > > > The ROC-RK3328-CC from Firefly and Libre Computer Project is a
> > > > > > credit
> > > > > > card size development board based on the Rockchip RK3328 SoC, with:
> > > > > >
> > > > > > - 1/2/4 GB DDR4 DRAM
> > > > > > - eMMC connector for optional module
> > > > > > - micro SD card slot
> > > > > > - 1 x USB 3.0 host port
> > > > > > - 2 x USB 2.0 host port
> > > > > > - 1 x USB 2.0 OTG port
> > > > > > - HDMI video output
> > > > > > - TRRS connector with audio and composite video output
> > > > > > - gigabit Ethernet
> > > > > > - consumer IR receiver
> > > > > > - debug UART pins
> > > > > >
> > > > > > The ROC-RK3328-CC has the enable pin of the SD card power switch
> > > > > > tied
> > > > > > to GPIO_0_D6. This pin also has the function SDMMC0_PWREN, which is
> > > > > > muxed by default. SDMMC0_PWREN is an active high signal controlled
> > > > > > by
> > > > > > the MMC controller, however the switch enable is active low, and
> > > > > > pulled low (enabled) by default to make things work on boot.
> > > > > >
> > > > > > As such, we need to mux away from SDMMC0_PWREN and use GPIO to
> > > > > > enable
> > > > > > power to the card. The default GPIO state for the pin is pull-down
> > > > > > and
> > > > > > input, which doesn't require extra configuration when paired with
> > > > > > the
> > > > > > external pull-down and active low switch.
> > > > > >
> > > > > > Thus we make a custom target for this board and do the muxing in its
> > > > > > spl_board_init() function.
> > > > > >
> > > > > > The device tree file is synced from the Linux kernel next-20200324.
> > > > > >
> > > > > > Signed-off-by: Chen-Yu Tsai
> > > > > > ---
> > > > >
> > > > > [snip]
> > > > >
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > new file mode 100644
> > > > > > index ..f2318e71ac33
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/MAINTAINERS
> > > > > > @@ -0,0 +1,7 @@
> > > > > > +ROC-RK3328-CC
> > > > > > +M: Loic Devulder
> > > > > > +M: Chen-Yu Tsai
> > > > > > +S: Maintained
> > > > > > +F: board/firefly/roc-cc-rk3328/
> > > > > > +F: configs/roc-rk3328-cc_defconfig
> > > > > > +F: arch/arm/dts/rk3328-roc-cc-u-boot.dtsi
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/Makefile
> > > > > > b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > new file mode 100644
> > > > > > index ..1550b5f5f16e
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/Makefile
> > > > > > @@ -0,0 +1 @@
> > > > > > +obj-y := board.o
> > > > > > diff --git a/board/firefly/roc-cc-rk3328/board.c
> > > > > > b/board/firefly/roc-cc-rk3328/board.c
> > > > > > new file mode 100644
> > > > > > index ..eca58c86b53e
> > > > > > --- /dev/null
> > > > > > +++ b/board/firefly/roc-cc-rk3328/board.c
> > > > > > @@ -0,0 +1,38 @@
> > > > > > +// SPDX-License-Identifier: GPL-2.0+
> > > > > > +/*
> > > > > > + * (C) Copyright 2020 Chen-Yu Tsai
> > > > > > + */
> > > > > > +#include
> > > > > > +
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +#if defined(CONFIG_SPL_BUILD)
> > > > > > +
> > > > > > +#define GRF_BASE 0xFF10
> > > > > > +
> > > > > > +enum {
> > > > > > + GPIO_0_D6_GPIO = 0 << 12,
> > > > > > + GPIO_0_D6_MASK = 0x3 << 12
> > > > > > +};
> > > > > > +
> > > > > > +/*
> > > > > > + * The ROC-RK3328-CC has the enable pin of the SD card power
> > > > > > switch tied
> > > > > > + * to GPIO_0_D6. This pin also has the function SDMMC0_PWREN,
> > > > > > which is
> > > > > > + * muxed by default. SDMMC0_PWREN is an active high signal
> > > > > > controlled by
> > > > > > + * the MMC controller, however the switch enable is active low, and
> > > > > > + * pulled low (enabled) by default to make things work on boot.
> > > > > > + *
> > > > > > + * As such, we need to mux away from SDMMC0_PWREN and use GPIO to
> > > > > > enable
> > > > > > + * power to the card. The default GPIO state for the pin is
> > > > > > pull-down and
> > > > > > + * input, which doesn't require extra configuration when paired
> > > > > > with the
> > > > > > + * external pull-down and active low switch.
> > > > > > + */
> > > > > > +void spl_board_init(void)
> > > > > > +{
> > > > > > + struct rk3328_grf_regs * const grf = (void *)GRF_BASE;
> > > > > > +
> > > > > > + rk_clrsetreg(>gpio0d_iomux,
RE: [PATCH V3 12/14] ARM: dts: stm32: Repair PMIC configuration on AV96
Hi, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:52 > > The core and vdd PMIC buck regulators were misconfigured, which caused > instability of the board and malfunction of high-speed interfaces, like the > RGMII. > Configure the PMIC correctly to repair these problems. Also, model the missing > Enpirion EP53A8LQI on the DHCOR SoM as a fixed regulator. > > Reviewed-by: Patrice Chotard > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 11/14] ARM: dts: stm32: Add missing ethernet PHY reset on AV96
Hi, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:52 > > Add PHY reset GPIO on AV96 ethernet PHY. > > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 10/14] ARM: dts: stm32: Repair ethernet operation on AV96
Hi, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:52 > > The AV96 RGMII uses different pinmux for ETH_RGMII_TXD0, > ETH_RGMII_RXD2 and ETH_RGMII_TX_CTL. Use the correct pinmux to make > ethernet operational. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 09/14] ARM: dts: stm32: Add alternate pinmux for ethernet RGMII
Hi, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:52 > > Add another mux option for DWMAC RGMII, this is used on AV96 board. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 08/14] ARM: dts: stm32: Add configuration EEPROM on AV96
Hi, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:52 > > The board has an EEPROM on the same I2C bus as PMIC, at address 0x53. > The EEPROM contains the board MAC address. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- Applied to u-boot-stm/master, with one minor modification I also add the alias eeprom0 = (with eeprom0: eeprom@53) to be compatible with previous patch "ARM: dts: stm32: Use DT alias for the configuration EEPROM" Regards Patrick
RE: [PATCH V3 07/14] ARM: dts: stm32: Use DT alias for the configuration EEPROM
Hi, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:51 > > Use DT /aliases node to establish a stable phandle to the configuration > EEPROM. > This permits the configuration EEPROM to be moved e.g. to a different address > or > a different bus. Adjust the board code to handle new phandle lookup. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 06/14] ARM: dts: stm32: Add QSPI NOR on AV96
Hi, > -Original Message- > From: Marek Vasut > Sent: mardi 31 mars 2020 19:51 > To: u-boot@lists.denx.de > Cc: Marek Vasut ; Manivannan Sadhasivam > ; Patrick DELAUNAY > ; Patrice CHOTARD > Subject: [PATCH V3 06/14] ARM: dts: stm32: Add QSPI NOR on AV96 > Importance: High > > The DH Electronics DHCOR SOM has QSPI NOR on the SoM itself, add it into the > DT. > > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > V2: Drop the explicit flash type in DT node, use spi-flash > V3: Reduce the SPI NOR window to 2 MiB > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 05/14] ARM: dts: stm32: Repair SDMMC2 operation
Hi Marek, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:51 > > The eMMC uses different pinmux for the top four data lines, use such a pinmux, > otherwise it takes a very long time until the test for 8bit operation times > out. And > this is the correct pinmux per schematic too. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > V2: Update also the -u-boot.dtsi to match this change > V3: No change > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 04/14] ARM: dts: stm32: Add alternate pinmux for SDMMC2 pins 4-7
Hi, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:51 > > Add another mux option for SDMMC2 pins 4..7, this is used on AV96 board. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > V2: Use correct pin AFs > V3: No change > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 03/14] ARM: dts: stm32: Repair SDMMC1 operation on AV96
Hi Marek, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:51 > > The SD uses different pinmux for the D123DIRline, use such a pinmux, otherwise > there is a pinmux collision on the AV96. Add missing SD voltage regulator > switch > and enable SDR104 operation. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > V2: New patch > V3: No change > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 02/14] ARM: dts: stm32: Add alternate pinmux for SDMMC1 direction pins
Hi, > From: Marek Vasut > Sent: mardi 31 mars 2020 19:51 > > Add another mux option for SDMMC1 direction pins, in particular > SDMMC1_D123DIR, this is used on AV96 board. > > Reviewed-by: Patrice Chotard > Reviewed-by: Patrick Delaunay > Signed-off-by: Marek Vasut > Cc: Manivannan Sadhasivam > Cc: Patrick Delaunay > Cc: Patrice Chotard > --- > V2: New patch > V3: No change > --- Applied to u-boot-stm/master, thanks! Regards Patrick
RE: [PATCH V3 01/14] ARM: dts: stm32: Repair SD1 pre-reloc pinmux DT node on AV96
Hi,
> From: Marek Vasut
> Sent: mardi 31 mars 2020 19:51
>
> The sdmmc1_dir_pins_a: sdmmc1-dir-0 layout changed in commit 35a54d41d9d4
> ("ARM: dts: stm32mp1: sync device tree with v5.2-rc4") such that pins{};
> became
> pins1{};pins2{};, however the SPL extras were not updated to reflect that
> change.
> Fix this.
>
> This fixes booting from SD1 X9 slot on the AV96 board.
>
> Reviewed-by: Patrice Chotard
> Reviewed-by: Patrick Delaunay
> Fixes: 35a54d41d9d4 ("ARM: dts: stm32mp1: sync device tree with v5.2-rc4")
> Signed-off-by: Marek Vasut
> Cc: Manivannan Sadhasivam
> Cc: Patrick Delaunay
> Cc: Patrice Chotard
> ---
> V2: Adjust patch subject
> V3: No change
> ---
Applied to u-boot-stm/master, thanks!
Regards
Patrick
RE: [PATCH v5 00/17] Enable ARM Trusted Firmware for U-Boot
Hi Marek/Simon,
Can you please help review and comment on this patchsets ?
> Any comment on this v5 patchsets ?
>
> > From: "Ang, Chee Hong"
> >
> > v5 changes:
> > This is another revision without the System Manager driver to handle
> > the secure/non-secure access. DW MAC and MMC drivers will make direct
> > calls to the high-level API to ATF if it's running in EL2 on
> > Stratix10/Agilex otherwise these drivers work as it is.
> >
> > [PATCH v5 08/17] arm: socfpga: Define SMC function identifiers for
> > PSCI SiP services
> > - Add documentation for high-level API supported by ATF:
> > - INTEL_SIP_SMC_FUNCID_HPS_SET_PHYINTF (For setting PHY interface)
> > - INTEL_SIP_SMC_FUNCID_HPS_SET_SDMMC_CCLK (For setting SDMMC
> clock
> > phase)
> >
> > [PATCH v5 10/17] mmc: dwmmc: socfpga: Add ATF support for MMC driver
> > - Call 'INTEL_SIP_SMC_FUNCID_HPS_SET_SDMMC_CCLK' if U-Boot running in
> > EL2 (non-secure)
> >
> > [PATCH v5 11/17] net: designware: socfpga: Add ATF support for MAC
> > driver
> > - Call 'INTEL_SIP_SMC_FUNCID_HPS_SET_PHYINTF' if U-Boot running in EL2
> > (non-secure)
> >
> > [PATCH v5 17/17] configs: socfpga: Add defconfig for Agilex and
> > Stratix 10 with ATF support
> > - Keep the existing Stratix10/Agilex defconfigs and add new defconfigs
> > with ATF support
> >
> > v4:
> > https://lists.denx.de/pipermail/u-boot/2020-March/402289.html
> >
> > These patchsets have dependency on:
> > https://lists.denx.de/pipermail/u-boot/2019-September/384906.html
> >
> > Ang, Chee Hong (1):
> > configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF
> > support
> >
> > Chee Hong Ang (16):
> > configs: agilex: Remove CONFIG_OF_EMBED
> > arm: socfpga: add fit source file for pack itb with ATF
> > arm: socfpga: Add function for checking description from FIT image
> > arm: socfpga: Load FIT image with ATF support
> > arm: socfpga: Override 'lowlevel_init' to support ATF
> > arm: socfpga: Disable "spin-table" method for booting Linux
> > arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > arm: socfpga: soc64: Remove PHY interface setup from misc arch init
> > mmc: dwmmc: socfpga: Add ATF support for MMC driver
> > net: designware: socfpga: Add ATF support for MAC driver
> > arm: socfpga: Add ATF support for Reset Manager driver
> > arm: socfpga: stratix10: Initialize timer in SPL
> > arm: socfpga: Add ATF support to query FPGA configuration status
> > arm: socfpga: stratix10: Add ATF support for FPGA reconfig driver
> > arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to
> > mbox_reset_cold()
> >
> > arch/arm/mach-socfpga/Kconfig | 2 -
> > arch/arm/mach-socfpga/Makefile | 2 +
> > arch/arm/mach-socfpga/board.c | 10 +
> > arch/arm/mach-socfpga/include/mach/misc.h | 3 +
> > arch/arm/mach-socfpga/lowlevel_init_64.S | 81
> > arch/arm/mach-socfpga/mailbox_s10.c| 4 +
> > arch/arm/mach-socfpga/misc_s10.c | 121 ++
> > arch/arm/mach-socfpga/reset_manager_s10.c | 10 +
> > arch/arm/mach-socfpga/timer_s10.c | 3 +-
> > board/altera/soc64/its/fit_spl_atf.its | 52 +++
> > ...ilex_defconfig => socfpga_agilex_atf_defconfig} | 8 +-
> > configs/socfpga_agilex_defconfig | 1 -
> > ...x_defconfig => socfpga_stratix10_atf_defconfig} | 23 +-
> > drivers/fpga/stratix10.c | 141 ++-
> > drivers/mmc/socfpga_dw_mmc.c | 21 +
> > drivers/net/dwmac_socfpga.c| 43 +-
> > include/configs/socfpga_soc64_common.h | 4 +
> > include/linux/intel-smc.h | 445
> > +
> > 18 files changed, 871 insertions(+), 103 deletions(-) create mode
> > 100644 arch/arm/mach-socfpga/lowlevel_init_64.S
> > create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > copy configs/{socfpga_agilex_defconfig =>
> > socfpga_agilex_atf_defconfig}
> > (87%) copy configs/{socfpga_agilex_defconfig =>
> > socfpga_stratix10_atf_defconfig} (68%) create mode 100644
> > include/linux/intel-smc.h
> >
> > --
> > 2.7.4
u-boot DT configuration node
Hi Rob and others, for couple of years already u-boot is using config node in root DT for u-boot configuration. Here is one example in u-boot source code. https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/exynos5250-spring.dts#L47 And here is dt binding description https://gitlab.denx.de/u-boot/u-boot/-/blob/master/doc/device-tree-bindings/config.txt I was checking dt binding specification and there no such a thing described there. It means I expect this is more adhoc u-boot solution. We have reached the point where could be beneficial to put some u-boot specific configurations to DT. Actually I have done similar thing some time ago too by using chosen node and add xilinx specific property there to point to eeprom. https://gitlab.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/zynqmp-zcu102-revA.dts#L39 I think it is a time to discuss it and do it properly. First of all my question is where we could list SW prefixes to make sure that they are listed and everybody is aware about it. We have vendor-prefixes and we should have a way to record also prefixes for sw projects. U-Boot is using u-boot. Xen has file in the kernel with using xen prefix. At least these two should be listed. Next my question is what is the recommended way to pass sw specific parameters via DT? I think using chosen node is more appropriate then adhoc config node. Or is there a better way how this should be done? Thanks, Michal
