Re: [U-Boot] [PATCH v2 07/11] drivers: usb: musb: add ti musb peripheral driver with driver model support

[Mugunthan V N]

On Tuesday 10 May 2016 06:09 PM, Marek Vasut wrote:
> On 05/10/2016 01:48 PM, Mugunthan V N wrote:
>> Add a TI MUSB peripheral driver with driver model support and the
>> driver will be bound by the MUSB wrapper driver based on the
>> dr_mode device tree entry.
>>
>> Signed-off-by: Mugunthan V N 
>> ---
>>  drivers/usb/musb-new/musb_uboot.c |   2 +
>>  drivers/usb/musb-new/ti-musb.c| 113 
>> ++
>>  2 files changed, 115 insertions(+)
>>
>> diff --git a/drivers/usb/musb-new/musb_uboot.c 
>> b/drivers/usb/musb-new/musb_uboot.c
>> index 6ce528c..b03b556 100644
>> --- a/drivers/usb/musb-new/musb_uboot.c
>> +++ b/drivers/usb/musb-new/musb_uboot.c
>> @@ -373,6 +373,7 @@ struct dm_usb_ops musb_usb_ops = {
>>  #endif /* CONFIG_DM_USB */
>>  #endif /* CONFIG_USB_MUSB_HOST */
>>  
>> +#ifndef CONFIG_DM_USB
>>  #ifdef CONFIG_USB_MUSB_GADGET
>>  static struct musb *gadget;
>>  
>> @@ -453,3 +454,4 @@ int musb_register(struct musb_hdrc_platform_data *plat, 
>> void *bdata,
>>  
>>  return 0;
>>  }
>> +#endif /* CONFIG_DM_USB */
>> diff --git a/drivers/usb/musb-new/ti-musb.c b/drivers/usb/musb-new/ti-musb.c
>> index 1c15aa2..11d10aa 100644
>> --- a/drivers/usb/musb-new/ti-musb.c
>> +++ b/drivers/usb/musb-new/ti-musb.c
>> @@ -14,6 +14,7 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>>  #include 
>>  #include 
>>  #include "musb_uboot.h"
>> @@ -142,6 +143,110 @@ static int ti_musb_ofdata_to_platdata(struct udevice 
>> *dev)
>>  return 0;
>>  }
>>  
>> +static struct musb *gadget;
>> +
>> +int usb_gadget_handle_interrupts(int index)
>> +{
>> +WATCHDOG_RESET();
>> +if (!gadget || !gadget->isr)
>> +return -EINVAL;
>> +
>> +return gadget->isr(0, gadget);
>> +}
>> +
>> +int usb_gadget_register_driver(struct usb_gadget_driver *driver)
>> +{
>> +int ret;
>> +
>> +if (!driver || driver->speed < USB_SPEED_FULL || !driver->bind ||
>> +!driver->setup) {
>> +printf("bad parameter.\n");
> 
> Sentence usually starts with capital letter and ends with fullstop (not
> the case below).
> 
>> +return -EINVAL;
>> +}
>> +
>> +if (!gadget) {
>> +printf("Controller uninitialized\n");
>> +return -ENXIO;
>> +}
>> +
>> +ret = musb_gadget_start(>g, driver);
>> +if (ret < 0) {
>> +printf("gadget_start failed with %d\n", ret);
>> +return ret;
>> +}
>> +
>> +ret = driver->bind(>g);
>> +if (ret < 0) {
>> +printf("bind failed with %d\n", ret);
> 
> Are all these prints really useful ?

This function is just a carry forward from non-DM driver, will have a
look to remove irrelevant logs.

Regards
Mugunthan V N

> 
>> +return ret;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +int usb_gadget_unregister_driver(struct usb_gadget_driver *driver)
>> +{
>> +if (driver->disconnect)
>> +driver->disconnect(>g);
>> +if (driver->unbind)
>> +driver->unbind(>g);
>> +return 0;
>> +}
>> +
>> +static int ti_musb_peripheral_usb_probe(struct udevice *dev)
>> +{
>> +struct ti_musb_platdata *platdata = dev_get_platdata(dev);
>> +struct usb_bus_priv *priv = dev_get_uclass_priv(dev);
>> +struct omap_musb_board_data *otg_board_data;
>> +
>> +otg_board_data = >otg_board_data;
>> +
>> +gadget = musb_init_controller(>plat,
>> +  (struct device *)otg_board_data,
>> +  platdata->base);
>> +if (!gadget) {
>> +error("gadget init failed\n");
>> +return -EIO;
>> +}
>> +
>> +return 0;
>> +}
>> +
>> +static int ti_musb_peripheral_remove(struct udevice *dev)
>> +{
>> +musb_stop(gadget);
>> +
>> +return 0;
>> +}
>> +
>> +static int ti_musb_peripheral_ofdata_to_platdata(struct udevice *dev)
>> +{
>> +struct ti_musb_platdata *platdata = dev_get_platdata(dev);
>> +const void *fdt = gd->fdt_blob;
>> +int node = dev->of_offset;
>> +int ret;
>> +
>> +ret = ti_musb_ofdata_to_platdata(dev);
>> +if (ret) {
>> +error("platdata dt parse error\n");
>> +return ret;
>> +}
>> +
>> +platdata->plat.mode = MUSB_PERIPHERAL;
>> +
>> +return 0;
>> +}
>> +
>> +U_BOOT_DRIVER(ti_musb_peripheral) = {
>> +.name   = "ti-musb-peripheral",
>> +.id = UCLASS_USB_DEV_GENERIC,
>> +.ofdata_to_platdata = ti_musb_peripheral_ofdata_to_platdata,
>> +.probe = ti_musb_peripheral_usb_probe,
>> +.remove = ti_musb_peripheral_remove,
>> +.platdata_auto_alloc_size = sizeof(struct ti_musb_platdata),
>> +.priv_auto_alloc_size = sizeof(struct musb),
>> +};
>> +
>>  static int ti_musb_host_probe(struct udevice *dev)
>>  {
>>  struct musb_host_data *host = dev_get_priv(dev);
>> @@ -222,7 +327,15 @@ static int ti_musb_wrapper_bind(struct udevice *parent)
>>  dr_mode = usb_get_dr_mode(node);
>>  switch (dr_mode) {
>>  

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

[Mugunthan V N]

On Tuesday 10 May 2016 05:57 PM, Marek Vasut wrote:
> On 05/10/2016 01:44 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/ether.c | 153 
>> ++---
>>  drivers/usb/gadget/rndis.c |  13 +++-
>>  drivers/usb/gadget/rndis.h |  19 --
>>  include/net.h  |   7 +++
>>  4 files changed, 177 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
>> index 2f70ebf..c436f75 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
>>  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
>>  struct eth_device netdev;
>> +#else
>> +struct udevice *netdev;
>> +#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
>>  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 */
>>  #ifndef CONFIG_USB_ETH_CDC
>> @@ -2188,7 +2204,11 @@ autoconf_fail:
>>  
>>  
>>  /* network device setup */
>> +#ifndef CONFIG_DM_ETH
>>  dev->net = _priv->netdev;
>> +#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);
>> +#else
>> +printf("MAC %pM\n", pdata->enetaddr);
>> +#endif
>>  
>>  if (cdc || rndis)
>>  printf("HOST MAC %02x:%02x:%02x:%02x:%02x:%02x\n",
>> @@ -2520,13 +2545,12 @@ void _usb_eth_halt(struct ether_priv *priv)
>>  }
>>  
>>  usb_gadget_unregister_driver(>eth_driver);
>> -#ifdef CONFIG_DM_USB
>> -device_remove(dev->usb_udev);
>> -#else
>> +#ifndef CONFIG_DM_USB
>>  board_usb_cleanup(0, USB_INIT_DEVICE);
>>  #endif
>>  }
>>  
>> +#ifndef CONFIG_DM_ETH
>>  static int usb_eth_init(struct eth_device *netdev, bd_t *bd)
>>  {
>>  struct ether_priv *priv = (struct ether_priv *)netdev->priv;
>> @@ -2592,3 +2616,114 @@ int usb_eth_initialize(bd_t *bi)
>>  eth_register(netdev);
>>  return 0;
>>  }
>> +#else
>> +static int usb_eth_start(struct udevice *dev)
>> +{
>> +struct ether_priv *priv = dev_get_priv(dev);
>> +
>> +return _usb_eth_init(priv);
>> +}
>> +
>> +static int usb_eth_send(struct udevice *dev, void *packet, int length)
>> +{
>> +struct ether_priv *priv = dev_get_priv(dev);

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

[Mugunthan V N]

On Tuesday 10 May 2016 05:54 PM, Marek Vasut wrote:
> On 05/10/2016 01:44 PM, Mugunthan V N wrote:
>> prepare driver for driver model migration
>>
>> Signed-off-by: Mugunthan V N 
>> ---
>>  drivers/usb/gadget/ether.c | 72 
>> --
>>  1 file changed, 51 insertions(+), 21 deletions(-)
>>
>> diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c
>> index 47071c3..2f70ebf 100644
>> --- a/drivers/usb/gadget/ether.c
>> +++ b/drivers/usb/gadget/ether.c
>> @@ -2334,9 +2334,8 @@ int dm_usb_init(struct eth_dev *e_dev)
>>  }
>>  #endif
>>  
>> -static int usb_eth_init(struct eth_device *netdev, bd_t *bd)
>> +static int _usb_eth_init(struct ether_priv *priv)
>>  {
>> -struct ether_priv *priv = (struct ether_priv *)netdev->priv;
>>  struct eth_dev *dev = >ethdev;
>>  struct usb_gadget *gadget;
>>  unsigned long ts;
>> @@ -2415,11 +2414,10 @@ fail:
>>  return -1;
>>  }
>>  
>> -static int usb_eth_send(struct eth_device *netdev, void *packet, int length)
>> +static int _usb_eth_send(struct ether_priv *priv, void *packet, int length)
>>  {
>>  int retval;
>>  void*rndis_pkt = NULL;
>> -struct ether_priv   *priv = (struct ether_priv *)netdev->priv;
>>  struct eth_dev  *dev = >ethdev;
>>  struct usb_request  *req = dev->tx_req;
>>  unsigned long ts;
>> @@ -2485,30 +2483,15 @@ drop:
>>  return -ENOMEM;
>>  }
>>  
>> -static int usb_eth_recv(struct eth_device *netdev)
>> +static int _usb_eth_recv(struct ether_priv *priv)
>>  {
>> -struct ether_priv *priv = (struct ether_priv *)netdev->priv;
>> -struct eth_dev *dev = >ethdev;
>> -
>>  usb_gadget_handle_interrupts(0);
>>  
>> -if (packet_received) {
>> -debug("%s: packet received\n", __func__);
>> -if (dev->rx_req) {
>> -net_process_received_packet(net_rx_packets[0],
>> -dev->rx_req->length);
>> -packet_received = 0;
>> -
>> -rx_submit(dev, dev->rx_req, 0);
>> -} else
>> -error("dev->rx_req invalid");
>> -}
>>  return 0;
>>  }
>>  
>> -void usb_eth_halt(struct eth_device *netdev)
>> +void _usb_eth_halt(struct ether_priv *priv)
>>  {
>> -struct ether_priv *priv = (struct ether_priv *)netdev->priv;
>>  struct eth_dev *dev = >ethdev;
>>  
>>  /* If the gadget not registered, simple return */
>> @@ -2544,6 +2527,53 @@ void usb_eth_halt(struct eth_device *netdev)
>>  #endif
>>  }
>>  
>> +static int usb_eth_init(struct eth_device *netdev, bd_t *bd)
>> +{
>> +struct ether_priv *priv = (struct ether_priv *)netdev->priv;
>> +
>> +return _usb_eth_init(priv);
>> +}
>> +
>> +static int usb_eth_send(struct eth_device *netdev, void *packet, int length)
>> +{
>> +struct ether_priv   *priv = (struct ether_priv *)netdev->priv;
>> +
>> +return _usb_eth_send(priv, packet, length);
>> +}
>> +
>> +static int usb_eth_recv(struct eth_device *netdev)
>> +{
>> +struct ether_priv *priv = (struct ether_priv *)netdev->priv;
>> +struct eth_dev *dev = >ethdev;
>> +int ret;
>> +
>> +ret = _usb_eth_recv(priv);
>> +if (ret) {
>> +error("error packet receive\n");
>> +return ret;
>> +}
>> +
>> +if (packet_received) {
> 
> if (!packet_received)
>  return 0;
> ... the rest ...

Will fix in next version.

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

Re: [U-Boot] U-boot UBI environment

[Heiko Schocher]

Hello Kevin,

Am 11.05.2016 um 17:54 schrieb Kevin Smith:

Hi Joe and Heiko,

I tried disabling the fastmap options, and it appears to be related to
these.  With fastmap off, I am able two write without corrupting the
other volume.  It looks like it may specifically be the autoupdate
feature, but I am still testing to be sure this is the case.  I will let
you know.


Thanks for debugging into it!


Thank you for your help,


You are welcome!

bye,
Heiko

Kevin

On 05/11/2016 12:51 AM, Heiko Schocher wrote:

Hello Joe,

Am 11.05.2016 um 01:15 schrieb Joseph Hershberger:

Hi Kevin,

Am 09.05.2016 um 23:16 schrieb Kevin Smith:

Hello,

I would appreciate some UBI help/advice if you are able to provide it.
I am trying to use UBI to store my u-boot environment, but when I try
to 'saveenv', it is corrupting another volume of my UBI.  I can image
the rootfs volume and boot Linux from it without a problem. However,
the first time that I save the u-boot environment, the rootfs becomes
unreadable.  When the rootfs is corrupted, I have booted Linux from
another source and tried to attach UBI and dd out the data. It
appears as all 0xFF.  Both u-boot and Linux can read the env volume
correctly.

I do not think that there is a board in U-boot that uses UBI env, so I
do not have anything to compare to.  I have included some details of
my setup below.  Do you have any suggestion about what might be wrong?
I saw the recent patch b1d6590d35, and thought it might fix it, but am
still having the problem even with this.  Maybe there is another bug?
I am glad to provide more info as needed.
Thank you,
Kevin

DTS:
flash@d {
num-cs = <1>;
marvell,nand-keep-config;
marvell,nand-enable-arbiter;
nand-on-flash-bbt;
nand-ecc-strength = <4>;
nand-ecc-step-size = <512>;
status = "okay";

partition@0 {
label = "mvboot";
reg = <0 0x20>;
};
partition@20 {
label = "ubi";
reg = <0x20 0x1fe0>;
};
};
Config:
#define MTDIDS_DEFAULT"nand0=pxa3xx_nand-0"
#define MTDPARTS_DEFAULT "mtdparts=pxa3xx_nand-0:2m(mvboot),-(ubi)"
#define CONFIG_CMD_UBI
#define CONFIG_CMD_UBIFS



#define CONFIG_MTD_UBI_FASTMAP
#define CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT1


I don’t define these 2, not sure if it matters.


This should be no problem ... but you (Kevin) may disable
FASTMAP for a test?


#define CONFIG_ENV_IS_IN_UBI
#define CONFIG_ENV_UBI_PART"ubi"
#define CONFIG_ENV_UBI_VOLUME"u-boot-env"
#define CONFIG_ENV_SIZE(64 * 1024)


My config looks like this:

#define MTDIDS_DEFAULT "nand0=xilinx_nand"
#define MTDPARTS_DEFAULT \
 "mtdparts=xilinx_nand:" \
 "128k(fsbl)ro," \
 "11M(u-boot)ro," \
 "70M(boot-config)," \
 "-(root)"


You have 70MB for Env?


#define CONFIG_ENV_IS_IN_UBI
#define CONFIG_ENV_UBI_PART "boot-config"
#define CONFIG_ENV_UBI_VOLUME "u-boot-env1"
#define CONFIG_ENV_UBI_VOLUME_REDUND "u-boot-env2"
#define CONFIG_ENV_SIZE0x2

I create volumes like this:

 "writepartitions=" \
 "if ubi part boot-config && " \
 "ubi read $verifyaddr u-boot-env1 1 && " \
 "ubi read $verifyaddr u-boot-env2 1; " \
 "then " \
 "ubi remove bootfs && " \
 "ubi remove config; " \
 "else " \
 "nand erase.part boot-config && " \
 "ubi part boot-config && " \
 "ubi create u-boot-env1 " __stringify(CONFIG_ENV_SIZE) "
dynamic && " \
 "ubi create u-boot-env2 " __stringify(CONFIG_ENV_SIZE) "
dynamic; " \
 "fi && " \
 "ubi create bootfs " __stringify(CONFIG_BOOTFS_VOLUME_SIZE) "
dynamic && " \
 "ubi create config - dynamic && " \
 "if ubi part root && " \
 "ubi read $verifyaddr rootfs 1; " \
 "then " \
 "ubi remove rootfs; " \
 "else " \
 "nand erase.part root && " \
 "ubi part root; " \
 "fi && " \
 "ubi create rootfs - dynamic;\0" \



=> ubi info
UBI: MTD device name:"mtd=1"
UBI: MTD device size:510 MiB
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:126976 bytes
UBI: number of good PEBs:4072
UBI: number of bad PEBs: 8
UBI: smallest flash I/O unit:2048
UBI: VID header offset:  2048 (aligned 2048)
UBI: data offset:4096
UBI: max. allowed volumes:   128
UBI: wear-leveling threshold:4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 2
UBI: available PEBs: 0
UBI: total number of reserved PEBs: 4072
UBI: number of PEBs reserved for bad PEB handling: 72
UBI: max/mean erase counter: 18/4

=> ubi info l
Volume information dump:
vol_id  0
reserved_pebs   1
alignment   1
data_pad0
vol_type3
 

Re: [U-Boot] [PATCH] usb: xhci: add struct devrequest declaration

[Masahiro Yamada]

Hi Marek,


2016-05-11 20:22 GMT+09:00 Marek Vasut :

>>> Because you want to have definition of every symbol you use in your
>>> headers when you include that header. I am not a big fan of huge stack
>>> of #include statements in a driver.
>>
>> Agree.  That's why this patch is here.
>>
>> See this patch.
>> http://patchwork.ozlabs.org/patch/620989/
>>
>>
>> xhci-dwc3.c needs to include xhci.h, but not usb.h
>> because this driver just wants to register the xHCI controller.
>> It need not know complicated USB protocol things in the first place.
>
> In that case, shouldn't the xhci_register() be in xhci.h instead ?

Ah, right.

That will make APIs clearer, but I cannot touch it
because I do not have either time or skill to refactor it.


>> Your way adds #include  to xhci.h,
>> so xhci-dwc3.c is compelled to include unnecessary usb.h
>>
>> It means huge stack of includes you do not like, isn't it?
>
> It does add possibly unused symbols to the namespace, yes.
> I don't think I really mind this though, since the symbol
> definition is available when I include xhci.h somewhere.

Right.

But, what I can tell at least is that
it would make the compiler to parse additional headers for nothing.



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

[U-Boot] [PATCH] i2c: mvtwsi: avoid writing to twsi_control_flags prior to relocation

[Chris Packham]

In a system where the initial u-boot location is genuinely NOR flash (as
opposed to RAM or a cache-line setup by a pre-bootloader) writes to the
data section are problematic. At best these writes have no effect at
worse they put the flash memory into a status mode which changes the
executable code underneath us.

Only write to twsi_control_flags once we know we've relocated to RAM.

Signed-off-by: Chris Packham 
---

 drivers/i2c/mvtwsi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index 221ff4f..aee28c4 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -28,6 +28,8 @@
 #error Driver mvtwsi not supported by SoC or board
 #endif
 
+DECLARE_GLOBAL_DATA_PTR;
+
 /*
  * TWSI register structure
  */
@@ -297,7 +299,8 @@ static void twsi_reset(struct i2c_adapter *adap)
 {
struct mvtwsi_registers *twsi = twsi_get_base(adap);
/* ensure controller will be enabled by any twsi*() function */
-   twsi_control_flags = MVTWSI_CONTROL_TWSIEN;
+   if (gd->flags & GD_FLG_RELOC)
+   twsi_control_flags = MVTWSI_CONTROL_TWSIEN;
/* reset controller */
writel(0, >soft_reset);
/* wait 2 ms -- this is what the Marvell LSP does */
-- 
2.8.2

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

[U-Boot] [PATCH 0/1] i2c: mvtwsi: running from flash ROM

[Chris Packham]

We have a board using Marvell's MV78100 SoC (note despite the name this
is quite different to the armada MV782x0/MV784x0 SoCs).

The SoC support isn't upstream but since it's quite similar to the
Orion/Kirkwood we've managed to keep reasonably up to date. One
difference with our system is that it boots directly from NOR flash (as
opposed to many Kirkwood implementations which make use of a
pre-bootloader to setup RAM).

Somewhere between v2015.04 and v2015.10 we started seeing a hang at
startup. I eventually tracked this down to the write to
twsi_control_flags which is putting the NOR flash into status mode
leading to the hang when the next instruction is executed.

I'm not sure how we haven't hit this before. In v2015.04 the same code
path is executed but somehow no hang occurs. This code hasn't changed
much between v2015.04 and v2015.10 and certainly not in any way that
would change this behaviour. Presumably _something_ else has changed in
a way that is affecting this behaviour but so far I haven't been able to
narrow this down to a particular change.


Chris Packham (1):
  i2c: mvtwsi: avoid writing to twsi_control_flags prior to relocation

 drivers/i2c/mvtwsi.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.8.2

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

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

[Tom Rini]

On Wed, May 11, 2016 at 09:20:20PM +0200, Marek Vasut wrote:

> On 05/11/2016 06:23 PM, Tom Rini wrote:
> > On Sat, May 07, 2016 at 03:42:15AM +0200, Marek Vasut wrote:
> > 
> >> The following changes since commit
> >> bbca7108db79076d3a9a9c112792d7c4608a665c:
> >>
> >>
> >>
> >>   ARM: tegra: import latest Jetson TK1 spreadsheet (2016-05-04 13:31:04
> >> -0700)
> >>
> >>
> >> are available in the git repository at:
> >>
> >>
> >>
> >>   git://git.denx.de/u-boot-socfpga.git master
> >>
> >>
> >>
> >> for you to fetch changes up to 5289c5fa5371dada10e9cbdcdbf3fb010905ea2d:
> >>
> >>   socfpga: fix broken build if CONFIG_ETH_DESIGNWARE disabled
> >> (2016-05-06 18:41:49 +0200)
> >>
> > 
> > As of a few days ago, applied to u-boot/master, thanks!
> > 
> Thanks!
> 
> There is one more fix, so please pull:
> 
> 
> The following changes since commit e8bd2a0bf6e334adaf7703c517989433e730091b:
> 
>   warp7: Fix boot by selecting CONFIG_OF_LIBFDT (2016-05-10 14:54:11 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> for you to fetch changes up to 4baca92001bff3c32a05001a7dc58996623e3ef8:
> 
>   arm: socfpga: Update iomux and pll for c5 socdk RevE (2016-05-10
> 23:32:42 +0200)
> 

Applied to u-boot/master, thanks!

-- 
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 8/9][v2] armv8: ls1012a: Add support of ls1012aqds board

[Alexander Graf]

On 11.05.16 17:59, York Sun wrote:
> On 05/11/2016 12:30 AM, Prabhakar Kushwaha wrote:
>> QorIQ LS1012A Development System (LS1012AQDS) is a high-performance
>> development platform, with a complete debugging environment.
>> The LS1012AQDS board supports the QorIQ LS1012A processor and is
>> optimized to support the high-bandwidth DDR3L memory and
>> a full complement of high-speed SerDes ports.
>>
>> Signed-off-by: Calvin Johnson 
>> Signed-off-by: Pratiyush Mohan Srivastava 
>> Signed-off-by: Abhimanyu Saini 
>> Signed-off-by: Prabhakar Kushwaha 
>> ---

[...]

>> +/* Initial environment variables */
>> +#define CONFIG_EXTRA_ENV_SETTINGS   \
>> +"initrd_high=0x\0"  \
>> +"verify=no\0"   \
>> +"hwconfig=fsl_ddr:bank_intlv=auto\0"\
>> +"loadaddr=0x8010\0" \
>> +"kernel_addr=0x10\0"\
>> +"ramdisk_addr=0x80\0"   \
>> +"ramdisk_size=0x200\0"  \
>> +"fdt_high=0x\0" \
>> +"initrd_high=0x\0"  \
>> +"kernel_start=0xa0\0"   \
>> +"kernel_load=0xa000\0"  \
>> +"kernel_size=0x280\0"   \
>> +"console=ttyAMA0,38400n8\0"
>> +
>> +#define CONFIG_BOOTARGS "console=ttyS0,115200 root=/dev/ram0 " \
>> +"earlycon=uart8250,mmio,0x21c0500"
>> +#define CONFIG_BOOTCOMMAND  "sf probe 0:0; sf read $kernel_load "\
>> +"$kernel_start $kernel_size && "\

Is SPI Flash the only boot method envisioned for these system? If not,
wouldn't it make sense to make use of the distro boot framework?


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

[U-Boot] [PATCH V2 1/2] dm: allow setting driver_data before/during bind

[Stephen Warren]

From: Stephen Warren 

This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.

Signed-off-by: Stephen Warren 
---
v2:
* Introduce a separate function for the new functionality, rather than
modifying device_bind().

This patch is a dependency for the upcoming Tegra186 GPIO driver too.
---
 doc/driver-model/README.txt  | 23 ++-
 drivers/core/device.c| 25 ++---
 drivers/core/lists.c |  4 ++--
 include/dm/device-internal.h | 24 
 4 files changed, 62 insertions(+), 14 deletions(-)

diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index 7a24552560d5..1b5ccec4b2e5 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -606,19 +606,24 @@ methods actually defined.
 
 1. Bind stage
 
-A device and its driver are bound using one of these two methods:
+U-Boot discovers devices using one of these two methods:
 
-   - Scan the U_BOOT_DEVICE() definitions. U-Boot It looks up the
-name specified by each, to find the appropriate driver. It then calls
-device_bind() to create a new device and bind' it to its driver. This will
-call the device's bind() method.
+   - Scan the U_BOOT_DEVICE() definitions. U-Boot looks up the name specified
+by each, to find the appropriate U_BOOT_DRIVER() definition. In this case,
+there is no path by which driver_data may be provided, but the U_BOOT_DEVICE()
+may provide platdata.
 
- Scan through the device tree definitions. U-Boot looks at top-level
 nodes in the the device tree. It looks at the compatible string in each node
-and uses the of_match part of the U_BOOT_DRIVER() structure to find the
-right driver for each node. It then calls device_bind() to bind the
-newly-created device to its driver (thereby creating a device structure).
-This will also call the device's bind() method.
+and uses the of_match table of the U_BOOT_DRIVER() structure to find the
+right driver for each node. In this case, the of_match table may provide a
+driver_data value, but platdata cannot be provided until later.
+
+For each device that is discovered, U-Boot then calls device_bind() to create a
+new device, initializes various core fields of the device object such as name,
+uclass & driver, initializes any optional fields of the device object that are
+applicable such as of_offset, driver_data & platdata, and finally calls the
+driver's bind() method if one is defined.
 
 At this point all the devices are known, and bound to their drivers. There
 is a 'struct udevice' allocated for all devices. However, nothing has been
diff --git a/drivers/core/device.c b/drivers/core/device.c
index 2b12ce7835f0..a8f2380e4676 100644
--- a/drivers/core/device.c
+++ b/drivers/core/device.c
@@ -26,9 +26,10 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-int device_bind(struct udevice *parent, const struct driver *drv,
-   const char *name, void *platdata, int of_offset,
-   struct udevice **devp)
+static int device_bind_common(struct udevice *parent, const struct driver *drv,
+ const char *name, void *platdata,
+ ulong driver_data, int of_offset,
+ struct udevice **devp)
 {
struct udevice *dev;
struct uclass *uc;
@@ -56,6 +57,7 @@ int device_bind(struct udevice *parent, const struct driver 
*drv,
INIT_LIST_HEAD(>devres_head);
 #endif
dev->platdata = platdata;
+   dev->driver_data = driver_data;
dev->name = name;
dev->of_offset = of_offset;
dev->parent = parent;
@@ -193,6 +195,23 @@ fail_alloc1:
return ret;
 }
 
+int device_bind_with_driver_data(struct udevice *parent,
+const struct driver *drv, const char *name,
+ulong driver_data, int of_offset,
+struct udevice **devp)
+{
+   return device_bind_common(parent, drv, name, NULL, driver_data,
+ of_offset, devp);
+}
+
+int device_bind(struct udevice *parent, const struct driver *drv,
+   const char *name, void *platdata, int of_offset,
+   struct udevice **devp)
+{
+   return device_bind_common(parent, drv, name, platdata, 0, of_offset,
+ devp);
+}
+
 int device_bind_by_name(struct udevice *parent, bool pre_reloc_only,
const struct driver_info *info, struct udevice **devp)
 {
diff --git a/drivers/core/lists.c b/drivers/core/lists.c
index a72db13a119a..0c2771779096 100644
--- a/drivers/core/lists.c
+++ b/drivers/core/lists.c
@@ -170,7 +170,8 @@ int lists_bind_fdt(struct udevice *parent, const void 
*blob, int 

[U-Boot] [PATCH V2 2/2] sunxi: gpio: convert bind() to use driver data

[Stephen Warren]

From: Stephen Warren 

Now that the DM core sets driver_data before calling bind(), this driver
can make use of driver_data to determine the set of child devices to
create, rather than manually re-implementing the matching logic in code.

Cc: Hans de Goede 
Signed-off-by: Stephen Warren 
---
v2: New patch.
---
 drivers/gpio/sunxi_gpio.c | 90 ++-
 1 file changed, 50 insertions(+), 40 deletions(-)

diff --git a/drivers/gpio/sunxi_gpio.c b/drivers/gpio/sunxi_gpio.c
index a7cec18d57fb..94abbeb39adc 100644
--- a/drivers/gpio/sunxi_gpio.c
+++ b/drivers/gpio/sunxi_gpio.c
@@ -258,43 +258,30 @@ static int gpio_sunxi_probe(struct udevice *dev)
 
return 0;
 }
+
+struct sunxi_gpio_soc_data {
+   int start;
+   int no_banks;
+};
+
 /**
  * We have a top-level GPIO device with no actual GPIOs. It has a child
  * device for each Sunxi bank.
  */
 static int gpio_sunxi_bind(struct udevice *parent)
 {
+   struct sunxi_gpio_soc_data *soc_data =
+   (struct sunxi_gpio_soc_data *)dev_get_driver_data(parent);
struct sunxi_gpio_platdata *plat = parent->platdata;
struct sunxi_gpio_reg *ctlr;
-   int bank, no_banks, ret, start;
+   int bank, ret;
 
/* If this is a child device, there is nothing to do here */
if (plat)
return 0;
 
-   if (fdt_node_check_compatible(gd->fdt_blob, parent->of_offset,
-   "allwinner,sun6i-a31-r-pinctrl") == 0) {
-   start = 'L' - 'A';
-   no_banks = 2; /* L & M */
-   } else if (fdt_node_check_compatible(gd->fdt_blob, parent->of_offset,
-   "allwinner,sun8i-a23-r-pinctrl") == 0 ||
-  fdt_node_check_compatible(gd->fdt_blob, parent->of_offset,
-   "allwinner,sun8i-a83t-r-pinctrl") == 0 ||
-  fdt_node_check_compatible(gd->fdt_blob, parent->of_offset,
-   "allwinner,sun8i-h3-r-pinctrl") == 0) {
-   start = 'L' - 'A';
-   no_banks = 1; /* L only */
-   } else if (fdt_node_check_compatible(gd->fdt_blob, parent->of_offset,
-   "allwinner,sun9i-a80-r-pinctrl") == 0) {
-   start = 'L' - 'A';
-   no_banks = 3; /* L, M & N */
-   } else {
-   start = 0;
-   no_banks = SUNXI_GPIO_BANKS;
-   }
-
ctlr = (struct sunxi_gpio_reg *)dev_get_addr(parent);
-   for (bank = 0; bank < no_banks; bank++) {
+   for (bank = 0; bank < soc_data->no_banks; bank++) {
struct sunxi_gpio_platdata *plat;
struct udevice *dev;
 
@@ -302,7 +289,7 @@ static int gpio_sunxi_bind(struct udevice *parent)
if (!plat)
return -ENOMEM;
plat->regs = >gpio_bank[bank];
-   plat->bank_name = gpio_bank_name(start + bank);
+   plat->bank_name = gpio_bank_name(soc_data->start + bank);
plat->gpio_count = SUNXI_GPIOS_PER_BANK;
 
ret = device_bind(parent, parent->driver,
@@ -315,23 +302,46 @@ static int gpio_sunxi_bind(struct udevice *parent)
return 0;
 }
 
+static const struct sunxi_gpio_soc_data soc_data_a_all = {
+   .start = 0,
+   .no_banks = SUNXI_GPIO_BANKS,
+};
+
+static const struct sunxi_gpio_soc_data soc_data_l_1 = {
+   .start = 'L' - 'A',
+   .no_banks = 1,
+};
+
+static const struct sunxi_gpio_soc_data soc_data_l_2 = {
+   .start = 'L' - 'A',
+   .no_banks = 2,
+};
+
+static const struct sunxi_gpio_soc_data soc_data_l_3 = {
+   .start = 'L' - 'A',
+   .no_banks = 3,
+};
+
+#define ID(_compat_, _soc_data_) \
+   { .compatible = _compat_, .data = (ulong)_data_##_soc_data_ }
+
 static const struct udevice_id sunxi_gpio_ids[] = {
-   { .compatible = "allwinner,sun4i-a10-pinctrl" },
-   { .compatible = "allwinner,sun5i-a10s-pinctrl" },
-   { .compatible = "allwinner,sun5i-a13-pinctrl" },
-   { .compatible = "allwinner,sun6i-a31-pinctrl" },
-   { .compatible = "allwinner,sun6i-a31s-pinctrl" },
-   { .compatible = "allwinner,sun7i-a20-pinctrl" },
-   { .compatible = "allwinner,sun8i-a23-pinctrl" },
-   { .compatible = "allwinner,sun8i-a33-pinctrl" },
-   { .compatible = "allwinner,sun8i-a83t-pinctrl", },
-   { .compatible = "allwinner,sun8i-h3-pinctrl" },
-   { .compatible = "allwinner,sun9i-a80-pinctrl" },
-   { .compatible = "allwinner,sun6i-a31-r-pinctrl" },
-   { .compatible = "allwinner,sun8i-a23-r-pinctrl" },
-   { .compatible = "allwinner,sun8i-a83t-r-pinctrl" },
-   { .compatible = "allwinner,sun8i-h3-r-pinctrl", },
-   { .compatible = "allwinner,sun9i-a80-r-pinctrl", },
+   ID("allwinner,sun4i-a10-pinctrl",   a_all),
+   ID("allwinner,sun5i-a10s-pinctrl",  a_all),
+   

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

[Marek Vasut]

On 05/11/2016 06:23 PM, Tom Rini wrote:
> On Sat, May 07, 2016 at 03:42:15AM +0200, Marek Vasut wrote:
> 
>> The following changes since commit
>> bbca7108db79076d3a9a9c112792d7c4608a665c:
>>
>>
>>
>>   ARM: tegra: import latest Jetson TK1 spreadsheet (2016-05-04 13:31:04
>> -0700)
>>
>>
>> are available in the git repository at:
>>
>>
>>
>>   git://git.denx.de/u-boot-socfpga.git master
>>
>>
>>
>> for you to fetch changes up to 5289c5fa5371dada10e9cbdcdbf3fb010905ea2d:
>>
>>   socfpga: fix broken build if CONFIG_ETH_DESIGNWARE disabled
>> (2016-05-06 18:41:49 +0200)
>>
> 
> As of a few days ago, applied to u-boot/master, thanks!
> 
Thanks!

There is one more fix, so please pull:


The following changes since commit e8bd2a0bf6e334adaf7703c517989433e730091b:

  warp7: Fix boot by selecting CONFIG_OF_LIBFDT (2016-05-10 14:54:11 -0400)

are available in the git repository at:

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

for you to fetch changes up to 4baca92001bff3c32a05001a7dc58996623e3ef8:

  arm: socfpga: Update iomux and pll for c5 socdk RevE (2016-05-10
23:32:42 +0200)


Dinh Nguyen (1):
  arm: socfpga: Update iomux and pll for c5 socdk RevE

 board/altera/cyclone5-socdk/qts/pinmux_config.h | 38
+++---
 board/altera/cyclone5-socdk/qts/pll_config.h| 34
+-
 2 files changed, 36 insertions(+), 36 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] reset uclass rename?

[Simon Glass]

Hi Stephen,

On 11 May 2016 at 12:45, Stephen Warren  wrote:
> Simon,
>
> For Tegra186 support, I'd like to introduce a reset subsystem into U-Boot,
> to support the reset DT bindings[1]. It'd be equivalent to the existing
> reset subsystem in Linux. This binding/subsystem does/would control reset of
> e.g. individual HW blocks in an SoC, or individual chips on the board.
>
> It looks like there's already a "reset" uclass (include/reset.h,
> drivers/misc/reset*.c). However, that seems to address a slightly different
> case; CPU- or system-level reset rather than individual blocks.
>
> I'd like to propose renaming the existing uclass to sysreset (system reset)
> to allow the new per-block/-module reset uclass/subsystem just "reset". Does
> that make sense to you, or should I name the new uclass/subsystem e.g.
> "module_reset"?
>
> An alternative might be to extend the existing U-Boot reset subsystem to
> cover the new use-case too. However, U-Boot's existing concepts of warm vs.
> cold vs. power reset, and reset_walk_halt() don't exist in the reset DT
> bindings, so my instinct is that combining the two doesn't make sense
> semantically; I believe the sysreset API is a higher level concept that may
> use the raw capabilities of the new reset API in some HW-specific
> implementations.

Yes that is fine with me. I've been thinking the same thing.
'sysreset' seems like a reasonable name.

>
> [1]
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reset
> (in particular, reset.txt)

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

Re: [U-Boot] [PATCH] dm: allow setting driver_data before/during bind

[Simon Glass]

Hi Stephen,

On 11 May 2016 at 10:52, Stephen Warren  wrote:
> On 05/10/2016 08:25 PM, Simon Glass wrote:
>>
>> Hi Stephen,
>>
>> On 4 May 2016 at 12:42, Stephen Warren  wrote:
>>>
>>> On 05/01/2016 01:27 PM, Simon Glass wrote:


 Hi Stephen,

 On 28 April 2016 at 17:08, Stephen Warren  wrote:
>
>
> From: Stephen Warren 
>
> This will allow a driver's bind function to use the driver data. One
> example is the Tegra186 GPIO driver, which instantiates child devices
> for each of its GPIO ports, yet supports two different HW instances
> each
> with a different set of ports, and identified by the udevice_id .data
> field.
>
> Signed-off-by: Stephen Warren 
> ---
>drivers/core/device.c| 7 ---
>drivers/core/lists.c | 6 +++---
>drivers/gpio/dwapb_gpio.c| 2 +-
>drivers/gpio/s5p_gpio.c  | 2 +-
>drivers/gpio/sunxi_gpio.c| 2 +-
>drivers/gpio/tegra_gpio.c| 2 +-
>drivers/mtd/spi/sandbox.c| 2 +-
>drivers/net/mvpp2.c  | 3 ++-
>drivers/pci/pci-uclass.c | 5 ++---
>drivers/power/pmic/pmic-uclass.c | 2 +-
>drivers/usb/host/usb-uclass.c| 5 ++---
>include/dm/device-internal.h | 5 +++--
>12 files changed, 22 insertions(+), 21 deletions(-)



 I'm not sure this extra parameter carries its weight:

 - most callers just pass 0
>>>
>>>
>>> The same is true of the existing platdata field in many cases.
>>
>>
>> Yes, but platdata is defined to be needed by bind(), whereas
>> driver_data is supposed to be used in probe()  to find out which
>> device tree compatible string matched.
>
>
> This seems to conflict with the documentation in include/dm/device.h; it
> claims that platdata is created by calling ofdata_to_platdata() just before
> calling probe(), at least for the DT case (for the case where U_BOOT_DEVICE
> is used, the platdata is available right from the start).

Exactly. That isn't a conflict. It's just that with DT the platform
data is provided by ofdata_to_platdata() whereas without it (the
degenerate case) it must be provided before bind().

>
> I couldn't find anywhere in the documentation that states when driver_data
> is supposed to be used; could you point me at it so I can read it?

No, but we should add something. See device.h:

 * @of_offset: Device tree node offset for this device (- for none)
 * @driver_data: Driver data word for the entry that matched this device with
 * its driver

It is related to DT, nothing else.

>
>> Remember that the device tree
>>
>> properties are not looked at during bind(), only later. So it makes
>> sense to include platdata in the device_bind() call, but not
>> driver_data.
>
>
> Hmm, drivers/gpio/tegra_gpio.c:gpio_tegra_bind() uses DT (which you wrote or
> at least converted it to DM and chose where to put the DT accesses), and you
> very recently reviewed and applied "video: tegra: refuse to bind to disabled
> dcs" which modified drivers/video/tegra.c:tegra_lcd_bind() to use DT.

Re GPIO, this is because on tegra this information is not present in
the DT - it uses the 'interrupts' property to figure out the number of
GPIO banks. It does not involve using driverdata.

The video thing is checking for a disabled device, something that is
already done in dm_scan_fdt_node().

>
> Admittedly I do now see the following in doc/driver-model/README.txt:
>
>> The device's bind() method is permitted to perform simple actions, but
>> should not scan the device tree node, not initialise hardware, nor set up
>> structures or allocate memory. All of these tasks should be left for
>> the probe() method.
>
>
> ... but then I wonder why that rule was enforced for the patch in this
> thread, but not in the other cases?
>
> This inconsistency in review is extremely frustrating to me.

See above. There are always grey areas, but the two you cite don't
involve core DM changes.

>
 - the field is supposed to be set up by device tree and probing tables,
 not code
>>>
>>>
>>> While the existence of this new parameter does allow arbitrary code to
>>> set
>>> the parameter, this patch only actually sets the parameter in the case
>>> where
>>> DT and probing tables have determined that value.
>>
>>
>> I don't think so. That value is set in lists_bind_fdt().
>
>
> Sure, but that function is only used from 3 places, and explicitly accepts a
> parameter to indicate which DT node to instantiate a device for. It won't
> work unless a valid DT node is passed to it, and therefore can only work for
> DT-based probing.
>
>> I wonder if you could set it yourself after calling device_bind()?
>
>
> The Tegra186 GPIO driver explicitly needs to use the data inside the
> driver's bind() function in order to know how 

[U-Boot] reset uclass rename?

[Stephen Warren]

Simon,

For Tegra186 support, I'd like to introduce a reset subsystem into 
U-Boot, to support the reset DT bindings[1]. It'd be equivalent to the 
existing reset subsystem in Linux. This binding/subsystem does/would 
control reset of e.g. individual HW blocks in an SoC, or individual 
chips on the board.


It looks like there's already a "reset" uclass (include/reset.h, 
drivers/misc/reset*.c). However, that seems to address a slightly 
different case; CPU- or system-level reset rather than individual blocks.


I'd like to propose renaming the existing uclass to sysreset (system 
reset) to allow the new per-block/-module reset uclass/subsystem just 
"reset". Does that make sense to you, or should I name the new 
uclass/subsystem e.g. "module_reset"?


An alternative might be to extend the existing U-Boot reset subsystem to 
cover the new use-case too. However, U-Boot's existing concepts of warm 
vs. cold vs. power reset, and reset_walk_halt() don't exist in the reset 
DT bindings, so my instinct is that combining the two doesn't make sense 
semantically; I believe the sysreset API is a higher level concept that 
may use the raw capabilities of the new reset API in some HW-specific 
implementations.


[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/reset 
(in particular, reset.txt)

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

Re: [U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[Alexander Graf]

> Am 11.05.2016 um 19:09 schrieb York Sun :
> 
>> On 05/11/2016 10:04 AM, Alexander Graf wrote:
>> 
>> 
 Am 11.05.2016 um 18:33 schrieb York Sun :
 
 On 05/11/2016 09:25 AM, Alexander Graf wrote:
 While testing our shiny new EFI support, I stumbled across systems that
 have disk I/O hardware that can only access the lower 32bits of our
 physical address space.
 
 This is not a problem when running with the normal U-Boot flow, since we
 define all "pointers" that get in use in our environment, so we can just
 put them inside the lower 32bits.
 
 But when a higher level application such as an EFI payload comes across,
 it doesn't know about these constraints. So we need to allocate bounce
 buffers for the payload and use them instead.
>>> 
>>> Alexander,
>>> 
>>> The low 32-bit physical memory is required for this to work, isn't it? 
>>> There was
>>> a discussion to move to high memory for LS2080 so the memory can be 
>>> continuous
>>> for OS.
>> 
>> So how would that work in the non-efi case? Do you configure the smmu 
>> statically to give you an offset between device memory view and physical?
> 
> Alex,
> 
> We are still waiting for more thorough testing on all drivers. This was an
> effort to provide continuous memory for OS. As you know, only 2GB memory is
> available under 32-bit space. All other memory shows up at above 39-bit space.
> Limited tests proved Linux can boot with the high memory. However, some 
> drivers
> may not be happy with the missing 32-bit memory space. The final call is not
> made yet.

Yes, I remember the discussion and I think it's a great idea. In Linux we 
shouldn't have any issue at all, since we have full SMMU support there, so a 
device can always just see everything inside its 32bit addressable space.

But in U-Boot things are not quite as clear to me. I don't think we configure 
any smmu mapping today, do we? So in that scenario, what's the plan to get it 
working? The simplest thing I could come up with were simple prepopulated iommu 
tables that just give us an offset, preferably one that allows us to just cut 
off the upper 32bits for addresses.


Alex


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

Re: [U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[York Sun]

On 05/11/2016 10:04 AM, Alexander Graf wrote:
> 
> 
>> Am 11.05.2016 um 18:33 schrieb York Sun :
>>
>>> On 05/11/2016 09:25 AM, Alexander Graf wrote:
>>> While testing our shiny new EFI support, I stumbled across systems that
>>> have disk I/O hardware that can only access the lower 32bits of our
>>> physical address space.
>>>
>>> This is not a problem when running with the normal U-Boot flow, since we
>>> define all "pointers" that get in use in our environment, so we can just
>>> put them inside the lower 32bits.
>>>
>>> But when a higher level application such as an EFI payload comes across,
>>> it doesn't know about these constraints. So we need to allocate bounce
>>> buffers for the payload and use them instead.
>>
>> Alexander,
>>
>> The low 32-bit physical memory is required for this to work, isn't it? There 
>> was
>> a discussion to move to high memory for LS2080 so the memory can be 
>> continuous
>> for OS.
> 
> So how would that work in the non-efi case? Do you configure the smmu 
> statically to give you an offset between device memory view and physical?

Alex,

We are still waiting for more thorough testing on all drivers. This was an
effort to provide continuous memory for OS. As you know, only 2GB memory is
available under 32-bit space. All other memory shows up at above 39-bit space.
Limited tests proved Linux can boot with the high memory. However, some drivers
may not be happy with the missing 32-bit memory space. The final call is not
made yet.

York

> 
> In that case we can probably extend the patch to make the config variable a 
> max addr instead of bool. Then the bounce buffer would be inside the shifted 
> 32bit window.
> 
> 
> Alex
> 
>>
>> York
>>
>>>
>>> Alexander Graf (2):
>>>  efi_loader: Add bounce buffer support
>>>  efi_loader: Select bounce buffers for known-bad boards
>>>
>>> configs/ls2080a_emu_defconfig|  1 +
>>> configs/ls2080a_simu_defconfig   |  1 +
>>> configs/ls2080aqds_SECURE_BOOT_defconfig |  1 +
>>> configs/ls2080aqds_defconfig |  1 +
>>> configs/ls2080aqds_nand_defconfig|  1 +
>>> configs/ls2080ardb_SECURE_BOOT_defconfig |  1 +
>>> configs/ls2080ardb_defconfig |  1 +
>>> configs/ls2080ardb_nand_defconfig|  1 +
>>> configs/xilinx_zynqmp_ep_defconfig   |  1 +
>>> configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  1 +
>>> configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  1 +
>>> configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  1 +
>>> configs/xilinx_zynqmp_zcu102_defconfig   |  1 +
>>> configs/xilinx_zynqmp_zcu102_revB_defconfig  |  1 +
>>> include/efi_loader.h |  5 ++
>>> lib/efi_loader/Kconfig   |  9 +++
>>> lib/efi_loader/efi_disk.c| 70 
>>> +---
>>> lib/efi_loader/efi_memory.c  | 16 ++
>>> 18 files changed, 105 insertions(+), 9 deletions(-)
>>
> 
> 

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

Re: [U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[Alexander Graf]

> Am 11.05.2016 um 18:33 schrieb York Sun :
> 
>> On 05/11/2016 09:25 AM, Alexander Graf wrote:
>> While testing our shiny new EFI support, I stumbled across systems that
>> have disk I/O hardware that can only access the lower 32bits of our
>> physical address space.
>> 
>> This is not a problem when running with the normal U-Boot flow, since we
>> define all "pointers" that get in use in our environment, so we can just
>> put them inside the lower 32bits.
>> 
>> But when a higher level application such as an EFI payload comes across,
>> it doesn't know about these constraints. So we need to allocate bounce
>> buffers for the payload and use them instead.
> 
> Alexander,
> 
> The low 32-bit physical memory is required for this to work, isn't it? There 
> was
> a discussion to move to high memory for LS2080 so the memory can be continuous
> for OS.

So how would that work in the non-efi case? Do you configure the smmu 
statically to give you an offset between device memory view and physical?

In that case we can probably extend the patch to make the config variable a max 
addr instead of bool. Then the bounce buffer would be inside the shifted 32bit 
window.


Alex

> 
> York
> 
>> 
>> Alexander Graf (2):
>>  efi_loader: Add bounce buffer support
>>  efi_loader: Select bounce buffers for known-bad boards
>> 
>> configs/ls2080a_emu_defconfig|  1 +
>> configs/ls2080a_simu_defconfig   |  1 +
>> configs/ls2080aqds_SECURE_BOOT_defconfig |  1 +
>> configs/ls2080aqds_defconfig |  1 +
>> configs/ls2080aqds_nand_defconfig|  1 +
>> configs/ls2080ardb_SECURE_BOOT_defconfig |  1 +
>> configs/ls2080ardb_defconfig |  1 +
>> configs/ls2080ardb_nand_defconfig|  1 +
>> configs/xilinx_zynqmp_ep_defconfig   |  1 +
>> configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  1 +
>> configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  1 +
>> configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  1 +
>> configs/xilinx_zynqmp_zcu102_defconfig   |  1 +
>> configs/xilinx_zynqmp_zcu102_revB_defconfig  |  1 +
>> include/efi_loader.h |  5 ++
>> lib/efi_loader/Kconfig   |  9 +++
>> lib/efi_loader/efi_disk.c| 70 
>> +---
>> lib/efi_loader/efi_memory.c  | 16 ++
>> 18 files changed, 105 insertions(+), 9 deletions(-)
> 

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

Re: [U-Boot] [PATCH] dm: allow setting driver_data before/during bind

[Stephen Warren]

On 05/10/2016 08:25 PM, Simon Glass wrote:

Hi Stephen,

On 4 May 2016 at 12:42, Stephen Warren  wrote:

On 05/01/2016 01:27 PM, Simon Glass wrote:


Hi Stephen,

On 28 April 2016 at 17:08, Stephen Warren  wrote:


From: Stephen Warren 

This will allow a driver's bind function to use the driver data. One
example is the Tegra186 GPIO driver, which instantiates child devices
for each of its GPIO ports, yet supports two different HW instances each
with a different set of ports, and identified by the udevice_id .data
field.

Signed-off-by: Stephen Warren 
---
   drivers/core/device.c| 7 ---
   drivers/core/lists.c | 6 +++---
   drivers/gpio/dwapb_gpio.c| 2 +-
   drivers/gpio/s5p_gpio.c  | 2 +-
   drivers/gpio/sunxi_gpio.c| 2 +-
   drivers/gpio/tegra_gpio.c| 2 +-
   drivers/mtd/spi/sandbox.c| 2 +-
   drivers/net/mvpp2.c  | 3 ++-
   drivers/pci/pci-uclass.c | 5 ++---
   drivers/power/pmic/pmic-uclass.c | 2 +-
   drivers/usb/host/usb-uclass.c| 5 ++---
   include/dm/device-internal.h | 5 +++--
   12 files changed, 22 insertions(+), 21 deletions(-)



I'm not sure this extra parameter carries its weight:

- most callers just pass 0


The same is true of the existing platdata field in many cases.


Yes, but platdata is defined to be needed by bind(), whereas
driver_data is supposed to be used in probe()  to find out which
device tree compatible string matched.


This seems to conflict with the documentation in include/dm/device.h; it 
claims that platdata is created by calling ofdata_to_platdata() just 
before calling probe(), at least for the DT case (for the case where 
U_BOOT_DEVICE is used, the platdata is available right from the start).


I couldn't find anywhere in the documentation that states when 
driver_data is supposed to be used; could you point me at it so I can 
read it?


> Remember that the device tree

properties are not looked at during bind(), only later. So it makes
sense to include platdata in the device_bind() call, but not
driver_data.


Hmm, drivers/gpio/tegra_gpio.c:gpio_tegra_bind() uses DT (which you 
wrote or at least converted it to DM and chose where to put the DT 
accesses), and you very recently reviewed and applied "video: tegra: 
refuse to bind to disabled dcs" which modified 
drivers/video/tegra.c:tegra_lcd_bind() to use DT.


Admittedly I do now see the following in doc/driver-model/README.txt:


The device's bind() method is permitted to perform simple actions, but
should not scan the device tree node, not initialise hardware, nor set up
structures or allocate memory. All of these tasks should be left for
the probe() method.


... but then I wonder why that rule was enforced for the patch in this 
thread, but not in the other cases?


This inconsistency in review is extremely frustrating to me.


- the field is supposed to be set up by device tree and probing tables,
not code


While the existence of this new parameter does allow arbitrary code to set
the parameter, this patch only actually sets the parameter in the case where
DT and probing tables have determined that value.


I don't think so. That value is set in lists_bind_fdt().


Sure, but that function is only used from 3 places, and explicitly 
accepts a parameter to indicate which DT node to instantiate a device 
for. It won't work unless a valid DT node is passed to it, and therefore 
can only work for DT-based probing.



I wonder if you could set it yourself after calling device_bind()?


The Tegra186 GPIO driver explicitly needs to use the data inside the 
driver's bind() function in order to know how many child devices to 
instantiate. Setting the value after calling device_bind() (which the 
core DM code already does) is too late.


For reference, you can see the exact code at:
http://lists.denx.de/pipermail/u-boot/2016-April/252238.html
"gpio: add Tegra186 GPIO driver"

Search for "tegra186_gpio_bind" and look at the assignment to, and use 
of, ctlr_data.


I had also quoted that part of the code in my previous email.


- bind() methods should not care about the driver data (they are not
allowed to touch hardware), so setting it later is fine


Not touching HW is fine, but the driver data can still feed into purely SW
decisions that bind makes. More details below.


- you can already pass platform data to the driver which is the
preferred communication method from a parent to its children


I don't believe this is possible for devices instantiated from DT is it? In
that case, platform data is always NULL:


That's right. For DT the paltform data is set up in the
ofdata_to_platdata() method. Since you are using DT, you should follow
that convention.


This is the opposite of what you said above, which was that platdata is 
for bind().



int lists_bind_fdt(struct udevice *parent, const void *blob, int offset,

Re: [U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[York Sun]

On 05/11/2016 09:25 AM, Alexander Graf wrote:
> While testing our shiny new EFI support, I stumbled across systems that
> have disk I/O hardware that can only access the lower 32bits of our
> physical address space.
> 
> This is not a problem when running with the normal U-Boot flow, since we
> define all "pointers" that get in use in our environment, so we can just
> put them inside the lower 32bits.
> 
> But when a higher level application such as an EFI payload comes across,
> it doesn't know about these constraints. So we need to allocate bounce
> buffers for the payload and use them instead.

Alexander,

The low 32-bit physical memory is required for this to work, isn't it? There was
a discussion to move to high memory for LS2080 so the memory can be continuous
for OS.

York

> 
> Alexander Graf (2):
>   efi_loader: Add bounce buffer support
>   efi_loader: Select bounce buffers for known-bad boards
> 
>  configs/ls2080a_emu_defconfig|  1 +
>  configs/ls2080a_simu_defconfig   |  1 +
>  configs/ls2080aqds_SECURE_BOOT_defconfig |  1 +
>  configs/ls2080aqds_defconfig |  1 +
>  configs/ls2080aqds_nand_defconfig|  1 +
>  configs/ls2080ardb_SECURE_BOOT_defconfig |  1 +
>  configs/ls2080ardb_defconfig |  1 +
>  configs/ls2080ardb_nand_defconfig|  1 +
>  configs/xilinx_zynqmp_ep_defconfig   |  1 +
>  configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  1 +
>  configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  1 +
>  configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  1 +
>  configs/xilinx_zynqmp_zcu102_defconfig   |  1 +
>  configs/xilinx_zynqmp_zcu102_revB_defconfig  |  1 +
>  include/efi_loader.h |  5 ++
>  lib/efi_loader/Kconfig   |  9 +++
>  lib/efi_loader/efi_disk.c| 70 
> +---
>  lib/efi_loader/efi_memory.c  | 16 ++
>  18 files changed, 105 insertions(+), 9 deletions(-)
> 

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

[U-Boot] [PATCH 2/2] efi_loader: Select bounce buffers for known-bad boards

[Alexander Graf]

We know for certain that we have 32bit DMA hardware, but 64bit addresses
on LS2085A and ZynqMP, so let's enable EFI bounce buffers for all defconfigs
on these SoCs.

Signed-off-by: Alexander Graf 
---
 configs/ls2080a_emu_defconfig| 1 +
 configs/ls2080a_simu_defconfig   | 1 +
 configs/ls2080aqds_SECURE_BOOT_defconfig | 1 +
 configs/ls2080aqds_defconfig | 1 +
 configs/ls2080aqds_nand_defconfig| 1 +
 configs/ls2080ardb_SECURE_BOOT_defconfig | 1 +
 configs/ls2080ardb_defconfig | 1 +
 configs/ls2080ardb_nand_defconfig| 1 +
 configs/xilinx_zynqmp_ep_defconfig   | 1 +
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig | 1 +
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig | 1 +
 configs/xilinx_zynqmp_zcu102_defconfig   | 1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig  | 1 +
 14 files changed, 14 insertions(+)

diff --git a/configs/ls2080a_emu_defconfig b/configs/ls2080a_emu_defconfig
index 30a6381..56922dc 100644
--- a/configs/ls2080a_emu_defconfig
+++ b/configs/ls2080a_emu_defconfig
@@ -26,3 +26,4 @@ CONFIG_CMD_CACHE=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
 CONFIG_BOOTP_VCI_STRING="U-Boot.LS2080A-EMU"
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080a_simu_defconfig b/configs/ls2080a_simu_defconfig
index a095b8a..f27fbb7 100644
--- a/configs/ls2080a_simu_defconfig
+++ b/configs/ls2080a_simu_defconfig
@@ -29,3 +29,4 @@ CONFIG_NET_RANDOM_ETHADDR=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
 CONFIG_BOOTP_VCI_STRING="U-Boot.LS2080A-SIMU"
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080aqds_SECURE_BOOT_defconfig 
b/configs/ls2080aqds_SECURE_BOOT_defconfig
index 216559c..04a84ab 100644
--- a/configs/ls2080aqds_SECURE_BOOT_defconfig
+++ b/configs/ls2080aqds_SECURE_BOOT_defconfig
@@ -30,3 +30,4 @@ CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_DSPI=y
 CONFIG_RSA=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080aqds_defconfig b/configs/ls2080aqds_defconfig
index 854630a..3b6504b 100644
--- a/configs/ls2080aqds_defconfig
+++ b/configs/ls2080aqds_defconfig
@@ -29,3 +29,4 @@ CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_DSPI=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080aqds_nand_defconfig 
b/configs/ls2080aqds_nand_defconfig
index 4f385a1..1302313 100644
--- a/configs/ls2080aqds_nand_defconfig
+++ b/configs/ls2080aqds_nand_defconfig
@@ -23,3 +23,4 @@ CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080ardb_SECURE_BOOT_defconfig 
b/configs/ls2080ardb_SECURE_BOOT_defconfig
index 41d30a6..f974d88 100644
--- a/configs/ls2080ardb_SECURE_BOOT_defconfig
+++ b/configs/ls2080ardb_SECURE_BOOT_defconfig
@@ -30,3 +30,4 @@ CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_DSPI=y
 CONFIG_RSA=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080ardb_defconfig b/configs/ls2080ardb_defconfig
index 2b775cd..0168dbb 100644
--- a/configs/ls2080ardb_defconfig
+++ b/configs/ls2080ardb_defconfig
@@ -29,3 +29,4 @@ CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_FSL_DSPI=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/ls2080ardb_nand_defconfig 
b/configs/ls2080ardb_nand_defconfig
index 0f184c0..718a651 100644
--- a/configs/ls2080ardb_nand_defconfig
+++ b/configs/ls2080ardb_nand_defconfig
@@ -23,3 +23,4 @@ CONFIG_NETDEVICES=y
 CONFIG_E1000=y
 CONFIG_SYS_NS16550=y
 CONFIG_OF_LIBFDT=y
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_ep_defconfig 
b/configs/xilinx_zynqmp_ep_defconfig
index b185593..2ca6fe5 100644
--- a/configs/xilinx_zynqmp_ep_defconfig
+++ b/configs/xilinx_zynqmp_ep_defconfig
@@ -55,3 +55,4 @@ CONFIG_G_DNL_MANUFACTURER="Xilinx"
 CONFIG_G_DNL_VENDOR_NUM=0x03fd
 CONFIG_G_DNL_PRODUCT_NUM=0x0300
 # CONFIG_REGEX is not set
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
index cc08b03..b86edfd 100644
--- a/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig
@@ -50,3 +50,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Xilinx"
 CONFIG_G_DNL_VENDOR_NUM=0x03FD
 CONFIG_G_DNL_PRODUCT_NUM=0x0300
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig 
b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
index 14d24a0..4b8ac1c 100644
--- a/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
+++ b/configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig
@@ -47,3 +47,4 @@ CONFIG_USB_GADGET_DOWNLOAD=y
 CONFIG_G_DNL_MANUFACTURER="Xilinx"
 CONFIG_G_DNL_VENDOR_NUM=0x03FD
 CONFIG_G_DNL_PRODUCT_NUM=0x0300
+CONFIG_EFI_LOADER_BOUNCE_BUFFER=y
diff --git a/configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig 

[U-Boot] [PATCH 1/2] efi_loader: Add bounce buffer support

[Alexander Graf]

Some hardware that is supported by U-Boot can not handle DMA above 32bits.
For these systems, we need to come up with a way to expose the disk interface
in a safe way.

This patch implements EFI specific bounce buffers. For non-EFI cases, this
apparently was no issue so far, since we can just define our environment
variables conveniently.

Signed-off-by: Alexander Graf 
---
 include/efi_loader.h|  5 
 lib/efi_loader/Kconfig  |  9 ++
 lib/efi_loader/efi_disk.c   | 70 +++--
 lib/efi_loader/efi_memory.c | 16 +++
 4 files changed, 91 insertions(+), 9 deletions(-)

diff --git a/include/efi_loader.h b/include/efi_loader.h
index 8005454..b1ca4ba 100644
--- a/include/efi_loader.h
+++ b/include/efi_loader.h
@@ -139,6 +139,11 @@ uint64_t efi_add_memory_map(uint64_t start, uint64_t 
pages, int memory_type,
 /* Called by board init to initialize the EFI memory map */
 int efi_memory_init(void);
 
+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+extern void *efi_bounce_buffer;
+#define EFI_LOADER_BOUNCE_BUFFER_SIZE (64 * 1024 * 1024)
+#endif
+
 /* Convert strings from normal C strings to uEFI strings */
 static inline void ascii2unicode(u16 *unicode, char *ascii)
 {
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index 14c99ec..37a0dd6 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -7,3 +7,12 @@ config EFI_LOADER
  on top of U-Boot. If this option is enabled, U-Boot will expose EFI
  interfaces to a loaded EFI application, enabling it to reuse U-Boot's
  device drivers.
+
+config EFI_LOADER_BOUNCE_BUFFER
+   bool "EFI Applications use bounce buffers for DMA operations"
+   depends on EFI_LOADER && ARM64
+   default n
+   help
+ Some hardware does not support DMA to full 64bit addresses. For this
+ hardware we can create a bounce buffer so that payloads don't have to
+ worry about platform details.
diff --git a/lib/efi_loader/efi_disk.c b/lib/efi_loader/efi_disk.c
index 28e5b7f..ffce286 100644
--- a/lib/efi_loader/efi_disk.c
+++ b/lib/efi_loader/efi_disk.c
@@ -75,9 +75,6 @@ static efi_status_t EFIAPI efi_disk_rw_blocks(struct 
efi_block_io *this,
int blocks;
unsigned long n;
 
-   EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba,
- buffer_size, buffer);
-
diskobj = container_of(this, struct efi_disk_obj, ops);
if (!(desc = blk_get_dev(diskobj->ifname, diskobj->dev_index)))
return EFI_EXIT(EFI_DEVICE_ERROR);
@@ -94,10 +91,11 @@ static efi_status_t EFIAPI efi_disk_rw_blocks(struct 
efi_block_io *this,
if (buffer_size & (blksz - 1))
return EFI_EXIT(EFI_DEVICE_ERROR);
 
-   if (direction == EFI_DISK_READ)
+   if (direction == EFI_DISK_READ) {
n = desc->block_read(desc, lba, blocks, buffer);
-   else
+   } else {
n = desc->block_write(desc, lba, blocks, buffer);
+   }
 
/* We don't do interrupts, so check for timers cooperatively */
efi_timer_check();
@@ -115,16 +113,70 @@ static efi_status_t efi_disk_read_blocks(struct 
efi_block_io *this,
u32 media_id, u64 lba, unsigned long buffer_size,
void *buffer)
 {
-   return efi_disk_rw_blocks(this, media_id, lba, buffer_size, buffer,
- EFI_DISK_READ);
+   void *real_buffer = buffer;
+   efi_status_t r;
+
+#ifdef CONFIG_EFI_LOADER_BOUNCE_BUFFER
+   if (buffer_size > EFI_LOADER_BOUNCE_BUFFER_SIZE) {
+   r = efi_disk_read_blocks(this, media_id, lba,
+   EFI_LOADER_BOUNCE_BUFFER_SIZE, buffer);
+   if (r != EFI_SUCCESS)
+   return r;
+   return efi_disk_read_blocks(this, media_id, lba +
+   EFI_LOADER_BOUNCE_BUFFER_SIZE / this->media->block_size,
+   buffer_size - EFI_LOADER_BOUNCE_BUFFER_SIZE,
+   buffer + EFI_LOADER_BOUNCE_BUFFER_SIZE);
+   }
+
+   real_buffer = efi_bounce_buffer;
+#endif
+
+   EFI_ENTRY("%p, %x, %"PRIx64", %lx, %p", this, media_id, lba,
+ buffer_size, buffer);
+
+   r = efi_disk_rw_blocks(this, media_id, lba, buffer_size, real_buffer,
+  EFI_DISK_READ);
+
+   /* Copy from bounce buffer to real buffer if necessary */
+   if ((r == EFI_SUCCESS) && (real_buffer != buffer))
+   memcpy(buffer, real_buffer, buffer_size);
+
+   return EFI_EXIT(r);
 }
 
 static efi_status_t efi_disk_write_blocks(struct efi_block_io *this,
u32 media_id, u64 lba, unsigned long buffer_size,
void *buffer)
 {
-   return efi_disk_rw_blocks(this, media_id, lba, buffer_size, buffer,
- EFI_DISK_WRITE);
+   void *real_buffer = buffer;
+   efi_status_t r;
+

[U-Boot] [PATCH 0/2] efi_loader: Add bounce buffers

[Alexander Graf]

While testing our shiny new EFI support, I stumbled across systems that
have disk I/O hardware that can only access the lower 32bits of our
physical address space.

This is not a problem when running with the normal U-Boot flow, since we
define all "pointers" that get in use in our environment, so we can just
put them inside the lower 32bits.

But when a higher level application such as an EFI payload comes across,
it doesn't know about these constraints. So we need to allocate bounce
buffers for the payload and use them instead.

Alexander Graf (2):
  efi_loader: Add bounce buffer support
  efi_loader: Select bounce buffers for known-bad boards

 configs/ls2080a_emu_defconfig|  1 +
 configs/ls2080a_simu_defconfig   |  1 +
 configs/ls2080aqds_SECURE_BOOT_defconfig |  1 +
 configs/ls2080aqds_defconfig |  1 +
 configs/ls2080aqds_nand_defconfig|  1 +
 configs/ls2080ardb_SECURE_BOOT_defconfig |  1 +
 configs/ls2080ardb_defconfig |  1 +
 configs/ls2080ardb_nand_defconfig|  1 +
 configs/xilinx_zynqmp_ep_defconfig   |  1 +
 configs/xilinx_zynqmp_zc1751_xm015_dc1_defconfig |  1 +
 configs/xilinx_zynqmp_zc1751_xm016_dc2_defconfig |  1 +
 configs/xilinx_zynqmp_zc1751_xm019_dc5_defconfig |  1 +
 configs/xilinx_zynqmp_zcu102_defconfig   |  1 +
 configs/xilinx_zynqmp_zcu102_revB_defconfig  |  1 +
 include/efi_loader.h |  5 ++
 lib/efi_loader/Kconfig   |  9 +++
 lib/efi_loader/efi_disk.c| 70 +---
 lib/efi_loader/efi_memory.c  | 16 ++
 18 files changed, 105 insertions(+), 9 deletions(-)

-- 
1.8.5.6

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

Re: [U-Boot] [PATCH 0/8] ARM: AM335x: Add support for ICEv2 board

[Tom Rini]

On Tue, May 10, 2016 at 02:33:47PM +0530, Lokesh Vutla wrote:

> TI's Industrial Communication Engine EVM is a low cost hardware mainly
> developed for industrial communication type applications using serial
> or Ethernet based interfaces. This platform features TI's AM3359 with
> 800MHz single core Cortex-A8 processor, 256MB DDR3, 64MB SPI flash,
> 8MB NOR Flash, mmc, usb, can, dual Ethernet ports.
> 
> For more information, look at HW user guide[1], Data manual[2].
> 
> Just add basic support for the moment.
> 
> [1] 
> http://processors.wiki.ti.com/index.php/AM335x_Industrial_Communication_Engine_EVM_Rev2_1_HW_User_Guide
> [2] http://www.ti.com/lit/ds/symlink/am3359.pdf
> 
> Logs: http://pastebin.ubuntu.com/16342968/ 

OK, so this depends on the series that adds FIT+SPL to am335x which is
good.  But I don't want to see adding in another defconfig for this.
Lets just figure out what we need to enable / change so that we can pick
the correct console here at run time (which will also make the ICE v1
supportable too and beaglebone people with UART capes too).  Thanks!

-- 
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 0/8] ARM: AM335x: Add support for FIT and various platforms

[Tom Rini]

On Tue, May 10, 2016 at 01:18:16PM +0530, Lokesh Vutla wrote:

> This series adds support for FIT and various AM335x based platforms
> 
> BBB: http://pastebin.ubuntu.com/16340189/ 
> BBW: http://pastebin.ubuntu.com/16340238/ 
> AM335x-evm: http://pastebin.ubuntu.com/16340157/ 
> AM335x-evmsk: http://pastebin.ubuntu.com/16340327/
> 
> Lokesh Vutla (6):
>   ARM: AM33xx: configs: Rename am335x_evm to am335xx_evm_nodt defconfig

OK, just like the am43xx series, lets just move over to FIT+DT in SPL
and drop the old case, no "nodt" config.

-- 
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] [PULL] u-boot-socfpga/master

[Tom Rini]

On Sat, May 07, 2016 at 03:42:15AM +0200, Marek Vasut wrote:

> The following changes since commit
> bbca7108db79076d3a9a9c112792d7c4608a665c:
> 
> 
> 
>   ARM: tegra: import latest Jetson TK1 spreadsheet (2016-05-04 13:31:04
> -0700)
> 
> 
> are available in the git repository at:
> 
> 
> 
>   git://git.denx.de/u-boot-socfpga.git master
> 
> 
> 
> for you to fetch changes up to 5289c5fa5371dada10e9cbdcdbf3fb010905ea2d:
> 
>   socfpga: fix broken build if CONFIG_ETH_DESIGNWARE disabled
> (2016-05-06 18:41:49 +0200)
> 

As of a few days ago, applied to u-boot/master, thanks!

-- 
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] [PULL] u-boot-usb/master

[Tom Rini]

On Sat, May 07, 2016 at 03:41:11AM +0200, Marek Vasut wrote:

> The following changes since commit bbca7108db79076d3a9a9c112792d7c4608a665c:
> 
>   ARM: tegra: import latest Jetson TK1 spreadsheet (2016-05-04 13:31:04
> -0700)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to 12ff19dbfd93abdb62b7b326fee3f5bfa659a75e:
> 
>   usb: gadget: dfu: discard dead code (2016-05-06 20:06:56 +0200)
> 

As of a few days ago, applied to u-boot/master, thanks!

-- 
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 8/9][v2] armv8: ls1012a: Add support of ls1012aqds board

[York Sun]

On 05/11/2016 12:30 AM, Prabhakar Kushwaha wrote:
> QorIQ LS1012A Development System (LS1012AQDS) is a high-performance
> development platform, with a complete debugging environment.
> The LS1012AQDS board supports the QorIQ LS1012A processor and is
> optimized to support the high-bandwidth DDR3L memory and
> a full complement of high-speed SerDes ports.
> 
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Pratiyush Mohan Srivastava 
> Signed-off-by: Abhimanyu Saini 
> Signed-off-by: Prabhakar Kushwaha 
> ---
> Changes for v2: 
>   - Added support of qixis over i2c
>   - print fpga, board info using qixis
> 
>  arch/arm/Kconfig  |  10 ++
>  arch/arm/dts/Makefile |   3 +-
>  arch/arm/dts/fsl-ls1012a-qds.dts  |  14 ++
>  arch/arm/dts/fsl-ls1012a-qds.dtsi | 123 ++
>  arch/arm/dts/fsl-ls1012a.dtsi | 119 ++
>  board/freescale/ls1012aqds/Kconfig|  15 ++
>  board/freescale/ls1012aqds/MAINTAINERS|   6 +
>  board/freescale/ls1012aqds/Makefile   |   7 +
>  board/freescale/ls1012aqds/README |  94 +++
>  board/freescale/ls1012aqds/ls1012aqds.c   | 220 
> ++
>  board/freescale/ls1012aqds/ls1012aqds_qixis.h |  35 
>  configs/ls1012aqds_qspi_defconfig |  32 
>  include/configs/ls1012a_common.h  | 195 +++
>  include/configs/ls1012aqds.h  | 150 ++
>  14 files changed, 1022 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dts
>  create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dtsi
>  create mode 100644 arch/arm/dts/fsl-ls1012a.dtsi
>  create mode 100644 board/freescale/ls1012aqds/Kconfig
>  create mode 100644 board/freescale/ls1012aqds/MAINTAINERS
>  create mode 100644 board/freescale/ls1012aqds/Makefile
>  create mode 100644 board/freescale/ls1012aqds/README
>  create mode 100644 board/freescale/ls1012aqds/ls1012aqds.c
>  create mode 100644 board/freescale/ls1012aqds/ls1012aqds_qixis.h
>  create mode 100644 configs/ls1012aqds_qspi_defconfig
>  create mode 100644 include/configs/ls1012a_common.h
>  create mode 100644 include/configs/ls1012aqds.h
> 



> diff --git a/board/freescale/ls1012aqds/MAINTAINERS 
> b/board/freescale/ls1012aqds/MAINTAINERS
> new file mode 100644
> index 000..3c01df6
> --- /dev/null
> +++ b/board/freescale/ls1012aqds/MAINTAINERS
> @@ -0,0 +1,6 @@
> +LS1012AQDS BOARD
> +M:
> +S:   Maintained
> +F:   board/freescale/ls1012aqds/
> +F:   include/configs/ls1012aqds.h
> +F:   configs/ls1012aqds_defconfig

Please add maintainer name.

> diff --git a/board/freescale/ls1012aqds/Makefile 
> b/board/freescale/ls1012aqds/Makefile
> new file mode 100644
> index 000..0b813f9
> --- /dev/null
> +++ b/board/freescale/ls1012aqds/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Copyright 2016 Freescale Semiconductor, Inc.
> +#
> +# SPDX-License-Identifier:  GPL-2.0+
> +#
> +
> +obj-y += ls1012aqds.o
> diff --git a/board/freescale/ls1012aqds/README 
> b/board/freescale/ls1012aqds/README
> new file mode 100644
> index 000..e94a267
> --- /dev/null
> +++ b/board/freescale/ls1012aqds/README
> @@ -0,0 +1,94 @@
> +Overview
> +
> +The LS1012AQDS power supplies (PS) provide all the voltages necessary
> +for the correct operation of the LS1012A processor, DDR3L, QSPI memory,
> +and other onboard peripherals.

Power suppliers? That's all you have?


> +
> +LS1012A SoC Overview
> +
> +The LS1012A features an advanced 64-bit ARM v8 Cortex-
> +A53 processor, with 32 KB of parity protected L1-I cache,
> +32 KB of ECC protected L1-D cache, as well as 256 KB of
> +ECC protected L2 cache.
> +
> +The LS1012A SoC includes the following function and features:
> + - One 64-bit ARM v8 Cortex-A53 core with the following capabilities:
> + - ARM v8 cryptography extensions
> + - One 16-bit DDR3L SDRAM memory controller, Up to 1.0 GT/s, Supports
> +16-/8-bit operation (no ECC support)
> + - ARM core-link CCI-400 cache coherent interconnect
> + - Packet Forwarding Engine (PFE)
> + - Cryptography acceleration (SEC)
> + - Ethernet interfaces supported by PFE:
> + - One Configurable x3 SerDes:
> +Two Serdes PLLs supported for usage by any SerDes data lane
> +Support for up to 6 GBaud operation
> + - High-speed peripheral interfaces:
> + - One PCI Express Gen2 controller, supporting x1 operation
> + - One serial ATA (SATA Gen 3.0) controller
> + - One USB 3.0/2.0 controller with integrated PHY
> + - One USB 2.0 controller with ULPI interface. .
> + - Additional peripheral interfaces:
> +- One quad serial peripheral interface (QuadSPI) controller
> +- One serial peripheral interface (SPI) controller
> +- Two enhanced secure digital host controllers
> +- Two I2C 

[U-Boot] [RESEND RFC PATCH] zynq: add support for on-board shared reset gpio

[Andrea Merello]

I'm adding support [1] for another zynq-based board (MYIR Zturn [2]).

This board has one peculiarity that I have to deal with: it has a shared reset
signal that hits both the USB PHY and the Ethernet PHY, and this is routed to
a GPIO that must be shaken down and up before using those two pheripherals
(especially USB) in order to make things working.

This must be done before the two ethernet and USB drivers probes, so I couldn't
delegate this to any of the twos..

Right now I added a top-level node "board" to my DT containing the GPIO property
and I handle this in the board initialization code.

board {
phys-reset-gpio = < 51 GPIO_ACTIVE_LOW>;
};

RFC: is this a good/clean way to handle this thing? Ideally I would like to
put this mechanism out of the Zynq-specific board file, so that it could be
available for any kind of board..

(once a clean way to handle this thing have been agreed I'll rebase and I'll
post a patch serie for adding support for that board).

[1] https://github.com/andreamerello/u-boot-zynq
[2] http://www.myirtech.com/list.asp?id=502

Signed-off-by: Andrea Merello 

diff --git a/board/xilinx/zynq/board.c b/board/xilinx/zynq/board.c
index 183f642..f72b219 100644
--- a/board/xilinx/zynq/board.c
+++ b/board/xilinx/zynq/board.c
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 

 DECLARE_GLOBAL_DATA_PTR;

@@ -70,8 +71,43 @@ int board_init(void)
return 0;
 }

+int phys_reset(void)
+{
+   struct gpio_desc reset_gpio;
+   int nodeoffset;
+   const void *blob = gd->fdt_blob;
+
+   nodeoffset = fdt_path_offset(blob, "/board");
+   if (nodeoffset == -FDT_ERR_NOTFOUND)
+   return 0;
+   if (nodeoffset < 0)
+   return nodeoffset;
+
+   gpio_request_by_name_nodev(blob, nodeoffset, "phys-reset-gpio", 0,
+  _gpio, 0);
+
+   if (dm_gpio_is_valid(_gpio)) {
+   /* reset PHYs (ethernet and USB) before any driver comes up */
+   dm_gpio_set_dir_flags(_gpio, reset_gpio.flags |
+   GPIOD_IS_OUT | GPIOD_IS_OUT_ACTIVE);
+
+   mdelay(100);
+   dm_gpio_set_dir_flags(_gpio, (reset_gpio.flags |
+   GPIOD_IS_OUT) & ~GPIOD_IS_OUT_ACTIVE);
+
+   /* wait for PHYs to come up before going on */
+   mdelay(100);
+
+   printf("PHYs reset OK\n");
+   }
+
+   return 0;
+}
+
 int board_late_init(void)
 {
+   phys_reset();
+
switch ((zynq_slcr_get_boot_mode()) & ZYNQ_BM_MASK) {
case ZYNQ_BM_NOR:
setenv("modeboot", "norboot");
--
2.1.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 9/9][v2] armv8: ls1012a: Add support of ls1012ardb board

[York Sun]

On 05/11/2016 12:30 AM, Prabhakar Kushwaha wrote:
> QorIQ LS1012A Reference Design System (LS1012ARDB) is a high-performance
> development platform, with a complete debugging environment.
> The LS1012ARDB board supports the QorIQ LS1012A processor and is
> optimized to support the high-bandwidth DDR3L memory and
> a full complement of high-speed SerDes ports.
> 
> Signed-off-by: Calvin Johnson 
> Signed-off-by: Pratiyush Mohan Srivastava 
> Signed-off-by: Prabhakar Kushwaha 
> ---
> Changes for v2: Sending as it is
> 
>  arch/arm/Kconfig|  10 ++
>  arch/arm/dts/Makefile   |   3 +-
>  arch/arm/dts/fsl-ls1012a-rdb.dts|  16 +++
>  arch/arm/dts/fsl-ls1012a-rdb.dtsi   |  39 ++
>  board/freescale/ls1012ardb/Kconfig  |  15 +++
>  board/freescale/ls1012ardb/MAINTAINERS  |   6 +
>  board/freescale/ls1012ardb/Makefile |   7 ++
>  board/freescale/ls1012ardb/README   |  89 ++
>  board/freescale/ls1012ardb/ls1012ardb.c | 210 
> 
>  configs/ls1012ardb_qspi_defconfig   |  32 +
>  include/configs/ls1012ardb.h|  59 +
>  11 files changed, 485 insertions(+), 1 deletion(-)
>  create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dts
>  create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dtsi
>  create mode 100644 board/freescale/ls1012ardb/Kconfig
>  create mode 100644 board/freescale/ls1012ardb/MAINTAINERS
>  create mode 100644 board/freescale/ls1012ardb/Makefile
>  create mode 100644 board/freescale/ls1012ardb/README
>  create mode 100644 board/freescale/ls1012ardb/ls1012ardb.c
>  create mode 100644 configs/ls1012ardb_qspi_defconfig
>  create mode 100644 include/configs/ls1012ardb.h
> 



> diff --git a/board/freescale/ls1012ardb/MAINTAINERS 
> b/board/freescale/ls1012ardb/MAINTAINERS
> new file mode 100644
> index 000..757e810
> --- /dev/null
> +++ b/board/freescale/ls1012ardb/MAINTAINERS
> @@ -0,0 +1,6 @@
> +LS1012ARDB BOARD
> +M:
> +S:   Maintained
> +F:   board/freescale/ls1012ardb/
> +F:   include/configs/ls1012ardb.h
> +F:   configs/ls1012ardb_defconfig

Who is the maintainer for this board?

> diff --git a/board/freescale/ls1012ardb/Makefile 
> b/board/freescale/ls1012ardb/Makefile
> new file mode 100644
> index 000..05fa9d9
> --- /dev/null
> +++ b/board/freescale/ls1012ardb/Makefile
> @@ -0,0 +1,7 @@
> +#
> +# Copyright 2016 Freescale Semiconductor, Inc.
> +#
> +# SPDX-License-Identifier:  GPL-2.0+
> +#
> +
> +obj-y += ls1012ardb.o
> diff --git a/board/freescale/ls1012ardb/README 
> b/board/freescale/ls1012ardb/README
> new file mode 100644
> index 000..cda03f6
> --- /dev/null
> +++ b/board/freescale/ls1012ardb/README
> @@ -0,0 +1,89 @@
> +Overview
> +
> +The LS1012ARDB power supplies (PS) provide all the voltages necessary
> +for the correct operation of the LS1012A processor, DDR3L, QSPI memory,
> +and other onboard peripherals.
> +
> +LS1012A SoC Overview
> +
> +The LS1012A features an advanced 64-bit ARM v8 Cortex-
> +A53 processor, with 32 KB of parity protected L1-I cache,
> +32 KB of ECC protected L1-D cache, as well as 256 KB of
> +ECC protected L2 cache.
> +
> +The LS1012A SoC includes the following function and features:
> + - One 64-bit ARM v8 Cortex-A53 core with the following capabilities:
> + - ARM v8 cryptography extensions
> + - One 16-bit DDR3L SDRAM memory controller, Up to 1.0 GT/s, Supports
> +16-/8-bit operation (no ECC support)
> + - ARM core-link CCI-400 cache coherent interconnect
> + - Packet Forwarding Engine (PFE)
> + - Cryptography acceleration (SEC)
> + - Ethernet interfaces supported by PFE:
> + - One Configurable x3 SerDes:
> +Two Serdes PLLs supported for usage by any SerDes data lane
> +Support for up to 6 GBaud operation
> + - High-speed peripheral interfaces:
> + - One PCI Express Gen2 controller, supporting x1 operation
> + - One serial ATA (SATA Gen 3.0) controller
> + - One USB 3.0/2.0 controller with integrated PHY
> + - One USB 2.0 controller with ULPI interface. .
> + - Additional peripheral interfaces:
> +- One quad serial peripheral interface (QuadSPI) controller
> +- One serial peripheral interface (SPI) controller
> +- Two enhanced secure digital host controllers
> +- Two I2C controllers
> +- One 16550 compliant DUART (two UART interfaces)
> +- Two general purpose IOs (GPIO)
> +- Two FlexTimers
> +- Five synchronous audio interfaces (SAI)
> +- Pre-boot loader (PBL) provides pre-boot initialization and RCW loading
> +- Single-source clocking solution enabling generation of core, platform,
> +DDR, SerDes, and USB clocks from a single external crystal and internal
> +crystaloscillator
> +- Thermal monitor unit (TMU) with +/- 3C accuracy
> +- Two WatchDog timers
> +- ARM generic timer
> + - QorIQ platform's trust architecture 2.1

SoC 

Re: [U-Boot] U-boot UBI environment

[Kevin Smith]

Hi Joe and Heiko,

I tried disabling the fastmap options, and it appears to be related to 
these.  With fastmap off, I am able two write without corrupting the 
other volume.  It looks like it may specifically be the autoupdate 
feature, but I am still testing to be sure this is the case.  I will let 
you know.

Thank you for your help,
Kevin

On 05/11/2016 12:51 AM, Heiko Schocher wrote:
> Hello Joe,
>
> Am 11.05.2016 um 01:15 schrieb Joseph Hershberger:
>> Hi Kevin,
>>
>> Am 09.05.2016 um 23:16 schrieb Kevin Smith:
>>> Hello,
>>>
>>> I would appreciate some UBI help/advice if you are able to provide it.
>>> I am trying to use UBI to store my u-boot environment, but when I try
>>> to 'saveenv', it is corrupting another volume of my UBI.  I can image
>>> the rootfs volume and boot Linux from it without a problem. However,
>>> the first time that I save the u-boot environment, the rootfs becomes
>>> unreadable.  When the rootfs is corrupted, I have booted Linux from
>>> another source and tried to attach UBI and dd out the data. It
>>> appears as all 0xFF.  Both u-boot and Linux can read the env volume 
>>> correctly.
>>>
>>> I do not think that there is a board in U-boot that uses UBI env, so I
>>> do not have anything to compare to.  I have included some details of
>>> my setup below.  Do you have any suggestion about what might be wrong?
>>> I saw the recent patch b1d6590d35, and thought it might fix it, but am
>>> still having the problem even with this.  Maybe there is another bug?
>>> I am glad to provide more info as needed.
>>> Thank you,
>>> Kevin
>>>
>>> DTS:
>>> flash@d {
>>>num-cs = <1>;
>>>marvell,nand-keep-config;
>>>marvell,nand-enable-arbiter;
>>>nand-on-flash-bbt;
>>>nand-ecc-strength = <4>;
>>>nand-ecc-step-size = <512>;
>>>status = "okay";
>>>
>>>partition@0 {
>>>label = "mvboot";
>>>reg = <0 0x20>;
>>>};
>>>partition@20 {
>>>label = "ubi";
>>>reg = <0x20 0x1fe0>;
>>>};
>>> };
>>> Config:
>>> #define MTDIDS_DEFAULT"nand0=pxa3xx_nand-0"
>>> #define MTDPARTS_DEFAULT "mtdparts=pxa3xx_nand-0:2m(mvboot),-(ubi)"
>>> #define CONFIG_CMD_UBI
>>> #define CONFIG_CMD_UBIFS
>>
>>> #define CONFIG_MTD_UBI_FASTMAP
>>> #define CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT1
>>
>> I don’t define these 2, not sure if it matters.
>
> This should be no problem ... but you (Kevin) may disable
> FASTMAP for a test?
>
>>> #define CONFIG_ENV_IS_IN_UBI
>>> #define CONFIG_ENV_UBI_PART"ubi"
>>> #define CONFIG_ENV_UBI_VOLUME"u-boot-env"
>>> #define CONFIG_ENV_SIZE(64 * 1024)
>>
>> My config looks like this:
>>
>> #define MTDIDS_DEFAULT "nand0=xilinx_nand"
>> #define MTDPARTS_DEFAULT \
>> "mtdparts=xilinx_nand:" \
>> "128k(fsbl)ro," \
>> "11M(u-boot)ro," \
>> "70M(boot-config)," \
>> "-(root)"
>
> You have 70MB for Env?
>
>> #define CONFIG_ENV_IS_IN_UBI
>> #define CONFIG_ENV_UBI_PART "boot-config"
>> #define CONFIG_ENV_UBI_VOLUME "u-boot-env1"
>> #define CONFIG_ENV_UBI_VOLUME_REDUND "u-boot-env2"
>> #define CONFIG_ENV_SIZE0x2
>>
>> I create volumes like this:
>>
>> "writepartitions=" \
>> "if ubi part boot-config && " \
>> "ubi read $verifyaddr u-boot-env1 1 && " \
>> "ubi read $verifyaddr u-boot-env2 1; " \
>> "then " \
>> "ubi remove bootfs && " \
>> "ubi remove config; " \
>> "else " \
>> "nand erase.part boot-config && " \
>> "ubi part boot-config && " \
>> "ubi create u-boot-env1 " __stringify(CONFIG_ENV_SIZE) " 
>> dynamic && " \
>> "ubi create u-boot-env2 " __stringify(CONFIG_ENV_SIZE) " 
>> dynamic; " \
>> "fi && " \
>> "ubi create bootfs " __stringify(CONFIG_BOOTFS_VOLUME_SIZE) " 
>> dynamic && " \
>> "ubi create config - dynamic && " \
>> "if ubi part root && " \
>> "ubi read $verifyaddr rootfs 1; " \
>> "then " \
>> "ubi remove rootfs; " \
>> "else " \
>> "nand erase.part root && " \
>> "ubi part root; " \
>> "fi && " \
>> "ubi create rootfs - dynamic;\0" \
>>
>>
>>> => ubi info
>>> UBI: MTD device name:"mtd=1"
>>> UBI: MTD device size:510 MiB
>>> UBI: physical eraseblock size:   131072 bytes (128 KiB)
>>> UBI: logical eraseblock size:126976 bytes
>>> UBI: number of good PEBs:4072
>>> UBI: number of bad PEBs: 8
>>> UBI: smallest flash I/O unit:2048
>>> UBI: VID header offset:  2048 (aligned 2048)
>>> UBI: data offset:4096
>>> UBI: max. allowed volumes:   128
>>> UBI: wear-leveling threshold:4096
>>> UBI: number of internal volumes: 1
>>> UBI: number of user volumes: 2
>>> UBI: available PEBs: 0
>>> UBI: total number of reserved PEBs: 4072
>>> UBI: number of 

[U-Boot] [PATCH v2 15/18] acpi: Quieten IASL output when 'make -s' is used

[Bin Meng]

IASL compiler does not provide a command line option to turn off
its non-warning message. To quieten the output when 'make -s',
redirect its output to /dev/null.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 scripts/Makefile.lib | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 44534e1..97a09a2 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -326,7 +326,7 @@ $(obj)/%.S: $(src)/%.ttf
 quiet_cmd_acpi_c_asl= ASL $<
 cmd_acpi_c_asl= \
$(CPP) -x assembler-with-cpp -P $(UBOOTINCLUDE) -o $<.tmp $<; \
-   iasl -p $< -tc $<.tmp; \
+   iasl -p $< -tc $<.tmp $(if $(KBUILD_VERBOSE:1=), >/dev/null); \
mv $(patsubst %.asl,%.hex,$<) $@
 
 $(obj)/dsdt.c:$(src)/dsdt.asl
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 18/18] x86: doc: Add porting hints for ACPI with Windows

[Bin Meng]

Windows might cache system information and only detect ACPI changes
if you modify the ACPI table versions.

Signed-off-by: Bin Meng 

---

Changes in v2: None

 doc/README.x86 | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/README.x86 b/doc/README.x86
index 75762de..4d50feb 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -982,6 +982,12 @@ transformations. Remember to add attribution to coreboot 
for new files added
 to U-Boot. This should go at the top of each file and list the coreboot
 filename where the code originated.
 
+Debugging ACPI issues with Windows:
+
+Windows might cache system information and only detect ACPI changes if you
+modify the ACPI table versions. So tweak them liberally when debugging ACPI
+issues with Windows.
+
 ACPI Support Status
 ---
 Advanced Configuration and Power Interface (ACPI) [16] aims to establish
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 09/18] x86: acpi: Switch to ACPI mode by ourselves instead of requested by OSPM

[Bin Meng]

Per ACPI spec, during ACPI OS initialization, OSPM can determine
that the ACPI hardware registers are owned by SMI (by way of the
SCI_EN bit in the PM1_CNT register), in which case the ACPI OS
issues the ACPI_ENABLE command to the SMI_CMD port. The SCI_EN bit
effectively tracks the ownership of the ACPI hardware registers.

However since U-Boot does not support SMI, we report all 3 fields
in FADT (SMI_CMD, ACPI_ENABLE, ACPI_DISABLE) as zero, by following
the spec who says: these fields are reserved and must be zero on
system that does not support System Management mode.

U-Boot seems to behave in a correct way that the ACPI spec allows,
at least Linux does not complain, but apparently Windows does not
think so. During Windows bring up debugging, it is observed that
even these 3 fields are zero, Windows are still trying to issue SMI
with hardcoded SMI port address and commands, and expecting SCI_EN
to be changed by the firmware. Eventually Windows gives us a BSOD
(Blue Screen of Death) saying ACPI_BIOS_ERROR and refuses to start.

To fix this, turn on the SCI_EN bit by ourselves. With this patch,
now U-Boot can install and boot Windows 8.1/10 successfully with
the help of SeaBIOS using legacy interface (non-UEFI mode).

Signed-off-by: Bin Meng 
---

Changes in v2: None

 arch/x86/include/asm/acpi_table.h |  3 +++
 arch/x86/lib/acpi_table.c | 26 ++
 2 files changed, 29 insertions(+)

diff --git a/arch/x86/include/asm/acpi_table.h 
b/arch/x86/include/asm/acpi_table.h
index ff4802a..56aa282 100644
--- a/arch/x86/include/asm/acpi_table.h
+++ b/arch/x86/include/asm/acpi_table.h
@@ -296,6 +296,9 @@ struct acpi_mcfg_mmconfig {
u8 reserved[4];
 };
 
+/* PM1_CNT bit defines */
+#define PM1_CNT_SCI_EN (1 << 0)
+
 /* These can be used by the target port */
 
 void acpi_fill_header(struct acpi_table_header *header, char *signature);
diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 989cf7d..a9fe243 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -301,6 +302,25 @@ static void acpi_create_mcfg(struct acpi_mcfg *mcfg)
header->checksum = table_compute_checksum((void *)mcfg, header->length);
 }
 
+static void enter_acpi_mode(int pm1_cnt)
+{
+   /*
+* PM1_CNT register bit0 selects the power management event to be
+* either an SCI or SMI interrupt. When this bit is set, then power
+* management events will generate an SCI interrupt. When this bit
+* is reset power management events will generate an SMI interrupt.
+*
+* Per ACPI spec, it is the responsibility of the hardware to set
+* or reset this bit. OSPM always preserves this bit position.
+*
+* U-Boot does not support SMI. And we don't have plan to support
+* anything running in SMM within U-Boot. To create a legacy-free
+* system, and expose ourselves to OSPM as working under ACPI mode
+* already, turn this bit on.
+*/
+   outw(PM1_CNT_SCI_EN, pm1_cnt);
+}
+
 /*
  * QEMU's version of write_acpi_tables is defined in
  * arch/x86/cpu/qemu/fw_cfg.c
@@ -400,5 +420,11 @@ u32 write_acpi_tables(u32 start)
 
debug("ACPI: done\n");
 
+   /*
+* Other than waiting for OSPM to request us to switch to ACPI mode,
+* do it by ourselves, since SMI will not be triggered.
+*/
+   enter_acpi_mode(fadt->pm1a_cnt_blk);
+
return current;
 }
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 08/18] x86: Use high_table_malloc() for tables passing to SeaBIOS

[Bin Meng]

Now that we already reserved high memory for configuration tables,
call high_table_malloc() to allocate tables from the region.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 arch/x86/lib/tables.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/x86/lib/tables.c b/arch/x86/lib/tables.c
index 1213a9c..f92111e 100644
--- a/arch/x86/lib/tables.c
+++ b/arch/x86/lib/tables.c
@@ -5,7 +5,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -81,9 +80,8 @@ void write_tables(void)
 
 #ifdef CONFIG_SEABIOS
table_size = rom_table_end - rom_table_start;
-   high_table = (u32)memalign(ROM_TABLE_ALIGN, table_size);
+   high_table = (u32)high_table_malloc(table_size);
if (high_table) {
-   memset((void *)high_table, 0, table_size);
table_write_funcs[i](high_table);
 
cfg_tables[i].start = high_table;
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 13/18] x86: baytrail: Enable SeaBIOS on all boards

[Bin Meng]

SeaBIOS can be loaded by U-Boot to aid the installation of Ubuntu
and Windows to a SATA drive and boot from there. Enable it on all
BayTrail boards.

Signed-off-by: Bin Meng 

---

Changes in v2:
- New patch to enable SeaBIOS on all boards

 configs/bayleybay_defconfig   | 1 +
 configs/conga-qeval20-qa3-e3845_defconfig | 1 +
 configs/minnowmax_defconfig   | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/bayleybay_defconfig b/configs/bayleybay_defconfig
index 7758c11..9f1d7fb 100644
--- a/configs/bayleybay_defconfig
+++ b/configs/bayleybay_defconfig
@@ -10,6 +10,7 @@ CONFIG_VGA_BIOS_ADDR=0xfffa
 CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
 CONFIG_GENERATE_ACPI_TABLE=y
+CONFIG_SEABIOS=y
 CONFIG_FIT=y
 CONFIG_BOOTSTAGE=y
 CONFIG_BOOTSTAGE_REPORT=y
diff --git a/configs/conga-qeval20-qa3-e3845_defconfig 
b/configs/conga-qeval20-qa3-e3845_defconfig
index 26f416c..64fd7c9 100644
--- a/configs/conga-qeval20-qa3-e3845_defconfig
+++ b/configs/conga-qeval20-qa3-e3845_defconfig
@@ -9,6 +9,7 @@ CONFIG_HAVE_VGA_BIOS=y
 CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
 CONFIG_GENERATE_ACPI_TABLE=y
+CONFIG_SEABIOS=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_BOOTSTAGE=y
diff --git a/configs/minnowmax_defconfig b/configs/minnowmax_defconfig
index 5daa648..28b837d 100644
--- a/configs/minnowmax_defconfig
+++ b/configs/minnowmax_defconfig
@@ -9,6 +9,7 @@ CONFIG_HAVE_VGA_BIOS=y
 CONFIG_GENERATE_PIRQ_TABLE=y
 CONFIG_GENERATE_MP_TABLE=y
 CONFIG_GENERATE_ACPI_TABLE=y
+CONFIG_SEABIOS=y
 CONFIG_FIT=y
 CONFIG_FIT_SIGNATURE=y
 CONFIG_BOOTSTAGE=y
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 05/18] x86: Prepare configuration tables in dedicated high memory region

[Bin Meng]

Currently when CONFIG_SEABIOS is on, U-Boot allocates configuration
tables via normal malloc(). To simplify, use a dedicated memory
region which is reserved on the stack before relocation for this
purpose. Add functions for reserve and malloc.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 arch/x86/Kconfig   | 14 ++
 arch/x86/include/asm/coreboot_tables.h | 19 +++
 arch/x86/include/asm/global_data.h |  4 
 arch/x86/lib/coreboot_table.c  | 31 +++
 4 files changed, 68 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 4ef27dc..d304e29 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -536,6 +536,20 @@ config SEABIOS
 
  Check http://www.seabios.org/SeaBIOS for details.
 
+config HIGH_TABLE_SIZE
+   hex "Size of configuration tables which reside in high memory"
+   default 0x1
+   depends on SEABIOS
+   help
+ SeaBIOS itself resides in E seg and F seg, where U-Boot puts all
+ configuration tables like PIRQ/MP/ACPI. To avoid conflicts, U-Boot
+ puts a copy of configuration tables in high memory region which
+ is reserved on the stack before relocation. The region size is
+ determined by this option.
+
+ Increse it if the default size does not fit the board's needs.
+ This is most likely due to a large ACPI DSDT table is used.
+
 source "arch/x86/lib/efi/Kconfig"
 
 endmenu
diff --git a/arch/x86/include/asm/coreboot_tables.h 
b/arch/x86/include/asm/coreboot_tables.h
index 15ccf9b..e036f74 100644
--- a/arch/x86/include/asm/coreboot_tables.h
+++ b/arch/x86/include/asm/coreboot_tables.h
@@ -295,6 +295,25 @@ struct cbmem_entry {
 #define CBMEM_ID_NONE  0x
 
 /**
+ * high_table_reserve() - reserve configuration table in high memory
+ *
+ * This reserves configuration table in high memory.
+ *
+ * @return:always 0
+ */
+int high_table_reserve(void);
+
+/**
+ * high_table_malloc() - allocate configuration table in high memory
+ *
+ * This allocates configuration table in high memory.
+ *
+ * @bytes: size of configuration table to be allocated
+ * @return:pointer to configuration table in high memory
+ */
+void *high_table_malloc(size_t bytes);
+
+/**
  * write_coreboot_table() - write coreboot table
  *
  * This writes coreboot table at a given address.
diff --git a/arch/x86/include/asm/global_data.h 
b/arch/x86/include/asm/global_data.h
index 3bc2ac2..7434f77 100644
--- a/arch/x86/include/asm/global_data.h
+++ b/arch/x86/include/asm/global_data.h
@@ -93,6 +93,10 @@ struct arch_global_data {
char *mrc_output;
unsigned int mrc_output_len;
ulong table;/* Table pointer from previous loader */
+#ifdef CONFIG_SEABIOS
+   u32 high_table_ptr;
+   u32 high_table_limit;
+#endif
 };
 
 #endif
diff --git a/arch/x86/lib/coreboot_table.c b/arch/x86/lib/coreboot_table.c
index cb45a79..ceab3cf 100644
--- a/arch/x86/lib/coreboot_table.c
+++ b/arch/x86/lib/coreboot_table.c
@@ -9,6 +9,37 @@
 #include 
 #include 
 
+DECLARE_GLOBAL_DATA_PTR;
+
+int high_table_reserve(void)
+{
+   /* adjust stack pointer to reserve space for configuration tables */
+   gd->arch.high_table_limit = gd->start_addr_sp;
+   gd->start_addr_sp -= CONFIG_HIGH_TABLE_SIZE;
+   gd->arch.high_table_ptr = gd->start_addr_sp;
+
+   /* clear the memory */
+   memset((void *)gd->arch.high_table_ptr, 0, CONFIG_HIGH_TABLE_SIZE);
+
+   gd->start_addr_sp &= ~0xf;
+
+   return 0;
+}
+
+void *high_table_malloc(size_t bytes)
+{
+   u32 new_ptr;
+   void *ptr;
+
+   new_ptr = gd->arch.high_table_ptr + bytes;
+   if (new_ptr >= gd->arch.high_table_limit)
+   return NULL;
+   ptr = (void *)gd->arch.high_table_ptr;
+   gd->arch.high_table_ptr = new_ptr;
+
+   return ptr;
+}
+
 /**
  * cb_table_init() - initialize a coreboot table header
  *
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 06/18] x86: Unify reserve_arch() for all x86 boards

[Bin Meng]

Instead of asking each platform to provide reserve_arch(),
supply it in arch/x86/cpu/cpu.c in a unified way.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 arch/x86/cpu/baytrail/valleyview.c |  8 
 arch/x86/cpu/broadwell/sdram.c |  5 -
 arch/x86/cpu/cpu.c | 12 
 arch/x86/cpu/ivybridge/sdram.c |  5 -
 arch/x86/cpu/quark/quark.c |  9 -
 5 files changed, 12 insertions(+), 27 deletions(-)

diff --git a/arch/x86/cpu/baytrail/valleyview.c 
b/arch/x86/cpu/baytrail/valleyview.c
index 25382f9..b31f24e 100644
--- a/arch/x86/cpu/baytrail/valleyview.c
+++ b/arch/x86/cpu/baytrail/valleyview.c
@@ -53,14 +53,6 @@ int arch_misc_init(void)
return 0;
 }
 
-int reserve_arch(void)
-{
-#ifdef CONFIG_ENABLE_MRC_CACHE
-   return mrccache_reserve();
-#else
-   return 0;
-#endif
-}
 #endif
 
 void reset_cpu(ulong addr)
diff --git a/arch/x86/cpu/broadwell/sdram.c b/arch/x86/cpu/broadwell/sdram.c
index 4bf5d15..e7befde 100644
--- a/arch/x86/cpu/broadwell/sdram.c
+++ b/arch/x86/cpu/broadwell/sdram.c
@@ -190,11 +190,6 @@ static int prepare_mrc_cache(struct pei_data *pei_data)
return 0;
 }
 
-int reserve_arch(void)
-{
-   return mrccache_reserve();
-}
-
 int dram_init(void)
 {
struct pei_data _pei_data __aligned(8);
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 1482153..2e27d78 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -751,3 +752,14 @@ int cpu_init_r(void)
 
return 0;
 }
+
+#ifndef CONFIG_EFI_STUB
+int reserve_arch(void)
+{
+#ifdef CONFIG_ENABLE_MRC_CACHE
+   return mrccache_reserve();
+#else
+   return 0;
+#endif
+}
+#endif
diff --git a/arch/x86/cpu/ivybridge/sdram.c b/arch/x86/cpu/ivybridge/sdram.c
index e35e543..9d9f63d 100644
--- a/arch/x86/cpu/ivybridge/sdram.c
+++ b/arch/x86/cpu/ivybridge/sdram.c
@@ -201,11 +201,6 @@ static int recovery_mode_enabled(void)
return false;
 }
 
-int reserve_arch(void)
-{
-   return mrccache_reserve();
-}
-
 static int copy_spd(struct udevice *dev, struct pei_data *peid)
 {
const void *data;
diff --git a/arch/x86/cpu/quark/quark.c b/arch/x86/cpu/quark/quark.c
index afb3463..cf3fe7f 100644
--- a/arch/x86/cpu/quark/quark.c
+++ b/arch/x86/cpu/quark/quark.c
@@ -360,12 +360,3 @@ void board_final_cleanup(void)
 
return;
 }
-
-int reserve_arch(void)
-{
-#ifdef CONFIG_ENABLE_MRC_CACHE
-   return mrccache_reserve();
-#else
-   return 0;
-#endif
-}
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 17/18] x86: baytrail: Add GPIO ASL description

[Bin Meng]

Since BayTrail, Intel starts to use new GPIO IPs in their chipset.
This adds the GPIO ASL, so that OS can load corresponding drivers
for it. On Linux, this is BayTrail pinctrl driver.

Signed-off-by: Bin Meng 

---

Changes in v2:
- New patch to add GPIO ASL description

 arch/x86/include/asm/arch-baytrail/acpi/gpio.asl   | 95 ++
 .../include/asm/arch-baytrail/acpi/platform.asl|  3 +
 2 files changed, 98 insertions(+)
 create mode 100644 arch/x86/include/asm/arch-baytrail/acpi/gpio.asl

diff --git a/arch/x86/include/asm/arch-baytrail/acpi/gpio.asl 
b/arch/x86/include/asm/arch-baytrail/acpi/gpio.asl
new file mode 100644
index 000..ef340f3
--- /dev/null
+++ b/arch/x86/include/asm/arch-baytrail/acpi/gpio.asl
@@ -0,0 +1,95 @@
+/*
+ * Copyright (C) 2013 Google Inc.
+ * Copyright (C) 2016 Bin Meng 
+ *
+ * Modified from coreboot src/soc/intel/baytrail/acpi/gpio.asl
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/* SouthCluster GPIO */
+Device (GPSC)
+{
+   Name(_HID, "INT33FC")
+   Name(_CID, "INT33FC")
+   Name(_UID, 1)
+
+   Name(RBUF, ResourceTemplate()
+   {
+   Memory32Fixed(ReadWrite, 0, 0x1000, RMEM)
+   Interrupt(ResourceConsumer, Level, ActiveLow, Shared, , ,)
+   {
+   GPIO_SC_IRQ
+   }
+   })
+
+   Method(_CRS)
+   {
+   CreateDwordField(^RBUF, ^RMEM._BAS, RBAS)
+   Add(IO_BASE_ADDRESS, IO_BASE_OFFSET_GPSCORE, RBAS)
+   Return (^RBUF)
+   }
+
+   Method(_STA)
+   {
+   Return (STA_VISIBLE)
+   }
+}
+
+/* NorthCluster GPIO */
+Device (GPNC)
+{
+   Name(_HID, "INT33FC")
+   Name(_CID, "INT33FC")
+   Name(_UID, 2)
+
+   Name(RBUF, ResourceTemplate()
+   {
+   Memory32Fixed(ReadWrite, 0, 0x1000, RMEM)
+   Interrupt(ResourceConsumer, Level, ActiveLow, Shared, , ,)
+   {
+   GPIO_NC_IRQ
+   }
+   })
+
+   Method(_CRS)
+   {
+   CreateDwordField(^RBUF, ^RMEM._BAS, RBAS)
+   Add(IO_BASE_ADDRESS, IO_BASE_OFFSET_GPNCORE, RBAS)
+   Return (^RBUF)
+   }
+
+   Method(_STA)
+   {
+   Return (STA_VISIBLE)
+   }
+}
+
+/* SUS GPIO */
+Device (GPSS)
+{
+   Name(_HID, "INT33FC")
+   Name(_CID, "INT33FC")
+   Name(_UID, 3)
+
+   Name(RBUF, ResourceTemplate()
+   {
+   Memory32Fixed(ReadWrite, 0, 0x1000, RMEM)
+   Interrupt(ResourceConsumer, Level, ActiveLow, Shared, , ,)
+   {
+   GPIO_SUS_IRQ
+   }
+   })
+
+   Method(_CRS)
+   {
+   CreateDwordField(^RBUF, ^RMEM._BAS, RBAS)
+   Add(IO_BASE_ADDRESS, IO_BASE_OFFSET_GPSSUS, RBAS)
+   Return (^RBUF)
+   }
+
+   Method(_STA)
+   {
+   Return (STA_VISIBLE)
+   }
+}
diff --git a/arch/x86/include/asm/arch-baytrail/acpi/platform.asl 
b/arch/x86/include/asm/arch-baytrail/acpi/platform.asl
index bd72842..6bc82ec 100644
--- a/arch/x86/include/asm/arch-baytrail/acpi/platform.asl
+++ b/arch/x86/include/asm/arch-baytrail/acpi/platform.asl
@@ -27,6 +27,9 @@ Method(_WAK, 1)
 Scope (\_SB)
 {
#include "southcluster.asl"
+
+   /* ACPI devices */
+   #include "gpio.asl"
 }
 
 /* Chipset specific sleep states */
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 14/18] x86: doc: Mention Ubuntu/Windows installation and boot support

[Bin Meng]

As of now, U-Boot can support installing and booting Ubuntu/Windows
with the help of SeaBIOS. Update the documentation.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 doc/README.x86 | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86
index 250d5a3..75762de 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -1004,12 +1004,14 @@ in the future. The status as of today is:
  * Support one static DSDT table only, compiled by Intel ACPI compiler.
  * Support S0/S5, reboot and shutdown from OS.
  * Support booting a pre-installed Ubuntu distribution via 'zboot' command.
+ * Support installing and booting Ubuntu 14.04 (or above) from U-Boot with
+   the help of SeaBIOS using legacy interface (non-UEFI mode).
+ * Support installing and booting Windows 8.1/10 from U-Boot with the help
+   of SeaBIOS using legacy interface (non-UEFI mode).
  * Support ACPI interrupts with SCI only.
 
 Features not supported so far (to make it a complete ACPI solution):
  * S3 (Suspend to RAM), S4 (Suspend to Disk).
- * Install and boot Ubuntu 14.04 (or above) from U-Boot with legacy interface.
- * Install and boot Windows 8.1/10 from U-Boot with legacy interface.
 
 Features that are optional:
  * ACPI global NVS support. We may need it to simplify ASL code logic if
@@ -1021,8 +1023,10 @@ Features that are optional:
support SMI (a legacy-free system).
 
 So far ACPI is enabled on BayTrail based boards. Testing was done by booting
-a pre-installed Ubuntu 14.04 from a SATA drive. Most devices seem to work
-correctly and the board can respond a reboot/shutdown command from Ubuntu.
+a pre-installed Ubuntu 14.04 from a SATA drive. Installing Ubuntu 14.04 and
+Windows 8.1/10 to a SATA drive and booting from there is also tested. Most
+devices seem to work correctly and the board can respond a reboot/shutdown
+command from the OS.
 
 TODO List
 -
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 12/18] x86: doc: Update information about IGD with SeaBIOS

[Bin Meng]

Document how to make SeaBIOS load and run the VGA ROM of Intel
IGD device when loaded by U-Boot.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 doc/README.x86 | 24 
 1 file changed, 24 insertions(+)

diff --git a/doc/README.x86 b/doc/README.x86
index 25cb218..250d5a3 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -807,6 +807,30 @@ to install/boot a Windows XP OS (below for example command 
to install Windows).
 This is also tested on Intel Crown Bay board with a PCIe graphics card, booting
 SeaBIOS then chain-loading a GRUB on a USB drive, then Linux kernel finally.
 
+If you are using Intel Integrated Graphics Device (IGD) as the primary display
+device on your board, SeaBIOS needs to be patched manually to get its VGA ROM
+loaded and run by SeaBIOS. SeaBIOS locates VGA ROM via the PCI expansion ROM
+register, but IGD device does not have its VGA ROM mapped by this register.
+Its VGA ROM is packaged as part of u-boot.rom at a configurable flash address
+which is unknown to SeaBIOS. An example patch is needed for SeaBIOS below:
+
+diff --git a/src/optionroms.c b/src/optionroms.c
+index 65f7fe0..c7b6f5e 100644
+--- a/src/optionroms.c
 b/src/optionroms.c
+@@ -324,6 +324,8 @@ init_pcirom(struct pci_device *pci, int isvga, u64 
*sources)
+ rom = deploy_romfile(file);
+ else if (RunPCIroms > 1 || (RunPCIroms == 1 && isvga))
+ rom = map_pcirom(pci);
++if (pci->bdf == pci_to_bdf(0, 2, 0))
++rom = (struct rom_header *)0xfff9;
+ if (! rom)
+ // No ROM present.
+ return;
+
+Note: the patch above expects IGD device is at PCI b.d.f 0.2.0 and its VGA ROM
+is at 0xfff9 which corresponds to CONFIG_VGA_BIOS_ADDR on Minnowboard MAX.
+Change these two accordingly if this is not the case on your board.
 
 Development Flow
 
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 16/18] x86: baytrail: Add internal UART ASL description

[Bin Meng]

BayTrail integrates an internal ns15550 compatible UART (PNP0501).
Its IRQ is hardwired to IRQ3 in old revision chipset, but in newer
revision one IRQ4 is being used for ISA compatibility. Handle this
correctly in the ASL file.

Linux does not need this ASL, but Windows need this to correctly
discover a COM port existing in the system so that Windows can
show it in the 'Device Manager' window, and expose this COM port
to any terminal emulation application.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 .../include/asm/arch-baytrail/acpi/irqlinks.asl|  4 ++
 arch/x86/include/asm/arch-baytrail/acpi/lpc.asl| 60 ++
 2 files changed, 64 insertions(+)

diff --git a/arch/x86/include/asm/arch-baytrail/acpi/irqlinks.asl 
b/arch/x86/include/asm/arch-baytrail/acpi/irqlinks.asl
index aa72085..0affa23 100644
--- a/arch/x86/include/asm/arch-baytrail/acpi/irqlinks.asl
+++ b/arch/x86/include/asm/arch-baytrail/acpi/irqlinks.asl
@@ -21,6 +21,10 @@ Scope (\)
PRTF, 8,
PRTG, 8,
PRTH, 8,
+   Offset (0x88),
+   , 3,
+   UI3E, 1,
+   UI4E, 1
}
 }
 
diff --git a/arch/x86/include/asm/arch-baytrail/acpi/lpc.asl 
b/arch/x86/include/asm/arch-baytrail/acpi/lpc.asl
index 1dca977..385671c 100644
--- a/arch/x86/include/asm/arch-baytrail/acpi/lpc.asl
+++ b/arch/x86/include/asm/arch-baytrail/acpi/lpc.asl
@@ -14,6 +14,15 @@ Device (LPCB)
 {
Name(_ADR, 0x001f)
 
+   OperationRegion(LPC0, PCI_Config, 0x00, 0x100)
+   Field(LPC0, AnyAcc, NoLock, Preserve) {
+   Offset(0x08),
+   SRID, 8,
+   Offset(0x80),
+   C1EN, 1,
+   Offset(0x84)
+   }
+
#include "irqlinks.asl"
 
/* Firmware Hub */
@@ -81,6 +90,57 @@ Device (LPCB)
}
}
 
+   /* Internal UART */
+   Device (IURT)
+   {
+   Name(_HID, EISAID("PNP0501"))
+   Name(_UID, 1)
+
+   Method(_STA, 0, Serialized)
+   {
+   /*
+* TODO:
+*
+* Need to hide the internal UART depending on whether
+* internal UART is enabled or not so that external
+* SuperIO UART can be exposed to system.
+*/
+   Store(1, UI3E)
+   Store(1, UI4E)
+   Store(1, C1EN)
+   Return (STA_VISIBLE)
+
+   }
+
+   Method(_DIS, 0, Serialized)
+   {
+   Store(0, UI3E)
+   Store(0, UI4E)
+   Store(0, C1EN)
+   }
+
+   Method(_CRS, 0, Serialized)
+   {
+   Name(BUF0, ResourceTemplate()
+   {
+   IO(Decode16, 0x03f8, 0x03f8, 0x01, 0x08)
+   IRQNoFlags() { 3 }
+   })
+
+   Name(BUF1, ResourceTemplate()
+   {
+   IO(Decode16, 0x03f8, 0x03f8, 0x01, 0x08)
+   IRQNoFlags() { 4 }
+   })
+
+   If (LLessEqual(SRID, 0x04)) {
+   Return (BUF0)
+   } Else {
+   Return (BUF1)
+   }
+   }
+   }
+
/* Real Time Clock */
Device (RTC)
{
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 07/18] x86: Reserve configuration tables in high memory

[Bin Meng]

When SeaBIOS is on, reserve configuration tables in reserve_arch().

Signed-off-by: Bin Meng 
---

Changes in v2: None

 arch/x86/cpu/cpu.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 2e27d78..e522ff3 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -757,9 +758,13 @@ int cpu_init_r(void)
 int reserve_arch(void)
 {
 #ifdef CONFIG_ENABLE_MRC_CACHE
-   return mrccache_reserve();
-#else
-   return 0;
+   mrccache_reserve();
+#endif
+
+#ifdef CONFIG_SEABIOS
+   high_table_reserve();
 #endif
+
+   return 0;
 }
 #endif
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 04/18] x86: Compile coreboot_table.c only for SeaBIOS

[Bin Meng]

coreboot_table.c only needs to be built when SeaBIOS is used.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 arch/x86/lib/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/lib/Makefile b/arch/x86/lib/Makefile
index dc90df2..73e3e52 100644
--- a/arch/x86/lib/Makefile
+++ b/arch/x86/lib/Makefile
@@ -10,7 +10,7 @@ obj-y += bios_asm.o
 obj-y += bios_interrupts.o
 obj-$(CONFIG_CMD_BOOTM) += bootm.o
 obj-y  += cmd_boot.o
-obj-y  += coreboot_table.o
+obj-$(CONFIG_SEABIOS) += coreboot_table.o
 obj-$(CONFIG_EFI) += efi/
 obj-y  += e820.o
 obj-y  += gcc.o
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 11/18] x86: acpi: Remove header length check when writing tables

