Re: [U-Boot] [PATCH v2 3/6] toradex: config block handling

[Stefan Agner]

On 28.09.2016 02:35, Marcel Ziswiler wrote:
> Add Toradex factory configuration block handling. The config block is a
> data structure which gets stored to flash during production testing. The
> structure holds such information as board resp. hardware revision,
> product ID and serial number which is used as the NIC part of the
> Ethernet MAC address as well. The config block will be read upon boot by
> the checkboard() function, displayed as part of the board information
> and passed to Linux via device tree or ATAGs.
>
> Signed-off-by: Marcel Ziswiler 
> ---
>
> Changes in v2: None
>
>  board/toradex/common/Kconfig |  80 ++
>  board/toradex/common/Makefile|  11 +
>  board/toradex/common/tdx-cfg-block.c | 544 
> +++
>  board/toradex/common/tdx-cfg-block.h |  68 +
>  board/toradex/common/tdx-common.c| 180 
>  board/toradex/common/tdx-common.h|  13 +
>  6 files changed, 896 insertions(+)
>  create mode 100644 board/toradex/common/Kconfig
>  create mode 100644 board/toradex/common/Makefile
>  create mode 100644 board/toradex/common/tdx-cfg-block.c
>  create mode 100644 board/toradex/common/tdx-cfg-block.h
>  create mode 100644 board/toradex/common/tdx-common.c
>  create mode 100644 board/toradex/common/tdx-common.h
>
> diff --git a/board/toradex/common/Kconfig b/board/toradex/common/Kconfig
> new file mode 100644
> index 000..e269875
> --- /dev/null
> +++ b/board/toradex/common/Kconfig
> @@ -0,0 +1,80 @@
> +# Copyright (c) 2016 Toradex, Inc.
> +# SPDX-License-Identifier:   GPL-2.0+
> +
> +# Not from device tree model node
> +config CUSTOM_BOARDINFO
> + bool

This Kconfig option seems to be hardly at the right place: We make use
of that config in common/board_info.c

But I have a completely different proposal, why don't we remove a config
option for once:
First, drop CONFIG_CUSTOM_BOARDINFO, it does not have widespread use
yet, so it shouldn't be a problem... Also it ifdefs almost the whole
function so not that much value. Then convert show_board_info to a weak
function instead... The implementer of show_board_info can then decide
whether checkboard should be called or not.

That way we can leave the checkboard() functions in all our boards as
is, and simply reimplement show_board_info in tdx-cfg-block.c (with a
call to checkboard only if the config block is corrupt/missing)...

Thoughts?

--
Stefan


> +
> +menuconfig TDX_CFG_BLOCK
> + bool "Enable Toradex config block support"
> + select OF_BOARD_SETUP
> + help
> +   The Toradex config block stored production data on the on-module
> +   flash device (NAND, NOR or eMMC). The area is normally preserved by
> +   software and contains the serial number (out of which the MAC
> +   address is generated) and the exact module type.
> +
> +# Helper config to determine the correct default location of the cfg block
> +config TDX_HAVE_MMC
> + bool
> +
> +config TDX_HAVE_NAND
> + bool
> +
> +config TDX_HAVE_NOR
> + bool
> +
> +if TDX_CFG_BLOCK
> +
> +choice TDX_CFG_BLOCK_LOCATION
> + prompt "Toradex config block location"
> + depends on TDX_CFG_BLOCK
> + default TDX_CFG_BLOCK_IS_IN_MMC if TDX_HAVE_MMC
> + default TDX_CFG_BLOCK_IS_IN_NAND if TDX_HAVE_NAND
> + default TDX_CFG_BLOCK_IS_IN_NOR if TDX_HAVE_NOR
> + help
> +   Configure the location of the Toradex config block. By default, the
> +   factory version of the Toradex config block is on the NAND, NOR or
> +   eMMC flash device on the module.
> +
> +config TDX_CFG_BLOCK_IS_IN_MMC
> + bool "Location of the config block is in eMMC"
> +
> +config TDX_CFG_BLOCK_IS_IN_NAND
> + bool "Location of the config block is in NAND"
> +
> +config TDX_CFG_BLOCK_IS_IN_NOR
> + bool "Location of the config block is in NOR"
> +
> +endchoice
> +
> +config TDX_CFG_BLOCK_DEV
> + int "Toradex config block eMMC device ID"
> + depends on TDX_CFG_BLOCK_IS_IN_MMC
> +
> +config TDX_CFG_BLOCK_PART
> + int "Toradex config block eMMC partition ID"
> + depends on TDX_CFG_BLOCK_IS_IN_MMC
> +
> +config TDX_CFG_BLOCK_OFFSET
> + int "Toradex config block offset"
> + help
> +   Specify the byte offset of the Toradex config block within the flash
> +   device the config block is stored on.
> +
> +config TDX_CFG_BLOCK_OFFSET2
> + int "Toradex config block offset, second instance"
> + default 0
> + help
> +   Specify the byte offset of the 2nd instance of the Toradex config 
> block
> +   within the flash device the config block is stored on.
> +   Set to 0 on modules which have no 2nd instance.
> +
> +config TDX_CFG_BLOCK_2ND_ETHADDR
> + bool "Set the second Ethernet address"
> + help
> +   For each serial number two Ethernet addresses are available for dual
> +   Ethernet carrier boards. This options enables the code to set the
> +   second Ethernet address as environment 

Re: [U-Boot] [PATCH v3 27/29] Convert CONFIG_SYS_CONSOLE_INFO_QUIET to Kconfig

[Tom Rini]

On Thu, Sep 29, 2016 at 02:23:26PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_SYS_CONSOLE_INFO_QUIET
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 16/29] Convert CONFIG_VGA_AS_SINGLE_DEVICE to Kconfig

[Tom Rini]

On Thu, Sep 29, 2016 at 02:23:15PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_VGA_AS_SINGLE_DEVICE
> 
> Once we migrate to driver model for video, we should be able to drop this
> option.
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 08/29] Convert CONFIG_CFB_CONSOLE to Kconfig

[Tom Rini]

On Thu, Sep 29, 2016 at 02:23:07PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_CFB_CONSOLE
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 02/29] Convert SILENT_CONSOLE options to Kconfig

[Tom Rini]

On Thu, Sep 29, 2016 at 02:23:01PM -0600, Simon Glass wrote:

> Move these option to Kconfig and tidy up existing uses.
> 
> The Power PC boards don't have a suitable common element: the common header
> files don't appear to line up with the Kconfig files as far as I can tell.
> This results in a lot of defconfig changes.
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 29/29] Convert CONFIG_SYS_STDIO_DEREGISTER to Kconfig

[Tom Rini]

On Thu, Sep 29, 2016 at 02:23:28PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_SYS_STDIO_DEREGISTER
> 
> This option should never be enabled in SPL, so use
> CONFIG_IS_ENABLED(SYS_STDIO_DEREGISTER) when checking the option.
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 28/29] Convert CONFIG_USB_KEYBOARD to Kconfig

[Tom Rini]

On Thu, Sep 29, 2016 at 02:23:27PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_USB_KEYBOARD
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 04/29] Convert CONFIG_SYS_CONSOLE_IS_IN_ENV et al to Kconfig

[Tom Rini]

On Thu, Sep 29, 2016 at 02:23:03PM -0600, Simon Glass wrote:

> This converts the following to Kconfig:
>CONFIG_SYS_CONSOLE_IS_IN_ENV
>CONFIG_CONSOLE_MUX
> 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 03/29] Convert CONSOLE_PRE_CONSOLE_BUFFER options to Kconfig

[Tom Rini]

On Fri, Sep 30, 2016 at 09:00:44AM +0300, Siarhei Siamashka wrote:
> Hello Simon,
> 
> On Thu, 29 Sep 2016 14:23:02 -0600
> Simon Glass  wrote:
> 
> > Move these option to Kconfig and tidy up existing uses.
> > 
> > Signed-off-by: Simon Glass 
> > ---
> > 
> > Changes in v3: None
> > Changes in v2:
> > - Change CONFIG_PRE_CON_BUF_SZ default to 4096
> > - Change CONFIG_PRE_CON_BUF_SZ to 'int' type
> > - Drop the depend clause on the CONFIG_PRE_CON_BUF_SZ default
> > - Move CONFIG_PRE_CON_BUF_ADDR default to common/Kconfig
> 
> What is the point moving these defines to Kconfig? They are neither
> user configurable, nor board specific. The location of the buffer is
> defined per platform or per SoC type and is a part of the global memory
> map. Similar to such things as the malloc heap and the stack.

This is a good point to bring up.  As we're discussing in another thread
about moving FSL things out of CONFIG_SYS_... and into Kconfig or a
different namespace, we have other examples today where there's
addresses in Kconfig.  Looking harder still at this code, perhaps as a
follow-up CONFIG_PRE_CON_BUF_SZ should just be 'PRE_CON_BUF_SIZE' in the
code and 4096, and not in Kconfig at all.  And for this series, make the
default tbs2910 uses the default for ARCH_MX6.

> Allowing the users to redefine the buffer location is a dangerous thing
> because everything may go out of control very easily (it may overlap
> with some other memory buffer). IMHO it only makes sense to have a
> single user configurable boolean flag in Kconfig (the one which
> enables/disables the pre-console functionality).
> 
> Regarding the buffer size. It was originally picked rather arbitrarily
> as 1MB at least for the sunxi platform:
> 
> https://patchwork.ozlabs.org/patch/426526/
> 
> Just because making it several orders of magnitude larger than
> necessary makes it extremely unlikely that anyone ever gets into
> a buffer wraparound situation. Picking smallish sizes does not gain
> us anything, but just adds an extra hassle because now one needs to
> make some estimations whether the size is large enough or not.
> Especially considering that this functionality may be sometimes
> used for debugging prints when troubleshooting something. And one
> can't easily predict how much debugging output would be actually
> necessary.

So maybe we should hide the size option under EXPERT?

-- 
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] [RFC] Rearrange CONFIG_* macros

[Tom Rini]

On Fri, Sep 30, 2016 at 04:20:10AM +, york sun wrote:
> On 09/29/2016 08:59 PM, Masahiro Yamada wrote:
> > 2016-09-30 0:47 GMT+09:00 york sun :
> >> On 09/28/2016 12:17 PM, Simon Glass wrote:
> >>> +Masahiro, who may know
> >>
> >> Masahiro,
> >>
> >> Need some advise on this. How do we deal with duplicated config?
> >>
> >> York
> >>
> >>>
> >>> On 28 September 2016 at 12:57, york sun  wrote:
>  On 09/27/2016 10:55 AM, Simon Glass wrote:
> > Hi York,
> >
> > On 27 September 2016 at 11:39, york sun  wrote:
> >> Guys,
> >>
> >> I want to discuss to rearrange the current CONFIG_* macros used by
> >> Freescale Layerscape SoCs. We have been encouraged to use CONFIG_SYS_*
> >> macros to define hardware setting, and other CONFIG_* macros for user
> >> setting. Clearly this has changed. Kconfig options are used for most
> >> user settings from now on. I am OK with it. But for existing
> >> CONFIG_SYS_* macros, we need a plan to either move them out of CONFIG_*
> >> name space, or move some to Kconfig, if that makes sense. Since most 
> >> our
> >> CONFIG_SYS_* macros are cross platforms (including armv7 and armv8), if
> >> using Kconfig option, do we add another mach-fsl folder to host the
> >> Kconfig, or somewhere else? We also have macros cross ARM and PowerPC.
> >> So we either move them out of arch/, or duplicate them for both arch.
> >>
> >> If we move them to another name space, for example SYS_FSL_*, do we 
> >> want
> >> to move them out of config.h?
> >>
> >> Any suggestion/comment?
> >
> > I wonder if some of these (the ones that represent actual values
> > rather than enabling functions) can move to device tree, or tables?
> >
> 
>  While I try to move some options to Kconfig, I have an issue of
>  duplicated names. For example, the MAX_CPUS is used in arch/x86/Kconfig.
>  I know I can put another config with the same name, for example
>  arch/arm/cpu/armv8/fsl-layerscape/Kconfig. The funny thing is when I
>  search for this config option under menuconfig, it shows the location of
>  x86, but showing defined in arch/arm/cpu/armv8/fsl-layerscape/Kconfig.
>  Same thing happens when I try to move an option which is used by both
>  PowerPC and ARM. This is not related to a common driver so I cannot put
>  the option into a driver Kconfig (for example CONFIG_SYS_HAS_SERDES).
> 
>  Is there a solution for this?
> 
> >
> > Right.
> > The "Help" in menuconfig is just to display the path
> > to the first Kconfig entry found.
> > The result looks funny if we have multiple entries for the same option name.
> >
> >
> > I am not pretty sure about this particular case,
> > but there should be general solutions.
> >
> >
> > (1)  Rename the option to avoid name space conflict, e.g.
> >
> > MAX_CPUS   ->  FSL_MAX_CPUS  (for Freescale SoCs)
> > MAX_CPUS   ->  X86_MAX_CPUS  (for x86)
> >
> 
> It is a solution, but I don't like it for the reason described below[1].
> 
> >
> > (2) Unify the Kconfig entry
> >
> >   As in Linux, we do not generally create multiple entries for the same 
> > option.
> >
> >   If the option is sensible only for some platforms, the general practice is
> > to use   "depends on HAVE_..." to hide the option on unrelated 
> > platforms.
> >
> >
> >   If X86 and FSL are the only platforms that have interest in this option,
> >   we can save HAVE_... and put them directly in "depends on".
> >
> > config MAX_CPUS
> >  int "Maximum number of CPUs permitted"
> >  depends on (SMP && X86) || VENDOR_FSL
> >
> >   I am not quite sure about "VENDOR_FSL",
> >so please choose your favorite one like
> >   SOC_FSL, PLAT_FSL, ARCH_FSL, or whatever.
> 
> This sounds like a bandage. I can go with this if there is no better 
> solution.

If MAX_CPUS has the same meaning in both cases, this isn't imho a
bandage but one of the cleanups that was hoped for in moving to Kconfig.
We see that a problem is encountered in more than one area more easily
and instead of letting N solutions accumulate we get one.

> Checking Linux Kconfig, I noticed the NR_CPUS are used in all archs. The 
> difference is only one arch Kconfig is sourced by
> 
> source "arch/$SRCARCH/Kconfig"
> 
> I tried to do the same for U-Boot, but that will require we put ARCH at 
> the command line of environmental variable. I think we moved away from 
> this syntax. It also has some trouble to to use aarch64 because we put 
> the actual code under arch/arm.

Yeah, we don't want to move in this direction.

[snip]
> [1] We have macros shared between PowerPC and ARM for Freescale QorIQ 
> SoCs because they share similar designs at SoC level. Some options can 
> be moved to driver Kconfig to avoid duplication. But there are many 
> options are tied to hardware and they are not related to a common 

Re: [U-Boot] [PATCH v6 6/6] configs: am57xx_evm_defconfig: Enable CMD_REG option

[Tom Rini]

On Fri, Sep 30, 2016 at 09:20:47AM +0530, Keerthy wrote:

> Enable CMD_REG option.
> 
> Signed-off-by: Keerthy 

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

Re: [U-Boot] [PATCH v5 6/6] configs: am57xx_evm_defconfig: Enable CMD_REG option

[Tom Rini]

On Wed, Sep 28, 2016 at 09:57:31AM +0530, Keerthy wrote:

> Enable CMD_REG option.
> 
> Signed-off-by: Keerthy 

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

Re: [U-Boot] U-Boot DFU test and Ctrl+C

[Tom Rini]

On Wed, Sep 28, 2016 at 11:49:52AM -0600, Stephen Warren wrote:
> On 09/28/2016 03:32 AM, Lukasz Majewski wrote:
> >Hi Tom,
> >
> >>Hey guys,
> >>
> >>As I use the DFU tests more and more, I keep hitting what I'm pretty
> >>sure is a false failure in the tests.  Sometimes the tests fail at:
> >>>  u_boot_console.wait_for('Ctrl+C to exit ...')
> >>
> >>and the last bit of the console log is:
> >>Starting download:
> >>[#]
> >>finished! unable to read DFU status #File System is consistent
> >>file found, deleting
> >>update journal finished
> >>File System is consistent
> >>update journal finished
> >>65 bytes written in 12380 ms (0 Bytes/s)
> >>=>
> >>
> >>So perhaps we should make the test look for the prompt itself rather
> >>than 'Ctrl+C' ?  Thanks!
> >
> >As fair as I remember, dfu-util provides and u-boot's dfu supports -e
> >switch behavior. This switch causes the dfu u-boot command to go
> >directly to u-boot prompt.
> >
> >Tom, I suppose that this is what you would need.
> >Just add -e to your host's dfu-util command.
> 
> Using -e is the opposite of what Tom wants. The test/py script
> expects the dfu command to continue running after an
> upload/download, since that's the default behaviour.

Right.  It sounds like DWC3 might have an intermittent issue I need to
find some time to try and debug, or talk someone else into debugging :)

-- 
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] [RFC PATCH 1/6] arm: Fix Kconfig for proper display menu

[York Sun]

Some config options should not have prompt. They are selected by choosing
target.

Signed-off-by: York Sun 
---
 arch/arm/cpu/armv7/ls102xa/Kconfig|  5 +++--
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 11 +++
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig 
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index 920eb4a..f0e7ae9 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -1,6 +1,7 @@
 config ARCH_LS1021A
-   bool "Freescale Layerscape LS1021A SoC"
+   bool
select SYS_FSL_ERRATUM_A010315
 
 config LS1_DEEP_SLEEP
-   bool "Freescale Layerscape 1 deep sleep"
+   bool "Deep sleep"
+   depends on ARCH_LS1021A
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index f8057ba..045261f 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -1,17 +1,20 @@
 config ARCH_LS1012A
-   bool "Freescale Layerscape LS1012A SoC"
+   bool
select SYS_FSL_MMDC
select SYS_FSL_ERRATUM_A010315
 
 config ARCH_LS1043A
-   bool "Freescale Layerscape LS1043A SoC"
+   bool
select SYS_FSL_ERRATUM_A010315
 
 config ARCH_LS1046A
-   bool "Freescale Layerscape LS1046A SoC"
+   bool
+
+config ARCH_LS2080A
+   bool
 
 config SYS_FSL_MMDC
-   bool "Freescale Multi Mode DDR Controller"
+   bool
 
 config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
-- 
2.7.4

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

[U-Boot] [RFC PATCH 3/6] arm: Move MAX_CPUS to Kconfig

[York Sun]

Move MAX_CPUS option to Kconfig and clean up existing uses for ARM. This
option is used by Freescale Layerscape SoCs.

Signed-off-by: York Sun 
---
 arch/arm/cpu/armv7/ls102xa/Kconfig| 11 +++
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 13 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h |  4 
 arch/arm/include/asm/arch-ls102xa/config.h|  1 -
 4 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig 
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index 2648416..e8264f5 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -9,6 +9,17 @@ config LS1_DEEP_SLEEP
bool "Deep sleep"
depends on ARCH_LS1021A
 
+config MAX_CPUS
+   int "Maximum number of CPUs permitted for LS102xA"
+   depends on ARCH_LS1021A
+   default 2
+   help
+ Set this number to the maximum number of possible CPUs in the SoC.
+ SoCs may have multiple clusters with each cluster may have multiple
+ ports. If some ports are reserved but higher ports are used for
+ cores, count the reserved ports. This will allocate enough memory
+ in spin table to properly handle all cores.
+
 config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
 
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 5619e0d..6d87fd8 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -32,4 +32,17 @@ config SYS_FSL_MMDC
 config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
 
+config MAX_CPUS
+   int "Maximum number of CPUs permitted for Layerscape"
+   default 4 if ARCH_LS1043A
+   default 4 if ARCH_LS1046A
+   default 16 if ARCH_LS2080A
+   default 1
+   help
+ Set this number to the maximum number of possible CPUs in the SoC.
+ SoCs may have multiple clusters with each cluster may have multiple
+ ports. If some ports are reserved but higher ports are used for
+ cores, count the reserved ports. This will allocate enough memory
+ in spin table to properly handle all cores.
+
 endmenu
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index a5c6c4c..572fa94 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -30,7 +30,6 @@
 #define CONFIG_SYS_MEM_RESERVE_SECURE  (2048 * 1024)   /* 2MB */
 
 #ifdef CONFIG_LS2080A
-#define CONFIG_MAX_CPUS16
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT  8
 #define CONFIG_NUM_DDR_CONTROLLERS 3
 #define CONFIG_SYS_FSL_HAS_DP_DDR  /* Runtime check to confirm */
@@ -171,7 +170,6 @@
 
 /* SoC related */
 #ifdef CONFIG_LS1043A
-#define CONFIG_MAX_CPUS4
 #define CONFIG_SYS_FMAN_V3
 #define CONFIG_SYS_NUM_FMAN1
 #define CONFIG_SYS_NUM_FM1_DTSEC   7
@@ -206,13 +204,11 @@
 #define CONFIG_SYS_FSL_ERRATUM_A009660
 #define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  1
 #elif defined(CONFIG_ARCH_LS1012A)
-#define CONFIG_MAX_CPUS 1
 #undef CONFIG_SYS_FSL_DDRC_ARM_GEN3
 
 #define GICD_BASE  0x01401000
 #define GICC_BASE  0x01402000
 #elif defined(CONFIG_ARCH_LS1046A)
-#define CONFIG_MAX_CPUS4
 #define CONFIG_SYS_FMAN_V3
 #define CONFIG_SYS_NUM_FMAN1
 #define CONFIG_SYS_NUM_FM1_DTSEC   8
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
b/arch/arm/include/asm/arch-ls102xa/config.h
index fab8774..70cc703 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -123,7 +123,6 @@
 #define CONFIG_SYS_FSL_SRDS_1
 
 #ifdef CONFIG_LS102XA
-#define CONFIG_MAX_CPUS2
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT  8
 #define CONFIG_NUM_DDR_CONTROLLERS 1
 #define CONFIG_SYS_FSL_DDR_VER FSL_DDR_VER_5_0
-- 
2.7.4

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

[U-Boot] [RFC PATCH 4/6] arm: Move SYS_FSL_IFC_BANK_COUNT to Kconfig

[York Sun]

Move this option to Kconfig and clean up existing uses.
This option is also used by PowerPC SoCs.

Signed-off-by: York Sun 
---
 arch/arm/cpu/armv7/ls102xa/Kconfig| 5 +
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 7 +++
 arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 ---
 3 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig 
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index e8264f5..88983f4 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -23,4 +23,9 @@ config MAX_CPUS
 config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
 
+config SYS_FSL_IFC_BANK_COUNT
+   int "Maximum banks of Integrated flash controller"
+   depends on ARCH_LS1021A
+   default 8
+
 endmenu
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 6d87fd8..aa412ec 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -45,4 +45,11 @@ config MAX_CPUS
  cores, count the reserved ports. This will allocate enough memory
  in spin table to properly handle all cores.
 
+config SYS_FSL_IFC_BANK_COUNT
+   int "Maximum banks of Integrated flash controller"
+   depends on ARCH_LS1043A || ARCH_LS1046A || ARCH_LS2080A
+   default 4 if ARCH_LS1043A
+   default 4 if ARCH_LS1046A
+   default 8 if ARCH_LS2080A
+
 endmenu
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 572fa94..2f10ab7 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -30,7 +30,6 @@
 #define CONFIG_SYS_MEM_RESERVE_SECURE  (2048 * 1024)   /* 2MB */
 
 #ifdef CONFIG_LS2080A
-#define CONFIG_SYS_FSL_IFC_BANK_COUNT  8
 #define CONFIG_NUM_DDR_CONTROLLERS 3
 #define CONFIG_SYS_FSL_HAS_DP_DDR  /* Runtime check to confirm */
 #define CONFIG_SYS_FSL_CLUSTER_CLOCKS  { 1, 1, 4, 4 }
@@ -174,7 +173,6 @@
 #define CONFIG_SYS_NUM_FMAN1
 #define CONFIG_SYS_NUM_FM1_DTSEC   7
 #define CONFIG_SYS_NUM_FM1_10GEC   1
-#define CONFIG_SYS_FSL_IFC_BANK_COUNT  4
 #define CONFIG_SYS_FSL_DDR_BE
 #define CONFIG_SYS_DDR_BLOCK1_SIZE ((phys_size_t)2 << 30)
 #define CONFIG_MAX_MEM_MAPPED  CONFIG_SYS_DDR_BLOCK1_SIZE
@@ -213,7 +211,6 @@
 #define CONFIG_SYS_NUM_FMAN1
 #define CONFIG_SYS_NUM_FM1_DTSEC   8
 #define CONFIG_SYS_NUM_FM1_10GEC   2
-#define CONFIG_SYS_FSL_IFC_BANK_COUNT  4
 #define CONFIG_SYS_FSL_DDR_BE
 #define CONFIG_SYS_DDR_BLOCK1_SIZE  ((phys_size_t)2 << 30)
 #define CONFIG_MAX_MEM_MAPPED   CONFIG_SYS_DDR_BLOCK1_SIZE
-- 
2.7.4

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

[U-Boot] [RFC PATCH 6/6] arm: Move SYS_FSL_SRDS_* and SYS_HAS_SERDES to Kconfig

[York Sun]

Move these options to Kconfig and clean up existing uses.

Signed-off-by: York Sun 
---
 arch/arm/cpu/armv7/ls102xa/Kconfig| 11 +++
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 16 
 arch/arm/include/asm/arch-fsl-layerscape/config.h |  5 -
 arch/arm/include/asm/arch-ls102xa/config.h|  2 --
 include/configs/ls1012a_common.h  |  2 --
 include/configs/ls1021aqds.h  |  2 --
 include/configs/ls1021atwr.h  |  2 --
 include/configs/ls1043a_common.h  |  3 ---
 include/configs/ls1043aqds.h  |  2 --
 include/configs/ls1046a_common.h  |  3 ---
 include/configs/ls1046aqds.h  |  2 --
 include/configs/ls2080a_common.h  |  3 ---
 12 files changed, 27 insertions(+), 26 deletions(-)

diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig 
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index 88983f4..17f1975 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -1,6 +1,8 @@
 config ARCH_LS1021A
bool
select SYS_FSL_ERRATUM_A010315
+   select SYS_FSL_SRDS_1
+   select SYS_HAS_SERDES
 
 menu "LS102xA architecture"
depends on ARCH_LS1021A
@@ -23,6 +25,15 @@ config MAX_CPUS
 config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
 
+config SYS_FSL_SRDS_1
+   bool
+
+config SYS_FSL_SRDS_2
+   bool
+
+config SYS_HAS_SERDES
+   bool
+
 config SYS_FSL_IFC_BANK_COUNT
int "Maximum banks of Integrated flash controller"
depends on ARCH_LS1021A
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index f683a14..66e509e 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -12,16 +12,23 @@ config ARCH_LS1043A
 config ARCH_LS1046A
bool
select FSL_LSCH2
+   select SYS_FSL_SRDS_2
 
 config ARCH_LS2080A
bool
select FSL_LSCH3
+   select SYS_FSL_HAS_DP_DDR
+   select SYS_FSL_SRDS_2
 
 config FSL_LSCH2
bool
+   select SYS_FSL_SRDS_1
+   select SYS_HAS_SERDES
 
 config FSL_LSCH3
bool
+   select SYS_FSL_SRDS_1
+   select SYS_HAS_SERDES
 
 menu "Layerscape architecture"
depends on FSL_LSCH2 || FSL_LSCH3
@@ -60,4 +67,13 @@ config SYS_FSL_IFC_BANK_COUNT
 config SYS_FSL_HAS_DP_DDR
bool
 
+config SYS_FSL_SRDS_1
+   bool
+
+config SYS_FSL_SRDS_2
+   bool
+
+config SYS_HAS_SERDES
+   bool
+
 endmenu
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 6ee75cb..3039e72 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -32,8 +32,6 @@
 #ifdef CONFIG_LS2080A
 #define CONFIG_SYS_FSL_CLUSTER_CLOCKS  { 1, 1, 4, 4 }
 #defineSRDS_MAX_LANES  8
-#define CONFIG_SYS_FSL_SRDS_1
-#define CONFIG_SYS_FSL_SRDS_2
 #define CONFIG_SYS_PAGE_SIZE   0x1
 #ifndef L1_CACHE_BYTES
 #define L1_CACHE_SHIFT 6
@@ -162,8 +160,6 @@
 #define CONFIG_SYS_FSL_PEX_LUT_BE
 #define CONFIG_SYS_FSL_SEC_BE
 
-#define CONFIG_SYS_FSL_SRDS_1
-
 /* SoC related */
 #ifdef CONFIG_LS1043A
 #define CONFIG_SYS_FMAN_V3
@@ -212,7 +208,6 @@
 #define CONFIG_SYS_DDR_BLOCK1_SIZE  ((phys_size_t)2 << 30)
 #define CONFIG_MAX_MEM_MAPPED   CONFIG_SYS_DDR_BLOCK1_SIZE
 
-#define CONFIG_SYS_FSL_SRDS_2
 #define CONFIG_SYS_FSL_IFC_BE
 #define CONFIG_SYS_FSL_SFP_VER_3_2
 #define CONFIG_SYS_FSL_SNVS_LE
diff --git a/arch/arm/include/asm/arch-ls102xa/config.h 
b/arch/arm/include/asm/arch-ls102xa/config.h
index 70cc703..dfcb546 100644
--- a/arch/arm/include/asm/arch-ls102xa/config.h
+++ b/arch/arm/include/asm/arch-ls102xa/config.h
@@ -120,8 +120,6 @@
 
 #define DCU_LAYER_MAX_NUM  16
 
-#define CONFIG_SYS_FSL_SRDS_1
-
 #ifdef CONFIG_LS102XA
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT  8
 #define CONFIG_NUM_DDR_CONTROLLERS 1
diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 1056755..ced8ead 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -10,8 +10,6 @@
 #define CONFIG_FSL_LAYERSCAPE
 #define CONFIG_GICV2
 
