date:20190624

On Tue, Jun 25, 2019 at 10:51 AM Ramon Fried  wrote:
>
> On Mon, Jun 24, 2019 at 7:03 AM Anup Patel  wrote:
> > The SiFive MACB ethernet has a custom TX_CLK_SEL register to select
> > different TX clock for 1000mbps vs 10/100mbps.
> >
> > This patch adds SiFive MACB compatible string and extends the MACB
> > ethernet driver to change TX clock using TX_CLK_SEL register for
> > SiFive MACB.
> >
> > Signed-off-by: Anup Patel 
> > ---
> >   drivers/net/macb.c | 86 +-
> >   1 file changed, 69 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> > index c072f99d8f..727cb0bc49 100644
> > --- a/drivers/net/macb.c
> > +++ b/drivers/net/macb.c
> > @@ -83,7 +83,9 @@ struct macb_dma_desc {
> >
> >   struct macb_device {
> >  void*regs;
> > -   unsigned intdma_burst_length;
> > +   void*regs1;
> This is just littering the macb_device with RISCV soc specifics,
> basically this is the SOC's
> mapping of clock tree. there's no clock tree support here, but you
> should map and use it in the
> the clock init function.
>
> > +
> > +   const struct macb_config*config;
> >
> >  unsigned intrx_tail;
> >  unsigned inttx_head;
> > @@ -123,6 +125,9 @@ struct macb_device {
> >
> >   struct macb_config {
> >  unsigned intdma_burst_length;
> > +
> > +   int (*probe)(struct udevice *dev);
> > +   int (*set_tx_clk)(struct udevice *dev, ulong 
> > rate);
> Let's be more generic, let's call this function clk_init and
> initialize all the clocks there.
> A good approach will be that by default we'll call the current clock
> configuration.
> In your case you should create a new callback function that calls the
> current clock function and also
> configures the specific tx clock.

Yes, that's what we are doing. If set_tx_clk() is not available then
we fallback to current clock configuration method.

I am not attached to set_tx_clk() function name so I will just
rename it to clk_init().

> >   };
> >
> >   #ifndef CONFIG_DM_ETH
> > @@ -483,21 +488,32 @@ static int macb_phy_find(struct macb_device *macb, 
> > const char *name)
> >* when operation failed.
> >*/
> >   #ifdef CONFIG_DM_ETH
> > +static int macb_sifive_set_tx_clk(struct udevice *dev, ulong rate)
> > +{
> > +   struct macb_device *macb = dev_get_priv(dev);
> > +
> > +   if (!macb->regs1)
> > +   return -ENODEV;
> > +
> > +   /*
> > +* SiFive GEMGXL TX clock operation mode:
> > +*
> > +* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
> > +* and output clock on GMII output signal GTX_CLK
> > +* 1 = MII mode. Use MII input signal TX_CLK in TX logic
> > +*/
> > +   writel(rate != 12500, macb->regs1);
> > +   return 0;
> > +}
> > +
> >   int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
> >   {
> >   #ifdef CONFIG_CLK
> > +   struct macb_device *macb = dev_get_priv(dev);
> >  struct clk tx_clk;
> >  ulong rate;
> >  int ret;
> >
> > -   /*
> > -* "tx_clk" is an optional clock source for MACB.
> > -* Ignore if it does not exist in DT.
> > -*/
> > -   ret = clk_get_by_name(dev, "tx_clk", _clk);
> > -   if (ret)
> > -   return 0;
> > -
> >  switch (speed) {
> >  case _10BASET:
> >  rate = 250; /* 2.5 MHz */
> > @@ -513,6 +529,17 @@ int __weak macb_linkspd_cb(struct udevice *dev, 
> > unsigned int speed)
> >  return 0;
> >  }
> >
> > +   if (macb->config->set_tx_clk)
> > +   return macb->config->set_tx_clk(dev, rate);
> > +
> > +   /*
> > +* "tx_clk" is an optional clock source for MACB.
> > +* Ignore if it does not exist in DT.
> > +*/
> > +   ret = clk_get_by_name(dev, "tx_clk", _clk);
> > +   if (ret)
> > +   return 0;
> > +
> >  if (tx_clk.dev) {
> >  ret = clk_set_rate(_clk, rate);
> >  if (ret)
> > @@ -701,12 +728,14 @@ static void gmac_configure_dma(struct macb_device 
> > *macb)
> >  u32 buffer_size;
> >  u32 dmacfg;
> >
> > +   if (!macb->config->dma_burst_length)
> > +   return;
> > +
> Don't skip it, we configure other things as well, including buffer size,
> which I just sent a patch that on GEM it sets it to 2K, greatly improving
> performance.

Already updated in v8 patch.

>
> >  buffer_size = 128 / RX_BUFFER_MULTIPLE;
> >  dmacfg = gem_readl(macb, DMACFG) & ~GEM_BF(RXBS, -1L);
> >  dmacfg |= GEM_BF(RXBS, buffer_size);
> >
> > -   if (macb->dma_burst_length)
> > -   dmacfg = GEM_BFINS(FBLDO, macb->dma_burst_length, dmacfg);
> > +   dmacfg = GEM_BFINS(FBLDO,

Re: [U-Boot] [PATCH V2 1/3] test: dm: adc: use the real device name

2019-06-24 Thread Peng Fan


> Subject: Re: [PATCH V2 1/3] test: dm: adc: use the real device name
> 
> On Wed, Jun 19, 2019 at 02:17:59AM +, Peng Fan wrote:
> > Hi Simon, Tom
> > > Subject: [PATCH V2 1/3] test: dm: adc: use the real device name
> > >
> > > "adc" is not the real device name, "adc@0" is.
> > >
> > > Signed-off-by: Peng Fan 
> >
> > Will you pick up this patchset?
> > https://patchwork.ozlabs.org/patch/1103212/
> > https://patchwork.ozlabs.org/patch/1103213/
> > https://patchwork.ozlabs.org/patch/1103214/
> 
> For the next release.  Or should they really come in now?  Thanks!

Could wait next release.

Thanks,
Peng.

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

Re: [U-Boot] [PATCH] arm: mvebu: set 38x and 39x AVS on lower frequency

2019-06-24 Thread Chris Packham

Hi Baruch,

On Mon, Jun 24, 2019 at 8:30 PM Baruch Siach  wrote:
>
> Reduce Auto Voltage Scaling VDD limit when core frequency is lower than
> 1600MHz. This reduces core voltage level from 1.25V to 1.15V, which
> saves power.
>
> The code is taken from Marvell's U-Boot 2013.01 revision 18.06.
>
> Signed-off-by: Baruch Siach 

I gave it a quick spin on DB-88F6820-AMC and x530. Both booted fine.

Reviewed-by: Chris Packham 
Tested-by: Chris Packham 

> ---
>  arch/arm/mach-mvebu/include/mach/cpu.h|  3 +++
>  arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c | 26 +++
>  arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h |  4 +++
>  arch/arm/mach-mvebu/spl.c |  3 +++
>  4 files changed, 36 insertions(+)
>
> diff --git a/arch/arm/mach-mvebu/include/mach/cpu.h 
> b/arch/arm/mach-mvebu/include/mach/cpu.h
> index e6140d67293e..e1128ee90f01 100644
> --- a/arch/arm/mach-mvebu/include/mach/cpu.h
> +++ b/arch/arm/mach-mvebu/include/mach/cpu.h
> @@ -163,6 +163,9 @@ int serdes_phy_config(void);
>   */
>  int ddr3_init(void);
>
> +/* Auto Voltage Scaling */
> +void mv_avs_init(void);
> +
>  /*
>   * get_ref_clk
>   *
> diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c 
> b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
> index d387893af37d..e9dd096ad0f5 100644
> --- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
> +++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.c
> @@ -256,3 +256,29 @@ u8 sys_env_device_rev_get(void)
> value = reg_read(DEV_VERSION_ID_REG);
> return (value & (REVISON_ID_MASK)) >> REVISON_ID_OFFS;
>  }
> +
> +void mv_avs_init(void)
> +{
> +   u32 sar_freq;
> +
> +   if (!(IS_ENABLED(CONFIG_ARMADA_38X) || IS_ENABLED(CONFIG_ARMADA_39X)))
> +   return;
> +
> +   reg_write(AVS_DEBUG_CNTR_REG, AVS_DEBUG_CNTR_DEFAULT_VALUE);
> +   reg_write(AVS_DEBUG_CNTR_REG, AVS_DEBUG_CNTR_DEFAULT_VALUE);
> +
> +   sar_freq = reg_read(DEVICE_SAMPLE_AT_RESET1_REG);
> +   sar_freq = sar_freq >> SAR_FREQ_OFFSET & SAR_FREQ_MASK;
> +
> +   /* Set AVS value only for core frequency of 1600MHz or less.
> +* For higher frequency leave the default value.
> +*/
> +   if (sar_freq <= 0xd) {
> +   u32 avs_reg_data = reg_read(AVS_ENABLED_CONTROL);
> +
> +   avs_reg_data &= ~(AVS_LOW_VDD_LIMIT_MASK
> +   | AVS_HIGH_VDD_LIMIT_MASK);
> +   avs_reg_data |= AVS_LOW_VDD_SLOW_VAL | AVS_HIGH_VDD_SLOW_VAL;
> +   reg_write(AVS_ENABLED_CONTROL, avs_reg_data);
> +   }
> +}
> diff --git a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h 
> b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
> index 365332d2b048..1774a5b780ca 100644
> --- a/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
> +++ b/arch/arm/mach-mvebu/serdes/a38x/sys_env_lib.h
> @@ -33,6 +33,8 @@
>  #define DEV_ID_REG_DEVICE_ID_OFFS  16
>  #define DEV_ID_REG_DEVICE_ID_MASK  0x
>
> +#define SAR_FREQ_OFFSET10
> +#define SAR_FREQ_MASK  0x1f
>  #define SAR_DEV_ID_OFFS27
>  #define SAR_DEV_ID_MASK0x7
>
> @@ -155,10 +157,12 @@
>  #define AVS_LOW_VDD_LIMIT_OFFS 4
>  #define AVS_LOW_VDD_LIMIT_MASK (0xff << AVS_LOW_VDD_LIMIT_OFFS)
>  #define AVS_LOW_VDD_LIMIT_VAL  (0x27 << AVS_LOW_VDD_LIMIT_OFFS)
> +#define AVS_LOW_VDD_SLOW_VAL   (0x23 << AVS_LOW_VDD_LIMIT_OFFS)
>
>  #define AVS_HIGH_VDD_LIMIT_OFFS12
>  #define AVS_HIGH_VDD_LIMIT_MASK(0xff << 
> AVS_HIGH_VDD_LIMIT_OFFS)
>  #define AVS_HIGH_VDD_LIMIT_VAL (0x27 << AVS_HIGH_VDD_LIMIT_OFFS)
> +#define AVS_HIGH_VDD_SLOW_VAL  (0x23 << AVS_HIGH_VDD_LIMIT_OFFS)
>
>  /* Board ID numbers */
>  #define MARVELL_BOARD_ID_MASK  0x10
> diff --git a/arch/arm/mach-mvebu/spl.c b/arch/arm/mach-mvebu/spl.c
> index d54de5195624..3cb27b7f4b20 100644
> --- a/arch/arm/mach-mvebu/spl.c
> +++ b/arch/arm/mach-mvebu/spl.c
> @@ -126,6 +126,9 @@ void board_init_f(ulong dummy)
> ddr3_init();
>  #endif
>
> +   /* Initialize Auto Voltage Scaling */
> +   mv_avs_init();
> +
> /*
>  * Return to the BootROM to continue the Marvell xmodem
>  * UART boot protocol. As initiated by the kwboot tool.
> --
> 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 v7 6/9] net: macb: Extend MACB driver for SiFive Unleashed board


On Mon, Jun 24, 2019 at 7:03 AM Anup Patel  wrote:

The SiFive MACB ethernet has a custom TX_CLK_SEL register to select
different TX clock for 1000mbps vs 10/100mbps.

This patch adds SiFive MACB compatible string and extends the MACB
ethernet driver to change TX clock using TX_CLK_SEL register for
SiFive MACB.

Signed-off-by: Anup Patel 
---
  drivers/net/macb.c | 86 +-
  1 file changed, 69 insertions(+), 17 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index c072f99d8f..727cb0bc49 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -83,7 +83,9 @@ struct macb_dma_desc {

  struct macb_device {
 void*regs;
-   unsigned intdma_burst_length;
+   void*regs1;

This is just littering the macb_device with RISCV soc specifics,
basically this is the SOC's
mapping of clock tree. there's no clock tree support here, but you
should map and use it in the
the clock init function.


+
+   const struct macb_config*config;

 unsigned intrx_tail;
 unsigned inttx_head;
@@ -123,6 +125,9 @@ struct macb_device {

  struct macb_config {
 unsigned intdma_burst_length;
+
+   int (*probe)(struct udevice *dev);
+   int (*set_tx_clk)(struct udevice *dev, ulong rate);

Let's be more generic, let's call this function clk_init and
initialize all the clocks there.
A good approach will be that by default we'll call the current clock
configuration.
In your case you should create a new callback function that calls the
current clock function and also
configures the specific tx clock.

  };

  #ifndef CONFIG_DM_ETH
@@ -483,21 +488,32 @@ static int macb_phy_find(struct macb_device *macb, const 
char *name)
   * when operation failed.
   */
  #ifdef CONFIG_DM_ETH
+static int macb_sifive_set_tx_clk(struct udevice *dev, ulong rate)
+{
+   struct macb_device *macb = dev_get_priv(dev);
+
+   if (!macb->regs1)
+   return -ENODEV;
+
+   /*
+* SiFive GEMGXL TX clock operation mode:
+*
+* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
+* and output clock on GMII output signal GTX_CLK
+* 1 = MII mode. Use MII input signal TX_CLK in TX logic
+*/
+   writel(rate != 12500, macb->regs1);
+   return 0;
+}
+
  int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
  {
  #ifdef CONFIG_CLK
+   struct macb_device *macb = dev_get_priv(dev);
 struct clk tx_clk;
 ulong rate;
 int ret;

-   /*
-* "tx_clk" is an optional clock source for MACB.
-* Ignore if it does not exist in DT.
-*/
-   ret = clk_get_by_name(dev, "tx_clk", _clk);
-   if (ret)
-   return 0;
-
 switch (speed) {
 case _10BASET:
 rate = 250; /* 2.5 MHz */
@@ -513,6 +529,17 @@ int __weak macb_linkspd_cb(struct udevice *dev, unsigned 
int speed)
 return 0;
 }

+   if (macb->config->set_tx_clk)
+   return macb->config->set_tx_clk(dev, rate);
+
+   /*
+* "tx_clk" is an optional clock source for MACB.
+* Ignore if it does not exist in DT.
+*/
+   ret = clk_get_by_name(dev, "tx_clk", _clk);
+   if (ret)
+   return 0;
+
 if (tx_clk.dev) {
 ret = clk_set_rate(_clk, rate);
 if (ret)
@@ -701,12 +728,14 @@ static void gmac_configure_dma(struct macb_device *macb)
 u32 buffer_size;
 u32 dmacfg;

+   if (!macb->config->dma_burst_length)
+   return;
+

Don't skip it, we configure other things as well, including buffer size,
which I just sent a patch that on GEM it sets it to 2K, greatly improving
performance.


 buffer_size = 128 / RX_BUFFER_MULTIPLE;
 dmacfg = gem_readl(macb, DMACFG) & ~GEM_BF(RXBS, -1L);
 dmacfg |= GEM_BF(RXBS, buffer_size);

-   if (macb->dma_burst_length)
-   dmacfg = GEM_BFINS(FBLDO, macb->dma_burst_length, dmacfg);
+   dmacfg = GEM_BFINS(FBLDO, macb->config->dma_burst_length, dmacfg);

 dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
 dmacfg &= ~GEM_BIT(ENDIA_PKT);
@@ -1171,13 +1200,25 @@ static const struct macb_config default_gem_config = {
 .dma_burst_length = 16,
  };

+static int macb_sifive_probe(struct udevice *dev)
+{
+   struct macb_device *macb = dev_get_priv(dev);
+   fdt_addr_t addr;
+
+   addr = dev_read_addr_index(dev, 1);
+   if (addr == FDT_ADDR_T_NONE)
+   return -ENODEV;
+   macb->regs1 = (void __iomem *)addr;
+
+   return 0;
+}

Can we get rid of this and place it in the clock init function instead?

+
  static int macb_eth_probe(struct udevice *dev)
  {
-   const struct macb_config *macb_config;
 struct eth_pdata *pdata =

Re: [U-Boot] [PATCH v8 9/9] net: macb: Fix check for little-endian system in gmac_configure_dma()

On Tue, Jun 25, 2019 at 7:15 AM Anup Patel  wrote:
>
> Instead of depending on CONFIG_SYS_LITTLE_ENDIAN, we check at runtime
> whether underlying system is little-endian or big-endian. This way
> we are not dependent on any U-Boot specific OR compiler specific macro
> to check system endianness.
>
> Signed-off-by: Anup Patel 
> Reviewed-by: Bin Meng 
> ---
>  drivers/net/macb.c | 12 
>  1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/macb.c b/drivers/net/macb.c
> index 7fedb9ae0e..942d469572 100644
> --- a/drivers/net/macb.c
> +++ b/drivers/net/macb.c
> @@ -85,6 +85,8 @@ struct macb_device {
> void*regs;
> void*regs1;
>
> +   boolis_big_endian;
> +
> const struct macb_config*config;
>
> unsigned intrx_tail;
> @@ -739,11 +741,10 @@ static void gmac_configure_dma(struct macb_device *macb)
> dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
> dmacfg &= ~GEM_BIT(ENDIA_PKT);
>
> -#ifdef CONFIG_SYS_LITTLE_ENDIAN
> -   dmacfg &= ~GEM_BIT(ENDIA_DESC);
> -#else
> +   if (macb->is_big_endian)
> dmacfg |= GEM_BIT(ENDIA_DESC); /* CPU in big endian */
> -#endif
> +   else
> +   dmacfg &= ~GEM_BIT(ENDIA_DESC);
>
> dmacfg &= ~GEM_BIT(ADDR64);
> gem_writel(macb, DMACFG, dmacfg);
> @@ -1230,6 +1231,9 @@ static int macb_eth_probe(struct udevice *dev)
>
> macb->regs = (void *)pdata->iobase;
>
> +   macb->is_big_endian = (cpu_to_be32(0x12345678) == 0x12345678) ?
> +   true : false;
> +
> macb->config = (struct macb_config *)dev_get_driver_data(dev);
> if (!macb->config)
> macb->config = _gem_config;
> --
> 2.17.1
>
Reviewed-By: Ramon Fried 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] pull request: raspberry pi updates


On 6/25/19 5:51 AM, Jonathan Gray wrote:

On Mon, Jun 24, 2019 at 02:11:43PM -0400, Tom Rini wrote:

On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:

On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:

On 6/12/19 10:08 PM, Tom Rini wrote:

On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:

On 6/12/19 9:56 PM, Tom Rini wrote:

On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:

Hi Matthias,

Have these been out on the list for general review? I don't remember
seeing them.

On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger  wrote:


Hi Tom,

Please have a look on the following patches.

Regards,
Matthias

---
The following changes since commit fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:

   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)

are available in the Git repository at:

   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07

for you to fetch changes up to 38e58ff2b785b45e8c8ade8e23f916a1984016c6:

   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER (2019-06-12 
12:23:46
+0200)


- fix complation error for CONFIG_USB
- update RPi3 DTBs to v5.1-rc6 state
- add defconfig for RPi3 B+


Why do we need a separate config when it's detected and works
perfectly well with the standard rpi_3 and rpi_3_32b configs?


Good question.  It came from Heinrich, so Heinrich?


If we call the bootefi command without a OS supplied device tree the
U-Boot device tree is passed to the operating system.

So we need a device tree which is a complete description of the
respective system.

On the Linaro boot-architecture list there has been a lengthy discussion
with Linaro people thinking that it is the responsibility of the
hardware and firmware to provide the correct device tree and not of the OS.


OK, but on Pi aren't we passed, and pass along, the dtb from the
previous stage?


Currently `bootefi` uses as default what it finds in $fdt_control_addr
and provides this to GRUB, Linux, or any other payload.


Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
in a device tree, that U-Boot then uses?


I haven't taken this as I haven't gotten an answer to this part.  I
could have sworn that the proprietary loader passed along the device
tree that's passed by us to the next stage.


The firmware includes device trees

https://github.com/raspberrypi/firmware/tree/master/boot

At least OpenSUSE, OpenBSD and Fedora change the rpi defconfigs to
better use it:

https://src.fedoraproject.org/rpms/uboot-tools/blob/master/f/rpi-Enable-using-the-DT-provided-by-the-Raspberry-Pi.patch
https://github.com/openSUSE/u-boot/commit/121d9d775c6af6ba5d1c3f198f478404a9196f84.patch


From 121d9d775c6af6ba5d1c3f198f478404a9196f84 Mon Sep 17 00:00:00 2001

From: Alexander Graf 
Date: Wed, 21 Feb 2018 17:41:13 +0100
Subject: [PATCH] rpi: Use firmware provided device tree

Currently the firmware generates a device tree for us that we could
just use to adjust ourselves. We then on boot throw that away and
use our own built-in device tree to configure device access.

This is bad for a multitude of reasons. For starters, it breaks
overlay support in config.txt, confusing users. Much worse however
is that we are stuck with individual U-Boot builds per board.
The firmware can easily give us the right DT depending on the
target board and revision though.

So let's use the firmware provided device tree instead. That way
U-Boot as well as payloads loaded by it can automatically adapt
to variants of RPi hardware.

Signed-off-by: Alexander Graf 
Signed-off-by: Guillaume Gardet 


This patch never made it into mainline U-Boot but it is still applicable.

So what is your suggestion? Drop all RPI device trees and apply this
patch? (CCing Alex)

Why does the patch not remove CONFIG_DEFAULT_DEVICE_TREE?
Why does the patch not reduce the number of config files to 2: one for
32bit and one for 64bit if everything else is given by the board
provided DTB?

Regards

Heinrich


---
  configs/rpi_0_w_defconfig   | 2 +-
  configs/rpi_2_defconfig | 2 +-
  configs/rpi_3_32b_defconfig | 2 +-
  configs/rpi_3_defconfig | 2 +-
  configs/rpi_defconfig   | 2 +-
  5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index 1ab35f1b253..d26010efac1 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y
  CONFIG_CMD_MMC=y
  CONFIG_CMD_USB=y
  CONFIG_CMD_FS_UUID=y
-CONFIG_OF_EMBED=y
+CONFIG_OF_BOARD=y
  CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-zero-w"
  CONFIG_ENV_FAT_INTERFACE="mmc"
  CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index 53aa554cc74..2b6bbf1b4b4 100644
--- a/configs/rpi_2_defconfig
+++ b/configs/rpi_2_defconfig
@@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y
  CONFIG_CMD_MMC=y
  CONFIG_CMD_USB=y
  CONFIG_CMD_FS_UUID=y
-CONFIG_OF_EMBED=y

Re: [U-Boot] efi_loader: implementing non-volatile UEFI variables


On 6/25/19 3:10 AM, AKASHI Takahiro wrote:

On Mon, Jun 24, 2019 at 09:10:07PM +0200, Heinrich Schuchardt wrote:

On 6/24/19 8:50 PM, Wolfgang Denk wrote:

Dear Heinrich,

In message <7083d208-4b3c-7261-a03b-9066dc8d2...@gmx.de> you wrote:


to be really useful UEFI variables should be available to the operating
system. This is not possible using U-Boot variables as storage.


Oops?  Is it possible that you are not aware of the
tools/env/fw_env* code?


I am fully aware of this.


Oops, I don't know, but


Think about secure boot. It is a bad idea to expose variables in this way.


Actually, we are thinking of disabling U-Boot environment (I mean,
ENV_IS_NOWHERE) still allowing for UEFI variables for security reason.

One of the differences between U-Boot env and UEFI variables
is that the former can and should be saved to backing storage
only with explicit "saveenv" command, while the latter are
expected to be saved immediately.

Preserving respective semantics simultaneously would be possible, but
it would make the implementation a bit complicated and ugly.
Instead, I believe that it will be a clever idea that we should have
separate contexts for them as I showed in my non-volatile support patch[1].

[1] https://lists.denx.de/pipermail/u-boot/2019-June/371601.html

One of possible improvements here is to refactor the env code and
parameterize "contexts" at env_save()/env_load().



Of course U-Boot environment variables can be accessed (read and
written) from Linux.


And maybe a fourth dummy one implementing no variable service at all.


Is this really a good idea?


Tom is always complaining that the UEFI subsystem has become too large.


And I agree on that.  But even if it was not the case, having four
different implementations for the same thing is  sub-optiman.


We have a lot of things that can be disabled in U-Boot. Why should we
not be able to disable UEFI variables?


To be honest, I'm a bit doubtful about practical meaning of
disabling UEFI variables for UEFI execution environment.


I will drop
https://lists.denx.de/pipermail/u-boot/2019-June/373915.html
"efi_debug: make variable support customizable"
to stop that discussion. We still can introduce the customization option
once the OP-TEE option has been worked out.

Concerning your patch
https://lists.denx.de/pipermail/u-boot/2019-June/371602.html
"env: save UEFI non-volatile variables in dedicated storage"
What do you think about Wolfgang's propositions below to adjust
env_save() to provide a volatile/non-volatile flag for normal U-Boot
variables?

Best regards

Heinrich




What Linaro is doing with OP-TEE makes sense to enable secure boot. But
it will be an ARM64 specific solution.



And if the "volatile" feature is all that is missing when using
environment variables, then this should be the road taken:

- It avoids a complete new implementation
- It can be added witrh very little effort
- It would be just a minimal increase in memory footprinmt
- It is useful for a lot of other pirposes as well.

What are your agruments for _not_ taking this approach?


See my comment above.


UEFI variables should be accessible via the UEFI runtime API and not via
some U-Boot specific hack which no other program but U-Boot cares about.


Please notice that one of the reasons that prevents UEFI variables
from being accessed by OS is a real hardware(device/controller) may be
shared between firmware(i.e. UEFI runtime) and OS and mutually exclusive
access must be ensured.

-Takahiro Akashi


Best regards

Heinrich




The best solution for UEFI variables would be to live in the secure part
of the ARM trusted firmware.


You think too narrow. Not all the world is ARM, and not everyone
uses ATF.


UEFI variables have both a name and a GUID as keys.


Internally U-Boot variables are stored in a hash table; you could
easily add GUID support.  the external storage format is also simple
enough.  You could extend it in a compatible way for example from

=\0

to something like

;=\0

of, if you don't want to waste another separator character, even

==\0

Extending the env import parser and the env export code for this
does not look like rocket science either.


Furthermore both
variable names and values are in UTF-16. So they are quite different to
U-Boot variables.


Nothing in U-Boot prevents this.  There is a number of ways to
convert UTF-16 (or even any kind of binary data) to and from plain
ASCII strings, and only your UEFI code needs to understand such
encoding.


Look at this output:

-> printenv

efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={boot,run}(blob)
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLang={nv,boot,run}(blob)656e2d555300
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLangCodes={boot,run}(blob)656e2d555300
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_RuntimeServicesSupported={boot,run}(blob)8004

=> printenv -e

OsIndicationsSupported: BS|RT, DataSize = 0x8
  :

[U-Boot] [PATCH v8 9/9] net: macb: Fix check for little-endian system in gmac_configure_dma()

Instead of depending on CONFIG_SYS_LITTLE_ENDIAN, we check at runtime
whether underlying system is little-endian or big-endian. This way
we are not dependent on any U-Boot specific OR compiler specific macro
to check system endianness.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 drivers/net/macb.c | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 7fedb9ae0e..942d469572 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -85,6 +85,8 @@ struct macb_device {
void*regs;
void*regs1;
 
+   boolis_big_endian;
+
const struct macb_config*config;
 
unsigned intrx_tail;
@@ -739,11 +741,10 @@ static void gmac_configure_dma(struct macb_device *macb)
dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
dmacfg &= ~GEM_BIT(ENDIA_PKT);
 
-#ifdef CONFIG_SYS_LITTLE_ENDIAN
-   dmacfg &= ~GEM_BIT(ENDIA_DESC);
-#else
+   if (macb->is_big_endian)
dmacfg |= GEM_BIT(ENDIA_DESC); /* CPU in big endian */
-#endif
+   else
+   dmacfg &= ~GEM_BIT(ENDIA_DESC);
 
dmacfg &= ~GEM_BIT(ADDR64);
gem_writel(macb, DMACFG, dmacfg);
@@ -1230,6 +1231,9 @@ static int macb_eth_probe(struct udevice *dev)
 
macb->regs = (void *)pdata->iobase;
 
+   macb->is_big_endian = (cpu_to_be32(0x12345678) == 0x12345678) ?
+   true : false;
+
macb->config = (struct macb_config *)dev_get_driver_data(dev);
if (!macb->config)
macb->config = _gem_config;
-- 
2.17.1

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

[U-Boot] [PATCH v8 7/9] riscv: sifive: fu540: Setup ethaddr env variable using OTP

This patch extends SiFive FU540 board support to setup ethaddr
env variable based on board serialnum read from OTP.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 board/sifive/fu540/fu540.c | 122 +
 configs/sifive_fu540_defconfig |   1 +
 2 files changed, 123 insertions(+)

diff --git a/board/sifive/fu540/fu540.c b/board/sifive/fu540/fu540.c
index 5adc4a3d4a..11daf1a75a 100644
--- a/board/sifive/fu540/fu540.c
+++ b/board/sifive/fu540/fu540.c
@@ -8,6 +8,128 @@
 
 #include 
 #include 
+#include 
+#include 
+
+#ifdef CONFIG_MISC_INIT_R
+
+#define FU540_OTP_BASE_ADDR0x1007
+
+struct fu540_otp_regs {
+   u32 pa; /* Address input */
+   u32 paio;   /* Program address input */
+   u32 pas;/* Program redundancy cell selection input */
+   u32 pce;/* OTP Macro enable input */
+   u32 pclk;   /* Clock input */
+   u32 pdin;   /* Write data input */
+   u32 pdout;  /* Read data output */
+   u32 pdstb;  /* Deep standby mode enable input (active low) */
+   u32 pprog;  /* Program mode enable input */
+   u32 ptc;/* Test column enable input */
+   u32 ptm;/* Test mode enable input */
+   u32 ptm_rep;/* Repair function test mode enable input */
+   u32 ptr;/* Test row enable input */
+   u32 ptrim;  /* Repair function enable input */
+   u32 pwe;/* Write enable input (defines program cycle) */
+} __packed;
+
+#define BYTES_PER_FUSE 4
+#define NUM_FUSES  0x1000
+
+static int fu540_otp_read(int offset, void *buf, int size)
+{
+   struct fu540_otp_regs *regs = (void __iomem *)FU540_OTP_BASE_ADDR;
+   unsigned int i;
+   int fuseidx = offset / BYTES_PER_FUSE;
+   int fusecount = size / BYTES_PER_FUSE;
+   u32 fusebuf[fusecount];
+
+   /* check bounds */
+   if (offset < 0 || size < 0)
+   return -EINVAL;
+   if (fuseidx >= NUM_FUSES)
+   return -EINVAL;
+   if ((fuseidx + fusecount) > NUM_FUSES)
+   return -EINVAL;
+
+   /* init OTP */
+   writel(0x01, >pdstb); /* wake up from stand-by */
+   writel(0x01, >ptrim); /* enable repair function */
+   writel(0x01, >pce);   /* enable input */
+
+   /* read all requested fuses */
+   for (i = 0; i < fusecount; i++, fuseidx++) {
+   writel(fuseidx, >pa);
+
+   /* cycle clock to read */
+   writel(0x01, >pclk);
+   mdelay(1);
+   writel(0x00, >pclk);
+   mdelay(1);
+
+   /* read the value */
+   fusebuf[i] = readl(>pdout);
+   }
+
+   /* shut down */
+   writel(0, >pce);
+   writel(0, >ptrim);
+   writel(0, >pdstb);
+
+   /* copy out */
+   memcpy(buf, fusebuf, size);
+
+   return 0;
+}
+
+static u32 fu540_read_serialnum(void)
+{
+   int ret;
+   u32 serial[2] = {0};
+
+   for (int i = 0xfe * 4; i > 0; i -= 8) {
+   ret = fu540_otp_read(i, serial, sizeof(serial));
+   if (ret) {
+   printf("%s: error reading from OTP\n", __func__);
+   break;
+   }
+   if (serial[0] == ~serial[1])
+   return serial[0];
+   }
+
+   return 0;
+}
+
+static void fu540_setup_macaddr(u32 serialnum)
+{
+   /* Default MAC address */
+   unsigned char mac[6] = { 0x70, 0xb3, 0xd5, 0x92, 0xf0, 0x00 };
+
+   /*
+* We derive our board MAC address by ORing last three bytes
+* of board serial number to above default MAC address.
+*
+* This logic of deriving board MAC address is taken from
+* SiFive FSBL and is kept unchanged.
+*/
+   mac[5] |= (serialnum >>  0) & 0xff;
+   mac[4] |= (serialnum >>  8) & 0xff;
+   mac[3] |= (serialnum >> 16) & 0xff;
+
+   /* Update environment variable */
+   eth_env_set_enetaddr("ethaddr", mac);
+}
+
+int misc_init_r(void)
+{
+   /* Set ethaddr environment variable if not set */
+   if (!env_get("ethaddr"))
+   fu540_setup_macaddr(fu540_read_serialnum());
+
+   return 0;
+}
+
+#endif
 
 int board_init(void)
 {
diff --git a/configs/sifive_fu540_defconfig b/configs/sifive_fu540_defconfig
index f78412398e..f19203745e 100644
--- a/configs/sifive_fu540_defconfig
+++ b/configs/sifive_fu540_defconfig
@@ -7,4 +7,5 @@ CONFIG_DISTRO_DEFAULTS=y
 CONFIG_FIT=y
 CONFIG_DISPLAY_CPUINFO=y
 CONFIG_DISPLAY_BOARDINFO=y
+CONFIG_MISC_INIT_R=y
 CONFIG_OF_PRIOR_STAGE=y
-- 
2.17.1

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

[U-Boot] [PATCH v8 8/9] doc: sifive-fu540: Update README for steps to create FW_PAYLOAD

Due changes in DT bindings, we now embed DTB from Linux-5.3 (or
higher) in OpenSBI FW_PAYLOAD along with payload u-boot.bin. This
patch updates SiFive FU540 README to reflect the changes in build
and boot steps.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
Reviewed-by: Alistair Francis 
---
 doc/README.sifive-fu540 | 356 ++--
 1 file changed, 164 insertions(+), 192 deletions(-)

diff --git a/doc/README.sifive-fu540 b/doc/README.sifive-fu540
index fd9f2a8e46..33e03dc861 100644
--- a/doc/README.sifive-fu540
+++ b/doc/README.sifive-fu540
@@ -13,7 +13,8 @@ The support for following drivers are already enabled:
 3. Cadence MACB ethernet driver for networking support.
 
 TODO:
-1. SPI driver is still missing. So MMC card can't be used in U-Boot as of now.
+1. SPI host driver is still missing.
+2. SPI MMC driver does not compile and needs a re-write using U-Boot DM.
 2. U-Boot expects the serial console device entry to be present under /chosen
DT node. Example:
chosen {
@@ -33,16 +34,21 @@ Building
 
 Flashing
 
-The current U-Boot port is supported in S-mode only and loaded from DRAM.
+The current U-Boot port is supported in S-mode only and loaded directly
+into DRAM.
 
-A prior stage (M-mode) firmware/bootloader (e.g OpenSBI or BBL) is required to
-load the u-boot.bin into memory and provide runtime services. The u-boot.bin
-can be given as a payload to the prior stage (M-mode) firmware/bootloader.
+A prior stage (M-mode) firmware/bootloader (e.g OpenSBI) is required to
+boot the u-boot.bin in S-mode and provide M-mode runtime services.
 
-The description of steps required to build the firmware is beyond the scope of
-this document. Please refer OpenSBI or BBL documenation.
+Currently, the u-boot.bin is used as a payload of the OpenSBI FW_PAYLOAD
+firmware. We need to compile OpenSBI with below command:
+make PLATFORM=sifive/fu540 FW_PAYLOAD_PATH= 
FW_PAYLOAD_FDT_PATH=
+(Note: Prefer hifive-unleashed-a00.dtb from Linux-5.3 or higher)
+(Note: Linux-5.2 is also fine but it does not have ethernet DT node)
+
+More detailed description of steps required to build FW_PAYLOAD firmware
+is beyond the scope of this document. Please refer OpenSBI documenation.
 (Note: OpenSBI git repo is at https://github.com/riscv/opensbi.git)
-(Note: BBL git repo is at https://github.com/riscv/riscv-pk.git)
 
 Once the prior stage firmware/bootloader binary is generated, it should be
 copied to the first partition of the sdcard.
@@ -55,20 +61,18 @@ Once you plugin the sdcard and power up, you should see the 
U-Boot prompt.
 
 Sample boot log from HiFive Unleashed board
 ===
-U-Boot 2019.01-00019-gc7953536-dirty (Jan 22 2019 - 11:05:40 -0800)
+U-Boot 2019.07-rc4-00013-g1837f893b0 (Jun 20 2019 - 11:08:48 +0530)
 
 CPU:   rv64imafdc
-Model: sifive,hifive-unleashed-a00
+Model: SiFive HiFive Unleashed A00
 DRAM:  8 GiB
 In:serial@1001
 Out:   serial@1001
 Err:   serial@1001
-Net:
-Warning: ethernet@1009 (eth0) using random MAC address - b6:75:4d:48:50:94
-eth0: ethernet@1009
+Net:   eth0: ethernet@1009
 Hit any key to stop autoboot:  0
 => version
-U-Boot 2019.01-00019-gc7953536-dirty (Jan 22 2019 - 11:05:40 -0800)
+U-Boot 2019.07-rc4-00013-g1837f893b0 (Jun 20 2019 - 11:08:48 +0530)
 
 riscv64-linux-gcc.br_real (Buildroot 2018.11-rc2-3-ga0787e9) 8.2.0
 GNU ld (GNU Binutils) 2.31.1
@@ -79,30 +83,19 @@ Now you can configure your networking, tftp server and use 
tftp boot method to
 load uImage.
 
 ==
-=> setenv ethaddr 70:B3:D5:92:F0:C2
-=> setenv ipaddr 10.196.157.189
-=> setenv serverip 10.11.143.218
-=> setenv gatewayip 10.196.156.1
+=> setenv ipaddr 10.206.5.241
 => setenv netmask 255.255.252.0
-=> bdinfo
-boot_params = 0x
-DRAM bank   = 0x
--> start= 0x8000
--> size = 0x0002
-relocaddr   = 0xfff9
-reloc off   = 0x7fd9
-ethaddr = 70:B3:D5:92:F0:C2
-IP addr = 10.196.157.189
-baudrate= 115200 bps
-=> tftpboot uImage
+=> setenv serverip 10.206.4.143
+=> setenv gateway 10.206.4.1
+=> tftpboot ${kernel_addr_r} /sifive/fu540/uImage
 ethernet@1009: PHY present at 0
 ethernet@1009: Starting autonegotiation...
 ethernet@1009: Autonegotiation complete
-ethernet@1009: link up, 1000Mbps full-duplex (lpa: 0x3800)
+ethernet@1009: link up, 1000Mbps full-duplex (lpa: 0x7c00)
 Using ethernet@1009 device
-TFTP from server 10.11.143.218; our IP address is 10.196.157.189; sending 
through gateway 10.196.156.1
-Filename 'uImage'.
-Load address: 0x8020
+TFTP from server 10.206.4.143; our IP address is 10.206.5.241
+Filename '/sifive/fu540/uImage'.
+Load address: 0x8060
 Loading: #
  #

[U-Boot] [PATCH v8 6/9] net: macb: Extend MACB driver for SiFive Unleashed board

The SiFive MACB ethernet has a custom TX_CLK_SEL register to select
different TX clock for 1000mbps vs 10/100mbps.

This patch adds SiFive MACB compatible string and extends the MACB
ethernet driver to change TX clock using TX_CLK_SEL register for
SiFive MACB.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 drivers/net/macb.c | 86 +-
 1 file changed, 69 insertions(+), 17 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index c072f99d8f..7fedb9ae0e 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -83,7 +83,9 @@ struct macb_dma_desc {
 
 struct macb_device {
void*regs;
-   unsigned intdma_burst_length;
+   void*regs1;
+
+   const struct macb_config*config;
 
unsigned intrx_tail;
unsigned inttx_head;
@@ -123,6 +125,9 @@ struct macb_device {
 
 struct macb_config {
unsigned intdma_burst_length;
+
+   int (*probe)(struct udevice *dev);
+   int (*set_tx_clk)(struct udevice *dev, ulong rate);
 };
 
 #ifndef CONFIG_DM_ETH
@@ -483,21 +488,32 @@ static int macb_phy_find(struct macb_device *macb, const 
char *name)
  * when operation failed.
  */
 #ifdef CONFIG_DM_ETH
+static int macb_sifive_set_tx_clk(struct udevice *dev, ulong rate)
+{
+   struct macb_device *macb = dev_get_priv(dev);
+
+   if (!macb->regs1)
+   return -ENODEV;
+
+   /*
+* SiFive GEMGXL TX clock operation mode:
+*
+* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
+* and output clock on GMII output signal GTX_CLK
+* 1 = MII mode. Use MII input signal TX_CLK in TX logic
+*/
+   writel(rate != 12500, macb->regs1);
+   return 0;
+}
+
 int __weak macb_linkspd_cb(struct udevice *dev, unsigned int speed)
 {
 #ifdef CONFIG_CLK
+   struct macb_device *macb = dev_get_priv(dev);
struct clk tx_clk;
ulong rate;
int ret;
 
-   /*
-* "tx_clk" is an optional clock source for MACB.
-* Ignore if it does not exist in DT.
-*/
-   ret = clk_get_by_name(dev, "tx_clk", _clk);
-   if (ret)
-   return 0;
-
switch (speed) {
case _10BASET:
rate = 250; /* 2.5 MHz */
@@ -513,6 +529,17 @@ int __weak macb_linkspd_cb(struct udevice *dev, unsigned 
int speed)
return 0;
}
 
+   if (macb->config->set_tx_clk)
+   return macb->config->set_tx_clk(dev, rate);
+
+   /*
+* "tx_clk" is an optional clock source for MACB.
+* Ignore if it does not exist in DT.
+*/
+   ret = clk_get_by_name(dev, "tx_clk", _clk);
+   if (ret)
+   return 0;
+
if (tx_clk.dev) {
ret = clk_set_rate(_clk, rate);
if (ret)
@@ -705,8 +732,9 @@ static void gmac_configure_dma(struct macb_device *macb)
dmacfg = gem_readl(macb, DMACFG) & ~GEM_BF(RXBS, -1L);
dmacfg |= GEM_BF(RXBS, buffer_size);
 
-   if (macb->dma_burst_length)
-   dmacfg = GEM_BFINS(FBLDO, macb->dma_burst_length, dmacfg);
+   if (macb->config->dma_burst_length)
+   dmacfg = GEM_BFINS(FBLDO,
+  macb->config->dma_burst_length, dmacfg);
 
dmacfg |= GEM_BIT(TXPBMS) | GEM_BF(RXBMS, -1L);
dmacfg &= ~GEM_BIT(ENDIA_PKT);
@@ -1171,13 +1199,25 @@ static const struct macb_config default_gem_config = {
.dma_burst_length = 16,
 };
 
+static int macb_sifive_probe(struct udevice *dev)
+{
+   struct macb_device *macb = dev_get_priv(dev);
+   fdt_addr_t addr;
+
+   addr = dev_read_addr_index(dev, 1);
+   if (addr == FDT_ADDR_T_NONE)
+   return -ENODEV;
+   macb->regs1 = (void __iomem *)addr;
+
+   return 0;
+}
+
 static int macb_eth_probe(struct udevice *dev)
 {
-   const struct macb_config *macb_config;
struct eth_pdata *pdata = dev_get_platdata(dev);
struct macb_device *macb = dev_get_priv(dev);
const char *phy_mode;
-   __maybe_unused int ret;
+   int ret;
 
phy_mode = fdt_getprop(gd->fdt_blob, dev_of_offset(dev), "phy-mode",
   NULL);
@@ -1190,11 +1230,16 @@ static int macb_eth_probe(struct udevice *dev)
 
macb->regs = (void *)pdata->iobase;
 
-   macb_config = (struct macb_config *)dev_get_driver_data(dev);
-   if (!macb_config)
-   macb_config = _gem_config;
+   macb->config = (struct macb_config *)dev_get_driver_data(dev);
+   if (!macb->config)
+   macb->config = _gem_config;
+
+   if (macb->config->probe) {
+   ret = macb->config->probe(dev);
+   if (ret)
+   return ret;
+   }
 
-   macb->dma_burst_length = macb_config->dma_burst_length;
 #ifdef CONFIG_CLK

[U-Boot] [PATCH v8 5/9] clk: sifive: Drop GEMGXL clock driver

The GEMGXL clock driver is now directly part of Cadence MACB
ethernet driver in upstream Linux kernel. There is no separate
GEMGXL clock driver in upstream Linux kernel hence we drop
GEMGXL clock driver from U-Boot as well.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 board/sifive/fu540/Kconfig   |  1 -
 drivers/clk/sifive/Kconfig   |  7 
 drivers/clk/sifive/Makefile  |  2 --
 drivers/clk/sifive/gemgxl-mgmt.c | 60 
 4 files changed, 70 deletions(-)
 delete mode 100644 drivers/clk/sifive/gemgxl-mgmt.c

diff --git a/board/sifive/fu540/Kconfig b/board/sifive/fu540/Kconfig
index 8eb5e304ab..f46437901d 100644
--- a/board/sifive/fu540/Kconfig
+++ b/board/sifive/fu540/Kconfig
@@ -28,7 +28,6 @@ config BOARD_SPECIFIC_OPTIONS # dummy
imply CMD_PING
imply CLK_SIFIVE
imply CLK_SIFIVE_FU540_PRCI
-   imply CLK_SIFIVE_GEMGXL_MGMT
imply DOS_PARTITION
imply EFI_PARTITION
imply IP_DYN
diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
index d90be1943f..c4d0a1f9b1 100644
--- a/drivers/clk/sifive/Kconfig
+++ b/drivers/clk/sifive/Kconfig
@@ -14,10 +14,3 @@ config CLK_SIFIVE_FU540_PRCI
  Supports the Power Reset Clock interface (PRCI) IP block found in
  FU540 SoCs.  If this kernel is meant to run on a SiFive FU540 SoC,
  enable this driver.
-
-config CLK_SIFIVE_GEMGXL_MGMT
-   bool "GEMGXL management for SiFive FU540 SoCs"
-   depends on CLK_SIFIVE
-   help
- Supports the GEMGXL management IP block found in FU540 SoCs to
- control GEM TX clock operation mode for 10/100/1000 Mbps.
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index 0813360ca7..b224279afb 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -1,5 +1,3 @@
 # SPDX-License-Identifier: GPL-2.0+
 
 obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
-
-obj-$(CONFIG_CLK_SIFIVE_GEMGXL_MGMT)   += gemgxl-mgmt.o
diff --git a/drivers/clk/sifive/gemgxl-mgmt.c b/drivers/clk/sifive/gemgxl-mgmt.c
deleted file mode 100644
index eb37416b5e..00
--- a/drivers/clk/sifive/gemgxl-mgmt.c
+++ /dev/null
@@ -1,60 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2019, Bin Meng 
- */
-
-#include 
-#include 
-#include 
-#include 
-
-struct gemgxl_mgmt_regs {
-   __u32 tx_clk_sel;
-};
-
-struct gemgxl_mgmt_platdata {
-   struct gemgxl_mgmt_regs *regs;
-};
-
-static int gemgxl_mgmt_ofdata_to_platdata(struct udevice *dev)
-{
-   struct gemgxl_mgmt_platdata *plat = dev_get_platdata(dev);
-
-   plat->regs = (struct gemgxl_mgmt_regs *)dev_read_addr(dev);
-
-   return 0;
-}
-
-static ulong gemgxl_mgmt_set_rate(struct clk *clk, ulong rate)
-{
-   struct gemgxl_mgmt_platdata *plat = dev_get_platdata(clk->dev);
-
-   /*
-* GEMGXL TX clock operation mode:
-*
-* 0 = GMII mode. Use 125 MHz gemgxlclk from PRCI in TX logic
-* and output clock on GMII output signal GTX_CLK
-* 1 = MII mode. Use MII input signal TX_CLK in TX logic
-*/
-   writel(rate != 12500, >regs->tx_clk_sel);
-
-   return 0;
-}
-
-const struct clk_ops gemgxl_mgmt_ops = {
-   .set_rate = gemgxl_mgmt_set_rate,
-};
-
-static const struct udevice_id gemgxl_mgmt_match[] = {
-   { .compatible = "sifive,cadencegemgxlmgmt0", },
-   { /* sentinel */ }
-};
-
-U_BOOT_DRIVER(sifive_gemgxl_mgmt) = {
-   .name = "sifive-gemgxl-mgmt",
-   .id = UCLASS_CLK,
-   .of_match = gemgxl_mgmt_match,
-   .ofdata_to_platdata = gemgxl_mgmt_ofdata_to_platdata,
-   .platdata_auto_alloc_size = sizeof(struct gemgxl_mgmt_platdata),
-   .ops = _mgmt_ops,
-};
-- 
2.17.1

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

[U-Boot] [PATCH v8 4/9] clk: sifive: Sync-up main driver with upstream Linux

The DT bindings of SiFive clock driver in upstream Linux has
changes. As-per latest DT bindings, the clock driver takes two
parent clocks and compatible string has also changed.

This patch sync-up SiFive clock driver implementation as-per
upstream Linux so that we now use latest DT bindings.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 drivers/clk/sifive/fu540-prci.c | 96 -
 1 file changed, 60 insertions(+), 36 deletions(-)

diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index ceb318e062..ce0769f2d1 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -158,30 +158,32 @@
  * PRCI per-device instance data
  */
 struct __prci_data {
-   void *base;
-   struct clk parent;
+   void *va;
+   struct clk parent_hfclk;
+   struct clk parent_rtcclk;
 };
 
 /**
  * struct __prci_wrpll_data - WRPLL configuration and integration data
  * @c: WRPLL current configuration record
- * @bypass: fn ptr to code to bypass the WRPLL (if applicable; else NULL)
- * @no_bypass: fn ptr to code to not bypass the WRPLL (if applicable; else 
NULL)
+ * @enable_bypass: fn ptr to code to bypass the WRPLL (if applicable; else 
NULL)
+ * @disable_bypass: fn ptr to code to not bypass the WRPLL (or NULL)
  * @cfg0_offs: WRPLL CFG0 register offset (in bytes) from the PRCI base address
  *
- * @bypass and @no_bypass are used for WRPLL instances that contain a separate
- * external glitchless clock mux downstream from the PLL.  The WRPLL internal
- * bypass mux is not glitchless.
+ * @enable_bypass and @disable_bypass are used for WRPLL instances
+ * that contain a separate external glitchless clock mux downstream
+ * from the PLL.  The WRPLL internal bypass mux is not glitchless.
  */
 struct __prci_wrpll_data {
struct wrpll_cfg c;
-   void (*bypass)(struct __prci_data *pd);
-   void (*no_bypass)(struct __prci_data *pd);
+   void (*enable_bypass)(struct __prci_data *pd);
+   void (*disable_bypass)(struct __prci_data *pd);
u8 cfg0_offs;
 };
 
 struct __prci_clock;
 
+/* struct __prci_clock_ops - clock operations */
 struct __prci_clock_ops {
int (*set_rate)(struct __prci_clock *pc,
unsigned long rate,
@@ -197,8 +199,7 @@ struct __prci_clock_ops {
  * struct __prci_clock - describes a clock device managed by PRCI
  * @name: user-readable clock name string - should match the manual
  * @parent_name: parent name for this clock
- * @ops: struct clk_ops for the Linux clock framework to use for control
- * @hw: Linux-private clock data
+ * @ops: struct __prci_clock_ops for control
  * @pwd: WRPLL-specific data, associated with this clock (if not NULL)
  * @pd: PRCI-specific data associated with this clock (if not NULL)
  *
@@ -232,12 +233,12 @@ struct __prci_clock {
  */
 static u32 __prci_readl(struct __prci_data *pd, u32 offs)
 {
-   return readl(pd->base + offs);
+   return readl(pd->va + offs);
 }
 
 static void __prci_writel(u32 v, u32 offs, struct __prci_data *pd)
 {
-   return writel(v, pd->base + offs);
+   writel(v, pd->va + offs);
 }
 
 /* WRPLL-related private functions */
@@ -279,10 +280,8 @@ static void __prci_wrpll_unpack(struct wrpll_cfg *c, u32 r)
c->flags &= (WRPLL_FLAGS_INT_FEEDBACK_MASK |
 WRPLL_FLAGS_EXT_FEEDBACK_MASK);
 
-   if (r & PRCI_COREPLLCFG0_FSE_MASK)
-   c->flags |= WRPLL_FLAGS_INT_FEEDBACK_MASK;
-   else
-   c->flags |= WRPLL_FLAGS_EXT_FEEDBACK_MASK;
+   /* external feedback mode not supported */
+   c->flags |= WRPLL_FLAGS_INT_FEEDBACK_MASK;
 }
 
 /**
@@ -300,7 +299,7 @@ static void __prci_wrpll_unpack(struct wrpll_cfg *c, u32 r)
  * Returns: a value suitable for writing into a PRCI PLL configuration
  *  register
  */
-static u32 __prci_wrpll_pack(struct wrpll_cfg *c)
+static u32 __prci_wrpll_pack(const struct wrpll_cfg *c)
 {
u32 r = 0;
 
@@ -308,8 +307,9 @@ static u32 __prci_wrpll_pack(struct wrpll_cfg *c)
r |= c->divf << PRCI_COREPLLCFG0_DIVF_SHIFT;
r |= c->divq << PRCI_COREPLLCFG0_DIVQ_SHIFT;
r |= c->range << PRCI_COREPLLCFG0_RANGE_SHIFT;
-   if (c->flags & WRPLL_FLAGS_INT_FEEDBACK_MASK)
-   r |= PRCI_COREPLLCFG0_FSE_MASK;
+
+   /* external feedback mode not supported */
+   r |= PRCI_COREPLLCFG0_FSE_MASK;
 
return r;
 }
@@ -352,7 +352,7 @@ static void __prci_wrpll_write_cfg(struct __prci_data *pd,
 {
__prci_writel(__prci_wrpll_pack(c), pwd->cfg0_offs, pd);
 
-   memcpy(>c, c, sizeof(struct wrpll_cfg));
+   memcpy(>c, c, sizeof(*c));
 }
 
 /* Core clock mux control */
@@ -431,17 +431,17 @@ static int sifive_fu540_prci_wrpll_set_rate(struct 
__prci_clock *pc,
 
r = wrpll_configure_for_rate(>c, rate, parent_rate);
if (r)
-   return -ERANGE;
+   return r;
 
-   if (pwd->bypass)
-   pwd->bypass(pd);
+

[U-Boot] [PATCH v8 2/9] clk: sifive: Sync-up WRPLL library with upstream Linux

Now that SiFive clock driver is merged in upstream Linux, we
sync-up WRPLL library used by SiFive clock driver with upstream
Linux sources.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 drivers/clk/analogbits/wrpll-cln28hpc.c   | 165 --
 drivers/clk/sifive/fu540-prci.c   |  26 +--
 include/linux/clk/analogbits-wrpll-cln28hpc.h |  70 +++-
 3 files changed, 107 insertions(+), 154 deletions(-)

diff --git a/drivers/clk/analogbits/wrpll-cln28hpc.c 
b/drivers/clk/analogbits/wrpll-cln28hpc.c
index 68eb1148b9..776ead319a 100644
--- a/drivers/clk/analogbits/wrpll-cln28hpc.c
+++ b/drivers/clk/analogbits/wrpll-cln28hpc.c
@@ -1,20 +1,9 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (c) 2019 Western Digital Corporation or its affiliates.
- *
- * Copyright (C) 2018 SiFive, Inc.
+ * Copyright (C) 2018-2019 SiFive, Inc.
  * Wesley Terpstra
  * Paul Walmsley
  *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
  * This library supports configuration parsing and reprogramming of
  * the CLN28HPC variant of the Analog Bits Wide Range PLL.  The
  * intention is for this library to be reusable for any device that
@@ -29,6 +18,7 @@
  * References:
  * - Analog Bits "Wide Range PLL Datasheet", version 2015.10.01
  * - SiFive FU540-C000 Manual v1p0, Chapter 7 "Clocking and Reset"
+ *   https://static.dev.sifive.com/FU540-C000-v1.0.pdf
  */
 
 #include 
@@ -84,40 +74,38 @@
  * range selection.
  *
  * Return: The RANGE value to be presented to the PLL configuration inputs,
- * or -1 upon error.
+ * or a negative return code upon error.
  */
 static int __wrpll_calc_filter_range(unsigned long post_divr_freq)
 {
-   u8 range;
-
if (post_divr_freq < MIN_POST_DIVR_FREQ ||
post_divr_freq > MAX_POST_DIVR_FREQ) {
WARN(1, "%s: post-divider reference freq out of range: %lu",
 __func__, post_divr_freq);
-   return -1;
+   return -ERANGE;
}
 
-   if (post_divr_freq < 1100)
-   range = 1;
-   else if (post_divr_freq < 1800)
-   range = 2;
-   else if (post_divr_freq < 3000)
-   range = 3;
-   else if (post_divr_freq < 5000)
-   range = 4;
-   else if (post_divr_freq < 8000)
-   range = 5;
-   else if (post_divr_freq < 13000)
-   range = 6;
-   else
-   range = 7;
-
-   return range;
+   switch (post_divr_freq) {
+   case 0 ... 1099:
+   return 1;
+   case 1100 ... 1799:
+   return 2;
+   case 1800 ... 2999:
+   return 3;
+   case 3000 ... 4999:
+   return 4;
+   case 5000 ... 7999:
+   return 5;
+   case 8000 ... 12999:
+   return 6;
+   }
+
+   return 7;
 }
 
 /**
  * __wrpll_calc_fbdiv() - return feedback fixed divide value
- * @c: ptr to a struct analogbits_wrpll_cfg record to read from
+ * @c: ptr to a struct wrpll_cfg record to read from
  *
  * The internal feedback path includes a fixed by-two divider; the
  * external feedback path does not.  Return the appropriate divider
@@ -132,7 +120,7 @@ static int __wrpll_calc_filter_range(unsigned long 
post_divr_freq)
  * Return: 2 if internal feedback is enabled or 1 if external feedback
  * is enabled.
  */
-static u8 __wrpll_calc_fbdiv(struct analogbits_wrpll_cfg *c)
+static u8 __wrpll_calc_fbdiv(const struct wrpll_cfg *c)
 {
return (c->flags & WRPLL_FLAGS_INT_FEEDBACK_MASK) ? 2 : 1;
 }
@@ -172,7 +160,7 @@ static u8 __wrpll_calc_divq(u32 target_rate, u64 *vco_rate)
*vco_rate = MIN_VCO_FREQ;
} else {
divq = ilog2(s);
-   *vco_rate = target_rate << divq;
+   *vco_rate = (u64)target_rate << divq;
}
 
 wcd_out:
@@ -181,7 +169,7 @@ wcd_out:
 
 /**
  * __wrpll_update_parent_rate() - update PLL data when parent rate changes
- * @c: ptr to a struct analogbits_wrpll_cfg record to write PLL data to
+ * @c: ptr to a struct wrpll_cfg record to write PLL data to
  * @parent_rate: PLL input refclk rate (pre-R-divider)
  *
  * Pre-compute some data used by the PLL configuration algorithm when
@@ -189,46 +177,40 @@ wcd_out:
  * computation when the parent rate remains constant - expected to be
  * the common case.
  *
- * Returns: 0 upon success or -1 if the reference clock rate is out of range.
+ * Returns: 0 upon success or -ERANGE if the reference clock rate is
+ * out of

[U-Boot] [PATCH v8 3/9] clk: sifive: Sync-up DT bindings header with upstream Linux

The location and license header of DT bindings header for SiFive
clock driver has changed in upstream Linux hence this patch.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 drivers/clk/sifive/fu540-prci.c   |  2 +-
 include/dt-bindings/clk/sifive-fu540-prci.h   | 29 ---
 include/dt-bindings/clock/sifive-fu540-prci.h | 18 
 3 files changed, 19 insertions(+), 30 deletions(-)
 delete mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h
 create mode 100644 include/dt-bindings/clock/sifive-fu540-prci.h

diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index cdbf35e871..ceb318e062 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -38,7 +38,7 @@
 
 #include 
 #include 
-#include 
+#include 
 
 /*
  * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
diff --git a/include/dt-bindings/clk/sifive-fu540-prci.h 
b/include/dt-bindings/clk/sifive-fu540-prci.h
deleted file mode 100644
index 531523ea62..00
--- a/include/dt-bindings/clk/sifive-fu540-prci.h
+++ /dev/null
@@ -1,29 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 */
-/*
- * Copyright (c) 2019 Western Digital Corporation or its affiliates.
- *
- * Copyright (C) 2018 SiFive, Inc.
- * Wesley Terpstra
- * Paul Walmsley
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- */
-
-#ifndef __LINUX_CLK_SIFIVE_FU540_PRCI_H
-#define __LINUX_CLK_SIFIVE_FU540_PRCI_H
-
-/* Clock indexes for use by Device Tree data */
-
-#define PRCI_CLK_COREPLL   0
-#define PRCI_CLK_DDRPLL1
-#define PRCI_CLK_GEMGXLPLL 2
-#define PRCI_CLK_TLCLK 3
-
-#endif
diff --git a/include/dt-bindings/clock/sifive-fu540-prci.h 
b/include/dt-bindings/clock/sifive-fu540-prci.h
new file mode 100644
index 00..6a0b70a37d
--- /dev/null
+++ b/include/dt-bindings/clock/sifive-fu540-prci.h
@@ -0,0 +1,18 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018-2019 SiFive, Inc.
+ * Wesley Terpstra
+ * Paul Walmsley
+ */
+
+#ifndef __DT_BINDINGS_CLOCK_SIFIVE_FU540_PRCI_H
+#define __DT_BINDINGS_CLOCK_SIFIVE_FU540_PRCI_H
+
+/* Clock indexes for use by Device Tree data and the PRCI driver */
+
+#define PRCI_CLK_COREPLL  0
+#define PRCI_CLK_DDRPLL   1
+#define PRCI_CLK_GEMGXLPLL2
+#define PRCI_CLK_TLCLK3
+
+#endif
-- 
2.17.1

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

[U-Boot] [PATCH v8 1/9] clk: sifive: Factor-out PLL library as separate module

To match SiFive clock driver with latest Linux, we factor-out PLL
library as separate module under drivers/clk/analogbits.

Signed-off-by: Anup Patel 
Reviewed-by: Bin Meng 
---
 drivers/clk/Kconfig   | 1 +
 drivers/clk/Makefile  | 1 +
 drivers/clk/analogbits/Kconfig| 4 
 drivers/clk/analogbits/Makefile   | 3 +++
 drivers/clk/{sifive => analogbits}/wrpll-cln28hpc.c   | 3 +--
 drivers/clk/sifive/Kconfig| 3 ---
 drivers/clk/sifive/Makefile   | 2 --
 drivers/clk/sifive/fu540-prci.c   | 3 +--
 .../sifive => include/linux/clk}/analogbits-wrpll-cln28hpc.h  | 0
 9 files changed, 11 insertions(+), 9 deletions(-)
 create mode 100644 drivers/clk/analogbits/Kconfig
 create mode 100644 drivers/clk/analogbits/Makefile
 rename drivers/clk/{sifive => analogbits}/wrpll-cln28hpc.c (99%)
 rename {drivers/clk/sifive => include/linux/clk}/analogbits-wrpll-cln28hpc.h 
(100%)

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 96969b9e30..7b81eacf50 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -98,6 +98,7 @@ config CLK_STM32MP1
  Enable the STM32 clock (RCC) driver. Enable support for
  manipulating STM32MP1's on-SoC clocks.
 
+source "drivers/clk/analogbits/Kconfig"
 source "drivers/clk/at91/Kconfig"
 source "drivers/clk/exynos/Kconfig"
 source "drivers/clk/imx/Kconfig"
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 719b9b8e02..f0ced49e5a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o
 obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
 obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
 
+obj-y += analogbits/
 obj-y += imx/
 obj-y += tegra/
 obj-$(CONFIG_ARCH_ASPEED) += aspeed/
diff --git a/drivers/clk/analogbits/Kconfig b/drivers/clk/analogbits/Kconfig
new file mode 100644
index 00..1d25e6f124
--- /dev/null
+++ b/drivers/clk/analogbits/Kconfig
@@ -0,0 +1,4 @@
+# SPDX-License-Identifier: GPL-2.0
+
+config CLK_ANALOGBITS_WRPLL_CLN28HPC
+   bool
diff --git a/drivers/clk/analogbits/Makefile b/drivers/clk/analogbits/Makefile
new file mode 100644
index 00..ec1bb4092b
--- /dev/null
+++ b/drivers/clk/analogbits/Makefile
@@ -0,0 +1,3 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+obj-$(CONFIG_CLK_ANALOGBITS_WRPLL_CLN28HPC)+= wrpll-cln28hpc.o
diff --git a/drivers/clk/sifive/wrpll-cln28hpc.c 
b/drivers/clk/analogbits/wrpll-cln28hpc.c
similarity index 99%
rename from drivers/clk/sifive/wrpll-cln28hpc.c
rename to drivers/clk/analogbits/wrpll-cln28hpc.c
index d377849693..68eb1148b9 100644
--- a/drivers/clk/sifive/wrpll-cln28hpc.c
+++ b/drivers/clk/analogbits/wrpll-cln28hpc.c
@@ -35,8 +35,7 @@
 #include 
 #include 
 #include 
-
-#include "analogbits-wrpll-cln28hpc.h"
+#include 
 
 /* MIN_INPUT_FREQ: minimum input clock frequency, in Hz (Fref_min) */
 #define MIN_INPUT_FREQ 700
diff --git a/drivers/clk/sifive/Kconfig b/drivers/clk/sifive/Kconfig
index 644881b948..d90be1943f 100644
--- a/drivers/clk/sifive/Kconfig
+++ b/drivers/clk/sifive/Kconfig
@@ -1,8 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0
 
-config CLK_ANALOGBITS_WRPLL_CLN28HPC
-   bool
-
 config CLK_SIFIVE
bool "SiFive SoC driver support"
depends on CLK
diff --git a/drivers/clk/sifive/Makefile b/drivers/clk/sifive/Makefile
index f8263e79b7..0813360ca7 100644
--- a/drivers/clk/sifive/Makefile
+++ b/drivers/clk/sifive/Makefile
@@ -1,7 +1,5 @@
 # SPDX-License-Identifier: GPL-2.0+
 
-obj-$(CONFIG_CLK_ANALOGBITS_WRPLL_CLN28HPC)+= wrpll-cln28hpc.o
-
 obj-$(CONFIG_CLK_SIFIVE_FU540_PRCI)+= fu540-prci.o
 
 obj-$(CONFIG_CLK_SIFIVE_GEMGXL_MGMT)   += gemgxl-mgmt.o
diff --git a/drivers/clk/sifive/fu540-prci.c b/drivers/clk/sifive/fu540-prci.c
index 2d47ebc6b1..56084db2e6 100644
--- a/drivers/clk/sifive/fu540-prci.c
+++ b/drivers/clk/sifive/fu540-prci.c
@@ -37,10 +37,9 @@
 #include 
 
 #include 
+#include 
 #include 
 
-#include "analogbits-wrpll-cln28hpc.h"
-
 /*
  * EXPECTED_CLK_PARENT_COUNT: how many parent clocks this driver expects:
  * hfclk and rtcclk
diff --git a/drivers/clk/sifive/analogbits-wrpll-cln28hpc.h 
b/include/linux/clk/analogbits-wrpll-cln28hpc.h
similarity index 100%
rename from drivers/clk/sifive/analogbits-wrpll-cln28hpc.h
rename to include/linux/clk/analogbits-wrpll-cln28hpc.h
-- 
2.17.1

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

[U-Boot] [PATCH v8 0/9] Update SiFive Unleashed Drivers

This series update SiFive Unleashed clock driver and Cadence MACB driver
so that:
1. It is in sync with upstream Linux driver
2. It uses latest DT bindings as-per upstream Linux driver

With this series, we can now use latest DT bindings with U-Boot. I have
tested SiFive Serial driver and Cadence MACB ethernet driver with this
changes and both work fine.

The legacy FSBL will still pass DTB with older DT bindings which will break
the updated SiFive Unleashed clock driver. To tackle this, we have embedded
DTB in OpenSBI FW_PAYLOAD firmware for SiFive Unleashed so that OpenSBI will
override and pass updated DTB to U-Boot.

The updated DTB passed by OpenSBI is in fact the DTB build by upstream Linux
so we can straight away pass this DTB to Linux as well.

This series can be found in riscv_unleashed_clk_sync_v8 branch at:
https://github.com/avpatel/u-boot.git

To try this series use latest OpenSBI at:
https://github.com/riscv/opensbi.git
And Linux-5.2-rc1 from v5.2-rc1_unleashed branch at:
https://github.com/avpatel/linux.git

Changes since v7:
- Update PATCH6 to not treat dma_burst_length = 0 as skip gmac_configure_dma()
- Update PATCH9 to check endianess at runtime

Changes since v6:
- Added separate patch to fix endianess check in gmac_configure_dma()

Changes since v5:
- Addressed Ramon's comments in PATCH6
- Addressed Bin's comments in PATCH7

Changes since v4:
- Rebased patches upon Ramon's MACB changes
  (Refer, https://patchwork.ozlabs.org/patch/1114025/)
- Added PATCH7 to setup ethaddr based on board serial number read from OTP
- Added PATCH8 to update documentation

Changes since v3:
- Extend MACB ethernet driver for SiFive Unleashed board (just like Linux)

Changes since v2:
- Dropped PATCH6 which adds new compatible string to MACB driver because
  more changes are required in MACB driver for different ethernet speeds

Changes since v1:
- Dropped GEMGXL clock driver
- Added new compatible string for SiFive MACB ethernet

Anup Patel (9):
  clk: sifive: Factor-out PLL library as separate module
  clk: sifive: Sync-up WRPLL library with upstream Linux
  clk: sifive: Sync-up DT bindings header with upstream Linux
  clk: sifive: Sync-up main driver with upstream Linux
  clk: sifive: Drop GEMGXL clock driver
  net: macb: Extend MACB driver for SiFive Unleashed board
  riscv: sifive: fu540: Setup ethaddr env variable using OTP
  doc: sifive-fu540: Update README for steps to create FW_PAYLOAD
  net: macb: Fix check for little-endian system in gmac_configure_dma()

 board/sifive/fu540/Kconfig|   1 -
 board/sifive/fu540/fu540.c| 122 ++
 configs/sifive_fu540_defconfig|   1 +
 doc/README.sifive-fu540   | 356 --
 drivers/clk/Kconfig   |   1 +
 drivers/clk/Makefile  |   1 +
 drivers/clk/analogbits/Kconfig|   4 +
 drivers/clk/analogbits/Makefile   |   3 +
 .../{sifive => analogbits}/wrpll-cln28hpc.c   | 168 -
 drivers/clk/sifive/Kconfig|  10 -
 drivers/clk/sifive/Makefile   |   4 -
 drivers/clk/sifive/fu540-prci.c   | 123 +++---
 drivers/clk/sifive/gemgxl-mgmt.c  |  60 ---
 drivers/net/macb.c|  98 +++--
 include/dt-bindings/clk/sifive-fu540-prci.h   |  29 --
 include/dt-bindings/clock/sifive-fu540-prci.h |  18 +
 .../linux/clk}/analogbits-wrpll-cln28hpc.h|  70 ++--
 17 files changed, 559 insertions(+), 510 deletions(-)
 create mode 100644 drivers/clk/analogbits/Kconfig
 create mode 100644 drivers/clk/analogbits/Makefile
 rename drivers/clk/{sifive => analogbits}/wrpll-cln28hpc.c (69%)
 delete mode 100644 drivers/clk/sifive/gemgxl-mgmt.c
 delete mode 100644 include/dt-bindings/clk/sifive-fu540-prci.h
 create mode 100644 include/dt-bindings/clock/sifive-fu540-prci.h
 rename {drivers/clk/sifive => include/linux/clk}/analogbits-wrpll-cln28hpc.h 
(52%)

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

Re: [U-Boot] [PATCH v7 9/9] net: macb: Fix check for little-endian system in gmac_configure_dma()

On Mon, Jun 24, 2019 at 6:37 PM Ramon Fried  wrote:
>
>
> On 6/24/19 4:02 PM, Daniel Schwierzeck wrote:
> > can't you simply remove the non-DM part of the driver and add a
> > device-tree property for the endianess?
> >
> > If that's not possible short-term, than maybe add a Kconfig symbol like 
> > this:
> >
> > config MACB_BIG_ENDIAN
> > bool ""
> > depends on MACB
> > default y if SYS_BIG_ENDIAN
> > default n
> >
> > this way it's automatically sync'ed with
> > CONFIG_SYS_LITTLE_ENDIAN/CONFIG_SYS_BIG_ENDIAN, but a board config
> > could still override this setting.
>
> I can even do better, Linux for instance automatically detects the endianess 
> for the CPU
> by writing to a scratch register on MACB HW and read it back.
>
> But I don't understand the need for a specific board to define anything 
> different than the SYS_ENDIANES for this driver.

Yap, it's very easy to detect endianess at runtime. I will update this
patch accordingly.

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

Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released

2019-06-24 Thread Heiko Schocher

Hello Heinrich,

Am 22.06.2019 um 21:12 schrieb Heinrich Schuchardt:

On 6/22/19 8:15 PM, Simon Glass wrote:

Hi,

On Sat, 22 Jun 2019 at 16:10, Andreas Färber wrote:

Hi Simon,

Am 22.06.19 um 16:55 schrieb Simon Glass:

I'd like to better understand the benefits of the 3-month timeline.

It takes time to learn about a release, package and build it, test it on
various hardware, investigate and report errors, wait for feedback and
fixes, rinse and repeat with the next -rc. Many people don't do this as
their main job.

If we shorten the release cycle, newer boards will get out faster (which
is good) but the overall quality of boards not actively worked on
(because they were working good enough before) will decay, which is bad.
The only way to counteract that would be to automatically test on real
hardware rather than just building, and doing that for all these masses
of boards seems unrealistic.

Here I think you are talking about distributions. But why not just
take every second release?

I have certain had the experience of getting a board our of the
cupboard and finding that the latest U-Boot doesn't work, nor the one
before, nor the three before that.

Are we actually seeing an improvement in regressions? I feel that
testing is the only way to get that.

Perhaps we should select a small subset of boards which do get tested,
and actually have custodians build/test on those for every rc?

What I have been doing before all my recent pull requests is to boot
both an arm32 (Orange Pi) and and an aarch64 (Pine A64 LTS) board via
bootefi and GRUB. To make this easier I am using a Raspberry with a
relay board and a Tizen SD-Wire card (https://wiki.tizen.org/SDWire)
controlling the system under test,
cf https://pbs.twimg.com/media/D5ugi3iX4AAh1bn.jpg:large
What would be needed is scripts to automate the testing including all
the Python tests.

It would make sense to have such test automation for all of our
architectures similar to what Kernel CI (https://kernelci.org/) does.

Yes ... my dream is also we have a lot of boards, on which we can test
automagically. My approach was tbot, with which I made weekly automated
commandline tests (u-boot and linux), see example results from my old
tbot version:

http://xeidos.ddns.net/tests/test_db_auslesen.php#987

(Intentionally link to latest good test, as I found no time yet to
refresh my testsetup to new tbot, see later).

Above webpage is created through a tbot generator, which fills a
mysql database and the webpage is a simple php script. I also speculated
to write a generator to connect to kernel-ci ... but time is the missing
resource.

For the above example tbot and the webserver run on a raspberry pi,
also the raspberry pi is used as "Lab Host" which controlls the board
under test, so cheap hardware costs. It is easy to adapt tbot to your
hardware setup, see [2]

But tbot was a hack as my python skills are not the greatest, so
luckily Harald (added to cc) found time to rewrite it completly from
scratch (many thanks!), see [1] and [2]

Ok, missing here and there functionality from the old version, but
it is much more cleaner ... may you take a look at it, also it is
Open Source, feel free to help and improve tbot!

I use tbot for my daily work, as tbot has also an interactive mode [3],
with which you can use tbot for powering on your board and connect
to for example the u-boot command line). No need anymore to know where
your board is and how to power it on or how to connect to the console.
(Background I mostly have no real physical access to hardware I work
on)

So you can work while developing with tbot, and at the end you have
immediately an automated setup you can integrate into your CI. As
tbot is a commandline tool, this is mostly easy to do.

Also it is possible to call pytest framework [4] from u-boot,
and of course you can call this out of tbot [5].

bye,
Heiko

[1] https://github.com/Rahix/tbot
[2] https://rahix.de/tbot/
[3] https://rahix.de/tbot/getting-started.html#interactive
[4]
http://git.denx.de/?p=u-boot.git;a=blob;f=test/README;h=4bc9ca3a6ae9de0e3ed6ff420c5edfe6027ad2c6;hb=77f6e2dd0551d8a825bab391a1bd6b838874bcd4

[5] result from pytest framework called from tbot
http://xeidos.ddns.net/tbot/id_985/test-log.html

Regards

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

--
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] pull request: raspberry pi updates

2019-06-24 Thread Jonathan Gray

On Mon, Jun 24, 2019 at 02:11:43PM -0400, Tom Rini wrote:
> On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
> > On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
> > > On 6/12/19 10:08 PM, Tom Rini wrote:
> > > >On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
> > > >>On 6/12/19 9:56 PM, Tom Rini wrote:
> > > >>>On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> > > Hi Matthias,
> > > 
> > > Have these been out on the list for general review? I don't remember
> > > seeing them.
> > > 
> > > On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger  
> > > wrote:
> > > >
> > > >Hi Tom,
> > > >
> > > >Please have a look on the following patches.
> > > >
> > > >Regards,
> > > >Matthias
> > > >
> > > >---
> > > >The following changes since commit 
> > > >fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> > > >
> > > >   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> > > >
> > > >are available in the Git repository at:
> > > >
> > > >   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> > > >
> > > >for you to fetch changes up to 
> > > >38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> > > >
> > > >   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER 
> > > > (2019-06-12 12:23:46
> > > >+0200)
> > > >
> > > >
> > > >- fix complation error for CONFIG_USB
> > > >- update RPi3 DTBs to v5.1-rc6 state
> > > >- add defconfig for RPi3 B+
> > > 
> > > Why do we need a separate config when it's detected and works
> > > perfectly well with the standard rpi_3 and rpi_3_32b configs?
> > > >>>
> > > >>>Good question.  It came from Heinrich, so Heinrich?
> > > >>
> > > >>If we call the bootefi command without a OS supplied device tree the
> > > >>U-Boot device tree is passed to the operating system.
> > > >>
> > > >>So we need a device tree which is a complete description of the
> > > >>respective system.
> > > >>
> > > >>On the Linaro boot-architecture list there has been a lengthy discussion
> > > >>with Linaro people thinking that it is the responsibility of the
> > > >>hardware and firmware to provide the correct device tree and not of the 
> > > >>OS.
> > > >
> > > >OK, but on Pi aren't we passed, and pass along, the dtb from the
> > > >previous stage?
> > > >
> > > Currently `bootefi` uses as default what it finds in $fdt_control_addr
> > > and provides this to GRUB, Linux, or any other payload.
> > 
> > Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
> > in a device tree, that U-Boot then uses?
> 
> I haven't taken this as I haven't gotten an answer to this part.  I
> could have sworn that the proprietary loader passed along the device
> tree that's passed by us to the next stage.

The firmware includes device trees

https://github.com/raspberrypi/firmware/tree/master/boot

At least OpenSUSE, OpenBSD and Fedora change the rpi defconfigs to
better use it:

https://src.fedoraproject.org/rpms/uboot-tools/blob/master/f/rpi-Enable-using-the-DT-provided-by-the-Raspberry-Pi.patch
https://github.com/openSUSE/u-boot/commit/121d9d775c6af6ba5d1c3f198f478404a9196f84.patch

From 121d9d775c6af6ba5d1c3f198f478404a9196f84 Mon Sep 17 00:00:00 2001
From: Alexander Graf 
Date: Wed, 21 Feb 2018 17:41:13 +0100
Subject: [PATCH] rpi: Use firmware provided device tree

Currently the firmware generates a device tree for us that we could
just use to adjust ourselves. We then on boot throw that away and
use our own built-in device tree to configure device access.

This is bad for a multitude of reasons. For starters, it breaks
overlay support in config.txt, confusing users. Much worse however
is that we are stuck with individual U-Boot builds per board.
The firmware can easily give us the right DT depending on the
target board and revision though.

So let's use the firmware provided device tree instead. That way
U-Boot as well as payloads loaded by it can automatically adapt
to variants of RPi hardware.

Signed-off-by: Alexander Graf 
Signed-off-by: Guillaume Gardet 
---
 configs/rpi_0_w_defconfig   | 2 +-
 configs/rpi_2_defconfig | 2 +-
 configs/rpi_3_32b_defconfig | 2 +-
 configs/rpi_3_defconfig | 2 +-
 configs/rpi_defconfig   | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/configs/rpi_0_w_defconfig b/configs/rpi_0_w_defconfig
index 1ab35f1b253..d26010efac1 100644
--- a/configs/rpi_0_w_defconfig
+++ b/configs/rpi_0_w_defconfig
@@ -14,7 +14,7 @@ CONFIG_CMD_GPIO=y
 CONFIG_CMD_MMC=y
 CONFIG_CMD_USB=y
 CONFIG_CMD_FS_UUID=y
-CONFIG_OF_EMBED=y
+CONFIG_OF_BOARD=y
 CONFIG_DEFAULT_DEVICE_TREE="bcm2835-rpi-zero-w"
 CONFIG_ENV_FAT_INTERFACE="mmc"
 CONFIG_ENV_FAT_DEVICE_AND_PART="0:1"
diff --git a/configs/rpi_2_defconfig b/configs/rpi_2_defconfig
index 53aa554cc74..2b6bbf1b4b4 100644
--- a/configs/rpi_2_defconfig
+++

Re: [U-Boot] [PATCH v4 1/2] fit: Support compression for non-kernel components (e.g. FDT)

2019-06-24 Thread Julius Werner

Hi Simon,

I forgot about these for a while, but I believe I addressed all the
feedback you still had in the latest version (v4). Looks like they
didn't get picked up anywhere though. Can you help?

On Thu, May 16, 2019 at 7:34 PM Simon Glass  wrote:
>
> On Wed, 15 May 2019 at 16:30, Julius Werner  wrote:
> >
> > This patch adds support for compressing non-kernel image nodes in a FIT
> > image (kernel nodes could already be compressed previously). This can
> > reduce the size of FIT images and therefore improve boot times
> > (especially when an image bundles many different kernel FDTs). The
> > images will automatically be decompressed on load.
> >
> > This patch does not support extracting compatible strings from
> > compressed FDTs, so it's not very helpful in conjunction with
> > CONFIG_FIT_BEST_MATCH yet, but it can already be used in environments
> > that select the configuration to load explicitly.
> >
> > Signed-off-by: Julius Werner 
> > ---
> >  - Changes for v2:
> >- Changed from only supporting compressed FDTs to supporting all
> >  non-kernel image node types.
> >  - Changes for v3:
> >- Fixed up some debug output that was still written for v1.
> >- Fixed a mistake with handling FIT_LOAD_OPTIONAL_NON_ZERO when
> >  'load' was 0 (i.e. unset).
> >- Added compression test case to the test_fit pytest.
> >  - No changes for v4
> >
> >  common/image-fit.c| 86 +++
> >  test/py/tests/test_fit.py | 29 +++--
> >  2 files changed, 77 insertions(+), 38 deletions(-)
>
> Reviewed-by: Simon Glass 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/15] arm: socfpga: agilex: Add base address for Intel Agilex SoC

2019-06-24 Thread Ley Foon Tan

On Tue, Jun 25, 2019 at 4:00 AM Simon Goldschmidt
 wrote:
>
> Am 30.05.2019 um 11:03 schrieb Ley Foon Tan:
> > Add base address for Intel Agilex SoC.
> >
> > Reuse base_addr_s10.h for Agilex, only one base address is
> > different from S10.
> >
> > Signed-off-by: Ley Foon Tan 
> > ---
>
> Wait, this is v2, right? What hss changed since v1? I notice v2 has 15
> patches while v1 had 14.
>
> Have you ever considered using patman and its helper tags? It would
> greatly reduce the effort for reviewers to keep things consistent and
> including a list of changes in each patch.
>
> I mean, when reading v2, I want to rely on you saying "patches 1, 3, and
> 5 of 14 have changed, the rest have not" to speed up my reviewing.
> Patman really helps you with that, just try it! And if you don't want
> to, well, look at how other developers send their multi-version patches...
>
> Regards,
> Simon
>
I will look into Patman for next revision.

Here is summary for this series:

Patch 1, 5, 6, 7, 8, 13, 14, 15 have changed, the rest have not.
*Patch 7 is new patch for clock manager driver with DM.

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

Re: [U-Boot] efi_loader: implementing non-volatile UEFI variables

2019-06-24 Thread AKASHI Takahiro

On Mon, Jun 24, 2019 at 09:10:07PM +0200, Heinrich Schuchardt wrote:
> On 6/24/19 8:50 PM, Wolfgang Denk wrote:
> >Dear Heinrich,
> >
> >In message <7083d208-4b3c-7261-a03b-9066dc8d2...@gmx.de> you wrote:
> >>
> >>to be really useful UEFI variables should be available to the operating
> >>system. This is not possible using U-Boot variables as storage.
> >
> >Oops?  Is it possible that you are not aware of the
> >tools/env/fw_env* code?
> 
> I am fully aware of this.

Oops, I don't know, but

> Think about secure boot. It is a bad idea to expose variables in this way.

Actually, we are thinking of disabling U-Boot environment (I mean,
ENV_IS_NOWHERE) still allowing for UEFI variables for security reason.

One of the differences between U-Boot env and UEFI variables
is that the former can and should be saved to backing storage
only with explicit "saveenv" command, while the latter are
expected to be saved immediately.

Preserving respective semantics simultaneously would be possible, but
it would make the implementation a bit complicated and ugly.
Instead, I believe that it will be a clever idea that we should have
separate contexts for them as I showed in my non-volatile support patch[1].

[1] https://lists.denx.de/pipermail/u-boot/2019-June/371601.html

One of possible improvements here is to refactor the env code and
parameterize "contexts" at env_save()/env_load().

> >
> >Of course U-Boot environment variables can be accessed (read and
> >written) from Linux.
> >
> And maybe a fourth dummy one implementing no variable service at all.
> >>>
> >>>Is this really a good idea?
> >>
> >>Tom is always complaining that the UEFI subsystem has become too large.
> >
> >And I agree on that.  But even if it was not the case, having four
> >different implementations for the same thing is  sub-optiman.
> 
> We have a lot of things that can be disabled in U-Boot. Why should we
> not be able to disable UEFI variables?

To be honest, I'm a bit doubtful about practical meaning of
disabling UEFI variables for UEFI execution environment.

> What Linaro is doing with OP-TEE makes sense to enable secure boot. But
> it will be an ARM64 specific solution.
> 
> >
> >And if the "volatile" feature is all that is missing when using
> >environment variables, then this should be the road taken:
> >
> >- It avoids a complete new implementation
> >- It can be added witrh very little effort
> >- It would be just a minimal increase in memory footprinmt
> >- It is useful for a lot of other pirposes as well.
> >
> >What are your agruments for _not_ taking this approach?

See my comment above.

> UEFI variables should be accessible via the UEFI runtime API and not via
> some U-Boot specific hack which no other program but U-Boot cares about.

Please notice that one of the reasons that prevents UEFI variables
from being accessed by OS is a real hardware(device/controller) may be
shared between firmware(i.e. UEFI runtime) and OS and mutually exclusive
access must be ensured.

-Takahiro Akashi

> Best regards
> 
> Heinrich
> 
> >
> >>The best solution for UEFI variables would be to live in the secure part
> >>of the ARM trusted firmware.
> >
> >You think too narrow. Not all the world is ARM, and not everyone
> >uses ATF.
> >
> >>UEFI variables have both a name and a GUID as keys.
> >
> >Internally U-Boot variables are stored in a hash table; you could
> >easily add GUID support.  the external storage format is also simple
> >enough.  You could extend it in a compatible way for example from
> >
> > =\0
> >
> >to something like
> >
> > ;=\0
> >
> >of, if you don't want to waste another separator character, even
> >
> > ==\0
> >
> >Extending the env import parser and the env export code for this
> >does not look like rocket science either.
> >
> >>Furthermore both
> >>variable names and values are in UTF-16. So they are quite different to
> >>U-Boot variables.
> >
> >Nothing in U-Boot prevents this.  There is a number of ways to
> >convert UTF-16 (or even any kind of binary data) to and from plain
> >ASCII strings, and only your UEFI code needs to understand such
> >encoding.
> >
> >>Look at this output:
> >>
> >>-> printenv
> >>
> >>efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={boot,run}(blob)
> >>efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLang={nv,boot,run}(blob)656e2d555300
> >>efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLangCodes={boot,run}(blob)656e2d555300
> >>efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_RuntimeServicesSupported={boot,run}(blob)8004
> >>
> >>=> printenv -e
> >>
> >>OsIndicationsSupported: BS|RT, DataSize = 0x8
> >>  : 00 00 00 00 00 00 00 00  
> >>PlatformLang: NV|BS|RT, DataSize = 0x6
> >>  : 65 6e 2d 55 53 00en-US.
> >>PlatformLangCodes: BS|RT, DataSize = 0x6
> >>  : 65 6e 2d 55 53 00en-US.
> >>RuntimeServicesSupported: BS|RT,

[U-Boot] Pull request for mmc sub-system for v2019.07-rc4 round 2

2019-06-24 Thread Peng Fan

Hi Tom,

This patchset is to cleanup code, not bug fix, but it has been long time since 
v1 and there
will be conflicts if defconfig changes or driver code change, and then there 
will surely
need v9. So I pick up this patchset after collected several R-b and A-b tags.

CI: https://travis-ci.org/MrVan/u-boot/builds/549278965

Thanks,
Peng

The following changes since commit bdf97b5d393fc94666a847e9bac1c358b2c63c59:

  Merge tag 'efi-2019-07-rc5-3' of 
https://gitlab.denx.de/u-boot/custodians/u-boot-efi (2019-06-21 14:12:28 -0400)

are available in the Git repository at:

  https://github.com/MrVan/u-boot.git tags/mmc-6-23

for you to fetch changes up to 5053da2e4aa297d888cdfc7d216d935504a9472a:

  mmc: fsl_esdhc_imx: drop useless code (2019-06-23 14:18:48 +0800)


Yangbo Lu (5):
  Move CONFIG_FSL_ESDHC to defconfig
  mmc: split fsl_esdhc driver for i.MX
  Convert to use fsl_esdhc_imx for i.MX platforms
  mmc: fsl_esdhc: drop i.MX code
  mmc: fsl_esdhc_imx: drop useless code

 arch/arm/cpu/arm1136/mx35/generic.c   |   10 +-
 arch/arm/cpu/arm926ejs/mx25/generic.c |8 +-
 arch/arm/cpu/armv7/vf610/generic.c|   10 +-
 arch/arm/cpu/armv8/s32v234/generic.c  |2 +-
 arch/arm/include/asm/global_data.h|2 +-
 arch/arm/mach-imx/cpu.c   |6 +-
 arch/arm/mach-imx/mx6/litesom.c   |4 +-
 arch/arm/mach-imx/mx7/clock.c |4 +-
 arch/arm/mach-imx/mx7ulp/clock.c  |2 +-
 arch/arm/mach-imx/speed.c |4 +-
 arch/m68k/cpu/mcf5445x/cpu_init.c |2 +-
 board/advantech/dms-ba16/dms-ba16.c   |4 +-
 board/aristainetos/aristainetos-v1.c  |2 +-
 board/aristainetos/aristainetos-v2.c  |2 +-
 board/aristainetos/aristainetos.c |4 +-
 board/bachmann/ot1200/ot1200.c|2 +-
 board/barco/platinum/platinum.c   |2 +-
 board/barco/titanium/titanium.c   |4 +-
 board/boundary/nitrogen6x/nitrogen6x.c|4 +-
 board/ccv/xpress/xpress.c |2 +-
 board/compulab/cl-som-imx7/cl-som-imx7.c  |6 +-
 board/compulab/cl-som-imx7/common.c   |6 +-
 board/compulab/cl-som-imx7/common.h   |8 +-
 board/compulab/cl-som-imx7/mux.c  |8 +-
 board/compulab/cl-som-imx7/spl.c  |6 +-
 board/compulab/cm_fx6/cm_fx6.c|4 +-
 board/compulab/cm_fx6/common.c|4 +-
 board/compulab/cm_fx6/spl.c   |2 +-
 board/congatec/cgtqmx6eval/cgtqmx6eval.c  |4 +-
 board/dhelectronics/dh_imx6/dh_imx6.c |2 +-
 board/dhelectronics/dh_imx6/dh_imx6_spl.c |2 +-
 board/el/el6x/el6x.c  |4 +-
 board/embest/mx6boards/mx6boards.c|4 +-
 board/freescale/imx8mq_evk/imx8mq_evk.c   |2 +-
 board/freescale/imx8mq_evk/spl.c  |2 +-
 board/freescale/imx8qxp_mek/imx8qxp_mek.c |2 +-
 board/freescale/m54418twr/m54418twr.c |2 +-
 board/freescale/mx25pdk/mx25pdk.c |6 +-
 board/freescale/mx35pdk/mx35pdk.c |4 +-
 board/freescale/mx51evk/mx51evk.c |6 +-
 board/freescale/mx53ard/mx53ard.c |4 +-
 board/freescale/mx53evk/mx53evk.c |4 +-
 board/freescale/mx53loco/mx53loco.c   |4 +-
 board/freescale/mx53smd/mx53smd.c |4 +-
 board/freescale/mx6qarm2/mx6qarm2.c   |4 +-
 board/freescale/mx6sabreauto/mx6sabreauto.c   |4 +-
 board/freescale/mx6sabresd/mx6sabresd.c   |4 +-
 board/freescale/mx6slevk/mx6slevk.c   |2 +-
 board/freescale/mx6sxsabreauto/mx6sxsabreauto.c   |2 +-
 board/freescale/mx6sxsabresd/mx6sxsabresd.c   |2 +-
 board/freescale/mx6ul_14x14_evk/mx6ul_14x14_evk.c |4 +-
 board/freescale/mx6ullevk/mx6ullevk.c |2 +-
 board/freescale/mx7dsabresd/mx7dsabresd.c |2 +-
 board/freescale/s32v234evb/s32v234evb.c   |4 +-
 board/freescale/vf610twr/vf610twr.c   |4 +-
 board/gateworks/gw_ventana/common.c   |6 +-
 board/gateworks/gw_ventana/gw_ventana.c   |2 +-
 board/ge/bx50v3/bx50v3.c  |2 +-
 board/ge/mx53ppd/mx53ppd.c|2 +-
 board/grinn/liteboard/board.c |4 +-
 board/inversepath/usbarmory/usbarmory.c   |2 +-
 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc.c |4 +-
 board/k+p/kp_imx6q_tpc/kp_imx6q_tpc_spl.c |2 +-
 board/kosagi/novena/novena.c  |2 +-

Re: [U-Boot] [PATCH 00/15] Add Intel Agilex SoC support

2019-06-24 Thread Ley Foon Tan

On Tue, Jun 25, 2019 at 3:53 AM Simon Goldschmidt
 wrote:
>
> Am 30.05.2019 um 11:03 schrieb Ley Foon Tan:
> > This is 2nd version of patchset to add Intel Agilex SoC[1] support.
>
> If this is v2, why doesn't the subject say so?
This is v2.
Forgot change the subject to v2 after sent the patches. Sorry about that.

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

Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released

Hi Marek,


On Mon, 24 Jun 2019 at 11:10, Marek Vasut  wrote:
>
> On 6/24/19 3:56 PM, Simon Glass wrote:
> > Hi Andreas,,
> >
> > On Sat, 22 Jun 2019 at 20:49, Andreas Färber  wrote:
> >>
> >> Hi Simon,
> >>
> >> Am 22.06.19 um 21:14 schrieb Simon Glass:
> >>> On Sat, 22 Jun 2019 at 20:08, Andreas Färber  wrote:
>  Am 22.06.19 um 20:15 schrieb Simon Glass:
> > On Sat, 22 Jun 2019 at 16:10, Andreas Färber  wrote:
> >> Am 22.06.19 um 16:55 schrieb Simon Glass:
> >>> I'd like to better understand the benefits of the 3-month timeline.
> >>
> >> It takes time to learn about a release, package and build it, test it 
> >> on
> >> various hardware, investigate and report errors, wait for feedback and
> >> fixes, rinse and repeat with the next -rc. Many people don't do this as
> >> their main job.
> >>
> >> If we shorten the release cycle, newer boards will get out faster 
> >> (which
> >> is good) but the overall quality of boards not actively worked on
> >> (because they were working good enough before) will decay, which is 
> >> bad.
> >> The only way to counteract that would be to automatically test on real
> >> hardware rather than just building, and doing that for all these masses
> >> of boards seems unrealistic.
> >
> > Here I think you are talking about distributions. But why not just
> > take every second release?
> 
>  You're missing my point: What good is it to do a release when you
>  yourself consider it of such poor quality that you advise others not to
>  take it?
> >>>
> >>> Who said that?
> >>
> >> You, quoted above. In response to my concerns about decreasing quality
> >> you suggested to take only every second release. That doesn't improve
> >> the quality of either. It implies that one may have such bad quality
> >> that people should skip it and yet does nothing to improve the next.
> >
> > Actually I did not say that I consider the release of such poor
> > quality. Nor did I advise others to take it. I suspect this is a
> > misunderstanding of "But why not just take every second release?".
> >
> > My point was that if people don't have time to test every release,
> > then just put in the time to test every second release.
>
> So what about be the point of releasing the untested intermediate
> release at all ? I'm sure people can just grab u-boot/master or -rc2
> just fine.

Because (I contend) these releases do actually attract testing effort
and are stable in most cases. I think this is the 90/10 rule - we are
adding a road-block in the project for the 10% of boards that are
super, super important...so important that no one can actually find
time to test them :-)

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

Re: [U-Boot] Difference between _defconfig and _config make switches

2019-06-24 Thread Robert P. J. Day

On Tue, 25 Jun 2019, Ahmad Ijaz wrote:

> Hi Sir,
>
> I am trying to understand u-boot source code. As a starting point, I
> compiled u-boot for beaglebone black and successfully executed it on
> beaglebone hardware.
> My question is related to compilation step.
>
> The u-boot can be compiled with the following switches on *make.*
>
> *1. am335x_beaglebone_defconfig*
> *2. am335x_beaglebone_config*
> *3. am335x_evm_defconfig*
> *4. am335x_evm_config*

  from scripts/kconfig/Makefile:

# Added for U-Boot (backward compatibility)
%_config: %_defconfig
@:

-- 


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

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

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

[U-Boot] Difference between _defconfig and _config make switches

2019-06-24 Thread Ahmad Ijaz

Hi Sir,

I am trying to understand u-boot source code. As a starting point, I
compiled u-boot for beaglebone black and successfully executed it on
beaglebone hardware.
My question is related to compilation step.

The u-boot can be compiled with the following switches on *make.*

*1. am335x_beaglebone_defconfig*
*2. am335x_beaglebone_config*
*3. am335x_evm_defconfig*
*4. am335x_evm_config*

All compiles fine. but whats the difference b/w " **_defconfig" AND "
*_config". *Interestingly there are no script in the /config directory
ending with *_config *(all ends with _defconfig). I tried to read the
Makefile to find out if these switches may be pointing to a file but
couldn't get it.

Please give me a direction in this regard. Are they switches or name of
configuration files?
waiting for your kind reply.

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

Re: [U-Boot] [PATCH v4 2/4] env: mmc: add erase-function

Frank Wunderlich  schrieb am Mo., 24. Juni 2019,
22:09:

> You mean passing the offset (normal/redundant) instead of a bool?
>

Would you mind keeping the mail style of this list and stop top-responses
please?

I don't care where you make the difference between bool and actual offset,
but you should keep all this as a changeset to env/mmc.c only to keep it
consistent to existing redundant env code. Don't expose the bool to the env
driver interface or the command file.

Regards,
Simon


> Am 24. Juni 2019 21:40:36 MESZ schrieb Simon Goldschmidt <
> simon.k.r.goldschm...@gmail.com>:
> >Am 28.04.2019 um 10:51 schrieb Frank Wunderlich:
> >> this adds erase environment for mmc storage
> >>
> >> Signed-off-by: Frank Wunderlich 
> >
> >I think this is still too complex.
> >
> >I'd drop patches 3/4 and 4/4 and just erase both redundant storages
> >here
> >in env/mmc.c by calling the actual erase function twice.
> >
> >To do that, it would help to do as I suggested in response to v3: copy
> >the 2-function style used by the save env code, then you can just call
> >that 2nd function twice with a different offset (all in env/mmc.c).
> >
> >Regards,
> >Simon
> >
> >>
> >> squashed fixes:
> >>   - fix bogus indent
> >>   - add CONFIG_CMD_ERASEENV
> >>
> >> Suggested-by: Simon Goldschmidt 
> >> =2D--
> >>   env/mmc.c | 31 +++
> >>   1 file changed, 31 insertions(+)
> >>
> >> diff --git a/env/mmc.c b/env/mmc.c
> >> index c3cf35d01b..9ae9b1a66a 100644
> >> =2D-- a/env/mmc.c
> >> +++ b/env/mmc.c
> >> @@ -242,6 +242,34 @@ fini:
> >>  fini_mmc_for_env(mmc);
> >>  return ret;
> >>   }
> >> +
> >> +#if defined(CONFIG_CMD_ERASEENV)
> >> +static int env_mmc_erase(void)
> >> +{
> >> +int dev =3D mmc_get_env_dev();
> >> +struct mmc *mmc =3D find_mmc_device(dev);
> >> +int n, blk, cnt;
> >> +
> >> +if (!mmc)
> >> +return CMD_RET_FAILURE;
> >> +
> >> +blk =3D CONFIG_ENV_OFFSET / mmc->read_bl_len;
> >> +cnt =3D CONFIG_ENV_SIZE / mmc->read_bl_len;
> >> +
> >> +printf("\nMMC erase env: dev # %d, block # %d (0x%x), count %d
> >(0x%x)\n"=
> >> ,
> >> +   dev, blk, blk * mmc->read_bl_len,
> >> +   cnt, cnt * mmc->read_bl_len);
> >> +
> >> +if (mmc_getwp(mmc) =3D=3D 1) {
> >> +printf("Error: card is write protected!\n");
> >> +return CMD_RET_FAILURE;
> >> +}
> >> +n =3D blk_derase(mmc_get_blk_desc(mmc), blk, cnt);
> >> +printf("%d blocks erased: %s\n", n, (n =3D=3D cnt) ? "OK" :
> >"ERROR");
> >> +
> >> +return (n =3D=3D cnt) ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
> >> +}
> >> +#endif /* CONFIG_CMD_ERASEENV */
> >>   #endif /* CONFIG_CMD_SAVEENV && !CONFIG_SPL_BUILD */
> >>
> >>   static inline int read_env(struct mmc *mmc, unsigned long size,
> >> @@ -351,5 +379,8 @@ U_BOOT_ENV_LOCATION(mmc) =3D {
> >>  .load   =3D env_mmc_load,
> >>   #ifndef CONFIG_SPL_BUILD
> >>  .save   =3D env_save_ptr(env_mmc_save),
> >> +#if defined(CONFIG_CMD_ERASEENV)
> >> +.erase  =3D env_mmc_erase,
> >> +#endif
> >>   #endif
> >>   };
> >> =2D-
> >> 2.17.1
> >>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 2/4] env: mmc: add erase-function

2019-06-24 Thread Frank Wunderlich

You mean passing the offset (normal/redundant) instead of a bool?

Am 24. Juni 2019 21:40:36 MESZ schrieb Simon Goldschmidt 
:
>Am 28.04.2019 um 10:51 schrieb Frank Wunderlich:
>> this adds erase environment for mmc storage
>> 
>> Signed-off-by: Frank Wunderlich 
>
>I think this is still too complex.
>
>I'd drop patches 3/4 and 4/4 and just erase both redundant storages
>here 
>in env/mmc.c by calling the actual erase function twice.
>
>To do that, it would help to do as I suggested in response to v3: copy 
>the 2-function style used by the save env code, then you can just call 
>that 2nd function twice with a different offset (all in env/mmc.c).
>
>Regards,
>Simon
>
>> 
>> squashed fixes:
>>   - fix bogus indent
>>   - add CONFIG_CMD_ERASEENV
>> 
>> Suggested-by: Simon Goldschmidt 
>> =2D--
>>   env/mmc.c | 31 +++
>>   1 file changed, 31 insertions(+)
>> 
>> diff --git a/env/mmc.c b/env/mmc.c
>> index c3cf35d01b..9ae9b1a66a 100644
>> =2D-- a/env/mmc.c
>> +++ b/env/mmc.c
>> @@ -242,6 +242,34 @@ fini:
>>  fini_mmc_for_env(mmc);
>>  return ret;
>>   }
>> +
>> +#if defined(CONFIG_CMD_ERASEENV)
>> +static int env_mmc_erase(void)
>> +{
>> +int dev =3D mmc_get_env_dev();
>> +struct mmc *mmc =3D find_mmc_device(dev);
>> +int n, blk, cnt;
>> +
>> +if (!mmc)
>> +return CMD_RET_FAILURE;
>> +
>> +blk =3D CONFIG_ENV_OFFSET / mmc->read_bl_len;
>> +cnt =3D CONFIG_ENV_SIZE / mmc->read_bl_len;
>> +
>> +printf("\nMMC erase env: dev # %d, block # %d (0x%x), count %d
>(0x%x)\n"=
>> ,
>> +   dev, blk, blk * mmc->read_bl_len,
>> +   cnt, cnt * mmc->read_bl_len);
>> +
>> +if (mmc_getwp(mmc) =3D=3D 1) {
>> +printf("Error: card is write protected!\n");
>> +return CMD_RET_FAILURE;
>> +}
>> +n =3D blk_derase(mmc_get_blk_desc(mmc), blk, cnt);
>> +printf("%d blocks erased: %s\n", n, (n =3D=3D cnt) ? "OK" :
>"ERROR");
>> +
>> +return (n =3D=3D cnt) ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
>> +}
>> +#endif /* CONFIG_CMD_ERASEENV */
>>   #endif /* CONFIG_CMD_SAVEENV && !CONFIG_SPL_BUILD */
>> 
>>   static inline int read_env(struct mmc *mmc, unsigned long size,
>> @@ -351,5 +379,8 @@ U_BOOT_ENV_LOCATION(mmc) =3D {
>>  .load   =3D env_mmc_load,
>>   #ifndef CONFIG_SPL_BUILD
>>  .save   =3D env_save_ptr(env_mmc_save),
>> +#if defined(CONFIG_CMD_ERASEENV)
>> +.erase  =3D env_mmc_erase,
>> +#endif
>>   #endif
>>   };
>> =2D-
>> 2.17.1
>> 
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 01/15] arm: socfpga: agilex: Add base address for Intel Agilex SoC


Am 30.05.2019 um 11:03 schrieb Ley Foon Tan:

Add base address for Intel Agilex SoC.

Reuse base_addr_s10.h for Agilex, only one base address is
different from S10.

Signed-off-by: Ley Foon Tan 
---


Wait, this is v2, right? What hss changed since v1? I notice v2 has 15 
patches while v1 had 14.


Have you ever considered using patman and its helper tags? It would 
greatly reduce the effort for reviewers to keep things consistent and 
including a list of changes in each patch.


I mean, when reading v2, I want to rely on you saying "patches 1, 3, and 
5 of 14 have changed, the rest have not" to speed up my reviewing. 
Patman really helps you with that, just try it! And if you don't want 
to, well, look at how other developers send their multi-version patches...


Regards,
Simon


  arch/arm/mach-socfpga/include/mach/base_addr_s10.h | 4 
  1 file changed, 4 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h 
b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
index 1f549d7e70..d3eca65e97 100644
--- a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
@@ -10,7 +10,11 @@
  #define SOCFPGA_SDR_SCHEDULER_ADDRESS 0xf8000400
  #define SOCFPGA_HMC_MMR_IO48_ADDRESS  0xf801
  #define SOCFPGA_SDR_ADDRESS   0xf8011000
+#ifdef CONFIG_TARGET_SOCFPGA_AGILEX
+#define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020200
+#else
  #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS0xf8020100
+#endif
  #define SOCFPGA_SMMU_ADDRESS  0xfa00
  #define SOCFPGA_MAILBOX_ADDRESS   0xffa3
  #define SOCFPGA_UART0_ADDRESS 0xffc02000



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

Re: [U-Boot] [PATCH 00/15] Add Intel Agilex SoC support


Am 30.05.2019 um 11:03 schrieb Ley Foon Tan:

This is 2nd version of patchset to add Intel Agilex SoC[1] support.


If this is v2, why doesn't the subject say so?


This patchset needs to apply after patch in [2] for Designware i2c clock from 
DM.

Intel Agilex SoC is with a 64-bit quad core ARM Cortex-A53 MPCore
hard processor system (HPS). New IPs in Agilex are CCU, clock manager and SDRAM,
other IPs have minor changes compared to Stratix 10.

Intel Agilex HPS TRM:
https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/hb/agilex/mnl-1100.pdf

v1->v2:
---
- Change clock driver to DM
- Reuse base_addr_s10.h from S10
- Add system_manager_s10_agilex_common.h
- Update commit message for CCU patch
- Update Linux commit id in dts/dtsi patch

History:
-
[v1]: https://patchwork.ozlabs.org/cover/1097830/

[1]: 
https://www.intel.com/content/www/us/en/products/programmable/fpga/agilex.html
[2]: https://patchwork.ozlabs.org/patch/1107608/


This has changed to v2 by now (just for the record):
https://patchwork.ozlabs.org/patch/1114251/

Regards,
Simon



Ley Foon Tan (15):
   arm: socfpga: agilex: Add base address for Intel Agilex SoC
   arm: socfpga: Move firewall code to firewall file
   arm: socfpga: Move Stratix10 and Agilex reset manager common code
   arm: socfpga: agilex: Add reset manager support
   arm: socfpga: Move Stratix10 and Agilex system manager common code
   arm: socfpga: agilex: Add system manager support
   clk: agilex: Add clock driver for Agilex.
   arm: socfpga: agilex: Add clock manager support
   arm: socfpga: agilex: Add CCU support for Agilex
   ddr: altera: Restructure Stratix 10 SDRAM driver
   ddr: altera: agilex: Add SDRAM driver for Agilex
   board: intel: agilex: Add socdk board support for Intel Agilex SoC
   arm: socfpga: agilex: Add SPL for Agilex SoC
   arm: dts: agilex: Add base dtsi and devkit dts
   arm: socfpga: agilex: Enable Agilex SoC build

  arch/arm/Kconfig  |   4 +-
  arch/arm/dts/Makefile |   1 +
  arch/arm/dts/socfpga_agilex.dtsi  | 495 +++
  arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi |  71 +++
  arch/arm/dts/socfpga_agilex_socdk.dts | 136 +
  arch/arm/mach-socfpga/Kconfig |  15 +
  arch/arm/mach-socfpga/Makefile|  18 +
  arch/arm/mach-socfpga/ccu_agilex.c|  99 +++
  arch/arm/mach-socfpga/clock_manager_agilex.c  |  87 +++
  arch/arm/mach-socfpga/firewall.c  |  97 +++
  .../mach-socfpga/include/mach/base_addr_s10.h |   4 +
  .../mach-socfpga/include/mach/ccu_agilex.h|  67 +++
  .../mach-socfpga/include/mach/clock_manager.h |   2 +
  .../include/mach/clock_manager_agilex.h   | 329 ++
  .../mach/{firewall_s10.h => firewall.h}   |  10 +-
  .../mach-socfpga/include/mach/reset_manager.h |  29 +
  .../include/mach/reset_manager_agilex.h   |  38 ++
  .../include/mach/reset_manager_s10.h  |  79 ---
  .../include/mach/system_manager.h |   2 +
  ..._manager_s10.h => system_manager_agilex.h} |  89 +--
  .../include/mach/system_manager_s10.h |  46 +-
  .../mach/system_manager_s10_agilex_common.h   |  60 ++
  arch/arm/mach-socfpga/reset_manager.c |   9 +-
  arch/arm/mach-socfpga/spl_agilex.c| 100 +++
  arch/arm/mach-socfpga/spl_s10.c   |  84 +--
  board/intel/agilex-socdk/MAINTAINERS  |   7 +
  board/intel/agilex-socdk/Makefile |   7 +
  board/intel/agilex-socdk/socfpga.c|   7 +
  configs/socfpga_agilex_defconfig  |  57 ++
  drivers/clk/altera/Makefile   |   1 +
  drivers/clk/altera/clk-agilex.c   | 568 ++
  drivers/ddr/altera/Kconfig|   6 +-
  drivers/ddr/altera/Makefile   |   3 +-
  drivers/ddr/altera/sdram_agilex.c | 158 +
  drivers/ddr/altera/sdram_common.c | 308 ++
  .../altera/{sdram_s10.h => sdram_common.h}|  75 +--
  drivers/ddr/altera/sdram_s10.c| 302 +-
  drivers/ddr/altera/sdram_s10.h| 148 -
  include/configs/socfpga_agilex_socdk.h| 208 +++
  include/dt-bindings/clock/stratix10-clock.h   |  84 +++
  40 files changed, 3140 insertions(+), 770 deletions(-)
  create mode 100644 arch/arm/dts/socfpga_agilex.dtsi
  create mode 100644 arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
  create mode 100644 arch/arm/dts/socfpga_agilex_socdk.dts
  create mode 100644 arch/arm/mach-socfpga/ccu_agilex.c
  create mode 100644 arch/arm/mach-socfpga/clock_manager_agilex.c
  create mode 100644 arch/arm/mach-socfpga/firewall.c
  create mode 100644 arch/arm/mach-socfpga/include/mach/ccu_agilex.h
  create mode 100644 arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
  rename arch/arm/mach-socfpga/include/mach/{firewall_s10.h => firewall.h} (94%)
  create mode 100644

Re: [U-Boot] [PATCH v2] i2c: designware: Get clock rate from clock DM


Am 12.06.2019 um 03:48 schrieb Ley Foon Tan:

Get clock rate from clock DM if CONFIG_CLK is enabled.
Otherwise, uses IC_CLK define.

Signed-off-by: Ley Foon Tan 
Acked-by: Marek Vasut 


Reviewed-by: Simon Goldschmidt 



---
v2:
- Changed u32 to unsigned int for bus_mhz.
- Added ACK from Marek
---
  drivers/i2c/designware_i2c.c | 55 +---
  1 file changed, 45 insertions(+), 10 deletions(-)

diff --git a/drivers/i2c/designware_i2c.c b/drivers/i2c/designware_i2c.c
index 9ccc2411a6..606891fc2f 100644
--- a/drivers/i2c/designware_i2c.c
+++ b/drivers/i2c/designware_i2c.c
@@ -4,6 +4,7 @@
   * Vipin Kumar, ST Micoelectronics, vipin.ku...@st.com.
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -35,6 +36,9 @@ struct dw_i2c {
struct i2c_regs *regs;
struct dw_scl_sda_cfg *scl_sda_cfg;
struct reset_ctl_bulk resets;
+#if CONFIG_IS_ENABLED(CLK)
+   struct clk clk;
+#endif
  };
  
  #ifdef CONFIG_SYS_I2C_DW_ENABLE_STATUS_UNSUPPORTED

@@ -78,7 +82,8 @@ static int dw_i2c_enable(struct i2c_regs *i2c_base, bool 
enable)
   */
  static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs *i2c_base,
   struct dw_scl_sda_cfg *scl_sda_cfg,
-  unsigned int speed)
+  unsigned int speed,
+  unsigned int bus_mhz)
  {
unsigned int cntl;
unsigned int hcnt, lcnt;
@@ -104,8 +109,8 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs 
*i2c_base,
hcnt = scl_sda_cfg->fs_hcnt;
lcnt = scl_sda_cfg->fs_lcnt;
} else {
-   hcnt = (IC_CLK * MIN_HS_SCL_HIGHTIME) / NANO_TO_MICRO;
-   lcnt = (IC_CLK * MIN_HS_SCL_LOWTIME) / NANO_TO_MICRO;
+   hcnt = (bus_mhz * MIN_HS_SCL_HIGHTIME) / NANO_TO_MICRO;
+   lcnt = (bus_mhz * MIN_HS_SCL_LOWTIME) / NANO_TO_MICRO;
}
writel(hcnt, _base->ic_hs_scl_hcnt);
writel(lcnt, _base->ic_hs_scl_lcnt);
@@ -118,8 +123,8 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs 
*i2c_base,
hcnt = scl_sda_cfg->ss_hcnt;
lcnt = scl_sda_cfg->ss_lcnt;
} else {
-   hcnt = (IC_CLK * MIN_SS_SCL_HIGHTIME) / NANO_TO_MICRO;
-   lcnt = (IC_CLK * MIN_SS_SCL_LOWTIME) / NANO_TO_MICRO;
+   hcnt = (bus_mhz * MIN_SS_SCL_HIGHTIME) / NANO_TO_MICRO;
+   lcnt = (bus_mhz * MIN_SS_SCL_LOWTIME) / NANO_TO_MICRO;
}
writel(hcnt, _base->ic_ss_scl_hcnt);
writel(lcnt, _base->ic_ss_scl_lcnt);
@@ -132,8 +137,8 @@ static unsigned int __dw_i2c_set_bus_speed(struct i2c_regs 
*i2c_base,
hcnt = scl_sda_cfg->fs_hcnt;
lcnt = scl_sda_cfg->fs_lcnt;
} else {
-   hcnt = (IC_CLK * MIN_FS_SCL_HIGHTIME) / NANO_TO_MICRO;
-   lcnt = (IC_CLK * MIN_FS_SCL_LOWTIME) / NANO_TO_MICRO;
+   hcnt = (bus_mhz * MIN_FS_SCL_HIGHTIME) / NANO_TO_MICRO;
+   lcnt = (bus_mhz * MIN_FS_SCL_LOWTIME) / NANO_TO_MICRO;
}
writel(hcnt, _base->ic_fs_scl_hcnt);
writel(lcnt, _base->ic_fs_scl_lcnt);
@@ -388,7 +393,7 @@ static int __dw_i2c_init(struct i2c_regs *i2c_base, int 
speed, int slaveaddr)
writel(IC_TX_TL, _base->ic_tx_tl);
writel(IC_STOP_DET, _base->ic_intr_mask);
  #ifndef CONFIG_DM_I2C
-   __dw_i2c_set_bus_speed(i2c_base, NULL, speed);
+   __dw_i2c_set_bus_speed(i2c_base, NULL, speed, IC_CLK);
writel(slaveaddr, _base->ic_sar);
  #endif
  
@@ -433,7 +438,7 @@ static unsigned int dw_i2c_set_bus_speed(struct i2c_adapter *adap,

 unsigned int speed)
  {
adap->speed = speed;
-   return __dw_i2c_set_bus_speed(i2c_get_base(adap), NULL, speed);
+   return __dw_i2c_set_bus_speed(i2c_get_base(adap), NULL, speed, IC_CLK);
  }
  
  static void dw_i2c_init(struct i2c_adapter *adap, int speed, int slaveaddr)

@@ -523,8 +528,20 @@ static int designware_i2c_xfer(struct udevice *bus, struct 
i2c_msg *msg,
  static int designware_i2c_set_bus_speed(struct udevice *bus, unsigned int 
speed)
  {
struct dw_i2c *i2c = dev_get_priv(bus);
+   ulong rate;
+
+#if CONFIG_IS_ENABLED(CLK)
+   rate = clk_get_rate(>clk);
+   if (IS_ERR_VALUE(rate))
+   return -EINVAL;
  
-	return __dw_i2c_set_bus_speed(i2c->regs, i2c->scl_sda_cfg, speed);

+   /* Convert to MHz */
+   rate /= 100;
+#else
+   rate = IC_CLK;
+#endif
+   return __dw_i2c_set_bus_speed(i2c->regs, i2c->scl_sda_cfg, speed,
+ rate);
  }
  
  static int

Re: [U-Boot] [PATCH v4 2/4] env: mmc: add erase-function


Am 28.04.2019 um 10:51 schrieb Frank Wunderlich:

this adds erase environment for mmc storage

Signed-off-by: Frank Wunderlich 


I think this is still too complex.

I'd drop patches 3/4 and 4/4 and just erase both redundant storages here 
in env/mmc.c by calling the actual erase function twice.


To do that, it would help to do as I suggested in response to v3: copy 
the 2-function style used by the save env code, then you can just call 
that 2nd function twice with a different offset (all in env/mmc.c).


Regards,
Simon



squashed fixes:
  - fix bogus indent
  - add CONFIG_CMD_ERASEENV

Suggested-by: Simon Goldschmidt 
=2D--
  env/mmc.c | 31 +++
  1 file changed, 31 insertions(+)

diff --git a/env/mmc.c b/env/mmc.c
index c3cf35d01b..9ae9b1a66a 100644
=2D-- a/env/mmc.c
+++ b/env/mmc.c
@@ -242,6 +242,34 @@ fini:
fini_mmc_for_env(mmc);
return ret;
  }
+
+#if defined(CONFIG_CMD_ERASEENV)
+static int env_mmc_erase(void)
+{
+   int dev =3D mmc_get_env_dev();
+   struct mmc *mmc =3D find_mmc_device(dev);
+   int n, blk, cnt;
+
+   if (!mmc)
+   return CMD_RET_FAILURE;
+
+   blk =3D CONFIG_ENV_OFFSET / mmc->read_bl_len;
+   cnt =3D CONFIG_ENV_SIZE / mmc->read_bl_len;
+
+   printf("\nMMC erase env: dev # %d, block # %d (0x%x), count %d 
(0x%x)\n"=
,
+  dev, blk, blk * mmc->read_bl_len,
+  cnt, cnt * mmc->read_bl_len);
+
+   if (mmc_getwp(mmc) =3D=3D 1) {
+   printf("Error: card is write protected!\n");
+   return CMD_RET_FAILURE;
+   }
+   n =3D blk_derase(mmc_get_blk_desc(mmc), blk, cnt);
+   printf("%d blocks erased: %s\n", n, (n =3D=3D cnt) ? "OK" : "ERROR");
+
+   return (n =3D=3D cnt) ? CMD_RET_SUCCESS : CMD_RET_FAILURE;
+}
+#endif /* CONFIG_CMD_ERASEENV */
  #endif /* CONFIG_CMD_SAVEENV && !CONFIG_SPL_BUILD */

  static inline int read_env(struct mmc *mmc, unsigned long size,
@@ -351,5 +379,8 @@ U_BOOT_ENV_LOCATION(mmc) =3D {
.load   =3D env_mmc_load,
  #ifndef CONFIG_SPL_BUILD
.save   =3D env_save_ptr(env_mmc_save),
+#if defined(CONFIG_CMD_ERASEENV)
+   .erase  =3D env_mmc_erase,
+#endif
  #endif
  };
=2D-
2.17.1



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

Re: [U-Boot] [PATCH v4 1/4] env: register erase command


Am 28.04.2019 um 10:51 schrieb Frank Wunderlich:

this patch adds basic changes for adding a erase-subcommand to env

with this command the environment stored on non-volatile storage written
by saveenv can be cleared.

Signed-off-by: Frank Wunderlich 


Reviewed-by: Simon Goldschmidt 

However, due to changes, this doesn't apply any more, so a v5 is needed.

Regards,
Simon



squashed fixes
  - start message with "Erasing"
  - mark erase-function as optional
  - env: separate eraseenv from saveenv

Suggested-by: Simon Goldschmidt 
=2D--
  cmd/Kconfig   |  8 
  cmd/nvedit.c  | 19 +++
  env/env.c | 30 ++
  include/environment.h | 17 +
  4 files changed, 74 insertions(+)

diff --git a/cmd/Kconfig b/cmd/Kconfig
index 0b07b3b9d7..e8a99cb5a3 100644
=2D-- a/cmd/Kconfig
+++ b/cmd/Kconfig
@@ -397,6 +397,14 @@ config CMD_SAVEENV
  Save all environment variables into the compiled-in persistent
  storage.

+config CMD_ERASEENV
+   bool "eraseenv"
+   default n
+   depends on CMD_SAVEENV
+   help
+ Erase environment variables from the compiled-in persistent
+ storage.
+
  config CMD_ENV_EXISTS
bool "env exists"
default y
diff --git a/cmd/nvedit.c b/cmd/nvedit.c
index 24a6cf7824..0cbd8e8984 100644
=2D-- a/cmd/nvedit.c
+++ b/cmd/nvedit.c
@@ -761,6 +761,19 @@ U_BOOT_CMD(
"save environment variables to persistent storage",
""
  );
+
+#if defined(CONFIG_CMD_ERASEENV)
+static int do_env_erase(cmd_tbl_t *cmdtp, int flag, int argc,
+   char * const argv[])
+{
+   return env_erase() ? 1 : 0;
+}
+U_BOOT_CMD(
+   eraseenv, 1, 0, do_env_erase,
+   "erase environment variables from persistent storage",
+   ""
+);
+#endif
  #endif
  #endif /* CONFIG_SPL_BUILD */

@@ -1207,6 +1220,9 @@ static cmd_tbl_t cmd_env_sub[] =3D {
  #endif
  #if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
U_BOOT_CMD_MKENT(save, 1, 0, do_env_save, "", ""),
+#if defined(CONFIG_CMD_ERASEENV)
+   U_BOOT_CMD_MKENT(erase, 1, 0, do_env_erase, "", ""),
+#endif
  #endif
U_BOOT_CMD_MKENT(set, CONFIG_SYS_MAXARGS, 0, do_env_set, "", ""),
  #if defined(CONFIG_CMD_ENV_EXISTS)
@@ -1282,6 +1298,9 @@ static char env_help_text[] =3D
  #endif
  #if defined(CONFIG_CMD_SAVEENV) && !defined(CONFIG_ENV_IS_NOWHERE)
"env save - save environment\n"
+#if defined(CONFIG_CMD_ERASEENV)
+   "env erase - erase environment\n"
+#endif
  #endif
  #if defined(CONFIG_CMD_NVEDIT_EFI)
"env set -e name [arg ...] - set UEFI variable; unset if 'arg' not 
speci=
fied\n"
diff --git a/env/env.c b/env/env.c
index 4b417b90a2..d3cbe2f915 100644
=2D-- a/env/env.c
+++ b/env/env.c
@@ -24,6 +24,8 @@ void env_fix_drivers(void)
entry->load +=3D gd->reloc_off;
if (entry->save)
entry->save +=3D gd->reloc_off;
+   if (entry->erase)
+   entry->erase +=3D gd->reloc_off;
if (entry->init)
entry->init +=3D gd->reloc_off;
}
@@ -254,6 +256,34 @@ int env_save(void)
return -ENODEV;
  }

+int env_erase(void)
+{
+   struct env_driver *drv;
+
+   drv =3D env_driver_lookup(ENVOP_ERASE, gd->env_load_prio);
+   if (drv) {
+   int ret;
+
+   if (!drv->erase)
+   return -ENODEV;
+
+   if (!env_has_inited(drv->location))
+   return -ENODEV;
+
+   printf("Erasing Environment on %s... ", drv->name);
+   ret =3D drv->erase();
+   if (ret)
+   printf("Failed (%d)\n", ret);
+   else
+   printf("OK\n");
+
+   if (!ret)
+   return 0;
+   }
+
+   return -ENODEV;
+}
+
  int env_init(void)
  {
struct env_driver *drv;
diff --git a/include/environment.h b/include/environment.h
index cd96676141..de67cf4f0e 100644
=2D-- a/include/environment.h
+++ b/include/environment.h
@@ -200,6 +200,7 @@ enum env_operation {
ENVOP_INIT, /* we want to call the init function */
ENVOP_LOAD, /* we want to call the load function */
ENVOP_SAVE, /* we want to call the save function */
+   ENVOP_ERASE,/* we want to call the erase function */
  };

  struct env_driver {
@@ -225,6 +226,15 @@ struct env_driver {
 */
int (*save)(void);

+   /**
+* erase() - Erase the environment on storage
+*
+* This method is optional and required for 'eraseenv' to work.
+*
+* @return 0 if OK, -ve on error
+*/
+   int (*erase)(void);
+
/**
 * init() - Set up the initial pre-relocation environment
 *
@@ -303,6 +313,13 @@ int env_load(void);
   */
  int env_save(void);

+/**
+ * env_erase() - Erase the environment

Re: [U-Boot] [PATCH v4 0/4] add command env erase


Hi Frank,

Am 24.06.2019 um 12:30 schrieb Frank Wunderlich:

no opinion about the last version?


Sorry, I tried multiple times to review this but failed to find the 
time. Seems like I found the time now ;-)


I'll reply to the original patch mails.

Regards,
Simon



regards Frank


Am 28. April 2019 10:51:24 MESZ schrieb Frank Wunderlich 
:

sometimes it is needed to erase the non-volatile environment
e.g. for boot-up with builtin-environment or after resizing env

this series add basic functionality for erasing environment from
storage
as a first storage-driver mmc is introduced, other needs to be added
later

changes since v3:
- fixes
- Kconfig-option as suggested by Simon Goldschmidt
- including CONFIG_ENV_OFFSET_REDUND (4/4 is RFC)

Frank Wunderlich (4):
  env: register erase command
  env: mmc: add erase-function
  env: add option to use redundant offset
  [RFC] env: call env_erase twice if CONFIG_ENV_OFFSET_REDUND is set

cmd/Kconfig   |  8 
cmd/nvedit.c  | 26 ++
env/env.c | 30 ++
env/mmc.c | 36 
include/environment.h | 17 +
5 files changed, 117 insertions(+)

--
2.17.1




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

Re: [U-Boot] [PATCH 7/7] wandboard: README: Adjust the U-Boot proper binary name

2019-06-24 Thread Fabio Estevam

Hi Heinrich,

On Sun, Jun 23, 2019 at 11:04 AM Heinrich Schuchardt  wrote:

> With U-Boot HEAD I cannot see any difference between the files:
> $ md5sum u-boot*.bin
> 56a64c916b79c012759ad430a52fb2c1  u-boot.bin
> 56a64c916b79c012759ad430a52fb2c1  u-boot-dtb.bin
> ed69f924f0cb4b9415d0bed27f896be3  u-boot-nodtb.bin

Actually we are talking about .img in this patch :-)

You are right: u-boot.img and u-boot-dtb.img are the same.

> So is this just a formal change?

Yes, just to point out that the board has been converted to DM and
since *dtb.img has been generated, we can explicitly use it.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] efi_loader: implementing non-volatile UEFI variables


On 6/24/19 8:50 PM, Wolfgang Denk wrote:

Dear Heinrich,

In message <7083d208-4b3c-7261-a03b-9066dc8d2...@gmx.de> you wrote:


to be really useful UEFI variables should be available to the operating
system. This is not possible using U-Boot variables as storage.


Oops?  Is it possible that you are not aware of the
tools/env/fw_env* code?


I am fully aware of this.

Think about secure boot. It is a bad idea to expose variables in this way.



Of course U-Boot environment variables can be accessed (read and
written) from Linux.


And maybe a fourth dummy one implementing no variable service at all.


Is this really a good idea?


Tom is always complaining that the UEFI subsystem has become too large.


And I agree on that.  But even if it was not the case, having four
different implementations for the same thing is  sub-optiman.


We have a lot of things that can be disabled in U-Boot. Why should we
not be able to disable UEFI variables?

What Linaro is doing with OP-TEE makes sense to enable secure boot. But
it will be an ARM64 specific solution.



And if the "volatile" feature is all that is missing when using
environment variables, then this should be the road taken:

- It avoids a complete new implementation
- It can be added witrh very little effort
- It would be just a minimal increase in memory footprinmt
- It is useful for a lot of other pirposes as well.

What are your agruments for _not_ taking this approach?


UEFI variables should be accessible via the UEFI runtime API and not via
some U-Boot specific hack which no other program but U-Boot cares about.

Best regards

Heinrich




The best solution for UEFI variables would be to live in the secure part
of the ARM trusted firmware.


You think too narrow. Not all the world is ARM, and not everyone
uses ATF.


UEFI variables have both a name and a GUID as keys.


Internally U-Boot variables are stored in a hash table; you could
easily add GUID support.  the external storage format is also simple
enough.  You could extend it in a compatible way for example from

=\0

to something like

;=\0

of, if you don't want to waste another separator character, even

==\0

Extending the env import parser and the env export code for this
does not look like rocket science either.


Furthermore both
variable names and values are in UTF-16. So they are quite different to
U-Boot variables.


Nothing in U-Boot prevents this.  There is a number of ways to
convert UTF-16 (or even any kind of binary data) to and from plain
ASCII strings, and only your UEFI code needs to understand such
encoding.


Look at this output:

-> printenv

efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={boot,run}(blob)
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLang={nv,boot,run}(blob)656e2d555300
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLangCodes={boot,run}(blob)656e2d555300
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_RuntimeServicesSupported={boot,run}(blob)8004

=> printenv -e

OsIndicationsSupported: BS|RT, DataSize = 0x8
  : 00 00 00 00 00 00 00 00  
PlatformLang: NV|BS|RT, DataSize = 0x6
  : 65 6e 2d 55 53 00en-US.
PlatformLangCodes: BS|RT, DataSize = 0x6
  : 65 6e 2d 55 53 00en-US.
RuntimeServicesSupported: BS|RT, DataSize = 0x2
  : 80 04..


I'm looking at it, but I don't understand what you want to show me
here?

All I can see is that this looks like something I would not want to
use (read: I consider it ugly and think the design should be
improved).


This is worthwhile but insufficient to solve the UEFI problems.


Could you please be so kine and clearly state what is lacking?

So far I have found:

- lack of "volatile" vs. "non-volatile"
- lack of support for GUID
- lack of support for UTF-16

None of these should be difficult to add by small (or even minimal)
extensions of the existing code, which would probaly also useful to
others (at least some of them).

So far, I see no killing point not an advantage that would justify
adding a completly new implementation for a problem that has been
solved before.

Best regards,

Wolfgang Denk



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

[U-Boot] [PATCH] net/macb: increase RX buffer size for GEM

Macb Ethernet controller requires a RX buffer of 128 bytes. It is
highly sub-optimal for Gigabit-capable GEM that is able to use
a bigger DMA buffer. Change this constant and associated macros
with data stored in the private structure.
RX DMA buffer size has to be multiple of 64 bytes as indicated in
DMA Configuration Register specification.

Signed-off-by: Ramon Fried 
---
 drivers/net/macb.c | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index c072f99d8f..8eb6977fa9 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -45,10 +45,16 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#define MACB_RX_BUFFER_SIZE4096
-#define MACB_RX_RING_SIZE  (MACB_RX_BUFFER_SIZE / 128)
+/* These buffer sizes must be power of 2 and divisible
+ * by RX_BUFFER_MULTIPLE
+ */
+#define MACB_RX_BUFFER_SIZE128
+#define GEM_RX_BUFFER_SIZE 2048
 #define RX_BUFFER_MULTIPLE 64
+
+#define MACB_RX_RING_SIZE  32
 #define MACB_TX_RING_SIZE  16
+
 #define MACB_TX_TIMEOUT1000
 #define MACB_AUTONEG_TIMEOUT   500
 
@@ -95,6 +101,7 @@ struct macb_device {
void*tx_buffer;
struct macb_dma_desc*rx_ring;
struct macb_dma_desc*tx_ring;
+   size_t  rx_buffer_size;
 
unsigned long   rx_buffer_dma;
unsigned long   rx_ring_dma;
@@ -395,15 +402,16 @@ static int _macb_recv(struct macb_device *macb, uchar 
**packetp)
}
 
if (status & MACB_BIT(RX_EOF)) {
-   buffer = macb->rx_buffer + 128 * macb->rx_tail;
+   buffer = macb->rx_buffer +
+   macb->rx_buffer_size * macb->rx_tail;
length = status & RXBUF_FRMLEN_MASK;
 
macb_invalidate_rx_buffer(macb);
if (macb->wrapped) {
unsigned int headlen, taillen;
 
-   headlen = 128 * (MACB_RX_RING_SIZE
-- macb->rx_tail);
+   headlen = macb->rx_buffer_size *
+   (MACB_RX_RING_SIZE - macb->rx_tail);
taillen = length - headlen;
memcpy((void *)net_rx_packets[0],
   buffer, headlen);
@@ -701,7 +709,7 @@ static void gmac_configure_dma(struct macb_device *macb)
u32 buffer_size;
u32 dmacfg;
 
-   buffer_size = 128 / RX_BUFFER_MULTIPLE;
+   buffer_size = macb->rx_buffer_size / RX_BUFFER_MULTIPLE;
dmacfg = gem_readl(macb, DMACFG) & ~GEM_BF(RXBS, -1L);
dmacfg |= GEM_BF(RXBS, buffer_size);
 
@@ -746,7 +754,7 @@ static int _macb_init(struct macb_device *macb, const char 
*name)
paddr |= MACB_BIT(RX_WRAP);
macb->rx_ring[i].addr = paddr;
macb->rx_ring[i].ctrl = 0;
-   paddr += 128;
+   paddr += macb->rx_buffer_size;
}
macb_flush_ring_desc(macb, RX);
macb_flush_rx_buffer(macb);
@@ -957,8 +965,13 @@ static void _macb_eth_initialize(struct macb_device *macb)
int id = 0; /* This is not used by functions we call */
u32 ncfgr;
 
+   if (macb_is_gem(macb))
+   macb->rx_buffer_size = GEM_RX_BUFFER_SIZE;
+   else
+   macb->rx_buffer_size = MACB_RX_BUFFER_SIZE;
+
/* TODO: we need check the rx/tx_ring_dma is dcache line aligned */
-   macb->rx_buffer = dma_alloc_coherent(MACB_RX_BUFFER_SIZE,
+   macb->rx_buffer = dma_alloc_coherent(macb->rx_buffer_size * 
MACB_RX_RING_SIZE,
 >rx_buffer_dma);
macb->rx_ring = dma_alloc_coherent(MACB_RX_DMA_DESC_SIZE,
   >rx_ring_dma);
-- 
2.22.0

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

Re: [U-Boot] efi_loader: implementing non-volatile UEFI variables

2019-06-24 Thread Wolfgang Denk

Dear Heinrich,

In message <7083d208-4b3c-7261-a03b-9066dc8d2...@gmx.de> you wrote:
>
> to be really useful UEFI variables should be available to the operating
> system. This is not possible using U-Boot variables as storage.

Oops?  Is it possible that you are not aware of the
tools/env/fw_env* code?

Of course U-Boot environment variables can be accessed (read and
written) from Linux.

> >> And maybe a fourth dummy one implementing no variable service at all.
> >
> > Is this really a good idea?
>
> Tom is always complaining that the UEFI subsystem has become too large.

And I agree on that.  But even if it was not the case, having four
different implementations for the same thing is  sub-optiman.

And if the "volatile" feature is all that is missing when using
environment variables, then this should be the road taken:

- It avoids a complete new implementation
- It can be added witrh very little effort
- It would be just a minimal increase in memory footprinmt
- It is useful for a lot of other pirposes as well.

What are your agruments for _not_ taking this approach?

> The best solution for UEFI variables would be to live in the secure part
> of the ARM trusted firmware.

You think too narrow. Not all the world is ARM, and not everyone
uses ATF.

> UEFI variables have both a name and a GUID as keys.

Internally U-Boot variables are stored in a hash table; you could
easily add GUID support.  the external storage format is also simple
enough.  You could extend it in a compatible way for example from

=\0

to something like

;=\0

of, if you don't want to waste another separator character, even

==\0

Extending the env import parser and the env export code for this
does not look like rocket science either.

> Furthermore both
> variable names and values are in UTF-16. So they are quite different to
> U-Boot variables.

Nothing in U-Boot prevents this.  There is a number of ways to
convert UTF-16 (or even any kind of binary data) to and from plain
ASCII strings, and only your UEFI code needs to understand such
encoding.

> Look at this output:
>
> -> printenv
>
> efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={boot,run}(blob)
> efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLang={nv,boot,run}(blob)656e2d555300
> efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLangCodes={boot,run}(blob)656e2d555300
> efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_RuntimeServicesSupported={boot,run}(blob)8004
>
> => printenv -e
>
> OsIndicationsSupported: BS|RT, DataSize = 0x8
>  : 00 00 00 00 00 00 00 00  
> PlatformLang: NV|BS|RT, DataSize = 0x6
>  : 65 6e 2d 55 53 00en-US.
> PlatformLangCodes: BS|RT, DataSize = 0x6
>  : 65 6e 2d 55 53 00en-US.
> RuntimeServicesSupported: BS|RT, DataSize = 0x2
>  : 80 04..

I'm looking at it, but I don't understand what you want to show me
here?

All I can see is that this looks like something I would not want to
use (read: I consider it ugly and think the design should be
improved).

> This is worthwhile but insufficient to solve the UEFI problems.

Could you please be so kine and clearly state what is lacking?

So far I have found:

- lack of "volatile" vs. "non-volatile"
- lack of support for GUID
- lack of support for UTF-16

None of these should be difficult to add by small (or even minimal)
extensions of the existing code, which would probaly also useful to
others (at least some of them).

So far, I see no killing point not an advantage that would justify
adding a completly new implementation for a problem that has been
solved before.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Everyone, in some small sacred sanctuary of the self, is nuts.
 - Leo Rosten
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] usb: kbd: simplify coding for arrow keys

Hi Heinrich,

On Mon, 24 Jun 2019 at 11:36, Heinrich Schuchardt  wrote:
>
> On 6/24/19 3:56 PM, Simon Glass wrote:
> > On Sun, 16 Jun 2019 at 22:44, Heinrich Schuchardt  
> > wrote:
> >>
> >> Avoid duplicate translation of arrow key codes.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >>   common/usb_kbd.c | 31 +--
> >>   1 file changed, 9 insertions(+), 22 deletions(-)
> >
> > Reviewed-by: Simon Glass 
> >
> > We should really have a test for this input stuff...
> >
>
> We already have.
>
> For low level analysis:
>
> => conitrace
> Waiting for your input
> To terminate type 'x'
> 61
> 1b 5b 32 30 7e
>
> For a higher level view:
>
> => setenv efi_selftest extended text input
> => bootefi selftest
> Executing 'extended text input'
> Waiting for your input
> To terminate type 'CTRL+x'
> Unicode char 100 ('d'), scan code 0 (Null)
> Unicode char 0 (Null), scan code 19 (+FN 9)
> Unicode char 0 (Null), scan code 19 (SHIFT+FN 9)

I mean automated test :-)

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

Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB

Hi Heinrich,

OK...I can't remember the details but there is a tool that does that. The
format that U-Boot's proftool emits is pretty standard. I recall using it
with a tool the kernel uses to get info like you are looking for.

Regards,
Simon


On Mon, 24 Jun 2019 at 11:30, Heinrich Schuchardt 
wrote:

> On 6/24/19 3:56 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt 
> wrote:
> >>
> >> On 6/22/19 9:10 PM, Simon Glass wrote:
> >>> On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt 
> wrote:
> 
>  There is no good reason to limit the trace buffer to 2GiB on a 64bit
>  system. Adjust the types of the relevant parameters.
> 
>  Signed-off-by: Heinrich Schuchardt 
>  ---
> cmd/trace.c  | 10 --
> include/trace.h  |  6 +++---
> lib/trace.c  | 14 +++---
> tools/proftool.c |  4 ++--
> 4 files changed, 16 insertions(+), 18 deletions(-)
> >>>
> >>> Wow it's going to take a very long time to transfer that much data
> >>> over your network.
> >>
> >> Thanks for reviewing.
> >>
> >> I am writing files with the traces to the mounted file system.
> >>
> >> I activated traces in lib/efi_loader only and found several hundred
> >> thousand function calls just to start Shell.efi which ended up in
> >> exceeding the trace buffer. This is why want to lift unnecessary
> >> restrictions.
> >>
> >> What I still need to write is a script to analyze the traces to
> >> calculate the gross and the net time spent in each function.
> >
> > OK I see, sounds good. Also, I suppose you saw that you can use
> > pytimechart to view the data, as in README.trace
>
> Yes, thanks I saw it. I would like to get output like this:
>
>
> https://sapinsider.wispubs.com/-/media/Alloy/Images/Assets/Articles/2018%20January/SPI-01-2018_Mensch_Fig07-large.jpg
>
> where for each function I see:
>
> * number of invocations
> * gross time (sum of individual exit time minus entry time)
> * net time (the same but without the calls invoked by the function)
>
> Regards
>
> Heinrich
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v4 0/4] add command env erase

On Mon, Jun 24, 2019 at 12:30:01PM +0200, Frank Wunderlich wrote:
> no opinion about the last version?
> 
> regards Frank
> 
> > Am 28. April 2019 10:51:24 MESZ schrieb Frank Wunderlich 
> > :
> > >sometimes it is needed to erase the non-volatile environment
> > >e.g. for boot-up with builtin-environment or after resizing env
> > >
> > >this series add basic functionality for erasing environment from
> > >storage
> > >as a first storage-driver mmc is introduced, other needs to be added
> > >later
> > >
> > >changes since v3:
> > > - fixes
> > > - Kconfig-option as suggested by Simon Goldschmidt
> > > - including CONFIG_ENV_OFFSET_REDUND (4/4 is RFC)
> > >
> > >Frank Wunderlich (4):
> > >  env: register erase command
> > >  env: mmc: add erase-function
> > >  env: add option to use redundant offset
> > >  [RFC] env: call env_erase twice if CONFIG_ENV_OFFSET_REDUND is set
> > >
> > > cmd/Kconfig   |  8 
> > > cmd/nvedit.c  | 26 ++
> > > env/env.c | 30 ++
> > > env/mmc.c | 36 
> > > include/environment.h | 17 +
> > > 5 files changed, 117 insertions(+)

Seems like a reasonable concept and I believe I looked it over and
everything new is under a CONFIG guard, so, thanks!

-- 
Tom


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

Re: [U-Boot] pull request: raspberry pi updates

On Wed, Jun 12, 2019 at 04:25:33PM -0400, Tom Rini wrote:
> On Wed, Jun 12, 2019 at 10:21:22PM +0200, Heinrich Schuchardt wrote:
> > On 6/12/19 10:08 PM, Tom Rini wrote:
> > >On Wed, Jun 12, 2019 at 10:07:31PM +0200, Heinrich Schuchardt wrote:
> > >>On 6/12/19 9:56 PM, Tom Rini wrote:
> > >>>On Wed, Jun 12, 2019 at 03:48:06PM +0100, Peter Robinson wrote:
> > Hi Matthias,
> > 
> > Have these been out on the list for general review? I don't remember
> > seeing them.
> > 
> > On Wed, Jun 12, 2019 at 1:57 PM Matthias Brugger  
> > wrote:
> > >
> > >Hi Tom,
> > >
> > >Please have a look on the following patches.
> > >
> > >Regards,
> > >Matthias
> > >
> > >---
> > >The following changes since commit 
> > >fc6c0e29a28f6b71dfb728b7f78e9e770f2cd218:
> > >
> > >   Prepare v2019.07-rc4 (2019-06-10 21:27:46 -0400)
> > >
> > >are available in the Git repository at:
> > >
> > >   https://github.com/mbgg/u-boot.git tags/rpi-next-2019.07
> > >
> > >for you to fetch changes up to 
> > >38e58ff2b785b45e8c8ade8e23f916a1984016c6:
> > >
> > >   ARM: bcm283x: Fix definition of MBOX_TAG_TEST_PIXEL_ORDER 
> > > (2019-06-12 12:23:46
> > >+0200)
> > >
> > >
> > >- fix complation error for CONFIG_USB
> > >- update RPi3 DTBs to v5.1-rc6 state
> > >- add defconfig for RPi3 B+
> > 
> > Why do we need a separate config when it's detected and works
> > perfectly well with the standard rpi_3 and rpi_3_32b configs?
> > >>>
> > >>>Good question.  It came from Heinrich, so Heinrich?
> > >>
> > >>If we call the bootefi command without a OS supplied device tree the
> > >>U-Boot device tree is passed to the operating system.
> > >>
> > >>So we need a device tree which is a complete description of the
> > >>respective system.
> > >>
> > >>On the Linaro boot-architecture list there has been a lengthy discussion
> > >>with Linaro people thinking that it is the responsibility of the
> > >>hardware and firmware to provide the correct device tree and not of the 
> > >>OS.
> > >
> > >OK, but on Pi aren't we passed, and pass along, the dtb from the
> > >previous stage?
> > >
> > Currently `bootefi` uses as default what it finds in $fdt_control_addr
> > and provides this to GRUB, Linux, or any other payload.
> 
> Right, and maybe I'm mistaken, but doesn't the previous stage on Pi pass
> in a device tree, that U-Boot then uses?

I haven't taken this as I haven't gotten an answer to this part.  I
could have sworn that the proprietary loader passed along the device
tree that's passed by us to the next stage.

-- 
Tom


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

Re: [U-Boot] Crash in U-Boot


On 6/24/19 7:56 AM, Alexander Graf wrote:




Am 24.06.2019 um 00:01 schrieb Ard Biesheuvel :


On Sun, 23 Jun 2019 at 23:47, Alexander Graf  wrote:




Am 23.06.2019 um 17:08 schrieb Heinrich Schuchardt :

Hello Alex,

on the i.MX6 Wandboard the Kernel crashes when booting via GRUB at least
since U-Boot v2019.01. See below.

In the code for SetVirtualAddressMap I saw the that the pointer to the
list of configuration tables is adjusted:

if ((map_start <= (uintptr_t)systab.tables) &&
(map_end >= (uintptr_t)systab.tables)) {
char *ptr = (char *)systab.tables;
ptr += off;
systab.tables = (struct efi_configuration_table *)ptr;
}

Shouldn't the pointers to the individual configuration tables be
adjusted too? I found no such code.


We have to adapt the systable, because RT code may use it. However, I thought 
tables are not guaranteed to be around after SVAM? Ard?



Only the system table pointers are updated for virtual remapping. I'm
not entirely sure why, but this permits the runtime firmware
components themselves to access the array. However, runtime firmware
typically has no way to translate a physical address into a virtual
address, so if they need to access such tables, they have to grab the
address *before* SVAM(), which means it doesn't matter whether the
config table array point is translated as well.


I tend to agree that in that case, adjusting the table pointer does not sound 
very useful either. Can we legally just set the table count to 0 there?



No. The OS expects to be able to locate config tables, and the OS
itself does not care about runtime remapping.


If however they are indeed legal to access via virtual addresses afterwards, I 
do agree that we should patch the individual table pointers too, yes.




Please don't do the sane thing. Where's the fun in that? :-)


I keep forgetting that we talk UEFI here ;). So the status quo is correct? Or 
do we have to drop the relocation part for the table array pointer?


EDK2 is doing it just like U-Boot. Change the pointer to the array. Do
not change the array.

Regards

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

Re: [U-Boot] efi_loader: implementing non-volatile UEFI variables


On 6/24/19 12:23 PM, Wolfgang Denk wrote:

Dear Heinrich,

In message <83a2d8c5-1b06-c502-8a63-dc3ca307d...@gmx.de> you wrote:


thanks a lot for the good online meeting this morning together with your
colleague Suggan where we discussed the requirements for the
implementation of non-volatile variables in U-Boot.

Currently UEFI variables are stored in U-Boot variables. Saving the
U-Boot variables will persist all UEFI variables in the environment both
volatile and non-volatile. This does not conform the the UEFI standard.


Is this the only problem of using the environment as storage?


Dear Wolfgang,

to be really useful UEFI variables should be available to the operating
system. This is not possible using U-Boot variables as storage.




To provide a secure storage Linaro is considering to implement an OP-TEE
module for variable storage and as alternative to this OP-TEE module a
standalone MM service which will be a BL32 ATF module.

So in future we will have possibly three alternative drivers for UEFI
variables:

- U-Boot only implementation
   (what is now in lib/efi_loader/efi_variable.c)
- OP-TEE module
- standalone MM service

And maybe a fourth dummy one implementing no variable service at all.


Is this really a good idea?


Tom is always complaining that the UEFI subsystem has become too large.
As GRUB and Linux boot without UEFI variables they are one possibility
to size down the image. But I would not choose this config option by
default.



If the volatile / non-volatile behaviour is the only problem you
see with using environment variables, would it then not make much
more sense to extend the environment flags concept by adding a
"volatile" flag, with the meaning that such variables don't get
written by "env save"?


The best solution for UEFI variables would be to live in the secure part
of the ARM trusted firmware.

UEFI variables have both a name and a GUID as keys. Furthermore both
variable names and values are in UTF-16. So they are quite different to
U-Boot variables.

Look at this output:

=> printenv

efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_OsIndicationsSupported={boot,run}(blob)
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLang={nv,boot,run}(blob)656e2d555300
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_PlatformLangCodes={boot,run}(blob)656e2d555300
efi_8be4df61-93ca-11d2-aa0d-00e098032b8c_RuntimeServicesSupported={boot,run}(blob)8004

=> printenv -e

OsIndicationsSupported: BS|RT, DataSize = 0x8
: 00 00 00 00 00 00 00 00  
PlatformLang: NV|BS|RT, DataSize = 0x6
: 65 6e 2d 55 53 00en-US.
PlatformLangCodes: BS|RT, DataSize = 0x6
: 65 6e 2d 55 53 00en-US.
RuntimeServicesSupported: BS|RT, DataSize = 0x2
: 80 04..



This would also make sense in some other places - for example, the
"filesize" variable is a perfect candidate to be flagged as
"volatile".  There is absolutely no use in saving it persistently.

So such an extension would be useful for others, too, and might
eventually avoid so many different implementations for the same
task?  Also, the implementation should be straightforward...



This is worthwhile but insufficient to solve the UEFI problems.

Best regards

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

Re: [U-Boot] [PATCH V2] usb: ehci-mx6: Fix bus enumeration for DM case

2019-06-24 Thread Marek Vasut

On 6/24/19 7:47 PM, Adam Ford wrote:
> On Mon, Jun 24, 2019 at 12:07 PM Marek Vasut  wrote:
>>
>> The EHCI iMX6 driver is only partly converted to DT probing and
>> still uses a tremendous amount of hard-coded addresses. Worse,
>> the driver uses hard-coded SoC-model-specific base addresses, which
>> are derived from values protected by SoC-specific macros, hence the
>> driver is also compiled for a specific SoC model. Even worse, the
>> driver depends on specific sequential indexing of the controllers,
>> from which it derives offsets in the PHY and ANATOP register sets.
>>
>> However, when the driver is probed from DT, the indexing is not
>> correct. In fact, each controller has index 0. This patch derives
>> the index for DT probing case from the controller base addresses,
>> which is not the way this should be done, however it is the least
>> intrusive approach, favorable this close to release.
>>
>> The necessary steps to convert this driver fully to DT probing are
>> described inside the patch, however this should be done in the next
>> release and depends on iMX clock driver patches.
>>
>> Signed-off-by: Marek Vasut 
> 
> I can test this, but I am curious to know what I am supposed to see
> and/if what's observable since I have been on vacation, I'm still
> catching up on e-mails.

Try "usb reset", on some platforms with DM_USB enabled, every controller
except for the first will either fail to init or the system will hang.

-- 
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] usb: ehci-mx6: Fix bus enumeration for DM case

On Mon, Jun 24, 2019 at 12:07 PM Marek Vasut  wrote:
>
> The EHCI iMX6 driver is only partly converted to DT probing and
> still uses a tremendous amount of hard-coded addresses. Worse,
> the driver uses hard-coded SoC-model-specific base addresses, which
> are derived from values protected by SoC-specific macros, hence the
> driver is also compiled for a specific SoC model. Even worse, the
> driver depends on specific sequential indexing of the controllers,
> from which it derives offsets in the PHY and ANATOP register sets.
>
> However, when the driver is probed from DT, the indexing is not
> correct. In fact, each controller has index 0. This patch derives
> the index for DT probing case from the controller base addresses,
> which is not the way this should be done, however it is the least
> intrusive approach, favorable this close to release.
>
> The necessary steps to convert this driver fully to DT probing are
> described inside the patch, however this should be done in the next
> release and depends on iMX clock driver patches.
>
> Signed-off-by: Marek Vasut 

I can test this, but I am curious to know what I am supposed to see
and/if what's observable since I have been on vacation, I'm still
catching up on e-mails.

adam
> Cc: Abel Vesa 
> Cc: Adam Ford 
> Cc: Fabio Estevam 
> Cc: Ludwig Zenz 
> Cc: Lukasz Majewski 
> Cc: Peng Fan 
> Cc: Stefano Babic 
> Cc: Vagrant Cascadian 
> ---
> V2: Derive the controller index from it's base address
> ---
>  drivers/usb/host/ehci-mx6.c | 37 +
>  1 file changed, 37 insertions(+)
>
> diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
> index 33abfeada0..e9e6ed596d 100644
> --- a/drivers/usb/host/ehci-mx6.c
> +++ b/drivers/usb/host/ehci-mx6.c
> @@ -503,6 +503,42 @@ static int ehci_usb_ofdata_to_platdata(struct udevice 
> *dev)
> return 0;
>  }
>
> +static int ehci_usb_bind(struct udevice *dev)
> +{
> +   /*
> +* TODO:
> +* This driver is only partly converted to DT probing and still uses
> +* a tremendous amount of hard-coded addresses. To make things worse,
> +* the driver depends on specific sequential indexing of controllers,
> +* from which it derives offsets in the PHY and ANATOP register sets.
> +*
> +* Here we attempt to calculate these indexes from DT information as
> +* well as we can. The USB controllers on all existing iMX6/iMX7 SoCs
> +* are placed next to each other, at addresses incremented by 0x200.
> +* Thus, the index is derived from the multiple of 0x200 offset from
> +* the first controller address.
> +*
> +* However, to complete conversion of this driver to DT probing, the
> +* following has to be done:
> +* - DM clock framework support for iMX must be implemented
> +* - usb_power_config() has to be converted to clock framework
> +*   -> Thus, the ad-hoc "index" variable goes away.
> +* - USB PHY handling has to be factored out into separate driver
> +*   -> Thus, the ad-hoc "index" variable goes away from the PHY
> +*  code, the PHY driver must parse it's address from DT. This
> +*  USB driver must find the PHY driver via DT phandle.
> +*   -> usb_power_config() shall be moved to PHY driver
> +* With these changes in place, the ad-hoc indexing goes away and
> +* the driver is fully converted to DT probing.
> +*/
> +   fdt_size_t size;
> +   fdt_addr_t addr = devfdt_get_addr_size_index(dev, 0, );
> +
> +   dev->req_seq = (addr - USB_BASE_ADDR) / size;
> +
> +   return 0;
> +}
> +
>  static int ehci_usb_probe(struct udevice *dev)
>  {
> struct usb_platdata *plat = dev_get_platdata(dev);
> @@ -564,6 +600,7 @@ U_BOOT_DRIVER(usb_mx6) = {
> .id = UCLASS_USB,
> .of_match = mx6_usb_ids,
> .ofdata_to_platdata = ehci_usb_ofdata_to_platdata,
> +   .bind   = ehci_usb_bind,
> .probe  = ehci_usb_probe,
> .remove = ehci_deregister,
> .ops= _usb_ops,
> --
> 2.20.1
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] usb: kbd: simplify coding for arrow keys


On 6/24/19 3:56 PM, Simon Glass wrote:

On Sun, 16 Jun 2019 at 22:44, Heinrich Schuchardt  wrote:


Avoid duplicate translation of arrow key codes.

Signed-off-by: Heinrich Schuchardt 
---
  common/usb_kbd.c | 31 +--
  1 file changed, 9 insertions(+), 22 deletions(-)


Reviewed-by: Simon Glass 

We should really have a test for this input stuff...



We already have.

For low level analysis:

=> conitrace
Waiting for your input
To terminate type 'x'
61
1b 5b 32 30 7e

For a higher level view:

=> setenv efi_selftest extended text input
=> bootefi selftest
Executing 'extended text input'
Waiting for your input
To terminate type 'CTRL+x'
Unicode char 100 ('d'), scan code 0 (Null)
Unicode char 0 (Null), scan code 19 (+FN 9)
Unicode char 0 (Null), scan code 19 (SHIFT+FN 9)

Regards

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

Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB


On 6/24/19 3:56 PM, Simon Glass wrote:

Hi Heinrich,

On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt  wrote:


On 6/22/19 9:10 PM, Simon Glass wrote:

On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt  wrote:


There is no good reason to limit the trace buffer to 2GiB on a 64bit
system. Adjust the types of the relevant parameters.

Signed-off-by: Heinrich Schuchardt 
---
   cmd/trace.c  | 10 --
   include/trace.h  |  6 +++---
   lib/trace.c  | 14 +++---
   tools/proftool.c |  4 ++--
   4 files changed, 16 insertions(+), 18 deletions(-)


Wow it's going to take a very long time to transfer that much data
over your network.


Thanks for reviewing.

I am writing files with the traces to the mounted file system.

I activated traces in lib/efi_loader only and found several hundred
thousand function calls just to start Shell.efi which ended up in
exceeding the trace buffer. This is why want to lift unnecessary
restrictions.

What I still need to write is a script to analyze the traces to
calculate the gross and the net time spent in each function.


OK I see, sounds good. Also, I suppose you saw that you can use
pytimechart to view the data, as in README.trace


Yes, thanks I saw it. I would like to get output like this:

https://sapinsider.wispubs.com/-/media/Alloy/Images/Assets/Articles/2018%20January/SPI-01-2018_Mensch_Fig07-large.jpg

where for each function I see:

* number of invocations
* gross time (sum of individual exit time minus entry time)
* net time (the same but without the calls invoked by the function)

Regards

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

Re: [U-Boot] [PATCH v3] Add a simple script to remove boards

On Mon, 20 May 2019 at 01:19, Chris Packham  wrote:
>
> On Sun, 19 May 2019, 4:07 AM Simon Glass,  wrote:
>>
>> This script attempts to create a git commit which removes a single board.
>> It is quite fallible and everything it does needs checking. But it can
>> help speed up the process.
>>
>> Signed-off-by: Simon Glass 
>
>
> Reviewed-by: Chris Packham 

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

Re: [U-Boot] [U-Boot-DM] [PATCH] drivers: serial: lpuart: Enable Little Endian Support

Hi,

On Fri, 19 Apr 2019 at 03:34, Marek Vasut  wrote:
>
> On 4/18/19 2:30 PM, Vabhav Sharma wrote:
> > Hello Maintainers,
> > A gentle reminder to merge the changes.
>
> Next time, use
> $ ./scripts/get_maintainer.pl -f drivers/serial/serial_lpuart.c
> and actually CC the maintainers.
>
> > Regards,
> > Vabhav

Applied to u-boot-dm, thanks!
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 00/21] patman: Update to support Python 3

On Wed, 15 May 2019 at 02:02, Chris Packham  wrote:
>
> On Wed, May 15, 2019 at 9:54 AM Simon Glass  wrote:
> >
> > This series updates patman to support Python 3:
> >
> > - Avoid using 'unicode' type directly
> > - Use items() instead of iteritems()
> > - Make sure file I/O uses binary mode where necessary
> > - Change print statements to functions
> > - Use the built-in set() class
> > - Fix up generation of repeated bytes
> >
> > A few patches for binman are included, but this still requires Python 2.
> >
>
> Couple of comments on 14/21 but the rest of the series
>
> Reviewed-by: Chris Packham 
>
> >
> > Simon Glass (21):
> >   patman: Update cros_subprocess to use bytearray
> >   patman: Convert print statements to Python 3
> >   binman: Convert print statements to Python 3
> >   binman: Don't show errors for failed tests
> >   binman: Remove use of Set()
> >   patman: Use items() instead of iteritems()
> >   binman: Use items() instead of iteritems()
> >   tools: binman: Open all binary files in binary mode
> >   tools: dtoc: Open all binary files in binary mode
> >   patman: Provide a way to get program output in binary mode
> >   binman: Use binary mode when compressing data
> >   binman: Drop an unused input file
> >   binman: Handle repeated bytes for Python 3
> >   Add a simple script to remove boards
> >   patman: Support use of stringIO in Python 3
> >   patman: Move unicode helpers to tools
> >   patman: Sort series output for repeatabily
> >   patman: Avoid unicode type in settings unit tests
> >   patman: Adjust functional tests for Python 3
> >   patman: Tidy up a few more unicode conversions
> >   patman: Don't require Python 2
> >
> >  tools/binman/binman.py   |  26 +++-
> >  tools/binman/bsection.py |   7 +-
> >  tools/binman/control.py  |   8 +-
> >  tools/binman/elf.py  |   4 +-
> >  tools/binman/elf_test.py |   2 +-
> >  tools/binman/entry.py|   5 +-
> >  tools/binman/etype/blob.py   |   2 +-
> >  tools/binman/etype/fill.py   |   4 +-
> >  tools/binman/etype/gbb.py|   2 +-
> >  tools/binman/etype/u_boot_spl_bss_pad.py |   2 +-
> >  tools/binman/ftest.py|  81 ++--
> >  tools/binman/state.py|   7 +-
> >  tools/dtoc/fdt.py|   2 +-
> >  tools/patman/cros_subprocess.py  |  53 +---
> >  tools/patman/func_test.py|  41 ---
> >  tools/patman/gitutil.py  |  16 +--
> >  tools/patman/patman.py   |   2 +-
> >  tools/patman/series.py   |  20 +--
> >  tools/patman/settings.py |  34 ++---
> >  tools/patman/test_util.py|  16 +--
> >  tools/patman/tools.py|  55 -
> >  tools/rmboard.py | 150 +++
> >  22 files changed, 385 insertions(+), 154 deletions(-)
> >  create mode 100755 tools/rmboard.py
> >
> > --
> > 2.21.0.1020.gf2820cf01a-goog
> >

Applied series to u-boot-dm/next

Due to a patchwork bug, some patches show up with missing spaces in
the UI, e.g. here http://patchwork.ozlabs.org/bundle/sjg/dm/

So my script which emails on each patch doesn't work, sorry.


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

Re: [U-Boot] [PATCH 00/24] binman: dtoc: Convert to Python 3

Hi,

On Fri, 17 May 2019 at 22:01, Simon Glass  wrote:
>
> This series updates both binman and dtoc to support Python 3 as well as
> Python 2. This mostly involves moving the code to use the 'bytes' type
> on Python 3 (with associated unicode conversions) but there are various
> other tweaks required as well.
>
>
> Simon Glass (24):
>   dtoc: Adjust code for Python 3
>   dtoc: Sort platdata output from dtoc
>   dtoc: Use GetBytes() to obtain repeating bytes
>   dtoc: Move BytesToValue() out of the Prop class
>   dtoc: Updates BytesToValue() for Python 3
>   dtoc: Use byte type instead of str in fdt
>   dtoc: Convert the Fdt.Prop class to Python 3
>   dtoc: Convert the Fdt.Node class to Python 3
>   dtoc: Use binary mode for reading files
>   dtoc: Test full 64-bit properties with FdtCellsToCpu()
>   dtoc: Add a unit test for BytesToValue()
>   dtoc: Update fdt_util for Python 3
>   dtoc: Update dtb_platdata to support Python 3
>   patman: Allow reading files in text mode
>   binman: Avoid changing a dict during iteration
>   binman: Convert to use bytes type
>   binman: Update entry_test to support Python 3
>   patman: Update fmap code for Python 3
>   binman: Update 'text' entry for Python 3
>   binman: Fix up a format string in AssertInList()
>   binman: Read map files as text
>   binman: Document parallel tests
>   binman: Update the README.entries file
>   patman: Update cover-coverage tests for Python 3
>
>  tools/binman/README |  14 ++
>  tools/binman/README.entries |  15 ++
>  tools/binman/control.py |   7 +-
>  tools/binman/elf_test.py|   5 +-
>  tools/binman/entry_test.py  |   6 +-
>  tools/binman/etype/_testing.py  |   2 +-
>  tools/binman/etype/fmap.py  |   3 +-
>  tools/binman/etype/text.py  |   9 +-
>  tools/binman/etype/u_boot_dtb_with_ucode.py |   4 +-
>  tools/binman/etype/u_boot_ucode.py  |   4 +-
>  tools/binman/etype/vblock.py|   2 +-
>  tools/binman/fmap_util.py   |  12 +-
>  tools/binman/ftest.py   | 136 +-
>  tools/dtoc/dtb_platdata.py  |  10 +-
>  tools/dtoc/dtoc.py  |   8 +-
>  tools/dtoc/fdt.py   | 146 +++-
>  tools/dtoc/fdt_util.py  |  15 +-
>  tools/dtoc/test_dtoc.py |  16 ++-
>  tools/dtoc/test_fdt.py  |  51 ---
>  tools/patman/test_util.py   |  15 +-
>  tools/patman/tools.py   |  56 +++-
>  21 files changed, 335 insertions(+), 201 deletions(-)
>
> --
> 2.21.0.1020.gf2820cf01a-goog
>

Applied series to u-boot-dm/next

Due to a patchwork bug, some patches show up with missing spaces in
the UI, e.g. here http://patchwork.ozlabs.org/bundle/sjg/dm/

So my script which emails on each patch doesn't work, sorry.


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

Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released

2019-06-24 Thread Marek Vasut

On 6/24/19 3:56 PM, Simon Glass wrote:
> Hi Andreas,,
> 
> On Sat, 22 Jun 2019 at 20:49, Andreas Färber  wrote:
>>
>> Hi Simon,
>>
>> Am 22.06.19 um 21:14 schrieb Simon Glass:
>>> On Sat, 22 Jun 2019 at 20:08, Andreas Färber  wrote:
 Am 22.06.19 um 20:15 schrieb Simon Glass:
> On Sat, 22 Jun 2019 at 16:10, Andreas Färber  wrote:
>> Am 22.06.19 um 16:55 schrieb Simon Glass:
>>> I'd like to better understand the benefits of the 3-month timeline.
>>
>> It takes time to learn about a release, package and build it, test it on
>> various hardware, investigate and report errors, wait for feedback and
>> fixes, rinse and repeat with the next -rc. Many people don't do this as
>> their main job.
>>
>> If we shorten the release cycle, newer boards will get out faster (which
>> is good) but the overall quality of boards not actively worked on
>> (because they were working good enough before) will decay, which is bad.
>> The only way to counteract that would be to automatically test on real
>> hardware rather than just building, and doing that for all these masses
>> of boards seems unrealistic.
>
> Here I think you are talking about distributions. But why not just
> take every second release?

 You're missing my point: What good is it to do a release when you
 yourself consider it of such poor quality that you advise others not to
 take it?
>>>
>>> Who said that?
>>
>> You, quoted above. In response to my concerns about decreasing quality
>> you suggested to take only every second release. That doesn't improve
>> the quality of either. It implies that one may have such bad quality
>> that people should skip it and yet does nothing to improve the next.
> 
> Actually I did not say that I consider the release of such poor
> quality. Nor did I advise others to take it. I suspect this is a
> misunderstanding of "But why not just take every second release?".
> 
> My point was that if people don't have time to test every release,
> then just put in the time to test every second release.

So what about be the point of releasing the untested intermediate
release at all ? I'm sure people can just grab u-boot/master or -rc2
just fine.

[...]

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

[U-Boot] [PATCH V2] usb: ehci-mx6: Fix bus enumeration for DM case

2019-06-24 Thread Marek Vasut

The EHCI iMX6 driver is only partly converted to DT probing and
still uses a tremendous amount of hard-coded addresses. Worse,
the driver uses hard-coded SoC-model-specific base addresses, which
are derived from values protected by SoC-specific macros, hence the
driver is also compiled for a specific SoC model. Even worse, the
driver depends on specific sequential indexing of the controllers,
from which it derives offsets in the PHY and ANATOP register sets.

However, when the driver is probed from DT, the indexing is not
correct. In fact, each controller has index 0. This patch derives
the index for DT probing case from the controller base addresses,
which is not the way this should be done, however it is the least
intrusive approach, favorable this close to release.

The necessary steps to convert this driver fully to DT probing are
described inside the patch, however this should be done in the next
release and depends on iMX clock driver patches.

Signed-off-by: Marek Vasut 
Cc: Abel Vesa 
Cc: Adam Ford 
Cc: Fabio Estevam 
Cc: Ludwig Zenz 
Cc: Lukasz Majewski 
Cc: Peng Fan 
Cc: Stefano Babic 
Cc: Vagrant Cascadian 
---
V2: Derive the controller index from it's base address
---
 drivers/usb/host/ehci-mx6.c | 37 +
 1 file changed, 37 insertions(+)

diff --git a/drivers/usb/host/ehci-mx6.c b/drivers/usb/host/ehci-mx6.c
index 33abfeada0..e9e6ed596d 100644
--- a/drivers/usb/host/ehci-mx6.c
+++ b/drivers/usb/host/ehci-mx6.c
@@ -503,6 +503,42 @@ static int ehci_usb_ofdata_to_platdata(struct udevice *dev)
return 0;
 }
 
+static int ehci_usb_bind(struct udevice *dev)
+{
+   /*
+* TODO:
+* This driver is only partly converted to DT probing and still uses
+* a tremendous amount of hard-coded addresses. To make things worse,
+* the driver depends on specific sequential indexing of controllers,
+* from which it derives offsets in the PHY and ANATOP register sets.
+*
+* Here we attempt to calculate these indexes from DT information as
+* well as we can. The USB controllers on all existing iMX6/iMX7 SoCs
+* are placed next to each other, at addresses incremented by 0x200.
+* Thus, the index is derived from the multiple of 0x200 offset from
+* the first controller address.
+*
+* However, to complete conversion of this driver to DT probing, the
+* following has to be done:
+* - DM clock framework support for iMX must be implemented
+* - usb_power_config() has to be converted to clock framework
+*   -> Thus, the ad-hoc "index" variable goes away.
+* - USB PHY handling has to be factored out into separate driver
+*   -> Thus, the ad-hoc "index" variable goes away from the PHY
+*  code, the PHY driver must parse it's address from DT. This
+*  USB driver must find the PHY driver via DT phandle.
+*   -> usb_power_config() shall be moved to PHY driver
+* With these changes in place, the ad-hoc indexing goes away and
+* the driver is fully converted to DT probing.
+*/
+   fdt_size_t size;
+   fdt_addr_t addr = devfdt_get_addr_size_index(dev, 0, );
+
+   dev->req_seq = (addr - USB_BASE_ADDR) / size;
+
+   return 0;
+}
+
 static int ehci_usb_probe(struct udevice *dev)
 {
struct usb_platdata *plat = dev_get_platdata(dev);
@@ -564,6 +600,7 @@ U_BOOT_DRIVER(usb_mx6) = {
.id = UCLASS_USB,
.of_match = mx6_usb_ids,
.ofdata_to_platdata = ehci_usb_ofdata_to_platdata,
+   .bind   = ehci_usb_bind,
.probe  = ehci_usb_probe,
.remove = ehci_deregister,
.ops= _usb_ops,
-- 
2.20.1

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

[U-Boot] [PATCH] drivers/spi: fsl_qspi: fix controller busy check

2019-06-24 Thread Fabio Estevam

From: Thomas Schaefer 

During QSPI reads, current is_busy_controller function sporadically
fails with -ETIMEDOUT due to fixed number of 5 test loops. This patch
fixes this by using the readl_poll_timeout function with
1000 us timeout.

Signed-off-by: Thomas Schaefer 
Signed-off-by: Fabio Estevam 
---
 drivers/spi/fsl_qspi.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 1598c4f698..41abe1996f 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -150,20 +151,13 @@ static void qspi_write32(u32 flags, u32 *addr, u32 val)
 static inline int is_controller_busy(const struct fsl_qspi_priv *priv)
 {
u32 val;
-   const u32 mask = QSPI_SR_BUSY_MASK | QSPI_SR_AHB_ACC_MASK |
-QSPI_SR_IP_ACC_MASK;
-   unsigned int retry = 5;
+   u32 mask = QSPI_SR_BUSY_MASK | QSPI_SR_AHB_ACC_MASK |
+  QSPI_SR_IP_ACC_MASK;
 
-   do {
-   val = qspi_read32(priv->flags, >regs->sr);
+   if (priv->flags & QSPI_FLAG_REGMAP_ENDIAN_BIG)
+   mask = (u32)cpu_to_be32(mask);
 
-   if ((~val & mask) == mask)
-   return 0;
-
-   udelay(1);
-   } while (--retry);
-
-   return -ETIMEDOUT;
+   return readl_poll_timeout(>regs->sr, val, !(val & mask), 1000);
 }
 
 /* QSPI support swapping the flash read/write data
-- 
2.11.0

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

Re: [U-Boot] [U-Boot-DM] [PATCH] drivers: serial: lpuart: Enable Little Endian Support

Hi Vabhav,

On Thu, 18 Apr 2019 at 06:30, Vabhav Sharma  wrote:
>
> Hello Maintainers,
> A gentle reminder to merge the changes.
>
> Regards,
> Vabhav
>
> > -Original Message-
> > From: Vabhav Sharma
> > Sent: Thursday, January 31, 2019 5:38 PM
> > To: u-boot@lists.denx.de; u-boot...@lists.denx.de
> > Cc: Vabhav Sharma 
> > Subject: [PATCH] drivers: serial: lpuart: Enable Little Endian Support
> >
> > By default LPUART driver with compatible string "fsl,ls1021a-lpuart"
> > support big-endian mode.On NXP SoC like LS1028A LPUART IP is little-
> > endian,Added support to Fetch LPUART IP Endianness from lpuart device-
> > tree node.
> >
> > Signed-off-by: Vabhav Sharma 
> > ---
> >  drivers/serial/serial_lpuart.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/serial/serial_lpuart.c 
> > b/drivers/serial/serial_lpuart.c index
> > a357b00..57dd4a7 100644
> > --- a/drivers/serial/serial_lpuart.c
> > +++ b/drivers/serial/serial_lpuart.c
> > @@ -1,5 +1,6 @@
> >  // SPDX-License-Identifier: GPL-2.0+
> >  /*
> > + * Copyright 2019 NXP
> >   * Copyright 2013 Freescale Semiconductor, Inc.
> >   */
> >
> > @@ -502,6 +503,9 @@ static int lpuart_serial_ofdata_to_platdata(struct
> > udevice *dev)
> >   plat->reg = (void *)addr;
> >   plat->flags = dev_get_driver_data(dev);
> >
> > +if (fdtdec_get_bool(blob, node, "little-endian"))
> > +plat->flags &= ~LPUART_FLAG_REGMAP_ENDIAN_BIG;

As Marek says, please cc the maintainers. If you use 'patman' to send
your patches, it will be done for you.

Reviewed-by: Simon Glass 

Can I suggest that you change this driver to live-tree instead?
(dev_read_bool()).

> > +
> >  if (!fdt_node_check_compatible(blob, node, "fsl,ls1021a-lpuart"))
> >  plat->devtype = DEV_LS1021A;

This should use a compatible array - see lpuart_serial_ids. It seems
that this is currently used for flags, but it could use the DEV_...
values.

> >   else if (!fdt_node_check_compatible(blob, node, "fsl,imx7ulp-
> > lpuart"))
> > --
> > 2.7.4
>
> ___
> U-Boot-DM mailing list
> u-boot...@lists.denx.de
> https://lists.denx.de/listinfo/u-boot-dm

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

[U-Boot] [PATCH] ARM: am3517-evm: Migrate to SPL_OF_CONTROL

Like the other Logic PD OMAP35/DM37 boards, this board has device
tree enabled for U-Boot.  This patch converts the board to enable
SPL_OF_CONTROL and further shrinks the device tree in SPL to limit
it to UART3 (console), MMC1, i2c1, and GPIO4 (for mmc1 CD and WP).

There appears to be a bug in minicom so users may need to
switch the minicom terminal emulation to ANSI from VT102 due
to the junk that gets pushed out of the UART on startup.

Signed-off-by: Adam Ford 

diff --git a/arch/arm/dts/am3517-evm-u-boot.dtsi 
b/arch/arm/dts/am3517-evm-u-boot.dtsi
index 59df819f9d..d5a4ce97d1 100644
--- a/arch/arm/dts/am3517-evm-u-boot.dtsi
+++ b/arch/arm/dts/am3517-evm-u-boot.dtsi
@@ -4,20 +4,40 @@
  * Logic PD - http://www.logicpd.com
  */
 
+#include "omap3-u-boot.dtsi"
+
 / {
-   chosen {
-   stdout-path = 
+   aliases {
+   /delete-property/ serial0;
+   /delete-property/ serial1;
+   };
+
+   ocp@6800 {
+   /delete-node/ bandgap@48002524;
};
 };
 
- {
-   reg-shift = <2>;
+ {
+   /delete-property/ u-boot,dm-spl;
+};
+
+ {
+   /delete-property/ u-boot,dm-spl;
+};
+
+ {
+   /delete-property/ u-boot,dm-spl;
 };
 
- {
-   reg-shift = <2>;
+ {
+   /delete-property/ u-boot,dm-spl;
 };
 
- {
-   reg-shift = <2>;
+ {
+   /delete-property/ u-boot,dm-spl;
 };
+
+/delete-node/ 
+/delete-node/ 
+/delete-node/ 
+/delete-node/ 
diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index b9f59f3291..64e62a4205 100644
--- a/configs/am3517_evm_defconfig
+++ b/configs/am3517_evm_defconfig
@@ -1,11 +1,15 @@
 CONFIG_ARM=y
+# CONFIG_SPL_USE_ARCH_MEMCPY is not set
+# CONFIG_TPL_USE_ARCH_MEMCPY is not set
+# CONFIG_SPL_USE_ARCH_MEMSET is not set
+# CONFIG_TPL_USE_ARCH_MEMSET is not set
 CONFIG_ARCH_OMAP2PLUS=y
 CONFIG_SYS_TEXT_BASE=0x8010
 CONFIG_TI_COMMON_CMD_OPTIONS=y
-# CONFIG_SPL_GPIO_SUPPORT is not set
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_SYS_MALLOC_F_LEN=0x4000
 CONFIG_TARGET_AM3517_EVM=y
 CONFIG_EMIF4=y
+CONFIG_SPL_SYS_MALLOC_F_LEN=0x3000
 CONFIG_NR_DRAM_BANKS=2
 CONFIG_SPL=y
 CONFIG_DISTRO_DEFAULTS=y
@@ -14,7 +18,10 @@ CONFIG_BOOTDELAY=10
 CONFIG_VERSION_VARIABLE=y
 CONFIG_SPL_TEXT_BASE=0x4020
 CONFIG_SPL_SYS_MALLOC_SIMPLE=y
+CONFIG_SPL_SEPARATE_BSS=y
+# CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_USE_SECTOR is not set
 # CONFIG_SPL_FS_EXT4 is not set
+# CONFIG_SPL_I2C_SUPPORT is not set
 CONFIG_SPL_MTD_SUPPORT=y
 CONFIG_SPL_OS_BOOT=y
 CONFIG_SYS_PROMPT="AM3517_EVM # "
@@ -34,9 +41,13 @@ CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand.0"
 
CONFIG_MTDPARTS_DEFAULT="mtdparts=omap2-nand.0:512k(MLO),1920k(u-boot),256k(u-boot-env),8m(kernel),512k(dtb),-(rootfs)"
 CONFIG_CMD_UBI=y
 CONFIG_OF_CONTROL=y
+CONFIG_SPL_OF_CONTROL=y
 CONFIG_DEFAULT_DEVICE_TREE="am3517-evm"
 # CONFIG_ENV_IS_IN_FAT is not set
 CONFIG_ENV_IS_IN_NAND=y
+CONFIG_SPL_DM=y
+CONFIG_SPL_DM_SEQ_ALIAS=y
+CONFIG_SPL_OF_TRANSLATE=y
 CONFIG_DM_PCA953X=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_NAND=y
@@ -49,7 +60,6 @@ CONFIG_DRIVER_TI_EMAC=y
 CONFIG_PINCTRL=y
 CONFIG_PINCTRL_SINGLE=y
 # CONFIG_TWL4030_POWER is not set
-CONFIG_CONS_INDEX=3
 CONFIG_SPI=y
 CONFIG_DM_SPI=y
 CONFIG_OMAP3_SPI=y
@@ -59,3 +69,4 @@ CONFIG_USB_EHCI_HCD=y
 CONFIG_USB_MUSB_HOST=y
 CONFIG_USB_MUSB_AM35X=y
 CONFIG_BCH=y
+CONFIG_SPL_TINY_MEMSET=y
-- 
2.17.1

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

Re: [U-Boot] [PATCH v2] net: davinci_emac: convert to using the driver model


On 6/24/19 5:21 PM, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski 
>
> Now that we removed all legacy boards selecting TI_EMAC we can
> completely convert the driver code to using the driver model.
> This patch also updates all remaining users of davinci_emac.
>
> Signed-off-by: Bartosz Golaszewski 
> ---
> v1 -> v2:
> - moved the packetp assignment to the top of the recv() callback which fixes
>   a crash on am3517_evm
> - dropped a redundant call to net_process_received_packet(): this is already
>   called from eth core
>
> Thanks goes to Adam Ford for much appreciated testing and help.
>
> Tested on da850-lcdk and da850-evm.
>
>  arch/arm/mach-davinci/cpu.c| 13 -
>  arch/arm/mach-omap2/omap3/emac.c   |  3 +-
>  board/davinci/da8xxevm/da850evm.c  |  6 --
>  board/davinci/da8xxevm/omapl138_lcdk.c | 14 -
>  board/logicpd/am3517evm/am3517evm.c|  1 -
>  board/ti/ti816x/evm.c  |  3 +-
>  configs/am3517_evm_defconfig   |  1 +
>  configs/da850evm_defconfig |  1 +
>  configs/da850evm_direct_nor_defconfig  |  1 +
>  configs/da850evm_nand_defconfig|  1 +
>  configs/omapl138_lcdk_defconfig|  1 +
>  configs/ti816x_evm_defconfig   |  1 +
>  drivers/net/ti/davinci_emac.c  | 77 ++
>  include/netdev.h   |  1 -
>  14 files changed, 50 insertions(+), 74 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
> index f97ad3fc74..9fd6564d04 100644
> --- a/arch/arm/mach-davinci/cpu.c
> +++ b/arch/arm/mach-davinci/cpu.c
> @@ -5,7 +5,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
>   gd->bd->bi_dsp_freq = 0;
>   return 0;
>  }
> -
> -/*
> - * Initializes on-chip ethernet controllers.
> - * to override, implement board_eth_init()
> - */
> -int cpu_eth_init(bd_t *bis)
> -{
> -#if defined(CONFIG_DRIVER_TI_EMAC)
> - davinci_emac_initialize();
> -#endif
> - return 0;
> -}
> diff --git a/arch/arm/mach-omap2/omap3/emac.c 
> b/arch/arm/mach-omap2/omap3/emac.c
> index c79e870183..fb0c9188f5 100644
> --- a/arch/arm/mach-omap2/omap3/emac.c
> +++ b/arch/arm/mach-omap2/omap3/emac.c
> @@ -7,7 +7,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  
> @@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis)
>   reset &= ~CPGMACSS_SW_RST;
>   writel(reset, _scm_general_regs->ip_sw_reset);
>  
> - return davinci_emac_initialize();
> + return 0;
>  }
> diff --git a/board/davinci/da8xxevm/da850evm.c 
> b/board/davinci/da8xxevm/da850evm.c
> index a90b7a3538..a5c583444d 100644
> --- a/board/davinci/da8xxevm/da850evm.c
> +++ b/board/davinci/da8xxevm/da850evm.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -472,11 +471,6 @@ int board_eth_init(bd_t *bis)
>   if (rmii_hw_init())
>   printf("RMII hardware init failed!!!\n");
>  #endif
> - if (!davinci_emac_initialize()) {
> - printf("Error: Ethernet init failed!\n");
> - return -1;
> - }
> -
>   return 0;
>  }
>  #endif /* CONFIG_DRIVER_TI_EMAC */
> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
> b/board/davinci/da8xxevm/omapl138_lcdk.c
> index fe1bf44101..dd11551428 100644
> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -229,19 +228,6 @@ int board_init(void)
>  
>  #ifdef CONFIG_DRIVER_TI_EMAC
>  
> -/*
> - * Initializes on-board ethernet controllers.
> - */
> -int board_eth_init(bd_t *bis)
> -{
> - if (!davinci_emac_initialize()) {
> - printf("Error: Ethernet init failed!\n");
> - return -1;
> - }
> -
> - return 0;
> -}
> -
>  #endif /* CONFIG_DRIVER_TI_EMAC */
>  
>  #define CFG_MAC_ADDR_SPI_BUS 0
> diff --git a/board/logicpd/am3517evm/am3517evm.c 
> b/board/logicpd/am3517evm/am3517evm.c
> index 10031a4801..bfd4e78274 100644
> --- a/board/logicpd/am3517evm/am3517evm.c
> +++ b/board/logicpd/am3517evm/am3517evm.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "am3517evm.h"
>  
>  DECLARE_GLOBAL_DATA_PTR;
> diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
> index 07a084bab8..240df8cbe1 100644
> --- a/board/ti/ti816x/evm.c
> +++ b/board/ti/ti816x/evm.c
> @@ -9,7 +9,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -56,7 +55,7 @@ int board_eth_init(bd_t *bis)
>   printf("Unable to read MAC address. Set \n");
>   }
>  
> - return davinci_emac_initialize();
> + return 0;
>  }
>  
>  #ifdef CONFIG_SPL_BUILD
> diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
> index b9f59f3291..5cb76322df 100644
> --- a/configs/am3517_evm_defconfig
> +++

Re: [U-Boot] [PATCH v2] net: davinci_emac: convert to using the driver model

On Mon, Jun 24, 2019 at 9:21 AM Bartosz Golaszewski  wrote:
>
> From: Bartosz Golaszewski 
>
> Now that we removed all legacy boards selecting TI_EMAC we can
> completely convert the driver code to using the driver model.
> This patch also updates all remaining users of davinci_emac.
>
> Signed-off-by: Bartosz Golaszewski 

Tested-by: Adam Ford  #am3517-evm & da850-evm
> ---
> v1 -> v2:
> - moved the packetp assignment to the top of the recv() callback which fixes
>   a crash on am3517_evm
> - dropped a redundant call to net_process_received_packet(): this is already
>   called from eth core
>
> Thanks goes to Adam Ford for much appreciated testing and help.
>
> Tested on da850-lcdk and da850-evm.
>
>  arch/arm/mach-davinci/cpu.c| 13 -
>  arch/arm/mach-omap2/omap3/emac.c   |  3 +-
>  board/davinci/da8xxevm/da850evm.c  |  6 --
>  board/davinci/da8xxevm/omapl138_lcdk.c | 14 -
>  board/logicpd/am3517evm/am3517evm.c|  1 -
>  board/ti/ti816x/evm.c  |  3 +-
>  configs/am3517_evm_defconfig   |  1 +
>  configs/da850evm_defconfig |  1 +
>  configs/da850evm_direct_nor_defconfig  |  1 +
>  configs/da850evm_nand_defconfig|  1 +
>  configs/omapl138_lcdk_defconfig|  1 +
>  configs/ti816x_evm_defconfig   |  1 +
>  drivers/net/ti/davinci_emac.c  | 77 ++
>  include/netdev.h   |  1 -
>  14 files changed, 50 insertions(+), 74 deletions(-)
>
> diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
> index f97ad3fc74..9fd6564d04 100644
> --- a/arch/arm/mach-davinci/cpu.c
> +++ b/arch/arm/mach-davinci/cpu.c
> @@ -5,7 +5,6 @@
>   */
>
>  #include 
> -#include 
>  #include 
>  #include 
>
> @@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
> gd->bd->bi_dsp_freq = 0;
> return 0;
>  }
> -
> -/*
> - * Initializes on-chip ethernet controllers.
> - * to override, implement board_eth_init()
> - */
> -int cpu_eth_init(bd_t *bis)
> -{
> -#if defined(CONFIG_DRIVER_TI_EMAC)
> -   davinci_emac_initialize();
> -#endif
> -   return 0;
> -}
> diff --git a/arch/arm/mach-omap2/omap3/emac.c 
> b/arch/arm/mach-omap2/omap3/emac.c
> index c79e870183..fb0c9188f5 100644
> --- a/arch/arm/mach-omap2/omap3/emac.c
> +++ b/arch/arm/mach-omap2/omap3/emac.c
> @@ -7,7 +7,6 @@
>   */
>
>  #include 
> -#include 
>  #include 
>  #include 
>
> @@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis)
> reset &= ~CPGMACSS_SW_RST;
> writel(reset, _scm_general_regs->ip_sw_reset);
>
> -   return davinci_emac_initialize();
> +   return 0;
>  }
> diff --git a/board/davinci/da8xxevm/da850evm.c 
> b/board/davinci/da8xxevm/da850evm.c
> index a90b7a3538..a5c583444d 100644
> --- a/board/davinci/da8xxevm/da850evm.c
> +++ b/board/davinci/da8xxevm/da850evm.c
> @@ -13,7 +13,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -472,11 +471,6 @@ int board_eth_init(bd_t *bis)
> if (rmii_hw_init())
> printf("RMII hardware init failed!!!\n");
>  #endif
> -   if (!davinci_emac_initialize()) {
> -   printf("Error: Ethernet init failed!\n");
> -   return -1;
> -   }
> -
> return 0;
>  }
>  #endif /* CONFIG_DRIVER_TI_EMAC */
> diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
> b/board/davinci/da8xxevm/omapl138_lcdk.c
> index fe1bf44101..dd11551428 100644
> --- a/board/davinci/da8xxevm/omapl138_lcdk.c
> +++ b/board/davinci/da8xxevm/omapl138_lcdk.c
> @@ -11,7 +11,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -229,19 +228,6 @@ int board_init(void)
>
>  #ifdef CONFIG_DRIVER_TI_EMAC
>
> -/*
> - * Initializes on-board ethernet controllers.
> - */
> -int board_eth_init(bd_t *bis)
> -{
> -   if (!davinci_emac_initialize()) {
> -   printf("Error: Ethernet init failed!\n");
> -   return -1;
> -   }
> -
> -   return 0;
> -}
> -
>  #endif /* CONFIG_DRIVER_TI_EMAC */
>
>  #define CFG_MAC_ADDR_SPI_BUS   0
> diff --git a/board/logicpd/am3517evm/am3517evm.c 
> b/board/logicpd/am3517evm/am3517evm.c
> index 10031a4801..bfd4e78274 100644
> --- a/board/logicpd/am3517evm/am3517evm.c
> +++ b/board/logicpd/am3517evm/am3517evm.c
> @@ -28,7 +28,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include "am3517evm.h"
>
>  DECLARE_GLOBAL_DATA_PTR;
> diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
> index 07a084bab8..240df8cbe1 100644
> --- a/board/ti/ti816x/evm.c
> +++ b/board/ti/ti816x/evm.c
> @@ -9,7 +9,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -56,7 +55,7 @@ int board_eth_init(bd_t *bis)
> printf("Unable to read MAC address. Set \n");
> }
>
> -   return davinci_emac_initialize();
> +   return 0;
>  }
>
>  #ifdef CONFIG_SPL_BUILD
> diff --git a/configs/am3517_evm_defconfig

Re: [U-Boot] QSPI support on i.MX7D Sabre Eval Board

2019-06-24 Thread Fabio Estevam

Hi Thomas,

On Mon, Jun 24, 2019 at 12:47 PM Thomas Schaefer
 wrote:

> Following Fabio's suggestion I have prepared the following patch that fixes 
> the QSPI read support issue of the fsl_qspi driver on my i.MX7D Sabre eval 
> system. Could you please review/check this patch and introduce it into 
> upcoming v2019.07 version?
>
> Thanks, Thomas
>
>
> From: Thomas Schaefer 
> Date: Mon, 24 Jun 2019 17:15:57 +0200
> Subject: [PATCH] driver/spi: fsl_qspi: fix is_controller_busy check
>
> Use readl_poll_timeout function to check for busy controller with
> a timeout of 1000 us instead of 5 fixed test loops.
>
> Signed-off-by: Thomas Schaefer 

I think the change looks good, but I suggest to improve the commit log
by stating that with the current code you observe timeout during QSPI
read.

Please submit it as formal patch.

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

Re: [U-Boot] [PATCH V2 1/3] test: dm: adc: use the real device name

On Wed, Jun 19, 2019 at 02:17:59AM +, Peng Fan wrote:
> Hi Simon, Tom
> > Subject: [PATCH V2 1/3] test: dm: adc: use the real device name
> > 
> > "adc" is not the real device name, "adc@0" is.
> > 
> > Signed-off-by: Peng Fan 
> 
> Will you pick up this patchset?
> https://patchwork.ozlabs.org/patch/1103212/
> https://patchwork.ozlabs.org/patch/1103213/
> https://patchwork.ozlabs.org/patch/1103214/

For the next release.  Or should they really come in now?  Thanks!

-- 
Tom


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

Re: [U-Boot] QSPI support on i.MX7D Sabre Eval Board

2019-06-24 Thread Thomas Schaefer

Hi all,


> Hi Fabio,
> 
> > Hi Thomas,
> > 
> > On Wed, Jun 19, 2019 at 10:04 AM Thomas Schaefer 
> >  wrote:
> > >
> > > Hi all,
> > >
> > > I've built current u-boot (v2019.07-rc4) with QSPI support for our i.MX7D 
> > > Sabre eval system. I am using mx7dsabresd_qspi_defconfig.
> > >
> > > The resulting u-boot fails to read from QSPI, i.e. the data read is not 
> > > the same than that written before with a previous (v2018) version.
> > >
> > > After some investigation I found that the 'is_controller_busy' function 
> > > comes back with -ETIMEDOUT during read operation, because the retry count 
> > > >of 5 is too low.
> > >
> > > To figure out how many retries are needed, I added some debug code as 
> > > part of a while(1) loop to the is_controller_busy function:
> > >
> > > diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
> > > 1598c4f698..fa5b7a29f2 100644
> > > --- a/drivers/spi/fsl_qspi.c
> > > +++ b/drivers/spi/fsl_qspi.c
> > > @@ -152,16 +152,20 @@ static inline int is_controller_busy(const struct 
> > > fsl_qspi_priv *priv)
> > > u32 val;
> > > const u32 mask = QSPI_SR_BUSY_MASK | QSPI_SR_AHB_ACC_MASK |
> > >  QSPI_SR_IP_ACC_MASK;
> > > -   unsigned int retry = 5;
> > > +   unsigned int retry = 0;
> > >
> > > do {
> > > val = qspi_read32(priv->flags, >regs->sr);
> > >
> > > -   if ((~val & mask) == mask)
> > > +   if ((~val & mask) == mask) {
> > > +   if (retry > 5)
> > > +   printf("%s: timeout! retry = %d\n", 
> > > + __func__, retry);
> > > return 0;
> > > +   }
> > >
> > > udelay(1);
> > > -   } while (--retry);
> > > +   retry++;
> > > +   } while (1);
> > >
> > > return -ETIMEDOUT;
> > >  }
> > >
> > > On my MX7 eval system I found that a retry count between 73 and 147 is 
> > > necessary to make sure that the controller will be ready before the next 
> > > operation.
> > >
> > > So from my point of view we have 2 options to fix this issue:
> > >
> > > - increase retry from 5 to 200
> > > - wait in an endless loop (while (1) ) and return only when the 
> > > controller is ready (which means that the board will hang if the 
> > > controller doesn't come back for some other reason.
> > >
> > > What do you think?
> >
> > I think that readl_poll_timeout() could be used here as it will timeout if 
> > the QSPI controller is not ready.
> >
> > Also, could you check how this is handled in the fsl qspi driver in the 
> > kernel?
> 
> There is a similar readl_plll_tout call in 5.1.12 linux kernel driver 
> (spi-fsl-qspi.c) with 1000us timeout:
> 
> /* wait for the controller being ready */ fsl_qspi_readl_poll_tout(q, base + 
> QUADSPI_SR, (QUADSPI_SR_IP_ACC_MASK |
>QUADSPI_SR_AHB_ACC_MASK), 10, 1000);
> 
> The fsl additions take concern about endianess before calling the general 
> 'readl_poll_timeout' function.
> 
> Thomas
>

Following Fabio's suggestion I have prepared the following patch that fixes the 
QSPI read support issue of the fsl_qspi driver on my i.MX7D Sabre eval system. 
Could you please review/check this patch and introduce it into upcoming 
v2019.07 version?

Thanks, Thomas


From: Thomas Schaefer 
Date: Mon, 24 Jun 2019 17:15:57 +0200
Subject: [PATCH] driver/spi: fsl_qspi: fix is_controller_busy check

Use readl_poll_timeout function to check for busy controller with
a timeout of 1000 us instead of 5 fixed test loops.

Signed-off-by: Thomas Schaefer 
---
 drivers/spi/fsl_qspi.c | 18 ++
 1 file changed, 6 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c
index 1598c4f698..41abe1996f 100644
--- a/drivers/spi/fsl_qspi.c
+++ b/drivers/spi/fsl_qspi.c
@@ -10,6 +10,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -150,20 +151,13 @@ static void qspi_write32(u32 flags, u32 *addr, u32 val)
 static inline int is_controller_busy(const struct fsl_qspi_priv *priv)
 {
u32 val;
-   const u32 mask = QSPI_SR_BUSY_MASK | QSPI_SR_AHB_ACC_MASK |
-QSPI_SR_IP_ACC_MASK;
-   unsigned int retry = 5;
+   u32 mask = QSPI_SR_BUSY_MASK | QSPI_SR_AHB_ACC_MASK |
+  QSPI_SR_IP_ACC_MASK;

-   do {
-   val = qspi_read32(priv->flags, >regs->sr);
+   if (priv->flags & QSPI_FLAG_REGMAP_ENDIAN_BIG)
+   mask = (u32)cpu_to_be32(mask);

-   if ((~val & mask) == mask)
-   return 0;
-
-   udelay(1);
-   } while (--retry);
-
-   return -ETIMEDOUT;
+   return readl_poll_timeout(>regs->sr, val, !(val & mask), 1000);
 }

 /* QSPI support swapping the flash read/write data
--
2.11.0

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

Re: [U-Boot] [U-Boot-Custodians] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released

On Sat, Jun 22, 2019 at 09:43:42PM +0200, Marek Vasut wrote:
> On 6/22/19 9:12 PM, Heinrich Schuchardt wrote:
> > On 6/22/19 8:15 PM, Simon Glass wrote:
> >> Hi,
> >>
> >> On Sat, 22 Jun 2019 at 16:10, Andreas Färber  wrote:
> >>>
> >>> Hi Simon,
> >>>
> >>> Am 22.06.19 um 16:55 schrieb Simon Glass:
>  I'd like to better understand the benefits of the 3-month timeline.
> >>>
> >>> It takes time to learn about a release, package and build it, test it on
> >>> various hardware, investigate and report errors, wait for feedback and
> >>> fixes, rinse and repeat with the next -rc. Many people don't do this as
> >>> their main job.
> >>>
> >>> If we shorten the release cycle, newer boards will get out faster (which
> >>> is good) but the overall quality of boards not actively worked on
> >>> (because they were working good enough before) will decay, which is bad.
> >>> The only way to counteract that would be to automatically test on real
> >>> hardware rather than just building, and doing that for all these masses
> >>> of boards seems unrealistic.
> >>
> >> Here I think you are talking about distributions. But why not just
> >> take every second release?
> >>
> >> I have certain had the experience of getting a board our of the
> >> cupboard and finding that the latest U-Boot doesn't work, nor the one
> >> before, nor the three before that.
> >>
> >> Are we actually seeing an improvement in regressions? I feel that
> >> testing is the only way to get that.
> >>
> >> Perhaps we should select a small subset of boards which do get tested,
> >> and actually have custodians build/test on those for every rc?
> > 
> > What I have been doing before all my recent pull requests is to boot
> > both an arm32 (Orange Pi) and and an aarch64 (Pine A64 LTS) board via
> > bootefi and GRUB. To make this easier I am using a Raspberry with a
> > relay board and a Tizen SD-Wire card (https://wiki.tizen.org/SDWire)
> > controlling the system under test,
> > cf https://pbs.twimg.com/media/D5ugi3iX4AAh1bn.jpg:large
> > What would be needed is scripts to automate the testing including all
> > the Python tests.
> > 
> > It would make sense to have such test automation for all of our
> > architectures similar to what Kernel CI (https://kernelci.org/) does.
> 
> So who's gonna set it up and host it ?

My hope is that we can make use of the GitLab CI features to carefully
() expose some labs and setups.

-- 
Tom


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

Re: [U-Boot] [ANNOUNCEMENT] Switching to gitlab.denx.de

On Mon, Jun 24, 2019 at 03:04:41PM +0200, Harald Seiler wrote:
> Hello Peng,
> 
> On Thu, 2019-06-20 at 06:42 +, Peng Fan wrote:
> > Hi Wolfgang,
> > 
> [...]
> > > 
> > > The switch will take place as follows:
> > > 
> > > 1. We will create user accounts for all custodians at gitlab.denx.de
> > >You will receive an e-mail notification with your login
> > >credentials. We will start with this this afternoon (CEST),
> > >so if you have not received such an e-mail by tomorrow morning,
> > >please let us know.
> > 
> > I did not receive email, could you please check?
> 
> You are not listed as custodian for any of the trees in either the wiki
> or MAINTAINERS.  Can you please verify to me which trees you should have
> access to?

Hey now:
MMC
M:  Peng Fan 
S:  Maintained
T:  git https://gitlab.denx.de/u-boot/custodians/u-boot-mmc.git
F:  drivers/mmc/

is in MAINTAINERS currently, btw.  Maybe a few others got missed too?
Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH] net: davinci_emac: convert to using the driver model

2019-06-24 Thread Bartosz Golaszewski

pon., 24 cze 2019 o 15:39 Adam Ford  napisał(a):
>
> On Mon, Jun 24, 2019 at 7:07 AM Bartosz Golaszewski  wrote:
> >
> > śr., 12 cze 2019 o 18:46 Adam Ford  napisał(a):
> > >
> > > On Mon, Jun 3, 2019 at 10:29 AM Bartosz Golaszewski  wrote:
> > > >
> > > > pon., 3 cze 2019 o 15:03 Adam Ford  napisał(a):
> > > > >
> > > > > On Mon, Jun 3, 2019 at 3:12 AM Bartosz Golaszewski  
> > > > > wrote:
> > > > > >
> > > > > > sob., 1 cze 2019 o 05:24 Adam Ford  napisał(a):
> > > > > > >
> > > > > > > On Fri, May 31, 2019 at 8:32 AM Bartosz Golaszewski 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > From: Bartosz Golaszewski 
> > > > > > > >
> > > > > > > > Now that we removed all legacy boards selecting TI_EMAC we can
> > > > > > > > completely convert the driver code to using the driver model.
> > > > > > > > This patch also updates all remaining users of davinci_emac.
> > > > > > > >
> > > > > > >
> > > > > > > I took a break from this to come back, and I'm going to give some
> > > > > > > feedback about how the driver was written. I still do not know 
> > > > > > > why I
> > > > > > > cannot get an IP address with this patch on the AM3517-evm.
> > > > > > >
> > > > > >
> > > > > > Hi Adam,
> > > > > >
> > > > > > thanks for all the testing. Unfortunately I can only test with
> > > > > > da850-evm and da850-lcdk.
> > > > > >
> > > > > > I was wondering if it is possible that the problem is caused by
> > > > > > cpu_eth_init() from ./arch/arm/mach-omap2/omap3/emac. not being 
> > > > > > called
> > > > > > with CONFIG_DM_ETH? The comments say that it brings the module out 
> > > > > > of
> > > > > > reset, so maybe this is what causes the problem you're seeing?
> > > > >
> > > > > I looked into that nearly right away, but there is a chunk of code in
> > > > > board/logicpd/am3517evm/am3517evm.c which has a function called
> > > > > misc_init_r() which does the same thing. Looking through the debug
> > > > > data, it appears as if the drive is communicating for a bit, but at
> > > > > some point it dies.  I'm not going to be able to look at it for a few
> > > > > days.  Is there any way you can submit a V2 to use #ifdef's to allow
> > > > > users to use the same driver with and without DM_ETH?  That would give
> > > > > the da850/L138 boards the DM_ETH, and give me some time to
> > > > > troubleshoot the am3517-evm. I know Sekhar works for TI and the AM3517
> > > > > was the official development kit for TI back in the day.  If TI has
> > > > > some ideas, I'm open to trying them as well when I can get back to it.
> > > > >
> > > > > adam
> > > >
> > > > Hi Adam,
> > > >
> > > > I'm trying to find out if I can get my hands on one of these boards 
> > > > somehow.
> > > >
> > > > My priority for this week is the nand driver conversion. I'll also be
> > > > off next week and the one after. I think that since we already removed
> > > > a bunch of boards to make it possible to avoid the ifdef hell, it's
> > > > better to wait a bit more than to merge something that we'll remove
> > > > soon anyway.
> > > >
> > > > If Sekhar agrees, we can push back merging of this patch until it's 
> > > > fixed.
> > > >
> > > > There's also a big backlog of my other davinci patches on the list
> > > > anyway, maybe they'll get picked up before we get back to it.
> > > >
> > > > Bart
> > > >
> > > > >
> > > > > >
> > > > > > > > Signed-off-by: Bartosz Golaszewski 
> > > > > > > > ---
> > > > > > > >  arch/arm/mach-davinci/cpu.c| 13 -
> > > > > > > >  arch/arm/mach-omap2/omap3/emac.c   |  3 +-
> > > > > > > >  board/davinci/da8xxevm/da850evm.c  |  6 --
> > > > > > > >  board/davinci/da8xxevm/omapl138_lcdk.c | 14 -
> > > > > > > >  board/logicpd/am3517evm/am3517evm.c|  1 -
> > > > > > > >  board/ti/ti816x/evm.c  |  3 +-
> > > > > > > >  configs/am3517_evm_defconfig   |  1 +
> > > > > > > >  configs/da850evm_defconfig |  1 +
> > > > > > > >  configs/da850evm_direct_nor_defconfig  |  1 +
> > > > > > > >  configs/da850evm_nand_defconfig|  1 +
> > > > > > > >  configs/omapl138_lcdk_defconfig|  1 +
> > > > > > > >  configs/ti816x_evm_defconfig   |  1 +
> > > > > > > >  drivers/net/ti/davinci_emac.c  | 77 
> > > > > > > > ++
> > > > > > > >  include/netdev.h   |  1 -
> > > > > > > >  14 files changed, 51 insertions(+), 73 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-davinci/cpu.c 
> > > > > > > > b/arch/arm/mach-davinci/cpu.c
> > > > > > > > index f97ad3fc74..9fd6564d04 100644
> > > > > > > > --- a/arch/arm/mach-davinci/cpu.c
> > > > > > > > +++ b/arch/arm/mach-davinci/cpu.c
> > > > > > > > @@ -5,7 +5,6 @@
> > > > > > > >   */
> > > > > > > >
> > > > > > > >  #include 
> > > > > > > > -#include 
> > > > > > > >  #include 
> > > > > > > >  #include 
> > > > > > > >
> > > > > > > > @@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
> > > > > > > > gd->bd->bi_dsp_freq =

[U-Boot] [PATCH v2] net: davinci_emac: convert to using the driver model

2019-06-24 Thread Bartosz Golaszewski

From: Bartosz Golaszewski 

Now that we removed all legacy boards selecting TI_EMAC we can
completely convert the driver code to using the driver model.
This patch also updates all remaining users of davinci_emac.

Signed-off-by: Bartosz Golaszewski 
---
v1 -> v2:
- moved the packetp assignment to the top of the recv() callback which fixes
  a crash on am3517_evm
- dropped a redundant call to net_process_received_packet(): this is already
  called from eth core

Thanks goes to Adam Ford for much appreciated testing and help.

Tested on da850-lcdk and da850-evm.

 arch/arm/mach-davinci/cpu.c| 13 -
 arch/arm/mach-omap2/omap3/emac.c   |  3 +-
 board/davinci/da8xxevm/da850evm.c  |  6 --
 board/davinci/da8xxevm/omapl138_lcdk.c | 14 -
 board/logicpd/am3517evm/am3517evm.c|  1 -
 board/ti/ti816x/evm.c  |  3 +-
 configs/am3517_evm_defconfig   |  1 +
 configs/da850evm_defconfig |  1 +
 configs/da850evm_direct_nor_defconfig  |  1 +
 configs/da850evm_nand_defconfig|  1 +
 configs/omapl138_lcdk_defconfig|  1 +
 configs/ti816x_evm_defconfig   |  1 +
 drivers/net/ti/davinci_emac.c  | 77 ++
 include/netdev.h   |  1 -
 14 files changed, 50 insertions(+), 74 deletions(-)

diff --git a/arch/arm/mach-davinci/cpu.c b/arch/arm/mach-davinci/cpu.c
index f97ad3fc74..9fd6564d04 100644
--- a/arch/arm/mach-davinci/cpu.c
+++ b/arch/arm/mach-davinci/cpu.c
@@ -5,7 +5,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 
@@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
gd->bd->bi_dsp_freq = 0;
return 0;
 }
-
-/*
- * Initializes on-chip ethernet controllers.
- * to override, implement board_eth_init()
- */
-int cpu_eth_init(bd_t *bis)
-{
-#if defined(CONFIG_DRIVER_TI_EMAC)
-   davinci_emac_initialize();
-#endif
-   return 0;
-}
diff --git a/arch/arm/mach-omap2/omap3/emac.c b/arch/arm/mach-omap2/omap3/emac.c
index c79e870183..fb0c9188f5 100644
--- a/arch/arm/mach-omap2/omap3/emac.c
+++ b/arch/arm/mach-omap2/omap3/emac.c
@@ -7,7 +7,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 
@@ -24,5 +23,5 @@ int cpu_eth_init(bd_t *bis)
reset &= ~CPGMACSS_SW_RST;
writel(reset, _scm_general_regs->ip_sw_reset);
 
-   return davinci_emac_initialize();
+   return 0;
 }
diff --git a/board/davinci/da8xxevm/da850evm.c 
b/board/davinci/da8xxevm/da850evm.c
index a90b7a3538..a5c583444d 100644
--- a/board/davinci/da8xxevm/da850evm.c
+++ b/board/davinci/da8xxevm/da850evm.c
@@ -13,7 +13,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -472,11 +471,6 @@ int board_eth_init(bd_t *bis)
if (rmii_hw_init())
printf("RMII hardware init failed!!!\n");
 #endif
-   if (!davinci_emac_initialize()) {
-   printf("Error: Ethernet init failed!\n");
-   return -1;
-   }
-
return 0;
 }
 #endif /* CONFIG_DRIVER_TI_EMAC */
diff --git a/board/davinci/da8xxevm/omapl138_lcdk.c 
b/board/davinci/da8xxevm/omapl138_lcdk.c
index fe1bf44101..dd11551428 100644
--- a/board/davinci/da8xxevm/omapl138_lcdk.c
+++ b/board/davinci/da8xxevm/omapl138_lcdk.c
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -229,19 +228,6 @@ int board_init(void)
 
 #ifdef CONFIG_DRIVER_TI_EMAC
 
-/*
- * Initializes on-board ethernet controllers.
- */
-int board_eth_init(bd_t *bis)
-{
-   if (!davinci_emac_initialize()) {
-   printf("Error: Ethernet init failed!\n");
-   return -1;
-   }
-
-   return 0;
-}
-
 #endif /* CONFIG_DRIVER_TI_EMAC */
 
 #define CFG_MAC_ADDR_SPI_BUS   0
diff --git a/board/logicpd/am3517evm/am3517evm.c 
b/board/logicpd/am3517evm/am3517evm.c
index 10031a4801..bfd4e78274 100644
--- a/board/logicpd/am3517evm/am3517evm.c
+++ b/board/logicpd/am3517evm/am3517evm.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include "am3517evm.h"
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/board/ti/ti816x/evm.c b/board/ti/ti816x/evm.c
index 07a084bab8..240df8cbe1 100644
--- a/board/ti/ti816x/evm.c
+++ b/board/ti/ti816x/evm.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -56,7 +55,7 @@ int board_eth_init(bd_t *bis)
printf("Unable to read MAC address. Set \n");
}
 
-   return davinci_emac_initialize();
+   return 0;
 }
 
 #ifdef CONFIG_SPL_BUILD
diff --git a/configs/am3517_evm_defconfig b/configs/am3517_evm_defconfig
index b9f59f3291..5cb76322df 100644
--- a/configs/am3517_evm_defconfig
+++ b/configs/am3517_evm_defconfig
@@ -44,6 +44,7 @@ CONFIG_SYS_NAND_BUSWIDTH_16BIT=y
 CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y
 CONFIG_SYS_NAND_U_BOOT_OFFS=0x8
 CONFIG_SPL_NAND_SIMPLE=y
+CONFIG_DM_ETH=y
 CONFIG_MII=y
 CONFIG_DRIVER_TI_EMAC=y
 CONFIG_PINCTRL=y
diff --git a/configs/da850evm_defconfig b/configs/da850evm_defconfig
index c095058282..f7c679d3b5

[U-Boot] [PATCH v5 00/18] clk: Port Linux common clock framework [CCF] to U-boot (tag: v5.1.12)

This patch series brings the files from Linux kernel (SHA1: 5752b50477da
Linux 5.1.12 to provide clocks support as it is used on the Linux kernel
with Common Clock Framework [CCF] setup.

This series also fixes several problems with current clocks and provides
sandbox tests for functions added to clk-uclass.c file.

CCF impact to U-Boot size:
--
SPL U-Boot.img
Without CCF:51 KiB  358 KiB
With CCF:   55 KiB  363 KiB
Size increase:  1.3%7.2%

The SPL implementation is not yet optimized (no OF_PLATDATA, etc).

Repository:
https://github.com/lmajewski/u-boot-dfu/commits/CCF-v5

Applicable on top of u-boot/master:
SHA1: 77f6e2dd0551d8a825bab391a1bd6b838874bcd4

Travis-CI:
https://travis-ci.org/lmajewski/u-boot-dfu/builds/549603356


Changes in v6:
- Use dev->uclass_priv pointer to store pointer to clk

Changes in v5:
- s/U-boot/U-Boot/g
- Update Linux version to 5.1.12
- Add paragraph regarding sandbox CCF testing (common uclass code)
- Use long long to store rate value (to avoid int overflow and also return
  errors correctly)
- Use u32 to avoid checkpatch warning
- s/U-boot/U-Boot/g
- Replace dev->driver_data with dev_get_clk_ptr() wrapper on uclass_priv
- Replace ulong with long long (to accommodate large freqs and return
  errors)
- s/U-boot/U-Boot/g
- Check if the relevant code has changed between Linux tag v5.0-rc3 and
  v5.1.12 (no changes - the version can be safely updated).
- Use imply CLK_IMX6Q in Kconfig for (SPL_)CCF
- Fix clk-fixed-factor implementation (kzalloc needed for correct Sandbox
  operation)
- Fix gate2 implementation
- Use dev->uclass_priv instead of dev->driver_data to store back pointer
  to the struct clk.
- Split and introduce earlier the clk-provider.h header file

Changes in v4:
- New patch
- Port some more Linux code to facilitate imx8 code porting (most notably
  flags)
- Explicitly use container_of() based macro to provide struct clk in various
  places (e.g. gate2, mux, etc)
  Following patches has been squashed:
  http://patchwork.ozlabs.org/patch/1093141/
  http://patchwork.ozlabs.org/patch/1093142/
  http://patchwork.ozlabs.org/patch/1093146/

Changes in v3:
- New patch
- The rate information is now cached into struct clk field
- The clk_get_parent() is used to get pointer to the parent struct clk
- Replace -ENODEV with -ENOENT
- Use **clkp instead of **c
- Replace dev->driver_data with dev_get_clk_ptr() wrapper on uclas_priv

Lukasz Majewski (18):
  clk: doc: Add documentation entry for Common Clock Framework [CCF]
(i.MX)
  dm: Fix documentation entry as there is no UCLASS_CLOCK uclass
  clk: Remove clock ID check in .get_rate() of clk_fixed_*
  clk: Extend struct clk to provide information regarding clock rate
  clk: Extend struct clk to provide clock type agnostic flags
  clk: Provide struct clk for fixed rate clock (clk_fixed_rate.c)
  clk: Introduce clk-provider.h to store Common Clock Framework's
internals
  dm: clk: Define clk_get_parent() for clk operations
  dm: clk: Define clk_get_parent_rate() for clk operations
  dm: clk: Define clk_get_by_id() for clk operations
  clk: Port Linux common clock framework [CCF] for imx6q to U-boot (tag:
v5.1.12)
  dm: clk: Extend clk_get_parent_rate() to support CLK_GET_RATE_NOCACHE
flag
  dts: sandbox: Add 'osc' clock for Common Clock Framework [CCF] testing
  clk: sandbox: Adjust clk-divider to emulate reading its value from HW
  clk: sandbox: Adjust clk-mux.c to emulate reading divider value from
HW
  clk: sandbox: Add sandbox test code for Common Clock Framework [CCF]
  defconfig: sandbox: Enable SANDBOX_CLK_CCF to reuse generic CCF code
  clk: Add MAINTAINERS entry for clocks (./drivers/clk/)

 MAINTAINERS|   7 ++
 arch/sandbox/dts/test.dts  |  10 ++
 configs/sandbox_defconfig  |   1 +
 configs/sandbox_flattree_defconfig |   1 +
 doc/imx/clk/ccf.txt| 101 
 drivers/clk/Kconfig|  22 +
 drivers/clk/Makefile   |   3 +
 drivers/clk/clk-divider.c  | 155 +++
 drivers/clk/clk-fixed-factor.c |  80 
 drivers/clk/clk-mux.c  | 172 ++
 drivers/clk/clk-uclass.c   |  60 
 drivers/clk/clk.c  |  57 
 drivers/clk/clk_fixed_factor.c |   3 -
 drivers/clk/clk_fixed_rate.c   |   8 +-
 drivers/clk/clk_sandbox_ccf.c  | 185 +
 drivers/clk/imx/Kconfig|  16 
 drivers/clk/imx/Makefile   |   2 +
 drivers/clk/imx/clk-gate2.c| 103 +
 drivers/clk/imx/clk-imx6q.c| 179 +++
 drivers/clk/imx/clk-pfd.c  |  90 ++
 drivers/clk/imx/clk-pllv3.c|  82 
 drivers/clk/imx/clk.h  |  69

[U-Boot] Bug in omap_gpmc.c:omap_nand_read_prefetch

2019-06-24 Thread Reitinger, Peter

Hello,


sorry I am completely new to these kind of mailing lists, and quite probably I 
violate most of the rules for using this mailing list, but I have a serious bug 
to report and actually no time at all...


/u-boot_2019/drivers/mtd/nand/raw/omap_gpmc.c - function 
omap_nand_read_prefetch():


Whenever buf % 4 is neither 0 or 2 (i.e. 1 or 3), too few or too many bytes, 
respectively, are read before the calls to __read_prefetch_align.


Suggested fix:


original:

/*
 * If the destination buffer is unaligned, start with reading
 * the overlap byte-wise.
 */
head = ((uint32_t) buf) % 4;
if (head) {
omap_nand_read(mtd, buf, head);
buf += head;
len -= head;
}


fixed:

/*
 * If the destination buffer is unaligned, start with reading
 * the overlap byte-wise.
 */
head = ((uint32_t) buf) % 4;
if (head) {

head = 4 - head; // randomly equal to head if head == 2 ;-)
omap_nand_read(mtd, buf, head);
buf += head;
len -= head;
}


Best regards

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

Re: [U-Boot] [PATCH 1/2] usb: kbd: simplify coding for arrow keys

On Sun, 16 Jun 2019 at 22:44, Heinrich Schuchardt  wrote:
>
> Avoid duplicate translation of arrow key codes.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  common/usb_kbd.c | 31 +--
>  1 file changed, 9 insertions(+), 22 deletions(-)

Reviewed-by: Simon Glass 

We should really have a test for this input stuff...
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [U-Boot-Board-Maintainers] [ANN] U-Boot v2019.07-rc4 released

Hi Andreas,,

On Sat, 22 Jun 2019 at 20:49, Andreas Färber  wrote:
>
> Hi Simon,
>
> Am 22.06.19 um 21:14 schrieb Simon Glass:
> > On Sat, 22 Jun 2019 at 20:08, Andreas Färber  wrote:
> >> Am 22.06.19 um 20:15 schrieb Simon Glass:
> >>> On Sat, 22 Jun 2019 at 16:10, Andreas Färber  wrote:
>  Am 22.06.19 um 16:55 schrieb Simon Glass:
> > I'd like to better understand the benefits of the 3-month timeline.
> 
>  It takes time to learn about a release, package and build it, test it on
>  various hardware, investigate and report errors, wait for feedback and
>  fixes, rinse and repeat with the next -rc. Many people don't do this as
>  their main job.
> 
>  If we shorten the release cycle, newer boards will get out faster (which
>  is good) but the overall quality of boards not actively worked on
>  (because they were working good enough before) will decay, which is bad.
>  The only way to counteract that would be to automatically test on real
>  hardware rather than just building, and doing that for all these masses
>  of boards seems unrealistic.
> >>>
> >>> Here I think you are talking about distributions. But why not just
> >>> take every second release?
> >>
> >> You're missing my point: What good is it to do a release when you
> >> yourself consider it of such poor quality that you advise others not to
> >> take it?
> >
> > Who said that?
>
> You, quoted above. In response to my concerns about decreasing quality
> you suggested to take only every second release. That doesn't improve
> the quality of either. It implies that one may have such bad quality
> that people should skip it and yet does nothing to improve the next.

Actually I did not say that I consider the release of such poor
quality. Nor did I advise others to take it. I suspect this is a
misunderstanding of "But why not just take every second release?".

My point was that if people don't have time to test every release,
then just put in the time to test every second release.

I am actually not sure how much a bit of extra time helps with
stability. Have the last two releases been more reliable on hardware,
since people have found time to test them using the 9-week -rc phases,
whereas the previous 6-week one did not?

>
> > Your point, I thought, was that people didn't have time to test it?
>
> Not quite, I was talking about the full build-test-report-fix cycle
> taking its time. Bugs in one -rc don't necessarily get detected and
> fixed in time for the next -rc.

That doesn't change unless the distance between rc's increases. But I
think your point is that there are more -rc releases so more time to
find and fix things.

>
> And I fail to see how your suggestion of skipping releases gives them
> more time to test before the U-Boot release. That would rather be an
> argument for slowing down the U-Boot release cycle beyond 3 months
> (which I'm not asking).

It would mean testing only every second release, which halves the time
you spend testing, a significant reduction in load. Just need to
schedule testing time over (say) 6 week, 3 times a year instead of 6
times.

I think an automated test setup is the best way to do this. Marek asks
who would run it? Perhaps people who have an interest in each board
and want to spend less time on manual testing? We already have the
technology to do this, with pytest and tbot.

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

Re: [U-Boot] [PATCH 1/1] trace: do not limit trace buffer to 2GiB

Hi Heinrich,

On Sat, 22 Jun 2019 at 20:37, Heinrich Schuchardt  wrote:
>
> On 6/22/19 9:10 PM, Simon Glass wrote:
> > On Fri, 14 Jun 2019 at 20:51, Heinrich Schuchardt  
> > wrote:
> >>
> >> There is no good reason to limit the trace buffer to 2GiB on a 64bit
> >> system. Adjust the types of the relevant parameters.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >>   cmd/trace.c  | 10 --
> >>   include/trace.h  |  6 +++---
> >>   lib/trace.c  | 14 +++---
> >>   tools/proftool.c |  4 ++--
> >>   4 files changed, 16 insertions(+), 18 deletions(-)
> >
> > Wow it's going to take a very long time to transfer that much data
> > over your network.
>
> Thanks for reviewing.
>
> I am writing files with the traces to the mounted file system.
>
> I activated traces in lib/efi_loader only and found several hundred
> thousand function calls just to start Shell.efi which ended up in
> exceeding the trace buffer. This is why want to lift unnecessary
> restrictions.
>
> What I still need to write is a script to analyze the traces to
> calculate the gross and the net time spent in each function.

OK I see, sounds good. Also, I suppose you saw that you can use
pytimechart to view the data, as in README.trace


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

[U-Boot] [PATCH v5 17/18] defconfig: sandbox: Enable SANDBOX_CLK_CCF to reuse generic CCF code

Enable by default the Common Clock Framework [CCF] clock code for sandbox.

Signed-off-by: Lukasz Majewski 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 configs/sandbox_defconfig  | 1 +
 configs/sandbox_flattree_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/sandbox_defconfig b/configs/sandbox_defconfig
index 4cffa2c604..a6056584c2 100644
--- a/configs/sandbox_defconfig
+++ b/configs/sandbox_defconfig
@@ -92,6 +92,7 @@ CONFIG_BOOTCOUNT_LIMIT=y
 CONFIG_DM_BOOTCOUNT=y
 CONFIG_DM_BOOTCOUNT_RTC=y
 CONFIG_CLK=y
+CONFIG_SANDBOX_CLK_CCF=y
 CONFIG_CPU=y
 CONFIG_DM_DEMO=y
 CONFIG_DM_DEMO_SIMPLE=y
diff --git a/configs/sandbox_flattree_defconfig 
b/configs/sandbox_flattree_defconfig
index dda6832f83..5c69206143 100644
--- a/configs/sandbox_flattree_defconfig
+++ b/configs/sandbox_flattree_defconfig
@@ -67,6 +67,7 @@ CONFIG_DEBUG_DEVRES=y
 CONFIG_ADC=y
 CONFIG_ADC_SANDBOX=y
 CONFIG_CLK=y
+CONFIG_SANDBOX_CLK_CCF=y
 CONFIG_CPU=y
 CONFIG_DM_DEMO=y
 CONFIG_DM_DEMO_SIMPLE=y
-- 
2.11.0

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

[U-Boot] [PATCH v5 13/18] dts: sandbox: Add 'osc' clock for Common Clock Framework [CCF] testing

This patch adds the 'osc' fixed clock to facilitate the CCF testing in
the sandbox U-Boot. It is a starting point for building CCF hierarchy of
clocks.

Signed-off-by: Lukasz Majewski 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 arch/sandbox/dts/test.dts | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index 8b2d6451c6..b56c980c9d 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -211,6 +211,12 @@
clock-mult = <2>;
clocks = <_fixed>;
};
+
+   osc {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2000>;
+   };
};
 
clk_sandbox: clk-sbox {
-- 
2.11.0

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

[U-Boot] [PATCH v5 16/18] clk: sandbox: Add sandbox test code for Common Clock Framework [CCF]

This patch provides code to implement the CCF clock tree in sandbox. It
uses all the introduced primitives; some generic ones are reused, some
sandbox specific were developed.

In that way (after introducing the real CCF tree in sandbox) the recently
added to clk-uclass.c: clk_get_by_id() and clk_get_parent_rate() are tested
in their natural work environment.

Usage (sandbox_defconfig and sandbox_flattree_defconfig):
./u-boot --fdt arch/sandbox/dts/test.dtb --command "ut dm clk_ccf"

Signed-off-by: Lukasz Majewski 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 arch/sandbox/dts/test.dts |   4 +
 drivers/clk/Kconfig   |  10 ++-
 drivers/clk/Makefile  |   1 +
 drivers/clk/clk_sandbox_ccf.c | 185 ++
 include/sandbox-clk.h |  76 +
 test/dm/Makefile  |   2 +-
 test/dm/clk_ccf.c |  62 ++
 7 files changed, 338 insertions(+), 2 deletions(-)
 create mode 100644 drivers/clk/clk_sandbox_ccf.c
 create mode 100644 include/sandbox-clk.h
 create mode 100644 test/dm/clk_ccf.c

diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts
index b56c980c9d..da12adb8ce 100644
--- a/arch/sandbox/dts/test.dts
+++ b/arch/sandbox/dts/test.dts
@@ -232,6 +232,10 @@
clock-names = "fixed", "i2c", "spi";
};
 
+   ccf: clk-ccf {
+   compatible = "sandbox,clk-ccf";
+   };
+
eth@10002000 {
compatible = "sandbox,eth";
reg = <0x10002000 0x1000>;
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 9c2b284d02..9399bb79e9 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -55,7 +55,7 @@ config SPL_CLK_CCF
 
 config CLK_CCF
bool "Common Clock Framework [CCF] support "
-   depends on CLK_IMX6Q
+   depends on CLK_IMX6Q || SANDBOX_CLK_CCF
help
  Enable this option if you want to (re-)use the Linux kernel's Common
  Clock Framework [CCF] code in U-Boot's clock driver.
@@ -138,4 +138,12 @@ config CLK_MPC83XX
help
  Support for the clock driver of the MPC83xx series of SoCs.
 
+config SANDBOX_CLK_CCF
+   bool "Sandbox Common Clock Framework [CCF] support "
+   depends on SANDBOX
+   select CLK_CCF
+   help
+ Enable this option if you want to test the Linux kernel's Common
+ Clock Framework [CCF] code in U-Boot's Sandbox clock driver.
+
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 1a45bf3505..37dfd281e9 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -38,5 +38,6 @@ obj-$(CONFIG_ICS8N3QV01) += ics8n3qv01.o
 obj-$(CONFIG_MACH_PIC32) += clk_pic32.o
 obj-$(CONFIG_SANDBOX) += clk_sandbox.o
 obj-$(CONFIG_SANDBOX) += clk_sandbox_test.o
+obj-$(CONFIG_SANDBOX_CLK_CCF) += clk_sandbox_ccf.o
 obj-$(CONFIG_STM32H7) += clk_stm32h7.o
 obj-$(CONFIG_CLK_TI_SCI) += clk-ti-sci.o
diff --git a/drivers/clk/clk_sandbox_ccf.c b/drivers/clk/clk_sandbox_ccf.c
new file mode 100644
index 00..edeb0f2cf3
--- /dev/null
+++ b/drivers/clk/clk_sandbox_ccf.c
@@ -0,0 +1,185 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2019
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * Common Clock Framework [CCF] driver for Sandbox
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Sandbox implementation of CCF primitives necessary for clk-uclass testing
+ *
+ * --- Sandbox PLLv3 ---
+ */
+struct clk_pllv3 {
+   struct clk  clk;
+   u32 div_mask;
+   u32 div_shift;
+};
+
+static ulong clk_pllv3_get_rate(struct clk *clk)
+{
+   unsigned long parent_rate = clk_get_parent_rate(clk);
+
+   return parent_rate * 24;
+}
+
+static const struct clk_ops clk_pllv3_generic_ops = {
+   .get_rate   = clk_pllv3_get_rate,
+};
+
+struct clk *sandbox_clk_pllv3(enum sandbox_pllv3_type type, const char *name,
+ const char *parent_name, void __iomem *base,
+ u32 div_mask)
+{
+   struct clk_pllv3 *pll;
+   struct clk *clk;
+   char *drv_name = "sandbox_clk_pllv3";
+   int ret;
+
+   pll = kzalloc(sizeof(*pll), GFP_KERNEL);
+   if (!pll)
+   return ERR_PTR(-ENOMEM);
+
+   pll->div_mask = div_mask;
+   clk = >clk;
+
+   ret = clk_register(clk, drv_name, name, parent_name);
+   if (ret) {
+   kfree(pll);
+   return ERR_PTR(ret);
+   }
+
+   return clk;
+}
+
+U_BOOT_DRIVER(sandbox_clk_pll_generic) = {
+   .name   = "sandbox_clk_pllv3",
+   .id = UCLASS_CLK,
+   .ops= _pllv3_generic_ops,
+};
+
+/* --- Sandbox PLLv3 --- */
+/* --- Sandbox Gate  --- */
+struct clk_gate2 {
+   struct clk clk;
+   boolstate;
+};
+
+#define to_clk_gate2(_clk) container_of(_clk, struct clk_gate2, clk)
+
+static int clk_gate2_enable(struct clk

[U-Boot] [PATCH v5 11/18] clk: Port Linux common clock framework [CCF] for imx6q to U-boot (tag: v5.1.12)

This patch brings the files from Linux kernel (linux-stable/linux-5.1.y
SHA1: 5752b50477da)to provide clocks support as it is used on the Linux
kernel with Common Clock Framework [CCF] setup.

The directory structure has been preserved. The ported code only supports
reading information from PLL, MUX, Divider, etc and enabling/disabling
the clocks USDHCx/ECSPIx depending on used bus. Moreover, it is agnostic
to the alias numbering as the information about the clock is read from the
device tree.

One needs to pay attention to the comments indicating necessary for U-Boot's
driver model changes.

If needed, the code can be extended to support the "set" part of the clock
management.

Signed-off-by: Lukasz Majewski 
---

Changes in v6: None
Changes in v5:
- s/U-boot/U-Boot/g
- Check if the relevant code has changed between Linux tag v5.0-rc3 and
  v5.1.12 (no changes - the version can be safely updated).
- Use imply CLK_IMX6Q in Kconfig for (SPL_)CCF
- Fix clk-fixed-factor implementation (kzalloc needed for correct Sandbox
  operation)
- Fix gate2 implementation
- Use dev->uclass_priv instead of dev->driver_data to store back pointer
  to the struct clk.
- Split and introduce earlier the clk-provider.h header file

Changes in v4:
- Port some more Linux code to facilitate imx8 code porting (most notably
  flags)
- Explicitly use container_of() based macro to provide struct clk in various
  places (e.g. gate2, mux, etc)
  Following patches has been squashed:
  http://patchwork.ozlabs.org/patch/1093141/
  http://patchwork.ozlabs.org/patch/1093142/
  http://patchwork.ozlabs.org/patch/1093146/

Changes in v3: None

 drivers/clk/Kconfig|  14 
 drivers/clk/Makefile   |   2 +
 drivers/clk/clk-divider.c  | 147 +
 drivers/clk/clk-fixed-factor.c |  80 ++
 drivers/clk/clk-mux.c  | 164 +
 drivers/clk/clk.c  |  57 +
 drivers/clk/imx/Kconfig|  16 
 drivers/clk/imx/Makefile   |   2 +
 drivers/clk/imx/clk-gate2.c| 103 
 drivers/clk/imx/clk-imx6q.c| 179 +
 drivers/clk/imx/clk-pfd.c  |  90 +
 drivers/clk/imx/clk-pllv3.c|  82 +++
 drivers/clk/imx/clk.h  |  69 
 include/linux/clk-provider.h   | 109 +
 14 files changed, 1114 insertions(+)
 create mode 100644 drivers/clk/clk-divider.c
 create mode 100644 drivers/clk/clk-fixed-factor.c
 create mode 100644 drivers/clk/clk-mux.c
 create mode 100644 drivers/clk/clk.c
 create mode 100644 drivers/clk/imx/clk-gate2.c
 create mode 100644 drivers/clk/imx/clk-imx6q.c
 create mode 100644 drivers/clk/imx/clk-pfd.c
 create mode 100644 drivers/clk/imx/clk-pllv3.c
 create mode 100644 drivers/clk/imx/clk.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 96969b9e30..9c2b284d02 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -46,6 +46,20 @@ config CLK_BOSTON
help
  Enable this to support the clocks
 
+config SPL_CLK_CCF
+   bool "SPL Common Clock Framework [CCF] support "
+   depends on SPL_CLK_IMX6Q
+   help
+ Enable this option if you want to (re-)use the Linux kernel's Common
+ Clock Framework [CCF] code in U-Boot's SPL.
+
+config CLK_CCF
+   bool "Common Clock Framework [CCF] support "
+   depends on CLK_IMX6Q
+   help
+ Enable this option if you want to (re-)use the Linux kernel's Common
+ Clock Framework [CCF] code in U-Boot's clock driver.
+
 config CLK_STM32F
bool "Enable clock driver support for STM32F family"
depends on CLK && (STM32F7 || STM32F4)
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 719b9b8e02..1a45bf3505 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -7,6 +7,8 @@
 obj-$(CONFIG_$(SPL_TPL_)CLK) += clk-uclass.o
 obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_rate.o
 obj-$(CONFIG_$(SPL_TPL_)CLK) += clk_fixed_factor.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk.o clk-divider.o clk-mux.o
+obj-$(CONFIG_$(SPL_TPL_)CLK_CCF) += clk-fixed-factor.o
 
 obj-y += imx/
 obj-y += tegra/
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
new file mode 100644
index 00..3348d97829
--- /dev/null
+++ b/drivers/clk/clk-divider.c
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 DENX Software Engineering
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix 
+ * Copyright (C) 2011 Richard Zhao, Linaro 
+ * Copyright (C) 2011-2012 Mike Turquette, Linaro Ltd 
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "clk.h"
+
+#define UBOOT_DM_CLK_CCF_DIVIDER "ccf_clk_divider"
+
+static unsigned int _get_table_div(const struct clk_div_table *table,
+

[U-Boot] [PATCH v5 14/18] clk: sandbox: Adjust clk-divider to emulate reading its value from HW

The generic divider clock code for CCF requires reading the divider value
from HW registers. As sandbox by design has readl() as no-op it was
necessary to provide this value in the other way.

The new field in the divider structure (accessible only when sandbox is
run) has been introduced for this purpose.

Signed-off-by: Lukasz Majewski 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/clk/clk-divider.c| 10 +-
 include/linux/clk-provider.h |  3 +++
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 3348d97829..6921c76a48 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -74,7 +74,12 @@ static ulong clk_divider_recalc_rate(struct clk *clk)
unsigned long parent_rate = clk_get_parent_rate(clk);
unsigned int val;
 
-   val = readl(divider->reg) >> divider->shift;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+   val = divider->io_divider_val;
+#else
+   val = readl(divider->reg);
+#endif
+   val >>= divider->shift;
val &= clk_div_mask(divider->width);
 
return divider_recalc_rate(clk, parent_rate, val, divider->table,
@@ -112,6 +117,9 @@ static struct clk *_register_divider(struct device *dev, 
const char *name,
div->width = width;
div->flags = clk_divider_flags;
div->table = table;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+   div->io_divider_val = *(u32 *)reg;
+#endif
 
/* register the clock */
clk = >clk;
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index e06487f07b..53c9c41b90 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -75,6 +75,9 @@ struct clk_divider {
u8  width;
u8  flags;
const struct clk_div_table  *table;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+   u32 io_divider_val;
+#endif
 };
 
 #define clk_div_mask(width)((1 << (width)) - 1)
-- 
2.11.0

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

[U-Boot] [PATCH v5 15/18] clk: sandbox: Adjust clk-mux.c to emulate reading divider value from HW

The generic mux clock code for CCF requires reading the clock multiplexer
value from HW registers. As sandbox by design has readl() as no-op it was
necessary to provide this value in the other way.

The new field in the mux structure (accessible only when sandbox is run)
has been introduced for this purpose.

Signed-off-by: Lukasz Majewski 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/clk/clk-mux.c| 10 +-
 include/linux/clk-provider.h |  4 
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-mux.c b/drivers/clk/clk-mux.c
index 14b9f2b1d9..3c075aa09e 100644
--- a/drivers/clk/clk-mux.c
+++ b/drivers/clk/clk-mux.c
@@ -64,7 +64,12 @@ static u8 clk_mux_get_parent(struct clk *clk)
struct clk_mux *mux = to_clk_mux(clk);
u32 val;
 
-   val = readl(mux->reg) >> mux->shift;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+   val = mux->io_mux_val;
+#else
+   val = readl(mux->reg);
+#endif
+   val >>= mux->shift;
val &= mux->mask;
 
return clk_mux_val_to_index(clk, mux->table, mux->flags, val);
@@ -108,6 +113,9 @@ struct clk *clk_hw_register_mux_table(struct device *dev, 
const char *name,
mux->mask = mask;
mux->flags = clk_mux_flags;
mux->table = table;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+   mux->io_mux_val = *(u32 *)reg;
+#endif
 
clk = >clk;
 
diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
index 53c9c41b90..43a25e9c6a 100644
--- a/include/linux/clk-provider.h
+++ b/include/linux/clk-provider.h
@@ -59,6 +59,10 @@ struct clk_mux {
 */
const char  * const *parent_names;
u8  num_parents;
+#if CONFIG_IS_ENABLED(SANDBOX_CLK_CCF)
+   u32 io_mux_val;
+#endif
+
 };
 
 #define to_clk_mux(_clk) container_of(_clk, struct clk_mux, clk)
-- 
2.11.0

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

[U-Boot] [PATCH v5 07/18] clk: Introduce clk-provider.h to store Common Clock Framework's internals

This file now stores the dev_get_clk_ptr() wrapper on the dev_get_uclass_priv()
function.

Signed-off-by: Lukasz Majewski 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 include/linux/clk-provider.h | 16 
 1 file changed, 16 insertions(+)
 create mode 100644 include/linux/clk-provider.h

diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
new file mode 100644
index 00..6adf0a5791
--- /dev/null
+++ b/include/linux/clk-provider.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2019 DENX Software Engineering
+ * Lukasz Majewski, DENX Software Engineering, lu...@denx.de
+ *
+ * Copyright (c) 2010-2011 Jeremy Kerr 
+ * Copyright (C) 2011-2012 Linaro Ltd 
+ */
+#ifndef __LINUX_CLK_PROVIDER_H
+#define __LINUX_CLK_PROVIDER_H
+
+static inline struct clk *dev_get_clk_ptr(struct udevice *dev)
+{
+   return (struct clk *)dev_get_uclass_priv(dev);
+}
+#endif /* __LINUX_CLK_PROVIDER_H */
-- 
2.11.0

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

[U-Boot] [PATCH v5 08/18] dm: clk: Define clk_get_parent() for clk operations

This commit adds the clk_get_parent() function, which is responsible
for getting the parent's struct clock pointer.

U-Boot's DM support for getting parent is different (the parent
relationship is in udevice) than the one in Common Clock Framework [CCF]
in Linux. To obtain the pointer to struct clk of parent the
pdev->uclass_priv field is read via dev_get_clk_ptr() wrapper.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Peng Fan 

---

Changes in v6: None
Changes in v5:
- s/U-boot/U-Boot/g
- Replace dev->driver_data with dev_get_clk_ptr() wrapper on uclass_priv

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

 drivers/clk/clk-uclass.c | 16 
 include/clk.h|  9 +
 2 files changed, 25 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 79b3b0494c..4346c61eea 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static inline const struct clk_ops *clk_dev_ops(struct udevice *dev)
 {
@@ -379,6 +380,21 @@ ulong clk_get_rate(struct clk *clk)
return ops->get_rate(clk);
 }
 
+struct clk *clk_get_parent(struct clk *clk)
+{
+   struct udevice *pdev;
+   struct clk *pclk;
+
+   debug("%s(clk=%p)\n", __func__, clk);
+
+   pdev = dev_get_parent(clk->dev);
+   pclk = dev_get_clk_ptr(pdev);
+   if (!pclk)
+   return ERR_PTR(-ENODEV);
+
+   return pclk;
+}
+
 ulong clk_set_rate(struct clk *clk, ulong rate)
 {
const struct clk_ops *ops = clk_dev_ops(clk->dev);
diff --git a/include/clk.h b/include/clk.h
index b10c0013b1..e20641ee98 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -259,6 +259,15 @@ int clk_free(struct clk *clk);
 ulong clk_get_rate(struct clk *clk);
 
 /**
+ * clk_get_parent() - Get current clock's parent.
+ *
+ * @clk:   A clock struct that was previously successfully requested by
+ * clk_request/get_by_*().
+ * @return pointer to parent's struct clk, or error code passed as pointer
+ */
+struct clk *clk_get_parent(struct clk *clk);
+
+/**
  * clk_set_rate() - Set current clock rate.
  *
  * @clk:   A clock struct that was previously successfully requested by
-- 
2.11.0

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

[U-Boot] [PATCH v5 09/18] dm: clk: Define clk_get_parent_rate() for clk operations

This commit adds the clk_get_parent_rate() function, which is responsible
for getting the rate of parent clock.
Unfortunately, u-boot's DM support for getting parent is different
(the parent relationship is in udevice) than the one in Common Clock
Framework [CCF] in Linux.

To alleviate this problem - the clk_get_parent_rate() function has been
introduced to clk-uclass.c.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Peng Fan 

---

Changes in v6: None
Changes in v5:
- Replace ulong with long long (to accommodate large freqs and return
  errors)

Changes in v4: None
Changes in v3:
- The rate information is now cached into struct clk field
- The clk_get_parent() is used to get pointer to the parent struct clk

 drivers/clk/clk-uclass.c | 22 ++
 include/clk.h|  9 +
 2 files changed, 31 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 4346c61eea..899b2dda6f 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -395,6 +395,28 @@ struct clk *clk_get_parent(struct clk *clk)
return pclk;
 }
 
+long long clk_get_parent_rate(struct clk *clk)
+{
+   const struct clk_ops *ops;
+   struct clk *pclk;
+
+   debug("%s(clk=%p)\n", __func__, clk);
+
+   pclk = clk_get_parent(clk);
+   if (IS_ERR(pclk))
+   return -ENODEV;
+
+   ops = clk_dev_ops(pclk->dev);
+   if (!ops->get_rate)
+   return -ENOSYS;
+
+   /* Read the 'rate' if not already set */
+   if (!pclk->rate)
+   pclk->rate = clk_get_rate(pclk);
+
+   return pclk->rate;
+}
+
 ulong clk_set_rate(struct clk *clk, ulong rate)
 {
const struct clk_ops *ops = clk_dev_ops(clk->dev);
diff --git a/include/clk.h b/include/clk.h
index e20641ee98..7b2ff8ebe6 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -268,6 +268,15 @@ ulong clk_get_rate(struct clk *clk);
 struct clk *clk_get_parent(struct clk *clk);
 
 /**
+ * clk_get_parent_rate() - Get parent of current clock rate.
+ *
+ * @clk:   A clock struct that was previously successfully requested by
+ * clk_request/get_by_*().
+ * @return clock rate in Hz, or -ve error code.
+ */
+long long clk_get_parent_rate(struct clk *clk);
+
+/**
  * clk_set_rate() - Set current clock rate.
  *
  * @clk:   A clock struct that was previously successfully requested by
-- 
2.11.0

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

[U-Boot] [PATCH v5 10/18] dm: clk: Define clk_get_by_id() for clk operations

This commit adds the clk_get_by_id() function, which is responsible
for getting the udevice with matching clk->id. Such approach allows
re-usage of inherit DM list relationship for the same class (UCLASS_CLK).
As a result - we don't need any other external list - it is just enough
to look for UCLASS_CLK related udevices.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Peng Fan 

---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- Replace -ENODEV with -ENOENT
- Use **clkp instead of **c
- Replace dev->driver_data with dev_get_clk_ptr() wrapper on uclas_priv

 drivers/clk/clk-uclass.c | 22 ++
 include/clk.h| 11 +++
 2 files changed, 33 insertions(+)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 899b2dda6f..506ba6014c 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -491,6 +491,28 @@ int clk_disable_bulk(struct clk_bulk *bulk)
return 0;
 }
 
+int clk_get_by_id(ulong id, struct clk **clkp)
+{
+   struct udevice *dev;
+   struct uclass *uc;
+   int ret;
+
+   ret = uclass_get(UCLASS_CLK, );
+   if (ret)
+   return ret;
+
+   uclass_foreach_dev(dev, uc) {
+   struct clk *clk = dev_get_clk_ptr(dev);
+
+   if (clk && clk->id == id) {
+   *clkp = clk;
+   return 0;
+   }
+   }
+
+   return -ENOENT;
+}
+
 UCLASS_DRIVER(clk) = {
.id = UCLASS_CLK,
.name   = "clk",
diff --git a/include/clk.h b/include/clk.h
index 7b2ff8ebe6..f8f56d9cf0 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -345,4 +345,15 @@ static inline bool clk_valid(struct clk *clk)
 {
return !!clk->dev;
 }
+
+/**
+ * clk_get_by_id() - Get the clock by its ID
+ *
+ * @id:The clock ID to search for
+ *
+ * @clkp:  A pointer to clock struct that has been found among added clocks
+ *  to UCLASS_CLK
+ * @return zero on success, or -ENOENT on error
+ */
+int clk_get_by_id(ulong id, struct clk **clkp);
 #endif
-- 
2.11.0

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

[U-Boot] [PATCH v5 18/18] clk: Add MAINTAINERS entry for clocks (./drivers/clk/)

The clock subsystem needs active maintenance as it steadily grows.
I do offer my help for this task.

Signed-off-by: Lukasz Majewski 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 MAINTAINERS | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8e26eda2c8..e659491d3c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -443,6 +443,13 @@ T: git git://git.denx.de/u-boot-cfi-flash.git
 F: drivers/mtd/cfi_flash.c
 F: drivers/mtd/jedec_flash.c
 
+CLOCK
+M: Lukasz Majewski 
+S: Maintained
+T: git git://git.denx.de/u-boot-dfu.git
+F: drivers/clk/
+F: drivers/clk/imx/
+
 COLDFIRE
 M: Huan Wang 
 M: Angelo Dureghello 
-- 
2.11.0

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

[U-Boot] [PATCH v5 12/18] dm: clk: Extend clk_get_parent_rate() to support CLK_GET_RATE_NOCACHE flag

If the CLK_GET_RATE_NOCACHE flag is set - the clk_get_parent_rate()
provides recalculated clock value without considering the cache setting.

This may be necessary for some clocks tightly coupled with power domains
(i.e. imx8), and prevents from reading invalid cached values.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Peng Fan 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/clk/clk-uclass.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
index 506ba6014c..5acf186b01 100644
--- a/drivers/clk/clk-uclass.c
+++ b/drivers/clk/clk-uclass.c
@@ -410,8 +410,8 @@ long long clk_get_parent_rate(struct clk *clk)
if (!ops->get_rate)
return -ENOSYS;
 
-   /* Read the 'rate' if not already set */
-   if (!pclk->rate)
+   /* Read the 'rate' if not already set or if proper flag set*/
+   if (!pclk->rate || pclk->flags & CLK_GET_RATE_NOCACHE)
pclk->rate = clk_get_rate(pclk);
 
return pclk->rate;
-- 
2.11.0

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

[U-Boot] [PATCH v5 06/18] clk: Provide struct clk for fixed rate clock (clk_fixed_rate.c)

Up till now the fixed rate clock ('osc') has been added to UCLASS_CLK
without declaring struct clk. As a result it was only accessible by
iterating the udevice's uclass list.

This is a problem for clock code, which operates on pointers to struct
clk (like clk_get_rate()), not udevices.

After this change struct clk is accessible from udevice and udevice from
struct clk.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Peng Fan 

---

Changes in v6:
- Use dev->uclass_priv pointer to store pointer to clk

Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/clk/clk_fixed_rate.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/clk/clk_fixed_rate.c b/drivers/clk/clk_fixed_rate.c
index 50dbb13655..1fdf8c4e54 100644
--- a/drivers/clk/clk_fixed_rate.c
+++ b/drivers/clk/clk_fixed_rate.c
@@ -8,6 +8,7 @@
 #include 
 
 struct clk_fixed_rate {
+   struct clk clk;
unsigned long fixed_rate;
 };
 
@@ -24,10 +25,14 @@ const struct clk_ops clk_fixed_rate_ops = {
 
 static int clk_fixed_rate_ofdata_to_platdata(struct udevice *dev)
 {
+   struct clk *clk = _clk_fixed_rate(dev)->clk;
 #if !CONFIG_IS_ENABLED(OF_PLATDATA)
to_clk_fixed_rate(dev)->fixed_rate =
dev_read_u32_default(dev, "clock-frequency", 0);
 #endif
+   /* Make fixed rate clock accessible from higher level struct clk */
+   dev->uclass_priv = clk;
+   clk->dev = dev;
 
return 0;
 }
-- 
2.11.0

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

[U-Boot] [PATCH v5 05/18] clk: Extend struct clk to provide clock type agnostic flags

This commit extends the struct clk to provide information regarding the
flags related to this devices.

Those flags are clk device agnostic and indicate generic features
(like e.g. CLK_GET_RATE_NOCACHE - the need to always recalculate the rate).

Signed-off-by: Lukasz Majewski 
Reviewed-by: Peng Fan 

---

Changes in v6: None
Changes in v5:
- Use u32 to avoid checkpatch warning

Changes in v4: None
Changes in v3: None

 include/clk.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/include/clk.h b/include/clk.h
index d7b937ca7b..b10c0013b1 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -41,6 +41,9 @@ struct udevice;
  *
  * @dev: The device which implements the clock signal.
  * @rate: The clock rate (in HZ).
+ * @flags: Flags used across common clock structure (e.g. CLK_)
+ * Clock IP blocks specific flags (i.e. mux, div, gate, etc) are 
defined
+ * in struct's for those devices (e.g. struct clk_mux).
  * @id: The clock signal ID within the provider.
  * @data: An optional data field for scenarios where a single integer ID is not
  *   sufficient. If used, it can be populated through an .of_xlate op and
@@ -57,6 +60,7 @@ struct udevice;
 struct clk {
struct udevice *dev;
long long rate; /* in HZ */
+   u32 flags;
/*
 * Written by of_xlate. In the future, we might add more fields here.
 */
-- 
2.11.0

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

[U-Boot] [PATCH v5 03/18] clk: Remove clock ID check in .get_rate() of clk_fixed_*

This check requires the struct clk passed to .get_rate() to be always
cleared out as any clock with valid ID causes -EINVAL return value.

The return code of fixed clocks shall always be returned.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Peng Fan 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

 drivers/clk/clk_fixed_factor.c | 3 ---
 drivers/clk/clk_fixed_rate.c   | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/drivers/clk/clk_fixed_factor.c b/drivers/clk/clk_fixed_factor.c
index 5fa20a84db..dcdb6ddf5c 100644
--- a/drivers/clk/clk_fixed_factor.c
+++ b/drivers/clk/clk_fixed_factor.c
@@ -24,9 +24,6 @@ static ulong clk_fixed_factor_get_rate(struct clk *clk)
uint64_t rate;
struct clk_fixed_factor *ff = to_clk_fixed_factor(clk->dev);
 
-   if (clk->id != 0)
-   return -EINVAL;
-
rate = clk_get_rate(>parent);
if (IS_ERR_VALUE(rate))
return rate;
diff --git a/drivers/clk/clk_fixed_rate.c b/drivers/clk/clk_fixed_rate.c
index d8d9f86c86..50dbb13655 100644
--- a/drivers/clk/clk_fixed_rate.c
+++ b/drivers/clk/clk_fixed_rate.c
@@ -15,9 +15,6 @@ struct clk_fixed_rate {
 
 static ulong clk_fixed_rate_get_rate(struct clk *clk)
 {
-   if (clk->id != 0)
-   return -EINVAL;
-
return to_clk_fixed_rate(clk->dev)->fixed_rate;
 }
 
-- 
2.11.0

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

[U-Boot] [PATCH v5 04/18] clk: Extend struct clk to provide information regarding clock rate

This commit extends the struct clk to provide information regarding the
clock rate.
As a result the clock tree traversal is performed at most once, and further
reads are using the cached value.

Signed-off-by: Lukasz Majewski 

---

Changes in v6: None
Changes in v5:
- Use long long to store rate value (to avoid int overflow and also return
  errors correctly)

Changes in v4: None
Changes in v3: None

 include/clk.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/clk.h b/include/clk.h
index a909b71f1a..d7b937ca7b 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -40,6 +40,7 @@ struct udevice;
  * other clock APIs to identify which clock signal to operate upon.
  *
  * @dev: The device which implements the clock signal.
+ * @rate: The clock rate (in HZ).
  * @id: The clock signal ID within the provider.
  * @data: An optional data field for scenarios where a single integer ID is not
  *   sufficient. If used, it can be populated through an .of_xlate op and
@@ -55,6 +56,7 @@ struct udevice;
  */
 struct clk {
struct udevice *dev;
+   long long rate; /* in HZ */
/*
 * Written by of_xlate. In the future, we might add more fields here.
 */
-- 
2.11.0

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

[U-Boot] [PATCH v5 02/18] dm: Fix documentation entry as there is no UCLASS_CLOCK uclass

There is no UCLASS_CLOCK uclass defined. Instead we do use the UCLASS_CLK.

Signed-off-by: Lukasz Majewski 
Reviewed-by: Simon Glass 
Reviewed-by: Peng Fan 
---

Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3: None

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

diff --git a/include/clk.h b/include/clk.h
index d24e99713a..a909b71f1a 100644
--- a/include/clk.h
+++ b/include/clk.h
@@ -20,7 +20,7 @@
  * clock provider. This API provides a standard means for drivers to enable and
  * disable clocks, and to set the rate at which they oscillate.
  *
- * A driver that implements UCLASS_CLOCK is a clock provider. A provider will
+ * A driver that implements UCLASS_CLK is a clock provider. A provider will
  * often implement multiple separate clocks, since the hardware it manages
  * often has this capability. clk-uclass.h describes the interface which
  * clock providers must implement.
-- 
2.11.0

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

[U-Boot] [PATCH v5 01/18] clk: doc: Add documentation entry for Common Clock Framework [CCF] (i.MX)

This patch describes the design decisions considerations and taken approach
for porting in a separate documentation entry.

Signed-off-by: Lukasz Majewski 

---

Changes in v6: None
Changes in v5:
- s/U-boot/U-Boot/g
- Update Linux version to 5.1.12
- Add paragraph regarding sandbox CCF testing (common uclass code)

Changes in v4:
- New patch

Changes in v3: None

 doc/imx/clk/ccf.txt | 101 
 1 file changed, 101 insertions(+)
 create mode 100644 doc/imx/clk/ccf.txt

diff --git a/doc/imx/clk/ccf.txt b/doc/imx/clk/ccf.txt
new file mode 100644
index 00..36b60dc438
--- /dev/null
+++ b/doc/imx/clk/ccf.txt
@@ -0,0 +1,101 @@
+Introduction:
+=
+
+This documentation entry describes the Common Clock Framework [CCF]
+port from Linux kernel (v5.1.12) to U-Boot.
+
+This code is supposed to bring CCF to IMX based devices (imx6q, imx7
+imx8). Moreover, it also provides some common clock code, which would
+allow easy porting of CCF Linux code to other platforms.
+
+Design decisions:
+=
+
+* U-Boot's driver model [DM] for clk differs from Linux CCF. The most
+  notably difference is the lack of support for hierarchical clocks and
+  "clock as a manager driver" (single clock DTS node acts as a starting
+  point for all other clocks).
+
+* The clk_get_rate() caches the previously read data if CLK_GET_RATE_NOCACHE
+  is not set (no need for recursive access).
+
+* On purpose the "manager" clk driver (clk-imx6q.c) is not using large
+  table to store pointers to clocks - e.g. clk[IMX6QDL_CLK_USDHC2_SEL] = 
+  Instead we use udevice's linked list for the same class (UCLASS_CLK).
+
+  Rationale:
+  --
+When porting the code as is from Linux, one would need ~1KiB of RAM to
+store it. This is way too much if we do plan to use this driver in SPL.
+
+* The "central" structure of this patch series is struct udevice and its
+  uclass_priv field contains the struct clk pointer (to the originally created
+  one).
+
+* Up till now U-Boot's driver model (DM) CLK operates on udevice (main
+  access to clock is by udevice ops)
+  In the CCF the access to struct clk (embodying pointer to *dev) is
+  possible via dev_get_clk_ptr() (it is a wrapper on dev_get_uclass_priv()).
+
+* To keep things simple the struct udevice's uclass_priv pointer is used to
+  store back pointer to corresponding struct clk. However, it is possible to
+  modify clk-uclass.c file and add there struct uc_clk_priv, which would have
+  clock related members (like pointer to clk). As of this writing there is no
+  such need, so to avoid extra allocations (as it can be auto allocated by
+  setting .per_device_auto_alloc_size = sizeof(struct uc_clk_priv)) the
+  uclass_priv stores the pointer to struct clk.
+
+* It is advised to add common clock code (like already added rate and flags) to
+  the struct clk, which is a top level description of the clock.
+
+* U-Boot's driver model already provides the facility to automatically allocate
+  (via private_alloc_size) device private data (accessible via dev->priv).
+  It may look appealing to use this feature to allocate private structures for
+  CCF clk devices e.g. divider (struct clk_divider *divider) for IMX6Q clock.
+
+  The above feature had not been used for following reasons:
+  - The original CCF Linux kernel driver is the "manager" for clocks - it
+decides when clock is instantiated (and when memory for it is allocated).
+
+  - Using it would change the original structure of the CCF code.
+
+  - To bind (via clk_register()) the clock device with U-Boot driver model we
+first need udevice for it (the "chicken and egg problem").
+
+* I've added the clk_get_parent(), which reads parent's dev->uclass_priv to
+  provide parent's struct clk pointer. This seems the easiest way to get
+  child/parent relationship for struct clk in U-Boot's udevice based clocks.
+
+* Linux's CCF 'struct clk_core' corresponds to U-Boot's udevice in 'struct 
clk'.
+  Clock IP block agnostic flags from 'struct clk_core' (e.g. NOCACHE) have been
+  moved from this struct one level up to 'struct clk'.
+
+* For tests the new ./test/dm/clk_ccf.c and ./drivers/clk/clk_sandbox_ccf.c
+  files have been introduced. The latter setups the CCF clock structure for
+  sandbox by reusing, if possible, generic clock primitives - like divier
+  and mux. The former file provides code to tests this setup.
+
+  For sandbox new CONFIG_SANDBOX_CLK_CCF Kconfig define has been introduced.
+  All new primitives added for new architectures must have corresponding test
+  in the two aforementioned files.
+
+
+Testing (sandbox):
+==
+
+make mrproper; make sandbox_defconfig; make -j4
+./u-boot -i -d arch/sandbox/dts/test.dtb
+=> ut dm clk
+
+or in a more "scriptable" way (with -v to print debug output):
+./u-boot --fdt arch/sandbox/dts/test.dtb --command "ut dm clk_ccf" -v
+
+To do:
+--
+
+* Use of OF_PLATDATA in the SPL setup for CCF - as

Re: [U-Boot] [PATCH] net: davinci_emac: convert to using the driver model

On Mon, Jun 24, 2019 at 7:07 AM Bartosz Golaszewski  wrote:
>
> śr., 12 cze 2019 o 18:46 Adam Ford  napisał(a):
> >
> > On Mon, Jun 3, 2019 at 10:29 AM Bartosz Golaszewski  wrote:
> > >
> > > pon., 3 cze 2019 o 15:03 Adam Ford  napisał(a):
> > > >
> > > > On Mon, Jun 3, 2019 at 3:12 AM Bartosz Golaszewski  
> > > > wrote:
> > > > >
> > > > > sob., 1 cze 2019 o 05:24 Adam Ford  napisał(a):
> > > > > >
> > > > > > On Fri, May 31, 2019 at 8:32 AM Bartosz Golaszewski  
> > > > > > wrote:
> > > > > > >
> > > > > > > From: Bartosz Golaszewski 
> > > > > > >
> > > > > > > Now that we removed all legacy boards selecting TI_EMAC we can
> > > > > > > completely convert the driver code to using the driver model.
> > > > > > > This patch also updates all remaining users of davinci_emac.
> > > > > > >
> > > > > >
> > > > > > I took a break from this to come back, and I'm going to give some
> > > > > > feedback about how the driver was written. I still do not know why I
> > > > > > cannot get an IP address with this patch on the AM3517-evm.
> > > > > >
> > > > >
> > > > > Hi Adam,
> > > > >
> > > > > thanks for all the testing. Unfortunately I can only test with
> > > > > da850-evm and da850-lcdk.
> > > > >
> > > > > I was wondering if it is possible that the problem is caused by
> > > > > cpu_eth_init() from ./arch/arm/mach-omap2/omap3/emac. not being called
> > > > > with CONFIG_DM_ETH? The comments say that it brings the module out of
> > > > > reset, so maybe this is what causes the problem you're seeing?
> > > >
> > > > I looked into that nearly right away, but there is a chunk of code in
> > > > board/logicpd/am3517evm/am3517evm.c which has a function called
> > > > misc_init_r() which does the same thing. Looking through the debug
> > > > data, it appears as if the drive is communicating for a bit, but at
> > > > some point it dies.  I'm not going to be able to look at it for a few
> > > > days.  Is there any way you can submit a V2 to use #ifdef's to allow
> > > > users to use the same driver with and without DM_ETH?  That would give
> > > > the da850/L138 boards the DM_ETH, and give me some time to
> > > > troubleshoot the am3517-evm. I know Sekhar works for TI and the AM3517
> > > > was the official development kit for TI back in the day.  If TI has
> > > > some ideas, I'm open to trying them as well when I can get back to it.
> > > >
> > > > adam
> > >
> > > Hi Adam,
> > >
> > > I'm trying to find out if I can get my hands on one of these boards 
> > > somehow.
> > >
> > > My priority for this week is the nand driver conversion. I'll also be
> > > off next week and the one after. I think that since we already removed
> > > a bunch of boards to make it possible to avoid the ifdef hell, it's
> > > better to wait a bit more than to merge something that we'll remove
> > > soon anyway.
> > >
> > > If Sekhar agrees, we can push back merging of this patch until it's fixed.
> > >
> > > There's also a big backlog of my other davinci patches on the list
> > > anyway, maybe they'll get picked up before we get back to it.
> > >
> > > Bart
> > >
> > > >
> > > > >
> > > > > > > Signed-off-by: Bartosz Golaszewski 
> > > > > > > ---
> > > > > > >  arch/arm/mach-davinci/cpu.c| 13 -
> > > > > > >  arch/arm/mach-omap2/omap3/emac.c   |  3 +-
> > > > > > >  board/davinci/da8xxevm/da850evm.c  |  6 --
> > > > > > >  board/davinci/da8xxevm/omapl138_lcdk.c | 14 -
> > > > > > >  board/logicpd/am3517evm/am3517evm.c|  1 -
> > > > > > >  board/ti/ti816x/evm.c  |  3 +-
> > > > > > >  configs/am3517_evm_defconfig   |  1 +
> > > > > > >  configs/da850evm_defconfig |  1 +
> > > > > > >  configs/da850evm_direct_nor_defconfig  |  1 +
> > > > > > >  configs/da850evm_nand_defconfig|  1 +
> > > > > > >  configs/omapl138_lcdk_defconfig|  1 +
> > > > > > >  configs/ti816x_evm_defconfig   |  1 +
> > > > > > >  drivers/net/ti/davinci_emac.c  | 77 
> > > > > > > ++
> > > > > > >  include/netdev.h   |  1 -
> > > > > > >  14 files changed, 51 insertions(+), 73 deletions(-)
> > > > > > >
> > > > > > > diff --git a/arch/arm/mach-davinci/cpu.c 
> > > > > > > b/arch/arm/mach-davinci/cpu.c
> > > > > > > index f97ad3fc74..9fd6564d04 100644
> > > > > > > --- a/arch/arm/mach-davinci/cpu.c
> > > > > > > +++ b/arch/arm/mach-davinci/cpu.c
> > > > > > > @@ -5,7 +5,6 @@
> > > > > > >   */
> > > > > > >
> > > > > > >  #include 
> > > > > > > -#include 
> > > > > > >  #include 
> > > > > > >  #include 
> > > > > > >
> > > > > > > @@ -90,15 +89,3 @@ int set_cpu_clk_info(void)
> > > > > > > gd->bd->bi_dsp_freq = 0;
> > > > > > > return 0;
> > > > > > >  }
> > > > > > > -
> > > > > > > -/*
> > > > > > > - * Initializes on-chip ethernet controllers.
> > > > > > > - * to override, implement board_eth_init()
> > > > > > > - */
> > > > > > > -int cpu_eth_init(bd_t *bis)
> > > > > > > -{
> > > > > > > -#if

Re: [U-Boot] [PATCH v7 9/9] net: macb: Fix check for little-endian system in gmac_configure_dma()


On 6/24/19 4:12 PM, Bin Meng wrote:
> Hi Ramon,
>
> On Mon, Jun 24, 2019 at 8:51 PM Ramon Fried  wrote:
>>
>> On 6/24/19 3:32 PM, Bin Meng wrote:
>>> Hi Ramon,
>>>
>>> On Mon, Jun 24, 2019 at 8:22 PM Ramon Fried  wrote:
 On 6/24/19 8:03 AM, Bin Meng wrote:

 On Mon, Jun 24, 2019 at 12:03 PM Anup Patel  wrote:

 We should depend on __LITTLE_ENDIAN pre-defined compiler macro for
 little-endian system instead of U-Boot specific CONFIG_SYS_LITTLE_ENDIAN
 macro.

 Signed-off-by: Anup Patel 
 ---
  drivers/net/macb.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

 Reviewed-by: Bin Meng 

 Hi.
 I don't like this approach, each platform should configure it's
 endianess, this is stated in README in root folder.
 relying on a specific GCC preprocessor extension is limiting us only to 
 use GCC.
 The RISCV issue with MACB can be easily resolved by defining the
 CONFIG_SYS_LITTLE_ENDIAN config.
>>> OK, but a system wide CONFIG_SYS_LITTLE_ENDIAN may bring side effects
>>> to other drivers, as not all devices are using the same endianness
>>> even in the same system. Maybe we can do something by parsing some
>>> property in device tree?
>>>
>>> Regards,
>>> Bin
>> Hey Bin
>>
>> I grep'ed for all instances of CONFIG_SYS_LITTLE_ENDIAN and I don't see any 
>> place
>> where something might brake. can you elaborate ?
> I mean this system wide CONFIG_SYS_LITTLE_ENDIAN is easy to break
> since it cannot represent all devices, although I did not check all
> instances currently in U-Boot. Maybe it's OK for now for the SiFive
> board. But this option is not better than the pure compiler flag
> either. So I was proposing using some properties in DT. Does that
> help?

Not all devices work using DT in macb, so it won't work for them. :(

Thanks,

Ramon.


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

Re: [U-Boot] [PATCH v7 9/9] net: macb: Fix check for little-endian system in gmac_configure_dma()

2019-06-24 Thread Bin Meng

Hi Ramon,

On Mon, Jun 24, 2019 at 8:51 PM Ramon Fried  wrote:
>
>
> On 6/24/19 3:32 PM, Bin Meng wrote:
> > Hi Ramon,
> >
> > On Mon, Jun 24, 2019 at 8:22 PM Ramon Fried  wrote:
> >>
> >> On 6/24/19 8:03 AM, Bin Meng wrote:
> >>
> >> On Mon, Jun 24, 2019 at 12:03 PM Anup Patel  wrote:
> >>
> >> We should depend on __LITTLE_ENDIAN pre-defined compiler macro for
> >> little-endian system instead of U-Boot specific CONFIG_SYS_LITTLE_ENDIAN
> >> macro.
> >>
> >> Signed-off-by: Anup Patel 
> >> ---
> >>  drivers/net/macb.c | 7 ---
> >>  1 file changed, 4 insertions(+), 3 deletions(-)
> >>
> >> Reviewed-by: Bin Meng 
> >>
> >> Hi.
> >> I don't like this approach, each platform should configure it's
> >> endianess, this is stated in README in root folder.
> >> relying on a specific GCC preprocessor extension is limiting us only to 
> >> use GCC.
> >> The RISCV issue with MACB can be easily resolved by defining the
> >> CONFIG_SYS_LITTLE_ENDIAN config.
> > OK, but a system wide CONFIG_SYS_LITTLE_ENDIAN may bring side effects
> > to other drivers, as not all devices are using the same endianness
> > even in the same system. Maybe we can do something by parsing some
> > property in device tree?
> >
> > Regards,
> > Bin
>
> Hey Bin
>
> I grep'ed for all instances of CONFIG_SYS_LITTLE_ENDIAN and I don't see any 
> place
> where something might brake. can you elaborate ?

I mean this system wide CONFIG_SYS_LITTLE_ENDIAN is easy to break
since it cannot represent all devices, although I did not check all
instances currently in U-Boot. Maybe it's OK for now for the SiFive
board. But this option is not better than the pure compiler flag
either. So I was proposing using some properties in DT. Does that
help?

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

Re: [U-Boot] [PATCH] usb: ehci-mx6: Fix bus enumeration for DM case

Hi Marek,

> On 6/24/19 1:57 PM, Lukasz Majewski wrote:
> > Hi Marek,
> >   
> >> On 6/24/19 12:26 PM, Lukasz Majewski wrote:  
> >>> On Mon, 24 Jun 2019 12:06:28 +0200
> >>> Marek Vasut  wrote:
> >>> 
>  On 6/24/19 8:33 AM, Peng Fan wrote:
> > Hi Marek,
> >   
> >> Subject: Re: [PATCH] usb: ehci-mx6: Fix bus enumeration for DM
> >> case
> >>
> >> On 6/21/19 3:45 AM, Peng Fan wrote:  
> >>> Hi Marek,
> >>>  
>  -Original Message-
>  From: Marek Vasut [mailto:ma...@denx.de]
>  Sent: 2019年6月21日 4:54
>  To: u-boot@lists.denx.de
>  Cc: Marek Vasut ; Abel Vesa
>  ;  
> >> Adam  
>  Ford ; Fabio Estevam
>  ;  
> >> Ludwig  
>  Zenz ; Peng Fan
>  ;  
> >> Stefano  
>  Babic ; Vagrant Cascadian
>   Subject: [PATCH] usb: ehci-mx6: Fix bus
>  enumeration for DM case
> 
>  It is likely that the DM conversion of EHCI iMX6 driver was a
>  derivative of EHCI VF, however the conversion is incomplete
>  and is missing the bind workaround, which updates dev->seq
>  number. Without this, all controllers have dev->seq number
>  0 . Add this bind workaround  
> >> into EHCI iMX6 driver as well.  
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Abel Vesa 
>  Cc: Adam Ford 
>  Cc: Fabio Estevam 
>  Cc: Ludwig Zenz 
>  Cc: Peng Fan 
>  Cc: Stefano Babic 
>  Cc: Vagrant Cascadian 
>  ---
>   drivers/usb/host/ehci-mx6.c | 17 +
>   1 file changed, 17 insertions(+)
> 
>  diff --git a/drivers/usb/host/ehci-mx6.c
>  b/drivers/usb/host/ehci-mx6.c index 33abfeada0..109ed7ed4a
>  100644 --- a/drivers/usb/host/ehci-mx6.c
>  +++ b/drivers/usb/host/ehci-mx6.c
>  @@ -503,6 +503,22 @@ static int
>  ehci_usb_ofdata_to_platdata(struct udevice *dev)
>   return 0;
>   }
> 
>  +static int ehci_usb_bind(struct udevice *dev) {
>  +static int num_controllers;
>  +
>  +/*
>  + * Without this hack, if we return ENODEV for USB
>  Controller 0, on
>  + * probe for the next controller, USB Controller 1
>  will be given a
>  + * sequence number of 0. This conflicts with our
>  requirement of
>  + * sequence numbers while initialising the
>  peripherals.
>  + */
>  +dev->req_seq = num_controllers;  
> >>>
> >>> With alias in dts, no need this, right?  
> >>
> >> There are no aliases in the DTs for the USB controllers, so
> >> that doesn't help. I think for DM, the real solution would be
> >> to parse the PHY phandle and pass around the PHY address
> >> instead of some arbitrary index, but that's something to be
> >> done for next release. For this release, it's only fixes.  
> >
> > I think the better method is use alias in dts, introducing
> > xx-u-boot.dtsi for such case.  
> 
>  What good would that make if you can obtain the PHY address from
>  the DT, without the need for arbitrary error-prone indexes? The
>  indexes are remnants from when there was no DM or from the DM
>  conversion, so we should remove them altogether.
> 
> >> Would you be interested in implementing the later for
> >> -next ? ;-)  
> >
> > In NXP vendor tree, we have ehci_usb_get_phy to parse phy from
> > dtb, I could find some time send that to community.  
>  What about implementing a proper USB PHY driver, which binds to a
>  DT entry, and then hooking it up to the EHCI MX6 ? IIRC the
>  infrastructure for this is already in place and that would be the
>  right (TM) solution.
> 
> >>>
> >>> Sorry, but I'm a bit confused.
> >>>
> >>> The patch that you introduced above, in the commit message, states
> >>> clearly that it is a hack.
> >>>
> >>> Why shall we allow introducing hacks instead of implementing it in
> >>> the "right way" from the outset ?
> >>
> >> Because we're in RC4 right now and this is the simplest possible
> >> fix which works and is consistent with the other NXP EHCI drivers.
> >> See the
> >> commit message -- this fills in the missing bit which ehci-vf has,
> >> but which was omitted from ehci-mx6 and ehci-mx5 during the
> >> conversion. 
> > 
> > Apparently I was not causing the error which you have encountered.
> >   
> >> The PHY driver and the migration to that infrastructure can be
> >> done in the next cycle, but right now there's no time to develop a
> >> driver and thoroughly test either the PHY driver or the changes to
> >> the EHCI driver, no way.
> >>  
> >>> As you mentioned the infrastructure is already in place, so why
>

Re: [U-Boot] [PATCH v7 9/9] net: macb: Fix check for little-endian system in gmac_configure_dma()