[Bin Meng]

Before moving 'current' pointer during ACPI table writing, we always
check the table length to see if it is larger than the table header.
Since our purpose is to generate valid tables, the check logic is
always true, which can be avoided.

Signed-off-by: Bin Meng 

---

Changes in v2:
- New patch to remove header length check when writing tables

 arch/x86/lib/acpi_table.c | 26 ++
 1 file changed, 10 insertions(+), 16 deletions(-)

diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index 05c958d..f959f5d 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -376,13 +376,11 @@ u32 write_acpi_tables(u32 start)
debug("ACPI:* DSDT\n");
dsdt = (struct acpi_table_header *)current;
memcpy(dsdt, , sizeof(struct acpi_table_header));
-   if (dsdt->length >= sizeof(struct acpi_table_header)) {
-   current += sizeof(struct acpi_table_header);
-   memcpy((char *)current,
-   (char *) + sizeof(struct acpi_table_header),
-   dsdt->length - sizeof(struct acpi_table_header));
-   current += dsdt->length - sizeof(struct acpi_table_header);
-   }
+   current += sizeof(struct acpi_table_header);
+   memcpy((char *)current,
+  (char *) + sizeof(struct acpi_table_header),
+  dsdt->length - sizeof(struct acpi_table_header));
+   current += dsdt->length - sizeof(struct acpi_table_header);
current = ALIGN(current, 16);
 
