Re: [U-Boot] [PATCH v11 3/9] ARM: socfpga: Cleaning up the messages

[Chee, Tien Fong]

On Tue, 2019-03-05 at 22:31 -0600, Dinh Nguyen wrote:
> 
> On 3/5/19 10:23 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > Ensure the comment and debug messages are always consistent with
> > the rest.
> The rest of what? This patch seems unnecessary to me.

This patch is mainly to change all existing debug messages with prefix
"FPGA:" and ensure uppercase for 1st character in all messages inside
FPGA driver.

Thanks,
TF.
> 
> > 
> > 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  drivers/fpga/socfpga_arria10.c | 13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/fpga/socfpga_arria10.c
> > b/drivers/fpga/socfpga_arria10.c
> > index 114dd910ab..b0abe1955c 100644
> > --- a/drivers/fpga/socfpga_arria10.c
> > +++ b/drivers/fpga/socfpga_arria10.c
> > @@ -94,7 +94,7 @@ int fpgamgr_wait_early_user_mode(void)
> >     i++;
> >     }
> >  
> > -   debug("Additional %i sync word needed\n", i);
> > +   debug("FPGA: Additional %i sync word needed\n", i);
> >  
> >     /* restoring original CDRATIO */
> >     fpgamgr_set_cd_ratio(cd_ratio);
> > @@ -172,9 +172,10 @@ static int
> > fpgamgr_set_cdratio_cdwidth(unsigned int cfg_width, u32 *rbf_data,
> >     compress = (rbf_data[COMPRESSION_OFFSET] >> 1) & 1;
> >     compress = !compress;
> >  
> > -   debug("header word %d = %08x\n", 69, rbf_data[69]);
> > -   debug("header word %d = %08x\n", 229, rbf_data[229]);
> > -   debug("read from rbf header: encrypt=%d compress=%d\n",
> > encrypt, compress);
> > +   debug("FPGA: Header word %d = %08x.\n", 69, rbf_data[69]);
> > +   debug("FPGA: Header word %d = %08x.\n", 229,
> > rbf_data[229]);
> > +   debug("FPGA: Read from rbf header: encrypt=%d
> > compress=%d.\n", encrypt,
> > +    compress);
> >  
> >     /*
> >      * from the register map description of cdratio in
> > imgcfg_ctrl_02:
> > @@ -455,10 +456,10 @@ int socfpga_load(Altera_desc *desc, const
> > void *rbf_data, size_t rbf_size)
> >  {
> >     int status;
> >  
> > -   /* disable all signals from hps peripheral controller to
> > fpga */
> > +   /* Disable all signals from hps peripheral controller to
> > fpga */
> >     writel(0, _manager_base->fpgaintf_en_global);
> >  
> > -   /* disable all axi bridge (hps2fpga, lwhps2fpga &
> > fpga2hps) */
> > +   /* Disable all axi bridge (hps2fpga, lwhps2fpga &
> > fpga2hps) */
> >     socfpga_bridges_reset();
> >  
> >     /* Initialize the FPGA Manager */
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v11 1/9] ARM: socfpga: Description on FPGA bitstream type and file name for Arria 10

[Chee, Tien Fong]

On Tue, 2019-03-05 at 13:12 -0600, Dinh Nguyen wrote:
> Curious, you sent out 3 versions(2x v10, and v11) within ~2 hours.
> What
> versions should we be reviewing?
2nd version of v10 was resent quickly after request from Dalon to
change the node names. I have comment on the 1st version v10 cover
letter to void the whole series since no review starting yet.

After that, Marek told me to resend in v11.

Sorry for any confusion, please help to review v11, this series of
patches mainly resolved some comments from Simek on [v9]: https://www.m
ail-archive.com/u-boot@lists.denx.de/msg316086.html and node names
changed on patch [2/9]
> 
> On 3/5/19 10:23 AM, tien.fong.c...@intel.com wrote:
> > 
> > From: Tien Fong Chee 
> > 
> > This patch adds description on properties about file name used for
> > both
> > peripheral bitstream and core bitstream.
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v11 9/9] ARM: socfpga: Increase Malloc pool size to support FAT filesystem in SPL

[Chee, Tien Fong]

On Tue, 2019-03-05 at 21:05 +0100, Simon Goldschmidt wrote:
> Am 05.03.2019 um 17:23 schrieb tien.fong.c...@intel.com:
> > 
> > From: Tien Fong Chee 
> > 
> > After some series of patches to maximise reusable of memory pool,
> > here come
> > to result of reasonable size required for whole SDMMC boot working
> > on A10
> > SoCDK. Size required come from default max cluster(0x1) +
> > others(0x2000) + additional memory for headroom(0x3000).
> > 
> > Signed-off-by: Tien Fong Chee 
> > 
> > ---
> > 
> > changes for v7
> > - Added 0x3000 for memory headroom.
> > ---
> >   include/configs/socfpga_common.h | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/configs/socfpga_common.h
> > b/include/configs/socfpga_common.h
> > index 4551cb29bc..548b458e78 100644
> > --- a/include/configs/socfpga_common.h
> > +++ b/include/configs/socfpga_common.h
> > @@ -1,6 +1,6 @@
> >   /* SPDX-License-Identifier: GPL-2.0+ */
> >   /*
> > - * Copyright (C) 2012 Altera Corporation 
> > + * Copyright (C) 2012-2019 Altera Corporation 
> >    */
> >   #ifndef __CONFIG_SOCFPGA_COMMON_H__
> >   #define __CONFIG_SOCFPGA_COMMON_H__
> > @@ -258,7 +258,7 @@ unsigned int
> > cm_get_qspi_controller_clk_hz(void);
> >   #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_SIZE 0x00015000
> This will clash with my series here:
> https://patchwork.ozlabs.org/patch/1051451/
> 
> Any chance you could test that on A10? I only have a cyclone 5.
> 
I have tested the series, and checking the failure from the codes,
SPL_SYS_MALLOC_SIMPLE and SPL_SYS_MALLOC_F_LEN are not working in A10,
because FPGA loading and distro boot from FAT FS require full malloc
mechanism.

Thanks,
TF.
> 
> 
> > 
> >   #define CONFIG_SYS_SPL_MALLOC_START   (CONFIG_SYS_INIT_RAM_S
> > IZE - \
> >      CONFIG_SYS_SPL_MALLOC_SI
> > ZE + \
> >      CONFIG_SYS_INIT_RAM_ADDR
> > )
> > 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] i2c: rcar_iic: Read ICSR only once

[Heiko Schocher]

Hello Marek,

Am 07.03.2019 um 03:41 schrieb Marek Vasut:

Read ICSR only once to avoid missing interrupts. This happens on R8A7791
Porter during reset, when reading the PMIC register 0x13, which may fail
sometimes because of the missed DTE interrupt.

Signed-off-by: Marek Vasut 
Cc: Heiko Schocher 
Cc: Nobuhiro Iwamatsu 
---
  drivers/i2c/rcar_iic.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)


Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH 2/2] mtd: ubi, ubifs debug: Use pr_debug instead of pr_crit

[Heiko Schocher]

Hello Eran,

Am 13.02.2019 um 19:56 schrieb Eran Matityahu:

Before printk.h was introduced and MTDDEBUG was removed,
pr_crit() was calling MTDDEBUG(), which was since then
replaced by the current pr_debug().

pr_debug is more appropriate here.

Signed-off-by: Eran Matityahu 
---
  drivers/mtd/ubi/debug.h | 2 +-
  fs/ubifs/debug.h| 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)


Reviewed-by: Heiko Schocher 

queued for next merge window.

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

Re: [U-Boot] [PATCH 1/2] mtd: ubi debug: Remove the pid print from ubi_assert

[Heiko Schocher]

Hello Eran,

Am 13.02.2019 um 19:55 schrieb Eran Matityahu:

Add a new definition for ubi_assert and keep
the original one in an ifndef __UBOOT__.

Signed-off-by: Eran Matityahu 
---
  drivers/mtd/ubi/debug.h | 10 ++
  1 file changed, 10 insertions(+)


Reviewed-by: Heiko Schocher 

queued for next merge window.

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

Re: [U-Boot] [PATCH v3 1/6] i2c: rcar_i2c: Setup SCL/SDA delay at rcar_i2c_set_speed

[Heiko Schocher]

Hello Ismael,

Am 06.03.2019 um 11:46 schrieb Ismael Luceno Cortes:

Setting up the delay only needs to be done once; move it to
rcar_i2c_set_speed so it's done at initialization time.

Signed-off-by: Ismael Luceno 
---
  drivers/i2c/rcar_i2c.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)


Your patch does not apply to

base-commit: f08023c07d826fbc8e62fdd3367961b2f0b06844

I get based on f08023c07d826fbc8e62fdd3367961b2f0b06844

Applying: i2c: rcar_i2c: Setup SCL/SDA delay at rcar_i2c_set_speed
error: sha1 information is lacking or useless (drivers/i2c/rcar_i2c.c).
error: could not build fake ancestor
Patch failed at 0001 i2c: rcar_i2c: Setup SCL/SDA delay at rcar_i2c_set_speed
Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

My base:

pollux:u-boot hs [temp] $ glg
* f08023c07d - (HEAD -> temp, tag: v2019.04-rc3, origin/master, origin/HEAD, master) Prepare 
v2019.04-rc4 (2 days ago) 

*   e102f74d65 - Merge branch 'master' of git://git.denx.de/u-boot-sh (2 days ago) 

|\
| * 65eef78cdb - pinctrl: renesas: r8a77990: Reivse USB ID pin name (3 days ago) 



How does this work for you ?

> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 10b0f8bad4..a57f72a228 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -116,9 +116,7 @@ static int rcar_i2c_set_addr(struct udevice *dev, u8 
chip, u8 read)
>writel(0, priv->base + RCAR_I2C_ICMSR);
>writel(priv->icccr, priv->base + RCAR_I2C_ICCCR);
>
> -  if (priv->type == RCAR_I2C_TYPE_GEN3)
> -  writel(RCAR_I2C_ICFBSCR_TCYC17, priv->base + RCAR_I2C_ICFBSCR);
> -
> +  /* Wait for the bus */
>ret = wait_for_bit_le32(priv->base + RCAR_I2C_ICMCR,
>RCAR_I2C_ICMCR_FSDA, false, 2, true);
>if (ret) {

I do not find RCAR_I2C_TYPE_GEN3 in current mainline code ... please
check!

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

Re: [U-Boot] [PATCH] spl: ymodem: Add support for loading full fitImages

[Lokesh Vutla]

On 07/03/19 2:34 AM, Marek Vasut wrote:
> Add support for loading fully featured fitImages over YModem in SPL.
> This is useful when various advanced features of full fitImages are
> needed in SPL.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> ---
>  common/spl/spl_ymodem.c | 20 +++-
>  1 file changed, 19 insertions(+), 1 deletion(-)
> 
> diff --git a/common/spl/spl_ymodem.c b/common/spl/spl_ymodem.c
> index 577fdc69af..4c2e84e07d 100644
> --- a/common/spl/spl_ymodem.c
> +++ b/common/spl/spl_ymodem.c
> @@ -89,7 +89,25 @@ static int spl_ymodem_load_image(struct spl_image_info 
> *spl_image,
>   if (res <= 0)
>   goto end_stream;
>  
> - if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
> + if (IS_ENABLED(CONFIG_SPL_LOAD_FIT_FULL) &&
> + image_get_magic((struct image_header *)buf) == FDT_MAGIC) {
> + addr = CONFIG_SYS_LOAD_ADDR;
> + ih = (struct image_header *)addr;
> +
> + memcpy((void *)addr, buf, res);
> + size += res;
> + addr += res;
> +
> + while ((res = xyzModem_stream_read(buf, BUF_SIZE, )) > 0) {
> + memcpy((void *)addr, buf, res);
> + size += res;
> + addr += res;
> + }

okay, but you are not parsing the FIT image here. Is this even booting? or you
are doing some parsing after loading?

Also this code looks very much similar to the one available in the else part.
Can we re use it?

Thanks and regards,
Lokesh

> +
> + ret = spl_parse_image_header(spl_image, ih);
> + if (ret)
> + return ret;
> + } else if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
>   image_get_magic((struct image_header *)buf) == FDT_MAGIC) {
>   struct spl_load_info load;
>   struct ymodem_fit_info info;
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 6/6] i2c: rcar_i2c: Move FSDA check to rcar_i2c_recover

[Heiko Schocher]

Hello Ismael,

Am 06.03.2019 um 11:46 schrieb Ismael Luceno Cortes:

Cosmetic change.  Any call to the recover function would need to do the
same check afterwards, so it's sensible to make it part of the function.

Signed-off-by: Ismael Luceno 
---
  drivers/i2c/rcar_i2c.c | 10 ++
  1 file changed, 6 insertions(+), 4 deletions(-)


Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH v3 5/6] i2c: rcar_i2c: Set the slave address from rcar_i2c_xfer

[Heiko Schocher]

Hello Ismael,

Am 06.03.2019 um 11:46 schrieb Ismael Luceno Cortes:

It needs to be done for both reads and writes, so do it at rcar_i2c_xfer
to avoid duplication.

Signed-off-by: Ismael Luceno 
---
  drivers/i2c/rcar_i2c.c | 14 +-
  1 file changed, 5 insertions(+), 9 deletions(-)


Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH v3 4/6] i2c: rcar_i2c: Don't mask errors with EREMOTEIO at rcar_i2c_xfer

[Heiko Schocher]

Hello Ismael,

Am 06.03.2019 um 11:46 schrieb Ismael Luceno Cortes:

Fix rcar_i2c_xfer return value, previously it was always returning
-EREMOTEIO when dealing with errors from calls to the read/write
functions.

Signed-off-by: Ismael Luceno 
---
  drivers/i2c/rcar_i2c.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH v3 3/6] i2c: rcar_i2c: Fix sending of slave addresses

[Heiko Schocher]

Hello Ismael,

Am 06.03.2019 um 11:46 schrieb Ismael Luceno Cortes:

Do the reset before clearing the MSR, otherwise it may result in a read
or write operation instead if the start condition is repeated.

Signed-off-by: Ismael Luceno 
Reviewed-by: Marek Vasut 
---
  drivers/i2c/rcar_i2c.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)


Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH v3 2/6] i2c: rcar_i2c: Add comments about registers & values

[Heiko Schocher]

Hello Ismael,

Am 06.03.2019 um 11:46 schrieb Ismael Luceno Cortes:

Document the meaning of macros related to registers and values to be
written to them.

Signed-off-by: Ismael Luceno 
---
  drivers/i2c/rcar_i2c.c | 47 +++---
  1 file changed, 26 insertions(+), 21 deletions(-)


Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH v3 1/6] i2c: rcar_i2c: Setup SCL/SDA delay at rcar_i2c_set_speed

[Heiko Schocher]

Hello Ismael,

Am 06.03.2019 um 11:46 schrieb Ismael Luceno Cortes:

Setting up the delay only needs to be done once; move it to
rcar_i2c_set_speed so it's done at initialization time.

Signed-off-by: Ismael Luceno 
---
  drivers/i2c/rcar_i2c.c | 9 ++---
  1 file changed, 6 insertions(+), 3 deletions(-)


Reviewed-by: Heiko Schocher 

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

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Anup Patel]

> -Original Message-
> From: Atish Patra 
> Sent: Thursday, March 7, 2019 5:20 AM
> To: Anup Patel ; Auer, Lukas
> 
> Cc: sch...@suse.de; paul.walms...@sifive.com; ag...@suse.de; u-
> b...@lists.denx.de; bar...@tkos.co.il; daniel.schwierz...@gmail.com;
> bmeng...@gmail.com; r...@andestech.com; s...@denx.de;
> pal...@sifive.com; Anup Patel 
> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> 
> On 3/6/19 4:32 AM, Anup Patel wrote:
> > On Wed, Mar 6, 2019 at 5:45 PM Auer, Lukas
> >  wrote:
> >>
> >> On Wed, 2019-03-06 at 13:01 +0100, Andreas Schwab wrote:
> >>> On Mär 06 2019, Anup Patel  wrote:
> >>>
>  On Wed, Mar 6, 2019 at 5:17 PM Andreas Schwab 
>  wrote:
> > On Mär 06 2019, Anup Patel  wrote:
> >
> >>> -Original Message-
> >>> From: Andreas Schwab 
> >>> Sent: Wednesday, March 6, 2019 4:27 PM
> >>> To: Anup Patel 
> >>> Cc: Auer, Lukas ;
> >>> u-boot@lists.denx.de; paul.walms...@sifive.com; ag...@suse.de;
> >>> a...@brainfault.org; bar...@tkos.co.il;
> >>> daniel.schwierz...@gmail.com; bmeng...@gmail.com;
> >>> r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish Patra
> >>> 
> >>> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> >>>
> >>> Apparently sometimes u-boot tries to boot the kernel on heart
> >>> 0 (the E51
> >>> core), which will then fail to start userspace, since that
> >>> cannot cope with the missing fpu.
> >>
> >> That's not possible
> >
> > Yes, it is.
> >
> >
> > OpenSBI v0.3 (Mar  6 2019 10:55:01)
> > _  _
> >/ __ \  / |  _ \_   _|
> >   | |  | |_ __   ___ _ __ | (___ | |_) || |
> >   | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> >   | |__| | |_) |  __/ | | |) | |_) || |_
> >\/| .__/ \___|_| |_|_/|/_|
> >  | |
> >  |_|
> >
> > Platform Name  : SiFive Freedom U540
> > Platform HART Features : RV64ACDFIMSU
> > Platform Max HARTs : 5
> > Current Hart   : 2
> > Firmware Base  : 0x8000
> > Firmware Size  : 88 KB
> > Runtime SBI Version: 0.1
> >
> > PMP0: 0x8000-0x8001 (A)
> > PMP1: 0x-0x007f (A,R,W,X)
> >
> >
> > U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10
> > +0100)
> >
> > CPU:   rv64imac
> > Model: sifive,hifive-unleashed-a00
> > DRAM:  8 GiB
> 
>  How does this prove that U-Boot is booting on HART 0?
> >>>
> >>> See the CPU isa.
> >>>
> >>
> >> Interesting.. U-Boot assumes that it can run on any core it is
> >> started on. In this case, OpenSBI must have booted its payload on hart 0.
> >
> > This is certainly not reproducible on cold-boot at my end but this
> > does mean OpenSBI has booted HART0 and let it jump to U-Boot.
> >
> > Now OpenSBI (by default) on SiFive FU540 does not allow HART0 to go
> > forward due to lack of S-mode. I think this is definitely the
> > warm-boot issue where OpenSBI sees corrupted memory contents.
> >
> 
> I am able to test both warm-boot and cold-boot several times(>10) without
> any issue with following pending PR in openSBI.
> 
> https://github.com/riscv/opensbi/pull/84

Thanks Atish, your changes have been merged in OpenSBI.

> 
> @Andreas @Anup: Can you please apply the above PR on top of master and
> verify at your end as well?
> 
> All the harts booted in Linux every time as well.

I tried warm-boot 10 times from U-Boot prompt and I did not see any issue
at all.

I also tried warm-boot 10 times from Linux prompt and I did not see any
Issue at all.

In both above cases, it came back to U-Boot prompt after warm-boot.

Also, tried cold-boot couple of times. I works perfectly fine as well.

Like I mentioned, there is no functional issue with this series. The
warm-boot issues were fixed in OpenSBI.

@Andreas, please try at your end.

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

Re: [U-Boot] [PATCH v2 7/9] riscv: do not rely on hart ID passed by previous boot stage

[Atish Patra]

On 3/5/19 2:54 PM, Lukas Auer wrote:

RISC-V U-Boot expects the hart ID to be passed to it via register a0 by
the previous boot stage. Machine mode firmware such as BBL and OpenSBI
do this when starting their payload (U-Boot) in supervisor mode. If
U-Boot is running in machine mode, this task must be handled by the boot
ROM. Explicitly populate register a0 with the hart ID from the mhartid
CSR to avoid possible problems on RISC-V processors with a boot ROM that
does not handle this task.

Suggested-by: Rick Chen 
Signed-off-by: Lukas Auer 
---

Changes in v2:
- New patch to populate register a0 with the hart ID from the mhartid
CSR in machine-mode

  arch/riscv/cpu/start.S | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 79b753847c..d4daa6e0bf 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -36,6 +36,10 @@
  .section .text
  .globl _start
  _start:
+#ifdef CONFIG_RISCV_MMODE
+   csrra0, mhartid
+#endif
+
/* save hart id and dtb pointer */
mv  s0, a0
mv  s1, a1



Reviewed-by: Atish Patra 

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

Re: [U-Boot] [PATCH v2 3/9] riscv: implement IPI platform functions using SBI

[Atish Patra]

On 3/5/19 2:54 PM, Lukas Auer wrote:

The supervisor binary interface (SBI) provides the necessary functions
to implement the platform IPI functions riscv_send_ipi() and
riscv_clear_ipi(). Use it to implement them.

This adds support for inter-processor interrupts (IPIs) on RISC-V CPUs
running in supervisor mode. Support for machine mode is already
available for CPUs that include the SiFive CLINT.

Signed-off-by: Lukas Auer 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---

Changes in v2: None

  arch/riscv/Kconfig   |  5 +
  arch/riscv/lib/Makefile  |  1 +
  arch/riscv/lib/sbi_ipi.c | 25 +
  3 files changed, 31 insertions(+)
  create mode 100644 arch/riscv/lib/sbi_ipi.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 4d7a115569..9da609b33b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -139,4 +139,9 @@ config NR_CPUS
  Stack memory is pre-allocated. U-Boot must therefore know the
  maximum number of CPUs that may be present.
  
+config SBI_IPI

+   bool
+   default y if RISCV_SMODE
+   depends on SMP
+
  endmenu
diff --git a/arch/riscv/lib/Makefile b/arch/riscv/lib/Makefile
index 19370f9749..35dbf643e4 100644
--- a/arch/riscv/lib/Makefile
+++ b/arch/riscv/lib/Makefile
@@ -13,6 +13,7 @@ obj-$(CONFIG_RISCV_RDTIME) += rdtime.o
  obj-$(CONFIG_SIFIVE_CLINT) += sifive_clint.o
  obj-y += interrupts.o
  obj-y += reset.o
+obj-$(CONFIG_SBI_IPI) += sbi_ipi.o
  obj-y   += setjmp.o
  obj-$(CONFIG_SMP) += smp.o
  
diff --git a/arch/riscv/lib/sbi_ipi.c b/arch/riscv/lib/sbi_ipi.c

new file mode 100644
index 00..170346da68
--- /dev/null
+++ b/arch/riscv/lib/sbi_ipi.c
@@ -0,0 +1,25 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019 Fraunhofer AISEC,
+ * Lukas Auer 
+ */
+
+#include 
+#include 
+
+int riscv_send_ipi(int hart)
+{
+   ulong mask;
+
+   mask = 1UL << hart;
+   sbi_send_ipi();
+
+   return 0;
+}
+
+int riscv_clear_ipi(int hart)
+{
+   sbi_clear_ipi();
+
+   return 0;
+}



LGTM.

Reviewed-by: Atish Patra 

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

Re: [U-Boot] [PATCH v2 2/9] riscv: import the supervisor binary interface header file

[Atish Patra]

On 3/5/19 2:54 PM, Lukas Auer wrote:

Import the supervisor binary interface (SBI) header file from Linux
(arch/riscv/include/asm/sbi.h). The last change to it was in commit
6d60b6ee0c97 ("RISC-V: Device, timer, IRQs, and the SBI").

Signed-off-by: Lukas Auer 
Reviewed-by: Anup Patel 
Reviewed-by: Bin Meng 
---

Changes in v2: None

  arch/riscv/include/asm/sbi.h | 94 
  1 file changed, 94 insertions(+)
  create mode 100644 arch/riscv/include/asm/sbi.h

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
new file mode 100644
index 00..ced57defdd
--- /dev/null
+++ b/arch/riscv/include/asm/sbi.h
@@ -0,0 +1,94 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2015 Regents of the University of California
+ *
+ * Taken from Linux arch/riscv/include/asm/sbi.h
+ */
+
+#ifndef _ASM_RISCV_SBI_H
+#define _ASM_RISCV_SBI_H
+
+#include 
+
+#define SBI_SET_TIMER 0
+#define SBI_CONSOLE_PUTCHAR 1
+#define SBI_CONSOLE_GETCHAR 2
+#define SBI_CLEAR_IPI 3
+#define SBI_SEND_IPI 4
+#define SBI_REMOTE_FENCE_I 5
+#define SBI_REMOTE_SFENCE_VMA 6
+#define SBI_REMOTE_SFENCE_VMA_ASID 7
+#define SBI_SHUTDOWN 8
+
+#define SBI_CALL(which, arg0, arg1, arg2) ({   \
+   register uintptr_t a0 asm ("a0") = (uintptr_t)(arg0); \
+   register uintptr_t a1 asm ("a1") = (uintptr_t)(arg1); \
+   register uintptr_t a2 asm ("a2") = (uintptr_t)(arg2); \
+   register uintptr_t a7 asm ("a7") = (uintptr_t)(which);\
+   asm volatile ("ecall" \
+ : "+r" (a0) \
+ : "r" (a1), "r" (a2), "r" (a7)  \
+ : "memory");\
+   a0; \
+})
+
+/* Lazy implementations until SBI is finalized */
+#define SBI_CALL_0(which) SBI_CALL(which, 0, 0, 0)
+#define SBI_CALL_1(which, arg0) SBI_CALL(which, arg0, 0, 0)
+#define SBI_CALL_2(which, arg0, arg1) SBI_CALL(which, arg0, arg1, 0)
+
+static inline void sbi_console_putchar(int ch)
+{
+   SBI_CALL_1(SBI_CONSOLE_PUTCHAR, ch);
+}
+
+static inline int sbi_console_getchar(void)
+{
+   return SBI_CALL_0(SBI_CONSOLE_GETCHAR);
+}
+
+static inline void sbi_set_timer(uint64_t stime_value)
+{
+#if __riscv_xlen == 32
+   SBI_CALL_2(SBI_SET_TIMER, stime_value, stime_value >> 32);
+#else
+   SBI_CALL_1(SBI_SET_TIMER, stime_value);
+#endif
+}
+
+static inline void sbi_shutdown(void)
+{
+   SBI_CALL_0(SBI_SHUTDOWN);
+}
+
+static inline void sbi_clear_ipi(void)
+{
+   SBI_CALL_0(SBI_CLEAR_IPI);
+}
+
+static inline void sbi_send_ipi(const unsigned long *hart_mask)
+{
+   SBI_CALL_1(SBI_SEND_IPI, hart_mask);
+}
+
+static inline void sbi_remote_fence_i(const unsigned long *hart_mask)
+{
+   SBI_CALL_1(SBI_REMOTE_FENCE_I, hart_mask);
+}
+
+static inline void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+unsigned long start,
+unsigned long size)
+{
+   SBI_CALL_1(SBI_REMOTE_SFENCE_VMA, hart_mask);
+}
+
+static inline void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+ unsigned long start,
+ unsigned long size,
+ unsigned long asid)
+{
+   SBI_CALL_1(SBI_REMOTE_SFENCE_VMA_ASID, hart_mask);
+}
+
+#endif



