Re: [U-Boot] [PATCH v3 04/11] spi: cadence_qspi: Use #define for bits instead of bit shifts

[Phil Edworthy]

Hi Jagan,

On 30 November 2016 04:59, Jagan Teki wrote:
> On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
>  wrote:
> > Most of the code already uses #defines for the bit value, rather
> > than the shift required to get the value. This changes the remaining
> > code over.
> >
> > Whislt at it, fix the names of the "Rd Data Capture" register defs.
> >
> > Signed-off-by: Phil Edworthy 
> > Acked-by: Marek Vasut 
> > ---
> >  v3:
> >  - Remove brackets that aren't needed.
> >  v2:
> >  - No change.
> > ---
> >  drivers/spi/cadence_qspi_apb.c | 37 +++--
> >  1 file changed, 19 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> > index 0a2963d..b41f36b 100644
> > --- a/drivers/spi/cadence_qspi_apb.c
> > +++ b/drivers/spi/cadence_qspi_apb.c
> > @@ -57,9 +57,9 @@
> >   * Controller's configuration and status register (offset from QSPI_BASE)
> >
> **
> **/
> >  #defineCQSPI_REG_CONFIG0x00
> > -#defineCQSPI_REG_CONFIG_CLK_POL_LSB1
> > -#defineCQSPI_REG_CONFIG_CLK_PHA_LSB2
> >  #defineCQSPI_REG_CONFIG_ENABLE_MASKBIT(0)
> > +#defineCQSPI_REG_CONFIG_CLK_POLBIT(1)
> > +#defineCQSPI_REG_CONFIG_CLK_PHABIT(2)
> >  #defineCQSPI_REG_CONFIG_DIRECT_MASKBIT(7)
> >  #defineCQSPI_REG_CONFIG_DECODE_MASKBIT(9)
> >  #defineCQSPI_REG_CONFIG_XIP_IMM_MASK   BIT(18)
> > @@ -94,10 +94,10 @@
> >  #defineCQSPI_REG_DELAY_TSD2D_MASK  0xFF
> >  #defineCQSPI_REG_DELAY_TSHSL_MASK  0xFF
> >
> > -#defineCQSPI_READLCAPTURE  0x10
> > -#defineCQSPI_READLCAPTURE_BYPASS_LSB   0
> > -#defineCQSPI_READLCAPTURE_DELAY_LSB1
> > -#defineCQSPI_READLCAPTURE_DELAY_MASK   0xF
> > +#defineCQSPI_REG_RD_DATA_CAPTURE   0x10
> > +#defineCQSPI_REG_RD_DATA_CAPTURE_BYPASSBIT(0)
> > +#defineCQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB 1
> > +#defineCQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK0xF
> >
> >  #defineCQSPI_REG_SIZE  0x14
> >  #defineCQSPI_REG_SIZE_ADDRESS_LSB  0
> > @@ -244,20 +244,20 @@ void cadence_qspi_apb_readdata_capture(void
> *reg_base,
> > unsigned int reg;
> > cadence_qspi_apb_controller_disable(reg_base);
> >
> > -   reg = readl(reg_base + CQSPI_READLCAPTURE);
> > +   reg = readl(reg_base + CQSPI_REG_RD_DATA_CAPTURE);
> >
> > if (bypass)
> > -   reg |= (1 << CQSPI_READLCAPTURE_BYPASS_LSB);
> > +   reg |= CQSPI_REG_RD_DATA_CAPTURE_BYPASS;
> > else
> > -   reg &= ~(1 << CQSPI_READLCAPTURE_BYPASS_LSB);
> > +   reg &= ~CQSPI_REG_RD_DATA_CAPTURE_BYPASS;
> >
> > -   reg &= ~(CQSPI_READLCAPTURE_DELAY_MASK
> > -   << CQSPI_READLCAPTURE_DELAY_LSB);
> > +   reg &= ~(CQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK
> > +   << CQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB);
> >
> > -   reg |= ((delay & CQSPI_READLCAPTURE_DELAY_MASK)
> > -   << CQSPI_READLCAPTURE_DELAY_LSB);
> > +   reg |= (delay & CQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK)
> > +   << CQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB;
> >
> > -   writel(reg, reg_base + CQSPI_READLCAPTURE);
> > +   writel(reg, reg_base + CQSPI_REG_RD_DATA_CAPTURE);
> >
> > cadence_qspi_apb_controller_enable(reg_base);
> > return;
> > @@ -301,11 +301,12 @@ void cadence_qspi_apb_set_clk_mode(void
> *reg_base,
> >
> > cadence_qspi_apb_controller_disable(reg_base);
> > reg = readl(reg_base + CQSPI_REG_CONFIG);
> > -   reg &= ~(1 << CQSPI_REG_CONFIG_CLK_POL_LSB);
> > -   reg &= ~(1 << CQSPI_REG_CONFIG_CLK_PHA_LSB);
> > +   reg &= ~(CQSPI_REG_CONFIG_CLK_POL |
> CQSPI_REG_CONFIG_CLK_PHA);
> >
> > -   reg |= ((clk_pol & 0x1) << CQSPI_REG_CONFIG_CLK_POL_LSB);
> > -   reg |= ((clk_pha & 0x1) << CQSPI_REG_CONFIG_CLK_PHA_LSB);
> > +   if (clk_pol)
> > +   reg |= CQSPI_REG_CONFIG_CLK_POL;
> > +   if (clk_pha)
> > +   reg |= CQSPI_REG_CONFIG_CLK_PHA;
> 
> I've commented about this change [1]?
> 
> [1] https://www.mail-archive.com/u-boot@lists.denx.de/msg232120.html
Yes, I fixed that in a separate patch, see
https://www.mail-archive.com/u-boot@lists.denx.de/msg232489.html

I did it in a separate patch because this patch is purely about replacing the
definitions of bit shifts with BIT(x).

> thanks!
> --
> Jagan Teki
> Free Software Engineer | www.openedev.com
> U-Boot, Linux | Upstream Maintainer
> Hyderabad, India.

Thanks
Phil
___

Re: [U-Boot] [PATCH] armv8: QSPI: Add AHB bus 16MB+ size support

[Mike Looijmans]

On 14-11-16 18:46, york sun wrote:

On 11/07/2016 10:03 PM, Yao Yuan wrote:

On 11/08/2016 02:27 AM, York Sun wrote:

On 10/25/2016 07:10 PM, Yuan Yao wrote:

From: Yuan Yao 

The default configuration for QSPI AHB bus can't support 16MB+.
But some flash on NXP layerscape board are more than 16MB.


So what do you do?

Is this an erratum workaround? If yes, please refer the erratum number.


Hi York,

I think It's not an erratum maybe it's better to call it new feature.

As a default configuration for QSPI AHB, the address size is 3-bytes.
It has a good compatibility for QSPI boot for different SPI-NOR flash.

But if the address size is only 3-bytes, the QSPI can't access to the data that 
more than 16M+.

So we can update the default configuration for QSPI AHB in uboot to use 4-bytes 
address.
So that QSPI can access to 16M+ size by AHB bus.


Let me try to understand this. With your change, 4-byte addressing is
supported. Do all flash chips support 4-byte addressing?


Nope.

And an extra word of warning: Not all QSPI host controllers support 4 byte 
addressing, so BOTH the chip and the controller must have that capability.


Note that the 3-byte address can be combined with a page-select register, 
effectively making the whole 4GB address space available.




Thanks.




Signed-off-by: Yuan Yao 
---
 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 37

++

 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
.../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
 include/configs/ls1012a_common.h   |  1 +
 include/configs/ls1046ardb.h   |  1 +
 5 files changed, 41 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index d68eeba..18d753e 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -370,6 +370,40 @@ void fsl_lsch2_early_init_f(void)  }  #endif

+#ifdef CONFIG_QSPI_AHB_INIT
+/* Enable 4bytes address support and fast read */ int
+qspi_ahb_init(void) {
+   u32 *qspi_lut, lut_key, *qspi_key;
+
+   qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
+   qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
+
+   lut_key = in_be32(qspi_key);
+
+   if (lut_key == 0x5af05af0) {
+   /* That means the register is BE */
+   out_be32(qspi_key, 0x5af05af0);
+   out_be32(qspi_key + 1, 0x0002);
+   out_be32(qspi_lut, 0x0820040c);
+   out_be32(qspi_lut + 1, 0x1c080c08);
+   out_be32(qspi_lut + 2, 0x2400);
+   out_be32(qspi_key, 0x5af05af0);
+   out_be32(qspi_key + 1, 0x0001);
+   } else {
+   /* That means the register is LE */
+   out_le32(qspi_key, 0x5af05af0);
+   out_le32(qspi_key + 1, 0x0002);
+   out_le32(qspi_lut, 0x0820040c);
+   out_le32(qspi_lut + 1, 0x1c080c08);
+   out_le32(qspi_lut + 2, 0x2400);
+   out_le32(qspi_key, 0x5af05af0);
+   out_le32(qspi_key + 1, 0x0001);
+   }


What do these sequences do?


It used to set the AHB bus to use 4-bytes command and the corresponding 
sequence.
So that QSPI can access to 16M+ size by AHB bus.



Put a blank line before return.


You need a blank line here.




+   return 0;
+}
+#endif
+
 #ifdef CONFIG_BOARD_LATE_INIT
 int board_late_init(void)
 {
@@ -379,6 +413,9 @@ int board_late_init(void)  #ifdef
CONFIG_CHAIN_OF_TRUST
fsl_setenv_chain_of_trust();
 #endif
+#ifdef CONFIG_QSPI_AHB_INIT
+   qspi_ahb_init();
+#endif

return 0;
 }
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index d88543d..a28b1fd 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -18,6 +18,7 @@
 #define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR +

0x0018)

 #define CONFIG_SYS_GIC400_ADDR (CONFIG_SYS_IMMR +

0x0040)

 #define CONFIG_SYS_IFC_ADDR(CONFIG_SYS_IMMR +

0x0053)

+#define CONFIG_SYS_QSPI_ADDR   (CONFIG_SYS_IMMR +

0x0055)

 #define CONFIG_SYS_FSL_ESDHC_ADDR  (CONFIG_SYS_IMMR +

0x0056)

 #define CONFIG_SYS_FSL_CSU_ADDR

(CONFIG_SYS_IMMR + 0x0051)

 #define CONFIG_SYS_FSL_GUTS_ADDR   (CONFIG_SYS_IMMR +

0x00ee)

diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 7acba27..8aefc76 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -19,6 +19,7 @@
 #define CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR   (CONFIG_SYS_IMMR +

0x0030)

 #define CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR   

[U-Boot] [PATCH v2] dm: core: Add dev_get_addr_size_index() to retrieve addr and size

[Stefan Roese]

The currently available functions accessing the 'reg' property of a
device only retrieve the address. Sometimes its also necessary to
retrieve the size described by the 'reg' property. This patch adds
the new function dev_get_addr_size_index() which retrieves both,
the address and the size described by the 'reg' property.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
v2:
- Account 'index' in fdtdec_get_addr_size_auto_noparent() as
  spotted by Simon

 drivers/core/device.c | 22 ++
 include/dm/device.h   | 16 
 2 files changed, 38 insertions(+)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index dcf5d9df7d..ed553d70a6 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -693,6 +693,28 @@ fdt_addr_t dev_get_addr_index(struct udevice *dev, int 
index)
 #endif
 }
 
+fdt_addr_t dev_get_addr_size_index(struct udevice *dev, int index,
+  fdt_size_t *size)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+   /*
+* Only get the size in this first call. We'll get the addr in the
+* next call to the exisiting dev_get_xxx function which handles
+* all config options.
+*/
+   fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, dev->of_offset,
+  "reg", index, size, false);
+
+   /*
+* Get the base address via the existing function which handles
+* all Kconfig cases
+*/
+   return dev_get_addr_index(dev, index);
+#else
+   return FDT_ADDR_T_NONE;
+#endif
+}
+
 fdt_addr_t dev_get_addr_name(struct udevice *dev, const char *name)
 {
 #if CONFIG_IS_ENABLED(OF_CONTROL)
diff --git a/include/dm/device.h b/include/dm/device.h
index babf8ac8f0..9948bd49fa 100644
--- a/include/dm/device.h
+++ b/include/dm/device.h
@@ -497,6 +497,22 @@ void *dev_map_physmem(struct udevice *dev, unsigned long 
size);
 fdt_addr_t dev_get_addr_index(struct udevice *dev, int index);
 
 /**
+ * dev_get_addr_size_index() - Get the indexed reg property of a device
+ *
+ * Returns the address and size specified in the 'reg' property of a device.
+ *
+ * @dev: Pointer to a device
+ * @index: the 'reg' property can hold a list of  pairs
+ *and @index is used to select which one is required
+ * @size: Pointer to size varible - this function returns the size
+ *specified in the 'reg' property here
+ *
+ * @return addr
+ */
+fdt_addr_t dev_get_addr_size_index(struct udevice *dev, int index,
+  fdt_size_t *size);
+
+/**
  * dev_get_addr_name() - Get the reg property of a device, indexed by name
  *
  * @dev: Pointer to a device
-- 
2.11.0

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

Re: [U-Boot] [PATCH] dm: core: Add dev_get_addr_size_index() to retrieve addr and size

[Stefan Roese]

Hi Simon,

On 30.11.2016 03:35, Simon Glass wrote:

On 28 November 2016 at 02:46, Stefan Roese  wrote:

The currently available functions accessing the 'reg' property of a
device only retrieve the address. Sometimes its also necessary to
retrieve the size described by the 'reg' property. This patch adds
the new function dev_get_addr_size_index() which retrieves both,
the address and the size described by the 'reg' property.

Signed-off-by: Stefan Roese 
Cc: Simon Glass 
---
 drivers/core/device.c | 22 ++
 include/dm/device.h   | 16 
 2 files changed, 38 insertions(+)

diff --git a/drivers/core/device.c b/drivers/core/device.c
index dcf5d9d..ec43654 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -693,6 +693,28 @@ fdt_addr_t dev_get_addr_index(struct udevice *dev, int 
index)
 #endif
 }

+fdt_addr_t dev_get_addr_size_index(struct udevice *dev, int index,
+  fdt_size_t *size)
+{
+#if CONFIG_IS_ENABLED(OF_CONTROL)
+   /*
+* Only get the size in this first call. We'll get the addr in the
+* next call to the exisiting dev_get_xxx function which handles
+* all config options.
+*/
+   fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, dev->of_offset,
+  "reg", 1, size, false);


Does this take account of 'index'?


No, copy and paste error. Thanks for spotting. v2 will follow soon.

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

Re: [U-Boot] [PATCH resend v3 6/6] drivers: usb: gadget: ether/rndis: convert driver to adopt device driver model

[Mugunthan V N]

On Wednesday 30 November 2016 05:24 AM, Joe Hershberger wrote:
> On Thu, Nov 17, 2016 at 11:39 PM, Mugunthan V N  wrote:
>> Adopt usb ether gadget and rndis driver to adopt driver model
>>
>> Signed-off-by: Mugunthan V N 
>> ---
>>  drivers/usb/gadget/Kconfig |   4 ++
>>  drivers/usb/gadget/ether.c | 153 
>> ++---
>>  drivers/usb/gadget/rndis.c |  13 +++-
>>  drivers/usb/gadget/rndis.h |  19 --
>>  include/net.h  |   7 +++
>>  5 files changed, 181 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
>> index 40839d89e9..261ed128ac 100644
>> --- a/drivers/usb/gadget/Kconfig
>> +++ b/drivers/usb/gadget/Kconfig
>> @@ -112,6 +112,10 @@ config G_DNL_VENDOR_NUM
>>  config G_DNL_PRODUCT_NUM
>> hex "Product ID of USB device"
>>
>> +config USBNET_DEVADDR
>> +   string "USB Gadget Ethernet device mac address"
>> +   default "de:ad:be:ef:00:01"
> 
> Please don't do this. We don't have "default" MAC addresses. They are
> either from the env, from ROM, or randomly generated.
> 

Okay will remove this and use either env MAC or random MAC.

