Re: [U-Boot] [PATCH 5/5] rockchip: rk3328: add rock64-rk3328_defconfig

2019-05-16 Thread Kever Yang
Hi Matwey,

    Please add commit message for the patch.

On 05/08/2019 02:34 PM, Matwey V. Kornilov wrote:
> Signed-off-by: Matwey V. Kornilov 
> ---
>  configs/rock64-rk3328_defconfig | 91 
> +
>  1 file changed, 91 insertions(+)
>  create mode 100644 configs/rock64-rk3328_defconfig
>
> diff --git a/configs/rock64-rk3328_defconfig b/configs/rock64-rk3328_defconfig
> new file mode 100644
> index 00..b278315035
> --- /dev/null
> +++ b/configs/rock64-rk3328_defconfig
> @@ -0,0 +1,91 @@
> +CONFIG_SMBIOS_MANUFACTURER="pine64"
> +CONFIG_SMBIOS_PRODUCT_NAME="rock64_rk3328"
> +CONFIG_ARM=y
> +CONFIG_ARCH_ROCKCHIP=y
> +CONFIG_SPL_LIBCOMMON_SUPPORT=y
> +CONFIG_SPL_LIBGENERIC_SUPPORT=y
> +CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_SYS_TEXT_BASE=0x0020
> +CONFIG_ROCKCHIP_RK3328=y
> +CONFIG_ROCKCHIP_SPL_RESERVE_IRAM=0x0
Does this SPL_REVERVE_IRAM=0 fine with support ATF?
SPL TEXT_BASE is 0, and ATF starts at 0x10, I use to reserve
big enough space for ATF and U-Boot before SPL enable
the relocate feature, or else it's very easy to get panic in SPL.

Thanks,
- Kever
> +CONFIG_SPL_DRIVERS_MISC_SUPPORT=y
> +CONFIG_SPL_STACK_R_ADDR=0x60
> +CONFIG_DEBUG_UART_BASE=0xFF13
> +CONFIG_DEBUG_UART_CLOCK=2400
> +CONFIG_DEBUG_UART=y
> +CONFIG_NR_DRAM_BANKS=1
> +# CONFIG_ANDROID_BOOT_IMAGE is not set
> +CONFIG_FIT=y
> +CONFIG_FIT_VERBOSE=y
> +CONFIG_SPL_LOAD_FIT=y
> +CONFIG_SPL_FIT_GENERATOR="arch/arm/mach-rockchip/make_fit_atf.py"
> +CONFIG_DEFAULT_FDT_FILE="rockchip/rk3328-rock64.dtb"
> +# CONFIG_DISPLAY_CPUINFO is not set
> +CONFIG_DISPLAY_BOARDINFO_LATE=y
> +CONFIG_SPL_STACK_R=y
> +CONFIG_SPL_ATF=y
> +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
> +CONFIG_FASTBOOT_BUF_ADDR=0x800800
> +CONFIG_FASTBOOT_FLASH=y
> +CONFIG_FASTBOOT_FLASH_MMC_DEV=1
> +CONFIG_CMD_BOOTZ=y
> +CONFIG_CMD_GPT=y
> +CONFIG_CMD_MMC=y
> +CONFIG_CMD_SF=y
> +CONFIG_CMD_USB=y
> +# CONFIG_CMD_SETEXPR is not set
> +CONFIG_CMD_TIME=y
> +CONFIG_DEFAULT_DEVICE_TREE="rk3328-rock64"
> +CONFIG_SPL_OF_CONTROL=y
> +CONFIG_OF_SPL_REMOVE_PROPS="pinctrl-0 pinctrl-names clock-names 
> interrupt-parent assigned-clocks assigned-clock-rates assigned-clock-parents"
> +CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_NET_RANDOM_ETHADDR=y
> +CONFIG_REGMAP=y
> +CONFIG_SPL_REGMAP=y
> +CONFIG_SYSCON=y
> +CONFIG_SPL_SYSCON=y
> +CONFIG_CLK=y
> +CONFIG_SPL_CLK=y
> +CONFIG_FASTBOOT_CMD_OEM_FORMAT=y
> +CONFIG_ROCKCHIP_GPIO=y
> +CONFIG_SYS_I2C_ROCKCHIP=y
> +CONFIG_MMC_DW=y
> +CONFIG_MMC_DW_ROCKCHIP=y
> +CONFIG_SPI_FLASH=y
> +CONFIG_SF_DEFAULT_SPEED=2000
> +CONFIG_DM_ETH=y
> +CONFIG_ETH_DESIGNWARE=y
> +CONFIG_GMAC_ROCKCHIP=y
> +CONFIG_PHY=y
> +CONFIG_PINCTRL=y
> +CONFIG_SPL_PINCTRL=y
> +CONFIG_PINCTRL_ROCKCHIP_RK3328=y
> +CONFIG_DM_PMIC=y
> +CONFIG_PMIC_RK8XX=y
> +CONFIG_REGULATOR_PWM=y
> +CONFIG_DM_REGULATOR_FIXED=y
> +CONFIG_REGULATOR_RK8XX=y
> +CONFIG_PWM_ROCKCHIP=y
> +CONFIG_RAM=y
> +CONFIG_SPL_RAM=y
> +CONFIG_DM_RESET=y
> +CONFIG_BAUDRATE=150
> +CONFIG_DEBUG_UART_SHIFT=2
> +CONFIG_SYSRESET=y
> +CONFIG_USB=y
> +CONFIG_USB_XHCI_HCD=y
> +CONFIG_USB_XHCI_DWC3=y
> +CONFIG_USB_EHCI_HCD=y
> +CONFIG_USB_EHCI_GENERIC=y
> +CONFIG_USB_OHCI_HCD=y
> +CONFIG_USB_OHCI_GENERIC=y
> +CONFIG_USB_DWC2=y
> +CONFIG_USB_DWC3=y
> +CONFIG_USB_GADGET=y
> +CONFIG_USB_GADGET_MANUFACTURER="Rockchip"
> +CONFIG_USB_GADGET_VENDOR_NUM=0x2207
> +CONFIG_USB_GADGET_PRODUCT_NUM=0x330a
> +CONFIG_USB_GADGET_DWC2_OTG=y
> +CONFIG_USE_TINY_PRINTF=y
> +CONFIG_SPL_TINY_MEMSET=y
> +CONFIG_ERRNO_STR=y



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0

2019-05-16 Thread Peter Robinson
On Thu, May 16, 2019 at 1:47 AM Andre Przywara  wrote:
>
> The first USB controller on the A64 SoC shares a PHY with the OTG
> controller. Reportedly to avoid problems with the VBUS regulator under
> Linux, we don't link OHCI0/EHCI0 to the USB PHY in the A64 .dtsi file.
>
> However on boards which can't use peripheral mode (because they have an
> always-on VBUS supply on an USB-A socket) we don't need this trick, and
> can properly connect host controller 0 to the PHY 0.
>
> Amend the Pine64 and SoPine/LTS .dts to reflect this. This enables the
> upper USB port in U-Boot on those boards.
>
> Signed-off-by: Andre Przywara 
> ---
>  arch/arm/dts/sun50i-a64-pine64.dts   | 5 -
>  arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 5 -
>  2 files changed, 8 insertions(+), 2 deletions(-)

Are these changes going to go upstream to Linux too? If not it's
probably best to add it to a u-boot.dtsi so the changes don't get lost
when the DT files are re-synced from Linux. Same with the similar
patches for the H6 boards.

Peter

> diff --git a/arch/arm/dts/sun50i-a64-pine64.dts 
> b/arch/arm/dts/sun50i-a64-pine64.dts
> index c077b6c1f4..523a4d5bff 100644
> --- a/arch/arm/dts/sun50i-a64-pine64.dts
> +++ b/arch/arm/dts/sun50i-a64-pine64.dts
> @@ -80,6 +80,8 @@
>  };
>
>  &ehci0 {
> +   phys = <&usbphy 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -136,6 +138,8 @@
>  };
>
>  &ohci0 {
> +   phys = <&usbphy 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -301,7 +305,6 @@
>
>  &usb_otg {
> dr_mode = "host";
> -   status = "okay";
>  };
>
>  &usbphy {
> diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts 
> b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> index 53fcc9098d..1986897177 100644
> --- a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> +++ b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> @@ -85,6 +85,8 @@
>  };
>
>  &ehci0 {
> +   phys = <&usbphy 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -131,6 +133,8 @@
>  };
>
>  &ohci0 {
> +   phys = <&usbphy 0>;
> +   phy-names = "usb";
> status = "okay";
>  };
>
> @@ -172,7 +176,6 @@
>
>  &usb_otg {
> dr_mode = "host";
> -   status = "okay";
>  };
>
>  &usbphy {
> --
> 2.14.5
>
> ___
> 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/3] arm: exynos: arndale: Remove unused CONFIG_POWER and CONFIG_POWER_I2C

2019-05-16 Thread Minkyu Kang
Hi,

On 11/05/2019 20:24, Krzysztof Kozlowski wrote:
> The CONFIG_POWER and CONFIG_POWER_I2C were introduced in
> include/configs/exynos5-common.h in commit 19bd3aaa5991 ("exynos5: fix
> build break by adding CONFIG_POWER") and then it propagated up to
> include/configs/arndale.h.  However before that commit, there was no
> build break at all on Arndale and SMDK5250 boards.  It seems the commit
> fixed nothing and just added unused defines.
> 
> In fact, the Arndale board is not configuring its PMIC (S5M8767) which
> uses I2C bus.
> 
> Signed-off-by: Krzysztof Kozlowski 
> Reviewed-by: Simon Glass 
> 
> ---
> 
> Not tested on Arndale board. Testing is welcomed.
> 
> Changes since v1:
> 1. Add Simon's tag.
> 2. Reorder patches - first remove CONFIG_POWER_I2C, then
>CONFIG_DM_I2C_COMPAT.
> ---
>  include/configs/arndale.h | 8 
>  1 file changed, 8 deletions(-)
> 
> diff --git a/include/configs/arndale.h b/include/configs/arndale.h
> index dd321c4748d0..841f3616482b 100644
> --- a/include/configs/arndale.h
> +++ b/include/configs/arndale.h
> @@ -29,10 +29,6 @@
>  
>  #define CONFIG_SYS_INIT_SP_ADDR  CONFIG_IRAM_STACK
>  
> -/* PMIC */
> -#define CONFIG_POWER
> -#define CONFIG_POWER_I2C
> -
>  #define CONFIG_PREBOOT
>  
>  #define CONFIG_S5P_PA_SYSRAM 0x0202
> @@ -41,8 +37,4 @@
>  /* The PERIPHBASE in the CBAR register is wrong on the Arndale, so override 
> it */
>  #define CONFIG_ARM_GIC_BASE_ADDRESS  0x1048
>  
> -/* Power */
> -#define CONFIG_POWER
> -#define CONFIG_POWER_I2C
> -
>  #endif   /* __CONFIG_H */
> 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 2/3] arm: exynos: arndale: Remove unused CONFIG_DM_I2C_COMPAT

2019-05-16 Thread Minkyu Kang
Hi,

On 11/05/2019 20:24, 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 
> Reviewed-by: Simon Glass 
> 
> ---
> 
> Not tested on Arndale board. Testing is welcomed.
> 
> Changes since v1:
> 1. Add Simon's tag.
> 2. Reorder patches - first remove CONFIG_POWER_I2C, then
>CONFIG_DM_I2C_COMPAT.
> ---
>  configs/arndale_defconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig
> index 9727d28c1241..e90d670f6813 100644
> --- a/configs/arndale_defconfig
> +++ b/configs/arndale_defconfig
> @@ -25,7 +25,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_SUPPORT_EMMC_BOOT=y
>  CONFIG_MMC_DW=y
>  CONFIG_MMC_SDHCI=y
> 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v2 3/3] configs: arndale: Use appropriate driver for Asix AX88760

2019-05-16 Thread Minkyu Kang
Hi,

On 11/05/2019 20:24, Krzysztof Kozlowski wrote:
> Arndale board has an Asix AX88760 USB 2.0 Hub and Fast Ethernet combo.
> The appropriate driver for it is USB_ETHER_ASIX.
> 
> The mistake probably came from misinterpretation of commit e9954b867ce0
> ("usb: eth: add ASIX AX88179 DRIVER") which was tested on RECS5250 COM
> module.  This module indeed has Exynos5250 and some similarities with
> Arndale 5250 board but the USB/Ethernet chip used there is apparently
> different.
> 
> Fixes: f58ad98a621c ("usb: net: migrate USB Ethernet adapters to Kconfig")
> Signed-off-by: Krzysztof Kozlowski 
> Reviewed-by: Lukasz Majewski 
> 
> ---
> 
> Not tested.
> 
> Changes since v1:
> 1. Add Lukasz's tag.
> ---
>  configs/arndale_defconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/arndale_defconfig b/configs/arndale_defconfig
> index e90d670f6813..37ad6accc396 100644
> --- a/configs/arndale_defconfig
> +++ b/configs/arndale_defconfig
> @@ -42,4 +42,4 @@ CONFIG_USB_XHCI_HCD=y
>  CONFIG_USB_XHCI_DWC3=y
>  CONFIG_USB_EHCI_HCD=y
>  CONFIG_USB_HOST_ETHER=y
> -CONFIG_USB_ETHER_ASIX88179=y
> +CONFIG_USB_ETHER_ASIX=y
> 

applied to u-boot-samsung.

Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 0/3] imx: Cleanup i.MX6Q mccmon6 board configuration

2019-05-16 Thread Lukasz Majewski

This patch series updates mccmon6 configuration to remove some "removal"
warnings (i.e. disables the USB related code).

It also on purpose disables gigabig ethernet, as this board works on
10/100 Mib environments.

Patches applicable on top of master branch:
SHA1: 5b4b680cfe29a67171ccbe439c66374cb31faca3



Lukasz Majewski (3):
  ARM: imx: cosmetic: Remove not needed comment from the mccmon6.h file
  ARM: imx: config: Disable support for USB on MCCMON6
  ARM: imx: Disable 1Gbps support on MCCMON6's KSZ9031 PHY

 configs/mccmon6_nor_defconfig | 2 --
 configs/mccmon6_sd_defconfig  | 2 --
 include/configs/mccmon6.h | 8 +---
 3 files changed, 1 insertion(+), 11 deletions(-)

-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 1/3] ARM: imx: cosmetic: Remove not needed comment from the mccmon6.h file

2019-05-16 Thread Lukasz Majewski
This comment is a leftover from the Kconfig CONFIG_*MTD* move.

Signed-off-by: Lukasz Majewski 
---

 include/configs/mccmon6.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/include/configs/mccmon6.h b/include/configs/mccmon6.h
index a1774c027a..b97373512f 100644
--- a/include/configs/mccmon6.h
+++ b/include/configs/mccmon6.h
@@ -65,8 +65,6 @@
 #define CONFIG_SYS_FLASH_BANKS_LIST{ (CONFIG_SYS_FLASH_BASE) }
 #define CONFIG_SYS_FLASH_BANKS_SIZES   { (32 * SZ_1M) }
 
-/* MTD support */
-
 /* USB Configs */
 #define CONFIG_USB_MAX_CONTROLLER_COUNT2
 #define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 3/3] ARM: imx: Disable 1Gbps support on MCCMON6's KSZ9031 PHY

2019-05-16 Thread Lukasz Majewski
mccmon6 works in 10/100 MiB Ethernet environment, so disabling 1GiB support
improves robustness of the network after power up (as one don't need to
wait for autoneg).

Signed-off-by: Lukasz Majewski 


---

 include/configs/mccmon6.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/configs/mccmon6.h b/include/configs/mccmon6.h
index 231b2af87a..667dac7340 100644
--- a/include/configs/mccmon6.h
+++ b/include/configs/mccmon6.h
@@ -78,6 +78,7 @@
"fdt_high=0x\0" \
"initrd_high=0x\0" \
"boot_os=yes\0" \
+   "disable_giga=yes\0" \
"download_kernel=" \
"tftpboot ${kernel_addr} ${kernel_file};" \
"tftpboot ${fdt_addr} ${fdtfile};\0" \
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 2/3] ARM: imx: config: Disable support for USB on MCCMON6

2019-05-16 Thread Lukasz Majewski
The IMX6Q based MCCMON6 is not using USB for any purpose.

Signed-off-by: Lukasz Majewski 
---

 configs/mccmon6_nor_defconfig | 2 --
 configs/mccmon6_sd_defconfig  | 2 --
 include/configs/mccmon6.h | 5 -
 3 files changed, 9 deletions(-)

diff --git a/configs/mccmon6_nor_defconfig b/configs/mccmon6_nor_defconfig
index af2a106644..ddbcd69316 100644
--- a/configs/mccmon6_nor_defconfig
+++ b/configs/mccmon6_nor_defconfig
@@ -20,7 +20,6 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
-CONFIG_CMD_USB=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_MTDPARTS=y
@@ -50,5 +49,4 @@ CONFIG_MII=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
 CONFIG_DM_THERMAL=y
-CONFIG_USB=y
 CONFIG_OF_LIBFDT=y
diff --git a/configs/mccmon6_sd_defconfig b/configs/mccmon6_sd_defconfig
index aac433c13b..a018d804f8 100644
--- a/configs/mccmon6_sd_defconfig
+++ b/configs/mccmon6_sd_defconfig
@@ -21,7 +21,6 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_I2C=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_SF=y
-CONFIG_CMD_USB=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_MTDPARTS=y
@@ -51,5 +50,4 @@ CONFIG_MII=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
 CONFIG_DM_THERMAL=y
-CONFIG_USB=y
 CONFIG_OF_LIBFDT=y
diff --git a/include/configs/mccmon6.h b/include/configs/mccmon6.h
index b97373512f..231b2af87a 100644
--- a/include/configs/mccmon6.h
+++ b/include/configs/mccmon6.h
@@ -65,11 +65,6 @@
 #define CONFIG_SYS_FLASH_BANKS_LIST{ (CONFIG_SYS_FLASH_BASE) }
 #define CONFIG_SYS_FLASH_BANKS_SIZES   { (32 * SZ_1M) }
 
-/* USB Configs */
-#define CONFIG_USB_MAX_CONTROLLER_COUNT2
-#define CONFIG_MXC_USB_PORTSC  (PORT_PTS_UTMI | PORT_PTS_PTW)
-#define CONFIG_MXC_USB_FLAGS   0
-
 /* Ethernet Configuration */
 #define CONFIG_FEC_MXC
 #define IMX_FEC_BASE   ENET_BASE_ADDR
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] sysreset: switch to using SYSRESET_POWER_OFF for poweroff

2019-05-16 Thread Patrick DELAUNAY
Hi Urja,