Reviewed-by: Atish Patra 

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

Re: [U-Boot] [PATCH v2 1/9] riscv: add infrastructure for calling functions on other harts

[Atish Patra]

On 3/5/19 2:54 PM, Lukas Auer wrote:

Harts on RISC-V boot independently, U-Boot is responsible for managing
them. Functions are called on other harts with smp_call_function(),
which sends inter-processor interrupts (IPIs) to all other available
harts. Available harts are those marked as available in the device tree
and present in the available_harts mask stored in global data. The
available_harts mask is used to register all harts that have entered
U-Boot. Functions are specified with their address and two function
arguments (argument 2 and 3). The first function argument is always the
hart ID of the hart calling the function. On the other harts, the IPI
interrupt handler handle_ipi() must be called on software interrupts to
handle the request and call the specified function.

Functions are stored in the ipi_data data structure. Every hart has its
own data structure in global data. While this is not required at the
moment (all harts are expected to boot Linux), this does allow future
expansion, where other harts may be used for monitoring or other tasks.

Signed-off-by: Lukas Auer 
---

Changes in v2:
- Remove unneeded quotes from NR_CPUS Kconfig entry
- Move memory barrier from send_ipi_many() to handle_ipi()
- Add check in send_ipi_many so that IPIs are only sent to available
harts as indicated by the available_harts mask

  arch/riscv/Kconfig   |  19 +
  arch/riscv/include/asm/global_data.h |   6 ++
  arch/riscv/include/asm/smp.h |  53 
  arch/riscv/lib/Makefile  |   1 +
  arch/riscv/lib/smp.c | 116 +++
  5 files changed, 195 insertions(+)
  create mode 100644 arch/riscv/include/asm/smp.h
  create mode 100644 arch/riscv/lib/smp.c

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 36512a8995..4d7a115569 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -120,4 +120,23 @@ config RISCV_RDTIME
  config SYS_MALLOC_F_LEN
default 0x1000
  
+config SMP

+   bool "Symmetric Multi-Processing"
+   help
+ This enables support for systems with more than one CPU. If
+ you say N here, U-Boot will run on single and multiprocessor
+ machines, but will use only one CPU of a multiprocessor
+ machine. If you say Y here, U-Boot will run on many, but not
+ all, single processor machines.
+
+config NR_CPUS
+   int "Maximum number of CPUs (2-32)"
+   range 2 32
+   depends on SMP
+   default 8
+   help
+ On multiprocessor machines, U-Boot sets up a stack for each CPU.
+ Stack memory is pre-allocated. U-Boot must therefore know the
+ maximum number of CPUs that may be present.
+
  endmenu
diff --git a/arch/riscv/include/asm/global_data.h 
b/arch/riscv/include/asm/global_data.h
index a3a342c6e1..80e3165e39 100644
--- a/arch/riscv/include/asm/global_data.h
+++ b/arch/riscv/include/asm/global_data.h
@@ -10,12 +10,18 @@
  #ifndef   __ASM_GBL_DATA_H
  #define __ASM_GBL_DATA_H
  
+#include 

+
  /* Architecture-specific global data */
  struct arch_global_data {
long boot_hart; /* boot hart id */
  #ifdef CONFIG_SIFIVE_CLINT
void __iomem *clint;/* clint base address */
  #endif
+#ifdef CONFIG_SMP
+   struct ipi_data ipi[CONFIG_NR_CPUS];
+#endif
+   ulong available_harts;
  };
  
  #include 

diff --git a/arch/riscv/include/asm/smp.h b/arch/riscv/include/asm/smp.h
new file mode 100644
index 00..bc863fdbaf
--- /dev/null
+++ b/arch/riscv/include/asm/smp.h
@@ -0,0 +1,53 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019 Fraunhofer AISEC,
+ * Lukas Auer 
+ */
+
+#ifndef _ASM_RISCV_SMP_H
+#define _ASM_RISCV_SMP_H
+
+/**
+ * struct ipi_data - Inter-processor interrupt (IPI) data structure
+ *
+ * IPIs are used for SMP support to communicate to other harts what function to
+ * call. Functions are in the form
+ * void (*addr)(ulong hart, ulong arg0, ulong arg1).
+ *
+ * The function address and the two arguments, arg0 and arg1, are stored in the
+ * IPI data structure. The hart ID is inserted by the hart handling the IPI and
+ * calling the function.
+ *
+ * @addr: Address of function
+ * @arg0: First argument of function
+ * @arg1: Second argument of function
+ */
+struct ipi_data {
+   ulong addr;
+   ulong arg0;
+   ulong arg1;
+};
+
+/**
+ * handle_ipi() - interrupt handler for software interrupts
+ *
+ * The IPI interrupt handler must be called to handle software interrupts. It
+ * calls the function specified in the hart's IPI data structure.
+ *
+ * @hart: Hart ID of the current hart
+ */
+void handle_ipi(ulong hart);
+
+/**
+ * smp_call_function() - Call a function on all other harts
+ *
+ * Send IPIs with the specified function call to all harts.
+ *
+ * @addr: Address of function
+ * @arg0: First argument of function
+ * @arg1: Second argument of function
+ * @return 0 if OK, -ve on error
+ */
+int smp_call_function(ulong addr, ulong arg0, ulong 

[U-Boot] [PATCH] i2c: rcar_iic: Read ICSR only once

[Marek Vasut]

Read ICSR only once to avoid missing interrupts. This happens on R8A7791
Porter during reset, when reading the PMIC register 0x13, which may fail
sometimes because of the missed DTE interrupt.

Signed-off-by: Marek Vasut 
Cc: Heiko Schocher 
Cc: Nobuhiro Iwamatsu 
---
 drivers/i2c/rcar_iic.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/rcar_iic.c b/drivers/i2c/rcar_iic.c
index e91fc86c1a..9d45f547d1 100644
--- a/drivers/i2c/rcar_iic.c
+++ b/drivers/i2c/rcar_iic.c
@@ -58,12 +58,14 @@ static void sh_irq_dte(struct udevice *dev)
 static int sh_irq_dte_with_tack(struct udevice *dev)
 {
struct rcar_iic_priv *priv = dev_get_priv(dev);
+   u8 icsr;
int i;
 
for (i = 0; i < IRQ_WAIT; i++) {
-   if (RCAR_IC_DTE & readb(priv->base + RCAR_IIC_ICSR))
+   icsr = readb(priv->base + RCAR_IIC_ICSR);
+   if (RCAR_IC_DTE & icsr)
break;
-   if (RCAR_IC_TACK & readb(priv->base + RCAR_IIC_ICSR))
+   if (RCAR_IC_TACK & icsr)
return -ETIMEDOUT;
udelay(10);
}
-- 
2.20.1

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

[U-Boot] [U-Boot, V3, PATCH 3/3] mips: fix erros on registers macros of pll-ddr-config1-nfrac for QCA956X

[rosysong]

From: Rosy Song 

 See details in chapter 8.6.2 and 8.6.4 (page 140-141) of qca9563 datasheet,

   NFRAC[17:0]

 So the mask of [17:5] is 0x1fff not 0x3fff.

Signed-off-by: Rosy Song 

Changes for v2-v3:
   - add more information for this commit
---
 arch/mips/mach-ath79/include/mach/ar71xx_regs.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/mips/mach-ath79/include/mach/ar71xx_regs.h 
b/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
index 7cd16b8d81..5888f6eb28 100644
--- a/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
+++ b/arch/mips/mach-ath79/include/mach/ar71xx_regs.h
@@ -554,7 +554,7 @@
 #define QCA956X_PLL_CPU_CONFIG1_NFRAC_L_SHIFT  0
 #define QCA956X_PLL_CPU_CONFIG1_NFRAC_L_MASK   0x1f
 #define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_SHIFT  5
-#define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK   0x3fff
+#define QCA956X_PLL_CPU_CONFIG1_NFRAC_H_MASK   0x1fff
 #define QCA956X_PLL_CPU_CONFIG1_NINT_SHIFT 18
 #define QCA956X_PLL_CPU_CONFIG1_NINT_MASK  0x1ff
 
@@ -566,7 +566,7 @@
 #define QCA956X_PLL_DDR_CONFIG1_NFRAC_L_SHIFT  0
 #define QCA956X_PLL_DDR_CONFIG1_NFRAC_L_MASK   0x1f
 #define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_SHIFT  5
-#define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK   0x3fff
+#define QCA956X_PLL_DDR_CONFIG1_NFRAC_H_MASK   0x1fff
 #define QCA956X_PLL_DDR_CONFIG1_NINT_SHIFT 18
 #define QCA956X_PLL_DDR_CONFIG1_NINT_MASK  0x1ff
 
-- 
2.17.1

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

[U-Boot] [U-Boot, V3, PATCH 2/3] mips: add initial support for qca956x referenced board

[rosysong]

From: Rosy Song 

QCA9563 is CPU used on AP152 board :

Clock speed : 750 MHz ,
Arch :  Mips 74Kc,
Eth : SGMII interface,
MIMO config : 3 * 3 450M,
2 * USB 2.0,

Signed-off-by: Rosy Song 

Changes for v2:
   - coding Style cleanup
   - remove ununsed flash chip in defconfig
   - enable automatic icache / dcache size in defconfig

Changes for v3:
   - add detailed information for qca956x in commit message
---
 arch/mips/dts/Makefile|   1 +
 arch/mips/dts/ap152.dts   |  48 ++
 arch/mips/dts/qca956x.dtsi|  87 
 arch/mips/mach-ath79/Kconfig  |  14 +
 arch/mips/mach-ath79/Makefile |   1 +
 .../mach-ath79/include/mach/ar71xx_regs.h |  73 +++
 arch/mips/mach-ath79/include/mach/ath79.h |   3 +
 arch/mips/mach-ath79/qca956x/Makefile |   5 +
 arch/mips/mach-ath79/qca956x/clk.c| 419 ++
 arch/mips/mach-ath79/qca956x/cpu.c|   9 +
 arch/mips/mach-ath79/qca956x/ddr.c| 308 +
 .../mips/mach-ath79/qca956x/qca956x-ddr-tap.S | 193 
 arch/mips/mach-ath79/reset.c  | 271 +++
 board/qca/ap152/Kconfig   |  15 +
 board/qca/ap152/MAINTAINERS   |   6 +
 board/qca/ap152/Makefile  |   3 +
 board/qca/ap152/ap152.c   |  81 
 configs/ap152_defconfig   |  49 ++
 include/configs/ap152.h   |  54 +++
 19 files changed, 1640 insertions(+)
 create mode 100644 arch/mips/dts/ap152.dts
 create mode 100644 arch/mips/dts/qca956x.dtsi
 create mode 100644 arch/mips/mach-ath79/qca956x/Makefile
 create mode 100644 arch/mips/mach-ath79/qca956x/clk.c
 create mode 100644 arch/mips/mach-ath79/qca956x/cpu.c
 create mode 100644 arch/mips/mach-ath79/qca956x/ddr.c
 create mode 100644 arch/mips/mach-ath79/qca956x/qca956x-ddr-tap.S
 create mode 100644 board/qca/ap152/Kconfig
 create mode 100644 board/qca/ap152/MAINTAINERS
 create mode 100644 board/qca/ap152/Makefile
 create mode 100644 board/qca/ap152/ap152.c
 create mode 100644 configs/ap152_defconfig
 create mode 100644 include/configs/ap152.h

diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
index b94b582837..621c35f0ef 100644
--- a/arch/mips/dts/Makefile
+++ b/arch/mips/dts/Makefile
@@ -2,6 +2,7 @@
 
 dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
 dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
+dtb-$(CONFIG_TARGET_AP152) += ap152.dtb
 dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
 dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
 dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
diff --git a/arch/mips/dts/ap152.dts b/arch/mips/dts/ap152.dts
new file mode 100644
index 00..1722290c73
--- /dev/null
+++ b/arch/mips/dts/ap152.dts
@@ -0,0 +1,48 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Rosy Song 
+ */
+
+/dts-v1/;
+#include "qca956x.dtsi"
+
+/ {
+   model = "AP152 Reference Board";
+   compatible = "qca,ap152", "qca,qca956x";
+
+   aliases {
+   spi0 = 
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+};
+
+ {
+   phy-mode = "sgmii";
+   status = "okay";
+};
+
+ {
+   clock-frequency = <2500>;
+};
+
+ {
+   clock-frequency = <2500>;
+   status = "okay";
+};
+
+ {
+   spi-max-frequency = <2500>;
+   status = "okay";
+   spi-flash@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   memory-map = <0x9f00 0x0100>;
+   spi-max-frequency = <2500>;
+   reg = <0>;
+   };
+};
diff --git a/arch/mips/dts/qca956x.dtsi b/arch/mips/dts/qca956x.dtsi
new file mode 100644
index 00..6cb360b3f8
--- /dev/null
+++ b/arch/mips/dts/qca956x.dtsi
@@ -0,0 +1,87 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2018 Rosy Song 
+ */
+
+#include "skeleton.dtsi"
+
+/ {
+   compatible = "qca,qca956x";
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "mips,mips74Kc";
+   reg = <0>;
+   };
+   };
+
+   clocks {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   xtal: xtal {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-output-names = "xtal";
+   };
+   };
+
+   ahb {
+   compatible = "simple-bus";
+   ranges;
+
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   apb {
+   compatible = "simple-bus";
+   

[U-Boot] [U-Boot, V3, PATCH 1/3] ag7xxx: add initial support for s17

[rosysong]

From: Rosy Song 

S17 ethernet support is for QCA8337N, which used on
AP152 (QCA9563) board. It is a 7 ports GbE switch.

Signed-off-by: Rosy Song 

Changes for v2-v3:
   - add more commit message for s17
---
 drivers/net/ag7xxx.c | 140 ++-
 1 file changed, 124 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
index 403eb64895..b3b53205fa 100644
--- a/drivers/net/ag7xxx.c
+++ b/drivers/net/ag7xxx.c
@@ -3,6 +3,7 @@
  * Atheros AR71xx / AR9xxx GMAC driver
  *
  * Copyright (C) 2016 Marek Vasut 
+ * Copyright (C) 2019 Rosy Song 
  */
 
 #include 
@@ -23,7 +24,8 @@ DECLARE_GLOBAL_DATA_PTR;
 enum ag7xxx_model {
AG7XXX_MODEL_AG933X,
AG7XXX_MODEL_AG934X,
-   AG7XXX_MODEL_AG953X
+   AG7XXX_MODEL_AG953X,
+   AG7XXX_MODEL_AG956X
 };
 
 /* MAC Configuration 1 */
@@ -219,6 +221,7 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, int 
reg, u32 *val)
u32 reg_addr;
u32 phy_temp;
u32 reg_temp;
+   u32 reg_temp_w = (reg & 0xfffc) >> 1;
u16 rv = 0;
int ret;
 
@@ -226,18 +229,25 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, 
int reg, u32 *val)
priv->model == AG7XXX_MODEL_AG953X) {
phy_addr = 0x1f;
reg_addr = 0x10;
-   } else if (priv->model == AG7XXX_MODEL_AG934X) {
+   } else if (priv->model == AG7XXX_MODEL_AG934X ||
+  priv->model == AG7XXX_MODEL_AG956X) {
phy_addr = 0x18;
reg_addr = 0x00;
} else
return -EINVAL;
 
-   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, (reg >> 9) & 
0x1ff);
+   } else
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
if (ret)
return ret;
 
phy_temp = ((reg >> 6) & 0x7) | 0x10;
-   reg_temp = (reg >> 1) & 0x1e;
+   if (priv->model == AG7XXX_MODEL_AG956X)
+   reg_temp = reg_temp_w & 0x1f;
+   else
+   reg_temp = (reg >> 1) & 0x1e;
*val = 0;
 
ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 0, );
@@ -245,7 +255,13 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, int 
reg, u32 *val)
return ret;
*val |= rv;
 
-   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 1, );
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   phy_temp = (((reg_temp_w + 1) >> 5) & 0x7) | 0x10;
+   reg_temp = (reg_temp_w + 1) & 0x1f;
+   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp, );
+   } else {
+   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 1, );
+   }
if (ret < 0)
return ret;
*val |= (rv << 16);
@@ -260,24 +276,35 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus, 
int reg, u32 val)
u32 reg_addr;
u32 phy_temp;
u32 reg_temp;
+   u32 reg_temp_w = (reg & 0xfffc) >> 1;
int ret;
 
if (priv->model == AG7XXX_MODEL_AG933X ||
priv->model == AG7XXX_MODEL_AG953X) {
phy_addr = 0x1f;
reg_addr = 0x10;
-   } else if (priv->model == AG7XXX_MODEL_AG934X) {
+   } else if (priv->model == AG7XXX_MODEL_AG934X ||
+  priv->model == AG7XXX_MODEL_AG956X) {
phy_addr = 0x18;
reg_addr = 0x00;
} else
return -EINVAL;
 
-   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
+   if (priv->model == AG7XXX_MODEL_AG956X)
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, (reg >> 9) & 
0x1ff);
+   else
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
if (ret)
return ret;
 
-   phy_temp = ((reg >> 6) & 0x7) | 0x10;
-   reg_temp = (reg >> 1) & 0x1e;
+
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   reg_temp = (reg_temp_w + 1) & 0x1f;
+   phy_temp = (((reg_temp_w + 1) >> 5) & 0x7) | 0x10;
+   } else {
+   phy_temp = ((reg >> 6) & 0x7) | 0x10;
+   reg_temp = (reg >> 1) & 0x1e;
+   }
 
/*
 * The switch on AR933x has some special register behavior, which
@@ -296,10 +323,18 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus, 
int reg, u32 val)
if (ret < 0)
return ret;
} else {
-   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp | 1, val >> 
16);
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp, val 
>> 16);
+   } else
+   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp | 1, 
val >> 16);
if (ret < 0)
return 

[U-Boot] [PATCH 1/3] ag7xxx: add initial support for s17

[rosysong]

From: Rosy Song 

S17 ethernet support is for QCA8337N, which used on
AP152 (QCA9563) board. It is a 7 ports GbE switch.

Signed-off-by: Rosy Song 

Changes for v2-v3:
   - add more commit message for s17
---
 drivers/net/ag7xxx.c | 140 ++-
 1 file changed, 124 insertions(+), 16 deletions(-)

diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
index 403eb64895..b3b53205fa 100644
--- a/drivers/net/ag7xxx.c
+++ b/drivers/net/ag7xxx.c
@@ -3,6 +3,7 @@
  * Atheros AR71xx / AR9xxx GMAC driver
  *
  * Copyright (C) 2016 Marek Vasut 
+ * Copyright (C) 2019 Rosy Song 
  */
 
 #include 
@@ -23,7 +24,8 @@ DECLARE_GLOBAL_DATA_PTR;
 enum ag7xxx_model {
AG7XXX_MODEL_AG933X,
AG7XXX_MODEL_AG934X,
-   AG7XXX_MODEL_AG953X
+   AG7XXX_MODEL_AG953X,
+   AG7XXX_MODEL_AG956X
 };
 
 /* MAC Configuration 1 */
@@ -219,6 +221,7 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, int 
reg, u32 *val)
u32 reg_addr;
u32 phy_temp;
u32 reg_temp;
+   u32 reg_temp_w = (reg & 0xfffc) >> 1;
u16 rv = 0;
int ret;
 
@@ -226,18 +229,25 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, 
int reg, u32 *val)
priv->model == AG7XXX_MODEL_AG953X) {
phy_addr = 0x1f;
reg_addr = 0x10;
-   } else if (priv->model == AG7XXX_MODEL_AG934X) {
+   } else if (priv->model == AG7XXX_MODEL_AG934X ||
+  priv->model == AG7XXX_MODEL_AG956X) {
phy_addr = 0x18;
reg_addr = 0x00;
} else
return -EINVAL;
 
-   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, (reg >> 9) & 
0x1ff);
+   } else
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
if (ret)
return ret;
 
phy_temp = ((reg >> 6) & 0x7) | 0x10;
-   reg_temp = (reg >> 1) & 0x1e;
+   if (priv->model == AG7XXX_MODEL_AG956X)
+   reg_temp = reg_temp_w & 0x1f;
+   else
+   reg_temp = (reg >> 1) & 0x1e;
*val = 0;
 
ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 0, );
@@ -245,7 +255,13 @@ static int ag7xxx_switch_reg_read(struct mii_dev *bus, int 
reg, u32 *val)
return ret;
*val |= rv;
 
-   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 1, );
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   phy_temp = (((reg_temp_w + 1) >> 5) & 0x7) | 0x10;
+   reg_temp = (reg_temp_w + 1) & 0x1f;
+   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp, );
+   } else {
+   ret = ag7xxx_switch_read(bus, phy_temp, reg_temp | 1, );
+   }
if (ret < 0)
return ret;
*val |= (rv << 16);
@@ -260,24 +276,35 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus, 
int reg, u32 val)
u32 reg_addr;
u32 phy_temp;
u32 reg_temp;
+   u32 reg_temp_w = (reg & 0xfffc) >> 1;
int ret;
 
if (priv->model == AG7XXX_MODEL_AG933X ||
priv->model == AG7XXX_MODEL_AG953X) {
phy_addr = 0x1f;
reg_addr = 0x10;
-   } else if (priv->model == AG7XXX_MODEL_AG934X) {
+   } else if (priv->model == AG7XXX_MODEL_AG934X ||
+  priv->model == AG7XXX_MODEL_AG956X) {
phy_addr = 0x18;
reg_addr = 0x00;
} else
return -EINVAL;
 
-   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
+   if (priv->model == AG7XXX_MODEL_AG956X)
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, (reg >> 9) & 
0x1ff);
+   else
+   ret = ag7xxx_switch_write(bus, phy_addr, reg_addr, reg >> 9);
if (ret)
return ret;
 
-   phy_temp = ((reg >> 6) & 0x7) | 0x10;
-   reg_temp = (reg >> 1) & 0x1e;
+
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   reg_temp = (reg_temp_w + 1) & 0x1f;
+   phy_temp = (((reg_temp_w + 1) >> 5) & 0x7) | 0x10;
+   } else {
+   phy_temp = ((reg >> 6) & 0x7) | 0x10;
+   reg_temp = (reg >> 1) & 0x1e;
+   }
 
