Re: [PATCH] arm: dts: socfpga: l2c-310 full line of zeros error @kernel boot
Am 11.06.2020 um 03:51 schrieb Tan, Ley Foon: -Original Message- From: Dinh Nguyen Sent: Thursday, June 11, 2020 2:55 AM To: Marek Vasut ; Nico Becker ; u-boot@lists.denx.de Cc: simon.k.r.goldschm...@gmail.com; Tan, Ley Foon Subject: Re: [PATCH] arm: dts: socfpga: l2c-310 full line of zeros error @kernel boot On 6/10/20 8:23 AM, Marek Vasut wrote: On 6/10/20 3:21 PM, Nico Becker wrote: Am 10.06.2020 um 15:19 schrieb Marek Vasut: On 6/10/20 3:14 PM, Nico Becker wrote: if i remove the arm,shared-override option in the dts file, the kernel boot without an error. With the option the kernel boots with the following error: dmesg --level=err L2C-310: enabling full line of zeros but not enabled in Cortex-A9 i ve no idea why the parameter have an effect on that. i try several kernels, allays the same behavior. diff --git a/arch/arm/dts/socfpga.dtsi b/arch/arm/dts/socfpga.dtsi index eda558f2fe..c2173416c7 100644 --- a/arch/arm/dts/socfpga.dtsi +++ b/arch/arm/dts/socfpga.dtsi @@ -719,7 +719,6 @@ arm,data-latency = <2 1 1>; prefetch-data = <1>; prefetch-instr = <1>; - arm,shared-override; arm,double-linefill = <1>; arm,double-linefill-incr = <0>; arm,double-linefill-wrap = <1>; Do you use latest u-boot/master or some older version ? Which one? sorry, i forget it. i use v2020.01 Should be OK I think. Hm, I suspect this is another fun with the ACTLR/CPACR registers, like 937db7188e3a5ab8f802eff9b57854189379667a . Ley, any ideas ? I just tested with 2020.07-rc4-00022-gbe79009f3b along with linux v5.7, and I no longer see the error. Yes, I also just tested 2020.04 uboot and 5.4.23-lts kernel, also didn't see this error. What kernel version you are using? Regards Ley Foon hello, i use kernel 4.14.126-rt62-ltsi. greetings
Re: [v2 1/3] Watchdog: introduce ARM SBSA watchdog driver
On 11.06.20 13:52, Biwen Li wrote:
From: Zhao Qiang
According to Server Base System Architecture (SBSA) specification,
the SBSA Generic Watchdog has two stage timeouts: the first signal
(WS0) is for alerting the system by interrupt, the second one (WS1) is a
real hardware reset.
More details about the hardware specification of this device:
ARM DEN0029B - Server Base System Architecture (SBSA)
This driver can operate ARM SBSA Generic Watchdog as a single stage
In the single stage mode, when the timeout is reached, your system
will be reset by WS1. The first signal (WS0) is ignored.
Signed-off-by: Zhao Qiang
Signed-off-by: Biwen Li
---
Change in v2:
- fix copyright
MAINTAINERS | 1 +
drivers/watchdog/Kconfig | 6 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/sbsa_gwdt.c | 131 +++
4 files changed, 139 insertions(+)
create mode 100644 drivers/watchdog/sbsa_gwdt.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fd975c..09554c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -685,6 +685,7 @@ M: Priyanka Jain
S:Maintained
T:git https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git
F:drivers/watchdog/sp805_wdt.c
+F: drivers/watchdog/sbsa_gwdt.c
I2C
M:Heiko Schocher
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index bf06180..191891c 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -163,6 +163,12 @@ config WDT_SANDBOX
can be probed and supports all of the methods of WDT, but does not
really do anything.
+config WDT_SBSA
+ bool "SBSA watchdog timer support"
+ depends on WDT
+ help
+ Select this to enable SBSA watchdog timer.
Please extend this help text a bit (add something from the commit text)
to make it more descriptive.
+
config WDT_SP805
bool "SP805 watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 519bbd3..0f0b2eb 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
+obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 000..ddac668
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Watchdog driver for SBSA
+ *
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR 0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS 0x000
+#define SBSA_GWDT_WOR 0x008
+#define SBSA_GWDT_WCV 0x010
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR 0xfcc
+#define SBSA_GWDT_IDR 0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN BIT(0)
+#define SBSA_GWDT_WCS_WS0 BIT(1)
+#define SBSA_GWDT_WCS_WS1 BIT(2)
+
+struct sbsa_gwdt_priv {
+ void __iomem *reg_refresh;
+ void __iomem *reg_control;
+};
+
+static int sbsa_gwdt_reset(struct udevice *dev)
+{
+ struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+
+ writel(0, priv->reg_refresh + SBSA_GWDT_WRR);
+
+ return 0;
+}
+
+static int sbsa_gwdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+ u32 clk;
+ u32 load_value;
+
+ struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
Nitpicking:
Remove empty line above and add sone below the variable declarations
(reverse x-max tree is preferred):
struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
u32 load_value;
u32 clk;
Other than that:
Reviewed-by: Stefan Roese
Thanks,
Stefan
+ /*
+* it work in the single stage mode in u-boot,
+* The first signal (WS0) is ignored,
+* the timeout is (WOR * 2), so the WOR should be configured
+* to half value of timeout.
+*/
+ clk = get_tbclk();
+ writel(clk / 2 * timeout,
+ priv->reg_control + SBSA_GWDT_WOR);
+
+ /* writing WCS will cause an explicit watchdog refresh */
+ writel(SBSA_GWDT_WCS_EN, priv->reg_control + SBSA_GWDT_WCS);
+
+ return 0;
+}
+
+static int sbsa_gwdt_stop(struct udevice *dev)
+{
+ struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+
+ writel(0, priv->reg_control + SBSA_GWDT_WCS);
+
+ return 0;
+}
+
+static int sbsa_gwdt_expire_now(struct udevice *dev, ulong flags)
+{
+ sbsa_gwdt_start(dev, 0, flags);
+
+ return 0;
+}
+
+static int
RE: [PATCH u-boot 4/4] eth/r8152: support RTL8153B/RTL8154B
Marek Vasut [mailto:ma...@denx.de] > Sent: Friday, June 12, 2020 8:05 AM [...] > > The real data (16-bit) would be inserted a dummy bit, > > and store the 17-bit to efuse offset 0x7d. Therefore, when > > reading the 17-bit data from efuse, we have to remove the > > dummy to get the real data. > > Ah, hmm, then let's use u32 type and be done with it. That solves the > typecasts and is safe. Would that work ? The unit of PHY data is 2-byte, so I think I have to convert it. void ocp_reg_write(struct r8152 *tp, u16 addr, u16 data); Best Regards, Hayes
Re: [PATCH 28/30] spi: Enable missing CONFIG_SPL_DM_SPI support
On Thu, Jun 11, 2020 at 7:17 AM Tom Rini wrote: > > On Thu, Jun 11, 2020 at 05:38:15AM -0500, Adam Ford wrote: > > On Wed, Jun 10, 2020 at 3:17 PM Tom Rini wrote: > > > > > > Due to how the Makefile logic is we currently get DM_SPI support in SPL > > > enabled by having DM_SPI enabled for full U-Boot but not having > > > CONFIG_SPL_DM_SPI set. Add this missing option to boards that were > > > inadvertently making use of it. > > > > Not knowing exactly which patches to apply to see the Makefile changes > > in question, I'm just doing a code review instead of the test. > > > > > > Cc: Adam Ford > > [snip] > > > > Acked-by: Adam Ford #da850evm > > Tested-by: Adam Ford #da850evm > > > Signed-off-by: Tom Rini > > > --- > > > > > configs/da850evm_defconfig | 1 + > > > configs/da850evm_nand_defconfig| 1 + > > > > The da850evm_defconfig is setup to boot from SPI Flash, so that board > > will need it. Thank you. > > > > The da850evm_nand_defconfig is set to boot from NAND via the NAND > > controller and not SPI, so it's probably not necessary, but I don't > > think it hurts anything. I may go through later and remove the > > CONFIG_SPL_DM_SPI from the nand version later. > > > > [snip] > > > > > diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig > > > index 1a6a97ed161a..12768065f3ab 100644 > > > --- a/configs/da850evm_defconfig > > > +++ b/configs/da850evm_defconfig > > > @@ -12,6 +12,7 @@ CONFIG_ENV_OFFSET=0x8 > > > CONFIG_ENV_SECT_SIZE=0x1 > > > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 > > > CONFIG_DM_GPIO=y > > > +CONFIG_SPL_DM_SPI=y > > > > Thank you, we'll need this. > > > > > CONFIG_SPL_SERIAL_SUPPORT=y > > > CONFIG_NR_DRAM_BANKS=1 > > > CONFIG_SPL=y > > > diff --git a/configs/da850evm_nand_defconfig > > > b/configs/da850evm_nand_defconfig > > > index e805f2c10eda..13026fd1ea2c 100644 > > > --- a/configs/da850evm_nand_defconfig > > > +++ b/configs/da850evm_nand_defconfig > > > @@ -11,6 +11,7 @@ CONFIG_ENV_SIZE=0x2 > > > CONFIG_ENV_OFFSET=0x0 > > > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 > > > CONFIG_DM_GPIO=y > > > +CONFIG_SPL_DM_SPI=y > > > > If you do a V2 for some reason and don't want to add this here in the > > future, I wouldn't object. If not, I'll do some testing later with > > this removed. > > This is similar to the socfpga case Marek pointed out. Today, the > platforms are building with SPI support enabled and are implicitly > getting SPL_DM_SPI enabled too > http://patchwork.ozlabs.org/project/uboot/patch/20200610201634.8457-30-tr...@konsulko.com/ > is the Makefile patch but it's just dropping in to the DM or not-DM side > based on SPL/TPL_DM and not just DM in main U-Boot. > > -- > Tom
Re: [PATCH 28/30] spi: Enable missing CONFIG_SPL_DM_SPI support
On Thu, Jun 11, 2020 at 9:09 PM Adam Ford wrote: > > On Thu, Jun 11, 2020 at 7:17 AM Tom Rini wrote: > > > > On Thu, Jun 11, 2020 at 05:38:15AM -0500, Adam Ford wrote: > > > On Wed, Jun 10, 2020 at 3:17 PM Tom Rini wrote: > > > > > > > > Due to how the Makefile logic is we currently get DM_SPI support in SPL > > > > enabled by having DM_SPI enabled for full U-Boot but not having > > > > CONFIG_SPL_DM_SPI set. Add this missing option to boards that were > > > > inadvertently making use of it. > > > > > > Not knowing exactly which patches to apply to see the Makefile changes > > > in question, I'm just doing a code review instead of the test. > > > > > > > > Cc: Adam Ford > > > [snip] > > > > > > Acked-by: Adam Ford #da850evm > > > > > Tested-by: Adam Ford #da850evm > > > > > Signed-off-by: Tom Rini > > > > --- > > > > > > > configs/da850evm_defconfig | 1 + > > > > configs/da850evm_nand_defconfig| 1 + > > > > > > The da850evm_defconfig is setup to boot from SPI Flash, so that board > > > will need it. Thank you. > > > > > > The da850evm_nand_defconfig is set to boot from NAND via the NAND > > > controller and not SPI, so it's probably not necessary, but I don't > > > think it hurts anything. I may go through later and remove the > > > CONFIG_SPL_DM_SPI from the nand version later. > > > > > > [snip] > > > > > > > diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig > > > > index 1a6a97ed161a..12768065f3ab 100644 > > > > --- a/configs/da850evm_defconfig > > > > +++ b/configs/da850evm_defconfig > > > > @@ -12,6 +12,7 @@ CONFIG_ENV_OFFSET=0x8 > > > > CONFIG_ENV_SECT_SIZE=0x1 > > > > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 > > > > CONFIG_DM_GPIO=y > > > > +CONFIG_SPL_DM_SPI=y > > > > > > Thank you, we'll need this. > > > > > > > CONFIG_SPL_SERIAL_SUPPORT=y > > > > CONFIG_NR_DRAM_BANKS=1 > > > > CONFIG_SPL=y > > > > diff --git a/configs/da850evm_nand_defconfig > > > > b/configs/da850evm_nand_defconfig > > > > index e805f2c10eda..13026fd1ea2c 100644 > > > > --- a/configs/da850evm_nand_defconfig > > > > +++ b/configs/da850evm_nand_defconfig > > > > @@ -11,6 +11,7 @@ CONFIG_ENV_SIZE=0x2 > > > > CONFIG_ENV_OFFSET=0x0 > > > > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 > > > > CONFIG_DM_GPIO=y > > > > +CONFIG_SPL_DM_SPI=y I just sent a separate patch removing SPI from SPL from the nand defconfig since the system is booting from NAND to free up some space. I don't know how that plays into this patch for the nand version. If you need to apply your patch first, I can always rebase mine and re-submit later. adam > > > > > > If you do a V2 for some reason and don't want to add this here in the > > > future, I wouldn't object. If not, I'll do some testing later with > > > this removed. > > > > This is similar to the socfpga case Marek pointed out. Today, the > > platforms are building with SPI support enabled and are implicitly > > getting SPL_DM_SPI enabled too > > http://patchwork.ozlabs.org/project/uboot/patch/20200610201634.8457-30-tr...@konsulko.com/ > > is the Makefile patch but it's just dropping in to the DM or not-DM side > > based on SPL/TPL_DM and not just DM in main U-Boot. > > > > -- > > Tom
Re: [PATCH v2] Fix MMC access on Sabrelite
On 6/11/2020 10:53 AM, Martyn Welch wrote:
> It appears that MMC access on the Sabrelite has been broken since
> cdcaee9518:
>
> Loading Environment from MMC... Card did not respond to voltage select!
> *** Warning - No block device, using default environment
>
> Remove the board_mmc_init() and related entries now that we should be
> using DM_MMC, add PINCTRL so that things work as expected.
>
> Signed-off-by: Martyn Welch
> ---
>
> Changes in v2:
> - Removed now redundant mmc header.
>
> board/boundary/nitrogen6x/nitrogen6x.c | 72 --
> configs/mx6qsabrelite_defconfig| 3 ++
> 2 files changed, 3 insertions(+), 72 deletions(-)
>
> diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
> b/board/boundary/nitrogen6x/nitrogen6x.c
> index d49725daa8..b3b121bad8 100644
> --- a/board/boundary/nitrogen6x/nitrogen6x.c
> +++ b/board/boundary/nitrogen6x/nitrogen6x.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -161,26 +160,6 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
> IOMUX_PAD_CTRL(SD2_DAT3__SD2_DATA3, USDHC_PAD_CTRL),
> };
>
> -static iomux_v3_cfg_t const usdhc3_pads[] = {
> - IOMUX_PAD_CTRL(SD3_CLK__SD3_CLK, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_CMD__SD3_CMD, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT0__SD3_DATA0, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT1__SD3_DATA1, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT2__SD3_DATA2, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT3__SD3_DATA3, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT5__GPIO7_IO00, NO_PAD_CTRL), /* CD */
> -};
> -
> -static iomux_v3_cfg_t const usdhc4_pads[] = {
> - IOMUX_PAD_CTRL(SD4_CLK__SD4_CLK, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_CMD__SD4_CMD, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT0__SD4_DATA0, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT1__SD4_DATA1, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT2__SD4_DATA2, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT3__SD4_DATA3, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(NANDF_D6__GPIO2_IO06, NO_PAD_CTRL), /* CD */
> -};
> -
> static iomux_v3_cfg_t const enet_pads1[] = {
> IOMUX_PAD_CTRL(ENET_MDIO__ENET_MDIO, ENET_PAD_CTRL),
> IOMUX_PAD_CTRL(ENET_MDC__ENET_MDC, ENET_PAD_CTRL),
> @@ -305,57 +284,6 @@ int board_ehci_power(int port, int on)
>
> #endif
>
> -#ifdef CONFIG_FSL_ESDHC_IMX
> -static struct fsl_esdhc_cfg usdhc_cfg[2] = {
> - {USDHC3_BASE_ADDR},
> - {USDHC4_BASE_ADDR},
> -};
> -
> -int board_mmc_getcd(struct mmc *mmc)
> -{
> - struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
> - int gp_cd = (cfg->esdhc_base == USDHC3_BASE_ADDR) ? IMX_GPIO_NR(7, 0) :
> - IMX_GPIO_NR(2, 6);
> -
> - gpio_direction_input(gp_cd);
> - return !gpio_get_value(gp_cd);
> -}
> -
> -int board_mmc_init(bd_t *bis)
> -{
> - int ret;
> - u32 index = 0;
> -
> - usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
> - usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK);
> -
> - usdhc_cfg[0].max_bus_width = 4;
> - usdhc_cfg[1].max_bus_width = 4;
> -
> - for (index = 0; index < CONFIG_SYS_FSL_USDHC_NUM; ++index) {
> - switch (index) {
> - case 0:
> - SETUP_IOMUX_PADS(usdhc3_pads);
> - break;
> - case 1:
> -SETUP_IOMUX_PADS(usdhc4_pads);
> -break;
> - default:
> -printf("Warning: you configured more USDHC controllers"
> -"(%d) then supported by the board (%d)\n",
> -index + 1, CONFIG_SYS_FSL_USDHC_NUM);
> -return -EINVAL;
> - }
> -
> - ret = fsl_esdhc_initialize(bis, _cfg[index]);
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -#endif
> -
> #ifdef CONFIG_MXC_SPI
> int board_spi_cs_gpio(unsigned bus, unsigned cs)
> {
> diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
> index ea338c1b53..39b0ef7a42 100644
> --- a/configs/mx6qsabrelite_defconfig
> +++ b/configs/mx6qsabrelite_defconfig
> @@ -28,6 +28,7 @@ CONFIG_CMD_GPT=y
> # CONFIG_RANDOM_UUID is not set
> CONFIG_CMD_I2C=y
> CONFIG_CMD_MMC=y
> +# CONFIG_CMD_PINMUX is not set
> CONFIG_CMD_SATA=y
> CONFIG_CMD_USB=y
> CONFIG_CMD_USB_MASS_STORAGE=y
> @@ -55,6 +56,8 @@ CONFIG_PHYLIB=y
> CONFIG_PHY_MICREL=y
> CONFIG_PHY_MICREL_KSZ90X1=y
> CONFIG_MII=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_IMX6=y
> CONFIG_SPI=y
> CONFIG_DM_SPI=y
> CONFIG_MXC_SPI=y
>
Tested-by: Troy Kisky
Acked-by: Troy Kisky
But for me, it worked both before and after this patch.
If you feel like sending a version 3, you can update these too.
nitrogen6dl2g_defconfig
nitrogen6dl_defconfig
nitrogen6q2g_defconfig
nitrogen6q_defconfig
nitrogen6s1g_defconfig
Otherwise, I'll do it later
Thanks
How to fix: partition (SPL) size alignment incorrect
I am doing some spot checks on the da850evm which boots from SPI. It seems OK, however, when I run the mtdparts, I expect to see the partition map of the SPI flash. Unfortunately, I get the following error: nor0: partition (SPL) size alignment incorrect Currently, it's setup as follows: CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:32k(SPL),480k(u-boot),64k(u-boot-env),7552k(kernel-spare),64k(MAC-Address)" This used to work, but I was hoping someone might have an idea on what I can do to address it. I haven't had a chance to bisect yet. Thanks in advance. adam
Re: [PATCH 01/10] dtoc: add support to scan drivers
Hi Walter,
On Thu, 11 Jun 2020 at 13:07, Walter Lozano wrote:
>
> Hi Simon,
>
> On 11/6/20 14:22, Simon Glass wrote:
> > Hi Walter,
> >
> > On Thu, 11 Jun 2020 at 11:11, Walter Lozano
> > wrote:
> >> Hi Simon
> >>
> >> On 11/6/20 13:45, Simon Glass wrote:
> >>> Hi Walter,
> >>>
> >>> On Mon, 8 Jun 2020 at 09:49, Walter Lozano
> >>> wrote:
> Hi Simon,
>
> On 4/6/20 12:59, Simon Glass wrote:
> > Hi Walter,
> >
> > On Fri, 29 May 2020 at 12:15, Walter Lozano
> > wrote:
> >> Currently dtoc scans dtbs to convert them to struct platdata and
> >> to generate U_BOOT_DEVICE entries. These entries need to be filled
> >> with the driver name, but at this moment the information used is the
> >> compatible name present in the dtb. This causes that only nodes with
> >> a compatible name that matches a driver name generate a working
> >> entry.
> >>
> >> In order to improve this behaviour, this patch adds to dtoc the
> >> capability of scan drivers source code to generate a list of valid
> >> driver
> >> names. This allows to rise a warning in the case that an U_BOOT_DEVICE
> >> entry will try to use a name not valid.
> >>
> >> Additionally, in order to add more flexibility to the solution, adds
> >> the
> >> U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows
> >> an
> >> easy way to declare driver name aliases. Thanks to this, dtoc can look
> >> for the driver name based on its alias when it populates the
> >> U_BOOT_DEVICE
> >> entry.
> >>
> >> Signed-off-by: Walter Lozano
> >> ---
> >> include/dm/device.h| 7
> >> tools/dtoc/dtb_platdata.py | 83
> >> --
> >> 2 files changed, 86 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/dm/device.h b/include/dm/device.h
> >> index 975eec5d0e..2cfe10766f 100644
> >> --- a/include/dm/device.h
> >> +++ b/include/dm/device.h
> >> @@ -282,6 +282,13 @@ struct driver {
> >> #define DM_GET_DRIVER(__name)
> >> \
> >>ll_entry_get(struct driver, __name, driver)
> >>
> >> +/**
> >> + * Declare a macro to state a alias for a driver name. This macro will
> >> + * produce no code but its information will be parsed by tools like
> >> + * dtoc
> >> + */
> >> +#define U_BOOT_DRIVER_ALIAS(__name, __alias)
> >> +
> >> /**
> >> * dev_get_platdata() - Get the platform data for a device
> >> *
> >> diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
> >> index ecfe0624d1..23cfda2f88 100644
> >> --- a/tools/dtoc/dtb_platdata.py
> >> +++ b/tools/dtoc/dtb_platdata.py
> >> @@ -13,6 +13,8 @@ static data.
> >>
> >> import collections
> >> import copy
> >> +import os
> >> +import re
> >> import sys
> >>
> >> from dtoc import fdt
> >> @@ -140,6 +142,9 @@ class DtbPlatdata(object):
> >> _include_disabled: true to include nodes marked status =
> >> "disabled"
> >> _outfile: The current output file (sys.stdout or a real
> >> file)
> >> _lines: Stashed list of output lines for outputting in the
> >> future
> >> +_aliases: Dict that hold aliases for compatible strings
> > key: The driver name, i.e. the part between brackets in
> > U_BOOT_DRIVER(xx) ??
> > value: ...
> Noted.
> >> +_drivers: List of valid driver names found in drivers/
> >> +_driver_aliases: Dict that holds aliases for driver names
> > key:
> > vaue:
> OK.
> >> """
> >> def __init__(self, dtb_fname, include_disabled):
> >> self._fdt = None
> >> @@ -149,6 +154,35 @@ class DtbPlatdata(object):
> >> self._outfile = None
> >> self._lines = []
> >> self._aliases = {}
> >> +self._drivers = []
> >> +self._driver_aliases = {}
> >> +
> >> +def get_normalized_compat_name(self, node):
> >> +"""Get a node's normalized compat name
> >> +
> >> +Returns a valid driver name by retrieving node's first
> >> compatible
> >> +string as a C identifier and perfomrming a check against
> >> _drivers
> > performing
> Noted.
> >> +and a lookup in driver_aliases rising a warning in case of
> >> failure.
> > s/ rising/, printing/
> OK.
> >> +
> >> +Args:
> >> +node: Node object to check
> >> +Return:
> >> +Tuple:
> >> +Driver name associated with the first compatible
> >> string
> >> +List of C identifiers for all the other compatible
> >> strings
>
[PATCH] ARM: da850-evm: Remove SPI from SPL when booting from NAND
The da850evm boots from SPI flash while the da850evm_nand_defconfig boots from NAND and these are configs are mutually exclusive. Since there isn't a need for SPI during SPL in the NAND configuration, this patch removes the SPI drivers in SPL while making them still available in U-Boot proper. This should save some code space in SPL. Signed-off-by: Adam Ford diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig index bc2c0a2c25..179a1782c6 100644 --- a/configs/da850evm_nand_defconfig +++ b/configs/da850evm_nand_defconfig @@ -9,12 +9,9 @@ CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x800 CONFIG_ENV_SIZE=0x2 CONFIG_ENV_OFFSET=0x0 -CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 CONFIG_DM_GPIO=y CONFIG_SPL_SERIAL_SUPPORT=y CONFIG_SPL=y -CONFIG_SPL_SPI_FLASH_SUPPORT=y -CONFIG_SPL_SPI_SUPPORT=y CONFIG_SPL_TEXT_BASE=0x8000 CONFIG_SYS_EXTRA_OPTIONS="MAC_ADDR_IN_SPIFLASH" CONFIG_BOOTDELAY=3 @@ -27,7 +24,6 @@ CONFIG_SPL_SYS_MALLOC_SIMPLE=y CONFIG_SPL_SEPARATE_BSS=y # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set CONFIG_SPL_NAND_SUPPORT=y -CONFIG_SPL_SPI_LOAD=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="U-Boot > " CONFIG_CRC32_VERIFY=y -- 2.25.1
RE: [PATCH 24/30] arm: imx: Finish migration of CONFIG_CSF_SIZE to Kconfig
Hi Tom,
> -Original Message-
> From: Tom Rini
> Sent: 2020年6月11日 20:12
> To: Ye Li
> Cc: u-boot@lists.denx.de; Stefano Babic ; Fabio Estevam
> ; dl-uboot-imx
> Subject: Re: [EXT] [PATCH 24/30] arm: imx: Finish migration of
> CONFIG_CSF_SIZE to Kconfig
>
> On Thu, Jun 11, 2020 at 05:28:45AM +, Ye Li wrote:
> > Hi Tom,
> >
> > > -Original Message-
> > > From: Tom Rini
> > > Sent: 2020年6月11日 4:16
> > > To: u-boot@lists.denx.de
> > > Cc: Stefano Babic ; Fabio Estevam
> > > ; dl-uboot-imx
> > > Subject: [EXT] [PATCH 24/30] arm: imx: Finish migration of
> > > CONFIG_CSF_SIZE to Kconfig
> > >
> > > Caution: EXT Email
> > >
> > > While the normal case of CSF_SIZE is handled via Kconfig we have
> > > entries in config headers related to CONFIG_SECURE_BOOT. However in
> > > commit d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with
> > > CONFIG_IMX_HAB") this was renamed to CONFIG_IMX_HAB. Update
> the
> > > CSF_SIZE entry to have the correct default value if we have IMX_HAB
> > > enabled.
> > >
> > > Cc: Stefano Babic
> > > Cc: Fabio Estevam
> > > Cc: NXP i.MX U-Boot Team
> > > Fixes: d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with
> > > CONFIG_IMX_HAB")
> > > Signed-off-by: Tom Rini
> > > ---
> > > arch/arm/mach-imx/Kconfig | 1 +
> > > include/configs/imx8mm_beacon.h | 4
> > > include/configs/imx8mm_evk.h| 4
> > > include/configs/imx8mn_evk.h| 4
> > > include/configs/imx8mp_evk.h| 4
> > > include/configs/verdin-imx8mm.h | 4
> > > 6 files changed, 1 insertion(+), 20 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> > > index
> > > 6c3fedf665d6..0648c2725bf8 100644
> > > --- a/arch/arm/mach-imx/Kconfig
> > > +++ b/arch/arm/mach-imx/Kconfig
> > > @@ -52,6 +52,7 @@ config IMX_HAB
> > >
> > > config CSF_SIZE
> > > hex "Maximum size for Command Sequence File (CSF) binary"
> > > + default 0x2000 if IMX_HAB
> > I suggest using "default 0x2000 if ARCH_IMX8M", because i.MX6/7 may also
> enable IMX_HAB.
>
> So ARCH_IMX8M && IMX_HAB? I would have expected the CSF size to be
> limited in all cases from the default value due to something security related
> eating up that 0x60 in overhead. Is that not the case? Thanks!
No, it is related to implementation on iMX8M. You don't need to add "&&
IMX_HAB".
But you could add 'depend on IMX_HAB' for the CSF_SIZE config. Because this
config is
only used when IMX_HAB is enabled.
This 0x60 overhead is actually for dek blob used by encrypted boot. While using
fit
on iMX8M, we will move this dek blob into fit as a standalone image, so it does
not
occupy extra space in CSF.
Best regards,
Ye Li
>
> --
> Tom
Re: [PATCH v2] Fix MMC access on Sabrelite
[Adding Stefano] On Thu, Jun 11, 2020 at 2:54 PM Martyn Welch wrote: > > It appears that MMC access on the Sabrelite has been broken since > cdcaee9518: > > Loading Environment from MMC... Card did not respond to voltage select! > *** Warning - No block device, using default environment > > Remove the board_mmc_init() and related entries now that we should be > using DM_MMC, add PINCTRL so that things work as expected. > > Signed-off-by: Martyn Welch Reviewed-by: Fabio Estevam
Re: [PATCH v2] Fix MMC access on Sabrelite
On 6/12/20 2:53 AM, Martyn Welch wrote:
> It appears that MMC access on the Sabrelite has been broken since
> cdcaee9518:
>
> Loading Environment from MMC... Card did not respond to voltage select!
> *** Warning - No block device, using default environment
>
> Remove the board_mmc_init() and related entries now that we should be
> using DM_MMC, add PINCTRL so that things work as expected.
>
> Signed-off-by: Martyn Welch
Reviewed-by: Jaehoon Chung
> ---
>
> Changes in v2:
> - Removed now redundant mmc header.
>
> board/boundary/nitrogen6x/nitrogen6x.c | 72 --
> configs/mx6qsabrelite_defconfig| 3 ++
> 2 files changed, 3 insertions(+), 72 deletions(-)
>
> diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
> b/board/boundary/nitrogen6x/nitrogen6x.c
> index d49725daa8..b3b121bad8 100644
> --- a/board/boundary/nitrogen6x/nitrogen6x.c
> +++ b/board/boundary/nitrogen6x/nitrogen6x.c
> @@ -25,7 +25,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -161,26 +160,6 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
> IOMUX_PAD_CTRL(SD2_DAT3__SD2_DATA3, USDHC_PAD_CTRL),
> };
>
> -static iomux_v3_cfg_t const usdhc3_pads[] = {
> - IOMUX_PAD_CTRL(SD3_CLK__SD3_CLK, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_CMD__SD3_CMD, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT0__SD3_DATA0, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT1__SD3_DATA1, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT2__SD3_DATA2, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT3__SD3_DATA3, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD3_DAT5__GPIO7_IO00, NO_PAD_CTRL), /* CD */
> -};
> -
> -static iomux_v3_cfg_t const usdhc4_pads[] = {
> - IOMUX_PAD_CTRL(SD4_CLK__SD4_CLK, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_CMD__SD4_CMD, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT0__SD4_DATA0, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT1__SD4_DATA1, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT2__SD4_DATA2, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(SD4_DAT3__SD4_DATA3, USDHC_PAD_CTRL),
> - IOMUX_PAD_CTRL(NANDF_D6__GPIO2_IO06, NO_PAD_CTRL), /* CD */
> -};
> -
> static iomux_v3_cfg_t const enet_pads1[] = {
> IOMUX_PAD_CTRL(ENET_MDIO__ENET_MDIO, ENET_PAD_CTRL),
> IOMUX_PAD_CTRL(ENET_MDC__ENET_MDC, ENET_PAD_CTRL),
> @@ -305,57 +284,6 @@ int board_ehci_power(int port, int on)
>
> #endif
>
> -#ifdef CONFIG_FSL_ESDHC_IMX
> -static struct fsl_esdhc_cfg usdhc_cfg[2] = {
> - {USDHC3_BASE_ADDR},
> - {USDHC4_BASE_ADDR},
> -};
> -
> -int board_mmc_getcd(struct mmc *mmc)
> -{
> - struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
> - int gp_cd = (cfg->esdhc_base == USDHC3_BASE_ADDR) ? IMX_GPIO_NR(7, 0) :
> - IMX_GPIO_NR(2, 6);
> -
> - gpio_direction_input(gp_cd);
> - return !gpio_get_value(gp_cd);
> -}
> -
> -int board_mmc_init(bd_t *bis)
> -{
> - int ret;
> - u32 index = 0;
> -
> - usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
> - usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK);
> -
> - usdhc_cfg[0].max_bus_width = 4;
> - usdhc_cfg[1].max_bus_width = 4;
> -
> - for (index = 0; index < CONFIG_SYS_FSL_USDHC_NUM; ++index) {
> - switch (index) {
> - case 0:
> - SETUP_IOMUX_PADS(usdhc3_pads);
> - break;
> - case 1:
> -SETUP_IOMUX_PADS(usdhc4_pads);
> -break;
> - default:
> -printf("Warning: you configured more USDHC controllers"
> -"(%d) then supported by the board (%d)\n",
> -index + 1, CONFIG_SYS_FSL_USDHC_NUM);
> -return -EINVAL;
> - }
> -
> - ret = fsl_esdhc_initialize(bis, _cfg[index]);
> - if (ret)
> - return ret;
> - }
> -
> - return 0;
> -}
> -#endif
> -
> #ifdef CONFIG_MXC_SPI
> int board_spi_cs_gpio(unsigned bus, unsigned cs)
> {
> diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
> index ea338c1b53..39b0ef7a42 100644
> --- a/configs/mx6qsabrelite_defconfig
> +++ b/configs/mx6qsabrelite_defconfig
> @@ -28,6 +28,7 @@ CONFIG_CMD_GPT=y
> # CONFIG_RANDOM_UUID is not set
> CONFIG_CMD_I2C=y
> CONFIG_CMD_MMC=y
> +# CONFIG_CMD_PINMUX is not set
> CONFIG_CMD_SATA=y
> CONFIG_CMD_USB=y
> CONFIG_CMD_USB_MASS_STORAGE=y
> @@ -55,6 +56,8 @@ CONFIG_PHYLIB=y
> CONFIG_PHY_MICREL=y
> CONFIG_PHY_MICREL_KSZ90X1=y
> CONFIG_MII=y
> +CONFIG_PINCTRL=y
> +CONFIG_PINCTRL_IMX6=y
> CONFIG_SPI=y
> CONFIG_DM_SPI=y
> CONFIG_MXC_SPI=y
>
Re: [PATCH v2 2/3] riscv: Expand the DT size before copy reserved memory node
On Fri, Jun 12, 2020 at 3:18 AM Atish Patra wrote: > > On Wed, Jun 10, 2020 at 2:05 AM Bin Meng wrote: > > > > Hi Atish, > > > > On Wed, Jun 3, 2020 at 2:23 AM Atish Patra wrote: > > > > > > On Thu, May 28, 2020 at 1:47 AM Bin Meng wrote: > > > > > > > > From: Bin Meng > > > > > > > > The FDT blob might not have sufficient space to hold a copy of > > > > reserved memory node. Expand it before the copy. > > > > > > > > Reported-by: Rick Chen > > > > Signed-off-by: Bin Meng > > > > --- > > > > > > > > arch/riscv/lib/fdt_fixup.c | 6 ++ > > > > 1 file changed, 6 insertions(+) > > > > > > > > diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c > > > > index 5f523f0..1290a64 100644 > > > > --- a/arch/riscv/lib/fdt_fixup.c > > > > +++ b/arch/riscv/lib/fdt_fixup.c > > > > @@ -41,6 +41,12 @@ int riscv_fdt_copy_resv_mem_node(const void *src, > > > > void *dst) > > > > return 0; > > > > } > > > > > > > > + err = fdt_open_into(dst, dst, fdt_totalsize(dst) + 32); > > > > > > The size may be bigger than 32 bytes in future given that we may have > > > multiple reserved pmp regions. > > > How about calculating the size from the source and using that instead > > > of a fixed size ? > > > > > > > This looks way too complicated. That means the codes here need to > > understand the FDT blob binary representation to know exactly how much > > additional size is needed. By looking at existing calls to > > fdt_open_into() none of these do such things. > > > > I guess we will have to give an estimated size to fit all possible > > situations. Say there are 16 PMP regions, and one occupies 64 bytes, > > so we can extend the FDT by 64 * 16 = 1024 bytes. Thoughts ?? > > > > That works too. I see we only allocate 256 bytes in OpenSBI. > Can you send a patch to OpenSBI as well with the above reasoning ? > Sure, will do. Regards, Bin
Re: [PATCH u-boot 4/4] eth/r8152: support RTL8153B/RTL8154B
On 6/11/20 5:18 AM, Hayes Wang wrote: > Marek Vasut [mailto:ma...@denx.de] >> Sent: Wednesday, June 10, 2020 9:21 PM > [...] >>> + /* ADC Bias Calibration: >>> +* read efuse offset 0x7d to get a 17-bit data. Remove the dummy/fake >>> +* bit (bit3) to rebuild the real 16-bit data. Write the data >>> to the >>> +* ADC ioffset. >>> +*/ >>> + ocp_data = r8152_efuse_read(tp, 0x7d); >>> + data = (u16)(((ocp_data & 0x1fff0) >> 1) | (ocp_data & 0x7)); >> >> Are these type casts really needed ? > > Is there not a warning from u32 to u16? There is, but it seems justified to warn about conversion from u32 to u16, so maybe that needs to be fixed ? >>> >>> Excuse me. I don't understand what you mean. >>> The original is 17-bit data, so I use u32 to store it. And, >>> the final desired data is 16-bit. That is why >>> I have to convert it from u32 to u16. >> >> So what happens to that bit 17 , is it dropped ? > > I have descripted is in the code, such as following. > > /* ADC Bias Calibration: >* read efuse offset 0x7d to get a 17-bit data. Remove the dummy/fake >* bit (bit3) to rebuild the real 16-bit data. Write the data to the >* ADC ioffset. >*/ > > The real data (16-bit) would be inserted a dummy bit, > and store the 17-bit to efuse offset 0x7d. Therefore, when > reading the 17-bit data from efuse, we have to remove the > dummy to get the real data. Ah, hmm, then let's use u32 type and be done with it. That solves the typecasts and is safe. Would that work ?
Re: [EXT] [PATCH 24/30] arm: imx: Finish migration of CONFIG_CSF_SIZE to Kconfig
On Thu, Jun 11, 2020 at 08:11:57AM -0400, Tom Rini wrote:
> On Thu, Jun 11, 2020 at 05:28:45AM +, Ye Li wrote:
> > Hi Tom,
> >
> > > -Original Message-
> > > From: Tom Rini
> > > Sent: 2020年6月11日 4:16
> > > To: u-boot@lists.denx.de
> > > Cc: Stefano Babic ; Fabio Estevam
> > > ; dl-uboot-imx
> > > Subject: [EXT] [PATCH 24/30] arm: imx: Finish migration of CONFIG_CSF_SIZE
> > > to Kconfig
> > >
> > > Caution: EXT Email
> > >
> > > While the normal case of CSF_SIZE is handled via Kconfig we have entries
> > > in
> > > config headers related to CONFIG_SECURE_BOOT. However in commit
> > > d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with
> > > CONFIG_IMX_HAB") this was renamed to CONFIG_IMX_HAB. Update the
> > > CSF_SIZE entry to have the correct default value if we have IMX_HAB
> > > enabled.
> > >
> > > Cc: Stefano Babic
> > > Cc: Fabio Estevam
> > > Cc: NXP i.MX U-Boot Team
> > > Fixes: d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with
> > > CONFIG_IMX_HAB")
> > > Signed-off-by: Tom Rini
> > > ---
> > > arch/arm/mach-imx/Kconfig | 1 +
> > > include/configs/imx8mm_beacon.h | 4
> > > include/configs/imx8mm_evk.h| 4
> > > include/configs/imx8mn_evk.h| 4
> > > include/configs/imx8mp_evk.h| 4
> > > include/configs/verdin-imx8mm.h | 4
> > > 6 files changed, 1 insertion(+), 20 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index
> > > 6c3fedf665d6..0648c2725bf8 100644
> > > --- a/arch/arm/mach-imx/Kconfig
> > > +++ b/arch/arm/mach-imx/Kconfig
> > > @@ -52,6 +52,7 @@ config IMX_HAB
> > >
> > > config CSF_SIZE
> > > hex "Maximum size for Command Sequence File (CSF) binary"
> > > + default 0x2000 if IMX_HAB
> > I suggest using "default 0x2000 if ARCH_IMX8M", because i.MX6/7 may also
> > enable IMX_HAB.
>
> So ARCH_IMX8M && IMX_HAB? I would have expected the CSF size to be
> limited in all cases from the default value due to something security
> related eating up that 0x60 in overhead. Is that not the case? Thanks!
Ah, looking at the actual usage now, I get it. I'll make a v2 that has
the right ddefault for ARCH_IMX8M and make CSF_SIZE itself depend on
IMX_HAB.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 25/30] arm: imx: Finish migration from CONFIG_SECURE_BOOT to CONFIG_IMX_HAB
On Fri, Jun 12, 2020 at 12:02:24AM +0300, Vladimir Oltean wrote:
> On Thu, 11 Jun 2020 at 23:30, Tom Rini wrote:
> >
> > On Thu, Jun 11, 2020 at 10:31:32PM +0300, Vladimir Oltean wrote:
> > > Hi Tom,
> > >
> > > On Wed, 10 Jun 2020 at 23:17, Tom Rini wrote:
> > > >
> > > > There are a few remaining places where we say CONFIG_SECURE_BOOT rather
> > > > than CONFIG_IMX HAB. Update these instances.
> > > >
> > > > Cc: Stefano Babic
> > > > Cc: Fabio Estevam
> > > > Cc: NXP i.MX U-Boot Team
> > > > Cc: Eddy Petrișor
> > > > Cc: Shawn Guo
> > > > Cc: Vladimir Oltean
> > > > Cc: Priyanka Jain
> > > > Fixes: d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with
> > > > CONFIG_IMX_HAB")
> > > > Signed-off-by: Tom Rini
> > > > ---
> > > > Note that we have one place left for CONFIG_SECURE_BOOT being in use but
> > > > I think that is shared with PowerPC so I don't think IMX_HAB is the
> > > > right name. But perhaps I'm wrong about it being used for PowerPC?
> > >
> > > NACK on this patch.
> >
> > Note that today CONFIG_SECURE_BOOT is not defined anywhere and the
> > commit you mention next replaced the only places that set
> > CONFIG_SECURE_BOOT with CONFIG_IMX_HAB.
> >
>
> Actually looks like the ls1021atsn_sdcard_SECURE_BOOT_defconfig that
> defined it (via CONFIG_SYS_EXTRA_OPTIONS) hasn't made it upstream yet,
> so it's a bit unfair to say it, but things under CONFIG_SECURE_BOOT
> are not dead code as you want to imply.
Ah, sorry, I was trying to fix inadvertently broken code.
> > > I'm not actually sure what were the cross-architecture problems with
> > > the CONFIG_SECURE_BOOT name that mandated Stefano to write this patch:
> > >
> > > commit d714a75fd4dcfb0eb8b7e1dd29f43e07113cec0b
> > > Author: Stefano Babic
> > > Date: Fri Sep 20 08:47:53 2019 +0200
> > >
> > > imx: replace CONFIG_SECURE_BOOT with CONFIG_IMX_HAB
> > >
> > > CONFIG_SECURE_BOOT is too generic and forbids to use it for cross
> > > architecture purposes. If Secure Boot is required for imx, this means
> > > to
> > > enable and use the HAB processor in the soc.
> > >
> > > Signed-off-by: Stefano Babic
> >
> > The problem is that SECURE_BOOT is very generic. We have quite a few
> > different "secure boot" implementations in the tree and another pointed
> > out what a bad name this one is. And just to be clear, I'm the only one
> > (intentionally) touching non-i.MX spots here.
> >
>
> Ok, agree that it's a bad name for something that lives under
> board/freescale/.
>
> > > but going the full way and grouping Layerscape, QorIQ and S32V secure
> > > boot implementations together with a boot ROM feature available only
> > > on i.MX 50, 53, 6, 7, 8M and 8MM is demonstrably incorrect.
> >
> > OK. I (and others on the thread at the time) were asking for someone to
> > group things right and provide a new symbol. What's in there is what we
> > got, but more details are always better as there were a few cases that
> > didn't get updated.
> >
> > > I think the correct solution (beside leaving the CONFIG_SECURE_BOOT
> > > name alone) would be to merge it, for the Layerscape (ls*) and PowerPC
> > > instances, with CONFIG_CHAIN_OF_TRUST (defined under
> > > board/freescale/common/Kconfig). But you or Stefano might argue that
> > > CHAIN_OF_TRUST is still too generic for a name, and in that case,
> > > maybe the whole thing can be renamed to CONFIG_FSL_ESBC (ESBC ==
> > > "External Secure Boot Code", aka image validation code executed by the
> > > bootloader as opposed to the [internal] boot ROM).
> >
> > So for this patch here it's a few instances of CONFIG_CSF_SIZE on i.MX
> > files, a change to S32V that looks quite a lot like i.MX (the file notes
> > as much) and a layerscape change to CONFIG_U_BOOT_HDR_SIZE. I'm quite
> > happy to spin v2 dropping the layerscape part out and waiting to see
> > what Eddy says for S32V. We have a CONFIG_NXP_ESBC symbol today, would
> > that make sense to use in the check on include/configs/ls1021atsn.h and
> > top-level Makefile for not making u-boot.pbl sometimes? Thanks again!
> >
>
> Yes, yes, for ls1021atsn.h and for the top-level Makefile,
> CONFIG_NXP_ESBC is exactly what is needed! For the top-level Makefile
> in particular, I believe it was missed during this conversion:
>
> commit 5536c3c9d0d10c1a4e440e71eac389df3a3dbfa7
> Author: Udit Agarwal
> Date: Thu Nov 7 16:11:32 2019 +
>
> freescale/layerscape: Rename the config CONFIG_SECURE_BOOT name
>
> Rename CONFIG_SECURE_BOOT to CONFIG_NXP_ESBC to avoid conflict
> with UEFI secure boot.
>
> Signed-off-by: Udit Agarwal
> Signed-off-by: Priyanka Jain
>
> I'm not sure how I missed it during my previous reply.
Ah-ha! I'll catch this in v2, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH 25/30] arm: imx: Finish migration from CONFIG_SECURE_BOOT to CONFIG_IMX_HAB
On Thu, 11 Jun 2020 at 23:30, Tom Rini wrote:
>
> On Thu, Jun 11, 2020 at 10:31:32PM +0300, Vladimir Oltean wrote:
> > Hi Tom,
> >
> > On Wed, 10 Jun 2020 at 23:17, Tom Rini wrote:
> > >
> > > There are a few remaining places where we say CONFIG_SECURE_BOOT rather
> > > than CONFIG_IMX HAB. Update these instances.
> > >
> > > Cc: Stefano Babic
> > > Cc: Fabio Estevam
> > > Cc: NXP i.MX U-Boot Team
> > > Cc: Eddy Petrișor
> > > Cc: Shawn Guo
> > > Cc: Vladimir Oltean
> > > Cc: Priyanka Jain
> > > Fixes: d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with
> > > CONFIG_IMX_HAB")
> > > Signed-off-by: Tom Rini
> > > ---
> > > Note that we have one place left for CONFIG_SECURE_BOOT being in use but
> > > I think that is shared with PowerPC so I don't think IMX_HAB is the
> > > right name. But perhaps I'm wrong about it being used for PowerPC?
> >
> > NACK on this patch.
>
> Note that today CONFIG_SECURE_BOOT is not defined anywhere and the
> commit you mention next replaced the only places that set
> CONFIG_SECURE_BOOT with CONFIG_IMX_HAB.
>
Actually looks like the ls1021atsn_sdcard_SECURE_BOOT_defconfig that
defined it (via CONFIG_SYS_EXTRA_OPTIONS) hasn't made it upstream yet,
so it's a bit unfair to say it, but things under CONFIG_SECURE_BOOT
are not dead code as you want to imply.
> > I'm not actually sure what were the cross-architecture problems with
> > the CONFIG_SECURE_BOOT name that mandated Stefano to write this patch:
> >
> > commit d714a75fd4dcfb0eb8b7e1dd29f43e07113cec0b
> > Author: Stefano Babic
> > Date: Fri Sep 20 08:47:53 2019 +0200
> >
> > imx: replace CONFIG_SECURE_BOOT with CONFIG_IMX_HAB
> >
> > CONFIG_SECURE_BOOT is too generic and forbids to use it for cross
> > architecture purposes. If Secure Boot is required for imx, this means to
> > enable and use the HAB processor in the soc.
> >
> > Signed-off-by: Stefano Babic
>
> The problem is that SECURE_BOOT is very generic. We have quite a few
> different "secure boot" implementations in the tree and another pointed
> out what a bad name this one is. And just to be clear, I'm the only one
> (intentionally) touching non-i.MX spots here.
>
Ok, agree that it's a bad name for something that lives under board/freescale/.
> > but going the full way and grouping Layerscape, QorIQ and S32V secure
> > boot implementations together with a boot ROM feature available only
> > on i.MX 50, 53, 6, 7, 8M and 8MM is demonstrably incorrect.
>
> OK. I (and others on the thread at the time) were asking for someone to
> group things right and provide a new symbol. What's in there is what we
> got, but more details are always better as there were a few cases that
> didn't get updated.
>
> > I think the correct solution (beside leaving the CONFIG_SECURE_BOOT
> > name alone) would be to merge it, for the Layerscape (ls*) and PowerPC
> > instances, with CONFIG_CHAIN_OF_TRUST (defined under
> > board/freescale/common/Kconfig). But you or Stefano might argue that
> > CHAIN_OF_TRUST is still too generic for a name, and in that case,
> > maybe the whole thing can be renamed to CONFIG_FSL_ESBC (ESBC ==
> > "External Secure Boot Code", aka image validation code executed by the
> > bootloader as opposed to the [internal] boot ROM).
>
> So for this patch here it's a few instances of CONFIG_CSF_SIZE on i.MX
> files, a change to S32V that looks quite a lot like i.MX (the file notes
> as much) and a layerscape change to CONFIG_U_BOOT_HDR_SIZE. I'm quite
> happy to spin v2 dropping the layerscape part out and waiting to see
> what Eddy says for S32V. We have a CONFIG_NXP_ESBC symbol today, would
> that make sense to use in the check on include/configs/ls1021atsn.h and
> top-level Makefile for not making u-boot.pbl sometimes? Thanks again!
>
Yes, yes, for ls1021atsn.h and for the top-level Makefile,
CONFIG_NXP_ESBC is exactly what is needed! For the top-level Makefile
in particular, I believe it was missed during this conversion:
commit 5536c3c9d0d10c1a4e440e71eac389df3a3dbfa7
Author: Udit Agarwal
Date: Thu Nov 7 16:11:32 2019 +
freescale/layerscape: Rename the config CONFIG_SECURE_BOOT name
Rename CONFIG_SECURE_BOOT to CONFIG_NXP_ESBC to avoid conflict
with UEFI secure boot.
Signed-off-by: Udit Agarwal
Signed-off-by: Priyanka Jain
I'm not sure how I missed it during my previous reply.
> --
> Tom
Thanks,
-Vladimir
Re: [PATCH 25/30] arm: imx: Finish migration from CONFIG_SECURE_BOOT to CONFIG_IMX_HAB
On Thu, Jun 11, 2020 at 10:31:32PM +0300, Vladimir Oltean wrote:
> Hi Tom,
>
> On Wed, 10 Jun 2020 at 23:17, Tom Rini wrote:
> >
> > There are a few remaining places where we say CONFIG_SECURE_BOOT rather
> > than CONFIG_IMX HAB. Update these instances.
> >
> > Cc: Stefano Babic
> > Cc: Fabio Estevam
> > Cc: NXP i.MX U-Boot Team
> > Cc: Eddy Petrișor
> > Cc: Shawn Guo
> > Cc: Vladimir Oltean
> > Cc: Priyanka Jain
> > Fixes: d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with CONFIG_IMX_HAB")
> > Signed-off-by: Tom Rini
> > ---
> > Note that we have one place left for CONFIG_SECURE_BOOT being in use but
> > I think that is shared with PowerPC so I don't think IMX_HAB is the
> > right name. But perhaps I'm wrong about it being used for PowerPC?
>
> NACK on this patch.
Note that today CONFIG_SECURE_BOOT is not defined anywhere and the
commit you mention next replaced the only places that set
CONFIG_SECURE_BOOT with CONFIG_IMX_HAB.
> I'm not actually sure what were the cross-architecture problems with
> the CONFIG_SECURE_BOOT name that mandated Stefano to write this patch:
>
> commit d714a75fd4dcfb0eb8b7e1dd29f43e07113cec0b
> Author: Stefano Babic
> Date: Fri Sep 20 08:47:53 2019 +0200
>
> imx: replace CONFIG_SECURE_BOOT with CONFIG_IMX_HAB
>
> CONFIG_SECURE_BOOT is too generic and forbids to use it for cross
> architecture purposes. If Secure Boot is required for imx, this means to
> enable and use the HAB processor in the soc.
>
> Signed-off-by: Stefano Babic
The problem is that SECURE_BOOT is very generic. We have quite a few
different "secure boot" implementations in the tree and another pointed
out what a bad name this one is. And just to be clear, I'm the only one
(intentionally) touching non-i.MX spots here.
> but going the full way and grouping Layerscape, QorIQ and S32V secure
> boot implementations together with a boot ROM feature available only
> on i.MX 50, 53, 6, 7, 8M and 8MM is demonstrably incorrect.
OK. I (and others on the thread at the time) were asking for someone to
group things right and provide a new symbol. What's in there is what we
got, but more details are always better as there were a few cases that
didn't get updated.
> I think the correct solution (beside leaving the CONFIG_SECURE_BOOT
> name alone) would be to merge it, for the Layerscape (ls*) and PowerPC
> instances, with CONFIG_CHAIN_OF_TRUST (defined under
> board/freescale/common/Kconfig). But you or Stefano might argue that
> CHAIN_OF_TRUST is still too generic for a name, and in that case,
> maybe the whole thing can be renamed to CONFIG_FSL_ESBC (ESBC ==
> "External Secure Boot Code", aka image validation code executed by the
> bootloader as opposed to the [internal] boot ROM).
So for this patch here it's a few instances of CONFIG_CSF_SIZE on i.MX
files, a change to S32V that looks quite a lot like i.MX (the file notes
as much) and a layerscape change to CONFIG_U_BOOT_HDR_SIZE. I'm quite
happy to spin v2 dropping the layerscape part out and waiting to see
what Eddy says for S32V. We have a CONFIG_NXP_ESBC symbol today, would
that make sense to use in the check on include/configs/ls1021atsn.h and
top-level Makefile for not making u-boot.pbl sometimes? Thanks again!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH] image: Add support for ZSTD decompression
On Wed, Jun 10, 2020 at 11:13:37AM +0200, Rasmus Villemoes wrote:
> On 08/06/2020 21.01, Robert Marko wrote:
> > On Wed, May 20, 2020 at 2:35 PM Tom Rini wrote:
> >>
> >> On Wed, May 20, 2020 at 01:38:01PM +0200, Robert Marko wrote:
> >>
> >>> Tom,
> >>> I have tried various things but CONFIG_IS_ENABLED won't work inside of
> >>> switch case.
> >>> It works fine outside of if though.
> >>
> >> OK, thanks, I'll poke things more to make sure what I'm worried about
> >> doesn't happen.
> >
> > Hi,
> > were you able to test the commit?
>
> So I took a look at this since I'm also interested in getting zstd
> support in. And the problem is that when building host tools, the
> IS_ENABLED / CONFIG_IS_ENABLED logic doesn't make much sense anyway -
> one can of course include the kconfig.h header that defines those macros
> to avoid the cpp error (one has to be careful, because the headers
> included vary wildly depending on USE_HOSTCC), but I don't think it's
> meaningful - the host tools should not depend on configuration for any
> specific board.
>
> Nor do they currently; the use of ifdef CONFIG_GZIP for example just
> means that that part is ignored for the host tools - doing
>
> --- a/common/image.c
> +++ b/common/image.c
> @@ -430,12 +430,12 @@ int image_decomp(int comp, ulong load, ulong
> image_start, int type,
> else
> ret = -ENOSPC;
> break;
> -#ifdef CONFIG_GZIP
> +//#ifdef CONFIG_GZIP
> case IH_COMP_GZIP: {
> ret = gunzip(load_buf, unc_len, image_buf, _len);
> break;
> }
> -#endif /* CONFIG_GZIP */
> +//#endif /* CONFIG_GZIP */
> #ifdef CONFIG_BZIP2
> case IH_COMP_BZIP2: {
> uint size = unc_len;
>
> should be a no-op when CONFIG_GZIP=y, but it breaks the build of the
> host tools.
>
> That, in turn, means that the fit_check_sign tool (which AFAICT is the
> only host tool that actually care about this - we really should build
> host tools with the
> -ffunction-sections,-fdata-sections,-Wl,--gc-sections flags) currently
> "works" in the sense that it does check the signature, but it doesn't
> really check if the image(s) can be decompressed using the vendored copy
> of the decompression code; hidden in the output is
>
> Unimplemented compression type 5
>
> but for some reason that ends up being ok.
>
> So, for now, I suggest simply surrounding all the CASE_IH_COMP_* (except
> NONE) by a #ifndef USE_HOSTCC - I don't think that will change anything
> at all for the existing host tools. Then you should be able to use the
> proper CONFIG_IS_ENABLED(ZSTD) to guard the IH_COMP_ZSTD case. Also, it
> would allow us to change the existing bare ifdefs to be SPL-aware, i.e.
> change #ifdef CONFIG_GZIP to #if CONFIG_IS_ENABLED(GZIP) [assuming the
> SPL_GZIP symbol actually exists].
Alright, so first thanks for digging here. Looking over the tools, for
verifying the signature we don't need to decompress the contents as we
are just checking the signature. For dumpimage it's also OK to dump a
compressed file and leave it to regular tools to decompress. Do you
want to make a patch to guard the existing section and CONFIG_IS_ENABLED
it or should I and Suggested-by you? Thanks!
--
Tom
signature.asc
Description: PGP signature
[PATCH v3 5/6] sandbox: Enable memio operations in board_init
initr_dm_devices() is called somewhere after board_init(). It can be used by drivers to initialize devices to some default bootup state. Those devices might use mmio read/write operations to perform the initialization. One such example is the mux devices. The mux framework initializes the muxes to their default state after idle state in mux_uclass_post_probe(). One type of mux controller is the MMIO mux controller. Initializing a MMIO mux to idle state can require a mmio read and write operation. With memio disabled, the reads return 0 and the writes go off into the void. This makes it impossible to initialize muxes to their idle state on boot, and consequentially makes it impossible to test that in sandbox. These same initializations work fine on actual hardware (tested on TI J721E EVM). So, enable memio operations on boot so devices like mux can perform whatever initialization they need. state_reset_for_test() will disable it before running tests so tests still need to enable memio manually. Signed-off-by: Pratyush Yadav --- board/sandbox/sandbox.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/board/sandbox/sandbox.c b/board/sandbox/sandbox.c index 1372003018..d7eb207822 100644 --- a/board/sandbox/sandbox.c +++ b/board/sandbox/sandbox.c @@ -55,6 +55,8 @@ int board_init(void) if (IS_ENABLED(CONFIG_LED)) led_default_state(); + sandbox_set_enable_memio(true); + return 0; } -- 2.27.0
[PATCH v3 6/6] test: Add tests for the multiplexer framework
From: Jean-Jacques Hiblot
Provide tests to check the behavior of the multiplexer framework.
The test uses a mmio-based multiplexer.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Simon Glass
Signed-off-by: Pratyush Yadav
---
arch/sandbox/dts/test.dts | 25 ++
configs/sandbox_defconfig | 2 +
test/dm/Makefile | 1 +
test/dm/mux-mmio.c| 168 ++
4 files changed, 196 insertions(+)
create mode 100644 test/dm/mux-mmio.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index e8701d2603..750779d20f 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -2,6 +2,7 @@
#include
#include
+#include
/ {
model = "sandbox";
@@ -115,6 +116,11 @@
int64-value = /bits/ 64 <0x>;
int-array = <5678 9123 4567>;
interrupts-extended = < 3 0>;
+
+ mux-controls = < 0>, < 1>,
+ < 2>, < 3>;
+ mux-control-names = "mux0", "mux1", "mux2", "mux3";
+ mux-syscon = <>;
};
another-test {
@@ -158,6 +164,9 @@
compatible = "denx,u-boot-fdt-test";
ping-expect = <3>;
ping-add = <3>;
+
+ mux-controls = < 0>;
+ mux-control-names = "mux0";
};
phy_provider0: gen_phy@0 {
@@ -787,6 +796,22 @@
0x58 8>;
};
+ syscon3: syscon@3 {
+ compatible = "simple-mfd", "syscon";
+ reg = <0x000100 0x10>;
+
+ muxcontroller0: a-mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+
+ mux-reg-masks = <0x0 0x30>, /* 0: reg 0x0, bits 5:4 */
+ <0xc 0x1E>, /* 1: reg 0xc, bits 4:1 */
+ <0x4 0xFF>; /* 2: reg 0x4, bits 7:0 */
+ idle-states = , <0x02>, <0x73>;
+ u-boot,mux-autoprobe;
+ };
+ };
+
timer {
compatible = "sandbox,timer";
clock-frequency = <100>;
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 5b7569319b..c301d11992 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -154,6 +154,8 @@ CONFIG_SPI_FLASH_SPANSION=y
CONFIG_SPI_FLASH_STMICRO=y
CONFIG_SPI_FLASH_SST=y
CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_MULTIPLEXER=y
+CONFIG_MUX_MMIO=y
CONFIG_DM_ETH=y
CONFIG_NVME=y
CONFIG_PCI=y
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 6c18fd04ce..d7ab7e27f7 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_DM_SPI_FLASH) += sf.o
obj-$(CONFIG_SMEM) += smem.o
obj-$(CONFIG_DM_SPI) += spi.o
obj-y += syscon.o
+obj-$(CONFIG_MUX_MMIO) += mux-mmio.o
obj-$(CONFIG_DM_USB) += usb.o
obj-$(CONFIG_DM_PMIC) += pmic.o
obj-$(CONFIG_DM_REGULATOR) += regulator.o
diff --git a/test/dm/mux-mmio.c b/test/dm/mux-mmio.c
new file mode 100644
index 00..91c383324f
--- /dev/null
+++ b/test/dm/mux-mmio.c
@@ -0,0 +1,168 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Test that mmio mux work correctly */
+static int dm_test_mux_mmio_default_state(struct unit_test_state *uts)
+{
+ struct udevice *dev, *dev_b;
+ struct regmap *map;
+ u32 val;
+
+ sandbox_set_enable_memio(true);
+
+ ut_assertok(uclass_get_device_by_name(UCLASS_TEST_FDT, "a-test",
+ ));
+ ut_assertok(uclass_get_device_by_name(UCLASS_TEST_FDT, "b-test",
+ _b));
+ map = syscon_regmap_lookup_by_phandle(dev, "mux-syscon");
+ ut_assertok_ptr(map);
+ ut_assert(map);
+
+ /* Check default states. */
+ ut_assertok(regmap_read(map, 0xc, ));
+ ut_asserteq(0x02, (val & 0x1E) >> 1);
+ ut_assertok(regmap_read(map, 0x4, ));
+ ut_asserteq(0x73, (val & 0xFF) >> 0);
+
+ return 0;
+}
+DM_TEST(dm_test_mux_mmio_default_state, DM_TESTF_SCAN_PDATA |
DM_TESTF_SCAN_FDT);
+
+static int dm_test_mux_mmio_select(struct unit_test_state *uts)
+{
+ struct udevice *dev, *dev_b;
+ struct regmap *map;
+ struct mux_control *ctl0_a, *ctl0_b;
+ struct mux_control *ctl1;
+ struct mux_control *ctl_err;
+ u32 val;
+ int i;
+
+ sandbox_set_enable_memio(true);
+
+ ut_assertok(uclass_get_device_by_name(UCLASS_TEST_FDT, "a-test",
+ ));
+ ut_assertok(uclass_get_device_by_name(UCLASS_TEST_FDT, "b-test",
+ _b));
+ map =
[PATCH v3 3/6] drivers: mux: mmio-based syscon mux controller
From: Jean-Jacques Hiblot
This adds a driver for mmio-based syscon multiplexers controlled by
bitfields in a syscon register range.
This is heavily based on the linux mmio-mux driver.
Signed-off-by: Jean-Jacques Hiblot
Reviewed-by: Simon Glass
Signed-off-by: Pratyush Yadav
---
drivers/mux/Kconfig | 14 +
drivers/mux/Makefile | 1 +
drivers/mux/mmio.c | 143 +++
3 files changed, 158 insertions(+)
create mode 100644 drivers/mux/mmio.c
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
index 35c1c5673c..f15ee4f833 100644
--- a/drivers/mux/Kconfig
+++ b/drivers/mux/Kconfig
@@ -8,4 +8,18 @@ config MULTIPLEXER
controllers. It provides the same API as Linux and mux drivers should
be portable with a minimum effort.
+if MULTIPLEXER
+
+config MUX_MMIO
+ bool "MMIO register bitfield-controlled Multiplexer"
+ depends on MULTIPLEXER && SYSCON
+ help
+ MMIO register bitfield-controlled Multiplexer controller.
+
+ The driver builds multiplexer controllers for bitfields in a syscon
+ register. For N bit wide bitfields, there will be 2^N possible
+ multiplexer states.
+
+endif
+
endmenu
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
index 351e4363d3..78ebf04c7a 100644
--- a/drivers/mux/Makefile
+++ b/drivers/mux/Makefile
@@ -4,3 +4,4 @@
# Jean-Jacques Hiblot
obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux-uclass.o
+obj-$(CONFIG_$(SPL_)MUX_MMIO) += mmio.o
diff --git a/drivers/mux/mmio.c b/drivers/mux/mmio.c
new file mode 100644
index 00..573e599dd1
--- /dev/null
+++ b/drivers/mux/mmio.c
@@ -0,0 +1,143 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * MMIO register bitfield-controlled multiplexer driver
+ * Based on the linux mmio multiplexer driver
+ *
+ * Copyright (C) 2017 Pengutronix, Philipp Zabel
+ * Copyright (C) 2019 Texas Instrument, Jean-jacques Hiblot
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+static int mux_mmio_set(struct mux_control *mux, int state)
+{
+ struct regmap_field **fields = dev_get_priv(mux->dev);
+
+ return regmap_field_write(fields[mux_control_get_index(mux)], state);
+}
+
+static const struct mux_control_ops mux_mmio_ops = {
+ .set = mux_mmio_set,
+};
+
+static const struct udevice_id mmio_mux_of_match[] = {
+ { .compatible = "mmio-mux" },
+ { /* sentinel */ },
+};
+
+static int mmio_mux_probe(struct udevice *dev)
+{
+ struct regmap_field **fields;
+ struct mux_chip *mux_chip = dev_get_uclass_priv(dev);
+ struct regmap *regmap;
+ u32 *mux_reg_masks;
+ u32 *idle_states;
+ int num_fields;
+ int ret;
+ int i;
+
+ regmap = syscon_node_to_regmap(dev_ofnode(dev->parent));
+ if (IS_ERR(regmap)) {
+ ret = PTR_ERR(regmap);
+ dev_err(dev, "failed to get regmap: %d\n", ret);
+ return ret;
+ }
+
+ num_fields = dev_read_size(dev, "mux-reg-masks");
+ if (num_fields < 0)
+ return log_msg_ret("mux-reg-masks missing or invalid", -EINVAL);
+
+ num_fields /= sizeof(u32);
+ if (num_fields == 0 || num_fields % 2)
+ ret = -EINVAL;
+ num_fields = num_fields / 2;
+
+ ret = mux_alloc_controllers(dev, num_fields);
+ if (ret < 0)
+ return log_msg_ret("failed to allocate mux controllers", ret);
+
+ fields = devm_kmalloc(dev, num_fields * sizeof(*fields), __GFP_ZERO);
+ if (!fields)
+ return -ENOMEM;
+ dev->priv = fields;
+
+ mux_reg_masks = devm_kmalloc(dev, num_fields * 2 * sizeof(u32),
+__GFP_ZERO);
+ if (!mux_reg_masks)
+ return -ENOMEM;
+
+ ret = dev_read_u32_array(dev, "mux-reg-masks", mux_reg_masks,
+num_fields * 2);
+ if (ret < 0)
+ return log_msg_ret("failed to read mux-reg-masks property",
+ ret);
+
+ idle_states = devm_kmalloc(dev, num_fields * sizeof(u32), __GFP_ZERO);
+ if (!idle_states)
+ return -ENOMEM;
+
+ ret = dev_read_u32_array(dev, "idle-states", idle_states, num_fields);
+ if (ret < 0) {
+ log_err("failed to read idle-states property: %d\n", ret);
+ devm_kfree(dev, idle_states);
+ idle_states = NULL;
+ }
+
+ for (i = 0; i < num_fields; i++) {
+ struct mux_control *mux = _chip->mux[i];
+ struct reg_field field;
+ u32 reg, mask;
+ int bits;
+
+ reg = mux_reg_masks[2 * i];
+ mask = mux_reg_masks[2 * i + 1];
+
+ field.reg = reg;
+ field.msb = fls(mask) - 1;
+ field.lsb = ffs(mask) - 1;
+
+ if (mask != GENMASK(field.msb, field.lsb))
+ return
[PATCH v3 2/6] dm: board: complete the initialization of the muxes in initr_dm()
From: Jean-Jacques Hiblot
This will probe the multiplexer devices that have a "u-boot,mux-autoprobe"
property. As a consequence they will be put in their idle state.
Signed-off-by: Jean-Jacques Hiblot
Signed-off-by: Pratyush Yadav
---
common/board_r.c | 12
drivers/mux/mux-uclass.c | 23 +++
include/mux.h| 12
3 files changed, 47 insertions(+)
diff --git a/common/board_r.c b/common/board_r.c
index fa57fa9b69..aa1f98e851 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -46,6 +46,7 @@
#include
#endif
#include
+#include
#include
#include
#include
@@ -334,6 +335,17 @@ static int initr_dm_devices(void)
return ret;
}
+ if (IS_ENABLED(CONFIG_MULTIPLEXER)) {
+ /*
+* Initialize the multiplexer controls to their default state.
+* This must be done early as other drivers may unknowingly
+* rely on it.
+*/
+ ret = dm_mux_init();
+ if (ret)
+ return ret;
+ }
+
return 0;
}
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
index 3c89e0a389..3dad466101 100644
--- a/drivers/mux/mux-uclass.c
+++ b/drivers/mux/mux-uclass.c
@@ -303,6 +303,29 @@ static int mux_uclass_post_probe(struct udevice *dev)
return 0;
}
+int dm_mux_init(void)
+{
+ struct uclass *uc;
+ struct udevice *dev;
+ int ret;
+
+ ret = uclass_get(UCLASS_MUX, );
+ if (ret < 0) {
+ log_debug("unable to get MUX uclass\n");
+ return ret;
+ }
+ uclass_foreach_dev(dev, uc) {
+ if (dev_read_bool(dev, "u-boot,mux-autoprobe")) {
+ ret = device_probe(dev);
+ if (ret)
+ log_debug("unable to probe device %s\n",
+ dev->name);
+ }
+ }
+
+ return 0;
+}
+
UCLASS_DRIVER(mux) = {
.id = UCLASS_MUX,
.name = "mux",
diff --git a/include/mux.h b/include/mux.h
index 85eb7d42fc..23844f480a 100644
--- a/include/mux.h
+++ b/include/mux.h
@@ -109,6 +109,13 @@ void mux_control_put(struct mux_control *mux);
*/
struct mux_control *devm_mux_control_get(struct udevice *dev,
const char *mux_name);
+/**
+ * dm_mux_init() - Initialize the multiplexer controls to their default state.
+ *
+ * Return: 0 if OK, -errno otherwise.
+ */
+int dm_mux_init(void);
+
#else
unsigned int mux_control_states(struct mux_control *mux)
{
@@ -142,6 +149,11 @@ struct mux_control *devm_mux_control_get(struct udevice
*dev,
{
return NULL;
}
+
+int dm_mux_init(void)
+{
+ return -ENOSYS;
+}
#endif
#endif
--
2.27.0
[PATCH v3 1/6] drivers: Add a new framework for multiplexer devices
From: Jean-Jacques Hiblot
Add a new subsystem that handles multiplexer controllers. The API is the
same as in Linux.
Signed-off-by: Jean-Jacques Hiblot
Signed-off-by: Pratyush Yadav
---
drivers/Kconfig | 2 +
drivers/Makefile | 1 +
drivers/mux/Kconfig | 11 ++
drivers/mux/Makefile | 6 +
drivers/mux/mux-uclass.c | 311 ++
include/dm/uclass-id.h| 1 +
include/dt-bindings/mux/mux.h | 17 ++
include/mux-internal.h| 109
include/mux.h | 147
9 files changed, 605 insertions(+)
create mode 100644 drivers/mux/Kconfig
create mode 100644 drivers/mux/Makefile
create mode 100644 drivers/mux/mux-uclass.c
create mode 100644 include/dt-bindings/mux/mux.h
create mode 100644 include/mux-internal.h
create mode 100644 include/mux.h
diff --git a/drivers/Kconfig b/drivers/Kconfig
index e34a22708c..03a2e5f5ef 100644
--- a/drivers/Kconfig
+++ b/drivers/Kconfig
@@ -60,6 +60,8 @@ source "drivers/mmc/Kconfig"
source "drivers/mtd/Kconfig"
+source "drivers/mux/Kconfig"
+
source "drivers/net/Kconfig"
source "drivers/nvme/Kconfig"
diff --git a/drivers/Makefile b/drivers/Makefile
index 94e8c5da17..76d8500bee 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_$(SPL_TPL_)INPUT) += input/
obj-$(CONFIG_$(SPL_TPL_)LED) += led/
obj-$(CONFIG_$(SPL_TPL_)MMC_SUPPORT) += mmc/
obj-y += mtd/
+obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux/
obj-$(CONFIG_$(SPL_TPL_)PCH_SUPPORT) += pch/
obj-$(CONFIG_$(SPL_TPL_)PCI) += pci/
obj-$(CONFIG_$(SPL_TPL_)PHY) += phy/
diff --git a/drivers/mux/Kconfig b/drivers/mux/Kconfig
new file mode 100644
index 00..35c1c5673c
--- /dev/null
+++ b/drivers/mux/Kconfig
@@ -0,0 +1,11 @@
+menu "Multiplexer drivers"
+
+config MULTIPLEXER
+ bool "Multiplexer Support"
+ depends on DM
+ help
+The mux framework is a minimalistic subsystem that handles multiplexer
+controllers. It provides the same API as Linux and mux drivers should
+be portable with a minimum effort.
+
+endmenu
diff --git a/drivers/mux/Makefile b/drivers/mux/Makefile
new file mode 100644
index 00..351e4363d3
--- /dev/null
+++ b/drivers/mux/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0+
+#
+# (C) Copyright 2019
+# Jean-Jacques Hiblot
+
+obj-$(CONFIG_$(SPL_)MULTIPLEXER) += mux-uclass.o
diff --git a/drivers/mux/mux-uclass.c b/drivers/mux/mux-uclass.c
new file mode 100644
index 00..3c89e0a389
--- /dev/null
+++ b/drivers/mux/mux-uclass.c
@@ -0,0 +1,311 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Multiplexer subsystem
+ *
+ * Based on the linux multiplexer framework
+ *
+ * Copyright (C) 2017 Axentia Technologies AB
+ * Author: Peter Rosin
+ *
+ * Copyright (C) 2017-2018 Texas Instruments Incorporated - http://www.ti.com/
+ * Jean-Jacques Hiblot
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * The idle-as-is "state" is not an actual state that may be selected, it
+ * only implies that the state should not be changed. So, use that state
+ * as indication that the cached state of the multiplexer is unknown.
+ */
+#define MUX_CACHE_UNKNOWN MUX_IDLE_AS_IS
+
+/**
+ * mux_control_ops() - Get the mux_control ops.
+ * @dev: The client device.
+ *
+ * Return: A pointer to the 'mux_control_ops' of the device.
+ */
+static inline const struct mux_control_ops *mux_dev_ops(struct udevice *dev)
+{
+ return (const struct mux_control_ops *)dev->driver->ops;
+}
+
+/**
+ * mux_control_set() - Set the state of the given mux controller.
+ * @mux: A multiplexer control
+ * @state: The new requested state.
+ *
+ * Return: 0 if OK, or a negative error code.
+ */
+static int mux_control_set(struct mux_control *mux, int state)
+{
+ int ret = mux_dev_ops(mux->dev)->set(mux, state);
+
+ mux->cached_state = ret < 0 ? MUX_CACHE_UNKNOWN : state;
+
+ return ret;
+}
+
+unsigned int mux_control_states(struct mux_control *mux)
+{
+ return mux->states;
+}
+
+/**
+ * __mux_control_select() - Select the given multiplexer state.
+ * @mux: The mux-control to request a change of state from.
+ * @state: The new requested state.
+ *
+ * Try to set the mux to the requested state. If not, try to revert if
+ * appropriate.
+ */
+static int __mux_control_select(struct mux_control *mux, int state)
+{
+ int ret;
+
+ if (WARN_ON(state < 0 || state >= mux->states))
+ return -EINVAL;
+
+ if (mux->cached_state == state)
+ return 0;
+
+ ret = mux_control_set(mux, state);
+ if (ret >= 0)
+ return 0;
+
+ /* The mux update failed, try to revert if appropriate... */
+ if (mux->idle_state != MUX_IDLE_AS_IS)
+ mux_control_set(mux, mux->idle_state);
+
+ return ret;
+}
+
+int mux_control_select(struct mux_control *mux, unsigned int state)
+{
+ int ret;
+
+
[PATCH v3 0/6] drivers: Add a framework for MUX drivers
Hi, This series is a re-roll of Jean-Jacques' earlier effort. It adds a new minimalistic subsystem that handles multiplexer controllers. It provides the same API as Linux and mux drivers should be portable with a minimum effort. This series also includes a port of the Linux's mmio-mux driver. This series relies on a series that extends the regmap [0]. [0] https://patchwork.ozlabs.org/project/uboot/list/?series=181623 Changes in v3: - Add a new command called 'mux' that allows listing, selecting, and deselecting muxes on the fly. - Move call to dm_mux_init() to initr_dm_devices(). - Enable mmio operations in sandbox on board_init() to dm_mux_init() can initialize muxes to their idle state and allow the tests to pass. - Add help for CONFIG_MULTIPLEXER. - Change dev_err() in mmio_mux_probe() to log_msg_ret() or log_err(). - Add comments on static functions in mux-class.c - Make mux_uclass_post_probe() static. - Make dm_mux_init() return an integer to signal failure. - Change ifdef of mux-internal.h to _HUX_INTERNAL_H. - Remove unused include from mux-internal.h - Remove comments for non-existent members in struct mux_chip. - Add missing comments for some members in struct mux_control. - Add missing comments for some functions in mux.h - Split up the mux_mmio test into two parts. More would lead to a lot of boilerplate. - Change ut_assertok(IS_ERR(ptr)) to ut_assertok_ptr(ptr). - Fix mis-spellings and capitalize comments. - Rebase on latest master. Changes in v2: - Fixed warning in mux_of_xlate_default() - Improved documentation - Fixed SPL build - insert the mux initialization in init_sequence_r[], just before the console is initialized as its serial port may be muxed - moved the definition of dm_mux_init() in this commit - Call sandbox_set_enable_memio(true) before running the test Jean-Jacques Hiblot (4): drivers: Add a new framework for multiplexer devices dm: board: complete the initialization of the muxes in initr_dm() drivers: mux: mmio-based syscon mux controller test: Add tests for the multiplexer framework Pratyush Yadav (2): cmd: Add a mux command sandbox: Enable memio operations in board_init arch/sandbox/dts/test.dts | 25 +++ board/sandbox/sandbox.c | 2 + cmd/Kconfig | 6 + cmd/Makefile | 1 + cmd/mux.c | 161 common/board_r.c | 12 ++ configs/sandbox_defconfig | 2 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/mux/Kconfig | 25 +++ drivers/mux/Makefile | 7 + drivers/mux/mmio.c| 143 +++ drivers/mux/mux-uclass.c | 334 ++ include/dm/uclass-id.h| 1 + include/dt-bindings/mux/mux.h | 17 ++ include/mux-internal.h| 109 +++ include/mux.h | 159 test/dm/Makefile | 1 + test/dm/mux-mmio.c| 168 + 19 files changed, 1176 insertions(+) create mode 100644 cmd/mux.c create mode 100644 drivers/mux/Kconfig create mode 100644 drivers/mux/Makefile create mode 100644 drivers/mux/mmio.c create mode 100644 drivers/mux/mux-uclass.c create mode 100644 include/dt-bindings/mux/mux.h create mode 100644 include/mux-internal.h create mode 100644 include/mux.h create mode 100644 test/dm/mux-mmio.c -- 2.27.0
[PATCH v3 4/6] cmd: Add a mux command
This command lets the user list, select, and deselect mux controllers
introduced with the mux framework on the fly. It has 3 subcommands:
list, select, and deselect.
List: Lists all the mux present on the system. The muxes are listed for
each chip. The chip is identified by its device name. Each chip can have
a number of mux controllers. Each is listed in sequence and is assigned
a sequential ID based on its position in the mux chip. It lists details
like ID, whether the mux is currently selected or not, the current
state, the idle state, and the number of states.
A sample output would look something like:
=> mux list
a-mux-controller:
ID SelectedCurrent State Idle State Num States
0 no unknown as-is 0x4
1 no 0x2 0x2 0x10
2 no 0x730x730x100
another-mux-controller:
ID SelectedCurrent State Idle State Num States
0 no 0x1 0x1 0x4
1 no 0x2 0x2 0x4
Select: Selects a given mux and puts it in the specified state. This
subcommand takes 3 arguments: mux chip, mux ID, state to set
the mux in. The arguments mux chip and mux ID are used to identify which
mux needs to be selected, and then it is selected to the given state.
The mux needs to be deselected before it can be selected again in
another state. The state should be a hexadecimal number.
For example:
=> mux list
a-mux-controller:
ID SelectedCurrent State Idle State Num States
0 no 0x1 0x1 0x4
1 no 0x1 0x1 0x4
=> mux select a-mux-controller 0 0x3
=> mux list
a-mux-controller:
ID SelectedCurrent State Idle State Num States
0 yes 0x3 0x1 0x4
1 no 0x1 0x1 0x4
Deselect: Deselects a given mux and puts it in its idle state. This
subcommand takes 2 arguments: the mux chip and mux ID to identify which
mux needs to be deselected. So in the above example, we can deselect mux
0 using:
=> mux deselect a-mux-controller 0
=> mux list
a-mux-controller:
ID SelectedCurrent State Idle State Num States
0 no 0x1 0x1 0x4
1 no 0x1 0x1 0x4
Signed-off-by: Pratyush Yadav
---
cmd/Kconfig | 6 ++
cmd/Makefile | 1 +
cmd/mux.c| 161 +++
3 files changed, 168 insertions(+)
create mode 100644 cmd/mux.c
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 192b3b262f..5e78f373d6 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -1128,6 +1128,12 @@ config CMD_MTD
help
MTD commands support.
+config CMD_MUX
+ bool "mux"
+ depends on MULTIPLEXER
+ help
+List, select, and deselect mux controllers on the fly.
+
config CMD_NAND
bool "nand"
default y if NAND_SUNXI
diff --git a/cmd/Makefile b/cmd/Makefile
index 974ad48b0a..8c680420e1 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -99,6 +99,7 @@ obj-$(CONFIG_CMD_MTDPARTS) += mtdparts.o
ifneq ($(CONFIG_CMD_NAND)$(CONFIG_CMD_SF),)
obj-y += legacy-mtd-utils.o
endif
+obj-$(CONFIG_CMD_MUX) += mux.o
obj-$(CONFIG_CMD_NAND) += nand.o
obj-$(CONFIG_CMD_NET) += net.o
obj-$(CONFIG_CMD_NVEDIT_EFI) += nvedit_efi.o
diff --git a/cmd/mux.c b/cmd/mux.c
new file mode 100644
index 00..fd9c09c3ff
--- /dev/null
+++ b/cmd/mux.c
@@ -0,0 +1,161 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * List, select, and deselect mux controllers on the fly.
+ *
+ * Copyright (c) 2020 Texas Instruments Inc.
+ * Author: Pratyush Yadav
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * Find a mux based on its device name in argv[1] and index in the chip in
+ * argv[2].
+ */
+static struct mux_control *cmd_mux_find(char *const argv[])
+{
+ struct udevice *dev;
+ struct mux_chip *chip;
+ int ret;
+ unsigned long id;
+
+ ret = strict_strtoul(argv[2], 10, );
+ if (ret)
+ return ERR_PTR(ret);
+
+ ret = uclass_get_device_by_name(UCLASS_MUX, argv[1], );
+ if (ret)
+ return ERR_PTR(ret);
+
+ chip = dev_get_uclass_priv(dev);
+ if (!chip)
+ return ERR_PTR(ret);
+
+ if (id >= chip->controllers)
+ return ERR_PTR(-EINVAL);
+
+ return >mux[id];
+}
+
+/*
+ * Print the details of a mux. The columns printed correspond to: "Selected",
+ * "Current State", "Idle State", and "Num States".
+ */
+static void print_mux(struct mux_control *mux)
+{
+ printf("%-10s\t", mux->in_use ? "yes" : "no");
+
+ if
Re: [PATCH 25/30] arm: imx: Finish migration from CONFIG_SECURE_BOOT to CONFIG_IMX_HAB
Hi Tom,
On Wed, 10 Jun 2020 at 23:17, Tom Rini wrote:
>
> There are a few remaining places where we say CONFIG_SECURE_BOOT rather
> than CONFIG_IMX HAB. Update these instances.
>
> Cc: Stefano Babic
> Cc: Fabio Estevam
> Cc: NXP i.MX U-Boot Team
> Cc: Eddy Petrișor
> Cc: Shawn Guo
> Cc: Vladimir Oltean
> Cc: Priyanka Jain
> Fixes: d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with CONFIG_IMX_HAB")
> Signed-off-by: Tom Rini
> ---
> Note that we have one place left for CONFIG_SECURE_BOOT being in use but
> I think that is shared with PowerPC so I don't think IMX_HAB is the
> right name. But perhaps I'm wrong about it being used for PowerPC?
NACK on this patch.
I'm not actually sure what were the cross-architecture problems with
the CONFIG_SECURE_BOOT name that mandated Stefano to write this patch:
commit d714a75fd4dcfb0eb8b7e1dd29f43e07113cec0b
Author: Stefano Babic
Date: Fri Sep 20 08:47:53 2019 +0200
imx: replace CONFIG_SECURE_BOOT with CONFIG_IMX_HAB
CONFIG_SECURE_BOOT is too generic and forbids to use it for cross
architecture purposes. If Secure Boot is required for imx, this means to
enable and use the HAB processor in the soc.
Signed-off-by: Stefano Babic
but going the full way and grouping Layerscape, QorIQ and S32V secure
boot implementations together with a boot ROM feature available only
on i.MX 50, 53, 6, 7, 8M and 8MM is demonstrably incorrect.
I think the correct solution (beside leaving the CONFIG_SECURE_BOOT
name alone) would be to merge it, for the Layerscape (ls*) and PowerPC
instances, with CONFIG_CHAIN_OF_TRUST (defined under
board/freescale/common/Kconfig). But you or Stefano might argue that
CHAIN_OF_TRUST is still too generic for a name, and in that case,
maybe the whole thing can be renamed to CONFIG_FSL_ESBC (ESBC ==
"External Secure Boot Code", aka image validation code executed by the
bootloader as opposed to the [internal] boot ROM).
By the way, I have no idea what is the correct solution for S32V.
> ---
> arch/arm/mach-imx/spl_qspi.cfg| 2 +-
> board/ea/mx7ulp_com/imximage.cfg | 2 +-
> board/freescale/s32v234evb/s32v234evb.cfg | 2 +-
> board/novtech/meerkat96/imximage.cfg | 2 +-
> include/configs/ls1021atsn.h | 4 ++--
> 5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-imx/spl_qspi.cfg b/arch/arm/mach-imx/spl_qspi.cfg
> index 88956e626ffd..1e39ae2f01f7 100644
> --- a/arch/arm/mach-imx/spl_qspi.cfg
> +++ b/arch/arm/mach-imx/spl_qspi.cfg
> @@ -12,6 +12,6 @@ BOOT_FROM qspi
> /*
> * Secure boot support
> */
> -#ifdef CONFIG_SECURE_BOOT
> +#ifdef CONFIG_IMX_HAB
> CSF CONFIG_CSF_SIZE
> #endif
> diff --git a/board/ea/mx7ulp_com/imximage.cfg
> b/board/ea/mx7ulp_com/imximage.cfg
> index d298d17c1e92..1b218996aea9 100644
> --- a/board/ea/mx7ulp_com/imximage.cfg
> +++ b/board/ea/mx7ulp_com/imximage.cfg
> @@ -28,7 +28,7 @@ BOOT_FROM sd
> PLUGIN board/freescale/mx7ulp_evk/plugin.bin 0x2F02
> #else
>
> -#ifdef CONFIG_SECURE_BOOT
> +#ifdef CONFIG_IMX_HAB
> CSF CONFIG_CSF_SIZE
> #endif
> /*
> diff --git a/board/freescale/s32v234evb/s32v234evb.cfg
> b/board/freescale/s32v234evb/s32v234evb.cfg
> index 7881512139d0..d7f722006312 100644
> --- a/board/freescale/s32v234evb/s32v234evb.cfg
> +++ b/board/freescale/s32v234evb/s32v234evb.cfg
> @@ -23,6 +23,6 @@ BOOT_FROM sd
> */
>
>
> -#ifdef CONFIG_SECURE_BOOT
> +#ifdef CONFIG_IMX_HAB
> SECURE_BOOT
> #endif
> diff --git a/board/novtech/meerkat96/imximage.cfg
> b/board/novtech/meerkat96/imximage.cfg
> index 3bd8cc55e53c..86275b84d9c8 100644
> --- a/board/novtech/meerkat96/imximage.cfg
> +++ b/board/novtech/meerkat96/imximage.cfg
> @@ -25,7 +25,7 @@ BOOT_FROM sd
> /*
> * Secure boot support
> */
> -#ifdef CONFIG_SECURE_BOOT
> +#ifdef CONFIG_IMX_HAB
> CSF CONFIG_CSF_SIZE
> #endif
>
> diff --git a/include/configs/ls1021atsn.h b/include/configs/ls1021atsn.h
> index e76e54e97fc9..efa708a239ea 100644
> --- a/include/configs/ls1021atsn.h
> +++ b/include/configs/ls1021atsn.h
> @@ -60,9 +60,9 @@
> #define CONFIG_SYS_FSL_PBL_RCW \
> "board/freescale/ls1021atsn/ls102xa_rcw_sd.cfg"
>
> -#ifdef CONFIG_SECURE_BOOT
> +#ifdef CONFIG_IMX_HAB
> #define CONFIG_U_BOOT_HDR_SIZE (16 << 10)
> -#endif /* ifdef CONFIG_SECURE_BOOT */
> +#endif /* ifdef CONFIG_IMX_HAB */
>
> #define CONFIG_SPL_MAX_SIZE0x1a000
> #define CONFIG_SPL_STACK 0x1001d000
> --
> 2.17.1
>
Thanks,
-Vladimir
Re: [PATCH v2 2/3] riscv: Expand the DT size before copy reserved memory node
On Wed, Jun 10, 2020 at 2:05 AM Bin Meng wrote:
>
> Hi Atish,
>
> On Wed, Jun 3, 2020 at 2:23 AM Atish Patra wrote:
> >
> > On Thu, May 28, 2020 at 1:47 AM Bin Meng wrote:
> > >
> > > From: Bin Meng
> > >
> > > The FDT blob might not have sufficient space to hold a copy of
> > > reserved memory node. Expand it before the copy.
> > >
> > > Reported-by: Rick Chen
> > > Signed-off-by: Bin Meng
> > > ---
> > >
> > > arch/riscv/lib/fdt_fixup.c | 6 ++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/arch/riscv/lib/fdt_fixup.c b/arch/riscv/lib/fdt_fixup.c
> > > index 5f523f0..1290a64 100644
> > > --- a/arch/riscv/lib/fdt_fixup.c
> > > +++ b/arch/riscv/lib/fdt_fixup.c
> > > @@ -41,6 +41,12 @@ int riscv_fdt_copy_resv_mem_node(const void *src, void
> > > *dst)
> > > return 0;
> > > }
> > >
> > > + err = fdt_open_into(dst, dst, fdt_totalsize(dst) + 32);
> >
> > The size may be bigger than 32 bytes in future given that we may have
> > multiple reserved pmp regions.
> > How about calculating the size from the source and using that instead
> > of a fixed size ?
> >
>
> This looks way too complicated. That means the codes here need to
> understand the FDT blob binary representation to know exactly how much
> additional size is needed. By looking at existing calls to
> fdt_open_into() none of these do such things.
>
> I guess we will have to give an estimated size to fit all possible
> situations. Say there are 16 PMP regions, and one occupies 64 bytes,
> so we can extend the FDT by 64 * 16 = 1024 bytes. Thoughts ??
>
That works too. I see we only allocate 256 bytes in OpenSBI.
Can you send a patch to OpenSBI as well with the above reasoning ?
> >
> > > + if (err < 0) {
> > > + printf("Device Tree can't be expanded to accommodate new
> > > node");
> > > + return err;
> > > + }
> > > +
> > > fdt_for_each_subnode(node, src, offset) {
> > > name = fdt_get_name(src, node, NULL);
> > >
>
> Regards,
> Bin
--
Regards,
Atish
Re: [PATCH 01/10] dtoc: add support to scan drivers
Hi Simon,
On 11/6/20 14:22, Simon Glass wrote:
Hi Walter,
On Thu, 11 Jun 2020 at 11:11, Walter Lozano wrote:
Hi Simon
On 11/6/20 13:45, Simon Glass wrote:
Hi Walter,
On Mon, 8 Jun 2020 at 09:49, Walter Lozano wrote:
Hi Simon,
On 4/6/20 12:59, Simon Glass wrote:
Hi Walter,
On Fri, 29 May 2020 at 12:15, Walter Lozano wrote:
Currently dtoc scans dtbs to convert them to struct platdata and
to generate U_BOOT_DEVICE entries. These entries need to be filled
with the driver name, but at this moment the information used is the
compatible name present in the dtb. This causes that only nodes with
a compatible name that matches a driver name generate a working
entry.
In order to improve this behaviour, this patch adds to dtoc the
capability of scan drivers source code to generate a list of valid driver
names. This allows to rise a warning in the case that an U_BOOT_DEVICE
entry will try to use a name not valid.
Additionally, in order to add more flexibility to the solution, adds the
U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an
easy way to declare driver name aliases. Thanks to this, dtoc can look
for the driver name based on its alias when it populates the U_BOOT_DEVICE
entry.
Signed-off-by: Walter Lozano
---
include/dm/device.h| 7
tools/dtoc/dtb_platdata.py | 83 --
2 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/include/dm/device.h b/include/dm/device.h
index 975eec5d0e..2cfe10766f 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -282,6 +282,13 @@ struct driver {
#define DM_GET_DRIVER(__name) \
ll_entry_get(struct driver, __name, driver)
+/**
+ * Declare a macro to state a alias for a driver name. This macro will
+ * produce no code but its information will be parsed by tools like
+ * dtoc
+ */
+#define U_BOOT_DRIVER_ALIAS(__name, __alias)
+
/**
* dev_get_platdata() - Get the platform data for a device
*
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index ecfe0624d1..23cfda2f88 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -13,6 +13,8 @@ static data.
import collections
import copy
+import os
+import re
import sys
from dtoc import fdt
@@ -140,6 +142,9 @@ class DtbPlatdata(object):
_include_disabled: true to include nodes marked status = "disabled"
_outfile: The current output file (sys.stdout or a real file)
_lines: Stashed list of output lines for outputting in the future
+_aliases: Dict that hold aliases for compatible strings
key: The driver name, i.e. the part between brackets in U_BOOT_DRIVER(xx) ??
value: ...
Noted.
+_drivers: List of valid driver names found in drivers/
+_driver_aliases: Dict that holds aliases for driver names
key:
vaue:
OK.
"""
def __init__(self, dtb_fname, include_disabled):
self._fdt = None
@@ -149,6 +154,35 @@ class DtbPlatdata(object):
self._outfile = None
self._lines = []
self._aliases = {}
+self._drivers = []
+self._driver_aliases = {}
+
+def get_normalized_compat_name(self, node):
+"""Get a node's normalized compat name
+
+Returns a valid driver name by retrieving node's first compatible
+string as a C identifier and perfomrming a check against _drivers
performing
Noted.
+and a lookup in driver_aliases rising a warning in case of failure.
s/ rising/, printing/
OK.
+
+Args:
+node: Node object to check
+Return:
+Tuple:
+Driver name associated with the first compatible string
+List of C identifiers for all the other compatible strings
+(possibly empty)
Can you update this comment to explain what is returned when it is not found?
Sure.
+"""
+compat_c, aliases_c = get_compat_name(node)
+if compat_c not in self._drivers:
+compat_c_old = compat_c
+compat_c = self._driver_aliases.get(compat_c)
+if not compat_c:
+print('WARNING: the driver %s was not found in the driver
list' % (compat_c_old))
This creates lots of warnings at present. Either we need a patch to
clean up the differences in the source code, or we need to disable the
warning.
Regarding this, maybe we should have a list of driver names we don't
expect to support, like simple_bus. For this to work probably the best
approach is to have a config option similar to CONFIG_OF_REMOVE_PROPS,
so each config can add their owns.
Or perhaps have another macro in the source code that indicates that
the driver cannot be used with of-platdata and should be ignored?
I don't fully understand your idea. As I see, the warning should help to
spot that you will be trying to create a U_BOOT_DEVICE without a proper
Re: [PATCH 2/2] omap4: panda: convert to device model
On Tue, Jun 2, 2020 at 4:49 PM Tero Kristo wrote: > > Convert omap4 panda to device model. > > Signed-off-by: Tero Kristo > --- Reviewed-by: Jagan Teki
Re: [ANN] U-Boot v2020.07-rc4 released
On Thu, Jun 11, 2020 at 07:16:23PM +0200, Mark Kettenis wrote: > > Date: Mon, 8 Jun 2020 20:36:08 -0400 > > From: Tom Rini > > > > Hey all, > > > > It's release day and I've tagged v2020.07-rc4. We continue to move > > along at a good pace. But at this point, we need to take in just bug > > fixes and Kconfig migrations. To help with any sort of contention on > > this, I'm also opening up -next at this point. > > Hi Tom, > > Any chance we can get the following bug-fix moving forward? > > https://patchwork.ozlabs.org/project/uboot/patch/20200427090947.75951-1-kette...@openbsd.org/ > > The issue being fixed is somewhat serious since it can't be worked > around in the OS. So Lukasz objected that it might break the use case that was being fixed in the original commit. Do you have time to confirm the proposed change does or does not break your use case now Lukasz? Thanks! -- Tom signature.asc Description: PGP signature
[PATCH v2] Fix MMC access on Sabrelite
It appears that MMC access on the Sabrelite has been broken since
cdcaee9518:
Loading Environment from MMC... Card did not respond to voltage select!
*** Warning - No block device, using default environment
Remove the board_mmc_init() and related entries now that we should be
using DM_MMC, add PINCTRL so that things work as expected.
Signed-off-by: Martyn Welch
---
Changes in v2:
- Removed now redundant mmc header.
board/boundary/nitrogen6x/nitrogen6x.c | 72 --
configs/mx6qsabrelite_defconfig| 3 ++
2 files changed, 3 insertions(+), 72 deletions(-)
diff --git a/board/boundary/nitrogen6x/nitrogen6x.c
b/board/boundary/nitrogen6x/nitrogen6x.c
index d49725daa8..b3b121bad8 100644
--- a/board/boundary/nitrogen6x/nitrogen6x.c
+++ b/board/boundary/nitrogen6x/nitrogen6x.c
@@ -25,7 +25,6 @@
#include
#include
#include
-#include
#include
#include
#include
@@ -161,26 +160,6 @@ static iomux_v3_cfg_t const usdhc2_pads[] = {
IOMUX_PAD_CTRL(SD2_DAT3__SD2_DATA3, USDHC_PAD_CTRL),
};
-static iomux_v3_cfg_t const usdhc3_pads[] = {
- IOMUX_PAD_CTRL(SD3_CLK__SD3_CLK, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD3_CMD__SD3_CMD, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD3_DAT0__SD3_DATA0, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD3_DAT1__SD3_DATA1, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD3_DAT2__SD3_DATA2, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD3_DAT3__SD3_DATA3, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD3_DAT5__GPIO7_IO00, NO_PAD_CTRL), /* CD */
-};
-
-static iomux_v3_cfg_t const usdhc4_pads[] = {
- IOMUX_PAD_CTRL(SD4_CLK__SD4_CLK, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD4_CMD__SD4_CMD, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD4_DAT0__SD4_DATA0, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD4_DAT1__SD4_DATA1, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD4_DAT2__SD4_DATA2, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(SD4_DAT3__SD4_DATA3, USDHC_PAD_CTRL),
- IOMUX_PAD_CTRL(NANDF_D6__GPIO2_IO06, NO_PAD_CTRL), /* CD */
-};
-
static iomux_v3_cfg_t const enet_pads1[] = {
IOMUX_PAD_CTRL(ENET_MDIO__ENET_MDIO, ENET_PAD_CTRL),
IOMUX_PAD_CTRL(ENET_MDC__ENET_MDC, ENET_PAD_CTRL),
@@ -305,57 +284,6 @@ int board_ehci_power(int port, int on)
#endif
-#ifdef CONFIG_FSL_ESDHC_IMX
-static struct fsl_esdhc_cfg usdhc_cfg[2] = {
- {USDHC3_BASE_ADDR},
- {USDHC4_BASE_ADDR},
-};
-
-int board_mmc_getcd(struct mmc *mmc)
-{
- struct fsl_esdhc_cfg *cfg = (struct fsl_esdhc_cfg *)mmc->priv;
- int gp_cd = (cfg->esdhc_base == USDHC3_BASE_ADDR) ? IMX_GPIO_NR(7, 0) :
- IMX_GPIO_NR(2, 6);
-
- gpio_direction_input(gp_cd);
- return !gpio_get_value(gp_cd);
-}
-
-int board_mmc_init(bd_t *bis)
-{
- int ret;
- u32 index = 0;
-
- usdhc_cfg[0].sdhc_clk = mxc_get_clock(MXC_ESDHC3_CLK);
- usdhc_cfg[1].sdhc_clk = mxc_get_clock(MXC_ESDHC4_CLK);
-
- usdhc_cfg[0].max_bus_width = 4;
- usdhc_cfg[1].max_bus_width = 4;
-
- for (index = 0; index < CONFIG_SYS_FSL_USDHC_NUM; ++index) {
- switch (index) {
- case 0:
- SETUP_IOMUX_PADS(usdhc3_pads);
- break;
- case 1:
- SETUP_IOMUX_PADS(usdhc4_pads);
- break;
- default:
- printf("Warning: you configured more USDHC controllers"
- "(%d) then supported by the board (%d)\n",
- index + 1, CONFIG_SYS_FSL_USDHC_NUM);
- return -EINVAL;
- }
-
- ret = fsl_esdhc_initialize(bis, _cfg[index]);
- if (ret)
- return ret;
- }
-
- return 0;
-}
-#endif
-
#ifdef CONFIG_MXC_SPI
int board_spi_cs_gpio(unsigned bus, unsigned cs)
{
diff --git a/configs/mx6qsabrelite_defconfig b/configs/mx6qsabrelite_defconfig
index ea338c1b53..39b0ef7a42 100644
--- a/configs/mx6qsabrelite_defconfig
+++ b/configs/mx6qsabrelite_defconfig
@@ -28,6 +28,7 @@ CONFIG_CMD_GPT=y
# CONFIG_RANDOM_UUID is not set
CONFIG_CMD_I2C=y
CONFIG_CMD_MMC=y
+# CONFIG_CMD_PINMUX is not set
CONFIG_CMD_SATA=y
CONFIG_CMD_USB=y
CONFIG_CMD_USB_MASS_STORAGE=y
@@ -55,6 +56,8 @@ CONFIG_PHYLIB=y
CONFIG_PHY_MICREL=y
CONFIG_PHY_MICREL_KSZ90X1=y
CONFIG_MII=y
+CONFIG_PINCTRL=y
+CONFIG_PINCTRL_IMX6=y
CONFIG_SPI=y
CONFIG_DM_SPI=y
CONFIG_MXC_SPI=y
--
2.26.2
Pull request: u-boot-spi/master
Hi Tom, This PR is for next release. I'm sending the PR for migration early hoping it can avoid conflicts from your series or in general. May be applied on next would help keep migrations changes inline. Summary: - Drop davinci, mxs spi nondm code - Zap nondm soft_spi - Switch few board to DM_SPI - Drop omap3_pandora, pcm051 boards Travis-CI: https://travis-ci.org/github/openedev/u-boot-amarula/builds/697164896 The following changes since commit be79009f3b9bbdbce283e67a865121e576d790ea: Merge tag 'u-boot-imx-20200609' of https://gitlab.denx.de/u-boot/custodians/u-boot-imx (2020-06-09 09:17:24 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-spi master for you to fetch changes up to b45926fa1d5a1be2a55d0eb208bff8f04f00f875: am335x: sl50: Enable DM_SPI (2020-06-11 15:14:04 +0530) Jagan Teki (13): spi: mxs: Drop nondm code spi: mxs: Code cleanup spi: Zap SOFT_SPI (non-dm) spi: fsl_dspi: Drop nondm code spi: atmel: Drop CONFIG_SYS_SPI_WRITE_TOUT spi: atmel: Remove nondm code spi: atmel: Drop atmel_spi.h ks2_evm: Switch to DM_SPL, SPL_OF_CONTROL spi: davinci: Drop non-dm code arm: Remove omap3_pandora_defconfig board arm: Remove pcm051 board configs: igep00x0: Enable DM_SPI am335x: sl50: Enable DM_SPI arch/arm/Kconfig | 1 - arch/arm/mach-omap2/omap3/Kconfig| 1 - board/pandora/Kconfig| 9 - board/pandora/MAINTAINERS| 6 - board/pandora/Makefile | 6 - board/pandora/pandora.c | 149 - board/pandora/pandora.h | 391 --- board/phytec/pcm051/Kconfig | 15 -- board/phytec/pcm051/MAINTAINERS | 7 - board/phytec/pcm051/Makefile | 11 - board/phytec/pcm051/board.c | 258 --- board/phytec/pcm051/board.h | 24 --- board/phytec/pcm051/mux.c| 127 configs/am335x_sl50_defconfig| 1 + configs/igep00x0_defconfig | 1 + configs/k2e_evm_defconfig| 2 + configs/k2g_evm_defconfig| 2 + configs/k2hk_evm_defconfig | 2 + configs/k2l_evm_defconfig| 2 + configs/omap3_pandora_defconfig | 40 configs/pcm051_rev1_defconfig| 60 -- configs/pcm051_rev3_defconfig| 60 -- doc/README.omap3 | 5 - drivers/spi/Kconfig | 37 ++-- drivers/spi/Makefile | 1 - drivers/spi/atmel_spi.c | 286 - drivers/spi/atmel_spi.h | 15 -- drivers/spi/davinci_spi.c| 157 -- drivers/spi/fsl_dspi.c | 132 drivers/spi/mxs_spi.c| 158 ++ drivers/spi/soft_spi_legacy.c| 168 --- include/configs/omap3_pandora.h | 62 -- include/configs/pcm051.h | 128 include/configs/ti_armv7_keystone2.h | 17 -- scripts/config_whitelist.txt | 1 - 35 files changed, 130 insertions(+), 2212 deletions(-) delete mode 100644 board/pandora/Kconfig delete mode 100644 board/pandora/MAINTAINERS delete mode 100644 board/pandora/Makefile delete mode 100644 board/pandora/pandora.c delete mode 100644 board/pandora/pandora.h delete mode 100644 board/phytec/pcm051/Kconfig delete mode 100644 board/phytec/pcm051/MAINTAINERS delete mode 100644 board/phytec/pcm051/Makefile delete mode 100644 board/phytec/pcm051/board.c delete mode 100644 board/phytec/pcm051/board.h delete mode 100644 board/phytec/pcm051/mux.c delete mode 100644 configs/omap3_pandora_defconfig delete mode 100644 configs/pcm051_rev1_defconfig delete mode 100644 configs/pcm051_rev3_defconfig delete mode 100644 drivers/spi/soft_spi_legacy.c delete mode 100644 include/configs/omap3_pandora.h delete mode 100644 include/configs/pcm051.h
Re: [PATCH] Fix MMC access on Sabrelite
On Thu, 2020-06-11 at 12:29 +0900, Jaehoon Chung wrote: > On 6/11/20 9:59 AM, Jonathan Gray wrote: > > On Tue, May 26, 2020 at 06:02:23PM +0100, Martyn Welch wrote: > > > - > > > -int board_mmc_getcd(struct mmc *mmc) > > I'm not sure..if board_mmc_getcd/init function is removed, can mmc > header be also removed mmc? > > Best Regards, > Jaehoon Chung Good point. I'll send v2. :-) Martyn
Re: [PATCH 01/10] dtoc: add support to scan drivers
Hi Walter,
On Thu, 11 Jun 2020 at 11:11, Walter Lozano wrote:
>
> Hi Simon
>
> On 11/6/20 13:45, Simon Glass wrote:
> > Hi Walter,
> >
> > On Mon, 8 Jun 2020 at 09:49, Walter Lozano
> > wrote:
> >> Hi Simon,
> >>
> >> On 4/6/20 12:59, Simon Glass wrote:
> >>> Hi Walter,
> >>>
> >>> On Fri, 29 May 2020 at 12:15, Walter Lozano
> >>> wrote:
> Currently dtoc scans dtbs to convert them to struct platdata and
> to generate U_BOOT_DEVICE entries. These entries need to be filled
> with the driver name, but at this moment the information used is the
> compatible name present in the dtb. This causes that only nodes with
> a compatible name that matches a driver name generate a working
> entry.
>
> In order to improve this behaviour, this patch adds to dtoc the
> capability of scan drivers source code to generate a list of valid driver
> names. This allows to rise a warning in the case that an U_BOOT_DEVICE
> entry will try to use a name not valid.
>
> Additionally, in order to add more flexibility to the solution, adds the
> U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an
> easy way to declare driver name aliases. Thanks to this, dtoc can look
> for the driver name based on its alias when it populates the
> U_BOOT_DEVICE
> entry.
>
> Signed-off-by: Walter Lozano
> ---
> include/dm/device.h| 7
> tools/dtoc/dtb_platdata.py | 83 --
> 2 files changed, 86 insertions(+), 4 deletions(-)
>
> diff --git a/include/dm/device.h b/include/dm/device.h
> index 975eec5d0e..2cfe10766f 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -282,6 +282,13 @@ struct driver {
> #define DM_GET_DRIVER(__name)
> \
> ll_entry_get(struct driver, __name, driver)
>
> +/**
> + * Declare a macro to state a alias for a driver name. This macro will
> + * produce no code but its information will be parsed by tools like
> + * dtoc
> + */
> +#define U_BOOT_DRIVER_ALIAS(__name, __alias)
> +
> /**
> * dev_get_platdata() - Get the platform data for a device
> *
> diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
> index ecfe0624d1..23cfda2f88 100644
> --- a/tools/dtoc/dtb_platdata.py
> +++ b/tools/dtoc/dtb_platdata.py
> @@ -13,6 +13,8 @@ static data.
>
> import collections
> import copy
> +import os
> +import re
> import sys
>
> from dtoc import fdt
> @@ -140,6 +142,9 @@ class DtbPlatdata(object):
> _include_disabled: true to include nodes marked status =
> "disabled"
> _outfile: The current output file (sys.stdout or a real file)
> _lines: Stashed list of output lines for outputting in the
> future
> +_aliases: Dict that hold aliases for compatible strings
> >>> key: The driver name, i.e. the part between brackets in U_BOOT_DRIVER(xx)
> >>> ??
> >>> value: ...
> >> Noted.
> +_drivers: List of valid driver names found in drivers/
> +_driver_aliases: Dict that holds aliases for driver names
> >>> key:
> >>> vaue:
> >> OK.
> """
> def __init__(self, dtb_fname, include_disabled):
> self._fdt = None
> @@ -149,6 +154,35 @@ class DtbPlatdata(object):
> self._outfile = None
> self._lines = []
> self._aliases = {}
> +self._drivers = []
> +self._driver_aliases = {}
> +
> +def get_normalized_compat_name(self, node):
> +"""Get a node's normalized compat name
> +
> +Returns a valid driver name by retrieving node's first
> compatible
> +string as a C identifier and perfomrming a check against
> _drivers
> >>> performing
> >> Noted.
> +and a lookup in driver_aliases rising a warning in case of
> failure.
> >>> s/ rising/, printing/
> >> OK.
> +
> +Args:
> +node: Node object to check
> +Return:
> +Tuple:
> +Driver name associated with the first compatible string
> +List of C identifiers for all the other compatible
> strings
> +(possibly empty)
> >>> Can you update this comment to explain what is returned when it is not
> >>> found?
> >> Sure.
> +"""
> +compat_c, aliases_c = get_compat_name(node)
> +if compat_c not in self._drivers:
> +compat_c_old = compat_c
> +compat_c = self._driver_aliases.get(compat_c)
> +if not compat_c:
> +
Re: [ANN] U-Boot v2020.07-rc4 released
> Date: Mon, 8 Jun 2020 20:36:08 -0400 > From: Tom Rini > > Hey all, > > It's release day and I've tagged v2020.07-rc4. We continue to move > along at a good pace. But at this point, we need to take in just bug > fixes and Kconfig migrations. To help with any sort of contention on > this, I'm also opening up -next at this point. Hi Tom, Any chance we can get the following bug-fix moving forward? https://patchwork.ozlabs.org/project/uboot/patch/20200427090947.75951-1-kette...@openbsd.org/ The issue being fixed is somewhat serious since it can't be worked around in the OS.
Re: [PATCH 01/10] dtoc: add support to scan drivers
Hi Simon
On 11/6/20 13:45, Simon Glass wrote:
Hi Walter,
On Mon, 8 Jun 2020 at 09:49, Walter Lozano wrote:
Hi Simon,
On 4/6/20 12:59, Simon Glass wrote:
Hi Walter,
On Fri, 29 May 2020 at 12:15, Walter Lozano wrote:
Currently dtoc scans dtbs to convert them to struct platdata and
to generate U_BOOT_DEVICE entries. These entries need to be filled
with the driver name, but at this moment the information used is the
compatible name present in the dtb. This causes that only nodes with
a compatible name that matches a driver name generate a working
entry.
In order to improve this behaviour, this patch adds to dtoc the
capability of scan drivers source code to generate a list of valid driver
names. This allows to rise a warning in the case that an U_BOOT_DEVICE
entry will try to use a name not valid.
Additionally, in order to add more flexibility to the solution, adds the
U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an
easy way to declare driver name aliases. Thanks to this, dtoc can look
for the driver name based on its alias when it populates the U_BOOT_DEVICE
entry.
Signed-off-by: Walter Lozano
---
include/dm/device.h| 7
tools/dtoc/dtb_platdata.py | 83 --
2 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/include/dm/device.h b/include/dm/device.h
index 975eec5d0e..2cfe10766f 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -282,6 +282,13 @@ struct driver {
#define DM_GET_DRIVER(__name) \
ll_entry_get(struct driver, __name, driver)
+/**
+ * Declare a macro to state a alias for a driver name. This macro will
+ * produce no code but its information will be parsed by tools like
+ * dtoc
+ */
+#define U_BOOT_DRIVER_ALIAS(__name, __alias)
+
/**
* dev_get_platdata() - Get the platform data for a device
*
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index ecfe0624d1..23cfda2f88 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -13,6 +13,8 @@ static data.
import collections
import copy
+import os
+import re
import sys
from dtoc import fdt
@@ -140,6 +142,9 @@ class DtbPlatdata(object):
_include_disabled: true to include nodes marked status = "disabled"
_outfile: The current output file (sys.stdout or a real file)
_lines: Stashed list of output lines for outputting in the future
+_aliases: Dict that hold aliases for compatible strings
key: The driver name, i.e. the part between brackets in U_BOOT_DRIVER(xx) ??
value: ...
Noted.
+_drivers: List of valid driver names found in drivers/
+_driver_aliases: Dict that holds aliases for driver names
key:
vaue:
OK.
"""
def __init__(self, dtb_fname, include_disabled):
self._fdt = None
@@ -149,6 +154,35 @@ class DtbPlatdata(object):
self._outfile = None
self._lines = []
self._aliases = {}
+self._drivers = []
+self._driver_aliases = {}
+
+def get_normalized_compat_name(self, node):
+"""Get a node's normalized compat name
+
+Returns a valid driver name by retrieving node's first compatible
+string as a C identifier and perfomrming a check against _drivers
performing
Noted.
+and a lookup in driver_aliases rising a warning in case of failure.
s/ rising/, printing/
OK.
+
+Args:
+node: Node object to check
+Return:
+Tuple:
+Driver name associated with the first compatible string
+List of C identifiers for all the other compatible strings
+(possibly empty)
Can you update this comment to explain what is returned when it is not found?
Sure.
+"""
+compat_c, aliases_c = get_compat_name(node)
+if compat_c not in self._drivers:
+compat_c_old = compat_c
+compat_c = self._driver_aliases.get(compat_c)
+if not compat_c:
+print('WARNING: the driver %s was not found in the driver
list' % (compat_c_old))
This creates lots of warnings at present. Either we need a patch to
clean up the differences in the source code, or we need to disable the
warning.
Regarding this, maybe we should have a list of driver names we don't
expect to support, like simple_bus. For this to work probably the best
approach is to have a config option similar to CONFIG_OF_REMOVE_PROPS,
so each config can add their owns.
Or perhaps have another macro in the source code that indicates that
the driver cannot be used with of-platdata and should be ignored?
I don't fully understand your idea. As I see, the warning should help to
spot that you will be trying to create a U_BOOT_DEVICE without a proper
driver name, which means that compatible string does not match a driver
name. The most probably reason for this is that driver doesn't
Re: [PATCH 01/10] dtoc: add support to scan drivers
Hi Walter,
On Mon, 8 Jun 2020 at 09:49, Walter Lozano wrote:
>
> Hi Simon,
>
> On 4/6/20 12:59, Simon Glass wrote:
> > Hi Walter,
> >
> > On Fri, 29 May 2020 at 12:15, Walter Lozano
> > wrote:
> >> Currently dtoc scans dtbs to convert them to struct platdata and
> >> to generate U_BOOT_DEVICE entries. These entries need to be filled
> >> with the driver name, but at this moment the information used is the
> >> compatible name present in the dtb. This causes that only nodes with
> >> a compatible name that matches a driver name generate a working
> >> entry.
> >>
> >> In order to improve this behaviour, this patch adds to dtoc the
> >> capability of scan drivers source code to generate a list of valid driver
> >> names. This allows to rise a warning in the case that an U_BOOT_DEVICE
> >> entry will try to use a name not valid.
> >>
> >> Additionally, in order to add more flexibility to the solution, adds the
> >> U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but allows an
> >> easy way to declare driver name aliases. Thanks to this, dtoc can look
> >> for the driver name based on its alias when it populates the U_BOOT_DEVICE
> >> entry.
> >>
> >> Signed-off-by: Walter Lozano
> >> ---
> >> include/dm/device.h| 7
> >> tools/dtoc/dtb_platdata.py | 83 --
> >> 2 files changed, 86 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/include/dm/device.h b/include/dm/device.h
> >> index 975eec5d0e..2cfe10766f 100644
> >> --- a/include/dm/device.h
> >> +++ b/include/dm/device.h
> >> @@ -282,6 +282,13 @@ struct driver {
> >> #define DM_GET_DRIVER(__name) \
> >> ll_entry_get(struct driver, __name, driver)
> >>
> >> +/**
> >> + * Declare a macro to state a alias for a driver name. This macro will
> >> + * produce no code but its information will be parsed by tools like
> >> + * dtoc
> >> + */
> >> +#define U_BOOT_DRIVER_ALIAS(__name, __alias)
> >> +
> >> /**
> >>* dev_get_platdata() - Get the platform data for a device
> >>*
> >> diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
> >> index ecfe0624d1..23cfda2f88 100644
> >> --- a/tools/dtoc/dtb_platdata.py
> >> +++ b/tools/dtoc/dtb_platdata.py
> >> @@ -13,6 +13,8 @@ static data.
> >>
> >> import collections
> >> import copy
> >> +import os
> >> +import re
> >> import sys
> >>
> >> from dtoc import fdt
> >> @@ -140,6 +142,9 @@ class DtbPlatdata(object):
> >> _include_disabled: true to include nodes marked status =
> >> "disabled"
> >> _outfile: The current output file (sys.stdout or a real file)
> >> _lines: Stashed list of output lines for outputting in the future
> >> +_aliases: Dict that hold aliases for compatible strings
> > key: The driver name, i.e. the part between brackets in U_BOOT_DRIVER(xx)
> > ??
> > value: ...
> Noted.
> >> +_drivers: List of valid driver names found in drivers/
> >> +_driver_aliases: Dict that holds aliases for driver names
> > key:
> > vaue:
> OK.
> >
> >> """
> >> def __init__(self, dtb_fname, include_disabled):
> >> self._fdt = None
> >> @@ -149,6 +154,35 @@ class DtbPlatdata(object):
> >> self._outfile = None
> >> self._lines = []
> >> self._aliases = {}
> >> +self._drivers = []
> >> +self._driver_aliases = {}
> >> +
> >> +def get_normalized_compat_name(self, node):
> >> +"""Get a node's normalized compat name
> >> +
> >> +Returns a valid driver name by retrieving node's first compatible
> >> +string as a C identifier and perfomrming a check against _drivers
> > performing
> Noted.
> >
> >> +and a lookup in driver_aliases rising a warning in case of
> >> failure.
> > s/ rising/, printing/
> OK.
> >
> >> +
> >> +Args:
> >> +node: Node object to check
> >> +Return:
> >> +Tuple:
> >> +Driver name associated with the first compatible string
> >> +List of C identifiers for all the other compatible strings
> >> +(possibly empty)
> > Can you update this comment to explain what is returned when it is not
> > found?
> Sure.
> >> +"""
> >> +compat_c, aliases_c = get_compat_name(node)
> >> +if compat_c not in self._drivers:
> >> +compat_c_old = compat_c
> >> +compat_c = self._driver_aliases.get(compat_c)
> >> +if not compat_c:
> >> +print('WARNING: the driver %s was not found in the driver
> >> list' % (compat_c_old))
> > This creates lots of warnings at present. Either we need a patch to
> > clean up the differences in the source code, or we need to disable the
> > warning.
>
>
> Regarding this, maybe we should have a list of driver names we don't
> expect to support, like simple_bus. For this to work probably the best
> approach is to have a config option
Re: [PATCH 01/10] dtoc: add support to scan drivers
Hi Walter,
On Thu, 11 Jun 2020 at 10:15, Walter Lozano wrote:
>
> Hi Simon,
>
> On 8/6/20 12:49, Walter Lozano wrote:
> > Hi Simon,
> >
> > On 4/6/20 12:59, Simon Glass wrote:
> >> Hi Walter,
> >>
> >> On Fri, 29 May 2020 at 12:15, Walter Lozano
> >> wrote:
> >>> Currently dtoc scans dtbs to convert them to struct platdata and
> >>> to generate U_BOOT_DEVICE entries. These entries need to be filled
> >>> with the driver name, but at this moment the information used is the
> >>> compatible name present in the dtb. This causes that only nodes with
> >>> a compatible name that matches a driver name generate a working
> >>> entry.
> >>>
> >>> In order to improve this behaviour, this patch adds to dtoc the
> >>> capability of scan drivers source code to generate a list of valid
> >>> driver
> >>> names. This allows to rise a warning in the case that an U_BOOT_DEVICE
> >>> entry will try to use a name not valid.
> >>>
> >>> Additionally, in order to add more flexibility to the solution, adds
> >>> the
> >>> U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but
> >>> allows an
> >>> easy way to declare driver name aliases. Thanks to this, dtoc can look
> >>> for the driver name based on its alias when it populates the
> >>> U_BOOT_DEVICE
> >>> entry.
> >>>
> >>> Signed-off-by: Walter Lozano
> >>> ---
> >>> include/dm/device.h| 7
> >>> tools/dtoc/dtb_platdata.py | 83
> >>> --
> >>> 2 files changed, 86 insertions(+), 4 deletions(-)
> >>>
[..]
> >>> +"""
> >>> +compat_c, aliases_c = get_compat_name(node)
> >>> +if compat_c not in self._drivers:
> >>> +compat_c_old = compat_c
> >>> +compat_c = self._driver_aliases.get(compat_c)
> >>> +if not compat_c:
> >>> +print('WARNING: the driver %s was not found in the
> >>> driver list' % (compat_c_old))
> >> This creates lots of warnings at present. Either we need a patch to
> >> clean up the differences in the source code, or we need to disable the
> >> warning.
> >
> >
> > Regarding this, maybe we should have a list of driver names we don't
> > expect to support, like simple_bus. For this to work probably the best
> > approach is to have a config option similar to CONFIG_OF_REMOVE_PROPS,
> > so each config can add their owns.
>
> I've been thinking about this issue, I think it would be better to only
> print the warning if build is issue with
>
> make V=1
>
> What do you think?
Can we not fix the warnings?
Regards,
Simon
Re: [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration
On 6/11/20 3:44 PM, Patrick DELAUNAY wrote: > Hi, > >> From: Tom Rini >> Sent: mercredi 10 juin 2020 23:58 >> >> On Wed, Jun 10, 2020 at 11:40:33PM +0200, Marek Vasut wrote: >>> On 6/10/20 11:35 PM, Tom Rini wrote: On Wed, Jun 10, 2020 at 10:56:40PM +0200, Marek Vasut wrote: > On 6/10/20 10:54 PM, Tom Rini wrote: >> On Wed, Jun 10, 2020 at 10:46:23PM +0200, Marek Vasut wrote: >>> On 6/10/20 10:11 PM, Tom Rini wrote: >>> [...] You mean be more like barebox and Linux where the board-specific stuff is kicked up one level and we have a more generic binary? I don't know and there's so much work that would be required before having to move this from a Kconfig choice to just Kconfig options I don't see that as being a >> relevant question here. Or did I misunderstand the question? >>> >>> More like automatically have a Kconfig option generate it's >>> _SPL and _TPL variant. >> >> Ah. Well, that is rephrasing my first question. Would it >> ever make sense to have more than one of these enabled? > > For some sort of universal SPL, maybe ? So no, there's not a reason today then and it should be a choice. >>> >>> Can you provide some more detailed explanation why we shouldn't >>> generate _SPL and _TPL variants of Kconfig entries for all >>> Kconfig entries ? It would make things much simpler and permit >>> configuring SPL/TPL the same way U-Boot is configured, with their own >> set of options. >> >> In the context of this particular thread? I don't see how it's >> helpful to say 3 times that we're in fact building for Tegra or >> STM32 or SoCFPGA when you can't build something that runs on more >> than one of those. > > In general. > > Here I can imagine it is possible to build SoCFPGA+STM32 universal > SD card image in fact. So that's the case I brought up at first and you said no to. >>> >>> I think I don't understand this part. >> >> You're talking about a binary that runs on more than one dissimilar SoC, yes? >> I don't see that in the foreseeable future but I don't feel so strongly about making this config area tidy enough to argue the point. So fine, leave it as separate options, the default y if ... is reasonable enough to ensure we get functional builds. >>> >>> This patch is OK as-is. >> >> Yes, since I'm no longer asking for changes to it, it's fine. > > I don't see possible use case where the 3 drivers configurations can be > activated at the same time, > Except, as Marek indicated it, the same U-Boot binary compiled to be executed > for several architecture > (STM32, IMX, TEGRA). > > But it is not possible (duplicate cote between arch) as each configuration > is linked to archictecture variant > (the synopsis IP is modified by SOC vendor). You can build Linux for all three and use the same zImage, so it should also be possible for U-Boot. > For me it should be possible to change the config option to select, > even it is no more requested and the patch is OK as-is (I keep the > possibility to have the 3 options activated). The patch is OK.
Re: [PATCH 01/10] dtoc: add support to scan drivers
Hi Simon,
On 8/6/20 12:49, Walter Lozano wrote:
Hi Simon,
On 4/6/20 12:59, Simon Glass wrote:
Hi Walter,
On Fri, 29 May 2020 at 12:15, Walter Lozano
wrote:
Currently dtoc scans dtbs to convert them to struct platdata and
to generate U_BOOT_DEVICE entries. These entries need to be filled
with the driver name, but at this moment the information used is the
compatible name present in the dtb. This causes that only nodes with
a compatible name that matches a driver name generate a working
entry.
In order to improve this behaviour, this patch adds to dtoc the
capability of scan drivers source code to generate a list of valid
driver
names. This allows to rise a warning in the case that an U_BOOT_DEVICE
entry will try to use a name not valid.
Additionally, in order to add more flexibility to the solution, adds
the
U_BOOT_DRIVER_ALIAS macro, which generates no code at all, but
allows an
easy way to declare driver name aliases. Thanks to this, dtoc can look
for the driver name based on its alias when it populates the
U_BOOT_DEVICE
entry.
Signed-off-by: Walter Lozano
---
include/dm/device.h | 7
tools/dtoc/dtb_platdata.py | 83
--
2 files changed, 86 insertions(+), 4 deletions(-)
diff --git a/include/dm/device.h b/include/dm/device.h
index 975eec5d0e..2cfe10766f 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -282,6 +282,13 @@ struct driver {
#define DM_GET_DRIVER(__name) \
ll_entry_get(struct driver, __name, driver)
+/**
+ * Declare a macro to state a alias for a driver name. This macro will
+ * produce no code but its information will be parsed by tools like
+ * dtoc
+ */
+#define U_BOOT_DRIVER_ALIAS(__name, __alias)
+
/**
* dev_get_platdata() - Get the platform data for a device
*
diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index ecfe0624d1..23cfda2f88 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -13,6 +13,8 @@ static data.
import collections
import copy
+import os
+import re
import sys
from dtoc import fdt
@@ -140,6 +142,9 @@ class DtbPlatdata(object):
_include_disabled: true to include nodes marked status =
"disabled"
_outfile: The current output file (sys.stdout or a real file)
_lines: Stashed list of output lines for outputting in the
future
+ _aliases: Dict that hold aliases for compatible strings
key: The driver name, i.e. the part between brackets in
U_BOOT_DRIVER(xx) ??
value: ...
Noted.
+ _drivers: List of valid driver names found in drivers/
+ _driver_aliases: Dict that holds aliases for driver names
key:
vaue:
OK.
"""
def __init__(self, dtb_fname, include_disabled):
self._fdt = None
@@ -149,6 +154,35 @@ class DtbPlatdata(object):
self._outfile = None
self._lines = []
self._aliases = {}
+ self._drivers = []
+ self._driver_aliases = {}
+
+ def get_normalized_compat_name(self, node):
+ """Get a node's normalized compat name
+
+ Returns a valid driver name by retrieving node's first
compatible
+ string as a C identifier and perfomrming a check against
_drivers
performing
Noted.
+ and a lookup in driver_aliases rising a warning in case of
failure.
s/ rising/, printing/
OK.
+
+ Args:
+ node: Node object to check
+ Return:
+ Tuple:
+ Driver name associated with the first compatible
string
+ List of C identifiers for all the other compatible
strings
+ (possibly empty)
Can you update this comment to explain what is returned when it is
not found?
Sure.
+ """
+ compat_c, aliases_c = get_compat_name(node)
+ if compat_c not in self._drivers:
+ compat_c_old = compat_c
+ compat_c = self._driver_aliases.get(compat_c)
+ if not compat_c:
+ print('WARNING: the driver %s was not found in the
driver list' % (compat_c_old))
This creates lots of warnings at present. Either we need a patch to
clean up the differences in the source code, or we need to disable the
warning.
Regarding this, maybe we should have a list of driver names we don't
expect to support, like simple_bus. For this to work probably the best
approach is to have a config option similar to CONFIG_OF_REMOVE_PROPS,
so each config can add their owns.
I've been thinking about this issue, I think it would be better to only
print the warning if build is issue with
make V=1
What do you think?
Also the warning is not really actionable. It needs to add mention of
U_BOOT_DEVICE and ...ALIAS.
I agree with you. Thanks.
In future we can scan the compatible strings and tell the user what
changes to make, I suppose.
Yes, it will be a great improvement!
+ compat_c = compat_c_old
+ else: # pragma: no cover
Need to fix the
[PATCH] configs: stm32mp1: activate WATCHDOG
As kernel v5.6 have a solution since so we will be able to enable
the watchdog at boot time. It is reloaded by the watchdog
framework (if CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED is set) and
until the userspace watchdog daemon takes over control.
Need presence of kernel patch 85fdc63fe256 ("drivers: watchdog:
stm32_iwdg: set WDOG_HW_RUNNING at probe") integrated in v5.6-rc1.
This patch revert the previous commit ca351e705a5c ("stm32mp1:
deactivate WATCHDOG in defconfig").
Signed-off-by: Patrick Delaunay
---
configs/stm32mp15_basic_defconfig | 2 ++
configs/stm32mp15_trusted_defconfig | 2 ++
2 files changed, 4 insertions(+)
diff --git a/configs/stm32mp15_basic_defconfig
b/configs/stm32mp15_basic_defconfig
index c7dd2926c9..a3b6c381d2 100644
--- a/configs/stm32mp15_basic_defconfig
+++ b/configs/stm32mp15_basic_defconfig
@@ -140,5 +140,7 @@ CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_DSI=y
CONFIG_VIDEO_STM32_MAX_XRES=1280
CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_WDT=y
+CONFIG_WDT_STM32MP=y
CONFIG_ERRNO_STR=y
CONFIG_FDT_FIXUP_PARTITIONS=y
diff --git a/configs/stm32mp15_trusted_defconfig
b/configs/stm32mp15_trusted_defconfig
index ca4a10813b..cf5ad916e7 100644
--- a/configs/stm32mp15_trusted_defconfig
+++ b/configs/stm32mp15_trusted_defconfig
@@ -127,5 +127,7 @@ CONFIG_VIDEO_STM32=y
CONFIG_VIDEO_STM32_DSI=y
CONFIG_VIDEO_STM32_MAX_XRES=1280
CONFIG_VIDEO_STM32_MAX_YRES=800
+CONFIG_WDT=y
+CONFIG_WDT_STM32MP=y
CONFIG_ERRNO_STR=y
CONFIG_FDT_FIXUP_PARTITIONS=y
--
2.17.1
Re: [PATCH 22/30] arm: toradex: Convert CONFIG_CONSOLE_MUX to Kconfig
Hi Tom, On Wed, Jun 10, 2020 at 11:21 PM Tom Rini wrote: > > This converts the following to Kconfig: >CONFIG_CONSOLE_MUX > > Cc: Igor Opaniuk > Signed-off-by: Tom Rini > --- > configs/apalis_imx6_defconfig | 2 -- > configs/colibri_imx6_defconfig | 2 -- > include/configs/apalis_imx6.h | 1 - > include/configs/colibri_imx6.h | 1 - > 4 files changed, 6 deletions(-) > > diff --git a/configs/apalis_imx6_defconfig b/configs/apalis_imx6_defconfig > index 6b0f0e463896..e9d9b3f30239 100644 > --- a/configs/apalis_imx6_defconfig > +++ b/configs/apalis_imx6_defconfig > @@ -19,8 +19,6 @@ CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6Q" > CONFIG_BOOTDELAY=1 > -# CONFIG_CONSOLE_MUX is not set > -CONFIG_SYS_CONSOLE_IS_IN_ENV=y > CONFIG_MISC_INIT_R=y > CONFIG_VERSION_VARIABLE=y > # CONFIG_DISPLAY_BOARDINFO is not set > diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig > index 44a3ff859c2d..8bdae00129c3 100644 > --- a/configs/colibri_imx6_defconfig > +++ b/configs/colibri_imx6_defconfig > @@ -18,8 +18,6 @@ CONFIG_DISTRO_DEFAULTS=y > CONFIG_FIT=y > CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg,MX6DL" > CONFIG_BOOTDELAY=1 > -# CONFIG_CONSOLE_MUX is not set > -CONFIG_SYS_CONSOLE_IS_IN_ENV=y > CONFIG_MISC_INIT_R=y > CONFIG_VERSION_VARIABLE=y > # CONFIG_DISPLAY_BOARDINFO is not set > diff --git a/include/configs/apalis_imx6.h b/include/configs/apalis_imx6.h > index d5a0625e0282..b2d87019c8e7 100644 > --- a/include/configs/apalis_imx6.h > +++ b/include/configs/apalis_imx6.h > @@ -74,7 +74,6 @@ > #define CONFIG_BMP_16BPP > #define CONFIG_VIDEO_LOGO > #define CONFIG_VIDEO_BMP_LOGO > -#define CONFIG_CONSOLE_MUX > #define CONFIG_IMX_HDMI > #define CONFIG_IMX_VIDEO_SKIP > > diff --git a/include/configs/colibri_imx6.h b/include/configs/colibri_imx6.h > index 6beef250942b..a0ee4d48ad06 100644 > --- a/include/configs/colibri_imx6.h > +++ b/include/configs/colibri_imx6.h > @@ -62,7 +62,6 @@ > #define CONFIG_BMP_16BPP > #define CONFIG_VIDEO_LOGO > #define CONFIG_VIDEO_BMP_LOGO > -#define CONFIG_CONSOLE_MUX > #define CONFIG_IMX_HDMI > #define CONFIG_IMX_VIDEO_SKIP > > -- > 2.17.1 > Thanks for the patch. Reviewed-by: Igor Opaniuk -- Best regards - Freundliche Grüsse - Meilleures salutations Igor Opaniuk mailto: igor.opan...@gmail.com skype: igor.opanyuk +380 (93) 836 40 67 http://ua.linkedin.com/in/iopaniuk
[PATCH 1/2] board: amlogic: move boards doc into doc/board/amlogic
Move the natural text Amlogic board README files to doc/board/amlogic into reStructuredText and : - add reStructuredText markup for bash code - fix secondary titles markup - move board support into global support matrix Signed-off-by: Neil Armstrong --- doc/board/amlogic/index.rst | 95 + .../board/amlogic/khadas-vim.rst | 138 +++-- .../board/amlogic/khadas-vim2.rst | 138 ++--- .../board/amlogic/khadas-vim3.rst | 189 + .../board/amlogic/khadas-vim3l.rst| 189 + .../board/amlogic/libretech-ac.rst| 142 ++--- .../board/amlogic/libretech-cc.rst| 139 +++-- .../board/amlogic/nanopi-k2.rst | 136 +++-- .../board/amlogic/odroid-c2.rst | 50 +++-- .../board/amlogic/odroid-n2.rst | 187 + .../README.p200 => doc/board/amlogic/p200.rst | 136 ++--- .../README.p201 => doc/board/amlogic/p201.rst | 136 ++--- .../README.p212 => doc/board/amlogic/p212.rst | 136 ++--- .../README.q200 => doc/board/amlogic/q200.rst | 136 ++--- .../s400/README => doc/board/amlogic/s400.rst | 150 +++--- .../README => doc/board/amlogic/sei510.rst| 190 - .../README => doc/board/amlogic/sei610.rst| 185 + .../u200/README => doc/board/amlogic/u200.rst | 188 - .../README.w400 => doc/board/amlogic/w400.rst | 192 +- doc/board/index.rst | 1 + 20 files changed, 1484 insertions(+), 1369 deletions(-) create mode 100644 doc/board/amlogic/index.rst rename board/amlogic/p212/README.khadas-vim => doc/board/amlogic/khadas-vim.rst (24%) rename board/amlogic/q200/README.khadas-vim2 => doc/board/amlogic/khadas-vim2.rst (26%) rename board/amlogic/w400/README.khadas-vim3 => doc/board/amlogic/khadas-vim3.rst (20%) rename board/amlogic/w400/README.khadas-vim3l => doc/board/amlogic/khadas-vim3l.rst (19%) rename board/amlogic/p212/README.libretech-ac => doc/board/amlogic/libretech-ac.rst (21%) rename board/amlogic/p212/README.libretech-cc => doc/board/amlogic/libretech-cc.rst (46%) rename board/amlogic/p200/README.nanopi-k2 => doc/board/amlogic/nanopi-k2.rst (24%) rename board/amlogic/p200/README.odroid-c2 => doc/board/amlogic/odroid-c2.rst (56%) rename board/amlogic/w400/README.odroid-n2 => doc/board/amlogic/odroid-n2.rst (19%) rename board/amlogic/p200/README.p200 => doc/board/amlogic/p200.rst (24%) rename board/amlogic/p201/README.p201 => doc/board/amlogic/p201.rst (24%) rename board/amlogic/p212/README.p212 => doc/board/amlogic/p212.rst (24%) rename board/amlogic/q200/README.q200 => doc/board/amlogic/q200.rst (24%) rename board/amlogic/s400/README => doc/board/amlogic/s400.rst (21%) rename board/amlogic/sei510/README => doc/board/amlogic/sei510.rst (14%) rename board/amlogic/sei610/README => doc/board/amlogic/sei610.rst (16%) rename board/amlogic/u200/README => doc/board/amlogic/u200.rst (17%) rename board/amlogic/w400/README.w400 => doc/board/amlogic/w400.rst (17%) diff --git a/doc/board/amlogic/index.rst b/doc/board/amlogic/index.rst new file mode 100644 index 00..3730419167 --- /dev/null +++ b/doc/board/amlogic/index.rst @@ -0,0 +1,95 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Amlogic +=== + +Hardware Support Matrix +--- + +An up-do-date matrix is also available on: http://linux-meson.com + +This matrix concerns the actual source code version. + ++---+---+--+--+++-+--+ +| | S905 | S905X| S912 | A113X | S905X2 | S922X | S905X3 | +| | | S805X| S905D| | S905D2 | A311D | S905D3 | +| | | | | | S905Y2 | | | ++===+===+==+==+++=+==+ +| Boards | Odroid-C2 | P212 | Khadas VIM2 | S400 | U200 | Odroid-N2 | SEI610 | +| | Nanopi-K2 | Khadas-VIM | Libretech-PC | | SEI510 | Khadas-VIM3 | Khadas-VIM3L | +| | P200 | LibreTech-CC | | || | | +| | P201 | LibreTech-AC | | || | | ++---+---+--+--+++-+--+ +| UART | **Yes** | **Yes** | **Yes**
RE: [PATCH] net: dwc_eth_qos: add Kconfig option to select supported configuration
Hi, > From: Tom Rini > Sent: mercredi 10 juin 2020 23:58 > > On Wed, Jun 10, 2020 at 11:40:33PM +0200, Marek Vasut wrote: > > On 6/10/20 11:35 PM, Tom Rini wrote: > > > On Wed, Jun 10, 2020 at 10:56:40PM +0200, Marek Vasut wrote: > > >> On 6/10/20 10:54 PM, Tom Rini wrote: > > >>> On Wed, Jun 10, 2020 at 10:46:23PM +0200, Marek Vasut wrote: > > On 6/10/20 10:11 PM, Tom Rini wrote: > > [...] > > > You mean be more like barebox and Linux where the > > > board-specific stuff is kicked up one level and we have a > > > more generic binary? I don't know and there's so much work > > > that would be required before having to move this from a > > > Kconfig choice to just Kconfig options I don't see that as being a > relevant question here. > > > > > > Or did I misunderstand the question? > > > > More like automatically have a Kconfig option generate it's > > _SPL and _TPL variant. > > >>> > > >>> Ah. Well, that is rephrasing my first question. Would it > > >>> ever make sense to have more than one of these enabled? > > >> > > >> For some sort of universal SPL, maybe ? > > > > > > So no, there's not a reason today then and it should be a choice. > > > > Can you provide some more detailed explanation why we shouldn't > > generate _SPL and _TPL variants of Kconfig entries for all > > Kconfig entries ? It would make things much simpler and permit > > configuring SPL/TPL the same way U-Boot is configured, with their own > set of options. > > >>> > > >>> In the context of this particular thread? I don't see how it's > > >>> helpful to say 3 times that we're in fact building for Tegra or > > >>> STM32 or SoCFPGA when you can't build something that runs on more > than one of those. > > >> > > >> In general. > > >> > > >> Here I can imagine it is possible to build SoCFPGA+STM32 universal > > >> SD card image in fact. > > > > > > So that's the case I brought up at first and you said no to. > > > > I think I don't understand this part. > > You're talking about a binary that runs on more than one dissimilar SoC, yes? > > > > I don't > > > see that in the foreseeable future but I don't feel so strongly > > > about making this config area tidy enough to argue the point. So > > > fine, leave it as separate options, the default y if ... is > > > reasonable enough to ensure we get functional builds. > > > > This patch is OK as-is. > > Yes, since I'm no longer asking for changes to it, it's fine. I don't see possible use case where the 3 drivers configurations can be activated at the same time, Except, as Marek indicated it, the same U-Boot binary compiled to be executed for several architecture (STM32, IMX, TEGRA). But it is not possible (duplicate cote between arch) as each configuration is linked to archictecture variant (the synopsis IP is modified by SOC vendor). For me it should be possible to change the config option to select, even it is no more requested and the patch is OK as-is (I keep the possibility to have the 3 options activated). Regards Patrick
[PATCH 2/2] board: amlogic: add board doc files to MAINTAINERS
Add the recently added reStructuredText board documentation in the appropriate MAINTAINERS files. Signed-off-by: Neil Armstrong --- MAINTAINERS | 1 + board/amlogic/p200/MAINTAINERS | 3 +++ board/amlogic/p201/MAINTAINERS | 1 + board/amlogic/p212/MAINTAINERS | 4 board/amlogic/q200/MAINTAINERS | 1 + board/amlogic/s400/MAINTAINERS | 1 + board/amlogic/sei510/MAINTAINERS | 1 + board/amlogic/sei610/MAINTAINERS | 1 + board/amlogic/u200/MAINTAINERS | 1 + board/amlogic/w400/MAINTAINERS | 4 10 files changed, 18 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 1fd975c72f..fb904ba7db 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -145,6 +145,7 @@ F: drivers/power/domain/meson-gx-pwrc-vpu.c F: drivers/video/meson/ F: include/configs/meson64.h F: include/configs/meson64_android.h +F: doc/board/amlogic/ N: meson ARM BROADCOM BCM283X diff --git a/board/amlogic/p200/MAINTAINERS b/board/amlogic/p200/MAINTAINERS index c20f056af2..1df9b8b24b 100644 --- a/board/amlogic/p200/MAINTAINERS +++ b/board/amlogic/p200/MAINTAINERS @@ -7,3 +7,6 @@ F: board/amlogic/p200/ F: configs/nanopi-k2_defconfig F: configs/odroid-c2_defconfig F: configs/p200_defconfig +F: doc/board/amlogic/p200.rst +F: doc/board/amlogic/nanopi-k2.rst +F: doc/board/amlogic/odroid-c2.rst diff --git a/board/amlogic/p201/MAINTAINERS b/board/amlogic/p201/MAINTAINERS index f84984d7ab..1501b6280d 100644 --- a/board/amlogic/p201/MAINTAINERS +++ b/board/amlogic/p201/MAINTAINERS @@ -4,3 +4,4 @@ S: Maintained L: u-boot-amlo...@groups.io F: board/amlogic/p201/ F: configs/p201_defconfig +F: doc/board/amlogic/p201.rst diff --git a/board/amlogic/p212/MAINTAINERS b/board/amlogic/p212/MAINTAINERS index 8848df05b7..cae6994393 100644 --- a/board/amlogic/p212/MAINTAINERS +++ b/board/amlogic/p212/MAINTAINERS @@ -8,3 +8,7 @@ F: configs/khadas-vim_defconfig F: configs/libretech-ac_defconfig F: configs/libretech-cc_defconfig F: configs/p212_defconfig +F: doc/board/amlogic/p212.rst +F: doc/board/amlogic/libretech-ac.rst +F: doc/board/amlogic/libretech-cc.rst +F: doc/board/amlogic/khadas-vim.rst diff --git a/board/amlogic/q200/MAINTAINERS b/board/amlogic/q200/MAINTAINERS index 6f00f87386..ec05aa6f4c 100644 --- a/board/amlogic/q200/MAINTAINERS +++ b/board/amlogic/q200/MAINTAINERS @@ -7,3 +7,4 @@ F: include/configs/q200.h F: configs/khadas-vim2_defconfig F: configs/libretech-s905d-pc_defconfig F: configs/libretech-s912-pc_defconfig +F: doc/board/amlogic/khadas-vim2.rst diff --git a/board/amlogic/s400/MAINTAINERS b/board/amlogic/s400/MAINTAINERS index da90cf9b6f..fb46b1bbbf 100644 --- a/board/amlogic/s400/MAINTAINERS +++ b/board/amlogic/s400/MAINTAINERS @@ -5,3 +5,4 @@ L: u-boot-amlo...@groups.io F: board/amlogic/s400/ F: include/configs/s400.h F: configs/s400_defconfig +F: doc/board/amlogic/s400.rst diff --git a/board/amlogic/sei510/MAINTAINERS b/board/amlogic/sei510/MAINTAINERS index 8dc655e8cc..c01c1d60df 100644 --- a/board/amlogic/sei510/MAINTAINERS +++ b/board/amlogic/sei510/MAINTAINERS @@ -5,3 +5,4 @@ L: u-boot-amlo...@groups.io F: board/amlogic/sei510/ F: configs/sei510_defconfig F: include/configs/sei510.h +F: doc/board/amlogic/sei510.rst diff --git a/board/amlogic/sei610/MAINTAINERS b/board/amlogic/sei610/MAINTAINERS index da77aafa41..092178b2c8 100644 --- a/board/amlogic/sei610/MAINTAINERS +++ b/board/amlogic/sei610/MAINTAINERS @@ -5,3 +5,4 @@ L: u-boot-amlo...@groups.io F: board/amlogic/sei610/ F: configs/sei610_defconfig F: include/configs/sei610.h +F: doc/board/amlogic/sei610.rst diff --git a/board/amlogic/u200/MAINTAINERS b/board/amlogic/u200/MAINTAINERS index 5ae7f5e66a..8c23f9a7d3 100644 --- a/board/amlogic/u200/MAINTAINERS +++ b/board/amlogic/u200/MAINTAINERS @@ -4,3 +4,4 @@ S: Maintained L: u-boot-amlo...@groups.io F: board/amlogic/u200/ F: configs/u200_defconfig +F: doc/board/amlogic/u200.rst diff --git a/board/amlogic/w400/MAINTAINERS b/board/amlogic/w400/MAINTAINERS index 2ff90039ca..5e837cfaef 100644 --- a/board/amlogic/w400/MAINTAINERS +++ b/board/amlogic/w400/MAINTAINERS @@ -6,3 +6,7 @@ F: board/amlogic/w400/ F: configs/khadas-vim3_defconfig F: configs/khadas-vim3l_defconfig F: configs/odroid-n2_defconfig +F: doc/board/amlogic/w400.rst +F: doc/board/amlogic/khadas-vim3.rst +F: doc/board/amlogic/khadas-vim3l.rst +F: doc/board/amlogic/odroid-n2.rst -- 2.22.0
[PATCH 0/2] board: amlogic: move boards doc into doc/board/amlogic
As asked by Tom, this moves all the Amlogic board documentation into doc/board/amlogic into RsT and proper index with feature matrix. Neil Armstrong (2): board: amlogic: move boards doc into doc/board/amlogic board: amlogic: add board doc files to MAINTAINERS MAINTAINERS | 1 + board/amlogic/p200/MAINTAINERS| 3 + board/amlogic/p201/MAINTAINERS| 1 + board/amlogic/p212/MAINTAINERS| 4 + board/amlogic/q200/MAINTAINERS| 1 + board/amlogic/s400/MAINTAINERS| 1 + board/amlogic/sei510/MAINTAINERS | 1 + board/amlogic/sei610/MAINTAINERS | 1 + board/amlogic/u200/MAINTAINERS| 1 + board/amlogic/w400/MAINTAINERS| 4 + doc/board/amlogic/index.rst | 95 + .../board/amlogic/khadas-vim.rst | 138 +++-- .../board/amlogic/khadas-vim2.rst | 138 ++--- .../board/amlogic/khadas-vim3.rst | 189 + .../board/amlogic/khadas-vim3l.rst| 189 + .../board/amlogic/libretech-ac.rst| 142 ++--- .../board/amlogic/libretech-cc.rst| 139 +++-- .../board/amlogic/nanopi-k2.rst | 136 +++-- .../board/amlogic/odroid-c2.rst | 50 +++-- .../board/amlogic/odroid-n2.rst | 187 + .../README.p200 => doc/board/amlogic/p200.rst | 136 ++--- .../README.p201 => doc/board/amlogic/p201.rst | 136 ++--- .../README.p212 => doc/board/amlogic/p212.rst | 136 ++--- .../README.q200 => doc/board/amlogic/q200.rst | 136 ++--- .../s400/README => doc/board/amlogic/s400.rst | 150 +++--- .../README => doc/board/amlogic/sei510.rst| 190 - .../README => doc/board/amlogic/sei610.rst| 185 + .../u200/README => doc/board/amlogic/u200.rst | 188 - .../README.w400 => doc/board/amlogic/w400.rst | 192 +- doc/board/index.rst | 1 + 30 files changed, 1502 insertions(+), 1369 deletions(-) create mode 100644 doc/board/amlogic/index.rst rename board/amlogic/p212/README.khadas-vim => doc/board/amlogic/khadas-vim.rst (24%) rename board/amlogic/q200/README.khadas-vim2 => doc/board/amlogic/khadas-vim2.rst (26%) rename board/amlogic/w400/README.khadas-vim3 => doc/board/amlogic/khadas-vim3.rst (20%) rename board/amlogic/w400/README.khadas-vim3l => doc/board/amlogic/khadas-vim3l.rst (19%) rename board/amlogic/p212/README.libretech-ac => doc/board/amlogic/libretech-ac.rst (21%) rename board/amlogic/p212/README.libretech-cc => doc/board/amlogic/libretech-cc.rst (46%) rename board/amlogic/p200/README.nanopi-k2 => doc/board/amlogic/nanopi-k2.rst (24%) rename board/amlogic/p200/README.odroid-c2 => doc/board/amlogic/odroid-c2.rst (56%) rename board/amlogic/w400/README.odroid-n2 => doc/board/amlogic/odroid-n2.rst (19%) rename board/amlogic/p200/README.p200 => doc/board/amlogic/p200.rst (24%) rename board/amlogic/p201/README.p201 => doc/board/amlogic/p201.rst (24%) rename board/amlogic/p212/README.p212 => doc/board/amlogic/p212.rst (24%) rename board/amlogic/q200/README.q200 => doc/board/amlogic/q200.rst (24%) rename board/amlogic/s400/README => doc/board/amlogic/s400.rst (21%) rename board/amlogic/sei510/README => doc/board/amlogic/sei510.rst (14%) rename board/amlogic/sei610/README => doc/board/amlogic/sei610.rst (16%) rename board/amlogic/u200/README => doc/board/amlogic/u200.rst (17%) rename board/amlogic/w400/README.w400 => doc/board/amlogic/w400.rst (17%) -- 2.22.0
Re: Update of dts files for U-Boot for i.MX
On Thu, Jun 11, 2020 at 12:43:21PM +, Peng Fan wrote: > Hi Tom, > > > Subject: Update of dts files for U-Boot for i.MX > > > > Hey, > > > > Can we please get the various i.MX dts files (and related) re-synced with > > the > > kernel? In looking at the various dts warnings we see in our build, even on > > something like i.MX7 we see warnings because our dts files are out of sync > > with linux and so have warnings that have since been fixed upstream. > > For i.MX6/7/8M dts, I could give a check. > For i.MX8QM/QXP, I could leave it as is for now. There is a major update > ongoing > in Linux kernel for the dts part. OK, thanks. -- Tom signature.asc Description: PGP signature
RE: Update of dts files for U-Boot for i.MX
Hi Tom, > Subject: Update of dts files for U-Boot for i.MX > > Hey, > > Can we please get the various i.MX dts files (and related) re-synced with the > kernel? In looking at the various dts warnings we see in our build, even on > something like i.MX7 we see warnings because our dts files are out of sync > with linux and so have warnings that have since been fixed upstream. For i.MX6/7/8M dts, I could give a check. For i.MX8QM/QXP, I could leave it as is for now. There is a major update ongoing in Linux kernel for the dts part. Thanks, Peng. > Thanks! > > -- > Tom
RE: [PATCH 28/30] spi: Enable missing CONFIG_SPL_DM_SPI support
Dear Tom > From: Tom Rini > Sent: mercredi 10 juin 2020 22:17 > > Due to how the Makefile logic is we currently get DM_SPI support in SPL > enabled > by having DM_SPI enabled for full U-Boot but not having CONFIG_SPL_DM_SPI > set. Add this missing option to boards that were inadvertently making use of > it. > > Cc: Adam Ford > Cc: Akash Gajjar > Cc: Anatolij Gustschin > Cc: Andy Yan > Cc: Anup Patel > Cc: Atish Patra > Cc: Bin Meng > Cc: Chee Hong Ang > Cc: Chin-Liang See > Cc: Dalon Westergreen > Cc: Dinh Nguyen > Cc: Eugen Hristev > Cc: Hannes Schmelzer > Cc: Heiko Schocher > Cc: Jagan Teki > Cc: Klaus Goger > Cc: Levin Du > Cc: Ley Foon Tan > Cc: Lokesh Vutla > Cc: Luca Ceresoli > Cc: Marek Vasut > Cc: Michal Simek > Cc: Mike Looijmans > Cc: Nicolas Ferre > Cc: Nikita Kiryanov > Cc: Palmer Dabbelt > Cc: Patrick Delaunay > Cc: Paul Walmsley > Cc: Pavel Machek > Cc: Peter Robinson > Cc: Philipp Tomsich > Cc: Simon Glass > Cc: Stefan Roese > Cc: Suniel Mahesh > Cc: Wolfgang Grandegger > Signed-off-by: Tom Rini > --- > configs/am57xx_evm_defconfig | 1 + > configs/am57xx_hs_evm_defconfig| 1 + > configs/am57xx_hs_evm_usb_defconfig| 1 + > configs/am65x_evm_a53_defconfig| 1 + > configs/am65x_evm_r5_defconfig | 1 + > configs/am65x_hs_evm_a53_defconfig | 1 + > configs/am65x_hs_evm_r5_defconfig | 1 + > configs/avnet_ultrazedev_cc_v1_0_ultrazedev_som_v1_0_defconfig | 1 + > configs/axm_defconfig | 1 + > configs/brppt1_spi_defconfig | 1 + > configs/brsmarc1_defconfig | 1 + > configs/chromebit_mickey_defconfig | 1 + > configs/chromebook_bob_defconfig | 1 + > configs/chromebook_coral_defconfig | 1 + > configs/chromebook_jerry_defconfig | 1 + > configs/chromebook_link64_defconfig| 1 + > configs/chromebook_minnie_defconfig| 1 + > configs/chromebook_samus_tpl_defconfig | 1 + > configs/chromebook_speedy_defconfig| 1 + > configs/cm_t43_defconfig | 1 + > configs/da850evm_defconfig | 1 + > configs/da850evm_nand_defconfig| 1 + > configs/dra7xx_evm_defconfig | 1 + > configs/dra7xx_hs_evm_defconfig| 1 + > configs/dra7xx_hs_evm_usb_defconfig| 1 + > configs/evb-px5_defconfig | 1 + > configs/j721e_evm_a72_defconfig| 1 + > configs/j721e_evm_r5_defconfig | 1 + > configs/j721e_hs_evm_a72_defconfig | 1 + > configs/j721e_hs_evm_r5_defconfig | 1 + > configs/lion-rk3368_defconfig | 1 + > configs/pinebook-pro-rk3399_defconfig | 1 + > configs/puma-rk3399_defconfig | 1 + > configs/qemu-x86_64_defconfig | 1 + > configs/roc-pc-mezzanine-rk3399_defconfig | 1 + > configs/roc-pc-rk3399_defconfig| 1 + > configs/rockpro64-rk3399_defconfig | 1 + > configs/sama5d27_wlsom1_ek_qspiflash_defconfig | 1 + > configs/sama5d2_xplained_spiflash_defconfig| 1 + > configs/sama5d3xek_spiflash_defconfig | 1 + > configs/sama5d4_xplained_spiflash_defconfig| 1 + > configs/sama5d4ek_spiflash_defconfig | 1 + > configs/sifive_fu540_defconfig | 1 + > configs/socfpga_agilex_defconfig | 1 + > configs/socfpga_arria10_defconfig | 1 + > configs/socfpga_arria5_defconfig | 1 + > configs/socfpga_cyclone5_defconfig | 1 + > configs/socfpga_dbm_soc1_defconfig | 1 + > configs/socfpga_de0_nano_soc_defconfig | 1 + > configs/socfpga_de10_nano_defconfig| 1 + > configs/socfpga_de1_soc_defconfig | 1 + > configs/socfpga_is1_defconfig | 1 + > configs/socfpga_mcvevk_defconfig | 1 + > configs/socfpga_sockit_defconfig | 1 + >
Re: [PATCH 28/30] spi: Enable missing CONFIG_SPL_DM_SPI support
On Thu, Jun 11, 2020 at 05:38:15AM -0500, Adam Ford wrote: > On Wed, Jun 10, 2020 at 3:17 PM Tom Rini wrote: > > > > Due to how the Makefile logic is we currently get DM_SPI support in SPL > > enabled by having DM_SPI enabled for full U-Boot but not having > > CONFIG_SPL_DM_SPI set. Add this missing option to boards that were > > inadvertently making use of it. > > Not knowing exactly which patches to apply to see the Makefile changes > in question, I'm just doing a code review instead of the test. > > > > Cc: Adam Ford > [snip] > > Acked-by: Adam Ford #da850evm > > > Signed-off-by: Tom Rini > > --- > > > configs/da850evm_defconfig | 1 + > > configs/da850evm_nand_defconfig| 1 + > > The da850evm_defconfig is setup to boot from SPI Flash, so that board > will need it. Thank you. > > The da850evm_nand_defconfig is set to boot from NAND via the NAND > controller and not SPI, so it's probably not necessary, but I don't > think it hurts anything. I may go through later and remove the > CONFIG_SPL_DM_SPI from the nand version later. > > [snip] > > > diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig > > index 1a6a97ed161a..12768065f3ab 100644 > > --- a/configs/da850evm_defconfig > > +++ b/configs/da850evm_defconfig > > @@ -12,6 +12,7 @@ CONFIG_ENV_OFFSET=0x8 > > CONFIG_ENV_SECT_SIZE=0x1 > > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 > > CONFIG_DM_GPIO=y > > +CONFIG_SPL_DM_SPI=y > > Thank you, we'll need this. > > > CONFIG_SPL_SERIAL_SUPPORT=y > > CONFIG_NR_DRAM_BANKS=1 > > CONFIG_SPL=y > > diff --git a/configs/da850evm_nand_defconfig > > b/configs/da850evm_nand_defconfig > > index e805f2c10eda..13026fd1ea2c 100644 > > --- a/configs/da850evm_nand_defconfig > > +++ b/configs/da850evm_nand_defconfig > > @@ -11,6 +11,7 @@ CONFIG_ENV_SIZE=0x2 > > CONFIG_ENV_OFFSET=0x0 > > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 > > CONFIG_DM_GPIO=y > > +CONFIG_SPL_DM_SPI=y > > If you do a V2 for some reason and don't want to add this here in the > future, I wouldn't object. If not, I'll do some testing later with > this removed. This is similar to the socfpga case Marek pointed out. Today, the platforms are building with SPI support enabled and are implicitly getting SPL_DM_SPI enabled too http://patchwork.ozlabs.org/project/uboot/patch/20200610201634.8457-30-tr...@konsulko.com/ is the Makefile patch but it's just dropping in to the DM or not-DM side based on SPL/TPL_DM and not just DM in main U-Boot. -- Tom signature.asc Description: PGP signature
[PATCH v2 5/5] arm: qemu: override flash accessors to use virtualizable instructions
Some instructions in the ARM ISA have multiple output registers, such
as ldrd/ldp (load pair), where two registers are loaded from memory,
but also ldr with indexing, where the memory base register is incremented
as well when the value is loaded to the destination register.
MMIO emulation under KVM is based on using the architecturally defined
syndrome information that is provided when an exception is taken to the
hypervisor. This syndrome information describes whether the instruction
that triggered the exception is a load or a store, what the faulting
address was, and which register was the destination register.
This syndrome information can only describe one destination register, and
when the trapping instruction is one with multiple outputs, KVM throws an
error like
kvm [615929]: Data abort outside memslots with no valid syndrome info
on the host and kills the QEMU process with the following error:
U-Boot 2020.07-rc3-00208-g88bd5b179360-dirty (Jun 06 2020 - 11:59:22 +0200)
DRAM: 1 GiB
Flash: error: kvm run failed Function not implemented
R00=0001 R01=0040 R02=7ee0ce20 R03=
R04=7ffd9eec R05=0004 R06=7ffda3f8 R07=0055
R08=7ffd9eec R09=7ef0ded0 R10=7ee0ce20 R11=
R12=0004 R13=7ee0cdf8 R14= R15=7ff72d08
PSR=21d3 --C- A svc32
QEMU: Terminated
This means that, in order to run U-Boot in QEMU under KVM, we need to
avoid such instructions when accessing emulated devices. For the flash
in particular, which is a hybrid between a ROM (backed by a read-only
KVM memslot) when in array mode, and an emulated MMIO device (when in
write mode), we need to take care to only use instructions that KVM can
deal with when they trap.
So override the flash read accessors that are used when running on QEMU
under KVM. Note that the the 64-bit wide read accessors and all the write
accessors have been omitted: they are either never used to begin with, or
don't suffer from the MMIO emulation issue (as str instructions don't have
multiple output registers)
Signed-off-by: Ard Biesheuvel
---
board/emulation/qemu-arm/qemu-arm.c | 30
include/configs/qemu-arm.h | 1 +
2 files changed, 31 insertions(+)
diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
index 1b0d543b93c1..524e302001ec 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -142,3 +142,33 @@ efi_status_t platform_get_rng_device(struct udevice **dev)
return EFI_SUCCESS;
}
#endif /* CONFIG_EFI_RNG_PROTOCOL */
+
+#ifdef CONFIG_ARM64
+#define __W"w"
+#else
+#define __W
+#endif
+
+u8 flash_read8(void *addr)
+{
+ u8 ret;
+
+ asm("ldrb %" __W "0, %1" : "=r"(ret) : "m"(*(u8 *)addr));
+ return ret;
+}
+
+u16 flash_read16(void *addr)
+{
+ u16 ret;
+
+ asm("ldrh %" __W "0, %1" : "=r"(ret) : "m"(*(u16 *)addr));
+ return ret;
+}
+
+u32 flash_read32(void *addr)
+{
+ u32 ret;
+
+ asm("ldr %" __W "0, %1" : "=r"(ret) : "m"(*(u32 *)addr));
+ return ret;
+}
diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
index 1ef75a87836b..bc8b7c5c1238 100644
--- a/include/configs/qemu-arm.h
+++ b/include/configs/qemu-arm.h
@@ -53,5 +53,6 @@
#define CONFIG_SYS_MAX_FLASH_BANKS 2
#endif
#define CONFIG_SYS_MAX_FLASH_SECT 256 /* Sector: 256K, Bank: 64M */
+#define CONFIG_CFI_FLASH_USE_WEAK_ACCESSORS
#endif /* __CONFIG_H */
--
2.26.2
Re: [PATCH 28/30] spi: Enable missing CONFIG_SPL_DM_SPI support
On Wed, Jun 10, 2020 at 3:17 PM Tom Rini wrote: > > Due to how the Makefile logic is we currently get DM_SPI support in SPL > enabled by having DM_SPI enabled for full U-Boot but not having > CONFIG_SPL_DM_SPI set. Add this missing option to boards that were > inadvertently making use of it. Not knowing exactly which patches to apply to see the Makefile changes in question, I'm just doing a code review instead of the test. > > Cc: Adam Ford [snip] Acked-by: Adam Ford #da850evm > Signed-off-by: Tom Rini > --- > configs/da850evm_defconfig | 1 + > configs/da850evm_nand_defconfig| 1 + The da850evm_defconfig is setup to boot from SPI Flash, so that board will need it. Thank you. The da850evm_nand_defconfig is set to boot from NAND via the NAND controller and not SPI, so it's probably not necessary, but I don't think it hurts anything. I may go through later and remove the CONFIG_SPL_DM_SPI from the nand version later. [snip] > diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig > index 1a6a97ed161a..12768065f3ab 100644 > --- a/configs/da850evm_defconfig > +++ b/configs/da850evm_defconfig > @@ -12,6 +12,7 @@ CONFIG_ENV_OFFSET=0x8 > CONFIG_ENV_SECT_SIZE=0x1 > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 > CONFIG_DM_GPIO=y > +CONFIG_SPL_DM_SPI=y Thank you, we'll need this. > CONFIG_SPL_SERIAL_SUPPORT=y > CONFIG_NR_DRAM_BANKS=1 > CONFIG_SPL=y > diff --git a/configs/da850evm_nand_defconfig b/configs/da850evm_nand_defconfig > index e805f2c10eda..13026fd1ea2c 100644 > --- a/configs/da850evm_nand_defconfig > +++ b/configs/da850evm_nand_defconfig > @@ -11,6 +11,7 @@ CONFIG_ENV_SIZE=0x2 > CONFIG_ENV_OFFSET=0x0 > CONFIG_SYS_SPI_U_BOOT_OFFS=0x8000 > CONFIG_DM_GPIO=y > +CONFIG_SPL_DM_SPI=y If you do a V2 for some reason and don't want to add this here in the future, I wouldn't object. If not, I'll do some testing later with this removed. > CONFIG_SPL_SERIAL_SUPPORT=y > CONFIG_SPL=y > CONFIG_SPL_SPI_FLASH_SUPPORT=y [snip] > -- > 2.17.1 >
[PATCH v2 3/5] arm: qemu: implement enable_caches()
Add an override for enable_caches to enable the I and D caches, along
with the cached 1:1 mapping of all of DRAM. This is needed for running
U-Boot under virtualization with QEMU/kvm.
Signed-off-by: Ard Biesheuvel
---
board/emulation/qemu-arm/qemu-arm.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/board/emulation/qemu-arm/qemu-arm.c
b/board/emulation/qemu-arm/qemu-arm.c
index 69e8ef46f1f5..1b0d543b93c1 100644
--- a/board/emulation/qemu-arm/qemu-arm.c
+++ b/board/emulation/qemu-arm/qemu-arm.c
@@ -4,6 +4,7 @@
*/
#include
+#include
#include
#include
#include
@@ -94,6 +95,12 @@ void *board_fdt_blob_setup(void)
return (void *)CONFIG_SYS_SDRAM_BASE;
}
+void enable_caches(void)
+{
+icache_enable();
+dcache_enable();
+}
+
#if defined(CONFIG_EFI_RNG_PROTOCOL)
#include
#include
--
2.26.2
[PATCH v2 4/5] arm: qemu: disable the EFI workaround for older GRUB
The QEMU/mach-virt targeted port of u-boot currently only runs on QEMU under TCG emulation, which does not model the caches at all, and so no users can exist that are relying on the GRUB hack for EFI boot. We will shortly enable support for running under KVM, but the GRUB hack (which disables all caches without doing cache cleaning by VA during ExitBootServices()) is likely to cause more problems than it solves, given that KVM hosts require correct maintenance if they incorporate non-architected system caches. So let's disable the GRUB hack by default on the QEMU/mach-virt port. Signed-off-by: Ard Biesheuvel Reviewed-by: Heinrich Schuchardt --- configs/qemu_arm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig index 75bdce7708c7..1d2b4437cb07 100644 --- a/configs/qemu_arm_defconfig +++ b/configs/qemu_arm_defconfig @@ -47,3 +47,4 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_PCI=y +# CONFIG_EFI_GRUB_ARM32_WORKAROUND is not set -- 2.26.2
[PATCH v2 2/5] arm: qemu: enable LPAE on 32-bit
QEMU's mach-virt machine only supports selecting CPU models that implement the virtualization extensions, and are therefore guaranteed to support LPAE as well. Initially, QEMU would not allow emulating these CPUs running in HYP mode (or EL2, for AArch64), but today, it also contains a complete implementation of the virtualization extensions themselves. This means we could be running U-Boot in HYP mode, in which case the LPAE long descriptor page table format is the only format that is supported. If we are not running in HYP mode, we can use either. So let's enable CONFIG_ARMV7_LPAE for qemu_arm_defconfig so that we get the best support for running with the MMU and caches enabled at any privilege level. Signed-off-by: Ard Biesheuvel Acked-by: Heinrich Schuchardt --- configs/qemu_arm_defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig index a8473988bd76..75bdce7708c7 100644 --- a/configs/qemu_arm_defconfig +++ b/configs/qemu_arm_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_ARM_SMCCC=y +CONFIG_ARMV7_LPAE=y CONFIG_ARCH_QEMU=y CONFIG_ENV_SIZE=0x4 CONFIG_ENV_SECT_SIZE=0x4 -- 2.26.2
[PATCH v2 1/5] arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH
The LPAE versions of DCACHE_WRITEBACK and DCACHE_WRITETHROUGH are currently
defined as no-allocate for both reads and writes, which deviates from the
non-LPAE definition, and mostly defeats the purpose of enabling the caches
in the first place.
So align LPAE with !LPAE, and enable allocate-on-read for both. And while
at it, add some clarification about the meaning of the chosen values.
Signed-off-by: Ard Biesheuvel
---
arch/arm/include/asm/system.h | 23
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 7a40b56acdca..3a1501a0623c 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -442,10 +442,16 @@ static inline void set_dacr(unsigned int val)
#define TTBCR_EPD0 (0 << 7)
/*
- * Memory types
+ * VMSAv8-32 Long-descriptor format memory region attributes
+ * (ARM Architecture Reference Manual section G5.7.4 [DDI0487E.a])
+ *
+ * MAIR0[ 7: 0] 0x00 Device-nGnRnE (aka Strongly-Ordered)
+ * MAIR0[15: 8] 0xaa Outer/Inner Write-Through, Read-Allocate No Write-Allocate
+ * MAIR0[23:16] 0xee Outer/Inner Write-Back, Read-Allocate No Write-Allocate
+ * MAIR0[31:24] 0xff Outer/Inner Write-Back, Read-Allocate Write-Allocate
*/
-#define MEMORY_ATTRIBUTES ((0x00 << (0 * 8)) | (0x88 << (1 * 8)) | \
-(0xcc << (2 * 8)) | (0xff << (3 * 8)))
+#define MEMORY_ATTRIBUTES ((0x00 << (0 * 8)) | (0xaa << (1 * 8)) | \
+(0xee << (2 * 8)) | (0xff << (3 * 8)))
/* options available for data cache on each page */
enum dcache_option {
@@ -468,7 +474,16 @@ enum dcache_option {
#define TTB_SECT_B_MASK(1 << 2)
#define TTB_SECT (2 << 0)
-/* options available for data cache on each page */
+/*
+ * Short-descriptor format memory region attributes, without TEX remap
+ * (ARM Architecture Reference Manual section G5.7.2 [DDI0487E.a])
+ *
+ * TEX[0] C B
+ * 00 0 Device-nGnRnE (aka Strongly-Ordered)
+ * 01 0 Outer/Inner Write-Through, Read-Allocate No Write-Allocate
+ * 01 1 Outer/Inner Write-Back, Read-Allocate No Write-Allocate
+ * 11 1 Outer/Inner Write-Back, Read-Allocate Write-Allocate
+ */
enum dcache_option {
DCACHE_OFF = TTB_SECT_DOMAIN(0) | TTB_SECT_XN_MASK | TTB_SECT,
DCACHE_WRITETHROUGH = DCACHE_OFF | TTB_SECT_C_MASK,
--
2.26.2
[PATCH v2 0/5] Fixes for running U-boot under QEMU/KVM
This series fixes a number of issues that exist in the QEMU/mach-virt port of u-boot, and that prevent it from executing correctly under virtualization (as opposed to TCG emulation) As the Linux EFI subsystem maintainer, I am looking to increase test coverage for the EFI related changes that are under development for Linux, and one of the things I plan to do is start using U-boot as test firmware for boot testing. This can be done under TCG emulation, but given how loosely TCG implements the architecture, it is better to test under virtualization as well. With these changes applied, u-boot can boot Linux in EFI mode under KVM. Changes since v1: - fix LPAE memory type for DCACHE_WRITETHROUGH as well, and add some comments to clarify what the values are based on (patch #1) - only override the flash accessors that we need to (patch #5) - add Heinrich's ack to #2 and #4 Cc: Tom Rini Cc: Andre Przywara Cc: Heinrich Schuchardt Cc: Tuomas Tynkkynen Ard Biesheuvel (5): arm: enable allocate-on-read for LPAE's DCACHE_WRITEBACK/_WRITETHROUGH arm: qemu: enable LPAE on 32-bit arm: qemu: implement enable_caches() arm: qemu: disable the EFI workaround for older GRUB arm: qemu: override flash accessors to use virtualizable instructions arch/arm/include/asm/system.h | 23 +--- board/emulation/qemu-arm/qemu-arm.c | 37 configs/qemu_arm_defconfig | 2 ++ include/configs/qemu-arm.h | 1 + 4 files changed, 59 insertions(+), 4 deletions(-) -- 2.26.2
Re: [EXT] [PATCH 24/30] arm: imx: Finish migration of CONFIG_CSF_SIZE to Kconfig
On Thu, Jun 11, 2020 at 05:28:45AM +, Ye Li wrote:
> Hi Tom,
>
> > -Original Message-
> > From: Tom Rini
> > Sent: 2020年6月11日 4:16
> > To: u-boot@lists.denx.de
> > Cc: Stefano Babic ; Fabio Estevam
> > ; dl-uboot-imx
> > Subject: [EXT] [PATCH 24/30] arm: imx: Finish migration of CONFIG_CSF_SIZE
> > to Kconfig
> >
> > Caution: EXT Email
> >
> > While the normal case of CSF_SIZE is handled via Kconfig we have entries in
> > config headers related to CONFIG_SECURE_BOOT. However in commit
> > d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with
> > CONFIG_IMX_HAB") this was renamed to CONFIG_IMX_HAB. Update the
> > CSF_SIZE entry to have the correct default value if we have IMX_HAB
> > enabled.
> >
> > Cc: Stefano Babic
> > Cc: Fabio Estevam
> > Cc: NXP i.MX U-Boot Team
> > Fixes: d714a75fd4dc ("imx: replace CONFIG_SECURE_BOOT with
> > CONFIG_IMX_HAB")
> > Signed-off-by: Tom Rini
> > ---
> > arch/arm/mach-imx/Kconfig | 1 +
> > include/configs/imx8mm_beacon.h | 4
> > include/configs/imx8mm_evk.h| 4
> > include/configs/imx8mn_evk.h| 4
> > include/configs/imx8mp_evk.h| 4
> > include/configs/verdin-imx8mm.h | 4
> > 6 files changed, 1 insertion(+), 20 deletions(-)
> >
> > diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index
> > 6c3fedf665d6..0648c2725bf8 100644
> > --- a/arch/arm/mach-imx/Kconfig
> > +++ b/arch/arm/mach-imx/Kconfig
> > @@ -52,6 +52,7 @@ config IMX_HAB
> >
> > config CSF_SIZE
> > hex "Maximum size for Command Sequence File (CSF) binary"
> > + default 0x2000 if IMX_HAB
> I suggest using "default 0x2000 if ARCH_IMX8M", because i.MX6/7 may also
> enable IMX_HAB.
So ARCH_IMX8M && IMX_HAB? I would have expected the CSF size to be
limited in all cases from the default value due to something security
related eating up that 0x60 in overhead. Is that not the case? Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v2] common: fdt: Remove additional 4k space for fdt allocation
On 11. 06. 20 13:24, Marek Vasut wrote: > On 6/11/20 1:10 PM, Michal Simek wrote: >> From: Ashok Reddy Soma >> >> There is no technical reason to add additional 4k space for FDT. > > Could it be that this is needed for adjusting the FDT early on ? > It really depends how early. fdt_totalsize is called in reserve_fdt(). It means if this is done before then you are working with already updated size and there is no need to add any space. And switch/copy is done by reloc_fdt from board_f.c. And in your case it is really question if 4k additional is enough. Because you can have a need to use more then 4k. Thanks, Michal
[v2 3/3] configs: lx2160a: Enable Watchdog support
From: Zhao Qiang Enable support to compile SBSA driver. Signed-off-by: Zhao Qiang --- Change in v2: - none configs/lx2160aqds_tfa_defconfig | 3 +++ configs/lx2160ardb_tfa_defconfig | 3 +++ 2 files changed, 6 insertions(+) diff --git a/configs/lx2160aqds_tfa_defconfig b/configs/lx2160aqds_tfa_defconfig index 716c089..93e6a05 100644 --- a/configs/lx2160aqds_tfa_defconfig +++ b/configs/lx2160aqds_tfa_defconfig @@ -29,6 +29,7 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y +CONFIG_CMD_WDT=y CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y @@ -82,4 +83,6 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_WDT=y +CONFIG_WDT_SBSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y diff --git a/configs/lx2160ardb_tfa_defconfig b/configs/lx2160ardb_tfa_defconfig index bc654cf..8504a50 100644 --- a/configs/lx2160ardb_tfa_defconfig +++ b/configs/lx2160ardb_tfa_defconfig @@ -30,6 +30,7 @@ CONFIG_CMD_I2C=y CONFIG_CMD_MMC=y CONFIG_CMD_PCI=y CONFIG_CMD_USB=y +CONFIG_CMD_WDT=y CONFIG_CMD_CACHE=y CONFIG_MP=y CONFIG_OF_CONTROL=y @@ -76,4 +77,6 @@ CONFIG_USB=y CONFIG_DM_USB=y CONFIG_USB_XHCI_HCD=y CONFIG_USB_XHCI_DWC3=y +CONFIG_WDT=y +CONFIG_WDT_SBSA=y CONFIG_EFI_LOADER_BOUNCE_BUFFER=y -- 2.7.4
[v2 1/3] Watchdog: introduce ARM SBSA watchdog driver
From: Zhao Qiang
According to Server Base System Architecture (SBSA) specification,
the SBSA Generic Watchdog has two stage timeouts: the first signal
(WS0) is for alerting the system by interrupt, the second one (WS1) is a
real hardware reset.
More details about the hardware specification of this device:
ARM DEN0029B - Server Base System Architecture (SBSA)
This driver can operate ARM SBSA Generic Watchdog as a single stage
In the single stage mode, when the timeout is reached, your system
will be reset by WS1. The first signal (WS0) is ignored.
Signed-off-by: Zhao Qiang
Signed-off-by: Biwen Li
---
Change in v2:
- fix copyright
MAINTAINERS | 1 +
drivers/watchdog/Kconfig | 6 ++
drivers/watchdog/Makefile| 1 +
drivers/watchdog/sbsa_gwdt.c | 131 +++
4 files changed, 139 insertions(+)
create mode 100644 drivers/watchdog/sbsa_gwdt.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 1fd975c..09554c0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -685,6 +685,7 @@ M: Priyanka Jain
S: Maintained
T: git https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git
F: drivers/watchdog/sp805_wdt.c
+F: drivers/watchdog/sbsa_gwdt.c
I2C
M: Heiko Schocher
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index bf06180..191891c 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -163,6 +163,12 @@ config WDT_SANDBOX
can be probed and supports all of the methods of WDT, but does not
really do anything.
+config WDT_SBSA
+ bool "SBSA watchdog timer support"
+ depends on WDT
+ help
+ Select this to enable SBSA watchdog timer.
+
config WDT_SP805
bool "SP805 watchdog timer support"
depends on WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 519bbd3..0f0b2eb 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -27,6 +27,7 @@ obj-$(CONFIG_WDT_MPC8xx) += mpc8xx_wdt.o
obj-$(CONFIG_WDT_MT7621) += mt7621_wdt.o
obj-$(CONFIG_WDT_MTK) += mtk_wdt.o
obj-$(CONFIG_WDT_OMAP3) += omap_wdt.o
+obj-$(CONFIG_WDT_SBSA) += sbsa_gwdt.o
obj-$(CONFIG_WDT_SP805) += sp805_wdt.o
obj-$(CONFIG_WDT_STM32MP) += stm32mp_wdt.o
obj-$(CONFIG_WDT_TANGIER) += tangier_wdt.o
diff --git a/drivers/watchdog/sbsa_gwdt.c b/drivers/watchdog/sbsa_gwdt.c
new file mode 100644
index 000..ddac668
--- /dev/null
+++ b/drivers/watchdog/sbsa_gwdt.c
@@ -0,0 +1,131 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Watchdog driver for SBSA
+ *
+ * Copyright 2020 NXP
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* SBSA Generic Watchdog register definitions */
+/* refresh frame */
+#define SBSA_GWDT_WRR 0x000
+
+/* control frame */
+#define SBSA_GWDT_WCS 0x000
+#define SBSA_GWDT_WOR 0x008
+#define SBSA_GWDT_WCV 0x010
+
+/* refresh/control frame */
+#define SBSA_GWDT_W_IIDR 0xfcc
+#define SBSA_GWDT_IDR 0xfd0
+
+/* Watchdog Control and Status Register */
+#define SBSA_GWDT_WCS_EN BIT(0)
+#define SBSA_GWDT_WCS_WS0 BIT(1)
+#define SBSA_GWDT_WCS_WS1 BIT(2)
+
+struct sbsa_gwdt_priv {
+ void __iomem *reg_refresh;
+ void __iomem *reg_control;
+};
+
+static int sbsa_gwdt_reset(struct udevice *dev)
+{
+ struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+
+ writel(0, priv->reg_refresh + SBSA_GWDT_WRR);
+
+ return 0;
+}
+
+static int sbsa_gwdt_start(struct udevice *dev, u64 timeout, ulong flags)
+{
+ u32 clk;
+ u32 load_value;
+
+ struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+ /*
+* it work in the single stage mode in u-boot,
+* The first signal (WS0) is ignored,
+* the timeout is (WOR * 2), so the WOR should be configured
+* to half value of timeout.
+*/
+ clk = get_tbclk();
+ writel(clk / 2 * timeout,
+ priv->reg_control + SBSA_GWDT_WOR);
+
+ /* writing WCS will cause an explicit watchdog refresh */
+ writel(SBSA_GWDT_WCS_EN, priv->reg_control + SBSA_GWDT_WCS);
+
+ return 0;
+}
+
+static int sbsa_gwdt_stop(struct udevice *dev)
+{
+ struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+
+ writel(0, priv->reg_control + SBSA_GWDT_WCS);
+
+ return 0;
+}
+
+static int sbsa_gwdt_expire_now(struct udevice *dev, ulong flags)
+{
+ sbsa_gwdt_start(dev, 0, flags);
+
+ return 0;
+}
+
+static int sbsa_gwdt_probe(struct udevice *dev)
+{
+ debug("%s: Probing wdt%u (sbsa-gwdt)\n", __func__, dev->seq);
+
+ return 0;
+}
+
+static int sbsa_gwdt_ofdata_to_platdata(struct udevice *dev)
+{
+ struct sbsa_gwdt_priv *priv = dev_get_priv(dev);
+
+ priv->reg_control = (void __iomem *)dev_read_addr_index(dev, 0);
+ if (IS_ERR(priv->reg_control))
+ return PTR_ERR(priv->reg_control);
+
+
[v2 2/3] arm64: lx2160a: dts: Add watchdog node
From: Zhao Qiang
Add watchdog node which is sbsa into lx2160a dtsi
Signed-off-by: Zhao Qiang
---
Change in v2:
- none
arch/arm/dts/fsl-lx2160a.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/dts/fsl-lx2160a.dtsi b/arch/arm/dts/fsl-lx2160a.dtsi
index 1789da8..a2421f6 100644
--- a/arch/arm/dts/fsl-lx2160a.dtsi
+++ b/arch/arm/dts/fsl-lx2160a.dtsi
@@ -204,6 +204,13 @@
#interrupt-cells = <2>;
};
+ watchdog@23a {
+ compatible = "arm,sbsa-gwdt";
+ reg = <0x0 0x23a 0 0x1000>,
+ <0x0 0x239 0 0x1000>;
+ timeout-sec = <30>;
+ };
+
usb0: usb3@310 {
compatible = "fsl,layerscape-dwc3";
reg = <0x0 0x310 0x0 0x1>;
--
2.7.4
Re: [PATCH v2] common: fdt: Remove additional 4k space for fdt allocation
On 6/11/20 1:10 PM, Michal Simek wrote: > From: Ashok Reddy Soma > > There is no technical reason to add additional 4k space for FDT. Could it be that this is needed for adjusting the FDT early on ?
[PATCH v2] common: fdt: Remove additional 4k space for fdt allocation
From: Ashok Reddy Soma
There is no technical reason to add additional 4k space for FDT. This space
is completely unused and just increase memory requirements. This is
problematic on systems with limited memory resources as Xilinx Zynq
CSE/ZynqMP mini and Versal mini configurations.
The patch is removing additional 4k space and also increasing alignment to
64 to be aligned with 64bit systems.
EFI code is using copy_fdt() which copy FDT to different location.
And all boot commands in case of using U-Boot's FDT pointed by
$fdtcontroladdr are copying FDT to different locations by
image_setup_libfdt().
That's why in proper flow none should modified DTB used by U-Boot that's
why there is no need for additional space.
Signed-off-by: Ashok Reddy Soma
Signed-off-by: Michal Simek
---
Changes in v2:
- Change subject (was: common: Add Kconfig option for FDT mem alignment)
- Remove Kconfig symbol
- Extend description
I have tested it on zcu104
---
common/board_f.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/common/board_f.c b/common/board_f.c
index 01194eaa0e4d..7e99b2425a62 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -537,7 +537,7 @@ static int reserve_fdt(void)
* will be relocated with other data.
*/
if (gd->fdt_blob) {
- gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32);
+ gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob), 64);
gd->start_addr_sp = reserve_stack_aligned(gd->fdt_size);
gd->new_fdt = map_sysmem(gd->start_addr_sp, gd->fdt_size);
--
2.27.0
Re: [PATCH 3/7] net: smc911x: Properly handle EEPROM MAC address
On Thu, Jun 11, 2020 at 2:05 PM Andre Przywara wrote:
>
> When compiled as a DM_ETH driver, the scm911x driver was reading the MAC
> address from the optional EEPROM storage, but failed to copy this to the
> platdata struct. Since it was also missing a definition of the
> read_rom_hwaddr() function, the generic Ethernet code was dismissing
> this MAC address, falling back to a random address or denying to start
> at all.
>
> Add an implementation of .read_rom_hwaddr, and refactor the function
> reading the ROM address to be called by all interested parties.
>
> This fixes MAC address issues when using the driver in DM_ETH "mode".
>
> Signed-off-by: Andre Przywara
> ---
> drivers/net/smc911x.c | 60 ++-
> 1 file changed, 36 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
> index 9d2790e561..053ff9f4ff 100644
> --- a/drivers/net/smc911x.c
> +++ b/drivers/net/smc911x.c
> @@ -187,6 +187,26 @@ static void smc911x_handle_mac_address(struct
> smc911x_priv *priv)
> printf(DRIVERNAME ": MAC %pM\n", m);
> }
>
> +static bool smc911x_read_mac_address(struct smc911x_priv *priv)
> +{
> + u32 addrh, addrl;
> +
> + /* address is obtained from optional eeprom */
> + addrh = smc911x_get_mac_csr(priv, ADDRH);
> + addrl = smc911x_get_mac_csr(priv, ADDRL);
> + if (addrl == 0x && addrh == 0x)
> + return false;
> +
> + priv->enetaddr[0] = addrl;
> + priv->enetaddr[1] = addrl >> 8;
> + priv->enetaddr[2] = addrl >> 16;
> + priv->enetaddr[3] = addrl >> 24;
> + priv->enetaddr[4] = addrh;
> + priv->enetaddr[5] = addrh >> 8;
> +
> + return true;
> +}
> +
> static int smc911x_eth_phy_read(struct smc911x_priv *priv,
> u8 phy, u8 reg, u16 *val)
> {
> @@ -471,7 +491,6 @@ static int smc911x_recv(struct eth_device *dev)
>
> int smc911x_initialize(u8 dev_num, int base_addr)
> {
> - unsigned long addrl, addrh;
> struct smc911x_priv *priv;
> int ret;
>
> @@ -489,18 +508,8 @@ int smc911x_initialize(u8 dev_num, int base_addr)
> goto err_detect;
> }
>
> - addrh = smc911x_get_mac_csr(priv, ADDRH);
> - addrl = smc911x_get_mac_csr(priv, ADDRL);
> - if (!(addrl == 0x && addrh == 0x)) {
> - /* address is obtained from optional eeprom */
> - priv->enetaddr[0] = addrl;
> - priv->enetaddr[1] = addrl >> 8;
> - priv->enetaddr[2] = addrl >> 16;
> - priv->enetaddr[3] = addrl >> 24;
> - priv->enetaddr[4] = addrh;
> - priv->enetaddr[5] = addrh >> 8;
> + if (smc911x_read_mac_address(priv))
> memcpy(priv->dev.enetaddr, priv->enetaddr, 6);
> - }
>
> priv->dev.init = smc911x_init;
> priv->dev.halt = smc911x_halt;
> @@ -565,6 +574,19 @@ static int smc911x_recv(struct udevice *dev, int flags,
> uchar **packetp)
> return ret ? ret : -EAGAIN;
> }
>
> +static int smc911x_read_rom_hwaddr(struct udevice *dev)
> +{
> + struct smc911x_priv *priv = dev_get_priv(dev);
> + struct eth_pdata *pdata = dev_get_platdata(dev);
> +
> + if (!smc911x_read_mac_address(priv))
> + return -ENODEV;
> +
> + memcpy(pdata->enetaddr, priv->enetaddr, sizeof(pdata->enetaddr));
> +
> + return 0;
> +}
> +
> static int smc911x_bind(struct udevice *dev)
> {
> return device_set_name(dev, dev->name);
> @@ -573,7 +595,6 @@ static int smc911x_bind(struct udevice *dev)
> static int smc911x_probe(struct udevice *dev)
> {
> struct smc911x_priv *priv = dev_get_priv(dev);
> - unsigned long addrh, addrl;
> int ret;
>
> /* Try to detect chip. Will fail if not present. */
> @@ -581,17 +602,7 @@ static int smc911x_probe(struct udevice *dev)
> if (ret)
> return ret;
>
> - addrh = smc911x_get_mac_csr(priv, ADDRH);
> - addrl = smc911x_get_mac_csr(priv, ADDRL);
> - if (!(addrl == 0x && addrh == 0x)) {
> - /* address is obtained from optional eeprom */
> - priv->enetaddr[0] = addrl;
> - priv->enetaddr[1] = addrl >> 8;
> - priv->enetaddr[2] = addrl >> 16;
> - priv->enetaddr[3] = addrl >> 24;
> - priv->enetaddr[4] = addrh;
> - priv->enetaddr[5] = addrh >> 8;
> - }
> + smc911x_read_rom_hwaddr(dev);
>
> return 0;
> }
> @@ -612,6 +623,7 @@ static const struct eth_ops smc911x_ops = {
> .send = smc911x_send,
> .recv = smc911x_recv,
> .stop = smc911x_stop,
> + .read_rom_hwaddr = smc911x_read_rom_hwaddr,
> };
>
> static const struct udevice_id smc911x_ids[] = {
> --
> 2.17.5
>
Reviewed-By: Ramon Fried
Re: [PATCH 2/7] net: dm: Remove warning about EEPROM provided MAC address
On Thu, Jun 11, 2020 at 2:05 PM Andre Przywara wrote:
>
> Similar to patch 821fec0ceb3e ("net: remove scary warning about EEPROM
> provided MAC address") this removes the somewhat awkward "warning" on
> boards using DM_ETH:
> In many parts of the computing world having a unique MAC address
> sitting in some on-NIC storage is considered the normal case.
>
> If there is a properly provided MAC address (either from ROM or from DT),
> remove the warning to not scare the user unnecessarily.
>
> Signed-off-by: Andre Przywara
> ---
> net/eth-uclass.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/net/eth-uclass.c b/net/eth-uclass.c
> index 7f89f65c92..0d9b75a9a2 100644
> --- a/net/eth-uclass.c
> +++ b/net/eth-uclass.c
> @@ -560,8 +560,6 @@ static int eth_post_probe(struct udevice *dev)
> memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
> } else if (is_valid_ethaddr(pdata->enetaddr)) {
> eth_env_set_enetaddr_by_index("eth", dev->seq,
> pdata->enetaddr);
> - printf("\nWarning: %s using MAC address from %s\n",
> - dev->name, source);
> } else if (is_zero_ethaddr(pdata->enetaddr) ||
>!is_valid_ethaddr(pdata->enetaddr)) {
> #ifdef CONFIG_NET_RANDOM_ETHADDR
> --
> 2.17.5
>
Reviewed-By: Ramon Fried
[PATCH 6/7] arm: juno: Enable PCI
The ARM Juno boards in their -r1 and -r2 variants sport a PCIe
controller, which we configure already in board specific code to be ECAM
compliant. Hence we can just enable the generic ECAM driver to let
U-Boot use PCIe devices.
Add the respective options to the Juno defconfig to enable the PCI
framework and the generic ECAM driver, and initialise the driver upon
loading U-Boot.
Make some functions in the Juno PCIe init code static on the way.
Signed-off-by: Andre Przywara
---
board/armltd/vexpress64/pcie.c | 14 +-
configs/vexpress_aemv8a_juno_defconfig | 5 +
2 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/board/armltd/vexpress64/pcie.c b/board/armltd/vexpress64/pcie.c
index 02de58b360..733b190e59 100644
--- a/board/armltd/vexpress64/pcie.c
+++ b/board/armltd/vexpress64/pcie.c
@@ -72,9 +72,9 @@
JUNO_RESET_STATUS_PHY | \
JUNO_RESET_STATUS_RC)
-void xr3pci_set_atr_entry(unsigned long base, unsigned long src_addr,
- unsigned long trsl_addr, int window_size,
- int trsl_param)
+static void xr3pci_set_atr_entry(unsigned long base, unsigned long src_addr,
+unsigned long trsl_addr, int window_size,
+int trsl_param)
{
/* X3PCI_ATR_SRC_ADDR_LOW:
- bit 0: enable entry,
@@ -94,7 +94,7 @@ void xr3pci_set_atr_entry(unsigned long base, unsigned long
src_addr,
((u64)1) << window_size, trsl_param);
}
-void xr3pci_setup_atr(void)
+static void xr3pci_setup_atr(void)
{
/* setup PCIe to CPU address translation tables */
unsigned long base = XR3_CONFIG_BASE + XR3PCI_ATR_PCIE_WIN0;
@@ -141,7 +141,7 @@ void xr3pci_setup_atr(void)
XR3_PCI_MEMSPACE64_SIZE,
XR3PCI_ATR_TRSLID_PCIE_MEMORY);
}
-void xr3pci_init(void)
+static void xr3pci_init(void)
{
u32 val;
int timeout = 200;
@@ -193,5 +193,9 @@ void xr3pci_init(void)
void vexpress64_pcie_init(void)
{
+ /* Initialise and configure the PCIe host bridge. */
xr3pci_init();
+
+ /* Register the now ECAM complaint PCIe host controller with U-Boot. */
+ pci_init();
}
diff --git a/configs/vexpress_aemv8a_juno_defconfig
b/configs/vexpress_aemv8a_juno_defconfig
index 49acb34310..4866a0e9d5 100644
--- a/configs/vexpress_aemv8a_juno_defconfig
+++ b/configs/vexpress_aemv8a_juno_defconfig
@@ -32,6 +32,11 @@ CONFIG_CMD_UBI=y
# CONFIG_ISO_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
CONFIG_OF_BOARD=y
+CONFIG_PCI=y
+CONFIG_DM_PCI=y
+CONFIG_PCIE_ECAM_GENERIC=y
+CONFIG_DM_PCI_COMPAT=y
+CONFIG_CMD_PCI=y
CONFIG_ENV_IS_IN_FLASH=y
CONFIG_ENV_ADDR=0xBFC
# CONFIG_MMC is not set
--
2.17.5
[PATCH 5/7] sata_sil: Enable DM_PCI operation
Even though the sata_sil driver was converted over to the driver model,
it still assumed that the PCI controller is using the legacy interface.
Allow the "devno" member to be a struct udevice pointer and use
DM_PCI_COMPAT to covert the rest of the interface.
Signed-off-by: Andre Przywara
---
drivers/ata/sata_sil.c | 11 ++-
drivers/ata/sata_sil.h | 6 +-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/ata/sata_sil.c b/drivers/ata/sata_sil.c
index 6896fa8771..d5ba94c172 100644
--- a/drivers/ata/sata_sil.c
+++ b/drivers/ata/sata_sil.c
@@ -27,7 +27,11 @@
#include "sata_sil.h"
+#ifdef CONFIG_DM_PCI
+#define virt_to_bus(devno, v) dm_pci_virt_to_mem(devno, (void *) (v))
+#else
#define virt_to_bus(devno, v) pci_virt_to_mem(devno, (void *) (v))
+#endif
/* just compatible ahci_ops */
struct sil_ops {
@@ -608,13 +612,18 @@ static int sil_init_sata(struct udevice *uc_dev, int dev)
/* Save the private struct to block device struct */
#if !CONFIG_IS_ENABLED(BLK)
sata_dev_desc[dev].priv = (void *)sata;
+ sata->devno = sata_info.devno;
#else
priv->sil_sata_desc[dev] = sata;
priv->port_num = dev;
+#ifdef CONFIG_DM_PCI
+ sata->devno = uc_dev->parent;
+#else
+ sata->devno = sata_info.devno;
+#endif /* CONFIG_DM_PCI */
#endif
sata->id = dev;
sata->port = port;
- sata->devno = sata_info.devno;
sprintf(sata->name, "SATA#%d", dev);
sil_cmd_soft_reset(sata);
tmp = readl(port + PORT_SSTATUS);
diff --git a/drivers/ata/sata_sil.h b/drivers/ata/sata_sil.h
index ef41e8259a..a300c0c388 100644
--- a/drivers/ata/sata_sil.h
+++ b/drivers/ata/sata_sil.h
@@ -21,7 +21,11 @@ struct sil_sata {
u16 pio;
u16 mwdma;
u16 udma;
- pci_dev_t devno;
+#ifdef CONFIG_DM_PCI
+ struct udevice *devno;
+#else
+ pci_dev_t devno;
+#endif
int wcache;
int flush;
int flush_ext;
--
2.17.5
[PATCH 3/7] net: smc911x: Properly handle EEPROM MAC address
When compiled as a DM_ETH driver, the scm911x driver was reading the MAC
address from the optional EEPROM storage, but failed to copy this to the
platdata struct. Since it was also missing a definition of the
read_rom_hwaddr() function, the generic Ethernet code was dismissing
this MAC address, falling back to a random address or denying to start
at all.
Add an implementation of .read_rom_hwaddr, and refactor the function
reading the ROM address to be called by all interested parties.
This fixes MAC address issues when using the driver in DM_ETH "mode".
Signed-off-by: Andre Przywara
---
drivers/net/smc911x.c | 60 ++-
1 file changed, 36 insertions(+), 24 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index 9d2790e561..053ff9f4ff 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -187,6 +187,26 @@ static void smc911x_handle_mac_address(struct smc911x_priv
*priv)
printf(DRIVERNAME ": MAC %pM\n", m);
}
+static bool smc911x_read_mac_address(struct smc911x_priv *priv)
+{
+ u32 addrh, addrl;
+
+ /* address is obtained from optional eeprom */
+ addrh = smc911x_get_mac_csr(priv, ADDRH);
+ addrl = smc911x_get_mac_csr(priv, ADDRL);
+ if (addrl == 0x && addrh == 0x)
+ return false;
+
+ priv->enetaddr[0] = addrl;
+ priv->enetaddr[1] = addrl >> 8;
+ priv->enetaddr[2] = addrl >> 16;
+ priv->enetaddr[3] = addrl >> 24;
+ priv->enetaddr[4] = addrh;
+ priv->enetaddr[5] = addrh >> 8;
+
+ return true;
+}
+
static int smc911x_eth_phy_read(struct smc911x_priv *priv,
u8 phy, u8 reg, u16 *val)
{
@@ -471,7 +491,6 @@ static int smc911x_recv(struct eth_device *dev)
int smc911x_initialize(u8 dev_num, int base_addr)
{
- unsigned long addrl, addrh;
struct smc911x_priv *priv;
int ret;
@@ -489,18 +508,8 @@ int smc911x_initialize(u8 dev_num, int base_addr)
goto err_detect;
}
- addrh = smc911x_get_mac_csr(priv, ADDRH);
- addrl = smc911x_get_mac_csr(priv, ADDRL);
- if (!(addrl == 0x && addrh == 0x)) {
- /* address is obtained from optional eeprom */
- priv->enetaddr[0] = addrl;
- priv->enetaddr[1] = addrl >> 8;
- priv->enetaddr[2] = addrl >> 16;
- priv->enetaddr[3] = addrl >> 24;
- priv->enetaddr[4] = addrh;
- priv->enetaddr[5] = addrh >> 8;
+ if (smc911x_read_mac_address(priv))
memcpy(priv->dev.enetaddr, priv->enetaddr, 6);
- }
priv->dev.init = smc911x_init;
priv->dev.halt = smc911x_halt;
@@ -565,6 +574,19 @@ static int smc911x_recv(struct udevice *dev, int flags,
uchar **packetp)
return ret ? ret : -EAGAIN;
}
+static int smc911x_read_rom_hwaddr(struct udevice *dev)
+{
+ struct smc911x_priv *priv = dev_get_priv(dev);
+ struct eth_pdata *pdata = dev_get_platdata(dev);
+
+ if (!smc911x_read_mac_address(priv))
+ return -ENODEV;
+
+ memcpy(pdata->enetaddr, priv->enetaddr, sizeof(pdata->enetaddr));
+
+ return 0;
+}
+
static int smc911x_bind(struct udevice *dev)
{
return device_set_name(dev, dev->name);
@@ -573,7 +595,6 @@ static int smc911x_bind(struct udevice *dev)
static int smc911x_probe(struct udevice *dev)
{
struct smc911x_priv *priv = dev_get_priv(dev);
- unsigned long addrh, addrl;
int ret;
/* Try to detect chip. Will fail if not present. */
@@ -581,17 +602,7 @@ static int smc911x_probe(struct udevice *dev)
if (ret)
return ret;
- addrh = smc911x_get_mac_csr(priv, ADDRH);
- addrl = smc911x_get_mac_csr(priv, ADDRL);
- if (!(addrl == 0x && addrh == 0x)) {
- /* address is obtained from optional eeprom */
- priv->enetaddr[0] = addrl;
- priv->enetaddr[1] = addrl >> 8;
- priv->enetaddr[2] = addrl >> 16;
- priv->enetaddr[3] = addrl >> 24;
- priv->enetaddr[4] = addrh;
- priv->enetaddr[5] = addrh >> 8;
- }
+ smc911x_read_rom_hwaddr(dev);
return 0;
}
@@ -612,6 +623,7 @@ static const struct eth_ops smc911x_ops = {
.send = smc911x_send,
.recv = smc911x_recv,
.stop = smc911x_stop,
+ .read_rom_hwaddr = smc911x_read_rom_hwaddr,
};
static const struct udevice_id smc911x_ids[] = {
--
2.17.5
[PATCH 2/7] net: dm: Remove warning about EEPROM provided MAC address
Similar to patch 821fec0ceb3e ("net: remove scary warning about EEPROM
provided MAC address") this removes the somewhat awkward "warning" on
boards using DM_ETH:
In many parts of the computing world having a unique MAC address
sitting in some on-NIC storage is considered the normal case.
If there is a properly provided MAC address (either from ROM or from DT),
remove the warning to not scare the user unnecessarily.
Signed-off-by: Andre Przywara
---
net/eth-uclass.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/net/eth-uclass.c b/net/eth-uclass.c
index 7f89f65c92..0d9b75a9a2 100644
--- a/net/eth-uclass.c
+++ b/net/eth-uclass.c
@@ -560,8 +560,6 @@ static int eth_post_probe(struct udevice *dev)
memcpy(pdata->enetaddr, env_enetaddr, ARP_HLEN);
} else if (is_valid_ethaddr(pdata->enetaddr)) {
eth_env_set_enetaddr_by_index("eth", dev->seq, pdata->enetaddr);
- printf("\nWarning: %s using MAC address from %s\n",
- dev->name, source);
} else if (is_zero_ethaddr(pdata->enetaddr) ||
!is_valid_ethaddr(pdata->enetaddr)) {
#ifdef CONFIG_NET_RANDOM_ETHADDR
--
2.17.5
[PATCH 7/7] arm: juno: Enable SATA controller
The ARM Juno boards (-r1 and -r2) feature a Silicon Image 3132 PCIe SATA controller soldered on the board, providing two SATA ports. Enable the driver and the sata command in the defconfig, to be able to load images from SATA disks. Tested by loading kernels and Grub/EFI from an SSD and successfully booting a Linux system (with and without using UEFI). Signed-off-by: Andre Przywara --- configs/vexpress_aemv8a_juno_defconfig | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/configs/vexpress_aemv8a_juno_defconfig b/configs/vexpress_aemv8a_juno_defconfig index 4866a0e9d5..4654c529e8 100644 --- a/configs/vexpress_aemv8a_juno_defconfig +++ b/configs/vexpress_aemv8a_juno_defconfig @@ -29,14 +29,15 @@ CONFIG_CMD_USB=y CONFIG_CMD_CACHE=y # CONFIG_CMD_MISC is not set CONFIG_CMD_UBI=y -# CONFIG_ISO_PARTITION is not set -# CONFIG_EFI_PARTITION is not set CONFIG_OF_BOARD=y CONFIG_PCI=y CONFIG_DM_PCI=y CONFIG_PCIE_ECAM_GENERIC=y CONFIG_DM_PCI_COMPAT=y CONFIG_CMD_PCI=y +CONFIG_LIBATA=y +CONFIG_SATA_SIL=y +CONFIG_CMD_SATA=y CONFIG_ENV_IS_IN_FLASH=y CONFIG_ENV_ADDR=0xBFC # CONFIG_MMC is not set -- 2.17.5
[PATCH 4/7] arm: juno: Enable DM_ETH
The smc911X driver is now DM enabled, so we can switch the Juno board
over to use DM_ETH for the on-board Fast Ethernet device.
Works out of the box by using the DT.
Signed-off-by: Andre Przywara
---
arch/arm/Kconfig | 2 +-
board/armltd/vexpress64/vexpress64.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 21df1c415f..09a819c5fa 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1169,7 +1169,7 @@ config TARGET_VEXPRESS64_JUNO
select DM_SERIAL
select ARM_PSCI_FW
select PSCI_RESET
- select DM
+ select DM_ETH
select BLK
select USB
select DM_USB
diff --git a/board/armltd/vexpress64/vexpress64.c
b/board/armltd/vexpress64/vexpress64.c
index fbfa7a18f1..5932a4a0c7 100644
--- a/board/armltd/vexpress64/vexpress64.c
+++ b/board/armltd/vexpress64/vexpress64.c
@@ -152,11 +152,13 @@ void reset_cpu(ulong addr)
int board_eth_init(bd_t *bis)
{
int rc = 0;
+#ifndef CONFIG_DM_ETH
#ifdef CONFIG_SMC9
rc = smc9_initialize(0, CONFIG_SMC9_BASE);
#endif
#ifdef CONFIG_SMC911X
rc = smc911x_initialize(0, CONFIG_SMC911X_BASE);
+#endif
#endif
return rc;
}
--
2.17.5
[PATCH 1/7] arm: vexpress64: Fix counter frequency
The arch timer on 64-bit Arm Ltd. platforms is driven by a 24 MHz crystal oscillator, so the frequency is not 25165824 MHz, as the current code suggests. Signed-off-by: Andre Przywara --- include/configs/vexpress_aemv8a.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 09cdd3dab5..e63c335f85 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -68,7 +68,7 @@ #define V2M_SYS_CFGSTAT(V2M_SYSREGS + 0x0a8) /* Generic Timer Definitions */ -#define COUNTER_FREQUENCY (0x180) /* 24MHz */ +#define COUNTER_FREQUENCY 2400/* 24MHz */ /* Generic Interrupt Controller Definitions */ #ifdef CONFIG_GICV3 -- 2.17.5
[PATCH 0/7] arm: Juno board updates and PCIe/SATA enablement
This updates the Arm Juno board to fix a small bug, enable DM_ETH and also allow the usage of PCIe devices, foremost the on-board SATA controller. Patch 1/7 is a "typo" fix for the counter frequency. Patch 2, 3 and 4 allow to use the smc911x driver with DM_ETH on the Juno board, that removes the deprecation warning. Patch 5 allows the sata_sil driver to be used with DM_PCI compliant host controller drivers. Patch 6 tells U-Boot about the PCIe controller on the two later revision Juno boards. So far we were initialising the host bridge, to pave the way for any OS driver, but denied U-Boot itself to use PCIe devices. The final patch just enables the sata_sil driver, which allows loading images from SATA hard drives connected to the on-board ports. This allows me to boot an off-the-shelf Ubuntu installation using Grub/EFI from an SSD. Cheers, Andre Andre Przywara (7): arm: vexpress64: Fix counter frequency net: dm: Remove warning about EEPROM provided MAC address net: smc911x: Properly handle EEPROM MAC address arm: juno: Enable DM_ETH sata_sil: Enable DM_PCI operation arm: juno: Enable PCI arm: juno: Enable SATA controller arch/arm/Kconfig | 2 +- board/armltd/vexpress64/pcie.c | 14 +++--- board/armltd/vexpress64/vexpress64.c | 2 + configs/vexpress_aemv8a_juno_defconfig | 10 - drivers/ata/sata_sil.c | 11 - drivers/ata/sata_sil.h | 6 ++- drivers/net/smc911x.c | 60 +++--- include/configs/vexpress_aemv8a.h | 2 +- net/eth-uclass.c | 2 - 9 files changed, 72 insertions(+), 37 deletions(-) -- 2.17.5
Re: [PATCH v2 8/8] board: ns3: start sp805 watchdog service
Hi Rayagonda,
On 10.06.20 18:35, Rayagonda Kokatanur wrote:
Hi Stefan,
On Wed, Jun 10, 2020 at 4:33 PM Stefan Roese wrote:
On 10.06.20 12:52, Rayagonda Kokatanur wrote:
Start sp805 watchdog service.
Parse wdt timeout from env and dts, give precedence to env
timeout if defined. Set default timeout to 60s if both env
and dts doesn't specifiy timeout.
Stop the WDT in board late init and start the
WDT service before giving control to Linux.
I don't really understand, why you need such a board specific
watchdog handling. You disable and enable it at some points? Why
exactly? Usually the common WDT IF is used and it enables and
services the WDT (if configured this way) until the OS is started.
Then the OS needs to service the WDT. If the OS fails here (doesn't
start correctly etc), then the board will reset via the WDT.
So what is missing in the commin WDT IF for your setup?
Our boot sequence is , first we check for valid Linux images in
Linux_part_1, Linux_part_2 and Linux_part_3 of eMMC partition tables.
If the Linux image is not available, then we check for a valid Linux
image on a USB device. If it is not available in USB devices, then we
attempt for PXE boot. We observe the WDT trigger for the PXE boot
case.
So the WDT triggers a reset while you are booting via PXE boot? While
a image is loaded via PXE boot (pxe command)? If this is the case,
I would prefer to fix this issue (WDT reset while running a U-Boot
command).
U-boot is used for updating the binaries (like fip.bin {ATF, optee,
and uboot}, Linux and file system). For updating, we use tftp
protocol, which will take more time and depends up on the network
speed.
Hence we stop and start wdt service.
Sure it takes time to update images. But all this should be possible
with an actively serviced watchdog while still running in U-Boot.
This is why we have all these WATCHDOG_RESET() calls sprinkled all over
the system. If some code paths are missing such WDT triggering, then we
should find and fix them.
Thanks,
Stefan
Re: [PATCH v3 0/6] riscv: sifive/fu540: SPI boot
Hi, On Fri, Jun 5, 2020 at 2:10 AM Jagan Teki wrote: > > Updated series with boot device detection directly > on spl_boot_device function instead of having separate > board driver. > > Previous version changes are at [1]. > > Changes for v3: > - fixed env definitions build > - added boot device detection in board > Changes for v2: > - fu540 board driver > - runtime bootmode detection > - rebase on Pragnesh v11 series > > [1] > https://patchwork.ozlabs.org/project/uboot/cover/20200519192340.16624-1-ja...@amarulasolutions.com/ > > Any inputs? > Jagan. > > Jagan Teki (6): > sifive: fu540: Add runtime boot mode detection > sifive: fu540: Add Booting from SPI > env: Enable SPI flash env for SiFive FU540 > sifive: fu540: Mark the default env as SPI flash > sifive: fu540: Add boot flash script offset, size > sifive: fu540: Enable SF distro bootcmd Hope these will push for the release? Jagan.
Re: [PATCH] Correct sun8i-v3s SRAM size
On Tue, Jun 2, 2020 at 12:40 PM Benedikt-Alexander Mokroß wrote: > > Hi Jagan, > > I run into some size-related issues regarding my SPL configuration for a > custom V3s board (mainly due to using fit images). In fact, the V3s has even > more SRAM that could be used for the SPL. However the BROM won't boot > anything larger than 32KiB. So I use this 32KiB limit in production now and > found no issues with my 29KiB SPL whatsoever. And - if I read the BROM ASM > correctly - there is no performance drawback for default (and smaller) SPL > configurations since the BROM only loads the actual SPL size amount of > pages/bytes. > > I think it would be much less frustrating for other users if they could use > these 32KiB from the start since the current limit is hit pretty fast and > there is no reason why it should be this 24k limit for the V3s. It's another > poorly or even plain wrongly documented aspect of the Allwinner BSP. Can you rebase on master and send it with the proper commit head. "sunxi: Correct sun8i-v3s SRAM size"
Re: [PATCH v2 02/23] am335x: sl50: Enable DM_SPI
On Wed, May 27, 2020 at 6:26 PM Jagan Teki wrote: > > Enable DM_SPI for am355x sl50 board. > > Build is fine, but not tested. > > Cc: Enric Balletbo i Serra > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH v2 01/23] configs: igep00x0: Enable DM_SPI
On Wed, May 27, 2020 at 6:26 PM Jagan Teki wrote: > > Enable DM_SPI for igep00x0 board. > > Build is fine, but not tested. > > Cc: Enric Balletbo i Serra > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: USB patch for rpi4
> > > I am trying to test v4 of your patch series for USB support on rpi4: > > > https://patchwork.ozlabs.org/project/uboot/list/?series=179078 > > > > > > I am building u-boot 64-bit. Testing on a rpi4 B 1.2 board. But, USB is > > > not working for me and wanted to see if you had any ideas. Are there > > > other dependencies other than just applying your patch series? > > > > > > I've pasted the u-boot console output below. > > > > > > From what I can tell this board does not need the VL805 firmware > > > > 1.2 rev boards do need the firmware loading patch series, not sure > > about any other patches. > > Are you sure? A colleague of mine said that it was in 1.4 that the flash > chip for the VL805 was removed. I can physically see that the flash > chip is on my board. Yes, I am sure, the 1.2 is for the 2/4Gb model with the changes that need the firmware loading, the 1.4 according to their rev docs is limited to the 8Gb model ATM. https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md > > In any case, I did figure out one thing that was going on. I was using > the rpi4 DTB as it came shipped with my board. I found that on the > PCIe node there was a typo in the compatible string. I fixed that: > bus-range = <0x0 0x1>; > - compatible = "brcm,bcm7211-pcie", > "brcm,bcm7445-pcie", "brcm,pci-plat-dev"; > + compatible = "brcm,bcm2711-pcie", > "brcm,bcm7445-pcie", "brcm,pci-plat-dev"; > max-link-speed = <0x2>; > > ...and USB now starts up and works. > > Thanks, > Stuart
Re: [PATCH 1/5] dm: core: Fix devfdt_get_addr_ptr return value
Hi,
On 27.05.2020 15:05, Matthias Brugger wrote:
On 27/05/2020 08:41, Ovidiu Panait wrote:
According to the description of devfdt_get_addr_ptr, this function should
return NULL on failure, but currently it returns (void *)FDT_ADDR_T_NONE.
This is also a problem because there are two definitions for
dev_read_addr_ptr, depending on CONFIG_DM_DEV_READ_INLINE:
1. one returning NULL on failure (drivers/core/read.c):
void *dev_read_addr_ptr(const struct udevice *dev)
{
fdt_addr_t addr = dev_read_addr(dev);
return (addr == FDT_ADDR_T_NONE) ? NULL : map_sysmem(addr, 0);
}
2. another one, which is a wrapper over devfdt_get_addr_ptr, returning
(void *)FDT_ADDR_T_NONE (include/dm/read.h)
static inline void *dev_read_addr_ptr(const struct udevice *dev)
{
return devfdt_get_addr_ptr(dev);
}
Currently, some drivers which make use of devfdt_get_addr_ptr check the
return value for NULL:
drivers/i2c/mvtwsi.c
drivers/i2c/designware_i2c.c
drivers/usb/host/ehci-zynq.c
while others check the return value for (void *)FDT_ADDR_T_NONE:
drivers/pinctrl/mvebu/pinctrl-mvebu.c
drivers/timer/ast_timer.c
drivers/watchdog/ast_wdt.c
Fix this by making devfdt_get_addr_ptr return NULL on failure, as
described in the function comments. Also, update the drivers currently
checking (void *)FDT_ADDR_T_NONE to check for NULL.
Signed-off-by: Ovidiu Panait
Reviewed-by: Matthias Brugger
Simon can you have a look. If it's OK for you I can queue the series through my
tree.
I will resend this patch after
http://patchwork.ozlabs.org/project/uboot/patch/20200521161503.384823-10-sean...@gmail.com/
series gets merged.
In the meantime, I resent the rest of "pinctrl: bcm283x" patches from
this series separately so maybe they could be picked up in the meantime:
https://patchwork.ozlabs.org/project/uboot/list/?series=182703
Thanks,
Ovidiu
Regards,
Matthias
---
drivers/clk/aspeed/clk_ast2500.c | 4 ++--
drivers/core/fdtaddr.c| 5 -
drivers/i2c/ast_i2c.c | 4 ++--
drivers/pinctrl/mvebu/pinctrl-mvebu.c | 2 +-
drivers/timer/ast_timer.c | 4 ++--
drivers/watchdog/ast_wdt.c| 4 ++--
6 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/aspeed/clk_ast2500.c b/drivers/clk/aspeed/clk_ast2500.c
index ccfeded30c..284f5f58d6 100644
--- a/drivers/clk/aspeed/clk_ast2500.c
+++ b/drivers/clk/aspeed/clk_ast2500.c
@@ -498,8 +498,8 @@ static int ast2500_clk_ofdata_to_platdata(struct udevice
*dev)
struct ast2500_clk_priv *priv = dev_get_priv(dev);
priv->scu = devfdt_get_addr_ptr(dev);
- if (IS_ERR(priv->scu))
- return PTR_ERR(priv->scu);
+ if (!priv->scu)
+ return -EINVAL;
return 0;
}
diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index dfcb868f65..044d5871b0 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -154,7 +155,9 @@ fdt_addr_t devfdt_get_addr(const struct udevice *dev)
void *devfdt_get_addr_ptr(const struct udevice *dev)
{
- return (void *)(uintptr_t)devfdt_get_addr_index(dev, 0);
+ fdt_addr_t addr = devfdt_get_addr_index(dev, 0);
+
+ return (addr == FDT_ADDR_T_NONE) ? NULL : map_sysmem(addr, 0);
}
void *devfdt_remap_addr_index(const struct udevice *dev, int index)
diff --git a/drivers/i2c/ast_i2c.c b/drivers/i2c/ast_i2c.c
index 214362d04b..253e653666 100644
--- a/drivers/i2c/ast_i2c.c
+++ b/drivers/i2c/ast_i2c.c
@@ -93,8 +93,8 @@ static int ast_i2c_ofdata_to_platdata(struct udevice *dev)
int ret;
priv->regs = devfdt_get_addr_ptr(dev);
- if (IS_ERR(priv->regs))
- return PTR_ERR(priv->regs);
+ if (!priv->regs)
+ return -EINVAL;
ret = clk_get_by_index(dev, 0, >clk);
if (ret < 0) {
diff --git a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
index 2206e958ec..ac0377e796 100644
--- a/drivers/pinctrl/mvebu/pinctrl-mvebu.c
+++ b/drivers/pinctrl/mvebu/pinctrl-mvebu.c
@@ -194,7 +194,7 @@ int mvebu_pinctl_probe(struct udevice *dev)
}
priv->base_reg = devfdt_get_addr_ptr(dev);
- if (priv->base_reg == (void *)FDT_ADDR_T_NONE) {
+ if (!priv->base_reg) {
debug("%s: Failed to get base address\n", __func__);
return -EINVAL;
}
diff --git a/drivers/timer/ast_timer.c b/drivers/timer/ast_timer.c
index 3838601f54..9f28cbfcf9 100644
--- a/drivers/timer/ast_timer.c
+++ b/drivers/timer/ast_timer.c
@@ -65,8 +65,8 @@ static int ast_timer_ofdata_to_platdata(struct udevice *dev)
struct ast_timer_priv *priv = dev_get_priv(dev);
priv->regs = devfdt_get_addr_ptr(dev);
- if (IS_ERR(priv->regs))
- return PTR_ERR(priv->regs);
+ if (!priv->regs)
+ return -EINVAL;
priv->tmc =
[PATCH 3/3] pinctrl: bcm283x: Store the return value of dev_read_u32_default to int
Currently, the return value of dev_read_u32_default is stored in an u32,
causing the subsequent "if (function < 0)" to always be false:
u32 function
...
function = dev_read_u32_default(config, "brcm,function", -1);
if (function < 0) {
debug("Failed reading function for pinconfig %s (%d)\n",
config->name, function);
return -EINVAL;
}
Make "function" variable an int to fix this.
Signed-off-by: Ovidiu Panait
---
drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
index 9ab0baee33..52aab4045c 100644
--- a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
+++ b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
@@ -63,7 +63,7 @@ static int bcm2835_gpio_get_func_id(struct udevice *dev,
unsigned int gpio)
int bcm283x_pinctrl_set_state(struct udevice *dev, struct udevice *config)
{
u32 pin_arr[MAX_PINS_PER_BANK];
- u32 function;
+ int function;
int i, len, pin_count = 0;
if (!dev_read_prop(config, "brcm,pins", ) || !len ||
--
2.17.1
[PATCH 1/3] pinctrl: bcm283x: DM_FLAG_PRE_RELOC: Remove OF_CONTROL check
Remove CONFIG_IS_ENABLED(OF_CONTROL) check from DM_FLAG_PRE_RELOC, since
this driver only supports OF_CONTROL.
drivers/pinctrl/broadcom/Kconfig:
config PINCTRL_BCM283X
depends on ARCH_BCM283X && PINCTRL_FULL && OF_CONTROL
Signed-off-by: Ovidiu Panait
---
drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
index f44af6cf9a..8bf7916627 100644
--- a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
+++ b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
@@ -150,7 +150,7 @@ U_BOOT_DRIVER(pinctrl_bcm283x) = {
.priv_auto_alloc_size = sizeof(struct bcm283x_pinctrl_priv),
.ops= _pinctrl_ops,
.probe = bcm283x_pinctl_probe,
-#if !CONFIG_IS_ENABLED(OF_CONTROL) || CONFIG_IS_ENABLED(OF_BOARD)
+#if CONFIG_IS_ENABLED(OF_BOARD)
.flags = DM_FLAG_PRE_RELOC,
#endif
};
--
2.17.1
[PATCH 2/3] pinctrl: bcm283x: Read address from DT in ofdata_to_platdata
Factor out reading IP base address to ofdata_to_platdata function, which
is designed for this purpose. Also, drop the dev->priv NULL check, since
this is already done by the dm core when allocating space using
priv_auto_alloc_size feature. (in drivers/core/device.c ->
device_ofdata_to_platdata).
Signed-off-by: Ovidiu Panait
---
drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
index 8bf7916627..9ab0baee33 100644
--- a/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
+++ b/drivers/pinctrl/broadcom/pinctrl-bcm283x.c
@@ -104,17 +104,11 @@ static const struct udevice_id bcm2835_pinctrl_id[] = {
{}
};
-int bcm283x_pinctl_probe(struct udevice *dev)
+int bcm283x_pinctl_ofdata_to_platdata(struct udevice *dev)
{
struct bcm283x_pinctrl_priv *priv;
- int ret;
- struct udevice *pdev;
priv = dev_get_priv(dev);
- if (!priv) {
- debug("%s: Failed to get private\n", __func__);
- return -EINVAL;
- }
priv->base_reg = dev_read_addr_ptr(dev);
if (priv->base_reg == (void *)FDT_ADDR_T_NONE) {
@@ -122,6 +116,14 @@ int bcm283x_pinctl_probe(struct udevice *dev)
return -EINVAL;
}
+ return 0;
+}
+
+int bcm283x_pinctl_probe(struct udevice *dev)
+{
+ int ret;
+ struct udevice *pdev;
+
/* Create GPIO device as well */
ret = device_bind(dev, lists_driver_lookup_name("gpio_bcm2835"),
"gpio_bcm2835", NULL, dev_of_offset(dev), );
@@ -147,6 +149,7 @@ U_BOOT_DRIVER(pinctrl_bcm283x) = {
.name = "bcm283x_pinctrl",
.id = UCLASS_PINCTRL,
.of_match = of_match_ptr(bcm2835_pinctrl_id),
+ .ofdata_to_platdata = bcm283x_pinctl_ofdata_to_platdata,
.priv_auto_alloc_size = sizeof(struct bcm283x_pinctrl_priv),
.ops= _pinctrl_ops,
.probe = bcm283x_pinctl_probe,
--
2.17.1
Re: [PATCH 5/9] spi: davinci: Drop non-dm code
On Tue, May 26, 2020 at 1:34 PM Jagan Teki wrote: > > Now all boards which are using davinci SPI driver > have moved to SPL_DM so drop the unneeded non-dm code. > > Cc: Adam Ford > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH 4/9] ks2_evm: Switch to DM_SPL, SPL_OF_CONTROL
On Tue, May 26, 2020 at 1:34 PM Jagan Teki wrote: > > This would make SPL build to DM_SPL, SPL_OF_CONTROL. > > Build fine with but not tested. > > Cc: Vitaly Andrianov > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH 3/3] spi: atmel: Drop atmel_spi.h
On Thu, May 28, 2020 at 12:30 AM Jagan Teki wrote: > > atmel_spi.h has register offsets, and atmel_spi_slave > structure, move it into .c file for better readability > and drop atmel_spi.h > > Cc: Wenyou Yang > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH 2/3] spi: atmel: Remove nondm code
On Thu, May 28, 2020 at 12:30 AM Jagan Teki wrote: > > atmel spi driver now accessible only when DM_SPI enabled. > > So, remove nondm code. > > Cc: Wenyou Yang > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH 1/3] spi: atmel: Drop CONFIG_SYS_SPI_WRITE_TOUT
On Thu, May 28, 2020 at 12:30 AM Jagan Teki wrote: > > Drop CONFIG_SYS_SPI_WRITE_TOUT there is no code usage. > > Cc: Wenyou Yang > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH 8/9] spi: Zap SOFT_SPI (non-dm)
On Tue, May 26, 2020 at 1:35 PM Jagan Teki wrote: > > - Deadline for DM migration already passed by months. > - Sent couple of zap patches and > - No response on dm conversation > hence removed the driver. > > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH 7/9] spi: mxs: Code cleanup
On Tue, May 26, 2020 at 1:34 PM Jagan Teki wrote: > > Order the macros, private structures and simple functions > in a proper way to have more code readability. > > No functionality changed. > > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
Re: [PATCH v5 0/6] ARM: arbitrary virtual-physical mappings for RPi4 XHCI support
On 03/06/2020 14:43, Marek Szyprowski wrote: > Hi All, > > This patchset adds support for creating a mapping for the arbitrary > physical address at the given virtual address. This is needed to enable > support for XHCI USB controller on PCIe bridge on Raspberry Pi 4 board, > on which the USB controller's MMIO area 0x6 has to be remapped > somewhere to fit in 4GiB virtual address space when running in ARM 32bit > mode. > > This patchset is a continuation of the Raspberry Pi 4 XHCI/PCIe patchset: > https://patchwork.ozlabs.org/project/uboot/list/?series=179078 > and the following discussion: > https://lists.denx.de/pipermail/u-boot/2020-May/411086.html > > Best regards > Marek Szyprowski > Samsung R Institute Poland > > > Changelog: > > v5: > - fixed issues pointed by Tom Rini (comments style, ifdefs, spdx) > > v4: https://lists.denx.de/pipermail/u-boot/2020-June/414531.html > - added a patch, which moves ADDR_MAP config entry to Kconfig system > as requested by Simon Glass > - rebased onto v4 of the "USB host support for Raspberry Pi 4 board > (64-bit)" patchset > > v3: https://lists.denx.de/pipermail/u-boot/2020-May/412427.html > - fixed broken RPi3 and lack of the identity mapping for map_physmem > (for example for the itest command was broken) > - added a patch fixing a new build warning > > v2: https://lists.denx.de/pipermail/u-boot/2020-May/411765.html > - fixed ARM64 build > > v1: https://lists.denx.de/pipermail/u-boot/2020-May/411765.html > - initial RFC > > > Patch summary: > > Marek Szyprowski (5): > powerpc: move ADDR_MAP to Kconfig > arm: update comments to the common style > arm: provide a function for boards init code to modify MMU > virtual-physical map > rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM > 32bit) > config: Enable support for the XHCI controller on RPI4 board > > Seung-Woo Kim (1): > mmc: bcm283x: fix int to pointer cast > Series looks good to me. The problem is that on RPi4 with 8 GB the USB FW get's loaded via the RPi FW. Nicolas provided a series which is under review right now. Without this series the 8 GB RPi4 won't boot. As soon as the series is ready I'll take all the RPi4 PCI/USB related patches into the next branch. Regards, Matthias > arch/arm/include/asm/mmu.h | 8 + > arch/arm/include/asm/system.h | 36 > -- > arch/arm/lib/cache-cp15.c | 24 +++ > arch/arm/mach-bcm283x/Kconfig | 1 + > arch/arm/mach-bcm283x/include/mach/base.h | 8 + > arch/arm/mach-bcm283x/init.c | 21 + > configs/B4420QDS_NAND_defconfig| 2 ++ > configs/B4420QDS_SPIFLASH_defconfig| 2 ++ > configs/B4420QDS_defconfig | 2 ++ > configs/B4860QDS_NAND_defconfig| 2 ++ > configs/B4860QDS_SECURE_BOOT_defconfig | 2 ++ > configs/B4860QDS_SPIFLASH_defconfig| 2 ++ > configs/B4860QDS_SRIO_PCIE_BOOT_defconfig | 2 ++ > configs/B4860QDS_defconfig | 2 ++ > configs/C29XPCIE_NAND_defconfig| 1 + > configs/C29XPCIE_NOR_SECBOOT_defconfig | 1 + > configs/C29XPCIE_SPIFLASH_SECBOOT_defconfig| 1 + > configs/C29XPCIE_SPIFLASH_defconfig| 1 + > configs/C29XPCIE_defconfig | 1 + > configs/Cyrus_P5020_defconfig | 2 ++ > configs/Cyrus_P5040_defconfig | 2 ++ > configs/MPC8536DS_36BIT_defconfig | 1 + > configs/MPC8548CDS_36BIT_defconfig | 1 + > configs/MPC8572DS_36BIT_defconfig | 1 + > configs/MPC8641HPCN_36BIT_defconfig| 2 ++ > configs/MPC8641HPCN_defconfig | 2 ++ > configs/P1010RDB-PA_36BIT_NAND_SECBOOT_defconfig | 1 + > configs/P1010RDB-PA_36BIT_NAND_defconfig | 1 + > configs/P1010RDB-PA_36BIT_NOR_SECBOOT_defconfig| 1 + > configs/P1010RDB-PA_36BIT_NOR_defconfig| 1 + > configs/P1010RDB-PA_36BIT_SDCARD_defconfig | 1 + > .../P1010RDB-PA_36BIT_SPIFLASH_SECBOOT_defconfig | 1 + > configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig | 1 + > configs/P1010RDB-PB_36BIT_NAND_SECBOOT_defconfig | 1 + > configs/P1010RDB-PB_36BIT_NAND_defconfig | 1 + > configs/P1010RDB-PB_36BIT_NOR_SECBOOT_defconfig| 1 + > configs/P1010RDB-PB_36BIT_NOR_defconfig| 1 + > configs/P1010RDB-PB_36BIT_SDCARD_defconfig | 1 + > .../P1010RDB-PB_36BIT_SPIFLASH_SECBOOT_defconfig | 1 + > configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig | 1 + > configs/P1020MBG-PC_36BIT_SDCARD_defconfig | 1 + > configs/P1020MBG-PC_36BIT_defconfig| 1 + > configs/P1020RDB-PC_36BIT_NAND_defconfig | 1 + >
Re: [PATCH v4 0/9] USB host support for Raspberry Pi 4 board (64-bit)
Hi Sylwester, On 25/05/2020 13:39, Sylwester Nawrocki wrote: > Hi all, > > This patch series adds USB host support for Raspberry Pi 4 board. > It includes the Broadcom STB PCIe controller driver ported from Linux > kernel, a memory mapping update for the xHCI controller on PCIe bus > for 64-bit builds and some related fixes and updates in the usb/xhci > and the pci driver core code. > > The 32-bit ARM part has be excluded from the series and will be posted > separately. > > The difference comparing to previous version is only in the config update > patch "configs: Enable support for the XHCI controller on RPI4 board (ARM > 64-bit)". > > The patch series is based on v2020.07-rc1 tree. > > Thanks, > Sylwester > > Marek Szyprowski (3): > rpi4: shorten a mapping for the DRAM > rpi4: add a mapping for the PCIe XHCI controller MMIO registers (ARM > 64bit) > configs: Enable support for the XHCI controller on RPI4 board (ARM > 64-bit) > > Nicolas Saenz Julienne (1): > linux/bitfield.h: Add primitives for manipulating bitfields both in > host- and fixed-endian > > Sylwester Nawrocki (5): > usb: xhci: Add missing cache flush in the scratchpad array > initialization > usb: xhci: Use only 32-bit accesses in xhci_writeq/xhci_readq > pci: Move some PCIe register offset definitions to a common header > pci: Add some PCI Express capability register offset definitions > pci: Add driver for Broadcom BCM2711 SoC PCIe controller > Series looks good to me. The problem is that on RPi4 with 8 GB the USB FW get's loaded via the RPi FW. Nicolas provided a series which is under review right now. Without this series the 8 GB RPi4 won't boot. As soon as the series is ready I'll take all the RPi4 PCI/USB related patches into the next branch. Regards, Matthias > arch/arm/mach-bcm283x/init.c | 20 +- > configs/rpi_4_defconfig | 9 + > configs/rpi_arm64_defconfig | 8 +- > drivers/pci/Kconfig | 9 + > drivers/pci/Makefile | 1 + > drivers/pci/pci-rcar-gen3.c | 8 - > drivers/pci/pcie_brcmstb.c| 623 > ++ > drivers/pci/pcie_intel_fpga.c | 3 - > drivers/usb/host/xhci-mem.c | 3 + > include/linux/bitfield.h | 52 > include/pci.h | 22 +- > include/usb/xhci.h| 8 - > 12 files changed, 740 insertions(+), 26 deletions(-) > create mode 100644 drivers/pci/pcie_brcmstb.c >
Re: [PATCH 6/9] spi: mxs: Drop nondm code
On Tue, May 26, 2020 at 1:34 PM Jagan Teki wrote: > > Deadline for DM migration already passed by months > and no response on full dm conversation hence removed > the nondm code. > > Note: Look like there is no user for nondm code > for this driver. > > Signed-off-by: Jagan Teki > --- Applied to u-boot-spi/master
[PATCH] configs: ls1043aqds: Configure QSPI related configs
LS1043A-QDS has "s25fl128s" flash of size 16M with 64K sector size. The board requires few spi-flash related configs to be updated in TFA and QSPI _defconfigs. Following are the changes: - Define/Update CONFIG_ENV_ADDR - Unset CONFIG_SPI_FLASH_BAR - Correct CONFIG_ENV_SECT_SIZE - Enable CONFIG_SYS_RELOC_GD_ENV_ADDR Signed-off-by: Kuldeep Singh --- configs/ls1043aqds_qspi_defconfig| 1 + configs/ls1043aqds_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1043aqds_tfa_defconfig | 3 ++- 3 files changed, 4 insertions(+), 1 deletion(-) diff --git a/configs/ls1043aqds_qspi_defconfig b/configs/ls1043aqds_qspi_defconfig index a018b22..bb92b4c 100644 --- a/configs/ls1043aqds_qspi_defconfig +++ b/configs/ls1043aqds_qspi_defconfig @@ -35,6 +35,7 @@ CONFIG_MTDPARTS_DEFAULT="mtdparts=spi0.0:1m(uboot),5m(kernel),1m(dtb),9m(file_sy CONFIG_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="fsl-ls1043a-qds-duart" CONFIG_ENV_IS_IN_SPI_FLASH=y +CONFIG_ENV_ADDR=0x4030 CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y diff --git a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig index 3ee5d28..a9d7131 100644 --- a/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1043aqds_tfa_SECURE_BOOT_defconfig @@ -48,6 +48,7 @@ CONFIG_SYS_FLASH_CFI=y CONFIG_MTD_RAW_NAND=y CONFIG_SPI_FLASH=y CONFIG_SF_DEFAULT_BUS=1 +# CONFIG_SPI_FLASH_BAR is not set CONFIG_SPI_FLASH_SPANSION=y CONFIG_PHYLIB=y CONFIG_PHYLIB_10G=y diff --git a/configs/ls1043aqds_tfa_defconfig b/configs/ls1043aqds_tfa_defconfig index 297788b..eb1f905 100644 --- a/configs/ls1043aqds_tfa_defconfig +++ b/configs/ls1043aqds_tfa_defconfig @@ -4,7 +4,7 @@ CONFIG_TFABOOT=y CONFIG_SYS_TEXT_BASE=0x8200 CONFIG_ENV_SIZE=0x2000 CONFIG_ENV_OFFSET=0x50 -CONFIG_ENV_SECT_SIZE=0x2 +CONFIG_ENV_SECT_SIZE=0x1 CONFIG_DM_GPIO=y CONFIG_NR_DRAM_BANKS=2 CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT=y @@ -43,6 +43,7 @@ CONFIG_ENV_IS_IN_SPI_FLASH=y CONFIG_USE_ENV_SPI_BUS=y CONFIG_ENV_SPI_BUS=0 CONFIG_ENV_ADDR=0x6050 +CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_FSL_CAAM=y -- 2.7.4
RE: [U-Boot] [PATCH v2 04/16] arm: socfpga: stratix10: Add pinmux support for Stratix10 SoC
> -Original Message-
> From: Heinrich Schuchardt
> Sent: Sunday, June 7, 2020 7:07 AM
> To: Tan, Ley Foon ; u-boot@lists.denx.de
> Cc: Marek Vasut ; See, Chin Liang
> ; Tom Rini
> Subject: Re: [U-Boot] [PATCH v2 04/16] arm: socfpga: stratix10: Add pinmux
> support for Stratix10 SoC
>
> On 5/18/18 4:05 PM, Ley Foon Tan wrote:
> > Add pinmux driver support for Stratix SoC
> >
> > Signed-off-by: Chin Liang See
> > Signed-off-by: Ley Foon Tan
> > ---
> > arch/arm/mach-socfpga/Makefile |2 +
> > .../arm/mach-socfpga/include/mach/system_manager.h |5 +-
> > .../mach-socfpga/include/mach/system_manager_s10.h | 176
>
> > arch/arm/mach-socfpga/system_manager_s10.c | 91 ++
> > arch/arm/mach-socfpga/wrap_pinmux_config_s10.c | 56 ++
> > 5 files changed, 329 insertions(+), 1 deletions(-) create mode
> > 100644 arch/arm/mach-socfpga/include/mach/system_manager_s10.h
> > create mode 100644 arch/arm/mach-socfpga/system_manager_s10.c
> > create mode 100644 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c
> >
> > diff --git a/arch/arm/mach-socfpga/Makefile
> > b/arch/arm/mach-socfpga/Makefile index 69bdb84..61f5778 100644
> > --- a/arch/arm/mach-socfpga/Makefile
> > +++ b/arch/arm/mach-socfpga/Makefile
> > @@ -31,6 +31,8 @@ endif
> > ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
> > obj-y += clock_manager_s10.o
> > obj-y += reset_manager_s10.o
> > +obj-y += system_manager_s10.o
> > +obj-y += wrap_pinmux_config_s10.o
> > obj-y += wrap_pll_config_s10.o
> > endif
> > ifdef CONFIG_SPL_BUILD
> > diff --git a/arch/arm/mach-socfpga/include/mach/system_manager.h
> > b/arch/arm/mach-socfpga/include/mach/system_manager.h
> > index fbe2a8b..7e76df7 100644
> > --- a/arch/arm/mach-socfpga/include/mach/system_manager.h
> > +++ b/arch/arm/mach-socfpga/include/mach/system_manager.h
> > @@ -6,6 +6,9 @@
> > #ifndef _SYSTEM_MANAGER_H_
> > #define _SYSTEM_MANAGER_H_
> >
> > +#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
> > +#include #else
> > #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGPINMUXBIT(0)
> > #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGIOBIT(1)
> > #define SYSMGR_ECC_OCRAM_ENBIT(0)
> > @@ -88,5 +91,5 @@
> >
> > #define SYSMGR_GET_BOOTINFO_BSEL(bsel) \
> > (((bsel) >> SYSMGR_BOOTINFO_BSEL_SHIFT) & 7)
> > -
> > +#endif
> > #endif /* _SYSTEM_MANAGER_H_ */
> > diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
> > b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
> > new file mode 100644
> > index 000..813dff2
> > --- /dev/null
> > +++ b/arch/arm/mach-socfpga/include/mach/system_manager_s10.h
> > @@ -0,0 +1,176 @@
> > +/* SPDX-License-Identifier: GPL-2.0
> > + *
> > + * Copyright (C) 2016-2018 Intel Corporation
> > + *
> > + */
> > +
> > +#ifndef_SYSTEM_MANAGER_S10_
> > +#define_SYSTEM_MANAGER_S10_
> > +
> > +void sysmgr_pinmux_init(void);
> > +void populate_sysmgr_fpgaintf_module(void);
> > +void populate_sysmgr_pinmux(void);
> > +void sysmgr_pinmux_table_sel(const u32 **table, unsigned int
> > +*table_len); void sysmgr_pinmux_table_ctrl(const u32 **table,
> > +unsigned int *table_len); void sysmgr_pinmux_table_fpga(const u32
> > +**table, unsigned int *table_len); void
> > +sysmgr_pinmux_table_delay(const u32 **table, unsigned int
> > +*table_len);
> > +
> > +struct socfpga_system_manager {
> > + /* System Manager Module */
> > + u32 siliconid1; /* 0x00 */
> > + u32 siliconid2;
> > + u32 wddbg;
> > + u32 _pad_0xc;
> > + u32 mpu_status; /* 0x10 */
> > + u32 mpu_ace;
> > + u32 _pad_0x18_0x1c[2];
> > + u32 dma;/* 0x20 */
> > + u32 dma_periph;
> > + /* SDMMC Controller Group */
> > + u32 sdmmcgrp_ctrl;
> > + u32 sdmmcgrp_l3master;
> > + /* NAND Flash Controller Register Group */
> > + u32 nandgrp_bootstrap; /* 0x30 */
> > + u32 nandgrp_l3master;
> > + /* USB Controller Group */
> > + u32 usb0_l3master;
> > + u32 usb1_l3master;
> > + /* EMAC Group */
> > + u32 emac_gbl; /* 0x40 */
> > + u32 emac0;
> > + u32 emac1;
> > + u32 emac2;
> > + u32 emac0_ace; /* 0x50 */
> > + u32 emac1_ace;
> > + u32 emac2_ace;
> > + u32 nand_axuser;
> > + u32 _pad_0x60_0x64[2]; /* 0x60 */
> > + /* FPGA interface Group */
> > + u32 fpgaintf_en_1;
> > + u32 fpgaintf_en_2;
> > + u32 fpgaintf_en_3; /* 0x70 */
> > + u32 dma_l3master;
> > + u32 etr_l3master;
> > + u32 _pad_0x7c;
> > + u32 sec_ctrl_slt; /* 0x80 */
> > + u32 osc_trim;
> > + u32 _pad_0x88_0x8c[2];
> > + /* ECC Group */
> > + u32 ecc_intmask_value; /* 0x90 */
> > + u32 ecc_intmask_set;
> > + u32