> 
> It seems that SYSRESET_POWER_OFF was added recently, and all previous
> code used SYSRESET_POWER for poweroff. SYSRESET_POWER is supposed
> to be a PMIC-level power cycle, not a poweroff.
> 
> Signed-off-by: Urja Rannikko 
> ---
> Note: I didnt touch the test/dm/sysreset.c code yet, mostly because I wanted 
> to
> get feedback on this first and that i'd need to understand the tests properly 
> to do
> that (and i havent used them before at all).
> ---
>  arch/arm/mach-stm32mp/cmd_poweroff.c | 2 +-
>  arch/sandbox/cpu/state.c | 2 +-
>  drivers/power/pmic/stpmic1.c | 2 +-
>  drivers/sysreset/sysreset_psci.c | 2 +-
>  drivers/sysreset/sysreset_sandbox.c  | 4 ++--
>  5 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/arm/mach-stm32mp/cmd_poweroff.c b/arch/arm/mach-
> stm32mp/cmd_poweroff.c
> index f54dd1daf2..62347425a0 100644
> --- a/arch/arm/mach-stm32mp/cmd_poweroff.c
> +++ b/arch/arm/mach-stm32mp/cmd_poweroff.c
> @@ -14,7 +14,7 @@ int do_poweroff(cmd_tbl_t *cmdtp, int flag, int argc, char *
> const argv[])
>   puts("poweroff ...\n");
>   mdelay(100);
> 
> - ret = sysreset_walk(SYSRESET_POWER);
> + ret = sysreset_walk(SYSRESET_POWER_OFF);
> 
>   if (ret == -EINPROGRESS)
>   mdelay(1000);
> diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c index
> d3b9c05985..dee5fde4f7 100644
> --- a/arch/sandbox/cpu/state.c
> +++ b/arch/sandbox/cpu/state.c
> @@ -355,7 +355,7 @@ void state_reset_for_test(struct sandbox_state *state)  {
>   /* No reset yet, so mark it as such. Always allow power reset */
>   state->last_sysreset = SYSRESET_COUNT;
> - state->sysreset_allowed[SYSRESET_POWER] = true;
> + state->sysreset_allowed[SYSRESET_POWER_OFF] = true;
> 
>   memset(&state->wdt, '\0', sizeof(state->wdt));
>   memset(state->spi, '\0', sizeof(state->spi)); diff --git
> a/drivers/power/pmic/stpmic1.c b/drivers/power/pmic/stpmic1.c index
> 65296c5fc3..eb735f4fe3 100644
> --- a/drivers/power/pmic/stpmic1.c
> +++ b/drivers/power/pmic/stpmic1.c
> @@ -221,7 +221,7 @@ static int stpmic1_sysreset_request(struct udevice *dev,
> enum sysreset_t type)
>   struct udevice *pmic_dev;
>   int ret;
> 
> - if (type != SYSRESET_POWER)
> + if (type != SYSRESET_POWER_OFF)
>   return -EPROTONOSUPPORT;

In fact in the next part of the code, we are supporting 
only SYSRESET_POWER (reset with PMIC1 switch OFF and restart) 
and not SYSRESET_POWER_OFF

because Power Cycle if RREQ_EN=1

I think you need to remove the update on this file for your patch and
I will modified this function is to support both mode

>   ret = uclass_get_device_by_driver(UCLASS_PMIC,
> diff --git a/drivers/sysreset/sysreset_psci.c 
> b/drivers/sysreset/sysreset_psci.c
> index de2ec8aeb1..c7907b3226 100644
> --- a/drivers/sysreset/sysreset_psci.c
> +++ b/drivers/sysreset/sysreset_psci.c
> @@ -18,7 +18,7 @@ static int psci_sysreset_request(struct udevice *dev, enum
> sysreset_t type)
>   case SYSRESET_COLD:
>   function_id = PSCI_0_2_FN_SYSTEM_RESET;
>   break;
> - case SYSRESET_POWER:
> + case SYSRESET_POWER_OFF:
>   function_id = PSCI_0_2_FN_SYSTEM_OFF;
>   break;
>   default:
> diff --git a/drivers/sysreset/sysreset_sandbox.c
> b/drivers/sysreset/sysreset_sandbox.c
> index 38e2a7e241..8bc9f4b4cc 100644
> --- a/drivers/sysreset/sysreset_sandbox.c
> +++ b/drivers/sysreset/sysreset_sandbox.c
> @@ -57,13 +57,13 @@ static int sandbox_sysreset_request(struct udevice *dev,
> enum sysreset_t type)
>   case SYSRESET_COLD:
>   state->last_sysreset = type;
>   break;
> - case SYSRESET_POWER:
> + case SYSRESET_POWER_OFF:
>   state->last_sysreset = type;
>   if (!state->sysreset_allowed[type])
>   return -EACCES;
>   sandbox_exit();
>   break;
> - case SYSRESET_POWER_OFF:
> + case SYSRESET_POWER:
>   if (!state->sysreset_allowed[type])
>   return -EACCES;
>   default:
> --
> 2.21.0

Regards.

Patrick
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/4] mailbox: introduce stm32-ipcc driver

2019-05-16 Thread Patrice CHOTARD
Hi Fabien

On 5/14/19 11:20 AM, Fabien Dessenne wrote:
> On STM32 family, the IPCC peripheral allows the communication
> between 2 processors offering doorbells mechanism.
> 
> Signed-off-by: Fabien Dessenne 
> Signed-off-by: Loic Pallardy 
> ---
>  drivers/mailbox/Kconfig  |   7 ++
>  drivers/mailbox/Makefile |   1 +
>  drivers/mailbox/stm32-ipcc.c | 167 
> +++
>  3 files changed, 175 insertions(+)
>  create mode 100644 drivers/mailbox/stm32-ipcc.c
> 
> diff --git a/drivers/mailbox/Kconfig b/drivers/mailbox/Kconfig
> index 2836ee4..11bf552 100644
> --- a/drivers/mailbox/Kconfig
> +++ b/drivers/mailbox/Kconfig
> @@ -24,6 +24,13 @@ config TEGRA_HSP
> This enables support for the NVIDIA Tegra HSP Hw module, which
> implements doorbells, mailboxes, semaphores, and shared interrupts.
>  
> +config STM32_IPCC
> + bool "Enable STM32 IPCC controller support"
> + depends on DM_MAILBOX && ARCH_STM32MP
> + help
> +   This enables support for the STM32MP IPCC Hw module, which
> +   implements doorbells between 2 processors.
> +
>  config K3_SEC_PROXY
>   bool "Texas Instruments K3 Secure Proxy Driver"
>   depends on DM_MAILBOX && ARCH_K3
> diff --git a/drivers/mailbox/Makefile b/drivers/mailbox/Makefile
> index cd23769..a753cc4 100644
> --- a/drivers/mailbox/Makefile
> +++ b/drivers/mailbox/Makefile
> @@ -6,5 +6,6 @@
>  obj-$(CONFIG_$(SPL_)DM_MAILBOX) += mailbox-uclass.o
>  obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox.o
>  obj-$(CONFIG_SANDBOX_MBOX) += sandbox-mbox-test.o
> +obj-$(CONFIG_STM32_IPCC) += stm32-ipcc.o
>  obj-$(CONFIG_TEGRA_HSP) += tegra-hsp.o
>  obj-$(CONFIG_K3_SEC_PROXY) += k3-sec-proxy.o
> diff --git a/drivers/mailbox/stm32-ipcc.c b/drivers/mailbox/stm32-ipcc.c
> new file mode 100644
> index 000..c3df967
> --- /dev/null
> +++ b/drivers/mailbox/stm32-ipcc.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) STMicroelectronics 2019 - All Rights Reserved
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * IPCC has one set of registers per CPU
> + * IPCC_PROC_OFFST allows to define cpu registers set base address
> + * according to the assigned proc_id.
> + */
> +
> +#define IPCC_PROC_OFFST  0x010
> +
> +#define IPCC_XSCR0x008
> +#define IPCC_XTOYSR  0x00c
> +
> +#define IPCC_HWCFGR  0x3f0
> +#define IPCFGR_CHAN_MASK GENMASK(7, 0)
> +
> +#define RX_BIT_CHAN(chan)BIT(chan)
> +#define TX_BIT_SHIFT 16
> +#define TX_BIT_CHAN(chan)BIT(TX_BIT_SHIFT + (chan))
> +
> +#define STM32_MAX_PROCS  2
> +
> +struct stm32_ipcc {
> + void __iomem *reg_base;
> + void __iomem *reg_proc;
> + u32 proc_id;
> + u32 n_chans;
> +};
> +
> +static int stm32_ipcc_request(struct mbox_chan *chan)
> +{
> + struct stm32_ipcc *ipcc = dev_get_priv(chan->dev);
> +
> + debug("%s(chan=%p)\n", __func__, chan);
> +
> + if (chan->id >= ipcc->n_chans) {
> + debug("%s failed to request channel: %ld\n",
> +   __func__, chan->id);
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int stm32_ipcc_free(struct mbox_chan *chan)
> +{
> + debug("%s(chan=%p)\n", __func__, chan);
> +
> + return 0;
> +}
> +
> +static int stm32_ipcc_send(struct mbox_chan *chan, const void *data)
> +{
> + struct stm32_ipcc *ipcc = dev_get_priv(chan->dev);
> +
> + debug("%s(chan=%p, data=%p)\n", __func__, chan, data);
> +
> + if (readl(ipcc->reg_proc + IPCC_XTOYSR) & BIT(chan->id))
> + return -EBUSY;
> +
> + /* set channel n occupied */
> + setbits_le32(ipcc->reg_proc + IPCC_XSCR, TX_BIT_CHAN(chan->id));
> +
> + return 0;
> +}
> +
> +static int stm32_ipcc_recv(struct mbox_chan *chan, void *data)
> +{
> + struct stm32_ipcc *ipcc = dev_get_priv(chan->dev);
> + u32 val;
> + int proc_offset;
> +
> + debug("%s(chan=%p, data=%p)\n", __func__, chan, data);
> +
> + /* read 'channel occupied' status from other proc */
> + proc_offset = ipcc->proc_id ? -IPCC_PROC_OFFST : IPCC_PROC_OFFST;
> + val = readl(ipcc->reg_proc + proc_offset + IPCC_XTOYSR);
> +
> + if (!(val & BIT(chan->id)))
> + return -ENODATA;
> +
> + setbits_le32(ipcc->reg_proc + IPCC_XSCR, RX_BIT_CHAN(chan->id));
> +
> + return 0;
> +}
> +
> +static int stm32_ipcc_probe(struct udevice *dev)
> +{
> + struct stm32_ipcc *ipcc = dev_get_priv(dev);
> + fdt_addr_t addr;
> + const fdt32_t *cell;
> + struct clk clk;
> + int len, ret;
> +
> + debug("%s(dev=%p)\n", __func__, dev);
> +
> + addr = dev_read_addr(dev);
> + if (addr == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + ipcc->reg_base = (void __iomem *)addr;
> +
> + /* proc_id */
> + cell = dev_read_prop(dev, "st,proc_id", &len);
> + if (len < sizeof(fdt32_t)) {
> + dev_dbg(dev, "Missing st,proc

Re: [U-Boot] [PATCH 3/4] configs: stm32mp15: enable IPCC mailbox

2019-05-16 Thread Patrice CHOTARD


On 5/14/19 11:20 AM, Fabien Dessenne wrote:
> Activate the ipcc mailbox for stm32mp15 configs.
> 
> Signed-off-by: Fabien Dessenne 
> ---
>  configs/stm32mp15_basic_defconfig   | 2 ++
>  configs/stm32mp15_trusted_defconfig | 2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/configs/stm32mp15_basic_defconfig 
> b/configs/stm32mp15_basic_defconfig
> index 0ea9dff..f03c72c 100644
> --- a/configs/stm32mp15_basic_defconfig
> +++ b/configs/stm32mp15_basic_defconfig
> @@ -52,6 +52,8 @@ CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_STM32F7=y
>  CONFIG_LED=y
>  CONFIG_LED_GPIO=y
> +CONFIG_DM_MAILBOX=y
> +CONFIG_STM32_IPCC=y
>  CONFIG_DM_MMC=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_STM32_SDMMC2=y
> diff --git a/configs/stm32mp15_trusted_defconfig 
> b/configs/stm32mp15_trusted_defconfig
> index 3c2bb75..525f4c3 100644
> --- a/configs/stm32mp15_trusted_defconfig
> +++ b/configs/stm32mp15_trusted_defconfig
> @@ -44,6 +44,8 @@ CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_STM32F7=y
>  CONFIG_LED=y
>  CONFIG_LED_GPIO=y
> +CONFIG_DM_MAILBOX=y
> +CONFIG_STM32_IPCC=y
>  CONFIG_DM_MMC=y
>  CONFIG_SUPPORT_EMMC_BOOT=y
>  CONFIG_STM32_SDMMC2=y
> 

Reviewed-by: Patrice Chotard 

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/4] MAINTAINERS: Add stm32 mailbox IPPC driver

2019-05-16 Thread Patrice CHOTARD


On 5/14/19 11:20 AM, Fabien Dessenne wrote:
> Signed-off-by: Fabien Dessenne 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 33fd465..5523c4a 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -301,6 +301,7 @@ S:Maintained
>  F:   arch/arm/mach-stm32mp/
>  F:   drivers/clk/clk_stm32mp1.c
>  F:   drivers/i2c/stm32f7_i2c.c
> +F:   drivers/mailbox/stm32-ipcc.c
>  F:   drivers/misc/stm32mp_fuse.c
>  F:   drivers/mmc/stm32_sdmmc2.c
>  F:   drivers/phy/phy-stm32-usbphyc.c
> 

Reviewed-by: Patrice Chotard 

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] ARM: dts: stm32: Add ipcc mailbox support on stm32mp1

2019-05-16 Thread Patrice CHOTARD


On 5/14/19 11:20 AM, Fabien Dessenne wrote:
> Add IPCC mailbox support on stm32mp157 eval and disco boards.
> 
> Signed-off-by: Fabien Dessenne 
> ---
>  arch/arm/dts/stm32mp157a-dk1.dts |  4 
>  arch/arm/dts/stm32mp157c-ed1.dts |  4 
>  arch/arm/dts/stm32mp157c.dtsi| 13 +
>  3 files changed, 21 insertions(+)
> 
> diff --git a/arch/arm/dts/stm32mp157a-dk1.dts 
> b/arch/arm/dts/stm32mp157a-dk1.dts
> index e36773d..b8dd4ba 100644
> --- a/arch/arm/dts/stm32mp157a-dk1.dts
> +++ b/arch/arm/dts/stm32mp157a-dk1.dts
> @@ -228,6 +228,10 @@
>   };
>  };
>  
> +&ipcc {
> + status = "okay";
> +};
> +
>  &iwdg2 {
>   timeout-sec = <32>;
>   status = "okay";
> diff --git a/arch/arm/dts/stm32mp157c-ed1.dts 
> b/arch/arm/dts/stm32mp157c-ed1.dts
> index b10208f..ab11c83 100644
> --- a/arch/arm/dts/stm32mp157c-ed1.dts
> +++ b/arch/arm/dts/stm32mp157c-ed1.dts
> @@ -318,6 +318,10 @@
>   };
>  };
>  
> +&ipcc {
> + status = "okay";
> +};
> +
>  &iwdg2 {
>   timeout-sec = <32>;
>   status = "okay";
> diff --git a/arch/arm/dts/stm32mp157c.dtsi b/arch/arm/dts/stm32mp157c.dtsi
> index 9463433..d90028a 100644
> --- a/arch/arm/dts/stm32mp157c.dtsi
> +++ b/arch/arm/dts/stm32mp157c.dtsi
> @@ -849,6 +849,19 @@
>   status = "disabled";
>   };
>  
> + ipcc: mailbox@4c001000 {
> + compatible = "st,stm32mp1-ipcc";
> + #mbox-cells = <1>;
> + reg = <0x4c001000 0x400>;
> + st,proc-id = <0>;
> + interrupts-extended =
> + <&intc GIC_SPI 100 IRQ_TYPE_LEVEL_HIGH>,
> + <&intc GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
> + interrupt-names = "rx", "tx";
> + clocks = <&rcc IPCC>;
> + status = "disabled";
> + };
> +
>   rcc: rcc@5000 {
>   compatible = "st,stm32mp1-rcc", "syscon";
>   reg = <0x5000 0x1000>;
> 

Reviewed-by: Patrice Chotard 

Thanks
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/2] configs: Add SPL Kconfig options

2019-05-16 Thread Shyam Saini
Add CONFIG_SPL_MMC_SUPPORT and CONFIG_SPL_NAND_SUPPORT for
Kconfig selection.

Signed-off-by: Jagan Teki 
Signed-off-by: Shyam Saini 
---
 configs/imx6dl_icore_nand_defconfig  |  1 +
 configs/imx6dl_mamoj_defconfig   |  1 +
 configs/imx6q_icore_nand_defconfig   |  1 +
 configs/imx6q_logic_defconfig|  1 +
 configs/imx6qdl_icore_mipi_defconfig |  1 +
 configs/imx6qdl_icore_mmc_defconfig  |  1 +
 configs/imx6qdl_icore_nand_defconfig |  1 +
 configs/imx6qdl_icore_rqs_defconfig  |  1 +
 configs/imx6ul_geam_mmc_defconfig|  1 +
 configs/imx6ul_geam_nand_defconfig   |  1 +
 configs/imx6ul_isiot_emmc_defconfig  |  1 +
 configs/imx6ul_isiot_nand_defconfig  |  1 +
 include/configs/imx6-engicam.h   | 10 +-
 13 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/configs/imx6dl_icore_nand_defconfig 
b/configs/imx6dl_icore_nand_defconfig
index 7b1f7abc4e..94c81b3e4a 100644
--- a/configs/imx6dl_icore_nand_defconfig
+++ b/configs/imx6dl_icore_nand_defconfig
@@ -13,6 +13,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
diff --git a/configs/imx6dl_mamoj_defconfig b/configs/imx6dl_mamoj_defconfig
index f3661c0a76..62a068c3c1 100644
--- a/configs/imx6dl_mamoj_defconfig
+++ b/configs/imx6dl_mamoj_defconfig
@@ -11,6 +11,7 @@ 
CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_BOUNCE_BUFFER=y
 CONFIG_SPL_OS_BOOT=y
+CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_CRC32_VERIFY=y
 CONFIG_CMD_MEMTEST=y
 CONFIG_CMD_DFU=y
diff --git a/configs/imx6q_icore_nand_defconfig 
b/configs/imx6q_icore_nand_defconfig
index 1e26f7a8c9..58c4ccc66c 100644
--- a/configs/imx6q_icore_nand_defconfig
+++ b/configs/imx6q_icore_nand_defconfig
@@ -13,6 +13,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
diff --git a/configs/imx6q_logic_defconfig b/configs/imx6q_logic_defconfig
index 385efcec4e..33f9c3b19d 100644
--- a/configs/imx6q_logic_defconfig
+++ b/configs/imx6q_logic_defconfig
@@ -19,6 +19,7 @@ CONFIG_SYS_CONSOLE_OVERWRITE_ROUTINE=y
 CONFIG_BOUNCE_BUFFER=y
 CONFIG_SPL_RAW_IMAGE_SUPPORT=y
 CONFIG_SPL_SEPARATE_BSS=y
+CONFIG_SPL_MMC_SUPPORT=y
 # CONFIG_TPL_BANNER_PRINT is not set
 # CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
 CONFIG_SPL_DMA_SUPPORT=y
diff --git a/configs/imx6qdl_icore_mipi_defconfig 
b/configs/imx6qdl_icore_mipi_defconfig
index 7a0e5169b6..8b30115b37 100644
--- a/configs/imx6qdl_icore_mipi_defconfig
+++ b/configs/imx6qdl_icore_mipi_defconfig
@@ -17,6 +17,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
diff --git a/configs/imx6qdl_icore_mmc_defconfig 
b/configs/imx6qdl_icore_mmc_defconfig
index 223f732207..8b8b382bf9 100644
--- a/configs/imx6qdl_icore_mmc_defconfig
+++ b/configs/imx6qdl_icore_mmc_defconfig
@@ -24,6 +24,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
diff --git a/configs/imx6qdl_icore_nand_defconfig 
b/configs/imx6qdl_icore_nand_defconfig
index 8702426561..5dfd276270 100644
--- a/configs/imx6qdl_icore_nand_defconfig
+++ b/configs/imx6qdl_icore_nand_defconfig
@@ -12,6 +12,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
diff --git a/configs/imx6qdl_icore_rqs_defconfig 
b/configs/imx6qdl_icore_rqs_defconfig
index a4766063ca..a56196b68a 100644
--- a/configs/imx6qdl_icore_rqs_defconfig
+++ b/configs/imx6qdl_icore_rqs_defconfig
@@ -14,6 +14,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
diff --git a/configs/imx6ul_geam_mmc_defconfig 
b/configs/imx6ul_geam_mmc_defconfig
index 8a7f41b53c..4c328fac2f 100644
--- a/configs/imx6ul_geam_mmc_defconfig
+++ b/configs/imx6ul_geam_mmc_defconfig
@@ -14,6 +14,7 @@ CONFIG_NR_DRAM_BANKS=1
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_SPL_MMC_SUPPORT=y
 CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
diff --git a/configs/imx6ul_geam_nand_defconfig 
b/configs/imx6ul_geam_nand_defconfig
index bf61f768ab..22b559b9ed 100644
--- a/configs/

[U-Boot] [PATCH 2/2] Kconfig: Add BUILD_TARGET for i.MX6 images

2019-05-16 Thread Shyam Saini
Right now, i.MX6 supports single image variants like u-boot-with-spl.imx
and u-boot-nand-with-spl.imx for MMC and NAND boots respectively.

But, it requires an explicit argument passing to 'make' to build
these images, like 'make  u-boot-with-spl.imx'

This patch would fix this by selecting BUILD_TARGET images with
respective SPL variants MMC, NAND. This would eventually help us to get
rid of explicit argument passing to 'make' to build these single images.

Tested-by: Shyam Saini 
Signed-off-by: Jagan Teki 
Signed-off-by: Shyam Saini 
---
 Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Kconfig b/Kconfig
index 7a5491bd67..05d1a19b1d 100644
--- a/Kconfig
+++ b/Kconfig
@@ -243,6 +243,8 @@ config BUILD_TARGET
default "u-boot.itb" if SPL_LOAD_FIT && ARCH_SUNXI
default "u-boot.kwb" if KIRKWOOD
default "u-boot-with-spl.bin" if ARCH_AT91 && SPL_NAND_SUPPORT
+   default "u-boot-with-spl.imx" if ARCH_MX6 && SPL_MMC_SUPPORT
+   default "u-boot-with-nand-spl.imx" if ARCH_MX6 && SPL_NAND_SUPPORT
help
  Some SoCs need special image types (e.g. U-Boot binary
  with a special header) as build targets. By defining
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] board_r: move initr_serial to be called before initr_watchdog

2019-05-16 Thread Stefan Roese

On 16.05.19 08:48, Weijie Gao wrote:

The initr_watchdog is currently placed before initr_serial. The
initr_watchdog calls printf and printf finally calls ops->putc of a serial
driver.

However, gd->cur_serial_dev points to a udevice allocated in board_f. The
gd->cur_serial_dev->driver->ops->putc points the the code region before
relocation.

Some serial drivers call WATCHDOG_RESET() in ops->putc. When DM is enabled
for watchdog, watchdog_reset() is called. watchdog_reset() calls get_timer
to get current timer.

On some platforms the timer driver is also a DM driver. initr_watchdog is
placed right after initr_dm, which means the timer driver hasn't been
initialized. So dm_timer_init() is called. To create a new udevice, calloc
is called.

However start from ops->putc, u-boot execution flow is redirected into the
memory region before relocation (board_f). In board_f, dlmalloc hasn't
been initialized. The call to calloc will fail, and this will cause DM to
print out an error message, and it will call printf again, causing
recursive error outputs.

This patch places initr_serial before initr_watchdog to solve this issue.

Cc: Stefan Roese 
Reviewed-by: Ryder Lee 
Signed-off-by: Weijie Gao 
---
  common/board_r.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/common/board_r.c b/common/board_r.c
index 150e8cd424..a298146c2b 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -678,6 +678,7 @@ static init_fnc_t init_sequence_r[] = {
  #ifdef CONFIG_DM
initr_dm,
  #endif
+   initr_serial,
  #if defined(CONFIG_WDT)
initr_watchdog,
  #endif
@@ -698,7 +699,6 @@ static init_fnc_t init_sequence_r[] = {
efi_memory_init,
  #endif
stdio_init_tables,
-   initr_serial,
initr_announce,


I'm not 100% sure, if moving initr_serial before stdio_init_tables and
other functions is safe. Perhaps its better to just move initr_watchdog
down a bit, perhaps after initr_announce?

What do you think?

Thanks,
Stefan

BTW: Somehow your Cc'ing me did not reach me directly. I only found the
patch on the list.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/3] watchdog: mtk_wdt: fix timeout calculation

2019-05-16 Thread Stefan Roese

On 16.05.19 08:49, Weijie Gao wrote:

U-Boot passes timeout in milliseconds for ops->start. However the driver
treats this value as seconds. This will cause an overflow on writing wdt
register.

This patch divides the timeout by 1000 before writing to wdt register.

Reviewed-by: Ryder Lee 
Signed-off-by: Weijie Gao 


Reviewed-by: Stefan Roese 

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: mediatek: remove arch_misc_init

2019-05-16 Thread Stefan Roese

On 16.05.19 08:49, Weijie Gao wrote:

The watchdog of mediatek chips is enabled by bootrom before u-boot is
running. Previously we choose to enable the wdt driver only to disable the
watchdog hardware.

Now wdt service is enabled by default. The function arch_misc_init which is
only used to disable wdt is no longer needed.

Reviewed-by: Ryder Lee 
Signed-off-by: Weijie Gao 


I must have missed this WDT init in my cleanup series.

Reviewed-by: Stefan Roese 

Thanks,
Stefan
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate

2019-05-16 Thread Lukasz Majewski
On Thu, 9 May 2019 01:13:15 +
Peng Fan  wrote:

> > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > clk_fixed_rate
> > 
> > On Wed, 8 May 2019 07:45:39 +
> > Peng Fan  wrote:
> >   
> > > > -Original Message-
> > > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > > Sent: 2019年5月8日 15:40
> > > > To: Peng Fan 
> > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx
> > > > ; s...@chromium.org;  
> > ja...@amarulasolutions.com;  
> > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com
> > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > clk_fixed_rate
> > > >
> > > > On Wed, 8 May 2019 06:51:46 +
> > > > Peng Fan  wrote:
> > > >  
> > > > > > -Original Message-
> > > > > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > > > > Sent: 2019年5月8日 14:46
> > > > > > To: Peng Fan 
> > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx
> > > > > > ; s...@chromium.org;  
> > > > ja...@amarulasolutions.com;  
> > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com
> > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > > > clk_fixed_rate
> > > > > >
> > > > > > On Tue, 7 May 2019 13:27:45 + Peng Fan
> > > > > >  wrote:
> > > > > >  
> > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > > > > > clk_fixed_rate
> > > > > > > >
> > > > > > > > Hi Peng,
> > > > > > > >  
> > > > > > > > > Export the structure for others to use.
> > > > > > > > >
> > > > > > > > > Signed-off-by: Peng Fan 
> > > > > > > > > ---
> > > > > > > > >  drivers/clk/clk_fixed_rate.c | 8 +---
> > > > > > > > > include/linux/clk-provider.h | 7 +++
> > > > > > > > >  2 files changed, 8 insertions(+), 7 deletions(-)
> > > > > > > > >
> > > > > > > > > diff --git a/drivers/clk/clk_fixed_rate.c
> > > > > > > > > b/drivers/clk/clk_fixed_rate.c index
> > > > > > > > > 089f060a23..069e643fbc 100644 ---
> > > > > > > > > a/drivers/clk/clk_fixed_rate.c +++
> > > > > > > > > b/drivers/clk/clk_fixed_rate.c @@ -6,13 +6,7 @@
> > > > > > > > > #include   #include 
> > > > > > > > > #include  -
> > > > > > > > > -struct clk_fixed_rate {
> > > > > > > > > - struct clk clk;
> > > > > > > > > - unsigned long fixed_rate;
> > > > > > > > > -};
> > > > > > > > > -
> > > > > > > > > -#define to_clk_fixed_rate(dev)   ((struct
> > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +#include
> > > > > > > > > 
> > > > > > > > >
> > > > > > > > >  static ulong clk_fixed_rate_get_rate(struct clk
> > > > > > > > > *clk) { diff --git a/include/linux/clk-provider.h
> > > > > > > > > b/include/linux/clk-provider.h index
> > > > > > > > > 3ed0db86d2..b2bed768b6 100644 ---
> > > > > > > > > a/include/linux/clk-provider.h +++
> > > > > > > > > b/include/linux/clk-provider.h @@ -112,6 +112,13 @@
> > > > > > > > > struct clk_fixed_factor {  #define
> > > > > > > > > to_clk_fixed_factor(_clk) container_of(_clk, struct
> > > > > > > > > clk_fixed_factor,\ clk)
> > > > > > > > >
> > > > > > > > > +struct clk_fixed_rate {
> > > > > > > > > + struct clk clk;
> > > > > > > > > + unsigned long fixed_rate; };  
> > > > > > > >
> > > > > > > > I think that this struct shall stay where it was.
> > > > > > > > Moreover, the clk-provider.h is not the API to be used
> > > > > > > > by other parts of the clock API.
> > > > > > > >
> > > > > > > > The clk_fixed_rate shall be accessed via get_rate()
> > > > > > > > only and in IMX6Q it is available in early SPL (parsed
> > > > > > > > from dts /clocks property
> > > > > > > > - the 24MHz OSC)  
> > > > > > > > > +
> > > > > > > > > +#define to_clk_fixed_rate(dev)   ((struct
> > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +  int
> > > > > > > > > clk_register(struct clk *clk, const char *drv_name,
> > > > > > > > >ulong drv_data, const char *name,
> > > > > > > > >const char *parent_name);  
> > > > > > > >
> > > > > > > > Please explain why iMX8MM needs such global export?  
> > > > > > >
> > > > > > > In clk-imx8mm.c, first configure ARM clk to osc24M fixed
> > > > > > > clk to change pll clock.
> > > > > > > +   /* Configure ARM to osc24M */
> > > > > > > +   clk_get_by_id(IMX8MM_CLK_A53_SRC, &clkp);
> > > > > > > +   uclass_get_device_by_name(UCLASS_CLK,
> > > > > > > "clock-osc-24m",  
> > > > > > &devp);  
> > > > > > > +   clkp1 = &to_clk_fixed_rate(devp)->clk;
> > > > > > > +   clk_set_parent(clkp, clkp1);  
> > > > > >
> > > > > > This code looks a bit strange to me. Why imx8mm sets parent
> > > > > > here?  
> > > > >
> > > > > The A53 clk could not change on the fly. There is a mux here,
> > > > > one is PLL, one is OSC, And there are others. If we want to
> > > > > change the pll clock which is currently being used by A53, we
> > > > > need first switch the A53 clk to source from OSC, then change
> > > > > pll clock, then switch A53 clk back to PLL.  
> > > >
> > > > The above description looks lik

Re: [U-Boot] [PATCH 1/3] board_r: move initr_serial to be called before initr_watchdog

2019-05-16 Thread Weijie Gao
On Thu, 2019-05-16 at 10:21 +0200, Stefan Roese wrote:
> On 16.05.19 08:48, Weijie Gao wrote:
> > The initr_watchdog is currently placed before initr_serial. The
> > initr_watchdog calls printf and printf finally calls ops->putc of a serial
> > driver.
> > 
> > However, gd->cur_serial_dev points to a udevice allocated in board_f. The
> > gd->cur_serial_dev->driver->ops->putc points the the code region before
> > relocation.
> > 
> > Some serial drivers call WATCHDOG_RESET() in ops->putc. When DM is enabled
> > for watchdog, watchdog_reset() is called. watchdog_reset() calls get_timer
> > to get current timer.
> > 
> > On some platforms the timer driver is also a DM driver. initr_watchdog is
> > placed right after initr_dm, which means the timer driver hasn't been
> > initialized. So dm_timer_init() is called. To create a new udevice, calloc
> > is called.
> > 
> > However start from ops->putc, u-boot execution flow is redirected into the
> > memory region before relocation (board_f). In board_f, dlmalloc hasn't
> > been initialized. The call to calloc will fail, and this will cause DM to
> > print out an error message, and it will call printf again, causing
> > recursive error outputs.
> > 
> > This patch places initr_serial before initr_watchdog to solve this issue.
> > 
> > Cc: Stefan Roese 
> > Reviewed-by: Ryder Lee 
> > Signed-off-by: Weijie Gao 
> > ---
> >   common/board_r.c | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/common/board_r.c b/common/board_r.c
> > index 150e8cd424..a298146c2b 100644
> > --- a/common/board_r.c
> > +++ b/common/board_r.c
> > @@ -678,6 +678,7 @@ static init_fnc_t init_sequence_r[] = {
> >   #ifdef CONFIG_DM
> > initr_dm,
> >   #endif
> > +   initr_serial,
> >   #if defined(CONFIG_WDT)
> > initr_watchdog,
> >   #endif
> > @@ -698,7 +699,6 @@ static init_fnc_t init_sequence_r[] = {
> > efi_memory_init,
> >   #endif
> > stdio_init_tables,
> > -   initr_serial,
> > initr_announce,
> 
> I'm not 100% sure, if moving initr_serial before stdio_init_tables and
> other functions is safe. Perhaps its better to just move initr_watchdog
> down a bit, perhaps after initr_announce?
> 
> What do you think?
> 
> Thanks,
> Stefan
> 
> BTW: Somehow your Cc'ing me did not reach me directly. I only found the
> patch on the list.

I'll change it to move initr_watchdog only.

My company's mail server reported delivery failure every time I Cc'ed
you and some others. I have no idea.

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 0/4] riscv: sifive: fu540: Make GEM 10/100 Mbps work

2019-05-16 Thread Bin Meng
At present the GEM ethernet on SiFive Unleashed board can only work
in 1000 Mbps mode. With a 10/100 Mbps connection it just fails to do
any network communication.

This adds a new GEMGXL clock driver to adjust the clock settings per
the connection speed so that 10/100 Mbps works.


Bin Meng (4):
  clk: sifive: Add clock driver for GEMGXL MGMT
  dm: net: macb: Update macb_linkspd_cb() signature
  dm: net: macb: Implement link speed change callback
  sifive: fu540: Enable GEMGXL MGMT driver

 board/sifive/fu540/Kconfig   |  1 +
 drivers/clk/sifive/Kconfig   |  7 +
 drivers/clk/sifive/Makefile  |  2 ++
 drivers/clk/sifive/gemgxl-mgmt.c | 60 
 drivers/net/macb.c   | 48 +++-
 5 files changed, 117 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/sifive/gemgxl-mgmt.c

-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/4] clk: sifive: Add clock driver for GEMGXL MGMT

2019-05-16 Thread Bin Meng
This adds a clock driver to support the GEMGXL management IP block
found in FU540 SoCs to control GEM TX clock operation mode for
10/100/1000 Mbps.

Signed-off-by: Bin Meng 
---

 drivers/clk/sifive/Kconfig   |  7 +
 drivers/clk/sifive/Makefile  |  2 ++
 drivers/clk/sifive/gemgxl-mgmt.c | 60 
 3 files changed, 69 insertions(+)
 create mode 100644 drivers/clk/sifive/gemgxl-mgmt.c

diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
index 81fc9f8..644881b 100644
--- a/drivers/clk/sifive/Kconfig
+++ b/drivers/clk/sifive/Kconfig
@@ -17,3 +17,10 @@ config CLK_SIFIVE_FU540_PRCI
  Supports the Power Reset Clock interface (PRCI) IP block found in
  FU540 SoCs.  If this kernel is meant to run on a SiFive FU540 SoC,
  enable this driver.
+
+config CLK_SIFIVE_GEMGXL_MGMT
+   bool "GEMGXL management for SiFive FU540 SoCs"
+   depends on CLK_SIFIVE
+   help
+ Supports the GEMGXL management IP block found in FU540 SoCs to
+ control GEM TX clock operation mode for 10/100/1000 Mbps.
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index 1155e07..f8263e7 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -3,3 +3,5 @@
 obj-$(CONFIG_CLK_ANALOGBITS_WRPLL_CLN28HPC)+= wrpll-cln28hpc.o
 
 obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
+
+obj-$(CONFIG_CLK_SIFIVE_GEMGXL_MGMT)   += gemgxl-mgmt.o
diff --git a/drivers/clk/sifive/gemgxl-mgmt.c b/drivers/clk/sifive/gemgxl-mgmt.c
new file mode 100644
index 000..d989989
--- /dev/null
+++ b/drivers/clk/sifive/gemgxl-mgmt.c
@@ -0,0 +1,60 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019, Bin Meng 
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+struct gemgxl_mgmt_regs {
+   __u32 tx_clk_sel;
+};
+
+struct gemgxl_mgmt_platdata {
+   struct gemgxl_mgmt_regs *regs;
+};
+
+static int gemgxl_mgmt_ofdata_to_platdata(struct udevice *dev)
+{
+   struct gemgxl_mgmt_platdata *plat = dev_get_platdata(dev);
+
+   plat->regs = (struct gemgxl_mgmt_regs *)dev_read_addr(dev);
+
+   return 0;
+}
+
+static ulong gemgxl_mgmt_set_rate(struct clk *clk, ulong rate)
+{
+   struct gemgxl_mgmt_platdata *plat = dev_get_platdata(clk->dev);
+
+   /*
+* GEMGXL TX clock operation mode:
+*
+* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
+* and output clock on GMII output signal GTX_CLK
+* 1 = MII mode. Use MII input signal TX_CLK in TX logic
+*/
+   writel(rate != 12500, &plat->regs->tx_clk_sel);
+
+   return 0;
+}
+
+const struct clk_ops gemgxl_mgmt_ops = {
+   .set_rate = gemgxl_mgmt_set_rate,
+};
+
+static const struct udevice_id gemgxl_mgmt_match[] = {
+   { .compatible = "sifive,cadencegemgxlmgmt0", },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(gemgxl_mgmt) = {
+   .name = "gemgxl-mgmt",
+   .id = UCLASS_CLK,
+   .of_match = gemgxl_mgmt_match,
+   .ofdata_to_platdata = gemgxl_mgmt_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct gemgxl_mgmt_platdata),
+   .ops = &gemgxl_mgmt_ops,
+};
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 3/4] dm: net: macb: Implement link speed change callback

2019-05-16 Thread Bin Meng
At present the link speed change callback is a nop. According to
macb device tree bindings, an optional "tx_clk" is used to clock
the ethernet controller's TX_CLK under different link speed.

In 10/100 MII mode, transmit logic must be clocked from a free
running clock generated by the external PHY. In gigabit GMII mode,
the controller, not the external PHY, must generate the 125 MHz
transmit clock towards the PHY.

Signed-off-by: Bin Meng 
---

 drivers/net/macb.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index b7f404e..7d86fa1 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -497,6 +497,32 @@ static int macb_phy_find(struct macb_device *macb, const 
char *name)
 #ifdef CONFIG_DM_ETH
 int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
 {
+#ifdef CONFIG_CLK
+   struct clk tx_clk;
+   ulong rate;
+   int ret;
+
+   ret = clk_get_by_name(dev, "tx_clk", &tx_clk);
+   if (ret)
+   return 0;
+
+   switch (speed) {
+   case _10BASET:
+   rate = 250;
+   break;
+   case _100BASET:
+   rate = 2500;
+   break;
+   case _1000BASET:
+   default:
+   rate = 12500;
+   break;
+   }
+
+   if (tx_clk.dev)
+   clk_set_rate(&tx_clk, rate);
+#endif
+
return 0;
 }
 #else
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/4] dm: net: macb: Update macb_linkspd_cb() signature

2019-05-16 Thread Bin Meng
This updates DM version macb_linkspd_cb() signature for future
expansion, eg: adding an implementation for link speed changes.

Signed-off-by: Bin Meng 
---

 drivers/net/macb.c | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 7261416..b7f404e 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -488,15 +488,23 @@ static int macb_phy_find(struct macb_device *macb, const 
char *name)
 
 /**
  * macb_linkspd_cb - Linkspeed change callback function
- * @regs:  Base Register of MACB devices
+ * @dev/@regs: MACB udevice (DM version) or
+ * Base Register of MACB devices (non-DM version)
  * @speed: Linkspeed
  * Returns 0 when operation success and negative errno number
  * when operation failed.
  */
+#ifdef CONFIG_DM_ETH
+int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
+{
+   return 0;
+}
+#else
 int __weak macb_linkspd_cb(void *regs, unsigned int speed)
 {
return 0;
 }
+#endif
 
 #ifdef CONFIG_DM_ETH
 static int macb_phy_init(struct udevice *dev, const char *name)
@@ -589,7 +597,11 @@ static int macb_phy_init(struct macb_device *macb, const 
char *name)
 
macb_writel(macb, NCFGR, ncfgr);
 
+#ifdef CONFIG_DM_ETH
+   ret = macb_linkspd_cb(dev, _1000BASET);
+#else
ret = macb_linkspd_cb(macb->regs, _1000BASET);
+#endif
if (ret)
return ret;
 
@@ -614,9 +626,17 @@ static int macb_phy_init(struct macb_device *macb, const 
char *name)
ncfgr &= ~(MACB_BIT(SPD) | MACB_BIT(FD) | GEM_BIT(GBE));
if (speed) {
ncfgr |= MACB_BIT(SPD);
+#ifdef CONFIG_DM_ETH
+   ret = macb_linkspd_cb(dev, _100BASET);
+#else
ret = macb_linkspd_cb(macb->regs, _100BASET);
+#endif
} else {
+#ifdef CONFIG_DM_ETH
+   ret = macb_linkspd_cb(dev, _10BASET);
+#else
ret = macb_linkspd_cb(macb->regs, _10BASET);
+#endif
}
 
if (ret)
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 4/4] sifive: fu540: Enable GEMGXL MGMT driver