/*
 * The switch on AR933x has some special register behavior, which
@@ -296,10 +323,18 @@ static int ag7xxx_switch_reg_write(struct mii_dev *bus, 
int reg, u32 val)
if (ret < 0)
return ret;
} else {
-   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp | 1, val >> 
16);
+   if (priv->model == AG7XXX_MODEL_AG956X) {
+   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp, val 
>> 16);
+   } else
+   ret = ag7xxx_switch_write(bus, phy_temp, reg_temp | 1, 
val >> 16);
if (ret < 0)
return 

Re: [U-Boot] [PATCH] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

[Marek Vasut]

On 3/6/19 6:55 PM, Eugeniu Rosca wrote:
> v2019.01 commit cbff9f80cedd ("ARM: dts: rmobile: Sync Gen3 DTs with
> Linux 4.19.6") made the sdhi/usb nodes available in r8a77965.dtsi.
> 
> Hence, remove the SDHI/USB nodes from r8a77965-u-boot.dtsi. This is
> equivalent to partially reverting below v2019.01 commits:
>  - f529bc551b6d ("ARM: dts: rmobile: Extract USB nodes on M3N")
>  - 830b94f76867 ("ARM: dts: rmobile: Extract SDHI nodes on M3N")
> 
> Not doing that results in MMC devices being undetected on M3NULCB:

M3N ULCB is not supported yet, so how can this be broken ?

I am planning to add support for it [1], however that is work in
progress and the patches still need more work. Can you rebase your
changes on top of that branch and if you have M3N ULCB, test it ?
The branch also contains sync with Linux 5.0 DTs, however it is also
work in progress and there's likely to be breakage.

[1] https://github.com/marex/u-boot-sh/tree/m3nulcb-v1

>  => mmc list
>  No MMC device available
> 
> Signed-off-by: Eugeniu Rosca 
> ---
>  arch/arm/dts/r8a77965-u-boot.dtsi | 99 ---
>  1 file changed, 99 deletions(-)
> 
> diff --git a/arch/arm/dts/r8a77965-u-boot.dtsi 
> b/arch/arm/dts/r8a77965-u-boot.dtsi
> index cbd29b3aed68..ca80ef8f29ee 100644
> --- a/arch/arm/dts/r8a77965-u-boot.dtsi
> +++ b/arch/arm/dts/r8a77965-u-boot.dtsi
> @@ -19,103 +19,4 @@
>   bank-width = <2>;
>   status = "disabled";
>   };
> -
> - sdhi0: sd@ee10 {
> - compatible = "renesas,sdhi-r8a77965";
> - reg = <0 0xee10 0 0x2000>;
> - interrupts = ;
> - clocks = < CPG_MOD 314>;
> - max-frequency = <2>;
> - power-domains = < 32>;
> - resets = < 314>;
> - status = "disabled";
> - };
> -
> - sdhi1: sd@ee12 {
> - compatible = "renesas,sdhi-r8a77965";
> - reg = <0 0xee12 0 0x2000>;
> - interrupts = ;
> - clocks = < CPG_MOD 313>;
> - max-frequency = <2>;
> - power-domains = < 32>;
> - resets = < 313>;
> - status = "disabled";
> - };
> -
> - sdhi2: sd@ee14 {
> - compatible = "renesas,sdhi-r8a77965";
> - reg = <0 0xee14 0 0x2000>;
> - interrupts = ;
> - clocks = < CPG_MOD 312>;
> - max-frequency = <2>;
> - power-domains = < 32>;
> - resets = < 312>;
> - status = "disabled";
> - };
> -
> - sdhi3: sd@ee16 {
> - compatible = "renesas,sdhi-r8a77965";
> - reg = <0 0xee16 0 0x2000>;
> - interrupts = ;
> - clocks = < CPG_MOD 311>;
> - max-frequency = <2>;
> - power-domains = < 32>;
> - resets = < 311>;
> - status = "disabled";
> - };
> -
> - ehci0: usb@ee080100 {
> - compatible = "generic-ehci";
> - reg = <0 0xee080100 0 0x100>;
> - interrupts = ;
> - clocks = < CPG_MOD 703>;
> - phys = <_phy0>;
> - phy-names = "usb";
> - companion= <>;
> - power-domains = < 32>;
> - resets = < 703>;
> - };
> -
> - usb2_phy0: usb-phy@ee080200 {
> - compatible = "renesas,usb2-phy-r8a77965",
> -  "renesas,rcar-gen3-usb2-phy";
> - reg = <0 0xee080200 0 0x700>;
> - interrupts = ;
> - clocks = < CPG_MOD 703>;
> - power-domains = < 32>;
> - resets = < 703>;
> - #phy-cells = <0>;
> - };
> -
> - ehci1: usb@ee0a0100 {
> - compatible = "generic-ehci";
> - reg = <0 0xee0a0100 0 0x100>;
> - interrupts = ;
> - clocks = < CPG_MOD 702>;
> - phys = <_phy1>;
> - phy-names = "usb";
> - companion= <>;
> - power-domains = < 32>;
> - resets = < 702>;
> - };
> -
> - usb2_phy1: usb-phy@ee0a0200 {
> - compatible = "renesas,usb2-phy-r8a77965",
> -  "renesas,rcar-gen3-usb2-phy";
> - reg = <0 0xee0a0200 0 0x700>;
> - clocks = < CPG_MOD 702>;
> - power-domains = < 32>;
> - resets = < 702>;
> - #phy-cells = <0>;
> - };
> -
> - xhci0: usb@ee00 {
> - compatible = "renesas,xhci-r8a77965",
> -  "renesas,rcar-gen3-xhci";
> - reg = <0 0xee00 0 0xc00>;
> - interrupts = ;
> - clocks = < CPG_MOD 328>;
> - power-domains = < 32>;
> - resets = < 328>;
> - };
>  };
> 


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

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Atish Patra]

On 3/6/19 4:32 AM, Anup Patel wrote:

On Wed, Mar 6, 2019 at 5:45 PM Auer, Lukas
 wrote:


On Wed, 2019-03-06 at 13:01 +0100, Andreas Schwab wrote:

On Mär 06 2019, Anup Patel  wrote:


On Wed, Mar 6, 2019 at 5:17 PM Andreas Schwab 
wrote:

On Mär 06 2019, Anup Patel  wrote:


-Original Message-
From: Andreas Schwab 
Sent: Wednesday, March 6, 2019 4:27 PM
To: Anup Patel 
Cc: Auer, Lukas ;
u-boot@lists.denx.de;
paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
bar...@tkos.co.il; daniel.schwierz...@gmail.com;
bmeng...@gmail.com;
r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish
Patra

Subject: Re: [PATCH v2 0/9] SMP support for RISC-V

Apparently sometimes u-boot tries to boot the kernel on heart
0 (the E51
core), which will then fail to start userspace, since that
cannot cope with the
missing fpu.


That's not possible


Yes, it is.


OpenSBI v0.3 (Mar  6 2019 10:55:01)
_  _
   / __ \  / |  _ \_   _|
  | |  | |_ __   ___ _ __ | (___ | |_) || |
  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
  | |__| | |_) |  __/ | | |) | |_) || |_
   \/| .__/ \___|_| |_|_/|/_|
 | |
 |_|

Platform Name  : SiFive Freedom U540
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 5
Current Hart   : 2
Firmware Base  : 0x8000
Firmware Size  : 88 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x007f (A,R,W,X)


U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10
+0100)

CPU:   rv64imac
Model: sifive,hifive-unleashed-a00
DRAM:  8 GiB


How does this prove that U-Boot is booting on HART 0?


See the CPU isa.



Interesting.. U-Boot assumes that it can run on any core it is started
on. In this case, OpenSBI must have booted its payload on hart 0.


This is certainly not reproducible on cold-boot at my end but this
does mean OpenSBI has booted HART0 and let it jump to U-Boot.

Now OpenSBI (by default) on SiFive FU540 does not allow HART0
to go forward due to lack of S-mode. I think this is definitely the
warm-boot issue where OpenSBI sees corrupted memory contents.



I am able to test both warm-boot and cold-boot several times(>10) 
without any issue with following pending PR in openSBI.


https://github.com/riscv/opensbi/pull/84

@Andreas @Anup: Can you please apply the above PR on top of master and 
verify at your end as well?


All the harts booted in Linux every time as well.

Regards,
Atish

Regards,
Anup



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

Re: [U-Boot] [PATCH 2/4] board: mscc: jr2: Update MSCC Jaguar2 boards

[Horatiu Vultur]

Hi Daniel,

The 03/06/2019 14:19, Daniel Schwierzeck wrote:
> 
> 
> Am 05.03.19 um 12:57 schrieb Horatiu Vultur:
> > In Jaguar2 SoC family there are 3 different pcb. Each of this needs
> > to configure the SerDes and the phys in different ways.
> > Therefore implement the function board_phy_config and serdes_cfg
> > and based on pcb configure them accordingly.
> 
> what are the differences between all boards? Can't you model the
> different register values somehow as custom DT properties? This method
> looks like a lot of code duplication and doesn't scale well when adding
> new boards.

So there are following boards:
 - pcb110: it has viper phys that are connected to serdes1g using the
   interface sgmii
 - pcb111: it has atom phys that are connected to serdes6g using the
   interface qsgmii
 - pcb112: it has viper phys that are connected to serdes6g using the
   interface sgmii.

Do you have an example where I can look, how to add this custom
properties?

Yes, it looks like a lot code duplication, but there are only few
differences between them. I was thinking maybe I can create 2 functions
that configure the serdes1g and serdes6g which will get as a paramenter
the interface mode. In this way I think it would scale better, because
then each new board it would just call these new functions.

/Horatiu

> 
> > 
> > Signed-off-by: Horatiu Vultur 
> > ---
> >  board/mscc/jr2/jr2.c | 542 
> > +++
> >  1 file changed, 542 insertions(+)
> > 
> > diff --git a/board/mscc/jr2/jr2.c b/board/mscc/jr2/jr2.c
> > index 58a4a04..94e0c5d 100644
> > --- a/board/mscc/jr2/jr2.c
> > +++ b/board/mscc/jr2/jr2.c
> > @@ -6,6 +6,140 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +
> > +#define HSIO_ANA_SERDES1G_DES_CFG  0xac
> > +#defineHSIO_ANA_SERDES1G_DES_CFG_BW_HYST(x)((x) << 
> > 1)
> > +#defineHSIO_ANA_SERDES1G_DES_CFG_BW_ANA(x) ((x) << 
> > 5)
> > +#defineHSIO_ANA_SERDES1G_DES_CFG_MBTR_CTRL(x)  ((x) << 
> > 8)
> > +#defineHSIO_ANA_SERDES1G_DES_CFG_PHS_CTRL(x)   ((x) << 
> > 13)
> > +#define HSIO_ANA_SERDES1G_IB_CFG   0xb0
> > +#defineHSIO_ANA_SERDES1G_IB_CFG_RESISTOR_CTRL(x)   (x)
> > +#defineHSIO_ANA_SERDES1G_IB_CFG_EQ_GAIN(x) ((x) << 
> > 6)
> > +#defineHSIO_ANA_SERDES1G_IB_CFG_ENA_OFFSET_COMPBIT(9)
> > +#defineHSIO_ANA_SERDES1G_IB_CFG_ENA_DETLEV BIT(11)
> > +#defineHSIO_ANA_SERDES1G_IB_CFG_ENA_CMV_TERM   BIT(13)
> > +#defineHSIO_ANA_SERDES1G_IB_CFG_DET_LEV(x) ((x) << 
> > 19)
> > +#defineHSIO_ANA_SERDES1G_IB_CFG_ACJTAG_HYST(x) ((x) << 
> > 24)
> > +#define HSIO_ANA_SERDES1G_OB_CFG   0xb4
> > +#defineHSIO_ANA_SERDES1G_OB_CFG_RESISTOR_CTRL(x)   (x)
> > +#defineHSIO_ANA_SERDES1G_OB_CFG_VCM_CTRL(x)((x) << 
> > 4)
> > +#defineHSIO_ANA_SERDES1G_OB_CFG_CMM_BIAS_CTRL(x)   ((x) << 
> > 10)
> > +#defineHSIO_ANA_SERDES1G_OB_CFG_AMP_CTRL(x)((x) << 
> > 13)
> > +#defineHSIO_ANA_SERDES1G_OB_CFG_SLP(x) ((x) << 
> > 17)
> > +#define HSIO_ANA_SERDES1G_SER_CFG  0xb8
> > +#define HSIO_ANA_SERDES1G_COMMON_CFG   0xbc
> > +#defineHSIO_ANA_SERDES1G_COMMON_CFG_IF_MODEBIT(0)
> > +#defineHSIO_ANA_SERDES1G_COMMON_CFG_ENA_LANE   BIT(18)
> > +#defineHSIO_ANA_SERDES1G_COMMON_CFG_SYS_RSTBIT(31)
> > +#define HSIO_ANA_SERDES1G_PLL_CFG  0xc0
> > +#defineHSIO_ANA_SERDES1G_PLL_CFG_FSM_ENA   BIT(7)
> > +#defineHSIO_ANA_SERDES1G_PLL_CFG_FSM_CTRL_DATA(x)  ((x) << 
> > 8)
> > +#defineHSIO_ANA_SERDES1G_PLL_CFG_ENA_RC_DIV2   BIT(21)
> > +#define HSIO_DIG_SERDES1G_DFT_CFG0 0xc8
> > +#define HSIO_DIG_SERDES1G_TP_CFG   0xd4
> > +#define HSIO_DIG_SERDES1G_MISC_CFG 0xdc
> > +#defineHSIO_DIG_SERDES1G_MISC_CFG_LANE_RST BIT(0)
> > +#define HSIO_MCB_SERDES1G_CFG  0xe8
> > +#defineHSIO_MCB_SERDES1G_CFG_WR_ONE_SHOT   BIT(31)
> > +#defineHSIO_MCB_SERDES1G_CFG_ADDR(x)   (x)
> > +
> > +#define HSIO_ANA_SERDES6G_DES_CFG  0x11c
> > +#defineHSIO_ANA_SERDES6G_DES_CFG_SWAP_ANA  BIT(0)
> > +#defineHSIO_ANA_SERDES6G_DES_CFG_BW_ANA(x) ((x) << 
> > 1)
> > +#defineHSIO_ANA_SERDES6G_DES_CFG_SWAP_HYST BIT(4)
> > +#defineHSIO_ANA_SERDES6G_DES_CFG_BW_HYST(x)((x) << 
> > 5)
> > +#defineHSIO_ANA_SERDES6G_DES_CFG_CPMD_SEL(x)   ((x) << 
> > 8)
> > +#defineHSIO_ANA_SERDES6G_DES_CFG_MBTR_CTRL(x)  ((x) << 
> > 10)
> > +#define

[U-Boot] [PATCH 3/4] ARM: socfpga: Fix Arria10 SPI and NAND U-Boot offset

[Marek Vasut]

The SPL size on Gen5 is 4*64kiB, but on A10 it is 4*256kiB.
Handle the difference.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 include/configs/socfpga_common.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index f182e9e71b..181af9b646 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -275,12 +275,20 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 
 /* SPL QSPI boot support */
 #ifdef CONFIG_SPL_SPI_SUPPORT
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 #define CONFIG_SYS_SPI_U_BOOT_OFFS 0x4
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+#define CONFIG_SYS_SPI_U_BOOT_OFFS 0x10
+#endif
 #endif
 
 /* SPL NAND boot support */
 #ifdef CONFIG_SPL_NAND_SUPPORT
+#if defined(CONFIG_TARGET_SOCFPGA_GEN5)
 #define CONFIG_SYS_NAND_U_BOOT_OFFS0x4
+#elif defined(CONFIG_TARGET_SOCFPGA_ARRIA10)
+#define CONFIG_SYS_NAND_U_BOOT_OFFS0x10
+#endif
 #endif
 
 /*
-- 
2.20.1

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

[U-Boot] [PATCH 2/4] ARM: socfpga: Drop CONFIG_SYS_NAND_BAD_BLOCK_POS

[Marek Vasut]

This is not used anywhere, so drop it.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 include/configs/socfpga_common.h | 1 -
 1 file changed, 1 deletion(-)

diff --git a/include/configs/socfpga_common.h b/include/configs/socfpga_common.h
index c9cbf8f5e3..f182e9e71b 100644
--- a/include/configs/socfpga_common.h
+++ b/include/configs/socfpga_common.h
@@ -280,7 +280,6 @@ unsigned int cm_get_qspi_controller_clk_hz(void);
 
 /* SPL NAND boot support */
 #ifdef CONFIG_SPL_NAND_SUPPORT
-#define CONFIG_SYS_NAND_BAD_BLOCK_POS  0
 #define CONFIG_SYS_NAND_U_BOOT_OFFS0x4
 #endif
 
-- 
2.20.1

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

[U-Boot] [PATCH 1/4] ARM: socfpga: Disable D cache in SPL

[Marek Vasut]

The bootrom seems to leave the D-cache in messed up state, make sure
the SPL disables it so it can not interfere with operation.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 arch/arm/mach-socfpga/spl_a10.c | 2 ++
 include/configs/socfpga_arria10_socdk.h | 2 --
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/spl_a10.c b/arch/arm/mach-socfpga/spl_a10.c
index c97eacb424..c8e73d47c0 100644
--- a/arch/arm/mach-socfpga/spl_a10.c
+++ b/arch/arm/mach-socfpga/spl_a10.c
@@ -77,6 +77,8 @@ void spl_board_init(void)
 
 void board_init_f(ulong dummy)
 {
+   dcache_disable();
+
socfpga_init_security_policies();
socfpga_sdram_remap_zero();
 
diff --git a/include/configs/socfpga_arria10_socdk.h 
b/include/configs/socfpga_arria10_socdk.h
index 58e446b60a..0f116fbf2d 100644
--- a/include/configs/socfpga_arria10_socdk.h
+++ b/include/configs/socfpga_arria10_socdk.h
@@ -15,8 +15,6 @@
 /*
  * U-Boot general configurations
  */
-/* Cache options */
-#define CONFIG_SYS_DCACHE_OFF
 
 /* Memory configurations  */
 #define PHYS_SDRAM_1_SIZE  0x4000
-- 
2.20.1

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

[U-Boot] [PATCH 4/4] ARM: socfpga: Fix A10 SoCDK Kconfig

[Marek Vasut]

The Kconfig checked for SoCFPGA Arria10 as a platform, instead of
checking for specific board configuration, which works with one
single platform in tree, but not with multiple. Fix it.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 board/altera/arria10-socdk/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/altera/arria10-socdk/Kconfig 
b/board/altera/arria10-socdk/Kconfig
index b80cc6d6f9..621dc97024 100644
--- a/board/altera/arria10-socdk/Kconfig
+++ b/board/altera/arria10-socdk/Kconfig
@@ -1,4 +1,4 @@
-if TARGET_SOCFPGA_ARRIA10
+if TARGET_SOCFPGA_ARRIA10_SOCDK
 
 config SYS_CPU
default "armv7"
-- 
2.20.1

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

[U-Boot] [PATCH 1/2] ddr: socfpga: Fix IO in Arria10 DDR driver

[Marek Vasut]

The Altera Arria10 DDR driver was using constants in a few places
instead of reading registers associated with those constants, fix
this.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 drivers/ddr/altera/sdram_arria10.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/ddr/altera/sdram_arria10.c 
b/drivers/ddr/altera/sdram_arria10.c
index 29ea7492f3..6724eb29f1 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -304,7 +304,7 @@ static void sdram_mmr_init(void)
 *  bit[9:6] = Minor Release #
 *  bit[14:10] = Major Release #
 */
-   if ((socfpga_io48_mmr_base->niosreserve1 >> 6) & 0x1FF) {
+   if ((readl(_io48_mmr_base->niosreserve1) >> 6) & 0x1FF) {
update_value = readl(_io48_mmr_base->niosreserve0);
writel(((update_value & 0xFF) >> 5),
   _ecc_hmc_base->ddrioctrl);
@@ -394,7 +394,7 @@ static void sdram_mmr_init(void)
caltim0_cfg_act_to_rdwr -
(ctrlcfg0_cfg_ctrl_burst_len >> 2));
 
-   io48_value = socfpga_io48_mmr_base->dramtiming0 &
+   io48_value = readl(_io48_mmr_base->dramtiming0) &
  ALT_IO48_DRAMTIME_MEM_READ_LATENCY_MASK) + 2 + 15 +
  (ctrlcfg0_cfg_ctrl_burst_len >> 1)) >> 1) -
  /* Up to here was in memory cycles so divide by 2 */
@@ -424,7 +424,7 @@ static void sdram_mmr_init(void)
_noc_ddr_scheduler_base->ddr_t_main_scheduler_ddrmode);
 
