Re: [U-Boot] u-boot.dtb is not generated when enabling verified boot

2018-04-20 Thread Davis Roman
Okay. I found my first mistake. I would help if I could spell properly!

Turns out it was:
#define CONFIG_OF_SEPARATE
and not
#define CONFIG_OF_SEPERATE

but now I'm getting an error:

  LD  test/dm/built-in.o
  CC  examples/standalone/stubs.o
  LD  examples/standalone/libstubs.o
  CC  examples/standalone/hello_world.o
  LD  examples/standalone/hello_world
  OBJCOPY examples/standalone/hello_world.srec
  OBJCOPY examples/standalone/hello_world.bin
  LDS u-boot.lds
  LD  u-boot
  OBJCOPY u-boot-nodtb.bin

Device Tree Source is not correctly specified.
Please define 'CONFIG_DEFAULT_DEVICE_TREE'
or build with 'DEVICE_TREE=' argument

dts/Makefile:27: recipe for target 'arch/arm/dts/unset.dtb' failed
make[1]: *** [arch/arm/dts/unset.dtb] Error 1
Makefile:820: recipe for target 'dts/dt.dtb' failed
make: *** [dts/dt.dtb] Error 2



Do I need to provide a dts file? I got the impression that this wasn't
the case from the docs.

Thank you,

Davis

On Fri, Apr 20, 2018 at 8:00 PM, Davis Roman  wrote:
> Hello,
>
> I'm trying to get verified-boot working using u-boot 2016.03 on an imx6.
>
> So far I've managed to figure out that I need the following additional
> config settings:
>  #define CONFIG_DM
> #define CONFIG_ENABLE_VBOOT
> #define CONFIG_RSA
> #define CONFIG_FIT
> #define CONFIG_OF_CONTROL
> #define CONFIG_FIT_SIGNATURE
> #define CONFIG_OF_SEPERATE
> #define CONFIG_OF_LIBFDT
> #define CONFIG_FIT_VERBOSE
>
> However, no matter what I do I can't seem to generate u-boot.dtb.
>
> My understanding is that u-boot automatically generates this
> u-boot.dtb for the purpose of storing
> the public key when mkimage signs the fitimage and that this process
> does not require that I provide a dts file.
>
> However, below are the files that are generated with my current
> configuration and no u-boot.dtb file is generated.
>
> Additionally, since u-boot produces a u-boot-nodtb.bin, I figured it
> was reasonable to believe that u-boot.bin contained the device tree
> however as shown below both u-boot-nodtb.bin and u-boot.bin have an
> idential hash.
>
> Is there something that I'm missing here? Any advice would be greatly
> appreciated
>
> Thank you,
>
> Davis
>
> davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ ls -l *u-boot*
> -rwxrwxr-x 1 davis davis 3413272 Apr 20 23:41 u-boot
> -rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot.bin
> -rw-rw-r-- 1 davis davis   39490 Apr 20 23:27 u-boot.cfg
> -rw-rw-r-- 1 davis davis  510976 Apr 20 23:37 u-boot.imx
> -rw-rw-r-- 1 davis davis1286 Apr 20 23:37 u-boot.lds
> -rw-rw-r-- 1 davis davis  456812 Apr 20 23:41 u-boot.map
> -rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot-nodtb.bin
> -rwxrwxr-x 1 davis davis 1518250 Apr 20 23:37 u-boot.srec
> -rw-rw-r-- 1 davis davis  119239 Apr 20 23:37 u-boot.sym
> davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$
> davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ sha1sum  *u-boot*
> cf00f776da67d1081fdfb8578ce71d0a63f16c48  u-boot
> 1fa17e1e90b51fc0dce73cf3f88d03cad0664a6f  u-boot.bin
> 1d2ad68da6c9aa7915f8684c53b6c532a07d7c7b  u-boot.cfg
> 599cec8e768eebf313d6735951c02c1271475f72  u-boot.imx
> 97054bccafd82b873a0af24f8e012ff032809b29  u-boot.lds
> 547e4e8cd4e46b5f9755aee4906a5f84906e2331  u-boot.map
> 1fa17e1e90b51fc0dce73cf3f88d03cad0664a6f  u-boot-nodtb.bin
> bb5839b8f23c6c8d952e65f99efac695ae91  u-boot.srec
> 5f933891f3939802ab92c4d642af16973b60af37  u-boot.sym
> davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] u-boot.dtb is not generated when enabling verified boot

2018-04-20 Thread Davis Roman
Hello,

I'm trying to get verified-boot working using u-boot 2016.03 on an imx6.

So far I've managed to figure out that I need the following additional
config settings:
 #define CONFIG_DM
#define CONFIG_ENABLE_VBOOT
#define CONFIG_RSA
#define CONFIG_FIT
#define CONFIG_OF_CONTROL
#define CONFIG_FIT_SIGNATURE
#define CONFIG_OF_SEPERATE
#define CONFIG_OF_LIBFDT
#define CONFIG_FIT_VERBOSE

However, no matter what I do I can't seem to generate u-boot.dtb.

My understanding is that u-boot automatically generates this
u-boot.dtb for the purpose of storing
the public key when mkimage signs the fitimage and that this process
does not require that I provide a dts file.

However, below are the files that are generated with my current
configuration and no u-boot.dtb file is generated.

Additionally, since u-boot produces a u-boot-nodtb.bin, I figured it
was reasonable to believe that u-boot.bin contained the device tree
however as shown below both u-boot-nodtb.bin and u-boot.bin have an
idential hash.

Is there something that I'm missing here? Any advice would be greatly
appreciated

Thank you,

Davis

davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ ls -l *u-boot*
-rwxrwxr-x 1 davis davis 3413272 Apr 20 23:41 u-boot
-rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot.bin
-rw-rw-r-- 1 davis davis   39490 Apr 20 23:27 u-boot.cfg
-rw-rw-r-- 1 davis davis  510976 Apr 20 23:37 u-boot.imx
-rw-rw-r-- 1 davis davis1286 Apr 20 23:37 u-boot.lds
-rw-rw-r-- 1 davis davis  456812 Apr 20 23:41 u-boot.map
-rwxrwxr-x 1 davis davis  506052 Apr 20 23:37 u-boot-nodtb.bin
-rwxrwxr-x 1 davis davis 1518250 Apr 20 23:37 u-boot.srec
-rw-rw-r-- 1 davis davis  119239 Apr 20 23:37 u-boot.sym
davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$
davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$ sha1sum  *u-boot*
cf00f776da67d1081fdfb8578ce71d0a63f16c48  u-boot
1fa17e1e90b51fc0dce73cf3f88d03cad0664a6f  u-boot.bin
1d2ad68da6c9aa7915f8684c53b6c532a07d7c7b  u-boot.cfg
599cec8e768eebf313d6735951c02c1271475f72  u-boot.imx
97054bccafd82b873a0af24f8e012ff032809b29  u-boot.lds
547e4e8cd4e46b5f9755aee4906a5f84906e2331  u-boot.map
1fa17e1e90b51fc0dce73cf3f88d03cad0664a6f  u-boot-nodtb.bin
bb5839b8f23c6c8d952e65f99efac695ae91  u-boot.srec
5f933891f3939802ab92c4d642af16973b60af37  u-boot.sym
davis@XPS-15-9560:~/Desktop/u-boot-work/uboot-imx$
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] u-boot 2018 SPI SPL

2018-04-20 Thread Fabio Estevam
On Fri, Apr 20, 2018 at 3:43 AM, Mehmet Ali İPİN
 wrote:
> Dear Fabio
>
> Thank you very much for your directives and helps.
>
> I applied the steps in WARP board readme file, for the command
>
> => ums 0 mmc 2
>
> I received Unknown command 'ums' - try 'help'
>
> I compared with  WARP7 defconfig and mx6sabresd_defconfig files added some 
> definitions in WARP, but got error messages in make file.
> Therefore I would appreciate your helps/commends if you write me the 
> definitions in config/defconfig files to enable u-boot to run this command?

You can take a look at this commit for reference:

commit 506abdb4ee9664cc0d6d1321e96f7fb8dae72eb9
Author: Marek Vasut 
Date:   Sun Oct 22 10:22:40 2017 +0200

ARM: imx6: Enable UMS and DFU on DHCOM i.MX6 PDK

Enable UMS and DFU, so that the eMMC can be accessed via the
USB gadget port on the board.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Make error in U-boot branch v2015.10-rc5

2018-04-20 Thread Chris Packham
On Fri, 20 Apr 2018, 10:55 PM Arunashis Ghose,  wrote:

> Hi,
>
> Thanks for reading this email and I would be grateful if you have time to
> help me fix the issue.
>
> I am very much new to U-boot world and trying to build U-boot in my
> machine for a particular board - 'Marvel Armada 38x'. While I was trying to
> compile the u-boot fork for Marvel (in github), I got following error:
>

You may want to take a look at the db-88f6820-gp, db-88f6820-amc or
clearfog boards. These are in both the Marvell fork and in u-boot proper.


> ---
>  [Building U-BOOT]*
>
> cc1: error: bad value (armv7-a) for -march= switch
> cc1: error: bad value (armv7-a) for -march= switch
> lib/asm-offsets.c:1:0: error: bad value (armv7-a) for -march= switch
>  /*
>  ^
> Makefile:716: recipe for target 'lib/asm-offsets.s' failed
> make: *** [lib/asm-offsets.s] Error 1
> make: *** Waiting for unfinished jobs
>
>  *** Error: Build failed
> ---
>
> I couldn't figure out what is causing it and a way to fix it.
>
> Then I thought I would try to build u-boot original. I checked out the
> branch v2015.10-rc5 of u-boot and tried to build it for board - 'bananapro'
> (a random choice). I got a similar error:
>
> ---
> $ make Bananapro_config
>   HOSTCC  scripts/basic/fixdep
>   HOSTCC  scripts/kconfig/conf.o
>   SHIPPED scripts/kconfig/zconf.tab.c
>   SHIPPED scripts/kconfig/zconf.lex.c
>   SHIPPED scripts/kconfig/zconf.hash.c
>   HOSTCC  scripts/kconfig/zconf.tab.o
>   HOSTLD  scripts/kconfig/conf
> #
> # configuration written to .config
> #
> $ make all
> scripts/kconfig/conf  --silentoldconfig Kconfig
>   CHK include/config.h
>   UPD include/config.h
>   GEN include/autoconf.mk
>   GEN include/autoconf.mk.dep
>   GEN spl/include/autoconf.mk
>   CHK include/config/uboot.release
>   UPD include/config/uboot.release
>   CHK include/generated/version_autogenerated.h
>   UPD include/generated/version_autogenerated.h
>   CHK include/generated/timestamp_autogenerated.h
>   UPD include/generated/timestamp_autogenerated.h
>   CC  lib/asm-offsets.s
> lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch
>  /*
>  ^
> Kbuild:43: recipe for target 'lib/asm-offsets.s' failed
> make[1]: *** [lib/asm-offsets.s] Error 1
> Makefile:1251: recipe for target 'prepare0' failed
> make: *** [prepare0] Error 2
> ---
>
> Can anyone give me a clue? Thanks a lot.
>

You need to tell the build to use a cross compiler. I.e

export CROSS_COMPILE=arm-linux-gnueabi-
make db-88f6820-gp_defconfig
make

You'll need a reasonably new version of gcc to compile u-boot for arm (for
size reasons mostly). Depending on your distro there might be a package you
can install otherwise there is the excellent service from bootlin (formerly
free-electrons)

https://toolchains.bootlin.com/

The Linux kernel community also publish cross toolchains for various
architectures

https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/7.3.0/

I believe it's possible to use u-boot's buildman tool to install these but
I'm traveling at the moment so I can't look up the details on that.

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


Re: [U-Boot] [PATCH v2 1/2] arm: make arm926ejs startup code thumb compatible

2018-04-20 Thread klaus . goger


> On 20.04.2018, at 23:55, Marek Vasut  wrote:
> 
> On 04/20/2018 09:51 PM, Klaus Goger wrote:
>> When building the mxs platform in thumb mode gcc generates code using
>> the intra procedure call scratch register (ip/r12) for the calling the
>> lowlevel_init function. This modifies the lr in flush_dcache which
>> causes u-boot proper to end in an endless loop.
>> 
>> 40002334:   e1a0c00emov ip, lr
>> 40002338:   eb00df4cbl  4003a070
>> <__lowlevel_init_from_arm>
>> 4000233c:   e1a0e00cmov lr, ip
>> 40002340:   e1a0f00emov pc, lr
>> [...]
>> 4003a070 <__lowlevel_init_from_arm>:
>> 4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
>> <__lowlevel_init_from_arm+0xc>
>> 4003a074:   e08fc00cadd ip, pc, ip
>> 4003a078:   e12fff1cbx  ip
>> 4003a07c:   fffc86cd.word   0xfffc86cd
>> 
>> Instead of using the the ip/r12 register we use sl/r10 to preserve the
>> link register.
>> 
>> According to "Procedure Call Standard for the ARM Architecture" by ARM
>> subroutines have to preserve the contents of register r4-r8, r10, r11
>> and SP. So using r10 instead of r12 should be save.
>> 
>> Signed-off-by: Klaus Goger 
>> Signed-off-by: Christoph Muellner 
>> 
>> ---
>> 
>> Changes in v2:
>> - use bl instead of blx to call lowlevel_init
>> - remove mxs tag as it apply to all arm926ejs platforms
> 
> What is lowlevel_init() is implemented as a C code and therefore thumb ?
> :-) doesn't ie. armv7a handle this somehow already ?
 
lowlevel_init() is implemented in C (you wrote it :)) and therefore thumb if
compiled as thumb.
armv7 lowlevel_init is implemented in assembly.

As the compiler will generate the necessary interwork code there was no need
to change the branch instruction to blx. So I changed it back to bl as the 
original
code as this will work with both generated codes (arm and thumb) and also
if someone decides to reimplement lowlevel_init as arm assembly.

> 
>> arch/arm/cpu/arm926ejs/start.S | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>> 
>> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
>> index 959d1ed86d..317df5c401 100644
>> --- a/arch/arm/cpu/arm926ejs/start.S
>> +++ b/arch/arm/cpu/arm926ejs/start.S
>> @@ -105,9 +105,9 @@ flush_dcache:
>>  /*
>>   * Go setup Memory and board specific bits prior to relocation.
>>   */
>> -mov ip, lr  /* perserve link reg across call */
>> +mov sl, lr  /* perserve link reg across call */
>>  bl  lowlevel_init   /* go setup pll,mux,memory */
>> -mov lr, ip  /* restore link */
>> +mov lr, sl  /* restore link */
>> #endif
>> -mov pc, lr  /* back to my caller */
>> +bx  lr  /* back to my caller */
>> #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
>> 
> 
> 
> -- 
> Best regards,
> Marek Vasut

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


Re: [U-Boot] [PATCH v2 1/2] arm: make arm926ejs startup code thumb compatible

2018-04-20 Thread Marek Vasut
On 04/20/2018 09:51 PM, Klaus Goger wrote:
> When building the mxs platform in thumb mode gcc generates code using
> the intra procedure call scratch register (ip/r12) for the calling the
> lowlevel_init function. This modifies the lr in flush_dcache which
> causes u-boot proper to end in an endless loop.
> 
> 40002334:   e1a0c00emov ip, lr
> 40002338:   eb00df4cbl  4003a070
> <__lowlevel_init_from_arm>
> 4000233c:   e1a0e00cmov lr, ip
> 40002340:   e1a0f00emov pc, lr
> [...]
> 4003a070 <__lowlevel_init_from_arm>:
> 4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
> <__lowlevel_init_from_arm+0xc>
> 4003a074:   e08fc00cadd ip, pc, ip
> 4003a078:   e12fff1cbx  ip
> 4003a07c:   fffc86cd.word   0xfffc86cd
> 
> Instead of using the the ip/r12 register we use sl/r10 to preserve the
> link register.
> 
> According to "Procedure Call Standard for the ARM Architecture" by ARM
> subroutines have to preserve the contents of register r4-r8, r10, r11
> and SP. So using r10 instead of r12 should be save.
> 
> Signed-off-by: Klaus Goger 
> Signed-off-by: Christoph Muellner 
> 
> ---
> 
> Changes in v2:
> - use bl instead of blx to call lowlevel_init
> - remove mxs tag as it apply to all arm926ejs platforms

What is lowlevel_init() is implemented as a C code and therefore thumb ?
:-) doesn't ie. armv7a handle this somehow already ?

>  arch/arm/cpu/arm926ejs/start.S | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
> index 959d1ed86d..317df5c401 100644
> --- a/arch/arm/cpu/arm926ejs/start.S
> +++ b/arch/arm/cpu/arm926ejs/start.S
> @@ -105,9 +105,9 @@ flush_dcache:
>   /*
>* Go setup Memory and board specific bits prior to relocation.
>*/
> - mov ip, lr  /* perserve link reg across call */
> + mov sl, lr  /* perserve link reg across call */
>   bl  lowlevel_init   /* go setup pll,mux,memory */
> - mov lr, ip  /* restore link */
> + mov lr, sl  /* restore link */
>  #endif
> - mov pc, lr  /* back to my caller */
> + bx  lr  /* back to my caller */
>  #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
> 


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


Re: [U-Boot] [PATCH] drivers: spi: migrate cf_spi to DM

2018-04-20 Thread Angelo Dureghello
Hi Jagan,

On Fri, Apr 20, 2018 at 09:37:29PM +, Jagan Teki wrote:
> On Thu, Mar 22, 2018 at 8:13 PM, Angelo Dureghello  wrote:
> > This patch adds DM support to cf_spi.c.
> > To be able to build spi driver with DM support, a new config
> > option has been introdiced (DM_NO_DT) since m68k architecture
> > does not support fdt.
> 
> This can be different case, how about using platdata in U-Boot?
>

I used also platdata, as you can see from

+#include 

But it is not enough: spi/spi-uclass.c in any case looks for 
fdt nodes entries, so i had to add that DM_NO_OF option, 
this to avoid all the of_xx calls as unresolved externals.

Every suggestion is welcome.
 
> Jagan.
> 

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


[U-Boot] [PATCH v2] Migrate IMAGE_FORMAT_LEGACY to Kconfig

2018-04-20 Thread Alex Kiernan
This converts IMAGE_FORMAT_LEGACY to Kconfig

Signed-off-by: Alex Kiernan 
---
Convert CONFIG_IMAGE_FORMAT_LEGACY to Kconfig. We also drop
CONFIG_DISABLE_IMAGE_LEGACY as this can now be handled through
configuration.

Green Travis build:

https://travis-ci.org/akiernan/u-boot/builds/369244180

Changes in v2:
- Drop RFC prefix
- Rebase against master
- Re-run Travis

 Kconfig| 10 ++
 README | 13 -
 configs/ids8313_defconfig  |  1 +
 configs/imx6dl_icore_nand_defconfig|  1 +
 configs/imx6q_icore_nand_defconfig |  1 +
 configs/imx6qdl_icore_mipi_defconfig   |  1 +
 configs/imx6qdl_icore_mmc_defconfig|  1 +
 configs/imx6qdl_icore_nand_defconfig   |  1 +
 configs/imx6qdl_icore_rqs_defconfig|  1 +
 configs/imx6ul_geam_mmc_defconfig  |  1 +
 configs/imx6ul_geam_nand_defconfig |  1 +
 configs/imx6ul_isiot_emmc_defconfig|  1 +
 configs/imx6ul_isiot_nand_defconfig|  1 +
 configs/syzygy_hub_defconfig   |  1 +
 configs/zynq_cc108_defconfig   |  1 +
 configs/zynq_microzed_defconfig|  1 +
 configs/zynq_z_turn_defconfig  |  1 +
 configs/zynq_zc702_defconfig   |  1 +
 configs/zynq_zc706_defconfig   |  1 +
 configs/zynq_zc770_xm010_defconfig |  1 +
 configs/zynq_zc770_xm011_defconfig |  1 +
 configs/zynq_zc770_xm011_x16_defconfig |  1 +
 configs/zynq_zc770_xm012_defconfig |  1 +
 configs/zynq_zc770_xm013_defconfig |  1 +
 configs/zynq_zed_defconfig |  1 +
 configs/zynq_zybo_defconfig|  1 +
 include/config_fallbacks.h |  8 
 include/configs/ids8313.h  |  2 --
 include/configs/imx6-engicam.h |  5 -
 include/configs/wb50n.h|  2 --
 include/configs/zynq-common.h  |  3 ---
 scripts/config_whitelist.txt   |  2 --
 32 files changed, 34 insertions(+), 35 deletions(-)

diff --git a/Kconfig b/Kconfig
index 6957097..78afe72 100644
--- a/Kconfig
+++ b/Kconfig
@@ -361,6 +361,16 @@ endif # SPL
 
 endif # FIT
 
+config IMAGE_FORMAT_LEGACY
+   bool "Enable support for the legacy image format"
+   default y if !FIT_SIGNATURE
+   help
+ This option enables the legacy image format. It is enabled by
+ default for backward compatibility, unless FIT_SIGNATURE is
+ set where it is disabled so that unsigned images cannot be
+ loaded. If a board needs the legacy image format support in this
+ case, enable it here.
+
 config OF_BOARD_SETUP
bool "Set up board-specific details in device tree before boot"
depends on OF_LIBFDT
diff --git a/README b/README
index 6f98e09..a15a3dd 100644
--- a/README
+++ b/README
@@ -2413,19 +2413,6 @@ FIT uImage format:
  -150  common/cmd_nand.c   Incorrect FIT image format
   151  common/cmd_nand.c   FIT image format OK
 
-- legacy image format:
-   CONFIG_IMAGE_FORMAT_LEGACY
-   enables the legacy image format support in U-Boot.
-
-   Default:
-   enabled if CONFIG_FIT_SIGNATURE is not defined.
-
-   CONFIG_DISABLE_IMAGE_LEGACY
-   disable the legacy image format
-
-   This define is introduced, as the legacy image format is
-   enabled per default for backward compatibility.
-
 - Standalone program support:
CONFIG_STANDALONE_LOAD_ADDR
 
diff --git a/configs/ids8313_defconfig b/configs/ids8313_defconfig
index b662111..695a1ed 100644
--- a/configs/ids8313_defconfig
+++ b/configs/ids8313_defconfig
@@ -4,6 +4,7 @@ CONFIG_MPC83xx=y
 CONFIG_TARGET_IDS8313=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
+CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_OF_BOARD_SETUP=y
 CONFIG_OF_STDOUT_VIA_ALIAS=y
 CONFIG_BOOTDELAY=1
diff --git a/configs/imx6dl_icore_nand_defconfig 
b/configs/imx6dl_icore_nand_defconfig
index 74a534c..c34e3ac 100644
--- a/configs/imx6dl_icore_nand_defconfig
+++ b/configs/imx6dl_icore_nand_defconfig
@@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="imx6dl-icore"
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_SPL_DMA_SUPPORT=y
diff --git a/configs/imx6q_icore_nand_defconfig 
b/configs/imx6q_icore_nand_defconfig
index 0caba80..f8477a9 100644
--- a/configs/imx6q_icore_nand_defconfig
+++ b/configs/imx6q_icore_nand_defconfig
@@ -13,6 +13,7 @@ CONFIG_DEFAULT_DEVICE_TREE="imx6q-icore"
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_FIT_VERBOSE=y
+CONFIG_IMAGE_FORMAT_LEGACY=y
 CONFIG_SYS_EXTRA_OPTIONS="IMX_CONFIG=arch/arm/mach-imx/spl_sd.cfg"
 CONFIG_BOOTDELAY=3
 CONFIG_SUPPORT_RAW_INITRD=y
diff --git a/configs/imx6qdl_icore_mipi_defconfig 
b/configs/imx6qdl_icore_mipi_defconfig
index 4e1dad6..17fff72 100644
--- a/configs/imx6qdl_icore_mipi_defconfig
+++ b/configs/imx6qdl_icore_mipi_defconfig
@@ -17,6 +17,7 @@ 

Re: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

2018-04-20 Thread Michael Nazzareno Trimarchi
Hi

On Fri, Apr 20, 2018 at 10:10 PM, Maxime Ripard
 wrote:
> On Mon, Apr 16, 2018 at 10:37:11PM +0200, Michael Nazzareno Trimarchi wrote:
>> Hi
>>
>> On Mon, Apr 16, 2018 at 9:55 PM, Maxime Ripard
>>  wrote:
>> > On Fri, Apr 06, 2018 at 07:54:47AM +0200, Maxime Ripard wrote:
>> >> Hi Jaehoon,
>> >>
>> >> On Wed, Mar 21, 2018 at 12:18:58PM +0100, Maxime Ripard wrote:
>> >> > From: Philipp Tomsich 
>> >> >
>> >> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
>> >> > read 10MB from a fast eMMC device due to excessive delays in polling
>> >> > loops.
>> >> >
>> >> > This commit restructures the main polling loops to use get_timer(...)
>> >> > to determine whether a (millisecond) timeout has expired.  We choose
>> >> > not to use the wait_bit function, as we don't need interruptability
>> >> > with ctrl-c and have at least one case where two bits (one for an
>> >> > error condition and another one for completion) need to be read and
>> >> > using wait_bit would have not added to the clarity.
>> >> >
>> >> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
>> >> > 10MB write decreases from 9.302s to 0.884s).
>> >> >
>> >> > Signed-off-by: Philipp Tomsich 
>> >> > Signed-off-by: Maxime Ripard 
>> >>
>> >> Any chance we can merge this for the next release?
>> >
>> > Ping?
>> >
>>
>> Just curios but what is the result if %s/udelay(1000)/udelay(1)/g in
>> the driver
>
> This will probably speed up the transfer as well, but we don't need
> that udelay in the first place. We don't have any application or OS to
> be nice to, so we can just busy loop in order to achieve the higher
> throughput. Or am I missing something?
>

One is to try to have less code change and second was to ping in another way
to be included

Michael

> Maxime
>
> --
> Maxime Ripard, Bootlin (formerly Free Electrons)
> Embedded Linux and Kernel engineering
> https://bootlin.com



-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] sunxi: improve throughput in the sunxi_mmc driver

2018-04-20 Thread Maxime Ripard
On Mon, Apr 16, 2018 at 10:37:11PM +0200, Michael Nazzareno Trimarchi wrote:
> Hi
> 
> On Mon, Apr 16, 2018 at 9:55 PM, Maxime Ripard
>  wrote:
> > On Fri, Apr 06, 2018 at 07:54:47AM +0200, Maxime Ripard wrote:
> >> Hi Jaehoon,
> >>
> >> On Wed, Mar 21, 2018 at 12:18:58PM +0100, Maxime Ripard wrote:
> >> > From: Philipp Tomsich 
> >> >
> >> > Throughput tests have shown the sunxi_mmc driver to take over 10s to
> >> > read 10MB from a fast eMMC device due to excessive delays in polling
> >> > loops.
> >> >
> >> > This commit restructures the main polling loops to use get_timer(...)
> >> > to determine whether a (millisecond) timeout has expired.  We choose
> >> > not to use the wait_bit function, as we don't need interruptability
> >> > with ctrl-c and have at least one case where two bits (one for an
> >> > error condition and another one for completion) need to be read and
> >> > using wait_bit would have not added to the clarity.
> >> >
> >> > The observed speedup in testing on a A31 is greater than 10x (e.g. a
> >> > 10MB write decreases from 9.302s to 0.884s).
> >> >
> >> > Signed-off-by: Philipp Tomsich 
> >> > Signed-off-by: Maxime Ripard 
> >>
> >> Any chance we can merge this for the next release?
> >
> > Ping?
> >
> 
> Just curios but what is the result if %s/udelay(1000)/udelay(1)/g in
> the driver

This will probably speed up the transfer as well, but we don't need
that udelay in the first place. We don't have any application or OS to
be nice to, so we can just busy loop in order to achieve the higher
throughput. Or am I missing something?

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v2 0/2] While trying to compile u-boot in thumb due space constraints on a mxs

2018-04-20 Thread Klaus Goger
platform it was observed that there are some thumb-interwork issues
in the handwritten assembly files.

Since the first patch only applies to ARM926EJS and no board on that platform
has thumb enabled for now,it was probably never observed.

The second one applies to the ARM specific assembly memcpy implementation
that is not enabled on any of the boards enabling thumb.

