Re: [U-Boot] [PATCH v2 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
On Tue, 2019-06-04 at 07:13 +0200, Simon Goldschmidt wrote: > On Tue, Jun 4, 2019 at 1:57 AM Dalon Westergreen > wrote: > > > > > > From: Dalon Westergreen > > > > CONFIG_OF_EMBED was primarily enabled to support the stratix10 > > spl hex file requirements. Since this option now produces a > > warning during build, and the spl hex can be created using > > alternate methods, CONFIG_OF_EMBED is no longer needed. > > > > Signed-off-by: Dalon Westergreen > > > > --- > > Changes in v2: > > -> Change CONFIG_SPL_TARGET back to u-boot-spl.hex > > --- > > configs/socfpga_stratix10_defconfig | 1 - > > include/configs/socfpga_stratix10_socdk.h | 2 +- > > 2 files changed, 1 insertion(+), 2 deletions(-) > > > > diff --git a/configs/socfpga_stratix10_defconfig > > b/configs/socfpga_stratix10_defconfig > > index fbab388b43..f27180385d 100644 > > --- a/configs/socfpga_stratix10_defconfig > > +++ b/configs/socfpga_stratix10_defconfig > > @@ -26,7 +26,6 @@ CONFIG_CMD_CACHE=y > > CONFIG_CMD_EXT4=y > > CONFIG_CMD_FAT=y > > CONFIG_CMD_FS_GENERIC=y > > -CONFIG_OF_EMBED=y > > CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" > > CONFIG_ENV_IS_IN_MMC=y > > CONFIG_NET_RANDOM_ETHADDR=y > > diff --git a/include/configs/socfpga_stratix10_socdk.h > > b/include/configs/socfpga_stratix10_socdk.h > > index 39d757d737..66855ff0d8 100644 > > --- a/include/configs/socfpga_stratix10_socdk.h > > +++ b/include/configs/socfpga_stratix10_socdk.h > > @@ -210,6 +210,6 @@ unsigned int cm_get_l4_sys_free_clk_hz(void); > > > > /* SPL SDMMC boot support */ > > #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 > > -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u- > > boot.img" > > +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot- > > dtb.img" > Is that really necessary? I don't have the aarch64 compiler at hand, > but when compiling a gen5 board, "u-boot.img" and "u-boot-dtb.img" > are the same. Changing to "u-boot-dtb.img" here only complicates > things for the user, I think. I would agree with Dalon since we want to make sure we use same name as socfpga_common.h, which is for CV, A10 SoCs. This would help to standardize our internal test infra. Thanks Chin Liang > > Regards, > Simon > > > > > > > #endif /* __CONFIG_H */ > > -- > > 2.21.0 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2] riscv: add Kconfig entries for the F and D ISA extensions support
This patch adds Kconfig entries for the F (Single-Precision) and D (Double-Precision) floating point instruction-set extensions. Signed-off-by: Eric Lin --- Changes for v2: - Grammatical correction in commit message "adds" - Fixed the config name to indicate both F and D arch/riscv/Kconfig | 7 +++ arch/riscv/Makefile | 12 2 files changed, 15 insertions(+), 4 deletions(-) diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 362f3cdc65..e7a76c67cc 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -91,6 +91,13 @@ config RISCV_ISA_C when building U-Boot, which results in compressed instructions in the U-Boot binary. +config RISCV_ISA_FD + bool "Emit Floating-point instructions" + help + Adds "F" and "D" to the ISA subsets that the toolchain is allowed to emit + when building U-Boot, which results in Single and Double-precision instructions + in the U-Boot binary. + config RISCV_ISA_A def_bool y diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile index 0b80eb8d86..5a5c8e75f0 100644 --- a/arch/riscv/Makefile +++ b/arch/riscv/Makefile @@ -5,15 +5,19 @@ ifeq ($(CONFIG_ARCH_RV64I),y) ARCH_BASE = rv64im - ABI = lp64 + ABI := lp64 endif ifeq ($(CONFIG_ARCH_RV32I),y) ARCH_BASE = rv32im - ABI = ilp32 + ABI := ilp32 endif ifeq ($(CONFIG_RISCV_ISA_A),y) ARCH_A = a endif +ifeq ($(CONFIG_RISCV_ISA_FD),y) + ARCH_FD = fd + ABI := $(ABI)d +endif ifeq ($(CONFIG_RISCV_ISA_C),y) ARCH_C = c endif @@ -24,8 +28,8 @@ ifeq ($(CONFIG_CMODEL_MEDANY),y) CMODEL = medany endif -ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_C) -mabi=$(ABI) \ --mcmodel=$(CMODEL) +ARCH_FLAGS = -march=$(ARCH_BASE)$(ARCH_A)$(ARCH_FD)$(ARCH_C) -mabi=$(ABI) \ +-mcmodel=$(CMODEL) PLATFORM_CPPFLAGS += $(ARCH_FLAGS) CFLAGS_EFI += $(ARCH_FLAGS) -- 2.17.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 1/1] riscv: increase the environment size for the qemu-riscv platform to 128kB
> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Bin Meng > Sent: Wednesday, May 08, 2019 9:39 PM > To: Karsten Merker > Cc: U-Boot Mailing List > Subject: Re: [U-Boot] [RFC PATCH 1/1] riscv: increase the environment size for > the qemu-riscv platform to 128kB > > On Mon, May 6, 2019 at 5:49 AM Karsten Merker wrote: > > > > The existing default size of 4kB is too small as the default > > environment has already nearly that size and defining a single > > additional environment variable can exceed the available space. > > > > Signed-off-by: Karsten Merker > > --- > > include/configs/qemu-riscv.h | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Reviewed-by: Bin Meng Applied to u-boot-riscv/master, thanks! > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4] riscv: Add Microchip MPFS Icicle board support
> From: Auer, Lukas [mailto:lukas.a...@aisec.fraunhofer.de] > Sent: Saturday, June 01, 2019 12:13 AM > To: padmarao.beg...@microchip.com; u-boot@lists.denx.de > Cc: Rick Jian-Zhi Chen(陳建志); cyril.j...@microchip.com; > bmeng...@gmail.com; anup.pa...@wdc.com; lewis.ha...@microchip.com > Subject: Re: [PATCH v4] riscv: Add Microchip MPFS Icicle board support > > On Tue, 2019-05-28 at 15:47 +0530, Padmarao Begari wrote: > > This patch adds Microchip MPFS Icicle board support. > > For now, NS16550 serial driver is only enabled. > > The Microchip MPFS Icicle defconfig by default builds U-Boot for > > M-Mode with SMP support. > > > > Signed-off-by: Padmarao Begari > > Reviewed-by: Bin Meng > > --- > > Changes in V4 > > - Remove CONFIG_DISTRO_DEFAULTS from microchip_mpfs_icicle_defconfig > > > > Changes in v3 > > - Fix some typos > > - Remove CONFIG_DM, CONFIG_DM_SERIAL, CONFIG_BAUDRATE, > > CONFIG_SYS_NS16550, CONFIG_SYS_TEXT_BASE and > CONFIG_NR_DRAM_BANKS > > from microchip_mpfs_icicle_defconfig > > - Add config SYS_TEXT_BASE in board kconfig > > - Imply SYS_NS16550 in BOARD_SPECIFIC_OPTIONS > > - select BOARD_EARLY_INIT_F in BOARD_SPECIFIC_OPTIONS > > > > Changes in v2 > > - Fix some typos > > - Rename target board to TARGET_MICROCHIP_ICICLE > > - select CONFIG_BOARD_EARLY_INIT_F in BOARD_SPECIFIC_OPTIONS > > - Remove #ifdef CONFIG_BOARD_EARLY_INIT_F > > --- > > arch/riscv/Kconfig| 4 ++ > > board/microchip/mpfs_icicle/Kconfig | 26 + > > board/microchip/mpfs_icicle/MAINTAINERS | 7 > > board/microchip/mpfs_icicle/Makefile | 7 > > board/microchip/mpfs_icicle/mpfs_icicle.c | 30 +++ > > configs/microchip_mpfs_icicle_defconfig | 8 > > include/configs/microchip_mpfs_icicle.h | 63 > +++ > > 7 files changed, 145 insertions(+) > > create mode 100644 board/microchip/mpfs_icicle/Kconfig > > create mode 100644 board/microchip/mpfs_icicle/MAINTAINERS > > create mode 100644 board/microchip/mpfs_icicle/Makefile > > create mode 100644 board/microchip/mpfs_icicle/mpfs_icicle.c > > create mode 100644 configs/microchip_mpfs_icicle_defconfig > > create mode 100644 include/configs/microchip_mpfs_icicle.h > > > > Reviewed-by: Lukas Auer Applied to u-boot-riscv/master, thanks! ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
> > Hi BIn > > > Hi Rick, > > > > On Mon, May 27, 2019 at 4:40 PM Auer, Lukas > > wrote: > > > > > > On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > > > > QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. > > > > Enable the driver for it. > > > > > > > > Signed-off-by: Bin Meng > > > > --- > > > > > > > > board/emulation/qemu-riscv/Kconfig | 4 > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > Reviewed-by: Lukas Auer > > > Tested-by: Lukas Auer > > > > Could you please apply this series for v2019.07? > > Applied to u-boot-riscv/master, thanks! > > OK > I will apply it today. > > Thanks > Rick > > > Regards, > > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 01/15] arm64: dts: k3: Sync sdhci0 node from kernel and change driver name
On 29/05/19 3:15 PM, Faiz Abbas wrote:
> Sync the sdhci0 node from kernel. This changes the compatible that is
> required to be there in the driver. Change the same for the SD card node
> which is not yet supported in kernel. This also syncs the main_pmx0 node
> as a side effect.
>
> Also change the name of the driver to match the compatible in kernel.
>
> Signed-off-by: Faiz Abbas
> Reviewed-by: Tom Rini
> ---
> arch/arm/dts/k3-am65-main.dtsi| 22
> arch/arm/dts/k3-am654-base-board-u-boot.dtsi | 27 ++
> arch/arm/dts/k3-am654-base-board.dts | 28 +++
> arch/arm/dts/k3-am654-r5-base-board.dts | 31
> configs/am65x_evm_a53_defconfig | 2 +-
> configs/am65x_evm_r5_defconfig| 2 +-
> drivers/mmc/Kconfig | 8 ++---
> drivers/mmc/Makefile | 2 +-
> .../mmc/{k3_arsan_sdhci.c => am654_sdhci.c} | 36 +--
> 9 files changed, 109 insertions(+), 49 deletions(-)
> rename drivers/mmc/{k3_arsan_sdhci.c => am654_sdhci.c} (67%)
>
> diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
> index adcd6341e4..84fed12fbd 100644
> --- a/arch/arm/dts/k3-am65-main.dtsi
> +++ b/arch/arm/dts/k3-am65-main.dtsi
> @@ -69,4 +69,26 @@
> clock-frequency = <4800>;
> current-speed = <115200>;
> };
> +
> + main_pmx0: pinmux@11c000 {
> + compatible = "pinctrl-single";
> + reg = <0x0 0x11c000 0x0 0x2e4>;
> + #pinctrl-cells = <1>;
> + pinctrl-single,register-width = <32>;
> + pinctrl-single,function-mask = <0x>;
> + };
> +
> + sdhci0: sdhci@4f8 {
> + compatible = "ti,am654-sdhci-5.1";
> + reg = <0x0 0x4f8 0x0 0x260>, <0x0 0x4f9 0x0 0x134>;
> + power-domains = <_pds 47>;
> + clocks = <_clks 47 0>, <_clks 47 1>;
> + clock-names = "clk_ahb", "clk_xin";
> + interrupts = ;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> + ti,otap-del-sel = <0x2>;
> + ti,trm-icp = <0x8>;
> + dma-coherent;
> + };
> };
> diff --git a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> index f5c8253831..589a90f9f9 100644
> --- a/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> +++ b/arch/arm/dts/k3-am654-base-board-u-boot.dtsi
> @@ -19,14 +19,6 @@
> _main{
> u-boot,dm-spl;
>
> - main_pmx0: pinmux@11c000 {
> - compatible = "pinctrl-single";
> - reg = <0x0 0x11c000 0x0 0x2e4>;
> - #pinctrl-cells = <1>;
> - pinctrl-single,register-width = <32>;
> - pinctrl-single,function-mask = <0x>;
> - };
> -
> main_pmx1: pinmux@11c2e8 {
> compatible = "pinctrl-single";
> reg = <0x0 0x11c2e8 0x0 0x24>;
> @@ -35,17 +27,8 @@
> pinctrl-single,function-mask = <0x>;
> };
>
> - sdhci0: sdhci@04F8 {
> - compatible = "arasan,sdhci-5.1";
> - reg = <0x0 0x4F8 0x0 0x1000>,
> - <0x0 0x4F9 0x0 0x400>;
> - clocks = <_clks 47 1>;
> - power-domains = <_pds 47>;
> - max-frequency = <2500>;
> - };
> -
> sdhci1: sdhci@04FA {
> - compatible = "arasan,sdhci-5.1";
> + compatible = "ti,am654-sdhci-5.1";
> reg = <0x0 0x4FA 0x0 0x1000>,
> <0x0 0x4FB 0x0 0x400>;
> clocks = <_clks 48 1>;
> @@ -164,7 +147,8 @@
> AM65X_IOPAD(0x0190, PIN_INPUT_PULLUP, 0)/*
> (A24) MMC0_DAT5 */
> AM65X_IOPAD(0x018c, PIN_INPUT_PULLUP, 0)/*
> (B26) MMC0_DAT6 */
> AM65X_IOPAD(0x0188, PIN_INPUT_PULLUP, 0)/*
> (D25) MMC0_DAT7 */
> - AM65X_IOPAD(0x01b0, PIN_INPUT, 0)
> /* (C25) MMC0_DS */
> + AM65X_IOPAD(0x01b4, PIN_INPUT_PULLUP, 0)/*
> (A23) MMC0_SDCD */
> + AM65X_IOPAD(0x01b0, PIN_INPUT, 0) /*
> (C25) MMC0_DS */
> >;
> u-boot,dm-spl;
> };
> @@ -198,11 +182,6 @@
>
> {
> u-boot,dm-spl;
> - status = "okay";
> - non-removable;
> - bus-width = <8>;
> - pinctrl-names = "default";
> - pinctrl-0 = <_mmc0_pins_default>;
> };
>
> {
> diff --git a/arch/arm/dts/k3-am654-base-board.dts
> b/arch/arm/dts/k3-am654-base-board.dts
> index af6956fdc1..ab233916c6 100644
> --- a/arch/arm/dts/k3-am654-base-board.dts
> +++ b/arch/arm/dts/k3-am654-base-board.dts
> @@ -6,6 +6,7 @@
> /dts-v1/;
>
> #include "k3-am654.dtsi"
> +#include
>
> / {
> compatible = "ti,am654-evm", "ti,am654";
> @@ -34,3 +35,30 @@
> };
> };
>
Re: [U-Boot] [PATCH v2 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
On Tue, Jun 4, 2019 at 1:57 AM Dalon Westergreen wrote: > > From: Dalon Westergreen > > CONFIG_OF_EMBED was primarily enabled to support the stratix10 > spl hex file requirements. Since this option now produces a > warning during build, and the spl hex can be created using > alternate methods, CONFIG_OF_EMBED is no longer needed. > > Signed-off-by: Dalon Westergreen > > --- > Changes in v2: > -> Change CONFIG_SPL_TARGET back to u-boot-spl.hex > --- > configs/socfpga_stratix10_defconfig | 1 - > include/configs/socfpga_stratix10_socdk.h | 2 +- > 2 files changed, 1 insertion(+), 2 deletions(-) > > diff --git a/configs/socfpga_stratix10_defconfig > b/configs/socfpga_stratix10_defconfig > index fbab388b43..f27180385d 100644 > --- a/configs/socfpga_stratix10_defconfig > +++ b/configs/socfpga_stratix10_defconfig > @@ -26,7 +26,6 @@ CONFIG_CMD_CACHE=y > CONFIG_CMD_EXT4=y > CONFIG_CMD_FAT=y > CONFIG_CMD_FS_GENERIC=y > -CONFIG_OF_EMBED=y > CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" > CONFIG_ENV_IS_IN_MMC=y > CONFIG_NET_RANDOM_ETHADDR=y > diff --git a/include/configs/socfpga_stratix10_socdk.h > b/include/configs/socfpga_stratix10_socdk.h > index 39d757d737..66855ff0d8 100644 > --- a/include/configs/socfpga_stratix10_socdk.h > +++ b/include/configs/socfpga_stratix10_socdk.h > @@ -210,6 +210,6 @@ unsigned int cm_get_l4_sys_free_clk_hz(void); > > /* SPL SDMMC boot support */ > #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 > -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" > +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-dtb.img" Is that really necessary? I don't have the aarch64 compiler at hand, but when compiling a gen5 board, "u-boot.img" and "u-boot-dtb.img" are the same. Changing to "u-boot-dtb.img" here only complicates things for the user, I think. Regards, Simon > > #endif /* __CONFIG_H */ > -- > 2.21.0 > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] efi_loader: re-organize UEFI-related configuration menu
On 6/4/19 5:11 AM, AKASHI Takahiro wrote: More and more features are coming into UEFI support, while some people are worried about the growing size of the code. Adding a configuration option for each feature is a solution, but it will also make the configuration complicated and unreadable. With this patch, this issue will be addressed by 1.putting UEFI-related menu to a sub-menu, "UEFI API support" in addition, 2.moving EFI_LOADER option, along with USE_BOUND_BUFFER, to "Boot Images" 3.moving forward *non-functional* configurations, currently PLATFORM_LANG_CODES only, at the beginning (1) helps improve readability by separating UEFI-specific configs from other U-Boot features. For (2), "Boot Images" is a right place for EFI_LOADER with architecture-dependent configs. Lastly, coming functional features (runtime services, protocols and others) will be no doubt added to the last. Signed-off-by: AKASHI Takahiro --- Kconfig| 27 lib/efi_loader/Kconfig | 47 +++--- 2 files changed, 39 insertions(+), 35 deletions(-) diff --git a/Kconfig b/Kconfig index a02168690f5b..2bb3db6262fe 100644 Most of the stuff under "Boot images" has nothing to do with boot images. I suggest that whole menu to be dissolved (but not with this patch). --- a/Kconfig +++ b/Kconfig @@ -526,6 +526,33 @@ config ARCH_FIXUP_FDT_MEMORY used for booting OS with different memory setup where the part of the memory location should be used for different purpose. +config EFI_LOADER I find it irritating to have to look into two different places for UEFI support. Couldn't we make EFI_LOADER a menuconfig and put all UEFI stuff beneath it? + bool "Support UEFI images" + depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT + # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB + depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT + # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB + depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT + default y + select LIB_UUID + select HAVE_BLOCK_DEVICE + select REGEX + imply CFB_CONSOLE_ANSI + help + Select this option if you want to run UEFI applications (like GNU + GRUB or iPXE) on top of U-Boot. If this option is enabled, U-Boot + will expose the UEFI API to a loaded application, enabling it to + reuse U-Boot's device drivers. + +config EFI_LOADER_BOUNCE_BUFFER This is not a boot image property. + bool "EFI Applications use bounce buffers for DMA operations" + depends on EFI_LOADER && ARM64 + default n + help + Some hardware does not support DMA to full 64bit addresses. For this + hardware we can create a bounce buffer so that payloads don't have to + worry about platform details. + endmenu # Boot images source "api/Kconfig" diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index cd5436c576b1..8b9e85e9a534 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,23 +1,16 @@ -config EFI_LOADER - bool "Support running UEFI applications" - depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT - # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB - depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT - # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB - depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT - default y - select LIB_UUID - select HAVE_BLOCK_DEVICE - select REGEX - imply CFB_CONSOLE_ANSI - help - Select this option if you want to run UEFI applications (like GNU - GRUB or iPXE) on top of U-Boot. If this option is enabled, U-Boot - will expose the UEFI API to a loaded application, enabling it to - reuse U-Boot's device drivers. - if EFI_LOADER +menu "UEFI API support" I would prefer to keep EFI_LOADER here but as menuconfig. EFI_LOADER is simply exposing an API. So putting it under "Library routines" seems to be a valid choice. + +config EFI_PLATFORM_LANG_CODES Protocols are more relevant than this nitty gritty. So why not keep it at the end? So the change needed reduces to: -config EFI_LOADER +menuconfig EFI_LOADER Best regards Heinrich + string "Language codes supported by firmware" + default "en-US" + help + This value is used to initialize the PlatformLangCodes variable. Its + value is a semicolon (;) separated list of language codes in native + RFC 4646 format, e.g. "en-US;de-DE". The first language code is used + to initialize the PlatformLang variable. + config EFI_GET_TIME bool "GetTime() runtime service" depends on DM_RTC @@ -83,22 +76,6 @@ config EFI_UNICODE_COLLATION_PROTOCOL endif -config EFI_LOADER_BOUNCE_BUFFER - bool "EFI Applications use
Re: [U-Boot] [EXT] Re: [PATCH 4/6] spl: mmc: support loading i.MX container format file
> Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support loading i.MX > container format file > > On 5/30/19 9:06 AM, Ye Li wrote: > > On 2019/5/27 19:31, Marek Vasut wrote: > >> Caution: EXT Email > >> > >> On 5/27/19 11:49 AM, Peng Fan wrote: > >>> Hi Marek, Lukasz, > >>> > Subject: Re: [EXT] Re: [U-Boot] [PATCH 4/6] spl: mmc: support > loading i.MX container format file > > Hi Marek, > > On 2019/5/22 19:41, Marek Vasut wrote: > > Caution: EXT Email > > > > On 5/22/19 9:34 AM, Lukasz Majewski wrote: > > [...] > By using above approach we do have the NXP's "container" > format only seen in the SPL (which is OK, as for example > Samsung does similar thing with FBL/BL1). When SPL is > "trused" > we may use available facilities. > >>> > >>> The issue to me is that sc_seco_authenticate could not take > >>> a FIT image as input. > >> > >> Is the sc_seco_authenticate an API accessible from SPL, > >> U-Boot proper or Linux crypro engine driver? > > > > Yes, it is an API accessible in SPL/U-Boot stage. I do not > > know about Linux crypto driver. > > Maybe it would be worth to check how Linux handle this? Maybe > it would shed some more light on it? > >>> > >>> I am not familiar with that, so might be stupid question below. > >>> Does it really matter? > >> > >> I would check it just out of curiosity. > > > > Yes, it matters, because there should be such API. How would Linux > > authenticate e.g. userspace binaries if there wasn't one, surely > > not by wrapping every single object into the custom vendor-specific > container ? > > And if there is one, you can use it to authenticate raw binaries > > from U-Boot SPL too, e.g. fitImage blobs with an associated signature. > > > > iMX8 AHAB uses RSA key pair for authentication, the on-chip thing > we called SRK is a array of public key hash which is dedicated for > AHAB. It is not a real key. The real public key is in container. > AHAB will check the public key with the on-chip SRK before using it > to authenticate the image. > Seco which contains the crypto engine on imx8 does not allow to use > the SRK by user. No such API exported. > And the fuse of SRK is locked, can't be read directly. > > Actually on imx6/imx7/imx8m, the SPL and u-boot are already using > ROM HAB to implement the trust chain, like SPL authenticates > u-boot, u-boot authenticatse kernel. We just follow this same way > on imx8, the difference is > imx8 needs container format for signed image. We prefer directly > loading container image than fit image. > If we pack fit image into container, obviously this will cause one more > copy. > As a boot loader, isn't it better to have more image format supported? > >> > >> If the functionality of the new image format is a subset of already > >> present image format, then no, that's called a duplication. > >> > We > don't force to use container, just set it as default. Users still > can choose fit or raw image. > >> > >> They can. however they cannot authenticate the fitImage because the > >> firmware doesn't provide the necessary API for that ? > >> > >>> > >>> Do you have more comment? > >> > >> How could Linux use this iMX8 chain of trust stuff to authenticate e.g. > >> userspace binaries ? It's the same thing as authenticating blob in a > >> fitImage. > >> > > > > Userspace binaries don't use the same key pair. They are signed by > > software vendors' key. The private key for chip secure boot is only hold by > device manufacturer. > > For example, android needs to authenticate a signed APK. Its public key (Key > A) is in system FS. > > iMX trust chain only reaches to kernel + ramdisk. Then the chain hands over > to android. > > In ramdisk, android puts another public Key (Key B) used by dm-verify > > for system FS. So once system FS is verified ok, then the public key A > > becomes trusted. Finally we can use public key A for APK authentication. > > So can we put a public key into the SPL and use it to verify a fitImage ? Technically doable. But compared with the current approach that reuse ROM public API, Using crypto driver in SPL will be complicated and code size larger without calling ROM API. I do not understand the problem the SPL loading NXP i.MX8 container format. SPL should only support raw and fit format? vendor format is not allowed and not accepted? Stefano, Simon, Tom Any comments? Thanks, Peng. > > -- > Best regards, > Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] bouncebuf: Add DMA validation check to addr_aligned().【请注意，邮件由u-boot-boun...@lists.denx.de代发】 addr_aligned().
Hi Simon, On 05/19/2019 12:08 AM, Simon Glass wrote: > Hi Christoph, > > On Tue, 7 May 2019 at 03:05, Christoph Muellner > wrote: >> Currently addr_aligned() performs an alignment and a length check >> to validate the DMA address. However, some machines have stricter >> restrictions of DMA-able addresses. >> >> This patch adds a call to mach_addr_is_dmaable() to honor this >> machine specific restrictions. >> >> Signed-off-by: Christoph Muellner >> --- >> >> common/bouncebuf.c | 6 ++ >> 1 file changed, 6 insertions(+) > I feel like this should be handled with DM. Can we add a new method to > the DMA uclass to check an address? If not provided by the DMA driver, > we can assume the address is OK. The DMA in MMC controller which is not stand alone, do not using the driver of DMA uclass, so I'm afraid this is not able to using DMA uclass for this address check. Thanks, - Kever > > Regards, > Simon > ___ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Makefile: Add target to generate hex output for combined spl and dtb
On Tue, 2019-06-04 at 02:00 +0200, Marek Vasut wrote: > On 6/4/19 1:57 AM, Dalon Westergreen wrote: > > From: Dalon Westergreen < > > dalon.westergr...@intel.com > > > > > > > Some architectures, Stratix10, require a hex formatted spl that combines > > the spl image and dtb. This adds a target to create said hex file with > > and offset of SPL_TEXT_BASE. > > > > Signed-off-by: Dalon Westergreen < > > dalon.westergr...@intel.com > > > > > > > [...] > > > @@ -363,6 +365,11 @@ endif > > $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE > > $(call if_changed,mkimage) > > > > +OBJCOPYFLAGS_$(SPL_BIN).hex := -I binary -O ihex --change- > > address=$(CONFIG_SPL_TEXT_BASE) > > Do we really need to do it here ? The commit message is not clear why > this is needed ; I think if you link the SPl against the correct > address, this should not be needed. > This objcopy is from the binary including the dtb and not the elf. If you objcopy using the elf, and link to the correct address, you are correct. It is not true when just taking a binary and converting to a hex file. The binary combined with the dtb is what is needed. I can try be more descriptive in the commit message. perhaps.. --- Stratix10 requires a hex image of the spl plus spl devicetree offset to the Stratix10 onchip memory located at SPL_TEXT_BASE. This patch adds a target to generate a hex file from the u-boot-spl binary including the dtb offset at SPL_TEST_BASE. --- > > +$(obj)/$(SPL_BIN).hex: $(obj)/u-boot-spl.bin FORCE > > + $(call if_changed,objcopy) > > + > > quiet_cmd_mksunxiboot = MKSUNXI $@ > > cmd_mksunxiboot = $(objtree)/tools/mksunxiboot \ > > --default-dt $(CONFIG_DEFAULT_DEVICE_TREE) $< $@ > > @@ -463,3 +470,4 @@ ifdef CONFIG_ARCH_K3 > > tispl.bin: $(obj)/u-boot-spl-nodtb.bin $(SHRUNK_ARCH_DTB) $(SPL_ITS) FORCE > > $(call if_changed,mkfitimage) > > endif > > + > > Drop this hunk Will do, and i likely should have used (SPL_BIN).bin rather than u-boot-spl.bin. --dalon > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] efi_loader: re-organize UEFI-related configuration menu
More and more features are coming into UEFI support, while some people are worried about the growing size of the code. Adding a configuration option for each feature is a solution, but it will also make the configuration complicated and unreadable. With this patch, this issue will be addressed by 1.putting UEFI-related menu to a sub-menu, "UEFI API support" in addition, 2.moving EFI_LOADER option, along with USE_BOUND_BUFFER, to "Boot Images" 3.moving forward *non-functional* configurations, currently PLATFORM_LANG_CODES only, at the beginning (1) helps improve readability by separating UEFI-specific configs from other U-Boot features. For (2), "Boot Images" is a right place for EFI_LOADER with architecture-dependent configs. Lastly, coming functional features (runtime services, protocols and others) will be no doubt added to the last. Signed-off-by: AKASHI Takahiro --- Kconfig| 27 lib/efi_loader/Kconfig | 47 +++--- 2 files changed, 39 insertions(+), 35 deletions(-) diff --git a/Kconfig b/Kconfig index a02168690f5b..2bb3db6262fe 100644 --- a/Kconfig +++ b/Kconfig @@ -526,6 +526,33 @@ config ARCH_FIXUP_FDT_MEMORY used for booting OS with different memory setup where the part of the memory location should be used for different purpose. +config EFI_LOADER + bool "Support UEFI images" + depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT + # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB + depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT + # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB + depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT + default y + select LIB_UUID + select HAVE_BLOCK_DEVICE + select REGEX + imply CFB_CONSOLE_ANSI + help + Select this option if you want to run UEFI applications (like GNU + GRUB or iPXE) on top of U-Boot. If this option is enabled, U-Boot + will expose the UEFI API to a loaded application, enabling it to + reuse U-Boot's device drivers. + +config EFI_LOADER_BOUNCE_BUFFER + bool "EFI Applications use bounce buffers for DMA operations" + depends on EFI_LOADER && ARM64 + default n + help + Some hardware does not support DMA to full 64bit addresses. For this + hardware we can create a bounce buffer so that payloads don't have to + worry about platform details. + endmenu# Boot images source "api/Kconfig" diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig index cd5436c576b1..8b9e85e9a534 100644 --- a/lib/efi_loader/Kconfig +++ b/lib/efi_loader/Kconfig @@ -1,23 +1,16 @@ -config EFI_LOADER - bool "Support running UEFI applications" - depends on (ARM || X86 || RISCV || SANDBOX) && OF_LIBFDT - # We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB - depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT - # We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB - depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT - default y - select LIB_UUID - select HAVE_BLOCK_DEVICE - select REGEX - imply CFB_CONSOLE_ANSI - help - Select this option if you want to run UEFI applications (like GNU - GRUB or iPXE) on top of U-Boot. If this option is enabled, U-Boot - will expose the UEFI API to a loaded application, enabling it to - reuse U-Boot's device drivers. - if EFI_LOADER +menu "UEFI API support" + +config EFI_PLATFORM_LANG_CODES + string "Language codes supported by firmware" + default "en-US" + help + This value is used to initialize the PlatformLangCodes variable. Its + value is a semicolon (;) separated list of language codes in native + RFC 4646 format, e.g. "en-US;de-DE". The first language code is used + to initialize the PlatformLang variable. + config EFI_GET_TIME bool "GetTime() runtime service" depends on DM_RTC @@ -83,22 +76,6 @@ config EFI_UNICODE_COLLATION_PROTOCOL endif -config EFI_LOADER_BOUNCE_BUFFER - bool "EFI Applications use bounce buffers for DMA operations" - depends on ARM64 - default n - help - Some hardware does not support DMA to full 64bit addresses. For this - hardware we can create a bounce buffer so that payloads don't have to - worry about platform details. - -config EFI_PLATFORM_LANG_CODES - string "Language codes supported by firmware" - default "en-US" - help - This value is used to initialize the PlatformLangCodes variable. Its - value is a semicolon (;) separated list of language codes in native - RFC 4646 format, e.g. "en-US;de-DE". The first language code is used - to initialize the PlatformLang variable. +endmenu endif -- 2.21.0
Re: [U-Boot] [PATCH 1/3] board_f: Add mach specific DMA address check function.
Hi Christoph,
On 05/07/2019 05:05 PM, Christoph Muellner wrote:
> From: Christoph Müllner
>
> Some machines have limited DMA engines, which cannot deal
> with arbitrary addresses. This patch introduces a function
> to model these restrictions on a machine level.
>
> Signed-off-by: Christoph Müllner
> Signed-off-by: Christoph Muellner
Do you need all these two signed-off ?
Reviewed-by: Kever Yang
Thanks,
- Kever
> ---
>
> common/board_f.c | 5 +
> include/init.h | 2 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/common/board_f.c b/common/board_f.c
> index 7ef20f2042..fed3c24373 100644
> --- a/common/board_f.c
> +++ b/common/board_f.c
> @@ -1053,3 +1053,8 @@ void board_init_f_r(void)
> hang();
> }
> #endif /* CONFIG_X86 */
> +
> +__weak int mach_addr_is_dmaable(unsigned long addr)
> +{
> + return 1;
> +}
> diff --git a/include/init.h b/include/init.h
> index afc953d51e..18210a1489 100644
> --- a/include/init.h
> +++ b/include/init.h
> @@ -125,6 +125,8 @@ int misc_init_f(void);
> int embedded_dtb_select(void);
> #endif
>
> +int mach_addr_is_dmaable(unsigned long addr);
> +
> /* common/init/board_init.c */
> extern ulong monitor_flash_len;
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] rk3399: Add restriction for DMA-able addresses.
Hi Christoph,
On 05/07/2019 05:05 PM, Christoph Muellner wrote:
> Patches on the U-Boot mailing list from Rockchip engineers
> indicate, that the RK3399's DMA engines are not able to use
> addresses in high-memory (above 0xf800).
>
> This patch models this restriction in an RK3399 specific
> mach_addr_is_dmaable() function.
>
> Signed-off-by: Christoph Muellner
> ---
>
> arch/arm/mach-rockchip/rk3399/rk3399.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/mach-rockchip/rk3399/rk3399.c
> b/arch/arm/mach-rockchip/rk3399/rk3399.c
> index a7ccd4f3ed..15b03726eb 100644
> --- a/arch/arm/mach-rockchip/rk3399/rk3399.c
> +++ b/arch/arm/mach-rockchip/rk3399/rk3399.c
> @@ -109,3 +109,14 @@ void board_debug_uart_init(void)
> #endif
> }
> #endif
> +
> +int mach_addr_is_dmaable(unsigned long addr)
> +{
> + /*
> + * The RK3399 cannot cope with high-memory DMA target/sources.
> + */
> + if (addr < 0xf800UL)
You'd better use SDRAM_MAX_SIZE instead of hard code, and this can
re-used on all Rockchip platform.
Thanks,
- Kever
> + return 1;
> +
> + return 0;
> +}
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] Revert "drivers/crypto/fsl: assign job-rings to non-TrustZone"
Hi Breno,
On Mon, Jun 3, 2019 at 11:55 PM Breno Matheus Lima wrote:
>
> Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to
> non-TrustZone") breaks HABv4 encrypted boot support in the
> following i.MX devices:
>
> - i.MX6UL
> - i.MX7S
> - i.MX7D
> - i.MX7ULP
>
> For preparing a HABv4 encrypted boot image it's necessary to
> encapsulate the generated DEK in a blob. In devices listed
> above the blob generation function takes into consideration
> the Job Ring TrustZone ownership configuration (JROWN_NS)
> and can be only decapsulated by the same configuration.
>
> The ROM code expects DEK blobs encapsulated by the Secure World
> environments which commonly have JROWN_NS = 0.
>
> As U-Boot is running in Secure World we must have JROWN_NS = 0
> so the blobs generated by dek_blob tool can be decapsulated
> by the ROM code.
>
> Job-rings assignment is now handled in OP-TEE OS, this commit can
> be safely reverted.
> https://github.com/OP-TEE/optee_os/pull/2986
>
> This reverts commit 22191ac353445ad8fafc5a78aefcd94e78963041.
>
> Signed-off-by: Breno Lima
Thanks for the fix:
Reviewed-by: Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] Revert "drivers/crypto/fsl: assign job-rings to non-TrustZone"
Commit 22191ac35344 ("drivers/crypto/fsl: assign job-rings to
non-TrustZone") breaks HABv4 encrypted boot support in the
following i.MX devices:
- i.MX6UL
- i.MX7S
- i.MX7D
- i.MX7ULP
For preparing a HABv4 encrypted boot image it's necessary to
encapsulate the generated DEK in a blob. In devices listed
above the blob generation function takes into consideration
the Job Ring TrustZone ownership configuration (JROWN_NS)
and can be only decapsulated by the same configuration.
The ROM code expects DEK blobs encapsulated by the Secure World
environments which commonly have JROWN_NS = 0.
As U-Boot is running in Secure World we must have JROWN_NS = 0
so the blobs generated by dek_blob tool can be decapsulated
by the ROM code.
Job-rings assignment is now handled in OP-TEE OS, this commit can
be safely reverted.
https://github.com/OP-TEE/optee_os/pull/2986
This reverts commit 22191ac353445ad8fafc5a78aefcd94e78963041.
Signed-off-by: Breno Lima
---
drivers/crypto/fsl/jr.c | 9 -
drivers/crypto/fsl/jr.h | 2 --
2 files changed, 11 deletions(-)
diff --git a/drivers/crypto/fsl/jr.c b/drivers/crypto/fsl/jr.c
index cc8d3b02a5..3121762364 100644
--- a/drivers/crypto/fsl/jr.c
+++ b/drivers/crypto/fsl/jr.c
@@ -578,8 +578,6 @@ int sec_init_idx(uint8_t sec_idx)
{
ccsr_sec_t *sec = (void *)SEC_ADDR(sec_idx);
uint32_t mcr = sec_in32(>mcfgr);
- uint32_t jrown_ns;
- int i;
int ret = 0;
#ifdef CONFIG_FSL_CORENET
@@ -635,13 +633,6 @@ int sec_init_idx(uint8_t sec_idx)
#endif
#endif
- /* Set ownership of job rings to non-TrustZone mode by default */
- for (i = 0; i < ARRAY_SIZE(sec->jrliodnr); i++) {
- jrown_ns = sec_in32(>jrliodnr[i].ms);
- jrown_ns |= JROWN_NS | JRMID_NS;
- sec_out32(>jrliodnr[i].ms, jrown_ns);
- }
-
ret = jr_init(sec_idx);
if (ret < 0) {
printf("SEC initialization failed\n");
diff --git a/drivers/crypto/fsl/jr.h b/drivers/crypto/fsl/jr.h
index f6fbb44383..ffd3a19273 100644
--- a/drivers/crypto/fsl/jr.h
+++ b/drivers/crypto/fsl/jr.h
@@ -33,8 +33,6 @@
#define JRNSLIODN_MASK 0x0fff
#define JRSLIODN_SHIFT 0
#define JRSLIODN_MASK 0x0fff
-#define JROWN_NS 0x0008
-#define JRMID_NS 0x0001
#define JQ_DEQ_ERR -1
#define JQ_DEQ_TO_ERR -2
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/5] mx6sabreauto: set SYS_MALLOC_F for video
> Subject: [PATCH 5/5] mx6sabreauto: set SYS_MALLOC_F for video > > Sabre Auto boards currently hang with: > ``` > U-Boot 2019.07-rc3-00057-gc41940c406 (Jun 03 2019 - 14:42:41 +0200) > > CPU: Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz) > CPU: Automotive temperature grade (-40C to 125C)Reset cause: WDOG > Model: Freescale i.MX6 Quad Plus SABRE Automotive Board > Board: MX6Q-Sabreauto revA > I2C: ready > DRAM: 2 GiB > Video device 'ipu@240' cannot allocate frame buffer memory -ensure > the device is set up before relocation Error binding driver 'ipuv3_video': -28 > Video device 'ipu@280' cannot allocate frame buffer memory -ensure > the device is set up before relocation Error binding driver 'ipuv3_video': -28 > Some drivers failed to bind Error binding driver 'generic_simple_bus': -28 > Some drivers failed to bind initcall sequence 8ffe00b8 failed at call 1780e93b > (err=-28) ``` > > Set SYS_MALLOC_F_LEN to reserve_video to work. > > This is similar to the change Peng Fan did for mx6sabresd (9002e735e717) > > Signed-off-by: Sjoerd Simons > > --- > > configs/mx6sabreauto_defconfig | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/configs/mx6sabreauto_defconfig > b/configs/mx6sabreauto_defconfig index 6903048d85..558b1cd996 100644 > --- a/configs/mx6sabreauto_defconfig > +++ b/configs/mx6sabreauto_defconfig > @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x1780 > CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y > CONFIG_SPL_LIBGENERIC_SUPPORT=y > +CONFIG_SYS_MALLOC_F_LEN=0x4000 > CONFIG_TARGET_MX6SABREAUTO=y > CONFIG_SPL_MMC_SUPPORT=y > CONFIG_SPL_SERIAL_SUPPORT=y > @@ -11,7 +12,6 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y > CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_NXP_BOARD_REVISION=y -# > CONFIG_SYS_MALLOC_F is not set CONFIG_FIT=y > CONFIG_SPL_FIT_PRINT=y CONFIG_SPL_LOAD_FIT=y > -- Reviewed-by: Peng Fan > 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/5] mx6sabreauto: Select pinctrl driver
> Subject: [PATCH 2/5] mx6sabreauto: Select pinctrl driver > > With the conversion to DM we should select the pinctrl driver. > > Signed-off-by: Sjoerd Simons > --- > > configs/mx6sabreauto_defconfig | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configs/mx6sabreauto_defconfig > b/configs/mx6sabreauto_defconfig index bf163a2a6e..91ea1ca9e4 100644 > --- a/configs/mx6sabreauto_defconfig > +++ b/configs/mx6sabreauto_defconfig > @@ -69,6 +69,8 @@ CONFIG_SF_DEFAULT_SPEED=2000 > CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_MII=y > +CONFIG_PINCTRL=y > +CONFIG_PINCTRL_IMX6=y > CONFIG_DM_REGULATOR=y > CONFIG_SPI=y > CONFIG_DM_SPI=y Reviewed-by: Peng Fan > -- > 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/6] riscv: ax25: use CCTL to flush d-cache
Hi Rick,
On Tue, May 28, 2019 at 5:45 PM Andes wrote:
>
> From: Rick Chen
>
> Use CCTL command to do d-cache write back and invalidate
> instead of fence.
>
> Signed-off-by: Rick Chen
> Cc: Greentime Hu
> ---
> arch/riscv/cpu/ax25/cache.c | 22 +-
> 1 file changed, 13 insertions(+), 9 deletions(-)
>
> diff --git a/arch/riscv/cpu/ax25/cache.c b/arch/riscv/cpu/ax25/cache.c
> index 228fc55..d30071e 100644
> --- a/arch/riscv/cpu/ax25/cache.c
> +++ b/arch/riscv/cpu/ax25/cache.c
> @@ -5,17 +5,21 @@
> */
>
> #include
> +#include
> +
> +#ifdef CONFIG_RISCV_NDS_CACHE
> +/* mcctlcommand */
> +#define CCTL_REG_MCCTLCOMMAND_NUM 0x7cc
> +
> +/* D-cache operation */
> +#define CCTL_L1D_WBINVAL_ALL 6
> +#endif
>
> void flush_dcache_all(void)
> {
> - /*
> -* Andes' AX25 does not have a coherence agent. U-Boot must use data
> -* cache flush and invalidate functions to keep data in the system
> -* coherent.
> -* The implementation of the fence instruction in the AX25 flushes the
> -* data cache and is used for this purpose.
> -*/
> - asm volatile ("fence" ::: "memory");
> +#ifdef CONFIG_RISCV_NDS_CACHE
> + csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
I think CCTL_REG_MCCTLCOMMAND_NUM is a vendor specific CSR. Does
upstream GCC support this CSR?
> +#endif
> }
>
> void flush_dcache_range(unsigned long start, unsigned long end)
> @@ -72,8 +76,8 @@ void dcache_disable(void)
> {
> #ifndef CONFIG_SYS_DCACHE_OFF
> #ifdef CONFIG_RISCV_NDS_CACHE
> + csr_write(CCTL_REG_MCCTLCOMMAND_NUM, CCTL_L1D_WBINVAL_ALL);
> asm volatile (
> - "fence\n\t"
> "csrr t1, mcache_ctl\n\t"
> "andi t0, t1, ~0x2\n\t"
> "csrw mcache_ctl, t0\n\t"
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] riscv: dts: move out AE350 L2 node from cpus node
Hi Rick,
On Tue, May 28, 2019 at 5:44 PM Andes wrote:
>
> From: Rick Chen
>
> When L2 node exists inside cpus node, uclass_get_device
> can not parse L2 node successfully. So move it outside
> from cpus node.
>
> Also add tag-ram-ctl and data-ram-ctl attributes for
> v5l2 cache controller driver. This can adjust timing
> by requirement from dtb to improve performance.
>
> Signed-off-by: Rick Chen
> Cc: Greentime Hu
> ---
> arch/riscv/dts/ae350_32.dts | 17 +++--
> arch/riscv/dts/ae350_64.dts | 17 +++--
> 2 files changed, 22 insertions(+), 12 deletions(-)
>
> diff --git a/arch/riscv/dts/ae350_32.dts b/arch/riscv/dts/ae350_32.dts
> index cb6ee13..83abfcb 100644
> --- a/arch/riscv/dts/ae350_32.dts
> +++ b/arch/riscv/dts/ae350_32.dts
> @@ -62,13 +62,18 @@
> compatible = "riscv,cpu-intc";
> };
> };
> + };
>
> - L2: l2-cache@e050 {
> - compatible = "cache";
> - cache-level = <2>;
> - cache-size = <0x4>;
> - reg = <0x0 0xe050 0x0 0x4>;
> - };
> + L2: l2-cache@e050 {
> + compatible = "cache";
too generic compatible string (see my previous comments in patch [1/6])
> + cache-level = <2>;
> + cache-size = <0x4>;
> + reg = <0xe050 0x4>;
> + andes,inst-prefetch = <3>;
> + andes,data-prefetch = <3>;
> + // The value format is
nits: no //, use /* */
> + andes,tag-ram-ctl = <0 0>;
> + andes,data-ram-ctl = <0 0>;
> };
>
> memory@0 {
> diff --git a/arch/riscv/dts/ae350_64.dts b/arch/riscv/dts/ae350_64.dts
> index 705491a..7009bdc 100644
> --- a/arch/riscv/dts/ae350_64.dts
> +++ b/arch/riscv/dts/ae350_64.dts
> @@ -62,13 +62,18 @@
> compatible = "riscv,cpu-intc";
> };
> };
> + };
>
> - L2: l2-cache@e050 {
> - compatible = "cache";
> - cache-level = <2>;
> - cache-size = <0x4>;
> - reg = <0x0 0xe050 0x0 0x4>;
> - };
> + L2: l2-cache@e050 {
> + compatible = "cache";
> + cache-level = <2>;
> + cache-size = <0x4>;
> + reg = <0x0 0xe050 0x0 0x4>;
> + andes,inst-prefetch = <3>;
> + andes,data-prefetch = <3>;
> + // The value format is
nits: no //, use /* */
> + andes,tag-ram-ctl = <0 0>;
> + andes,data-ram-ctl = <0 0>;
> };
>
> memory@0 {
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/6] riscv: cache: Flush L2 cache before jump to linux
Hi Rick, On Tue, May 28, 2019 at 5:44 PM Andes wrote: > > From: Rick Chen > > Flush and disable cache in cleanup_before_linux() > which will be called before jump to linux. > > The sequence will be preferred as below: > L1 flush -> L1 disable -> L2 flush -> L2 disable > > Signed-off-by: Rick Chen > Cc: Greentime Hu > --- > arch/riscv/cpu/ax25/cpu.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/arch/riscv/cpu/ax25/cpu.c b/arch/riscv/cpu/ax25/cpu.c > index 76689b2..9e7579a 100644 > --- a/arch/riscv/cpu/ax25/cpu.c > +++ b/arch/riscv/cpu/ax25/cpu.c > @@ -7,6 +7,7 @@ > /* CPU specific code */ > #include > #include > +#include > > /* > * cleanup_before_linux() is called just before we call linux > @@ -22,6 +23,9 @@ int cleanup_before_linux(void) > cache_flush(); > icache_disable(); > dcache_disable(); > +#ifdef CONFIG_RISCV_NDS_CACHE > + v5l2_disable(); > +#endif The direct call into a driver should be avoided. Instead, use a proper DM cache uclass driver API (see my review comments in patch [1/6]) Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/6] riscv: ae350: use the v5l2 driver to configure the cache
Hi Rick,
On Tue, May 28, 2019 at 5:44 PM Andes wrote:
>
> From: Rick Chen
>
> Find the UCLASS_CACHE driver to configure the cache controller's
> settings.
>
> Signed-off-by: Rick Chen
> Cc: Greentime Hu
> ---
> board/AndesTech/ax25-ae350/ax25-ae350.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/board/AndesTech/ax25-ae350/ax25-ae350.c
> b/board/AndesTech/ax25-ae350/ax25-ae350.c
> index 3d65ce7..686ec4a 100644
> --- a/board/AndesTech/ax25-ae350/ax25-ae350.c
> +++ b/board/AndesTech/ax25-ae350/ax25-ae350.c
> @@ -11,6 +11,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -93,10 +94,24 @@ int smc_init(void)
> return 0;
> }
>
> +int v5l2_init(void)
> +{
> + struct udevice *dev;
> + int ret;
> +
> + ret = uclass_get_device(UCLASS_CACHE, 0, );
> +
> + if (ret)
> + return ret;
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_BOARD_EARLY_INIT_F
> int board_early_init_f(void)
> {
> smc_init();
> + v5l2_init();
Please check the return value here, or you can make v512_init() returns void.
>
> return 0;
> }
> --
Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/6] riscv: ae350: add imply v5l2 cache controller
Hi Rick, On Tue, May 28, 2019 at 5:44 PM Andes wrote: > > From: Rick Chen > > Select the v5l2 UCLASS_CACHE driver for AE350. > > Signed-off-by: Rick Chen > Cc: Greentime Hu > --- > board/AndesTech/ax25-ae350/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/board/AndesTech/ax25-ae350/Kconfig > b/board/AndesTech/ax25-ae350/Kconfig > index 5e682b6..dd299d9 100644 > --- a/board/AndesTech/ax25-ae350/Kconfig > +++ b/board/AndesTech/ax25-ae350/Kconfig > @@ -25,5 +25,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy > def_bool y > select RISCV_NDS > imply SMP > + imply V5L2_CACHE I believe L2 cache is a CPU specific feature, hence this should be implied from arch/riscv/cpu/ax25/Kconfig Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] dm: cache: add v5l2 cache controller driver
Hi Rick,
On Tue, May 28, 2019 at 5:44 PM Andes wrote:
>
> From: Rick Chen
>
> Add a v5l2 cache controller driver that is usually found on
> Andes RISC-V ae350 platform. It will parse the cache settings
> from the dtb.
>
> In this version tag and data ram control timing can be adjusted
> by the requirement from the dtb.
>
> Signed-off-by: Rick Chen
> Cc: Greentime Hu
> ---
> arch/riscv/include/asm/global_data.h | 3 ++
> arch/riscv/include/asm/v5l2cache.h | 61 +
> drivers/cache/Kconfig| 9
> drivers/cache/Makefile | 1 +
> drivers/cache/cache-v5l2.c | 102
> +++
> 5 files changed, 176 insertions(+)
> create mode 100644 arch/riscv/include/asm/v5l2cache.h
> create mode 100644 drivers/cache/cache-v5l2.c
>
> diff --git a/arch/riscv/include/asm/global_data.h
> b/arch/riscv/include/asm/global_data.h
> index b74bd7e..6e52d5d 100644
> --- a/arch/riscv/include/asm/global_data.h
> +++ b/arch/riscv/include/asm/global_data.h
> @@ -24,6 +24,9 @@ struct arch_global_data {
> #ifdef CONFIG_ANDES_PLMT
> void __iomem *plmt; /* plmt base address */
> #endif
> +#ifdef CONFIG_V5L2_CACHE
> + void __iomem *v5l2; /* v5l2 base address */
> +#endif
Please do not expose this to global data if it is only used inside a
driver. Anything that is here is for "global" usage.
> #ifdef CONFIG_SMP
> struct ipi_data ipi[CONFIG_NR_CPUS];
> #endif
> diff --git a/arch/riscv/include/asm/v5l2cache.h
> b/arch/riscv/include/asm/v5l2cache.h
> new file mode 100644
> index 000..8ed1c6c
> --- /dev/null
> +++ b/arch/riscv/include/asm/v5l2cache.h
Please create arch/riscv/include/asm/arch-ax25/v5l2cache.h. Speaking
of the name, would it be more readable to name it as v5_l2cache.h? Or
even add more information to v5, for me, I don't know what v5 stands
for :)
> @@ -0,0 +1,61 @@
> +/* SPDX-License-Identifier: GPL-2.0+ */
> +/*
> + * Copyright (C) 2019 Andes Technology Corporation
> + * Rick Chen, Andes Technology Corporation
> + */
> +
> +#ifndef _ASM_V5_L2CACHE_H
> +#define _ASM_V5_L2CACHE_H
> +
> +struct l2cache {
> + volatile u64configure;
checkpatch.pl will report warnings against volatile usage. I think we
should drop these.
> + volatile u64control;
> + volatile u64hpm0;
> + volatile u64hpm1;
> + volatile u64hpm2;
> + volatile u64hpm3;
> + volatile u64error_status;
> + volatile u64ecc_error;
> + volatile u64cctl_command0;
> + volatile u64cctl_access_line0;
> + volatile u64cctl_command1;
> + volatile u64cctl_access_line1;
> + volatile u64cctl_command2;
> + volatile u64cctl_access_line2;
> + volatile u64cctl_command3;
> + volatile u64cctl_access_line4;
> + volatile u64cctl_status;
> +};
> +
> +/* Control Register */
> +#define L2_ENABLE 0x1
> +/* prefetch */
> +#define IPREPETCH_OFF 3
> +#define DPREPETCH_OFF 5
> +#define IPREPETCH_MSK (3 << IPREPETCH_OFF)
> +#define DPREPETCH_MSK (3 << DPREPETCH_OFF)
> +/* tag ram */
> +#define TRAMOCTL_OFF 8
> +#define TRAMICTL_OFF 10
> +#define TRAMOCTL_MSK (3 << TRAMOCTL_OFF)
> +#define TRAMICTL_MSK BIT(TRAMICTL_OFF)
> +/* data ram */
> +#define DRAMOCTL_OFF 11
> +#define DRAMICTL_OFF 13
> +#define DRAMOCTL_MSK (3 << DRAMOCTL_OFF)
> +#define DRAMICTL_MSK BIT(DRAMICTL_OFF)
> +
> +/* CCTL Command Register */
> +#define CCTL_CMD_REG(base, hart) ((ulong)(base) + 0x40 + (hart) * 0x10)
> +#define L2_WBINVAL_ALL 0x12
> +
> +/* CCTL Status Register */
> +#define CCTL_STATUS_MSK(hart) (0xf << ((hart) * 4))
> +#define CCTL_STATUS_IDLE(hart) (0 << ((hart) * 4))
> +#define CCTL_STATUS_PROCESS(hart) (1 << ((hart) * 4))
> +#define CCTL_STATUS_ILLEGAL(hart) (2 << ((hart) * 4))
> +
> +void v5l2_enable(void);
> +void v5l2_disable(void);
> +
> +#endif /* _ASM_V5_L2CACHE_H */
> diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
> index 24def7a..665689a 100644
> --- a/drivers/cache/Kconfig
> +++ b/drivers/cache/Kconfig
> @@ -22,4 +22,13 @@ config L2X0_CACHE
> ARMv7(32-bit) devices. The driver configures the cache settings
> found in the device tree.
>
> +config V5L2_CACHE
> + tristate "Andes V5L2 cache driver"
This should be bool. U-Boot does not support "tristate"
> + select CACHE
> + depends on RISCV_NDS_CACHE
> + help
> + Support Andes V5L2 cache controller in AE350 platform.
> + It will configure tag and data ram timing control from the
> + device tree and enable L2 cache.
> +
> endmenu
> diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile
> index 9deb961..4a6458c 100644
> --- a/drivers/cache/Makefile
> +++ b/drivers/cache/Makefile
> @@ -2,3 +2,4 @@
> obj-$(CONFIG_CACHE) += cache-uclass.o
> obj-$(CONFIG_SANDBOX) += sandbox_cache.o
> obj-$(CONFIG_L2X0_CACHE) +=
Re: [U-Boot] [PATCH 1/5] mx6sabreauto: Remove CONFIG_SPL_DM to decrease the SPL size
> Subject: [PATCH 1/5] mx6sabreauto: Remove CONFIG_SPL_DM to decrease > the SPL size > > The i.mx6 SPL binary cannot be bigger then 68K, while with the current > defconfig for sabreauto it's only about 56K as soon as USB support gets added > the size will overflows. > > Signed-off-by: Sjoerd Simons > > --- > > configs/mx6sabreauto_defconfig | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/configs/mx6sabreauto_defconfig > b/configs/mx6sabreauto_defconfig index d0f302e9d0..bf163a2a6e 100644 > --- a/configs/mx6sabreauto_defconfig > +++ b/configs/mx6sabreauto_defconfig > @@ -55,7 +55,6 @@ CONFIG_MULTI_DTB_FIT=y > CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_MMC=y > CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y > -CONFIG_SPL_DM=y The spl bin exceeds 68KB on this board? If the intention of this patch is to fix regression, `Reviewed-by: Peng Fan ` > CONFIG_DFU_MMC=y > CONFIG_DFU_SF=y > CONFIG_DM_GPIO=y > -- > 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 6/6] doc: rockchip: Add note for Pine64 Rock64 board
On 06/01/2019 10:47 PM, Matwey V. Kornilov wrote: > Add build notes for Pine64 Rock64 board. > > Signed-off-by: Matwey V. Kornilov > --- > doc/README.rockchip | 30 -- Reviewed-by: Kever Yang Thanks, - Kever > 1 file changed, 28 insertions(+), 2 deletions(-) > > diff --git a/doc/README.rockchip b/doc/README.rockchip > index ca4d6473b0..eacedbddf4 100644 > --- a/doc/README.rockchip > +++ b/doc/README.rockchip > @@ -48,9 +48,10 @@ Two RK3036 boards are supported: > - EVB RK3036 - use evb-rk3036 configuration > - Kylin - use kylin_rk3036 configuration > > -One RK3328 board is supported: > +Two RK3328 board are supported: > > - - EVB RK3328 > + - EVB RK3328 - use evb-rk3328_defconfig > + - Pine64 Rock64 board - use rock64-rk3328_defconfig > > Size RK3399 boards are supported (aarch64): > > @@ -307,6 +308,31 @@ tools/mkimage -n rk3188 -T rksd -d spl/u-boot-spl.bin out > truncate -s %2048 u-boot.bin > cat u-boot.bin | split -b 512 --filter='openssl rc4 -K > 7C4E0304550509072D2C7B38170D1711' >> out > > +Booting from an SD card on Pine64 Rock64 (RK3328) > += > + > +For Rock64 rk3328 board the following three parts are required: > +TPL, SPL, and the u-boot image tree blob. While u-boot-spl.bin and > +u-boot.itb are to be compiled as usual, TPL is currently not > +implemented in u-boot, so you need to pick one from rkbin: > + > + - Get the rkbin > + > +=> git clone https://github.com/rockchip-linux/rkbin.git > + > + - Create TPL/SPL image > + > +=> tools/mkimage -n rk3328 -T rksd -d > rkbin/bin/rk33/rk3328_ddr_333MHz_v1.16.bin idbloader.img > +=> cat spl/u-boot-spl.bin >> idbloader.img > + > + - Write TPL/SPL image at 64 sector > + > +=> sudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 > + > + - Write u-boot image tree blob at 16384 sector > + > +=> sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 > + > Booting from an SD card on RK3399 > = > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] fsl_esdhc: GPIO regulator as VQMMC supply?
> Subject: fsl_esdhc: GPIO regulator as VQMMC supply?
>
> Hi,
>
> I’m trying to implement the VQMMC supply for the an eMMC on my board
> using a GPIO regulator, i.e.
>
> reg_sd_vsel: regulator-sd-vsel {
> pinctrl-names = "default";
> pinctrl-0 = <_sd_vsel>;
> compatible = "regulator-gpio";
> regulator-name = "sd-vsel";
> regulator-min-microvolt = <180>;
> regulator-max-microvolt = <330>;
> gpios = < 1 GPIO_ACTIVE_HIGH>;
> states = <180 1 330 0>;
> gpios-states = <0>; /* default: 3.3V */ };
>
> {
> vqmmc-supply = <_sd_vsel>;
> };
>
> This is using an i.MX7D SoC, so my [eu]sdhc driver is fsl_esdhc. In
> fsl_esdhc_probe, regulator_set_enable is called for vqmmc-supply. This fails
> for GPIO regulators because they only have a set_value method and no
> set_enable method. How is this best resolved? Does it make sense to add a
> set_enable method to the GPIO regulator or should the esdhc driver handle
> the -ENOSYS return value gracefully? Or should I write my device tree
> differently?
Add set_enable callback to gpio regulator seems make sense.
Regards,
Peng
>
> Hints are much appreciated. Thanks!
>
> Best regards,
> Sven
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] regulator: Allow autosetting fixed regulators
> -Original Message- > From: Sven Schwermer [mailto:s...@svenschwermer.de] > Sent: 2019年5月31日 18:44 > To: Peng Fan > Cc: u-boot@lists.denx.de; Jaehoon Chung > Subject: Re: [PATCH] regulator: Allow autosetting fixed regulators > > > How about the following patch? not tested > > > > diff --git a/drivers/power/regulator/regulator-uclass.c > b/drivers/power/regulator/regulator-uclass.c > > index 9118b8eb39..76be95bcd1 100644 > > --- a/drivers/power/regulator/regulator-uclass.c > > +++ b/drivers/power/regulator/regulator-uclass.c > > @@ -238,6 +238,9 @@ int regulator_autoset(struct udevice *dev) > >if (!uc_pdata->always_on && !uc_pdata->boot_on) > >return -EMEDIUMTYPE; > > > > + if (uc_pdata->type == REGULATOR_TYPE_FIXED) > > + return regulator_set_enable(dev, true); > > + > >if (uc_pdata->flags & REGULATOR_FLAG_AUTOSET_UV) > >ret = regulator_set_value(dev, uc_pdata->min_uV); > >if (!ret && (uc_pdata->flags & REGULATOR_FLAG_AUTOSET_UA)) > > That will probably work as well. It does, however, feel a little like a hack. > What if there are other regulator types that require a similar workaround? When ret is -ENOSYS, it might be a fixed regulator. So directly use FIXED regulator check make more sense to me. Regards, Peng. > > Sven ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
Hi BIn > Hi Rick, > > On Mon, May 27, 2019 at 4:40 PM Auer, Lukas > wrote: > > > > On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > > > QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. > > > Enable the driver for it. > > > > > > Signed-off-by: Bin Meng > > > --- > > > > > > board/emulation/qemu-riscv/Kconfig | 4 > > > 1 file changed, 4 insertions(+) > > > > > > > Reviewed-by: Lukas Auer > > Tested-by: Lukas Auer > > Could you please apply this series for v2019.07? > OK I will apply it today. Thanks Rick > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2 v3] test: dm: add MDIO test
On Tue, Jun 4, 2019 at 12:12 AM Alex Marginean wrote: > > A very simple test for DM_MDIO, mimicks a register write/read through the > sandbox bus to a dummy PHY. > > Signed-off-by: Alex Marginean > --- > > Changes in v2: > - new patch, v1 didn't have a test included > Changes in v3: > - DM_MDIO and PHYLIB are now implied in arc/Kconfig > - added basic test for mdio reset op > - simplified compatible, static probe function > > arch/Kconfig | 2 + > arch/sandbox/dts/test.dts | 4 ++ > drivers/net/Kconfig| 10 + > drivers/net/Makefile | 1 + > drivers/net/mdio_sandbox.c | 92 ++ > test/dm/Makefile | 1 + > test/dm/mdio.c | 53 ++ > 7 files changed, 163 insertions(+) > create mode 100644 drivers/net/mdio_sandbox.c > create mode 100644 test/dm/mdio.c > Reviewed-by: Bin Meng Tested-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2 v3] net: introduce MDIO DM class for MDIO devices
Hi Alex, On Tue, Jun 4, 2019 at 12:11 AM Alex Marginean wrote: > > Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as > stand-alone devices. Useful in particular for systems that support > DM_ETH and have a stand-alone MDIO hardware block shared by multiple > Ethernet interfaces. > > Signed-off-by: Alex Marginean > --- > > Changes in v2: > - fixed several comments using wrong API names > - dropped dm_ from names of internal functions that don't use udevice > * > - fixed UCLASS driver name > - added missing mdio_unregister in dm_mdio_pre_remove > - added a comment on why spaces in names aren't ok > - added a comment on how static mdio_read/_write/_reset functions > are used > Changes in v3: > - none > > cmd/mdio.c | 5 ++ > drivers/net/Kconfig| 13 + > include/dm/uclass-id.h | 1 + > include/miiphy.h | 49 ++ > net/Makefile | 1 + > net/mdio-uclass.c | 115 + > 6 files changed, 184 insertions(+) > create mode 100644 net/mdio-uclass.c > Reviewed-by: Bin Meng Please keep the RoB tag if there is nothing changed so that I know this has been reviewed :) Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] riscv: qemu: Enable PCI host ECAM generic driver
Hi Rick, On Mon, May 27, 2019 at 4:40 PM Auer, Lukas wrote: > > On Wed, 2019-05-15 at 08:42 -0700, Bin Meng wrote: > > QEMU 4.0.0 'virt' target integrates a generic ECAM PCI host. > > Enable the driver for it. > > > > Signed-off-by: Bin Meng > > --- > > > > board/emulation/qemu-riscv/Kconfig | 4 > > 1 file changed, 4 insertions(+) > > > > Reviewed-by: Lukas Auer > Tested-by: Lukas Auer Could you please apply this series for v2019.07? Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Hart lottery and CONFIG_XIP
Hi Troy Bin Meng 於 2019年6月3日 週一 下午10:56寫道： > > Hi Troy, > > On Mon, Jun 3, 2019 at 10:53 PM Troy Benjegerdes > wrote: > > > > > > > > > On Jun 3, 2019, at 9:19 AM, Bin Meng wrote: > > > > > > +Anup > > > > > > Hi Troy, > > > > > > On Mon, Jun 3, 2019 at 9:19 PM Troy Benjegerdes > > > wrote: > > >> > > >> > > >> > > >>> On Jun 2, 2019, at 9:22 PM, Rick Chen wrote: > > >>> > > >>> Hi Troy > > >>> > > > From: Troy Benjegerdes [mailto:troy.benjeger...@sifive.com] > > > Sent: Saturday, June 01, 2019 12:24 AM > > > To: Auer, Lukas > > > Cc: Rick Jian-Zhi Chen(陳建志); bmeng...@gmail.com; pal...@sifive.com > > > Subject: Re: Hart lottery and CONFIG_XIP > > > > > > > > > > > >> On May 31, 2019, at 9:13 AM, Auer, Lukas > > >> > > > wrote: > > >> > > >> Hi Troy, > > >> > > >> On Fri, 2019-05-31 at 08:18 -0500, Troy Benjegerdes wrote: > > >>> Wouldn't the following line in head.S fail when running from flash > > >>> (although maybe not in a way that prevents booting) > > >>> > > >>> /* save the boot hart id to global_data */ > > >>> SREGtp, GD_BOOT_HART(gp) > > >>> > > >>> Shouldn’t this be protected by CONFIG_XIP? > > >> > > >> The boot hart ID is stored in global data, which is allocated from > > >> the > > >> stack (in board_init_f_alloc_reserve() ). It is therefore writable > > >> and > > >> won't cause any issues when running from flash. > > > > > > Sorry about the confusion, I was reading it wrong earlier. > > > > > > I’m hoping to have a couple of patches ready later today to change the > > > CONFIG_XIP patch to ‘CONFIG_HART_LOTTERY’ since it is also useful to > > > remove the potential indeterminism of which hart wins the lottery > > > when doing > > > board bringup and debugging. > > >>> > > >>> I am OK with that. > > >>> Actually my preliminary patch about > > >>> [PATCH 0/4] AE350 support SMP boot from flash > > >>> did as your wish. > > >>> > > >>> You can refer it : > > >>> [PATCH 1/4] riscv: hart_lottery and available harts feature can be > > >>> seletable > > >>> https://www.mail-archive.com/u-boot@lists.denx.de/msg323419.html > > >>> > > >>> Rick > > >> > > >> To follow up on > > >> https://www.mail-archive.com/u-boot@lists.denx.de/msg323526.html > > >> > > >> It is confusing and misleading to mix CONFIG_XIP and CONFIG_HART_LOTTERY. > > >> > > > > > > I am not sure what caused the confusion. CONFIG_XIP was added to > > > support U-Boot executing from ROM directly. > > > > > > > The confusion is use cases where you don’t necessarily need CONFIG_XIP, > > but you do want deterministic SMP booting, and the code is a lot more > > understandable > > with ‘#ifdef CONFIG_HART_LOTTERY’, and a Kconfig option and/or documentation > > warning that says CONFIG_HART_LOTTERY depends on !CONFIG_XIP > > > > OK, as I pointed out, the deterministic SMP booting was originally > posted, but later was changed to the lottery mechanism per Anup's > review comments. I am personally fine with both. Yes. I am agree with that. But it shall also support booting form ROM and RAM as now. > > > >> From an system testing and validation point of view, I would find it > > >> much better > > >> (especially at very early boot stages, where U-boot might be the first > > >> non-ROM code > > >> running) to have a deterministic process to determine what core runs > > >> U-boot. This > > > > > > I remember when SMP patches were submitted by Lukas for the first time > > > it was deterministic using some macros like CONFIG_BOOT_HART, however > > > per Anup's request, the hart lottery feature, similar to what Linux > > > has, was added. > > > > I’d like to have CONFIG_BOOT_HART available as a config option as well, > > particularly > > for system validation testing. Also along those lines, if we are going to > > use a lottery > > to determine what CPU boots the system, how do we know afterwards which one > > it was? > > > > Yes, there is a way to know. Type 'dm tree' from U-Boot shell, then > look at which cpu node has a child node of "riscv_timer". Or you can check gd->arch.boot_hart by gdb (gdb) p/x gd->arch.boot_hart $3 = 0x0 B.R Rick > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Question about cfi flash driver can not work well in cacheable region !
Hi Stefan Stefan Roese 於 2019年6月3日 週一 下午9:05寫道： > > Hi Rick, > > On 03.06.19 11:27, Rick Chen wrote: > > Hi Stefan and other seniors > > > > I encounter some problems about cfi flash driver. > > And hope you can give some comments to resolve it. > > Followings are the flash verification status and descriptions : > > > > When I verify cfi flash which it's address base is in cacheable region > > (0x8800) and cache is enabled in system. > > The flash detection, write and erase action will be failure somehow. > > The failure messages will be as below: > > > > # > > # Detection failure # > > # > > Flash: ## Unknown flash on Bank 1 - Size = 0x = 0 MB > > 0 Bytes > > > > ### > > # Erase fail # > > ### > > protect off all; erase 0x8800 0x8bff; > > Error: start and/or end address not on sector boundary > > RISC-V # > > > > ### > > # Write fail # > > ### > > RISC-V # cp.b 0x2000 0x8bf0 0x1444 > > RISC-V # > > > > But when I disable cache in system, they will all pass the verification. > > > > > > # Detection pass # > > > > Flash: 64 MiB > > > > # > > # erase pass # > > # > > protect off all; erase 0x8800 0x8bff; > > Un-Protect Flash Bank # 1 > > > > > > > > > > > > > > > > > > > > > > > > done > > Erased 512 sectors > > RISC-V # > > > > ## > > # write pass # > > ## > > RISC-V # cp.b 0x2000 0x8bf0 0x1444 > > Copy to Flash... done > > RISC-V # > > > > How can I enable cache and let cfi flash can work fine to get better > > performance ? > > The CFI driver expects the flash to be located on a uncached area. > Is it possible on your architecture to map some areas uncached Yes. We have configuresd the flash address base in the uncached area in another platform before. And it would not be affected by enabling cache. > and others cached? That's how it was done in the old PowerPC days, > when parallel flash (via CFI) was still used much more frequently. > Now I know it much more. Thanks for sharing the useful advice. B.R Rick > Thanks, > Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/2] Makefile: Add target to generate hex output for combined spl and dtb
On 6/4/19 1:57 AM, Dalon Westergreen wrote: > From: Dalon Westergreen > > Some architectures, Stratix10, require a hex formatted spl that combines > the spl image and dtb. This adds a target to create said hex file with > and offset of SPL_TEXT_BASE. > > Signed-off-by: Dalon Westergreen > [...] > @@ -363,6 +365,11 @@ endif > $(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE > $(call if_changed,mkimage) > > +OBJCOPYFLAGS_$(SPL_BIN).hex := -I binary -O ihex > --change-address=$(CONFIG_SPL_TEXT_BASE) Do we really need to do it here ? The commit message is not clear why this is needed ; I think if you link the SPl against the correct address, this should not be needed. > +$(obj)/$(SPL_BIN).hex: $(obj)/u-boot-spl.bin FORCE > + $(call if_changed,objcopy) > + > quiet_cmd_mksunxiboot = MKSUNXI $@ > cmd_mksunxiboot = $(objtree)/tools/mksunxiboot \ > --default-dt $(CONFIG_DEFAULT_DEVICE_TREE) $< $@ > @@ -463,3 +470,4 @@ ifdef CONFIG_ARCH_K3 > tispl.bin: $(obj)/u-boot-spl-nodtb.bin $(SHRUNK_ARCH_DTB) $(SPL_ITS) FORCE > $(call if_changed,mkfitimage) > endif > + Drop this hunk -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] ARM: socfpga: stratix10: Remove CONFIG_OF_EMBED
From: Dalon Westergreen CONFIG_OF_EMBED was primarily enabled to support the stratix10 spl hex file requirements. Since this option now produces a warning during build, and the spl hex can be created using alternate methods, CONFIG_OF_EMBED is no longer needed. Signed-off-by: Dalon Westergreen --- Changes in v2: -> Change CONFIG_SPL_TARGET back to u-boot-spl.hex --- configs/socfpga_stratix10_defconfig | 1 - include/configs/socfpga_stratix10_socdk.h | 2 +- 2 files changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/socfpga_stratix10_defconfig b/configs/socfpga_stratix10_defconfig index fbab388b43..f27180385d 100644 --- a/configs/socfpga_stratix10_defconfig +++ b/configs/socfpga_stratix10_defconfig @@ -26,7 +26,6 @@ CONFIG_CMD_CACHE=y CONFIG_CMD_EXT4=y CONFIG_CMD_FAT=y CONFIG_CMD_FS_GENERIC=y -CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" CONFIG_ENV_IS_IN_MMC=y CONFIG_NET_RANDOM_ETHADDR=y diff --git a/include/configs/socfpga_stratix10_socdk.h b/include/configs/socfpga_stratix10_socdk.h index 39d757d737..66855ff0d8 100644 --- a/include/configs/socfpga_stratix10_socdk.h +++ b/include/configs/socfpga_stratix10_socdk.h @@ -210,6 +210,6 @@ unsigned int cm_get_l4_sys_free_clk_hz(void); /* SPL SDMMC boot support */ #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION 1 -#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot-dtb.img" #endif /* __CONFIG_H */ -- 2.21.0 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 1/2] Makefile: Add target to generate hex output for combined spl and dtb
From: Dalon Westergreen
Some architectures, Stratix10, require a hex formatted spl that combines
the spl image and dtb. This adds a target to create said hex file with
and offset of SPL_TEXT_BASE.
Signed-off-by: Dalon Westergreen
---
Changes in v2:
-> Move spl hex file generation to SPL Makefile
-> Create hexfile from $(SPL_BIN).bin which will include the dtb
ifneq(build_dtb,)
---
Makefile | 9 -
scripts/Makefile.spl | 8
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 07106138e9..12e36ebb72 100644
--- a/Makefile
+++ b/Makefile
@@ -1124,11 +1124,6 @@ OBJCOPYFLAGS_u-boot-nodtb.bin := -O binary \
$(if $(CONFIG_X86_16BIT_INIT),-R .start16 -R .resetvec) \
$(if $(CONFIG_MPC85XX_HAVE_RESET_VECTOR),-R .bootpg -R
.resetvec)
-OBJCOPYFLAGS_u-boot-spl.hex = $(OBJCOPYFLAGS_u-boot.hex)
-
-spl/u-boot-spl.hex: spl/u-boot-spl FORCE
- $(call if_changed,objcopy)
-
binary_size_check: u-boot-nodtb.bin FORCE
@file_size=$(shell wc -c u-boot-nodtb.bin | awk '{print $$1}') ; \
map_size=$(shell cat u-boot.map | \
@@ -1707,6 +1702,10 @@ u-boot.lds: $(LDSCRIPT) prepare FORCE
spl/u-boot-spl.bin: spl/u-boot-spl
@:
+
+spl/u-boot-spl.hex: spl/u-boot-spl
+ @:
+
spl/u-boot-spl: tools prepare \
$(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SPL_OF_PLATDATA),dts/dt.dtb) \
$(if
$(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_TPL_OF_PLATDATA),dts/dt.dtb)
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index 7af6b120b6..419bb6e222 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -216,6 +216,8 @@ ifneq
($(CONFIG_TARGET_SOCFPGA_GEN5)$(CONFIG_TARGET_SOCFPGA_ARRIA10),)
ALL-y += $(obj)/$(SPL_BIN).sfp
endif
+ALL-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += $(obj)/$(SPL_BIN).hex
+
ifdef CONFIG_ARCH_SUNXI
ALL-y += $(obj)/sunxi-spl.bin
@@ -363,6 +365,11 @@ endif
$(obj)/$(SPL_BIN).sfp: $(obj)/$(SPL_BIN).bin FORCE
$(call if_changed,mkimage)
+OBJCOPYFLAGS_$(SPL_BIN).hex := -I binary -O ihex
--change-address=$(CONFIG_SPL_TEXT_BASE)
+
+$(obj)/$(SPL_BIN).hex: $(obj)/u-boot-spl.bin FORCE
+ $(call if_changed,objcopy)
+
quiet_cmd_mksunxiboot = MKSUNXI $@
cmd_mksunxiboot = $(objtree)/tools/mksunxiboot \
--default-dt $(CONFIG_DEFAULT_DEVICE_TREE) $< $@
@@ -463,3 +470,4 @@ ifdef CONFIG_ARCH_K3
tispl.bin: $(obj)/u-boot-spl-nodtb.bin $(SHRUNK_ARCH_DTB) $(SPL_ITS) FORCE
$(call if_changed,mkfitimage)
endif
+
--
2.21.0
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] dm: i2c: Add a flag that not call i2c_setup_offset
On Thu, 30 May 2019 18:31:48 +0800
Chuanhua Han wrote:
> Usually the i2c bus needs to write the address of the register before
> reading the internal register data of the device (ignoring the
> transmission of the slave address).
>
> Generally, the stop signal is not needed before the register is read,
> but there is a special chip that needs this stop signal (such as
> pcf2127). However, in the current i2c general code, the dm_i2c_read
> api encapsulates two messages, the first time is to set the register
> address message, the second time is a message to read the register
> data, so that no stop signal is generated.
>
> This patch uses the DM_I2C_CHIP_RD_NO_I2C_SETUP_OFFSET flag for
> specific i2c chips, so if the i2c slave requires a stop signal, chips
> driver can set this flag, then call the dm_i2c_write to set the
> register address (a stop signal is generated after this API call),
> then call dm_i2c_read to read the register data.
>
> Signed-off-by: Chuanhua Han
> ---
> Changes in v3:
> - Use the new flag DM_I2C_CHIP_RD_NO_I2C_SETUP_OFFSET
>
> Changes in v2:
> - Split the original patch into 3 patches
> - Add detailed description information for each patch
>
> drivers/i2c/i2c-uclass.c | 6 --
> include/i2c.h| 1 +
> 2 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/i2c-uclass.c b/drivers/i2c/i2c-uclass.c
> index e47abf1833..9804b5e8c7 100644
> --- a/drivers/i2c/i2c-uclass.c
> +++ b/drivers/i2c/i2c-uclass.c
> @@ -135,8 +135,10 @@ int dm_i2c_read(struct udevice *dev, uint
> offset, uint8_t *buffer, int len) if (chip->flags &
> DM_I2C_CHIP_RD_ADDRESS) return i2c_read_bytewise(dev, offset, buffer,
> len); ptr = msg;
> - if (!i2c_setup_offset(chip, offset, offset_buf, ptr))
> - ptr++;
> + if (!(chip->flags & DM_I2C_CHIP_RD_NO_I2C_SETUP_OFFSET)) {
> + if (!i2c_setup_offset(chip, offset, offset_buf, ptr))
> + ptr++;
> + }
>
> if (len) {
> ptr->addr = chip->chip_addr;
> diff --git a/include/i2c.h b/include/i2c.h
> index a5c760c711..3123cbf280 100644
> --- a/include/i2c.h
> +++ b/include/i2c.h
> @@ -28,6 +28,7 @@ enum dm_i2c_chip_flags {
> DM_I2C_CHIP_10BIT = 1 << 0,
> /* Use 10-bit addressing */
> DM_I2C_CHIP_RD_ADDRESS = 1 << 1,
> /* Send address for each read byte */
> DM_I2C_CHIP_WR_ADDRESS = 1 << 2,
> /* Send address for each write byte */
Aren't those two above flags describe exactly what you need? They send
address for each read/written byte. (or do you need to send more than a
single byte)?
> DM_I2C_CHIP_RD_NO_I2C_SETUP_OFFSET = 1 << 3,
> /* No i2c_setup_offset*/ };
>
> struct udevice;
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgp9EUwDDlzmG.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Sjoerd,
> From: Frieder Schrempf
>
> Add support for loading u-boot FIT images over the USB SPD protocol in
> the SPL
>
> [Small fixes to build]
> Signed-off-by: Sjoerd Simons
Reviewed-by: Lukasz Majewski
> ---
>
> common/spl/spl_sdp.c | 11 --
> drivers/usb/gadget/f_sdp.c | 41
> -- include/sdp.h |
> 4 +++- 3 files changed, 47 insertions(+), 9 deletions(-)
>
> diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
> index 807256e908..dc57171966 100644
> --- a/common/spl/spl_sdp.c
> +++ b/common/spl/spl_sdp.c
> @@ -26,9 +26,16 @@ static int spl_sdp_load_image(struct
> spl_image_info *spl_image, }
>
> /* This command typically does not return but jumps to an
> image */
> - sdp_handle(controller_index);
> + sdp_handle(controller_index, spl_image);
> pr_err("SDP ended\n");
> + /*
> + * This command either loads a legacy image, jumps and never
> returns,
> + * or it loads a FIT image and returns it to be handled by
> the SPL
> + * code.
> + */
> + ret = sdp_handle(controller_index, spl_image);
> + debug("SDP ended\n");
>
> - return -EINVAL;
> + return ret;
> }
> SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_BOARD,
> spl_sdp_load_image); diff --git a/drivers/usb/gadget/f_sdp.c
> b/drivers/usb/gadget/f_sdp.c index ae97ab2b49..2a23160d91 100644
> --- a/drivers/usb/gadget/f_sdp.c
> +++ b/drivers/usb/gadget/f_sdp.c
> @@ -638,7 +638,18 @@ static u32 sdp_jump_imxheader(void *address)
> return 0;
> }
>
> -static void sdp_handle_in_ep(void)
> +#ifdef CONFIG_SPL_LOAD_FIT
> +static ulong sdp_fit_read(struct spl_load_info *load, ulong sector,
> + ulong count, void *buf)
> +{
> + debug("%s: sector %lx, count %lx, buf %lx\n",
> + __func__, sector, count, (ulong)buf);
> + memcpy(buf, (void *)(load->dev + sector), count);
> + return count;
> +}
> +#endif
> +
> +static void sdp_handle_in_ep(struct spl_image_info *spl_image)
> {
> u8 *data = sdp_func->in_req->buf;
> u32 status;
> @@ -689,11 +700,26 @@ static void sdp_handle_in_ep(void)
>
> /* If imx header fails, try some U-Boot specific
> headers */ if (status) {
> + image_header_t *header =
> + sdp_ptr(sdp_func->jmp_address);
> #ifdef CONFIG_SPL_BUILD
> +#ifdef CONFIG_SPL_LOAD_FIT
> + if (image_get_magic(header) == FDT_MAGIC) {
> + struct spl_load_info load;
> +
> + debug("Found FIT\n");
> + load.dev = header;
> + load.bl_len = 1;
> + load.read = sdp_fit_read;
> + spl_load_simple_fit(spl_image,
> , 0,
> + header);
> +
> + return;
> + }
> +#endif
> /* In SPL, allow jumps to U-Boot images */
> struct spl_image_info spl_image = {};
> - spl_parse_image_header(_image,
> - (struct image_header
> *)sdp_func->jmp_address);
> + spl_parse_image_header(_image, header);
> jump_to_image_no_args(_image);
> #else
> /* In U-Boot, allow jumps to scripts */
> @@ -715,19 +741,22 @@ static void sdp_handle_in_ep(void)
> };
> }
>
> -void sdp_handle(int controller_index)
> +int sdp_handle(int controller_index, struct spl_image_info
> *spl_image) {
> printf("SDP: handle requests...\n");
> while (1) {
> if (ctrlc()) {
> puts("\rCTRL+C - Operation aborted.\n");
> - return;
> + return -EINVAL;
> }
>
> + if (spl_image->flags & SPL_FIT_FOUND)
> + return 0;
> +
> WATCHDOG_RESET();
> usb_gadget_handle_interrupts(controller_index);
>
> - sdp_handle_in_ep();
> + sdp_handle_in_ep(spl_image);
> }
> }
>
> diff --git a/include/sdp.h b/include/sdp.h
> index f6252d027f..f30e2bca19 100644
> --- a/include/sdp.h
> +++ b/include/sdp.h
> @@ -9,7 +9,9 @@
> #ifndef __SDP_H_
> #define __SDP_H_
>
> +#include
> +
> int sdp_init(int controller_index);
> -void sdp_handle(int controller_index);
> +int sdp_handle(int controller_index, struct spl_image_info
> *spl_image);
> #endif /* __SDP_H_ */
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de
pgpxMP_K98LJO.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
Re: [U-Boot] [PATCH 0/5] Enable usage of SDP for i.MX6 Sabre Auto Boards
Hi Sjoerd, > Being able to upload u-boot over USB is rather useful, so ideally this > functionality should be enabled by the default config for these > boards. Currently however no USB support is built into the SPL nor is > SDP enabled for i.MX6 Sabre Auto boards. > > The first two patches in this series adjust the defconfig in a similar > way as Fabio has done in a recent patchset for Sabre SD. The first one > drops SPL DM support as there is no way to fit that *and* USB support > in at the moment, the second one adds missing pinctrl configuration > for the main u-boot binary. > > The third patch enabled USB & SPL SDP support. > > Patch four adds support for loading FIT images over SDP as that is > what is in use for the Sabre auto's main u-boot image. This is simply > the patch Frieder Schrempf submitted to the mainlinglist earlier, but > made to build on current git master. (Frieder could you be so kind to > add your SoB?). > > The final patch fixes the u-boot image failing to start due to > DM_VIDEO. > > Patchset tested by using uuu with the following configuration: > ``` > uuu_version 1.2 > SDP: boot -f SPL > SDPU: write -f u-boot-dtb.img -addr 0x1000 > SDPU: jump -addr 0x1000 > SPDU: done > ``` > > I suspect these patches are to late for 2019.07, especially since FIT > support in SDP would be a new feature? If so I'm happy to split this > set out of patches that should definatly land for 2019.07 (Making > sabre auto work) and submit the others for 2019.10 I think that Fabio and Stefano would have a final opinion, but IMHO, it would be best if you would split those patches. > > > Frieder Schrempf (1): > usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP > > Sjoerd Simons (4): > mx6sabreauto: Remove CONFIG_SPL_DM to decrease the SPL size > mx6sabreauto: Select pinctrl driver > mx6sabreauto: Enable SPL SDP support > mx6sabreauto: set SYS_MALLOC_F for video > > common/spl/spl_sdp.c | 11 +++-- > configs/mx6sabreauto_defconfig | 8 +-- > drivers/usb/gadget/f_sdp.c | 41 > +- include/sdp.h | > 4 +++- 4 files changed, 53 insertions(+), 11 deletions(-) > Best regards, Lukasz Majewski -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de pgpG_NTRZTIJY.pgp Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 5/6] ARM: dts: colibri_imx7: Add lcdif node
From: Igor Opaniuk
Extend lcdif DT node with proper display-timings for mxsfb driver.
Signed-off-by: Igor Opaniuk
---
arch/arm/dts/imx7-colibri-emmc.dts | 2 ++
arch/arm/dts/imx7-colibri.dtsi | 28
2 files changed, 30 insertions(+)
diff --git a/arch/arm/dts/imx7-colibri-emmc.dts
b/arch/arm/dts/imx7-colibri-emmc.dts
index efd600091d..8db2a62707 100644
--- a/arch/arm/dts/imx7-colibri-emmc.dts
+++ b/arch/arm/dts/imx7-colibri-emmc.dts
@@ -11,8 +11,10 @@
compatible = "toradex,imx7d-colibri-emmc", "fsl,imx7d";
aliases {
+ u-boot,dm-pre-reloc;
mmc0 =
mmc1 =
+ display1 =
};
chosen {
diff --git a/arch/arm/dts/imx7-colibri.dtsi b/arch/arm/dts/imx7-colibri.dtsi
index a85702f519..81717c233d 100644
--- a/arch/arm/dts/imx7-colibri.dtsi
+++ b/arch/arm/dts/imx7-colibri.dtsi
@@ -111,3 +111,31 @@
>;
};
};
+
+ {
+ u-boot,dm-pre-reloc;
+ status = "okay";
+
+ display-timings {
+ native-mode = <_vga>;
+
+ /* Standard VGA timing */
+ timing_vga: 640x480 {
+ u-boot,dm-pre-reloc;
+ clock-frequency = <25175000>;
+ hactive = <640>;
+ vactive = <480>;
+ hback-porch = <48>;
+ hfront-porch = <16>;
+ vback-porch = <33>;
+ vfront-porch = <10>;
+ hsync-len = <96>;
+ vsync-len = <2>;
+
+ de-active = <1>;
+ hsync-active = <0>;
+ vsync-active = <0>;
+ pixelclk-active = <0>;
+ };
+ };
+};
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 3/6] video: mxsfb: refactor video_hw_init()
From: Igor Opaniuk
Refactor video_hw_init() function, and introduce an independent function
for the common procedure of initialization.
Currently video_hw_init() is only in charge of parsing configuration from
env("videomode") and filling struct GraphicPanel, and new
mxs_probe_common() does hw specific initialization (invocation of
mxs_lcd_init() etc.)
Signed-off-by: Igor Opaniuk
---
drivers/video/mxsfb.c | 68 ++-
1 file changed, 41 insertions(+), 27 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 059fbf2b05..6e269409d6 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -128,6 +128,37 @@ static void mxs_lcd_init(u32 fb_addr, struct
ctfb_res_modes *mode, int bpp)
writel(LCDIF_CTRL_RUN, >hw_lcdif_ctrl_set);
}
+static int mxs_probe_common(struct ctfb_res_modes *mode, int bpp, void *fb)
+{
+ /* Start framebuffer */
+ mxs_lcd_init((u32)fb, mode, bpp);
+
+#ifdef CONFIG_VIDEO_MXS_MODE_SYSTEM
+ /*
+* If the LCD runs in system mode, the LCD refresh has to be triggered
+* manually by setting the RUN bit in HW_LCDIF_CTRL register. To avoid
+* having to set this bit manually after every single change in the
+* framebuffer memory, we set up specially crafted circular DMA, which
+* sets the RUN bit, then waits until it gets cleared and repeats this
+* infinitelly. This way, we get smooth continuous updates of the LCD.
+*/
+ struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
+
+ memset(, 0, sizeof(struct mxs_dma_desc));
+ desc.address = (dma_addr_t)
+ desc.cmd.data = MXS_DMA_DESC_COMMAND_NO_DMAXFER | MXS_DMA_DESC_CHAIN |
+ MXS_DMA_DESC_WAIT4END |
+ (1 << MXS_DMA_DESC_PIO_WORDS_OFFSET);
+ desc.cmd.pio_words[0] = readl(>hw_lcdif_ctrl) | LCDIF_CTRL_RUN;
+ desc.cmd.next = (uint32_t)
+
+ /* Execute the DMA chain. */
+ mxs_dma_circ_start(MXS_DMA_CHANNEL_AHB_APBH_LCDIF, );
+#endif
+
+ return 0;
+}
+
void lcdif_power_down(void)
{
struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
@@ -151,8 +182,9 @@ void lcdif_power_down(void)
void *video_hw_init(void)
{
int bpp = -1;
+ int ret = 0;
char *penv;
- void *fb;
+ void *fb = NULL;
struct ctfb_res_modes mode;
puts("Video: ");
@@ -167,8 +199,7 @@ void *video_hw_init(void)
bpp = video_get_params(, penv);
/* fill in Graphic device struct */
- sprintf(panel.modeIdent, "%dx%dx%d",
- mode.xres, mode.yres, bpp);
+ sprintf(panel.modeIdent, "%dx%dx%d", mode.xres, mode.yres, bpp);
panel.winSizeX = mode.xres;
panel.winSizeY = mode.yres;
@@ -211,31 +242,14 @@ void *video_hw_init(void)
printf("%s\n", panel.modeIdent);
- /* Start framebuffer */
- mxs_lcd_init(panel.frameAdrs, , bpp);
-
-#ifdef CONFIG_VIDEO_MXS_MODE_SYSTEM
- /*
-* If the LCD runs in system mode, the LCD refresh has to be triggered
-* manually by setting the RUN bit in HW_LCDIF_CTRL register. To avoid
-* having to set this bit manually after every single change in the
-* framebuffer memory, we set up specially crafted circular DMA, which
-* sets the RUN bit, then waits until it gets cleared and repeats this
-* infinitelly. This way, we get smooth continuous updates of the LCD.
-*/
- struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
+ ret = mxs_probe_common(, bpp, fb);
+ if (ret)
+ goto dealloc_fb;
- memset(, 0, sizeof(struct mxs_dma_desc));
- desc.address = (dma_addr_t)
- desc.cmd.data = MXS_DMA_DESC_COMMAND_NO_DMAXFER | MXS_DMA_DESC_CHAIN |
- MXS_DMA_DESC_WAIT4END |
- (1 << MXS_DMA_DESC_PIO_WORDS_OFFSET);
- desc.cmd.pio_words[0] = readl(>hw_lcdif_ctrl) | LCDIF_CTRL_RUN;
- desc.cmd.next = (uint32_t)
+ return (void *)
- /* Execute the DMA chain. */
- mxs_dma_circ_start(MXS_DMA_CHANNEL_AHB_APBH_LCDIF, );
-#endif
+dealloc_fb:
+ free(fb);
- return (void *)
+ return NULL;
}
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 2/6] video: mxsfb: reorder includes
From: Igor Opaniuk Follow alphabetical order of includes, which simplifies detecting duplicate includes etc. Signed-off-by: Igor Opaniuk --- drivers/video/mxsfb.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c index 0f3a10b0f6..059fbf2b05 100644 --- a/drivers/video/mxsfb.c +++ b/drivers/video/mxsfb.c @@ -5,16 +5,15 @@ * Copyright (C) 2011-2013 Marek Vasut */ #include +#include #include #include -#include #include +#include #include -#include -#include - #include +#include #include "videomodes.h" -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 6/6] colibri_imx7_emmc: enable DM_VIDEO
From: Igor Opaniuk Enable DM_VIDEO for Colibri iMX7 eMMC version. Signed-off-by: Igor Opaniuk --- configs/colibri_imx7_emmc_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/colibri_imx7_emmc_defconfig b/configs/colibri_imx7_emmc_defconfig index f35cabaed6..392d4ab8d0 100644 --- a/configs/colibri_imx7_emmc_defconfig +++ b/configs/colibri_imx7_emmc_defconfig @@ -63,6 +63,6 @@ CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4000 CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y -CONFIG_VIDEO=y +CONFIG_DM_VIDEO=y CONFIG_FAT_WRITE=y CONFIG_OF_LIBFDT_OVERLAY=y -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 1/6] video: mxsfb: change mxs_lcd_init signature
From: Igor Opaniuk
Provide directly framebuffer address instead of pointer to
GraphicDevice struct, which will let to re-use this function in
DM_VIDEO configurations.
Signed-off-by: Igor Opaniuk
---
drivers/video/mxsfb.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 02fde05908..0f3a10b0f6 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -46,8 +46,7 @@ __weak void mxsfb_system_setup(void)
* le:89,ri:164,up:23,lo:10,hs:10,vs:10,sync:0,vmode:0
*/
-static void mxs_lcd_init(GraphicDevice *panel,
- struct ctfb_res_modes *mode, int bpp)
+static void mxs_lcd_init(u32 fb_addr, struct ctfb_res_modes *mode, int bpp)
{
struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
uint32_t word_len = 0, bus_width = 0;
@@ -112,8 +111,8 @@ static void mxs_lcd_init(GraphicDevice *panel,
writel((0 << LCDIF_VDCTRL4_DOTCLK_DLY_SEL_OFFSET) | mode->xres,
>hw_lcdif_vdctrl4);
- writel(panel->frameAdrs, >hw_lcdif_cur_buf);
- writel(panel->frameAdrs, >hw_lcdif_next_buf);
+ writel(fb_addr, >hw_lcdif_cur_buf);
+ writel(fb_addr, >hw_lcdif_next_buf);
/* Flush FIFO first */
writel(LCDIF_CTRL1_FIFO_CLEAR, >hw_lcdif_ctrl1_set);
@@ -214,7 +213,7 @@ void *video_hw_init(void)
printf("%s\n", panel.modeIdent);
/* Start framebuffer */
- mxs_lcd_init(, , bpp);
+ mxs_lcd_init(panel.frameAdrs, , bpp);
#ifdef CONFIG_VIDEO_MXS_MODE_SYSTEM
/*
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [RFC 4/6] video: mxsfb: add DM_VIDEO support
From: Igor Opaniuk
Extend the driver to build with DM_VIDEO enabled. DTS files
must additionally include 'u-boot,dm-pre-reloc' property in
soc and child nodes to enable driver binding to mxsfb device.
Signed-off-by: Igor Opaniuk
---
arch/arm/mach-imx/cpu.c| 2 +-
arch/arm/mach-imx/mx7/soc.c| 2 +-
drivers/video/mxsfb.c | 145 +++--
include/configs/colibri_imx7.h | 2 +-
4 files changed, 139 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-imx/cpu.c b/arch/arm/mach-imx/cpu.c
index 6b83f92662..64a0670fcf 100644
--- a/arch/arm/mach-imx/cpu.c
+++ b/arch/arm/mach-imx/cpu.c
@@ -298,7 +298,7 @@ void arch_preboot_os(void)
/* disable video before launching O/S */
ipuv3_fb_shutdown();
#endif
-#if defined(CONFIG_VIDEO_MXS)
+#if defined(CONFIG_VIDEO_MXS) && !defined(CONFIG_DM_VIDEO)
lcdif_power_down();
#endif
}
diff --git a/arch/arm/mach-imx/mx7/soc.c b/arch/arm/mach-imx/mx7/soc.c
index 7cfdff0981..4a914fca5e 100644
--- a/arch/arm/mach-imx/mx7/soc.c
+++ b/arch/arm/mach-imx/mx7/soc.c
@@ -369,7 +369,7 @@ void s_init(void)
void reset_misc(void)
{
#ifndef CONFIG_SPL_BUILD
-#ifdef CONFIG_VIDEO_MXS
+#if defined(CONFIG_VIDEO_MXS) && !defined(CONFIG_DM_VIDEO)
lcdif_power_down();
#endif
#endif
diff --git a/drivers/video/mxsfb.c b/drivers/video/mxsfb.c
index 6e269409d6..f02ba20138 100644
--- a/drivers/video/mxsfb.c
+++ b/drivers/video/mxsfb.c
@@ -5,8 +5,10 @@
* Copyright (C) 2011-2013 Marek Vasut
*/
#include
+#include
#include
#include
+#include
#include
#include
@@ -18,8 +20,11 @@
#include "videomodes.h"
#definePS2KHZ(ps) (10UL / (ps))
+#define HZ2PS(hz) (10UL / ((hz) / 1000))
+
+#define BITS_PP18
+#define BYTES_PP 4
-static GraphicDevice panel;
struct mxs_dma_desc desc;
/**
@@ -128,10 +133,10 @@ static void mxs_lcd_init(u32 fb_addr, struct
ctfb_res_modes *mode, int bpp)
writel(LCDIF_CTRL_RUN, >hw_lcdif_ctrl_set);
}
-static int mxs_probe_common(struct ctfb_res_modes *mode, int bpp, void *fb)
+static int mxs_probe_common(struct ctfb_res_modes *mode, int bpp, u32 fb)
{
/* Start framebuffer */
- mxs_lcd_init((u32)fb, mode, bpp);
+ mxs_lcd_init(fb, mode, bpp);
#ifdef CONFIG_VIDEO_MXS_MODE_SYSTEM
/*
@@ -159,16 +164,16 @@ static int mxs_probe_common(struct ctfb_res_modes *mode,
int bpp, void *fb)
return 0;
}
-void lcdif_power_down(void)
+static int mxs_remove_common(u32 fb)
{
struct mxs_lcdif_regs *regs = (struct mxs_lcdif_regs *)MXS_LCDIF_BASE;
int timeout = 100;
- if (!panel.frameAdrs)
- return;
+ if (!fb)
+ return -EINVAL;
- writel(panel.frameAdrs, >hw_lcdif_cur_buf_reg);
- writel(panel.frameAdrs, >hw_lcdif_next_buf_reg);
+ writel(fb, >hw_lcdif_cur_buf_reg);
+ writel(fb, >hw_lcdif_next_buf_reg);
writel(LCDIF_CTRL1_VSYNC_EDGE_IRQ, >hw_lcdif_ctrl1_clr);
while (--timeout) {
if (readl(>hw_lcdif_ctrl1_reg) &
@@ -177,6 +182,17 @@ void lcdif_power_down(void)
udelay(1);
}
mxs_reset_block((struct mxs_register_32 *)>hw_lcdif_ctrl_reg);
+
+ return 0;
+}
+
+#ifndef CONFIG_DM_VIDEO
+
+static GraphicDevice panel;
+
+void lcdif_power_down(void)
+{
+ mxs_remove_common(panel.frameAdrs);
}
void *video_hw_init(void)
@@ -242,7 +258,7 @@ void *video_hw_init(void)
printf("%s\n", panel.modeIdent);
- ret = mxs_probe_common(, bpp, fb);
+ ret = mxs_probe_common(, bpp, (u32)fb);
if (ret)
goto dealloc_fb;
@@ -253,3 +269,114 @@ dealloc_fb:
return NULL;
}
+#else /* ifndef CONFIG_DM_VIDEO */
+
+static int mxs_video_probe(struct udevice *dev)
+{
+ struct video_uc_platdata *plat = dev_get_uclass_platdata(dev);
+ struct video_priv *uc_priv = dev_get_uclass_priv(dev);
+
+ struct ctfb_res_modes mode;
+ struct display_timing timings;
+ int bpp = -1;
+ u32 fb_start, fb_end;
+ int ret;
+
+ debug("%s() plat: base 0x%lx, size 0x%x\n",
+ __func__, plat->base, plat->size);
+
+ ret = ofnode_decode_display_timing(dev_ofnode(dev), 0, );
+ if (ret) {
+ dev_err(dev, "failed to get any display timings\n");
+ return -EINVAL;
+ }
+
+ mode.xres = timings.hactive.typ;
+ mode.yres = timings.vactive.typ;
+ mode.left_margin = timings.hback_porch.typ;
+ mode.right_margin = timings.hfront_porch.typ;
+ mode.upper_margin = timings.vback_porch.typ;
+ mode.lower_margin = timings.vfront_porch.typ;
+ mode.hsync_len = timings.hsync_len.typ;
+ mode.vsync_len = timings.vsync_len.typ;
+ mode.pixclock = HZ2PS(timings.pixelclock.typ);
+
+ bpp = BITS_PP;
+
+ ret = mxs_probe_common(, bpp, plat->base);
+ if (ret)
+ return ret;
+
+
[U-Boot] [RFC 0/6] Convert mxsfb to DM_VIDEO
From: Igor Opaniuk This series of patches refactors and extends NXP mxsfb video driver to be build with DM_VIDEO enabled. DTS files must additionally include 'u-boot,dm-pre-reloc' property in soc and child nodes to enable driver binding to mxsfb device. Also enables DM_VIDEO by default for Colibri iMX7 eMMC edition. Igor Opaniuk (6): video: mxsfb: change mxs_lcd_init signature video: mxsfb: reorder includes video: mxsfb: refactor video_hw_init() video: mxsfb: add DM_VIDEO support ARM: dts: colibri_imx7: Add lcdif node colibri_imx7_emmc: enable DM_VIDEO arch/arm/dts/imx7-colibri-emmc.dts | 2 + arch/arm/dts/imx7-colibri.dtsi | 28 arch/arm/mach-imx/cpu.c | 2 +- arch/arm/mach-imx/mx7/soc.c | 2 +- configs/colibri_imx7_emmc_defconfig | 2 +- drivers/video/mxsfb.c | 219 +++- include/configs/colibri_imx7.h | 2 +- 7 files changed, 213 insertions(+), 44 deletions(-) -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
> On Jun 3, 2019, at 12:02 PM, Tom Rini wrote: > > On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote: >> >> >>> On Jun 3, 2019, at 5:49 AM, Andreas Schwab wrote: >>> >>> On Mai 29 2019, Karsten Merker wrote: >>> Mainline U-Boot already uses the distro bootcmd environment for the qemu "virt" machine and it works well. >>> >>> The distro_bootcmd doesn't work for the sifive platform yet because it >>> doesn't set the correct MAC address for booting. >>> >>> Andreas. >>> >> >> Before we go an use distro_bootcmd and drag in a bunch of legacy stuff >> we really should not be using, can we make some kind of effort to decide >> what the design goals and boot flow should look like instead using the >> default legacy behavior of a bunch of hard to read and maintain CPP >> macros? > > I feel like you're calling "what everyone agreed on and uses today" > legacy just because it already exists. It is a bit complex because > devices are so complex, rather than it having to support one-off > situations or similar things people usually call "legacy”. My biggest complaint is all the CPP macros, which are really hard to maintain and read. I should probably be more careful to quantify ‘legacy’ much more specifically as “legacy proprietary ROM code”. Or maybe that’s not the right term at all For the first time I know of, we have a (mostly) blank slate to write the ROM boot code to help manage boot complexity. So I’d like to make sure we can tease out all the reasons we have all this important logic and knowledge tied up in a single header file, and at least re-examine is there a better way to do this than abusing CPP. > >> The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’. >> >> What good does it do linux distros on RiscV to keep using the old boot >> script format, rather than just load a text file and use ‘env import’? Is >> there >> some benefit to this? Do we gain something from the .scr format, like >> maybe cryptographic signature support? > > Writing things out in script format ends up being more natural (and > easier to understand) than writing things out in environment format. > This is why while I wish the "uEnv.txt" hook had become more popular and > widely used, at this point I also understand why it wasn't. Doing > a=foo > b=bar > c=baz > magic_name=do this;do that > > Was not easier nor more understandable than: > setenv a foo > setenv b bar > setenv c baz > do this; do that uEnv has the significant user experience advantage of being editable with a plain old text editor, which is why I used it in freedom-u-sdk. If we can get a ’script’ format that can be edited by a non-technical user on a windows or mac box without requiring mkimage, then we have an improvement. Can this be done with .scr currently? > >> How do we want to support secure boot into Debian, Fedora, and Suse, >> and does distro_bootcmd have a way to do this, or can we come up with >> some improvement that doesn’t depend on trying to do all the work in >> CPP macros and U-boot runtime scripts? > > I think the general answer about "secure boot" is that distros want > "UEFI secure boot". And I want to make sure that's done in such a way > that things like user-owned secure boot aren't any more difficult than > vendor secured boot. It seems like making use of existing secure boot > mechanisms has set aside as, well, I don't want to throw snark around > myself, so I'll refrain from speculating. > > -- > Tom The problematic issue with ‘user-owned secure boot’ is it’s never been a major ‘business critical’ need, so it’s always ended up lower on the priority list from anyone who’s looking at what their clients are paying for. Now on that note, I think maybe the best way to approach this is to start with a clear community consensus that we MUST support a user experience where an end-user with an open RiscV device MUST be able to edit the boot parameters (boot script? uEnv.txt?), and then be able to resign the script with their key(s), so the system can boot and maintain a secured state when it gets to userspace where we are running distro-signed binaries. I honestly don’t know of anyone that’s really looked at this in a commercial setting other than maybe purism, and they are a pretty niche vendor, and stuck with a lot of x86 legacy to deal with. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
On Mon, Jun 03, 2019 at 12:17:43PM -0700, Palmer Dabbelt wrote: > On Mon, 03 Jun 2019 10:02:57 PDT (-0700), tr...@konsulko.com wrote: > >On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote: > >> > >> > >>> On Jun 3, 2019, at 5:49 AM, Andreas Schwab wrote: > >>> > On Mai 29 2019, Karsten Merker wrote: > >>> >> Mainline U-Boot already uses the distro bootcmd environment for > the qemu "virt" machine and it works well. > >>> > The distro_bootcmd doesn't work for the sifive platform yet because > >>it > >>> doesn't set the correct MAC address for booting. > >>> > Andreas. > >>> > >> > >>Before we go an use distro_bootcmd and drag in a bunch of legacy stuff > >>we really should not be using, can we make some kind of effort to decide > >>what the design goals and boot flow should look like instead using the > >>default legacy behavior of a bunch of hard to read and maintain CPP > >>macros? > > > >I feel like you're calling "what everyone agreed on and uses today" > >legacy just because it already exists. It is a bit complex because > >devices are so complex, rather than it having to support one-off > >situations or similar things people usually call "legacy". > > The goal in RISC-V land is to avoid inventing our own stuff, particularly when > there's an agreed upon way of doing things. As far as I can tell the users > (ie, distros) all want this distro_bootcmd stuff because it's what already > works in ARM land. While I'm not really a bootloader guy, the general > arguments in favor of distro_bootcmd appaer to be "we tried it some other ways > and that was a mess, but this way works". That is a really strong argument to > me. Right. While I'm sure there's room for improvement, the distro_bootcmd stuff was borne out of working with the distro folks to get what was needed so they could Just Install on whatever SBC the user had. And the EBBR spec (which in turn, roughly, is a subset of UEFI) intends to make that more formal still. As long as we can avoid I think that's a good thing, overall. -- Tom 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 4/5] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
On Mon, 2019-06-03 at 16:17 -0300, Fabio Estevam wrote: > Hi Sjoerd, > > On Mon, Jun 3, 2019 at 4:02 PM Sjoerd Simons > wrote: > > From: Frieder Schrempf > > > > Add support for loading u-boot FIT images over the USB SPD protocol > > in > > the SPL > > > > [Small fixes to build] > > Applied this patch against U-Boot master and it still does not build > for me when using mx6sabresd_defconfig: Ah; that has CONFIG_CMD_USB_SDP which i didn't enable in the sabre auto defconfig (and thus didn't notice the failure). Will fix that. > cmd/usb_gadget_sdp.c: In function ‘do_sdp’: > cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function > ‘sdp_handle’ > sdp_handle(controller_index); > ^~ > In file included from cmd/usb_gadget_sdp.c:11:0: > include/sdp.h:15:5: note: declared here > int sdp_handle(int controller_index, struct spl_image_info > *spl_image); > ^~ > scripts/Makefile.build:278: recipe for target 'cmd/usb_gadget_sdp.o' > failed > make[1]: *** [cmd/usb_gadget_sdp.o] Error -- Sjoerd Simons Collabora Ltd. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
On Mon, 03 Jun 2019 10:02:57 PDT (-0700), tr...@konsulko.com wrote: On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote: > On Jun 3, 2019, at 5:49 AM, Andreas Schwab wrote: > > On Mai 29 2019, Karsten Merker wrote: > >> Mainline U-Boot already uses the distro bootcmd environment for >> the qemu "virt" machine and it works well. > > The distro_bootcmd doesn't work for the sifive platform yet because it > doesn't set the correct MAC address for booting. > > Andreas. > Before we go an use distro_bootcmd and drag in a bunch of legacy stuff we really should not be using, can we make some kind of effort to decide what the design goals and boot flow should look like instead using the default legacy behavior of a bunch of hard to read and maintain CPP macros? I feel like you're calling "what everyone agreed on and uses today" legacy just because it already exists. It is a bit complex because devices are so complex, rather than it having to support one-off situations or similar things people usually call "legacy". The goal in RISC-V land is to avoid inventing our own stuff, particularly when there's an agreed upon way of doing things. As far as I can tell the users (ie, distros) all want this distro_bootcmd stuff because it's what already works in ARM land. While I'm not really a bootloader guy, the general arguments in favor of distro_bootcmd appaer to be "we tried it some other ways and that was a mess, but this way works". That is a really strong argument to me. The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’. What good does it do linux distros on RiscV to keep using the old boot script format, rather than just load a text file and use ‘env import’? Is there some benefit to this? Do we gain something from the .scr format, like maybe cryptographic signature support? Writing things out in script format ends up being more natural (and easier to understand) than writing things out in environment format. This is why while I wish the "uEnv.txt" hook had become more popular and widely used, at this point I also understand why it wasn't. Doing a=foo b=bar c=baz magic_name=do this;do that Was not easier nor more understandable than: setenv a foo setenv b bar setenv c baz do this; do that How do we want to support secure boot into Debian, Fedora, and Suse, and does distro_bootcmd have a way to do this, or can we come up with some improvement that doesn’t depend on trying to do all the work in CPP macros and U-boot runtime scripts? I think the general answer about "secure boot" is that distros want "UEFI secure boot". And I want to make sure that's done in such a way that things like user-owned secure boot aren't any more difficult than vendor secured boot. It seems like making use of existing secure boot mechanisms has set aside as, well, I don't want to throw snark around myself, so I'll refrain from speculating. -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 4/5] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
Hi Sjoerd, On Mon, Jun 3, 2019 at 4:02 PM Sjoerd Simons wrote: > > From: Frieder Schrempf > > Add support for loading u-boot FIT images over the USB SPD protocol in > the SPL > > [Small fixes to build] Applied this patch against U-Boot master and it still does not build for me when using mx6sabresd_defconfig: cmd/usb_gadget_sdp.c: In function ‘do_sdp’: cmd/usb_gadget_sdp.c:35:2: error: too few arguments to function ‘sdp_handle’ sdp_handle(controller_index); ^~ In file included from cmd/usb_gadget_sdp.c:11:0: include/sdp.h:15:5: note: declared here int sdp_handle(int controller_index, struct spl_image_info *spl_image); ^~ scripts/Makefile.build:278: recipe for target 'cmd/usb_gadget_sdp.o' failed make[1]: *** [cmd/usb_gadget_sdp.o] Error ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/5] mx6sabreauto: Remove CONFIG_SPL_DM to decrease the SPL size
The i.mx6 SPL binary cannot be bigger then 68K, while with the current defconfig for sabreauto it's only about 56K as soon as USB support gets added the size will overflows. Signed-off-by: Sjoerd Simons --- configs/mx6sabreauto_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index d0f302e9d0..bf163a2a6e 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -55,7 +55,6 @@ CONFIG_MULTI_DTB_FIT=y CONFIG_SPL_MULTI_DTB_FIT=y CONFIG_ENV_IS_IN_MMC=y CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG=y -CONFIG_SPL_DM=y CONFIG_DFU_MMC=y CONFIG_DFU_SF=y CONFIG_DM_GPIO=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/5] mx6sabreauto: Enable SPL SDP support
To allow loading u-boot over USB enable SPD support in the SPL. Signed-off-by: Sjoerd Simons --- configs/mx6sabreauto_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index 91ea1ca9e4..6903048d85 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -26,6 +26,9 @@ CONFIG_SPL_SEPARATE_BSS=y CONFIG_SPL_FIT_IMAGE_TINY=y CONFIG_SPL_FS_EXT4=y CONFIG_SPL_I2C_SUPPORT=y +CONFIG_SPL_USB_HOST_SUPPORT=y +CONFIG_SPL_USB_GADGET=y +CONFIG_SPL_USB_SDP_SUPPORT=y CONFIG_SPL_WATCHDOG_SUPPORT=y CONFIG_HUSH_PARSER=y CONFIG_CMD_BOOTZ=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/5] mx6sabreauto: set SYS_MALLOC_F for video
Sabre Auto boards currently hang with: ``` U-Boot 2019.07-rc3-00057-gc41940c406 (Jun 03 2019 - 14:42:41 +0200) CPU: Freescale i.MX6QP rev1.0 996 MHz (running at 792 MHz) CPU: Automotive temperature grade (-40C to 125C)Reset cause: WDOG Model: Freescale i.MX6 Quad Plus SABRE Automotive Board Board: MX6Q-Sabreauto revA I2C: ready DRAM: 2 GiB Video device 'ipu@240' cannot allocate frame buffer memory -ensure the device is set up before relocation Error binding driver 'ipuv3_video': -28 Video device 'ipu@280' cannot allocate frame buffer memory -ensure the device is set up before relocation Error binding driver 'ipuv3_video': -28 Some drivers failed to bind Error binding driver 'generic_simple_bus': -28 Some drivers failed to bind initcall sequence 8ffe00b8 failed at call 1780e93b (err=-28) ``` Set SYS_MALLOC_F_LEN to reserve_video to work. This is similar to the change Peng Fan did for mx6sabresd (9002e735e717) Signed-off-by: Sjoerd Simons --- configs/mx6sabreauto_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index 6903048d85..558b1cd996 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x1780 CONFIG_SPL_GPIO_SUPPORT=y CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y +CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_TARGET_MX6SABREAUTO=y CONFIG_SPL_MMC_SUPPORT=y CONFIG_SPL_SERIAL_SUPPORT=y @@ -11,7 +12,6 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_SPL=y CONFIG_SPL_LIBDISK_SUPPORT=y CONFIG_NXP_BOARD_REVISION=y -# CONFIG_SYS_MALLOC_F is not set CONFIG_FIT=y CONFIG_SPL_FIT_PRINT=y CONFIG_SPL_LOAD_FIT=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/5] usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP
From: Frieder Schrempf
Add support for loading u-boot FIT images over the USB SPD protocol in
the SPL
[Small fixes to build]
Signed-off-by: Sjoerd Simons
---
common/spl/spl_sdp.c | 11 --
drivers/usb/gadget/f_sdp.c | 41 --
include/sdp.h | 4 +++-
3 files changed, 47 insertions(+), 9 deletions(-)
diff --git a/common/spl/spl_sdp.c b/common/spl/spl_sdp.c
index 807256e908..dc57171966 100644
--- a/common/spl/spl_sdp.c
+++ b/common/spl/spl_sdp.c
@@ -26,9 +26,16 @@ static int spl_sdp_load_image(struct spl_image_info
*spl_image,
}
/* This command typically does not return but jumps to an image */
- sdp_handle(controller_index);
+ sdp_handle(controller_index, spl_image);
pr_err("SDP ended\n");
+ /*
+* This command either loads a legacy image, jumps and never returns,
+* or it loads a FIT image and returns it to be handled by the SPL
+* code.
+*/
+ ret = sdp_handle(controller_index, spl_image);
+ debug("SDP ended\n");
- return -EINVAL;
+ return ret;
}
SPL_LOAD_IMAGE_METHOD("USB SDP", 0, BOOT_DEVICE_BOARD, spl_sdp_load_image);
diff --git a/drivers/usb/gadget/f_sdp.c b/drivers/usb/gadget/f_sdp.c
index ae97ab2b49..2a23160d91 100644
--- a/drivers/usb/gadget/f_sdp.c
+++ b/drivers/usb/gadget/f_sdp.c
@@ -638,7 +638,18 @@ static u32 sdp_jump_imxheader(void *address)
return 0;
}
-static void sdp_handle_in_ep(void)
+#ifdef CONFIG_SPL_LOAD_FIT
+static ulong sdp_fit_read(struct spl_load_info *load, ulong sector,
+ ulong count, void *buf)
+{
+ debug("%s: sector %lx, count %lx, buf %lx\n",
+ __func__, sector, count, (ulong)buf);
+ memcpy(buf, (void *)(load->dev + sector), count);
+ return count;
+}
+#endif
+
+static void sdp_handle_in_ep(struct spl_image_info *spl_image)
{
u8 *data = sdp_func->in_req->buf;
u32 status;
@@ -689,11 +700,26 @@ static void sdp_handle_in_ep(void)
/* If imx header fails, try some U-Boot specific headers */
if (status) {
+ image_header_t *header =
+ sdp_ptr(sdp_func->jmp_address);
#ifdef CONFIG_SPL_BUILD
+#ifdef CONFIG_SPL_LOAD_FIT
+ if (image_get_magic(header) == FDT_MAGIC) {
+ struct spl_load_info load;
+
+ debug("Found FIT\n");
+ load.dev = header;
+ load.bl_len = 1;
+ load.read = sdp_fit_read;
+ spl_load_simple_fit(spl_image, , 0,
+ header);
+
+ return;
+ }
+#endif
/* In SPL, allow jumps to U-Boot images */
struct spl_image_info spl_image = {};
- spl_parse_image_header(_image,
- (struct image_header *)sdp_func->jmp_address);
+ spl_parse_image_header(_image, header);
jump_to_image_no_args(_image);
#else
/* In U-Boot, allow jumps to scripts */
@@ -715,19 +741,22 @@ static void sdp_handle_in_ep(void)
};
}
-void sdp_handle(int controller_index)
+int sdp_handle(int controller_index, struct spl_image_info *spl_image)
{
printf("SDP: handle requests...\n");
while (1) {
if (ctrlc()) {
puts("\rCTRL+C - Operation aborted.\n");
- return;
+ return -EINVAL;
}
+ if (spl_image->flags & SPL_FIT_FOUND)
+ return 0;
+
WATCHDOG_RESET();
usb_gadget_handle_interrupts(controller_index);
- sdp_handle_in_ep();
+ sdp_handle_in_ep(spl_image);
}
}
diff --git a/include/sdp.h b/include/sdp.h
index f6252d027f..f30e2bca19 100644
--- a/include/sdp.h
+++ b/include/sdp.h
@@ -9,7 +9,9 @@
#ifndef __SDP_H_
#define __SDP_H_
+#include
+
int sdp_init(int controller_index);
-void sdp_handle(int controller_index);
+int sdp_handle(int controller_index, struct spl_image_info *spl_image);
#endif /* __SDP_H_ */
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/5] mx6sabreauto: Select pinctrl driver
With the conversion to DM we should select the pinctrl driver. Signed-off-by: Sjoerd Simons --- configs/mx6sabreauto_defconfig | 2 ++ 1 file changed, 2 insertions(+) diff --git a/configs/mx6sabreauto_defconfig b/configs/mx6sabreauto_defconfig index bf163a2a6e..91ea1ca9e4 100644 --- a/configs/mx6sabreauto_defconfig +++ b/configs/mx6sabreauto_defconfig @@ -69,6 +69,8 @@ CONFIG_SF_DEFAULT_SPEED=2000 CONFIG_SPI_FLASH_STMICRO=y CONFIG_PHYLIB=y CONFIG_MII=y +CONFIG_PINCTRL=y +CONFIG_PINCTRL_IMX6=y CONFIG_DM_REGULATOR=y CONFIG_SPI=y CONFIG_DM_SPI=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 0/5] Enable usage of SDP for i.MX6 Sabre Auto Boards
Being able to upload u-boot over USB is rather useful, so ideally this functionality should be enabled by the default config for these boards. Currently however no USB support is built into the SPL nor is SDP enabled for i.MX6 Sabre Auto boards. The first two patches in this series adjust the defconfig in a similar way as Fabio has done in a recent patchset for Sabre SD. The first one drops SPL DM support as there is no way to fit that *and* USB support in at the moment, the second one adds missing pinctrl configuration for the main u-boot binary. The third patch enabled USB & SPL SDP support. Patch four adds support for loading FIT images over SDP as that is what is in use for the Sabre auto's main u-boot image. This is simply the patch Frieder Schrempf submitted to the mainlinglist earlier, but made to build on current git master. (Frieder could you be so kind to add your SoB?). The final patch fixes the u-boot image failing to start due to DM_VIDEO. Patchset tested by using uuu with the following configuration: ``` uuu_version 1.2 SDP: boot -f SPL SDPU: write -f u-boot-dtb.img -addr 0x1000 SDPU: jump -addr 0x1000 SPDU: done ``` I suspect these patches are to late for 2019.07, especially since FIT support in SDP would be a new feature? If so I'm happy to split this set out of patches that should definatly land for 2019.07 (Making sabre auto work) and submit the others for 2019.10 Frieder Schrempf (1): usb: gadget: f_sdp: Allow SPL to load and boot FIT via SDP Sjoerd Simons (4): mx6sabreauto: Remove CONFIG_SPL_DM to decrease the SPL size mx6sabreauto: Select pinctrl driver mx6sabreauto: Enable SPL SDP support mx6sabreauto: set SYS_MALLOC_F for video common/spl/spl_sdp.c | 11 +++-- configs/mx6sabreauto_defconfig | 8 +-- drivers/usb/gadget/f_sdp.c | 41 +- include/sdp.h | 4 +++- 4 files changed, 53 insertions(+), 11 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v7] ARM: am335x: Add phyCORE AM335x R2 support
On 6/3/19 3:31 PM, Parthiban Nallathambi wrote:
> From: Niel Fourie
>
> Support for Phytech phyCORE AM335x R2 SOM (PCL060) on the Phytec
> phyBOARD-Wega AM335x.
>
> CPU : AM335X-GP rev 2.1
> Model: Phytec AM335x phyBOARD-WEGA
> DRAM: 256 MiB
> NAND: 256 MiB
> MMC: OMAP SD/MMC: 0
> eth0: ethernet@4a10
>
> Working:
> - Eth0
> - i2C
> - MMC/SD
> - NAND
> - UART
> - USB (host)
>
> Device trees were taken from Linux mainline:
> commit 37624b58542f ("Linux 5.1-rc7")
>
> Signed-off-by: Niel Fourie
> Signed-off-by: Parthiban Nallathambi
> Reviewed-by: Heiko Schocher
> Reviewed-by: Tom Rini
> Tested-by: Marek Vasut
[...]
> +static void scale_vcores_generic(int freq)
> +{
> + int sil_rev, mpu_vdd;
> +
> + /*
> + * We use a TPS65910 PMIC. For all MPU frequencies we support we use a
> + * CORE voltage of 1.10V. For MPU voltage we need to switch based on
> + * the frequency we are running at.
> + */
> + if (power_tps65910_init(0))
> + return;
Did you verify that this does not silently fail ?
> + /*
> + * Depending on MPU clock and PG we will need a different
> + * VDD to drive at that speed.
> + */
> + sil_rev = readl(>deviceid) >> 28;
> + mpu_vdd = am335x_get_tps65910_mpu_vdd(sil_rev, freq);
> +
> + /* Tell the TPS65910 to use i2c */
> + tps65910_set_i2c_control();
> +
> + /* First update MPU voltage. */
> + if (tps65910_voltage_update(MPU, mpu_vdd))
> + return;
And the other ones here too ? Because if they do, the CPU will suffer
undervolt and will be unstable, at least the models faster than 600 MHz.
> + /* Second, update the CORE voltage. */
> + if (tps65910_voltage_update(CORE, TPS65910_OP_REG_SEL_1_1_0))
> + return;
> +}
[...]
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
On Mon, Jun 03, 2019 at 09:44:28AM -0500, Troy Benjegerdes wrote: > > > > On Jun 3, 2019, at 5:49 AM, Andreas Schwab wrote: > > > > On Mai 29 2019, Karsten Merker wrote: > > > >> Mainline U-Boot already uses the distro bootcmd environment for > >> the qemu "virt" machine and it works well. > > > > The distro_bootcmd doesn't work for the sifive platform yet because it > > doesn't set the correct MAC address for booting. > > > > Andreas. > > > > Before we go an use distro_bootcmd and drag in a bunch of legacy stuff > we really should not be using, can we make some kind of effort to decide > what the design goals and boot flow should look like instead using the > default legacy behavior of a bunch of hard to read and maintain CPP > macros? I feel like you're calling "what everyone agreed on and uses today" legacy just because it already exists. It is a bit complex because devices are so complex, rather than it having to support one-off situations or similar things people usually call "legacy". > The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’. > > What good does it do linux distros on RiscV to keep using the old boot > script format, rather than just load a text file and use ‘env import’? Is > there > some benefit to this? Do we gain something from the .scr format, like > maybe cryptographic signature support? Writing things out in script format ends up being more natural (and easier to understand) than writing things out in environment format. This is why while I wish the "uEnv.txt" hook had become more popular and widely used, at this point I also understand why it wasn't. Doing a=foo b=bar c=baz magic_name=do this;do that Was not easier nor more understandable than: setenv a foo setenv b bar setenv c baz do this; do that > How do we want to support secure boot into Debian, Fedora, and Suse, > and does distro_bootcmd have a way to do this, or can we come up with > some improvement that doesn’t depend on trying to do all the work in > CPP macros and U-boot runtime scripts? I think the general answer about "secure boot" is that distros want "UEFI secure boot". And I want to make sure that's done in such a way that things like user-owned secure boot aren't any more difficult than vendor secured boot. It seems like making use of existing secure boot mechanisms has set aside as, well, I don't want to throw snark around myself, so I'll refrain from speculating. -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/2 v3] test: dm: add MDIO test
A very simple test for DM_MDIO, mimicks a register write/read through the
sandbox bus to a dummy PHY.
Signed-off-by: Alex Marginean
---
Changes in v2:
- new patch, v1 didn't have a test included
Changes in v3:
- DM_MDIO and PHYLIB are now implied in arc/Kconfig
- added basic test for mdio reset op
- simplified compatible, static probe function
arch/Kconfig | 2 +
arch/sandbox/dts/test.dts | 4 ++
drivers/net/Kconfig| 10 +
drivers/net/Makefile | 1 +
drivers/net/mdio_sandbox.c | 92 ++
test/dm/Makefile | 1 +
test/dm/mdio.c | 53 ++
7 files changed, 163 insertions(+)
create mode 100644 drivers/net/mdio_sandbox.c
create mode 100644 test/dm/mdio.c
diff --git a/arch/Kconfig b/arch/Kconfig
index e574b0d441..1e62a7615d 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -120,6 +120,8 @@ config SANDBOX
imply VIRTIO_NET
imply DM_SOUND
imply PCH
+ imply PHYLIB
+ imply DM_MDIO
config SH
bool "SuperH architecture"
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8b2d6451c6..46d8a56d0f 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -799,6 +799,10 @@
dmas = < 0>, < 1>, < 2>;
dma-names = "m2m", "tx0", "rx0";
};
+
+ mdio-test {
+ compatible = "sandbox,mdio";
+ };
};
#include "sandbox_pmic.dtsi"
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6fba5a84dd..635f8d72c2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -24,6 +24,16 @@ config DM_MDIO
This is currently implemented in net/mdio-uclass.c
Look in include/miiphy.h for details.
+config MDIO_SANDBOX
+ depends on DM_MDIO && SANDBOX
+ default y
+ bool "Sandbox: Mocked MDIO driver"
+ help
+ This driver implements dummy read/write/reset MDIO functions mimicking
+ a bus with a single PHY.
+
+ This driver is used in for testing in test/dm/mdio.c
+
menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 8d02a37896..40038427db 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -77,3 +77,4 @@ obj-y += ti/
obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
obj-y += mscc_eswitch/
obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
+obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
diff --git a/drivers/net/mdio_sandbox.c b/drivers/net/mdio_sandbox.c
new file mode 100644
index 00..07515e078c
--- /dev/null
+++ b/drivers/net/mdio_sandbox.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019
+ * Alex Marginean, NXP
+ */
+
+#include
+#include
+#include
+
+#define SANDBOX_PHY_ADDR 5
+#define SANDBOX_PHY_REG0
+
+struct mdio_sandbox_priv {
+ int enabled;
+ u16 reg;
+};
+
+static int mdio_sandbox_read(struct udevice *dev, int addr, int devad, int reg)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ if (!priv->enabled)
+ return -ENODEV;
+
+ if (addr != SANDBOX_PHY_ADDR)
+ return -ENODEV;
+ if (devad != MDIO_DEVAD_NONE)
+ return -ENODEV;
+ if (reg != SANDBOX_PHY_REG)
+ return -ENODEV;
+
+ return priv->reg;
+}
+
+static int mdio_sandbox_write(struct udevice *dev, int addr, int devad, int
reg,
+ u16 val)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ if (!priv->enabled)
+ return -ENODEV;
+
+ if (addr != SANDBOX_PHY_ADDR)
+ return -ENODEV;
+ if (devad != MDIO_DEVAD_NONE)
+ return -ENODEV;
+ if (reg != SANDBOX_PHY_REG)
+ return -ENODEV;
+
+ priv->reg = val;
+
+ return 0;
+}
+
+static int mdio_sandbox_reset(struct udevice *dev)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ priv->reg = 0;
+
+ return 0;
+}
+
+static const struct mdio_ops mdio_sandbox_ops = {
+ .read = mdio_sandbox_read,
+ .write = mdio_sandbox_write,
+ .reset = mdio_sandbox_reset,
+};
+
+static int mdio_sandbox_probe(struct udevice *dev)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ priv->enabled = 1;
+
+ return 0;
+}
+
+static const struct udevice_id mdio_sandbox_ids[] = {
+ { .compatible = "sandbox,mdio" },
+ { }
+};
+
+U_BOOT_DRIVER(mdio_sandbox) = {
+ .name = "mdio_sandbox",
+ .id = UCLASS_MDIO,
+ .of_match = mdio_sandbox_ids,
+ .probe = mdio_sandbox_probe,
+ .ops= _sandbox_ops,
+ .priv_auto_alloc_size = sizeof(struct mdio_sandbox_priv),
+};
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 49857c5092..3f042e3ab4 100644
---
[U-Boot] [PATCH 1/2 v3] net: introduce MDIO DM class for MDIO devices
Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as
stand-alone devices. Useful in particular for systems that support
DM_ETH and have a stand-alone MDIO hardware block shared by multiple
Ethernet interfaces.
Signed-off-by: Alex Marginean
---
Changes in v2:
- fixed several comments using wrong API names
- dropped dm_ from names of internal functions that don't use udevice *
- fixed UCLASS driver name
- added missing mdio_unregister in dm_mdio_pre_remove
- added a comment on why spaces in names aren't ok
- added a comment on how static mdio_read/_write/_reset functions
are used
Changes in v3:
- none
cmd/mdio.c | 5 ++
drivers/net/Kconfig| 13 +
include/dm/uclass-id.h | 1 +
include/miiphy.h | 49 ++
net/Makefile | 1 +
net/mdio-uclass.c | 115 +
6 files changed, 184 insertions(+)
create mode 100644 net/mdio-uclass.c
diff --git a/cmd/mdio.c b/cmd/mdio.c
index 5e219f699d..a6fa9266d0 100644
--- a/cmd/mdio.c
+++ b/cmd/mdio.c
@@ -203,6 +203,11 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (argc < 2)
return CMD_RET_USAGE;
+#ifdef CONFIG_DM_MDIO
+ /* probe DM MII device before any operation so they are all accesible */
+ dm_mdio_probe_devices();
+#endif
+
/*
* We use the last specified parameters, unless new ones are
* entered.
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e6a4fdf30e..6fba5a84dd 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -11,6 +11,19 @@ config DM_ETH
This is currently implemented in net/eth-uclass.c
Look in include/net.h for details.
+config DM_MDIO
+ bool "Enable Driver Model for MDIO devices"
+ depends on DM_ETH && PHYLIB
+ help
+ Enable driver model for MDIO devices
+
+ Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as
+ stand-alone devices. Useful in particular for systems that support
+ DM_ETH and have a stand-alone MDIO hardware block shared by multiple
+ Ethernet interfaces.
+ This is currently implemented in net/mdio-uclass.c
+ Look in include/miiphy.h for details.
+
menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 09e0ad5391..90667e62cf 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -58,6 +58,7 @@ enum uclass_id {
UCLASS_LPC, /* x86 'low pin count' interface */
UCLASS_MAILBOX, /* Mailbox controller */
UCLASS_MASS_STORAGE,/* Mass storage device */
+ UCLASS_MDIO,/* MDIO bus */
UCLASS_MISC,/* Miscellaneous device */
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
diff --git a/include/miiphy.h b/include/miiphy.h
index f11763affd..e6dd441983 100644
--- a/include/miiphy.h
+++ b/include/miiphy.h
@@ -118,4 +118,53 @@ int bb_miiphy_write(struct mii_dev *miidev, int addr, int
devad, int reg,
#define ESTATUS_1000XF 0x8000
#define ESTATUS_1000XH 0x4000
+#ifdef CONFIG_DM_MDIO
+
+/**
+ * struct mdio_perdev_priv - Per-device class data for MDIO DM
+ *
+ * @mii_bus: Supporting MII legacy bus
+ */
+struct mdio_perdev_priv {
+ struct mii_dev *mii_bus;
+};
+
+/**
+ * struct mdio_ops - MDIO bus operations
+ *
+ * @read: Read from a PHY register
+ * @write: Write to a PHY register
+ * @reset: Reset the MDIO bus, NULL if not supported
+ */
+struct mdio_ops {
+ int (*read)(struct udevice *mdio_dev, int addr, int devad, int reg);
+ int (*write)(struct udevice *mdio_dev, int addr, int devad, int reg,
+u16 val);
+ int (*reset)(struct udevice *mdio_dev);
+};
+
+#define mdio_get_ops(dev) ((struct mdio_ops *)(dev)->driver->ops)
+
+/**
+ * dm_mdio_probe_devices - Call probe on all MII devices, currently used for
+ * MDIO console commands.
+ */
+void dm_mdio_probe_devices(void);
+
+/**
+ * dm_mdio_phy_connect - Wrapper over phy_connect for DM MDIO
+ *
+ * @dev: mdio dev
+ * @addr: PHY address on MDIO bus
+ * @ethdev: ethernet device to connect to the PHY
+ * @interface: MAC-PHY protocol
+ *
+ * @return pointer to phy_device, or 0 on error
+ */
+struct phy_device *dm_mdio_phy_connect(struct udevice *dev, int addr,
+ struct udevice *ethdev,
+ phy_interface_t interface);
+
+#endif
+
#endif
diff --git a/net/Makefile b/net/Makefile
index ce36362168..6251ff3991 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_NET) += eth-uclass.o
else
obj-$(CONFIG_NET) += eth_legacy.o
endif
+obj-$(CONFIG_DM_MDIO) += mdio-uclass.o
obj-$(CONFIG_NET) +=
Re: [U-Boot] [PATCH] net: davinci_emac: convert to using the driver model
pon., 3 cze 2019 o 15:03 Adam Ford napisał(a):
>
> On Mon, Jun 3, 2019 at 3:12 AM Bartosz Golaszewski wrote:
> >
> > sob., 1 cze 2019 o 05:24 Adam Ford napisał(a):
> > >
> > > On Fri, May 31, 2019 at 8:32 AM Bartosz Golaszewski wrote:
> > > >
> > > > From: Bartosz Golaszewski
> > > >
> > > > Now that we removed all legacy boards selecting TI_EMAC we can
> > > > completely convert the driver code to using the driver model.
> > > > This patch also updates all remaining users of davinci_emac.
> > > >
> > >
> > > I took a break from this to come back, and I'm going to give some
> > > feedback about how the driver was written. I still do not know why I
> > > cannot get an IP address with this patch on the AM3517-evm.
> > >
> >
> > Hi Adam,
> >
> > thanks for all the testing. Unfortunately I can only test with
> > da850-evm and da850-lcdk.
> >
> > I was wondering if it is possible that the problem is caused by
> > cpu_eth_init() from ./arch/arm/mach-omap2/omap3/emac. not being called
> > with CONFIG_DM_ETH? The comments say that it brings the module out of
> > reset, so maybe this is what causes the problem you're seeing?
>
> I looked into that nearly right away, but there is a chunk of code in
> board/logicpd/am3517evm/am3517evm.c which has a function called
> misc_init_r() which does the same thing. Looking through the debug
> data, it appears as if the drive is communicating for a bit, but at
> some point it dies. I'm not going to be able to look at it for a few
> days. Is there any way you can submit a V2 to use #ifdef's to allow
> users to use the same driver with and without DM_ETH? That would give
> the da850/L138 boards the DM_ETH, and give me some time to
> troubleshoot the am3517-evm. I know Sekhar works for TI and the AM3517
> was the official development kit for TI back in the day. If TI has
> some ideas, I'm open to trying them as well when I can get back to it.
>
> adam
Hi Adam,
I'm trying to find out if I can get my hands on one of these boards somehow.
My priority for this week is the nand driver conversion. I'll also be
off next week and the one after. I think that since we already removed
a bunch of boards to make it possible to avoid the ifdef hell, it's
better to wait a bit more than to merge something that we'll remove
soon anyway.
If Sekhar agrees, we can push back merging of this patch until it's fixed.
There's also a big backlog of my other davinci patches on the list
anyway, maybe they'll get picked up before we get back to it.
Bart
>
> >
> > > > Signed-off-by: Bartosz Golaszewski
> > > > ---
> > > > arch/arm/mach-davinci/cpu.c| 13 -
> > > > arch/arm/mach-omap2/omap3/emac.c | 3 +-
> > > > board/davinci/da8xxevm/da850evm.c | 6 --
> > > > board/davinci/da8xxevm/omapl138_lcdk.c | 14 -
> > > > board/logicpd/am3517evm/am3517evm.c| 1 -
> > > > board/ti/ti816x/evm.c | 3 +-
> > > > configs/am3517_evm_defconfig | 1 +
> > > > configs/da850evm_defconfig | 1 +
> > > > configs/da850evm_direct_nor_defconfig | 1 +
> > > > configs/da850evm_nand_defconfig| 1 +
> > > > configs/omapl138_lcdk_defconfig| 1 +
> > > > configs/ti816x_evm_defconfig | 1 +
> > > > drivers/net/ti/davinci_emac.c | 77 ++
> > > > include/netdev.h | 1 -
> > > > 14 files changed, 51 insertions(+), 73 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
> > > > index f97ad3fc74..9fd6564d04 100644
> > > > --- a/arch/arm/mach-davinci/cpu.c
> > > > +++ b/arch/arm/mach-davinci/cpu.c
> > > > @@ -5,7 +5,6 @@
> > > > */
> > > >
> > > > #include
> > > > -#include
> > > > #include
> > > > #include
> > > >
> > > > @@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
> > > > gd->bd->bi_dsp_freq = 0;
> > > > return 0;
> > > > }
> > > > -
> > > > -/*
> > > > - * Initializes on-chip ethernet controllers.
> > > > - * to override, implement board_eth_init()
> > > > - */
> > > > -int cpu_eth_init(bd_t *bis)
> > > > -{
> > > > -#if defined(CONFIG_DRIVER_TI_EMAC)
> > > > - davinci_emac_initialize();
> > > > -#endif
> > > > - return 0;
> > > > -}
> > > > diff --git a/arch/arm/mach-omap2/omap3/emac.c
> > > > b/arch/arm/mach-omap2/omap3/emac.c
> > > > index c79e870183..fb0c9188f5 100644
> > > > --- a/arch/arm/mach-omap2/omap3/emac.c
> > > > +++ b/arch/arm/mach-omap2/omap3/emac.c
> > > > @@ -7,7 +7,6 @@
> > > > */
> > > >
> > > > #include
> > > > -#include
> > > > #include
> > > > #include
> > > >
> > > > @@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis)
> > > > reset &= ~CPGMACSS_SW_RST;
> > > > writel(reset, _scm_general_regs->ip_sw_reset);
> > > >
> > > > - return davinci_emac_initialize();
> > > > + return 0;
> > > > }
> > > > diff --git a/board/davinci/da8xxevm/da850evm.c
> > > > b/board/davinci/da8xxevm/da850evm.c
> > > > index
Re: [U-Boot] Hart lottery and CONFIG_XIP
Hi Troy, On Mon, Jun 3, 2019 at 10:53 PM Troy Benjegerdes wrote: > > > > > On Jun 3, 2019, at 9:19 AM, Bin Meng wrote: > > > > +Anup > > > > Hi Troy, > > > > On Mon, Jun 3, 2019 at 9:19 PM Troy Benjegerdes > > wrote: > >> > >> > >> > >>> On Jun 2, 2019, at 9:22 PM, Rick Chen wrote: > >>> > >>> Hi Troy > >>> > > From: Troy Benjegerdes [mailto:troy.benjeger...@sifive.com] > > Sent: Saturday, June 01, 2019 12:24 AM > > To: Auer, Lukas > > Cc: Rick Jian-Zhi Chen(陳建志); bmeng...@gmail.com; pal...@sifive.com > > Subject: Re: Hart lottery and CONFIG_XIP > > > > > > > >> On May 31, 2019, at 9:13 AM, Auer, Lukas > >> > > wrote: > >> > >> Hi Troy, > >> > >> On Fri, 2019-05-31 at 08:18 -0500, Troy Benjegerdes wrote: > >>> Wouldn't the following line in head.S fail when running from flash > >>> (although maybe not in a way that prevents booting) > >>> > >>> /* save the boot hart id to global_data */ > >>> SREGtp, GD_BOOT_HART(gp) > >>> > >>> Shouldn’t this be protected by CONFIG_XIP? > >> > >> The boot hart ID is stored in global data, which is allocated from the > >> stack (in board_init_f_alloc_reserve() ). It is therefore writable and > >> won't cause any issues when running from flash. > > > > Sorry about the confusion, I was reading it wrong earlier. > > > > I’m hoping to have a couple of patches ready later today to change the > > CONFIG_XIP patch to ‘CONFIG_HART_LOTTERY’ since it is also useful to > > remove the potential indeterminism of which hart wins the lottery when > > doing > > board bringup and debugging. > >>> > >>> I am OK with that. > >>> Actually my preliminary patch about > >>> [PATCH 0/4] AE350 support SMP boot from flash > >>> did as your wish. > >>> > >>> You can refer it : > >>> [PATCH 1/4] riscv: hart_lottery and available harts feature can be > >>> seletable > >>> https://www.mail-archive.com/u-boot@lists.denx.de/msg323419.html > >>> > >>> Rick > >> > >> To follow up on > >> https://www.mail-archive.com/u-boot@lists.denx.de/msg323526.html > >> > >> It is confusing and misleading to mix CONFIG_XIP and CONFIG_HART_LOTTERY. > >> > > > > I am not sure what caused the confusion. CONFIG_XIP was added to > > support U-Boot executing from ROM directly. > > > > The confusion is use cases where you don’t necessarily need CONFIG_XIP, > but you do want deterministic SMP booting, and the code is a lot more > understandable > with ‘#ifdef CONFIG_HART_LOTTERY’, and a Kconfig option and/or documentation > warning that says CONFIG_HART_LOTTERY depends on !CONFIG_XIP > OK, as I pointed out, the deterministic SMP booting was originally posted, but later was changed to the lottery mechanism per Anup's review comments. I am personally fine with both. > >> From an system testing and validation point of view, I would find it much > >> better > >> (especially at very early boot stages, where U-boot might be the first > >> non-ROM code > >> running) to have a deterministic process to determine what core runs > >> U-boot. This > > > > I remember when SMP patches were submitted by Lukas for the first time > > it was deterministic using some macros like CONFIG_BOOT_HART, however > > per Anup's request, the hart lottery feature, similar to what Linux > > has, was added. > > I’d like to have CONFIG_BOOT_HART available as a config option as well, > particularly > for system validation testing. Also along those lines, if we are going to use > a lottery > to determine what CPU boots the system, how do we know afterwards which one > it was? > Yes, there is a way to know. Type 'dm tree' from U-Boot shell, then look at which cpu node has a child node of "riscv_timer". Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Hart lottery and CONFIG_XIP
> On Jun 3, 2019, at 9:19 AM, Bin Meng wrote: > > +Anup > > Hi Troy, > > On Mon, Jun 3, 2019 at 9:19 PM Troy Benjegerdes > wrote: >> >> >> >>> On Jun 2, 2019, at 9:22 PM, Rick Chen wrote: >>> >>> Hi Troy >>> > From: Troy Benjegerdes [mailto:troy.benjeger...@sifive.com] > Sent: Saturday, June 01, 2019 12:24 AM > To: Auer, Lukas > Cc: Rick Jian-Zhi Chen(陳建志); bmeng...@gmail.com; pal...@sifive.com > Subject: Re: Hart lottery and CONFIG_XIP > > > >> On May 31, 2019, at 9:13 AM, Auer, Lukas > wrote: >> >> Hi Troy, >> >> On Fri, 2019-05-31 at 08:18 -0500, Troy Benjegerdes wrote: >>> Wouldn't the following line in head.S fail when running from flash >>> (although maybe not in a way that prevents booting) >>> >>> /* save the boot hart id to global_data */ >>> SREGtp, GD_BOOT_HART(gp) >>> >>> Shouldn’t this be protected by CONFIG_XIP? >> >> The boot hart ID is stored in global data, which is allocated from the >> stack (in board_init_f_alloc_reserve() ). It is therefore writable and >> won't cause any issues when running from flash. > > Sorry about the confusion, I was reading it wrong earlier. > > I’m hoping to have a couple of patches ready later today to change the > CONFIG_XIP patch to ‘CONFIG_HART_LOTTERY’ since it is also useful to > remove the potential indeterminism of which hart wins the lottery when > doing > board bringup and debugging. >>> >>> I am OK with that. >>> Actually my preliminary patch about >>> [PATCH 0/4] AE350 support SMP boot from flash >>> did as your wish. >>> >>> You can refer it : >>> [PATCH 1/4] riscv: hart_lottery and available harts feature can be seletable >>> https://www.mail-archive.com/u-boot@lists.denx.de/msg323419.html >>> >>> Rick >> >> To follow up on >> https://www.mail-archive.com/u-boot@lists.denx.de/msg323526.html >> >> It is confusing and misleading to mix CONFIG_XIP and CONFIG_HART_LOTTERY. >> > > I am not sure what caused the confusion. CONFIG_XIP was added to > support U-Boot executing from ROM directly. > The confusion is use cases where you don’t necessarily need CONFIG_XIP, but you do want deterministic SMP booting, and the code is a lot more understandable with ‘#ifdef CONFIG_HART_LOTTERY’, and a Kconfig option and/or documentation warning that says CONFIG_HART_LOTTERY depends on !CONFIG_XIP >> From an system testing and validation point of view, I would find it much >> better >> (especially at very early boot stages, where U-boot might be the first >> non-ROM code >> running) to have a deterministic process to determine what core runs U-boot. >> This > > I remember when SMP patches were submitted by Lukas for the first time > it was deterministic using some macros like CONFIG_BOOT_HART, however > per Anup's request, the hart lottery feature, similar to what Linux > has, was added. I’d like to have CONFIG_BOOT_HART available as a config option as well, particularly for system validation testing. Also along those lines, if we are going to use a lottery to determine what CPU boots the system, how do we know afterwards which one it was? > >> necessarily seems as it will require a CONFIG_BOOT_HART option, as we are not >> in a position to parse a device tree in head.S >> > > Yes, this is understood. So the CONFIG_XIP was added to support such > case, for which the lottery feature relies on a memory location which > isn't writable yet. > > Regards, > Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Distro bootcmd: Re: 5.2-rc1 boot on Unleashed
> On Jun 3, 2019, at 5:49 AM, Andreas Schwab wrote: > > On Mai 29 2019, Karsten Merker wrote: > >> Mainline U-Boot already uses the distro bootcmd environment for >> the qemu "virt" machine and it works well. > > The distro_bootcmd doesn't work for the sifive platform yet because it > doesn't set the correct MAC address for booting. > > Andreas. > Before we go an use distro_bootcmd and drag in a bunch of legacy stuff we really should not be using, can we make some kind of effort to decide what the design goals and boot flow should look like instead using the default legacy behavior of a bunch of hard to read and maintain CPP macros? The first thing I notice is that the default dhcp target is ‘boot.scr.uimg’. What good does it do linux distros on RiscV to keep using the old boot script format, rather than just load a text file and use ‘env import’? Is there some benefit to this? Do we gain something from the .scr format, like maybe cryptographic signature support? How do we want to support secure boot into Debian, Fedora, and Suse, and does distro_bootcmd have a way to do this, or can we come up with some improvement that doesn’t depend on trying to do all the work in CPP macros and U-boot runtime scripts? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Hart lottery and CONFIG_XIP
> On Jun 2, 2019, at 9:22 PM, Rick Chen wrote: > > Hi Troy > >>> From: Troy Benjegerdes [mailto:troy.benjeger...@sifive.com] >>> Sent: Saturday, June 01, 2019 12:24 AM >>> To: Auer, Lukas >>> Cc: Rick Jian-Zhi Chen(陳建志); bmeng...@gmail.com; pal...@sifive.com >>> Subject: Re: Hart lottery and CONFIG_XIP >>> >>> >>> On May 31, 2019, at 9:13 AM, Auer, Lukas >>> wrote: Hi Troy, On Fri, 2019-05-31 at 08:18 -0500, Troy Benjegerdes wrote: > Wouldn't the following line in head.S fail when running from flash > (although maybe not in a way that prevents booting) > > /* save the boot hart id to global_data */ > SREGtp, GD_BOOT_HART(gp) > > Shouldn’t this be protected by CONFIG_XIP? The boot hart ID is stored in global data, which is allocated from the stack (in board_init_f_alloc_reserve() ). It is therefore writable and won't cause any issues when running from flash. >>> >>> Sorry about the confusion, I was reading it wrong earlier. >>> >>> I’m hoping to have a couple of patches ready later today to change the >>> CONFIG_XIP patch to ‘CONFIG_HART_LOTTERY’ since it is also useful to >>> remove the potential indeterminism of which hart wins the lottery when doing >>> board bringup and debugging. > > I am OK with that. > Actually my preliminary patch about > [PATCH 0/4] AE350 support SMP boot from flash > did as your wish. > > You can refer it : > [PATCH 1/4] riscv: hart_lottery and available harts feature can be seletable > https://www.mail-archive.com/u-boot@lists.denx.de/msg323419.html > > Rick To follow up on https://www.mail-archive.com/u-boot@lists.denx.de/msg323526.html It is confusing and misleading to mix CONFIG_XIP and CONFIG_HART_LOTTERY. From an system testing and validation point of view, I would find it much better (especially at very early boot stages, where U-boot might be the first non-ROM code running) to have a deterministic process to determine what core runs U-boot. This necessarily seems as it will require a CONFIG_BOOT_HART option, as we are not in a position to parse a device tree in head.S ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] image: android: allow to wrap uImage into the Android boot image
From: Roman Stratiienko
This allows to use any available compression format with Android boot image
Since not all available compression formats have a magic number we should
explicitly specify type of compression.
For this purpose using uImage format becomes very useful, as this format is
well-known by the community and mkimage tool is already available.
Usage example:
mkimage -A ARM64 -T kernel -C lzma -d Image.lzma out/kernel
At this moment only -C option is handled, but specifying -A and -T options
are recommended for compatibility reasons in the future.
Kernel that compressed with LZ4 can be already used without wrapping into
the uImage, but I recommend wrapping it into the uImage in order to avoid
situations when by some mistake legacy LZ4 is used, that is interpreted as
raw Image and causes CPU to enter Exception Handler without providing any
meaningful explanation to the user.
Signed-off-by: Roman Stratiienko
---
common/image-android.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/common/image-android.c b/common/image-android.c
index 8b0f6b3b8b..6c9568a655 100644
--- a/common/image-android.c
+++ b/common/image-android.c
@@ -52,6 +52,8 @@ int android_image_get_kernel(const struct andr_img_hdr *hdr,
int verify,
ulong *os_data, ulong *os_len)
{
u32 kernel_addr = android_image_get_kernel_addr(hdr);
+ const struct image_header *ihdr = (const struct image_header *)
+ ((uintptr_t)hdr + hdr->page_size);
/*
* Not all Android tools use the id field for signing the image with
@@ -93,11 +95,19 @@ int android_image_get_kernel(const struct andr_img_hdr
*hdr, int verify,
env_set("bootargs", newbootargs);
if (os_data) {
- *os_data = (ulong)hdr;
- *os_data += hdr->page_size;
+ if (image_get_magic(ihdr) == IH_MAGIC) {
+ *os_data = image_get_data(ihdr);
+ } else {
+ *os_data = (ulong)hdr;
+ *os_data += hdr->page_size;
+ }
+ }
+ if (os_len) {
+ if (image_get_magic(ihdr) == IH_MAGIC)
+ *os_len = image_get_data_size(ihdr);
+ else
+ *os_len = hdr->kernel_size;
}
- if (os_len)
- *os_len = hdr->kernel_size;
return 0;
}
@@ -131,7 +141,9 @@ ulong android_image_get_kcomp(const struct andr_img_hdr
*hdr)
{
const void *p = (void *)((uintptr_t)hdr + hdr->page_size);
- if (get_unaligned_le32(p) == LZ4F_MAGIC)
+ if (image_get_magic((image_header_t *)p) == IH_MAGIC)
+ return image_get_comp((image_header_t *)p);
+ else if (get_unaligned_le32(p) == LZ4F_MAGIC)
return IH_COMP_LZ4;
else
return IH_COMP_NONE;
--
2.17.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Hart lottery and CONFIG_XIP
+Anup Hi Troy, On Mon, Jun 3, 2019 at 9:19 PM Troy Benjegerdes wrote: > > > > > On Jun 2, 2019, at 9:22 PM, Rick Chen wrote: > > > > Hi Troy > > > >>> From: Troy Benjegerdes [mailto:troy.benjeger...@sifive.com] > >>> Sent: Saturday, June 01, 2019 12:24 AM > >>> To: Auer, Lukas > >>> Cc: Rick Jian-Zhi Chen(陳建志); bmeng...@gmail.com; pal...@sifive.com > >>> Subject: Re: Hart lottery and CONFIG_XIP > >>> > >>> > >>> > On May 31, 2019, at 9:13 AM, Auer, Lukas > >>> wrote: > > Hi Troy, > > On Fri, 2019-05-31 at 08:18 -0500, Troy Benjegerdes wrote: > > Wouldn't the following line in head.S fail when running from flash > > (although maybe not in a way that prevents booting) > > > > /* save the boot hart id to global_data */ > > SREGtp, GD_BOOT_HART(gp) > > > > Shouldn’t this be protected by CONFIG_XIP? > > The boot hart ID is stored in global data, which is allocated from the > stack (in board_init_f_alloc_reserve() ). It is therefore writable and > won't cause any issues when running from flash. > >>> > >>> Sorry about the confusion, I was reading it wrong earlier. > >>> > >>> I’m hoping to have a couple of patches ready later today to change the > >>> CONFIG_XIP patch to ‘CONFIG_HART_LOTTERY’ since it is also useful to > >>> remove the potential indeterminism of which hart wins the lottery when > >>> doing > >>> board bringup and debugging. > > > > I am OK with that. > > Actually my preliminary patch about > > [PATCH 0/4] AE350 support SMP boot from flash > > did as your wish. > > > > You can refer it : > > [PATCH 1/4] riscv: hart_lottery and available harts feature can be seletable > > https://www.mail-archive.com/u-boot@lists.denx.de/msg323419.html > > > > Rick > > To follow up on > https://www.mail-archive.com/u-boot@lists.denx.de/msg323526.html > > It is confusing and misleading to mix CONFIG_XIP and CONFIG_HART_LOTTERY. > I am not sure what caused the confusion. CONFIG_XIP was added to support U-Boot executing from ROM directly. > From an system testing and validation point of view, I would find it much > better > (especially at very early boot stages, where U-boot might be the first > non-ROM code > running) to have a deterministic process to determine what core runs U-boot. > This I remember when SMP patches were submitted by Lukas for the first time it was deterministic using some macros like CONFIG_BOOT_HART, however per Anup's request, the hart lottery feature, similar to what Linux has, was added. > necessarily seems as it will require a CONFIG_BOOT_HART option, as we are not > in a position to parse a device tree in head.S > Yes, this is understood. So the CONFIG_XIP was added to support such case, for which the lottery feature relies on a memory location which isn't writable yet. Regards, Bin ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH v2 1/5] spl: dm: disable SPI DM flash for non-DM SPL
On Mon, Jun 03, 2019 at 04:18:29AM +, Chuanhua Han wrote: > > > > -Original Message- > > From: Tom Rini > > Sent: 2019年5月31日 3:43 > > To: Chuanhua Han > > Cc: ja...@openedev.com; w...@denx.de; Shengzhou Liu > > ; Ruchika Gupta ; Pan > > Jiafei ; u-boot@lists.denx.de; Jiafei Pan > > ; Yinbo Zhu > > Subject: Re: [EXT] Re: [U-Boot] [PATCH v2 1/5] spl: dm: disable SPI DM > > flash for > > non-DM SPL > > > > On Thu, May 30, 2019 at 10:45:10AM +, Chuanhua Han wrote: > > > > > > > > > > -Original Message- > > > > From: Tom Rini > > > > Sent: 2019年5月24日 22:24 > > > > To: Chuanhua Han > > > > Cc: ja...@openedev.com; w...@denx.de; Shengzhou Liu > > > > ; Ruchika Gupta ; Pan > > > > Jiafei ; u-boot@lists.denx.de; Jiafei Pan > > > > ; Yinbo Zhu > > > > Subject: [EXT] Re: [U-Boot] [PATCH v2 1/5] spl: dm: disable SPI DM > > > > flash for non-DM SPL > > > > > > > > On Fri, May 24, 2019 at 12:40:53PM +0800, Chuanhua Han wrote: > > > > > > > > > This patch solves the problem that spiboot cannot be performed in > > > > > non-DM SPL. > > > > > > > > > > Signed-off-by: Pan Jiafei > > > > > Signed-off-by: Chuanhua Han > > > > > --- > > > > > Changes in v2: > > > > > - No change. > > > > > > > > > > include/config_uncmd_spl.h | 1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > diff --git a/include/config_uncmd_spl.h > > > > > b/include/config_uncmd_spl.h index c2f9735ce7..da94b3d9df 100644 > > > > > --- a/include/config_uncmd_spl.h > > > > > +++ b/include/config_uncmd_spl.h > > > > > @@ -15,6 +15,7 @@ > > > > > #undef CONFIG_DM_GPIO > > > > > #undef CONFIG_DM_I2C > > > > > #undef CONFIG_DM_SPI > > > > > +#undef CONFIG_DM_SPI_FLASH > > > > > #endif > > > > > > > > > > #undef CONFIG_DM_WARN > > > > > > > > Long term, this shows places where we need CONFIG_SPL_DM_xxx and > > > > code should be using CONFIG_IS_ENABLED(DM_xxx). Please update at > > > > least the DM_SPI_FLASH case you're finding to behave like that, thanks! > > > I don't understand you very much. Are you saying to modify the spi-flash > > related code? > > > > Correct. include/config_uncmd_spl.h should be removed as there should, > > long term, be no cases of code in SPL that we can / should exclude not > > guarded by CONFIG_SPL_xxx instead. > Do you mean include/config_uncmd_spl.h will be deleted in the future? > Why did you start adding this file? The file config_uncmd_spl.h predates the CONFIG_IS_ENABLED() macro and whats left in that file should have code in question migrated to use CONFIG_IS_ENABLED(xxx) and as needed new CONFIG_SPL_xxx symbols added, in case some places _do_ need it. I'm not asking you to do this migrated, but I don't want to see more technical debt added here. We can solve the problem you're seeing around CONFIG_DM_SPI_FLASH in another easier to maintain manner. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH v2 1/5] spl: dm: disable SPI DM flash for non-DM SPL
On Fri, May 31, 2019 at 02:49:34AM +, Chuanhua Han wrote: > > > > -Original Message- > > From: Tom Rini > > Sent: 2019年5月31日 3:43 > > To: Chuanhua Han > > Cc: ja...@openedev.com; w...@denx.de; Shengzhou Liu > > ; Ruchika Gupta ; Pan > > Jiafei ; u-boot@lists.denx.de; Jiafei Pan > > ; Yinbo Zhu > > Subject: Re: [EXT] Re: [U-Boot] [PATCH v2 1/5] spl: dm: disable SPI DM > > flash for > > non-DM SPL > > > > On Thu, May 30, 2019 at 10:45:10AM +, Chuanhua Han wrote: > > > > > > > > > > -Original Message- > > > > From: Tom Rini > > > > Sent: 2019年5月24日 22:24 > > > > To: Chuanhua Han > > > > Cc: ja...@openedev.com; w...@denx.de; Shengzhou Liu > > > > ; Ruchika Gupta ; Pan > > > > Jiafei ; u-boot@lists.denx.de; Jiafei Pan > > > > ; Yinbo Zhu > > > > Subject: [EXT] Re: [U-Boot] [PATCH v2 1/5] spl: dm: disable SPI DM > > > > flash for non-DM SPL > > > > > > > > On Fri, May 24, 2019 at 12:40:53PM +0800, Chuanhua Han wrote: > > > > > > > > > This patch solves the problem that spiboot cannot be performed in > > > > > non-DM SPL. > > > > > > > > > > Signed-off-by: Pan Jiafei > > > > > Signed-off-by: Chuanhua Han > > > > > --- > > > > > Changes in v2: > > > > > - No change. > > > > > > > > > > include/config_uncmd_spl.h | 1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > diff --git a/include/config_uncmd_spl.h > > > > > b/include/config_uncmd_spl.h index c2f9735ce7..da94b3d9df 100644 > > > > > --- a/include/config_uncmd_spl.h > > > > > +++ b/include/config_uncmd_spl.h > > > > > @@ -15,6 +15,7 @@ > > > > > #undef CONFIG_DM_GPIO > > > > > #undef CONFIG_DM_I2C > > > > > #undef CONFIG_DM_SPI > > > > > +#undef CONFIG_DM_SPI_FLASH > > > > > #endif > > > > > > > > > > #undef CONFIG_DM_WARN > > > > > > > > Long term, this shows places where we need CONFIG_SPL_DM_xxx and > > > > code should be using CONFIG_IS_ENABLED(DM_xxx). Please update at > > > > least the DM_SPI_FLASH case you're finding to behave like that, thanks! > > > I don't understand you very much. Are you saying to modify the spi-flash > > related code? > > > > Correct. include/config_uncmd_spl.h should be removed as there should, > > long term, be no cases of code in SPL that we can / should exclude not > > guarded by CONFIG_SPL_xxx instead. > Do you mean I should not add "#undef CONFIG_DM_SPI_FLASH" in > include/config_uncmd_spl.h? > What should I do? Is there any code or file for reference? You should fix whatever code is being linked in to SPL that should not be in SPL to use CONFIG_IS_ENABLED(DM_SPI_FLASH) and add a SPL_DM_SPI_FLASH symbol so that platforms which do need it can still enable it. Thanks! -- Tom signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v7] ARM: am335x: Add phyCORE AM335x R2 support
From: Niel Fourie
Support for Phytech phyCORE AM335x R2 SOM (PCL060) on the Phytec
phyBOARD-Wega AM335x.
CPU : AM335X-GP rev 2.1
Model: Phytec AM335x phyBOARD-WEGA
DRAM: 256 MiB
NAND: 256 MiB
MMC: OMAP SD/MMC: 0
eth0: ethernet@4a10
Working:
- Eth0
- i2C
- MMC/SD
- NAND
- UART
- USB (host)
Device trees were taken from Linux mainline:
commit 37624b58542f ("Linux 5.1-rc7")
Signed-off-by: Niel Fourie
Signed-off-by: Parthiban Nallathambi
Reviewed-by: Heiko Schocher
Reviewed-by: Tom Rini
Tested-by: Marek Vasut
---
Notes:
Notes:
Changes for v7:
- commands dhcp, ping added by default
- dm-pre-reloc added for i2c0
- console changed to ttyO0 and other nit picks fix
Changes for v6:
- RAM initialisation reworked to detect available memory
- Remove memory section from am335x-wega-rdk-u-boot.dtsi
Changes for v5:
- Revert proposed moving of sections to am33xx-u-boot.dtsi
- Remove redundant/incorrect lines from am33xx-u-boot.dtsi
- Add missing changelog
Changes for v4:
- Propose abstracting common sections to am33xx-u-boot.dtsi
- Remove dead Falcon mode code
- Remove non-DM I2C support for TPS65910 I2C
Changes for v3:
- Added kernel revision of upstream Linux dtsi files
- Place TARGET_PHYCORE_AM335X_R2 alphabetically in Kconfig
- Rework TPS65910 I2C init code
- Remove non-DM USB board macros
- Minor tweaks
Changes for v2:
- Remove formatting changes to upstream Linux dtsi files
- Remove incorrectly added MACH_TYPE
- Rename board from phycore_pcl060 to phycore_am335x_r2
- Implement selecting memory size from device tree
- Remove non-DM Ethernet board code
- General clean-up
arch/arm/dts/Makefile | 3 +-
arch/arm/dts/am335x-phycore-som.dtsi | 322 +
arch/arm/dts/am335x-wega-rdk-u-boot.dtsi | 31 ++
arch/arm/dts/am335x-wega-rdk.dts | 23 ++
arch/arm/dts/am335x-wega.dtsi | 230 +++
arch/arm/mach-omap2/Kconfig| 1 +
arch/arm/mach-omap2/am33xx/Kconfig | 7 +
board/phytec/phycore_am335x_r2/Kconfig | 15 +
board/phytec/phycore_am335x_r2/MAINTAINERS | 7 +
board/phytec/phycore_am335x_r2/Makefile| 11 +
board/phytec/phycore_am335x_r2/board.c | 260 +
board/phytec/phycore_am335x_r2/board.h | 24 ++
board/phytec/phycore_am335x_r2/mux.c | 117
configs/phycore-am335x-r2-wega_defconfig | 81 ++
include/configs/phycore_am335x_r2.h| 130 +
15 files changed, 1261 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/am335x-phycore-som.dtsi
create mode 100644 arch/arm/dts/am335x-wega-rdk-u-boot.dtsi
create mode 100644 arch/arm/dts/am335x-wega-rdk.dts
create mode 100644 arch/arm/dts/am335x-wega.dtsi
create mode 100644 board/phytec/phycore_am335x_r2/Kconfig
create mode 100644 board/phytec/phycore_am335x_r2/MAINTAINERS
create mode 100644 board/phytec/phycore_am335x_r2/Makefile
create mode 100644 board/phytec/phycore_am335x_r2/board.c
create mode 100644 board/phytec/phycore_am335x_r2/board.h
create mode 100644 board/phytec/phycore_am335x_r2/mux.c
create mode 100644 configs/phycore-am335x-r2-wega_defconfig
create mode 100644 include/configs/phycore_am335x_r2.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index e0c54bfa76..ceb7a32cf6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -287,7 +287,8 @@ dtb-$(CONFIG_AM33XX) += \
am335x-chiliboard.dtb \
am335x-sl50.dtb \
am335x-base0033.dtb \
- am335x-guardian.dtb
+ am335x-guardian.dtb \
+ am335x-wega-rdk.dtb
dtb-$(CONFIG_AM43XX) += am437x-gp-evm.dtb am437x-sk-evm.dtb\
am43x-epos-evm.dtb \
am437x-idk-evm.dtb \
diff --git a/arch/arm/dts/am335x-phycore-som.dtsi
b/arch/arm/dts/am335x-phycore-som.dtsi
new file mode 100644
index 00..8d7c19e5e1
--- /dev/null
+++ b/arch/arm/dts/am335x-phycore-som.dtsi
@@ -0,0 +1,322 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2015 Phytec Messtechnik GmbH
+ * Author: Teresa Remmet
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "am33xx.dtsi"
+#include
+
+/ {
+ model = "Phytec AM335x phyCORE";
+ compatible = "phytec,am335x-phycore-som", "ti,am33xx";
+
+ aliases {
+ rtc0 = _rtc;
+ rtc1 =
+ };
+
+ cpus {
+ cpu@0 {
+ cpu0-supply = <_reg>;
+ };
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x8000 0x1000>; /* 256 MB */
+ };
+
+
[U-Boot] [PATCH v2 7/7] configs: am65x_evm_a53: enable support for PCIe ethernet cards
Enable support for Intel E1000 based PCIe ethernet cards that can be used to test PCIe RC functionality on AM65x EVM. Signed-off-by: Sekhar Nori --- configs/am65x_evm_a53_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 7745e2038790..c1a04257769f 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -60,6 +60,9 @@ CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_K3_ARASAN=y CONFIG_PHY=y +CONFIG_DM_ETH=y +CONFIG_E1000=y +CONFIG_CMD_E1000=y CONFIG_PCI=y CONFIG_DM_PCI=y CONFIG_PCI_KEYSTONE=y -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 6/7] arm: dts: k3-am65: add support for PCIe and SERDES
Add needed device-tree nodes to support PCIe 0
and SERDES on AM65x SoC. The nodes are kept
disabled by default.
Signed-off-by: Sekhar Nori
---
arch/arm/dts/k3-am65-main.dtsi | 108 +
arch/arm/dts/k3-am65.dtsi | 1 +
include/dt-bindings/phy/phy-am654-serdes.h | 13
3 files changed, 122 insertions(+)
create mode 100644 include/dt-bindings/phy/phy-am654-serdes.h
diff --git a/arch/arm/dts/k3-am65-main.dtsi b/arch/arm/dts/k3-am65-main.dtsi
index adcd6341e40c..a564b277c357 100644
--- a/arch/arm/dts/k3-am65-main.dtsi
+++ b/arch/arm/dts/k3-am65-main.dtsi
@@ -5,6 +5,9 @@
* Copyright (C) 2016-2018 Texas Instruments Incorporated - http://www.ti.com/
*/
+#include
+#include
+
_main {
gic500: interrupt-controller@180 {
compatible = "arm,gic-v3";
@@ -69,4 +72,109 @@
clock-frequency = <4800>;
current-speed = <115200>;
};
+
+ scm_conf: scm_conf@10 {
+ compatible = "syscon", "simple-mfd";
+ reg = <0 0x0010 0 0x1c000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0010 0x1c000>;
+
+ serdes_mux: mux-controller {
+ compatible = "mmio-mux";
+ #mux-control-cells = <1>;
+ mux-reg-masks = <0x4080 0x3>, /* SERDES0 lane select */
+ <0x4090 0x3>; /* SERDES1 lane select */
+ };
+
+ pcie0_mode: pcie-mode@4060 {
+ compatible = "syscon";
+ reg = <0x4060 0x4>;
+ };
+
+ pcie1_mode: pcie-mode@4070 {
+ compatible = "syscon";
+ reg = <0x4070 0x4>;
+ };
+
+ serdes0_clk: serdes_clk@4080 {
+ compatible = "syscon";
+ reg = <0x4080 0x4>;
+ };
+
+ serdes1_clk: serdes_clk@4090 {
+ compatible = "syscon";
+ reg = <0x4090 0x4>;
+ };
+
+ pcie_devid: pcie-devid@210 {
+ compatible = "syscon";
+ reg = <0x0210 0x4>;
+ };
+ };
+
+ serdes0: serdes@90 {
+ compatible = "ti,phy-am654-serdes";
+ reg = <0x0 0x90 0x0 0x2000>;
+ reg-names = "serdes";
+ #phy-cells = <2>;
+ power-domains = <_pds 153>;
+ clocks = <_clks 153 4>, <_clks 153 1>, <
AM654_SERDES_LO_REFCLK>;
+ clock-output-names = "serdes0_cmu_refclk", "serdes0_lo_refclk",
"serdes0_ro_refclk";
+ assigned-clocks = <_clks 153 4>, <
AM654_SERDES_CMU_REFCLK>;
+ assigned-clock-parents = <_clks 153 8>, <_clks 153 4>;
+ ti,serdes-clk = <_clk>;
+ mux-controls = <_mux 0>;
+ #clock-cells = <1>;
+ };
+
+ serdes1: serdes@91 {
+ compatible = "ti,phy-am654-serdes";
+ reg = <0x0 0x91 0x0 0x2000>;
+ reg-names = "serdes";
+ #phy-cells = <2>;
+ power-domains = <_pds 154>;
+ clocks = < AM654_SERDES_RO_REFCLK>, <_clks 154 1>,
<_clks 154 5>;
+ clock-output-names = "serdes1_cmu_refclk", "serdes1_lo_refclk",
"serdes1_ro_refclk";
+ assigned-clocks = <_clks 154 5>, <
AM654_SERDES_CMU_REFCLK>;
+ assigned-clock-parents = <_clks 154 9>, <_clks 154 5>;
+ ti,serdes-clk = <_clk>;
+ mux-controls = <_mux 1>;
+ #clock-cells = <1>;
+ };
+
+ pcie0_rc: pcie@550 {
+ compatible = "ti,am654-pcie-rc";
+ reg = <0x0 0x550 0x0 0x1000>, <0x0 0x5501000 0x0 0x1000>,
<0x0 0x1000 0x0 0x2000>, <0x0 0x5506000 0x0 0x1000>;
+ reg-names = "app", "dbics", "config", "atu";
+ power-domains = <_pds 120>;
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x8100 0 0 0x0 0x1002 0 0x0001
+ 0x8200 0 0x1003 0x0 0x1003 0
0x07FD>;
+ ti,syscon-pcie-id = <_devid>;
+ ti,syscon-pcie-mode = <_mode>;
+ bus-range = <0x0 0xff>;
+ status = "disabled";
+ device_type = "pci";
+ num-lanes = <1>;
+ num-ob-windows = <16>;
+ num-viewport = <16>;
+ max-link-speed = <3>;
+ interrupts = ;
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 7>;
+ interrupt-map = <0 0 0 1 _intc 0>, /* INT A */
+ <0 0 0 2 _intc 0>, /* INT B */
+
[U-Boot] [PATCH v2 1/7] clk: add support for clk_is_match()
Add support for clk_is_match() which is required to
know if two clock pointers point to the same exact
physical clock.
Also add a unit test for the new API.
Reviewed-by: Lokesh Vutla
Signed-off-by: Sekhar Nori
---
drivers/clk/clk-uclass.c | 13 +
include/clk.h| 13 +
test/dm/clk.c| 1 +
3 files changed, 27 insertions(+)
diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 79b3b0494c65..823be2bcb624 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -453,6 +453,19 @@ int clk_disable_bulk(struct clk_bulk *bulk)
return 0;
}
+bool clk_is_match(const struct clk *p, const struct clk *q)
+{
+ /* trivial case: identical struct clk's or both NULL */
+ if (p == q)
+ return true;
+
+ /* same device, id and data */
+ if (p->dev == q->dev && p->id == q->id && p->data == q->data)
+ return true;
+
+ return false;
+}
+
UCLASS_DRIVER(clk) = {
.id = UCLASS_CLK,
.name = "clk",
diff --git a/include/clk.h b/include/clk.h
index d24e99713a35..e657da038398 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -309,6 +309,18 @@ int clk_disable(struct clk *clk);
*/
int clk_disable_bulk(struct clk_bulk *bulk);
+/**
+ * clk_is_match - check if two clk's point to the same hardware clock
+ * @p: clk compared against q
+ * @q: clk compared against p
+ *
+ * Returns true if the two struct clk pointers both point to the same hardware
+ * clock node.
+ *
+ * Returns false otherwise. Note that two NULL clks are treated as matching.
+ */
+bool clk_is_match(const struct clk *p, const struct clk *q);
+
int soc_clk_dump(void);
/**
@@ -321,4 +333,5 @@ static inline bool clk_valid(struct clk *clk)
{
return !!clk->dev;
}
+
#endif
diff --git a/test/dm/clk.c b/test/dm/clk.c
index f301ecbb459d..8468fd45d464 100644
--- a/test/dm/clk.c
+++ b/test/dm/clk.c
@@ -24,6 +24,7 @@ static int dm_test_clk_base(struct unit_test_state *uts)
/* Get the same clk port in 2 different ways and compare */
ut_assertok(clk_get_by_index(dev, 1, _method1));
ut_assertok(clk_get_by_index_nodev(dev_ofnode(dev), 1, _method2));
+ ut_assertok(clk_is_match(_method1, _method2));
ut_asserteq(clk_method1.id, clk_method2.id);
return 0;
--
2.16.2
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 5/7] configs: am65x_evm_a53: enable PCIe support
Enable support for PCIe and related configurations on AM654 EVM platform. Signed-off-by: Sekhar Nori --- configs/am65x_evm_a53_defconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/configs/am65x_evm_a53_defconfig b/configs/am65x_evm_a53_defconfig index 41cf0100fa3a..7745e2038790 100644 --- a/configs/am65x_evm_a53_defconfig +++ b/configs/am65x_evm_a53_defconfig @@ -31,6 +31,7 @@ CONFIG_SPL_YMODEM_SUPPORT=y CONFIG_CMD_ASKENV=y # CONFIG_CMD_FLASH is not set CONFIG_CMD_MMC=y +CONFIG_CMD_PCI=y CONFIG_CMD_REMOTEPROC=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y @@ -58,6 +59,11 @@ CONFIG_K3_SEC_PROXY=y CONFIG_DM_MMC=y CONFIG_MMC_SDHCI=y CONFIG_MMC_SDHCI_K3_ARASAN=y +CONFIG_PHY=y +CONFIG_PCI=y +CONFIG_DM_PCI=y +CONFIG_PCI_KEYSTONE=y +CONFIG_AM654_PHY=y CONFIG_PINCTRL=y # CONFIG_PINCTRL_GENERIC is not set CONFIG_SPL_PINCTRL=y -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 4/7] phy: add support for AM654x SERDES
Add a new SERDES driver for TI's AM654x SoC which configures
the SERDES only for PCIe. Support fo USB3 can be added later.
SERDES in am654x has three input clocks (left input, external
reference clock and right input) and two output clocks (left
output and right output) in addition to a PLL mux clock which
the SERDES uses for Clock Multiplier Unit (CMU refclock).
The PLL mux clock can select from one of the three input
clocks. The right output can select between left input and
external reference clock while the left output can select
between the right input and external reference clock.
The driver has support to select PLL mux and left/right output
mux as specified in device tree.
Signed-off-by: Sekhar Nori
---
drivers/phy/Kconfig| 9 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-ti-am654.c | 411 +
3 files changed, 421 insertions(+)
create mode 100644 drivers/phy/phy-ti-am654.c
diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig
index 957efb3984bf..cce98448a4b5 100644
--- a/drivers/phy/Kconfig
+++ b/drivers/phy/Kconfig
@@ -102,6 +102,15 @@ config SPL_PIPE3_PHY
This PHY is found on omap devices supporting SATA such as dra7, am57x
and omap5
+config AM654_PHY
+ tristate "TI AM654 SERDES support"
+ depends on PHY && ARCH_K3
+ select REGMAP
+ select SYSCON
+ help
+ This option enables support for TI AM654 SerDes PHY used for
+ PCIe.
+
config STI_USB_PHY
bool "STMicroelectronics USB2 picoPHY driver for STiH407 family"
depends on PHY && ARCH_STI
diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile
index 90646ca55b9d..39da13c4c941 100644
--- a/drivers/phy/Makefile
+++ b/drivers/phy/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_BCM6358_USBH_PHY) += bcm6358-usbh-phy.o
obj-$(CONFIG_BCM6368_USBH_PHY) += bcm6368-usbh-phy.o
obj-$(CONFIG_PHY_SANDBOX) += sandbox-phy.o
obj-$(CONFIG_$(SPL_)PIPE3_PHY) += ti-pipe3-phy.o
+obj-$(CONFIG_AM654_PHY) += phy-ti-am654.o
obj-$(CONFIG_STI_USB_PHY) += sti_usb_phy.o
obj-$(CONFIG_PHY_RCAR_GEN2) += phy-rcar-gen2.o
obj-$(CONFIG_PHY_RCAR_GEN3) += phy-rcar-gen3.o
diff --git a/drivers/phy/phy-ti-am654.c b/drivers/phy/phy-ti-am654.c
new file mode 100644
index ..39490124eabf
--- /dev/null
+++ b/drivers/phy/phy-ti-am654.c
@@ -0,0 +1,411 @@
+// SPDX-License-Identifier: GPL-2.0+
+/**
+ * PCIe SERDES driver for AM654x SoC
+ *
+ * Copyright (C) 2018 Texas Instruments
+ * Author: Kishon Vijay Abraham I
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define CMU_R07C 0x7c
+#define CMU_MASTER_CDN_O BIT(24)
+
+#define COMLANE_R138 0xb38
+#define CONFIG_VERSION_REG_MASKGENMASK(23, 16)
+#define CONFIG_VERSION_REG_SHIFT 16
+#define VERSION0x70
+
+#define COMLANE_R190 0xb90
+#define L1_MASTER_CDN_OBIT(9)
+
+#define COMLANE_R194 0xb94
+#define CMU_OK_I_0 BIT(19)
+
+#define SERDES_CTRL0x1fd0
+#define POR_EN BIT(29)
+
+#define WIZ_LANEXCTL_STS 0x1fe0
+#define TX0_ENABLE_OVL BIT(31)
+#define TX0_ENABLE_MASKGENMASK(30, 29)
+#define TX0_ENABLE_SHIFT 29
+#define TX0_DISABLE_STATE 0x0
+#define TX0_SLEEP_STATE0x1
+#define TX0_SNOOZE_STATE 0x2
+#define TX0_ENABLE_STATE 0x3
+#define RX0_ENABLE_OVL BIT(15)
+#define RX0_ENABLE_MASKGENMASK(14, 13)
+#define RX0_ENABLE_SHIFT 13
+#define RX0_DISABLE_STATE 0x0
+#define RX0_SLEEP_STATE0x1
+#define RX0_SNOOZE_STATE 0x2
+#define RX0_ENABLE_STATE 0x3
+
+#define WIZ_PLL_CTRL 0x1ff4
+#define PLL_ENABLE_OVL BIT(31)
+#define PLL_ENABLE_MASKGENMASK(30, 29)
+#define PLL_ENABLE_SHIFT 29
+#define PLL_DISABLE_STATE 0x0
+#define PLL_SLEEP_STATE0x1
+#define PLL_SNOOZE_STATE 0x2
+#define PLL_ENABLE_STATE 0x3
+#define PLL_OK BIT(28)
+
+#define PLL_LOCK_TIME 1000/* in milliseconds */
+#define SLEEP_TIME 100 /* in microseconds */
+
+#define LANE_USB3 0x0
+#define LANE_PCIE0_LANE0 0x1
+
+#define LANE_PCIE1_LANE0 0x0
+#define LANE_PCIE0_LANE1 0x1
+
+#define SERDES_NUM_CLOCKS 3
+
+/* SERDES control MMR bit offsets */
+#define SERDES_CTL_LANE_FUNC_SEL_SHIFT 0
+#define SERDES_CTL_LANE_FUNC_SEL_MASK GENMASK(1, 0)
+#define SERDES_CTL_CLK_SEL_SHIFT 4
+#define SERDES_CTL_CLK_SEL_MASKGENMASK(7, 4)
+
+/**
+ * struct serdes_am654_mux_clk_data - clock controller information structure
+ */
+struct serdes_am654_mux_clk_data {
+ struct regmap *regmap;
+ struct clk_bulk parents;
+};
+
+static int serdes_am654_mux_clk_probe(struct udevice *dev)
+{
+ struct serdes_am654_mux_clk_data *data =
[U-Boot] [PATCH v2 3/7] pcie: ti: add driver for AM65x PCIe RC
Add driver supporting PCIe root-complex available on TI's AM65x SoC. Signed-off-by: Sekhar Nori --- drivers/pci/Kconfig | 6 + drivers/pci/Makefile | 1 + drivers/pci/pcie_dw_ti.c | 725 +++ 3 files changed, 732 insertions(+) create mode 100644 drivers/pci/pcie_dw_ti.c diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig index 429bb836a8a0..1cb96634e7fe 100644 --- a/drivers/pci/Kconfig +++ b/drivers/pci/Kconfig @@ -137,4 +137,10 @@ config PCI_MVEBU Say Y here if you want to enable PCIe controller support on Armada XP/38x SoCs. +config PCI_KEYSTONE + bool "TI Keystone PCIe controller" + depends on DM_PCI + help + Say Y here if you want to enable PCI controller support on AM654 SoC. + endif diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile index bd392edba179..151aa3f1569d 100644 --- a/drivers/pci/Makefile +++ b/drivers/pci/Makefile @@ -37,3 +37,4 @@ obj-$(CONFIG_PCIE_LAYERSCAPE_GEN4) += pcie_layerscape_gen4.o \ pcie_layerscape_gen4_fixup.o obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o obj-$(CONFIG_PCIE_INTEL_FPGA) += pcie_intel_fpga.o +obj-$(CONFIG_PCI_KEYSTONE) += pcie_dw_ti.o diff --git a/drivers/pci/pcie_dw_ti.c b/drivers/pci/pcie_dw_ti.c new file mode 100644 index ..b37fc2de7fb8 --- /dev/null +++ b/drivers/pci/pcie_dw_ti.c @@ -0,0 +1,725 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2018 Texas Instruments, Inc + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include + +DECLARE_GLOBAL_DATA_PTR; + +#define PCIE_VENDORID_MASK GENMASK(15, 0) +#define PCIE_DEVICEID_SHIFT16 + +/* PCI DBICS registers */ +#define PCIE_CONFIG_BAR0 0x10 +#define PCIE_LINK_STATUS_REG 0x80 +#define PCIE_LINK_STATUS_SPEED_OFF 16 +#define PCIE_LINK_STATUS_SPEED_MASK(0xf << PCIE_LINK_STATUS_SPEED_OFF) +#define PCIE_LINK_STATUS_WIDTH_OFF 20 +#define PCIE_LINK_STATUS_WIDTH_MASK(0xf << PCIE_LINK_STATUS_WIDTH_OFF) + +#define PCIE_LINK_CAPABILITY 0x7c +#define PCIE_LINK_CTL_20xa0 +#define TARGET_LINK_SPEED_MASK 0xf +#define LINK_SPEED_GEN_1 0x1 +#define LINK_SPEED_GEN_2 0x2 +#define LINK_SPEED_GEN_3 0x3 + +#define PCIE_MISC_CONTROL_1_OFF0x8bc +#define PCIE_DBI_RO_WR_EN BIT(0) + +#define PLR_OFFSET 0x700 +#define PCIE_PORT_DEBUG0 (PLR_OFFSET + 0x28) +#define PORT_LOGIC_LTSSM_STATE_MASK0x1f +#define PORT_LOGIC_LTSSM_STATE_L0 0x11 + +#define PCIE_LINK_WIDTH_SPEED_CONTROL 0x80c +#define PORT_LOGIC_SPEED_CHANGE(0x1 << 17) + +#define PCIE_LINK_UP_TIMEOUT_MS100 + +/* + * iATU Unroll-specific register definitions + * From 4.80 core version the address translation will be made by unroll. + * The registers are offset from atu_base + */ +#define PCIE_ATU_UNR_REGION_CTRL1 0x00 +#define PCIE_ATU_UNR_REGION_CTRL2 0x04 +#define PCIE_ATU_UNR_LOWER_BASE0x08 +#define PCIE_ATU_UNR_UPPER_BASE0x0c +#define PCIE_ATU_UNR_LIMIT 0x10 +#define PCIE_ATU_UNR_LOWER_TARGET 0x14 +#define PCIE_ATU_UNR_UPPER_TARGET 0x18 + +#define PCIE_ATU_REGION_INDEX1 (0x1 << 0) +#define PCIE_ATU_REGION_INDEX0 (0x0 << 0) +#define PCIE_ATU_TYPE_MEM (0x0 << 0) +#define PCIE_ATU_TYPE_IO (0x2 << 0) +#define PCIE_ATU_TYPE_CFG0 (0x4 << 0) +#define PCIE_ATU_TYPE_CFG1 (0x5 << 0) +#define PCIE_ATU_ENABLE(0x1 << 31) +#define PCIE_ATU_BAR_MODE_ENABLE (0x1 << 30) +#define PCIE_ATU_BUS(x)(((x) & 0xff) << 24) +#define PCIE_ATU_DEV(x)(((x) & 0x1f) << 19) +#define PCIE_ATU_FUNC(x) (((x) & 0x7) << 16) + +/* Register address builder */ +#define PCIE_GET_ATU_OUTB_UNR_REG_OFFSET(region) ((region) << 9) + +/* Offsets from App base */ +#define PCIE_CMD_STATUS0x04 +#define LTSSM_EN_VAL BIT(0) + +/* Parameters for the waiting for iATU enabled routine */ +#define LINK_WAIT_MAX_IATU_RETRIES 5 +#define LINK_WAIT_IATU 1 + +#define AM654_PCIE_DEV_TYPE_MASK 0x3 +#define EP 0x0 +#define LEG_EP 0x1 +#define RC 0x2 + +/** + * struct pcie_dw_ti - TI DW PCIe controller state + * + * @app_base: The base address of application register space + * @dbics_base: The base address of dbics register space + * @cfg_base: The base address of configuration space + * @atu_base: The base address of ATU space + * @cfg_size: The size of the configuration space which is needed + *as it gets written into the PCIE_ATU_LIMIT register + * @first_busno: This driver supports multiple PCIe controllers.
[U-Boot] [PATCH v2 0/7] Add PCIe root complex support for AM654x SoC
Hi, This patch series adds PCIe root complex support for AM654x SoC. The device-tree files are based on bindings accepted in linux. See files Documentation/devicetree/bindings/phy/ti,phy-am654-serdes.txt and Documentation/devicetree/bindings/pci/pci-keystone.txt in latest mainline master. I have not posted the actual board-specific device-tree bits yet. The reason is that PCIe slot is on a daughter card on the AM65x EVM. I want to see how we can support that as an overlay in U-Boot. That needs some more attention. Meanwhile I have tested this using a patch that simply enables PCIe in the baseboard device-tree file itself. v2: - add unit tests for new clock and dm APIs introduced - add Lokesh's Reviewed-by: for patches #1 and #2 Sekhar Nori (7): clk: add support for clk_is_match() dm: core: add support for getting register address and size pcie: ti: add driver for AM65x PCIe RC phy: add support for AM654x SERDES configs: am65x_evm_a53: enable PCIe support arm: dts: k3-am65: add support for PCIe and SERDES configs: am65x_evm_a53: enable support for PCIe ethernet cards arch/arm/dts/k3-am65-main.dtsi | 108 + arch/arm/dts/k3-am65.dtsi | 1 + configs/am65x_evm_a53_defconfig| 9 + drivers/clk/clk-uclass.c | 13 + drivers/core/fdtaddr.c | 17 + drivers/core/read.c| 20 + drivers/pci/Kconfig| 6 + drivers/pci/Makefile | 1 + drivers/pci/pcie_dw_ti.c | 725 + drivers/phy/Kconfig| 9 + drivers/phy/Makefile | 1 + drivers/phy/phy-ti-am654.c | 411 include/clk.h | 13 + include/dm/fdtaddr.h | 18 + include/dm/read.h | 41 ++ include/dt-bindings/phy/phy-am654-serdes.h | 13 + test/dm/clk.c | 1 + test/dm/test-fdt.c | 16 +- 18 files changed, 1419 insertions(+), 4 deletions(-) create mode 100644 drivers/pci/pcie_dw_ti.c create mode 100644 drivers/phy/phy-ti-am654.c create mode 100644 include/dt-bindings/phy/phy-am654-serdes.h -- 2.16.2 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v2 2/7] dm: core: add support for getting register address and size
Current dev_read_*() API lacks support to get address and size
of a "reg" property by name or index. Add support for the same.
Livetree support has been added but not tested on real hardware.
The existing unit tests testing reading address from device-tree
have been updated to test address as well as size.
Reviewed-by: Lokesh Vutla
Signed-off-by: Sekhar Nori
---
drivers/core/fdtaddr.c | 17 +
drivers/core/read.c| 20
include/dm/fdtaddr.h | 18 ++
include/dm/read.h | 41 +
test/dm/test-fdt.c | 16
5 files changed, 108 insertions(+), 4 deletions(-)
diff --git a/drivers/core/fdtaddr.c b/drivers/core/fdtaddr.c
index c2873861dacd..6850003a287b 100644
--- a/drivers/core/fdtaddr.c
+++ b/drivers/core/fdtaddr.c
@@ -129,6 +129,23 @@ fdt_addr_t devfdt_get_addr_name(struct udevice *dev, const
char *name)
#endif
}
+fdt_addr_t devfdt_get_addr_size_name(struct udevice *dev, const char *name,
+fdt_size_t *size)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+ int index;
+
+ index = fdt_stringlist_search(gd->fdt_blob, dev_of_offset(dev),
+ "reg-names", name);
+ if (index < 0)
+ return index;
+
+ return devfdt_get_addr_size_index(dev, index, size);
+#else
+ return FDT_ADDR_T_NONE;
+#endif
+}
+
fdt_addr_t devfdt_get_addr(struct udevice *dev)
{
return devfdt_get_addr_index(dev, 0);
diff --git a/drivers/core/read.c b/drivers/core/read.c
index 6bda077a34b9..0fcd20874610 100644
--- a/drivers/core/read.c
+++ b/drivers/core/read.c
@@ -82,6 +82,15 @@ fdt_addr_t dev_read_addr_index(struct udevice *dev, int
index)
return devfdt_get_addr_index(dev, index);
}
+fdt_addr_t dev_read_addr_size_index(struct udevice *dev, int index,
+ fdt_size_t *size)
+{
+ if (ofnode_is_np(dev_ofnode(dev)))
+ return ofnode_get_addr_size_index(dev_ofnode(dev), index, size);
+ else
+ return devfdt_get_addr_size_index(dev, index, size);
+}
+
void *dev_remap_addr_index(struct udevice *dev, int index)
{
fdt_addr_t addr = dev_read_addr_index(dev, index);
@@ -102,6 +111,17 @@ fdt_addr_t dev_read_addr_name(struct udevice *dev, const
char *name)
return dev_read_addr_index(dev, index);
}
+fdt_addr_t dev_read_addr_size_name(struct udevice *dev, const char *name,
+ fdt_size_t *size)
+{
+ int index = dev_read_stringlist_search(dev, "reg-names", name);
+
+ if (index < 0)
+ return FDT_ADDR_T_NONE;
+ else
+ return dev_read_addr_size_index(dev, index, size);
+}
+
void *dev_remap_addr_name(struct udevice *dev, const char *name)
{
fdt_addr_t addr = dev_read_addr_name(dev, name);
diff --git a/include/dm/fdtaddr.h b/include/dm/fdtaddr.h
index 3bc2599b6cbd..57b326cb3362 100644
--- a/include/dm/fdtaddr.h
+++ b/include/dm/fdtaddr.h
@@ -120,4 +120,22 @@ fdt_addr_t devfdt_get_addr_size_index(struct udevice *dev,
int index,
*/
fdt_addr_t devfdt_get_addr_name(struct udevice *dev, const char *name);
+/**
+ * devfdt_get_addr_size_name() - Get the reg property and its size for a
device,
+ * indexed by name
+ *
+ * Returns the address and size specified in the 'reg' property of a device.
+ *
+ * @dev: Pointer to a device
+ * @name: the 'reg' property can hold a list of pairs, with the
+ * 'reg-names' property providing named-based identification. @index
+ * indicates the value to search for in 'reg-names'.
+ * @size: Pointer to size variable - this function returns the size
+ *specified in the 'reg' property here
+ *
+ * @return addr
+ */
+fdt_addr_t devfdt_get_addr_size_name(struct udevice *dev, const char *name,
+fdt_size_t *size);
+
#endif
diff --git a/include/dm/read.h b/include/dm/read.h
index 60b727cbd821..5c38fcc922ae 100644
--- a/include/dm/read.h
+++ b/include/dm/read.h
@@ -144,6 +144,19 @@ int dev_read_size(struct udevice *dev, const char
*propname);
*/
fdt_addr_t dev_read_addr_index(struct udevice *dev, int index);
+/**
+ * dev_read_addr_size_index() - Get the indexed reg property of a device
+ *
+ * @dev: Device to read from
+ * @index: the 'reg' property can hold a list of pairs
+ *and @index is used to select which one is required
+ * @size: place to put size value (on success)
+ *
+ * @return address or FDT_ADDR_T_NONE if not found
+ */
+fdt_addr_t dev_read_addr_size_index(struct udevice *dev, int index,
+ fdt_size_t *size);
+
/**
* dev_remap_addr_index() - Get the indexed reg property of a device
* as a memory-mapped I/O pointer
@@ -168,6 +181,20 @@ void *dev_remap_addr_index(struct udevice *dev, int index);
*/
fdt_addr_t
Re: [U-Boot] Question about cfi flash driver can not work well in cacheable region !
Hi Rick, On 03.06.19 11:27, Rick Chen wrote: Hi Stefan and other seniors I encounter some problems about cfi flash driver. And hope you can give some comments to resolve it. Followings are the flash verification status and descriptions : When I verify cfi flash which it's address base is in cacheable region (0x8800) and cache is enabled in system. The flash detection, write and erase action will be failure somehow. The failure messages will be as below: # # Detection failure # # Flash: ## Unknown flash on Bank 1 - Size = 0x = 0 MB 0 Bytes ### # Erase fail # ### protect off all; erase 0x8800 0x8bff; Error: start and/or end address not on sector boundary RISC-V # ### # Write fail # ### RISC-V # cp.b 0x2000 0x8bf0 0x1444 RISC-V # But when I disable cache in system, they will all pass the verification. # Detection pass # Flash: 64 MiB # # erase pass # # protect off all; erase 0x8800 0x8bff; Un-Protect Flash Bank # 1 done Erased 512 sectors RISC-V # ## # write pass # ## RISC-V # cp.b 0x2000 0x8bf0 0x1444 Copy to Flash... done RISC-V # How can I enable cache and let cfi flash can work fine to get better performance ? The CFI driver expects the flash to be located on a uncached area. Is it possible on your architecture to map some areas uncached and others cached? That's how it was done in the old PowerPC days, when parallel flash (via CFI) was still used much more frequently. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: davinci_emac: convert to using the driver model
On Mon, Jun 3, 2019 at 3:12 AM Bartosz Golaszewski wrote:
>
> sob., 1 cze 2019 o 05:24 Adam Ford napisał(a):
> >
> > On Fri, May 31, 2019 at 8:32 AM Bartosz Golaszewski wrote:
> > >
> > > From: Bartosz Golaszewski
> > >
> > > Now that we removed all legacy boards selecting TI_EMAC we can
> > > completely convert the driver code to using the driver model.
> > > This patch also updates all remaining users of davinci_emac.
> > >
> >
> > I took a break from this to come back, and I'm going to give some
> > feedback about how the driver was written. I still do not know why I
> > cannot get an IP address with this patch on the AM3517-evm.
> >
>
> Hi Adam,
>
> thanks for all the testing. Unfortunately I can only test with
> da850-evm and da850-lcdk.
>
> I was wondering if it is possible that the problem is caused by
> cpu_eth_init() from ./arch/arm/mach-omap2/omap3/emac. not being called
> with CONFIG_DM_ETH? The comments say that it brings the module out of
> reset, so maybe this is what causes the problem you're seeing?
I looked into that nearly right away, but there is a chunk of code in
board/logicpd/am3517evm/am3517evm.c which has a function called
misc_init_r() which does the same thing. Looking through the debug
data, it appears as if the drive is communicating for a bit, but at
some point it dies. I'm not going to be able to look at it for a few
days. Is there any way you can submit a V2 to use #ifdef's to allow
users to use the same driver with and without DM_ETH? That would give
the da850/L138 boards the DM_ETH, and give me some time to
troubleshoot the am3517-evm. I know Sekhar works for TI and the AM3517
was the official development kit for TI back in the day. If TI has
some ideas, I'm open to trying them as well when I can get back to it.
adam
>
> > > Signed-off-by: Bartosz Golaszewski
> > > ---
> > > arch/arm/mach-davinci/cpu.c| 13 -
> > > arch/arm/mach-omap2/omap3/emac.c | 3 +-
> > > board/davinci/da8xxevm/da850evm.c | 6 --
> > > board/davinci/da8xxevm/omapl138_lcdk.c | 14 -
> > > board/logicpd/am3517evm/am3517evm.c| 1 -
> > > board/ti/ti816x/evm.c | 3 +-
> > > configs/am3517_evm_defconfig | 1 +
> > > configs/da850evm_defconfig | 1 +
> > > configs/da850evm_direct_nor_defconfig | 1 +
> > > configs/da850evm_nand_defconfig| 1 +
> > > configs/omapl138_lcdk_defconfig| 1 +
> > > configs/ti816x_evm_defconfig | 1 +
> > > drivers/net/ti/davinci_emac.c | 77 ++
> > > include/netdev.h | 1 -
> > > 14 files changed, 51 insertions(+), 73 deletions(-)
> > >
> > > diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
> > > index f97ad3fc74..9fd6564d04 100644
> > > --- a/arch/arm/mach-davinci/cpu.c
> > > +++ b/arch/arm/mach-davinci/cpu.c
> > > @@ -5,7 +5,6 @@
> > > */
> > >
> > > #include
> > > -#include
> > > #include
> > > #include
> > >
> > > @@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
> > > gd->bd->bi_dsp_freq = 0;
> > > return 0;
> > > }
> > > -
> > > -/*
> > > - * Initializes on-chip ethernet controllers.
> > > - * to override, implement board_eth_init()
> > > - */
> > > -int cpu_eth_init(bd_t *bis)
> > > -{
> > > -#if defined(CONFIG_DRIVER_TI_EMAC)
> > > - davinci_emac_initialize();
> > > -#endif
> > > - return 0;
> > > -}
> > > diff --git a/arch/arm/mach-omap2/omap3/emac.c
> > > b/arch/arm/mach-omap2/omap3/emac.c
> > > index c79e870183..fb0c9188f5 100644
> > > --- a/arch/arm/mach-omap2/omap3/emac.c
> > > +++ b/arch/arm/mach-omap2/omap3/emac.c
> > > @@ -7,7 +7,6 @@
> > > */
> > >
> > > #include
> > > -#include
> > > #include
> > > #include
> > >
> > > @@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis)
> > > reset &= ~CPGMACSS_SW_RST;
> > > writel(reset, _scm_general_regs->ip_sw_reset);
> > >
> > > - return davinci_emac_initialize();
> > > + return 0;
> > > }
> > > diff --git a/board/davinci/da8xxevm/da850evm.c
> > > b/board/davinci/da8xxevm/da850evm.c
> > > index 1bc26828bf..d090c00466 100644
> > > --- a/board/davinci/da8xxevm/da850evm.c
> > > +++ b/board/davinci/da8xxevm/da850evm.c
> > > @@ -13,7 +13,6 @@
> > > #include
> > > #include
> > > #include
> > > -#include
> > > #include
> > > #include
> > > #include
> > > @@ -472,11 +471,6 @@ int board_eth_init(bd_t *bis)
> > > if (rmii_hw_init())
> > > printf("RMII hardware init failed!!!\n");
> > > #endif
> > > - if (!davinci_emac_initialize()) {
> > > - printf("Error: Ethernet init failed!\n");
> > > - return -1;
> > > - }
> > > -
> > > return 0;
> > > }
> > > #endif /* CONFIG_DRIVER_TI_EMAC */
> > > diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c
> > > b/board/davinci/da8xxevm/omapl138_lcdk.c
> > > index 2c2f885d43..ef9656add8 100644
> > > --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> >
Re: [U-Boot] [PATCH 2/2 v2] test: dm: add MDIO test
Hi Bin,
On 6/3/2019 3:52 PM, Bin Meng wrote:
Hi Alex,
On Mon, Jun 3, 2019 at 5:47 PM Alex Marginean wrote:
A very simple test for DM_MDIO, mimicks a register write/read through the
sandbox bus to a dummy PHY.
Signed-off-by: Alex Marginean
---
Changes in v2:
- new patch, v1 didn't have a test included
arch/sandbox/dts/test.dts | 4 ++
configs/sandbox_defconfig | 2 +
drivers/net/Kconfig| 10 +
drivers/net/Makefile | 1 +
drivers/net/mdio_sandbox.c | 92 ++
test/dm/Makefile | 1 +
test/dm/mdio.c | 48
7 files changed, 158 insertions(+)
create mode 100644 drivers/net/mdio_sandbox.c
create mode 100644 test/dm/mdio.c
Reviewed-by: Bin Meng
Tested-by: Bin Meng
However, please see some nits below.
Thank you for the review, I'll send a v3 for these later today.
Alex
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8b2d6451c6..70b7e4c275 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -799,6 +799,10 @@
dmas = < 0>, < 1>, < 2>;
dma-names = "m2m", "tx0", "rx0";
};
+
+ mdio-test {
+ compatible = "sandbox,mdio_sandbox";
nits: it reads better if we had "sandbox,mdio"
+ };
};
#include "sandbox_pmic.dtsi"
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 4877f1099a..2a00df9807 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
nits: I think we need update all sandbox defconfigs, or just update
arch/Kconfig and imply PHYLIB & DM_MDIO there.
@@ -139,7 +139,9 @@ CONFIG_SPI_FLASH_SPANSION=y
CONFIG_SPI_FLASH_STMICRO=y
CONFIG_SPI_FLASH_SST=y
CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
CONFIG_NVME=y
CONFIG_PCI=y
CONFIG_DM_PCI=y
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6fba5a84dd..635f8d72c2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -24,6 +24,16 @@ config DM_MDIO
This is currently implemented in net/mdio-uclass.c
Look in include/miiphy.h for details.
+config MDIO_SANDBOX
+ depends on DM_MDIO && SANDBOX
+ default y
+ bool "Sandbox: Mocked MDIO driver"
+ help
+ This driver implements dummy read/write/reset MDIO functions mimicking
+ a bus with a single PHY.
+
+ This driver is used in for testing in test/dm/mdio.c
+
menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 8d02a37896..40038427db 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -77,3 +77,4 @@ obj-y += ti/
obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
obj-y += mscc_eswitch/
obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
+obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
diff --git a/drivers/net/mdio_sandbox.c b/drivers/net/mdio_sandbox.c
new file mode 100644
index 00..d55a7c4466
--- /dev/null
+++ b/drivers/net/mdio_sandbox.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019
+ * Alex Marginean, NXP
+ */
+
+#include
+#include
+#include
+
+#define SANDBOX_PHY_ADDR 5
+#define SANDBOX_PHY_REG0
+
+struct mdio_sandbox_priv {
+ int enabled;
+ u16 reg;
+};
+
+static int mdio_sandbox_read(struct udevice *dev, int addr, int devad, int reg)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ if (!priv->enabled)
+ return -ENODEV;
+
+ if (addr != SANDBOX_PHY_ADDR)
+ return -ENODEV;
+ if (devad != MDIO_DEVAD_NONE)
+ return -ENODEV;
+ if (reg != SANDBOX_PHY_REG)
+ return -ENODEV;
+
+ return priv->reg;
+}
+
+static int mdio_sandbox_write(struct udevice *dev, int addr, int devad, int
reg,
+ u16 val)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ if (!priv->enabled)
+ return -ENODEV;
+
+ if (addr != SANDBOX_PHY_ADDR)
+ return -ENODEV;
+ if (devad != MDIO_DEVAD_NONE)
+ return -ENODEV;
+ if (reg != SANDBOX_PHY_REG)
+ return -ENODEV;
+
+ priv->reg = val;
+
+ return 0;
+}
+
+static int mdio_sandbox_reset(struct udevice *dev)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ priv->reg = 0;
+
+ return 0;
+}
+
+static const struct mdio_ops mdio_sandbox_ops = {
+ .read = mdio_sandbox_read,
+ .write = mdio_sandbox_write,
+ .reset = mdio_sandbox_reset,
+};
+
+int mdio_sandbox_probe(struct udevice *dev)
This should be static.
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ priv->enabled = 1;
+
+ return 0;
+}
+
+static const struct udevice_id mdio_sandbox_ids[] = {
+ { .compatible = "sandbox,mdio_sandbox" },
+ { }
+};
+
Re: [U-Boot] [PATCH 1/2] drivers: pci: add map_bar support for Enhanced Allocation
Hi Alex,
On Mon, Jun 3, 2019 at 8:49 PM Alex Marginean wrote:
>
> Hi Bin,
>
> On 6/2/2019 4:15 PM, Bin Meng wrote:
> > +Simon,
> >
> > Hi Alex,
> >
> > On Sat, Jun 1, 2019 at 12:26 AM Alex Marginean
> > wrote:
> >>
> >> Makes dm_pci_map_bar function available for integrated PCI devices that
> >> support Enhanced Allocation instead of original PCI BAR mechanism.
> >>
> >> Signed-off-by: Alex Marginean
> >> ---
> >> drivers/pci/pci-uclass.c | 47
> >> include/pci.h| 2 +-
> >> 2 files changed, 48 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
> >> index cf1e7617ae..3204f156c3 100644
> >> --- a/drivers/pci/pci-uclass.c
> >> +++ b/drivers/pci/pci-uclass.c
> >> @@ -1341,11 +1341,58 @@ pci_addr_t dm_pci_phys_to_bus(struct udevice *dev,
> >> phys_addr_t phys_addr,
> >> return bus_addr;
> >> }
> >>
> >> +static void *dm_pci_map_ea_bar(struct udevice *dev, int bar, int flags)
> >> +{
> >> + int ea_off, ea_cnt, i, entry_size = 0;
> >
> > nits: no need to initialize entry_size here.
> >
> >> + int bar_id = bar - PCI_BASE_ADDRESS_0;
> >
> > This does not work for anything other than BAR0. It should be (bar -
> > PCI_BASE_ADDRESS_0) >> 2;
>
> Good find, you're right, I did use it only for BAR0 and missed this.
>
> >
> >> + u32 ea_entry;
> >> + u64 addr;
> >
> > This should be: pci_addr_t addr
>
> I think maybe phys_addr_t is more appropriate, EA functions are supposed
> to be integrated and their BAR equivalent addresses map into system
> address space. In the end this goes to map_physmem, which takes a
> phys_addr_t.
>
Makes sense.
> >
> >> +
> >> + /* handle PCI functions that use Enhanced Allocation */
> >> + ea_off = dm_pci_find_capability(dev, PCI_CAP_ID_EA);
> >> +
> >> + if (!ea_off)
> >> + return 0;
> >
> > Above codes are not necessary. EA offset is already known when calling
> > dm_pci_map_ea_bar() from dm_pci_map_bar(). We can pass the offset to
> > this function.
> >
> >> +
> >> + /* EA capability structure header */
> >> + dm_pci_read_config32(dev, ea_off, _entry);
> >> + ea_cnt = (ea_entry >> 16) & 0x3f;
> >
> > Avoid using magic numbers, instead use a macro PCI_EA_NUM_ENT_MASK. In
> > fact, Linux has several macros for EA capability
> > (include/uapi/linux/pci_regs.h) and we can just import these macros in
> > U-Boot too.
>
> That's a good suggestion, I will do that.
>
> >
> >> + ea_off += 4;
> >> +
> >> + for (i = 0; i < ea_cnt; i++, ea_off += entry_size) {
> >
> > nits: two spaces before entry_size
> >
> >> + /* Entry header */
> >> + dm_pci_read_config32(dev, ea_off, _entry);
> >> + entry_size = (ea_entry & 0x7) * 4;
> >
> > Per the spec, entry size is number of DW following the initial DW in
> > this entry. So it should really be: ((ea_entry & 0x7) + 1) * 4. Again
> > like the bar_id comments above, we can use << 2 here instead of * 4.
> >
> >> +
> >> + if (((ea_entry >> 4) & 0xf) != bar_id)
> >> + continue;
> >> +
> >> + /* Base address, 1st DW */
> >> + dm_pci_read_config32(dev, ea_off + 4, _entry);
> >> + addr = ea_entry & ~0x3;
> >> + if (ea_entry & 0x2) {
> >> + dm_pci_read_config32(dev, ea_off + 12, _entry);
> >> + addr |= (u64)ea_entry << 32;
> >> + }
> >> +
> >> + /* size ignored for now */
> >> + return map_physmem(addr, flags, 0);
> >> + }
> >
> > nits: should have one blank line here
> >
> >> + return 0;
> >> +}
> >> +
> >> void *dm_pci_map_bar(struct udevice *dev, int bar, int flags)
> >> {
> >> pci_addr_t pci_bus_addr;
> >> u32 bar_response;
> >>
> >> + /*
> >> +* if the function supports Enhanced Allocation use that instead of
> >> +* BARs
> >> +*/
> >> + if (dm_pci_find_capability(dev, PCI_CAP_ID_EA))
> >> + return dm_pci_map_ea_bar(dev, bar, flags);
> >> +
> >> /* read BAR address */
> >> dm_pci_read_config32(dev, bar, _response);
> >> pci_bus_addr = (pci_addr_t)(bar_response & ~0xf);
> >> diff --git a/include/pci.h b/include/pci.h
> >> index 508f7bca81..e1528bb257 100644
> >> --- a/include/pci.h
> >> +++ b/include/pci.h
> >> @@ -1314,7 +1314,7 @@ pci_addr_t dm_pci_phys_to_bus(struct udevice *dev,
> >> phys_addr_t addr,
> >>* @dev: Device to check
> >>* @bar: Bar number to read (numbered from 0)
> >
> > This one is confusing. It it not bar number (0/1/...), but bar
> > register offset. Suggest a separate patch to correct it. And this
> > function seems to only handle BAR0-BAR0 for header type 0. Please also
> > comment that.
>
> I suppose it works for BARs0-5 on type 0. I'm not clear if it also
> works for type 1
Re: [U-Boot] [PATCH 2/2 v2] test: dm: add MDIO test
Hi Alex,
On Mon, Jun 3, 2019 at 5:47 PM Alex Marginean wrote:
>
> A very simple test for DM_MDIO, mimicks a register write/read through the
> sandbox bus to a dummy PHY.
>
> Signed-off-by: Alex Marginean
> ---
>
> Changes in v2:
> - new patch, v1 didn't have a test included
>
> arch/sandbox/dts/test.dts | 4 ++
> configs/sandbox_defconfig | 2 +
> drivers/net/Kconfig| 10 +
> drivers/net/Makefile | 1 +
> drivers/net/mdio_sandbox.c | 92 ++
> test/dm/Makefile | 1 +
> test/dm/mdio.c | 48
> 7 files changed, 158 insertions(+)
> create mode 100644 drivers/net/mdio_sandbox.c
> create mode 100644 test/dm/mdio.c
>
Reviewed-by: Bin Meng
Tested-by: Bin Meng
However, please see some nits below.
> diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
> index 8b2d6451c6..70b7e4c275 100644
> --- a/arch/sandbox/dts/test.dts
> +++ b/arch/sandbox/dts/test.dts
> @@ -799,6 +799,10 @@
> dmas = < 0>, < 1>, < 2>;
> dma-names = "m2m", "tx0", "rx0";
> };
> +
> + mdio-test {
> + compatible = "sandbox,mdio_sandbox";
nits: it reads better if we had "sandbox,mdio"
> + };
> };
>
> #include "sandbox_pmic.dtsi"
> diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
> index 4877f1099a..2a00df9807 100644
> --- a/configs/sandbox_defconfig
> +++ b/configs/sandbox_defconfig
nits: I think we need update all sandbox defconfigs, or just update
arch/Kconfig and imply PHYLIB & DM_MDIO there.
> @@ -139,7 +139,9 @@ CONFIG_SPI_FLASH_SPANSION=y
> CONFIG_SPI_FLASH_STMICRO=y
> CONFIG_SPI_FLASH_SST=y
> CONFIG_SPI_FLASH_WINBOND=y
> +CONFIG_PHYLIB=y
> CONFIG_DM_ETH=y
> +CONFIG_DM_MDIO=y
> CONFIG_NVME=y
> CONFIG_PCI=y
> CONFIG_DM_PCI=y
> diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
> index 6fba5a84dd..635f8d72c2 100644
> --- a/drivers/net/Kconfig
> +++ b/drivers/net/Kconfig
> @@ -24,6 +24,16 @@ config DM_MDIO
> This is currently implemented in net/mdio-uclass.c
> Look in include/miiphy.h for details.
>
> +config MDIO_SANDBOX
> + depends on DM_MDIO && SANDBOX
> + default y
> + bool "Sandbox: Mocked MDIO driver"
> + help
> + This driver implements dummy read/write/reset MDIO functions
> mimicking
> + a bus with a single PHY.
> +
> + This driver is used in for testing in test/dm/mdio.c
> +
> menuconfig NETDEVICES
> bool "Network device support"
> depends on NET
> diff --git a/drivers/net/Makefile b/drivers/net/Makefile
> index 8d02a37896..40038427db 100644
> --- a/drivers/net/Makefile
> +++ b/drivers/net/Makefile
> @@ -77,3 +77,4 @@ obj-y += ti/
> obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
> obj-y += mscc_eswitch/
> obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
> +obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
> diff --git a/drivers/net/mdio_sandbox.c b/drivers/net/mdio_sandbox.c
> new file mode 100644
> index 00..d55a7c4466
> --- /dev/null
> +++ b/drivers/net/mdio_sandbox.c
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * (C) Copyright 2019
> + * Alex Marginean, NXP
> + */
> +
> +#include
> +#include
> +#include
> +
> +#define SANDBOX_PHY_ADDR 5
> +#define SANDBOX_PHY_REG0
> +
> +struct mdio_sandbox_priv {
> + int enabled;
> + u16 reg;
> +};
> +
> +static int mdio_sandbox_read(struct udevice *dev, int addr, int devad, int
> reg)
> +{
> + struct mdio_sandbox_priv *priv = dev_get_priv(dev);
> +
> + if (!priv->enabled)
> + return -ENODEV;
> +
> + if (addr != SANDBOX_PHY_ADDR)
> + return -ENODEV;
> + if (devad != MDIO_DEVAD_NONE)
> + return -ENODEV;
> + if (reg != SANDBOX_PHY_REG)
> + return -ENODEV;
> +
> + return priv->reg;
> +}
> +
> +static int mdio_sandbox_write(struct udevice *dev, int addr, int devad, int
> reg,
> + u16 val)
> +{
> + struct mdio_sandbox_priv *priv = dev_get_priv(dev);
> +
> + if (!priv->enabled)
> + return -ENODEV;
> +
> + if (addr != SANDBOX_PHY_ADDR)
> + return -ENODEV;
> + if (devad != MDIO_DEVAD_NONE)
> + return -ENODEV;
> + if (reg != SANDBOX_PHY_REG)
> + return -ENODEV;
> +
> + priv->reg = val;
> +
> + return 0;
> +}
> +
> +static int mdio_sandbox_reset(struct udevice *dev)
> +{
> + struct mdio_sandbox_priv *priv = dev_get_priv(dev);
> +
> + priv->reg = 0;
> +
> + return 0;
> +}
> +
> +static const struct mdio_ops mdio_sandbox_ops = {
> + .read = mdio_sandbox_read,
> + .write = mdio_sandbox_write,
> + .reset = mdio_sandbox_reset,
> +};
> +
> +int mdio_sandbox_probe(struct udevice *dev)
This should be static.
> +{
> + struct mdio_sandbox_priv *priv = dev_get_priv(dev);
> +
> +
Re: [U-Boot] [PATCH 1/2 v2] net: introduce MDIO DM class for MDIO devices
On Mon, Jun 3, 2019 at 5:47 PM Alex Marginean wrote: > > Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as > stand-alone devices. Useful in particular for systems that support > DM_ETH and have a stand-alone MDIO hardware block shared by multiple > Ethernet interfaces. > > Signed-off-by: Alex Marginean > --- > > Changes in v2: > - fixed several comments using wrong API names > - dropped dm_ from names of internal functions that don't use udevice > * > - fixed UCLASS driver name > - added missing mdio_unregister in dm_mdio_pre_remove > - added a comment on why spaces in names aren't ok > - added a comment on how static mdio_read/_write/_reset functions > are used > > cmd/mdio.c | 5 ++ > drivers/net/Kconfig| 13 + > include/dm/uclass-id.h | 1 + > include/miiphy.h | 49 ++ > net/Makefile | 1 + > net/mdio-uclass.c | 115 + > 6 files changed, 184 insertions(+) > create mode 100644 net/mdio-uclass.c > Reviewed-by: Bin Meng ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] drivers: pci: add map_bar support for Enhanced Allocation
Hi Bin,
On 6/2/2019 4:15 PM, Bin Meng wrote:
+Simon,
Hi Alex,
On Sat, Jun 1, 2019 at 12:26 AM Alex Marginean wrote:
Makes dm_pci_map_bar function available for integrated PCI devices that
support Enhanced Allocation instead of original PCI BAR mechanism.
Signed-off-by: Alex Marginean
---
drivers/pci/pci-uclass.c | 47
include/pci.h| 2 +-
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index cf1e7617ae..3204f156c3 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -1341,11 +1341,58 @@ pci_addr_t dm_pci_phys_to_bus(struct udevice *dev,
phys_addr_t phys_addr,
return bus_addr;
}
+static void *dm_pci_map_ea_bar(struct udevice *dev, int bar, int flags)
+{
+ int ea_off, ea_cnt, i, entry_size = 0;
nits: no need to initialize entry_size here.
+ int bar_id = bar - PCI_BASE_ADDRESS_0;
This does not work for anything other than BAR0. It should be (bar -
PCI_BASE_ADDRESS_0) >> 2;
Good find, you're right, I did use it only for BAR0 and missed this.
+ u32 ea_entry;
+ u64 addr;
This should be: pci_addr_t addr
I think maybe phys_addr_t is more appropriate, EA functions are supposed
to be integrated and their BAR equivalent addresses map into system
address space. In the end this goes to map_physmem, which takes a
phys_addr_t.
+
+ /* handle PCI functions that use Enhanced Allocation */
+ ea_off = dm_pci_find_capability(dev, PCI_CAP_ID_EA);
+
+ if (!ea_off)
+ return 0;
Above codes are not necessary. EA offset is already known when calling
dm_pci_map_ea_bar() from dm_pci_map_bar(). We can pass the offset to
this function.
+
+ /* EA capability structure header */
+ dm_pci_read_config32(dev, ea_off, _entry);
+ ea_cnt = (ea_entry >> 16) & 0x3f;
Avoid using magic numbers, instead use a macro PCI_EA_NUM_ENT_MASK. In
fact, Linux has several macros for EA capability
(include/uapi/linux/pci_regs.h) and we can just import these macros in
U-Boot too.
That's a good suggestion, I will do that.
+ ea_off += 4;
+
+ for (i = 0; i < ea_cnt; i++, ea_off += entry_size) {
nits: two spaces before entry_size
+ /* Entry header */
+ dm_pci_read_config32(dev, ea_off, _entry);
+ entry_size = (ea_entry & 0x7) * 4;
Per the spec, entry size is number of DW following the initial DW in
this entry. So it should really be: ((ea_entry & 0x7) + 1) * 4. Again
like the bar_id comments above, we can use << 2 here instead of * 4.
+
+ if (((ea_entry >> 4) & 0xf) != bar_id)
+ continue;
+
+ /* Base address, 1st DW */
+ dm_pci_read_config32(dev, ea_off + 4, _entry);
+ addr = ea_entry & ~0x3;
+ if (ea_entry & 0x2) {
+ dm_pci_read_config32(dev, ea_off + 12, _entry);
+ addr |= (u64)ea_entry << 32;
+ }
+
+ /* size ignored for now */
+ return map_physmem(addr, flags, 0);
+ }
nits: should have one blank line here
+ return 0;
+}
+
void *dm_pci_map_bar(struct udevice *dev, int bar, int flags)
{
pci_addr_t pci_bus_addr;
u32 bar_response;
+ /*
+* if the function supports Enhanced Allocation use that instead of
+* BARs
+*/
+ if (dm_pci_find_capability(dev, PCI_CAP_ID_EA))
+ return dm_pci_map_ea_bar(dev, bar, flags);
+
/* read BAR address */
dm_pci_read_config32(dev, bar, _response);
pci_bus_addr = (pci_addr_t)(bar_response & ~0xf);
diff --git a/include/pci.h b/include/pci.h
index 508f7bca81..e1528bb257 100644
--- a/include/pci.h
+++ b/include/pci.h
@@ -1314,7 +1314,7 @@ pci_addr_t dm_pci_phys_to_bus(struct udevice *dev,
phys_addr_t addr,
* @dev: Device to check
* @bar: Bar number to read (numbered from 0)
This one is confusing. It it not bar number (0/1/...), but bar
register offset. Suggest a separate patch to correct it. And this
function seems to only handle BAR0-BAR0 for header type 0. Please also
comment that.
I suppose it works for BARs0-5 on type 0. I'm not clear if it also
works for type 1 though, type 1 defines a couple of BARs at offset 0x10
too.
* @flags: Flags for the region type (PCI_REGION_...)
- * @return: pointer to the virtual address to use
+ * @return: pointer to the virtual address to use or 0 on error
This should be separate patch to correct the comments. Together with
the bar comments above.
*/
void *dm_pci_map_bar(struct udevice *dev, int bar, int flags);
Please create test cases in test/dm/pci.c to cover the EA capability
test. Especially since there are some bugs in the for loop in
dm_pci_map_ea_bar(), we should create case to get something like BAR3
instead of BAR0. I suspect why you
[U-Boot] [v5, 5/5] mmc: fsl_esdhc_imx: drop useless code
Dropped useless code for i.MX eSDHC driver.
Signed-off-by: Yangbo Lu
Tested-by: Steffen Dirkwinkel
Reviewed-by: Peng Fan
---
Changes for v2:
- Added this patch.
Changes for v3:
- None.
Changes for v4:
- Dropped PPC code introduced recently.
Changes for v5:
- Kept MCF5441x code.
---
drivers/mmc/fsl_esdhc_imx.c | 65 +++--
include/fsl_esdhc_imx.h | 4 ---
2 files changed, 4 insertions(+), 65 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc_imx.c b/drivers/mmc/fsl_esdhc_imx.c
index 1474e2c..2c0ad18 100644
--- a/drivers/mmc/fsl_esdhc_imx.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -261,8 +261,7 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
{
int timeout;
struct fsl_esdhc *regs = priv->esdhc_regs;
-#if defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \
- defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
+#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
dma_addr_t addr;
#endif
uint wml_value;
@@ -275,8 +274,7 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
esdhc_clrsetbits32(>wml, WML_RD_WML_MASK, wml_value);
#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
-#if defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \
- defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
+#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
addr = virt_to_phys((void *)(data->dest));
if (upper_32_bits(addr))
printf("Error found for upper 32 bits\n");
@@ -312,8 +310,7 @@ static int esdhc_setup_data(struct fsl_esdhc_priv *priv,
struct mmc *mmc,
esdhc_clrsetbits32(>wml, WML_WR_WML_MASK,
wml_value << 16);
#ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
-#if defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \
- defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
+#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
addr = virt_to_phys((void *)(data->src));
if (upper_32_bits(addr))
printf("Error found for upper 32 bits\n");
@@ -378,8 +375,7 @@ static void check_and_invalidate_dcache_range
unsigned end = 0;
unsigned size = roundup(ARCH_DMA_MINALIGN,
data->blocks*data->blocksize);
-#if defined(CONFIG_FSL_LAYERSCAPE) || defined(CONFIG_S32V234) || \
- defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
+#if defined(CONFIG_S32V234) || defined(CONFIG_IMX8) || defined(CONFIG_IMX8M)
dma_addr_t addr;
addr = virt_to_phys((void *)(data->dest));
@@ -1364,45 +1360,6 @@ int fsl_esdhc_mmc_init(bd_t *bis)
}
#endif
-#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
-void mmc_adapter_card_type_ident(void)
-{
- u8 card_id;
- u8 value;
-
- card_id = QIXIS_READ(present) & QIXIS_SDID_MASK;
- gd->arch.sdhc_adapter = card_id;
-
- switch (card_id) {
- case QIXIS_ESDHC_ADAPTER_TYPE_EMMC45:
- value = QIXIS_READ(brdcfg[5]);
- value |= (QIXIS_DAT4 | QIXIS_DAT5_6_7);
- QIXIS_WRITE(brdcfg[5], value);
- break;
- case QIXIS_ESDHC_ADAPTER_TYPE_SDMMC_LEGACY:
- value = QIXIS_READ(pwr_ctl[1]);
- value |= QIXIS_EVDD_BY_SDHC_VS;
- QIXIS_WRITE(pwr_ctl[1], value);
- break;
- case QIXIS_ESDHC_ADAPTER_TYPE_EMMC44:
- value = QIXIS_READ(brdcfg[5]);
- value |= (QIXIS_SDCLKIN | QIXIS_SDCLKOUT);
- QIXIS_WRITE(brdcfg[5], value);
- break;
- case QIXIS_ESDHC_ADAPTER_TYPE_RSV:
- break;
- case QIXIS_ESDHC_ADAPTER_TYPE_MMC:
- break;
- case QIXIS_ESDHC_ADAPTER_TYPE_SD:
- break;
- case QIXIS_ESDHC_NO_ADAPTER:
- break;
- default:
- break;
- }
-}
-#endif
-
#ifdef CONFIG_OF_LIBFDT
__weak int esdhc_status_fixup(void *blob, const char *compat)
{
@@ -1430,17 +1387,11 @@ void fdt_fixup_esdhc(void *blob, bd_t *bd)
do_fixup_by_compat_u32(blob, compat, "clock-frequency",
gd->arch.sdhc_clk, 1);
#endif
-#ifdef CONFIG_FSL_ESDHC_ADAPTER_IDENT
- do_fixup_by_compat_u32(blob, compat, "adapter-type",
- (u32)(gd->arch.sdhc_adapter), 1);
-#endif
}
#endif
#if CONFIG_IS_ENABLED(DM_MMC)
-#ifndef CONFIG_PPC
#include
-#endif
__weak void init_clk_usdhc(u32 index)
{
}
@@ -1465,11 +1416,7 @@ static int fsl_esdhc_probe(struct udevice *dev)
addr = dev_read_addr(dev);
if (addr == FDT_ADDR_T_NONE)
return -EINVAL;
-#ifdef CONFIG_PPC
- priv->esdhc_regs = (struct fsl_esdhc *)lower_32_bits(addr);
-#else
priv->esdhc_regs = (struct fsl_esdhc *)addr;
-#endif
priv->dev = dev;
[U-Boot] [PATCH v3] armv8: fsl-lsch2: add clock support for the second eSDHC
Layerscape began to use two eSDHC controllers, for example, LS1012A. They are same IP block with same reference clock. This patch is to add clock support for the second eSDHC. Signed-off-by: Yinbo Zhu --- Change in v2: Update the Copyright information Change in v3: Add "* Copyright 2019 NXP." arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c index 723d7eac5d..9ece4b90e6 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ /* * Copyright 2015 Freescale Semiconductor, Inc. + * Copyright 2019 NXP. */ #include @@ -250,6 +251,7 @@ unsigned int mxc_get_clock(enum mxc_clock clk) return get_i2c_freq(0); #if defined(CONFIG_FSL_ESDHC) case MXC_ESDHC_CLK: + case MXC_ESDHC2_CLK: return get_sdhc_freq(0); #endif case MXC_DSPI_CLK: -- 2.17.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [v5, 4/5] mmc: fsl_esdhc: drop i.MX code
Dropped i.MX code which couldn't be reused.
Signed-off-by: Yangbo Lu
Tested-by: Steffen Dirkwinkel
Acked-by: Peng Fan
---
Changes for v2:
- Added this patch.
Changes for v3:
- Rebased.
Changes for v4:
- Rebased.
- Added Tested-by/Acked-by.
Changes for v5:
- Dropped MCF5441x code.
---
drivers/mmc/fsl_esdhc.c | 626 ++--
include/fsl_esdhc.h | 57 -
2 files changed, 16 insertions(+), 667 deletions(-)
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc.c
index 672691f..65fc849 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc.c
@@ -16,14 +16,11 @@
#include
#include
#include
-#include
#include
#include
#include
#include
#include
-#include
-#include
DECLARE_GLOBAL_DATA_PTR;
@@ -33,8 +30,6 @@ DECLARE_GLOBAL_DATA_PTR;
IRQSTATEN_CIE | IRQSTATEN_DTOE | IRQSTATEN_DCE
| \
IRQSTATEN_DEBE | IRQSTATEN_BRR | IRQSTATEN_BWR
| \
IRQSTATEN_DINT)
-#define MAX_TUNING_LOOP 40
-
struct fsl_esdhc {
uintdsaddr; /* SDMA system address register */
uintblkattr;/* Block attributes register */
@@ -54,37 +49,20 @@ struct fsl_esdhc {
uintautoc12err; /* Auto CMD error status register */
uinthostcapblt; /* Host controller capabilities register */
uintwml;/* Watermark level register */
- uintmixctrl;/* For USDHC */
- charreserved1[4]; /* reserved */
+ charreserved1[8]; /* reserved */
uintfevt; /* Force event register */
uintadmaes; /* ADMA error status register */
uintadsaddr;/* ADMA system address register */
- charreserved2[4];
- uintdllctrl;
- uintdllstat;
- uintclktunectrlstatus;
- charreserved3[4];
- uintstrobe_dllctrl;
- uintstrobe_dllstat;
- charreserved4[72];
- uintvendorspec;
- uintmmcboot;
- uintvendorspec2;
- uinttuning_ctrl;/* on i.MX6/7/8 */
- charreserved5[44];
+ charreserved2[160];
uinthostver;/* Host controller version register */
- charreserved6[4]; /* reserved */
+ charreserved3[4]; /* reserved */
uintdmaerraddr; /* DMA error address register */
- charreserved7[4]; /* reserved */
+ charreserved4[4]; /* reserved */
uintdmaerrattr; /* DMA error attribute register */
- charreserved8[4]; /* reserved */
+ charreserved5[4]; /* reserved */
uinthostcapblt2;/* Host controller capabilities register 2 */
- charreserved9[8]; /* reserved */
- uinttcr;/* Tuning control register */
- charreserved10[28]; /* reserved */
- uintsddirctl; /* SD direction control register */
- charreserved11[712];/* reserved */
- uintscr;/* eSDHC control register */
+ charreserved6[756]; /* reserved */
+ uintesdhcctl; /* eSDHC control register */
};
struct fsl_esdhc_plat {
@@ -92,11 +70,6 @@ struct fsl_esdhc_plat {
struct mmc mmc;
};
-struct esdhc_soc_data {
- u32 flags;
- u32 caps;
-};
-
/**
* struct fsl_esdhc_priv
*
@@ -109,13 +82,6 @@ struct esdhc_soc_data {
* @dev: pointer for the device
* @non_removable: 0: removable; 1: non-removable
* @wp_enable: 1: enable checking wp; 0: no check
- * @vs18_enable: 1: use 1.8V voltage; 0: use 3.3V
- * @flags: ESDHC_FLAG_xx in include/fsl_esdhc.h
- * @caps: controller capabilities
- * @tuning_step: tuning step setting in tuning_ctrl register
- * @start_tuning_tap: the start point for tuning in tuning_ctrl register
- * @strobe_dll_delay_target: settings in strobe_dllctrl
- * @signal_voltage: indicating the current voltage
* @cd_gpio: gpio for card detection
* @wp_gpio: gpio for write protection
*/
@@ -124,7 +90,6 @@ struct fsl_esdhc_priv {
unsigned int sdhc_clk;
struct clk per_clk;
unsigned int clock;
- unsigned int mode;
unsigned int bus_width;
#if !CONFIG_IS_ENABLED(BLK)
struct mmc *mmc;
@@ -132,21 +97,6 @@ struct fsl_esdhc_priv {
struct udevice *dev;
int non_removable;
int wp_enable;
- int vs18_enable;
- u32 flags;
- u32 caps;
- u32 tuning_step;
- u32 tuning_start_tap;
- u32 strobe_dll_delay_target;
- u32 signal_voltage;
-#if IS_ENABLED(CONFIG_DM_REGULATOR)
- struct udevice *vqmmc_dev;
- struct udevice *vmmc_dev;
-#endif
-#ifdef CONFIG_DM_GPIO
- struct gpio_desc cd_gpio;
- struct gpio_desc wp_gpio;
-#endif
};
/* Return the XFERTYP flags for a given command and data packet */
@@ -258,8 +208,7 @@ static int
[U-Boot] [v5, 2/5] mmc: split fsl_esdhc driver for i.MX
The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX
initially. The later QoriQ series PowerPC processors (which were
evolutions of MPC83XX/MPC85XX), QorIQ series ARM processors, and
i.MX series processors were using this driver for their eSDHCs too.
For the two series processors, the eSDHCs are becoming more and
more different. We should have split it into two drivers, like them
(sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel.
This patch is just to create a fsl_esdhc_imx driver which is a copy
of fsl_esdhc driver for i.MX processors. We will convert i.MX processors
to use fsl_esdhc_imx, and clean up the two drivers separately in the
future patches.
Signed-off-by: Yangbo Lu
Tested-by: Steffen Dirkwinkel
Reviewed-by: Peng Fan
---
Changes for v2:
- None.
Changes for v3:
- None.
Changes for v4:
- Used "Enhanced Secure Digital Host" in Kconfig help.
- Moved copyright to top line and added my info.
- Added Tested-by/Reviewed-by.
Changes for v5:
- None.
---
drivers/mmc/Kconfig | 10 --
drivers/mmc/Makefile | 1 +
drivers/mmc/{fsl_esdhc.c => fsl_esdhc_imx.c} | 7 +--
include/{fsl_esdhc.h => fsl_esdhc_imx.h} | 13 -
4 files changed, 22 insertions(+), 9 deletions(-)
copy drivers/mmc/{fsl_esdhc.c => fsl_esdhc_imx.c} (99%)
copy include/{fsl_esdhc.h => fsl_esdhc_imx.h} (97%)
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index c23299e..9358872 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -668,8 +668,14 @@ config TEGRA124_MMC_DISABLE_EXT_LOOPBACK
config FSL_ESDHC
bool "Freescale/NXP eSDHC controller support"
help
- This selects support for the eSDHC (enhanced secure digital host
- controller) found on numerous Freescale/NXP SoCs.
+ This selects support for the eSDHC (Enhanced Secure Digital Host
+ Controller) found on numerous Freescale/NXP SoCs.
+
+config FSL_ESDHC_IMX
+ bool "Freescale/NXP i.MX eSDHC controller support"
+ help
+ This selects support for the i.MX eSDHC (Enhanced Secure Digital Host
+ Controller) found on numerous Freescale/NXP SoCs.
endmenu
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 0076fc3..3c8c53a 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MMC_DW_ROCKCHIP) += rockchip_dw_mmc.o
obj-$(CONFIG_MMC_DW_SOCFPGA) += socfpga_dw_mmc.o
obj-$(CONFIG_MMC_DW_SNPS) += snps_dw_mmc.o
obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
+obj-$(CONFIG_FSL_ESDHC_IMX) += fsl_esdhc_imx.o
obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o
obj-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o
obj-$(CONFIG_MMC_MESON_GX) += meson_gx_mmc.o
diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc_imx.c
similarity index 99%
copy from drivers/mmc/fsl_esdhc.c
copy to drivers/mmc/fsl_esdhc_imx.c
index 672691f..1474e2c 100644
--- a/drivers/mmc/fsl_esdhc.c
+++ b/drivers/mmc/fsl_esdhc_imx.c
@@ -1,5 +1,8 @@
// SPDX-License-Identifier: GPL-2.0+
/*
+ * Copyright 2019 NXP
+ * Yangbo Lu
+ *
* Copyright 2007, 2010-2011 Freescale Semiconductor, Inc
* Andy Fleming
*
@@ -18,7 +21,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include
@@ -110,7 +113,7 @@ struct esdhc_soc_data {
* @non_removable: 0: removable; 1: non-removable
* @wp_enable: 1: enable checking wp; 0: no check
* @vs18_enable: 1: use 1.8V voltage; 0: use 3.3V
- * @flags: ESDHC_FLAG_xx in include/fsl_esdhc.h
+ * @flags: ESDHC_FLAG_xx in include/fsl_esdhc_imx.h
* @caps: controller capabilities
* @tuning_step: tuning step setting in tuning_ctrl register
* @start_tuning_tap: the start point for tuning in tuning_ctrl register
diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc_imx.h
similarity index 97%
copy from include/fsl_esdhc.h
copy to include/fsl_esdhc_imx.h
index 8dbd524..67fd289 100644
--- a/include/fsl_esdhc.h
+++ b/include/fsl_esdhc_imx.h
@@ -3,11 +3,14 @@
* FSL SD/MMC Defines
*---
*
+ * Copyright 2019 NXP
+ * Yangbo Lu
+ *
* Copyright 2007-2008,2010-2011 Freescale Semiconductor, Inc
*/
-#ifndef __FSL_ESDHC_H__
-#define__FSL_ESDHC_H__
+#ifndef __FSL_ESDHC_IMX_H__
+#define __FSL_ESDHC_IMX_H__
#include
#include
@@ -258,15 +261,15 @@ struct fsl_esdhc_cfg {
#error "Endianess is not defined: please fix to continue"
#endif
-#ifdef CONFIG_FSL_ESDHC
+#ifdef CONFIG_FSL_ESDHC_IMX
int fsl_esdhc_mmc_init(bd_t *bis);
int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg);
void fdt_fixup_esdhc(void *blob, bd_t *bd);
#else
static inline int fsl_esdhc_mmc_init(bd_t *bis) { return -ENOSYS; }
static inline void fdt_fixup_esdhc(void *blob, bd_t *bd) {}
-#endif /* CONFIG_FSL_ESDHC */
+#endif /* CONFIG_FSL_ESDHC_IMX */
void __noreturn mmc_boot(void);
void mmc_spl_load_image(uint32_t offs,
[U-Boot] [v5, 1/5] Move CONFIG_FSL_ESDHC to defconfig
Moved CONFIG_FSL_ESDHC from header files to defconfig files. Signed-off-by: Yangbo Lu Tested-by: Steffen Dirkwinkel Reviewed-by: Peng Fan Reviewed-by: Lukasz Majewski Acked-by: Jason Liu --- Changes for v2: - Rebased. Changes for v3: - Rebased. Changes for v4: - Added Tested-by/Reviewed-by/Acked-by. Changes for v5: - None. --- configs/imx8mq_evk_defconfig | 1 + configs/imx8qm_mek_defconfig | 1 + configs/imx8qxp_mek_defconfig | 1 + configs/kp_imx6q_tpc_defconfig | 1 + configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 1 + configs/ls1012afrwy_qspi_defconfig | 1 + configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig | 1 + configs/ls1012afrwy_tfa_defconfig | 1 + include/configs/imx8mq_evk.h | 1 - include/configs/imx8qm_mek.h | 1 - include/configs/imx8qxp_mek.h | 1 - include/configs/kp_imx6q_tpc.h | 1 - include/configs/ls1012afrwy.h | 1 - 13 files changed, 8 insertions(+), 5 deletions(-) diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig index bc84a66..1c857bc 100644 --- a/configs/imx8mq_evk_defconfig +++ b/configs/imx8mq_evk_defconfig @@ -31,6 +31,7 @@ CONFIG_DM_GPIO=y CONFIG_DM_I2C=y CONFIG_SYS_I2C_MXC=y CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_DM_ETH=y CONFIG_PINCTRL=y diff --git a/configs/imx8qm_mek_defconfig b/configs/imx8qm_mek_defconfig index 1c67b98..f1155d6 100644 --- a/configs/imx8qm_mek_defconfig +++ b/configs/imx8qm_mek_defconfig @@ -52,6 +52,7 @@ CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PCA954x=y CONFIG_MISC=y CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y CONFIG_PHYLIB=y CONFIG_PHY_ADDR_ENABLE=y CONFIG_PHY_ATHEROS=y diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig index d735d34..1ce175e 100644 --- a/configs/imx8qxp_mek_defconfig +++ b/configs/imx8qxp_mek_defconfig @@ -55,6 +55,7 @@ CONFIG_I2C_MUX=y CONFIG_I2C_MUX_PCA954x=y CONFIG_MISC=y CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y CONFIG_SUPPORT_EMMC_BOOT=y CONFIG_PHYLIB=y CONFIG_PHY_ADDR_ENABLE=y diff --git a/configs/kp_imx6q_tpc_defconfig b/configs/kp_imx6q_tpc_defconfig index 0ca83cb..9b6ff4a 100644 --- a/configs/kp_imx6q_tpc_defconfig +++ b/configs/kp_imx6q_tpc_defconfig @@ -34,6 +34,7 @@ CONFIG_CMD_EXT4_WRITE=y # CONFIG_ISO_PARTITION is not set # CONFIG_EFI_PARTITION is not set CONFIG_ENV_IS_IN_MMC=y +CONFIG_FSL_ESDHC=y CONFIG_PHYLIB=y CONFIG_PHY_ATHEROS=y CONFIG_FEC_MXC=y diff --git a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig index bf98466..0360d9d 100644 --- a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig +++ b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig @@ -31,6 +31,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y diff --git a/configs/ls1012afrwy_qspi_defconfig b/configs/ls1012afrwy_qspi_defconfig index aa3256f..08eedec 100644 --- a/configs/ls1012afrwy_qspi_defconfig +++ b/configs/ls1012afrwy_qspi_defconfig @@ -32,6 +32,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y diff --git a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig index b0fdad6..2c3d893 100644 --- a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig +++ b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig @@ -31,6 +31,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y diff --git a/configs/ls1012afrwy_tfa_defconfig b/configs/ls1012afrwy_tfa_defconfig index 6a70f58..19aae5a 100644 --- a/configs/ls1012afrwy_tfa_defconfig +++ b/configs/ls1012afrwy_tfa_defconfig @@ -32,6 +32,7 @@ CONFIG_NET_RANDOM_ETHADDR=y CONFIG_DM=y CONFIG_SATA_CEVA=y CONFIG_DM_MMC=y +CONFIG_FSL_ESDHC=y CONFIG_DM_SPI_FLASH=y CONFIG_SPI_FLASH=y CONFIG_SPI_FLASH_WINBOND=y diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h index e4fa2df..16e4136 100644 --- a/include/configs/imx8mq_evk.h +++ b/include/configs/imx8mq_evk.h @@ -216,7 +216,6 @@ #define CONFIG_IMX_BOOTAUX #define CONFIG_CMD_MMC -#define CONFIG_FSL_ESDHC #define CONFIG_FSL_USDHC #define CONFIG_SYS_FSL_USDHC_NUM 2 diff --git a/include/configs/imx8qm_mek.h b/include/configs/imx8qm_mek.h index 2bdf3be..3679b48 100644 --- a/include/configs/imx8qm_mek.h +++ b/include/configs/imx8qm_mek.h @@ -47,7 +47,6 @@ #undef CONFIG_CMD_CRC32 #undef CONFIG_BOOTM_NETBSD -#define CONFIG_FSL_ESDHC #define CONFIG_FSL_USDHC #define CONFIG_SYS_FSL_ESDHC_ADDR 0 #define USDHC1_BASE_ADDR0x5B01 diff --git a/include/configs/imx8qxp_mek.h
[U-Boot] [v5, 0/5] Split fsl_esdhc driver for i.MX
The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX initially. The later QoriQ series PowerPC processors (which were evolutions of MPC83XX/MPC85XX), QorIQ series ARM processors, and i.MX series processors were using this driver for their eSDHCs too. For the two series processors, the eSDHCs are becoming more and more different. We should have split it into two drivers, like them (sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel. It's ideal to keep common part for reusing. However, it's hard to find out a little which could be reused. The truth is there will be more and more different registers, bits and operatiing processes. Even some code is common now, it may have to be split in the future. So let's just split is as two drivers. Patch #2 just created a fsl_esdhc_imx driver which was a copy of fsl_esdhc driver for i.MX processors. Patch #3 converted i.MX platforms to use fsl_esdhc_imx. Patch #4 and #5 just dropped useless code for the two driver. There are still many cleaning up works needed to be done in the future, because the eSDHC driver is mess for a long time. Since I'm only owner for QorIQ eSDHC driver, I dropped only a little things which I'm sure for fsl_esdhc_imx. Let i.MX eSDHC owner do futhur cleaning up. Yangbo Lu (5): Move CONFIG_FSL_ESDHC to defconfig mmc: split fsl_esdhc driver for i.MX Convert to use fsl_esdhc_imx for i.MX platforms mmc: fsl_esdhc: drop i.MX code mmc: fsl_esdhc_imx: drop useless code arch/arm/cpu/arm1136/mx35/generic.c | 10 +- arch/arm/cpu/arm926ejs/mx25/generic.c | 8 +- arch/arm/cpu/armv7/vf610/generic.c| 10 +- arch/arm/cpu/armv8/s32v234/generic.c | 2 +- arch/arm/include/asm/global_data.h| 2 +- arch/arm/mach-imx/cpu.c | 6 +- arch/arm/mach-imx/mx6/litesom.c | 4 +- arch/arm/mach-imx/mx7/clock.c | 4 +- arch/arm/mach-imx/mx7ulp/clock.c | 2 +- arch/arm/mach-imx/speed.c | 4 +- arch/m68k/cpu/mcf5445x/cpu_init.c | 2 +- board/advantech/dms-ba16/dms-ba16.c | 4 +- board/aristainetos/aristainetos-v1.c | 2 +- board/aristainetos/aristainetos-v2.c | 2 +- board/aristainetos/aristainetos.c | 4 +- board/bachmann/ot1200/ot1200.c| 2 +- board/barco/platinum/platinum.c | 2 +- board/barco/titanium/titanium.c | 4 +- board/boundary/nitrogen6x/nitrogen6x.c| 4 +- board/ccv/xpress/xpress.c | 2 +- board/compulab/cl-som-imx7/cl-som-imx7.c | 6 +- board/compulab/cl-som-imx7/common.c | 6 +- board/compulab/cl-som-imx7/common.h | 8 +- board/compulab/cl-som-imx7/mux.c | 8 +- board/compulab/cl-som-imx7/spl.c | 6 +- board/compulab/cm_fx6/cm_fx6.c| 4 +- board/compulab/cm_fx6/common.c| 4 +- board/compulab/cm_fx6/spl.c | 2 +- board/congatec/cgtqmx6eval/cgtqmx6eval.c | 4 +- board/dhelectronics/dh_imx6/dh_imx6.c | 4 +- board/dhelectronics/dh_imx6/dh_imx6_spl.c | 2 +- board/el/el6x/el6x.c | 4 +- board/embest/mx6boards/mx6boards.c| 4 +- board/freescale/imx8mq_evk/imx8mq_evk.c | 2 +- board/freescale/imx8mq_evk/spl.c | 2 +- board/freescale/imx8qxp_mek/imx8qxp_mek.c | 2 +- board/freescale/m54418twr/m54418twr.c | 2 +- board/freescale/mx25pdk/mx25pdk.c | 6 +- board/freescale/mx35pdk/mx35pdk.c | 4 +- board/freescale/mx51evk/mx51evk.c | 6 +- board/freescale/mx53ard/mx53ard.c | 4 +- board/freescale/mx53evk/mx53evk.c | 4 +- board/freescale/mx53loco/mx53loco.c | 4 +- board/freescale/mx53smd/mx53smd.c | 4 +- board/freescale/mx6qarm2/mx6qarm2.c | 4 +- board/freescale/mx6sabreauto/mx6sabreauto.c | 4 +- board/freescale/mx6sabresd/mx6sabresd.c | 4 +- board/freescale/mx6slevk/mx6slevk.c | 2 +- board/freescale/mx6sxsabreauto/mx6sxsabreauto.c | 2 +- board/freescale/mx6sxsabresd/mx6sxsabresd.c | 2 +- board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c | 4 +- board/freescale/mx6ullevk/mx6ullevk.c | 2 +- board/freescale/mx7dsabresd/mx7dsabresd.c | 2 +- board/freescale/s32v234evb/s32v234evb.c | 4 +- board/freescale/vf610twr/vf610twr.c | 4 +- board/gateworks/gw_ventana/common.c | 6 +- board/gateworks/gw_ventana/gw_ventana.c | 2 +- board/ge/bx50v3/bx50v3.c | 2 +- board/ge/mx53ppd/mx53ppd.c
Re: [U-Boot] [EXT] Re: [PATCH v2 1/5] spl: dm: disable SPI DM flash for non-DM SPL
> -Original Message- > From: Tom Rini > Sent: 2019年5月31日 3:43 > To: Chuanhua Han > Cc: ja...@openedev.com; w...@denx.de; Shengzhou Liu > ; Ruchika Gupta ; Pan > Jiafei ; u-boot@lists.denx.de; Jiafei Pan > ; Yinbo Zhu > Subject: Re: [EXT] Re: [U-Boot] [PATCH v2 1/5] spl: dm: disable SPI DM flash > for > non-DM SPL > > On Thu, May 30, 2019 at 10:45:10AM +, Chuanhua Han wrote: > > > > > > > -Original Message- > > > From: Tom Rini > > > Sent: 2019年5月24日 22:24 > > > To: Chuanhua Han > > > Cc: ja...@openedev.com; w...@denx.de; Shengzhou Liu > > > ; Ruchika Gupta ; Pan > > > Jiafei ; u-boot@lists.denx.de; Jiafei Pan > > > ; Yinbo Zhu > > > Subject: [EXT] Re: [U-Boot] [PATCH v2 1/5] spl: dm: disable SPI DM > > > flash for non-DM SPL > > > > > > On Fri, May 24, 2019 at 12:40:53PM +0800, Chuanhua Han wrote: > > > > > > > This patch solves the problem that spiboot cannot be performed in > > > > non-DM SPL. > > > > > > > > Signed-off-by: Pan Jiafei > > > > Signed-off-by: Chuanhua Han > > > > --- > > > > Changes in v2: > > > > - No change. > > > > > > > > include/config_uncmd_spl.h | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/include/config_uncmd_spl.h > > > > b/include/config_uncmd_spl.h index c2f9735ce7..da94b3d9df 100644 > > > > --- a/include/config_uncmd_spl.h > > > > +++ b/include/config_uncmd_spl.h > > > > @@ -15,6 +15,7 @@ > > > > #undef CONFIG_DM_GPIO > > > > #undef CONFIG_DM_I2C > > > > #undef CONFIG_DM_SPI > > > > +#undef CONFIG_DM_SPI_FLASH > > > > #endif > > > > > > > > #undef CONFIG_DM_WARN > > > > > > Long term, this shows places where we need CONFIG_SPL_DM_xxx and > > > code should be using CONFIG_IS_ENABLED(DM_xxx). Please update at > > > least the DM_SPI_FLASH case you're finding to behave like that, thanks! > > I don't understand you very much. Are you saying to modify the spi-flash > related code? > > Correct. include/config_uncmd_spl.h should be removed as there should, > long term, be no cases of code in SPL that we can / should exclude not > guarded by CONFIG_SPL_xxx instead. Do you mean include/config_uncmd_spl.h will be deleted in the future? Why did you start adding this file? > > -- > Tom ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI driver to driver model
> -Original Message- > From: Jagan Teki > Sent: 2019年5月23日 12:56 > To: Prabhakar Kushwaha > Cc: Chuanhua Han ; U-Boot-Denx > ; Jiafei Pan ; Jagan Teki > ; Yinbo Zhu ; Ruchika Gupta > > Subject: Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert Freescale ESPI > driver to driver model > > Caution: EXT Email > > On Thu, May 23, 2019 at 10:22 AM Prabhakar Kushwaha > wrote: > > > > > > > -Original Message- > > > From: U-Boot On Behalf Of Jagan Teki > > > Sent: Thursday, May 23, 2019 10:06 AM > > > To: Chuanhua Han > > > Cc: U-Boot-Denx ; Jiafei Pan > > > ; Jagan Teki ; Yinbo Zhu > > > ; Ruchika Gupta > > > Subject: Re: [U-Boot] [EXT] Re: [PATCH 2/5] dm: spi: Convert > > > Freescale ESPI driver to driver model > > > > > > On Mon, May 6, 2019 at 1:38 PM Chuanhua Han > > > > wrote: > > > > > > > > > > > > > > > > > -Original Message- > > > > > From: Jagan Teki > > > > > Sent: 2019年5月6日 15:03 > > > > > To: Chuanhua Han > > > > > Cc: Jagan Teki ; Wolfgang Denk ; > > > > > Shengzhou Liu ; Ruchika Gupta > > > > > ; U-Boot-Denx ; > > > > > Jiafei Pan ; Yinbo Zhu > > > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > Freescale ESPI driver to driver model > > > > > > > > > > Caution: EXT Email > > > > > > > > > > On Mon, May 6, 2019 at 12:29 PM Chuanhua Han > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Jagan Teki > > > > > > > Sent: 2019年4月26日 2:07 > > > > > > > To: Chuanhua Han > > > > > > > Cc: Jagan Teki ; Wolfgang Denk > > > > > > > ; Shengzhou Liu ; Ruchika > > > > > > > Gupta ; U-Boot-Denx > > > > > > > ; Jiafei Pan ; > > > > > > > Yinbo Zhu > > > > > > > Subject: Re: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > > > Freescale ESPI driver to driver model > > > > > > > > > > > > > > Caution: EXT Email > > > > > > > > > > > > > > On Thu, Apr 25, 2019 at 8:27 AM Chuanhua Han > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > Hi,jagan > > > > > > > > Thank you for your replay! > > > > > > > > > > > > > > > > > -Original Message- > > > > > > > > > From: Jagan Teki > > > > > > > > > Sent: 2019年4月24日 14:57 > > > > > > > > > To: Chuanhua Han > > > > > > > > > Cc: Jagan Teki ; Wolfgang Denk > > > > > > > > > ; Shengzhou Liu ; > > > > > > > > > Ruchika Gupta ; U-Boot-Denx > > > > > > > > > ; Jiafei Pan ; > > > > > > > > > Yinbo Zhu > > > > > > > > > Subject: [EXT] Re: [U-Boot] [PATCH 2/5] dm: spi: Convert > > > > > > > > > Freescale ESPI driver to driver model > > > > > > > > > > > > > > > > > > WARNING: This email was created outside of NXP. DO NOT > > > > > > > > > CLICK links or attachments unless you recognize the > > > > > > > > > sender and know the content is > > > > > > > safe. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Apr 23, 2019 at 4:17 PM Chuanhua Han > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > Modify the Freescale ESPI driver to support the driver > > > > > > > > > > model. > > > > > > > > > > Also resolved the following problems: > > > > > > > > > > > > > > > > > > > > = WARNING == > > > This > > > > > > > > > > board > > > > > > > > > does > > > > > > > > > > not use CONFIG_DM_SPI. Please update the board before > > > > > > > > > > v2019.04 for no dm conversion and v2019.07 for > > > > > > > > > > partially dm > > > converted drivers. > > > > > > > > > > Failure to update can lead to driver/board removal See > > > > > > > > > > doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > > > > > > = WARNING == > > > This > > > > > > > > > > board > > > > > > > > > does > > > > > > > > > > not use CONFIG_DM_SPI_FLASH. Please update the board > > > > > > > > > > to use CONFIG_SPI_FLASH before the v2019.07 release. > > > > > > > > > > Failure to update by the deadline may result in board > > > > > > > > > > removal. > > > > > > > > > > See doc/driver-model/MIGRATION.txt for more info. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Chuanhua Han > > > > > > > > > > --- > > > > > > > > > > depends on: > > > > > > > > > > - > > > > > > > > > > https://eur01.safelinks.protection.outlook.com/?url=ht > > > > > > > > > > tps% > > > > > > > > > > 3A%2 > > > > > > > > > > F%2F > > > > > > > > > > patc > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99439d > > > > > > > > > ata > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =02%7C01%7Cchuanhua.han%40nxp.com%7Cfa6bdd7859c4411b5d8608d6c8 > > > > > > > > > 8223e3%7 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63691685860819371 >
[U-Boot] [PATCH 2/2 v2] test: dm: add MDIO test
A very simple test for DM_MDIO, mimicks a register write/read through the
sandbox bus to a dummy PHY.
Signed-off-by: Alex Marginean
---
Changes in v2:
- new patch, v1 didn't have a test included
arch/sandbox/dts/test.dts | 4 ++
configs/sandbox_defconfig | 2 +
drivers/net/Kconfig| 10 +
drivers/net/Makefile | 1 +
drivers/net/mdio_sandbox.c | 92 ++
test/dm/Makefile | 1 +
test/dm/mdio.c | 48
7 files changed, 158 insertions(+)
create mode 100644 drivers/net/mdio_sandbox.c
create mode 100644 test/dm/mdio.c
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8b2d6451c6..70b7e4c275 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -799,6 +799,10 @@
dmas = < 0>, < 1>, < 2>;
dma-names = "m2m", "tx0", "rx0";
};
+
+ mdio-test {
+ compatible = "sandbox,mdio_sandbox";
+ };
};
#include "sandbox_pmic.dtsi"
diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 4877f1099a..2a00df9807 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -139,7 +139,9 @@ CONFIG_SPI_FLASH_SPANSION=y
CONFIG_SPI_FLASH_STMICRO=y
CONFIG_SPI_FLASH_SST=y
CONFIG_SPI_FLASH_WINBOND=y
+CONFIG_PHYLIB=y
CONFIG_DM_ETH=y
+CONFIG_DM_MDIO=y
CONFIG_NVME=y
CONFIG_PCI=y
CONFIG_DM_PCI=y
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index 6fba5a84dd..635f8d72c2 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -24,6 +24,16 @@ config DM_MDIO
This is currently implemented in net/mdio-uclass.c
Look in include/miiphy.h for details.
+config MDIO_SANDBOX
+ depends on DM_MDIO && SANDBOX
+ default y
+ bool "Sandbox: Mocked MDIO driver"
+ help
+ This driver implements dummy read/write/reset MDIO functions mimicking
+ a bus with a single PHY.
+
+ This driver is used in for testing in test/dm/mdio.c
+
menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index 8d02a37896..40038427db 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -77,3 +77,4 @@ obj-y += ti/
obj-$(CONFIG_MEDIATEK_ETH) += mtk_eth.o
obj-y += mscc_eswitch/
obj-$(CONFIG_HIGMACV300_ETH) += higmacv300.o
+obj-$(CONFIG_MDIO_SANDBOX) += mdio_sandbox.o
diff --git a/drivers/net/mdio_sandbox.c b/drivers/net/mdio_sandbox.c
new file mode 100644
index 00..d55a7c4466
--- /dev/null
+++ b/drivers/net/mdio_sandbox.c
@@ -0,0 +1,92 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * (C) Copyright 2019
+ * Alex Marginean, NXP
+ */
+
+#include
+#include
+#include
+
+#define SANDBOX_PHY_ADDR 5
+#define SANDBOX_PHY_REG0
+
+struct mdio_sandbox_priv {
+ int enabled;
+ u16 reg;
+};
+
+static int mdio_sandbox_read(struct udevice *dev, int addr, int devad, int reg)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ if (!priv->enabled)
+ return -ENODEV;
+
+ if (addr != SANDBOX_PHY_ADDR)
+ return -ENODEV;
+ if (devad != MDIO_DEVAD_NONE)
+ return -ENODEV;
+ if (reg != SANDBOX_PHY_REG)
+ return -ENODEV;
+
+ return priv->reg;
+}
+
+static int mdio_sandbox_write(struct udevice *dev, int addr, int devad, int
reg,
+ u16 val)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ if (!priv->enabled)
+ return -ENODEV;
+
+ if (addr != SANDBOX_PHY_ADDR)
+ return -ENODEV;
+ if (devad != MDIO_DEVAD_NONE)
+ return -ENODEV;
+ if (reg != SANDBOX_PHY_REG)
+ return -ENODEV;
+
+ priv->reg = val;
+
+ return 0;
+}
+
+static int mdio_sandbox_reset(struct udevice *dev)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ priv->reg = 0;
+
+ return 0;
+}
+
+static const struct mdio_ops mdio_sandbox_ops = {
+ .read = mdio_sandbox_read,
+ .write = mdio_sandbox_write,
+ .reset = mdio_sandbox_reset,
+};
+
+int mdio_sandbox_probe(struct udevice *dev)
+{
+ struct mdio_sandbox_priv *priv = dev_get_priv(dev);
+
+ priv->enabled = 1;
+
+ return 0;
+}
+
+static const struct udevice_id mdio_sandbox_ids[] = {
+ { .compatible = "sandbox,mdio_sandbox" },
+ { }
+};
+
+U_BOOT_DRIVER(mdio_sandbox) = {
+ .name = "mdio_sandbox",
+ .id = UCLASS_MDIO,
+ .of_match = mdio_sandbox_ids,
+ .probe = mdio_sandbox_probe,
+ .ops= _sandbox_ops,
+ .priv_auto_alloc_size = sizeof(struct mdio_sandbox_priv),
+};
diff --git a/test/dm/Makefile b/test/dm/Makefile
index 49857c5092..3f042e3ab4 100644
--- a/test/dm/Makefile
+++ b/test/dm/Makefile
@@ -60,4 +60,5 @@ obj-$(CONFIG_SOUND) += sound.o
[U-Boot] [PATCH 1/2 v2] net: introduce MDIO DM class for MDIO devices
Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as
stand-alone devices. Useful in particular for systems that support
DM_ETH and have a stand-alone MDIO hardware block shared by multiple
Ethernet interfaces.
Signed-off-by: Alex Marginean
---
Changes in v2:
- fixed several comments using wrong API names
- dropped dm_ from names of internal functions that don't use udevice *
- fixed UCLASS driver name
- added missing mdio_unregister in dm_mdio_pre_remove
- added a comment on why spaces in names aren't ok
- added a comment on how static mdio_read/_write/_reset functions
are used
cmd/mdio.c | 5 ++
drivers/net/Kconfig| 13 +
include/dm/uclass-id.h | 1 +
include/miiphy.h | 49 ++
net/Makefile | 1 +
net/mdio-uclass.c | 115 +
6 files changed, 184 insertions(+)
create mode 100644 net/mdio-uclass.c
diff --git a/cmd/mdio.c b/cmd/mdio.c
index 5e219f699d..a6fa9266d0 100644
--- a/cmd/mdio.c
+++ b/cmd/mdio.c
@@ -203,6 +203,11 @@ static int do_mdio(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
if (argc < 2)
return CMD_RET_USAGE;
+#ifdef CONFIG_DM_MDIO
+ /* probe DM MII device before any operation so they are all accesible */
+ dm_mdio_probe_devices();
+#endif
+
/*
* We use the last specified parameters, unless new ones are
* entered.
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index e6a4fdf30e..6fba5a84dd 100644
--- a/drivers/net/Kconfig
+++ b/drivers/net/Kconfig
@@ -11,6 +11,19 @@ config DM_ETH
This is currently implemented in net/eth-uclass.c
Look in include/net.h for details.
+config DM_MDIO
+ bool "Enable Driver Model for MDIO devices"
+ depends on DM_ETH && PHYLIB
+ help
+ Enable driver model for MDIO devices
+
+ Adds UCLASS_MDIO DM class supporting MDIO buses that are probed as
+ stand-alone devices. Useful in particular for systems that support
+ DM_ETH and have a stand-alone MDIO hardware block shared by multiple
+ Ethernet interfaces.
+ This is currently implemented in net/mdio-uclass.c
+ Look in include/miiphy.h for details.
+
menuconfig NETDEVICES
bool "Network device support"
depends on NET
diff --git a/include/dm/uclass-id.h b/include/dm/uclass-id.h
index 09e0ad5391..90667e62cf 100644
--- a/include/dm/uclass-id.h
+++ b/include/dm/uclass-id.h
@@ -58,6 +58,7 @@ enum uclass_id {
UCLASS_LPC, /* x86 'low pin count' interface */
UCLASS_MAILBOX, /* Mailbox controller */
UCLASS_MASS_STORAGE,/* Mass storage device */
+ UCLASS_MDIO,/* MDIO bus */
UCLASS_MISC,/* Miscellaneous device */
UCLASS_MMC, /* SD / MMC card or chip */
UCLASS_MOD_EXP, /* RSA Mod Exp device */
diff --git a/include/miiphy.h b/include/miiphy.h
index f11763affd..e6dd441983 100644
--- a/include/miiphy.h
+++ b/include/miiphy.h
@@ -118,4 +118,53 @@ int bb_miiphy_write(struct mii_dev *miidev, int addr, int
devad, int reg,
#define ESTATUS_1000XF 0x8000
#define ESTATUS_1000XH 0x4000
+#ifdef CONFIG_DM_MDIO
+
+/**
+ * struct mdio_perdev_priv - Per-device class data for MDIO DM
+ *
+ * @mii_bus: Supporting MII legacy bus
+ */
+struct mdio_perdev_priv {
+ struct mii_dev *mii_bus;
+};
+
+/**
+ * struct mdio_ops - MDIO bus operations
+ *
+ * @read: Read from a PHY register
+ * @write: Write to a PHY register
+ * @reset: Reset the MDIO bus, NULL if not supported
+ */
+struct mdio_ops {
+ int (*read)(struct udevice *mdio_dev, int addr, int devad, int reg);
+ int (*write)(struct udevice *mdio_dev, int addr, int devad, int reg,
+u16 val);
+ int (*reset)(struct udevice *mdio_dev);
+};
+
+#define mdio_get_ops(dev) ((struct mdio_ops *)(dev)->driver->ops)
+
+/**
+ * dm_mdio_probe_devices - Call probe on all MII devices, currently used for
+ * MDIO console commands.
+ */
+void dm_mdio_probe_devices(void);
+
+/**
+ * dm_mdio_phy_connect - Wrapper over phy_connect for DM MDIO
+ *
+ * @dev: mdio dev
+ * @addr: PHY address on MDIO bus
+ * @ethdev: ethernet device to connect to the PHY
+ * @interface: MAC-PHY protocol
+ *
+ * @return pointer to phy_device, or 0 on error
+ */
+struct phy_device *dm_mdio_phy_connect(struct udevice *dev, int addr,
+ struct udevice *ethdev,
+ phy_interface_t interface);
+
+#endif
+
#endif
diff --git a/net/Makefile b/net/Makefile
index ce36362168..6251ff3991 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -15,6 +15,7 @@ obj-$(CONFIG_NET) += eth-uclass.o
else
obj-$(CONFIG_NET) += eth_legacy.o
endif
+obj-$(CONFIG_DM_MDIO) += mdio-uclass.o
obj-$(CONFIG_NET) += eth_common.o
[U-Boot] Question about cfi flash driver can not work well in cacheable region !
Hi Stefan and other seniors I encounter some problems about cfi flash driver. And hope you can give some comments to resolve it. Followings are the flash verification status and descriptions : When I verify cfi flash which it's address base is in cacheable region (0x8800) and cache is enabled in system. The flash detection, write and erase action will be failure somehow. The failure messages will be as below: # # Detection failure # # Flash: ## Unknown flash on Bank 1 - Size = 0x = 0 MB 0 Bytes ### # Erase fail # ### protect off all; erase 0x8800 0x8bff; Error: start and/or end address not on sector boundary RISC-V # ### # Write fail # ### RISC-V # cp.b 0x2000 0x8bf0 0x1444 RISC-V # But when I disable cache in system, they will all pass the verification. # Detection pass # Flash: 64 MiB # # erase pass # # protect off all; erase 0x8800 0x8bff; Un-Protect Flash Bank # 1 done Erased 512 sectors RISC-V # ## # write pass # ## RISC-V # cp.b 0x2000 0x8bf0 0x1444 Copy to Flash... done RISC-V # How can I enable cache and let cfi flash can work fine to get better performance ? Do you have any comments ? Thanks Rick ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: davinci_emac: convert to using the driver model
sob., 1 cze 2019 o 05:24 Adam Ford napisał(a):
>
> On Fri, May 31, 2019 at 8:32 AM Bartosz Golaszewski wrote:
> >
> > From: Bartosz Golaszewski
> >
> > Now that we removed all legacy boards selecting TI_EMAC we can
> > completely convert the driver code to using the driver model.
> > This patch also updates all remaining users of davinci_emac.
> >
>
> I took a break from this to come back, and I'm going to give some
> feedback about how the driver was written. I still do not know why I
> cannot get an IP address with this patch on the AM3517-evm.
>
Hi Adam,
thanks for all the testing. Unfortunately I can only test with
da850-evm and da850-lcdk.
I was wondering if it is possible that the problem is caused by
cpu_eth_init() from ./arch/arm/mach-omap2/omap3/emac. not being called
with CONFIG_DM_ETH? The comments say that it brings the module out of
reset, so maybe this is what causes the problem you're seeing?
> > Signed-off-by: Bartosz Golaszewski
> > ---
> > arch/arm/mach-davinci/cpu.c| 13 -
> > arch/arm/mach-omap2/omap3/emac.c | 3 +-
> > board/davinci/da8xxevm/da850evm.c | 6 --
> > board/davinci/da8xxevm/omapl138_lcdk.c | 14 -
> > board/logicpd/am3517evm/am3517evm.c| 1 -
> > board/ti/ti816x/evm.c | 3 +-
> > configs/am3517_evm_defconfig | 1 +
> > configs/da850evm_defconfig | 1 +
> > configs/da850evm_direct_nor_defconfig | 1 +
> > configs/da850evm_nand_defconfig| 1 +
> > configs/omapl138_lcdk_defconfig| 1 +
> > configs/ti816x_evm_defconfig | 1 +
> > drivers/net/ti/davinci_emac.c | 77 ++
> > include/netdev.h | 1 -
> > 14 files changed, 51 insertions(+), 73 deletions(-)
> >
> > diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
> > index f97ad3fc74..9fd6564d04 100644
> > --- a/arch/arm/mach-davinci/cpu.c
> > +++ b/arch/arm/mach-davinci/cpu.c
> > @@ -5,7 +5,6 @@
> > */
> >
> > #include
> > -#include
> > #include
> > #include
> >
> > @@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
> > gd->bd->bi_dsp_freq = 0;
> > return 0;
> > }
> > -
> > -/*
> > - * Initializes on-chip ethernet controllers.
> > - * to override, implement board_eth_init()
> > - */
> > -int cpu_eth_init(bd_t *bis)
> > -{
> > -#if defined(CONFIG_DRIVER_TI_EMAC)
> > - davinci_emac_initialize();
> > -#endif
> > - return 0;
> > -}
> > diff --git a/arch/arm/mach-omap2/omap3/emac.c
> > b/arch/arm/mach-omap2/omap3/emac.c
> > index c79e870183..fb0c9188f5 100644
> > --- a/arch/arm/mach-omap2/omap3/emac.c
> > +++ b/arch/arm/mach-omap2/omap3/emac.c
> > @@ -7,7 +7,6 @@
> > */
> >
> > #include
> > -#include
> > #include
> > #include
> >
> > @@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis)
> > reset &= ~CPGMACSS_SW_RST;
> > writel(reset, _scm_general_regs->ip_sw_reset);
> >
> > - return davinci_emac_initialize();
> > + return 0;
> > }
> > diff --git a/board/davinci/da8xxevm/da850evm.c
> > b/board/davinci/da8xxevm/da850evm.c
> > index 1bc26828bf..d090c00466 100644
> > --- a/board/davinci/da8xxevm/da850evm.c
> > +++ b/board/davinci/da8xxevm/da850evm.c
> > @@ -13,7 +13,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -472,11 +471,6 @@ int board_eth_init(bd_t *bis)
> > if (rmii_hw_init())
> > printf("RMII hardware init failed!!!\n");
> > #endif
> > - if (!davinci_emac_initialize()) {
> > - printf("Error: Ethernet init failed!\n");
> > - return -1;
> > - }
> > -
> > return 0;
> > }
> > #endif /* CONFIG_DRIVER_TI_EMAC */
> > diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c
> > b/board/davinci/da8xxevm/omapl138_lcdk.c
> > index 2c2f885d43..ef9656add8 100644
> > --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> > +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> > @@ -11,7 +11,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -229,19 +228,6 @@ int board_init(void)
> >
> > #ifdef CONFIG_DRIVER_TI_EMAC
> >
> > -/*
> > - * Initializes on-board ethernet controllers.
> > - */
> > -int board_eth_init(bd_t *bis)
> > -{
> > - if (!davinci_emac_initialize()) {
> > - printf("Error: Ethernet init failed!\n");
> > - return -1;
> > - }
> > -
> > - return 0;
> > -}
> > -
> > #endif /* CONFIG_DRIVER_TI_EMAC */
> >
> > #define CFG_MAC_ADDR_SPI_BUS 0
> > diff --git a/board/logicpd/am3517evm/am3517evm.c
> > b/board/logicpd/am3517evm/am3517evm.c
> > index 10031a4801..bfd4e78274 100644
> > --- a/board/logicpd/am3517evm/am3517evm.c
> > +++ b/board/logicpd/am3517evm/am3517evm.c
> > @@ -28,7 +28,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include "am3517evm.h"
> >
> > DECLARE_GLOBAL_DATA_PTR;
> > diff --git
Re: [U-Boot] [PATCH] arm: mvebu: helios4: add MMC to SPL DT
On 29.05.19 16:36, dgilm...@redhat.com wrote: From: Dennis Gilmore This allows SPL to load the main U-Boot image from MMC once DM_MMC is enabled. Signed-off-by: Dennis Gilmore Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