/* Configure the read latency [0xFFD12414] */
-   writel(((socfpga_io48_mmr_base->dramtiming0 &
+   writel(((readl(_io48_mmr_base->dramtiming0) &
ALT_IO48_DRAMTIME_MEM_READ_LATENCY_MASK) >> 1) +
DDR_READ_LATENCY_DELAY,
_noc_ddr_scheduler_base->
-- 
2.20.1

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

[U-Boot] [PATCH 2/2] ddr: socfpga: Fix newline in debug print on A10

[Marek Vasut]

The debug print is missing a newline, add it.

Signed-off-by: Marek Vasut 
Cc: Chin Liang See 
Cc: Dinh Nguyen 
Cc: Simon Goldschmidt 
Cc: Tien Fong Chee 
---
 drivers/ddr/altera/sdram_arria10.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/ddr/altera/sdram_arria10.c 
b/drivers/ddr/altera/sdram_arria10.c
index 6724eb29f1..be5ce778e8 100644
--- a/drivers/ddr/altera/sdram_arria10.c
+++ b/drivers/ddr/altera/sdram_arria10.c
@@ -270,7 +270,7 @@ static u64 sdram_size_calc(void)
size *= (2 << (readl(_ecc_hmc_base->ddrioctrl) &
   ALT_ECC_HMC_OCP_DDRIOCTRL_IO_SIZE_MSK));
 
-   debug("SDRAM size=%llu", size);
+   debug("SDRAM size=%llu\n", size);
 
return size;
 }
-- 
2.20.1

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

[U-Boot] [PATCH] spl: ymodem: Add support for loading full fitImages

[Marek Vasut]

Add support for loading fully featured fitImages over YModem in SPL.
This is useful when various advanced features of full fitImages are
needed in SPL.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 common/spl/spl_ymodem.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/common/spl/spl_ymodem.c b/common/spl/spl_ymodem.c
index 577fdc69af..4c2e84e07d 100644
--- a/common/spl/spl_ymodem.c
+++ b/common/spl/spl_ymodem.c
@@ -89,7 +89,25 @@ static int spl_ymodem_load_image(struct spl_image_info 
*spl_image,
if (res <= 0)
goto end_stream;
 
-   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
+   if (IS_ENABLED(CONFIG_SPL_LOAD_FIT_FULL) &&
+   image_get_magic((struct image_header *)buf) == FDT_MAGIC) {
+   addr = CONFIG_SYS_LOAD_ADDR;
+   ih = (struct image_header *)addr;
+
+   memcpy((void *)addr, buf, res);
+   size += res;
+   addr += res;
+
+   while ((res = xyzModem_stream_read(buf, BUF_SIZE, )) > 0) {
+   memcpy((void *)addr, buf, res);
+   size += res;
+   addr += res;
+   }
+
+   ret = spl_parse_image_header(spl_image, ih);
+   if (ret)
+   return ret;
+   } else if (IS_ENABLED(CONFIG_SPL_LOAD_FIT) &&
image_get_magic((struct image_header *)buf) == FDT_MAGIC) {
struct spl_load_info load;
struct ymodem_fit_info info;
-- 
2.20.1

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

[U-Boot] [BUG] efiloader: cannot boot OpenBSD on armv7 via bootefi

[Heinrich Schuchardt]

Hello Nedko,

you reported on the IRC channel:

 i'm trying to get openbsd-6.4 kernel booted with latest u-boot.
it works with both v2018.09 and v2019.01, but not with latest git
 i'm reproducing this with default configs for sunxi lime2-emmc
 it seems that openbsd kernel loading stage is going well, but
then execution does not happen, there is no "OpenBSD/armv7 booting ..."

Olimex A20-OLinuXino-LIME2-eMMC uses the ARMv7 architecture.

The relevant source for the OpenBSD bootloader can be found at

https://github.com/openbsd/src.git in sys/arch/armv7/stand/efiboot/

While on the armv8 architecture SetVirtualAddressMap() is called it is
not called for armv7.

Alex has described in patch

efi_loader: Patch non-runtime code out at ExitBootServices already
https://lists.denx.de/pipermail/u-boot/2019-January/356845.html

that currently U-Boot does not support booting without calling
SetVirtualAddressMap() and provided a fix.

The patch has not been merged due to requested changes.

I tried to reproduce the problem on a BananaPi

This was my recipe:
Copy
https://ftp.eu.openbsd.org/pub/OpenBSD/6.4/armv7/miniroot-cubox-64.fs
to an SD-Card.
Add Linux sun7i-a20-bananapi.dtb to the first partition.
Flash Bananapi_defconfig U-Boot v2019.04-rc3 to the SD-Card

After resetting the board the installer started. All further reboots
failed even with Alex's patch applied.

Further analysis is needed.

Best regards

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

[U-Boot] [PATCH] Makefile: Do not pass -E to mkimage when SPL has full fitImage support

[Marek Vasut]

When the SPL has full fitImage support, do not generate fitImage with
external data. The full fitImage code assumes the entire fitImage is
loaded in RAM, and the SPL uses fdt_totalsize() to determine the size
of the whole fitImage, which can not work with external data.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 Makefile | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 26db4e7b59..b69e6349e2 100644
--- a/Makefile
+++ b/Makefile
@@ -893,7 +893,7 @@ cmd_mkimage = $(objtree)/tools/mkimage 
$(MKIMAGEFLAGS_$(@F)) -d $< $@ \
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 quiet_cmd_mkfitimage = MKIMAGE $@
-cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f 
$(U_BOOT_ITS) -E -p $(CONFIG_FIT_EXTERNAL_OFFSET) $@\
+cmd_mkfitimage = $(objtree)/tools/mkimage $(MKIMAGEFLAGS_$(@F)) -f 
$(U_BOOT_ITS) -p $(CONFIG_FIT_EXTERNAL_OFFSET) $@\
>$(MKIMAGEOUTPUT) $(if $(KBUILD_VERBOSE:0=), && cat $(MKIMAGEOUTPUT))
 
 quiet_cmd_cat = CAT $@
@@ -1200,6 +1200,12 @@ u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl 
u-boot-ivt.img: \
$(call if_changed,mkimage)
$(BOARD_SIZE_CHECK)
 
+ifeq ($(CONFIG_SPL_LOAD_FIT_FULL),y)
+MKIMAGEFLAGS_u-boot.itb =
+else
+MKIMAGEFLAGS_u-boot.itb = -E
+endif
+
 u-boot.itb: u-boot-nodtb.bin dts/dt.dtb $(U_BOOT_ITS) FORCE
$(call if_changed,mkfitimage)
$(BOARD_SIZE_CHECK)
-- 
2.20.1

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

Re: [U-Boot] [U-Boot, v2] Enable expression support for CONFIG_BOARD_SIZE_LIMIT

[Simon Goldschmidt]

Tom,

On Fri, Dec 14, 2018 at 8:16 PM Tom Rini  wrote:
>
> On Fri, Dec 07, 2018 at 08:27:51PM +0100, Wolfgang Denk wrote:
>
> > So far, the use of CONFIG_BOARD_SIZE_LIMIT would only work with
> > plain numeric constants.  Extend it to allow for expressions, so one
> > can for example use
> >
> >   #define CONFIG_BOARD_SIZE_LIMIT (768 << 10)
> >
> > in the board configuration.
> >
> > Signed-off-by: Wolfgang Denk 
> > Tested-by: Fabio Estevam 
> >
> > Cc: Fabio Estevam 
> > Cc: Stefano Babic 
> > Cc: Vanessa Maegima 
> > Cc: Otavio Salvador 
> > Cc: John Weber 
> > Cc: Stefan Roese 
> > ---
> > v2: replace bashism for evaluating expressions in CONFIG_BOARD_SIZE_LIMIT
> > by another call to awk.
> >
> > Note 1: As gawk lacks an eval function and we don't want to rely on
> >  bash being used as shell, we use another call to awk to evaluate the
> >  expression. This has the disadvantage that we cannot use expressions
> >  like "<<" which awk does not understand. OK, one could replace awk
> >  by something better...
> >
> > Note 2: This patch focusses on enabling this new feature.  It does
> >  not addres another issue that should be solved in a later
> >  commit: the duplication of the same code in Makefile and
> >  arch/arm/mach-imx/Makefile
> >
> > ---
> >  Makefile   | 17 -
> >  arch/arm/mach-imx/Makefile | 17 -
> >  2 files changed, 16 insertions(+), 18 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 0d11ff9797..87eb0fd2b1 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -774,15 +774,14 @@ LDPPFLAGS += \
> >
> >  ifneq ($(CONFIG_BOARD_SIZE_LIMIT),)
> >  BOARD_SIZE_CHECK = \
> > - @actual=`wc -c $@ | awk '{print $$1}'`; \
> > - limit=`printf "%d" $(CONFIG_BOARD_SIZE_LIMIT)`; \
> > - if test $$actual -gt $$limit; then \
> > - echo "$@ exceeds file size limit:" >&2 ; \
> > - echo "  limit:  $$limit bytes" >&2 ; \
> > - echo "  actual: $$actual bytes" >&2 ; \
> > - echo "  excess: $$((actual - limit)) bytes" >&2; \
> > - exit 1; \
> > - fi
> > + @(awk "END{print $$(echo $(CONFIG_BOARD_SIZE_LIMIT))}" /dev/null; wc 
> > -c $@ ) | \
>
> So this fails with awk being provided by mawk, not gawk:
> $ mawk "END{print $(echo 0xE)}" /dev/null;
> 0
> $ gawk "END{print $(echo 0xE)}" /dev/null;
> 917504
>
> And then things fail as mawk doesn't like hex.
>
> Now, at the end of the day, I'm now not sure I agree with this patch in
> concept.  When CONFIG_BOARD_SIZE_LIMIT is moved to Kconfig it will be
> taking I would assume a hex input and so we don't have to worry about <<
> at all.

Sorry to warm up an old thread, but I have some slightly new input on this.

I can understand you disliking the concept of this patch regarding U-Boot
proper size check (if CONFIG_BOARD_SIZE_LIMIT moves to Kconfig).

However, I think for SPL this is different: SPL often starts with one single
small SRAM shared for code + data. In this case, the size available for the
SPL binary often can be calculated like this:

CONFIG_SPL_MAX_SIZE = SRAM_SIZE - SYS_MALLOC_F_LEN -
GENERATED_GBL_DATA_SIZE - STACKSIZE;

Being like that, it cannot just be moved to Kconfig and by definition is not
a hardcoded single hex number but changes depending on other options.

I see two ways out here:
a) continue the way of this patch until it works for all shells/awks or
b) implement SPL binary size check using 4 constants instead of 1 (see above)

I'm willing to code this through, as I am hitting this limit on socfpga, so I
could need a decision ;-)

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

Re: [U-Boot] [PATCH v2 2/3] net: add higmacv300 Ethernet driver for HiSilicon platform

[Joe Hershberger]

On Tue, Mar 5, 2019 at 7:42 PM Shawn Guo  wrote:
>
> On Tue, Mar 05, 2019 at 11:58:26PM +, Joe Hershberger wrote:
> > > +static int higmac_recv(struct udevice *dev, int flags, uchar **packetp)
> > > +{
> > > +   struct higmac_priv *priv = dev_get_priv(dev);
> > > +   struct higmac_desc *fqd = priv->rxfq;
> > > +   struct higmac_desc *bqd = priv->rxbq;
> > > +   int fqw_pos, fqr_pos, bqw_pos, bqr_pos;
> > > +   int timeout = 10;
> > > +   int len = 0;
> > > +   int space;
> > > +   int i;
> > > +
> > > +   fqw_pos = DESC_CNT(readl(priv->base + RX_FQ_WR_ADDR));
> > > +   fqr_pos = DESC_CNT(readl(priv->base + RX_FQ_RD_ADDR));
> > > +
> > > +   if (fqw_pos >= fqr_pos)
> > > +   space = RX_DESC_NUM - (fqw_pos - fqr_pos);
> > > +   else
> > > +   space = fqr_pos - fqw_pos;
> > > +
> > > +   /* Leave one free to distinguish full filled from empty buffer */
> > > +   for (i = 0; i < space - 1; i++) {
> > > +   fqd = priv->rxfq + fqw_pos;
> > > +   invalidate_dcache_range(fqd->buf_addr,
> > > +   fqd->buf_addr + 
> > > MAC_MAX_FRAME_SIZE);
> > > +
> > > +   if (++fqw_pos >= RX_DESC_NUM)
> > > +   fqw_pos = 0;
> > > +
> > > +   writel(DESC_BYTE(fqw_pos), priv->base + RX_FQ_WR_ADDR);
> > > +   }
> > > +
> > > +   bqr_pos = DESC_CNT(readl(priv->base + RX_BQ_RD_ADDR));
> > > +   bqd += bqr_pos;
> > > +   /* BQ is only ever written by GMAC */
> > > +   invalidate_desc(bqd);
> > > +
> > > +   do {
> > > +   bqw_pos = DESC_CNT(readl(priv->base + RX_BQ_WR_ADDR));
> > > +   udelay(1);
> > > +   } while (--timeout && bqw_pos == bqr_pos);
> >
> > Did you look into using wait bit macros?
>
> I may miss your point, but this is not a loop waiting for some bits set
> or clear.  It's waiting for a given number.

OK, I see that, thanks. Should you make these "breakable" in the same
way that wait_for_bit_* does? The timeout seems quite long.

>
> >
> > > +
> > > +   if (!timeout)
> > > +   return -ETIMEDOUT;
> > > +
> > > +   if (++bqr_pos >= RX_DESC_NUM)
> > > +   bqr_pos = 0;
> > > +
> > > +   len = bqd->data_len;
> > > +
> > > +   /* CPU should not have touched this buffer since we added it to 
> > > FQ */
> > > +   invalidate_dcache_range(bqd->buf_addr, bqd->buf_addr + len);
> > > +   *packetp = (void *)(unsigned long)bqd->buf_addr;
> > > +
> > > +   /* Record the RX_BQ descriptor that is holding RX data */
> > > +   priv->rxdesc_in_use = bqr_pos;
> > > +
> > > +   return len;
> > > +}
>
> 
>
> > > +static int higmac_hw_init(struct higmac_priv *priv)
> > > +{
> > > +   int ret;
> > > +
> > > +   /* Initialize hardware queues */
> > > +   ret = higmac_init_hw_queue(priv, RX_FQ);
> > > +   if (ret)
> > > +   return ret;
> > > +
> > > +   ret = higmac_init_hw_queue(priv, RX_BQ);
> > > +   if (ret)
> > > +   goto free_rx_fq;
> > > +
> > > +   ret = higmac_init_hw_queue(priv, TX_BQ);
> > > +   if (ret)
> > > +   goto free_rx_bq;
> > > +
> > > +   ret = higmac_init_hw_queue(priv, TX_RQ);
> > > +   if (ret)
> > > +   goto free_tx_bq;
> > > +
> > > +   /* Reset phy */
> > > +   reset_assert(>rst_phy);
> > > +   mdelay(10);
> >
> > I'm surprised the delay here is not a DT parameter.
>
> We do not see the necessity for now.  We can make it a DT parameter when
> we see the real need in the future.

OK

>
> >
> > > +   reset_deassert(>rst_phy);
> > > +   mdelay(30);
> >
> > I'm surprised the delay here is not a DT parameter.
> >
> > > +   reset_assert(>rst_phy);
> > > +   mdelay(30);
> >
> > Why is this reasserted?
>
> I have to admit this is a bit hackish.  Ideally, the reset sequence
> should be: deassert -> assert -> deassert.  But this reset signal gets
> an opposite polarity than others that reset driver handles.  I can add a
> comment to explain it if you can tolerate this little hack, or I will
> add polarity support to reset driver to handle this phy reset quirk.
> Please let me know your preference.

I would prefer a polarity to be defined in the DT for this reset.

>
> >
> > > +
> > > +   return 0;
> > > +
> > > +free_tx_bq:
> > > +   free(priv->txbq);
> > > +free_rx_bq:
> > > +   free(priv->rxbq);
> > > +free_rx_fq:
> > > +   free(priv->rxfq);
> > > +   return ret;
> > > +}
> > > +
> > > +static int higmac_probe(struct udevice *dev)
> > > +{
> > > +   struct higmac_priv *priv = dev_get_priv(dev);
> > > +   struct phy_device *phydev;
> > > +   struct mii_dev *bus;
> > > +   int ret;
> > > +
> > > +   ret = higmac_hw_init(priv);
> > > +   if (ret)
> > > +   return ret;
> > > +
> > > +   bus = mdio_alloc();
> > > +   if (!bus)
> > > +   return 

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

[Simon Glass]

(We don't use the -dm mailing list...perhaps it should be deleted?)

On Wed, 27 Feb 2019 at 09:22, viktor babrian 
wrote:

> Hi,
>
> 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-DM mailing list
> u-boot...@lists.denx.de
> https://lists.denx.de/listinfo/u-boot-dm
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] net: phy: micrel: Allow KSZ8xxx and KSZ90x1 to be used together

[Joe Hershberger]

On Wed, Mar 6, 2019 at 6:48 AM James Byrne
 wrote:
>
> Commit d397f7c45b0b ("net: phy: micrel: Separate KSZ9000 drivers from
> KSZ8000 drivers") separated the KSZ8xxx and KSZ90x1 drivers and warns
> that you shouldn't select both of them due to a device ID clash between
> the KSZ9021 and the KS8721, asserting that "it is highly unlikely for a
> system to contain both a KSZ8000 and a KSZ9000 PHY". Unfortunately
> boards like the SAMA5D3xEK do contain both types of PHY, but fortunately
> the Linux Micrel PHY driver provides a solution by using different PHY
> ID and mask values to distinguish these chips.
>
> This commit contains the following changes:
>
> - The PHY ID and mask values for the KSZ9021 and the KS8721 now match
> those used by the Linux driver.
> - The warnings about not enabling both drivers have been removed.
> - The description for PHY_MICREL_KSZ8XXX has been corrected (these are
> 10/100 PHYs, not GbE PHYs).
> - PHY_MICREL_KSZ9021 and PHY_MICREL_KSZ9031 no longer select PHY_GIGE
> since this is selected by PHY_MICREL_KSZ90X1.
> - All of the relevant defconfig files have been updated now that
> PHY_MICREL_KSZ8XXX does not default to 'Y'.
>
> Signed-off-by: James Byrne 

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

Re: [U-Boot] [PATCH v1 15/22] colibri_vf: sync the board info message

[Igor Opaniuk]

Reviewed-by: Igor Opaniuk 

On Sat, 16 Feb 2019 at 00:26, Marcel Ziswiler  wrote:
>
> From: Bhuvanchandra DV 
>
> Use similar info message as on other modules.
>
> Signed-off-by: Bhuvanchandra DV 
> Acked-by: Marcel Ziswiler 
>
> ---
>
>  board/toradex/colibri_vf/colibri_vf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/toradex/colibri_vf/colibri_vf.c 
> b/board/toradex/colibri_vf/colibri_vf.c
> index 421a4791a1..d28a73332a 100644
> --- a/board/toradex/colibri_vf/colibri_vf.c
> +++ b/board/toradex/colibri_vf/colibri_vf.c
> @@ -405,9 +405,9 @@ int board_init(void)
>  int checkboard(void)
>  {
> if (is_colibri_vf61())
> -   puts("Board: Colibri VF61\n");
> +   puts("Model: Toradex Colibri VF61\n");
> else
> -   puts("Board: Colibri VF50\n");
> +   puts("Model: Toradex Colibri VF50\n");
>
> return 0;
>  }
> --
> 2.20.1
>
> ___
> 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] STM32H7-EVAL Ethernet support

[Sergei Poselenov]

Hello all,

Did anyone succeed in bringing up Ethernet support on the STM32H7x3-EVAL board 
(stm32h743-eval_deconfig)?
Please let us know.

Regards,
Sergei Poselenov,
Emcraft Systems
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v1 12/22] config: colibri_vf: use macros from linux/sizes.h

[Igor Opaniuk]

Reviewed-by: Igor Opaniuk 

On Sat, 16 Feb 2019 at 00:25, Marcel Ziswiler  wrote:
>
> From: Marcel Ziswiler 
>
> Use SZ_X{MK} macros from linux/sizes.h for include/configs/colibri_vf.h.
>
> Signed-off-by: Marcel Ziswiler 
>
> ---
>
>  include/configs/colibri_vf.h | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
> index 1acc6e5056..9effa56539 100644
> --- a/include/configs/colibri_vf.h
> +++ b/include/configs/colibri_vf.h
> @@ -12,6 +12,7 @@
>  #define __CONFIG_H
>
>  #include 
> +#include 
>
>  #define CONFIG_SYS_FSL_CLK
>
> @@ -28,7 +29,7 @@
>  #endif
>
>  /* Size of malloc() pool */
> -#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * 1024 * 1024)
> +#define CONFIG_SYS_MALLOC_LEN  (CONFIG_ENV_SIZE + 2 * SZ_1M)
>
>  /* Allow to overwrite serial and ethaddr */
>  #define CONFIG_ENV_OVERWRITE
> @@ -118,7 +119,7 @@
>
>  /* Physical memory map */
>  #define PHYS_SDRAM (0x8000)
> -#define PHYS_SDRAM_SIZE(256 * 1024 * 1024)
> +#define PHYS_SDRAM_SIZE(256 * SZ_1M)
>
>  #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM
>  #define CONFIG_SYS_INIT_RAM_ADDR   IRAM_BASE_ADDR
> @@ -141,6 +142,6 @@
>  #define CONFIG_EHCI_HCD_INIT_AFTER_RESET
>
>  /* USB DFU */
> -#define CONFIG_SYS_DFU_DATA_BUF_SIZE (1024 * 1024)
> +#define CONFIG_SYS_DFU_DATA_BUF_SIZE (SZ_1M)
>
>  #endif /* __CONFIG_H */
> --
> 2.20.1
>
> ___
> 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 v1 22/22] colibri_vf: fix sdboot for vybrid modules

[Igor Opaniuk]

Reviewed-by: Igor Opaniuk 

On Sat, 16 Feb 2019 at 00:33, Marcel Ziswiler  wrote:
>
> From: Gerard Salvatella 
>
> Currently, Vybrid's sdboot variable tries to load the kernel from /boot
> of the root partition (typically second partition when using the sdcard
> image). However, since we moved to flash the kernel in a separate UBI
> volume, we no longer deploy the kernel/device tree to /boot, hence
> sdboot does not work in its current state.
>
> Load the kernel and device tree from the first (typically FAT) partition
> as customary on all Toradex modules.
>
> While at it also change from rw to ro as e.g. systemd will re-mount the
> root file system rw anyway after checking it.
>
> Signed-off-by: Gerard Salvatella 
> Acked-by: Stefan Agner 
> Acked-by: Marcel Ziswiler 
>
> ---
>
>  include/configs/colibri_vf.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/configs/colibri_vf.h b/include/configs/colibri_vf.h
> index b2f27c1977..0d57e303a1 100644
> --- a/include/configs/colibri_vf.h
> +++ b/include/configs/colibri_vf.h
> @@ -68,11 +68,11 @@
> "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
>
>  #define SD_BOOTCMD \
> -   "sdargs=root=/dev/mmcblk0p2 rw rootwait\0"  \
> +   "sdargs=root=/dev/mmcblk0p2 ro rootwait\0"  \
> "sdboot=run setup; setenv bootargs ${defargs} ${sdargs} ${mtdparts} " 
> \
> "${setupargs} ${vidargs}; echo Booting from MMC/SD card...; " \
> -   "load mmc 0:2 ${kernel_addr_r} /boot/${kernel_file} && " \
> -   "load mmc 0:2 ${fdt_addr_r} /boot/${soc}-colibri-${fdt_board}.dtb && 
> " \
> +   "load mmc 0:1 ${kernel_addr_r} ${kernel_file} && " \
> +   "load mmc 0:1 ${fdt_addr_r} ${soc}-colibri-${fdt_board}.dtb && " \
> "run fdt_fixup && bootz ${kernel_addr_r} - ${fdt_addr_r}\0" \
>
>  #define UBI_BOOTCMD \
> --
> 2.20.1
>
> ___
> 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] Unable to compile U-Boot for Tegra K1 with modified SPL_TEXT_BASE

[Embedded Engineer]

I am trying to build latest U-Boot for my custom board based on Tegra
TK1. The downstream U-Boot provided by Nvidia builds and works fine on
my board. But when I try to build mainline U-Boot and flash it to my
board using tegra-uboot-flasher scripts, I get no output when I boot
the board.

Then I noticed that the downstream U-Boot has CONFIG_SPL_TEXT_BASE set
to 0x83D88000 while in mainline U-Boot, it is set to 0x80108000. When
I tried to modify this to any value other than 0x80108000, I get
following error while building:

binman: 'I' format requires 0 <= number <= 4294967295

Can someone guide what can I do to remove this error and get the
latest U-Boot working on Tegra K1?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v5 9/9] arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid XU3 family

[Krzysztof Kozlowski]

Add startup time to LDO regulators of S2MPS11 PMIC on Odroid XU3/XU4/HC1
family of boards to be sure the voltage is proper before relying on the
regulator.

The datasheet for all the S2MPS1x family is inconsistent here and does
not specify unambiguously the value of ramp delay for LDO.  It mentions
30 mV/us in one timing diagram but then omits it completely in LDO
regulator characteristics table (it is specified for bucks).

However the vendor kernels for Galaxy S5 and Odroid XU3 use values of 12
mV/us or 24 mV/us.

Without the ramp delay value the consumers do not wait for voltage
settle after changing it.  Although the proper value of ramp delay for
LDOs is unknown, it seems safer to use at least some value from
reference kernel than to leave it unset.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 arch/arm/dts/exynos5422-odroidxu3.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts 
b/arch/arm/dts/exynos5422-odroidxu3.dts
index 9dfae90667cf..04ecc404f907 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -45,6 +45,7 @@
regulator-name = "vdd_ldo1";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -52,18 +53,21 @@
regulator-name = "vddq_mmc0";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
};
 
ldo4_reg: LDO4 {
regulator-name = "vdd_adc";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
};
 
ldo5_reg: LDO5 {
regulator-name = "vdd_ldo5";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -71,6 +75,7 @@
regulator-name = "vdd_ldo6";
regulator-min-microvolt = <100>;
regulator-max-microvolt = <100>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -78,6 +83,7 @@
regulator-name = "vdd_ldo7";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -85,6 +91,7 @@
regulator-name = "vdd_ldo8";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -92,6 +99,7 @@
regulator-name = "vdd_ldo9";
regulator-min-microvolt = <300>;
regulator-max-microvolt = <300>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -99,6 +107,7 @@
regulator-name = "vdd_ldo10";
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
+   regulator-ramp-delay = <12000>;
regulator-always-on;
};
 
@@ -106,6 +115,7 @@
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <100>;
   

[U-Boot] [PATCH v5 5/9] arm: exynos: Wait till ADC stabilizes before checking Odroid HC1 revision

[Krzysztof Kozlowski]

Fix detection of Odroid HC1 (Exynos5422) after reboot if kernel disabled
the LDO4/VDD_ADC regulator.

The LDO4 supplies both ADC block and the ADC input AIN9.  Voltage on
AIN9 will rise slowly, so use delay of 5 milliseconds instead of
timers-based loop to wait for voltage stabilization.

First reads on Odroid HC1 return 305, 1207, 1297 and finally 1308
(reference value is 1309).

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
---
 board/samsung/common/exynos5-dt-types.c | 38 -
 1 file changed, 37 insertions(+), 1 deletion(-)

diff --git a/board/samsung/common/exynos5-dt-types.c 
b/board/samsung/common/exynos5-dt-types.c
index 7c1271d6547a..516c32923e44 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -57,12 +57,48 @@ static unsigned int odroid_get_rev(void)
return 0;
 }
 
+/*
+ * Read ADC at least twice and check the resuls.  If regulator providing 
voltage
+ * on to measured point was just turned on, first reads might require time
+ * to stabilize.
+ */
+static int odroid_get_adc_val(unsigned int *adcval)
+{
+   unsigned int adcval_prev = 0;
+   int ret, retries = 20;
+
+   ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
+ _prev);
+   if (ret)
+   return ret;
+
+   while (retries--) {
+   mdelay(5);
+
+   ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN,
+ adcval);
+   if (ret)
+   return ret;
+
+   /*
+* If difference between ADC reads is less than 3%,
+* accept the result
+*/
+   if ((100 * abs(*adcval - adcval_prev) / adcval_prev) < 3)
+   return ret;
+
+   adcval_prev = *adcval;
+   }
+
+   return ret;
+}
+
 static int odroid_get_board_type(void)
 {
unsigned int adcval;
int ret, i;
 
-   ret = adc_channel_single_shot("adc", CONFIG_ODROID_REV_AIN, );
+   ret = odroid_get_adc_val();
if (ret)
goto rev_default;
 
-- 
2.17.1

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

[U-Boot] [PATCH v5 7/9] power: regulator: s2mps11: Add enable delay

[Krzysztof Kozlowski]

According to datasheet, the output on LDO regulators will start
appearing after 10-15 us.

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
---
 drivers/power/regulator/s2mps11_regulator.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/drivers/power/regulator/s2mps11_regulator.c 
b/drivers/power/regulator/s2mps11_regulator.c
index 723d27f67c9a..67d1f9689de3 100644
--- a/drivers/power/regulator/s2mps11_regulator.c
+++ b/drivers/power/regulator/s2mps11_regulator.c
@@ -551,7 +551,16 @@ static int ldo_get_enable(struct udevice *dev)
 
 static int ldo_set_enable(struct udevice *dev, bool enable)
 {
-   return s2mps11_ldo_enable(dev, PMIC_OP_SET, );
+   int ret;
+
+   ret = s2mps11_ldo_enable(dev, PMIC_OP_SET, );
+   if (ret)
+   return ret;
+
+   /* Wait the "enable delay" for voltage to start to rise */
+   udelay(15);
+
+   return 0;
 }
 
 static int ldo_get_mode(struct udevice *dev)
-- 
2.17.1

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

[U-Boot] [PATCH v5 8/9] arm: dts: exynos: Add supply for ADC block to Odroid XU3 family

[Krzysztof Kozlowski]

The ADC block requires VDD supply to be on so provide one.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 arch/arm/dts/exynos5422-odroidxu3.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/exynos5422-odroidxu3.dts 
b/arch/arm/dts/exynos5422-odroidxu3.dts
index e859dd1b981a..9dfae90667cf 100644
--- a/arch/arm/dts/exynos5422-odroidxu3.dts
+++ b/arch/arm/dts/exynos5422-odroidxu3.dts
@@ -32,6 +32,7 @@
 
adc@12D1 {
u-boot,dm-pre-reloc;
+   vdd-supply = <_reg>;
status = "okay";
};
 
-- 
2.17.1

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

[U-Boot] [PATCH v5 2/9] power: regulator: s2mps11: Fix step for LDO27 and LDO35

[Krzysztof Kozlowski]

LDO27 and LDO35 have 25 mV step, not 50 mV.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 drivers/power/regulator/s2mps11_regulator.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/power/regulator/s2mps11_regulator.c 
b/drivers/power/regulator/s2mps11_regulator.c
index ced504eb1476..723d27f67c9a 100644
--- a/drivers/power/regulator/s2mps11_regulator.c
+++ b/drivers/power/regulator/s2mps11_regulator.c
@@ -346,6 +346,8 @@ static int s2mps11_ldo_hex2volt(int ldo, int hex)
case 11:
case 22:
case 23:
+   case 27:
+   case 35:
uV = hex * S2MPS11_LDO_STEP + S2MPS11_LDO_UV_MIN;
break;
default:
@@ -366,6 +368,8 @@ static int s2mps11_ldo_volt2hex(int ldo, int uV)
case 11:
case 22:
case 23:
+   case 27:
+   case 35:
hex = (uV - S2MPS11_LDO_UV_MIN) / S2MPS11_LDO_STEP;
break;
default:
-- 
2.17.1

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

[U-Boot] [PATCH v5 4/9] arm: exynos: odroid-xu3: Display info late to have proper type

[Krzysztof Kozlowski]

Printing the "Type" of board requires proper detection of revision which
can happen only late because regulators are needed.

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
---
 board/samsung/common/board.c | 2 +-
 configs/odroid-xu3_defconfig | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 58ecb22d75a1..9adbd1e2cf95 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -249,7 +249,7 @@ int board_eth_init(bd_t *bis)
return 0;
 }
 