debug("ACPI:* FADT\n");
@@ -395,20 +393,16 @@ u32 write_acpi_tables(u32 start)
debug("ACPI:* MADT\n");
madt = (struct acpi_madt *)current;
acpi_create_madt(madt);
-   if (madt->header.length > sizeof(struct acpi_madt)) {
-   current += madt->header.length;
-   acpi_add_table(rsdp, madt);
-   }
+   current += madt->header.length;
+   acpi_add_table(rsdp, madt);
current = ALIGN(current, 16);
 
debug("ACPI:* MCFG\n");
mcfg = (struct acpi_mcfg *)current;
acpi_create_mcfg(mcfg);
-   if (mcfg->header.length > sizeof(struct acpi_mcfg)) {
-   current += mcfg->header.length;
-   current = ALIGN(current, 16);
-   acpi_add_table(rsdp, mcfg);
-   }
+   current += mcfg->header.length;
+   acpi_add_table(rsdp, mcfg);
+   current = ALIGN(current, 16);
 
debug("current = %x\n", current);
 
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 10/18] x86: acpi: Remove the unnecessary checksum calculation of DSDT

[Bin Meng]

The generated AmlCode[] from IASL already has the calculated DSDT
table checksum in place. No need for us to calculate it again.

Signed-off-by: Bin Meng 