-#defineCONFIG_SYS_HAS_SERDES
-
 #include 
 #define CONFIG_SYS_NO_FLASH
 
diff --git a/include/configs/ls1021aqds.h b/include/configs/ls1021aqds.h
index 0d72e69..5ff3db6 100644
--- a/include/configs/ls1021aqds.h
+++ b/include/configs/ls1021aqds.h
@@ -143,8 +143,6 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_MEM_INIT_VALUE   0xdeadbeef
 #endif
 
-#define CONFIG_SYS_HAS_SERDES
-
 #define CONFIG_FSL_CAAM/* Enable CAAM */
 
 #if !defined(CONFIG_SD_BOOT) && !defined(CONFIG_NAND_BOOT) && \
diff --git a/include/configs/ls1021atwr.h b/include/configs/ls1021atwr.h
index 

[U-Boot] [RFC PATCH 5/6] arm: Move FSL_HAS_DP_DDR and NUM_DDR_CONTROLLERS to Kconfig

[York Sun]

Move this option to Kconfig and clean up existing uses.
NUM_DDR_CONTROLLERS is also used by PowerPC SoCs.

Signed-off-by: York Sun 
---
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 8 
 arch/arm/include/asm/arch-fsl-layerscape/config.h | 3 ---
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index aa412ec..f683a14 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -45,6 +45,11 @@ config MAX_CPUS
  cores, count the reserved ports. This will allocate enough memory
  in spin table to properly handle all cores.
 
+config NUM_DDR_CONTROLLERS
+   int "Maximum DDR controllers"
+   default 3 if ARCH_LS2080A
+   default 1
+
 config SYS_FSL_IFC_BANK_COUNT
int "Maximum banks of Integrated flash controller"
depends on ARCH_LS1043A || ARCH_LS1046A || ARCH_LS2080A
@@ -52,4 +57,7 @@ config SYS_FSL_IFC_BANK_COUNT
default 4 if ARCH_LS1046A
default 8 if ARCH_LS2080A
 
+config SYS_FSL_HAS_DP_DDR
+   bool
+
 endmenu
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/config.h 
b/arch/arm/include/asm/arch-fsl-layerscape/config.h
index 2f10ab7..6ee75cb 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/config.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/config.h
@@ -30,8 +30,6 @@
 #define CONFIG_SYS_MEM_RESERVE_SECURE  (2048 * 1024)   /* 2MB */
 
 #ifdef CONFIG_LS2080A
-#define CONFIG_NUM_DDR_CONTROLLERS 3
-#define CONFIG_SYS_FSL_HAS_DP_DDR  /* Runtime check to confirm */
 #define CONFIG_SYS_FSL_CLUSTER_CLOCKS  { 1, 1, 4, 4 }
 #defineSRDS_MAX_LANES  8
 #define CONFIG_SYS_FSL_SRDS_1
@@ -150,7 +148,6 @@
 
 #define CONFIG_SYS_FSL_MAX_NUM_OF_SEC  1
 #elif defined(CONFIG_FSL_LSCH2)
-#define CONFIG_NUM_DDR_CONTROLLERS 1
 #define CONFIG_SYS_FSL_SEC_COMPAT  5
 #define CONFIG_SYS_FSL_OCRAM_BASE  0x1000 /* initial RAM */
 #define CONFIG_SYS_FSL_OCRAM_SIZE  0x0020 /* 2M */
-- 
2.7.4

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

[U-Boot] [RFC PATCH 2/6] arm: Move FSL_LSCH2 FSL_LSCH3 to Kconfig

[York Sun]

Move these options to Kconfig and create a sub-menu to avoid name
conflict with other architectures.

Signed-off-by: York Sun 
---
 arch/arm/Kconfig  |  4 
 arch/arm/cpu/armv7/ls102xa/Kconfig|  8 
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig | 15 +++
 include/configs/ls1012a_common.h  |  1 -
 include/configs/ls1043a_common.h  |  1 -
 include/configs/ls1046a_common.h  |  1 -
 include/configs/ls2080a_common.h  |  1 -
 scripts/config_whitelist.txt  |  2 --
 8 files changed, 27 insertions(+), 6 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 1e4830a..43722bc 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -729,6 +729,7 @@ config TARGET_VEXPRESS64_JUNO
 
 config TARGET_LS2080A_EMU
bool "Support ls2080a_emu"
+   select ARCH_LS2080A
select ARM64
select ARMV8_MULTIENTRY
help
@@ -739,6 +740,7 @@ config TARGET_LS2080A_EMU
 
 config TARGET_LS2080A_SIMU
bool "Support ls2080a_simu"
+   select ARCH_LS2080A
select ARM64
select ARMV8_MULTIENTRY
help
@@ -749,6 +751,7 @@ config TARGET_LS2080A_SIMU
 
 config TARGET_LS2080AQDS
bool "Support ls2080aqds"
+   select ARCH_LS2080A
select ARM64
select ARMV8_MULTIENTRY
select SUPPORT_SPL
@@ -760,6 +763,7 @@ config TARGET_LS2080AQDS
 
 config TARGET_LS2080ARDB
bool "Support ls2080ardb"
+   select ARCH_LS2080A
select ARM64
select ARMV8_MULTIENTRY
select SUPPORT_SPL
diff --git a/arch/arm/cpu/armv7/ls102xa/Kconfig 
b/arch/arm/cpu/armv7/ls102xa/Kconfig
index f0e7ae9..2648416 100644
--- a/arch/arm/cpu/armv7/ls102xa/Kconfig
+++ b/arch/arm/cpu/armv7/ls102xa/Kconfig
@@ -2,6 +2,14 @@ config ARCH_LS1021A
bool
select SYS_FSL_ERRATUM_A010315
 
+menu "LS102xA architecture"
+   depends on ARCH_LS1021A
+
 config LS1_DEEP_SLEEP
bool "Deep sleep"
depends on ARCH_LS1021A
+
+config SYS_FSL_ERRATUM_A010315
+   bool "Workaround for PCIe erratum A010315"
+
+endmenu
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 045261f..5619e0d 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -1,20 +1,35 @@
 config ARCH_LS1012A
bool
+   select FSL_LSCH2
select SYS_FSL_MMDC
select SYS_FSL_ERRATUM_A010315
 
 config ARCH_LS1043A
bool
+   select FSL_LSCH2
select SYS_FSL_ERRATUM_A010315
 
 config ARCH_LS1046A
bool
+   select FSL_LSCH2
 
 config ARCH_LS2080A
bool
+   select FSL_LSCH3
+
+config FSL_LSCH2
+   bool
+
+config FSL_LSCH3
+   bool
+
+menu "Layerscape architecture"
+   depends on FSL_LSCH2 || FSL_LSCH3
 
 config SYS_FSL_MMDC
bool
 
 config SYS_FSL_ERRATUM_A010315
bool "Workaround for PCIe erratum A010315"
+
+endmenu
diff --git a/include/configs/ls1012a_common.h b/include/configs/ls1012a_common.h
index 5fb6c47..1056755 100644
--- a/include/configs/ls1012a_common.h
+++ b/include/configs/ls1012a_common.h
@@ -8,7 +8,6 @@
 #define __LS1012A_COMMON_H
 
 #define CONFIG_FSL_LAYERSCAPE
-#define CONFIG_FSL_LSCH2
 #define CONFIG_GICV2
 
 #defineCONFIG_SYS_HAS_SERDES
diff --git a/include/configs/ls1043a_common.h b/include/configs/ls1043a_common.h
index ed0e434..ac86c08 100644
--- a/include/configs/ls1043a_common.h
+++ b/include/configs/ls1043a_common.h
@@ -9,7 +9,6 @@
 
 #define CONFIG_REMAKE_ELF
 #define CONFIG_FSL_LAYERSCAPE
-#define CONFIG_FSL_LSCH2
 #define CONFIG_LS1043A
 #define CONFIG_MP
 #define CONFIG_SYS_FSL_CLK
diff --git a/include/configs/ls1046a_common.h b/include/configs/ls1046a_common.h
index 7c5e635..ec6c908 100644
--- a/include/configs/ls1046a_common.h
+++ b/include/configs/ls1046a_common.h
@@ -9,7 +9,6 @@
 
 #define CONFIG_REMAKE_ELF
 #define CONFIG_FSL_LAYERSCAPE
-#define CONFIG_FSL_LSCH2
 #define CONFIG_MP
 #define CONFIG_SYS_FSL_CLK
 #define CONFIG_GICV2
diff --git a/include/configs/ls2080a_common.h b/include/configs/ls2080a_common.h
index 42d0298..d9eea09 100644
--- a/include/configs/ls2080a_common.h
+++ b/include/configs/ls2080a_common.h
@@ -9,7 +9,6 @@
 
 #define CONFIG_REMAKE_ELF
 #define CONFIG_FSL_LAYERSCAPE
-#define CONFIG_FSL_LSCH3
 #define CONFIG_MP
 #define CONFIG_GICV3
 #define CONFIG_FSL_TZPC_BP147
diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
index efa95f0..d717103 100644
--- a/scripts/config_whitelist.txt
+++ b/scripts/config_whitelist.txt
@@ -1299,8 +1299,6 @@ CONFIG_FSL_LAW
 CONFIG_FSL_LAYERSCAPE
 CONFIG_FSL_LBC
 CONFIG_FSL_LINFLEXUART
-CONFIG_FSL_LSCH2
-CONFIG_FSL_LSCH3
 CONFIG_FSL_LS_PPA
 CONFIG_FSL_MC9SDZ60
 CONFIG_FSL_MC_ENET
-- 
2.7.4

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

[U-Boot] [RFC PATCH 0/6] Move some config macros to Kconfig

[York Sun]

Guys,

I try to move some config macros to Kconfig. This is a beginning.
Please review this set and let me know.

[RFC PATCH 1/6] arm: Fix Kconfig for proper display menu
[RFC PATCH 2/6] arm: Move FSL_LSCH2 FSL_LSCH3 to Kconfig
[RFC PATCH 3/6] arm: Move MAX_CPUS to Kconfig
[RFC PATCH 4/6] arm: Move SYS_FSL_IFC_BANK_COUNT to Kconfig
[RFC PATCH 5/6] arm: Move FSL_HAS_DP_DDR and NUM_DDR_CONTROLLERS to
[RFC PATCH 6/6] arm: Move SYS_FSL_SRDS_* and SYS_HAS_SERDES to Kconfig

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

Re: [U-Boot] [PATCH] sunxi: Fix H3 DRAM impedance calibration on rev. A chips

[Jagan Teki]

On Fri, Sep 30, 2016 at 7:55 PM, Jens Kuske  wrote:
> On 30.09.2016 15:17, Jagan Teki wrote:
>> On Fri, Sep 30, 2016 at 6:20 PM, Jens Kuske  wrote:
>>> On 30.09.2016 14:24, Jagan Teki wrote:
 On Wed, Sep 21, 2016 at 11:38 PM, Jens Kuske  wrote:
> H3 seems to have a silicon bug breaking the impedance calibration.
> This is currently worked around in software by multiple steps
> combining the results to replace the wrong values.
>
> Revision A chips need a different workaround, which is present in
> the vendor bootloader too, but got overlooked in lack of
> information and affected boards till now.
> This commit adds a simplified version without correction factor,
> which would be 1.00 for all known boards anyway.
>
> Signed-off-by: Jens Kuske 
> ---
>
> Hi,
>
> This has been tested by an Armbian user:
> http://forum.armbian.com/index.php/topic/872-beelink-x2-with-armbian-possible/?p=16061
>
> It looks like only few boards have revision A chips, probably only
> non-development boards, otherwise we would have found this earlier.
> The idea that these are different chip revision is based on:
> https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L341
>
> Regards,
> Jens
>
> ---
>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 64 
> +
>  1 file changed, 43 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> index 2020d75..b08b8e6 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> @@ -217,35 +217,57 @@ static void mctl_zq_calibration(struct dram_para 
> *para)
> struct sunxi_mctl_ctl_reg * const mctl_ctl =
> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>
> -   int i;
> -   u16 zq_val[6];
> -   u8 val;
> +   if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
> +   (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {

 I think we can unlock before reading the sram version, do you think
 so? and lock same after.
>>>
>>> We don't have to unlock to read this field, it's even documented in the
>>> datasheet. Only to read the full version in bits 31:16 it has to be
>>> unlocked. Or what did you mean?
>>
>> This code is detecting H3 rev.A chip, correct? I'm thinking we need to
>> detect the H3(0x1680) first and check for rev.A for safety.
>
> All code in this file must only be run on H3, otherwise everything else
> will fail too. So we don't have extra checks for that anywhere, the SoC
> version is a compiletime option for all sunxi code.

OK.

>
>> Can you
>> point me where it documented, unable to find the same.
>
> H3 Datasheet v1.2 page 152 (VER_BITS), but only the 0x24, 0xf0 is from
> https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L338-L341

Thanks.

Reviewed-by: Jagan Teki 

-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 2/6] apalis/colibri_t20/t30: deactivate displaying board info

[Marcel Ziswiler]

On Wed, 2016-09-28 at 12:00 -0600, Stephen Warren wrote:
> On 09/28/2016 03:35 AM, Marcel Ziswiler wrote:
> > 
> > Avoid a checkboard() name clash with our upcoming custom
> > implementation
> > thereof.
> If you want to avoid naming conflicts, please simply name your new 
> function something that doesn't conflict. That way it will avoid 
> confusion is someone actually wants to enable the 
> CONFIG_DISPLAY_BOARDINFO option themselves, plus it avoids taking
> the 
> current feature set away.

No, it is not just any function. We do want our custom checkboard() to
be called upon boot and not the Tegra generic one just printing a hard
coded string.

I guess alternatively we could gate the checkboard() call
in arch/arm/mach-tegra/board2.c with a

#if !defined(CONFIG_CUSTOM_BOARDINFO)

just as introduced a while ago in common/board_info.c

http://git.denx.de/?p=u-boot.git;a=blob;f=common/board_info.c;h=bd5dcfa
066358c2cc44ce5d19fcc3e77d555cd09;hb=HEAD#l20

in order to not print the hard coded name from the device tree.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 14/23] gpio: Provide dummy get/request & is_valid functions

[Paul Burton]

On Monday, 26 September 2016 18:35:25 BST Simon Glass wrote:
> Hi Paul,
> 
> On 26 September 2016 at 12:29, Paul Burton  wrote:
> > Allow for drivers to make use of driver model GPIOs when they're enabled
> > & available without needing to #ifdef on CONFIG_DM_GPIO by providing
> > dummy functions covering GPIO requests. Each will simply return -ENODEV
> > or -EINVAL, depending upon which the real implementation returns when a
> > GPIO isn't found. Only the driver model versions of the GPIO request
> > functions are covered & dm_gpio_request is excluded since it's
> > documented as only being of use for debugging, so drivers shouldn't be
> > calling it anyway.
> > 
> > Also provide a dummy dm_gpio_is_valid, with the idea that all other GPIO
> > functions called would be within an if (dm_gpio_is_valid(...)) statement
> > and have been optimised out in cases where that returns a compile-time
> > constant false.
> > 
> > This parallels the clock API, keeping the #ifdefs & checks in a single
> > location allowing drivers or other code to use GPIOs without needing to
> > perform such checks themselves.
> > 
> > Signed-off-by: Paul Burton 
> > 
> > ---
> > 
> >  include/asm-generic/gpio.h | 38 ++
> >  1 file changed, 38 insertions(+)
> 
> Ick - why not just define DM_GPIO? I don't think we want to provide
> special support for legacy things. It is just confusing.
> 
> - Simon