-#ifdef CONFIG_DISPLAY_BOARDINFO
+#if defined(CONFIG_DISPLAY_BOARDINFO) || defined(CONFIG_DISPLAY_BOARDINFO_LATE)
 int checkboard(void)
 {
if (IS_ENABLED(CONFIG_BOARD_TYPES)) {
diff --git a/configs/odroid-xu3_defconfig b/configs/odroid-xu3_defconfig
index e35f8d6dde78..682460a1934e 100644
--- a/configs/odroid-xu3_defconfig
+++ b/configs/odroid-xu3_defconfig
@@ -10,6 +10,8 @@ CONFIG_FIT=y
 CONFIG_FIT_BEST_MATCH=y
 CONFIG_SILENT_CONSOLE=y
 CONFIG_CONSOLE_MUX=y
+# CONFIG_DISPLAY_BOARDINFO is not set
+CONFIG_DISPLAY_BOARDINFO_LATE=y
 CONFIG_MISC_INIT_R=y
 CONFIG_BOARD_TYPES=y
 CONFIG_SYS_PROMPT="ODROID-XU3 # "
-- 
2.17.1

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

[U-Boot] [PATCH v5 6/9] regulator: Add support for ramp delay

[Krzysztof Kozlowski]

Changing voltage and enabling regulator might require delays so the
regulator stabilizes at expected level.

Add support for "regulator-ramp-delay" binding which can introduce
required time to both enabling the regulator and to changing the
voltage.

Signed-off-by: Krzysztof Kozlowski 
Tested-by: Anand Moon 
---
 .../regulator/regulator.txt   |  2 +
 drivers/power/regulator/regulator-uclass.c| 47 ++-
 include/power/regulator.h |  2 +
 3 files changed, 49 insertions(+), 2 deletions(-)

diff --git a/doc/device-tree-bindings/regulator/regulator.txt 
b/doc/device-tree-bindings/regulator/regulator.txt
index 65b69c427899..4ba642b7c77f 100644
--- a/doc/device-tree-bindings/regulator/regulator.txt
+++ b/doc/device-tree-bindings/regulator/regulator.txt
@@ -35,6 +35,7 @@ Optional properties:
 - regulator-max-microamp: a maximum allowed Current value
 - regulator-always-on: regulator should never be disabled
 - regulator-boot-on: enabled by bootloader/firmware
+- regulator-ramp-delay: ramp delay for regulator (in uV/us)
 
 Note
 The "regulator-name" constraint is used for setting the device's uclass
@@ -60,4 +61,5 @@ ldo0 {
regulator-max-microamp = <10>;
regulator-always-on;
regulator-boot-on;
+   regulator-ramp-delay = <12000>;
 };
diff --git a/drivers/power/regulator/regulator-uclass.c 
b/drivers/power/regulator/regulator-uclass.c
index 6f355b969a6d..9118b8eb39e3 100644
--- a/drivers/power/regulator/regulator-uclass.c
+++ b/drivers/power/regulator/regulator-uclass.c
@@ -35,10 +35,22 @@ int regulator_get_value(struct udevice *dev)
return ops->get_value(dev);
 }
 
+static void regulator_set_value_ramp_delay(struct udevice *dev, int old_uV,
+  int new_uV, unsigned int ramp_delay)
+{
+   int delay = DIV_ROUND_UP(abs(new_uV - old_uV), ramp_delay);
+
+   debug("regulator %s: delay %u us (%d uV -> %d uV)\n", dev->name, delay,
+ old_uV, new_uV);
+
+   udelay(delay);
+}
+
 int regulator_set_value(struct udevice *dev, int uV)
 {
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
struct dm_regulator_uclass_platdata *uc_pdata;
+   int ret, old_uV = uV, is_enabled = 0;
 
uc_pdata = dev_get_uclass_platdata(dev);
if (uc_pdata->min_uV != -ENODATA && uV < uc_pdata->min_uV)
@@ -49,7 +61,20 @@ int regulator_set_value(struct udevice *dev, int uV)
if (!ops || !ops->set_value)
return -ENOSYS;
 
-   return ops->set_value(dev, uV);
+   if (uc_pdata->ramp_delay) {
+   is_enabled = regulator_get_enable(dev);
+   old_uV = regulator_get_value(dev);
+   }
+
+   ret = ops->set_value(dev, uV);
+
+   if (!ret) {
+   if (uc_pdata->ramp_delay && old_uV > 0 && is_enabled)
+   regulator_set_value_ramp_delay(dev, old_uV, uV,
+  uc_pdata->ramp_delay);
+   }
+
+   return ret;
 }
 
 /*
@@ -107,6 +132,7 @@ int regulator_set_enable(struct udevice *dev, bool enable)
 {
const struct dm_regulator_ops *ops = dev_get_driver_ops(dev);
struct dm_regulator_uclass_platdata *uc_pdata;
+   int ret, old_enable = 0;
 
if (!ops || !ops->set_enable)
return -ENOSYS;
@@ -115,7 +141,22 @@ int regulator_set_enable(struct udevice *dev, bool enable)
if (!enable && uc_pdata->always_on)
return -EACCES;
 
-   return ops->set_enable(dev, enable);
+   if (uc_pdata->ramp_delay)
+   old_enable = regulator_get_enable(dev);
+
+   ret = ops->set_enable(dev, enable);
+   if (!ret) {
+   if (uc_pdata->ramp_delay && !old_enable && enable) {
+   int uV = regulator_get_value(dev);
+
+   if (uV > 0) {
+   regulator_set_value_ramp_delay(dev, 0, uV,
+  
uc_pdata->ramp_delay);
+   }
+   }
+   }
+
+   return ret;
 }
 
 int regulator_set_enable_if_allowed(struct udevice *dev, bool enable)
@@ -335,6 +376,8 @@ static int regulator_pre_probe(struct udevice *dev)
-ENODATA);
uc_pdata->always_on = dev_read_bool(dev, "regulator-always-on");
uc_pdata->boot_on = dev_read_bool(dev, "regulator-boot-on");
+   uc_pdata->ramp_delay = dev_read_u32_default(dev, "regulator-ramp-delay",
+   0);
 
/* Those values are optional (-ENODATA if unset) */
if ((uc_pdata->min_uV != -ENODATA) &&
diff --git a/include/power/regulator.h b/include/power/regulator.h
index 314160a894b7..6c6e2cd4f996 100644
--- a/include/power/regulator.h
+++ b/include/power/regulator.h
@@ -150,6 +150,7 @@ enum regulator_flag {
  * @always_on* - bool type, true or false
  * @boot_on*   - 

[U-Boot] [PATCH v5 3/9] arm: exynos: Detect revision later, when all resources are ready

[Krzysztof Kozlowski]

Detection of board revision is done early - before power setup.  In case of
Odroid XU3/XU4/HC1 family, the detection is done using ADC which
is supplied by LDO4/VDD_ADC regulator.  This regulator could be turned
off (e.g. by kernel before reboot).  If ADC is used early, the
regulators are not yet available and the detection won't work.

Split the revision detection out of set_board_type() into separate
function called later - either when displaying board info (in late mode)
or during misc_init_r.  The idea is that set_board_type() will be called
early so its method of detection are limited to flattened device tree
(exynos5-dt-types.c for Exynos5) or GPIO (odroid.c for Exynos4412).  The
newly added set_board_revision() can be called only later, when
resources like regulator are available.

This is necessary to fix the detection of Odroid HC1 after reboot, if
kernel turned off the LDO4 regulator.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 board/samsung/common/board.c| 23 ++-
 board/samsung/common/exynos5-dt-types.c | 16 +---
 board/samsung/odroid/odroid.c   |  8 
 include/samsung/misc.h  |  1 +
 4 files changed, 44 insertions(+), 4 deletions(-)

diff --git a/board/samsung/common/board.c b/board/samsung/common/board.c
index 96228a86a117..58ecb22d75a1 100644
--- a/board/samsung/common/board.c
+++ b/board/samsung/common/board.c
@@ -253,7 +253,18 @@ int board_eth_init(bd_t *bis)
 int checkboard(void)
 {
if (IS_ENABLED(CONFIG_BOARD_TYPES)) {
-   const char *board_info = get_board_type();
+   const char *board_info;
+
+   if (IS_ENABLED(CONFIG_DISPLAY_BOARDINFO_LATE)) {
+   /*
+* Printing type requires having revision, although
+* this will succeed only if done late.
+* Otherwise revision will be set in misc_init_r().
+*/
+   set_board_revision();
+   }
+
+   board_info = get_board_type();
 
if (board_info)
printf("Type:  %s\n", board_info);
@@ -287,6 +298,16 @@ int board_late_init(void)
 #ifdef CONFIG_MISC_INIT_R
 int misc_init_r(void)
 {
+   if (IS_ENABLED(CONFIG_BOARD_TYPES) &&
+   !IS_ENABLED(CONFIG_DISPLAY_BOARDINFO_LATE)) {
+   /*
+* If revision was not set by late display boardinfo,
+* set it here. At this point regulators should be already
+* available.
+*/
+   set_board_revision();
+   }
+
 #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG
set_board_info();
 #endif
diff --git a/board/samsung/common/exynos5-dt-types.c 
b/board/samsung/common/exynos5-dt-types.c
index 7a86e9187768..7c1271d6547a 100644
--- a/board/samsung/common/exynos5-dt-types.c
+++ b/board/samsung/common/exynos5-dt-types.c
@@ -192,8 +192,11 @@ const char *get_board_type(void)
 
 /**
  * set_board_type() - set board type in gd->board_type.
- * As default type set EXYNOS5_BOARD_GENERIC, if detect Odroid,
- * then set its proper type.
+ * As default type set EXYNOS5_BOARD_GENERIC. If Odroid is detected,
+ * set its proper type based on device tree.
+ *
+ * This might be called early when some more specific ways to detect revision
+ * are not yet available.
  */
 void set_board_type(void)
 {
@@ -211,8 +214,15 @@ void set_board_type(void)
gd->board_type = of_match->data;
break;
}
+}
 
-   /* If Odroid, then check its revision */
+/**
+ * set_board_revision() - set detailed board type in gd->board_type.
+ * Should be called when resources (e.g. regulators) are available
+ * so ADC can be used to detect the specific revision of a board.
+ */
+void set_board_revision(void)
+{
if (board_is_odroidxu3())
gd->board_type = odroid_get_board_type();
 }
diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index 552333fe869d..4be8cc9826c3 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -54,6 +54,14 @@ void set_board_type(void)
gd->board_type = ODROID_TYPE_U3;
 }
 
+void set_board_revision(void)
+{
+   /*
+* Revision already set by set_board_type() because it can be
+* executed early.
+*/
+}
+
 const char *get_board_type(void)
 {
const char *board_type[] = {"u3", "x2"};
diff --git a/include/samsung/misc.h b/include/samsung/misc.h
index 017560c25662..4ff28a1df0e8 100644
--- a/include/samsung/misc.h
+++ b/include/samsung/misc.h
@@ -33,6 +33,7 @@ char *get_dfu_alt_system(char *interface, char *devstr);
 char *get_dfu_alt_boot(char *interface, char *devstr);
 #endif
 void set_board_type(void);
+void set_board_revision(void);
 const char *get_board_type(void);
 
 #endif /* __SAMSUNG_MISC_COMMON_H__ */
-- 
2.17.1

[U-Boot] [PATCH v5 1/9] adc: exynos-adc: Fix wrong bit operation used to stop the ADC

[Krzysztof Kozlowski]

When stopping the ADC_V2_CON1_STC_EN should be cleared.

Signed-off-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Majewski 
Tested-by: Anand Moon 
---
 drivers/adc/exynos-adc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/adc/exynos-adc.c b/drivers/adc/exynos-adc.c
index d33e3d632afc..12c49fc8cefb 100644
--- a/drivers/adc/exynos-adc.c
+++ b/drivers/adc/exynos-adc.c
@@ -62,7 +62,7 @@ int exynos_adc_stop(struct udevice *dev)
 
/* Stop conversion */
cfg = readl(>con1);
-   cfg |= ~ADC_V2_CON1_STC_EN;
+   cfg &= ~ADC_V2_CON1_STC_EN;
 
writel(cfg, >con1);
 
-- 
2.17.1

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

[U-Boot] [PATCH v5 0/9] arm: exynos: Fix reboot on Odroid HC1

[Krzysztof Kozlowski]

Hi,

Changes since v4

1. Patch 3: Fix build of trats/trats2 and other by hiding new call
   behind check for CONFIG_BOARD_TYPES.

Changes since v3

1. Add accumulated review and test tags.
2. Patch 6: Add "ramp" keyword to new function (as discussed with
   Torsten Duwe).
3. Rebased on v2019.04-rc3.


Changes since v2

1. Add Lukasz review tags.
2. Patch 7: Return on error, as suggested by Simon.
2. Patch 3: Use IS_ENABLED() to run revision detection only
   once - either during late display board or misc_init_r.

Changes since v1

1. Move fixes to beginning of patchset.
2. Patch 3: Rework the idea - split revision detection to be executed later.
3. Patch 4: New patch.
4. Patch 6: Apply Simon's comments.
5. Patch 6: Do not delay when changing voltage if regulator is disabled.
6. Patch 6: Do not delay when disabling the regulator.


Description
===
Odroid HC1 does not reboot properly (at least from SD card but
I do not expect difference on eMMC), if LDO4/VDD_ADC was turned
off by Linux kernel.  This condition happens so far always, because
Linux kernel did not enable ADC on Odroid HC1, therefore the
VDD_ADC regulator was turned off as unused.

The issue is in detection of revision which later is used to load
proper DTB.

The revision is obtained by ADC read of a voltage depending on VDD_ADC.
Therefore:
1. VDD_ADC has to be turned on (but board detection happens before
   power is initialized),
2. Turning VDD_ADC should wait with ramp delay,
3. Reading the value from ADC should wait for it to stabilize.

Tested on Odroid XU3-Lite and Odroid HC1.

Comments and testing are welcomed.

Best regards,
Krzysztof


Krzysztof Kozlowski (9):
  adc: exynos-adc: Fix wrong bit operation used to stop the ADC
  power: regulator: s2mps11: Fix step for LDO27 and LDO35
  arm: exynos: Detect revision later, when all resources are ready
  arm: exynos: odroid-xu3: Display info late to have proper type
  arm: exynos: Wait till ADC stabilizes before checking Odroid HC1
revision
  regulator: Add support for ramp delay
  power: regulator: s2mps11: Add enable delay
  arm: dts: exynos: Add supply for ADC block to Odroid XU3 family
  arm: dts: exynos: Add ramp delay property to LDO regulators to Odroid
XU3 family

 arch/arm/dts/exynos5422-odroidxu3.dts | 20 +++
 board/samsung/common/board.c  | 25 -
 board/samsung/common/exynos5-dt-types.c   | 54 +--
 board/samsung/odroid/odroid.c |  8 +++
 configs/odroid-xu3_defconfig  |  2 +
 .../regulator/regulator.txt   |  2 +
 drivers/adc/exynos-adc.c  |  2 +-
 drivers/power/regulator/regulator-uclass.c| 47 +++-
 drivers/power/regulator/s2mps11_regulator.c   | 15 +-
 include/power/regulator.h |  2 +
 include/samsung/misc.h|  1 +
 11 files changed, 168 insertions(+), 10 deletions(-)

-- 
2.17.1

___
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

[Fabio Estevam]

Hi Stefano,

On Fri, Mar 1, 2019 at 8:13 AM Stefano Babic  wrote:

> It is weird because Tom has pick up u-boot-imx and I have not yet pushed
>  anything new to the server.

Now I understand the reason it generates flash.bin only inside my
u-boot-imx tree: on this branch I have applied Baruch's patch:
http://patchwork.ozlabs.org/patch/1019908/

After applying it on top of U-Boot mainline tree I am also able to get
flash.bin.

It seems we need a proper fix for this problem for the upcoming 2019.04.

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

[U-Boot] [PATCH] ARM: dts: rmobile: Zap redundant USB/SDHI nodes on M3N

[Eugeniu Rosca]

v2019.01 commit cbff9f80cedd ("ARM: dts: rmobile: Sync Gen3 DTs with
Linux 4.19.6") made the sdhi/usb nodes available in r8a77965.dtsi.

Hence, remove the SDHI/USB nodes from r8a77965-u-boot.dtsi. This is
equivalent to partially reverting below v2019.01 commits:
 - f529bc551b6d ("ARM: dts: rmobile: Extract USB nodes on M3N")
 - 830b94f76867 ("ARM: dts: rmobile: Extract SDHI nodes on M3N")

Not doing that results in MMC devices being undetected on M3NULCB:

 => mmc list
 No MMC device available

Signed-off-by: Eugeniu Rosca 
---
 arch/arm/dts/r8a77965-u-boot.dtsi | 99 ---
 1 file changed, 99 deletions(-)

diff --git a/arch/arm/dts/r8a77965-u-boot.dtsi 
b/arch/arm/dts/r8a77965-u-boot.dtsi
index cbd29b3aed68..ca80ef8f29ee 100644
--- a/arch/arm/dts/r8a77965-u-boot.dtsi
+++ b/arch/arm/dts/r8a77965-u-boot.dtsi
@@ -19,103 +19,4 @@
bank-width = <2>;
status = "disabled";
};
-
-   sdhi0: sd@ee10 {
-   compatible = "renesas,sdhi-r8a77965";
-   reg = <0 0xee10 0 0x2000>;
-   interrupts = ;
-   clocks = < CPG_MOD 314>;
-   max-frequency = <2>;
-   power-domains = < 32>;
-   resets = < 314>;
-   status = "disabled";
-   };
-
-   sdhi1: sd@ee12 {
-   compatible = "renesas,sdhi-r8a77965";
-   reg = <0 0xee12 0 0x2000>;
-   interrupts = ;
-   clocks = < CPG_MOD 313>;
-   max-frequency = <2>;
-   power-domains = < 32>;
-   resets = < 313>;
-   status = "disabled";
-   };
-
-   sdhi2: sd@ee14 {
-   compatible = "renesas,sdhi-r8a77965";
-   reg = <0 0xee14 0 0x2000>;
-   interrupts = ;
-   clocks = < CPG_MOD 312>;
-   max-frequency = <2>;
-   power-domains = < 32>;
-   resets = < 312>;
-   status = "disabled";
-   };
-
-   sdhi3: sd@ee16 {
-   compatible = "renesas,sdhi-r8a77965";
-   reg = <0 0xee16 0 0x2000>;
-   interrupts = ;
-   clocks = < CPG_MOD 311>;
-   max-frequency = <2>;
-   power-domains = < 32>;
-   resets = < 311>;
-   status = "disabled";
-   };
-
-   ehci0: usb@ee080100 {
-   compatible = "generic-ehci";
-   reg = <0 0xee080100 0 0x100>;
-   interrupts = ;
-   clocks = < CPG_MOD 703>;
-   phys = <_phy0>;
-   phy-names = "usb";
-   companion= <>;
-   power-domains = < 32>;
-   resets = < 703>;
-   };
-
-   usb2_phy0: usb-phy@ee080200 {
-   compatible = "renesas,usb2-phy-r8a77965",
-"renesas,rcar-gen3-usb2-phy";
-   reg = <0 0xee080200 0 0x700>;
-   interrupts = ;
-   clocks = < CPG_MOD 703>;
-   power-domains = < 32>;
-   resets = < 703>;
-   #phy-cells = <0>;
-   };
-
-   ehci1: usb@ee0a0100 {
-   compatible = "generic-ehci";
-   reg = <0 0xee0a0100 0 0x100>;
-   interrupts = ;
-   clocks = < CPG_MOD 702>;
-   phys = <_phy1>;
-   phy-names = "usb";
-   companion= <>;
-   power-domains = < 32>;
-   resets = < 702>;
-   };
-
-   usb2_phy1: usb-phy@ee0a0200 {
-   compatible = "renesas,usb2-phy-r8a77965",
-"renesas,rcar-gen3-usb2-phy";
-   reg = <0 0xee0a0200 0 0x700>;
-   clocks = < CPG_MOD 702>;
-   power-domains = < 32>;
-   resets = < 702>;
-   #phy-cells = <0>;
-   };
-
-   xhci0: usb@ee00 {
-   compatible = "renesas,xhci-r8a77965",
-"renesas,rcar-gen3-xhci";
-   reg = <0 0xee00 0 0xc00>;
-   interrupts = ;
-   clocks = < CPG_MOD 328>;
-   power-domains = < 32>;
-   resets = < 328>;
-   };
 };
-- 
2.21.0

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

Re: [U-Boot] [PATCH 5/7] Convert CONFIG_SF_DEFAULT_* to Kconfig

[Patrick DELAUNAY]

Hi Simon,

> From: Simon Goldschmidt 
> Sent: lundi 4 mars 2019 11:51
> 
> On Mon, Mar 4, 2019 at 11:44 AM Patrick DELAUNAY
>  wrote:
> >
> > Hi Simon,
> >
> > > From: Simon Goldschmidt 
> > > Sent: mercredi 27 février 2019 15:50
> > >
> > > [reducing the CC list as gmail won't let me send otherwise]
> > >
> > > On 27.02.2019 15:20, Patrick Delaunay wrote:
> > > > This converts the following to Kconfig:
> > > >CONFIG_SF_DEFAULT_BUS
> > > >CONFIG_SF_DEFAULT_CS
> > > >CONFIG_SF_DEFAULT_MODE
> > > >CONFIG_SF_DEFAULT_SPEED
> > > >
> > > > I use moveconfig script and then manual check on generated
> > > > u-boot.cfg to solve the remaining issue.
> > > >
> > > > Signed-off-by: Patrick Delaunay 
> > >
> > > I admit I haven't followed the patches regarding these defines
> > > completely, but isn't moving these to Kconfig the opposite of what we 
> > > want?
> >
> > Yes it was my first plan in the series:
> >
> > http://patchwork.ozlabs.org/project/uboot/list/?series=76834=*
> > http://patchwork.ozlabs.org/project/uboot/list/?series=80769=*
> >
> > But it is not possible too many dependency with board using platdata for SPI
> initialization and regression after my v3.
> 
> Oh, ok. That's sad. But I wouldn't have time to work on this, either...
> 
> >
> > > I always thought the goal would be to move U-Boot to DM and
> > > devicetree completely sooner or later (where these defines aren't
> > > used). Adding them to Kconfig does not make them optional but makes
> > > them *always* present (but probably with default values if not used).
> >
> > Migration to Kconfig was requested by Jagan in
> > http://patchwork.ozlabs.org/patch/1031768/
> >
> > The define need to be always define, as they are used in cmd/sf.c They
> > could dependent on CONFIG_CMD_SF when they are no more used is other
> part of code (for other purpose).
> 
> Well, defaults for that command are not necessarily defaults for use at driver
> level?

Yes, but today it is the case for some fallback when DT information is not 
available (dfu_sf / spl_spi).
And I don't know solve this issue.

This serie is only a step, I hope in the good direction.

> >
> > ./board/Arcturus/ucp1020/cmd_arc.c
> > ./board/aristainetos/aristainetos-v1.c
> > ./board/aristainetos/aristainetos-v2.c
> > ./board/davinci/da8xxevm/da850evm.c
> > ./board/davinci/da8xxevm/omapl138_lcdk.c
> > ./board/el/el6x/el6x.c
> > ./board/siemens/taurus/taurus.c
> > ./board/Synology/ds414/cmd_syno.c
> > ./board/tqc/tqma6/tqma6.c
> > ./cmd/mvebu/bubt.c
> > ./common/splash_source.c
> > ./common/spl/spl_spi.c
> > ./drivers/dfu/dfu_sf.c
> >
> > And yes, 0 is the "default" value, so defines are present in .config.
> >
> > Why it is disturbing if these defines are requested by command sf ?
> 
> Because I would have thought with DM, defaults would come from dts, not from
> some defines.
> 
> Anyway, I guess I now understand why you have done it like that.
> I'm not the SPI maintainer, so I won't interfere. I was only a little bit 
> surprised that
> this took a different direction as the first things we discussed in that 
> area...

In fact, I am also waiting feedback to be sure that is the good direction.

> And as long as this define doesn't interfere with my SPL + U-Boot using the
> settings from dts, this looks good, I guess.

Yes, no interference: they are used only when DT is not available
(tested on my board stm32mp1 ev1 which use only device tree, and it is OK).

> 
> Regards,
> Simon
> 
> >
> > > Regards,
> > > Simon
> >
> > Jagan: can you tell me what is the right direction.for you...
> >
> > Regards
> >
> > Patrick

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

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

[Jagan Teki]

Hi Tom,

Please pull this PR.

Summary:
- dw spi include file fix
- Allwinner A31 spi, been in ML in many releases.

thanks,
Jagan.

The following changes since commit cfba74d0bef350d81241b059180bcc5a1e93bdfa:

  Merge branch 'master' of git://git.denx.de/u-boot-socfpga (2019-02-28 
18:57:32 -0500)

are available in the Git repository at:

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

for you to fetch changes up to a51cd54eff284ee42bfc1b74b8581daec78496f6:

  spi: Rename sun4i_spi.c into spi-sunxi.c (2019-03-04 18:08:56 +0530)


horatiu.vul...@microchip.com (1):
  spi: designware: Change include order

Jagan Teki (9):
  spi: sun4i: Poll for rxfifo to be filled up
  clk: sunxi: Implement SPI clocks, resets
  spi: sun4i: Simplify reg writes using set/clrbits_le32
  spi: sun4i: Access registers and bits via enum offsets
  spi: sun4i: Support fifo_depth via drvdata
  spi: sun4i: Add CLK support
  spi: sun4: Add A31 spi controller support
  spi: sun4i: Driver cleanup
  spi: Rename sun4i_spi.c into spi-sunxi.c

 drivers/clk/sunxi/clk_a10.c  |  10 +
 drivers/clk/sunxi/clk_a10s.c |   7 +
 drivers/clk/sunxi/clk_a23.c  |   7 +
 drivers/clk/sunxi/clk_a31.c  |  13 +
 drivers/clk/sunxi/clk_a64.c  |   7 +
 drivers/clk/sunxi/clk_a80.c  |  13 +
 drivers/clk/sunxi/clk_a83t.c |   7 +
 drivers/clk/sunxi/clk_h3.c   |   7 +
 drivers/clk/sunxi/clk_h6.c   |   9 +
 drivers/clk/sunxi/clk_r40.c  |  13 +
 drivers/clk/sunxi/clk_v3s.c  |   4 +
 drivers/spi/Kconfig  |  12 +-
 drivers/spi/Makefile |   2 +-
 drivers/spi/designware_spi.c |   2 +-
 drivers/spi/{sun4i_spi.c => spi-sunxi.c} | 445 +--
 15 files changed, 417 insertions(+), 141 deletions(-)
 rename drivers/spi/{sun4i_spi.c => spi-sunxi.c} (50%)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/9] spi: Add Allwinner A31 SPI driver

[Jagan Teki]

On Wed, Feb 27, 2019 at 8:02 PM Jagan Teki  wrote:
>
> This series add support for Allwinner A31 SPI controller driver.
>
> Fixed and improved conde when compared to previous series[1]
>
> Changes for v3:
> - update commit message for "poll rxfifo" patch
> - change SPI_CS argument as SPI_CS(priv, cs)
> - keep 'unsigned long' for register set, since using u16 encounter
>   type-casting issues with writel and readl calls
> - change 'unsigned long' to u32 for register bits
> - add detailed commit message for 'spi: sun4i: Add CLK support'
> - use has_soft_reset and has_burst_ctl driver variant flags for
>   A31 specific changes
> - add allwinner,sun6i-a31-spi compatible support
> - add fifo_depth support for A31
> - rename sun4i_spi to spi-sunxi.c
> - update spi-sunxi.c Kconfig entry
> Changes for v2:
> - use fifo_sta instead ctl reg in readl_poll
> - use ">=" instead of negotiation in readl_poll condition
> - use SPI_REG, SPI_BIT, SPI_CS macro for code improvement
> - use compatible check for A31 register enablement
> - add allwinner,sun6i-a31-spi compatible
> - exclude driver enable patches, since it has SPI kconfig dependencies.
>
> [1] https://patchwork.ozlabs.org/cover/1041901/
>
> Jagan Teki (9):
>   spi: sun4i: Poll for rxfifo to be filled up
>   clk: sunxi: Implement SPI clocks, resets
>   spi: sun4i: Simplify reg writes using set/clrbits_le32
>   spi: sun4i: Access registers and bits via enum offsets
>   spi: sun4i: Support fifo_depth via drvdata
>   spi: sun4i: Add CLK support
>   spi: sun4: Add A31 spi controller support
>   spi: sun4i: Driver cleanup
>   spi: Rename sun4i_spi.c into spi-sunxi.c

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

Re: [U-Boot] imx8qxp: Fix the reported CPU frequency

[Andrejs Cainikovs]

Tested-by: Andrejs Cainikovs 

 > Could you please consider this one for 2019.04?

Ditto, I would like to have this in upcoming release as well. Thanks,

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

Re: [U-Boot] [PATCH] fit: load all fragments from the extra configurations

[Lokesh Vutla]

On 06/03/19 7:22 PM, Peter Ujfalusi wrote:
> Currently only the first fdt is loaded from the extra configuration of
> FIT image.
> If the configuration have multiple fdt, load them all as well.
> 
> Signed-off-by: Peter Ujfalusi 
> ---
>  common/image-fit.c | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/common/image-fit.c b/common/image-fit.c
> index ac901e131ca1..a74b44f2982c 100644
> --- a/common/image-fit.c
> +++ b/common/image-fit.c
> @@ -2118,6 +2118,18 @@ int boot_get_fdt_fit(bootm_headers_t *images, ulong 
> addr,
>   if (next_config)
>   *next_config++ = '\0';
>   uname = NULL;
> +
> + /*
> +  * fit_image_load() would load the first FDT from the
> +  * extra config only when uconfig is specified.
> +  * Check if the extra config contains multiple FDTs and
> +  * if so, load them.
> +  */
> + cfg_noffset = fit_conf_get_node(fit, uconfig);
> +
> + i = 0;
> + count = fit_conf_get_prop_node_count(fit, cfg_noffset,
> +  FIT_FDT_PROP);

This is a nice extension to the extra configs.

Reviewed-by: Lokesh Vutla 

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

[U-Boot] [PATCH] fit: load all fragments from the extra configurations

[Peter Ujfalusi]

Currently only the first fdt is loaded from the extra configuration of
FIT image.
If the configuration have multiple fdt, load them all as well.

Signed-off-by: Peter Ujfalusi 
---
 common/image-fit.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/common/image-fit.c b/common/image-fit.c
index ac901e131ca1..a74b44f2982c 100644
--- a/common/image-fit.c
+++ b/common/image-fit.c
@@ -2118,6 +2118,18 @@ int boot_get_fdt_fit(bootm_headers_t *images, ulong addr,
if (next_config)
*next_config++ = '\0';
uname = NULL;
+
+   /*
+* fit_image_load() would load the first FDT from the
+* extra config only when uconfig is specified.
+* Check if the extra config contains multiple FDTs and
+* if so, load them.
+*/
+   cfg_noffset = fit_conf_get_node(fit, uconfig);
+
+   i = 0;
+   count = fit_conf_get_prop_node_count(fit, cfg_noffset,
+FIT_FDT_PROP);
}
 
debug("%d: using uname=%s uconfig=%s\n", i, uname, uconfig);
-- 
Peter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki

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

Re: [U-Boot] [PATCH v2] ARM: dts: i.MX6QDL: add missing spba-bus to aips-bus

[Fabio Estevam]

On Wed, Mar 6, 2019 at 10:37 AM Hannes Schmelzer
 wrote:
>
> Add this spba-bus@200 sub-bus to the aips-bus@200, because
> below there are essential boot-devices (ecspi1-4) which are needed in
> SPL for booting from SPI.
>
> Signed-off-by: Hannes Schmelzer 

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

[U-Boot] [PATCH v2] ARM: dts: i.MX6QDL: add missing spba-bus to aips-bus

[Hannes Schmelzer]

Add this spba-bus@200 sub-bus to the aips-bus@200, because
below there are essential boot-devices (ecspi1-4) which are needed in
SPL for booting from SPI.

Signed-off-by: Hannes Schmelzer 

---

Changes in v2:
- rebase on current master for taking care about changes of
  commit 67f165ddfd99f03bf4e442a6f3cf808299c87ae9
  arm: dts: Update all the dts[i] files for imx6[q|qp|dl] sabre[auto|sd]

 arch/arm/dts/imx6qdl-u-boot.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/dts/imx6qdl-u-boot.dtsi b/arch/arm/dts/imx6qdl-u-boot.dtsi
index 45ae2fa..0aa29e3 100644
--- a/arch/arm/dts/imx6qdl-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-u-boot.dtsi
@@ -9,6 +9,9 @@
 
aips-bus@200 {
u-boot,dm-spl;
+   spba-bus@200 {
+   u-boot,dm-spl;
+   };
};
 
aips-bus@210 {
-- 
2.7.4


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

[U-Boot] [PATCH] dts: force dtb recompilation

[Patrick Delaunay]

The dependency for .dtb = .dts is not enough in dts Makefile,
as the dts files are dts pre-proprocessed (include dtsi files,
as specific *-u-boot.dtsi).

For arm architecture, the dependency is correctly managed in
makefile of arch/arm/dts with .cmd files, it is needed to
execute make in this directory.

Signed-off-by: Patrick Delaunay 
---
Issue see on stm32mp1 board

stm32mp157c-ed1.dts is included in stm32mp157c-ev1.dts
and dependency is not correctly managed
(ev1 is not recompiled when ed1 is modified)


 dts/Makefile | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/dts/Makefile b/dts/Makefile
index a7a6043..bcd611f 100644
--- a/dts/Makefile
+++ b/dts/Makefile
@@ -17,7 +17,6 @@ ifneq ($(EXT_DTB),)
 DTB := $(EXT_DTB)
 else
 DTB := $(ARCH_PATH)/$(DEVICE_TREE).dtb
-dtb_depends += $(DTB:.dtb=.dts)
 endif
 
 $(obj)/dt-spl.dtb: $(DTB) $(objtree)/tools/fdtgrep FORCE
@@ -28,7 +27,7 @@ $(obj)/dt.dtb: $(DTB) FORCE
 
 targets += dt.dtb dt-spl.dtb
 
-$(DTB): $(dtb_depends)
+$(DTB): $(dtb_depends) FORCE
 ifeq ($(EXT_DTB),)
$(Q)$(MAKE) $(build)=$(ARCH_PATH) $@
 endif
-- 
2.7.4

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

[U-Boot] [PATCH] image: fdt: handle coalesced reserve region

[Patrick Delaunay]

Handle in boot_fdt_reserve_region
any return value > 0 of lmb_reserve() function;
it occurs when coalesced region are found:
adjacent reserved region are merged.

This patch avoid the error trace:
  ERROR: reserving fdt memory region failed..
when reserved region are merged (return value = 1).

Signed-off-by: Patrick Delaunay 
---

Tested on stm32mp1 board v2019.04-rc2

with reserved memory in device tree:

reserved-memory {
#address-cells = <1>;
#size-cells = <1>;
ranges;
retram: retram@0x3800 {
compatible = "shared-dma-pool";
reg = <0x3800 0x1>;
no-map;
};
mcuram: mcuram@0x3000 {
compatible = "shared-dma-pool";
reg = <0x3000 0x4>;
no-map;
};
mcuram2: mcuram2@0x1000 {
compatible = "shared-dma-pool";
reg = <0x1000 0x4>;
no-map;
};
vdev0vring0: vdev0vring0@1004 {
compatible = "shared-dma-pool";
reg = <0x1004 0x2000>;
no-map;
};

vdev0vring1: vdev0vring1@10042000 {
compatible = "shared-dma-pool";
reg = <0x10042000 0x2000>;
no-map;
};

vdev0buffer: vdev0buffer@10044000 {
compatible = "shared-dma-pool";
reg = <0x10044000 0x4000>;
no-map;
};
};

we have several adjacent reserved memory (0x1000...0x10046000)

Without the patch I have the ERROR:

ERROR: reserving fdt memory region failed (addr=1004 size=2000)
ERROR: reserving fdt memory region failed (addr=10042000 size=2000)
ERROR: reserving fdt memory region failed (addr=10044000 size=2000)
lmb_dump_all:
memory.cnt = 0x1
memory.size= 0x0
memory.reg[0x0].base   = 0xc000
   .size   = 0x4000

reserved.cnt   = 0x4
reserved.size  = 0x0
reserved.reg[0x0].base = 0x1000
 .size = 0x46000
reserved.reg[0x1].base = 0x3000
 .size = 0x4
reserved.reg[0x2].base = 0x3800
 .size = 0x1
reserved.reg[0x3].base = 0xfdc38a98
 .size = 0x23c7568

with the patch not more issue...


 common/image-fdt.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/image-fdt.c b/common/image-fdt.c
index 94089b2..01186ae 100644
--- a/common/image-fdt.c
+++ b/common/image-fdt.c
@@ -71,10 +71,10 @@ static const image_header_t *image_get_fdt(ulong fdt_addr)
 static void boot_fdt_reserve_region(struct lmb *lmb, uint64_t addr,
uint64_t size)
 {
-   int ret;
+   long ret;
 
ret = lmb_reserve(lmb, addr, size);
-   if (!ret) {
+   if (ret >= 0) {
debug("   reserving fdt memory region: addr=%llx size=%llx\n",
  (unsigned long long)addr, (unsigned long long)size);
} else {
-- 
2.7.4

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

Re: [U-Boot] [PATCH 2/4] board: mscc: jr2: Update MSCC Jaguar2 boards

[Daniel Schwierzeck]

Am 05.03.19 um 12:57 schrieb Horatiu Vultur:
> In Jaguar2 SoC family there are 3 different pcb. Each of this needs
> to configure the SerDes and the phys in different ways.
> Therefore implement the function board_phy_config and serdes_cfg
> and based on pcb configure them accordingly.

what are the differences between all boards? Can't you model the
different register values somehow as custom DT properties? This method
looks like a lot of code duplication and doesn't scale well when adding
new boards.

> 
> Signed-off-by: Horatiu Vultur 
> ---
>  board/mscc/jr2/jr2.c | 542 
> +++
>  1 file changed, 542 insertions(+)
> 
> diff --git a/board/mscc/jr2/jr2.c b/board/mscc/jr2/jr2.c
> index 58a4a04..94e0c5d 100644
> --- a/board/mscc/jr2/jr2.c
> +++ b/board/mscc/jr2/jr2.c
> @@ -6,6 +6,140 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +
> +#define HSIO_ANA_SERDES1G_DES_CFG0xac
> +#define  HSIO_ANA_SERDES1G_DES_CFG_BW_HYST(x)((x) << 
> 1)
> +#define  HSIO_ANA_SERDES1G_DES_CFG_BW_ANA(x) ((x) << 
> 5)
> +#define  HSIO_ANA_SERDES1G_DES_CFG_MBTR_CTRL(x)  ((x) << 
> 8)
> +#define  HSIO_ANA_SERDES1G_DES_CFG_PHS_CTRL(x)   ((x) << 
> 13)
> +#define HSIO_ANA_SERDES1G_IB_CFG 0xb0
> +#define  HSIO_ANA_SERDES1G_IB_CFG_RESISTOR_CTRL(x)   (x)
> +#define  HSIO_ANA_SERDES1G_IB_CFG_EQ_GAIN(x) ((x) << 
> 6)
> +#define  HSIO_ANA_SERDES1G_IB_CFG_ENA_OFFSET_COMPBIT(9)
> +#define  HSIO_ANA_SERDES1G_IB_CFG_ENA_DETLEV BIT(11)
> +#define  HSIO_ANA_SERDES1G_IB_CFG_ENA_CMV_TERM   BIT(13)
> +#define  HSIO_ANA_SERDES1G_IB_CFG_DET_LEV(x) ((x) << 
> 19)
> +#define  HSIO_ANA_SERDES1G_IB_CFG_ACJTAG_HYST(x) ((x) << 
> 24)
> +#define HSIO_ANA_SERDES1G_OB_CFG 0xb4
> +#define  HSIO_ANA_SERDES1G_OB_CFG_RESISTOR_CTRL(x)   (x)
> +#define  HSIO_ANA_SERDES1G_OB_CFG_VCM_CTRL(x)((x) << 
> 4)
> +#define  HSIO_ANA_SERDES1G_OB_CFG_CMM_BIAS_CTRL(x)   ((x) << 
> 10)
> +#define  HSIO_ANA_SERDES1G_OB_CFG_AMP_CTRL(x)((x) << 
> 13)
> +#define  HSIO_ANA_SERDES1G_OB_CFG_SLP(x) ((x) << 
> 17)
> +#define HSIO_ANA_SERDES1G_SER_CFG0xb8
> +#define HSIO_ANA_SERDES1G_COMMON_CFG 0xbc
> +#define  HSIO_ANA_SERDES1G_COMMON_CFG_IF_MODEBIT(0)
> +#define  HSIO_ANA_SERDES1G_COMMON_CFG_ENA_LANE   BIT(18)
> +#define  HSIO_ANA_SERDES1G_COMMON_CFG_SYS_RSTBIT(31)
> +#define HSIO_ANA_SERDES1G_PLL_CFG0xc0
> +#define  HSIO_ANA_SERDES1G_PLL_CFG_FSM_ENA   BIT(7)
> +#define  HSIO_ANA_SERDES1G_PLL_CFG_FSM_CTRL_DATA(x)  ((x) << 
> 8)
> +#define  HSIO_ANA_SERDES1G_PLL_CFG_ENA_RC_DIV2   BIT(21)
> +#define HSIO_DIG_SERDES1G_DFT_CFG0   0xc8
> +#define HSIO_DIG_SERDES1G_TP_CFG 0xd4
> +#define HSIO_DIG_SERDES1G_MISC_CFG   0xdc
> +#define  HSIO_DIG_SERDES1G_MISC_CFG_LANE_RST BIT(0)
> +#define HSIO_MCB_SERDES1G_CFG0xe8
> +#define  HSIO_MCB_SERDES1G_CFG_WR_ONE_SHOT   BIT(31)
> +#define  HSIO_MCB_SERDES1G_CFG_ADDR(x)   (x)
> +
> +#define HSIO_ANA_SERDES6G_DES_CFG0x11c
> +#define  HSIO_ANA_SERDES6G_DES_CFG_SWAP_ANA  BIT(0)
> +#define  HSIO_ANA_SERDES6G_DES_CFG_BW_ANA(x) ((x) << 
> 1)
> +#define  HSIO_ANA_SERDES6G_DES_CFG_SWAP_HYST BIT(4)
> +#define  HSIO_ANA_SERDES6G_DES_CFG_BW_HYST(x)((x) << 
> 5)
> +#define  HSIO_ANA_SERDES6G_DES_CFG_CPMD_SEL(x)   ((x) << 
> 8)
> +#define  HSIO_ANA_SERDES6G_DES_CFG_MBTR_CTRL(x)  ((x) << 
> 10)
> +#define  HSIO_ANA_SERDES6G_DES_CFG_PHS_CTRL(x)   ((x) << 
> 13)
> +#define HSIO_ANA_SERDES6G_IB_CFG 0x120
> +#define  HSIO_ANA_SERDES6G_IB_CFG_REG_ENABIT(0)
> +#define  HSIO_ANA_SERDES6G_IB_CFG_EQZ_ENABIT(1)
> +#define  HSIO_ANA_SERDES6G_IB_CFG_SAM_ENABIT(2)
> +#define  HSIO_ANA_SERDES6G_IB_CFG_CAL_ENABIT(3)
> +#define  HSIO_ANA_SERDES6G_IB_CFG_CONCUR BIT(4)
> +#define  HSIO_ANA_SERDES6G_IB_CFG_SIG_DET_ENABIT(5)
> +#define  HSIO_ANA_SERDES6G_IB_CFG_REG_PAT_SEL_OFF(x) ((x) << 
> 7)
> +#define  HSIO_ANA_SERDES6G_IB_CFG_REG_PAT_SEL_LP(x)  ((x) << 
> 9)
> +#define  HSIO_ANA_SERDES6G_IB_CFG_REG_PAT_SEL_MID(x) ((x) << 
> 11)
> +#define  