grep -l CONFIG_SYS_THUMB_BUILD=y configs/* | \
  xargs grep -c CONFIG_USE_ARCH_MEMCPY
configs/apalis_imx6_nospl_com_defconfig:0
configs/apalis_imx6_nospl_it_defconfig:0
configs/bk4r1_defconfig:0
configs/colibri_imx6_nospl_defconfig:0
configs/colibri_imx7_defconfig:0
configs/colibri_vf_defconfig:0
configs/highbank_defconfig:0
configs/openrd_base_defconfig:0
configs/openrd_client_defconfig:0
configs/openrd_ultimate_defconfig:0
configs/pcm052_defconfig:0
configs/tbs2910_defconfig:0
configs/x600_defconfig:0

With CONFIG_USE_ARCH_MEMCPY on our mxs platform the speedup for memcopy
was about 100%.

Changes in v2:
- use bl instead of blx to call lowlevel_init
- remove mxs tag as it apply to all arm926ejs platforms

Klaus Goger (2):
  arm: make arm926ejs startup code thumb compatible
  arm: Make arch specific memcpy thumb-safe.

 arch/arm/cpu/arm926ejs/start.S | 6 +++---
 arch/arm/lib/memcpy.S  | 8 +---
 2 files changed, 8 insertions(+), 6 deletions(-)

-- 
2.11.0

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


[U-Boot] [PATCH v2 2/2] arm: Make arch specific memcpy thumb-safe.

2018-04-20 Thread Klaus Goger
The current arch implementation of memcpy cannot be called
from thumb code, because it does not use bx instructions on return.
This patch addresses that. Note, that this patch does not touch
the hot loop of memcpy, so performance is not affected.

Tested on MXS (arm926ejs) with and without thumb-mode enabled.

Signed-off-by: Klaus Goger 
Signed-off-by: Christoph Muellner 

---

Changes in v2: None

 arch/arm/lib/memcpy.S | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/arch/arm/lib/memcpy.S b/arch/arm/lib/memcpy.S
index 588b3f8971..9e9a193c2a 100644
--- a/arch/arm/lib/memcpy.S
+++ b/arch/arm/lib/memcpy.S
@@ -62,7 +62,7 @@
 #endif
 ENTRY(memcpy)
cmp r0, r1
-   moveq   pc, lr
+   bxeqlr
 
enter   r4, lr
 
@@ -150,7 +150,8 @@ ENTRY(memcpy)
str1b   r0, r4, cs, abort=21f
str1b   r0, ip, cs, abort=21f
 
-   exitr4, pc
+   exitr4, lr
+   bx  lr
 
 9: rsb ip, ip, #4
cmp ip, #2
@@ -259,7 +260,8 @@ ENTRY(memcpy)
.endm
 
.macro  copy_abort_end
-   ldmfd   sp!, {r4, pc}
+   ldmfd   sp!, {r4, lr}
+   bx  lr
.endm
 
 ENDPROC(memcpy)
-- 
2.11.0

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


[U-Boot] [PATCH v2 1/2] arm: make arm926ejs startup code thumb compatible

2018-04-20 Thread Klaus Goger
When building the mxs platform in thumb mode gcc generates code using
the intra procedure call scratch register (ip/r12) for the calling the
lowlevel_init function. This modifies the lr in flush_dcache which
causes u-boot proper to end in an endless loop.

40002334:   e1a0c00emov ip, lr
40002338:   eb00df4cbl  4003a070
<__lowlevel_init_from_arm>
4000233c:   e1a0e00cmov lr, ip
40002340:   e1a0f00emov pc, lr
[...]
4003a070 <__lowlevel_init_from_arm>:
4003a070:   e59fc004ldr ip, [pc, #4]; 4003a07c
<__lowlevel_init_from_arm+0xc>
4003a074:   e08fc00cadd ip, pc, ip
4003a078:   e12fff1cbx  ip
4003a07c:   fffc86cd.word   0xfffc86cd

Instead of using the the ip/r12 register we use sl/r10 to preserve the
link register.

According to "Procedure Call Standard for the ARM Architecture" by ARM
subroutines have to preserve the contents of register r4-r8, r10, r11
and SP. So using r10 instead of r12 should be save.

Signed-off-by: Klaus Goger 
Signed-off-by: Christoph Muellner 

---

Changes in v2:
- use bl instead of blx to call lowlevel_init
- remove mxs tag as it apply to all arm926ejs platforms

 arch/arm/cpu/arm926ejs/start.S | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S
index 959d1ed86d..317df5c401 100644
--- a/arch/arm/cpu/arm926ejs/start.S
+++ b/arch/arm/cpu/arm926ejs/start.S
@@ -105,9 +105,9 @@ flush_dcache:
/*
 * Go setup Memory and board specific bits prior to relocation.
 */
-   mov ip, lr  /* perserve link reg across call */
+   mov sl, lr  /* perserve link reg across call */
bl  lowlevel_init   /* go setup pll,mux,memory */
-   mov lr, ip  /* restore link */
+   mov lr, sl  /* restore link */
 #endif
-   mov pc, lr  /* back to my caller */
+   bx  lr  /* back to my caller */
 #endif /* CONFIG_SKIP_LOWLEVEL_INIT */
-- 
2.11.0

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


[U-Boot] [PATCH v3] db410c: set clk node to be probed before relocation

2018-04-20 Thread Ramon Fried
The clock node is used by the serial driver and it's needed
before relocation.
This patch ensures that the msm-serial driver can actually
use the clock node.

Signed-off-by: Ramon Fried 
---
v2: Moved the u-boot,dm-pre-reloc attribute to the -uboot.dtsi file
v3: Moved the forgotten u-boot,dm-pre-reloc also to -uboot.dtsi file

 arch/arm/dts/dragonboard410c-uboot.dtsi | 12 
 arch/arm/dts/dragonboard410c.dts|  1 -
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi 
b/arch/arm/dts/dragonboard410c-uboot.dtsi
index c3475c4227..1de1419edc 100644
--- a/arch/arm/dts/dragonboard410c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
@@ -10,6 +10,18 @@
config {
u-boot,mmc-env-partition = "boot";
};
+
+   soc {
+   u-boot,dm-pre-reloc;
+
+   qcom,gcc@180 {
+   u-boot,dm-pre-reloc;
+   };
+
+   serial@78b {
+   u-boot,dm-pre-reloc;
+   };
+   };
 };
 
 
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 5ccfe7f8c8..aa9b0a138b 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -49,7 +49,6 @@
serial@78b {
compatible = "qcom,msm-uartdm-v1.4";
reg = <0x78b 0x200>;
-   u-boot,dm-pre-reloc;
clock = < 4>;
};
 
-- 
2.14.1

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


[U-Boot] [PATCH v2] db410c: set clk node to be probed before relocation

2018-04-20 Thread Ramon Fried
The clock node is used by the serial driver and it's needed
before relocation.
This patch ensures that the msm-serial driver can actually
use the clock node.

Signed-off-by: Ramon Fried 
---
v2: Moved the u-boot,dm-pre-reloc attribute to the -uboot.dtsi file

 arch/arm/dts/dragonboard410c-uboot.dtsi | 8 
 arch/arm/dts/dragonboard410c.dts| 2 +-
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/dragonboard410c-uboot.dtsi 
b/arch/arm/dts/dragonboard410c-uboot.dtsi
index c3475c4227..adf6b62f13 100644
--- a/arch/arm/dts/dragonboard410c-uboot.dtsi
+++ b/arch/arm/dts/dragonboard410c-uboot.dtsi
@@ -10,6 +10,14 @@
config {
u-boot,mmc-env-partition = "boot";
};
+
+   soc {
+   u-boot,dm-pre-reloc;
+
+   serial@78b {
+   u-boot,dm-pre-reloc;
+   };
+   };
 };
 
 
diff --git a/arch/arm/dts/dragonboard410c.dts b/arch/arm/dts/dragonboard410c.dts
index 5ccfe7f8c8..d6a296ca37 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -44,12 +44,12 @@
reg = <0x180 0x8>;
#address-cells = <0x1>;
#size-cells = <0x0>;
+   u-boot,dm-pre-reloc;
};
 
serial@78b {
compatible = "qcom,msm-uartdm-v1.4";
reg = <0x78b 0x200>;
-   u-boot,dm-pre-reloc;
clock = < 4>;
};
 
-- 
2.14.1

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


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Ramon Fried
On 20 April 2018 at 21:38, Ramon Fried  wrote:
> On 20 April 2018 at 17:45, Jorge Ramirez-Ortiz  wrote:
>> On 04/20/2018 03:46 PM, Ramon Fried wrote:
>>>
>>> On 20 April 2018 at 14:50, Jorge Ramirez-Ortiz 
>>> wrote:

 On 04/20/2018 01:22 PM, Ramon Fried wrote:
>
> On 20 April 2018 at 14:14, Jorge Ramirez-Ortiz 
> wrote:
>>
>> On 04/20/2018 01:02 PM, Ramon Fried wrote:
>>>
>>> On 18 April 2018 at 13:15, Jorge Ramirez-Ortiz 
>>> wrote:

 On 04/18/2018 09:02 AM, Jorge Ramirez-Ortiz wrote:
>
> On 04/17/2018 02:01 PM, Ramon Fried wrote:
>>
>> The clock node is used by the serial driver and it's needed
>> before relocation.
>> This patch ensures that the msm-serial driver can actually
>> use the clock node.
>>
>> Signed-off-by: Ramon Fried 
>> ---
>>  arch/arm/dts/dragonboard410c.dts | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/dts/dragonboard410c.dts
>> b/arch/arm/dts/dragonboard410c.dts
>> index 5ccfe7f8c8..f37ef5d523 100644
>> --- a/arch/arm/dts/dragonboard410c.dts
>> +++ b/arch/arm/dts/dragonboard410c.dts
>> @@ -38,12 +38,14 @@
>>  #size-cells = <0x1>;
>>  ranges = <0x0 0x0 0x0 0x>;
>>  compatible = "simple-bus";
>> +u-boot,dm-pre-reloc;
>
>
> I think the intent is to make dm-pre-reloc legacy.
> New platforms should be using "u-boot,dm-spl" even if
> CONFIG_SPL_BUILD
> is
> not enabled (I believe it should work)
>
>>clkc: qcom,gcc@180 {
>>  compatible = "qcom,gcc-apq8016";
>>  reg = <0x180 0x8>;
>>  #address-cells = <0x1>;
>>  #size-cells = <0x0>;
>> +u-boot,dm-pre-reloc;
>>  };
>>serial@78b {
>
>
 another question is, how will you probe the clock driver before the
 uart?
 I think even if you probed in misc_init_f it is already too late.

 other than that - + Peter Robinson's comments- looks good.

>>> The clock is probed because the uart driver asks for it. it's actually
>>> already exists in the code, but wasn't used because
>>> the clock wasn't set to dm-pre-reloc
>>
>>
>> um, are you sure? that is not what I see during my tests but I could be
>> wrong - or something else might be happening in uboot
>>
>> you can create a misc_init_f for the board that retrieves the clock
>> driver
>> by name and forces a probe; I can see that the probe happens (ie, the
>> DM_FLAG_ACTIVATED was _not_ set for that driver) which is not what I
>> believe
>> you expect since you want the clock driver to be probed before the
>> uart.
>
> It doesn't need to be probed before the uart, the uart is probed first
> and when it asks for the
> clock node it's forcing a probe. it's tested.


 can you post a trace. just dump the value of GD_FLG_RELOC on clock the
 probe
 function.
>>>
>>> The serial isn't  initialized at this time, I'll save the value and
>>> print afterwards :)
>>
>>
>> of course.
>>  I think it makes sense to add some debug statement near DM_FLAG_ACTIVATED
>> in device_probe...the driver should not be probed a second time if it was
>> successfully probed early before relocation
> Actually, I already verified that. the driver probes twice, once
> before and once after relocation.
> In case of serial, it's not a big deal to re-initialize the hardware,
> but I agree it's worthless.
>>
Ok. just checked, it's first probed before relocation.
>>
>>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Ramon Fried
On 20 April 2018 at 17:45, Jorge Ramirez-Ortiz  wrote:
> On 04/20/2018 03:46 PM, Ramon Fried wrote:
>>
>> On 20 April 2018 at 14:50, Jorge Ramirez-Ortiz 
>> wrote:
>>>
>>> On 04/20/2018 01:22 PM, Ramon Fried wrote:

 On 20 April 2018 at 14:14, Jorge Ramirez-Ortiz 
 wrote:
>
> On 04/20/2018 01:02 PM, Ramon Fried wrote:
>>
>> On 18 April 2018 at 13:15, Jorge Ramirez-Ortiz 
>> wrote:
>>>
>>> On 04/18/2018 09:02 AM, Jorge Ramirez-Ortiz wrote:

 On 04/17/2018 02:01 PM, Ramon Fried wrote:
>
> The clock node is used by the serial driver and it's needed
> before relocation.
> This patch ensures that the msm-serial driver can actually
> use the clock node.
>
> Signed-off-by: Ramon Fried 
> ---
>  arch/arm/dts/dragonboard410c.dts | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/dts/dragonboard410c.dts
> b/arch/arm/dts/dragonboard410c.dts
> index 5ccfe7f8c8..f37ef5d523 100644
> --- a/arch/arm/dts/dragonboard410c.dts
> +++ b/arch/arm/dts/dragonboard410c.dts
> @@ -38,12 +38,14 @@
>  #size-cells = <0x1>;
>  ranges = <0x0 0x0 0x0 0x>;
>  compatible = "simple-bus";
> +u-boot,dm-pre-reloc;


 I think the intent is to make dm-pre-reloc legacy.
 New platforms should be using "u-boot,dm-spl" even if
 CONFIG_SPL_BUILD
 is
 not enabled (I believe it should work)

>clkc: qcom,gcc@180 {
>  compatible = "qcom,gcc-apq8016";
>  reg = <0x180 0x8>;
>  #address-cells = <0x1>;
>  #size-cells = <0x0>;
> +u-boot,dm-pre-reloc;
>  };
>serial@78b {


>>> another question is, how will you probe the clock driver before the
>>> uart?
>>> I think even if you probed in misc_init_f it is already too late.
>>>
>>> other than that - + Peter Robinson's comments- looks good.
>>>
>> The clock is probed because the uart driver asks for it. it's actually
>> already exists in the code, but wasn't used because
>> the clock wasn't set to dm-pre-reloc
>
>
> um, are you sure? that is not what I see during my tests but I could be
> wrong - or something else might be happening in uboot
>
> you can create a misc_init_f for the board that retrieves the clock
> driver
> by name and forces a probe; I can see that the probe happens (ie, the
> DM_FLAG_ACTIVATED was _not_ set for that driver) which is not what I
> believe
> you expect since you want the clock driver to be probed before the
> uart.

 It doesn't need to be probed before the uart, the uart is probed first
 and when it asks for the
 clock node it's forcing a probe. it's tested.
>>>
>>>
>>> can you post a trace. just dump the value of GD_FLG_RELOC on clock the
>>> probe
>>> function.
>>
>> The serial isn't  initialized at this time, I'll save the value and
>> print afterwards :)
>
>
> of course.
>  I think it makes sense to add some debug statement near DM_FLAG_ACTIVATED
> in device_probe...the driver should not be probed a second time if it was
> successfully probed early before relocation
Actually, I already verified that. the driver probes twice, once
before and once after relocation.
In case of serial, it's not a big deal to re-initialize the hardware,
but I agree it's worthless.
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] Make error in U-boot branch v2015.10-rc5

2018-04-20 Thread Alex Kiernan
On Fri, Apr 20, 2018 at 10:41 AM, Arunashis Ghose  wrote:
> Hi,
>
> Thanks for reading this email and I would be grateful if you have time to 
> help me fix the issue.
>
> I am very much new to U-boot world and trying to build U-boot in my machine 
> for a particular board - 'Marvel Armada 38x'. While I was trying to compile 
> the u-boot fork for Marvel (in github), I got following error:
>
> ---
>  [Building U-BOOT]*
>
> cc1: error: bad value (armv7-a) for -march= switch
> cc1: error: bad value (armv7-a) for -march= switch
> lib/asm-offsets.c:1:0: error: bad value (armv7-a) for -march= switch
>  /*
>  ^
> Makefile:716: recipe for target 'lib/asm-offsets.s' failed
> make: *** [lib/asm-offsets.s] Error 1
> make: *** Waiting for unfinished jobs
>
>  *** Error: Build failed

Wild guess, you've not told the build process to use a cross-compiler?

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


Re: [U-Boot] [PATCH v6 1/2] x86: Add TSC-specific timer functions

2018-04-20 Thread Ivan Gorinov
On Fri, Apr 20, 2018 at 06:25:08AM -0600, Andy Shevchenko wrote:
> > Coreboot timestamp functions and Quark memory reference code use
> > get_tbclk() to get TSC frequency. This will not work if another
> > early timer is selected.
> > 
> > Add tsc_rate_mhz() function and use it in the code that specifically
> > needs to get TSC rate regardless of currently selected early timer.
> 
> 
> >  void delay_n(uint32_t ns)
> >  {
> > /* 1000 MHz clock has 1ns period --> no conversion required
> > */
> > -   uint64_t final_tsc = rdtsc();
> > +   uint64_t start_tsc = rdtsc();
> > +   uint64_t ticks;
> >  
> > -   final_tsc += ((get_tbclk_mhz() * ns) / 1000);
> > -
> > -   while (rdtsc() < final_tsc)
> > -   ;
> > +   ticks = (tsc_rate_mhz() * ns) / 1000;
> 
> > +   while (rdtsc() - start_tsc < ticks);
> 
> I would rather preserve existing style.

OK. Existing style does not correctly handle overflow,
but for a 64-bit counter it's a very unlikely event.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] x86: Use microcode update from device tree for all processors

2018-04-20 Thread Ivan Gorinov
Hi Bin,

On Wed, Apr 18, 2018 at 07:05:28PM -0600, Bin Meng wrote:
> >> >
> >> > If there is no ROM image, ucode_base and ucode_size are not initialized 
> >> > and
> >> > the microcode update data from DTB applied by microcode_update_intel() 
> >> > to the
> >> > bootstrap CPU is not used by the multiprocessing code.
> >>
> >> Correct. If it's not a ROM image, which means U-Boot is probably not
> >> the 1st stage bootloader, which means updating microcode is not
> >> necessary. So is there any issue with current implementation?
> >
> > If the 1st stage bootloader is running from the on-chip SRAM, there may be
> > not enough space to include the microcode update data. In this case, U-Boot
> > is a secondary boot loader but still has to update the microcode.
> 
> Thanks for the information. Correct, if that's the case, then we
> should tune our codes to support that.
> 
> But I guess the "1st stage" bootloader is loaded by some on-chip
> BOOTROM to the internal SRAM?

Correct.

> Is the "1st stage" bootloader running from SRAM the U-Boot SPL? Or
> some proprietary implementation?

It's usually a proprietary implementation.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 5/9] mtd: nand: mxs_nand: create separate header file

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

Create separate header file so we can use a separate compile
unit for device tree support.

Signed-off-by: Stefan Agner 
---

 drivers/mtd/nand/mxs_nand.c | 61 ++-
 drivers/mtd/nand/mxs_nand.h | 72 +
 2 files changed, 75 insertions(+), 58 deletions(-)
 create mode 100644 drivers/mtd/nand/mxs_nand.h

diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 978f6a6893..5fbbb0a706 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -14,11 +14,10 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -26,7 +25,8 @@
 #include 
 #include 
 #include 
-#include 
+
+#include "mxs_nand.h"
 
 #defineMXS_NAND_DMA_DESCRIPTOR_COUNT   4
 
@@ -46,61 +46,6 @@
 
 #defineMXS_NAND_BCH_TIMEOUT1
 
-/**
- * @gf_len:   The length of Galois Field. (e.g., 13 or 14)
- * @ecc_strength: A number that describes the strength of the ECC
- *algorithm.
- * @ecc_chunk_size:   The size, in bytes, of a single ECC chunk. Note
- *the first chunk in the page includes both data 
and
- *metadata, so it's a bit larger than this value.
- * @ecc_chunk_count:  The number of ECC chunks in the page,
- * @block_mark_byte_offset:   The byte offset in the ECC-based page view at
- *which the underlying physical block mark appears.
- * @block_mark_bit_offset:The bit offset into the ECC-based page view at
- *which the underlying physical block mark appears.
- */
-struct bch_geometry {
-   unsigned int  gf_len;
-   unsigned int  ecc_strength;
-   unsigned int  ecc_chunk_size;
-   unsigned int  ecc_chunk_count;
-   unsigned int  block_mark_byte_offset;
-   unsigned int  block_mark_bit_offset;
-};
-
-struct mxs_nand_info {
-   struct nand_chip chip;
-   unsigned intmax_ecc_strength_supported;
-   booluse_minimum_ecc;
-   int cur_chip;
-
-   uint32_tcmd_queue_len;
-   uint32_tdata_buf_size;
-   struct bch_geometry bch_geometry;
-
-   uint8_t *cmd_buf;
-   uint8_t *data_buf;
-   uint8_t *oob_buf;
-
-   uint8_t marking_block_bad;
-   uint8_t raw_oob_mode;
-
-   struct mxs_gpmi_regs *gpmi_regs;
-   struct mxs_bch_regs *bch_regs;
-
-   /* Functions with altered behaviour */
-   int (*hooked_read_oob)(struct mtd_info *mtd,
-   loff_t from, struct mtd_oob_ops *ops);
-   int (*hooked_write_oob)(struct mtd_info *mtd,
-   loff_t to, struct mtd_oob_ops *ops);
-   int (*hooked_block_markbad)(struct mtd_info *mtd,
-   loff_t ofs);
-
-   /* DMA descriptors */
-   struct mxs_dma_desc **desc;
-   uint32_tdesc_index;
-};
-
 struct nand_ecclayout fake_ecc_layout;
 
 /*
diff --git a/drivers/mtd/nand/mxs_nand.h b/drivers/mtd/nand/mxs_nand.h
new file mode 100644
index 00..ae3432357e
--- /dev/null
+++ b/drivers/mtd/nand/mxs_nand.h
@@ -0,0 +1,72 @@
+/*
+ * NXP GPMI NAND flash driver
+ *
+ * Copyright (C) 2018 Toradex
+ * Authors:
+ * Stefan Agner 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * @gf_len:   The length of Galois Field. (e.g., 13 or 14)
+ * @ecc_strength: A number that describes the strength of the ECC
+ *algorithm.
+ * @ecc_chunk_size:   The size, in bytes, of a single ECC chunk. Note
+ *the first chunk in the page includes both data 
and
+ *metadata, so it's a bit larger than this value.
+ * @ecc_chunk_count:  The number of ECC chunks in the page,
+ * @block_mark_byte_offset:   The byte offset in the ECC-based page view at
+ *which the underlying physical block mark appears.
+ * @block_mark_bit_offset:The bit offset into the ECC-based page view at
+ *which the underlying physical block mark appears.
+ */
+struct bch_geometry {
+   unsigned int  gf_len;
+   unsigned int  ecc_strength;
+   unsigned int  ecc_chunk_size;
+   unsigned int  ecc_chunk_count;
+   unsigned int  block_mark_byte_offset;
+   unsigned int  block_mark_bit_offset;
+};
+
+struct mxs_nand_info {
+   struct nand_chip chip;
+   struct udevice *dev;
+   unsigned intmax_ecc_strength_supported;
+   booluse_minimum_ecc;
+   int cur_chip;
+
+   uint32_t

[U-Boot] [PATCH v1 7/9] mtd: nand: mxs_nand: add support for specific ECC strength

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

Add support for specified ECC strength/size using device tree
properties nand-ecc-strength/nand-ecc-step-size.

This aligns behavior with the mainline driver, such that:
- If fsl,use-minimal-ecc is requested it will use data from
  data sheet/ONFI. If this is not available the driver will fail.
- If nand-ecc-strength/nand-ecc-step-size are specified those
  value will be used.
- By default maximum possible ECC strength is used

Signed-off-by: Stefan Agner 
---

 drivers/mtd/nand/mxs_nand.c | 44 +
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 8c3f4f1871..746444d3fd 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -162,15 +162,14 @@ static inline int mxs_nand_calc_mark_offset(struct 
bch_geometry *geo,
 }
 
 static inline int mxs_nand_calc_ecc_layout_by_info(struct bch_geometry *geo,
-  struct mtd_info *mtd)
+  struct mtd_info *mtd,
+  unsigned int ecc_strength,
+  unsigned int ecc_step)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
struct mxs_nand_info *nand_info = nand_get_controller_data(chip);
 
-   if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
-   return -ENOTSUPP;
-
-   switch (chip->ecc_step_ds) {
+   switch (ecc_step) {
case SZ_512:
geo->gf_len = 13;
break;
@@ -181,8 +180,8 @@ static inline int mxs_nand_calc_ecc_layout_by_info(struct 
bch_geometry *geo,
return -EINVAL;
}
 
-   geo->ecc_chunk_size = chip->ecc_step_ds;
-   geo->ecc_strength = round_up(chip->ecc_strength_ds, 2);
+   geo->ecc_chunk_size = ecc_step;
+   geo->ecc_strength = round_up(ecc_strength, 2);
 
/* Keep the C >= O */
if (geo->ecc_chunk_size < mtd->oobsize)
@@ -965,6 +964,28 @@ static int mxs_nand_block_bad(struct mtd_info *mtd, loff_t 
ofs)
return 0;
 }
 
+static int mxs_nand_set_geometry(struct mtd_info *mtd, struct bch_geometry 
*geo)
+{
+   struct nand_chip *chip = mtd_to_nand(mtd);
+   struct nand_chip *nand = mtd_to_nand(mtd);
+   struct mxs_nand_info *nand_info = nand_get_controller_data(nand);
+
+   if (chip->ecc.strength > 0 && chip->ecc.size > 0)
+   return mxs_nand_calc_ecc_layout_by_info(geo, mtd,
+   chip->ecc.strength, chip->ecc.size);
+
+   if (nand_info->use_minimum_ecc ||
+   mxs_nand_calc_ecc_layout(geo, mtd)) {
+   if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
+   return -EINVAL;
+
+   return mxs_nand_calc_ecc_layout_by_info(geo, mtd,
+   chip->ecc_strength_ds, chip->ecc_step_ds);
+   }
+
+   return 0;
+}
+
 /*
  * At this point, the physical NAND Flash chips have been identified and
  * counted, so we know the physical geometry. This enables us to make some
@@ -981,14 +1002,9 @@ static int mxs_nand_setup_ecc(struct mtd_info *mtd)
struct bch_geometry *geo = _info->bch_geometry;
struct mxs_bch_regs *bch_regs = nand_info->bch_regs;
uint32_t tmp;
-   int ret = -ENOTSUPP;
-
-   if (nand_info->use_minimum_ecc)
-   ret = mxs_nand_calc_ecc_layout_by_info(geo, mtd);
-
-   if (ret == -ENOTSUPP)
-   ret = mxs_nand_calc_ecc_layout(geo, mtd);
+   int ret;
 
+   ret = mxs_nand_set_geometry(mtd, geo);
if (ret)
return ret;
 
-- 
2.17.0

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


[U-Boot] [PATCH v1 8/9] arm: dts: imx7: sync with Linux

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

Sync with Linux commit 60cc43fc8884 ("Linux 4.17-rc1").

Signed-off-by: Stefan Agner 
---

 arch/arm/dts/imx7s.dtsi | 491 +++-
 include/dt-bindings/clock/imx7d-clock.h |  15 +-
 include/dt-bindings/power/imx7-power.h  |  16 +
 3 files changed, 341 insertions(+), 181 deletions(-)
 create mode 100644 include/dt-bindings/power/imx7-power.h

diff --git a/arch/arm/dts/imx7s.dtsi b/arch/arm/dts/imx7s.dtsi
index a7d48e785d..4d42335c0d 100644
--- a/arch/arm/dts/imx7s.dtsi
+++ b/arch/arm/dts/imx7s.dtsi
@@ -42,6 +42,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -57,7 +58,7 @@
 * Also for U-Boot there must be a pre-existing /memory node.
 */
chosen {};
-   memory { device_type = "memory"; reg = <0 0>; };
+   memory { device_type = "memory"; };
 
aliases {
gpio0 = 
@@ -115,11 +116,77 @@
clock-output-names = "osc";
};
 
+   usbphynop1: usbphynop1 {
+   compatible = "usb-nop-xceiv";
+   clocks = < IMX7D_USB_PHY1_CLK>;
+   clock-names = "main_clk";
+   #phy-cells = <0>;
+   };
+
+   usbphynop3: usbphynop3 {
+   compatible = "usb-nop-xceiv";
+   clocks = < IMX7D_USB_HSIC_ROOT_CLK>;
+   clock-names = "main_clk";
+   #phy-cells = <0>;
+   };
+
+   pmu {
+   compatible = "arm,cortex-a7-pmu";
+   interrupt-parent = <>;
+   interrupts = ;
+   interrupt-affinity = <>;
+   };
+
+   replicator {
+   /*
+* non-configurable replicators don't show up on the
+* AMBA bus.  As such no need to add "arm,primecell"
+*/
+   compatible = "arm,coresight-replicator";
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   /* replicator output ports */
+   port@0 {
+   reg = <0>;
+   replicator_out_port0: endpoint {
+   remote-endpoint = <_in_port>;
+   };
+   };
+
+   port@1 {
+   reg = <1>;
+   replicator_out_port1: endpoint {
+   remote-endpoint = <_in_port>;
+   };
+   };
+
+   /* replicator input port */
+   port@2 {
+   reg = <0>;
+   replicator_in_port0: endpoint {
+   slave-mode;
+   remote-endpoint = <_out_port>;
+   };
+   };
+   };
+   };
+
+   timer {
+   compatible = "arm,armv7-timer";
+   interrupt-parent = <>;
+   interrupts = ,
+,
+,
+;
+   };
+
soc {
#address-cells = <1>;
#size-cells = <1>;
compatible = "simple-bus";
-   interrupt-parent = <>;
+   interrupt-parent = <>;
ranges;
 
funnel@30041000 {
@@ -259,62 +326,18 @@
};
};
 