Hi Simon,

For the MIPS Boston system I already enable DM_GPIO, I went with this approach 
so that it 
wouldn't necessarily need to be enabled for the Crown Bay x86 system which is 
the other 
user of the pch_gbe driver.

Would having pch_gbe depend on CONFIG_DM_GPIO be ok with you Bin? I see 
crownbay_defconfig enables CONFIG_CMD_GPIO but couldn't find any GPIO-using 
code at 
a glance. So hopefully it would just work without needing to change any 
existing crownbay 
code?

Thanks,
Paul


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM:dts: Added device tree for socfpga arria10 development kit sdmmc

[Marek Vasut]

On 09/30/2016 10:12 AM, Tien Fong Chee wrote:
> This is initial version of device tree for the Intel socfpga arria10
> development kit with sdmmc.
> 
> Signed-off-by: Tien Fong Chee 
> Cc: Marek Vasut 
> Cc: Stefan Roese 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> Cc: Tien Fong 
> ---
>  arch/arm/dts/socfpga_arria10.dtsi   |  866 
> +++
>  arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi |  457 
>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts|   30 +
>  3 files changed, 1353 insertions(+), 0 deletions(-)
>  create mode 100755 arch/arm/dts/socfpga_arria10.dtsi
>  create mode 100755 arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi
>  create mode 100755 arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> 

How does this fit with this previous stuff ?
http://git.denx.de/?p=u-boot/u-boot-socfpga.git;a=shortlog;h=refs/heads/01-arria10

Can I compile U-Boot and run it on A10 with this DT ?

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

Re: [U-Boot] [PATCH] ARM:dts: Added device tree for socfpga arria10 development kit sdmmc

[Dinh Nguyen]

On 09/30/2016 03:12 AM, Tien Fong Chee wrote:
> This is initial version of device tree for the Intel socfpga arria10

I would think that it's still an Altera SOCFPGA.

> development kit with sdmmc.
> 
> Signed-off-by: Tien Fong Chee 
> Cc: Marek Vasut 
> Cc: Stefan Roese 
> Cc: Dinh Nguyen 
> Cc: Chin Liang See 
> Cc: Tien Fong 
> ---
>  arch/arm/dts/socfpga_arria10.dtsi   |  866 
> +++
>  arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi |  457 
>  arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts|   30 +
>  3 files changed, 1353 insertions(+), 0 deletions(-)
>  create mode 100755 arch/arm/dts/socfpga_arria10.dtsi
>  create mode 100755 arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi
>  create mode 100755 arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> 

Please recheck all of your file attributes. They should be 100644.

> diff --git a/arch/arm/dts/socfpga_arria10.dtsi 
> b/arch/arm/dts/socfpga_arria10.dtsi
> new file mode 100755
> index 000..8ed5ff4
> --- /dev/null
> +++ b/arch/arm/dts/socfpga_arria10.dtsi
> @@ -0,0 +1,866 @@

[snip}
> +
> + base_fpga_region {
> + compatible = "fpga-region";
> + fpga-mgr = <_mgr>;
> +
> + #address-cells = <0x1>;
> + #size-cells = <0x1>;
> + };

This has has not been upstreamed and accepted yet, I think.