Re: [U-Boot] [U-Boot, V2, PATCH 2/3] mips: add initial support for qca956x referenced board

[Daniel Schwierzeck]

Am 05.03.19 um 08:04 schrieb rosys...@rosinson.com:
> From: Rosy Song 
> 
> Signed-off-by: Rosy Song 
> ---

as requested in the last review, please provide a proper commit message.
You also need to provide a changelog if you submit an updated series.

Maybe you should read this:
https://www.denx.de/wiki/U-Boot/Patches


>  arch/mips/dts/Makefile|   1 +
>  arch/mips/dts/ap152.dts   |  48 ++
>  arch/mips/dts/qca956x.dtsi|  87 
>  arch/mips/mach-ath79/Kconfig  |  14 +
>  arch/mips/mach-ath79/Makefile |   1 +
>  .../mach-ath79/include/mach/ar71xx_regs.h |  73 +++
>  arch/mips/mach-ath79/include/mach/ath79.h |   3 +
>  arch/mips/mach-ath79/qca956x/Makefile |   5 +
>  arch/mips/mach-ath79/qca956x/clk.c| 419 ++
>  arch/mips/mach-ath79/qca956x/cpu.c|   9 +
>  arch/mips/mach-ath79/qca956x/ddr.c| 308 +
>  .../mips/mach-ath79/qca956x/qca956x-ddr-tap.S | 193 
>  arch/mips/mach-ath79/reset.c  | 271 +++
>  board/qca/ap152/Kconfig   |  15 +
>  board/qca/ap152/MAINTAINERS   |   6 +
>  board/qca/ap152/Makefile  |   3 +
>  board/qca/ap152/ap152.c   |  81 
>  configs/ap152_defconfig   |  49 ++
>  include/configs/ap152.h   |  54 +++
>  19 files changed, 1640 insertions(+)
>  create mode 100644 arch/mips/dts/ap152.dts
>  create mode 100644 arch/mips/dts/qca956x.dtsi
>  create mode 100644 arch/mips/mach-ath79/qca956x/Makefile
>  create mode 100644 arch/mips/mach-ath79/qca956x/clk.c
>  create mode 100644 arch/mips/mach-ath79/qca956x/cpu.c
>  create mode 100644 arch/mips/mach-ath79/qca956x/ddr.c
>  create mode 100644 arch/mips/mach-ath79/qca956x/qca956x-ddr-tap.S
>  create mode 100644 board/qca/ap152/Kconfig
>  create mode 100644 board/qca/ap152/MAINTAINERS
>  create mode 100644 board/qca/ap152/Makefile
>  create mode 100644 board/qca/ap152/ap152.c
>  create mode 100644 configs/ap152_defconfig
>  create mode 100644 include/configs/ap152.h
> 
> diff --git a/arch/mips/dts/Makefile b/arch/mips/dts/Makefile
> index b94b582837..621c35f0ef 100644
> --- a/arch/mips/dts/Makefile
> +++ b/arch/mips/dts/Makefile
> @@ -2,6 +2,7 @@
>  
>  dtb-$(CONFIG_TARGET_AP121) += ap121.dtb
>  dtb-$(CONFIG_TARGET_AP143) += ap143.dtb
> +dtb-$(CONFIG_TARGET_AP152) += ap152.dtb
>  dtb-$(CONFIG_TARGET_BOSTON) += img,boston.dtb
>  dtb-$(CONFIG_TARGET_MALTA) += mti,malta.dtb
>  dtb-$(CONFIG_TARGET_PIC32MZDASK) += pic32mzda_sk.dtb
> diff --git a/arch/mips/dts/ap152.dts b/arch/mips/dts/ap152.dts
> new file mode 100644
> index 00..1722290c73
> --- /dev/null
> +++ b/arch/mips/dts/ap152.dts
> @@ -0,0 +1,48 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Rosy Song 
> + */
> +
> +/dts-v1/;
> +#include "qca956x.dtsi"
> +
> +/ {
> + model = "AP152 Reference Board";
> + compatible = "qca,ap152", "qca,qca956x";
> +
> + aliases {
> + spi0 = 
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +};
> +
> + {
> + phy-mode = "sgmii";
> + status = "okay";
> +};
> +
> + {
> + clock-frequency = <2500>;
> +};
> +
> + {
> + clock-frequency = <2500>;
> + status = "okay";
> +};
> +
> + {
> + spi-max-frequency = <2500>;
> + status = "okay";
> + spi-flash@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "spi-flash";
> + memory-map = <0x9f00 0x0100>;
> + spi-max-frequency = <2500>;
> + reg = <0>;
> + };
> +};
> diff --git a/arch/mips/dts/qca956x.dtsi b/arch/mips/dts/qca956x.dtsi
> new file mode 100644
> index 00..6cb360b3f8
> --- /dev/null
> +++ b/arch/mips/dts/qca956x.dtsi
> @@ -0,0 +1,87 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2018 Rosy Song 
> + */
> +
> +#include "skeleton.dtsi"
> +
> +/ {
> + compatible = "qca,qca956x";
> +
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "mips,mips74Kc";
> + reg = <0>;
> + };
> + };
> +
> + clocks {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + xtal: xtal {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-output-names = "xtal";
> + };
> + };
> +
> + ahb {
> + compatible = "simple-bus";
> + ranges;
> +
> + #address-cells = <1>;
> + #size-cells = 

[U-Boot] [PATCH] net: phy: micrel: Allow KSZ8xxx and KSZ90x1 to be used together

[James Byrne]

Commit d397f7c45b0b ("net: phy: micrel: Separate KSZ9000 drivers from
KSZ8000 drivers") separated the KSZ8xxx and KSZ90x1 drivers and warns
that you shouldn't select both of them due to a device ID clash between
the KSZ9021 and the KS8721, asserting that "it is highly unlikely for a
system to contain both a KSZ8000 and a KSZ9000 PHY". Unfortunately
boards like the SAMA5D3xEK do contain both types of PHY, but fortunately
the Linux Micrel PHY driver provides a solution by using different PHY
ID and mask values to distinguish these chips.

This commit contains the following changes:

- The PHY ID and mask values for the KSZ9021 and the KS8721 now match
those used by the Linux driver.
- The warnings about not enabling both drivers have been removed.
- The description for PHY_MICREL_KSZ8XXX has been corrected (these are
10/100 PHYs, not GbE PHYs).
- PHY_MICREL_KSZ9021 and PHY_MICREL_KSZ9031 no longer select PHY_GIGE
since this is selected by PHY_MICREL_KSZ90X1.
- All of the relevant defconfig files have been updated now that
PHY_MICREL_KSZ8XXX does not default to 'Y'.

Signed-off-by: James Byrne 

---

 configs/alt_defconfig|  1 +
 configs/aristainetos_defconfig   |  1 +
 configs/bk4r1_defconfig  |  1 +
 configs/colibri_imx6_defconfig   |  1 +
 configs/colibri_imx6_nospl_defconfig |  1 +
 configs/colibri_imx7_defconfig   |  1 +
 configs/colibri_imx7_emmc_defconfig  |  1 +
 configs/colibri_vf_defconfig |  1 +
 configs/flea3_defconfig  |  1 +
 configs/gose_defconfig   |  1 +
 configs/imx6dl_mamoj_defconfig   |  1 +
 configs/imx6qdl_icore_rqs_defconfig  |  1 +
 configs/k2g_evm_defconfig|  1 +
 configs/k2g_hs_evm_defconfig |  1 +
 configs/koelsch_defconfig|  1 +
 configs/lager_defconfig  |  1 +
 configs/m53menlo_defconfig   |  1 +
 configs/mx6ul_14x14_evk_defconfig|  1 +
 configs/mx6ul_9x9_evk_defconfig  |  1 +
 configs/opos6uldev_defconfig |  1 +
 configs/pcm052_defconfig |  1 +
 configs/phycore_pcl063_defconfig |  1 +
 configs/pico-hobbit-imx6ul_defconfig |  1 +
 configs/pico-imx6ul_defconfig|  1 +
 configs/pico-pi-imx6ul_defconfig |  1 +
 configs/porter_defconfig |  1 +
 configs/silk_defconfig   |  1 +
 configs/stout_defconfig  |  1 +
 configs/stv0991_defconfig|  1 +
 configs/udoo_neo_defconfig   |  1 +
 configs/vf610twr_defconfig   |  1 +
 configs/vf610twr_nand_defconfig  |  1 +
 configs/woodburn_defconfig   |  1 +
 configs/woodburn_sd_defconfig|  1 +
 drivers/net/phy/Kconfig  | 19 +--
 drivers/net/phy/micrel_ksz8xxx.c |  8 +---
 drivers/net/phy/micrel_ksz90x1.c |  2 +-
 37 files changed, 45 insertions(+), 18 deletions(-)

diff --git a/configs/alt_defconfig b/configs/alt_defconfig
index c4ece79507..44f25a4b94 100644
--- a/configs/alt_defconfig
+++ b/configs/alt_defconfig
@@ -67,6 +67,7 @@ CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_SPANSION=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
 CONFIG_DM_ETH=y
 CONFIG_SH_ETHER=y
 CONFIG_PCI=y
diff --git a/configs/aristainetos_defconfig b/configs/aristainetos_defconfig
index 950f9f6baa..0f71f4621e 100644
--- a/configs/aristainetos_defconfig
+++ b/configs/aristainetos_defconfig
@@ -44,6 +44,7 @@ CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT=1
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
 CONFIG_MII=y
 CONFIG_SPI=y
 CONFIG_MXC_SPI=y
diff --git a/configs/bk4r1_defconfig b/configs/bk4r1_defconfig
index 9e31b4ac97..5608110c3a 100644
--- a/configs/bk4r1_defconfig
+++ b/configs/bk4r1_defconfig
@@ -39,6 +39,7 @@ CONFIG_SPI_FLASH_STMICRO=y
 CONFIG_SPI_FLASH_MTD=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
 CONFIG_MII=y
 CONFIG_RTC_M41T62=y
 CONFIG_DM_SERIAL=y
diff --git a/configs/colibri_imx6_defconfig b/configs/colibri_imx6_defconfig
index 2072281354..4127a47115 100644
--- a/configs/colibri_imx6_defconfig
+++ b/configs/colibri_imx6_defconfig
@@ -57,6 +57,7 @@ CONFIG_DFU_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
 CONFIG_MII=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/colibri_imx6_nospl_defconfig 
b/configs/colibri_imx6_nospl_defconfig
index 5e9490bc42..b1609b8b7e 100644
--- a/configs/colibri_imx6_nospl_defconfig
+++ b/configs/colibri_imx6_nospl_defconfig
@@ -46,6 +46,7 @@ CONFIG_DFU_MMC=y
 CONFIG_FSL_ESDHC=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
 CONFIG_MII=y
 CONFIG_USB=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/colibri_imx7_defconfig b/configs/colibri_imx7_defconfig
index 7a52361a2a..f4c78dfa1d 100644
--- a/configs/colibri_imx7_defconfig
+++ b/configs/colibri_imx7_defconfig
@@ -57,6 +57,7 @@ CONFIG_NAND_MXS_DT=y
 CONFIG_MTD_UBI_FASTMAP=y
 CONFIG_PHYLIB=y
 CONFIG_PHY_MICREL=y
+CONFIG_PHY_MICREL_KSZ8XXX=y
 

Re: [U-Boot] [PATCH v3 3/6] i2c: rcar_i2c: Fix sending of slave addresses

[Marek Vasut]

On 3/6/19 11:46 AM, Ismael Luceno Cortes wrote:
> Do the reset before clearing the MSR, otherwise it may result in a read
> or write operation instead if the start condition is repeated.
> 
> Signed-off-by: Ismael Luceno 
> Reviewed-by: Marek Vasut 


Reviewed-by: Marek Vasut 

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

Re: [U-Boot] [PATCH v3 6/6] i2c: rcar_i2c: Move FSDA check to rcar_i2c_recover

[Marek Vasut]

On 3/6/19 11:46 AM, Ismael Luceno Cortes wrote:
> Cosmetic change.  Any call to the recover function would need to do the
> same check afterwards, so it's sensible to make it part of the function.
> 
> Signed-off-by: Ismael Luceno 

Reviewed-by: Marek Vasut 

> ---
>  drivers/i2c/rcar_i2c.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 78ef8acacc..8fe0aadffa 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -81,12 +81,13 @@ static int rcar_i2c_finish(struct udevice *dev)
>   return ret;
>  }
>  
> -static void rcar_i2c_recover(struct udevice *dev)
> +static int rcar_i2c_recover(struct udevice *dev)
>  {
>   struct rcar_i2c_priv *priv = dev_get_priv(dev);
>   u32 mcr = RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_OBPC;
>   u32 mcra = mcr | RCAR_I2C_ICMCR_FSDA;
>   int i;
> + u32 mstat;
Nit: would be nice to keep these variables sorted in reverse xmas tree.

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

Re: [U-Boot] [PATCH v3 5/6] i2c: rcar_i2c: Set the slave address from rcar_i2c_xfer

[Marek Vasut]

On 3/6/19 11:46 AM, Ismael Luceno Cortes wrote:
> It needs to be done for both reads and writes, so do it at rcar_i2c_xfer
> to avoid duplication.
> 
> Signed-off-by: Ismael Luceno 


Reviewed-by: Marek Vasut 

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

Re: [U-Boot] [PATCH v3 2/6] i2c: rcar_i2c: Add comments about registers & values

[Marek Vasut]

On 3/6/19 11:46 AM, Ismael Luceno Cortes wrote:
> Document the meaning of macros related to registers and values to be
> written to them.
> 
> Signed-off-by: Ismael Luceno 


Reviewed-by: Marek Vasut 

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

Re: [U-Boot] [PATCH v3 4/6] i2c: rcar_i2c: Don't mask errors with EREMOTEIO at rcar_i2c_xfer

[Marek Vasut]

On 3/6/19 11:46 AM, Ismael Luceno Cortes wrote:
> Fix rcar_i2c_xfer return value, previously it was always returning
> -EREMOTEIO when dealing with errors from calls to the read/write
> functions.
> 
> Signed-off-by: Ismael Luceno 

Reviewed-by: Marek Vasut 

> ---
>  drivers/i2c/rcar_i2c.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index a88fbcf34f..9223eaecbf 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -221,7 +221,7 @@ static int rcar_i2c_xfer(struct udevice *dev, struct 
> i2c_msg *msg, int nmsgs)
>   ret = rcar_i2c_write_common(dev, msg);
>  
>   if (ret)
> - return -EREMOTEIO;
> + return ret;
>   }
>  
>   return ret;
> 


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

Re: [U-Boot] [PATCH v3 1/6] i2c: rcar_i2c: Setup SCL/SDA delay at rcar_i2c_set_speed

[Marek Vasut]

On 3/6/19 11:46 AM, Ismael Luceno Cortes wrote:
> Setting up the delay only needs to be done once; move it to
> rcar_i2c_set_speed so it's done at initialization time.
> 
> Signed-off-by: Ismael Luceno 

Reviewed-by: Marek Vasut 

> ---
>  drivers/i2c/rcar_i2c.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> index 10b0f8bad4..a57f72a228 100644
> --- a/drivers/i2c/rcar_i2c.c
> +++ b/drivers/i2c/rcar_i2c.c
> @@ -116,9 +116,7 @@ static int rcar_i2c_set_addr(struct udevice *dev, u8 
> chip, u8 read)
>   writel(0, priv->base + RCAR_I2C_ICMSR);
>   writel(priv->icccr, priv->base + RCAR_I2C_ICCCR);
>  
> - if (priv->type == RCAR_I2C_TYPE_GEN3)
> - writel(RCAR_I2C_ICFBSCR_TCYC17, priv->base + RCAR_I2C_ICFBSCR);
> -
> + /* Wait for the bus */
>   ret = wait_for_bit_le32(priv->base + RCAR_I2C_ICMCR,
>   RCAR_I2C_ICMCR_FSDA, false, 2, true);
>   if (ret) {
> @@ -304,6 +302,11 @@ scgd_find:
>   priv->icccr = (scgd << RCAR_I2C_ICCCR_SCGD_OFF) | cdf;
>   writel(priv->icccr, priv->base + RCAR_I2C_ICCCR);
>  
> + if (priv->type == RCAR_I2C_TYPE_GEN3) {
> + /* Set SCL/SDA delay */
> + writel(RCAR_I2C_ICFBSCR_TCYC17, priv->base + RCAR_I2C_ICFBSCR);
> + }
> +
>   return 0;
>  }
>  
> 
> base-commit: f08023c07d826fbc8e62fdd3367961b2f0b06844
> prerequisite-patch-id: 9e5b0458bc15640eb483ccad91dbe85150f9f7be
> 


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

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Anup Patel]