---

Changes in v2:
- New patch to remove the unnecessary checksum calculation of DSDT

 arch/x86/lib/acpi_table.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/arch/x86/lib/acpi_table.c b/arch/x86/lib/acpi_table.c
index a9fe243..05c958d 100644
--- a/arch/x86/lib/acpi_table.c
+++ b/arch/x86/lib/acpi_table.c
@@ -382,12 +382,6 @@ u32 write_acpi_tables(u32 start)
(char *) + sizeof(struct acpi_table_header),
dsdt->length - sizeof(struct acpi_table_header));
current += dsdt->length - sizeof(struct acpi_table_header);
-
-   /* (Re)calculate length and checksum */
-   dsdt->length = current - (u32)dsdt;
-   dsdt->checksum = 0;
-   dsdt->checksum = table_compute_checksum((void *)dsdt,
-   dsdt->length);
}
current = ALIGN(current, 16);
 
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 01/18] x86: minnowmax: Adjust U-Boot environment address in SPI flash

[Bin Meng]

Currently U-Boot environment address is at offset 0x7fe00 of a 8MB
SPI flash. When creating a partial u-boot.rom image without flash
descriptor and ME firmware, U-Boot actually occupies the last 1MB
of the flash, and reprograming U-Boot causes previous environment
settings get lost which is not convenient during testing.

