Re: [U-Boot] [PATCH v2] odroid: remove CONFIG_DM_I2C_COMPAT config

[Minkyu Kang]

Hi

2017. 6. 7. 12:09에 "Jaehoon Chung" 님이 작성:

Remove the CONFIG_DM_I2C_COMPAT config.

Signed-off-by: Jaehoon Chung 
Reviewed-by: Simon Glass 
---
Changelog on V2:
- Rebased on latest u-boot-samsung
- Added Simon's Reviewed tag
- Fix the typo (COMPAT_DM_I2C_COMPAT -> CONFIG_DM_I2C_COMPAT)

 configs/odroid_defconfig | 2 +-
 include/configs/odroid.h | 5 -
 2 files changed, 1 insertion(+), 6 deletions(-)


applied to u-boot-samsung.

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

[U-Boot] [PATCH v3] rockchip: video: mipi: Modify variable type for arm32 compatibility

[Eric Gao]

Some address relevant varibable is defined originally as u64. To
compatible with arm32, this patch change them to uintptr_t type.

Signed-off-by: Eric Gao 
Reviewed-by: Simon Glass 

---

Changes in v2:
-Change the address base variable from "uintptr_t *" to "uintptr_t"

Changes in v1:
-Change the address base variable to uintptr_t * type.

 drivers/video/rockchip/rk_mipi.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/video/rockchip/rk_mipi.c b/drivers/video/rockchip/rk_mipi.c