On Wed, Mar 6, 2019 at 5:45 PM Auer, Lukas
 wrote:
>
> On Wed, 2019-03-06 at 13:01 +0100, Andreas Schwab wrote:
> > On Mär 06 2019, Anup Patel  wrote:
> >
> > > On Wed, Mar 6, 2019 at 5:17 PM Andreas Schwab 
> > > wrote:
> > > > On Mär 06 2019, Anup Patel  wrote:
> > > >
> > > > > > -Original Message-
> > > > > > From: Andreas Schwab 
> > > > > > Sent: Wednesday, March 6, 2019 4:27 PM
> > > > > > To: Anup Patel 
> > > > > > Cc: Auer, Lukas ;
> > > > > > u-boot@lists.denx.de;
> > > > > > paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
> > > > > > bar...@tkos.co.il; daniel.schwierz...@gmail.com;
> > > > > > bmeng...@gmail.com;
> > > > > > r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish
> > > > > > Patra
> > > > > > 
> > > > > > Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> > > > > >
> > > > > > Apparently sometimes u-boot tries to boot the kernel on heart
> > > > > > 0 (the E51
> > > > > > core), which will then fail to start userspace, since that
> > > > > > cannot cope with the
> > > > > > missing fpu.
> > > > >
> > > > > That's not possible
> > > >
> > > > Yes, it is.
> > > >
> > > >
> > > > OpenSBI v0.3 (Mar  6 2019 10:55:01)
> > > >_  _
> > > >   / __ \  / |  _ \_   _|
> > > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > > >  | |__| | |_) |  __/ | | |) | |_) || |_
> > > >   \/| .__/ \___|_| |_|_/|/_|
> > > > | |
> > > > |_|
> > > >
> > > > Platform Name  : SiFive Freedom U540
> > > > Platform HART Features : RV64ACDFIMSU
> > > > Platform Max HARTs : 5
> > > > Current Hart   : 2
> > > > Firmware Base  : 0x8000
> > > > Firmware Size  : 88 KB
> > > > Runtime SBI Version: 0.1
> > > >
> > > > PMP0: 0x8000-0x8001 (A)
> > > > PMP1: 0x-0x007f (A,R,W,X)
> > > >
> > > >
> > > > U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10
> > > > +0100)
> > > >
> > > > CPU:   rv64imac
> > > > Model: sifive,hifive-unleashed-a00
> > > > DRAM:  8 GiB
> > >
> > > How does this prove that U-Boot is booting on HART 0?
> >
> > See the CPU isa.
> >
>
> Interesting.. U-Boot assumes that it can run on any core it is started
> on. In this case, OpenSBI must have booted its payload on hart 0.

This is certainly not reproducible on cold-boot at my end but this
does mean OpenSBI has booted HART0 and let it jump to U-Boot.

Now OpenSBI (by default) on SiFive FU540 does not allow HART0
to go forward due to lack of S-mode. I think this is definitely the
warm-boot issue where OpenSBI sees corrupted memory contents.

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

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Auer, Lukas]

On Wed, 2019-03-06 at 10:07 +, Anup Patel wrote:
> > -Original Message-
> > From: Auer, Lukas 
> > Sent: Wednesday, March 6, 2019 2:52 PM
> > To: u-boot@lists.denx.de; Anup Patel 
> > Cc: paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
> > bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com
> > ;
> > r...@andestech.com; s...@denx.de; sch...@suse.de; pal...@sifive.com;
> > Atish Patra 
> > Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> > 
> > On Wed, 2019-03-06 at 04:00 +, Anup Patel wrote:
> > > > -Original Message-
> > > > From: Lukas Auer 
> > > > Sent: Wednesday, March 6, 2019 4:23 AM
> > > > To: u-boot@lists.denx.de
> > > > Cc: Atish Patra ; Anup Patel
> > > > ; Bin Meng ; Andreas
> > Schwab
> > > > ; Palmer Dabbelt ; Alexander
> > Graf
> > > > ; Lukas Auer ;
> > > > Anup
> > > > Patel ; Anup Patel ;
> > > > Rick
> > > > Chen ; Baruch Siach ;
> > > > Atish
> > > > Patra  ; Stefan Roese ; Paul
> > > > Walmsley  ; Daniel Schwierzeck
> > > > 
> > > > Subject: [PATCH v2 0/9] SMP support for RISC-V
> > > > 
> > > > This patch series adds SMP support for RISC-V to U-Boot. It
> > > > allows
> > > > U-Boot to run on multi-hart systems (hart is the RISC-V
> > > > terminology
> > > > for hardware thread). Images passed to bootm will be started on
> > > > all
> > > > harts.
> > > > The bootm command is currently the only one that will boot
> > > > images on
> > > > all harts, bootefi is not yet supported.
> > > > 
> > > > The patches have been successfully tested on both QEMU (machine
> > > > and
> > > > supervisor mode) and the HiFive Unleashed board (supervisor
> > > > mode),
> > > > using BBL and OpenSBI.
> > > > Mainline QEMU requires two patches [1, 2] to run in this
> > > > configuration.
> > > > 
> > > > [1]: https://patchwork.ozlabs.org/patch/1039493/
> > > > [2]: https://patchwork.ozlabs.org/patch/1039082/
> > > > 
> > > > Changes in v2:
> > > > - Remove unneeded quotes from NR_CPUS Kconfig entry
> > > > - Move memory barrier from send_ipi_many() to handle_ipi()
> > > > - Add check in send_ipi_many so that IPIs are only sent to
> > > > available
> > > > harts as indicated by the available_harts mask
> > > > - Implement hart lottery to pick main hart to run U-Boot
> > > > - Remove CONFIG_MAIN_HART as it is not required anymore
> > > > - Register available harts in the available_harts mask
> > > > - New patch to populate register a0 with the hart ID from the
> > > > mhartid CSR in machine-mode
> > > > - New patch to enable SMP on the SiFive FU540, which was
> > > > previously
> > > > sent independently
> > > > 
> > > > Lukas Auer (9):
> > > >   riscv: add infrastructure for calling functions on other
> > > > harts
> > > >   riscv: import the supervisor binary interface header file
> > > >   riscv: implement IPI platform functions using SBI
> > > >   riscv: delay initialization of caches and debug UART
> > > >   riscv: add support for multi-hart systems
> > > >   riscv: boot images passed to bootm on all harts
> > > >   riscv: do not rely on hart ID passed by previous boot stage
> > > >   riscv: fu540: enable SMP
> > > >   riscv: qemu: enable SMP
> > > > 
> > > >  arch/riscv/Kconfig   |  28 +
> > > >  arch/riscv/cpu/cpu.c |   9 +-
> > > >  arch/riscv/cpu/start.S   | 152
> > > > +--
> > > >  arch/riscv/include/asm/csr.h |   1 +
> > > >  arch/riscv/include/asm/global_data.h |   6 ++
> > > >  arch/riscv/include/asm/sbi.h |  94 +
> > > >  arch/riscv/include/asm/smp.h |  53 ++
> > > >  arch/riscv/lib/Makefile  |   2 +
> > > >  arch/riscv/lib/asm-offsets.c |   1 +
> > > >  arch/riscv/lib/bootm.c   |  13 ++-
> > > >  arch/riscv/lib/sbi_ipi.c |  25 +
> > > >  arch/riscv/lib/smp.c | 116
> > > > 
> > > >  board/emulation/qemu-riscv/Kconfig   |   1 +
> > > >  board/sifive/fu540/Kconfig   |   1 +
> > > >  14 files changed, 492 insertions(+), 10 deletions(-)  create
> > > > mode
> > > > 100644
> > > > arch/riscv/include/asm/sbi.h  create mode 100644
> > > > arch/riscv/include/asm/smp.h  create mode 100644
> > > > arch/riscv/lib/sbi_ipi.c create mode 100644
> > > > arch/riscv/lib/smp.c
> > > > 
> > > > --
> > > > 2.20.1
> > > 
> > > I tried this series on U-Boot-2019.04-rc3 and works fine on
> > > SiFive
> > > Unleashed board.
> > > 
> > > Tested-by: Anup Patel 
> > > 
> > > I have also pushed these patches to riscv_sifive_fu540_smp_v4
> > > branch
> > > of https://github.com/avpatel/u-boot.git
> > > 
> > 
> > Thank you for testing the series, Anup!
> > Did you observe anymore issues, where not all harts enter Linux?
> 
> I tried using cold-boot (using power-on button) worked fine for me
> 10 times. I did not try more.
> 
> We are trying to make OpenSBI stable with warm-boot (using reset
> button) as well but I have not tried that with U-Boot using 

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

[Michal Simek]

On 28. 02. 19 23:28, Luca Ceresoli wrote:
> 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_MAJOR  1
>  #define ZYNQMP_PM_VERSION_MINOR  0
> 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)
> 

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Auer, Lukas]

On Wed, 2019-03-06 at 13:01 +0100, Andreas Schwab wrote:
> On Mär 06 2019, Anup Patel  wrote:
> 
> > On Wed, Mar 6, 2019 at 5:17 PM Andreas Schwab 
> > wrote:
> > > On Mär 06 2019, Anup Patel  wrote:
> > > 
> > > > > -Original Message-
> > > > > From: Andreas Schwab 
> > > > > Sent: Wednesday, March 6, 2019 4:27 PM
> > > > > To: Anup Patel 
> > > > > Cc: Auer, Lukas ; 
> > > > > u-boot@lists.denx.de;
> > > > > paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
> > > > > bar...@tkos.co.il; daniel.schwierz...@gmail.com; 
> > > > > bmeng...@gmail.com;
> > > > > r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish
> > > > > Patra
> > > > > 
> > > > > Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> > > > > 
> > > > > Apparently sometimes u-boot tries to boot the kernel on heart
> > > > > 0 (the E51
> > > > > core), which will then fail to start userspace, since that
> > > > > cannot cope with the
> > > > > missing fpu.
> > > > 
> > > > That's not possible
> > > 
> > > Yes, it is.
> > > 
> > > 
> > > OpenSBI v0.3 (Mar  6 2019 10:55:01)
> > >_  _
> > >   / __ \  / |  _ \_   _|
> > >  | |  | |_ __   ___ _ __ | (___ | |_) || |
> > >  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
> > >  | |__| | |_) |  __/ | | |) | |_) || |_
> > >   \/| .__/ \___|_| |_|_/|/_|
> > > | |
> > > |_|
> > > 
> > > Platform Name  : SiFive Freedom U540
> > > Platform HART Features : RV64ACDFIMSU
> > > Platform Max HARTs : 5
> > > Current Hart   : 2
> > > Firmware Base  : 0x8000
> > > Firmware Size  : 88 KB
> > > Runtime SBI Version: 0.1
> > > 
> > > PMP0: 0x8000-0x8001 (A)
> > > PMP1: 0x-0x007f (A,R,W,X)
> > > 
> > > 
> > > U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10
> > > +0100)
> > > 
> > > CPU:   rv64imac
> > > Model: sifive,hifive-unleashed-a00
> > > DRAM:  8 GiB
> > 
> > How does this prove that U-Boot is booting on HART 0?
> 
> See the CPU isa.
> 

Interesting.. U-Boot assumes that it can run on any core it is started
on. In this case, OpenSBI must have booted its payload on hart 0.

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

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

[Michal Simek]

On 28. 02. 19 23:28, Luca Ceresoli wrote:
> 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_ACCESS0x1U
> +#define PM_CAP_CONTEXT   0x2U
> +#define PM_CAP_WAKEUP0x4U
> +/**@}*/
> +
> +/**
> + * 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 {

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Andreas Schwab]

On Mär 06 2019, Anup Patel  wrote:

> On Wed, Mar 6, 2019 at 5:17 PM Andreas Schwab  wrote:
>>
>> On Mär 06 2019, Anup Patel  wrote:
>>
>> >> -Original Message-
>> >> From: Andreas Schwab 
>> >> Sent: Wednesday, March 6, 2019 4:27 PM
>> >> To: Anup Patel 
>> >> Cc: Auer, Lukas ; u-boot@lists.denx.de;
>> >> paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
>> >> bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com;
>> >> r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish Patra
>> >> 
>> >> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
>> >>
>> >> Apparently sometimes u-boot tries to boot the kernel on heart 0 (the E51
>> >> core), which will then fail to start userspace, since that cannot cope 
>> >> with the
>> >> missing fpu.
>> >
>> > That's not possible
>>
>> Yes, it is.
>>
>>
>> OpenSBI v0.3 (Mar  6 2019 10:55:01)
>>_  _
>>   / __ \  / |  _ \_   _|
>>  | |  | |_ __   ___ _ __ | (___ | |_) || |
>>  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
>>  | |__| | |_) |  __/ | | |) | |_) || |_
>>   \/| .__/ \___|_| |_|_/|/_|
>> | |
>> |_|
>>
>> Platform Name  : SiFive Freedom U540
>> Platform HART Features : RV64ACDFIMSU
>> Platform Max HARTs : 5
>> Current Hart   : 2
>> Firmware Base  : 0x8000
>> Firmware Size  : 88 KB
>> Runtime SBI Version: 0.1
>>
>> PMP0: 0x8000-0x8001 (A)
>> PMP1: 0x-0x007f (A,R,W,X)
>>
>>
>> U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10 +0100)
>>
>> CPU:   rv64imac
>> Model: sifive,hifive-unleashed-a00
>> DRAM:  8 GiB
>
> How does this prove that U-Boot is booting on HART 0?

See the CPU isa.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Anup Patel]

On Wed, Mar 6, 2019 at 5:17 PM Andreas Schwab  wrote:
>
> On Mär 06 2019, Anup Patel  wrote:
>
> >> -Original Message-
> >> From: Andreas Schwab 
> >> Sent: Wednesday, March 6, 2019 4:27 PM
> >> To: Anup Patel 
> >> Cc: Auer, Lukas ; u-boot@lists.denx.de;
> >> paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
> >> bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com;
> >> r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish Patra
> >> 
> >> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> >>
> >> Apparently sometimes u-boot tries to boot the kernel on heart 0 (the E51
> >> core), which will then fail to start userspace, since that cannot cope 
> >> with the
> >> missing fpu.
> >
> > That's not possible
>
> Yes, it is.
>
>
> OpenSBI v0.3 (Mar  6 2019 10:55:01)
>_  _
>   / __ \  / |  _ \_   _|
>  | |  | |_ __   ___ _ __ | (___ | |_) || |
>  | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
>  | |__| | |_) |  __/ | | |) | |_) || |_
>   \/| .__/ \___|_| |_|_/|/_|
> | |
> |_|
>
> Platform Name  : SiFive Freedom U540
> Platform HART Features : RV64ACDFIMSU
> Platform Max HARTs : 5
> Current Hart   : 2
> Firmware Base  : 0x8000
> Firmware Size  : 88 KB
> Runtime SBI Version: 0.1
>
> PMP0: 0x8000-0x8001 (A)
> PMP1: 0x-0x007f (A,R,W,X)
>
>
> U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10 +0100)
>
> CPU:   rv64imac
> Model: sifive,hifive-unleashed-a00
> DRAM:  8 GiB

How does this prove that U-Boot is booting on HART 0?

This seems to be warm reset issues for which fixes from Atish are
not yet merged.

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

[U-Boot] [PATCH] common: spl_fit: Allow firmware image if no loadables

[Abel Vesa]

If CONFIG_SPL_OS_BOOT and FIT_IMAGE_TINY are enabled,
the os will not be set to anything and therefore will
remain as IH_OS_INVALID. What's needed here is to
have IH_OS_U_BOOT as default. And since using the
mkimage oneline command (that is, no its file), the
loadables can't be specified, so we allow firmware
as a fallback.

Signed-off-by: Abel Vesa 
---
 common/spl/spl_fit.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/common/spl/spl_fit.c b/common/spl/spl_fit.c
index db43626..d5aa792 100644
--- a/common/spl/spl_fit.c
+++ b/common/spl/spl_fit.c
@@ -478,11 +478,14 @@ int spl_load_simple_fit(struct spl_image_info *spl_image,
 
/* Now check if there are more images for us to load */
for (; ; index++) {
-   uint8_t os_type = IH_OS_INVALID;
+   uint8_t os_type = IH_OS_U_BOOT;
 
node = spl_fit_get_image_node(fit, images, "loadables", index);
if (node < 0)
-   break;
+   node = spl_fit_get_image_node(fit, images,
+ "firmware", index);
+   if (node < 0)
+   break;
 
ret = spl_load_fit_image(info, sector, fit, base_offset, node,
 _info);
-- 
2.7.4

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

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Andreas Schwab]

On Mär 06 2019, Anup Patel  wrote:

>> -Original Message-
>> From: Andreas Schwab 
>> Sent: Wednesday, March 6, 2019 4:27 PM
>> To: Anup Patel 
>> Cc: Auer, Lukas ; u-boot@lists.denx.de;
>> paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
>> bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com;
>> r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish Patra
>> 
>> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
>> 
>> Apparently sometimes u-boot tries to boot the kernel on heart 0 (the E51
>> core), which will then fail to start userspace, since that cannot cope with 
>> the
>> missing fpu.
>
> That's not possible

Yes, it is.


OpenSBI v0.3 (Mar  6 2019 10:55:01)
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name  : SiFive Freedom U540
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 5
Current Hart   : 2
Firmware Base  : 0x8000
Firmware Size  : 88 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x007f (A,R,W,X)


U-Boot 2019.04-rc3-00010-g3ea5582c09 (Mar 06 2019 - 10:06:10 +0100)

CPU:   rv64imac
Model: sifive,hifive-unleashed-a00
DRAM:  8 GiB

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Anup Patel]

> -Original Message-
> From: Andreas Schwab 
> Sent: Wednesday, March 6, 2019 4:27 PM
> To: Anup Patel 
> Cc: Auer, Lukas ; u-boot@lists.denx.de;
> paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
> bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com;
> r...@andestech.com; s...@denx.de; pal...@sifive.com; Atish Patra
> 
> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> 
> Apparently sometimes u-boot tries to boot the kernel on heart 0 (the E51
> core), which will then fail to start userspace, since that cannot cope with 
> the
> missing fpu.

That's not possible because in this series we have "available_hart_mask"
to track HARTs that entered U-Boot.

Recently, Atish made some progress with OpenSBI warm-boot issues. I
will let him provide details about it.

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

Re: [U-Boot] [PATCH v2 1/2] x86: TunnelCreek: switch P state to the highest freq

[Andy Shevchenko]

On Thu, Feb 28, 2019 at 11:29:50AM +0800, Bin Meng wrote:
> On Thu, May 24, 2018 at 12:00 PM Bin Meng  wrote:
> > On Thu, Apr 12, 2018 at 4:07 PM, Christian Gmeiner
> >  wrote:

> So to me this seems to match my understanding about EIST. If this is
> true, then I can't explain why Christian's patch is needed since the
> EIST is disabled on TunnelCreek by default and the processor should
> already run at the highest performance.

The some internal documents I found suggesting that first what one needs to do
is to be sure that EIST is enabled / disabled by reading a bit from CPUID.

(There is no mention of the exact bit, I'm guessing it might be X86_FEATURE_EST)

It also refers to IA32_MISC_ENABLE MSR, i.e. bit 20
(MSR_IA32_MISC_ENABLE_SPEEDSTEP_LOCK_BIT) and bit 16
(MSR_IA32_MISC_ENABLE_ENHANCED_SPEEDSTEP_BIT), that firmware can set up
accordingly.

Hope this helps.

P.S. All names are implying Linux kernel source code.

-- 
With Best Regards,
Andy Shevchenko


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

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Andreas Schwab]

Apparently sometimes u-boot tries to boot the kernel on heart 0 (the E51
core), which will then fail to start userspace, since that cannot cope
with the missing fpu.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot, 2/2] rockchip: Drop call to rockchip_dnl_mode_check() for now【请注意，邮件由u-boot-boun...@lists.denx.de代发】【请注意，邮件由s...@google.com代发】

[Andy Yan]

Hi Simon:

On 2019/2/12 下午11:31, Simon Glass wrote:

HI Andy,

On Tue, 12 Feb 2019 at 04:05, Andy Yan  wrote:

Hi Philipp:

  Sorry for the late reply, we just come back from the Chinese Spring
Festival.

On 2019/2/1 下午6:26, Philipp Tomsich wrote:

Kever,

Independent of whether we revert this for the current cycle (and also
independent of
if I ever find the other patch you had been referring to — I couldn’t
find it in my local
mailing list archive) and then deprecate it for the next release
(unless converted to
DM), we still have a number of architectural issues that need to be
addressed:

I still doubt  is this a right  work-flow for patch apply. Before we
apply  a patch  which will break many other boards , should we  make
sure there is a solution patch applied for these boars first?



1.This really should be a driver under DTS control.
2.We need to not get away from configuring SOM-specific addresses via
Kconfig

Both these issues are technical debt that we’ve accumulated over the
last 18 months
and need to address for the sake of future maintainability.
E.g. ‘setting an address to 0x0 via Kconfig to disable a
driver/feature’ really isn’t in line
with the architectural direction of U-Boot.


For technical side, I think CONFIG_ROCKCHIP_BOOT_MODE_REG is necessary
here, we will read this register from save_boot_params when we get out
from bootrom,  the dtb is not available at this point.

Yes this is happening very early, but I wonder why this is necessary?
Can it be moved to later?

The call to check_back_to_brom_dnl_flag() happens much later so there
should be no problem to convert that.


On the other hand, almost rockchip based products use a recovery key to
enter download(upgrade)mode, this is a muti-funtion key, most of them
reuse with vol+- key,  we would like the u-boot share

dtb with linux kernel. To keep the linux kernel dts as clean as possible
,we don't want to add another dts property to describe this key either.
This is why I implement function rockchip_dnl_key_pressed as __weak.


OK, but given that it is called later, it seems to me that it could
use a driver.




We can't let it called later. See the discuss here : 
http://patchwork.ozlabs.org/patch/812228/




Regards,
Simon



I don’t have my own house completely in order (I’ve been talking for a
year now about
finally wrapping the RGMII/GMII selection into an ioctl-call to a
driver) yet, but that doesn’t
mean that we we should delay this clean-up more than absolutely necessary.

Thanks,
Philipp.


On 01.02.2019, at 10:34, Philipp Tomsich
mailto:philipp.toms...@theobroma-systems.com>> wrote:




On 01.02.2019, at 10:32, Kever Yang mailto:kever.y...@rock-chips.com>> wrote:

Hi Philipp,

This is not right,  this patch should not merged like this!!!

I have give my review comment in previous mail, and this will break
many boards.

My another patch do not break anything, but you insist NAK it
without acceptable reason;

What other patch?
I don’t remember seeing that one...


This patch definitely break other board and I have comment it, but
you just ignore other people's review and merge it, good job!

Thanks,
- Kever
On 02/01/2019 05:12 AM, Philipp Tomsich wrote:

This function causes a 5-second delay and stops the display working on
minnie. This code should be in a driver and should only be enabled by
a device-tree property, so that it does not affect devices which
do not
have this feature.

Signed-off-by: Simon Glass mailto:s...@chromium.org>>
Reviewed-by: Philipp Tomsich
mailto:philipp.toms...@theobroma-systems.com>>
---

arch/arm/mach-rockchip/boot_mode.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)


Applied to u-boot-rockchip, thanks!
___
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 mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 3/6] i2c: rcar_i2c: Fix sending of slave addresses

[Ismael Luceno Cortes]

Do the reset before clearing the MSR, otherwise it may result in a read
or write operation instead if the start condition is repeated.

Signed-off-by: Ismael Luceno 
Reviewed-by: Marek Vasut 
---
 drivers/i2c/rcar_i2c.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
index d7b27204cb..a88fbcf34f 100644
--- a/drivers/i2c/rcar_i2c.c
+++ b/drivers/i2c/rcar_i2c.c
@@ -134,9 +134,11 @@ static int rcar_i2c_set_addr(struct udevice *dev, u8 chip, 
u8 read)
}
 
writel((chip << 1) | read, priv->base + RCAR_I2C_ICMAR);
-   writel(0, priv->base + RCAR_I2C_ICMSR);
+   /* Reset */
writel(RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_MIE | RCAR_I2C_ICMCR_ESG,
   priv->base + RCAR_I2C_ICMCR);
+   /* Clear Status */
+   writel(0, priv->base + RCAR_I2C_ICMSR);
 
ret = wait_for_bit_le32(priv->base + RCAR_I2C_ICMSR, mask,
true, 100, true);
-- 
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 6/6] i2c: rcar_i2c: Move FSDA check to rcar_i2c_recover

[Ismael Luceno Cortes]

Cosmetic change.  Any call to the recover function would need to do the
same check afterwards, so it's sensible to make it part of the function.

Signed-off-by: Ismael Luceno 
---
 drivers/i2c/rcar_i2c.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
index 78ef8acacc..8fe0aadffa 100644
--- a/drivers/i2c/rcar_i2c.c
+++ b/drivers/i2c/rcar_i2c.c
@@ -81,12 +81,13 @@ static int rcar_i2c_finish(struct udevice *dev)
return ret;
 }
 