2019-05-16 Thread Bin Meng
Enable the new GEMGXL MGMT driver so that GEM 10/100 Mbps works now.

Signed-off-by: Bin Meng 

---

 board/sifive/fu540/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index f464379..8eb5e30 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -28,6 +28,7 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply CMD_PING
imply CLK_SIFIVE
imply CLK_SIFIVE_FU540_PRCI
+   imply CLK_SIFIVE_GEMGXL_MGMT
imply DOS_PARTITION
imply EFI_PARTITION
imply IP_DYN
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 1/3] board_r: move initr_watchdog to be called after initr_serial

2019-05-16 Thread Weijie Gao
The initr_watchdog is currently placed before initr_serial. The
initr_watchdog calls printf and printf finally calls ops->putc of a serial
driver.

However, gd->cur_serial_dev points to a udevice allocated in board_f. The
gd->cur_serial_dev->driver->ops->putc points the the code region before
relocation.

Some serial drivers call WATCHDOG_RESET() in ops->putc. When DM is enabled
for watchdog, watchdog_reset() is called. watchdog_reset() calls get_timer
to get current timer.

On some platforms the timer driver is also a DM driver. initr_watchdog is
placed right after initr_dm, which means the timer driver hasn't been
initialized. So dm_timer_init() is called. To create a new udevice, calloc
is called.

However start from ops->putc, u-boot execution flow is redirected into the
memory region before relocation (board_f). In board_f, dlmalloc hasn't
been initialized. The call to calloc will fail, and this will cause DM to
print out an error message, and it will call printf again, causing
recursive error outputs.

This patch places initr_watchdog after initr_serial to solve this issue.

Cc: Stefan Roese 
Reviewed-by: Ryder Lee 
Signed-off-by: Weijie Gao 
---
Changes since v1: move initr_watchdog instead of initr_serial
---
 common/board_r.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/board_r.c b/common/board_r.c
index 150e8cd424..df24021f2c 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -678,9 +678,6 @@ static init_fnc_t init_sequence_r[] = {
 #ifdef CONFIG_DM
initr_dm,
 #endif
-#if defined(CONFIG_WDT)
-   initr_watchdog,
-#endif
 #if defined(CONFIG_ARM) || defined(CONFIG_NDS32) || defined(CONFIG_RISCV) || \
defined(CONFIG_SANDBOX)
board_init, /* Setup chipselects */
@@ -700,6 +697,9 @@ static init_fnc_t init_sequence_r[] = {
stdio_init_tables,
initr_serial,
initr_announce,
+#if defined(CONFIG_WDT)
+   initr_watchdog,
+#endif
INIT_FUNC_WATCHDOG_RESET
 #ifdef CONFIG_NEEDS_MANUAL_RELOC
initr_manual_reloc_cmdtable,
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 2/3] watchdog: mtk_wdt: fix timeout calculation

2019-05-16 Thread Weijie Gao
U-Boot passes timeout in milliseconds for ops->start. However the driver
treats this value as seconds. This will cause an overflow on writing wdt
register.

This patch divides the timeout by 1000 before writing to wdt register.

Reviewed-by: Stefan Roese 
Reviewed-by: Ryder Lee 
Signed-off-by: Weijie Gao 
---
Changes since v1: none
---
 drivers/watchdog/mtk_wdt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
index 0b501733f2..19e3fde968 100644
--- a/drivers/watchdog/mtk_wdt.c
+++ b/drivers/watchdog/mtk_wdt.c
@@ -78,7 +78,7 @@ static void mtk_wdt_set_timeout(struct udevice *dev, unsigned 
int timeout)
 * One bit is the value of 512 ticks
 * The clock has 32 KHz
 */
-   timeout = WDT_LENGTH_TIMEOUT(timeout << 6) | WDT_LENGTH_KEY;
+   timeout = WDT_LENGTH_TIMEOUT((timeout << 6) / 1000) | WDT_LENGTH_KEY;
writel(timeout, priv->base + MTK_WDT_LENGTH);
 
mtk_wdt_reset(dev);
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 3/3] arm: mediatek: remove arch_misc_init

2019-05-16 Thread Weijie Gao
The watchdog of mediatek chips is enabled by bootrom before u-boot is
running. Previously we choose to enable the wdt driver only to disable the
watchdog hardware.

Now wdt service is enabled by default. The function arch_misc_init which is
only used to disable wdt is no longer needed.

Reviewed-by: Stefan Roese 
Reviewed-by: Ryder Lee 
Signed-off-by: Weijie Gao 
---
Changes since v1: none
---
 arch/arm/mach-mediatek/Kconfig |  3 ---
 arch/arm/mach-mediatek/cpu.c   | 12 
 2 files changed, 15 deletions(-)

diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig
index b5e91d4a7d..60aef15f15 100644
--- a/arch/arm/mach-mediatek/Kconfig
+++ b/arch/arm/mach-mediatek/Kconfig
@@ -12,7 +12,6 @@ choice
 config TARGET_MT7623
bool "MediaTek MT7623 SoC"
select CPU_V7A
-   select ARCH_MISC_INIT
help
  The MediaTek MT7623 is a ARM-based SoC with a quad-core Cortex-A7
  including NEON and GPU, Mali-450 graphics, several DDR3 options,
@@ -25,7 +24,6 @@ config TARGET_MT7629
bool "MediaTek MT7629 SoC"
select CPU_V7A
select SPL
-   select ARCH_MISC_INIT
help
  The MediaTek MT7629 is a ARM-based SoC with a dual-core Cortex-A7
  including DDR3, crypto engine, 3x3 11n/ac Wi-Fi, Gigabit Ethernet,
@@ -34,7 +32,6 @@ config TARGET_MT7629
 config TARGET_MT8516
bool "MediaTek MT8516 SoC"
select ARM64
-   select ARCH_MISC_INIT
help
  The MediaTek MT8516 is a ARM64-based SoC with a quad-core Cortex-A35.
  including UART, SPI, USB2.0 and OTG, SD and MMC cards, NAND, PWM,
diff --git a/arch/arm/mach-mediatek/cpu.c b/arch/arm/mach-mediatek/cpu.c
index b37e299b74..1923c9e527 100644
--- a/arch/arm/mach-mediatek/cpu.c
+++ b/arch/arm/mach-mediatek/cpu.c
@@ -8,18 +8,6 @@
 #include 
 #include 
 
-int arch_misc_init(void)
-{
-   struct udevice *wdt;
-   int ret;
-
-   ret = uclass_first_device_err(UCLASS_WDT, &wdt);
-   if (!ret)
-   wdt_stop(wdt);
-
-   return 0;
-}
-
 int arch_cpu_init(void)
 {
icache_enable();
-- 
2.18.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] sunxi: Pine64: DTS: enable USB PHY 0 for HCI0

2019-05-16 Thread Andre Przywara
On Thu, 16 May 2019 08:15:23 +0100
Peter Robinson  wrote:

Hi Peter,

> On Thu, May 16, 2019 at 1:47 AM Andre Przywara  wrote:
> >
> > The first USB controller on the A64 SoC shares a PHY with the OTG
> > controller. Reportedly to avoid problems with the VBUS regulator under
> > Linux, we don't link OHCI0/EHCI0 to the USB PHY in the A64 .dtsi file.
> >
> > However on boards which can't use peripheral mode (because they have an
> > always-on VBUS supply on an USB-A socket) we don't need this trick, and
> > can properly connect host controller 0 to the PHY 0.
> >
> > Amend the Pine64 and SoPine/LTS .dts to reflect this. This enables the
> > upper USB port in U-Boot on those boards.
> >
> > Signed-off-by: Andre Przywara 
> > ---
> >  arch/arm/dts/sun50i-a64-pine64.dts   | 5 -
> >  arch/arm/dts/sun50i-a64-sopine-baseboard.dts | 5 -
> >  2 files changed, 8 insertions(+), 2 deletions(-)  
> 
> Are these changes going to go upstream to Linux too? If not it's
> probably best to add it to a u-boot.dtsi so the changes don't get lost
> when the DT files are re-synced from Linux. Same with the similar
> patches for the H6 boards.

Yes, but I need to wait for the end of the merge window before I can post
anything there. So I just posted this here to get some input on this.
And we need to resync the DTs anyway, I will post something next week,
probably syncing with 5.2-rc1.

Actually I believe the changes belong into the .dtsi, as this is how the
hardware is wired. But I need to do more tests, as Chen-Yu hinted that
this might break USB-OTG on boards with a proper micro-B socket (like the
Banana-Pi M64), due to the HCI driver always enabling VBUS. So far I
failed to use host mode on that board, but I will keep digging.

Cheers,
Andre.