-   replicator {
-   /*
-* non-configurable replicators don't show up on the
-* AMBA bus.  As such no need to add "arm,primecell"
-*/
-   compatible = "arm,coresight-replicator";
-
-   ports {
-   #address-cells = <1>;
-   #size-cells = <0>;
-
-   /* replicator output ports */
-   port@0 {
-   reg = <0>;
-   replicator_out_port0: endpoint {
-   remote-endpoint = 
<_in_port>;
-   };
-   };
-
-   port@1 {
-   reg = <1>;
-   replicator_out_port1: endpoint {
-   remote-endpoint = 
<_in_port>;
-   };
-   };
-
-   /* replicator input port */
-   port@2 {
-   reg = <0>;
-   replicator_in_port0: 

[U-Boot] [PATCH v1 6/9] mtd: nand: mxs_nand: add device tree support

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

Support driver data from device tree. Also support fsl,use-minimal-ecc
similar to Linux' GPMI NAND driver.

Signed-off-by: Stefan Agner 
---

 drivers/mtd/nand/Kconfig   |  7 +++
 drivers/mtd/nand/Makefile  |  1 +
 drivers/mtd/nand/mxs_nand.c|  5 ++
 drivers/mtd/nand/mxs_nand_dt.c | 86 ++
 4 files changed, 99 insertions(+)
 create mode 100644 drivers/mtd/nand/mxs_nand_dt.c

diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index c039b9cc60..bdc272142e 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -154,6 +154,13 @@ config NAND_MXS
 
 if NAND_MXS
 
+config NAND_MXS_DT
+   bool "Support MXS NAND controller as a DT device"
+   depends on OF_CONTROL && MTD
+   help
+ Enable the driver for MXS NAND flash on platforms using
+ device tree.
+
 config NAND_MXS_USE_MINIMUM_ECC
bool "Use minimum ECC strength supported by the controller"
default false
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 332d905a3a..86877e1592 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_NAND_LPC32XX_SLC) += lpc32xx_nand_slc.o
 obj-$(CONFIG_NAND_VF610_NFC) += vf610_nfc.o
 obj-$(CONFIG_NAND_MXC) += mxc_nand.o
 obj-$(CONFIG_NAND_MXS) += mxs_nand.o
+obj-$(CONFIG_NAND_MXS_DT) += mxs_nand_dt.o
 obj-$(CONFIG_NAND_PXA3XX) += pxa3xx_nand.o
 obj-$(CONFIG_NAND_SPEAR) += spr_nand.o
 obj-$(CONFIG_TEGRA_NAND) += tegra_nand.o
diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 5fbbb0a706..8c3f4f1871 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -1159,6 +1159,9 @@ int mxs_nand_init(struct mxs_nand_info *nand_info)
nand_set_controller_data(nand, nand_info);
nand->options |= NAND_NO_SUBPAGE_WRITE;
 
+   if (nand_info->dev)
+   nand->flash_node = dev_of_offset(nand_info->dev);
+
nand->cmd_ctrl  = mxs_nand_cmd_ctrl;
 
nand->dev_ready = mxs_nand_device_ready;
@@ -1206,6 +1209,7 @@ err1:
return err;
 }
 
+#ifndef CONFIG_NAND_MXS_DT
 void board_nand_init(void)
 {
struct mxs_nand_info *nand_info;
@@ -1232,3 +1236,4 @@ void board_nand_init(void)
 
mxs_nand_init(nand_info);
 }
+#endif
diff --git a/drivers/mtd/nand/mxs_nand_dt.c b/drivers/mtd/nand/mxs_nand_dt.c
new file mode 100644
index 00..c7355371ac
--- /dev/null
+++ b/drivers/mtd/nand/mxs_nand_dt.c
@@ -0,0 +1,86 @@
+/*
+ * NXP GPMI NAND flash driver (DT initialization)
+ *
+ * Copyright (C) 2018 Toradex
+ * Authors:
+ * Stefan Agner 
+ *
+ * Based on denali_dt.c
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include "mxs_nand.h"
+
+struct mxs_nand_dt_data {
+   unsigned int max_ecc_strength_supported;
+};
+
+static const struct mxs_nand_dt_data mxs_nand_imx7d_data = {
+   .max_ecc_strength_supported = 62,
+};
+
+static const struct udevice_id mxs_nand_dt_ids[] = {
+   {
+   .compatible = "fsl,imx7d-gpmi-nand",
+   .data = (unsigned long)_nand_imx7d_data,
+   },
+   { /* sentinel */ }
+};
+
+static int mxs_nand_dt_probe(struct udevice *dev)
+{
+   struct mxs_nand_info *info = dev_get_priv(dev);
+   const struct mxs_nand_dt_data *data;
+   struct resource res;
+   int ret;
+
+   data = (void *)dev_get_driver_data(dev);
+   if (data)
+   info->max_ecc_strength_supported = 
data->max_ecc_strength_supported;
+
+   info->dev = dev;
+
+   ret = dev_read_resource_byname(dev, "gpmi-nand", );
+   if (ret)
+   return ret;
+
+   info->gpmi_regs = devm_ioremap(dev, res.start, resource_size());
+
+
+   ret = dev_read_resource_byname(dev, "bch", );
+   if (ret)
+   return ret;
+
+   info->bch_regs = devm_ioremap(dev, res.start, resource_size());
+
+   info->use_minimum_ecc = dev_read_bool(dev, "fsl,use-minimum-ecc");
+
+   return mxs_nand_init(info);
+}
+
+U_BOOT_DRIVER(mxs_nand_dt) = {
+   .name = "mxs-nand-dt",
+   .id = UCLASS_MTD,
+   .of_match = mxs_nand_dt_ids,
+   .probe = mxs_nand_dt_probe,
+   .priv_auto_alloc_size = sizeof(struct mxs_nand_info),
+};
+
+void board_nand_init(void)
+{
+   struct udevice *dev;
+   int ret;
+
+   ret = uclass_get_device_by_driver(UCLASS_MTD,
+ DM_GET_DRIVER(mxs_nand_dt),
+ );
+   if (ret && ret != -ENODEV)
+   pr_err("Failed to initialize MXS NAND controller. (error %d)\n",
+  ret);
+}
-- 
2.17.0

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


[U-Boot] [PATCH v1 4/9] mtd: nand: mxs_nand: add use_minimum_ecc to struct

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

Add use_minimum_ecc as struct mxs_nand_info field in preparation
for device tree support.

