Re: [U-Boot] [PATCH v3] libfdt: Introduce new ARCH_FIXUP_FDT option

[Michal Simek]

On 1.8.2016 03:03, Simon Glass wrote:
> On 28 July 2016 at 01:06, Michal Simek  wrote:
>> Add new Kconfig option to disable arch_fixup_fdt() calls for cases where
>> U-Boot shouldn't update memory setup in DTB file.
>> One example of usage of this option is to boot OS with different memory
>> setup than U-Boot use.
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>> Changes in v3:
>> - Fix MIPS macro
>>
>> Changes in v2:
>> - Change logic to be possitive - sjg
>>
>>  Kconfig  | 9 +
>>  arch/arm/lib/bootm-fdt.c | 2 ++
>>  arch/arm/lib/bootm.c | 2 ++
>>  arch/mips/lib/bootm.c| 2 ++
>>  common/image-fdt.c   | 7 ++-
>>  5 files changed, 17 insertions(+), 5 deletions(-)
> 
> Acked-by: Simon Glass 
> 

I have to send PR with xilinx changes to fix others critical issues
that's why I would include this to my PR.
I expect that this should be fine for you.

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] libfdt: Introduce new ARCH_FIXUP_FDT option

[Simon Glass]

On 28 July 2016 at 01:06, Michal Simek  wrote:
> Add new Kconfig option to disable arch_fixup_fdt() calls for cases where
> U-Boot shouldn't update memory setup in DTB file.
> One example of usage of this option is to boot OS with different memory
> setup than U-Boot use.
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v3:
> - Fix MIPS macro
>
> Changes in v2:
> - Change logic to be possitive - sjg
>
>  Kconfig  | 9 +
>  arch/arm/lib/bootm-fdt.c | 2 ++
>  arch/arm/lib/bootm.c | 2 ++
>  arch/mips/lib/bootm.c| 2 ++
>  common/image-fdt.c   | 7 ++-
>  5 files changed, 17 insertions(+), 5 deletions(-)

Acked-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] u-boot-imx: watchdog driver always asserts WDOG1_B?

[Ross Parker]

I've been hardening up hardware watchdog support on our custom i.MX6q based
boards and think I have found a bug in the U-Boot imx watchdog driver
(imx_watchdog.c).

Currently in the function hw_watchdog_init(), the watchdog control register
bits are explicitly initialised as follows:

writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS |
SET_WCR_WT(timeout), &wdog->wcr);

Bit WCR_WDA (bit 5; 0x20) is not mentioned and is therefore set to zero.

The function of that bit is:

"WDA: WDOG_B assertion. Controls the software assertion of the WDOG_B
signal.
0 = Assert WDOG_B output.
1 = No effect on system (Default)."

[Ref. i.MX 6Dual/6Quad Applications Processor Reference Manual, Rev. 3,
07/2015, p5791].

Furthermore:

"70.5.6.2 WDOG_B generation
The WDOG asserts WDOG_B in the following scenarios:
- Software write to WDA bit of Watchdog Control Register (WDOG_WCR).
WDOG_B signal remains asserted as long as the WDA bit is '0'.
..."

[Ref. i.MX 6Dual/6Quad Applications Processor Reference Manual, Rev. 3,
07/2015, p5785]

Sure enough, on my board I'm seeing WDOG1_B being permanently asserted as
soon as that line is executed.

I think that line should be:

writew(WCR_WDZST | WCR_WDBG | WCR_WDE | WCR_WDT | WCR_SRS |
*WCR_WDA |* SET_WCR_WT(timeout), &wdog->wcr);

(And obviously WCR_WDA needs to be defined in "include/fsl_wdog.h".)

Once I made that change, WDOG1_B is no longer asserted when that line is
run and behaves as I expect - i.e. WDOG1_B is asserted when the watchdog
actually fires.

Do others agree - am I on the right track?

If so, should I submit a patch? (Something I have never done before and
should learn how to do...)

Regards,
Ross Parker.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM64: zynqmp: Do not enable DM_MMC by default

[Michal Simek]

The patch:
"dm: mmc: zynq: Convert zynq to use driver model for MMC"
(sha1: 329a449f2c289b4de8f892fca1d9379ce5fd81b8)
added dependency on enabling some MMC options by default.
There are minimal ZynqMP configurations which require
only minimal configurations to be enabled to keep u-boot size
as lower as possible.

Move options to defconfig instead.

Signed-off-by: Michal Simek 
---

 arch/arm/Kconfig | 3 ---
 configs/xilinx_zynqmp_ep_defconfig   | 2 ++
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 2 ++
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 2 ++
 configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 2 ++
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 2 ++
 configs/xilinx_zynqmp_zcu102_defconfig   | 2 ++
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 2 ++
 8 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6de734f8f20f..a0a866ef4864 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -675,9 +675,6 @@ config ARCH_ZYNQMP
select CLK
select SPL_CLK
select DM_USB if USB
-   select DM_MMC
-   select DM_MMC_OPS
-   select BLK
 
 config TEGRA
bool "NVIDIA Tegra"
diff --git a/configs/xilinx_zynqmp_ep_defconfig 
b/configs/xilinx_zynqmp_ep_defconfig
index b6dee51ff124..a0eb374235a7 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -46,9 +46,11 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_NAND_ARASAN=y
 CONFIG_SPI_FLASH=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index 0700ec24ede6..52eb8c9329c8 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -37,9 +37,11 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
index afcae994874b..928806b2c42c 100644
--- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
@@ -37,9 +37,11 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
 CONFIG_NAND_ARASAN=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
index 28d35c1edc43..6a648dafe133 100644
--- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
@@ -33,9 +33,11 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_DM_ETH=y
 CONFIG_ZYNQ_GEM=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
index 2d55ae03d193..c6521e87136e 100644
--- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
@@ -32,9 +32,11 @@ CONFIG_SPL_OF_CONTROL=y
 CONFIG_OF_EMBED=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
 CONFIG_DM_I2C=y
 CONFIG_SYS_I2C_CADENCE=y
 CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_DM_ETH=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zcu102_defconfig 
b/configs/xilinx_zynqmp_zcu102_defconfig
index 2c6ceb35a589..f0378fee6879 100644
--- a/configs/xilinx_zynqmp_zcu102_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_defconfig
@@ -37,7 +37,9 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
 CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
b/configs/xilinx_zynqmp_zcu102_revB_defconfig
index 0b42734e0bc3..cb810cfff704 100644
--- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
+++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
@@ -37,7 +37,9 @@ CONFIG_OF_EMBED=y
 CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SPL_DM=y
 CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_BLK=y
 CONFIG_DM_MMC=y
+CONFIG_DM_MMC_OPS=y
 CONFIG_ZYNQ_SDHCI=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_BAR=y
-- 
1.9.1

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

Re: [U-Boot] [PATCH 1/3] net: emaclite: Use ioremap_nocache

[Michal Simek]

On 27.7.2016 13:50, Daniel Schwierzeck wrote:
> 
> 
> Am 27.07.2016 um 13:25 schrieb Zubair Lutfullah Kakakhel:
>> Virtual to physical mapping isn't necessarily 1:1 for all architectures
>>
>> Using ioremap_nocache allows for the arch code to translate the
>> physical address to a virtual address.
>>
>> Signed-off-by: Zubair Lutfullah Kakakhel 
>> Reviewed-by: Paul Burton 
> 
> looks okay because this driver is only used by Microblaze which has
> ioremap_nocache() defined.
> 
> Reviewed-by: Daniel Schwierzeck 

First of all please keep me in CC for all these xilinx drivers changes.

This driver is enabled only for Microblaze but can be also used for ARM
and ARM64.

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/3] zynqmp: Move config IDENT_STRING to defconfig

[Michal Simek]

On 1.8.2016 06:49, Siva Durga Prasad Paladugu wrote:
> Move config IDENT_STRING to defconfig for all
> zynqmp boards.
> 
> Signed-off-by: Siva Durga Prasad Paladugu 
> ---
> Changes for v2:
> - Appended revB in CONFIG_IDENT_ENTRY definition
>   for zcu102 RevB board
> ---
>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig | 1 +
>  configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
>  configs/xilinx_zynqmp_zcu102_defconfig   | 1 +
>  configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
>  include/configs/xilinx_zynqmp_zc1751_xm015_dc1.h | 2 --
>  include/configs/xilinx_zynqmp_zc1751_xm016_dc2.h | 2 --
>  include/configs/xilinx_zynqmp_zc1751_xm018_dc4.h | 2 --
>  include/configs/xilinx_zynqmp_zc1751_xm019_dc5.h | 2 --
>  include/configs/xilinx_zynqmp_zcu102.h   | 2 --
>  11 files changed, 6 insertions(+), 10 deletions(-)
> 
> diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> index 51637fc..de0e2d3 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
> @@ -14,6 +14,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1751 xm015 dc1"
>  CONFIG_SYS_PROMPT="ZynqMP> "
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_MEMTEST=y
> diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> index 9fa1562..1db0735 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
> @@ -14,6 +14,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1751 xm016 dc2"
>  CONFIG_SYS_PROMPT="ZynqMP> "
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_MEMTEST=y
> diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> index efa7b8c..7c6b5ab 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> @@ -13,6 +13,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1751 xm018 dc4"
>  CONFIG_SYS_PROMPT="ZynqMP> "
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_MEMTEST=y
> diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
> index a6818c1..2505fef 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig
> @@ -13,6 +13,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_IDENT_STRING=" Xilinx ZynqMP ZC1751 xm019 dc5"
>  CONFIG_SYS_PROMPT="ZynqMP> "
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_MEMTEST=y
> diff --git a/configs/xilinx_zynqmp_zcu102_defconfig 
> b/configs/xilinx_zynqmp_zcu102_defconfig
> index b0303f6..a95f684 100644
> --- a/configs/xilinx_zynqmp_zcu102_defconfig
> +++ b/configs/xilinx_zynqmp_zcu102_defconfig
> @@ -13,6 +13,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_IDENT_STRING=" Xilinx ZynqMP ZCU102"
>  CONFIG_SYS_PROMPT="ZynqMP> "
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_MEMTEST=y
> diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
> b/configs/xilinx_zynqmp_zcu102_revB_defconfig
> index b2b5208..88ccf25 100644
> --- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
> +++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
> @@ -13,6 +13,7 @@ CONFIG_FIT=y
>  CONFIG_FIT_VERBOSE=y
>  CONFIG_SPL_LOAD_FIT=y
>  CONFIG_HUSH_PARSER=y
> +CONFIG_IDENT_STRING=" Xilinx ZynqMP ZCU102 revB"
>  CONFIG_SYS_PROMPT="ZynqMP> "
>  # CONFIG_CMD_IMLS is not set
>  CONFIG_CMD_MEMTEST=y
> diff --git a/include/configs/xilinx_zynqmp_zc1751_xm015_dc1.h 
> b/include/configs/xilinx_zynqmp_zc1751_xm015_dc1.h
> index c9f4432..b19a552 100644
> --- a/include/configs/xilinx_zynqmp_zc1751_xm015_dc1.h
> +++ b/include/configs/xilinx_zynqmp_zc1751_xm015_dc1.h
> @@ -15,8 +15,6 @@
>  #define CONFIG_AHCI
>  #define CONFIG_ZYNQMP_XHCI_LIST {ZYNQMP_USB0_XHCI_BASEADDR}
>  
> -#define CONFIG_IDENT_STRING  " Xilinx ZynqMP ZC1751 xm015 dc1"
> -
>  #include 
>  
>  #endif /* __CONFIG_ZYNQMP_ZC1751_XM015_DC1_H */
> diff --git a/include/configs/xilinx_zynqmp_zc1751_xm016_dc2.h 
> b/include/configs/xilinx_zynqmp_zc1751_xm016_dc2.h
> index 526d0bb..0714d72 100644
> --- a/include/configs/xilinx_zynqmp_zc1751_xm016_dc2.h
> +++ b/include/configs/xilinx_zynqmp_zc1751_xm016_dc2.h
> @@ -12,8 +12,6 @@
>  
>  #define CONFIG_ZYNQMP_XHCI_LIST {ZYNQMP_USB1_XHCI_BASEADDR}
>  
> -#define CONFIG_IDENT_STRING  " Xilinx ZynqMP ZC1751 xm016 dc2"
> -
>  #include 
>  
>  #endif /* __CONFIG_ZYNQMP_ZC1751_XM016_DC2_H */
> diff

Re: [U-Boot] [PATCH v2 3/3] zynqmp: Remove unnnecessary board config file for dc4

[Michal Simek]

On 1.8.2016 06:49, Siva Durga Prasad Paladugu wrote:
> Remove unnecessary board specific config file for DC4
> board.
> 
> Signed-off-by: Siva Durga Prasad Paladugu 
> ---
> Changes for v2:
> - None
> ---
>  configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig |  1 -
>  include/configs/xilinx_zynqmp_zc1751_xm018_dc4.h | 15 ---
>  2 files changed, 16 deletions(-)
>  delete mode 100644 include/configs/xilinx_zynqmp_zc1751_xm018_dc4.h
> 
> diff --git a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig 
> b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> index 7c6b5ab..1ed0c52 100644
> --- a/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> +++ b/configs/xilinx_zynqmp_zc1751_xm018_dc4_defconfig
> @@ -1,5 +1,4 @@
>  CONFIG_ARM=y
> -CONFIG_SYS_CONFIG_NAME="xilinx_zynqmp_zc1751_xm018_dc4"
>  CONFIG_ARCH_ZYNQMP=y
>  CONFIG_SYS_MALLOC_F_LEN=0x8000
>  CONFIG_SPL_SYS_MALLOC_SIMPLE=y
> diff --git a/include/configs/xilinx_zynqmp_zc1751_xm018_dc4.h 
> b/include/configs/xilinx_zynqmp_zc1751_xm018_dc4.h
> deleted file mode 100644
> index 4866b61..000
> --- a/include/configs/xilinx_zynqmp_zc1751_xm018_dc4.h
> +++ /dev/null
> @@ -1,15 +0,0 @@
> -/*
> - * Configuration for Xilinx ZynqMP zc1751 XM018 DC4
> - *
> - * (C) Copyright 2015 Xilinx, Inc.
> - * Michal Simek 
> - *
> - * SPDX-License-Identifier:  GPL-2.0+
> - */
> -
> -#ifndef __CONFIG_ZYNQMP_ZC1751_XM018_DC4_H
> -#define __CONFIG_ZYNQMP_ZC1751_XM018_DC4_H
> -
> -#include 
> -
> -#endif /* __CONFIG_ZYNQMP_ZC1751_XM018_DC4_H */
> 

Same here.

Acked-by: Michal Simek 

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] gpio: Add driver for TI PCF8575 I2C GPIO expander

[Vignesh R]

On Monday 01 August 2016 06:31 AM, Simon Glass wrote:
> Hi,
> 
> On 25 July 2016 at 07:10, Vignesh R  wrote:
>> TI's PCF8575 is a 16-bit I2C GPIO expander.The device features a
>> 16-bit quasi-bidirectional I/O ports. Each quasi-bidirectional I/O can
>> be used as an input or output without the use of a data-direction
>> control signal. The I/Os should be high before being used as inputs.
>> Read the device documentation for more details[1].
>>
>> This driver is based on pcf857x driver available in Linux v4.7 kernel.
>> It supports basic reading and writing of gpio pins.
>>
>> [1] http://www.ti.com/lit/ds/symlink/pcf8575.pdf
>>
>> Signed-off-by: Vignesh R 
>> ---
>>  doc/device-tree-bindings/gpio/gpio-pcf857x.txt |  71 +
>>  drivers/gpio/Kconfig   |   7 +
>>  drivers/gpio/Makefile  |   1 +
>>  drivers/gpio/pcf8575_gpio.c| 199 
>> +
>>  4 files changed, 278 insertions(+)
>>  create mode 100644 doc/device-tree-bindings/gpio/gpio-pcf857x.txt
>>  create mode 100644 drivers/gpio/pcf8575_gpio.c
> 
> Reviewed-by: Simon Glass 
> 
> A few nits below.
> 
>>
>> diff --git a/doc/device-tree-bindings/gpio/gpio-pcf857x.txt 
>> b/doc/device-tree-bindings/gpio/gpio-pcf857x.txt
>> new file mode 100644
>> index ..ada4e2973323
>> --- /dev/null
>> +++ b/doc/device-tree-bindings/gpio/gpio-pcf857x.txt
>> @@ -0,0 +1,71 @@
>> +* PCF857x-compatible I/O expanders
>> +
>> +The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can 
>> be
>> +driven high by a pull-up current source or driven low to ground. This 
>> combines
>> +the direction and output level into a single bit per line, which can't be 
>> read
>> +back. We can't actually know at initialization time whether a line is 
>> configured
>> +(a) as output and driving the signal low/high, or (b) as input and 
>> reporting a
>> +low/high value, without knowing the last value written since the chip came 
>> out
>> +of reset (if any). The only reliable solution for setting up line direction 
>> is
>> +thus to do it explicitly.
>> +
>> +Required Properties:
>> +
>> +  - compatible: should be one of the following.
>> +- "maxim,max7328": For the Maxim MAX7378
>> +- "maxim,max7329": For the Maxim MAX7329
>> +- "nxp,pca8574": For the NXP PCA8574
>> +- "nxp,pca8575": For the NXP PCA8575
>> +- "nxp,pca9670": For the NXP PCA9670
>> +- "nxp,pca9671": For the NXP PCA9671
>> +- "nxp,pca9672": For the NXP PCA9672
>> +- "nxp,pca9673": For the NXP PCA9673
>> +- "nxp,pca9674": For the NXP PCA9674
>> +- "nxp,pca9675": For the NXP PCA9675
>> +- "nxp,pcf8574": For the NXP PCF8574
>> +- "nxp,pcf8574a": For the NXP PCF8574A
>> +- "nxp,pcf8575": For the NXP PCF8575
>> +- "ti,tca9554": For the TI TCA9554
>> +
>> +  - reg: I2C slave address.
>> +
>> +  - gpio-controller: Marks the device node as a gpio controller.
>> +  - #gpio-cells: Should be 2. The first cell is the GPIO number and the 
>> second
>> +cell specifies GPIO flags, as defined in . 
>> Only the
>> +GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
>> +
>> +Optional Properties:
>> +
>> +  - lines-initial-states: Bitmask that specifies the initial state of each
>> +  line. When a bit is set to zero, the corresponding line will be 
>> initialized to
>> +  the input (pulled-up) state. When the  bit is set to one, the line will be
>> +  initialized the low-level output state. If the property is not specified
>> +  all lines will be initialized to the input state.
>> +
>> +  The I/O expander can detect input state changes, and thus optionally act 
>> as
>> +  an interrupt controller. When the expander interrupt line is connected 
>> all the
>> +  following properties must be set. For more information please see the
>> +  interrupt controller device tree bindings documentation available at
>> +  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
>> +
>> +  - interrupt-controller: Identifies the node as an interrupt controller.
>> +  - #interrupt-cells: Number of cells to encode an interrupt source, shall 
>> be 2.
>> +  - interrupt-parent: phandle of the parent interrupt controller.
>> +  - interrupts: Interrupt specifier for the controllers interrupt.
>> +
>> +
>> +Please refer to gpio.txt in this directory for details of the common GPIO
>> +bindings used by client devices.
>> +
>> +Example: PCF8575 I/O expander node
>> +
>> +   pcf8575: gpio@20 {
>> +   compatible = "nxp,pcf8575";
>> +   reg = <0x20>;
>> +   interrupt-parent = <&irqpin2>;
>> +   interrupts = <3 0>;
>> +   gpio-controller;
>> +   #gpio-cells = <2>;
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   };
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index 73b862dc0b21..1af05358ec76 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/

[U-Boot] [PATCH] Makefile: Remove tags file on mrproper

[Vignesh R]

make tags creates a symbolic link called tags to ctags. Remove this file
on make mrproper or make distclean.

Signed-off-by: Vignesh R 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 99cc8cf2f701..d1ad6c685442 100644
--- a/Makefile
+++ b/Makefile
@@ -1418,7 +1418,7 @@ CLEAN_FILES += include/bmp_logo.h include/bmp_logo_data.h 
include/license.h \
 MRPROPER_DIRS  += include/config include/generated spl tpl \
  .tmp_objdiff
 MRPROPER_FILES += .config .config.old include/autoconf.mk* include/config.h \
- ctags etags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
+ ctags etags tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
 
 # clean - Delete most, but leave enough to build external modules
 #
-- 
2.9.2

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

Re: [U-Boot] [PATCH 1/3] usb: add CONIFG_USB_OHCI_HCD in Kconfig

[Alexey Brodkin]

Hi Masahiro-san,

On Sun, 2016-07-31 at 18:24 +0900, Masahiro Yamada wrote:
> Add this option as a common config for all OHCI controllers.  Its
> help message was copied from Linux.  Also, I moved it below EHCI
> to respect the order in Linux's Kconfig.
> 
> Add CONFIG_USB_OHCI_HCD=y to axs103_defconfig, which is the only
> user of OHCI_GENERIC.
> 
> Signed-off-by: Masahiro Yamada 
> ---

There's such a thing like "new OHCI driver" which is enabled by
CONFIG_USB_OHCI_NEW (as of today in config headers) and some OHCI
drivers rely on it.

I'd say it is a very good candidate to go to Kconfig especially for
those boards that use DM_USB.

Not sure if that makes sense for boards except axs103 in your change-set
though.

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

Re: [U-Boot] SCSI is missing DM support?

[Michal Simek]

Hi, +u-boot

On 1.8.2016 09:19, Alexander Graf wrote:
> Hi guys,
> 
> I tried to boot from SCSI on the Xilinx ZynqMP EP platform (the QEMU based 
> system) and turns out the scsi commands can’t find a scsi disk that is 
> attached to it. For an example command line, just run
> 
>   ./aarch64-softmmu/qemu-system-aarch64 -nographic -M xlnx-ep108 -m 2G 
> -kernel ~/git/u-boot/u-boot.elf -drive file=~/foo.raw,if=none,id=disk -device 
> ide-drive,drive=disk
> 
> While that U-Boot will find a scsi disk (which really is SATA) and expose it, 
> it’s unable to make use of it later because it’s missing in the object tree. 
> I suppose we use CONFIG_BLK because of SD access, but that really shouldn’t 
> break non-SD devices ;).

I can confirm that issue is there even on HW,
Some hours ago I have sent this patch
"ARM64: zynqmp: Do not enable DM_MMC by default"
which removed some Kconfig default options because of different
configuration but CONFIG_BLK is causing this problem.

But the issue was there even before.
For 2016.05 there is compilation error when you enable CONFIG_BLK
on ZynqMP. And 2016.07 has the same issue like current HEAD.

But definitely we need to move ceva driver to match latest structure.
Is there any driver which can be used with BLK on and it is ahci
and it is using scsi command?

Thanks,
Michal


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

Re: [U-Boot] [PATCH 1/2] mmc: sdhci: set to INT_DATA_END when there are data

[Lukasz Majewski]

Dear All,