Adjust the environment address to 0x6ef000 instead (before the MRC
cache data region in the flash).

Signed-off-by: Bin Meng 
Reviewed-by: Stefan Roese 
---

Changes in v2: None

 doc/README.x86  | 2 +-
 include/configs/minnowmax.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/README.x86 b/doc/README.x86
index ce806ee..25cb218 100644
--- a/doc/README.x86
+++ b/doc/README.x86
@@ -304,12 +304,12 @@ Offset   Description Controlling config
 00   descriptor.bin  Hard-coded to 0 in ifdtool
 001000   me.bin  Set by the descriptor
 50   
+6ef000   Environment CONFIG_ENV_OFFSET
 6f   MRC cache   CONFIG_ENABLE_MRC_CACHE
 70   u-boot-dtb.bin  CONFIG_SYS_TEXT_BASE
 79   vga.bin CONFIG_VGA_BIOS_ADDR
 7c   fsp.bin CONFIG_FSP_ADDR
 7f8000(depends on size of fsp.bin)
-7fe000   Environment CONFIG_ENV_OFFSET
 7ff800   U-Boot 16-bit boot  CONFIG_SYS_X86_START16
 
 Overall ROM image size is controlled by CONFIG_ROM_SIZE.
diff --git a/include/configs/minnowmax.h b/include/configs/minnowmax.h
index 674d1f6..95ad128 100644
--- a/include/configs/minnowmax.h
+++ b/include/configs/minnowmax.h
@@ -40,6 +40,6 @@
 #define CONFIG_X86EMU_RAW_IO
 
 #define CONFIG_ENV_SECT_SIZE   0x1000
-#define CONFIG_ENV_OFFSET  0x007fe000
+#define CONFIG_ENV_OFFSET  0x006ef000
 
 #endif /* __CONFIG_H */
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 00/18] x86: acpi: Support installation of Ubuntu/Windows and boot Windows

[Bin Meng]

SeaBIOS can be loaded by U-Boot to aid the installation of Ubuntu
and Windows to a SATA drive and boot from there. But till now this
is broken. The installation either hangs forever or just crashes.

This series fixed a bunch of issues that affect the installation
of Ubuntu and Windows, and booting Windows.

Testing was performed on MinnowMax by:
- Install Ubuntu 14.04 and boot
- Install Windows 8.1 and boot
- Install Windows 10 and boot

This series is available at u-boot-x86/acpi2-working.

Changes in v2:
- New patch to remove the unnecessary checksum calculation of DSDT
- New patch to remove header length check when writing tables
- New patch to enable SeaBIOS on all boards
- New patch to add GPIO ASL description

Bin Meng (18):
  x86: minnowmax: Adjust U-Boot environment address in SPI flash
  x86: Call board_final_cleanup() in last_stage_init()
  x86: Fix up PIRQ routing table checksum earlier
  x86: Compile coreboot_table.c only for SeaBIOS
  x86: Prepare configuration tables in dedicated high memory region
  x86: Unify reserve_arch() for all x86 boards
  x86: Reserve configuration tables in high memory
  x86: Use high_table_malloc() for tables passing to SeaBIOS
  x86: acpi: Switch to ACPI mode by ourselves instead of requested by
OSPM
  x86: acpi: Remove the unnecessary checksum calculation of DSDT
  x86: acpi: Remove header length check when writing tables
  x86: doc: Update information about IGD with SeaBIOS
  x86: baytrail: Enable SeaBIOS on all boards
  x86: doc: Mention Ubuntu/Windows installation and boot support
  acpi: Quieten IASL output when 'make -s' is used
  x86: baytrail: Add internal UART ASL description
  x86: baytrail: Add GPIO ASL description
  x86: doc: Add porting hints for ACPI with Windows

 arch/x86/Kconfig   | 14 
 arch/x86/cpu/baytrail/valleyview.c |  8 --
 arch/x86/cpu/broadwell/sdram.c |  5 --
 arch/x86/cpu/coreboot/coreboot.c   | 20 +++--
 arch/x86/cpu/cpu.c | 27 ++
 arch/x86/cpu/irq.c |  4 +
 arch/x86/cpu/ivybridge/sdram.c |  5 --
 arch/x86/cpu/quark/quark.c |  9 --
 arch/x86/include/asm/acpi_table.h  |  3 +
 arch/x86/include/asm/arch-baytrail/acpi/gpio.asl   | 95 ++
 .../include/asm/arch-baytrail/acpi/irqlinks.asl|  4 +
 arch/x86/include/asm/arch-baytrail/acpi/lpc.asl| 60 ++
 .../include/asm/arch-baytrail/acpi/platform.asl|  3 +
 arch/x86/include/asm/coreboot_tables.h | 19 +
 arch/x86/include/asm/global_data.h |  4 +
 arch/x86/lib/Makefile  |  2 +-
 arch/x86/lib/acpi_table.c  | 58 -
 arch/x86/lib/bootm.c   |  9 --
 arch/x86/lib/coreboot_table.c  | 31 +++
 arch/x86/lib/pirq_routing.c|  4 -
 arch/x86/lib/tables.c  |  4 +-
 configs/bayleybay_defconfig|  1 +
 configs/conga-qeval20-qa3-e3845_defconfig  |  1 +
 configs/minnowmax_defconfig|  1 +
 doc/README.x86 | 44 --
 include/configs/minnowmax.h|  2 +-
 scripts/Makefile.lib   |  2 +-
 27 files changed, 357 insertions(+), 82 deletions(-)
 create mode 100644 arch/x86/include/asm/arch-baytrail/acpi/gpio.asl

-- 
1.8.2.1

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

[U-Boot] [PATCH v2 02/18] x86: Call board_final_cleanup() in last_stage_init()

[Bin Meng]

At present board_final_cleanup() is called before booting a Linux
kernel. This actually needs to be done before booting anything,
like SeaBIOS, VxWorks or Windows.

Move the call to last_stage_init() instead.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 arch/x86/cpu/coreboot/coreboot.c | 20 +++-
 arch/x86/cpu/cpu.c   | 10 ++
 arch/x86/lib/bootm.c |  9 -
 3 files changed, 21 insertions(+), 18 deletions(-)

diff --git a/arch/x86/cpu/coreboot/coreboot.c b/arch/x86/cpu/coreboot/coreboot.c
index 845f86a..1b04203 100644
--- a/arch/x86/cpu/coreboot/coreboot.c
+++ b/arch/x86/cpu/coreboot/coreboot.c
@@ -39,15 +39,7 @@ int print_cpuinfo(void)
return default_print_cpuinfo();
 }
 
-int last_stage_init(void)
-{
-   if (gd->flags & GD_FLG_COLD_BOOT)
-   timestamp_add_to_bootstage();
-
-   return 0;
-}
-
-void board_final_cleanup(void)
+static void board_final_cleanup(void)
 {
/*
 * Un-cache the ROM so the kernel has one
@@ -79,6 +71,16 @@ void board_final_cleanup(void)
}
 }
 
+int last_stage_init(void)
+{
+   if (gd->flags & GD_FLG_COLD_BOOT)
+   timestamp_add_to_bootstage();
+
+   board_final_cleanup();
+
+   return 0;
+}
+
 int misc_init_r(void)
 {
return 0;
diff --git a/arch/x86/cpu/cpu.c b/arch/x86/cpu/cpu.c
index 233a6c8..1482153 100644
--- a/arch/x86/cpu/cpu.c
+++ b/arch/x86/cpu/cpu.c
@@ -661,10 +661,20 @@ void show_boot_progress(int val)
 }
 
 #ifndef CONFIG_SYS_COREBOOT
+/*
+ * Implement a weak default function for boards that optionally
+ * need to clean up the system before jumping to the kernel.
+ */
+__weak void board_final_cleanup(void)
+{
+}
+
 int last_stage_init(void)
 {
write_tables();
 
+   board_final_cleanup();
+
return 0;
 }
 #endif
diff --git a/arch/x86/lib/bootm.c b/arch/x86/lib/bootm.c
index 783be69..7cf9de4 100644
--- a/arch/x86/lib/bootm.c
+++ b/arch/x86/lib/bootm.c
@@ -26,14 +26,6 @@ DECLARE_GLOBAL_DATA_PTR;
 
 #define COMMAND_LINE_OFFSET 0x9000
 
-/*
- * Implement a weak default function for boards that optionally
- * need to clean up the system before jumping to the kernel.
- */
-__weak void board_final_cleanup(void)
-{
-}
-
 void bootm_announce_and_cleanup(void)
 {
printf("\nStarting kernel ...\n\n");
@@ -45,7 +37,6 @@ void bootm_announce_and_cleanup(void)
 #ifdef CONFIG_BOOTSTAGE_REPORT
bootstage_report();
 #endif
-   board_final_cleanup();
 }
 
 #if defined(CONFIG_OF_LIBFDT) && !defined(CONFIG_OF_NO_KERNEL)
-- 
1.8.2.1

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

[U-Boot] [PATCH v2 03/18] x86: Fix up PIRQ routing table checksum earlier

[Bin Meng]

PIRQ routing table checksum is fixed up in copy_pirq_routing_table(),
which is fine if we only write the configuration table once. But with
the SeaBIOS case, when we write the table for the second time, the
checksum will be fixed up to zero per the checksum algorithm, which
is caused by the checksum field not being zero before fix up, since
the checksum has already been calculated in the first run.

To fix this, move the checksum fixup to create_pirq_routing_table(),
so that copy_pirq_routing_table() only does what its function name
suggests: copy the table to somewhere else.

Signed-off-by: Bin Meng 
---

Changes in v2: None

 arch/x86/cpu/irq.c  | 4 
 arch/x86/lib/pirq_routing.c | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/cpu/irq.c b/arch/x86/cpu/irq.c
index 86183b0..df3cd0a 100644
--- a/arch/x86/cpu/irq.c
+++ b/arch/x86/cpu/irq.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -214,6 +215,9 @@ static int create_pirq_routing_table(struct udevice *dev)
 
rt->size = irq_entries * sizeof(struct irq_info) + 32;
 
+   /* Fix up the table checksum */
+   rt->checksum = table_compute_checksum(rt, rt->size);
+
pirq_routing_table = rt;
 
return 0;
diff --git a/arch/x86/lib/pirq_routing.c b/arch/x86/lib/pirq_routing.c
index 3cc6adb..a93d355 100644
--- a/arch/x86/lib/pirq_routing.c
+++ b/arch/x86/lib/pirq_routing.c
@@ -10,7 +10,6 @@
 #include 
 #include 
 #include 
-#include 
 
 static bool irq_already_routed[16];
 
@@ -111,9 +110,6 @@ u32 copy_pirq_routing_table(u32 addr, struct 
irq_routing_table *rt)
 {
struct irq_routing_table *rom_rt;
 
-   /* Fix up the table checksum */
-   rt->checksum = table_compute_checksum(rt, rt->size);
-
/* Align the table to be 16 byte aligned */
addr = ALIGN(addr, 16);
 
-- 
1.8.2.1

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

Re: [U-Boot] GPIO driver for Freescale QorIQ T2080

[Joakim Tjernlund]

On Wed, 2016-05-11 at 11:54 +0200, Mario Six wrote:
> On Tue, May 10, 2016 at 1:22 AM, Hamish Martin <
> hamish.mar...@alliedtelesis.co.nz> wrote:
> 
> > 
> > Hi,
> > 
> > I'm looking for uboot driver support for the Freescale QorIQ T2080 CPU.
> > This has 4 blocks of GPIOs similar to the single block defined in
> > arch/powerpc/include/asm/mpc85xx_gpio.h.
> > 
> > If someone is working on a driver for that CPU or similar, let me know.
> > Ideally this would fit the new driver model. I'd be happy to help test
> > it out and debug it.
> > 
> > Alternatively, if you know another way to drive those GPIO blocks with
> > existing code, feel free to suggest a way.
> > 
> > Cheers,
> > Hamish Martin.
> > 
> Hi Hamish,
> 
> I posted v2 of a patch series for a MPC85xx GPIO DM driver just yesterday;
> it was
> tested on a P1022, but it's quite likely that it will work with other
> QorIQs,
> too (it's basically arpc/powerpc/include/asm/mpc85xx_gpio.h turned into a
> proper DM driver).

I have not read you patch but I wanted to mention a defect in QorIO:
It cannot read back the DAT register, it always read the pin values.
This means one needs to hold the DAT register in a RAM copy or risk
malfunction when using open drain etc.

See GPIO for QorIO in the kernel for details.

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

Re: [U-Boot] [RFC PATCH] arm: socfpga: Update iomux and pll for c5 socdk RevE

[Chin Liang See]

On Tue, 2016-05-10 at 23:30 +0200, Marek Vasut wrote:
> On 05/10/2016 10:13 PM, dingu...@opensource.altera.com wrote:
> > From: Dinh Nguyen 
> > 
> > Update the pinmux and pll configuration for the Cyclone5 RevE or
> > later devkit.
> > 
> > Signed-off-by: Dinh Nguyen 
> > ---
> > Hi Marek,
> 
> Hi!
> 
> > Without these pinmux and pll changes, DS-5 is unable to connect to
> > my board
> > and Linux is stuck in a loop and eventually the watchdog will
> > trigger a
> > reset.
> > 
> > I tested these changes on an earlier rev board, and it seem to be
> > stable as
> > well. When you get a chance, can you try on your devkit?
> 
> Tested-by: Marek Vasut 
> 
> > > 

Acked-by: Chin Liang See 

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

Re: [U-Boot] [PATCH 06/10] usb: uniphier: remove UniPhier xHCI driver

[Marek Vasut]

On 05/11/2016 12:28 PM, Masahiro Yamada wrote:
> UniPhier platform switched to DWC3 core with UniPhier specific
> glue layer to support USB3.  This pre-DM driver is no longer
> needed.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Marek Vasut 

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 04/10] ARM: uniphier: switch over to USB DM

[Marek Vasut]

On 05/11/2016 12:28 PM, Masahiro Yamada wrote:

Please, do write commit messages.

> Signed-off-by: Masahiro Yamada 
> ---
> 
>  arch/arm/Kconfig   | 1 +
>  include/configs/uniphier.h | 4 
>  2 files changed, 5 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 6b65d8e..59410cb 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -723,6 +723,7 @@ config ARCH_UNIPHIER
>   select DM_SERIAL
>   select DM_I2C
>   select DM_MMC
> + select DM_USB
>   help
> Support for UniPhier SoC family developed by Socionext Inc.
> (formerly, System LSI Business Division of Panasonic Corporation)
> diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
> index 18cb963..868f001 100644
> --- a/include/configs/uniphier.h
> +++ b/include/configs/uniphier.h
> @@ -136,6 +136,10 @@
>  #define CONFIG_FAT_WRITE
>  #define CONFIG_DOS_PARTITION
>  
> +#ifdef CONFIG_USB_DWC3_UNIPHIER
> +#define CONFIG_USB_XHCI_DWC3

Could this be converted to Kconfig ?

> +#endif
> +
>  /* SD/MMC */
>  #define CONFIG_SUPPORT_EMMC_BOOT
>  #define CONFIG_GENERIC_MMC
> 


-- 
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 02/10] usb: dwc3: make DWC3 core support code into a driver

[Marek Vasut]

On 05/11/2016 12:28 PM, Masahiro Yamada wrote:
> Synopsys DWC3 IP generally works with an SoC-specific glue layer.
> DT binding for that is like this:
> 
>   usb3_glue {
>   compatible = "foo,dwc3";
>   ...
> 
>   usb3: usb3 {
>   compatible = "snps,dwc3";
>   ...
>   };
>   };
> 
> The glue layer initializes some SoC-specific parts, then populates
> the child DWC3 core.  To see how it works, refer to
> 
>   drivers/usb/dwc3/dwc3-exynos.c
>   drivers/usb/dwc3/dwc3-keystone.c
>   drivers/usb/dwc3/dwc3-omap.c
>   drivers/usb/dwc3/dwc3-st.c
> 
> of Linux Kernel.
> 
> This commit implements a driver for "snps,dwc3", which allows to use
> the same binding in U-Boot.  The glue layer can be simply implemented
> based on Simple Bus Uclass.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Marek Vasut 

> ---
> 
>  drivers/usb/host/xhci-dwc3.c | 71 
> +++-
>  1 file changed, 70 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
> index 33961cd..c7c8324 100644
> --- a/drivers/usb/host/xhci-dwc3.c
> +++ b/drivers/usb/host/xhci-dwc3.c
> @@ -9,8 +9,13 @@
>   */
>  
>  #include 
> -#include 
> +#include 
> +#include 
> +#include 
>  #include 
> +#include 
> +
> +#include "xhci.h"
>  
>  void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
>  {
> @@ -97,3 +102,67 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
>   setbits_le32(_reg->g_fladj, GFLADJ_30MHZ_REG_SEL |
>   GFLADJ_30MHZ(val));
>  }
> +
> +struct dwc3_priv {
> + struct xhci_ctrl ctrl;  /* should be the first member */
> + void __iomem *regs;
> +};
> +
> +static int dwc3_probe(struct udevice *dev)
> +{
> + struct dwc3_priv *priv = dev_get_priv(dev);
> + struct xhci_hccr *hccr;
> + struct xhci_hcor *hcor;
> + fdt_addr_t base;
> + int ret;
> +
> + base = dev_get_addr(dev);
> + if (base == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + priv->regs = map_sysmem(base, SZ_32K);
> + if (!priv->regs)
> + return -ENOMEM;
> +
> + hccr = priv->regs;
> +
> + hcor = priv->regs + HC_LENGTH(xhci_readl(>cr_capbase));
> +
> + ret = dwc3_core_init(priv->regs + DWC3_REG_OFFSET);
> + if (ret) {
> + puts("XHCI: failed to initialize controller\n");
> + return ret;
> + }
> +
> + /* We are hard-coding DWC3 core to Host Mode */
> + dwc3_set_mode(priv->regs + DWC3_REG_OFFSET, DWC3_GCTL_PRTCAP_HOST);
> +
> + return xhci_register(dev, hccr, hcor);
> +}
> +
> +static int dwc3_remove(struct udevice *dev)
> +{
> + struct dwc3_priv *priv = dev_get_priv(dev);
> +
> + xhci_deregister(dev);
> + unmap_sysmem(priv->regs);
> +
> + return 0;
> +}
> +
> +static const struct udevice_id of_dwc3_match[] = {
> + { .compatible = "snps,dwc3" },
> + { .compatible = "synopsys,dwc3" },
> + { /* sentinel */ }
> +};
> +
> +U_BOOT_DRIVER(dwc3) = {
> + .name = "dwc3",
> + .id = UCLASS_USB,
> + .of_match = of_dwc3_match,
> + .probe = dwc3_probe,
> + .remove = dwc3_remove,
> + .ops = _usb_ops,
> + .priv_auto_alloc_size = sizeof(struct dwc3_priv),
> + .flags  = DM_FLAG_ALLOC_PRIV_DMA,
> +};
> 


-- 
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 03/10] usb: dwc3: add UniPhier specific glue layer

[Marek Vasut]

On 05/11/2016 12:28 PM, Masahiro Yamada wrote:
> Add UniPhier platform specific glue layer to support USB3 Host mode
> on Synopsys DWC3 IP.
> 
> Signed-off-by: Masahiro Yamada 

Reviewed-by: Marek Vasut 

> ---
> 
>  drivers/usb/host/Kconfig |   7 +++
>  drivers/usb/host/Makefile|   1 +
>  drivers/usb/host/dwc3-uniphier.c | 110 
> +++
>  3 files changed, 118 insertions(+)
>  create mode 100644 drivers/usb/host/dwc3-uniphier.c
> 
> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
> index d2363c8..b9eb5ed 100644
> --- a/drivers/usb/host/Kconfig
> +++ b/drivers/usb/host/Kconfig
> @@ -24,6 +24,13 @@ config USB_XHCI_UNIPHIER
>   ---help---
> Enables support for the on-chip xHCI controller on UniPhier SoCs.
>  
> +config USB_DWC3_UNIPHIER
> + bool "DesignWare USB3 Host Support on UniPhier Platforms"
> + depends on ARCH_UNIPHIER
> + help
> +   Support of USB2/3 functionality in Socionext UniPhier platforms.
> +   Say 'Y' here if you have one such device.
> +
>  endif
>  
>  config USB_OHCI_GENERIC
> diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
> index 507519e..cc8b584 100644
> --- a/drivers/usb/host/Makefile
> +++ b/drivers/usb/host/Makefile
> @@ -56,6 +56,7 @@ obj-$(CONFIG_USB_EHCI_ZYNQ) += ehci-zynq.o
>  # xhci
>  obj-$(CONFIG_USB_XHCI) += xhci.o xhci-mem.o xhci-ring.o
>  obj-$(CONFIG_USB_XHCI_DWC3) += xhci-dwc3.o
> +obj-$(CONFIG_USB_DWC3_UNIPHIER) += dwc3-uniphier.o
>  obj-$(CONFIG_USB_XHCI_ZYNQMP) += xhci-zynqmp.o
>  obj-$(CONFIG_USB_XHCI_KEYSTONE) += xhci-keystone.o
>  obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
> diff --git a/drivers/usb/host/dwc3-uniphier.c 
> b/drivers/usb/host/dwc3-uniphier.c
> new file mode 100644
> index 000..0571c6e
> --- /dev/null
> +++ b/drivers/usb/host/dwc3-uniphier.c
> @@ -0,0 +1,110 @@
> +/*
> + * UniPhier Specific Glue Layer for DWC3
> + *
> + * Copyright (C) 2016 Socionext Inc.
> + *   Author: Masahiro Yamada 
> + *
> + * SPDX-License-Identifier:  GPL-2.0+
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define UNIPHIER_PRO4_DWC3_RESET 0x40
> +#define   UNIPHIER_PRO4_DWC3_RESET_XIOMMUBIT(5)
> +#define   UNIPHIER_PRO4_DWC3_RESET_XLINK BIT(4)
> +
> +#define UNIPHIER_PRO5_DWC3_RESET 0x00
> +#define   UNIPHIER_PRO5_DWC3_RESET_XLINK BIT(15)
> +#define   UNIPHIER_PRO5_DWC3_RESET_XIOMMUBIT(14)
> +
> +#define UNIPHIER_PXS2_DWC3_RESET 0x00
> +#define   UNIPHIER_PXS2_DWC3_RESET_XLINK BIT(15)
> +
> +static int uniphier_pro4_dwc3_init(void __iomem *regs)
> +{
> + u32 tmp;
> +
> + tmp = readl(regs + UNIPHIER_PRO4_DWC3_RESET);
> + tmp |= UNIPHIER_PRO4_DWC3_RESET_XIOMMU | UNIPHIER_PRO4_DWC3_RESET_XLINK;
> + writel(tmp, regs + UNIPHIER_PRO4_DWC3_RESET);
> +
> + return 0;
> +}
> +
> +static int uniphier_pro5_dwc3_init(void __iomem *regs)
> +{
> + u32 tmp;
> +
> + tmp = readl(regs + UNIPHIER_PRO5_DWC3_RESET);
> + tmp |= UNIPHIER_PRO5_DWC3_RESET_XLINK | UNIPHIER_PRO5_DWC3_RESET_XIOMMU;
> + writel(tmp, regs + UNIPHIER_PRO5_DWC3_RESET);

I like how the bits doing exactly the same thing are always placed
elsewhere :-)

> + return 0;
> +}
> +
> +
> +static int uniphier_pxs2_dwc3_init(void __iomem *regs)
> +{
> + u32 tmp;
> +
> + tmp = readl(regs + UNIPHIER_PXS2_DWC3_RESET);
> + tmp |= UNIPHIER_PXS2_DWC3_RESET_XLINK | UNIPHIER_PXS2_DWC3_RESET_XIOMMU;
> + writel(tmp, regs + UNIPHIER_PXS2_DWC3_RESET);
> +
> + return 0;
> +}
> +
> +static int uniphier_dwc3_probe(struct udevice *dev)
> +{
> + fdt_addr_t base;
> + void __iomem *regs;
> + int (*init)(void __iomem *regs);
> + int ret;
> +
> + base = dev_get_addr(dev);
> + if (base == FDT_ADDR_T_NONE)
> + return -EINVAL;
> +
> + regs = map_sysmem(base, SZ_32K);
> + if (!regs)
> + return -ENOMEM;
> +
> + init = (int (*)(void __iomem *regs))dev_get_driver_data(dev);
> + ret = init(regs);
> +
> + unmap_sysmem(regs);
> +
> + return 0;
> +}
> +
> +static const struct udevice_id uniphier_dwc3_match[] = {
> + {
> + .compatible = "socionext,uniphier-pro4-dwc3",
> + .data = (ulong)uniphier_pro4_dwc3_init,
> + },
> + {
> + .compatible = "socionext,uniphier-pro5-dwc3",
> + .data = (ulong)uniphier_pro5_dwc3_init,
> + },
> + {
> + .compatible = "socionext,uniphier-pxs2-dwc3",
> + .data = (ulong)uniphier_pxs2_dwc3_init,
> + },
> + {
> + .compatible = "socionext,uniphier-ld20-dwc3",
> + .data = (ulong)uniphier_pxs2_dwc3_init,
> + },
> + { /* sentinel */ }
> +};
> +
> +U_BOOT_DRIVER(usb_xhci) = {
> + .name   = "uniphier-dwc3",
> + .id = UCLASS_SIMPLE_BUS,
> + .of_match = uniphier_dwc3_match,
> + .probe = 

Re: [U-Boot] [PATCH] usb: xhci: add struct devrequest declaration

[Marek Vasut]

On 05/11/2016 01:03 PM, Masahiro Yamada wrote:
> Hi Marek,

Hi!

> 2016-05-07 1:40 GMT+09:00 Marek Vasut :
>> On 05/06/2016 01:31 PM, Masahiro Yamada wrote:
>>> Hi Marek,
>>
>> Hi!
>>
>>> 2016-05-06 19:50 GMT+09:00 Marek Vasut :
 On 05/06/2016 12:36 PM, Masahiro Yamada wrote:
> This should be declared for xhci_ctrl_tx() to avoid build error.

 Can you please include the build error in the commit message ?
 That is extremely useful.

> Signed-off-by: Masahiro Yamada 
> ---
>
>  drivers/usb/host/xhci.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 2afa386..16dd61a 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1252,6 +1252,8 @@ void xhci_acknowledge_event(struct xhci_ctrl *ctrl);
>  union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type 
> expected);
>  int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
>int length, void *buffer);
> +
> +struct devrequest;

 I don't think that's the right thing to do, since the structure
 devrequest is not defined anywhere in this file or the headers
 which are included in this file.

 Will this patch work for you instead? It includes usb.h , which
 defines the struct devrequest.