-static void rcar_i2c_recover(struct udevice *dev)
+static int rcar_i2c_recover(struct udevice *dev)
 {
struct rcar_i2c_priv *priv = dev_get_priv(dev);
u32 mcr = RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_OBPC;
u32 mcra = mcr | RCAR_I2C_ICMCR_FSDA;
int i;
+   u32 mstat;
 
/* Send 9 SCL pulses */
for (i = 0; i < 9; i++) {
@@ -106,6 +107,9 @@ static void rcar_i2c_recover(struct udevice *dev)
udelay(5);
writel(mcra | RCAR_I2C_ICMCR_FSCL, priv->base + RCAR_I2C_ICMCR);
udelay(5);
+
+   mstat = readl(priv->base + RCAR_I2C_ICMSR);
+   return mstat & RCAR_I2C_ICMCR_FSDA ? -EBUSY : 0;
 }
 
 static int rcar_i2c_set_addr(struct udevice *dev, u8 chip, u8 read)
@@ -125,9 +129,7 @@ static int rcar_i2c_set_addr(struct udevice *dev, u8 chip, 
u8 read)
ret = wait_for_bit_le32(priv->base + RCAR_I2C_ICMCR,
RCAR_I2C_ICMCR_FSDA, false, 2, true);
if (ret) {
-   rcar_i2c_recover(dev);
-   val = readl(priv->base + RCAR_I2C_ICMSR);
-   if (val & RCAR_I2C_ICMCR_FSDA) {
+   if (rcar_i2c_recover(dev)) {
dev_err(dev, "Bus busy, aborting\n");
return ret;
}
-- 
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 5/6] i2c: rcar_i2c: Set the slave address from rcar_i2c_xfer

[Ismael Luceno Cortes]

It needs to be done for both reads and writes, so do it at rcar_i2c_xfer
to avoid duplication.

Signed-off-by: Ismael Luceno 
---
 drivers/i2c/rcar_i2c.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
index 9223eaecbf..78ef8acacc 100644
--- a/drivers/i2c/rcar_i2c.c
+++ b/drivers/i2c/rcar_i2c.c
@@ -158,10 +158,6 @@ static int rcar_i2c_read_common(struct udevice *dev, 
struct i2c_msg *msg)
u32 icmcr = RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_MIE;
int i, ret = -EREMOTEIO;
 
-   ret = rcar_i2c_set_addr(dev, msg->addr, 1);
-   if (ret)
-   return ret;
-
for (i = 0; i < msg->len; i++) {
if (msg->len - 1 == i)
icmcr |= RCAR_I2C_ICMCR_FSB;
@@ -188,10 +184,6 @@ static int rcar_i2c_write_common(struct udevice *dev, 
struct i2c_msg *msg)
u32 icmcr = RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_MIE;
int i, ret = -EREMOTEIO;
 
-   ret = rcar_i2c_set_addr(dev, msg->addr, 0);
-   if (ret)
-   return ret;
-
for (i = 0; i < msg->len; i++) {
writel(msg->buf[i], priv->base + RCAR_I2C_ICRXD_ICTXD);
writel(icmcr, priv->base + RCAR_I2C_ICMCR);
@@ -215,6 +207,10 @@ static int rcar_i2c_xfer(struct udevice *dev, struct 
i2c_msg *msg, int nmsgs)
int ret;
 
for (; nmsgs > 0; nmsgs--, msg++) {
+   ret = rcar_i2c_set_addr(dev, msg->addr, 1);
+   if (ret)
+   return ret;
+
if (msg->flags & I2C_M_RD)
ret = rcar_i2c_read_common(dev, msg);
else
@@ -224,7 +220,7 @@ static int rcar_i2c_xfer(struct udevice *dev, struct 
i2c_msg *msg, int nmsgs)
return ret;
}
 
-   return ret;
+   return 0;
 }
 
 static int rcar_i2c_probe_chip(struct udevice *dev, uint addr, uint flags)
-- 
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 4/6] i2c: rcar_i2c: Don't mask errors with EREMOTEIO at rcar_i2c_xfer

[Ismael Luceno Cortes]

Fix rcar_i2c_xfer return value, previously it was always returning
-EREMOTEIO when dealing with errors from calls to the read/write
functions.

Signed-off-by: Ismael Luceno 
---
 drivers/i2c/rcar_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
index a88fbcf34f..9223eaecbf 100644
--- a/drivers/i2c/rcar_i2c.c
+++ b/drivers/i2c/rcar_i2c.c
@@ -221,7 +221,7 @@ static int rcar_i2c_xfer(struct udevice *dev, struct 
i2c_msg *msg, int nmsgs)
ret = rcar_i2c_write_common(dev, msg);
 
if (ret)
-   return -EREMOTEIO;
+   return ret;
}
 
return ret;
-- 
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/6] i2c: rcar_i2c: Setup SCL/SDA delay at rcar_i2c_set_speed

[Ismael Luceno Cortes]

Setting up the delay only needs to be done once; move it to
rcar_i2c_set_speed so it's done at initialization time.

Signed-off-by: Ismael Luceno 
---
 drivers/i2c/rcar_i2c.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
index 10b0f8bad4..a57f72a228 100644
--- a/drivers/i2c/rcar_i2c.c
+++ b/drivers/i2c/rcar_i2c.c
@@ -116,9 +116,7 @@ static int rcar_i2c_set_addr(struct udevice *dev, u8 chip, 
u8 read)
writel(0, priv->base + RCAR_I2C_ICMSR);
writel(priv->icccr, priv->base + RCAR_I2C_ICCCR);
 
-   if (priv->type == RCAR_I2C_TYPE_GEN3)
-   writel(RCAR_I2C_ICFBSCR_TCYC17, priv->base + RCAR_I2C_ICFBSCR);
-
+   /* Wait for the bus */
ret = wait_for_bit_le32(priv->base + RCAR_I2C_ICMCR,
RCAR_I2C_ICMCR_FSDA, false, 2, true);
if (ret) {
@@ -304,6 +302,11 @@ scgd_find:
priv->icccr = (scgd << RCAR_I2C_ICCCR_SCGD_OFF) | cdf;
writel(priv->icccr, priv->base + RCAR_I2C_ICCCR);
 
+   if (priv->type == RCAR_I2C_TYPE_GEN3) {
+   /* Set SCL/SDA delay */
+   writel(RCAR_I2C_ICFBSCR_TCYC17, priv->base + RCAR_I2C_ICFBSCR);
+   }
+
return 0;
 }
 

base-commit: f08023c07d826fbc8e62fdd3367961b2f0b06844
prerequisite-patch-id: 9e5b0458bc15640eb483ccad91dbe85150f9f7be
-- 
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 2/6] i2c: rcar_i2c: Add comments about registers & values

[Ismael Luceno Cortes]

Document the meaning of macros related to registers and values to be
written to them.

Signed-off-by: Ismael Luceno 
---
 drivers/i2c/rcar_i2c.c | 47 +++---
 1 file changed, 26 insertions(+), 21 deletions(-)

diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
index a57f72a228..d7b27204cb 100644
--- a/drivers/i2c/rcar_i2c.c
+++ b/drivers/i2c/rcar_i2c.c
@@ -18,35 +18,40 @@
 #include 
 #include 
 
-#define RCAR_I2C_ICSCR 0x00
-#define RCAR_I2C_ICMCR 0x04
-#define RCAR_I2C_ICMCR_MDBSBIT(7)
-#define RCAR_I2C_ICMCR_FSCLBIT(6)
-#define RCAR_I2C_ICMCR_FSDABIT(5)
-#define RCAR_I2C_ICMCR_OBPCBIT(4)
-#define RCAR_I2C_ICMCR_MIE BIT(3)
+#define RCAR_I2C_ICSCR 0x00 /* slave ctrl */
+#define RCAR_I2C_ICMCR 0x04 /* master ctrl */
+#define RCAR_I2C_ICMCR_MDBSBIT(7) /* non-fifo mode switch */
+#define RCAR_I2C_ICMCR_FSCLBIT(6) /* override SCL pin */
+#define RCAR_I2C_ICMCR_FSDABIT(5) /* override SDA pin */
+#define RCAR_I2C_ICMCR_OBPCBIT(4) /* override pins */
+#define RCAR_I2C_ICMCR_MIE BIT(3) /* master if enable */
 #define RCAR_I2C_ICMCR_TSBEBIT(2)
-#define RCAR_I2C_ICMCR_FSB BIT(1)
-#define RCAR_I2C_ICMCR_ESG BIT(0)
-#define RCAR_I2C_ICSSR 0x08
-#define RCAR_I2C_ICMSR 0x0c
+#define RCAR_I2C_ICMCR_FSB BIT(1) /* force stop bit */
+#define RCAR_I2C_ICMCR_ESG BIT(0) /* enable start bit gen */
+#define RCAR_I2C_ICSSR 0x08 /* slave status */
+#define RCAR_I2C_ICMSR 0x0c /* master status */
 #define RCAR_I2C_ICMSR_MASK0x7f
-#define RCAR_I2C_ICMSR_MNR BIT(6)
-#define RCAR_I2C_ICMSR_MAL BIT(5)
-#define RCAR_I2C_ICMSR_MST BIT(4)
+#define RCAR_I2C_ICMSR_MNR BIT(6) /* Nack */
+#define RCAR_I2C_ICMSR_MAL BIT(5) /* Arbitration lost */
+#define RCAR_I2C_ICMSR_MST BIT(4) /* Stop */
 #define RCAR_I2C_ICMSR_MDE BIT(3)
 #define RCAR_I2C_ICMSR_MDT BIT(2)
 #define RCAR_I2C_ICMSR_MDR BIT(1)
 #define RCAR_I2C_ICMSR_MAT BIT(0)
-#define RCAR_I2C_ICSIER0x10
-#define RCAR_I2C_ICMIER0x14
-#define RCAR_I2C_ICCCR 0x18
+#define RCAR_I2C_ICSIER0x10 /* slave irq enable */
+#define RCAR_I2C_ICMIER0x14 /* master irq enable */
+#define RCAR_I2C_ICCCR 0x18 /* clock dividers */
 #define RCAR_I2C_ICCCR_SCGD_OFF3
-#define RCAR_I2C_ICSAR 0x1c
-#define RCAR_I2C_ICMAR 0x20
-#define RCAR_I2C_ICRXD_ICTXD   0x24
+#define RCAR_I2C_ICSAR 0x1c /* slave address */
+#define RCAR_I2C_ICMAR 0x20 /* master address */
+#define RCAR_I2C_ICRXD_ICTXD   0x24 /* data port */
+/*
+ * First Bit Setup Cycle (Gen3).
+ * Defines 1st bit delay between SDA and SCL.
+ */
 #define RCAR_I2C_ICFBSCR   0x38
-#define RCAR_I2C_ICFBSCR_TCYC170x0f
+#define RCAR_I2C_ICFBSCR_TCYC170x0f /* 17*Tcyc */
+
 
 enum rcar_i2c_type {
RCAR_I2C_TYPE_GEN2,
-- 
2.19.1
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/9] SMP support for RISC-V

[Anup Patel]

> -Original Message-
> From: Auer, Lukas 
> Sent: Wednesday, March 6, 2019 2:52 PM
> To: u-boot@lists.denx.de; Anup Patel 
> Cc: paul.walms...@sifive.com; ag...@suse.de; a...@brainfault.org;
> bar...@tkos.co.il; daniel.schwierz...@gmail.com; bmeng...@gmail.com;
> r...@andestech.com; s...@denx.de; sch...@suse.de; pal...@sifive.com;
> Atish Patra 
> Subject: Re: [PATCH v2 0/9] SMP support for RISC-V
> 
> On Wed, 2019-03-06 at 04:00 +, Anup Patel wrote:
> > > -Original Message-
> > > From: Lukas Auer 
> > > Sent: Wednesday, March 6, 2019 4:23 AM
> > > To: u-boot@lists.denx.de
> > > Cc: Atish Patra ; Anup Patel
> > > ; Bin Meng ; Andreas
> Schwab
> > > ; Palmer Dabbelt ; Alexander
> Graf
> > > ; Lukas Auer ; Anup
> > > Patel ; Anup Patel ; Rick
> > > Chen ; Baruch Siach ; Atish
> > > Patra  ; Stefan Roese ; Paul
> > > Walmsley  ; Daniel Schwierzeck
> > > 
> > > Subject: [PATCH v2 0/9] SMP support for RISC-V
> > >
> > > This patch series adds SMP support for RISC-V to U-Boot. It allows
> > > U-Boot to run on multi-hart systems (hart is the RISC-V terminology
> > > for hardware thread). Images passed to bootm will be started on all
> > > harts.
> > > The bootm command is currently the only one that will boot images on
> > > all harts, bootefi is not yet supported.
> > >
> > > The patches have been successfully tested on both QEMU (machine and
> > > supervisor mode) and the HiFive Unleashed board (supervisor mode),
> > > using BBL and OpenSBI.
> > > Mainline QEMU requires two patches [1, 2] to run in this
> > > configuration.
> > >
> > > [1]: https://patchwork.ozlabs.org/patch/1039493/
> > > [2]: https://patchwork.ozlabs.org/patch/1039082/
> > >
> > > Changes in v2:
> > > - Remove unneeded quotes from NR_CPUS Kconfig entry
> > > - Move memory barrier from send_ipi_many() to handle_ipi()
> > > - Add check in send_ipi_many so that IPIs are only sent to available
> > > harts as indicated by the available_harts mask
> > > - Implement hart lottery to pick main hart to run U-Boot
> > > - Remove CONFIG_MAIN_HART as it is not required anymore
> > > - Register available harts in the available_harts mask
> > > - New patch to populate register a0 with the hart ID from the
> > > mhartid CSR in machine-mode
> > > - New patch to enable SMP on the SiFive FU540, which was previously
> > > sent independently
> > >
> > > Lukas Auer (9):
> > >   riscv: add infrastructure for calling functions on other harts
> > >   riscv: import the supervisor binary interface header file
> > >   riscv: implement IPI platform functions using SBI
> > >   riscv: delay initialization of caches and debug UART
> > >   riscv: add support for multi-hart systems
> > >   riscv: boot images passed to bootm on all harts
> > >   riscv: do not rely on hart ID passed by previous boot stage
> > >   riscv: fu540: enable SMP
> > >   riscv: qemu: enable SMP
> > >
> > >  arch/riscv/Kconfig   |  28 +
> > >  arch/riscv/cpu/cpu.c |   9 +-
> > >  arch/riscv/cpu/start.S   | 152
> > > +--
> > >  arch/riscv/include/asm/csr.h |   1 +
> > >  arch/riscv/include/asm/global_data.h |   6 ++
> > >  arch/riscv/include/asm/sbi.h |  94 +
> > >  arch/riscv/include/asm/smp.h |  53 ++
> > >  arch/riscv/lib/Makefile  |   2 +
> > >  arch/riscv/lib/asm-offsets.c |   1 +
> > >  arch/riscv/lib/bootm.c   |  13 ++-
> > >  arch/riscv/lib/sbi_ipi.c |  25 +
> > >  arch/riscv/lib/smp.c | 116 
> > >  board/emulation/qemu-riscv/Kconfig   |   1 +
> > >  board/sifive/fu540/Kconfig   |   1 +
> > >  14 files changed, 492 insertions(+), 10 deletions(-)  create mode
> > > 100644
> > > arch/riscv/include/asm/sbi.h  create mode 100644
> > > arch/riscv/include/asm/smp.h  create mode 100644
> > > arch/riscv/lib/sbi_ipi.c create mode 100644 arch/riscv/lib/smp.c
> > >
> > > --
> > > 2.20.1
> >
> > I tried this series on U-Boot-2019.04-rc3 and works fine on SiFive
> > Unleashed board.
> >
> > Tested-by: Anup Patel 
> >
> > I have also pushed these patches to riscv_sifive_fu540_smp_v4 branch
> > of https://github.com/avpatel/u-boot.git
> >
> 
> Thank you for testing the series, Anup!
> Did you observe anymore issues, where not all harts enter Linux?

I tried using cold-boot (using power-on button) worked fine for me
10 times. I did not try more.

We are trying to make OpenSBI stable with warm-boot (using reset
button) as well but I have not tried that with U-Boot using reset button.

Regards,
Anup


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

Re: [U-Boot] [PATCH v2 6/6] i2c: rcar_i2c: Move FSDA check to rcar_i2c_recover

[Ismael Luceno Cortes]

On 05/Mar/2019 19:32, Marek Vasut wrote:
> On 3/5/19 12:23 PM, Ismael Luceno Cortes wrote:
> > Cosmetic change.  Any call to the recover function would need to do the
> > same check afterwards, so it's sensible to make it part of the function.
> > 
> > Signed-off-by: Ismael Luceno 
> > ---
> > 
> > Notes:
> > Changes since v1:
> > - Rebased on top of patch 1050650 ("i2c: rcar_i2c: Add Gen3 SoC 
> > support")
> > - Explained the change
> > - Replaced C99-style variable declaration
> > 
> >  drivers/i2c/rcar_i2c.c | 10 ++
> >  1 file changed, 6 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/i2c/rcar_i2c.c b/drivers/i2c/rcar_i2c.c
> > index 4556b115bd..21bcf09101 100644
> > --- a/drivers/i2c/rcar_i2c.c
> > +++ b/drivers/i2c/rcar_i2c.c
> > @@ -77,12 +77,13 @@ static int rcar_i2c_finish(struct udevice *dev)
> > return ret;
> >  }
> >  
> > -static void rcar_i2c_recover(struct udevice *dev)
> > +static int rcar_i2c_recover(struct udevice *dev)
> >  {
> > struct rcar_i2c_priv *priv = dev_get_priv(dev);
> > u32 mcr = RCAR_I2C_ICMCR_MDBS | RCAR_I2C_ICMCR_OBPC;
> > u32 mcra = mcr | RCAR_I2C_ICMCR_FSDA;
> > int i;
> > +   u32 ret;
> 
> Can you change this to "reg" or something like that ? $ret is usually a
> signed int return value, so this could be confusing.

Ok.
 
> >  
> > /* Send 9 SCL pulses */
> > for (i = 0; i < 9; i++) {
> > @@ -102,6 +103,9 @@ static void rcar_i2c_recover(struct udevice *dev)
> > udelay(5);
> > writel(mcra | RCAR_I2C_ICMCR_FSCL, priv->base + RCAR_I2C_ICMCR);
> > udelay(5);
> > +
> > +   ret = readl(priv->base + RCAR_I2C_ICMSR);
> > +   return ret & RCAR_I2C_ICMCR_FSDA;
> 
> What about doing this instead
> 
> reg = readl...
> if (reg & ...FSDA)
>   return -EBUSY;
> 
> return 0;
> 
> That way, the code will use standard errno.h return values.

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

[U-Boot] [PATCH] arm: mvebu: theadorable: Add test for ctrl-c in PCIe PEX switch test

[Stefan Roese]

The check for the missing PEX switch can lead to an infinite loop, when
the PCIe device is not found. It is helpful to enable the user to break
out of this boot-loop, to enable booting to the prompt for test cases.
This patch adds a 3 second delay in the error case before rebooting.
The user can press Ctrl-C in this time to abort the boot-loop.

This patch also calls bootcount_inc() before rebooting in the error
case. This is needed to increment the bootcounter, since this function
is called earlier than the main bootcounter increment. Otherwise the
bootcounter will not be incremented in the error case at all.

Signed-off-by: Stefan Roese 
---
 board/theadorable/theadorable.c | 32 ++--
 1 file changed, 30 insertions(+), 2 deletions(-)

diff --git a/board/theadorable/theadorable.c b/board/theadorable/theadorable.c
index 1169d67746..9e7623837b 100644
--- a/board/theadorable/theadorable.c
+++ b/board/theadorable/theadorable.c
@@ -1,11 +1,15 @@
 // SPDX-License-Identifier: GPL-2.0+
 /*
- * Copyright (C) 2015-2016 Stefan Roese 
+ * Copyright (C) 2015-2019 Stefan Roese 
  */
 
 #include 
+#include 
 #include 
 #include 
+#if !defined(CONFIG_SPL_BUILD)
+#include 
+#endif
 #include 
 #include 
 #include 
@@ -42,6 +46,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define STM_I2C_BUS1
 #define STM_I2C_ADDR   0x27
 #define REBOOT_DELAY   1000/* reboot-delay in ms */
+#define ABORT_TIMEOUT  3000/* 3 seconds reboot abort timeout */
 
 /* DDR3 static configuration */
 static MV_DRAM_MC_INIT ddr3_theadorable[MV_MAX_DDR3_STATIC_SIZE] = {
@@ -238,7 +243,7 @@ int board_video_init(void)
return mvebu_lcd_register_init(_info);
 }
 
-#ifdef CONFIG_BOARD_LATE_INIT
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_BOARD_LATE_INIT)
 int board_late_init(void)
 {
pci_dev_t bdf;
@@ -252,6 +257,7 @@ int board_late_init(void)
 */
bdf = pci_find_device(PCI_VENDOR_ID_PLX, 0x8619, 0);
if (bdf == -1) {
+   unsigned long start_time = get_timer(0);
u8 i2c_buf[8];
int ret;
 
@@ -259,6 +265,28 @@ int board_late_init(void)
bootcount = bootcount_load();
printf("Failed to find PLX PEX-switch (bootcount=%ld)\n",
   bootcount);
+
+   /*
+* The user can exit this boot-loop in the error case by
+* hitting Ctrl-C. So wait some time for this key here.
+*/
+   printf("Continue booting with Ctrl-C, otherwise rebooting\n");
+   do {
+   /* Handle control-c and timeouts */
+   if (ctrlc()) {
+   printf("PEX error boot-loop aborted!\n");
+   return 0;
+   }
+   } while (get_timer(start_time) < ABORT_TIMEOUT);
+
+
+   /*
+* At this stage the bootcounter has not been incremented
+* yet. We need to do this manually here to get an actually
+* working bootcounter in this error case.
+*/
+   bootcount_inc();
+
if (bootcount > PEX_SWITCH_NOT_FOUNT_LIMIT) {
printf("Issuing power-switch via uC!\n");
 
-- 
2.21.0

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

[U-Boot] [PATCH] arm: exynos: odroid: Fix build if BOARD_TYPES are not set

[Krzysztof Kozlowski]

CONFIG_BOARD_TYPES is necessary for Odroid X/X2/U3 boards to detect
proper revision.  However building should succeed even without it.
While moving code around, document also the reference clock selection.

This fixes the build error without CONFIG_BOARD_TYPES:

board/samsung/odroid/odroid.c: In function 'board_usb_init':
board/samsung/odroid/odroid.c:473:8: error: 'gd_t' {aka 'volatile struct 
global_data'} has no member named 'board_type'
  if (gd->board_type == ODROID_TYPE_U3)
^~

Signed-off-by: Krzysztof Kozlowski 
---
 board/samsung/odroid/odroid.c | 27 +--
 1 file changed, 21 insertions(+), 6 deletions(-)

diff --git a/board/samsung/odroid/odroid.c b/board/samsung/odroid/odroid.c
index 552333fe869d..b11d99223346 100644
--- a/board/samsung/odroid/odroid.c
+++ b/board/samsung/odroid/odroid.c
@@ -462,18 +462,33 @@ struct dwc2_plat_otg_data s5pc210_otg_data = {
 
 #if defined(CONFIG_USB_GADGET) || defined(CONFIG_CMD_USB)
 
+static void set_usb3503_ref_clk(void)
+{
+#ifdef CONFIG_BOARD_TYPES
+   /*
+* gpx3-0 chooses primary (low) or secondary (high) reference clock
+* frequencies table.  The choice of clock is done through hard-wired
+* REF_SEL pins.
+* The Odroid Us have reference clock at 24 MHz (00 entry from secondary
+* table) and Odroid Xs have it at 26 MHz (01 entry from primary table).
+*/
+   if (gd->board_type == ODROID_TYPE_U3)
+   gpio_direction_output(EXYNOS4X12_GPIO_X30, 0);
+   else
+   gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
+#else
+   /* Choose Odroid Xs frequency without board types */
+   gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
+#endif /* CONFIG_BOARD_TYPES */
+}
+
 int board_usb_init(int index, enum usb_init_type init)
 {
 #ifdef CONFIG_CMD_USB
struct udevice *dev;
int ret;
 
-   /* Set Ref freq 0 => 24MHz, 1 => 26MHz*/
-   /* Odroid Us have it at 24MHz, Odroid Xs at 26MHz */
-   if (gd->board_type == ODROID_TYPE_U3)
-   gpio_direction_output(EXYNOS4X12_GPIO_X30, 0);
-   else
-   gpio_direction_output(EXYNOS4X12_GPIO_X30, 1);
+   set_usb3503_ref_clk();
 
/* Disconnect, Reset, Connect */
gpio_direction_output(EXYNOS4X12_GPIO_X34, 0);
-- 
2.7.4

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

Re: [U-Boot] [PATCH v4 00/25] MTD defconfigs/Kconfigs/Makefiles heavy cleanup

[Miquel Raynal]

Hi Jagan,

Miquel Raynal  wrote on Wed, 20 Feb 2019
08:08:58 +0100:

> Hi Vignesh,
> 
> Vignesh R  wrote on Wed, 20 Feb 2019 10:50:18 +0530:
> 
> > Hi Jagan,
> > 
> > On 09/12/18 11:37 PM, Miquel Raynal wrote:  
> > > Hello,
> > > 
> > > During my last project about SPI-NAND support in U-Boot, I discovered
> > > when modifying Makefiles a confusing organization where:
> > > * Sub-directories/files are compiled from the root Makefile
> > > * Commands are at the root of everything
> > > 
> > > I sent a fist series a few weeks ago to move Makefile entries in their
> > > respective directories (which needed to be reworked). Since then, I
> > > have been working on clarifying all this for the MTD subsystem and
> > > here are the main points of such re-organization:
> > > * Rename CONFIG_MTD into CONFIG_DM_MTD to reserve CONFIG_MTD to what
> > >   is called today CONFIG_MTD_DEVICE.
> > > * Fix build dependencies in defconfigs, like: "UBI and NAND depend on 
> > > MTD".
> > > * Fix the Kconfig files to reflect these dependencies (as defconfigs
> > >   have been updated, nothing should break).
> > > * Simplify the Makefiles: compiling the drivers/mtd/nand/raw/
> > >   sub-directory should just depend on MTD being compiled and the NAND
> > >   core as well, there is absolutely no logic to make it depend on
> > >   CMD_NAND.
> > > 
> > > New green Travis CI build for the third version of this series:
> > > https://travis-ci.org/miquelraynal/u-boot/builds/463486099
> > > There are three Sandbox tests that are failing, they have not been
> > > break by this series. The following Travis test has been done on the
> > > commit on which has been based the series and shows the same errors:
> > > https://travis-ci.org/miquelraynal/u-boot/builds/463593006
> > > 
> > 
> > I would like to revive this series. With some rebasing, this series
> > should still apply as is.
> > 
> > Jagan, did you get a chance to look into this series? Any comments?  
> 
> Thanks for reviving the series, actually I was sure it was merged by
> that time as AFAIR there was no more opposition to it.
> 
> Jagan, I see it is still marked 'new' on patchwork and assigned to
> you, would you mind applying it?

Gentle 3-month-later ping. Jagan, please consider this series.


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