> > diff --git a/arch/arm/dts/sun50i-a64-pine64.dts 
> > b/arch/arm/dts/sun50i-a64-pine64.dts
> > index c077b6c1f4..523a4d5bff 100644
> > --- a/arch/arm/dts/sun50i-a64-pine64.dts
> > +++ b/arch/arm/dts/sun50i-a64-pine64.dts
> > @@ -80,6 +80,8 @@
> >  };
> >
> >  &ehci0 {
> > +   phys = <&usbphy 0>;
> > +   phy-names = "usb";
> > status = "okay";
> >  };
> >
> > @@ -136,6 +138,8 @@
> >  };
> >
> >  &ohci0 {
> > +   phys = <&usbphy 0>;
> > +   phy-names = "usb";
> > status = "okay";
> >  };
> >
> > @@ -301,7 +305,6 @@
> >
> >  &usb_otg {
> > dr_mode = "host";
> > -   status = "okay";
> >  };
> >
> >  &usbphy {
> > diff --git a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts 
> > b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> > index 53fcc9098d..1986897177 100644
> > --- a/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> > +++ b/arch/arm/dts/sun50i-a64-sopine-baseboard.dts
> > @@ -85,6 +85,8 @@
> >  };
> >
> >  &ehci0 {
> > +   phys = <&usbphy 0>;
> > +   phy-names = "usb";
> > status = "okay";
> >  };
> >
> > @@ -131,6 +133,8 @@
> >  };
> >
> >  &ohci0 {
> > +   phys = <&usbphy 0>;
> > +   phy-names = "usb";
> > status = "okay";
> >  };
> >
> > @@ -172,7 +176,6 @@
> >
> >  &usb_otg {
> > dr_mode = "host";
> > -   status = "okay";
> >  };
> >
> >  &usbphy {
> > --
> > 2.14.5
> >
> > ___
> > 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] [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate

2019-05-16 Thread Peng Fan
> Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate
> 
> On Thu, 9 May 2019 01:13:15 +
> Peng Fan  wrote:
> 
> > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > clk_fixed_rate
> > >
> > > On Wed, 8 May 2019 07:45:39 +
> > > Peng Fan  wrote:
> > >
> > > > > -Original Message-
> > > > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > > > Sent: 2019年5月8日 15:40
> > > > > To: Peng Fan 
> > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx
> > > > > ; s...@chromium.org;
> > > ja...@amarulasolutions.com;
> > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com
> > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > > clk_fixed_rate
> > > > >
> > > > > On Wed, 8 May 2019 06:51:46 + Peng Fan 
> > > > > wrote:
> > > > >
> > > > > > > -Original Message-
> > > > > > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > > > > > Sent: 2019年5月8日 14:46
> > > > > > > To: Peng Fan 
> > > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx
> > > > > > > ; s...@chromium.org;
> > > > > ja...@amarulasolutions.com;
> > > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com
> > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > > > > clk_fixed_rate
> > > > > > >
> > > > > > > On Tue, 7 May 2019 13:27:45 + Peng Fan
> > > > > > >  wrote:
> > > > > > >
> > > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > > > > > > clk_fixed_rate
> > > > > > > > >
> > > > > > > > > Hi Peng,
> > > > > > > > >
> > > > > > > > > > Export the structure for others to use.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Peng Fan 
> > > > > > > > > > ---
> > > > > > > > > >  drivers/clk/clk_fixed_rate.c | 8 +---
> > > > > > > > > > include/linux/clk-provider.h | 7 +++
> > > > > > > > > >  2 files changed, 8 insertions(+), 7 deletions(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/drivers/clk/clk_fixed_rate.c
> > > > > > > > > > b/drivers/clk/clk_fixed_rate.c index
> > > > > > > > > > 089f060a23..069e643fbc 100644 ---
> > > > > > > > > > a/drivers/clk/clk_fixed_rate.c +++
> > > > > > > > > > b/drivers/clk/clk_fixed_rate.c @@ -6,13 +6,7 @@
> > > > > > > > > > #include   #include  #include
> > > > > > > > > >  - -struct clk_fixed_rate {
> > > > > > > > > > -   struct clk clk;
> > > > > > > > > > -   unsigned long fixed_rate;
> > > > > > > > > > -};
> > > > > > > > > > -
> > > > > > > > > > -#define to_clk_fixed_rate(dev) ((struct
> > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +#include
> > > > > > > > > > 
> > > > > > > > > >
> > > > > > > > > >  static ulong clk_fixed_rate_get_rate(struct clk
> > > > > > > > > > *clk) { diff --git a/include/linux/clk-provider.h
> > > > > > > > > > b/include/linux/clk-provider.h index
> > > > > > > > > > 3ed0db86d2..b2bed768b6 100644 ---
> > > > > > > > > > a/include/linux/clk-provider.h +++
> > > > > > > > > > b/include/linux/clk-provider.h @@ -112,6 +112,13 @@
> > > > > > > > > > struct clk_fixed_factor {  #define
> > > > > > > > > > to_clk_fixed_factor(_clk) container_of(_clk, struct
> > > > > > > > > > clk_fixed_factor,\ clk)
> > > > > > > > > >
> > > > > > > > > > +struct clk_fixed_rate {
> > > > > > > > > > +   struct clk clk;
> > > > > > > > > > +   unsigned long fixed_rate; };
> > > > > > > > >
> > > > > > > > > I think that this struct shall stay where it was.
> > > > > > > > > Moreover, the clk-provider.h is not the API to be used
> > > > > > > > > by other parts of the clock API.
> > > > > > > > >
> > > > > > > > > The clk_fixed_rate shall be accessed via get_rate() only
> > > > > > > > > and in IMX6Q it is available in early SPL (parsed from
> > > > > > > > > dts /clocks property
> > > > > > > > > - the 24MHz OSC)
> > > > > > > > > > +
> > > > > > > > > > +#define to_clk_fixed_rate(dev) ((struct
> > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +  int
> > > > > > > > > > clk_register(struct clk *clk, const char *drv_name,
> > > > > > > > > >  ulong drv_data, const char *name,
> > > > > > > > > >  const char *parent_name);
> > > > > > > > >
> > > > > > > > > Please explain why iMX8MM needs such global export?
> > > > > > > >
> > > > > > > > In clk-imx8mm.c, first configure ARM clk to osc24M fixed
> > > > > > > > clk to change pll clock.
> > > > > > > > +   /* Configure ARM to osc24M */
> > > > > > > > +   clk_get_by_id(IMX8MM_CLK_A53_SRC, &clkp);
> > > > > > > > +   uclass_get_device_by_name(UCLASS_CLK,
> > > > > > > > "clock-osc-24m",
> > > > > > > &devp);
> > > > > > > > +   clkp1 = &to_clk_fixed_rate(devp)->clk;
> > > > > > > > +   clk_set_parent(clkp, clkp1);
> > > > > > >
> > > > > > > This code looks a bit strange to me. Why imx8mm sets parent
> > > > > > > here?
> > > > > >
> > > > > > The A53 clk could not change on the fly. There is a mux here,
> > > > > > one is PLL, one is OSC, And there are others. If we want to
> > > > > > chan

Re: [U-Boot] [linux-sunxi] [PATCH 2/6] sunxi: gpio: Enable support for H6 pin controller

2019-05-16 Thread Andre Przywara
On Thu, 16 May 2019 10:34:38 +0800
Icenowy Zheng  wrote:

Hi Icenowy,

thanks for having a look!

> 于 2019年5月16日 GMT+08:00 上午9:26:29, Andre Przywara  写到:
> >The Allwinner H6 pin controller is not really special, at least not
> >when it comes to normal GPIO operation.
> >
> >Add the H6 compatible strings to the list of recognised strings, to
> >make GPIOs work for H6 boards.
> >
> >Signed-off-by: Andre Przywara 
> >---
> > drivers/gpio/sunxi_gpio.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> >diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
> >index cbed8d42b7..780c39962a 100644
> >--- a/drivers/gpio/sunxi_gpio.c
> >+++ b/drivers/gpio/sunxi_gpio.c
> >@@ -354,12 +354,14 @@ static const struct udevice_id sunxi_gpio_ids[] =
> >{
> > ID("allwinner,sun8i-v3s-pinctrl",   a_all),
> > ID("allwinner,sun9i-a80-pinctrl",   a_all),
> > ID("allwinner,sun50i-a64-pinctrl",  a_all),
> >+ID("allwinner,sun50i-h6-pinctrl",   a_all),
> > ID("allwinner,sun6i-a31-r-pinctrl", l_2),
> > ID("allwinner,sun8i-a23-r-pinctrl", l_1),
> > ID("allwinner,sun8i-a83t-r-pinctrl",l_1),
> > ID("allwinner,sun8i-h3-r-pinctrl",  l_1),
> > ID("allwinner,sun9i-a80-r-pinctrl", l_3),
> > ID("allwinner,sun50i-a64-r-pinctrl",l_1),
> >+ID("allwinner,sun50i-h6-r-pinctrl", l_1),  
> 
> Should be l_2 because H6 has PM bank.

Oh, indeed, I totally missed that. Thanks for pointing this out!

Cheers,
Andre
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 0/9] arm: mvebu: clearfog: support boot from SATA disk

2019-05-16 Thread Baruch Siach
This series enables support for boot from SATA on the SolidRun Clearfog
platform.

Patches 1-3 are preparations for the addition of loading U-Boot main image from
raw SATA device. They make spl sata code independent of board macros and
specific kconfig symbols.

Patch 4 adds to SPL generic support for loading U-Boot from a raw SATA device.
This code is modeled after the similar support for MMC devices.

Patches 5-6 are mvebu specific. Patch 5 fixes SATA access from SPL. Patch 6
adds the SATA boot option at the SoC level.

Patches 7-9 are the board specific update that enable SATA boot in Clearfog,
and document the offset setting requirement.

Baruch Siach (9):
  spl: sata: add default partition and image name
  spl: sata: fix build with DM_SCSI
  spl: sata: don't force FS_FAT support
  spl: sata: support U-Boot load from raw sata disk
  arm: mvebu: fix ahci mbus config in SPL
  arm: mvebu: add support for boot from SATA
  arm: mvebu: clearfog: enable SATA in SPL
  arm: mvebu: clearfog: set U-Boot offset for SATA boot
  arm: mvebu: clearfog: document boot from SATA

 arch/arm/dts/armada-388-clearfog-u-boot.dtsi |  8 
 arch/arm/mach-mvebu/Kconfig  |  5 ++
 arch/arm/mach-mvebu/Makefile |  3 ++
 arch/arm/mach-mvebu/cpu.c|  4 ++
 arch/arm/mach-mvebu/include/mach/soc.h   |  2 +
 arch/arm/mach-mvebu/spl.c|  5 ++
 board/solidrun/clearfog/README   |  6 +++
 common/spl/Kconfig   | 14 ++
 common/spl/spl_sata.c| 49 ++--
 include/configs/clearfog.h   |  2 +-
 10 files changed, 94 insertions(+), 4 deletions(-)

-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/9] spl: sata: add default partition and image name

2019-05-16 Thread Baruch Siach
Add sensible defaults for the FAT partition selection and the main
U-Boot image file name. This allows spl_sata to build when the board
headers does not select them explicitly.

Signed-off-by: Baruch Siach 
---
 common/spl/spl_sata.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/common/spl/spl_sata.c b/common/spl/spl_sata.c
index adfce1d527f6..b08efc841903 100644
--- a/common/spl/spl_sata.c
+++ b/common/spl/spl_sata.c
@@ -17,6 +17,14 @@
 #include 
 #include 
 
+#ifndef CONFIG_SYS_SATA_FAT_BOOT_PARTITION
+#define CONFIG_SYS_SATA_FAT_BOOT_PARTITION 1
+#endif
+
+#ifndef CONFIG_SPL_FS_LOAD_PAYLOAD_NAME
+#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"
+#endif
+
 static int spl_sata_load_image(struct spl_image_info *spl_image,
   struct spl_boot_device *bootdev)
 {
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 5/9] arm: mvebu: fix ahci mbus config in SPL

2019-05-16 Thread Baruch Siach
SPL does not initialize mbus_dram_info. Don't change the ahci mbus
settings of the ROM. This allows the ahci to work in SPL.

Signed-off-by: Baruch Siach 
---
 arch/arm/mach-mvebu/cpu.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-mvebu/cpu.c b/arch/arm/mach-mvebu/cpu.c
index f09e7b10e935..f4b7a4fa8010 100644
--- a/arch/arm/mach-mvebu/cpu.c
+++ b/arch/arm/mach-mvebu/cpu.c
@@ -542,6 +542,10 @@ static void ahci_mvebu_mbus_config(void __iomem *base)
const struct mbus_dram_target_info *dram;
int i;
 
+   /* mbus is not initialized in SPL; keep the ROM settings */
+   if (IS_ENABLED(CONFIG_SPL_BUILD))
+   return;
+
dram = mvebu_mbus_dram_info();
 
for (i = 0; i < 4; i++) {
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 2/9] spl: sata: fix build with DM_SCSI

2019-05-16 Thread Baruch Siach
The init_sata() routine is only present when DM_SCSI is not enabled.
Don't call init_sata() when DM_SCSI is enabled. The code will fall back
to scsi_scan() in this case.

Signed-off-by: Baruch Siach 
---
 common/spl/spl_sata.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_sata.c b/common/spl/spl_sata.c
index b08efc841903..2fb46108a512 100644
--- a/common/spl/spl_sata.c
+++ b/common/spl/spl_sata.c
@@ -28,10 +28,12 @@
 static int spl_sata_load_image(struct spl_image_info *spl_image,
   struct spl_boot_device *bootdev)
 {
-   int err;
+   int err = 0;
struct blk_desc *stor_dev;
 
+#if !defined(CONFIG_DM_SCSI) && !defined(CONFIG_AHCI)
err = init_sata(CONFIG_SPL_SATA_BOOT_DEVICE);
+#endif
if (err) {
 #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
printf("spl: sata init failed: err - %d\n", err);
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 3/9] spl: sata: don't force FS_FAT support

2019-05-16 Thread Baruch Siach
Allow the code to build when FS_FAT is not enabled, and thus
spl_load_image_fat() is not provided.

A subsequent patch should add alternative raw access U-Boot main image
load method.

Signed-off-by: Baruch Siach 
---
 common/spl/spl_sata.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_sata.c b/common/spl/spl_sata.c
index 2fb46108a512..f0af9f38d19f 100644
--- a/common/spl/spl_sata.c
+++ b/common/spl/spl_sata.c
@@ -53,9 +53,13 @@ static int spl_sata_load_image(struct spl_image_info 
*spl_image,
  CONFIG_SYS_SATA_FAT_BOOT_PARTITION))
 #endif
{
-   err = spl_load_image_fat(spl_image, stor_dev,
+   err = -ENOSYS;
+
+   if (IS_ENABLED(CONFIG_SPL_FS_FAT)) {
+   err = spl_load_image_fat(spl_image, stor_dev,
CONFIG_SYS_SATA_FAT_BOOT_PARTITION,
-   CONFIG_SPL_FS_LOAD_PAYLOAD_NAME);
+   CONFIG_SPL_FS_LOAD_PAYLOAD_NAME);
+   }
}
if (err) {
puts("Error loading sata device\n");
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 4/9] spl: sata: support U-Boot load from raw sata disk

2019-05-16 Thread Baruch Siach
Support load of the U-Boot image from raw SATA disk sector. This is
equivalent to load from MMC raw sector.

Signed-off-by: Baruch Siach 
---
 common/spl/Kconfig| 14 ++
 common/spl/spl_sata.c | 29 +
 2 files changed, 43 insertions(+)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index c7cd34449a52..a90c6adbf68b 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -733,6 +733,20 @@ config SPL_SATA_SUPPORT
  expense and power consumption. This enables loading from SATA
  using a configured device.
 
+config SPL_SATA_RAW_U_BOOT_USE_SECTOR
+   bool "SATA raw mode: by sector"
+   depends on SPL_SATA_SUPPORT
+   help
+ Use sector number for specifying U-Boot location on SATA disk in
+ raw mode.
+
+config SPL_SATA_RAW_U_BOOT_SECTOR
+   hex "Sector on the SATA disk to load U-Boot from"
+   depends on SPL_SATA_RAW_U_BOOT_USE_SECTOR
+   help
+ Sector on the SATA disk to load U-Boot from, when the SATA disk is 
being
+ used in raw mode. Units: SATA disk sectors (1 sector = 512 bytes).
+
 config SPL_SERIAL_SUPPORT
bool "Support serial"
select SPL_PRINTF
diff --git a/common/spl/spl_sata.c b/common/spl/spl_sata.c
index f0af9f38d19f..3ad8a5a58035 100644
--- a/common/spl/spl_sata.c
+++ b/common/spl/spl_sata.c
@@ -25,6 +25,32 @@
 #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img"
 #endif
 
+static int spl_sata_load_image_raw(struct spl_image_info *spl_image,
+   struct blk_desc *stor_dev, unsigned long sector)
+{
+   struct image_header *header;
+   unsigned long count;
+   u32 image_size_sectors;
+   int ret;
+
+   header = spl_get_load_buffer(-sizeof(*header), stor_dev->blksz);
+   count = blk_dread(stor_dev, sector, 1, header);
+   if (count == 0)
+   return -EIO;
+
+   ret = spl_parse_image_header(spl_image, header);
+   if (ret)
+   return ret;
+
+   image_size_sectors = DIV_ROUND_UP(spl_image->size, stor_dev->blksz);
+   count = blk_dread(stor_dev, sector, image_size_sectors,
+   (void *)spl_image->load_addr);
+   if (count != image_size_sectors)
+   return -EIO;
+
+   return 0;
+}
+
 static int spl_sata_load_image(struct spl_image_info *spl_image,
   struct spl_boot_device *bootdev)
 {
@@ -59,6 +85,9 @@ static int spl_sata_load_image(struct spl_image_info 
*spl_image,
err = spl_load_image_fat(spl_image, stor_dev,
CONFIG_SYS_SATA_FAT_BOOT_PARTITION,
CONFIG_SPL_FS_LOAD_PAYLOAD_NAME);
+   } else if (IS_ENABLED(CONFIG_SPL_SATA_RAW_U_BOOT_USE_SECTOR)) {
+   err = spl_sata_load_image_raw(spl_image, stor_dev,
+   CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR);
}
}
if (err) {
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 6/9] arm: mvebu: add support for boot from SATA

2019-05-16 Thread Baruch Siach
Add the required Kconfig and macro definitions to allow boot from SATA
on Armada 38x systems.

Signed-off-by: Baruch Siach 
---
 arch/arm/mach-mvebu/Kconfig| 5 +
 arch/arm/mach-mvebu/Makefile   | 3 +++
 arch/arm/mach-mvebu/include/mach/soc.h | 2 ++
 arch/arm/mach-mvebu/spl.c  | 5 +
 4 files changed, 15 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 495c48e6c749..fdd39685b75d 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -239,6 +239,11 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
bool "SDIO/MMC card"
select SPL_LIBDISK_SUPPORT
 
+config MVEBU_SPL_BOOT_DEVICE_SATA
+   bool "SATA"
+   select SPL_SATA_SUPPORT
+   select SPL_LIBDISK_SUPPORT
+
 config MVEBU_SPL_BOOT_DEVICE_UART
bool "UART"
 
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 02d3ce27ee74..8228a17972f9 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -37,6 +37,9 @@ endif
 ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
KWB_CFG_BOOT_FROM=sdio
 endif
+ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),)
+   KWB_CFG_BOOT_FROM=sata
+endif
 ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),)
KWB_CFG_BOOT_FROM=uart
 endif
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
b/arch/arm/mach-mvebu/include/mach/soc.h
index f666ee24243b..acb9257c90fe 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -159,7 +159,9 @@
 #define BOOT_DEV_SEL_MASK  (0x3f << BOOT_DEV_SEL_OFFS)
 
 #define BOOT_FROM_NAND 0x0A
+#define BOOT_FROM_SATA 0x22
 #define BOOT_FROM_UART 0x28
+#define BOOT_FROM_SATA_ALT 0x2A
 #define BOOT_FROM_UART_ALT 0x3f
 #define BOOT_FROM_SPI  0x32
 #define BOOT_FROM_MMC  0x30
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 530b98c1aa31..d54de5195624 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -59,6 +59,11 @@ static u32 get_boot_device(void)
case BOOT_FROM_UART_ALT:
 #endif
return BOOT_DEVICE_UART;
+#ifdef BOOT_FROM_SATA
+   case BOOT_FROM_SATA:
+   case BOOT_FROM_SATA_ALT:
+   return BOOT_DEVICE_SATA;
+#endif
case BOOT_FROM_SPI:
default:
return BOOT_DEVICE_SPI;
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 8/9] arm: mvebu: clearfog: set U-Boot offset for SATA boot

2019-05-16 Thread Baruch Siach
See the offset of U-Boot in raw SATA disk to the same value as the MMC
offset. That is 0x140 sectors from the beginning of the SPL, which is
0x141 sectors from the beginning of the device (after the MBR sector).

Signed-off-by: Baruch Siach 
---
 include/configs/clearfog.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/clearfog.h b/include/configs/clearfog.h
index 4198ff051177..15c402b542e9 100644
--- a/include/configs/clearfog.h
+++ b/include/configs/clearfog.h
@@ -85,7 +85,7 @@
 /* SPL related SPI defines */
 #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x2
 #define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_SPI_U_BOOT_OFFS
-#elif defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC)
+#elif defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC) || 
defined(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA)
 /* SPL related MMC defines */
 #define CONFIG_SYS_MMC_U_BOOT_OFFS (160 << 10)
 #define CONFIG_SYS_U_BOOT_OFFS CONFIG_SYS_MMC_U_BOOT_OFFS
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 7/9] ARM: dts: clearfog: enable SATA in SPL

2019-05-16 Thread Baruch Siach
Enable SATA peripherals in SPL to allow boot from SATA.

Signed-off-by: Baruch Siach 
---
 arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi 
b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
index a12694e17103..cf6c08881b18 100644
--- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
+++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
@@ -11,3 +11,11 @@
 &sdhci {
u-boot,dm-spl;
 };
+
+&ahci0 {
+   u-boot,dm-spl;
+};
+
+&ahci1 {
+   u-boot,dm-spl;
+};
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 7/9] arm: mvebu: clearfog: enable SATA in SPL

2019-05-16 Thread Baruch Siach
Enable SATA peripherals in SPL to allow boot from SATA.

Signed-off-by: Baruch Siach 
---
 arch/arm/dts/armada-388-clearfog-u-boot.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi 
b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
index a12694e17103..cf6c08881b18 100644
--- a/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
+++ b/arch/arm/dts/armada-388-clearfog-u-boot.dtsi
@@ -11,3 +11,11 @@
 &sdhci {
u-boot,dm-spl;
 };
+
+&ahci0 {
+   u-boot,dm-spl;
+};
+
+&ahci1 {
+   u-boot,dm-spl;
+};
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 6/9] ARM: mvebu: add support for boot from SATA

2019-05-16 Thread Baruch Siach
Add the required Kconfig and macro definitions to allow boot from SATA
on Armada 38x systems.

Signed-off-by: Baruch Siach 
---
 arch/arm/mach-mvebu/Kconfig| 5 +
 arch/arm/mach-mvebu/Makefile   | 3 +++
 arch/arm/mach-mvebu/include/mach/soc.h | 2 ++
 arch/arm/mach-mvebu/spl.c  | 5 +
 4 files changed, 15 insertions(+)

diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
index 495c48e6c749..fdd39685b75d 100644
--- a/arch/arm/mach-mvebu/Kconfig
+++ b/arch/arm/mach-mvebu/Kconfig
@@ -239,6 +239,11 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
bool "SDIO/MMC card"
select SPL_LIBDISK_SUPPORT
 
+config MVEBU_SPL_BOOT_DEVICE_SATA
+   bool "SATA"
+   select SPL_SATA_SUPPORT
+   select SPL_LIBDISK_SUPPORT
+
 config MVEBU_SPL_BOOT_DEVICE_UART
bool "UART"
 
diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
index 02d3ce27ee74..8228a17972f9 100644
--- a/arch/arm/mach-mvebu/Makefile
+++ b/arch/arm/mach-mvebu/Makefile
@@ -37,6 +37,9 @@ endif
 ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
KWB_CFG_BOOT_FROM=sdio
 endif
+ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),)
+   KWB_CFG_BOOT_FROM=sata
+endif
 ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),)
KWB_CFG_BOOT_FROM=uart
 endif
diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
b/arch/arm/mach-mvebu/include/mach/soc.h
index f666ee24243b..acb9257c90fe 100644
--- a/arch/arm/mach-mvebu/include/mach/soc.h
+++ b/arch/arm/mach-mvebu/include/mach/soc.h
@@ -159,7 +159,9 @@
 #define BOOT_DEV_SEL_MASK  (0x3f << BOOT_DEV_SEL_OFFS)
 
 #define BOOT_FROM_NAND 0x0A
+#define BOOT_FROM_SATA 0x22
 #define BOOT_FROM_UART 0x28
+#define BOOT_FROM_SATA_ALT 0x2A
 #define BOOT_FROM_UART_ALT 0x3f
 #define BOOT_FROM_SPI  0x32
 #define BOOT_FROM_MMC  0x30
diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
index 530b98c1aa31..d54de5195624 100644
--- a/arch/arm/mach-mvebu/spl.c
+++ b/arch/arm/mach-mvebu/spl.c
@@ -59,6 +59,11 @@ static u32 get_boot_device(void)
case BOOT_FROM_UART_ALT:
 #endif
return BOOT_DEVICE_UART;
+#ifdef BOOT_FROM_SATA
+   case BOOT_FROM_SATA:
+   case BOOT_FROM_SATA_ALT:
+   return BOOT_DEVICE_SATA;
+#endif
case BOOT_FROM_SPI:
default:
return BOOT_DEVICE_SPI;
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [i.MX8MM+CCF 11/41] clk: fixed_rate: export clk_fixed_rate

2019-05-16 Thread Lukasz Majewski
On Thu, 16 May 2019 09:58:17 +
Peng Fan  wrote:

> > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > clk_fixed_rate
> > 
> > On Thu, 9 May 2019 01:13:15 +
> > Peng Fan  wrote:
> >   
> > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > clk_fixed_rate
> > > >
> > > > On Wed, 8 May 2019 07:45:39 +
> > > > Peng Fan  wrote:
> > > >  
> > > > > > -Original Message-
> > > > > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > > > > Sent: 2019年5月8日 15:40
> > > > > > To: Peng Fan 
> > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx
> > > > > > ; s...@chromium.org;  
> > > > ja...@amarulasolutions.com;  
> > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com
> > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > > > clk_fixed_rate
> > > > > >
> > > > > > On Wed, 8 May 2019 06:51:46 + Peng Fan
> > > > > >  wrote:
> > > > > >  
> > > > > > > > -Original Message-
> > > > > > > > From: Lukasz Majewski [mailto:lu...@denx.de]
> > > > > > > > Sent: 2019年5月8日 14:46
> > > > > > > > To: Peng Fan 
> > > > > > > > Cc: sba...@denx.de; feste...@gmail.com; dl-uboot-imx
> > > > > > > > ; s...@chromium.org;  
> > > > > > ja...@amarulasolutions.com;  
> > > > > > > > s...@denx.de; u-boot@lists.denx.de; tr...@konsulko.com
> > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate: export
> > > > > > > > clk_fixed_rate
> > > > > > > >
> > > > > > > > On Tue, 7 May 2019 13:27:45 + Peng Fan
> > > > > > > >  wrote:
> > > > > > > >  
> > > > > > > > > > Subject: Re: [i.MX8MM+CCF 11/41] clk: fixed_rate:
> > > > > > > > > > export clk_fixed_rate
> > > > > > > > > >
> > > > > > > > > > Hi Peng,
> > > > > > > > > >  
> > > > > > > > > > > Export the structure for others to use.
> > > > > > > > > > >
> > > > > > > > > > > Signed-off-by: Peng Fan 
> > > > > > > > > > > ---
> > > > > > > > > > >  drivers/clk/clk_fixed_rate.c | 8 +---
> > > > > > > > > > > include/linux/clk-provider.h | 7 +++
> > > > > > > > > > >  2 files changed, 8 insertions(+), 7 deletions(-)
> > > > > > > > > > >
> > > > > > > > > > > diff --git a/drivers/clk/clk_fixed_rate.c
> > > > > > > > > > > b/drivers/clk/clk_fixed_rate.c index
> > > > > > > > > > > 089f060a23..069e643fbc 100644 ---
> > > > > > > > > > > a/drivers/clk/clk_fixed_rate.c +++
> > > > > > > > > > > b/drivers/clk/clk_fixed_rate.c @@ -6,13 +6,7 @@
> > > > > > > > > > > #include   #include 
> > > > > > > > > > > #include  - -struct clk_fixed_rate {
> > > > > > > > > > > - struct clk clk;
> > > > > > > > > > > - unsigned long fixed_rate;
> > > > > > > > > > > -};
> > > > > > > > > > > -
> > > > > > > > > > > -#define to_clk_fixed_rate(dev)   ((struct
> > > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +#include
> > > > > > > > > > > 
> > > > > > > > > > >
> > > > > > > > > > >  static ulong clk_fixed_rate_get_rate(struct clk
> > > > > > > > > > > *clk) { diff --git a/include/linux/clk-provider.h
> > > > > > > > > > > b/include/linux/clk-provider.h index
> > > > > > > > > > > 3ed0db86d2..b2bed768b6 100644 ---
> > > > > > > > > > > a/include/linux/clk-provider.h +++
> > > > > > > > > > > b/include/linux/clk-provider.h @@ -112,6 +112,13
> > > > > > > > > > > @@ struct clk_fixed_factor {  #define
> > > > > > > > > > > to_clk_fixed_factor(_clk) container_of(_clk,
> > > > > > > > > > > struct clk_fixed_factor,\ clk)
> > > > > > > > > > >
> > > > > > > > > > > +struct clk_fixed_rate {
> > > > > > > > > > > + struct clk clk;
> > > > > > > > > > > + unsigned long fixed_rate; };  
> > > > > > > > > >
> > > > > > > > > > I think that this struct shall stay where it was.
> > > > > > > > > > Moreover, the clk-provider.h is not the API to be
> > > > > > > > > > used by other parts of the clock API.
> > > > > > > > > >
> > > > > > > > > > The clk_fixed_rate shall be accessed via get_rate()
> > > > > > > > > > only and in IMX6Q it is available in early SPL
> > > > > > > > > > (parsed from dts /clocks property
> > > > > > > > > > - the 24MHz OSC)  
> > > > > > > > > > > +
> > > > > > > > > > > +#define to_clk_fixed_rate(dev)   ((struct
> > > > > > > > > > > clk_fixed_rate *)dev_get_platdata(dev)) +  int
> > > > > > > > > > > clk_register(struct clk *clk, const char
> > > > > > > > > > > *drv_name, ulong drv_data, const char *name,
> > > > > > > > > > >const char *parent_name);  
> > > > > > > > > >
> > > > > > > > > > Please explain why iMX8MM needs such global
> > > > > > > > > > export?  
> > > > > > > > >
> > > > > > > > > In clk-imx8mm.c, first configure ARM clk to osc24M
> > > > > > > > > fixed clk to change pll clock.
> > > > > > > > > +   /* Configure ARM to osc24M */
> > > > > > > > > +   clk_get_by_id(IMX8MM_CLK_A53_SRC, &clkp);
> > > > > > > > > +   uclass_get_device_by_name(UCLASS_CLK,
> > > > > > > > > "clock-osc-24m",  
> > > > > > > > &devp);  
> > > > > > > > > +   clkp1 = &to_clk_fixed_rate(devp)->clk;
> > > > > > > > > +   clk_set_parent(cl

[U-Boot] [PATCH 9/9] arm: mvebu: clearfog: document boot from SATA

2019-05-16 Thread Baruch Siach
Document the main U-Boot image offset when booting from SATA disk on the
Clearfog board.

Signed-off-by: Baruch Siach 
---
 board/solidrun/clearfog/README | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/board/solidrun/clearfog/README b/board/solidrun/clearfog/README
index 0b0e98de90a0..6171ce66f4f8 100644
--- a/board/solidrun/clearfog/README
+++ b/board/solidrun/clearfog/README
@@ -40,6 +40,12 @@ Install U-Boot on eMMC boot partition from Linux running on 
Clearfog:
 Note that the SD card is not accessible when the Clearfog SOM has eMMC.
 Consider initial boot from UART (see below).
 
+Install U-Boot on SATA:
+---
+
+When loading the main U-Boot image from raw SATA sector, set
+CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR to 0x141.
+
 Boot selection:
 ---
 
-- 
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 6/9] ARM: mvebu: add support for boot from SATA

2019-05-16 Thread Baruch Siach
Hi u-boot list, Stefan,

Please ignore this patch and the next. The patch series starts at the
0/9 cover letter.

Sorry for the spam.

baruch

On Thu, May 16 2019, Baruch Siach wrote:

> Add the required Kconfig and macro definitions to allow boot from SATA
> on Armada 38x systems.
>
> Signed-off-by: Baruch Siach 
> ---
>  arch/arm/mach-mvebu/Kconfig| 5 +
>  arch/arm/mach-mvebu/Makefile   | 3 +++
>  arch/arm/mach-mvebu/include/mach/soc.h | 2 ++
>  arch/arm/mach-mvebu/spl.c  | 5 +
>  4 files changed, 15 insertions(+)
>
> diff --git a/arch/arm/mach-mvebu/Kconfig b/arch/arm/mach-mvebu/Kconfig
> index 495c48e6c749..fdd39685b75d 100644
> --- a/arch/arm/mach-mvebu/Kconfig
> +++ b/arch/arm/mach-mvebu/Kconfig
> @@ -239,6 +239,11 @@ config MVEBU_SPL_BOOT_DEVICE_MMC
>   bool "SDIO/MMC card"
>   select SPL_LIBDISK_SUPPORT
>  
> +config MVEBU_SPL_BOOT_DEVICE_SATA
> + bool "SATA"
> + select SPL_SATA_SUPPORT
> + select SPL_LIBDISK_SUPPORT
> +
>  config MVEBU_SPL_BOOT_DEVICE_UART
>   bool "UART"
>  
> diff --git a/arch/arm/mach-mvebu/Makefile b/arch/arm/mach-mvebu/Makefile
> index 02d3ce27ee74..8228a17972f9 100644
> --- a/arch/arm/mach-mvebu/Makefile
> +++ b/arch/arm/mach-mvebu/Makefile
> @@ -37,6 +37,9 @@ endif
>  ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_MMC),)
>   KWB_CFG_BOOT_FROM=sdio
>  endif
> +ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_SATA),)
> + KWB_CFG_BOOT_FROM=sata
> +endif
>  ifneq ($(CONFIG_MVEBU_SPL_BOOT_DEVICE_UART),)
>   KWB_CFG_BOOT_FROM=uart
>  endif
> diff --git a/arch/arm/mach-mvebu/include/mach/soc.h 
> b/arch/arm/mach-mvebu/include/mach/soc.h
> index f666ee24243b..acb9257c90fe 100644
> --- a/arch/arm/mach-mvebu/include/mach/soc.h
> +++ b/arch/arm/mach-mvebu/include/mach/soc.h
> @@ -159,7 +159,9 @@
>  #define BOOT_DEV_SEL_MASK(0x3f << BOOT_DEV_SEL_OFFS)
>  
>  #define BOOT_FROM_NAND   0x0A
> +#define BOOT_FROM_SATA   0x22
>  #define BOOT_FROM_UART   0x28
> +#define BOOT_FROM_SATA_ALT   0x2A
>  #define BOOT_FROM_UART_ALT   0x3f
>  #define BOOT_FROM_SPI0x32
>  #define BOOT_FROM_MMC0x30
> diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> index 530b98c1aa31..d54de5195624 100644
> --- a/arch/arm/mach-mvebu/spl.c
> +++ b/arch/arm/mach-mvebu/spl.c
> @@ -59,6 +59,11 @@ static u32 get_boot_device(void)
>   case BOOT_FROM_UART_ALT:
>  #endif
>   return BOOT_DEVICE_UART;
> +#ifdef BOOT_FROM_SATA
> + case BOOT_FROM_SATA:
> + case BOOT_FROM_SATA_ALT:
> + return BOOT_DEVICE_SATA;
> +#endif
>   case BOOT_FROM_SPI:
>   default:
>   return BOOT_DEVICE_SPI;


