date:20190228

On Thu, Feb 28, 2019 at 10:44 PM Marek Vasut  wrote:
>
> On 2/28/19 9:33 PM, Simon Goldschmidt wrote:
> > If SPL pre-reloc stage puts the stack into DDR, U-Boot should be able to
> > do that, too.
>
> Here you mention SPL pre-reloc stage, while about mid-way through the
> patch you have a comment talking about SPL post-reloc stage, which one
> is it ? I think the commit message needs rewording, it's not clear what
> the patch does based on it.

Ehrm right. The commit message is wrong. Post-reloc is correct.

> On a separate note, this is likely a fix for current release, right ?

Not really. For A10, this should not change anything, just ensure the common
header file does not use 2 different ways to achieve the same thing.
Note that A10 does *not* enable a different stack/malloc area for SPL
post-reloc!

For gen5, yes there is a change, but only in U-Boot, not in SPL. But this is
not a fix, it's an improvement to be able to make the SPL malloc pool smaller
without U-Boot overwriting it. It's currently not overwritten as both
malloc sizes
are the same. I'd change that in a follow-up patch which reduces SPL malloc
size for gen5.

> Finally , keep in mind the A10 needs to load the FPGA before DRAM
> becomes available, so the stack shenanigans there become even more nasty.

Right, that's why even the initial malloc size for SPL is 64 KiB,
right? As written
above, this patch should not change anything for A10, so this should still work.

From reading the A10 SPL code, I didn't quite get how this works though, as
it seems the simple-malloc members in gd are only initialized after
spl_early_init(), so after initializing DT/DM? Or is A10 not yet
converted to DT?

Regards,
Simon

> > The reason to do so is that this way, U-Boot initial stack can be larger
> > than SPL initial stack. In situations where we want to save the SPL
> > in SRAM for next boot without reloading, this prevents overwriting the
> > SPL DTB in SRAM if U-Boot stack usage gets too high.
> >
> > Signed-off-by: Simon Goldschmidt 
> > ---
> >
> >  include/configs/socfpga_common.h | 20 +---
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/include/configs/socfpga_common.h 
> > b/include/configs/socfpga_common.h
> > index c23b34186a..7ae3db233f 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -38,12 +38,23 @@
> >  #if ((CONFIG_SYS_BOOTCOUNT_ADDR > CONFIG_SYS_INIT_RAM_ADDR) &&   \
> >   (CONFIG_SYS_BOOTCOUNT_ADDR < (CONFIG_SYS_INIT_RAM_ADDR +\
> >  CONFIG_SYS_INIT_RAM_SIZE)))
> > -#define CONFIG_SYS_INIT_SP_ADDR  CONFIG_SYS_BOOTCOUNT_ADDR
> > +#define CONFIG_SPL_STACK CONFIG_SYS_BOOTCOUNT_ADDR
> >  #else
> > -#define CONFIG_SYS_INIT_SP_ADDR  \
> > +#define CONFIG_SPL_STACK \
> >   (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)
> >  #endif
> >
> > +/*
> > + * U-Boot stack setup: if SPL post-reloc uses DDR stack, use it in 
> > pre-reloc
> > + * phase of U-Boot, too. This prevents overwriting SPL data if stack/heap 
> > usage
> > + * in U-Boot pre-reloc is higher than in SPL.
> > + */
> > +#if defined(CONFIG_SPL_STACK_R_ADDR) && CONFIG_SPL_STACK_R_ADDR
> > +#define CONFIG_SYS_INIT_SP_ADDR  CONFIG_SPL_STACK_R_ADDR
> > +#else
> > +#define CONFIG_SYS_INIT_SP_ADDR  CONFIG_SPL_STACK
> > +#endif
> > +
> >  #define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1
> >
> >  /*
> > @@ -274,11 +285,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> >  #define CONFIG_SYS_NAND_U_BOOT_OFFS  0x4
> >  #endif
> >
> > -/*
> > - * Stack setup
> > - */
> > -#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
> > -
> >  /* Extra Environment */
> >  #ifndef CONFIG_SPL_BUILD
> >
> >
>
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] arm: socfpga: a10: move SPL stack size to Kconfig

On Thu, Feb 28, 2019 at 10:44 PM Marek Vasut  wrote:
>
> On 2/28/19 9:33 PM, Simon Goldschmidt wrote:
> > Instead of fixing the SPL stack to 64 KiB in the board config header via
> > CONFIG_SYS_SPL_MALLOC_SIZE, let's just use CONFIG_SPL_SYS_MALLOC_F_LEN
> > in the defconfig.
> >
> > This also has the advandage that it removes sub-mach specific ifdefs in
> > socfpga_common.h.
> >
> > Signed-off-by: Simon Goldschmidt 
>
> Can't we default these stack sizes with imply in Kconfig files instead ?
> Then they won't have to be in the defconfigs either.

I guess you mean default the *malloc* sizes, not *stack* sizes? Yes, that
should work.

I started this whole series because all gen5 defconfigs set the initial malloc
size to 8 KiB, while I monitored socrates to only need a bit more than 1 KiB.
With my reset patches, something around 1.5 KiB is still enough. So I'd
move that to imply 2 KiB for gen5 and 64 KiB for a10 in a patch 4/4 for v2.

Regards,
Simon

>
> > ---
> >
> >  configs/socfpga_arria10_defconfig |  1 +
> >  include/configs/socfpga_common.h  | 14 --
> >  2 files changed, 1 insertion(+), 14 deletions(-)
> >
> > diff --git a/configs/socfpga_arria10_defconfig 
> > b/configs/socfpga_arria10_defconfig
> > index f321a0ac3b..8d0479cc05 100644
> > --- a/configs/socfpga_arria10_defconfig
> > +++ b/configs/socfpga_arria10_defconfig
> > @@ -2,6 +2,7 @@ CONFIG_ARM=y
> >  CONFIG_ARCH_SOCFPGA=y
> >  CONFIG_SYS_TEXT_BASE=0x0140
> >  CONFIG_SYS_MALLOC_F_LEN=0x2000
> > +CONFIG_SPL_SYS_MALLOC_F_LEN=0x1
> >  CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y
> >  CONFIG_SPL=y
> >  CONFIG_IDENT_STRING="socfpga_arria10"
> > diff --git a/include/configs/socfpga_common.h 
> > b/include/configs/socfpga_common.h
> > index a3fbca0a5d..c23b34186a 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -251,16 +251,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> >  #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR
> >  #define CONFIG_SPL_MAX_SIZE  CONFIG_SYS_INIT_RAM_SIZE
> >
> > -#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > -/* SPL memory allocation configuration, this is for FAT implementation */
> > -#ifndef CONFIG_SYS_SPL_MALLOC_START
> > -#define CONFIG_SYS_SPL_MALLOC_SIZE   0x0001
> > -#define CONFIG_SYS_SPL_MALLOC_START  (CONFIG_SYS_INIT_RAM_SIZE - \
> > -  CONFIG_SYS_SPL_MALLOC_SIZE + \
> > -  CONFIG_SYS_INIT_RAM_ADDR)
> > -#endif
> > -#endif
> > -
> >  /* SPL SDMMC boot support */
> >  #ifdef CONFIG_SPL_MMC_SUPPORT
> >  #if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
> > @@ -287,11 +277,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
> >  /*
> >   * Stack setup
> >   */
> > -#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
> >  #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
> > -#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> > -#define CONFIG_SPL_STACK CONFIG_SYS_SPL_MALLOC_START
> > -#endif
> >
> >  /* Extra Environment */
> >  #ifndef CONFIG_SPL_BUILD
> >
>
>
> --
> Best regards,
> Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] db-88f6820-amc doesn't boot on latest u-boot/master

On Fri, Mar 1, 2019 at 5:12 PM Vignesh Raghavendra  wrote:
>
>
>
> On 01/03/19 7:00 AM, Chris Packham wrote:
> > On Fri, Mar 1, 2019 at 11:15 AM Chris Packham  
> > wrote:
> >>
> >> Hi All,
> >>
> >> I was just testing out the db-88f6820-amc on u-boot#master and found
> >> that the SPL can't fetch then next stage from SPI.
> >>
> >> U-Boot SPL 2019.04-rc2-00139-g91c56ed98da7 (Mar 01 2019 - 10:26:26 +1300)
> >> High speed PHY - Version: 2.0
> >> Detected Device ID 6820
> >> board SerDes lanes topology details:
> >> | Lane # | Speed | Type |
> >> 
> >> | 0 | 5 | PCIe0 |
> >> | 4 | 0 | SGMII1 |
> >> | 5 | 0 | SGMII2 |
> >> 
> >> PCIe, Idx 0: detected no link
> >> High speed PHY - Ended Successfully
> >> mv_ddr: mv_ddr-armada-18.09.2
> >> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> >> mv_ddr: completed successfully
> >> Trying to boot from SPI SPI probe failed.
> >> SPL: failed to boot from all boot devices
> >> ### ERROR ### Please RESET the board ###
> >>
> >> I haven't had time to bisect this yet but I wondered if this was
> >> related to the recent spi changes (this board uses SPI1 so maybe
> >> that's the corner case). I may also potentially be fixed by the SPI
> >> Kconfig series that is floating around on the list.
> >
> > The plot thickens...
> >
> > The failure to boot is because the db-88f6820-amc does not set
> > CONFIG_SYS_MALLOC_F_LEN and the default is too small to support all
> > the probing required to fetch the next stage from SPI. I don't know
> > why I never set this. The other mvebu boards all have it set. Patch
> > for that on the way.
> >
> > Now I run into a situation where I can't update u-boot. The spi
> > commands all say success but erasing won't actually delete the data
> > and updating fails (presumably because the erase fails). Similarly
> > when I change something and use saveenv it doesn't stick for the next
> > boot.
> >
>
> Hmm, interesting. What's the flash part on this board? Is flash
> identified correctly by sf probe?

Seems to be correct.

=> sf probe
SF: Detected n25q256a with page size 256 Bytes, erase size 4 KiB, total 32 MiB

>
> Could you enable debug prints in drivers/spi/spi-mem.c (especially ones
> at the of spi_mem_exec_op()) and post the log?
>

They're a bit too verbose to post here but nothing out of the
ordinary, bytes in/out all ret 0.

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

Re: [U-Boot] [PATCH] Convert CONFIG_IP_DEFRAG to Kconfig

2019-02-28 Thread Christian Gmeiner

Am Di., 12. Feb. 2019 um 13:29 Uhr schrieb Christian Gmeiner
:
>
> This converts the following to Kconfig:
>CONFIG_IP_DEFRAG
>
> Signed-off-by: Christian Gmeiner 
> ---
>  net/Kconfig  | 6 ++
>  scripts/config_whitelist.txt | 1 -
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/net/Kconfig b/net/Kconfig
> index f2363e5256..5f5f632469 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -8,6 +8,12 @@ menuconfig NET
>
>  if NET
>
> +config IP_DEFRAG
> +   bool "Support IP datagram reassembly"
> +   help
> + Selecting this will enable IP datagram reassembly according
> + to the algorithm in RFC815.
> +
>  config NET_RANDOM_ETHADDR
> bool "Random ethaddr if unset"
> help
> diff --git a/scripts/config_whitelist.txt b/scripts/config_whitelist.txt
> index 2b3572568b..6b746c5242 100644
> --- a/scripts/config_whitelist.txt
> +++ b/scripts/config_whitelist.txt
> @@ -972,7 +972,6 @@ CONFIG_IPAM390_GPIO_BOOTMODE
>  CONFIG_IPAM390_GPIO_LED_GREEN
>  CONFIG_IPAM390_GPIO_LED_RED
>  CONFIG_IPROC
> -CONFIG_IP_DEFRAG
>  CONFIG_IRAM_BASE
>  CONFIG_IRAM_END
>  CONFIG_IRAM_SIZE
> --
> 2.20.1
>

ping

-- 
greets
--
Christian Gmeiner, MSc

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

Re: [U-Boot] [PATCH 2/3] mmc: split fsl_esdhc driver for i.MX

2019-02-28 Thread Lukasz Majewski

Hi Yangbo,

I've added Fabio and Stefano (IMX maintainers) to CC, so the would be
aware about the ongoing work.

> The fsl_esdhc driver was for Freescale eSDHC on MPC83XX/MPC85XX
> initially. The later QoriQ series PowerPC processors (which were
> evolutions of MPC83XX/MPC85XX), QorIQ series ARM processors, and
> i.MX series processors were using this driver for their eSDHCs too.
> 
> For the two series processors, the eSDHCs are becoming more and
> more different. We should have split it into two drivers, like them
> (sdhci-of-esdhc.c/sdhci-esdhc-imx.c) in linux kernel.
> 
> This patch is just to create a fsl_esdhc_imx driver which is a copy
> of fsl_esdhc driver for i.MX processors. We will convert i.MX
> processors to use fsl_esdhc_imx, and clean up the two drivers
> separately in the future patches.

The direction is good. Such intrusive patch shall be accepted only
during merge window.

Stefano, Fabio what do you think about this patch set?

> 
> Signed-off-by: Yangbo Lu 
> ---
>  drivers/mmc/Kconfig  |  6 ++
>  drivers/mmc/Makefile |  1 +
>  drivers/mmc/{fsl_esdhc.c => fsl_esdhc_imx.c} |  5 +++--
>  include/{fsl_esdhc.h => fsl_esdhc_imx.h} | 11 ++-
>  4 files changed, 16 insertions(+), 7 deletions(-)
>  copy drivers/mmc/{fsl_esdhc.c => fsl_esdhc_imx.c} (99%)
>  copy include/{fsl_esdhc.h => fsl_esdhc_imx.h} (97%)
> 
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 04a4e7716f..09bc02fe9c 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -641,6 +641,12 @@ config FSL_ESDHC
> This selects support for the eSDHC (enhanced secure
> digital host controller) found on numerous Freescale/NXP SoCs.
>  
> +config FSL_ESDHC_IMX
> + bool "Freescale/NXP i.MX eSDHC controller support"
> + help
> +   This selects support for the i.MX eSDHC (enhanced secure
> digital host
> +   controller) found on numerous Freescale/NXP SoCs.
> +
>  endmenu
>  
>  config SYS_FSL_ERRATUM_ESDHC111
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 7892c468f0..1287ad4cc1 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_MMC_DW_K3) +=
> hi6220_dw_mmc.o obj-$(CONFIG_MMC_DW_ROCKCHIP) +=
> rockchip_dw_mmc.o obj-$(CONFIG_MMC_DW_SOCFPGA)+=
> socfpga_dw_mmc.o obj-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
> +obj-$(CONFIG_FSL_ESDHC_IMX) += fsl_esdhc_imx.o
>  obj-$(CONFIG_FTSDC010) += ftsdc010_mci.o
>  obj-$(CONFIG_GENERIC_ATMEL_MCI) += gen_atmel_mci.o
>  obj-$(CONFIG_MMC_MESON_GX) += meson_gx_mmc.o
> diff --git a/drivers/mmc/fsl_esdhc.c b/drivers/mmc/fsl_esdhc_imx.c
> similarity index 99%
> copy from drivers/mmc/fsl_esdhc.c
> copy to drivers/mmc/fsl_esdhc_imx.c
> index 21fa2ab1d4..9c823e86e2 100644
> --- a/drivers/mmc/fsl_esdhc.c
> +++ b/drivers/mmc/fsl_esdhc_imx.c
> @@ -2,6 +2,7 @@
>  /*
>   * Copyright 2007, 2010-2011 Freescale Semiconductor, Inc
>   * Andy Fleming
> + * Copyright 2019 NXP
>   *
>   * Based vaguely on the pxa mmc code:
>   * (C) Copyright 2003
> @@ -18,7 +19,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -110,7 +111,7 @@ struct esdhc_soc_data {
>   * @non_removable: 0: removable; 1: non-removable
>   * @wp_enable: 1: enable checking wp; 0: no check
>   * @vs18_enable: 1: use 1.8V voltage; 0: use 3.3V
> - * @flags: ESDHC_FLAG_xx in include/fsl_esdhc.h
> + * @flags: ESDHC_FLAG_xx in include/fsl_esdhc_imx.h
>   * @caps: controller capabilities
>   * @tuning_step: tuning step setting in tuning_ctrl register
>   * @start_tuning_tap: the start point for tuning in tuning_ctrl
> register diff --git a/include/fsl_esdhc.h b/include/fsl_esdhc_imx.h
> similarity index 97%
> copy from include/fsl_esdhc.h
> copy to include/fsl_esdhc_imx.h
> index 8dbd5249a7..e05b24e7e8 100644
> --- a/include/fsl_esdhc.h
> +++ b/include/fsl_esdhc_imx.h
> @@ -4,10 +4,11 @@
>   *---
>   *
>   * Copyright 2007-2008,2010-2011 Freescale Semiconductor, Inc
> + * Copyright 2019 NXP
>   */
>  
> -#ifndef  __FSL_ESDHC_H__
> -#define  __FSL_ESDHC_H__
> +#ifndef __FSL_ESDHC_IMX_H__
> +#define __FSL_ESDHC_IMX_H__
>  
>  #include 
>  #include 
> @@ -258,15 +259,15 @@ struct fsl_esdhc_cfg {
>  #error "Endianess is not defined: please fix to continue"
>  #endif
>  
> -#ifdef CONFIG_FSL_ESDHC
> +#ifdef CONFIG_FSL_ESDHC_IMX
>  int fsl_esdhc_mmc_init(bd_t *bis);
>  int fsl_esdhc_initialize(bd_t *bis, struct fsl_esdhc_cfg *cfg);
>  void fdt_fixup_esdhc(void *blob, bd_t *bd);
>  #else
>  static inline int fsl_esdhc_mmc_init(bd_t *bis) { return -ENOSYS; }
>  static inline void fdt_fixup_esdhc(void *blob, bd_t *bd) {}
> -#endif /* CONFIG_FSL_ESDHC */
> +#endif /* CONFIG_FSL_ESDHC_IMX */
>  void __noreturn mmc_boot(void);
>  void mmc_spl_load_image(uint32_t offs, unsigned int size, void
> *vdst); 
> -#endif  /* __FSL_ESDHC_H__ */

Re: [U-Boot] [PATCH] Fix spelling of download.

2019-02-28 Thread Lukasz Majewski

On Thu, 28 Feb 2019 19:56:25 -0800
Vagrant Cascadian  wrote:

> Signed-off-by: Vagrant Cascadian 
> ---
> 
>  cmd/thordown.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/cmd/thordown.c b/cmd/thordown.c
> index ce3660d174..19ae6721d1 100644
> --- a/cmd/thordown.c
> +++ b/cmd/thordown.c
> @@ -65,7 +65,7 @@ done:
>  U_BOOT_CMD(thordown, CONFIG_SYS_MAXARGS, 1, do_thor_down,
>  "TIZEN \"THOR\" downloader",
>  "  \n"
> -"  - device software upgrade via LTHOR TIZEN dowload\n"
> +"  - device software upgrade via LTHOR TIZEN download\n"
>  "program via  on device ,\n"
>  "attached to interface \n"
>  );

Reviewed-by: Lukasz Majewski 


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgpUl3XQTittU.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] Fix spelling of download.

2019-02-28 Thread Bin Meng

Hi,

On Fri, Mar 1, 2019 at 11:56 AM Vagrant Cascadian  wrote:
>

Can you please add some tags in the commit title: like "cmd: thordown: "

> Signed-off-by: Vagrant Cascadian 
> ---
>
>  cmd/thordown.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

Other than that,
Reviewed-by: Bin Meng 

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

Re: [U-Boot] db-88f6820-amc doesn't boot on latest u-boot/master

2019-02-28 Thread Vignesh Raghavendra