index ad00397..521256e 100644
--- a/drivers/video/rockchip/rk_mipi.c
+++ b/drivers/video/rockchip/rk_mipi.c
@@ -40,7 +40,7 @@ DECLARE_GLOBAL_DATA_PTR;
  * @txesc_clk: clock for tx esc mode
  */
 struct rk_mipi_priv {
-   void __iomem *regs;
+   uintptr_t regs;
struct rk3399_grf_regs *grf;
struct udevice *panel;
struct mipi_dsi *dsi;
@@ -76,13 +76,13 @@ static int rk_mipi_read_timing(struct udevice *dev,
  *use define in rk_mipi.h directly for this parameter
  *  @val: value that will be write to specified bits of register
  */
-static void rk_mipi_dsi_write(u32 regs, u32 reg, u32 val)
+static void rk_mipi_dsi_write(uintptr_t regs, u32 reg, u32 val)
 {
u32 dat;
u32 mask;
u32 offset = (reg >> OFFSET_SHIFT) & 0xff;
u32 bits = (reg >> BITS_SHIFT) & 0xff;
-   u64 addr = (reg >> ADDR_SHIFT) + regs;
+   uintptr_t *addr = (reg >> ADDR_SHIFT) + regs;
 
/* Mask for specifiled bits,the corresponding bits will be clear */
mask = ~((0x << offset) & (0x >> (32 - offset - bits)));
@@ -108,7 +108,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
int node, timing_node;
int val;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t regs = priv->regs;
struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
u32 txbyte_clk = priv->txbyte_clk;
u32 txesc_clk = priv->txesc_clk;
@@ -224,7 +224,7 @@ static int rk_mipi_dsi_enable(struct udevice *dev,
 }
 
 /* rk mipi dphy write function. It is used to write test data to dphy */
-static void rk_mipi_phy_write(u32 regs, unsigned char test_code,
+static void rk_mipi_phy_write(uintptr_t regs, unsigned char test_code,
  unsigned char *test_data, unsigned char size)
 {
int i = 0;
@@ -253,7 +253,7 @@ static int rk_mipi_phy_enable(struct udevice *dev)
 {
int i;
struct rk_mipi_priv *priv = dev_get_priv(dev);
-   u64 regs = (u64)priv->regs;
+   uintptr_t regs = priv->regs;
u64 fbdiv;
u64 prediv = 1;
u32 max_fbdiv = 512;
-- 
1.9.1


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

[U-Boot] [PATCH 2/3] dtoc: Add a 64-bit type and a way to convert cells into 64 bits

[Simon Glass]

When dealing with multi-cell values we need a type that can hold this
value. Add this and a function to process it from a list of cell values.

Signed-off-by: Simon Glass 
---

 tools/dtoc/dtb_platdata.py |  3 +++
 tools/dtoc/fdt.py  |  2 +-
 tools/dtoc/fdt_util.py | 14 ++
 3 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index 1f85343a9f..f5841cbb88 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -38,6 +38,7 @@ TYPE_NAMES = {
 fdt.TYPE_BYTE: 'unsigned char',
 fdt.TYPE_STRING: 'const char *',
 fdt.TYPE_BOOL: 'bool',
+fdt.TYPE_INT64: 'fdt64_t',
 }
 
 STRUCT_PREFIX = 'dtd_'
@@ -95,6 +96,8 @@ def get_value(ftype, value):
 return '"%s"' % value
 elif ftype == fdt.TYPE_BOOL:
 return 'true'
+elif ftype == fdt.TYPE_INT64:
+return '%#x' % value
 
 def get_compat_name(node):
 """Get a node's first compatible string as a C identifier
diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index 49409a62ec..ffd42ce541 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -21,7 +21,7 @@ import libfdt
 # so it is fairly efficient.
 
 # A list of types we support
-(TYPE_BYTE, TYPE_INT, TYPE_STRING, TYPE_BOOL) = range(4)
+(TYPE_BYTE, TYPE_INT, TYPE_STRING, TYPE_BOOL, TYPE_INT64) = range(5)
 
 def CheckErr(errnum, msg):
 if errnum:
diff --git a/tools/dtoc/fdt_util.py b/tools/dtoc/fdt_util.py
index b9dfae8d0e..bec6ee947a 100644
--- a/tools/dtoc/fdt_util.py
+++ b/tools/dtoc/fdt_util.py
@@ -29,6 +29,20 @@ def fdt32_to_cpu(val):
 val = val.encode('raw_unicode_escape')
 return struct.unpack('>I', val)[0]
 
+def fdt_cells_to_cpu(val, cells):
+"""Convert one or two cells to a long integer
+
+Args:
+Value to convert (array of one or more 4-character strings)
+
+Return:
+A native-endian long value
+"""
+out = long(fdt32_to_cpu(val[0]))
+if cells == 2:
+out = out << 32 | fdt32_to_cpu(val[1])
+return out
+
 def EnsureCompiled(fname):
 """Compile an fdt .dts source file into a .dtb binary blob if needed.
 
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 3/3] dtoc: Add support for 32 or 64-bit addresses

[Simon Glass]

When using 32-bit addresses dtoc works correctly. For 64-bit addresses it
does not since it ignores the #address-cells and #size-cells properties.

Update the tool to use fdt64_t as the element type for reg properties when
either the address or size is larger than one cell. Use the correct value
so that C code can obtain the information from the device tree easily.

Add tests for the four combinations of address and size values (32/32,
64/64, 32/64, 64/32).

Signed-off-by: Simon Glass 
Suggested-by: Heiko Stuebner 
Reported-by: Kever Yang 
---

 tools/dtoc/dtb_platdata.py |  59 +++
 tools/dtoc/dtoc_test_addr32.dts|  27 +
 tools/dtoc/dtoc_test_addr32_64.dts |  33 ++
 tools/dtoc/dtoc_test_addr64.dts|  33 ++
 tools/dtoc/dtoc_test_addr64_32.dts |  33 ++
 tools/dtoc/test_dtoc.py| 212 +
 6 files changed, 397 insertions(+)
 create mode 100644 tools/dtoc/dtoc_test_addr32.dts
 create mode 100644 tools/dtoc/dtoc_test_addr32_64.dts
 create mode 100644 tools/dtoc/dtoc_test_addr64.dts
 create mode 100644 tools/dtoc/dtoc_test_addr64_32.dts

diff --git a/tools/dtoc/dtb_platdata.py b/tools/dtoc/dtb_platdata.py
index f5841cbb88..3de1a20dbd 100644
--- a/tools/dtoc/dtb_platdata.py
+++ b/tools/dtoc/dtb_platdata.py
@@ -242,6 +242,64 @@ class DtbPlatdata(object):
 self._valid_nodes = []
 return self.scan_node(self._fdt.GetRoot())
 
+@staticmethod
+def get_num_cells(node):
+"""Get the number of cells in addresses and sizes for this node
+
+Args:
+node: Node to check
+
+Returns:
+Tuple:
+Number of address cells for this node
+Number of size cells for this node
+"""
+parent = node.parent
+na, ns = 2, 2
+if parent:
+na_prop = parent.props.get('#address-cells')
+ns_prop = parent.props.get('#size-cells')
+if na_prop:
+na = fdt_util.fdt32_to_cpu(na_prop.value)
+if ns_prop:
+ns = fdt_util.fdt32_to_cpu(ns_prop.value)
+return na, ns
+
+def scan_reg_sizes(self):
+"""Scan for 64-bit 'reg' properties and update the values
+
+This finds 'reg' properties with 64-bit data and converts the value to
+an array of 64-values. This allows it to be output in a way that the
+C code can read.
+"""
+for node in self._valid_nodes:
+reg = node.props.get('reg')
+if not reg:
+continue
+na, ns = self.get_num_cells(node)
+total = na + ns
+
+if reg.type != fdt.TYPE_INT:
+raise ValueError("Node '%s' reg property is not an int")
+if len(reg.value) % total:
+raise ValueError("Node '%s' reg property has %d cells "
+'which is not a multiple of na + ns = %d + %d)' %
+(node.name, len(reg.value), na, ns))
+reg.na = na
+reg.ns = ns
+if na != 1 or ns != 1:
+reg.type = fdt.TYPE_INT64
+i = 0
+new_value = []
+val = reg.value
+while i < len(val):
+addr = fdt_util.fdt_cells_to_cpu(val[i:], reg.na)
+i += na
+size = fdt_util.fdt_cells_to_cpu(val[i:], reg.ns)
+i += ns
+new_value += [addr, size]
+reg.value = new_value
+
 def scan_structs(self):
 """Scan the device tree building up the C structures we will use.
 
@@ -445,6 +503,7 @@ def run_steps(args, dtb_file, include_disabled, output):
 plat = DtbPlatdata(dtb_file, include_disabled)
 plat.scan_dtb()
 plat.scan_tree()
+plat.scan_reg_sizes()
 plat.setup_output(output)
 structs = plat.scan_structs()
 plat.scan_phandles()
diff --git a/tools/dtoc/dtoc_test_addr32.dts b/tools/dtoc/dtoc_test_addr32.dts
new file mode 100644
index 00..bcfdcae10b
--- /dev/null
+++ b/tools/dtoc/dtoc_test_addr32.dts
@@ -0,0 +1,27 @@
+/*
+ * Test device tree file for dtoc
+ *
+ * Copyright 2017 Google, Inc
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+ /dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+
+   test1 {
+   u-boot,dm-pre-reloc;
+   compatible = "test1";
+   reg = <0x1234 0x5678>;
+   };
+
+   test2 {
+   u-boot,dm-pre-reloc;
+   compatible = "test2";
+   reg = <0x12345678 0x98765432 2 3>;
+   };
+
+};
diff --git a/tools/dtoc/dtoc_test_addr32_64.dts 
b/tools/dtoc/dtoc_test_addr32_64.dts
new file mode 100644
index 00..1c96243310
--- /dev/null
+++ b/tools/dtoc/dtoc_test_addr32_64.dts
@@ -0,0 +1,33 @@
+/*
+ * Test device tree file for dtoc
+ *
+ * Copyright 2017 

[U-Boot] [PATCH 0/3] dtoc: Add support for 64-bit addresses

[Simon Glass]

This series updates dtoc to support 64-bit addresses automatically. These
appear in C code as fdt64_t arrays:

struct dtd_test1 {
fdt64_t reg[2];

};

static struct dtd_test1 dtv_test1 = {
.reg= {0x1234, 0x5678},
};

C code can then process these address and size parents easily. This
feature is controlled by the #address-cells and #size-cells values of the
parent.


Simon Glass (3):
  dtoc: Adjust Node to record its parent
  dtoc: Add a 64-bit type and a way to convert cells into 64 bits
  dtoc: Add support for 32 or 64-bit addresses

 tools/dtoc/dtb_platdata.py |  62 +++
 tools/dtoc/dtoc_test_addr32.dts|  27 +
 tools/dtoc/dtoc_test_addr32_64.dts |  33 ++
 tools/dtoc/dtoc_test_addr64.dts|  33 ++
 tools/dtoc/dtoc_test_addr64_32.dts |  33 ++
 tools/dtoc/fdt.py  |  14 +--
 tools/dtoc/fdt_util.py |  14 +++
 tools/dtoc/test_dtoc.py| 212 +
 8 files changed, 422 insertions(+), 6 deletions(-)
 create mode 100644 tools/dtoc/dtoc_test_addr32.dts
 create mode 100644 tools/dtoc/dtoc_test_addr32_64.dts
 create mode 100644 tools/dtoc/dtoc_test_addr64.dts
 create mode 100644 tools/dtoc/dtoc_test_addr64_32.dts

-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 1/3] dtoc: Adjust Node to record its parent

[Simon Glass]

We need to be able to search back up the tree for #address-cells and
 #size-cells. Record the parent of each node to make this easier.

Signed-off-by: Simon Glass 
---

 tools/dtoc/fdt.py | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/tools/dtoc/fdt.py b/tools/dtoc/fdt.py
index 63a32ea2d7..49409a62ec 100644
--- a/tools/dtoc/fdt.py
+++ b/tools/dtoc/fdt.py
@@ -174,8 +174,9 @@ class Node:
 props: A dict of properties for this node, each a Prop object.
 Keyed by property name
 """
-def __init__(self, fdt, offset, name, path):
+def __init__(self, fdt, parent, offset, name, path):
 self._fdt = fdt
+self.parent = parent
 self._offset = offset
 self.name = name
 self.path = path
@@ -217,7 +218,7 @@ class Node:
 sep = '' if self.path[-1] == '/' else '/'
 name = self._fdt._fdt_obj.get_name(offset)
 path = self.path + sep + name
-node = Node(self._fdt, offset, name, path)
+node = Node(self._fdt, self, offset, name, path)
 self.subnodes.append(node)
 
 node.Scan()
@@ -279,7 +280,7 @@ class Fdt:
 
 TODO(s...@chromium.org): Implement the 'root' parameter
 """
-self._root = self.Node(self, 0, '/', '/')
+self._root = self.Node(self, None, 0, '/', '/')
 self._root.Scan()
 
 def GetRoot(self):
@@ -386,7 +387,7 @@ class Fdt:
 return libfdt.fdt_off_dt_struct(self._fdt) + offset
 
 @classmethod
-def Node(self, fdt, offset, name, path):
+def Node(self, fdt, parent, offset, name, path):
 """Create a new node
 
 This is used by Fdt.Scan() to create a new node using the correct
@@ -394,11 +395,12 @@ class Fdt:
 
 Args:
 fdt: Fdt object
+parent: Parent node, or None if this is the root node
 offset: Offset of node
 name: Node name
 path: Full path to node
 """
-node = Node(fdt, offset, name, path)
+node = Node(fdt, parent, offset, name, path)
 return node
 
 def FdtScan(fname):
-- 
2.13.1.518.g3df882009-goog

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

Re: [U-Boot] [PATCH v5 04/11] usb: host: xhci-rockchip: use fixed regulator to control vbus

[Simon Glass]

On 19 June 2017 at 04:15, Marek Vasut  wrote:
> On 06/19/2017 11:50 AM, rock-chips(daniel.meng) wrote:
>>
>>
>> On 2017/6/18 13:11, Marek Vasut wrote:
>>> On 06/18/2017 12:10 AM, Simon Glass wrote:
 Hi Marek,

 On 17 June 2017 at 13:33, Marek Vasut  wrote:
> On 06/17/2017 07:28 PM, Simon Glass wrote:
>> Hi Marek,
>>
>> On 17 June 2017 at 00:22, Marek Vasut  wrote:
>>> On 06/17/2017 05:41 AM, Simon Glass wrote:
 Hi Marek,

 On 15 June 2017 at 10:53, Marek Vasut  wrote:
> On 06/15/2017 05:51 AM, rock-chips(daniel.meng) wrote:
>>
>> On 2017/6/13 17:11, Marek Vasut wrote:
>>> On 06/12/2017 11:19 AM, Meng Dongyang wrote:
 Use fixed regulator to control the voltage of vbus and turn off
 vbus when usb stop.

 Signed-off-by: Meng Dongyang 
 ---

 Changes in v5:
 - Propagate return value and print error message when failed

 Changes in v4:
 - Splited from patch [Uboot,v3,04/10]
 - Define set vbus as empty function if the macros aren't set

 Changes in v3: None
 Changes in v2:
 - Use fixed regulator to control vbus instead of gpio

 drivers/usb/host/xhci-rockchip.c | 55
 ++--
 1 file changed, 42 insertions(+), 13 deletions(-)

 diff --git a/drivers/usb/host/xhci-rockchip.c
 b/drivers/usb/host/xhci-rockchip.c
 index f559830..15df6ef 100644
 --- a/drivers/usb/host/xhci-rockchip.c
 +++ b/drivers/usb/host/xhci-rockchip.c
 @@ -11,10 +11,10 @@
 #include 
 #include 
 #include 
 -#include 
 #include 
 #include 
 #include 
 +#include 
 #include "xhci.h"
 @@ -23,7 +23,7 @@ DECLARE_GLOBAL_DATA_PTR;
 struct rockchip_xhci_platdata {
 fdt_addr_t hcd_base;
 fdt_addr_t phy_base;
 - struct gpio_desc vbus_gpio;
 + struct udevice *vbus_supply;
 };
 /*
 @@ -48,7 +48,7 @@ static int xhci_usb_ofdata_to_platdata(struct
 udevice *dev)
 */
 plat->hcd_base = dev_get_addr(dev);
 if (plat->hcd_base == FDT_ADDR_T_NONE) {
 - debug("Can't get the XHCI register base address\n");
 + error("Can't get the XHCI register base address\n");
 return -ENXIO;
 }
 @@ -62,19 +62,39 @@ static int
 xhci_usb_ofdata_to_platdata(struct
 udevice *dev)
 }
 if (plat->phy_base == FDT_ADDR_T_NONE) {
 - debug("Can't get the usbphy register address\n");
 + error("Can't get the usbphy register address\n");
 return -ENXIO;
 }
 - /* Vbus gpio */
 - ret = gpio_request_by_name(dev, "rockchip,vbus-gpio", 0,
 - >vbus_gpio, GPIOD_IS_OUT);
 +#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR)
>>> I don't think you need the CONFIG_DM_USB , the driver depends
>>> on it (or
>>> should) already anyway.
>> Yes, I will remove it in v6.
 + /* Vbus regulator */
 + ret = device_get_supply_regulator(dev, "vbus-supply",
 + >vbus_supply);
>>> So I was curious, does this expand to empty function or is
>>> this not
>>> defined if CONFIG_DM_REGULATOR is not defined ?
>> This is not defined if CONFIG_DM_REGULATOR is not defined.
> Simon, can you comment on this ?
 It looks OK to me.
>>> Shouldn't you have empty stub functions instead to avoid
>>> proliferation
>>> of adhoc #ifdef CONFIG_FOO throughout the codebase ?
>> You could, but this is just a temporary state while apparently some
>> rockchip boards don't use DM_USB and DM_REGULATOR. I'm not sure what
>> those bad boards are, actually.
> Temporary state ? What's the final state then ?
 Well I wasn't aware that any rockchip boards didn't use regulators.
 Presumably this #ifdef is because of a board that does not.
>>> This is IMO unrelated to rockchip.
>>>
> Anyway, what if you just disable regulator support (because you don't
> need it for whatever reason), but want to keep USB ? Wouldn't it make
> more sense to have empty stub functions instead of swamping the
drivers
> with ifdefs ?
 USB would not work without VBUS, which is handled with regulators
>>> The VBUS can be directly tied to 5V rail without power switching.
>>>
 , so
 there is something I don't understand here. 

Re: [U-Boot] [PATCH 3/3] cmd: scsi: Fix null pointer dereference in 'scsi reset'

[Simon Glass]

On 17 June 2017 at 07:36, Bin Meng  wrote:
> During 'scsi reset', scsi_bus_reset() is called with udevice pointed
> to NULL, which causes exception. As a temporary fix, disable the call
> for DM SCSI for now.
>
> Signed-off-by: Bin Meng 
> ---
>
> cmd/scsi.c | 2 ++
> 1 file changed, 2 insertions(+)

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

Re: [U-Boot] [PATCH v2 1/3] rockchip: video: mipi: Add rk3288 soc specific driver for mipi dsi

[Simon Glass]

On 19 June 2017 at 00:19, Eric Gao  wrote:
> Add rk3288 soc specific driver for mipi dsi.
>
> Signed-off-by: Eric Gao 
>
> ---
>
> Changes in v1:
> -Change function name from rk_display_enable to rk_mipi_enable.
> -Use IS_ERR to judge the return status.
> -Use dev_read_addr to replace devfdt_get_addr.
>
> drivers/video/rockchip/rk3288_mipi.c | 191
+++
> 1 file changed, 191 insertions(+)
> create mode 100644 drivers/video/rockchip/rk3288_mipi.c
>

Reviewed-by: Simon Glass 

I would expect a warning comparing a pointer to FDT_ADDR_T_NONE, but
presumably you would have seen it if it happened.

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

Re: [U-Boot] [PATCH 2/3] dm: ahci: Avoid scsi_scan_dev() in ahci_probe_scsi()

[Simon Glass]

On 17 June 2017 at 07:35, Bin Meng  wrote:
> Running 'scsi scan' command causes scsi_scan_dev() to be called,
> from which device_probe() is called and consequently AHCI driver
> probe routine will be called as SCSI driver's parent, and finally
> ahci_probe_scsi() calls scsi_scan_dev() again.
>
> Remove the call to scsi_scan_dev() in ahci_probe_scsi().
>
> Signed-off-by: Bin Meng 
> ---
>
> drivers/ata/ahci.c | 5 -
> 1 file changed, 5 deletions(-)

I just sent a similar patch but anyway I agree this is a good idea.

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

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

[Tom Rini]

On Fri, Jun 16, 2017 at 09:54:47PM +0530, Jagan Teki wrote:

> Hi Tom,
> 
> Please pull this PR.
> 
> thanks!
> Jagan.
> 
> The following changes since commit 24796d27be0d0f403ed6ad7e3022b33e36ac08b5:
> 
>   Merge git://git.denx.de/u-boot-ubi (2017-06-06 07:13:39 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-sunxi.git master
> 
> for you to fetch changes up to 2b1a33213e810f43f9d7e33b9d8db99e1b80a1c0:
> 
>   sun50i: h5: Add initial NanoPi NEO2 support (2017-06-14 20:25:56 +0530)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Tom Rini]

On Sun, Jun 18, 2017 at 09:46:39PM +0200, Marek Vasut wrote:

> The following changes since commit b9f7d8817424bb328d5eac9b16196a1189b8b6f5:
> 
>   powerpc, 5xx: remove some "5xx" remains (2017-06-16 10:14:56 -0400)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-usb.git master
> 
> for you to fetch changes up to b9203429a04402bd03c48fa87670686ef7e7891d:
> 
>   cmd: usb_mass_storage: Staticize do_usb_mass_storage() (2017-06-18
> 21:11:10 +0200)
> 

Applied to u-boot/master, thanks!

-- 
Tom


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

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

[Jagan Teki]

On Fri, Jun 16, 2017 at 9:54 PM, Jagan Teki  wrote:
> Hi Tom,
>
> Please pull this PR.
>
> thanks!
> Jagan.
>
> The following changes since commit 24796d27be0d0f403ed6ad7e3022b33e36ac08b5:
>
>   Merge git://git.denx.de/u-boot-ubi (2017-06-06 07:13:39 -0400)
>
> are available in the git repository at:
>
>   git://git.denx.de/u-boot-sunxi.git master
>
> for you to fetch changes up to 2b1a33213e810f43f9d7e33b9d8db99e1b80a1c0:
>
>   sun50i: h5: Add initial NanoPi NEO2 support (2017-06-14 20:25:56 +0530)
>
> 
> Chen-Yu Tsai (1):
>   sunxi: psci: Move entry address setting to separate function
>
> Icenowy Zheng (12):
>   sunxi: makes an invisible option for H3-like DRAM controllers
>   sunxi: Rename bus-width related macros in H3 DRAM code
>   sunxi: add option for 16-bit DW DRAM controller
>   sunxi: add bank detection code to H3 DRAM initialization code
>   sunxi: Add selective DRAM type and timing
>   sunxi: enable dual rank detection in DesignWare-like DRAM code
>   sunxi: add support for the DDR2 in V3s SoC
>   sunxi: add support for V3s DRAM controller
>   sunxi: enable DRAM initialization and SPL for V3s SoC
>   sunxi: add LPDDR3 DRAM type support for DesignWare-like DRAM controller
>   sunxi: add LPDDR3 timing from stock boot0
>   sunxi: add a defconfig for SoPine w/ official baseboard
>
> Jagan Teki (4):
>   sun8i: h3: Add initial NanoPi M1 Plus support
>   sun50i: h5: Add initial Orangepi Zero Plus 2 support
>   sun50i: a64: Add initial Orangepi Win/WinPlus support
>   sun50i: h5: Add initial NanoPi NEO2 support

Ping!

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

[U-Boot] [ANN] U-Boot v2017.07-rc2 released

[Tom Rini]

Hey all,

It's release day and v2017.07-rc2 is out.  I'm mostly happy with the
size of the changes here and I did remember to sync the defconfigs prior
to tagging.

If anyone has critical fixes I've missed or some Kconfig migrations
(that I can prove out as correct), please speak up.

Things look on track for -rc3 on July 3rd and release on July 10th.
Thanks all!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/2] MIPS: Stop building position independent code

[Paul Burton]

Hi Daniel,

On Monday, 19 June 2017 12:48:12 PDT Daniel Schwierzeck wrote:
> Am 19.06.2017 um 20:53 schrieb Paul Burton:
> > Hi Daniel,
> > 
> > On Friday, 16 June 2017 15:48:06 PDT Daniel Schwierzeck wrote:
> >> Am 16.06.2017 um 02:05 schrieb Paul Burton:
> >>> U-Boot has up until now built with -fpic for the MIPS architecture,
> >>> producing position independent code which uses indirection through a
> >>> global offset table, making relocation fairly straightforward as it
> >>> simply involves patching up GOT entries.
> >>> 
> >>> Using -fpic does however have some downsides. The biggest of these is
> >>> that generated code is bloated in various ways. For example, function
> >>> 
> >>> calls are indirected through the GOT & the t9 register:
> >>>   8f998064   lw t9,-32668(gp)
> >>>   0320f809   jalr   t9
> >>> 
> >>> Without -fpic the call is simply:
> >>>   0f803f01   jalbe00fc04 
> >>> 
> >>> This is more compact & faster (due to the lack of the load & the
> >>> dependency the jump has on its result). It is also easier to read &
> >>> debug because the disassembly shows what function is being called,
> >>> rather than just an offset from gp which would then have to be looked up
> >>> in the ELF to discover the target function.
> >>> 
> >>> Another disadvantage of -fpic is that each function begins with a
> >>> 
> >>> sequence to calculate the value of the gp register, for example:
> >>>   3c1c0004   luigp,0x4
> >>>   279c3384   addiu  gp,gp,13188
> >>>   0399e021   addu   gp,gp,t9
> >>> 
> >>> Without using -fpic this sequence no longer appears at the start of each
> >>> function, reducing code size considerably.
> >>> 
> >>> This patch switches U-Boot from building with -fpic to building with
> >>> -fno-pic, in order to gain the benefits described above. The cost of
> >>> this is an extra step during the build process to extract relocation
> >>> data from the ELF & write it into a new .rel section in a compact
> >>> format, plus the added complexity of dealing with multiple types of
> >>> relocation rather than the single type that applied to the GOT. The
> >>> benefit is smaller, cleaner, more debuggable code. The relocate_code()
> >>> function is reimplemented in C to handle the new relocation scheme,
> >>> which also makes it easier to read & debug.
> >>> 
> >>> Taking maltael_defconfig as an example the size of u-boot.bin built
> >>> using the Codescape MIPS 2016.05-06 toolchain (gcc 4.9.2, binutils
> >>> 2.24.90) shrinks from 254KiB to 224KiB.
> >>> 
> >>> Signed-off-by: Paul Burton 
> >>> Cc: Daniel Schwierzeck 
> >>> Cc: u-boot@lists.denx.de
> >>> ---
> >>> 
> >>>  arch/mips/Makefile.postlink|  23 +++
> >>>  arch/mips/config.mk|  19 +-
> >>>  arch/mips/cpu/start.S  | 130 -
> >>>  arch/mips/cpu/u-boot.lds   |  41 +---
> >>>  arch/mips/include/asm/relocs.h |  24 +++
> >>>  arch/mips/lib/Makefile |   1 +
> >>>  arch/mips/lib/reloc.c  | 164 
> >>>  common/board_f.c   |   2 +-
> >>>  tools/.gitignore   |   1 +
> >>>  tools/Makefile |   2 +
> >>>  tools/mips-relocs.c| 426
> >>>  + 11 files changed, 656
> >>>  insertions(+), 177 deletions(-)
> >>>  create mode 100644 arch/mips/Makefile.postlink
> >>>  create mode 100644 arch/mips/include/asm/relocs.h
> >>>  create mode 100644 arch/mips/lib/reloc.c
> >>>  create mode 100644 tools/mips-relocs.c
> >> 
> >> there is a regression on qemu_mips when started with Qemu. The code
> >> execution hangs in an endless loop and doesn't reach the console prompt.
> >> 
> >> I could debug it to following location:
> >> 
> >> int bootm_find_images(int flag, int argc, char * const argv[])
> >> {
> >> 
> >>int ret;
> >>
> >>/* find ramdisk */
> >>ret = boot_get_ramdisk(argc, argv, , IH_INITRD_ARCH,
> >>
> >>   _start, _end);
> >>
> >>if (ret) {
> >>
> >>puts("Ramdisk image is corrupt or invalid\n");
> >>return 1;
> >>
> >>}
> >>
> >> ...
> >> 
> >> }
> >> 
> >> The code flow goes into the "if (ret)" branch. At the "return 1" the $ra
> >> register contains the address of bootm_find_images(). Thus the code is
> >> executed in an endless loop. I don't know yet if that's a miscalculated
> >> relocation or a stack overflow (maybe due to the changed 64KiB alignment
> >> of the U-Boot relocation address) because $ra in bootm_find_images() is
> >> loaded from stack:
> >> 
> >> bfc08f1c :
> >> bfc08f1c:  3c02bfc3lui v0,0xbfc3
> >> bfc08f20:  27bdffe0addiu   sp,sp,-32
> >> ...
> >> bfc08f6c:  8fbf001clw  ra,28(sp)
> >> bfc08f70:  00601025movev0,v1
> >> bfc08f74:  03e8jr  ra
> >> bfc08f78:  27bd0020addiu   sp,sp,32
> >> 
> >> 
> >> This regression leads to broken pytest for qemu_mips and 

Re: [U-Boot] [PATCH 2/2] MIPS: Stop building position independent code

[Daniel Schwierzeck]

Am 19.06.2017 um 20:53 schrieb Paul Burton:
> Hi Daniel,
> 
> On Friday, 16 June 2017 15:48:06 PDT Daniel Schwierzeck wrote:
>> Am 16.06.2017 um 02:05 schrieb Paul Burton:
>>> U-Boot has up until now built with -fpic for the MIPS architecture,
>>> producing position independent code which uses indirection through a
>>> global offset table, making relocation fairly straightforward as it
>>> simply involves patching up GOT entries.
>>>
>>> Using -fpic does however have some downsides. The biggest of these is
>>> that generated code is bloated in various ways. For example, function
>>>
>>> calls are indirected through the GOT & the t9 register:
>>>   8f998064   lw t9,-32668(gp)
>>>   0320f809   jalr   t9
>>>
>>> Without -fpic the call is simply:
>>>   0f803f01   jalbe00fc04 
>>>
>>> This is more compact & faster (due to the lack of the load & the
>>> dependency the jump has on its result). It is also easier to read &
>>> debug because the disassembly shows what function is being called,
>>> rather than just an offset from gp which would then have to be looked up
>>> in the ELF to discover the target function.
>>>
>>> Another disadvantage of -fpic is that each function begins with a
>>>
>>> sequence to calculate the value of the gp register, for example:
>>>   3c1c0004   luigp,0x4
>>>   279c3384   addiu  gp,gp,13188
>>>   0399e021   addu   gp,gp,t9
>>>
>>> Without using -fpic this sequence no longer appears at the start of each
>>> function, reducing code size considerably.
>>>
>>> This patch switches U-Boot from building with -fpic to building with
>>> -fno-pic, in order to gain the benefits described above. The cost of
>>> this is an extra step during the build process to extract relocation
>>> data from the ELF & write it into a new .rel section in a compact
>>> format, plus the added complexity of dealing with multiple types of
>>> relocation rather than the single type that applied to the GOT. The
>>> benefit is smaller, cleaner, more debuggable code. The relocate_code()
>>> function is reimplemented in C to handle the new relocation scheme,
>>> which also makes it easier to read & debug.
>>>
>>> Taking maltael_defconfig as an example the size of u-boot.bin built
>>> using the Codescape MIPS 2016.05-06 toolchain (gcc 4.9.2, binutils
>>> 2.24.90) shrinks from 254KiB to 224KiB.
>>>
>>> Signed-off-by: Paul Burton 
>>> Cc: Daniel Schwierzeck 
>>> Cc: u-boot@lists.denx.de
>>> ---
>>>
>>>  arch/mips/Makefile.postlink|  23 +++
>>>  arch/mips/config.mk|  19 +-
>>>  arch/mips/cpu/start.S  | 130 -
>>>  arch/mips/cpu/u-boot.lds   |  41 +---
>>>  arch/mips/include/asm/relocs.h |  24 +++
>>>  arch/mips/lib/Makefile |   1 +
>>>  arch/mips/lib/reloc.c  | 164 
>>>  common/board_f.c   |   2 +-
>>>  tools/.gitignore   |   1 +
>>>  tools/Makefile |   2 +
>>>  tools/mips-relocs.c| 426
>>>  + 11 files changed, 656
>>>  insertions(+), 177 deletions(-)
>>>  create mode 100644 arch/mips/Makefile.postlink
>>>  create mode 100644 arch/mips/include/asm/relocs.h
>>>  create mode 100644 arch/mips/lib/reloc.c
>>>  create mode 100644 tools/mips-relocs.c
>>
>> there is a regression on qemu_mips when started with Qemu. The code
>> execution hangs in an endless loop and doesn't reach the console prompt.
>>
>> I could debug it to following location:
>>
>> int bootm_find_images(int flag, int argc, char * const argv[])
>> {
>>  int ret;
>>
>>  /* find ramdisk */
>>  ret = boot_get_ramdisk(argc, argv, , IH_INITRD_ARCH,
>> _start, _end);
>>  if (ret) {
>>  puts("Ramdisk image is corrupt or invalid\n");
>>  return 1;
>>  }
>> ...
>> }
>>
>> The code flow goes into the "if (ret)" branch. At the "return 1" the $ra
>> register contains the address of bootm_find_images(). Thus the code is
>> executed in an endless loop. I don't know yet if that's a miscalculated
>> relocation or a stack overflow (maybe due to the changed 64KiB alignment
>> of the U-Boot relocation address) because $ra in bootm_find_images() is
>> loaded from stack:
>>
>> bfc08f1c :
>> bfc08f1c:3c02bfc3lui v0,0xbfc3
>> bfc08f20:27bdffe0addiu   sp,sp,-32
>> ...
>> bfc08f6c:8fbf001clw  ra,28(sp)
>> bfc08f70:00601025movev0,v1
>> bfc08f74:03e8jr  ra
>> bfc08f78:27bd0020addiu   sp,sp,32
>>
>>
>> This regression leads to broken pytest for qemu_mips and therefore to
>> failing Travis CI [1]. I used the kernel.org MIPS toolchain with gcc-4.9
>> (same as in Travis CI). Could you please have a look?
>>
>>
>> [1] https://travis-ci.org/danielschwierzeck/u-boot/jobs/243667863
> 
> This was due to an R_MIPS_26 relocation applied to a j instruction in 
> show_board_info, which overflowed into the opcode 

Re: [U-Boot] Use u-boot to recover bricked NVIDIA SHIELD TV.

[Matthew Gorski]

On Mon, Jun 19, 2017 at 11:53 AM, Stephen Warren 
wrote:

> On 06/18/2017 04:46 PM, Matthew Gorski wrote:
>
>> I am curious if there is a possibility to recover a wrongly flashed
>> NVIDIA SHIELD TV device by flashing u-boot instead of cboot and mounting
>> the emmc in uboot to do some repairs.
>>
>
> The NVIDIA SHIELD TV is a production Android device, and hence I'm pretty
> sure it has boot security enabled. This security also applies to the USB
> recovery mode protocol, so I don't believe you'll be able to communicate
> with the device unless you know the system's keys, which I assume you don't.


> There is some support for flashing generic upstream Linux onto the NVIDIA
> SHIELD tablet, but I believe that relies on  making (at least some of) the
> modifications from a running system, so if your system isn't booting, I
> don't expect this will work either. Just in case it's useful, see:
>
> https://github.com/linux-shield


Here is a thought I would gladly give anyone that has access to the needed
device keys access to my build system and they could shell in and wget the
private key to flash and then delete (my last ditch effort at a hail mary
recovery)
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 2/2] MIPS: Stop building position independent code

[Paul Burton]

U-Boot has up until now built with -fpic for the MIPS architecture,
producing position independent code which uses indirection through a
global offset table, making relocation fairly straightforward as it
simply involves patching up GOT entries.

Using -fpic does however have some downsides. The biggest of these is
that generated code is bloated in various ways. For example, function
calls are indirected through the GOT & the t9 register:

  8f998064   lw t9,-32668(gp)
  0320f809   jalr   t9

Without -fpic the call is simply:

  0f803f01   jalbe00fc04 

This is more compact & faster (due to the lack of the load & the
dependency the jump has on its result). It is also easier to read &
debug because the disassembly shows what function is being called,
rather than just an offset from gp which would then have to be looked up
in the ELF to discover the target function.

Another disadvantage of -fpic is that each function begins with a
sequence to calculate the value of the gp register, for example:

  3c1c0004   luigp,0x4
  279c3384   addiu  gp,gp,13188
  0399e021   addu   gp,gp,t9

Without using -fpic this sequence no longer appears at the start of each
function, reducing code size considerably.

This patch switches U-Boot from building with -fpic to building with
-fno-pic, in order to gain the benefits described above. The cost of
this is an extra step during the build process to extract relocation
data from the ELF & write it into a new .rel section in a compact
format, plus the added complexity of dealing with multiple types of
relocation rather than the single type that applied to the GOT. The
benefit is smaller, cleaner, more debuggable code. The relocate_code()
function is reimplemented in C to handle the new relocation scheme,
which also makes it easier to read & debug.

Taking maltael_defconfig as an example the size of u-boot.bin built
using the Codescape MIPS 2016.05-06 toolchain (gcc 4.9.2, binutils
2.24.90) shrinks from 254KiB to 224KiB.

Signed-off-by: Paul Burton 
Cc: Daniel Schwierzeck 
Cc: u-boot@lists.denx.de

---

Changes in v3:
- Fix R_MIPS_26 case that was breaking qemu_mips_defconfig.

Changes in v2:
- Drop unused .$@.relocs from Makefile.postlink.
- Remove PF_OBJCOPY & assign to OBJCOPYFLAGS directly in config.mk.
- Move declaration of __rel_start to asm/sections.h.

 arch/mips/Makefile.postlink  |  23 +++
 arch/mips/config.mk  |  21 +-
 arch/mips/cpu/start.S| 130 
 arch/mips/cpu/u-boot.lds |  41 +---
 arch/mips/include/asm/relocs.h   |  24 +++
 arch/mips/include/asm/sections.h |   7 +
 arch/mips/lib/Makefile   |   1 +
 arch/mips/lib/reloc.c| 164 +++
 common/board_f.c |   2 +-
 tools/.gitignore |   1 +
 tools/Makefile   |   2 +
 tools/mips-relocs.c  | 426 +++
 12 files changed, 663 insertions(+), 179 deletions(-)
 create mode 100644 arch/mips/Makefile.postlink
 create mode 100644 arch/mips/include/asm/relocs.h
 create mode 100644 arch/mips/lib/reloc.c
 create mode 100644 tools/mips-relocs.c

diff --git a/arch/mips/Makefile.postlink b/arch/mips/Makefile.postlink
new file mode 100644
index 00..7da3acdf52
--- /dev/null
+++ b/arch/mips/Makefile.postlink
@@ -0,0 +1,23 @@
+#
+# Copyright (c) 2017 Imagination Technologies Ltd.
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+PHONY := __archpost
+__archpost:
+
+-include include/config/auto.conf
+include scripts/Kbuild.include
+
+CMD_RELOCS = tools/mips-relocs
+quiet_cmd_relocs = RELOCS  $@
+  cmd_relocs = $(CMD_RELOCS) $@
+
+u-boot: FORCE
+   @true
+   $(call if_changed,relocs)
+
+.PHONY: FORCE
+
+FORCE:
diff --git a/arch/mips/config.mk b/arch/mips/config.mk
index 2c72c1553d..cefdbe65e1 100644
--- a/arch/mips/config.mk
+++ b/arch/mips/config.mk
@@ -56,25 +56,14 @@ PLATFORM_ELFFLAGS += -B mips $(OBJCOPYFLAGS)
 # LDFLAGS_vmlinux  += -G 0 -static -n -nostdlib
 # MODFLAGS += -mlong-calls
 #
-# On the other hand, we want PIC in the U-Boot code to relocate it from ROM
-# to RAM. $28 is always used as gp.
-#
-ifdef CONFIG_SPL_BUILD
-PF_ABICALLS:= -mno-abicalls
-PF_PIC := -fno-pic
-PF_PIE :=
-else
-PF_ABICALLS:= -mabicalls
-PF_PIC := -fpic
-PF_PIE := -pie
-PF_OBJCOPY := -j .got -j .rel.dyn -j .padding
-PF_OBJCOPY += -j .dtb.init.rodata
+ifndef CONFIG_SPL_BUILD
+OBJCOPYFLAGS   += -j .got -j .rel -j .padding -j 
.dtb.init.rodata
+LDFLAGS_FINAL  += --emit-relocs
 endif
 
-PLATFORM_CPPFLAGS  += -G 0 $(PF_ABICALLS) $(PF_PIC)
+PLATFORM_CPPFLAGS  += -G 0 -mno-abicalls -fno-pic
 PLATFORM_CPPFLAGS  += -msoft-float
 PLATFORM_LDFLAGS   

Re: [U-Boot] [PATCH 2/2] MIPS: Stop building position independent code

[Paul Burton]

Hi Daniel,

On Friday, 16 June 2017 15:48:06 PDT Daniel Schwierzeck wrote:
> Am 16.06.2017 um 02:05 schrieb Paul Burton:
> > U-Boot has up until now built with -fpic for the MIPS architecture,
> > producing position independent code which uses indirection through a
> > global offset table, making relocation fairly straightforward as it
> > simply involves patching up GOT entries.
> > 
> > Using -fpic does however have some downsides. The biggest of these is
> > that generated code is bloated in various ways. For example, function
> > 
> > calls are indirected through the GOT & the t9 register:
> >   8f998064   lw t9,-32668(gp)
> >   0320f809   jalr   t9
> > 
> > Without -fpic the call is simply:
> >   0f803f01   jalbe00fc04 
> > 
> > This is more compact & faster (due to the lack of the load & the
> > dependency the jump has on its result). It is also easier to read &
> > debug because the disassembly shows what function is being called,
> > rather than just an offset from gp which would then have to be looked up
> > in the ELF to discover the target function.
> > 
> > Another disadvantage of -fpic is that each function begins with a
> > 
> > sequence to calculate the value of the gp register, for example:
> >   3c1c0004   luigp,0x4
> >   279c3384   addiu  gp,gp,13188
> >   0399e021   addu   gp,gp,t9
> > 
> > Without using -fpic this sequence no longer appears at the start of each
> > function, reducing code size considerably.
> > 
> > This patch switches U-Boot from building with -fpic to building with
> > -fno-pic, in order to gain the benefits described above. The cost of
> > this is an extra step during the build process to extract relocation
> > data from the ELF & write it into a new .rel section in a compact
> > format, plus the added complexity of dealing with multiple types of
> > relocation rather than the single type that applied to the GOT. The
> > benefit is smaller, cleaner, more debuggable code. The relocate_code()
> > function is reimplemented in C to handle the new relocation scheme,
> > which also makes it easier to read & debug.
> > 
> > Taking maltael_defconfig as an example the size of u-boot.bin built
> > using the Codescape MIPS 2016.05-06 toolchain (gcc 4.9.2, binutils
> > 2.24.90) shrinks from 254KiB to 224KiB.
> > 
> > Signed-off-by: Paul Burton 
> > Cc: Daniel Schwierzeck 
> > Cc: u-boot@lists.denx.de
> > ---
> > 
> >  arch/mips/Makefile.postlink|  23 +++
> >  arch/mips/config.mk|  19 +-
> >  arch/mips/cpu/start.S  | 130 -
> >  arch/mips/cpu/u-boot.lds   |  41 +---
> >  arch/mips/include/asm/relocs.h |  24 +++
> >  arch/mips/lib/Makefile |   1 +
> >  arch/mips/lib/reloc.c  | 164 
> >  common/board_f.c   |   2 +-
> >  tools/.gitignore   |   1 +
> >  tools/Makefile |   2 +
> >  tools/mips-relocs.c| 426
> >  + 11 files changed, 656
> >  insertions(+), 177 deletions(-)
> >  create mode 100644 arch/mips/Makefile.postlink
> >  create mode 100644 arch/mips/include/asm/relocs.h
> >  create mode 100644 arch/mips/lib/reloc.c
> >  create mode 100644 tools/mips-relocs.c
> 
> there is a regression on qemu_mips when started with Qemu. The code
> execution hangs in an endless loop and doesn't reach the console prompt.
> 
> I could debug it to following location:
> 
> int bootm_find_images(int flag, int argc, char * const argv[])
> {
>   int ret;
> 
>   /* find ramdisk */
>   ret = boot_get_ramdisk(argc, argv, , IH_INITRD_ARCH,
>  _start, _end);
>   if (ret) {
>   puts("Ramdisk image is corrupt or invalid\n");
>   return 1;
>   }
> ...
> }
> 
> The code flow goes into the "if (ret)" branch. At the "return 1" the $ra
> register contains the address of bootm_find_images(). Thus the code is
> executed in an endless loop. I don't know yet if that's a miscalculated
> relocation or a stack overflow (maybe due to the changed 64KiB alignment
> of the U-Boot relocation address) because $ra in bootm_find_images() is
> loaded from stack:
> 
> bfc08f1c :
> bfc08f1c: 3c02bfc3lui v0,0xbfc3
> bfc08f20: 27bdffe0addiu   sp,sp,-32
> ...
> bfc08f6c: 8fbf001clw  ra,28(sp)
> bfc08f70: 00601025movev0,v1
> bfc08f74: 03e8jr  ra
> bfc08f78: 27bd0020addiu   sp,sp,32
> 
> 
> This regression leads to broken pytest for qemu_mips and therefore to
> failing Travis CI [1]. I used the kernel.org MIPS toolchain with gcc-4.9
> (same as in Travis CI). Could you please have a look?
> 
> 
> [1] https://travis-ci.org/danielschwierzeck/u-boot/jobs/243667863

This was due to an R_MIPS_26 relocation applied to a j instruction in 
show_board_info, which overflowed into the opcode field & changed the j into a 
jal.

v3 should fix it.

Thanks,

Re: [U-Boot] Use u-boot to recover bricked NVIDIA SHIELD TV.

[Matthew Gorski]

On Mon, Jun 19, 2017 at 12:22 PM, Matthew Gorski 
wrote:

>
>
> On Mon, Jun 19, 2017 at 11:53 AM, Stephen Warren 
> wrote:
>
>> On 06/18/2017 04:46 PM, Matthew Gorski wrote:
>>
>>> I am curious if there is a possibility to recover a wrongly flashed
>>> NVIDIA SHIELD TV device by flashing u-boot instead of cboot and mounting
>>> the emmc in uboot to do some repairs.
>>>
>>
>> The NVIDIA SHIELD TV is a production Android device, and hence I'm pretty
>> sure it has boot security enabled. This security also applies to the USB
>> recovery mode protocol, so I don't believe you'll be able to communicate
>> with the device unless you know the system's keys, which I assume you don't.
>>
>> There is some support for flashing generic upstream Linux onto the NVIDIA
>> SHIELD tablet, but I believe that relies on  making (at least some of) the
>> modifications from a running system, so if your system isn't booting, I
>> don't expect this will work either. Just in case it's useful, see:
>>
>> https://github.com/linux-shield
>>
>
> Thanks for chiming in Simon and Stephen.  I appreciate you both taking the
> time out of your busy day to answer. I figured the boot security was
> preventing communication to the USB recovery mode protocol.  I tried
> tegrarcm just to see if I could read the bct and no go.  Seems this happens
> quite a bit and there is no way to recover and NVIDIA will not do any
> repairs after the warranty expiration date.  Would have been nice if
> fastboot could have recognized I used the wrong package :/  Maybe a crc
> check to see if the system images match up to the correct device.
>
> Is there anyway to determine what mode I am currently in with tegrarcm
> (assuming I can even get communication)?
>
> Operating Mode:  0x3 (developer mode)
>
>
> Simon the soldering solution sounds interesting.  If someone can elaborate
> on that just for reference that would be great.  Ive always wanted UART on
> foster.  Thanks again guys for your input.  I'll try a few tricks just to
> see what happens and report back.
>
>
>
>
>
> Okay definitely locked down, no communication with APX USB recovery device
in production mode. Error: Return value 3 = No communication with USB
device (even if APX is recognized in linux):

tegrasign --key None --list rcm_list.xml --pubkeyhash pub_key.key
Assuming zero filled SBK key

[1467528.418181] usb 2-1.3: Product: APX
[1467528.418185] usb 2-1.3: Manufacturer: NVIDIA Corp.

sudo ./tegraflash.py --bl cboot.bin --applet nvtboot_recovery.bin --chip
0x21 --cmd "write USP blob"

Welcome to Tegra Flash
version 1.0.0
Type ? or help for help and q or quit to exit
Use ! to execute system commands

[   0.0655 ] Generating RCM messages
[   0.0803 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm
nvtboot_recovery.bin 0 0
[   0.0819 ] RCM 0 is saved as rcm_0.rcm
[   0.0951 ] RCM 1 is saved as rcm_1.rcm
[   0.0952 ] List of rcm files are saved in rcm_list.xml
[   0.0952 ]
[   0.0952 ] Signing RCM messages
[   0.1080 ] tegrasign --key None --list rcm_list.xml --pubkeyhash
pub_key.key
[   0.1097 ] Assuming zero filled SBK key
[   0.1301 ]
[   0.1302 ] Copying signature to RCM mesages
[   0.1318 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml
[   0.1484 ]
[   0.1484 ] Boot Rom communication
[   0.1500 ] tegrarcm --chip 0x21 --rcm rcm_list_signed.xml
[   0.1515 ] BR_CID: 0x621010015c656186180010fd8140
[   0.1526 ] RCM version 0X13
[   0.1526 ] Boot Rom communication failed
[   0.1526 ]
Error: Return value 3
Command tegrarcm --chip 0x21 --rcm rcm_list_signed.xml
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 03/14] fdt: Correct fdt_get_base_address()

[Simon Glass]

This function appears to obtain the value of the 'ranges' property rather
than 'reg'. As such it does not behave as documented or expected.

In addition it picks up the second field of the property which is the size
(with prop += naddr) rather than the first which is the address.

Fix it.

Signed-off-by: Simon Glass 
---

 common/fdt_support.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/common/fdt_support.c b/common/fdt_support.c
index dfdc04dfba..605fa79b27 100644
--- a/common/fdt_support.c
+++ b/common/fdt_support.c
@@ -1542,14 +1542,11 @@ int fdt_verify_alias_address(void *fdt, int anode, 
const char *alias, u64 addr)
 u64 fdt_get_base_address(const void *fdt, int node)
 {
int size;
-   u32 naddr;
const fdt32_t *prop;
 
-   naddr = fdt_address_cells(fdt, node);
+   prop = fdt_getprop(fdt, node, "reg", );
 
-   prop = fdt_getprop(fdt, node, "ranges", );
-
-   return prop ? fdt_translate_address(fdt, node, prop + naddr) : 0;
+   return prop ? fdt_translate_address(fdt, node, prop) : 0;
 }
 
 /*
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 09/14] dm: mmc: sunxi: Drop mmc_clk_io_on()

[Simon Glass]

This function has #ifdefs in it which we want to avoid for driver model.
Instead we should use different compatible strings and the .data field.
It also uses the MMC device number which is not available in driver
model except through aliases.

Move the function's into its caller so that the driver-model version can
do things its own way.

Signed-off-by: Simon Glass 
---

 drivers/mmc/sunxi_mmc.c | 42 ++
 1 file changed, 18 insertions(+), 24 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index bd41fbb752..23bef94f24 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -153,29 +153,6 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, 
unsigned int hz)
return 0;
 }
 
-static int mmc_clk_io_on(int sdc_no)
-{
-   struct sunxi_mmc_priv *priv = _host[sdc_no];
-   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
-
-   debug("init mmc %d clock and io\n", sdc_no);
-
-   /* config ahb clock */
-   setbits_le32(>ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
-
-#ifdef CONFIG_SUNXI_GEN_SUN6I
-   /* unassert reset */
-   setbits_le32(>ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_MMC(sdc_no));
-#endif
-#if defined(CONFIG_MACH_SUN9I)
-   /* sun9i has a mmc-common module, also set the gate and reset there */
-   writel(SUNXI_MMC_COMMON_CLK_GATE | SUNXI_MMC_COMMON_RESET,
-  SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
-#endif
-
-   return mmc_set_mod_clk(priv, 2400);
-}
-
 static int mmc_update_clk(struct sunxi_mmc_priv *priv)
 {
unsigned int cmd;
@@ -467,8 +444,10 @@ static const struct mmc_ops sunxi_mmc_ops = {
 
 struct mmc *sunxi_mmc_init(int sdc_no)
 {
+   struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
struct sunxi_mmc_priv *priv = _host[sdc_no];
struct mmc_config *cfg = >cfg;
+   int ret;
 
memset(priv, '\0', sizeof(struct sunxi_mmc_priv));
 
@@ -490,7 +469,22 @@ struct mmc *sunxi_mmc_init(int sdc_no)
if (mmc_resource_init(sdc_no) != 0)
return NULL;
 
-   mmc_clk_io_on(sdc_no);
+   /* config ahb clock */
+   debug("init mmc %d clock and io\n", sdc_no);
+   setbits_le32(>ahb_gate0, 1 << AHB_GATE_OFFSET_MMC(sdc_no));
+
+#ifdef CONFIG_SUNXI_GEN_SUN6I
+   /* unassert reset */
+   setbits_le32(>ahb_reset0_cfg, 1 << AHB_RESET_OFFSET_MMC(sdc_no));
+#endif
+#if defined(CONFIG_MACH_SUN9I)
+   /* sun9i has a mmc-common module, also set the gate and reset there */
+   writel(SUNXI_MMC_COMMON_CLK_GATE | SUNXI_MMC_COMMON_RESET,
+  SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
+#endif
+   ret = mmc_set_mod_clk(priv, 2400);
+   if (ret)
+   return NULL;
 
return mmc_create(cfg, mmc_host);
 }
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 12/14] dm: sunxi: sata: Don't build sata support into SPL

[Simon Glass]

This is not used in SPL so we do not need to compile it. Make this change
before adding driver-model support to the driver, to avoid build errors.
With driver model we define a U_BOOT_DRIVER() which would otherwise be
present in SPL and not be garbage-collected when building.

Signed-off-by: Simon Glass 
---

 board/sunxi/Makefile | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 43766e0ef4..f4411f01c3 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -10,7 +10,9 @@
 #
 obj-y  += board.o
 obj-$(CONFIG_SUNXI_GMAC)   += gmac.o
+ifndef CONFIG_SPL_BUILD
 obj-$(CONFIG_SUNXI_AHCI)   += ahci.o
+endif
 obj-$(CONFIG_MACH_SUN4I)   += dram_sun4i_auto.o
 obj-$(CONFIG_MACH_SUN5I)   += dram_sun5i_auto.o
 obj-$(CONFIG_MACH_SUN7I)   += dram_sun5i_auto.o
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 10/14] dm: mmc: sunxi: Add support for driver model

[Simon Glass]

Add a driver-model version of this driver which mostly uses the existing
code. The old code can be removed once all boards are switched over.

Signed-off-by: Simon Glass 
---

 drivers/mmc/sunxi_mmc.c | 134 
 1 file changed, 134 insertions(+)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 23bef94f24..8886e351f0 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -9,6 +9,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -19,14 +20,21 @@
 #include 
 #include 
 
+struct sunxi_mmc_plat {
+   struct mmc_config cfg;
+   struct mmc mmc;
+};
+
 struct sunxi_mmc_priv {
unsigned mmc_no;
uint32_t *mclkreg;
unsigned fatal_err;
+   struct gpio_desc cd_gpio;   /* Change Detect GPIO */
struct sunxi_mmc *reg;
struct mmc_config cfg;
 };
 
+#if !CONFIG_IS_ENABLED(DM_MMC)
 /* support 4 mmc hosts */
 struct sunxi_mmc_priv mmc_host[4];
 
@@ -83,6 +91,7 @@ static int mmc_resource_init(int sdc_no)
 
return ret;
 }
+#endif
 
 static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
 {
@@ -224,6 +233,7 @@ static int sunxi_mmc_set_ios_common(struct sunxi_mmc_priv 
*priv,
return 0;
 }
 
+#if !CONFIG_IS_ENABLED(DM_MMC)
 static int sunxi_mmc_core_init(struct mmc *mmc)
 {
struct sunxi_mmc_priv *priv = mmc->priv;
@@ -234,6 +244,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
 
return 0;
 }
+#endif
 
 static int mmc_trans_data_by_cpu(struct sunxi_mmc_priv *priv, struct mmc *mmc,
 struct mmc_data *data)
@@ -408,6 +419,7 @@ out:
return error;
 }
 
+#if !CONFIG_IS_ENABLED(DM_MMC)
 static int sunxi_mmc_set_ios_legacy(struct mmc *mmc)
 {
struct sunxi_mmc_priv *priv = mmc->priv;
@@ -488,3 +500,125 @@ struct mmc *sunxi_mmc_init(int sdc_no)
 
return mmc_create(cfg, mmc_host);
 }
+#else
+
+static int sunxi_mmc_set_ios(struct udevice *dev)
+{
+   struct sunxi_mmc_plat *plat = dev_get_platdata(dev);
+   struct sunxi_mmc_priv *priv = dev_get_priv(dev);
+
+   return sunxi_mmc_set_ios_common(priv, >mmc);
+}
+
+static int sunxi_mmc_send_cmd(struct udevice *dev, struct mmc_cmd *cmd,
+ struct mmc_data *data)
+{
+   struct sunxi_mmc_plat *plat = dev_get_platdata(dev);
+   struct sunxi_mmc_priv *priv = dev_get_priv(dev);
+
+   return sunxi_mmc_send_cmd_common(priv, >mmc, cmd, data);
+}
+
+static int sunxi_mmc_getcd(struct udevice *dev)
+{
+   struct sunxi_mmc_priv *priv = dev_get_priv(dev);
+
+   if (dm_gpio_is_valid(>cd_gpio))
+   return dm_gpio_get_value(>cd_gpio);
+
+   return 1;
+}
+
+static const struct dm_mmc_ops sunxi_mmc_ops = {
+   .send_cmd   = sunxi_mmc_send_cmd,
+   .set_ios= sunxi_mmc_set_ios,
+   .get_cd = sunxi_mmc_getcd,
+};
+
+static int sunxi_mmc_probe(struct udevice *dev)
+{
+   struct mmc_uclass_priv *upriv = dev_get_uclass_priv(dev);
+   struct sunxi_mmc_plat *plat = dev_get_platdata(dev);
+   struct sunxi_mmc_priv *priv = dev_get_priv(dev);
+   struct mmc_config *cfg = >cfg;
+   struct ofnode_phandle_args args;
+   u32 *gate_reg;
+   int bus_width, ret;
+
+   cfg->name = dev->name;
+   bus_width = dev_read_u32_default(dev, "bus-width", 1);
+
+   cfg->voltages = MMC_VDD_32_33 | MMC_VDD_33_34;
+   cfg->host_caps = 0;
+   if (bus_width == 8)
+   cfg->host_caps |= MMC_MODE_8BIT;
+   if (bus_width >= 4)
+   cfg->host_caps |= MMC_MODE_4BIT;
+   cfg->host_caps |= MMC_MODE_HS_52MHz | MMC_MODE_HS;
+   cfg->b_max = CONFIG_SYS_MMC_MAX_BLK_COUNT;
+
+   cfg->f_min = 40;
+   cfg->f_max = 5200;
+
+   priv->reg = (void *)dev_read_addr(dev);
+
+   /* We don't have a sunxi clock driver so find the clock address here */
+   ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
+ 1, );
+   if (ret)
+   return ret;
+   priv->mclkreg = (u32 *)ofnode_get_addr(args.node);
+
+   ret = dev_read_phandle_with_args(dev, "clocks", "#clock-cells", 0,
+ 0, );
+   if (ret)
+   return ret;
+   gate_reg = (u32 *)ofnode_get_addr(args.node);
+   setbits_le32(gate_reg, 1 << args.args[0]);
+   priv->mmc_no = args.args[0] - 8;
+
+   ret = mmc_set_mod_clk(priv, 2400);
+   if (ret)
+   return ret;
+
+   /* This GPIO is optional */
+   if (!gpio_request_by_name(dev, "cd-gpios", 0, >cd_gpio,
+ GPIOD_IS_IN)) {
+   int cd_pin = gpio_get_number(>cd_gpio);
+
+   printf("cd_pin = %d\n", cd_pin);
+   sunxi_gpio_set_pull(cd_pin, SUNXI_GPIO_PULL_UP);
+   }
+
+   upriv->mmc = >mmc;
+
+   /* Reset controller */
+   

[U-Boot] [PATCH 14/14] dm: sunxi: Move Linksprite_pcDuino3 to use DM for MMC, SATA

[Simon Glass]

Move this board over to driver model for MMC and SATA. This means that it
uses CONFIG_BLK as well. In SPL these options remain turned off since it
increases the code size. One option would be to use CONFIG_SPL_OF_PLATDATA
to avoid device-tree overhead.

Signed-off-by: Simon Glass 
---

 arch/arm/dts/sun7i-a20-pcduino3.dts   | 1 -
 configs/Linksprite_pcDuino3_defconfig | 7 ++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/dts/sun7i-a20-pcduino3.dts 
b/arch/arm/dts/sun7i-a20-pcduino3.dts
index 1a8b39be1d..d487c84562 100644
--- a/arch/arm/dts/sun7i-a20-pcduino3.dts
+++ b/arch/arm/dts/sun7i-a20-pcduino3.dts
@@ -164,7 +164,6 @@
pinctrl-0 = <_pins_a>, <_cd_pin_reference_design>;
vmmc-supply = <_vcc3v3>;
bus-width = <4>;
-   cd-gpios = < 7 1 GPIO_ACTIVE_HIGH>; /* PH1 */
cd-inverted;
status = "okay";
 };
diff --git a/configs/Linksprite_pcDuino3_defconfig 
b/configs/Linksprite_pcDuino3_defconfig
index 6f4a02f8d4..f0d382c002 100644
--- a/configs/Linksprite_pcDuino3_defconfig
+++ b/configs/Linksprite_pcDuino3_defconfig
@@ -15,7 +15,12 @@ CONFIG_SPL_I2C_SUPPORT=y
 # CONFIG_SPL_DOS_PARTITION is not set
 # CONFIG_SPL_ISO_PARTITION is not set
 # CONFIG_SPL_EFI_PARTITION is not set
-CONFIG_SCSI=y
+# CONFIG_SPL_BLK is not set
+CONFIG_DM_MMC=y
+# CONFIG_SPL_DM_MMC is not set
+# CONFIG_SPL_DM_MMC_OPS is not set
 CONFIG_ETH_DESIGNWARE=y
 CONFIG_SUN7I_GMAC=y
+CONFIG_SCSI=y
+CONFIG_DM_SCSI=y
 CONFIG_USB_EHCI_HCD=y
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 13/14] dm: sata: sunxi: Add support for driver model

[Simon Glass]

Adjust SATA setup to support driver model.

Signed-off-by: Simon Glass 
---

 board/sunxi/ahci.c | 61 +++---
 1 file changed, 58 insertions(+), 3 deletions(-)

diff --git a/board/sunxi/ahci.c b/board/sunxi/ahci.c
index 522e54ab16..a79b80ca1e 100644
--- a/board/sunxi/ahci.c
+++ b/board/sunxi/ahci.c
@@ -1,5 +1,6 @@
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -13,9 +14,8 @@
 /* This magic PHY initialisation was taken from the Allwinner releases
  * and Linux driver, but is completely undocumented.
  */
-static int sunxi_ahci_phy_init(u32 base)
+static int sunxi_ahci_phy_init(u8 *reg_base)
 {
-   u8 *reg_base = (u8 *)base;
u32 reg_val;
int timeout;
 
@@ -70,10 +70,65 @@ static int sunxi_ahci_phy_init(u32 base)
return 0;
 }
 
+#ifndef CONFIG_DM_SCSI
 void scsi_init(void)
 {
-   if (sunxi_ahci_phy_init(SUNXI_SATA_BASE) < 0)
+   if (sunxi_ahci_phy_init((u8 *)SUNXI_SATA_BASE) < 0)
return;
 
ahci_init((void __iomem *)SUNXI_SATA_BASE);
 }
+#else
+static int sunxi_sata_probe(struct udevice *dev)
+{
+   ulong base;
+   u8 *reg;
+   int ret;
+
+   base = dev_read_addr(dev);
+   if (base == FDT_ADDR_T_NONE) {
+   debug("%s: Failed to find address (err=%d\n)", __func__, ret);
+   return -EINVAL;
+   }
+   reg = (u8 *)base;
+   ret = sunxi_ahci_phy_init(reg);
+   if (ret) {
+   debug("%s: Failed to init phy (err=%d\n)", __func__, ret);
+   return ret;
+   }
+   ret = ahci_probe_scsi(dev, base);
+   if (ret) {
+   debug("%s: Failed to probe (err=%d\n)", __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int sunxi_sata_bind(struct udevice *dev)
+{
+   struct udevice *scsi_dev;
+   int ret;
+
+   ret = ahci_bind_scsi(dev, _dev);
+   if (ret) {
+   debug("%s: Failed to bind (err=%d\n)", __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct udevice_id sunxi_ahci_ids[] = {
+   { .compatible = "allwinner,sun4i-a10-ahci" },
+   { }
+};
+
+U_BOOT_DRIVER(ahci_sunxi_drv) = {
+   .name   = "ahci_sunxi",
+   .id = UCLASS_AHCI,
+   .of_match   = sunxi_ahci_ids,
+   .bind   = sunxi_sata_bind,
+   .probe  = sunxi_sata_probe,
+};
+#endif
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 11/14] dm: scsi: Don't scan the SCSI bus when probing

[Simon Glass]

The 'scsi scan' function handles this at present and we don't want to
do it twice. With driver model we want to adopt U-Boot's lazy init
approach where possible.

Drop the automatic scan when probing a SCSI bus.

Signed-off-by: Simon Glass 
---

 drivers/ata/ahci.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 066524758a..5e4df19386 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1181,11 +1181,6 @@ int ahci_probe_scsi(struct udevice *ahci_dev, ulong base)
if (ret)
return ret;
 
-   debug("Scanning %s\n", dev->name);
-   ret = scsi_scan_dev(dev, true);
-   if (ret)
-   return ret;
-
return 0;
 }
 
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 08/14] dm: mmc: sunxi: Pass private data around explicitly

[Simon Glass]

At present the driver-private data is obtained in various functions by
various means. With driver model this is provided automatically. Without
driver model it comes from a C array declared at the top of the file.

Adjust internal functions so that they are passed the private data as
a parameter, allowing the caller to obtain it using either means.

Signed-off-by: Simon Glass 
---

 drivers/mmc/sunxi_mmc.c | 71 +
 1 file changed, 42 insertions(+), 29 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index 9276a29d76..bd41fbb752 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -176,9 +176,8 @@ static int mmc_clk_io_on(int sdc_no)
return mmc_set_mod_clk(priv, 2400);
 }
 
-static int mmc_update_clk(struct mmc *mmc)
+static int mmc_update_clk(struct sunxi_mmc_priv *priv)
 {
-   struct sunxi_mmc_priv *priv = mmc->priv;
unsigned int cmd;
unsigned timeout_msecs = 2000;
 
@@ -198,15 +197,14 @@ static int mmc_update_clk(struct mmc *mmc)
return 0;
 }
 
-static int mmc_config_clock(struct mmc *mmc)
+static int mmc_config_clock(struct sunxi_mmc_priv *priv, struct mmc *mmc)
 {
-   struct sunxi_mmc_priv *priv = mmc->priv;
unsigned rval = readl(>reg->clkcr);
 
/* Disable Clock */
rval &= ~SUNXI_MMC_CLK_ENABLE;
writel(rval, >reg->clkcr);
-   if (mmc_update_clk(mmc))
+   if (mmc_update_clk(priv))
return -1;
 
/* Set mod_clk to new rate */
@@ -220,21 +218,20 @@ static int mmc_config_clock(struct mmc *mmc)
/* Re-enable Clock */
rval |= SUNXI_MMC_CLK_ENABLE;
writel(rval, >reg->clkcr);
-   if (mmc_update_clk(mmc))
+   if (mmc_update_clk(priv))
return -1;
 
return 0;
 }
 
-static int sunxi_mmc_set_ios(struct mmc *mmc)
+static int sunxi_mmc_set_ios_common(struct sunxi_mmc_priv *priv,
+   struct mmc *mmc)
 {
-   struct sunxi_mmc_priv *priv = mmc->priv;
-
debug("set ios: bus_width: %x, clock: %d\n",
  mmc->bus_width, mmc->clock);
 
/* Change clock first */
-   if (mmc->clock && mmc_config_clock(mmc) != 0) {
+   if (mmc->clock && mmc_config_clock(priv, mmc) != 0) {
priv->fatal_err = 1;
return -EINVAL;
}
@@ -261,9 +258,9 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
return 0;
 }
 
-static int mmc_trans_data_by_cpu(struct mmc *mmc, struct mmc_data *data)
+static int mmc_trans_data_by_cpu(struct sunxi_mmc_priv *priv, struct mmc *mmc,
+struct mmc_data *data)
 {
-   struct sunxi_mmc_priv *priv = mmc->priv;
const int reading = !!(data->flags & MMC_DATA_READ);
const uint32_t status_bit = reading ? SUNXI_MMC_STATUS_FIFO_EMPTY :
  SUNXI_MMC_STATUS_FIFO_FULL;
@@ -293,10 +290,9 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct 
mmc_data *data)
return 0;
 }
 
-static int mmc_rint_wait(struct mmc *mmc, unsigned int timeout_msecs,
-unsigned int done_bit, const char *what)
+static int mmc_rint_wait(struct sunxi_mmc_priv *priv, struct mmc *mmc,
+uint timeout_msecs, uint done_bit, const char *what)
 {
-   struct sunxi_mmc_priv *priv = mmc->priv;
unsigned int status;
 
do {
@@ -313,10 +309,10 @@ static int mmc_rint_wait(struct mmc *mmc, unsigned int 
timeout_msecs,
return 0;
 }
 
-static int sunxi_mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
- struct mmc_data *data)
+static int sunxi_mmc_send_cmd_common(struct sunxi_mmc_priv *priv,
+struct mmc *mmc, struct mmc_cmd *cmd,
+struct mmc_data *data)
 {
-   struct sunxi_mmc_priv *priv = mmc->priv;
unsigned int cmdval = SUNXI_MMC_CMD_START;
unsigned int timeout_msecs;
int error = 0;
@@ -372,7 +368,7 @@ static int sunxi_mmc_send_cmd(struct mmc *mmc, struct 
mmc_cmd *cmd,
bytecnt = data->blocksize * data->blocks;
debug("trans data %d bytes\n", bytecnt);
writel(cmdval | cmd->cmdidx, >reg->cmd);
-   ret = mmc_trans_data_by_cpu(mmc, data);
+   ret = mmc_trans_data_by_cpu(priv, mmc, data);
if (ret) {
error = readl(>reg->rint) &
SUNXI_MMC_RINT_INTERRUPT_ERROR_BIT;
@@ -381,14 +377,15 @@ static int sunxi_mmc_send_cmd(struct mmc *mmc, struct 
mmc_cmd *cmd,
}
}
 
-   error = mmc_rint_wait(mmc, 1000, SUNXI_MMC_RINT_COMMAND_DONE, "cmd");
+   error = mmc_rint_wait(priv, mmc, 1000, SUNXI_MMC_RINT_COMMAND_DONE,
+ "cmd");
if (error)
goto out;
 
if (data) {

[U-Boot] [PATCH 07/14] dm: mmc: sunxi: Rename mmchost to priv

[Simon Glass]

Use the driver-model naming convention for this structure. It is data
private to the driver so the local variable should be called 'priv'.

Signed-off-by: Simon Glass 
---

 drivers/mmc/sunxi_mmc.c | 125 
 1 file changed, 62 insertions(+), 63 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index e30db015ef..9276a29d76 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -43,7 +43,7 @@ static int sunxi_mmc_getcd_gpio(int sdc_no)
 
 static int mmc_resource_init(int sdc_no)
 {
-   struct sunxi_mmc_priv *mmchost = _host[sdc_no];
+   struct sunxi_mmc_priv *priv = _host[sdc_no];
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
int cd_pin, ret = 0;
 
@@ -51,26 +51,26 @@ static int mmc_resource_init(int sdc_no)
 
switch (sdc_no) {
case 0:
-   mmchost->reg = (struct sunxi_mmc *)SUNXI_MMC0_BASE;
-   mmchost->mclkreg = >sd0_clk_cfg;
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC0_BASE;
+   priv->mclkreg = >sd0_clk_cfg;
break;
case 1:
-   mmchost->reg = (struct sunxi_mmc *)SUNXI_MMC1_BASE;
-   mmchost->mclkreg = >sd1_clk_cfg;
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC1_BASE;
+   priv->mclkreg = >sd1_clk_cfg;
break;
case 2:
-   mmchost->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
-   mmchost->mclkreg = >sd2_clk_cfg;
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC2_BASE;
+   priv->mclkreg = >sd2_clk_cfg;
break;
case 3:
-   mmchost->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
-   mmchost->mclkreg = >sd3_clk_cfg;
+   priv->reg = (struct sunxi_mmc *)SUNXI_MMC3_BASE;
+   priv->mclkreg = >sd3_clk_cfg;
break;
default:
printf("Wrong mmc number %d\n", sdc_no);
return -1;
}
-   mmchost->mmc_no = sdc_no;
+   priv->mmc_no = sdc_no;
 
cd_pin = sunxi_mmc_getcd_gpio(sdc_no);
if (cd_pin >= 0) {
@@ -84,7 +84,7 @@ static int mmc_resource_init(int sdc_no)
return ret;
 }
 
-static int mmc_set_mod_clk(struct sunxi_mmc_priv *mmchost, unsigned int hz)
+static int mmc_set_mod_clk(struct sunxi_mmc_priv *priv, unsigned int hz)
 {
unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
 
@@ -112,8 +112,8 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv *mmchost, 
unsigned int hz)
}
 
if (n > 3) {
-   printf("mmc %u error cannot set clock to %u\n",
-  mmchost->mmc_no, hz);
+   printf("mmc %u error cannot set clock to %u\n", priv->mmc_no,
+  hz);
return -1;
}
 
@@ -145,18 +145,17 @@ static int mmc_set_mod_clk(struct sunxi_mmc_priv 
*mmchost, unsigned int hz)
 
writel(CCM_MMC_CTRL_ENABLE | pll | CCM_MMC_CTRL_SCLK_DLY(sclk_dly) |
   CCM_MMC_CTRL_N(n) | CCM_MMC_CTRL_OCLK_DLY(oclk_dly) |
-  CCM_MMC_CTRL_M(div), mmchost->mclkreg);
+  CCM_MMC_CTRL_M(div), priv->mclkreg);
 
debug("mmc %u set mod-clk req %u parent %u n %u m %u rate %u\n",
- mmchost->mmc_no, hz, pll_hz, 1u << n, div,
- pll_hz / (1u << n) / div);
+ priv->mmc_no, hz, pll_hz, 1u << n, div, pll_hz / (1u << n) / div);
 
return 0;
 }
 
 static int mmc_clk_io_on(int sdc_no)
 {
-   struct sunxi_mmc_priv *mmchost = _host[sdc_no];
+   struct sunxi_mmc_priv *priv = _host[sdc_no];
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
debug("init mmc %d clock and io\n", sdc_no);
@@ -174,53 +173,53 @@ static int mmc_clk_io_on(int sdc_no)
   SUNXI_MMC_COMMON_BASE + 4 * sdc_no);
 #endif
 
-   return mmc_set_mod_clk(mmchost, 2400);
+   return mmc_set_mod_clk(priv, 2400);
 }
 
 static int mmc_update_clk(struct mmc *mmc)
 {
-   struct sunxi_mmc_priv *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *priv = mmc->priv;
unsigned int cmd;
unsigned timeout_msecs = 2000;
 
cmd = SUNXI_MMC_CMD_START |
  SUNXI_MMC_CMD_UPCLK_ONLY |
  SUNXI_MMC_CMD_WAIT_PRE_OVER;
-   writel(cmd, >reg->cmd);
-   while (readl(>reg->cmd) & SUNXI_MMC_CMD_START) {
+   writel(cmd, >reg->cmd);
+   while (readl(>reg->cmd) & SUNXI_MMC_CMD_START) {
if (!timeout_msecs--)
return -1;
udelay(1000);
}
 
/* clock update sets various irq status bits, clear these */
-   writel(readl(>reg->rint), >reg->rint);
+   writel(readl(>reg->rint), >reg->rint);
 
return 0;
 }
 
 static int mmc_config_clock(struct mmc *mmc)
 {
-   struct sunxi_mmc_priv *mmchost = mmc->priv;
-   unsigned rval = 

[U-Boot] [PATCH 05/14] dm: ahci: Correct uclass private data

[Simon Glass]

This is expected to be attached to the uclass and the code operates that
way, but the uclass has not been updated. Fix it to avoid using memory at
address 0.

Signed-off-by: Simon Glass 
Fixes: 47fc61a (dm: ahci: Drop use of probe_ent)
---

 drivers/ata/ahci-uclass.c | 2 ++
 drivers/ata/ahci.c| 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/ata/ahci-uclass.c b/drivers/ata/ahci-uclass.c
index 7b8c32699f..71600fed68 100644
--- a/drivers/ata/ahci-uclass.c
+++ b/drivers/ata/ahci-uclass.c
@@ -6,9 +6,11 @@
  */
 
 #include 
+#include 
 #include 
 
 UCLASS_DRIVER(ahci) = {
.id = UCLASS_AHCI,
.name   = "ahci",
+   .per_device_auto_alloc_size = sizeof(struct ahci_uc_priv),
 };
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 035db85b45..066524758a 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -935,7 +935,7 @@ static int ahci_scsi_exec(struct udevice *dev, struct 
scsi_cmd *pccb)
 {
struct ahci_uc_priv *uc_priv;
 #ifdef CONFIG_DM_SCSI
-   uc_priv = dev_get_uclass_priv(dev);
+   uc_priv = dev_get_uclass_priv(dev->parent);
 #else
uc_priv = probe_ent;
 #endif
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 06/14] dm: mmc: sunxi: Rename struct sunxi_mmc_host to sunxi_mmc_priv

[Simon Glass]

Use the driver-model naming convention for this structure. It is data
private to the driver.

Signed-off-by: Simon Glass 
---

 drivers/mmc/sunxi_mmc.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/mmc/sunxi_mmc.c b/drivers/mmc/sunxi_mmc.c
index fd3fc2af40..e30db015ef 100644
--- a/drivers/mmc/sunxi_mmc.c
+++ b/drivers/mmc/sunxi_mmc.c
@@ -19,7 +19,7 @@
 #include 
 #include 
 
-struct sunxi_mmc_host {
+struct sunxi_mmc_priv {
unsigned mmc_no;
uint32_t *mclkreg;
unsigned fatal_err;
@@ -28,7 +28,7 @@ struct sunxi_mmc_host {
 };
 
 /* support 4 mmc hosts */
-struct sunxi_mmc_host mmc_host[4];
+struct sunxi_mmc_priv mmc_host[4];
 
 static int sunxi_mmc_getcd_gpio(int sdc_no)
 {
@@ -43,7 +43,7 @@ static int sunxi_mmc_getcd_gpio(int sdc_no)
 
 static int mmc_resource_init(int sdc_no)
 {
-   struct sunxi_mmc_host *mmchost = _host[sdc_no];
+   struct sunxi_mmc_priv *mmchost = _host[sdc_no];
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
int cd_pin, ret = 0;
 
@@ -84,7 +84,7 @@ static int mmc_resource_init(int sdc_no)
return ret;
 }
 
-static int mmc_set_mod_clk(struct sunxi_mmc_host *mmchost, unsigned int hz)
+static int mmc_set_mod_clk(struct sunxi_mmc_priv *mmchost, unsigned int hz)
 {
unsigned int pll, pll_hz, div, n, oclk_dly, sclk_dly;
 
@@ -156,7 +156,7 @@ static int mmc_set_mod_clk(struct sunxi_mmc_host *mmchost, 
unsigned int hz)
 
 static int mmc_clk_io_on(int sdc_no)
 {
-   struct sunxi_mmc_host *mmchost = _host[sdc_no];
+   struct sunxi_mmc_priv *mmchost = _host[sdc_no];
struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
 
debug("init mmc %d clock and io\n", sdc_no);
@@ -179,7 +179,7 @@ static int mmc_clk_io_on(int sdc_no)
 
 static int mmc_update_clk(struct mmc *mmc)
 {
-   struct sunxi_mmc_host *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *mmchost = mmc->priv;
unsigned int cmd;
unsigned timeout_msecs = 2000;
 
@@ -201,7 +201,7 @@ static int mmc_update_clk(struct mmc *mmc)
 
 static int mmc_config_clock(struct mmc *mmc)
 {
-   struct sunxi_mmc_host *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *mmchost = mmc->priv;
unsigned rval = readl(>reg->clkcr);
 
/* Disable Clock */
@@ -229,7 +229,7 @@ static int mmc_config_clock(struct mmc *mmc)
 
 static int sunxi_mmc_set_ios(struct mmc *mmc)
 {
-   struct sunxi_mmc_host *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *mmchost = mmc->priv;
 
debug("set ios: bus_width: %x, clock: %d\n",
  mmc->bus_width, mmc->clock);
@@ -253,7 +253,7 @@ static int sunxi_mmc_set_ios(struct mmc *mmc)
 
 static int sunxi_mmc_core_init(struct mmc *mmc)
 {
-   struct sunxi_mmc_host *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *mmchost = mmc->priv;
 
/* Reset controller */
writel(SUNXI_MMC_GCTRL_RESET, >reg->gctrl);
@@ -264,7 +264,7 @@ static int sunxi_mmc_core_init(struct mmc *mmc)
 
 static int mmc_trans_data_by_cpu(struct mmc *mmc, struct mmc_data *data)
 {
-   struct sunxi_mmc_host *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *mmchost = mmc->priv;
const int reading = !!(data->flags & MMC_DATA_READ);
const uint32_t status_bit = reading ? SUNXI_MMC_STATUS_FIFO_EMPTY :
  SUNXI_MMC_STATUS_FIFO_FULL;
@@ -297,7 +297,7 @@ static int mmc_trans_data_by_cpu(struct mmc *mmc, struct 
mmc_data *data)
 static int mmc_rint_wait(struct mmc *mmc, unsigned int timeout_msecs,
 unsigned int done_bit, const char *what)
 {
-   struct sunxi_mmc_host *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *mmchost = mmc->priv;
unsigned int status;
 
do {
@@ -317,7 +317,7 @@ static int mmc_rint_wait(struct mmc *mmc, unsigned int 
timeout_msecs,
 static int sunxi_mmc_send_cmd(struct mmc *mmc, struct mmc_cmd *cmd,
  struct mmc_data *data)
 {
-   struct sunxi_mmc_host *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *mmchost = mmc->priv;
unsigned int cmdval = SUNXI_MMC_CMD_START;
unsigned int timeout_msecs;
int error = 0;
@@ -437,7 +437,7 @@ out:
 
 static int sunxi_mmc_getcd(struct mmc *mmc)
 {
-   struct sunxi_mmc_host *mmchost = mmc->priv;
+   struct sunxi_mmc_priv *mmchost = mmc->priv;
int cd_pin;
 
cd_pin = sunxi_mmc_getcd_gpio(mmchost->mmc_no);
@@ -458,7 +458,7 @@ struct mmc *sunxi_mmc_init(int sdc_no)
 {
struct mmc_config *cfg = _host[sdc_no].cfg;
 
-   memset(_host[sdc_no], 0, sizeof(struct sunxi_mmc_host));
+   memset(_host[sdc_no], 0, sizeof(struct sunxi_mmc_priv));
 
cfg->name = "SUNXI SD/MMC";
cfg->ops  = _mmc_ops;
-- 
2.13.1.518.g3df882009-goog

___
U-Boot mailing list
U-Boot@lists.denx.de

[U-Boot] [PATCH 04/14] dm: scsi: Drop duplicate SCSI and DM_SCSI options

[Simon Glass]

When the SATA code was moved into drivers/ata these Kconfig options were
added to that directory. They already exist in drivers/scsi. Remove them
from drivers/ata to fix the duplication.

Signed-off-by: Simon Glass 
Fixes: 7f2b5f4 (sata: Move drivers into new drivers/ata directory)
---

 drivers/ata/Kconfig | 18 --
 1 file changed, 18 deletions(-)

diff --git a/drivers/ata/Kconfig b/drivers/ata/Kconfig
index 6427f1b94a..a1bd12ebe9 100644
--- a/drivers/ata/Kconfig
+++ b/drivers/ata/Kconfig
@@ -20,24 +20,6 @@ config SATA
 
  See also CMD_SATA which provides command-line support.
 
-config SCSI
-   bool "Support SCSI controllers"
-   help
- This enables support for SCSI (Small Computer System Interface),
- a parallel interface widely used with storage peripherals such as
- hard drives and optical drives. The SCSI standards define physical
- interfaces as well as protocols for controlling devices and
- tranferring data.
-
-config DM_SCSI
-   bool "Support SCSI controllers with driver model"
-   depends on BLK
-   help
- This option enables the SCSI (Small Computer System Interface) uclass
- which supports SCSI and SATA HDDs. For every device configuration
- (IDs/LUNs) a block device is created with RAW read/write and
- filesystem support.
-
 menu "SATA/SCSI device support"
 
 config SATA_CEVA
-- 
2.13.1.518.g3df882009-goog

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

[U-Boot] [PATCH 02/14] dm: mmc: Allow disabling driver model in SPL

[Simon Glass]

At present if U-Boot proper uses driver model for MMC, then SPL has to
also. While this is desirable, it places a significant barrier to moving
to driver model in some cases. For example, with a space-constrained SPL
it may be necessary to enable CONFIG_SPL_OF_PLATDATA which involves
adjusting some drivers.

Add new SPL versions of the options for DM_MMC, DM_MMC_OPS and BLK. By
default these follow their non-SPL versions, but this can be changed by
boards which need it.

Signed-off-by: Simon Glass 
---

 common/spl/spl_mmc.c  |  4 ++--
 drivers/block/Kconfig | 12 
 drivers/block/Makefile|  4 ++--
 drivers/mmc/Kconfig   | 21 +
 drivers/mmc/Makefile  |  4 ++--
 drivers/mmc/mmc-uclass.c  |  6 +++---
 drivers/mmc/mmc.c | 28 ++--
 drivers/mmc/mmc_legacy.c  |  2 +-
 drivers/mmc/mmc_private.h |  6 +++---
 drivers/mmc/omap_hsmmc.c  | 20 ++--
 drivers/scsi/scsi.c   |  2 +-
 include/blk.h |  4 ++--
 include/mmc.h | 12 ++--
 13 files changed, 79 insertions(+), 46 deletions(-)

diff --git a/common/spl/spl_mmc.c b/common/spl/spl_mmc.c
index 18c1b59b22..953e484e27 100644
--- a/common/spl/spl_mmc.c
+++ b/common/spl/spl_mmc.c
@@ -115,7 +115,7 @@ int spl_mmc_get_device_index(u32 boot_device)
 
 static int spl_mmc_find_device(struct mmc **mmcp, u32 boot_device)
 {
-#ifdef CONFIG_DM_MMC
+#if CONFIG_IS_ENABLED(DM_MMC)
struct udevice *dev;
 #endif
int err, mmc_dev;
@@ -132,7 +132,7 @@ static int spl_mmc_find_device(struct mmc **mmcp, u32 
boot_device)
return err;
}
 
-#ifdef CONFIG_DM_MMC
+#if CONFIG_IS_ENABLED(DM_MMC)
err = uclass_get_device(UCLASS_MMC, mmc_dev, );
if (!err)
*mmcp = mmc_get_mmc_dev(dev);
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index ca7692d8a5..26760895f9 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -10,6 +10,18 @@ config BLK
  be partitioned into several areas, called 'partitions' in U-Boot.
  A filesystem can be placed in each partition.
 
+config SPL_BLK
+   bool "Support block devices in SPL"
+   depends on SPL_DM && BLK
+   default y
+   help
+ Enable support for block devices, such as SCSI, MMC and USB
+ flash sticks. These provide a block-level interface which permits
+ reading, writing and (in some cases) erasing blocks. Block
+ devices often have a partition table which allows the device to
+ be partitioned into several areas, called 'partitions' in U-Boot.
+ A filesystem can be placed in each partition.
+
 config BLOCK_CACHE
bool "Use block device cache"
default n
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index 146c4fe01f..a09a15a30f 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -5,9 +5,9 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
 
-obj-$(CONFIG_BLK) += blk-uclass.o
+obj-$(CONFIG_$(SPL_)BLK) += blk-uclass.o
 
-ifndef CONFIG_BLK
+ifndef CONFIG_$(SPL_)BLK
 obj-y += blk_legacy.o
 endif
 
diff --git a/drivers/mmc/Kconfig b/drivers/mmc/Kconfig
index 82b8d75686..51a87cdd77 100644
--- a/drivers/mmc/Kconfig
+++ b/drivers/mmc/Kconfig
@@ -30,6 +30,27 @@ config DM_MMC_OPS
  option will be removed as soon as all DM_MMC drivers use it, as it
  will the only supported behaviour.
 
+config SPL_DM_MMC
+   bool "Enable MMC controllers using Driver Model in SPL"
+   depends on SPL_DM && DM_MMC
+   default y
+   help
+ This enables the MultiMediaCard (MMC) uclass which supports MMC and
+ Secure Digital I/O (SDIO) cards. Both removable (SD, micro-SD, etc.)
+ and non-removable (e.g. eMMC chip) devices are supported. These
+ appear as block devices in U-Boot and can support filesystems such
+ as EXT4 and FAT.
+
+config SPL_DM_MMC_OPS
+   bool "Support MMC controller operations using Driver Model in SPL"
+   depends on SPL_DM && DM_MMC_OPS
+   default y
+   help
+ Driver model provides a means of supporting device operations. This
+ option moves MMC operations under the control of driver model. The
+ option will be removed as soon as all DM_MMC drivers use it, as it
+ will the only supported behaviour.
+
 if MMC
 
 config SPL_MMC_TINY
diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
index 2d781c38a6..a6becb2309 100644
--- a/drivers/mmc/Makefile
+++ b/drivers/mmc/Makefile
@@ -6,9 +6,9 @@
 #
 
 obj-y += mmc.o
-obj-$(CONFIG_DM_MMC) += mmc-uclass.o
+obj-$(CONFIG_$(SPL_)DM_MMC) += mmc-uclass.o
 
-ifndef CONFIG_BLK
+ifndef CONFIG_$(SPL_)BLK
 obj-y += mmc_legacy.o
 endif
 
diff --git a/drivers/mmc/mmc-uclass.c b/drivers/mmc/mmc-uclass.c
index 994d2686f4..3e907253ea 100644
--- a/drivers/mmc/mmc-uclass.c
+++ b/drivers/mmc/mmc-uclass.c
@@ -15,7 +15,7 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
-#ifdef 

[U-Boot] [PATCH 01/14] ahci: Support non-PCI controllers

[Simon Glass]

At present the AHCI SCSI driver only supports PCI with driver model.
Rename the existing function to indicate this and add support for adding
a non-PCI controller .

Signed-off-by: Simon Glass 
---

 arch/x86/cpu/ivybridge/sata.c |  2 +-
 drivers/ata/ahci.c| 26 +-
 include/ahci.h| 14 +-
 3 files changed, 31 insertions(+), 11 deletions(-)

diff --git a/arch/x86/cpu/ivybridge/sata.c b/arch/x86/cpu/ivybridge/sata.c
index 462b7c09dd..7febb8cf88 100644
--- a/arch/x86/cpu/ivybridge/sata.c
+++ b/arch/x86/cpu/ivybridge/sata.c
@@ -236,7 +236,7 @@ static int bd82x6x_sata_probe(struct udevice *dev)
bd82x6x_sata_enable(dev);
else {
bd82x6x_sata_init(dev, pch);
-   ret = ahci_probe_scsi(dev);
+   ret = ahci_probe_scsi_pci(dev);
if (ret)
return ret;
}
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 6da412d178..035db85b45 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -431,7 +431,7 @@ static void ahci_print_info(struct ahci_uc_priv *uc_priv)
   cap2 & (1 << 0) ? "boh " : "");
 }
 
-#ifndef CONFIG_SCSI_AHCI_PLAT
+#if defined(CONFIG_DM_SCSI) || !defined(CONFIG_SCSI_AHCI_PLAT)
 # if defined(CONFIG_DM_PCI) || defined(CONFIG_DM_SCSI)
 static int ahci_init_one(struct ahci_uc_priv *uc_priv, struct udevice *dev)
 # else
@@ -1158,11 +1158,8 @@ int ahci_bind_scsi(struct udevice *ahci_dev, struct 
udevice **devp)
return 0;
 }
 
-int ahci_probe_scsi(struct udevice *ahci_dev)
+int ahci_probe_scsi(struct udevice *ahci_dev, ulong base)
 {
-#ifdef CONFIG_SCSI_AHCI_PLAT
-   return -ENOSYS;  /* TODO(s...@chromium.org): Support non-PCI AHCI */
-#else
struct ahci_uc_priv *uc_priv;
struct scsi_platdata *uc_plat;
struct udevice *dev;
@@ -1172,11 +1169,11 @@ int ahci_probe_scsi(struct udevice *ahci_dev)
if (!dev)
return -ENODEV;
uc_plat = dev_get_uclass_platdata(dev);
-   uc_plat->base = (ulong)dm_pci_map_bar(ahci_dev, PCI_BASE_ADDRESS_5,
- PCI_REGION_MEM);
+   uc_plat->base = base;
uc_plat->max_lun = 1;
uc_plat->max_id = 2;
-   uc_priv = dev_get_uclass_priv(dev);
+
+   uc_priv = dev_get_uclass_priv(ahci_dev);
ret = ahci_init_one(uc_priv, dev);
if (ret)
return ret;
@@ -1188,11 +1185,22 @@ int ahci_probe_scsi(struct udevice *ahci_dev)
ret = scsi_scan_dev(dev, true);
if (ret)
return ret;
-#endif
 
return 0;
 }
 
+#ifdef CONFIG_DM_PCI
+int ahci_probe_scsi_pci(struct udevice *ahci_dev)
+{
+   ulong base;
+
+   base = (ulong)dm_pci_map_bar(ahci_dev, PCI_BASE_ADDRESS_5,
+PCI_REGION_MEM);
+
+   return ahci_probe_scsi(ahci_dev, base);
+}
+#endif
+
 struct scsi_ops scsi_ops = {
.exec   = ahci_scsi_exec,
.bus_reset  = ahci_scsi_bus_reset,
diff --git a/include/ahci.h b/include/ahci.h
index 818f34464e..29f4ba1d13 100644
--- a/include/ahci.h
+++ b/include/ahci.h
@@ -218,8 +218,20 @@ int ahci_bind_scsi(struct udevice *ahci_dev, struct 
udevice **devp);
  * devices it finds.
  *
  * @ahci_dev: AHCI parent device
+ * @base: Base address of AHCI port
  * @return 0 if OK, -ve on error
  */
-int ahci_probe_scsi(struct udevice *ahci_dev);
+int ahci_probe_scsi(struct udevice *ahci_dev, ulong base);
+
+/**
+ * ahci_probe_scsi_pci() - probe and scan the attached SCSI bus on PCI
+ *
+ * Note that the SCSI device will itself bind block devices for any storage
+ * devices it finds.
+ *
+ * @ahci_dev: AHCI parent device
+ * @return 0 if OK, -ve on error
+ */
+int ahci_probe_scsi_pci(struct udevice *ahci_dev);
 
 #endif
-- 
2.13.1.518.g3df882009-goog

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

Re: [U-Boot] Use u-boot to recover bricked NVIDIA SHIELD TV.

[Matthew Gorski]

On Mon, Jun 19, 2017 at 11:53 AM, Stephen Warren 
wrote:

> On 06/18/2017 04:46 PM, Matthew Gorski wrote:
>
>> I am curious if there is a possibility to recover a wrongly flashed
>> NVIDIA SHIELD TV device by flashing u-boot instead of cboot and mounting
>> the emmc in uboot to do some repairs.
>>
>
> The NVIDIA SHIELD TV is a production Android device, and hence I'm pretty
> sure it has boot security enabled. This security also applies to the USB
> recovery mode protocol, so I don't believe you'll be able to communicate
> with the device unless you know the system's keys, which I assume you don't.
>
> There is some support for flashing generic upstream Linux onto the NVIDIA
> SHIELD tablet, but I believe that relies on  making (at least some of) the
> modifications from a running system, so if your system isn't booting, I
> don't expect this will work either. Just in case it's useful, see:
>
> https://github.com/linux-shield
>

Thanks for chiming in Simon and Stephen.  I appreciate you both taking the
time out of your busy day to answer. I figured the boot security was
preventing communication to the USB recovery mode protocol.  I tried
tegrarcm just to see if I could read the bct and no go.  Seems this happens
quite a bit and there is no way to recover and NVIDIA will not do any
repairs after the warranty expiration date.  Would have been nice if
fastboot could have recognized I used the wrong package :/  Maybe a crc
check to see if the system images match up to the correct device.

Is there anyway to determine what mode I am currently in with tegrarcm
(assuming I can even get communication)?

Operating Mode:  0x3 (developer mode)


Simon the soldering solution sounds interesting.  If someone can elaborate
on that just for reference that would be great.  Ive always wanted UART on
foster.  Thanks again guys for your input.  I'll try a few tricks just to
see what happens and report back.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC PATCH] net: ag7xxx: Clean up some issues with phy access

[Joe Hershberger]

On Mon, Jun 19, 2017 at 4:37 AM, Marek Vasut  wrote:
> On 06/13/2017 06:28 PM, Joe Hershberger wrote:
>> On Tue, Jun 13, 2017 at 4:24 AM, Marek Vasut  wrote:
>>> On 06/12/2017 10:20 PM, Joe Hershberger wrote:
 Don't wait forever, Pass errors back, etc.

 Signed-off-by: Joe Hershberger 

 ---
 This is a pass at improving the code quality.
 This has not been tested in any way.

  drivers/net/ag7xxx.c | 63 
 +---
  1 file changed, 50 insertions(+), 13 deletions(-)

 diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
 index cf60d11..c8352d1 100644
 --- a/drivers/net/ag7xxx.c
 +++ b/drivers/net/ag7xxx.c
>>
>> [...] SNIP
>>
 @@ -723,10 +764,13 @@ static int ag933x_phy_setup_common(struct udevice 
 *dev)
   return ret;

   /* Read out link status */
 - ret = ag7xxx_mdio_read(priv->bus, phymax, 0, MII_MIPSCR);
 + ret = ag7xxx_mdio_read(priv->bus, phymax, 0, 
 AG7XXX_PHY_PSSR);
   if (ret < 0)
   return ret;

 + if (!(ret & AG7XXX_PHY_PSSR_LINK_UP))
 + return -ENOLINK;
>>>
>>> Are you sure about this ?
>>
>> It seems reasonable to me, but I don't have the HW to test against as
>> noted above.
>
> CCing Wills . I wouldn't be surprised if the hardware was somehow
> magically screwed up, so I'd prefer to stick with equivalent changes and
> maybe changes of the logic in a separate patch.

OK.

   return 0;
   }

 @@ -743,13 +787,6 @@ static int ag933x_phy_setup_common(struct udevice 
 *dev)
   return ret;
   }

 - for (i = 0; i < phymax; i++) {
 - /* Read out link status */
 - ret = ag7xxx_mdio_read(priv->bus, i, 0, MII_MIPSCR);
 - if (ret < 0)
 - return ret;
 - }
>>>
>>> And this ?
>>
>> This was based on your comment: "Actually, I think this is only for
>> the switch ports, so we don't care about the link status."
>
> Just so I understand it correctly, the code reads link status and does
> nothing with it ?

That's how I read it.

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

Re: [U-Boot] Use u-boot to recover bricked NVIDIA SHIELD TV.

[Stephen Warren]

On 06/18/2017 04:46 PM, Matthew Gorski wrote:
I am curious if there is a possibility to recover a wrongly flashed 
NVIDIA SHIELD TV device by flashing u-boot instead of cboot and mounting 
the emmc in uboot to do some repairs.


The NVIDIA SHIELD TV is a production Android device, and hence I'm 
pretty sure it has boot security enabled. This security also applies to 
the USB recovery mode protocol, so I don't believe you'll be able to 
communicate with the device unless you know the system's keys, which I 
assume you don't.


There is some support for flashing generic upstream Linux onto the 
NVIDIA SHIELD tablet, but I believe that relies on  making (at least 
some of) the modifications from a running system, so if your system 
isn't booting, I don't expect this will work either. Just in case it's 
useful, see:


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

Re: [U-Boot] Use u-boot to recover bricked NVIDIA SHIELD TV.

[Simon Glass]

Hi Matthew,

On 18 June 2017 at 16:46, Matthew Gorski  wrote:
>
> I am curious if there is a possibility to recover a wrongly flashed NVIDIA 
> SHIELD TV device by flashing u-boot instead of cboot and mounting the emmc in 
> uboot to do some repairs.  If I lose keys for widevine I won't care I just 
> would like to know if this or any remedy is possible when stuck in APX mode 
> after a wrongly flashed system.  My device is past the warranty date so an 
> RMA is not an option.  Even if I could possibly flash linux4tegra it would 
> still be better than having a bricked device stuck in an unusable state.  Any 
> help is immensely appreciated.

I don't know but am interested also. I think I asked once and was told
that you have to solder things to the shield or add a separate board
to get access to UART and I lost interest at that point. I need to
practice my soldering.

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

Re: [U-Boot] Use u-boot to recover bricked NVIDIA SHIELD TV.

[Matthew Gorski]

Would these commands work in production mode even though the bootloader was
previously unlocked?  (Assuming all TX1 chip id's are 0x21)

tegrarcm --download ebt cboot.bin 0 0


or

sudo ./tegraflash.py --bl ./t210ref/cboot.bin --applet
nvtboot_recovery.bin --chip 0x21 --cmd "write USP blob"


On Sun, Jun 18, 2017 at 6:46 PM, Matthew Gorski 
wrote:

> I am curious if there is a possibility to recover a wrongly flashed NVIDIA
> SHIELD TV device by flashing u-boot instead of cboot and mounting the emmc
> in uboot to do some repairs.  If I lose keys for widevine I won't care I
> just would like to know if this or any remedy is possible when stuck in APX
> mode after a wrongly flashed system.  My device is past the warranty date
> so an RMA is not an option.  Even if I could possibly flash linux4tegra it
> would still be better than having a bricked device stuck in an unusable
> state.  Any help is immensely appreciated.
>
> Please help u-boot community and or anyone at NVIDIA.
>
>
> Tried APX flashing the same as I flash my Jetson TX1 devkit. Log below.
>
> sudo ./tegraflash.py --bl cboot.bin --bct bct_e2530.cfg --odmdata 0x84000
> --bldtb tegra210-foster-e-p2530-0930-e02-00.dtb --applet
> nvtboot_recovery.bin --cmd "flash;reboot" --cfg
> flash_t210_android_sdmmc.xml --chip 0x21
> Welcome to Tegra Flash
> version 1.0.0
> Type ? or help for help and q or quit to exit
> Use ! to execute system commands
>
> [   0. ] Generating RCM messages
> [   0.0017 ] tegrarcm --listrcm rcm_list.xml --chip 0x21 --download rcm
> nvtboot_recovery.bin 0 0
> [   0.0033 ] RCM 0 is saved as rcm_0.rcm
> [   0.0043 ] RCM 1 is saved as rcm_1.rcm
> [   0.0043 ] List of rcm files are saved in rcm_list.xml
> [   0.0044 ]
> [   0.0044 ] Signing RCM messages
> [   0.0060 ] tegrasign --key None --list rcm_list.xml --pubkeyhash
> pub_key.key
> [   0.0076 ] Assuming zero filled SBK key
> [   0.0255 ]
> [   0.0256 ] Copying signature to RCM mesages
> [   0.0273 ] tegrarcm --chip 0x21 --updatesig rcm_list_signed.xml
> [   0.0299 ]
> [   0.0299 ] Parsing partition layout
> [   0.0317 ] tegraparser --pt flash_t210_android_sdmmc.xml
> [   0.0341 ]
> [   0.0341 ] Creating list of images to be signed
> [   0.0358 ] tegrahost --chip 0x21 --partitionlayout
> flash_t210_android_sdmmc.bin --list images_list.xml
> [   0.0444 ]
> [   0.0445 ] Generating signatures
> [   0.0460 ] tegrasign --key None --list images_list.xml --pubkeyhash
> pub_key.key
> [   0.0477 ] Assuming zero filled SBK key
> [   0.4273 ]
> [   0.4291 ] tegrabct --bct bct_e2530.cfg --chip 0x21
> [   0.4308 ] Copying Sdram info from 0 to 1 set
> [   0.4339 ] Copying Sdram info from 1 to 2 set
> [   0.4339 ] Copying Sdram info from 2 to 3 set
> [   0.4339 ]
> [   0.4340 ] Updating boot device parameters
> [   0.4356 ] tegrabct --bct bct_e2530.bct --chip 0x21 --updatedevparam
> flash_t210_android_sdmmc.bin
> [   0.4371 ] Warning: No sdram params
> [   0.4374 ]
> [   0.4374 ] Updating bl info
> [   0.4391 ] tegrabct --bct bct_e2530.bct --chip 0x21 --updateblinfo
> flash_t210_android_sdmmc.bin --updatesig images_list_signed.xml
> [   0.4418 ]
> [   0.4419 ] Updating secondary storage information into bct
> [   0.4435 ] tegraparser --pt flash_t210_android_sdmmc.bin --chip 0x21
> --updatecustinfo bct_e2530.bct
> [   0.4453 ]
> [   0.4454 ] Updating Odmdata
> [   0.4469 ] tegrabct --bct bct_e2530.bct --chip 0x21 --updatefields
> Odmdata = 0x84000
> [   0.4484 ] Warning: No sdram params
> [   0.4486 ]
> [   0.4487 ] Get Signed section bct
> [   0.4502 ] tegrabct --bct bct_e2530.bct --chip 0x21 --listbct
> bct_list.xml
> [   0.4520 ]
> [   0.4520 ] Signing BCT
> [   0.4536 ] tegrasign --key None --list bct_list.xml --pubkeyhash
> pub_key.key
> [   0.4551 ] Assuming zero filled SBK key
> [   0.4563 ]
> [   0.4563 ] Updating BCT with signature
> [   0.4578 ] tegrabct --bct bct_e2530.bct --chip 0x21 --updatesig
> bct_list_signed.xml
> [   0.4597 ]
> [   0.4598 ] Copying signatures
> [   0.4613 ] tegrahost --chip 0x21 --partitionlayout
> flash_t210_android_sdmmc.bin --updatesig images_list_signed.xml
> [   0.4628 ] Run tegrabct to update tboot signature in bct
> [   0.4639 ] Run tegrabct to update tboot signature in bct
> [   0.4811 ]
> [   0.4811 ] Updating BFS information
> [   0.4829 ] tegrabct --bct bct_e2530.bct --chip 0x21 --updatebfsinfo
> flash_t210_android_sdmmc.bin
> [   0.4848 ]
> [   0.4849 ] Boot Rom communication
> [   0.4864 ] tegrarcm --chip 0x21 --rcm rcm_list_signed.xml
> [   0.4880 ] BR_CID: 0x621010015c656186180010fd8140
> [   0.4890 ] RCM version 0X13
> [   0.4890 ] Boot Rom communication failed
> [   0.4890 ]
> Error: Return value 3
> Command tegrarcm --chip 0x21 --rcm rcm_list_signed.xml
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH] Initilize IDE prior environment

[Otavio Salvador]

To allow the loading of environment from IDE (for example, using FAT)
the initilization of IDE subsystem must come before the environment
one.

Successfully tested on QEMU x86.

Signed-off-by: Otavio Salvador 
---

 common/board_r.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/board_r.c b/common/board_r.c
index adc1f1937e..247a6668fc 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -806,6 +806,9 @@ static init_fnc_t init_sequence_r[] = {
 #ifdef CONFIG_MMC
initr_mmc,
 #endif
+#if defined(CONFIG_IDE)
+   initr_ide,
+#endif
 #ifdef CONFIG_HAS_DATAFLASH
initr_dataflash,
 #endif
@@ -878,9 +881,6 @@ static init_fnc_t init_sequence_r[] = {
 #if defined(CONFIG_CMD_PCMCIA) && !defined(CONFIG_IDE)
initr_pcmcia,
 #endif
-#if defined(CONFIG_IDE)
-   initr_ide,
-#endif
 #ifdef CONFIG_LAST_STAGE_INIT
INIT_FUNC_WATCHDOG_RESET
/*
-- 
2.13.1

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

Re: [U-Boot] [PATCH v8 4/7] arm: socfpga: Enable FPGA driver on SPL

[Dinh Nguyen]

On 06/19/2017 05:32 AM, Chee, Tien Fong wrote:
> On Sel, 2017-06-13 at 11:05 +0200, Marek Vasut wrote:
>> On 06/13/2017 05:26 AM, Chee, Tien Fong wrote:
>>>
>>> On Isn, 2017-06-12 at 16:38 +0800, Chee, Tien Fong wrote:

 On Jum, 2017-06-09 at 08:52 -0500, Dinh Nguyen wrote:
>
>
>
> On 06/09/2017 03:25 AM, Marek Vasut wrote:
>>
>>
>>
>>
>> I didn't really look since we still have a discussion open on
>> V8
>> .
>> There
>> is no point in sending new versions while discussion is still
>> open.
>> Also, I'd like some review from Ley/Dinh
> I've reviewed v6 and gave my Reviewed-by. Now I see there's a
> v10.
> Should I be reviewing v10 or wait for a new version?
>
> Dinh
 If Marek agree with my planning, code cleaning for gen5 in
 different
 patchset. v10 is updated based on Mareks' comments on v9, then
 v10
 should be the final version.

 Thanks.
>>> Hi Marek,
>>>
>>> I think Dinh is still waiting answer from you.
>> Thanks for reminding me daily. I'm actually on vacation, so sorry for
>> the delayed reply.

I have no idea what question I have to Marek, but it probably doesn't
matter anymore.

>>
>>>
>>> Could you please to
>>> advice?
>> Actually I lost track of what's going on here, we're still having
>> discussion on V8 and I already have V10 in my mailbox. I have two
>> suggestions:
>> 1) Slow down, bombarding people with new versions of patches every
>> day
>>does not help at all. Give people some space to review the
>> patchset,
>>discuss and let the discussion settle, then submit a new set. That
>>can take a week or more, so let's establish a rule that you will
>> not
>>submit more than one version of the patchset each week unless
>>explicitly asked. OK ?

+1 in agreement. Just because you're in a hurry to get a patchset
reviewed and accepted, doesn't mean the rest of us are in a hurry to
review for you. If you had done things right and planned to upstream
first, often, and frequently, you'd not be trying to push 10 versions of
patchset in 2 weeks down our throat.

>> 2) I'd like AB/RB from Dinh on this set, yes.
>>
> Hi Dinh,
> 
> Could you help to review?

Sorry, I also just got back from vacation. Will try to get to it this week.

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

Re: [U-Boot] ImportError: No module named _libfdt

[Peter Robinson]

On Sat, Jun 17, 2017 at 6:45 PM, Jean-Marc Beaune  wrote:
> Hello,
>
> I am new to U-Boot and trying to compile source code in order to get U-Boot
> working on a BananaPi.
>
> I get the following error while compiling the latest version of master
> branch:
>
> ImportError: No module named _libfdt
>
> Has anyone an idea about why Python is not happy?

If you're using the upstream dtc you'll need something newer than the
latest actual release to pull in the python bindings, even then I've
found errors because I think u-boot has something different to
upstream that is some how being utilised in the .07 RCs but I've not
had time to look closer at it.

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

[U-Boot] [PATCH 2/2] rpi: Fix fdt_high & initrd_high for 64-bit builds

[Tuomas Tynkkynen]

The magic value that disables relocation is dependent on the CPU word
size, so the current '' is doing the wrong thing on aarch64.

Signed-off-by: Tuomas Tynkkynen 
---
These two patches aren't really related except for touching the same
parts of the code, I just noticed this by coincidence. For me there's no
visible effects with this patch.

Instead of spreading this #ifdef pattern further,
http://patchwork.ozlabs.org/patch/716487/ would be a cleaner way of
solving this...
---
 include/configs/rpi.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index a2d82a9146..153b2463a7 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -119,6 +119,14 @@
"stdout=serial,vidconsole\0" \
"stderr=serial,vidconsole\0"
 
+#ifdef CONFIG_ARM64
+#define FDT_HIGH ""
+#define INITRD_HIGH ""
+#else
+#define FDT_HIGH ""
+#define INITRD_HIGH ""
+#endif
+
 /*
  * Memory layout for where various images get loaded by boot scripts:
  *
@@ -164,8 +172,8 @@
 # define KERNEL_ADDR_R "0x0300"
 #endif
 #define ENV_MEM_LAYOUT_SETTINGS \
-   "fdt_high=\0" \
-   "initrd_high=\0" \
+   "fdt_high=" FDT_HIGH "\0" \
+   "initrd_high=" INITRD_HIGH "\0" \
"fdt_addr_r=0x0100\0" \
"kernel_addr_r=" KERNEL_ADDR_R "\0" \
"scriptaddr=0x0400\0" \
-- 
2.13.0

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

[U-Boot] [PATCH 1/2] rpi: Change load addresses to make more room for the kernel

[Tuomas Tynkkynen]

According to the comment in rpi.h, the current kernel load address is
picked such that the compressed kernel and the uncompressed kernel don't
overlap in memory to avoid unnecessary relocation of the compressed
image in the decompressor stub. However, as is evident from the
kernel boot log snipped below, a full-blown ARMv7 distro kernel
(v4.11.3) can use as much as 17063 kB uncompressed. That is larger
than the current 16M reservation which means that the relocation
indeed is happening.

[0.00] Virtual kernel memory layout:
 .text : 0xc0208000 - 0xc0f0   (13280 kB)
 .init : 0xc150 - 0xc170   (2048 kB)
 .data : 0xc170 - 0xc18b1978   (1735 kB)

Additionally, on AArch64 the kernel images are much larger than
on ARM. A full-blown 4.11.3 distro kernel takes 24M, which with the
current load addresses (reserving only 17M) stomps over the initrd,
breaking the boot of such large kernels.

Fix both of these problems by tweaking the load addresses as appropriate
depending on the CPU architecture. To make things simpler, pxefile_addr_r
is moved from low memory next to scriptaddr.

After this patch we end up with this memory map on ARM (assuming the
most conservative CPU-GPU memory split of 128M for the CPU):
0x0100 - 0x8000 (31 kB): fdt_addr_r - decompressed_kernel_start
0x8000 - 0x0300 ( 49120 kB): decompressed_kernel - kernel_addr_r
0x0300 - 0x0400 ( 16384 kB): kernel_addr_r - scriptaddr
0x0400 - 0x0410 (  1024 kB): scriptaddr - pxefile_addr_r
0x0410 - 0x0420 (  1024 kB): pxefile_addr_r - ramdisk_addr_r
0x0420 - 0x0800 ( 63488 kB): ramdisk_addr_r - top_of_ram

And this for AArch64:
0x0100 - 0x0008 (   511 kB): fdt_addr_r - kernel_addr_r
0x0008 - 0x0400 ( 65024 kB): kernel_addr_r - scriptaddr
0x0400 - 0x0410 (  1024 kB): scriptaddr - pxefile_addr_r
0x0410 - 0x0420 (  1024 kB): pxefile_addr_r - ramdisk_addr_r
0x0420 - 0x0800 ( 63488 kB): ramdisk_addr_r - top_of_ram

Signed-off-by: Tuomas Tynkkynen 
---
This has been tested on:
 - RPi 1 booting the RPi Foundation downstream kernel
 - RPi 3 booting a distro multi_v7_defconfig in 32-bit mode
 - RPi 3 booting a AArch64 distro defconfig in 64-bit mode
---
 include/configs/rpi.h | 36 +---
 1 file changed, 25 insertions(+), 11 deletions(-)

diff --git a/include/configs/rpi.h b/include/configs/rpi.h
index d715eaad14..a2d82a9146 100644
--- a/include/configs/rpi.h
+++ b/include/configs/rpi.h
@@ -131,32 +131,46 @@
  *   U-Boot (and scripts it executes) typicaly ignore the DT loaded by the FW
  *   and loads its own DT from disk (triggered by boot.scr or extlinux.conf).
  *
- * pxefile_addr_r can be pretty much anywhere that doesn't conflict with
- *   something else. Put it low in memory to avoid conflicts.
+ * kernel_addr_r has different constraints on ARM and Aarch64.
+ *   For Aarch64, the kernel image is uncompressed and must be loaded at
+ *   text_offset bytes (specified in the header of the Image) into a
+ *   2MB boundary. As Linux uses a default text_offset of 0x8, load
+ *   the kernel at 0x8 so that the 'booti' command does not need
+ *   to perform any relocation of the Image in the typical case.
  *
- * kernel_addr_r must be within the first 128M of RAM in order for the
+ *   For 32-bit ARM, it must be within the first 128M of RAM in order for the
  *   kernel's CONFIG_AUTO_ZRELADDR option to work. Since the kernel will
  *   decompress itself to 0x8000 after the start of RAM, kernel_addr_r
  *   should not overlap that area, or the kernel will have to copy itself
  *   somewhere else before decompression. Similarly, the address of any other
  *   data passed to the kernel shouldn't overlap the start of RAM. Pushing
- *   this up to 16M allows for a sizable kernel to be decompressed below the
+ *   this up to 48M allows for a sizable kernel to be decompressed below the
  *   compressed load address.
  *
  * scriptaddr can be pretty much anywhere that doesn't conflict with something
- *   else. Choosing 32M allows for the compressed kernel to be up to 16M.
+ *   else. Choosing 64M allows for the compressed kernel to be up to 16M on
+ *   32-bit ARM and roughly 64M for the uncompressed kernel on Aarch64.
+ *
+ * pxefile_addr_r can be pretty much anywhere that doesn't conflict with
+ *   something else. Choosing 65M allows for any boot script to be up to 1M,
+ *   which is hopefully plenty.
  *
- * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 33M allows
- *   for any boot script to be up to 1M, which is hopefully plenty.
+ * ramdisk_addr_r simply shouldn't overlap anything else. Choosing 66M allows
+ *   for any PXE configuration file to be up to 1M, which is hopefully plenty.
  */
+#ifdef CONFIG_ARM64
+# define KERNEL_ADDR_R "0x0008"
+#else
+# define KERNEL_ADDR_R "0x0300"
+#endif
 #define ENV_MEM_LAYOUT_SETTINGS \
 

[U-Boot] Driver model u-boot 2017

[Christine Gharzuzi]

Hi Simon,

I need an early binding in order to print information about the CPU frequency
using a driver I implemented using driver model.
u-boot starts binding all the devices at once? I don't understand why the 
printing is performed during the binding (I have only 1 CPU)

also it's performed right after the root driver bind.

Thanks,
Christine





--

Hi Christine,



On 14 June 2017 at 10:18, Christine Gharzuzi 
> wrote:

> Hi,

>

> I Need an early binding for a device right after the root driver is binding.

> By doing a simple debug I see that after binding the root driver

> there's an attempt to bind

>

> all the devices (nodes) from the device tree to their suitable driver,

> the device  I want to bind to its drivers is also a part of my device

> tree but I need it

>

> to be right after the root driver binding and not according to the

> nodes sequence in the device tree.

>

> I hope there's  a way to do so.



Why do you need this?



Regards,

Simon

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

[U-Boot] Getting splash screen to work

[Sergey Borovkov]

Hello,

I am trying to get splash screen work in the uboot but have no luck so far.

Anyone can help me with what I might be doing wrong? I have following code
right now:
fatload ${devtype} ${devnum}:${bootpart} 0x0020 /splash.bmp && bmp
display 0x0020;

I can see that image is actually loaded into the RAM. I can read it back
with bmp info. bmp display does nothing though. I tried putting an image
with incorrect color depth on the SD card and at that time bmp display
actually complained about incorrect color depth. So it's actually called
and can read the image.
Setting splashimage variable made no difference as well unfortunately.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] ImportError: No module named _libfdt

[Jean-Marc Beaune]

Hello,

I am new to U-Boot and trying to compile source code in order to get U-Boot
working on a BananaPi.

I get the following error while compiling the latest version of master
branch:

ImportError: No module named _libfdt

Has anyone an idea about why Python is not happy?

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

Re: [U-Boot] [PATCH 1/2] rpi: Change load addresses to make more room for the kernel

[Tom Rini]

On Mon, Jun 19, 2017 at 02:08:03PM +0300, Tuomas Tynkkynen wrote:
> According to the comment in rpi.h, the current kernel load address is
> picked such that the compressed kernel and the uncompressed kernel don't
> overlap in memory to avoid unnecessary relocation of the compressed
> image in the decompressor stub. However, as is evident from the
> kernel boot log snipped below, a full-blown ARMv7 distro kernel
> (v4.11.3) can use as much as 17063 kB uncompressed. That is larger
> than the current 16M reservation which means that the relocation
> indeed is happening.
> 
> [0.00] Virtual kernel memory layout:
>  .text : 0xc0208000 - 0xc0f0   (13280 kB)
>  .init : 0xc150 - 0xc170   (2048 kB)
>  .data : 0xc170 - 0xc18b1978   (1735 kB)
> 
> Additionally, on AArch64 the kernel images are much larger than
> on ARM. A full-blown 4.11.3 distro kernel takes 24M, which with the
> current load addresses (reserving only 17M) stomps over the initrd,
> breaking the boot of such large kernels.
> 
> Fix both of these problems by tweaking the load addresses as appropriate
> depending on the CPU architecture. To make things simpler, pxefile_addr_r
> is moved from low memory next to scriptaddr.
> 
> After this patch we end up with this memory map on ARM (assuming the
> most conservative CPU-GPU memory split of 128M for the CPU):
> 0x0100 - 0x8000 (31 kB): fdt_addr_r - decompressed_kernel_start
> 0x8000 - 0x0300 ( 49120 kB): decompressed_kernel - kernel_addr_r
> 0x0300 - 0x0400 ( 16384 kB): kernel_addr_r - scriptaddr
> 0x0400 - 0x0410 (  1024 kB): scriptaddr - pxefile_addr_r
> 0x0410 - 0x0420 (  1024 kB): pxefile_addr_r - ramdisk_addr_r
> 0x0420 - 0x0800 ( 63488 kB): ramdisk_addr_r - top_of_ram
> 
> And this for AArch64:
> 0x0100 - 0x0008 (   511 kB): fdt_addr_r - kernel_addr_r
> 0x0008 - 0x0400 ( 65024 kB): kernel_addr_r - scriptaddr
> 0x0400 - 0x0410 (  1024 kB): scriptaddr - pxefile_addr_r
> 0x0410 - 0x0420 (  1024 kB): pxefile_addr_r - ramdisk_addr_r
> 0x0420 - 0x0800 ( 63488 kB): ramdisk_addr_r - top_of_ram
> 
> Signed-off-by: Tuomas Tynkkynen 
> ---
> This has been tested on:
>  - RPi 1 booting the RPi Foundation downstream kernel
>  - RPi 3 booting a distro multi_v7_defconfig in 32-bit mode
>  - RPi 3 booting a AArch64 distro defconfig in 64-bit mode

Can we try using bootm_size instead so that things are relocated
appropriately?  See DEFAULT_LINUX_BOOT_ENV in
include/configs/ti_armv7_common.h (and then Documentation/arm/Booting
and Documentation/arm64/booting.txt in the kernel).  Thanks!

-- 
Tom


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

Re: [U-Boot] [PATCH 2/6] arm: mach-omap2: Factor out common FDT fixup suport

[Tom Rini]

On Fri, Jun 16, 2017 at 02:26:57PM -0500, Andrew F. Davis wrote:

> Some of the fixups currently done for OMAP5 class boards are common to
> other OMAP family devices, move these to fdt-common.c.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 6/6] board: ti: am43xx: Add FDT fixup for HS devices

[Tom Rini]

On Fri, Jun 16, 2017 at 02:27:01PM -0500, Andrew F. Davis wrote:

> Disable RNG and add TEE to FDT used on HS devices.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 4/6] arm: mach-omap2: am33xx: Add FDT fixup suport for AM33xx/AM43xx boards

[Tom Rini]

On Fri, Jun 16, 2017 at 02:26:59PM -0500, Andrew F. Davis wrote:

> Similar to what is done with OMAP5 class boards we need to
> perform fixups common to this SoC class, add support for this here
> and add HS fixups.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 1/6] arm: mach-omap2: Move omap5/sec-fxns.c into sec-common.c

[Tom Rini]

On Fri, Jun 16, 2017 at 02:26:56PM -0500, Andrew F. Davis wrote:

> TEE loading and firewall setup are common to all omap2 devices, move
> these function out of omap5 and into mach-omap2. This allows us
> to use these functions from other omap class devices.
> 
> Signed-off-by: Andrew F. Davis 

Reviewed-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH v4 03/10] dm: spi: add BCM63xx SPI driver

[Jagan Teki]

On Thu, Jun 15, 2017 at 2:54 PM, Álvaro Fernández Rojas
 wrote:
> Hi Jagan,
>
> El 15/6/17 a las 7:38, Jagan Teki escribió:
>> On Wed, Jun 14, 2017 at 3:27 PM, Álvaro Fernández Rojas
>>  wrote:
>>> This driver is a simplified version of linux/drivers/spi/spi-bcm63xx.c
>>> Instead of supporting both HW revisions of the controller in a single build,
>>> support has been split by the selected config to save space.
>>>
>>> Signed-off-by: Álvaro Fernández Rojas 
>>> Reviewed-by: Simon Glass 
>>> Reviewed-by: Daniel Schwierzeck 
>>> ---
>>>  v4: Introduce changes suggested by Jagan Teki:
>>>   - Add data for each HW controller instead of having two separate configs.
>>>   - Also check clock and reset returns as suggested by Simon Glass for 
>>> HSSPI.
>>>  v3: rename BCM6338 SPI driver to BCM6348
>>>   switch to devfdt_get_addr_size_index()
>>>  v2: no changes
>>>
>>>  drivers/spi/Kconfig   |   8 +
>>>  drivers/spi/Makefile  |   1 +
>>>  drivers/spi/bcm63xx_spi.c | 419 
>>> ++
>>>  3 files changed, 428 insertions(+)
>>>  create mode 100644 drivers/spi/bcm63xx_spi.c
>>>
>>> diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
>>> index bef864f..6da78bd 100644
>>> --- a/drivers/spi/Kconfig
>>> +++ b/drivers/spi/Kconfig
>>> @@ -40,6 +40,14 @@ config ATMEL_SPI
>>>   many AT32 (AVR32) and AT91 (ARM) chips. This driver can be
>>>   used to access the SPI Flash, such as AT25DF321.
>>>
>>> +config BCM63XX_SPI
>>> +   bool "BCM6348 SPI driver"
>>> +   depends on ARCH_BMIPS
>>> +   help
>>> + Enable the BCM6348/BCM6358 SPI driver. This driver can be used to
>>> + access the SPI NOR flash on platforms embedding these Broadcom
>>> + SPI cores.
>>> +
>>>  config CADENCE_QSPI
>>> bool "Cadence QSPI driver"
>>> help
>>> diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
>>> index c090562..260ba06 100644
>>> --- a/drivers/spi/Makefile
>>> +++ b/drivers/spi/Makefile
>>> @@ -19,6 +19,7 @@ obj-$(CONFIG_ALTERA_SPI) += altera_spi.o
>>>  obj-$(CONFIG_ATH79_SPI) += ath79_spi.o
>>>  obj-$(CONFIG_ATMEL_DATAFLASH_SPI) += atmel_dataflash_spi.o
>>>  obj-$(CONFIG_ATMEL_SPI) += atmel_spi.o
>>> +obj-$(CONFIG_BCM63XX_SPI) += bcm63xx_spi.o
>>
>> Thanks for doing this change.
> That's what you requested ;).
>
>>
>>>  obj-$(CONFIG_CADENCE_QSPI) += cadence_qspi.o cadence_qspi_apb.o
>>>  obj-$(CONFIG_CF_SPI) += cf_spi.o
>>>  obj-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
>>> diff --git a/drivers/spi/bcm63xx_spi.c b/drivers/spi/bcm63xx_spi.c
>>> new file mode 100644
>>> index 000..e1629fa
>>> --- /dev/null
>>> +++ b/drivers/spi/bcm63xx_spi.c
>>> @@ -0,0 +1,419 @@
>>> +/*
>>> + * Copyright (C) 2017 Álvaro Fernández Rojas 
>>> + *
>>> + * Derived from linux/drivers/spi/spi-bcm63xx.c:
>>> + * Copyright (C) 2009-2012 Florian Fainelli 
>>> + * Copyright (C) 2010 Tanguy Bouzeloc 
>>> + *
>>> + * SPDX-License-Identifier: GPL-2.0+
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +DECLARE_GLOBAL_DATA_PTR;
>>> +
>>> +/* SPI Clock register */
>>> +#define SPI_CLK_SHIFT  0
>>> +#define SPI_CLK_20MHZ  (0 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_0_391MHZ   (1 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_0_781MHZ   (2 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_1_563MHZ   (3 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_3_125MHZ   (4 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_6_250MHZ   (5 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_12_50MHZ   (6 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_25MHZ  (7 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_MASK   (7 << SPI_CLK_SHIFT)
>>> +#define SPI_CLK_SSOFF_SHIFT3
>>> +#define SPI_CLK_SSOFF_2(2 << SPI_CLK_SSOFF_SHIFT)
>>> +#define SPI_CLK_SSOFF_MASK (7 << SPI_CLK_SSOFF_SHIFT)
>>> +#define SPI_CLK_BSWAP_SHIFT7
>>> +#define SPI_CLK_BSWAP_MASK (1 << SPI_CLK_BSWAP_SHIFT)
>>> +
>>> +/* SPI Command register */
>>> +#define SPI_CMD_OP_SHIFT   0
>>> +#define SPI_CMD_OP_START   (0x3 << SPI_CMD_OP_SHIFT)
>>> +#define SPI_CMD_SLAVE_SHIFT4
>>> +#define SPI_CMD_SLAVE_MASK (0xf << SPI_CMD_SLAVE_SHIFT)
>>> +#define SPI_CMD_PREPEND_SHIFT  8
>>> +#define SPI_CMD_PREPEND_BYTES  0xf
>>> +#define SPI_CMD_3WIRE_SHIFT12
>>> +#define SPI_CMD_3WIRE_MASK (1 << SPI_CMD_3WIRE_SHIFT)
>>> +
>>> +/* SPI Control register */
>>> +# define SPI_CTL_TYPE_FD_RW0
>>> +# define SPI_CTL_TYPE_HD_W 1
>>> +# define SPI_CTL_TYPE_HD_R 2
>>> +
>>> +/* SPI Interrupt registers */
>>> +#define SPI_IR_DONE_SHIFT  0
>>> +#define SPI_IR_DONE_MASK   (1 << SPI_IR_DONE_SHIFT)
>>> +#define SPI_IR_RXOVER_SHIFT1
>>> +#define SPI_IR_RXOVER_MASK (1 << SPI_IR_RXOVER_SHIFT)
>>> +#define SPI_IR_TXUNDER_SHIFT   2
>>> 

Re: [U-Boot] [PATCH v2 08/13] usb: gadget: ether: Provide a way to read MAC address

[Vignesh R]

Hi Lukasz,

On Thursday 15 June 2017 10:28 PM, Marek Vasut wrote:
> On 06/14/2017 02:24 PM, Vignesh R wrote:
>>
>>
>> On Tuesday 13 June 2017 07:36 PM, Marek Vasut wrote:
>>> On 06/13/2017 02:10 PM, Vignesh R wrote:
 Provide a way to read MAC address for usb_ether device from board
 function. Board files can override board_set_usbnet_devaddr() to
 populate MAC address to be used by usb_ether as device address.

 Signed-off-by: Vignesh R 
>>>
>>> This patch is totally unrelated to this series. 
>>
>> This series converts dwc3 peripheral to device model and the best way to
>> test this on TI platform to use it on ether gadget and test RNDIS boot.
>> Hence, I had to do patches 8 to 13. Therefore I posted them together for
>> completeness, if somebody wanted to test this out.
> 
> Testing is great, but this is probably a fix and it's unrelated to the
> series anyway.
> 
>>> Moreover, just set eth*addr using setenv() to achieve the same iirc .
>>>
>>
>> eth*addr is used for regular ethernet interface and usually set by
>> regular ethernet driver, but I could not find a way to set MAC address
>> for usb ethernet interface
>> Board file will now override board_set_usbnet_devaddr() to read MAC and
>> then call setenv()
> 
> Lukasz should be able to jump in and help.
> 

Any preference on how to handle this?
Basically, I need a way to pass MAC address to usb_ether driver. MAC
address is available in specific efuse registers. Previously, this was
handled by board_eth_init(), this is no longer available when using DM
based ethernet driver.


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

[U-Boot] [PATCH v4 3/4] rockchip: Add basic support for phyCORE-RK3288 SoM based carrier board

[Wadim Egorov]

The phyCORE-RK3288 is a SoM (System on Module) containing a RK3288 SoC.
The module can be connected to different carrier boards.
It can be also equipped with different RAM, SPI flash and eMMC variants.
The Rapid Development Kit option is using the following setup:

  - 1 GB DDR3 RAM (2 Banks)
  - 1x 4 KB EEPROM
  - DP83867 Gigabit Ethernet PHY
  - 16 MB SPI Flash
  - 4 GB eMMC Flash

Add basic support for the PCM-947 carrier board, a RK3288 based development
board made by PHYTEC. This board works in a combination with
the phyCORE-RK3288 System on Module.

Signed-off-by: Wadim Egorov 
Reviewed-by: Simon Glass 
---
Changes in v4:
- Use of_machine_is_compatible()
- Wrap phycore_init()/of_machine_is_compatible() with CONFIG_SPL_OF_PLATDATA
  and CONFIG_SPL_POWER_SUPPORT. Needed because of_machine_is_compatible() and
  rk818_spl_configure_*() is not available with all rk3288 board configs.
- Added Reviewed-by: Simon Glass 

 arch/arm/dts/Makefile|   1 +
 arch/arm/dts/rk3288-phycore-rdk.dts  | 294 
 arch/arm/dts/rk3288-phycore-som.dtsi | 506 +++
 arch/arm/mach-rockchip/rk3288-board-spl.c|  40 +++
 arch/arm/mach-rockchip/rk3288/Kconfig|  10 +
 board/phytec/phycore_rk3288/Kconfig  |  15 +
 board/phytec/phycore_rk3288/MAINTAINERS  |   6 +
 board/phytec/phycore_rk3288/Makefile |   8 +
 board/phytec/phycore_rk3288/phycore-rk3288.c |   8 +
 configs/phycore-rk3288_defconfig |  70 
 include/configs/phycore_rk3288.h |  23 ++
 11 files changed, 981 insertions(+)
 create mode 100644 arch/arm/dts/rk3288-phycore-rdk.dts
 create mode 100644 arch/arm/dts/rk3288-phycore-som.dtsi
 create mode 100644 board/phytec/phycore_rk3288/Kconfig
 create mode 100644 board/phytec/phycore_rk3288/MAINTAINERS
 create mode 100644 board/phytec/phycore_rk3288/Makefile
 create mode 100644 board/phytec/phycore_rk3288/phycore-rk3288.c
 create mode 100644 configs/phycore-rk3288_defconfig
 create mode 100644 include/configs/phycore_rk3288.h

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8b8f5e9..84f63e1 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -34,6 +34,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += \
rk3288-fennec.dtb \
rk3288-firefly.dtb \
rk3288-miqi.dtb \
+   rk3288-phycore-rdk.dtb \
rk3288-popmetal.dtb \
rk3288-rock2-square.dtb \
rk3288-tinker.dtb \
diff --git a/arch/arm/dts/rk3288-phycore-rdk.dts 
b/arch/arm/dts/rk3288-phycore-rdk.dts
new file mode 100644
index 000..f2bb7b5
--- /dev/null
+++ b/arch/arm/dts/rk3288-phycore-rdk.dts
@@ -0,0 +1,294 @@
+/*
+ * Device tree file for Phytec PCM-947 carrier board
+ * Copyright (C) 2017 PHYTEC Messtechnik GmbH
+ * Author: Wadim Egorov 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include 
+#include "rk3288-phycore-som.dtsi"
+
+/ {
+   model = "Phytec RK3288 PCM-947";
+   compatible = 

[U-Boot] [PATCH v4 2/4] power: regulator: rk8xx: Allow input current/charger shutdown configuration

[Wadim Egorov]

The RK818 PMIC contains a charger. Add very basic charger functionality
to be able to regulate the USB input current and charger shutdown limits.

Signed-off-by: Wadim Egorov 
Reviewed-by: Simon Glass 
---
Changes in v4:
- Added Reviewed-by: Simon Glass 

 drivers/power/regulator/rk8xx.c | 34 ++
 include/power/rk8xx_pmic.h  |  2 ++
 2 files changed, 36 insertions(+)

diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index d96a1f8..7c0a3aa 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -30,6 +30,9 @@
 #define RK818_LDO_VSEL_MASK0x1f
 #define RK818_LDO3_ON_VSEL_MASK0xf
 #define RK818_BOOST_ON_VSEL_MASK   0xe0
+#define RK818_USB_ILIM_SEL_MASK0x0f
+#define RK818_USB_CHG_SD_VSEL_MASK 0x70
+
 
 struct rk8xx_reg_info {
uint min_uv;
@@ -76,6 +79,14 @@ static const struct rk8xx_reg_info rk818_ldo[] = {
 };
 #endif
 
+static const u16 rk818_chrg_cur_input_array[] = {
+   450, 800, 850, 1000, 1250, 1500, 1750, 2000, 2250, 2500, 2750, 3000
+};
+
+static const uint rk818_chrg_shutdown_vsel_array[] = {
+   278, 285, 292, 299, 306, 313, 319, 326
+};
+
 static const struct rk8xx_reg_info *get_buck_reg(struct udevice *pmic,
 int num)
 {
@@ -353,3 +364,26 @@ int rk8xx_spl_configure_buck(struct udevice *pmic, int 
buck, int uvolt)
 
return _buck_set_enable(pmic, buck, true);
 }
+
+int rk818_spl_configure_usb_input_current(struct udevice *pmic, int current_ma)
+{
+   uint i;
+
+   for (i = 0; i < ARRAY_SIZE(rk818_chrg_cur_input_array); i++)
+   if (current_ma <= rk818_chrg_cur_input_array[i])
+   break;
+
+   return pmic_clrsetbits(pmic, REG_USB_CTRL, RK818_USB_ILIM_SEL_MASK, i);
+}
+
+int rk818_spl_configure_usb_chrg_shutdown(struct udevice *pmic, int uvolt)
+{
+   uint i;
+
+   for (i = 0; i < ARRAY_SIZE(rk818_chrg_shutdown_vsel_array); i++)
+   if (uvolt <= rk818_chrg_shutdown_vsel_array[i])
+   break;
+
+   return pmic_clrsetbits(pmic, REG_USB_CTRL, RK818_USB_CHG_SD_VSEL_MASK,
+  i);
+}
diff --git a/include/power/rk8xx_pmic.h b/include/power/rk8xx_pmic.h
index 589f8c4..47a6b36 100644
--- a/include/power/rk8xx_pmic.h
+++ b/include/power/rk8xx_pmic.h
@@ -189,5 +189,7 @@ struct rk8xx_priv {
 };
 
 int rk8xx_spl_configure_buck(struct udevice *pmic, int buck, int uvolt);
+int rk818_spl_configure_usb_input_current(struct udevice *pmic, int 
current_ma);
+int rk818_spl_configure_usb_chrg_shutdown(struct udevice *pmic, int uvolt);
 
 #endif
-- 
1.9.1

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

[U-Boot] [PATCH v4 4/4] doc: rockchip: Add phyCORE-RK3288 RDK to board list

[Wadim Egorov]

Signed-off-by: Wadim Egorov 
Acked-by: Simon Glass 
Reviewed-by: Simon Glass 
---
Changes in v4:
- Added Reviewed-by: Simon Glass 

 doc/README.rockchip | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/doc/README.rockchip b/doc/README.rockchip
index 2d8cf9f..dbeb8be 100644
--- a/doc/README.rockchip
+++ b/doc/README.rockchip
@@ -36,13 +36,14 @@ You will need:
 Building
 
 
-At present eight RK3288 boards are supported:
+At present nine RK3288 boards are supported:
 
- EVB RK3288 - use evb-rk3288 configuration
- Fennec RK3288 - use fennec-rk3288 configuration
- Firefly RK3288 - use firefly-rk3288 configuration
- Hisense Chromebook - use chromebook_jerry configuration
- MiQi RK3288 - use miqi-rk3288 configuration
+   - phyCORE-RK3288 RDK - use phycore-rk3288 configuration
- PopMetal RK3288 - use popmetal-rk3288 configuration
- Radxa Rock 2 - use rock2 configuration
- Tinker RK3288 - use tinker-rk3288 configuration
-- 
1.9.1

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

[U-Boot] [PATCH v4 1/4] power: regulator: rk8xx: Build get_ldo_reg only for SPL

[Wadim Egorov]

Enabling CONFIG_SPL_POWER_SUPPORT will cause a compiler warning:
  ‘get_ldo_reg’ defined but not used [-Wunused-function]

Let's wrap get_ldo_reg(), rk808_ldo and rk818_ldo with ENABLE_DRIVER
which is only set for non SPL builds.

Signed-off-by: Wadim Egorov 
Reviewed-by: Simon Glass 
---
Changes in v4:
- Added Reviewed-by: Simon Glass 

 drivers/power/regulator/rk8xx.c | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/drivers/power/regulator/rk8xx.c b/drivers/power/regulator/rk8xx.c
index c1ece96..d96a1f8 100644
--- a/drivers/power/regulator/rk8xx.c
+++ b/drivers/power/regulator/rk8xx.c
@@ -45,6 +45,14 @@ static const struct rk8xx_reg_info rk808_buck[] = {
{ 180, 10, REG_BUCK4_ON_VSEL, RK808_BUCK4_VSEL_MASK, },
 };
 
+static const struct rk8xx_reg_info rk818_buck[] = {
+   { 712500, 12500, REG_BUCK1_ON_VSEL, RK818_BUCK_VSEL_MASK, },
+   { 712500, 12500, REG_BUCK2_ON_VSEL, RK818_BUCK_VSEL_MASK, },
+   { 712500, 12500, -1, RK818_BUCK_VSEL_MASK, },
+   { 180, 10, REG_BUCK4_ON_VSEL, RK818_BUCK4_VSEL_MASK, },
+};
+
+#ifdef ENABLE_DRIVER
 static const struct rk8xx_reg_info rk808_ldo[] = {
{ 180, 10, REG_LDO1_ON_VSEL, RK808_LDO_VSEL_MASK, },
{ 180, 10, REG_LDO2_ON_VSEL, RK808_LDO_VSEL_MASK, },
@@ -56,13 +64,6 @@ static const struct rk8xx_reg_info rk808_ldo[] = {
{ 180, 10, REG_LDO8_ON_VSEL, RK808_LDO_VSEL_MASK, },
 };
 
-static const struct rk8xx_reg_info rk818_buck[] = {
-   { 712500, 12500, REG_BUCK1_ON_VSEL, RK818_BUCK_VSEL_MASK, },
-   { 712500, 12500, REG_BUCK2_ON_VSEL, RK818_BUCK_VSEL_MASK, },
-   { 712500, 12500, -1, RK818_BUCK_VSEL_MASK, },
-   { 180, 10, REG_BUCK4_ON_VSEL, RK818_BUCK4_VSEL_MASK, },
-};
-
 static const struct rk8xx_reg_info rk818_ldo[] = {
{ 180, 10, REG_LDO1_ON_VSEL, RK818_LDO_VSEL_MASK, },
{ 180, 10, REG_LDO2_ON_VSEL, RK818_LDO_VSEL_MASK, },
@@ -73,6 +74,7 @@ static const struct rk8xx_reg_info rk818_ldo[] = {
{ 80, 10, REG_LDO7_ON_VSEL, RK818_LDO_VSEL_MASK, },
{ 180, 10, REG_LDO8_ON_VSEL, RK818_LDO_VSEL_MASK, },
 };
+#endif
 
 static const struct rk8xx_reg_info *get_buck_reg(struct udevice *pmic,
 int num)
@@ -86,18 +88,6 @@ static const struct rk8xx_reg_info *get_buck_reg(struct 
udevice *pmic,
}
 }
 
-static const struct rk8xx_reg_info *get_ldo_reg(struct udevice *pmic,
-int num)
-{
-   struct rk8xx_priv *priv = dev_get_priv(pmic);
-   switch (priv->variant) {
-   case RK818_ID:
-   return _ldo[num];
-   default:
-   return _ldo[num];
-   }
-}
-
 static int _buck_set_value(struct udevice *pmic, int buck, int uvolt)
 {
const struct rk8xx_reg_info *info = get_buck_reg(pmic, buck - 1);
@@ -133,6 +123,18 @@ static int _buck_set_enable(struct udevice *pmic, int 
buck, bool enable)
 }
 
 #ifdef ENABLE_DRIVER
+static const struct rk8xx_reg_info *get_ldo_reg(struct udevice *pmic,
+int num)
+{
+   struct rk8xx_priv *priv = dev_get_priv(pmic);
+   switch (priv->variant) {
+   case RK818_ID:
+   return _ldo[num];
+   default:
+   return _ldo[num];
+   }
+}
+
 static int buck_get_value(struct udevice *dev)
 {
int buck = dev->driver_data - 1;
-- 
1.9.1

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

Re: [U-Boot] [PATCH v8 4/7] arm: socfpga: Enable FPGA driver on SPL

[Chee, Tien Fong]

On Sel, 2017-06-13 at 11:05 +0200, Marek Vasut wrote:
> On 06/13/2017 05:26 AM, Chee, Tien Fong wrote:
> > 
> > On Isn, 2017-06-12 at 16:38 +0800, Chee, Tien Fong wrote:
> > > 
> > > On Jum, 2017-06-09 at 08:52 -0500, Dinh Nguyen wrote:
> > > > 
> > > > 
> > > > 
> > > > On 06/09/2017 03:25 AM, Marek Vasut wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > > I didn't really look since we still have a discussion open on
> > > > > V8
> > > > > .
> > > > > There
> > > > > is no point in sending new versions while discussion is still
> > > > > open.
> > > > > Also, I'd like some review from Ley/Dinh
> > > > I've reviewed v6 and gave my Reviewed-by. Now I see there's a
> > > > v10.
> > > > Should I be reviewing v10 or wait for a new version?
> > > > 
> > > > Dinh
> > > If Marek agree with my planning, code cleaning for gen5 in
> > > different
> > > patchset. v10 is updated based on Mareks' comments on v9, then
> > > v10
> > > should be the final version.
> > > 
> > > Thanks.
> > Hi Marek,
> > 
> > I think Dinh is still waiting answer from you.
> Thanks for reminding me daily. I'm actually on vacation, so sorry for
> the delayed reply.
> 
> > 
> > Could you please to
> > advice?
> Actually I lost track of what's going on here, we're still having
> discussion on V8 and I already have V10 in my mailbox. I have two
> suggestions:
> 1) Slow down, bombarding people with new versions of patches every
> day
>    does not help at all. Give people some space to review the
> patchset,
>    discuss and let the discussion settle, then submit a new set. That
>    can take a week or more, so let's establish a rule that you will
> not
>    submit more than one version of the patchset each week unless
>    explicitly asked. OK ?
> 2) I'd like AB/RB from Dinh on this set, yes.
> 
Hi Dinh,

Could you help to review?

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

Re: [U-Boot] [PATCH v5 04/11] usb: host: xhci-rockchip: use fixed regulator to control vbus

[Marek Vasut]

On 06/19/2017 11:50 AM, rock-chips(daniel.meng) wrote:
> 
> 
> On 2017/6/18 13:11, Marek Vasut wrote:
>> On 06/18/2017 12:10 AM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 17 June 2017 at 13:33, Marek Vasut  wrote:
 On 06/17/2017 07:28 PM, Simon Glass wrote:
> Hi Marek,
>
> On 17 June 2017 at 00:22, Marek Vasut  wrote:
>> On 06/17/2017 05:41 AM, Simon Glass wrote:
>>> Hi Marek,
>>>
>>> On 15 June 2017 at 10:53, Marek Vasut  wrote:
 On 06/15/2017 05:51 AM, rock-chips(daniel.meng) wrote:
>
> On 2017/6/13 17:11, Marek Vasut wrote:
>> On 06/12/2017 11:19 AM, Meng Dongyang wrote:
>>> Use fixed regulator to control the voltage of vbus and turn off
>>> vbus when usb stop.
>>>
>>> Signed-off-by: Meng Dongyang 
>>> ---
>>>
>>> Changes in v5:
>>> - Propagate return value and print error message when failed
>>>
>>> Changes in v4:
>>> - Splited from patch [Uboot,v3,04/10]
>>> - Define set vbus as empty function if the macros aren't set
>>>
>>> Changes in v3: None
>>> Changes in v2:
>>> - Use fixed regulator to control vbus instead of gpio
>>>
>>>drivers/usb/host/xhci-rockchip.c | 55
>>> ++--
>>>1 file changed, 42 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/xhci-rockchip.c
>>> b/drivers/usb/host/xhci-rockchip.c
>>> index f559830..15df6ef 100644
>>> --- a/drivers/usb/host/xhci-rockchip.c
>>> +++ b/drivers/usb/host/xhci-rockchip.c
>>> @@ -11,10 +11,10 @@
>>>#include 
>>>#include 
>>>#include 
>>> -#include 
>>>#include 
>>>#include 
>>>#include 
>>> +#include 
>>>  #include "xhci.h"
>>>@@ -23,7 +23,7 @@ DECLARE_GLOBAL_DATA_PTR;
>>>struct rockchip_xhci_platdata {
>>>fdt_addr_t hcd_base;
>>>fdt_addr_t phy_base;
>>> -struct gpio_desc vbus_gpio;
>>> +struct udevice *vbus_supply;
>>>};
>>>  /*
>>> @@ -48,7 +48,7 @@ static int xhci_usb_ofdata_to_platdata(struct
>>> udevice *dev)
>>> */
>>>plat->hcd_base = dev_get_addr(dev);
>>>if (plat->hcd_base == FDT_ADDR_T_NONE) {
>>> -debug("Can't get the XHCI register base address\n");
>>> +error("Can't get the XHCI register base address\n");
>>>return -ENXIO;
>>>}
>>>@@ -62,19 +62,39 @@ static int
>>> xhci_usb_ofdata_to_platdata(struct
>>> udevice *dev)
>>>}
>>>  if (plat->phy_base == FDT_ADDR_T_NONE) {
>>> -debug("Can't get the usbphy register address\n");
>>> +error("Can't get the usbphy register address\n");
>>>return -ENXIO;
>>>}
>>>-/* Vbus gpio */
>>> -ret = gpio_request_by_name(dev, "rockchip,vbus-gpio", 0,
>>> -   >vbus_gpio, GPIOD_IS_OUT);
>>> +#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR)
>> I don't think you need the CONFIG_DM_USB , the driver depends
>> on it (or
>> should) already anyway.
> Yes, I will remove it in v6.
>>> +/* Vbus regulator */
>>> +ret = device_get_supply_regulator(dev, "vbus-supply",
>>> +  >vbus_supply);
>> So I was curious, does this expand to empty function or is
>> this not
>> defined if CONFIG_DM_REGULATOR is not defined ?
> This is not defined if CONFIG_DM_REGULATOR is not defined.
 Simon, can you comment on this ?
>>> It looks OK to me.
>> Shouldn't you have empty stub functions instead to avoid
>> proliferation
>> of adhoc #ifdef CONFIG_FOO throughout the codebase ?
> You could, but this is just a temporary state while apparently some
> rockchip boards don't use DM_USB and DM_REGULATOR. I'm not sure what
> those bad boards are, actually.
 Temporary state ? What's the final state then ?
>>> Well I wasn't aware that any rockchip boards didn't use regulators.
>>> Presumably this #ifdef is because of a board that does not.
>> This is IMO unrelated to rockchip.
>>
 Anyway, what if you just disable regulator support (because you don't
 need it for whatever reason), but want to keep USB ? Wouldn't it make
 more sense to have empty stub functions instead of swamping the drivers
 with ifdefs ?
>>> USB would not work without VBUS, which is handled with regulators
>> The VBUS can be directly tied to 5V rail without power switching.
>>
>>> , so
>>> 

Re: [U-Boot] [PATCH v5 04/11] usb: host: xhci-rockchip: use fixed regulator to control vbus

[rock-chips(daniel.meng)]

On 2017/6/18 13:11, Marek Vasut wrote:

On 06/18/2017 12:10 AM, Simon Glass wrote:

Hi Marek,

On 17 June 2017 at 13:33, Marek Vasut  wrote:

On 06/17/2017 07:28 PM, Simon Glass wrote:

Hi Marek,

On 17 June 2017 at 00:22, Marek Vasut  wrote:

On 06/17/2017 05:41 AM, Simon Glass wrote:

Hi Marek,

On 15 June 2017 at 10:53, Marek Vasut  wrote:

On 06/15/2017 05:51 AM, rock-chips(daniel.meng) wrote:


On 2017/6/13 17:11, Marek Vasut wrote:

On 06/12/2017 11:19 AM, Meng Dongyang wrote:

Use fixed regulator to control the voltage of vbus and turn off
vbus when usb stop.

Signed-off-by: Meng Dongyang 
---

Changes in v5:
- Propagate return value and print error message when failed

Changes in v4:
- Splited from patch [Uboot,v3,04/10]
- Define set vbus as empty function if the macros aren't set

Changes in v3: None
Changes in v2:
- Use fixed regulator to control vbus instead of gpio

   drivers/usb/host/xhci-rockchip.c | 55
++--
   1 file changed, 42 insertions(+), 13 deletions(-)

diff --git a/drivers/usb/host/xhci-rockchip.c
b/drivers/usb/host/xhci-rockchip.c
index f559830..15df6ef 100644
--- a/drivers/usb/host/xhci-rockchip.c
+++ b/drivers/usb/host/xhci-rockchip.c
@@ -11,10 +11,10 @@
   #include 
   #include 
   #include 
-#include 
   #include 
   #include 
   #include 
+#include 
 #include "xhci.h"
   @@ -23,7 +23,7 @@ DECLARE_GLOBAL_DATA_PTR;
   struct rockchip_xhci_platdata {
   fdt_addr_t hcd_base;
   fdt_addr_t phy_base;
-struct gpio_desc vbus_gpio;
+struct udevice *vbus_supply;
   };
 /*
@@ -48,7 +48,7 @@ static int xhci_usb_ofdata_to_platdata(struct
udevice *dev)
*/
   plat->hcd_base = dev_get_addr(dev);
   if (plat->hcd_base == FDT_ADDR_T_NONE) {
-debug("Can't get the XHCI register base address\n");
+error("Can't get the XHCI register base address\n");
   return -ENXIO;
   }
   @@ -62,19 +62,39 @@ static int xhci_usb_ofdata_to_platdata(struct
udevice *dev)
   }
 if (plat->phy_base == FDT_ADDR_T_NONE) {
-debug("Can't get the usbphy register address\n");
+error("Can't get the usbphy register address\n");
   return -ENXIO;
   }
   -/* Vbus gpio */
-ret = gpio_request_by_name(dev, "rockchip,vbus-gpio", 0,
-   >vbus_gpio, GPIOD_IS_OUT);
+#if defined(CONFIG_DM_USB) && defined(CONFIG_DM_REGULATOR)

I don't think you need the CONFIG_DM_USB , the driver depends on it (or
should) already anyway.

Yes, I will remove it in v6.

+/* Vbus regulator */
+ret = device_get_supply_regulator(dev, "vbus-supply",
+  >vbus_supply);

So I was curious, does this expand to empty function or is this not
defined if CONFIG_DM_REGULATOR is not defined ?

This is not defined if CONFIG_DM_REGULATOR is not defined.

Simon, can you comment on this ?

It looks OK to me.

Shouldn't you have empty stub functions instead to avoid proliferation
of adhoc #ifdef CONFIG_FOO throughout the codebase ?

You could, but this is just a temporary state while apparently some
rockchip boards don't use DM_USB and DM_REGULATOR. I'm not sure what
those bad boards are, actually.

Temporary state ? What's the final state then ?

Well I wasn't aware that any rockchip boards didn't use regulators.
Presumably this #ifdef is because of a board that does not.

This is IMO unrelated to rockchip.


Anyway, what if you just disable regulator support (because you don't
need it for whatever reason), but want to keep USB ? Wouldn't it make
more sense to have empty stub functions instead of swamping the drivers
with ifdefs ?

USB would not work without VBUS, which is handled with regulators

The VBUS can be directly tied to 5V rail without power switching.


, so
there is something I don't understand here. Anyway I don't see any
point in adding stub functions here.

Not here, into the regulator framework, so you don't have to pollute
drivers which use the regulators with ifdefs if the regulator framework
is not enabled in the config.


Meng can you please explain why the #ifdef is needed?


Because the function "device_get_supply_regulator" is undefined if undefined
CONFIG_DM_REGULATOR and this will result in a compile error. Maybe the regulator
framework can be optimized and make it compiled successful whether define
CONFIG_DM_REGULATOR.
So is this #ifdef still needed here?




Regards,
Simon






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

Re: [U-Boot] [RFC PATCH] net: ag7xxx: Clean up some issues with phy access

[Marek Vasut]

On 06/13/2017 06:28 PM, Joe Hershberger wrote:
> On Tue, Jun 13, 2017 at 4:24 AM, Marek Vasut  wrote:
>> On 06/12/2017 10:20 PM, Joe Hershberger wrote:
>>> Don't wait forever, Pass errors back, etc.
>>>
>>> Signed-off-by: Joe Hershberger 
>>>
>>> ---
>>> This is a pass at improving the code quality.
>>> This has not been tested in any way.
>>>
>>>  drivers/net/ag7xxx.c | 63 
>>> +---
>>>  1 file changed, 50 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/drivers/net/ag7xxx.c b/drivers/net/ag7xxx.c
>>> index cf60d11..c8352d1 100644
>>> --- a/drivers/net/ag7xxx.c
>>> +++ b/drivers/net/ag7xxx.c
> 
> [...] SNIP
> 
>>> @@ -723,10 +764,13 @@ static int ag933x_phy_setup_common(struct udevice 
>>> *dev)
>>>   return ret;
>>>
>>>   /* Read out link status */
>>> - ret = ag7xxx_mdio_read(priv->bus, phymax, 0, MII_MIPSCR);
>>> + ret = ag7xxx_mdio_read(priv->bus, phymax, 0, AG7XXX_PHY_PSSR);
>>>   if (ret < 0)
>>>   return ret;
>>>
>>> + if (!(ret & AG7XXX_PHY_PSSR_LINK_UP))
>>> + return -ENOLINK;
>>
>> Are you sure about this ?
> 
> It seems reasonable to me, but I don't have the HW to test against as
> noted above.

CCing Wills . I wouldn't be surprised if the hardware was somehow
magically screwed up, so I'd prefer to stick with equivalent changes and
maybe changes of the logic in a separate patch.

>>>   return 0;
>>>   }
>>>
>>> @@ -743,13 +787,6 @@ static int ag933x_phy_setup_common(struct udevice *dev)
>>>   return ret;
>>>   }
>>>
>>> - for (i = 0; i < phymax; i++) {
>>> - /* Read out link status */
>>> - ret = ag7xxx_mdio_read(priv->bus, i, 0, MII_MIPSCR);
>>> - if (ret < 0)
>>> - return ret;
>>> - }
>>
>> And this ?
> 
> This was based on your comment: "Actually, I think this is only for
> the switch ports, so we don't care about the link status."

Just so I understand it correctly, the code reads link status and does
nothing with it ?

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

[U-Boot] [PATCH] drivers: mmc: Change buffer type in ALLOC_CACHE_ALIGN_BUFFER macro

[sunil . m]

From: Suniel Mahesh 

__be32_to_cpu() accepts argument of type __be32. This patch changes type of
the buffer in ALLOC_CACHE_ALIGN_BUFFER macro to __be32, which is then passed
to __be32_to_cpu().
This prevents sparse build warnings.
drivers/mmc/mmc.c: warning: cast to restricted __be32

Signed-off-by: Suniel Mahesh 
Signed-off-by: Karthik Tummala 
---
Note:
- Build was carried out with the above changes, no build errors
  reported.
---
 drivers/mmc/mmc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index 3cdf6a4..3d4da4c 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -882,8 +882,8 @@ static int sd_change_freq(struct mmc *mmc)
 {
int err;
struct mmc_cmd cmd;
-   ALLOC_CACHE_ALIGN_BUFFER(uint, scr, 2);
-   ALLOC_CACHE_ALIGN_BUFFER(uint, switch_status, 16);
+   ALLOC_CACHE_ALIGN_BUFFER(__be32, scr, 2);
+   ALLOC_CACHE_ALIGN_BUFFER(__be32, switch_status, 16);
struct mmc_data data;
int timeout;
 
-- 
1.9.1

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

[U-Boot] [PATCH v1] rockchip: pwm: fix: pwm dosen't work on rk3288

[Eric Gao]

According to rk3288 spec, the pwm register order is:
PWM_PWM0_CNT,
PWM_PWM0_PERIOD_HPR,
PWM_PWM0_DUTY_LPR,
PWM_PWM0_CTRL

but the source code's order is:
struct rk3288_pwm {
u32 cnt;
u32 duty_lpr;
u32 period_hpr;
u32 ctrl;
};

So, correct it here. It is the same as RK3399

Signed-off-by: Eric Gao 

---

 arch/arm/include/asm/arch-rockchip/pwm.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/include/asm/arch-rockchip/pwm.h 
b/arch/arm/include/asm/arch-rockchip/pwm.h
index 5d9a178..08ff945 100644
--- a/arch/arm/include/asm/arch-rockchip/pwm.h
+++ b/arch/arm/include/asm/arch-rockchip/pwm.h
@@ -10,8 +10,8 @@
 
 struct rk3288_pwm {
u32 cnt;
-   u32 duty_lpr;
u32 period_hpr;
+   u32 duty_lpr;
u32 ctrl;
 };
 check_member(rk3288_pwm, ctrl, 0xc);
-- 
1.9.1


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

Re: [U-Boot] [PATCH 2/2] mmc: rpmb: update size format for write_counter

[Lothar Waßmann]

Hi,

On Tue, 13 Jun 2017 10:11:17 +0800 Kever Yang wrote:
> Hi Simon,
> 
> 
> On 06/09/2017 08:28 PM, Simon Glass wrote:
> > On 7 June 2017 at 19:20, Kever Yang  wrote:
> >> According to MMC spec, the write_counter is 4-byte length,
> >> use 'int' instead of 'long' type for the 'long' is not 4-byte
> >> in 64 bit CPU.
> >>
> >> Signed-off-by: Jason Zhu 
> >> Signed-off-by: Kever Yang 
> >> ---
> >>
> >>   drivers/mmc/rpmb.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> > So should we use uint32_t?
> 
> Yes, we can use uint32_t, I use 'unsigned int' just for the same format 
> with other
> members in the structure which using unsigned char/short.
> 
> Is there a doc for which kind of data format prefer to use first in U-Boot?
> unsigned int, uint32_t, u32;
> 
uint32_t is guaranteed to be of size 32bit according to the C spec.
'[unsigned] int' is only guaranteed to be at least 32bit but can be
larger on some machine.
A good overview of the C data types and their properties can be found
at: https://en.wikipedia.org/wiki/C_data_types


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

[U-Boot] [PATCH v2 1/3] rockchip: video: mipi: Add rk3288 soc specific driver for mipi dsi

[Eric Gao]

Add rk3288 soc specific driver for mipi dsi.

Signed-off-by: Eric Gao 

---

Changes in v1:
-Change function name from rk_display_enable to rk_mipi_enable.
-Use IS_ERR to judge the return status.
-Use dev_read_addr to replace devfdt_get_addr.

 drivers/video/rockchip/rk3288_mipi.c | 191 +++
 1 file changed, 191 insertions(+)
 create mode 100644 drivers/video/rockchip/rk3288_mipi.c

diff --git a/drivers/video/rockchip/rk3288_mipi.c 
b/drivers/video/rockchip/rk3288_mipi.c
new file mode 100644
index 000..a0d3544
--- /dev/null
+++ b/drivers/video/rockchip/rk3288_mipi.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright (c) 2017, Fuzhou Rockchip Electronics Co., Ltd
+ * Author: Eric Gao 
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rk_mipi.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#define MHz 100
+
+/* Select mipi dsi source, big or little vop */
+static int rk_mipi_dsi_source_select(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+   struct rk3288_grf *grf = priv->grf;
+   struct display_plat *disp_uc_plat = dev_get_uclass_platdata(dev);
+
+   /* Select the video source */
+   switch (disp_uc_plat->source_id) {
+   case VOP_B:
+   rk_clrsetreg(>soc_con6, RK3288_DSI0_LCDC_SEL_MASK,
+RK3288_DSI0_LCDC_SEL_BIG
+<< RK3288_DSI0_LCDC_SEL_SHIFT);
+   break;
+   case VOP_L:
+   rk_clrsetreg(>soc_con6, RK3288_DSI0_LCDC_SEL_MASK,
+RK3288_DSI0_LCDC_SEL_LIT
+<< RK3288_DSI0_LCDC_SEL_SHIFT);
+   break;
+   default:
+   debug("%s: Invalid VOP id\n", __func__);
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+/* Setup mipi dphy working mode */
+static void rk_mipi_dphy_mode_set(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+   struct rk3288_grf *grf = priv->grf;
+   int val;
+
+   /* Set Controller as TX mode */
+   val = RK3288_DPHY_TX0_RXMODE_DIS << RK3288_DPHY_TX0_RXMODE_SHIFT;
+   rk_clrsetreg(>soc_con8, RK3288_DPHY_TX0_RXMODE_MASK, val);
+
+   /* Exit tx stop mode */
+   val |= RK3288_DPHY_TX0_TXSTOPMODE_EN
+   << RK3288_DPHY_TX0_TXSTOPMODE_SHIFT;
+   rk_clrsetreg(>soc_con8,
+RK3288_DPHY_TX0_TXSTOPMODE_MASK, val);
+
+   /* Disable turnequest */
+   val |= RK3288_DPHY_TX0_TURNREQUEST_EN
+   << RK3288_DPHY_TX0_TURNREQUEST_SHIFT;
+   rk_clrsetreg(>soc_con8,
+RK3288_DPHY_TX0_TURNREQUEST_MASK, val);
+}
+
+/*
+ * This function is called by rk_display_init() using rk_mipi_dsi_enable() and
+ * rk_mipi_phy_enable() to initialize mipi controller and dphy. If success,
+ * enable backlight.
+ */
+static int rk_mipi_enable(struct udevice *dev, int panel_bpp,
+ const struct display_timing *timing)
+{
+   int ret;
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+
+   /* Fill the mipi controller parameter */
+   priv->ref_clk = 24 * MHz;
+   priv->sys_clk = priv->ref_clk;
+   priv->pix_clk = timing->pixelclock.typ;
+   priv->phy_clk = priv->pix_clk * 6;
+   priv->txbyte_clk = priv->phy_clk / 8;
+   priv->txesc_clk = 20 * MHz;
+
+   /* Select vop port, big or little */
+   rk_mipi_dsi_source_select(dev);
+
+   /* Set mipi dphy work mode */
+   rk_mipi_dphy_mode_set(dev);
+
+   /* Config  and enable mipi dsi according to timing */
+   ret = rk_mipi_dsi_enable(dev, timing);
+   if (ret) {
+   debug("%s: rk_mipi_dsi_enable() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   /* Config and enable mipi phy */
+   ret = rk_mipi_phy_enable(dev);
+   if (ret) {
+   debug("%s: rk_mipi_phy_enable() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   /* Enable backlight */
+   ret = panel_enable_backlight(priv->panel);
+   if (ret) {
+   debug("%s: panel_enable_backlight() failed (err=%d)\n",
+ __func__, ret);
+   return ret;
+   }
+
+   return 0;
+}
+
+static int rk_mipi_ofdata_to_platdata(struct udevice *dev)
+{
+   struct rk_mipi_priv *priv = dev_get_priv(dev);
+
+   priv->grf = syscon_get_first_range(ROCKCHIP_SYSCON_GRF);
+   if (IS_ERR(priv->grf)) {
+   debug("%s: Get syscon grf failed (ret=%p)\n",
+ __func__, priv->grf);
+   return  -ENXIO;
+   }
+   priv->regs = (void *)dev_read_addr(dev);
+   if (priv->regs == FDT_ADDR_T_NONE) {
+   

[U-Boot] [PATCH v2 2/3] rockchip: video: Makefile: Add soc specific driver for rk3288 mipi dsi

[Eric Gao]

Signed-off-by: Eric Gao 
---

Changes in v1: None

 drivers/video/rockchip/Makefile | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/video/rockchip/Makefile b/drivers/video/rockchip/Makefile
index 600743c..8005003 100644
--- a/drivers/video/rockchip/Makefile
+++ b/drivers/video/rockchip/Makefile
@@ -14,6 +14,7 @@ obj-$(CONFIG_DISPLAY_ROCKCHIP_LVDS) += rk_lvds.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_hdmi.o
 obj-hdmi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_hdmi.o
 obj-$(CONFIG_DISPLAY_ROCKCHIP_HDMI) += rk_hdmi.o $(obj-hdmi-y)
+obj-mipi-$(CONFIG_ROCKCHIP_RK3288) += rk3288_mipi.o
 obj-mipi-$(CONFIG_ROCKCHIP_RK3399) += rk3399_mipi.o
 obj-$(CONFIG_DISPLAY_ROCKCHIP_MIPI) += rk_mipi.o $(obj-mipi-y)
 endif
-- 
1.9.1


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

[U-Boot] [PATCH v2 3/3] rockchip: video: defconfig: Add mipi dsi support for evb-rk3288

[Eric Gao]

Add support for rk3288 mipi dsi.

Signed-off-by: Eric Gao 
Reviewed-by: Simon Glass 

---

Changes in v1:
-Make the subject more intelligible.

 configs/evb-rk3288_defconfig | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/configs/evb-rk3288_defconfig b/configs/evb-rk3288_defconfig
index 227150d..fb5599d 100644
--- a/configs/evb-rk3288_defconfig
+++ b/configs/evb-rk3288_defconfig
@@ -6,8 +6,8 @@ CONFIG_ROCKCHIP_SPL_BACK_TO_BROM=y
 CONFIG_TARGET_EVB_RK3288=y
 CONFIG_SPL_STACK_R_ADDR=0x8
 CONFIG_DEFAULT_DEVICE_TREE="rk3288-evb"
+CONFIG_DEBUG_UART=y
 CONFIG_SILENT_CONSOLE=y
-CONFIG_CONSOLE_MUX=y
 # CONFIG_DISPLAY_CPUINFO is not set
 CONFIG_SPL_STACK_R=y
 CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x2000
@@ -55,12 +55,16 @@ CONFIG_DM_REGULATOR_FIXED=y
 CONFIG_PWM_ROCKCHIP=y
 CONFIG_RAM=y
 CONFIG_SPL_RAM=y
-CONFIG_DEBUG_UART=y
 CONFIG_DEBUG_UART_BASE=0xff69
 CONFIG_DEBUG_UART_CLOCK=2400
 CONFIG_DEBUG_UART_SHIFT=2
 CONFIG_SYS_NS16550=y
 CONFIG_SYSRESET=y
+CONFIG_DM_VIDEO=y
+CONFIG_DISPLAY=y
+CONFIG_VIDEO_ROCKCHIP=y
+CONFIG_VIDEO_ROCKCHIP_MAX_YRES=1200
+CONFIG_DISPLAY_ROCKCHIP_MIPI=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
-- 
1.9.1


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

[U-Boot] [PATCH v2 0/3] Add mipi dsi support for evb-rk3288.

[Eric Gao]

Changes in v1:
-Change function name from rk_display_enable to rk_mipi_enable.
-Use IS_ERR to judge the return status.
-Use dev_read_addr to replace devfdt_get_addr.
-Make the subject more intelligible.

Eric Gao (3):
  rockchip: video: mipi: Add rk3288 soc specific driver for mipi dsi
  rockchip: video: Makefile: Add soc specific driver for rk3288 mipi dsi
  rockchip: video: defconfig: Add mipi dsi support for evb-rk3288

 configs/evb-rk3288_defconfig |   8 +-
 drivers/video/rockchip/Makefile  |   1 +
 drivers/video/rockchip/rk3288_mipi.c | 191 +++
 3 files changed, 198 insertions(+), 2 deletions(-)
 create mode 100644 drivers/video/rockchip/rk3288_mipi.c

-- 
1.9.1


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