>> +
>>  endif # USB_GADGET_DOWNLOAD
>>
>>  endif # USB_GADGET
>> diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
>> index 046ad8ca2b..8c3c3fd9ab 100644
>> --- a/drivers/usb/gadget/ether.c
>> +++ b/drivers/usb/gadget/ether.c
>> @@ -25,6 +25,7 @@
>>  #include "rndis.h"
>>
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -116,7 +117,11 @@ struct eth_dev {
>>
>> struct usb_request  *tx_req, *rx_req;
>>
>> +#ifndef CONFIG_DM_ETH
> 
> Please use positive logic.

Okay, will fix in next version.

> 
>> struct eth_device   *net;
>> +#else
>> +   struct udevice  *net;
>> +#endif
>> struct net_device_stats stats;
>> unsigned inttx_qlen;
>>
>> @@ -143,7 +148,11 @@ struct eth_dev {
>>  
>> /*-*/
>>  struct ether_priv {
>> struct eth_dev ethdev;
>> +#ifndef CONFIG_DM_ETH
> 
> Please use positive logic
> 
>> struct eth_device netdev;
>> +#else
>> +   struct udevice *netdev;
> 
> Did you really intend to have a pointer here when the other is an
> inline structure?

Yes, udevice is the device allocated by probe and passed in probe, but
in non-dm case netdev has to be allocated by driver, in this case it
declared as inline structure.

> 
>> +#endif
>> struct usb_gadget_driver eth_driver;
>>  };
>>
>> @@ -1851,7 +1860,11 @@ static void rndis_control_ack_complete(struct usb_ep 
>> *ep,
>>
>>  static char rndis_resp_buf[8] __attribute__((aligned(sizeof(__le32;
>>
>> +#ifndef CONFIG_DM_ETH
> 
> Please use positive logic.
> 
>>  static int rndis_control_ack(struct eth_device *net)
>> +#else
>> +static int rndis_control_ack(struct udevice *net)
>> +#endif
>>  {
>> struct ether_priv   *priv = (struct ether_priv *)net->priv;
>> struct eth_dev  *dev = >ethdev;
>> @@ -2001,6 +2014,9 @@ static int eth_bind(struct usb_gadget *gadget)
>> int status = -ENOMEM;
>> int gcnum;
>> u8  tmp[7];
>> +#ifdef CONFIG_DM_ETH
>> +   struct eth_pdata*pdata = dev_get_platdata(l_priv->netdev);
>> +#endif
>>
>> /* these flags are only ever cleared; compiler take note */
>>  #ifndefCONFIG_USB_ETH_CDC
>> @@ -2188,7 +2204,11 @@ autoconf_fail:
>>
>>
>> /* network device setup */
>> +#ifndef CONFIG_DM_ETH
>> dev->net = _priv->netdev;
> 
> You wouldn't need this difference if the priv also used a ptr in the
> non-dm case.
> 
> Also, if you are opposed to cleaning this up (preferably by adding a
> preceding patch to make it a pointer), at least use positive logic
> (#ifdef CONFIG_DM_ETH). Same applies elsewhere.

Okay, will add a patch to convert netdev to pointer

> 
>> +#else
>> +   dev->net = l_priv->netdev;
>> +#endif
>>
>> dev->cdc = cdc;
>> dev->zlp = zlp;
>> @@ -2197,6 +2217,7 @@ autoconf_fail:
>> dev->out_ep = out_ep;
>> dev->status_ep = status_ep;
>>
>> +   memset(tmp, 0, sizeof(tmp));
>> /*
>>  * Module params for these addresses should come from ID proms.
>>  * The host side address is used with CDC and RNDIS, and commonly
>> @@ -2204,10 +2225,13 @@ autoconf_fail:
>>  * host side code for the SAFE thing cares -- its original BLAN
>>  * thing didn't, Sharp never assigned those addresses on Zaurii.
>>  */
>> +#ifndef CONFIG_DM_ETH
>> get_ether_addr(dev_addr, dev->net->enetaddr);
>> -
>> -   memset(tmp, 0, sizeof(tmp));
>> memcpy(tmp, dev->net->enetaddr, sizeof(dev->net->enetaddr));
>> +#else
>> +   get_ether_addr(dev_addr, pdata->enetaddr);
>> +   memcpy(tmp, pdata->enetaddr, 

Re: [U-Boot] [PATCH v3 1/6] drivers: usb: gadget: ether: adopt to usb driver model

[Mugunthan V N]

On Wednesday 30 November 2016 04:43 AM, Joe Hershberger wrote:
> On Sun, Nov 27, 2016 at 11:02 AM, Simon Glass  wrote:
>> Hi Mugunthan,
>>
>> On 24 November 2016 at 01:11, Mugunthan V N  wrote:
>>> Hi Simon
>>>
>>> On Thursday 24 November 2016 07:51 AM, Simon Glass wrote:
 Hi Mugunthan,

 On 20 November 2016 at 22:38, Mugunthan V N  wrote:
> Hi Simon,
>
> On Saturday 19 November 2016 01:04 AM, Simon Glass wrote:
>> Hi Mugunthan,
>>
>> On 17 November 2016 at 01:09, Mugunthan V N  wrote:
>>> Convert usb ether gadget to adopt usb driver model
>>>
>>> Signed-off-by: Mugunthan V N 
>>> Reviewed-by: Simon Glass 
>>
>> Sorry, but I'd like to 'un-review' this.
>>
>>> ---
>>>  drivers/usb/gadget/ether.c | 36 
>>>  1 file changed, 36 insertions(+)
>>>
>>> diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
>>> index 497b981129..9bc61186cf 100644
>>> --- a/drivers/usb/gadget/ether.c
>>> +++ b/drivers/usb/gadget/ether.c
>>> @@ -24,6 +24,10 @@
>>>  #include "gadget_chips.h"
>>>  #include "rndis.h"
>>>
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>>  #define USB_NET_NAME "usb_ether"
>>>
>>>  #define atomic_read
>>> @@ -101,6 +105,9 @@ struct eth_dev {
>>> struct usb_gadget   *gadget;
>>> struct usb_request  *req;   /* for control 
>>> responses */
>>> struct usb_request  *stat_req;  /* for cdc & rndis 
>>> status */
>>> +#ifdef CONFIG_DM_USB
>>> +   struct udevice  *usb_udev;
>>> +#endif
>>>
>>> u8  config;
>>> struct usb_ep   *in_ep, *out_ep, *status_ep;
>>> @@ -2303,6 +2310,24 @@ fail:
>>>
>>>  
>>> /*-*/
>>>
>>> +#ifdef CONFIG_DM_USB
>>> +int dm_usb_init(struct eth_dev *e_dev)
>>> +{
>>> +   struct udevice *dev = NULL;
>>> +   int ret;
>>> +
>>> +   ret = uclass_first_device(UCLASS_USB_DEV_GENERIC, );
>>> +   if (!dev || ret) {
>>> +   error("No USB device found\n");
>>> +   return -ENODEV;
>>> +   }
>>> +
>>> +   e_dev->usb_udev = dev;
>>> +
>>> +   return ret;
>>> +}
>>> +#endif
>>> +
>>>  static int usb_eth_init(struct eth_device *netdev, bd_t *bd)
>>>  {
>>> struct eth_dev *dev = _ethdev;
>>> @@ -2315,7 +2340,14 @@ static int usb_eth_init(struct eth_device 
>>> *netdev, bd_t *bd)
>>> goto fail;
>>> }
>>>
>>> +#ifdef CONFIG_DM_USB
>>> +   if (dm_usb_init(dev)) {
>>> +   error("USB ether not found\n");
>>> +   return -ENODEV;
>>> +   }
>>> +#else
>>> board_usb_init(0, USB_INIT_DEVICE);
>>> +#endif
>>>
>>> /* Configure default mac-addresses for the USB ethernet device 
>>> */
>>>  #ifdef CONFIG_USBNET_DEV_ADDR
>>> @@ -2497,7 +2529,11 @@ void usb_eth_halt(struct eth_device *netdev)
>>> }
>>>
>>> usb_gadget_unregister_driver(_driver);
>>> +#ifdef CONFIG_DM_USB
>>> +   device_remove(dev->usb_udev);
>>> +#else
>>> board_usb_cleanup(0, USB_INIT_DEVICE);
>>> +#endif
>>
>> This doesn't look right to me. If your board is to be an Ethernet
>> device then it should do:
>>
>> uclass_first_device(UCLASS_ETH, )
>>
>> to get the device. That could be in the device tree under the USB
>> node, or perhaps you want to have a setup function which manualy binds
>> the device, a bit like usb_find_and_bind_driver().
>>
>
> This patch is to get usb device for the ether gadget. It uses the same
> api with UCLASS_USB_DEV_GENERIC to get usb device. The patch hadn't done
> for eth driver model adoption.

 So can you do that one first, or is it coming soon?

>>>
>>> Its already implemented above in the function dm_usb_init()
>>
>> So are you saying that the Ethernet 'USB device' driver needs to be
>> converted to driver model? Otherwise what stops us from using
>> UCLASS_ETH here?
> 
> I think the confusion might be that this is a USB gadget and it
> doesn't support ETH DM yet. This code needs lots of clean-up. It is
> still using the old Ethernet stack. This just makes the driver able to
> function if you have USB DM enabled.
> 
> At least that how I understand this patch.
> 

Yes, this patch adopts the driver to use DM_USB and still use only non
DM ETH. Patch 6/6 actually converts the driver to adopt DM_ETH.

Regards
Mugunthan V N
___

Re: [U-Boot] [PATCH] fsl/usb: enable the errata-a005697 for ls1012a

[york sun]

On 11/29/2016 06:39 PM, Jerry Huang wrote:
> Any comment for this patch?
>

Looks simple enough.

York


> Best Regards
> Jerry Huang
>
> -Original Message-
> From: Changming Huang [mailto:jerry.hu...@nxp.com]
> Sent: Thursday, November 24, 2016 3:14 PM
> To: york sun ; u-boot@lists.denx.de
> Cc: Jerry Huang 
> Subject: [PATCH] fsl/usb: enable the errata-a005697 for ls1012a
>
> Enable the errata-a005697 for ls1012a
>
> Signed-off-by: Changming Huang 
> ---
>  drivers/usb/common/fsl-errata.c |4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/usb/common/fsl-errata.c 
> b/drivers/usb/common/fsl-errata.c index 0dc3dd8..59a69a1 100644
> --- a/drivers/usb/common/fsl-errata.c
> +++ b/drivers/usb/common/fsl-errata.c
> @@ -139,6 +139,10 @@ bool has_erratum_a005697(void)
>   case SVR_9132:
>   return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 1, 1);  #endif
> +#ifdef CONFIG_ARM
> + case SVR_LS1012A:
> + return IS_SVR_REV(svr, 1, 0);
> +#endif
>   }
>   return false;
>  }
> --
> 1.7.9.5
>
>

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

Re: [U-Boot] [PATCH v3 04/11] spi: cadence_qspi: Use #define for bits instead of bit shifts

[Jagan Teki]

On Tue, Nov 29, 2016 at 6:28 PM, Phil Edworthy
 wrote:
> Most of the code already uses #defines for the bit value, rather
> than the shift required to get the value. This changes the remaining
> code over.
>
> Whislt at it, fix the names of the "Rd Data Capture" register defs.
>
> Signed-off-by: Phil Edworthy 
> Acked-by: Marek Vasut 
> ---
>  v3:
>  - Remove brackets that aren't needed.
>  v2:
>  - No change.
> ---
>  drivers/spi/cadence_qspi_apb.c | 37 +++--
>  1 file changed, 19 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/spi/cadence_qspi_apb.c b/drivers/spi/cadence_qspi_apb.c
> index 0a2963d..b41f36b 100644
> --- a/drivers/spi/cadence_qspi_apb.c
> +++ b/drivers/spi/cadence_qspi_apb.c
> @@ -57,9 +57,9 @@
>   * Controller's configuration and status register (offset from QSPI_BASE)
>   
> /
>  #defineCQSPI_REG_CONFIG0x00
> -#defineCQSPI_REG_CONFIG_CLK_POL_LSB1
> -#defineCQSPI_REG_CONFIG_CLK_PHA_LSB2
>  #defineCQSPI_REG_CONFIG_ENABLE_MASKBIT(0)
> +#defineCQSPI_REG_CONFIG_CLK_POLBIT(1)
> +#defineCQSPI_REG_CONFIG_CLK_PHABIT(2)
>  #defineCQSPI_REG_CONFIG_DIRECT_MASKBIT(7)
>  #defineCQSPI_REG_CONFIG_DECODE_MASKBIT(9)
>  #defineCQSPI_REG_CONFIG_XIP_IMM_MASK   BIT(18)
> @@ -94,10 +94,10 @@
>  #defineCQSPI_REG_DELAY_TSD2D_MASK  0xFF
>  #defineCQSPI_REG_DELAY_TSHSL_MASK  0xFF
>
> -#defineCQSPI_READLCAPTURE  0x10
> -#defineCQSPI_READLCAPTURE_BYPASS_LSB   0
> -#defineCQSPI_READLCAPTURE_DELAY_LSB1
> -#defineCQSPI_READLCAPTURE_DELAY_MASK   0xF
> +#defineCQSPI_REG_RD_DATA_CAPTURE   0x10
> +#defineCQSPI_REG_RD_DATA_CAPTURE_BYPASSBIT(0)
> +#defineCQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB 1
> +#defineCQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK0xF
>
>  #defineCQSPI_REG_SIZE  0x14
>  #defineCQSPI_REG_SIZE_ADDRESS_LSB  0
> @@ -244,20 +244,20 @@ void cadence_qspi_apb_readdata_capture(void *reg_base,
> unsigned int reg;
> cadence_qspi_apb_controller_disable(reg_base);
>
> -   reg = readl(reg_base + CQSPI_READLCAPTURE);
> +   reg = readl(reg_base + CQSPI_REG_RD_DATA_CAPTURE);
>
> if (bypass)
> -   reg |= (1 << CQSPI_READLCAPTURE_BYPASS_LSB);
> +   reg |= CQSPI_REG_RD_DATA_CAPTURE_BYPASS;
> else
> -   reg &= ~(1 << CQSPI_READLCAPTURE_BYPASS_LSB);
> +   reg &= ~CQSPI_REG_RD_DATA_CAPTURE_BYPASS;
>
> -   reg &= ~(CQSPI_READLCAPTURE_DELAY_MASK
> -   << CQSPI_READLCAPTURE_DELAY_LSB);
> +   reg &= ~(CQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK
> +   << CQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB);
>
> -   reg |= ((delay & CQSPI_READLCAPTURE_DELAY_MASK)
> -   << CQSPI_READLCAPTURE_DELAY_LSB);
> +   reg |= (delay & CQSPI_REG_RD_DATA_CAPTURE_DELAY_MASK)
> +   << CQSPI_REG_RD_DATA_CAPTURE_DELAY_LSB;
>
> -   writel(reg, reg_base + CQSPI_READLCAPTURE);
> +   writel(reg, reg_base + CQSPI_REG_RD_DATA_CAPTURE);
>
> cadence_qspi_apb_controller_enable(reg_base);
> return;
> @@ -301,11 +301,12 @@ void cadence_qspi_apb_set_clk_mode(void *reg_base,
>
> cadence_qspi_apb_controller_disable(reg_base);
> reg = readl(reg_base + CQSPI_REG_CONFIG);
> -   reg &= ~(1 << CQSPI_REG_CONFIG_CLK_POL_LSB);
> -   reg &= ~(1 << CQSPI_REG_CONFIG_CLK_PHA_LSB);
> +   reg &= ~(CQSPI_REG_CONFIG_CLK_POL | CQSPI_REG_CONFIG_CLK_PHA);
>
> -   reg |= ((clk_pol & 0x1) << CQSPI_REG_CONFIG_CLK_POL_LSB);
> -   reg |= ((clk_pha & 0x1) << CQSPI_REG_CONFIG_CLK_PHA_LSB);
> +   if (clk_pol)
> +   reg |= CQSPI_REG_CONFIG_CLK_POL;
> +   if (clk_pha)
> +   reg |= CQSPI_REG_CONFIG_CLK_PHA;

I've commented about this change [1]?

[1] https://www.mail-archive.com/u-boot@lists.denx.de/msg232120.html

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

Re: [U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Stephen Warren]

On 11/21/2016 04:21 PM, Alexander Graf wrote:



On 21/11/2016 23:21, Stephen Warren wrote:

On 11/18/2016 05:18 AM, Alexander Graf wrote:

We have all the building blocks now to run arbitrary efi applications
in travis. The most important one out there is grub2, so let's add
a simple test to verify that grub2 still comes up.



diff --git a/.travis.yml b/.travis.yml



@@ -45,6 +48,9 @@ install:
  - virtualenv /tmp/venv
  - . /tmp/venv/bin/activate
  - pip install pytest
+ - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo lsefimmap
lsefi lsefisystab efinet tftp minicmd
+ - mkdir ~/grub2-arm
+ - ( cd ~/grub2-arm; wget -O -
http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm

| rpm2cpio | cpio -di )


Do we really want to do this for all the build-only jobs too? I might
have expected to do this inside the test scripts that actually use those
binaries.


diff --git a/test/py/tests/test_efi_loader.py
b/test/py/tests/test_efi_loader.py



+@pytest.mark.buildconfigspec('cmd_bootefi')



+u_boot_console.run_command('bootefi %x' % addr,
wait_for_prompt=False)
+
+# Verify that we have an SMBIOS table
+check_smbios =
u_boot_console.config.env.get('env__efi_loader_check_smbios', False)
+if check_smbios:
+u_boot_console.wait_for('grub>')
+output = u_boot_console.run_command('lsefisystab',
wait_for_prompt=False, wait_for_echo=False)
+u_boot_console.wait_for('SMBIOS')
+
+# Then exit cleanly
+u_boot_console.wait_for('grub>')
+output = u_boot_console.run_command('exit',
wait_for_prompt=False, wait_for_echo=False)
+u_boot_console.wait_for('r = 0')
+
+# And give us our U-Boot prompt back
+u_boot_console.run_command('')


I can't help wondering if adding push_prompt() function (for use in a
Python "with" statement) to u_boot_console wouldn't be better; that
would avoid all the wait_for_prompt=False and wait_for(prompt) logic
there.


What would that function do? The same?


The internal implementation would likely look the same, but it would 
avoid needing to implement/replicate such low-level prompt-parsing 
details in each test that invokes "sub-commands" with different prompts.

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

Re: [U-Boot] [PATCH v2] travis: Add efi_loader grub2 test

[Stephen Warren]

On 11/21/2016 04:15 PM, Alexander Graf wrote:



On 21/11/2016 23:31, Tom Rini wrote:

On Mon, Nov 21, 2016 at 03:21:43PM -0700, Stephen Warren wrote:

On 11/18/2016 05:18 AM, Alexander Graf wrote:

We have all the building blocks now to run arbitrary efi applications
in travis. The most important one out there is grub2, so let's add
a simple test to verify that grub2 still comes up.



diff --git a/.travis.yml b/.travis.yml



@@ -45,6 +48,9 @@ install:
 - virtualenv /tmp/venv
 - . /tmp/venv/bin/activate
 - pip install pytest
+ - grub-mkimage -o ~/grub_x86.efi -O i386-efi normal  echo
lsefimmap lsefi lsefisystab efinet tftp minicmd
+ - mkdir ~/grub2-arm
+ - ( cd ~/grub2-arm; wget -O -
http://download.opensuse.org/ports/armv7hl/distribution/leap/42.2/repo/oss/suse/armv7hl/grub2-arm-efi-2.02~beta2-87.1.armv7hl.rpm
| rpm2cpio | cpio -di )


Do we really want to do this for all the build-only jobs too? I
might have expected to do this inside the test scripts that actually
use those binaries.


So, it's the difference between making various jobs / stanzas more
correct vs taking more time to do stuff.  Unless this starts to push the
"catch-all" arm job over the time limit, I don't think it's a big deal
either way.  And since travis-ci will tell us how long a given stanza
takes we'll have a good idea pretty quick on if that's starting to take
too long.  That said, I don't have a strong opinion here and it wouldn't
be too hard to move all of this into being under the TEST_PY_BD check
and since we aren't relying on apt, it's not going to be time-in-apt
factor.


If we move it into TEST_PY_BD, we would either run the same sequence
over and over again for individual tests or check if the file exists
inside the generation path. Either way, it will get less readable :).


I believe each test job configures a new container, so no, the change I 
suggested would mean a given job would either:


a) Run a build without downloading the test EFI RPM.

b) Run a test and download the EFI RPM once.

It seems trivial to just put this in the right place, although 
admittedly if it's quick it's not going to save much, except that it 
will make all the compile-only tests not depend on so many 
potentially-intermittent network accesses.



Overall, we're talking of 1s of build time for this:

  https://travis-ci.org/agraf/u-boot/jobs/177000864

so I'd definitely prefer to keep it simple rather than optimized.


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

Re: [U-Boot] [PATCH] fsl/usb: enable the errata-a005697 for ls1012a

[Jerry Huang]

Any comment for this patch?

Best Regards
Jerry Huang

-Original Message-
From: Changming Huang [mailto:jerry.hu...@nxp.com] 
Sent: Thursday, November 24, 2016 3:14 PM
To: york sun ; u-boot@lists.denx.de
Cc: Jerry Huang 
Subject: [PATCH] fsl/usb: enable the errata-a005697 for ls1012a

Enable the errata-a005697 for ls1012a

Signed-off-by: Changming Huang 
---
 drivers/usb/common/fsl-errata.c |4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/usb/common/fsl-errata.c b/drivers/usb/common/fsl-errata.c 
index 0dc3dd8..59a69a1 100644
--- a/drivers/usb/common/fsl-errata.c
+++ b/drivers/usb/common/fsl-errata.c
@@ -139,6 +139,10 @@ bool has_erratum_a005697(void)
case SVR_9132:
return IS_SVR_REV(svr, 1, 0) || IS_SVR_REV(svr, 1, 1);  #endif
+#ifdef CONFIG_ARM
+   case SVR_LS1012A:
+   return IS_SVR_REV(svr, 1, 0);
+#endif
}
return false;
 }
--
1.7.9.5

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

Re: [U-Boot] [PATCH v5 10/13] tegra: Use a U-Boot-specific .dtsi file

[Stephen Warren]

On 11/28/2016 03:09 PM, Simon Glass wrote:

Hi Stephen,

On 17 November 2016 at 12:45, Stephen Warren  wrote:


On 11/16/2016 06:13 PM, Simon Glass wrote:


With the new device-tree rules it is possible to put device-tree changes
needed by U-Boot into their own file. As an example of this approach, move
Tegra over to use it.



Sounds like a good idea.


diff --git a/arch/arm/dts/tegra20-u-boot.dtsi b/arch/arm/dts/tegra20-u-boot.dtsi



I'd expect to see more "U-Boot overlay" DTs than this; I recall there being 
more differences between U-Boot and kernel DTS files when I last sync'd the two.


Yes but most of those changes should be dropped. I did a partial sync
a few months back but if you recall there were still differences. Is
this something the Tegra maintainer might look at?

I don't want to immortalise those differences in a separate U-Boot
file when really we should just get rid of them.


From my perspective, we should have two files:

1) The base DT.

This should not contain any U-Boot modifications, and should exactly 
match the DT used elsewhere, such as in mainline Linux. Since this 
should always match other DTs, we should pretty much always be able to 
over-write it with any updated DT from other sources.


2) The U-Boot modifications.

This always contain /all/ local modifications applied by U-Boot. It 
shouldn't matter why the change was made, or how long we hope/expect the 
delta to continue to exist. This will isolate all U-Boot changes into 
this file so it's obvious what local changes exist. If some changes are 
intended to be temporary, we can add a comment to that effect, and 
eventually submit a patch to remove the delta.


I don't think that putting a change into this "U-Boot local overlay" 
should in any way imply that the change is by definition correct and 
long-term; some changes may satisfy that decription and others won't. 
Just like we sometimes have C code that we wish we didn't and eventually 
clean up.

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

Re: [U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Vignesh R]

[...]
>>>
>>> I'd like to have at least Dinh's/Chin's ack on this.
>>>
>>> btw don't you need BB for READ as well ?
>>>
>>
>> I don't see any issue with READ due to non word size accesses ATM,
>
> Like user does sf read ... 0x1003 0x100 , you'll likely have a problem, 
> no?

 No issues with that either. The above limitation seems to be only wrt sf
 write (indirect write).
>>>
>>> Because indirect read already uses readsb to handle the alignment , right ?
>>>
>>
>> Alignment is not the problem here, even indirect write uses writesb to
>> handle alignment. But the problem is, driver uses readsb/writesb (which
>> perform byte wise accesses) for reading/writing, if txbuf/rxbuf is
>> unaligned or data length is not a multiple of word size. As per the TI
>> K2G SoC TRM, external master is not permitted to do non 32 bit indirect
>> read/write accesses except for last read/write.
>> So, if the driver writes say 25 bytes, one byte at a time using writesb,
>> then some bytes are do not get written to flash correctly (instead 0x0
>> is written).
> 
> Well ok, then we have a problem on READ as well.
> 
>> What my patch is doing is to use bounce buffer so that txbuf is always
>> aligned and writesl can be used instead of writesb. And also make sure
>> that writesb is only to right last trailing bytes in case data length is
>> not a multiple of word size.
> 
> Right.
> 
>> But wrt indirect read, I don't see any such data corruption or other
>> issues if driver reads, say 25 bytes, one byte at a time using readsb
>> (though the TRM advises against this)
> 
> Correct, so fix the READ path too to be extra sure.
> 

Yes, I will submit a separate patch for that shortly.

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

Re: [U-Boot] [PATCH 1/1] rpi: set serial port clock to 48 MHz

[Stephen Warren]

On 11/27/2016 11:05 PM, Mirza Krak wrote:

From: Mirza Krak 

Recently the default UART clock rate has been changed to 48 MHz on all
pi`s in the firmware files, which broke UART support in u-boot.

Align configuration to boot firmware.



diff --git a/board/raspberrypi/rpi/rpi.c b/board/raspberrypi/rpi/rpi.c



@@ -37,7 +37,7 @@ static const struct pl01x_serial_platdata serial_platdata = {
.base = 0x20201000,
 #endif
.type = TYPE_PL011,
-   .clock = 300,
+   .clock = 4800,


I'm not sure this is the best fix, since it will prevent the latest 
U-Boot from working with the FW before the change.


Better would be:

a) Revert the change in the FW, since it violates the contract that 
previously existed between FW and OS, and will likely break UART usage 
on (almost?) all SW.


b) Detect the correct clock rate at run-time rather than hard-coding it.

b1) Perhaps the rate is available in the DT passed by the FW, which 
following http://patchwork.ozlabs.org/patch/690769/ "rpi: save firmware 
provided boot param for later use" should now be available within U-Boot 
to parse.


b2) Perhaps query the rate from the FW via the mailbox API; see 
https://github.com/raspberrypi/firmware/wiki/Mailbox-property-interface

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

Re: [U-Boot] [PATCH] armv8: QSPI: Add AHB bus 16MB+ size support

[Yao Yuan]

On 11/15/2016 02:27 AM, York Sun wrote:
> On 11/07/2016 10:03 PM, Yao Yuan wrote:
> > On 11/08/2016 02:27 AM, York Sun wrote:
> >> On 10/25/2016 07:10 PM, Yuan Yao wrote:
> >>> From: Yuan Yao 
> >>>
> >>> The default configuration for QSPI AHB bus can't support 16MB+.
> >>> But some flash on NXP layerscape board are more than 16MB.
> >>
> >> So what do you do?
> >>
> >> Is this an erratum workaround? If yes, please refer the erratum number.
> >
> > Hi York,
> >
> > I think It's not an erratum maybe it's better to call it new feature.
> >
> > As a default configuration for QSPI AHB, the address size is 3-bytes.
> > It has a good compatibility for QSPI boot for different SPI-NOR flash.
> >
> > But if the address size is only 3-bytes, the QSPI can't access to the data 
> > that
> more than 16M+.
> >
> > So we can update the default configuration for QSPI AHB in uboot to use 4-
> bytes address.
> > So that QSPI can access to 16M+ size by AHB bus.
> 
> Let me try to understand this. With your change, 4-byte addressing is
> supported. Do all flash chips support 4-byte addressing?

No, Not all the flash.
 
> 
> >
> > Thanks.
> >>
> >>>
> >>> Signed-off-by: Yuan Yao 
> >>> ---
> >>>  arch/arm/cpu/armv8/fsl-layerscape/soc.c| 37
> >> ++
> >>>  .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
> >>> .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
> >>>  include/configs/ls1012a_common.h   |  1 +
> >>>  include/configs/ls1046ardb.h   |  1 +
> >>>  5 files changed, 41 insertions(+)
> >>>
> >>> diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> index d68eeba..18d753e 100644
> >>> --- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> +++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
> >>> @@ -370,6 +370,40 @@ void fsl_lsch2_early_init_f(void)  }  #endif
> >>>
> >>> +#ifdef CONFIG_QSPI_AHB_INIT
> >>> +/* Enable 4bytes address support and fast read */ int
> >>> +qspi_ahb_init(void) {
> >>> + u32 *qspi_lut, lut_key, *qspi_key;
> >>> +
> >>> + qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
> >>> + qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
> >>> +
> >>> + lut_key = in_be32(qspi_key);
> >>> +
> >>> + if (lut_key == 0x5af05af0) {
> >>> + /* That means the register is BE */
> >>> + out_be32(qspi_key, 0x5af05af0);
> >>> + out_be32(qspi_key + 1, 0x0002);
> >>> + out_be32(qspi_lut, 0x0820040c);
> >>> + out_be32(qspi_lut + 1, 0x1c080c08);
> >>> + out_be32(qspi_lut + 2, 0x2400);
> >>> + out_be32(qspi_key, 0x5af05af0);
> >>> + out_be32(qspi_key + 1, 0x0001);
> >>> + } else {
> >>> + /* That means the register is LE */
> >>> + out_le32(qspi_key, 0x5af05af0);
> >>> + out_le32(qspi_key + 1, 0x0002);
> >>> + out_le32(qspi_lut, 0x0820040c);
> >>> + out_le32(qspi_lut + 1, 0x1c080c08);
> >>> + out_le32(qspi_lut + 2, 0x2400);
> >>> + out_le32(qspi_key, 0x5af05af0);
> >>> + out_le32(qspi_key + 1, 0x0001);
> >>> + }
> >>
> >> What do these sequences do?
> >
> > It used to set the AHB bus to use 4-bytes command and the corresponding
> sequence.
> > So that QSPI can access to 16M+ size by AHB bus.
> >
> >>
> >> Put a blank line before return.
> 
> You need a blank line here.

OK, get it.


> 
> >>
> >>> + return 0;
> >>> +}
> >>> +#endif
> >>> +
> >>>  #ifdef CONFIG_BOARD_LATE_INIT
> >>>  int board_late_init(void)
> >>>  {
> >>> @@ -379,6 +413,9 @@ int board_late_init(void)  #ifdef
> >>> CONFIG_CHAIN_OF_TRUST
> >>>   fsl_setenv_chain_of_trust();
> >>>  #endif
> >>> +#ifdef CONFIG_QSPI_AHB_INIT
> >>> + qspi_ahb_init();
> >>> +#endif
> >>>
> >>>   return 0;
> >>>  }
> >>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> >>> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> >>> index d88543d..a28b1fd 100644
> >>> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> >>> +++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
> >>> @@ -18,6 +18,7 @@
> >>>  #define CONFIG_SYS_CCI400_ADDR
>   (CONFIG_SYS_IMMR +
> >> 0x0018)
> >>>  #define CONFIG_SYS_GIC400_ADDR
>   (CONFIG_SYS_IMMR +
> >> 0x0040)
> >>>  #define CONFIG_SYS_IFC_ADDR  (CONFIG_SYS_IMMR +
> >> 0x0053)
> >>> +#define CONFIG_SYS_QSPI_ADDR
>   (CONFIG_SYS_IMMR +
> >> 0x0055)
> >>>  #define CONFIG_SYS_FSL_ESDHC_ADDR(CONFIG_SYS_IMMR +
> >> 0x0056)
> >>>  #define CONFIG_SYS_FSL_CSU_ADDR
> >>(CONFIG_SYS_IMMR + 0x0051)
> >>>  #define CONFIG_SYS_FSL_GUTS_ADDR (CONFIG_SYS_IMMR +
> >> 0x00ee)
> >>> diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >>> b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >>> index 7acba27..8aefc76 100644
> >>> --- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
> >>> +++ 

[U-Boot] [PATCH v2] armv8: QSPI: Add AHB bus 16MB+ size support

[Yuan Yao]

From: Yuan Yao 

The default configuration for QSPI AHB bus can't support 16MB+.
But some flash on NXP layerscape board are more than 16MB.

Signed-off-by: Yuan Yao 
---
Changed in v2:
Remove the CONFIG_QSPI_AHB_INIT into Kconfig.
---
 arch/arm/cpu/armv8/fsl-layerscape/Kconfig  |  7 
 arch/arm/cpu/armv8/fsl-layerscape/soc.c| 38 ++
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  1 +
 .../include/asm/arch-fsl-layerscape/immap_lsch3.h  |  1 +
 configs/ls1012afrdm_qspi_defconfig |  1 +
 configs/ls1012aqds_qspi_defconfig  |  1 +
 configs/ls1012ardb_qspi_defconfig  |  1 +
 configs/ls1046ardb_qspi_defconfig  |  1 +
 scripts/config_whitelist.txt   |  1 +
 9 files changed, 52 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig 
b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
index 94ec8d5..f078712 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Kconfig
@@ -71,6 +71,13 @@ config NUM_DDR_CONTROLLERS
default 3 if ARCH_LS2080A
default 1
 
+config QSPI_AHB_INIT
+   bool "Init the QSPI AHB bus"
+   help
+ The default setting for QSPI AHB bus just support 3bytes addressing.
+ But some QSPI flash size up to 64MBytes, so initialize the QSPI AHB
+ bus for those flashes to support the full QSPI flash size.
+
 config SYS_FSL_IFC_BANK_COUNT
int "Maximum banks of Integrated flash controller"
depends on ARCH_LS1043A || ARCH_LS1046A || ARCH_LS2080A
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 6c42387..44927b1 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -373,6 +373,41 @@ void fsl_lsch2_early_init_f(void)
 }
 #endif
 
+#ifdef CONFIG_QSPI_AHB_INIT
+/* Enable 4bytes address support and fast read */
+int qspi_ahb_init(void)
+{
+   u32 *qspi_lut, lut_key, *qspi_key;
+
+   qspi_key = (void *)CONFIG_SYS_QSPI_ADDR + 0x300;
+   qspi_lut = (void *)CONFIG_SYS_QSPI_ADDR + 0x310;
+
+   lut_key = in_be32(qspi_key);
+
+   if (lut_key == 0x5af05af0) {
+   /* That means the register is BE */
+   out_be32(qspi_key, 0x5af05af0);
+   out_be32(qspi_key + 1, 0x0002);
+   out_be32(qspi_lut, 0x0820040c);
+   out_be32(qspi_lut + 1, 0x1c080c08);
+   out_be32(qspi_lut + 2, 0x2400);
+   out_be32(qspi_key, 0x5af05af0);
+   out_be32(qspi_key + 1, 0x0001);
+   } else {
+   /* That means the register is LE */
+   out_le32(qspi_key, 0x5af05af0);
+   out_le32(qspi_key + 1, 0x0002);
+   out_le32(qspi_lut, 0x0820040c);
+   out_le32(qspi_lut + 1, 0x1c080c08);
+   out_le32(qspi_lut + 2, 0x2400);
+   out_le32(qspi_key, 0x5af05af0);
+   out_le32(qspi_key + 1, 0x0001);
+   }
+
+   return 0;
+}
+#endif
+
 #ifdef CONFIG_BOARD_LATE_INIT
 int board_late_init(void)
 {
@@ -382,6 +417,9 @@ int board_late_init(void)
 #ifdef CONFIG_CHAIN_OF_TRUST
fsl_setenv_chain_of_trust();
 #endif
+#ifdef CONFIG_QSPI_AHB_INIT
+   qspi_ahb_init();
+#endif
 
return 0;
 }
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
index d88543d..a28b1fd 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch2.h
@@ -18,6 +18,7 @@
 #define CONFIG_SYS_CCI400_ADDR (CONFIG_SYS_IMMR + 0x0018)
 #define CONFIG_SYS_GIC400_ADDR (CONFIG_SYS_IMMR + 0x0040)
 #define CONFIG_SYS_IFC_ADDR(CONFIG_SYS_IMMR + 0x0053)
+#define CONFIG_SYS_QSPI_ADDR   (CONFIG_SYS_IMMR + 0x0055)
 #define CONFIG_SYS_FSL_ESDHC_ADDR  (CONFIG_SYS_IMMR + 0x0056)
 #define CONFIG_SYS_FSL_CSU_ADDR(CONFIG_SYS_IMMR + 
0x0051)
 #define CONFIG_SYS_FSL_GUTS_ADDR   (CONFIG_SYS_IMMR + 0x00ee)
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h 
b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
index 2df56f7..e0cf0e4 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/immap_lsch3.h
@@ -19,6 +19,7 @@
 #define CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR   (CONFIG_SYS_IMMR + 0x0030)
 #define CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR   (CONFIG_SYS_IMMR + 0x0031)
 #define CONFIG_SYS_FSL_CH3_CLK_CTRL_ADDR   (CONFIG_SYS_IMMR + 0x0037)
+#define CONFIG_SYS_QSPI_ADDR   (CONFIG_SYS_IMMR + 0x010c)
 #define CONFIG_SYS_FSL_ESDHC_ADDR  (CONFIG_SYS_IMMR + 0x0114)
 #define CONFIG_SYS_IFC_ADDR  

[U-Boot] [PATCH v2] ls1021a: QSPI: update the node for QSPI support

[Yuan Yao]

From: Yuan Yao 

Add the name for register space and memory space.
<0x155 0x1 > is the QSPI register space.
<0x4000 0x400> is the QSPI memory space.

Signed-off-by: Yuan Yao 
---
Changed in v2:
Updated the commit message.
---
 arch/arm/dts/ls1021a.dtsi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/dts/ls1021a.dtsi b/arch/arm/dts/ls1021a.dtsi
index 119b1af..37be169 100644
--- a/arch/arm/dts/ls1021a.dtsi
+++ b/arch/arm/dts/ls1021a.dtsi
@@ -176,6 +176,7 @@
#size-cells = <0>;
reg = <0x155 0x1>,
<0x4000 0x400>;
+   reg-names = "QuadSPI", "QuadSPI-memory";
num-cs = <2>;
big-endian;
status = "disabled";
-- 
2.1.0.27.g96db324

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

Re: [U-Boot] [PATCH 05/14] serial: 16550: Add port type as driver data

[Marek Vasut]

On 11/30/2016 04:10 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 29 November 2016 at 20:04, Marek Vasut  wrote:
>> On 11/30/2016 03:26 AM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 29 November 2016 at 18:27, Marek Vasut  wrote:
 On 11/30/2016 01:32 AM, Simon Glass wrote:
> Hi Marek,
>
> On 27 November 2016 at 10:07, Marek Vasut  wrote:
>> On 11/27/2016 06:03 PM, Simon Glass wrote:
>>> Hi Marex,
>>>
>>> On 25 November 2016 at 15:32, Marek Vasut  wrote:
 Add driver data to each compatible string to identify the type of
 the port. Since all the ports in the driver are entirely compatible
 with 16550 for now, all are marked with PORT_NS16550. But, there
 are ports which have specific quirks, like the JZ4780 UART, which
 do not have any DT property to denote the quirks. Instead, Linux
 uses the compatible string to discern such ports and enable the
 necessary quirks.

 Signed-off-by: Marek Vasut 
 Cc: Tom Rini 
 Cc: Simon Glass 
 ---
  drivers/serial/ns16550.c | 26 --
  1 file changed, 16 insertions(+), 10 deletions(-)

 diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
 index 3c9f3b0..3130a1d 100644
 --- a/drivers/serial/ns16550.c
 +++ b/drivers/serial/ns16550.c
 @@ -360,6 +360,12 @@ int ns16550_serial_probe(struct udevice *dev)
 return 0;
  }

 +#if CONFIG_IS_ENABLED(OF_CONTROL)
 +enum {
 +   PORT_NS16550 = 0,
 +};
 +#endif
 +
  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
  int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
  {
 @@ -453,16 +459,16 @@ const struct dm_serial_ops ns16550_serial_ops = {
   * compatible string to your dts.
   */
  static const struct udevice_id ns16550_serial_ids[] = {
 -   { .compatible = "ns16550" },
 -   { .compatible = "ns16550a" },
 -   { .compatible = "nvidia,tegra20-uart" },
 -   { .compatible = "snps,dw-apb-uart" },
 -   { .compatible = "ti,omap2-uart" },
 -   { .compatible = "ti,omap3-uart" },
 -   { .compatible = "ti,omap4-uart" },
 -   { .compatible = "ti,am3352-uart" },
 -   { .compatible = "ti,am4372-uart" },
 -   { .compatible = "ti,dra742-uart" },
 +   { .compatible = "ns16550",  .data = PORT_NS16550 },
 +   { .compatible = "ns16550a", .data = PORT_NS16550 },
 +   { .compatible = "nvidia,tegra20-uart",  .data = PORT_NS16550 },
 +   { .compatible = "snps,dw-apb-uart", .data = PORT_NS16550 },
 +   { .compatible = "ti,omap2-uart",.data = PORT_NS16550 },
 +   { .compatible = "ti,omap3-uart",.data = PORT_NS16550 },
 +   { .compatible = "ti,omap4-uart",.data = PORT_NS16550 },
 +   { .compatible = "ti,am3352-uart",   .data = PORT_NS16550 },
 +   { .compatible = "ti,am4372-uart",   .data = PORT_NS16550 },
 +   { .compatible = "ti,dra742-uart",   .data = PORT_NS16550 },
>>>
>>> But can we have 0 as the default so we don't need these values?
>>
>> PORT_NS16550 is zero anyway, it's just explicitly spelled here.
>
> One way might be to use PORT_DEFAULT, set it to 0 and omit it here. It
> does seem odd to have PORT_NS16550 in the ns16550 driver.

 I'd rather be explicit in case we grow this list, it also doesn't hurt
 anything since it is implicitly set to zero. Or is this something more
 than a matter of preference here ?
>>>
>>> Well, at least rename the PORT value to DEFAULT or something like that
>>> if you want to be explicit.
>>
>> Why DEFAULT ? It's NS16550 compatible port and the others are not
>> entirely NS16550 compatible, so I think NS16550 is exactly how it should
>> be named. There never was any DEFAULT label on these chips,
>> but the original 16550 UART chip had 16550 written on it.
> 
> Because the driver is called ns16550. So one can assume that this is
> the base case...

Until someone refactors it or splits it. I wouldn't go with that
assumption. I really dislike having some default here.

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

Re: [U-Boot] [PATCH v2 10/22] spi: Add error checking for invalid bus widths

[Simon Glass]

Hi,

On 25 November 2016 at 20:28, Jagan Teki  wrote:
> On Sat, Nov 26, 2016 at 1:08 AM, Simon Glass  wrote:
>> Hi,
>>
>> On 25 November 2016 at 09:59, Fabio Estevam  wrote:
>>> On Fri, Nov 25, 2016 at 2:57 PM, Jagan Teki  wrote:
>>>
 Yeah, ie what if dts has a wrong value and do print that and continue
 with default width, so-that the user will update this for next run.
 Since it's not key a attribute to break or decide functionality better
 to go with it.
>>>
>>> Agreed. This also matches with the kernel behaviour.
>>
>> So it is correct to print an error, and then continue? This error will
>> almost never occur and thus it wastes code space. SPI is sensitive
>> because it can be used in SPL. Linux doesn't care about code size as
>> much.
>>
>> So how about either:
>> 1. debug() and return an error
>> 2. debug() and skip the error
>
> I prefer 2. for SPL and replace debug with printf for U-Boot.

OK I have sent v3.

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

Re: [U-Boot] [PATCH 05/14] serial: 16550: Add port type as driver data

[Simon Glass]

Hi Marek,

On 29 November 2016 at 20:04, Marek Vasut  wrote:
> On 11/30/2016 03:26 AM, Simon Glass wrote:
>> Hi Marek,
>>
>> On 29 November 2016 at 18:27, Marek Vasut  wrote:
>>> On 11/30/2016 01:32 AM, Simon Glass wrote:
 Hi Marek,

 On 27 November 2016 at 10:07, Marek Vasut  wrote:
> On 11/27/2016 06:03 PM, Simon Glass wrote:
>> Hi Marex,
>>
>> On 25 November 2016 at 15:32, Marek Vasut  wrote:
>>> Add driver data to each compatible string to identify the type of
>>> the port. Since all the ports in the driver are entirely compatible
>>> with 16550 for now, all are marked with PORT_NS16550. But, there
>>> are ports which have specific quirks, like the JZ4780 UART, which
>>> do not have any DT property to denote the quirks. Instead, Linux
>>> uses the compatible string to discern such ports and enable the
>>> necessary quirks.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Tom Rini 
>>> Cc: Simon Glass 
>>> ---
>>>  drivers/serial/ns16550.c | 26 --
>>>  1 file changed, 16 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>>> index 3c9f3b0..3130a1d 100644
>>> --- a/drivers/serial/ns16550.c
>>> +++ b/drivers/serial/ns16550.c
>>> @@ -360,6 +360,12 @@ int ns16550_serial_probe(struct udevice *dev)
>>> return 0;
>>>  }
>>>
>>> +#if CONFIG_IS_ENABLED(OF_CONTROL)
>>> +enum {
>>> +   PORT_NS16550 = 0,
>>> +};
>>> +#endif
>>> +
>>>  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>>>  int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
>>>  {
>>> @@ -453,16 +459,16 @@ const struct dm_serial_ops ns16550_serial_ops = {
>>>   * compatible string to your dts.
>>>   */
>>>  static const struct udevice_id ns16550_serial_ids[] = {
>>> -   { .compatible = "ns16550" },
>>> -   { .compatible = "ns16550a" },
>>> -   { .compatible = "nvidia,tegra20-uart" },
>>> -   { .compatible = "snps,dw-apb-uart" },
>>> -   { .compatible = "ti,omap2-uart" },
>>> -   { .compatible = "ti,omap3-uart" },
>>> -   { .compatible = "ti,omap4-uart" },
>>> -   { .compatible = "ti,am3352-uart" },
>>> -   { .compatible = "ti,am4372-uart" },
>>> -   { .compatible = "ti,dra742-uart" },
>>> +   { .compatible = "ns16550",  .data = PORT_NS16550 },
>>> +   { .compatible = "ns16550a", .data = PORT_NS16550 },
>>> +   { .compatible = "nvidia,tegra20-uart",  .data = PORT_NS16550 },
>>> +   { .compatible = "snps,dw-apb-uart", .data = PORT_NS16550 },
>>> +   { .compatible = "ti,omap2-uart",.data = PORT_NS16550 },
>>> +   { .compatible = "ti,omap3-uart",.data = PORT_NS16550 },
>>> +   { .compatible = "ti,omap4-uart",.data = PORT_NS16550 },
>>> +   { .compatible = "ti,am3352-uart",   .data = PORT_NS16550 },
>>> +   { .compatible = "ti,am4372-uart",   .data = PORT_NS16550 },
>>> +   { .compatible = "ti,dra742-uart",   .data = PORT_NS16550 },
>>
>> But can we have 0 as the default so we don't need these values?
>
> PORT_NS16550 is zero anyway, it's just explicitly spelled here.

 One way might be to use PORT_DEFAULT, set it to 0 and omit it here. It
 does seem odd to have PORT_NS16550 in the ns16550 driver.
>>>
>>> I'd rather be explicit in case we grow this list, it also doesn't hurt
>>> anything since it is implicitly set to zero. Or is this something more
>>> than a matter of preference here ?
>>
>> Well, at least rename the PORT value to DEFAULT or something like that
>> if you want to be explicit.
>
> Why DEFAULT ? It's NS16550 compatible port and the others are not
> entirely NS16550 compatible, so I think NS16550 is exactly how it should
> be named. There never was any DEFAULT label on these chips,
> but the original 16550 UART chip had 16550 written on it.

Because the driver is called ns16550. So one can assume that this is
the base case...

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

Re: [U-Boot] [PATCH v3 4/7] arm: omap5: Add TEE loading support

[Tom Rini]

On Tue, Nov 29, 2016 at 04:33:23PM -0600, Andrew F. Davis wrote:

> From: Harinarayan Bhatta 
> 
> secure_tee_install is used to install and initialize a secure TEE OS such as
> Linaro OP-TEE into the secure world. This function takes in the address
> where the signed TEE image is loaded as an argument. The signed TEE image
> consists of a header (struct tee_header), TEE code+data followed by the
> signature generated using image signing tool from TI security development
> package (SECDEV). Refer to README.ti-secure for more information.
> 
> This function uses 2 new secure APIs.
> 
> 1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected
>memory for TEE must be reserved before calling this function. This API
>needs arguments filled into struct ppa_tee_load_info. The TEE image is
>authenticated and if there are no errors, the control passes to the TEE
>entry point.
> 
> 2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after
>a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was
>successfully loaded (on core 0) and transfers control to the same TEE
>entry point.
> 
> The code at TEE entry point is expected perform OS initialization steps
> and return back to non-secure world (U-Boot).
> 
> Signed-off-by: Harinarayan Bhatta 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 05/14] serial: 16550: Add port type as driver data

[Marek Vasut]

On 11/30/2016 03:26 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 29 November 2016 at 18:27, Marek Vasut  wrote:
>> On 11/30/2016 01:32 AM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 27 November 2016 at 10:07, Marek Vasut  wrote:
 On 11/27/2016 06:03 PM, Simon Glass wrote:
> Hi Marex,
>
> On 25 November 2016 at 15:32, Marek Vasut  wrote:
>> Add driver data to each compatible string to identify the type of
>> the port. Since all the ports in the driver are entirely compatible
>> with 16550 for now, all are marked with PORT_NS16550. But, there
>> are ports which have specific quirks, like the JZ4780 UART, which
>> do not have any DT property to denote the quirks. Instead, Linux
>> uses the compatible string to discern such ports and enable the
>> necessary quirks.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Tom Rini 
>> Cc: Simon Glass 
>> ---
>>  drivers/serial/ns16550.c | 26 --
>>  1 file changed, 16 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>> index 3c9f3b0..3130a1d 100644
>> --- a/drivers/serial/ns16550.c
>> +++ b/drivers/serial/ns16550.c
>> @@ -360,6 +360,12 @@ int ns16550_serial_probe(struct udevice *dev)
>> return 0;
>>  }
>>
>> +#if CONFIG_IS_ENABLED(OF_CONTROL)
>> +enum {
>> +   PORT_NS16550 = 0,
>> +};
>> +#endif
>> +
>>  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>>  int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
>>  {
>> @@ -453,16 +459,16 @@ const struct dm_serial_ops ns16550_serial_ops = {
>>   * compatible string to your dts.
>>   */
>>  static const struct udevice_id ns16550_serial_ids[] = {
>> -   { .compatible = "ns16550" },
>> -   { .compatible = "ns16550a" },
>> -   { .compatible = "nvidia,tegra20-uart" },
>> -   { .compatible = "snps,dw-apb-uart" },
>> -   { .compatible = "ti,omap2-uart" },
>> -   { .compatible = "ti,omap3-uart" },
>> -   { .compatible = "ti,omap4-uart" },
>> -   { .compatible = "ti,am3352-uart" },
>> -   { .compatible = "ti,am4372-uart" },
>> -   { .compatible = "ti,dra742-uart" },
>> +   { .compatible = "ns16550",  .data = PORT_NS16550 },
>> +   { .compatible = "ns16550a", .data = PORT_NS16550 },
>> +   { .compatible = "nvidia,tegra20-uart",  .data = PORT_NS16550 },
>> +   { .compatible = "snps,dw-apb-uart", .data = PORT_NS16550 },
>> +   { .compatible = "ti,omap2-uart",.data = PORT_NS16550 },
>> +   { .compatible = "ti,omap3-uart",.data = PORT_NS16550 },
>> +   { .compatible = "ti,omap4-uart",.data = PORT_NS16550 },
>> +   { .compatible = "ti,am3352-uart",   .data = PORT_NS16550 },
>> +   { .compatible = "ti,am4372-uart",   .data = PORT_NS16550 },
>> +   { .compatible = "ti,dra742-uart",   .data = PORT_NS16550 },
>
> But can we have 0 as the default so we don't need these values?

 PORT_NS16550 is zero anyway, it's just explicitly spelled here.
>>>
>>> One way might be to use PORT_DEFAULT, set it to 0 and omit it here. It
>>> does seem odd to have PORT_NS16550 in the ns16550 driver.
>>
>> I'd rather be explicit in case we grow this list, it also doesn't hurt
>> anything since it is implicitly set to zero. Or is this something more
>> than a matter of preference here ?
> 
> Well, at least rename the PORT value to DEFAULT or something like that
> if you want to be explicit.

Why DEFAULT ? It's NS16550 compatible port and the others are not
entirely NS16550 compatible, so I think NS16550 is exactly how it should
be named. There never was any DEFAULT label on these chips,
but the original 16550 UART chip had 16550 written on it.

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

[U-Boot] [PATCH v3] spi: Add error checking for invalid bus widths

[Simon Glass]

At present an invalid bus width prints a message but does not return an
error. This is the opposite of the correct behaviour. Adjust it to avoid
code bloat in the common case, and avoid hard-to-debug failure in the
uncommon case.

Signed-off-by: Simon Glass 
---

Changes in v3:
- Display an error in U-Boot proper, but then continue
- Drop patches previously applied

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

diff --git a/drivers/spi/spi-uclass.c b/drivers/spi/spi-uclass.c
index f59a701..1ab5b75 100644
--- a/drivers/spi/spi-uclass.c
+++ b/drivers/spi/spi-uclass.c
@@ -418,7 +418,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
mode |= SPI_TX_QUAD;
break;
default:
-   error("spi-tx-bus-width %d not supported\n", value);
+   warn_non_spl("spi-tx-bus-width %d not supported\n", value);
break;
}
 
@@ -433,7 +433,7 @@ int spi_slave_ofdata_to_platdata(const void *blob, int node,
mode |= SPI_RX_QUAD;
break;
default:
-   error("spi-rx-bus-width %d not supported\n", value);
+   warn_non_spl("spi-rx-bus-width %d not supported\n", value);
break;
}
 
-- 
2.8.0.rc3.226.g39d4020

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

Re: [U-Boot] [PATCH v3 0/9] From Simon:

[Simon Glass]

Hi Heiko,

On 29 November 2016 at 16:45, Heiko Stübner  wrote:
> Hi Simon,
>
> Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
>> This v3 patch is an update on Sjoerd's original v2 series from Feburary.
>> I have dealt with the changes requested at the time, and adjusted the way
>> that the speed change is handled.
>>
>> Tested on firefly-rk3288, rock2.
>
> Tested on a firefly as well. Though I get mixed results in my netboot
> environment. At 100MBit (manually limited) everything seems fine:
>
> --
> Speed: 100, full duplex
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 192.168.140.58 (269 ms)
> Using ethernet@ff29 device
> TFTP from server 192.168.140.1; our IP address is 192.168.140.58
> Filename 'hstuebner/firefly.vmlinuz'.
> Load address: 0x400
> Loading: #
>  #
>  #
>  #
>  #
>  #
>  #
>  #
>  2.9 MiB/s
> done
> Bytes transferred = 7033483 (6b528b hex)
> --
>
> 5 out of 5 boots worked fine.
>
>
> but at 1000MHz I only get:
>
> --
> Speed: 1000, full duplex
> BOOTP broadcast 1
> BOOTP broadcast 2
> DHCP client bound to address 192.168.140.57 (270 ms)
> Using ethernet@ff29 device
> TFTP from server 192.168.140.1; our IP address is 192.168.140.57
> Filename 'hstuebner/firefly.vmlinuz'.
> Load address: 0x400
> Loading: #T #T #T ##T T #T #T T T #T 
> Retry count exceeded; starting again
> --
>
> on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown reason.
> I'm not sure if just my switch is some special snowflake (TL-SG1024 from TP-
> Link) or there is some other voodoo at work here.
>
> The rootfs over nfs seems to work fine on 1000MBit though.

Yes I see some timeouts, although I don't think it is anything to do
with the driver conversion. Or does this not happen unless my patches
are applied?


>
>
> Heiko
>
[..]

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

Re: [U-Boot] [coreboot] Any one have a experence the coreboot with u-boot?

[Simon Glass]

+U-Boot and Bin

On 29 November 2016 at 15:25, Julius Werner  wrote:
> edit: forgot the mailing list
>
> On Tue, Nov 29, 2016 at 2:24 PM, Julius Werner  wrote:
>> +Simon who maintains the U-Boot x86 port and might be interested
>>
>> In general, this sounds like a U-Boot problem more than a coreboot
>> problem (since you're clearly getting into U-Boot code execution), and
>> you'd probably have better luck asking on the U-Boot mailing lists for
>> help.
>>
>> On Mon, Nov 28, 2016 at 12:22 AM, 김유석  wrote:
>>> Dear Sir.
>>>
>>> My env is see below.
>>>
>>>   board : Intel rangeley MOHON PEAK.(CPU is C2358)
>>>
>>>
>>> I was success boot coreboot + SeaBIOS.
>>>
>>> This time, I'm try to boot coreboot + u-boot(16.05).
>>>
>>> But u-boot is every time fail. log is see below.
>>>
>>>
>>>   U-Boot 2016.05-rc3 (Nov 28 2016 - 17:04:31 +0900)
>>>
>>>   CPU: x86_64, vendor Intel, device 406d8h
>>>   DRAM:  4 GiB
>>>
>>>   dm_pci_hose_probe_bus: Internal error, bus 'pch@1,0' got seq 0, expected 1

This says that U-Boot is scanning a bridge and expects to to be bus
number 1, but it is bus number 0. I'm not quite sure how this can
happen. Try 'dm tree' to list the devices. Or put a call to
dm_dump_all() in dm_pci_hose_probe_bus().

>>>   Using default environment
>>>
>>>   Video: No video mode configured in coreboot!

This is because you need to enable the display in coreboot (if you want to).

>>>   Model: QEMU x86 (I440FX)

Here you are using the qemu board. You might want to create a new
device tree file. If you see qemu-x86_i440fx.dts you may need to
change the PCH address?

>>>
>>>   dm_pci_hose_probe_bus: Internal error, bus 'pch@1,0' got seq 0, expected 1
>>>   initcall sequence 7fc59100 failed at call 01110185 (err=-32)
>>>   ### ERROR ### Please RESET the board ###

You can use:

   grep 7fc59100 System.map

to find the function that is failing. But I'm pretty sure it is
because of the PCI problem, since it returns -EPIPE.

>>>
>>>
>>> Every time occured fail on the interrupt_init().
>>>
>>> But I don't have a solution.
>>>
>>>
>>> I was attached the config of corebooe and u-boot.
>>>
>>>
>>> Please advise to me.

Can you explain why you are using coreboot first? Is it because you
don't want to support this platform on U-Boot? It would be more work,
at least unless you have an FSP.

I talked with one of the coreboot guys about setting up a U-Boot
config that reads everything it needs from coreboot, instead of
requiring its own configuration. Then we would not have these
problems. However I haven't actually worked on this as I don't
actually have a board that fails...maybe soon.

>>>
>>>
>>> Thank you.


Regards,
Simon

>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> coreboot mailing list: coreb...@coreboot.org
>>> https://www.coreboot.org/mailman/listinfo/coreboot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 07/14] mmc: Tinification of the mmc code

[Tom Rini]

On Tue, Nov 29, 2016 at 07:26:55PM -0700, Simon Glass wrote:
> Hi Marek,
> 
> On 29 November 2016 at 18:28, Marek Vasut  wrote:
> > On 11/30/2016 01:32 AM, Simon Glass wrote:
> >> Hi Marek,
> >>
> >> On 25 November 2016 at 15:32, Marek Vasut  wrote:
> >>> Add new configuration option CONFIG_MMC_TINY which strips away all
> >>> memory allocation within the MMC code and code for handling multiple
> >>> cards. This allows extremely space-constrained SPL code use the MMC
> >>> framework.
> >>>
> >>> Signed-off-by: Marek Vasut 
> >>> Cc: Tom Rini 
> >>> Cc: Simon Glass 
> >>> ---
> >>> V2: Switch the MMC_TINY option to Kconfig
> >>> ---
> >>>  common/spl/spl_mmc.c |  6 +-
> >>>  drivers/mmc/Kconfig  | 16 
> >>>  drivers/mmc/mmc.c| 31 ++-
> >>>  drivers/mmc/mmc_legacy.c | 32 
> >>>  include/mmc.h|  1 +
> >>>  5 files changed, 84 insertions(+), 2 deletions(-)
> >>
> >> Reviewed-by: Simon Glass 
> >>
> >> nit below.
> >>
> >> I assume this does not use DM?
> >
> > Nope, DM does not fit into those 14 kiB I have for SPL, no way.
> >
> >>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> >>> index 43c1030..3cad998 100644
> >>> --- a/common/spl/spl_mmc.c
> >>> +++ b/common/spl/spl_mmc.c
> >>> @@ -306,7 +306,11 @@ static int spl_mmc_load_image(struct spl_image_info 
> >>> *spl_image,
> >>> if (part == 7)
> >>> part = 0;
> >>>
> >>> -   err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), 
> >>> part);
> >>> +   if (CONFIG_IS_ENABLED(MMC_TINY))
> >>> +   err = mmc_switch_part(mmc, part);
> >>> +   else
> >>> +   err = 
> >>> blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
> >>> +
> >>> if (err) {
> >>>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> >>> puts("spl: mmc partition switch 
> >>> failed\n");
> >>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> >>> index 24f4b28..aca438b8 100644
> >>> --- a/drivers/mmc/Kconfig
> >>> +++ b/drivers/mmc/Kconfig
> >>> @@ -26,6 +26,22 @@ config DM_MMC_OPS
> >>>   option will be removed as soon as all DM_MMC drivers use it, as 
> >>> it
> >>>   will the only supported behaviour.
> >>>
> >>> +config SPL_MMC_TINY
> >>> +   bool "Tiny MMC framework in SPL"
> >>> +   default n
> >>
> >> Not needed?
> >
> > Why not ? This makes the tinification configurable and is used on the
> > CI20 (JZ4780 horrorchip).
> 
> Well it should default to n anyway so I don't think you need that line.

To be clear, there's a lot of "default n" which isn't needed, but I
hadn't publicly said anything about, but yes, we should stop adding
that line as it is the normal default.

-- 
Tom


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

Re: [U-Boot] [PATCH] dm: core: Add dev_get_addr_size_index() to retrieve addr and size

[Simon Glass]

Hi Stefan,

On 28 November 2016 at 02:46, Stefan Roese  wrote:
> The currently available functions accessing the 'reg' property of a
> device only retrieve the address. Sometimes its also necessary to
> retrieve the size described by the 'reg' property. This patch adds
> the new function dev_get_addr_size_index() which retrieves both,
> the address and the size described by the 'reg' property.
>
> Signed-off-by: Stefan Roese 
> Cc: Simon Glass 
> ---
>  drivers/core/device.c | 22 ++
>  include/dm/device.h   | 16 
>  2 files changed, 38 insertions(+)
>
> diff --git a/drivers/core/device.c b/drivers/core/device.c
> index dcf5d9d..ec43654 100644
> --- a/drivers/core/device.c
> +++ b/drivers/core/device.c
> @@ -693,6 +693,28 @@ fdt_addr_t dev_get_addr_index(struct udevice *dev, int 
> index)
>  #endif
>  }
>
> +fdt_addr_t dev_get_addr_size_index(struct udevice *dev, int index,
> +  fdt_size_t *size)
> +{
> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> +   /*
> +* Only get the size in this first call. We'll get the addr in the
> +* next call to the exisiting dev_get_xxx function which handles
> +* all config options.
> +*/
> +   fdtdec_get_addr_size_auto_noparent(gd->fdt_blob, dev->of_offset,
> +  "reg", 1, size, false);

Does this take account of 'index'?

> +
> +   /*
> +* Get the base address via the existing function which handles
> +* all Kconfig cases
> +*/
> +   return dev_get_addr_index(dev, index);
> +#else
> +   return FDT_ADDR_T_NONE;
> +#endif
> +}
> +
>  fdt_addr_t dev_get_addr_name(struct udevice *dev, const char *name)
>  {
>  #if CONFIG_IS_ENABLED(OF_CONTROL)
> diff --git a/include/dm/device.h b/include/dm/device.h
> index babf8ac..9948bd4 100644
> --- a/include/dm/device.h
> +++ b/include/dm/device.h
> @@ -497,6 +497,22 @@ void *dev_map_physmem(struct udevice *dev, unsigned long 
> size);
>  fdt_addr_t dev_get_addr_index(struct udevice *dev, int index);
>
>  /**
> + * dev_get_addr_size_index() - Get the indexed reg property of a device
> + *
> + * Returns the address and size specified in the 'reg' property of a device.
> + *
> + * @dev: Pointer to a device
> + * @index: the 'reg' property can hold a list of  pairs
> + *and @index is used to select which one is required
> + * @size: Pointer to size varible - this function returns the size
> + *specified in the 'reg' property here
> + *
> + * @return addr
> + */
> +fdt_addr_t dev_get_addr_size_index(struct udevice *dev, int index,
> +  fdt_size_t *size);
> +
> +/**
>   * dev_get_addr_name() - Get the reg property of a device, indexed by name
>   *
>   * @dev: Pointer to a device
> --
> 2.10.2
>

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

Re: [U-Boot] [PATCH resend v3 0/6] DM conversion of usb ether gadget

[Simon Glass]

Hi Lucasz,

On 17 November 2016 at 22:19, Mugunthan V N  wrote:
> The previous series didn't land on the mailing list properly, so
> resending the series as *v3 resend*, sorry for spamming.
>
> This patch series adopts driver model for usb ether gadget
> driver. This series is tested with MUSB driver model conversion
> on AM335x GP evm and AM335x BBB (logs [1]).
>
> Also pushed a branch for testing [2]
>
> Changes from v2:
> * Moved USB ether address from driver hard code to Kconfig entry
> * Optimized if check in patch 5/6 as mentioned by Marek Vasut.
>
> Changes from initial version:
> * Separated out the usb gadget driver patches from earlier musb
>   series [3] for testing and submitting of dwc3 dm musb patches.
>
> [1] - http://pastebin.ubuntu.com/23489333/
> [2] - git://git.ti.com/~mugunthanvnm/ti-u-boot/mugunth-ti-u-boot.git 
> dm-musb-v3
> [3] - http://lists.denx.de/pipermail/u-boot/2016-February/246827.html
>
> Note:
> ~
> The following checkpatch warning can be ignored as this has to be
> fixed all over the file which should be a separate patch.
> CHECK: Avoid CamelCase: 
> #297: FILE: drivers/usb/gadget/rndis.c:1157:
> +int  rndis_set_param_dev(u8 configNr, struct eth_device *dev, int mtu,
>
> Mugunthan V N (6):
>   drivers: usb: gadget: ether: adopt to usb driver model
>   drivers: usb: gadget: ether: access network_started using local
> variable
>   drivers: usb: gadget: ether: consolidate global devices to single
> struct
>   drivers: usb: gadget: ether: use net device priv to pass usb ether
> priv
>   drivers: usb: gadget: ether: prepare driver for driver model migration
>   drivers: usb: gadget: ether/rndis: convert driver to adopt device
> driver model
>
>  drivers/usb/gadget/Kconfig |   4 +
>  drivers/usb/gadget/ether.c | 315 
> -
>  drivers/usb/gadget/rndis.c |  13 +-
>  drivers/usb/gadget/rndis.h |  19 ++-
>  include/net.h  |   7 +
>  5 files changed, 293 insertions(+), 65 deletions(-)
>
> --
> 2.11.0.rc2
>

This series is assigned to me in patchwork. Are you OK with it? I plan
to bring it in via DM.

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

Re: [U-Boot] [PATCH v6 00/13] binman: A tool for creating firmware images

[Simon Glass]

Hi Bin,

On 25 November 2016 at 20:15, Simon Glass  wrote:
> This series introduces binman, a tool designed to create firmware images.
> It provides a way to bring together various binaries and place them in an
> image, at particular positions and with configurable alignment.
>
> Packaging of firmware is quite a different task from building the various
> parts. In many cases the various binaries which go into the image come from
> separate build systems. For example, ARM Trusted Firmware is used on ARMv8
> devices but is not built in the U-Boot tree. If a Linux kernel is included
> in the firmware image, it is built elsewhere.
>
> It is of course possible to add more and more build rules to the U-Boot
> build system to cover these cases. It can shell out to other Makefiles and
> build scripts. But it seems better to create a clear divide between building
> software and packaging it.
>
> U-Boot supports a very large number of boards. Many of these have their own
> specific rules for how an image should be put together so that it boots
> correctly. At present these rules are described by manual instructions,
> different for each board. By turning these instructions into a standard
> format, we can support making valid images for any board without manual
> effort, lots of READMEs, etc.
>
> Images consist of a number of entries which are combined to make up the
> final image. The image is described in the device tree for the board, meaning
> that it can be accessed at run-time if desired.
>
> Binman is an extensible tool. A set of standard entries is provides, but
> new entries can be created fairly easily. Entries can be as simple as
> providing the name of a file to include. They can also handle more complex
> requirements, such as adjusting the input file or reading header information
> from one entry to control the position of another.
>
> U-Boot's mkimage builds FIT images and various other binaries. Binman
> augments this by allowing these binaries to be packed together. While FIT
> should be used where possible, it cannot be used everywhere. For example,
> many devices require executable code at a particular offset in the image.
> X86 machines require lots of binary blobs at particular places, and a
> microcode collection easily accessible at boot.
>
> So far binman has enough functionality to be useful, so sunxi and x86 boards
> are switched over to use it, as examples.
>
> The series is available at u-boot-dm/binman-working
>
> Future work and missing features are documented in the README.
>
> Changes in v6:
> - Deal with optional microcode in SPL
> - Drop unwanted root-node properties from tegra20-u-boot.dtsi
> - Use __import__() when importlib is not available

Does this work OK for you now?

[...]

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

Re: [U-Boot] [PATCH 07/14] mmc: Tinification of the mmc code

[Simon Glass]

Hi Marek,

On 29 November 2016 at 18:28, Marek Vasut  wrote:
> On 11/30/2016 01:32 AM, Simon Glass wrote:
>> Hi Marek,
>>
>> On 25 November 2016 at 15:32, Marek Vasut  wrote:
>>> Add new configuration option CONFIG_MMC_TINY which strips away all
>>> memory allocation within the MMC code and code for handling multiple
>>> cards. This allows extremely space-constrained SPL code use the MMC
>>> framework.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Tom Rini 
>>> Cc: Simon Glass 
>>> ---
>>> V2: Switch the MMC_TINY option to Kconfig
>>> ---
>>>  common/spl/spl_mmc.c |  6 +-
>>>  drivers/mmc/Kconfig  | 16 
>>>  drivers/mmc/mmc.c| 31 ++-
>>>  drivers/mmc/mmc_legacy.c | 32 
>>>  include/mmc.h|  1 +
>>>  5 files changed, 84 insertions(+), 2 deletions(-)
>>
>> Reviewed-by: Simon Glass 
>>
>> nit below.
>>
>> I assume this does not use DM?
>
> Nope, DM does not fit into those 14 kiB I have for SPL, no way.
>
>>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
>>> index 43c1030..3cad998 100644
>>> --- a/common/spl/spl_mmc.c
>>> +++ b/common/spl/spl_mmc.c
>>> @@ -306,7 +306,11 @@ static int spl_mmc_load_image(struct spl_image_info 
>>> *spl_image,
>>> if (part == 7)
>>> part = 0;
>>>
>>> -   err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), 
>>> part);
>>> +   if (CONFIG_IS_ENABLED(MMC_TINY))
>>> +   err = mmc_switch_part(mmc, part);
>>> +   else
>>> +   err = 
>>> blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
>>> +
>>> if (err) {
>>>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>>> puts("spl: mmc partition switch failed\n");
>>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>>> index 24f4b28..aca438b8 100644
>>> --- a/drivers/mmc/Kconfig
>>> +++ b/drivers/mmc/Kconfig
>>> @@ -26,6 +26,22 @@ config DM_MMC_OPS
>>>   option will be removed as soon as all DM_MMC drivers use it, as it
>>>   will the only supported behaviour.
>>>
>>> +config SPL_MMC_TINY
>>> +   bool "Tiny MMC framework in SPL"
>>> +   default n
>>
>> Not needed?
>
> Why not ? This makes the tinification configurable and is used on the
> CI20 (JZ4780 horrorchip).

Well it should default to n anyway so I don't think you need that line.

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

Re: [U-Boot] [PATCH 05/14] serial: 16550: Add port type as driver data

[Simon Glass]

Hi Marek,

On 29 November 2016 at 18:27, Marek Vasut  wrote:
> On 11/30/2016 01:32 AM, Simon Glass wrote:
>> Hi Marek,
>>
>> On 27 November 2016 at 10:07, Marek Vasut  wrote:
>>> On 11/27/2016 06:03 PM, Simon Glass wrote:
 Hi Marex,

 On 25 November 2016 at 15:32, Marek Vasut  wrote:
> Add driver data to each compatible string to identify the type of
> the port. Since all the ports in the driver are entirely compatible
> with 16550 for now, all are marked with PORT_NS16550. But, there
> are ports which have specific quirks, like the JZ4780 UART, which
> do not have any DT property to denote the quirks. Instead, Linux
> uses the compatible string to discern such ports and enable the
> necessary quirks.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
>  drivers/serial/ns16550.c | 26 --
>  1 file changed, 16 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
> index 3c9f3b0..3130a1d 100644
> --- a/drivers/serial/ns16550.c
> +++ b/drivers/serial/ns16550.c
> @@ -360,6 +360,12 @@ int ns16550_serial_probe(struct udevice *dev)
> return 0;
>  }
>
> +#if CONFIG_IS_ENABLED(OF_CONTROL)
> +enum {
> +   PORT_NS16550 = 0,
> +};
> +#endif
> +
>  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>  int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
>  {
> @@ -453,16 +459,16 @@ const struct dm_serial_ops ns16550_serial_ops = {
>   * compatible string to your dts.
>   */
>  static const struct udevice_id ns16550_serial_ids[] = {
> -   { .compatible = "ns16550" },
> -   { .compatible = "ns16550a" },
> -   { .compatible = "nvidia,tegra20-uart" },
> -   { .compatible = "snps,dw-apb-uart" },
> -   { .compatible = "ti,omap2-uart" },
> -   { .compatible = "ti,omap3-uart" },
> -   { .compatible = "ti,omap4-uart" },
> -   { .compatible = "ti,am3352-uart" },
> -   { .compatible = "ti,am4372-uart" },
> -   { .compatible = "ti,dra742-uart" },
> +   { .compatible = "ns16550",  .data = PORT_NS16550 },
> +   { .compatible = "ns16550a", .data = PORT_NS16550 },
> +   { .compatible = "nvidia,tegra20-uart",  .data = PORT_NS16550 },
> +   { .compatible = "snps,dw-apb-uart", .data = PORT_NS16550 },
> +   { .compatible = "ti,omap2-uart",.data = PORT_NS16550 },
> +   { .compatible = "ti,omap3-uart",.data = PORT_NS16550 },
> +   { .compatible = "ti,omap4-uart",.data = PORT_NS16550 },
> +   { .compatible = "ti,am3352-uart",   .data = PORT_NS16550 },
> +   { .compatible = "ti,am4372-uart",   .data = PORT_NS16550 },
> +   { .compatible = "ti,dra742-uart",   .data = PORT_NS16550 },

 But can we have 0 as the default so we don't need these values?
>>>
>>> PORT_NS16550 is zero anyway, it's just explicitly spelled here.
>>
>> One way might be to use PORT_DEFAULT, set it to 0 and omit it here. It
>> does seem odd to have PORT_NS16550 in the ns16550 driver.
>
> I'd rather be explicit in case we grow this list, it also doesn't hurt
> anything since it is implicitly set to zero. Or is this something more
> than a matter of preference here ?

Well, at least rename the PORT value to DEFAULT or something like that
if you want to be explicit.

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

Re: [U-Boot] [PATCH v2 1/4] usb: dwc2: add support for external vbus supply

[Marek Vasut]

On 11/29/2016 09:46 AM, Kever Yang wrote:
> Hi Marek,
> 
> On 11/26/2016 12:46 AM, Marek Vasut wrote:
>> On 11/24/2016 08:29 AM, Kever Yang wrote:
>>> Some board do not use the dwc2 internal VBUS_DRV signal, but
>>> use a gpio pin to enable the 5.0V VBUS power, add interface to
>>> enable the power in dwc2 driver.
>>>
>>> Signed-off-by: Kever Yang 
>>> ---
>>>
>>> Changes in v2: None
>>>
>>>   drivers/usb/host/dwc2.c | 29 +
>>>   1 file changed, 29 insertions(+)
>>>
>>> diff --git a/drivers/usb/host/dwc2.c b/drivers/usb/host/dwc2.c
>>> index d08879d..8292aa8 100644
>>> --- a/drivers/usb/host/dwc2.c
>>> +++ b/drivers/usb/host/dwc2.c
>>> @@ -15,6 +15,7 @@
>>>   #include 
>>>   #include 
>>>   #include 
>>> +#include 
>>> #include "dwc2.h"
>>>   @@ -55,6 +56,8 @@ DEFINE_ALIGN_BUFFER(uint8_t, status_buffer_addr,
>>> DWC2_STATUS_BUF_SIZE,
>>>   static struct dwc2_priv local;
>>>   #endif
>>>   +static struct udevice *g_dwc2_udev;
>> Can we avoid the static global var ?
> 
> I don't want to use this global var either, but I don't know how to get
> this udev structure
> without this var, do you have any good suggestion?
> BTW, of_container() is not available to find the udevice structure with
> dwc2_priv pointer.

But you can ie. store the udevice in priv ? Simon , any hints ?

>>
>>> +
>>>   /*
>>>* DWC2 IP interface
>>>*/
>>> @@ -159,6 +162,29 @@ static void dwc_otg_core_reset(struct
>>> dwc2_core_regs *regs)
>>>   mdelay(100);
>>>   }
>>>   +static int dwc_vbus_supply_init(void)
>>> +{
>>> +#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR) && \
>>> +!defined(CONFIG_SPL_BUILD)
>> Why does this not work for SPL ?
> 
> We do not enable the USB driver in SPL, in this case I can just drop the
> CONFIG_SPL_BUILD
> because the driver in not compiled in SPL.

Correct

>> btw, I'd rather see this as:
>>
>> #if FOO
>> function bar()
>> {
>>   ...
>> }
>> #else
>> static inline function bar()
>> {
>>   return 0;
>> }
>> #endif
>>
>>> +struct udevice *vbus_supply;
>>> +int ret;
>>> +
>>> +ret = device_get_supply_regulator(g_dwc2_udev, "vbus-supply",
>>> +  _supply);
>> Is this compatible with the Linux DWC2 DT bindings ?
> 
> This compatible in kernel is in in phy dts node, the dwc2 driver and phy
> driver
> in U-Boot are both very different from kernel now, so I chose a place
> which is
> reasonable to enable the vbus.

DT is driver and OS agnostic, so if there is already agreed-upon binding
for specifying external VBUS to DWC2, we should use it.
Why would that be a problem ?

>>> +if (ret) {
>>> +debug("%s: No vbus supply\n", g_dwc2_udev->name);
>>> +return 0;
>>> +}
>>> +
>>> +ret = regulator_set_enable(vbus_supply, true);
>> Shouldn't the regulator be enabled when we enable VBUS for a port
>> instead of here ? And where is it disabled ?
> 
> I add this function just after the controller enable the port power bit,
> isn't it?
> I didn't found anywhere the driver disable the vbus power, we do not
> need it
> in U-Boot?

So we leave it enabled and pass the hardware to kernel in some weird
state ? That's a bit odd, isn't it. dwc2_lowlevel_stop() might be a
good place to disable the regulator ...

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

Re: [U-Boot] [PATCH 07/14] mmc: Tinification of the mmc code

[Marek Vasut]

On 11/30/2016 01:32 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 25 November 2016 at 15:32, Marek Vasut  wrote:
>> Add new configuration option CONFIG_MMC_TINY which strips away all
>> memory allocation within the MMC code and code for handling multiple
>> cards. This allows extremely space-constrained SPL code use the MMC
>> framework.
>>
>> Signed-off-by: Marek Vasut 
>> Cc: Tom Rini 
>> Cc: Simon Glass 
>> ---
>> V2: Switch the MMC_TINY option to Kconfig
>> ---
>>  common/spl/spl_mmc.c |  6 +-
>>  drivers/mmc/Kconfig  | 16 
>>  drivers/mmc/mmc.c| 31 ++-
>>  drivers/mmc/mmc_legacy.c | 32 
>>  include/mmc.h|  1 +
>>  5 files changed, 84 insertions(+), 2 deletions(-)
> 
> Reviewed-by: Simon Glass 
> 
> nit below.
> 
> I assume this does not use DM?

Nope, DM does not fit into those 14 kiB I have for SPL, no way.

>> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
>> index 43c1030..3cad998 100644
>> --- a/common/spl/spl_mmc.c
>> +++ b/common/spl/spl_mmc.c
>> @@ -306,7 +306,11 @@ static int spl_mmc_load_image(struct spl_image_info 
>> *spl_image,
>> if (part == 7)
>> part = 0;
>>
>> -   err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), 
>> part);
>> +   if (CONFIG_IS_ENABLED(MMC_TINY))
>> +   err = mmc_switch_part(mmc, part);
>> +   else
>> +   err = 
>> blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
>> +
>> if (err) {
>>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>> puts("spl: mmc partition switch failed\n");
>> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
>> index 24f4b28..aca438b8 100644
>> --- a/drivers/mmc/Kconfig
>> +++ b/drivers/mmc/Kconfig
>> @@ -26,6 +26,22 @@ config DM_MMC_OPS
>>   option will be removed as soon as all DM_MMC drivers use it, as it
>>   will the only supported behaviour.
>>
>> +config SPL_MMC_TINY
>> +   bool "Tiny MMC framework in SPL"
>> +   default n
> 
> Not needed?

Why not ? This makes the tinification configurable and is used on the
CI20 (JZ4780 horrorchip).

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

Re: [U-Boot] [PATCH 05/14] serial: 16550: Add port type as driver data

[Marek Vasut]

On 11/30/2016 01:32 AM, Simon Glass wrote:
> Hi Marek,
> 
> On 27 November 2016 at 10:07, Marek Vasut  wrote:
>> On 11/27/2016 06:03 PM, Simon Glass wrote:
>>> Hi Marex,
>>>
>>> On 25 November 2016 at 15:32, Marek Vasut  wrote:
 Add driver data to each compatible string to identify the type of
 the port. Since all the ports in the driver are entirely compatible
 with 16550 for now, all are marked with PORT_NS16550. But, there
 are ports which have specific quirks, like the JZ4780 UART, which
 do not have any DT property to denote the quirks. Instead, Linux
 uses the compatible string to discern such ports and enable the
 necessary quirks.

 Signed-off-by: Marek Vasut 
 Cc: Tom Rini 
 Cc: Simon Glass 
 ---
  drivers/serial/ns16550.c | 26 --
  1 file changed, 16 insertions(+), 10 deletions(-)

 diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
 index 3c9f3b0..3130a1d 100644
 --- a/drivers/serial/ns16550.c
 +++ b/drivers/serial/ns16550.c
 @@ -360,6 +360,12 @@ int ns16550_serial_probe(struct udevice *dev)
 return 0;
  }

 +#if CONFIG_IS_ENABLED(OF_CONTROL)
 +enum {
 +   PORT_NS16550 = 0,
 +};
 +#endif
 +
  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
  int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
  {
 @@ -453,16 +459,16 @@ const struct dm_serial_ops ns16550_serial_ops = {
   * compatible string to your dts.
   */
  static const struct udevice_id ns16550_serial_ids[] = {
 -   { .compatible = "ns16550" },
 -   { .compatible = "ns16550a" },
 -   { .compatible = "nvidia,tegra20-uart" },
 -   { .compatible = "snps,dw-apb-uart" },
 -   { .compatible = "ti,omap2-uart" },
 -   { .compatible = "ti,omap3-uart" },
 -   { .compatible = "ti,omap4-uart" },
 -   { .compatible = "ti,am3352-uart" },
 -   { .compatible = "ti,am4372-uart" },
 -   { .compatible = "ti,dra742-uart" },
 +   { .compatible = "ns16550",  .data = PORT_NS16550 },
 +   { .compatible = "ns16550a", .data = PORT_NS16550 },
 +   { .compatible = "nvidia,tegra20-uart",  .data = PORT_NS16550 },
 +   { .compatible = "snps,dw-apb-uart", .data = PORT_NS16550 },
 +   { .compatible = "ti,omap2-uart",.data = PORT_NS16550 },
 +   { .compatible = "ti,omap3-uart",.data = PORT_NS16550 },
 +   { .compatible = "ti,omap4-uart",.data = PORT_NS16550 },
 +   { .compatible = "ti,am3352-uart",   .data = PORT_NS16550 },
 +   { .compatible = "ti,am4372-uart",   .data = PORT_NS16550 },
 +   { .compatible = "ti,dra742-uart",   .data = PORT_NS16550 },
>>>
>>> But can we have 0 as the default so we don't need these values?
>>
>> PORT_NS16550 is zero anyway, it's just explicitly spelled here.
> 
> One way might be to use PORT_DEFAULT, set it to 0 and omit it here. It
> does seem odd to have PORT_NS16550 in the ns16550 driver.

I'd rather be explicit in case we grow this list, it also doesn't hurt
anything since it is implicitly set to zero. Or is this something more
than a matter of preference here ?

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

Re: [U-Boot] [PATCH v3 1/9] ARM: DTS: stm32: add stm32f746 device tree pin control files

[Vikas MANOCHA]

Hi Michael,

> -Original Message-
> From: Michael Kurz [mailto:michi.k...@gmail.com]
> Sent: Thursday, November 24, 2016 11:11 AM
> To: u-boot@lists.denx.de
> Cc: Michael Kurz ; Albert Aribaud 
> ; Vikas MANOCHA 
> Subject: [PATCH v3 1/9] ARM: DTS: stm32: add stm32f746 device tree pin 
> control files
>
> This patch adds pin control definitions for use in device tree files
> The definitions are based on the stm32f429/469 files from current
> linux kernel.

These definitions are based on stm32f746 pin control binding, please correct 
the commit message.
Also add the source of this file (which is 
"include/dt-bindings/pinctrl/stm32f746-pinfunc.h"), it would help to keep the 
file in sync.
I will review rest of the patches of the series also this week.

Cheers,
Vikas

>
> Signed-off-by: Michael Kurz 
> Acked-by: Vikas MANOCHA 
>
> ---
>
> Changes in v3:
> - Split pin control files of from device tree patch
> - Add Acked-by tag to 'add stm32f746 device tree pin control files'
>
> Changes in v2: None
>
>  include/dt-bindings/pinctrl/stm32f746-pinfunc.h | 1324 
> +++
>  1 file changed, 1324 insertions(+)
>  create mode 100644 include/dt-bindings/pinctrl/stm32f746-pinfunc.h
>
> diff --git a/include/dt-bindings/pinctrl/stm32f746-pinfunc.h 
> b/include/dt-bindings/pinctrl/stm32f746-pinfunc.h
> new file mode 100644
> index 000..6348c6a
> --- /dev/null
> +++ b/include/dt-bindings/pinctrl/stm32f746-pinfunc.h
> @@ -0,0 +1,1324 @@
> +#ifndef _DT_BINDINGS_STM32F746_PINFUNC_H
> +#define _DT_BINDINGS_STM32F746_PINFUNC_H
> +
> +#define STM32F746_PA0_FUNC_GPIO 0x0
> +#define STM32F746_PA0_FUNC_TIM2_CH1_TIM2_ETR 0x2
> +#define STM32F746_PA0_FUNC_TIM5_CH1 0x3
> +#define STM32F746_PA0_FUNC_TIM8_ETR 0x4
> +#define STM32F746_PA0_FUNC_USART2_CTS 0x8
> +#define STM32F746_PA0_FUNC_UART4_TX 0x9
> +#define STM32F746_PA0_FUNC_SAI2_SD_B 0xb
> +#define STM32F746_PA0_FUNC_ETH_MII_CRS 0xc
> +#define STM32F746_PA0_FUNC_EVENTOUT 0x10
> +#define STM32F746_PA0_FUNC_ANALOG 0x11
> +
> +#define STM32F746_PA1_FUNC_GPIO 0x100
> +#define STM32F746_PA1_FUNC_TIM2_CH2 0x102
> +#define STM32F746_PA1_FUNC_TIM5_CH2 0x103
> +#define STM32F746_PA1_FUNC_USART2_RTS 0x108
> +#define STM32F746_PA1_FUNC_UART4_RX 0x109
> +#define STM32F746_PA1_FUNC_QUADSPI_BK1_IO3 0x10a
> +#define STM32F746_PA1_FUNC_SAI2_MCLK_B 0x10b
> +#define STM32F746_PA1_FUNC_ETH_MII_RX_CLK_ETH_RMII_REF_CLK 0x10c
> +#define STM32F746_PA1_FUNC_LCD_R2 0x10f
> +#define STM32F746_PA1_FUNC_EVENTOUT 0x110
> +#define STM32F746_PA1_FUNC_ANALOG 0x111
> +
> +#define STM32F746_PA2_FUNC_GPIO 0x200
> +#define STM32F746_PA2_FUNC_TIM2_CH3 0x202
> +#define STM32F746_PA2_FUNC_TIM5_CH3 0x203
> +#define STM32F746_PA2_FUNC_TIM9_CH1 0x204
> +#define STM32F746_PA2_FUNC_USART2_TX 0x208
> +#define STM32F746_PA2_FUNC_SAI2_SCK_B 0x209
> +#define STM32F746_PA2_FUNC_ETH_MDIO 0x20c
> +#define STM32F746_PA2_FUNC_LCD_R1 0x20f
> +#define STM32F746_PA2_FUNC_EVENTOUT 0x210
> +#define STM32F746_PA2_FUNC_ANALOG 0x211
> +
> +#define STM32F746_PA3_FUNC_GPIO 0x300
> +#define STM32F746_PA3_FUNC_TIM2_CH4 0x302
> +#define STM32F746_PA3_FUNC_TIM5_CH4 0x303
> +#define STM32F746_PA3_FUNC_TIM9_CH2 0x304
> +#define STM32F746_PA3_FUNC_USART2_RX 0x308
> +#define STM32F746_PA3_FUNC_OTG_HS_ULPI_D0 0x30b
> +#define STM32F746_PA3_FUNC_ETH_MII_COL 0x30c
> +#define STM32F746_PA3_FUNC_LCD_B5 0x30f
> +#define STM32F746_PA3_FUNC_EVENTOUT 0x310
> +#define STM32F746_PA3_FUNC_ANALOG 0x311
> +
> +#define STM32F746_PA4_FUNC_GPIO 0x400
> +#define STM32F746_PA4_FUNC_SPI1_NSS_I2S1_WS 0x406
> +#define STM32F746_PA4_FUNC_SPI3_NSS_I2S3_WS 0x407
> +#define STM32F746_PA4_FUNC_USART2_CK 0x408
> +#define STM32F746_PA4_FUNC_OTG_HS_SOF 0x40d
> +#define STM32F746_PA4_FUNC_DCMI_HSYNC 0x40e
> +#define STM32F746_PA4_FUNC_LCD_VSYNC 0x40f
> +#define STM32F746_PA4_FUNC_EVENTOUT 0x410
> +#define STM32F746_PA4_FUNC_ANALOG 0x411
> +
> +#define STM32F746_PA5_FUNC_GPIO 0x500
> +#define STM32F746_PA5_FUNC_TIM2_CH1_TIM2_ETR 0x502
> +#define STM32F746_PA5_FUNC_TIM8_CH1N 0x504
> +#define STM32F746_PA5_FUNC_SPI1_SCK_I2S1_CK 0x506
> +#define STM32F746_PA5_FUNC_OTG_HS_ULPI_CK 0x50b
> +#define STM32F746_PA5_FUNC_LCD_R4 0x50f
> +#define STM32F746_PA5_FUNC_EVENTOUT 0x510
> +#define STM32F746_PA5_FUNC_ANALOG 0x511
> +
> +#define STM32F746_PA6_FUNC_GPIO 0x600
> +#define STM32F746_PA6_FUNC_TIM1_BKIN 0x602
> +#define STM32F746_PA6_FUNC_TIM3_CH1 0x603
> +#define STM32F746_PA6_FUNC_TIM8_BKIN 0x604
> +#define STM32F746_PA6_FUNC_SPI1_MISO 0x606
> +#define STM32F746_PA6_FUNC_TIM13_CH1 0x60a
> +#define STM32F746_PA6_FUNC_DCMI_PIXCLK 0x60e
> +#define STM32F746_PA6_FUNC_LCD_G2 0x60f
> +#define STM32F746_PA6_FUNC_EVENTOUT 0x610
> +#define STM32F746_PA6_FUNC_ANALOG 0x611
> +
> +#define STM32F746_PA7_FUNC_GPIO 0x700
> +#define STM32F746_PA7_FUNC_TIM1_CH1N 0x702
> +#define STM32F746_PA7_FUNC_TIM3_CH2 0x703
> +#define STM32F746_PA7_FUNC_TIM8_CH1N 0x704
> 

Re: [U-Boot] [PATCH v2 2/4] board: popmetal: de-assert the host rst pin in board init

[Simon Glass]

On 29 November 2016 at 01:49, Kever Yang  wrote:
> Hi Simon,
>
>
> On 11/26/2016 03:39 AM, Simon Glass wrote:
>>
>> Hi Kever,
>>
>> On 24 November 2016 at 00:29, Kever Yang 
>> wrote:
>>>
>>> The PopMetal board have a on board FE1.1 usb 2.0 hub which connect to
>>> the usb host port, we need to de-assert its reset pin to enable it.
>>>
>>> Signed-off-by: Kever Yang 
>>> ---
>>>
>>> Changes in v2:
>>> - move the vbus power enable into dwc2 driver
>>>
>>>   board/chipspark/popmetal_rk3288/popmetal-rk3288.c | 17
>>> +
>>>   1 file changed, 17 insertions(+)
>>>
>>> diff --git a/board/chipspark/popmetal_rk3288/popmetal-rk3288.c
>>> b/board/chipspark/popmetal_rk3288/popmetal-rk3288.c
>>> index aad74ef..ed82b2b 100644
>>> --- a/board/chipspark/popmetal_rk3288/popmetal-rk3288.c
>>> +++ b/board/chipspark/popmetal_rk3288/popmetal-rk3288.c
>>> @@ -6,6 +6,7 @@
>>>
>>>   #include 
>>>   #include 
>>> +#include 
>>>
>>>   void board_boot_order(u32 *spl_boot_list)
>>>   {
>>> @@ -13,3 +14,19 @@ void board_boot_order(u32 *spl_boot_list)
>>>  spl_boot_list[0] = BOOT_DEVICE_MMC2;
>>>  spl_boot_list[1] = BOOT_DEVICE_MMC1;
>>>   }
>>> +
>>> +#define GPIO7A3_HUB_RST227
>>> +
>>> +int rk_board_late_init(void)
>>> +{
>>> +   int ret;
>>> +
>>> +   ret = gpio_request(GPIO7A3_HUB_RST, "hub_rst");
>>> +   if (ret)
>>> +   return ret;
>>> +   ret = gpio_direction_output(GPIO7A3_HUB_RST, 1);
>>> +   if (ret)
>>
>> Can we get this from the device tree instead of hard-coding it? Then
>> it can go in generic code.
>
>
> I don't understand how to get this from device tree, this board is the
> only one based on rk3288 with a USB hub on board and need the de-assert
> its reset pin. I think it is reasonable to hard coding it in its board file.

OK, since it's just one board.

Acked-by: Simon Glass 

In general we can support this sort of thing by adding a driver for
UCLASS_USB_HUB, but I suspect it would need refactoring of
common/usb.c.

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

Re: [U-Boot] [PATCH] Add RTC chip pcf2127 support

[Simon Glass]

Hi Meng,

On 28 November 2016 at 22:32, Meng Yi  wrote:
> This driver compatible with pcf2127 and pcf2129
>
> Signed-off-by: Meng Yi 
> ---
>  drivers/rtc/Makefile  |  1 +
>  drivers/rtc/pcf2127.c | 94 
> +++
>  2 files changed, 95 insertions(+)
>  create mode 100644 drivers/rtc/pcf2127.c

Please can you convert this to driver model?

See for example drivers/rtc/sandbox_rtc.c, or perhaps
drivers/rtc/mc146818.c (you can ignore all code except that used by
CONFIG_DM_RTC).

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

Re: [U-Boot] [RFC PATCH 3/3] spl: Add support for enabling dcache

[Simon Glass]

On 28 November 2016 at 02:34, Lokesh Vutla  wrote:
> Add support for enabling d-cache in SPL. The sequence in SPL tries to
> replicate the sequence done in U-Boot except that MMU entries were added
> for SRAM.
>
> Signed-off-by: Lokesh Vutla 
> ---
>  arch/arm/include/asm/cache.h |  1 +
>  arch/arm/lib/cache-cp15.c| 46 
> +++-
>  arch/arm/mach-omap2/omap-cache.c | 15 +
>  common/spl/spl.c | 40 ++
>  4 files changed, 92 insertions(+), 10 deletions(-)

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

Re: [U-Boot] [PATCH 3/4] env_sf: re-order error handling in single-buffer env_relocate_spec

[Simon Glass]

On 28 November 2016 at 03:01, Andreas Fenkart
 wrote:
> this makes it easier comparable to the double-buffered version
>
> Signed-off-by: Andreas Fenkart 
> ---
>  common/env_sf.c | 20 +++-
>  1 file changed, 11 insertions(+), 9 deletions(-)

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

Re: [U-Boot] [RFC PATCH 2/3] spl: reorder the assignment of board info to global data

[Simon Glass]

On 28 November 2016 at 02:34, Lokesh Vutla  wrote:
> Move the assignment of board info to global data a bit early which is safe,
> so that ram details can be used to enable caches.
>
> Signed-off-by: Lokesh Vutla 
> ---
>  common/spl/spl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [RESEND][PATCH 21/24] sh4: fix start.S by calling board_init_f() after first code relocation

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> Like on ARM platform keep the first code relocation from a U-boot
> image storage to RAM at CONFIG_SYS_TEXT_BASE, then pass execution to a
> generic board_init_f() with empty GD flags. If CONFIG_SYS_TEXT_BASE is
> equal to a calculated by board_init_f() relocation address there will
> be no more code and data copy, however it's worth to mention that the
> first copy happens even if $pc on _start is the same as
> CONFIG_SYS_TEXT_BASE, on practice this works without a problem.
>
> Also note that _sh_start is renamed back to _start to correct
> gd->mon_len calculation by setup_mon_len(), the opposite rename was
> done in pre-generic board commit 2024b968ee9 ("sh: Fix build in start.S").
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/sh4/start.S | 23 +++
>  1 file changed, 11 insertions(+), 12 deletions(-)

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

Re: [U-Boot] [PATCH 1/4] env_sf: factor out prepare_flash_device

[Simon Glass]

On 28 November 2016 at 03:01, Andreas Fenkart
 wrote:
> copy code found in single/double buffered code path
>
> Signed-off-by: Andreas Fenkart 
> ---
>  common/env_sf.c | 47 ++-
>  1 file changed, 18 insertions(+), 29 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 22/24] sh: share the correct version of start.S among all cpus

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> It is easy to note that SH2/SH3/SH4 start.S code is practically
> the same with a minor difference for SH2 where a short data header is
> present. To avoid unwanted code duplication and to automatically
> convert SH2 and SH3 platforms to generic board support move fixed SH4
> start.S into arch/sh/lib/start.S and share it among all platforms.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/Makefile |  2 +-
>  arch/sh/cpu/sh2/Makefile |  1 -
>  arch/sh/cpu/sh2/start.S  | 66 
> 
>  arch/sh/cpu/sh3/Makefile |  1 -
>  arch/sh/cpu/sh3/start.S  | 65 ---
>  arch/sh/cpu/sh4/Makefile |  1 -
>  arch/sh/lib/Makefile |  2 ++
>  arch/sh/{cpu/sh4 => lib}/start.S |  6 
>  8 files changed, 9 insertions(+), 135 deletions(-)
>  delete mode 100644 arch/sh/cpu/sh2/start.S
>  delete mode 100644 arch/sh/cpu/sh3/start.S
>  rename arch/sh/{cpu/sh4 => lib}/start.S (87%)

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

Re: [U-Boot] [RESEND][PATCH 20/24] sh: add shared relocate_code() function and call board_init_r()

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> Commits b61e90e6fd83 ("sh: Drop the arch-specific board init") and
> f41e6088eb1a ("sh: Fix build errors for generic board") left code and
> data relocation done in start.S, however further actual U-boot

U-Boot

> configuration is not started anymore. Practically SH boards with the
> code relocated into the expected position by start.S still can be
> booted, so the change adds this option and provides an option how to
> relocate code for board_init_r() execution.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/sh2/cpu.c |  6 --
>  arch/sh/cpu/sh3/cpu.c |  6 --
>  arch/sh/cpu/sh4/cpu.c |  6 --
>  arch/sh/lib/board.c   | 18 ++
>  4 files changed, 18 insertions(+), 18 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 17/24] sh: remove undefined DEBUG preprocessor token from board config files

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> By default this undef is a noop, moreover at this point when the
> platform support is broken is prevents debugging of U-boot by manual

U-Boot

> insertion of #define DEBUG into common files, so it makes sense to
> remove the option from all SH boards as a harmful one.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  include/configs/MigoR.h  | 1 -
>  include/configs/ap325rxa.h   | 1 -
>  include/configs/ap_sh4a_4a.h | 1 -
>  include/configs/ecovec.h | 1 -
>  include/configs/r0p7734.h| 1 -
>  include/configs/r2dplus.h| 2 --
>  include/configs/r7780mp.h| 1 -
>  include/configs/rsk7203.h| 1 -
>  include/configs/rsk7264.h| 1 -
>  include/configs/rsk7269.h| 1 -
>  include/configs/sh7752evb.h  | 1 -
>  include/configs/sh7753evb.h  | 1 -
>  include/configs/sh7757lcr.h  | 1 -
>  include/configs/sh7785lcr.h  | 1 -
>  14 files changed, 15 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 19/24] sh: add common dram_init() function for all boards

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> Generic board support assumes a different method of specifying
> DRAM size on board, also it can be shared among all boards, notably
> only sh7763rdp board has a custom legacy dram_init(), however
> the difference is only in printing some additional information,
> this feature can be removed.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/lib/Makefile   |  2 +-
>  arch/sh/lib/board.c| 17 +
>  board/alphaproject/ap_sh4a_4a/ap_sh4a_4a.c | 11 ---
>  board/espt/espt.c  | 10 --
>  board/mpr2/mpr2.c  | 10 --
>  board/ms7720se/ms7720se.c  | 10 --
>  board/ms7722se/ms7722se.c  | 10 --
>  board/ms7750se/ms7750se.c  | 10 --
>  board/renesas/MigoR/migo_r.c   | 10 --
>  board/renesas/ap325rxa/ap325rxa.c  | 10 --
>  board/renesas/ecovec/ecovec.c  | 10 --
>  board/renesas/r0p7734/r0p7734.c| 11 ---
>  board/renesas/r2dplus/r2dplus.c| 10 --
>  board/renesas/r7780mp/r7780mp.c| 10 --
>  board/renesas/rsk7203/rsk7203.c| 10 --
>  board/renesas/rsk7264/rsk7264.c| 10 --
>  board/renesas/rsk7269/rsk7269.c| 10 --
>  board/renesas/sh7752evb/sh7752evb.c| 11 ---
>  board/renesas/sh7753evb/sh7753evb.c| 11 ---
>  board/renesas/sh7757lcr/sh7757lcr.c| 25 -
>  board/renesas/sh7763rdp/sh7763rdp.c| 10 --
>  board/renesas/sh7785lcr/sh7785lcr.c| 10 --
>  board/shmin/shmin.c| 10 --
>  23 files changed, 18 insertions(+), 230 deletions(-)
>  create mode 100644 arch/sh/lib/board.c

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

Re: [U-Boot] [RESEND][PATCH 18/24] sh: define CONFIG_DISPLAY_BOARDINFO to print board information

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> All SH boards define a checkboard() function which outputs basic board
> information on boot, however generic board support requires to define
> CONFIG_DISPLAY_BOARDINFO to do that, so define it for the boards.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  include/configs/MigoR.h  | 1 +
>  include/configs/ap325rxa.h   | 1 +
>  include/configs/ap_sh4a_4a.h | 1 +
>  include/configs/ecovec.h | 1 +
>  include/configs/espt.h   | 1 +
>  include/configs/mpr2.h   | 2 ++
>  include/configs/ms7720se.h   | 1 +
>  include/configs/ms7722se.h   | 1 +
>  include/configs/ms7750se.h   | 2 ++
>  include/configs/r0p7734.h| 1 +
>  include/configs/r2dplus.h| 2 ++
>  include/configs/r7780mp.h| 2 ++
>  include/configs/rsk7203.h| 1 +
>  include/configs/rsk7264.h| 2 ++
>  include/configs/rsk7269.h| 2 ++
>  include/configs/sh7752evb.h  | 1 +
>  include/configs/sh7753evb.h  | 1 +
>  include/configs/sh7757lcr.h  | 1 +
>  include/configs/sh7763rdp.h  | 1 +
>  include/configs/sh7785lcr.h  | 1 +
>  include/configs/shmin.h  | 1 +
>  21 files changed, 27 insertions(+)

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

Re: [U-Boot] [RESEND][PATCH 16/24] sh: add MEMORY command to a shared linker script

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> At the moment in runtime all defined sections are copied into or
> created in RAM, specify this explicitly to assert potential out of RAM
> placements of the sections.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/u-boot.lds | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 14/24] sh: place board lowlevel_init code in the beginning of .text

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> Reference lowlevel_init of all supported SH2A/SH3/SH4/SH4A boards
> from a shared linker script, the lowlevel_init function will be called
> by a relative address.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/u-boot.lds | 2 +-
>  board/alphaproject/ap_sh4a_4a/Makefile | 2 +-
>  board/espt/Makefile| 2 +-
>  board/mpr2/Makefile| 2 +-
>  board/ms7720se/Makefile| 2 +-
>  board/ms7722se/Makefile| 2 +-
>  board/ms7750se/Makefile| 2 +-
>  board/renesas/MigoR/Makefile   | 2 +-
>  board/renesas/ap325rxa/Makefile| 2 +-
>  board/renesas/ecovec/Makefile  | 2 +-
>  board/renesas/r0p7734/Makefile | 2 +-
>  board/renesas/r2dplus/Makefile | 2 +-
>  board/renesas/r7780mp/Makefile | 2 +-
>  board/renesas/rsk7203/Makefile | 2 +-
>  board/renesas/rsk7264/Makefile | 2 +-
>  board/renesas/rsk7269/Makefile | 2 +-
>  board/renesas/sh7763rdp/Makefile   | 2 +-
>  board/renesas/sh7785lcr/Makefile   | 2 +-
>  board/shmin/Makefile   | 2 +-
>  19 files changed, 19 insertions(+), 19 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 13/24] sh4: use single u-boot linker script for all boards

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> Three supported SH4/SH4A boards with the bootloader image stored on
> SPI flash have own flavour of a linker script, in turn they are equal
> among each other. The only difference is that the text from
> lowlevel_init.o is placed right after start.o, which makes sense.
>
> Note that .bss section is not marked as NOLOAD, because for about
> 10 years this is a default option of a GNU linker, either the
> attribute is found or not the resulting image file is the same.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/u-boot.lds |  4 ++
>  board/renesas/sh7752evb/Makefile   |  2 +-
>  board/renesas/sh7752evb/u-boot.lds | 82 -
>  board/renesas/sh7753evb/Makefile   |  2 +-
>  board/renesas/sh7753evb/u-boot.lds | 82 -
>  board/renesas/sh7757lcr/Makefile   |  2 +-
>  board/renesas/sh7757lcr/u-boot.lds | 83 
> --
>  include/configs/sh7752evb.h|  1 -
>  include/configs/sh7753evb.h|  1 -
>  include/configs/sh7757lcr.h|  1 -
>  10 files changed, 7 insertions(+), 253 deletions(-)
>  delete mode 100644 board/renesas/sh7752evb/u-boot.lds
>  delete mode 100644 board/renesas/sh7753evb/u-boot.lds
>  delete mode 100644 board/renesas/sh7757lcr/u-boot.lds

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

Re: [U-Boot] [RESEND][PATCH 15/24] sh: define entry point and reloc_dst inside a linker script

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> No functional change, concentrate linker script commands in one
> place for convenience. Entry point is set to CONFIG_SYS_TEXT_BASE by
> default on build, so this option can be omitted from being added to
> the linker script.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/config.mk  | 1 -
>  arch/sh/cpu/u-boot.lds | 6 +-
>  2 files changed, 1 insertion(+), 6 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 11/24] r2dplus: select rtl8139 driver in defconfig

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> CONFIG_RTL8139 was moved to a board defconfig by a commit 86e9dc86b1a2
> ("net: Move CONFIG_RTL8139 to Kconfig"), however it was done
> incorrectly due to a missing CONFIG_NETDEVICES selection, thus
> virtually it was just a removal of the driver compilation.
>
> As an unlucky consequence the option was completely removed by a purge
> commit adad96e60d0e ("configs: Re-sync HUSH options"), restore the
> driver inclusion back.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  configs/r2dplus_defconfig | 2 ++
>  1 file changed, 2 insertions(+)

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

Re: [U-Boot] [RESEND][PATCH 09/24] sh4: remove __io config options from r2dplus and r7780mp boards

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> Defined __io is no-op for the SH architecture and it can be removed
> from board files without any functional change.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/include/asm/io.h  | 10 --
>  include/configs/r2dplus.h |  1 -
>  include/configs/r7780mp.h |  1 -
>  3 files changed, 12 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 04/24] sh: cache use jump_to_P2() and back_to_P1() from asm/system.h

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> Both jump_to_P2() and back_to_P1() functions are found in asm/system.h
> header file and functionally they are the same, don't redefine them.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/sh4/cache.c | 39 ++-
>  1 file changed, 2 insertions(+), 37 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 06/24] sh4: cache: move exported cache manipulation functions into cache.c

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> No functional change, moving cache manipulation functions into cache.c
> allows to collect all of them in a single location and as a pleasant
> side effect cache_control() function can be unexported now.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/sh4/cache.c | 39 ---
>  arch/sh/cpu/sh4/cpu.c   | 34 --
>  arch/sh/include/asm/cache.h |  2 --
>  3 files changed, 36 insertions(+), 39 deletions(-)

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

Re: [U-Boot] [RESEND][PATCH 10/24] r2dplus: use P1 area space for text base and PCI system memory

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> While both options are acceptable use P1 area physical addresses
> instead of external memory space of text base and PCI system memory
> for unification purposes, all other supported superh boards have the
> same selection.
>
> This allows to easily ensure that CONFIG_SYS_TEXT_BASE is located
> within available DRAM.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  include/configs/r2dplus.h | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

Reviewed-by: Simon Glass 

But it is probably nice to move this to DM_PCI.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RESEND][PATCH 03/24] sh3: remove unused cache.c file from being built

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> The change is similar to commit 994b56616bae ("sh: delete an unused
> source file") for SH2, however here the removed cache.c file was
> built and included into an image as a dead code.
>
> If it is needed in future the contents can be reused from a similar
> arch/sh/cpu/sh4/cache.c file, which is in turn will be moved to
> a shared among all core flavours location at arch/sh/lib/cache.c.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/sh3/Makefile |  2 +-
>  arch/sh/cpu/sh3/cache.c  | 96 
> 
>  2 files changed, 1 insertion(+), 97 deletions(-)
>  delete mode 100644 arch/sh/cpu/sh3/cache.c

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

Re: [U-Boot] [RESEND][PATCH 02/24] sh4: cache: correct flush_cache() to writeback and invalidate

[Simon Glass]

On 27 November 2016 at 15:15, Vladimir Zapolskiy  wrote:
> In common usecases flush_cache() assumes both cache invalidation and
> write-back to memory, instead of doing cache invalidation only with
> the wrapped 'ocbi' instruction pin flush_cache() to cache invalidation
> with memory write-back done by 'ocbp'.
>
> Signed-off-by: Vladimir Zapolskiy 
> ---
>  arch/sh/cpu/sh4/cpu.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [U-Boot] [PATCH 05/14] serial: 16550: Add port type as driver data

[Simon Glass]

Hi Marek,

On 27 November 2016 at 10:07, Marek Vasut  wrote:
> On 11/27/2016 06:03 PM, Simon Glass wrote:
>> Hi Marex,
>>
>> On 25 November 2016 at 15:32, Marek Vasut  wrote:
>>> Add driver data to each compatible string to identify the type of
>>> the port. Since all the ports in the driver are entirely compatible
>>> with 16550 for now, all are marked with PORT_NS16550. But, there
>>> are ports which have specific quirks, like the JZ4780 UART, which
>>> do not have any DT property to denote the quirks. Instead, Linux
>>> uses the compatible string to discern such ports and enable the
>>> necessary quirks.
>>>
>>> Signed-off-by: Marek Vasut 
>>> Cc: Tom Rini 
>>> Cc: Simon Glass 
>>> ---
>>>  drivers/serial/ns16550.c | 26 --
>>>  1 file changed, 16 insertions(+), 10 deletions(-)
>>>
>>> diff --git a/drivers/serial/ns16550.c b/drivers/serial/ns16550.c
>>> index 3c9f3b0..3130a1d 100644
>>> --- a/drivers/serial/ns16550.c
>>> +++ b/drivers/serial/ns16550.c
>>> @@ -360,6 +360,12 @@ int ns16550_serial_probe(struct udevice *dev)
>>> return 0;
>>>  }
>>>
>>> +#if CONFIG_IS_ENABLED(OF_CONTROL)
>>> +enum {
>>> +   PORT_NS16550 = 0,
>>> +};
>>> +#endif
>>> +
>>>  #if CONFIG_IS_ENABLED(OF_CONTROL) && !CONFIG_IS_ENABLED(OF_PLATDATA)
>>>  int ns16550_serial_ofdata_to_platdata(struct udevice *dev)
>>>  {
>>> @@ -453,16 +459,16 @@ const struct dm_serial_ops ns16550_serial_ops = {
>>>   * compatible string to your dts.
>>>   */
>>>  static const struct udevice_id ns16550_serial_ids[] = {
>>> -   { .compatible = "ns16550" },
>>> -   { .compatible = "ns16550a" },
>>> -   { .compatible = "nvidia,tegra20-uart" },
>>> -   { .compatible = "snps,dw-apb-uart" },
>>> -   { .compatible = "ti,omap2-uart" },
>>> -   { .compatible = "ti,omap3-uart" },
>>> -   { .compatible = "ti,omap4-uart" },
>>> -   { .compatible = "ti,am3352-uart" },
>>> -   { .compatible = "ti,am4372-uart" },
>>> -   { .compatible = "ti,dra742-uart" },
>>> +   { .compatible = "ns16550",  .data = PORT_NS16550 },
>>> +   { .compatible = "ns16550a", .data = PORT_NS16550 },
>>> +   { .compatible = "nvidia,tegra20-uart",  .data = PORT_NS16550 },
>>> +   { .compatible = "snps,dw-apb-uart", .data = PORT_NS16550 },
>>> +   { .compatible = "ti,omap2-uart",.data = PORT_NS16550 },
>>> +   { .compatible = "ti,omap3-uart",.data = PORT_NS16550 },
>>> +   { .compatible = "ti,omap4-uart",.data = PORT_NS16550 },
>>> +   { .compatible = "ti,am3352-uart",   .data = PORT_NS16550 },
>>> +   { .compatible = "ti,am4372-uart",   .data = PORT_NS16550 },
>>> +   { .compatible = "ti,dra742-uart",   .data = PORT_NS16550 },
>>
>> But can we have 0 as the default so we don't need these values?
>
> PORT_NS16550 is zero anyway, it's just explicitly spelled here.

One way might be to use PORT_DEFAULT, set it to 0 and omit it here. It
does seem odd to have PORT_NS16550 in the ns16550 driver.

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

Re: [U-Boot] [PATCH 07/14] mmc: Tinification of the mmc code

[Simon Glass]

Hi Marek,

On 25 November 2016 at 15:32, Marek Vasut  wrote:
> Add new configuration option CONFIG_MMC_TINY which strips away all
> memory allocation within the MMC code and code for handling multiple
> cards. This allows extremely space-constrained SPL code use the MMC
> framework.
>
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 
> Cc: Simon Glass 
> ---
> V2: Switch the MMC_TINY option to Kconfig
> ---
>  common/spl/spl_mmc.c |  6 +-
>  drivers/mmc/Kconfig  | 16 
>  drivers/mmc/mmc.c| 31 ++-
>  drivers/mmc/mmc_legacy.c | 32 
>  include/mmc.h|  1 +
>  5 files changed, 84 insertions(+), 2 deletions(-)

Reviewed-by: Simon Glass 

nit below.

I assume this does not use DM?

>
> diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
> index 43c1030..3cad998 100644
> --- a/common/spl/spl_mmc.c
> +++ b/common/spl/spl_mmc.c
> @@ -306,7 +306,11 @@ static int spl_mmc_load_image(struct spl_image_info 
> *spl_image,
> if (part == 7)
> part = 0;
>
> -   err = blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
> +   if (CONFIG_IS_ENABLED(MMC_TINY))
> +   err = mmc_switch_part(mmc, part);
> +   else
> +   err = 
> blk_dselect_hwpart(mmc_get_blk_desc(mmc), part);
> +
> if (err) {
>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
> puts("spl: mmc partition switch failed\n");
> diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
> index 24f4b28..aca438b8 100644
> --- a/drivers/mmc/Kconfig
> +++ b/drivers/mmc/Kconfig
> @@ -26,6 +26,22 @@ config DM_MMC_OPS
>   option will be removed as soon as all DM_MMC drivers use it, as it
>   will the only supported behaviour.
>
> +config SPL_MMC_TINY
> +   bool "Tiny MMC framework in SPL"
> +   default n

Not needed?

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

Re: [U-Boot] [PATCH v2 7/7] block: Move ceva driver to DM

[Simon Glass]

Hi Michal,

On 25 November 2016 at 08:00, Michal Simek  wrote:
> This patch also includes ARM64 zynqmp changes:
> - Remove platform non DM initialization
> - Remove hardcoded sata base address
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v2:
> - make ceva_init_sata static
> - Move SATA_CEVA to defconfig
> - Initalized max_lun and max_id platdata
>
>  arch/arm/include/asm/arch-zynqmp/hardware.h |  2 --
>  board/xilinx/zynqmp/zynqmp.c| 11 
>  configs/xilinx_zynqmp_ep_defconfig  |  2 ++
>  configs/xilinx_zynqmp_zcu102_defconfig  |  2 ++
>  configs/xilinx_zynqmp_zcu102_revB_defconfig |  2 ++
>  drivers/block/Kconfig   |  6 +
>  drivers/block/sata_ceva.c   | 41 
> +++--
>  include/configs/xilinx_zynqmp.h |  5 ++--
>  include/configs/xilinx_zynqmp_ep.h  |  1 -
>  include/configs/xilinx_zynqmp_zcu102.h  |  2 --
>  10 files changed, 54 insertions(+), 20 deletions(-)

Reviewed-by: Simon Glass 

nits below

>
> diff --git a/arch/arm/include/asm/arch-zynqmp/hardware.h 
> b/arch/arm/include/asm/arch-zynqmp/hardware.h
> index e7738faaf896..d1970953e234 100644
> --- a/arch/arm/include/asm/arch-zynqmp/hardware.h
> +++ b/arch/arm/include/asm/arch-zynqmp/hardware.h
> @@ -18,8 +18,6 @@
>
>  #define ARASAN_NAND_BASEADDR   0xFF10
>
> -#define ZYNQMP_SATA_BASEADDR   0xFD0C
> -
>  #define ZYNQMP_USB0_XHCI_BASEADDR  0xFE20
>  #define ZYNQMP_USB1_XHCI_BASEADDR  0xFE30
>
> diff --git a/board/xilinx/zynqmp/zynqmp.c b/board/xilinx/zynqmp/zynqmp.c
> index cef1f6a13aee..a23c38acd99d 100644
> --- a/board/xilinx/zynqmp/zynqmp.c
> +++ b/board/xilinx/zynqmp/zynqmp.c
> @@ -311,17 +311,6 @@ void reset_cpu(ulong addr)
>  {
>  }
>
> -#ifdef CONFIG_SCSI_AHCI_PLAT
> -void scsi_init(void)
> -{
> -#if defined(CONFIG_SATA_CEVA)
> -   init_sata(0);
> -#endif
> -   ahci_init((void __iomem *)ZYNQMP_SATA_BASEADDR);
> -   scsi_scan(1);
> -}
> -#endif
> -
>  int board_late_init(void)
>  {
> u32 reg = 0;
> diff --git a/configs/xilinx_zynqmp_ep_defconfig 
> b/configs/xilinx_zynqmp_ep_defconfig
> index f3cdf90c1f73..8d6a6cf5701e 100644
> --- a/configs/xilinx_zynqmp_ep_defconfig
> +++ b/configs/xilinx_zynqmp_ep_defconfig
> @@ -49,6 +49,8 @@ CONFIG_OF_EMBED=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_SPL_DM=y
>  CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_DM_SCSI=y
> +CONFIG_SATA_CEVA=y
>  CONFIG_DFU_RAM=y
>  CONFIG_FPGA_XILINX=y
>  CONFIG_FPGA_ZYNQMPPL=y
> diff --git a/configs/xilinx_zynqmp_zcu102_defconfig 
> b/configs/xilinx_zynqmp_zcu102_defconfig
> index fa6d6692040e..7e5e83fdc043 100644
> --- a/configs/xilinx_zynqmp_zcu102_defconfig
> +++ b/configs/xilinx_zynqmp_zcu102_defconfig
> @@ -41,6 +41,8 @@ CONFIG_OF_EMBED=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_SPL_DM=y
>  CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_DM_SCSI=y
> +CONFIG_SATA_CEVA=y
>  CONFIG_DFU_RAM=y
>  CONFIG_FPGA_XILINX=y
>  CONFIG_FPGA_ZYNQMPPL=y
> diff --git a/configs/xilinx_zynqmp_zcu102_revB_defconfig 
> b/configs/xilinx_zynqmp_zcu102_revB_defconfig
> index a4af8024e454..f57705b2cba9 100644
> --- a/configs/xilinx_zynqmp_zcu102_revB_defconfig
> +++ b/configs/xilinx_zynqmp_zcu102_revB_defconfig
> @@ -41,6 +41,8 @@ CONFIG_OF_EMBED=y
>  CONFIG_NET_RANDOM_ETHADDR=y
>  CONFIG_SPL_DM=y
>  CONFIG_SPL_DM_SEQ_ALIAS=y
> +CONFIG_DM_SCSI=y
> +CONFIG_SATA_CEVA=y
>  CONFIG_DFU_RAM=y
>  CONFIG_FPGA_XILINX=y
>  CONFIG_FPGA_ZYNQMPPL=y
> diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
> index 55edae71eec3..0b289b2fc111 100644
> --- a/drivers/block/Kconfig
> +++ b/drivers/block/Kconfig
> @@ -34,3 +34,9 @@ config BLOCK_CACHE
>   This is most useful when accessing filesystems under U-Boot since
>   it will prevent repeated reads from directory structures and other
>   filesystem data structures.
> +
> +config SATA_CEVA
> +   bool "Ceva Sata controller"
> +   depends on DM_SCSI
> +   help
> + This option enables Ceva Sata controller available on Xilinx ZynqMP.

Can you add more detail? What does it support? Is this soft IP?

> diff --git a/drivers/block/sata_ceva.c b/drivers/block/sata_ceva.c
> index dcc3b90b17f1..3f40b7efb6fa 100644
> --- a/drivers/block/sata_ceva.c
> +++ b/drivers/block/sata_ceva.c
> @@ -9,6 +9,7 @@
>  #include 
>  #include 
>  #include 
> +#include 

please put these in order with http://www.denx.de/wiki/U-Boot/CodingStyle

>
>  #include 
>
> @@ -73,10 +74,9 @@
>  #define DRV_NAME   "ahci-ceva"
>  #define CEVA_FLAG_BROKEN_GEN2  1
>
> -int init_sata(int dev)
> +static int ceva_init_sata(ulong mmio)
>  {
> ulong tmp;
> -   ulong mmio = ZYNQMP_SATA_BASEADDR;
> int i;
>
> /*
> @@ -111,3 +111,40 @@ int init_sata(int dev)
> }
> return 0;
>  }
> +
> +static int sata_ceva_probe(struct udevice *dev)
> +{
> +   struct scsi_platdata *plat = dev_get_platdata(dev);
> +

Re: [U-Boot] [PATCH v2 6/7] dm: Add support for scsi/sata based devices

[Simon Glass]

Hi Michal,

On 25 November 2016 at 08:00, Michal Simek  wrote:
> All sata based drivers are bind and corresponding block
> device is created. Based on this find_scsi_device() is able
> to get back block device based on scsi_curr_dev pointer.
>
> intr_scsi() is commented now but it can be replaced by calling
> find_scsi_device() and scsi_scan().
>
> scsi_dev_desc[] is commented out but common/scsi.c heavily depends on
> it. That's why CONFIG_SYS_SCSI_MAX_DEVICE is hardcoded to 1 and symbol
> is reassigned to a block description allocated by uclass.
> There is only one block description by device now but it doesn't need to
> be correct when more devices are present.
>
> scsi_bind() ensures corresponding block device creation.
> uclass post_probe (scsi_post_probe()) is doing low level init.
>
> SCSI/SATA DM based drivers requires to have 64bit base address as
> the first entry in platform data structure to setup mmio_base.
>
> Signed-off-by: Michal Simek 
> ---
>
> Changes in v2:
> - Use CONFIG_DM_SCSI instead of mix of DM_SCSI and DM_SATA
>   Ceva sata has never used sata commands that's why keep it in
>   SCSI part only.
> - Separate scsi_scan() for DM_SCSI and do not change cmd/scsi.c
> - Extend platdata
>
>  common/board_r.c|  4 +--
>  common/scsi.c   | 81 
> +
>  drivers/block/Kconfig   |  7 
>  drivers/block/Makefile  |  1 +
>  drivers/block/ahci.c| 30 -
>  drivers/block/blk-uclass.c  |  2 +-
>  drivers/block/scsi-uclass.c | 29 
>  include/ahci.h  |  2 +-
>  include/dm/uclass-id.h  |  1 +
>  include/sata.h  |  3 ++
>  include/scsi.h  | 19 ++-
>  11 files changed, 166 insertions(+), 13 deletions(-)
>  create mode 100644 drivers/block/scsi-uclass.c

This looks really good. I've made some comments below.

>
> diff --git a/common/board_r.c b/common/board_r.c
> index d959ad3c6f90..108cabbd023b 100644
> --- a/common/board_r.c
> +++ b/common/board_r.c
> @@ -620,7 +620,7 @@ static int initr_ambapp_print(void)
>  }
>  #endif
>
> -#if defined(CONFIG_SCSI)
> +#if defined(CONFIG_SCSI) && !defined(CONFIG_DM_SCSI)
>  static int initr_scsi(void)
>  {
> puts("SCSI:  ");
> @@ -923,7 +923,7 @@ init_fnc_t init_sequence_r[] = {
> initr_ambapp_print,
>  #endif
>  #endif
> -#ifdef CONFIG_SCSI
> +#if defined(CONFIG_SCSI) && !defined(CONFIG_DM_SCSI)
> INIT_FUNC_WATCHDOG_RESET
> initr_scsi,
>  #endif
> diff --git a/common/scsi.c b/common/scsi.c
> index 9e4ef54a9be8..bc55512913da 100644
> --- a/common/scsi.c
> +++ b/common/scsi.c
> @@ -7,10 +7,14 @@
>
>  #include 
>  #include 
> +#if defined(CONFIG_DM_SCSI)
> +#include 
> +#endif

You can drop that #ifdef - also please put the dm/ include at the end,
after scsi.h.

>  #include 
>  #include 
>  #include 
>
> +#if !defined(CONFIG_DM_SCSI)
>  #ifdef CONFIG_SCSI_DEV_LIST
>  #define SCSI_DEV_LIST CONFIG_SCSI_DEV_LIST
>  #else
> @@ -31,6 +35,7 @@
>  #endif
>  #define SCSI_DEV_LIST {SCSI_VEND_ID, SCSI_DEV_ID}
>  #endif
> +#endif
>
>  #if defined(CONFIG_PCI) && !defined(CONFIG_SCSI_AHCI_PLAT)
>  const struct pci_device_id scsi_device_list[] = { SCSI_DEV_LIST };
> @@ -41,9 +46,11 @@ static unsigned char tempbuff[512]; /* temporary data 
> buffer */
>
>  static int scsi_max_devs; /* number of highest available scsi device */

I think this should be bracketed by !CONFIG_DM_SCSI, also.

>
> +#if !defined(CONFIG_DM_SCSI)
>  static int scsi_curr_dev; /* current device */
>
>  static struct blk_desc scsi_dev_desc[CONFIG_SYS_SCSI_MAX_DEVICE];
> +#endif
>
>  /* almost the maximum amount of the scsi_ext command.. */
>  #define SCSI_MAX_READ_BLK 0x
> @@ -555,6 +562,79 @@ removable:
>   * (re)-scan the scsi bus and reports scsi device info
>   * to the user if mode = 1
>   */
> +#if defined(CONFIG_DM_SCSI)
> +void scsi_scan(int mode)

This function can generate errors - can you update it to return 'int'
so you can return them?

> +{
> +   unsigned char i, lun;
> +   struct uclass *uc;
> +   struct udevice *dev; /* SCSI controller */
> +   int ret;
> +
> +   if (mode == 1)
> +   printf("scanning bus for devices...\n");
> +
> +   ret = uclass_get(UCLASS_SCSI, );
> +   if (ret)
> +   return;
> +
> +   uclass_foreach_dev(dev, uc) {
> +   struct scsi_platdata *plat; /* scsi controller platdata */
> +   struct blk_desc *bdesc = NULL; /* block device description */

I don't think you need the = NULL

> +   struct udevice *bdev; /* block device */
> +   struct udevice **devp = NULL;

You should be able to drop this

> +   int dev_num = 0;
> +   int last_dev_num = -1;
> +
> +   /* probe SCSI controller driver */
> +   ret = uclass_get_device_tail(dev, 0, devp);

ret = device_probe(dev);

> +   if 

Re: [U-Boot] [PATCH 05/24] SPL: tiny-printf: add "l" modifier

[Simon Glass]

Hi Andre,

On 28 November 2016 at 18:13, André Przywara  wrote:
> On 28/11/16 00:22, André Przywara wrote:
>> On 27/11/16 17:02, Simon Glass wrote:
>>
>> Hi,
>>
>>> On 23 November 2016 at 20:19, Siarhei Siamashka
>>>  wrote:
 On Sun, 20 Nov 2016 14:56:59 +
 Andre Przywara  wrote:

> tiny-printf does not know about the "l" modifier so far, which breaks
> the crash dump on AArch64, because it uses %lx to print the registers.
> Add an easy way of handling longs correctly.

 I can't help but notice that the changes of this kind are in a way
 defeating the original purpose of tiny-printf. And it is surely not
 the first patch adding features to tiny-printf. I guess, in the end
 we may end up with a large and bloated printf implementation again :-)

 A possible solution might be just a strict check when parsing format
 modifiers and abort with an error message (yeah, this will introduce
 some size increase, but hopefully the last one). This way we
 acknowledge the fact that tiny-printf is a reduced incomplete
 implementation, and that the callers need to take this into account.

 As for the "l" modifier. How much does it add to the code size? IMHO
 this information should be mentioned in the commit message. Can the
 AArch64 crash dump code be modified to avoid using it? Or can we have
 the "l" modifier supported on 64-bit platforms only?

> Signed-off-by: Andre Przywara 
> ---
>  lib/tiny-printf.c | 43 +--
>  1 file changed, 33 insertions(+), 10 deletions(-)
>>>
>>> I think I tested this patch as adding 36 bytes on Thumb2 so not too
>>> terrible. But I do agree with the sentiment.
>
> Simon, what is your compiler?

4.9 I suspect for that test. I build with various ones as I have been
caught by breaking a slightly older compiler.

> Both with GCC 5.3.0 and GCC 6.2.0 I get exactly 6/4 bytes more of .text,
> which is not too bad for parsing (but ignoring) two new modifiers.
> It turns out that (at least these two versions of) GCCs are quite clever
> here and optimize away almost everything.
> Looking closer one can see that the if and else branches become
> identical if sizeof(long) == sizeof(int) == 4, so the compiler happily
> merges the code, removes the "if (long)" check and in turn the whole
> long-handling code on 32-bit.
> This is the patch as sent, without any further hints in the code.
>
> If anyone really wants to save code space, I suggest to switch to a
> later compiler:
>
> GCC 5.3.0:
>  textdata bss dec hex filename
> origin/master   orangepi_plus_defconfig GCC 5.3.0
> 18881 488 232   196014c91 spl/u-boot-spl
>   758   0   0 758 2f6 spl/lib/tiny-printf.o
>
> master+tiny_printf %l,%- orangepi_plus_defconfig GCC 5.3.0
> 18887 488 232   196074c97 spl/u-boot-spl
>   758   0   0 758 2f6 spl/lib/tiny-printf.o
>
> GCC 6.2.0:
> origin/master   orangepi_plus_defconfig GCC 6.2.0
> 16871 488 232   1759144b7 spl/u-boot-spl
>   698   0   0 698 2ba spl/lib/tiny-printf.o
>
> master+tiny_printf %l,%- orangepi_plus_defconfig GCC 6.2.0
> 16875 488 232   1759544bb spl/u-boot-spl
>   702   0   0 702 2be spl/lib/tiny-printf.o
>
> On 64-bit (only GCC 6.2.0) this results in more code, as expected:
> HEAD of patch set w/o tiny-printf %l, pine64_plus_defconfig
> 25824 392 360   2657667d0 spl/u-boot-spl
>  1542   0   01542 606 spl/lib/tiny-printf.o
> HEAD of patch set, pine64_plus_defconfig
> 25972 392 360   267246864 spl/u-boot-spl
>  1690   0   01690 69a spl/lib/tiny-printf.o
>
> So this is 148 Bytes more in .text. I can trade three simple patches
> that cut off 80 Bytes in sunxi/armv8 to at least offset this a bit,
> though this isn't really a regression, as there was no SPL64 for sunxi
> before.
> So apart from Alex' bug fix I won't change the patch, if people can live
> with that.

That seems fine to me. Also this useful info could go in a note in your patch.

>
> Cheers,
> Andre.
>

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

Re: [U-Boot] [PATCH resend v3 5/6] drivers: usb: gadget: ether: prepare driver for driver model migration

[Joe Hershberger]

On Thu, Nov 17, 2016 at 11:38 PM, Mugunthan V N  wrote:
> prepare driver for driver model migration
>
> Signed-off-by: Mugunthan V N 

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

Re: [U-Boot] [PATCH resend v3 4/6] drivers: usb: gadget: ether: use net device priv to pass usb ether priv

[Joe Hershberger]

On Thu, Nov 17, 2016 at 11:37 PM, Mugunthan V N  wrote:
> Use net device priv to pass usb ether priv and use it in
> net device ops callback.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH resend v3 3/6] drivers: usb: gadget: ether: consolidate global devices to single struct

[Joe Hershberger]

On Thu, Nov 17, 2016 at 11:36 PM, Mugunthan V N  wrote:
> Consolidate the net device, usb eth device and gadget device
> struct to single struct and a single global variable so that the
> same can be passed as priv of ethernet driver.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [PATCH resend v3 1/6] drivers: usb: gadget: ether: adopt to usb driver model

[Joe Hershberger]

On Thu, Nov 17, 2016 at 11:19 PM, Mugunthan V N  wrote:
> Convert usb ether gadget to adopt usb driver model
>
> Signed-off-by: Mugunthan V N 

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

Re: [U-Boot] [PATCH resend v3 6/6] drivers: usb: gadget: ether/rndis: convert driver to adopt device driver model

[Joe Hershberger]

On Thu, Nov 17, 2016 at 11:39 PM, Mugunthan V N  wrote:
> Adopt usb ether gadget and rndis driver to adopt driver model
>
> Signed-off-by: Mugunthan V N 
> ---
>  drivers/usb/gadget/Kconfig |   4 ++
>  drivers/usb/gadget/ether.c | 153 
> ++---
>  drivers/usb/gadget/rndis.c |  13 +++-
>  drivers/usb/gadget/rndis.h |  19 --
>  include/net.h  |   7 +++
>  5 files changed, 181 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/usb/gadget/Kconfig b/drivers/usb/gadget/Kconfig
> index 40839d89e9..261ed128ac 100644
> --- a/drivers/usb/gadget/Kconfig
> +++ b/drivers/usb/gadget/Kconfig
> @@ -112,6 +112,10 @@ config G_DNL_VENDOR_NUM
>  config G_DNL_PRODUCT_NUM
> hex "Product ID of USB device"
>
> +config USBNET_DEVADDR
> +   string "USB Gadget Ethernet device mac address"
> +   default "de:ad:be:ef:00:01"

Please don't do this. We don't have "default" MAC addresses. They are
either from the env, from ROM, or randomly generated.

> +
>  endif # USB_GADGET_DOWNLOAD
>
>  endif # USB_GADGET
> diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
> index 046ad8ca2b..8c3c3fd9ab 100644
> --- a/drivers/usb/gadget/ether.c
> +++ b/drivers/usb/gadget/ether.c
> @@ -25,6 +25,7 @@
>  #include "rndis.h"
>
>  #include 
> +#include 
>  #include 
>  #include 
>
> @@ -116,7 +117,11 @@ struct eth_dev {
>
> struct usb_request  *tx_req, *rx_req;
>
> +#ifndef CONFIG_DM_ETH

Please use positive logic.

> struct eth_device   *net;
> +#else
> +   struct udevice  *net;
> +#endif
> struct net_device_stats stats;
> unsigned inttx_qlen;
>
> @@ -143,7 +148,11 @@ struct eth_dev {
>  /*-*/
>  struct ether_priv {
> struct eth_dev ethdev;
> +#ifndef CONFIG_DM_ETH

Please use positive logic

> struct eth_device netdev;
> +#else
> +   struct udevice *netdev;

Did you really intend to have a pointer here when the other is an
inline structure?

> +#endif
> struct usb_gadget_driver eth_driver;
>  };
>
> @@ -1851,7 +1860,11 @@ static void rndis_control_ack_complete(struct usb_ep 
> *ep,
>
>  static char rndis_resp_buf[8] __attribute__((aligned(sizeof(__le32;
>
> +#ifndef CONFIG_DM_ETH

Please use positive logic.

>  static int rndis_control_ack(struct eth_device *net)
> +#else
> +static int rndis_control_ack(struct udevice *net)
> +#endif
>  {
> struct ether_priv   *priv = (struct ether_priv *)net->priv;
> struct eth_dev  *dev = >ethdev;
> @@ -2001,6 +2014,9 @@ static int eth_bind(struct usb_gadget *gadget)
> int status = -ENOMEM;
> int gcnum;
> u8  tmp[7];
> +#ifdef CONFIG_DM_ETH
> +   struct eth_pdata*pdata = dev_get_platdata(l_priv->netdev);
> +#endif
>
> /* these flags are only ever cleared; compiler take note */
>  #ifndefCONFIG_USB_ETH_CDC
> @@ -2188,7 +2204,11 @@ autoconf_fail:
>
>
> /* network device setup */
> +#ifndef CONFIG_DM_ETH
> dev->net = _priv->netdev;

You wouldn't need this difference if the priv also used a ptr in the
non-dm case.

Also, if you are opposed to cleaning this up (preferably by adding a
preceding patch to make it a pointer), at least use positive logic
(#ifdef CONFIG_DM_ETH). Same applies elsewhere.

> +#else
> +   dev->net = l_priv->netdev;
> +#endif
>
> dev->cdc = cdc;
> dev->zlp = zlp;
> @@ -2197,6 +2217,7 @@ autoconf_fail:
> dev->out_ep = out_ep;
> dev->status_ep = status_ep;
>
> +   memset(tmp, 0, sizeof(tmp));
> /*
>  * Module params for these addresses should come from ID proms.
>  * The host side address is used with CDC and RNDIS, and commonly
> @@ -2204,10 +2225,13 @@ autoconf_fail:
>  * host side code for the SAFE thing cares -- its original BLAN
>  * thing didn't, Sharp never assigned those addresses on Zaurii.
>  */
> +#ifndef CONFIG_DM_ETH
> get_ether_addr(dev_addr, dev->net->enetaddr);
> -
> -   memset(tmp, 0, sizeof(tmp));
> memcpy(tmp, dev->net->enetaddr, sizeof(dev->net->enetaddr));
> +#else
> +   get_ether_addr(dev_addr, pdata->enetaddr);
> +   memcpy(tmp, pdata->enetaddr, sizeof(pdata->enetaddr));
> +#endif
>
> get_ether_addr(host_addr, dev->host_mac);
>
> @@ -2268,10 +2292,11 @@ autoconf_fail:
> status_ep ? " STATUS " : "",
> status_ep ? status_ep->name : ""
> );
> -   printf("MAC %02x:%02x:%02x:%02x:%02x:%02x\n",
> -   dev->net->enetaddr[0], dev->net->enetaddr[1],
> -   dev->net->enetaddr[2], dev->net->enetaddr[3],
> -   dev->net->enetaddr[4], dev->net->enetaddr[5]);
> +#ifndef CONFIG_DM_ETH
> +   printf("MAC %pM\n", dev->net->enetaddr);
> 

Re: [U-Boot] [PATCH v3 0/9] From Simon:

[Heiko Stübner]

Hi Simon,

Am Sonntag, 27. November 2016, 10:01:40 schrieb Simon Glass:
> This v3 patch is an update on Sjoerd's original v2 series from Feburary.
> I have dealt with the changes requested at the time, and adjusted the way
> that the speed change is handled.
> 
> Tested on firefly-rk3288, rock2.

Tested on a firefly as well. Though I get mixed results in my netboot 
environment. At 100MBit (manually limited) everything seems fine:

--
Speed: 100, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.140.58 (269 ms)
Using ethernet@ff29 device
TFTP from server 192.168.140.1; our IP address is 192.168.140.58
Filename 'hstuebner/firefly.vmlinuz'.
Load address: 0x400
Loading: #
 #
 #
 #
 #
 #
 #
 #
 2.9 MiB/s
done
Bytes transferred = 7033483 (6b528b hex)
--

5 out of 5 boots worked fine.


but at 1000MHz I only get:

--
Speed: 1000, full duplex
BOOTP broadcast 1
BOOTP broadcast 2
DHCP client bound to address 192.168.140.57 (270 ms)
Using ethernet@ff29 device
TFTP from server 192.168.140.1; our IP address is 192.168.140.57
Filename 'hstuebner/firefly.vmlinuz'.
Load address: 0x400
Loading: #T #T #T ##T T #T #T T T #T 
Retry count exceeded; starting again
--

on 5 boots. 1 lonely boot also worked at 1000MBit for some unknown reason.
I'm not sure if just my switch is some special snowflake (TL-SG1024 from TP-
Link) or there is some other voodoo at work here.

The rootfs over nfs seems to work fine on 1000MBit though.


Heiko

> Original cover letter:
> To add support I've taken a slightly different approach then some of the
> other boards with a designware IP block, by creating a new driver to
> take care of the platfrom glue which subclasses the main designware driver
> instead of adding the compatibility string the designware driver
> directly and doing the SoC specific setup in the board files. This seems
> quite a bit more elegant in a device model based world.
> 
> I've only tested this series on a Radxa Rock 2 board, it would be great
> if someone could test this on other boards with the designware IP
> especially for those with the reset GPIO in devicetree (e.g. some of the
> Allwinner boards).
> 
> Compared to the first one round the pinctrl related bits were dropped as
> RK3288 now has a full pinctrl driver. Furthermore the started hook in the
> designware driver was renamed to fix_mac_speed in line with what linux
> uses and moved to the dw_link_adjust function.
> 
> Changes in v3:
> - Add a few new patches
> - Add comments for struct gmac_rk3288_platdata
> - Add new patch to adjust dw_adjust_link() to return an error
> - Add new patch to enable networking on evb-rk3288
> - Add new patch to export the operation functions
> - Add new patch to split the link init into a separate function
> - Adjust binding to use r/tx-delay instead of r/tx_delay
> - Drop the 'net: designware: Add a fix_mac_speed hook' patch
> - Sort includes
> - Use debug() instead of printf() for error
> - Use function calls instead of fix_mac_speed() hook
> - Use new clk interface
> 
> Changes in v2:
> - Adjust to new hook name
> - Fix various coding style nits
> 
> Simon Glass (4):
>   net: designware: Adjust dw_adjust_link() to return an error
>   net: designware: Split the link init into a separate function
>   net: designware: Export the operation functions
>   rockchip: evb-rk3339: Enable DHCP
> 
> Sjoerd Simons (5):
>   net: designware: Export various functions/struct to allow subclassing
>   net: gmac_rk3288: Add RK3288 GMAC driver
>   rockchip: Enable networking support on rock2 and firefly
>   rockchip: Add PXE and DHCP to the default boot targets
>   rockchip: Drop Ethernet from the TODO
> 
>  configs/evb-rk3399_defconfig  |   3 +
>  configs/firefly-rk3288_defconfig  |   4 +
>  configs/rock2_defconfig   |   4 +
>  doc/README.rockchip   |   1 -
>  drivers/net/Kconfig   |   7 ++
>  drivers/net/Makefile  |   1 +
>  drivers/net/designware.c  |  57 ++
>  drivers/net/designware.h  |  13 
>  drivers/net/gmac_rk3288.c | 154
> ++ include/configs/rockchip-common.h | 
>  4 +-
>  10 files changed, 230 insertions(+), 18 deletions(-)
>  create mode 100644 drivers/net/gmac_rk3288.c

___
U-Boot mailing list

[U-Boot] [PATCH 2/2] common/board_f.c: align m68k arch to use CONFIG_DISPLAY_CPUINFO

[Angelo Dureghello]

Change all coldfire board files to use CONFIG_DISPLAY_CPUINFO.

Signed-off-by: Angelo Dureghello 
---
 configs/M5208EVBE_defconfig   | 1 +
 configs/M52277EVB_defconfig   | 1 +
 configs/M52277EVB_stmicro_defconfig   | 1 +
 configs/M5235EVB_Flash32_defconfig| 1 +
 configs/M5235EVB_defconfig| 1 +
 configs/M5249EVB_defconfig| 1 +
 configs/M5253DEMO_defconfig   | 1 +
 configs/M5253EVBE_defconfig   | 1 +
 configs/M5272C3_defconfig | 1 +
 configs/M5275EVB_defconfig| 1 +
 configs/M5282EVB_defconfig| 1 +
 configs/M53017EVB_defconfig   | 1 +
 configs/M5329AFEE_defconfig   | 1 +
 configs/M5329BFEE_defconfig   | 1 +
 configs/M5373EVB_defconfig| 1 +
 configs/M54418TWR_defconfig   | 1 +
 configs/M54418TWR_nand_mii_defconfig  | 1 +
 configs/M54418TWR_nand_rmii_defconfig | 1 +
 configs/M54418TWR_nand_rmii_lowfreq_defconfig | 1 +
 configs/M54418TWR_serial_mii_defconfig| 1 +
 configs/M54418TWR_serial_rmii_defconfig   | 1 +
 configs/M54451EVB_defconfig   | 1 +
 configs/M54451EVB_stmicro_defconfig   | 1 +
 configs/M54455EVB_a66_defconfig   | 1 +
 configs/M54455EVB_defconfig   | 1 +
 configs/M54455EVB_i66_defconfig   | 1 +
 configs/M54455EVB_intel_defconfig | 1 +
 configs/M54455EVB_stm33_defconfig | 1 +
 configs/M5475AFE_defconfig| 1 +
 configs/M5475BFE_defconfig| 1 +
 configs/M5475CFE_defconfig| 1 +
 configs/M5475DFE_defconfig| 1 +
 configs/M5475EFE_defconfig| 1 +
 configs/M5475FFE_defconfig| 1 +
 configs/M5475GFE_defconfig| 1 +
 configs/M5485AFE_defconfig| 1 +
 configs/M5485BFE_defconfig| 1 +
 configs/M5485CFE_defconfig| 1 +
 configs/M5485DFE_defconfig| 1 +
 configs/M5485EFE_defconfig| 1 +
 configs/M5485FFE_defconfig| 1 +
 configs/M5485GFE_defconfig| 1 +
 configs/M5485HFE_defconfig| 1 +
 configs/amcore_defconfig  | 1 +
 configs/astro_mcf5373l_defconfig  | 1 +
 configs/cobra5272_defconfig   | 1 +
 configs/eb_cpu5282_defconfig  | 1 +
 configs/eb_cpu5282_internal_defconfig | 1 +
 48 files changed, 48 insertions(+)

diff --git a/configs/M5208EVBE_defconfig b/configs/M5208EVBE_defconfig
index 405405d..f51dcaa 100644
--- a/configs/M5208EVBE_defconfig
+++ b/configs/M5208EVBE_defconfig
@@ -8,3 +8,4 @@ CONFIG_SYS_PROMPT="-> "
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
+CONFIG_DISPLAY_CPUINFO=y
diff --git a/configs/M52277EVB_defconfig b/configs/M52277EVB_defconfig
index f7aee4b..d700466 100644
--- a/configs/M52277EVB_defconfig
+++ b/configs/M52277EVB_defconfig
@@ -14,3 +14,4 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_CACHE=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DISPLAY_CPUINFO=y
diff --git a/configs/M52277EVB_stmicro_defconfig 
b/configs/M52277EVB_stmicro_defconfig
index 200bf35..f9bd959 100644
--- a/configs/M52277EVB_stmicro_defconfig
+++ b/configs/M52277EVB_stmicro_defconfig
@@ -13,3 +13,4 @@ CONFIG_CMD_I2C=y
 CONFIG_CMD_CACHE=y
 CONFIG_SPI_FLASH=y
 CONFIG_SPI_FLASH_STMICRO=y
+CONFIG_DISPLAY_CPUINFO=y
diff --git a/configs/M5235EVB_Flash32_defconfig 
b/configs/M5235EVB_Flash32_defconfig
index 6581802..22d835f 100644
--- a/configs/M5235EVB_Flash32_defconfig
+++ b/configs/M5235EVB_Flash32_defconfig
@@ -12,3 +12,4 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
+CONFIG_DISPLAY_CPUINFO=y
diff --git a/configs/M5235EVB_defconfig b/configs/M5235EVB_defconfig
index 15a7f1f..6d469f3 100644
--- a/configs/M5235EVB_defconfig
+++ b/configs/M5235EVB_defconfig
@@ -12,3 +12,4 @@ CONFIG_CMD_DHCP=y
 CONFIG_CMD_MII=y
 CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
+CONFIG_DISPLAY_CPUINFO=y
diff --git a/configs/M5249EVB_defconfig b/configs/M5249EVB_defconfig
index 2470aa2..b0fc2bb 100644
--- a/configs/M5249EVB_defconfig
+++ b/configs/M5249EVB_defconfig
@@ -8,3 +8,4 @@ CONFIG_LOOPW=y
 # CONFIG_CMD_SETEXPR is not set
 # CONFIG_CMD_NET is not set
 CONFIG_CMD_CACHE=y
+CONFIG_DISPLAY_CPUINFO=y
diff --git a/configs/M5253DEMO_defconfig b/configs/M5253DEMO_defconfig
index 621cb8f..ea8dc5c 100644
--- a/configs/M5253DEMO_defconfig
+++ b/configs/M5253DEMO_defconfig
@@ -8,3 +8,4 @@ CONFIG_CMD_PING=y
 CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT2=y
 CONFIG_CMD_FAT=y
+CONFIG_DISPLAY_CPUINFO=y
diff --git a/configs/M5253EVBE_defconfig b/configs/M5253EVBE_defconfig
index 4b81ba4..87904e7 100644
--- a/configs/M5253EVBE_defconfig
+++ b/configs/M5253EVBE_defconfig
@@ -8,3 +8,4 @@ 

[U-Boot] [PATCH 1/2] common/board_f.c: align m68k arch to use CONFIG_DISPLAY_CPUINFO

[Angelo Dureghello]

Change all coldfire arch files to use CONFIG_DISPLAY_CPUINFO.

Signed-off-by: Angelo Dureghello 
---
 arch/m68k/cpu/mcf5227x/cpu.c   |  4 +++-
 arch/m68k/cpu/mcf523x/cpu.c|  4 +++-
 arch/m68k/cpu/mcf52x2/cpu.c| 29 +
 arch/m68k/cpu/mcf530x/cpu.c|  4 +++-
 arch/m68k/cpu/mcf532x/cpu.c|  4 +++-
 arch/m68k/cpu/mcf5445x/cpu.c   |  4 +++-
 arch/m68k/cpu/mcf547x_8x/cpu.c |  4 +++-
 common/board_f.c   |  2 +-
 8 files changed, 40 insertions(+), 15 deletions(-)

diff --git a/arch/m68k/cpu/mcf5227x/cpu.c b/arch/m68k/cpu/mcf5227x/cpu.c
index 7d611de..63cffd3 100644
--- a/arch/m68k/cpu/mcf5227x/cpu.c
+++ b/arch/m68k/cpu/mcf5227x/cpu.c
@@ -28,7 +28,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return 0;
 };
 
-int checkcpu(void)
+#if defined(CONFIG_DISPLAY_CPUINFO)
+int print_cpuinfo(void)
 {
ccm_t *ccm = (ccm_t *) MMAP_CCM;
u16 msk;
@@ -60,3 +61,4 @@ int checkcpu(void)
 
return 0;
 }
+#endif /* CONFIG_DISPLAY_CPUINFO */
diff --git a/arch/m68k/cpu/mcf523x/cpu.c b/arch/m68k/cpu/mcf523x/cpu.c
index 67879c7..2e52939 100644
--- a/arch/m68k/cpu/mcf523x/cpu.c
+++ b/arch/m68k/cpu/mcf523x/cpu.c
@@ -28,7 +28,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return 0;
 }
 
-int checkcpu(void)
+#if defined(CONFIG_DISPLAY_CPUINFO)
+int print_cpuinfo(void)
 {
ccm_t *ccm = (ccm_t *) MMAP_CCM;
u16 msk;
@@ -56,6 +57,7 @@ int checkcpu(void)
 
return 0;
 };
+#endif /* CONFIG_DISPLAY_CPUINFO */
 
 #if defined(CONFIG_WATCHDOG)
 /* Called by macro WATCHDOG_RESET */
diff --git a/arch/m68k/cpu/mcf52x2/cpu.c b/arch/m68k/cpu/mcf52x2/cpu.c
index 5ec7609..7b27133 100644
--- a/arch/m68k/cpu/mcf52x2/cpu.c
+++ b/arch/m68k/cpu/mcf52x2/cpu.c
@@ -37,7 +37,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return 0;
 };
 
-int checkcpu(void)
+#if defined(CONFIG_DISPLAY_CPUINFO)
+int print_cpuinfo(void)
 {
char buf1[32], buf2[32];
 
@@ -47,6 +48,7 @@ int checkcpu(void)
   strmhz(buf2, gd->bus_clk));
return 0;
 };
+#endif /* CONFIG_DISPLAY_CPUINFO */
 
 #if defined(CONFIG_WATCHDOG)
 /* Called by macro WATCHDOG_RESET */
@@ -94,12 +96,13 @@ int watchdog_init(void)
 #endif /* #ifdef CONFIG_M5208 */
 
 #ifdef  CONFIG_M5271
+#if defined(CONFIG_DISPLAY_CPUINFO)
 /*
  * Both MCF5270 and MCF5271 are members of the MPC5271 family. Try to
  * determine which one we are running on, based on the Chip Identification
  * Register (CIR).
  */
-int checkcpu(void)
+int print_cpuinfo(void)
 {
char buf[32];
unsigned short cir; /* Chip Identification Register */
@@ -133,6 +136,7 @@ int checkcpu(void)
 
return 0;
 }
+#endif /* CONFIG_DISPLAY_CPUINFO */
 
 int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
@@ -184,7 +188,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return 0;
 };
 
-int checkcpu(void)
+#if defined(CONFIG_DISPLAY_CPUINFO)
+int print_cpuinfo(void)
 {
sysctrl_t *sysctrl = (sysctrl_t *) (MMAP_CFG);
uchar msk;
@@ -209,6 +214,7 @@ int checkcpu(void)
printf("Freescale MCF5272 %s\n", suf);
return 0;
 };
+#endif /* CONFIG_DISPLAY_CPUINFO */
 
 #if defined(CONFIG_WATCHDOG)
 /* Called by macro WATCHDOG_RESET */
@@ -268,7 +274,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return 0;
 };
 
-int checkcpu(void)
+#if defined(CONFIG_DISPLAY_CPUINFO)
+int print_cpuinfo(void)
 {
char buf[32];
 
@@ -276,7 +283,7 @@ int checkcpu(void)
strmhz(buf, CONFIG_SYS_CLK));
return 0;
 };
-
+#endif /* CONFIG_DISPLAY_CPUINFO */
 
 #if defined(CONFIG_WATCHDOG)
 /* Called by macro WATCHDOG_RESET */
@@ -326,7 +333,8 @@ int watchdog_init(void)
 #endif /* #ifdef CONFIG_M5275 */
 
 #ifdef CONFIG_M5282
-int checkcpu(void)
+#if defined(CONFIG_DISPLAY_CPUINFO)
+int print_cpuinfo(void)
 {
unsigned char resetsource = MCFRESET_RSR;
 
@@ -342,6 +350,7 @@ int checkcpu(void)
   (resetsource & MCFRESET_RSR_LVD) ? " Low Voltage" : "");
return 0;
 }
+#endif /* CONFIG_DISPLAY_CPUINFO */
 
 int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
@@ -351,7 +360,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 #endif
 
 #ifdef CONFIG_M5249
-int checkcpu(void)
+#if defined(CONFIG_DISPLAY_CPUINFO)
+int print_cpuinfo(void)
 {
char buf[32];
 
@@ -359,6 +369,7 @@ int checkcpu(void)
   strmhz(buf, CONFIG_SYS_CLK));
return 0;
 }
+#endif /* CONFIG_DISPLAY_CPUINFO */
 
 int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 {
@@ -372,7 +383,8 @@ int do_reset(cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
 #endif
 
 #ifdef CONFIG_M5253
-int checkcpu(void)
+#if 

Re: [U-Boot] [PATCH resend v3 2/6] drivers: usb: gadget: ether: access network_started using local variable

[Joe Hershberger]

On Thu, Nov 17, 2016 at 11:19 PM, Mugunthan V N  wrote:
> network_started of struct eth_dev can be accessed using local
> variable dev and no reason to access it with the global struct.
>
> Signed-off-by: Mugunthan V N 
> Reviewed-by: Simon Glass 

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

Re: [U-Boot] [RFC PATCH] common: miiphyutil: Work and report phy address in hex in mdio cmd

[Joe Hershberger]

On Wed, Nov 16, 2016 at 2:24 AM, Michal Simek  wrote:
> It is confusing that mdio commands work and report phy id as
> decimal value when mii is working with hex values.
>
> For example:
> ZynqMP> mdio list
> gem:
> 21 - TI DP83867 <--> ethernet@ff0e
> ZynqMP> mdio read ethernet@ff0e 0
> Reading from bus gem
> PHY at address 21:
> 0 - 0x1140
> ZynqMP> mii dump 21 0
> Incorrect PHY address. Range should be 0-31
> ...
> ZynqMP> mii dump 15
> 0. (1140) -- PHY control register --
>   (8000:) 0.15= 0reset
>
> U-Boot normally takes hex values that's why this patch is changing mdio
> command to handle hex instead of changing mii command to handle decimal
> values.
>
> Signed-off-by: Michal Simek 

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

Re: [U-Boot] [PATCH v3 1/6] drivers: usb: gadget: ether: adopt to usb driver model

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:02 AM, Simon Glass  wrote:
> Hi Mugunthan,
>
> On 24 November 2016 at 01:11, Mugunthan V N  wrote:
>> Hi Simon
>>
>> On Thursday 24 November 2016 07:51 AM, Simon Glass wrote:
>>> Hi Mugunthan,
>>>
>>> On 20 November 2016 at 22:38, Mugunthan V N  wrote:
 Hi Simon,

 On Saturday 19 November 2016 01:04 AM, Simon Glass wrote:
> Hi Mugunthan,
>
> On 17 November 2016 at 01:09, Mugunthan V N  wrote:
>> Convert usb ether gadget to adopt usb driver model
>>
>> Signed-off-by: Mugunthan V N 
>> Reviewed-by: Simon Glass 
>
> Sorry, but I'd like to 'un-review' this.
>
>> ---
>>  drivers/usb/gadget/ether.c | 36 
>>  1 file changed, 36 insertions(+)
>>
>> diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
>> index 497b981129..9bc61186cf 100644
>> --- a/drivers/usb/gadget/ether.c
>> +++ b/drivers/usb/gadget/ether.c
>> @@ -24,6 +24,10 @@
>>  #include "gadget_chips.h"
>>  #include "rndis.h"
>>
>> +#include 
>> +#include 
>> +#include 
>> +
>>  #define USB_NET_NAME "usb_ether"
>>
>>  #define atomic_read
>> @@ -101,6 +105,9 @@ struct eth_dev {
>> struct usb_gadget   *gadget;
>> struct usb_request  *req;   /* for control responses 
>> */
>> struct usb_request  *stat_req;  /* for cdc & rndis 
>> status */
>> +#ifdef CONFIG_DM_USB
>> +   struct udevice  *usb_udev;
>> +#endif
>>
>> u8  config;
>> struct usb_ep   *in_ep, *out_ep, *status_ep;
>> @@ -2303,6 +2310,24 @@ fail:
>>
>>  
>> /*-*/
>>
>> +#ifdef CONFIG_DM_USB
>> +int dm_usb_init(struct eth_dev *e_dev)
>> +{
>> +   struct udevice *dev = NULL;
>> +   int ret;
>> +
>> +   ret = uclass_first_device(UCLASS_USB_DEV_GENERIC, );
>> +   if (!dev || ret) {
>> +   error("No USB device found\n");
>> +   return -ENODEV;
>> +   }
>> +
>> +   e_dev->usb_udev = dev;
>> +
>> +   return ret;
>> +}
>> +#endif
>> +
>>  static int usb_eth_init(struct eth_device *netdev, bd_t *bd)
>>  {
>> struct eth_dev *dev = _ethdev;
>> @@ -2315,7 +2340,14 @@ static int usb_eth_init(struct eth_device 
>> *netdev, bd_t *bd)
>> goto fail;
>> }
>>
>> +#ifdef CONFIG_DM_USB
>> +   if (dm_usb_init(dev)) {
>> +   error("USB ether not found\n");
>> +   return -ENODEV;
>> +   }
>> +#else
>> board_usb_init(0, USB_INIT_DEVICE);
>> +#endif
>>
>> /* Configure default mac-addresses for the USB ethernet device */
>>  #ifdef CONFIG_USBNET_DEV_ADDR
>> @@ -2497,7 +2529,11 @@ void usb_eth_halt(struct eth_device *netdev)
>> }
>>
>> usb_gadget_unregister_driver(_driver);
>> +#ifdef CONFIG_DM_USB
>> +   device_remove(dev->usb_udev);
>> +#else
>> board_usb_cleanup(0, USB_INIT_DEVICE);
>> +#endif
>
> This doesn't look right to me. If your board is to be an Ethernet
> device then it should do:
>
> uclass_first_device(UCLASS_ETH, )
>
> to get the device. That could be in the device tree under the USB
> node, or perhaps you want to have a setup function which manualy binds
> the device, a bit like usb_find_and_bind_driver().
>

 This patch is to get usb device for the ether gadget. It uses the same
 api with UCLASS_USB_DEV_GENERIC to get usb device. The patch hadn't done
 for eth driver model adoption.
>>>
>>> So can you do that one first, or is it coming soon?
>>>
>>
>> Its already implemented above in the function dm_usb_init()
>
> So are you saying that the Ethernet 'USB device' driver needs to be
> converted to driver model? Otherwise what stops us from using
> UCLASS_ETH here?

I think the confusion might be that this is a USB gadget and it
doesn't support ETH DM yet. This code needs lots of clean-up. It is
still using the old Ethernet stack. This just makes the driver able to
function if you have USB DM enabled.

At least that how I understand this patch.

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

Re: [U-Boot] [PATCH 03/17] net: phy: Support Marvell 88E1680

[Joe Hershberger]

On Wed, Nov 23, 2016 at 9:12 AM, Mario Six  wrote:
> From: Dirk Eibach 
>
> Add support for Marvell 88E1680 Integrated Octal
> 10/100/1000 Mbps Energy Efficient Ethernet Transceiver.
>
> Signed-off-by: Dirk Eibach 
> ---
>  drivers/net/phy/marvell.c | 51 
> +++
>  1 file changed, 51 insertions(+)
>
> diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
> index 4eeb0f6..72f3f92 100644
> --- a/drivers/net/phy/marvell.c
> +++ b/drivers/net/phy/marvell.c
> @@ -480,6 +480,46 @@ static int m88e1310_config(struct phy_device *phydev)
> return genphy_config_aneg(phydev);
>  }
>
> +static int m88e1680_config(struct phy_device *phydev)
> +{
> +   /*
> +* As per Marvell Release Notes - Alaska V 88E1680 Rev A2
> +* Errata Section 4.1
> +*/
> +   u16 reg;
> +
> +   /* Matrix LED mode (not neede if single LED mode is used */
> +   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x0004);

I realize the 88e151* driver went in without my ack (35fa0dda: "net:
phy: marvell: add errata w/a for 88E151* chips"), and is loaded with
magic numbers, but let's not proliferate the problem. Please define
register offsets or use already-defined register offsets. If
reasonable, use defined field values to build values from defines and
something like bitfield_replace() from bitfield.h or clrsetbits_le32()
from asm/io.h. When it is a constant that represents an encoded
physical value that will never be used elsewhere, it's ok to just keep
the hard-coded number in the write, but it should be preceeded with a
comment that describes the actual meaning in engineering units and
prefereably the equation used to come up with the constant.  If you
have the information to improve the 151* implementation as well, that
would be very welcome.

> +   reg = phy_read(phydev, MDIO_DEVAD_NONE, 27);
> +   reg |= (1 << 5);
> +   phy_write(phydev, MDIO_DEVAD_NONE, 27, reg);
> +
> +   /* QSGMII TX amplitude change */
> +   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x00fd);
> +   phy_write(phydev, MDIO_DEVAD_NONE,  8, 0x0b53);
> +   phy_write(phydev, MDIO_DEVAD_NONE,  7, 0x200d);
> +   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x);
> +
> +   /* EEE initialization */
> +   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x00ff);
> +   phy_write(phydev, MDIO_DEVAD_NONE, 17, 0xb030);
> +   phy_write(phydev, MDIO_DEVAD_NONE, 16, 0x215c);
> +   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x00fc);
> +   phy_write(phydev, MDIO_DEVAD_NONE, 24, 0x888c);
> +   phy_write(phydev, MDIO_DEVAD_NONE, 25, 0x888c);
> +   phy_write(phydev, MDIO_DEVAD_NONE, 22, 0x);
> +   phy_write(phydev, MDIO_DEVAD_NONE,  0, 0x9140);
> +
> +   genphy_config_aneg(phydev);

This should check the return code and return it if negative.

> +
> +   /* soft reset */
> +   reg = phy_read(phydev, MDIO_DEVAD_NONE, MII_BMCR);
> +   reg |= BMCR_RESET;
> +   phy_write(phydev, MDIO_DEVAD_NONE, MII_BMCR, reg);
> +
> +   return 0;
> +}

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

Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel

[Rick Bronson]

Hi Heiko and Simon,

  Again, thank you both for your help, I really appreciate it!

  The good news is that I finally got it to boot fully into mainline
u-boot.  I switched gears and tried miniarm-rk3288_defconfig which
doesn't use the CONFIG_SPL_OF_PLATDATA option.  So now my build looks
like:

u-boot-denx:
cd $@; make miniarm-rk3288_defconfig CROSS_COMPILE="${CROSS_COMPILE}"
cd $@; make ${MK_PAR} all CROSS_COMPILE="${CROSS_COMPILE}"
$@/tools/mkimage -n rk3288 -T rksd -d $@/spl/u-boot-spl-dtb.bin
tftpboot/u-boot-dtb.bin; cat $@/u-boot-dtb.bin >> tftpboot/u-boot-dtb.bin

  and my flash looks like:

UPGD=./Linux_Upgrade_Tool_v1.21/upgrade_tool
sudo ${UPGD} db rkbin/rk32/rk3288_boot.bin
sleep 1
sudo ${UPGD} wl 64 tftpboot/u-boot-dtb.bin
sudo ${UPGD} rd

  So I'm pretty excited :)

  The strange thing is I still don't have emmc or my LED turning on
  from the device tree entry in rk3288-miniarm.dtsi (which I modified
  for my LED [ on GPIO0_B3]):

pwr-led {
gpios = < 11 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "default-on";
};

  Below is what I see when I boot.

  Cheers,

  Rick


U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 29 2016 - 14:19:08)


U-Boot 2016.11-00138-g136179b-dirty (Nov 29 2016 - 14:19:08 -0800)

Model: Miniarm-RK3288
DRAM:  2 GiB
MMC:   dwmmc@ff0c: 0
Card did not respond to voltage select!
*** Warning - MMC init failed, using default environment

In:serial
Out:   serial
Err:   serial
Net:   Net Initialization Skipped
No ethernet found.
Hit any key to stop autoboot:  0
=> md 0xFF75 4
ff75:    
=> md 0xFF79 4
ff79:    
=>


> Hi Rick,
>
> On 29 November 2016 at 11:22, Rick Bronson  wrote:
> > Hi Heiko and Simon,
> >
> >   Thank you both for your help, I really appreciate it.
> >
> >   No, I do not have the Linux mainline running yet as I was focusing
> > on getting the mainline u-boot running since I saw some references
> > that implied I may need that to use the mainline Linux.  I did try the
> > mainline kernel with the vendor-fork u-boot but got nothing pas the
> > "Loading Linux" line from u-boot.
> >
> >   I think what I will probably do is take the easy way out and use the
> > vendor-fork u-boot since that boots on this hardware.
> >
> >   But since I've invested some amount of time in the mainline u-boot
> > and it's drinving me mad that I can't seem to figure out what's wrong,
> > I do have one last question (hopefully).
>
> It would certainly make sense to invest in getting this running if you can.
>
> >
> >   I've got mainline u-boot getting this far (I added debug to show
> > what GPIO0 and 2 are outputting).
> >
> > 
> > U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 28 2016 - 13:29:59)
> > Trying to boot from MMC1
> > Card did not respond to voltage select! GPIO0=0x0 GPIO2=0x0
> > ...
> > 
> >
> >   I've modified rk3288-firefly.dts (the closest thing to hardware I
> > have) to set the eMMC reset line high but as you see above, nothing is
> > set on any GPIO.  This leads me to believe that I do not understand
> > how the device tree is loaded/used in SPL.  Can anyone point me to
> > help on whether I should use u-boot-spl-nodtb or u-boot-spl-dtb (I've
> > tried both) or how to debug if I am in fact even reading my dtb.
>
> You should be able to use 'gpio status' to see the GPIO state once you
> get to U-Boot.
>
> But if your board is booting SPL from MMC how can it possibly fail to
> load U-Boot from MMC? The MMC GPIO must already work for you to get
> this far. Or are you loading SPL from something other than MMC?
>
> You want u-boot-spl.bin (which includes the device tree).
>
> >
> >   Thanks again,
> >
> >   Rick
> >
> > PS.  My Makefile is here if you are so inclined:
> > http://members.efn.org/~rick/pub/Makefile  See the targets u-boot-denx
> > and uboot_new_flash to see what I've tried.
>
> You could push your tree somewhere or a patch showing what changes you
> have made.
>
> Regards,
> Simon
>
> >>
> >> From heiko at sntech.de Tue Nov 29 08:45:02 2016
> >> To: u-boot at lists.denx.de
> >> Cc: Simon Glass , Rick Bronson ,
> > "eddie.cai" ,
> > linux-rockchip at lists.infradead.org
> >> Subject: Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
> >> Date: Tue, 29 Nov 2016 11:20:52 +0100
> >>
> >> Hi Rick,
> >>
> >> Am Montag, 28. November 2016, 15:09:05 schrieb Simon Glass:
> >> > + A few rockchip people and linux-rockchip
> >> >
> >> > Hi Rick,
> >> >
> >> > On 25 November 2016 at 11:20, Rick Bronson  wrote:
> >> > > Hi All,
> >> > >
> >> > >   I've got unsupported RK3288 hardware running the latest git
u-boot to
> >> > >
> >> > > SPL as explained in
> >> > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip. 
My goal
> >> > > is to run the mainline 

[U-Boot] Please pull u-boot-mpc85xx master

[york sun]

Tom,

The following changes since commit 693d4c9f1dc40fcf24ced459bc4d1b46db33298a:

   spl: Remove CONFIG_SYS_U_BOOT_MAX_SIZE_SECTORS (2016-11-18 21:20:59 
-0500)

are available in the git repository at:

   git://git.denx.de/u-boot-mpc85xx.git

for you to fetch changes up to e8a390f0189c5868f2fa305004821bcfcd71d32c:

   powerpc: Drop default CONFIG_MAX_CPUS (2016-11-23 23:42:17 -0800)


York Sun (97):
   tools/env: Correct include kconfig
   powerpc: MPC8548: Move CONFIG_MPC8548 to Kconfig option
   powerpc: MPC8548CDS: Remove macro CONFIG_MPC8548CDS
   powerpc: MPC8544: Move CONFIG_MPC8544 to Kconfig option
   powerpc: MPC8544DS: Remove macro CONFIG_MPC8544DS
   powerpc: BSC9131/2: Move CONFIG_BSC9131/2 to Kconfig options
   powerpc: BSC9131RDB: Remove CONFIG_BSC9131RDB macro
   powerpc: BSC9132QDS: Remove CONFIG_BSC9132QDS macro
   powerpc: C29X: Move CONFIG_PPC_C29X to Kconfig option
   powerpc: C29XPCIE: Remove macro CONFIG_C29XPCIE
   powerpc: MPC8536: Move CONFIG_MPC8536 to Kconfig option
   powerpc: MPC8536DS: Remove macro CONFIG_MPC8536DS
   powerpc: mpc8540: Remove macro CONFIG_MPC8540
   powerpc: MPC8540ADS: Remove macro CONFIG_MPC8540ADS
   powerpc: mpc8541: Remove macro CONFIG_MPC8541
   powerpc: MPC8541CDS: Remove macro CONFIG_MPC8541CDS
   powerpc: MPC8555: Remove macro CONFIG_MPC8555
   powerpc: MPC8555CDS: Remove macro CONFIG_MPC8555CDS
   powerpc: MPC8560: Remove macro CONFIG_MPC8560
   powerpc: MPC8560ADS: Remove macro CONFIG_MPC8560ADS
   powerpc: MPC8568: Remove macro CONFIG_MPC8568
   powerpc: MPC8568MDS: Remove macro CONFIG_MPC8568MDS
   powerpc: MPC8569: Remove macro CONFIG_MPC8569
   powerpc: MPC8569MDS: Remove macro CONFIG_MPC8569MDS
   powerpc: MPC8572: Remove macro CONFIG_MPC8572
   powerpc: MPC8572DS: Remove macro CONFIG_MPC8572DS
   powerpc: xpedite: Remove macro CONFIG_XPEDITE5370
   powerpc: P1010: Remove macro CONFIG_P1010
   powerpc: P1010RDB: Remove macros CONFIG_P1010RDB_PA and 
CONFIG_P1010RDB_PB
   powerpc: P1022: Remove macro CONFIG_P1022
   powerpc: P1022DS: Remove macro CONFIG_P1022DS
   powerpc: P1023: Remove macro CONFIG_P1023
   powerpc: P1011: Remove macro CONFIG_P1011
   powerpc: P1012: Drop configuration for P1012
   powerpc: P1013: Drop configuration for P1013
   powerpc: P1014: Drop configuration for P1014
   powerpc: P1017: Drop configuration for P1017
   powerpc: P1020MBG: Separate from P1_P2_RDB_PC in Kconfig
   powerpc: P1020RDB-PC: Separate from P1_P2_RDB_PC in Kconfig
   powerpc: P1020RDB-PD: Separate from P1_P2_RDB_PC in Kconfig
   powerpc: P1020UTM: Separate from P1_P2_RDB_P2 in Kconfig
   powerpc: P1021RDB: Separate from P1_P2_RDB_PC in Kconfig
   powerpc: P1024RDB: Separate from P1_P2_RDB_PC in Kconfig
   powerpc: P1025RDB: Separate from P1_P2_RDB_PC in Kconfig
   powerpc: P2020RDB-PC: Separate from P1_P2_RDB_PC in Kconfig
   powerpc: P1_P2_RDB_PC: Drop TARGET_P1_P2_RDB_PC
   powerpc: P1020: Remove macro CONFIG_P1020
   powerpc: P1021: Remove macro CONFIG_P1021
   powerpc: P1024: Remove CONFIG_P1024
   powerpc: P1025: Remove macro CONFIG_P1025
   powerpc: P2020: Remove macro CONFIG_P2020
   powerpc: P2010: Drop configuration for P2010
   powerpc: P2041: Remove macro CONFIG_PPC_P2041
   powerpc: P2041RDB: Remove macro CONFIG_P2041RDB
   powerpc: P3041: Remove macro CONFIG_PPC_P3041
   powerpc: P3041DS: Remove macro CONFIG_P3041DS
   powerpc: P4080: Remove macro CONFIG_PPC_P4080
   powerpc: P4080DS: Remove macro CONFIG_P4080DS
   powerpc: P5020: Remove macro CONFIG_PPC_P5020
   powerpc: P5020DS: Remove macro CONFIG_P5020DS
   powerpc: P5040: Remove macro CONFIG_P5040
   powerpc: P5040DS: Remove macro CONFIG_P5040DS
   powerpc: B4420QDS: Split from B4860QDS in Kconfig
   powerpc: B4860: Remove macro CONFIG_PPC_B4860
   powerpc: B4860QDS: Remove macro CONFIG_B4860QDS
   powerpc: B4420: Remove macro CONFIG_PPC_B4420
   powerpc: QEMU_E500: Remove macro CONFIG_QEMU_E500
   powerpc: T102xRDB: Split as T1023RDB and T1024RDB
   powerpc: T1023: Remove macro CONFIG_PPC_T1023
   powerpc: T1024QDS: Rename Kconfig option to match the name
   powerpc: T1024: Remove macro CONFIG_PPC_T1024
   powerpc: T104XRDB: Split to T1040RDB and T1042RDB in Kconfig
   powerpc: T1040: Remove macro CONFIG_PPC_T1040
   powerpc: T1040D4RDB: Separate from T1040RDB in Kconfig
   powerpc: T1040RDB: Remove macro CONFIG_T1040RDB
   powerpc: T1042: Remove macro CONFIG_PPC_T1042
   powerpc: T1042RDB_PI: Split from T1042RDB in Kconfig
   powerpc: T1042D4RDB: Separate from T1042RDB in Kconfig
   powerpc: T1042RDB: Remove macro CONFIG_T1042RDB
   powerpc: T104xRDB: Remove macro CONFIG_T104xRDB and T104xD4RDB
   

Re: [U-Boot] [PATCH v3 5/9] ARM: stm32: use clock setup function defined in clock.c

[Joe Hershberger]

On Thu, Nov 24, 2016 at 1:10 PM, Michael Kurz  wrote:
> Use the clock setup function defined in clock.c instead of setting the
> clock bits directly in the drivers.
> Remove register definitions of RCC in rcc.h as these are already
> defined in the struct in stm32.h
>
> Signed-off-by: Michael Kurz 

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

Re: [U-Boot] [PATCH v3 5/9] net: gmac_rk3288: Add RK3288 GMAC driver

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass  wrote:
> From: Sjoerd Simons 
>
> Add a new driver for the GMAC ethernet interface present in Rockchip
> RK3288 SOCs. This driver subclasses the generic design-ware driver to
> add the glue needed specifically for Rockchip.
>
> Signed-off-by: Sjoerd Simons 
> Signed-off-by: Simon Glass 

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

[U-Boot] [PATCH v3 4/7] arm: omap5: Add TEE loading support

[Andrew F. Davis]

From: Harinarayan Bhatta 

secure_tee_install is used to install and initialize a secure TEE OS such as
Linaro OP-TEE into the secure world. This function takes in the address
where the signed TEE image is loaded as an argument. The signed TEE image
consists of a header (struct tee_header), TEE code+data followed by the
signature generated using image signing tool from TI security development
package (SECDEV). Refer to README.ti-secure for more information.

This function uses 2 new secure APIs.

1. PPA_SERV_HAL_TEE_LOAD_MASTER - Must be called on CPU Core 0. Protected
   memory for TEE must be reserved before calling this function. This API
   needs arguments filled into struct ppa_tee_load_info. The TEE image is
   authenticated and if there are no errors, the control passes to the TEE
   entry point.

2. PPA_SERV_HAL_TEE_LOAD_SLAVE - Called on other CPU cores only after
   a TEE_LOAD_MASTER call. Takes no arguments. Checks if TEE was
   successfully loaded (on core 0) and transfers control to the same TEE
   entry point.

The code at TEE entry point is expected perform OS initialization steps
and return back to non-secure world (U-Boot).

Signed-off-by: Harinarayan Bhatta 
Signed-off-by: Andrew F. Davis 
---
 arch/arm/include/asm/omap_sec_common.h |   6 ++
 arch/arm/mach-omap2/omap5/sec-fxns.c   | 108 +
 include/tee/optee.h|  30 +
 3 files changed, 144 insertions(+)
 create mode 100644 include/tee/optee.h

diff --git a/arch/arm/include/asm/omap_sec_common.h 
b/arch/arm/include/asm/omap_sec_common.h
index 4bde93f..79f1fbd 100644
--- a/arch/arm/include/asm/omap_sec_common.h
+++ b/arch/arm/include/asm/omap_sec_common.h
@@ -51,4 +51,10 @@ int secure_emif_reserve(void);
  */
 int secure_emif_firewall_lock(void);
 
+/*
+ * Invoke a secure HAL API to authenticate and install a Trusted Execution
+ * Environment (TEE) image.
+ */
+int secure_tee_install(u32 tee_image);
+
 #endif /* _OMAP_SEC_COMMON_H_ */
diff --git a/arch/arm/mach-omap2/omap5/sec-fxns.c 
b/arch/arm/mach-omap2/omap5/sec-fxns.c
index 33d4ea4..7fab575 100644
--- a/arch/arm/mach-omap2/omap5/sec-fxns.c
+++ b/arch/arm/mach-omap2/omap5/sec-fxns.c
@@ -19,13 +19,30 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 /* Index for signature PPA-based TI HAL APIs */
 #define PPA_HAL_SERVICES_START_INDEX(0x200)
+#define PPA_SERV_HAL_TEE_LOAD_MASTER(PPA_HAL_SERVICES_START_INDEX + 23)
+#define PPA_SERV_HAL_TEE_LOAD_SLAVE (PPA_HAL_SERVICES_START_INDEX + 24)
 #define PPA_SERV_HAL_SETUP_SEC_RESVD_REGION (PPA_HAL_SERVICES_START_INDEX + 25)
 #define PPA_SERV_HAL_SETUP_EMIF_FW_REGION   (PPA_HAL_SERVICES_START_INDEX + 26)
 #define PPA_SERV_HAL_LOCK_EMIF_FW   (PPA_HAL_SERVICES_START_INDEX + 27)
 
+int tee_loaded = 0;
+
+/* Argument for PPA_SERV_HAL_TEE_LOAD_MASTER */
+struct ppa_tee_load_info {
+   u32 tee_sec_mem_start; /* Physical start address reserved for TEE */
+   u32 tee_sec_mem_size;  /* Size of the memory reserved for TEE */
+   u32 tee_cert_start;/* Address where signed TEE binary is loaded */
+   u32 tee_cert_size; /* Size of TEE certificate (signed binary) */
+   u32 tee_jump_addr; /* Address to jump to start TEE execution */
+   u32 tee_arg0;  /* argument to TEE jump function, in r0 */
+};
+
 static u32 get_sec_mem_start(void)
 {
u32 sec_mem_start = CONFIG_TI_SECURE_EMIF_REGION_START;
@@ -124,3 +141,94 @@ int secure_emif_firewall_lock(void)
 
return result;
 }
+
+static struct ppa_tee_load_info tee_info __aligned(ARCH_DMA_MINALIGN);
+
+int secure_tee_install(u32 addr)
+{
+   struct optee_header *hdr;
+   void *loadptr;
+   u32 tee_file_size;
+   u32 sec_mem_start = get_sec_mem_start();
+   const u32 size = CONFIG_TI_SECURE_EMIF_PROTECTED_REGION_SIZE;
+   u32 *smc_cpu1_params;
+   u32 ret;
+
+   /* If there is no protected region, there is no place to put the TEE */
+   if (size == 0) {
+   printf("Error loading TEE, no protected memory region 
available\n");
+   return -ENOBUFS;
+   }
+
+   hdr = (struct optee_header *)map_sysmem(addr, sizeof(struct 
optee_header));
+   /* 280 bytes = size of signature */
+   tee_file_size = hdr->init_size + hdr->paged_size +
+   sizeof(struct optee_header) + 280;
+
+   if ((hdr->magic != OPTEE_MAGIC) ||
+   (hdr->version != OPTEE_VERSION) ||
+   (hdr->init_load_addr_hi != 0) ||
+   (hdr->init_load_addr_lo < (sec_mem_start + sizeof(struct 
optee_header))) ||
+   (tee_file_size > size) ||
+   ((hdr->init_load_addr_lo + tee_file_size - 1) >
+(sec_mem_start + size - 1))) {
+   printf("Error in TEE header. Check load address and sizes\n");
+   unmap_sysmem(hdr);
+   return CMD_RET_FAILURE;
+   }
+
+   

[U-Boot] [PATCH v3 5/7] arm: omap5: Add OPTEE node to fdt

[Andrew F. Davis]

Add an OPTEE node to the FDT when TEE installation has completed
successfully. This informs the kernel of the presence of OPTEE.

Signed-off-by: Andrew F. Davis 
---
 arch/arm/mach-omap2/omap5/fdt.c | 35 ++-
 1 file changed, 34 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-omap2/omap5/fdt.c b/arch/arm/mach-omap2/omap5/fdt.c
index da8d59b..afa0037 100644
--- a/arch/arm/mach-omap2/omap5/fdt.c
+++ b/arch/arm/mach-omap2/omap5/fdt.c
@@ -212,6 +212,38 @@ static int ft_hs_fixup_dram(void *fdt, bd_t *bd)
 static int ft_hs_fixup_dram(void *fdt, bd_t *bd) { return 0; }
 #endif
 
+static int ft_hs_add_tee(void *fdt, bd_t *bd)
+{
+   const char *path, *subpath;
+   int offs;
+
+   extern int tee_loaded;
+   if (!tee_loaded)
+   return 0;
+
+   path = "/";
+   offs = fdt_path_offset(fdt, path);
+
+   subpath = "firmware";
+   offs = fdt_add_subnode(fdt, offs, subpath);
+   if (offs < 0) {
+   printf("Could not create %s node.\n", subpath);
+   return 1;
+   }
+
+   subpath = "optee";
+   offs = fdt_add_subnode(fdt, offs, subpath);
+   if (offs < 0) {
+   printf("Could not create %s node.\n", subpath);
+   return 1;
+   }
+
+   fdt_setprop_string(fdt, offs, "compatible", "linaro,optee-tz");
+   fdt_setprop_string(fdt, offs, "method", "smc");
+
+   return 0;
+}
+
 static void ft_hs_fixups(void *fdt, bd_t *bd)
 {
/* Check we are running on an HS/EMU device type */
@@ -219,7 +251,8 @@ static void ft_hs_fixups(void *fdt, bd_t *bd)
if ((ft_hs_fixup_crossbar(fdt, bd) == 0) &&
(ft_hs_disable_rng(fdt, bd) == 0) &&
(ft_hs_fixup_sram(fdt, bd) == 0) &&
-   (ft_hs_fixup_dram(fdt, bd) == 0))
+   (ft_hs_fixup_dram(fdt, bd) == 0) &&
+   (ft_hs_add_tee(fdt, bd) == 0))
return;
} else {
printf("ERROR: Incorrect device type (GP) detected!");
-- 
2.10.2

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

[U-Boot] [PATCH v3 7/7] board: ti: am57xx: add FIT image TEE processing

[Andrew F. Davis]

Populate the corresponding TEE image processing call to be
performed during FIT loadable processing.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
---
 board/ti/am57xx/board.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/ti/am57xx/board.c b/board/ti/am57xx/board.c
index f3e3f0b..1895a30 100644
--- a/board/ti/am57xx/board.c
+++ b/board/ti/am57xx/board.c
@@ -739,4 +739,11 @@ void board_fit_image_post_process(void **p_image, size_t 
*p_size)
 {
secure_boot_verify_image(p_image, p_size);
 }
+
+void board_tee_image_process(ulong tee_image, size_t tee_size)
+{
+   secure_tee_install((u32)tee_image);
+}
+
+U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TEE, board_tee_image_process);
 #endif
-- 
2.10.2

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

[U-Boot] [PATCH v3 2/7] image: Add Trusted Execution Environment image type

[Andrew F. Davis]

Add a new image type representing Trusted Execution Environment (TEE)
image types. For example, an OP-TEE OS binary image.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 common/image.c  | 1 +
 include/image.h | 1 +
 2 files changed, 2 insertions(+)

diff --git a/common/image.c b/common/image.c
index 2aac90d..bd07e86 100644
--- a/common/image.c
+++ b/common/image.c
@@ -165,6 +165,7 @@ static const table_entry_t uimage_type[] = {
{   IH_TYPE_ZYNQIMAGE,  "zynqimage",  "Xilinx Zynq Boot Image" },
{   IH_TYPE_ZYNQMPIMAGE, "zynqmpimage", "Xilinx ZynqMP Boot Image" 
},
{   IH_TYPE_FPGA,   "fpga",   "FPGA Image" },
+   {   IH_TYPE_TEE,"tee","Trusted Execution 
Environment Image",},
{   -1, "",   "",   },
 };
 
diff --git a/include/image.h b/include/image.h
index b96b8eb..575f592 100644
--- a/include/image.h
+++ b/include/image.h
@@ -279,6 +279,7 @@ enum {
IH_TYPE_ZYNQMPIMAGE,/* Xilinx ZynqMP Boot Image */
IH_TYPE_FPGA,   /* FPGA Image */
IH_TYPE_VYBRIDIMAGE,/* VYBRID .vyb Image */
+   IH_TYPE_TEE,/* Trusted Execution Environment OS Image */
 
IH_TYPE_COUNT,  /* Number of image types */
 };
-- 
2.10.2

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

[U-Boot] [PATCH v3 0/7] Add FIT loadable custom processing

[Andrew F. Davis]

Hello all,

To see the background on this see here[0].

As Simon suggested we are now using a linker list to keep any and all TEE
specific code out of common files as, unlike kernel, dtb, and ramdisk
TEE images may not be used by needed by all users.

The last 5 patches in this series are an example of how one can now add a
handler for an image type for their platform.

Thanks,
Andrew

[0] http://lists.denx.de/pipermail/u-boot/2016-November/272614.html

Changes from v2:
 - Moved generic OP-TEE definitions to common location
 - Check return value from SMC call
 - Added patch to add OP-TEE node to kernel fdt, this was missing
 from the last set to complete the working solution

Changes from v1:
 - Added some additional documentation
 - Last 4 patches are now the compleate working TEE loading solution for
 our DRA7xx/AM57xx platforms, not just an example

Andrew F. Davis (5):
  image: Add FIT image loadable section custom processing
  image: Add Trusted Execution Environment image type
  arm: omap5: Add OPTEE node to fdt
  board: ti: dra7xx: add FIT image TEE processing
  board: ti: am57xx: add FIT image TEE processing

Harinarayan Bhatta (2):
  arm: omap5: Add function to make an SMC call on cpu1
  arm: omap5: Add TEE loading support

 arch/arm/include/asm/omap_common.h |   1 +
 arch/arm/include/asm/omap_sec_common.h |   6 ++
 arch/arm/mach-omap2/omap5/Makefile |   1 +
 arch/arm/mach-omap2/omap5/fdt.c|  35 +++-
 arch/arm/mach-omap2/omap5/sec-fxns.c   | 108 +
 arch/arm/mach-omap2/omap5/sec_entry_cpu1.S | 123 +
 board/ti/am57xx/board.c|   7 ++
 board/ti/dra7xx/evm.c  |   7 ++
 common/image.c |  34 
 doc/uImage.FIT/source_file_format.txt  |   4 +-
 include/image.h|  31 
 include/tee/optee.h|  30 +++
 12 files changed, 385 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
 create mode 100644 include/tee/optee.h

-- 
2.10.2

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

[U-Boot] [PATCH v3 1/7] image: Add FIT image loadable section custom processing

[Andrew F. Davis]

To help automate the loading of custom image types we add the ability
to define custom handlers for the loadable section types. When we find
a compatible type while loading a "loadable" image from a FIT image we
run its associated handlers to perform any additional steps needed for
loading this image.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
---
 common/image.c| 33 +
 doc/uImage.FIT/source_file_format.txt |  4 +++-
 include/image.h   | 30 ++
 3 files changed, 66 insertions(+), 1 deletion(-)

diff --git a/common/image.c b/common/image.c
index 7604494..2aac90d 100644
--- a/common/image.c
+++ b/common/image.c
@@ -1389,6 +1389,23 @@ int boot_get_fpga(int argc, char * const argv[], 
bootm_headers_t *images,
 }
 #endif
 
+static void fit_loadable_process(uint8_t img_type,
+ulong img_data,
+ulong img_len)
+{
+   int i;
+   const unsigned int count =
+   ll_entry_count(struct fit_loadable_tbl, fit_loadable);
+   struct fit_loadable_tbl *fit_loadable_handler =
+   ll_entry_start(struct fit_loadable_tbl, fit_loadable);
+   /* For each loadable handler */
+   for (i = 0; i < count; i++, fit_loadable_handler++)
+   /* matching this type */
+   if (fit_loadable_handler->type == img_type)
+   /* call that handler with this image data */
+   fit_loadable_handler->handler(img_data, img_len);
+}
+
 int boot_get_loadable(int argc, char * const argv[], bootm_headers_t *images,
uint8_t arch, const ulong *ld_start, ulong * const ld_len)
 {
@@ -1407,6 +1424,7 @@ int boot_get_loadable(int argc, char * const argv[], 
bootm_headers_t *images,
int conf_noffset;
int fit_img_result;
const char *uname;
+   uint8_t img_type;
 
/* Check to see if the images struct has a FIT configuration */
if (!genimg_has_config(images)) {
@@ -1447,6 +1465,21 @@ int boot_get_loadable(int argc, char * const argv[], 
bootm_headers_t *images,
/* Something went wrong! */
return fit_img_result;
}
+
+   fit_img_result = fit_image_get_node(buf, uname);
+   if (fit_img_result < 0) {
+   /* Something went wrong! */
+   return fit_img_result;
+   }
+   fit_img_result = fit_image_get_type(buf,
+   fit_img_result,
+   _type);
+   if (fit_img_result < 0) {
+   /* Something went wrong! */
+   return fit_img_result;
+   }
+
+   fit_loadable_process(img_type, img_data, img_len);
}
break;
default:
diff --git a/doc/uImage.FIT/source_file_format.txt 
b/doc/uImage.FIT/source_file_format.txt
index 91aa89a..afff301 100644
--- a/doc/uImage.FIT/source_file_format.txt
+++ b/doc/uImage.FIT/source_file_format.txt
@@ -256,7 +256,9 @@ o config@1
 (component image node of a "fpga type").
   - loadables : Unit name containing a list of additional binaries to be
 loaded at their given locations.  "loadables" is a comma-separated list
-of strings. U-Boot will load each binary at its given start-address.
+of strings. U-Boot will load each binary at its given start-address and
+may optionaly invoke additional post-processing steps on this binary based
+on its component image node type.
 
 The FDT blob is required to properly boot FDT based kernel, so the minimal
 configuration for 2.6 FDT kernel is (kernel, fdt) pair.
diff --git a/include/image.h b/include/image.h
index 8131595..b96b8eb 100644
--- a/include/image.h
+++ b/include/image.h
@@ -1271,4 +1271,34 @@ int board_fit_config_name_match(const char *name);
 void board_fit_image_post_process(void **p_image, size_t *p_size);
 #endif /* CONFIG_SPL_FIT_IMAGE_POST_PROCESS */
 
+/**
+ * Mapping of image types to function handlers to be invoked on the associated
+ * loaded images
+ *
+ * @type: Type of image, I.E. IH_TYPE_*
+ * @handler: Function to call on loaded image
+ */
+struct fit_loadable_tbl {
+   int type;
+   /**
+* handler() - Process a loaded image
+*
+* @data: Pointer to start of loaded image data
+* @size: Size of loaded image data
+*/
+   void (*handler)(ulong data, size_t size);
+};
+
+/*
+ * Define a FIT loadable image type handler
+ *
+ * _type is a valid uimage_type ID as defined in the "Image Type" enum above
+ * _handler is the handler function to call after this 

[U-Boot] [PATCH v3 6/7] board: ti: dra7xx: add FIT image TEE processing

[Andrew F. Davis]

Populate the corresponding TEE image processing call to be
performed during FIT loadable processing.

Signed-off-by: Andrew F. Davis 
Reviewed-by: Simon Glass 
Reviewed-by: Tom Rini 
---
 board/ti/dra7xx/evm.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/board/ti/dra7xx/evm.c b/board/ti/dra7xx/evm.c
index 3c16846..3bb895c 100644
--- a/board/ti/dra7xx/evm.c
+++ b/board/ti/dra7xx/evm.c
@@ -848,4 +848,11 @@ void board_fit_image_post_process(void **p_image, size_t 
*p_size)
 {
secure_boot_verify_image(p_image, p_size);
 }
+
+void board_tee_image_process(ulong tee_image, size_t tee_size)
+{
+   secure_tee_install((u32)tee_image);
+}
+
+U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TEE, board_tee_image_process);
 #endif
-- 
2.10.2

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

[U-Boot] [PATCH v3 3/7] arm: omap5: Add function to make an SMC call on cpu1

[Andrew F. Davis]

From: Harinarayan Bhatta 

On DRA7xx platform, CPU Core 1 is not used in u-boot. However, in some
cases it is need to make secure API calls from Core 1. This patch adds
an assembly function to make a secure (SMC) call from CPU Core #1.

Signed-off-by: Harinarayan Bhatta 
Signed-off-by: Andrew F. Davis 
Reviewed-by: Tom Rini 
---
 arch/arm/include/asm/omap_common.h |   1 +
 arch/arm/mach-omap2/omap5/Makefile |   1 +
 arch/arm/mach-omap2/omap5/sec_entry_cpu1.S | 123 +
 3 files changed, 125 insertions(+)
 create mode 100644 arch/arm/mach-omap2/omap5/sec_entry_cpu1.S

diff --git a/arch/arm/include/asm/omap_common.h 
b/arch/arm/include/asm/omap_common.h
index 605c549..290a190 100644
--- a/arch/arm/include/asm/omap_common.h
+++ b/arch/arm/include/asm/omap_common.h
@@ -632,6 +632,7 @@ void omap_smc1(u32 service, u32 val);
  * security (HS) device variants by doing a specially-formed smc entry.
  */
 u32 omap_smc_sec(u32 service, u32 proc_id, u32 flag, u32 *params);
+u32 omap_smc_sec_cpu1(u32 service, u32 proc_id, u32 flag, u32 *params);
 
 void enable_edma3_clocks(void);
 void disable_edma3_clocks(void);
diff --git a/arch/arm/mach-omap2/omap5/Makefile 
b/arch/arm/mach-omap2/omap5/Makefile
index 0212df7..af17a3d 100644
--- a/arch/arm/mach-omap2/omap5/Makefile
+++ b/arch/arm/mach-omap2/omap5/Makefile
@@ -15,3 +15,4 @@ obj-y += abb.o
 obj-y  += fdt.o
 obj-$(CONFIG_IODELAY_RECALIBRATION) += dra7xx_iodelay.o
 obj-$(CONFIG_TI_SECURE_DEVICE) += sec-fxns.o
+obj-$(CONFIG_DRA7XX) += sec_entry_cpu1.o
diff --git a/arch/arm/mach-omap2/omap5/sec_entry_cpu1.S 
b/arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
new file mode 100644
index 000..c2a35ee
--- /dev/null
+++ b/arch/arm/mach-omap2/omap5/sec_entry_cpu1.S
@@ -0,0 +1,123 @@
+/*
+ * Secure entry function for CPU Core #1
+ *
+ * (C) Copyright 2016
+ * Texas Instruments, 
+ *
+ * Author :
+ * Harinarayan Bhatta 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+.arch_extension sec
+
+#if !defined(CONFIG_SYS_DCACHE_OFF)
+.global flush_dcache_range
+#endif
+
+#define AUX_CORE_BOOT_00x48281800
+#define AUX_CORE_BOOT_10x48281804
+
+#ifdef CONFIG_DRA7XX
+/* DRA7xx ROM code function "startup_BootSlave". This function is where CPU1
+ * waits on WFE, polling on AUX_CORE_BOOT_x registers.
+ * This address is same for J6 and J6 Eco.
+ */
+#define ROM_FXN_STARTUP_BOOTSLAVE 0x00038a64
+#endif
+
+/* Assembly core where CPU1 is woken up into
+ * No need to save-restore registers, does not use stack.
+ */
+LENTRY(cpu1_entry)
+   ldr r4, =omap_smc_sec_cpu1_args
+   ldm r4, {r0,r1,r2,r3}   @ Retrieve args
+
+   mov r6, #0xFF   @ Indicate new Task call
+   mov r12, #0x00  @ Secure Service ID in R12
+
+   dsb
+   dmb
+   smc 0   @ SMC #0 to enter monitor mode
+
+   b   .Lend   @ exit at end of the service execution
+   nop
+
+   @ In case of IRQ happening in Secure, then ARM will branch here.
+   @ At that moment, IRQ will be pending and ARM will jump to Non Secure
+   @ IRQ handler
+   mov r12, #0xFE
+
+   dsb
+   dmb
+   smc 0   @ SMC #0 to enter monitor mode
+
+.Lend:
+   ldr r4, =omap_smc_sec_cpu1_args
+   str r0, [r4, #0x10] @ save return value
+   ldr r4, =AUX_CORE_BOOT_0
+   mov r5, #0x0
+   str r5, [r4]
+   ldr r4, =ROM_FXN_STARTUP_BOOTSLAVE
+   sev @ Tell CPU0 we are done
+   bx  r4  @ Jump back to ROM
+END(cpu1_entry)
+
+/*
+ * u32 omap_smc_sec_cpu1(u32 service, u32 proc_id, u32 flag, u32 *params);
+ *
+ * Makes a secure ROM/PPA call on CPU Core #1 on supported platforms.
+ * Assumes that CPU #1 is waiting in ROM code and not yet woken up or used by
+ * u-boot.
+ */
+ENTRY(omap_smc_sec_cpu1)
+   push{r4, r5, lr}
+   ldr r4, =omap_smc_sec_cpu1_args
+   stm r4, {r0,r1,r2,r3}   @ Save args to memory
+#if !defined(CONFIG_SYS_DCACHE_OFF)
+   mov r0, r4
+   mov r1, #CONFIG_SYS_CACHELINE_SIZE
+   add r1, r0, r1  @ dcache is not enabled on CPU1, so
+   blx flush_dcache_range  @ flush the cache on args buffer
+#endif
+   ldr r4, =AUX_CORE_BOOT_1
+   ldr r5, =cpu1_entry
+   str r5, [r4]@ Setup CPU1 entry function
+   ldr r4, =AUX_CORE_BOOT_0
+   mov r5, #0x10
+   str r5, [r4]@ Tell ROM to exit while loop
+   sev @ Wake up CPU1
+.Lwait:
+   wfe @ Wait for CPU1 to finish
+   nop
+   ldr r5, [r4]@ Check if CPU1 is done
+   cmp r5, #0
+   bne .Lwait
+
+   ldr 

Re: [U-Boot] [PATCH v3 4/9] net: designware: Export the operation functions

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass  wrote:
> Export all functions so that drivers can use them, or not, as the need
> arises.
>
> Signed-off-by: Simon Glass 

With a minor nit below,

Acked-by: Joe Hershberger 

> ---
>
> Changes in v3:
> - Add new patch to export the operation functions
>
> Changes in v2: None
>
>  drivers/net/designware.c | 19 +--
>  drivers/net/designware.h |  9 +
>  2 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> index 0c596a7..f242fc6 100644
> --- a/drivers/net/designware.c
> +++ b/drivers/net/designware.c
> @@ -271,7 +271,7 @@ static void _dw_eth_halt(struct dw_eth_dev *priv)
> phy_shutdown(priv->phydev);
>  }
>
> -static int _dw_eth_init(struct dw_eth_dev *priv, u8 *enetaddr)
> +int designware_eth_init(struct dw_eth_dev *priv, u8 *enetaddr)

Modern functions are called "_start", not init. Also, this already
uses stop below, instead of halt. It would be nice to keep them
symmetric.

>  {
> struct eth_mac_regs *mac_p = priv->mac_regs_p;
> struct eth_dma_regs *dma_p = priv->dma_regs_p;
> @@ -330,7 +330,7 @@ static int _dw_eth_init(struct dw_eth_dev *priv, u8 
> *enetaddr)
> return 0;
>  }
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 3/9] net: designware: Split the link init into a separate function

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass  wrote:
> With rockchip we need to make adjustments after the link speed is set but
> before enabling received/transmit. In preparation for this, split these
> two pieces into separate functions.
>
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v3 1/9] net: designware: Export various functions/struct to allow subclassing

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass  wrote:
> From: Sjoerd Simons 
>
> To allow other DM drivers to subclass the designware driver various
> functions and structures need to be exported. Export these.
>
> Signed-off-by: Sjoerd Simons 
> Reviewed-by: Bin Meng 
> Acked-by: Simon Glass 
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH] sunxi: move CONFIG_SATAPWR to Kconfig option

[Tom Rini]

On Tue, Nov 29, 2016 at 10:17:42PM +0100, Maxime Ripard wrote:
> Hi Tom,
> 
> On Tue, Nov 29, 2016 at 04:11:38PM -0500, Tom Rini wrote:
> > On Tue, Nov 29, 2016 at 09:39:32PM +0100, Maxime Ripard wrote:
> > > On Mon, Nov 28, 2016 at 02:20:10PM +0100, Hans de Goede wrote:
> > > > HI,
> > > > 
> > > > On 28-11-16 13:42, Maxime Ripard wrote:
> > > > > Hi Hans,
> > > > > 
> > > > > On Fri, Nov 25, 2016 at 09:12:30AM +0100, Hans de Goede wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 24-11-16 22:22, Maxime Ripard wrote:
> > > > > > > On Wed, Nov 23, 2016 at 07:28:16PM +0100, Jelle van der Waa wrote:
> > > > > > > > Introduce a new CONFIG_SATAPWR Kconfig option to replace the
> > > > > > > > option in CONFIG_SYS_EXTRA_OPTIONS.
> > > > > > > > 
> > > > > > > > Signed-off-by: Jelle van der Waa 
> > > > > > > > ---
> > > > > > > >  board/sunxi/Kconfig|  7 +++
> > > > > > > >  board/sunxi/board.c| 11 ++-
> > > > > > > >  configs/A10-OLinuXino-Lime_defconfig   |  3 ++-
> > > > > > > >  configs/A20-OLinuXino-Lime2_defconfig  |  3 ++-
> > > > > > > >  configs/A20-OLinuXino-Lime_defconfig   |  3 ++-
> > > > > > > >  configs/A20-OLinuXino_MICRO_defconfig  |  3 ++-
> > > > > > > >  configs/A20-Olimex-SOM-EVB_defconfig   |  3 ++-
> > > > > > > >  configs/Cubieboard2_defconfig  |  3 ++-
> > > > > > > >  configs/Cubieboard_defconfig   |  3 ++-
> > > > > > > >  configs/Cubietruck_defconfig   |  3 ++-
> > > > > > > >  configs/Itead_Ibox_A20_defconfig   |  3 ++-
> > > > > > > >  configs/Lamobo_R1_defconfig|  3 ++-
> > > > > > > >  configs/Linksprite_pcDuino3_Nano_defconfig |  3 ++-
> > > > > > > >  configs/Linksprite_pcDuino3_defconfig  |  3 ++-
> > > > > > > >  configs/Sinovoip_BPI_M3_defconfig  |  2 +-
> > > > > > > >  configs/orangepi_plus_defconfig|  3 ++-
> > > > > > > >  16 files changed, 40 insertions(+), 19 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> > > > > > > > index ae2fba1..fe2f7b4 100644
> > > > > > > > --- a/board/sunxi/Kconfig
> > > > > > > > +++ b/board/sunxi/Kconfig
> > > > > > > > @@ -667,6 +667,13 @@ config GMAC_TX_DELAY
> > > > > > > > ---help---
> > > > > > > > Set the GMAC Transmit Clock Delay Chain value.
> > > > > > > > 
> > > > > > > > +config SATAPWR
> > > > > > > > +   string "power pin for SATA"
> > > > > > > > +   default ""
> > > > > > > > +   ---help---
> > > > > > > > +   Set the power pin for SATA. This takes a string in the 
> > > > > > > > format
> > > > > > > > +   understood by sunxi_name_to_gpio, e.g. PH1 for pin 1 of 
> > > > > > > > port H.
> > > > > > > > +
> > > > > > > 
> > > > > > > This looks like a rather generic option. Can't this be in
> > > > > > > drivers/block instead?
> > > > > > 
> > > > > > The proper solution would be to get the info from devicetree,
> > > > > > which requires regulator support, which we don't have yet
> > > > > > for sunxi. In the mean time getting rid of the need for
> > > > > > CONFIG_SYS_EXTRA_OPTIONS is a worthwhile goal in itself
> > > > > > IMHO.
> > > > > 
> > > > > Yes, but a GPIO to enable the SATA 5V rail seems like a rather common
> > > > > thing, and definitely not Allwinner specific.
> > > > > 
> > > > > Moving that option to drivers/block would make more sense I guess.
> > > > 
> > > > Hmm, but in the end this should be removed, as everything should'
> > > > be using devicetree, so I'm not convinced it is a good idea
> > > > to introduce a generic option for this.
> > > > 
> > > > Anyways either way is fine with me.
> > > 
> > > I don't know, in the end, not all platforms will be converted to
> > > device tree, so it still might be something worth adding.
> > 
> > We also don't want to get hung up on fixing sub-optional solutions while
> > also converting to Kconfig.  We can move the option now and see about
> > re-naming or getting the information elsewhere afterwards.  Thanks!
> 
> I'm not sure I got what you wanted. Do you want it to be merged in
> drivers/block as a generic option, or in board/sunxi as a
> platform-specific one?

I'm fine with either place.  Today it's used just on sunxi as a config
option with that name, so board/sunxi/Kconfig and make a note to
investigate how all of the other platforms that have this issue handle
it.  For example, my gut (based on some other imx6 stuff I've been
doing) is that on imx6 they just fiddle the GPIO and not have it in
Kconfig because rather than 1 board.c and N defconfig files they have
(roughly) N board.c files and N defconfigs.

-- 
Tom


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

Re: [U-Boot] [PATCH 01/11] net: dw: Add read_rom_hwaddr net_op hook

[Joe Hershberger]

On Tue, Nov 29, 2016 at 3:40 PM, Simon Glass  wrote:
> Hi Joe,
>
> On 29 November 2016 at 14:24, Joe Hershberger  
> wrote:
>>
>> Hi Simon,
>>
>> On Thu, Nov 17, 2016 at 7:13 PM, Simon Glass  wrote:
>> > Hi Oliver,
>> >
>> > On 8 November 2016 at 08:54, Olliver Schinagl  wrote:
>> >> Add the read_rom_hwaddr net_op hook so that it can be called from boards
>> >> to read the mac from a ROM chip.
>> >>
>> >> Signed-off-by: Olliver Schinagl 
>> >> ---
>> >>  drivers/net/designware.c | 18 ++
>> >>  1 file changed, 18 insertions(+)
>> >>
>> >> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
>> >> index 9e6d726..aa87f30 100644
>> >> --- a/drivers/net/designware.c
>> >> +++ b/drivers/net/designware.c
>> >> @@ -230,6 +230,23 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv, 
>> >> u8 *mac_id)
>> >> return 0;
>> >>  }
>> >>
>> >> +__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr)
>> >> +{
>> >> +   return -ENOSYS;
>> >> +}
>> >
>> > Instead of a weak function I think this should use driver model, with
>> > a driver supplied by the board to read this value. It should be
>> > possible to supply the 'hardware-address reading' device to any
>> > Ethernet driver, not just dwmmc.
>>
>> How do we reconcile something like that with the concern of using the
>> device tree for boards using only Linux bindings, and sharing the
>> device tree with Linux? Linux probably doesn't care about this and so
>> won't have a binding for defining this relationship. This is a fairly
>> generic question. Where have we landed on this?
>
> So far I have not seen something that cannot be solved either as I
> suggest above or with platform data.
>
> Often you can pass platform data to the driver - e.g. see the end of
> board_init() in gurnard.c which tells the video driver which LCD to
> use.
>
> Is there another case? I certainly have ideas but don't want to create
> something without a solid case.

I hadn't understood what pattern you were referring to when you said
"with a driver supplied by the board to read this value."  I just
reviewed the rockchip series that you referred to and I think that
pattern works pretty cleanly.

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

Re: [U-Boot] [PATCHv2 1/5] fsl: serdes: ensure accessing the initialized maps of serdes protocol

[york sun]

On 08/02/2016 04:14 AM, Zhiqiang Hou wrote:
> From: Hou Zhiqiang 
>
> Up to now, the function is_serdes_configed() doesn't check if the map
> of serdes protocol is initialized before accessing it. The function
> is_serdes_configed() will get wrong result when it was called before
> the serdes protocol maps initialized. As the first element of the map
> isn't used for any device, so use it as the flag to indicate if the
> map has been initialized.
>
> Signed-off-by: Hou Zhiqiang 
> ---
> V2:
>  - Check initialization-state of the serdes protocol map before serdes init.
>  - Comment the element 'NONE' used as a initialization-state flag.

Zhiqiang,

This patch has been merged but I found an issue with it today. Please 
try to boot P4080DS from NOR flash. It causes recursive calls
fsl_serdes_init()->p4080_erratum_serdes_a005()->is_serdes_configured()->fsl_serdes_init().
 
Please check if you have any similar recursive case for other platforms. 
Please send a fix ASAP.

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

Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel

[Heiko Stübner]

Am Dienstag, 29. November 2016, 14:40:49 schrieb Simon Glass:
> Hi Rick,
> 
> On 29 November 2016 at 11:22, Rick Bronson  wrote:
> > Hi Heiko and Simon,
> > 
> >   Thank you both for your help, I really appreciate it.
> >   
> >   No, I do not have the Linux mainline running yet as I was focusing
> > 
> > on getting the mainline u-boot running since I saw some references
> > that implied I may need that to use the mainline Linux.  I did try the
> > mainline kernel with the vendor-fork u-boot but got nothing pas the
> > "Loading Linux" line from u-boot.
> > 
> >   I think what I will probably do is take the easy way out and use the
> > 
> > vendor-fork u-boot since that boots on this hardware.
> > 
> >   But since I've invested some amount of time in the mainline u-boot
> > 
> > and it's drinving me mad that I can't seem to figure out what's wrong,
> > I do have one last question (hopefully).
> 
> It would certainly make sense to invest in getting this running if you can.
> 
> >   I've got mainline u-boot getting this far (I added debug to show
> > 
> > what GPIO0 and 2 are outputting).
> > 
> > 
> > U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 28 2016 - 13:29:59)
> > Trying to boot from MMC1
> > Card did not respond to voltage select! GPIO0=0x0 GPIO2=0x0
> > ...
> > 
> > 
> >   I've modified rk3288-firefly.dts (the closest thing to hardware I
> > 
> > have) to set the eMMC reset line high but as you see above, nothing is
> > set on any GPIO.  This leads me to believe that I do not understand
> > how the device tree is loaded/used in SPL.  Can anyone point me to
> > help on whether I should use u-boot-spl-nodtb or u-boot-spl-dtb (I've
> > tried both) or how to debug if I am in fact even reading my dtb.
> 
> You should be able to use 'gpio status' to see the GPIO state once you
> get to U-Boot.
> 
> But if your board is booting SPL from MMC how can it possibly fail to
> load U-Boot from MMC? The MMC GPIO must already work for you to get
> this far. Or are you loading SPL from something other than MMC?

Or you can try enabling the 
CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
option, which will simply let the on-chip rom also load the 2nd stage uboot 
seemingly using the same method as for the spl.

I'm currently testing Simon's network patches and this option works quite 
nicely.


Heiko

> You want u-boot-spl.bin (which includes the device tree).
> 
> >   Thanks again,
> >   
> >   Rick
> > 
> > PS.  My Makefile is here if you are so inclined:
> > http://members.efn.org/~rick/pub/Makefile  See the targets u-boot-denx
> > and uboot_new_flash to see what I've tried.
> 
> You could push your tree somewhere or a patch showing what changes you
> have made.
> 
> Regards,
> Simon
> 
> >> From he...@sntech.de Tue Nov 29 08:45:02 2016
> >> To: u-boot@lists.denx.de
> >> Cc: Simon Glass , Rick Bronson ,
> > 
> > "eddie.cai" ,
> > linux-rockc...@lists.infradead.org
> > 
> >> Subject: Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
> >> Date: Tue, 29 Nov 2016 11:20:52 +0100
> >> 
> >> Hi Rick,
> >> 
> >> Am Montag, 28. November 2016, 15:09:05 schrieb Simon Glass:
> >> > + A few rockchip people and linux-rockchip
> >> > 
> >> > Hi Rick,
> >> > 
> >> > On 25 November 2016 at 11:20, Rick Bronson  wrote:
> >> > > Hi All,
> >> > > 
> >> > >   I've got unsupported RK3288 hardware running the latest git u-boot
> >> > >   to
> >> > > 
> >> > > SPL as explained in
> >> > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip.  My
> >> > > goal
> >> > > is to run the mainline (ie. not Android) Linux kernel on this
> >> > > hardware
> >> > > 
> >> > > and wondered:
> >> > >  - Do I need to get the latest git u-boot to run before I can run the
> >> > > 
> >> > > mainline kernel?  Or can I use
> >> > > github.com/linux-rockchip/u-boot-rockchip.git, which I have running
> >> > > u-boot fully.
> >> > 
> >> > It's up to you - obviously mainline is where the development should
> >> > be, but there is no requirement that I know of.
> >> 
> >> correct, the (mainline-)kernel runs just fine on both the vendor-fork of
> > 
> > uboot
> > 
> >> as well as on mainline.
> >> 
> >> > Does mainline run on your board?
> >> > 
> >> > >  - The device tree seems to be in two places, once via:
> >> > > resource_tool --image=resource2.img --pack linux/logo.bmp
> >> > > ${DTS}.dtb
> >> > >   
> >> > >   that gets put into the resource file and then again at the end of
> >> > >   the
> >> > > 
> >> > > kernel via CONFIG_ARM_APPENDED_DTB.  Do I need both?  When I do both
> >> > > I get things like:
> >> > > 
> >> > > Unknow param: MACHINE_MODEL:rk30sdk!
> >> > > Unknow param: MACHINE_ID:007!
> >> 
> >> ARM_APPEND_DTB is meant for boards where the bootloader cannot load the
> >> devicetree (to old or so) and also cannot be reasonably exchanged. So the
> >> append-mechanism was invented to allow 

Re: [U-Boot] [PATCH v3 2/9] net: designware: Adjust dw_adjust_link() to return an error

[Joe Hershberger]

On Sun, Nov 27, 2016 at 11:01 AM, Simon Glass  wrote:
> This function can fail, so return the error if there is one.
>
> Signed-off-by: Simon Glass 

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

Re: [U-Boot] [PATCH v4 0/6] Add ARMv8 PSCI framework

[york sun]

On 11/28/2016 06:06 PM, Hongbo Zhang wrote:
> Hi York,
> This generic PSCI is controlled by CONFIG_ARMV8_PSCI, if enabled, any
> platform can implement their own PSCI functions under this framework,
> this is all similar with ARMv7's.
>
> While PPA is controlled by CONFIG_FSL_LS_PPA, and the private PSCI
> inside the PPA is controlled by FSL_PPA_ARMV8_PSCI,  this macro
> depends on and selected by CONFIG_FSL_LS_PPA.
>
> That is to say, they are using separate configs, and only one of them
> can be enabled at one time.
>

That's what I am looking for. So these two options are mutually 
exclusive. But you don't have that in Kconfig. I can run menuconfig and 
get this result in .config file

#
# Layerscape PPA
#
CONFIG_FSL_LS_PPA=y
CONFIG_FSL_PPA_ARMV8_PSCI=y
CONFIG_SYS_FSL_ERRATUM_A010539=y
CONFIG_ARMV8_MULTIENTRY=y
# CONFIG_ARMV8_SPIN_TABLE is not set
CONFIG_ARMV8_PSCI=y
CONFIG_ARMV8_PSCI_NR_CPUS=4
CONFIG_ARMV8_PSCI_CPUS_PER_CLUSTER=0
CONFIG_IDENT_STRING=""
# CONFIG_PRE_CONSOLE_BUFFER is not set
# CONFIG_VIDEO is not set

You can see both options can be enabled from menuconfig. Please see 
comments in other patches as well.

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

Re: [U-Boot] [PATCHv3 09/15] pci: layerscape: add pci driver based on DM

[Simon Glass]

Hi,

On 27 November 2016 at 22:59, Z.Q. Hou  wrote:
> Hi Simon,
>
> Thanks for your comments!
>
>> -Original Message-
>> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>> Sent: 2016年11月28日 1:02
>> To: Z.Q. Hou 
>> Cc: U-Boot Mailing List ; Albert ARIBAUD
>> ; Prabhakar Kushwaha
>> ; Huan Wang-B18965
>> ; Sumit Garg ; Ruchika
>> Gupta ; Saksham Jain
>> ; york sun ; M.H. Lian
>> ; Bin Meng ; Mingkai Hu
>> 
>> Subject: Re: [PATCHv3 09/15] pci: layerscape: add pci driver based on DM
>>
>> Hi,
>>
>> On 24 November 2016 at 02:28, Z.Q. Hou  wrote:
>> > Hi Simon,
>> >
>> > Thanks for your comments!
>> >
>> >> -Original Message-
>> >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
>> >> Sent: 2016年11月24日 10:21
>> >> To: Z.Q. Hou 
>> >> Cc: U-Boot Mailing List ; Albert ARIBAUD
>> >> ; Prabhakar Kushwaha
>> >> ; Huan Wang-B18965
>> >> ; Sumit Garg ;
>> Ruchika
>> >> Gupta ; Saksham Jain
>> >> ; york sun ; M.H.
>> >> Lian ; Bin Meng ;
>> Mingkai
>> >> Hu 
>> >> Subject: Re: [PATCHv3 09/15] pci: layerscape: add pci driver based on
>> >> DM
>> >>
>> >> Hi,
>> >>
>> >> On 22 November 2016 at 02:25, Z.Q. Hou  wrote:
>> >> > Hi Simon,
>> >> >
>> >> > Sorry for my delay respond due to out of the office several days,
>> >> > and thanks
>> >> a lot for your comments!
>> >> >
>> >> >> -Original Message-
>> >> >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon
>> >> >> Glass
>> >> >> Sent: 2016年11月18日 9:15
>> >> >> To: Z.Q. Hou 
>> >> >> Cc: U-Boot Mailing List ; Albert ARIBAUD
>> >> >> ; Prabhakar Kushwaha
>> >> >> ; Huan Wang-B18965
>> >> >> ; Sumit Garg ;
>> >> Ruchika
>> >> >> Gupta ; Saksham Jain
>> >> >> ; york sun ;
>> M.H.
>> >> >> Lian ; Bin Meng ;
>> >> Mingkai
>> >> >> Hu 
>> >> >> Subject: Re: [PATCHv3 09/15] pci: layerscape: add pci driver based
>> >> >> on DM
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> On 16 November 2016 at 02:48, Zhiqiang Hou 
>> >> >> wrote:
>> >> >> > From: Minghuan Lian 
>> >> >> >
>> >> >> > There are more than five kinds of Layerscape SoCs.
>> >> >> > unfortunately, PCIe controller of each SoC is a little bit
>> >> >> > different. In order to avoid too many macro definitions, the
>> >> >> > patch addes a new implementation of PCIe driver based on DM.
>> >> >> > PCIe dts node is used to describe the difference.
>> >> >> >
>> >> >> > Signed-off-by: Minghuan Lian 
>> >> >> > Signed-off-by: Hou Zhiqiang 
>> >> >> > ---
>> >> >> > V3:
>> >> >> >  - No change
>> >> >> >
>> >> >> >  drivers/pci/Kconfig   |   8 +
>> >> >> >  drivers/pci/pcie_layerscape.c | 761
>> >> >> > ++
>> >> >> >  2 files changed, 769 insertions(+)
>> >> >> >
>> >>
>> >> >> > +#ifdef CONFIG_FSL_LSCH3
>> >> >>
>> >> >> Can this be a run-time check?
>> >> >
>> >> > No, it is for Linux DT fixup and these functions is needed only by
>> >> > FSL_LSCH3
>> >> SoCs.
>> >>
>> >> I mean that you cannot have an #ifdef in a driver - it should be done
>> >> at run-time by looking at the compatible strings.
>> >
>> > This driver work for many platforms, but this fixup is only used by
>> > FSL_LSCH3 SoCs, if check the compatible string at run-time, the fixup will 
>> > be
>> still compiled for the platform which doesn't need it.
>> > Why compile it into the binary for the platform which doesn't need it?
>>
>> Because that's how it works. Drivers are drivers for their hardware.
>> We cannot compile them differently depending on who might use them...
>>
>> If this is a big problem you could split the driver into multiple parts 
>> perhaps. But
>> what exactly is the problem here?
>
> It isn't a big problem, actually it is just kernel DT fixup function, and it 
> doesn't affect the u-boot pcie driver.
> But the fixup is LSCH3 SoC special, and some macros are only defined in 
> header file of LSCH3, e.g. FSL_PEX_STREAM_ID_*.
> So cannot removed the #ifdef CONFIG_FSL_LSCH3.

Really there should be two separate drivers, with a 

Re: [U-Boot] [PATCH 1/6] net: dw: Add read_rom_hwaddr net_op hook

[Simon Glass]

Hi Oliver,

On 28 November 2016 at 03:38, Olliver Schinagl  wrote:
> On 27-11-16 18:02, Simon Glass wrote:
>>
>> Hi,
>>
>> On 25 November 2016 at 08:38, Olliver Schinagl  wrote:
>>>
>>> Add the read_rom_hwaddr net_op hook so that it can be called from boards
>>> to read the mac from a ROM chip.
>>>
>>> Signed-off-by: Olliver Schinagl 
>>> ---
>>>   drivers/net/designware.c | 16 
>>>   1 file changed, 16 insertions(+)
>>>
>>> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
>>> index 9e6d726..3f2f67c 100644
>>> --- a/drivers/net/designware.c
>>> +++ b/drivers/net/designware.c
>>> @@ -230,6 +230,21 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv,
>>> u8 *mac_id)
>>>  return 0;
>>>   }
>>>
>>> +__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr, int id)
>>> +{
>>> +   return -ENOSYS;
>>> +}
>>> +
>>> +static int designware_eth_read_rom_hwaddr(struct udevice *dev)
>>> +{
>>> +   struct eth_pdata *pdata = dev_get_platdata(dev);
>>> +
>>> +   if (!dev)
>>> +   return -ENOSYS;
>>> +
>>> +   return dw_board_read_rom_hwaddr(pdata->enetaddr, dev->seq);
>>> +}
>>> +
>>>   static void dw_adjust_link(struct eth_mac_regs *mac_p,
>>> struct phy_device *phydev)
>>>   {
>>> @@ -685,6 +700,7 @@ static const struct eth_ops designware_eth_ops = {
>>>  .free_pkt   = designware_eth_free_pkt,
>>>  .stop   = designware_eth_stop,
>>>  .write_hwaddr   = designware_eth_write_hwaddr,
>>> +   .read_rom_hwaddr= designware_eth_read_rom_hwaddr,
>>>   };
>>>
>>>   static int designware_eth_ofdata_to_platdata(struct udevice *dev)
>>
>> You should not call board code from a driver. But since this is a
>> sunxi driver, why not move all the code that reads the serial number
>> into this file?
>
> Hey Simon,
>
> unless I missunderstand, this is how Joe suggested in a while ago, and how
> it has been implemented in a few other drivers. Can you elaborate a bit
> more?

Yes...drivers must not call into board-specific code, nor have
board-specific #defines. This limits their usefulness for other
boards.

Adding hooks like this (particularly with the word 'board' in the
name) should be avoided.

We end up with bidirectional coupling between the board and the
driver. The board should use the driver but not the other way around.
I understand that you are trying to get around this by using a weak
function, but with driver model I'm really trying hard to avoid weak
functions. They normally indicate an ad-hoc API and can generally be
avoided with a bit more design thought.

If you have a standard way of reading the serial number which is
supported by all sunxi boards, then you should be able to add your
changes to the sunxi Ethernet driver (which uses designware.c?). Then
you can leave the designware.c code alone and avoid adding a hook.

In a sense you end up subclassing the designware driver.

Also see this series which deals with a similar problem with rockchip:

http://lists.denx.de/pipermail/u-boot/2016-November/274256.html

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

Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel

[Simon Glass]

Hi Rick,

On 29 November 2016 at 11:22, Rick Bronson  wrote:
> Hi Heiko and Simon,
>
>   Thank you both for your help, I really appreciate it.
>
>   No, I do not have the Linux mainline running yet as I was focusing
> on getting the mainline u-boot running since I saw some references
> that implied I may need that to use the mainline Linux.  I did try the
> mainline kernel with the vendor-fork u-boot but got nothing pas the
> "Loading Linux" line from u-boot.
>
>   I think what I will probably do is take the easy way out and use the
> vendor-fork u-boot since that boots on this hardware.
>
>   But since I've invested some amount of time in the mainline u-boot
> and it's drinving me mad that I can't seem to figure out what's wrong,
> I do have one last question (hopefully).

It would certainly make sense to invest in getting this running if you can.

>
>   I've got mainline u-boot getting this far (I added debug to show
> what GPIO0 and 2 are outputting).
>
> 
> U-Boot SPL 2016.11-00138-g136179b-dirty (Nov 28 2016 - 13:29:59)
> Trying to boot from MMC1
> Card did not respond to voltage select! GPIO0=0x0 GPIO2=0x0
> ...
> 
>
>   I've modified rk3288-firefly.dts (the closest thing to hardware I
> have) to set the eMMC reset line high but as you see above, nothing is
> set on any GPIO.  This leads me to believe that I do not understand
> how the device tree is loaded/used in SPL.  Can anyone point me to
> help on whether I should use u-boot-spl-nodtb or u-boot-spl-dtb (I've
> tried both) or how to debug if I am in fact even reading my dtb.

You should be able to use 'gpio status' to see the GPIO state once you
get to U-Boot.

But if your board is booting SPL from MMC how can it possibly fail to
load U-Boot from MMC? The MMC GPIO must already work for you to get
this far. Or are you loading SPL from something other than MMC?

You want u-boot-spl.bin (which includes the device tree).

>
>   Thanks again,
>
>   Rick
>
> PS.  My Makefile is here if you are so inclined:
> http://members.efn.org/~rick/pub/Makefile  See the targets u-boot-denx
> and uboot_new_flash to see what I've tried.

You could push your tree somewhere or a patch showing what changes you
have made.

Regards,
Simon

>>
>> From he...@sntech.de Tue Nov 29 08:45:02 2016
>> To: u-boot@lists.denx.de
>> Cc: Simon Glass , Rick Bronson ,
> "eddie.cai" ,
> linux-rockc...@lists.infradead.org
>> Subject: Re: [U-Boot] Rockchip RK3288 u-boot with mainline kernel
>> Date: Tue, 29 Nov 2016 11:20:52 +0100
>>
>> Hi Rick,
>>
>> Am Montag, 28. November 2016, 15:09:05 schrieb Simon Glass:
>> > + A few rockchip people and linux-rockchip
>> >
>> > Hi Rick,
>> >
>> > On 25 November 2016 at 11:20, Rick Bronson  wrote:
>> > > Hi All,
>> > >
>> > >   I've got unsupported RK3288 hardware running the latest git u-boot to
>> > >
>> > > SPL as explained in
>> > > http://git.denx.de/?p=u-boot.git;a=blob;f=doc/README.rockchip.  My goal
>> > > is to run the mainline (ie. not Android) Linux kernel on this hardware
>> > >
>> > > and wondered:
>> > >  - Do I need to get the latest git u-boot to run before I can run the
>> > >
>> > > mainline kernel?  Or can I use
>> > > github.com/linux-rockchip/u-boot-rockchip.git, which I have running
>> > > u-boot fully.
>> >
>> > It's up to you - obviously mainline is where the development should
>> > be, but there is no requirement that I know of.
>>
>> correct, the (mainline-)kernel runs just fine on both the vendor-fork of
> uboot
>> as well as on mainline.
>>
>>
>> > Does mainline run on your board?
>> >
>> > >  - The device tree seems to be in two places, once via:
>> > > resource_tool --image=resource2.img --pack linux/logo.bmp
>> > > ${DTS}.dtb
>> > >
>> > >   that gets put into the resource file and then again at the end of the
>> > >
>> > > kernel via CONFIG_ARM_APPENDED_DTB.  Do I need both?  When I do both
>> > > I get things like:
>> >
>> > > Unknow param: MACHINE_MODEL:rk30sdk!
>> > > Unknow param: MACHINE_ID:007!
>>
>> ARM_APPEND_DTB is meant for boards where the bootloader cannot load the
>> devicetree (to old or so) and also cannot be reasonably exchanged. So the
>> append-mechanism was invented to allow bundling the devicetree with the
> actual
>> kernel image, so that to the bootloader it looks like just any other kernel
>> image.
>>
>> So you essentially only need one or the other. Also at least mainline uboot
>> also supports the FIT image type, where you can bundle the devicetree in a
>> more generalized way.
>>
>> For your message I would guess the kernel didn't find a usable devicetree
>> somehow and was falling back to ATAGS-based board selection?
>>
>>
>
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 01/11] net: dw: Add read_rom_hwaddr net_op hook

[Simon Glass]

Hi Joe,

On 29 November 2016 at 14:24, Joe Hershberger  wrote:
>
> Hi Simon,
>
> On Thu, Nov 17, 2016 at 7:13 PM, Simon Glass  wrote:
> > Hi Oliver,
> >
> > On 8 November 2016 at 08:54, Olliver Schinagl  wrote:
> >> Add the read_rom_hwaddr net_op hook so that it can be called from boards
> >> to read the mac from a ROM chip.
> >>
> >> Signed-off-by: Olliver Schinagl 
> >> ---
> >>  drivers/net/designware.c | 18 ++
> >>  1 file changed, 18 insertions(+)
> >>
> >> diff --git a/drivers/net/designware.c b/drivers/net/designware.c
> >> index 9e6d726..aa87f30 100644
> >> --- a/drivers/net/designware.c
> >> +++ b/drivers/net/designware.c
> >> @@ -230,6 +230,23 @@ static int _dw_write_hwaddr(struct dw_eth_dev *priv, 
> >> u8 *mac_id)
> >> return 0;
> >>  }
> >>
> >> +__weak int dw_board_read_rom_hwaddr(unsigned char *enetaddr)
> >> +{
> >> +   return -ENOSYS;
> >> +}
> >
> > Instead of a weak function I think this should use driver model, with
> > a driver supplied by the board to read this value. It should be
> > possible to supply the 'hardware-address reading' device to any
> > Ethernet driver, not just dwmmc.
>
> How do we reconcile something like that with the concern of using the
> device tree for boards using only Linux bindings, and sharing the
> device tree with Linux? Linux probably doesn't care about this and so
> won't have a binding for defining this relationship. This is a fairly
> generic question. Where have we landed on this?

So far I have not seen something that cannot be solved either as I
suggest above or with platform data.

Often you can pass platform data to the driver - e.g. see the end of
board_init() in gurnard.c which tells the video driver which LCD to
use.

Is there another case? I certainly have ideas but don't want to create
something without a solid case.

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