>>>
>>> Of course, works.
>>> But why?
>>
>> Because you want to have definition of every symbol you use in your
>> headers when you include that header. I am not a big fan of huge stack
>> of #include statements in a driver.
> 
> Agree.  That's why this patch is here.
> 
> See this patch.
> http://patchwork.ozlabs.org/patch/620989/
> 
> 
> xhci-dwc3.c needs to include xhci.h, but not usb.h
> because this driver just wants to register the xHCI controller.
> It need not know complicated USB protocol things in the first place.

In that case, shouldn't the xhci_register() be in xhci.h instead ?

> Your way adds #include  to xhci.h,
> so xhci-dwc3.c is compelled to include unnecessary usb.h
> 
> It means huge stack of includes you do not like, isn't it?

It does add possibly unused symbols to the namespace, yes.
I don't think I really mind this though, since the symbol
definition is available when I include xhci.h somewhere.

>>> xhci_ctrl_tx() only takes a pointer to struct devrequest.
>>>
>>> This header does not need to know
>>> the members of struct devrequest, or sizeof(struct devrequest).
>>>
>>> We need to teach it that devrequest is a structure.
>>> That's enough.
>>>
>>>
>>> This is a very common way to fix
>>> "warning: 'struct devrequest' declared inside parameter list" error.
>>>
>>> For example,
>>>
>>> head -25 include/linux/clk.h
>>> head -30 include/linux/pinctrl/pinctrl.h
>>>
>>> in Linux Kernel.
>>
>> Ha, I didn't know about that. Is that some new recommended practice or
>> is this a matter of taste ?
> 
> I guess neither of them.
> 
> I recommend this practice for any projects written in C
> for two reasons:
> 
> 
> [1] Avoid unneeded includes
>   This is explained above.
> 
> 
> [2] Scope control
> 
> We have a good example in Linux Kernel.
> 
> struct clk is defined in drivers/clk/clk.c
> 
> It means that no clock consumers/providers are allowed
> to have access to any members of struct clk directly.
> 
> (If you want to get access to such private members,
> it is a good charm you are doing wrong.)
> 
> So, include/linux/clk.h has just a declaration:
> 
> struct clk;
> 
> It can claim clk is a structure,
> but not expose its internal details.
> 
> When we implement APIs, it is a good practice to think about
> private/public members.

This is a good point about the clk API. OK, let's go with this approach.

>> CCing Tom and Simon, so I can get some more input on this. I cannot
>> decide either way myself.
>>
> 
> You can.   Just consult yourself as a software engineer.

No comment.

-- 
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 00/10] usb: dwc3: rework DWC3 and convert UniPhier xHCI driver to DM

[Masahiro Yamada]

2016-05-11 19:28 GMT+09:00 Masahiro Yamada :
>
>
>
> Masahiro Yamada (10):
>   usb: xhci: add struct devrequest declaration to xhci.h
>   usb: dwc3: make DWC3 core support code into a driver
>   usb: dwc3: add UniPhier specific glue layer
>   ARM: uniphier: switch over to USB DM
>   ARM: uniphier: enable DWC3 xHCI driver
>   usb: uniphier: remove UniPhier xHCI driver
>   ARM: uniphier: delete unnecessary xHCI pin-mux settings
>   ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG
>   ARM: dts: uniphier: add/update xHCI nodes
>   ARM: uniphier: enable Generic EHCI for PH1-Pro4
>


I included 01 because this is a prerequisite for 02.

I delegated 01-06 to Marek
and 07-10 (follow-up cleanups) to me.


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

Re: [U-Boot] [PATCH 01/10] usb: xhci: add struct devrequest declaration to xhci.h

[Marek Vasut]

On 05/11/2016 12:28 PM, Masahiro Yamada wrote:
> If xhci.h is included without include/usb.h, the compiler
> complains like follows:
> warning: 'struct devrequest' declared inside parameter list
> 
> Teach the compiler that devrequest is a structure.
> I found no reason include include/usb.h from xhci.h.

I still don't like the fact that you would now have to include usb.h in
each driver instead of including it in xhci.h once.

> Signed-off-by: Masahiro Yamada 
> ---
> 
>  drivers/usb/host/xhci.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
> index 2afa386..16dd61a 100644
> --- a/drivers/usb/host/xhci.h
> +++ b/drivers/usb/host/xhci.h
> @@ -1252,6 +1252,8 @@ void xhci_acknowledge_event(struct xhci_ctrl *ctrl);
>  union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type 
> expected);
>  int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
>int length, void *buffer);
> +
> +struct devrequest;
>  int xhci_ctrl_tx(struct usb_device *udev, unsigned long pipe,
>struct devrequest *req, int length, void *buffer);
>  int xhci_check_maxpacket(struct usb_device *udev);
> 


-- 
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] usb: xhci: add struct devrequest declaration

[Masahiro Yamada]

Hi Marek,


2016-05-07 1:40 GMT+09:00 Marek Vasut :
> On 05/06/2016 01:31 PM, Masahiro Yamada wrote:
>> Hi Marek,
>
> Hi!
>
>> 2016-05-06 19:50 GMT+09:00 Marek Vasut :
>>> On 05/06/2016 12:36 PM, Masahiro Yamada wrote:
 This should be declared for xhci_ctrl_tx() to avoid build error.
>>>
>>> Can you please include the build error in the commit message ?
>>> That is extremely useful.
>>>
 Signed-off-by: Masahiro Yamada 
 ---

  drivers/usb/host/xhci.h | 2 ++
  1 file changed, 2 insertions(+)

 diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
 index 2afa386..16dd61a 100644
 --- a/drivers/usb/host/xhci.h
 +++ b/drivers/usb/host/xhci.h
 @@ -1252,6 +1252,8 @@ void xhci_acknowledge_event(struct xhci_ctrl *ctrl);
  union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type 
 expected);
  int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
int length, void *buffer);
 +
 +struct devrequest;
>>>
>>> I don't think that's the right thing to do, since the structure
>>> devrequest is not defined anywhere in this file or the headers
>>> which are included in this file.
>>>
>>> Will this patch work for you instead? It includes usb.h , which
>>> defines the struct devrequest.
>>
>> Of course, works.
>> But why?
>
> Because you want to have definition of every symbol you use in your
> headers when you include that header. I am not a big fan of huge stack
> of #include statements in a driver.

Agree.  That's why this patch is here.

See this patch.
http://patchwork.ozlabs.org/patch/620989/


xhci-dwc3.c needs to include xhci.h, but not usb.h
because this driver just wants to register the xHCI controller.
It need not know complicated USB protocol things in the first place.

Your way adds #include  to xhci.h,
so xhci-dwc3.c is compelled to include unnecessary usb.h

It means huge stack of includes you do not like, isn't it?



>> xhci_ctrl_tx() only takes a pointer to struct devrequest.
>>
>> This header does not need to know
>> the members of struct devrequest, or sizeof(struct devrequest).
>>
>> We need to teach it that devrequest is a structure.
>> That's enough.
>>
>>
>> This is a very common way to fix
>> "warning: 'struct devrequest' declared inside parameter list" error.
>>
>> For example,
>>
>> head -25 include/linux/clk.h
>> head -30 include/linux/pinctrl/pinctrl.h
>>
>> in Linux Kernel.
>
> Ha, I didn't know about that. Is that some new recommended practice or
> is this a matter of taste ?

I guess neither of them.

I recommend this practice for any projects written in C
for two reasons:


[1] Avoid unneeded includes
  This is explained above.


[2] Scope control

We have a good example in Linux Kernel.

struct clk is defined in drivers/clk/clk.c

It means that no clock consumers/providers are allowed
to have access to any members of struct clk directly.

(If you want to get access to such private members,
it is a good charm you are doing wrong.)

So, include/linux/clk.h has just a declaration:

struct clk;

It can claim clk is a structure,
but not expose its internal details.

When we implement APIs, it is a good practice to think about
private/public members.





> CCing Tom and Simon, so I can get some more input on this. I cannot
> decide either way myself.
>

You can.   Just consult yourself as a software engineer.



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

[U-Boot] [PATCH 06/10] usb: uniphier: remove UniPhier xHCI driver

[Masahiro Yamada]

UniPhier platform switched to DWC3 core with UniPhier specific
glue layer to support USB3.  This pre-DM driver is no longer
needed.

Signed-off-by: Masahiro Yamada 
---

 drivers/usb/host/Kconfig |  7 
 drivers/usb/host/Makefile|  1 -
 drivers/usb/host/xhci-uniphier.c | 85 
 include/fdtdec.h |  1 -
 lib/fdtdec.c |  1 -
 5 files changed, 95 deletions(-)
 delete mode 100644 drivers/usb/host/xhci-uniphier.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index b9eb5ed..c0d85c8 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -17,13 +17,6 @@ config USB_XHCI
 
 if USB_XHCI_HCD
 
-config USB_XHCI_UNIPHIER
-   bool "Support for UniPhier on-chip xHCI USB controller"
-   depends on ARCH_UNIPHIER
-   default y
-   ---help---
- Enables support for the on-chip xHCI controller on UniPhier SoCs.
-
 config USB_DWC3_UNIPHIER
bool "DesignWare USB3 Host Support on UniPhier Platforms"
depends on ARCH_UNIPHIER
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index cc8b584..ff987f6 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -63,7 +63,6 @@ obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
 obj-$(CONFIG_USB_XHCI_FSL) += xhci-fsl.o
 obj-$(CONFIG_USB_XHCI_OMAP) += xhci-omap.o
 obj-$(CONFIG_USB_XHCI_PCI) += xhci-pci.o
-obj-$(CONFIG_USB_XHCI_UNIPHIER) += xhci-uniphier.o
 
 # designware
 obj-$(CONFIG_USB_DWC2) += dwc2.o
diff --git a/drivers/usb/host/xhci-uniphier.c b/drivers/usb/host/xhci-uniphier.c
deleted file mode 100644
index 1b3f3d2..000
--- a/drivers/usb/host/xhci-uniphier.c
+++ /dev/null
@@ -1,85 +0,0 @@
-/*
- * Copyright (C) 2015 Masahiro Yamada 
- *
- * SPDX-License-Identifier:GPL-2.0+
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include "xhci.h"
-
-static int get_uniphier_xhci_base(int index, struct xhci_hccr **base)
-{
-   DECLARE_GLOBAL_DATA_PTR;
-   int node_list[2];
-   fdt_addr_t addr;
-   int count;
-
-   count = fdtdec_find_aliases_for_id(gd->fdt_blob, "usb",
-  COMPAT_SOCIONEXT_XHCI, node_list,
-  ARRAY_SIZE(node_list));
-
-   if (index >= count)
-   return -ENODEV;
-
-   addr = fdtdec_get_addr(gd->fdt_blob, node_list[index], "reg");
-   if (addr == FDT_ADDR_T_NONE)
-   return -ENODEV;
-
-   *base = (struct xhci_hccr *)addr;
-
-   return 0;
-}
-
-#define USB3_RST_CTRL  0x00100040
-#define IOMMU_RST_N(1 << 5)
-#define LINK_RST_N (1 << 4)
-
-static void uniphier_xhci_reset(void __iomem *base, int on)
-{
-   u32 tmp;
-
-   tmp = readl(base + USB3_RST_CTRL);
-
-   if (on)
-   tmp &= ~(IOMMU_RST_N | LINK_RST_N);
-   else
-   tmp |= IOMMU_RST_N | LINK_RST_N;
-
-   writel(tmp, base + USB3_RST_CTRL);
-}
-
-int xhci_hcd_init(int index, struct xhci_hccr **hccr, struct xhci_hcor **hcor)
-{
-   int ret;
-   struct xhci_hccr *cr;
-   struct xhci_hcor *or;
-
-   ret = get_uniphier_xhci_base(index, );
-   if (ret < 0)
-   return ret;
-
-   uniphier_xhci_reset(cr, 0);
-
-   or = (void *)cr + HC_LENGTH(xhci_readl(>cr_capbase));
-
-   *hccr = cr;
-   *hcor = or;
-
-   return 0;
-}
-
-void xhci_hcd_stop(int index)
-{
-   int ret;
-   struct xhci_hccr *cr;
-
-   ret = get_uniphier_xhci_base(index, );
-   if (ret < 0)
-   return;
-
-   uniphier_xhci_reset(cr, 1);
-}
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 37d482a..d1fddaa 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -158,7 +158,6 @@ enum fdt_compat_id {
COMPAT_AMS_AS3722,  /* AMS AS3722 PMIC */
COMPAT_INTEL_ICH_SPI,   /* Intel ICH7/9 SPI controller */
COMPAT_INTEL_QRK_MRC,   /* Intel Quark MRC */
-   COMPAT_SOCIONEXT_XHCI,  /* Socionext UniPhier xHCI */
COMPAT_INTEL_PCH,   /* Intel PCH */
COMPAT_ALTERA_SOCFPGA_DWMAC,/* SoCFPGA Ethernet controller */
COMPAT_ALTERA_SOCFPGA_DWMMC,/* SoCFPGA DWMMC controller */
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 70acc29..e316cc8 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -63,7 +63,6 @@ static const char * const compat_names[COMPAT_COUNT] = {
COMPAT(AMS_AS3722, "ams,as3722"),
COMPAT(INTEL_ICH_SPI, "intel,ich-spi"),
COMPAT(INTEL_QRK_MRC, "intel,quark-mrc"),
-   COMPAT(SOCIONEXT_XHCI, "socionext,uniphier-xhci"),
COMPAT(COMPAT_INTEL_PCH, "intel,bd82x6x"),
COMPAT(ALTERA_SOCFPGA_DWMAC, "altr,socfpga-stmmac"),
COMPAT(ALTERA_SOCFPGA_DWMMC, "altr,socfpga-dw-mshc"),
-- 
1.9.1

___
U-Boot mailing list

[U-Boot] [PATCH 09/10] ARM: dts: uniphier: add/update xHCI nodes

[Masahiro Yamada]

Adjust xHCI nodes to use the DWC3 core and the SoC-specific glue
layer for former SoCs.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/dts/uniphier-ph1-ld20.dtsi| 17 +
 arch/arm/dts/uniphier-ph1-pro4-ref.dts |  4 
 arch/arm/dts/uniphier-ph1-pro4.dtsi| 32 
 arch/arm/dts/uniphier-ph1-pro5.dtsi| 32 
 arch/arm/dts/uniphier-proxstream2.dtsi | 32 
 5 files changed, 93 insertions(+), 24 deletions(-)

diff --git a/arch/arm/dts/uniphier-ph1-ld20.dtsi 
b/arch/arm/dts/uniphier-ph1-ld20.dtsi
index f9cc3c4..5e2b595 100644
--- a/arch/arm/dts/uniphier-ph1-ld20.dtsi
+++ b/arch/arm/dts/uniphier-ph1-ld20.dtsi
@@ -256,6 +256,23 @@
#interrupt-cells = <3>;
interrupts = <1 9 4>;
};
+
+   usb: usb@65b0 {
+   compatible = "socionext,uniphier-ld20-dwc3";
+   reg = <0x65b0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   pinctrl-names = "default";
+   pinctrl-0 = <_usb0>, <_usb1>,
+   <_usb2>, <_usb3>;
+   dwc3@65a0 {
+   compatible = "snps,dwc3";
+   reg = <0x65a0 0x1>;
+   interrupts = <0 134 4>;
+   tx-fifo-resize;
+   };
+   };
};
 };
 
diff --git a/arch/arm/dts/uniphier-ph1-pro4-ref.dts 
b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
index 5be76e2..6cc5d1e 100644
--- a/arch/arm/dts/uniphier-ph1-pro4-ref.dts
+++ b/arch/arm/dts/uniphier-ph1-pro4-ref.dts
@@ -71,6 +71,10 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/dts/uniphier-ph1-pro4.dtsi 
b/arch/arm/dts/uniphier-ph1-pro4.dtsi
index d5767b6..7f42bc2 100644
--- a/arch/arm/dts/uniphier-ph1-pro4.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro4.dtsi
@@ -400,22 +400,38 @@
clocks = < 4>, < 6>;
};
 
-   usb0: usb@65a0 {
-   compatible = "socionext,uniphier-xhci", "generic-xhci";
+   usb0: usb@65b0 {
+   compatible = "socionext,uniphier-pro4-dwc3";
status = "disabled";
-   reg = <0x65a0 0x100>;
-   interrupts = <0 134 4>;
+   reg = <0x65b0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
pinctrl-names = "default";
pinctrl-0 = <_usb0>;
+   dwc3@65a0 {
+   compatible = "snps,dwc3";
+   reg = <0x65a0 0x1>;
+   interrupts = <0 134 4>;
+   tx-fifo-resize;
+   };
};
 
-   usb1: usb@65c0 {
-   compatible = "socionext,uniphier-xhci", "generic-xhci";
+   usb1: usb@65d0 {
+   compatible = "socionext,uniphier-pro4-dwc3";
status = "disabled";
-   reg = <0x65c0 0x100>;
-   interrupts = <0 137 4>;
+   reg = <0x65d0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
pinctrl-names = "default";
pinctrl-0 = <_usb1>;
+   dwc3@65c0 {
+   compatible = "snps,dwc3";
+   reg = <0x65c0 0x1>;
+   interrupts = <0 137 4>;
+   tx-fifo-resize;
+   };
};
 };
 
diff --git a/arch/arm/dts/uniphier-ph1-pro5.dtsi 
b/arch/arm/dts/uniphier-ph1-pro5.dtsi
index bd1b4b1..3036a76 100644
--- a/arch/arm/dts/uniphier-ph1-pro5.dtsi
+++ b/arch/arm/dts/uniphier-ph1-pro5.dtsi
@@ -379,22 +379,38 @@
bus-width = <4>;
};
 