-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RSA in U-Boot

2019-05-16 Thread Sughosh Ganu
On Sat, 27 Apr 2019 at 12:03, Heinrich Schuchardt 
wrote:

> On 4/27/19 7:31 AM, Paolo Bonzini wrote:
> >
>  I've done porting linux's pkcs7/x509 parsers and they work well
>  with my UEFI secure boot patch, but I'm still looking for other
> options
>  as well.
> 
>  * openssl
> Most of existing components linked to UEFI secure boot, including
> EDK2, shim and grub, reply on this library. Why not for U-Boot?
> The size of U-Boot UEFI code in U-Boot is already quite big, and
> so the size of openssl won't be a big issue.
>  * mbedTLS
> which is maintained by ARM and used with Zephyr, I guess it should
> have small footprint. But it currently lacks pkcs7 parser.
> 
>  Any thoughts?
> >>>
> >>>
> >>> Paolo, Laszlo, Ard, if you could write a new secure boot implementation
> >>> today, which of the options above would you pick and why so? :)
> >>
> >> Difficult question. Ideally you'd want a library where three aspects
> met:
> >>
> >> - widely used (so that there is a diverse community that's interested in
> >> vulnerabilities, and fixing them too)
> >>
> >> - easy to cross-compile for your free-standing environment (optimally
> >> the upstream project would support being cross-compiled and packaged
> >> stand-alone, for that free-standing environment)
> >>
> >> - cares about API stability
> >>
> >> OpenSSL is very widely used...
> >> ...and that's where we can stop in the list :)
> >
> > It's also license-incompatible with U-Boot's GPLv2 I think.  I guess
> > grub can use it because GPLv3 and Apache v2 can be combined just fine.
> > Reusing Linux's code seems like the best match.
> >
> > Paolo
> >
>
> You could have a look at GnuTLS available at
> https://gitlab.com/gnutls/gnutls/ .
>
> PKCS7 is supported, cf.
> https://www.gnutls.org/manual/html_node/PKCS-7-API.html
>
> There seem to be four main contributors to GnuTLS adding two patches a day:
>
> https://github.com/gnutls/gnutls/graphs/contributors?from=2018-04-28&to=2019-04-27&type=a


There is LibreSSL as well which is a fork of openssl. Guess that too should
be fine. What would be the more preferred solution here. The relevant bits
can be imported from the kernel code into u-boot, or there can be a
solution with linking of ssl/tls library with u-boot. Which would be the
more preferred solution. It'd be great if the maintainers can comment on
this. Thanks.

-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] please pull u-boot-samsung master

2019-05-16 Thread Minkyu Kang
Dear Tom,

The following changes since commit 5b4b680cfe29a67171ccbe439c66374cb31faca3:

  Prepare v2019.07-rc2 (2019-05-15 15:58:48 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-samsung master

for you to fetch changes up to f4b2ab97ed37ea6b202aaa951d31dab9187e3720:

  configs: arndale: Use appropriate driver for Asix AX88760 (2019-05-16 
16:11:42 +0900)


Krzysztof Kozlowski (3):
  arm: exynos: arndale: Remove unused CONFIG_POWER and CONFIG_POWER_I2C
  arm: exynos: arndale: Remove unused CONFIG_DM_I2C_COMPAT
  configs: arndale: Use appropriate driver for Asix AX88760

 configs/arndale_defconfig | 3 +--
 include/configs/arndale.h | 8 
 2 files changed, 1 insertion(+), 10 deletions(-)

-- 
Thanks,
Minkyu Kang.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RSA in U-Boot

2019-05-16 Thread Wolfgang Denk
Dear Sughosh Ganu,

In message  
you wrote:
> 
> There is LibreSSL as well which is a fork of openssl. Guess that too should
> be fine. What would be the more preferred solution here. The relevant bits
> can be imported from the kernel code into u-boot, or there can be a
> solution with linking of ssl/tls library with u-boot. Which would be the
> more preferred solution. It'd be great if the maintainers can comment on
> this. Thanks.

I'd go for the Linux kernel code.  A number of issues we have here
(cross compiling, code size, license compatibility, long term
maintenance efforts) have already been considered there, so why
should we duplicate all these efforts?  And if we did, is there any
clear benefit from doing this?

Just my 0,02€

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Never underestimate the power of human stupidity  when  it  comes  to
using technology they don't understand.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RSA in U-Boot

2019-05-16 Thread Ilias Apalodimas
On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
Hello Wolfgang, 

Thanks for taking the time with this
> > 
> > There is LibreSSL as well which is a fork of openssl. Guess that too should
> > be fine. What would be the more preferred solution here. The relevant bits
> > can be imported from the kernel code into u-boot, or there can be a
> > solution with linking of ssl/tls library with u-boot. Which would be the
> > more preferred solution. It'd be great if the maintainers can comment on
> > this. Thanks.
> 
> I'd go for the Linux kernel code.  A number of issues we have here
> (cross compiling, code size, license compatibility, long term
> maintenance efforts) have already been considered there, so why
> should we duplicate all these efforts?  And if we did, is there any
> clear benefit from doing this?
Well someone has to port the linux code in U-Boot and maintain it though.

The LibreSSL proposal was made with some of these in mind. 
We don't expect the licence to ever change (which is compatible) 
and it's being maintained. 
I am not sure on the portability status, but i think it runs on all major
architectures.

I'd imagine this lifts the maintenance burden from U-Boot. On the other 
hand we'll rely on an external library to offer the functionality. 

Regards
/Ilias
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCHv2 2/2] pci: layerscape: Add the workaround for errata A-009460

2019-05-16 Thread Xiaowei Bao
From: Xiaowei Bao 

The VF_BARn_REG register's Prefetchable and Type bit fields
are overwritten by a write to VF's BAR Mask register.
workaround: Before writing to the VF_BARn_MASK_REG register,
write 0b to the PCIE_MISC_CONTROL_1_OFF register.

Signed-off-by: Xiaowei Bao 
---
v2:
 - Add the NXP copyright.

 drivers/pci/pcie_layerscape.c |9 +
 drivers/pci/pcie_layerscape.h |1 +
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index 8f5ebda..25c5a0c 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -446,6 +446,15 @@ static void ls_pcie_setup_ep(struct ls_pcie *pcie)
if (PCI_EXT_CAP_ID(sriov) == PCI_EXT_CAP_ID_SRIOV) {
pcie->sriov_flag = 1;
for (pf = 0; pf < PCIE_PF_NUM; pf++) {
+   /*
+* The VF_BARn_REG register's Prefetchable and Type bit
+* fields are overwritten by a write to VF's BAR Mask
+* register. Before writing to the VF_BARn_MASK_REG
+* register, write 0b to the PCIE_MISC_CONTROL_1_OFF
+* register.
+*/
+   writel(0, pcie->dbi + PCIE_MISC_CONTROL_1_OFF);
+
if (pcie->cfg2_flag) {
for (vf = 0; vf <= PCIE_VF_NUM; vf++) {
ctrl_writel(pcie,
diff --git a/drivers/pci/pcie_layerscape.h b/drivers/pci/pcie_layerscape.h
index eb910ba..c6f1cb2 100644
--- a/drivers/pci/pcie_layerscape.h
+++ b/drivers/pci/pcie_layerscape.h
@@ -94,6 +94,7 @@
 #define PCIE_BAR4_SIZE SZ_1M /* 1M */
 
 #define PCIE_SRIOV_VFBAR0  0x19C
+#define PCIE_MISC_CONTROL_1_OFF0x8BC
 #define PCIE_CTRL1_FUNC_NUM(pf)(pf << 20)
 
 #define PCIE_MASK_OFFSET(flag, pf) ((flag) ? 0 : (0x1000 + 0x2 * (pf)))
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCHv2 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode

2019-05-16 Thread Xiaowei Bao
From: Xiaowei Bao 

Signed-off-by: hongbo.wang 
Signed-off-by: Minghuan Lian 
Signed-off-by: Xiaowei Bao 
---
v2:
 - Add the NXP copyright and make the function readability.

 drivers/pci/pcie_layerscape.c |  117 +++--
 drivers/pci/pcie_layerscape.h |   19 +--
 2 files changed, 91 insertions(+), 45 deletions(-)

diff --git a/drivers/pci/pcie_layerscape.c b/drivers/pci/pcie_layerscape.c
index db1375a..8f5ebda 100644
--- a/drivers/pci/pcie_layerscape.c
+++ b/drivers/pci/pcie_layerscape.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright 2017 NXP
+ * Copyright 2017, 2019 NXP
  * Copyright 2014-2015 Freescale Semiconductor, Inc.
  * Layerscape PCIe driver
  */
@@ -105,13 +105,14 @@ static void ls_pcie_atu_outbound_set(struct ls_pcie 
*pcie, int idx, int type,
 }
 
 /* Use bar match mode and MEM type as default */
-static void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, int idx,
-int bar, u64 phys)
+static void ls_pcie_atu_inbound_set(struct ls_pcie *pcie, u32 pf, int idx,
+   int bar, u64 phys)
 {
dbi_writel(pcie, PCIE_ATU_REGION_INBOUND | idx, PCIE_ATU_VIEWPORT);
dbi_writel(pcie, (u32)phys, PCIE_ATU_LOWER_TARGET);
dbi_writel(pcie, phys >> 32, PCIE_ATU_UPPER_TARGET);
-   dbi_writel(pcie, PCIE_ATU_TYPE_MEM, PCIE_ATU_CR1);
+   dbi_writel(pcie, PCIE_ATU_TYPE_MEM | PCIE_CTRL1_FUNC_NUM(pf),
+  PCIE_ATU_CR1);
dbi_writel(pcie, PCIE_ATU_ENABLE | PCIE_ATU_BAR_MODE_ENABLE |
   PCIE_ATU_BAR_NUM(bar), PCIE_ATU_CR2);
 }
@@ -341,50 +342,61 @@ static void ls_pcie_setup_ctrl(struct ls_pcie *pcie)
ls_pcie_disable_bars(pcie);
 }
 
-static void ls_pcie_ep_setup_atu(struct ls_pcie *pcie)
+static void ls_pcie_ep_setup_atu(struct ls_pcie *pcie, u32 pf)
 {
-   u64 phys = CONFIG_SYS_PCI_EP_MEMORY_BASE;
+   pci_size_t atu_size = CONFIG_SYS_PCI_MEMORY_SIZE;
+   u64 phys = 0;
 
+   phys = CONFIG_SYS_PCI_EP_MEMORY_BASE + pf * SZ_2M;
+
+   phys = ALIGN(phys, PCIE_BAR0_SIZE);
/* ATU 0 : INBOUND : map BAR0 */
-   ls_pcie_atu_inbound_set(pcie, 0, 0, phys);
+   ls_pcie_atu_inbound_set(pcie, pf, 0 + pf * BAR_NUM, 0, phys);
/* ATU 1 : INBOUND : map BAR1 */
-   phys += PCIE_BAR1_SIZE;
-   ls_pcie_atu_inbound_set(pcie, 1, 1, phys);
+   phys = ALIGN(phys + PCIE_BAR0_SIZE, PCIE_BAR1_SIZE);
+   ls_pcie_atu_inbound_set(pcie, pf, 1 + pf * BAR_NUM, 1, phys);
/* ATU 2 : INBOUND : map BAR2 */
-   phys += PCIE_BAR2_SIZE;
-   ls_pcie_atu_inbound_set(pcie, 2, 2, phys);
-   /* ATU 3 : INBOUND : map BAR4 */
-   phys = CONFIG_SYS_PCI_EP_MEMORY_BASE + PCIE_BAR4_SIZE;
-   ls_pcie_atu_inbound_set(pcie, 3, 4, phys);
+   phys = ALIGN(phys + PCIE_BAR1_SIZE, PCIE_BAR2_SIZE);
+   ls_pcie_atu_inbound_set(pcie, pf, 2 + pf * BAR_NUM, 2, phys);
+   /* ATU 3 : INBOUND : map BAR2 */
+   phys = ALIGN(phys + PCIE_BAR2_SIZE, PCIE_BAR2_SIZE);
+   ls_pcie_atu_inbound_set(pcie, pf, 3 + pf * BAR_NUM, 4, phys);
 
/* ATU 0 : OUTBOUND : map MEM */
-   ls_pcie_atu_outbound_set(pcie, 0,
-PCIE_ATU_TYPE_MEM,
-pcie->cfg_res.start,
-0,
-CONFIG_SYS_PCI_MEMORY_SIZE);
+   ls_pcie_atu_outbound_set(pcie, PCIE_ATU_REGION_INDEX0,
+PCIE_ATU_TYPE_MEM, (u64)pcie->cfg_res.start,
+0, atu_size);
+
+   /* ATU 1 : OUTBOUND : map MEM */
+   ls_pcie_atu_outbound_set(pcie, PCIE_ATU_REGION_INDEX1,
+PCIE_ATU_TYPE_MEM, (u64)pcie->cfg_res.start
++ atu_size, atu_size, atu_size);
 }
 
 /* BAR0 and BAR1 are 32bit BAR2 and BAR4 are 64bit */
 static void ls_pcie_ep_setup_bar(void *bar_base, int bar, u32 size)
 {
+   u32 mask;
+
/* The least inbound window is 4KiB */
-   if (size < 4 * 1024)
-   return;
+   if (size < SZ_4K)
+   mask = 0;
+   else
+   mask = size - 1;
 
switch (bar) {
case 0:
-   writel(size - 1, bar_base + PCI_BASE_ADDRESS_0);
+   writel(mask, bar_base + PCI_BASE_ADDRESS_0);
break;
case 1:
-   writel(size - 1, bar_base + PCI_BASE_ADDRESS_1);
+   writel(mask, bar_base + PCI_BASE_ADDRESS_1);
break;
case 2:
-   writel(size - 1, bar_base + PCI_BASE_ADDRESS_2);
+   writel(mask, bar_base + PCI_BASE_ADDRESS_2);
writel(0, bar_base + PCI_BASE_ADDRESS_3);
break;
case 4:
-   writel(size - 1, bar_base + PCI_BASE_ADDRESS_4);
+   writel(mask, bar_base + PCI_BASE_ADDRESS_4);
writel(0, bar_base + PCI_BASE_ADDRESS_5);
break;
default:

Re: [U-Boot] RSA in U-Boot

2019-05-16 Thread Tom Rini
On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> Hello Wolfgang, 
> 
> Thanks for taking the time with this
> > > 
> > > There is LibreSSL as well which is a fork of openssl. Guess that too 
> > > should
> > > be fine. What would be the more preferred solution here. The relevant bits
> > > can be imported from the kernel code into u-boot, or there can be a
> > > solution with linking of ssl/tls library with u-boot. Which would be the
> > > more preferred solution. It'd be great if the maintainers can comment on
> > > this. Thanks.
> > 
> > I'd go for the Linux kernel code.  A number of issues we have here
> > (cross compiling, code size, license compatibility, long term
> > maintenance efforts) have already been considered there, so why
> > should we duplicate all these efforts?  And if we did, is there any
> > clear benefit from doing this?
> Well someone has to port the linux code in U-Boot and maintain it though.
> 
> The LibreSSL proposal was made with some of these in mind. 
> We don't expect the licence to ever change (which is compatible) 
> and it's being maintained. 
> I am not sure on the portability status, but i think it runs on all major
> architectures.
> 
> I'd imagine this lifts the maintenance burden from U-Boot. On the other 
> hand we'll rely on an external library to offer the functionality. 

I don't see how using LibreSSL instead of Linux kernel code would have a
lesser maintenance burden, sorry.  If anything, given the number of
parts of the code we have today that come from the Linux kernel, adding
one more to the "keep in sync, or at least port bugfixes" list is less
than "add a new external project to keep an eye on".

-- 
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] RSA in U-Boot

2019-05-16 Thread Ilias Apalodimas
Hi Tom,
> > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > Hello Wolfgang, 
> > 
> > Thanks for taking the time with this
> > > > 
> > > > There is LibreSSL as well which is a fork of openssl. Guess that too 
> > > > should
> > > > be fine. What would be the more preferred solution here. The relevant 
> > > > bits
> > > > can be imported from the kernel code into u-boot, or there can be a
> > > > solution with linking of ssl/tls library with u-boot. Which would be the
> > > > more preferred solution. It'd be great if the maintainers can comment on
> > > > this. Thanks.
> > > 
> > > I'd go for the Linux kernel code.  A number of issues we have here
> > > (cross compiling, code size, license compatibility, long term
> > > maintenance efforts) have already been considered there, so why
> > > should we duplicate all these efforts?  And if we did, is there any
> > > clear benefit from doing this?
> > Well someone has to port the linux code in U-Boot and maintain it though.
> > 
> > The LibreSSL proposal was made with some of these in mind. 
> > We don't expect the licence to ever change (which is compatible) 
> > and it's being maintained. 
> > I am not sure on the portability status, but i think it runs on all major
> > architectures.
> > 
> > I'd imagine this lifts the maintenance burden from U-Boot. On the other 
> > hand we'll rely on an external library to offer the functionality. 
> 
> I don't see how using LibreSSL instead of Linux kernel code would have a
> lesser maintenance burden, sorry.  If anything, given the number of
> parts of the code we have today that come from the Linux kernel, adding
> one more to the "keep in sync, or at least port bugfixes" list is less
> than "add a new external project to keep an eye on".
> 
Right then we know what we have to do. Kernel code it is. 

Thanks a lot 
/Ilias
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] sysreset: switch to using SYSRESET_POWER_OFF for poweroff

2019-05-16 Thread Urja Rannikko
Hi,

On Thu, May 16, 2019 at 7:44 AM Patrick DELAUNAY
 wrote:
>
> Hi Urja,
>
> > - if (type != SYSRESET_POWER)
> > + if (type != SYSRESET_POWER_OFF)
> >   return -EPROTONOSUPPORT;
>
> In fact in the next part of the code, we are supporting
> only SYSRESET_POWER (reset with PMIC1 switch OFF and restart)
> and not SYSRESET_POWER_OFF
>
> because Power Cycle if RREQ_EN=1
>
> I think you need to remove the update on this file for your patch and
> I will modified this function is to support both mode
Okay I will drop this part, but just to confirm... this means that
currently you have a configuration where using the poweroff command
causes a power-cycle? Neat.

-- 
Urja Rannikko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 2/3] sysreset: move stm32mp sysreset poweroff implementation to sysreset uclass

2019-05-16 Thread Urja Rannikko
Hi,

On Tue, May 14, 2019 at 4:07 PM Patrice CHOTARD  wrote:
>
> Hi Urja
>
> This patch doesn't compile using the stm32mp15_trusted_defconfig
> configuration:
>
> ...
>   LD  drivers/pinctrl/built-in.o
>   LD  drivers/core/built-in.o
>   LD  drivers/mmc/built-in.o
>   LD  drivers/built-in.o
> drivers/sysreset/built-in.o: In function `do_poweroff':
> /local/home/nxp11987/projects/community/u-boot.denx/drivers/sysreset/sysreset-uclass.c:123:
> multiple definition of `do_poweroff'
> drivers/firmware/built-in.o:/local/home/nxp11987/projects/community/u-boot.denx/drivers/firmware/psci.c:134:
> first defined here
> make[1]: *** [drivers/built-in.o] Error 1
> make: *** [drivers] Error 2
> build error !!
>
>
> I suggest you to update your patch with :
>
> config PMIC_STPMIC1
> bool "Enable support for STMicroelectronics STPMIC1 PMIC"
> depends on DM_PMIC && DM_I2C
> -   select SYSRESET_CMD_POWEROFF if CMD_POWEROFF
> +   select SYSRESET_CMD_POWEROFF if CMD_POWEROFF && !ARM_PSCI_FW
> ---help---
> The STPMIC1 PMIC provides 4 BUCKs, 6 LDOs, 1 VREF and 2 power 
> switches.
> It is accessed via an I2C interface. The device is used with STM32MP1
> SoCs. This driver implements register read/write operations.

I'll do that in v2, thanks for the test.

-- 
Urja Rannikko
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RSA in U-Boot

2019-05-16 Thread AKASHI Takahiro
Hi Tom,

On Thu, May 16, 2019 at 07:13:59AM -0400, Tom Rini wrote:
> On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > Hello Wolfgang, 
> > 
> > Thanks for taking the time with this
> > > > 
> > > > There is LibreSSL as well which is a fork of openssl. Guess that too 
> > > > should
> > > > be fine. What would be the more preferred solution here. The relevant 
> > > > bits
> > > > can be imported from the kernel code into u-boot, or there can be a
> > > > solution with linking of ssl/tls library with u-boot. Which would be the
> > > > more preferred solution. It'd be great if the maintainers can comment on
> > > > this. Thanks.
> > > 
> > > I'd go for the Linux kernel code.  A number of issues we have here
> > > (cross compiling, code size, license compatibility, long term
> > > maintenance efforts) have already been considered there, so why
> > > should we duplicate all these efforts?  And if we did, is there any
> > > clear benefit from doing this?
> > Well someone has to port the linux code in U-Boot and maintain it though.
> > 
> > The LibreSSL proposal was made with some of these in mind. 
> > We don't expect the licence to ever change (which is compatible) 
> > and it's being maintained. 
> > I am not sure on the portability status, but i think it runs on all major
> > architectures.
> > 
> > I'd imagine this lifts the maintenance burden from U-Boot. On the other 
> > hand we'll rely on an external library to offer the functionality. 
> 
> I don't see how using LibreSSL instead of Linux kernel code would have a
> lesser maintenance burden, sorry.  If anything, given the number of
> parts of the code we have today that come from the Linux kernel, adding
> one more to the "keep in sync, or at least port bugfixes" list is less
> than "add a new external project to keep an eye on".

# I will reply on this topic in more details tomorrow.

Can you give me an example of U-Boot code which comes from linux (or
other projects) and is regularly synced (or updated) with the origin?
Who maintains that? and how?

Thanks,
-Takahiro Akashi

> -- 
> Tom



> ___
> 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] [PATCHv2 1/2] PCI: layerscape: Add Support for ls2088 PCIe EP mode

2019-05-16 Thread Bin Meng
Hi,

On Thu, May 16, 2019 at 7:02 PM Xiaowei Bao  wrote:
>
> From: Xiaowei Bao 
>
> Signed-off-by: hongbo.wang 
> Signed-off-by: Minghuan Lian 
> Signed-off-by: Xiaowei Bao 
> ---
> v2:
>  - Add the NXP copyright and make the function readability.
>
>  drivers/pci/pcie_layerscape.c |  117 
> +++--
>  drivers/pci/pcie_layerscape.h |   19 +--
>  2 files changed, 91 insertions(+), 45 deletions(-)
>

Could you please support the PCIe EP mode using driver model?

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [v1] ls1028a: video: Add a empty video hw init for LS1028A

2019-05-16 Thread Bin Meng
On Thu, May 16, 2019 at 11:57 AM Wen He  wrote:
>
> The video driver causes a link failure when config VIDEO built-in,
>
> drivers/video/cfb_console.c:2022: undefined reference to `video_hw_init'
>
> Adding a empty video hw init to slove the build issue, now the board
> does not support display anything on U-boot.
>
> Signed-off-by: Wen He 
> ---
>  board/freescale/ls1028a/ls1028a.c | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/board/freescale/ls1028a/ls1028a.c 
> b/board/freescale/ls1028a/ls1028a.c
> index e5de4eb70c..ece91660bf 100644
> --- a/board/freescale/ls1028a/ls1028a.c
> +++ b/board/freescale/ls1028a/ls1028a.c
> @@ -20,6 +20,7 @@
>  #endif
>  #include 
>  #include 
> +#include 
>
>  #include 
>  #include 
> @@ -229,3 +230,8 @@ int checkboard(void)
> return 0;
>  }
>  #endif
> +
> +void *video_hw_init(void)
> +{
> +   return NULL;
> +}
> --

Please stop adding non-DM driver support to any new platforms. We
should start using DM driver. In this case, use DM_VIDEO.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RSA in U-Boot

2019-05-16 Thread Tom Rini
On Thu, May 16, 2019 at 08:56:40PM +0900, AKASHI Takahiro wrote:
> Hi Tom,
> 
> On Thu, May 16, 2019 at 07:13:59AM -0400, Tom Rini wrote:
> > On Thu, May 16, 2019 at 01:45:54PM +0300, Ilias Apalodimas wrote:
> > > On Thu, May 16, 2019 at 12:39:02PM +0200, Wolfgang Denk wrote:
> > > Hello Wolfgang, 
> > > 
> > > Thanks for taking the time with this
> > > > > 
> > > > > There is LibreSSL as well which is a fork of openssl. Guess that too 
> > > > > should
> > > > > be fine. What would be the more preferred solution here. The relevant 
> > > > > bits
> > > > > can be imported from the kernel code into u-boot, or there can be a
> > > > > solution with linking of ssl/tls library with u-boot. Which would be 
> > > > > the
> > > > > more preferred solution. It'd be great if the maintainers can comment 
> > > > > on
> > > > > this. Thanks.
> > > > 
> > > > I'd go for the Linux kernel code.  A number of issues we have here
> > > > (cross compiling, code size, license compatibility, long term
> > > > maintenance efforts) have already been considered there, so why
> > > > should we duplicate all these efforts?  And if we did, is there any
> > > > clear benefit from doing this?
> > > Well someone has to port the linux code in U-Boot and maintain it though.
> > > 
> > > The LibreSSL proposal was made with some of these in mind. 
> > > We don't expect the licence to ever change (which is compatible) 
> > > and it's being maintained. 
> > > I am not sure on the portability status, but i think it runs on all major
> > > architectures.
> > > 
> > > I'd imagine this lifts the maintenance burden from U-Boot. On the other 
> > > hand we'll rely on an external library to offer the functionality. 
> > 
> > I don't see how using LibreSSL instead of Linux kernel code would have a
> > lesser maintenance burden, sorry.  If anything, given the number of
> > parts of the code we have today that come from the Linux kernel, adding
> > one more to the "keep in sync, or at least port bugfixes" list is less
> > than "add a new external project to keep an eye on".
> 
> # I will reply on this topic in more details tomorrow.
> 
> Can you give me an example of U-Boot code which comes from linux (or
> other projects) and is regularly synced (or updated) with the origin?
> Who maintains that? and how?

The device trees are one example.  Kbuild is another.  ubifs too.  We
just added lib/zstd :)

-- 
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 1/3 v3] armv8: ls1028a: Add NXP LS1028A SoC support

2019-05-16 Thread Bin Meng
Hi,

On Wed, Apr 10, 2019 at 4:50 PM Yuantian Tang  wrote:
>
> Ls1028a Soc is based on Layerscape Chassis Generation 3.2
> architecture with features:
>  2 ARM v8 Cortex-A72 cores, CCI400, SEC, DDR3L/4, LCD, GPU, TSN
>  ENETC, 2 USB 3.0, 2 eSDHC, 2 FlexCAN, 2 SPI, SATA, 8 I2C controllers,
>  6 LPUARTs, GPIO, SAI, qDMA, eDMA, GIC, TMU etc.
>
> Signed-off-by: Sudhanshu Gupta 
> Signed-off-by: Rai Harninder 
> Signed-off-by: Rajesh Bhagat 
> Signed-off-by: Bhaskar Upadhaya 
> Signed-off-by: Tang Yuantian 
> ---
> v3:
> -- fix some issues
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  39 ++-
>  arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
>  arch/arm/cpu/armv8/fsl-layerscape/cpu.c|   3 +
>  arch/arm/cpu/armv8/fsl-layerscape/doc/README.soc   |  51 
>  arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c |  73 ++
>  arch/arm/dts/fsl-ls1028a.dtsi  | 280 
> +
>  arch/arm/include/asm/arch-fsl-layerscape/config.h  |  61 +
>  .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |   9 +
>  arch/arm/include/asm/arch-fsl-layerscape/soc.h |   1 +
>  .../asm/arch-fsl-layerscape/stream_id_lsch3.h  |   2 +-
>  10 files changed, 521 insertions(+), 2 deletions(-)
>  create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1028a_serdes.c
>  create mode 100644 arch/arm/dts/fsl-ls1028a.dtsi
>

I really would like to see complete DM driver support on this new
platform. Please consider converting appropriate codes to driver
model. If there is no proper uclass model, please propose one and
discuss it on the list. I see the existing NXP PowerPC support is
stuck in such a situation that lots of codes are still non-DM and we
are getting close to the DM deadline. I don't want to see such happens
again in the NXP ARM support.

Thanks!

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [v2] board: ls1028a: Add an empty video hw init function

2019-05-16 Thread Bin Meng
On Thu, May 16, 2019 at 2:48 PM Wen He  wrote:
>
> The video driver causes a link failure when config VIDEO built-in,
>
> drivers/video/cfb_console.c:2022: undefined reference to `video_hw_init'
>
> Adding an empty video hw init to slove the build issue, now the board
> does not support display anything on U-boot.
>
> Signed-off-by: Wen He 
> ---
>  board/freescale/ls1028a/ls1028a.c | 6 ++
>  1 file changed, 6 insertions(+)
>

I should have commented in the v2 patch here. Sorry for the duplication.

Please stop adding non-DM driver support to any new platforms. We
should start using DM driver. In this case, use DM_VIDEO.

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] RSA in U-Boot

