Re: [U-Boot] [PATCH v2 16/18] mmc: mtk-sd: add SD/MMC host controller driver for MT7623 SoC
Hi Ryder. On 12 October 2018 at 01:01, Ryder Lee wrote: > From: Weijie Gao > > This patch adds MT7623 host controller driver for accessing SD/MMC. > > Cc: Jaehoon Chung > Signed-off-by: Weijie Gao > Signed-off-by: Ryder Lee > Tested-by: Matthias Brugger > --- > drivers/mmc/Kconfig |9 + > drivers/mmc/Makefile |1 + > drivers/mmc/mtk-sd.c | 1331 > ++ > 3 files changed, 1341 insertions(+) > create mode 100644 drivers/mmc/mtk-sd.c Reviewed-by: Simon Glass nits below > > diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig > index 0a0d4aa..ca13341 100644 > --- a/drivers/mmc/Kconfig > +++ b/drivers/mmc/Kconfig > @@ -598,6 +598,15 @@ config FTSDC010_SDIO > help > This can enable ftsdc010 sdio function. > > +config MMC_MTK > + bool "MediaTek SD/MMC Card Interface support" > + default n You should be able to omit this since it is the default. > + help > + This selects the MediaTek(R) Secure digital and Multimedia card > Interface. > + If you have a machine with a integrated SD/MMC card reader, say Y > or M here. > + This is needed if support for any SD/SDIO/MMC devices is required. > + If unsure, say N. > + > endif > > config TEGRA124_MMC_DISABLE_EXT_LOOPBACK > diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile > index 23c5b0d..801a26d 100644 > --- a/drivers/mmc/Makefile > +++ b/drivers/mmc/Makefile > @@ -65,3 +65,4 @@ obj-$(CONFIG_MMC_SUNXI) += sunxi_mmc.o > obj-$(CONFIG_MMC_UNIPHIER) += tmio-common.o uniphier-sd.o > obj-$(CONFIG_RENESAS_SDHI) += tmio-common.o renesas-sdhi.o > obj-$(CONFIG_MMC_BCM2835) += bcm2835_sdhost.o > +obj-$(CONFIG_MMC_MTK) += mtk-sd.o > diff --git a/drivers/mmc/mtk-sd.c b/drivers/mmc/mtk-sd.c > new file mode 100644 > index 000..5027764 > --- /dev/null > +++ b/drivers/mmc/mtk-sd.c > @@ -0,0 +1,1331 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * MediaTek SD/MMC Card Interface driver > + * > + * Copyright (C) 2018 MediaTek Inc. > + * Author: Weijie Gao > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include Please check include-file order on all these patches. > + > +#define MSDC_CFG 0x0 > +#define MSDC_CFG_HS400_CK_MODE_EXT BIT(22) > +#define MSDC_CFG_CKMOD_EXT_M 0x03 > +#define MSDC_CFG_CKMOD_EXT_S 20 > +#define MSDC_CFG_CKDIV_EXT_M 0xfff > +#define MSDC_CFG_CKDIV_EXT_S 8 > +#define MSDC_CFG_HS400_CK_MODE BIT(18) > +#define MSDC_CFG_CKMOD_M 0x03 > +#define MSDC_CFG_CKMOD_S 16 > +#define MSDC_CFG_CKDIV_M 0xff > +#define MSDC_CFG_CKDIV_S 8 We mostly use shifted masks in U-Boot since they are easier to use: +#define MSDC_CFG_CKDIV_S 8 +#define MSDC_CFG_CKDIV_M (0xff << MSDC_CFG_CKDIV_S) > +#define MSDC_CFG_CKSTB BIT(7) > +#define MSDC_CFG_PIO BIT(3) > +#define MSDC_CFG_RST BIT(2) > +#define MSDC_CFG_CKPDN BIT(1) > +#define MSDC_CFG_MODEBIT(0) > + > +#define MSDC_IOCON 0x04 > +#define MSDC_IOCON_W_DSPLBIT(8) > +#define MSDC_IOCON_DSPL BIT(2) > +#define MSDC_IOCON_RSPL BIT(1) > + > +#define MSDC_PS0x08 > +#define MSDC_PS_DAT0 BIT(16) > +#define MSDC_PS_CDEN BIT(0) > + > +#define MSDC_INT 0x0c > +#define MSDC_INTEN 0x10 > +#define MSDC_INT_ACMDRDY BIT(3) > +#define MSDC_INT_ACMDTMO BIT(4) > +#define MSDC_INT_ACMDCRCERR BIT(5) > +#define MSDC_INT_CMDRDY BIT(8) > +#define MSDC_INT_CMDTMO BIT(9) > +#define MSDC_INT_RSPCRCERR BIT(10) > +#define MSDC_INT_XFER_COMPL BIT(12) > +#define MSDC_INT_DATTMO BIT(14) > +#define MSDC_INT_DATCRCERR BIT(15) > + > +#define MSDC_FIFOCS0x14 > +#define MSDC_FIFOCS_CLR BIT(31) > +#define MSDC_FIFOCS_TXCNT_M 0xff > +#define MSDC_FIFOCS_TXCNT_S 16 > +#define MSDC_FIFOCS_RXCNT_M 0xff > +#define MSDC_FIFOCS_RXCNT_S 0 > + > +#define MSDC_TXDATA0x18 > +#define MSDC_RXDATA0x1c > + > +#define SDC_CFG0x30 > +#define SDC_CFG_DTOC_M 0xff > +#define SDC_CFG_DTOC_S 24 > +#define SDC_CFG_SDIOIDE BIT(20) > +#define SDC_CFG_SDIO BIT(19) > +#define SDC_CFG_BUSWIDTH_M 0x03 > +#define SDC_CFG_BUSWIDTH_S 16 > + > +#define SDC_CMD
Re: [U-Boot] [PATCH v11 07/16] mips: Implement {in, out}_{le, be}_{16, 32, 64} and {in, out}_8
On 15 October 2018 at 01:24, Mario Six wrote: > MIPS is the only architecture currently supported by U-Boot that does > not implement any of the in/out register access functions. > > To have a interface that is useable across architectures, add the > functions to the MIPS architecture (implemented using the __raw_write > and __raw_read functions). > > Reviewed-by: Simon Glass > Reviewed-by: Stefan Roese > Reviewed-by: Daniel Schwierzeck > Signed-off-by: Mario Six > Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 17/18] spi: mtk_qspi: add qspi driver for MT7629 SoC
On 12 October 2018 at 01:01, Ryder Lee wrote: > From: Guochun Mao > > This patch adds MT7629 qspi driver for accessing SPI NOR flash. > > Cc: Jagan Teki > Signed-off-by: Guochun Mao > --- > change since v2: > - Drop flash commands in the driver. > --- > drivers/spi/Kconfig| 7 + > drivers/spi/Makefile | 1 + > drivers/spi/mtk_qspi.c | 359 > + > 3 files changed, 367 insertions(+) > create mode 100644 drivers/spi/mtk_qspi.c > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/13] dm: doc: Update description of pre-relocation support
On 24 October 2018 at 07:36, Bin Meng wrote: > Add some description about pre-relocation driver binding, including > usage of DM_FLAG_PRE_RELOC flag and caveats. > > Signed-off-by: Bin Meng > > --- > > doc/driver-model/README.txt | 16 > 1 file changed, 12 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/19] cmd: Kconfig: Do not include EEPROM if DM_I2C is used without DM_I2C_COMPAT
On 22 October 2018 at 08:12, Jean-Jacques Hiblot wrote: > > The implementation of the EEPROM commands does not support the DM I2C API. > Prevent compilation breakage by not enabling it if the non-DM API is not > available (if DM_I2C is used without DM_I2C_COMPAT) > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Simon Glass > > --- > > Changes in v3: None > Changes in v2: > - Add missing commit log to the commit disabling CMD_EEPROM when non-DM API > is not available > > cmd/Kconfig | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_selftest: rename setup_ok
On 22 October 2018 at 15:15, Heinrich Schuchardt wrote: > The variable name setup_ok might suggest a boolean with true indicating > OK. Let's avoid the misleading name. > > %s/setup_ok/setup_status/g > > Suggested-by: Simon Glass > Signed-off-by: Heinrich Schuchardt > --- > lib/efi_selftest/efi_selftest.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 08/18] timer: MediaTek: add timer driver for MediaTek SoCs
On 12 October 2018 at 01:00, Ryder Lee wrote: > This patch adds clock source and clock event for the timer found > on the Mediatek SoCs. > > Signed-off-by: Ryder Lee > Tested-by: Matthias Brugger > --- > drivers/timer/Kconfig | 7 > drivers/timer/Makefile| 1 + > drivers/timer/mtk_timer.c | 85 > +++ > 3 files changed, 93 insertions(+) > create mode 100644 drivers/timer/mtk_timer.c Reviewed-by: Simon Glass Consider supporting the early timer too so you can use bootstage. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 17/19] drivers: core: Add the option SPL_DM_DEVICE_REMOVE to the Kconfig
On 22 October 2018 at 08:12, Jean-Jacques Hiblot wrote: > It is currently not possible to include the support to remove devices in > the SPL. This is however needed by platforms that re-select their dtb after > DM is initialized; they need to remove all the previously bound devices > before triggering a scan of the new DT. > > Add a Kconfig option to be able to include the support for device removal > in the SPL. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Simon Glass > > Seeries-changes:3 > - update commit message > > --- > > Changes in v3: None > Changes in v2: None > > drivers/core/Kconfig | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 09/18] watchdog: MediaTek: add watchdog driver for MediaTek SoCs
On 12 October 2018 at 01:00, Ryder Lee wrote: > This patch adds a common driver for the Mediatek SoC integrated > watchdog. > > Signed-off-by: Ryder Lee > Tested-by: Matthias Brugger > --- > drivers/watchdog/Kconfig | 8 +++ > drivers/watchdog/Makefile | 1 + > drivers/watchdog/mtk_wdt.c | 135 > + > 3 files changed, 144 insertions(+) > create mode 100644 drivers/watchdog/mtk_wdt.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 11/18] pinctrl: MediaTek: add pinctrl driver for MT7623 SoC
Hi Ryder, On 12 October 2018 at 01:01, Ryder Lee wrote: > This patch adds pinctrl support for MT7623 SoC. And most of the > structures are used to hold the hardware configuration for each > pin. > > Signed-off-by: Ryder Lee > Tested-by: Matthias Brugger > --- > drivers/pinctrl/mediatek/Kconfig |4 + > drivers/pinctrl/mediatek/Makefile |1 + > drivers/pinctrl/mediatek/pinctrl-mt7623.c | 1284 > + > drivers/pinctrl/mediatek/pinctrl-mtk-common.h |1 + > 4 files changed, 1290 insertions(+) > create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7623.c [..] > +void mtk_rmw(struct udevice *dev, u32 reg, u32 mask, u32 set); What is this for? It has no comment and is an exported function. We should not export things from drivers unless there is a good reason. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 03/18] arm: dts: MediaTek: add device tree for MT7623
On 12 October 2018 at 01:00, Ryder Lee wrote: > This adds device tree for MT7623 development board - Bananapi R2 > Detailed hardware information for BPI-R2 which could be found on > http://wiki.banana-pi.org/Banana_Pi_BPI-R2. > > Signed-off-by: Ryder Lee > Tested-by: Matthias Brugger > --- > arch/arm/dts/Makefile| 1 + > arch/arm/dts/mt7623.dtsi | 255 +++ > arch/arm/dts/mt7623n-bananapi-bpi-r2.dts | 207 > include/dt-bindings/clock/mt7623-clk.h | 413 > +++ > include/dt-bindings/power/mt7623-power.h | 19 ++ > 5 files changed, 895 insertions(+) > create mode 100644 arch/arm/dts/mt7623.dtsi > create mode 100644 arch/arm/dts/mt7623n-bananapi-bpi-r2.dts > create mode 100644 include/dt-bindings/clock/mt7623-clk.h > create mode 100644 include/dt-bindings/power/mt7623-power.h Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 04/18] arm: MediaTek: add basic support for MT7629 boards
Hi Ryder, On 12 October 2018 at 01:00, Ryder Lee wrote: > This adds a general board file based on MT7629 SoCs from MediaTek. > > Apart from the generic parts (cpu) we add some low level init codes > and initialize the early clocks. > > Signed-off-by: Ryder Lee > Signed-off-by: Weijie Gao > --- > arch/arm/Kconfig | 14 +++ > arch/arm/Makefile | 1 + > arch/arm/include/asm/arch-mediatek/misc.h | 17 > arch/arm/mach-mediatek/Kconfig| 24 + > arch/arm/mach-mediatek/Makefile | 6 ++ > arch/arm/mach-mediatek/cpu.c | 34 +++ > arch/arm/mach-mediatek/init.h | 11 +++ > arch/arm/mach-mediatek/mt7629/Makefile| 4 + > arch/arm/mach-mediatek/mt7629/init.c | 131 > ++ > arch/arm/mach-mediatek/mt7629/lowlevel_init.S | 50 ++ > arch/arm/mach-mediatek/spl.c | 43 + > board/mediatek/mt7629/Kconfig | 17 > board/mediatek/mt7629/MAINTAINERS | 7 ++ > board/mediatek/mt7629/Makefile| 3 + > board/mediatek/mt7629/mt7629_rfb.c| 16 > configs/mt7629_rfb_defconfig | 73 ++ > include/configs/mt7629.h | 62 > 17 files changed, 513 insertions(+) > create mode 100644 arch/arm/include/asm/arch-mediatek/misc.h > create mode 100644 arch/arm/mach-mediatek/Kconfig > create mode 100644 arch/arm/mach-mediatek/Makefile > create mode 100644 arch/arm/mach-mediatek/cpu.c > create mode 100644 arch/arm/mach-mediatek/init.h > create mode 100644 arch/arm/mach-mediatek/mt7629/Makefile > create mode 100644 arch/arm/mach-mediatek/mt7629/init.c > create mode 100644 arch/arm/mach-mediatek/mt7629/lowlevel_init.S > create mode 100644 arch/arm/mach-mediatek/spl.c > create mode 100644 board/mediatek/mt7629/Kconfig > create mode 100644 board/mediatek/mt7629/MAINTAINERS > create mode 100644 board/mediatek/mt7629/Makefile > create mode 100644 board/mediatek/mt7629/mt7629_rfb.c > create mode 100644 configs/mt7629_rfb_defconfig > create mode 100644 include/configs/mt7629.h Looks good. A few nits below > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index ccf2a84..eac03f0 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -668,6 +668,18 @@ config ARCH_MESON > targeted at media players and tablet computers. We currently > support the S905 (GXBaby) 64-bit SoC. > > +config ARCH_MEDIATEK > + bool "MediaTek SoCs" > + select DM > + select OF_CONTROL > + select SPL_DM if SPL > + select SPL_LIBCOMMON_SUPPORT if SPL > + select SPL_LIBGENERIC_SUPPORT if SPL > + select SPL_OF_CONTROL if SPL > + select SUPPORT_SPL > + help > + Support for the MediaTek SoCs family. Please add more info. What type of SoCs are these? What are the capabilities? Link to web site? datasheets? wiki? Or maybe point to a doc/README.mediatek? > + > config ARCH_MX8M > bool "NXP i.MX8M platform" > select ARM64 > @@ -1423,6 +1435,8 @@ source "arch/arm/mach-rmobile/Kconfig" > > source "arch/arm/mach-meson/Kconfig" > > +source "arch/arm/mach-mediatek/Kconfig" > + > source "arch/arm/mach-qemu/Kconfig" > > source "arch/arm/mach-rockchip/Kconfig" > diff --git a/arch/arm/Makefile b/arch/arm/Makefile > index 8f50560..ddb9618 100644 > --- a/arch/arm/Makefile > +++ b/arch/arm/Makefile > @@ -62,6 +62,7 @@ machine-$(CONFIG_ARCH_K3) += k3 > machine-$(CONFIG_ARCH_KEYSTONE)+= keystone > # TODO: rename CONFIG_KIRKWOOD -> CONFIG_ARCH_KIRKWOOD > machine-$(CONFIG_KIRKWOOD) += kirkwood > +machine-$(CONFIG_ARCH_MEDIATEK)+= mediatek > machine-$(CONFIG_ARCH_MESON) += meson > machine-$(CONFIG_ARCH_MVEBU) += mvebu > # TODO: rename CONFIG_TEGRA -> CONFIG_ARCH_TEGRA > diff --git a/arch/arm/include/asm/arch-mediatek/misc.h > b/arch/arm/include/asm/arch-mediatek/misc.h > new file mode 100644 > index 000..2530e78 > --- /dev/null > +++ b/arch/arm/include/asm/arch-mediatek/misc.h > @@ -0,0 +1,17 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * Copyright (C) 2018 MediaTek Inc. > + */ > + > +#ifndef __MEDIATEK_MISC_H_ > +#define __MEDIATEK_MISC_H_ > + > +#define VER_BASE 0x0800 > +#define VER_SIZE 0x10 > + > +#define APHW_CODE 0x00 > +#define APHW_SUBCODE 0x04 > +#define APHW_VER 0x08 > +#define APSW_VER 0x0c > + > +#endif /* __MEDIATEK_MISC_H_ */ > diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig > new file mode 100644 > index 000..a932e70 > --- /dev/null > +++ b/arch/arm/mach-mediatek/Kconfig > @@ -0,0 +1,24 @@ > +if ARCH_MEDIATEK > + > +config SYS_SOC > + default "mediatek" > + > +config SYS_VENDOR > + default
Re: [U-Boot] [PATCH v2 15/18] ram: MediaTek: add DDR3 driver for MT7629 SoC
On 12 October 2018 at 01:01, Ryder Lee wrote:
> This patch adds a DDR3 driver for MT7629 SoC.
>
> Signed-off-by: Wu Zou
> Signed-off-by: Ryder Lee
> ---
> drivers/ram/Makefile | 1 +
> drivers/ram/mediatek/Makefile | 7 +
> drivers/ram/mediatek/ddr3-mt7629.c | 766
> +
> 3 files changed, 774 insertions(+)
> create mode 100644 drivers/ram/mediatek/Makefile
> create mode 100644 drivers/ram/mediatek/ddr3-mt7629.c
Reviewed-by: Simon Glass
Thoughts below.
[..]
> +#define DDRPHY_PLL10x
> +#define DDRPHY_PLL20x0004
Why not use a C struct for these registers?
[..]
> + writel(0x400, priv->dramc_ao + DRAMC_MRS);
> + writel(0x1d7000, priv->dramc_ao + DRAMC_MRS);
> + writel(0x1, priv->dramc_ao + DRAMC_SPCMD);
> + writel(0x0, priv->dramc_ao + DRAMC_SPCMD);
> + udelay(100);
Are these delays specified in a datasheet? Why did you chose 100?
Perhaps add an enum for this value? Is there a way to check for when
the hardware is ready, e.g. by reading a registers in a loop?
[..]
> +static int mtk_ddr3_probe(struct udevice *dev)
> +{
> + struct mtk_ddr3_priv *priv = dev_get_priv(dev);
> +
> + priv->emi = dev_read_addr_index(dev, 0);
> + if (priv->emi == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + priv->ddrphy = dev_read_addr_index(dev, 1);
> + if (priv->ddrphy == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + priv->dramc_ao = dev_read_addr_index(dev, 2);
> + if (priv->dramc_ao == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> +#ifdef CONFIG_SPL_BUILD
> + int ret;
> +
> + ret = clk_get_by_index(dev, 0, >phy);
> + if (ret)
> + return ret;
> +
> + ret = clk_get_by_index(dev, 1, >phy_mux);
> + if (ret)
> + return ret;
> +
> + ret = clk_get_by_index(dev, 2, >mem);
> + if (ret)
> + return ret;
> +
> + ret = clk_get_by_index(dev, 3, >mem_mux);
> + if (ret)
> + return ret;
Do you have phandles for these clocks? I only worry that it is a bit
brittle to have them numbered.
> +
> + ret = mtk_ddr3_init(dev);
> + if (ret)
> + return ret;
> +#endif
> + return 0;
> +}
> +
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 11/13] video: simplefb: Remove DM_FLAG_PRE_RELOC flag
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/video/simplefb.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 12/13] watchdog: Remove DM_FLAG_PRE_RELOC flag in various drivers
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/watchdog/ast_wdt.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 14/18] serial: 16550: allow the driver to support MediaTek serial
On 12 October 2018 at 01:01, Ryder Lee wrote: > This patch adds an extra operation in ns16550.c to suuport MediaTek > SoCs as we have a highspeed register which influences the calcualtion > of the divisor. > > Note that we don't support the baudrate greater than 115200 currently. > > Signed-off-by: Ryder Lee > Tested-by: Matthias Brugger > --- > drivers/serial/ns16550.c | 10 ++ > 1 file changed, 10 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 06/18] clk: MediaTek: add clock driver for MT7629 SoC.
Hi Ryder,
On 12 October 2018 at 01:00, Ryder Lee wrote:
> This patch adds clock modules for MediaTek SoCs:
> - Shared part: a common driver which contains the general operations
> for plls, muxes, dividers and gates so that we can reuse it in future.
>
> - Specific SoC part: the group of structures used to hold the hardware
> configuration for each SoC.
>
> We take MT7629 as an example to demonstrate how to implement driver if
> any other MediaTek chips would like to use it.
>
> Signed-off-by: Ryder Lee
> ---
> drivers/clk/Makefile | 1 +
> drivers/clk/mediatek/Makefile | 6 +
> drivers/clk/mediatek/clk-mt7629.c | 709
> ++
> drivers/clk/mediatek/clk-mtk.c| 492 ++
> drivers/clk/mediatek/clk-mtk.h| 153
> 5 files changed, 1361 insertions(+)
> create mode 100644 drivers/clk/mediatek/Makefile
> create mode 100644 drivers/clk/mediatek/clk-mt7629.c
> create mode 100644 drivers/clk/mediatek/clk-mtk.c
> create mode 100644 drivers/clk/mediatek/clk-mtk.h
Looks good except for a few things below.
[..]
> +const struct clk_ops mtk_clk_gate_ops = {
> + .enable = mtk_clk_gate_enable,
> + .disable = mtk_clk_gate_disable,
> + .get_rate = mtk_clk_gate_get_rate,
> +};
> +
> +int mtk_clk_init(struct udevice *dev, const struct mtk_clk_tree *tree)
> +{
> + struct mtk_clk_priv *priv = dev_get_priv(dev);
> +
> + priv->base = dev_read_addr_ptr(dev);
> + if (!priv->base)
> + return -ENOENT;
Why do you export these two functions? Devices should be probed in the
normal DM way.
> +
> + priv->tree = tree;
> +
> + return 0;
> +}
> +
> +int mtk_clk_gate_init(struct udevice *dev,
> + const struct mtk_clk_tree *tree,
> + const struct mtk_gate *gates)
> +{
> + struct mtk_cg_priv *priv = dev_get_priv(dev);
> +
> + priv->base = dev_read_addr_ptr(dev);
> + if (!priv->base)
> + return -ENOENT;
> +
> + priv->tree = tree;
> + priv->gates = gates;
> +
> + return 0;
> +}
[...]
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 12/18] power domain: MediaTek: add power domain driver for MT7629 SoC
On 12 October 2018 at 01:01, Ryder Lee wrote: > This adds a power domain driver for the Mediatek SCPSYS unit. > > The System Control Processor System (SCPSYS) has several power > management related tasks in the system. The tasks include thermal > measurement, dynamic voltage frequency scaling (DVFS), interrupt > filter and lowlevel sleep control. The System Power Manager (SPM) > inside the SCPSYS is for the MTCMOS power domain control. > > For now this driver only adds power domain support. > > Signed-off-by: Ryder Lee > --- > drivers/power/domain/Kconfig| 7 + > drivers/power/domain/Makefile | 1 + > drivers/power/domain/mtk-power-domain.c | 326 > > 3 files changed, 334 insertions(+) > create mode 100644 drivers/power/domain/mtk-power-domain.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 01/18] tools: MediaTek: add MTK boot header generation to mkimage
Hi Ryder, On 12 October 2018 at 01:00, Ryder Lee wrote: > This patch adds support for MTK boot image generation. > > Signed-off-by: Weijie Gao > Signed-off-by: Ryder Lee > --- > Makefile | 22 ++ > common/image.c | 1 + > include/image.h | 1 + > scripts/Makefile.spl | 11 + > tools/Makefile | 1 + > tools/mtkimage.c | 749 > +++ > tools/mtkimage.h | 199 ++ > 7 files changed, 984 insertions(+) > create mode 100644 tools/mtkimage.c > create mode 100644 tools/mtkimage.h The mkimage stuff looks fine. But can you use binman for the pad/cat part of this? See for example sunxi. - sunxi-u-boot.dtsi Also mtkimage.c is too close to mkimage.c - how about mtk_image.c ? Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 07/18] clk: MediaTek: add clock driver for MT7623 SoC.
On 12 October 2018 at 01:00, Ryder Lee wrote: > This patch adds a driver for MT7623 clock blocks. > > Signed-off-by: Ryder Lee > Tested-by: Matthias Brugger > --- > drivers/clk/mediatek/Makefile | 1 + > drivers/clk/mediatek/clk-mt7623.c | 870 > ++ > 2 files changed, 871 insertions(+) > create mode 100644 drivers/clk/mediatek/clk-mt7623.c Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/13] pinctrl: Remove DM_FLAG_PRE_RELOC flag in various drivers
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/pinctrl/broadcom/pinctrl-bcm283x.c | 2 ++ > drivers/pinctrl/exynos/pinctrl-exynos7420.c | 1 - > drivers/pinctrl/nxp/pinctrl-imx5.c | 2 ++ > drivers/pinctrl/nxp/pinctrl-imx6.c | 2 ++ > drivers/pinctrl/nxp/pinctrl-imx7.c | 2 ++ > drivers/pinctrl/nxp/pinctrl-imx7ulp.c| 2 ++ > drivers/pinctrl/pinctrl-single.c | 1 - > drivers/pinctrl/uniphier/pinctrl-uniphier-pro4.c | 2 ++ > drivers/pinctrl/uniphier/pinctrl-uniphier-pro5.c | 2 ++ > 9 files changed, 14 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 05/18] arm: MediaTek: add basic support for MT7623 boards
Hi, On 12 October 2018 at 01:00, Ryder Lee wrote: > From: Weijie Gao > > This adds a general board file based on MT7623 SoCs from MediaTek. > > As this u-boot is loaded by preloader, there is no low level > initializtion codes. > > Signed-off-by: Weijie Gao > Signed-off-by: Ryder Lee > Tested-by: Matthias Brugger > --- > arch/arm/mach-mediatek/Kconfig| 8 +++ > arch/arm/mach-mediatek/Makefile | 1 + > arch/arm/mach-mediatek/mt7623/Makefile| 4 ++ > arch/arm/mach-mediatek/mt7623/init.c | 54 +++ > arch/arm/mach-mediatek/mt7623/lowlevel_init.S | 22 ++ > arch/arm/mach-mediatek/mt7623/preloader.h | 99 > +++ > board/mediatek/mt7623/Kconfig | 13 > board/mediatek/mt7623/MAINTAINERS | 7 ++ > board/mediatek/mt7623/Makefile| 3 + > board/mediatek/mt7623/mt7623_rfb.c| 16 + > configs/mt7623n_bpir2_defconfig | 53 ++ > include/configs/mt7623.h | 61 + > 12 files changed, 341 insertions(+) > create mode 100644 arch/arm/mach-mediatek/mt7623/Makefile > create mode 100644 arch/arm/mach-mediatek/mt7623/init.c > create mode 100644 arch/arm/mach-mediatek/mt7623/lowlevel_init.S > create mode 100644 arch/arm/mach-mediatek/mt7623/preloader.h > create mode 100644 board/mediatek/mt7623/Kconfig > create mode 100644 board/mediatek/mt7623/MAINTAINERS > create mode 100644 board/mediatek/mt7623/Makefile > create mode 100644 board/mediatek/mt7623/mt7623_rfb.c > create mode 100644 configs/mt7623n_bpir2_defconfig > create mode 100644 include/configs/mt7623.h > There is a new SPL handoff and bloblist feature that I hope will land in the next release. Can you please look at using this instead of an SoC-specififc mechanism? See u-boot-dm/spl-working Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 13/18] power domain: MediaTek: add power domain driver for MT7623 SoC
On 12 October 2018 at 01:01, Ryder Lee wrote: > This adds power domain (scpsys) support for MT7623 SoC. > > Signed-off-by: Ryder Lee > --- > drivers/power/domain/mtk-power-domain.c | 80 > + > 1 file changed, 80 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 02/18] arm: dts: MediaTek: add device tree for MT7629
On 12 October 2018 at 01:00, Ryder Lee wrote: > This patch adds MT7629 device tree and the includes it needs. > > Signed-off-by: Ryder Lee > --- > arch/arm/dts/Makefile| 3 + > arch/arm/dts/mt7629-rfb.dts | 71 + > arch/arm/dts/mt7629.dtsi | 244 > +++ > include/dt-bindings/clock/mt7629-clk.h | 206 ++ > include/dt-bindings/power/mt7629-power.h | 13 ++ > 5 files changed, 537 insertions(+) > create mode 100644 arch/arm/dts/mt7629-rfb.dts > create mode 100644 arch/arm/dts/mt7629.dtsi > create mode 100644 include/dt-bindings/clock/mt7629-clk.h > create mode 100644 include/dt-bindings/power/mt7629-power.h Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/13] ram: bmips: Remove DM_FLAG_PRE_RELOC flag
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/ram/bmips_ram.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 18/18] MAINTAINERS: add an entry for MediaTek
On 12 October 2018 at 01:01, Ryder Lee wrote: > This patch adds an entry for MediaTek. > > Signed-off-by: Ryder Lee > --- > MAINTAINERS | 18 ++ > 1 file changed, 18 insertions(+) Reviewed-by: Simon Glass Please also add something like README.mediatek explaining what boards are supported and how to build and put on a board (or two). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 10/18] pinctrl: MediaTek: add pinctrl driver for MT7629 SoC
Hi Ryder,
On 12 October 2018 at 01:00, Ryder Lee wrote:
> This patch adds pinctrl support for MT7629 SoC. The IO core found on
> the SoC has the registers for pinctrl, pinconf and gpio mixed up in
> the same register range. Hence the driver also implements the gpio
> functionality through UCLASS_GPIO.
>
> This also creates a common file as there might be other chips that use
> the same binding and driver, then being a little more abstract could
> help in the long run.
>
> Signed-off-by: Ryder Lee
> ---
> arch/arm/include/asm/arch-mediatek/gpio.h | 9 +
> drivers/pinctrl/Kconfig | 1 +
> drivers/pinctrl/Makefile | 1 +
> drivers/pinctrl/mediatek/Kconfig | 11 +
> drivers/pinctrl/mediatek/Makefile | 6 +
> drivers/pinctrl/mediatek/pinctrl-mt7629.c | 488 +++
> drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 552
> ++
> drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 182 +
> 8 files changed, 1250 insertions(+)
> create mode 100644 arch/arm/include/asm/arch-mediatek/gpio.h
> create mode 100644 drivers/pinctrl/mediatek/Kconfig
> create mode 100644 drivers/pinctrl/mediatek/Makefile
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt7629.c
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-common.h
>
[..]
> +int mtk_pinctrl_probe(struct udevice *dev, struct mtk_pinctrl_soc *soc)
> +{
> + struct mtk_pinctrl_priv *priv = dev_get_priv(dev);
> + int ret;
> +
> + priv->base = dev_read_addr_ptr(dev);
> + if (priv->base == (void *)FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + priv->soc = soc;
> +
> + ret = mtk_gpiochip_register(dev);
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
How come this function is exported? It should be probed like any other driver.
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] efi_selftest: do not write to linker generated array
Hi Heinrich,
On 22 October 2018 at 15:14, Heinrich Schuchardt wrote:
> On 10/22/2018 07:49 PM, Simon Glass wrote:
>> Hi Heinrich,
>>
>> On 18 October 2018 at 23:51, Heinrich Schuchardt wrote:
>>> Linker generated arrays may be stored in code sections of memory that are
>>> not writable. So let's allocate setup_ok as an array at runtime.
>>>
>>> This avoids an illegal memory access observed in the sandbox.
>>>
>>> Reported-by: Simon Glass
>>> Signed-off-by: Heinrich Schuchardt
>>> ---
>>> include/efi_selftest.h | 2 --
>>> lib/efi_selftest/efi_selftest.c | 31 ++-
>>> 2 files changed, 22 insertions(+), 11 deletions(-)
>>
>> Reviewed-by: Simon Glass
>>
>> Thanks for doing this!
>>
>>>
>>> diff --git a/include/efi_selftest.h b/include/efi_selftest.h
>>> index 56beac305e..49d3d6d0b4 100644
>>> --- a/include/efi_selftest.h
>>> +++ b/include/efi_selftest.h
>>> @@ -129,7 +129,6 @@ u16 efi_st_get_key(void);
>>> * @setup: set up the unit test
>>> * @teardown: tear down the unit test
>>> * @execute: execute the unit test
>>> - * @setup_ok: setup was successful (set at runtime)
>>
>> I'm not keen on the name setup_ok, which suggests a bool which would
>> be true if it is OK.
>>
>> How about setup_err or setup_ret?
>>
>>> * @on_request:test is only executed on request
>>> */
>>> struct efi_unit_test {
>>> @@ -139,7 +138,6 @@ struct efi_unit_test {
>>> const struct efi_system_table *systable);
>>> int (*execute)(void);
>>> int (*teardown)(void);
>>> - int setup_ok;
>>> bool on_request;
>>> };
>>>
>>> diff --git a/lib/efi_selftest/efi_selftest.c
>>> b/lib/efi_selftest/efi_selftest.c
>>> index dd338db687..fc7866365d 100644
>>> --- a/lib/efi_selftest/efi_selftest.c
>>> +++ b/lib/efi_selftest/efi_selftest.c
>>> @@ -18,6 +18,7 @@ static const struct efi_boot_services *boottime;
>>> static const struct efi_runtime_services *runtime;
>>> static efi_handle_t handle;
>>> static u16 reset_message[] = L"Selftest completed";
>>> +static int *setup_ok;
>>>
>>> /*
>>> * Exit the boot services.
>>> @@ -74,20 +75,20 @@ void efi_st_exit_boot_services(void)
>>> */
>>> static int setup(struct efi_unit_test *test, unsigned int *failures)
>>> {
>>> - if (!test->setup) {
>>> - test->setup_ok = EFI_ST_SUCCESS;
>>> + int ret;
>>> +
>>> + if (!test->setup)
>>> return EFI_ST_SUCCESS;
>>> - }
>>> efi_st_printc(EFI_LIGHTBLUE, "\nSetting up '%s'\n", test->name);
>>> - test->setup_ok = test->setup(handle, systable);
>>> - if (test->setup_ok != EFI_ST_SUCCESS) {
>>> + ret = test->setup(handle, systable);
>>> + if (ret != EFI_ST_SUCCESS) {
>>> efi_st_error("Setting up '%s' failed\n", test->name);
>>> ++*failures;
>>> } else {
>>> efi_st_printc(EFI_LIGHTGREEN,
>>> "Setting up '%s' succeeded\n", test->name);
>>> }
>>> - return test->setup_ok;
>>> + return ret;
>>> }
>>>
>>> /*
>>> @@ -186,18 +187,20 @@ static void list_all_tests(void)
>>> void efi_st_do_tests(const u16 *testname, unsigned int phase,
>>> unsigned int steps, unsigned int *failures)
>>> {
>>> + int i = 0;
>>> struct efi_unit_test *test;
>>>
>>> for (test = ll_entry_start(struct efi_unit_test, efi_unit_test);
>>> -test < ll_entry_end(struct efi_unit_test, efi_unit_test);
>>> ++test) {
>>> +test < ll_entry_end(struct efi_unit_test, efi_unit_test);
>>> +++test, ++i) {
>>> if (testname ?
>>> efi_st_strcmp_16_8(testname, test->name) :
>>> test->on_request)
>>> continue;
>>> if (test->phase != phase)
>>> continue;
>>> if (steps & EFI_ST_SETUP)
>>> - setup(test, failures);
>>> - if (steps & EFI_ST_EXECUTE && test->setup_ok ==
>>> EFI_ST_SUCCESS)
>>> + setup_ok[i] = setup(test, failures);
>>> + if (steps & EFI_ST_EXECUTE && setup_ok[i] == EFI_ST_SUCCESS)
>>> execute(test, failures);
>>> if (steps & EFI_ST_TEARDOWN)
>>> teardown(test, failures);
>>> @@ -271,6 +274,16 @@ efi_status_t EFIAPI efi_selftest(efi_handle_t
>>> image_handle,
>>> ll_entry_count(struct efi_unit_test,
>>> efi_unit_test));
>>>
>>> + /* Allocate buffer for setup results */
>>> + ret = boottime->allocate_pool(EFI_RUNTIME_SERVICES_DATA,
>>> sizeof(int) *
>>> + ll_entry_count(struct efi_unit_test,
>>> +efi_unit_test),
>>> + (void **)_ok);
>>
>> Isn't this calling the
Re: [U-Boot] [PATCH 09/13] serial: Remove DM_FLAG_PRE_RELOC flag in various drivers
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/serial/altera_jtag_uart.c | 1 - > drivers/serial/altera_uart.c | 1 - > drivers/serial/arm_dcc.c | 1 - > drivers/serial/atmel_usart.c | 2 ++ > drivers/serial/ns16550.c | 2 ++ > drivers/serial/serial_ar933x.c| 1 - > drivers/serial/serial_arc.c | 1 - > drivers/serial/serial_bcm283x_mu.c| 2 ++ > drivers/serial/serial_bcm283x_pl011.c | 2 ++ > drivers/serial/serial_bcm6345.c | 1 - > drivers/serial/serial_efi.c | 1 - > drivers/serial/serial_intel_mid.c | 1 - > drivers/serial/serial_lpuart.c| 1 - > drivers/serial/serial_meson.c | 1 - > drivers/serial/serial_mvebu_a3700.c | 1 - > drivers/serial/serial_mxc.c | 2 ++ > drivers/serial/serial_omap.c | 2 ++ > drivers/serial/serial_owl.c | 1 - > drivers/serial/serial_pic32.c | 1 - > drivers/serial/serial_pl01x.c | 2 ++ > drivers/serial/serial_s5p.c | 1 - > drivers/serial/serial_sh.c| 2 ++ > drivers/serial/serial_sti_asc.c | 1 - > drivers/serial/serial_stm32.c | 2 ++ > drivers/serial/serial_xuartlite.c | 1 - > drivers/serial/serial_zynq.c | 1 - > 26 files changed, 18 insertions(+), 17 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] gpio: Remove DM_FLAG_PRE_RELOC flag in various drivers
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/gpio/omap_gpio.c | 2 ++ > drivers/gpio/stm32f7_gpio.c | 2 +- > drivers/gpio/tegra186_gpio.c | 1 - > drivers/gpio/tegra_gpio.c| 1 - > 4 files changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 05/13] mmc: omap: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/mmc/omap_hsmmc.c | 2 ++ > 1 file changed, 2 insertions(+) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 04/13] i2c: omap24xx: Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/i2c/omap24xx_i2c.c | 2 ++ > 1 file changed, 2 insertions(+) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 08/13] timer: Remove DM_FLAG_PRE_RELOC flag in various drivers
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/timer/ag101p_timer.c| 1 - > drivers/timer/altera_timer.c| 1 - > drivers/timer/arc_timer.c | 1 - > drivers/timer/ast_timer.c | 1 - > drivers/timer/atcpit100_timer.c | 1 - > drivers/timer/atmel_pit_timer.c | 1 - > drivers/timer/cadence-ttc.c | 1 - > drivers/timer/dw-apb-timer.c| 1 - > drivers/timer/mpc83xx_timer.c | 1 - > drivers/timer/omap-timer.c | 1 - > drivers/timer/rockchip_timer.c | 1 - > drivers/timer/sti-timer.c | 1 - > drivers/timer/stm32_timer.c | 1 - > drivers/timer/tsc_timer.c | 1 - > 14 files changed, 14 deletions(-) > Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 10/13] sysreset: Remove DM_FLAG_PRE_RELOC flag in various drivers
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > arch/x86/cpu/tangier/sysreset.c | 1 - > drivers/sysreset/sysreset_x86.c | 1 - > lib/efi/efi_app.c | 1 - > 3 files changed, 3 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/13] clk: Remove DM_FLAG_PRE_RELOC flag in various drivers
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > drivers/clk/altera/clk-arria10.c| 1 - > drivers/clk/clk_pic32.c | 1 - > drivers/clk/clk_zynq.c | 1 - > drivers/clk/exynos/clk-exynos7420.c | 3 --- > drivers/clk/owl/clk_s900.c | 1 - > 5 files changed, 7 deletions(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/13] arm: stm32mp: Remove DM_FLAG_PRE_RELOC flag
On 24 October 2018 at 07:36, Bin Meng wrote: > When a driver declares DM_FLAG_PRE_RELOC flag, it wishes to be > bound before relocation. However due to a bug in the DM core, > the flag only takes effect when devices are statically declared > via U_BOOT_DEVICE(). This bug has been fixed recently by commit > "dm: core: Respect drivers with the DM_FLAG_PRE_RELOC flag in > lists_bind_fdt()", but with the fix, it has a side effect that > all existing drivers that declared DM_FLAG_PRE_RELOC flag will > be bound before relocation now. This may expose potential boot > failure on some boards due to insufficient memory during the > pre-relocation stage. > > To mitigate this potential impact, the following changes are > implemented: > > - Remove DM_FLAG_PRE_RELOC flag in the driver, if the driver > only supports configuration from device tree (OF_CONTROL) > - Keep DM_FLAG_PRE_RELOC flag in the driver only if the device > is statically declared via U_BOOT_DEVICE() > - Surround DM_FLAG_PRE_RELOC flag with OF_CONTROL check, for > drivers that support both statically declared devices and > configuration from device tree > > Signed-off-by: Bin Meng > --- > > arch/arm/mach-stm32mp/bsec.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
Bin Meng 於 2018年10月25日 週四 上午11:16寫道：
>
> Hi Rick,
>
> On Thu, Oct 25, 2018 at 11:11 AM Rick Chen wrote:
> >
> > Bin Meng 於 2018年10月25日 週四 上午10:33寫道：
> > >
> > > Hi Rick,
> > >
> > > On Thu, Oct 25, 2018 at 9:20 AM Andes wrote:
> > > >
> > > > From: Rick Chen
> > > >
> > > > ax25-ae350 use CONFIG_OF_BOARD which allow the board to
> > > > override the fdt address. And prior_stage_fdt_address offer
> > > > a temporary memory address to keep the dtb address which was
> > > > passed from loader(gdb) to u-boot with a1.
> > >
> > > nits: U-Boot
> > >
> > > >
> > > > Signed-off-by: Rick Chen
> > > > Cc: Greentime Hu
> > > > ---
> > > > board/AndesTech/ax25-ae350/ax25-ae350.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > index 5f4ca0f..d343453 100644
> > > > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > > @@ -14,6 +14,7 @@
> > > >
> > > > DECLARE_GLOBAL_DATA_PTR;
> > > >
> > > > +extern phys_addr_t prior_stage_fdt_address;
> > > > /*
> > > > * Miscellaneous platform dependent initializations
> > > > */
> > > > @@ -66,7 +67,7 @@ ulong board_flash_get_legacy(ulong base, int banknum,
> > > > flash_info_t *info)
> > > >
> > > > void *board_fdt_blob_setup(void)
> > > > {
> > > > - void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > > + void **ptr = (void *)_stage_fdt_address;
> > > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > > return (void *)*ptr;
> > > >
> > > > --
> > >
> > > board_fdt_blob_setup() should be completely removed. Instead the
> > > simple fix should be add CONFIG_OF_PRIOR_STAGE to your board defconfig
> > > files.
> > >
> >
> > Hi Bin
> >
> > I have tried to switch from CONFIG_OF_BOARD to CONFIG_OF_PRIOR_STAGE.
> >
> > But it will lost the function
> > that dtb will be pre-burned into designated flash location,
> > when U-Boot was booting from flash.
> >
>
> I don't get it. Do you mean on ae350 board, the DTB is pre-flashed on the
> flash?
>
Yes
On ae350 board, the DTB is pre-flashed on the flash in booting from rom case.
u-boot boot from ram case:
CONFIG_OF_PRIOR_STAGE can achieve u-boot boot from ram and dtb was
passed by loader with a1(0xf).
u-boot boot from rom case:
If DTB is pre-flashed on the flash 0x800f (This address can be
dynamically changed)
But no one assign a1=0x800f000, how can be gd->fdt_blob changed to 0x800f000.
I am wondering about that ?
0xf is ram space
0x800f is flash rom space
Rick
> > How can I achieve that with CONFIG_OF_PRIOR_STAGE ?
>
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
Hi Rick,
On Thu, Oct 25, 2018 at 11:11 AM Rick Chen wrote:
>
> Bin Meng 於 2018年10月25日 週四 上午10:33寫道：
> >
> > Hi Rick,
> >
> > On Thu, Oct 25, 2018 at 9:20 AM Andes wrote:
> > >
> > > From: Rick Chen
> > >
> > > ax25-ae350 use CONFIG_OF_BOARD which allow the board to
> > > override the fdt address. And prior_stage_fdt_address offer
> > > a temporary memory address to keep the dtb address which was
> > > passed from loader(gdb) to u-boot with a1.
> >
> > nits: U-Boot
> >
> > >
> > > Signed-off-by: Rick Chen
> > > Cc: Greentime Hu
> > > ---
> > > board/AndesTech/ax25-ae350/ax25-ae350.c | 3 ++-
> > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > index 5f4ca0f..d343453 100644
> > > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > > @@ -14,6 +14,7 @@
> > >
> > > DECLARE_GLOBAL_DATA_PTR;
> > >
> > > +extern phys_addr_t prior_stage_fdt_address;
> > > /*
> > > * Miscellaneous platform dependent initializations
> > > */
> > > @@ -66,7 +67,7 @@ ulong board_flash_get_legacy(ulong base, int banknum,
> > > flash_info_t *info)
> > >
> > > void *board_fdt_blob_setup(void)
> > > {
> > > - void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > > + void **ptr = (void *)_stage_fdt_address;
> > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > return (void *)*ptr;
> > >
> > > --
> >
> > board_fdt_blob_setup() should be completely removed. Instead the
> > simple fix should be add CONFIG_OF_PRIOR_STAGE to your board defconfig
> > files.
> >
>
> Hi Bin
>
> I have tried to switch from CONFIG_OF_BOARD to CONFIG_OF_PRIOR_STAGE.
>
> But it will lost the function
> that dtb will be pre-burned into designated flash location,
> when U-Boot was booting from flash.
>
I don't get it. Do you mean on ae350 board, the DTB is pre-flashed on the flash?
> How can I achieve that with CONFIG_OF_PRIOR_STAGE ?
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
Bin Meng 於 2018年10月25日 週四 上午10:33寫道：
>
> Hi Rick,
>
> On Thu, Oct 25, 2018 at 9:20 AM Andes wrote:
> >
> > From: Rick Chen
> >
> > ax25-ae350 use CONFIG_OF_BOARD which allow the board to
> > override the fdt address. And prior_stage_fdt_address offer
> > a temporary memory address to keep the dtb address which was
> > passed from loader(gdb) to u-boot with a1.
>
> nits: U-Boot
>
> >
> > Signed-off-by: Rick Chen
> > Cc: Greentime Hu
> > ---
> > board/AndesTech/ax25-ae350/ax25-ae350.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > index 5f4ca0f..d343453 100644
> > --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > @@ -14,6 +14,7 @@
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > +extern phys_addr_t prior_stage_fdt_address;
> > /*
> > * Miscellaneous platform dependent initializations
> > */
> > @@ -66,7 +67,7 @@ ulong board_flash_get_legacy(ulong base, int banknum,
> > flash_info_t *info)
> >
> > void *board_fdt_blob_setup(void)
> > {
> > - void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > + void **ptr = (void *)_stage_fdt_address;
> > if (fdt_magic(*ptr) == FDT_MAGIC)
> > return (void *)*ptr;
> >
> > --
>
> board_fdt_blob_setup() should be completely removed. Instead the
> simple fix should be add CONFIG_OF_PRIOR_STAGE to your board defconfig
> files.
>
Hi Bin
I have tried to switch from CONFIG_OF_BOARD to CONFIG_OF_PRIOR_STAGE.
But it will lost the function
that dtb will be pre-burned into designated flash location,
when U-Boot was booting from flash.
How can I achieve that with CONFIG_OF_PRIOR_STAGE ?
Rick
> Regards,
> Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 21/30] riscv: remove CONFIG_INIT_CRITICAL
Hi Lukas, On Mon, Oct 22, 2018 at 5:19 PM Bin Meng wrote: > > Hi Lukas, > > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer > wrote: > > > > CONFIG_INIT_CRITICAL is deprecated and not used for RISC-V. Remove it. > > > > Signed-off-by: Lukas Auer > > --- > > > > arch/riscv/cpu/start.S | 11 --- > > 1 file changed, 11 deletions(-) > > > > Please see my patch which does more :) > > http://git.denx.de/?p=u-boot/u-boot-x86.git;a=commitdiff;h=1f1c216d426a6c2196f8c39f5a2d85fe35096102 You can take my patch above in your v2 if you want. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 09/30] riscv: move target selection into separate file
On Tue, Oct 23, 2018 at 10:48 AM Rick Chen wrote: > > > > Subject: Re: [PATCH 09/30] riscv: move target selection into separate file > > > > > > Hi Lukas, > > > > > > On Sat, Oct 20, 2018 at 6:10 AM Lukas Auer > > > > > > wrote: > > > > > > > > Move the target selection into a separate file (Kconfig.board) to > > > > avoid clutter once we support more boards. > > > > > > > > Signed-off-by: Lukas Auer > > > > --- > > > > > > > > arch/riscv/Kconfig | 17 ++--- > > > > arch/riscv/Kconfig.board | 14 ++ > > > > 2 files changed, 16 insertions(+), 15 deletions(-) create mode > > > > 100644 arch/riscv/Kconfig.board > > > > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index > > > > ce07fb4b55..10d17a0e18 100644 > > > > --- a/arch/riscv/Kconfig > > > > +++ b/arch/riscv/Kconfig > > > > @@ -4,21 +4,6 @@ menu "RISC-V architecture" > > > > config SYS_ARCH > > > > default "riscv" > > > > > > > > -choice > > > > - prompt "Target select" > > > > - optional > > > > - > > > > -config TARGET_AX25_AE350 > > > > - bool "Support ax25-ae350" > > > > - > > > > -config TARGET_QEMU_VIRT > > > > - bool "Support QEMU Virt Board" > > > > - > > > > -endchoice > > > > - > > > > -source "board/AndesTech/ax25-ae350/Kconfig" > > > > -source "board/emulation/qemu-riscv/Kconfig" > > > > - > > > > choice > > > > prompt "Base ISA" > > > > default ARCH_RV32I > > > > @@ -72,4 +57,6 @@ config 32BIT > > > > config 64BIT > > > > bool > > > > > > > > +source "arch/riscv/Kconfig.board" > > > > + > > > > > > I am OK with moving board one to a separate file, though it looks no > > > other arch > > > uses scuh convention in U-Boot :) > > > > > Though no other arch use Kconfig.board here. > Because RISC-V is an open architechture. > Maybe separate board option from Kconfig to Kconfig.board is an good idea. > I suggest we keep current kconfig structure for now to be in consistent with other archs. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
Hi Rick,
On Thu, Oct 25, 2018 at 9:20 AM Andes wrote:
>
> From: Rick Chen
>
> ax25-ae350 use CONFIG_OF_BOARD which allow the board to
> override the fdt address. And prior_stage_fdt_address offer
> a temporary memory address to keep the dtb address which was
> passed from loader(gdb) to u-boot with a1.
nits: U-Boot
>
> Signed-off-by: Rick Chen
> Cc: Greentime Hu
> ---
> board/AndesTech/ax25-ae350/ax25-ae350.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> b/board/AndesTech/ax25-ae350/ax25-ae350.c
> index 5f4ca0f..d343453 100644
> --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> @@ -14,6 +14,7 @@
>
> DECLARE_GLOBAL_DATA_PTR;
>
> +extern phys_addr_t prior_stage_fdt_address;
> /*
> * Miscellaneous platform dependent initializations
> */
> @@ -66,7 +67,7 @@ ulong board_flash_get_legacy(ulong base, int banknum,
> flash_info_t *info)
>
> void *board_fdt_blob_setup(void)
> {
> - void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> + void **ptr = (void *)_stage_fdt_address;
> if (fdt_magic(*ptr) == FDT_MAGIC)
> return (void *)*ptr;
>
> --
board_fdt_blob_setup() should be completely removed. Instead the
simple fix should be add CONFIG_OF_PRIOR_STAGE to your board defconfig
files.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 06/30] riscv: add Kconfig entries for the C and A ISA extensions
Hi Lukas,
On Wed, Oct 24, 2018 at 11:41 PM Auer, Lukas
wrote:
>
> Hi Bin,
>
> On Wed, 2018-10-24 at 23:32 +0800, Bin Meng wrote:
> > Hi Lukas,
> >
> > On Wed, Oct 24, 2018 at 11:21 PM Auer, Lukas
> > wrote:
> > >
> > > Hi Bin,
> > >
> > > On Mon, 2018-10-22 at 15:21 +0800, Bin Meng wrote:
> > > > Hi Lukas,
> > > >
> > > > On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer
> > > > wrote:
> > > > >
> > > > > Add Kconfig entries for the C (compressed instructions) and A
> > > > > (atomic
> > > > > instructions) ISA extensions. Only the C ISA extension is
> > > > > selectable.
> > > > > This matches the configuration in Linux.
> > > > >
> > > > > The Kconfig entries are not used yet. A follow-up patch will
> > > > > select
> > > > > the
> > > > > appropriate compiler flags based on the Kconfig configuration.
> > > > >
> > > > > Signed-off-by: Lukas Auer
> > > > > ---
> > > > >
> > > > > arch/riscv/Kconfig | 9 +
> > > > > 1 file changed, 9 insertions(+)
> > > > >
> > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > > > > index b81e0d990a..e15329c35e 100644
> > > > > --- a/arch/riscv/Kconfig
> > > > > +++ b/arch/riscv/Kconfig
> > > > > @@ -38,6 +38,15 @@ config ARCH_RV64I
> > > > >
> > > > > endchoice
> > > > >
> > > > > +config RISCV_ISA_C
> > > > > + bool "Emit compressed instructions"
> > > > > + default y
> > > > > + help
> > > > > + This enables the compressed instructions ("C") ISA
> > > > > extension.
> > > >
> > > > This is a little bit confusing. Can we use Linux kernel's
> > > > description
> > > > instead like below?
> > > >
> > > > Adds "C" to the ISA subsets that the toolchain is
> > > > allowed
> > > > to emit
> > > > when building U-Boot, which results in compressed
> > > > instructions in the
> > > > U-Boot binary.
> > > >
> > >
> > > Sure, I will change it in v2.
> > >
> > > > > +
> > > > > +config RISCV_ISA_A
> > > > > + def_bool y
> > > >
> > > > I do not believe U-Boot need to care about 'A' extension. So this
> > > > can
> > > > be dropped?
> > > >
> > >
> > > That's right. The only reason it might be used in U-Boot is on
> > > multi-
> > > core systems. Linux chooses the hart to boot on with the hart
> > > lottery,
> > > which requires atomics. The first core to increment a flag wins and
> > > starts the boot process. We could do something similar in U-Boot,
> > > but I
> > > don't think it's necessary. In my patches (for the next patch
> > > series) I
> > > have added CONFIG_MAIN_HART to select the hart U-Boot should run
> > > on.
> > >
> >
> > Thanks for the additional details. I think we will need
> > CONFIG_MAIN_HART to select the hart U-Boot should run on instead of
> > Linux's lottery game, since we need handle situation like SiFive
> > Freedom U540 where hart0 is something that does not run Linux. But
> > even with CONFIG_MAIN_HART, U-Boot still doesn't need support 'A',
> > right?
> >
>
> Yes that's right, at least I can't think of a reason for why we might
> need it. Should I drop it then?
>
Since we can use such to construct the "-march" string, let's keep this.
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 07/30] riscv: set -march and -mabi based on the Kconfig configuration
Hi Lukas, On Wed, Oct 24, 2018 at 11:57 PM Auer, Lukas wrote: > > Hi Bin, > > On Mon, 2018-10-22 at 15:21 +0800, Bin Meng wrote: > > Hi Lukas, > > > > On Sat, Oct 20, 2018 at 6:09 AM Lukas Auer > > wrote: > > > > > > Use the new Kconfig entries to construct the ISA string for the > > > -march > > > compiler flag. The -mabi compiler flag is selected based on the > > > base > > > integer instruction set. > > > > > > With this change, the C (compressed instructions) ISA extension is > > > now > > > enabled for all boards with CONFIG_RISCV_ISA_C set. Buildman > > > reports a > > > decrease in binary size of 71590 bytes. > > > > > > Signed-off-by: Lukas Auer > > > --- > > > > > > arch/riscv/Makefile | 13 + > > > arch/riscv/config.mk | 4 > > > 2 files changed, 13 insertions(+), 4 deletions(-) > > > > > > diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile > > > index 8fb6a889d8..6fb292d0b4 100644 > > > --- a/arch/riscv/Makefile > > > +++ b/arch/riscv/Makefile > > > @@ -3,6 +3,19 @@ > > > # Copyright (C) 2017 Andes Technology Corporation. > > > # Rick Chen, Andes Technology Corporation > > > > > > +riscv-march-$(CONFIG_ARCH_RV32I) := rv32im > > > +riscv-march-$(CONFIG_ARCH_RV64I) := rv64im > > > +riscv-march-$(CONFIG_RISCV_ISA_A) := $(riscv-march-y)a > > > +riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c > > > + > > > +riscv-mabi-$(CONFIG_ARCH_RV64I):= lp64 > > > +riscv-mabi-$(CONFIG_ARCH_RV32I):= ilp32 > > > + > > > +arch-y := -march=$(riscv-march-y) -mabi=$(riscv-mabi-y) > > > + > > > +PLATFORM_CPPFLAGS += $(arch-y) > > > +CFLAGS_EFI += $(arch-y) > > > + > > > > The concept of this patch is good. However the usage of := is a bit > > odd, since it makes people think the latter will override the former > > one, however it is not. > > > > Can we get rid of these riscv-mach-xxx, instead using something like > > this: > > > > ifeq ($(CONFIG_RISCV_ISA_A),y) > > ARCH_A = a > > endif > > ifeq ($(CONFIG_RISCV_ISA_C),y) > > ARCH_C = c > > endif > > > > ifeq ($(CONFIG_ARCH_RV32I),y) > > BITS = 32 > > ABI_I = i > > endif > > ifeq ($(CONFIG_ARCH_RV64I),y) > > BITS = 64 > > endif > > > > PLATFORM_CPPFLAGS += -march=rv$(BITS)im$(ARCH_A)$(ARCH_C) > > -mabi=$(ABI_I)lp$(BITS) > > > > That makes sense. Yes I can change it to something like that. > One small change I would do is to try and keep any constant ISA / ABI > strings (so rv and im) out of PLATFORM_CPPFLAGS to keep the > configuration more in one place. So something like this. What do you > think? > This looks good. Thanks! > ifeq ($(CONFIG_ARCH_RV32I),y) > ARCH_BASE = rv32im > ABI = ilp32 > endif > ifeq ($(CONFIG_ARCH_RV64I),y) > ARCH_BASE = rv64im > ABI = lp64 > endif > > PLATFORM_CPPFLAGS += -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) > -mabi=$(ABI) > Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] riscv: ax25-ae350: Pass dtb address to u-boot with a1 register
From: Rick Chen
ax25-ae350 use CONFIG_OF_BOARD which allow the board to
override the fdt address. And prior_stage_fdt_address offer
a temporary memory address to keep the dtb address which was
passed from loader(gdb) to u-boot with a1.
Signed-off-by: Rick Chen
Cc: Greentime Hu
---
board/AndesTech/ax25-ae350/ax25-ae350.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
b/board/AndesTech/ax25-ae350/ax25-ae350.c
index 5f4ca0f..d343453 100644
--- a/board/AndesTech/ax25-ae350/ax25-ae350.c
+++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
@@ -14,6 +14,7 @@
DECLARE_GLOBAL_DATA_PTR;
+extern phys_addr_t prior_stage_fdt_address;
/*
* Miscellaneous platform dependent initializations
*/
@@ -66,7 +67,7 @@ ulong board_flash_get_legacy(ulong base, int banknum,
flash_info_t *info)
void *board_fdt_blob_setup(void)
{
- void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
+ void **ptr = (void *)_stage_fdt_address;
if (fdt_magic(*ptr) == FDT_MAGIC)
return (void *)*ptr;
--
2.7.4
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 22/30] riscv: remove unused labels in start.S
Auer, Lukas 於 2018年10月24日 週三 下午10:14寫道：
>
> Hi Rick,
>
> On Wed, 2018-10-24 at 13:47 +0800, Rick Chen wrote:
> > Rick Chen 於 2018年10月24日 週三 下午1:20寫道：
> > >
> > > Bin Meng 於 2018年10月24日 週三 上午11:34寫道：
> > > >
> > > > Hi Rich,
> > > >
> > > > On Wed, Oct 24, 2018 at 10:37 AM Rick Chen
> > > > wrote:
> > > > >
> > > > > > > > The labels nmi_vector, trap_vector and handle_reset in
> > > > > > > > start.S are not
> > > > > > > > used for RISC-V. Remove them.
> > > > > > > >
> > > > >
> > > > > Hi Lukas
> > > > >
> > > > > Agree with the above part.
> > > > >
> > > > > > > > While we are here, also remove the code from the
> > > > > > > > beginning of start.S,
> > > > > > > > which stores the contents of a2 to memory. Only registers
> > > > > > > > a0 and a1
> > > > > > > > contain information from the previous boot stage. There
> > > > > > > > is therefore
> > > > > > > > no reason for saving a2.
> > > > >
> > > > > NOT agree with this part.
> > > > > Saving a2 is trying to support dynamically dtb pass at runtime.
> > > > >
> > > >
> > > > Could you please describe in more details on what the use case is
> > > > here?
> > > >
> > >
> > > Hi Bin and Lukas
> > >
> > > After I study [PATCH 24/30] riscv: save hart ID and device tree
> > > passed
> > > by prior boot stage.
> > > I found it is the same thing.
> > > I will accepted this patch.
> > > So this patch is
> > >
> > > Reviewed-by: Rick Chen
> > >
> > > But I shall send a patch to fix ax25-ae350 to work as well later.
> > > And it will be as below :
> > >
> > > ax5-ae350.c
> > > void *board_fdt_blob_setup(void)
> > > {
> > > void **ptr = (void *)_stage_fdt_address;
> > > if (fdt_magic(*ptr) == FDT_MAGIC)
> > > return (void *)*ptr;
> > >
> > > return (void *)CONFIG_SYS_FDT_BASE;
> > > }
> > >
> >
> > Sorry!
> >
> > I shall send a fixed patch as below:
> > riscv: ax25-ae350: use device tree passed by prior boot stage
> >
> > --- a/configs/ax25-ae350_defconfig
> > +++ b/configs/ax25-ae350_defconfig
> > @@ -15,7 +15,7 @@ CONFIG_CMD_SF_TEST=y
> > # CONFIG_CMD_SETEXPR is not set
> > CONFIG_BOOTP_PREFER_SERVERIP=y
> > CONFIG_CMD_CACHE=y
> > -CONFIG_OF_BOARD=y
> > +CONFIG_OF_PRIOR_STAGE=y
> >
> > +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> > @@ -64,15 +64,6 @@ ulong board_flash_get_legacy(ulong base, int
> > banknum, flash_info_t *info)
> > return 0;
> > }
> >
> > -void *board_fdt_blob_setup(void)
> > -{
> > - void **ptr = (void *)CONFIG_SYS_SDRAM_BASE;
> > - if (fdt_magic(*ptr) == FDT_MAGIC)
> > - return (void *)*ptr;
> > -
> > - return (void *)CONFIG_SYS_FDT_BASE;
> > -}
> > -
> >
> > Rick
> >
>
> Sorry, I have missed your commit. Just to clarify, does the ax25 pass
> the device tree in a2 instead of a1? In that case, my patch must be
> changed since it assumes the device tree to be in a1.
> Related to this, can I assume that a0 stores the hart ID?
>
> If you want, I can add this patch to my series.
>
Hi Lukas
Your patch is correct.
I will send out a patch to fix the mismatch in ax25-ae350 later.
And maybe you can put this patch into your v2 series.
Thanks
Rick
> Thanks,
> Lukas
>
> > >
> > > > > You can see it in the following commit :
> > > > >
> > > > > commit d58717e42559189a226ea800173147399c8edef9
> > > > > Author: Rick Chen
> > > > > Date: Thu Mar 29 10:08:33 2018 +0800
> > > > >
> > > > > riscv: ae250: Support DT provided by the board at runtime
> > > > >
> > > >
> > > > Regards,
> > > > Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when required files not exists
> -Original Message-
> From: Anatolij Gustschin [mailto:ag...@denx.de]
> Sent: 2018年10月25日 7:44
> To: Peng Fan
> Cc: sba...@denx.de; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when required files
> not exists
>
> Hi Peng,
>
> On Wed, 24 Oct 2018 09:49:04 +
> Peng Fan peng@nxp.com wrote:
> ...
> > --- /dev/null
> > +++ b/tools/imx8_cntr_image.sh
> > @@ -0,0 +1,32 @@
> > +#!/bin/sh
> > +# SPDX-License-Identifier: GPL-2.0+
> > +#
> > +# script to generate FIT image source for K3 Family boards with #
> > +ATF, OPTEE, SPL and multiple device trees (given on the command line).
> > +# Inspired from board/sunxi/mksunxi_fit_atf.sh
>
> Please drop this comment, it doesn't describe what the script is actually
> doing.
Thanks. Fix in V2.
>
> ...
> > +file=$1
> > +
> > +linecount=`cat ${file} | wc -l`
> > +
> > +for ((i=1; i<=${linecount}; i++));
> > +do
> [ snip ]
>
> blobs=`awk '/^APPEND/ {print $2} /^IMAGE/ || /^DATA/ {print $3}' $file` for f
> in
> $blobs; do
> if [ ! -f $f ]; then
> echo "WARNING '$f' not found, resulting binary is
> not-functional"
> fi;
> done
>
> will do the checks more efficiently.
Yes. Simpiler.
Thanks,
Peng.
>
> Thanks,
>
> Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when required files not exists
> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de]
> Sent: 2018年10月24日 22:09
> To: Peng Fan
> Cc: sba...@denx.de; u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when required files
> not exists
>
> Dear Peng Fan,
>
> In message <20181024095456.27486-1-peng@nxp.com> you wrote:
> > Introduce a new script to check whether file exists and use that check
> > in Makefile to avoid break CI system.
>
> Hm... this looks overly complicate to me.
>
> I think you should at least provide more documentation for this script, i. e.
> what
> it does, and what the reutrn codes mean.
Fix in V2.
>
> > +DEPFILE_EXITS := 1
> > ifeq ($(CONFIG_ARCH_IMX8), y)
> > -IMAGE_TYPE = imx8image
> > +IMAGE_TYPE := imx8image
> > +DEPFILE_EXITS := $(shell $(srctree)/tools/imx8_cntr_image.sh
> > +$(IMX_CONFIG); echo $$?)
>
> DEPFILE_EXITS ? Or ..._EXISTS ??
DEPFILE_EXISTS
>
> > +file=$1
> > +
> > +linecount=`cat ${file} | wc -l`
> > +
> > +for ((i=1; i<=${linecount}; i++));
> > +do
> > + name=`awk -F '\t' -F ' ' 'NR=='${i}' && /^APPEND/ {print $2}'
> > +${file}`
>
> You mean you first count the lines of the file, then run a for loop over all
> line
> numbers (which are otherwise unsused), and then run a awk process for each
> and every line, making awk read all the file while you just want to process a
> single line?
>
> Why the hell don;t you just runf awk _once_ over all lines of the files and
> add the
> logic (including message printing and return code
> setting) to the awk script?
The filenames are not always at the same column. So I check each line.
>
> This script is a awful waste of processes and CPU resources.
> [Not to mention the Useless Use of Cat above.]
Understand, but the imximage.cfg file only has about 20~30 lines. It is very
small.
>
> > + if [ -n "${name}" ]; then
> > + if [ ! -f "${name}" ]; then
> > + echo "WARNING ${name} not found, resulting binary is
> not-functional" >&2
> > + exit 0
>
> If a file is not found which is supposed to be there, then this should be an
> error,
> and not just a warning. And for such scripts the return code for errors is
> 1, as 0
> is reserved for OK.
I use exit 1 when files not found, use 0 when files found.
Thanks,
Peng.
>
> > +done
> > +
> > +exit 1
>
> The return code in case of no errors is 0.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is
> better to marry than to burn.
> - Bible ``I Corinthians'' ch. 7, v. 9
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] imx: mkimage: avoid stop CI when required files not exists
Hi Peng,
On Wed, 24 Oct 2018 09:49:04 +
Peng Fan peng@nxp.com wrote:
...
> --- /dev/null
> +++ b/tools/imx8_cntr_image.sh
> @@ -0,0 +1,32 @@
> +#!/bin/sh
> +# SPDX-License-Identifier: GPL-2.0+
> +#
> +# script to generate FIT image source for K3 Family boards with
> +# ATF, OPTEE, SPL and multiple device trees (given on the command line).
> +# Inspired from board/sunxi/mksunxi_fit_atf.sh
Please drop this comment, it doesn't describe what the script is
actually doing.
...
> +file=$1
> +
> +linecount=`cat ${file} | wc -l`
> +
> +for ((i=1; i<=${linecount}; i++));
> +do
[ snip ]
blobs=`awk '/^APPEND/ {print $2} /^IMAGE/ || /^DATA/ {print $3}' $file`
for f in $blobs; do
if [ ! -f $f ]; then
echo "WARNING '$f' not found, resulting binary is
not-functional"
fi;
done
will do the checks more efficiently.
Thanks,
Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5] net: Add MT7628 ethernet driver
On Wed, Oct 24, 2018 at 1:36 AM Stefan Roese wrote:
>
> This patch adds ethernet support for the MIPS based Mediatek MT76xx SoCs
> (e.g. MT7628 and MT7688), including a minimum setup of the integrated
> switch. This driver is loosly based on the driver version included in
> this MediaTek github repository:
>
> https://github.com/MediaTek-Labs/linkit-smart-uboot.git
>
> Tested on the MT7688 LinkIt smart-gateway and on the
> Gardena-smart-gateway.
>
> Signed-off-by: Stefan Roese
> Reviewed-by: Daniel Schwierzeck
> Cc: Joe Hershberger
> Cc: Frank Wunderlich
> Cc: Weijie Gao
> ---
> v5:
> - Rename driver and Kconfig and functions names again to avoid mix-up
> with the MT76xx ARM SoCs
>
> v4:
> - Rename driver and Kconfig to avoid mix-up with the MT76xx ARM SoCs
>
> v3:
> - Add Reviewed-by from Daniel
> - Address review comments from Joe:
> - Use more macros / defines instead of magic values, especially
> in the MDIO functions
> - Use FIELD_xxx from include/linux/bitfield.h whereever possible
> - Remove some unreferenced defines
> - Remove some unnecessary casts
> - Spelling fixes
> - Add documentation in doc/device-tree-bindings/net/
>
> v2:
> - Use wait_for_bit_le32() in more places
> - Use syscon / regmap to access the system-controller registers
> needed in this driver instead of finding and mapping this
> area
>
> .../net/mediatek,mt7628-eth.txt | 17 +
> drivers/net/Kconfig | 7 +
> drivers/net/Makefile | 1 +
> drivers/net/mt7628-eth.c | 635 ++
> 4 files changed, 660 insertions(+)
> create mode 100644 doc/device-tree-bindings/net/mediatek,mt7628-eth.txt
> create mode 100644 drivers/net/mt7628-eth.c
>
> diff --git a/doc/device-tree-bindings/net/mediatek,mt7628-eth.txt
> b/doc/device-tree-bindings/net/mediatek,mt7628-eth.txt
> new file mode 100644
> index 00..ec97504a3f
> --- /dev/null
> +++ b/doc/device-tree-bindings/net/mediatek,mt7628-eth.txt
> @@ -0,0 +1,17 @@
> +* MediaTek Frame Engine Ethernet controller
> +
> +Required properties:
> +- compatible: should be "mediatek,mt7628-eth"
> +- reg: address and length of the register set for the frame
> + engine ethernet controller and the internal switch.
> +- syscon: phandle to the system controller
> +
> +Example:
> +
> +eth@1010 {
> + compatible = "mediatek,mt7628-eth";
> + reg = <0x1010 0x1
> + 0x1011 0x8000>;
> +
> + syscon = <>;
> +};
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index f1f0e2d94e..fba9d7c31c 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -227,6 +227,13 @@ config MACB_ZYNQ
> The Cadence MACB ethernet interface was used on Zynq platform.
> Say Y to enable support for the MACB/GEM in Zynq chip.
>
> +config MT7628_ETH
> + bool "MediaTek MT7628 Ethernet Interface"
> + depends on ARCH_MT7620
> + help
> + The MediaTek MT7628 ethernet interface is used on MT7628 and
> + MT7688 based boards.
> +
> config PCH_GBE
> bool "Intel Platform Controller Hub EG20T GMAC driver"
> depends on DM_ETH && DM_PCI
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 48a2878071..cc0971c614 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_LPC32XX_ETH) += lpc32xx_eth.o
> obj-$(CONFIG_MACB) += macb.o
> obj-$(CONFIG_MCFFEC) += mcffec.o mcfmii.o
> obj-$(CONFIG_MPC8XX_FEC) += mpc8xx_fec.o
> +obj-$(CONFIG_MT7628_ETH) += mt7628-eth.o
> obj-$(CONFIG_MVGBE) += mvgbe.o
> obj-$(CONFIG_MVNETA) += mvneta.o
> obj-$(CONFIG_MVPP2) += mvpp2.o
> diff --git a/drivers/net/mt7628-eth.c b/drivers/net/mt7628-eth.c
> new file mode 100644
> index 00..93efea395b
> --- /dev/null
> +++ b/drivers/net/mt7628-eth.c
> @@ -0,0 +1,635 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * MediaTek ethernet IP driver for U-Boot
> + *
> + * Copyright (C) 2018 Stefan Roese
> + *
> + * This code is mostly based on the code extracted from this MediaTek
> + * github repository:
> + *
> + * https://github.com/MediaTek-Labs/linkit-smart-uboot.git
> + *
> + * I was not able to find a specific license or other developers
> + * copyrights here, so I can't add them here.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* System controller register */
> +#define MT7628_RSTCTRL_REG 0x34
> +#define RSTCTRL_EPHY_RST BIT(24)
> +
> +#define MT7628_AGPIO_CFG_REG 0x3c
> +#define MT7628_EPHY_GPIO_AIO_ENGENMASK(20, 17)
> +#define MT7628_EPHY_P0_DIS BIT(16)
> +
> +#define MT7628_GPIO2_MODE_REG 0x64
> +
> +/* Ethernet frame engine register */
> +#define PDMA_RELATED 0x0800
> +
> +#define TX_BASE_PTR0 (PDMA_RELATED + 0x000)
> +#define TX_MAX_CNT0(PDMA_RELATED + 0x004)
>
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
On 10/24/2018 08:58 PM, Hannes Schmelzer wrote: >> Hello Hannes, >> >> thanks for reporting the problem. >> >> There are two possible reasons: >> >> a) The build process introduces relocations of the reported type. >> b) The relocation records are overwritten before relocation. This >> happens if you update uninitialized globals. >> >> To analyze your problem further, please, provide instructions for >> building your version of U-Boot (repository, commit, config). That will >> allow to check for a). >> >> Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would >> allow to analyze case b). Are you able to reproduce the problem with >> QEMU? >> >> Best regards >> >> Heinrich >> > Hello Heinrich, > > thanks for this input. > The "trouble" occurs also with QEMU, have a look to console output below. > > Maybe you can investigate on this, I've pushed the branch to my github > account: > > https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb > config is "brpp065mb" > > please let me know if i can help. > > cheers, > Hannes And running qemu-x86_defonfig results in do_elf_reloc_fixups32: unsupported relocation type 0x2 at fff84e38, offset = 0xfff00091 So the problem is not restricted to your board. I have had a first look at the relocations actually present in the u-boot ELF file. Your repo: make brpp065mb_defconfig make objdump -r u-boot | cut -c10-20 | sort | uniq R_386_32 R_386_NONE R_386_PC32 u-boot master: make qemu-x86_defconfig make objdump -r u-boot | cut -c10-20 | sort | uniq R_386_16 R_386_32 R_386_NONE R_386_PC16 R_386_PC32 The current relocation code only supports a single relocation type (R_386_RELATIVE). What I still do not understand is why most of the relocations that we actually see inside U-Boot are of type R_386_RELATIVE). So where are the relocations transformed on the way from u-boot to u-boot.bin? The following command drops some sections and creates an image without any relocation information: objcopy --gap-fill=0xff -O binary -R .start16 -R .resetvec u-boot u-boot-nodtb.bin But where are the R_386_RELATIVEs created? @Bin: do you have an understanding of how this works? Best regards Heinrich ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: dm: fec: Support the phy-supply binding
Hi Martin, https://patchwork.ozlabs.org/patch/979100/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: aquantia: add firmware loading support
Hi Jeremy, https://patchwork.ozlabs.org/patch/971309/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: mvpp2: fix polarity of PHY reset signal
Hi Baruch, https://patchwork.ozlabs.org/patch/984073/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: dm: fec: Obtain the transceiver type from the DT
Hi Martin, https://patchwork.ozlabs.org/patch/979102/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: dm: fec: Fix phy-reset-duration clamping and defaults
Hi Martin, https://patchwork.ozlabs.org/patch/979101/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: dm: fec: Fix time unit error in phy-reset-duration
Hi Martin, https://patchwork.ozlabs.org/patch/979099/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: fec_mxc: add support for i.MX8X
Hi Anatolij, https://patchwork.ozlabs.org/patch/985918/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: mvpp2: increase PHY reset pulse
Hi Baruch, https://patchwork.ozlabs.org/patch/984072/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net/phy: Add phy-id for IN112525_S03
Hi Priyanka, https://patchwork.ozlabs.org/patch/982237/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] net: phy: aquantia: autodetect if firmware needs to be loaded
Hi Jeremy, https://patchwork.ozlabs.org/patch/971312/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] configs: migrate CONFIG_PHY_AQUANTIA to Kconfig
Hi Jeremy, https://patchwork.ozlabs.org/patch/971306/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] miiphy: Add function to retrieve MDIO bus list head
Hi Pankaj, https://patchwork.ozlabs.org/patch/970926/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] cmd: mii: don't check address for 'device' subcommand
Hi Hector, https://patchwork.ozlabs.org/patch/958780/ was applied to http://git.denx.de/?p=u-boot/u-boot-net.git Thanks! -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request: u-boot-net.git master
Hi Tom, Tested as https://travis-ci.org/jhershbe/u-boot/builds/445352605 The following changes since commit 1ed3c0954bd160dafcad8847a51c3ddd5f992f51: Merge branch 'master' of git://git.denx.de/u-boot-samsung (2018-10-23 21:13:32 -0400) are available in the git repository at: git://git.denx.de/u-boot-net.git master for you to fetch changes up to 58ec4d3342f4ffd195f3f3f2e570f772500c6ecb: net: fec_mxc: add support for i.MX8X (2018-10-24 14:45:38 -0500) Anatolij Gustschin (1): net: fec_mxc: add support for i.MX8X Baruch Siach (2): net: mvpp2: fix polarity of PHY reset signal net: mvpp2: increase PHY reset pulse Hector Palacios (1): cmd: mii: don't check address for 'device' subcommand Jeremy Gebben (3): configs: migrate CONFIG_PHY_AQUANTIA to Kconfig net: phy: aquantia: add firmware loading support net: phy: aquantia: autodetect if firmware needs to be loaded Martin Fuzzey (4): net: dm: fec: Fix time unit error in phy-reset-duration net: dm: fec: Fix phy-reset-duration clamping and defaults net: dm: fec: Support the phy-supply binding net: dm: fec: Obtain the transceiver type from the DT Pankaj Bansal (1): miiphy: Add function to retrieve MDIO bus list head Priyanka Jain (1): net/phy: Add phy-id for IN112525_S03 cmd/mii.c | 2 +- common/miiphyutil.c| 5 + configs/T1023RDB_NAND_defconfig| 2 +- configs/T1023RDB_SDCARD_defconfig | 2 +- configs/T1023RDB_SECURE_BOOT_defconfig | 2 +- configs/T1023RDB_SPIFLASH_defconfig| 2 +- configs/T1023RDB_defconfig | 2 +- configs/T1024RDB_NAND_defconfig| 2 +- configs/T1024RDB_SDCARD_defconfig | 2 +- configs/T1024RDB_SECURE_BOOT_defconfig | 2 +- configs/T1024RDB_SPIFLASH_defconfig| 2 +- configs/T1024RDB_defconfig | 2 +- configs/T2080QDS_NAND_defconfig| 2 +- configs/T2080QDS_SDCARD_defconfig | 2 +- configs/T2080QDS_SECURE_BOOT_defconfig | 2 +- configs/T2080QDS_SPIFLASH_defconfig| 2 +- configs/T2080QDS_SRIO_PCIE_BOOT_defconfig | 2 +- configs/T2080QDS_defconfig | 2 +- configs/T2080RDB_NAND_defconfig| 2 +- configs/T2080RDB_SDCARD_defconfig | 2 +- configs/T2080RDB_SECURE_BOOT_defconfig | 2 +- configs/T2080RDB_SPIFLASH_defconfig| 2 +- configs/T2080RDB_SRIO_PCIE_BOOT_defconfig | 2 +- configs/T2080RDB_defconfig | 2 +- configs/T2081QDS_NAND_defconfig| 2 +- configs/T2081QDS_SDCARD_defconfig | 2 +- configs/T2081QDS_SPIFLASH_defconfig| 2 +- configs/T2081QDS_SRIO_PCIE_BOOT_defconfig | 2 +- configs/T2081QDS_defconfig | 2 +- configs/ls1043ardb_defconfig | 2 +- configs/ls1043ardb_nand_SECURE_BOOT_defconfig | 2 +- configs/ls1043ardb_nand_defconfig | 2 +- configs/ls1043ardb_sdcard_defconfig| 2 +- configs/ls1046ardb_emmc_defconfig | 2 +- configs/ls1046ardb_qspi_SECURE_BOOT_defconfig | 2 +- configs/ls1046ardb_qspi_defconfig | 2 +- configs/ls1046ardb_sdcard_SECURE_BOOT_defconfig| 2 +- configs/ls1046ardb_sdcard_defconfig| 2 +- configs/ls1088ardb_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_qspi_defconfig | 1 + .../ls1088ardb_sdcard_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1088ardb_sdcard_qspi_defconfig | 1 + configs/ls2080ardb_SECURE_BOOT_defconfig | 2 +- configs/ls2080ardb_defconfig | 2 +- configs/ls2080ardb_nand_defconfig | 2 +- configs/ls2081ardb_defconfig | 2 +- configs/ls2088ardb_qspi_SECURE_BOOT_defconfig | 2 +- configs/ls2088ardb_qspi_defconfig | 2 +- drivers/net/Kconfig| 2 +- drivers/net/fec_mxc.c | 121 -- drivers/net/fec_mxc.h | 7 + drivers/net/mvpp2.c| 4 +- drivers/net/phy/Kconfig| 26 ++- drivers/net/phy/aquantia.c | 254 - include/configs/T102xRDB.h | 2 - include/configs/T208xQDS.h | 1 - include/configs/T208xRDB.h | 2 - include/configs/ls1043ardb.h | 2 - include/configs/ls1046ardb.h
Re: [U-Boot] socfpga cyclone5 dts
On 23.10.2018 10:54, Marek Vasut wrote: On 10/23/2018 10:52 AM, Simon Goldschmidt wrote: [...] - socfpga_cyclone5_de1_soc.dts - socfpga_cyclone5_de10_nano.dts These should be upstream. But they aren't? Or did you mean "these should be upstreamed"? By whom? CCing Dinh :-) [...] Also, Dinh has enabled the watchdog nearly 4 years ago in socfpga_cyclone5.dtsi but U-Boot doesn't. Should we keep it enabled or disable it in the U-Boot specific dts files? Disable it in board files to keep the current behavior. Do we enable such things in the "-u-boot.dtsi" "overlay" as well? Because when adding it to the dts, we end up having diffs again... Sounds good! To get the Linux devicetree running on the socrates board, I had to add the "clock-frequency" property to the uart(s). What's the status here, socfpga gen5 does not support getting clock rates from the device tree, is that correct? If so, I'll put the clock-frequency into the "-u-boot.dtsi" files, as well. They can be removed once the clock drivers work. Also, the gpio controllers are now missing the "bank-name" property, without which they fail to register. Since this property is not even described in device tree bindings, I chose to add a fallback to the driver to use 'fdt_get_name()' to get a name. The downside is that searching a GPIO by bank name might now fail. Is this acceptable? If not, we'll have to add the "bank-name" properties to the "-u-boot.dtsi" files as well. But since most gpio drivers seem to do it that way, I figured it should be OK... I haven't tested QSPI yet, and I only have access to a SoCrates board, but aside from some "u-boot,dm-pre-reloc" strings, my "-u-boot.dtsi" currently only sets "clock-frequency" for the uarts and disables the watchdog and everything seems to boot fine so far. Simon ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] x86: detect unsupported relocation types
On 10/24/2018 02:35 AM, Heinrich Schuchardt wrote:
On 10/23/2018 11:13 AM, Hannes Schmelzer wrote:
On 10/13/18 3:30 AM, Heinrich Schuchardt wrote:
Currently we support only relocations of type ELF64_R_TYPE or
ELF32_R_TYPE.
We should be warned if other relocation types appear in the relocation
sections.
This type of message has helped to identify code overwriting a relocation
section before relocation and incorrect parsing of relocation tables.
Signed-off-by: Heinrich Schuchardt
---
arch/x86/lib/relocate.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/lib/relocate.c b/arch/x86/lib/relocate.c
index ed10755d9c..01e619d20b 100644
--- a/arch/x86/lib/relocate.c
+++ b/arch/x86/lib/relocate.c
@@ -53,6 +53,15 @@ static void do_elf_reloc_fixups64(unsigned int
text_base, uintptr_t size,
Elf64_Addr *offset_ptr_ram;
do {
+ unsigned long long type = ELF64_R_TYPE(re_src->r_info);
+
+ if (type != R_X86_64_RELATIVE) {
+ printf("%s: unsupported relocation type 0x%llx "
+ "at %p, ",__func__, type, re_src);
+ printf("offset = 0x%llx\n", re_src->r_offset);
+ continue;
+ }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf64_Addr *)(uintptr_t)re_src->r_offset;
@@ -91,6 +100,15 @@ static void do_elf_reloc_fixups32(unsigned int
text_base, uintptr_t size,
Elf32_Addr *offset_ptr_ram;
do {
+ unsigned int type = ELF32_R_TYPE(re_src->r_info);
+
+ if (type != R_386_RELATIVE) {
+ printf("%s: unsupported relocation type 0x%x "
+ "at %p, ",__func__, type, re_src);
+ printf("offset = 0x%x\n", re_src->r_offset);
+ continue;
+ }
+
/* Get the location from the relocation entry */
offset_ptr_rom = (Elf32_Addr *)(uintptr_t)re_src->r_offset;
Hi Heinrich,
i just merged recent u-boot master into my devbranch and ran it on my
board:
--
U-Boot 2018.11-rc2-00728-g85a448b (Oct 23 2018 - 10:50:53 +0200)
CPU: x86, vendor AMD, device 5a2h
DRAM: 119.6 MiB
do_elf_reloc_fixups32: unsupported relocation type 0x1 at 0204d3d0,
offset = 0x287
do_elf_reloc_fixups32: unsupported relocation type 0x2 at 0204d3d8,
offset = 0x291
Bus 0: OK
---
now i get such relocation warnings, can you help me in this how to deal
with that?
I'm starting u-boot as a payload from coreboot.
thanks!
cheers,
Hannes
Hello Hannes,
thanks for reporting the problem.
There are two possible reasons:
a) The build process introduces relocations of the reported type.
b) The relocation records are overwritten before relocation. This
happens if you update uninitialized globals.
To analyze your problem further, please, provide instructions for
building your version of U-Boot (repository, commit, config). That will
allow to check for a).
Coreboot can be run on QEMU (https://www.coreboot.org/QEMU). QEMU would
allow to analyze case b). Are you able to reproduce the problem with QEMU?
Best regards
Heinrich
Hello Heinrich,
thanks for this input.
The "trouble" occurs also with QEMU, have a look to console output below.
Maybe you can investigate on this, I've pushed the branch to my github
account:
https://github.com/oe5hpm/u-boot/tree/bur-next-pp065mb
config is "brpp065mb"
please let me know if i can help.
cheers,
Hannes
schmelzerh@scm-ws10 /tmp $ qemu-system-i386 -bios coreboot.rom -serial stdio
coreboot-4.8-1857-g076ce2f-dirty Fri Oct 19 09:25:23 UTC 2018 romstage
starting...
CBMEM:
IMD: root @ 07fff000 254 entries.
IMD: root @ 07ffec00 62 entries.
CBFS: 'Master Header Locator' located CBFS at [200:3ffc0)
CBFS: Locating 'fallback/ramstage'
CBFS: Found @ offset 3d40 size ad33
Decompressing stage fallback/ramstage @ 0x07fbcfc0 (128696 bytes)
Loading module at 07fbd000 with entry 07fbd000. filesize: 0x15810
memsize: 0x1f678
Processing 1261 relocs. Offset value of 0x071bd000
coreboot-4.8-1857-g076ce2f-dirty Fri Oct 19 09:25:23 UTC 2018 ramstage
starting...
Enumerating buses...
CPU_CLUSTER: 0 enabled
DOMAIN: enabled
QEMU: firmware config interface detected
QEMU: max_cpus is 1
CPU: APIC: 00 enabled
scan_bus: scanning of bus CPU_CLUSTER: 0 took 0 usecs
PCI: pci_scan_bus for bus 00
PCI: 00:00.0 [8086/1237] enabled
PCI: 00:01.0 [8086/7000] enabled
PCI: 00:01.1 [8086/7010] enabled
PCI: 00:01.3 [8086/7113] enabled
PCI: 00:02.0 [1234/] enabled
PCI: 00:03.0 [8086/100e] enabled
scan_bus: scanning of bus PCI: 00:01.0 took 0 usecs
scan_bus: scanning of bus PCI: 00:01.3 took 0 usecs
scan_bus: scanning of bus DOMAIN: took 0 usecs
scan_bus: scanning of bus Root Device took 0 usecs
done
found VGA at PCI: 00:02.0
Setting up VGA for PCI: 00:02.0
Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN:
Setting PCI_BRIDGE_CTL_VGA for bridge Root Device
Allocating resources...
Reading resources...
QEMU: 11 files in fw_cfg
QEMU: etc/boot-fail-wait [size=4]
QEMU:
Re: [U-Boot] [linux-sunxi] [PATCH 5/5] sunxi: doc: Add basic fastboot example
On Wed, Oct 24, 2018 at 10:06:05PM +0530, Jagan Teki wrote: > On Tue, Oct 23, 2018 at 10:51 PM Priit Laes wrote: > > > > From: Priit Laes > > > > Signed-off-by: Priit Laes > > --- > > board/sunxi/README.fastboot | 98 ++- > > 1 file changed, 98 insertions(+) > > create mode 100644 board/sunxi/README.fastboot > > > > diff --git a/board/sunxi/README.fastboot b/board/sunxi/README.fastboot > > We have enough documentation about fastboot in other platforms, people > easily explore the changes wrt sunxi if needed. Well, if someone felt that it's worth writing a doc, maybe it's not so easy to find or understand and we should make the doc better? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 08/16] regmap: Add raw read/write functions
On 15 October 2018 at 01:24, Mario Six wrote:
> The regmap functions currently assume that all register map accesses
> have a data width of 32 bits, but there are maps that have different
> widths.
>
> To rectify this, implement the regmap_raw_read and regmap_raw_write
> functions from the Linux kernel API that specify the width of a desired
> read or write operation on a regmap.
>
> Implement the regmap_read and regmap_write functions using these raw
> functions in a backwards-compatible manner.
>
> Reviewed-by: Anatolij Gustschin
> Signed-off-by: Mario Six
>
> ---
> v10 -> v11:
> No changes
>
> v9 -> v10:
> * Switched to the read{b,w,l,q} and write{b,w,l,q} functions for
> register map access
>
> v8 -> v9:
> * Removed forgotten "fpgamap" in documentation
>
> v7 -> v8:
> No changes
>
> v6 -> v7:
> * Fixed wrong variable type in 64-bit read (u32 -> u64)
> * Added 64-bit case in write function
>
> v5 -> v6:
> * Corrected format specifier
> * Added support for 64-bit reads/writes
>
> v4 -> v5:
> No changes
>
> v3 -> v4:
> * Switched 'ranges[0] + offset' to 'ranges[0].start + offset'
> * Explained the difference between the raw and non-raw read/write
> functions better in the docs
>
> v2 -> v3:
> * Implement the "raw" functions from Linux instead of adding a size
> parameter to the regmap_{read,write} functions
> * Fixed style violation
> * Improved error handling
>
> v1 -> v2:
> New in v2
> ---
> drivers/core/regmap.c | 64 ++-
> include/regmap.h | 58 +++
> 2 files changed, 115 insertions(+), 7 deletions(-)
Reviewed-by: Simon Glass
Applied to u-boot-dm/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 12/16] regmap: Add endianness support
Add support for switching the endianness of regmap accesses via the "little-endian", "big-endian", and "native-endian" boolean properties in the device tree. The default endianness is native endianness. Signed-off-by: Mario Six Reviewed-by: Simon Glass Reviewed-by: Daniel Schwierzeck --- v10 -> v11: * Added more #ifdef tests for 64-bit case to resolve compilation issues v9 -> v10: * Switched to readb/writeb for 8-bit reads/writes v8 -> v9: New in v9 --- drivers/core/regmap.c | 134 ++ include/regmap.h | 14 + 2 files changed, 138 insertions(+), 10 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 06/16] regmap: Add error output
Add some debug output in cases where the initialization of a regmap fails. Reviewed-by: Anatolij Gustschin Reviewed-by: Simon Glass Signed-off-by: Mario Six --- v10 -> v11: No changes v9 -> v10: No changes v8 -> v9: No changes v7 -> v8: No changes v6 -> v7: No changes v5 -> v6: No changes v4 -> v5: No changes v3 -> v4: No changes v2 -> v3: New in v3 --- drivers/core/regmap.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 13/16] regmap: Add overview documentation
Add some overview documentation that explains the purpose and some of the features and limitations of the regmap interface. Reviewed-by: Bin Meng Signed-off-by: Mario Six --- v10 -> v11: No changes v9 -> v10: No changes v8 -> v9: * Amended for inclusion of endianness setting via DT v7 -> v8: New in v8 --- include/regmap.h | 27 +++ 1 file changed, 27 insertions(+) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 09/31] sandbox: blk: Switch to use platdata_auto_alloc_size for the driver data
Currently the sandbox block driver uses priv_auto_alloc_size for the driver data, however that's only available after the device probe phase. In order to make it accessible in an earlier phase, switch to use platdata_auto_alloc_size instead. This patch is the prerequisite for the follow up patch of DM BLK driver changes to work with Sandbox. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None drivers/block/sandbox.c | 15 --- 1 file changed, 8 insertions(+), 7 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] sunxi: add custom board
On Wed, Oct 24, 2018 at 03:59:56PM +0200, Giulio Benetti wrote: > Hello Jagan and Maxime, > > I've looked around a lot, but I can't find a way to use the board/sunxi: > http://git.denx.de/?p=u-boot.git;a=tree;f=board/sunxi;h=304ee6b4cc8e075759d3bd0beb250b56f6901702;hb=HEAD > > to fit what we need. > > We have 5 gpios that control the max current setting on > current-driver for Backlight biasing shunt kathode resistor, and I > don't know where to place the code to set those pins. > > I would like to avoid to create another new board if possible, since > board/sunxi has everything we need to make our board operative. > In general, is there some sort of __weak__ hooks to be used to extend an > existing board? > Because I understand that probably you wouldn't add this code I'm talking > about inside board/sunxi. > > This request is done with idea to upstream patch for this board. > > Can you help me? If that's backlight related, maybe you can just create a new backlight driver? Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 19/31] kconfig: Introduce HAVE_ARCH_IOMAP
Introduce a new Kconfig option for architecture codes to control
whether it provides io{read,write}{8,16,32} I/O accessor functions.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
include/linux/io.h | 4
lib/Kconfig| 6 ++
2 files changed, 10 insertions(+)
Applied to u-boot-dm/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 05/31] virtio: Add codes for virtual queue/ring management
From: Tuomas Tynkkynen This adds support for managing virtual queue/ring, the channel for high performance I/O between host and guest. Signed-off-by: Tuomas Tynkkynen Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None drivers/virtio/Makefile | 2 +- drivers/virtio/virtio_ring.c | 358 +++ include/virtio_ring.h| 320 ++ 3 files changed, 679 insertions(+), 1 deletion(-) create mode 100644 drivers/virtio/virtio_ring.c create mode 100644 include/virtio_ring.h Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 27/31] virtio: pci: Support non-legacy PCI transport device
By default QEMU creates legacy PCI transport devices, but we can
ask QEMU to create non-legacy one if we pass additional device
property/value pairs in the command line:
-device virtio-blk-pci,disable-legacy=true,disable-modern=false
This adds a new driver driver to support non-legacy (modern) device
mode. Previous driver/file name is changed accordingly.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2:
- fix compiler warnings in 64-bit build
- adjust virtio_pci_find_capability() to avoid walking through capability
list to find next one by ourselves
drivers/virtio/Makefile| 2 +-
.../virtio/{virtio_pci.c => virtio_pci_legacy.c} | 6 +-
drivers/virtio/virtio_pci_modern.c | 609 +
3 files changed, 613 insertions(+), 4 deletions(-)
rename drivers/virtio/{virtio_pci.c => virtio_pci_legacy.c} (98%)
create mode 100644 drivers/virtio/virtio_pci_modern.c
Applied to u-boot-dm/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 15/31] virtio: Add block driver support
From: Tuomas Tynkkynen This adds virtio block device driver support. Signed-off-by: Tuomas Tynkkynen Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: - Correct desc->vendor for PCI transport drivers/virtio/Kconfig | 7 +++ drivers/virtio/Makefile | 1 + drivers/virtio/virtio_blk.c | 137 drivers/virtio/virtio_blk.h | 129 + 4 files changed, 274 insertions(+) create mode 100644 drivers/virtio/virtio_blk.c create mode 100644 drivers/virtio/virtio_blk.h Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 12/31] blk: Drop blk_prepare_device()
With the post_probe() changes, this API is no longer needed. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None drivers/block/blk-uclass.c | 9 - include/blk.h | 10 -- 2 files changed, 19 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 10/31] efi_driver: blk: Switch to use platdata_auto_alloc_size for the driver data
Currently the efi block driver uses priv_auto_alloc_size for the driver data, however that's only available after the device probe phase. In order to make it accessible in an earlier phase, switch to use platdata_auto_alloc_size instead. This patch is the prerequisite for the follow up patch of DM BLK driver changes to work with EFI loader. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None lib/efi_driver/efi_block_device.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 09/16] regmap: Support reading from specific range
It is useful to be able to treat the different ranges of a regmap
separately to be able to use distinct offset for them, but this is
currently not implemented in the regmap API.
To preserve backwards compatibility, add regmap_read_range and
regmap_write_range functions that take an additional parameter
'range_num' that identifies the range to operate on.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v10 -> v11:
No changes
v9 -> v10:
No changes
v8 -> v9:
No changes
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
* Renamed the functions to regmap_{write,read}_range
* Added function comments
* Fixed style violations
* Improved error handling
v1 -> v2:
New in v2
---
drivers/core/regmap.c | 49 ++-
include/regmap.h | 31 +++
2 files changed, 75 insertions(+), 5 deletions(-)
Applied to u-boot-dm/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 11/31] blk: Call part_init() in the post_probe() method
part_init() is currently called in every DM BLK driver, either in its bind() or probe() method. However we can use the BLK uclass driver's post_probe() method to do it automatically. Update all DM BLK drivers to adopt this change. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None cmd/sata.c| 9 - common/usb_storage.c | 4 +--- drivers/block/blk-uclass.c| 12 drivers/block/ide.c | 2 -- drivers/block/sandbox.c | 2 +- drivers/mmc/mmc.c | 3 --- drivers/nvme/nvme.c | 1 - drivers/scsi/scsi.c | 1 - lib/efi_driver/efi_block_device.c | 2 -- 9 files changed, 14 insertions(+), 22 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 07/31] virtio: Add net driver support
From: Tuomas Tynkkynen This adds virtio net device driver support. Signed-off-by: Tuomas Tynkkynen Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: - Changed virtio net driver feature table to const drivers/virtio/Kconfig | 7 ++ drivers/virtio/Makefile | 1 + drivers/virtio/virtio_net.c | 218 +++ drivers/virtio/virtio_net.h | 268 4 files changed, 494 insertions(+) create mode 100644 drivers/virtio/virtio_net.c create mode 100644 drivers/virtio/virtio_net.h Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 13/31] blk: Make blk_next_free_devnum() public
blk_next_free_devnum() can be helpful in some cases. Make it a public API. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None drivers/block/blk-uclass.c | 2 +- include/blk.h | 11 +++ 2 files changed, 12 insertions(+), 1 deletion(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 08/31] test: dm: blk: Correct blk_base test case
The blk_base test case creates a USB mass storage block device with the Sandbox host block device as its parent. This does not make any sense and causes potential issue, for example if the test case tries to read/write anything on the USB mass storage block device it will definitely fail as its parent is not on USB bus at all. Correct the test case by creating another Sandbox host block device instead of the USB mass storage one and adjust the case accordingly. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None test/dm/blk.c | 27 +++ 1 file changed, 11 insertions(+), 16 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 02/31] test: dm: core: Add test case for uclass driver's child_post_probe()
On 15 October 2018 at 03:20, Bin Meng wrote: > Add test case to cover uclass driver's child_post_probe() method. > > Signed-off-by: Bin Meng > > --- > > Changes in v3: None > Changes in v2: > - new patch to add test case for uclass driver's child_post_probe() > > include/dm/test.h | 1 + > test/dm/bus.c | 45 + > test/dm/test-fdt.c | 7 +-- > 3 files changed, 51 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 03/31] riscv: bootm: Add dm_remove_devices_flags() call to do_bootm_linux()
On 15 October 2018 at 03:20, Bin Meng wrote: > This adds a call to dm_remove_devices_flags() to do_bootm_linux() > so that drivers that have one of the removal flags set (e.g. > DM_FLAG_ACTIVE_DMA_REMOVE) in their driver struct, may do some > last-stage cleanup before the OS is started. > > arm and x86 already did such, and we should do the same for riscv. > > Signed-off-by: Bin Meng > > --- > > Changes in v3: None > Changes in v2: > - new patch to add dm_remove_devices_flags() call to do_bootm_linux() > for riscv bootm > > arch/riscv/lib/bootm.c | 11 ++- > 1 file changed, 10 insertions(+), 1 deletion(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 10/16] regmap: Define regmap_{get,set}
It would be convenient if one could use the regmap API in conjunction with register maps defined as structs (i.e. structs that directly mirror the memory layout of the registers in question). A similar approach was planned with the regmap_write32/regmap_read32 macros, but was never used. Hence, implement regmap_set/regmap_range_set and regmap_get/regmap_range_get macros, which, given a register map, a struct describing the layout of the register map, and a member name automatically produce regmap_read/regmap_write calls that access the specified member in the register map. Reviewed-by: Anatolij Gustschin Reviewed-by: Simon Glass Signed-off-by: Mario Six --- v10 -> v11: No changes v9 -> v10: No changes v8 -> v9: No changes v7 -> v8: No changes v6 -> v7: No changes v5 -> v6: No changes v4 -> v5: No changes v3 -> v4: No changes v2 -> v3: * Fixed style violations * Added documentation v1 -> v2: New in v2 --- include/regmap.h | 54 1 file changed, 50 insertions(+), 4 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 11/16] test: regmap: Add test for regmap_{set, get}
Add test for regmap_{set,get} functions.
Reviewed-by: Anatolij Gustschin
Reviewed-by: Simon Glass
Signed-off-by: Mario Six
---
v10 -> v11:
No changes
v9 -> v10:
No changes
v8 -> v9:
No changes
v7 -> v8:
No changes
v6 -> v7:
No changes
v5 -> v6:
No changes
v4 -> v5:
No changes
v3 -> v4:
No changes
v2 -> v3:
New in v3
---
test/dm/regmap.c | 28
1 file changed, 28 insertions(+)
Applied to u-boot-dm/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v11 05/16] regmap: Introduce init_range
Both fdtdec_get_addr_size_fixed and of_address_to_resource can fail with an error, which is not currently checked during regmap initialization. Since the indentation depth is already quite deep, extract a new 'init_range' method to do the initialization. Reviewed-by: Anatolij Gustschin Reviewed-by: Simon Glass Signed-off-by: Mario Six --- v10 -> v11: No changes v9 -> v10: No changes v8 -> v9: No changes v7 -> v8: No changes v6 -> v7: No changes v5 -> v6: No changes v4 -> v5: No changes v3 -> v4: * Introduced else clause in of_live_active() if statement to make the distinction between live and non-live cases clearer v2 -> v3: New in v3 --- drivers/core/regmap.c | 68 +++ 1 file changed, 56 insertions(+), 12 deletions(-) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 17/31] riscv: qemu: Enumerate virtio bus during early boot
Currently devices on the virtio bus is not automatically enumerated, which means peripherals on the virtio bus are not discovered by their drivers. This uses board_init() to do the virtio enumeration. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None board/emulation/qemu-riscv/Kconfig | 3 +++ board/emulation/qemu-riscv/qemu-riscv.c | 9 + 2 files changed, 12 insertions(+) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 01/31] dm: core: Allow uclass to set up a device's child after it is probed
On 15 October 2018 at 03:20, Bin Meng wrote: > Some buses need to set up their child devices after they are probed. > Support a common child_post_probe() method for the uclass. > > With this change, the two APIs uclass_pre_probe_device() and > uclass_post_probe_device() become symmetric. > > Signed-off-by: Bin Meng > --- > > Changes in v3: None > Changes in v2: None > > drivers/core/uclass.c | 13 - > include/dm/uclass.h | 4 +++- > 2 files changed, 15 insertions(+), 2 deletions(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 06/31] virtio: Add virtio over mmio transport driver
VirtIO can use various different buses and virtio devices are commonly implemented as PCI devices. But virtual environments without PCI support (a common situation in embedded devices models) might use simple memory mapped device (“virtio-mmio”) instead of the PCI device. This adds a transport driver that implements UCLASS_VIRTIO for virtio over mmio. Signed-off-by: Tuomas Tynkkynen Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None drivers/virtio/Kconfig | 7 + drivers/virtio/Makefile | 1 + drivers/virtio/virtio_mmio.c | 413 +++ drivers/virtio/virtio_mmio.h | 129 ++ 4 files changed, 550 insertions(+) create mode 100644 drivers/virtio/virtio_mmio.c create mode 100644 drivers/virtio/virtio_mmio.h Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 18/31] riscv: qemu: Include some useful commands
With the virtio net and blk drivers, we can do more stuff with some useful commands. Imply those in the board Kconfig. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None board/emulation/qemu-riscv/Kconfig | 8 1 file changed, 8 insertions(+) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 20/31] x86: Implement arch-specific io accessor routines
At present the generic io{read,write}{8,16,32} routines only support
MMIO access. With architecture like x86 that has a separate IO space,
these routines cannot be used to access I/O ports.
Implement x86-specific version to support both PIO and MMIO access,
so that drivers for multiple architectures can use these accessors
without the need to know whether it's MMIO or PIO.
These are ported from Linux kernel lib/iomap.c, with slight changes.
Signed-off-by: Bin Meng
Reviewed-by: Simon Glass
---
Changes in v3: None
Changes in v2: None
arch/Kconfig | 1 +
arch/x86/include/asm/io.h | 66 +++
2 files changed, 67 insertions(+)
Applied to u-boot-dm/next, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 04/31] dm: Add a new uclass driver for VirtIO transport devices
On 15 October 2018 at 03:21, Bin Meng wrote: > This adds a new virtio uclass driver for “virtio” [1] family of > devices that are are found in virtual environments like QEMU, > yet by design they look like physical devices to the guest. > > The uclass driver provides child_pre_probe() and child_post_probe() > methods to do some common operations for virtio device drivers like > device and driver supported feature negotiation, etc. > > [1] http://docs.oasis-open.org/virtio/virtio/v1.0/virtio-v1.0.pdf > > Signed-off-by: Tuomas Tynkkynen > Signed-off-by: Bin Meng > > --- > > Changes in v3: None > Changes in v2: > - Added virtio spec link and a short statement of what virtio is > in the header and source files > - Changed to use 'transport' over 'bus' in drivers/virtio/Kconfig > - Added UCLASS_VIRTIO ID in alphabetical order > - Moved the header file inclusion from virtio.h to C file > - Fixed code styling issue (blank line before return) in > virtio_xxx() APIs > - Changed virtio_init() to return int if there is an error > - Added virtio_uclass_pre_probe() to check virtio transport driver > ops here so that we don't need check these ops each time when > the virtio_xxx APIs are called > - Implemented child_post_remove() method to reset the virtio device > - Changed virtio_driver_features_init() parameter 'feature' and > 'feature_legacy' to const, and adjust member of > 'struct virtio_dev_priv' accordingly > - Initialize uc_priv->vqs in virtio_uclass_post_probe() > > drivers/Kconfig| 2 + > drivers/Makefile | 1 + > drivers/virtio/Kconfig | 25 ++ > drivers/virtio/Makefile| 6 + > drivers/virtio/virtio-uclass.c | 369 + > include/dm/uclass-id.h | 1 + > include/virtio.h | 707 > + > include/virtio_types.h | 24 ++ > 8 files changed, 1135 insertions(+) > create mode 100644 drivers/virtio/Kconfig > create mode 100644 drivers/virtio/Makefile > create mode 100644 drivers/virtio/virtio-uclass.c > create mode 100644 include/virtio.h > create mode 100644 include/virtio_types.h Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 16/31] virtio: cmd: Add virtio command for virtio devices
From: Tuomas Tynkkynen Add 'virtio' command in U-Boot command line. Signed-off-by: Tuomas Tynkkynen Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: None cmd/Kconfig | 7 +++ cmd/Makefile | 1 + cmd/virtio.c | 38 ++ 3 files changed, 46 insertions(+) create mode 100644 cmd/virtio.c Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2] uclass: Use uclass_foreach_dev() macro instead of open coding
Hi Livu, On 28 September 2018 at 10:02, Liviu Dudau wrote: > On Fri, Sep 28, 2018 at 09:57:49AM -0600, Simon Glass wrote: >> On 28 September 2018 at 06:12, Liviu Dudau wrote: >> > Use the uclass_foreach_dev() macro instead of the open coded version. >> > >> > Signed-off-by: Liviu Dudau >> > --- >> > Changelog: >> > - v2: Find more places where the open coded version exists and >> >replace them with the macro >> > >> > drivers/core/dump.c | 2 +- >> > drivers/core/uclass.c | 18 +- >> > 2 files changed, 10 insertions(+), 10 deletions(-) >> >> Reviewed-by: Simon Glass >> >> I wonder how you got that email address?! > > Which one? Mine or yours? > > Mine comes from the new setup that Arm has for dealing with FOSS, where > the email servers don't send the standard Arm disclaimer. Yes I mean yours. OK I see, seems useful. Regards, Simon Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 23/31] arm: qemu: Enumerate virtio bus during early boot
Currently devices on the virtio bus is not automatically enumerated, which means peripherals on the virtio bus are not discovered by their drivers. This uses board_init() to do the virtio enumeration. Signed-off-by: Bin Meng Reviewed-by: Simon Glass --- Changes in v3: None Changes in v2: - imply VIRTIO_PCI for qemu-arm too board/emulation/qemu-arm/Kconfig| 4 board/emulation/qemu-arm/qemu-arm.c | 10 ++ 2 files changed, 14 insertions(+) Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] serial: ns16550: fix debug uart putc called before init
On Tue, Oct 23, 2018 at 11:01 AM Marek Vasut wrote: > > On 10/19/2018 05:25 AM, Simon Glass wrote: > > On 9 August 2018 at 13:04, Simon Goldschmidt > > wrote: > >> If _debug_uart_putc() is called before _debug_uart_init(), the > >> ns16550 debug uart driver hangs in a tight loop waiting for the > >> tx FIFO to get empty. > >> > >> As this can happen via a printf sneaking in before the port calls > >> debug_uart_init(), let's rather ignore characters before the debug > >> uart is initialized. > >> > >> This is done by reading the baudrate divisor and aborting if is zero. > >> > >> Tested on socfpga_cyclone5_socrates. > >> > >> Signed-off-by: Simon Goldschmidt > >> --- > >> v2: > >> - this patch is new in v2 of the series. It replaces the printf/debug > >> change in reset_manager_gen5.c from v1 > >> > >> drivers/serial/ns16550.c | 18 -- > >> 1 file changed, 16 insertions(+), 2 deletions(-) > > > > We cannot use global_data before it is set up, so I think this is the > > best solution. > > > > Acked-by: Simon Glass > > So there's no GD available when using debug uart ? Hum. > > btw. Does the NS16550_read_baud_divisor() need to be called within the > while loop ? No. I just decided to put it there so that it is not executed unless we wait in a tight loop anyway. So if the transmit buffer is empty, code flow is unchanged by this patch. Only if it is not empty, the baud divisor is read. But in this case, we would cycle the while loop a few hundred times, anyway, I guess... Simon Applied to u-boot-dm/next, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