-   usb0: usb@65a0 {
-   compatible = "socionext,uniphier-xhci", "generic-xhci";
+   usb0: usb@65b0 {
+   compatible = "socionext,uniphier-pro5-dwc3";
status = "disabled";
-   reg = <0x65a0 0x100>;
-   interrupts = <0 134 4>;
+   reg = <0x65b0 0x1000>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
pinctrl-names = "default";
pinctrl-0 = <_usb0>;
+   dwc3@65a0 {
+   compatible = "snps,dwc3";
+   reg = <0x65a0 0x1>;
+   interrupts = <0 134 4>;
+   tx-fifo-resize;
+   };
};
 
-   usb1: usb@65c0 {
-   compatible = "socionext,uniphier-xhci", "generic-xhci";
+   

[U-Boot] [PATCH 03/10] usb: dwc3: add UniPhier specific glue layer

[Masahiro Yamada]

Add UniPhier platform specific glue layer to support USB3 Host mode
on Synopsys DWC3 IP.

Signed-off-by: Masahiro Yamada 
---

 drivers/usb/host/Kconfig |   7 +++
 drivers/usb/host/Makefile|   1 +
 drivers/usb/host/dwc3-uniphier.c | 110 +++
 3 files changed, 118 insertions(+)
 create mode 100644 drivers/usb/host/dwc3-uniphier.c

diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index d2363c8..b9eb5ed 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -24,6 +24,13 @@ config USB_XHCI_UNIPHIER
---help---
  Enables support for the on-chip xHCI controller on UniPhier SoCs.
 
+config USB_DWC3_UNIPHIER
+   bool "DesignWare USB3 Host Support on UniPhier Platforms"
+   depends on ARCH_UNIPHIER
+   help
+ Support of USB2/3 functionality in Socionext UniPhier platforms.
+ Say 'Y' here if you have one such device.
+
 endif
 
 config USB_OHCI_GENERIC
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 507519e..cc8b584 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_USB_EHCI_ZYNQ) += ehci-zynq.o
 # xhci
 obj-$(CONFIG_USB_XHCI) += xhci.o xhci-mem.o xhci-ring.o
 obj-$(CONFIG_USB_XHCI_DWC3) += xhci-dwc3.o
+obj-$(CONFIG_USB_DWC3_UNIPHIER) += dwc3-uniphier.o
 obj-$(CONFIG_USB_XHCI_ZYNQMP) += xhci-zynqmp.o
 obj-$(CONFIG_USB_XHCI_KEYSTONE) += xhci-keystone.o
 obj-$(CONFIG_USB_XHCI_EXYNOS) += xhci-exynos5.o
diff --git a/drivers/usb/host/dwc3-uniphier.c b/drivers/usb/host/dwc3-uniphier.c
new file mode 100644
index 000..0571c6e
--- /dev/null
+++ b/drivers/usb/host/dwc3-uniphier.c
@@ -0,0 +1,110 @@
+/*
+ * UniPhier Specific Glue Layer for DWC3
+ *
+ * Copyright (C) 2016 Socionext Inc.
+ *   Author: Masahiro Yamada 
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define UNIPHIER_PRO4_DWC3_RESET   0x40
+#define   UNIPHIER_PRO4_DWC3_RESET_XIOMMU  BIT(5)
+#define   UNIPHIER_PRO4_DWC3_RESET_XLINK   BIT(4)
+
+#define UNIPHIER_PRO5_DWC3_RESET   0x00
+#define   UNIPHIER_PRO5_DWC3_RESET_XLINK   BIT(15)
+#define   UNIPHIER_PRO5_DWC3_RESET_XIOMMU  BIT(14)
+
+#define UNIPHIER_PXS2_DWC3_RESET   0x00
+#define   UNIPHIER_PXS2_DWC3_RESET_XLINK   BIT(15)
+
+static int uniphier_pro4_dwc3_init(void __iomem *regs)
+{
+   u32 tmp;
+
+   tmp = readl(regs + UNIPHIER_PRO4_DWC3_RESET);
+   tmp |= UNIPHIER_PRO4_DWC3_RESET_XIOMMU | UNIPHIER_PRO4_DWC3_RESET_XLINK;
+   writel(tmp, regs + UNIPHIER_PRO4_DWC3_RESET);
+
+   return 0;
+}
+
+static int uniphier_pro5_dwc3_init(void __iomem *regs)
+{
+   u32 tmp;
+
+   tmp = readl(regs + UNIPHIER_PRO5_DWC3_RESET);
+   tmp |= UNIPHIER_PRO5_DWC3_RESET_XLINK | UNIPHIER_PRO5_DWC3_RESET_XIOMMU;
+   writel(tmp, regs + UNIPHIER_PRO5_DWC3_RESET);
+
+   return 0;
+}
+
+
+static int uniphier_pxs2_dwc3_init(void __iomem *regs)
+{
+   u32 tmp;
+
+   tmp = readl(regs + UNIPHIER_PXS2_DWC3_RESET);
+   tmp |= UNIPHIER_PXS2_DWC3_RESET_XLINK | UNIPHIER_PXS2_DWC3_RESET_XIOMMU;
+   writel(tmp, regs + UNIPHIER_PXS2_DWC3_RESET);
+
+   return 0;
+}
+
+static int uniphier_dwc3_probe(struct udevice *dev)
+{
+   fdt_addr_t base;
+   void __iomem *regs;
+   int (*init)(void __iomem *regs);
+   int ret;
+
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   regs = map_sysmem(base, SZ_32K);
+   if (!regs)
+   return -ENOMEM;
+
+   init = (int (*)(void __iomem *regs))dev_get_driver_data(dev);
+   ret = init(regs);
+
+   unmap_sysmem(regs);
+
+   return 0;
+}
+
+static const struct udevice_id uniphier_dwc3_match[] = {
+   {
+   .compatible = "socionext,uniphier-pro4-dwc3",
+   .data = (ulong)uniphier_pro4_dwc3_init,
+   },
+   {
+   .compatible = "socionext,uniphier-pro5-dwc3",
+   .data = (ulong)uniphier_pro5_dwc3_init,
+   },
+   {
+   .compatible = "socionext,uniphier-pxs2-dwc3",
+   .data = (ulong)uniphier_pxs2_dwc3_init,
+   },
+   {
+   .compatible = "socionext,uniphier-ld20-dwc3",
+   .data = (ulong)uniphier_pxs2_dwc3_init,
+   },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(usb_xhci) = {
+   .name   = "uniphier-dwc3",
+   .id = UCLASS_SIMPLE_BUS,
+   .of_match = uniphier_dwc3_match,
+   .probe = uniphier_dwc3_probe,
+};
-- 
1.9.1

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

[U-Boot] [PATCH 02/10] usb: dwc3: make DWC3 core support code into a driver

[Masahiro Yamada]

Synopsys DWC3 IP generally works with an SoC-specific glue layer.
DT binding for that is like this:

  usb3_glue {
  compatible = "foo,dwc3";
  ...

  usb3: usb3 {
  compatible = "snps,dwc3";
  ...
  };
  };

The glue layer initializes some SoC-specific parts, then populates
the child DWC3 core.  To see how it works, refer to

  drivers/usb/dwc3/dwc3-exynos.c
  drivers/usb/dwc3/dwc3-keystone.c
  drivers/usb/dwc3/dwc3-omap.c
  drivers/usb/dwc3/dwc3-st.c

of Linux Kernel.

This commit implements a driver for "snps,dwc3", which allows to use
the same binding in U-Boot.  The glue layer can be simply implemented
based on Simple Bus Uclass.

Signed-off-by: Masahiro Yamada 
---

 drivers/usb/host/xhci-dwc3.c | 71 +++-
 1 file changed, 70 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/host/xhci-dwc3.c b/drivers/usb/host/xhci-dwc3.c
index 33961cd..c7c8324 100644
--- a/drivers/usb/host/xhci-dwc3.c
+++ b/drivers/usb/host/xhci-dwc3.c
@@ -9,8 +9,13 @@
  */
 
 #include 
-#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+
+#include "xhci.h"
 
 void dwc3_set_mode(struct dwc3 *dwc3_reg, u32 mode)
 {
@@ -97,3 +102,67 @@ void dwc3_set_fladj(struct dwc3 *dwc3_reg, u32 val)
setbits_le32(_reg->g_fladj, GFLADJ_30MHZ_REG_SEL |
GFLADJ_30MHZ(val));
 }
+
+struct dwc3_priv {
+   struct xhci_ctrl ctrl;  /* should be the first member */
+   void __iomem *regs;
+};
+
+static int dwc3_probe(struct udevice *dev)
+{
+   struct dwc3_priv *priv = dev_get_priv(dev);
+   struct xhci_hccr *hccr;
+   struct xhci_hcor *hcor;
+   fdt_addr_t base;
+   int ret;
+
+   base = dev_get_addr(dev);
+   if (base == FDT_ADDR_T_NONE)
+   return -EINVAL;
+
+   priv->regs = map_sysmem(base, SZ_32K);
+   if (!priv->regs)
+   return -ENOMEM;
+
+   hccr = priv->regs;
+
+   hcor = priv->regs + HC_LENGTH(xhci_readl(>cr_capbase));
+
+   ret = dwc3_core_init(priv->regs + DWC3_REG_OFFSET);
+   if (ret) {
+   puts("XHCI: failed to initialize controller\n");
+   return ret;
+   }
+
+   /* We are hard-coding DWC3 core to Host Mode */
+   dwc3_set_mode(priv->regs + DWC3_REG_OFFSET, DWC3_GCTL_PRTCAP_HOST);
+
+   return xhci_register(dev, hccr, hcor);
+}
+
+static int dwc3_remove(struct udevice *dev)
+{
+   struct dwc3_priv *priv = dev_get_priv(dev);
+
+   xhci_deregister(dev);
+   unmap_sysmem(priv->regs);
+
+   return 0;
+}
+
+static const struct udevice_id of_dwc3_match[] = {
+   { .compatible = "snps,dwc3" },
+   { .compatible = "synopsys,dwc3" },
+   { /* sentinel */ }
+};
+
+U_BOOT_DRIVER(dwc3) = {
+   .name = "dwc3",
+   .id = UCLASS_USB,
+   .of_match = of_dwc3_match,
+   .probe = dwc3_probe,
+   .remove = dwc3_remove,
+   .ops = _usb_ops,
+   .priv_auto_alloc_size = sizeof(struct dwc3_priv),
+   .flags  = DM_FLAG_ALLOC_PRIV_DMA,
+};
-- 
1.9.1

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

[U-Boot] [PATCH 00/10] usb: dwc3: rework DWC3 and convert UniPhier xHCI driver to DM

[Masahiro Yamada]

Masahiro Yamada (10):
  usb: xhci: add struct devrequest declaration to xhci.h
  usb: dwc3: make DWC3 core support code into a driver
  usb: dwc3: add UniPhier specific glue layer
  ARM: uniphier: switch over to USB DM
  ARM: uniphier: enable DWC3 xHCI driver
  usb: uniphier: remove UniPhier xHCI driver
  ARM: uniphier: delete unnecessary xHCI pin-mux settings
  ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG
  ARM: dts: uniphier: add/update xHCI nodes
  ARM: uniphier: enable Generic EHCI for PH1-Pro4

 arch/arm/Kconfig  |   1 +
 arch/arm/dts/uniphier-ph1-ld20.dtsi   |  17 
 arch/arm/dts/uniphier-ph1-pro4-ref.dts|   4 +
 arch/arm/dts/uniphier-ph1-pro4.dtsi   |  32 ++--
 arch/arm/dts/uniphier-ph1-pro5.dtsi   |  32 ++--
 arch/arm/dts/uniphier-proxstream2.dtsi|  32 ++--
 arch/arm/mach-uniphier/clk/clk-pro4.c |   6 +-
 arch/arm/mach-uniphier/clk/clk-pro5.c |   6 +-
 arch/arm/mach-uniphier/clk/clk-pxs2.c |   6 +-
 arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c |  12 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c |  11 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c |   7 --
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c |   7 --
 arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c |  11 ---
 configs/uniphier_ld20_defconfig   |   1 +
 configs/uniphier_pro4_defconfig   |   3 +
 configs/uniphier_pxs2_ld6b_defconfig  |   1 +
 drivers/usb/host/Kconfig  |  10 +--
 drivers/usb/host/Makefile |   2 +-
 drivers/usb/host/dwc3-uniphier.c  | 110 ++
 drivers/usb/host/xhci-dwc3.c  |  71 -
 drivers/usb/host/xhci-uniphier.c  |  85 
 drivers/usb/host/xhci.h   |   2 +
 include/configs/uniphier.h|   4 +
 include/fdtdec.h  |   1 -
 lib/fdtdec.c  |   1 -
 26 files changed, 300 insertions(+), 175 deletions(-)
 create mode 100644 drivers/usb/host/dwc3-uniphier.c
 delete mode 100644 drivers/usb/host/xhci-uniphier.c

-- 
1.9.1

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

[U-Boot] [PATCH 10/10] ARM: uniphier: enable Generic EHCI for PH1-Pro4

[Masahiro Yamada]

On Driver Model USB, EHCI and xHCI can be enabled at the same time.
PH1-Pro4 SoC has two EHCI cores and two xHCI cores, so enable the
Generic EHCI driver.

Signed-off-by: Masahiro Yamada 
---

 configs/uniphier_pro4_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig
index ab7b3f4..c50e403 100644
--- a/configs/uniphier_pro4_defconfig
+++ b/configs/uniphier_pro4_defconfig
@@ -32,4 +32,6 @@ CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
 CONFIG_USB_DWC3_UNIPHIER=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_GENERIC=y
 CONFIG_USB_STORAGE=y
-- 
1.9.1

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

[U-Boot] [PATCH 05/10] ARM: uniphier: enable DWC3 xHCI driver

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

 configs/uniphier_ld20_defconfig  | 1 +
 configs/uniphier_pro4_defconfig  | 1 +
 configs/uniphier_pxs2_ld6b_defconfig | 1 +
 3 files changed, 3 insertions(+)

diff --git a/configs/uniphier_ld20_defconfig b/configs/uniphier_ld20_defconfig
index cbc65dd..f340681 100644
--- a/configs/uniphier_ld20_defconfig
+++ b/configs/uniphier_ld20_defconfig
@@ -27,4 +27,5 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_DWC3_UNIPHIER=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/uniphier_pro4_defconfig b/configs/uniphier_pro4_defconfig
index 18f4caf..ab7b3f4 100644
--- a/configs/uniphier_pro4_defconfig
+++ b/configs/uniphier_pro4_defconfig
@@ -31,4 +31,5 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_DWC3_UNIPHIER=y
 CONFIG_USB_STORAGE=y
diff --git a/configs/uniphier_pxs2_ld6b_defconfig 
b/configs/uniphier_pxs2_ld6b_defconfig
index cf6d3e4..53cb5ce 100644
--- a/configs/uniphier_pxs2_ld6b_defconfig
+++ b/configs/uniphier_pxs2_ld6b_defconfig
@@ -32,4 +32,5 @@ CONFIG_SPL_PINCTRL=y
 CONFIG_UNIPHIER_SERIAL=y
 CONFIG_USB=y
 CONFIG_USB_XHCI_HCD=y
+CONFIG_USB_DWC3_UNIPHIER=y
 CONFIG_USB_STORAGE=y
-- 
1.9.1

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

[U-Boot] [PATCH 08/10] ARM: uniphier: adjust ifdefs for new UniPhier DWC3 CONFIG

[Masahiro Yamada]

Now USB 3.0 feature is enabled/disabled by CONFIG_USB_DWC3_UNIPHIER.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/clk/clk-pro4.c | 6 +++---
 arch/arm/mach-uniphier/clk/clk-pro5.c | 6 +++---
 arch/arm/mach-uniphier/clk/clk-pxs2.c | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/arm/mach-uniphier/clk/clk-pro4.c 
b/arch/arm/mach-uniphier/clk/clk-pro4.c
index 8746d7d..6a01543 100644
--- a/arch/arm/mach-uniphier/clk/clk-pro4.c
+++ b/arch/arm/mach-uniphier/clk/clk-pro4.c
@@ -15,7 +15,7 @@ void uniphier_pro4_clk_init(void)
 
/* deassert reset */
tmp = readl(SC_RSTCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_USB3C0 |
SC_RSTCTRL_NRST_GIO;
 #endif
@@ -31,7 +31,7 @@ void uniphier_pro4_clk_init(void)
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp = readl(SC_RSTCTRL2);
tmp |= SC_RSTCTRL2_NRST_USB3B1 | SC_RSTCTRL2_NRST_USB3C1;
writel(tmp, SC_RSTCTRL2);
@@ -40,7 +40,7 @@ void uniphier_pro4_clk_init(void)
 
/* provide clocks */
tmp = readl(SC_CLKCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
SC_CLKCTRL_CEN_GIO;
 #endif
diff --git a/arch/arm/mach-uniphier/clk/clk-pro5.c 
b/arch/arm/mach-uniphier/clk/clk-pro5.c
index 823bb06..dd86cad 100644
--- a/arch/arm/mach-uniphier/clk/clk-pro5.c
+++ b/arch/arm/mach-uniphier/clk/clk-pro5.c
@@ -15,7 +15,7 @@ void uniphier_pro5_clk_init(void)
 
/* deassert reset */
tmp = readl(SC_RSTCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_GIO;
 #endif
 #ifdef CONFIG_NAND_DENALI
@@ -24,7 +24,7 @@ void uniphier_pro5_clk_init(void)
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp = readl(SC_RSTCTRL2);
tmp |= SC_RSTCTRL2_NRST_USB3B1;
writel(tmp, SC_RSTCTRL2);
@@ -33,7 +33,7 @@ void uniphier_pro5_clk_init(void)
 
/* provide clocks */
tmp = readl(SC_CLKCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
SC_CLKCTRL_CEN_GIO;
 #endif
diff --git a/arch/arm/mach-uniphier/clk/clk-pxs2.c 
b/arch/arm/mach-uniphier/clk/clk-pxs2.c
index 76bf856..3b50a20 100644
--- a/arch/arm/mach-uniphier/clk/clk-pxs2.c
+++ b/arch/arm/mach-uniphier/clk/clk-pxs2.c
@@ -15,7 +15,7 @@ void uniphier_pxs2_clk_init(void)
 
/* deassert reset */
tmp = readl(SC_RSTCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_RSTCTRL_NRST_USB3B0 | SC_RSTCTRL_NRST_GIO;
 #endif
 #ifdef CONFIG_UNIPHIER_ETH
@@ -27,7 +27,7 @@ void uniphier_pxs2_clk_init(void)
writel(tmp, SC_RSTCTRL);
readl(SC_RSTCTRL); /* dummy read */
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp = readl(SC_RSTCTRL2);
tmp |= SC_RSTCTRL2_NRST_USB3B1;
writel(tmp, SC_RSTCTRL2);
@@ -36,7 +36,7 @@ void uniphier_pxs2_clk_init(void)
 
/* provide clocks */
tmp = readl(SC_CLKCTRL);
-#ifdef CONFIG_USB_XHCI_UNIPHIER
+#ifdef CONFIG_USB_DWC3_UNIPHIER
tmp |= SC_CLKCTRL_CEN_USB31 | SC_CLKCTRL_CEN_USB30 |
SC_CLKCTRL_CEN_GIO;
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH 01/10] usb: xhci: add struct devrequest declaration to xhci.h

[Masahiro Yamada]

If xhci.h is included without include/usb.h, the compiler
complains like follows:
warning: 'struct devrequest' declared inside parameter list

Teach the compiler that devrequest is a structure.
I found no reason include include/usb.h from xhci.h.

Signed-off-by: Masahiro Yamada 
---

 drivers/usb/host/xhci.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/usb/host/xhci.h b/drivers/usb/host/xhci.h
index 2afa386..16dd61a 100644
--- a/drivers/usb/host/xhci.h
+++ b/drivers/usb/host/xhci.h
@@ -1252,6 +1252,8 @@ void xhci_acknowledge_event(struct xhci_ctrl *ctrl);
 union xhci_trb *xhci_wait_for_event(struct xhci_ctrl *ctrl, trb_type expected);
 int xhci_bulk_tx(struct usb_device *udev, unsigned long pipe,
 int length, void *buffer);
+
+struct devrequest;
 int xhci_ctrl_tx(struct usb_device *udev, unsigned long pipe,
 struct devrequest *req, int length, void *buffer);
 int xhci_check_maxpacket(struct usb_device *udev);
-- 
1.9.1

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

[U-Boot] [PATCH 07/10] ARM: uniphier: delete unnecessary xHCI pin-mux settings

[Masahiro Yamada]

Now UniPhier platform switched over to the DM-based xHCI driver.
The pin-muxing for that is automatically cared by the pinctrl
driver.  These ad-hoc pin-muxing code is no longer needed.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c | 12 
 arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c | 11 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c |  7 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c |  7 ---
 arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c | 11 ---
 5 files changed, 48 deletions(-)

diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c
index 6066b16..0da280f 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld20.c
@@ -31,16 +31,4 @@ void uniphier_ld20_pin_init(void)
sg_set_pinsel(17, 0, 8, 4); /* NFD7-> NFD7 */
sg_set_iectrl_range(3, 17);
 #endif
-
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(46, 0, 8, 4); /* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(47, 0, 8, 4); /* USB0OD   -> USB0OD */
-   sg_set_pinsel(48, 0, 8, 4); /* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(49, 0, 8, 4); /* USB1OD   -> USB1OD */
-   sg_set_pinsel(50, 0, 8, 4); /* USB2VBUS -> USB2VBUS */
-   sg_set_pinsel(51, 0, 8, 4); /* USB2OD   -> USB2OD */
-   sg_set_pinsel(52, 0, 8, 4); /* USB3VBUS -> USB3VBUS */
-   sg_set_pinsel(53, 0, 8, 4); /* USB3OD   -> USB3OD */
-   sg_set_iectrl_range(46, 53);
-#endif
 }
diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c
index 913722b..f3b7115 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-ld6b.c
@@ -32,15 +32,4 @@ void uniphier_ld6b_pin_init(void)
sg_set_pinsel(45, 0, 8, 4); /* NFD6   -> NFD6 */
sg_set_pinsel(46, 0, 8, 4); /* NFD7   -> NFD7 */
 #endif
-
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(56, 0, 8, 4); /* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(57, 0, 8, 4); /* USB0OD   -> USB0OD */
-   sg_set_pinsel(58, 0, 8, 4); /* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(59, 0, 8, 4); /* USB1OD   -> USB1OD */
-   sg_set_pinsel(60, 0, 8, 4); /* USB2VBUS -> USB2VBUS */
-   sg_set_pinsel(61, 0, 8, 4); /* USB2OD   -> USB2OD */
-   sg_set_pinsel(62, 0, 8, 4); /* USB3VBUS -> USB3VBUS */
-   sg_set_pinsel(63, 0, 8, 4); /* USB3OD   -> USB3OD */
-#endif
 }
diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c
index 3796491..871d3ef 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro4.c
@@ -33,12 +33,5 @@ void uniphier_pro4_pin_init(void)
/* sg_set_pinsel(132, 1, 4, 8); */  /* TXD2   -> XNFCE1 */
 #endif
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(180, 0, 4, 8);/* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(181, 0, 4, 8);/* USB0OD   -> USB0OD */
-   sg_set_pinsel(182, 0, 4, 8);/* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(183, 0, 4, 8);/* USB1OD   -> USB1OD */
-#endif
-
writel(1, SG_LOADPINCTRL);
 }
diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c
index 32ba923..58dff18 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pro5.c
@@ -33,12 +33,5 @@ void uniphier_pro5_pin_init(void)
sg_set_pinsel(35, 0, 4, 8); /* NFD7   -> NFD7 */
 #endif
 
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(124, 0, 4, 8);/* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(125, 0, 4, 8);/* USB0OD   -> USB0OD */
-   sg_set_pinsel(126, 0, 4, 8);/* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(127, 0, 4, 8);/* USB1OD   -> USB1OD */
-#endif
-
writel(1, SG_LOADPINCTRL);
 }
diff --git a/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c 
b/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c
index 2d62ab3..fc59205 100644
--- a/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c
+++ b/arch/arm/mach-uniphier/pinctrl/pinctrl-pxs2.c
@@ -32,15 +32,4 @@ void uniphier_pxs2_pin_init(void)
sg_set_pinsel(45, 8, 8, 4); /* NFD6   -> NFD6 */
sg_set_pinsel(46, 8, 8, 4); /* NFD7   -> NFD7 */
 #endif
-
-#ifdef CONFIG_USB_XHCI_UNIPHIER
-   sg_set_pinsel(56, 8, 8, 4); /* USB0VBUS -> USB0VBUS */
-   sg_set_pinsel(57, 8, 8, 4); /* USB0OD   -> USB0OD */
-   sg_set_pinsel(58, 8, 8, 4); /* USB1VBUS -> USB1VBUS */
-   sg_set_pinsel(59, 8, 8, 4); /* USB1OD   -> USB1OD */
-   sg_set_pinsel(60, 8, 8, 4); /* USB2VBUS -> USB2VBUS */
-   sg_set_pinsel(61, 8, 8, 4); /* USB2OD   -> USB2OD */
-   sg_set_pinsel(62, 8, 8, 4); /* USB3VBUS -> USB3VBUS */
-   sg_set_pinsel(63, 8, 

[U-Boot] [PATCH 04/10] ARM: uniphier: switch over to USB DM

[Masahiro Yamada]

Signed-off-by: Masahiro Yamada 
---

 arch/arm/Kconfig   | 1 +
 include/configs/uniphier.h | 4 
 2 files changed, 5 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..59410cb 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -723,6 +723,7 @@ config ARCH_UNIPHIER
select DM_SERIAL
select DM_I2C
select DM_MMC
+   select DM_USB
help
  Support for UniPhier SoC family developed by Socionext Inc.
  (formerly, System LSI Business Division of Panasonic Corporation)
diff --git a/include/configs/uniphier.h b/include/configs/uniphier.h
index 18cb963..868f001 100644
--- a/include/configs/uniphier.h
+++ b/include/configs/uniphier.h
@@ -136,6 +136,10 @@
 #define CONFIG_FAT_WRITE
 #define CONFIG_DOS_PARTITION
 
+#ifdef CONFIG_USB_DWC3_UNIPHIER
+#define CONFIG_USB_XHCI_DWC3
+#endif
+
 /* SD/MMC */
 #define CONFIG_SUPPORT_EMMC_BOOT
 #define CONFIG_GENERIC_MMC
-- 
1.9.1

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

Re: [U-Boot] [PATCH 00/12] Introduce layout aware eeprom commands

[Nikita Kiryanov]

Hi Tom, Marek,
 
For the time being I do not wish to make additional refactoring to the
code as I think it is better to wait until an alternative to the bus
number is found. My changes follow the current implementation of the
eeprom command, so if there are no additional comments, can this be
applied?

On Mon, Apr 18, 2016 at 01:21:30PM +0200, Marek Vasut wrote:
> On 04/18/2016 10:22 AM, Nikita Kiryanov wrote:
> > On Sun, Apr 17, 2016 at 11:00:09PM +0200, Marek Vasut wrote:
> >> On 04/17/2016 12:33 PM, Nikita Kiryanov wrote:
> >>> Hi Marek,
> >>>
> >>> On Sun, Apr 17, 2016 at 11:47:23AM +0200, Marek Vasut wrote:
>  On 04/16/2016 04:55 PM, Nikita Kiryanov wrote:
> > This series introduces eeprom layout aware capabilities to the existing 
> > eeprom
> > command, and then enables this feature on Compulab boards. It is an 
> > import of
> > the Compulab eeprom-utility (https://github.com/compulab/eeprom-util), 
> > and it
> > introduces 2 new options to the eeprom command:
> >
> > eeprom print [-l ] bus_num device_addr
> 
>  The bus number starts to become a problem, esp. when used with DM and
>  where the bus number can change between boots.
> >>>
> >>> Are you referring to the fact that the command allows the user to not 
> >>> specify
> >>> the bus number (relying on a default value instead)?
> >>
> >> No, just using the bus number and device address doesn't seem right 
> >> anymore.
> > 
> > How so? Both are properties of the hardware, and they should be
> > addressable as such. I feel like I'm missing something, can you
> > elaborate on what you think the problem is?
> 
> The bus number is not really an exact identifier in the system anymore
> because the number changes depending on the number and order of
> registered buses in DM case. This works for now and is backwards
> compatible, but I am tempted to push for user API which would be more
> exact. You might want Simon's opinion on this too.
> 
> >>> If so, I agree with you
> >>> that it is problematic. If I had my way I would've made it a mendatory
> >>> parameter along with the device address, but that will hurt backwards
> >>> compatibility.
> >>
> >> But this is new feature, there is no backward compatibility.
> > 
> > I meant making this change for the eeprom read and write commands as well, 
> > not
> > just the new commands. I think that the new commands should follow the
> > conventions of the original commands for consistency, I just wish the 
> > current
> > conventions were less ambiguous than they are now (it's not possible to 
> > figure
> > out what ommision of these parameters does without looking at the source 
> > code).
> 
> The EEPROM code is in horrible state, indeed. If you want to clean it up
> some more, I'd be real happy.
> 
> >>
> >>> I'll be more than happy to redo the last 3 patches if we
> >>> agree that we are willing to pay that price.
> >>>
> 
>  Best regards,
>  Marek Vasut
> 
> >>
> >>
> >> -- 
> >> Best regards,
> >> Marek Vasut
> >>
> 
> 
> -- 
> Best regards,
> Marek Vasut
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] GPIO driver for Freescale QorIQ T2080

[Mario Six]

On Tue, May 10, 2016 at 1:22 AM, Hamish Martin <
hamish.mar...@alliedtelesis.co.nz> wrote:

> Hi,
>
> I'm looking for uboot driver support for the Freescale QorIQ T2080 CPU.
> This has 4 blocks of GPIOs similar to the single block defined in
> arch/powerpc/include/asm/mpc85xx_gpio.h.
>
> If someone is working on a driver for that CPU or similar, let me know.
> Ideally this would fit the new driver model. I'd be happy to help test
> it out and debug it.
>
> Alternatively, if you know another way to drive those GPIO blocks with
> existing code, feel free to suggest a way.
>
> Cheers,
> Hamish Martin.
>

Hi Hamish,

I posted v2 of a patch series for a MPC85xx GPIO DM driver just yesterday;
it was
tested on a P1022, but it's quite likely that it will work with other
QorIQs,
too (it's basically arpc/powerpc/include/asm/mpc85xx_gpio.h turned into a
proper DM driver).

Tests would be very welcome :-)

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

Re: [U-Boot] [PATCH v2] x86: qemu: Move qfw command over to cmd and add Kconfig entry

[Bin Meng]

On Wed, May 11, 2016 at 5:01 PM, Miao Yan  wrote:
> 2016-05-11 10:11 GMT+08:00 Bin Meng :
>> Hi Miao,
>>
>> On Tue, May 10, 2016 at 10:10 AM, Miao Yan  wrote:
>
> +config CMD_QEMU_FW_CFG
> +   bool "qfw"
> +   depends on X86
> +   help
> + This provides access to the QEMU firmware interface.  The main
> + feature is to allow easy loading of files passed to qemu-system
> + via -kernel / -initrd
>  endmenu

 This should really be "depends on QEMU". Sorry for my earlier comment.
>>>
>>>
>>> This line should be "depends on X86 && QEMU". Sorry I wasn't thinking right.
>>>
>>
>> This "depends on X86 && QEMU" still does not work as users can still
>> unselect this qfw command from menuconfig.
>
> The qfw commands are not mandatory, so users should be able to disable it.

Yes

>
>> We should make QEMU select this qfw command when CONFIG_GENERATE_ACPI_TABLE.
>
> GENERATE_ACPI_TABLE should select qfw core, not qfw command interface.

Correct

>
> Anyway I'll prepare patches for you guys to review.
>

Thanks!

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

Re: [U-Boot] [PATCH v2] x86: qemu: Move qfw command over to cmd and add Kconfig entry

[Miao Yan]

2016-05-11 10:11 GMT+08:00 Bin Meng :
> Hi Miao,
>
> On Tue, May 10, 2016 at 10:10 AM, Miao Yan  wrote:

 +config CMD_QEMU_FW_CFG
 +   bool "qfw"
 +   depends on X86
 +   help
 + This provides access to the QEMU firmware interface.  The main
 + feature is to allow easy loading of files passed to qemu-system
 + via -kernel / -initrd
  endmenu
>>>
>>> This should really be "depends on QEMU". Sorry for my earlier comment.
>>
>>
>> This line should be "depends on X86 && QEMU". Sorry I wasn't thinking right.
>>
>
> This "depends on X86 && QEMU" still does not work as users can still
> unselect this qfw command from menuconfig.

The qfw commands are not mandatory, so users should be able to disable it.

> We should make QEMU select this qfw command when CONFIG_GENERATE_ACPI_TABLE.

GENERATE_ACPI_TABLE should select qfw core, not qfw command interface.

Anyway I'll prepare patches for you guys to review.

Thanks,
Miao

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

[U-Boot] GPIO driver for Freescale QorIQ T2080

[Hamish Martin]

Hi,

I'm looking for uboot driver support for the Freescale QorIQ T2080 CPU. 
This has 4 blocks of GPIOs similar to the single block defined in 
arch/powerpc/include/asm/mpc85xx_gpio.h.

If someone is working on a driver for that CPU or similar, let me know. 
Ideally this would fit the new driver model. I'd be happy to help test 
it out and debug it.

Alternatively, if you know another way to drive those GPIO blocks with 
existing code, feel free to suggest a way.

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

[U-Boot] U-BOOT DDR INITIALIZATION

[yyurtcan]

Hi,
We are using P4080DS demo board.  It has two 2GB Ram. We want to
optimize/reduce both bootloader time. For bootloader we use u-boot. While we
are working on u-boot, DDR is the one that takes more time.  When we have
checked u-boot DDR initialization code timeout is stated 400 milliseconds
for each GByte. So, after that point we have done some tests. First of all,
we have removed one of DDR3 which is 2GB. We have booted demo board
successfully, and check DDR initialization time. It was 200 milliseconds and
that elapsed time is for clearing to D_INIT bit. After that, we have
attached the removed DDR. We have booted demo board successfully and check
DDR initialization time. It was 1000 milliseconds. The 800 milliseconds
elapsed time is clearing D_INIT bit for both DDR. And the 200 milliseconds
elapsed time is reallocating DDR. After that, we have removed the code that
waits for D_INIT bit to be cleared and we have booted demo board
successfully when all DDR attached (4GB). We were expecting to pass 200
milliseconds for relocation; however elapsed time was 400 milliseconds. So,
1.  What are the reasons for that?
2.  What are the reasons that when we update DDR RAM from 2 GByte to 4 GByte
it takes much more time (From 200(2GB) + 0(relocation) = 200 millisecond to
400 (2GB ) + 400 (2GB) + 200(relocation) = 1000 millisecond)?
3.  How can we reduce DDR initialization time?
4.  When we comment out the code that waits D_INIT bir to be cleared, board
boots successfully. So, do we really need to wait for D_INIT? 
Best Regards.



--
View this message in context: 
http://u-boot.10912.n7.nabble.com/U-BOOT-DDR-INITIALIZATION-tp254576.html
Sent from the U-Boot mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot UBI environment

[Joseph Hershberger]

Hi Kevin,

Am 09.05.2016 um 23:16 schrieb Kevin Smith:
> Hello,
>
> I would appreciate some UBI help/advice if you are able to provide it.
> I am trying to use UBI to store my u-boot environment, but when I try 
> to 'saveenv', it is corrupting another volume of my UBI.  I can image 
> the rootfs volume and boot Linux from it without a problem.  However, 
> the first time that I save the u-boot environment, the rootfs becomes 
> unreadable.  When the rootfs is corrupted, I have booted Linux from 
> another source and tried to attach UBI and dd out the data.  It 
> appears as all 0xFF.  Both u-boot and Linux can read the env volume correctly.
>
> I do not think that there is a board in U-boot that uses UBI env, so I 
> do not have anything to compare to.  I have included some details of 
> my setup below.  Do you have any suggestion about what might be wrong?  
> I saw the recent patch b1d6590d35, and thought it might fix it, but am
> still having the problem even with this.  Maybe there is another bug?  
> I am glad to provide more info as needed.
> Thank you,
> Kevin
>
> DTS:
> flash@d {
>   num-cs = <1>;
>   marvell,nand-keep-config;
>   marvell,nand-enable-arbiter;
>   nand-on-flash-bbt;
>   nand-ecc-strength = <4>;
>   nand-ecc-step-size = <512>;
>   status = "okay";
>
>   partition@0 {
>   label = "mvboot";
>   reg = <0 0x20>;
>   };
>   partition@20 {
>   label = "ubi";
>   reg = <0x20 0x1fe0>;
>   };
> };
> Config:
> #define MTDIDS_DEFAULT"nand0=pxa3xx_nand-0"
> #define MTDPARTS_DEFAULT "mtdparts=pxa3xx_nand-0:2m(mvboot),-(ubi)"
> #define CONFIG_CMD_UBI
> #define CONFIG_CMD_UBIFS

> #define CONFIG_MTD_UBI_FASTMAP
> #define CONFIG_MTD_UBI_FASTMAP_AUTOCONVERT1

I don’t define these 2, not sure if it matters.

> #define CONFIG_ENV_IS_IN_UBI
> #define CONFIG_ENV_UBI_PART"ubi"
> #define CONFIG_ENV_UBI_VOLUME"u-boot-env"
> #define CONFIG_ENV_SIZE(64 * 1024)

My config looks like this:

#define MTDIDS_DEFAULT "nand0=xilinx_nand"
#define MTDPARTS_DEFAULT \
"mtdparts=xilinx_nand:" \
"128k(fsbl)ro," \
"11M(u-boot)ro," \
"70M(boot-config)," \
"-(root)" 
#define CONFIG_ENV_IS_IN_UBI
#define CONFIG_ENV_UBI_PART "boot-config"
#define CONFIG_ENV_UBI_VOLUME "u-boot-env1"
#define CONFIG_ENV_UBI_VOLUME_REDUND "u-boot-env2"
#define CONFIG_ENV_SIZE 0x2

I create volumes like this:

"writepartitions=" \
"if ubi part boot-config && " \
"ubi read $verifyaddr u-boot-env1 1 && " \
"ubi read $verifyaddr u-boot-env2 1; " \
"then " \
"ubi remove bootfs && " \
"ubi remove config; " \
"else " \
"nand erase.part boot-config && " \
"ubi part boot-config && " \
"ubi create u-boot-env1 " __stringify(CONFIG_ENV_SIZE) 
" dynamic && " \
"ubi create u-boot-env2 " __stringify(CONFIG_ENV_SIZE) 
" dynamic; " \
"fi && " \
"ubi create bootfs " __stringify(CONFIG_BOOTFS_VOLUME_SIZE) " 
dynamic && " \
"ubi create config - dynamic && " \
"if ubi part root && " \
"ubi read $verifyaddr rootfs 1; " \
"then " \
"ubi remove rootfs; " \
"else " \
"nand erase.part root && " \
"ubi part root; " \
"fi && " \
"ubi create rootfs - dynamic;\0" \


> => ubi info
> UBI: MTD device name:"mtd=1"
> UBI: MTD device size:510 MiB
> UBI: physical eraseblock size:   131072 bytes (128 KiB)
> UBI: logical eraseblock size:126976 bytes
> UBI: number of good PEBs:4072
> UBI: number of bad PEBs: 8
> UBI: smallest flash I/O unit:2048
> UBI: VID header offset:  2048 (aligned 2048)
> UBI: data offset:4096
> UBI: max. allowed volumes:   128
> UBI: wear-leveling threshold:4096
> UBI: number of internal volumes: 1
> UBI: number of user volumes: 2
> UBI: available PEBs: 0
> UBI: total number of reserved PEBs: 4072
> UBI: number of PEBs reserved for bad PEB handling: 72
> UBI: max/mean erase counter: 18/4
>
> => ubi info l
> Volume information dump:
>   vol_id  0
>   reserved_pebs   1
>   alignment   1
>   data_pad0
>   vol_type3
>   name_len10
>   usable_leb_size 126976
>   used_ebs1
>   used_bytes  126976
>   last_eb_bytes   126976
>   corrupted   0
>   upd_marker  0
>   nameu-boot-env
> Volume information dump:
>   vol_id  

Re: [U-Boot] [PATCH v2] x86: qemu: Move qfw command over to cmd and add Kconfig entry

[Miao Yan]

Hi Tom,

>
> Well, this patch was a first pass at trying to separate out the logic.
> My end goal is to be able to use -kernel / -initrd / -dtb to pass in
> files "directly" to say vexpress_ca9x4 rather than have to fiddle with
> fake networking.  So we need to keep that in mind when splitting the

Well, about that, the fw_cfg is only exposed on certain QEMU emulated boards.
For ARM, it is only available on arm_virt which supports cortexA15/53/57.
Does U-boot have out-of-box support for that ?

Thanks,
Miao

> code into cmd/ common/ and arch/x86/ (I'll set aside ACPI tables on ARM
> in QEMU for the moment, but lets also not forget that will be something
> someone will talk about in the future).
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/14] x86: acpi: Support installation of Ubuntu/Windows and boot Windows

[Stefan Roese]

Hi Bin,

On 11.05.2016 10:15, Bin Meng wrote:

On Wed, May 11, 2016 at 3:23 PM, Stefan Roese  wrote:

Hi Bin,

On 09.05.2016 11:34, Bin Meng wrote:


This series fixed a bunch of issues that affect the installation
of Ubuntu and Windows, and booting Windows.

Testing was performed on MinnowMax by:
- Install Ubuntu 14.04 and boot
- Install Windows 8.1 and boot
- Install Windows 10 and boot

This series is available at u-boot-x86/acpi2-working.



This is really great news. Thanks for working on this. I do have
some questions though:

AFAICT, SeaBIOS is required for this installation, correct?


Correct.


Perhaps you should mention this here in this patch summary
as well. And if this is the case, its would be nice to enable the
SeaBIOS support at least for MinnowMAX as well in the defconfig?



Makes sense. Maybe enable this on all BayTrail boards.


Yes, please do this for v2.

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

Re: [U-Boot] [PATCH 00/14] x86: acpi: Support installation of Ubuntu/Windows and boot Windows

[Bin Meng]

Hi Stefan,

On Wed, May 11, 2016 at 3:23 PM, Stefan Roese  wrote:
> Hi Bin,
>
> On 09.05.2016 11:34, Bin Meng wrote:
>>
>> This series fixed a bunch of issues that affect the installation
>> of Ubuntu and Windows, and booting Windows.
>>
>> Testing was performed on MinnowMax by:
>> - Install Ubuntu 14.04 and boot
>> - Install Windows 8.1 and boot
>> - Install Windows 10 and boot
>>
>> This series is available at u-boot-x86/acpi2-working.
>
>
> This is really great news. Thanks for working on this. I do have
> some questions though:
>
> AFAICT, SeaBIOS is required for this installation, correct?

Correct.