2019-05-16 Thread Wolfgang Denk
Dear Akashi Takahiro,

In message <20190516115636.GA8052@fireball> you wrote:
> 
> Can you give me an example of U-Boot code which comes from linux (or
> other projects) and is regularly synced (or updated) with the origin?
> Who maintains that? and how?

Comes from Linux: a ton... Kconfig, Linker Script, MTD, UBI, UBIFS,
ext2/3/4, jffs2, libfdt, many drivers, network stack,
reiserfs, just to name a few.

Regularly synced: None.  Usually this only happens in irregular
intervals, if incompatibilities or bugs (that have been
fixed in more recent code) show up

Who: usually the responsible custodians

How: ideally thius should be a straightforward, though largely
manual process.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Eureka! -- Archimedes
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 0/3] Enable spl relocation on arm

2019-05-16 Thread Andy Yan
Some times we want to relocate spl code to dram after dram
initialization or relocate spl code to a high memory to avoid
code overid.

For example on Rockchip armv8 platform, we run with boot flow
TPL->SPL->ATF->U-Boot.
TPL run in sram and is responsible for dram initialization.
SPL run from the start address of dram and is responsible for
loading ATF and U-Boot.

The case here is that the ATF load address is from 64KB of dram,
which overlaps with spl code itself.

So we want to relocate spl itself to high memory to aovid this.

When look the code, I found powerpc use the spl relocation. So
I dicide share the config with powerpc.

Changes in v2:
- Move Kconfig modification to PATCH 1/3
- Add more detial commit message

Andy Yan (3):
  powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig
  spl: add relocation support
  arm: add spl relocation support for arm

 arch/arm/config.mk   |  6 +++
 arch/arm/cpu/armv8/start.S   |  4 ++
 arch/arm/cpu/armv8/u-boot-spl.lds| 17 ++
 arch/arm/lib/Makefile|  2 +-
 arch/arm/lib/crt0_64.S   |  3 +-
 common/spl/Kconfig   | 13 +
 common/spl/spl.c | 55 
 configs/BSC9131RDB_NAND_SYSCLK100_defconfig  |  2 +
 configs/BSC9131RDB_NAND_defconfig|  2 +
 configs/BSC9132QDS_NAND_DDRCLK100_defconfig  |  2 +
 configs/BSC9132QDS_NAND_DDRCLK133_defconfig  |  2 +
 configs/C29XPCIE_NAND_defconfig  |  2 +
 configs/P1010RDB-PA_36BIT_NAND_defconfig |  2 +
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig   |  2 +
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig |  2 +
 configs/P1010RDB-PA_NAND_defconfig   |  2 +
 configs/P1010RDB-PA_SDCARD_defconfig |  2 +
 configs/P1010RDB-PA_SPIFLASH_defconfig   |  2 +
 configs/P1010RDB-PB_36BIT_NAND_defconfig |  2 +
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig   |  2 +
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig |  2 +
 configs/P1010RDB-PB_NAND_defconfig   |  2 +
 configs/P1010RDB-PB_SDCARD_defconfig |  2 +
 configs/P1010RDB-PB_SPIFLASH_defconfig   |  2 +
 configs/P1020MBG-PC_36BIT_SDCARD_defconfig   |  2 +
 configs/P1020MBG-PC_SDCARD_defconfig |  2 +
 configs/P1020RDB-PC_36BIT_NAND_defconfig |  2 +
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig   |  2 +
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig |  2 +
 configs/P1020RDB-PC_NAND_defconfig   |  2 +
 configs/P1020RDB-PC_SDCARD_defconfig |  2 +
 configs/P1020RDB-PC_SPIFLASH_defconfig   |  2 +
 configs/P1020RDB-PD_NAND_defconfig   |  2 +
 configs/P1020RDB-PD_SDCARD_defconfig |  2 +
 configs/P1020RDB-PD_SPIFLASH_defconfig   |  2 +
 configs/P1020UTM-PC_36BIT_SDCARD_defconfig   |  2 +
 configs/P1020UTM-PC_SDCARD_defconfig |  2 +
 configs/P1021RDB-PC_36BIT_NAND_defconfig |  2 +
 configs/P1021RDB-PC_36BIT_SDCARD_defconfig   |  2 +
 configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig |  2 +
 configs/P1021RDB-PC_NAND_defconfig   |  2 +
 configs/P1021RDB-PC_SDCARD_defconfig |  2 +
 configs/P1021RDB-PC_SPIFLASH_defconfig   |  2 +
 configs/P1022DS_36BIT_NAND_defconfig |  2 +
 configs/P1022DS_36BIT_SDCARD_defconfig   |  2 +
 configs/P1022DS_36BIT_SPIFLASH_defconfig |  2 +
 configs/P1022DS_NAND_defconfig   |  2 +
 configs/P1022DS_SDCARD_defconfig |  2 +
 configs/P1022DS_SPIFLASH_defconfig   |  2 +
 configs/P1024RDB_NAND_defconfig  |  2 +
 configs/P1024RDB_SDCARD_defconfig|  2 +
 configs/P1024RDB_SPIFLASH_defconfig  |  2 +
 configs/P1025RDB_NAND_defconfig  |  2 +
 configs/P1025RDB_SDCARD_defconfig|  2 +
 configs/P1025RDB_SPIFLASH_defconfig  |  2 +
 configs/P2020RDB-PC_36BIT_NAND_defconfig |  2 +
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig   |  2 +
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig |  2 +
 configs/P2020RDB-PC_NAND_defconfig   |  2 +
 configs/P2020RDB-PC_SDCARD_defconfig |  2 +
 configs/P2020RDB-PC_SPIFLASH_defconfig   |  2 +
 include/configs/BSC9131RDB.h |  1 -
 include/configs/BSC9132QDS.h |  1 -
 include/configs/C29XPCIE.h   |  3 --
 include/configs/P1010RDB.h   |  4 --
 include/configs/P1022DS.h|  3 --
 include/configs/p1_p2_rdb_pc.h   |  3 --
 67 files changed, 206 insertions(+), 17 deletions(-)

-- 
2.17.1



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 1/3] powerpc: Convert CONFIG_SPL_RELOC_TEXT_BASE to Kconfig

2019-05-16 Thread Andy Yan
Move CONFIG_SPL_RELOC_TEXT_BASE and CONFIG_SPL_SKIP_RELOCATE
to Kconfig, so we can reuse it for cross other platform.

Signed-off-by: Andy Yan 
---

Changes in v2: None

 common/spl/Kconfig   | 13 +
 configs/BSC9131RDB_NAND_SYSCLK100_defconfig  |  2 ++
 configs/BSC9131RDB_NAND_defconfig|  2 ++
 configs/BSC9132QDS_NAND_DDRCLK100_defconfig  |  2 ++
 configs/BSC9132QDS_NAND_DDRCLK133_defconfig  |  2 ++
 configs/C29XPCIE_NAND_defconfig  |  2 ++
 configs/P1010RDB-PA_36BIT_NAND_defconfig |  2 ++
 configs/P1010RDB-PA_36BIT_SDCARD_defconfig   |  2 ++
 configs/P1010RDB-PA_36BIT_SPIFLASH_defconfig |  2 ++
 configs/P1010RDB-PA_NAND_defconfig   |  2 ++
 configs/P1010RDB-PA_SDCARD_defconfig |  2 ++
 configs/P1010RDB-PA_SPIFLASH_defconfig   |  2 ++
 configs/P1010RDB-PB_36BIT_NAND_defconfig |  2 ++
 configs/P1010RDB-PB_36BIT_SDCARD_defconfig   |  2 ++
 configs/P1010RDB-PB_36BIT_SPIFLASH_defconfig |  2 ++
 configs/P1010RDB-PB_NAND_defconfig   |  2 ++
 configs/P1010RDB-PB_SDCARD_defconfig |  2 ++
 configs/P1010RDB-PB_SPIFLASH_defconfig   |  2 ++
 configs/P1020MBG-PC_36BIT_SDCARD_defconfig   |  2 ++
 configs/P1020MBG-PC_SDCARD_defconfig |  2 ++
 configs/P1020RDB-PC_36BIT_NAND_defconfig |  2 ++
 configs/P1020RDB-PC_36BIT_SDCARD_defconfig   |  2 ++
 configs/P1020RDB-PC_36BIT_SPIFLASH_defconfig |  2 ++
 configs/P1020RDB-PC_NAND_defconfig   |  2 ++
 configs/P1020RDB-PC_SDCARD_defconfig |  2 ++
 configs/P1020RDB-PC_SPIFLASH_defconfig   |  2 ++
 configs/P1020RDB-PD_NAND_defconfig   |  2 ++
 configs/P1020RDB-PD_SDCARD_defconfig |  2 ++
 configs/P1020RDB-PD_SPIFLASH_defconfig   |  2 ++
 configs/P1020UTM-PC_36BIT_SDCARD_defconfig   |  2 ++
 configs/P1020UTM-PC_SDCARD_defconfig |  2 ++
 configs/P1021RDB-PC_36BIT_NAND_defconfig |  2 ++
 configs/P1021RDB-PC_36BIT_SDCARD_defconfig   |  2 ++
 configs/P1021RDB-PC_36BIT_SPIFLASH_defconfig |  2 ++
 configs/P1021RDB-PC_NAND_defconfig   |  2 ++
 configs/P1021RDB-PC_SDCARD_defconfig |  2 ++
 configs/P1021RDB-PC_SPIFLASH_defconfig   |  2 ++
 configs/P1022DS_36BIT_NAND_defconfig |  2 ++
 configs/P1022DS_36BIT_SDCARD_defconfig   |  2 ++
 configs/P1022DS_36BIT_SPIFLASH_defconfig |  2 ++
 configs/P1022DS_NAND_defconfig   |  2 ++
 configs/P1022DS_SDCARD_defconfig |  2 ++
 configs/P1022DS_SPIFLASH_defconfig   |  2 ++
 configs/P1024RDB_NAND_defconfig  |  2 ++
 configs/P1024RDB_SDCARD_defconfig|  2 ++
 configs/P1024RDB_SPIFLASH_defconfig  |  2 ++
 configs/P1025RDB_NAND_defconfig  |  2 ++
 configs/P1025RDB_SDCARD_defconfig|  2 ++
 configs/P1025RDB_SPIFLASH_defconfig  |  2 ++
 configs/P2020RDB-PC_36BIT_NAND_defconfig |  2 ++
 configs/P2020RDB-PC_36BIT_SDCARD_defconfig   |  2 ++
 configs/P2020RDB-PC_36BIT_SPIFLASH_defconfig |  2 ++
 configs/P2020RDB-PC_NAND_defconfig   |  2 ++
 configs/P2020RDB-PC_SDCARD_defconfig |  2 ++
 configs/P2020RDB-PC_SPIFLASH_defconfig   |  2 ++
 include/configs/BSC9131RDB.h |  1 -
 include/configs/BSC9132QDS.h |  1 -
 include/configs/C29XPCIE.h   |  3 ---
 include/configs/P1010RDB.h   |  4 
 include/configs/P1022DS.h|  3 ---
 include/configs/p1_p2_rdb_pc.h   |  3 ---
 61 files changed, 121 insertions(+), 15 deletions(-)

diff --git a/common/spl/Kconfig b/common/spl/Kconfig
index 206c24076d..52669ce1f8 100644
--- a/common/spl/Kconfig
+++ b/common/spl/Kconfig
@@ -189,6 +189,19 @@ config SPL_DISPLAY_PRINT
  banner ("U-Boot SPL ..."). This function should be provided by
  the board.
 
+config SPL_SKIP_RELOCATE
+   bool "Skip code relocation in SPL"
+   default y
+   help
+ The SPL code will be relocated to a high memory if you say no here.
+ Only ARM64 and PowerPC SPL support relocate now.
+
+config SPL_RELOC_TEXT_BASE
+   hex "Address the SPL relocate to"
+   depends on !SPL_SKIP_RELOCATE
+   help
+ The address on the ram where the SPL relocate to.
+
 config SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR
bool "MMC raw mode: by sector"
default y if ARCH_SUNXI || ARCH_DAVINCI || ARCH_UNIPHIER || \
diff --git a/configs/BSC9131RDB_NAND_SYSCLK100_defconfig 
b/configs/BSC9131RDB_NAND_SYSCLK100_defconfig
index 55906fa0ff..81aaff4585 100644
--- a/configs/BSC9131RDB_NAND_SYSCLK100_defconfig
+++ b/configs/BSC9131RDB_NAND_SYSCLK100_defconfig
@@ -13,6 +13,8 @@ CONFIG_BOOTDELAY=10
 CONFIG_SYS_CONSOLE_IS_IN_ENV=y
 # CONFIG_MISC_INIT_R is not set
 # CONFIG_SPL_FRAMEWORK is not set
+# CONFIG_SPL_SKIP_RELOCATE is not set
+CONFIG_SPL_RELOC_TEXT_BASE=0x10
 CONFIG_SPL_NAND_SUPPORT=y
 CONFIG_HUSH_PARSER=y
 # CONFIG_CMD_FLASH is not set
diff --git a/configs/BSC9131RDB_NAND_defconfig 
b/configs/BSC9131RDB_NAND_d

[U-Boot] [PATCH v2 2/3] spl: add relocation support

2019-05-16 Thread Andy Yan
Some times we want to relocate spl code to dram after dram
initialization or relocate spl code to a high memory to avoid
code overid.

For example on Rockchip armv8 platform, we run with boot flow
TPL->SPL->ATF->U-Boot.
TPL run in sram and is responsible for dram initialization.
SPL run from the start address of dram and is responsible for
loading ATF and U-Boot.

The case here is that the ATF load address is from 64KB of dram,
which overlaps with spl code itself.

So we want to relocate spl itself to high memory to aovid this.

Signed-off-by: Andy Yan 
---

Changes in v2:
- Move Kconfig modification to PATCH 1/3

 common/spl/spl.c | 55 
 1 file changed, 55 insertions(+)

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 88d4b8a9bf..affb65ccbd 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -439,6 +440,28 @@ static int spl_common_init(bool setup_malloc)
return 0;
 }
 