> Hi All,
> 
> On 07/12/2016 09:55 PM, Lukasz Majewski wrote:
> > Hi Jaehoon,
> > 
> >> There is no data, it doesn't needs to wait for completing data
> >> transfer. (It seems that it can be removed.)
> >> Almost all timeout error is occured from stop command without data.
> >> After applied this patch, I hope that we don't need to increase
> >> timeout value anymore.
> > 
> > This patch fixes issue (in a better way) for Odroid U3 write
> > performance (http://patchwork.ozlabs.org/patch/646932/) and hence
> > should be used.
> > 
> 
> Is there any other opinion for this patch?
> Who is maintaining u-boot-mmc? Is Pantelis still maintaining
> u-boot-mmc?
> 
> Who can apply this patch and patch relevant to mmc?

Gentle ping .

Pantelis could you pull this patch to u-boot-mmc tree?

> 
> Best Regards,
> Jaehoon Chung
> 
> > 
> >>
> >> Signed-off-by: Jaehoon Chung 
> >> ---
> >>  drivers/mmc/sdhci.c | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
> >> index 604f18d..0a38a56 100644
> >> --- a/drivers/mmc/sdhci.c
> >> +++ b/drivers/mmc/sdhci.c
> >> @@ -175,7 +175,8 @@ static int sdhci_send_command(struct mmc *mmc,
> >> struct mmc_cmd *cmd, flags = SDHCI_CMD_RESP_LONG;
> >>else if (cmd->resp_type & MMC_RSP_BUSY) {
> >>flags = SDHCI_CMD_RESP_SHORT_BUSY;
> >> -  mask |= SDHCI_INT_DATA_END;
> >> +  if (data)
> >> +  mask |= SDHCI_INT_DATA_END;
> >>} else
> >>flags = SDHCI_CMD_RESP_SHORT;
> >>  
> > 
> > Acked-by: Lukasz Majewski 
> > Tested-by: Lukasz Majewski 
> > 
> > Test HW: Odroid U3 (Exynos4):
> > 
> > Odroid # ext4load mmc 0:2 0x4100 dat_31M.img
> > 32505856 bytes read in 1471 ms (21.1 MiB/s)
> > Odroid # ext4write mmc 0:2 0x4100 /dat_w55.img 0x1f0
> > File System is consistent
> > update journal finished
> > 32505856 bytes written in 3528 ms (8.8 MiB/s)
> > 
> > Performance improvement is even better than with previously proposed
> > patches.
> > 
> > Test HW: Odroid XU3 (Exynos5):
> > 
> > ODROID-XU3 # ext4load mmc 0:2 0x4100 dat_31M.img
> > 32505856 bytes read in 6309 ms (4.9 MiB/s)
> > ODROID-XU3 # ext4write mmc 0:2 0x4100 /dat_w1.img 0x1f0
> > File System is consistent
> > update journal finished
> > 32505856 bytes written in 4884 ms (6.3 MiB/s)
> > 
> > 
> 



-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 00/11] MIPS Boston Development Board Support

[Paul Burton]

This series introduces initial support for the MIPS Boston, and FPGA
based development board & successor to the older Malta board. Further
peripheral work is needed but this introduces the basics.

This can be tested in a currently out-of-tree QEMU port if desired,
which can be found in the boston branch of:

  git://git.linux-mips.org/pub/scm/paul/qemu.git

QEMU can be used to run U-Boot like this:

  ./configure --target-list=mips64el-softmmu
  make
  ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \
-bios u-boot.bin -serial stdio

Paul Burton (11):
  serial: ns16550: Support clocks via phandle
  dt-bindings: Add interrupt-controller/mips-gic.h header
  pci: xilinx: Add a driver for Xilinx AXI to PCIe bridge
  pci: Flip condition for detecting non-PCI parent devices
  net: pch_gbe: Use dm_pci_map_bar to discover MMIO base
  net: pch_gbe: Make 64 bit safe
  dm: regmap: Implement simple regmap_read & regmap_write
  dm: core: Match compatible strings in order of priority
  dm: syscon: Provide a generic syscon driver
  clk: boston: Providea simple driver for Boston board clocks
  boston: Introduce support for the MIPS Boston development board

 arch/mips/Kconfig  |  16 ++
 arch/mips/dts/Makefile |   1 +
 arch/mips/dts/img,boston.dts   | 216 
 board/imgtec/boston/Kconfig|  16 ++
 board/imgtec/boston/MAINTAINERS|   6 +
 board/imgtec/boston/Makefile   |   9 +
 board/imgtec/boston/boston-lcd.h   |  21 ++
 board/imgtec/boston/boston-regs.h  |  47 +
 board/imgtec/boston/checkboard.c   |  29 +++
 board/imgtec/boston/ddr.c  |  30 +++
 board/imgtec/boston/lowlevel_init.S|  56 ++
 configs/boston32r2_defconfig   |  40 
 configs/boston32r2el_defconfig |  41 
 configs/boston64r2_defconfig   |  40 
 configs/boston64r2el_defconfig |  41 
 doc/README.boston  |  39 
 drivers/clk/Kconfig|   8 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk_boston.c   |  97 +
 drivers/core/lists.c   |  83 
 drivers/core/regmap.c  |  20 ++
 drivers/core/syscon-uclass.c   |  11 ++
 drivers/net/pch_gbe.c  |  28 ++-
 drivers/pci/Kconfig|   7 +
 drivers/pci/Makefile   |   1 +
 drivers/pci/pci-uclass.c   |   2 +-
 drivers/pci/pcie_xilinx.c  | 219 +
 drivers/serial/ns16550.c   |  19 +-
 include/configs/boston.h   |  68 +++
 include/dt-bindings/clock/boston-clock.h   |  13 ++
 .../dt-bindings/interrupt-controller/mips-gic.h|   9 +
 31 files changed, 1173 insertions(+), 61 deletions(-)
 create mode 100644 arch/mips/dts/img,boston.dts
 create mode 100644 board/imgtec/boston/Kconfig
 create mode 100644 board/imgtec/boston/MAINTAINERS
 create mode 100644 board/imgtec/boston/Makefile
 create mode 100644 board/imgtec/boston/boston-lcd.h
 create mode 100644 board/imgtec/boston/boston-regs.h
 create mode 100644 board/imgtec/boston/checkboard.c
 create mode 100644 board/imgtec/boston/ddr.c
 create mode 100644 board/imgtec/boston/lowlevel_init.S
 create mode 100644 configs/boston32r2_defconfig
 create mode 100644 configs/boston32r2el_defconfig
 create mode 100644 configs/boston64r2_defconfig
 create mode 100644 configs/boston64r2el_defconfig
 create mode 100644 doc/README.boston
 create mode 100644 drivers/clk/clk_boston.c
 create mode 100644 drivers/pci/pcie_xilinx.c
 create mode 100644 include/configs/boston.h
 create mode 100644 include/dt-bindings/clock/boston-clock.h
 create mode 100644 include/dt-bindings/interrupt-controller/mips-gic.h

-- 
2.9.0

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

[U-Boot] Question on Enabling hypervisor mode in u-boot

[Keerthy]

Hi Alexander,

I am trying to enable hypervisor in u-boot for DRA7(A15 based) family of 
SoCs which does not have LPAE support yet.


Is it mandatory for LPAE to be enabled before enabling hypervisor for A15?

I was looking at commit:

commit d990f5c834f1b42293fb53e4fd7f3aa988184196
Author: Alexander Graf 
Date:   Wed Mar 16 15:41:21 2016 +0100

arm: Add support for HYP mode and LPAE page tables

and the is_hyp always returns 0 when LPAE config option is not enabled.

Just wanted to confirm if that is mandatory.

Best Regards,
Keerthy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 02/11] dt-bindings: Add interrupt-controller/mips-gic.h header

[Paul Burton]

Import a copy of the dt-bindings/interrupt-controller/mips-gic.h header
from Linux, such that we can use device trees which include it without
modification.

Signed-off-by: Paul Burton 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 include/dt-bindings/interrupt-controller/mips-gic.h | 9 +
 1 file changed, 9 insertions(+)
 create mode 100644 include/dt-bindings/interrupt-controller/mips-gic.h

diff --git a/include/dt-bindings/interrupt-controller/mips-gic.h 
b/include/dt-bindings/interrupt-controller/mips-gic.h
new file mode 100644
index 000..cf35a57
--- /dev/null
+++ b/include/dt-bindings/interrupt-controller/mips-gic.h
@@ -0,0 +1,9 @@
+#ifndef _DT_BINDINGS_INTERRUPT_CONTROLLER_MIPS_GIC_H
+#define _DT_BINDINGS_INTERRUPT_CONTROLLER_MIPS_GIC_H
+
+#include 
+
+#define GIC_SHARED 0
+#define GIC_LOCAL 1
+
+#endif
-- 
2.9.0

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

[U-Boot] [PATCH v4 01/11] serial: ns16550: Support clocks via phandle

[Paul Burton]

Previously ns16550 compatible UARTs probed via device tree have needed
their device tree nodes to contain a clock-frequency property. An
alternative to this commonly used with Linux is to reference a clock via
a phandle. This patch allows U-Boot to support that, retrieving the
clock frequency by probing the appropriate clock device.

For example, a system might choose to provide the UART base clock as a
reference to a clock common to multiple devices:

  sys_clk: clock {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1000>;
  };

  uart0: uart@1000 {
compatible = "ns16550a";
reg = <0x1000 0x1000>;
clocks = <&sys_clk>;
  };

  uart1: uart@1000 {
compatible = "ns16550a";
reg = <0x10001000 0x1000>;
clocks = <&sys_clk>;
  };

This removes the need for the frequency information to be duplicated in
multiple nodes and allows the device tree to be more descriptive of the
system.

Signed-off-by: Paul Burton 
Reviewed-by: Simon Glass 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Propogate non-ENODEV errors from clk_get_by_index

 drivers/serial/ns16550.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 88fca15..37da3ed 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -5,6 +5,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -352,6 +353,8 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
 {
struct ns16550_platdata *plat = dev->platdata;
fdt_addr_t addr;
+   struct clk clk;
+   int err;
 
/* try Processor Local Bus device first */
addr = dev_get_addr(dev);
@@ -397,9 +400,19 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
 "reg-offset", 0);
plat->reg_shift = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
 "reg-shift", 0);