> Perhaps you should mention this here in this patch summary
> as well. And if this is the case, its would be nice to enable the
> SeaBIOS support at least for MinnowMAX as well in the defconfig?
>

Makes sense. Maybe enable this on all BayTrail boards.

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

[U-Boot] [PATCH 4/9][v2] armv8: fsl-layerscape: fix compile warning "rcw_tmp"

[Prabhakar Kushwaha]

arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c: In function
‘get_sys_info’:
arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c:29:6: warning:
unused variable ‘rcw_tmp’ [-Wunused-variable]
  u32 rcw_tmp;

Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Sending as it is

 arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
index 453a93d..4fc3186 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
@@ -25,7 +25,10 @@ void get_sys_info(struct sys_info *sys_info)
struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
u32 ccr;
 #endif
-#if defined(CONFIG_FSL_ESDHC) || defined(CONFIG_SYS_DPAA_FMAN)
+#if (defined(CONFIG_FSL_ESDHC) &&\
+   defined(CONFIG_FSL_ESDHC_USE_PERIPHERAL_CLK)) ||\
+   defined(CONFIG_SYS_DPAA_FMAN)
+
u32 rcw_tmp;
 #endif
struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_CLK_ADDR);
-- 
1.9.1


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

[U-Boot] [PATCH 8/9][v2] armv8: ls1012a: Add support of ls1012aqds board

[Prabhakar Kushwaha]

QorIQ LS1012A Development System (LS1012AQDS) is a high-performance
development platform, with a complete debugging environment.
The LS1012AQDS board supports the QorIQ LS1012A processor and is
optimized to support the high-bandwidth DDR3L memory and
a full complement of high-speed SerDes ports.

Signed-off-by: Calvin Johnson 
Signed-off-by: Pratiyush Mohan Srivastava 
Signed-off-by: Abhimanyu Saini 
Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: 
  - Added support of qixis over i2c
  - print fpga, board info using qixis

 arch/arm/Kconfig  |  10 ++
 arch/arm/dts/Makefile |   3 +-
 arch/arm/dts/fsl-ls1012a-qds.dts  |  14 ++
 arch/arm/dts/fsl-ls1012a-qds.dtsi | 123 ++
 arch/arm/dts/fsl-ls1012a.dtsi | 119 ++
 board/freescale/ls1012aqds/Kconfig|  15 ++
 board/freescale/ls1012aqds/MAINTAINERS|   6 +
 board/freescale/ls1012aqds/Makefile   |   7 +
 board/freescale/ls1012aqds/README |  94 +++
 board/freescale/ls1012aqds/ls1012aqds.c   | 220 ++
 board/freescale/ls1012aqds/ls1012aqds_qixis.h |  35 
 configs/ls1012aqds_qspi_defconfig |  32 
 include/configs/ls1012a_common.h  | 195 +++
 include/configs/ls1012aqds.h  | 150 ++
 14 files changed, 1022 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dts
 create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1012a.dtsi
 create mode 100644 board/freescale/ls1012aqds/Kconfig
 create mode 100644 board/freescale/ls1012aqds/MAINTAINERS
 create mode 100644 board/freescale/ls1012aqds/Makefile
 create mode 100644 board/freescale/ls1012aqds/README
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds.c
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds_qixis.h
 create mode 100644 configs/ls1012aqds_qspi_defconfig
 create mode 100644 include/configs/ls1012a_common.h
 create mode 100644 include/configs/ls1012aqds.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 6b65d8e..2540045 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -673,6 +673,15 @@ config TARGET_HIKEY
  Support for HiKey 96boards platform. It features a HI6220
  SoC, with 8xA53 CPU, mali450 gpu, and 1GB RAM.
 
+config TARGET_LS1012AQDS
+   bool "Support ls1012aqds"
+   select ARM64
+   help
+ Support for Freescale LS1012AQDS platform.
+ The LS1012A Development System (QDS) is a high-performance
+ development platform that supports the QorIQ LS1012A
+ Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
bool "Support ls1021aqds"
select CPU_V7
@@ -831,6 +840,7 @@ source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
 source "board/freescale/ls1043ardb/Kconfig"
+source "board/freescale/ls1012aqds/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx25pdk/Kconfig"
 source "board/freescale/mx28evk/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d1f8e22..b26870a 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -113,7 +113,8 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
fsl-ls2080a-rdb.dtb
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
-   fsl-ls1043a-rdb.dtb
+   fsl-ls1043a-rdb.dtb \
+   fsl-ls1012a-qds.dtb
 
 dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb
 
diff --git a/arch/arm/dts/fsl-ls1012a-qds.dts b/arch/arm/dts/fsl-ls1012a-qds.dts
new file mode 100644
index 000..ef6de34
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-qds.dts
@@ -0,0 +1,14 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include "fsl-ls1012a-qds.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   };
+};
diff --git a/arch/arm/dts/fsl-ls1012a-qds.dtsi 
b/arch/arm/dts/fsl-ls1012a-qds.dtsi
new file mode 100644
index 000..a32a84a
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-qds.dtsi
@@ -0,0 +1,123 @@
+/*
+ * Copyright (C) 2016 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/include/ "fsl-ls1012a.dtsi"
+
+/ {
+   model = "LS1012A QDS Board";
+   aliases {
+   spi0 = 
+   spi1 = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   dflash0: n25q128a {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   reg = <0>;
+   spi-max-frequency = <100>; /* input clock */
+   };
+
+   dflash1: sst25wf040b {
+   

[U-Boot] [PATCH 6/9][v2] board: freescale: common: Conditionally compile IFC QXIS func

[Prabhakar Kushwaha]

From: Abhimanyu Saini 

Check if qixis supports memory-mapped read/write
before compiling IFC based qixis read/write functions.

Signed-off-by: Calvin Johnson 
Signed-off-by: Abhimanyu Saini 
Signed-off-by: Prabhakar Kushwaha 
---
Chages for v2: New patch in this patch-set

 board/freescale/common/qixis.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/freescale/common/qixis.c b/board/freescale/common/qixis.c
index 113295f..2e35d41 100644
--- a/board/freescale/common/qixis.c
+++ b/board/freescale/common/qixis.c
@@ -27,6 +27,7 @@ void qixis_write_i2c(unsigned int reg, u8 value)
 }
 #endif
 
+#ifdef QIXIS_BASE
 u8 qixis_read(unsigned int reg)
 {
void *p = (void *)QIXIS_BASE;
@@ -40,6 +41,7 @@ void qixis_write(unsigned int reg, u8 value)
 
out_8(p + reg, value);
 }
+#endif
 
 u16 qixis_read_minor(void)
 {
-- 
1.9.1


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

[U-Boot] [PATCH 1/9][v2] armv8: fsl-layerscape: Put SMMU config code in SMMU_BASE

[Prabhakar Kushwaha]

It is not mandatory for Layerscape SoCs to have SMMU. SoCs like
LS1012A are layerscape SoC without SMMU IP.

So put SMMU configuration code under SMMU_BASE.

Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Sending as it is

 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index 04831ca..d743ffe 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -94,11 +94,13 @@ ENTRY(lowlevel_init)
bl  ccn504_set_qos
 #endif
 
+#ifdef SMMU_BASE
/* Set the SMMU page size in the sACR register */
ldr x1, =SMMU_BASE
ldr w0, [x1, #0x10]
orr w0, w0, #1 << 16  /* set sACR.pagesize to indicate 64K page */
str w0, [x1, #0x10]
+#endif
 
/* Initialize GIC Secure Bank Status */
 #if defined(CONFIG_GICV2) || defined(CONFIG_GICV3)
-- 
1.9.1


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

[U-Boot] [PATCH 9/9][v2] armv8: ls1012a: Add support of ls1012ardb board

[Prabhakar Kushwaha]

QorIQ LS1012A Reference Design System (LS1012ARDB) is a high-performance
development platform, with a complete debugging environment.
The LS1012ARDB board supports the QorIQ LS1012A processor and is
optimized to support the high-bandwidth DDR3L memory and
a full complement of high-speed SerDes ports.

Signed-off-by: Calvin Johnson 
Signed-off-by: Pratiyush Mohan Srivastava 
Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Sending as it is

 arch/arm/Kconfig|  10 ++
 arch/arm/dts/Makefile   |   3 +-
 arch/arm/dts/fsl-ls1012a-rdb.dts|  16 +++
 arch/arm/dts/fsl-ls1012a-rdb.dtsi   |  39 ++
 board/freescale/ls1012ardb/Kconfig  |  15 +++
 board/freescale/ls1012ardb/MAINTAINERS  |   6 +
 board/freescale/ls1012ardb/Makefile |   7 ++
 board/freescale/ls1012ardb/README   |  89 ++
 board/freescale/ls1012ardb/ls1012ardb.c | 210 
 configs/ls1012ardb_qspi_defconfig   |  32 +
 include/configs/ls1012ardb.h|  59 +
 11 files changed, 485 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dts
 create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dtsi
 create mode 100644 board/freescale/ls1012ardb/Kconfig
 create mode 100644 board/freescale/ls1012ardb/MAINTAINERS
 create mode 100644 board/freescale/ls1012ardb/Makefile
 create mode 100644 board/freescale/ls1012ardb/README
 create mode 100644 board/freescale/ls1012ardb/ls1012ardb.c
 create mode 100644 configs/ls1012ardb_qspi_defconfig
 create mode 100644 include/configs/ls1012ardb.h

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2540045..31dfac2 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -682,6 +682,15 @@ config TARGET_LS1012AQDS
  development platform that supports the QorIQ LS1012A
  Layerscape Architecture processor.
 
+config TARGET_LS1012ARDB
+   bool "Support ls1012ardb"
+   select ARM64
+   help
+ Support for Freescale LS1012ARDB platform.
+ The LS1012A Reference design board (RDB) is a high-performance
+ development platform that supports the QorIQ LS1012A
+ Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
bool "Support ls1021aqds"
select CPU_V7
@@ -841,6 +850,7 @@ source "board/freescale/ls1043aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
 source "board/freescale/ls1043ardb/Kconfig"
 source "board/freescale/ls1012aqds/Kconfig"
+source "board/freescale/ls1012ardb/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
 source "board/freescale/mx25pdk/Kconfig"
 source "board/freescale/mx28evk/Kconfig"
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index b26870a..9324d82 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -114,7 +114,8 @@ dtb-$(CONFIG_FSL_LSCH3) += fsl-ls2080a-qds.dtb \
 dtb-$(CONFIG_FSL_LSCH2) += fsl-ls1043a-qds-duart.dtb \
fsl-ls1043a-qds-lpuart.dtb \
fsl-ls1043a-rdb.dtb \
-   fsl-ls1012a-qds.dtb
+   fsl-ls1012a-qds.dtb \
+   fsl-ls1012a-rdb.dtb
 
 dtb-$(CONFIG_ARCH_SNAPDRAGON) += dragonboard410c.dtb
 
diff --git a/arch/arm/dts/fsl-ls1012a-rdb.dts b/arch/arm/dts/fsl-ls1012a-rdb.dts
new file mode 100644
index 000..4ec9786
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-rdb.dts
@@ -0,0 +1,16 @@
+/*
+ * Device Tree file for Freescale Layerscape-1012A family SoC.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/dts-v1/;
+#include "fsl-ls1012a-rdb.dtsi"
+
+/ {
+   chosen {
+   stdout-path = 
+   };
+};
diff --git a/arch/arm/dts/fsl-ls1012a-rdb.dtsi 
b/arch/arm/dts/fsl-ls1012a-rdb.dtsi
new file mode 100644
index 000..71aba78
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1012a-rdb.dtsi
@@ -0,0 +1,39 @@
+/*
+ * Device Tree Include file for Freescale Layerscape-1012A family SoC.
+ *
+ * Copyright (C) 2016, Freescale Semiconductor
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+/include/ "fsl-ls1012a.dtsi"
+
+/ {
+   model = "LS1012A RDB Board";
+   aliases {
+   spi0 = 
+   };
+};
+
+ {
+   bus-num = <0>;
+   status = "okay";
+
+   qflash0: s25fl128s@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "spi-flash";
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   };
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
diff --git a/board/freescale/ls1012ardb/Kconfig 
b/board/freescale/ls1012ardb/Kconfig
new file mode 100644
index 000..3f67c28
--- /dev/null
+++ b/board/freescale/ls1012ardb/Kconfig
@@ -0,0 +1,15 @@
+if TARGET_LS1012ARDB
+
+config SYS_BOARD
+   default 

[U-Boot] [PATCH 7/9][v2] board: freescale: common: Add flag for LBMAP brdcfg reg offset

[Prabhakar Kushwaha]

From: Abhimanyu Saini 

Add QIXIS_LBMAP_BRDCFG_REG to the save offset of LBMAP
configuration register instead of hardcoding it in
set_lbmap() function.

Signed-off-by: Calvin Johnson 
Signed-off-by: Abhimanyu Saini 
Signed-off-by: Prabhakar Kushwaha 
---
Chages for v2: New patch in this patch-set

 board/freescale/common/qixis.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/board/freescale/common/qixis.c b/board/freescale/common/qixis.c
index 2e35d41..0db0ed6 100644
--- a/board/freescale/common/qixis.c
+++ b/board/freescale/common/qixis.c
@@ -14,6 +14,13 @@
 #include 
 #include "qixis.h"
 
+#ifndef QIXIS_LBMAP_BRDCFG_REG
+/*
+ * For consistency with existing platforms
+ */
+#define QIXIS_LBMAP_BRDCFG_REG 0x00
+#endif
+
 #ifdef CONFIG_SYS_I2C_FPGA_ADDR
 u8 qixis_read_i2c(unsigned int reg)
 {
@@ -144,9 +151,9 @@ static void __maybe_unused set_lbmap(int lbmap)
 {
u8 reg;
 
-   reg = QIXIS_READ(brdcfg[0]);
+   reg = QIXIS_READ(brdcfg[QIXIS_LBMAP_BRDCFG_REG]);
reg = (reg & ~QIXIS_LBMAP_MASK) | lbmap;
-   QIXIS_WRITE(brdcfg[0], reg);
+   QIXIS_WRITE(brdcfg[QIXIS_LBMAP_BRDCFG_REG], reg);
 }
 
 static void __maybe_unused set_rcw_src(int rcw_src)
-- 
1.9.1


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

[U-Boot] [PATCH 5/9][v2] armv8: fsl-layerscape: Add support of QorIQ LS1012A SoC

[Prabhakar Kushwaha]

The QorIQ LS1012A processor, optimized for battery-backed or
USB-powered, integrates a single ARM Cortex-A53 core with a hardware
packet forwarding engine and high-speed interfaces to deliver
line-rate networking performance.

This patch add support of LS1012A SoC along with
 - Update platform & DDR clock read logic as per SVR
 - Define MMDC controller register set.
 - Update LUT base address for PCIe
 - Avoid L3 platform cache compilation
 - Update USB address, errata
 - SerDes table
 - Added CSU IDs for SDHC2, SAI-1 to SAI-4

Signed-off-by: Calvin Johnson 
Signed-off-by: Makarand Pawagi 
Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Sending as it is

 arch/arm/cpu/armv8/fsl-layerscape/Makefile |  4 +
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c | 24 --
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |  2 +
 arch/arm/cpu/armv8/fsl-layerscape/ls1012a_serdes.c | 74 +
 arch/arm/include/asm/arch-fsl-layerscape/config.h  | 31 +++
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |  1 +
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |  1 +
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |  4 +
 .../include/asm/arch-fsl-layerscape/ns_access.h| 10 +++
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |  1 +
 include/fsl_mmdc.h | 94 ++
 include/linux/usb/xhci-fsl.h   |  6 +-
 12 files changed, 245 insertions(+), 7 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1012a_serdes.c
 create mode 100644 include/fsl_mmdc.h

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/Makefile 
b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
index 5f86ef9..eb2cbc3 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/Makefile
+++ b/arch/arm/cpu/armv8/fsl-layerscape/Makefile
@@ -28,3 +28,7 @@ endif
 ifneq ($(CONFIG_LS1043A),)
 obj-$(CONFIG_SYS_HAS_SERDES) += ls1043a_serdes.o
 endif
+
+ifneq ($(CONFIG_LS1012A),)
+obj-$(CONFIG_SYS_HAS_SERDES) += ls1012a_serdes.o
+endif
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c 
b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
index 4fc3186..41c3688 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c
@@ -33,6 +33,7 @@ void get_sys_info(struct sys_info *sys_info)
 #endif
struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_CLK_ADDR);
unsigned int cpu;
+   unsigned int svr, ver;
const u8 core_cplx_pll[8] = {
[0] = 0,/* CC1 PPL / 1 */
[1] = 0,/* CC1 PPL / 2 */
@@ -59,12 +60,20 @@ void get_sys_info(struct sys_info *sys_info)
sys_info->freq_ddrbus = sysclk;
 #endif
 
-   sys_info->freq_systembus *= (gur_in32(>rcwsr[0]) >>
-   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_SHIFT) &
-   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_MASK;
-   sys_info->freq_ddrbus *= (gur_in32(>rcwsr[0]) >>
-   FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_SHIFT) &
-   FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_MASK;
+   svr = gur_in32(>svr);
+   ver = SVR_SOC_VER(svr);
+   if (ver == SVR_LS1012) {
+   sys_info->freq_ddrbus *= (gur_in32(>rcwsr[0]) >>
+   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_SHIFT) &
+   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_MASK;
+   } else {
+   sys_info->freq_systembus *= (gur_in32(>rcwsr[0]) >>
+   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_SHIFT) &
+   FSL_CHASSIS2_RCWSR0_SYS_PLL_RAT_MASK;
+   sys_info->freq_ddrbus *= (gur_in32(>rcwsr[0]) >>
+   FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_SHIFT) &
+   FSL_CHASSIS2_RCWSR0_MEM_PLL_RAT_MASK;
+   }
 
for (i = 0; i < CONFIG_SYS_FSL_NUM_CC_PLLS; i++) {
ratio[i] = (in_be32(>pllcgsr[i].pllcngsr) >> 1) & 0xff;
@@ -83,6 +92,9 @@ void get_sys_info(struct sys_info *sys_info)
freq_c_pll[cplx_pll] / core_cplx_pll_div[c_pll_sel];
}
 
+   if (ver == SVR_LS1012)
+   sys_info->freq_systembus = sys_info->freq_ddrbus / 2;
+
 #define HWA_CGA_M1_CLK_SEL 0xe000
 #define HWA_CGA_M1_CLK_SHIFT   29
 #ifdef CONFIG_SYS_DPAA_FMAN
diff --git a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S 
b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
index d743ffe..5af6b73 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
+++ b/arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S
@@ -183,6 +183,7 @@ ENTRY(lowlevel_init)
ret
 ENDPROC(lowlevel_init)
 
+#ifdef CONFIG_FSL_LSCH3
 hnf_pstate_poll:
/* x0 has the desired status, return 0 for success, 1 for timeout
 * clobber x1, x2, x3, x4, x6, x7
@@ -260,6 +261,7 @@ ENTRY(__asm_flush_l3_cache)
mov lr, x29
ret
 

[U-Boot] [PATCH 3/9][v2] driver: mtd: spi: Adding support for QSPI flash

[Prabhakar Kushwaha]

Serial number, vendor id and page size are added for QSPI flash
common on both LS1012AQDS and LS1012ARDB i.e. S25FS512SDSMFI011.

Signed-off-by: Pratiyush Mohan Srivastava 
Signed-off-by: Calvin Johnson 
Signed-off-by: Mingkai Hu 
Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Sending as it is

 drivers/mtd/spi/sf_params.c | 1 +
 drivers/mtd/spi/spi_flash.c | 5 +++--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi/sf_params.c b/drivers/mtd/spi/sf_params.c
index 4f37e33..c577d9e 100644
--- a/drivers/mtd/spi/sf_params.c
+++ b/drivers/mtd/spi/sf_params.c
@@ -67,6 +67,7 @@ const struct spi_flash_params spi_flash_params_table[] = {
{"S25FL128S_64K",  0x012018, 0x4d01,64 * 1024,   256, RD_FULL,  
 WR_QPP},
{"S25FL256S_256K", 0x010219, 0x4d00,   256 * 1024,   128, RD_FULL,  
 WR_QPP},
{"S25FL256S_64K",  0x010219, 0x4d01,64 * 1024,   512, RD_FULL,  
 WR_QPP},
+   {"S25FS512S",  0x010220, 0x4D00,   128 * 1024,   512, RD_FULL,  
 WR_QPP},
{"S25FL512S_256K", 0x010220, 0x4d00,   256 * 1024,   256, RD_FULL,  
 WR_QPP},
{"S25FL512S_64K",  0x010220, 0x4d01,64 * 1024,  1024, RD_FULL,  
 WR_QPP},
{"S25FL512S_512K", 0x010220, 0x4f00,   256 * 1024,   256, RD_FULL,  
 WR_QPP},
diff --git a/drivers/mtd/spi/spi_flash.c b/drivers/mtd/spi/spi_flash.c
index fa0e799..64d4e0f 100644
--- a/drivers/mtd/spi/spi_flash.c
+++ b/drivers/mtd/spi/spi_flash.c
@@ -1072,7 +1072,8 @@ int spi_flash_scan(struct spi_flash *flash)
 * sector that is not overlaid by the parameter sectors.
 * The uniform sector erase command has no effect on parameter sectors.
 */
-   if (jedec == 0x0219 && (ext_jedec & 0xff00) == 0x4d00) {
+   if ((jedec == 0x0219 || (jedec == 0x0220)) &&
+   (ext_jedec & 0xff00) == 0x4d00) {
int ret;
u8 id[6];
 
@@ -1146,7 +1147,7 @@ int spi_flash_scan(struct spi_flash *flash)
 * have 256b pages.
 */
if (ext_jedec == 0x4d00) {
-   if ((jedec == 0x0215) || (jedec == 0x216))
+   if ((jedec == 0x0215) || (jedec == 0x216) || (jedec == 0x220))
flash->page_size = 256;
else
flash->page_size = 512;
-- 
1.9.1


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

[U-Boot] [PATCH 0/9][v2] armv8: fsl-layerscape: Add support of LS1012A SoC and platform

[Prabhakar Kushwaha]

The QorIQ LS1012A processor is a new Freescale' SoC optimized for 
battery-backed or USB-powered, integrates a single ARM Cortex-A53
core with a hardware packet forwarding engine and high-speed 
interfaces to deliver line-rate networking performance.

LS1012AQDS, LS1012ARDB are a high-performance development platform
using LS1012A SoC.

This patch-set add support of LS1012A SoC, platfrom along with modify
existing code to support LS1012A. 

This patch set is dependent upon following spi related patches
https://patchwork.ozlabs.org/patch/597365/
https://patchwork.ozlabs.org/patch/597366/
https://patchwork.ozlabs.org/patch/597367/
https://patchwork.ozlabs.org/patch/597368/
https://patchwork.ozlabs.org/patch/597369/

Changes for v2: Add support of board, fpga info and qixis_reset for QDS


Abhimanyu Saini (2):
  board: freescale: common: Conditionally compile IFC QXIS func
  board: freescale: common: Add flag for LBMAP brdcfg reg offset

Prabhakar Kushwaha (7):
  armv8: fsl-layerscape: Put SMMU config code in SMMU_BASE
  armv8: fsl-layerscape: Avoid LS1043A specifc defines
  driver: mtd: spi: Adding support for QSPI flash
  armv8: fsl-layerscape: fix compile warning "rcw_tmp"
  armv8: fsl-layerscape: Add support of QorIQ LS1012A SoC
  armv8: ls1012a: Add support of ls1012aqds board
  armv8: ls1012a: Add support of ls1012ardb board

 arch/arm/Kconfig   |  20 ++
 arch/arm/cpu/armv8/fsl-layerscape/Makefile |   4 +
 .../arm/cpu/armv8/fsl-layerscape/fsl_lsch2_speed.c |  29 ++-
 arch/arm/cpu/armv8/fsl-layerscape/lowlevel.S   |   4 +
 arch/arm/cpu/armv8/fsl-layerscape/ls1012a_serdes.c |  74 +++
 arch/arm/cpu/armv8/fsl-layerscape/soc.c|   2 +-
 arch/arm/dts/Makefile  |   4 +-
 arch/arm/dts/fsl-ls1012a-qds.dts   |  14 ++
 arch/arm/dts/fsl-ls1012a-qds.dtsi  | 123 
 arch/arm/dts/fsl-ls1012a-rdb.dts   |  16 ++
 arch/arm/dts/fsl-ls1012a-rdb.dtsi  |  39 
 arch/arm/dts/fsl-ls1012a.dtsi  | 119 +++
 arch/arm/include/asm/arch-fsl-layerscape/config.h  |  31 +++
 arch/arm/include/asm/arch-fsl-layerscape/cpu.h |   1 +
 .../include/asm/arch-fsl-layerscape/fsl_serdes.h   |   3 +-
 .../include/asm/arch-fsl-layerscape/immap_lsch2.h  |   4 +
 .../include/asm/arch-fsl-layerscape/ns_access.h|  10 +
 arch/arm/include/asm/arch-fsl-layerscape/soc.h |   1 +
 board/freescale/common/qixis.c |  13 +-
 board/freescale/ls1012aqds/Kconfig |  15 ++
 board/freescale/ls1012aqds/MAINTAINERS |   6 +
 board/freescale/ls1012aqds/Makefile|   7 +
 board/freescale/ls1012aqds/README  |  94 +
 board/freescale/ls1012aqds/ls1012aqds.c| 220 +
 board/freescale/ls1012aqds/ls1012aqds_qixis.h  |  35 
 board/freescale/ls1012ardb/Kconfig |  15 ++
 board/freescale/ls1012ardb/MAINTAINERS |   6 +
 board/freescale/ls1012ardb/Makefile|   7 +
 board/freescale/ls1012ardb/README  |  89 +
 board/freescale/ls1012ardb/ls1012ardb.c| 210 
 configs/ls1012aqds_qspi_defconfig  |  32 +++
 configs/ls1012ardb_qspi_defconfig  |  32 +++
 drivers/mtd/spi/sf_params.c|   1 +
 drivers/mtd/spi/spi_flash.c|   5 +-
 include/configs/ls1012a_common.h   | 195 ++
 include/configs/ls1012aqds.h   | 150 ++
 include/configs/ls1012ardb.h   |  59 ++
 include/fsl_mmdc.h |  94 +
 include/linux/usb/xhci-fsl.h   |   6 +-
 39 files changed, 1774 insertions(+), 15 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-layerscape/ls1012a_serdes.c
 create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dts
 create mode 100644 arch/arm/dts/fsl-ls1012a-qds.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dts
 create mode 100644 arch/arm/dts/fsl-ls1012a-rdb.dtsi
 create mode 100644 arch/arm/dts/fsl-ls1012a.dtsi
 create mode 100644 board/freescale/ls1012aqds/Kconfig
 create mode 100644 board/freescale/ls1012aqds/MAINTAINERS
 create mode 100644 board/freescale/ls1012aqds/Makefile
 create mode 100644 board/freescale/ls1012aqds/README
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds.c
 create mode 100644 board/freescale/ls1012aqds/ls1012aqds_qixis.h
 create mode 100644 board/freescale/ls1012ardb/Kconfig
 create mode 100644 board/freescale/ls1012ardb/MAINTAINERS
 create mode 100644 board/freescale/ls1012ardb/Makefile
 create mode 100644 board/freescale/ls1012ardb/README
 create mode 100644 board/freescale/ls1012ardb/ls1012ardb.c
 create mode 100644 configs/ls1012aqds_qspi_defconfig
 create mode 100644 configs/ls1012ardb_qspi_defconfig
 create mode 100644 

[U-Boot] [PATCH 2/9][v2] armv8: fsl-layerscape: Avoid LS1043A specifc defines

[Prabhakar Kushwaha]

Other than LS1043A, LS1012A also Chassis Gen2 Architecture compliant.

So Avoid LS1043A specific defines in arch/arm

Signed-off-by: Prabhakar Kushwaha 
---
Changes for v2: Sending as it is

 arch/arm/cpu/armv8/fsl-layerscape/soc.c   | 2 +-
 arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/cpu/armv8/fsl-layerscape/soc.c 
b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
index 0cb0100..41f9547 100644
--- a/arch/arm/cpu/armv8/fsl-layerscape/soc.c
+++ b/arch/arm/cpu/armv8/fsl-layerscape/soc.c
@@ -222,7 +222,7 @@ int sata_init(void)
 }
 #endif
 
-#elif defined(CONFIG_LS1043A)
+#elif defined(CONFIG_FSL_LSCH2)
 #ifdef CONFIG_SCSI_AHCI_PLAT
 int sata_init(void)
 {
diff --git a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h 
b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
index f71c2c1..c4fb7c9 100644
--- a/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
+++ b/arch/arm/include/asm/arch-fsl-layerscape/fsl_serdes.h
@@ -55,7 +55,7 @@ enum srds {
FSL_SRDS_1  = 0,
FSL_SRDS_2  = 1,
 };
-#elif defined(CONFIG_LS1043A)
+#elif defined(CONFIG_FSL_LSCH2)
 enum srds_prtcl {
NONE = 0,
PCIE1,
-- 
1.9.1


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

Re: [U-Boot] [PATCH 00/14] x86: acpi: Support installation of Ubuntu/Windows and boot Windows

[Stefan Roese]

Hi Bin,

On 09.05.2016 11:34, Bin Meng wrote:

This series fixed a bunch of issues that affect the installation
of Ubuntu and Windows, and booting Windows.

Testing was performed on MinnowMax by:
- Install Ubuntu 14.04 and boot
- Install Windows 8.1 and boot
- Install Windows 10 and boot

This series is available at u-boot-x86/acpi2-working.


This is really great news. Thanks for working on this. I do have
some questions though:

AFAICT, SeaBIOS is required for this installation, correct?
Perhaps you should mention this here in this patch summary
as well. And if this is the case, its would be nice to enable the
SeaBIOS support at least for MinnowMAX as well in the defconfig?

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

Re: [U-Boot] [PATCH 01/14] x86: minnowmax: Adjust U-Boot environment address in SPI flash

[Stefan Roese]

On 09.05.2016 11:34, Bin Meng wrote:

Currently U-Boot environment address is at offset 0x7fe00 of a 8MB
SPI flash. When creating a partial u-boot.rom image without flash
descriptor and ME firmware, U-Boot actually occupies the last 1MB
of the flash, and reprograming U-Boot causes previous environment
settings get lost which is not convenient during testing.

Adjust the environment address to 0x6ef000 instead (before the MRC
cache data region in the flash).

Signed-off-by: Bin Meng 


Reviewed-by: Stefan Roese 

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