+#if !defined(CONFIG_SPL_SKIP_RELOCATE) && !defined(CONFIG_TPL_BUILD)
+static void spl_setup_relocate(void)
+{
+   gd->relocaddr = CONFIG_SPL_RELOC_TEXT_BASE;
+   gd->new_gd = (gd_t *)gd;
+   gd->start_addr_sp = gd->relocaddr;
+   gd->fdt_size = ALIGN(fdt_totalsize(gd->fdt_blob) + 0x1000, 32);
+
+   gd->start_addr_sp -= gd->fdt_size;
+   gd->new_fdt = (void *)gd->start_addr_sp;
+   memcpy(gd->new_fdt, gd->fdt_blob, gd->fdt_size);
+   gd->fdt_blob = gd->new_fdt;
+
+   gd->reloc_off = gd->relocaddr - (unsigned long)__image_copy_start;
+}
+#else
+static void spl_setup_relocate(void)
+{
+
+}
+#endif
+
 void spl_set_bd(void)
 {
/*
@@ -460,6 +483,8 @@ int spl_early_init(void)
return ret;
gd->flags |= GD_FLG_SPL_EARLY_INIT;
 
+   spl_setup_relocate();
+
return 0;
 }
 
@@ -563,6 +588,34 @@ static int boot_from_devices(struct spl_image_info 
*spl_image,
return -ENODEV;
 }
 
+#if defined(CONFIG_DM) && !defined(CONFIG_SPL_SKIP_RELOCATE) && 
!defined(CONFIG_TPL_BUILD)
+static int spl_initr_dm(void)
+{
+   int ret;
+
+   /* Save the pre-reloc driver model and start a new one */
+   gd->dm_root_f = gd->dm_root;
+   gd->dm_root = NULL;
+   bootstage_start(BOOTSTATE_ID_ACCUM_DM_R, "dm_r");
+   ret = dm_init_and_scan(false);
+   bootstage_accum(BOOTSTATE_ID_ACCUM_DM_R);
+   if (ret)
+   return ret;
+
+#if defined(CONFIG_TIMER)
+   gd->timer = NULL;
+#endif
+   serial_init();
+
+   return 0;
+}
+#else
+static int spl_initr_dm(void)
+{
+   return 0;
+}
+#endif
+
 void board_init_r(gd_t *dummy1, ulong dummy2)
 {
u32 spl_boot_list[] = {
@@ -577,6 +630,8 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 
debug(">>" SPL_TPL_PROMPT "board_init_r()\n");
 
+   spl_initr_dm();
+
spl_set_bd();
 
 #if defined(CONFIG_SYS_SPL_MALLOC_START)
-- 
2.17.1



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 3/3] arm: add spl relocation support for arm

2019-05-16 Thread Andy Yan
Some times we want to relocate spl code to dram after dram
initialization or relocate spl code to a high memory to avoid
code overid.

For example on Rockchip armv8 platform, we run with boot flow
TPL->SPL->ATF->U-Boot.
TPL run in sram and is responsible for dram initialization.
SPL run from the start address of dram and is responsible for
loading ATF and U-Boot.

The case here is that the ATF load address is from 64KB of dram,
which overlaps with spl code itself.

So we want to relocate spl itself to high memory to aovid this.

Signed-off-by: Andy Yan 
---

Changes in v2:
- Add more detial commit message

 arch/arm/config.mk|  6 ++
 arch/arm/cpu/armv8/start.S|  4 
 arch/arm/cpu/armv8/u-boot-spl.lds | 17 +
 arch/arm/lib/Makefile |  2 +-
 arch/arm/lib/crt0_64.S|  3 ++-
 5 files changed, 30 insertions(+), 2 deletions(-)

diff --git a/arch/arm/config.mk b/arch/arm/config.mk
index f25603109e..7f6ad89601 100644
--- a/arch/arm/config.mk
+++ b/arch/arm/config.mk
@@ -102,6 +102,12 @@ endif
 # needed for relocation
 LDFLAGS_u-boot += -pie
 
+ifndef CONFIG_SPL_SKIP_RELOCATE
+LDFLAGS_u-boot-spl = -pie
+else
+SPL_LDFLAGS_u-boot-spl =
+endif
+
 #
 # FIXME: binutils versions < 2.22 have a bug in the assembler where
 # branches to weak symbols can be incorrectly optimized in thumb mode
diff --git a/arch/arm/cpu/armv8/start.S b/arch/arm/cpu/armv8/start.S
index fe52166e28..a7dad3cd69 100644
--- a/arch/arm/cpu/armv8/start.S
+++ b/arch/arm/cpu/armv8/start.S
@@ -35,7 +35,11 @@ _start:
 
 .globl _TEXT_BASE
 _TEXT_BASE:
+#if defined(CONFIG_SPL_BUILD)
+   .quad   CONFIG_SPL_TEXT_BASE
+#else
.quad   CONFIG_SYS_TEXT_BASE
+#endif
 
 /*
  * These are defined in the linker script.
diff --git a/arch/arm/cpu/armv8/u-boot-spl.lds 
b/arch/arm/cpu/armv8/u-boot-spl.lds
index ccbf359bd1..64102afc8b 100644
--- a/arch/arm/cpu/armv8/u-boot-spl.lds
+++ b/arch/arm/cpu/armv8/u-boot-spl.lds
@@ -53,6 +53,23 @@ SECTIONS
*(.__end)
} >.sram
 
+#ifndef CONFIG_SPL_SKIP_RELOCATE
+   . = ALIGN(8);
+
+   .rel_dyn_start :
+   {
+   *(.__rel_dyn_start)
+   } >.sram
+
+   .rela.dyn : {
+   *(.rela*)
+   } >.sram
+
+   .rel_dyn_end :
+   {
+   *(.__rel_dyn_end)
+   } >.sram
+#endif
_image_binary_end = .;
 
.bss_start (NOLOAD) : {
diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 48ee6c3c60..f27b3fb79f 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -21,7 +21,7 @@ else
 obj-y   += setjmp.o
 endif
 
-ifndef CONFIG_SPL_BUILD
+ifndef CONFIG_TPL_BUILD
 ifdef CONFIG_ARM64
 obj-y  += relocate_64.o
 else
diff --git a/arch/arm/lib/crt0_64.S b/arch/arm/lib/crt0_64.S
index d6b632aa87..e5605fe325 100644
--- a/arch/arm/lib/crt0_64.S
+++ b/arch/arm/lib/crt0_64.S
@@ -89,7 +89,8 @@ ENTRY(_main)
mov x0, #0
bl  board_init_f
 
-#if !defined(CONFIG_SPL_BUILD)
+#if (defined(CONFIG_SPL_BUILD) && !defined(CONFIG_TPL_BUILD) && 
!defined(CONFIG_SPL_SKIP_RELOCATE)) || \
+   !defined(CONFIG_SPL_BUILD)
 /*
  * Set up intermediate environment (new sp and gd) and call
  * relocate_code(addr_moni). Trick here is that we'll return
-- 
2.17.1



___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] The CONFIG_DM_I2C_COMPAT option is not available

2019-05-16 Thread Chuanhua Han
hi, Heiko Schocher

Some soc related files use i2c_read, i2c_write similar function interface,
if you do not use the CONFIG_DM_I2C_COMPAT option to compile,
there will be a function undefined compilation error,
but if you do CONFIG_DM_I2C_COMPAT=y When compiling,
there will be the following warnings:

= 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.


If I do ONFIG_DM_I2C_COMPAT=y, do I need to implement i2c_read, i2c_write such 
as the function interface definition in the i2c controller driver?
But these function declarations are all from include/i2c.h, if CONFIG_DM_I2C=y, 
these functions are not declared.

How should I be compatible with these old-style interfaces?

look forward to your reply!

Thanks,
Chuanhua
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: Avoid writing temporary asl files into the source tree

2019-05-16 Thread Bin Meng
Hi Simon,

On Thu, May 9, 2019 at 10:57 AM Simon Glass  wrote:
>
> At present the iasl tool (Intel ACPI (Advanced Configuration and Power
> Interface) Source Language compiler) is called in such a way that it uses
> the source directory for its temporary files.
>
> This means we end up with these files when building x86 boards:
>
>board/dfi/dfi-bt700/dsdt.aml
>board/dfi/dfi-bt700/dsdt.asl.tmp
>
> Update the code to put temporary files in the target directory instead.
>
> Signed-off-by: Simon Glass 
> ---
>
>  scripts/Makefile.lib | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
> index de67677f61..6cf1382721 100644
> --- a/scripts/Makefile.lib
> +++ b/scripts/Makefile.lib
> @@ -397,9 +397,10 @@ $(obj)/%_efi.so: $(obj)/%.o $(obj)/efi_crt0.o 
> $(obj)/efi_reloc.o $(obj)/efi_free
>  # ---
>  quiet_cmd_acpi_c_asl= ASL $<
>  cmd_acpi_c_asl= \
> -   $(CPP) -x assembler-with-cpp -D__ASSEMBLY__ -P $(UBOOTINCLUDE) -o 
> $<.tmp $<; \
> -   iasl -p $< -tc $<.tmp $(if $(KBUILD_VERBOSE:1=), >/dev/null) && \
> -   mv $(patsubst %.asl,%.hex,$<) $@
> +   $(CPP) -x assembler-with-cpp -D__ASSEMBLY__ -P $(UBOOTINCLUDE) \
> +   -o $@.tmp $< && \

With the changes here, there is no board/dfi/dfi-bt700/dsdt.asl.tmp
anymore, but board/dfi/dfi-bt700/dsdt.c.tmp. This file name looks not
correct as it is not a C file. I am not sure if this could confuse
anyone else.

Besides, 'make distclean' does not clean the 'dsdt.c.tmp'.

> +   iasl -p $@ -tc $@.tmp $(if $(KBUILD_VERBOSE:1=), >/dev/null) && \
> +   mv $(patsubst %.c,%.hex,$@) $@
>

Regards,
Bin
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: coreboot: make it possible to process unhandled tags

2019-05-16 Thread Bin Meng
On Wed, Apr 17, 2019 at 8:42 PM Christian Gmeiner
 wrote:
>
> coreboot makes it possible to add own entries into coreboot's
> table at a per mainboard basis. As there might be some custom
> ones it makes sense to provide a way to process them.
>
> Signed-off-by: Christian Gmeiner 
> ---
>  arch/x86/cpu/coreboot/tables.c | 5 +
>  1 file changed, 5 insertions(+)
>

Reviewed-by: Bin Meng 

> diff --git a/arch/x86/cpu/coreboot/tables.c b/arch/x86/cpu/coreboot/tables.c
> index bc18b710c9..a7c55c7dd1 100644
> --- a/arch/x86/cpu/coreboot/tables.c
> +++ b/arch/x86/cpu/coreboot/tables.c
> @@ -109,6 +109,8 @@ static void cb_parse_string(unsigned char *ptr, char 
> **info)
> *info = (char *)((struct cb_string *)ptr)->string;
>  }
>
> +__weak void cb_parse_unhandled(u32 tag, unsigned char *ptr) {}
> +

nits: I would prefer to have {} in sparate lines.

I can fix this when applying.

>  static int cb_parse_header(void *addr, int len, struct sysinfo_t *info)
>  {
> struct cb_header *header;
> @@ -211,6 +213,9 @@ static int cb_parse_header(void *addr, int len, struct 
> sysinfo_t *info)
> case CB_TAG_VBNV:
> cb_parse_vbnv(ptr, info);
> break;
> +   default:
> +   cb_parse_unhandled(rec->tag, ptr);
> +   break;
> }
>
> ptr += rec->size;
> --
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: coreboot: make it possible to process unhandled tags

2019-05-16 Thread Bin Meng
On Thu, May 16, 2019 at 9:18 PM Bin Meng  wrote:
>
> On Wed, Apr 17, 2019 at 8:42 PM Christian Gmeiner
>  wrote:
> >
> > coreboot makes it possible to add own entries into coreboot's
> > table at a per mainboard basis. As there might be some custom
> > ones it makes sense to provide a way to process them.
> >
> > Signed-off-by: Christian Gmeiner 
> > ---
> >  arch/x86/cpu/coreboot/tables.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
>
> Reviewed-by: Bin Meng 
>
> > diff --git a/arch/x86/cpu/coreboot/tables.c b/arch/x86/cpu/coreboot/tables.c
> > index bc18b710c9..a7c55c7dd1 100644
> > --- a/arch/x86/cpu/coreboot/tables.c
> > +++ b/arch/x86/cpu/coreboot/tables.c
> > @@ -109,6 +109,8 @@ static void cb_parse_string(unsigned char *ptr, char 
> > **info)
> > *info = (char *)((struct cb_string *)ptr)->string;
> >  }
> >
> > +__weak void cb_parse_unhandled(u32 tag, unsigned char *ptr) {}
> > +
>
> nits: I would prefer to have {} in sparate lines.
>
> I can fix this when applying.

Fixed the nits and applied to u-boot-x86, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 1/4] Kconfig: Make CMD_SPL_NAND_OFS only available when proper memory is used

2019-05-16 Thread Lukasz Majewski
This commit makes the CMD_SPL_NAND_OFS only visible when we use NAND
memory.
Before this change it was present when only CMD_SPL was enabled (and
would stay when board with other falcon boot medium is used).

Signed-off-by: Lukasz Majewski 
---

 cmd/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 0d36da2a5c..7bc275f135 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -327,6 +327,7 @@ config CMD_SPL
 config CMD_SPL_NAND_OFS
hex "Offset of OS command line args for Falcon-mode NAND boot"
depends on CMD_SPL
+   depends on CMD_SPL && (TPL_NAND_SUPPORT || SPL_NAND_SUPPORT)
default 0
help
  This provides the offset of the command line arguments for Linux
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 2/4] Kconfig: cosmetic: Update description of CMD_SPL_NAND_OFS

2019-05-16 Thread Lukasz Majewski
The CMD_SPL_NAND_OFS description was a bit misleading, has
been updated.

Signed-off-by: Lukasz Majewski 
---

 cmd/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 7bc275f135..4dec190a38 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -325,8 +325,7 @@ config CMD_SPL
  command.
 
 config CMD_SPL_NAND_OFS
-   hex "Offset of OS command line args for Falcon-mode NAND boot"
-   depends on CMD_SPL
+   hex "Offset of OS args or dtb for Falcon-mode NAND boot"
depends on CMD_SPL && (TPL_NAND_SUPPORT || SPL_NAND_SUPPORT)
default 0
help
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 3/4] Kconfig: Add CMD_SPL_NOR_OFS config for falcon boot argument offset

2019-05-16 Thread Lukasz Majewski
This option will provide the offset in the parallel NOR flash memory to,
which the falcon boot data is stored.

Signed-off-by: Lukasz Majewski 
---

 cmd/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4dec190a38..b4b10cce00 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -334,6 +334,14 @@ config CMD_SPL_NAND_OFS
  for full information about how to use this option (and also see
  board/gateworks/gw_ventana/README for an example).
 
+config CMD_SPL_NOR_OFS
+   hex "Offset of OS args or dtb for Falcon-mode NOR boot"
+   depends on CMD_SPL && SPL_NOR_SUPPORT
+   default 0
+   help
+ This provides the offset of the command line arguments or dtb for
+ Linux when booting from NOR in Falcon mode.
+
 config CMD_SPL_WRITE_SIZE
hex "Size of argument area"
depends on CMD_SPL
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 4/4] doc: Update parallel NOR flash related information in README.falcon

2019-05-16 Thread Lukasz Majewski
This commit updates the doc/README.falcon regarding Falcon boot on
NOR flash memories.

Signed-off-by: Lukasz Majewski 

---

 doc/README.falcon | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/doc/README.falcon b/doc/README.falcon
index 9a7f0bc235..204f4b12b6 100644
--- a/doc/README.falcon
+++ b/doc/README.falcon
@@ -67,6 +67,9 @@ CONFIG_SYS_NAND_SPL_KERNEL_OFFS   Offset in NAND where 
the kernel is stored
 
 CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was 
saved.
 
+CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved.
+   (Please refer to MCCMON6 board's configuraiton)
+
 CONFIG_CMD_SPL_WRITE_SIZE  Size of the parameters area to be copied
 
 CONFIG_SPL_OS_BOOT Activate Falcon Mode.
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1 4/4] doc: Update parallel NOR flash related information in README.falcon

2019-05-16 Thread Fabio Estevam
On Thu, May 16, 2019 at 10:33 AM Lukasz Majewski  wrote:

>  CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was 
> saved.
>
> +CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved.
> +   (Please refer to MCCMON6 board's configuraiton)

Typo: configuration.

Also, it is not very obvious for the reader where the MCCMON6 board
configuration is located.

It would be easier to explicitly mention configs/mccmon6_nor_defconfig
as an example.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 1/4] Kconfig: Make CMD_SPL_NAND_OFS only available when proper memory is used

2019-05-16 Thread Lukasz Majewski
This commit makes the CMD_SPL_NAND_OFS only visible when we use NAND
memory.
Before this change it was present when only CMD_SPL was enabled (and
would stay when board with other falcon boot medium is used).

Signed-off-by: Lukasz Majewski 
---

Changes in v2: None

 cmd/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 0d36da2a5c..7bc275f135 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -327,6 +327,7 @@ config CMD_SPL
 config CMD_SPL_NAND_OFS
hex "Offset of OS command line args for Falcon-mode NAND boot"
depends on CMD_SPL
+   depends on CMD_SPL && (TPL_NAND_SUPPORT || SPL_NAND_SUPPORT)
default 0
help
  This provides the offset of the command line arguments for Linux
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 2/4] Kconfig: cosmetic: Update description of CMD_SPL_NAND_OFS

2019-05-16 Thread Lukasz Majewski
The CMD_SPL_NAND_OFS description was a bit misleading, has
been updated.

Signed-off-by: Lukasz Majewski 
---

Changes in v2: None

 cmd/Kconfig | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 7bc275f135..4dec190a38 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -325,8 +325,7 @@ config CMD_SPL
  command.
 
 config CMD_SPL_NAND_OFS
-   hex "Offset of OS command line args for Falcon-mode NAND boot"
-   depends on CMD_SPL
+   hex "Offset of OS args or dtb for Falcon-mode NAND boot"
depends on CMD_SPL && (TPL_NAND_SUPPORT || SPL_NAND_SUPPORT)
default 0
help
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 4/4] doc: Update parallel NOR flash related information in README.falcon

2019-05-16 Thread Lukasz Majewski
This commit updates the doc/README.falcon regarding Falcon boot on
NOR flash memories.

This code is used by MCCMON6 board - so for more details please refer to
configs/mccmon6_nor_defconfig.

Signed-off-by: Lukasz Majewski 

---

Changes in v2:
- Fix the description
- Update the comit message

 doc/README.falcon | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/README.falcon b/doc/README.falcon
index 9a7f0bc235..713d7063a1 100644
--- a/doc/README.falcon
+++ b/doc/README.falcon
@@ -67,6 +67,8 @@ CONFIG_SYS_NAND_SPL_KERNEL_OFFS   Offset in NAND where 
the kernel is stored
 
 CONFIG_CMD_SPL_NAND_OFSOffset in NAND where the parameters area was 
saved.
 
+CONFIG_CMD_SPL_NOR_OFS Offset in NOR where the parameters area was saved.
+
 CONFIG_CMD_SPL_WRITE_SIZE  Size of the parameters area to be copied
 
 CONFIG_SPL_OS_BOOT Activate Falcon Mode.
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 3/4] Kconfig: Add CMD_SPL_NOR_OFS config for falcon boot argument offset

2019-05-16 Thread Lukasz Majewski
This option will provide the offset in the parallel NOR flash memory to,
which the falcon boot data is stored.

Signed-off-by: Lukasz Majewski 
---

Changes in v2: None

 cmd/Kconfig | 8 
 1 file changed, 8 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 4dec190a38..b4b10cce00 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -334,6 +334,14 @@ config CMD_SPL_NAND_OFS
  for full information about how to use this option (and also see
  board/gateworks/gw_ventana/README for an example).
 
+config CMD_SPL_NOR_OFS
+   hex "Offset of OS args or dtb for Falcon-mode NOR boot"
+   depends on CMD_SPL && SPL_NOR_SUPPORT
+   default 0
+   help
+ This provides the offset of the command line arguments or dtb for
+ Linux when booting from NOR in Falcon mode.
+
 config CMD_SPL_WRITE_SIZE
hex "Size of argument area"
depends on CMD_SPL
-- 
2.11.0

___
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().

2019-05-16 Thread Christoph Müllner
Hi Kever,

sorry for the delay.
Will do within the next couple of days.

Thanks,
Christoph

On 09.05.19 12:46, Kever Yang wrote:
> 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] fs: fat: Fix possible double free of fatbuf

2019-05-16 Thread Andrew F. Davis
fat_itr_root() allocates fatbuf so we free it on the exit path, if
the function fails we should not free it, check the return value
and skip freeing if the function fails.

Signed-off-by: Andrew F. Davis 
---
 fs/fat/fat.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index c5997c2173..06c8ed14bd 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -1134,11 +1134,12 @@ int fat_size(const char *filename, loff_t *size)
 * expected to fail if passed a directory path:
 */
free(fsdata.fatbuf);
-   fat_itr_root(itr, &fsdata);
-   if (!fat_itr_resolve(itr, filename, TYPE_DIR)) {
+   ret = fat_itr_root(itr, &fsdata);
+   if (ret)
+   goto out_free_itr;
+   ret = fat_itr_resolve(itr, filename, TYPE_DIR);
+   if (!ret)
*size = 0;
-   ret = 0;
-   }
goto out_free_both;
}
 
-- 
2.17.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] U-Boot PXA support

2019-05-16 Thread Marcel Ziswiler
Hi Tom

On Mon, 2019-05-06 at 09:26 -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!

We are actually still shipping Colibri PXA270 modules for another one
or two years I believe after which Marvell stops selling us chips.

The strange thing is that I build U-Boot master more or less daily
without any known issues currently using the regular gcc 8.2 2019.01
tool chain from ARM.

The only issue is the missing DM_MMC and/or DM_USB conversion which I
started working on a long time ago but never came around properly
debugging. I may pick that one up tomorrow again.

Cheers

Marcel

> ___
> 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] U-Boot PXA support

2019-05-16 Thread Marek Vasut
On 5/16/19 4:53 PM, Marcel Ziswiler wrote:
> Hi Tom
> 
> On Mon, 2019-05-06 at 09:26 -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!
> 
> We are actually still shipping Colibri PXA270 modules for another one
> or two years I believe after which Marvell stops selling us chips.
> 
> The strange thing is that I build U-Boot master more or less daily
> without any known issues currently using the regular gcc 8.2 2019.01
> tool chain from ARM.
> 
> The only issue is the missing DM_MMC and/or DM_USB conversion which I
> started working on a long time ago but never came around properly
> debugging. I may pick that one up tomorrow again.

Would you like to co-maintain the PXA ? :)

-- 
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 1/1] pci: pci_mvebu: fix bus enumeration if some buses have empty slots

2019-05-16 Thread Marek Behún
Hi Mario, you are right. I shall send a new patch chaning pci_init to
use the _check functions after I test it.
Marek

On Wed, 15 May 2019 07:05:43 +0200
Mario Six  wrote:

> Hi Marek,
> 
> On Tue, May 14, 2019 at 5:12 PM Marek Behún 
> wrote:
> >
> > The documentation for the uclass_next_device says this:
> >
> >   @devp: On entry, pointer to device to lookup. On exit, returns
> > pointer to the next device in the uclass if no error occurred, or
> > NULL if there is no next device, or an error occurred with that
> > next device.
> >
> > But this is useless, because if an error occured with that next
> > device, the iteration stops and devices which should work won't be
> > probed.  
> 
> The class_{first,next}_device_check functions do exactly what you
> need: They skip the devices that won't probe and only return the ones
> that do probe.
> 
> Best regards,
> 
> Mario

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y

2019-05-16 Thread Matthias Brugger


On 30/04/2019 21:07, Heinrich Schuchardt wrote:
> On 4/30/19 4:53 AM, Eugeniu Rosca wrote:
>> The random uuid values (enabled via CONFIG_RANDOM_UUID=y) on our
>> platform are always the same. Below is consistent on each cold boot:
>>
>>   => ### interrupt autoboot
>>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
>>   ...
>>   uuid_gpt_misc=d117f98e-6f2c-d04b-a5b2-331a19f91cb2
>>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
>>   ...
>>   uuid_gpt_misc=ad5ec4b6-2d9f-8544-9417-fe3bd1c9b1b3
>>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
>>   ...
>>   uuid_gpt_misc=cceb0b18-39cb-d547-9db7-03b405fa77d4
>>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
>>   ...
>>   uuid_gpt_misc=d4981a2b-0478-544e-9607-7fd3c651068d
>>   => env default -a; gpt write mmc 1 $partitions; print uuid_gpt_misc
>>   ...
>>   uuid_gpt_misc=6d6c9a36-e919-264d-a9ee-bd00379686c7
>>
>> While the uuids do change on every 'gpt write' command, the values
>> appear to be taken from the same pool, in the same order.
>>
>> As a user, I expect a trully random uuid value in the above example.
>> Otherwise, system/RFS designers and OS people might assume they have
>> a reliable/consistent uuid passed by the bootloader, while the truth
>> is U-Boot simply lacks entropy to generate a random string.
>>
>> In its first attempt [1] to improve the uuid randomness, this patch
>> updated the seed based on the output of get_timer(), similar to [2].
>>
>> There are two problems with this approach:
>>   - get_timer() has a poor _ms_ resolution
>>   - when gen_rand_uuid() is called in a loop, get_timer() returns the
>>     same result, leading to the same seed being passed to srand(),
>>     leading to the same uuid being generated for several partitions
>>     with different names
>>
>> This second patch addresses both drawbacks.
>>
>> My R-Car3 testing [3] consists of running 'gpt write mmc 1 $partitions'
>> in a loop for several minutes collecting 8844 randomly generated UUIDS.
>> Two consecutive cold boots are concatenated in the log. As a result,
>> all uuid values are unique (scripted check).
>>
>> Thanks to Roman, who reported the issue and provided support in fixing.
>>
>> [1] https://patchwork.ozlabs.org/patch/1091802/
>> [2] commit da384a9d7628 ("net: rename and refactor eth_rand_ethaddr() 
>> function")
>> [3] https://gist.github.com/erosca/2820be9d554f76b982edd48474d0e7ca
>>   => while true; do \
>>  env default -a; \
>>  gpt write mmc 1 $partitions; \
>>  print; done
>>
>> Reported-by: Roman Stratiienko 
>> Signed-off-by: Eugeniu Rosca 
> 
> This patch may ameliorate the situation for GUIDs a bit. But I dislike:
> 
> - This patch is a uuid only solution to introduce time ticks as source
>   of entropy.
> - With timer ticks you possibly introduce very little entropy.
> - Our random number generator with only 32 state bits remains
>   sub-standard.
> 
> This is the current situation:
> 
> net/bootp.c uses the MAC address to seed the random number generator and
> uses random numbers for defining waits.
> 
> lib/uuid.c is using it for UUID generation.
> 
> In the UEFI sub-system I would like to implement the EFI_RNG_PROTOCOL.
> Linux uses it for randomizing memory layout. iPXE needs it for secure
> network connections. This requires a good random number generator with
> sufficient entropy.
> 
> We already have implemented a single hardware random number generator in
> drivers/crypto/ace_sha.c (CONFIG_EXYNOS_ACE_SHA).
> 
> Many other CPUs come with a hardware random number generator. In Linux's
> drivers/char/hw_random/ I found, e.g.
> 
> - meson-rng.c (Amlogic)
> - mtk-rng.c (MediaTek)
> - st-rng.c (STMicroelectronics)
> - imx-rng.c (Freescale)
> 
> I think we should have a u-class for hardware RNGs as one source of entropy.
> 

Anyone working on this already? If not I can have a look. It could be used for
RPi3 as well (drivers/char/hw_random/bcm2835-rng.c in the Linux kernel). :)

Regards,
Matthias

> I would like a random number generator with a high number of state bits
> (> 127) that we initialize with hardware RNG bits and other sources of
> entropy. A nice discussion of how Linux does it can be found in [1].
> 
> Best regards
> 
> Heinrich
> 
> [1]
> https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Studies/LinuxRNG/LinuxRNG_EN.pdf
> 
> 
> 
>> ---
>> v2:
>>   - Replaced get_timer(0) with get_ticks() and added rand() to seed value
>>   - Performed extensive testing on R-Car3 (ARMv8)
>> v1:
>>   - https://patchwork.ozlabs.org/patch/1091802/
>> ---
>>   lib/uuid.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/lib/uuid.c b/lib/uuid.c
>> index fa20ee39fc32..2d4d6ef7e461 100644
>> --- a/lib/uuid.c
>> +++ b/lib/uuid.c
>> @@ -238,6 +238,8 @@ void gen_rand_uuid(unsigned char *uuid_bin)
>>   unsigned int *ptr = (unsigned int *)&uuid;
>>   int i;
>>
>> +    srand(get_ticks() + rand());
>> +
>>   /* Set al

[U-Boot] [PATCH] board/BuR: invalidate ${dtbaddr} before cfgscr

2019-05-16 Thread Hannes Schmelzer
From: Hannes Schmelzer 

The first memory location of ${dtbaddr} may be still valid after a warm
restart of the machine and 'fdt addr ${dtbaddr}' doesn't recognize that
the cfgscript didn't run properly and fallback mechanism with copying
the internal fdt ${fdtcontroladdr} to ${dtbaddr} doesn't catch this.

To get sure that we have proper failsafe behaviour we simply zero the
first memory location of ${dtbaddr} for getting sure that the fdt is
invalid if cfgscript didn't run.

Signed-off-by: Hannes Schmelzer 

Signed-off-by: Hannes Schmelzer 
---

 include/configs/brppt1.h | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/include/configs/brppt1.h b/include/configs/brppt1.h
index 51af93a..82f3f1a 100644
--- a/include/configs/brppt1.h
+++ b/include/configs/brppt1.h
@@ -66,7 +66,8 @@
 #define NANDTGTS \
 "mtdids=" CONFIG_MTDIDS_DEFAULT "\0" \
 "mtdparts=" CONFIG_MTDPARTS_DEFAULT "\0" \
-"cfgscr=nand read ${cfgaddr} cfgscr && source ${cfgaddr}\0" \
+"cfgscr=mw ${dtbaddr} 0; nand read ${cfgaddr} cfgscr && source ${cfgaddr};" \
+" fdt addr ${dtbaddr} || cp ${fdtcontroladdr} ${dtbaddr} 4000\0" \
 "nandargs=setenv bootargs console=${console} ${optargs} ${optargs_rot} " \
"root=mtd6 rootfstype=jffs2 b_mode=${b_mode}\0" \
 "b_nand=nand read ${loadaddr} kernel; nand read ${dtbaddr} dtb; " \
@@ -104,7 +105,9 @@
 #ifdef CONFIG_ENV_IS_IN_MMC
 #define MMCTGTS \
 MMCSPI_TGTS \
-"cfgscr=mmc dev 1; mmc read ${cfgaddr} 200 80; source ${cfgaddr}\0"
+"cfgscr=mw ${dtbaddr} 0;" \
+" mmc dev 1; mmc read ${cfgaddr} 200 80; source ${cfgaddr};" \
+" fdt addr ${dtbaddr} || cp ${fdtcontroladdr} ${dtbaddr} 4000\0"
 #else
 #define MMCTGTS ""
 #endif /* CONFIG_MMC */
@@ -112,7 +115,9 @@ MMCSPI_TGTS \
 #ifdef CONFIG_SPI
 #define SPITGTS \
 MMCSPI_TGTS \
-"cfgscr=sf probe; sf read ${cfgaddr} 0xC 1; source ${cfgaddr}\0"
+"cfgscr=mw ${dtbaddr} 0;" \
+" sf probe; sf read ${cfgaddr} 0xC 1; source ${cfgaddr};" \
+" fdt addr ${dtbaddr} || cp ${fdtcontroladdr} ${dtbaddr} 4000\0"
 #else
 #define SPITGTS ""
 #endif /* CONFIG_SPI */
-- 
2.7.4

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Raspberry Pi's MAC address locked to the first device the SD card boots on

2019-05-16 Thread Matthias Brugger


On 03/05/2019 01:07, Timothy Froehlich wrote:
> We've had a problem the past few days that we've traced back to U-Boot.
> We're generating images using Yocto with Mender's update routine. The issue
> is the first time a clean image is booted on a Raspberry Pi, the mac
> address gets permanently saved to the ethaddr env variable. It's a
> combination of this line:
> 
> https://github.com/u-boot/u-boot/blob/b4ee6daad7a2604ca9466b2ba48de86cc27d381f/board/raspberrypi/rpi/rpi.c#L348
> 
> and what I'm pretty sure is Mender doing a "saveenv" on first boot. If you
> move the SD card to a different Raspberry Pi, it will boot up with the mac
> address of the first Raspberry Pi.
> 

What you would need to do is, delete ethaddr before booting on a different
board. I suppose your problem is, that you want to use the same image on
different boards and find yourself with the same address. Correct?

> I'm not sure what the best long-term solution will be but I can make a
> patch for my purposes to just always set ethaddr to usbethaddr.
> 
Well that would omit the possibility to use other MAC addresses then the one in
the RPi firmware.

Regards,
Matthias

> So I guess i'm emailing this in to report an issue and maybe help anyone
> else who runs into this issue.
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH 04/13] arm: K3: Introduce System Firmware loader framework

2019-05-16 Thread Andreas Dannenberg
Hi Tom,

