Re: [U-Boot] [PATCH v1 0/3] Enable PSCI services for booting Linux
On 5/9/19 7:52 AM, Ang, Chee Hong wrote: > On Mon, 2019-05-06 at 22:20 -0700, chee.hong@intel.com wrote: >> From: "Ang, Chee Hong" >> >> Add "SYTEM_RESET" (cold reset) and "CPU_ON" (SMP) PSCI support >> for booting Linux on Stratix 10 platform. >> >> Ang, Chee Hong (3): >> ARM: socfpga: stratix10: Enable PSCI system reset >> ARM: socfpga: stratix10: Enable PSCI CPU_ON >> ARM: socfpga: stratix10: Enable PSCI support for Stratix 10 >> >> arch/arm/mach-socfpga/Kconfig | 9 ++- >> arch/arm/mach-socfpga/Makefile | 3 +++ >> arch/arm/mach-socfpga/psci.c | 56 >> ++ >> 3 files changed, 67 insertions(+), 1 deletion(-) >> create mode 100644 arch/arm/mach-socfpga/psci.c >> > Hi Marek, > > Any comment on this ? These PSCI patches are needed for booting Linux > on our S10 platform. Same questions as in Re: [PATCH v1 0/3] Enable HPS execution stage notification , can we stop adding more and more stuff to arch/ and instead add it to drivers/ ? As you might have noticed, we are trying to remove stuff from arch/ and move as much as possible to drivers/ , but S10 is doing the exact opposite :( -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Hi, On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > (Sorry for the noice, I have missed to send two patches from v7) > > This is v7 resend patchset for New rk3399 boards support wrt previous > version[1] > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > orangepi rk3399 changes are merged, so this is rework on top of > u-boot-rockchip/master. > > Overall this series add support below rk3399 boards > - NanoPI M4 > - NanoPC T4 > - NanoPI NEO4 > - Orangepi RK3399 > - Rock PI 4 > - Rockpro64 > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > dts(i) from linux-next. > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > series [3]. > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > booting via Rockchip miniloader as of now. Could you send these two boards in a separate series so that we avoid merging them for now (because SPL support is broken) and then re- iterate the series later with the DDR bringup? Or maybe find a way to disable SPL support, but in any case, it's not ok to merge a board with SPL enabled and broken. Cheers, Paul > For booting the same with SPL NEO4 would require dynamic dram timing > detection and rest require LPDDR4 code. There is WIP[2] for these > dependencies and this would require big chunk of changes will effect > all the rk3399 boards, so I'm planning to mark it for next MW. > > Changes for v7: > - rebase on top of u-boot-rockchip/master > - add SPL_TEXT_BASE on each board defconfig > - rebase on required changes > Changes for v6: > - Include Nanopc T4 support patch > - drop rk3399-u-boot.dtsi patch since it is send separately. > Changes for v5: > - Make all changes related to move sdmmc, spi1 u-boot,dm-pre-reloc > properties into all rk3399 dts(i) files. > Changes for v4: > - don't include existing dts(i) sdmmc, u-boot,dm-pre-reloc into > rk3399-u-boot.dtsi > Changes for v3: > - drop NanoPC T4 for now, since board is yet to receive. > - add Rock PI-4 board. > - add separate -u-boot.dtsi file for nanopi4 sdram changes. > - collect Paul, Philipp and Kever Reviewed-by tags > > Travis-CI: > https://travis-ci.org/openedev/u-boot-amarula/builds/529284236 > > [1] https://patchwork.ozlabs.org/cover/1096473/ > [2] https://github.com/amarula/u-boot-amarula/tree/rockdev-lpddr4 > [3] https://patchwork.ozlabs.org/cover/1091909/ > > Any inputs? > Jagan. > > Jagan Teki (11): > rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2 > Kconfig: Add default SPL_FIT_GENERATOR for rockchip > arm: rockchip: rk3399: Move common configs in Kconfig > rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux > rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1 > rockchip: rk3399: Add Nanopi M4 board support > rockchip: rk3399: Add Nanopc T4 board support > rockchip: rk3399: Add Nanopi NEO4 board support > rockchip: rk3399: Add Rockpro64 board support > rockchip: rk3399: Add Rock PI 4 support > doc: rockchip: Add global doc for rk3399 build/flash > > Kconfig | 1 + > arch/arm/dts/Makefile | 5 + > arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi | 7 + > arch/arm/dts/rk3399-nanopc-t4.dts | 91 +++ > arch/arm/dts/rk3399-nanopi-m4-u-boot.dtsi | 7 + > arch/arm/dts/rk3399-nanopi-m4.dts | 66 ++ > arch/arm/dts/rk3399-nanopi-neo4-u-boot.dtsi | 6 + > arch/arm/dts/rk3399-nanopi-neo4.dts | 50 ++ > arch/arm/dts/rk3399-nanopi4-u-boot.dtsi | 11 + > arch/arm/dts/rk3399-nanopi4.dtsi| 703 +++ > arch/arm/dts/rk3399-rock-pi-4-u-boot.dtsi | 6 + > arch/arm/dts/rk3399-rock-pi-4.dts | 606 + > arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 6 + > arch/arm/dts/rk3399-rockpro64.dts | 712 > arch/arm/dts/rk3399.dtsi| 5 + > arch/arm/mach-rockchip/Kconfig | 16 + > board/rockchip/evb_rk3399/MAINTAINERS | 32 + > configs/chromebook_bob_defconfig| 17 - > configs/evb-rk3399_defconfig| 17 - > configs/ficus-rk3399_defconfig | 17 - > configs/firefly-rk3399_defconfig| 17 - > configs/nanopc-t4-rk3399_defconfig | 59 ++ > configs/nanopi-m4-rk3399_defconfig | 59 ++ > configs/nanopi-neo4-rk3399_defconfig| 59 ++ > configs/orangepi-rk3399_defconfig | 17 - > configs/puma-rk3399_defconfig | 16 - > configs/rock-pi-4-rk3399_defconfig | 59 ++ > configs/rock960-rk3399_defconfig| 17 - > configs/rockpro64-rk3399_defconfig | 59 ++ > doc/README.rockchip | 233 ++- > 30 files changed, 2857 insertions(+), 119 deletions(-) > create mode 100644 arch/arm/dts/rk3399-nanopc-t4-u-boot.dtsi > create mode 100644 arch/arm/dts/rk3399-nanopc-t4.dts > create mode 100644 arch/arm/dts/rk33
Re: [U-Boot] [PATCH v1 0/3] Enable PSCI services for booting Linux
On Thu, 2019-05-09 at 08:59 +0200, Marek Vasut wrote: > On 5/9/19 7:52 AM, Ang, Chee Hong wrote: > > > > On Mon, 2019-05-06 at 22:20 -0700, chee.hong@intel.com wrote: > > > > > > From: "Ang, Chee Hong" > > > > > > Add "SYTEM_RESET" (cold reset) and "CPU_ON" (SMP) PSCI support > > > for booting Linux on Stratix 10 platform. > > > > > > Ang, Chee Hong (3): > > > ARM: socfpga: stratix10: Enable PSCI system reset > > > ARM: socfpga: stratix10: Enable PSCI CPU_ON > > > ARM: socfpga: stratix10: Enable PSCI support for Stratix 10 > > > > > > arch/arm/mach-socfpga/Kconfig | 9 ++- > > > arch/arm/mach-socfpga/Makefile | 3 +++ > > > arch/arm/mach-socfpga/psci.c | 56 > > > ++ > > > 3 files changed, 67 insertions(+), 1 deletion(-) > > > create mode 100644 arch/arm/mach-socfpga/psci.c > > > > > Hi Marek, > > > > Any comment on this ? These PSCI patches are needed for booting > > Linux > > on our S10 platform. > Same questions as in Re: [PATCH v1 0/3] Enable HPS execution stage > notification , can we stop adding more and more stuff to arch/ and > instead add it to drivers/ ? As you might have noticed, we are trying > to > remove stuff from arch/ and move as much as possible to drivers/ , > but > S10 is doing the exact opposite :( > Not all PSCI code fit in DM (drivers/). There should be a good place to keep the PSCI code for our platform. Can you advise us where should we place those PSCI implementation other than arch/ ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] dm: MIGRATION: Add migration plan for WDT (DM watchdog support)
As much of the watchdog system has been migrated to DM now, formalize a deadline for migration. Please note that the old CONFIG_HW_WATCHDOG macro should be removed completely at some point. Signed-off-by: Stefan Roese Cc: Michal Simek Cc: Simon Glass Cc: Tom Rini --- Makefile | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Makefile b/Makefile index 9fb90c0779..fa47b068ac 100644 --- a/Makefile +++ b/Makefile @@ -1014,6 +1014,17 @@ ifneq ($(CONFIG_DM_SPI_FLASH)$(CONFIG_OF_CONTROL),yy) @echo >&2 "See doc/driver-model/MIGRATION.txt for more info." @echo >&2 "" endif +endif +ifneq ($(CONFIG_WATCHDOG)$(CONFIG_HW_WATCHDOG),) +ifneq ($(CONFIG_WDT),y) + @echo >&2 "= WARNING ==" + @echo >&2 "This board does not use CONFIG_WDT (DM watchdog support)." + @echo >&2 "Please update the board to use CONFIG_WDT before the" + @echo >&2 "v2019.10 release." + @echo >&2 "Failure to update by the deadline may result in board removal." + @echo >&2 "See doc/driver-model/MIGRATION.txt for more info." + @echo >&2 "" +endif endif @# Check that this build does not use CONFIG options that we do not @# know about unless they are in Kconfig. All the existing CONFIG -- 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] arm: exynos: arndale: Remove unused CONFIG_DM_I2C_COMPAT
Dear Krzysztof Kozlowski,
On 16/03/2019 02:11, Krzysztof Kozlowski wrote:
> The CONFIG_DM_I2C_COMPAT was introduced in
> include/configs/exynos5-common.h in commit 189d80166b31 ("exynos5:
> enable dm i2c") and then it propagated up to configs/arndale_defconfig.
> However since beginning the Arndale board (Exynos5250) was not using
> I2C.
>
> In fact, the Arndale board is not configuring its PMIC (S5M8767) which
> uses I2C bus. This setting can be thus safely removed to fix build
> warning:
>
> This board uses CONFIG_DM_I2C_COMPAT. Please remove
> (possibly in a subsequent patch in your series)
> before sending patches to the mailing list.
>
> Signed-off-by: Krzysztof Kozlowski
>
> ---
>
> Not tested on Arndale board. Testing is welcomed.
> ---
> configs/arndale_defconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig
> index 24422645cbac..2f218e8bb64c 100644
> --- a/configs/arndale_defconfig
> +++ b/configs/arndale_defconfig
> @@ -24,7 +24,6 @@ CONFIG_CMD_SOUND=y
> CONFIG_CMD_EXT4_WRITE=y
> CONFIG_DEFAULT_DEVICE_TREE="exynos5250-arndale"
> CONFIG_ENV_IS_IN_MMC=y
> -CONFIG_DM_I2C_COMPAT=y
> CONFIG_MMC_DW=y
> CONFIG_MMC_SDHCI=y
> CONFIG_MMC_SDHCI_S5P=y
>
Sorry to late response.
Could you please rebase this patch series?
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] imx: drop imx-regs.h
imx-regs.h under arch-imx has no user, drop it. Signed-off-by: Peng Fan --- CI: https://travis-ci.org/MrVan/u-boot/builds/530082356 arch/arm/include/asm/arch-imx/imx-regs.h | 637 --- 1 file changed, 637 deletions(-) delete mode 100644 arch/arm/include/asm/arch-imx/imx-regs.h diff --git a/arch/arm/include/asm/arch-imx/imx-regs.h b/arch/arm/include/asm/arch-imx/imx-regs.h deleted file mode 100644 index 93e336951c..00 --- a/arch/arm/include/asm/arch-imx/imx-regs.h +++ /dev/null @@ -1,637 +0,0 @@ -#ifndef _IMX_REGS_H -#define _IMX_REGS_H - -#define ARCH_MXC - -/* - * Motorola IMX system registers - * - * - */ - -#define IO_ADDRESS(x) ((x) | IMX_IO_BASE) - -# ifndef __ASSEMBLY__ -# define __REG(x) (*((volatile u32 *)IO_ADDRESS(x))) -# define __REG2(x,y)(*(volatile u32 *)((u32)&__REG(x) + (y))) -# else -# define __REG(x) (x) -# define __REG2(x,y) ((x)+(y)) -#endif - -#define IMX_IO_BASE0x0020 - -/* - * Register BASEs, based on OFFSETs - * - */ -#define IMX_AIPI1_BASE (0x0 + IMX_IO_BASE) -#define IMX_WDT_BASE (0x01000 + IMX_IO_BASE) -#define IMX_TIM1_BASE (0x02000 + IMX_IO_BASE) -#define IMX_TIM2_BASE (0x03000 + IMX_IO_BASE) -#define IMX_RTC_BASE (0x04000 + IMX_IO_BASE) -#define IMX_LCDC_BASE (0x05000 + IMX_IO_BASE) -#define IMX_UART1_BASE (0x06000 + IMX_IO_BASE) -#define IMX_UART2_BASE (0x07000 + IMX_IO_BASE) -#define IMX_PWM_BASE (0x08000 + IMX_IO_BASE) -#define IMX_DMAC_BASE (0x09000 + IMX_IO_BASE) -#define IMX_AIPI2_BASE (0x1 + IMX_IO_BASE) -#define IMX_SIM_BASE (0x11000 + IMX_IO_BASE) -#define IMX_USBD_BASE (0x12000 + IMX_IO_BASE) -#define IMX_SPI1_BASE (0x13000 + IMX_IO_BASE) -#define IMX_MMC_BASE (0x14000 + IMX_IO_BASE) -#define IMX_ASP_BASE (0x15000 + IMX_IO_BASE) -#define IMX_BTA_BASE (0x16000 + IMX_IO_BASE) -#define I2C1_BASE_ADDR (0x17000 + IMX_IO_BASE) -#define IMX_SSI_BASE (0x18000 + IMX_IO_BASE) -#define IMX_SPI2_BASE (0x19000 + IMX_IO_BASE) -#define IMX_MSHC_BASE (0x1A000 + IMX_IO_BASE) -#define IMX_PLL_BASE (0x1B000 + IMX_IO_BASE) -#define IMX_SYSCTRL_BASE (0x1B800 + IMX_IO_BASE) -#define IMX_GPIO_BASE (0x1C000 + IMX_IO_BASE) -#define IMX_EIM_BASE (0x2 + IMX_IO_BASE) -#define IMX_SDRAMC_BASE(0x21000 + IMX_IO_BASE) -#define IMX_MMA_BASE (0x22000 + IMX_IO_BASE) -#define IMX_AITC_BASE (0x23000 + IMX_IO_BASE) -#define IMX_CSI_BASE (0x24000 + IMX_IO_BASE) - -/* Watchdog Registers*/ - -#define WCR __REG(IMX_WDT_BASE + 0x00) /* Watchdog Control Register */ -#define WSR __REG(IMX_WDT_BASE + 0x04) /* Watchdog Service Register */ -#define WSTR __REG(IMX_WDT_BASE + 0x08) /* Watchdog Status Register */ - -/* SYSCTRL Registers */ -#define SIDR __REG(IMX_SYSCTRL_BASE + 0x4) /* Silicon ID Register */ -#define FMCR __REG(IMX_SYSCTRL_BASE + 0x8) /* Function Multiplex Control Register */ -#define GPCR __REG(IMX_SYSCTRL_BASE + 0xC) /* Function Multiplex Control Register */ - -/* Chip Select Registers */ -#define CS0U __REG(IMX_EIM_BASE)/* Chip Select 0 Upper Register */ -#define CS0L __REG(IMX_EIM_BASE + 0x4) /* Chip Select 0 Lower Register */ -#define CS1U __REG(IMX_EIM_BASE + 0x8) /* Chip Select 1 Upper Register */ -#define CS1L __REG(IMX_EIM_BASE + 0xc) /* Chip Select 1 Lower Register */ -#define CS2U __REG(IMX_EIM_BASE + 0x10) /* Chip Select 2 Upper Register */ -#define CS2L __REG(IMX_EIM_BASE + 0x14) /* Chip Select 2 Lower Register */ -#define CS3U __REG(IMX_EIM_BASE + 0x18) /* Chip Select 3 Upper Register */ -#define CS3L __REG(IMX_EIM_BASE + 0x1c) /* Chip Select 3 Lower Register */ -#define CS4U __REG(IMX_EIM_BASE + 0x20) /* Chip Select 4 Upper Register */ -#define CS4L __REG(IMX_EIM_BASE + 0x24) /* Chip Select 4 Lower Register */ -#define CS5U __REG(IMX_EIM_BASE + 0x28) /* Chip Select 5 Upper Register */ -#define CS5L __REG(IMX_EIM_BASE + 0x2c) /* Chip Select 5 Lower Register */ -#define EIM __REG(IMX_EIM_BASE + 0x30) /* EIM Configuration Register */ - -/* SDRAM controller registers */ - -#define SDCTL0 __REG(IMX_SDRAMC_BASE)/* SDRAM 0 Control Register */ -#define SDCTL1 __REG(IMX_SDRAMC_BASE + 0x4) /* SDRAM 1 Control Register */ -#define SDMISC __REG(IMX_SDRAMC_BASE + 0x14) /* Miscellaneous Register */ -#define SDRST __REG(IMX_SDRAMC_BASE + 0x18) /* SDRAM Reset Register */ - -/* PLL registers */ -#define CSCR __REG(IMX_PLL_BASE)/* Clock Source Control Register */ -#define CSCR_SPLL_RESTART (1<<22) -#define CSCR_MPLL_RESTART (1<<21) -#d
[U-Boot] [PATCH 2/2] imx: define ARCH_MXC for i.MX8/8M/7ULP
Without this definition, fsl_esdhc will access reserved registers on i.MX chips, so define ARCH_MXC to fix it. Signed-off-by: Peng Fan --- CI: https://travis-ci.org/MrVan/u-boot/builds/530082356 arch/arm/include/asm/arch-imx8/imx-regs.h | 2 ++ arch/arm/include/asm/arch-imx8m/imx-regs.h | 2 ++ arch/arm/include/asm/arch-mx7ulp/imx-regs.h | 2 ++ 3 files changed, 6 insertions(+) diff --git a/arch/arm/include/asm/arch-imx8/imx-regs.h b/arch/arm/include/asm/arch-imx8/imx-regs.h index af0fb5154b..6333ff4686 100644 --- a/arch/arm/include/asm/arch-imx8/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8/imx-regs.h @@ -6,6 +6,8 @@ #ifndef __ASM_ARCH_IMX8_REGS_H__ #define __ASM_ARCH_IMX8_REGS_H__ +#define ARCH_MXC + #define LPUART_BASE0x5A06 #define GPT1_BASE_ADDR 0x5D14 diff --git a/arch/arm/include/asm/arch-imx8m/imx-regs.h b/arch/arm/include/asm/arch-imx8m/imx-regs.h index 3facd5450c..68666a535b 100644 --- a/arch/arm/include/asm/arch-imx8m/imx-regs.h +++ b/arch/arm/include/asm/arch-imx8m/imx-regs.h @@ -6,6 +6,8 @@ #ifndef __ASM_ARCH_IMX8M_REGS_H__ #define __ASM_ARCH_IMX8M_REGS_H__ +#define ARCH_MXC + #include #define ROM_VERSION_A0 0x800 diff --git a/arch/arm/include/asm/arch-mx7ulp/imx-regs.h b/arch/arm/include/asm/arch-mx7ulp/imx-regs.h index bf9f39aca2..63b02de087 100644 --- a/arch/arm/include/asm/arch-mx7ulp/imx-regs.h +++ b/arch/arm/include/asm/arch-mx7ulp/imx-regs.h @@ -8,6 +8,8 @@ #include +#define ARCH_MXC + #define CAAM_SEC_SRAM_BASE (0x2600) #define CAAM_SEC_SRAM_SIZE (SZ_32K) #define CAAM_SEC_SRAM_END (CAAM_SEC_SRAM_BASE + CAAM_SEC_SRAM_SIZE - 1) -- 2.16.4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/3] Enable PSCI services for booting Linux
On 5/9/19 10:03 AM, Ang, Chee Hong wrote: > On Thu, 2019-05-09 at 08:59 +0200, Marek Vasut wrote: >> On 5/9/19 7:52 AM, Ang, Chee Hong wrote: >>> >>> On Mon, 2019-05-06 at 22:20 -0700, chee.hong@intel.com wrote: From: "Ang, Chee Hong" Add "SYTEM_RESET" (cold reset) and "CPU_ON" (SMP) PSCI support for booting Linux on Stratix 10 platform. Ang, Chee Hong (3): ARM: socfpga: stratix10: Enable PSCI system reset ARM: socfpga: stratix10: Enable PSCI CPU_ON ARM: socfpga: stratix10: Enable PSCI support for Stratix 10 arch/arm/mach-socfpga/Kconfig | 9 ++- arch/arm/mach-socfpga/Makefile | 3 +++ arch/arm/mach-socfpga/psci.c | 56 ++ 3 files changed, 67 insertions(+), 1 deletion(-) create mode 100644 arch/arm/mach-socfpga/psci.c >>> Hi Marek, >>> >>> Any comment on this ? These PSCI patches are needed for booting >>> Linux >>> on our S10 platform. >> Same questions as in Re: [PATCH v1 0/3] Enable HPS execution stage >> notification , can we stop adding more and more stuff to arch/ and >> instead add it to drivers/ ? As you might have noticed, we are trying >> to >> remove stuff from arch/ and move as much as possible to drivers/ , >> but >> S10 is doing the exact opposite :( >> > Not all PSCI code fit in DM (drivers/). There should be a good place to > keep the PSCI code for our platform. Can you advise us where should we > place those PSCI implementation other than arch/ ? Look through this discussion: https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html and possibly follow up on it. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: socfpga: Fix FPGA bitstream loading code
On 5/9/19 5:57 AM, Chee, Tien Fong wrote:
> On Wed, 2019-05-08 at 14:55 +0200, Marek Vasut wrote:
>> On 5/8/19 12:17 PM, Chee, Tien Fong wrote:
>>>
>>> On Tue, 2019-05-07 at 21:44 +0200, Marek Vasut wrote:
On 5/7/19 9:43 PM, Simon Goldschmidt wrote:
>
>
>
>
> On 07.05.19 21:41, Marek Vasut wrote:
>>
>>
>> On 5/7/19 9:36 PM, Simon Goldschmidt wrote:
>>>
>>>
>>>
>>>
>>> On 07.05.19 21:19, Marek Vasut wrote:
According to SoCFPGA Cyclone V datasheet rev.2018.01.26
page
175
(Chapter 5, FPGA Manager, data register) and Arria10
datasheet
rev.2017.07.22 page 211 (Chapter 5.4.1.2, FPGA Manager,
img_data_w
register), the FPGA data register must be written with
writes
with
non-incrementing address.
The current code increments the address in 32-byte
bursts.
Fix the
code so it does not increment the address and writes the
register
repeatedly instead. >
Signed-off-by: Marek Vasut
Cc: Chin Liang See
Cc: Dinh Nguyen
Cc: Simon Goldschmidt
Cc: Tien Fong Chee
---
drivers/fpga/socfpga.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/fpga/socfpga.c
b/drivers/fpga/socfpga.c
index 685957626b..6ecea771ce 100644
--- a/drivers/fpga/socfpga.c
+++ b/drivers/fpga/socfpga.c
@@ -55,8 +55,7 @@ void fpgamgr_program_write(const void
*rbf_data,
size_t rbf_size)
" cmp %2, #0\n"
" beq 2f\n"
"1: ldmia %0!, {r0-r7}\n"
- " stmia %1!, {r0-r7}\n"
- " sub %1, #32\n"
+ " stmia %1, {r0-r7}\n"
>>> Iirc, stmia without the "!" still stores the registers to
>>> different
>>> addresses, it just does not change %1 any more if you leave
>>> away the
>>> "!"? So this would save on opcode, but not change anything?
>> Uh oh, you're right. Do we have a bigger problem here then ?
>> Or
>> is the
>> socfpga ignoring the bottom 5 bits of this register address ?
> Well, bitsream programming works for me very well (we're
> loading
> all our
> FGPAs in U-Boot from a FIT image), so maybe it's the
> documentation
> that
> has a problem?
That could indeed be, maybe someone on the CC list can take a
look
into
it and crosscheck it with internal docs ?
>>> I can't find any doc mention about "FPGA data must be written in
>>> non-
>>> incremting address", but i saw there is a description about
>>> configuration data is buffered in a 64 deep x 32 bits wide FIFO in
>>> the
>>> FPGA Manager https://www.intel.com/content/dam/www/programmable/us/
>>> en/p
>>> dfs/literature/hb/arria-10/a10_5v4.pdf (pg. 204)
>> Well yes, it's a FIFO, but is the FIFO populated by writing to a
>> single
>> non-incrementing address or are we supposed to write to subsequent
>> incrementing addresses ?
>>
>>>
>>> Based on my understand through this register fpga_mgr_fpgamgrdata
>>> address map (0xFFCFE400-0xFFCFE7FF) on pg. 207 , the 256 bytes of
>>> FIFO
>>> buffer is mapping to above range addresses.
>> 0xFFCFE7FF-0xFFCFE400 = 0x400 = 1024 Bytes , not 256 . Why ?
>
> Finally, i have connected all scattered dot information from few
> internal docs. The register fpga_mgr_fpgamgrdata is actually a space in
> memory, acting like a buffer for the FPGA data. Regardless of the
> programming mode, data input from this buffer is translated into a 32-
> bit wide data path used by the configuration logic.
Does that mean that a write anywhere in 0xFFCFE400..0xFFCFE7FF ends up
in the same register / FIFO ? Does that mean that whole address range
ignores the bottom 0x3ff MSbits ? Does it matter to which address in
that range the CPU writes the data or not ?
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PULL u-boot] Please pull u-boot-amlogic-20190509
Hi Tom, This PR add support for USB on Amlogic G12A, Marek and Lukasz acked me for sending these patches via the amlogic u-boot tree. Thanks, Neil The following changes since commit 504bf790da08db9b4a443566cf6ef577f9c7996a: Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-05-08 16:21:43 -0400) are available in the Git repository at: git://git.denx.de/u-boot-amlogic.git tags/u-boot-amlogic-20190509 for you to fetch changes up to 92d911b2eedec8fee1f494ab961585e253351d4f: mach-meson: g12a: add DWC2 peripheral mode support (2019-05-09 10:38:32 +0200) - Add USB PHY drivers for Amlogic G12A - Add USB Complex Glue driver for Amlogic G12A - Add USB Gadget support for Amlogic G12A Neil Armstrong (3): usb: dwc3: Add Meson G12A USB Glue phy: meson: add Amlogic G12A USB2 and USB3+PCIE PHY drivers mach-meson: g12a: add DWC2 peripheral mode support arch/arm/include/asm/arch-meson/usb.h | 12 + arch/arm/mach-meson/board-g12a.c | 126 ++ drivers/phy/Kconfig | 8 + drivers/phy/Makefile | 1 + drivers/phy/meson-g12a-usb2.c | 216 drivers/phy/meson-g12a-usb3-pcie.c| 345 + drivers/usb/dwc3/Kconfig | 8 + drivers/usb/dwc3/Makefile | 1 + drivers/usb/dwc3/dwc3-meson-g12a.c| 456 ++ 9 files changed, 1173 insertions(+) create mode 100644 arch/arm/include/asm/arch-meson/usb.h create mode 100644 drivers/phy/meson-g12a-usb2.c create mode 100644 drivers/phy/meson-g12a-usb3-pcie.c create mode 100644 drivers/usb/dwc3/dwc3-meson-g12a.c ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 0/3] ARM: meson: Add G12A USB Support
Lukasz, Marek, On 07/05/2019 17:54, Lukasz Majewski wrote: > On Tue, 7 May 2019 17:16:52 +0200 > Marek Vasut wrote: > >> On 5/7/19 5:11 PM, Neil Armstrong wrote: >>> Hi Marek, >>> >>> On 07/05/2019 15:05, Marek Vasut wrote: On 5/7/19 10:43 AM, Neil Armstrong wrote: > This patchset adds support for USB on Amlogic G12A SoCs. > > This patchset is composed with : > - PHY Drivers > - USB Control Glue driver > - G12A board setup for Device mode > > Device Tree nodes will be added in a separate patchset when > applied on a tagged Linux tree. > > The Amlogic G12A USB Complex is composed of : > - 2 USB Controllers : > * DWC3 for USB2 and USB3 Host functionality > * DWC2 for USB2 Peripheral functionality > - 2 USB2 OTG PHYs, only a single one will be routed to either > DWC2 to DWC3 > - 1 USB3 PHY shared with PCIE funcionnality > - A Glue to control PHY routing, setup and OTG detection > > The Glue configures the UTMI 8bit interfaces for the USB2 PHYs, > including routing of the OTG PHY between the DWC3 and DWC2 > controllers, and setups the on-chip OTG mode selection for this > PHY. > > This drivers supports the on-probe setup of the OTG mode, and > manually via a setup function in the G12A common board code. > > Changes since v2: > - rebased on u-boot master > > Changes since v1: > - switch printf() to debug() in patch 1 > > Neil Armstrong (3): > usb: dwc3: Add Meson G12A USB Glue > phy: meson: add Amlogic G12A USB2 and USB3+PCIE PHY drivers > mach-meson: g12a: add DWC2 peripheral mode support > > arch/arm/include/asm/arch-meson/usb.h | 12 + > arch/arm/mach-meson/board-g12a.c | 126 +++ > drivers/phy/Kconfig | 8 + > drivers/phy/Makefile | 1 + > drivers/phy/meson-g12a-usb2.c | 216 > drivers/phy/meson-g12a-usb3-pcie.c| 345 +++ > drivers/usb/dwc3/Kconfig | 8 + > drivers/usb/dwc3/Makefile | 1 + > drivers/usb/dwc3/dwc3-meson-g12a.c| 456 > ++ 9 files changed, 1173 insertions(+) > create mode 100644 arch/arm/include/asm/arch-meson/usb.h > create mode 100644 drivers/phy/meson-g12a-usb2.c > create mode 100644 drivers/phy/meson-g12a-usb3-pcie.c > create mode 100644 drivers/usb/dwc3/dwc3-meson-g12a.c > Looks good to me, pick this via the meson tree please. >>> >>> No problem, but Lukasz wanted to pick it up. >>> >>> Lukasz, I can push it through u-boot-amlogic tree, is it ok for >>> you ? >> >> I don't care either way, whatever is comfortable for you two. >> > > Yes, please - use the u-boot-amlogic tree. Thanks in advance. Done, thanks. Neil > > > 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 > signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND
Hello Heiko On Tue, Apr 30, 2019 at 06:54:01AM +0200, Heiko Schocher wrote: >Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher: >> From: Markus Klotzbuecher > >please add a commit message. > >> Signed-off-by: Markus Klotzbuecher >> Cc: Heiko Schocher >> Cc: Kyungmin Park >> --- >> env/Kconfig | 6 ++ >> scripts/config_whitelist.txt | 1 - >> 2 files changed, 6 insertions(+), 1 deletion(-) >> >> diff --git a/env/Kconfig b/env/Kconfig >> index 78300660c7..44c47220c2 100644 >> --- a/env/Kconfig >> +++ b/env/Kconfig >> @@ -513,6 +513,12 @@ config ENV_UBI_VOLUME >> help >>Name of the volume that you want to store the environment in. >> +config ENV_UBI_VOLUME_REDUND >> +string "UBI redundant volume name" >> +depends on ENV_IS_IN_UBI >> +help >> + Name of the redundant volume that you want to store the environment >> in. >> + >> endif >> config USE_DEFAULT_ENV_FILE >> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt >> index fa98efc24c..5d76c781d3 100644 >> --- a/scripts/config_whitelist.txt >> +++ b/scripts/config_whitelist.txt >> @@ -504,7 +504,6 @@ CONFIG_ENV_SROM_BANK >> CONFIG_ENV_TOTAL_SIZE >> CONFIG_ENV_UBIFS_OPTION >> CONFIG_ENV_UBI_MTD >> -CONFIG_ENV_UBI_VOLUME_REDUND >> CONFIG_ENV_VERSION >> CONFIG_EP9302 >> CONFIG_EP9307 >> > >Please move from the config files: > >./include/configs/omap3_igep00x0.h >./include/configs/gardena-smart-gateway-at91sam.h >./include/configs/am335x_igep003x.h > >also the symbols to the defconfig files, thanks. I have a question: to convert these, I need to make available the additional ENV_ configs to OMAP2PLUS and AT91: diff --git a/env/Kconfig b/env/Kconfig index 44c47220c2..1250656d74 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -470,7 +470,7 @@ config ENV_EXT4_FILE It's a string of the EXT4 file name. This file use to store the environment (explicit path to the file) -if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || ARC +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || ARC || ARCH_OMAP2PLUS || ARCH_AT91 However, this "if" region contains a few other, non UBI settings such as ENV_SIZE, which would become visible to a large number of OMAP2PLUS and AT91 boards, which still define this in the headers. I'm a bit hesitant to touch all of these. What is the suggested way to solve this? Thank you, Markus -- Markus Klotzbuecher Freelancer Embedded, Distributed & Real-time Systems Am See 28, 78465 Konstanz, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5] ARM: am335x: Add phyCORE AM335x R2 support
On 07.05.19 16:43, Niel Fourie wrote:
> Hi Tom,
>
> On 5/7/19 3:19 PM, Tom Rini wrote:
>> On Tue, May 07, 2019 at 11:39:12AM +0200, Niel Fourie wrote:
>>> Hi Tom,
>>>
>>> On 5/6/19 7:24 PM, Tom Rini wrote:
On Mon, May 06, 2019 at 06:44:48PM +0200, Niel Fourie wrote:
> Hi Tom,
>
> On 5/6/19 4:18 PM, Tom Rini wrote:
>> On Mon, May 06, 2019 at 04:02:53PM +0200, Niel Fourie wrote:
>>
>>> 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
>>> [snip]
>
> void sdram_init(void)
> {
> /* Configure memory to maximum supported size for detection */
> int ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
> config_ddr(DDR_CLK_MHZ, &ioregs,
> &physom_timings[ram_type_index].ddr3_data,
> &ddr3_cmd_ctrl_data,
> &physom_timings[ram_type_index].ddr3_emif_reg_data,
> 0);
>
> /* Detect memory physically present */
> gd->ram_size = get_ram_size((void *)CONFIG_SYS_SDRAM_BASE,
> CONFIG_MAX_RAM_BANK_SIZE);
>
> /* Reconfigure memory for actual detected size */
> switch (gd->ram_size) {
> case SZ_1G:
> ram_type_index = PHYCORE_R2_MT41K512M16HA125IT_1024MB;
> break;
> case SZ_512M:
> ram_type_index = PHYCORE_R2_MT41K256M16TW107IT_512MB;
> break;
> case SZ_256M:
> default:
> ram_type_index = PHYCORE_R2_MT41K128M16JT_256MB;
> break;
> }
> config_ddr(DDR_CLK_MHZ, &ioregs,
> &physom_timings[ram_type_index].ddr3_data,
> &ddr3_cmd_ctrl_data,
> &physom_timings[ram_type_index].ddr3_emif_reg_data,
> 0);
> }
>
> The ugliest part of this is, as you pointed out, that directly
> after this is
> called, get_ram_size() will be called again from sdram_init(). But
> it at
> least noninvasive, and no longer requires the device tree.
I don't think it's safe to call config_ddr twice, especially with the
possibly wrong parameters. What's barebox doing in this case, being
told the presumably correct DDR size in the device tree?
>>>
>>> Good point. Barebox uses the above mechanism to detect the memory
>>> size, and
>>> I could find no equivalent memory size specified in its internal device
>>> tree.
>>
>> Configure for 1GB and then see how much we can actually talk to?
>
> Yes. If you are interested, you can see their implementation here [1],
> where get_minimal_timings() returns the configuration for 1GiB;
> everything is in that file. (I did credit the author.)
>
> [1]
> https://git.pengutronix.de/cgit/barebox/tree/arch/arm/boards/phytec-som-am335x/lowlevel.c#n167
>
>>> Marek originally proposed using the memory size specified in the
>>> device tree
>>> as an improvement over specifying the size in the defconfig (as in
>>> v1 of the
>>> patch).
>>
>> But then you aren't populating 3 device trees nor making it clear / easy
>> to say which module you're on, and then still need to change the config
>> for which DT you're picking up. These SOMs really don't provide any
>> run-time method to see which one you're on? There's no GPIOs to poke?
>
> Agreed, the device tree solution is inferior to autodetection. The
> SOMs manual makes no mention of how different variants can be
> distinguished/detected, and the board specific code in Barebox
> (written by Phytec) does not contain any other detection code (except
> for the RAM), like checking GPIOs. Unfortunately there is no publicly
> available schematic, so I can't be completely sure. So I am going to
> assume it, there is no other way of detection.
You are right, for our AM335 based SOMs there is no way to detect the
variant. The barebox generates for every possible RAM configuration an
own MLO. The nice thing is that barebox generates all variants with one
build by using its multi image mechanism.
Besides the RAM, the phyCORE can be populated with different AM335x
variants, NANDs, RTC/EEPROM/Eth-PHY(yes/no) and maybe other things I
don't remember now.
I think it would be a good Idea to maintain a list of article numbers
(that fully describes the SOM variant) which are supported by the
current u-boot version.
Regards,
Wadim
>
> Best regards,
> Niel Fourie
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u
[U-Boot] Pull request: u-boot-riscv/master
Hi Tom, Please pull some riscv updates: - Correct SYS_TEXT_BASE for qemu. - Support booti. - Increase SYSBOOTM_LEN for Fedora/RISCV kernel. - Support SMP booting from flash. https://travis-ci.org/rickchen36/u-boot-riscv/builds/530082266 Thanks Rick The following changes since commit 504bf790da08db9b4a443566cf6ef577f9c7996a: Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-05-08 16:21:43 -0400) are available in the Git repository at: git://git.denx.de/u-boot-riscv.git for you to fetch changes up to 3cedc97479ff44cdc00485de7517a833e3dfb630: RISCV: image: Add booti support (2019-05-09 16:47:52 +0800) Anup Patel (1): riscv: qemu: Use correct SYS_TEXT_BASE for S-mode on 32bit system Atish Patra (1): RISCV: image: Add booti support David Abdurachmanov (2): riscv: set CONFIG_SYS_BOOTM_LEN to SZ_64M riscv: qemu-riscv.h: define CONFIG_PREBOOT (enables extlinux) Rick Chen (5): riscv: Introduce CONFIG_XIP to support booting from flash riscv: configs: Support AE350 SMP booting from flash flow riscv: prior_stage_fdt_address should only be used when OF_PRIOR_STAGE is enabled riscv: configs: AE350 will use CONFIG_OF_PRIOR_STAGE when boots from ram riscv: configs: AE350 will use CONFIG_OF_SEPARATE when boots from flash arch/riscv/Kconfig | 7 +++ arch/riscv/cpu/cpu.c| 4 arch/riscv/cpu/start.S | 8 arch/riscv/include/asm/global_data.h| 2 ++ arch/riscv/lib/Makefile | 1 + arch/riscv/lib/asm-offsets.c| 2 ++ arch/riscv/lib/image.c | 55 +++ arch/riscv/lib/smp.c| 2 ++ board/AndesTech/ax25-ae350/MAINTAINERS | 2 ++ board/AndesTech/ax25-ae350/ax25-ae350.c | 4 board/emulation/qemu-riscv/Kconfig | 3 ++- cmd/Kconfig | 2 +- cmd/booti.c | 8 ++-- configs/ae350_rv32_defconfig| 2 +- configs/ae350_rv32_xip_defconfig| 37 + configs/ae350_rv64_defconfig| 2 +- configs/ae350_rv64_xip_defconfig| 38 ++ include/configs/ax25-ae350.h| 2 +- include/configs/qemu-riscv.h| 16 ++-- 19 files changed, 180 insertions(+), 17 deletions(-) create mode 100644 arch/riscv/lib/image.c create mode 100644 configs/ae350_rv32_xip_defconfig create mode 100644 configs/ae350_rv64_xip_defconfig ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] arm: mvebu: clearfog: Enable BLK and DM support
On 03.05.19 08:42, Stefan Roese wrote: This patch enables CONFIG_BLK and some DM enabled drivers on clearfog to remove these compile warnings: = WARNING == This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB 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. = WARNING == This board does use CONFIG_LIBATA but has CONFIG_AHCI not enabled. Please update the storage controller driver to use CONFIG_AHCI 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: Stefan Roese Applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] arm: mvebu: db-88f6720: Enable CONFIG_BLK
On 03.05.19 08:42, Stefan Roese wrote: This patch enables CONFIG_BLK to remove this compile warning: = WARNING == This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB 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: Stefan Roese Applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v4] arm: mvebu: Add CRS305-1G-4S board
On 07.05.19 19:35, Luka Kovacic wrote: CRS305-1G-4S has a switch chip with an integrated CPU (98DX3236) and like some of the other similar boards requires bin_hdr. bin_hdr (DDR3 init stage) is currently retrieved from the stock bootloader and compiled into the kwb image. Adds support for U-Boot, enable UART, SPI, Winbond SPI flash chip support and writing env to SPI flash. Signed-off-by: Luka Kovacic Applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: mvebu: clearfog: add MMC to SPL DT
On 08.05.19 16:47, Baruch Siach wrote: This allows SPL to load the main U-Boot image from MMC once DM_MMC is enabled. Signed-off-by: Baruch Siach Applied to u-boot-marvell/master. Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] arm: mvebu: db-88f6820-gp: Enabel BLK and DM support
On 03.05.19 08:42, Stefan Roese wrote: This patch enables CONFIG_BLK and some DM enabled drivers on db-88f6820-gp to remove these compile warnings: = WARNING == This board does not use CONFIG_DM_MMC. Please update the board to use CONFIG_DM_MMC before the v2019.04 release. Failure to update by the deadline may result in board removal. See doc/driver-model/MIGRATION.txt for more info. = WARNING == This board does not use CONFIG_DM_USB. Please update the board to use CONFIG_DM_USB 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. = WARNING == This board does use CONFIG_LIBATA but has CONFIG_AHCI not enabled. Please update the storage controller driver to use CONFIG_AHCI 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: Stefan Roese Applied to u-boot-marvell/master. (after fixing the typo in the subject) Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Please pull u-boot-marvell/master
Hi Tom, please pull the following Marvell related patches: - DM updates for multiple MVEBU boards (Stefan) - Add CRS305-1G-4S board (Luka) - Enable MMC in SPL on clearfog (Baruch) Here the Travis build, without any issues: https://travis-ci.org/stroese/u-boot/builds/530119803 Thanks, Stefan The following changes since commit 504bf790da08db9b4a443566cf6ef577f9c7996a: Merge branch 'master' of git://git.denx.de/u-boot-sunxi (2019-05-08 16:21:43 -0400) are available in the Git repository at: git://www.denx.de/git/u-boot-marvell.git for you to fetch changes up to 13cba82b51f57e9a06ebf3d9490e1f682e55ed97: arm: mvebu: clearfog: add MMC to SPL DT (2019-05-09 07:35:04 +0200) Baruch Siach (1): arm: mvebu: clearfog: add MMC to SPL DT Luka Kovacic (1): arm: mvebu: Add CRS305-1G-4S board Stefan Roese (3): arm: mvebu: clearfog: Enable BLK and DM support arm: mvebu: db-88f6720: Enable CONFIG_BLK arm: mvebu: db-88f6820-gp: Enable BLK and DM support arch/arm/dts/Makefile | 3 +- arch/arm/dts/armada-388-clearfog-u-boot.dtsi| 4 + arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi | 13 +++ arch/arm/dts/armada-xp-crs305-1g-4s.dts | 110 arch/arm/mach-mvebu/Kconfig | 7 ++ board/mikrotik/crs305-1g-4s/.gitignore | 1 + board/mikrotik/crs305-1g-4s/MAINTAINERS | 7 ++ board/mikrotik/crs305-1g-4s/Makefile| 14 +++ board/mikrotik/crs305-1g-4s/README | 23 + board/mikrotik/crs305-1g-4s/binary.0| 11 +++ board/mikrotik/crs305-1g-4s/crs305-1g-4s.c | 75 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in | 12 +++ configs/clearfog_defconfig | 4 +- configs/crs305-1g-4s_defconfig | 52 +++ configs/db-88f6720_defconfig| 1 + configs/db-88f6820-gp_defconfig | 4 +- include/configs/crs305-1g-4s.h | 37 17 files changed, 375 insertions(+), 3 deletions(-) create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s-u-boot.dtsi create mode 100644 arch/arm/dts/armada-xp-crs305-1g-4s.dts create mode 100644 board/mikrotik/crs305-1g-4s/.gitignore create mode 100644 board/mikrotik/crs305-1g-4s/MAINTAINERS create mode 100644 board/mikrotik/crs305-1g-4s/Makefile create mode 100644 board/mikrotik/crs305-1g-4s/README create mode 100644 board/mikrotik/crs305-1g-4s/binary.0 create mode 100644 board/mikrotik/crs305-1g-4s/crs305-1g-4s.c create mode 100644 board/mikrotik/crs305-1g-4s/kwbimage.cfg.in create mode 100644 configs/crs305-1g-4s_defconfig create mode 100644 include/configs/crs305-1g-4s.h ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PULL]Please pull u-boot-rockchip/tags/rockchip-for-v2019.07-rc1
Hi Tom, Please ignore this pull and I'm going to send v2 of PULL with drop some board support for it does not have available SPL now. Thanks, - Kever On 05/09/2019 09:17 AM, Kever Yang wrote: > Hi Tom, > > Here is the second batch of changes for the Rockchip side of the repository. > > Clean bill-of-health in Travis-CI at > > https://travis-ci.org/keveryang/u-boot/builds/529695743 > > And I have test on all evb of Rockchip SoCs. > > Thanks, > - Kever > > > The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 > 09:38:00 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-rockchip.git tags/rockchip-for-v2019.07-rc1 > > for you to fetch changes up to 53fc7795e2310a5c52cdc240d84fed8d3373: > > doc: rockchip: Add global doc for rk3399 build/flash (2019-05-08 > 17:34:14 +0800) > > > Improvements and new features: > - split more rockchip pinctrl_core feature into per SoC > - enable TPL for evb-rk3399 board > - enable TPL/SPL for evb-px5 board > - enable TPL and OP-TEE support for evb-rk3229 > - update fix in arm common assembly start code for rockchip header file > - update default SPL_FIT_GENERATOR for rockchip > - rk3399 boards update to use '-u-boot.dtsi' > - add new rk3399 boards: Nanopi M4/NEO4, Nanopc T4, RockPro64, Rock PI 4 > - enable sound for chromebook_minnie > > > > David Wu (10): > pinctrl: rockchip: Add pull-pin-default param and remove unused param > pinctrl: rockchip: Remove redundant spaces > pinctrl: rockchip: Split the common set_mux() into per Soc > pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' iomux > pinctrl: rockchip: Split the common set_drive() func into per Soc > pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' drive > strength > pinctrl: rockchip: Split the common set_pull() func into per Soc > pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' pull > pinctrl: rockchip: Clean the unused type and label > pinctrl: rockchip: Also move common set_schmitter func into per > Soc file > > Jagan Teki (16): > dts: Makefile: Build rockchip dtbs based on SoC types > arm64: rockchip: dts: rk3399: Add board -u-boot.dtsi files > rockchip: dts: rk3399-u-boot: Add u-boot, dm-pre-reloc for spi1 > arm64: rockchip: dts: rk3399: Use rk3399-u-boot.dtsi > rockchip: rk3399: orangepi: Add SPL_TEXT_BASE > rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2 > Kconfig: Add default SPL_FIT_GENERATOR for rockchip > arm: rockchip: rk3399: Move common configs in Kconfig > rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux > rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1 > rockchip: rk3399: Add Nanopi M4 board support > rockchip: rk3399: Add Nanopc T4 board support > rockchip: rk3399: Add Nanopi NEO4 board support > rockchip: rk3399: Add Rockpro64 board support > rockchip: rk3399: Add Rock PI 4 support > doc: rockchip: Add global doc for rk3399 build/flash > > Kever Yang (26): > rockchip: add common header boot0.h and gpio.h for soc > arm: remove ARCH_ROCKCHIP macro in common code > Revert "rockchip: rk322x: ram: enable DRAM init in SPL instead of TPL" > arm: add option for TPL support in arm 32bit > arm: add a separate stack for TPL > rockchip: rk322x: add CLK_EMMC_SAMPLE clock support > rockchip: clk: rk322x: fix assert clock value > rockchip: rk322x: add tpl support > sysreset: enable driver support in SPL/TPL > rockchip: rk322x: dts: enable uart2 for SPL/TPL > rockchip: evb-rk3229: remove unnecessary defines > rockchip: evb-rk3229: add README file for OP-TEE support > rockchip: evb-rk322x: update defconfig with tpl and optee support > rockchip: rk3368: support UART2/4 in board_debug_uart_init() > rockchip: px5 update dts for spl/tpl > rockchip: px5: update SPL size for spl/tpl > rockchip: px5: update defconfig for TPL/SPL > rockchip: boot0: update CONFIG_ROCKCHIP_SPL_RESERVE_IRAM for SPL only > rockchip: dmc: rk3368: update rank number for evb-px5 > rockchip: rk3368: remove uart iomux init in SPL > rockchip: px5: add timer0 dts node as tick timer > rockchip: add u-boot-tpl-v8.lds > rockchip: rk3399: add tpl support > rockchip: ram: rk3399: update for TPL > rockchip: rk3399: update defconfig for TPL > Revert "pinctrl: rockchip: Add 32bit writing function for rk3288 > gpio0 pinctrl" > > Simon Glass (1): > rockchip: chromebook_minnie: Enable sound > > Kconfig | 1 + > arch/Kconfig | 1 + > arch/arm/Kc
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月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=https%3A%2
> > > > > > F%2F
> > > > > > patc
> > > > > >
> > > > >
> > >
> hwork.ozlabs.org%2Fproject%2Fuboot%2Flist%2F%3Fseries%3D99439&d
> > > > > ata
> > > > > >
> > > > >
> > >
> =02%7C01%7Cchuanhua.han%40nxp.com%7Cfa6bdd7859c4411b5d8608d6c8
> > > > > 8223e3%7
> > > > > >
> > > > >
> > >
> C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C63691685860819371
> > > > > 5&sda
> > > > > >
> > > > >
> > >
> ta=437CqPexTmJAzhl7wZ3lAUQVbmy%2B2NvHlurTcGTJKT0%3D&reserve
> > > > > d=0
> > > > > >
> > > > > > drivers/spi/fsl_espi.c | 450
> > > > > > +
> > > > > > 1 file changed, 316 insertions(+), 134 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
> > > > > > index 7444ae1a06..6ebe57c30b 100644
> > > > > > --- a/drivers/spi/fsl_espi.c
> > > > > > +++ b/drivers/spi/fsl_espi.c
> > > > > > @@ -4,17 +4,27 @@
> > > > > > *
> > > > > > * Copyright 2010-2011 Freescale Semiconductor, Inc.
> > > > > > * Author: Mingkai Hu (mingkai...@freescale.com)
> > > > > > + *Chuanhua Han (chuanhua@nxp.com)
> > > > > > */
> > > > > >
> > > > > > #include
> > > > > > -
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > +#include
> > > > > > +#include
> > > > > > +#include
> > > > > > +
> > > > > > +struct fsl_espi_platdata {
> > > > > > + uint flags;
> > > > > > + uint speed_hz;
> > > > > > + uint num_chipselect;
> > > > > > + fdt_addr_t regs_addr;
> > > > > > +};
> > > > > >
> > > > > > -struct fsl_spi_slave {
> > > > > > - struct spi_slave slave;
> > > > > > +struct fsl_espi_priv {
> > > > > > ccsr_espi_t *espi;
> > > > > > + u32 speed_hz;
> > > > > > unsigned intdiv16;
> > > > > > unsigned intpm;
> > > > > > int tx_timeout;
> > > > > > @@ -25,9 +35,18 @@ struct fsl_spi_slave {
> > > > > > unsigned intmax_transfer_length;
> > > > > > };
> > > > > >
> > > > > > +struct fsl_spi_slave {
> > > > > > + struct spi_slave slave;
> > > > > > + struct fsl_espi_priv priv; };
> > > > > > +
> > > > > > #define to_fs
Re: [U-Boot] [PATCH v1] dm: pinctrl: Remove obsolete function pinctrl_decode_pin_config_dm().
Hi Simon, On 05/09/2019 11:52 AM, Simon Glass wrote: > Hi, > > On Fri, 5 Apr 2019 at 05:43, Christoph Müllner > wrote: >> Hi Simon, >> >> any plans to get this merged? > Yes, Kever should do it. OK, I will take this. I didn't notice this before you send this patch, it does not in rockchip related files and look like it delegate to your name, while the origin patch(need to revert) is from rockchip tree. Please cc me if there are similar case, or else I may miss it. Thanks, - Kever > > - Simon > >> Thanks, >> Christoph >> >>> On 14.02.2019, at 02:54, Simon Glass wrote: >>> >>> On Tue, 12 Feb 2019 at 18:29, Christoph Muellner >>> wrote: This reverts commit 5ff776889212c080e3d1a33634ac904405ed6845. As noted in the comment, the function pinctrl_decode_pin_config_dm() only served as a temporary solution. Since the function has no users anymore, we can remove it again. Signed-off-by: Christoph Muellner --- drivers/pinctrl/pinctrl-uclass.c | 22 -- include/dm/pinctrl.h | 12 2 files changed, 34 deletions(-) >>> Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] Pull request v2: u-boot-rockchip/tags/rockchip-for-v2019.07-rc1
Here is the v2 of second batch of changes for the Rockchip repository. Drop support for rk3399 neo4, rockpro64, rock-pi boards support since v1. Clean bill-of-health in Travis-CI at https://travis-ci.org/keveryang/u-boot/builds/529695743 And I have test on all evb of Rockchip SoCs. Thanks, - Kever The following changes since commit 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-07 09:38:00 -0400) are available in the Git repository at: git://git.denx.de/u-boot-rockchip.git tags/rockchip-for-v2019.07-rc1 for you to fetch changes up to c661c059b9a507baa1704c03f29ff2f79bae2ce2: doc: rockchip: Add global doc for rk3399 build/flash (2019-05-09 18:24:31 +0800) Improvements and new features: - split more rockchip pinctrl_core feature into per SoC - enable TPL for evb-rk3399 board - enable TPL/SPL for evb-px5 board - enable TPL and OP-TEE support for evb-rk3229 - update fix in arm common assembly start code for rockchip header file - update default SPL_FIT_GENERATOR for rockchip - rk3399 boards update to use '-u-boot.dtsi' - add new rk3399 boards: Nanopi M4, Nanopc T4 - enable sound for chromebook_minnie David Wu (10): pinctrl: rockchip: Add pull-pin-default param and remove unused param pinctrl: rockchip: Remove redundant spaces pinctrl: rockchip: Split the common set_mux() into per Soc pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' iomux pinctrl: rockchip: Split the common set_drive() func into per Soc pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' drive strength pinctrl: rockchip: Split the common set_pull() func into per Soc pinctrl: rockchip: Special treatment for RK3288 gpio0 pins' pull pinctrl: rockchip: Clean the unused type and label pinctrl: rockchip: Also move common set_schmitter func into per Soc file Jagan Teki (13): dts: Makefile: Build rockchip dtbs based on SoC types arm64: rockchip: dts: rk3399: Add board -u-boot.dtsi files rockchip: dts: rk3399-u-boot: Add u-boot, dm-pre-reloc for spi1 arm64: rockchip: dts: rk3399: Use rk3399-u-boot.dtsi rockchip: rk3399: orangepi: Add SPL_TEXT_BASE rockchip: dts: rk3399: Sync pwm2_pin_pull_down from Linux 5.1-rc2 Kconfig: Add default SPL_FIT_GENERATOR for rockchip arm: rockchip: rk3399: Move common configs in Kconfig rockchip: dts: rk3399: Sync rk3399-nanopi4.dtsi from Linux rockchip: dts: rk3399: nanopi4: Use CD pin as RK_FUNC_1 rockchip: rk3399: Add Nanopi M4 board support rockchip: rk3399: Add Nanopc T4 board support doc: rockchip: Add global doc for rk3399 build/flash Kever Yang (26): rockchip: add common header boot0.h and gpio.h for soc arm: remove ARCH_ROCKCHIP macro in common code Revert "rockchip: rk322x: ram: enable DRAM init in SPL instead of TPL" arm: add option for TPL support in arm 32bit arm: add a separate stack for TPL rockchip: rk322x: add CLK_EMMC_SAMPLE clock support rockchip: clk: rk322x: fix assert clock value rockchip: rk322x: add tpl support sysreset: enable driver support in SPL/TPL rockchip: rk322x: dts: enable uart2 for SPL/TPL rockchip: evb-rk3229: remove unnecessary defines rockchip: evb-rk3229: add README file for OP-TEE support rockchip: evb-rk322x: update defconfig with tpl and optee support rockchip: rk3368: support UART2/4 in board_debug_uart_init() rockchip: px5 update dts for spl/tpl rockchip: px5: update SPL size for spl/tpl rockchip: px5: update defconfig for TPL/SPL rockchip: boot0: update CONFIG_ROCKCHIP_SPL_RESERVE_IRAM for SPL only rockchip: dmc: rk3368: update rank number for evb-px5 rockchip: rk3368: remove uart iomux init in SPL rockchip: px5: add timer0 dts node as tick timer rockchip: add u-boot-tpl-v8.lds rockchip: rk3399: add tpl support rockchip: ram: rk3399: update for TPL rockchip: rk3399: update defconfig for TPL Revert "pinctrl: rockchip: Add 32bit writing function for rk3288 gpio0 pinctrl" Simon Glass (1): rockchip: chromebook_minnie: Enable sound Kconfig | 1 + arch/Kconfig | 1 + arch/arm/Kconfig | 30 + arch/arm/cpu/armv8/start.S | 4 - arch/arm/dts/Makefile| 37 +- arch/arm/dts/rk3229-evb.dts | 1 + arch/arm/dts/rk3288-veyron-minnie.dts| 12 + arch/arm/dts/rk3368-px5-evb-u-boot.dtsi | 36 ++ arch/arm/dts/rk3399-evb-u-boot.dtsi | 7 + arch/arm/dts/rk3399-evb.dts | 1 - arch/arm/dts/rk3399-ficus-u-boot.dtsi| 6 + arc
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Hi Paul, On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski wrote: > > Hi, > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > (Sorry for the noice, I have missed to send two patches from v7) > > > > This is v7 resend patchset for New rk3399 boards support wrt previous > > version[1] > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > orangepi rk3399 changes are merged, so this is rework on top of > > u-boot-rockchip/master. > > > > Overall this series add support below rk3399 boards > > - NanoPI M4 > > - NanoPC T4 > > - NanoPI NEO4 > > - Orangepi RK3399 > > - Rock PI 4 > > - Rockpro64 > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > > dts(i) from linux-next. > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > > series [3]. > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > > booting via Rockchip miniloader as of now. > > Could you send these two boards in a separate series so that we avoid > merging them for now (because SPL support is broken) and then re- > iterate the series later with the DDR bringup? Or maybe find a way to > disable SPL support, but in any case, it's not ok to merge a board with > SPL enabled and broken. I have explained the details about this concern on v2 [1], thought you would comeback on the same line instead here. Anyway, making SPL as an optional is not an idea to go with Mainline as we make many decisions with regards to make SPL is mandatory. Since the DDR is show stopper here (and it would really need a good amount of time, since it effect the other boards), I can go with TPL enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of booting stages. This way we can avoid skipping SPL usage, and many config changes to make SPL optional. [1] https://patchwork.ozlabs.org/cover/1086213/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] dm: pinctrl: Remove obsolete function pinctrl_decode_pin_config_dm().
Hi Christoph, Could you re-send this patch with re-base on top of master, because there is a conflict when I try to merge it. Thanks, - Kever On 05/09/2019 11:52 AM, Simon Glass wrote: > Hi, > > On Fri, 5 Apr 2019 at 05:43, Christoph Müllner > wrote: >> Hi Simon, >> >> any plans to get this merged? > Yes, Kever should do it. > > - Simon > >> Thanks, >> Christoph >> >>> On 14.02.2019, at 02:54, Simon Glass wrote: >>> >>> On Tue, 12 Feb 2019 at 18:29, Christoph Muellner >>> wrote: This reverts commit 5ff776889212c080e3d1a33634ac904405ed6845. As noted in the comment, the function pinctrl_decode_pin_config_dm() only served as a temporary solution. Since the function has no users anymore, we can remove it again. Signed-off-by: Christoph Muellner --- drivers/pinctrl/pinctrl-uclass.c | 22 -- include/dm/pinctrl.h | 12 2 files changed, 34 deletions(-) >>> Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] dm: pinctrl: Remove obsolete function pinctrl_decode_pin_config_dm().【请注意，邮件由s...@google.com代发】
Hi Christoph, Could you re-send this patch with re-base on top of master, because there is a conflict when I try to merge it. Thanks, - Kever On 05/09/2019 11:52 AM, Simon Glass wrote: > Hi, > > On Fri, 5 Apr 2019 at 05:43, Christoph Müllner > wrote: >> Hi Simon, >> >> any plans to get this merged? > Yes, Kever should do it. > > - Simon > >> Thanks, >> Christoph >> >>> On 14.02.2019, at 02:54, Simon Glass wrote: >>> >>> On Tue, 12 Feb 2019 at 18:29, Christoph Muellner >>> wrote: This reverts commit 5ff776889212c080e3d1a33634ac904405ed6845. As noted in the comment, the function pinctrl_decode_pin_config_dm() only served as a temporary solution. Since the function has no users anymore, we can remove it again. Signed-off-by: Christoph Muellner --- drivers/pinctrl/pinctrl-uclass.c | 22 -- include/dm/pinctrl.h | 12 2 files changed, 34 deletions(-) >>> Reviewed-by: Simon Glass ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/3] rk3399: orangepi: Enable TPL
Enable TPL for OrangePI rk3399 board. Signed-off-by: Jagan Teki --- configs/orangepi-rk3399_defconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/configs/orangepi-rk3399_defconfig b/configs/orangepi-rk3399_defconfig index 3f02c89983..90021bb695 100644 --- a/configs/orangepi-rk3399_defconfig +++ b/configs/orangepi-rk3399_defconfig @@ -5,7 +5,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_ROCKCHIP_RK3399=y -CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000 +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x5 CONFIG_DEBUG_UART_BASE=0xFF1A CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_STACK_R_ADDR=0x8 @@ -14,9 +14,8 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-orangepi.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_SPL_TEXT_BASE=0xff8c2000 CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y @@ -24,6 +23,7 @@ CONFIG_CMD_SF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y +CONFIG_TPL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3399-orangepi" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" @@ -56,4 +56,5 @@ CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y CONFIG_USE_TINY_PRINTF=y +CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/3] rk3399: nanopi4: Enable TPL
Enable TPL for NanoPC T4, NanoPI M4 boards. Signed-off-by: Jagan Teki --- configs/nanopc-t4-rk3399_defconfig | 7 --- configs/nanopi-m4-rk3399_defconfig | 7 --- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/configs/nanopc-t4-rk3399_defconfig b/configs/nanopc-t4-rk3399_defconfig index d9f2137b4c..9b7e15d63a 100644 --- a/configs/nanopc-t4-rk3399_defconfig +++ b/configs/nanopc-t4-rk3399_defconfig @@ -5,7 +5,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_ROCKCHIP_RK3399=y -CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000 +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x5 CONFIG_DEBUG_UART_BASE=0xFF1A CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_STACK_R_ADDR=0x8 @@ -14,9 +14,8 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopc-t4.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_SPL_TEXT_BASE=0xff8c2000 CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y @@ -24,6 +23,7 @@ CONFIG_CMD_SF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y +CONFIG_TPL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopc-t4" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" @@ -56,4 +56,5 @@ CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y CONFIG_USE_TINY_PRINTF=y +CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y diff --git a/configs/nanopi-m4-rk3399_defconfig b/configs/nanopi-m4-rk3399_defconfig index c2832788f0..92e70dd939 100644 --- a/configs/nanopi-m4-rk3399_defconfig +++ b/configs/nanopi-m4-rk3399_defconfig @@ -5,7 +5,7 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y CONFIG_SPL_LIBGENERIC_SUPPORT=y CONFIG_SYS_MALLOC_F_LEN=0x4000 CONFIG_ROCKCHIP_RK3399=y -CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x4000 +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x5 CONFIG_DEBUG_UART_BASE=0xFF1A CONFIG_DEBUG_UART_CLOCK=2400 CONFIG_SPL_STACK_R_ADDR=0x8 @@ -14,9 +14,8 @@ CONFIG_NR_DRAM_BANKS=1 CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-nanopi-m4.dtb" # CONFIG_DISPLAY_CPUINFO is not set CONFIG_DISPLAY_BOARDINFO_LATE=y -CONFIG_SPL_TEXT_BASE=0xff8c2000 CONFIG_SPL_STACK_R=y -CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x4000 +CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x1 CONFIG_CMD_BOOTZ=y CONFIG_CMD_GPT=y CONFIG_CMD_MMC=y @@ -24,6 +23,7 @@ CONFIG_CMD_SF=y CONFIG_CMD_USB=y # CONFIG_CMD_SETEXPR is not set CONFIG_CMD_TIME=y +CONFIG_TPL=y CONFIG_SPL_OF_CONTROL=y CONFIG_DEFAULT_DEVICE_TREE="rk3399-nanopi-m4" CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents" @@ -56,4 +56,5 @@ CONFIG_USB_ETHER_MCS7830=y CONFIG_USB_ETHER_RTL8152=y CONFIG_USB_ETHER_SMSC95XX=y CONFIG_USE_TINY_PRINTF=y +CONFIG_SPL_TINY_MEMSET=y CONFIG_ERRNO_STR=y -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/3] doc: rockchip: Add doc for rk3399 TPL build/flash
This patch add documentation for TPL build and flashing steps for rk3399 boards. Add full boot log for future reference. Signed-off-by: Jagan Teki --- doc/README.rockchip | 51 - 1 file changed, 50 insertions(+), 1 deletion(-) diff --git a/doc/README.rockchip b/doc/README.rockchip index ca4d6473b0..264f7e4994 100644 --- a/doc/README.rockchip +++ b/doc/README.rockchip @@ -173,7 +173,10 @@ For example: => make u-boot.itb (Get spl/u-boot-spl-dtb.bin, u-boot.itb images and some boards would get - spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL) + spl/u-boot-spl.bin since it doesn't enable CONFIG_SPL_OF_CONTROL + + If TPL enabled on the target, get tpl/u-boot-tpl-dtb.bin or tpl/u-boot-tpl.bin + if CONFIG_TPL_OF_CONTROL not enabled) Writing to the board with USB = @@ -455,6 +458,52 @@ Net: eth0: ethernet@fe30 Hit any key to stop autoboot: 0 => +Option 3: Package the image with TPL: + + - Prefix rk3399 header to TPL image + +=> cd /path/to/u-boot +=> ./tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl-dtb.bin out + + - Concatinate tpl with spl + +=> cd /path/to/u-boot +=> cat ./spl/u-boot-spl-dtb.bin >> out + + - Write tpl+spl at 64th sector + +=> sudo dd if=out of=/dev/sdc seek=64 + + - Write U-Boot proper at 16384 sector + +=> sudo dd if=u-boot.itb of=/dev/sdc seek=16384 +=> sync + +Put this SD (or micro-SD) card into your board and reset it. You should see +something like: + +U-Boot TPL board init +Trying to boot from BOOTROM +Returning to boot ROM... + +U-Boot SPL board init +Trying to boot from MMC1 + + +U-Boot 2019.07-rc1-00241-g5b3244767a (May 08 2019 - 10:51:06 +0530) + +Model: Orange Pi RK3399 Board +DRAM: 2 GiB +MMC: dwmmc@fe31: 2, dwmmc@fe32: 1, sdhci@fe33: 0 +Loading Environment from MMC... OK +In:serial@ff1a +Out: serial@ff1a +Err: serial@ff1a +Model: Orange Pi RK3399 Board +Net: eth0: ethernet@fe30 +Hit any key to stop autoboot: 0 +=> + Using fastboot on rk3288 - Write GPT partition layout to mmc device which fastboot want to use it to -- 2.18.0.321.gffc6fa0e3 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: drop imx-regs.h
On Thu, May 9, 2019 at 5:33 AM Peng Fan wrote: > > imx-regs.h under arch-imx has no user, drop it. > > Signed-off-by: Peng Fan Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] imx: define ARCH_MXC for i.MX8/8M/7ULP
On Thu, May 9, 2019 at 5:33 AM Peng Fan wrote: > > Without this definition, fsl_esdhc will access reserved registers > on i.MX chips, so define ARCH_MXC to fix it. > > Signed-off-by: Peng Fan Reviewed-by: Fabio Estevam ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND
Hello Markus, Am 09.05.2019 um 10:59 schrieb Markus Klotzbuecher: Hello Heiko On Tue, Apr 30, 2019 at 06:54:01AM +0200, Heiko Schocher wrote: Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher: From: Markus Klotzbuecher please add a commit message. Signed-off-by: Markus Klotzbuecher Cc: Heiko Schocher Cc: Kyungmin Park --- env/Kconfig | 6 ++ scripts/config_whitelist.txt | 1 - 2 files changed, 6 insertions(+), 1 deletion(-) diff --git a/env/Kconfig b/env/Kconfig index 78300660c7..44c47220c2 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -513,6 +513,12 @@ config ENV_UBI_VOLUME help Name of the volume that you want to store the environment in. +config ENV_UBI_VOLUME_REDUND + string "UBI redundant volume name" + depends on ENV_IS_IN_UBI + help + Name of the redundant volume that you want to store the environment in. + endif config USE_DEFAULT_ENV_FILE diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt index fa98efc24c..5d76c781d3 100644 --- a/scripts/config_whitelist.txt +++ b/scripts/config_whitelist.txt @@ -504,7 +504,6 @@ CONFIG_ENV_SROM_BANK CONFIG_ENV_TOTAL_SIZE CONFIG_ENV_UBIFS_OPTION CONFIG_ENV_UBI_MTD -CONFIG_ENV_UBI_VOLUME_REDUND CONFIG_ENV_VERSION CONFIG_EP9302 CONFIG_EP9307 Please move from the config files: ./include/configs/omap3_igep00x0.h ./include/configs/gardena-smart-gateway-at91sam.h ./include/configs/am335x_igep003x.h also the symbols to the defconfig files, thanks. I have a question: to convert these, I need to make available the additional ENV_ configs to OMAP2PLUS and AT91: diff --git a/env/Kconfig b/env/Kconfig index 44c47220c2..1250656d74 100644 --- a/env/Kconfig +++ b/env/Kconfig @@ -470,7 +470,7 @@ config ENV_EXT4_FILE It's a string of the EXT4 file name. This file use to store the environment (explicit path to the file) -if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || ARC +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL || ARC || ARCH_OMAP2PLUS || ARCH_AT91 However, this "if" region contains a few other, non UBI settings such as ENV_SIZE, which would become visible to a large number of OMAP2PLUS and AT91 boards, which still define this in the headers. Huch? If so, than they are not converted (yet) ... :-( I'm a bit hesitant to touch all of these. What is the suggested way to solve this? I think, they should be converted too ... Sorry for the additional work ... I can understand your hesitantion to do such a conversion... Hmm... I used some year(s) ago tbot for checking, if a config change did not introduced diffs in created binaries for all boards [1] ... In principal I did: - build all boards with "SOURCE_DATE_EPOCH=0" and created a md5sum from each binary - apply patch(es) - build again, create md5sums and check if mdsum is the same Unfortunately not converted this testcase to the new tbot ... But may it is possible to convert this into a script ? bye, Heiko [1] https://github.com/hsdenx/tbot/blob/master/src/tc/uboot/tc_uboot_check_kconfig.py -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 01/18] i2c: omap24xx_i2c: Adapt driver to support K3 devices
Hello Andreas, Am 08.05.2019 um 23:37 schrieb Andreas Dannenberg: From: Vignesh R K3 devices have I2C IP that is same as OMAP2+ family. Allow driver to be compiled for ARCH_K3. Signed-off-by: Vignesh R Signed-off-by: Andreas Dannenberg --- drivers/i2c/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 02/18] arm: omap_i2c: Remove unwanted header file inclusion
Hello Andreas, Am 08.05.2019 um 23:37 schrieb Andreas Dannenberg: From: Vignesh R There is no need for to include this header here, so drop it. Signed-off-by: Vignesh R --- arch/arm/include/asm/omap_i2c.h | 2 -- 1 file changed, 2 deletions(-) Reviewed-by: Heiko Schocher bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
On Thu, May 09, 2019 at 12:15:34AM +0200, Graf, Alexander wrote:
>
> On 09.05.19 00:03, Heinrich Schuchardt wrote:
> >On 5/8/19 7:50 PM, Tom Rini wrote:
> >>On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
> >>
> >>>The following changes since commit
> >>>44237e272f1eac3b026709e76333a07b2d3a3523:
> >>>
> >>>Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
> >>>07:19:31 -0400)
> >>>
> >>>are available in the Git repository at:
> >>>
> >>>git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
> >>>
> >>>for you to fetch changes up to
> >>>b015ab57bf558daa1c768995a7a7f1df2d40191e:
> >>>
> >>>efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
> >>>+0200)
> >>>
> >>>Travis CI results are here:
> >>>https://travis-ci.org/xypron2/u-boot/builds/529448555
> >>>
> >>>Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC
> >>>2C05 1AC4
> >>>
> >>
> >>Note that you may want to run ./scripts/checkpatch.pl --git
> >>origin/master.. or similar as: WARNING: 'follwing' may be misspelled
> >>- perhaps 'following'?
> >>
> >>which I left alone rather than mess up the tag.
> >
> >Sorry I missed that one. Typically I run checkpatch.pl.
> >
> >>
> >>Applied to u-boot/master, thanks!
> >>
> >>And all of that said, looking over my before/after builds I see a lot
> >>of size growth, everywhere, due to EFI changes. I assume this is due
> >>to increasing overall functionality and support, which is good. But
> >>is there perhaps some way we can split things into a minimal "we
> >>have enough to support loading ${OS LOADER}" and then "we are aiming
> >>for large parts of spec compliance" ? Some days I start to wonder
> >>if "EFI_LOADER on by default" was a bad idea.
> >>
> >
> >The following switches allow to reduce the size of the UEFI subsystem:
> >
> >CONFIG_CMD_BOOTEFI_HELLO, default N
> >CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
> >CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
> >CONFIG_EFI_LOADER_HII
> >(The Makefile does not consider it yet correctly, patch submitted.)
> >CONFIG_CMD_EFIDEBUG, default N
> >CONFIG_CMD_NVEDIT_EFI
> >
> >In doc/README.uefi we describe that we target EBBR compatibility.
> >
> >We have implemented functionality that is not needed for EBBR
> >compatibility but is needed to run the EFI Shell and the conformance
> >tests or iPXE. Here we should think about making it customizable, e.g.
> >
> >lib/efi_loader/efi_bootmgr.c
> >lib/efi_driver/*
> >lib/efi_loader/efi_unicode_collation.c
> >lib/efi_loader/efi_variable.c
> >lib/efi_loader/device_path_to_text.c
> >lib/efi_loader/device_path_utilities.c
> >
> >For the Unicode collation protocol I just sent a patch.
>
>
> Do you have size estimates for how much each of those bits are? Where did we
> see the biggest growth? What eats up the most code/data space?
>
> I think we should aim to ideally incur less than 20kb overhead for an arm
> target. How far are we from that? We used to be at 10kb.
On am335x_evm disabling CONFIG_EFI_LOADER saves 51kb and on pine64-lts
disabling CONFIG_EFI_LOADER saves 75kb.
--
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 v2 0/2] Fix compilation error if CONFIG_USB is disabled
On 25/04/19, 7:07 PM, "Tom Rini" wrote: > On Thu, Apr 25, 2019 at 01:13:24PM +, Ajay Kaher wrote: > > > > Tom, [PATCH v2 1/2] reviewed by 'Matthias Brugger'. > > But no update on [Patch v2 2/2] (includes changes in include/configs/rpi.h) > > Since Matthias is the Pi custodian, I'm expecting a PR from him with the > changes. Thanks! Matthias, please let me know if you would require any info or detail from me to review [Patch v2 2/2]. To create the [Patch v2 2/2], I have taken the reference of include/configs/rockchip-common.h. Same changes are already present in include/configs/rockchip-common.h, hope this will help you to do review and PR. Thanks. - Ajay > > > > > > On 11/04/19, 10:56 AM, "akaher" wrote: > > > > Fix compilation error if CONFIG_USB is disabled > > > > [Patch v2 1/2]: > > CONFIG_CMD_USB depends upon CONFIG_USB, so CONFIG_CMD_USB > > should not be enabled if CONFIG_USB is disabled. > > > > [Patch v2 2/2]: > > This patch is to fix the following compilation error when > > disabling CONFIG_USB for Rpi3: > > > > include/config_distro_bootcmd.h:242:2: error: expected ‘}’ > > before ‘BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB’ > > BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB > > > > > > Changes from v1: > > Split the patch. > > > > > > cmd/Kconfig | 1 + > > include/configs/rpi.h | 36 +++- > > > > 2 file changed, 32 insertions(+), 5 deletions(-) > > > > -- > > 2.14.2 > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/2] Fix compilation error if CONFIG_USB is disabled
Hi Ajay, On 09/05/2019 13:26, Ajay Kaher wrote: > > > On 25/04/19, 7:07 PM, "Tom Rini" wrote: > >> On Thu, Apr 25, 2019 at 01:13:24PM +, Ajay Kaher wrote: >> > >> > Tom, [PATCH v2 1/2] reviewed by 'Matthias Brugger'. >> > But no update on [Patch v2 2/2] (includes changes in >> include/configs/rpi.h) >> >> Since Matthias is the Pi custodian, I'm expecting a PR from him with the >> changes. Thanks! > > Matthias, please let me know if you would require any info or detail from > me to review [Patch v2 2/2]. To create the [Patch v2 2/2], I have taken the > reference > of include/configs/rockchip-common.h. Same changes are already present in > include/configs/rockchip-common.h, hope this will help you to do review and > PR. Thanks. > It's on my list. On the first look it seems good for me. Bear with me, I'll take it netxt week and push it out. Regards, Matthias > - Ajay > >> > >> > >> > On 11/04/19, 10:56 AM, "akaher" wrote: >> > >> > Fix compilation error if CONFIG_USB is disabled >> > >> > [Patch v2 1/2]: >> > CONFIG_CMD_USB depends upon CONFIG_USB, so CONFIG_CMD_USB >> > should not be enabled if CONFIG_USB is disabled. >> > >> > [Patch v2 2/2]: >> > This patch is to fix the following compilation error when >> > disabling CONFIG_USB for Rpi3: >> > >> > include/config_distro_bootcmd.h:242:2: error: expected ‘}’ >> > before ‘BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB’ >> > BOOT_TARGET_DEVICES_references_USB_without_CONFIG_CMD_USB >> > >> > >> > Changes from v1: >> > Split the patch. >> > >> > >> > cmd/Kconfig | 1 + >> > include/configs/rpi.h | 36 +++- >> > >> > 2 file changed, 32 insertions(+), 5 deletions(-) >> > >> > -- >> > 2.14.2 >> > > > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Hi, On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > Hi Paul, > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > wrote: > > Hi, > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > This is v7 resend patchset for New rk3399 boards support wrt previous > > > version[1] > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > orangepi rk3399 changes are merged, so this is rework on top of > > > u-boot-rockchip/master. > > > > > > Overall this series add support below rk3399 boards > > > - NanoPI M4 > > > - NanoPC T4 > > > - NanoPI NEO4 > > > - Orangepi RK3399 > > > - Rock PI 4 > > > - Rockpro64 > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > > > dts(i) from linux-next. > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > > > series [3]. > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > > > booting via Rockchip miniloader as of now. > > > > Could you send these two boards in a separate series so that we avoid > > merging them for now (because SPL support is broken) and then re- > > iterate the series later with the DDR bringup? Or maybe find a way to > > disable SPL support, but in any case, it's not ok to merge a board with > > SPL enabled and broken. > > I have explained the details about this concern on v2 [1], thought you > would comeback on the same line instead here. Yes, you have already explained the issue, but I don't think it's enough a justification to merge broken SPL support. If it was only partial or limited, it would be fine, but here it's just broken. > Anyway, making SPL as an optional is not an idea to go with Mainline > as we make many decisions with regards to make SPL is mandatory. Yes I think making SPL mandatory is a good idea, so that's why I'm suggesting that we don't merge the boards until they have SPL support. > Since the DDR is show stopper here (and it would really need a good > amount of time, since it effect the other boards), I can go with TPL > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > booting stages. This way we can avoid skipping SPL usage, and many > config changes to make SPL optional. Honestly I don't really see the point of merging these boards at all if they don't have SPL support. People who really want to use them with the rockchip blob can cherry-pick the patches from the list in the meantime. It also creates incentive for people to free the DDR init, since that becomes a condition to have the board upstream. What do you think? Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski wrote: > > Hi, > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > Hi Paul, > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > wrote: > > > Hi, > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt previous > > > > version[1] > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > u-boot-rockchip/master. > > > > > > > > Overall this series add support below rk3399 boards > > > > - NanoPI M4 > > > > - NanoPC T4 > > > > - NanoPI NEO4 > > > > - Orangepi RK3399 > > > > - Rock PI 4 > > > > - Rockpro64 > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > > > > dts(i) from linux-next. > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > > > > series [3]. > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > > > > booting via Rockchip miniloader as of now. > > > > > > Could you send these two boards in a separate series so that we avoid > > > merging them for now (because SPL support is broken) and then re- > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > disable SPL support, but in any case, it's not ok to merge a board with > > > SPL enabled and broken. > > > > I have explained the details about this concern on v2 [1], thought you > > would comeback on the same line instead here. > > Yes, you have already explained the issue, but I don't think it's > enough a justification to merge broken SPL support. If it was only > partial or limited, it would be fine, but here it's just broken. > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > as we make many decisions with regards to make SPL is mandatory. > > Yes I think making SPL mandatory is a good idea, so that's why I'm > suggesting that we don't merge the boards until they have SPL support. > > > Since the DDR is show stopper here (and it would really need a good > > amount of time, since it effect the other boards), I can go with TPL > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > booting stages. This way we can avoid skipping SPL usage, and many > > config changes to make SPL optional. > > Honestly I don't really see the point of merging these boards at all if > they don't have SPL support. People who really want to use them with > the rockchip blob can cherry-pick the patches from the list in the > meantime. > > It also creates incentive for people to free the DDR init, since that > becomes a condition to have the board upstream. > > What do you think? I don't know whether you get my point or not? these boards are not merged yet. What I'm saying is we are going to support them with TPL-enabled, that was SPL can make use of these boards which still a valid boot-chain. moreover this way can avoid touching core files and no specific change require while supporting ddr dtsi. Jagan. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
On Thu, 2019-05-09 at 18:06 +0530, Jagan Teki wrote: > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > wrote: > > Hi, > > > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > > Hi Paul, > > > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > > wrote: > > > > Hi, > > > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt previous > > > > > version[1] > > > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > > u-boot-rockchip/master. > > > > > > > > > > Overall this series add support below rk3399 boards > > > > > - NanoPI M4 > > > > > - NanoPC T4 > > > > > - NanoPI NEO4 > > > > > - Orangepi RK3399 > > > > > - Rock PI 4 > > > > > - Rockpro64 > > > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > > > > > dts(i) from linux-next. > > > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of > > > > > another > > > > > series [3]. > > > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would > > > > > support > > > > > booting via Rockchip miniloader as of now. > > > > > > > > Could you send these two boards in a separate series so that we avoid > > > > merging them for now (because SPL support is broken) and then re- > > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > > disable SPL support, but in any case, it's not ok to merge a board with > > > > SPL enabled and broken. > > > > > > I have explained the details about this concern on v2 [1], thought you > > > would comeback on the same line instead here. > > > > Yes, you have already explained the issue, but I don't think it's > > enough a justification to merge broken SPL support. If it was only > > partial or limited, it would be fine, but here it's just broken. > > > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > > as we make many decisions with regards to make SPL is mandatory. > > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > > suggesting that we don't merge the boards until they have SPL support. > > > > > Since the DDR is show stopper here (and it would really need a good > > > amount of time, since it effect the other boards), I can go with TPL > > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > > booting stages. This way we can avoid skipping SPL usage, and many > > > config changes to make SPL optional. > > > > Honestly I don't really see the point of merging these boards at all if > > they don't have SPL support. People who really want to use them with > > the rockchip blob can cherry-pick the patches from the list in the > > meantime. > > > > It also creates incentive for people to free the DDR init, since that > > becomes a condition to have the board upstream. > > > > What do you think? > > I don't know whether you get my point or not? these boards are not > merged yet. What I'm saying is we are going to support them with > TPL-enabled, that was SPL can make use of these boards which still a > valid boot-chain. moreover this way can avoid touching core files and > no specific change require while supporting ddr dtsi. Ah maybe I missed the point indeed. So what you are suggesting is: rkboot (acts as TPL) -> SPL -> U-Boot? Then I have no problem what that. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Jagan, > On 09.05.2019, at 14:36, Jagan Teki wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > mailto:paul.kocialkow...@bootlin.com>> wrote: >> >> Hi, >> >> On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: >>> Hi Paul, >>> >>> On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski >>> wrote: Hi, On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > (Sorry for the noice, I have missed to send two patches from v7) > > This is v7 resend patchset for New rk3399 boards support wrt previous > version[1] > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > orangepi rk3399 changes are merged, so this is rework on top of > u-boot-rockchip/master. > > Overall this series add support below rk3399 boards > - NanoPI M4 > - NanoPC T4 > - NanoPI NEO4 > - Orangepi RK3399 > - Rock PI 4 > - Rockpro64 > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > dts(i) from linux-next. > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > series [3]. > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > booting via Rockchip miniloader as of now. Could you send these two boards in a separate series so that we avoid merging them for now (because SPL support is broken) and then re- iterate the series later with the DDR bringup? Or maybe find a way to disable SPL support, but in any case, it's not ok to merge a board with SPL enabled and broken. >>> >>> I have explained the details about this concern on v2 [1], thought you >>> would comeback on the same line instead here. >> >> Yes, you have already explained the issue, but I don't think it's >> enough a justification to merge broken SPL support. If it was only >> partial or limited, it would be fine, but here it's just broken. >> >>> Anyway, making SPL as an optional is not an idea to go with Mainline >>> as we make many decisions with regards to make SPL is mandatory. >> >> Yes I think making SPL mandatory is a good idea, so that's why I'm >> suggesting that we don't merge the boards until they have SPL support. >> >>> Since the DDR is show stopper here (and it would really need a good >>> amount of time, since it effect the other boards), I can go with TPL >>> enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of >>> booting stages. This way we can avoid skipping SPL usage, and many >>> config changes to make SPL optional. >> >> Honestly I don't really see the point of merging these boards at all if >> they don't have SPL support. People who really want to use them with >> the rockchip blob can cherry-pick the patches from the list in the >> meantime. >> >> It also creates incentive for people to free the DDR init, since that >> becomes a condition to have the board upstream. >> >> What do you think? > > I don't know whether you get my point or not? these boards are not > merged yet. What I'm saying is we are going to support them with > TPL-enabled, that was SPL can make use of these boards which still a > valid boot-chain. moreover this way can avoid touching core files and > no specific change require while supporting ddr dtsi. On some boards, there will be no TPL and only a SPL stage that will initialise DRAM (as the move to having TPL on the RK3399 is optional). I agree with Paul that the DRAM init should be part of U-Boot whenever we add new boards and make an open DRAM init a prerequisite. Thanks, Philipp. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
On Thu, May 9, 2019 at 6:09 PM Paul Kocialkowski wrote: > > On Thu, 2019-05-09 at 18:06 +0530, Jagan Teki wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > > wrote: > > > Hi, > > > > > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > > > Hi Paul, > > > > > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > > > wrote: > > > > > Hi, > > > > > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt > > > > > > previous > > > > > > version[1] > > > > > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > > > u-boot-rockchip/master. > > > > > > > > > > > > Overall this series add support below rk3399 boards > > > > > > - NanoPI M4 > > > > > > - NanoPC T4 > > > > > > - NanoPI NEO4 > > > > > > - Orangepi RK3399 > > > > > > - Rock PI 4 > > > > > > - Rockpro64 > > > > > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and > > > > > > few > > > > > > dts(i) from linux-next. > > > > > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of > > > > > > another > > > > > > series [3]. > > > > > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would > > > > > > support > > > > > > booting via Rockchip miniloader as of now. > > > > > > > > > > Could you send these two boards in a separate series so that we avoid > > > > > merging them for now (because SPL support is broken) and then re- > > > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > > > disable SPL support, but in any case, it's not ok to merge a board > > > > > with > > > > > SPL enabled and broken. > > > > > > > > I have explained the details about this concern on v2 [1], thought you > > > > would comeback on the same line instead here. > > > > > > Yes, you have already explained the issue, but I don't think it's > > > enough a justification to merge broken SPL support. If it was only > > > partial or limited, it would be fine, but here it's just broken. > > > > > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > > > as we make many decisions with regards to make SPL is mandatory. > > > > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > > > suggesting that we don't merge the boards until they have SPL support. > > > > > > > Since the DDR is show stopper here (and it would really need a good > > > > amount of time, since it effect the other boards), I can go with TPL > > > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > > > booting stages. This way we can avoid skipping SPL usage, and many > > > > config changes to make SPL optional. > > > > > > Honestly I don't really see the point of merging these boards at all if > > > they don't have SPL support. People who really want to use them with > > > the rockchip blob can cherry-pick the patches from the list in the > > > meantime. > > > > > > It also creates incentive for people to free the DDR init, since that > > > becomes a condition to have the board upstream. > > > > > > What do you think? > > > > I don't know whether you get my point or not? these boards are not > > merged yet. What I'm saying is we are going to support them with > > TPL-enabled, that was SPL can make use of these boards which still a > > valid boot-chain. moreover this way can avoid touching core files and > > no specific change require while supporting ddr dtsi. > > Ah maybe I missed the point indeed. > > So what you are suggesting is: > rkboot (acts as TPL) -> SPL -> U-Boot? Exactly, to make it confirm. Here is boot-chain on NEO4: DDR Version 1.20 20190314 In Channel 0: DDR3, 800MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB no stride ch 0 ddrconfig = 0x101, ddrsize = 0x20 pmugrf_os_reg[2] = 0x10006281, stride = 0x17 OUT U-Boot SPL 2019.07-rc1-00243-gbd57cc7444 (May 09 2019 - 18:10:25 +0530) Trying to boot from MMC1 U-Boot 2019.07-rc1-00243-gbd57cc7444 (May 09 2019 - 18:12:59 +0530) Model: FriendlyARM NanoPi NEO4 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-net.git master
On 09.05.2019 02:05, Vladimir Oltean wrote: > On 5/9/19 1:55 AM, Tom Rini wrote: >> On Wed, May 08, 2019 at 10:52:28PM +, Vladimir Oltean wrote: >>> On 5/9/19 1:48 AM, Tom Rini wrote: On Wed, May 08, 2019 at 10:45:50PM +, Vladimir Oltean wrote: > On 5/9/19 1:42 AM, Tom Rini wrote: >> On Wed, May 08, 2019 at 10:40:57PM +, Vladimir Oltean wrote: >>> On 5/9/19 1:24 AM, Joe Hershberger wrote: On Tue, May 7, 2019 at 5:15 PM Joe Hershberger wrote: > > Hi Tom, > > The following changes since commit > 8d7f06bbbef16f172cd5e9c4923cdcebe16b8980: > > I rebased on your master and built for BB Black. DHCP seems to work > fine. > MLO also now fits again. > >Merge branch 'master' of git://git.denx.de/u-boot-sh > (2019-05-07 09:38:00 -0400) > > are available in the git repository at: > >git://git.denx.de/u-boot-net.git master > > for you to fetch changes up to > 8d0c6858455e89b089222a08d55ff711681ca011: > >net: phy: micrel: Find Micrel PHY node correctly (2019-05-07 > 14:51:55 -0500) > > > Carlo Caione (4): >net: phy: Add generic helpers to access MMD PHY registers >net: phy: ti: use generic helpers to access MMD registers >cmd: mdio: Switch to generic helpers when accessing the > registers >net: phy: realtek: Introduce quirk to mark RXC not > stoppable > > James Byrne (2): >net: phy: micrel: Use correct skew values on KSZ9021 >net: phy: micrel: Find Micrel PHY node correctly > > Murali Karicheri (2): >ARM: k2g-gp-evm: update to rgmii pinmux configuration >ARM: k2g-ice: Add pinmux support for rgmii interface > > Pankaj Bansal (1): >drivers: net: ldpaa_eth: fix resource leak > > Siva Durga Prasad Paladugu (2): >net: phy: Reloc next and prev pointers inside phy_drivers >net: phy: Fix return value check phy_probe > > Valentin-catalin Neacsu (1): >net: phy: aquantia: Set only autoneg on in register 4.c441 > > Vladimir Oltean (6): >net: phy: ar803x: Address packet drops at low traffic rate > due to SmartEEE feature >net: phy: ar803x: Make RGMII Tx delays actually > configurable for AR8035 >net: phy: ar803x: Use common functions for RGMII internal > delays >net: phy: ar803x: Clarify the configuration of the CLK_25M > output pin >net: phy: ar803x: Explicitly disable RGMII delays Tom, this [1] is the patch that is breaking the evm. It doesn't affect BB Black because it uses an SMSC phy, where as this evm uses an AR8031/AR8033. Is it possible the device tree [2] is wrong for the board? It lists 'phy-mode = "rgmii-txid";', so that means that with this patch the RX delay is now being disabled. Any thoughts, Vladimir? Thanks, -Joe [1] b3224e0f7e - "net: phy: ar803x: Explicitly disable RGMII delays" [2] arch/arm/dts/am335x-evm.dts >net: phy: ar803x: Clarify the intention of ar8021_config > > arch/arm/dts/sama5d3xcm.dtsi| 32 +++--- > arch/arm/dts/sama5d3xcm_cmp.dtsi| 32 +++--- > arch/arm/dts/socfpga_arria5_socdk.dts | 4 +- > arch/arm/dts/socfpga_cyclone5_is1.dts | 4 +- > arch/arm/dts/socfpga_cyclone5_socdk.dts | 4 +- > arch/arm/dts/socfpga_cyclone5_sockit.dts| 4 +- > arch/arm/dts/socfpga_cyclone5_vining_fpga.dts | 4 +- > board/ti/ks2_evm/mux-k2g.h | 36 +++ > cmd/mdio.c | 27 +++-- > doc/device-tree-bindings/net/micrel-ksz90x1.txt | 27 + > drivers/net/ldpaa_eth/ldpaa_eth.c | 1 + > drivers/net/phy/Kconfig | 41 > drivers/net/phy/aquantia.c | 7 +- > drivers/net/phy/atheros.c | 128 > --- > drivers/net/phy/micrel_ksz90x1.c| 24 - > drivers/net/phy/phy.c | 21 +++- > drivers/net/phy/realtek.c
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Hi, On Thu, 2019-05-09 at 14:40 +0200, Philipp Tomsich wrote: > Jagan, > > > On 09.05.2019, at 14:36, Jagan Teki wrote: > > > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > > wrote: > > > Hi, > > > > > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > > > Hi Paul, > > > > > > > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > > > > wrote: > > > > > Hi, > > > > > > > > > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > > > > > (Sorry for the noice, I have missed to send two patches from v7) > > > > > > > > > > > > This is v7 resend patchset for New rk3399 boards support wrt > > > > > > previous > > > > > > version[1] > > > > > > > > > > > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > > > > > > orangepi rk3399 changes are merged, so this is rework on top of > > > > > > u-boot-rockchip/master. > > > > > > > > > > > > Overall this series add support below rk3399 boards > > > > > > - NanoPI M4 > > > > > > - NanoPC T4 > > > > > > - NanoPI NEO4 > > > > > > - Orangepi RK3399 > > > > > > - Rock PI 4 > > > > > > - Rockpro64 > > > > > > > > > > > > All the respective dts(i) files are synced from Linux 5.1-rc2 and > > > > > > few > > > > > > dts(i) from linux-next. > > > > > > > > > > > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of > > > > > > another > > > > > > series [3]. > > > > > > > > > > > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would > > > > > > support > > > > > > booting via Rockchip miniloader as of now. > > > > > > > > > > Could you send these two boards in a separate series so that we avoid > > > > > merging them for now (because SPL support is broken) and then re- > > > > > iterate the series later with the DDR bringup? Or maybe find a way to > > > > > disable SPL support, but in any case, it's not ok to merge a board > > > > > with > > > > > SPL enabled and broken. > > > > > > > > I have explained the details about this concern on v2 [1], thought you > > > > would comeback on the same line instead here. > > > > > > Yes, you have already explained the issue, but I don't think it's > > > enough a justification to merge broken SPL support. If it was only > > > partial or limited, it would be fine, but here it's just broken. > > > > > > > Anyway, making SPL as an optional is not an idea to go with Mainline > > > > as we make many decisions with regards to make SPL is mandatory. > > > > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > > > suggesting that we don't merge the boards until they have SPL support. > > > > > > > Since the DDR is show stopper here (and it would really need a good > > > > amount of time, since it effect the other boards), I can go with TPL > > > > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > > > > booting stages. This way we can avoid skipping SPL usage, and many > > > > config changes to make SPL optional. > > > > > > Honestly I don't really see the point of merging these boards at all if > > > they don't have SPL support. People who really want to use them with > > > the rockchip blob can cherry-pick the patches from the list in the > > > meantime. > > > > > > It also creates incentive for people to free the DDR init, since that > > > becomes a condition to have the board upstream. > > > > > > What do you think? > > > > I don't know whether you get my point or not? these boards are not > > merged yet. What I'm saying is we are going to support them with > > TPL-enabled, that was SPL can make use of these boards which still a > > valid boot-chain. moreover this way can avoid touching core files and > > no specific change require while supporting ddr dtsi. > > On some boards, there will be no TPL and only a SPL stage that will > initialise DRAM (as the move to having TPL on the RK3399 is optional). > > I agree with Paul that the DRAM init should be part of U-Boot whenever > we add new boards and make an open DRAM init a prerequisite. Well, my initial point was to forbid merging broken SPL support, but I am totally in favor of requiring free DRAM init for merging new boards. Sadly it's hard to enforce this as a general rule in U-Boot since some platforms are plagued by non-free first-stage bootloaders because of signature checks, and that's where DRAM init happens. But for RK3399, we can totally have that rule, which directly creates incentive to free the blobs. Cheers, Paul -- Paul Kocialkowski, Bootlin Embedded Linux and kernel engineering https://bootlin.com ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH v7 00/11] rockchip: Add new rk3399 boards
Hi Philipp, On Thu, May 9, 2019 at 6:10 PM Philipp Tomsich wrote: > > Jagan, > > On 09.05.2019, at 14:36, Jagan Teki wrote: > > On Thu, May 9, 2019 at 6:01 PM Paul Kocialkowski > wrote: > > > Hi, > > On Thu, 2019-05-09 at 16:15 +0530, Jagan Teki wrote: > > Hi Paul, > > On Thu, May 9, 2019 at 12:38 PM Paul Kocialkowski > wrote: > > Hi, > > On Wed, 2019-05-08 at 11:11 +0530, Jagan Teki wrote: > > (Sorry for the noice, I have missed to send two patches from v7) > > This is v7 resend patchset for New rk3399 boards support wrt previous > version[1] > > Unfortunately initial version of creating rk3399-u-boot.dtsi and > orangepi rk3399 changes are merged, so this is rework on top of > u-boot-rockchip/master. > > Overall this series add support below rk3399 boards > - NanoPI M4 > - NanoPC T4 > - NanoPI NEO4 > - Orangepi RK3399 > - Rock PI 4 > - Rockpro64 > > All the respective dts(i) files are synced from Linux 5.1-rc2 and few > dts(i) from linux-next. > > SoC u-boot specific dtsi rk3399-u-boot.dtsi changes are part of another > series [3]. > > Out of all above boards Rockpor64, Rock-PI and Nanopi NEO4 would support > booting via Rockchip miniloader as of now. > > > Could you send these two boards in a separate series so that we avoid > merging them for now (because SPL support is broken) and then re- > iterate the series later with the DDR bringup? Or maybe find a way to > disable SPL support, but in any case, it's not ok to merge a board with > SPL enabled and broken. > > > I have explained the details about this concern on v2 [1], thought you > would comeback on the same line instead here. > > > Yes, you have already explained the issue, but I don't think it's > enough a justification to merge broken SPL support. If it was only > partial or limited, it would be fine, but here it's just broken. > > Anyway, making SPL as an optional is not an idea to go with Mainline > as we make many decisions with regards to make SPL is mandatory. > > > Yes I think making SPL mandatory is a good idea, so that's why I'm > suggesting that we don't merge the boards until they have SPL support. > > Since the DDR is show stopper here (and it would really need a good > amount of time, since it effect the other boards), I can go with TPL > enabled boot-chain where ddr bin, SPL and U-Boot proper can be part of > booting stages. This way we can avoid skipping SPL usage, and many > config changes to make SPL optional. > > > Honestly I don't really see the point of merging these boards at all if > they don't have SPL support. People who really want to use them with > the rockchip blob can cherry-pick the patches from the list in the > meantime. > > It also creates incentive for people to free the DDR init, since that > becomes a condition to have the board upstream. > > What do you think? > > > I don't know whether you get my point or not? these boards are not > merged yet. What I'm saying is we are going to support them with > TPL-enabled, that was SPL can make use of these boards which still a > valid boot-chain. moreover this way can avoid touching core files and > no specific change require while supporting ddr dtsi. > > > On some boards, there will be no TPL and only a SPL stage that will > initialise DRAM (as the move to having TPL on the RK3399 is optional). True, my suggestion here the same. SPL is mandatory. > > I agree with Paul that the DRAM init should be part of U-Boot whenever > we add new boards and make an open DRAM init a prerequisite. True, I agree this point. Since we have an option of having DRAM init at TPL I'm proposing this boot-chain (along with commitment on dram work). ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> Hey folks,
>
> I'm attempting, again, to see what we need to do in order to use gcc-8.x
> for U-Boot and ran into, again:
> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
> using -mcpu=xscale gcc-8.x throws an odd error:
> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch [-Werror]
>
> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
> suggests perhaps something broke in upstream gcc. Looking at the
> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
> leads to different failures (seen here with gcc-7.3):
> CC drivers/usb/gadget/pxa25x_udc.o
> {standard input}: Assembler messages:
> {standard input}:779: Error: selected processor does not support `pld [lr]'
> in ARM mode
> {standard input}:1201: Error: selected processor does not support `pld [r7]'
> in ARM mode
> {standard input}:2519: Error: selected processor does not support `pld [r3]'
> in ARM mode
> {standard input}:2796: Error: selected processor does not support `pld [r3]'
> in ARM mode
>
> So, what should we do about this? Is there still active interest in
> supporting the PXA platforms? Thanks folks!
ping? 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] [PATCH 8/8] spi: Kconfig: Mark LPC32XX_SSP has BROKEN
Acked-by: Sylvain Lemieux On Tue, Apr 30, 2019 at 4:48 PM Vladimir Zapolskiy wrote: > > Hi Jagan, > > On 04/28/2019 11:48 PM, Jagan Teki wrote: > > Mark LPC32XX_SSP has BROKEN, this so the resulting build shows > > warning for broken configuration enabled and associated code > > will remove in v2019.07 release. > > > > Cc: Vladimir Zapolskiy > > Cc: Albert ARIBAUD > > Signed-off-by: Jagan Teki > > --- > > drivers/spi/Kconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig > > index 55f0d6cf2b..5fbe17bb20 100644 > > --- a/drivers/spi/Kconfig > > +++ b/drivers/spi/Kconfig > > @@ -369,6 +369,7 @@ config KIRKWOOD_SPI > > > > config LPC32XX_SSP > > bool "LPC32XX SPI Driver" > > + select BROKEN > > help > > Enable support for SPI on LPC32xx > > > > > > Acked-by: Vladimir Zapolskiy > > Thank you for the change, as we've discussed earlier I won't have > objections against the driver removal when time is up. > > Thus you can locally prepare a removal change in advance, the one > which you've sent earlier needs a minor update, please also remove > lpc32xx_ssp_init() function and its usage in the board files. > > -- > Best wishes, > Vladimir ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] armv8: ls1046afrwy: Add support for LS1046AFRWY platform
LS1046AFRWY board supports LS1046A family SoCs. This patch add base support for this board. Board support's 4GB ddr memory, i2c, micro-click module,microSD card, serial console,qspi nor flash,ifc nand flash,qsgmii network interface, usb 3.0 and serdes interface to support two x1gen3 pcie interface. Signed-off-by: Camelia Groza Signed-off-by: Madalin Bucur Signed-off-by: Pankit Garg Signed-off-by: Pramod Kumar Signed-off-by: Rajesh Bhagat Signed-off-by: Vabhav Sharma --- arch/arm/Kconfig | 17 ++ arch/arm/cpu/armv8/Kconfig | 1 + arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c | 2 + arch/arm/dts/Makefile | 1 + arch/arm/dts/fsl-ls1046a-frwy.dts | 34 +++ board/freescale/ls1046afrwy/Kconfig| 17 ++ board/freescale/ls1046afrwy/MAINTAINERS| 17 ++ board/freescale/ls1046afrwy/Makefile | 9 + board/freescale/ls1046afrwy/README | 76 +++ board/freescale/ls1046afrwy/ddr.c | 24 ++ board/freescale/ls1046afrwy/eth.c | 114 ++ board/freescale/ls1046afrwy/ls1046afrwy.c | 249 + board/freescale/ls1046afrwy/ls1046afrwy_pbi.cfg| 22 ++ .../freescale/ls1046afrwy/ls1046afrwy_qspi_pbi.cfg | 26 +++ .../freescale/ls1046afrwy/ls1046afrwy_rcw_qspi.cfg | 7 + board/freescale/ls1046afrwy/ls1046afrwy_rcw_sd.cfg | 7 + configs/ls1046afrwy_tfa_defconfig | 58 + include/configs/ls1046a_common.h | 13 +- include/configs/ls1046afrwy.h | 204 + include/fm_eth.h | 12 + 20 files changed, 908 insertions(+), 2 deletions(-) create mode 100644 arch/arm/dts/fsl-ls1046a-frwy.dts create mode 100644 board/freescale/ls1046afrwy/Kconfig create mode 100644 board/freescale/ls1046afrwy/MAINTAINERS create mode 100644 board/freescale/ls1046afrwy/Makefile create mode 100644 board/freescale/ls1046afrwy/README create mode 100644 board/freescale/ls1046afrwy/ddr.c create mode 100644 board/freescale/ls1046afrwy/eth.c create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy.c create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy_pbi.cfg create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy_qspi_pbi.cfg create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy_rcw_qspi.cfg create mode 100644 board/freescale/ls1046afrwy/ls1046afrwy_rcw_sd.cfg create mode 100644 configs/ls1046afrwy_tfa_defconfig create mode 100644 include/configs/ls1046afrwy.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index f91c590..15699a2 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1329,6 +1329,22 @@ config TARGET_LS1046ARDB development platform that supports the QorIQ LS1046A Layerscape Architecture processor. +config TARGET_LS1046AFRWY + bool "Support ls1046afrwy" + select ARCH_LS1046A + select ARM64 + select ARMV8_MULTIENTRY + select BOARD_EARLY_INIT_F + select BOARD_LATE_INIT + select DM_SPI_FLASH if DM_SPI + select POWER_MC34VR500 + select SUPPORT_SPL + imply SCSI + help + Support for Freescale LS1046AFRWY platform. + The LS1046A Freeway Board (FRWY) is a high-performance + development platform that supports the QorIQ LS1046A + Layerscape Architecture processor. config TARGET_H2200 bool "Support h2200" select CPU_PXA @@ -1617,6 +1633,7 @@ source "board/freescale/ls1021aiot/Kconfig" source "board/freescale/ls1046aqds/Kconfig" source "board/freescale/ls1043ardb/Kconfig" source "board/freescale/ls1046ardb/Kconfig" +source "board/freescale/ls1046afrwy/Kconfig" source "board/freescale/ls1012aqds/Kconfig" source "board/freescale/ls1012ardb/Kconfig" source "board/freescale/ls1012afrdm/Kconfig" diff --git a/arch/arm/cpu/armv8/Kconfig b/arch/arm/cpu/armv8/Kconfig index 7405c3a..ed31df1 100644 --- a/arch/arm/cpu/armv8/Kconfig +++ b/arch/arm/cpu/armv8/Kconfig @@ -106,6 +106,7 @@ config PSCI_RESET !TARGET_LS1012AFRWY && \ !TARGET_LS1043ARDB && !TARGET_LS1043AQDS && \ !TARGET_LS1046ARDB && !TARGET_LS1046AQDS && \ + !TARGET_LS1046AFRWY && \ !TARGET_LS2081ARDB && !TARGET_LX2160ARDB && \ !TARGET_LX2160AQDS && \ !ARCH_UNIPHIER && !TARGET_S32V234EVB diff --git a/arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c b/arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c index f8310f2..caa4862 100644 --- a/arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c +++ b/arch/arm/cpu/armv8/fsl-layerscape/ls1046a_serdes.c @@ -1,6 +1,7 @@ // SPDX-License-Identifier: GPL-2.0+ /* * Copyright 2016 Freescale Semiconductor, Inc. + * Copyright 2019 NXP */ #include @@ -33,6 +34,7 @@ static struct serdes_config serdes1_cfg_tb
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
On Thu, May 09, 2019 at 12:03:38AM +0200, Heinrich Schuchardt wrote:
> On 5/8/19 7:50 PM, Tom Rini wrote:
> >On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
> >
> >>The following changes since commit
> >>44237e272f1eac3b026709e76333a07b2d3a3523:
> >>
> >>Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
> >>07:19:31 -0400)
> >>
> >>are available in the Git repository at:
> >>
> >>git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
> >>
> >>for you to fetch changes up to
> >>b015ab57bf558daa1c768995a7a7f1df2d40191e:
> >>
> >>efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
> >>+0200)
> >>
> >>Travis CI results are here:
> >>https://travis-ci.org/xypron2/u-boot/builds/529448555
> >>
> >>Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC
> >>2C05 1AC4
> >>
> >
> >Note that you may want to run ./scripts/checkpatch.pl --git
> >origin/master.. or similar as: WARNING: 'follwing' may be misspelled
> >- perhaps 'following'?
> >
> >which I left alone rather than mess up the tag.
>
> Sorry I missed that one. Typically I run checkpatch.pl.
>
> >
> >Applied to u-boot/master, thanks!
> >
> >And all of that said, looking over my before/after builds I see a lot
> >of size growth, everywhere, due to EFI changes. I assume this is due
> >to increasing overall functionality and support, which is good. But
> >is there perhaps some way we can split things into a minimal "we
> >have enough to support loading ${OS LOADER}" and then "we are aiming
> >for large parts of spec compliance" ? Some days I start to wonder
> >if "EFI_LOADER on by default" was a bad idea.
> >
>
> The following switches allow to reduce the size of the UEFI subsystem:
>
> CONFIG_CMD_BOOTEFI_HELLO, default N
> CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
Note there's 2 non-QEMU platforms enabling it, can you please add a
patch turning it off and cc'ing the maintainer as they probably didn't
really mean to have that on? It's also not on for riscv QEMU nor
sandbox but should be?
> CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
> CONFIG_EFI_LOADER_HII
> (The Makefile does not consider it yet correctly, patch submitted.)
> CONFIG_CMD_EFIDEBUG, default N
> CONFIG_CMD_NVEDIT_EFI
Adding in:
commit 7494b7764508332e37a3375fa0b6c328bc34637f
Author: Tom Rini
Date: Thu May 9 10:06:40 2019 -0400
LOCAL: Disable some EFI stuff by default
Signed-off-by: Tom Rini
diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4e11e0f404c8..4ebaf2f5bcb9 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -238,7 +238,6 @@ config CMD_BOOTEFI
config CMD_BOOTEFI_HELLO_COMPILE
bool "Compile a standard EFI hello world binary for testing"
depends on CMD_BOOTEFI && !CPU_V7M && !SANDBOX
- default y
help
This compiles a standard EFI hello world application with U-Boot so
that it can be used with the test/py testing framework. This is useful
@@ -434,7 +433,6 @@ config CMD_ENV_FLAGS
config CMD_NVEDIT_EFI
bool "env [set|print] -e - set/print UEFI variables"
depends on EFI_LOADER
- default y
imply HEXDUMP
help
UEFI variables are encoded as some form of U-Boot variables.
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 50b050159c37..bd8fb9be00bc 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -19,7 +19,6 @@ config EFI_LOADER
config EFI_UNICODE_CAPITALIZATION
bool "Support Unicode capitalization"
depends on EFI_LOADER
- default y
help
Select this option to enable correct handling of the capitalization of
Unicode codepoints in the range 0x-0x. If this option is not
@@ -48,7 +47,6 @@ config EFI_LOADER_BOUNCE_BUFFER
config EFI_LOADER_HII
bool "Expose HII protocols to EFI applications"
depends on EFI_LOADER
- default y
help
The Human Interface Infrastructure is a complicated framework that
allows UEFI applications to draw fancy menus and hook strings using
And note that with the bugfix to the Makefile for EFI_LOADER_HII added,
there's either more to be done, or it was already being discarded at
link time as applying that patch on top of this didn't result in any
size savings. Doing the above saves about 10kb. Which helps, but with
the numbers I mentioned earlier still puts us at about 40kb which Alex
was hoping it should be closer to 20kb. Is there more we can do here?
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] U-Boot PXA support
On 5/9/19 4:02 PM, Tom Rini wrote:
> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
>
>> Hey folks,
>>
>> I'm attempting, again, to see what we need to do in order to use gcc-8.x
>> for U-Boot and ran into, again:
>> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
>> using -mcpu=xscale gcc-8.x throws an odd error:
>> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch
>> [-Werror]
>>
>> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
>> suggests perhaps something broke in upstream gcc. Looking at the
>> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
>> leads to different failures (seen here with gcc-7.3):
>> CC drivers/usb/gadget/pxa25x_udc.o
>> {standard input}: Assembler messages:
>> {standard input}:779: Error: selected processor does not support `pld [lr]'
>> in ARM mode
>> {standard input}:1201: Error: selected processor does not support `pld [r7]'
>> in ARM mode
>> {standard input}:2519: Error: selected processor does not support `pld [r3]'
>> in ARM mode
>> {standard input}:2796: Error: selected processor does not support `pld [r3]'
>> in ARM mode
>>
>> So, what should we do about this? Is there still active interest in
>> supporting the PXA platforms? Thanks folks!
>
> ping? Thanks!
Maybe we should just remove it.
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
>
> On 5/9/19 4:02 PM, Tom Rini wrote:
> > On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> >
> >> Hey folks,
> >>
> >> I'm attempting, again, to see what we need to do in order to use gcc-8.x
> >> for U-Boot and ran into, again:
> >> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
> >> using -mcpu=xscale gcc-8.x throws an odd error:
> >> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch
> >> [-Werror]
> >>
> >> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
> >> suggests perhaps something broke in upstream gcc. Looking at the
> >> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
> >> leads to different failures (seen here with gcc-7.3):
> >> CC drivers/usb/gadget/pxa25x_udc.o
> >> {standard input}: Assembler messages:
> >> {standard input}:779: Error: selected processor does not support `pld
> >> [lr]' in ARM mode
> >> {standard input}:1201: Error: selected processor does not support `pld
> >> [r7]' in ARM mode
> >> {standard input}:2519: Error: selected processor does not support `pld
> >> [r3]' in ARM mode
> >> {standard input}:2796: Error: selected processor does not support `pld
> >> [r3]' in ARM mode
> >>
> >> So, what should we do about this? Is there still active interest in
> >> supporting the PXA platforms? Thanks folks!
> >
> > ping? Thanks!
>
> Maybe we should just remove it.
+1, almost no one uses it nowadays.
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On 5/9/19 5:03 PM, Vasily Khoruzhick wrote:
> On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
>>
>> On 5/9/19 4:02 PM, Tom Rini wrote:
>>> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
>>>
Hey folks,
I'm attempting, again, to see what we need to do in order to use gcc-8.x
for U-Boot and ran into, again:
https://patchwork.ozlabs.org/patch/920329/ which in short is that when
using -mcpu=xscale gcc-8.x throws an odd error:
cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch
[-Werror]
Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
suggests perhaps something broke in upstream gcc. Looking at the
kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
leads to different failures (seen here with gcc-7.3):
CC drivers/usb/gadget/pxa25x_udc.o
{standard input}: Assembler messages:
{standard input}:779: Error: selected processor does not support `pld
[lr]' in ARM mode
{standard input}:1201: Error: selected processor does not support `pld
[r7]' in ARM mode
{standard input}:2519: Error: selected processor does not support `pld
[r3]' in ARM mode
{standard input}:2796: Error: selected processor does not support `pld
[r3]' in ARM mode
So, what should we do about this? Is there still active interest in
supporting the PXA platforms? Thanks folks!
>>>
>>> ping? Thanks!
>>
>> Maybe we should just remove it.
>
> +1, almost no one uses it nowadays.
Well, there are still a few users of Zipit Z2 and there was some
interest in Sharp Zaurus, but ...
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] U-Boot PXA support
On Thu, May 09, 2019 at 05:12:25PM +0200, Marek Vasut wrote:
> On 5/9/19 5:03 PM, Vasily Khoruzhick wrote:
> > On Thu, May 9, 2019 at 7:56 AM Marek Vasut wrote:
> >>
> >> On 5/9/19 4:02 PM, Tom Rini wrote:
> >>> On Mon, May 06, 2019 at 09:26:04AM -0400, Tom Rini wrote:
> >>>
> Hey folks,
>
> I'm attempting, again, to see what we need to do in order to use gcc-8.x
> for U-Boot and ran into, again:
> https://patchwork.ozlabs.org/patch/920329/ which in short is that when
> using -mcpu=xscale gcc-8.x throws an odd error:
> cc1: error: switch -mcpu=xscale conflicts with -march=armv5te switch
> [-Werror]
>
> Now note, U-Boot isn't passing -march= at all, just -mcpu=xscale which
> suggests perhaps something broke in upstream gcc. Looking at the
> kernel, it's not used -mcpu=xscale ever, just -mtune=xscale but that
> leads to different failures (seen here with gcc-7.3):
> CC drivers/usb/gadget/pxa25x_udc.o
> {standard input}: Assembler messages:
> {standard input}:779: Error: selected processor does not support `pld
> [lr]' in ARM mode
> {standard input}:1201: Error: selected processor does not support `pld
> [r7]' in ARM mode
> {standard input}:2519: Error: selected processor does not support `pld
> [r3]' in ARM mode
> {standard input}:2796: Error: selected processor does not support `pld
> [r3]' in ARM mode
>
> So, what should we do about this? Is there still active interest in
> supporting the PXA platforms? Thanks folks!
> >>>
> >>> ping? Thanks!
> >>
> >> Maybe we should just remove it.
> >
> > +1, almost no one uses it nowadays.
>
> Well, there are still a few users of Zipit Z2 and there was some
> interest in Sharp Zaurus, but ...
I don't see anything for Zipit Z2 that's been updated more recently than
about 5 years ago, sadly. Vasily, do you want to post a patch to drop
that board since it's yours? 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] [PATCH] test/py: don't use mmc_rd config for other mmc tests
On 5/1/19 4:51 PM, Stephen Warren wrote: On 4/30/19 10:27 AM, Marek Vasut wrote: On 4/30/19 5:29 PM, Stephen Warren wrote: On 4/16/19 4:04 PM, Stephen Warren wrote: From: Stephen Warren Fix test_mmc_dev(), test_mmc_rescan(), test_mmc_info() not to use the same configuration data that test_mmc_rd() does. Doing so causes the following issues: * The new code uncondtionally expects certain keys to exist in the configuration data. These keys do not exist in existing configuration data since they were not previously required, and there was no notification re: a requirement to add these new keys. This causes test failures due to thrown exceptions when accessing the non-existent keys. * The new tests logically operate on different objects. test_mmc_rd() operates on ranges of sectors on an MMC device (which may be the entire set of sectors of a device, or a part of a device), whereas all the new tests operate solely on entire devices. These are separate things, and it's entirely likely that the user will wish to runs the two types of tests on different sets of data; see the example configuration data that this commit adds. Ideally, the new tests would have been added to a separate Python file, since they aren' closely related to the existing tests. FIXME: Marek, can you please replace the "???" in this patch with some reasonable looking data? Thanks. Tom, Marek, any chance of applying this? Right now, every mainline branch is failing 5 tests on every push, which wastes my time having to go through all the logs to manually check that the failures aren't anything new/unknown. Thanks. I'm still overloaded, and didn't have time to look into this. But I'm really not fond of the duplication here -- now we have two big tables describing very much the same thing, which SD/MMC to test . There's no redundancy; the two different tests are semantically entirely different and don't share any configuration. See the patch description above for the full details. Tom, could you please apply this patch to fix the test failures. Thanks. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] warp7: include: configs: Differentiate bootscript address from loadaddr
On 08/05/2019 20:33, Pierre-Jean Texier wrote:
Hi Bryan,
Le 08/05/2019 à 20:14, Bryan O'Donoghue a écrit :
Reusing the loadaddr to load the boot script breaks some of the logic we
want to have around the bootscript/FIT load addresses. Making a dedicated
bootscript address allows us to differentiate the bootscript load address
from the Linux Kernel or OPTEE load address, thus ensuring that no matter
what the load sequence the bootscript and Kernel/OPTEE binary load
addresses do not conflict.
Signed-off-by: Bryan O'Donoghue
---
include/configs/warp7.h | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/include/configs/warp7.h b/include/configs/warp7.h
index 95955fd626..0c63050833 100644
--- a/include/configs/warp7.h
+++ b/include/configs/warp7.h
@@ -50,6 +50,7 @@
"script=boot.scr\0" \
"bootscr_fitimage_name=bootscr\0" \
"script_signed=boot.scr.imx-signed\0" \
+ "bootscriptaddr=0x8320\0" \
"image=zImage\0" \
"console=ttymxc0\0" \
"ethact=usb_ether\0" \
@@ -70,16 +71,16 @@
"warp7_auth_or_fail=hab_auth_img_or_fail ${hab_ivt_addr}
${filesize} 0;\0" \
"do_bootscript_hab=" \
"if test ${hab_enabled} -eq 1; then " \
- "setexpr hab_ivt_addr ${loadaddr} - ${ivt_offset}; " \
+ "setexpr hab_ivt_addr ${bootscriptaddr} - ${ivt_offset}; " \
"setenv script ${script_signed}; " \
"load mmc ${mmcdev}:${mmcpart} ${hab_ivt_addr}
${script}; " \
"run warp7_auth_or_fail; " \
"run bootscript; "\
"fi;\0" \
"loadbootscript=" \
- "load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0" \
+ "load mmc ${mmcdev}:${mmcpart} ${bootscriptaddr} ${script};\0" \
"bootscript=echo Running bootscript from mmc ...; " \
- "source\0" \
+ BOOT_SCR_STRING \
"loadimage=load mmc ${mmcdev}:${mmcpart} ${loadaddr} ${image}\0" \
"loadfdt=load mmc ${mmcdev}:${mmcpart} ${fdt_addr} ${fdt_file}\0" \
"mmcboot=echo Booting from mmc ...; " \
Instead of implementing a new variable (bootscriptaddr), I think (IMHO)
it's time to migrate
to distroboot for the WaRP7 (like pico imx7 for instance >
In fact, in this specific case, this allows to use the common
scriptaddr[1] variable.
FYI, this is a task I am currently working on [2] (work in progress).
Maybe we could integrate this migration into this series ?
Sure.
Let me give it a test later tonight/tomorrow
---
bod
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] configs: bcm963158 disable CONFIG_CMD_BOOTEFI_SELFTEST
Configuration option CONFIG_CMD_BOOTEFI_SELFTEST is useful for the development of the UEFI sub-system. For production it is not needed. Remove CONFIG_CMD_BOOTEFI_SELFTEST from bcm963158_ram_defconfig. Suggested-by: Tom Rini Signed-off-by: Heinrich Schuchardt --- configs/bcm963158_ram_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/bcm963158_ram_defconfig b/configs/bcm963158_ram_defconfig index 321bc22699..dfd69069c7 100644 --- a/configs/bcm963158_ram_defconfig +++ b/configs/bcm963158_ram_defconfig @@ -16,7 +16,6 @@ CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_HUSH_PARSER=y -CONFIG_CMD_BOOTEFI_SELFTEST=y # CONFIG_CMD_LZMADEC is not set # CONFIG_CMD_UNZIP is not set # CONFIG_CMD_FLASH is not set -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 45/50] Revert "pci: Scale MAX_PCI_REGIONS based on CONFIG_NR_DRAM_BANKS"
On Tue, May 07, 2019 at 09:04:16PM -0600, Simon Glass wrote: > Hi Bin, > > On Tue, 7 May 2019 at 03:28, Bin Meng wrote: > > > > Hi Simon, Thierry, > > > > On Fri, May 3, 2019 at 12:22 AM Simon Glass wrote: > > > > > > Hi Thierry, > > > > > > On Thu, 2 May 2019 at 03:25, Thierry Reding wrote: > > > > > > > > On Thu, May 02, 2019 at 12:09:49AM +0800, Bin Meng wrote: > > > > > +Thierry > > > > > > > > > > On Fri, Apr 26, 2019 at 12:00 PM Simon Glass > > > > > wrote: > > > > > > > > > > > > This reverts commit aec4298ccb337106fd0115b91d846a022fdf301d. > > > > > > > > > > > > Unfortunately this has a dramatic impact on the pre-relocation > > > > > > memory > > > > > > used on x86 platforms (increasing it by 2KB) since it increases the > > > > > > overhead for each PCI device from 220 bytes to 412 bytes. > > > > > > > > > > > > The offending line is in UCLASS_DRIVER(pci): > > > > > > > > > > > > .per_device_auto_alloc_size = sizeof(struct pci_controller), > > > > > > > > > > > > This means that all PCI devices have the controller struct > > > > > > associated > > > > > > with them. The solution is to move the regions[] member out of the > > > > > > array, > > > > > > makes its size dynamic, or split UCLASS_PCI into controllers and > > > > > > non-controllers, as the comment suggests. > > > > > > > > > > > > For now, revert the commit to get things running again. > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > --- > > > > > > > > > > > > Changes in v2: None > > > > > > > > > > > > include/pci.h | 6 +- > > > > > > 1 file changed, 1 insertion(+), 5 deletions(-) > > > > > > > > > > > > > > > > Reviewed-by: Bin Meng > > > > > > > > Ugh... so we're trading one regression for another? Can we not live with > > > > the 2 KiB increase on x86 until this has been properly fixed? Currently > > > > this will cause Jetson TX2 to crash if it starts using PCI. > > > > > > Unfortunately this breaks several boards since we are out of memory. > > > > > > I think this needs a better solution to reduce the memory usage down > > > to sensible levels. This is something I should have considered when > > > implementing the PCI uclass, but unfortunately I did not. > > > > > > > Could you please suggest whether I should apply this revert patch for now? > > I suggest a temporary revert since this breaks some x86 boards. > > I think the real fix is to reduce the memory used by PCI devices. > Thierry, do you have time to look at this? Not right away. I may get around to this within a couple of weeks maybe. Thierry signature.asc Description: PGP signature ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/1] configs: bcm968580 disable CONFIG_CMD_BOOTEFI_SELFTEST
Configuration option CONFIG_CMD_BOOTEFI_SELFTEST is useful for the development of the UEFI sub-system. For production it is not needed. Remove CONFIG_CMD_BOOTEFI_SELFTEST from bcm968580xref_ram_defconfig. Suggested-by: Tom Rini Signed-off-by: Heinrich Schuchardt --- configs/bcm968580xref_ram_defconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/configs/bcm968580xref_ram_defconfig b/configs/bcm968580xref_ram_defconfig index d6509e30bc..d331e4e807 100644 --- a/configs/bcm968580xref_ram_defconfig +++ b/configs/bcm968580xref_ram_defconfig @@ -14,7 +14,6 @@ CONFIG_IMAGE_FORMAT_LEGACY=y CONFIG_SUPPORT_RAW_INITRD=y CONFIG_DISPLAY_BOARDINFO_LATE=y CONFIG_HUSH_PARSER=y -CONFIG_CMD_BOOTEFI_SELFTEST=y CONFIG_CMD_GPIO=y CONFIG_CMD_MTD=y CONFIG_CMD_NAND=y -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND
Hello Heiko On Thu, May 09, 2019 at 01:17:06PM +0200, Heiko Schocher wrote: > >Am 09.05.2019 um 10:59 schrieb Markus Klotzbuecher: >> Hello Heiko >> >> On Tue, Apr 30, 2019 at 06:54:01AM +0200, Heiko Schocher wrote: >> >> > Am 15.04.2019 um 17:32 schrieb Markus Klotzbuecher: >> > > From: Markus Klotzbuecher >> > >> > please add a commit message. >> > >> > > Signed-off-by: Markus Klotzbuecher >> > > Cc: Heiko Schocher >> > > Cc: Kyungmin Park >> > > --- >> > >env/Kconfig | 6 ++ >> > >scripts/config_whitelist.txt | 1 - >> > >2 files changed, 6 insertions(+), 1 deletion(-) >> > > >> > > diff --git a/env/Kconfig b/env/Kconfig >> > > index 78300660c7..44c47220c2 100644 >> > > --- a/env/Kconfig >> > > +++ b/env/Kconfig >> > > @@ -513,6 +513,12 @@ config ENV_UBI_VOLUME >> > > help >> > >Name of the volume that you want to store the environment in. >> > > +config ENV_UBI_VOLUME_REDUND >> > > +string "UBI redundant volume name" >> > > +depends on ENV_IS_IN_UBI >> > > +help >> > > + Name of the redundant volume that you want to store the >> > > environment in. >> > > + >> > >endif >> > >config USE_DEFAULT_ENV_FILE >> > > diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt >> > > index fa98efc24c..5d76c781d3 100644 >> > > --- a/scripts/config_whitelist.txt >> > > +++ b/scripts/config_whitelist.txt >> > > @@ -504,7 +504,6 @@ CONFIG_ENV_SROM_BANK >> > >CONFIG_ENV_TOTAL_SIZE >> > >CONFIG_ENV_UBIFS_OPTION >> > >CONFIG_ENV_UBI_MTD >> > > -CONFIG_ENV_UBI_VOLUME_REDUND >> > >CONFIG_ENV_VERSION >> > >CONFIG_EP9302 >> > >CONFIG_EP9307 >> > > >> > >> > Please move from the config files: >> > >> > ./include/configs/omap3_igep00x0.h >> > ./include/configs/gardena-smart-gateway-at91sam.h >> > ./include/configs/am335x_igep003x.h >> > >> > also the symbols to the defconfig files, thanks. >> >> I have a question: to convert these, I need to make available the >> additional ENV_ configs to OMAP2PLUS and AT91: >> >> diff --git a/env/Kconfig b/env/Kconfig >> index 44c47220c2..1250656d74 100644 >> --- a/env/Kconfig >> +++ b/env/Kconfig >> @@ -470,7 +470,7 @@ config ENV_EXT4_FILE >>It's a string of the EXT4 file name. This file use to store the >>environment (explicit path to the file) >> -if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL >> || ARC >> +if ARCH_ROCKCHIP || ARCH_SUNXI || ARCH_ZYNQ || ARCH_ZYNQMP || ARCH_VERSAL >> || ARC || ARCH_OMAP2PLUS || ARCH_AT91 >> >> However, this "if" region contains a few other, non UBI settings such >> as ENV_SIZE, which would become visible to a large number of OMAP2PLUS >> and AT91 boards, which still define this in the headers. > >Huch? > >If so, than they are not converted (yet) ... :-( > >> I'm a bit hesitant to touch all of these. What is the suggested way to >> solve this? > >I think, they should be converted too ... OK. >Sorry for the additional work ... I can understand your hesitantion >to do such a conversion... No problem, I just wasn't sure how handle this. I'm now trying to run moveconfig as follows $ grep -l "ARCH_OMAP2PLUS\|ARCH_AT91" configs/* | ./tools/moveconfig.py -s ENV_OFFSET ENV_SIZE ENV_SECT_SIZE -d - but the command hangs infinitely. If I run it for all boards without "-d", it starts processing and gets through about 50 configs and then hangs too. Any idea what may be the cause? I'm using python 2.7.16rc1. >Hmm... I used some year(s) ago tbot for checking, if a config change >did not introduced diffs in created binaries for all boards [1] ... > >In principal I did: > >- build all boards with "SOURCE_DATE_EPOCH=0" > and created a md5sum from each binary >- apply patch(es) >- build again, create md5sums and check if mdsum is the same > >Unfortunately not converted this testcase to the new tbot ... > >But may it is possible to convert this into a script ? Thank you, I'll take a look at it one I get that far. Best regards Markus -- Markus Klotzbuecher Freelancer Embedded, Distributed & Real-time Systems Am See 28, 78465 Konstanz, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 13/18] arm: K3: am654: Map common EEPROM data into SRAM scratch space
On 5/8/19 11:52 PM, Lokesh Vutla wrote: > > > On 09/05/19 3:07 AM, Andreas Dannenberg wrote: >> The board detection scheme employed on various TI EVMs makes use of >> SRAM scratch space to share data read from an on-board EEPROM between >> the different bootloading stages. Map the associated definition that's >> used to locate this data into the SRAM scratch space we use on AM654x. >> >> Signed-off-by: Andreas Dannenberg >> --- >> arch/arm/mach-k3/include/mach/am6_hardware.h | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h >> b/arch/arm/mach-k3/include/mach/am6_hardware.h >> index 3343233aa3..6df7631545 100644 >> --- a/arch/arm/mach-k3/include/mach/am6_hardware.h >> +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h >> @@ -44,4 +44,7 @@ >> #define CTRLMMR_LOCK_KICK1 0x0100c >> #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a >> >> +/* MCU SCRATCHPAD usage */ >> +#define TI_SRAM_SCRATCH_BOARD_EEPROM_START CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE > > Won't HS devices fail while accessing this region? We should drop it > altogether. > HS devices cannot read this before SYSFW is loaded as by default it is left firewalled by ROM. This read happens after SYSFW loading so it does work currently, but no guarantee SYSFW will always remove this firewall by default, we may need a driver that does an explicit device get for this region to be sure it is powered and accessible (it is on a different reset domain, it may need special handling). I think we should avoid using this scratchpad for a couple other reasons. After R5 SPL has finished bootloading is handled by A53 cores, the R5 will be repurposed and other software will run on it, possibly wiping out the memory here. Anything we want to pass form R5 to A53 should use a non-R5-local memory, not this scratchpad. We need the same for passing the original boot media info also. A lot of pitfalls for just 512 bytes of RAM.. Andrew > Thanks and regards, > Lokesh > >> + >> #endif /* __ASM_ARCH_AM6_HARDWARE_H */ >> > ___ > 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] Pull request for UEFI sub-system for v2019.07-rc2 (2)
On 5/9/19 4:16 PM, Tom Rini wrote:
> On Thu, May 09, 2019 at 12:03:38AM +0200, Heinrich Schuchardt wrote:
>> On 5/8/19 7:50 PM, Tom Rini wrote:
>>> On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
>>>
The following changes since commit
44237e272f1eac3b026709e76333a07b2d3a3523:
Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
07:19:31 -0400)
are available in the Git repository at:
git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
for you to fetch changes up to
b015ab57bf558daa1c768995a7a7f1df2d40191e:
efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
+0200)
Travis CI results are here:
https://travis-ci.org/xypron2/u-boot/builds/529448555
Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC
2C05 1AC4
>>>
>>> Note that you may want to run ./scripts/checkpatch.pl --git
>>> origin/master.. or similar as: WARNING: 'follwing' may be misspelled
>>> - perhaps 'following'?
>>>
>>> which I left alone rather than mess up the tag.
>>
>> Sorry I missed that one. Typically I run checkpatch.pl.
>>
>>>
>>> Applied to u-boot/master, thanks!
>>>
>>> And all of that said, looking over my before/after builds I see a lot
>>> of size growth, everywhere, due to EFI changes. I assume this is due
>>> to increasing overall functionality and support, which is good. But
>>> is there perhaps some way we can split things into a minimal "we
>>> have enough to support loading ${OS LOADER}" and then "we are aiming
>>> for large parts of spec compliance" ? Some days I start to wonder
>>> if "EFI_LOADER on by default" was a bad idea.
>>>
>>
>> The following switches allow to reduce the size of the UEFI subsystem:
>>
>> CONFIG_CMD_BOOTEFI_HELLO, default N
>> CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
>
> Note there's 2 non-QEMU platforms enabling it, can you please add a
> patch turning it off and cc'ing the maintainer as they probably didn't
> really mean to have that on? It's also not on for riscv QEMU nor
> sandbox but should be?
>
>> CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
>> CONFIG_EFI_LOADER_HII
>> (The Makefile does not consider it yet correctly, patch submitted.)
>> CONFIG_CMD_EFIDEBUG, default N
>> CONFIG_CMD_NVEDIT_EFI
>
> Adding in:
> commit 7494b7764508332e37a3375fa0b6c328bc34637f
> Author: Tom Rini
> Date: Thu May 9 10:06:40 2019 -0400
>
> LOCAL: Disable some EFI stuff by default
>
> Signed-off-by: Tom Rini
>
> diff --git a/cmd/Kconfig b/cmd/Kconfig
> index 4e11e0f404c8..4ebaf2f5bcb9 100644
> --- a/cmd/Kconfig
> +++ b/cmd/Kconfig
> @@ -238,7 +238,6 @@ config CMD_BOOTEFI
> config CMD_BOOTEFI_HELLO_COMPILE
> bool "Compile a standard EFI hello world binary for testing"
> depends on CMD_BOOTEFI && !CPU_V7M && !SANDBOX
> - default y
> help
> This compiles a standard EFI hello world application with U-Boot so
> that it can be used with the test/py testing framework. This is useful
> @@ -434,7 +433,6 @@ config CMD_ENV_FLAGS
> config CMD_NVEDIT_EFI
> bool "env [set|print] -e - set/print UEFI variables"
> depends on EFI_LOADER
> - default y
> imply HEXDUMP
> help
> UEFI variables are encoded as some form of U-Boot variables.
> diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> index 50b050159c37..bd8fb9be00bc 100644
> --- a/lib/efi_loader/Kconfig
> +++ b/lib/efi_loader/Kconfig
> @@ -19,7 +19,6 @@ config EFI_LOADER
> config EFI_UNICODE_CAPITALIZATION
> bool "Support Unicode capitalization"
> depends on EFI_LOADER
> - default y
> help
> Select this option to enable correct handling of the capitalization of
> Unicode codepoints in the range 0x-0x. If this option is not
> @@ -48,7 +47,6 @@ config EFI_LOADER_BOUNCE_BUFFER
> config EFI_LOADER_HII
> bool "Expose HII protocols to EFI applications"
> depends on EFI_LOADER
> - default y
> help
> The Human Interface Infrastructure is a complicated framework that
> allows UEFI applications to draw fancy menus and hook strings using
>
> And note that with the bugfix to the Makefile for EFI_LOADER_HII added,
> there's either more to be done, or it was already being discarded at
> link time as applying that patch on top of this didn't result in any
> size savings. Doing the above saves about 10kb. Which helps, but with
> the numbers I mentioned earlier still puts us at about 40kb which Alex
> was hoping it should be closer to 20kb. Is there more we can do here?
> Thanks!
>
I already mentioned further areas that possibly can be made customizable
in this thread.
Alex numbers refer to a state where everything except starting GRUB
would fail in the 1st half of 2017. Even the most simple conceivable
UEFI binary doing nothing but `return EFI_SUCCESS;` resulted in a crash.
My priority is on using the UEFI SCT to identify areas w
Re: [U-Boot] Pull request for UEFI sub-system for v2019.07-rc2 (2)
On Thu, May 09, 2019 at 06:05:57PM +0200, Heinrich Schuchardt wrote:
> On 5/9/19 4:16 PM, Tom Rini wrote:
> > On Thu, May 09, 2019 at 12:03:38AM +0200, Heinrich Schuchardt wrote:
> >> On 5/8/19 7:50 PM, Tom Rini wrote:
> >>> On Wed, May 08, 2019 at 07:57:57AM +0200, Heinrich Schuchardt wrote:
> >>>
> The following changes since commit
> 44237e272f1eac3b026709e76333a07b2d3a3523:
>
> Merge branch 'master' of git://git.denx.de/u-boot-sh (2019-05-06
> 07:19:31 -0400)
>
> are available in the Git repository at:
>
> git://git.denx.de/u-boot-efi.git tags/efi-2019-07-rc2-2
>
> for you to fetch changes up to
> b015ab57bf558daa1c768995a7a7f1df2d40191e:
>
> efi_loader: signature of ExitBootServices() (2019-05-07 21:10:04
> +0200)
>
> Travis CI results are here:
> https://travis-ci.org/xypron2/u-boot/builds/529448555
>
> Primary key fingerprint: 6DC4 F9C7 1F29 A6FA 06B7 6D33 C481 DBBC
> 2C05 1AC4
>
> >>>
> >>> Note that you may want to run ./scripts/checkpatch.pl --git
> >>> origin/master.. or similar as: WARNING: 'follwing' may be misspelled
> >>> - perhaps 'following'?
> >>>
> >>> which I left alone rather than mess up the tag.
> >>
> >> Sorry I missed that one. Typically I run checkpatch.pl.
> >>
> >>>
> >>> Applied to u-boot/master, thanks!
> >>>
> >>> And all of that said, looking over my before/after builds I see a lot
> >>> of size growth, everywhere, due to EFI changes. I assume this is due
> >>> to increasing overall functionality and support, which is good. But
> >>> is there perhaps some way we can split things into a minimal "we
> >>> have enough to support loading ${OS LOADER}" and then "we are aiming
> >>> for large parts of spec compliance" ? Some days I start to wonder
> >>> if "EFI_LOADER on by default" was a bad idea.
> >>>
> >>
> >> The following switches allow to reduce the size of the UEFI subsystem:
> >>
> >> CONFIG_CMD_BOOTEFI_HELLO, default N
> >> CONFIG_CMD_BOOTEFI_SELFTEST, default N except QEMU
> >
> > Note there's 2 non-QEMU platforms enabling it, can you please add a
> > patch turning it off and cc'ing the maintainer as they probably didn't
> > really mean to have that on? It's also not on for riscv QEMU nor
> > sandbox but should be?
> >
> >> CONFIG_EFI_UNICODE_CAPITALIZATION, default Y
> >> CONFIG_EFI_LOADER_HII
> >> (The Makefile does not consider it yet correctly, patch submitted.)
> >> CONFIG_CMD_EFIDEBUG, default N
> >> CONFIG_CMD_NVEDIT_EFI
> >
> > Adding in:
> > commit 7494b7764508332e37a3375fa0b6c328bc34637f
> > Author: Tom Rini
> > Date: Thu May 9 10:06:40 2019 -0400
> >
> > LOCAL: Disable some EFI stuff by default
> >
> > Signed-off-by: Tom Rini
> >
> > diff --git a/cmd/Kconfig b/cmd/Kconfig
> > index 4e11e0f404c8..4ebaf2f5bcb9 100644
> > --- a/cmd/Kconfig
> > +++ b/cmd/Kconfig
> > @@ -238,7 +238,6 @@ config CMD_BOOTEFI
> > config CMD_BOOTEFI_HELLO_COMPILE
> > bool "Compile a standard EFI hello world binary for testing"
> > depends on CMD_BOOTEFI && !CPU_V7M && !SANDBOX
> > - default y
> > help
> > This compiles a standard EFI hello world application with U-Boot so
> > that it can be used with the test/py testing framework. This is useful
> > @@ -434,7 +433,6 @@ config CMD_ENV_FLAGS
> > config CMD_NVEDIT_EFI
> > bool "env [set|print] -e - set/print UEFI variables"
> > depends on EFI_LOADER
> > - default y
> > imply HEXDUMP
> > help
> > UEFI variables are encoded as some form of U-Boot variables.
> > diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
> > index 50b050159c37..bd8fb9be00bc 100644
> > --- a/lib/efi_loader/Kconfig
> > +++ b/lib/efi_loader/Kconfig
> > @@ -19,7 +19,6 @@ config EFI_LOADER
> > config EFI_UNICODE_CAPITALIZATION
> > bool "Support Unicode capitalization"
> > depends on EFI_LOADER
> > - default y
> > help
> > Select this option to enable correct handling of the capitalization of
> > Unicode codepoints in the range 0x-0x. If this option is not
> > @@ -48,7 +47,6 @@ config EFI_LOADER_BOUNCE_BUFFER
> > config EFI_LOADER_HII
> > bool "Expose HII protocols to EFI applications"
> > depends on EFI_LOADER
> > - default y
> > help
> > The Human Interface Infrastructure is a complicated framework that
> > allows UEFI applications to draw fancy menus and hook strings using
> >
> > And note that with the bugfix to the Makefile for EFI_LOADER_HII added,
> > there's either more to be done, or it was already being discarded at
> > link time as applying that patch on top of this didn't result in any
> > size savings. Doing the above saves about 10kb. Which helps, but with
> > the numbers I mentioned earlier still puts us at about 40kb which Alex
> > was hoping it should be closer to 20kb. Is there more we can do here?
> > Thanks!
> >
>
> I already mentioned further areas that possibly can be made customizable
> in this threa
Re: [U-Boot] [PATCH 13/18] arm: K3: am654: Map common EEPROM data into SRAM scratch space
Andrew, On Thu, May 09, 2019 at 12:03:31PM -0400, Andrew F. Davis wrote: > On 5/8/19 11:52 PM, Lokesh Vutla wrote: > > > > > > On 09/05/19 3:07 AM, Andreas Dannenberg wrote: > >> The board detection scheme employed on various TI EVMs makes use of > >> SRAM scratch space to share data read from an on-board EEPROM between > >> the different bootloading stages. Map the associated definition that's > >> used to locate this data into the SRAM scratch space we use on AM654x. > >> > >> Signed-off-by: Andreas Dannenberg > >> --- > >> arch/arm/mach-k3/include/mach/am6_hardware.h | 3 +++ > >> 1 file changed, 3 insertions(+) > >> > >> diff --git a/arch/arm/mach-k3/include/mach/am6_hardware.h > >> b/arch/arm/mach-k3/include/mach/am6_hardware.h > >> index 3343233aa3..6df7631545 100644 > >> --- a/arch/arm/mach-k3/include/mach/am6_hardware.h > >> +++ b/arch/arm/mach-k3/include/mach/am6_hardware.h > >> @@ -44,4 +44,7 @@ > >> #define CTRLMMR_LOCK_KICK10x0100c > >> #define CTRLMMR_LOCK_KICK1_UNLOCK_VAL 0xd172bc5a > >> > >> +/* MCU SCRATCHPAD usage */ > >> +#define TI_SRAM_SCRATCH_BOARD_EEPROM_START > >> CONFIG_SYS_K3_MCU_SCRATCHPAD_BASE > > > > Won't HS devices fail while accessing this region? We should drop it > > altogether. > > > > HS devices cannot read this before SYSFW is loaded as by default it is > left firewalled by ROM. This read happens after SYSFW loading so it does > work currently, but no guarantee SYSFW will always remove this firewall > by default, we may need a driver that does an explicit device get for > this region to be sure it is powered and accessible (it is on a > different reset domain, it may need special handling). Yes this is understood. For others reading this, this is how it is done in our current production U-Boot tree (upstream U-Boot does not yet have SYSFW loading capability). > I think we should avoid using this scratchpad for a couple other > reasons. After R5 SPL has finished bootloading is handled by A53 cores, > the R5 will be repurposed and other software will run on it, possibly > wiping out the memory here. Anything we want to pass form R5 to A53 > should use a non-R5-local memory, not this scratchpad. We need the same > for passing the original boot media info also. > > A lot of pitfalls for just 512 bytes of RAM.. I don't disagree, this approach is limited, it's just the "easiest" we started using when creating the initial solution. Let's find/align on a different memory region. While at it, there is a need to pass additional data across our three boot stages (R5 SPL -> A53 SPL -> A53 U-Boot); for example I'd at some point like to carry forward peripheral initialization state (so we don't have to re-probe stuff 3 times), amongst other things, for which I was eyeing to use the new CONFIG_BLOBLIST* feature. So if we can identify a new/dedicated memory region for such data it would be a good opportunity to also start making use of the BLOBLIST feature at the same time, creating a more scalable solution. -- Andreas Dannenberg Texas Instruments Inc > Andrew > > > Thanks and regards, > > Lokesh > > > >> + > >> #endif /* __ASM_ARCH_AM6_HARDWARE_H */ > >> > > ___ > > 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] wandboard: Don't use I2C speed Kconfig settings with DM_I2C
On Thu, 2019-05-09 at 08:20 +0200, Anatolij Gustschin wrote: > On Wed, 8 May 2019 23:30:01 + > Trent Piepho tpie...@impinj.com wrote: > ... > > diff --git a/board/wandboard/wandboard.c > > b/board/wandboard/wandboard.c > > index 69fbc8b690..9d7a94ff9d 100644 > > --- a/board/wandboard/wandboard.c > > +++ b/board/wandboard/wandboard.c > > @@ -46,6 +46,15 @@ DECLARE_GLOBAL_DATA_PTR; > > #define ETH_PHY_AR8035_POWER IMX_GPIO_NR(7, 13) > > #define REV_DETECTION IMX_GPIO_NR(2, 28) > > > > +/* Speed defined in Kconfig is only applicable when not using > > DM_I2C. */ > > +#ifdef CONFIG_DM_I2C > > +#define I2C1_SPEED_NON_DM 0 > > +#define I2C2_SPEED_NON_DM 0 > > +#else > > +#define I2C1_SPEED_NON_DM CONFIG_SYS_MXC_I2C1_SPEED > > +#define I2C2_SPEED_NON_DM CONFIG_SYS_MXC_I2C2_SPEED > > Shouldn't we change this to > > #ifdef CONFIG_DM_I2C > #define I2C2_SPEED_NON_DM 0 > #define I2C3_SPEED_NON_DM 0 > #else > #define I2C2_SPEED_NON_DM CONFIG_SYS_MXC_I2C2_SPEED > #define I2C3_SPEED_NON_DM CONFIG_SYS_MXC_I2C3_SPEED > #endif > ... > setup_i2c(1, I2C2_SPEED_NON_DM, 0x7f, &mx6q_i2c2_pad_info); > setup_i2c(2, I2C3_SPEED_NON_DM, 0x7f, &mx6q_i2c3_pad_info); > ? > > Because the first argument to setup_i2c() is the bus number > which starts counting from 0, but the CONFIG_SYS_MXC_I2C* > start counting from 1. This doesn't affect the actual > configuration since the speed value is currently the same > for all buses. But it is more accurate. Seems like it should have been, but the existing code uses I2C1_SPEED and I2C2_SPEED. Probably a bug. But if I change it here, then it will affect existing config files, which were done when the bug existed. Also I see it calls setup_i2c(1, ...) twice, which seems like another bug. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 4/4] sysreset: add support for socfpga sysreset
This moves sysreset support for socfgpa from ad-hoc code in mach-socfpga
to a UCLASS_SYSRESET based dm driver.
A side effect is that gen5 and a10 can now select between cold and warm
reset.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- this patch enables the new drivers and drops the ad-hoc code
Changes in v2:
- adapt to patch that separates drivers/sysreset from drivers/misc
for SPL: select SPL_SYSRESET_SUPPORT, not SPL_DRIVERS_MISC_SUPPORT
- separate gen5/a10 driver from s10 driver
- as sysreset is a function of rstmgr, bind the sysreset drivers
from rstmgr to get the base address instead of hardcoding it
arch/arm/Kconfig | 4 +++
arch/arm/mach-socfpga/Makefile| 1 -
arch/arm/mach-socfpga/reset_manager.c | 41 ---
drivers/reset/reset-socfpga.c | 19 +
4 files changed, 23 insertions(+), 42 deletions(-)
delete mode 100644 arch/arm/mach-socfpga/reset_manager.c
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f91c590f6d..327adbbf0a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -829,10 +829,14 @@ config ARCH_SOCFPGA
select SPL_OF_CONTROL
select SPL_SEPARATE_BSS if TARGET_SOCFPGA_STRATIX10
select SPL_SERIAL_SUPPORT
+ select SPL_SYSRESET_SUPPORT
select SPL_WATCHDOG_SUPPORT
select SUPPORT_SPL
select SYS_NS16550
select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+ select SYSRESET
+ select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || TARGET_SOCFPGA_ARRIA10
+ select SYSRESET_SOCFPGA_STRATIX10 if TARGET_SOCFPGA_STRATIX10
imply CMD_DM
imply CMD_MTDPARTS
imply CRC32_VERIFY
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e66720447f..fc1181cb27 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -8,7 +8,6 @@
obj-y += board.o
obj-y += clock_manager.o
obj-y += misc.o
-obj-y += reset_manager.o
ifdef CONFIG_TARGET_SOCFPGA_GEN5
obj-y += clock_manager_gen5.o
diff --git a/arch/arm/mach-socfpga/reset_manager.c
b/arch/arm/mach-socfpga/reset_manager.c
deleted file mode 100644
index e0a01ed07a..00
--- a/arch/arm/mach-socfpga/reset_manager.c
+++ /dev/null
@@ -1,41 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2013 Altera Corporation
- */
-
-
-#include
-#include
-#include
-
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-#include
-#endif
-
-DECLARE_GLOBAL_DATA_PTR;
-
-#if !defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
-static const struct socfpga_reset_manager *reset_manager_base =
- (void *)SOCFPGA_RSTMGR_ADDRESS;
-#endif
-
-/*
- * Write the reset manager register to cause reset
- */
-void reset_cpu(ulong addr)
-{
- /* request a warm reset */
-#if defined(CONFIG_TARGET_SOCFPGA_STRATIX10)
- puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
- mbox_reset_cold();
-#else
- writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
- &reset_manager_base->ctrl);
-#endif
- /*
-* infinite loop here as watchdog will trigger and reset
-* the processor
-*/
- while (1)
- ;
-}
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index cb8312619f..f49f064574 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -14,6 +14,7 @@
#include
#include
+#include
#include
#include
#include
@@ -132,6 +133,23 @@ static int socfpga_reset_remove(struct udevice *dev)
return 0;
}
+static int socfpga_reset_bind(struct udevice *dev)
+{
+ int ret;
+ struct udevice *sys_child;
+
+ /*
+* The sysreset driver does not have a device node, so bind it here.
+* Bind it to the node, too, so that it can get its base address.
+*/
+ ret = device_bind_driver_to_node(dev, "socfpga_sysreset", "sysreset",
+dev->node, &sys_child);
+ if (ret)
+ debug("Warning: No sysreset driver: ret=%d\n", ret);
+
+ return 0;
+}
+
static const struct udevice_id socfpga_reset_match[] = {
{ .compatible = "altr,rst-mgr" },
{ /* sentinel */ },
@@ -141,6 +159,7 @@ U_BOOT_DRIVER(socfpga_reset) = {
.name = "socfpga-reset",
.id = UCLASS_RESET,
.of_match = socfpga_reset_match,
+ .bind = socfpga_reset_bind,
.probe = socfpga_reset_probe,
.priv_auto_alloc_size = sizeof(struct socfpga_reset_data),
.ops = &socfpga_reset_ops,
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 1/4] arm: socfpga: rst: add register definition for cold reset
This adds a define for the bit in rstmgr's ctrl regiser that issues a cold reset (we had a define for the warm reset bit only) in preparation for a proper sysrese driver. Signed-off-by: Simon Goldschmidt Series changes: 2 - separate this patch to the register descriptions from the actual sysreset driver patch --- Changes in v3: None Changes in v2: None arch/arm/mach-socfpga/include/mach/reset_manager.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager.h b/arch/arm/mach-socfpga/include/mach/reset_manager.h index 42beaecdd6..6ad037e325 100644 --- a/arch/arm/mach-socfpga/include/mach/reset_manager.h +++ b/arch/arm/mach-socfpga/include/mach/reset_manager.h @@ -11,6 +11,7 @@ void reset_cpu(ulong addr); void socfpga_per_reset(u32 reset, int set); void socfpga_per_reset_all(void); +#define RSTMGR_CTRL_SWCOLDRSTREQ_LSB 0 #define RSTMGR_CTRL_SWWARMRSTREQ_LSB 1 /* -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 3/4] sysreset: socfpga: stratix10: add sysreset driver
This adds a UCLASS_SYSRESET sysreset driver for socfgpa stratix10.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- moved socfpga stratix sysreset driver to extra patch
Changes in v2: None
drivers/sysreset/Kconfig| 7 ++
drivers/sysreset/Makefile | 1 +
drivers/sysreset/sysreset_socfpga_s10.c | 29 +
3 files changed, 37 insertions(+)
create mode 100644 drivers/sysreset/sysreset_socfpga_s10.c
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 066838c106..5b8402ccae 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -43,6 +43,13 @@ config SYSRESET_SOCFPGA
This enables the system reset driver support for Intel SOCFPGA SoCs
(Cyclone 5, Arria 5 and Arria 10).
+config SYSRESET_SOCFPGA_S10
+ bool "Enable support for Intel SOCFPGA Stratix 10"
+ depends on ARCH_SOCFPGA && TARGET_SOCFPGA_STRATIX10
+ help
+ This enables the system reset driver support for Intel SOCFPGA
+ Stratix SoCs.
+
config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index 0241b0132d..71291fa2cf 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
+obj-$(CONFIG_SYSRESET_SOCFPGA_S10) += sysreset_socfpga_s10.o
obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_socfpga_s10.c
b/drivers/sysreset/sysreset_socfpga_s10.c
new file mode 100644
index 00..9837aadf64
--- /dev/null
+++ b/drivers/sysreset/sysreset_socfpga_s10.c
@@ -0,0 +1,29 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Pepperl+Fuchs
+ * Simon Goldschmidt
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+static int socfpga_sysreset_request(struct udevice *dev,
+ enum sysreset_t type)
+{
+ puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
+ mbox_reset_cold();
+ return -EINPROGRESS;
+}
+
+static struct sysreset_ops socfpga_sysreset = {
+ .request = socfpga_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_socfpga) = {
+ .id = UCLASS_SYSRESET,
+ .name = "socfpga_sysreset",
+ .ops= &socfpga_sysreset,
+};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- moved socfpga gen5 sysreset driver to extra patch
Changes in v2: None
drivers/sysreset/Kconfig| 7
drivers/sysreset/Makefile | 1 +
drivers/sysreset/sysreset_socfpga.c | 56 +
3 files changed, 64 insertions(+)
create mode 100644 drivers/sysreset/sysreset_socfpga.c
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 8ce3e2e207..066838c106 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -36,6 +36,13 @@ config SYSRESET_PSCI
Enable PSCI SYSTEM_RESET function call. To use this, PSCI firmware
must be running on your system.
+config SYSRESET_SOCFPGA
+ bool "Enable support for Intel SOCFPGA family"
+ depends on ARCH_SOCFPGA && (TARGET_SOCFPGA_GEN5 ||
TARGET_SOCFPGA_ARRIA10)
+ help
+ This enables the system reset driver support for Intel SOCFPGA SoCs
+ (Cyclone 5, Arria 5 and Arria 10).
+
config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index b3728ac17f..0241b0132d 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
+obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_socfpga.c
b/drivers/sysreset/sysreset_socfpga.c
new file mode 100644
index 00..fc1ba72d5b
--- /dev/null
+++ b/drivers/sysreset/sysreset_socfpga.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Pepperl+Fuchs
+ * Simon Goldschmidt
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct socfpga_sysreset_data {
+ struct socfpga_reset_manager *rstmgr_base;
+};
+
+static int socfpga_sysreset_request(struct udevice *dev,
+ enum sysreset_t type)
+{
+ struct socfpga_sysreset_data *data = dev_get_priv(dev);
+
+ switch (type) {
+ case SYSRESET_WARM:
+ writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
+ &data->rstmgr_base->ctrl);
+ break;
+ case SYSRESET_COLD:
+ writel(1 << RSTMGR_CTRL_SWCOLDRSTREQ_LSB,
+ &data->rstmgr_base->ctrl);
+ break;
+ default:
+ return -EPROTONOSUPPORT;
+ }
+ return -EINPROGRESS;
+}
+
+static int socfpga_sysreset_probe(struct udevice *dev)
+{
+ struct socfpga_sysreset_data *data = dev_get_priv(dev);
+
+ data->rstmgr_base = devfdt_get_addr_ptr(dev);
+ return 0;
+}
+
+static struct sysreset_ops socfpga_sysreset = {
+ .request = socfpga_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_socfpga) = {
+ .id = UCLASS_SYSRESET,
+ .name = "socfpga_sysreset",
+ .priv_auto_alloc_size = sizeof(struct socfpga_sysreset_data),
+ .ops= &socfpga_sysreset,
+ .probe = socfpga_sysreset_probe,
+};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] env: ubi: KConfig: add CONFIG_ENV_UBI_VOLUME_REDUND
âFrom: Markus Klotzbuecher User-Agent: Mutt/1.10.1 (2018-07-13) X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - m2731.contabo.net X-AntiAbuse: Original Domain - lists.denx.de X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - mkio.de X-Get-Message-Sender-Via: m2731.contabo.net: authenticated_id: m...@mkio.de X-Authenticated-Sender: m2731.contabo.net: m...@mkio.de X-Source: X-Source-Args: X-Source-Dir: On Thu, May 09, 2019 at 05:49:51PM +0200, Markus Klotzbuecher wrote: ... >I'm now trying to run moveconfig as follows > >$ grep -l "ARCH_OMAP2PLUS\|ARCH_AT91" configs/* | ./tools/moveconfig.py -s >ENV_OFFSET ENV_SIZE ENV_SECT_SIZE -d - > >but the command hangs infinitely. > >If I run it for all boards without "-d", it starts processing and gets >through about 50 configs and then hangs too. > >Any idea what may be the cause? I found it: I didn't add a default to the new KConfig, so the script got stuck when it was asked for the new config options. Sorry for the noise. Markus -- Markus Klotzbuecher Freelancer Embedded, Distributed & Real-time Am See 28, 78465 Konstanz, Germany ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
This fixes 3 boards that don't use CONFIG_EXTRA_ENV_SETTINGS from
socfpga_common.h. They need to enable reset manager compatibility
mode unless all peripheral drivers in Linux support reset handling.
Fixes: commit 4b2e32efa4e7 ("arm: socfpga: gen5: deassert peripheral reset by
default")
Signed-off-by: Simon Goldschmidt
Reported-by: Wolfgang Grandegger
---
include/configs/socfpga_dbm_soc1.h| 3 ++-
include/configs/socfpga_stratix10_socdk.h | 3 ++-
include/configs/socfpga_vining_fpga.h | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/configs/socfpga_dbm_soc1.h
b/include/configs/socfpga_dbm_soc1.h
index b36d7e56fb..fc1db2442e 100644
--- a/include/configs/socfpga_dbm_soc1.h
+++ b/include/configs/socfpga_dbm_soc1.h
@@ -87,7 +87,8 @@
"echo Running bootscript... ; " \
"source ${kernel_addr_r} ; "\
"fi ; " \
- "fi\0"
+ "fi\0" \
+ "socfpga_legacy_reset_compat=1\0"
/* The rest of the configuration is shared */
#include
diff --git a/include/configs/socfpga_stratix10_socdk.h
b/include/configs/socfpga_stratix10_socdk.h
index 8d2971c6e2..90ad8172e2 100644
--- a/include/configs/socfpga_stratix10_socdk.h
+++ b/include/configs/socfpga_stratix10_socdk.h
@@ -113,7 +113,8 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
"scriptaddr=0x0210\0" \
"scriptfile=u-boot.scr\0" \
"fatscript=if fatload mmc 0:1 ${scriptaddr} ${scriptfile};" \
- "then source ${scriptaddr}; fi\0"
+ "then source ${scriptaddr}; fi\0" \
+ "socfpga_legacy_reset_compat=1\0"
/*
* Generic Interrupt Controller Definitions
diff --git a/include/configs/socfpga_vining_fpga.h
b/include/configs/socfpga_vining_fpga.h
index 29a92b9146..737a304217 100644
--- a/include/configs/socfpga_vining_fpga.h
+++ b/include/configs/socfpga_vining_fpga.h
@@ -145,6 +145,7 @@
"run ubi_ubi ; "\
"else echo \"Unsupported boot mode: \"${bootmode} ; " \
"fi\0" \
+ "socfpga_legacy_reset_compat=1\0" \
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
#define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: davinci_emac: use driver model (CONFIG_DM_ETH)
On Tue, Apr 30, 2019 at 11:04 AM Bartosz Golaszewski wrote:
>
> From: Bartosz Golaszewski
>
> Add support for CONFIG_DM_ETH to the davinci_emac driver. Optimally
> we should only support DM-enabled platforms but there are several
> non-DT boards that still use it so either we need to keep supporting
> it or drop the boards from u-boot. For now we're stuck with ugly
> ifdefs.
Which boards are still not using DM that you refer to here?
>
> This patch adds support for driver-model to the driver and converts
> all platforms that use the driver model to selecting CONFIG_DM_ETH.
>
> Tested on da850-evm and da850-lcdk.
>
> Signed-off-by: Bartosz Golaszewski
> ---
> NOTE: I'm currently working on modernizing da850 support in u-boot.
> This patch is just the first step - I plan on improving the emac driver
> in general but I'll be OoO until end of next week, so I decided to post
> it already for reviews.
>
> Does anyone know what the status is on boards like twister, ea20 etc.
> that use davinci_emac, but don't use the driver model? Dropping them
> would make it easier to clean up this driver.
>
> This patch applies on top of my previous series[1].
>
> [1] https://lists.denx.de/pipermail/u-boot/2019-April/367236.html
>
> arch/arm/mach-davinci/cpu.c| 13 ---
> arch/arm/mach-omap2/omap3/emac.c | 3 +-
> board/davinci/da8xxevm/da850evm.c | 5 --
> 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/da850_am18xxevm_defconfig | 1 +
> configs/da850evm_defconfig | 1 +
> configs/da850evm_direct_nor_defconfig | 1 +
> configs/omapl138_lcdk_defconfig| 1 +
> configs/ti816x_evm_defconfig | 1 +
> drivers/net/ti/davinci_emac.c | 109 +
> 13 files changed, 100 insertions(+), 54 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, &am35x_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..0d2bc5fb32 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,10 +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;
> }
> 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 a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
> index 07a084bab8..240df8cbe1 100644
> --- a/board/ti/ti816x
Re: [U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
On 09.05.19 20:08, Simon Goldschmidt wrote:
This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5.
Signed-off-by: Simon Goldschmidt
---
Changes in v3:
- moved socfpga gen5 sysreset driver to extra patch
Changes in v2: None
drivers/sysreset/Kconfig| 7
drivers/sysreset/Makefile | 1 +
drivers/sysreset/sysreset_socfpga.c | 56 +
3 files changed, 64 insertions(+)
create mode 100644 drivers/sysreset/sysreset_socfpga.c
I just noticed patman complained about new files regarding MAINTAINERS.
Should these new drivers be listed in the MAINTAINERS file under the
socfpga section? I noticed other platforms seem to do that but we don't.
How is this handled?
Regards,
Simon
diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig
index 8ce3e2e207..066838c106 100644
--- a/drivers/sysreset/Kconfig
+++ b/drivers/sysreset/Kconfig
@@ -36,6 +36,13 @@ config SYSRESET_PSCI
Enable PSCI SYSTEM_RESET function call. To use this, PSCI firmware
must be running on your system.
+config SYSRESET_SOCFPGA
+ bool "Enable support for Intel SOCFPGA family"
+ depends on ARCH_SOCFPGA && (TARGET_SOCFPGA_GEN5 ||
TARGET_SOCFPGA_ARRIA10)
+ help
+ This enables the system reset driver support for Intel SOCFPGA SoCs
+ (Cyclone 5, Arria 5 and Arria 10).
+
config SYSRESET_TI_SCI
bool "TI System Control Interface (TI SCI) system reset driver"
depends on TI_SCI_PROTOCOL
diff --git a/drivers/sysreset/Makefile b/drivers/sysreset/Makefile
index b3728ac17f..0241b0132d 100644
--- a/drivers/sysreset/Makefile
+++ b/drivers/sysreset/Makefile
@@ -11,6 +11,7 @@ obj-$(CONFIG_SYSRESET_GPIO) += sysreset_gpio.o
obj-$(CONFIG_SYSRESET_MCP83XX) += sysreset_mpc83xx.o
obj-$(CONFIG_SYSRESET_MICROBLAZE) += sysreset_microblaze.o
obj-$(CONFIG_SYSRESET_PSCI) += sysreset_psci.o
+obj-$(CONFIG_SYSRESET_SOCFPGA) += sysreset_socfpga.o
obj-$(CONFIG_SYSRESET_TI_SCI) += sysreset-ti-sci.o
obj-$(CONFIG_SYSRESET_SYSCON) += sysreset_syscon.o
obj-$(CONFIG_SYSRESET_WATCHDOG) += sysreset_watchdog.o
diff --git a/drivers/sysreset/sysreset_socfpga.c
b/drivers/sysreset/sysreset_socfpga.c
new file mode 100644
index 00..fc1ba72d5b
--- /dev/null
+++ b/drivers/sysreset/sysreset_socfpga.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Pepperl+Fuchs
+ * Simon Goldschmidt
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+struct socfpga_sysreset_data {
+ struct socfpga_reset_manager *rstmgr_base;
+};
+
+static int socfpga_sysreset_request(struct udevice *dev,
+ enum sysreset_t type)
+{
+ struct socfpga_sysreset_data *data = dev_get_priv(dev);
+
+ switch (type) {
+ case SYSRESET_WARM:
+ writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
+ &data->rstmgr_base->ctrl);
+ break;
+ case SYSRESET_COLD:
+ writel(1 << RSTMGR_CTRL_SWCOLDRSTREQ_LSB,
+ &data->rstmgr_base->ctrl);
+ break;
+ default:
+ return -EPROTONOSUPPORT;
+ }
+ return -EINPROGRESS;
+}
+
+static int socfpga_sysreset_probe(struct udevice *dev)
+{
+ struct socfpga_sysreset_data *data = dev_get_priv(dev);
+
+ data->rstmgr_base = devfdt_get_addr_ptr(dev);
+ return 0;
+}
+
+static struct sysreset_ops socfpga_sysreset = {
+ .request = socfpga_sysreset_request,
+};
+
+U_BOOT_DRIVER(sysreset_socfpga) = {
+ .id = UCLASS_SYSRESET,
+ .name = "socfpga_sysreset",
+ .priv_auto_alloc_size = sizeof(struct socfpga_sysreset_data),
+ .ops= &socfpga_sysreset,
+ .probe = socfpga_sysreset_probe,
+};
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: > > According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the > TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 > (r8a77995). > > Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM > when the DT explicitly specifies RGMII ID or TXID mode instead of setting > it unconditionally when the PHY link speed is 1000 Mbit/s. We just ran into an issue with a very similar patch. It blocked my tree being merged for a few months. Finally got to the bottom of it. https://patchwork.ozlabs.org/patch/1096572/ Are you sure there are no boards depending on the broken DT, like the 335-evm was? > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Joe Hershberger > --- > drivers/net/ravb.c | 13 ++--- > 1 file changed, 10 insertions(+), 3 deletions(-) > > diff --git a/drivers/net/ravb.c b/drivers/net/ravb.c > index 749562db96..11abe5e0c9 100644 > --- a/drivers/net/ravb.c > +++ b/drivers/net/ravb.c > @@ -46,6 +46,8 @@ > #define CSR_OPS0x000F > #define CSR_OPS_CONFIG BIT(1) > > +#define APSR_TDM BIT(14) > + > #define TCCR_TSRQ0 BIT(0) > > #define RFLR_RFL_MIN 0x05EE > @@ -389,9 +391,14 @@ static int ravb_dmac_init(struct udevice *dev) > /* FIFO size set */ > writel(0x0010, eth->iobase + RAVB_REG_TGC); > > - /* Delay CLK: 2ns */ > - if (pdata->max_speed == 1000) > - writel(BIT(14), eth->iobase + RAVB_REG_APSR); > + /* Delay CLK: 2ns (not applicable on R-Car E3/D3) */ > + if ((rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77990) || > + (rmobile_get_cpu_type() == RMOBILE_CPU_TYPE_R8A77995)) > + return 0; > + > + if ((pdata->phy_interface == PHY_INTERFACE_MODE_RGMII_ID) || > + (pdata->phy_interface == PHY_INTERFACE_MODE_RGMII_TXID)) > + writel(APSR_TDM, eth->iobase + RAVB_REG_APSR); > > return 0; > } > -- > 2.20.1 > > ___ > 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] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
Hello Simon,
Am 09.05.19 um 20:42 schrieb Simon Goldschmidt:
> This fixes 3 boards that don't use CONFIG_EXTRA_ENV_SETTINGS from
> socfpga_common.h. They need to enable reset manager compatibility
> mode unless all peripheral drivers in Linux support reset handling.
>
> Fixes: commit 4b2e32efa4e7 ("arm: socfpga: gen5: deassert peripheral reset by
> default")
> Signed-off-by: Simon Goldschmidt
> Reported-by: Wolfgang Grandegger
> ---
>
> include/configs/socfpga_dbm_soc1.h| 3 ++-
> include/configs/socfpga_stratix10_socdk.h | 3 ++-
> include/configs/socfpga_vining_fpga.h | 1 +
> 3 files changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/include/configs/socfpga_dbm_soc1.h
> b/include/configs/socfpga_dbm_soc1.h
> index b36d7e56fb..fc1db2442e 100644
> --- a/include/configs/socfpga_dbm_soc1.h
> +++ b/include/configs/socfpga_dbm_soc1.h
> @@ -87,7 +87,8 @@
> "echo Running bootscript... ; " \
> "source ${kernel_addr_r} ; "\
> "fi ; " \
> - "fi\0"
> + "fi\0" \
> + "socfpga_legacy_reset_compat=1\0"
>
> /* The rest of the configuration is shared */
> #include
> diff --git a/include/configs/socfpga_stratix10_socdk.h
> b/include/configs/socfpga_stratix10_socdk.h
> index 8d2971c6e2..90ad8172e2 100644
> --- a/include/configs/socfpga_stratix10_socdk.h
> +++ b/include/configs/socfpga_stratix10_socdk.h
> @@ -113,7 +113,8 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> "scriptaddr=0x0210\0" \
> "scriptfile=u-boot.scr\0" \
> "fatscript=if fatload mmc 0:1 ${scriptaddr} ${scriptfile};" \
> -"then source ${scriptaddr}; fi\0"
> +"then source ${scriptaddr}; fi\0" \
> + "socfpga_legacy_reset_compat=1\0"
>
> /*
> * Generic Interrupt Controller Definitions
> diff --git a/include/configs/socfpga_vining_fpga.h
> b/include/configs/socfpga_vining_fpga.h
> index 29a92b9146..737a304217 100644
> --- a/include/configs/socfpga_vining_fpga.h
> +++ b/include/configs/socfpga_vining_fpga.h
> @@ -145,6 +145,7 @@
> "run ubi_ubi ; "\
> "else echo \"Unsupported boot mode: \"${bootmode} ; " \
> "fi\0" \
> + "socfpga_legacy_reset_compat=1\0" \
>
> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> #define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
>
On my board, setting "socfpga_legacy_reset_compat=1" was not enough. It
also needs "bootm_size=0xa00" to boot Linux.
Wolfgang
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
Am 09.05.2019 um 21:13 schrieb Wolfgang Grandegger:
Hello Simon,
Am 09.05.19 um 20:42 schrieb Simon Goldschmidt:
This fixes 3 boards that don't use CONFIG_EXTRA_ENV_SETTINGS from
socfpga_common.h. They need to enable reset manager compatibility
mode unless all peripheral drivers in Linux support reset handling.
Fixes: commit 4b2e32efa4e7 ("arm: socfpga: gen5: deassert peripheral reset by
default")
Signed-off-by: Simon Goldschmidt
Reported-by: Wolfgang Grandegger
---
include/configs/socfpga_dbm_soc1.h| 3 ++-
include/configs/socfpga_stratix10_socdk.h | 3 ++-
include/configs/socfpga_vining_fpga.h | 1 +
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/include/configs/socfpga_dbm_soc1.h
b/include/configs/socfpga_dbm_soc1.h
index b36d7e56fb..fc1db2442e 100644
--- a/include/configs/socfpga_dbm_soc1.h
+++ b/include/configs/socfpga_dbm_soc1.h
@@ -87,7 +87,8 @@
"echo Running bootscript... ; " \
"source ${kernel_addr_r} ; " \
"fi ; " \
- "fi\0"
+ "fi\0"\
+ "socfpga_legacy_reset_compat=1\0"
/* The rest of the configuration is shared */
#include
diff --git a/include/configs/socfpga_stratix10_socdk.h
b/include/configs/socfpga_stratix10_socdk.h
index 8d2971c6e2..90ad8172e2 100644
--- a/include/configs/socfpga_stratix10_socdk.h
+++ b/include/configs/socfpga_stratix10_socdk.h
@@ -113,7 +113,8 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
"scriptaddr=0x0210\0" \
"scriptfile=u-boot.scr\0" \
"fatscript=if fatload mmc 0:1 ${scriptaddr} ${scriptfile};" \
- "then source ${scriptaddr}; fi\0"
+ "then source ${scriptaddr}; fi\0" \
+ "socfpga_legacy_reset_compat=1\0"
/*
* Generic Interrupt Controller Definitions
diff --git a/include/configs/socfpga_vining_fpga.h
b/include/configs/socfpga_vining_fpga.h
index 29a92b9146..737a304217 100644
--- a/include/configs/socfpga_vining_fpga.h
+++ b/include/configs/socfpga_vining_fpga.h
@@ -145,6 +145,7 @@
"run ubi_ubi ; " \
"else echo \"Unsupported boot mode: \"${bootmode} ; " \
"fi\0"\
+ "socfpga_legacy_reset_compat=1\0" \
#define CONFIG_SYS_REDUNDAND_ENVIRONMENT
#define CONFIG_ENV_SIZE_REDUNDCONFIG_ENV_SIZE
On my board, setting "socfpga_legacy_reset_compat=1" was not enough. It
also needs "bootm_size=0xa00" to boot Linux.
Ok, but that would be a different patch - I wanted this to be a 'fixes'
patch for that one thing. I'd have to check with the socrates board what
happens without that bootm_size thing and why...
Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/2] cmd: mii: Refactor some of the MII reg dump code
Share the code that prints out a register field with the function that
prints out the "special" fields.
There were two arrays the register dump list, one with reg number and
name, another with a pointer to the field table and the table size.
These two arrays had have each entry match what register is referred to.
Combine them into just one table. Now they can't not match and there is
just one table.
Add some missing consts to pointers to string literals.
The dump code was ignoring the regno field in the description table and
assuming register 0 was at index 0, etc. Have it use the field.
Change reg > max+1 into reg >= max, which doesn't fail if max+1 could
overflow, besides just making more sense.
Signed-off-by: Trent Piepho
---
cmd/mii.c | 154 --
1 file changed, 69 insertions(+), 85 deletions(-)
diff --git a/cmd/mii.c b/cmd/mii.c
index c0c42a851f..fcc677b485 100644
--- a/cmd/mii.c
+++ b/cmd/mii.c
@@ -12,25 +12,11 @@
#include
#include
-typedef struct _MII_reg_desc_t {
- ushort regno;
- char * name;
-} MII_reg_desc_t;
-
-static const MII_reg_desc_t reg_0_5_desc_tbl[] = {
- { MII_BMCR, "PHY control register" },
- { MII_BMSR, "PHY status register" },
- { MII_PHYSID1, "PHY ID 1 register" },
- { MII_PHYSID2, "PHY ID 2 register" },
- { MII_ADVERTISE, "Autonegotiation advertisement register" },
- { MII_LPA, "Autonegotiation partner abilities register" },
-};
-
typedef struct _MII_field_desc_t {
ushort hi;
ushort lo;
ushort mask;
- char * name;
+ const char *name;
} MII_field_desc_t;
static const MII_field_desc_t reg_0_desc_tbl[] = {
@@ -87,7 +73,7 @@ static const MII_field_desc_t reg_4_desc_tbl[] = {
{ 7, 7, 0x01, "100BASE-TX able" },
{ 6, 6, 0x01, "10BASE-T full duplex able" },
{ 5, 5, 0x01, "10BASE-T able" },
- { 4, 0, 0x1f, "xxx to do"},
+ { 4, 0, 0x1f, "selector" },
};
static const MII_field_desc_t reg_5_desc_tbl[] = {
@@ -102,50 +88,65 @@ static const MII_field_desc_t reg_5_desc_tbl[] = {
{ 7, 7, 0x01, "100BASE-TX able" },
{ 6, 6, 0x01, "10BASE-T full duplex able"},
{ 5, 5, 0x01, "10BASE-T able"},
- { 4, 0, 0x1f, "xxx to do"},
+ { 4, 0, 0x1f, "partner selector" },
};
-typedef struct _MII_field_desc_and_len_t {
+
+typedef struct _MII_reg_desc_t {
+ ushort regno;
const MII_field_desc_t *pdesc;
ushort len;
-} MII_field_desc_and_len_t;
-
-static const MII_field_desc_and_len_t desc_and_len_tbl[] = {
- { reg_0_desc_tbl, ARRAY_SIZE(reg_0_desc_tbl) },
- { reg_1_desc_tbl, ARRAY_SIZE(reg_1_desc_tbl) },
- { reg_2_desc_tbl, ARRAY_SIZE(reg_2_desc_tbl) },
- { reg_3_desc_tbl, ARRAY_SIZE(reg_3_desc_tbl) },
- { reg_4_desc_tbl, ARRAY_SIZE(reg_4_desc_tbl) },
- { reg_5_desc_tbl, ARRAY_SIZE(reg_5_desc_tbl) },
+ const char *name;
+} MII_reg_desc_t;
+
+static const MII_reg_desc_t mii_reg_desc_tbl[] = {
+ { MII_BMCR, reg_0_desc_tbl, ARRAY_SIZE(reg_0_desc_tbl),
+ "PHY control register" },
+ { MII_BMSR, reg_1_desc_tbl, ARRAY_SIZE(reg_1_desc_tbl),
+ "PHY status register" },
+ { MII_PHYSID1, reg_2_desc_tbl, ARRAY_SIZE(reg_2_desc_tbl),
+ "PHY ID 1 register" },
+ { MII_PHYSID2, reg_3_desc_tbl, ARRAY_SIZE(reg_3_desc_tbl),
+ "PHY ID 2 register" },
+ { MII_ADVERTISE, reg_4_desc_tbl, ARRAY_SIZE(reg_4_desc_tbl),
+ "Autonegotiation advertisement register" },
+ { MII_LPA, reg_5_desc_tbl, ARRAY_SIZE(reg_5_desc_tbl),
+ "Autonegotiation partner abilities register" },
};
static void dump_reg(
ushort regval,
- const MII_reg_desc_t *prd,
- const MII_field_desc_and_len_t *pdl);
-
-static int special_field(
- ushort regno,
- const MII_field_desc_t *pdesc,
- ushort regval);
-
-static void MII_dump_0_to_5(
- ushort regvals[6],
- uchar reglo,
- uchar reghi)
+ const MII_reg_desc_t *prd);
+
+static bool special_field(ushort regno, const MII_field_desc_t *pdesc,
+ ushort regval);
+
+static void MII_dump(const ushort *regvals, uchar reglo, uchar reghi)
{
ulong i;
- for (i = 0; i < 6; i++) {
- if ((reglo <= i) && (i <= reghi))
- dump_reg(regvals[i], ®_0_5_desc_tbl[i],
- &desc_and_len_tbl[i]);
+ for (i = 0; i < ARRAY_SIZE(mii_reg_desc_tbl); i++) {
+ const uchar reg = mii_reg_desc_tbl[i].regno;
+
+ if (reg >= reglo && reg <= reghi)
+ dump_reg(regvals[reg - reglo], &mii_reg_desc_tbl[i]);
}
}
+
[U-Boot] [PATCH 2/2] cmd: mii: Add the standard 1000BASE-T registers
These are standard across gigabit phys. These mostly extend the
auto-negotiation information with gigabit fields.
Signed-off-by: Trent Piepho
---
cmd/mii.c | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/cmd/mii.c b/cmd/mii.c
index fcc677b485..1cb0904689 100644
--- a/cmd/mii.c
+++ b/cmd/mii.c
@@ -91,6 +91,28 @@ static const MII_field_desc_t reg_5_desc_tbl[] = {
{ 4, 0, 0x1f, "partner selector" },
};
+static const MII_field_desc_t reg_9_desc_tbl[] = {
+ { 15, 13, 0x07, "test mode"},
+ { 12, 12, 0x01, "manual master/slave enable" },
+ { 11, 11, 0x01, "manual master/slave value"},
+ { 10, 10, 0x01, "multi/single port"},
+ { 9, 9, 0x01, "1000BASE-T full duplex able" },
+ { 8, 8, 0x01, "1000BASE-T half duplex able" },
+ { 7, 7, 0x01, "automatic TDR on link down" },
+ { 6, 6, 0x7f, "(reserved)" },
+};
+
+static const MII_field_desc_t reg_10_desc_tbl[] = {
+ { 15, 15, 0x01, "master/slave config fault"},
+ { 14, 14, 0x01, "master/slave config result" },
+ { 13, 13, 0x01, "local receiver status OK" },
+ { 12, 12, 0x01, "remote receiver status OK"},
+ { 11, 11, 0x01, "1000BASE-T full duplex able" },
+ { 10, 10, 0x01, "1000BASE-T half duplex able" },
+ { 9, 8, 0x03, "(reserved)" },
+ { 7, 0, 0xff, "1000BASE-T idle error counter"},
+};
+
typedef struct _MII_reg_desc_t {
ushort regno;
const MII_field_desc_t *pdesc;
@@ -111,6 +133,10 @@ static const MII_reg_desc_t mii_reg_desc_tbl[] = {
"Autonegotiation advertisement register" },
{ MII_LPA, reg_5_desc_tbl, ARRAY_SIZE(reg_5_desc_tbl),
"Autonegotiation partner abilities register" },
+ { MII_CTRL1000, reg_9_desc_tbl, ARRAY_SIZE(reg_9_desc_tbl),
+ "1000BASE-T control register" },
+ { MII_STAT1000, reg_10_desc_tbl, ARRAY_SIZE(reg_10_desc_tbl),
+ "1000BASE-T status register" },
};
static void dump_reg(
@@ -390,12 +416,10 @@ static int do_mii(cmd_tbl_t *cmdtp, int flag, int argc,
char * const argv[])
}
}
} else if (strncmp(op, "du", 2) == 0) {
- ushort regs[6];
+ ushort regs[MII_STAT1000 + 1]; /* Last reg is 0x0a */
int ok = 1;
- if ((reglo > 5) || (reghi > 5)) {
- printf(
- "The MII dump command only formats the "
- "standard MII registers, 0-5.\n");
+ if (reglo > MII_STAT1000 || reghi > MII_STAT1000) {
+ printf("The MII dump command only formats the standard
MII registers, 0-5, 9-a.\n");
return 1;
}
for (addr = addrlo; addr <= addrhi; addr++) {
--
2.14.5
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH] net: phy: ti: Use default values for tx/rx delay and fifo size
When not using DM_ETH, these PHY settings are programmed with default values hardcoded into the driver. When using DM_ETH, they should come from the device tree. However, if the device tree does not have the properties, the driver will silent use -1. Which is entirely out of range, programs nonsense into the PHY's registers, and does not work. Change this to use the same defaults as non-DM_ETH if the device tree is lacking the properties. As an alternative, the kernel driver for the phy will display an error message and fail if the device tree is lacking. Cc: Joe Hershberger Cc: Janine Hagemann Cc: Grygorii Strashko Signed-off-by: Trent Piepho --- drivers/net/phy/ti.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/net/phy/ti.c b/drivers/net/phy/ti.c index 6db6edd0d0..33f5687e0e 100644 --- a/drivers/net/phy/ti.c +++ b/drivers/net/phy/ti.c @@ -240,14 +240,14 @@ static int dp83867_of_init(struct phy_device *phydev) dp83867->rxctrl_strap_quirk = true; dp83867->rx_id_delay = ofnode_read_u32_default(node, "ti,rx-internal-delay", - -1); + DEFAULT_RX_ID_DELAY); dp83867->tx_id_delay = ofnode_read_u32_default(node, "ti,tx-internal-delay", - -1); + DEFAULT_TX_ID_DELAY); dp83867->fifo_depth = ofnode_read_u32_default(node, "ti,fifo-depth", - -1); + DEFAULT_FIFO_DEPTH); if (ofnode_read_bool(node, "enet-phy-lane-swap")) dp83867->port_mirroring = DP83867_PORT_MIRRORING_EN; -- 2.14.5 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On 5/9/19 8:56 PM, Joe Hershberger wrote: > On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: >> >> According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the >> TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 >> (r8a77995). >> >> Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM >> when the DT explicitly specifies RGMII ID or TXID mode instead of setting >> it unconditionally when the PHY link speed is 1000 Mbit/s. > > We just ran into an issue with a very similar patch. It blocked my > tree being merged for a few months. Finally got to the bottom of it. > https://patchwork.ozlabs.org/patch/1096572/ > > Are you sure there are no boards depending on the broken DT, like the > 335-evm was? I cannot be sure, but the boards which are supported and tested work fine. If someone runs into any issue. they can raise them, and we'll solve the problem when we come to that bridge. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] net: use block layer in net driver
On Wed, Apr 17, 2019 at 4:02 AM Yinbo Zhu wrote:
>
> From: Yinbo Zhu
>
> At present the MMC subsystem maintains its own list
> of MMC devices. This cannot work with driver model
> when CONFIG_BLK is enabled, use blk_dread to
> replace previous mmc read interface,
>
> Signed-off-by: Yinbo Zhu
> ---
> drivers/net/phy/cortina.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/phy/cortina.c b/drivers/net/phy/cortina.c
> index a04a118f90..2337c3403c 100644
> --- a/drivers/net/phy/cortina.c
> +++ b/drivers/net/phy/cortina.c
> @@ -176,7 +176,7 @@ void cs4340_upload_firmware(struct phy_device *phydev)
> printf("MMC read: dev # %u, block # %u, count %u ...\n",
>dev, blk, cnt);
> mmc_init(mmc);
> - (void)mmc->block_dev.block_read(&mmc->block_dev, blk, cnt,
> + (void)blk_dread(mmc_get_blk_desc(mmc), blk, cnt,
> addr);
Should this be switching on CONFIG_BLK or CONFIG_DM_MMC or something.
> }
> #endif
> --
> 2.17.1
>
> ___
> 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
[U-Boot] [PATCH 0/6] arm: socfpga: convert drivers to dm livetree
This series converts (hopefully) all drivers used in socfpga to livetree so that none of them references 'gd' any more (with the exception of some a10/s10 drivers that should be fixed). Simon Goldschmidt (6): timer: dw-apb: remove unused DECLARE_GLOBAL_DATA_PTR spi: cadence_qspi: convert to livetree spi: designware: convert to livetree serial: altera_uart: convert to livetree reset: socfpga: covnert to livetree gpio: dwapb_gpio: convert to livetree drivers/gpio/dwapb_gpio.c | 25 ++ drivers/reset/reset-socfpga.c | 4 +--- drivers/serial/altera_uart.c | 5 + drivers/spi/cadence_qspi.c| 39 +-- drivers/spi/designware_spi.c | 8 ++- drivers/timer/dw-apb-timer.c | 2 -- 6 files changed, 34 insertions(+), 49 deletions(-) -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 4/6] serial: altera_uart: convert to livetree
Convert 'altera_uart_ofdata_to_platdata' to use 'dev_read_u32_default' instead of 'fdtdec_get_int' and get rid of DECLARE_GLOBAL_DATA_PTR. Signed-off-by: Simon Goldschmidt --- drivers/serial/altera_uart.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/serial/altera_uart.c b/drivers/serial/altera_uart.c index 67d47199aa..436cf2331d 100644 --- a/drivers/serial/altera_uart.c +++ b/drivers/serial/altera_uart.c @@ -10,8 +10,6 @@ #include #include -DECLARE_GLOBAL_DATA_PTR; - /* status register */ #define ALTERA_UART_TMTBIT(5) /* tx empty */ #define ALTERA_UART_TRDY BIT(6) /* tx ready */ @@ -91,8 +89,7 @@ static int altera_uart_ofdata_to_platdata(struct udevice *dev) plat->regs = map_physmem(devfdt_get_addr(dev), sizeof(struct altera_uart_regs), MAP_NOCACHE); - plat->uartclk = fdtdec_get_int(gd->fdt_blob, dev_of_offset(dev), - "clock-frequency", 0); + plat->uartclk = dev_read_u32_default(dev, "clock-frequency", 0); return 0; } -- 2.20.1 ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 1/6] timer: dw-apb: remove unused DECLARE_GLOBAL_DATA_PTR
The dw-apb timer does not use 'gd', so remove its declaration.
Signed-off-by: Simon Goldschmidt
---
drivers/timer/dw-apb-timer.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/timer/dw-apb-timer.c b/drivers/timer/dw-apb-timer.c
index cb48801af1..86312b8dc7 100644
--- a/drivers/timer/dw-apb-timer.c
+++ b/drivers/timer/dw-apb-timer.c
@@ -17,8 +17,6 @@
#define DW_APB_CURR_VAL0x4
#define DW_APB_CTRL0x8
-DECLARE_GLOBAL_DATA_PTR;
-
struct dw_apb_timer_priv {
fdt_addr_t regs;
};
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 5/6] reset: socfpga: convert to livetree
Convert 'socfpga_reset_probe' to use 'dev_read_u32_default'
instead of 'fdtdec_get_int'.
Signed-off-by: Simon Goldschmidt
---
drivers/reset/reset-socfpga.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/reset/reset-socfpga.c b/drivers/reset/reset-socfpga.c
index cb8312619f..ee4cbcb02f 100644
--- a/drivers/reset/reset-socfpga.c
+++ b/drivers/reset/reset-socfpga.c
@@ -107,14 +107,12 @@ static const struct reset_ops socfpga_reset_ops = {
static int socfpga_reset_probe(struct udevice *dev)
{
struct socfpga_reset_data *data = dev_get_priv(dev);
- const void *blob = gd->fdt_blob;
- int node = dev_of_offset(dev);
u32 modrst_offset;
void __iomem *membase;
membase = devfdt_get_addr_ptr(dev);
- modrst_offset = fdtdec_get_int(blob, node, "altr,modrst-offset", 0x10);
+ modrst_offset = dev_read_u32_default(dev, "altr,modrst-offset", 0x10);
data->modrst_base = membase + modrst_offset;
return 0;
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 2/6] spi: cadence_qspi: convert to livetree
Convert 'cadence_spi_ofdata_to_platdata' to use dev_read_* functions to
read driver parameters and 'dev_read_first_subnode'/'ofnode_read_*' to
read flash (child node) parameters.
Tested on socfpga_socrates (socfpga gen5).
Signed-off-by: Simon Goldschmidt
---
drivers/spi/cadence_qspi.c | 39 +++---
1 file changed, 19 insertions(+), 20 deletions(-)
diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
index 41c87004d8..e2e54cd277 100644
--- a/drivers/spi/cadence_qspi.c
+++ b/drivers/spi/cadence_qspi.c
@@ -18,8 +18,6 @@
#define CQSPI_INDIRECT_READ2
#define CQSPI_INDIRECT_WRITE 3
-DECLARE_GLOBAL_DATA_PTR;
-
static int cadence_spi_write_speed(struct udevice *bus, uint hz)
{
struct cadence_spi_platdata *plat = bus->platdata;
@@ -295,36 +293,37 @@ static int cadence_spi_xfer(struct udevice *dev, unsigned
int bitlen,
static int cadence_spi_ofdata_to_platdata(struct udevice *bus)
{
struct cadence_spi_platdata *plat = bus->platdata;
- const void *blob = gd->fdt_blob;
- int node = dev_of_offset(bus);
- int subnode;
+ ofnode subnode;
plat->regbase = (void *)devfdt_get_addr_index(bus, 0);
plat->ahbbase = (void *)devfdt_get_addr_index(bus, 1);
- plat->is_decoded_cs = fdtdec_get_bool(blob, node, "cdns,is-decoded-cs");
- plat->fifo_depth = fdtdec_get_uint(blob, node, "cdns,fifo-depth", 128);
- plat->fifo_width = fdtdec_get_uint(blob, node, "cdns,fifo-width", 4);
- plat->trigger_address = fdtdec_get_uint(blob, node,
- "cdns,trigger-address", 0);
+ plat->is_decoded_cs = dev_read_bool(bus, "cdns,is-decoded-cs");
+ plat->fifo_depth = dev_read_u32_default(bus, "cdns,fifo-depth", 128);
+ plat->fifo_width = dev_read_u32_default(bus, "cdns,fifo-width", 4);
+ plat->trigger_address = dev_read_u32_default(bus,
+"cdns,trigger-address",
+0);
/* All other paramters are embedded in the child node */
- subnode = fdt_first_subnode(blob, node);
- if (subnode < 0) {
+ subnode = dev_read_first_subnode(bus);
+ if (!ofnode_valid(subnode)) {
printf("Error: subnode with SPI flash config missing!\n");
return -ENODEV;
}
/* Use 500 KHz as a suitable default */
- plat->max_hz = fdtdec_get_uint(blob, subnode, "spi-max-frequency",
- 50);
+ plat->max_hz = ofnode_read_u32_default(subnode, "spi-max-frequency",
+ 50);
/* Read other parameters from DT */
- plat->page_size = fdtdec_get_uint(blob, subnode, "page-size", 256);
- plat->block_size = fdtdec_get_uint(blob, subnode, "block-size", 16);
- plat->tshsl_ns = fdtdec_get_uint(blob, subnode, "cdns,tshsl-ns", 200);
- plat->tsd2d_ns = fdtdec_get_uint(blob, subnode, "cdns,tsd2d-ns", 255);
- plat->tchsh_ns = fdtdec_get_uint(blob, subnode, "cdns,tchsh-ns", 20);
- plat->tslch_ns = fdtdec_get_uint(blob, subnode, "cdns,tslch-ns", 20);
+ plat->page_size = ofnode_read_u32_default(subnode, "page-size", 256);
+ plat->block_size = ofnode_read_u32_default(subnode, "block-size", 16);
+ plat->tshsl_ns = ofnode_read_u32_default(subnode, "cdns,tshsl-ns",
+200);
+ plat->tsd2d_ns = ofnode_read_u32_default(subnode, "cdns,tsd2d-ns",
+255);
+ plat->tchsh_ns = ofnode_read_u32_default(subnode, "cdns,tchsh-ns", 20);
+ plat->tslch_ns = ofnode_read_u32_default(subnode, "cdns,tslch-ns", 20);
debug("%s: regbase=%p ahbbase=%p max-frequency=%d page-size=%d\n",
__func__, plat->regbase, plat->ahbbase, plat->max_hz,
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 6/6] gpio: dwapb_gpio: convert to livetree
Convert 'gpio_dwapb_bind' to iterate over subnodes using livetree
functions (inspired from mt7621_gpio.c).
Signed-off-by: Simon Goldschmidt
---
drivers/gpio/dwapb_gpio.c | 25 +++--
1 file changed, 11 insertions(+), 14 deletions(-)
diff --git a/drivers/gpio/dwapb_gpio.c b/drivers/gpio/dwapb_gpio.c
index e55fb4ac73..04a2381acd 100644
--- a/drivers/gpio/dwapb_gpio.c
+++ b/drivers/gpio/dwapb_gpio.c
@@ -17,8 +17,6 @@
#include
#include
-DECLARE_GLOBAL_DATA_PTR;
-
#define GPIO_SWPORT_DR(p) (0x00 + (p) * 0xc)
#define GPIO_SWPORT_DDR(p) (0x04 + (p) * 0xc)
#define GPIO_INTEN 0x30
@@ -150,10 +148,10 @@ static int gpio_dwapb_probe(struct udevice *dev)
static int gpio_dwapb_bind(struct udevice *dev)
{
struct gpio_dwapb_platdata *plat = dev_get_platdata(dev);
- const void *blob = gd->fdt_blob;
struct udevice *subdev;
fdt_addr_t base;
- int ret, node, bank = 0;
+ int ret, bank = 0;
+ ofnode node;
/* If this is a child device, there is nothing to do here */
if (plat)
@@ -165,10 +163,9 @@ static int gpio_dwapb_bind(struct udevice *dev)
return -ENXIO;
}
- for (node = fdt_first_subnode(blob, dev_of_offset(dev));
-node > 0;
-node = fdt_next_subnode(blob, node)) {
- if (!fdtdec_get_bool(blob, node, "gpio-controller"))
+ for (node = dev_read_first_subnode(dev); ofnode_valid(node);
+node = dev_read_next_subnode(node)) {
+ if (!ofnode_read_bool(node, "gpio-controller"))
continue;
plat = devm_kcalloc(dev, 1, sizeof(*plat), GFP_KERNEL);
@@ -177,15 +174,15 @@ static int gpio_dwapb_bind(struct udevice *dev)
plat->base = base;
plat->bank = bank;
- plat->pins = fdtdec_get_int(blob, node, "snps,nr-gpios", 0);
- plat->name = fdt_stringlist_get(blob, node, "bank-name", 0,
- NULL);
- if (!plat->name) {
+ plat->pins = ofnode_read_u32_default(node, "snps,nr-gpios", 0);
+
+ if (ofnode_read_string_index(node, "bank-name", 0,
+&plat->name)) {
/*
* Fall back to node name. This means accessing pins
* via bank name won't work.
*/
- plat->name = fdt_get_name(blob, node, NULL);
+ plat->name = ofnode_get_name(node);
}
ret = device_bind(dev, dev->driver, plat->name,
@@ -193,7 +190,7 @@ static int gpio_dwapb_bind(struct udevice *dev)
if (ret)
return ret;
- dev_set_of_offset(subdev, node);
+ dev->node = node;
bank++;
}
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
[U-Boot] [PATCH 3/6] spi: designware: convert to livetree
Convert 'dw_spi_ofdata_to_platdata' to use 'dev_read_u32_default'
instead of 'fdtdec_get_int' and get rid of DECLARE_GLOBAL_DATA_PTR.
Signed-off-by: Simon Goldschmidt
---
drivers/spi/designware_spi.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/spi/designware_spi.c b/drivers/spi/designware_spi.c
index dadb6fa18b..7d58cfae55 100644
--- a/drivers/spi/designware_spi.c
+++ b/drivers/spi/designware_spi.c
@@ -22,8 +22,6 @@
#include
#include
-DECLARE_GLOBAL_DATA_PTR;
-
/* Register offsets */
#define DW_SPI_CTRL0 0x00
#define DW_SPI_CTRL1 0x04
@@ -155,14 +153,12 @@ static int request_gpio_cs(struct udevice *bus)
static int dw_spi_ofdata_to_platdata(struct udevice *bus)
{
struct dw_spi_platdata *plat = bus->platdata;
- const void *blob = gd->fdt_blob;
- int node = dev_of_offset(bus);
plat->regs = (struct dw_spi *)devfdt_get_addr(bus);
/* Use 500KHz as a suitable default */
- plat->frequency = fdtdec_get_int(blob, node, "spi-max-frequency",
- 50);
+ plat->frequency = dev_read_u32_default(bus, "spi-max-frequency",
+ 50);
debug("%s: regs=%p max-frequency=%d\n", __func__, plat->regs,
plat->frequency);
--
2.20.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On 5/9/19 10:18 PM, Joe Hershberger wrote: > On Thu, May 9, 2019 at 3:01 PM Marek Vasut wrote: >> >> On 5/9/19 8:56 PM, Joe Hershberger wrote: >>> On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 (r8a77995). Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM when the DT explicitly specifies RGMII ID or TXID mode instead of setting it unconditionally when the PHY link speed is 1000 Mbit/s. >>> >>> We just ran into an issue with a very similar patch. It blocked my >>> tree being merged for a few months. Finally got to the bottom of it. >>> https://patchwork.ozlabs.org/patch/1096572/ >>> >>> Are you sure there are no boards depending on the broken DT, like the >>> 335-evm was? >> >> I cannot be sure, but the boards which are supported and tested work >> fine. If someone runs into any issue. they can raise them, and we'll >> solve the problem when we come to that bridge. > > The point that came up is that the DT is considered the ABI, so it > shouldn't break / change behavior. Just wanted to make sure you were > aware. I am, but I still prefer for the ethernet to work correctly. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On Thu, May 9, 2019 at 3:01 PM Marek Vasut wrote: > > On 5/9/19 8:56 PM, Joe Hershberger wrote: > > On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: > >> > >> According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the > >> TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 > >> (r8a77995). > >> > >> Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM > >> when the DT explicitly specifies RGMII ID or TXID mode instead of setting > >> it unconditionally when the PHY link speed is 1000 Mbit/s. > > > > We just ran into an issue with a very similar patch. It blocked my > > tree being merged for a few months. Finally got to the bottom of it. > > https://patchwork.ozlabs.org/patch/1096572/ > > > > Are you sure there are no boards depending on the broken DT, like the > > 335-evm was? > > I cannot be sure, but the boards which are supported and tested work > fine. If someone runs into any issue. they can raise them, and we'll > solve the problem when we come to that bridge. The point that came up is that the DT is considered the ABI, so it shouldn't break / change behavior. Just wanted to make sure you were aware. Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On Thu, May 9, 2019 at 3:24 PM Marek Vasut wrote: > > On 5/9/19 10:18 PM, Joe Hershberger wrote: > > On Thu, May 9, 2019 at 3:01 PM Marek Vasut wrote: > >> > >> On 5/9/19 8:56 PM, Joe Hershberger wrote: > >>> On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: > > According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the > TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 > (r8a77995). > > Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM > when the DT explicitly specifies RGMII ID or TXID mode instead of setting > it unconditionally when the PHY link speed is 1000 Mbit/s. > >>> > >>> We just ran into an issue with a very similar patch. It blocked my > >>> tree being merged for a few months. Finally got to the bottom of it. > >>> https://patchwork.ozlabs.org/patch/1096572/ > >>> > >>> Are you sure there are no boards depending on the broken DT, like the > >>> 335-evm was? > >> > >> I cannot be sure, but the boards which are supported and tested work > >> fine. If someone runs into any issue. they can raise them, and we'll > >> solve the problem when we come to that bridge. > > > > The point that came up is that the DT is considered the ABI, so it > > shouldn't break / change behavior. Just wanted to make sure you were > > aware. > > I am, but I still prefer for the ethernet to work correctly. Is the whole patch required to fix it? The commit log doesn't make that clear. "Moreover, only set APSR:TDM when the DT explicitly specifies RGMII ID or TXID mode instead of setting it unconditionally when the PHY link speed is 1000 Mbit/s." Thanks, -Joe > > -- > Best regards, > Marek Vasut > ___ > 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] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On 5/9/19 10:26 PM, Joe Hershberger wrote: > On Thu, May 9, 2019 at 3:24 PM Marek Vasut wrote: >> >> On 5/9/19 10:18 PM, Joe Hershberger wrote: >>> On Thu, May 9, 2019 at 3:01 PM Marek Vasut wrote: On 5/9/19 8:56 PM, Joe Hershberger wrote: > On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: >> >> According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the >> TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 >> (r8a77995). >> >> Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM >> when the DT explicitly specifies RGMII ID or TXID mode instead of setting >> it unconditionally when the PHY link speed is 1000 Mbit/s. > > We just ran into an issue with a very similar patch. It blocked my > tree being merged for a few months. Finally got to the bottom of it. > https://patchwork.ozlabs.org/patch/1096572/ > > Are you sure there are no boards depending on the broken DT, like the > 335-evm was? I cannot be sure, but the boards which are supported and tested work fine. If someone runs into any issue. they can raise them, and we'll solve the problem when we come to that bridge. >>> >>> The point that came up is that the DT is considered the ABI, so it >>> shouldn't break / change behavior. Just wanted to make sure you were >>> aware. >> >> I am, but I still prefer for the ethernet to work correctly. > > Is the whole patch required to fix it? The commit log doesn't make > that clear. "Moreover, only set APSR:TDM when the DT explicitly > specifies RGMII ID or TXID mode instead of setting it unconditionally > when the PHY link speed is 1000 Mbit/s." Yep, it's a port of similar patch from Linux. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] net: ravb: Avoid unsupported internal delay mode for R-Car E3/D3
On Wed, May 1, 2019 at 5:36 PM Marek Vasut wrote: > > According to the R-Car Gen3 Hardware Manual Rev 1.50 of Nov 30, 2018, the > TX clock internal delay mode isn't supported on R-Car E3 (r8a77990) or D3 > (r8a77995). > > Avoid setting the APSR:TDM bit on these SoCs. Moreover, only set APSR:TDM > when the DT explicitly specifies RGMII ID or TXID mode instead of setting > it unconditionally when the PHY link speed is 1000 Mbit/s. > > Signed-off-by: Marek Vasut > Cc: Nobuhiro Iwamatsu > Cc: Joe Hershberger Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 5/9] net: sh_eth: Add RZ/A1 support
On Sat, May 4, 2019 at 12:28 PM Marek Vasut wrote: > > Add support for RZ/A1 SoC specifics. > > Signed-off-by: Marek Vasut > Cc: Chris Brandt > Cc: Joe Hershberger > Cc: Nobuhiro Iwamatsu Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 6/9] net: sh_eth: Add support for operation without clock framework
On Sat, May 4, 2019 at 12:28 PM Marek Vasut wrote: > > Add ifdeffery to allow operation without the clock framework > enabled. This is required on RZ/A1, as it does not have clock > driver yet. > > Signed-off-by: Marek Vasut > Cc: Chris Brandt > Cc: Joe Hershberger > Cc: Nobuhiro Iwamatsu Acked-by: Joe Hershberger ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] net: mscc: luton: Update network driver for pcb90
On Wed, May 1, 2019 at 6:18 AM Horatiu Vultur
wrote:
>
> Update Luton network driver to have support also for pcb90. The pcb90
> has 24 ports from which 12 ports are connected to SerDes6G.
Can you separate this into a restructuring patch and the patch that
adds support for this device? This is a bit hard to read.
Thanks,
-Joe
>
> Signed-off-by: Horatiu Vultur
> ---
> drivers/net/mscc_eswitch/Makefile | 2 +-
> drivers/net/mscc_eswitch/luton_switch.c | 415
>
> 2 files changed, 258 insertions(+), 159 deletions(-)
>
> diff --git a/drivers/net/mscc_eswitch/Makefile
> b/drivers/net/mscc_eswitch/Makefile
> index 9c208d1..02f39a7 100644
> --- a/drivers/net/mscc_eswitch/Makefile
> +++ b/drivers/net/mscc_eswitch/Makefile
> @@ -1,6 +1,6 @@
>
> obj-$(CONFIG_MSCC_OCELOT_SWITCH) += ocelot_switch.o mscc_xfer.o
> mscc_mac_table.o
> -obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_miim.o mscc_xfer.o
> mscc_mac_table.o
> +obj-$(CONFIG_MSCC_LUTON_SWITCH) += luton_switch.o mscc_xfer.o
> mscc_mac_table.o
> obj-$(CONFIG_MSCC_JR2_SWITCH) += jr2_switch.o mscc_xfer.o
> obj-$(CONFIG_MSCC_SERVALT_SWITCH) += servalt_switch.o mscc_xfer.o
> obj-$(CONFIG_MSCC_SERVAL_SWITCH) += serval_switch.o mscc_xfer.o
> mscc_mac_table.o
> diff --git a/drivers/net/mscc_eswitch/luton_switch.c
> b/drivers/net/mscc_eswitch/luton_switch.c
> index 6667614..94852b0 100644
> --- a/drivers/net/mscc_eswitch/luton_switch.c
> +++ b/drivers/net/mscc_eswitch/luton_switch.c
> @@ -15,10 +15,21 @@
> #include
> #include
>
> -#include "mscc_miim.h"
> #include "mscc_xfer.h"
> #include "mscc_mac_table.h"
>
> +#define GCB_MIIM_MII_STATUS0x0
> +#defineGCB_MIIM_STAT_BUSY BIT(3)
> +#define GCB_MIIM_MII_CMD 0x8
> +#defineGCB_MIIM_MII_CMD_OPR_WRITE BIT(1)
> +#defineGCB_MIIM_MII_CMD_OPR_READ BIT(2)
> +#defineGCB_MIIM_MII_CMD_WRDATA(x) ((x) << 4)
> +#defineGCB_MIIM_MII_CMD_REGAD(x) ((x) << 20)
> +#defineGCB_MIIM_MII_CMD_PHYAD(x) ((x) << 25)
> +#defineGCB_MIIM_MII_CMD_VLDBIT(31)
> +#define GCB_MIIM_DATA 0xC
> +#defineGCB_MIIM_DATA_ERROR (0x2 << 16)
> +
> #define ANA_PORT_VLAN_CFG(x) (0x00 + 0x80 * (x))
> #defineANA_PORT_VLAN_CFG_AWARE_ENA BIT(20)
> #defineANA_PORT_VLAN_CFG_POP_CNT(x)((x) << 18)
> @@ -136,61 +147,53 @@
> #define PGID_UNICAST 29
> #define PGID_SRC 80
>
> -enum luton_target {
> - PORT0,
> - PORT1,
> - PORT2,
> - PORT3,
> - PORT4,
> - PORT5,
> - PORT6,
> - PORT7,
> - PORT8,
> - PORT9,
> - PORT10,
> - PORT11,
> - PORT12,
> - PORT13,
> - PORT14,
> - PORT15,
> - PORT16,
> - PORT17,
> - PORT18,
> - PORT19,
> - PORT20,
> - PORT21,
> - PORT22,
> - PORT23,
> - SYS,
> +static const char * const regs_names[] = {
> + "port0", "port1", "port2", "port3", "port4", "port5", "port6",
> "port7",
> + "port8", "port9", "port10", "port11", "port12", "port13", "port14",
> + "port15", "port16", "port17", "port18", "port19", "port20", "port21",
> + "port22", "port23",
> + "sys", "ana", "rew", "gcb", "qs", "hsio",
> +};
> +
> +#define REGS_NAMES_COUNT ARRAY_SIZE(regs_names) + 1
> +#define MAX_PORT 24
> +
> +enum luton_ctrl_regs {
> + SYS = MAX_PORT,
> ANA,
> REW,
> GCB,
> QS,
> - HSIO,
> - TARGET_MAX,
> + HSIO
> };
>
> -#define MAX_PORT (PORT23 - PORT0 + 1)
> +#define MIN_INT_PORT 0
> +#define PORT10 10
> +#define PORT11 11
> +#define MAX_INT_PORT 12
> +#define MIN_EXT_PORT MAX_INT_PORT
> +#define MAX_EXT_PORT MAX_PORT
>
> -#define MIN_INT_PORT PORT0
> -#define MAX_INT_PORT (PORT11 - PORT0 + 1)
> -#define MIN_EXT_PORT PORT12
> -#define MAX_EXT_PORT MAX_PORT
> +#define LUTON_MIIM_BUS_COUNT 2
>
> -enum luton_mdio_target {
> - MIIM,
> - TARGET_MDIO_MAX,
> +struct luton_phy_port_t {
> + size_t phy_addr;
> + struct mii_dev *bus;
> + u8 serdes_index;
> + u8 phy_mode;
> };
>
> -enum luton_phy_id {
> - INTERNAL,
> - EXTERNAL,
> - NUM_PHY,
> +struct luton_private {
> + void __iomem *regs[REGS_NAMES_COUNT];
> + struct mii_dev *bus[LUTON_MIIM_BUS_COUNT];
> + struct luton_phy_port_t ports[MAX_PORT];
> };
>
> -struct luton_private {
> - void __iomem *regs[TARGET_MAX];
> - struct mii_dev *bus[NUM_PHY];
> +struct mscc_miim_dev {
> + void __iomem *regs;
> + phys_addr_t miim_base;
> + unsigned long miim_size;
> + struct mii_dev *bus;
> };
>
> static const unsigned long lu
Re: [U-Boot] [PATCH] arm: socfpga: fix 3 boards missing env var "socfpga_legacy_reset_compat"
On 5/9/19 8:42 PM, Simon Goldschmidt wrote:
[...]
> diff --git a/include/configs/socfpga_vining_fpga.h
> b/include/configs/socfpga_vining_fpga.h
> index 29a92b9146..737a304217 100644
> --- a/include/configs/socfpga_vining_fpga.h
> +++ b/include/configs/socfpga_vining_fpga.h
> @@ -145,6 +145,7 @@
> "run ubi_ubi ; "\
> "else echo \"Unsupported boot mode: \"${bootmode} ; " \
> "fi\0" \
> + "socfpga_legacy_reset_compat=1\0" \
Drop the trailing backslash please.
> #define CONFIG_SYS_REDUNDAND_ENVIRONMENT
> #define CONFIG_ENV_SIZE_REDUND CONFIG_ENV_SIZE
>
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
On 5/9/19 8:55 PM, Simon Goldschmidt wrote: > > > On 09.05.19 20:08, Simon Goldschmidt wrote: >> This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5. >> >> Signed-off-by: Simon Goldschmidt >> --- >> >> Changes in v3: >> - moved socfpga gen5 sysreset driver to extra patch >> >> Changes in v2: None >> >> drivers/sysreset/Kconfig | 7 >> drivers/sysreset/Makefile | 1 + >> drivers/sysreset/sysreset_socfpga.c | 56 + >> 3 files changed, 64 insertions(+) >> create mode 100644 drivers/sysreset/sysreset_socfpga.c > > I just noticed patman complained about new files regarding MAINTAINERS. > Should these new drivers be listed in the MAINTAINERS file under the > socfpga section? I noticed other platforms seem to do that but we don't. > How is this handled? I think that's sane. -- Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH 1/2] net: rtl8169: Implement ->hwaddr_write() callback
Hi Thierry, On Thu, Apr 25, 2019 at 8:32 AM Thierry Reding wrote: > > On Tue, Apr 16, 2019 at 04:36:16PM +, Joe Hershberger wrote: > > On Tue, Apr 16, 2019 at 11:21 AM Thierry Reding > > wrote: > > > > > > From: Thierry Reding > > > > > > Implement this callback that allows the MAC address to be set for the > > > Ethernet card. This is necessary in order for the device to be able to > > > receive packets for the MAC address that U-Boot advertises. > > > > > > Signed-off-by: Thierry Reding > > > > Acked-by: Joe Hershberger > > Hi Joe, > > it's not clear to me who you expect to pick this (and patch 2/2) up. I > didn't Cc anyone, so nobody else may consider themselves responsible for > these. > > Did you mean to pick these up yourself or should they go via Simon's DT > tree along with the two eth-uclass patches that I sent? Or perhaps TomR > handles these patches directly? MAINTAINERS clearly identifies you as a > maintainer for the u-boot-net tree, so I was expecting you to pick them > up. Let me know if I should resend these to someone else with your > Acked-by. I just sent a new PR [1] that Tom should accept soon. I'll be pulling in your patches as well as other remaining Acked patches tomorrow to start build testing. Sorry for the inconvenience. It was a bear to track down. -Joe [1] - https://patchwork.ozlabs.org/patch/1097270/ ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v3 2/4] sysreset: socfpga: gen5: add sysreset driver
On 5/9/19 8:08 PM, Simon Goldschmidt wrote:
> This adds a UCLASS_SYSRESET sysreset driver for socfgpa gen5.
>
> Signed-off-by: Simon Goldschmidt
> ---
>
> Changes in v3:
> - moved socfpga gen5 sysreset driver to extra patch
>
> Changes in v2: None
[...]
> +static int socfpga_sysreset_request(struct udevice *dev,
> + enum sysreset_t type)
> +{
> + struct socfpga_sysreset_data *data = dev_get_priv(dev);
> +
> + switch (type) {
> + case SYSRESET_WARM:
> + writel(1 << RSTMGR_CTRL_SWWARMRSTREQ_LSB,
> +&data->rstmgr_base->ctrl);
> + break;
> + case SYSRESET_COLD:
> + writel(1 << RSTMGR_CTRL_SWCOLDRSTREQ_LSB,
BIT(RSTMGR...LSB)
--
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