> +
> + clkmgr@ffd04000 {
> + compatible = "intc,clk-mgr";

Whoa...why are you replacing "altr" with "intc"? If you switch from altr
to intc, then none of the bindings have been accepted yet and needs to
be resubmitted.

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

[U-Boot] is there any issue with creating and using more than one hashtable?

[Robert P. J. Day]

  short version: migrating target board from legacy OS to linux and,
in a fixed address in flash, there is a legacy "bootline" of the form

var=value var=value ... etc etc ...

that i want to convert to u-boot compatible values such as ipaddr,
gatewayip, serverip and so on.

  in misc_init_r(), i create a new hashtable to just grab the contents
of that bootline as is. i then create a *second* hashtable and
selectively move over just those keys i want from the first hashtable,
possibly renaming them in the process.

  in the end, i end up with a small hashtable of u-boot compatible
values, which i dump by walking through that second hashtable:

  Walking populated bootline_htab_2...
  k: [gatewayip], d: [192.168.1.1]
  k: [netmask], d: [255.255.255.0]
  k: [ipaddr], d: [192.168.1.2]

now here's the thing ... after all that, i manually check whether the
CRC for the env table in persistent storage is valid and, if it is, i
do *nothing* with all that hashtable content -- that was all wasted
cycles, but it should not do any harm.

  but it does, because this is what happens:

  TFTP from server 10.35.5.37; our IP address is 192.168.1.2; sending
  through gateway 192.168.1.1

the server address is correct, but the IP address and gateway are
totally wrong -- they should have been untouched and been completely
different values; instead, they now equal the values in that second
hashtable, which i chose to do nothing with.

  is there some weird issue with re-entrancy here? if i print "ipaddr"
and "gatewayip", they seem correct. if i "md" the environment in
persistent storage, again, they seem correct. and yet, when TFTP kicks
in, it seems to pick up the values from that hashtable.

  thoughts? is there some weird way that values from one hashtable can
"bleed" into another one? i'm baffled.

rday

-- 


Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter:   http://twitter.com/rpjday
LinkedIn:   http://ca.linkedin.com/in/rpjday


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

Re: [U-Boot] [PATCH 2/6] efi_loader: Fix memory map size check to avoid out-of-bounds access

[Alexander Graf]

On 30.09.16 16:15, Brüns, Stefan wrote:
> On Freitag, 30. September 2016 14:25:40 CEST Alexander Graf wrote:
>> On 30.09.16 02:03, Stefan Brüns wrote:
>>> memory_map_size as IN parameter specifies the size of the provided buffer.
>>> If the buffer is to small, memory_map_size is updated to indicate the
>>> required size, and an error code is returned.
>>>
>>> Signed-off-by: Stefan Brüns 
>>
>> This patch doesn't actually change anything, does it?
> 
> It does ...
> 
>>
>> Alex
>>
>>> ---
>>>
>>>  lib/efi_loader/efi_memory.c | 8 +---
>>>  1 file changed, 5 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
>>> index ebe8e94..5d71fdf 100644
>>> --- a/lib/efi_loader/efi_memory.c
>>> +++ b/lib/efi_loader/efi_memory.c
>>> @@ -342,16 +342,18 @@ efi_status_t efi_get_memory_map(unsigned long
>>> *memory_map_size,> 
>>> map_size = map_entries * sizeof(struct efi_mem_desc);
>>>
>>> -   *memory_map_size = map_size;
> 
> The caller provided buffer size was changed here
> 
>>> -
>>>
>>> if (descriptor_size)
>>> 
>>> *descriptor_size = sizeof(struct efi_mem_desc);
>>> 
>>> if (descriptor_version)
>>> 
>>> *descriptor_version = EFI_MEMORY_DESCRIPTOR_VERSION;
>>>
>>> -   if (*memory_map_size < map_size)
> 
> -> this check was always false

Ah, I see it now. Could you please adjust the commit message to point
that out properly? :)


Thanks!

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

Re: [U-Boot] [PATCH] sunxi: Fix H3 DRAM impedance calibration on rev. A chips

[Jens Kuske]

On 30.09.2016 15:17, Jagan Teki wrote:
> On Fri, Sep 30, 2016 at 6:20 PM, Jens Kuske  wrote:
>> On 30.09.2016 14:24, Jagan Teki wrote:
>>> On Wed, Sep 21, 2016 at 11:38 PM, Jens Kuske  wrote:
 H3 seems to have a silicon bug breaking the impedance calibration.
 This is currently worked around in software by multiple steps
 combining the results to replace the wrong values.

 Revision A chips need a different workaround, which is present in
 the vendor bootloader too, but got overlooked in lack of
 information and affected boards till now.
 This commit adds a simplified version without correction factor,
 which would be 1.00 for all known boards anyway.

 Signed-off-by: Jens Kuske 
 ---

 Hi,

 This has been tested by an Armbian user:
 http://forum.armbian.com/index.php/topic/872-beelink-x2-with-armbian-possible/?p=16061

 It looks like only few boards have revision A chips, probably only
 non-development boards, otherwise we would have found this earlier.
 The idea that these are different chip revision is based on:
 https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L341

 Regards,
 Jens

 ---
  arch/arm/mach-sunxi/dram_sun8i_h3.c | 64 
 +
  1 file changed, 43 insertions(+), 21 deletions(-)

 diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
 b/arch/arm/mach-sunxi/dram_sun8i_h3.c
 index 2020d75..b08b8e6 100644
 --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
 +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
 @@ -217,35 +217,57 @@ static void mctl_zq_calibration(struct dram_para 
 *para)
 struct sunxi_mctl_ctl_reg * const mctl_ctl =
 (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;

 -   int i;
 -   u16 zq_val[6];
 -   u8 val;
 +   if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
 +   (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {
>>>
>>> I think we can unlock before reading the sram version, do you think
>>> so? and lock same after.
>>
>> We don't have to unlock to read this field, it's even documented in the
>> datasheet. Only to read the full version in bits 31:16 it has to be
>> unlocked. Or what did you mean?
> 
> This code is detecting H3 rev.A chip, correct? I'm thinking we need to
> detect the H3(0x1680) first and check for rev.A for safety.

All code in this file must only be run on H3, otherwise everything else
will fail too. So we don't have extra checks for that anywhere, the SoC
version is a compiletime option for all sunxi code.

> Can you
> point me where it documented, unable to find the same.

H3 Datasheet v1.2 page 152 (VER_BITS), but only the 0x24, 0xf0 is from
https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L338-L341

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

Re: [U-Boot] [PATCH 2/6] efi_loader: Fix memory map size check to avoid out-of-bounds access

[Brüns , Stefan]

On Freitag, 30. September 2016 14:25:40 CEST Alexander Graf wrote:
> On 30.09.16 02:03, Stefan Brüns wrote:
> > memory_map_size as IN parameter specifies the size of the provided buffer.
> > If the buffer is to small, memory_map_size is updated to indicate the
> > required size, and an error code is returned.
> > 
> > Signed-off-by: Stefan Brüns 
> 
> This patch doesn't actually change anything, does it?

It does ...

> 
> Alex
> 
> > ---
> > 
> >  lib/efi_loader/efi_memory.c | 8 +---
> >  1 file changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> > index ebe8e94..5d71fdf 100644
> > --- a/lib/efi_loader/efi_memory.c
> > +++ b/lib/efi_loader/efi_memory.c
> > @@ -342,16 +342,18 @@ efi_status_t efi_get_memory_map(unsigned long
> > *memory_map_size,> 
> > map_size = map_entries * sizeof(struct efi_mem_desc);
> > 
> > -   *memory_map_size = map_size;

The caller provided buffer size was changed here

> > -
> > 
> > if (descriptor_size)
> > 
> > *descriptor_size = sizeof(struct efi_mem_desc);
> > 
> > if (descriptor_version)
> > 
> > *descriptor_version = EFI_MEMORY_DESCRIPTOR_VERSION;
> > 
> > -   if (*memory_map_size < map_size)

-> this check was always false

> > +   if (*memory_map_size < map_size) {
> > +   *memory_map_size = map_size;
> > 
> > return EFI_BUFFER_TOO_SMALL;
> > 
> > +   }
> > +
> > +   *memory_map_size = map_size;
> > 
> > /* Copy list into array */
> > if (memory_map) {

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

[U-Boot] [PATCH] arch: powerpc: Remove unused dts frequency fixup for lbc_clk

[Prabhakar Kushwaha]

lbc_clk is used to fixup dts as "bus frequency".
It is not being used by Linux IFC and eLBC driver.

So remove unused "bus frqeuency" fix-up of devicre tree.

Signed-off-by: Prabhakar Kushwaha 
---
 arch/powerpc/cpu/mpc85xx/fdt.c | 4 
 arch/powerpc/cpu/mpc86xx/fdt.c | 7 ---
 2 files changed, 11 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index ced216c..047c972 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -626,10 +626,6 @@ void ft_cpu_setup(void *blob, bd_t *bd)
do_fixup_by_prop_u32(blob, "device_type", "soc", 4,
"bus-frequency", bd->bi_busfreq, 1);
 
-   do_fixup_by_compat_u32(blob, "fsl,pq3-localbus",
-   "bus-frequency", gd->arch.lbc_clk, 1);
-   do_fixup_by_compat_u32(blob, "fsl,elbc",
-   "bus-frequency", gd->arch.lbc_clk, 1);
 #ifdef CONFIG_QE
ft_qe_setup(blob);
ft_fixup_qe_snum(blob);
diff --git a/arch/powerpc/cpu/mpc86xx/fdt.c b/arch/powerpc/cpu/mpc86xx/fdt.c
index dd99155..5f9ad6b 100644
--- a/arch/powerpc/cpu/mpc86xx/fdt.c
+++ b/arch/powerpc/cpu/mpc86xx/fdt.c
@@ -30,13 +30,6 @@ void ft_cpu_setup(void *blob, bd_t *bd)
do_fixup_by_prop_u32(blob, "device_type", "soc", 4,
 "bus-frequency", bd->bi_busfreq, 1);
 
-#if defined(CONFIG_MPC8641)
-   do_fixup_by_compat_u32(blob, "fsl,mpc8641-localbus",
-  "bus-frequency", gd->arch.lbc_clk, 1);
-#endif
-   do_fixup_by_compat_u32(blob, "fsl,elbc",
-  "bus-frequency", gd->arch.lbc_clk, 1);
-
fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
 
 #if defined(CONFIG_HAS_ETH0) || defined(CONFIG_HAS_ETH1) \
-- 
2.7.4


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

Re: [U-Boot] [PATCH] sunxi: Fix H3 DRAM impedance calibration on rev. A chips

[Jagan Teki]

On Fri, Sep 30, 2016 at 6:20 PM, Jens Kuske  wrote:
> On 30.09.2016 14:24, Jagan Teki wrote:
>> On Wed, Sep 21, 2016 at 11:38 PM, Jens Kuske  wrote:
>>> H3 seems to have a silicon bug breaking the impedance calibration.
>>> This is currently worked around in software by multiple steps
>>> combining the results to replace the wrong values.
>>>
>>> Revision A chips need a different workaround, which is present in
>>> the vendor bootloader too, but got overlooked in lack of
>>> information and affected boards till now.
>>> This commit adds a simplified version without correction factor,
>>> which would be 1.00 for all known boards anyway.
>>>
>>> Signed-off-by: Jens Kuske 
>>> ---
>>>
>>> Hi,
>>>
>>> This has been tested by an Armbian user:
>>> http://forum.armbian.com/index.php/topic/872-beelink-x2-with-armbian-possible/?p=16061
>>>
>>> It looks like only few boards have revision A chips, probably only
>>> non-development boards, otherwise we would have found this earlier.
>>> The idea that these are different chip revision is based on:
>>> https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L341
>>>
>>> Regards,
>>> Jens
>>>
>>> ---
>>>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 64 
>>> +
>>>  1 file changed, 43 insertions(+), 21 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
>>> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>>> index 2020d75..b08b8e6 100644
>>> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>>> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>>> @@ -217,35 +217,57 @@ static void mctl_zq_calibration(struct dram_para 
>>> *para)
>>> struct sunxi_mctl_ctl_reg * const mctl_ctl =
>>> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>>>
>>> -   int i;
>>> -   u16 zq_val[6];
>>> -   u8 val;
>>> +   if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
>>> +   (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {
>>
>> I think we can unlock before reading the sram version, do you think
>> so? and lock same after.
>
> We don't have to unlock to read this field, it's even documented in the
> datasheet. Only to read the full version in bits 31:16 it has to be
> unlocked. Or what did you mean?

This code is detecting H3 rev.A chip, correct? I'm thinking we need to
detect the H3(0x1680) first and check for rev.A for safety. Can you
point me where it documented, unable to find the same.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Display output in LCD

[Othmane Essamlali]

Hello all,
 
We have a "Ka-Ro TX6S-8035"  Board (TX baseboard + Freescale i.MX6SoloX) and we 
made  a Linux build for it via linuxlink (timesys) based on Yocto 
installer(QT5).
 
We are now able to boot our system from the board but we still cant assign the 
output to the lcd(FG0700G3DSSWBG01).
 
We tryed setenv stdout/stderr/stdin/ lcd then saveenv, after rebooting they are 
set to serial again. Except those variables the rest stay saved after the 
reboot.
 
We are wondering if we are missing something, maybe someone can help over there.
 
Thanks a lot.
 
Otman Essam
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Fix H3 DRAM impedance calibration on rev. A chips

[Jens Kuske]

On 30.09.2016 14:24, Jagan Teki wrote:
> On Wed, Sep 21, 2016 at 11:38 PM, Jens Kuske  wrote:
>> H3 seems to have a silicon bug breaking the impedance calibration.
>> This is currently worked around in software by multiple steps
>> combining the results to replace the wrong values.
>>
>> Revision A chips need a different workaround, which is present in
>> the vendor bootloader too, but got overlooked in lack of
>> information and affected boards till now.
>> This commit adds a simplified version without correction factor,
>> which would be 1.00 for all known boards anyway.
>>
>> Signed-off-by: Jens Kuske 
>> ---
>>
>> Hi,
>>
>> This has been tested by an Armbian user:
>> http://forum.armbian.com/index.php/topic/872-beelink-x2-with-armbian-possible/?p=16061
>>
>> It looks like only few boards have revision A chips, probably only
>> non-development boards, otherwise we would have found this earlier.
>> The idea that these are different chip revision is based on:
>> https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L341
>>
>> Regards,
>> Jens
>>
>> ---
>>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 64 
>> +
>>  1 file changed, 43 insertions(+), 21 deletions(-)
>>
>> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
>> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> index 2020d75..b08b8e6 100644
>> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
>> @@ -217,35 +217,57 @@ static void mctl_zq_calibration(struct dram_para *para)
>> struct sunxi_mctl_ctl_reg * const mctl_ctl =
>> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>>
>> -   int i;
>> -   u16 zq_val[6];
>> -   u8 val;
>> +   if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
>> +   (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {
> 
> I think we can unlock before reading the sram version, do you think
> so? and lock same after.

We don't have to unlock to read this field, it's even documented in the
datasheet. Only to read the full version in bits 31:16 it has to be
unlocked. Or what did you mean?

> 
>> +   u32 reg_val;
>>
>> -   writel(0x0a0a0a0a, _ctl->zqdr[2]);
>> -
>> -   for (i = 0; i < 6; i++) {
>> -   u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf;
>> -
>> -   writel((zq << 20) | (zq << 16) | (zq << 12) |
>> -   (zq << 8) | (zq << 4) | (zq << 0),
>> -   _ctl->zqcr);
>> +   clrsetbits_le32(_ctl->zqcr, 0x,
>> +   CONFIG_DRAM_ZQ & 0x);
>>
>> writel(PIR_CLRSR, _ctl->pir);
>> mctl_phy_init(PIR_ZCAL);
>>
>> -   zq_val[i] = readl(_ctl->zqdr[0]) & 0xff;
>> -   writel(REPEAT_BYTE(zq_val[i]), _ctl->zqdr[2]);
>> +   reg_val = readl(_ctl->zqdr[0]);
>> +   reg_val &= (0x1f << 16) | (0x1f << 0);
>> +   reg_val |= reg_val << 8;
>> +   writel(reg_val, _ctl->zqdr[0]);
>>
>> -   writel(PIR_CLRSR, _ctl->pir);
>> -   mctl_phy_init(PIR_ZCAL);
>> +   reg_val = readl(_ctl->zqdr[1]);
>> +   reg_val &= (0x1f << 16) | (0x1f << 0);
>> +   reg_val |= reg_val << 8;
>> +   writel(reg_val, _ctl->zqdr[1]);
>> +   writel(reg_val, _ctl->zqdr[2]);
> 
> Was this write call for zqdr[2] true?

Yes, it is correct, calibration for zqdr[2] doesn't work at all, so
zqdr[1] gets copied. Both are for the data lanes, so this is reasonable.

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

Re: [U-Boot] [PATCH 6/6] efi_loader: Do not leak memory when unlinking a mapping

[Alexander Graf]

On 30.09.16 02:04, Stefan Brüns wrote:
> As soon as a mapping is unlinked from the list, there are no further
> references to it, so it should be freed. If it not unlinked,
> update the start address and length.
> 
> Signed-off-by: Stefan Brüns 

Reviewed-by: Alexander Graf 


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

Re: [U-Boot] [PATCH 5/6] efi_loader: Keep memory mapping sorted when splitting an entry

[Alexander Graf]

On 30.09.16 02:03, Stefan Brüns wrote:
> The code assumes sorted mappings in descending address order. When
> splitting a mapping, insert the new part next to the current mapping.
> 
> Signed-off-by: Stefan Brüns 

I wonder why I didn't do that. Hm. Oh well.

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

Re: [U-Boot] [PATCH 4/6] efi_loader: Readd freed pages to memory pool

[Alexander Graf]

On 30.09.16 02:03, Stefan Brüns wrote:
> Currently each allocation creates a new mapping. Readding the mapping
> as free memory (EFI_CONVENTIONAL_MEMORY) potentially allows to hand out
> an existing mapping, thus limiting the number of mapping descriptors in
> the memory map.
> 
> Mitigates a problem with current (4.8rc7) linux kernels when doing an
> efi_get_memory map, resulting in an infinite loop. Space for the memory
> map is reserved with allocate_pool (implicitly creating a new mapping) and
> filled. If there is insufficient slack space (8 entries) in the map, the
> space is freed and a new round is started, with space for one more entry.
> As each round increases requirement and allocation by exactly one, there
> is never enough slack space. (At least 32 entries are allocated, so as
> long as there are less than 24 entries, there is enough slack).
> Earlier kernels reserved no slack, and did less allocations, so this
> problem was not visible.
> 
> Signed-off-by: Stefan Brüns 

Reviewed-by: Alexander Graf 

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

Re: [U-Boot] [PATCH 3/6] efi_loader: Track size of pool allocations to allow freeing

[Alexander Graf]

On 30.09.16 02:03, Stefan Brüns wrote:
> allocate_pool has to return a buffer which is 8-byte aligned. Shift the
> region returned by allocate_pages by 8 byte and store the size in the
> headroom. The 8 byte overhead is neglegible, but provides the required
> size when freeing the allocation later.
> 
> Signed-off-by: Stefan Brüns 
> ---
>  lib/efi_loader/efi_boottime.c | 21 +++--
>  1 file changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_boottime.c b/lib/efi_loader/efi_boottime.c
> index be6f5e8..3e526eb 100644
> --- a/lib/efi_loader/efi_boottime.c
> +++ b/lib/efi_loader/efi_boottime.c
> @@ -134,18 +134,35 @@ static efi_status_t EFIAPI efi_allocate_pool(int 
> pool_type, unsigned long size,
>void **buffer)
>  {
>   efi_status_t r;
> + u64 num_pages = (size + 8 + 0xfff) >> 12;
>  
>   EFI_ENTRY("%d, %ld, %p", pool_type, size, buffer);
> - r = efi_allocate_pages(0, pool_type, (size + 0xfff) >> 12, 
> (void*)buffer);

Please base on top of this patch to avoid conflicts:

  http://lists.denx.de/pipermail/u-boot/2016-September/266580.html

> +
> + if (size == 0) {
> + *buffer = NULL;
> + return EFI_EXIT(EFI_SUCCESS);
> + }
> +
> + r = efi_allocate_pages(0, pool_type, num_pages, (void *)buffer);
> + if (r == EFI_SUCCESS) {
> + *(u64 *)(*buffer) = num_pages;
> + *buffer = (char *)(*buffer) + 8;
> + }
> +
>   return EFI_EXIT(r);
>  }
>  
>  static efi_status_t EFIAPI efi_free_pool(void *buffer)
>  {
>   efi_status_t r;
> + u64 num_pages;
>  
>   EFI_ENTRY("%p", buffer);
> - r = efi_free_pages((ulong)buffer, 0);
> +
> + buffer = (char *)(buffer) - 8;

Please add a sanity assert here that verifies that (ulong)buffer &
EFI_PAGE_MASK == 8.


Alex

> + num_pages = *(u64 *)buffer;
> +
> + r = efi_free_pages((ulong)buffer, num_pages);
>   return EFI_EXIT(r);
>  }
>  
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] efi_loader: Fix memory map size check to avoid out-of-bounds access

[Alexander Graf]

On 30.09.16 02:03, Stefan Brüns wrote:
> memory_map_size as IN parameter specifies the size of the provided buffer.
> If the buffer is to small, memory_map_size is updated to indicate the
> required size, and an error code is returned.
> 
> Signed-off-by: Stefan Brüns 

This patch doesn't actually change anything, does it?


Alex

> ---
>  lib/efi_loader/efi_memory.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_memory.c b/lib/efi_loader/efi_memory.c
> index ebe8e94..5d71fdf 100644
> --- a/lib/efi_loader/efi_memory.c
> +++ b/lib/efi_loader/efi_memory.c
> @@ -342,16 +342,18 @@ efi_status_t efi_get_memory_map(unsigned long 
> *memory_map_size,
>  
>   map_size = map_entries * sizeof(struct efi_mem_desc);
>  
> - *memory_map_size = map_size;
> -
>   if (descriptor_size)
>   *descriptor_size = sizeof(struct efi_mem_desc);
>  
>   if (descriptor_version)
>   *descriptor_version = EFI_MEMORY_DESCRIPTOR_VERSION;
>  
> - if (*memory_map_size < map_size)
> + if (*memory_map_size < map_size) {
> + *memory_map_size = map_size;
>   return EFI_BUFFER_TOO_SMALL;
> + }
> +
> + *memory_map_size = map_size;
>  
>   /* Copy list into array */
>   if (memory_map) {
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sunxi: Fix H3 DRAM impedance calibration on rev. A chips

[Jagan Teki]

On Wed, Sep 21, 2016 at 11:38 PM, Jens Kuske  wrote:
> H3 seems to have a silicon bug breaking the impedance calibration.
> This is currently worked around in software by multiple steps
> combining the results to replace the wrong values.
>
> Revision A chips need a different workaround, which is present in
> the vendor bootloader too, but got overlooked in lack of
> information and affected boards till now.
> This commit adds a simplified version without correction factor,
> which would be 1.00 for all known boards anyway.
>
> Signed-off-by: Jens Kuske 
> ---
>
> Hi,
>
> This has been tested by an Armbian user:
> http://forum.armbian.com/index.php/topic/872-beelink-x2-with-armbian-possible/?p=16061
>
> It looks like only few boards have revision A chips, probably only
> non-development boards, otherwise we would have found this earlier.
> The idea that these are different chip revision is based on:
> https://github.com/igorpecovnik/linux/blob/sun8i/arch/arm/mach-sunxi/sunxi-chip.c#L341
>
> Regards,
> Jens
>
> ---
>  arch/arm/mach-sunxi/dram_sun8i_h3.c | 64 
> +
>  1 file changed, 43 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm/mach-sunxi/dram_sun8i_h3.c 
> b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> index 2020d75..b08b8e6 100644
> --- a/arch/arm/mach-sunxi/dram_sun8i_h3.c
> +++ b/arch/arm/mach-sunxi/dram_sun8i_h3.c
> @@ -217,35 +217,57 @@ static void mctl_zq_calibration(struct dram_para *para)
> struct sunxi_mctl_ctl_reg * const mctl_ctl =
> (struct sunxi_mctl_ctl_reg *)SUNXI_DRAM_CTL0_BASE;
>
> -   int i;
> -   u16 zq_val[6];
> -   u8 val;
> +   if ((readl(SUNXI_SRAMC_BASE + 0x24) & 0xff) == 0 &&
> +   (readl(SUNXI_SRAMC_BASE + 0xf0) & 0x1) == 0) {

I think we can unlock before reading the sram version, do you think
so? and lock same after.

> +   u32 reg_val;
>
> -   writel(0x0a0a0a0a, _ctl->zqdr[2]);
> -
> -   for (i = 0; i < 6; i++) {
> -   u8 zq = (CONFIG_DRAM_ZQ >> (i * 4)) & 0xf;
> -
> -   writel((zq << 20) | (zq << 16) | (zq << 12) |
> -   (zq << 8) | (zq << 4) | (zq << 0),
> -   _ctl->zqcr);
> +   clrsetbits_le32(_ctl->zqcr, 0x,
> +   CONFIG_DRAM_ZQ & 0x);
>
> writel(PIR_CLRSR, _ctl->pir);
> mctl_phy_init(PIR_ZCAL);
>
> -   zq_val[i] = readl(_ctl->zqdr[0]) & 0xff;
> -   writel(REPEAT_BYTE(zq_val[i]), _ctl->zqdr[2]);
> +   reg_val = readl(_ctl->zqdr[0]);
> +   reg_val &= (0x1f << 16) | (0x1f << 0);
> +   reg_val |= reg_val << 8;
> +   writel(reg_val, _ctl->zqdr[0]);
>
> -   writel(PIR_CLRSR, _ctl->pir);
> -   mctl_phy_init(PIR_ZCAL);
> +   reg_val = readl(_ctl->zqdr[1]);
> +   reg_val &= (0x1f << 16) | (0x1f << 0);
> +   reg_val |= reg_val << 8;
> +   writel(reg_val, _ctl->zqdr[1]);
> +   writel(reg_val, _ctl->zqdr[2]);

Was this write call for zqdr[2] true?

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/6] apalis/colibri_t30: move environment location

[Marcel Ziswiler]

On Wed, 2016-09-28 at 12:11 -0600, Stephen Warren wrote:
> On 09/28/2016 03:35 AM, Marcel Ziswiler wrote:
> > 
> > Now with the config block handling in place move the U-Boot
> > environment
> > location before the config block at the end of 1st "boot sector" as
> > deployed during production using our downstream BSP.
> > 
> > diff --git a/include/configs/apalis_t30.h
> > b/include/configs/apalis_t30.h
> > 
> > -/* Environment in eMMC, at the end of 2nd "boot sector" */
> > +/* Environment in eMMC, before config block at the end of 1st
> > "boot sector" */
> >  #define CONFIG_ENV_IS_IN_MMC
> > -#define CONFIG_ENV_OFFSET  (-CONFIG_ENV_SIZE)
> > +#define CONFIG_ENV_OFFSET  (-CONFIG_ENV_SIZE + \
> > +    CONFIG_TDX_CFG_BLOCK_OFFS
> > ET)
> I'm not convinced that ENV_OFFSET actually points where the
> description 
> says it does. (-CONFIG_ENV_SIZE + CONFIG_TDX_CFG_BLOCK_OFFSET) is (-
> 8192 
> + -512). The original comment states that an ENV_OFFSET of -8192
> locates 
> the environment at the end of a sector, so shifting it 512 bytes
> earlier 
> in the flash can't possible now align it with a different sector? 

Why not?

> Should 
> ENV_OFFSET be shifted down by a whole sector size by this patch,
> i.e. 
> should +CONFIG_TXT_CFG_BLOCK_OFFSET be rounded up to a sector size
> to 
> match the comment?

Yes, a block, sector or whatever you wana call it is actually 512 bytes
in size on all eMMCs or even MMC/SD cards that I have seen so far.

I guess while it would be kind of nice having this enforced to some
intrinsic size in software ultimately this is a board configuration
option concerning our Toradex factory configuration block as programmed
during production. We just want to make sure that one is preserved and
the environment is stored right before.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] imx7 u-boot nand update from u-boot

[Belisko Marek]

Hi Jagan,

On Thu, Sep 29, 2016 at 1:23 PM, Jagan Teki  wrote:
> On Thu, Aug 4, 2016 at 11:52 AM, Belisko Marek  
> wrote:
>> Hi,
>>
>> I'm trying to figure out how it is possible easily update u-boot in
>> nand on custom imx7 board. I can start u-boot using imx_usb tool. I
>> came from ti am33xx world where I simply get u-boot.img from tftp
>> server and store it to beginning of flash (after SPL offset).
>>
>> According imx7 datasheet for nand boot it is necessary to store FCB +
>> DBBT and other things. It is currently possible only with userspace
>> tool kobs-ng which can save u-boot to nand memory. It is possible to
>> generate such image (with FCB, ...) to be able to update u-boot from
>> u-boot by tftp and some nand write? Or it is enough to just write
>> u-boot.imx to offset 0x400 when u-boot was writen before by kobs-ng
>> and it will work? Many thanks for replies.
>
> Try this patch[1] for nand bootupdate look fine for me.
Thanks a lot. I'll look on it. Cheers.
>
> U-Boot> tftp ${loadaddr} SPL
> U-Boot> nand bootupdate ${loadaddr} ${filesize}
>
> U-Boot> nand erase 0x20 0x10
> U-Boot> tftp ${loadaddr} u-boot.img
> U-Boot> nand write ${loadaddr} 0x20 ${filesize}
>
> [1] https://patchwork.ozlabs.org/patch/637573/
>
> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.


BR,

marek
-- 
as simple and primitive as possible
-
Marek Belisko - OPEN-NANDRA
Freelance Developer

Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
Tel: +421 915 052 184
skype: marekwhite
twitter: #opennandra
web: http://open-nandra.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mmc: sdhci: Add the programmable clock mode support

[Jaehoon Chung]

Hi Kever,

On 09/30/2016 07:05 PM, Kever Yang wrote:
> Hi Wenyou,
> 
> I can not enable my emmc device  on my evb-rk3399 with this patch, could 
> you help to fix it?
> 
> Here is the debug info may help:
> 
> mmc->cfg->f_max is 2;
> 
> [with this patch]
> I get host->clk_mul 16 ;
> When driver want to set clock to 40, always get div 1024, and then write 
> 0x21 to SDHCI_CLOCK_CONTROL register,
> mmc controller can not work because of the wrong clock rate;
> 
> [without this patch]
> we don't use host->clk_mul;
> When driver want to set clock to 40, get div 250, and then write 0xfa01 
> to SDHCI_CLOCK_CONTROL register,
> mmc controller works OK.

If you don't use host->clk_mul, then your host controller is the lower version 
than V3.0..?

host->clk_mul is assigned to dummy value? Could you check this?

When i have checked Whenyou's patch, there is only difference about 
"host->clk_mul".

Best Regards,
Jaehoon Chung

> 
> Thanks,
> - Kever
> On 09/18/2016 09:01 AM, Wenyou Yang wrote:
>> Add the programmable clock mode for the clock generator.
>>
>> Signed-off-by: Wenyou Yang 
>> ---
>>
>> Changes in v2:
>>   - Rebase on the latest u-boot-mmc.
>>   - Fix the typo Muliplier->Multiplier.
>>
>>   drivers/mmc/sdhci.c | 50 --
>>   include/sdhci.h |  2 ++
>>   2 files changed, 42 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
>> index 504f2d2..b2bf5a0 100644
>> --- a/drivers/mmc/sdhci.c
>> +++ b/drivers/mmc/sdhci.c
>> @@ -294,7 +294,7 @@ static int sdhci_send_command(struct mmc *mmc, struct 
>> mmc_cmd *cmd,
>>   static int sdhci_set_clock(struct mmc *mmc, unsigned int clock)
>>   {
>>   struct sdhci_host *host = mmc->priv;
>> -unsigned int div, clk, timeout, reg;
>> +unsigned int div, clk = 0, timeout, reg;
>> /* Wait max 20 ms */
>>   timeout = 200;
>> @@ -318,14 +318,36 @@ static int sdhci_set_clock(struct mmc *mmc, unsigned 
>> int clock)
>>   return 0;
>> if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_300) {
>> -/* Version 3.00 divisors must be a multiple of 2. */
>> -if (mmc->cfg->f_max <= clock)
>> -div = 1;
>> -else {
>> -for (div = 2; div < SDHCI_MAX_DIV_SPEC_300; div += 2) {
>> -if ((mmc->cfg->f_max / div) <= clock)
>> +/*
>> + * Check if the Host Controller supports Programmable Clock
>> + * Mode.
>> + */
>> +if (host->clk_mul) {
>> +for (div = 1; div <= 1024; div++) {
>> +if ((mmc->cfg->f_max * host->clk_mul / div)
>> +<= clock)
>>   break;
>>   }
>> +
>> +/*
>> + * Set Programmable Clock Mode in the Clock
>> + * Control register.
>> + */
>> +clk = SDHCI_PROG_CLOCK_MODE;
>> +div--;
>> +} else {
>> +/* Version 3.00 divisors must be a multiple of 2. */
>> +if (mmc->cfg->f_max <= clock) {
>> +div = 1;
>> +} else {
>> +for (div = 2;
>> + div < SDHCI_MAX_DIV_SPEC_300;
>> + div += 2) {
>> +if ((mmc->cfg->f_max / div) <= clock)
>> +break;
>> +}
>> +}
>> +div >>= 1;
>>   }
>>   } else {
>>   /* Version 2.00 divisors must be a power of 2. */
>> @@ -333,13 +355,13 @@ static int sdhci_set_clock(struct mmc *mmc, unsigned 
>> int clock)
>>   if ((mmc->cfg->f_max / div) <= clock)
>>   break;
>>   }
>> +div >>= 1;
>>   }
>> -div >>= 1;
>> if (host->set_clock)
>>   host->set_clock(host->index, div);
>>   -clk = (div & SDHCI_DIV_MASK) << SDHCI_DIVIDER_SHIFT;
>> +clk |= (div & SDHCI_DIV_MASK) << SDHCI_DIVIDER_SHIFT;
>>   clk |= ((div & SDHCI_DIV_HI_MASK) >> SDHCI_DIV_MASK_LEN)
>>   << SDHCI_DIVIDER_HI_SHIFT;
>>   clk |= SDHCI_CLOCK_INT_EN;
>> @@ -513,7 +535,7 @@ static const struct mmc_ops sdhci_ops = {
>>   int sdhci_setup_cfg(struct mmc_config *cfg, struct sdhci_host *host,
>>   u32 max_clk, u32 min_clk)
>>   {
>> -u32 caps;
>> +u32 caps, caps_1;
>> caps = sdhci_readl(host, SDHCI_CAPABILITIES);
>>   @@ -577,6 +599,14 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct 
>> sdhci_host *host,
>> cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
>>   +/*
>> + * In case of Host Controller v3.00, find out whether clock
>> + * multiplier is supported.
>> + */
>> +caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
>> +host->clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >>
>> +SDHCI_CLOCK_MUL_SHIFT;
>> +
>>   return 0;
>>   }
>>   diff --git a/include/sdhci.h b/include/sdhci.h
>> index 6844c73..144570f 100644
>> --- a/include/sdhci.h
>> 

Re: [U-Boot] [PATCH] serial: ns16550: Fix serial output on Tegra186

[Thierry Reding]

On Fri, Sep 30, 2016 at 10:47:38AM +0100, Paul Burton wrote:
> On Friday, 30 September 2016 17:53:38 BST Alexandre Courbot wrote:
> > On 09/30/2016 05:46 PM, Thierry Reding wrote:
> > > From: Thierry Reding 
> > > 
> > > For Tegra186 there are currently no UART clocks wired up in device tree.
> > > This exposes a regression introduced in commit 50fce1d5d874 ("serial:
> > > ns16550: Support clocks via phandle"), which causes the p2771--500
> > > board (and probably any Tegra186-based board as well) to fail to boot.
> > > 
> > > The reason is that if no clocks property exists, then clk_get_by_index()
> > > returns -ENOENT (via fdtdec_parse_phandle_with_args()) rather than
> > > -ENODEV as the above-mentioned commit expects.
> > > 
> > > Fix this by checking for the right error code.
> > 
> > Tested-by: Alexandre Courbot 
> > 
> > I sent a similar patch ~10 minutes before this one, but Thierry's commit
> > message is clearer than mine (and his handling of -ENODEV probably more
> > correct as well), so let's go with this version!
> 
> 
> Hi Thierry & Alexandre,
> 
> Apologies for the breakage!
> 
> If a DT contains a clock & the UART node references it by phandle then I 
> believe clk_get_by_index() could return -ENODEV via 
> uclass_get_device_by_of_offset & uclass_find_device_by_of_offset. So we 
> probably need to handle both -ENOENT for the "no clocks property" case & -
> ENODEV for the "clocks property but no driver" case, as Alexandre's patch 
> does?

Indeed. I thought I had checked all possible return values, but I've
obviously been blind. Alex's patch looks more correct, though I'm
beginning to wonder if there's a better way to achieve this than keep
adding whatever error codes happen to be special cases.

How about we just leave out the else completely? At this point it seems
like any failure to obtain a valid clock would best be dealt with by
falling back to clock-frequency or the one specified in the config.

Are there even other errors besides -ENODEV, -ENOENT and -ENOSYS that we
could get here?

Thierry


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

Re: [U-Boot] [PATCH v2] mmc: sdhci: Add the programmable clock mode support

[Kever Yang]

Hi Wenyou,

I can not enable my emmc device  on my evb-rk3399 with this patch, 
could you help to fix it?


Here is the debug info may help:

mmc->cfg->f_max is 2;

[with this patch]
I get host->clk_mul 16 ;
When driver want to set clock to 40, always get div 1024, and then 
write 0x21 to SDHCI_CLOCK_CONTROL register,

mmc controller can not work because of the wrong clock rate;

[without this patch]
we don't use host->clk_mul;
When driver want to set clock to 40, get div 250, and then write 
0xfa01 to SDHCI_CLOCK_CONTROL register,

mmc controller works OK.

Thanks,
- Kever
On 09/18/2016 09:01 AM, Wenyou Yang wrote:

Add the programmable clock mode for the clock generator.

Signed-off-by: Wenyou Yang 
---

Changes in v2:
  - Rebase on the latest u-boot-mmc.
  - Fix the typo Muliplier->Multiplier.

  drivers/mmc/sdhci.c | 50 --
  include/sdhci.h |  2 ++
  2 files changed, 42 insertions(+), 10 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index 504f2d2..b2bf5a0 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -294,7 +294,7 @@ static int sdhci_send_command(struct mmc *mmc, struct 
mmc_cmd *cmd,
  static int sdhci_set_clock(struct mmc *mmc, unsigned int clock)
  {
struct sdhci_host *host = mmc->priv;
-   unsigned int div, clk, timeout, reg;
+   unsigned int div, clk = 0, timeout, reg;
  
  	/* Wait max 20 ms */

timeout = 200;
@@ -318,14 +318,36 @@ static int sdhci_set_clock(struct mmc *mmc, unsigned int 
clock)
return 0;
  
  	if (SDHCI_GET_VERSION(host) >= SDHCI_SPEC_300) {

-   /* Version 3.00 divisors must be a multiple of 2. */
-   if (mmc->cfg->f_max <= clock)
-   div = 1;
-   else {
-   for (div = 2; div < SDHCI_MAX_DIV_SPEC_300; div += 2) {
-   if ((mmc->cfg->f_max / div) <= clock)
+   /*
+* Check if the Host Controller supports Programmable Clock
+* Mode.
+*/
+   if (host->clk_mul) {
+   for (div = 1; div <= 1024; div++) {
+   if ((mmc->cfg->f_max * host->clk_mul / div)
+   <= clock)
break;
}
+
+   /*
+* Set Programmable Clock Mode in the Clock
+* Control register.
+*/
+   clk = SDHCI_PROG_CLOCK_MODE;
+   div--;
+   } else {
+   /* Version 3.00 divisors must be a multiple of 2. */
+   if (mmc->cfg->f_max <= clock) {
+   div = 1;
+   } else {
+   for (div = 2;
+div < SDHCI_MAX_DIV_SPEC_300;
+div += 2) {
+   if ((mmc->cfg->f_max / div) <= clock)
+   break;
+   }
+   }
+   div >>= 1;
}
} else {
/* Version 2.00 divisors must be a power of 2. */
@@ -333,13 +355,13 @@ static int sdhci_set_clock(struct mmc *mmc, unsigned int 
clock)
if ((mmc->cfg->f_max / div) <= clock)
break;
}
+   div >>= 1;
}
-   div >>= 1;
  
  	if (host->set_clock)

host->set_clock(host->index, div);
  
-	clk = (div & SDHCI_DIV_MASK) << SDHCI_DIVIDER_SHIFT;

+   clk |= (div & SDHCI_DIV_MASK) << SDHCI_DIVIDER_SHIFT;
clk |= ((div & SDHCI_DIV_HI_MASK) >> SDHCI_DIV_MASK_LEN)
<< SDHCI_DIVIDER_HI_SHIFT;
clk |= SDHCI_CLOCK_INT_EN;
@@ -513,7 +535,7 @@ static const struct mmc_ops sdhci_ops = {
  int sdhci_setup_cfg(struct mmc_config *cfg, struct sdhci_host *host,
u32 max_clk, u32 min_clk)
  {
-   u32 caps;
+   u32 caps, caps_1;
  
  	caps = sdhci_readl(host, SDHCI_CAPABILITIES);
  
@@ -577,6 +599,14 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct sdhci_host *host,
  
  	cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
  
+	/*

+* In case of Host Controller v3.00, find out whether clock
+* multiplier is supported.
+*/
+   caps_1 = sdhci_readl(host, SDHCI_CAPABILITIES_1);
+   host->clk_mul = (caps_1 & SDHCI_CLOCK_MUL_MASK) >>
+   SDHCI_CLOCK_MUL_SHIFT;
+
return 0;
  }
  
diff --git a/include/sdhci.h b/include/sdhci.h

index 6844c73..144570f 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -97,6 +97,7 @@
  #define  SDHCI_DIV_MASK   0xFF
  #define  SDHCI_DIV_MASK_LEN   8
  #define  SDHCI_DIV_HI_MASK0x300

Re: [U-Boot] [PATCH] serial: ns16550: Fix serial output on Tegra186

[Alexandre Courbot]

Hi Paul,

On 09/30/2016 06:47 PM, Paul Burton wrote:
> * PGP Signed by an unknown key
> 
> On Friday, 30 September 2016 17:53:38 BST Alexandre Courbot wrote:
>> On 09/30/2016 05:46 PM, Thierry Reding wrote:
>>> From: Thierry Reding 
>>>
>>> For Tegra186 there are currently no UART clocks wired up in device tree.
>>> This exposes a regression introduced in commit 50fce1d5d874 ("serial:
>>> ns16550: Support clocks via phandle"), which causes the p2771--500
>>> board (and probably any Tegra186-based board as well) to fail to boot.
>>>
>>> The reason is that if no clocks property exists, then clk_get_by_index()
>>> returns -ENOENT (via fdtdec_parse_phandle_with_args()) rather than
>>> -ENODEV as the above-mentioned commit expects.
>>>
>>> Fix this by checking for the right error code.
>>
>> Tested-by: Alexandre Courbot 
>>
>> I sent a similar patch ~10 minutes before this one, but Thierry's commit
>> message is clearer than mine (and his handling of -ENODEV probably more
>> correct as well), so let's go with this version!
> 
> 
> Hi Thierry & Alexandre,
> 
> Apologies for the breakage!
> 
> If a DT contains a clock & the UART node references it by phandle then I 
> believe clk_get_by_index() could return -ENODEV via 
> uclass_get_device_by_of_offset & uclass_find_device_by_of_offset. So we 
> probably need to handle both -ENOENT for the "no clocks property" case & -
> ENODEV for the "clocks property but no driver" case, as Alexandre's patch 
> does?

But if a DT contains a clock, shouldn't it simply take precedence over
the legacy method? (not very familiar with this code so my comment may
not make sense).

IOW, do we have a case where clk_get_by_index() returns -ENODEV and
fdtdec_get_int() returns a valid clock?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] serial: ns16550: Fix serial output on Tegra186

[Paul Burton]

On Friday, 30 September 2016 17:53:38 BST Alexandre Courbot wrote:
> On 09/30/2016 05:46 PM, Thierry Reding wrote:
> > From: Thierry Reding 
> > 
> > For Tegra186 there are currently no UART clocks wired up in device tree.
> > This exposes a regression introduced in commit 50fce1d5d874 ("serial:
> > ns16550: Support clocks via phandle"), which causes the p2771--500
> > board (and probably any Tegra186-based board as well) to fail to boot.
> > 
> > The reason is that if no clocks property exists, then clk_get_by_index()
> > returns -ENOENT (via fdtdec_parse_phandle_with_args()) rather than
> > -ENODEV as the above-mentioned commit expects.
> > 
> > Fix this by checking for the right error code.
> 
> Tested-by: Alexandre Courbot 
> 
> I sent a similar patch ~10 minutes before this one, but Thierry's commit
> message is clearer than mine (and his handling of -ENODEV probably more
> correct as well), so let's go with this version!


Hi Thierry & Alexandre,

Apologies for the breakage!

If a DT contains a clock & the UART node references it by phandle then I 
believe clk_get_by_index() could return -ENODEV via 
uclass_get_device_by_of_offset & uclass_find_device_by_of_offset. So we 
probably need to handle both -ENOENT for the "no clocks property" case & -
ENODEV for the "clocks property but no driver" case, as Alexandre's patch 
does?

Thanks,
Paul

signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] serial: ns16550: Fix serial output on Tegra186

[Alexandre Courbot]

On 09/30/2016 05:46 PM, Thierry Reding wrote:
> From: Thierry Reding 
> 
> For Tegra186 there are currently no UART clocks wired up in device tree.
> This exposes a regression introduced in commit 50fce1d5d874 ("serial:
> ns16550: Support clocks via phandle"), which causes the p2771--500
> board (and probably any Tegra186-based board as well) to fail to boot.
> 
> The reason is that if no clocks property exists, then clk_get_by_index()
> returns -ENOENT (via fdtdec_parse_phandle_with_args()) rather than
> -ENODEV as the above-mentioned commit expects.
> 
> Fix this by checking for the right error code.

Tested-by: Alexandre Courbot 

I sent a similar patch ~10 minutes before this one, but Thierry's commit
message is clearer than mine (and his handling of -ENODEV probably more
correct as well), so let's go with this version!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] serial: ns16550: Handle -ENOENT when requesting clock

[Alexandre Courbot]

On 09/30/2016 05:37 PM, Alexandre Courbot wrote:
> When calling clk_get_by_index(), fall back to the legacy method of
> getting the clock if -ENOENT is returned.

Withdrawing this patch as Thierry sent a better version of it.

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

[U-Boot] [PATCH] ARM:dts: Added device tree for socfpga arria10 development kit sdmmc

[Tien Fong Chee]

This is initial version of device tree for the Intel socfpga arria10
development kit with sdmmc.

Signed-off-by: Tien Fong Chee 
Cc: Marek Vasut 
Cc: Stefan Roese 
Cc: Dinh Nguyen 
Cc: Chin Liang See 
Cc: Tien Fong 
---
 arch/arm/dts/socfpga_arria10.dtsi   |  866 +++
 arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi |  457 
 arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts|   30 +
 3 files changed, 1353 insertions(+), 0 deletions(-)
 create mode 100755 arch/arm/dts/socfpga_arria10.dtsi
 create mode 100755 arch/arm/dts/socfpga_arria10_handoff_sdmmc.dtsi
 create mode 100755 arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts

diff --git a/arch/arm/dts/socfpga_arria10.dtsi 
b/arch/arm/dts/socfpga_arria10.dtsi
new file mode 100755
index 000..8ed5ff4
--- /dev/null
+++ b/arch/arm/dts/socfpga_arria10.dtsi
@@ -0,0 +1,866 @@
+/*
+ * Copyright (C) 2016 Intel Corporation
+ *
+ * SPDX-License-Identifier:GPL-2.0
+ */
+
+#include "skeleton.dtsi"
+#include 
+#include 
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   aliases {
+   ethernet0 = 
+   ethernet1 = 
+   ethernet2 = 
+   serial0 = 
+   serial1 = 
+   timer0 = 
+   timer1 = 
+   timer2 = 
+   timer3 = 
+   spi0 = 
+   spi1 = 
+   };
+
+   memory {
+   name = "memory";
+   device_type = "memory";
+   reg = <0x0 0x4000>; /* 1GB */
+   };
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   compatible = "arm,cortex-a9";
+   device_type = "cpu";
+   reg = <0>;
+   next-level-cache = <>;
+   };
+   cpu@1 {
+   compatible = "arm,cortex-a9";
+   device_type = "cpu";
+   reg = <1>;
+   next-level-cache = <>;
+   };
+   };
+
+   intc: intc@d000 {
+   compatible = "arm,cortex-a9-gic";
+   #interrupt-cells = <3>;
+   interrupt-controller;
+   reg = <0xd000 0x1000>,
+ <0xc100 0x100>;
+   };
+
+   soc {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "simple-bus";
+   device_type = "soc";
+   interrupt-parent = <>;
+   ranges;
+
+   amba {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   pdma: pdma@ffda1000 {
+   compatible = "arm,pl330", "arm,primecell";
+   reg = <0xffda1000 0x1000>;
+   interrupts = <0 83 IRQ_TYPE_LEVEL_HIGH>,
+<0 84 IRQ_TYPE_LEVEL_HIGH>,
+<0 85 IRQ_TYPE_LEVEL_HIGH>,
+<0 86 IRQ_TYPE_LEVEL_HIGH>,
+<0 87 IRQ_TYPE_LEVEL_HIGH>,
+<0 88 IRQ_TYPE_LEVEL_HIGH>,
+<0 89 IRQ_TYPE_LEVEL_HIGH>,
+<0 90 IRQ_TYPE_LEVEL_HIGH>,
+<0 91 IRQ_TYPE_LEVEL_HIGH>;
+   #dma-cells = <1>;
+   #dma-channels = <8>;
+   #dma-requests = <32>;
+   clocks = <_main_clk>;
+   clock-names = "apb_pclk";
+   };
+   };
+
+   base_fpga_region {
+   compatible = "fpga-region";
+   fpga-mgr = <_mgr>;
+
+   #address-cells = <0x1>;
+   #size-cells = <0x1>;
+   };
+
+   clkmgr@ffd04000 {
+   compatible = "intc,clk-mgr";
+   reg = <0xffd04000 0x1000>;
+   reg-names = "soc_clock_manager_OCP_SLV";
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cb_intosc_hs_div2_clk: 
cb_intosc_hs_div2_clk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   };
+
+ 

[U-Boot] [PATCH] serial: ns16550: Fix serial output on Tegra186

[Thierry Reding]

From: Thierry Reding 

For Tegra186 there are currently no UART clocks wired up in device tree.
This exposes a regression introduced in commit 50fce1d5d874 ("serial:
ns16550: Support clocks via phandle"), which causes the p2771--500
board (and probably any Tegra186-based board as well) to fail to boot.

The reason is that if no clocks property exists, then clk_get_by_index()
returns -ENOENT (via fdtdec_parse_phandle_with_args()) rather than
-ENODEV as the above-mentioned commit expects.

Fix this by checking for the right error code.

Reported-by: Alexandre Courbot 
Signed-off-by: Thierry Reding 
---
 drivers/serial/ns16550.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 765499dab646..9c36dbe2a566 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -408,7 +408,7 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
err = clk_get_rate();
if (!IS_ERR_VALUE(err))
plat->clock = err;
-   } else if (err != -ENODEV && err != -ENOSYS) {
+   } else if (err != -ENOENT && err != -ENOSYS) {
debug("ns16550 failed to get clock\n");
return err;
}
-- 
2.10.0

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

[U-Boot] [PATCH] serial: ns16550: Handle -ENOENT when requesting clock

[Alexandre Courbot]

When calling clk_get_by_index(), fall back to the legacy method of
getting the clock if -ENOENT is returned.

Signed-off-by: Alexandre Courbot 
---
 drivers/serial/ns16550.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
index 765499dab646..29d547166b90 100644
--- a/drivers/serial/ns16550.c
+++ b/drivers/serial/ns16550.c
@@ -408,7 +408,7 @@ int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
err = clk_get_rate();
if (!IS_ERR_VALUE(err))
plat->clock = err;
-   } else if (err != -ENODEV && err != -ENOSYS) {
+   } else if (err != -ENOENT && err != -ENODEV && err != -ENOSYS) {
debug("ns16550 failed to get clock\n");
return err;
}
-- 
2.10.0

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

[U-Boot] [PATCH v2] x86: Fix Linux v4.7+ zimage booting (update bootparam.h)

[Stefan Roese]

Booting Linux kernel v4.7+ does not work since commit Linux commit 974f221c
"x86/boot: Move compressed kernel to the end of the decompression buffer".

This patch adds the latest version of the setup_header struct, adding
"init_size" which is needed since this commit referenced above. With this
patch, booting Linux v4.8-rc8 does work again on x86 boards.

Signed-off-by: Stefan Roese 
Reviewed-by: Simon Glass 
Reviewed-by: Bin Meng 
Tested-by: Bin Meng 
---
v2:
- Specified that the refereced git commit is a Linux commit as
  suggested by Bin
  
 arch/x86/include/asm/bootparam.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/include/asm/bootparam.h b/arch/x86/include/asm/bootparam.h
index 1400951..a373a79 100644
--- a/arch/x86/include/asm/bootparam.h
+++ b/arch/x86/include/asm/bootparam.h
@@ -63,6 +63,9 @@ struct setup_header {
__u32   payload_offset;
__u32   payload_length;
__u64   setup_data;
+   __u64   pref_address;
+   __u32   init_size;
+   __u32   handover_offset;
 } __attribute__((packed));
 
 struct sys_desc_table {
-- 
2.9.3

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

Re: [U-Boot] [PATCH] x86: Fix Linux v4.7+ zimage booting (update bootparam.h)

[Bin Meng]

Hi Stefan,

Well done!

On Thu, Sep 29, 2016 at 5:34 PM, Stefan Roese  wrote:
> Booting Linux kernel v4.7+ does not work since commit 974f221c

Please specify this is Linux kernel commit.

> "x86/boot: Move compressed kernel to the end of the decompression buffer".
>
> This patch adds the latest version of the setup_header struct, adding
> "init_size" which is needed since this commit referenced above. With this
> patch, booting Linux v4.8-rc8 does work again on x86 boards.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> Cc: Bin Meng 
> ---
>  arch/x86/include/asm/bootparam.h | 3 +++
>  1 file changed, 3 insertions(+)
>

Reviewed-by: Bin Meng 

Tested on Crown Bay
Tested-by: Bin Meng 

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

Re: [U-Boot] [PATCH v5 00/21] imx6: Add Engicam i.CoreM6 QDL support

[Jagan Teki]

Hi Stefano,

On Wed, Sep 28, 2016 at 11:57 PM, Jagan Teki  wrote:
> From: Jagan Teki 
>
> This series supports Engicam i.CoreM6 QDL modules on top of 
> u-boot-imx.git/next
> and test on the respective starter kits as well.
>
> Tested both MMC and NAND boot.
>
> Changes for v5:
> - Add NAND support
>
> Changes for v4:
> - Add 'net: Kconfig: Add FEC_MXC entry' patch
> - Updated ENV configs along with comments
> - Restructured configs for more readability
> - Add CONFIG_ENV_OVERWRITE
> - Rename icorem6qdl_defconfig with icorem6qdl_mmc_defconfig
>
> Changes for v3:
> - Remove "v2 01/17 imx: iomux-v3: Fix build error with snvs base" 
> patch
> - Remove 'default n' on Kconfig DEFAULT_FDT_FILE patch
> - Add minimal devicetree support for Engicam i.CoreM6 QDL
> - Add is_mx6dl()
> - Add is_mx6solo()
> - Use is_mx6dq()
> - Add last commit sha1 and header in pull devicetree files from Linux
>
> Changes for v2:
> - Make static to local iomux structure in board file
> - Corrected rowaddr in mx6_ddr3_cfg
> - Used imx_ddr_size
> - Add FEC support and tested the same
> - Add DM_GPIO, DM_MMC support
> - Add pinctrl support
> - Add devicetree support
>
> Jagan Teki (21):
>   serial: Kconfig: Add MXC_UART entry
>   thermal: Kconfig: Add IMX_THERMAL entry
>   Kconfig: Add DEFAULT_FDT_FILE entry
>   arm: imx: Add Engicam i.CoreM6 QDL Starter Kit initial support
>   net: Kconfig: Add FEC_MXC entry
>   imx6: icorem6: Add ENET support
>   imx: s/docs\/README.imximage/doc\/README.imximage/g
>   arm: dts: Add devicetree for i.MX6DL
>   arm: dts: Add devicetree for i.MX6DQL
>   arm: dts: imx6dl: Add pinctrl defines
>   dt-bindings: clock: imx6qdl: Add clock defines
>   arm: imx6q: Add devicetree support for Engicam i.CoreM6 DualLite/Solo
>   imx6q: icorem6: Enable pinctrl driver
>   engicam: icorem6: Add DM_GPIO, DM_MMC support
>   arm: dts: Add devicetree for i.MX6Q
>   arm: dts: imx6q: Add pinctrl defines
>   arm: imx6q: Add devicetree support for Engicam i.CoreM6 Quad/Dual
>   mtd: nand: Kconfig: Add NAND_MXS entry
>   imx6: icorem6: Add NAND support
>   imx6: icorem6: Enable MTD device support
>   imx6: icorem6: Add default mtd nand partition table

Can you pick this series.

thanks!
-- 
Jagan Teki
Free Software Engineer | www.openedev.com
U-Boot, Linux | Upstream Maintainer
Hyderabad, India.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] Add support for the topic-miami system-on-modules and carrier boards

[Mike Looijmans]

The topic-miami SoMs contain a Zynq xc7z015 or xc7z030 SoC, 1GB DDR3L RAM,
32MB QSPI NOR flash and 256MB NAND flash.

The topic-miamiplus SoMs contain a Zynq xc7z035, xc7z045 or xc7z100 SoC,
2x 1GB DDR3L RAM, 64MB dual-parallel QSPI flash, clock sources
and a fan controller.

The "Florida" carrier boards add SD, USB, ethernet and other interfaces.

Signed-off-by: Mike Looijmans 
---
Note: Requires these patches:
 mach-zynq/Kconfig: Make SYS_VENDOR configurable
 tools: mkimage: Add support for initialization table for Zynq and ZynqMP

 arch/arm/dts/Makefile  |   2 +
 arch/arm/dts/zynq-topic-miami.dts  |  97 +
 arch/arm/dts/zynq-topic-miamiplus.dts  |  17 ++
 board/topic/zynq/MAINTAINERS   |   6 +
 board/topic/zynq/Makefile  |  10 +
 board/topic/zynq/board.c   |   1 +
 board/topic/zynq/ps7_init_common.c | 117 +++
 board/topic/zynq/ps7_init_gpl.h|  34 +++
 board/topic/zynq/zynq-topic-miami/ps7_init_gpl.c   | 227 
 board/topic/zynq/zynq-topic-miami/ps7_regs.txt |  61 ++
 .../topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c | 233 +
 board/topic/zynq/zynq-topic-miamiplus/ps7_regs.txt |  61 ++
 configs/topic_miami_defconfig  |  48 +
 configs/topic_miamiplus_defconfig  |  48 +
 include/configs/topic_miami.h  | 149 +
 include/configs/topic_miamiplus.h  |   2 +
 16 files changed, 1113 insertions(+)
 create mode 100644 arch/arm/dts/zynq-topic-miami.dts
 create mode 100644 arch/arm/dts/zynq-topic-miamiplus.dts
 create mode 100644 board/topic/zynq/MAINTAINERS
 create mode 100644 board/topic/zynq/Makefile
 create mode 100644 board/topic/zynq/board.c
 create mode 100644 board/topic/zynq/ps7_init_common.c
 create mode 100644 board/topic/zynq/ps7_init_gpl.h
 create mode 100644 board/topic/zynq/zynq-topic-miami/ps7_init_gpl.c
 create mode 100644 board/topic/zynq/zynq-topic-miami/ps7_regs.txt
 create mode 100644 board/topic/zynq/zynq-topic-miamiplus/ps7_init_gpl.c
 create mode 100644 board/topic/zynq/zynq-topic-miamiplus/ps7_regs.txt
 create mode 100644 configs/topic_miami_defconfig
 create mode 100644 configs/topic_miamiplus_defconfig
 create mode 100644 include/configs/topic_miami.h
 create mode 100644 include/configs/topic_miamiplus.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 032c5ae..92bba73 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -97,6 +97,8 @@ dtb-$(CONFIG_ARCH_ZYNQ) += zynq-zc702.dtb \
zynq-zybo.dtb \
zynq-microzed.dtb \
zynq-picozed.dtb \
+   zynq-topic-miami.dtb \
+   zynq-topic-miamiplus.dtb \
zynq-zc770-xm010.dtb \
zynq-zc770-xm011.dtb \
zynq-zc770-xm012.dtb \
diff --git a/arch/arm/dts/zynq-topic-miami.dts 
b/arch/arm/dts/zynq-topic-miami.dts
new file mode 100644
index 000..8e988f9
--- /dev/null
+++ b/arch/arm/dts/zynq-topic-miami.dts
@@ -0,0 +1,97 @@
+/*
+ * Topic Miami board DTS
+ *
+ * Copyright (C) 2014-2016 Topic Embedded Products
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+/dts-v1/;
+#include "zynq-7000.dtsi"
+
+/ {
+   model = "Topic Miami Zynq Board";
+   compatible = "topic,miami", "xlnx,zynq-7000";
+
+   aliases {
+   ethernet0 = 
+   serial0 = 
+   spi0 = 
+   i2c0 = 
+   i2c1 = 
+   mmc0 = 
+   };
+
+   memory {
+   device_type = "memory";
+   reg = <0x0 0x4000>;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   u-boot,dm-pre-reloc;
+   status = "okay";
+   is-dual = <0>;
+   num-cs = <1>;
+   flash@0 {
+   compatible = "st,m25p80", "n25q256a";
+   m25p,fast-read;
+   reg = <0x0>;
+   spi-tx-bus-width = <1>;
+   spi-rx-bus-width = <4>;
+   spi-max-frequency = <1>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   partition@qspi-u-boot-spl {
+   label = "qspi-u-boot-spl";
+   reg = <0x0 0x1>;
+   };
+   partition@qspi-u-boot-img {
+   label = "qspi-u-boot-img";
+   reg = <0x1 0x6>;
+   };
+   partition@qspi-device-tree {
+   label = "qspi-device-tree";
+   reg = <0x7 0x1>;
+   };
+   partition@qspi-linux {
+   label = "qspi-linux";
+   reg = <0x8 0x40>;
+   };
+   partition@qspi-rootfs {
+   label = "qspi-rootfs";
+   reg 

[U-Boot] [[RFC Patch] 2/2] tools: buildman: Add compiler wrapper

[York Sun]

Now we can use compiler wrapper such as ccache or distcc for buildman.

Signed-off-by: York Sun 
CC: Simon Glass 
---
This is not perfect and may need some improvement. Something I didn't figure
out is how to drop the name under [toolchain-wrapper]. I intended to have this
format but bsettings.GetItems doesn't like it.

[toolchain-wrapper]
ccache

It doesn't deal with more than one line for this setting. For now, the last
setting is taken.

 tools/buildman/README   |  9 +
 tools/buildman/toolchain.py | 17 +++--
 2 files changed, 24 insertions(+), 2 deletions(-)

diff --git a/tools/buildman/README b/tools/buildman/README
index 8c5f861..514bebc 100644
--- a/tools/buildman/README
+++ b/tools/buildman/README
@@ -211,6 +211,15 @@ arm: arm-none-eabi-
 
 and buildman will find arm-none-eabi-gcc in /usr/bin if you have it installed.
 
+[toolchain-wrapper]
+wrapper: ccache
+
+This tells buildman to use a compiler wrapper in front of CROSS_COMPILE. In
+this example, ccache. It doesn't affect the toolchain scan. The wrapper is
+added when CROSS_COMPILE environtal variable is set. The name in this
+section is ignored. If more than one line is provided, only the last one
+is taken.
+
 3. Make sure you have the require Python pre-requisites
 
 Buildman uses multiprocessing, Queue, shutil, StringIO, ConfigParser and
diff --git a/tools/buildman/toolchain.py b/tools/buildman/toolchain.py
index 41e4e4c..01cdb03 100644
--- a/tools/buildman/toolchain.py
+++ b/tools/buildman/toolchain.py
@@ -127,6 +127,15 @@ class Toolchain:
 return PRIORITY_CALC + prio
 return PRIORITY_CALC + prio
 
+def GetWrapper(self, show_warning=True):
+"""Get toolchain wrapper from the setting file.
+"""
+   value = ''
+   for name, value in bsettings.GetItems('toolchain-wrapper'):
+if not value:
+print "Warning: Wrapper not found"
+return value
+
 def MakeEnvironment(self, full_path):
 """Returns an environment for using the toolchain.
 
@@ -138,10 +147,14 @@ class Toolchain:
 PATH
 """
 env = dict(os.environ)
+wrapper = self.GetWrapper()
+if wrapper:
+wrapper = wrapper + ' '
+
 if full_path:
-env['CROSS_COMPILE'] = os.path.join(self.path, self.cross)
+env['CROSS_COMPILE'] = wrapper + os.path.join(self.path, 
self.cross)
 else:
-env['CROSS_COMPILE'] = self.cross
+env['CROSS_COMPILE'] = wrapper + self.cross
 env['PATH'] = self.path + ':' + env['PATH']
 
 return env
-- 
2.7.4

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

Re: [U-Boot] [PATCH v3 03/29] Convert CONSOLE_PRE_CONSOLE_BUFFER options to Kconfig

[Siarhei Siamashka]

Hello Simon,

On Thu, 29 Sep 2016 14:23:02 -0600
Simon Glass  wrote:

> Move these option to Kconfig and tidy up existing uses.
> 
> Signed-off-by: Simon Glass 
> ---
> 
> Changes in v3: None
> Changes in v2:
> - Change CONFIG_PRE_CON_BUF_SZ default to 4096
> - Change CONFIG_PRE_CON_BUF_SZ to 'int' type
> - Drop the depend clause on the CONFIG_PRE_CON_BUF_SZ default
> - Move CONFIG_PRE_CON_BUF_ADDR default to common/Kconfig

What is the point moving these defines to Kconfig? They are neither
user configurable, nor board specific. The location of the buffer is
defined per platform or per SoC type and is a part of the global memory
map. Similar to such things as the malloc heap and the stack.

Allowing the users to redefine the buffer location is a dangerous thing
because everything may go out of control very easily (it may overlap
with some other memory buffer). IMHO it only makes sense to have a
single user configurable boolean flag in Kconfig (the one which
enables/disables the pre-console functionality).

Regarding the buffer size. It was originally picked rather arbitrarily
as 1MB at least for the sunxi platform:

https://patchwork.ozlabs.org/patch/426526/

Just because making it several orders of magnitude larger than
necessary makes it extremely unlikely that anyone ever gets into
a buffer wraparound situation. Picking smallish sizes does not gain
us anything, but just adds an extra hassle because now one needs to
make some estimations whether the size is large enough or not.
Especially considering that this functionality may be sometimes
used for debugging prints when troubleshooting something. And one
can't easily predict how much debugging output would be actually
necessary.
 
>  README| 17 
>  board/sunxi/Kconfig   |  3 +++
>  common/Kconfig| 42 
> +++
>  common/console.c  |  6 +++---
>  configs/tbs2910_defconfig |  2 ++
>  include/asm-generic/global_data.h |  2 +-
>  include/configs/sunxi-common.h|  6 --
>  include/configs/tbs2910.h |  4 
>  scripts/config_whitelist.txt  |  3 ---
>  9 files changed, 51 insertions(+), 34 deletions(-)
> 
> diff --git a/README b/README
> index 0a1f3fe..8f93dad 100644
> --- a/README
> +++ b/README
> @@ -872,23 +872,6 @@ The following options need to be configured:
>   must be defined, to setup the maximum idle timeout for
>   the SMC.
>  
> -- Pre-Console Buffer:
> - Prior to the console being initialised (i.e. serial UART
> - initialised etc) all console output is silently discarded.
> - Defining CONFIG_PRE_CONSOLE_BUFFER will cause U-Boot to
> - buffer any console messages prior to the console being
> - initialised to a buffer of size CONFIG_PRE_CON_BUF_SZ
> - bytes located at CONFIG_PRE_CON_BUF_ADDR. The buffer is
> - a circular buffer, so if more than CONFIG_PRE_CON_BUF_SZ
> - bytes are output before the console is initialised, the
> - earlier bytes are discarded.
> -
> - Note that when printing the buffer a copy is made on the
> - stack so CONFIG_PRE_CON_BUF_SZ must fit on the stack.
> -
> - 'Sane' compilers will generate smaller code if
> - CONFIG_PRE_CON_BUF_SZ is a power of 2
> -
>  - Autoboot Command:
>   CONFIG_BOOTCOMMAND
>   Only needed when CONFIG_BOOTDELAY is enabled;
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index b139d1c..c0ffeb3 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -3,6 +3,9 @@ if ARCH_SUNXI
>  config IDENT_STRING
>   default " Allwinner Technology"
>  
> +config PRE_CONSOLE_BUFFER
> + default y
> +
>  config SPL_GPIO_SUPPORT
>   default y
>  
> diff --git a/common/Kconfig b/common/Kconfig
> index bbd5633..6ee67ac 100644
> --- a/common/Kconfig
> +++ b/common/Kconfig
> @@ -246,6 +246,48 @@ config SILENT_CONSOLE_UPDATE_ON_RELOC
> (e.g. NAND). This option makes the value of the 'silent'
> environment variable take effect at relocation.
>  
> +config PRE_CONSOLE_BUFFER
> + bool "Buffer characters before the console is available"
> + help
> +   Prior to the console being initialised (i.e. serial UART
> +   initialised etc) all console output is silently discarded.
> +   Defining CONFIG_PRE_CONSOLE_BUFFER will cause U-Boot to
> +   buffer any console messages prior to the console being
> +   initialised to a buffer. The buffer is a circular buffer, so
> +   if it overflows, earlier output is discarded.
> +
> +   Note that this is not currently supported in SPL. It would be
> +   useful to be able to share the pre-console buffer with SPL.

We can't (easily) share this buffer with SPL. In the SPL case, this
buffer needs to be placed somewhere in