On Wed, May 15, 2019 at 05:50:31PM -0400, Tom Rini wrote:
> On Wed, May 15, 2019 at 04:39:22PM -0500, Andreas Dannenberg wrote:
> > Hi Tom,
> > 
> > On Wed, May 15, 2019 at 11:17:22AM -0400, Tom Rini wrote:
> > > On Tue, May 07, 2019 at 12:25:33PM -0500, Andreas Dannenberg wrote:
> > > 
> > > > Introduce a framework that allows loading the System Firmware (SYSFW)
> > > > binary as well as the associated configuration data from an image tree
> > > > blob named "sysfw.itb" from an FS-based MMC boot media or from an MMC
> > > > RAW mode partition or sector.
> > > > 
> > > > To simplify the handling of and loading from the different boot media
> > > > we tap into the existing U-Boot SPL framework usually used for loading
> > > > U-Boot by building on an earlier commit that exposes some of that
> > > > functionality.
> > > > 
> > > > Note that this initial implementation only supports FS and RAW-based
> > > > eMMC/SD card boot.
> > > [snip]
> > > > diff --git a/arch/arm/mach-k3/Kconfig b/arch/arm/mach-k3/Kconfig
> > > > index e677a2e01b..f1731dda58 100644
> > > > --- a/arch/arm/mach-k3/Kconfig
> > > > +++ b/arch/arm/mach-k3/Kconfig
> > > > @@ -58,6 +58,46 @@ config SYS_K3_BOOT_CORE_ID
> > > > int
> > > > default 16
> > > >  
> > > > +config K3_LOAD_SYSFW
> > > > +   bool
> > > > +   depends on SPL
> > > > +   default n
> > > 
> > > 'n' is already default, you can drop this.
> > 
> > Ok sure.
> > 
> > > 
> > > [snip]
> > > > +config K3_SYSFW_IMAGE_SIZE_MAX
> > > > +   int "Amount of memory dynamically allocated for loading SYSFW 
> > > > blob"
> > > > +   depends on K3_LOAD_SYSFW
> > > > +   default 269000
> > > > +   help
> > > > + Amount of memory reserved through dynamic allocation at 
> > > > runtime for
> > > > + loading the combined System Firmware and configuration image 
> > > > tree
> > > > + blob. Keep it as tight as possible, as this directly affects 
> > > > the
> > > > + overall SPL memory footprint.
> > > 
> > > This is missing a unit, and is 'int' really the best choice here (and
> > > really, I guess, 262.6KiB as a default) ?

I think 'int' is a more natural fit as this is to reserve memory for the
'sysfw.itb' blob we load from media. This blob is build outside U-Boot
using the "System Firmware Image Generator" project [1], and if after
build somebody does an 'll' in the build directory the file size would
show up as decimal, and that's what needs to fit inside
K3_SYSFW_IMAGE_SIZE_MAX.

> > Will add a unit.
> > 
> > As for the specific value, in our R5 SPL memory is very very tight. The
> > value used here is basically used for a malloc(), and any extra byte
> > allocated will be "wasted" and not available for stack etc. Also our
> > SYSFW image that is loaded is fixed size (except some +/-100 odd bytes
> > if the configuration data is changed that's part of the same SYSFW.ITB
> > blob), so a rather tailored size makes sense here.
> 
> Right, that makes sense.  But how did you get to that
> not-exactly-"round" number rather than say 0x41A00 or some other
> slightly smaller value in hex?  If 0x41AC8 is right, then, OK, it's
> right.  It just seems strange at first.

The sysfw.itb blob consumed by the SYSFW loader comprises a fixed
component (the SYSFW itself), plus a few smaller chunks of variable data
containing user configuration data. During initial development the
combined size of this ITB was about 264,900 bytes, and 4KB was added as
slack to accommodate configuration changes, resulting in what looks like
the arbitrary number under discussion. The sysfw.itb blob has actually
since grown in size but there is still plenty of space for it to further
grow if needed. Since we use this value already in production since last
year with no issues I'd rather leave it alone (due to using stack based
malloc in R5 SPL increasing that value would directly decrease available
stack space with our R5 SPL memory layout where the stack is growing
down towards the R5 SPL image itself).

> > > [snip]
> > > > diff --git a/arch/arm/mach-k3/Makefile b/arch/arm/mach-k3/Makefile
> > > > index 0c3a4f7db1..6c895400c2 100644
> > > > --- a/arch/arm/mach-k3/Makefile
> > > > +++ b/arch/arm/mach-k3/Makefile
> > > > @@ -7,4 +7,5 @@ obj-$(CONFIG_SOC_K3_AM6) += am6_init.o
> > > >  obj-$(CONFIG_ARM64) += arm64-mmu.o
> > > >  obj-$(CONFIG_CPU_V7R) += r5_mpu.o lowlevel_init.o
> > > >  obj-$(CONFIG_TI_SECURE_DEVICE) += security.o
> > > > +obj-$(CONFIG_K3_LOAD_SYSFW) += sysfw-loader.o
> > > >  obj-y += common.o
> > > [snip]
> > > > diff --git a/arch/arm/mach-k3/sysfw-loader.c 
> > > > b/arch/arm/mach-k3/sysfw-loader.c
> > > > new file mode 100644
> > > > index 00..a66c27
> > > > --- /dev/null
> > > > +++ b/arch/arm/mach-k3/sysfw-loader.c
> > > > @@ -0,0 +1,263 @@
> > > [snip]
> > > > +#ifdef CONFIG_SPL_BUILD
> > > [snip of the whole body of the file]
> > > > +#endif
> > > 
> > > We should be using something else in the Makefile, typicall

Re: [U-Boot] [PATCH 4/4] lib: uuid: Improve randomness of uuid values on RANDOM_UUID=y

2019-05-16 Thread Eugeniu Rosca
On Thu, May 16, 2019 at 5:14 PM Matthias Brugger  wrote:
> On 30/04/2019 21:07, Heinrich Schuchardt wrote:
> >
> > I think we should have a u-class for hardware RNGs as one source of entropy.
>
> Anyone working on this already?

Not me.

> If not I can have a look.

green_light_on(); // :)

> It could be used for
> RPi3 as well (drivers/char/hw_random/bcm2835-rng.c in the Linux kernel). :)
>
> Regards,
> Matthias

-- 
Regards,
Eugeniu.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH] tpm: wait for valid status

2019-05-16 Thread Roman Kapl
The TPM specification says that the EXPECT_DATA bit is not valid until
the VALID bit is set. Wait for that bit to be set. Fixes problems with
Ifineon SPI TPM.

Signed-off-by: Roman Kapl 
---
 drivers/tpm/tpm2_tis_spi.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/tpm/tpm2_tis_spi.c b/drivers/tpm/tpm2_tis_spi.c
index 8878130bd7..7186c179d1 100644
--- a/drivers/tpm/tpm2_tis_spi.c
+++ b/drivers/tpm/tpm2_tis_spi.c
@@ -295,6 +295,14 @@ static int tpm_tis_spi_wait_for_stat(struct udevice *dev, 
u8 mask,
return -ETIMEDOUT;
 }
 
+static u8 tpm_tis_spi_valid_status(struct udevice *dev, u8 *status)
+{
+   struct tpm_chip *chip = dev_get_priv(dev);
+
+   return tpm_tis_spi_wait_for_stat(dev, TPM_STS_VALID,
+   chip->timeout_c, status);
+}
+
 static int tpm_tis_spi_get_burstcount(struct udevice *dev)
 {
struct tpm_chip *chip = dev_get_priv(dev);
@@ -455,7 +463,7 @@ static int tpm_tis_spi_send(struct udevice *dev, const u8 
*buf, size_t len)
i += size;
}
 
-   ret = tpm_tis_spi_status(dev, &status);
+   ret = tpm_tis_spi_valid_status(dev, &status);
if (ret)
goto out_err;
 
@@ -469,7 +477,7 @@ static int tpm_tis_spi_send(struct udevice *dev, const u8 
*buf, size_t len)
if (ret)
goto out_err;
 
-   ret = tpm_tis_spi_status(dev, &status);
+   ret = tpm_tis_spi_valid_status(dev, &status);
if (ret)
goto out_err;
 
-- 
2.20.1.390.gb5101f9297

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC/RESEND 01/22] arm: introduce ARCH_THUNDERX

2019-05-16 Thread Suneel Garapati
Hi Tim,

Missed aggressive timeline, first RFC series should be out in three weeks
time as priority.

Regards,
Suneel


On Tue, May 7, 2019 at 8:10 AM Tim Harvey  wrote:
>
> On Fri, Mar 22, 2019 at 11:23 AM Suneel Garapati 
wrote:
> >
> > Hi Tim,
> >
> > First series will be out week ending April 20th.
> >
> > Regards,
> > Suneel
>
> Suneel,
>
> Any update on a Marvell submitted/maintained patch series for Octeon-TX
support?
>
> Best Regards,
>
> Tim
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

2019-05-16 Thread Fabio Estevam
Hi,

I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:

U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
Trying to boot from MMC1
spl: could not find mmc device 0. error: -19
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I haven't debugged this yet.

Does anyone have any ideas?

Thanks,

Fabio Estevam
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 0/2] efi_loader: implement deprecated Unicode collation protocol

2019-05-16 Thread Heinrich Schuchardt
In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2
language codes existed. This protocol is not part of the UEFI specification
any longer. Unfortunately it is required to run the UEFI Self Certification
Test (SCT) II, version 2.6, 2017. So we implement it here for the sole
purpose of running the SCT. It can be removed once a compliant SCT is
available.

The configuration option defaults to no.

Heinrich Schuchardt (2):
  efi_loader: rename Unicode collation protocol 2 variables
  efi_loader: implement deprecated Unicode collation protocol

 include/efi_api.h  |  5 
 include/efi_loader.h   |  9 +--
 lib/efi_loader/Kconfig | 15 ++--
 lib/efi_loader/Makefile|  2 +-
 lib/efi_loader/efi_root_node.c |  7 +-
 lib/efi_loader/efi_unicode_collation.c | 33 +++---
 lib/efi_selftest/Makefile  |  3 ++-
 7 files changed, 64 insertions(+), 10 deletions(-)

--
2.20.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH 1/2] efi_loader: rename Unicode collation protocol 2 variables

2019-05-16 Thread Heinrich Schuchardt
Rename variables to make it clear they refer to the Unicode collation
protocol identified by the EFI_UNICODE_PROTOCOL2_GUID.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_loader.h   | 4 ++--
 lib/efi_loader/Kconfig | 4 ++--
 lib/efi_loader/Makefile| 2 +-
 lib/efi_loader/efi_root_node.c | 6 +++---
 lib/efi_loader/efi_unicode_collation.c | 6 +++---
 lib/efi_selftest/Makefile  | 3 ++-
 6 files changed, 13 insertions(+), 12 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 07ef14ba1c..835007e179 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -108,7 +108,7 @@ extern const struct efi_device_path_utilities_protocol
efi_device_path_utilities;
 /* Implementation of the EFI_UNICODE_COLLATION_PROTOCOL */
 extern const struct efi_unicode_collation_protocol
-   efi_unicode_collation_protocol;
+   efi_unicode_collation_protocol2;
 extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
 extern const struct efi_hii_config_access_protocol efi_hii_config_access;
 extern const struct efi_hii_database_protocol efi_hii_database;
@@ -146,7 +146,7 @@ extern const efi_guid_t efi_file_info_guid;
 extern const efi_guid_t efi_file_system_info_guid;
 extern const efi_guid_t efi_guid_device_path_utilities_protocol;
 /* GUID of the Unicode collation protocol */
-extern const efi_guid_t efi_guid_unicode_collation_protocol;
+extern const efi_guid_t efi_guid_unicode_collation_protocol2;
 extern const efi_guid_t efi_guid_hii_config_routing_protocol;
 extern const efi_guid_t efi_guid_hii_config_access_protocol;
 extern const efi_guid_t efi_guid_hii_database_protocol;
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 6501ee56aa..7e13ee54b2 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -36,14 +36,14 @@ config EFI_LOADER_HII
  U-Boot implements enough of its features to be able to run the UEFI
  Shell, but not more than that.

-config EFI_UNICODE_COLLATION_PROTOCOL
+config EFI_UNICODE_COLLATION_PROTOCOL2
bool "Unicode collation protocol"
default y
help
  The Unicode collation protocol is used for lexical comparisons. It is
  required to run the UEFI shell.

-if EFI_UNICODE_COLLATION_PROTOCOL
+if EFI_UNICODE_COLLATION_PROTOCOL2

 config EFI_UNICODE_CAPITALIZATION
bool "Support Unicode capitalization"
diff --git a/lib/efi_loader/Makefile b/lib/efi_loader/Makefile
index f3d6773bf6..01769ea58b 100644
--- a/lib/efi_loader/Makefile
+++ b/lib/efi_loader/Makefile
@@ -30,7 +30,7 @@ obj-y += efi_memory.o
 obj-y += efi_root_node.o
 obj-y += efi_runtime.o
 obj-y += efi_setup.o
-obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL) += efi_unicode_collation.o
+obj-$(CONFIG_EFI_UNICODE_COLLATION_PROTOCOL2) += efi_unicode_collation.o
 obj-y += efi_variable.o
 obj-y += efi_watchdog.o
 obj-$(CONFIG_LCD) += efi_gop.o
diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c
index d8496cc3c2..2b7277de05 100644
--- a/lib/efi_loader/efi_root_node.c
+++ b/lib/efi_loader/efi_root_node.c
@@ -60,10 +60,10 @@ efi_status_t efi_root_node_register(void)
 /* Device path utilities protocol */
 &efi_guid_device_path_utilities_protocol,
 (void *)&efi_device_path_utilities,
-#if CONFIG_IS_ENABLED(EFI_UNICODE_COLLATION_PROTOCOL)
+#if CONFIG_IS_ENABLED(EFI_UNICODE_COLLATION_PROTOCOL2)
 /* Unicode collation protocol */
-&efi_guid_unicode_collation_protocol,
-(void *)&efi_unicode_collation_protocol,
+&efi_guid_unicode_collation_protocol2,
+(void *)&efi_unicode_collation_protocol2,
 #endif
 #if CONFIG_IS_ENABLED(EFI_LOADER_HII)
 /* HII string protocol */
diff --git a/lib/efi_loader/efi_unicode_collation.c 
b/lib/efi_loader/efi_unicode_collation.c
index 7f3ea3c77e..e04a4de5b7 100644
--- a/lib/efi_loader/efi_unicode_collation.c
+++ b/lib/efi_loader/efi_unicode_collation.c
@@ -26,8 +26,8 @@ static const u16 codepage[] = CP1250;
 static const u16 codepage[] = CP437;
 #endif

-/* GUID of the EFI_UNICODE_COLLATION_PROTOCOL */
-const efi_guid_t efi_guid_unicode_collation_protocol =
+/* GUID of the EFI_UNICODE_COLLATION_PROTOCOL2 */
+const efi_guid_t efi_guid_unicode_collation_protocol2 =
EFI_UNICODE_COLLATION_PROTOCOL2_GUID;

 /**
@@ -318,7 +318,7 @@ static bool EFIAPI efi_str_to_fat(struct 
efi_unicode_collation_protocol *this,
return ret;
 }

-const struct efi_unicode_collation_protocol efi_unicode_collation_protocol = {
+const struct efi_unicode_collation_protocol efi_unicode_collation_protocol2 = {
.stri_coll = efi_stri_coll,
.metai_match = efi_metai_match,
.str_lwr = efi_str

[U-Boot] [PATCH 2/2] efi_loader: implement deprecated Unicode collation protocol

2019-05-16 Thread Heinrich Schuchardt
In EFI 1.10 a version of the Unicode collation protocol using ISO 639-2
language codes existed. This protocol is not part of the UEFI specification
any longer. Unfortunately it is required to run the UEFI Self Certification
Test (SCT) II, version 2.6, 2017. So we implement it here for the sole
purpose of running the SCT. It can be removed once a compliant SCT is
available.

The configuration option defaults to no.

Signed-off-by: Rob Clark 

Most of Rob's original patch is already merged. Only the deprecated
protocol is missing. Rebase it and make it configurable.

Signed-off-by: Heinrich Schuchardt 
---
 include/efi_api.h  |  5 +
 include/efi_loader.h   |  7 ++-
 lib/efi_loader/Kconfig | 11 +++
 lib/efi_loader/efi_root_node.c |  7 ++-
 lib/efi_loader/efi_unicode_collation.c | 27 ++
 5 files changed, 55 insertions(+), 2 deletions(-)

diff --git a/include/efi_api.h b/include/efi_api.h
index 755c405793..7dcd82b681 100644
--- a/include/efi_api.h
+++ b/include/efi_api.h
@@ -1425,6 +1425,11 @@ struct efi_driver_binding_protocol {
efi_handle_t driver_binding_handle;
 };

+/* Deprecated version of the Unicode collation protocol */
+#define EFI_UNICODE_COLLATION_PROTOCOL_GUID \
+   EFI_GUID(0x1d85cd7f, 0xf43d, 0x11d2, \
+0x9a, 0x0c, 0x00, 0x90, 0x27, 0x3f, 0xc1, 0x4d)
+/* Current version of the Unicode collation protocol */
 #define EFI_UNICODE_COLLATION_PROTOCOL2_GUID \
EFI_GUID(0xa4c751fc, 0x23ae, 0x4c3e, \
 0x92, 0xe9, 0x49, 0x64, 0xcf, 0x63, 0xf3, 0x49)
diff --git a/include/efi_loader.h b/include/efi_loader.h
index 835007e179..8167e6ffcb 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -106,7 +106,10 @@ extern const struct efi_device_path_to_text_protocol 
efi_device_path_to_text;
 /* implementation of the EFI_DEVICE_PATH_UTILITIES_PROTOCOL */
 extern const struct efi_device_path_utilities_protocol
efi_device_path_utilities;
-/* Implementation of the EFI_UNICODE_COLLATION_PROTOCOL */
+/* deprecated version of the EFI_UNICODE_COLLATION_PROTOCOL */
+extern const struct efi_unicode_collation_protocol
+   efi_unicode_collation_protocol;
+/* current version of the EFI_UNICODE_COLLATION_PROTOCOL */
 extern const struct efi_unicode_collation_protocol
efi_unicode_collation_protocol2;
 extern const struct efi_hii_config_routing_protocol efi_hii_config_routing;
@@ -145,6 +148,8 @@ extern const efi_guid_t efi_file_info_guid;
 /* GUID for file system information */
 extern const efi_guid_t efi_file_system_info_guid;
 extern const efi_guid_t efi_guid_device_path_utilities_protocol;
+/* GUID of the deprecated Unicode collation protocol */
+extern const efi_guid_t efi_guid_unicode_collation_protocol;
 /* GUID of the Unicode collation protocol */
 extern const efi_guid_t efi_guid_unicode_collation_protocol2;
 extern const efi_guid_t efi_guid_hii_config_routing_protocol;
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 7e13ee54b2..fc04ea39d0 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -54,6 +54,17 @@ config EFI_UNICODE_CAPITALIZATION
  set, only the the correct handling of the letters of the codepage
  used by the FAT file system is ensured.

+config EFI_UNICODE_COLLATION_PROTOCOL
+   bool "Deprecated version of the Unicode collation protocol"
+   default n
+   help
+ In EFI 1.10 a version of the Unicode collation protocol using ISO
+ 639-2 language codes existed. This protocol is not part of the UEFI
+ specification any longer. Unfortunately it is required to run the
+ UEFI Self Certification Test (SCT) II, version 2.6, 2017.
+
+ Choose this option for testing only. It is bound to be removed.
+
 endif

 config EFI_LOADER_BOUNCE_BUFFER
diff --git a/lib/efi_loader/efi_root_node.c b/lib/efi_loader/efi_root_node.c
index 2b7277de05..f68b0fdc61 100644
--- a/lib/efi_loader/efi_root_node.c
+++ b/lib/efi_loader/efi_root_node.c
@@ -61,7 +61,12 @@ efi_status_t efi_root_node_register(void)
 &efi_guid_device_path_utilities_protocol,
 (void *)&efi_device_path_utilities,
 #if CONFIG_IS_ENABLED(EFI_UNICODE_COLLATION_PROTOCOL2)
-/* Unicode collation protocol */
+#if CONFIG_IS_ENABLED(EFI_UNICODE_COLLATION_PROTOCOL)
+/* Deprecated Unicode collation protocol */
+&efi_guid_unicode_collation_protocol,
+(void *)&efi_unicode_collation_protocol,
+#endif
+/* Current Unicode collation protocol */
 &efi_guid_unicode_collation_protocol2,
 (void *)&efi_unicode_collation_protocol2,
 #endif
diff --git a/lib/efi_loader/efi_unicode_collation.c 
b/lib/efi_lo

Re: [U-Boot] Cannot boot mx6qsabred with 2019.07-rc2

2019-05-16 Thread Jagan Teki
On Thu, May 16, 2019 at 11:02 PM Fabio Estevam  wrote:
>
> Hi,
>
> I get the following error when trying to boot mx6q sabresd with 2019.07-rc2:
>
> U-Boot SPL 2019.07-rc2 (May 16 2019 - 14:28:55 -0300)
> Trying to boot from MMC1
> spl: could not find mmc device 0. error: -19

No device.

Is it DM-SPL-enabled? check with u-boot,dm-spl on associated nodes?

usdhc3 is  for sabresd, seems like gpio2 missing to add u-boot,dm-spl
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] U-Boot PXA support

2019-05-16 Thread Tom Rini
On Thu, May 16, 2019 at 02:53:55PM +, Marcel Ziswiler wrote:
> Hi Tom
> 
> On Mon, 2019-05-06 at 09:26 -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!
> 
> We are actually still shipping Colibri PXA270 modules for another one
> or two years I believe after which Marvell stops selling us chips.
> 
> The strange thing is that I build U-Boot master more or less daily
> without any known issues currently using the regular gcc 8.2 2019.01
> tool chain from ARM.

Oh, that is interesting.  The failure that triggers this comes from
https://cdn.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-arm-linux-gnueabi.tar.xz

Can you point me at the gcc-8.2 toolchain you're talking about please?
Thanks!

-- 
Tom


signature.asc
Description: PGP signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Regarding usage of e1000 driver with our device tree in U-boot.

2019-05-16 Thread Terry Thiburcius
I have accustom hardware uses IMX6q which has a intel i210 ethernet controller 
connected to PCIE of IMX6Q , I had configured the PCIE in Kernel and enabled 
the e1000 driver , I am able to enumerate the controller ping works fine, etc.
whereas when I try to configure the controller and PCIE in UBoot, I see PCI 
driver listing the devices but the ethernet controller is not seen in the 
"NET:" looks like the e1000 driver is not getting linked to built-in.o
 Can someone help me with the correct configuration of the uboot for PCIE and 
e1000. (I am not using driver model, I am configuring my 2017 in the legacy way.
 Below is my Uboot log
 U-Boot 2017.03 (May 14 2019 - 14:22:34 -0700)
CPU:   Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU:   Automotive temperature grade (-40C to 125C) at 55C
Reset cause: POR
Board: iMX6q Sbare-SD
I2C:   ready
DRAM:  2 GiB
spi setup
 i2C INIT :
PMIC:  PFUZE100 ID=0x10
MMC:   FSL_SDHC: 0, FSL_SDHC: 1, FSL_SDHC: 2
*** Warning - bad CRC, using default environment
PCI:
  00:01.0 - 16c3:abcd - Bridge device
   01:00.0- 8086:1533 - Network controller
No panel detected: default to Hannstar-XGA
Display: Hannstar-XGA (1024x768)
In:serial
Out:   serial
Err:   serial
switch to partitions #0, OK
mmc0 is current device
Net:   FEC
Normal Boot
Hit any key to stop autoboot:  0
=> pci
Scanning PCI devices on bus 0
BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
_
00.01.00   0x16c3 0xabcd Bridge device   0x04
Cannot read bus configuration: -1
=> pci 1
Scanning PCI devices on bus 1
BusDevFun  VendorId   DeviceId   Device Class   Sub-Class
_
01.00.00   0x8086 0x1533 Network controller  0x00
Cannot read bus configuration: -1
 => pci header 1
  vendor ID =   0x16c3
  device ID =   0xabcd
  command register ID = 0x0007
  status register = 0x0010
  revision ID = 0x01
  class code =  0x06 (Bridge device)
  sub class code =  0x04
  programming interface =   0x00
  cache line =  0x08
  latency time =0x00
  header type = 0x01
  BIST =0x00
  base address 0 =  0x0100
  base address 1 =  0x
  primary bus number =  0x00
  secondary bus number =0x01
  subordinate bus number =  0x01
  secondary latency timer = 0x00
  IO base = 0x00
  IO limit =0x00
  secondary status =0x
  memory base = 0x0120
  memory limit =0x0120
  prefetch memory base =0x1000
  prefetch memory limit =   0x
  prefetch memory base upper =  0x
  prefetch memory limit upper = 0x
  IO base upper 16 bits =   0x
  IO limit upper 16 bits =  0x
  expansion ROM base address =  0x0110
  interrupt line =  0xff
  interrupt pin =   0x01
  bridge control =  0x

Thanks and Regards
Terry






Statement Of Confidentiality:

This electronic message transmission, and all attachments, contains information 
from Extron Electronics which is confidential and privileged. The information 
is for the exclusive viewing or use of the intended recipient. If you are not 
the intended recipient, be aware that any disclosure, copying, distribution or 
use of the contents of this information is prohibited. If you have received 
this electronic transmission in error, please notify the sender immediately by 
a "reply to sender only" message and destroy all electronic and hard copies of 
the communication, including attachments.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [RFC PATCH] arm: zynqmp: Add ZynqMP minimal R5 support

2019-05-16 Thread Evangelista, Daniel
Hello,

I have recently been investigating u-boot for booting VxWorks on to the APU and 
an RPU core of a ZU+ ZCU102 Rev1.1. For some general context, it would be ideal 
if it were possible to run u-boot on an RPU core to boot VxWorks on to the APU 
and RPU, instead of running u-boot on the APU.

I came across this post (by Michal Simek at xilinx.com) describing minimal 
support for the R5 which was tested on a ZCU100 Rev C. I compiled and ran the 
u-boot source with the R5 defconfig, however was not able to get it to run when 
programmed on to the ZCU102 (no serial data, R5 program counter cycling between 
0x0, 0x2, 0x4...0xC, 0x0...). To program it, I placed the binary in memory over 
JTAG and commanded the CPU to jump to the address (I tried 0x0, 0x100, and 
0x200 based on the R5 defconfig CONFIG_SYS_TEXT_BASE= 0x1000).

Can you provide any insight as to why this may be and what I can try to fix it? 
I also noticed that this post specifically mentions using a u-boot.elf, but 
when I compile the u-boot source a u-boot.elf is not generated, only a 
u-boot.bin which is what I tried and failed to get working. I suspect there 
will be more work to be able to boot VxWorks on both processors, but simply 
having u-boot run would be a great first step.

Thank you,

Dan Evangelista


___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


  1   2   >