-   plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
-"clock-frequency",
-CONFIG_SYS_NS16550_CLK);
+
+   err = clk_get_by_index(dev, 0, &clk);
+   if (!err) {
+   plat->clock = clk_get_rate(&clk);
+   } else if (err != -ENODEV) {
+   debug("ns16550 failed to get clock\n");
+   return err;
+   }
+
+   if (!plat->clock)
+   plat->clock = fdtdec_get_int(gd->fdt_blob, dev->of_offset,
+"clock-frequency",
+CONFIG_SYS_NS16550_CLK);
if (!plat->clock) {
debug("ns16550 clock not defined\n");
return -EINVAL;
-- 
2.9.0

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

[U-Boot] [PATCH v4 04/11] pci: Flip condition for detecting non-PCI parent devices

[Paul Burton]

In pci_uclass_pre_probe an attempt is made to detect whether the parent
of a device is a PCI device and that the device is thus a bridge. This
was being done by checking whether the parent of the device is of the
UCLASS_ROOT class. This causes problems if the PCI controller is a child
of some other non-PCI node, for example a simple-bus node.

For example, if the device tree contains something like the following
then pci_uclass_pre_probe would incorrectly believe that the PCI
controller is a bridge, with a PCI parent:

  / {
some_child {
  compatible = "simple-bus";
  #address-cells = <1>;
  #size-cells = <1>;
  ranges = <>;

  pci_controller: pci@1000 {
compatible = "my-pci-controller";
device_type = "pci";
reg = <0x1000 0x200>;
  };
};
  };

Avoid this incorrect detection of bridges by instead checking whether
the parent devices class is UCLASS_PCI and treating a device as a bridge
when this is true, making use of device_is_on_pci_bus to perform this
test.

Signed-off-by: Paul Burton 
Reviewed-by: Simon Glass 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Use device_is_on_pci_bus instead of effectively open-coding it

 drivers/pci/pci-uclass.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci-uclass.c b/drivers/pci/pci-uclass.c
index 32590ce..b9b55e2 100644
--- a/drivers/pci/pci-uclass.c
+++ b/drivers/pci/pci-uclass.c
@@ -859,7 +859,7 @@ static int pci_uclass_pre_probe(struct udevice *bus)
hose = bus->uclass_priv;
 
/* For bridges, use the top-level PCI controller */
-   if (device_get_uclass_id(bus->parent) == UCLASS_ROOT) {
+   if (!device_is_on_pci_bus(bus)) {
hose->ctlr = bus;
ret = decode_regions(hose, gd->fdt_blob, bus->parent->of_offset,
bus->of_offset);
-- 
2.9.0

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

[U-Boot] [PATCH v4 03/11] pci: xilinx: Add a driver for Xilinx AXI to PCIe bridge

[Paul Burton]

This patch adds a driver for the Xilinx AXI bridge for PCI express, an
IP block which can be used on some generations of Xilinx FPGAs. This is
mostly a case of implementing PCIe ECAM specification, but with some
quirks about what devices are valid to access.

Signed-off-by: Paul Burton 
Reviewed-by: Simon Glass 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
- Clean up error returns & documentation

 drivers/pci/Kconfig   |   7 ++
 drivers/pci/Makefile  |   1 +
 drivers/pci/pcie_xilinx.c | 219 ++
 3 files changed, 227 insertions(+)
 create mode 100644 drivers/pci/pcie_xilinx.c

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 26aa2b0..1f9ea66 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -38,4 +38,11 @@ config PCI_TEGRA
  with a total of 5 lanes. Some boards require this for Ethernet
  support to work (e.g. beaver, jetson-tk1).
 
+config PCI_XILINX
+   bool "Xilinx AXI Bridge for PCI Express"
+   depends on DM_PCI
+   help
+ Enable support for the Xilinx AXI bridge for PCI express, an IP block
+ which can be used on some generations of Xilinx FPGAs.
+
 endmenu
diff --git a/drivers/pci/Makefile b/drivers/pci/Makefile
index f8be9bf..9583e91 100644
--- a/drivers/pci/Makefile
+++ b/drivers/pci/Makefile
@@ -31,3 +31,4 @@ obj-$(CONFIG_PCI_TEGRA) += pci_tegra.o
 obj-$(CONFIG_TSI108_PCI) += tsi108_pci.o
 obj-$(CONFIG_WINBOND_83C553) += w83c553f.o
 obj-$(CONFIG_PCIE_LAYERSCAPE) += pcie_layerscape.o
+obj-$(CONFIG_PCI_XILINX) += pcie_xilinx.o
diff --git a/drivers/pci/pcie_xilinx.c b/drivers/pci/pcie_xilinx.c
new file mode 100644
index 000..9fe02be
--- /dev/null
+++ b/drivers/pci/pcie_xilinx.c
@@ -0,0 +1,219 @@
+/*
+ * Xilinx AXI Bridge for PCI Express Driver
+ *
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+
+#include 
+
+/**
+ * struct xilinx_pcie - Xilinx PCIe controller state
+ * @hose: The parent classes PCI controller state
+ * @cfg_base: The base address of memory mapped configuration space
+ */
+struct xilinx_pcie {
+   struct pci_controller hose;
+   void *cfg_base;
+};
+
+/* Register definitions */
+#define XILINX_PCIE_REG_PSCR   0x144
+#define XILINX_PCIE_REG_PSCR_LNKUP BIT(11)
+
+/**
+ * pcie_xilinx_link_up() - Check whether the PCIe link is up
+ * @pcie: Pointer to the PCI controller state
+ *
+ * Checks whether the PCIe link for the given device is up or down.
+ *
+ * Return: true if the link is up, else false
+ */
+static bool pcie_xilinx_link_up(struct xilinx_pcie *pcie)
+{
+   uint32_t pscr = __raw_readl(pcie->cfg_base + XILINX_PCIE_REG_PSCR);
+
+   return pscr & XILINX_PCIE_REG_PSCR_LNKUP;
+}
+
+/**
+ * pcie_xilinx_config_address() - Calculate the address of a config access
+ * @pcie: Pointer to the PCI controller state
+ * @bdf: Identifies the PCIe device to access
+ * @offset: The offset into the device's configuration space
+ * @paddress: Pointer to the pointer to write the calculates address to
+ *
+ * Calculates the address that should be accessed to perform a PCIe
+ * configuration space access for a given device identified by the PCIe
+ * controller device @pcie and the bus, device & function numbers in @bdf. If
+ * access to the device is not valid then the function will return an error
+ * code. Otherwise the address to access will be written to the pointer pointed
+ * to by @paddress.
+ *
+ * Return: 0 on success, else -ENODEV
+ */
+static int pcie_xilinx_config_address(struct xilinx_pcie *pcie, pci_dev_t bdf,
+ uint offset, void **paddress)
+{
+   unsigned int bus = PCI_BUS(bdf);
+   unsigned int dev = PCI_DEV(bdf);
+   unsigned int func = PCI_FUNC(bdf);
+   void *addr;
+
+   if ((bus > 0) && !pcie_xilinx_link_up(pcie))
+   return -ENODEV;
+
+   /*
+* Busses 0 (host-PCIe bridge) & 1 (its immediate child) are
+* limited to a single device each.
+*/
+   if ((bus < 2) && (dev > 0))
+   return -ENODEV;
+
+   addr = pcie->cfg_base;
+   addr += bus << 20;
+   addr += dev << 15;
+   addr += func << 12;
+   addr += offset;
+   *paddress = addr;
+
+   return 0;
+}
+
+/**
+ * pcie_xilinx_read_config() - Read from configuration space
+ * @pcie: Pointer to the PCI controller state
+ * @bdf: Identifies the PCIe device to access
+ * @offset: The offset into the device's configuration space
+ * @valuep: A pointer at which to store the read value
+ * @size: Indicates the size of access to perform
+ *
+ * Read a value of size @size from offset @offset within the configuration
+ * space of the device identified by the bus, device & function numbers in @bdf
+ * on the PCI bus @bus.
+ *
+ * Return: 0 on success, else -ENODEV or -EINVAL
+ */
+static int pcie_xilinx_read_config(struct udevice *bus, pci_dev_t bdf,
+   

[U-Boot] [PATCH v4 05/11] net: pch_gbe: Use dm_pci_map_bar to discover MMIO base

[Paul Burton]

Reading the PCI BAR & converting the result to a physical address is not
safe across all architectures. For example on MIPS the virtual:physical
mapping is not 1:1, so we cannot directly make use of the physical
address.

Use the more generic BAR-mapping function dm_pci_map_bar to discover the
MMIO base address, which should work across architectures.

Signed-off-by: Paul Burton 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/net/pch_gbe.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
index 137818b..2d0a700 100644
--- a/drivers/net/pch_gbe.c
+++ b/drivers/net/pch_gbe.c
@@ -421,7 +421,7 @@ int pch_gbe_probe(struct udevice *dev)
 {
struct pch_gbe_priv *priv;
struct eth_pdata *plat = dev_get_platdata(dev);
-   u32 iobase;
+   void *iobase;
 
/*
 * The priv structure contains the descriptors and frame buffers which
@@ -432,11 +432,9 @@ int pch_gbe_probe(struct udevice *dev)
 
priv->dev = dev;
 
-   dm_pci_read_config32(dev, PCI_BASE_ADDRESS_1, &iobase);
-   iobase &= PCI_BASE_ADDRESS_MEM_MASK;
-   iobase = dm_pci_mem_to_phys(dev, iobase);
+   iobase = dm_pci_map_bar(dev, PCI_BASE_ADDRESS_1, PCI_REGION_MEM);
 
-   plat->iobase = iobase;
+   plat->iobase = (ulong)iobase;
priv->mac_regs = (struct pch_gbe_regs *)iobase;
 
/* Read MAC address from SROM and initialize dev->enetaddr with it */
-- 
2.9.0

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

[U-Boot] [PATCH v4 07/11] dm: regmap: Implement simple regmap_read & regmap_write

[Paul Burton]

The regmap_read & regmap_write functions were previously declared in
regmap.h but not implemented anywhere. The regmap implementation &
commit message of 6f98b7504f70 ("dm: Add support for register maps
(regmap)") indicate that only memory mapped accesses are supported for
now, so providing simple implementations of regmap_read & regmap_write
is trivial. The access size is presumed to be 4 bytes & endianness is
presumed native, which are the defaults for the regmap code in Linux.

Signed-off-by: Paul Burton 
Reviewed-by: Simon Glass 

---

Changes in v4:
- Tweak whitespace

Changes in v3: None
Changes in v2:
- New patch

 drivers/core/regmap.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/core/regmap.c b/drivers/core/regmap.c
index 0299ff0..3177515 100644
--- a/drivers/core/regmap.c
+++ b/drivers/core/regmap.c
@@ -13,6 +13,8 @@
 #include 
 #include 
 
+#include 
+
 DECLARE_GLOBAL_DATA_PTR;
 
 static struct regmap *regmap_alloc_count(int count)
@@ -117,3 +119,21 @@ int regmap_uninit(struct regmap *map)
 
return 0;
 }
+
+int regmap_read(struct regmap *map, uint offset, uint *valp)
+{
+   uint32_t *ptr = ioremap(map->base + offset, 4);
+
+   *valp = __raw_readl(ptr);
+
+   return 0;
+}
+
+int regmap_write(struct regmap *map, uint offset, uint val)
+{
+   uint32_t *ptr = ioremap(map->base + offset, 4);
+
+   __raw_writel(val, ptr);
+
+   return 0;
+}
-- 
2.9.0

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

[U-Boot] [PATCH v4 06/11] net: pch_gbe: Make 64 bit safe

[Paul Burton]

The pch_gbe driver previously casted pointers to & from unsigned 32 bit
integers in many locations. This breaks the driver on 64 bit systems,
producing streams of compiler warnings about mismatched pointer &
integer sizes and then failing to keep track of addresses correctly at
runtime.

Fix the driver for 64 bit systems by using unsigned longs in place of
the previously used 32 bit integers.

Signed-off-by: Paul Burton 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/net/pch_gbe.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/pch_gbe.c b/drivers/net/pch_gbe.c
index 2d0a700..d40fff0 100644
--- a/drivers/net/pch_gbe.c
+++ b/drivers/net/pch_gbe.c
@@ -118,14 +118,14 @@ static void pch_gbe_rx_descs_init(struct udevice *dev)
memset(rx_desc, 0, sizeof(struct pch_gbe_rx_desc) * PCH_GBE_DESC_NUM);
for (i = 0; i < PCH_GBE_DESC_NUM; i++)
rx_desc->buffer_addr = dm_pci_phys_to_mem(priv->dev,
-   (u32)(priv->rx_buff[i]));
+   (ulong)(priv->rx_buff[i]));
 
-   writel(dm_pci_phys_to_mem(priv->dev, (u32)rx_desc),
+   writel(dm_pci_phys_to_mem(priv->dev, (ulong)rx_desc),
   &mac_regs->rx_dsc_base);
writel(sizeof(struct pch_gbe_rx_desc) * (PCH_GBE_DESC_NUM - 1),
   &mac_regs->rx_dsc_size);
 
-   writel(dm_pci_phys_to_mem(priv->dev, (u32)(rx_desc + 1)),
+   writel(dm_pci_phys_to_mem(priv->dev, (ulong)(rx_desc + 1)),
   &mac_regs->rx_dsc_sw_p);
 }
 
@@ -137,11 +137,11 @@ static void pch_gbe_tx_descs_init(struct udevice *dev)
 
memset(tx_desc, 0, sizeof(struct pch_gbe_tx_desc) * PCH_GBE_DESC_NUM);
 
-   writel(dm_pci_phys_to_mem(priv->dev, (u32)tx_desc),
+   writel(dm_pci_phys_to_mem(priv->dev, (ulong)tx_desc),
   &mac_regs->tx_dsc_base);
writel(sizeof(struct pch_gbe_tx_desc) * (PCH_GBE_DESC_NUM - 1),
   &mac_regs->tx_dsc_size);
-   writel(dm_pci_phys_to_mem(priv->dev, (u32)(tx_desc + 1)),
+   writel(dm_pci_phys_to_mem(priv->dev, (ulong)(tx_desc + 1)),
   &mac_regs->tx_dsc_sw_p);
 }
 
@@ -251,7 +251,7 @@ static int pch_gbe_send(struct udevice *dev, void *packet, 
int length)
if (length < 64)
frame_ctrl |= PCH_GBE_TXD_CTRL_APAD;
 
-   tx_desc->buffer_addr = dm_pci_phys_to_mem(priv->dev, (u32)packet);
+   tx_desc->buffer_addr = dm_pci_phys_to_mem(priv->dev, (ulong)packet);
tx_desc->length = length;
tx_desc->tx_words_eob = length + 3;
tx_desc->tx_frame_ctrl = frame_ctrl;
@@ -262,7 +262,7 @@ static int pch_gbe_send(struct udevice *dev, void *packet, 
int length)
if (++priv->tx_idx >= PCH_GBE_DESC_NUM)
priv->tx_idx = 0;
 
-   writel(dm_pci_phys_to_mem(priv->dev, (u32)(tx_head + priv->tx_idx)),
+   writel(dm_pci_phys_to_mem(priv->dev, (ulong)(tx_head + priv->tx_idx)),
   &mac_regs->tx_dsc_sw_p);
 
start = get_timer(0);
@@ -283,7 +283,7 @@ static int pch_gbe_recv(struct udevice *dev, int flags, 
uchar **packetp)
struct pch_gbe_priv *priv = dev_get_priv(dev);
struct pch_gbe_regs *mac_regs = priv->mac_regs;
struct pch_gbe_rx_desc *rx_desc;
-   u32 hw_desc, buffer_addr, length;
+   ulong hw_desc, buffer_addr, length;
 
rx_desc = &priv->rx_desc[priv->rx_idx];
 
@@ -291,7 +291,7 @@ static int pch_gbe_recv(struct udevice *dev, int flags, 
uchar **packetp)
hw_desc = readl(&mac_regs->rx_dsc_hw_p_hld);
 
/* Just return if not receiving any packet */
-   if ((u32)rx_desc == hw_desc)
+   if ((ulong)rx_desc == hw_desc)
return -EAGAIN;
 
buffer_addr = dm_pci_mem_to_phys(priv->dev, rx_desc->buffer_addr);
@@ -315,7 +315,7 @@ static int pch_gbe_free_pkt(struct udevice *dev, uchar 
*packet, int length)
if (++rx_swp >= PCH_GBE_DESC_NUM)
rx_swp = 0;
 
-   writel(dm_pci_phys_to_mem(priv->dev, (u32)(rx_head + rx_swp)),
+   writel(dm_pci_phys_to_mem(priv->dev, (ulong)(rx_head + rx_swp)),
   &mac_regs->rx_dsc_sw_p);
 
return 0;
-- 
2.9.0

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

[U-Boot] [PATCH v4 08/11] dm: core: Match compatible strings in order of priority

[Paul Burton]

Device model drivers have previously been matched to FDT nodes by virtue
of being the first driver in the driver list to be compatible with the
node. This ignores the fact that compatible strings in the device tree
are listed in order of priority - that is, if we have a node with 2
compatible strings & a driver that matches each then we should always
probe the driver that matches the first compatible string.

Fix this by looping through the compatible strings for a node when
attempting to bind it in lists_bind_fdt and checking each driver for
a match of the first string, then each driver for a match of the second
string etc. Effectively this inverts the loops over compatible strings &
drivers.

Signed-off-by: Paul Burton 
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/core/lists.c | 83 ++--
 1 file changed, 41 insertions(+), 42 deletions(-)

diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index 6a634e6..bde6ec1 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -101,37 +101,21 @@ int device_bind_driver_to_node(struct udevice *parent, 
const char *drv_name,
 
 #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
 /**
- * driver_check_compatible() - Check if a driver is compatible with this node
+ * driver_check_compatible() - Check if a driver matches a compatible string
  *
- * @param blob:Device tree pointer
- * @param offset:  Offset of node in device tree
  * @param of_match:List of compatible strings to match
- * @param of_idp:  Returns the match that was found
- * @return 0 if there is a match, -ENOENT if no match, -ENODEV if the node
- * does not have a compatible string, other error <0 if there is a device
- * tree error
+ * @param compat:  The compatible string to search for
+ * @return 0 if there is a match, -ENOENT if no match
  */
-static int driver_check_compatible(const void *blob, int offset,
-  const struct udevice_id *of_match,
-  const struct udevice_id **of_idp)
+static int driver_check_compatible(const struct udevice_id *of_match,
+  const char *compat)
 {
-   int ret;
-
-   *of_idp = NULL;
if (!of_match)
return -ENOENT;
 
while (of_match->compatible) {
-   ret = fdt_node_check_compatible(blob, offset,
-   of_match->compatible);
-   if (!ret) {
-   *of_idp = of_match;
+   if (!strcmp(of_match->compatible, compat))
return 0;
-   } else if (ret == -FDT_ERR_NOTFOUND) {
-   return -ENODEV;
-   } else if (ret < 0) {
-   return -EINVAL;
-   }
of_match++;
}
 
@@ -143,35 +127,52 @@ int lists_bind_fdt(struct udevice *parent, const void 
*blob, int offset,
 {
struct driver *driver = ll_entry_start(struct driver, driver);
const int n_ents = ll_entry_count(struct driver, driver);
-   const struct udevice_id *id;
struct driver *entry;
struct udevice *dev;
bool found = false;
-   const char *name;
+   const char *name, *compat_list, *compat;
+   int compat_length, i;
int result = 0;
int ret = 0;
 
-   dm_dbg("bind node %s\n", fdt_get_name(blob, offset, NULL));
+   name = fdt_get_name(blob, offset, NULL);
+   dm_dbg("bind node %s\n", name);
if (devp)
*devp = NULL;
-   for (entry = driver; entry != driver + n_ents; entry++) {
-   ret = driver_check_compatible(blob, offset, entry->of_match,
- &id);
-   name = fdt_get_name(blob, offset, NULL);
-   if (ret == -ENOENT) {
-   continue;
-   } else if (ret == -ENODEV) {
+
+   compat_list = fdt_getprop(blob, offset, "compatible", &compat_length);
+   if (!compat_list) {
+   if (compat_length == -FDT_ERR_NOTFOUND) {
dm_dbg("Device '%s' has no compatible string\n", name);
-   break;
-   } else if (ret) {
-   dm_warn("Device tree error at offset %d\n", offset);
-   result = ret;
-   break;
+   return 0;
}
 
+   dm_warn("Device tree error at offset %d\n", offset);
+   return compat_length;
+   }
+
+   /*
+* Walk through the compatible string list, attempting to match each
+* compatible string in order such that we match in order of priority
+* from the first string to the last.
+*/
+   for (i = 0; i < compat_length; i += strlen(compat) + 1) {
+   compat = compat_list + i;
+   dm_dbg("   - a

[U-Boot] [PATCH v4 11/11] boston: Introduce support for the MIPS Boston development board

[Paul Burton]

This patch introduces support for building U-Boot to run on the MIPS
Boston development board. This is a board built around an FPGA & an
Intel EG20T Platform Controller Hub, used largely as part of the
development of new CPUs and their software support. It is essentially
the successor to the older MIPS Malta board.

Signed-off-by: Paul Burton 

---

Changes in v4:
- Add README.boston

Changes in v3:
- Add defconfigs for 32b & 64b, big & little endian, switch to MIPSr2

Changes in v2:
- Use AT instead of $1
- Use a clock driver instead of patching the DT

 arch/mips/Kconfig   |  16 +++
 arch/mips/dts/Makefile  |   1 +
 arch/mips/dts/img,boston.dts| 216 
 board/imgtec/boston/Kconfig |  16 +++
 board/imgtec/boston/MAINTAINERS |   6 +
 board/imgtec/boston/Makefile|   9 ++
 board/imgtec/boston/boston-lcd.h|  21 
 board/imgtec/boston/boston-regs.h   |  47 
 board/imgtec/boston/checkboard.c|  29 +
 board/imgtec/boston/ddr.c   |  30 +
 board/imgtec/boston/lowlevel_init.S |  56 ++
 configs/boston32r2_defconfig|  40 +++
 configs/boston32r2el_defconfig  |  41 +++
 configs/boston64r2_defconfig|  40 +++
 configs/boston64r2el_defconfig  |  41 +++
 doc/README.boston   |  39 +++
 include/configs/boston.h|  68 
 17 files changed, 716 insertions(+)
 create mode 100644 arch/mips/dts/img,boston.dts
 create mode 100644 board/imgtec/boston/Kconfig
 create mode 100644 board/imgtec/boston/MAINTAINERS
 create mode 100644 board/imgtec/boston/Makefile
 create mode 100644 board/imgtec/boston/boston-lcd.h
 create mode 100644 board/imgtec/boston/boston-regs.h
 create mode 100644 board/imgtec/boston/checkboard.c
 create mode 100644 board/imgtec/boston/ddr.c
 create mode 100644 board/imgtec/boston/lowlevel_init.S
 create mode 100644 configs/boston32r2_defconfig
 create mode 100644 configs/boston32r2el_defconfig
 create mode 100644 configs/boston64r2_defconfig
 create mode 100644 configs/boston64r2el_defconfig
 create mode 100644 doc/README.boston
 create mode 100644 include/configs/boston.h

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 21066f0..7ba0ef2 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -73,9 +73,25 @@ config MACH_PIC32
select OF_CONTROL
select DM
 
+config TARGET_BOSTON
+   bool "Support Boston"
+   select DM
+   select DM_SERIAL
+   select OF_CONTROL
+   select MIPS_L1_CACHE_SHIFT_6
+   select SUPPORTS_BIG_ENDIAN
+   select SUPPORTS_LITTLE_ENDIAN
+   select SUPPORTS_CPU_MIPS32_R1
+   select SUPPORTS_CPU_MIPS32_R2
+   select SUPPORTS_CPU_MIPS32_R6
+   select SUPPORTS_CPU_MIPS64_R1
+   select SUPPORTS_CPU_MIPS64_R2
+   select SUPPORTS_CPU_MIPS64_R6
+
 endchoice
 
 source "board/dbau1x00/Kconfig"
+source "board/imgtec/boston/Kconfig"
 source "board/imgtec/malta/Kconfig"
 source "board/micronas/vct/Kconfig"
 source "board/pb1x00/Kconfig"
diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index 2f04d73..6a5e43e 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -4,6 +4,7 @@
 
 dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
 dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
+dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
 dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
 dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
 dtb-$(CONFIG_BOARD_TPLINK_WDR4300) += tplink_wdr4300.dtb
diff --git a/arch/mips/dts/img,boston.dts b/arch/mips/dts/img,boston.dts
new file mode 100644
index 000..2fbcb93
--- /dev/null
+++ b/arch/mips/dts/img,boston.dts
@@ -0,0 +1,216 @@
+/dts-v1/;
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "img,boston";
+
+   chosen {
+   stdout-path = &uart0;
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "img,mips";
+   reg = <0>;
+   clocks = <&clk_boston BOSTON_CLK_CPU>;
+   };
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x 0x1000>;
+   };
+
+   gic: interrupt-controller {
+   compatible = "mti,gic";
+
+   interrupt-controller;
+   #interrupt-cells = <3>;
+
+   timer {
+   compatible = "mti,gic-timer";
+   interrupts = ;
+   clocks = <&clk_boston BOSTON_CLK_CPU>;
+   };
+   };
+
+   pci0: pci@1000 {
+   status = "disabled";
+   compatible = "xlnx,axi-pcie-host-1.00.a";
+   device_type = "pci";
+   reg = <0x1000 0x200>;
+
+   #addres

[U-Boot] [PATCH v4 09/11] dm: syscon: Provide a generic syscon driver

[Paul Burton]

Provide a trivial syscon driver matching the generic "syscon" compatible
string, allowing for simple system controllers to be used without a
custom driver just as in Linux.

Signed-off-by: Paul Burton 

---

Changes in v4: None
Changes in v3: None
Changes in v2:
- New patch

 drivers/core/syscon-uclass.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/core/syscon-uclass.c b/drivers/core/syscon-uclass.c
index 01bd968..2148469 100644
--- a/drivers/core/syscon-uclass.c
+++ b/drivers/core/syscon-uclass.c
@@ -95,3 +95,14 @@ UCLASS_DRIVER(syscon) = {
.per_device_auto_alloc_size = sizeof(struct syscon_uc_info),
.pre_probe = syscon_pre_probe,
 };
+
+static const struct udevice_id generic_syscon_ids[] = {
+   { .compatible = "syscon" },
+   { }
+};
+
+U_BOOT_DRIVER(generic_syscon) = {
+   .name   = "syscon",
+   .id = UCLASS_SYSCON,
+   .of_match = generic_syscon_ids,
+};
-- 
2.9.0

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

Re: [U-Boot] [PATCH v2 08/10] dm: syscon: Provide a generic syscon driver

[Paul Burton]

On 01/08/16 03:20, Simon Glass wrote:

Hi Paul,

On 27 July 2016 at 08:26, Paul Burton  wrote:

Provide a trivial syscon driver matching the generic "syscon" compatible
string, allowing for simple system controllers to be used without a
custom driver just as in Linux.

Signed-off-by: Paul Burton 

---

Changes in v2:
- New patch

 drivers/core/syscon-uclass.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/core/syscon-uclass.c b/drivers/core/syscon-uclass.c
index 01bd968..2148469 100644
--- a/drivers/core/syscon-uclass.c
+++ b/drivers/core/syscon-uclass.c
@@ -95,3 +95,14 @@ UCLASS_DRIVER(syscon) = {
.per_device_auto_alloc_size = sizeof(struct syscon_uc_info),
.pre_probe = syscon_pre_probe,
 };
+
+static const struct udevice_id generic_syscon_ids[] = {
+   { .compatible = "syscon" },
+   { }
+};
+
+U_BOOT_DRIVER(generic_syscon) = {
+   .name   = "syscon",
+   .id = UCLASS_SYSCON,
+   .of_match = generic_syscon_ids,
+};
--
2.9.0



This would work if driver model checked compatible strings in priority
order. But it does not.

lists_bind_fdt() checks every driver to see if it is compatible. So
your driver may be picked in preference to a more specific one.

I've been aware of this limitation but it hasn't come up until now.

I suppose the solution is to flip things around so that we:

1. Pick a node
2. Look at each compatible string in turn, starting from the first
(most specific)
3. Search for a driver for that string

Do you want to take a look?

Regards,
Simon



Hi Simon,

Ah - I wasn't aware of that discrepancy vs the device tree spec. I've 
just submitted v4 of my series which introduces a new patch 8 "dm: core: 
Match compatible strings in order of priority" which should fix that.


Thanks,
Paul
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 10/11] clk: boston: Providea simple driver for Boston board clocks

[Paul Burton]

Add a simple driver for the clocks provided by the MIPS Boston
development board. The system provides information about 2 clocks whose
rates are fixed by the bitfile flashed in the boards FPGA, and this
driver simply reads the rates of these 2 clocks.

Signed-off-by: Paul Burton 
Reviewed-by: Simon Glass 

---

Changes in v4:
- Replace EXT macro with ext_field function

Changes in v3: None
Changes in v2:
- New patch

 drivers/clk/Kconfig  |  8 +++
 drivers/clk/Makefile |  1 +
 drivers/clk/clk_boston.c | 97 
 include/dt-bindings/clock/boston-clock.h | 13 +
 4 files changed, 119 insertions(+)
 create mode 100644 drivers/clk/clk_boston.c
 create mode 100644 include/dt-bindings/clock/boston-clock.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 6eee8eb..85eea0d 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -20,6 +20,14 @@ config SPL_CLK
  setting up clocks within SPL, and allows the same drivers to be
  used as U-Boot proper.
 
+config CLK_BOSTON
+   def_bool y if TARGET_BOSTON
+   depends on CLK
+   select REGMAP
+   select SYSCON
+   help
+ Enable this to support the clocks
+
 source "drivers/clk/uniphier/Kconfig"
 source "drivers/clk/exynos/Kconfig"
 
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index f7a8891..9d14122 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -13,3 +13,4 @@ obj-$(CONFIG_SANDBOX) += clk_sandbox_test.o
 obj-$(CONFIG_MACH_PIC32) += clk_pic32.o
 obj-$(CONFIG_CLK_UNIPHIER) += uniphier/
 obj-$(CONFIG_CLK_EXYNOS) += exynos/
+obj-$(CONFIG_CLK_BOSTON) += clk_boston.o
diff --git a/drivers/clk/clk_boston.c b/drivers/clk/clk_boston.c
new file mode 100644
index 000..78f1b75
--- /dev/null
+++ b/drivers/clk/clk_boston.c
@@ -0,0 +1,97 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct clk_boston {
+   struct regmap *regmap;
+};
+
+#define BOSTON_PLAT_MMCMDIV0x30
+# define BOSTON_PLAT_MMCMDIV_CLK0DIV   (0xff << 0)
+# define BOSTON_PLAT_MMCMDIV_INPUT (0xff << 8)
+# define BOSTON_PLAT_MMCMDIV_MUL   (0xff << 16)
+# define BOSTON_PLAT_MMCMDIV_CLK1DIV   (0xff << 24)
+
+static uint32_t ext_field(uint32_t val, uint32_t mask)
+{
+   return (val & mask) >> (ffs(mask) - 1);
+}
+
+static ulong clk_boston_get_rate(struct clk *clk)
+{
+   struct clk_boston *state = dev_get_platdata(clk->dev);
+   uint32_t in_rate, mul, div;
+   uint mmcmdiv;
+   int err;
+
+   err = regmap_read(state->regmap, BOSTON_PLAT_MMCMDIV, &mmcmdiv);
+   if (err)
+   return 0;
+
+   in_rate = ext_field(mmcmdiv, BOSTON_PLAT_MMCMDIV_INPUT);
+   mul = ext_field(mmcmdiv, BOSTON_PLAT_MMCMDIV_MUL);
+
+   switch (clk->id) {
+   case BOSTON_CLK_SYS:
+   div = ext_field(mmcmdiv, BOSTON_PLAT_MMCMDIV_CLK0DIV);
+   break;
+   case BOSTON_CLK_CPU:
+   div = ext_field(mmcmdiv, BOSTON_PLAT_MMCMDIV_CLK1DIV);
+   break;
+   default:
+   return 0;
+   }
+
+   return (in_rate * mul * 100) / div;
+}
+
+const struct clk_ops clk_boston_ops = {
+   .get_rate = clk_boston_get_rate,
+};
+
+static int clk_boston_ofdata_to_platdata(struct udevice *dev)
+{
+   struct clk_boston *state = dev_get_platdata(dev);
+   struct udevice *syscon;
+   int err;
+
+   err = uclass_get_device_by_phandle(UCLASS_SYSCON, dev,
+  "regmap", &syscon);
+   if (err) {
+   error("unable to find syscon device\n");
+   return err;
+   }
+
+   state->regmap = syscon_get_regmap(syscon);
+   if (!state->regmap) {
+   error("unable to find regmap\n");
+   return -ENODEV;
+   }
+
+   return 0;
+}
+
+static const struct udevice_id clk_boston_match[] = {
+   {
+   .compatible = "img,boston-clock",
+   },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(clk_boston) = {
+   .name = "boston_clock",
+   .id = UCLASS_CLK,
+   .of_match = clk_boston_match,
+   .ofdata_to_platdata = clk_boston_ofdata_to_platdata,
+   .platdata_auto_alloc_size = sizeof(struct clk_boston),
+   .ops = &clk_boston_ops,
+};
diff --git a/include/dt-bindings/clock/boston-clock.h 
b/include/dt-bindings/clock/boston-clock.h
new file mode 100644
index 000..25f9cd2
--- /dev/null
+++ b/include/dt-bindings/clock/boston-clock.h
@@ -0,0 +1,13 @@
+/*
+ * Copyright (C) 2016 Imagination Technologies
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_BOSTON_CLOCK_H__
+#define __DT_BINDINGS_CLOCK_BOSTON_CLOCK_H__
+
+#define BOSTON_CLK_SYS 0
+#define BOSTON_CLK_CPU 1
+
+#endif /* __DT_BINDINGS_CLOCK_BOSTON_CLOCK_H__ */
-- 
2.9.0

_

Re: [U-Boot] [PATCH v4 00/11] MIPS Boston Development Board Support

[Michal Simek]

On 1.8.2016 12:06, Paul Burton wrote:
> This series introduces initial support for the MIPS Boston, and FPGA
> based development board & successor to the older Malta board. Further
> peripheral work is needed but this introduces the basics.
> 
> This can be tested in a currently out-of-tree QEMU port if desired,
> which can be found in the boston branch of:
> 
>   git://git.linux-mips.org/pub/scm/paul/qemu.git
> 
> QEMU can be used to run U-Boot like this:
> 
>   ./configure --target-list=mips64el-softmmu
>   make
>   ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \
> -bios u-boot.bin -serial stdio

I have tried it and nothing is coming up.

Latest u-boot + your patches
make boston64r2el_defconfig

and your qemu on ubuntu 14.

Can you recheck it?

Thanks,
Michal
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 00/11] MIPS Boston Development Board Support

[Paul Burton]

On 01/08/16 11:46, Michal Simek wrote:

On 1.8.2016 12:06, Paul Burton wrote:

This series introduces initial support for the MIPS Boston, and FPGA
based development board & successor to the older Malta board. Further
peripheral work is needed but this introduces the basics.

This can be tested in a currently out-of-tree QEMU port if desired,
which can be found in the boston branch of:

  git://git.linux-mips.org/pub/scm/paul/qemu.git

QEMU can be used to run U-Boot like this:

  ./configure --target-list=mips64el-softmmu
  make
  ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \
-bios u-boot.bin -serial stdio


I have tried it and nothing is coming up.

Latest u-boot + your patches
make boston64r2el_defconfig

and your qemu on ubuntu 14.

Can you recheck it?

Thanks,
Michal


Hi Michal,

This would be because U-Boot is being built for MIPS64r2 whilst QEMU is 
emulating the MIPS64r6-implementing I6400, and MIPSr6 isn't entirely 
backwards compatible with MIPSr2. If you reconfigure U-Boot to build for 
MIPS64r6 then you should find that it runs correctly. I'll add mention 
of that to the README file.


Thanks,
Paul
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 00/11] MIPS Boston Development Board Support

[Michal Simek]

On 1.8.2016 14:09, Paul Burton wrote:
> On 01/08/16 11:46, Michal Simek wrote:
>> On 1.8.2016 12:06, Paul Burton wrote:
>>> This series introduces initial support for the MIPS Boston, and FPGA
>>> based development board & successor to the older Malta board. Further
>>> peripheral work is needed but this introduces the basics.
>>>
>>> This can be tested in a currently out-of-tree QEMU port if desired,
>>> which can be found in the boston branch of:
>>>
>>>   git://git.linux-mips.org/pub/scm/paul/qemu.git
>>>
>>> QEMU can be used to run U-Boot like this:
>>>
>>>   ./configure --target-list=mips64el-softmmu
>>>   make
>>>   ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \
>>> -bios u-boot.bin -serial stdio
>>
>> I have tried it and nothing is coming up.
>>
>> Latest u-boot + your patches
>> make boston64r2el_defconfig
>>
>> and your qemu on ubuntu 14.
>>
>> Can you recheck it?
>>
>> Thanks,
>> Michal
> 
> Hi Michal,
> 
> This would be because U-Boot is being built for MIPS64r2 whilst QEMU is
> emulating the MIPS64r6-implementing I6400, and MIPSr6 isn't entirely
> backwards compatible with MIPSr2. If you reconfigure U-Boot to build for
> MIPS64r6 then you should find that it runs correctly. I'll add mention
> of that to the README file.

sorry don't have any overview about mips at all.
But last patch is adding 4 defconfigs 32r2 and 64r2 (big and little)
endian.

I do use
.buildman-toolchains/gcc-4.9.0-nolibc/mips-linux/bin//mips-linux-gcc

And getting this when I change it to mips64r6
mips-linux-gcc: error: unrecognized argument in option '-march=mips64r6'

Are there any toolchain at generic location which buildman can use?

Thanks,
Michal


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

Re: [U-Boot] [PATCH v4 00/11] MIPS Boston Development Board Support

[Paul Burton]

On 01/08/16 13:41, Michal Simek wrote:

On 1.8.2016 14:09, Paul Burton wrote:

On 01/08/16 11:46, Michal Simek wrote:

On 1.8.2016 12:06, Paul Burton wrote:

This series introduces initial support for the MIPS Boston, and FPGA
based development board & successor to the older Malta board. Further
peripheral work is needed but this introduces the basics.

This can be tested in a currently out-of-tree QEMU port if desired,
which can be found in the boston branch of:

  git://git.linux-mips.org/pub/scm/paul/qemu.git

QEMU can be used to run U-Boot like this:

  ./configure --target-list=mips64el-softmmu
  make
  ./mips64el-softmmu/qemu-system-mips64el -M boston -m 2G \
-bios u-boot.bin -serial stdio


I have tried it and nothing is coming up.

Latest u-boot + your patches
make boston64r2el_defconfig

and your qemu on ubuntu 14.

Can you recheck it?

Thanks,
Michal


Hi Michal,

This would be because U-Boot is being built for MIPS64r2 whilst QEMU is
emulating the MIPS64r6-implementing I6400, and MIPSr6 isn't entirely
backwards compatible with MIPSr2. If you reconfigure U-Boot to build for
MIPS64r6 then you should find that it runs correctly. I'll add mention
of that to the README file.


sorry don't have any overview about mips at all.
But last patch is adding 4 defconfigs 32r2 and 64r2 (big and little)
endian.

I do use
.buildman-toolchains/gcc-4.9.0-nolibc/mips-linux/bin//mips-linux-gcc

And getting this when I change it to mips64r6
mips-linux-gcc: error: unrecognized argument in option '-march=mips64r6'


Hi Michal,

Ah, and that's why the defconfigs were changed to MIPSr2 in v3 of the 
patchset. The Boston board can technically use CPUs implementing any 
architecture revision, but is most commonly used with ones implementing 
MIPSr6 hence the QEMU default. If it weren't for that buildman failure 
with MIPSr6 it'd be the Boston defconfig default too.



Are there any toolchain at generic location which buildman can use?


The toolchain I use is the codescape one available from imgtec.com:

http://codescape-mips-sdk.imgtec.com/components/toolchain/2015.06-05/

The "IMG GNU Linux Toolchain" from that page will suffice. Anything with 
gcc 5.x or newer should work too if you wanted to use crosstool-ng, 
buildroot or similar to produce a toolchain.


Thanks,
Paul
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] MAINTAINERS, git-mailrc: Update the mmc maintainer

[Pantelis Antoniou]

Hi Jaehoon,

> On Aug 1, 2016, at 06:35 , Jaehoon Chung  wrote:
> 
> Update the mmc maintainer from Pantelis to me.
> 
> Signed-off-by: Jaehoon Chung 

Acked-by: Pantelis Antoniou 

Good job!

> ---
> MAINTAINERS| 2 +-
> doc/git-mailrc | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 1225ce2..8905f88 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -299,7 +299,7 @@ T:git git://git.denx.de/u-boot-mips.git
> F:arch/mips/
> 
> MMC
> -M:   Pantelis Antoniou 
> +M:   Jaehoon Chung 
> S:Maintained
> T:git git://git.denx.de/u-boot-mmc.git
> F:drivers/mmc/
> diff --git a/doc/git-mailrc b/doc/git-mailrc
> index 8f0724f..a14629c 100644
> --- a/doc/git-mailrc
> +++ b/doc/git-mailrc
> @@ -23,6 +23,7 @@ alias galak  Kumar Gala 
> alias hs Heiko Schocher 
> alias ijcIan Campbell 
> alias iwamatsu   Nobuhiro Iwamatsu 
> +alias jaehoonJaehoon Chung 
> alias jagan  Jagan Teki 
> alias jasonjin   Jason Jin 
> alias jhersh Joe Hershberger 
> @@ -35,7 +36,6 @@ alias marex  Marek Vasut 
> alias masahiro   Masahiro Yamada 
> alias mateuszMateusz Kulikowski 
> alias monstr Michal Simek 
> -alias panto  Pantelis Antoniou 
> alias prafulla   Prafulla Wadaskar 
> alias bobenstein Przemyslaw Marczak 
> alias prom   Minkyu Kang 
> @@ -124,7 +124,7 @@ alias kerneldoc  uboot, marex
> alias fdtuboot, sjg
> alias i2cuboot, hs
> alias kconfiguboot, masahiro
> -alias mmcuboot, panto
> +alias mmcuboot, jaehoon
> alias nand   uboot, scottwood
> alias netuboot, jhersh
> alias phyuboot, jhersh
> -- 
> 1.9.1
> 

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

Re: [U-Boot] Network boot fallback usage/features

[Wolfgang Denk]

Dear Dragan,

In message <39afb55812f6cf1f1f955c73c6f12d32.squir...@webmail.tu-dortmund.de> 
you wrote:
> 
> I'm about to use U-Boot for an embedded project. I need a fallback


You posted the very same question  (three!) times within just a couple
of hours.  I highly recommend you to read [1], especially section [2].

> strategy if the network boot (no matter what exactly) fails e.g. no server
> reached after a timeout period. In this case it should boot an linux image
> from flash memory.
>
> The U-Boot docs say nothing about that...

Well, actually it does, even with a complete example.  See [3]

[1] http://catb.org/esr/faqs/smart-questions.html
[2] http://catb.org/esr/faqs/smart-questions.html#urgent
[2] http://www.denx.de/wiki/view/DULG/CommandLineParsing

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
Some programming languages manage to  absorb  change,  but  withstand
progress.  -- Epigrams in Programming, ACM SIGPLAN Sept. 1982
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 0/1] Fix U-Boot Prompt on CM-FX6 with enabled watchdog

[Andreas J. Reichel]

This patch fixes unwanted watchdog resets while the user enters
a command at the U-Boot prompt.

As found on the CM-FX6 board from Compulab, when having enabled the
watchdog, a missing WATCHDOG_RESET call in _serial_tstc() in
(/drivers/serial/serial-uclass.c) causes this and alike boards to
reset when the watchdog's timeout has elapsed while waiting at the
U-Boot prompt.

Despite the user could press several keys within the watchdog
timeout limit, the while loop in cli_readline.c, line 261, does only
call WATCHDOG_RESET if first == 1, which gets set to 0 in the 1st
loop iteration. This leads to a watchdog timeout no matter if the
user presses keys or not.

The problem is solved with a call to WATCHDOG_RESET in _serial_tstc,
defined in drivers/serial/serial-uclass.c.

Since the macro WATCHDOG_RESET expands to {} if watchdog support
isn't configured, there's no need to surround it by #ifdef in this
case.

Changes in v2:
 - Move WATCHDOG_RESET() call from common/console.c to
   drivers/serial/serial-uclass.c.

Andreas J. Reichel (1):
  watchdog: Fix Watchdog Reset while in U-Boot Prompt

 drivers/serial/serial-uclass.c | 1 +
 1 file changed, 1 insertion(+)

-- 
2.8.2

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

[U-Boot] [PATCH v2] watchdog: Fix Watchdog Reset while in U-Boot Prompt

[Andreas J. Reichel]

This patch fixes unwanted watchdog resets while the user enters
a command at the U-Boot prompt.

As found on the CM-FX6 board from Compulab, when having enabled the
watchdog, a missing WATCHDOG_RESET call in _serial_tstc() in
(/drivers/serial/serial-uclass.c) causes this and alike boards to
reset when the watchdog's timeout has elapsed while waiting at the
U-Boot prompt.

Despite the user could press several keys within the watchdog
timeout limit, the while loop in cli_readline.c, line 261, does only
call WATCHDOG_RESET if first == 1, which gets set to 0 in the 1st
loop iteration. This leads to a watchdog timeout no matter if the
user presses keys or not.

The problem is solved with a call to WATCHDOG_RESET in _serial_tstc,
defined in drivers/serial/serial-uclass.c.

Since the macro WATCHDOG_RESET expands to {} if watchdog support
isn't configured, there's no need to surround it by #ifdef in this
case.

 * Symptom:
   U-Boot resets after watchdog times out when in commandline prompt
   and watchdog is enabled.

 * Reasoning:
   When U-Boot shows the commandline prompt, the following function
   call stack is executed while waiting for a keypress:

   common/main.c:
main_loop  => common/cli.c: cli_loop() =>
   common/cli_hush.c:
parse_file_outer   => parse_stream_outer   =>
parse_stream   => b_getch(i)   =>
i->get(i)  => file_get =>
get_user_input => cmdedit_read_input   =>
uboot_cli_readline =>
   common/cli_readline.c:
cli_readline   => cli_readline_into_buffer =>
cread_line => getcmd_getch (== getc)   =>
   commonn/console.c:
fgetc  => console_tstc

   - in console_tstc line 181:
   If dev->tstc(dev) returns 0, the global tstcdev variable doesn't
   get set. This is the case if no character is in the serial buffer.

   - in fgetc(int file), line 297:
   Program flow keeps looping because tstcdev does not get set.
   Therefore WATCHDOG_RESET is not called, as mx_serial_tstc from
   drivers/serial/serial_mxc.c does not call it.

   - Initialization calls drv_system_init in stdio.c, which sets
   dev.tstc = stdio_serial_tstc. Thus, dev->tstc(dev) calls serial_tstc()
   which in turn calls _serial_tstc().

   Hence, _serial_tstc() needs to call WATCHDOG_RESET() to periodically
   reset the watchdog while cli_readline waits for user input.

Signed-off-by: Christian Storm 
Signed-off-by: Jan Kiszka 
Signed-off-by: Andreas J. Reichel 
---

Changes in v2:
 - Move WATCHDOG_RESET() call from common/console.c to
   drivers/serial/serial-uclass.c.

 drivers/serial/serial-uclass.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/serial/serial-uclass.c b/drivers/serial/serial-uclass.c
index 0ce5c44..72cf808 100644
--- a/drivers/serial/serial-uclass.c
+++ b/drivers/serial/serial-uclass.c
@@ -155,6 +155,7 @@ static int _serial_tstc(struct udevice *dev)
 {
struct dm_serial_ops *ops = serial_get_ops(dev);
 
+   WATCHDOG_RESET();
if (ops->pending)
return ops->pending(dev, true);
 
-- 
2.8.2

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

[U-Boot] [PATCH v1] ppc4xx: Fix platform support

[dirk . eibach]

From: Dirk Eibach 

Commit "ecc3066 Fix board init code to respect the C runtime environment"
broke platform support for ppc4xx.
start.S prepares a stackframe that is later rendered unusable by appending
the reserved space for global data.
Instead the reserved space has to be put first. Then the stackframe can
be pushed.

I can only test the 405EP OCM case. At least all other ppc4xx boards still
build.

Signed-off-by: Dirk Eibach 
---

 arch/powerpc/cpu/ppc4xx/start.S | 66 -
 1 file changed, 45 insertions(+), 21 deletions(-)

diff --git a/arch/powerpc/cpu/ppc4xx/start.S b/arch/powerpc/cpu/ppc4xx/start.S
index b432b18..f357726 100644
--- a/arch/powerpc/cpu/ppc4xx/start.S
+++ b/arch/powerpc/cpu/ppc4xx/start.S
@@ -743,8 +743,16 @@ _start:
/**/
/* Setup the stack in internal SRAM */
/**/
-   lis r1,CONFIG_SYS_INIT_RAM_ADDR@h
-   ori r1,r1,CONFIG_SYS_INIT_SP_OFFSET@l
+   lis r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@h
+   ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@l
+   /*
+* Reserve space for globals and store address for initialization
+* with board_init_f_init_reserve() in r14
+*/
+   mr  r3, r1
+   bl  board_init_f_alloc_reserve
+   mr  r1, r3
+   mr  r14, r3
li  r0,0
stwur0,-4(r1)
stwur0,-4(r1)   /* Terminate call chain */
@@ -760,13 +768,9 @@ _start:
 #endif
 
bl  cpu_init_f  /* run low-level CPU init code (from Flash) 
*/
-   mr  r3, r1
-   bl  board_init_f_alloc_reserve
-   mr  r1, r3
+   /* address for globals was stored in r14 */
+   mr  r3, r14
bl  board_init_f_init_reserve
-   li  r0,0
-   stwur0, -4(r1)
-   stwur0, -4(r1)
li  r3, 0
bl  board_init_f
/* NOTREACHED - board_init_f() does not return */
@@ -831,8 +835,16 @@ _start:
 * for their primordial stack, setup stack here directly after the
 * SDRAM is initialized in ext_bus_cntlr_init.
 */
-   lis r1, CONFIG_SYS_INIT_RAM_ADDR@h
-   ori r1,r1,CONFIG_SYS_INIT_SP_OFFSET /* set up the stack in SDRAM */
+   lis r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@h
+   ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@l
+   /*
+* Reserve space for globals and store address for initialization
+* with board_init_f_init_reserve() in r14
+*/
+   mr  r3, r1
+   bl  board_init_f_alloc_reserve
+   mr  r1, r3
+   mr  r14, r3
 
li  r0, 0   /* Make room for stack frame header and 
*/
stwur0, -4(r1)  /* clear final stack frame so that  
*/
@@ -972,8 +984,16 @@ _start:
 * Load the initial stack pointer and data area and convert the size,
 * in bytes, to the number of words to initialize to a known value.
 */
-   lis r1, CONFIG_SYS_INIT_RAM_ADDR@h
-   ori r1, r1, CONFIG_SYS_INIT_SP_OFFSET@l
+   lis r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@h
+   ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@l
+   /*
+* Reserve space for globals and store address for initialization
+* with board_init_f_init_reserve() in r14
+*/
+   mr  r3, r1
+   bl  board_init_f_alloc_reserve
+   mr  r1, r3
+   mr  r14, r3
 
lis r4, (CONFIG_SYS_INIT_RAM_SIZE >> 2)@h
ori r4, r4, (CONFIG_SYS_INIT_RAM_SIZE >> 2)@l
@@ -993,6 +1013,7 @@ _start:
 * Make room for stack frame header and clear final stack frame so
 * that stack backtraces terminate cleanly.
 */
+   li  r0, 0
stwur0, -4(r1)
stwur0, -4(r1)
 
@@ -1011,10 +1032,16 @@ _start:
/*
 * Stack in OCM.
 */
-
-   /* Set up Stack at top of OCM */
-   lis r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)@h
-   ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_SP_OFFSET)@l
+   lis r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@h
+   ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)@l
+   /*
+* Reserve space for globals and store address for initialization
+* with board_init_f_init_reserve() in r14
+*/
+   mr  r3, r1
+   bl  board_init_f_alloc_reserve
+   mr  r1, r3
+   mr  r14, r3
 
/* Set up a zeroized stack frame so that backtrace works right */
li  r0, 0
@@ -1035,12 +1062,9 @@ _start:
GET_GOT /* initialize GOT access
*/
 
  

Re: [U-Boot] [PATCH] Add a power domain framework/uclass

[Stephen Warren]

On 07/31/2016 07:01 PM, Simon Glass wrote:

Hi Stephen,

On 25 July 2016 at 10:50, Stephen Warren  wrote:

On 07/24/2016 08:07 PM, Simon Glass wrote:


Hi Stephen,

On 14 July 2016 at 22:17, Simon Glass  wrote:


Hi Stephen,

On 13 July 2016 at 13:45, Stephen Warren  wrote:


From: Stephen Warren 

Many SoCs allow power to be applied to or removed from portions of the
SoC
(power domains). This may be used to save power. This API provides the
means to control such power management hardware.

Signed-off-by: Stephen Warren 
---
I'll soon(?) send a Tegra186 power domain driver that implements this
new subsystem. I'm waiting for all the relevant DT bindings to be
reviewed as kernel patches first though.


...


Acked-by: Simon Glass 

Could you add a command (with list/on/off subcommands) to control this
also?



Any thoughts on this?

Applied to u-boot-dm, thanks!



Such a command sounds like a good idea. I'm a bit too swamped to do this
immediately though.

One issue to consider: How would the user specify which power domain to
control? There's no global namespace. Only individual drivers can parse
their own namespace, and there's no requirement that drivers identify each
powerdomain with e.g. a single integer or name, just like DT specificiers
can use multiple cells. I can think of two ways to handle this:

a) Add a new "op" function to the driver to allow converting the cmdline
arguments the user passed to the shell command into whatever value(s) the
driver uses to identify the power domain, e.g. "cmdline_xlate()". This has
the disadvantage of requiring extra code (although we could provide a
default implementation for the common code), but has the advantage of
allowing control over any powerdomain that any driver implements.

b) Make the command take a DT property node name and index, and have the
command look the powerdomain ID up from DT. This has the disadvantage of
limiting control to powerdomains that are already added to the DT, but does
have the advantage of not requiring any driver code.


Option 'b' sounds good. I notice with regulators that there is an
extra name in the DT (regulator-name). This is used by the 'pmic'
command. Should power domains have that too?


The DT bindings for power domains don't have a name, no.

The problem-domain and hence DT bindings for power domains are simpler 
than those for regulators. Regulators typically need a bunch of 
configuration and hence each have their own node that describes all kind 
of metadata and configuration for the regulator. Power domains are just 
identified by a (series of) number(s), and are assumed to be very simple 
on/off objects.

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

Re: [U-Boot] [PATCH] serial: bcm283x_mu: Detect disabled serial device

[Stephen Warren]

On 07/29/2016 03:49 PM, Alexander Graf wrote:

On the raspberry pi, you can disable the serial port to gain dynamic frequency
scaling which can get handy at times.

However, in such a configuration the serial controller gets its rx queue filled
up with zero bytes which then happily get transmitted on to whoever calls
getc() today.

This patch adds detection logic for that case and disables the mini uart if it
sends a zero byte during probe. That way we can leave the driver enabled in the
tree and can determine during runtime whether serial is usable or not.


I don't think this is the correct approach; it is quite possible and 
legal to receive a NULL character (which with this HW IIRC can also be 
triggered by a break condition on the line) even when the UART is fully 
operational. This could lead to false detection, and end up disabling 
the UART when it should not.


Rather, I would suggest detecting this condition based on some register 
content. The most direct might be to check the pinmux for the UART's RX 
pin, or perhaps whether the UART itself has been initialized.

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

Re: [U-Boot] [PATCH 1/5] pci: tegra: port to standard clock/reset/pwr domain APIs

[Stephen Warren]

On 07/31/2016 07:02 PM, Simon Glass wrote:

Hi Stephen,

On 27 July 2016 at 15:48, Stephen Warren  wrote:

From: Stephen Warren 

Tegra186 supports the new standard clock, reset, and power domain APIs.
Older Tegra SoCs still use custom APIs. Enhance the Tegra PCIe driver so
that it can operate with either set of APIs.

On Tegra186, the BPMP handles all aspects of PCIe PHY (UPHY) programming.
Consequently, this logic is disabled too.

Signed-off-by: Stephen Warren 
---
This whole series builds on the other Tegra186 series that I just sent.

 drivers/pci/Kconfig |   1 +
 drivers/pci/pci_tegra.c | 154 ++--
 2 files changed, 150 insertions(+), 5 deletions(-)

diff --git a/drivers/pci/Kconfig b/drivers/pci/Kconfig
index 26aa2b0930a0..669e37bb5dc5 100644
--- a/drivers/pci/Kconfig
+++ b/drivers/pci/Kconfig
@@ -31,6 +31,7 @@ config PCI_SANDBOX
 config PCI_TEGRA
bool "Tegra PCI support"
depends on TEGRA
+   depends on (TEGRA186 && POWER_DOMAIN) || (!TEGRA186)
help
  Enable support for the PCIe controller found on some generations of
  Tegra. Tegra20 has 2 root ports with a total of 4 lanes, Tegra30 has
diff --git a/drivers/pci/pci_tegra.c b/drivers/pci/pci_tegra.c
index 352cdef56ab4..a6785ad0bbee 100644
--- a/drivers/pci/pci_tegra.c
+++ b/drivers/pci/pci_tegra.c
@@ -13,22 +13,26 @@
 #define pr_fmt(fmt) "tegra-pcie: " fmt

 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 

 #include 
 #include 

+#include 
+
+#ifndef CONFIG_TEGRA186
 #include 
 #include 
 #include 
-
-#include 
-
 #include 
+#endif

 DECLARE_GLOBAL_DATA_PTR;

@@ -103,6 +107,9 @@ DECLARE_GLOBAL_DATA_PTR;
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_222   (0x1 << 20)
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_X4_X1 (0x1 << 20)
 #define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_411   (0x2 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_401  (0x0 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_211  (0x1 << 20)
+#define  AFI_PCIE_CONFIG_SM2TMS0_XBAR_CONFIG_T186_111  (0x2 << 20)

 #define AFI_FUSE   0x104
 #define  AFI_FUSE_PCIE_T0_GEN2_DIS (1 << 2)
@@ -110,6 +117,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define AFI_PEX0_CTRL  0x110
 #define AFI_PEX1_CTRL  0x118
 #define AFI_PEX2_CTRL  0x128
+#define AFI_PEX2_CTRL_T186 0x19c
 #define  AFI_PEX_CTRL_RST  (1 << 0)
 #define  AFI_PEX_CTRL_CLKREQ_EN(1 << 1)
 #define  AFI_PEX_CTRL_REFCLK_EN(1 << 3)
@@ -173,6 +181,7 @@ enum tegra_pci_id {
TEGRA30_PCIE,
TEGRA124_PCIE,
TEGRA210_PCIE,
+   TEGRA186_PCIE,
 };

 struct tegra_pcie_port {
@@ -189,6 +198,7 @@ struct tegra_pcie_soc {
unsigned int num_ports;
unsigned long pads_pll_ctl;
unsigned long tx_ref_sel;
+   unsigned long afi_pex2_ctrl;
u32 pads_refclk_cfg0;
u32 pads_refclk_cfg1;
bool has_pex_clkreq_en;
@@ -209,7 +219,17 @@ struct tegra_pcie {
unsigned long xbar;

const struct tegra_pcie_soc *soc;
+
+#ifdef CONFIG_TEGRA186
+   struct clk clk_afi;
+   struct clk clk_pex;
+   struct reset_ctl reset_afi;
+   struct reset_ctl reset_pex;
+   struct reset_ctl reset_pcie_x;
+   struct power_domain pwrdom;
+#else


Eek. This is a compile-time driver configuration. Can you use the
device tree compatible string to detect which to use?


No. The legacy APIs are simply not available (not compiled in) on the 
newer SoCs, so there must be a compile-time condition.


It is theoretically possible to convert all the old SoCs to the new APIs 
so that this conditional goes away in the future, but we don't have that 
work scheduled at present.

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

Re: [U-Boot] [PATCH 3/5] i2c: tegra: add standardized clk/reset API support

[Stephen Warren]

On 07/31/2016 07:02 PM, Simon Glass wrote:

Hi Stephen,

On 27 July 2016 at 15:48, Stephen Warren  wrote:

From: Bryan Wu 

clk/reset API was tested on T186 platform and previous chip like
T210/T124 will still use the old APIs.



diff --git a/drivers/i2c/tegra_i2c.c b/drivers/i2c/tegra_i2c.c



@@ -30,7 +35,12 @@ enum i2c_type {
 /* Information about i2c controller */
 struct i2c_bus {
int id;
+#ifdef CONFIG_TEGRA186
+   struct reset_ctlreset_ctl;
+   struct clk  clk;
+#else
enum periph_id  periph_id;
+#endif


This doesn't seem right - the drivers should be SoC-independent at compile-time.


Same comment as before; there's not yet a common clock/reset API 
implementation except on the latest SoC.



@@ -370,7 +437,12 @@ static int tegra_i2c_probe(struct udevice *dev)
i2c_init_controller(i2c_bus);
debug("%s: controller bus %d at %p, periph_id %d, speed %d: ",
  is_dvc ? "dvc" : "i2c", dev->seq, i2c_bus->regs,
- i2c_bus->periph_id, i2c_bus->speed);
+#ifndef CONFIG_TEGRA186
+ i2c_bus->periph_id,


Probably the concept of periph_id can go away now? Perhaps this driver
needs a clean-up?


It's still needed for the legacy APIs on older SoCs.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/2] cmd: Split 'bootz' and 'booti' out from 'bootm'

[Tom Rini]

The bootz and booti commands rely on common functionality that is found
in common/bootm.c and common/bootm_os.c.  They do not however rely on
the rest of cmd/bootm.c to be implemented so split them into their own
files.  Have various Makefiles include the required infrastructure for
CONFIG_CMD_BOOT[IZ] as well as CONFIG_CMD_BOOTM.

Signed-off-by: Tom Rini 
---
 arch/arm/lib/Makefile |   2 +-
 arch/sandbox/lib/Makefile |   1 +
 cmd/Makefile  |   2 +
 cmd/booti.c   | 161 ++
 cmd/bootm.c   | 248 --
 cmd/bootz.c   | 106 
 common/Makefile   |   2 +
 7 files changed, 273 insertions(+), 249 deletions(-)
 create mode 100644 cmd/booti.c
 create mode 100644 cmd/bootz.c

diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile
index 9f71376..b754026 100644
--- a/arch/arm/lib/Makefile
+++ b/arch/arm/lib/Makefile
@@ -27,7 +27,7 @@ endif
 obj-$(CONFIG_CPU_V7M) += cmd_boot.o
 obj-$(CONFIG_OF_LIBFDT) += bootm-fdt.o
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
-obj-$(CONFIG_CMD_BOOTM) += zimage.o
+obj-$(CONFIG_CMD_BOOTZ) += bootm.o zimage.o
 obj-$(CONFIG_SYS_L2_PL310) += cache-pl310.o
 obj-$(CONFIG_USE_ARCH_MEMSET) += memset.o
 obj-$(CONFIG_USE_ARCH_MEMCPY) += memcpy.o
diff --git a/arch/sandbox/lib/Makefile b/arch/sandbox/lib/Makefile
index 7820c55..2e7802f 100644
--- a/arch/sandbox/lib/Makefile
+++ b/arch/sandbox/lib/Makefile
@@ -12,3 +12,4 @@ ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_PCI)  += pci_io.o
 endif
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
+obj-$(CONFIG_CMD_BOOTZ) += bootm.o
diff --git a/cmd/Makefile b/cmd/Makefile
index a1731be..e4c43e7 100644
--- a/cmd/Makefile
+++ b/cmd/Makefile
@@ -26,6 +26,8 @@ obj-$(CONFIG_CMD_BOOTEFI) += bootefi.o
 obj-$(CONFIG_CMD_BOOTMENU) += bootmenu.o
 obj-$(CONFIG_CMD_BOOTLDR) += bootldr.o
 obj-$(CONFIG_CMD_BOOTSTAGE) += bootstage.o
+obj-$(CONFIG_CMD_BOOTZ) += bootm.o bootz.o
+obj-$(CONFIG_CMD_BOOTI) += bootm.o booti.o
 obj-$(CONFIG_CMD_CACHE) += cache.o
 obj-$(CONFIG_CMD_CBFS) += cbfs.o
 obj-$(CONFIG_CMD_CLK) += clk.o
diff --git a/cmd/booti.c b/cmd/booti.c
new file mode 100644
index 000..6c1c998
--- /dev/null
+++ b/cmd/booti.c
@@ -0,0 +1,161 @@
+/*
+ * (C) Copyright 2000-2009
+ * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* See Documentation/arm64/booting.txt in the Linux kernel */
+struct Image_header {
+   uint32_tcode0;  /* Executable code */
+   uint32_tcode1;  /* Executable code */
+   uint64_ttext_offset;/* Image load offset, LE */
+   uint64_timage_size; /* Effective Image size, LE */
+   uint64_tres1;   /* reserved */
+   uint64_tres2;   /* reserved */
+   uint64_tres3;   /* reserved */
+   uint64_tres4;   /* reserved */
+   uint32_tmagic;  /* Magic number */
+   uint32_tres5;
+};
+
+#define LINUX_ARM64_IMAGE_MAGIC0x644d5241
+
+static int booti_setup(bootm_headers_t *images)
+{
+   struct Image_header *ih;
+   uint64_t dst;
+   uint64_t image_size;
+
+   ih = (struct Image_header *)map_sysmem(images->ep, 0);
+
+   if (ih->magic != le32_to_cpu(LINUX_ARM64_IMAGE_MAGIC)) {
+   puts("Bad Linux ARM64 Image magic!\n");
+   return 1;
+   }
+   
+   if (ih->image_size == 0) {
+   puts("Image lacks image_size field, assuming 16MiB\n");
+   image_size = 16 << 20;
+   } else {
+   image_size = le64_to_cpu(ih->image_size);
+   }
+
+   /*
+* If we are not at the correct run-time location, set the new
+* correct location and then move the image there.
+*/
+   dst = gd->bd->bi_dram[0].start + le64_to_cpu(ih->text_offset);
+
+   unmap_sysmem(ih);
+
+   if (images->ep != dst) {
+   void *src;
+
+   debug("Moving Image from 0x%lx to 0x%llx\n", images->ep, dst);
+
+   src = (void *)images->ep;
+   images->ep = dst;
+   memmove((void *)dst, src, image_size);
+   }
+
+   return 0;
+}
+
+/*
+ * Image booting support
+ */
+static int booti_start(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[], bootm_headers_t *images)
+{
+   int ret;
+   struct Image_header *ih;
+
+   ret = do_bootm_states(cmdtp, flag, argc, argv, BOOTM_STATE_START,
+ images, 1);
+
+   /* Setup Linux kernel Image entry point */
+   if (!argc) {
+   images->ep = load_addr;
+   debug("*  kernel: default image load address = 0x%08lx\n",
+   load_addr);
+   } else {
+   images->ep = simple_strt

[U-Boot] [PATCH v2 2/2] cmd: booti: move CONFIG_CMD_BOOTI to Kconfig

[Tom Rini]

From: Masahiro Yamada 

This command is used to boot ARM64 Linux.

I made DISTRO_DEFAULTS select this option for ARM64 to respect
include/config_distro_defaults.h.

Signed-off-by: Masahiro Yamada 
Signed-off-by: Tom Rini 
---
Changes in v2:
- Move to default y so this isn't in the defconfig files
- Reword help text slightly
---
 Kconfig   | 1 +
 cmd/Kconfig   | 7 +++
 include/config_distro_defaults.h  | 3 ---
 include/configs/uniphier.h| 1 -
 include/configs/vexpress_aemv8a.h | 1 -
 include/configs/xilinx_zynqmp.h   | 1 -
 6 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/Kconfig b/Kconfig
index ef12f9f..189bcf4 100644
--- a/Kconfig
+++ b/Kconfig
@@ -58,6 +58,7 @@ config DISTRO_DEFAULTS
default y if ARCH_SUNXI
default n
select CMD_BOOTZ
+   select CMD_BOOTI if ARM64
select CMD_DHCP
select CMD_EXT2
select CMD_EXT4
diff --git a/cmd/Kconfig b/cmd/Kconfig
index d69b817..e219246 100644
--- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -165,6 +165,13 @@ config CMD_BOOTZ
help
  Boot the Linux zImage
 
+config CMD_BOOTI
+   bool "booti"
+   depends on ARM64
+   default y
+   help
+ Boot an AArch64 Linux Kernel image from memory.
+
 config CMD_BOOTEFI
bool "bootefi"
depends on EFI_LOADER
diff --git a/include/config_distro_defaults.h b/include/config_distro_defaults.h
index 9244680..b5efab5 100644
--- a/include/config_distro_defaults.h
+++ b/include/config_distro_defaults.h
@@ -20,9 +20,6 @@
 #define CONFIG_BOOTP_PXE
 #define CONFIG_BOOTP_SUBNETMASK
 
-#ifdef CONFIG_ARM64
-#define CONFIG_CMD_BOOTI
-#endif
 #define CONFIG_CMD_PXE
 
 #define CONFIG_CMDLINE_EDITING
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index e485583..7e6d5a5 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -183,7 +183,6 @@
"__nfsboot=run tftpboot\0"
 #else
 #ifdef CONFIG_ARM64
-#define CONFIG_CMD_BOOTI
 #define CONFIG_BOOTFILE"Image"
 #define LINUXBOOT_CMD  "booti"
 #define KERNEL_ADDR_R  "kernel_addr_r=0x8008\0"
diff --git a/include/configs/vexpress_aemv8a.h 
b/include/configs/vexpress_aemv8a.h
index 46cf83b..9aca393 100644
--- a/include/configs/vexpress_aemv8a.h
+++ b/include/configs/vexpress_aemv8a.h
@@ -133,7 +133,6 @@
 /* Command line configuration */
 #define CONFIG_MENU
 /*#define CONFIG_MENU_SHOW*/
-#define CONFIG_CMD_BOOTI
 #define CONFIG_CMD_UNZIP
 #define CONFIG_CMD_PXE
 #define CONFIG_CMD_ENV
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index e776e32..173e0c9 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -206,7 +206,6 @@
 
 #define CONFIG_SYS_BOOTM_LEN   (60 * 1024 * 1024)
 
-#define CONFIG_CMD_BOOTI
 #define CONFIG_CMD_UNZIP
 
 #define CONFIG_BOARD_EARLY_INIT_R
-- 
1.9.1

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

Re: [U-Boot] [PATCH 2/9] ARM: tegra: add BPMP DT bindings

[Stephen Warren]

On 07/31/2016 07:02 PM, Simon Glass wrote:

On 27 July 2016 at 15:24, Stephen Warren  wrote:

From: Stephen Warren 

The Tegra BPMP (Boot and Power Management Processor) is a separate
auxiliary CPU embedded into Tegra to perform power management work, and
controls related features such as clocks, resets, power domains, PMIC I2C
bus, etc. These bindings dictate how to represent the BPMP in device tree.



Reviewed-by: Simon Glass 

The comment format seems novel. Is it docbook-compatible?


I think that it's Doxygen.

Note that the BPMP FW team publishes these headers along with the FW. I 
deliberately didn't change these files beyond adapting to the U-Boot 
license header format so that incorporating further updates from that 
team would be trivial.

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

[U-Boot] [PATCH 1/4] Introduce CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE

[Andrew F. Davis]

Introduce CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE. An SPL which define
this will panic() if the image it has loaded is not a FIT image.

Signed-off-by: Andrew F. Davis 
---
 Kconfig  | 8 
 common/spl/spl.c | 4 
 2 files changed, 12 insertions(+)

diff --git a/Kconfig b/Kconfig
index ef12f9f..4c03716 100644
--- a/Kconfig
+++ b/Kconfig
@@ -336,6 +336,14 @@ config SPL_FIT_IMAGE_POST_PROCESS
  injected into the FIT creation (i.e. the blobs would have been pre-
  processed before being added to the FIT image).
 
+config SPL_PANIC_ON_NON_FIT_IMAGE
+   bool "Disable SPL loading of non-FIT images"
+   help
+ SPL will panic() if the image loaded is not a FIT image. This is
+ useful for devices that only support authentication/encryption
+ through SPL FIT loading paths and do not want SPL falling back
+ to legacy image loading when a non-FIT image is present.
+
 config SYS_CLK_FREQ
depends on ARC || ARCH_SUNXI
int "CPU clock frequency"
diff --git a/common/spl/spl.c b/common/spl/spl.c
index b7ec333..7a30c7d 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -93,6 +93,9 @@ void spl_set_header_raw_uboot(void)
 
 int spl_parse_image_header(const struct image_header *header)
 {
+#ifdef CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE
+   panic("** non-FIT images are not supported");
+#else
u32 header_size = sizeof(struct image_header);
 
if (image_get_magic(header) == IH_MAGIC) {
@@ -153,6 +156,7 @@ int spl_parse_image_header(const struct image_header 
*header)
spl_set_header_raw_uboot();
 #endif
}
+#endif
return 0;
 }
 
-- 
2.9.2

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

[U-Boot] [PATCH 3/4] ARM: AM437x: Disable non-FIT based image loading for HS devices

[Andrew F. Davis]

Disable support for loading non-FIT images for AM437x platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
---
 configs/am43xx_hs_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am43xx_hs_evm_defconfig b/configs/am43xx_hs_evm_defconfig
index c8ce723..fc2b8b0 100644
--- a/configs/am43xx_hs_evm_defconfig
+++ b/configs/am43xx_hs_evm_defconfig
@@ -14,6 +14,7 @@ CONFIG_FIT=y
 CONFIG_SYS_EXTRA_OPTIONS="CONS_INDEX=1, NAND"
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE=y
 CONFIG_HUSH_PARSER=y
 CONFIG_CMD_BOOTZ=y
 # CONFIG_CMD_IMLS is not set
-- 
2.9.2

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

[U-Boot] [PATCH 2/4] ARM: AM57xx: Disable non-FIT based image loading for HS devices

[Andrew F. Davis]

Disable support for loading non-FIT images for AM57xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
---
 configs/am57xx_hs_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/am57xx_hs_evm_defconfig b/configs/am57xx_hs_evm_defconfig
index a4bfdd5..e6f3ebc 100644
--- a/configs/am57xx_hs_evm_defconfig
+++ b/configs/am57xx_hs_evm_defconfig
@@ -41,6 +41,7 @@ CONFIG_FIT=y
 CONFIG_SPL_OF_LIBFDT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE=y
 CONFIG_OF_LIST="am57xx-beagle-x15"
 CONFIG_DM_I2C=y
 CONFIG_DM_SPI=y
-- 
2.9.2

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

[U-Boot] [PATCH 0/4] Allow disabling non-FIT image loading from SPL

[Andrew F. Davis]

Hello all,

To address a needed feature brought up by Andreas[0], we need a way to
disable SPL from loading non-FIT images.

The function spl_parse_image_header is common to all SPL loading paths
(common/spl/spl_(nand|net|nor|etc..)) so we add the check here, much
like the existing CONFIG_SPL_PANIC_ON_RAW_IMAGE.

My original attempt was to add CONFIG_SPL_PANIC_ON_MKIMAGE, but then if other
formats are added, flaws in restricting image types may be introduced, so we
would like a single option to restrict all non-FIT types vs disabling types
individually.

Thanks,
Andrew

[0]: https://www.mail-archive.com/u-boot@lists.denx.de/msg219253.html

Andrew F. Davis (4):
  Introduce CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE
  ARM: AM57xx: Disable non-FIT based image loading for HS devices
  ARM: AM437x: Disable non-FIT based image loading for HS devices
  ARM: DRA7xx: Disable non-FIT based image loading for HS devices

 Kconfig | 8 
 common/spl/spl.c| 4 
 configs/am43xx_hs_evm_defconfig | 1 +
 configs/am57xx_hs_evm_defconfig | 1 +
 configs/dra7xx_hs_evm_defconfig | 1 +
 5 files changed, 15 insertions(+)

-- 
2.9.2

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

[U-Boot] [PATCH 4/4] ARM: DRA7xx: Disable non-FIT based image loading for HS devices

[Andrew F. Davis]

Disable support for loading non-FIT images for DRA7xx platforms using
the high-security (HS) device variant.

Signed-off-by: Andrew F. Davis 
---
 configs/dra7xx_hs_evm_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/dra7xx_hs_evm_defconfig b/configs/dra7xx_hs_evm_defconfig
index faf9cd5..63801fe 100644
--- a/configs/dra7xx_hs_evm_defconfig
+++ b/configs/dra7xx_hs_evm_defconfig
@@ -59,5 +59,6 @@ CONFIG_FIT=y
 CONFIG_SPL_OF_LIBFDT=y
 CONFIG_SPL_LOAD_FIT=y
 CONFIG_SPL_FIT_IMAGE_POST_PROCESS=y
+CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE=y
 CONFIG_OF_LIST="dra7-evm dra72-evm"
 CONFIG_DM_I2C=y
-- 
2.9.2

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

Re: [U-Boot] [PATCH] serial: bcm283x_mu: Detect disabled serial device

[Alexander Graf]

> On 01 Aug 2016, at 16:20, Stephen Warren  wrote:
> 
> On 07/29/2016 03:49 PM, Alexander Graf wrote:
>> On the raspberry pi, you can disable the serial port to gain dynamic 
>> frequency
>> scaling which can get handy at times.
>> 
>> However, in such a configuration the serial controller gets its rx queue 
>> filled
>> up with zero bytes which then happily get transmitted on to whoever calls
>> getc() today.
>> 
>> This patch adds detection logic for that case and disables the mini uart if 
>> it
>> sends a zero byte during probe. That way we can leave the driver enabled in 
>> the
>> tree and can determine during runtime whether serial is usable or not.
> 
> I don't think this is the correct approach; it is quite possible and legal to 
> receive a NULL character (which with this HW IIRC can also be triggered by a 
> break condition on the line) even when the UART is fully operational. This 
> could lead to false detection, and end up disabling the UART when it should 
> not.

Right, that’s why I tried to be very careful about the detection and only have 
it triggered when the very first byte ever received is a null byte. Any bytes 
after that don’t affect it.

> Rather, I would suggest detecting this condition based on some register 
> content. The most direct might be to check the pinmux for the UART's RX pin, 
> or perhaps whether the UART itself has been initialized.

Hmm. I can try and dig through the documentation again to see whether there is 
a way.


Alex

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

Re: [U-Boot] [PATCH 4/9] misc: add Tegra BPMP driver

[Stephen Warren]

On 07/31/2016 07:02 PM, Simon Glass wrote:

On 27 July 2016 at 15:24, Stephen Warren  wrote:

From: Stephen Warren 

The Tegra BPMP (Boot and Power Management Processor) is a separate
auxiliary CPU embedded into Tegra to perform power management work, and
controls related features such as clocks, resets, power domains, PMIC I2C
bus, etc. This driver provides the core low-level communication path by
which feature-specific drivers (such as clock) can make requests to the
BPMP. This driver is similar to an MFD driver in the Linux kernel. It is
unconditionally selected by CONFIG_TEGRA186 since virtually any Tegra186
build of U-Boot will need the feature.



diff --git a/arch/arm/include/asm/arch-tegra/bpmp_abi.h 
b/arch/arm/include/asm/arch-tegra/bpmp_abi.h
new file mode 100644
index ..0aaef5960e29
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/bpmp_abi.h
@@ -0,0 +1,1601 @@
+/*
+ * Copyright (c) 2014-2016, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .


Can this use SPDX? Or if it is generated, where from?


I forgot to convert this one. These headers are shipped alongside the 
BPMP FW so I deliberately edited it as little as possible, but I did 
mean to convert the license header.



diff --git a/drivers/misc/tegra186_bpmp.c b/drivers/misc/tegra186_bpmp.c



+int tegra186_bpmp_call(struct udevice *dev, uint32_t mrq,
+  void *tx_msg, uint32_t tx_size,
+  void *rx_msg, uint32_t rx_size)


... Also why is this exported? Shouldn't calls come in via DM??


This is an internal API between the core BPMP driver and the "services" 
drivers that are part of it. More below.



+/**
+ * The BPMP exposes multiple different services. We create a sub-device for
+ * each separate type of service, since each device must be of the appropriate
+ * UCLASS.
+ */
+static int tegra186_bpmp_bind(struct udevice *dev)
+{
+   int ret;
+   struct udevice *child;
+
+   debug("%s(dev=%p)\n", __func__, dev);
+
+   ret = device_bind_driver_to_node(dev, "tegra186_clk", "tegra186_clk",
+dev->of_offset, &child);
+   if (ret)
+   return ret;
+
+   ret = device_bind_driver_to_node(dev, "tegra186_reset",
+"tegra186_reset", dev->of_offset,
+&child);
+   if (ret)
+   return ret;
+
+   ret = device_bind_driver_to_node(dev, "tegra186_power_domain",
+"tegra186_power_domain",
+dev->of_offset, &child);
+   if (ret)
+   return ret;


What's happening here? Is there one device tree node with 3 devices?


The BPMP is a single device, hence a single DT node, that exports a 
multitude of services. This file/patch is the top-level/core driver for 
the BPMP. This function is instantiating a separate U-Boot driver for 
each type of service; DM requires each device/drive object be a single 
uclass. This is logically extremely similar to MFD devices in the Linux 
kernel.



+static ulong tegra186_bpmp_get_shmem(struct udevice *dev, int index)
+{
+   int ret;
+   struct fdtdec_phandle_args args;
+   struct udevice fakedev;
+   fdt_addr_t reg;
+
+   ret = fdtdec_parse_phandle_with_args(gd->fdt_blob, dev->of_offset,
+ "shmem", NULL, 0, index, &args);
+   if (ret < 0) {
+   error("fdtdec_parse_phandle_with_args() failed: %d\n", ret);
+   return ret;
+   }
+
+   fakedev.of_offset = args.node;
+   reg = dev_get_addr_index(&fakedev, 0);


This is nasty. If you don't set fakedev.parent, how does this work?


Hmmm. Good question; I thought dev_get_addr_index() only used the 
device's own of_offset, but it does look like it uses the parent device 
too. I'll have to look into this.



Can you instead call fdtdec_get_addr_size_auto_parent() or similar?


dev_get_addr_index() is the only API which applies address translation 
(i.e. processes the DT ranges property).



+static void tegra186_bpmp_ivc_notify(struct tegra_ivc *ivc)
+{
+   struct tegra186_bpmp *priv =
+   container_of(ivc, struct tegra186_bpmp, ivc);
+   int ret;
+
+   ret = mbox_send(&priv->mbox, NULL);
+   if (ret)
+   error("mbox_send() failed: %d\n", r

Re: [U-Boot] [PATCH 5/9] clock: add Tegra186 clock driver

[Stephen Warren]

On 07/31/2016 07:02 PM, Simon Glass wrote:

Hi Stephen,

On 27 July 2016 at 15:24, Stephen Warren  wrote:

From: Stephen Warren 

In Tegra186, on-SoC clocks are manipulated using IPC requests to the BPMP
(Boot and Power Management Processor). This change implements a driver
that does that. A tegra/ sub-directory is created to follow the existing
pattern. It is unconditionally selected by CONFIG_TEGRA186 since virtually
any Tegra186 build of U-Boot will need the feature.



diff --git a/drivers/clk/tegra/tegra186-clk.c b/drivers/clk/tegra/tegra186-clk.c



+static ulong tegra186_clk_get_rate(struct clk *clk)
+{
+   struct mrq_clk_request req;
+   struct mrq_clk_response resp;
+   int ret;
+
+   debug("%s(clk=%p) (dev=%p, id=%lu)\n", __func__, clk, clk->dev,
+ clk->id);
+
+   req.cmd_and_id = (CMD_CLK_GET_RATE << 24) | clk->id;
+
+   ret = tegra186_bpmp_call(clk->dev->parent, MRQ_CLK,
+&req, sizeof(req), &resp, sizeof(resp));


Isn't his a MISC driver? Perhaps you can add a new method to
UCLASS_MISC matching your requirements here?


The core BPMP driver is a MISC driver, yes.

I don't see any advantage of making this call something that the MISC 
uclass supports directly. This function is an internal implementation 
detail of the BPMP, and certainly not something that every single MISC 
driver (for any SoC for any HW module) would implement. If we did add 
direct support to the MISC uclass, then the MISC "ops" structure would 
basically grow forever since every single SoC's/HW's internal function 
calls would be added to it. This would just bloat it up unnecessarily, 
and I don't see any advantage to offset the disadvantage of that bloat.


FWIW, the Linux MFD (Multi-Function Devices) stack typically has "child" 
(sub-)devices call custom APIs like this on the "parent"/container.

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

Re: [U-Boot] [PATCH 8/9] mmc: tegra: port to standard clock/reset APIs

[Stephen Warren]

On 07/31/2016 08:20 PM, Simon Glass wrote:

Hi Stephen,

On 27 July 2016 at 15:24, Stephen Warren  wrote:

From: Stephen Warren 

Tegra186 supports the new standard clock and reset APIs. Older Tegra SoCs
still use custom APIs. Enhance the Tegra MMC driver so that it can operate
with either set of APIs.

Signed-off-by: Stephen Warren 
Cc: Pantelis Antoniou 
---
 arch/arm/include/asm/arch-tegra/tegra_mmc.h |  8 -
 drivers/mmc/tegra_mmc.c | 55 -
 2 files changed, 53 insertions(+), 10 deletions(-)


Shouldn't we fix up the code to all use the new APIs?


Eventually yes. However, that's something that will take a lot of work. 
When similar common APIs were introduced into Linux, there was a 
transition period of 1-2 years where new code was immediately written to 
the new APIs, and old code (e.g. legacy clock API implementation, and 
its callers) was slowly converted. I would expect the same thing in 
U-Boot; any other approach means preventing new work until the 
conversions are complete, which would be rather stagnating.

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

Re: [U-Boot] [PATCH 2/7] misc: Tegra BPMP: support child node devices

[Stephen Warren]

On 07/31/2016 07:03 PM, Simon Glass wrote:

On 29 July 2016 at 13:15, Stephen Warren  wrote:

From: Stephen Warren 

The BPMP bindings allow devices to be represented as child nodes of the
BPMP node. This requires the driver to trigger scanning of its node for



diff --git a/drivers/misc/tegra186_bpmp.c b/drivers/misc/tegra186_bpmp.c
index 147528da9269..526d812ecd39 100644
--- a/drivers/misc/tegra186_bpmp.c
+++ b/drivers/misc/tegra186_bpmp.c
@@ -129,6 +129,10 @@ static int tegra186_bpmp_bind(struct udevice *dev)
if (ret)
return ret;

+   ret = dm_scan_fdt_node(dev, gd->fdt_blob, dev->of_offset, false);
+   if (ret)
+   return ret;
+


Can you use dm_scan_fdt_dev() here? Hot off the press.


It looks like it, yes.

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

Re: [U-Boot] [PATCH 6/7] ARM: tegra: enable SD card on p2771-0000

[Stephen Warren]

On 07/31/2016 07:04 PM, Simon Glass wrote:

Hi Stephen,

On 29 July 2016 at 13:15, Stephen Warren  wrote:

From: Stephen Warren 

Now that clock and reset drivers exist for Tegra186, we can enable the SD
card controller. Now that a BPMP I2C driver exists for Tegra186, we can
communicate with the PMIC to enable power to the SD card. Hook up the DT
content and board code required to make the SD card work.



diff --git a/board/nvidia/p2771-/p2771-.c 
b/board/nvidia/p2771-/p2771-.c



+int tegra_board_init(void)
+{
+   struct udevice *dev;
+   uchar val;
+   int ret;
+
+   /* Turn on MAX77620 LDO3 to 3.3V for SD card power */
+   debug("%s: Set LDO3 for VDDIO_SDMMC_AP power to 3.3V\n", __func__);
+   ret = i2c_get_chip_for_busnum(0, MAX77620_I2C_ADDR_7BIT, 1, &dev);
+   if (ret) {
+   printf("%s: Cannot find MAX77620 I2C chip\n", __func__);
+   return ret;
+   }
+   /* 0xF2 for 3.3v, enabled: bit7:6 = 11 = enable, bit5:0 = voltage */
+   val = 0xF2;
+   ret = dm_i2c_write(dev, MAX77620_CNFG1_L3_REG, &val, 1);
+   if (ret) {
+   printf("i2c_write 0 0x3c 0x27 failed: %d\n", ret);
+   return ret;
+   }


Can you add a simple pmic driver for this? It's really easy and avoids
the horrible busnum stuff. The i2c_get_chip_for_busnum() should
ideally not be used.


Perhaps we can defer that until later?

FWIW, this current approach is used by all/most Tegra boards and works 
great for now. If converting this kind of code to use the PMIC 
infra-structure, I'd rather take a pass and do all Tegra boards at once, 
but equally I'd rather not hold up the Tegra186 patches behind yet 
another common API conversion; there are already 3 new common APIs 
introduced for Tegra in the Tegra186 support...

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

Re: [U-Boot] [PATCH] Makefile: Remove tags file on mrproper

[Tom Rini]

On Mon, Aug 01, 2016 at 02:41:08PM +0530, Vignesh R wrote:

> make tags creates a symbolic link called tags to ctags. Remove this file
> on make mrproper or make distclean.
> 
> Signed-off-by: Vignesh R 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] powerpc/mpc85xx: Update erratum workaround for A006379

[York Sun]

Update erratum workaround for A006379 to set register CPCHDBCR0
with value 0x001e, replacing the old value 0x003c.

Signed-off-by: York Sun 
Reported-by: Dave Liu 
---
 arch/powerpc/include/asm/immap_85xx.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/powerpc/include/asm/immap_85xx.h 
b/arch/powerpc/include/asm/immap_85xx.h
index c045a24..7a878be 100644
--- a/arch/powerpc/include/asm/immap_85xx.h
+++ b/arch/powerpc/include/asm/immap_85xx.h
@@ -1579,7 +1579,7 @@ typedef struct cpc_corenet {
 #define CPC_HDBCR0_CDQ_SPEC_DIS0x0800
 #define CPC_HDBCR0_TAG_ECC_SCRUB_DIS   0x0100
 #define CPC_HDBCR0_DATA_ECC_SCRUB_DIS  0x0040
-#define CPC_HDBCR0_SPLRU_LEVEL_EN  0x003c
+#define CPC_HDBCR0_SPLRU_LEVEL_EN  0x001e
 #endif /* CONFIG_SYS_FSL_CPC */
 
 /* Global Utilities Block */
-- 
2.7.4

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

Re: [U-Boot] [PATCH 2/3] arm/PSCI: Fixed the backward compatiblity issue

[york sun]

On 07/31/2016 08:20 PM, Zhiqiang Hou wrote:
> Hi York,
>
> Thanks for your comments!
>
>> -Original Message-
>> From: york sun
>> Sent: 2016年7月29日 23:37
>> To: Zhiqiang Hou ; u-boot@lists.denx.de;
>> albert.u.b...@aribaud.net; hdego...@redhat.com; w...@csie.org; Hongbo
>> Zhang ; b.galv...@gmail.com
>> Subject: Re: [PATCH 2/3] arm/PSCI: Fixed the backward compatiblity issue
>>
>> On 07/29/2016 03:37 AM, Zhiqiang Hou wrote:
>>> From: Hou Zhiqiang 
>>>
>>> Appended the compatible strings of old version PSCI to the latest
>>> version supported. And there are some psci functions' property must be
>>> added to DT only for psci version 0.1, such as 'cpu_on' 'cpu_off' etc.
>>>
>>> Note:
>>> The PSCI version 0.1 isn't supported by ARMv8 Secure Firmware Framework.
>>>
>>> Signed-off-by: Hou Zhiqiang 
>>> ---
>>
>> You missed version number and change log.
>
> Should the previous Secure Firmware Framework patchset need to be 
> resubmitted? And the version number follow the that patchset?

Zhiqiang,

When you send a new version, reviewers are expecting updated version 
number and a change log. This helps us tracking what has been changed. 
All patches in the same set should be updated. If a patch has not 
change, a simple "no change" helps. If any dependency has 
changed/updated, please update the note as well.

>
>>>  arch/arm/include/asm/psci.h |  3 +++
>>>  arch/arm/lib/psci-dt.c  | 61
>> ++---
>>>  2 files changed, 38 insertions(+), 26 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/psci.h b/arch/arm/include/asm/psci.h
>>> index 8aefaa7..5b8ce4d 100644
>>> --- a/arch/arm/include/asm/psci.h
>>> +++ b/arch/arm/include/asm/psci.h
>>> @@ -18,6 +18,9 @@
>>>  #ifndef __ARM_PSCI_H__
>>>  #define __ARM_PSCI_H__
>>>
>>> +#define ARM_PSCI_VER_1_0   (0x0001)
>>> +#define ARM_PSCI_VER_0_2   (0x0002)
>>> +
>>>  /* PSCI 0.1 interface */
>>>  #define ARM_PSCI_FN_BASE   0x95c1ba5e
>>>  #define ARM_PSCI_FN(n) (ARM_PSCI_FN_BASE + (n))
>>> diff --git a/arch/arm/lib/psci-dt.c b/arch/arm/lib/psci-dt.c index
>>> bcd92e7..af49c24 100644
>>> --- a/arch/arm/lib/psci-dt.c
>>> +++ b/arch/arm/lib/psci-dt.c
>>> @@ -19,7 +19,6 @@ int fdt_psci(void *fdt)  #if
>>> defined(CONFIG_ARMV8_PSCI) || defined(CONFIG_ARMV7_PSCI)
>>> int nodeoff;
>>> unsigned int psci_ver = 0;
>>> -   char *psci_compt;
>>> int tmp;
>>>
>>> nodeoff = fdt_path_offset(fdt, "/cpus"); @@ -68,39 +67,49 @@
>>> init_psci_node:
>>> psci_ver = sec_firmware_support_psci_version();
>>>  #endif
>>> switch (psci_ver) {
>>> -   case 0x0001:
>>> -   psci_compt = "arm,psci-1.0";
>>> -   break;
>>> -   case 0x0002:
>>> -   psci_compt = "arm,psci-0.2";
>>> -   break;
>>> +   case ARM_PSCI_VER_1_0:
>>> +   tmp = fdt_setprop_string(fdt, nodeoff,
>>> +   "compatible", "arm,psci-1.0");
>>> +   if (tmp)
>>> +   return tmp;
>>
>> Add a comment "fall through".
>>
>
> Yes, will add the comment.
> []
>>> +   case ARM_PSCI_VER_0_2:
>>> +   tmp = fdt_appendprop_string(fdt, nodeoff,
>>> +   "compatible", "arm,psci-0.2");
>>> +   if (tmp)
>>> +   return tmp;
>>
>> Add a comment "fall through".
>>
>>> default:
>>> -   psci_compt = "arm,psci";
>>> +   /*
>>> +* The Secure firmware framework isn't able to support PSCI version 0.1.
>>> +*/
>>> +#ifndef CONFIG_ARMV8_SEC_FIRMWARE_SUPPORT
>>> +   tmp = fdt_appendprop_string(fdt, nodeoff,
>>> +   "compatible", "arm,psci");
>>> +   if (tmp)
>>> +   return tmp;
>>> +   tmp = fdt_setprop_u32(fdt, nodeoff, "cpu_suspend",
>>> +   ARM_PSCI_FN_CPU_SUSPEND);
>>> +   if (tmp)
>>> +   return tmp;
>>> +   tmp = fdt_setprop_u32(fdt, nodeoff, "cpu_off",
>>> +   ARM_PSCI_FN_CPU_OFF);
>>> +   if (tmp)
>>> +   return tmp;
>>> +   tmp = fdt_setprop_u32(fdt, nodeoff, "cpu_on",
>>> +   ARM_PSCI_FN_CPU_ON);
>>> +   if (tmp)
>>> +   return tmp;
>>> +   tmp = fdt_setprop_u32(fdt, nodeoff, "migrate",
>>> +   ARM_PSCI_FN_MIGRATE);
>>> +   if (tmp)
>>> +   return tmp;
>>
>> This may not be a real concern, but I am curious what would happen if one of
>> the above fdt_setprop_u32 fails? Would it be better to set "arm,psci" last?
>
> Trend to add the error check to prevent the unexpected issue. Is there 
> benefit to set the "arm,psci" last?

I just guessed without "arm,psci" node, kernel wouldn't look for 
"cpu_on", "cpu_off" node. I could be wrong.

York

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

Re: [U-Boot] [PATCH v2 2/3] zynqmp: Move config IDENT_STRING to defconfig

[Jagan Teki]

On 1 August 2016 at 13:42, Michal Simek  wrote:
> On 1.8.2016 06:49, Siva Durga Prasad Paladugu wrote:
>> Move config IDENT_STRING to defconfig for all
>> zynqmp boards.
>>
>> Signed-off-by: Siva Durga Prasad Paladugu 
>> ---

Acked-by: Jagan Teki 

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

Re: [U-Boot] [PATCH 1/4] Introduce CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE

[Tom Rini]

On Mon, Aug 01, 2016 at 10:30:23AM -0500, Andrew F. Davis wrote:
> Introduce CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE. An SPL which define
> this will panic() if the image it has loaded is not a FIT image.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  Kconfig  | 8 
>  common/spl/spl.c | 4 
>  2 files changed, 12 insertions(+)
> 
> diff --git a/Kconfig b/Kconfig
> index ef12f9f..4c03716 100644
> --- a/Kconfig
> +++ b/Kconfig
> @@ -336,6 +336,14 @@ config SPL_FIT_IMAGE_POST_PROCESS
> injected into the FIT creation (i.e. the blobs would have been pre-
> processed before being added to the FIT image).
>  
> +config SPL_PANIC_ON_NON_FIT_IMAGE
> + bool "Disable SPL loading of non-FIT images"

I think we should make this default y if SPL_FIT_SIGNATURE since the
point of enabling these options is that you want to be verified or
failing.  During development you can disable this easily enough.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 3/3] zynqmp: Remove unnnecessary board config file for dc4

[Jagan Teki]

On 1 August 2016 at 10:19, Siva Durga Prasad Paladugu
 wrote:
> Remove unnecessary board specific config file for DC4
> board.
>
> Signed-off-by: Siva Durga Prasad Paladugu 

Acked-by: Jagan Teki 

fyi: I've Acked previously for the same patch, pls- add them in your
patch if any such in previous versions.

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

Re: [U-Boot] Question on Enabling hypervisor mode in u-boot

[Andreas Färber]

Hi Keerthy,

Am 01.08.2016 um 12:07 schrieb Keerthy:
> I am trying to enable hypervisor in u-boot for DRA7(A15 based) family of
> SoCs which does not have LPAE support yet.
> 
> Is it mandatory for LPAE to be enabled before enabling hypervisor for A15?

On the Linux kernel side you can't enable KVM without LPAE.
I assume the same will hold true in U-Boot then.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] Introduce CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE

[Simon Glass]

Hi,

On 1 August 2016 at 11:30, Tom Rini  wrote:
>
> On Mon, Aug 01, 2016 at 10:30:23AM -0500, Andrew F. Davis wrote:
> > Introduce CONFIG_SPL_PANIC_ON_NON_FIT_IMAGE. An SPL which define
> > this will panic() if the image it has loaded is not a FIT image.
> >
> > Signed-off-by: Andrew F. Davis 
> > ---
> >  Kconfig  | 8 
> >  common/spl/spl.c | 4 
> >  2 files changed, 12 insertions(+)
> >
> > diff --git a/Kconfig b/Kconfig
> > index ef12f9f..4c03716 100644
> > --- a/Kconfig
> > +++ b/Kconfig
> > @@ -336,6 +336,14 @@ config SPL_FIT_IMAGE_POST_PROCESS
> > injected into the FIT creation (i.e. the blobs would have been pre-
> > processed before being added to the FIT image).
> >
> > +config SPL_PANIC_ON_NON_FIT_IMAGE
> > + bool "Disable SPL loading of non-FIT images"
>
> I think we should make this default y if SPL_FIT_SIGNATURE since the
> point of enabling these options is that you want to be verified or
> failing.  During development you can disable this easily enough.

Also can we reuse CONFIG_IMAGE_FORMAT_LEGACY?

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2] misc: Tegra BPMP: support child node devices

[Stephen Warren]

From: Stephen Warren 

The BPMP bindings allow devices to be represented as child nodes of the
BPMP node. This requires the driver to trigger scanning of its node for
those child nodes.

Signed-off-by: Stephen Warren 
---
v2: Use dm_scan_fdt_dev() to scan sub-nodes. This function was just added.
---
 drivers/misc/tegra186_bpmp.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/misc/tegra186_bpmp.c b/drivers/misc/tegra186_bpmp.c
index 147528da9269..87216dce8dea 100644
--- a/drivers/misc/tegra186_bpmp.c
+++ b/drivers/misc/tegra186_bpmp.c
@@ -129,6 +129,10 @@ static int tegra186_bpmp_bind(struct udevice *dev)
if (ret)
return ret;
 
+   ret = dm_scan_fdt_dev(dev);
+   if (ret)
+   return ret;
+
return 0;
 }
 
-- 
2.9.2

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

Re: [U-Boot] [PATCH v2 05/11] buildman: Improve the toolchain progress/error output

[Simon Glass]

On 27 July 2016 at 20:33, Simon Glass  wrote:
> Use colour to make it easier to see what is going on. Also print a message
> before downloading a new toolchain. Mention --fetch-arch in the message that
> is shown when there are no available toolchains, since this is the quickest
> way to resolve the problem.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
>
> Changes in v2: None
>
>  tools/buildman/control.py   |  9 ++---
>  tools/buildman/toolchain.py | 24 +++-
>  2 files changed, 21 insertions(+), 12 deletions(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 07/11] buildman: Drop the toolchain error when downloading toolchains

[Simon Glass]

On 27 July 2016 at 20:33, Simon Glass  wrote:
> It doesn't make sense to complain about missing toolchains when the
> --fetch-arch option is being used. The user is presumably aware that there
> is a toolchain problem and is actively correcting it by running with this
> option.
>
> Refactor the code to avoid printing this confusing message.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  tools/buildman/control.py | 17 ++---
>  1 file changed, 10 insertions(+), 7 deletions(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/11] buildman: Fix a typo in TestSettingsHasPath()

[Simon Glass]

On 27 July 2016 at 21:28, Tom Rini  wrote:
> On Wed, Jul 27, 2016 at 08:33:03PM -0600, Simon Glass wrote:
>
>> The function comment should say 'buildman'. Fix it.
>>
>> Signed-off-by: Simon Glass 
>
> Reviewed-by: Tom Rini 
>
> --
> Tom

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 08/11] buildman: Avoid overwriting existing toolchain entries

[Simon Glass]

On 27 July 2016 at 21:28, Tom Rini  wrote:
> On Wed, Jul 27, 2016 at 08:33:05PM -0600, Simon Glass wrote:
>
>> The current code for setting up the toolchain config always writes the new
>> paths to an item called 'toolchain'. This means that it will overwrite any
>> existing toolchain item with the same name. In practice, this means that:
>>
>>buildman --fetch-arch all
>>
>> will fetch all toolchains, but only the path of the final one will be added
>> to the config. This normally works out OK, since most toolchains are the
>> same version (e.g. gcc 4.9) and will be found on the same path. But it is
>> not correct and toolchains for archs which don't use the same version will
>> not function as expected.
>>
>> Adjust the code to use a complete glob of the toolchain path.
>>
>> Signed-off-by: Simon Glass 
>
> Reviewed-by: Tom Rini 
>
> --
> Tom

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/11] buildman: Add a quick-start note

[Simon Glass]

On 27 July 2016 at 21:28, Tom Rini  wrote:
> On Wed, Jul 27, 2016 at 08:33:06PM -0600, Simon Glass wrote:
>
>> For those who just want to build a board, it is useful to see a quick hint
>> right at the start of the documentation. Add a few commands showing how to
>> download toolchains and build a board.
>>
>> Signed-off-by: Simon Glass 
>
> Reviewed-by: Tom Rini 
>
> --
> Tom

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 10/11] Drop the MAKEALL tool

[Simon Glass]

On 27 July 2016 at 20:33, Simon Glass  wrote:
> Buildman has been around for 3 years now. It has had a lot of use and
> testing. Perhaps it is time to remove MAKEALL.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
>
> Changes in v2: None
>
>  MAKEALL | 850 
> 
>  1 file changed, 850 deletions(-)
>  delete mode 100755 MAKEALL

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 11/11] Drop references to MAKEALL in the documentation

[Simon Glass]

On 27 July 2016 at 20:33, Simon Glass  wrote:
> It is confusing to mention MAKEALL when it is not the normal way of building
> U-Boot anymore. Update the documentation to suit.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
>
> Changes in v2: None
>
>  README | 35 ++-
>  board/Barix/ipam390/README.ipam390 | 12 ++--
>  doc/README.sha1|  5 +++--
>  3 files changed, 15 insertions(+), 37 deletions(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-dm

[Simon Glass]

Hi Tom,

Here's the buildman updates and an fdt patch. If you end up dropping
the last two patches (MAKEALL removal) that's fine. But I've included
them for now.


The following changes since commit 26fb8db0f4d1e7c118b5e8f3a8849f359b91c166:

  Merge git://git.denx.de/u-boot-rockchip (2016-07-31 20:31:13 -0400)

are available in the git repository at:

  git://git.denx.de/u-boot-dm.git

for you to fetch changes up to 6de80f2196cb7b7a2c550a636404c54cf532fc17:

  Drop references to MAKEALL in the documentation (2016-07-31 19:37:08 -0600)


Michal Simek (1):
  libfdt: Introduce new ARCH_FIXUP_FDT option

Simon Glass (11):
  buildman: Tidy up the README a little
  buildman: Automatically create a config file if needed
  buildman: Fix the 'help' test to use the correct path
  buildman: Allow the toolchain error to be suppressed
  buildman: Improve the toolchain progress/error output
  buildman: Fix a typo in TestSettingsHasPath()
  buildman: Drop the toolchain error when downloading toolchains
  buildman: Avoid overwriting existing toolchain entries
  buildman: Add a quick-start note
  Drop the MAKEALL tool
  Drop references to MAKEALL in the documentation

 Kconfig|   9 +
 MAKEALL| 850
--
 README |  35 +---
 arch/arm/lib/bootm-fdt.c   |   2 +
 arch/arm/lib/bootm.c   |   2 +
 arch/mips/lib/bootm.c  |   2 +
 board/Barix/ipam390/README.ipam390 |  12 +-
 common/image-fdt.c |   7 +-
 doc/README.sha1|   5 +-
 tools/buildman/README  |  67 --
 tools/buildman/bsettings.py|  44 
 tools/buildman/control.py  |  26 ++-
 tools/buildman/func_test.py|   2 +-
 tools/buildman/toolchain.py|  49 +++--
 14 files changed, 168 insertions(+), 944 deletions(-)
 delete mode 100755 MAKEALL

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/11] buildman: Automatically create a config file if needed

[Simon Glass]

On 27 July 2016 at 21:28, Tom Rini  wrote:
> On Wed, Jul 27, 2016 at 08:32:59PM -0600, Simon Glass wrote:
>
>> If there is no ~/.buildman file, buildman currently complains and exists. To
>> make things a little more friendly, create an empty one automatically. This
>> will not allow things to be built, but --fetch-arch can be used to handle
>> that.
>>
>> Signed-off-by: Simon Glass 
>
> Reviewed-by: Tom Rini 
>
> --
> Tom

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2] misc: Tegra BPMP: support child node devices

[Simon Glass]

On 1 August 2016 at 11:57, Stephen Warren  wrote:
> From: Stephen Warren 
>
> The BPMP bindings allow devices to be represented as child nodes of the
> BPMP node. This requires the driver to trigger scanning of its node for
> those child nodes.
>
> Signed-off-by: Stephen Warren 
> ---
> v2: Use dm_scan_fdt_dev() to scan sub-nodes. This function was just added.
> ---
>  drivers/misc/tegra186_bpmp.c | 4 
>  1 file changed, 4 insertions(+)

Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 04/11] buildman: Allow the toolchain error to be suppressed

[Simon Glass]

On 27 July 2016 at 20:33, Simon Glass  wrote:
> When there are no toolchains a warning is printed. But in some cases this is
> confusing, such as when the user is fetching new toolchains.
>
> Adjust the function to supress the warning in this case.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2:
> - Add code to actually suppress the warning
>
>  tools/buildman/toolchain.py | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 03/11] buildman: Fix the 'help' test to use the correct path

[Simon Glass]

On 27 July 2016 at 20:33, Simon Glass  wrote:
> When buildman is run via a symlink, this test fails. Fix it to work the same
> way as buildman itself.
>
> Signed-off-by: Simon Glass 
> ---
>
> Changes in v2: None
>
>  tools/buildman/func_test.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/11] buildman: Tidy up the README a little

[Simon Glass]

On 27 July 2016 at 20:32, Simon Glass  wrote:
> Tidy up some problems found by a recent review.
>
> Signed-off-by: Simon Glass 
> Reviewed-by: Tom Rini 
> ---
>
> Changes in v2: None
>
>  tools/buildman/README | 53 
> +--
>  1 file changed, 30 insertions(+), 23 deletions(-)

Applied to u-boot-dm
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 10/10] boston: Introduce support for the MIPS Boston development board

[Marek Vasut]

On 07/31/2016 07:32 PM, Paul Burton wrote:
> On 31/07/16 16:56, Marek Vasut wrote:
>> On 07/29/2016 10:36 AM, Paul Burton wrote:
>> [...]
> +#ifndef __ASSEMBLY__
> +
> +#include 
> +
> +#define BUILD_PLAT_ACCESSORS(offset, name)\
> +static inline uint32_t read_boston_##name(void)\
> +{\
> +uint32_t *reg = (void *)CKSEG1ADDR(BOSTON_PLAT_BASE) + (offset);\
> +return __raw_readl(reg);\
> +}

 Don't we have enough standard accessors to confuse people ?
 Why do you add another custom ones ? Remove this and just use
 standard accessors throughout the code.
>>>
>>> Hi Marek,
>>>
>>> These accessors are simple wrappers around __raw_readl, I'd hardly say
>>> they can be considered confusing. The alternative is lots of:
>>>
>>> val = __raw_readl((void *)CKSEG1ADDR(BOSTON_PLAT_BASE) + OFFSET);
>>>
>>> ...and that is just plain ugly.
>>
>> This should be map_physmem() + readl(), see ie. the ag7xxx.c driver or
>> whatever other stuff from the atheros ath79 port. Does this work ?
> 
> Yes this works. I suggest you read about the MIPS memory map if you wish
> to critique this code.

What am I missing ?

>>> Invoking readl on a field of a struct
>>> representing these registers would be nice, but some of them need to be
>>> accessed from assembly so that would involve duplication which isn't
>>> nice.
>>
>> The struct based access is deprecated, don't bother with it.
>>
>>> I think this way is the best option, where if you want to read the
>>> Boston core_cl register you call read_boston_core_cl() - it's hardly
>>> confusing what that does.
>>
>> Now imagine what would happen if everyone introduced his own
>> my_platform_read_random_register() accessor(s) . This would be utter
>> chaos.
> 
> You speak as though this patch introduces new general purpose accessor
> functions that perform some arbitrary memory read. It does not.

Yes it does, the accessor is globally available.

> It
> introduces functions each of which reads a single register in the only
> sane way to read that register, via the standard __raw_readl. It does so
> in a pretty well namespaced manner & with names that match the register
> names of the platform. If everyone were to do that I fail to see what
> the problem would be.

Say you want to find all register accesses -- with random functions with
ad-hoc names, you cannot do simple git grep, you need to grep for these
ad-hoc functions as well ... but they won't show up, since there
is also preprocessor string concatenation, which further obfuscates
things and makes it unpleasant to work with.

In my opinion, this macro has no value.

> +BUILD_PLAT_ACCESSORS(BOSTON_PLAT_CORE_CL, core_cl)
> +BUILD_PLAT_ACCESSORS(BOSTON_PLAT_MMCMDIV, mmcmdiv)
> +BUILD_PLAT_ACCESSORS(BOSTON_PLAT_DDRCONF0, ddrconf0)
> +
> +#endif /* !__ASSEMBLY__ */
> +
> +#endif /* __BOARD_BOSTON_REGS_H__ */
> diff --git a/board/imgtec/boston/checkboard.c
> b/board/imgtec/boston/checkboard.c
> new file mode 100644
> index 000..417ac4e
> --- /dev/null
> +++ b/board/imgtec/boston/checkboard.c
> @@ -0,0 +1,29 @@
> +/*
> + * Copyright (C) 2016 Imagination Technologies
> + *
> + * SPDX-License-Identifier:GPL-2.0
> + */
> +
> +#include 
> +
> +#include 
> +
> +#include "boston-lcd.h"
> +#include "boston-regs.h"
>
> +int checkboard(void)
> +{
> +u32 changelist;
> +
> +lowlevel_display("U-boot  ");
> +
> +printf("Board: MIPS Boston\n");
> +
> +printf("CPU:   0x%08x", read_c0_prid());

 This should be in print_cpuinfo()
>>>
>>> I don't agree. This goes on to read a board-specific register to
>>> determine information about the CPU (the revision of its RTL) and that
>>> should not be done in arch-level code, which is what every other
>>> implementation of print_cpuinfo is.
>>
>> Ah, so the register used to determine CPU info is board-specific ? That
>> is utterly braindead design in my mind. The read_c0_prid() looked like
>> it is reading some standard register, maybe that's not true ...
> 
> read_c0_prid() is generic, it's the read_boston_core_cl() that is
> board-specific & used to print the CPU's RTL revision, as I described
> with "goes on to...".

So this stuff should be in print_cpuinfo() if it's generic.

> I disagree that this is a bad design. It's pretty
> logical that an FPGA based development platform might wish to expose
> more information about the CPU loaded on it, such as its RTL revision,
> than that CPU would expose in general use.

I am fine with this, you can print an ascii-art pikachu there if you
want. But board info should go into show_board_info() and CPU info
should be in print_cpuinfo() .

> You can insult the design of the system all you like if it makes you
> feel better. However, if you expect me t

Re: [U-Boot] [PATCH v3] libfdt: Introduce new ARCH_FIXUP_FDT option

[Simon Glass]

On 1 August 2016 at 00:37, Michal Simek  wrote:
> On 1.8.2016 03:03, Simon Glass wrote:
>> On 28 July 2016 at 01:06, Michal Simek  wrote:
>>> Add new Kconfig option to disable arch_fixup_fdt() calls for cases where
>>> U-Boot shouldn't update memory setup in DTB file.
>>> One example of usage of this option is to boot OS with different memory
>>> setup than U-Boot use.
>>>
>>> Signed-off-by: Michal Simek 
>>> ---
>>>
>>> Changes in v3:
>>> - Fix MIPS macro
>>>
>>> Changes in v2:
>>> - Change logic to be possitive - sjg
>>>
>>>  Kconfig  | 9 +
>>>  arch/arm/lib/bootm-fdt.c | 2 ++
>>>  arch/arm/lib/bootm.c | 2 ++
>>>  arch/mips/lib/bootm.c| 2 ++
>>>  common/image-fdt.c   | 7 ++-
>>>  5 files changed, 17 insertions(+), 5 deletions(-)
>>
>> Acked-by: Simon Glass 
>>
>
> I have to send PR with xilinx changes to fix others critical issues
> that's why I would include this to my PR.
> I expect that this should be fine for you.
>

OK that's fine. I'm about to send a pull request with this, but there
should be no conflict.

Applied to u-boot-dm, thanks!

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

Re: [U-Boot] [PATCH] armv8: ls2080a/ls1043a/ls1012a: enable support for booti

[Stuart Yoder]

> -Original Message-
> From: Tom Rini [mailto:tr...@konsulko.com]
> Sent: Saturday, July 30, 2016 9:03 AM
> To: Stuart Yoder 
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] armv8: ls2080a/ls1043a/ls1012a: enable support 
> for booti
> 
> On Fri, Jul 29, 2016 at 03:59:18PM -0500, Stuart Yoder wrote:
> 
> > The booti command allows booting kernels specifying dtb,
> > kernel, and rootfs addresses individually (without needing
> > an ITB file), providing more flexibility.
> >
> > Signed-off-by: Stuart Yoder 
> 
> With v2 of https://patchwork.ozlabs.org/patch/652262/ we shouldn't need
> this at all as BOOTI will be enabled by default on ARM64 boards.

Sounds good.

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

Re: [U-Boot] [PATCH 4/9] misc: add Tegra BPMP driver

[Stephen Warren]

On 08/01/2016 09:41 AM, Stephen Warren wrote:

On 07/31/2016 07:02 PM, Simon Glass wrote:

On 27 July 2016 at 15:24, Stephen Warren  wrote:

From: Stephen Warren 

The Tegra BPMP (Boot and Power Management Processor) is a separate
auxiliary CPU embedded into Tegra to perform power management work, and
controls related features such as clocks, resets, power domains, PMIC
I2C
bus, etc. This driver provides the core low-level communication path by
which feature-specific drivers (such as clock) can make requests to the
BPMP. This driver is similar to an MFD driver in the Linux kernel. It is
unconditionally selected by CONFIG_TEGRA186 since virtually any Tegra186
build of U-Boot will need the feature.



diff --git a/arch/arm/include/asm/arch-tegra/bpmp_abi.h



+static ulong tegra186_bpmp_get_shmem(struct udevice *dev, int index)
+{
+   int ret;
+   struct fdtdec_phandle_args args;
+   struct udevice fakedev;
+   fdt_addr_t reg;
+
+   ret = fdtdec_parse_phandle_with_args(gd->fdt_blob,
dev->of_offset,
+ "shmem", NULL, 0,
index, &args);
+   if (ret < 0) {
+   error("fdtdec_parse_phandle_with_args() failed:
%d\n", ret);
+   return ret;
+   }
+
+   fakedev.of_offset = args.node;
+   reg = dev_get_addr_index(&fakedev, 0);


This is nasty. If you don't set fakedev.parent, how does this work?


Hmmm. Good question; I thought dev_get_addr_index() only used the
device's own of_offset, but it does look like it uses the parent device
too. I'll have to look into this.


How sad. It works because dev->parent happens to be 0, and address 0 is 
part of the mapped MMIO space so is mapped in the MMU, and then 
dev->parent->of_offset happens to be 0, so dev_get_addr_index() ends up 
querying #address-calls/#size-cells from the root node, and those happen 
to match the values for the node we're actually interested in:-(


I guess the simplest approach is to use 
fdtdec_get_addr_size_auto_parent() or similar as you say, but also  call 
fdt_translate_address() afterwards.

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

Re: [U-Boot] Disable command at runtime

[Wolfgang Denk]

Dear Petr,

In message <1f085e1d-378c-5f29-2f35-988b8d110...@elnico.cz> you wrote:
> 
> I wonder whether it is possible to dynamically enable/disable a command. 
> Since u-boot does not provide any secure authentication method, it is 
> dangerous to keep some commands available to a potential hacker. E.g. 

If some evil guy has access to the U-Boot command line interface you
are pawned anyway.

> the "fuse" command. On the other hand, I need these commands during the 
> manufacturing process. So my idea is to enable/disable the commands 
> dynamically based on some obscure logic. Is there a way to do it without 
> need to deeply hack the code?

You have to modify the code to implement such a thing; but it should
not require any "deep hacking".  But then, I doubt it's useful.  If
you let an attacker run _any_ commands on your system you are already
doomed.  If it's in U-Boot, you lost.

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
Of course there's no reason for it, it's just our policy.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Disable command at runtime

[Wolfgang Denk]

Dear Petr,

In message <9c257c71-97b6-a83e-3d9d-e3a8459fc...@elnico.cz> you wrote:
> 
> Anyway, at least a user feedback / feature request... I believe it would 
> be useful for many users to have a manufacturing mode, which they would 
> escape permanently by e.g. executing some command. In normal mode, some 
> commands would be disabled. Logic would be similar to 
> CONFIG_OVERWRITE_ETHADDR_ONCE.

How could that ever be "safe" - in the sense of protecting against an
attacker?  How could you perform such a "switch" between modes?  By
setting some bit somewhere.  And it has to be in some persistent
storage.  And the source code of your image is available to the
public.  What should prevent an attacker from undoing your bit
setting and switching back to "full" mode?

U-Boot is a boot loader, not a high security environment.  If you
grand somebody access to the U-Boot command line interface, he owns
the system.  If not directly, so by just pulling a few simple tricks.

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
If it went on at this rate, in several billion  years  he'd  be  rich
beyond his wildest dreams!- Terry Pratchett, _Soul Music_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Disable command at runtime

[Ladislav Michl]

On Fri, Jul 29, 2016 at 05:57:58PM +0200, Petr Kubiz??ák wrote:
> Ok, I get it, then I'll have to deal with two defconfigs and reflashing for
> now.
> 
> Anyway, at least a user feedback / feature request... I believe it would be
> useful for many users to have a manufacturing mode, which they would escape
> permanently by e.g. executing some command. In normal mode, some commands
> would be disabled. Logic would be similar to CONFIG_OVERWRITE_ETHADDR_ONCE.

You can still download U-Boot standalone application implementing whatever
you need to do in production, so in "normal mode" your manufacturing secrets
are not even part of your product.

Best regards,
ladis
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] fdt: allow fdtdec_get_addr_size_*() to translate addresses

[Stephen Warren]

From: Stephen Warren 

Some code may want to read reg values from DT, but from nodes that aren't
associated with DM devices, so using dev_get_addr_index() isn't
appropriate. In this case, fdtdec_get_addr_size_*() are the functions to
use. However, "translation" (via the chain of ranges properties in parent
nodes) may still be desirable. Add a function parameter to request that,
and implement it. Update all call sites to default to the original
behaviour.

Signed-off-by: Stephen Warren 
---
 drivers/core/device.c   |  2 +-
 drivers/gpio/mpc85xx_gpio.c |  2 +-
 drivers/i2c/fsl_i2c.c   |  2 +-
 drivers/mmc/msm_sdhci.c |  3 ++-
 drivers/net/cpsw.c  |  3 ++-
 drivers/spmi/spmi-msm.c |  5 +++--
 include/fdtdec.h| 14 +++---
 lib/fdtdec.c| 20 +---
 8 files changed, 34 insertions(+), 17 deletions(-)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index 5bb1d7793dd6..b737f1c78907 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -671,7 +671,7 @@ fdt_addr_t dev_get_addr_index(struct udevice *dev, int 
index)
addr = fdtdec_get_addr_size_auto_parent(gd->fdt_blob,
dev->parent->of_offset,
dev->of_offset, "reg",
-   index, NULL);
+   index, NULL, false);
if (CONFIG_IS_ENABLED(SIMPLE_BUS) && addr != FDT_ADDR_T_NONE) {
if (device_get_uclass_id(dev->parent) ==
UCLASS_SIMPLE_BUS)
diff --git a/drivers/gpio/mpc85xx_gpio.c b/drivers/gpio/mpc85xx_gpio.c
index 3754a8215c36..168c696c4dc0 100644
--- a/drivers/gpio/mpc85xx_gpio.c
+++ b/drivers/gpio/mpc85xx_gpio.c
@@ -170,7 +170,7 @@ static int mpc85xx_gpio_ofdata_to_platdata(struct udevice 
*dev) {
fdt_size_t size;
 
addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, dev->of_offset,
- "reg", 0, &size);
+ "reg", 0, &size, false);
 
plat->addr = addr;
plat->size = size;
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 407c4a7b10b8..c3f826d68c75 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -587,7 +587,7 @@ static int fsl_i2c_ofdata_to_platdata(struct udevice *bus)
fdt_size_t size;
 
addr = fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, bus->of_offset,
- "reg", 0, &size);
+ "reg", 0, &size, false);
 
dev->base = map_sysmem(CONFIG_SYS_IMMR + addr, size);
 
diff --git a/drivers/mmc/msm_sdhci.c b/drivers/mmc/msm_sdhci.c
index 70a8d96eeef3..4b95e1837f63 100644
--- a/drivers/mmc/msm_sdhci.c
+++ b/drivers/mmc/msm_sdhci.c
@@ -180,7 +180,8 @@ static int msm_ofdata_to_platdata(struct udevice *dev)
priv->base = (void *)fdtdec_get_addr_size_auto_parent(gd->fdt_blob,
  parent->of_offset,
  dev->of_offset,
- "reg", 1, NULL);
+ "reg", 1, NULL,
+ false);
if (priv->base == (void *)FDT_ADDR_T_NONE ||
host->ioaddr == (void *)FDT_ADDR_T_NONE)
return -EINVAL;
diff --git a/drivers/net/cpsw.c b/drivers/net/cpsw.c
index 2ce4ec69f1df..2a458955ed05 100644
--- a/drivers/net/cpsw.c
+++ b/drivers/net/cpsw.c
@@ -1145,7 +1145,8 @@ static const struct eth_ops cpsw_eth_ops = {
 
 static inline fdt_addr_t cpsw_get_addr_by_node(const void *fdt, int node)
 {
-   return fdtdec_get_addr_size_auto_noparent(fdt, node, "reg", 0, NULL);
+   return fdtdec_get_addr_size_auto_noparent(fdt, node, "reg", 0, NULL,
+ false);
 }
 
 static int cpsw_eth_ofdata_to_platdata(struct udevice *dev)
diff --git a/drivers/spmi/spmi-msm.c b/drivers/spmi/spmi-msm.c
index 0cef505e37d0..48bc15759645 100644
--- a/drivers/spmi/spmi-msm.c
+++ b/drivers/spmi/spmi-msm.c
@@ -153,11 +153,12 @@ static int msm_spmi_probe(struct udevice *dev)
priv->spmi_core = fdtdec_get_addr_size_auto_parent(gd->fdt_blob,
   parent->of_offset,
   dev->of_offset,
-  "reg", 1, NULL);
+  "reg", 1, NULL,
+  false);
priv->spmi_obs = fdtdec_get_addr_size_auto_parent(gd->fdt_blob,
 

[U-Boot] [PATCH 1/2] fdt_support: fdt_translate_address() blob const correctness

[Stephen Warren]

From: Stephen Warren 

The next patch will call fdt_translate_address() from somewhere with a
"const void *blob" rather than a "void *blob", so fdt_translate_address()
must accept a const pointer too. Constify the minimum number of function
parameters to achieve this.

Signed-off-by: Stephen Warren 
---
 common/fdt_support.c  | 19 ++-
 include/fdt_support.h |  5 +++--
 2 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index 5d8eb12f1073..da59f2c8cc07 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -997,8 +997,8 @@ static void of_dump_addr(const char *s, const fdt32_t 
*addr, int na) { }
 struct of_bus {
const char  *name;
const char  *addresses;
-   int (*match)(void *blob, int parentoffset);
-   void(*count_cells)(void *blob, int parentoffset,
+   int (*match)(const void *blob, int parentoffset);
+   void(*count_cells)(const void *blob, int parentoffset,
int *addrc, int *sizec);
u64 (*map)(fdt32_t *addr, const fdt32_t *range,
int na, int ns, int pna);
@@ -1006,7 +1006,7 @@ struct of_bus {
 };
 
 /* Default translator (generic bus) */
-void of_bus_default_count_cells(void *blob, int parentoffset,
+void of_bus_default_count_cells(const void *blob, int parentoffset,
int *addrc, int *sizec)
 {
const fdt32_t *prop;
@@ -1066,7 +1066,7 @@ static int of_bus_isa_match(void *blob, int parentoffset)
return !strcmp(name, "isa");
 }
 
-static void of_bus_isa_count_cells(void *blob, int parentoffset,
+static void of_bus_isa_count_cells(const void *blob, int parentoffset,
   int *addrc, int *sizec)
 {
if (addrc)
@@ -1126,7 +1126,7 @@ static struct of_bus of_busses[] = {
},
 };
 
-static struct of_bus *of_match_bus(void *blob, int parentoffset)
+static struct of_bus *of_match_bus(const void *blob, int parentoffset)
 {
struct of_bus *bus;
 
@@ -1148,7 +1148,7 @@ static struct of_bus *of_match_bus(void *blob, int 
parentoffset)
return NULL;
 }
 
-static int of_translate_one(void * blob, int parent, struct of_bus *bus,
+static int of_translate_one(const void *blob, int parent, struct of_bus *bus,
struct of_bus *pbus, fdt32_t *addr,
int na, int ns, int pna, const char *rprop)
 {
@@ -1211,8 +1211,8 @@ static int of_translate_one(void * blob, int parent, 
struct of_bus *bus,
  * that can be mapped to a cpu physical address). This is not really specified
  * that way, but this is traditionally the way IBM at least do things
  */
-static u64 __of_translate_address(void *blob, int node_offset, const fdt32_t 
*in_addr,
- const char *rprop)
+static u64 __of_translate_address(const void *blob, int node_offset,
+ const fdt32_t *in_addr, const char *rprop)
 {
int parent;
struct of_bus *bus, *pbus;
@@ -1284,7 +1284,8 @@ static u64 __of_translate_address(void *blob, int 
node_offset, const fdt32_t *in
return result;
 }
 
-u64 fdt_translate_address(void *blob, int node_offset, const fdt32_t *in_addr)
+u64 fdt_translate_address(const void *blob, int node_offset,
+ const fdt32_t *in_addr)
 {
return __of_translate_address(blob, node_offset, in_addr, "ranges");
 }
diff --git a/include/fdt_support.h b/include/fdt_support.h
index 731809874f48..e9f3497ab642 100644
--- a/include/fdt_support.h
+++ b/include/fdt_support.h
@@ -180,7 +180,8 @@ static inline void fdt_fixup_mtdparts(void *fdt, void 
*node_info,
 #endif
 
 void fdt_del_node_and_alias(void *blob, const char *alias);
-u64 fdt_translate_address(void *blob, int node_offset, const __be32 *in_addr);
+u64 fdt_translate_address(const void *blob, int node_offset,
+ const __be32 *in_addr);
 int fdt_node_offset_by_compat_reg(void *blob, const char *compat,
phys_addr_t compat_off);
 int fdt_alloc_phandle(void *blob);
@@ -239,7 +240,7 @@ static inline u64 of_read_number(const fdt32_t *cell, int 
size)
return r;
 }
 
-void of_bus_default_count_cells(void *blob, int parentoffset,
+void of_bus_default_count_cells(const void *blob, int parentoffset,
int *addrc, int *sizec);
 int ft_verify_fdt(void *fdt);
 int arch_fixup_memory_node(void *blob);
-- 
2.9.2

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

[U-Boot] [PATCH V2] misc: add Tegra BPMP driver

[Stephen Warren]

From: Stephen Warren 

The Tegra BPMP (Boot and Power Management Processor) is a separate
auxiliary CPU embedded into Tegra to perform power management work, and
controls related features such as clocks, resets, power domains, PMIC I2C
bus, etc. This driver provides the core low-level communication path by
which feature-specific drivers (such as clock) can make requests to the
BPMP. This driver is similar to an MFD driver in the Linux kernel. It is
unconditionally selected by CONFIG_TEGRA186 since virtually any Tegra186
build of U-Boot will need the feature.

Signed-off-by: Stephen Warren 
---
v2:
* Use an SPDX license header in bpmp_abi.h.
* Add a function-level comment for tegra186_bpmp_call().
* Use fdtdec_get_addr_size_auto_noparent() to retrieve shmem address.

This depends on the following patches:
fdt: allow fdtdec_get_addr_size_*() to translate addresses
fdt_support: fdt_translate_address() blob const correctness
---
 arch/arm/include/asm/arch-tegra/bpmp_abi.h  | 1591 +++
 arch/arm/include/asm/arch-tegra/tegra186_bpmp.h |   14 +
 arch/arm/mach-tegra/Kconfig |2 +
 drivers/misc/Kconfig|   12 +
 drivers/misc/Makefile   |1 +
 drivers/misc/tegra186_bpmp.c|  268 
 6 files changed, 1888 insertions(+)
 create mode 100644 arch/arm/include/asm/arch-tegra/bpmp_abi.h
 create mode 100644 arch/arm/include/asm/arch-tegra/tegra186_bpmp.h
 create mode 100644 drivers/misc/tegra186_bpmp.c

diff --git a/arch/arm/include/asm/arch-tegra/bpmp_abi.h 
b/arch/arm/include/asm/arch-tegra/bpmp_abi.h
new file mode 100644
index ..7b6ad899cf6f
--- /dev/null
+++ b/arch/arm/include/asm/arch-tegra/bpmp_abi.h
@@ -0,0 +1,1591 @@
+/*
+ * Copyright (c) 2014-2016, NVIDIA CORPORATION.
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+#ifndef _ABI_BPMP_ABI_H_
+#define _ABI_BPMP_ABI_H_
+
+#ifdef LK
+#include 
+#endif
+
+#ifndef __ABI_PACKED
+#define __ABI_PACKED __attribute__((packed))
+#endif
+
+#ifdef NO_GCC_EXTENSIONS
+#define EMPTY char empty;
+#define EMPTY_ARRAY 1
+#else
+#define EMPTY
+#define EMPTY_ARRAY 0
+#endif
+
+#ifndef __UNION_ANON
+#define __UNION_ANON
+#endif
+/**
+ * @file
+ */
+
+
+/**
+ * @defgroup MRQ MRQ Messages
+ * @brief Messages sent to/from BPMP via IPC
+ * @{
+ *   @defgroup MRQ_Format Message Format
+ *   @defgroup MRQ_Codes Message Request (MRQ) Codes
+ *   @defgroup MRQ_Payloads Message Payloads
+ *   @defgroup Error_Codes Error Codes
+ * @}
+ */
+
+/**
+ * @addtogroup MRQ_Format Message Format
+ * @{
+ * The CPU requests the BPMP to perform a particular service by
+ * sending it an IVC frame containing a single MRQ message. An MRQ
+ * message consists of a @ref mrq_request followed by a payload whose
+ * format depends on mrq_request::mrq.
+ *
+ * The BPMP processes the data and replies with an IVC frame (on the
+ * same IVC channel) containing and MRQ response. An MRQ response
+ * consists of a @ref mrq_response followed by a payload whose format
+ * depends on the associated mrq_request::mrq.
+ *
+ * A well-defined subset of the MRQ messages that the CPU sends to the
+ * BPMP can lead to BPMP eventually sending an MRQ message to the
+ * CPU. For example, when the CPU uses an #MRQ_THERMAL message to set
+ * a thermal trip point, the BPMP may eventually send a single
+ * #MRQ_THERMAL message of its own to the CPU indicating that the trip
+ * point has been crossed.
+ * @}
+ */
+
+/**
+ * @ingroup MRQ_Format
+ * @brief header for an MRQ message
+ *
+ * Provides the MRQ number for the MRQ message: #mrq. The remainder of
+ * the MRQ message is a payload (immediately following the
+ * mrq_request) whose format depends on mrq.
+ *
+ * @todo document the flags
+ */
+struct mrq_request {
+   /** @brief MRQ number of the request */
+   uint32_t mrq;
+   /** @brief flags for the request */
+   uint32_t flags;
+} __ABI_PACKED;
+
+/**
+ * @ingroup MRQ_Format
+ * @brief header for an MRQ response
+ *
+ *  Provides an error code for the associated MRQ message. The
+ *  remainder of the MRQ response is a payload (immediately following
+ *  the mrq_response) whose format depends on the associated
+ *  mrq_request::mrq
+ *
+ * @todo document the flags
+ */
+struct mrq_response {
+   /** @brief error code for the MRQ request itself */
+   int32_t err;
+   /** @brief flags for the response */
+   uint32_t flags;
+} __ABI_PACKED;
+
+/**
+ * @ingroup MRQ_Format
+ * Minimum needed size for an IPC message buffer
+ */
+#define MSG_MIN_SZ 128
+/**
+ * @ingroup MRQ_Format
+ *  Minimum size guaranteed for data in an IPC message buffer
+ */
+#define MSG_DATA_MIN_SZ120
+
+/**
+ * @ingroup MRQ_Codes
+ * @name Legal MRQ codes
+ * These are the legal values for mrq_request::mrq
+ * @{
+ */
+
+#define MRQ_PING   0
+#define MRQ_QUERY_TAG  1
+#define MRQ_MODULE_LOAD4
+#define MRQ_MODULE_UNLOAD  5
+#define MRQ_TRACE_MODIFY   

Re: [U-Boot] [PATCH v2 7/7] cmd/bdinfo: extract print_std_bdinfo

[Tom Rini]

On Mon, Aug 01, 2016 at 04:10:47AM +0300, Max Filippov wrote:
> Tom, Simon,
> 
> On Mon, Aug 1, 2016 at 4:03 AM, Simon Glass  wrote:
> > On 27 July 2016 at 18:57, Max Filippov  wrote:
> >> print_std_bdinfo outputs typical set of board information entries:
> >> boot params location, memory and flash addresses and sizes, network
> >> interfaces information and configured serial baud rate.
> >>
> >> Signed-off-by: Max Filippov 
> >> ---
> >>  cmd/bdinfo.c | 32 
> >>  1 file changed, 12 insertions(+), 20 deletions(-)
> >
> > Nice!
> >
> > Reviewed-by: Simon Glass 
> 
> Thank you for reviews. Do I need to post pull request or will anybody
> take this series?

I'll pick it up soon, thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Question on Enabling hypervisor mode in u-boot

[Alexander Graf]

> On 01 Aug 2016, at 11:07, Keerthy  wrote:
> 
> Hi Alexander,
> 
> I am trying to enable hypervisor in u-boot for DRA7(A15 based) family of SoCs 
> which does not have LPAE support yet.
> 
> Is it mandatory for LPAE to be enabled before enabling hypervisor for A15?

HYP mode shares the same page table layout as the LPAE one. I’m actually 
surprised you managed to configure an A15 without LPAE. Are you sure it doesn’t 
support it?


Alex

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

[U-Boot] [PATCH] ARM: Rework and correct barrier definitions

[Tom Rini]

As part of testing booting Linux kernels on Rockchip devices, it was
discovered by Ziyuan Xu and Sandy Patterson that we had multiple and for
some cases incomplete isb definitions.  This was causing a failure to
boot of the Linux kernel.

In order to solve this problem as well as cover any corner cases that we
may also have had a number of changes are made in order to consolidate
things.  First,  now becomes the source of isb/dsb/dmb
definitions.  This however introduces another complexity.  Due to
needing to build SPL for 32bit tegra with -march=armv4 we need to borrow
the __LINUX_ARM_ARCH__ logic from the Linux Kernel in a more complete
form.  Move this from arch/arm/lib/Makefile to arch/arm/Makefile and add
a comment about it.  Now that we can always know what the target CPU is
capable off we can get always do the correct thing for the barrier.  The
final part of this is that need to be consistent everywhere and call
isb()/dsb()/dmb() and NOT call ISB/DSB/DMB in some cases and the
function names in others.

Reported-by: Ziyuan Xu 
Reported-by: Sandy Patterson 
Signed-off-by: Tom Rini 
---
Good work on figuring this out guys.  Please test and ack this on your
hardware as well.  I've given this a boot test on one of my platforms
and built it for all ARM targets.
---
 arch/arm/Makefile  |  8 
 arch/arm/cpu/armv7/cache_v7.c  | 10 +-
 arch/arm/cpu/armv7/psci-common.c   |  2 +-
 arch/arm/cpu/armv7/sunxi/psci.c| 12 ++--
 arch/arm/include/asm/barriers.h| 11 +--
 arch/arm/include/asm/io.h  |  4 ++--
 arch/arm/include/asm/system.h  |  8 +---
 arch/arm/lib/Makefile  |  5 -
 arch/arm/mach-exynos/include/mach/system.h | 10 --
 arch/arm/mach-sunxi/dram_helpers.c |  2 +-
 arch/arm/mach-tegra/tegra20/Makefile   |  3 ++-
 11 files changed, 35 insertions(+), 40 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 6a07cd1..82f2fd0 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -20,6 +20,14 @@ arch-$(CONFIG_CPU_V7)=$(call cc-option, 
-march=armv7-a, \
 $(call cc-option, -march=armv7, -march=armv5))
 arch-$(CONFIG_ARM64)   =-march=armv8-a
 
+# On Tegra systems we must build SPL for the armv4 core on the device
+# but otherwise we can use the value in CONFIG_SYS_ARM_ARCH
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TEGRA),yy)
+arch-y += -D__LINUX_ARM_ARCH__=4
+else
+arch-y += -D__LINUX_ARM_ARCH__=$(CONFIG_SYS_ARM_ARCH)
+endif
+
 # Evaluate arch cc-option calls now
 arch-y := $(arch-y)
 
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 52f1856..c4bbcc3 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -75,7 +75,7 @@ static void v7_dcache_maint_range(u32 start, u32 stop, u32 
range_op)
}
 
/* DSB to make sure the operation is complete */
-   DSB;
+   dsb();
 }
 
 /* Invalidate TLB */
@@ -88,9 +88,9 @@ static void v7_inval_tlb(void)
/* Invalidate entire instruction TLB */
asm volatile ("mcr p15, 0, %0, c8, c5, 0" : : "r" (0));
/* Full system DSB - make sure that the invalidation is complete */
-   DSB;
+   dsb();
/* Full system ISB - make sure the instruction stream sees it */
-   ISB;
+   isb();
 }
 
 void invalidate_dcache_all(void)
@@ -194,10 +194,10 @@ void invalidate_icache_all(void)
asm volatile ("mcr p15, 0, %0, c7, c5, 6" : : "r" (0));
 
/* Full system DSB - make sure that the invalidation is complete */
-   DSB;
+   dsb();
 
/* ISB - make sure the instruction stream sees it */
-   ISB;
+   isb();
 }
 #else
 void invalidate_icache_all(void)
diff --git a/arch/arm/cpu/armv7/psci-common.c b/arch/arm/cpu/armv7/psci-common.c
index d14b693..8cb4107 100644
--- a/arch/arm/cpu/armv7/psci-common.c
+++ b/arch/arm/cpu/armv7/psci-common.c
@@ -29,7 +29,7 @@ static u32 psci_target_pc[CONFIG_ARMV7_PSCI_NR_CPUS] 
__secure_data = { 0 };
 void __secure psci_save_target_pc(int cpu, u32 pc)
 {
psci_target_pc[cpu] = pc;
-   DSB;
+   dsb();
 }
 
 u32 __secure psci_get_target_pc(int cpu)
diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 7ac8406..766b8c7 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -53,16 +53,16 @@ static void __secure __mdelay(u32 ms)
u32 reg = ONE_MS * ms;
 
cp15_write_cntp_tval(reg);
-   ISB;
+   isb();
cp15_write_cntp_ctl(3);
 
do {
-   ISB;
+   isb();
reg = cp15_read_cntp_ctl();
} while (!(reg & BIT(2)));
 
cp15_write_cntp_ctl(0);
-   ISB;
+   isb();
 }
 
 static void __secure clamp_release(u32 __maybe_unused *clamp)
@@ -164,7 +164,7 @@ static u32 __secure cp15_read_scr(void)
 static void __secure cp15_write_scr

Re: [U-Boot] [PATCH] ARM: Rework and correct barrier definitions

[Ziyuan Xu]

Hi Tom,


On 2016年08月02日 06:54, Tom Rini wrote:

As part of testing booting Linux kernels on Rockchip devices, it was
discovered by Ziyuan Xu and Sandy Patterson that we had multiple and for
some cases incomplete isb definitions.  This was causing a failure to
boot of the Linux kernel.

In order to solve this problem as well as cover any corner cases that we
may also have had a number of changes are made in order to consolidate
things.  First,  now becomes the source of isb/dsb/dmb
definitions.  This however introduces another complexity.  Due to
needing to build SPL for 32bit tegra with -march=armv4 we need to borrow
the __LINUX_ARM_ARCH__ logic from the Linux Kernel in a more complete
form.  Move this from arch/arm/lib/Makefile to arch/arm/Makefile and add
a comment about it.  Now that we can always know what the target CPU is
capable off we can get always do the correct thing for the barrier.  The
final part of this is that need to be consistent everywhere and call
isb()/dsb()/dmb() and NOT call ISB/DSB/DMB in some cases and the
function names in others.

Reported-by: Ziyuan Xu 
Reported-by: Sandy Patterson 
Signed-off-by: Tom Rini 
Great, this rework is similar to linux kernel, and it's better than what 
I did.  Moreover, it works for my rk3288 boards.

Tested-by: Ziyuan Xu 

But please can you keep things in alpha order? See below.

---
Good work on figuring this out guys.  Please test and ack this on your
hardware as well.  I've given this a boot test on one of my platforms
and built it for all ARM targets.
---
  arch/arm/Makefile  |  8 
  arch/arm/cpu/armv7/cache_v7.c  | 10 +-
  arch/arm/cpu/armv7/psci-common.c   |  2 +-
  arch/arm/cpu/armv7/sunxi/psci.c| 12 ++--
  arch/arm/include/asm/barriers.h| 11 +--
  arch/arm/include/asm/io.h  |  4 ++--
  arch/arm/include/asm/system.h  |  8 +---
  arch/arm/lib/Makefile  |  5 -
  arch/arm/mach-exynos/include/mach/system.h | 10 --
  arch/arm/mach-sunxi/dram_helpers.c |  2 +-
  arch/arm/mach-tegra/tegra20/Makefile   |  3 ++-
  11 files changed, 35 insertions(+), 40 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 6a07cd1..82f2fd0 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -20,6 +20,14 @@ arch-$(CONFIG_CPU_V7)=$(call cc-option, 
-march=armv7-a, \
 $(call cc-option, -march=armv7, -march=armv5))
  arch-$(CONFIG_ARM64)  =-march=armv8-a
  
+# On Tegra systems we must build SPL for the armv4 core on the device

+# but otherwise we can use the value in CONFIG_SYS_ARM_ARCH
+ifeq ($(CONFIG_SPL_BUILD)$(CONFIG_TEGRA),yy)
+arch-y += -D__LINUX_ARM_ARCH__=4
+else
+arch-y += -D__LINUX_ARM_ARCH__=$(CONFIG_SYS_ARM_ARCH)
+endif
+
  # Evaluate arch cc-option calls now
  arch-y := $(arch-y)
  
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c

index 52f1856..c4bbcc3 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -75,7 +75,7 @@ static void v7_dcache_maint_range(u32 start, u32 stop, u32 
range_op)
}
  
  	/* DSB to make sure the operation is complete */

-   DSB;
+   dsb();
  }
  
  /* Invalidate TLB */

@@ -88,9 +88,9 @@ static void v7_inval_tlb(void)
/* Invalidate entire instruction TLB */
asm volatile ("mcr p15, 0, %0, c8, c5, 0" : : "r" (0));
/* Full system DSB - make sure that the invalidation is complete */
-   DSB;
+   dsb();
/* Full system ISB - make sure the instruction stream sees it */
-   ISB;
+   isb();
  }
  
  void invalidate_dcache_all(void)

@@ -194,10 +194,10 @@ void invalidate_icache_all(void)
asm volatile ("mcr p15, 0, %0, c7, c5, 6" : : "r" (0));
  
  	/* Full system DSB - make sure that the invalidation is complete */

-   DSB;
+   dsb();
  
  	/* ISB - make sure the instruction stream sees it */

-   ISB;
+   isb();
  }
  #else
  void invalidate_icache_all(void)
diff --git a/arch/arm/cpu/armv7/psci-common.c b/arch/arm/cpu/armv7/psci-common.c
index d14b693..8cb4107 100644
--- a/arch/arm/cpu/armv7/psci-common.c
+++ b/arch/arm/cpu/armv7/psci-common.c
@@ -29,7 +29,7 @@ static u32 psci_target_pc[CONFIG_ARMV7_PSCI_NR_CPUS] 
__secure_data = { 0 };
  void __secure psci_save_target_pc(int cpu, u32 pc)
  {
psci_target_pc[cpu] = pc;
-   DSB;
+   dsb();
  }
  
  u32 __secure psci_get_target_pc(int cpu)

diff --git a/arch/arm/cpu/armv7/sunxi/psci.c b/arch/arm/cpu/armv7/sunxi/psci.c
index 7ac8406..766b8c7 100644
--- a/arch/arm/cpu/armv7/sunxi/psci.c
+++ b/arch/arm/cpu/armv7/sunxi/psci.c
@@ -53,16 +53,16 @@ static void __secure __mdelay(u32 ms)
u32 reg = ONE_MS * ms;
  
  	cp15_write_cntp_tval(reg);

-   ISB;
+   isb();
cp15_write_cntp_ctl(3);
  
  	do {

-   ISB;
+   isb();
reg = cp15_re

Re: [U-Boot] [PATCH] ARM: Rework and correct barrier definitions

[Tom Rini]

On Tue, Aug 02, 2016 at 08:37:19AM +0800, Ziyuan Xu wrote:
> Hi Tom,
> 
> 
> On 2016年08月02日 06:54, Tom Rini wrote:
> >As part of testing booting Linux kernels on Rockchip devices, it was
> >discovered by Ziyuan Xu and Sandy Patterson that we had multiple and for
> >some cases incomplete isb definitions.  This was causing a failure to
> >boot of the Linux kernel.
> >
> >In order to solve this problem as well as cover any corner cases that we
> >may also have had a number of changes are made in order to consolidate
> >things.  First,  now becomes the source of isb/dsb/dmb
> >definitions.  This however introduces another complexity.  Due to
> >needing to build SPL for 32bit tegra with -march=armv4 we need to borrow
> >the __LINUX_ARM_ARCH__ logic from the Linux Kernel in a more complete
> >form.  Move this from arch/arm/lib/Makefile to arch/arm/Makefile and add
> >a comment about it.  Now that we can always know what the target CPU is
> >capable off we can get always do the correct thing for the barrier.  The
> >final part of this is that need to be consistent everywhere and call
> >isb()/dsb()/dmb() and NOT call ISB/DSB/DMB in some cases and the
> >function names in others.
> >
> >Reported-by: Ziyuan Xu 
> >Reported-by: Sandy Patterson 
> >Signed-off-by: Tom Rini 
> Great, this rework is similar to linux kernel, and it's better than
> what I did.  Moreover, it works for my rk3288 boards.
> Tested-by: Ziyuan Xu 
> 
> But please can you keep things in alpha order? See below.

Sure, I'll re-work when applying or reposting if there's any other
comments.  Thanks!

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Question on Enabling hypervisor mode in u-boot

[Keerthy]

On Tuesday 02 August 2016 03:16 AM, Alexander Graf wrote:



On 01 Aug 2016, at 11:07, Keerthy  wrote:

Hi Alexander,

I am trying to enable hypervisor in u-boot for DRA7(A15 based) family of SoCs 
which does not have LPAE support yet.

Is it mandatory for LPAE to be enabled before enabling hypervisor for A15?


HYP mode shares the same page table layout as the LPAE one. I’m actually 
surprised you managed to configure an A15 without LPAE. Are you sure it doesn’t 
support it?


I meant CONFIG_LPAE not enabled yet in our defconfig. I was trying to 
get hyp mode enabled and saw that enabling LPAE config seemed mandatory 
as per your commit.





Alex


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

Re: [U-Boot] Question on Enabling hypervisor mode in u-boot

[Keerthy]

On Monday 01 August 2016 11:11 PM, Andreas Färber wrote:

Hi Keerthy,

Am 01.08.2016 um 12:07 schrieb Keerthy:

I am trying to enable hypervisor in u-boot for DRA7(A15 based) family of
SoCs which does not have LPAE support yet.

Is it mandatory for LPAE to be enabled before enabling hypervisor for A15?


On the Linux kernel side you can't enable KVM without LPAE.
I assume the same will hold true in U-Boot then.


Hi Andreas,

Okay. Thanks for the confirmations. I will try with LPAE config defined 
in u-boot also.


Best Regards,
Keerthy



Regards,
Andreas


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

[U-Boot] [PATCH] configs: rk3399: add gpt and fs support

[Kever Yang]

To compatible with distro boot, we need to add gpt and fs support,
including gpt table and vfat, ext2, ext4 support.

Signed-off-by: Kever Yang 
---

 include/configs/rk3399_common.h | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index a9c9d29..12327d5 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -35,6 +35,15 @@
 #define CONFIG_BOUNCE_BUFFER
 #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ 2
 
+#define CONFIG_DOS_PARTITION
+#define CONFIG_PARTITION_UUIDS
+#define CONFIG_SUPPORT_VFAT
+#define CONFIG_FS_FAT
+#define CONFIG_FAT_WRITE
+#define CONFIG_CMD_PART
+
+/*  EXT4 FS */
+#define CONFIG_FS_EXT4
 #define CONFIG_FAT_WRITE
 
 /* RAW SD card / eMMC locations. */
@@ -60,6 +69,14 @@
"kernel_addr_r=0x0200\0" \
"ramdisk_addr_r=0x0400\0"
 
+#define CONFIG_CMD_GPT
+#define CONFIG_RANDOM_UUID
+#define CONFIG_EFI_PARTITION
+#define PARTS_DEFAULT \
+   "uuid_disk=${uuid_gpt_disk};" \
+   "name=boot,start=16M,size=32M,bootable;" \
+   "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};" \
+
 /* First try to boot from SD (index 0), then eMMC (index 1) */
 #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
@@ -67,6 +84,8 @@
 
 #include 
 #define CONFIG_EXTRA_ENV_SETTINGS \
+   ENV_MEM_LAYOUT_SETTINGS \
+   "partitions=" PARTS_DEFAULT \
BOOTENV
 
 #endif
-- 
1.9.1


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

[U-Boot] [PATCH 1/3] clock: rk3399: add support for dwmmc 400K

[Kever Yang]

MMC core will use 400KHz for card initialize first and then switch to
higher frequency like 50MHz, we need to support both 400KHz and about
50MHz for dwmmc controller.

Signed-off-by: Kever Yang 
---

 drivers/clk/clk_rk3399.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/clk/clk_rk3399.c b/drivers/clk/clk_rk3399.c
index 5d9bce0..802b8a1 100644
--- a/drivers/clk/clk_rk3399.c
+++ b/drivers/clk/clk_rk3399.c
@@ -142,6 +142,7 @@ enum {
CLK_EMMC_PLL_SHIFT  = 8,
CLK_EMMC_PLL_MASK   = 0x7 << CLK_EMMC_PLL_SHIFT,
CLK_EMMC_PLL_SEL_GPLL   = 0x1,
+   CLK_EMMC_PLL_SEL_24M= 0x5,
CLK_EMMC_DIV_CON_SHIFT  = 0,
CLK_EMMC_DIV_CON_MASK   = 0x7f << CLK_EMMC_DIV_CON_SHIFT,
 
@@ -640,9 +641,13 @@ static ulong rk3399_mmc_get_clk(struct rk3399_cru *cru, 
uint clk_id)
default:
return -EINVAL;
}
-   div = (con>>CLK_EMMC_DIV_CON_SHIFT) & CLK_EMMC_DIV_CON_MASK;
+   div = (con & CLK_EMMC_DIV_CON_MASK) >> CLK_EMMC_DIV_CON_SHIFT;
 
-   return DIV_TO_RATE(GPLL_HZ, div);
+   if ((con & CLK_EMMC_PLL_MASK) >> CLK_EMMC_PLL_SHIFT
+   == CLK_EMMC_PLL_SEL_24M)
+   return DIV_TO_RATE(24*1024*1024, div);
+   else
+   return DIV_TO_RATE(GPLL_HZ, div);
 }
 
 static ulong rk3399_mmc_set_clk(struct rk3399_cru *cru,
@@ -653,14 +658,22 @@ static ulong rk3399_mmc_set_clk(struct rk3399_cru *cru,
 
switch (clk_id) {
case SCLK_SDMMC:
-   /* Select clk_sdmmc source from GPLL too */
+   /* Select clk_sdmmc source from GPLL by default */
src_clk_div = GPLL_HZ / set_rate;
-   assert(src_clk_div - 1 < 127);
 
-   rk_clrsetreg(&cru->clksel_con[16],
-CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
-CLK_EMMC_PLL_SEL_GPLL << CLK_EMMC_PLL_SHIFT |
-(src_clk_div - 1) << CLK_EMMC_DIV_CON_SHIFT);
+   if (src_clk_div > 127) {
+   /* use 24MHz source for 400KHz clock */
+   src_clk_div = 24*1024*1024 / set_rate;
+   rk_clrsetreg(&cru->clksel_con[16],
+CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
+CLK_EMMC_PLL_SEL_24M << CLK_EMMC_PLL_SHIFT 
|
+(src_clk_div - 1) << 
CLK_EMMC_DIV_CON_SHIFT);
+   } else {
+   rk_clrsetreg(&cru->clksel_con[16],
+CLK_EMMC_PLL_MASK | CLK_EMMC_DIV_CON_MASK,
+CLK_EMMC_PLL_SEL_GPLL << 
CLK_EMMC_PLL_SHIFT |
+(src_clk_div - 1) << 
CLK_EMMC_DIV_CON_SHIFT);
+   }
break;
case SCLK_EMMC:
/* Select aclk_emmc source from GPLL */
-- 
1.9.1


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

Re: [U-Boot] [PATCH] configs: rk3399: add gpt and fs support

[Kever Yang]

On 08/02/2016 10:29 AM, Kever Yang wrote:

To compatible with distro boot, we need to add gpt and fs support,
including gpt table and vfat, ext2, ext4 support.

Signed-off-by: Kever Yang 
---

  include/configs/rk3399_common.h | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index a9c9d29..12327d5 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -35,6 +35,15 @@
  #define CONFIG_BOUNCE_BUFFER
  #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ2
  
+#define CONFIG_DOS_PARTITION

+#define CONFIG_PARTITION_UUIDS
+#define CONFIG_SUPPORT_VFAT
+#define CONFIG_FS_FAT
+#define CONFIG_FAT_WRITE


Sorry, this MACRO CONFIG_FAT_WRITE is duplicated, will fix in next version,
I will waiting for other comments before send out V2 tomorrow.

Thanks,
- Kever

+#define CONFIG_CMD_PART
+
+/*  EXT4 FS */
+#define CONFIG_FS_EXT4
  #define CONFIG_FAT_WRITE
  
  /* RAW SD card / eMMC locations. */

@@ -60,6 +69,14 @@
"kernel_addr_r=0x0200\0" \
"ramdisk_addr_r=0x0400\0"
  
+#define CONFIG_CMD_GPT

+#define CONFIG_RANDOM_UUID
+#define CONFIG_EFI_PARTITION
+#define PARTS_DEFAULT \
+   "uuid_disk=${uuid_gpt_disk};" \
+   "name=boot,start=16M,size=32M,bootable;" \
+   "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};" \
+
  /* First try to boot from SD (index 0), then eMMC (index 1) */
  #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
@@ -67,6 +84,8 @@
  
  #include 

  #define CONFIG_EXTRA_ENV_SETTINGS \
+   ENV_MEM_LAYOUT_SETTINGS \
+   "partitions=" PARTS_DEFAULT \
BOOTENV
  
  #endif



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

[U-Boot] [PATCH 0/3] rk3399: enable dwmmc controller for sdcard

[Kever Yang]

rk3399 using dwmmc controller for sdcard, let's enable it.
this patch set has been test on rk3399 evb.



Kever Yang (3):
  clock: rk3399: add support for dwmmc 400K
  dts: rk3399: enable dwmmc for sdcard
  config: rk3399: enable dwmmc controller

 arch/arm/dts/rk3399-evb.dts |  4 
 arch/arm/dts/rk3399.dtsi|  2 +-
 configs/evb-rk3399_defconfig|  1 +
 drivers/clk/clk_rk3399.c| 29 +
 include/configs/rk3399_common.h |  1 +
 5 files changed, 28 insertions(+), 9 deletions(-)

-- 
1.9.1


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

Re: [U-Boot] [PATCH] configs: rk3399: add gpt and fs support

[Ziyuan Xu]

Hi kever,


On 2016年08月02日 10:29, Kever Yang wrote:

To compatible with distro boot, we need to add gpt and fs support,
including gpt table and vfat, ext2, ext4 support.

Signed-off-by: Kever Yang 
---

  include/configs/rk3399_common.h | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index a9c9d29..12327d5 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -35,6 +35,15 @@
  #define CONFIG_BOUNCE_BUFFER
  #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ2
  
+#define CONFIG_DOS_PARTITION
CONFIG_DOS_PARTITION and CONFIG_EFI_PARTITION are already included in 
config_distro_defaults.h, you not need to define it.

See 77337c1 rockchip: remove the duplicated macro config

+#define CONFIG_PARTITION_UUIDS
+#define CONFIG_SUPPORT_VFAT
+#define CONFIG_FS_FAT
+#define CONFIG_FAT_WRITE
+#define CONFIG_CMD_PART
+
+/*  EXT4 FS */
+#define CONFIG_FS_EXT4
  #define CONFIG_FAT_WRITE
  
  /* RAW SD card / eMMC locations. */

@@ -60,6 +69,14 @@
"kernel_addr_r=0x0200\0" \
"ramdisk_addr_r=0x0400\0"
  
+#define CONFIG_CMD_GPT

+#define CONFIG_RANDOM_UUID
+#define CONFIG_EFI_PARTITION
+#define PARTS_DEFAULT \
+   "uuid_disk=${uuid_gpt_disk};" \
+   "name=boot,start=16M,size=32M,bootable;" \
+   "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};" \

miss '\0'.
should be  "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};\0" \

+
  /* First try to boot from SD (index 0), then eMMC (index 1) */
  #define BOOT_TARGET_DEVICES(func) \
func(MMC, mmc, 0) \
@@ -67,6 +84,8 @@
  
  #include 

  #define CONFIG_EXTRA_ENV_SETTINGS \
+   ENV_MEM_LAYOUT_SETTINGS \
+   "partitions=" PARTS_DEFAULT \
BOOTENV
  
  #endif



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

[U-Boot] [PATCH 3/3] config: rk3399: enable dwmmc controller

[Kever Yang]

Signed-off-by: Kever Yang 
---

 configs/evb-rk3399_defconfig| 1 +
 include/configs/rk3399_common.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/evb-rk3399_defconfig b/configs/evb-rk3399_defconfig
index 3f9b47e..18f6ae6 100644
--- a/configs/evb-rk3399_defconfig
+++ b/configs/evb-rk3399_defconfig
@@ -22,6 +22,7 @@ CONFIG_FIT=y
 CONFIG_SYSRESET=y
 CONFIG_DM_MMC=y
 CONFIG_ROCKCHIP_SDHCI=y
+CONFIG_ROCKCHIP_DWMMC=y
 CONFIG_PINCTRL=y
 CONFIG_RAM=y
 CONFIG_SYS_NS16550=y
diff --git a/include/configs/rk3399_common.h b/include/configs/rk3399_common.h
index ca05e5c..12327d5 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -30,6 +30,7 @@
 /* MMC/SD IP block */
 #define CONFIG_MMC
 #define CONFIG_GENERIC_MMC
+#define CONFIG_DWMMC
 #define CONFIG_SDHCI
 #define CONFIG_BOUNCE_BUFFER
 #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ 2
-- 
1.9.1


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

Re: [U-Boot] [PATCH] configs: rk3399: add gpt and fs support

[Ziyuan Xu]

On 2016年08月02日 10:56, Ziyuan Xu wrote:

Hi kever,


On 2016年08月02日 10:29, Kever Yang wrote:

To compatible with distro boot, we need to add gpt and fs support,
including gpt table and vfat, ext2, ext4 support.

Signed-off-by: Kever Yang 
---

  include/configs/rk3399_common.h | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/include/configs/rk3399_common.h 
b/include/configs/rk3399_common.h

index a9c9d29..12327d5 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -35,6 +35,15 @@
  #define CONFIG_BOUNCE_BUFFER
  #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ2
  +#define CONFIG_DOS_PARTITION
CONFIG_DOS_PARTITION and CONFIG_EFI_PARTITION are already included in 
config_distro_defaults.h, you not need to define it.

See 77337c1 rockchip: remove the duplicated macro config

+#define CONFIG_PARTITION_UUIDS
+#define CONFIG_SUPPORT_VFAT
+#define CONFIG_FS_FAT
+#define CONFIG_FAT_WRITE
+#define CONFIG_CMD_PART
+
+/*  EXT4 FS */
+#define CONFIG_FS_EXT4
  #define CONFIG_FAT_WRITE
/* RAW SD card / eMMC locations. */
@@ -60,6 +69,14 @@
  "kernel_addr_r=0x0200\0" \
  "ramdisk_addr_r=0x0400\0"
  +#define CONFIG_CMD_GPT
+#define CONFIG_RANDOM_UUID
+#define CONFIG_EFI_PARTITION
+#define PARTS_DEFAULT \
+"uuid_disk=${uuid_gpt_disk};" \
+"name=boot,start=16M,size=32M,bootable;" \
+"name=rootfs,size=-,uuid=${uuid_gpt_rootfs};" \

I think partitions table should be defined in includes/configs/${board}.h

miss '\0'.
should be  "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};\0" \

+
  /* First try to boot from SD (index 0), then eMMC (index 1) */
  #define BOOT_TARGET_DEVICES(func) \
  func(MMC, mmc, 0) \
@@ -67,6 +84,8 @@
#include 
  #define CONFIG_EXTRA_ENV_SETTINGS \
+ENV_MEM_LAYOUT_SETTINGS \
+"partitions=" PARTS_DEFAULT \
  BOOTENV
#endif





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

Re: [U-Boot] [PATCH] configs: rk3399: add gpt and fs support

[Ziyuan Xu]

On 2016年08月02日 10:56, Ziyuan Xu wrote:

Hi kever,


On 2016年08月02日 10:29, Kever Yang wrote:

To compatible with distro boot, we need to add gpt and fs support,
including gpt table and vfat, ext2, ext4 support.

Signed-off-by: Kever Yang 
---

  include/configs/rk3399_common.h | 19 +++
  1 file changed, 19 insertions(+)

diff --git a/include/configs/rk3399_common.h 
b/include/configs/rk3399_common.h

index a9c9d29..12327d5 100644
--- a/include/configs/rk3399_common.h
+++ b/include/configs/rk3399_common.h
@@ -35,6 +35,15 @@
  #define CONFIG_BOUNCE_BUFFER
  #define CONFIG_ROCKCHIP_SDHCI_MAX_FREQ2
  +#define CONFIG_DOS_PARTITION
CONFIG_DOS_PARTITION and CONFIG_EFI_PARTITION are already included in 
config_distro_defaults.h, you not need to define it.

See 77337c1 rockchip: remove the duplicated macro config

+#define CONFIG_PARTITION_UUIDS
+#define CONFIG_SUPPORT_VFAT
+#define CONFIG_FS_FAT
+#define CONFIG_FAT_WRITE
+#define CONFIG_CMD_PART
+
+/*  EXT4 FS */
+#define CONFIG_FS_EXT4
  #define CONFIG_FAT_WRITE
/* RAW SD card / eMMC locations. */
@@ -60,6 +69,14 @@
  "kernel_addr_r=0x0200\0" \
  "ramdisk_addr_r=0x0400\0"
  +#define CONFIG_CMD_GPT
+#define CONFIG_RANDOM_UUID
+#define CONFIG_EFI_PARTITION
+#define PARTS_DEFAULT \
+"uuid_disk=${uuid_gpt_disk};" \
+"name=boot,start=16M,size=32M,bootable;" \
+"name=rootfs,size=-,uuid=${uuid_gpt_rootfs};" \

I think partitions table should be defined in includes/configs/${board}.h.

miss '\0'.
should be  "name=rootfs,size=-,uuid=${uuid_gpt_rootfs};\0" \

+
  /* First try to boot from SD (index 0), then eMMC (index 1) */
  #define BOOT_TARGET_DEVICES(func) \
  func(MMC, mmc, 0) \
@@ -67,6 +84,8 @@
#include 
  #define CONFIG_EXTRA_ENV_SETTINGS \
+ENV_MEM_LAYOUT_SETTINGS \
+"partitions=" PARTS_DEFAULT \
  BOOTENV
#endif





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