Signed-off-by: Stefan Agner 
---

 drivers/mtd/nand/mxs_nand.c | 34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index b5fd0fdd62..978f6a6893 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -70,6 +70,8 @@ struct bch_geometry {
 
 struct mxs_nand_info {
struct nand_chip chip;
+   unsigned intmax_ecc_strength_supported;
+   booluse_minimum_ecc;
int cur_chip;
 
uint32_tcmd_queue_len;
@@ -214,19 +216,11 @@ static inline int mxs_nand_calc_mark_offset(struct 
bch_geometry *geo,
return 0;
 }
 
-static inline unsigned int mxs_nand_max_ecc_strength_supported(void)
-{
-   /* Refer to Chapter 17 for i.MX6DQ, Chapter 18 for i.MX6SX */
-   if (is_mx6sx() || is_mx7())
-   return 62;
-   else
-   return 40;
-}
-
 static inline int mxs_nand_calc_ecc_layout_by_info(struct bch_geometry *geo,
   struct mtd_info *mtd)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
+   struct mxs_nand_info *nand_info = nand_get_controller_data(chip);
 
if (!(chip->ecc_strength_ds > 0 && chip->ecc_step_ds > 0))
return -ENOTSUPP;
@@ -249,7 +243,7 @@ static inline int mxs_nand_calc_ecc_layout_by_info(struct 
bch_geometry *geo,
if (geo->ecc_chunk_size < mtd->oobsize)
return -EINVAL;
 
-   if (geo->ecc_strength > mxs_nand_max_ecc_strength_supported())
+   if (geo->ecc_strength > nand_info->max_ecc_strength_supported)
return -EINVAL;
 
geo->ecc_chunk_count = mtd->writesize / geo->ecc_chunk_size;
@@ -260,6 +254,9 @@ static inline int mxs_nand_calc_ecc_layout_by_info(struct 
bch_geometry *geo,
 static inline int mxs_nand_calc_ecc_layout(struct bch_geometry *geo,
   struct mtd_info *mtd)
 {
+   struct nand_chip *chip = mtd_to_nand(mtd);
+   struct mxs_nand_info *nand_info = nand_get_controller_data(chip);
+
/* The default for the length of Galois Field. */
geo->gf_len = 13;
 
@@ -291,7 +288,7 @@ static inline int mxs_nand_calc_ecc_layout(struct 
bch_geometry *geo,
/ (geo->gf_len * geo->ecc_chunk_count);
 
geo->ecc_strength = min(round_down(geo->ecc_strength, 2),
-   mxs_nand_max_ecc_strength_supported());
+   nand_info->max_ecc_strength_supported);
 
return 0;
 }
@@ -1041,9 +1038,8 @@ static int mxs_nand_setup_ecc(struct mtd_info *mtd)
uint32_t tmp;
int ret = -ENOTSUPP;
 
-#ifdef CONFIG_NAND_MXS_USE_MINIMUM_ECC
-   ret = mxs_nand_calc_ecc_layout_by_info(geo, mtd);
-#endif
+   if (nand_info->use_minimum_ecc)
+   ret = mxs_nand_calc_ecc_layout_by_info(geo, mtd);
 
if (ret == -ENOTSUPP)
ret = mxs_nand_calc_ecc_layout(geo, mtd);
@@ -1279,5 +1275,15 @@ void board_nand_init(void)
nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
 
+   /* Refer to Chapter 17 for i.MX6DQ, Chapter 18 for i.MX6SX */
+   if (is_mx6sx() || is_mx7())
+   nand_info->max_ecc_strength_supported = 62;
+   else
+   nand_info->max_ecc_strength_supported = 40;
+
+#ifdef CONFIG_NAND_MXS_USE_MINIMUM_ECC
+   nand_info->use_minimum_ecc = true;
+#endif
+
mxs_nand_init(nand_info);
 }
-- 
2.17.0

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


[U-Boot] [PATCH v1 9/9] arm: dts: imx7: colibri: add raw NAND support

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

Signed-off-by: Stefan Agner 
---

 arch/arm/dts/imx7-colibri.dts | 28 
 1 file changed, 28 insertions(+)

diff --git a/arch/arm/dts/imx7-colibri.dts b/arch/arm/dts/imx7-colibri.dts
index f6c21052ae..a3b5618b45 100644
--- a/arch/arm/dts/imx7-colibri.dts
+++ b/arch/arm/dts/imx7-colibri.dts
@@ -17,6 +17,15 @@
};
 };
 
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_gpmi_nand>;
+   fsl,use-minimum-ecc;
+   nand-on-flash-bbt;
+   nand-ecc-mode = "hw";
+   status = "okay";
+};
+
  {
pinctrl-names = "default", "gpio";
pinctrl-0 = <_i2c1>;
@@ -49,6 +58,25 @@
 };
 
  {
+   pinctrl_gpmi_nand: gpmi-nand-grp {
+   fsl,pins = <
+   MX7D_PAD_SD3_CLK__NAND_CLE  0x71
+   MX7D_PAD_SD3_CMD__NAND_ALE  0x71
+   MX7D_PAD_SAI1_TX_BCLK__NAND_CE0_B   0x71
+   MX7D_PAD_SAI1_TX_DATA__NAND_READY_B 0x74
+   MX7D_PAD_SD3_STROBE__NAND_RE_B  0x71
+   MX7D_PAD_SD3_RESET_B__NAND_WE_B 0x71
+   MX7D_PAD_SD3_DATA0__NAND_DATA00 0x71
+   MX7D_PAD_SD3_DATA1__NAND_DATA01 0x71
+   MX7D_PAD_SD3_DATA2__NAND_DATA02 0x71
+   MX7D_PAD_SD3_DATA3__NAND_DATA03 0x71
+   MX7D_PAD_SD3_DATA4__NAND_DATA04 0x71
+   MX7D_PAD_SD3_DATA5__NAND_DATA05 0x71
+   MX7D_PAD_SD3_DATA6__NAND_DATA06 0x71
+   MX7D_PAD_SD3_DATA7__NAND_DATA07 0x71
+   >;
+   };
+
pinctrl_i2c4: i2c4-grp {
fsl,pins = <
MX7D_PAD_ENET1_RGMII_TD3__I2C4_SDA  0x407f
-- 
2.17.0

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


[U-Boot] [PATCH v1 1/9] mtd: nand: mxs_nand: move register structs to driver data

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

Move GPMI and BCH register structs to the driver struct mxs_nand_info
in prepartion for device tree support.

Signed-off-by: Stefan Agner 
---

 drivers/mtd/nand/mxs_nand.c | 32 +++-
 1 file changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 8305bf2302..f619a2f139 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -83,6 +83,9 @@ struct mxs_nand_info {
uint8_t marking_block_bad;
uint8_t raw_oob_mode;
 
+   struct mxs_gpmi_regs *gpmi_regs;
+   struct mxs_bch_regs *bch_regs;
+
/* Functions with altered behaviour */
int (*hooked_read_oob)(struct mtd_info *mtd,
loff_t from, struct mtd_oob_ops *ops);
@@ -296,16 +299,15 @@ static inline int mxs_nand_calc_ecc_layout(struct 
bch_geometry *geo,
 /*
  * Wait for BCH complete IRQ and clear the IRQ
  */
-static int mxs_nand_wait_for_bch_complete(void)
+static int mxs_nand_wait_for_bch_complete(struct mxs_nand_info *nand_info)
 {
-   struct mxs_bch_regs *bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
int timeout = MXS_NAND_BCH_TIMEOUT;
int ret;
 
-   ret = mxs_wait_mask_set(_regs->hw_bch_ctrl_reg,
+   ret = mxs_wait_mask_set(_info->bch_regs->hw_bch_ctrl_reg,
BCH_CTRL_COMPLETE_IRQ, timeout);
 
-   writel(BCH_CTRL_COMPLETE_IRQ, _regs->hw_bch_ctrl_clr);
+   writel(BCH_CTRL_COMPLETE_IRQ, _info->bch_regs->hw_bch_ctrl_clr);
 
return ret;
 }
@@ -403,11 +405,9 @@ static int mxs_nand_device_ready(struct mtd_info *mtd)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
struct mxs_nand_info *nand_info = nand_get_controller_data(chip);
-   struct mxs_gpmi_regs *gpmi_regs =
-   (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
uint32_t tmp;
 
-   tmp = readl(_regs->hw_gpmi_stat);
+   tmp = readl(_info->gpmi_regs->hw_gpmi_stat);
tmp >>= (GPMI_STAT_READY_BUSY_OFFSET + nand_info->cur_chip);
 
return tmp & 1;
@@ -704,7 +704,7 @@ static int mxs_nand_ecc_read_page(struct mtd_info *mtd, 
struct nand_chip *nand,
goto rtn;
}
 
-   ret = mxs_nand_wait_for_bch_complete();
+   ret = mxs_nand_wait_for_bch_complete(nand_info);
if (ret) {
printf("MXS NAND: BCH read timeout\n");
goto rtn;
@@ -812,7 +812,7 @@ static int mxs_nand_ecc_write_page(struct mtd_info *mtd,
goto rtn;
}
 
-   ret = mxs_nand_wait_for_bch_complete();
+   ret = mxs_nand_wait_for_bch_complete(nand_info);
if (ret) {
printf("MXS NAND: BCH write timeout\n");
goto rtn;
@@ -1037,7 +1037,7 @@ static int mxs_nand_setup_ecc(struct mtd_info *mtd)
struct nand_chip *nand = mtd_to_nand(mtd);
struct mxs_nand_info *nand_info = nand_get_controller_data(nand);
struct bch_geometry *geo = _info->bch_geometry;
-   struct mxs_bch_regs *bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
+   struct mxs_bch_regs *bch_regs = nand_info->bch_regs;
uint32_t tmp;
int ret = -ENOTSUPP;
 
@@ -1138,10 +1138,6 @@ int mxs_nand_alloc_buffers(struct mxs_nand_info 
*nand_info)
  */
 int mxs_nand_init(struct mxs_nand_info *info)
 {
-   struct mxs_gpmi_regs *gpmi_regs =
-   (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
-   struct mxs_bch_regs *bch_regs =
-   (struct mxs_bch_regs *)MXS_BCH_BASE;
int i = 0, j, ret = 0;
 
info->desc = malloc(sizeof(struct mxs_dma_desc *) *
@@ -1170,14 +1166,14 @@ int mxs_nand_init(struct mxs_nand_info *info)
}
 
/* Reset the GPMI block. */
-   mxs_reset_block(_regs->hw_gpmi_ctrl0_reg);
-   mxs_reset_block(_regs->hw_bch_ctrl_reg);
+   mxs_reset_block(>gpmi_regs->hw_gpmi_ctrl0_reg);
+   mxs_reset_block(>bch_regs->hw_bch_ctrl_reg);
 
/*
 * Choose NAND mode, set IRQ polarity, disable write protection and
 * select BCH ECC.
 */
-   clrsetbits_le32(_regs->hw_gpmi_ctrl1,
+   clrsetbits_le32(>gpmi_regs->hw_gpmi_ctrl1,
GPMI_CTRL1_GPMI_MODE,
GPMI_CTRL1_ATA_IRQRDY_POLARITY | GPMI_CTRL1_DEV_RESET |
GPMI_CTRL1_BCH_MODE);
@@ -1211,6 +1207,8 @@ void board_nand_init(void)
}
memset(nand_info, 0, sizeof(struct mxs_nand_info));
 
+   nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
+   nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
nand = _info->chip;
mtd = nand_to_mtd(nand);
err = mxs_nand_alloc_buffers(nand_info);
-- 
2.17.0

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


[U-Boot] [PATCH v1 3/9] mtd: nand: mxs_nand: separate board/controller init

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

In preparation for device tree support separate board init
from controller init similar to other raw NAND drivers.

Signed-off-by: Stefan Agner 
---

 drivers/mtd/nand/mxs_nand.c | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index 3f97da5e8f..b5fd0fdd62 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -1193,22 +1193,12 @@ err1:
return ret;
 }
 
-void board_nand_init(void)
+int mxs_nand_init(struct mxs_nand_info *nand_info)
 {
struct mtd_info *mtd;
-   struct mxs_nand_info *nand_info;
struct nand_chip *nand;
int err;
 
-   nand_info = malloc(sizeof(struct mxs_nand_info));
-   if (!nand_info) {
-   printf("MXS NAND: Failed to allocate private data\n");
-   return;
-   }
-   memset(nand_info, 0, sizeof(struct mxs_nand_info));
-
-   nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
-   nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
nand = _info->chip;
mtd = nand_to_mtd(nand);
err = mxs_nand_alloc_buffers(nand_info);
@@ -1265,12 +1255,29 @@ void board_nand_init(void)
if (err)
goto err2;
 
-   return;
+   return 0;
 
 err2:
free(nand_info->data_buf);
free(nand_info->cmd_buf);
 err1:
free(nand_info);
-   return;
+   return err;
+}
+
+void board_nand_init(void)
+{
+   struct mxs_nand_info *nand_info;
+
+   nand_info = malloc(sizeof(struct mxs_nand_info));
+   if (!nand_info) {
+   printf("MXS NAND: Failed to allocate private data\n");
+   return;
+   }
+   memset(nand_info, 0, sizeof(struct mxs_nand_info));
+
+   nand_info->gpmi_regs = (struct mxs_gpmi_regs *)MXS_GPMI_BASE;
+   nand_info->bch_regs = (struct mxs_bch_regs *)MXS_BCH_BASE;
+
+   mxs_nand_init(nand_info);
 }
-- 
2.17.0

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


[U-Boot] [PATCH v1 2/9] mtd: nand: mxs_nand: use more precise function name

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

This function initializes DMA descriptors so mxs_nand_init_dma is
more precise. It also frees up the rather generic name mxs_nand_init.

Signed-off-by: Stefan Agner 
---

 drivers/mtd/nand/mxs_nand.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/mxs_nand.c b/drivers/mtd/nand/mxs_nand.c
index f619a2f139..3f97da5e8f 100644
--- a/drivers/mtd/nand/mxs_nand.c
+++ b/drivers/mtd/nand/mxs_nand.c
@@ -1136,7 +1136,7 @@ int mxs_nand_alloc_buffers(struct mxs_nand_info 
*nand_info)
 /*
  * Initializes the NFC hardware.
  */
-int mxs_nand_init(struct mxs_nand_info *info)
+int mxs_nand_init_dma(struct mxs_nand_info *info)
 {
int i = 0, j, ret = 0;
 
@@ -1215,7 +1215,7 @@ void board_nand_init(void)
if (err)
goto err1;
 
-   err = mxs_nand_init(nand_info);
+   err = mxs_nand_init_dma(nand_info);
if (err)
goto err2;
 
-- 
2.17.0

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


[U-Boot] [PATCH v1 0/9] mtd: nand: mxs_nand: add device tree support

2018-04-20 Thread Stefan Agner
From: Stefan Agner 

This patchset adds device tree support to the MXS NAND driver.
This also allows to use fixed ECC strenght usingt he device
tree properties nand-ecc-strength/nand-ecc-step-size and aligns
behavior with the Linux GPMI NAND driver.

This is based on the "mtd: nand: mxs_nand: improve ECC support"
patchset:
https://patchwork.ozlabs.org/cover/897263/

Support for nand-ecc-strength/nand-ecc-step-size has recently
been added in Linux, see:
https://patchwork.kernel.org/patch/10257829/

This patchset has been tested with various ECC configurations
on a Colibri iMX7.

--
Stefan


Stefan Agner (9):
  mtd: nand: mxs_nand: move register structs to driver data
  mtd: nand: mxs_nand: use more precise function name
  mtd: nand: mxs_nand: separate board/controller init
  mtd: nand: mxs_nand: add use_minimum_ecc to struct
  mtd: nand: mxs_nand: create separate header file
  mtd: nand: mxs_nand: add device tree support
  mtd: nand: mxs_nand: add support for specific ECC strength
  arm: dts: imx7: sync with Linux
  arm: dts: imx7: colibri: add raw NAND support

 arch/arm/dts/imx7-colibri.dts   |  28 ++
 arch/arm/dts/imx7s.dtsi | 491 +++-
 drivers/mtd/nand/Kconfig|   7 +
 drivers/mtd/nand/Makefile   |   1 +
 drivers/mtd/nand/mxs_nand.c | 195 +-
 drivers/mtd/nand/mxs_nand.h |  72 
 drivers/mtd/nand/mxs_nand_dt.c  |  86 +
 include/dt-bindings/clock/imx7d-clock.h |  15 +-
 include/dt-bindings/power/imx7-power.h  |  16 +
 9 files changed, 621 insertions(+), 290 deletions(-)
 create mode 100644 drivers/mtd/nand/mxs_nand.h
 create mode 100644 drivers/mtd/nand/mxs_nand_dt.c
 create mode 100644 include/dt-bindings/power/imx7-power.h

-- 
2.17.0

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


Re: [U-Boot] [PATCH] board: freescale: ls1012ardb: Add command to switch QSPI bank

2018-04-20 Thread Scott Wood
On Fri, 2018-04-20 at 03:16 +, Prabhakar Kushwaha wrote:
> Thanks Scott for reviewing this patch
> 
> > -Original Message-
> > From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Scott
> > Wood
> > Sent: Friday, April 20, 2018 6:40 AM
> > To: Calvin Johnson 
> > Cc: U-Boot Mailing List 
> > Subject: Re: [U-Boot] [PATCH] board: freescale: ls1012ardb: Add command to
> > switch QSPI bank
> > 
> > On Thu, 2018-04-19 at 14:09 +0530, Calvin Johnson wrote:
> > > On Thu, Apr 19, 2018 at 12:17 PM, Scott Wood  wrote:
> > > > On Mon, 2018-04-16 at 08:40 +0530, Calvin Johnson wrote:
> > > > > On Fri, Apr 13, 2018 at 12:18 AM, Jagdish Gediya
> > > > >  > > > > > 
> > > > > 
> > > > > wrote:
> > > > > > Add command "boot_bank X" to switch the boot bank to either
> > > > > > 1 or 2.
> > > > > 
> > > > > Are these functions required as this can be handled by new env
> > > > > vars to switch banks?
> > > > 
> > > > If you're going to add something new, a command is much more
> > > > pleasant than env vars -- particularly if you stick to something
> > > > like the familiar interfaces ("pix altbank", "qix altbank", etc),
> > > > and include reporting of which bank was booted from if it's not
> > > > there already.  Of course, a fully standardized interface would be
> > > > even better.
> > > 
> > > Yes, a fully standardized generic interface supporting all similar
> > > platforms with multiple banks
> > 
> > And other boot sources such as NAND and MMC.
> 
> 
> LS1012A has only one boot source i.e. QSPI

I meant that if there is any effort to standardize the command it should
support multiple boot sources, not just bank selection.

-Scott

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


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Jorge Ramirez-Ortiz

On 04/20/2018 03:46 PM, Ramon Fried wrote:

On 20 April 2018 at 14:50, Jorge Ramirez-Ortiz  wrote:

On 04/20/2018 01:22 PM, Ramon Fried wrote:

On 20 April 2018 at 14:14, Jorge Ramirez-Ortiz 
wrote:

On 04/20/2018 01:02 PM, Ramon Fried wrote:

On 18 April 2018 at 13:15, Jorge Ramirez-Ortiz 
wrote:

On 04/18/2018 09:02 AM, Jorge Ramirez-Ortiz wrote:

On 04/17/2018 02:01 PM, Ramon Fried wrote:

The clock node is used by the serial driver and it's needed
before relocation.
This patch ensures that the msm-serial driver can actually
use the clock node.

Signed-off-by: Ramon Fried 
---
 arch/arm/dts/dragonboard410c.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/dragonboard410c.dts
b/arch/arm/dts/dragonboard410c.dts
index 5ccfe7f8c8..f37ef5d523 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -38,12 +38,14 @@
 #size-cells = <0x1>;
 ranges = <0x0 0x0 0x0 0x>;
 compatible = "simple-bus";
+u-boot,dm-pre-reloc;


I think the intent is to make dm-pre-reloc legacy.
New platforms should be using "u-boot,dm-spl" even if CONFIG_SPL_BUILD
is
not enabled (I believe it should work)


   clkc: qcom,gcc@180 {
 compatible = "qcom,gcc-apq8016";
 reg = <0x180 0x8>;
 #address-cells = <0x1>;
 #size-cells = <0x0>;
+u-boot,dm-pre-reloc;
 };
   serial@78b {



another question is, how will you probe the clock driver before the
uart?
I think even if you probed in misc_init_f it is already too late.

other than that - + Peter Robinson's comments- looks good.


The clock is probed because the uart driver asks for it. it's actually
already exists in the code, but wasn't used because
the clock wasn't set to dm-pre-reloc


um, are you sure? that is not what I see during my tests but I could be
wrong - or something else might be happening in uboot

you can create a misc_init_f for the board that retrieves the clock
driver
by name and forces a probe; I can see that the probe happens (ie, the
DM_FLAG_ACTIVATED was _not_ set for that driver) which is not what I
believe
you expect since you want the clock driver to be probed before the uart.

It doesn't need to be probed before the uart, the uart is probed first
and when it asks for the
clock node it's forcing a probe. it's tested.


can you post a trace. just dump the value of GD_FLG_RELOC on clock the probe
function.

The serial isn't  initialized at this time, I'll save the value and
print afterwards :)


of course.
 I think it makes sense to add some debug statement near 
DM_FLAG_ACTIVATED in device_probe...the driver should not be probed a 
second time if it was successfully probed early before relocation




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


Re: [U-Boot] [RFC PATCH v1 0/1] Migrate IMAGE_FORMAT_LEGACY to Kconfig

2018-04-20 Thread Tom Rini
On Fri, Apr 20, 2018 at 10:46:00AM +0100, Alex Kiernan wrote:
> On Fri, Apr 20, 2018 at 5:23 AM, Alex Kiernan  wrote:
> > On Thu, Apr 19, 2018 at 8:39 PM, Tom Rini  wrote:
> >> On Thu, Apr 19, 2018 at 04:52:30AM +, Alex Kiernan wrote:
> >>>
> >>> On the face of it, this is a straightforward moveconfig, but because
> >>> of how CONFIG_FIT_SIGNATURE, CONFIG_IMAGE_FORMAT_LEGACY and
> >>> CONFIG_DISABLE_IMAGE_LEGACY interacted when you enabled
> >>> CONFIG_FIT_SIGNATURE, you got CONFIG_IMAGE_FORMAT_LEGACY disabled
> >>> immediately unless you had some way of explicitly enabling it
> >>> elsewhere.
> >>>
> >>> Kconfig doesn't give us this - CONFIG_IMAGE_FORMAT_LEGACY starts off
> >>> enabled, CONFIG_FIT_SIGNATURE starts off disabled and if you enable
> >>> CONFIG_FIT_SIGNATURE then CONFIG_IMAGE_FORMAT_LEGACY stays enabled.
> >>>
> >>> Is there some way to preserve the existing behaviour through Kconfig
> >>> that I've failed to figure out?
> >>
> >> When I do these, it's a multi-step moveconfig.py that goes something
> >> like:
> >> - Introduce FOO (no deps)
> >> - moveconfig.py -y it.
> >> - Introduce BAR (no deps)
> >> - moveconfig.py -y it.
> >> - for FILE in configs/*defconfig;do grep -q FOO $FILE || echo '#
> >>   CONFIG_FOO is not set' >> $FILE;done
> >> - Repeat the for loop but for BAR.
> >> - Introduce deps
> >> - moveconfig.py -sC
> >> - Build before/after for a few boards that I know are tricky, use
> >>   buildman -SCvel/Ssdel to confirm size changes didn't happen.
> >> - If good, world-build checking sizes.
> >>
> >> And in some cases like this particular one, there might need to be an
> >> initial first comment to invert the logic, and as that can be tricky
> >> when adding a new option that _should_ be default y, first I add it
> >> without default y, moveconfig.py -y it, for loop like above, then add
> >> default y and moveconfig.py -s.
> >>
> >
> > Thanks, let me give that a go...
> >
> 
> Having gone through that piece by piece, I'm pretty sure that
> moveconfig has actually done the right thing. We've these
> configurations which enable FIT_SIGNATURE without IMAGE_FORMAT_LEGACY:
> 
> am335x_boneblack_vboot_defconfig
> conga-qeval20-qa3-e3845_defconfig
> conga-qeval20-qa3-e3845-internal-uart_defconfig
> controlcenterdc_defconfig
> dfi-bt700-q7x-151_defconfig
> minnowmax_defconfig
> sandbox64_defconfig
> sandbox_defconfig
> sandbox_flattree_defconfig
> sandbox_noblk_defconfig
> sandbox_spl_defconfig
> som-db5800-som-6867_defconfig
> theadorable-x86-conga-qa3-e3845_defconfig
> theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
> theadorable-x86-dfi-bt700_defconfig
> 
> And checking each of them, they're IMAGE_FORMAT_LEGACY disabled after
> the conversion.
> 
> I'll hang fire on sending a non-RFC v2 to see if there's any more comments.

I think you have it right as well, thanks!

-- 
Tom


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


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

2018-04-20 Thread Michal Simek

 diff --git a/configs/xilinx_zynqmp_r5_defconfig
 b/configs/xilinx_zynqmp_r5_defconfig
 new file mode 100644
 index ..46715242e703
 --- /dev/null
 +++ b/configs/xilinx_zynqmp_r5_defconfig
 @@ -0,0 +1,16 @@
 +CONFIG_ARM=y
 +CONFIG_ARCH_ZYNQMP_R5=y
 +CONFIG_SYS_TEXT_BASE=0x1000
>>>
>>> You may want to document somewhere what this address is. Is this OCM? Is
>>> this DDR? Is this the super-fast local RAM of the R5?
>>
>> In commit message it is written about DDR but maybe it can be more
>> explicitly said.
> 
> The history is almost invisible when looking at the code itself once things 
> are committed to the tree. So yes, a comment or readme in-tree would be good.

I have extended commit message. Normally you run blame for that line
which setup that address and then looking at commit message.

 +CONFIG_DEFAULT_DEVICE_TREE="zynqmp-r5"
 +CONFIG_DEBUG_UART=y
 +# CONFIG_DISPLAY_CPUINFO is not set
 +CONFIG_SYS_PROMPT="ZynqMP r5> "
 +# CONFIG_CMD_FLASH is not set
 +# CONFIG_CMD_SETEXPR is not set
 +CONFIG_OF_EMBED=y
 +CONFIG_DEBUG_UART_ZYNQ=y
 +CONFIG_DEBUG_UART_BASE=0xff01
 +CONFIG_DEBUG_UART_CLOCK=1
 +CONFIG_ZYNQ_SERIAL=y
 +CONFIG_TIMER=y
 +CONFIG_CADENCE_TTC_TIMER=y
 diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig
 index 3d5b2bf15f08..3292edbaf240 100644
 --- a/drivers/serial/Kconfig
 +++ b/drivers/serial/Kconfig
 @@ -617,7 +617,7 @@ config STM32_SERIAL
 config ZYNQ_SERIAL
   bool "Cadence (Xilinx Zynq) UART support"
 -depends on DM_SERIAL && (MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP)
 +depends on DM_SERIAL && (MICROBLAZE || ARCH_ZYNQ || ARCH_ZYNQMP
 || ARCH_ZYNQMP_R5)
>>>
>>> I'm sure there are more drivers that could be accessed from the R5
>>> instead, right?
>>
>> I would expect that but it needs to be tested which is not at this
>> stage. This is minimal support with DDR/timer/serial which is enough for
>> now.
> 
> I think a quick git grep -e on depends.*ARCH_ZYNQMP would make sense at this 
> stage already. Otherwise people will just fall into traps later on.

When that driver is tested it can be enabled. It is also a question if
make sense to protect these drivers with DM in place.

> 
>>
>>
>>>
>>> Either way, I'm happy to see this port - looks like great work :)
>>
>> Happy to see any your tag to write it to the history.
> 
> I don‘t tag RFCs :). For the next (non-RFC) version, I‘ll be happy to do so.

v1 out.

Thanks,
Michal


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


Re: [U-Boot] [PULL] u-boot-sh/master

2018-04-20 Thread Tom Rini
On Fri, Apr 20, 2018 at 03:46:00PM +0200, Marek Vasut wrote:
> On 04/19/2018 05:14 AM, Tom Rini wrote:
> > On Wed, Apr 18, 2018 at 09:57:19PM +0200, Marek Vasut wrote:
> > 
> >> The following changes since commit 
> >> 8c0a17be0a632b9a823e14628c42f85c3e64f08e:
> >>
> >>   Prepare v2018.05-rc2 (2018-04-16 20:00:14 -0400)
> >>
> >> are available in the Git repository at:
> >>
> >>   git://git.denx.de/u-boot-sh.git master
> >>
> >> for you to fetch changes up to 7d0299cd8f11f33910f15531913ff2e3d1621bda:
> >>
> >>   ARM: rmobile: Update M2 Koelsch (2018-04-17 20:19:57 +0200)
> >>
> > 
> > Applied to u-boot/master, thanks!
> 
> Are you sure? I don't see it in master

Ah yes, thanks for the reminder.  The denx side had a hiccup at the time
and I forgot to re-push in the morning.

-- 
Tom


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


[U-Boot] [PATCH 2/2] arm: zynqmp: Add ZynqMP minimal R5 support

2018-04-20 Thread Michal Simek
Xilinx ZynqMP also contains dual Cortex R5 which can run U-Boot.
This patch is adding minimal support to get U-Boot boot.
U-Boot on R5 runs out of DDR with default configuration that's why
DDR needs to be partitioned if there is something else running on arm64.
Console is done via Cadence uart driver and the first Cadence Triple
Timer Counter is used for time.

This configuration with uart1 was tested on zcu100-revC.

U-Boot 2018.05-rc2-00021-gd058a08d907d (Apr 18 2018 - 14:11:27 +0200)

Model: Xilinx ZynqMP R5
DRAM:  512 MiB
WARNING: Caches not enabled
MMC:
In:serial@ff01
Out:   serial@ff01
Err:   serial@ff01
Net:   Net Initialization Skipped
No ethernet found.
ZynqMP r5>

There are two ways how to run this on ZynqMP.
1. Run from ZynqMP arm64
tftpb 2000 u-boot-r5.elf
setenv autostart no && bootelf -p 2000
cpu 4 disable && cpu 4 release 1000 lockstep
or
cpu 4 disable && cpu 4 release 1000 split

2. Load via jtag when directly to R5

Signed-off-by: Michal Simek 
---

Changes compare to RFC
- Use 500MHz instead of 600MHz
- Remove fpu compilation flags
- Split arm-r5 code and platform
---
 MAINTAINERS|  6 +++
 arch/arm/Kconfig   | 10 
 arch/arm/Makefile  |  1 +
 arch/arm/dts/Makefile  |  2 +
 arch/arm/dts/zynqmp-r5.dts | 73 ++
 arch/arm/mach-zynqmp-r5/Kconfig| 27 +++
 arch/arm/mach-zynqmp-r5/Makefile   |  3 ++
 arch/arm/mach-zynqmp-r5/cpu.c  | 15 ++
 board/xilinx/zynqmp_r5/MAINTAINERS |  7 +++
 board/xilinx/zynqmp_r5/Makefile|  6 +++
 board/xilinx/zynqmp_r5/board.c | 25 ++
 configs/xilinx_zynqmp_r5_defconfig | 16 +++
 drivers/serial/Kconfig |  2 +-
 include/configs/xilinx_zynqmp_r5.h | 49 
 14 files changed, 241 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/zynqmp-r5.dts
 create mode 100644 arch/arm/mach-zynqmp-r5/Kconfig
 create mode 100644 arch/arm/mach-zynqmp-r5/Makefile
 create mode 100644 arch/arm/mach-zynqmp-r5/cpu.c
 create mode 100644 board/xilinx/zynqmp_r5/MAINTAINERS
 create mode 100644 board/xilinx/zynqmp_r5/Makefile
 create mode 100644 board/xilinx/zynqmp_r5/board.c
 create mode 100644 configs/xilinx_zynqmp_r5_defconfig
 create mode 100644 include/configs/xilinx_zynqmp_r5.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 147551f66fd3..e60d76dbad8a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -295,6 +295,12 @@ F: include/zynqmppl.h
 F: tools/zynqimage.c
 N: zynqmp
 
+ARM ZYNQMP R5
+M: Michal Simek 
+S: Maintained
+T: git git://git.denx.de/u-boot-microblaze.git
+F: arch/arm/mach-zynqmp-r5/
+
 BUILDMAN
 M: Simon Glass 
 S: Maintained
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b10804f55224..e09ab487b7d0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -771,6 +771,14 @@ config ARCH_ZYNQ
imply CMD_SPL
imply ARCH_EARLY_INIT_R
 
+config ARCH_ZYNQMP_R5
+   bool "Xilinx ZynqMP R5 based platform"
+   select CPU_V7R
+   select OF_CONTROL
+   select DM
+   select DM_SERIAL
+   select CLK
+
 config ARCH_ZYNQMP
bool "Xilinx ZynqMP based platform"
select ARM64
@@ -1289,6 +1297,8 @@ source "arch/arm/cpu/armv7/vf610/Kconfig"
 
 source "arch/arm/mach-zynq/Kconfig"
 
+source "arch/arm/mach-zynqmp-r5/Kconfig"
+
 source "arch/arm/cpu/armv7/Kconfig"
 
 source "arch/arm/cpu/armv8/zynqmp/Kconfig"
diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index 4fa8b38397d9..b4b45f3c6328 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -76,6 +76,7 @@ machine-$(CONFIG_ARCH_STM32MP)+= stm32mp
 machine-$(CONFIG_TEGRA)+= tegra
 machine-$(CONFIG_ARCH_UNIPHIER)+= uniphier
 machine-$(CONFIG_ARCH_ZYNQ)+= zynq
+machine-$(CONFIG_ARCH_ZYNQMP_R5)   += zynqmp-r5
 
 machdirs := $(patsubst %,arch/arm/mach-%/,$(machine-y))
 
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 1fb36b3ecdb3..d44a4310081e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -165,6 +165,8 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
zynqmp-zc1751-xm017-dc3.dtb \
zynqmp-zc1751-xm018-dc4.dtb \
zynqmp-zc1751-xm019-dc5.dtb
+dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \
+   zynqmp-r5.dtb
 dtb-$(CONFIG_AM33XX) += am335x-boneblack.dtb am335x-bone.dtb \
am335x-draco.dtb \
am335x-evm.dtb \
diff --git a/arch/arm/dts/zynqmp-r5.dts b/arch/arm/dts/zynqmp-r5.dts
new file mode 100644
index ..ba4d66a167c2
--- /dev/null
+++ b/arch/arm/dts/zynqmp-r5.dts
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * dts file for Xilinx ZynqMP R5
+ *
+ * (C) Copyright 2018, Xilinx, Inc.
+ *
+ * Michal Simek 
+ */
+
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   

[U-Boot] [PATCH 1/2] arm: Add minimal support for Cortex-R5

2018-04-20 Thread Michal Simek
This minimal support will be used by Xilinx ZynqMP R5 cpu.

Signed-off-by: Michal Simek 
---

 arch/arm/Kconfig  |  6 ++
 arch/arm/cpu/armv7r/Makefile  |  4 
 arch/arm/cpu/armv7r/config.mk |  3 +++
 arch/arm/cpu/armv7r/cpu.c | 24 
 arch/arm/cpu/armv7r/start.S   | 17 +
 5 files changed, 54 insertions(+)
 create mode 100644 arch/arm/cpu/armv7r/Makefile
 create mode 100644 arch/arm/cpu/armv7r/config.mk
 create mode 100644 arch/arm/cpu/armv7r/cpu.c
 create mode 100644 arch/arm/cpu/armv7r/start.S

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index b5fbce03667d..b10804f55224 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -192,6 +192,10 @@ config CPU_V7M
select THUMB2_KERNEL
select SYS_CACHE_SHIFT_5
 
+config CPU_V7R
+   bool
+   select SYS_CACHE_SHIFT_6
+
 config CPU_PXA
bool
select SYS_CACHE_SHIFT_5
@@ -209,6 +213,7 @@ config SYS_CPU
default "arm1176" if CPU_ARM1176
default "armv7" if CPU_V7
default "armv7m" if CPU_V7M
+   default "armv7r" if CPU_V7R
default "pxa" if CPU_PXA
default "sa1100" if CPU_SA1100
default "armv8" if ARM64
@@ -223,6 +228,7 @@ config SYS_ARM_ARCH
default 6 if CPU_ARM1176
default 7 if CPU_V7
default 7 if CPU_V7M
+   default 7 if CPU_V7R
default 5 if CPU_PXA
default 4 if CPU_SA1100
default 8 if ARM64
diff --git a/arch/arm/cpu/armv7r/Makefile b/arch/arm/cpu/armv7r/Makefile
new file mode 100644
index ..3c66976dfa62
--- /dev/null
+++ b/arch/arm/cpu/armv7r/Makefile
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+extra-y := start.o
+obj-y += cpu.o
diff --git a/arch/arm/cpu/armv7r/config.mk b/arch/arm/cpu/armv7r/config.mk
new file mode 100644
index ..224d191ff846
--- /dev/null
+++ b/arch/arm/cpu/armv7r/config.mk
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0
+
+PLATFORM_CPPFLAGS += -mcpu=cortex-r5 -DARMR5
diff --git a/arch/arm/cpu/armv7r/cpu.c b/arch/arm/cpu/armv7r/cpu.c
new file mode 100644
index ..e384a530c5e0
--- /dev/null
+++ b/arch/arm/cpu/armv7r/cpu.c
@@ -0,0 +1,24 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * (C) Copyright 2018 Xilinx, Inc. (Michal Simek)
+ */
+
+#include 
+
+/*
+ * This is called right before passing control to
+ * the Linux kernel point.
+ */
+int cleanup_before_linux(void)
+{
+   return 0;
+}
+
+/*
+ * Perform the low-level reset.
+ */
+void reset_cpu(ulong addr)
+{
+   while (1)
+   ;
+}
diff --git a/arch/arm/cpu/armv7r/start.S b/arch/arm/cpu/armv7r/start.S
new file mode 100644
index ..d6e8eecf54b7
--- /dev/null
+++ b/arch/arm/cpu/armv7r/start.S
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * (C) Copyright 2015
+ * Kamil Lulko, 
+ *
+ */
+
+#include 
+
+.globl reset
+.type reset, %function
+reset:
+   W(b)_main
+
+.globl c_runtime_cpu_setup
+c_runtime_cpu_setup:
+   mov pc, lr
-- 
2.17.0

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


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Ramon Fried
On 20 April 2018 at 14:50, Jorge Ramirez-Ortiz  wrote:
> On 04/20/2018 01:22 PM, Ramon Fried wrote:
>>
>> On 20 April 2018 at 14:14, Jorge Ramirez-Ortiz 
>> wrote:
>>>
>>> On 04/20/2018 01:02 PM, Ramon Fried wrote:

 On 18 April 2018 at 13:15, Jorge Ramirez-Ortiz 
 wrote:
>
> On 04/18/2018 09:02 AM, Jorge Ramirez-Ortiz wrote:
>>
>> On 04/17/2018 02:01 PM, Ramon Fried wrote:
>>>
>>> The clock node is used by the serial driver and it's needed
>>> before relocation.
>>> This patch ensures that the msm-serial driver can actually
>>> use the clock node.
>>>
>>> Signed-off-by: Ramon Fried 
>>> ---
>>> arch/arm/dts/dragonboard410c.dts | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/dragonboard410c.dts
>>> b/arch/arm/dts/dragonboard410c.dts
>>> index 5ccfe7f8c8..f37ef5d523 100644
>>> --- a/arch/arm/dts/dragonboard410c.dts
>>> +++ b/arch/arm/dts/dragonboard410c.dts
>>> @@ -38,12 +38,14 @@
>>> #size-cells = <0x1>;
>>> ranges = <0x0 0x0 0x0 0x>;
>>> compatible = "simple-bus";
>>> +u-boot,dm-pre-reloc;
>>
>>
>> I think the intent is to make dm-pre-reloc legacy.
>> New platforms should be using "u-boot,dm-spl" even if CONFIG_SPL_BUILD
>> is
>> not enabled (I believe it should work)
>>
>>>   clkc: qcom,gcc@180 {
>>> compatible = "qcom,gcc-apq8016";
>>> reg = <0x180 0x8>;
>>> #address-cells = <0x1>;
>>> #size-cells = <0x0>;
>>> +u-boot,dm-pre-reloc;
>>> };
>>>   serial@78b {
>>
>>
> another question is, how will you probe the clock driver before the
> uart?
> I think even if you probed in misc_init_f it is already too late.
>
> other than that - + Peter Robinson's comments- looks good.
>
 The clock is probed because the uart driver asks for it. it's actually
 already exists in the code, but wasn't used because
 the clock wasn't set to dm-pre-reloc
>>>
>>>
>>> um, are you sure? that is not what I see during my tests but I could be
>>> wrong - or something else might be happening in uboot
>>>
>>> you can create a misc_init_f for the board that retrieves the clock
>>> driver
>>> by name and forces a probe; I can see that the probe happens (ie, the
>>> DM_FLAG_ACTIVATED was _not_ set for that driver) which is not what I
>>> believe
>>> you expect since you want the clock driver to be probed before the uart.
>>
>> It doesn't need to be probed before the uart, the uart is probed first
>> and when it asks for the
>> clock node it's forcing a probe. it's tested.
>
>
> can you post a trace. just dump the value of GD_FLG_RELOC on clock the probe
> function.
The serial isn't  initialized at this time, I'll save the value and
print afterwards :)
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PULL] u-boot-sh/master

2018-04-20 Thread Marek Vasut
On 04/19/2018 05:14 AM, Tom Rini wrote:
> On Wed, Apr 18, 2018 at 09:57:19PM +0200, Marek Vasut wrote:
> 
>> The following changes since commit 8c0a17be0a632b9a823e14628c42f85c3e64f08e:
>>
>>   Prepare v2018.05-rc2 (2018-04-16 20:00:14 -0400)
>>
>> are available in the Git repository at:
>>
>>   git://git.denx.de/u-boot-sh.git master
>>
>> for you to fetch changes up to 7d0299cd8f11f33910f15531913ff2e3d1621bda:
>>
>>   ARM: rmobile: Update M2 Koelsch (2018-04-17 20:19:57 +0200)
>>
> 
> Applied to u-boot/master, thanks!

Are you sure? I don't see it in master

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


[U-Boot] [PATCH 2/2] tools: mkenvimage: Fix possible segfault on stdin input

2018-04-20 Thread Alexander Dahl
The size of 'filebuf' was not increased as more and more bytes are read
from stdin, but 'filebuf' was always reallocated to the same fix size.
This works as long as only less bytes than the initial buffer size come
in, for more input this will segfault. (It actually does, I tested
that.) So for each loop cycle the buffer size has to be increased by the
number of bytes we want to read.

Signed-off-by: Alexander Dahl 
---
 tools/mkenvimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index 716cb73a5c..8cd9ffa1c6 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -162,7 +162,7 @@ int main(int argc, char **argv)
txt_fd = STDIN_FILENO;
 
do {
-   filebuf = realloc(filebuf, readlen);
+   filebuf = realloc(filebuf, filesize + readlen);
if (!filebuf) {
fprintf(stderr, "Can't realloc memory for the 
input file buffer\n");
return EXIT_FAILURE;
-- 
2.11.0

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


[U-Boot] [PATCH 1/2] tools: mkenvimage: Fix read() stdin error handling

2018-04-20 Thread Alexander Dahl
On success read() returns the number of bytes read or zero for EOF. On
error -1 is returned and errno is set, so the right way to test if read
had failed is to test the return value instead of errno.

Signed-off-by: Alexander Dahl 
---
 tools/mkenvimage.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/mkenvimage.c b/tools/mkenvimage.c
index 8eee72e257..716cb73a5c 100644
--- a/tools/mkenvimage.c
+++ b/tools/mkenvimage.c
@@ -168,7 +168,7 @@ int main(int argc, char **argv)
return EXIT_FAILURE;
}
readbytes = read(txt_fd, filebuf + filesize, readlen);
-   if (errno) {
+   if (readbytes < 0) {
fprintf(stderr, "Error while reading stdin: 
%s\n",
strerror(errno));
return EXIT_FAILURE;
-- 
2.11.0

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


[U-Boot] [PATCH 0/2] tools: mkenvimage: Fix input from STDIN

2018-04-20 Thread Alexander Dahl
Hei hei,

while reviewing what mkenvimage does in detail, I found two small bugs
in input file handling when reading from STDIN.

HTH & Greets
Alex

Alexander Dahl (2):
  tools: mkenvimage: Fix read() stdin error handling
  tools: mkenvimage: Fix possible segfault on stdin input

 tools/mkenvimage.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

-- 
2.11.0

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


Re: [U-Boot] [PATCH v1 05/16] arm: socfpga: misc: Add CONFIG_SYS_L2_PL310 switch

2018-04-20 Thread Marek Vasut
On 04/20/2018 09:49 AM, Ley Foon Tan wrote:
> On Thu, Apr 19, 2018 at 4:19 PM, Marek Vasut  wrote:
>> On 04/19/2018 07:15 AM, See, Chin Liang wrote:
>>> On Thu, 2018-04-19 at 04:47 +0200, Marek Vasut wrote:
 On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
>
> Add CONFIG_SYS_L2_PL310 conditional build.
 Why ?

>>>
>>> In ARM64, L2 cache controller is accessed through processor registers.
>>> Hence we shall make this conditional in order this file can be shared
>>> across SOCFPGAs.
>>
>> That should be in the patch description .
>> Do you ever add the PL310 register access on S10 later in the set?
>>
>> --
> Okay, will update description.
> No, S10 doesn't use PL310 registers.

If this PL310 is Gen5 specific, then keep it in some Gen5 file.

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


Re: [U-Boot] [PATCH v1 01/16] arm: socfpga: stratix10: Add base address map for Statix10 SoC

2018-04-20 Thread Marek Vasut
On 04/20/2018 05:22 PM, Ley Foon Tan wrote:
> On Thu, 2018-04-19 at 05:02 +0200, Marek Vasut wrote:
>> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
>>>
>>> Add the base address map for Statix10 SoC
>>>
>>> Signed-off-by: Chin Liang See 
>>> Signed-off-by: Ley Foon Tan 
>>> ---
>>>  arch/arm/mach-socfpga/include/mach/base_addr_s10.h |   38
>>> 
>>>  1 files changed, 38 insertions(+), 0 deletions(-)
>>>  create mode 100644 arch/arm/mach-
>>> socfpga/include/mach/base_addr_s10.h
>>>
>>> diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
>>> b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
>>> new file mode 100644
>>> index 000..e18d2bf
>>> --- /dev/null
>>> +++ b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
>>> @@ -0,0 +1,38 @@
>>> +/* SPDX-License-Identifier: GPL-2.0
>>> + *
>>> + * Copyright (C) 2016-2018 Intel Corporation 
>>> + *
>>> + */
>>> +
>>> +#ifndef _SOCFPGA_S10_BASE_HARDWARE_H_
>>> +#define _SOCFPGA_S10_BASE_HARDWARE_H_
>>> +
>>> +#define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xf8000400
>>> +#define SOCFPGA_HMC_MMR_IO48_ADDRESS   0xf801
>>> +#define SOCFPGA_SDR_ADDRESS0xf8011000
>>> +#define SOCFPGA_SMMU_ADDRESS   0xfa00
>>> +#define SOCFPGA_MAILBOX_ADDRESS0xffA3
>>> +#define SOCFPGA_UART0_ADDRESS  0xffc02000
>>> +#define SOCFPGA_UART1_ADDRESS  0xffc02100
>>> +#define SOCFPGA_L4WD0_ADDRESS  0xffd00200
>>> +#define SOCFPGA_L4WD1_ADDRESS  0xffd00300
>>> +#define SOCFPGA_L4WD2_ADDRESS  0xffd00400
>>> +#define SOCFPGA_L4WD3_ADDRESS  0xffd00500
>>> +#define SOCFPGA_GTIMER_SEC_ADDRESS 0xffd01000
>>> +#define SOCFPGA_GTIMER_NSEC_ADDRESS0xffd02000
>>> +#define SOCFPGA_CLKMGR_ADDRESS 0xffd1
>>> +#define SOCFPGA_RSTMGR_ADDRESS 0xffd11000
>>> +#define SOCFPGA_SYSMGR_ADDRESS 0xffd12000
>>> +#define SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS0xffd13000
>>> +#define SOCFPGA_FIREWALL_L4_PER0xffd21000
>>> +#define SOCFPGA_FIREWALL_L4_SYS0xffd21100
>>> +#define SOCFPGA_FIREWALL_SOC2FPGA  0xffd21200
>>> +#define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300
>>> +#define SOCFPGA_FIREWALL_TCU   0xffd21400
>>> +#define SOCFPGA_DMANONSECURE_ADDRESS   0xffda
>>> +#define SOCFPGA_DMASECURE_ADDRESS  0xffda1000
>>> +#define SOCFPGA_OCRAM_ADDRESS  0xffe0
>>> +#define GICD_BASE  0xfffc1000
>>> +#define GICC_BASE  0xfffc2000
>> How much of this can come from DT ?
>>
> 
> Just found out Dinh already upstreamed this patch. BTW, we will try to 
> use DT when it is possible.

It is possible since years ago :-)

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


Re: [U-Boot] [PATCH v6 1/2] x86: Add TSC-specific timer functions

2018-04-20 Thread Andy Shevchenko
On Thu, 2018-04-12 at 15:12 -0700, Ivan Gorinov wrote:
> Coreboot timestamp functions and Quark memory reference code use
> get_tbclk() to get TSC frequency. This will not work if another
> early timer is selected.
> 
> Add tsc_rate_mhz() function and use it in the code that specifically
> needs to get TSC rate regardless of currently selected early timer.


>  void delay_n(uint32_t ns)
>  {
>   /* 1000 MHz clock has 1ns period --> no conversion required
> */
> - uint64_t final_tsc = rdtsc();
> + uint64_t start_tsc = rdtsc();
> + uint64_t ticks;
>  
> - final_tsc += ((get_tbclk_mhz() * ns) / 1000);
> -
> - while (rdtsc() < final_tsc)
> - ;
> + ticks = (tsc_rate_mhz() * ns) / 1000;

> + while (rdtsc() - start_tsc < ticks);

I would rather preserve existing style.

>  }
 
>  /* Delay number of microseconds */
> -void delay_u(uint32_t ms)
> +void delay_u(uint32_t us)
>  {
>   /* 64-bit math is not an option, just use loops */
> - while (ms--)
> + while (us--)
>   delay_n(1000);
>  }

This is a separate change.

-- 
Andy Shevchenko 
Intel Finland Oy
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Jorge Ramirez-Ortiz

On 04/20/2018 01:22 PM, Ramon Fried wrote:

On 20 April 2018 at 14:14, Jorge Ramirez-Ortiz  wrote:

On 04/20/2018 01:02 PM, Ramon Fried wrote:

On 18 April 2018 at 13:15, Jorge Ramirez-Ortiz 
wrote:

On 04/18/2018 09:02 AM, Jorge Ramirez-Ortiz wrote:

On 04/17/2018 02:01 PM, Ramon Fried wrote:

The clock node is used by the serial driver and it's needed
before relocation.
This patch ensures that the msm-serial driver can actually
use the clock node.

Signed-off-by: Ramon Fried 
---
arch/arm/dts/dragonboard410c.dts | 2 ++
1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/dragonboard410c.dts
b/arch/arm/dts/dragonboard410c.dts
index 5ccfe7f8c8..f37ef5d523 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -38,12 +38,14 @@
#size-cells = <0x1>;
ranges = <0x0 0x0 0x0 0x>;
compatible = "simple-bus";
+u-boot,dm-pre-reloc;


I think the intent is to make dm-pre-reloc legacy.
New platforms should be using "u-boot,dm-spl" even if CONFIG_SPL_BUILD
is
not enabled (I believe it should work)


  clkc: qcom,gcc@180 {
compatible = "qcom,gcc-apq8016";
reg = <0x180 0x8>;
#address-cells = <0x1>;
#size-cells = <0x0>;
+u-boot,dm-pre-reloc;
};
  serial@78b {



another question is, how will you probe the clock driver before the uart?
I think even if you probed in misc_init_f it is already too late.

other than that - + Peter Robinson's comments- looks good.


The clock is probed because the uart driver asks for it. it's actually
already exists in the code, but wasn't used because
the clock wasn't set to dm-pre-reloc


um, are you sure? that is not what I see during my tests but I could be
wrong - or something else might be happening in uboot

you can create a misc_init_f for the board that retrieves the clock driver
by name and forces a probe; I can see that the probe happens (ie, the
DM_FLAG_ACTIVATED was _not_ set for that driver) which is not what I believe
you expect since you want the clock driver to be probed before the uart.

It doesn't need to be probed before the uart, the uart is probed first
and when it asks for the
clock node it's forcing a probe. it's tested.


can you post a trace. just dump the value of GD_FLG_RELOC on clock the 
probe function.


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


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Ramon Fried
On 20 April 2018 at 14:14, Jorge Ramirez-Ortiz  wrote:
> On 04/20/2018 01:02 PM, Ramon Fried wrote:
>>
>> On 18 April 2018 at 13:15, Jorge Ramirez-Ortiz 
>> wrote:
>>>
>>> On 04/18/2018 09:02 AM, Jorge Ramirez-Ortiz wrote:

 On 04/17/2018 02:01 PM, Ramon Fried wrote:
>
> The clock node is used by the serial driver and it's needed
> before relocation.
> This patch ensures that the msm-serial driver can actually
> use the clock node.
>
> Signed-off-by: Ramon Fried 
> ---
>arch/arm/dts/dragonboard410c.dts | 2 ++
>1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/dts/dragonboard410c.dts
> b/arch/arm/dts/dragonboard410c.dts
> index 5ccfe7f8c8..f37ef5d523 100644
> --- a/arch/arm/dts/dragonboard410c.dts
> +++ b/arch/arm/dts/dragonboard410c.dts
> @@ -38,12 +38,14 @@
>#size-cells = <0x1>;
>ranges = <0x0 0x0 0x0 0x>;
>compatible = "simple-bus";
> +u-boot,dm-pre-reloc;


 I think the intent is to make dm-pre-reloc legacy.
 New platforms should be using "u-boot,dm-spl" even if CONFIG_SPL_BUILD
 is
 not enabled (I believe it should work)

>  clkc: qcom,gcc@180 {
>compatible = "qcom,gcc-apq8016";
>reg = <0x180 0x8>;
>#address-cells = <0x1>;
>#size-cells = <0x0>;
> +u-boot,dm-pre-reloc;
>};
>  serial@78b {


>>> another question is, how will you probe the clock driver before the uart?
>>> I think even if you probed in misc_init_f it is already too late.
>>>
>>> other than that - + Peter Robinson's comments- looks good.
>>>
>> The clock is probed because the uart driver asks for it. it's actually
>> already exists in the code, but wasn't used because
>> the clock wasn't set to dm-pre-reloc
>
>
> um, are you sure? that is not what I see during my tests but I could be
> wrong - or something else might be happening in uboot
>
> you can create a misc_init_f for the board that retrieves the clock driver
> by name and forces a probe; I can see that the probe happens (ie, the
> DM_FLAG_ACTIVATED was _not_ set for that driver) which is not what I believe
> you expect since you want the clock driver to be probed before the uart.
It doesn't need to be probed before the uart, the uart is probed first
and when it asks for the
clock node it's forcing a probe. it's tested.
>
> Good news is that since misc_init_f runs before relocation you can check
> that GD_FLG_RELOC was not set either so it is indeed being probed before
> relocation (which makes sense after adding the reloc property).
>
> maybe you can have a look?
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Jorge Ramirez-Ortiz

On 04/20/2018 01:02 PM, Ramon Fried wrote:

On 18 April 2018 at 13:15, Jorge Ramirez-Ortiz  wrote:

On 04/18/2018 09:02 AM, Jorge Ramirez-Ortiz wrote:

On 04/17/2018 02:01 PM, Ramon Fried wrote:

The clock node is used by the serial driver and it's needed
before relocation.
This patch ensures that the msm-serial driver can actually
use the clock node.

Signed-off-by: Ramon Fried 
---
   arch/arm/dts/dragonboard410c.dts | 2 ++
   1 file changed, 2 insertions(+)

diff --git a/arch/arm/dts/dragonboard410c.dts
b/arch/arm/dts/dragonboard410c.dts
index 5ccfe7f8c8..f37ef5d523 100644
--- a/arch/arm/dts/dragonboard410c.dts
+++ b/arch/arm/dts/dragonboard410c.dts
@@ -38,12 +38,14 @@
   #size-cells = <0x1>;
   ranges = <0x0 0x0 0x0 0x>;
   compatible = "simple-bus";
+u-boot,dm-pre-reloc;


I think the intent is to make dm-pre-reloc legacy.
New platforms should be using "u-boot,dm-spl" even if CONFIG_SPL_BUILD is
not enabled (I believe it should work)


 clkc: qcom,gcc@180 {
   compatible = "qcom,gcc-apq8016";
   reg = <0x180 0x8>;
   #address-cells = <0x1>;
   #size-cells = <0x0>;
+u-boot,dm-pre-reloc;
   };
 serial@78b {



another question is, how will you probe the clock driver before the uart?
I think even if you probed in misc_init_f it is already too late.

other than that - + Peter Robinson's comments- looks good.


The clock is probed because the uart driver asks for it. it's actually
already exists in the code, but wasn't used because
the clock wasn't set to dm-pre-reloc


um, are you sure? that is not what I see during my tests but I could be 
wrong - or something else might be happening in uboot


you can create a misc_init_f for the board that retrieves the clock 
driver by name and forces a probe; I can see that the probe happens (ie, 
the DM_FLAG_ACTIVATED was _not_ set for that driver) which is not what I 
believe you expect since you want the clock driver to be probed before 
the uart.


Good news is that since misc_init_f runs before relocation you can check 
that GD_FLG_RELOC was not set either so it is indeed being probed before 
relocation (which makes sense after adding the reloc property).


maybe you can have a look?


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


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Ramon Fried
On 18 April 2018 at 13:15, Jorge Ramirez-Ortiz  wrote:
> On 04/18/2018 09:02 AM, Jorge Ramirez-Ortiz wrote:
>>
>> On 04/17/2018 02:01 PM, Ramon Fried wrote:
>>>
>>> The clock node is used by the serial driver and it's needed
>>> before relocation.
>>> This patch ensures that the msm-serial driver can actually
>>> use the clock node.
>>>
>>> Signed-off-by: Ramon Fried 
>>> ---
>>>   arch/arm/dts/dragonboard410c.dts | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/dragonboard410c.dts
>>> b/arch/arm/dts/dragonboard410c.dts
>>> index 5ccfe7f8c8..f37ef5d523 100644
>>> --- a/arch/arm/dts/dragonboard410c.dts
>>> +++ b/arch/arm/dts/dragonboard410c.dts
>>> @@ -38,12 +38,14 @@
>>>   #size-cells = <0x1>;
>>>   ranges = <0x0 0x0 0x0 0x>;
>>>   compatible = "simple-bus";
>>> +u-boot,dm-pre-reloc;
>>
>>
>> I think the intent is to make dm-pre-reloc legacy.
>> New platforms should be using "u-boot,dm-spl" even if CONFIG_SPL_BUILD is
>> not enabled (I believe it should work)
>>
>>> clkc: qcom,gcc@180 {
>>>   compatible = "qcom,gcc-apq8016";
>>>   reg = <0x180 0x8>;
>>>   #address-cells = <0x1>;
>>>   #size-cells = <0x0>;
>>> +u-boot,dm-pre-reloc;
>>>   };
>>> serial@78b {
>>
>>
>
> another question is, how will you probe the clock driver before the uart?
> I think even if you probed in misc_init_f it is already too late.
>
> other than that - + Peter Robinson's comments- looks good.
>
The clock is probed because the uart driver asks for it. it's actually
already exists in the code, but wasn't used because
the clock wasn't set to dm-pre-reloc
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH] db410c: set clk node to be probed before relocation

2018-04-20 Thread Ramon Fried
On 18 April 2018 at 11:15, Peter Robinson  wrote:
> On Tue, Apr 17, 2018 at 1:01 PM, Ramon Fried  wrote:
>> The clock node is used by the serial driver and it's needed
>> before relocation.
>> This patch ensures that the msm-serial driver can actually
>> use the clock node.
>>
>> Signed-off-by: Ramon Fried 
>> ---
>>  arch/arm/dts/dragonboard410c.dts | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/arch/arm/dts/dragonboard410c.dts 
>> b/arch/arm/dts/dragonboard410c.dts
>> index 5ccfe7f8c8..f37ef5d523 100644
>> --- a/arch/arm/dts/dragonboard410c.dts
>> +++ b/arch/arm/dts/dragonboard410c.dts
>> @@ -38,12 +38,14 @@
>> #size-cells = <0x1>;
>> ranges = <0x0 0x0 0x0 0x>;
>> compatible = "simple-bus";
>> +   u-boot,dm-pre-reloc;
>
> u-boot specific DT bits should be put in a u-boot.dts[i] file, see in
> arch/arm/dts/ for other examples, it makes syncing DT changes from the
> linux kernel more straight forward.
Thanks for the feedback.
I'll resend the the patch with the correction.
>
>> clkc: qcom,gcc@180 {
>> compatible = "qcom,gcc-apq8016";
>> reg = <0x180 0x8>;
>> #address-cells = <0x1>;
>> #size-cells = <0x0>;
>> +   u-boot,dm-pre-reloc;
>> };
>>
>> serial@78b {
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
>> a Linux Foundation Collaborative Project
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> https://lists.denx.de/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 3/3] arm: socfpga: stratix10: Enable Stratix10 FPGA Reconfiguration

2018-04-20 Thread chee . hong . ang
From: Chee Hong Ang 

Enable Stratix10 FPGA reconfiguration support in defconfig.

Signed-off-by: Chee Hong Ang 
---
 configs/socfpga_stratix10_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/socfpga_stratix10_defconfig 
b/configs/socfpga_stratix10_defconfig
index 46b7999..2414f4e 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_defconfig
@@ -9,6 +9,8 @@ CONFIG_SPL_FAT_SUPPORT=y
 CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk"
 CONFIG_BOOTDELAY=5
 CONFIG_HUSH_PARSER=y
+CONFIG_FPGA_ALTERA=y
+CONFIG_FPGA_STRATIX10=y
 CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
 CONFIG_CMD_MEMTEST=y
 # CONFIG_CMD_FLASH is not set
-- 
2.2.0

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


[U-Boot] [PATCH v1 2/3] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table

2018-04-20 Thread chee . hong . ang
From: Chee Hong Ang 

Enable 'fpga' command in u-boot. User will be able to use the
fpga command to program the FPGA on Stratix10 SoC.

Signed-off-by: Chee Hong Ang 
---
 arch/arm/mach-socfpga/misc.c | 20 +---
 arch/arm/mach-socfpga/misc_s10.c |  4 
 drivers/fpga/altera.c|  6 ++
 include/altera.h |  8 
 4 files changed, 35 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index d15cbc7..e36c686 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -87,11 +87,24 @@ int overwrite_console(void)
 #endif
 
 #ifdef CONFIG_FPGA
-/*
- * FPGA programming support for SoC FPGA Cyclone V
- */
 static Altera_desc altera_fpga[] = {
{
+#ifdef CONFIG_FPGA_STRATIX10
+   /* FPGA programming support for SoC FPGA Stratix 10 */
+   /* Family */
+   Intel_FPGA_Stratix10,
+   /* Interface type */
+   secure_device_manager_mailbox,
+   /* No limitation as additional data will be ignored */
+   -1,
+   /* No device function table */
+   NULL,
+   /* Base interface address specified in driver */
+   NULL,
+   /* No cookie implementation */
+   0
+#else
+   /* FPGA programming support for SoC FPGA Cyclone V */
/* Family */
Altera_SoCFPGA,
/* Interface type */
@@ -104,6 +117,7 @@ static Altera_desc altera_fpga[] = {
NULL,
/* No cookie implementation */
0
+#endif
},
 };
 
diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index b1cc6ca..012d8f6 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -71,6 +71,10 @@ int arch_misc_init(void)
 
 int arch_early_init_r(void)
 {
+#ifdef CONFIG_FPGA
+   socfpga_fpga_add();
+#endif
+
return 0;
 }
 
diff --git a/drivers/fpga/altera.c b/drivers/fpga/altera.c
index 135a357..b662ff5 100644
--- a/drivers/fpga/altera.c
+++ b/drivers/fpga/altera.c
@@ -40,6 +40,9 @@ static const struct altera_fpga {
 #if defined(CONFIG_FPGA_STRATIX_V)
{ Altera_StratixV, "StratixV", stratixv_load, NULL, NULL },
 #endif
+#if defined(CONFIG_FPGA_STRATIX10)
+   { Intel_FPGA_Stratix10, "Stratix10", stratix10_load, NULL, NULL },
+#endif
 #if defined(CONFIG_FPGA_SOCFPGA)
{ Altera_SoCFPGA, "SoC FPGA", socfpga_load, NULL, NULL },
 #endif
@@ -155,6 +158,9 @@ int altera_info(Altera_desc *desc)
case fast_passive_parallel_security:
printf("Fast Passive Parallel with Security (FPPS)\n");
break;
+   case secure_device_manager_mailbox:
+   puts("Secure Device Manager (SDM) Mailbox\n");
+   break;
/* Add new interface types here */
default:
printf("Unsupported interface type, %d\n", desc->iface);
diff --git a/include/altera.h b/include/altera.h
index 48d3eb7..e9ba47a 100644
--- a/include/altera.h
+++ b/include/altera.h
@@ -40,6 +40,8 @@ enum altera_iface {
fast_passive_parallel,
/* fast passive parallel with security (FPPS) */
fast_passive_parallel_security,
+   /* secure device manager (SDM) mailbox */
+   secure_device_manager_mailbox,
/* insert all new types before this */
max_altera_iface_type,
 };
@@ -55,6 +57,8 @@ enum altera_family {
Altera_StratixII,
/* StratixV Family */
Altera_StratixV,
+   /* Stratix10 Family */
+   Intel_FPGA_Stratix10,
/* SoCFPGA Family */
Altera_SoCFPGA,
 
@@ -117,4 +121,8 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, 
size_t rbf_size);
 int stratixv_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size);
 #endif
 
+#ifdef CONFIG_FPGA_STRATIX10
+int stratix10_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size);
+#endif
+
 #endif /* _ALTERA_H_ */
-- 
2.2.0

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


[U-Boot] [PATCH v1 1/3] arm: socfpga: stratix10: Add Stratix10 FPGA Reconfiguration Driver

2018-04-20 Thread chee . hong . ang
From: Chee Hong Ang 

Enable FPGA reconfiguration support on Stratix10 SoC.

Signed-off-by: Chee Hong Ang 
---
 drivers/fpga/Kconfig |  10 ++
 drivers/fpga/Makefile|   1 +
 drivers/fpga/stratix10.c | 298 +++
 3 files changed, 309 insertions(+)
 create mode 100644 drivers/fpga/stratix10.c

diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index d36c4c5..255683d 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -31,6 +31,16 @@ config FPGA_CYCLON2
  Enable FPGA driver for loading bitstream in BIT and BIN format
  on Altera Cyclone II device.
 
+config FPGA_STRATIX10
+   bool "Enable Altera FPGA driver for Stratix 10"
+   depends on FPGA_ALTERA && TARGET_SOCFPGA_STRATIX10
+   help
+ Say Y here to enable the Altera Stratix 10 FPGA specific driver
+
+ This provides common functionality for Altera Stratix 10 devices.
+ Enable FPGA driver for writing bitstream into Altera Stratix10
+ device.
+
 config FPGA_XILINX
bool "Enable Xilinx FPGA drivers"
select FPGA
diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
index 08c9ff8..3c906ec 100644
--- a/drivers/fpga/Makefile
+++ b/drivers/fpga/Makefile
@@ -19,6 +19,7 @@ obj-$(CONFIG_FPGA_ACEX1K) += ACEX1K.o
 obj-$(CONFIG_FPGA_CYCLON2) += cyclon2.o
 obj-$(CONFIG_FPGA_STRATIX_II) += stratixII.o
 obj-$(CONFIG_FPGA_STRATIX_V) += stratixv.o
+obj-$(CONFIG_FPGA_STRATIX10) += stratix10.o
 obj-$(CONFIG_FPGA_SOCFPGA) += socfpga.o
 obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += socfpga_gen5.o
 obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += socfpga_arria10.o
diff --git a/drivers/fpga/stratix10.c b/drivers/fpga/stratix10.c
new file mode 100644
index 000..f0c5ace
--- /dev/null
+++ b/drivers/fpga/stratix10.c
@@ -0,0 +1,298 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2016-2018 Intel Corporation 
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#define RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS   6
+#define RECONFIG_STATUS_INTERVAL_DELAY_US  100
+
+static const struct mbox_cfgstat_state {
+   int err_no;
+   const char  *error_name;
+} mbox_cfgstat_state[] = {
+   {MBOX_CFGSTAT_STATE_IDLE, "FPGA in idle mode."},
+   {MBOX_CFGSTAT_STATE_CONFIG, "FPGA in config mode."},
+   {MBOX_CFGSTAT_STATE_FAILACK, "Acknowledgement failed!"},
+   {MBOX_CFGSTAT_STATE_ERROR_INVALID, "Invalid bitstream!"},
+   {MBOX_CFGSTAT_STATE_ERROR_CORRUPT, "Corrupted bitstream!"},
+   {MBOX_CFGSTAT_STATE_ERROR_AUTH, "Authentication failed!"},
+   {MBOX_CFGSTAT_STATE_ERROR_CORE_IO, "I/O error!"},
+   {MBOX_CFGSTAT_STATE_ERROR_HARDWARE, "Hardware error!"},
+   {MBOX_CFGSTAT_STATE_ERROR_FAKE, "Fake error!"},
+   {MBOX_CFGSTAT_STATE_ERROR_BOOT_INFO, "Error in boot info!"},
+   {MBOX_CFGSTAT_STATE_ERROR_QSPI_ERROR, "Error in QSPI!"},
+   {-ETIMEDOUT, "I/O timeout error"},
+   {-1, "Unknown error!"}
+};
+
+#define MBOX_CFGSTAT_MAX \
+ (sizeof(mbox_cfgstat_state) / sizeof(struct mbox_cfgstat_state))
+
+static const char *mbox_cfgstat_to_str(int err)
+{
+   int i;
+
+   for (i = 0; i < MBOX_CFGSTAT_MAX - 1; i++) {
+   if (mbox_cfgstat_state[i].err_no == err)
+   return mbox_cfgstat_state[i].error_name;
+   }
+
+   return mbox_cfgstat_state[MBOX_CFGSTAT_MAX - 1].error_name;
+}
+
+static void inc_cmd_id(u8 *id)
+{
+   u8 val = *id + 1;
+
+   if (val > 15)
+   val = 1;
+
+   *id = val;
+}
+
+/*
+ * Polling the FPGA configuration status.
+ * Return 0 for success, non-zero for error.
+ */
+static int reconfig_status_polling_resp(void)
+{
+   u32 reconfig_status_resp_len;
+   u32 reconfig_status_resp[RECONFIG_STATUS_RESPONSE_LEN];
+   int ret;
+   unsigned long start = get_timer(0);
+
+   while (1) {
+   reconfig_status_resp_len = RECONFIG_STATUS_RESPONSE_LEN;
+   ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_RECONFIG_STATUS,
+   MBOX_CMD_DIRECT, 0, NULL, 0,
+   _status_resp_len,
+   reconfig_status_resp);
+
+   if (ret) {
+   puts("Failure in RECONFIG_STATUS mailbox command!\n");
+   return ret;
+   }
+
+   /* Check for any error */
+   ret = reconfig_status_resp[RECONFIG_STATUS_STATE];
+   if (ret && ret != MBOX_CFGSTAT_STATE_CONFIG)
+   return ret;
+
+   /* Make sure nStatus is not 0 */
+   ret = reconfig_status_resp[RECONFIG_STATUS_PIN_STATUS];
+   if (!(ret & RCF_PIN_STATUS_NSTATUS))
+   return MBOX_CFGSTAT_STATE_ERROR_HARDWARE;
+
+   ret = reconfig_status_resp[RECONFIG_STATUS_SOFTFUNC_STATUS];
+   if 

Re: [U-Boot] [PATCH] mx7dsabresd: Remove the mx7dsabresd_secure_defconfig target

2018-04-20 Thread Bryan O'Donoghue



On 19/04/18 20:34, Fabio Estevam wrote:

From: Fabio Estevam 

mx7dsabresd_secure_defconfig was introduced to allow booting NXP kernel
that has CAAM support and needs to boot in secure mode.

Instead of keeping two different config targets for the same board,
remove mx7dsabresd_secure_defconfig and select
CONFIG_ARMV7_BOOT_SEC_DEFAULT inside mx7dsabresd_defconfig so that
this target could be used to boot both mainline and the vendor kernel.

This makes maintenance task easier and avoid potentially confusion
for the end user.

Signed-off-by: Fabio Estevam 


Acked-by: Bryan O'Donoghue 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] Make error in U-boot branch v2015.10-rc5

2018-04-20 Thread Arunashis Ghose
Hi,

Thanks for reading this email and I would be grateful if you have time to help 
me fix the issue.

I am very much new to U-boot world and trying to build U-boot in my machine for 
a particular board - 'Marvel Armada 38x'. While I was trying to compile the 
u-boot fork for Marvel (in github), I got following error:

---
 [Building U-BOOT]*

cc1: error: bad value (armv7-a) for -march= switch
cc1: error: bad value (armv7-a) for -march= switch
lib/asm-offsets.c:1:0: error: bad value (armv7-a) for -march= switch
 /*
 ^
Makefile:716: recipe for target 'lib/asm-offsets.s' failed
make: *** [lib/asm-offsets.s] Error 1
make: *** Waiting for unfinished jobs

 *** Error: Build failed
---

I couldn't figure out what is causing it and a way to fix it.

Then I thought I would try to build u-boot original. I checked out the branch 
v2015.10-rc5 of u-boot and tried to build it for board - 'bananapro' (a random 
choice). I got a similar error:

---
$ make Bananapro_config
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  SHIPPED scripts/kconfig/zconf.hash.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
#
# configuration written to .config
#
$ make all
scripts/kconfig/conf  --silentoldconfig Kconfig
  CHK include/config.h
  UPD include/config.h
  GEN include/autoconf.mk
  GEN include/autoconf.mk.dep
  GEN spl/include/autoconf.mk
  CHK include/config/uboot.release
  UPD include/config/uboot.release
  CHK include/generated/version_autogenerated.h
  UPD include/generated/version_autogenerated.h
  CHK include/generated/timestamp_autogenerated.h
  UPD include/generated/timestamp_autogenerated.h
  CC  lib/asm-offsets.s
lib/asm-offsets.c:1:0: error: bad value (armv5) for -march= switch
 /*
 ^
Kbuild:43: recipe for target 'lib/asm-offsets.s' failed
make[1]: *** [lib/asm-offsets.s] Error 1
Makefile:1251: recipe for target 'prepare0' failed
make: *** [prepare0] Error 2
---

Can anyone give me a clue? Thanks a lot.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] CFI flash broken for 8-bit bus

2018-04-20 Thread Radovan Prodanovic

Has the pending patch for the issue described below ever been released?

Am observing the same issue in the U-Boot version 2015-10.


On 2011/03/18 6:02 AM, Aaron Williams wrote:
> Hi,
>
> I am running into issues in that the CFI code is broken for flash with an 8-
> bit bus. The problem is that the CFI code uses the wrong addresses for 8-bits
> vs 16-bits.
>
> The CFI function flash_map incorrectly calculates the byte offset with
> Spansion flash.
>
> In our case, we have an 8-bit Spansion S29GL-N MirrorBit flash chip on an 8-
> bit bus.
>
> According to the data sheet, in 8-bit mode the first unlock address is 0xAAA
> and the second is 0x555. Basically all of the addresses are approximately
> double what they are in 16-bit mode.
>
> Most of the addresses in the CFI code are wrong for 8-bit mode.
>
> They should be as follows:
> unlock1: 0xAAA
> unlock2: 0x555
> CFI Query: 0xAA
>
> Offset Device ID: 0x02, 0x1c, 0x1e
> Offset Silicon Sector Factory Protect: 0x6
> Sector protect verify (sector address) + 4
>
> The problem is that the dectection code detects (incorrectly) that we're an 8-
> bit device on a 16-bit bus when in fact it's an 8-bit bus.
>
> For 16-bits, it's:
>
> unlock1: 0x555
> unlock2: 0x2aa
> CFI Query: 0x55
> Offset Device ID: 0x1, 0x0e, 0x0f
>
> Now, in 16-bit mode these addresses should be effectively doubled so they
> should look to be the same to software as I understand it.
>
> This is all taken from the datasheet.
>
> Note that the CFI code works fine with the flash hooked up as 16-bit on a 16-
> bit bus.
>
> If it's an 8-bit flash on a 16-bit bus then the addresses should be doubled.
>

>
> -Aaron




Thanks,
Radovan Prodanovic
S/W Designer, Embedded Platforms
613-691-3358



NOTE: This e-mail (including any attachments) is for the sole use of the 
intended recipient(s) and may contain information that is confidential and/or 
protected by legal privilege. Any unauthorized review, use, copy, disclosure or 
distribution of this e-mail is strictly prohibited. If you are not the intended 
recipient, please notify Mitel immediately and destroy all copies of this 
e-mail. Mitel does not accept any liability for breach of security, error or 
virus that may result from the transmission of this message.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


[U-Boot] [PATCH v1 0/3] Stratix10 FPGA reconfiguration support

2018-04-20 Thread chee . hong . ang
From: Chee Hong Ang 

This patch enable FPGA reconfiguration for Stratix10 SoC.
This patch works on top of:
https://lists.denx.de/pipermail/u-boot/2018-April/325900.html

Chee Hong Ang (3):
  arm: socfpga: stratix10: Add Stratix10 FPGA Reconfiguration Driver
  arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
  arm: socfpga: stratix10: Enable Stratix10 FPGA Reconfiguration

 arch/arm/mach-socfpga/misc.c|  20 ++-
 arch/arm/mach-socfpga/misc_s10.c|   4 +
 configs/socfpga_stratix10_defconfig |   2 +
 drivers/fpga/Kconfig|  10 ++
 drivers/fpga/Makefile   |   1 +
 drivers/fpga/altera.c   |   6 +
 drivers/fpga/stratix10.c| 298 
 include/altera.h|   8 +
 8 files changed, 346 insertions(+), 3 deletions(-)
 create mode 100644 drivers/fpga/stratix10.c

-- 
2.2.0

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


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

2018-04-20 Thread Alexander Graf


> Am 20.04.2018 um 09:09 schrieb Michal Simek :
> 
> Hi Alex,
> 
>> On 19.4.2018 18:48, Alexander Graf wrote:
>>> On 04/18/2018 03:11 PM, Michal Simek wrote:
>>> Xilinx ZynqMP also contains dual Cortex R5 which can run U-Boot.
>>> This patch is adding minimal support to get U-Boot boot.
>>> DDR needs to be partitioned. Console is done via Cadence uart driver and
>>> the first Cadence Triple Timer Counter is used for time.
>>> 
>>> This configuration with uart1 was tested on zcu100-revC.
>>> 
>>> U-Boot 2018.05-rc2-00021-gd058a08d907d (Apr 18 2018 - 14:11:27 +0200)
>>> 
>>> Model: Xilinx ZynqMP R5
>>> DRAM:  512 MiB
>>> WARNING: Caches not enabled
>>> MMC:
>>> In:serial@ff01
>>> Out:   serial@ff01
>>> Err:   serial@ff01
>>> Net:   Net Initialization Skipped
>>> No ethernet found.
>>> ZynqMP r5>
>>> 
>>> There are two ways how to run this on ZynqMP.
>>> 1. Run from ZynqMP arm64
>>> tftpb 2000 u-boot-r5.elf
>>> setenv autostart no && bootelf -p 2000
>>> cpu 4 disable && cpu 4 release 1000 lockstep
>>> or
>>> cpu 4 disable && cpu 4 release 1000 split
>>> 
>>> 2. Load via jtag when directly to R5
>>> 
>>> Signed-off-by: Michal Simek 
>>> ---
>>> 
>>>   MAINTAINERS|  6 +++
>>>   arch/arm/Kconfig   | 16 +++
>>>   arch/arm/Makefile  |  1 +
>>>   arch/arm/cpu/armv7r/Makefile   |  4 ++
>>>   arch/arm/cpu/armv7r/config.mk  |  3 ++
>>>   arch/arm/cpu/armv7r/cpu.c  | 24 ++
>>>   arch/arm/cpu/armv7r/start.S| 17 +++
>>>   arch/arm/dts/Makefile  |  2 +
>>>   arch/arm/dts/zynqmp-r5.dts | 73 ++
>>>   arch/arm/mach-zynqmp-r5/Kconfig| 27 +++
>>>   arch/arm/mach-zynqmp-r5/Makefile   |  3 ++
>>>   arch/arm/mach-zynqmp-r5/cpu.c  | 15 ++
>>>   board/xilinx/zynqmp_r5/MAINTAINERS |  7 +++
>>>   board/xilinx/zynqmp_r5/Makefile|  6 +++
>>>   board/xilinx/zynqmp_r5/board.c | 25 ++
>>>   configs/xilinx_zynqmp_r5_defconfig | 16 +++
>>>   drivers/serial/Kconfig |  2 +-
>>>   include/configs/xilinx_zynqmp_r5.h | 49 
>>>   18 files changed, 295 insertions(+), 1 deletion(-)
>>>   create mode 100644 arch/arm/cpu/armv7r/Makefile
>>>   create mode 100644 arch/arm/cpu/armv7r/config.mk
>>>   create mode 100644 arch/arm/cpu/armv7r/cpu.c
>>>   create mode 100644 arch/arm/cpu/armv7r/start.S
>>>   create mode 100644 arch/arm/dts/zynqmp-r5.dts
>>>   create mode 100644 arch/arm/mach-zynqmp-r5/Kconfig
>>>   create mode 100644 arch/arm/mach-zynqmp-r5/Makefile
>>>   create mode 100644 arch/arm/mach-zynqmp-r5/cpu.c
>>>   create mode 100644 board/xilinx/zynqmp_r5/MAINTAINERS
>>>   create mode 100644 board/xilinx/zynqmp_r5/Makefile
>>>   create mode 100644 board/xilinx/zynqmp_r5/board.c
>>>   create mode 100644 configs/xilinx_zynqmp_r5_defconfig
>>>   create mode 100644 include/configs/xilinx_zynqmp_r5.h
>>> 
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index 76c6f71d6af2..c78a698f75b0 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -293,6 +293,12 @@ F:include/zynqmppl.h
>>>   F:tools/zynqimage.c
>>>   N:zynqmp
>>>   +ARM ZYNQMP R5
>>> +M:Michal Simek 
>>> +S:Maintained
>>> +T:git git://git.denx.de/u-boot-microblaze.git
>>> +F:arch/arm/mach-zynqmp-r5/
>>> +
>>>   BUILDMAN
>>>   M:Simon Glass 
>>>   S:Maintained
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 7212fc5afa72..c6d8d4d4984d 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -192,6 +192,10 @@ config CPU_V7M
>>>   select THUMB2_KERNEL
>>>   select SYS_CACHE_SHIFT_5
>>>   +config CPU_V7R
>>> +bool
>>> +select SYS_CACHE_SHIFT_6
>> 
>> I think you want to split out Cortex-R support from platform support for
>> zynqmp-r5.
> 
> R5 support is quite minimal that's why I kept it like this. But I can
> split it with no problem.

Thanks :). That makes it easier on review and on git history.

> 
>> 
>>> +
>>>   config CPU_PXA
>>>   bool
>>>   select SYS_CACHE_SHIFT_5
>>> @@ -209,6 +213,7 @@ config SYS_CPU
>>>   default "arm1176" if CPU_ARM1176
>>>   default "armv7" if CPU_V7
>>>   default "armv7m" if CPU_V7M
>>> +default "armv7r" if CPU_V7R
>>>   default "pxa" if CPU_PXA
>>>   default "sa1100" if CPU_SA1100
>>>   default "armv8" if ARM64
>>> @@ -223,6 +228,7 @@ config SYS_ARM_ARCH
>>>   default 6 if CPU_ARM1176
>>>   default 7 if CPU_V7
>>>   default 7 if CPU_V7M
>>> +default 7 if CPU_V7R
>>>   default 5 if CPU_PXA
>>>   default 4 if CPU_SA1100
>>>   default 8 if ARM64
>>> @@ -764,6 +770,14 @@ config ARCH_ZYNQ
>>>   imply FAT_WRITE
>>>   imply CMD_SPL
>>>   +config ARCH_ZYNQMP_R5
>>> +bool "Xilinx ZynqMP R5 based platform"
>>> +select CPU_V7R
>>> +select OF_CONTROL
>>> +select DM
>>> +

[U-Boot] [PATCH 2/2] rpi: Change load addresses to make more room for the kernel & DTB

2018-04-20 Thread Tuomas Tynkkynen
As of Linux 4.16, a multiplatform AArch64 kernel with our distro config
takes 26M. The current space reservation leaves only 17M for the kernel
and if it goes over it, the initrd gets overwritten when loading the
kernel from the filesystem.

A similar problem happens on ARMv7 with the DTBs taken from the
downstream Raspberry Pi foundation kernel. I guess they compile them
with DT overlay support enabled which grows them just enough.

Fix both of these problems by rewriting the memory map, which now allows
kernels to be up to 36M and DTBs up to 1M. Also the comment block was
kind of obsolete ever since the introduction of AArch64 support and the
firmware-loaded DTB doesn't get placed at 0x100 anymore either, so that
is fixed as well.

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/rpi.h | 61 ++-
 1 file changed, 36 insertions(+), 25 deletions(-)

diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index f1189a27f3..425c0c2e6d 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -104,39 +104,50 @@
  *
  * I suspect address 0 is used as the SMP pen on the RPi2, so avoid this.
  *
- * fdt_addr_r simply shouldn't overlap anything else. However, the RPi's
- *   binary firmware loads a DT to address 0x100, so we choose this address to
- *   match it. This allows custom boot scripts to pass this DT on to Linux
- *   simply by not over-writing the data at this address. When using U-Boot,
- *   U-Boot (and scripts it executes) typicaly ignore the DT loaded by the FW
- *   and loads its own DT from disk (triggered by boot.scr or extlinux.conf).
+ * Older versions of the boot firmware place the firmware-loaded DTB at 0x100,
+ * newer versions place it in high memory. So prevent U-Boot from doing its own
+ * DTB + initrd relocation so that we won't accidentally relocate the initrd
+ * over the firmware-loaded DTB and generally try to lay out things starting
+ * from the bottom of RAM.
  *
- * pxefile_addr_r can be pretty much anywhere that doesn't conflict with
- *   something else. Put it low in memory to avoid conflicts.
+ * kernel_addr_r has different constraints on ARM and Aarch64.  For 32-bit ARM,
+ * it must be within the first 128M of RAM in order for the kernel's
+ * CONFIG_AUTO_ZRELADDR option to work. The kernel itself will be decompressed
+ * to 0x8000 but the decompressor clobbers 0x4000-0x8000 as well. The
+ * decompressor also likes to relocate itself to right past the end of the
+ * decompressed kernel, so in total the sum of the compressed and and
+ * decompressed kernel needs to be reserved.
  *
- * kernel_addr_r must be within the first 128M of RAM in order for the
- *   kernel's CONFIG_AUTO_ZRELADDR option to work. Since the kernel will
- *   decompress itself to 0x8000 after the start of RAM, kernel_addr_r
- *   should not overlap that area, or the kernel will have to copy itself
- *   somewhere else before decompression. Similarly, the address of any other
- *   data passed to the kernel shouldn't overlap the start of RAM. Pushing
- *   this up to 16M allows for a sizable kernel to be decompressed below the
- *   compressed load address.
+ *   For Aarch64, the kernel image is uncompressed and must be loaded at
+ *   text_offset bytes (specified in the header of the Image) into a 2MB
+ *   boundary. The 'booti' command relocates the image if necessary. Linux uses
+ *   a default text_offset of 0x8.  In summary, loading at 0x8
+ *   satisfies all these constraints and reserving memory up to 0x0240
+ *   permits fairly large (roughly 36M) kernels.
  *
- * scriptaddr can be pretty much anywhere that doesn't conflict with something
- *   else. Choosing 32M allows for the compressed kernel to be up to 16M.
+ * scriptaddr and pxefile_addr_r can be pretty much anywhere that doesn't
+ * conflict with something else. Reserving 1M for each of them at
+ * 0x0240-0x0250 and 0x0250-0x0260 should be plenty.
  *
- * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows
- *   for any boot script to be up to 1M, which is hopefully plenty.
+ * On ARM, both the DTB and any possible initrd must be loaded such that they
+ * fit inside the lowmem mapping in Linux. In practice, this usually means not
+ * more than ~700M away from the start of the kernel image but this number can
+ * be larger OR smaller depending on e.g. the 'vmalloc=xxxM' command line
+ * parameter given to the kernel. So reserving memory from low to high
+ * satisfies this constraint again. Reserving 1M at 0x0260-0x0270 for
+ * the DTB leaves rest of the free RAM to the initrd starting at 0x0270.
+ * Even with the smallest possible CPU-GPU memory split of the CPU getting
+ * only 64M, the remaining 25M starting at 0x0270 should allow quite
+ * large initrds before they start colliding with U-Boot.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
"fdt_high=" FDT_HIGH "\0" \
"initrd_high=" 

[U-Boot] [PATCH 1/2] rpi: Fix fdt_high & initrd_high for 64-bit builds

2018-04-20 Thread Tuomas Tynkkynen
The magic value that disables relocation is dependent on the CPU word
size, so the current '' is doing the wrong thing on aarch64.

Signed-off-by: Tuomas Tynkkynen 
---
 include/configs/rpi.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index 325e52a019..f1189a27f3 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -91,6 +91,14 @@
"stdout=serial,vidconsole\0" \
"stderr=serial,vidconsole\0"
 
+#ifdef CONFIG_ARM64
+#define FDT_HIGH ""
+#define INITRD_HIGH ""
+#else
+#define FDT_HIGH ""
+#define INITRD_HIGH ""
+#endif
+
 /*
  * Memory layout for where various images get loaded by boot scripts:
  *
@@ -122,8 +130,8 @@
  *   for any boot script to be up to 1M, which is hopefully plenty.
  */
 #define ENV_MEM_LAYOUT_SETTINGS \
-   "fdt_high=\0" \
-   "initrd_high=\0" \
+   "fdt_high=" FDT_HIGH "\0" \
+   "initrd_high=" INITRD_HIGH "\0" \
"fdt_addr_r=0x0100\0" \
"pxefile_addr_r=0x0010\0" \
"kernel_addr_r=0x0100\0" \
-- 
2.16.3

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


Re: [U-Boot] [PATCH] rpi: Adjust fdt_addr_r to a sane address

2018-04-20 Thread Tuomas Tynkkynen
Hi Alexander,

What do you think of these patches? I haven't done testing with the
big kernels / DTBs yet, just that my previously-working kernel still
boots.

Tuomas Tynkkynen (2):
  rpi: Fix fdt_high & initrd_high for 64-bit builds
  rpi: Change load addresses to make more room for the kernel & DTB

 include/configs/rpi.h | 73 ---
 1 file changed, 46 insertions(+), 27 deletions(-)

-- 
2.16.3

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


[U-Boot] [PATCH] arm64: zynqmp: Enable cadence WDT for zcu100

2018-04-20 Thread Michal Simek
Enable watchdog on zcu100 to make sure if there is a bug in the u-boot
there is proper reset.
Watchdog expires and PMU fw is informed and based on setting proper
action is taken.

The patch is enabling reset-on-timeout feature and also fixing fixed
clock rate for watchdog where 100MHz is max (and also default) clock value.

Signed-off-by: Michal Simek 
---

 arch/arm/dts/zynqmp-clk.dtsi| 2 +-
 arch/arm/dts/zynqmp-zcu100-revC.dts | 1 +
 configs/xilinx_zynqmp_zcu100_revC_defconfig | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/dts/zynqmp-clk.dtsi b/arch/arm/dts/zynqmp-clk.dtsi
index a8664e81870e..a795efdc15c8 100644
--- a/arch/arm/dts/zynqmp-clk.dtsi
+++ b/arch/arm/dts/zynqmp-clk.dtsi
@@ -219,7 +219,7 @@
 };
 
  {
-   clocks = <>;
+   clocks = <>;
 };
 
 _drm {
diff --git a/arch/arm/dts/zynqmp-zcu100-revC.dts 
b/arch/arm/dts/zynqmp-zcu100-revC.dts
index 38b8753da114..da5af96051d1 100644
--- a/arch/arm/dts/zynqmp-zcu100-revC.dts
+++ b/arch/arm/dts/zynqmp-zcu100-revC.dts
@@ -332,6 +332,7 @@
 
  {
status = "okay";
+   reset-on-timeout;
 };
 
 _ams {
diff --git a/configs/xilinx_zynqmp_zcu100_revC_defconfig 
b/configs/xilinx_zynqmp_zcu100_revC_defconfig
index 348c8c77cd41..db6ed1aa86eb 100644
--- a/configs/xilinx_zynqmp_zcu100_revC_defconfig
+++ b/configs/xilinx_zynqmp_zcu100_revC_defconfig
@@ -80,5 +80,7 @@ CONFIG_USB_ULPI=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DOWNLOAD=y
+CONFIG_WDT=y
+CONFIG_WDT_CDNS=y
 CONFIG_OF_LIBFDT_OVERLAY=y
 CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
-- 
2.17.0

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


Re: [U-Boot] [RFC PATCH v1 0/1] Migrate IMAGE_FORMAT_LEGACY to Kconfig

2018-04-20 Thread Alex Kiernan
On Fri, Apr 20, 2018 at 5:23 AM, Alex Kiernan  wrote:
> On Thu, Apr 19, 2018 at 8:39 PM, Tom Rini  wrote:
>> On Thu, Apr 19, 2018 at 04:52:30AM +, Alex Kiernan wrote:
>>>
>>> On the face of it, this is a straightforward moveconfig, but because
>>> of how CONFIG_FIT_SIGNATURE, CONFIG_IMAGE_FORMAT_LEGACY and
>>> CONFIG_DISABLE_IMAGE_LEGACY interacted when you enabled
>>> CONFIG_FIT_SIGNATURE, you got CONFIG_IMAGE_FORMAT_LEGACY disabled
>>> immediately unless you had some way of explicitly enabling it
>>> elsewhere.
>>>
>>> Kconfig doesn't give us this - CONFIG_IMAGE_FORMAT_LEGACY starts off
>>> enabled, CONFIG_FIT_SIGNATURE starts off disabled and if you enable
>>> CONFIG_FIT_SIGNATURE then CONFIG_IMAGE_FORMAT_LEGACY stays enabled.
>>>
>>> Is there some way to preserve the existing behaviour through Kconfig
>>> that I've failed to figure out?
>>
>> When I do these, it's a multi-step moveconfig.py that goes something
>> like:
>> - Introduce FOO (no deps)
>> - moveconfig.py -y it.
>> - Introduce BAR (no deps)
>> - moveconfig.py -y it.
>> - for FILE in configs/*defconfig;do grep -q FOO $FILE || echo '#
>>   CONFIG_FOO is not set' >> $FILE;done
>> - Repeat the for loop but for BAR.
>> - Introduce deps
>> - moveconfig.py -sC
>> - Build before/after for a few boards that I know are tricky, use
>>   buildman -SCvel/Ssdel to confirm size changes didn't happen.
>> - If good, world-build checking sizes.
>>
>> And in some cases like this particular one, there might need to be an
>> initial first comment to invert the logic, and as that can be tricky
>> when adding a new option that _should_ be default y, first I add it
>> without default y, moveconfig.py -y it, for loop like above, then add
>> default y and moveconfig.py -s.
>>
>
> Thanks, let me give that a go...
>

Having gone through that piece by piece, I'm pretty sure that
moveconfig has actually done the right thing. We've these
configurations which enable FIT_SIGNATURE without IMAGE_FORMAT_LEGACY:

am335x_boneblack_vboot_defconfig
conga-qeval20-qa3-e3845_defconfig
conga-qeval20-qa3-e3845-internal-uart_defconfig
controlcenterdc_defconfig
dfi-bt700-q7x-151_defconfig
minnowmax_defconfig
sandbox64_defconfig
sandbox_defconfig
sandbox_flattree_defconfig
sandbox_noblk_defconfig
sandbox_spl_defconfig
som-db5800-som-6867_defconfig
theadorable-x86-conga-qa3-e3845_defconfig
theadorable-x86-conga-qa3-e3845-pcie-x4_defconfig
theadorable-x86-dfi-bt700_defconfig

And checking each of them, they're IMAGE_FORMAT_LEGACY disabled after
the conversion.

I'll hang fire on sending a non-RFC v2 to see if there's any more comments.

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


[U-Boot] [PATCH] ARM: uniphier: select a correct mmc device before flashing images

2018-04-20 Thread Masahiro Yamada
Some boards support an SD card and an eMMC device at the same time.
Since both belong to 'mmc', they are identified by a device number.
When the device number of the eMMC is 1 instead 0, "mmc dev" command
must be performed to switch the target device before flashing images.

Signed-off-by: Masahiro Yamada 
---

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

diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 5d4e86d..f359d85 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -186,6 +186,7 @@
"setexpr tmp_addr $nor_base + 0x7 && " \
"tftpboot $tmp_addr $third_image\0" \
"emmcupdate=mmcsetn &&" \
+   "mmc dev $mmc_first_dev &&" \
"mmc partconf $mmc_first_dev 0 1 1 &&"  \
"tftpboot $second_image && " \
"mmc write $loadaddr 0 100 && " \
-- 
2.7.4

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


Re: [U-Boot] [PATCH 1/4] mmc: tmio: move clk_enable() to each driver's probe function

2018-04-20 Thread Masahiro Yamada
+CC Marek


2018-04-20 18:14 GMT+09:00 Masahiro Yamada :
> I need to differentiate the clock handling for uniphier-sd.  Move it
> to each driver's probe function from the tmio common code so that
> renesas-sdhi will not be affected.
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/mmc/renesas-sdhi.c | 23 +++
>  drivers/mmc/tmio-common.c  | 22 --
>  drivers/mmc/uniphier-sd.c  | 25 +
>  3 files changed, 48 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
> index 56a43ca..8e49b2f 100644
> --- a/drivers/mmc/renesas-sdhi.c
> +++ b/drivers/mmc/renesas-sdhi.c
> @@ -330,8 +330,10 @@ static const struct udevice_id renesas_sdhi_match[] = {
>
>  static int renesas_sdhi_probe(struct udevice *dev)
>  {
> +   struct tmio_sd_priv *priv = dev_get_priv(dev);
> u32 quirks = dev_get_driver_data(dev);
> struct fdt_resource reg_res;
> +   struct clk clk;
> DECLARE_GLOBAL_DATA_PTR;
> int ret;
>
> @@ -348,6 +350,27 @@ static int renesas_sdhi_probe(struct udevice *dev)
> quirks |= TMIO_SD_CAP_16BIT;
> }
>
> +   ret = clk_get_by_index(dev, 0, );
> +   if (ret < 0) {
> +   dev_err(dev, "failed to get host clock\n");
> +   return ret;
> +   }
> +
> +   /* set to max rate */
> +   priv->mclk = clk_set_rate(, ULONG_MAX);
> +   if (IS_ERR_VALUE(priv->mclk)) {
> +   dev_err(dev, "failed to set rate for host clock\n");
> +   clk_free();
> +   return priv->mclk;
> +   }
> +
> +   ret = clk_enable();
> +   clk_free();
> +   if (ret) {
> +   dev_err(dev, "failed to enable host clock\n");
> +   return ret;
> +   }
> +
> ret = tmio_sd_probe(dev, quirks);
>  #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
> if (!ret)
> diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c
> index 5f1c9c0..4ea6612 100644
> --- a/drivers/mmc/tmio-common.c
> +++ b/drivers/mmc/tmio-common.c
> @@ -713,7 +713,6 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks)
> struct tmio_sd_priv *priv = dev_get_priv(dev);
> struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
> fdt_addr_t base;
> -   struct clk clk;
> int ret;
>
> base = devfdt_get_addr(dev);
> @@ -728,27 +727,6 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks)
> device_get_supply_regulator(dev, "vqmmc-supply", >vqmmc_dev);
>  #endif
>
> -   ret = clk_get_by_index(dev, 0, );
> -   if (ret < 0) {
> -   dev_err(dev, "failed to get host clock\n");
> -   return ret;
> -   }
> -
> -   /* set to max rate */
> -   priv->mclk = clk_set_rate(, ULONG_MAX);
> -   if (IS_ERR_VALUE(priv->mclk)) {
> -   dev_err(dev, "failed to set rate for host clock\n");
> -   clk_free();
> -   return priv->mclk;
> -   }
> -
> -   ret = clk_enable();
> -   clk_free();
> -   if (ret) {
> -   dev_err(dev, "failed to enable host clock\n");
> -   return ret;
> -   }
> -
> ret = mmc_of_parse(dev, >cfg);
> if (ret < 0) {
> dev_err(dev, "failed to parse host caps\n");
> diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
> index 47379b0..bc6e41d 100644
> --- a/drivers/mmc/uniphier-sd.c
> +++ b/drivers/mmc/uniphier-sd.c
> @@ -32,6 +32,31 @@ static const struct udevice_id uniphier_sd_match[] = {
>
>  static int uniphier_sd_probe(struct udevice *dev)
>  {
> +   struct tmio_sd_priv *priv = dev_get_priv(dev);
> +   struct clk clk;
> +   int ret;
> +
> +   ret = clk_get_by_index(dev, 0, );
> +   if (ret < 0) {
> +   dev_err(dev, "failed to get host clock\n");
> +   return ret;
> +   }
> +
> +   /* set to max rate */
> +   priv->mclk = clk_set_rate(, ULONG_MAX);
> +   if (IS_ERR_VALUE(priv->mclk)) {
> +   dev_err(dev, "failed to set rate for host clock\n");
> +   clk_free();
> +   return priv->mclk;
> +   }
> +
> +   ret = clk_enable();
> +   clk_free();
> +   if (ret) {
> +   dev_err(dev, "failed to enable host clock\n");
> +   return ret;
> +   }
> +
> return tmio_sd_probe(dev, 0);
>  }
>
> --
> 2.7.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> https://lists.denx.de/listinfo/u-boot



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


[U-Boot] [PATCH 4/4] clk: uniphier: disable SPL_CLK

2018-04-20 Thread Masahiro Yamada
The last clock consumer in SPL, SD/eMMC driver, gave up using the
clock driver.  The clock driver is only used in U-Boot proper.

Signed-off-by: Masahiro Yamada 
---

 drivers/clk/uniphier/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/clk/uniphier/Kconfig b/drivers/clk/uniphier/Kconfig
index 3666d84..a26ca8c 100644
--- a/drivers/clk/uniphier/Kconfig
+++ b/drivers/clk/uniphier/Kconfig
@@ -2,7 +2,6 @@ config CLK_UNIPHIER
def_bool y
depends on ARCH_UNIPHIER
select CLK
-   select SPL_CLK if SPL
help
  Support for clock controllers on UniPhier SoCs.
  Say Y if you want to control clocks provided by System Control
-- 
2.7.4

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


[U-Boot] [PATCH 3/4] ARM: dts: uniphier: drop u-boot, dm-pre-reloc from SD/eMMC clock node

2018-04-20 Thread Masahiro Yamada
Now that the SD/eMMC driver does not use the clock driver in SPL,
remove u-boot,dm-pre-reloc properties to let the fdtgrep tool drop
the unnecessary nodes.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-v7-u-boot.dtsi | 16 
 1 file changed, 16 deletions(-)

diff --git a/arch/arm/dts/uniphier-v7-u-boot.dtsi 
b/arch/arm/dts/uniphier-v7-u-boot.dtsi
index 0094a45..9459bf0 100644
--- a/arch/arm/dts/uniphier-v7-u-boot.dtsi
+++ b/arch/arm/dts/uniphier-v7-u-boot.dtsi
@@ -14,22 +14,6 @@
u-boot,dm-pre-reloc;
};
 
-   mioctrl@5981 {
-   u-boot,dm-pre-reloc;
-
-   clock {
-   u-boot,dm-pre-reloc;
-   };
-   };
-
-   sdctrl@5981 {
-   u-boot,dm-pre-reloc;
-
-   clock {
-   u-boot,dm-pre-reloc;
-   };
-   };
-
soc-glue@5f80 {
u-boot,dm-pre-reloc;
 
-- 
2.7.4

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


[U-Boot] [PATCH 1/4] mmc: tmio: move clk_enable() to each driver's probe function

2018-04-20 Thread Masahiro Yamada
I need to differentiate the clock handling for uniphier-sd.  Move it
to each driver's probe function from the tmio common code so that
renesas-sdhi will not be affected.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/renesas-sdhi.c | 23 +++
 drivers/mmc/tmio-common.c  | 22 --
 drivers/mmc/uniphier-sd.c  | 25 +
 3 files changed, 48 insertions(+), 22 deletions(-)

diff --git a/drivers/mmc/renesas-sdhi.c b/drivers/mmc/renesas-sdhi.c
index 56a43ca..8e49b2f 100644
--- a/drivers/mmc/renesas-sdhi.c
+++ b/drivers/mmc/renesas-sdhi.c
@@ -330,8 +330,10 @@ static const struct udevice_id renesas_sdhi_match[] = {
 
 static int renesas_sdhi_probe(struct udevice *dev)
 {
+   struct tmio_sd_priv *priv = dev_get_priv(dev);
u32 quirks = dev_get_driver_data(dev);
struct fdt_resource reg_res;
+   struct clk clk;
DECLARE_GLOBAL_DATA_PTR;
int ret;
 
@@ -348,6 +350,27 @@ static int renesas_sdhi_probe(struct udevice *dev)
quirks |= TMIO_SD_CAP_16BIT;
}
 
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0) {
+   dev_err(dev, "failed to get host clock\n");
+   return ret;
+   }
+
+   /* set to max rate */
+   priv->mclk = clk_set_rate(, ULONG_MAX);
+   if (IS_ERR_VALUE(priv->mclk)) {
+   dev_err(dev, "failed to set rate for host clock\n");
+   clk_free();
+   return priv->mclk;
+   }
+
+   ret = clk_enable();
+   clk_free();
+   if (ret) {
+   dev_err(dev, "failed to enable host clock\n");
+   return ret;
+   }
+
ret = tmio_sd_probe(dev, quirks);
 #if CONFIG_IS_ENABLED(MMC_HS200_SUPPORT)
if (!ret)
diff --git a/drivers/mmc/tmio-common.c b/drivers/mmc/tmio-common.c
index 5f1c9c0..4ea6612 100644
--- a/drivers/mmc/tmio-common.c
+++ b/drivers/mmc/tmio-common.c
@@ -713,7 +713,6 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks)
struct tmio_sd_priv *priv = dev_get_priv(dev);
struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
fdt_addr_t base;
-   struct clk clk;
int ret;
 
base = devfdt_get_addr(dev);
@@ -728,27 +727,6 @@ int tmio_sd_probe(struct udevice *dev, u32 quirks)
device_get_supply_regulator(dev, "vqmmc-supply", >vqmmc_dev);
 #endif
 
-   ret = clk_get_by_index(dev, 0, );
-   if (ret < 0) {
-   dev_err(dev, "failed to get host clock\n");
-   return ret;
-   }
-
-   /* set to max rate */
-   priv->mclk = clk_set_rate(, ULONG_MAX);
-   if (IS_ERR_VALUE(priv->mclk)) {
-   dev_err(dev, "failed to set rate for host clock\n");
-   clk_free();
-   return priv->mclk;
-   }
-
-   ret = clk_enable();
-   clk_free();
-   if (ret) {
-   dev_err(dev, "failed to enable host clock\n");
-   return ret;
-   }
-
ret = mmc_of_parse(dev, >cfg);
if (ret < 0) {
dev_err(dev, "failed to parse host caps\n");
diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index 47379b0..bc6e41d 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -32,6 +32,31 @@ static const struct udevice_id uniphier_sd_match[] = {
 
 static int uniphier_sd_probe(struct udevice *dev)
 {
+   struct tmio_sd_priv *priv = dev_get_priv(dev);
+   struct clk clk;
+   int ret;
+
+   ret = clk_get_by_index(dev, 0, );
+   if (ret < 0) {
+   dev_err(dev, "failed to get host clock\n");
+   return ret;
+   }
+
+   /* set to max rate */
+   priv->mclk = clk_set_rate(, ULONG_MAX);
+   if (IS_ERR_VALUE(priv->mclk)) {
+   dev_err(dev, "failed to set rate for host clock\n");
+   clk_free();
+   return priv->mclk;
+   }
+
+   ret = clk_enable();
+   clk_free();
+   if (ret) {
+   dev_err(dev, "failed to enable host clock\n");
+   return ret;
+   }
+
return tmio_sd_probe(dev, 0);
 }
 
-- 
2.7.4

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


[U-Boot] [PATCH 2/4] mmc: uniphier-sd: skip clock set-up for SPL

2018-04-20 Thread Masahiro Yamada
The size of SPL is hitting the limit (64KB) for uniphier_v7_defconfig.
When booting from SD/eMMC, obviously its clock has been properly set up
by the boot ROM.  Acutually, no need to re-initialize the clock in SPL.

Using a clock driver would generalize the SoC specific code, but
solving the memory footprint problem would win.

Signed-off-by: Masahiro Yamada 
---

 drivers/mmc/uniphier-sd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/mmc/uniphier-sd.c b/drivers/mmc/uniphier-sd.c
index bc6e41d..61f8da4 100644
--- a/drivers/mmc/uniphier-sd.c
+++ b/drivers/mmc/uniphier-sd.c
@@ -33,6 +33,7 @@ static const struct udevice_id uniphier_sd_match[] = {
 static int uniphier_sd_probe(struct udevice *dev)
 {
struct tmio_sd_priv *priv = dev_get_priv(dev);
+#ifndef CONFIG_SPL_BUILD
struct clk clk;
int ret;
 
@@ -56,6 +57,9 @@ static int uniphier_sd_probe(struct udevice *dev)
dev_err(dev, "failed to enable host clock\n");
return ret;
}
+#else
+   priv->mclk = 1;
+#endif
 
return tmio_sd_probe(dev, 0);
 }
-- 
2.7.4

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


[U-Boot] [PATCH 0/4] ARM: uniphier: decrease the SPL image size to fix uniphier_v7_defconfig

2018-04-20 Thread Masahiro Yamada

Usually, the image size tends to increase gradually.
Finally, it is hitting the size limit for my board.

One size consuming part is the clock driver, and it is only used
by the SD/eMMC driver in SPL.  By disabling it, I can save lots of space.



Masahiro Yamada (4):
  mmc: tmio: move clk_enable() to each driver's probe function
  mmc: uniphier-sd: skip clock set-up for SPL
  ARM: dts: uniphier: drop u-boot,dm-pre-reloc from SD/eMMC clock node
  clk: uniphier: disable SPL_CLK

 arch/arm/dts/uniphier-v7-u-boot.dtsi | 16 
 drivers/clk/uniphier/Kconfig |  1 -
 drivers/mmc/renesas-sdhi.c   | 23 +++
 drivers/mmc/tmio-common.c| 22 --
 drivers/mmc/uniphier-sd.c| 29 +
 5 files changed, 52 insertions(+), 39 deletions(-)

-- 
2.7.4

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


Re: [U-Boot] [PATCH 4/6] uniphier: psci: save context id in cpu_on command

2018-04-20 Thread Masahiro Yamada
2018-04-16 17:15 GMT+09:00 Patrick Delaunay :
> Replace the psci_save_target_pc call by the new function
> psci_save(cpu, pc,context_id)
>
> Signed-off-by: Patrick Delaunay 
> ---
>


Acked-by: Masahiro Yamada 

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


Re: [U-Boot] [PATCH v2 1/3] arm: psci: save context id for cpu_on PSCI command

2018-04-20 Thread Masahiro Yamada
2018-04-16 17:13 GMT+09:00 Patrick Delaunay :
> Save and use the 3rd parameter of PSCI CPU_ON request: context_id.
>
> The context_id parameter is only meaningful to the caller.
> U-Boot PSCI preserves a copy of the value passed in this parameter.
> Following wakeup from a  powerdown state, U-BOOT PSCI places
> this value in R0 when it first enters the OS.
>
> NB: this context id is not (yet?) used by Linux but it is mandatory
> to be PSCI compliant.
>
> update armv7 psci functions:
> - psci_save_target_pc(): keep for backward compatibility with
>   current platform (only save PC and force context id to 0)
>   => should be removed when all platform migrate to the new API
>
> - psci_save(): new API to use by ARMv7 platform with PSCI,
>   save pc (= entry_point_address) and context_id
>
> Signed-off-by: Patrick Delaunay 
> ---
>
> Changes in v2: None


Reviewed-by: Masahiro Yamada 




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


[U-Boot] [[RESEND] PATCH v3 2/2] mmc: zynq_sdhci: use correct quirk if CONFIG_ZYNQ_HISPD_BROKEN is defined

2018-04-20 Thread Hannes Schmelzer
The 'SDHCI_QUIRK_NO_HISPD_BIT' is used wrong here. The purpose of this
quirk is to tell the sdhci-driver that the IP-core doesn't have a "high-
speed-enable" bit in its registers.

With this commit we change this to the correct quirk:
SDHCI_QUIRK_BROKEN_HISPD_MODE

Signed-off-by: Hannes Schmelzer 
---

Changes in v3: None
Changes in v2: None

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

diff --git a/drivers/mmc/zynq_sdhci.c b/drivers/mmc/zynq_sdhci.c
index 9463a06..76fe97f 100644
--- a/drivers/mmc/zynq_sdhci.c
+++ b/drivers/mmc/zynq_sdhci.c
@@ -54,7 +54,7 @@ static int arasan_sdhci_probe(struct udevice *dev)
   SDHCI_QUIRK_BROKEN_R1B;
 
 #ifdef CONFIG_ZYNQ_HISPD_BROKEN
-   host->quirks |= SDHCI_QUIRK_NO_HISPD_BIT;
+   host->quirks |= SDHCI_QUIRK_BROKEN_HISPD_MODE;
 #endif
 
host->max_clk = clock;
-- 
2.7.4


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


[U-Boot] [[RESEND] PATCH v3 1/2] mmc: sdhci: add SDHCI_QUIRK_BROKEN_HISPD_MODE

2018-04-20 Thread Hannes Schmelzer
From: Hannes Schmelzer 

Some IP-core implementations of the SDHCI have different troubles on the
silicon where they are placed.

On ZYNQ platform for example Xilinx doesn't accept the hold timing of an
eMMC chip which operates in High-Speed mode and must be forced to
operate in non high-speed mode. To get rid of this
"SDHCI_QUIRK_BROKEN_HISPD_MODE" is introduced.

For more details about this refer to the Xilinx answer-recor #5
https://www.xilinx.com/support/answers/5.html

This commit:
- doesn't set HISPD bit on the host-conroller
- reflects this fact within the host-controller capabilities

Upon this the layer above (mmc-driver) can setup the card correctly.

Otherwise the MMC card will be switched into high-speed mode and causes
possible timing violation on the host-controller side.

Signed-off-by: Hannes Schmelzer 

Signed-off-by: Hannes Schmelzer 
---

Changes in v3:
- cleanup sign-off tag
- fix typo (sdci -> sdhci)
- combine the if instruction SDHCI_QUIRK_BROKEN_HISPD_MODE with the
  existing SDHCI_QUIRK_NO_HISPD_BIT

Changes in v2:
- don't use the SDHCI_QUIRK_NO_HISPD_BIT for getting rid of this,
since this quirk was designed for another purpose. Instead introduce the
new SDHCI_QUIRK_BROKEN_HISPD_MODE quirk.

 drivers/mmc/sdhci.c | 8 +++-
 include/sdhci.h | 6 ++
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c
index d31793a..1e5e8a6 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -462,7 +462,8 @@ static int sdhci_set_ios(struct mmc *mmc)
else
ctrl &= ~SDHCI_CTRL_HISPD;
 
-   if (host->quirks & SDHCI_QUIRK_NO_HISPD_BIT)
+   if ((host->quirks & SDHCI_QUIRK_NO_HISPD_BIT) ||
+   (host->quirks & SDHCI_QUIRK_BROKEN_HISPD_MODE))
ctrl &= ~SDHCI_CTRL_HISPD;
 
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
@@ -602,6 +603,11 @@ int sdhci_setup_cfg(struct mmc_config *cfg, struct 
sdhci_host *host,
cfg->host_caps &= ~MMC_MODE_8BIT;
}
 
+   if (host->quirks & SDHCI_QUIRK_BROKEN_HISPD_MODE) {
+   cfg->host_caps &= ~MMC_MODE_HS;
+   cfg->host_caps &= ~MMC_MODE_HS_52MHz;
+   }
+
if (host->host_caps)
cfg->host_caps |= host->host_caps;
 
diff --git a/include/sdhci.h b/include/sdhci.h
index 7e84012..ed35f04 100644
--- a/include/sdhci.h
+++ b/include/sdhci.h
@@ -213,6 +213,12 @@
 #define SDHCI_QUIRK_BROKEN_R1B (1 << 2)
 #define SDHCI_QUIRK_NO_HISPD_BIT   (1 << 3)
 #define SDHCI_QUIRK_BROKEN_VOLTAGE (1 << 4)
+/*
+ * SDHCI_QUIRK_BROKEN_HISPD_MODE
+ * the hardware cannot operate correctly in high-speed mode,
+ * this quirk forces the sdhci host-controller to non high-speed mode
+ */
+#define SDHCI_QUIRK_BROKEN_HISPD_MODE  BIT(5)
 #define SDHCI_QUIRK_WAIT_SEND_CMD  (1 << 6)
 #define SDHCI_QUIRK_USE_WIDE8  (1 << 8)
 
-- 
2.7.4


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


[U-Boot] [PATCH] ARM: uniphier: increase CONFIG_SYS_MONITOR_LEN

2018-04-20 Thread Masahiro Yamada
With the recent changes, the size of the U-Boot proper image for
uniphier_v7_defconfig exceeded the current limit, 512KB, then SPL
fails to load the whole of the U-Boot proper.  Increase the size.

Signed-off-by: Masahiro Yamada 
---

 include/configs/uniphier.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index d4f6fe1..03a45b2 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -33,7 +33,7 @@
 
 #define CONFIG_SYS_MAX_FLASH_SECT  256
 #define CONFIG_SYS_MONITOR_BASE0
-#define CONFIG_SYS_MONITOR_LEN 0x0008  /* 512KB */
+#define CONFIG_SYS_MONITOR_LEN 0x000C  /* 768KB */
 #define CONFIG_SYS_FLASH_BASE  0
 
 /*
-- 
2.7.4

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


[U-Boot] [PATCH] ARM: dts: sti: Add stih410-b2260-u-boot.dtsi

2018-04-20 Thread Patrice Chotard
STiH410 has 2 PHYs wired on the DWC3 IP, USB2 and USB3 PHYs.
As currently no U-boot driver is available for the USB3 PHY and to avoid
issue during DWC3 drive probe, we use DWC3 IP with only USB2 PHY
using stih410-b2260-u-boot.dtsi file.

Fixes: 2fd4242cc50e ("ubs: xhci-dwc3: Enable USB3 PHY when available")

Signed-off-by: Patrice Chotard 
---

 arch/arm/dts/stih410-b2260-u-boot.dtsi | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 arch/arm/dts/stih410-b2260-u-boot.dtsi

diff --git a/arch/arm/dts/stih410-b2260-u-boot.dtsi 
b/arch/arm/dts/stih410-b2260-u-boot.dtsi
new file mode 100644
index ..83916319fc1e
--- /dev/null
+++ b/arch/arm/dts/stih410-b2260-u-boot.dtsi
@@ -0,0 +1,16 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2018, STMicroelectronics - All Rights Reserved
+ * Author(s): Patrice Chotard,  for STMicroelectronics.
+ *
+ */
+
+/{
+   soc {
+   st_dwc3: dwc3@8f94000 {
+   dwc3: dwc3@990 {
+   phys = <_picophy0>;
+   };
+   };
+   };
+};
-- 
1.9.1

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


Re: [U-Boot] [PATCH 1/2] nand: zynq: Fix driver initialization

2018-04-20 Thread Michal Simek
Hi Ezequiel,

On 19.4.2018 17:16, Ezequiel Garcia wrote:
> Hi Michal,
> 
> On 19 April 2018 at 08:10, Michal Simek  wrote:
>> From: Ezequiel Garcia 
>>
>> This driver is currently broken, refusing to initialize properly.
>>
>> The reason is that get_nand_dev_by_index() was being called before
>> nand_register(), thus returning a pointer into uninitialized memory.
>> In other words, the struct mtd_info used by the driver is total junk.
>>
>> Fix it by getting the correct struct mtd_info, via nand_to_mtd()
>> on the driver's struct nand_chip.
>>
>> Tested on a custom board, where the CPU is halted without this patch.
>>
>> Signed-off-by: Ezequiel Garcia 
>> Reviewed-by: Michal Simek 
>> Signed-off-by: Michal Simek 
> 
> Thanks for collecting these and submitting them!
> 
> BTW, I thought there was no need for a reviewed-by on top
> of a signed-off-by. It's kind of assumed that if you are signing
> something, you have reviewed it in the first place.
> 
> Or at least that's how I've been doing it.

My initial goal was to send it without my SoB line but my good git setup
is adding it automatically. I didn't touch your patches that's why I
wanted to say that I have reviewed it and at the end my SoB line will be
there too because it will go via my tree.

Thanks,
Michal


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


Re: [U-Boot] [PATCH v1 05/16] arm: socfpga: misc: Add CONFIG_SYS_L2_PL310 switch

2018-04-20 Thread Ley Foon Tan
On Thu, Apr 19, 2018 at 4:19 PM, Marek Vasut  wrote:
> On 04/19/2018 07:15 AM, See, Chin Liang wrote:
>> On Thu, 2018-04-19 at 04:47 +0200, Marek Vasut wrote:
>>> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:

 Add CONFIG_SYS_L2_PL310 conditional build.
>>> Why ?
>>>
>>
>> In ARM64, L2 cache controller is accessed through processor registers.
>> Hence we shall make this conditional in order this file can be shared
>> across SOCFPGAs.
>
> That should be in the patch description .
> Do you ever add the PL310 register access on S10 later in the set?
>
> --
Okay, will update description.
No, S10 doesn't use PL310 registers.

Thanks.

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


[U-Boot] [PATCH] arm64: zynqmp: Setup MMU map for DDR at run time

2018-04-20 Thread Michal Simek
From: Nitin Jain 

This patch used for filling the MMU map for DDR at run time based
information read from Device Tree or automatically detected from static
configuration.

Signed-off-by: Nitin Jain 
Signed-off-by: Siva Durga Prasad Paladugu 
Signed-off-by: Michal Simek 
---

 arch/arm/cpu/armv8/zynqmp/cpu.c  | 84 
 arch/arm/include/asm/arch-zynqmp/sys_proto.h |  2 +-
 board/xilinx/zynqmp/zynqmp.c | 22 -
 3 files changed, 74 insertions(+), 34 deletions(-)

diff --git a/arch/arm/cpu/armv8/zynqmp/cpu.c b/arch/arm/cpu/armv8/zynqmp/cpu.c
index 14e7d4006494..5db5fafc6f65 100644
--- a/arch/arm/cpu/armv8/zynqmp/cpu.c
+++ b/arch/arm/cpu/armv8/zynqmp/cpu.c
@@ -16,16 +16,28 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-static struct mm_region zynqmp_mem_map[] = {
+/*
+ * Number of filled static entries and also the first empty
+ * slot in zynqmp_mem_map.
+ */
+#define ZYNQMP_MEM_MAP_USED4
+
 #if !defined(CONFIG_ZYNQMP_NO_DDR)
-   {
-   .virt = 0x0UL,
-   .phys = 0x0UL,
-   .size = 0x8000UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   },
+#define DRAM_BANKS CONFIG_NR_DRAM_BANKS
+#else
+#define DRAM_BANKS 0
 #endif
+
+#if defined(CONFIG_DEFINE_TCM_OCM_MMAP)
+#define TCM_MAP 1
+#else
+#define TCM_MAP 0
+#endif
+
+/* +1 is end of list which needs to be empty */
+#define ZYNQMP_MEM_MAP_MAX (ZYNQMP_MEM_MAP_USED + DRAM_BANKS + TCM_MAP + 1)
+
+static struct mm_region zynqmp_mem_map[ZYNQMP_MEM_MAP_MAX] = {
{
.virt = 0x8000UL,
.phys = 0x8000UL,
@@ -33,8 +45,7 @@ static struct mm_region zynqmp_mem_map[] = {
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   },
-   {
+   }, {
.virt = 0xf800UL,
.phys = 0xf800UL,
.size = 0x07e0UL,
@@ -42,42 +53,51 @@ static struct mm_region zynqmp_mem_map[] = {
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
}, {
-#if defined(CONFIG_DEFINE_TCM_OCM_MMAP)
-   .virt = 0xffe0UL,
-   .phys = 0xffe0UL,
-   .size = 0x0020UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   }, {
-#endif
.virt = 0x4UL,
.phys = 0x4UL,
.size = 0x4UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   },
-#if !defined(CONFIG_ZYNQMP_NO_DDR)
-   {
-   .virt = 0x8UL,
-   .phys = 0x8UL,
-   .size = 0x8UL,
-   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
-PTE_BLOCK_INNER_SHARE
-   },
-#endif
-   {
+   }, {
.virt = 0x10UL,
.phys = 0x10UL,
.size = 0xf0UL,
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE |
 PTE_BLOCK_PXN | PTE_BLOCK_UXN
-   }, {
-   /* List terminator */
-   0,
}
 };
+
+void mem_map_fill(void)
+{
+   int banks = ZYNQMP_MEM_MAP_USED;
+
+#if defined(CONFIG_DEFINE_TCM_OCM_MMAP)
+   zynqmp_mem_map[banks].virt = 0xffe0UL;
+   zynqmp_mem_map[banks].phys = 0xffe0UL;
+   zynqmp_mem_map[banks].size = 0x0020UL;
+   zynqmp_mem_map[banks].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_INNER_SHARE;
+   banks = banks + 1;
+#endif
+
+#if !defined(CONFIG_ZYNQMP_NO_DDR)
+   for (int i = 0; i < CONFIG_NR_DRAM_BANKS; i++) {
+   /* Skip empty banks */
+   if (!gd->bd->bi_dram[i].size)
+   break;
+
+   zynqmp_mem_map[banks].virt = gd->bd->bi_dram[i].start;
+   zynqmp_mem_map[banks].phys = gd->bd->bi_dram[i].start;
+   zynqmp_mem_map[banks].size = gd->bd->bi_dram[i].size;
+   zynqmp_mem_map[banks].attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+ PTE_BLOCK_INNER_SHARE;
+   banks = banks + 1;
+   }
+#endif
+}
+
 struct mm_region *mem_map = zynqmp_mem_map;
 
 u64 get_page_table_size(void)
diff --git a/arch/arm/include/asm/arch-zynqmp/sys_proto.h 
b/arch/arm/include/asm/arch-zynqmp/sys_proto.h
index 3daf0e81d80c..d11c0782b8dd 100644
--- a/arch/arm/include/asm/arch-zynqmp/sys_proto.h
+++ b/arch/arm/include/asm/arch-zynqmp/sys_proto.h
@@ -46,7 +46,7 @@ int invoke_smc(u32 pm_api_id, u32 arg0, u32 

Re: [U-Boot] [PATCH v1 01/16] arm: socfpga: stratix10: Add base address map for Statix10 SoC

2018-04-20 Thread Ley Foon Tan
On Thu, 2018-04-19 at 05:02 +0200, Marek Vasut wrote:
> On 04/19/2018 11:50 AM, Ley Foon Tan wrote:
> > 
> > Add the base address map for Statix10 SoC
> > 
> > Signed-off-by: Chin Liang See 
> > Signed-off-by: Ley Foon Tan 
> > ---
> >  arch/arm/mach-socfpga/include/mach/base_addr_s10.h |   38
> > 
> >  1 files changed, 38 insertions(+), 0 deletions(-)
> >  create mode 100644 arch/arm/mach-
> > socfpga/include/mach/base_addr_s10.h
> > 
> > diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> > b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> > new file mode 100644
> > index 000..e18d2bf
> > --- /dev/null
> > +++ b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
> > @@ -0,0 +1,38 @@
> > +/* SPDX-License-Identifier: GPL-2.0
> > + *
> > + * Copyright (C) 2016-2018 Intel Corporation 
> > + *
> > + */
> > +
> > +#ifndef _SOCFPGA_S10_BASE_HARDWARE_H_
> > +#define _SOCFPGA_S10_BASE_HARDWARE_H_
> > +
> > +#define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xf8000400
> > +#define SOCFPGA_HMC_MMR_IO48_ADDRESS   0xf801
> > +#define SOCFPGA_SDR_ADDRESS0xf8011000
> > +#define SOCFPGA_SMMU_ADDRESS   0xfa00
> > +#define SOCFPGA_MAILBOX_ADDRESS0xffA3
> > +#define SOCFPGA_UART0_ADDRESS  0xffc02000
> > +#define SOCFPGA_UART1_ADDRESS  0xffc02100
> > +#define SOCFPGA_L4WD0_ADDRESS  0xffd00200
> > +#define SOCFPGA_L4WD1_ADDRESS  0xffd00300
> > +#define SOCFPGA_L4WD2_ADDRESS  0xffd00400
> > +#define SOCFPGA_L4WD3_ADDRESS  0xffd00500
> > +#define SOCFPGA_GTIMER_SEC_ADDRESS 0xffd01000
> > +#define SOCFPGA_GTIMER_NSEC_ADDRESS0xffd02000
> > +#define SOCFPGA_CLKMGR_ADDRESS 0xffd1
> > +#define SOCFPGA_RSTMGR_ADDRESS 0xffd11000
> > +#define SOCFPGA_SYSMGR_ADDRESS 0xffd12000
> > +#define SOCFPGA_PINMUX_DEDICATED_IO_ADDRESS0xffd13000
> > +#define SOCFPGA_FIREWALL_L4_PER0xffd21000
> > +#define SOCFPGA_FIREWALL_L4_SYS0xffd21100
> > +#define SOCFPGA_FIREWALL_SOC2FPGA  0xffd21200
> > +#define SOCFPGA_FIREWALL_LWSOC2FPGA0xffd21300
> > +#define SOCFPGA_FIREWALL_TCU   0xffd21400
> > +#define SOCFPGA_DMANONSECURE_ADDRESS   0xffda
> > +#define SOCFPGA_DMASECURE_ADDRESS  0xffda1000
> > +#define SOCFPGA_OCRAM_ADDRESS  0xffe0
> > +#define GICD_BASE  0xfffc1000
> > +#define GICC_BASE  0xfffc2000
> How much of this can come from DT ?
> 

Just found out Dinh already upstreamed this patch. BTW, we will try to 
use DT when it is possible.

Thanks.

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


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

2018-04-20 Thread Michal Simek
Hi Alex,

On 19.4.2018 18:48, Alexander Graf wrote:
> On 04/18/2018 03:11 PM, Michal Simek wrote:
>> Xilinx ZynqMP also contains dual Cortex R5 which can run U-Boot.
>> This patch is adding minimal support to get U-Boot boot.
>> DDR needs to be partitioned. Console is done via Cadence uart driver and
>> the first Cadence Triple Timer Counter is used for time.
>>
>> This configuration with uart1 was tested on zcu100-revC.
>>
>> U-Boot 2018.05-rc2-00021-gd058a08d907d (Apr 18 2018 - 14:11:27 +0200)
>>
>> Model: Xilinx ZynqMP R5
>> DRAM:  512 MiB
>> WARNING: Caches not enabled
>> MMC:
>> In:    serial@ff01
>> Out:   serial@ff01
>> Err:   serial@ff01
>> Net:   Net Initialization Skipped
>> No ethernet found.
>> ZynqMP r5>
>>
>> There are two ways how to run this on ZynqMP.
>> 1. Run from ZynqMP arm64
>> tftpb 2000 u-boot-r5.elf
>> setenv autostart no && bootelf -p 2000
>> cpu 4 disable && cpu 4 release 1000 lockstep
>> or
>> cpu 4 disable && cpu 4 release 1000 split
>>
>> 2. Load via jtag when directly to R5
>>
>> Signed-off-by: Michal Simek 
>> ---
>>
>>   MAINTAINERS    |  6 +++
>>   arch/arm/Kconfig   | 16 +++
>>   arch/arm/Makefile  |  1 +
>>   arch/arm/cpu/armv7r/Makefile   |  4 ++
>>   arch/arm/cpu/armv7r/config.mk  |  3 ++
>>   arch/arm/cpu/armv7r/cpu.c  | 24 ++
>>   arch/arm/cpu/armv7r/start.S    | 17 +++
>>   arch/arm/dts/Makefile  |  2 +
>>   arch/arm/dts/zynqmp-r5.dts | 73 ++
>>   arch/arm/mach-zynqmp-r5/Kconfig    | 27 +++
>>   arch/arm/mach-zynqmp-r5/Makefile   |  3 ++
>>   arch/arm/mach-zynqmp-r5/cpu.c  | 15 ++
>>   board/xilinx/zynqmp_r5/MAINTAINERS |  7 +++
>>   board/xilinx/zynqmp_r5/Makefile    |  6 +++
>>   board/xilinx/zynqmp_r5/board.c | 25 ++
>>   configs/xilinx_zynqmp_r5_defconfig | 16 +++
>>   drivers/serial/Kconfig |  2 +-
>>   include/configs/xilinx_zynqmp_r5.h | 49 
>>   18 files changed, 295 insertions(+), 1 deletion(-)
>>   create mode 100644 arch/arm/cpu/armv7r/Makefile
>>   create mode 100644 arch/arm/cpu/armv7r/config.mk
>>   create mode 100644 arch/arm/cpu/armv7r/cpu.c
>>   create mode 100644 arch/arm/cpu/armv7r/start.S
>>   create mode 100644 arch/arm/dts/zynqmp-r5.dts
>>   create mode 100644 arch/arm/mach-zynqmp-r5/Kconfig
>>   create mode 100644 arch/arm/mach-zynqmp-r5/Makefile
>>   create mode 100644 arch/arm/mach-zynqmp-r5/cpu.c
>>   create mode 100644 board/xilinx/zynqmp_r5/MAINTAINERS
>>   create mode 100644 board/xilinx/zynqmp_r5/Makefile
>>   create mode 100644 board/xilinx/zynqmp_r5/board.c
>>   create mode 100644 configs/xilinx_zynqmp_r5_defconfig
>>   create mode 100644 include/configs/xilinx_zynqmp_r5.h
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 76c6f71d6af2..c78a698f75b0 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -293,6 +293,12 @@ F:    include/zynqmppl.h
>>   F:    tools/zynqimage.c
>>   N:    zynqmp
>>   +ARM ZYNQMP R5
>> +M:    Michal Simek 
>> +S:    Maintained
>> +T:    git git://git.denx.de/u-boot-microblaze.git
>> +F:    arch/arm/mach-zynqmp-r5/
>> +
>>   BUILDMAN
>>   M:    Simon Glass 
>>   S:    Maintained
>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>> index 7212fc5afa72..c6d8d4d4984d 100644
>> --- a/arch/arm/Kconfig
>> +++ b/arch/arm/Kconfig
>> @@ -192,6 +192,10 @@ config CPU_V7M
>>   select THUMB2_KERNEL
>>   select SYS_CACHE_SHIFT_5
>>   +config CPU_V7R
>> +    bool
>> +    select SYS_CACHE_SHIFT_6
> 
> I think you want to split out Cortex-R support from platform support for
> zynqmp-r5.

R5 support is quite minimal that's why I kept it like this. But I can
split it with no problem.

> 
>> +
>>   config CPU_PXA
>>   bool
>>   select SYS_CACHE_SHIFT_5
>> @@ -209,6 +213,7 @@ config SYS_CPU
>>   default "arm1176" if CPU_ARM1176
>>   default "armv7" if CPU_V7
>>   default "armv7m" if CPU_V7M
>> +    default "armv7r" if CPU_V7R
>>   default "pxa" if CPU_PXA
>>   default "sa1100" if CPU_SA1100
>>   default "armv8" if ARM64
>> @@ -223,6 +228,7 @@ config SYS_ARM_ARCH
>>   default 6 if CPU_ARM1176
>>   default 7 if CPU_V7
>>   default 7 if CPU_V7M
>> +    default 7 if CPU_V7R
>>   default 5 if CPU_PXA
>>   default 4 if CPU_SA1100
>>   default 8 if ARM64
>> @@ -764,6 +770,14 @@ config ARCH_ZYNQ
>>   imply FAT_WRITE
>>   imply CMD_SPL
>>   +config ARCH_ZYNQMP_R5
>> +    bool "Xilinx ZynqMP R5 based platform"
>> +    select CPU_V7R
>> +    select OF_CONTROL
>> +    select DM
>> +    select DM_SERIAL
>> +    select CLK
>> +
>>   config ARCH_ZYNQMP
>>   bool "Xilinx ZynqMP based platform"
>>   select ARM64
>> @@ -1282,6 +1296,8 @@ source "arch/arm/cpu/armv7/vf610/Kconfig"
>>     source "arch/arm/mach-zynq/Kconfig"
>>   +source "arch/arm/mach-zynqmp-r5/Kconfig"
>> +

[U-Boot] [PATCH v1 2/2] serial: serial_stm32: Rename status register flags

2018-04-20 Thread Patrice Chotard
Uart status register is named USART_ISR on STM32F7, STM32H7
and STM32MP1 SoCs family, but USART_SR only on STM32F4 SoCs.

Use USART_ISR_ prefix instead of USART_SR_ .

Signed-off-by: Patrice Chotard 
---

 drivers/serial/serial_stm32.c | 10 +-
 drivers/serial/serial_stm32.h |  6 +++---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/serial/serial_stm32.c b/drivers/serial/serial_stm32.c
index 8275a76bf10b..5045be4bf950 100644
--- a/drivers/serial/serial_stm32.c
+++ b/drivers/serial/serial_stm32.c
@@ -47,10 +47,10 @@ static int stm32_serial_getc(struct udevice *dev)
fdt_addr_t base = plat->base;
u32 isr = readl(base + ISR_OFFSET(stm32f4));
 
-   if ((isr & USART_SR_FLAG_RXNE) == 0)
+   if ((isr & USART_ISR_FLAG_RXNE) == 0)
return -EAGAIN;
 
-   if (isr & USART_SR_FLAG_ORE) {
+   if (isr & USART_ISR_FLAG_ORE) {
if (!stm32f4)
setbits_le32(base + ICR_OFFSET, USART_ICR_OREF);
else
@@ -67,7 +67,7 @@ static int stm32_serial_putc(struct udevice *dev, const char 
c)
bool stm32f4 = plat->uart_info->stm32f4;
fdt_addr_t base = plat->base;
 
-   if ((readl(base + ISR_OFFSET(stm32f4)) & USART_SR_FLAG_TXE) == 0)
+   if ((readl(base + ISR_OFFSET(stm32f4)) & USART_ISR_FLAG_TXE) == 0)
return -EAGAIN;
 
writel(c, base + TDR_OFFSET(stm32f4));
@@ -83,10 +83,10 @@ static int stm32_serial_pending(struct udevice *dev, bool 
input)
 
if (input)
return readl(base + ISR_OFFSET(stm32f4)) &
-   USART_SR_FLAG_RXNE ? 1 : 0;
+   USART_ISR_FLAG_RXNE ? 1 : 0;
else
return readl(base + ISR_OFFSET(stm32f4)) &
-   USART_SR_FLAG_TXE ? 0 : 1;
+   USART_ISR_FLAG_TXE ? 0 : 1;
 }
 
 static int stm32_serial_probe(struct udevice *dev)
diff --git a/drivers/serial/serial_stm32.h b/drivers/serial/serial_stm32.h
index 42fb1321e9dc..6ebec0acac45 100644
--- a/drivers/serial/serial_stm32.h
+++ b/drivers/serial/serial_stm32.h
@@ -60,9 +60,9 @@ struct stm32x7_serial_platdata {
 
 #define USART_CR3_OVRDIS   BIT(12)
 
-#define USART_SR_FLAG_ORE  BIT(3)
-#define USART_SR_FLAG_RXNE BIT(5)
-#define USART_SR_FLAG_TXE  BIT(7)
+#define USART_ISR_FLAG_ORE BIT(3)
+#define USART_ISR_FLAG_RXNEBIT(5)
+#define USART_ISR_FLAG_TXE BIT(7)
 
 #define USART_BRR_F_MASK   GENMASK(7, 0)
 #define USART_BRR_M_SHIFT  4
-- 
1.9.1

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


[U-Boot] [PATCH v1 1/2] serial: serial_stm32: Enable overrun

2018-04-20 Thread Patrice Chotard
Enable uart overrun feature which allows to benefits of uart
FIFO usage.

Previously overrun management was disabled, this has to effect
to bypassed the uart FIFO usage even if FIFO was enabled.
In particular configuration, for example when video console is
enabled, copy/pasting a long command line in console results in
corruption. This is due to the fact that a lot of time is consumed
in flushing the cache during frame buffer update, so uart chars are
not read fast enough.

By using uart FIFO and managing overrun, long command line can by
copy/paste in console without being corrupted.

Signed-off-by: Patrice Chotard 
---

 drivers/serial/serial_stm32.c | 15 +++
 drivers/serial/serial_stm32.h |  8 
 2 files changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/serial/serial_stm32.c b/drivers/serial/serial_stm32.c
index 286b954fdd74..8275a76bf10b 100644
--- a/drivers/serial/serial_stm32.c
+++ b/drivers/serial/serial_stm32.c
@@ -45,10 +45,19 @@ static int stm32_serial_getc(struct udevice *dev)
struct stm32x7_serial_platdata *plat = dev_get_platdata(dev);
bool stm32f4 = plat->uart_info->stm32f4;
fdt_addr_t base = plat->base;
+   u32 isr = readl(base + ISR_OFFSET(stm32f4));
 
-   if ((readl(base + ISR_OFFSET(stm32f4)) & USART_SR_FLAG_RXNE) == 0)
+   if ((isr & USART_SR_FLAG_RXNE) == 0)
return -EAGAIN;
 
+   if (isr & USART_SR_FLAG_ORE) {
+   if (!stm32f4)
+   setbits_le32(base + ICR_OFFSET, USART_ICR_OREF);
+   else
+   readl(base + RDR_OFFSET(stm32f4));
+   return -EIO;
+   }
+
return readl(base + RDR_OFFSET(stm32f4));
 }
 
@@ -109,11 +118,9 @@ static int stm32_serial_probe(struct udevice *dev)
return plat->clock_rate;
};
 
-   /* Disable uart-> disable overrun-> enable uart */
+   /* Disable uart-> enable fifo-> enable uart */
clrbits_le32(base + CR1_OFFSET(stm32f4), USART_CR1_RE | USART_CR1_TE |
 BIT(uart_enable_bit));
-   if (plat->uart_info->has_overrun_disable)
-   setbits_le32(base + CR3_OFFSET(stm32f4), USART_CR3_OVRDIS);
if (plat->uart_info->has_fifo)
setbits_le32(base + CR1_OFFSET(stm32f4), USART_CR1_FIFOEN);
setbits_le32(base + CR1_OFFSET(stm32f4), USART_CR1_RE | USART_CR1_TE |
diff --git a/drivers/serial/serial_stm32.h b/drivers/serial/serial_stm32.h
index d08ba1f55fc4..42fb1321e9dc 100644
--- a/drivers/serial/serial_stm32.h
+++ b/drivers/serial/serial_stm32.h
@@ -12,6 +12,8 @@
 #define CR3_OFFSET(x)  (x ? 0x14 : 0x08)
 #define BRR_OFFSET(x)  (x ? 0x08 : 0x0c)
 #define ISR_OFFSET(x)  (x ? 0x00 : 0x1c)
+
+#define ICR_OFFSET 0x20
 /*
  * STM32F4 has one Data Register (DR) for received or transmitted
  * data, so map Receive Data Register (RDR) and Transmit Data
@@ -23,28 +25,24 @@
 struct stm32_uart_info {
u8 uart_enable_bit; /* UART_CR1_UE */
bool stm32f4;   /* true for STM32F4, false otherwise */
-   bool has_overrun_disable;
bool has_fifo;
 };
 
 struct stm32_uart_info stm32f4_info = {
.stm32f4 = true,
.uart_enable_bit = 13,
-   .has_overrun_disable = false,
.has_fifo = false,
 };
 
 struct stm32_uart_info stm32f7_info = {
.uart_enable_bit = 0,
.stm32f4 = false,
-   .has_overrun_disable = true,
.has_fifo = false,
 };
 
 struct stm32_uart_info stm32h7_info = {
.uart_enable_bit = 0,
.stm32f4 = false,
-   .has_overrun_disable = true,
.has_fifo = true,
 };
 
@@ -62,6 +60,7 @@ struct stm32x7_serial_platdata {
 
 #define USART_CR3_OVRDIS   BIT(12)
 
+#define USART_SR_FLAG_ORE  BIT(3)
 #define USART_SR_FLAG_RXNE BIT(5)
 #define USART_SR_FLAG_TXE  BIT(7)
 
@@ -69,4 +68,5 @@ struct stm32x7_serial_platdata {
 #define USART_BRR_M_SHIFT  4
 #define USART_BRR_M_MASK   GENMASK(15, 4)
 
+#define USART_ICR_OREF BIT(3)
 #endif
-- 
1.9.1

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


[U-Boot] [PATCH v1 0/2] stm32_serial fixes

2018-04-20 Thread Patrice Chotard

This series :
_ enable overrun uart feature
_ rename status register flags


Patrice Chotard (2):
  serial: serial_stm32: Enable overrun
  serial: serial_stm32: Rename status register flags

 drivers/serial/serial_stm32.c | 21 ++---
 drivers/serial/serial_stm32.h | 12 ++--
 2 files changed, 20 insertions(+), 13 deletions(-)

-- 
1.9.1

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


Re: [U-Boot] u-boot 2018 SPI SPL

2018-04-20 Thread Mehmet Ali İPİN
Dear Fabio

Thank you very much for your directives and helps. 

I applied the steps in WARP board readme file, for the command 

=> ums 0 mmc 2

I received Unknown command 'ums' - try 'help'

I compared with  WARP7 defconfig and mx6sabresd_defconfig files added some 
definitions in WARP, but got error messages in make file.
Therefore I would appreciate your helps/commends if you write me the 
definitions in config/defconfig files to enable u-boot to run this command?

Best regads.


-Original Message-
From: Fabio Estevam [mailto:feste...@gmail.com] 
Sent: Wednesday, April 18, 2018 4:25 PM
To: Mehmet Ali İPİN 
Cc: u-boot@lists.denx.de; Kutsal ANIL 
Subject: Re: [U-Boot] u-boot 2018 SPI SPL

Hi Mehmet,

On Wed, Apr 18, 2018 at 3:56 AM, Mehmet Ali İPİN  
wrote:
> Dear Fabio,
>
> I manually set spl_boot_list[]  array with SPI, eMMCx, USB RAM etc.
> For SPI NOR flash loader = spl_ll_find_loader(spl_boot_list[i])
> function (in spl.c) is returning a negative loader->boot_device number  
> -442503140
>
> May be there is a definition in u-boot/SPL config files to make file 
> to generate SPI NOR flash boot code, instead of MMC, Which enable this SPL 
> function to return positive correct value for SPI NOR Flash?
>
> eMMC is working, but I did not put SPL and u-boot in eMMC; May be you 
> can give me a link explaining how to SPL+u-boot.img to eMMC flash commands.

You can check board/warp7/README

> I added puts() messages to trace the execution;
>
> These are the messages at terminal.
>
>
> U-Boot SPL 2018.05-rc1 (Apr 17 2018 - 22:43:50 -0700) SPL set_bd() SPL 
> DRAM initialized SPL Malloc; gd flags board boot order spl boot list
> spl_boot_list:8
> spl_boot_list:8
> Trying to boot from -442503140

You need to debug why you are getting this.

Make sure your board is correctly configured to boot from SPI NOR via 
GPIO/fuses.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot


Re: [U-Boot] [PATCH v1 1/3] arm: socfpga: stratix10: Add Stratix10 FPGA Reconfiguration Driver

2018-04-20 Thread Marek Vasut
On 04/20/2018 05:26 AM, chee.hong@intel.com wrote:
> From: Chee Hong Ang 
> 
> Enable FPGA reconfiguration support on Stratix10 SoC.
> 
> Signed-off-by: Chee Hong Ang 
> ---
>  drivers/fpga/Kconfig |  10 ++
>  drivers/fpga/Makefile|   1 +
>  drivers/fpga/stratix10.c | 298 
> +++
>  3 files changed, 309 insertions(+)
>  create mode 100644 drivers/fpga/stratix10.c
> 
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index d36c4c5..255683d 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -31,6 +31,16 @@ config FPGA_CYCLON2
> Enable FPGA driver for loading bitstream in BIT and BIN format
> on Altera Cyclone II device.
>  
> +config FPGA_STRATIX10
> + bool "Enable Altera FPGA driver for Stratix 10"
> + depends on FPGA_ALTERA && TARGET_SOCFPGA_STRATIX10
> + help
> +   Say Y here to enable the Altera Stratix 10 FPGA specific driver
> +
> +   This provides common functionality for Altera Stratix 10 devices.
> +   Enable FPGA driver for writing bitstream into Altera Stratix10
> +   device.
> +
>  config FPGA_XILINX
>   bool "Enable Xilinx FPGA drivers"
>   select FPGA
> diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> index 08c9ff8..3c906ec 100644
> --- a/drivers/fpga/Makefile
> +++ b/drivers/fpga/Makefile
> @@ -19,6 +19,7 @@ obj-$(CONFIG_FPGA_ACEX1K) += ACEX1K.o
>  obj-$(CONFIG_FPGA_CYCLON2) += cyclon2.o
>  obj-$(CONFIG_FPGA_STRATIX_II) += stratixII.o
>  obj-$(CONFIG_FPGA_STRATIX_V) += stratixv.o
> +obj-$(CONFIG_FPGA_STRATIX10) += stratix10.o
>  obj-$(CONFIG_FPGA_SOCFPGA) += socfpga.o
>  obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += socfpga_gen5.o
>  obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += socfpga_arria10.o
> diff --git a/drivers/fpga/stratix10.c b/drivers/fpga/stratix10.c
> new file mode 100644
> index 000..f0c5ace
> --- /dev/null
> +++ b/drivers/fpga/stratix10.c
> @@ -0,0 +1,298 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2016-2018 Intel Corporation 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#define RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS 6
> +#define RECONFIG_STATUS_INTERVAL_DELAY_US100
> +
> +static const struct mbox_cfgstat_state {
> + int err_no;
> + const char  *error_name;
> +} mbox_cfgstat_state[] = {
> + {MBOX_CFGSTAT_STATE_IDLE, "FPGA in idle mode."},
> + {MBOX_CFGSTAT_STATE_CONFIG, "FPGA in config mode."},
> + {MBOX_CFGSTAT_STATE_FAILACK, "Acknowledgement failed!"},
> + {MBOX_CFGSTAT_STATE_ERROR_INVALID, "Invalid bitstream!"},
> + {MBOX_CFGSTAT_STATE_ERROR_CORRUPT, "Corrupted bitstream!"},
> + {MBOX_CFGSTAT_STATE_ERROR_AUTH, "Authentication failed!"},
> + {MBOX_CFGSTAT_STATE_ERROR_CORE_IO, "I/O error!"},
> + {MBOX_CFGSTAT_STATE_ERROR_HARDWARE, "Hardware error!"},
> + {MBOX_CFGSTAT_STATE_ERROR_FAKE, "Fake error!"},
> + {MBOX_CFGSTAT_STATE_ERROR_BOOT_INFO, "Error in boot info!"},
> + {MBOX_CFGSTAT_STATE_ERROR_QSPI_ERROR, "Error in QSPI!"},
> + {-ETIMEDOUT, "I/O timeout error"},
> + {-1, "Unknown error!"}
> +};
> +
> +#define MBOX_CFGSTAT_MAX \
> +   (sizeof(mbox_cfgstat_state) / sizeof(struct mbox_cfgstat_state))
> +
> +static const char *mbox_cfgstat_to_str(int err)
> +{
> + int i;
> +
> + for (i = 0; i < MBOX_CFGSTAT_MAX - 1; i++) {
> + if (mbox_cfgstat_state[i].err_no == err)
> + return mbox_cfgstat_state[i].error_name;
> + }
> +
> + return mbox_cfgstat_state[MBOX_CFGSTAT_MAX - 1].error_name;
> +}
> +
> +static void inc_cmd_id(u8 *id)
> +{
> + u8 val = *id + 1;
> +
> + if (val > 15)
> + val = 1;

What's this function about, elaborate implementation of (i % 15) + 1 ?

> + *id = val;
> +}
> +
> +/*
> + * Polling the FPGA configuration status.
> + * Return 0 for success, non-zero for error.
> + */
> +static int reconfig_status_polling_resp(void)
> +{
> + u32 reconfig_status_resp_len;
> + u32 reconfig_status_resp[RECONFIG_STATUS_RESPONSE_LEN];
> + int ret;
> + unsigned long start = get_timer(0);
> +
> + while (1) {
> + reconfig_status_resp_len = RECONFIG_STATUS_RESPONSE_LEN;
> + ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_RECONFIG_STATUS,
> + MBOX_CMD_DIRECT, 0, NULL, 0,
> + _status_resp_len,
> + reconfig_status_resp);
> +
> + if (ret) {
> + puts("Failure in RECONFIG_STATUS mailbox command!\n");
> + return ret;
> + }
> +
> + /* Check for any error */
> + ret = reconfig_status_resp[RECONFIG_STATUS_STATE];
> + if (ret && ret != MBOX_CFGSTAT_STATE_CONFIG)
> + return ret;
> +
> + /* Make sure nStatus is not 0 */
> +

Re: [U-Boot] [PATCH v1 3/3] arm: socfpga: stratix10: Enable Stratix10 FPGA Reconfiguration

2018-04-20 Thread Marek Vasut
On 04/20/2018 05:26 AM, chee.hong@intel.com wrote:
> From: Chee Hong Ang 
> 
> Enable Stratix10 FPGA reconfiguration support in defconfig.
> 
> Signed-off-by: Chee Hong Ang 
> ---
>  configs/socfpga_stratix10_defconfig | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/configs/socfpga_stratix10_defconfig 
> b/configs/socfpga_stratix10_defconfig
> index 46b7999..2414f4e 100644
> --- a/configs/socfpga_stratix10_defconfig
> +++ b/configs/socfpga_stratix10_defconfig
> @@ -9,6 +9,8 @@ CONFIG_SPL_FAT_SUPPORT=y
>  CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk"
>  CONFIG_BOOTDELAY=5
>  CONFIG_HUSH_PARSER=y
> +CONFIG_FPGA_ALTERA=y
> +CONFIG_FPGA_STRATIX10=y

CONFIG_FPGA_STRATIX10 should select FPGA_ALTERA in Kconfig

>  CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
>  CONFIG_CMD_MEMTEST=y
>  # CONFIG_CMD_FLASH is not set
> 


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


Re: [U-Boot] [PATCH v1 2/3] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table

2018-04-20 Thread Marek Vasut
On 04/20/2018 05:26 AM, chee.hong@intel.com wrote:
> From: Chee Hong Ang 
> 
> Enable 'fpga' command in u-boot. User will be able to use the
> fpga command to program the FPGA on Stratix10 SoC.
> 
> Signed-off-by: Chee Hong Ang 
> ---
>  arch/arm/mach-socfpga/misc.c | 20 +---
>  arch/arm/mach-socfpga/misc_s10.c |  4 
>  drivers/fpga/altera.c|  6 ++
>  include/altera.h |  8 
>  4 files changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
> index d15cbc7..e36c686 100644
> --- a/arch/arm/mach-socfpga/misc.c
> +++ b/arch/arm/mach-socfpga/misc.c
> @@ -87,11 +87,24 @@ int overwrite_console(void)
>  #endif
>  
>  #ifdef CONFIG_FPGA
> -/*
> - * FPGA programming support for SoC FPGA Cyclone V
> - */
>  static Altera_desc altera_fpga[] = {
>   {
> +#ifdef CONFIG_FPGA_STRATIX10

Create a separate structure for each FPGA family.

> + /* FPGA programming support for SoC FPGA Stratix 10 */
> + /* Family */
> + Intel_FPGA_Stratix10,
> + /* Interface type */
> + secure_device_manager_mailbox,
> + /* No limitation as additional data will be ignored */
> + -1,
> + /* No device function table */
> + NULL,
> + /* Base interface address specified in driver */
> + NULL,
> + /* No cookie implementation */
> + 0
> +#else
> + /* FPGA programming support for SoC FPGA Cyclone V */
>   /* Family */
>   Altera_SoCFPGA,
>   /* Interface type */
> @@ -104,6 +117,7 @@ static Altera_desc altera_fpga[] = {
>   NULL,
>   /* No cookie implementation */
>   0
> +#endif
>   },
>  };
>  
> diff --git a/arch/arm/mach-socfpga/misc_s10.c 
> b/arch/arm/mach-socfpga/misc_s10.c
> index b1cc6ca..012d8f6 100644
> --- a/arch/arm/mach-socfpga/misc_s10.c
> +++ b/arch/arm/mach-socfpga/misc_s10.c
> @@ -71,6 +71,10 @@ int arch_misc_init(void)
>  
>  int arch_early_init_r(void)
>  {
> +#ifdef CONFIG_FPGA
> + socfpga_fpga_add();
> +#endif
> +
>   return 0;
>  }
>  
> diff --git a/drivers/fpga/altera.c b/drivers/fpga/altera.c
> index 135a357..b662ff5 100644
> --- a/drivers/fpga/altera.c
> +++ b/drivers/fpga/altera.c
> @@ -40,6 +40,9 @@ static const struct altera_fpga {
>  #if defined(CONFIG_FPGA_STRATIX_V)
>   { Altera_StratixV, "StratixV", stratixv_load, NULL, NULL },
>  #endif
> +#if defined(CONFIG_FPGA_STRATIX10)
> + { Intel_FPGA_Stratix10, "Stratix10", stratix10_load, NULL, NULL },
> +#endif
>  #if defined(CONFIG_FPGA_SOCFPGA)
>   { Altera_SoCFPGA, "SoC FPGA", socfpga_load, NULL, NULL },
>  #endif
> @@ -155,6 +158,9 @@ int altera_info(Altera_desc *desc)
>   case fast_passive_parallel_security:
>   printf("Fast Passive Parallel with Security (FPPS)\n");
>   break;
> + case secure_device_manager_mailbox:
> + puts("Secure Device Manager (SDM) Mailbox\n");
> + break;
>   /* Add new interface types here */
>   default:
>   printf("Unsupported interface type, %d\n", desc->iface);
> diff --git a/include/altera.h b/include/altera.h
> index 48d3eb7..e9ba47a 100644
> --- a/include/altera.h
> +++ b/include/altera.h
> @@ -40,6 +40,8 @@ enum altera_iface {
>   fast_passive_parallel,
>   /* fast passive parallel with security (FPPS) */
>   fast_passive_parallel_security,
> + /* secure device manager (SDM) mailbox */
> + secure_device_manager_mailbox,
>   /* insert all new types before this */
>   max_altera_iface_type,
>  };
> @@ -55,6 +57,8 @@ enum altera_family {
>   Altera_StratixII,
>   /* StratixV Family */
>   Altera_StratixV,
> + /* Stratix10 Family */
> + Intel_FPGA_Stratix10,
>   /* SoCFPGA Family */
>   Altera_SoCFPGA,
>  
> @@ -117,4 +121,8 @@ int socfpga_load(Altera_desc *desc, const void *rbf_data, 
> size_t rbf_size);
>  int stratixv_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size);
>  #endif
>  
> +#ifdef CONFIG_FPGA_STRATIX10
> +int stratix10_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size);

What is this doing here ?

> +#endif
> +
>  #endif /* _ALTERA_H_ */
> 


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