On 01/03/19 7:00 AM, Chris Packham wrote:
> On Fri, Mar 1, 2019 at 11:15 AM Chris Packham  wrote:
>>
>> Hi All,
>>
>> I was just testing out the db-88f6820-amc on u-boot#master and found
>> that the SPL can't fetch then next stage from SPI.
>>
>> U-Boot SPL 2019.04-rc2-00139-g91c56ed98da7 (Mar 01 2019 - 10:26:26 +1300)
>> High speed PHY - Version: 2.0
>> Detected Device ID 6820
>> board SerDes lanes topology details:
>> | Lane # | Speed | Type |
>> 
>> | 0 | 5 | PCIe0 |
>> | 4 | 0 | SGMII1 |
>> | 5 | 0 | SGMII2 |
>> 
>> PCIe, Idx 0: detected no link
>> High speed PHY - Ended Successfully
>> mv_ddr: mv_ddr-armada-18.09.2
>> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
>> mv_ddr: completed successfully
>> Trying to boot from SPI SPI probe failed.
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
>>
>> I haven't had time to bisect this yet but I wondered if this was
>> related to the recent spi changes (this board uses SPI1 so maybe
>> that's the corner case). I may also potentially be fixed by the SPI
>> Kconfig series that is floating around on the list.
> 
> The plot thickens...
> 
> The failure to boot is because the db-88f6820-amc does not set
> CONFIG_SYS_MALLOC_F_LEN and the default is too small to support all
> the probing required to fetch the next stage from SPI. I don't know
> why I never set this. The other mvebu boards all have it set. Patch
> for that on the way.
> 
> Now I run into a situation where I can't update u-boot. The spi
> commands all say success but erasing won't actually delete the data
> and updating fails (presumably because the erase fails). Similarly
> when I change something and use saveenv it doesn't stick for the next
> boot.
> 

Hmm, interesting. What's the flash part on this board? Is flash
identified correctly by sf probe?

Could you enable debug prints in drivers/spi/spi-mem.c (especially ones
at the of spi_mem_exec_op()) and post the log?



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

[U-Boot] [PATCH] Fix spelling of download.

2019-02-28 Thread Vagrant Cascadian

Signed-off-by: Vagrant Cascadian 
---

 cmd/thordown.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/thordown.c b/cmd/thordown.c
index ce3660d174..19ae6721d1 100644
--- a/cmd/thordown.c
+++ b/cmd/thordown.c
@@ -65,7 +65,7 @@ done:
 U_BOOT_CMD(thordown, CONFIG_SYS_MAXARGS, 1, do_thor_down,
   "TIZEN \"THOR\" downloader",
   "  \n"
-  "  - device software upgrade via LTHOR TIZEN dowload\n"
+  "  - device software upgrade via LTHOR TIZEN download\n"
   "program via  on device ,\n"
   "attached to interface \n"
 );
-- 
2.11.0

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

Re: [U-Boot] [PATCH 1/3] Move CONFIG_FSL_ESDHC to defconfig

2019-02-28 Thread Y.b. Lu

Any comments on the patch-set?
Thanks a lot.

> -Original Message-
> From: Y.b. Lu 
> Sent: Thursday, February 21, 2019 3:55 PM
> To: u-boot@lists.denx.de
> Cc: Jaehoon Chung ; Prabhakar Kushwaha
> ; Peng Fan ; Lukasz
> Majewski ; Y.b. Lu 
> Subject: [PATCH 1/3] Move CONFIG_FSL_ESDHC to defconfig
> 
> Moved CONFIG_FSL_ESDHC from header files to defconfig files.
> 
> Signed-off-by: Yangbo Lu 
> ---
>  configs/imx8mq_evk_defconfig   | 1 +
>  configs/imx8qxp_mek_defconfig  | 1 +
>  configs/kp_imx53_defconfig | 1 +
>  configs/kp_imx6q_tpc_defconfig | 1 +
>  configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig | 1 +
>  configs/ls1012afrwy_qspi_defconfig | 1 +
>  configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig  | 1 +
>  configs/ls1012afrwy_tfa_defconfig  | 1 +
>  include/configs/imx8mq_evk.h   | 1 -
>  include/configs/imx8qxp_mek.h  | 1 -
>  include/configs/kp_imx53.h | 1 -
>  include/configs/kp_imx6q_tpc.h | 1 -
>  include/configs/ls1012afrwy.h  | 1 -
>  13 files changed, 8 insertions(+), 5 deletions(-)
> 
> diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig
> index 53025e45bc..8f6d66b741 100644
> --- a/configs/imx8mq_evk_defconfig
> +++ b/configs/imx8mq_evk_defconfig
> @@ -27,6 +27,7 @@ CONFIG_DM_GPIO=y
>  CONFIG_DM_I2C=y
>  CONFIG_SYS_I2C_MXC=y
>  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_ETH=y
>  CONFIG_PINCTRL=y
>  CONFIG_DM_REGULATOR=y
> diff --git a/configs/imx8qxp_mek_defconfig b/configs/imx8qxp_mek_defconfig
> index a94998b8b5..88da3ac784 100644
> --- a/configs/imx8qxp_mek_defconfig
> +++ b/configs/imx8qxp_mek_defconfig
> @@ -51,6 +51,7 @@ CONFIG_I2C_MUX=y
>  CONFIG_I2C_MUX_PCA954x=y
>  CONFIG_MISC=y
>  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_PHYLIB=y
>  CONFIG_PHY_ADDR_ENABLE=y
>  CONFIG_PHY_ATHEROS=y
> diff --git a/configs/kp_imx53_defconfig b/configs/kp_imx53_defconfig index
> cfe96fcce5..d00c8cde62 100644
> --- a/configs/kp_imx53_defconfig
> +++ b/configs/kp_imx53_defconfig
> @@ -29,6 +29,7 @@ CONFIG_CMD_FS_GENERIC=y
> CONFIG_OF_CONTROL=y  CONFIG_DEFAULT_DEVICE_TREE="imx53-kp"
>  CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_I2C_SET_DEFAULT_BUS_NUM=y
>  CONFIG_I2C_DEFAULT_BUS_NUMBER=0x1
>  CONFIG_PHYLIB=y
> diff --git a/configs/kp_imx6q_tpc_defconfig b/configs/kp_imx6q_tpc_defconfig
> index cb58ed6678..3f48463c0c 100644
> --- a/configs/kp_imx6q_tpc_defconfig
> +++ b/configs/kp_imx6q_tpc_defconfig
> @@ -33,6 +33,7 @@ CONFIG_CMD_EXT4_WRITE=y  #
> CONFIG_ISO_PARTITION is not set  # CONFIG_EFI_PARTITION is not set
> CONFIG_ENV_IS_IN_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_PHYLIB=y
>  CONFIG_PHY_ATHEROS=y
>  CONFIG_FEC_MXC=y
> diff --git a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
> b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
> index c273dc937e..35a606ce23 100644
> --- a/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
> +++ b/configs/ls1012afrwy_qspi_SECURE_BOOT_defconfig
> @@ -30,6 +30,7 @@ CONFIG_NET_RANDOM_ETHADDR=y  CONFIG_DM=y
> # CONFIG_BLK is not set  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_WINBOND=y
> diff --git a/configs/ls1012afrwy_qspi_defconfig
> b/configs/ls1012afrwy_qspi_defconfig
> index 85523ba2d3..50068a12d7 100644
> --- a/configs/ls1012afrwy_qspi_defconfig
> +++ b/configs/ls1012afrwy_qspi_defconfig
> @@ -31,6 +31,7 @@ CONFIG_NET_RANDOM_ETHADDR=y  CONFIG_DM=y
> # CONFIG_BLK is not set  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_WINBOND=y
> diff --git a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
> b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
> index d9020c5281..1b281c90a2 100644
> --- a/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
> +++ b/configs/ls1012afrwy_tfa_SECURE_BOOT_defconfig
> @@ -30,6 +30,7 @@ CONFIG_NET_RANDOM_ETHADDR=y  CONFIG_DM=y
> # CONFIG_BLK is not set  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_WINBOND=y
> diff --git a/configs/ls1012afrwy_tfa_defconfig
> b/configs/ls1012afrwy_tfa_defconfig
> index 08b3692f97..060cf47156 100644
> --- a/configs/ls1012afrwy_tfa_defconfig
> +++ b/configs/ls1012afrwy_tfa_defconfig
> @@ -31,6 +31,7 @@ CONFIG_NET_RANDOM_ETHADDR=y  CONFIG_DM=y
> # CONFIG_BLK is not set  CONFIG_DM_MMC=y
> +CONFIG_FSL_ESDHC=y
>  CONFIG_DM_SPI_FLASH=y
>  CONFIG_SPI_FLASH=y
>  CONFIG_SPI_FLASH_WINBOND=y
> diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h
> index f0430224cb..492e89a20c 100644
> --- a/include/configs/imx8mq_evk.h
> +++ b/include/configs/imx8mq_evk.h
> @@ -220,7 +220,6 @@
>  #define CONFIG_IMX_BOOTAUX
> 
>  #define CONFIG_CMD_MMC
> -#define CONFIG_FSL_ESDHC
>  #define CONFIG_FSL_USDHC
> 
>  #define CONFIG_SYS_FSL_USDHC_NUM 2
> diff --git a/include/configs/imx8qxp_mek.h b/include/configs/imx8qxp_mek.h
>

Re: [U-Boot] [PATCH v2] x86: acpi: Not every platform has serial console a first device

2019-02-28 Thread Bin Meng

On Thu, Feb 28, 2019 at 11:19 PM Andy Shevchenko
 wrote:
>
> We may not do an assumption that current console device is always a first
> of UCLASS_SERIAL one.
>
> For example, on properly described Intel Edison board the console UART
> is a third one.
>
> Use current serial device as described in global data.
>
> Fixes: a61cbad78e67 ("dm: serial: Adjust serial_getinfo() to use proper API")
> Cc: Simon Glass 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/lib/acpi_table.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>

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

Re: [U-Boot] i.MX8MQ: u-boot-spl-ddr.bin not found



> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年3月1日 9:26
> To: Peng Fan 
> Cc: Stefano Babic ; Baruch Siach ;
> Chris Spencer ; U-Boot-Denx 
> Subject: Re: i.MX8MQ: u-boot-spl-ddr.bin not found
> 
> Hi Peng,
> 
> On Thu, Feb 28, 2019 at 10:17 PM Peng Fan  wrote:
> >
> > Did you execute `make flash.bin`?
> 
> Yes, I did, but flash.bin is not generated for me in mainline U-Boot tree, 
> only in
> u-boot-imx tree.

That's weird, I did not meet issues. My command as following:

. /opt/fsl-imx-internal-xwayland/4.14-sumo/environment-setup-aarch64-poky-linux
make CC="$CC" imx8mq_evk_defconfig
make CC="$CC"  flash.bin

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

Re: [U-Boot] db-88f6820-amc doesn't boot on latest u-boot/master

On Fri, Mar 1, 2019 at 11:15 AM Chris Packham  wrote:
>
> Hi All,
>
> I was just testing out the db-88f6820-amc on u-boot#master and found
> that the SPL can't fetch then next stage from SPI.
>
> U-Boot SPL 2019.04-rc2-00139-g91c56ed98da7 (Mar 01 2019 - 10:26:26 +1300)
> High speed PHY - Version: 2.0
> Detected Device ID 6820
> board SerDes lanes topology details:
> | Lane # | Speed | Type |
> 
> | 0 | 5 | PCIe0 |
> | 4 | 0 | SGMII1 |
> | 5 | 0 | SGMII2 |
> 
> PCIe, Idx 0: detected no link
> High speed PHY - Ended Successfully
> mv_ddr: mv_ddr-armada-18.09.2
> DDR3 Training Sequence - Switching XBAR Window to FastPath Window
> mv_ddr: completed successfully
> Trying to boot from SPI SPI probe failed.
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
> I haven't had time to bisect this yet but I wondered if this was
> related to the recent spi changes (this board uses SPI1 so maybe
> that's the corner case). I may also potentially be fixed by the SPI
> Kconfig series that is floating around on the list.

The plot thickens...

The failure to boot is because the db-88f6820-amc does not set
CONFIG_SYS_MALLOC_F_LEN and the default is too small to support all
the probing required to fetch the next stage from SPI. I don't know
why I never set this. The other mvebu boards all have it set. Patch
for that on the way.

Now I run into a situation where I can't update u-boot. The spi
commands all say success but erasing won't actually delete the data
and updating fails (presumably because the erase fails). Similarly
when I change something and use saveenv it doesn't stick for the next
boot.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] ARM: mvebu: set CONFIG_SYS_MALLOC_F_LEN to 0x2000

Set CONFIG_SYS_MALLOC_F_LEN to match the rest of the mvebu boards. The
default of 0x400 is not enough when booting from SPI.

Signed-off-by: Chris Packham 
---

 configs/db-88f6820-amc_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/db-88f6820-amc_defconfig b/configs/db-88f6820-amc_defconfig
index 3e1b404408a2..f5d35229d11c 100644
--- a/configs/db-88f6820-amc_defconfig
+++ b/configs/db-88f6820-amc_defconfig
@@ -3,6 +3,7 @@ CONFIG_ARCH_MVEBU=y
 CONFIG_SYS_TEXT_BASE=0x0080
 CONFIG_SPL_LIBCOMMON_SUPPORT=y
 CONFIG_SPL_LIBGENERIC_SUPPORT=y
+CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_TARGET_DB_88F6820_AMC=y
 CONFIG_SPL_SERIAL_SUPPORT=y
 CONFIG_SPL=y
-- 
2.21.0

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

Re: [U-Boot] i.MX8MQ: u-boot-spl-ddr.bin not found

Hi Peng,

On Thu, Feb 28, 2019 at 10:17 PM Peng Fan  wrote:
>
> Did you execute `make flash.bin`?

Yes, I did, but flash.bin is not generated for me in mainline U-Boot
tree, only in u-boot-imx tree.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

On Thu, Feb 28, 2019 at 09:59:14PM +0100, Heinrich Schuchardt wrote:
> On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > "run -e" allows for executing EFI application with a specific "Boot"
> > variable. If no "Boot" is specified or "BootOrder" is specified,
> > it tries to run an EFI application specified in the order of "bootOrder."
> > 
> > Signed-off-by: AKASHI Takahiro 
> > ---
> >  cmd/bootefi.c | 31 +++
> >  cmd/nvedit.c  |  9 -
> >  common/cli.c  | 10 ++
> >  include/command.h |  3 +++
> >  4 files changed, 52 insertions(+), 1 deletion(-)
> > 
> > diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> > index 241fd0f987ab..ebe149dffa1f 100644
> > --- a/cmd/bootefi.c
> > +++ b/cmd/bootefi.c
> > @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
> > return CMD_RET_SUCCESS;
> >  }
> >  
> > +/* Called by "run" command */
> > +int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> > +{
> > +   int boot_id = -1;
> > +   char *endp;
> > +
> > +   if (argc > 2)
> > +   return CMD_RET_USAGE;
> > +
> > +   if (argc == 2) {
> > +   if (!strcmp(argv[1], "BootOrder")) {
> > +   boot_id = -1;
> > +   } else if (!strncmp(argv[2], "Boot", 4)) {
> > +   boot_id = (int)simple_strtoul([2][4], , 0);
> > +   if ((argv[2] + strlen(argv[2]) != endp) ||
> > +   boot_id > 0x)
> > +   return CMD_RET_USAGE;
> > +   } else {
> > +   return CMD_RET_USAGE;
> > +   }
> > +   }
> > +
> > +   if (efi_init_obj_list())
> > +   return CMD_RET_FAILURE;
> > +
> > +   if (efi_handle_fdt(NULL))
> > +   return CMD_RET_FAILURE;
> > +
> > +   return do_bootefi_bootmgr_exec(boot_id);
> 
> This function does not invoke:
> 
>     allow_unaligned();
>     switch_to_non_secure_mode();

I've already fixed it in my pre-v3 patch.

> Probably these calls should be moved to efi_init_obj_list() anyway.

Can be, but the name no longer represents its function.

-Takahiro Akashi
>
> Best regards
> 
> Heinrich
> 
> > +}
> > +
> >  /* Interpreter command to boot an arbitrary EFI image from memory */
> >  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[])
> >  {
> > diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> > index de16c72c23f2..ce746bbf1b3e 100644
> > --- a/cmd/nvedit.c
> > +++ b/cmd/nvedit.c
> > @@ -1344,7 +1344,14 @@ U_BOOT_CMD_COMPLETE(
> > run,CONFIG_SYS_MAXARGS, 1,  do_run,
> > "run commands in an environment variable",
> > "var [...]\n"
> > -   "- run the commands in the environment variable(s) 'var'",
> > +   "- run the commands in the environment variable(s) 'var'"
> > +#if defined(CONFIG_CMD_BOOTEFI)
> > +   "\n"
> > +   "run -e [Boot]\n"
> > +   "- load and run UEFI app based on 'Boot' UEFI variable",
> > +#else
> > +   ,
> > +#endif
> > var_complete
> >  );
> >  #endif
> > diff --git a/common/cli.c b/common/cli.c
> > index 51b8d5f85cbb..fbb09d5049a4 100644
> > --- a/common/cli.c
> > +++ b/common/cli.c
> > @@ -12,6 +12,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  
> > @@ -125,6 +126,15 @@ int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char 
> > * const argv[])
> > if (argc < 2)
> > return CMD_RET_USAGE;
> >  
> > +#ifdef CONFIG_CMD_BOOTEFI
> > +   if (!strcmp(argv[1], "-e")) {
> > +   argc--;
> > +   argv++;
> > +
> > +   return do_bootefi_run(cmdtp, flag, argc, argv);
> > +   }
> > +#endif
> > +
> > for (i = 1; i < argc; ++i) {
> > char *arg;
> >  
> > diff --git a/include/command.h b/include/command.h
> > index 200c7a5e9f4e..feddef300ccc 100644
> > --- a/include/command.h
> > +++ b/include/command.h
> > @@ -48,6 +48,9 @@ typedef struct cmd_tbl_s  cmd_tbl_t;
> >  #if defined(CONFIG_CMD_RUN)
> >  extern int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> > argv[]);
> >  #endif
> > +#if defined(CONFIG_CMD_BOOTEFI)
> > +extern int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> > const argv[]);
> > +#endif
> >  
> >  /* common/command.c */
> >  int _do_help (cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t * cmdtp, int
> > 
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

On Thu, Feb 28, 2019 at 06:13:39AM +0100, Heinrich Schuchardt wrote:
> On 2/28/19 6:06 AM, AKASHI Takahiro wrote:
> > On Thu, Feb 28, 2019 at 05:53:17AM +0100, Heinrich Schuchardt wrote:
> >> On 2/28/19 5:45 AM, AKASHI Takahiro wrote:
> >>> On Wed, Feb 27, 2019 at 08:10:36AM +0100, Heinrich Schuchardt wrote:
>  On 2/27/19 7:37 AM, AKASHI Takahiro wrote:
> > On Wed, Feb 27, 2019 at 07:25:52AM +0100, Heinrich Schuchardt wrote:
> >> On 2/27/19 7:12 AM, AKASHI Takahiro wrote:
> >>> On Tue, Feb 26, 2019 at 08:20:10PM +0100, Heinrich Schuchardt wrote:
>  On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> > "run -e" allows for executing EFI application with a specific 
> > "Boot"
> > variable. If no "Boot" is specified or "BootOrder" is specified,
> > it tries to run an EFI application specified in the order of 
> > "bootOrder."
> >
> 
>  If we cannot specify the device tree what would be the use of this 
>  for
>  ARM processors?
> >>>
> >>> I don't get your point. What's the matter with device tree?
> >>
> >> To boot an ARM board on Linux or BSD you need a device tree.
> >
> > When I discussed with Alex about Boot Manager (and distro_bootcmd?),
> > he suggested that we should not allow users to specify fdt at a command 
> > line.
> > I believe that it would apply to my case above.
> >
> > IMO, we should always provide system's fdt to EFI applications.
> 
>  With current Linux development practice this unfortunately does not
>  work. Linux device trees sometimes see incompatible changes between
>  versions. Booting may fail with a device tree that is either too old or
>  too new for your Linux version.
> 
>  E.g. for the Odroid C2 some reserved memory regions were removed from
>  the device tree and replaced by a logic that determines them on the fly
>  due to changes in ARM trusted firmware location.
> 
>  The Wandboard rev B1 device tree was moved to a new file when a new
>  board revision appeared and the new revision changed the old file (sic).
> 
>  U-Boot is also not perfect at keeping its device tree in sync with the
>  newest Linux device tree.
> >>>
> >>> Why don't you use "fdt" command in that case?
> >>> IMO, we don't need  argument at bootefi (and run -e).
> >>> Obviously, I have one assumption that we need change the code
> >>> to utilize "fdtaddr" variable in do_bootefi().
> >>
> >> Such a change would mean that after an upgrade of U-Boot all boards
> >> running on Suse and Fedora suddenly will not boot again.
> > 
> > Why do you think so?
> > Unless people intentionally run "fdt" command before bootefi,
> > the system will behave in the exact same way.
> > 
> > How many people really expect that, in the case below,
> >   => load ...  
> >   => fdt addr 
> >   => bootefi bootmgr
> > bootefi will start EFI application *without* fdt?
> > 
> > -Takahiro Akashi
> 
> Your previous mail sounded to me as if you wanted to drop the
> possibility to specify an FDT address in the bootefi command. But maybe
> I got you wrong.

No, even in v2, I didn't change any semantics in do_bootefi()
and hence bootefi command.

> If your idea is that we should use the address specified in command fdt
> and $fdtcontroladdr as fallbacks if no FDT address is specified, that is
> another story.

Exactly for "run -e" case (and probably a new command, efibootmgr, too).

The only concern is an incompatibility with distro_bootcmd.
It has yet another logic regarding fdt.

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> > 
> >> We should not change existing commands in an incompatible way.
> >>
> >>>
> >>> Under the current implementation, a similar behavior is achieved
> >>> only via distro_bootcmd. IMO, this should be corrected.
> >>> If you agree, I will add another patch to my current patchset
> >>> for this purpose.
> >>
> >> I suggest to drop patch 5/5 from your series.
> >>
> >> Best regards
> >>
> >> Heinrich
> >>
> >>>
> >
> >> So run -e Boot0001 will not allow you to boot into Linux because it 
> >> does
> >> not specify a device tree.
> >>
> >>>
> >>>
>  Why do you add the option to run and not to bootefi?
> 
>  You already introduced the capability to set BootNext. Why isn't that
>  enough?
> >>>
> >>> Simple.
> >>>
> >>> => run -e Boot00>
> >>> versus
> >>>
> >>> => efidebug boot next 1
> >>> => bootefi bootmgr
> >>
> >> In patch 4/5 you already introduced 'bootefi bootmgr $fdt_addr_r 0001'
> >>
> >> So there is no need to go through efidebug.
> >>
> >> I think we should avoid alternative commands.
> >
> > As I said, I already removed this feature from bootefi.
> >
> >>>
> >>> First of all, efidebug is only recognized as a *debugging* tool.
> >>> I believe that the former

Re: [U-Boot] i.MX8MQ: u-boot-spl-ddr.bin not found

Hi Fabio,

> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年2月28日 20:59
> To: Peng Fan 
> Cc: Stefano Babic ; Baruch Siach ;
> Chris Spencer ; U-Boot-Denx 
> Subject: i.MX8MQ: u-boot-spl-ddr.bin not found
> 
> Hi,
> 
> I am not able to build top of tree U-Boot for imx8mq-evk:
> 
> WARNING './spl/u-boot-spl-ddr.bin' not found, resulting binary is
> not-functional
> make[1]: Nothing to be done for 'SPL'.
>   CFGCHK  u-boot.cfg
> 
> It works fine when I build from u-boot-imx tree though.
> 
> I have copied all the binaries to the U-Boot source as per the README.
> 
> Does anyone have any ideas to fix the build for U-boot mainline?


Did you execute `make flash.bin`?

Regards,
Peng.

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

Re: [U-Boot] [PATCH v2 1/2] imx8mq_evk/README: add missing firmware extract step



> -Original Message-
> From: Baruch Siach [mailto:bar...@tkos.co.il]
> Sent: 2019年2月28日 19:51
> To: u-boot@lists.denx.de; Stefano Babic ; Peng Fan
> 
> Cc: Ofer Heifetz ; Fabio Estevam
> ; Baruch Siach 
> Subject: [PATCH v2 1/2] imx8mq_evk/README: add missing firmware extract
> step
> 
> Tested-by: Fabio Estevam 
> Signed-off-by: Baruch Siach 
> ---
>  board/freescale/imx8mq_evk/README | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/board/freescale/imx8mq_evk/README
> b/board/freescale/imx8mq_evk/README
> index 1da6eaf24277..004fa3fb3cf6 100644
> --- a/board/freescale/imx8mq_evk/README
> +++ b/board/freescale/imx8mq_evk/README
> @@ -18,6 +18,7 @@ Get the ddr and hdmi firmware
>  Note: srctree is U-Boot source directory  $ wget
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Ffirmware-imx-7.9.bin&
> amp;data=02%7C01%7Cpeng.fan%40nxp.com%7C6242b94a27db448363980
> 8d69d730df3%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C6368
> 69514811541188sdata=5qNEEjJvcBUnxx%2BhPCERWWop36OACD9lhJ
> yrXRFzrWs%3Dreserved=0
>  $ chmod +x firmware-imx-7.9.bin
> +$ ./firmware-imx-7.9.bin
>  $ cp firmware-imx-7.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin
> $(srctree)  $ cp
> firmware-imx-7.9/firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin
> $(srctee)

Reviewed-by: Peng Fan 

> 
> --
> 2.20.1

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

Re: [U-Boot] [PATCH v2 2/2] imx8mq_evk/README: fix DDR training firmware path



> -Original Message-
> From: Baruch Siach [mailto:bar...@tkos.co.il]
> Sent: 2019年2月28日 19:51
> To: u-boot@lists.denx.de; Stefano Babic ; Peng Fan
> 
> Cc: Ofer Heifetz ; Fabio Estevam
> ; Baruch Siach 
> Subject: [PATCH v2 2/2] imx8mq_evk/README: fix DDR training firmware
> path
> 
> Remove a redundant directory level.
> 
> Reported-by: Ofer Heifetz 
> Tested-by: Fabio Estevam 
> Signed-off-by: Baruch Siach 
> ---
>  board/freescale/imx8mq_evk/README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/board/freescale/imx8mq_evk/README
> b/board/freescale/imx8mq_evk/README
> index 004fa3fb3cf6..2529f7da3d98 100644
> --- a/board/freescale/imx8mq_evk/README
> +++ b/board/freescale/imx8mq_evk/README
> @@ -20,7 +20,7 @@ $ wget
> https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.nxp.com%2Flgfiles%2FNMG%2FMAD%2FYOCTO%2Ffirmware-imx-7.9.bin&
> amp;data=02%7C01%7Cpeng.fan%40nxp.com%7C53ee3f803c0e4652a0bb08
> d69d730e27%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63686
> 9514831044327sdata=37cNapsnlVb5ZzuJDuDrZF3kpBblfGprxRtUn6ayn
> %2BU%3Dreserved=0
>  $ chmod +x firmware-imx-7.9.bin
>  $ ./firmware-imx-7.9.bin
>  $ cp firmware-imx-7.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin
> $(srctree) -$ cp
> firmware-imx-7.9/firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin
> $(srctee)
> +$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(srctee)

Reviewed-by: Peng Fan 

> 
>  Build U-Boot
>  
> --
> 2.20.1

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

Re: [U-Boot] [PATCH 1/1] efi_loader: HII protocols: informative error message

On Fri, Mar 01, 2019 at 12:02:37AM +0100, Heinrich Schuchardt wrote:
> When package types are not supported an error message is displayed.
> Unfortunately there is no hint in the messages that they concern the HII
> protocols. Furthermore they are indent by tab for no obvious reason.

I think that I intended to use EFI_PRINT() here, but
printf() is fine for showing informative error messages.

> Prefix the messages by "HII: " instead of "\t".

"EFI HII" would be better?

Thanks,
-Takahiro Akashi

> Signed-off-by: Heinrich Schuchardt 
> ---
>  lib/efi_loader/efi_hii.c | 36 ++--
>  1 file changed, 18 insertions(+), 18 deletions(-)
> 
> diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c
> index d63d2d84184..6ee386596a5 100644
> --- a/lib/efi_loader/efi_hii.c
> +++ b/lib/efi_loader/efi_hii.c
> @@ -387,7 +387,7 @@ add_packages(struct efi_hii_packagelist *hii,
>   (struct efi_hii_guid_package *)package);
>   break;
>   case EFI_HII_PACKAGE_FORMS:
> - printf("\tForm package not supported\n");
> + printf("HII: Form package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_STRINGS:
> @@ -395,19 +395,19 @@ add_packages(struct efi_hii_packagelist *hii,
>   (struct efi_hii_strings_package *)package);
>   break;
>   case EFI_HII_PACKAGE_FONTS:
> - printf("\tFont package not supported\n");
> + printf("HII: Font package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_IMAGES:
> - printf("\tImage package not supported\n");
> + printf("HII: Image package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_SIMPLE_FONTS:
> - printf("\tSimple font package not supported\n");
> + printf("HII: Simple font package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_DEVICE_PATH:
> - printf("\tDevice path package not supported\n");
> + printf("HII: Device path package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_KEYBOARD_LAYOUT:
> @@ -415,7 +415,7 @@ add_packages(struct efi_hii_packagelist *hii,
>   (struct efi_hii_keyboard_package *)package);
>   break;
>   case EFI_HII_PACKAGE_ANIMATIONS:
> - printf("\tAnimation package not supported\n");
> + printf("HII: Animation package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_END:
> @@ -522,33 +522,33 @@ update_package_list(const struct 
> efi_hii_database_protocol *this,
>   remove_guid_package(hii);
>   break;
>   case EFI_HII_PACKAGE_FORMS:
> - printf("\tForm package not supported\n");
> + printf("HII: Form package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_STRINGS:
>   remove_strings_package(hii);
>   break;
>   case EFI_HII_PACKAGE_FONTS:
> - printf("\tFont package not supported\n");
> + printf("HII: Font package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_IMAGES:
> - printf("\tImage package not supported\n");
> + printf("HII: Image package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_SIMPLE_FONTS:
> - printf("\tSimple font package not supported\n");
> + printf("HII: Simple font package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_DEVICE_PATH:
> - printf("\tDevice path package not supported\n");
> + printf("HII: Device path package not supported\n");
>   ret = EFI_INVALID_PARAMETER;
>   break;
>   case EFI_HII_PACKAGE_KEYBOARD_LAYOUT:
>   remove_keyboard_package(hii);
>   break;
>   case

Re: [U-Boot] [PATCH 2/2] imx8mq_evk: Add myself as a co-maintainer



> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年2月28日 19:46
> To: sba...@denx.de
> Cc: Peng Fan ; u-boot@lists.denx.de; dl-uboot-imx
> ; spence...@gmail.com; bar...@tkos.co.il; Fabio
> Estevam 
> Subject: [PATCH 2/2] imx8mq_evk: Add myself as a co-maintainer
> 
> I would like to help maintaining this board.
> 
> Signed-off-by: Fabio Estevam 

Acked-by: Peng Fan 

> ---
>  board/freescale/imx8mq_evk/MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/board/freescale/imx8mq_evk/MAINTAINERS
> b/board/freescale/imx8mq_evk/MAINTAINERS
> index a2e320cb10..a00bb4ef78 100644
> --- a/board/freescale/imx8mq_evk/MAINTAINERS
> +++ b/board/freescale/imx8mq_evk/MAINTAINERS
> @@ -1,5 +1,6 @@
>  i.MX8MQ EVK BOARD
>  M:   Peng Fan 
> +M:   Fabio Estevam 
>  S:   Maintained
>  F:   board/freescale/imx8mq_evk/
>  F:   include/configs/imx8mq_evk.h
> --
> 2.17.1

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

Re: [U-Boot] [PATCH 1/2] imx8mq_evk: Move CONFIG_ENV_IS_IN_MMC to Kconfig



> -Original Message-
> From: Fabio Estevam [mailto:feste...@gmail.com]
> Sent: 2019年2月28日 19:46
> To: sba...@denx.de
> Cc: Peng Fan ; u-boot@lists.denx.de; dl-uboot-imx
> ; spence...@gmail.com; bar...@tkos.co.il; Fabio
> Estevam 
> Subject: [PATCH 1/2] imx8mq_evk: Move CONFIG_ENV_IS_IN_MMC to
> Kconfig
> 
> Currently the command "saveenv" is not available.
> 
> The CONFIG_ENV_IS_IN_MMC symbol has been converted to Kconfig, so fix
> the problem by moving it to the defconfig.
> 
> Signed-off-by: Fabio Estevam 
> ---
>  configs/imx8mq_evk_defconfig | 1 +
>  include/configs/imx8mq_evk.h | 1 -
>  2 files changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig
> index 53025e45bc..889d8f1484 100644
> --- a/configs/imx8mq_evk_defconfig
> +++ b/configs/imx8mq_evk_defconfig
> @@ -22,6 +22,7 @@ CONFIG_CMD_EXT4_WRITE=y  CONFIG_CMD_FAT=y
> CONFIG_OF_CONTROL=y
> CONFIG_DEFAULT_DEVICE_TREE="fsl-imx8mq-evk"
> +CONFIG_ENV_IS_IN_MMC=y
>  CONFIG_SAVED_DRAM_TIMING_BASE=0x4000
>  CONFIG_DM_GPIO=y
>  CONFIG_DM_I2C=y
> diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h
> index f0430224cb..a9e38a70e6 100644
> --- a/include/configs/imx8mq_evk.h
> +++ b/include/configs/imx8mq_evk.h
> @@ -187,7 +187,6 @@
>  #define CONFIG_ENV_OVERWRITE
>  #define CONFIG_ENV_OFFSET   (64 * SZ_64K)
>  #define CONFIG_ENV_SIZE  0x1000
> -#define CONFIG_ENV_IS_IN_MMC
>  #define CONFIG_SYS_MMC_ENV_DEV   1   /* USDHC2 */
>  #define CONFIG_MMCROOT   "/dev/mmcblk1p2"  /* USDHC2

Reviewed-by: Peng Fan 

> */
> 
> --
> 2.17.1

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

Re: [U-Boot] [PATCH 1/1] efi_loader: HII protocols: fix new_package_list()

On Thu, Feb 28, 2019 at 11:20:34PM +0100, Heinrich Schuchardt wrote:
> In new_package_list() we call new_packagelist() to create a new package
> list. Next we try to add the packages which fails for form packages. Due
> to this error we call free_packagelist(). Now in free_packagelist()
> list_del() is called for an uninitialized field hii->link. This leads to
> changing random memory addresses.
> 
> To solve the problem move the initialization of hii->link to
> new_packagelist().
> 
> Signed-off-by: Heinrich Schuchardt 
> ---
> @Takahiro:
> Please, review the patch.

Good catch, thank you.

Reviewed-by: AKASHI Takahiro 

> ---
>  lib/efi_loader/efi_hii.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c
> index d63d2d84184..0ed4b196333 100644
> --- a/lib/efi_loader/efi_hii.c
> +++ b/lib/efi_loader/efi_hii.c
> @@ -343,6 +343,7 @@ static struct efi_hii_packagelist *new_packagelist(void)
>   struct efi_hii_packagelist *hii;
>  
>   hii = malloc(sizeof(*hii));
> + list_add_tail(>link, _package_lists);
>   hii->max_string_id = 0;
>   INIT_LIST_HEAD(>string_tables);
>   INIT_LIST_HEAD(>guid_list);
> @@ -465,7 +466,6 @@ new_package_list(const struct efi_hii_database_protocol 
> *this,
>   }
>  
>   hii->driver_handle = driver_handle;
> - list_add_tail(>link, _package_lists);
>   *handle = hii;
>  
>   return EFI_EXIT(EFI_SUCCESS);
> -- 
> 2.20.1
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: socfpga: Configure PL310 latencies

2019-02-28 Thread Dinh Nguyen

Hi Marek,

On 2/19/19 4:01 AM, Simon Goldschmidt wrote:
> On Tue, Feb 19, 2019 at 1:44 AM Marek Vasut  wrote:
>>
>> Configure the PL310 tag and data latency registers, which slightly
>> improves performance and aligns the behavior with Linux.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Dalon Westergreen 
>> Cc: Dinh Nguyen 
>> ---
>>  arch/arm/mach-socfpga/misc.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
>> index 78fbe28724..1ea4e32c11 100644
>> --- a/arch/arm/mach-socfpga/misc.c
>> +++ b/arch/arm/mach-socfpga/misc.c
>> @@ -62,6 +62,9 @@ void v7_outer_cache_enable(void)
>> /* Disable the L2 cache */
>> clrbits_le32(>pl310_ctrl, L2X0_CTRL_EN);
>>
>> +   writel(0x111, >pl310_tag_latency_ctrl);
>> +   writel(0x121, >pl310_data_latency_ctrl);
> 
> Would it make sense to add defines as named constants for this?
> OTOH, in Linux, the values in the devicetree aren't really described,
> either, so:

I was thinking the same, so I'm working on a patch to get these values
from the device tree.

So while I was doing that, I realized that this patch is wrong.

The patch should be like this:

writel(0x0, >pl310_tag_latency_ctrl);
writel(0x010, >pl310_data_latency_ctrl);

The reason is for the latency values:

000 = 1 cycle of latency, there is no additional latency.
001 = 2 cycles of latency.
010 = 3 cycles of latency.
011 = 4 cycles of latency.
100 = 5 cycles of latency.
101 = 6 cycles of latency.
110 = 7 cycles of latency.
111 = 8 cycles of latency.

So from the values in the device tree, they should be n-1.

It looks like you've already sent the patch to Tom. I'll send a follow
up patch to fix that when it lands.

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

Re: [U-Boot] arm: pdu001: Fix order of include files

On Mon, Feb 25, 2019 at 04:38:23PM +0100, Felix Brack wrote:

> Fix the order of include files according to U-Boot coding style.
> 
> Signed-off-by: Felix Brack 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot, 1/1] fs: fat: fix link error when building with DEBUG=1

On Mon, Feb 25, 2019 at 07:42:48PM +0100, Heinrich Schuchardt wrote:

> When compiling with DEBUG=1 an error
> fs/fat/fat_write.c:831: undefined reference to `__aeabi_ldivmod'
> occurred.
> 
> We should use do_div() instead of the modulus operator.
> 
> filesize and cur_pos cannot be negative. So let's use u64 to avoid
> warnings.
> 
> Fixes: cb8af8af5ba0 ("fs: fat: support write with non-zero offset")
> Signed-off-by: Heinrich Schuchardt 

Applied to u-boot/master, 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] spl: add debug print for early malloc usage

On Tue, Feb 26, 2019 at 10:27:52PM +0100, Simon Goldschmidt wrote:

> To find out how big the early malloc heap must be in SPL, add a debug
> print statement that dumps its usage before switching to relocated heap
> in spl_relocate_stack_gd() via CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN.
> 
> Signed-off-by: Simon Goldschmidt 

Applied to u-boot/master, 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] doc: binding: rename directory ram to memory-controller

On Tue, Feb 26, 2019 at 01:09:00PM +0100, Patrick Delaunay wrote:

> Alignment with kernel directory name as it have already bindings for
> DDR controllers in the directory:
> Documentation/devicetree/bindings/memory-controller
> 
> PS: the drivers using RAM u-class should be associated with
> this binding directory
> 
> Signed-off-by: Patrick Delaunay 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,2/2] kbuild: fix DTB .cmd source variable

On Tue, Feb 26, 2019 at 12:20:26PM -0700, Stephen Warren wrote:

> From: Stephen Warren 
> 
> *.dts are processed using a custom command, then the C pre-processor is
> run on them, then they are compiled using dtc. Thus, the dependency
> files generated by both cpp and dtc reference a temporary file name
> rather than the actual source file. While this information isn't used
> for any purpose by the build system, and hence this causes no functional
> issue, it does cause the dependency files to contain invalid and
> confusing data, which is unhelpful while debugging build problems. Fix
> this using sed.
> 
> Signed-off-by: Stephen Warren 
> Reviewed-by: Masahiro Yamada 

Applied to u-boot/master, thanks!

-- 
Tom


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

Re: [U-Boot] [U-Boot,1/2] kbuild: make arch-dtbs target PHONY

On Tue, Feb 26, 2019 at 12:20:25PM -0700, Stephen Warren wrote:

> From: Stephen Warren 
> 
> Without this, the arch-dtbs target only gets evaluated when building
> U-Boot the first time, not when re-building (incrementally building)
> U-Boot. Thus incremental builds ignore changes to DTB files.
> 
> Signed-off-by: Stephen Warren 
> Reviewed-by: Masahiro Yamada 

Applied to u-boot/master, 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] .gitignore: Ignore regenerated *.dtbo files

On Thu, Feb 21, 2019 at 07:48:54AM +0100, Michal Simek wrote:

> *.dtbo are dt overlays files which should be also ignored as *.dtb.
> 
> Signed-off-by: Michal Simek 

Applied to u-boot/master, 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] ARM: cache: Fix incorrect bitwise operation

On Tue, Feb 19, 2019 at 01:43:51AM +0100, Marek Vasut wrote:

> The loop implemented in the code is supposed to check whether the
> PL310 operation register has any bit from the mask set. Currently,
> the code checks whether the PL310 operation register has any bit
> set AND whether the mask is non-zero, which is incorrect. Fix the
> conditional.
> 
> Signed-off-by: Marek Vasut 
> Cc: Dalon Westergreen 
> Cc: Dinh Nguyen 
> Cc: Tom Rini 
> Fixes: 93bc21930a1b ("armv7: add PL310 support to u-boot")
> Reviewed-by: Simon Goldschmidt 
> Reviewed-by: Dinh Nguyen 

Applied to u-boot/master, 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] spi: omap3: fix set_wordlen() reading from incorrect address for CHCONF

On Mon, Feb 18, 2019 at 06:04:29PM -0500, David Rivshin wrote:

> From: David Rivshin 
> 
> _omap3_spi_set_wordlen() indexed the regs->channel[] array with the
> old wordlen (instead of the chipselect number) when reading the current
> CHCONF register value. This meant it read from the wrong memory location,
> modified that value, and then wrote it back to the correct CHCONF
> register. The end result is that most slave configuration settings would
> be lost, such as clock divisor, clock/chipselect polarities, etc.
> 
> Fixes: 77b8d04854f4 ("spi: omap3: Convert to driver model")
> Signed-off-by: David Rivshin 

Applied to u-boot/master, 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] Pull request: u-boot-sunxi/master

On Fri, Mar 01, 2019 at 12:38:23AM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> Jagan.
> 
> The following changes since commit b89074f65047c4058741ed2bf3e6ff0c5af4c5bc:
> 
>   Merge tag 'u-boot-imx-2019-02-16' of git://git.denx.de/u-boot-imx 
> (2019-02-16 08:31:05 -0500)
> 
> are available in the Git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to da95ed58c4765ff23ed35753878274ef585f28b5:
> 
>   sunxi: Add Bananapi M2+ H5 board (2019-02-18 14:46:53 +0530)
> 

Applied to u-boot/master, 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] Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug

On Wed, Feb 27, 2019 at 11:32:16AM +, Leigh Brown wrote:

> Hello,
> 
> Vagrant Cascadian asked for people to test the version of u-boot packaged
> for Debian Buster.  I tested u-boot on my Dreamplug and found it was not
> working correctly.  I raised a bug for Debian[1] but I have also tested
> with the mainline version of u-boot and found the same issues.
> 
> The first issue is that the following commit caused u-boot to no longer
> be able to access usb storage on the Dreamplug:
> 
> commit 93b283d49f933f95f3a6f40762936f454ac655a8
> Author: Adam Ford 
> Date:   Thu Aug 16 13:23:11 2018 -0500
> 
> ARM: CPU: arm926ejs: Consolidate cache routines to common file
> 
> Four different boards had different options for enabling cache
> that were virtually all the same.  This consolidates these
> common functions into arch/arm/cpu/arm926ejs/cache.c
> 
> This also has the positive side-effect of enabling cache on
> the Davinci (da850) boards.
> 
> Signed-off-by: Adam Ford 
> [trini: Add mach-at91 to the list of consolidations]
> Signed-off-by: Tom Rini 
> 
> I don't have much knowledge of ARM caching, but the following patch makes
> it work again on my Dreamplug.
> 
> diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
> index d54de53f31..8a065d73ae 100644

Thanks for digging into this.  Based on the whole thread, yes, this
makes sense.

Reviewed-by: Tom Rini 

-- 
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] [RESEND PATCH 2/2] ARM: qemu-arm: enable USB boot in distro boot with UEFI

On 12/23/18 3:26 AM, Alexander Graf wrote:
> 
> 
> On 14.12.18 10:53, AKASHI Takahiro wrote:
>> With this patch which adds a removable USB mass storage to a list
>> of bootable devices, USB boot is supported in distro boot if UEFI is
>> configured.
>>
>> Signed-off-by: AKASHI Takahiro 
> 
> Reviewied-by: Alexander Graf 

Hello Tom,

this patch is in status new since December.

My understanding was that this patch can be merged while patch 1/2 of
this series is superseded.

Best regards

Heinrich

> 
> 
> Alex
> 
>> ---
>>  include/configs/qemu-arm.h | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/include/configs/qemu-arm.h b/include/configs/qemu-arm.h
>> index fedc4662fa18..392839f7ad59 100644
>> --- a/include/configs/qemu-arm.h
>> +++ b/include/configs/qemu-arm.h
>> @@ -24,6 +24,7 @@
>>  #define CONFIG_ENV_SIZE SZ_64K
>>  
>>  #define BOOT_TARGET_DEVICES(func) \
>> +func(USB, usb, 0) \
>>  func(SCSI, scsi, 0) \
>>  func(DHCP, dhcp, na)
>>  
>>
> 

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

[U-Boot] [PATCH 1/1] efi_loader: HII protocols: informative error message

When package types are not supported an error message is displayed.
Unfortunately there is no hint in the messages that they concern the HII
protocols. Furthermore they are indent by tab for no obvious reason.

Prefix the messages by "HII: " instead of "\t".

Signed-off-by: Heinrich Schuchardt 
---
 lib/efi_loader/efi_hii.c | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c
index d63d2d84184..6ee386596a5 100644
--- a/lib/efi_loader/efi_hii.c
+++ b/lib/efi_loader/efi_hii.c
@@ -387,7 +387,7 @@ add_packages(struct efi_hii_packagelist *hii,
(struct efi_hii_guid_package *)package);
break;
case EFI_HII_PACKAGE_FORMS:
-   printf("\tForm package not supported\n");
+   printf("HII: Form package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_STRINGS:
@@ -395,19 +395,19 @@ add_packages(struct efi_hii_packagelist *hii,
(struct efi_hii_strings_package *)package);
break;
case EFI_HII_PACKAGE_FONTS:
-   printf("\tFont package not supported\n");
+   printf("HII: Font package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_IMAGES:
-   printf("\tImage package not supported\n");
+   printf("HII: Image package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_SIMPLE_FONTS:
-   printf("\tSimple font package not supported\n");
+   printf("HII: Simple font package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_DEVICE_PATH:
-   printf("\tDevice path package not supported\n");
+   printf("HII: Device path package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_KEYBOARD_LAYOUT:
@@ -415,7 +415,7 @@ add_packages(struct efi_hii_packagelist *hii,
(struct efi_hii_keyboard_package *)package);
break;
case EFI_HII_PACKAGE_ANIMATIONS:
-   printf("\tAnimation package not supported\n");
+   printf("HII: Animation package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_END:
@@ -522,33 +522,33 @@ update_package_list(const struct 
efi_hii_database_protocol *this,
remove_guid_package(hii);
break;
case EFI_HII_PACKAGE_FORMS:
-   printf("\tForm package not supported\n");
+   printf("HII: Form package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_STRINGS:
remove_strings_package(hii);
break;
case EFI_HII_PACKAGE_FONTS:
-   printf("\tFont package not supported\n");
+   printf("HII: Font package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_IMAGES:
-   printf("\tImage package not supported\n");
+   printf("HII: Image package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_SIMPLE_FONTS:
-   printf("\tSimple font package not supported\n");
+   printf("HII: Simple font package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_DEVICE_PATH:
-   printf("\tDevice path package not supported\n");
+   printf("HII: Device path package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case EFI_HII_PACKAGE_KEYBOARD_LAYOUT:
remove_keyboard_package(hii);
break;
case EFI_HII_PACKAGE_ANIMATIONS:
-   printf("\tAnimation package not supported\n");
+   printf("HII: Animation package not supported\n");
ret = EFI_INVALID_PARAMETER;
break;
case

Re: [U-Boot] iMX8QXP MEK: no ethernet

2019-02-28 Thread Anatolij Gustschin

Hi,

On Thu, 28 Feb 2019 12:27:45 +
Andrejs Cainikovs andrejs.cainik...@netmodule.com wrote:

> Hi,
> 
> I cant get ethernet to work on iMX8QXP MEK board with latest sources 
> (tried v2019.01 as well). Is this a bug or work in progress?

This is probably due to the missing delay after PHY reset in fec_gpio_reset().

Please try with attached patch, it worked for me on MEK board with RevA CPU.

--
Anatolij
>From 0f5297e36eb280c983415e6e63e469b876acf990 Mon Sep 17 00:00:00 2001
From: Anatolij Gustschin 
Date: Thu, 11 Oct 2018 19:37:51 +0200
Subject: [PATCH] net: fec: delay after PHY reset when on i.MX8QXP MEK board

Some delay after PHY reset is required, otherwise the PHY
detection fails and ethernet doesn't work as a result.
Add delay when building for i.MX8QXP MEK board.

Signed-off-by: Anatolij Gustschin 
---
 drivers/net/fec_mxc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 1a59026a62..81904740de 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -1315,6 +1315,9 @@ static void fec_gpio_reset(struct fec_priv *priv)
 		dm_gpio_set_value(>phy_reset_gpio, 1);
 		mdelay(priv->reset_delay);
 		dm_gpio_set_value(>phy_reset_gpio, 0);
+#if CONFIG_IS_ENABLED(TARGET_IMX8QXP_MEK)
+		mdelay(150);
+#endif
 	}
 }
 #endif
-- 
2.17.1

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

Re: [U-Boot] IMX6 DM_USB / DM_MMC requires OF_CONTROL?

2019-02-28 Thread Lukasz Majewski

Hi Tim,

> On Thu, Feb 21, 2019 at 6:48 AM Marcel Ziswiler
>  wrote:
> >
> > Hi Fabio
> >
> > On Tue, 2019-02-19 at 19:32 +0100, Stefano Babic wrote:  
> > > Hi Tim,
> > >
> > > On 19/02/19 19:24, Tim Harvey wrote:  
> > > > Greetings,
> > > >
> > > > I'm seeing that I need to switch my IMX6 board support
> > > > (board/gateworks/gw_ventana) over to DM_USB and DM_MMC right
> > > > away (v2019.04) and I notice enabling those fails building as
> > > > it looks like
> > > > these DM drivers expect OF_CONTROL (U-Boot running from a
> > > > device-tree).
> > > > Is that currently true or am I perhaps missing
> > > > something?  
> > >
> > > You are completely correct : moving to DM requires to set a DT for
> > > the
> > > board.  
> >
> > I don't think that is fully true. There is also the option of using
> > platform data. At least for certain parts of DM that is certainly
> > working (e.g. have a look at colibri_pxa270).
> >  
> 
> Marcel,
> 
> Good point, and IMX boards have used this already as for DM_SERIAL.
> However I don't see this possible yet for IMX (fsl_esdhc.c) DM_MMC...
> one would need to export a platdata struct to
> include/dm/platform_data. I'll have to look into that... I'm sure
> there are many other IMX boards out there that also need to get this
> done and perhaps are not ready to go to OF_CONTROL yet. I did take a
> quick stab at converting my board(s) to OF_CONTROL using
> SPL_MULTI_DTB_FIT and while I'm still not booting the SPL is way too
> large to fit within an IMX6DL cache.

Please look into my recent work for IMX6Q mccmon6 u-boot proper DM/DTS
conversion.

I've also converted the tpc70 board (including SPL).

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




Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lu...@denx.de


pgp7zm2rfZnIq.pgp
Description: OpenPGP digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: kirkwood: add spi0 alias for dreamplug

2019-02-28 Thread Leigh Brown

Hi Chris, 

On 2019-02-28 19:00, Chris Packham wrote:

> On Thu, 28 Feb 2019 22:13 Leigh Brown,  wrote: 
> 
>> Hi Chris,
>> 
>> I tested together with my own patch. It fixes the issue, thanks very 
>> much!
> 
> Great. Thanks again for the bug report. 
> 
> Slightly related I've got a series of changes for USB on kirkwood. Would you 
> be in a position to take them for a spin?

Sure, happy to. 

Regards, 

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

[U-Boot] [RFC 1/2] arm64: zynqmp: add minimal include files to build a pm_cfg_obj.c

2019-02-28 Thread Luca Ceresoli

A following commit will allow U-Boot to pass a configuration object to
the ZynqMP PMU firmware. This configuration object is generated by
Xilinx tools in the form of a C file (pm_cfg_obj.c), which #includes a
few headers with constants definitions.

In order to allow pm_cfg_obj.c to build, include in U-Boot a minimal
version of those headers files:

 - pm_defs: a copy of [0], reduced to remove unneeded values
 - pmu_global.h: empty file, it is included but not really needed
 - xil_types.h: just includes common.h which has all the needed types

[0] 
https://github.com/Xilinx/embeddedsw/blob/xilinx-v2018.3/lib/sw_services/xilpm/src/common/pm_defs.h

Signed-off-by: Luca Ceresoli 
---
 board/xilinx/zynqmp/pm_defs.h| 254 +++
 board/xilinx/zynqmp/pmu_global.h |   0
 board/xilinx/zynqmp/xil_types.h  |   1 +
 3 files changed, 255 insertions(+)
 create mode 100644 board/xilinx/zynqmp/pm_defs.h
 create mode 100644 board/xilinx/zynqmp/pmu_global.h
 create mode 100644 board/xilinx/zynqmp/xil_types.h

diff --git a/board/xilinx/zynqmp/pm_defs.h b/board/xilinx/zynqmp/pm_defs.h
new file mode 100644
index ..a339d5ef4fd1
--- /dev/null
+++ b/board/xilinx/zynqmp/pm_defs.h
@@ -0,0 +1,254 @@
+/**
+*
+* Copyright (C) 2015-2018 Xilinx, Inc.  All rights reserved.
+*
+* Permission is hereby granted, free of charge, to any person obtaining a copy
+* of this software and associated documentation files (the "Software"), to deal
+* in the Software without restriction, including without limitation the rights
+* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+* copies of the Software, and to permit persons to whom the Software is
+* furnished to do so, subject to the following conditions:
+*
+* The above copyright notice and this permission notice shall be included in
+* all copies or substantial portions of the Software.
+*
+* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+* XILINX  BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF
+* OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+* SOFTWARE.
+*
+* Except as contained in this notice, the name of the Xilinx shall not be used
+* in advertising or otherwise to promote the sale, use or other dealings in
+* this Software without prior written authorization from Xilinx.
+*
+**/
+
+/*/
+/**
+ * @file pm_defs.h
+ *
+ * PM Definitions implementation
+ * @addtogroup xpm_apis XilPM APIs
+ * @{
+ */
+
+#ifndef PM_DEFS_H_
+#define PM_DEFS_H_
+
+/** @name Capabilities for RAM
+ *
+ * @{
+ */
+#define PM_CAP_ACCESS  0x1U
+#define PM_CAP_CONTEXT 0x2U
+#define PM_CAP_WAKEUP  0x4U
+/**@}*/
+
+/**
+ * PM Node ID Enum
+ */
+enum XPmNodeId {
+   NODE_UNKNOWN,
+   NODE_APU,
+   NODE_APU_0,
+   NODE_APU_1,
+   NODE_APU_2,
+   NODE_APU_3,
+   NODE_RPU,
+   NODE_RPU_0,
+   NODE_RPU_1,
+   NODE_PLD,
+   NODE_FPD,
+   NODE_OCM_BANK_0,
+   NODE_OCM_BANK_1,
+   NODE_OCM_BANK_2,
+   NODE_OCM_BANK_3,
+   NODE_TCM_0_A,
+   NODE_TCM_0_B,
+   NODE_TCM_1_A,
+   NODE_TCM_1_B,
+   NODE_L2,
+   NODE_GPU_PP_0,
+   NODE_GPU_PP_1,
+   NODE_USB_0,
+   NODE_USB_1,
+   NODE_TTC_0,
+   NODE_TTC_1,
+   NODE_TTC_2,
+   NODE_TTC_3,
+   NODE_SATA,
+   NODE_ETH_0,
+   NODE_ETH_1,
+   NODE_ETH_2,
+   NODE_ETH_3,
+   NODE_UART_0,
+   NODE_UART_1,
+   NODE_SPI_0,
+   NODE_SPI_1,
+   NODE_I2C_0,
+   NODE_I2C_1,
+   NODE_SD_0,
+   NODE_SD_1,
+   NODE_DP,
+   NODE_GDMA,
+   NODE_ADMA,
+   NODE_NAND,
+   NODE_QSPI,
+   NODE_GPIO,
+   NODE_CAN_0,
+   NODE_CAN_1,
+   NODE_EXTERN,
+   NODE_APLL,
+   NODE_VPLL,
+   NODE_DPLL,
+   NODE_RPLL,
+   NODE_IOPLL,
+   NODE_DDR,
+   NODE_IPI_APU,
+   NODE_IPI_RPU_0,
+   NODE_GPU,
+   NODE_PCIE,
+   NODE_PCAP,
+   NODE_RTC,
+   NODE_LPD,
+   NODE_VCU,
+   NODE_IPI_RPU_1,
+   NODE_IPI_PL_0,
+   NODE_IPI_PL_1,
+   NODE_IPI_PL_2,
+   NODE_IPI_PL_3,
+   NODE_PL,
+   NODE_ID_MAX
+};
+
+/**
+ *  PM Reset Line IDs
+ */
+enum XPmReset {
+   XILPM_RESET_PCIE_CFG = 1000,
+   XILPM_RESET_PCIE_BRIDGE,
+   XILPM_RESET_PCIE_CTRL,
+   XILPM_RESET_DP,
+   XILPM_RESET_SWDT_CRF,
+   XILPM_RESET_AFI_FM5,
+   XILPM_RESET_AFI_FM4,
+   XILPM_RESET_AFI_FM3,
+

[U-Boot] [RFC 2/2] arm64: zynqmp: install a PMU firmware config object at runtime

2019-02-28 Thread Luca Ceresoli

Optionally allow U-Boot to load at the PMU firmware configuration
object into the Power Management Unit (PMU) on Xilinx ZynqMP.

The configuration object is required by the PMU FW to use the SoC. So
far the only way to boot using U-Boot SPL was to hard-code the
configuration object in the PMU firmware. Allow a different boot
process, where the PMU FW is equal for any ZynqMP chip and its
configuration is passed at runtime by U-Boot proper.

Requires the PM_SET_CONFIGURATION command to be implemented by ARM
Trusted Firmware.

Signed-off-by: Luca Ceresoli 
---
 arch/arm/mach-zynqmp/include/mach/sys_proto.h |  1 +
 board/xilinx/zynqmp/Kconfig   | 27 +++
 board/xilinx/zynqmp/Makefile  |  4 +++
 board/xilinx/zynqmp/zynqmp.c  | 23 
 4 files changed, 55 insertions(+)

diff --git a/arch/arm/mach-zynqmp/include/mach/sys_proto.h 
b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
index 385c8825f2f6..1f2c0476ce96 100644
--- a/arch/arm/mach-zynqmp/include/mach/sys_proto.h
+++ b/arch/arm/mach-zynqmp/include/mach/sys_proto.h
@@ -22,6 +22,7 @@
 #define ZYNQMP_FPGA_AUTH_DDR   1
 
 #define ZYNQMP_SIP_SVC_GET_API_VERSION 0xC201
+#define ZYNQMP_SIP_SVC_SET_CONFIGURATION   0xC202
 
 #define ZYNQMP_PM_VERSION_MAJOR1
 #define ZYNQMP_PM_VERSION_MINOR0
diff --git a/board/xilinx/zynqmp/Kconfig b/board/xilinx/zynqmp/Kconfig
index 7d1f7398c3e9..e9cec5c95470 100644
--- a/board/xilinx/zynqmp/Kconfig
+++ b/board/xilinx/zynqmp/Kconfig
@@ -15,4 +15,31 @@ config CMD_ZYNQMP
  and authentication feature enabled while generating
  BOOT.BIN using Xilinx bootgen tool.
 
+config ZYNQMP_LOAD_PM_CFG_OBJ_FILE
+   string "PMU firmware configuration object to load at runtime"
+   help
+ Path to a PMU firmware configuration object to be built into
+ U-Boot and loaded at runtime into the PMU firmware.
+
+ The ZynqMP Power Management Unit (PMU) needs a configuration
+ object for most SoC peripherals to work. It can be either
+ hard-coded in the PMUFW or passed at runtime.
+
+ U-Boot can load the configuration object loaded at
+ runtime. To enable this feature set here the file name
+ (absolute path or relative to board/xilinx/zynqmp/). It will
+ be loaded into the PMU firmware at the beginning of U-Boot
+ proper.
+
+ Note: if your pm_cfg_obj.c is generated by the Xilinx tools,
+ you must remove any linking directives from the
+ XPm_ConfigObject declaration! E.g.:
+
+   -const u32 XPm_ConfigObject[] __attribute__((used, 
section(".sys_cfg_data"))) = {
+   +const u32 XPm_ConfigObject[] = {
+
+ Leave this option empty if your PMU firmware has a built-in
+ configuration object or you are loading it by any other
+ means.
+
 endif
diff --git a/board/xilinx/zynqmp/Makefile b/board/xilinx/zynqmp/Makefile
index 80f8ca7e1e4b..5965eff3 100644
--- a/board/xilinx/zynqmp/Makefile
+++ b/board/xilinx/zynqmp/Makefile
@@ -33,6 +33,10 @@ ifneq ($(call ifdef_any_of, CONFIG_ZYNQMP_PSU_INIT_ENABLED 
CONFIG_SPL_BUILD),)
 obj-y += $(init-objs)
 endif
 
+ifneq ($(CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE),"")
+CFLAGS_zynqmp.o += -DZYNQMP_LOAD_PM_CFG_OBJ -I$(srctree)/$(src)
+endif
+
 obj-$(CONFIG_MMC_SDHCI_ZYNQ) += tap_delays.o
 
 ifndef CONFIG_SPL_BUILD
diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
index 5e1d2116bc32..84fecf5a347f 100644
--- a/board/xilinx/zynqmp/zynqmp.c
+++ b/board/xilinx/zynqmp/zynqmp.c
@@ -302,6 +302,25 @@ static char *zynqmp_get_silicon_idcode_name(void)
 }
 #endif
 
+#ifdef ZYNQMP_LOAD_PM_CFG_OBJ
+#include CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE
+
+void zynqmp_pmufw_load_config_object(void)
+{
+   u32 *ocm = (u32*) CONFIG_SPL_TEXT_BASE;
+   int err;
+
+   printf("Loading PMUFW cfg obj using OCM @ %p (size %ld)\n",
+  ocm, sizeof(XPm_ConfigObject));
+
+   memcpy(ocm, XPm_ConfigObject, sizeof(XPm_ConfigObject));
+   err = invoke_smc(ZYNQMP_SIP_SVC_SET_CONFIGURATION,
+CONFIG_SPL_TEXT_BASE, 0, 0, 0, NULL);
+   if (err)
+   panic("Cannot load PMUFW configuration object (%d)\n", err);
+}
+#endif // ZYNQMP_LOAD_PM_CFG_OBJ
+
 int board_early_init_f(void)
 {
int ret = 0;
@@ -316,6 +335,10 @@ int board_early_init_f(void)
if (pm_api_version < ZYNQMP_PM_VERSION)
panic("PMUFW version error. Expected: v%d.%d\n",
  ZYNQMP_PM_VERSION_MAJOR, ZYNQMP_PM_VERSION_MINOR);
+
+   #ifdef ZYNQMP_LOAD_PM_CFG_OBJ
+   zynqmp_pmufw_load_config_object();
+   #endif
 #endif
 
 #if defined(CONFIG_ZYNQMP_PSU_INIT_ENABLED)
-- 
2.17.1

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

[U-Boot] [RFC 0/2] arm64: zynqmp: pass a PMUFW config object

2019-02-28 Thread Luca Ceresoli

Hi,

a long-standing issue in the ZynqMP users community is the management
on the PMU firmware configuration object.

The Platform Management Unit (PMU) needs a configuration object (cfg
obj) to know how to operate the SoC. When using the "Xilinx workflow",
the Xilinx FSBL (First Stage Bootloader) has te SPL role. FSBL has a
built-in cfg obj and passes it to the PMUFW at runtime before jumping
to U-Boot proper.

This is just not implemented in the U-Boot code. The best workaround
for U-Boot SPL users is to patch [0] the PMUFW itself to have the cfg
obj built-in and self-load it. This approach has some drawbacks: among
others, it forces to use a different PMUFW binary for each hardware
and hardware configuation. It also makes it impossible to change the
configuration after boot.

This patchset is a first attempt at filling the gap by allowing U-Boot
to load the cfg obj firmware at runtime. It adds a Kconfig string
option to point to the cfg obj in the form of a C file as produced by
Xilinx tools (usually called pm_cfg_obj.c). If the option is
non-empty, code is enabled to compile that file in U-Boot proper and
to send the configuration to PMUFW early after SPL.

This mechanism relies on the underlying EL3 (ARM Trusted Firmware) to
implement the SET_CONFIGURATION SMC call. I just sent a trivial pull
request [1] to ATF to add this call. With this in place, the path of
the cfg obj is U-Boot -> ATF -> PMUFW.

This is a rather simple approach that works in many cases, but not
all, as pointed out by Michal Simek. Some boards (reportedly zcu100
and ultra96 according to Michal) need the cfg obj loaded in SPL,
before applying psu_init. Such boards cannot boot with my patches.

Michal also suggested that the cfg obj loading code should be
available both in SPL (configured at build time) and in U-Boot proper
(loading an object from a file) in order to support different FPGA
configuration and partial reconfiguration at runtime. Even with these
limitations Michal suggested to send this work as an RFC to start the
discussion.

These patches are tested on the ZCU106 and UltraZed EV boards.

[0]
https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware/0001-Load-XPm_ConfigObject-at-boot.patch

[1] https://github.com/ARM-software/arm-trusted-firmware/pull/1850

Luca

Luca Ceresoli (2):
arm64: zynqmp: add minimal include files to build a pm_cfg_obj.c
arm64: zynqmp: install a PMU firmware config object at runtime

arch/arm/mach-zynqmp/include/mach/sys_proto.h | 1 +
board/xilinx/zynqmp/Kconfig | 27 ++
board/xilinx/zynqmp/Makefile | 4 +
board/xilinx/zynqmp/pm_defs.h | 254 ++
board/xilinx/zynqmp/pmu_global.h | 0
board/xilinx/zynqmp/xil_types.h | 1 +
board/xilinx/zynqmp/zynqmp.c | 23 ++
7 files changed, 310 insertions(+)
create mode 100644 board/xilinx/zynqmp/pm_defs.h
create mode 100644 board/xilinx/zynqmp/pmu_global.h
create mode 100644 board/xilinx/zynqmp/xil_types.h

--
2.17.1

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

[U-Boot] [PATCH 1/1] efi_loader: HII protocols: fix new_package_list()

In new_package_list() we call new_packagelist() to create a new package
list. Next we try to add the packages which fails for form packages. Due
to this error we call free_packagelist(). Now in free_packagelist()
list_del() is called for an uninitialized field hii->link. This leads to
changing random memory addresses.

To solve the problem move the initialization of hii->link to
new_packagelist().

Signed-off-by: Heinrich Schuchardt 
---
@Takahiro:
Please, review the patch.
---
 lib/efi_loader/efi_hii.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/efi_loader/efi_hii.c b/lib/efi_loader/efi_hii.c
index d63d2d84184..0ed4b196333 100644
--- a/lib/efi_loader/efi_hii.c
+++ b/lib/efi_loader/efi_hii.c
@@ -343,6 +343,7 @@ static struct efi_hii_packagelist *new_packagelist(void)
struct efi_hii_packagelist *hii;
 
hii = malloc(sizeof(*hii));
+   list_add_tail(>link, _package_lists);
hii->max_string_id = 0;
INIT_LIST_HEAD(>string_tables);
INIT_LIST_HEAD(>guid_list);
@@ -465,7 +466,6 @@ new_package_list(const struct efi_hii_database_protocol 
*this,
}
 
hii->driver_handle = driver_handle;
-   list_add_tail(>link, _package_lists);
*handle = hii;
 
return EFI_EXIT(EFI_SUCCESS);
-- 
2.20.1

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

[U-Boot] db-88f6820-amc doesn't boot on latest u-boot/master

Hi All,

I was just testing out the db-88f6820-amc on u-boot#master and found
that the SPL can't fetch then next stage from SPI.

U-Boot SPL 2019.04-rc2-00139-g91c56ed98da7 (Mar 01 2019 - 10:26:26 +1300)
High speed PHY - Version: 2.0
Detected Device ID 6820
board SerDes lanes topology details:
| Lane # | Speed | Type |

| 0 | 5 | PCIe0 |
| 4 | 0 | SGMII1 |
| 5 | 0 | SGMII2 |

PCIe, Idx 0: detected no link
High speed PHY - Ended Successfully
mv_ddr: mv_ddr-armada-18.09.2
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
mv_ddr: completed successfully
Trying to boot from SPI SPI probe failed.
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I haven't had time to bisect this yet but I wondered if this was
related to the recent spi changes (this board uses SPI1 so maybe
that's the corner case). I may also potentially be fixed by the SPI
Kconfig series that is floating around on the list.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC 0/9] Convert Pico-Pi i.MX7D to DM

2019-02-28 Thread Offouga Joris



> Le 28 févr. 2019 à 21:38, Fabio Estevam  a écrit :
> 
> Hi Joris,
> 
>> On Sat, Feb 16, 2019 at 1:25 PM Fabio Estevam  wrote:
>> 
>> Just run a "git bisect" and the problem comes from:
>> 
>> commit 9e3c0174da842dd88f5feaffbf843ba332233897 (refs/bisect/bad)
>> Author: Fabio Estevam 
>> Date:   Tue Dec 11 16:40:38 2018 -0200
>> 
>>pico-imx7d: Add LCD support
>> 
>>Add support for the VXT VL050-8048NT-C01 panel connected through
>>the 24 bit parallel LCDIF interface.
>> 
>>Signed-off-by: Fabio Estevam 
>>Signed-off-by: Otavio Salvador 
>> 
>> It used to work at some point as I could see the splashscreen logo in
>> the screen.
> 
> Just a quick update: if I boot from eMMC I don't see this video
> related hang. I only see the hang when I boot from USB.
I do not have the screen connected when I do my tests and I disabled 
CONFIG_VIDEO because it lacks the GPIOs for the screen in the current device 
tree
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] arm: socfpga: a10: move SPL stack size to Kconfig

On 2/28/19 9:33 PM, Simon Goldschmidt wrote:
> Instead of fixing the SPL stack to 64 KiB in the board config header via
> CONFIG_SYS_SPL_MALLOC_SIZE, let's just use CONFIG_SPL_SYS_MALLOC_F_LEN
> in the defconfig.
> 
> This also has the advandage that it removes sub-mach specific ifdefs in
> socfpga_common.h.
> 
> Signed-off-by: Simon Goldschmidt 

Can't we default these stack sizes with imply in Kconfig files instead ?
Then they won't have to be in the defconfigs either.

> ---
> 
>  configs/socfpga_arria10_defconfig |  1 +
>  include/configs/socfpga_common.h  | 14 --
>  2 files changed, 1 insertion(+), 14 deletions(-)
> 
> diff --git a/configs/socfpga_arria10_defconfig 
> b/configs/socfpga_arria10_defconfig
> index f321a0ac3b..8d0479cc05 100644
> --- a/configs/socfpga_arria10_defconfig
> +++ b/configs/socfpga_arria10_defconfig
> @@ -2,6 +2,7 @@ CONFIG_ARM=y
>  CONFIG_ARCH_SOCFPGA=y
>  CONFIG_SYS_TEXT_BASE=0x0140
>  CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_SPL_SYS_MALLOC_F_LEN=0x1
>  CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y
>  CONFIG_SPL=y
>  CONFIG_IDENT_STRING="socfpga_arria10"
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index a3fbca0a5d..c23b34186a 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -251,16 +251,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  #define CONFIG_SPL_TEXT_BASE CONFIG_SYS_INIT_RAM_ADDR
>  #define CONFIG_SPL_MAX_SIZE  CONFIG_SYS_INIT_RAM_SIZE
>  
> -#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> -/* SPL memory allocation configuration, this is for FAT implementation */
> -#ifndef CONFIG_SYS_SPL_MALLOC_START
> -#define CONFIG_SYS_SPL_MALLOC_SIZE   0x0001
> -#define CONFIG_SYS_SPL_MALLOC_START  (CONFIG_SYS_INIT_RAM_SIZE - \
> -  CONFIG_SYS_SPL_MALLOC_SIZE + \
> -  CONFIG_SYS_INIT_RAM_ADDR)
> -#endif
> -#endif
> -
>  /* SPL SDMMC boot support */
>  #ifdef CONFIG_SPL_MMC_SUPPORT
>  #if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
> @@ -287,11 +277,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  /*
>   * Stack setup
>   */
> -#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
>  #define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
> -#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
> -#define CONFIG_SPL_STACK CONFIG_SYS_SPL_MALLOC_START
> -#endif
>  
>  /* Extra Environment */
>  #ifndef CONFIG_SPL_BUILD
> 


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

Re: [U-Boot] [PATCH 3/3] arm: socfpga: put initial U-Boot stack into DDR

On 2/28/19 9:33 PM, Simon Goldschmidt wrote:
> If SPL pre-reloc stage puts the stack into DDR, U-Boot should be able to
> do that, too.

Here you mention SPL pre-reloc stage, while about mid-way through the
patch you have a comment talking about SPL post-reloc stage, which one
is it ? I think the commit message needs rewording, it's not clear what
the patch does based on it.

On a separate note, this is likely a fix for current release, right ?

Finally , keep in mind the A10 needs to load the FPGA before DRAM
becomes available, so the stack shenanigans there become even more nasty.

> The reason to do so is that this way, U-Boot initial stack can be larger
> than SPL initial stack. In situations where we want to save the SPL
> in SRAM for next boot without reloading, this prevents overwriting the
> SPL DTB in SRAM if U-Boot stack usage gets too high.
> 
> Signed-off-by: Simon Goldschmidt 
> ---
> 
>  include/configs/socfpga_common.h | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/include/configs/socfpga_common.h 
> b/include/configs/socfpga_common.h
> index c23b34186a..7ae3db233f 100644
> --- a/include/configs/socfpga_common.h
> +++ b/include/configs/socfpga_common.h
> @@ -38,12 +38,23 @@
>  #if ((CONFIG_SYS_BOOTCOUNT_ADDR > CONFIG_SYS_INIT_RAM_ADDR) &&   \
>   (CONFIG_SYS_BOOTCOUNT_ADDR < (CONFIG_SYS_INIT_RAM_ADDR +\
>  CONFIG_SYS_INIT_RAM_SIZE)))
> -#define CONFIG_SYS_INIT_SP_ADDR  CONFIG_SYS_BOOTCOUNT_ADDR
> +#define CONFIG_SPL_STACK CONFIG_SYS_BOOTCOUNT_ADDR
>  #else
> -#define CONFIG_SYS_INIT_SP_ADDR  \
> +#define CONFIG_SPL_STACK \
>   (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)
>  #endif
>  
> +/*
> + * U-Boot stack setup: if SPL post-reloc uses DDR stack, use it in pre-reloc
> + * phase of U-Boot, too. This prevents overwriting SPL data if stack/heap 
> usage
> + * in U-Boot pre-reloc is higher than in SPL.
> + */
> +#if defined(CONFIG_SPL_STACK_R_ADDR) && CONFIG_SPL_STACK_R_ADDR
> +#define CONFIG_SYS_INIT_SP_ADDR  CONFIG_SPL_STACK_R_ADDR
> +#else
> +#define CONFIG_SYS_INIT_SP_ADDR  CONFIG_SPL_STACK
> +#endif
> +
>  #define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1
>  
>  /*
> @@ -274,11 +285,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
>  #define CONFIG_SYS_NAND_U_BOOT_OFFS  0x4
>  #endif
>  
> -/*
> - * Stack setup
> - */
> -#define CONFIG_SPL_STACK CONFIG_SYS_INIT_SP_ADDR
> -
>  /* Extra Environment */
>  #ifndef CONFIG_SPL_BUILD
>  
> 


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

[U-Boot] [PULL] u-boot-socfpga/master

SoCFPGA cache/gpio fixes:

The following changes since commit afd46c5f13d0c93c44008bd7040227d0b84e31b9:

  Merge branch '2019-02-22-master-imports' (2019-02-22 22:40:24 -0500)

are available in the Git repository at:

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

for you to fetch changes up to 4a9743f73c10a4b3801be3b662a892f61617256e:

  ARM: socfpga: Clear PL310 early in SPL (2019-02-25 16:07:36 +0100)


Julien Béraud (1):
  gpio: altera_pio: fix get_value

Marek Vasut (3):
  ARM: cache: Fix incorrect bitwise operation
  ARM: socfpga: Configure PL310 latencies
  ARM: socfpga: Clear PL310 early in SPL

 arch/arm/lib/cache-pl310.c   |  2 +-
 arch/arm/mach-socfpga/misc.c |  3 +++
 arch/arm/mach-socfpga/spl_gen5.c | 58
++
 drivers/gpio/altera_pio.c|  2 +-
 4 files changed, 63 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

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

Gen2/Gen3 fixes for warnings and sdhi:

The following changes since commit afd46c5f13d0c93c44008bd7040227d0b84e31b9:

  Merge branch '2019-02-22-master-imports' (2019-02-22 22:40:24 -0500)

are available in the Git repository at:

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

for you to fetch changes up to ba41c45ec3402178520ca59d5d847c1c94ae25c4:

  mmc: renesas: Unconditionally set DTCNTL TAPNUM to 8 (2019-02-25
16:07:41 +0100)


Marek Vasut (9):
  ARM: rmobile: Imply clock drivers per SoC
  ARM: rmobile: Imply pinctrl drivers per SoC
  clk: rmobile: Drop def_bool per SoC
  pinctrl: renesas: Drop def_bool per SoC
  ARM: rmobile: Imply SoC per board
  ARM: rmobile: Sync Gen3 defconfigs
  ARM: rmobile: Convert Gen2 to OF_SEPARATE
  mmc: tmio: Clear BUSWIDTH bit when WMODE bit is set
  mmc: renesas: Unconditionally set DTCNTL TAPNUM to 8

 arch/arm/mach-rmobile/Kconfig.32  | 10 ++
 arch/arm/mach-rmobile/Kconfig.64  | 24 
 configs/alt_defconfig |  1 -
 configs/blanche_defconfig |  1 -
 configs/gose_defconfig|  1 -
 configs/koelsch_defconfig |  1 -
 configs/lager_defconfig   |  1 -
 configs/porter_defconfig  |  1 -
 configs/r8a77965_salvator-x_defconfig |  1 -
 configs/r8a7796_salvator-x_defconfig  |  1 -
 configs/r8a7796_ulcb_defconfig|  1 -
 configs/silk_defconfig|  1 -
 configs/stout_defconfig   |  1 -
 drivers/clk/renesas/Kconfig   | 10 --
 drivers/mmc/renesas-sdhi.c|  2 +-
 drivers/mmc/tmio-common.c |  2 +-
 drivers/pinctrl/renesas/Kconfig   | 10 --
 17 files changed, 32 insertions(+), 37 deletions(-)

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

Re: [U-Boot] Marvell DDR training custom ODT configuration

On Thu, Feb 28, 2019 at 10:45 PM Baruch Siach  wrote:
>
> Hi Chris,
>
> Currently the value of g_odt_config is hard coded in Marvell SoC
> platform headers. Some SolidRun A388 SOMs need a custom value. These
> SOMs use both DDR chip-selects, but ODT0 alone is connected to both
> chips. For that to work we need to set g_odt_config to 0x3, that is,
> ODT0 is configured for both CS0 and CS1.
>
> How can we do that in a clean way so as to not interfere too much with
> your periodic code syncs from Marvell's DDR training source tree?

In terms of syncing the best approach is upstream first
(https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell) then
it's a non-issue. I've had some success on that front but that may
only be because $dayjob has a commercial relationship with the SoC
vendor and I can access their support channels. Even with that I've
got two outstanding PRs on github that don't seem to be going anywhere
(I have had some feedback through the support channel that the tRAS
changes will be incorporated, no information as to when).

Ideally instead of you or I having to maintain this code it would be
great if someone from Marvell was involved (I see a similar comment on
the recent ThunderX series).

That all said, the only delta we have right now is the configurable 2T
timing (Marvell's code forces 2T timing on for all boards). I've been
tempted to mark that with #ifdef __U_BOOT__ to make it more obvious.
We probably should do the same for any other changes we do end up
making.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/2] mv_ddr: ddr3: only use active chip-selects when tuning ODT

From: Chris Packham 

Inactive chip-selects will give invalid values for read_sample so don't
consider them when trying to determine the overall min/max read sample.

Signed-off-by: Chris Packham 

[https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/18]
Signed-off-by: Chris Packham 
---
Hi Baruch,

Does this help with your boards? It's not the custom g_odt_config you
were after but it might mean that the code gets the right ODT value so
you don't have to override it.

 drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c 
b/drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c
index db0f8ad7fb55..df832ac6dce0 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_hw_algo.c
@@ -50,6 +50,7 @@ int ddr3_tip_write_additional_odt_setting(u32 dev_num, u32 
if_id)
int max_phase = MIN_VALUE, current_phase;
enum hws_access_type access_type = ACCESS_TYPE_UNICAST;
u32 octets_per_if_num = ddr3_tip_dev_attr_get(dev_num, 
MV_ATTR_OCTET_PER_INTERFACE);
+   unsigned int max_cs = mv_ddr_cs_num_get();
 
CHECK_STATUS(ddr3_tip_if_write(dev_num, access_type, if_id,
   DUNIT_ODT_CTRL_REG,
@@ -59,7 +60,7 @@ int ddr3_tip_write_additional_odt_setting(u32 dev_num, u32 
if_id)
  data_read, MASK_ALL_BITS));
val = data_read[if_id];
 
-   for (cs_num = 0; cs_num < MAX_CS_NUM; cs_num++) {
+   for (cs_num = 0; cs_num < max_cs; cs_num++) {
read_sample[cs_num] = GET_RD_SAMPLE_DELAY(val, cs_num);
 
/* find maximum of read_samples */
-- 
2.21.0

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

[U-Boot] [PATCH 1/2] mv_ddr: ddr3: fix tRAS timimg parameter

From: Chris Packham 

Based on the JEDEC standard JESD79-3F. The tRAS timings should include
the highest speed bins at a given frequency. This is similar to commit
683c67b ("mv_ddr: ddr3: fix tfaw timimg parameter") where the wrong
comparison was used in the initial implementation.

Signed-off-by: Chris Packham 

[https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/pull/15]
Signed-off-by: Chris Packham 
---

 drivers/ddr/marvell/a38x/ddr3_training_db.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/ddr/marvell/a38x/ddr3_training_db.c 
b/drivers/ddr/marvell/a38x/ddr3_training_db.c
index 111a8586c6e3..b2f11a839961 100644
--- a/drivers/ddr/marvell/a38x/ddr3_training_db.c
+++ b/drivers/ddr/marvell/a38x/ddr3_training_db.c
@@ -420,13 +420,13 @@ unsigned int mv_ddr_speed_bin_timing_get(enum 
mv_ddr_speed_bin index, enum mv_dd
result = speed_bin_table_t_rcd_t_rp[index];
break;
case SPEED_BIN_TRAS:
-   if (index < SPEED_BIN_DDR_1066G)
+   if (index <= SPEED_BIN_DDR_1066G)
result = 37500;
-   else if (index < SPEED_BIN_DDR_1333J)
+   else if (index <= SPEED_BIN_DDR_1333J)
result = 36000;
-   else if (index < SPEED_BIN_DDR_1600K)
+   else if (index <= SPEED_BIN_DDR_1600K)
result = 35000;
-   else if (index < SPEED_BIN_DDR_1866M)
+   else if (index <= SPEED_BIN_DDR_1866M)
result = 34000;
else
result = 33000;
-- 
2.21.0

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

Re: [U-Boot] [PATCH v2 5/5] cmd: run: add "-e" option to run an EFI application

On 1/15/19 3:54 AM, AKASHI Takahiro wrote:
> "run -e" allows for executing EFI application with a specific "Boot"
> variable. If no "Boot" is specified or "BootOrder" is specified,
> it tries to run an EFI application specified in the order of "bootOrder."
> 
> Signed-off-by: AKASHI Takahiro 
> ---
>  cmd/bootefi.c | 31 +++
>  cmd/nvedit.c  |  9 -
>  common/cli.c  | 10 ++
>  include/command.h |  3 +++
>  4 files changed, 52 insertions(+), 1 deletion(-)
> 
> diff --git a/cmd/bootefi.c b/cmd/bootefi.c
> index 241fd0f987ab..ebe149dffa1f 100644
> --- a/cmd/bootefi.c
> +++ b/cmd/bootefi.c
> @@ -492,6 +492,37 @@ static int do_bootefi_bootmgr_exec(int boot_id)
>   return CMD_RET_SUCCESS;
>  }
>  
> +/* Called by "run" command */
> +int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + int boot_id = -1;
> + char *endp;
> +
> + if (argc > 2)
> + return CMD_RET_USAGE;
> +
> + if (argc == 2) {
> + if (!strcmp(argv[1], "BootOrder")) {
> + boot_id = -1;
> + } else if (!strncmp(argv[2], "Boot", 4)) {
> + boot_id = (int)simple_strtoul([2][4], , 0);
> + if ((argv[2] + strlen(argv[2]) != endp) ||
> + boot_id > 0x)
> + return CMD_RET_USAGE;
> + } else {
> + return CMD_RET_USAGE;
> + }
> + }
> +
> + if (efi_init_obj_list())
> + return CMD_RET_FAILURE;
> +
> + if (efi_handle_fdt(NULL))
> + return CMD_RET_FAILURE;
> +
> + return do_bootefi_bootmgr_exec(boot_id);

This function does not invoke:

    allow_unaligned();
    switch_to_non_secure_mode();

Probably these calls should be moved to efi_init_obj_list() anyway.

Best regards

Heinrich

> +}
> +
>  /* Interpreter command to boot an arbitrary EFI image from memory */
>  static int do_bootefi(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[])
>  {
> diff --git a/cmd/nvedit.c b/cmd/nvedit.c
> index de16c72c23f2..ce746bbf1b3e 100644
> --- a/cmd/nvedit.c
> +++ b/cmd/nvedit.c
> @@ -1344,7 +1344,14 @@ U_BOOT_CMD_COMPLETE(
>   run,CONFIG_SYS_MAXARGS, 1,  do_run,
>   "run commands in an environment variable",
>   "var [...]\n"
> - "- run the commands in the environment variable(s) 'var'",
> + "- run the commands in the environment variable(s) 'var'"
> +#if defined(CONFIG_CMD_BOOTEFI)
> + "\n"
> + "run -e [Boot]\n"
> + "- load and run UEFI app based on 'Boot' UEFI variable",
> +#else
> + ,
> +#endif
>   var_complete
>  );
>  #endif
> diff --git a/common/cli.c b/common/cli.c
> index 51b8d5f85cbb..fbb09d5049a4 100644
> --- a/common/cli.c
> +++ b/common/cli.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -125,6 +126,15 @@ int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char * 
> const argv[])
>   if (argc < 2)
>   return CMD_RET_USAGE;
>  
> +#ifdef CONFIG_CMD_BOOTEFI
> + if (!strcmp(argv[1], "-e")) {
> + argc--;
> + argv++;
> +
> + return do_bootefi_run(cmdtp, flag, argc, argv);
> + }
> +#endif
> +
>   for (i = 1; i < argc; ++i) {
>   char *arg;
>  
> diff --git a/include/command.h b/include/command.h
> index 200c7a5e9f4e..feddef300ccc 100644
> --- a/include/command.h
> +++ b/include/command.h
> @@ -48,6 +48,9 @@ typedef struct cmd_tbl_scmd_tbl_t;
>  #if defined(CONFIG_CMD_RUN)
>  extern int do_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]);
>  #endif
> +#if defined(CONFIG_CMD_BOOTEFI)
> +extern int do_bootefi_run(cmd_tbl_t *cmdtp, int flag, int argc, char * const 
> argv[]);
> +#endif
>  
>  /* common/command.c */
>  int _do_help (cmd_tbl_t *cmd_start, int cmd_items, cmd_tbl_t * cmdtp, int
> 

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

Re: [U-Boot] [RFC 0/9] Convert Pico-Pi i.MX7D to DM

Hi Joris,

On Sat, Feb 16, 2019 at 1:25 PM Fabio Estevam  wrote:

> Just run a "git bisect" and the problem comes from:
>
> commit 9e3c0174da842dd88f5feaffbf843ba332233897 (refs/bisect/bad)
> Author: Fabio Estevam 
> Date:   Tue Dec 11 16:40:38 2018 -0200
>
> pico-imx7d: Add LCD support
>
> Add support for the VXT VL050-8048NT-C01 panel connected through
> the 24 bit parallel LCDIF interface.
>
> Signed-off-by: Fabio Estevam 
> Signed-off-by: Otavio Salvador 
>
> It used to work at some point as I could see the splashscreen logo in
> the screen.

Just a quick update: if I boot from eMMC I don't see this video
related hang. I only see the hang when I boot from USB.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/3] arm: socfpga: a10: move SPL stack size to Kconfig

Instead of fixing the SPL stack to 64 KiB in the board config header via
CONFIG_SYS_SPL_MALLOC_SIZE, let's just use CONFIG_SPL_SYS_MALLOC_F_LEN
in the defconfig.

This also has the advandage that it removes sub-mach specific ifdefs in
socfpga_common.h.

Signed-off-by: Simon Goldschmidt 
---

 configs/socfpga_arria10_defconfig |  1 +
 include/configs/socfpga_common.h  | 14 --
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/configs/socfpga_arria10_defconfig 
b/configs/socfpga_arria10_defconfig
index f321a0ac3b..8d0479cc05 100644
--- a/configs/socfpga_arria10_defconfig
+++ b/configs/socfpga_arria10_defconfig
@@ -2,6 +2,7 @@ CONFIG_ARM=y
 CONFIG_ARCH_SOCFPGA=y
 CONFIG_SYS_TEXT_BASE=0x0140
 CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x1
 CONFIG_TARGET_SOCFPGA_ARRIA10_SOCDK=y
 CONFIG_SPL=y
 CONFIG_IDENT_STRING="socfpga_arria10"
diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index a3fbca0a5d..c23b34186a 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -251,16 +251,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #define CONFIG_SPL_TEXT_BASE   CONFIG_SYS_INIT_RAM_ADDR
 #define CONFIG_SPL_MAX_SIZECONFIG_SYS_INIT_RAM_SIZE
 
-#if defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
-/* SPL memory allocation configuration, this is for FAT implementation */
-#ifndef CONFIG_SYS_SPL_MALLOC_START
-#define CONFIG_SYS_SPL_MALLOC_SIZE 0x0001
-#define CONFIG_SYS_SPL_MALLOC_START(CONFIG_SYS_INIT_RAM_SIZE - \
-CONFIG_SYS_SPL_MALLOC_SIZE + \
-CONFIG_SYS_INIT_RAM_ADDR)
-#endif
-#endif
-
 /* SPL SDMMC boot support */
 #ifdef CONFIG_SPL_MMC_SUPPORT
 #if defined(CONFIG_SPL_FS_FAT) || defined(CONFIG_SPL_FS_EXT4)
@@ -287,11 +277,7 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 /*
  * Stack setup
  */
-#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 #define CONFIG_SPL_STACK   CONFIG_SYS_INIT_SP_ADDR
-#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
-#define CONFIG_SPL_STACK   CONFIG_SYS_SPL_MALLOC_START
-#endif
 
 /* Extra Environment */
 #ifndef CONFIG_SPL_BUILD
-- 
2.17.1

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

[U-Boot] [PATCH 3/3] arm: socfpga: put initial U-Boot stack into DDR

If SPL pre-reloc stage puts the stack into DDR, U-Boot should be able to
do that, too.

The reason to do so is that this way, U-Boot initial stack can be larger
than SPL initial stack. In situations where we want to save the SPL
in SRAM for next boot without reloading, this prevents overwriting the
SPL DTB in SRAM if U-Boot stack usage gets too high.

Signed-off-by: Simon Goldschmidt 
---

 include/configs/socfpga_common.h | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index c23b34186a..7ae3db233f 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -38,12 +38,23 @@
 #if ((CONFIG_SYS_BOOTCOUNT_ADDR > CONFIG_SYS_INIT_RAM_ADDR) && \
  (CONFIG_SYS_BOOTCOUNT_ADDR < (CONFIG_SYS_INIT_RAM_ADDR +  \
   CONFIG_SYS_INIT_RAM_SIZE)))
-#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SYS_BOOTCOUNT_ADDR
+#define CONFIG_SPL_STACK   CONFIG_SYS_BOOTCOUNT_ADDR
 #else
-#define CONFIG_SYS_INIT_SP_ADDR\
+#define CONFIG_SPL_STACK   \
(CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_INIT_RAM_SIZE)
 #endif
 
+/*
+ * U-Boot stack setup: if SPL post-reloc uses DDR stack, use it in pre-reloc
+ * phase of U-Boot, too. This prevents overwriting SPL data if stack/heap usage
+ * in U-Boot pre-reloc is higher than in SPL.
+ */
+#if defined(CONFIG_SPL_STACK_R_ADDR) && CONFIG_SPL_STACK_R_ADDR
+#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SPL_STACK_R_ADDR
+#else
+#define CONFIG_SYS_INIT_SP_ADDRCONFIG_SPL_STACK
+#endif
+
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
 
 /*
@@ -274,11 +285,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 #define CONFIG_SYS_NAND_U_BOOT_OFFS0x4
 #endif
 
-/*
- * Stack setup
- */
-#define CONFIG_SPL_STACK   CONFIG_SYS_INIT_SP_ADDR
-
 /* Extra Environment */
 #ifndef CONFIG_SPL_BUILD
 
-- 
2.17.1

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

[U-Boot] [PATCH 1/3] arm: socfpga: fix comment about SPL memory layout

The comment about SPL memory layout for socfpga gen5 is outdated: the
initial malloc memory is now at the end of the SRAM, gd is below it
(see board_init_f_alloc_reserve).

Signed-off-by: Simon Goldschmidt 
---

 include/configs/socfpga_common.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index c9cbf8f5e3..a3fbca0a5d 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -237,9 +237,9 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
  *
  * 0x_ .. Start of SRAM
  * 0x_ .. Top of stack (grows down)
- * 0x_ .. Malloc area
- * 0x_ .. Global Data
- * 0x_FF00 .. End of SRAM
+ * 0x_ .. Global Data
+ * 0x_ .. Malloc area
+ * 0x_ .. End of SRAM
  *
  * SRAM Memory layout for Arria 10:
  * 0xFFE0_ .. Start of SRAM (bottom)
-- 
2.17.1

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

[U-Boot] [PATCH 1/1] efi_loader: error handling for `efidebug boot add`

In  `efidebug boot add iPXE scsi 0:1 snp-arm64.efi --foo` a parameter is
missing. Hence the command should not silently return as if everything were
ok but should display the usage info.

Signed-off-by: Heinrich Schuchardt 
---
 cmd/efidebug.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/cmd/efidebug.c b/cmd/efidebug.c
index 5072a7b39bc..db96682c5a4 100644
--- a/cmd/efidebug.c
+++ b/cmd/efidebug.c
@@ -491,7 +491,7 @@ static int do_efi_boot_add(cmd_tbl_t *cmdtp, int flag,
 
id = (int)simple_strtoul(argv[1], , 16);
if (*endp != '\0' || id > 0x)
-   return CMD_RET_FAILURE;
+   return CMD_RET_USAGE;
 
sprintf(var_name, "Boot%04X", id);
p = var_name16;
-- 
2.20.1

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

Re: [U-Boot] [PATCH v4 19/20] board: mx6sabresd: Remove the enet reset gpio handling

Hi Soeren,

On Thu, Feb 28, 2019 at 4:01 PM Soeren Moch  wrote:

> Fabio,
>
> I tried to understand this patch, in order to also apply it  for the
> tbs2910 board.
> What I read from the fec_mxc driver, this only works with DM_ETH
> enabled, but this is not enabled for mx6sabresd.

Good catch. DM_ETH needs to be enabled for mx6sabresd.

However, I noticed that when using U-Boot master I can not boot
mx6sabresd anymore:

U-Boot SPL 2019.04-rc2-00134-g783e66816d (Feb 28 2019 - 16:17:32 -0300)
Trying to boot from MMC1

(It hangs here)

Abel, Peng,

Could you please take a look at this?

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

[U-Boot] Pull request: u-boot-sunxi/master

2019-02-28 Thread Jagan Teki

Hi Tom,

Please pull this PR.

Jagan.

The following changes since commit b89074f65047c4058741ed2bf3e6ff0c5af4c5bc:

  Merge tag 'u-boot-imx-2019-02-16' of git://git.denx.de/u-boot-imx (2019-02-16 
08:31:05 -0500)

are available in the Git repository at:

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

for you to fetch changes up to da95ed58c4765ff23ed35753878274ef585f28b5:

  sunxi: Add Bananapi M2+ H5 board (2019-02-18 14:46:53 +0530)


Chen-Yu Tsai (3):
  sunxi: Sync Bananapi M2+ device tree from Linux v5.0-rc1
  sunxi: Rename Sinovoip BPI M2 Plus to Bananapi M2 Plus H3
  sunxi: Add Bananapi M2+ H5 board

 arch/arm/dts/sun50i-h5-bananapi-m2-plus.dts|  11 +
 arch/arm/dts/sun8i-h3-bananapi-m2-plus.dts | 190 +---
 arch/arm/dts/sunxi-bananapi-m2-plus.dtsi   | 245 +
 board/sunxi/MAINTAINERS|  12 +-
 ...lus_defconfig => bananapi_m2_plus_h3_defconfig} |   0
 configs/bananapi_m2_plus_h5_defconfig  |  20 ++
 6 files changed, 285 insertions(+), 193 deletions(-)
 create mode 100644 arch/arm/dts/sun50i-h5-bananapi-m2-plus.dts
 create mode 100644 arch/arm/dts/sunxi-bananapi-m2-plus.dtsi
 rename configs/{Sinovoip_BPI_M2_Plus_defconfig => 
bananapi_m2_plus_h3_defconfig} (100%)
 create mode 100644 configs/bananapi_m2_plus_h5_defconfig
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 19/20] board: mx6sabresd: Remove the enet reset gpio handling

2019-02-28 Thread Soeren Moch

On 02.02.19 10:48, Fabio Estevam wrote:
> On Fri, Feb 1, 2019 at 2:53 PM Abel Vesa  wrote:
>> Rely on the phy-reset-gpios which is set in imx6qdl-sabresd dtsi
>> and get rid of the enet reset gpio handling from the board file.
>>
>> Signed-off-by: Abel Vesa 
> Reviewed-by: Fabio Estevam 
Fabio,

I tried to understand this patch, in order to also apply it  for the
tbs2910 board.
What I read from the fec_mxc driver, this only works with DM_ETH
enabled, but this is not enabled for mx6sabresd.

Can you point me to what I miss here?

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

Re: [U-Boot] [PATCH] ARM: kirkwood: add spi0 alias for dreamplug

On Thu, 28 Feb 2019 22:13 Leigh Brown,  wrote:

> Hi Chris,
>
> I tested together with my own patch. It fixes the issue, thanks very
> much!
>

Great. Thanks again for the bug report.

Slightly related I've got a series of changes for USB on kirkwood. Would
you be in a position to take them for a spin?


> Tested-by: Leigh Brown 
>
> Output:
>
> U-Boot 2019.04-rc2-00134-g783e66816d-dirty (Feb 28 2019 - 08:27:16
> +)
> Marvell-DreamPlug
>
> SoC:   Kirkwood 88F6281_A1
> DRAM:  512 MiB
> Loading Environment from SPI Flash... SF: Detected mx25l1606e with page
> size 256 Bytes, erase size 4 KiB, total 2 MiB
> OK
> In:serial
> Out:   serial
> Err:   serial
> Net:   egiga0, egiga1
> 88E1116 Initialized on egiga0
> 88E1116 Initialized on egiga1
> IDE:   ide_preinit failed
> Hit any key to stop autoboot:  0
> starting USB...
> USB0:   USB EHCI 1.00
> scanning bus 0 for devices... 4 USB Device(s) found
> scanning usb for storage devices... Device NOT ready
> Request Sense returned 02 3A 00
> 1 Storage Device(s) found
> 1879928 bytes read in 130 ms (13.8 MiB/s)
> 9949 bytes read in 40 ms (242.2 KiB/s)
> 2746404 bytes read in 163 ms (16.1 MiB/s)
> ## Booting kernel from Legacy Image at 0600 ...
> Image Name:   uImage-4.19.7+
> Created:  2018-12-06  14:10:50 UTC
> Image Type:   ARM Linux Kernel Image (uncompressed)
> Data Size:1879864 Bytes = 1.8 MiB
> Load Address: 8000
> Entry Point:  8000
> Verifying Checksum ... OK
> ## Loading init Ramdisk from Legacy Image at 0660 ...
> Image Name:   uInitrd-4.19.7+
> Created:  2018-12-06  14:10:50 UTC
> Image Type:   ARM Linux RAMDisk Image (uncompressed)
> Data Size:2746340 Bytes = 2.6 MiB
> Load Address: 
> Entry Point:  
> Verifying Checksum ... OK
> ## Flattened Device Tree blob at 0640
> Booting using the fdt blob at 0x640
> Loading Kernel Image ... OK
> Loading Ramdisk to 0fd61000, end 07e4 ... OK
> Loading Device Tree to 0fd5b000, end 0fd606dc ... OK
>
> Starting kernel ...
>
> On 2019-02-28 07:53, Chris Packham wrote:
> > The conversion to DM_SPI managed to break accessing the environment on
> > dreamplug. This is because the environment code relies on being to able
> > to select the SPI device based on the sequence number. Add an alias so
> > that the spi0 bus gets sequence number 0.
> >
> > Reported-by: Leigh Brown 
> > Signed-off-by: Chris Packham 
> > ---
> > Leigh,
> >
> > Could you test this on your system for me. I'm only able to compile
> > test
> > this myself.
> >
> >  arch/arm/dts/kirkwood-dreamplug.dts | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/arch/arm/dts/kirkwood-dreamplug.dts
> > b/arch/arm/dts/kirkwood-dreamplug.dts
> > index a647a65c20a0..ccd74dd7fb33 100644
> > --- a/arch/arm/dts/kirkwood-dreamplug.dts
> > +++ b/arch/arm/dts/kirkwood-dreamplug.dts
> > @@ -18,6 +18,10 @@
> >   stdout-path = 
> >   };
> >
> > + aliases {
> > + spi0 = 
> > + };
> > +
> >   ocp@f100 {
> >   pinctrl: pin-controller@1 {
> >   pmx_led_bluetooth: pmx-led-bluetooth {
>
> Regards,
>
> Leigh.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] Marvell DDR training custom ODT configuration

On Thu, 28 Feb 2019 22:45 Baruch Siach,  wrote:

> Hi Chris,
>
> Currently the value of g_odt_config is hard coded in Marvell SoC
> platform headers. Some SolidRun A388 SOMs need a custom value. These
> SOMs use both DDR chip-selects, but ODT0 alone is connected to both
> chips. For that to work we need to set g_odt_config to 0x3, that is,
> ODT0 is configured for both CS0 and CS1.
>
> How can we do that in a clean way so as to not interfere too much with
> your periodic code syncs from Marvell's DDR training source tree?
>

I've actually got a patch from marvell that might help. I'll send it to the
list when I'm at a proper keyboard.

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

Re: [U-Boot] [PATCH v3 1/1] configs: rk3288: Tinker Board SPL file must fit into 32 KiB

On Thu, Feb 28, 2019 at 07:14:08PM +0100, Simon Goldschmidt wrote:
> Am 27.02.2019 um 19:55 schrieb Tom Rini:
> >On Wed, Feb 27, 2019 at 11:15:23AM +0100, Simon Goldschmidt wrote:
> >>Tom,
> >>
> >>On Thu, Feb 14, 2019 at 10:20 AM Simon Goldschmidt
> >> wrote:
> >>>
> >>>On Thu, Feb 14, 2019 at 7:26 AM Heinrich Schuchardt  
> >>>wrote:
> 
> The SPL image for the Tinker Board has to fit into 32 KiB. This includes
> up to 2 KiB for the file header.
> 
> A new configuration variable CONFIG_SPL_WITH_DTB_SIZE_LIMIT is introduced
> to define the board specific limit.
> 
> Signed-off-by: Heinrich Schuchardt 
> >>>
> >>>Reviewed-by: Simon Goldschmidt 
> >>
> >>Is this planned for v2019.04? I know we're in rc phase, but this patch
> >>adds a new config
> >>option so shouldn't interfere with boards not using it.
> >>
> >>Plus if we have this SPL size check in v2019.04, it would probably
> >>enable more board
> >>maintainers testing/fixing the SPL size check after the release.
> >
> >I really want to get the generic version of this in, yes.
> 
> Which generic version? Was there some kind of generic follow-up patch I
> missed?

No, there wasn't I believe which is why nothing has been applied.  I
don't want to add a 3rd copy of the BOARD_SIZE_CHECK logic, I want it to
be re-usable and then used by CONFIG_SPL_MAX_SIZE / CONFIG_TPL_MAX_SIZE
because as with the switch (compared to when these checks were first
introduced, pre-SPL-DM) we now have image content that's not caught by
the linker check, so we need to use those variables in the right place
now.

-- 
Tom


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

Re: [U-Boot] [PATCH v3 1/1] configs: rk3288: Tinker Board SPL file must fit into 32 KiB


Am 27.02.2019 um 19:55 schrieb Tom Rini:

On Wed, Feb 27, 2019 at 11:15:23AM +0100, Simon Goldschmidt wrote:

Tom,

On Thu, Feb 14, 2019 at 10:20 AM Simon Goldschmidt
 wrote:


On Thu, Feb 14, 2019 at 7:26 AM Heinrich Schuchardt  wrote:


The SPL image for the Tinker Board has to fit into 32 KiB. This includes
up to 2 KiB for the file header.

A new configuration variable CONFIG_SPL_WITH_DTB_SIZE_LIMIT is introduced
to define the board specific limit.

Signed-off-by: Heinrich Schuchardt 


Reviewed-by: Simon Goldschmidt 


Is this planned for v2019.04? I know we're in rc phase, but this patch
adds a new config
option so shouldn't interfere with boards not using it.

Plus if we have this SPL size check in v2019.04, it would probably
enable more board
maintainers testing/fixing the SPL size check after the release.


I really want to get the generic version of this in, yes.


Which generic version? Was there some kind of generic follow-up patch I 
missed?


I would like to implement a real & working SPL size check for socfpga 
(including pre-reloc malloc, gd and stack) which builds on this.


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

Re: [U-Boot] i.MX8MQ: u-boot-spl-ddr.bin not found

2019-02-28 Thread Chris Spencer

On Thu, 28 Feb 2019 at 12:58, Fabio Estevam  wrote:
> Hi,
>
> I am not able to build top of tree U-Boot for imx8mq-evk:
>
> WARNING './spl/u-boot-spl-ddr.bin' not found, resulting binary is 
> not-functional
> make[1]: Nothing to be done for 'SPL'.
>   CFGCHK  u-boot.cfg
>
> It works fine when I build from u-boot-imx tree though.
>
> I have copied all the binaries to the U-Boot source as per the README.
>
> Does anyone have any ideas to fix the build for U-boot mainline?
>
> Thanks,
>
> Fabio Estevam

I'll have to double check in the office tomorrow, but I'm pretty sure
I'm using v2019.01 with the bash fix as the only relevant patch. Might
be worth doing a bisect from there.

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

Re: [U-Boot] i.MX8MQ: u-boot-spl-ddr.bin not found

2019-02-28 Thread Andrejs Cainikovs

Hi Fabio,

On 28/02/2019 13:58, Fabio Estevam wrote:
> Hi,
> 
> I am not able to build top of tree U-Boot for imx8mq-evk:
> 
> WARNING './spl/u-boot-spl-ddr.bin' not found, resulting binary is 
> not-functional
> make[1]: Nothing to be done for 'SPL'.
>CFGCHK  u-boot.cfg

Same for i.MX8QXP:
WARNING './spl/u-boot-spl.bin' not found, resulting binary is not-functional

But this still produces a working binary.

> It works fine when I build from u-boot-imx tree though.
> 
> I have copied all the binaries to the U-Boot source as per the README.
> 
> Does anyone have any ideas to fix the build for U-boot mainline?
> 
> Thanks,
> 
> Fabio Estevam
> ___
> 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] pre-reloc fdt scan for non-top-level nodes

2019-02-28 Thread viktor babrian

I can already answer my questions: all parent devices of the spi
display (5 in my case) need to have the u-boot,dm-pre-reloc flag set
in dt and bound before reloc.

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

[U-Boot] iMX8QXP MEK: no ethernet

2019-02-28 Thread Andrejs Cainikovs

Hi,

I cant get ethernet to work on iMX8QXP MEK board with latest sources 
(tried v2019.01 as well). Is this a bug or work in progress?

---

U-Boot SPL 2019.04-rc2-00134-g783e66816d (Feb 28 2019 - 13:15:40 +0100)
Normal Boot
Trying to boot from MMC2_2


U-Boot 2019.04-rc2-00134-g783e66816d (Feb 28 2019 - 13:15:40 +0100)

CPU:   NXP i.MX8QXP RevB A35 at 147228 MHz

Model: Freescale i.MX8QXP MEK
Board: iMX8QXP MEK
Build: SCFW 3301c1a9
Boot:  SD1
DRAM:  3 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... OK
In:serial@5a06
Out:   serial@5a06
Err:   serial@5a06
Net:   eth-1: ethernet@5b04
Hit any key to stop autoboot:  0
=> dhcp
No ethernet found.

---

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

[U-Boot] pre-reloc fdt scan for non-top-level nodes

2019-02-28 Thread viktor babrian

Hi,

sorry for flooding; I have already sent this email to u-boot-dm. I
just wonder if that list is alive.

as far as I understood, the pre-reloc device binding of drivers having
DM_FLAG_PRE_RELOC flag set is only performed for top-level devices -
at least that is what I experience. Is this intentional? What is the
concept there?
I am trying to use a spi slave display that is by default described as
a node under root/soc/spiX. We have the device working under Linux. I
understand these displays are not supported as is in u-boot so I
ported some Linux code and made some minor mods in the video uclass.
Still I do not have memory reserved for the frame-buffer and debugging
shows that it is because bind() is not invoked pre-reloc. And it is
not invoked because dm_extended_scan_fdt() parses top-level nodes
only.
I wonder if that pre-reloc scan is so for some purpose because a
recursive scan would seemingly be justified in my case.
(or am I just missing something?)

Any comments are welcome,
Thanks,
Viktor
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] arm: arm64 32bit address relocation

2019-02-28 Thread Ibai Erkiaga Elorza

Hi Udit

> -Original Message-
> From: Udit Kumar 
> Sent: 28 February 2019 09:07
> To: Ibai Erkiaga Elorza ; u-boot@lists.denx.de
> Cc: Tom Rini ; Albert Aribaud
> ; Meenakshi Aggarwal
> ; Stefan Roese ; Prabhakar
> Kushwaha 
> Subject: RE: [U-Boot][PATCH] arm: arm64 32bit address relocation
> 
> Hi Ibai
> 
> > -Original Message-
> > From: Ibai Erkiaga 
> > Sent: Wednesday, February 27, 2019 8:18 PM
> > To: u-boot@lists.denx.de
> > Cc: Ibai Erkiaga ; Udit Kumar
> > ; Tom Rini ; Albert Aribaud
> > ; Meenakshi Aggarwal
> > ; Stefan Roese ; Prabhakar
> > Kushwaha 
> > Subject: [U-Boot][PATCH] arm: arm64 32bit address relocation
> >
> > Current relocation code is limited to 21bit PC-relative addressing
> > which might not be enough for bigger code sizes. The following patch
> > increases the addressing to 32bit PC-relative. This feature is
> > specially interesting if U-Boot is build without optimiation (-O0) as
> > the text section is increased significativelly.
> >
> > Signed-off-by: Ibai Erkiaga 
> > ---
> >
> >  arch/arm/lib/relocate_64.S | 19 ---
> >  1 file changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S
> > index 7603f52..6e9658b 100644
> > --- a/arch/arm/lib/relocate_64.S
> > +++ b/arch/arm/lib/relocate_64.S
> > @@ -26,9 +26,10 @@ ENTRY(relocate_code)
> > /*
> >  * Copy u-boot from flash to RAM
> >  */
> > -   adr x1, __image_copy_start  /* x1 <- Run
> > &__image_copy_start */
> > -   subsx9, x0, x1  /* x8 <- Run to copy offset */
> > -   b.eqrelocate_done   /* skip relocation */
> > +   adrpx1, __image_copy_start  /* x1 <- address bits
> > [31:12] */
> > +   add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00]
> > */
> > +   subsx9, x0, x1  /* x8 <- Run to copy offset */
> 
> Should be x9 in comments
> 
The original comment was x8 so did not realize about it. Does take sense to 
change within my patch? Or should it be done in a different one?

> > +   b.eqrelocate_done   /* skip relocation */
> > /*
> >  * Don't ldr x1, __image_copy_start here, since if the code is already
> >  * running at an address other than it was linked to, that
> > instruction @@ -42,8 +43,10 @@ ENTRY(relocate_code)
> > ldr x1, _TEXT_BASE  /* x1 <- Linked
> > &__image_copy_start */
> > subsx9, x0, x1  /* x9 <- Link to copy offset */
> >
> > -   adr x1, __image_copy_start  /* x1 <- Run
> > &__image_copy_start */
> > -   adr x2, __image_copy_end/* x2 <- Run &__image_copy_end */
> > +   adrpx1, __image_copy_start  /* x1 <- address bits
> > [31:12] */
> > +   add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00]
> > */
> > +   adrpx2, __image_copy_end/* x2 <- address bits [31:12]
> > */
> > +   add x2, x2, :lo12:__image_copy_end  /* x2 <- address bits
> > [11:00] */
> >  copy_loop:
> > ldp x10, x11, [x1], #16 /* copy from source address [x1] */
> > stp x10, x11, [x0], #16 /* copy to   target address [x0] */
> > @@ -54,8 +57,10 @@ copy_loop:
> > /*
> >  * Fix .rela.dyn relocations
> >  */
> > -   adr x2, __rel_dyn_start /* x2 <- Run &__rel_dyn_start */
> > -   adr x3, __rel_dyn_end   /* x3 <- Run &__rel_dyn_end */
> > +   adrpx2, __rel_dyn_start /* x2 <- address bits [31:12]
> > */
> > +   add x2, x2, :lo12:__rel_dyn_start   /* x2 <- address bits [11:00]
> > */
> > +   adrpx3, __rel_dyn_end   /* x3 <- address bits [31:12]
> > */
> > +   add x3, x3, :lo12:__rel_dyn_end /* x3 <- address bits [11:00]
> > */
> >  fixloop:
> > ldp x0, x1, [x2], #16   /* (x0,x1) <- (SRC location, fixup) */
> > ldr x4, [x2], #8/* x4 <- addend */
> > --
> > 1.8.3.1

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

Re: [U-Boot] [PATCH 1/2] kbuild: make arch-dtbs target PHONY

2019-02-28 Thread Stephen Warren


On 2/26/19 12:20 PM, Stephen Warren wrote:

From: Stephen Warren 

Without this, the arch-dtbs target only gets evaluated when building
U-Boot the first time, not when re-building (incrementally building)
U-Boot. Thus incremental builds ignore changes to DTB files.


Commit b630d57d0ab4 "clk: Add fixed-factor clock driver", which was 
recently applied to u-boot/master, also triggers this same issue. It'd 
be nice to get this fix applied ASAP. Thanks!

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

[U-Boot] [PATCH v2] x86: acpi: Not every platform has serial console a first device

We may not do an assumption that current console device is always a first
of UCLASS_SERIAL one.

For example, on properly described Intel Edison board the console UART
is a third one.

Use current serial device as described in global data.

Fixes: a61cbad78e67 ("dm: serial: Adjust serial_getinfo() to use proper API")
Cc: Simon Glass 
Signed-off-by: Andy Shevchenko 
---
 arch/x86/lib/acpi_table.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 04058a60d7..270274f6b3 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -347,7 +347,7 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
uint serial_width;
int access_size;
int space_id;
-   int ret;
+   int ret = -ENODEV;
 
/* Fill out header fields */
acpi_fill_header(header, "SPCR");
@@ -355,8 +355,8 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
header->revision = 2;
 
/* Read the device once, here. It is reused below */
-   ret = uclass_first_device_err(UCLASS_SERIAL, );
-   if (!ret)
+   dev = gd->cur_serial_dev;
+   if (dev)
ret = serial_getinfo(dev, _info);
if (ret)
serial_info.type = SERIAL_CHIP_UNKNOWN;
-- 
2.20.1

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

Re: [U-Boot] [PATCH v1] x86: acpi: Not every platform has serial console a first device

On Thu, Feb 28, 2019 at 05:06:26PM +0200, Andy Shevchenko wrote:
> We may not do an assumption that current console device is always a first
> of UCLASS_SERIAL one.
> 
> For example, on properly described Intel Edison board the console UART
> is a third one.
> 
> Use current serial device as described in global data.
> 
> Fixes: a61cbad78e67 ("dm: serial: Adjust serial_getinfo() to use proper API")
> Cc: Simon Glass 
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/lib/acpi_table.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
> index 04058a60d7..5848b6fcd8 100644
> --- a/arch/x86/lib/acpi_table.c
> +++ b/arch/x86/lib/acpi_table.c
> @@ -347,7 +347,7 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
>   uint serial_width;
>   int access_size;
>   int space_id;
> - int ret;

> + int ret = 0;

This should be -ENODEV.

>  
>   /* Fill out header fields */
>   acpi_fill_header(header, "SPCR");
> @@ -355,8 +355,8 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
>   header->revision = 2;
>  
>   /* Read the device once, here. It is reused below */
> - ret = uclass_first_device_err(UCLASS_SERIAL, );
> - if (!ret)
> + dev = gd->cur_serial_dev;
> + if (dev)
>   ret = serial_getinfo(dev, _info);
>   if (ret)
>   serial_info.type = SERIAL_CHIP_UNKNOWN;
> -- 
> 2.20.1
> 

-- 
With Best Regards,
Andy Shevchenko


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

[U-Boot] [PATCH v1] x86: acpi: Not every platform has serial console a first device

We may not do an assumption that current console device is always a first
of UCLASS_SERIAL one.

For example, on properly described Intel Edison board the console UART
is a third one.

Use current serial device as described in global data.

Fixes: a61cbad78e67 ("dm: serial: Adjust serial_getinfo() to use proper API")
Cc: Simon Glass 
Signed-off-by: Andy Shevchenko 
---
 arch/x86/lib/acpi_table.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 04058a60d7..5848b6fcd8 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -347,7 +347,7 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
uint serial_width;
int access_size;
int space_id;
-   int ret;
+   int ret = 0;
 
/* Fill out header fields */
acpi_fill_header(header, "SPCR");
@@ -355,8 +355,8 @@ static void acpi_create_spcr(struct acpi_spcr *spcr)
header->revision = 2;
 
/* Read the device once, here. It is reused below */
-   ret = uclass_first_device_err(UCLASS_SERIAL, );
-   if (!ret)
+   dev = gd->cur_serial_dev;
+   if (dev)
ret = serial_getinfo(dev, _info);
if (ret)
serial_info.type = SERIAL_CHIP_UNKNOWN;
-- 
2.20.1

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

Re: [U-Boot] [PATCH v2 2/2] x86: edison: Add the rest of UARTs present on board

On Thu, Feb 28, 2019 at 01:29:57PM +0200, Andy Shevchenko wrote:
> On Thu, Feb 28, 2019 at 04:21:48PM +0800, Bin Meng wrote:
> > On Thu, Feb 28, 2019 at 4:12 PM Andy Shevchenko
> >  wrote:
> > >
> > > Intel Edison has three UART ports, i.e.
> > >  port 0 - Bluetooth
> > >  port 1 - auxiliary, available for general purpose use
> > >  port 2 - debugging, usually console output is here
> > >
> > > Enable all of them for future use.
> > >
> > > Signed-off-by: Andy Shevchenko 
> > > ---
> > >  arch/x86/dts/edison.dts | 18 ++
> > >  1 file changed, 18 insertions(+)
> > >
> > 
> > Reviewed-by: Bin Meng 
> 
> Thanks, but please defer this series. It made a regression.

I found the root cause.

It's a regression in the

commit a61cbad78e67963944e7d719f0aee27b8aef6c02
Author: Simon Glass 
Date:   Fri Dec 28 14:23:10 2018 -0700

dm: serial: Adjust serial_getinfo() to use proper API

I will send a fix soon.

This series is okay as long as future fix will be applied.

Should I make a fix as patch 1 in the series and resend as v3?

-- 
With Best Regards,
Andy Shevchenko


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

Re: [U-Boot] i.MX8MQ: u-boot-spl-ddr.bin not found

Hi Andrejs,

On Thu, Feb 28, 2019 at 10:21 AM Andrejs Cainikovs
 wrote:

> Same for i.MX8QXP:
> WARNING './spl/u-boot-spl.bin' not found, resulting binary is not-functional
>
> But this still produces a working binary.

In my case the flash.bin binary is not generated.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

2019-02-28 Thread Heiko Stübner

Hi Philipp,

Am Donnerstag, 28. Februar 2019, 13:46:44 CET schrieb Heiko Stübner:
> Am Donnerstag, 28. Februar 2019, 13:36:52 CET schrieb Philipp Tomsich:
> > > On 28.02.2019, at 11:50, Heiko Stübner  wrote:
> > > 
> > > Hi David,
> > > 
> > > Am Montag, 18. Februar 2019, 02:05:12 CET schrieb David Wu:
> > >> Hi Heinrich and Michael,
> > >> 
> > >> Another thing i see is that I missed a patch, for the 3288 gpio0, its
> > >> iomux is special, there is no high 16-bit write-enabled bit. For Tinker
> > >> board, it uses I2C0, the current driver will overwrite the I2C0 iomux,
> > >> while request the GPIO0A4. It requires a patch:
> > >> 
> > >> http://patchwork.ozlabs.org/patch/1040541/
> > >> >
> > > 
> > > I've also just stumbled onto the issue of recent uboots not booting
> > > on rk3288. While your patch seems to have reached patchwork, somehow
> > > the u-boot list seems to have lost it - as it's neither in public
> > > archives nor in my inbox it seems.
> > 
> > Please note that I had requested changes to that patch during review.
> > I’ll ping David again on when he expect to have those changes implemented
> > and ready.
> 
> yeah, I saw that in patchwork, but couldn't comment due to the patch
> seemingly not having reach the actual u-boot list strangely.
> 
> That patch doesn't seem to help me right now anyway, as I somehow seem
> be stuck on mem_malloc_init() hanging when called from initr_malloc()
> (board_r.c) and am not yet sure what is going on there
> (on u-boot-master from last friday).

This problem seems to be memory-related somehow?
My 2GB rk3288-evb comes up fine to the uboot prompt, while
my 1GB rk3288-phycore hangs in said mem_malloc_init().


rk3288-evb (2GB):
[...]
Relocation Offset is: 7ed88000
Relocating to 7ed88000, new gd at 7cd7fed8, sp at 7cd76230
[...]
initr_malloc: before mem_malloc_init
using memory 0x7cd8-0x7ed88000 for malloc()
initr_malloc: after mem_malloc_init
[...]


rk3288-phycore (1GB):
[...]
Relocation Offset is: 3ff7b000
Relocating to 3ff7b000, new gd at 3df72ee0, sp at 3df68f60
[...]
initr_malloc: before mem_malloc_init
using memory 0x3df73000-0x3ff7b000 for malloc()
[HANG]


Do you have some tips what I need to poke for this issue?


Heiko

> > > Applying the patch does not make my board (phycore-rk3288 in this case)
> > > get farther though - I'll investigate more.
> > > 
> > > 
> > > But it looks like we should be having the same issue in the kernel, just
> > > never triggered it, as the gpio0 are of more esotheric uses normally.
> > > 
> > > Anyway, I'm wondering if defining IOMUX_WRITABLE_32BIT alone
> > > wouldn't be enough and use that for iomux, pull and drv, similar to
> > > what we do for the pull/drv register source already.
> > > 
> > > That way we could refrain from introducing DRV_TYPE_WRITABLE_32BIT
> > > and PULL_TYPE_WRITABLE_32BIT .
> > > 
> > > 
> > > Heiko
> > > 
> > >> 在 2019/2/17 下午8:41, Heinrich Schuchardt 写道:
> > >>> On 2/17/19 1:18 PM, Michael Nazzareno Trimarchi wrote:
> >  Hi
> >  
> >  [U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space
> >  after
> >  relocation
> >  
> >  Can you check it if you have the same problem?
> > >>> 
> > >>> Applying all the changes causes SPL not to start.
> > >>> 
> > >>> CONFIG_SYS_MALLOC_F_LEN=0x4000
> > >>> does not solve the problem.
> > >>> 
> > >>> Best regards
> > >>> 
> > >>> Heinrich
> > >>> 
> >  Michael
> >  
> >  
> >  On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt
> >   >  
> >   wrote:
> >  On 2/17/19 9:19 AM, David Wu wrote:
> > > Hi Henrich,
> > > 
> > > 在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
> > >> On 2/13/19 11:56 AM, Philipp Tomsich wrote:
> >  
> > >> 
> > >> Hello David, hello Philipp,
> > >> 
> > >> what are your ideas to reduce the SPL size to under 0x7800 again?
> > >> Or will you move all rk3288 boards to TPL like
> > >> TARGET_VYASA_RK3288?
> > > 
> > > CONFIG_SPL_I2C_SUPPORT is necessary for Tink spl? Remove this can
> > > make
> > > spl boot. As the Tinker does not use the i2c to read the MAC
> > > address
> > > from eeprom at the SPL stage, which is at uboot.
> > > 
> >  Hello David,
> >  
> >  the SPL image size now just fits:
> >  Image Type:   Rockchip RK32 (SD/MMC) boot image
> >  Data Size:30720 bytes
> >  
> >  SPL is successful. But MMC is failing in main U-Boot:
> >  
> >  ```
> >  U-Boot SPL 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39
> >  +0100)
> >  Returning to boot ROM...
> >  
> >  
> >  U-Boot 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39
> >  +0100)
> >  
> >  Model: Tinker-RK3288
> >  DRAM:  2 GiB
> >  MMC:   dwmmc@ff0c: 1
> >  Loading

[U-Boot] i.MX8MQ: u-boot-spl-ddr.bin not found

Hi,

I am not able to build top of tree U-Boot for imx8mq-evk:

WARNING './spl/u-boot-spl-ddr.bin' not found, resulting binary is not-functional
make[1]: Nothing to be done for 'SPL'.
  CFGCHK  u-boot.cfg

It works fine when I build from u-boot-imx tree though.

I have copied all the binaries to the U-Boot source as per the README.

Does anyone have any ideas to fix the build for U-boot mainline?

Thanks,

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

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

2019-02-28 Thread Heiko Stübner

Am Donnerstag, 28. Februar 2019, 13:36:52 CET schrieb Philipp Tomsich:
> > On 28.02.2019, at 11:50, Heiko Stübner  wrote:
> > 
> > Hi David,
> > 
> > Am Montag, 18. Februar 2019, 02:05:12 CET schrieb David Wu:
> >> Hi Heinrich and Michael,
> >> 
> >> Another thing i see is that I missed a patch, for the 3288 gpio0, its
> >> iomux is special, there is no high 16-bit write-enabled bit. For Tinker
> >> board, it uses I2C0, the current driver will overwrite the I2C0 iomux,
> >> while request the GPIO0A4. It requires a patch:
> >> 
> >> http://patchwork.ozlabs.org/patch/1040541/
> >> > 
> > I've also just stumbled onto the issue of recent uboots not booting
> > on rk3288. While your patch seems to have reached patchwork, somehow
> > the u-boot list seems to have lost it - as it's neither in public
> > archives nor in my inbox it seems.
> 
> Please note that I had requested changes to that patch during review.
> I’ll ping David again on when he expect to have those changes implemented
> and ready.

yeah, I saw that in patchwork, but couldn't comment due to the patch
seemingly not having reach the actual u-boot list strangely.

That patch doesn't seem to help me right now anyway, as I somehow seem
be stuck on mem_malloc_init() hanging when called from initr_malloc() 
(board_r.c) and am not yet sure what is going on there
(on u-boot-master from last friday).




> > Applying the patch does not make my board (phycore-rk3288 in this case)
> > get farther though - I'll investigate more.
> > 
> > 
> > But it looks like we should be having the same issue in the kernel, just
> > never triggered it, as the gpio0 are of more esotheric uses normally.
> > 
> > Anyway, I'm wondering if defining IOMUX_WRITABLE_32BIT alone
> > wouldn't be enough and use that for iomux, pull and drv, similar to
> > what we do for the pull/drv register source already.
> > 
> > That way we could refrain from introducing DRV_TYPE_WRITABLE_32BIT
> > and PULL_TYPE_WRITABLE_32BIT .
> > 
> > 
> > Heiko
> > 
> >> 在 2019/2/17 下午8:41, Heinrich Schuchardt 写道:
> >>> On 2/17/19 1:18 PM, Michael Nazzareno Trimarchi wrote:
>  Hi
>  
>  [U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space after
>  relocation
>  
>  Can you check it if you have the same problem?
> >>> 
> >>> Applying all the changes causes SPL not to start.
> >>> 
> >>> CONFIG_SYS_MALLOC_F_LEN=0x4000
> >>> does not solve the problem.
> >>> 
> >>> Best regards
> >>> 
> >>> Heinrich
> >>> 
>  Michael
>  
>  
>  On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt   
>   wrote:
>  On 2/17/19 9:19 AM, David Wu wrote:
> > Hi Henrich,
> > 
> > 在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
> >> On 2/13/19 11:56 AM, Philipp Tomsich wrote:
>  
> >> 
> >> Hello David, hello Philipp,
> >> 
> >> what are your ideas to reduce the SPL size to under 0x7800 again?
> >> Or will you move all rk3288 boards to TPL like
> >> TARGET_VYASA_RK3288?
> > 
> > CONFIG_SPL_I2C_SUPPORT is necessary for Tink spl? Remove this can
> > make
> > spl boot. As the Tinker does not use the i2c to read the MAC
> > address
> > from eeprom at the SPL stage, which is at uboot.
> > 
>  Hello David,
>  
>  the SPL image size now just fits:
>  Image Type:   Rockchip RK32 (SD/MMC) boot image
>  Data Size:30720 bytes
>  
>  SPL is successful. But MMC is failing in main U-Boot:
>  
>  ```
>  U-Boot SPL 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39
>  +0100)
>  Returning to boot ROM...
>  
>  
>  U-Boot 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 +0100)
>  
>  Model: Tinker-RK3288
>  DRAM:  2 GiB
>  MMC:   dwmmc@ff0c: 1
>  Loading Environment from MMC...
>  ```
>  
>  No further output here.
>  
>  With some debug output enabled:
>  
>  ```
>  U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 -
>  13:05:10
>  +0100)
>  Returning to boot ROM...
>  mmc_bind: alias ret=0, devnum=1
>  env_init: Environment MMC init done (ret=-2)
>  
>  
>  U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10
>  +0100)
>  
>  Model: Tinker-RK3288
>  DRAM:  2 GiB
>  mmc_bind: alias ret=0, devnum=1
>  MMC:   dwmmc@ff0c: 1
>  Loading Environment from MMC...
>  ```
>  
>  Any suggestion how to proceed?
>  
>  CC: Jaehoon.
>  
>  Best regards
>  
>  Heinrich
> >> 
> >> ___
> >> U-Boot mailing list
> >> U-Boot@lists.denx.de 
> >>

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

2019-02-28 Thread Philipp Tomsich



> On 28.02.2019, at 11:50, Heiko Stübner  wrote:
> 
> Hi David,
> 
> Am Montag, 18. Februar 2019, 02:05:12 CET schrieb David Wu:
>> Hi Heinrich and Michael,
>> 
>> Another thing i see is that I missed a patch, for the 3288 gpio0, its
>> iomux is special, there is no high 16-bit write-enabled bit. For Tinker
>> board, it uses I2C0, the current driver will overwrite the I2C0 iomux,
>> while request the GPIO0A4. It requires a patch:
>> 
>> http://patchwork.ozlabs.org/patch/1040541/ 
>> 
> 
> I've also just stumbled onto the issue of recent uboots not booting
> on rk3288. While your patch seems to have reached patchwork, somehow
> the u-boot list seems to have lost it - as it's neither in public
> archives nor in my inbox it seems.

Please note that I had requested changes to that patch during review.
I’ll ping David again on when he expect to have those changes implemented
and ready.

> Applying the patch does not make my board (phycore-rk3288 in this case)
> get farther though - I'll investigate more.
> 
> 
> But it looks like we should be having the same issue in the kernel, just
> never triggered it, as the gpio0 are of more esotheric uses normally.
> 
> Anyway, I'm wondering if defining IOMUX_WRITABLE_32BIT alone
> wouldn't be enough and use that for iomux, pull and drv, similar to
> what we do for the pull/drv register source already.
> 
> That way we could refrain from introducing DRV_TYPE_WRITABLE_32BIT
> and PULL_TYPE_WRITABLE_32BIT .
> 
> 
> Heiko
> 
> 
>> 
>> 在 2019/2/17 下午8:41, Heinrich Schuchardt 写道:
>>> On 2/17/19 1:18 PM, Michael Nazzareno Trimarchi wrote:
 Hi
 
 [U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space after
 relocation
 
 Can you check it if you have the same problem?
>>> 
>>> Applying all the changes causes SPL not to start.
>>> 
>>> CONFIG_SYS_MALLOC_F_LEN=0x4000
>>> does not solve the problem.
>>> 
>>> Best regards
>>> 
>>> Heinrich
>>> 
 Michael
 
 
 On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt >>> 
  wrote:
 On 2/17/19 9:19 AM, David Wu wrote:
> Hi Henrich,
> 
> 在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
>> On 2/13/19 11:56 AM, Philipp Tomsich wrote:
 
 
>> Hello David, hello Philipp,
>> 
>> what are your ideas to reduce the SPL size to under 0x7800 again?
>> Or will you move all rk3288 boards to TPL like
>> TARGET_VYASA_RK3288?
> 
> CONFIG_SPL_I2C_SUPPORT is necessary for Tink spl? Remove this can
> make
> spl boot. As the Tinker does not use the i2c to read the MAC
> address
> from eeprom at the SPL stage, which is at uboot.
 
 Hello David,
 
 the SPL image size now just fits:
 Image Type:   Rockchip RK32 (SD/MMC) boot image
 Data Size:30720 bytes
 
 SPL is successful. But MMC is failing in main U-Boot:
 
 ```
 U-Boot SPL 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39
 +0100)
 Returning to boot ROM...
 
 
 U-Boot 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 +0100)
 
 Model: Tinker-RK3288
 DRAM:  2 GiB
 MMC:   dwmmc@ff0c: 1
 Loading Environment from MMC...
 ```
 
 No further output here.
 
 With some debug output enabled:
 
 ```
 U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 -
 13:05:10
 +0100)
 Returning to boot ROM...
 mmc_bind: alias ret=0, devnum=1
 env_init: Environment MMC init done (ret=-2)
 
 
 U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10
 +0100)
 
 Model: Tinker-RK3288
 DRAM:  2 GiB
 mmc_bind: alias ret=0, devnum=1
 MMC:   dwmmc@ff0c: 1
 Loading Environment from MMC...
 ```
 
 Any suggestion how to proceed?
 
 CC: Jaehoon.
 
 Best regards
 
 Heinrich
>> 
>> ___
>> 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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/2] imx8mq_evk/README: fix DDR training firmware path

2019-02-28 Thread Baruch Siach

Remove a redundant directory level.

Reported-by: Ofer Heifetz 
Tested-by: Fabio Estevam 
Signed-off-by: Baruch Siach 
---
 board/freescale/imx8mq_evk/README | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/freescale/imx8mq_evk/README 
b/board/freescale/imx8mq_evk/README
index 004fa3fb3cf6..2529f7da3d98 100644
--- a/board/freescale/imx8mq_evk/README
+++ b/board/freescale/imx8mq_evk/README
@@ -20,7 +20,7 @@ $ wget 
https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.9.bin
 $ chmod +x firmware-imx-7.9.bin
 $ ./firmware-imx-7.9.bin
 $ cp firmware-imx-7.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin $(srctree)
-$ cp firmware-imx-7.9/firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin 
$(srctee)
+$ cp firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin $(srctee)
 
 Build U-Boot
 
-- 
2.20.1

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

[U-Boot] [PATCH v2 1/2] imx8mq_evk/README: add missing firmware extract step

2019-02-28 Thread Baruch Siach

Tested-by: Fabio Estevam 
Signed-off-by: Baruch Siach 
---
 board/freescale/imx8mq_evk/README | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/freescale/imx8mq_evk/README 
b/board/freescale/imx8mq_evk/README
index 1da6eaf24277..004fa3fb3cf6 100644
--- a/board/freescale/imx8mq_evk/README
+++ b/board/freescale/imx8mq_evk/README
@@ -18,6 +18,7 @@ Get the ddr and hdmi firmware
 Note: srctree is U-Boot source directory
 $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-7.9.bin
 $ chmod +x firmware-imx-7.9.bin
+$ ./firmware-imx-7.9.bin
 $ cp firmware-imx-7.9/firmware/hdmi/cadence/signed_hdmi_imx8m.bin $(srctree)
 $ cp firmware-imx-7.9/firmware-imx-7.9/firmware/ddr/synopsys/lpddr4*.bin 
$(srctee)
 
-- 
2.20.1

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

[U-Boot] [PATCH 1/2] imx8mq_evk: Move CONFIG_ENV_IS_IN_MMC to Kconfig

Currently the command "saveenv" is not available.

The CONFIG_ENV_IS_IN_MMC symbol has been converted to Kconfig,
so fix the problem by moving it to the defconfig.

Signed-off-by: Fabio Estevam 
---
 configs/imx8mq_evk_defconfig | 1 +
 include/configs/imx8mq_evk.h | 1 -
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/configs/imx8mq_evk_defconfig b/configs/imx8mq_evk_defconfig
index 53025e45bc..889d8f1484 100644
--- a/configs/imx8mq_evk_defconfig
+++ b/configs/imx8mq_evk_defconfig
@@ -22,6 +22,7 @@ CONFIG_CMD_EXT4_WRITE=y
 CONFIG_CMD_FAT=y
 CONFIG_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="fsl-imx8mq-evk"
+CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SAVED_DRAM_TIMING_BASE=0x4000
 CONFIG_DM_GPIO=y
 CONFIG_DM_I2C=y
diff --git a/include/configs/imx8mq_evk.h b/include/configs/imx8mq_evk.h
index f0430224cb..a9e38a70e6 100644
--- a/include/configs/imx8mq_evk.h
+++ b/include/configs/imx8mq_evk.h
@@ -187,7 +187,6 @@
 #define CONFIG_ENV_OVERWRITE
 #define CONFIG_ENV_OFFSET   (64 * SZ_64K)
 #define CONFIG_ENV_SIZE0x1000
-#define CONFIG_ENV_IS_IN_MMC
 #define CONFIG_SYS_MMC_ENV_DEV 1   /* USDHC2 */
 #define CONFIG_MMCROOT "/dev/mmcblk1p2"  /* USDHC2 */
 
-- 
2.17.1

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

[U-Boot] [PATCH 2/2] imx8mq_evk: Add myself as a co-maintainer

I would like to help maintaining this board.

Signed-off-by: Fabio Estevam 
---
 board/freescale/imx8mq_evk/MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/board/freescale/imx8mq_evk/MAINTAINERS 
b/board/freescale/imx8mq_evk/MAINTAINERS
index a2e320cb10..a00bb4ef78 100644
--- a/board/freescale/imx8mq_evk/MAINTAINERS
+++ b/board/freescale/imx8mq_evk/MAINTAINERS
@@ -1,5 +1,6 @@
 i.MX8MQ EVK BOARD
 M: Peng Fan 
+M: Fabio Estevam 
 S: Maintained
 F: board/freescale/imx8mq_evk/
 F: include/configs/imx8mq_evk.h
-- 
2.17.1

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

Re: [U-Boot] [PATCH v2 2/2] x86: edison: Add the rest of UARTs present on board

On Thu, Feb 28, 2019 at 04:21:48PM +0800, Bin Meng wrote:
> On Thu, Feb 28, 2019 at 4:12 PM Andy Shevchenko
>  wrote:
> >
> > Intel Edison has three UART ports, i.e.
> >  port 0 - Bluetooth
> >  port 1 - auxiliary, available for general purpose use
> >  port 2 - debugging, usually console output is here
> >
> > Enable all of them for future use.
> >
> > Signed-off-by: Andy Shevchenko 
> > ---
> >  arch/x86/dts/edison.dts | 18 ++
> >  1 file changed, 18 insertions(+)
> >
> 
> Reviewed-by: Bin Meng 

Thanks, but please defer this series. It made a regression.

-- 
With Best Regards,
Andy Shevchenko


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

Re: [U-Boot] [BUG] booting on the Tinker Board (tinker-rk3288_defconfig) is broken

2019-02-28 Thread Heiko Stübner

Hi David,

Am Montag, 18. Februar 2019, 02:05:12 CET schrieb David Wu:
> Hi Heinrich and Michael,
> 
> Another thing i see is that I missed a patch, for the 3288 gpio0, its
> iomux is special, there is no high 16-bit write-enabled bit. For Tinker
> board, it uses I2C0, the current driver will overwrite the I2C0 iomux,
> while request the GPIO0A4. It requires a patch:
> 
> http://patchwork.ozlabs.org/patch/1040541/

I've also just stumbled onto the issue of recent uboots not booting
on rk3288. While your patch seems to have reached patchwork, somehow
the u-boot list seems to have lost it - as it's neither in public
archives nor in my inbox it seems.

Applying the patch does not make my board (phycore-rk3288 in this case)
get farther though - I'll investigate more.


But it looks like we should be having the same issue in the kernel, just
never triggered it, as the gpio0 are of more esotheric uses normally.

Anyway, I'm wondering if defining IOMUX_WRITABLE_32BIT alone
wouldn't be enough and use that for iomux, pull and drv, similar to
what we do for the pull/drv register source already.

That way we could refrain from introducing DRV_TYPE_WRITABLE_32BIT
and PULL_TYPE_WRITABLE_32BIT .


Heiko


> 
> 在 2019/2/17 下午8:41, Heinrich Schuchardt 写道:
> > On 2/17/19 1:18 PM, Michael Nazzareno Trimarchi wrote:
> >> Hi
> >> 
> >> [U-Boot] [PATCH 3/5] rockchip: rk3288-vyasa: increase heap space after
> >> relocation
> >> 
> >> Can you check it if you have the same problem?
> > 
> > Applying all the changes causes SPL not to start.
> > 
> > CONFIG_SYS_MALLOC_F_LEN=0x4000
> > does not solve the problem.
> > 
> > Best regards
> > 
> > Heinrich
> > 
> >> Michael
> >> 
> >> 
> >> On Sun., 17 Feb. 2019, 1:11 pm Heinrich Schuchardt  >> 
> >>  wrote:
> >>  On 2/17/19 9:19 AM, David Wu wrote:
> >>  > Hi Henrich,
> >>  > 
> >>  > 在 2019/2/16 下午5:53, Heinrich Schuchardt 写道:
> >>  >> On 2/13/19 11:56 AM, Philipp Tomsich wrote:
> >>  
> >>  
> >>  >> Hello David, hello Philipp,
> >>  >> 
> >>  >> what are your ideas to reduce the SPL size to under 0x7800 again?
> >>  >> Or will you move all rk3288 boards to TPL like
> >>  >> TARGET_VYASA_RK3288?
> >>  > 
> >>  > CONFIG_SPL_I2C_SUPPORT is necessary for Tink spl? Remove this can
> >>  > make
> >>  > spl boot. As the Tinker does not use the i2c to read the MAC
> >>  > address
> >>  > from eeprom at the SPL stage, which is at uboot.
> >>  
> >>  Hello David,
> >>  
> >>  the SPL image size now just fits:
> >>  Image Type:   Rockchip RK32 (SD/MMC) boot image
> >>  Data Size:30720 bytes
> >>  
> >>  SPL is successful. But MMC is failing in main U-Boot:
> >>  
> >>  ```
> >>  U-Boot SPL 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39
> >>  +0100)
> >>  Returning to boot ROM...
> >>  
> >>  
> >>  U-Boot 2019.04-rc1-00239-gb89074f650 (Feb 17 2019 - 12:41:39 +0100)
> >>  
> >>  Model: Tinker-RK3288
> >>  DRAM:  2 GiB
> >>  MMC:   dwmmc@ff0c: 1
> >>  Loading Environment from MMC...
> >>  ```
> >>  
> >>  No further output here.
> >>  
> >>  With some debug output enabled:
> >>  
> >>  ```
> >>  U-Boot SPL 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 -
> >>  13:05:10
> >>  +0100)
> >>  Returning to boot ROM...
> >>  mmc_bind: alias ret=0, devnum=1
> >>  env_init: Environment MMC init done (ret=-2)
> >>  
> >>  
> >>  U-Boot 2019.04-rc1-00239-gb89074f650-dirty (Feb 17 2019 - 13:05:10
> >>  +0100)
> >>  
> >>  Model: Tinker-RK3288
> >>  DRAM:  2 GiB
> >>  mmc_bind: alias ret=0, devnum=1
> >>  MMC:   dwmmc@ff0c: 1
> >>  Loading Environment from MMC...
> >>  ```
> >>  
> >>  Any suggestion how to proceed?
> >>  
> >>  CC: Jaehoon.
> >>  
> >>  Best regards
> >>  
> >>  Heinrich
> 
> ___
> 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 2/2] imx8mq_evk/README: add missing firmware extract step

Hi Baruch,

On Thu, Feb 28, 2019 at 1:26 AM Baruch Siach  wrote:

> Should I post v2 with that change?

That would be nice, if possible.

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

Re: [U-Boot] [PATCH v3 0/7] android: implement A/B boot process

2019-02-28 Thread Sam Protsenko

For the whole series:

Reviewed-by: Sam Protsenko 

On Mon, Feb 18, 2019 at 6:22 PM Igor Opaniuk  wrote:
>
> This patch series adds support for Android A/B boot process [1].
> Main steps of A/B boot process are:
>   - A/B metadata integrity check
>   - looking for the current slot (where the system should be
> booting from)
>   - getting the name of the current boot partition (boot_a or boot_b)
> and loading the corresponding Android boot image
>   - getting the name of the current system partition (system_a or
> system_b) and passing of its full name via kernel command line
> (like 'root=/dev/mmcblk1p11')
>   - passing current slot via kernel command line (like
> 'androidboot.slot_suffix=_a') and via A/B metadata (e.g. via
> misc partition)
>   - A/B metadata processing: setting the boot success flag for
> current slot, handling the retry counter, etc
>
> A/B metadata is organized according to Android reference [2] and stored
> on 'misc' partition. On the first A/B boot process, when 'misc'
> partition doesn't contain required data, default A/B metadata will be
> created and stored in 'misc' partition. In the end of the Android boot,
> 'update_verifier' and 'update_engine' services are processing the
> A/B metadata through the Boot Control HAL. To confirm the boot was
> successful using current slot, "boot success" flag must be set on
> Android side.
>
> To enable Android A/B support in U-Boot:
>   1. Set the following config options:
>
>  CONFIG_ANDROID_AB=y
>  CONFIG_CMD_AB_SELECT=y
>
>   2. Change the disk layout so that it has sloted boot partitions.
>  E.g. instead of 'boot' and 'system' partitions there should be
>  'boot_a', 'boot_b', 'system_a' and 'system_b' partitions.
>
> To be able to actually test this patch series, the A/B features must
> be implemented and enabled in Android as well (see [1] for details).
>
> Documentation and corresponding test for A/B boot is present here. The
> last patch in this series integrates A/B boot support on AM57xx based
> boards (though it's not enabled by default). Future users of A/B boot
> feature can use it as a reference.
>
> This series is a part of previous submission [3] by Alex Deymo. It
> contains only A/B feature that was stripped out from there with some
> modifications for using with "bootm" command preferred in upstream.
>
> Changes in v3:
>   * Minor fixes in the ab metadata handling (added additional sanity checks).
>   * As Ruslan Trofymenko left Linaro and won't address comments anymore,
> continue (added my S-b tag) upstreaming patches on my own.
>
> Changes in v2:
>   * 'android_ab_select' command is renamed to 'ab_select' command and
>  moved to separate 'Android support commands' menu
>   * For am57xx boards slotted sections (e.g. system_a and system_b) are
> added to the default sections if CONFIG_CMD_AB_SELECT flag is
> defined
>   * Returned function error codes are clarified (errno using)
>   * Some types constants and files are renamed
>   * Assertion condition is clarified in test case
>   * 'debug' calls are changed to 'log_debug'
>   * The Guide is clarified by the results of changes
>
> [1] https://source.android.com/devices/tech/ota/ab/ab_implement
> [2] 
> bootable/recovery/bootloader_message/include/bootloader_message/bootloader_message.h
> [3] https://lists.denx.de/pipermail/u-boot/2017-April/285841.html
>
> Ruslan Trofymenko (7):
>   cmd: part: Add 'number' sub-command
>   disk: part: Extend API to get partition info
>   common: Implement A/B metadata
>   cmd: Add 'ab_select' command
>   test/py: Add base test case for A/B updates
>   doc: android: Add simple guide for A/B updates
>   env: am57xx: Implement A/B boot process
>
>  cmd/Kconfig   |  15 +++
>  cmd/Makefile  |   1 +
>  cmd/ab_select.c   |  52 
>  cmd/part.c|  16 ++-
>  common/Kconfig|  10 ++
>  common/Makefile   |   1 +
>  common/android_ab.c   | 290 
> ++
>  configs/sandbox_defconfig |   2 +
>  disk/part.c   |  68 ++
>  doc/README.android-ab |  67 ++
>  include/android_ab.h  |  34 +
>  include/android_bl_msg.h  | 169 
>  include/environment/ti/boot.h |  58 -
>  include/part.h|  21 +++
>  test/py/tests/test_ab.py  |  74 +++
>  15 files changed, 871 insertions(+), 7 deletions(-)
>  create mode 100644 cmd/ab_select.c
>  create mode 100644 common/android_ab.c
>  create mode 100644 doc/README.android-ab
>  create mode 100644 include/android_ab.h
>  create mode 100644 include/android_bl_msg.h
>  create mode 100644 test/py/tests/test_ab.py
>
> --
> 2.7.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] Marvell DDR training custom ODT configuration

2019-02-28 Thread Baruch Siach

Hi Chris,

Currently the value of g_odt_config is hard coded in Marvell SoC
platform headers. Some SolidRun A388 SOMs need a custom value. These
SOMs use both DDR chip-selects, but ODT0 alone is connected to both
chips. For that to work we need to set g_odt_config to 0x3, that is,
ODT0 is configured for both CS0 and CS1.

How can we do that in a clean way so as to not interfere too much with
your periodic code syncs from Marvell's DDR training source tree?

Thanks,
baruch

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

Re: [U-Boot] [PATCH] ARM: kirkwood: add spi0 alias for dreamplug

2019-02-28 Thread Leigh Brown


Hi Chris,

I tested together with my own patch. It fixes the issue, thanks very 
much!


Tested-by: Leigh Brown 

Output:

U-Boot 2019.04-rc2-00134-g783e66816d-dirty (Feb 28 2019 - 08:27:16 
+)

Marvell-DreamPlug

SoC:   Kirkwood 88F6281_A1
DRAM:  512 MiB
Loading Environment from SPI Flash... SF: Detected mx25l1606e with page 
size 256 Bytes, erase size 4 KiB, total 2 MiB

OK
In:serial
Out:   serial
Err:   serial
Net:   egiga0, egiga1
88E1116 Initialized on egiga0
88E1116 Initialized on egiga1
IDE:   ide_preinit failed
Hit any key to stop autoboot:  0
starting USB...
USB0:   USB EHCI 1.00
scanning bus 0 for devices... 4 USB Device(s) found
   scanning usb for storage devices... Device NOT ready
   Request Sense returned 02 3A 00
1 Storage Device(s) found
1879928 bytes read in 130 ms (13.8 MiB/s)
9949 bytes read in 40 ms (242.2 KiB/s)
2746404 bytes read in 163 ms (16.1 MiB/s)
## Booting kernel from Legacy Image at 0600 ...
   Image Name:   uImage-4.19.7+
   Created:  2018-12-06  14:10:50 UTC
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:1879864 Bytes = 1.8 MiB
   Load Address: 8000
   Entry Point:  8000
   Verifying Checksum ... OK
## Loading init Ramdisk from Legacy Image at 0660 ...
   Image Name:   uInitrd-4.19.7+
   Created:  2018-12-06  14:10:50 UTC
   Image Type:   ARM Linux RAMDisk Image (uncompressed)
   Data Size:2746340 Bytes = 2.6 MiB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
## Flattened Device Tree blob at 0640
   Booting using the fdt blob at 0x640
   Loading Kernel Image ... OK
   Loading Ramdisk to 0fd61000, end 07e4 ... OK
   Loading Device Tree to 0fd5b000, end 0fd606dc ... OK

Starting kernel ...

On 2019-02-28 07:53, Chris Packham wrote:

The conversion to DM_SPI managed to break accessing the environment on
dreamplug. This is because the environment code relies on being to able
to select the SPI device based on the sequence number. Add an alias so
that the spi0 bus gets sequence number 0.

Reported-by: Leigh Brown 
Signed-off-by: Chris Packham 
---
Leigh,

Could you test this on your system for me. I'm only able to compile 
test

this myself.

 arch/arm/dts/kirkwood-dreamplug.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm/dts/kirkwood-dreamplug.dts
b/arch/arm/dts/kirkwood-dreamplug.dts
index a647a65c20a0..ccd74dd7fb33 100644
--- a/arch/arm/dts/kirkwood-dreamplug.dts
+++ b/arch/arm/dts/kirkwood-dreamplug.dts
@@ -18,6 +18,10 @@
stdout-path = 
};

+   aliases {
+   spi0 = 
+   };
+
ocp@f100 {
pinctrl: pin-controller@1 {
pmx_led_bluetooth: pmx-led-bluetooth {


Regards,

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

Re: [U-Boot] [PATCH] arm: arm64 32bit address relocation

2019-02-28 Thread Udit Kumar

Hi Ibai

> -Original Message-
> From: Ibai Erkiaga 
> Sent: Wednesday, February 27, 2019 8:18 PM
> To: u-boot@lists.denx.de
> Cc: Ibai Erkiaga ; Udit Kumar
> ; Tom Rini ; Albert Aribaud
> ; Meenakshi Aggarwal
> ; Stefan Roese ; Prabhakar
> Kushwaha 
> Subject: [U-Boot][PATCH] arm: arm64 32bit address relocation
> 
> Current relocation code is limited to 21bit PC-relative addressing
> which might not be enough for bigger code sizes. The following patch
> increases the addressing to 32bit PC-relative. This feature is
> specially interesting if U-Boot is build without optimiation (-O0) as
> the text section is increased significativelly.
> 
> Signed-off-by: Ibai Erkiaga 
> ---
> 
>  arch/arm/lib/relocate_64.S | 19 ---
>  1 file changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/lib/relocate_64.S b/arch/arm/lib/relocate_64.S
> index 7603f52..6e9658b 100644
> --- a/arch/arm/lib/relocate_64.S
> +++ b/arch/arm/lib/relocate_64.S
> @@ -26,9 +26,10 @@ ENTRY(relocate_code)
>   /*
>* Copy u-boot from flash to RAM
>*/
> - adr x1, __image_copy_start  /* x1 <- Run
> &__image_copy_start */
> - subsx9, x0, x1  /* x8 <- Run to copy offset */
> - b.eqrelocate_done   /* skip relocation */
> + adrpx1, __image_copy_start  /* x1 <- address bits
> [31:12] */
> + add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00]
> */
> + subsx9, x0, x1  /* x8 <- Run to copy offset */

Should be x9 in comments 

> + b.eqrelocate_done   /* skip relocation */
>   /*
>* Don't ldr x1, __image_copy_start here, since if the code is already
>* running at an address other than it was linked to, that instruction
> @@ -42,8 +43,10 @@ ENTRY(relocate_code)
>   ldr x1, _TEXT_BASE  /* x1 <- Linked
> &__image_copy_start */
>   subsx9, x0, x1  /* x9 <- Link to copy offset */
> 
> - adr x1, __image_copy_start  /* x1 <- Run
> &__image_copy_start */
> - adr x2, __image_copy_end/* x2 <- Run &__image_copy_end */
> + adrpx1, __image_copy_start  /* x1 <- address bits
> [31:12] */
> + add x1, x1, :lo12:__image_copy_start/* x1 <- address bits [11:00]
> */
> + adrpx2, __image_copy_end/* x2 <- address bits [31:12]
> */
> + add x2, x2, :lo12:__image_copy_end  /* x2 <- address bits
> [11:00] */
>  copy_loop:
>   ldp x10, x11, [x1], #16 /* copy from source address [x1] */
>   stp x10, x11, [x0], #16 /* copy to   target address [x0] */
> @@ -54,8 +57,10 @@ copy_loop:
>   /*
>* Fix .rela.dyn relocations
>*/
> - adr x2, __rel_dyn_start /* x2 <- Run &__rel_dyn_start */
> - adr x3, __rel_dyn_end   /* x3 <- Run &__rel_dyn_end */
> + adrpx2, __rel_dyn_start /* x2 <- address bits [31:12]
> */
> + add x2, x2, :lo12:__rel_dyn_start   /* x2 <- address bits [11:00]
> */
> + adrpx3, __rel_dyn_end   /* x3 <- address bits [31:12]
> */
> + add x3, x3, :lo12:__rel_dyn_end /* x3 <- address bits [11:00]
> */
>  fixloop:
>   ldp x0, x1, [x2], #16   /* (x0,x1) <- (SRC location, fixup) */
>   ldr x4, [x2], #8/* x4 <- addend */
> --
> 1.8.3.1

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

[U-Boot] [PATCH] drivers: net: ls1088ardb: Fix EC1 and EC2 RCW offset

2019-02-28 Thread Pramod Kumar

Fix EC1 and EC2 read from correct offset 26, instead of 25

Signed-off-by: Pramod Kumar 
---
 drivers/net/ldpaa_eth/ls1088a.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ldpaa_eth/ls1088a.c b/drivers/net/ldpaa_eth/ls1088a.c
index 43210532ba..c3260d318c 100644
--- a/drivers/net/ldpaa_eth/ls1088a.c
+++ b/drivers/net/ldpaa_eth/ls1088a.c
@@ -93,7 +93,7 @@ void fsl_rgmii_init(void)
u32 ec;
 
 #ifdef CONFIG_SYS_FSL_EC1
-   ec = gur_in32(>rcwsr[FSL_CHASSIS3_EC1_REGSR - 1])
+   ec = gur_in32(>rcwsr[FSL_CHASSIS3_EC1_REGSR])
& FSL_CHASSIS3_RCWSR25_EC1_PRTCL_MASK;
ec >>= FSL_CHASSIS3_RCWSR25_EC1_PRTCL_SHIFT;
 
@@ -102,7 +102,7 @@ void fsl_rgmii_init(void)
 #endif
 
 #ifdef CONFIG_SYS_FSL_EC2
-   ec = gur_in32(>rcwsr[FSL_CHASSIS3_EC2_REGSR - 1])
+   ec = gur_in32(>rcwsr[FSL_CHASSIS3_EC2_REGSR])
& FSL_CHASSIS3_RCWSR25_EC2_PRTCL_MASK;
ec >>= FSL_CHASSIS3_RCWSR25_EC2_PRTCL_SHIFT;
 
-- 
2.17.1

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

Re: [U-Boot] Commit "ARM: CPU: arm926ejs: Consolidate cache routines to common file" breaks u-boot on Dreamplug

Hi Leigh,

On Thu, Feb 28, 2019 at 1:11 AM Leigh Brown  wrote:
>
> Hello,
>
> Vagrant Cascadian asked for people to test the version of u-boot
> packaged
> for Debian Buster.  I tested u-boot on my Dreamplug and found it was not
> working correctly.  I raised a bug for Debian[1] but I have also tested
> with the mainline version of u-boot and found the same issues.
>
> The first issue is that the following commit caused u-boot to no longer
> be able to access usb storage on the Dreamplug:
>
> commit 93b283d49f933f95f3a6f40762936f454ac655a8
> Author: Adam Ford 
> Date:   Thu Aug 16 13:23:11 2018 -0500
>
>  ARM: CPU: arm926ejs: Consolidate cache routines to common file
>
>  Four different boards had different options for enabling cache
>  that were virtually all the same.  This consolidates these
>  common functions into arch/arm/cpu/arm926ejs/cache.c
>
>  This also has the positive side-effect of enabling cache on
>  the Davinci (da850) boards.
>
>  Signed-off-by: Adam Ford 
>  [trini: Add mach-at91 to the list of consolidations]
>  Signed-off-by: Tom Rini 
>
> I don't have much knowledge of ARM caching, but the following patch
> makes
> it work again on my Dreamplug.
>
> diff --git a/arch/arm/mach-kirkwood/cpu.c b/arch/arm/mach-kirkwood/cpu.c
> index d54de53f31..8a065d73ae 100644
> --- a/arch/arm/mach-kirkwood/cpu.c
> +++ b/arch/arm/mach-kirkwood/cpu.c
> @@ -291,7 +291,6 @@ int arch_misc_init(void)
> temp |= (1 << 22);
> writefr_extra_feature_reg(temp);
>
> -   icache_enable();
> /* Change reset vector to address 0x0 */
> temp = get_cr();
> set_cr(temp & ~CR_V);
> diff --git a/include/configs/dreamplug.h b/include/configs/dreamplug.h
> index f4d717213c..6348935c68 100644
> --- a/include/configs/dreamplug.h
> +++ b/include/configs/dreamplug.h
> @@ -79,4 +79,6 @@
>   #define CONFIG_SYS_ATA_IDE0_OFFSETMV_SATA_PORT0_OFFSET
>   #endif /*CONFIG_MVSATA_IDE*/
>
> +#define CONFIG_SYS_DCACHE_OFF
> +
>   #endif /* _CONFIG_DREAMPLUG_H */
>
> I'd be grateful if someone could take a look.  If you need me to do any
> testing  or provide any more information, please let me know.
>

Thanks for pointing this out. I'd been having a problem like this with
the Ethernet interface. I'd been blaming the hardware I was using but
your change makes things work for me.

> I found another issue (documented in the same bug).  I'll send a
> separate
> email about that.
>
> Regards,
>
> Leigh.
>
> --
> [1] 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=923379___
> 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 2/2] x86: edison: Add the rest of UARTs present on board

2019-02-28 Thread Bin Meng

On Thu, Feb 28, 2019 at 4:12 PM Andy Shevchenko
 wrote:
>
> Intel Edison has three UART ports, i.e.
>  port 0 - Bluetooth
>  port 1 - auxiliary, available for general purpose use
>  port 2 - debugging, usually console output is here
>
> Enable all of them for future use.
>
> Signed-off-by: Andy Shevchenko 
> ---
>  arch/x86/dts/edison.dts | 18 ++
>  1 file changed, 18 insertions(+)
>

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

[U-Boot] [PATCH v2 1/2] x86: edison: Use proper number of serial interface

The console is actually serial #2. When we would like to enable other ports,
this would be not okay to mess up with the ordering.

Thus, fix the number of default console interface to be 2.

Reviewed-by: Bin Meng 
Signed-off-by: Andy Shevchenko 
---
 arch/x86/dts/edison.dts | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/dts/edison.dts b/arch/x86/dts/edison.dts
index 0dd72407ea..b59171cb50 100644
--- a/arch/x86/dts/edison.dts
+++ b/arch/x86/dts/edison.dts
@@ -17,11 +17,11 @@
compatible = "intel,edison";
 
aliases {
-   serial0 = 
+   serial2 = 
};
 
chosen {
-   stdout-path = 
+   stdout-path = 
};
 
cpus {
@@ -53,7 +53,7 @@
  0x0100 0x0 0x2000 0x2000 0 0xe000>;
};
 
-   serial0: serial@ff010180 {
+   serial2: serial@ff010180 {
compatible = "intel,mid-uart";
reg = <0xff010180 0x100>;
reg-shift = <0>;
-- 
2.20.1

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

[U-Boot] [PATCH] board: fsl: lx2160aqds: modify the phy fixup code

2019-02-28 Thread Pankaj Bansal

Now that we are representing the MDIO mux in LX2160AQDS board in
producer/consumer terms, the consumer nodes' has been changed.

Therefore, modify the device tree fixups according to change in device
tree.

Signed-off-by: Pankaj Bansal 
---

Notes:
reference 
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=43185c3b82c33df351bf6a605ca884c35099b6c6

 board/freescale/lx2160a/eth_lx2160aqds.c | 38 ++
 1 file changed, 31 insertions(+), 7 deletions(-)

diff --git a/board/freescale/lx2160a/eth_lx2160aqds.c 
b/board/freescale/lx2160a/eth_lx2160aqds.c
index 1e98d0c1f9..f6e22d7337 100644
--- a/board/freescale/lx2160a/eth_lx2160aqds.c
+++ b/board/freescale/lx2160a/eth_lx2160aqds.c
@@ -628,8 +628,9 @@ int fdt_fixup_dpmac_phy_handle(void *fdt, int dpmac_id, int 
node_phandle)
 int fdt_get_ioslot_offset(void *fdt, struct mii_dev *mii_dev, int fpga_offset)
 {
char mdio_ioslot_str[] = "mdio@00";
-   char mdio_mux_str[] = "mdio-mux-0";
struct lx2160a_qds_mdio *priv;
+   u64 reg;
+   u32 phandle;
int offset, mux_val;
 
/*Test if the MDIO bus is real mdio bus or muxing front end ?*/
@@ -643,15 +644,32 @@ int fdt_get_ioslot_offset(void *fdt, struct mii_dev 
*mii_dev, int fpga_offset)
debug("real_bus_num = %d, ioslot = %d\n",
  priv->realbusnum, priv->ioslot);
 
-   sprintf(mdio_mux_str, "mdio-mux-%1d", priv->realbusnum);
-   offset = fdt_subnode_offset(fdt, fpga_offset, mdio_mux_str);
+   if (priv->realbusnum == EMI1)
+   reg = CONFIG_SYS_FSL_WRIOP1_MDIO1;
+   else
+   reg = CONFIG_SYS_FSL_WRIOP1_MDIO2;
+
+   offset = fdt_node_offset_by_compat_reg(fdt, "fsl,fman-memac-mdio", reg);
+   if (offset < 0) {
+   printf("mdio@%llx node not found in device tree\n", reg);
+   return offset;
+   }
+
+   phandle = fdt_get_phandle(fdt, offset);
+   phandle = cpu_to_fdt32(phandle);
+   offset = fdt_node_offset_by_prop_value(fdt, -1, "mdio-parent-bus",
+  , 4);
if (offset < 0) {
-   printf("%s node not found under node %s in device tree\n",
-  mdio_mux_str, fdt_get_name(fdt, fpga_offset, NULL));
+   printf("mdio-mux-%d node not found in device tree\n",
+  priv->realbusnum == EMI1 ? 1 : 2);
return offset;
}
 
mux_val = lx2160a_qds_get_mdio_mux_val(priv->realbusnum, priv->ioslot);
+   if (priv->realbusnum == EMI1)
+   mux_val >>= BRDCFG4_EMI1SEL_SHIFT;
+   else
+   mux_val >>= BRDCFG4_EMI2SEL_SHIFT;
sprintf(mdio_ioslot_str, "mdio@%x", (u8)mux_val);
 
offset = fdt_subnode_offset(fdt, offset, mdio_ioslot_str);
@@ -675,7 +693,9 @@ int fdt_create_phy_node(void *fdt, int offset, u8 phyaddr, 
int *subnodeoffset,
 
*subnodeoffset = fdt_add_subnode(fdt, offset, phy_node_name);
if (*subnodeoffset <= 0) {
-   printf("Could not add subnode %s\n", phy_node_name);
+   printf("Could not add subnode %s inside node %s err = %s\n",
+  phy_node_name, fdt_get_name(fdt, offset, NULL),
+  fdt_strerror(*subnodeoffset));
return *subnodeoffset;
}
 
@@ -779,7 +799,6 @@ int fdt_fixup_board_phy(void *fdt)
}
if (dpmac_id == NUM_WRIOP_PORTS)
continue;
-
ret = fdt_create_phy_node(fdt, offset, i,
  ,
  phy_dev, phandle);
@@ -792,6 +811,11 @@ int fdt_fixup_board_phy(void *fdt)
fdt_del_node(fdt, subnodeoffset);
break;
}
+   /* calculate offset again as new node addition may have
+* changed offset;
+*/
+   offset = fdt_get_ioslot_offset(fdt, mii_dev,
+  fpga_offset);
phandle++;
}
 
-- 
2.17.1

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

[U-Boot] [PATCH v2 2/2] x86: edison: Add the rest of UARTs present on board